From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01629 for ; Fri, 19 May 2000 22:28:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 19 May 2000 22:28:49 +0200 (MEST) Received: (qmail 639 invoked by uid 0); 19 May 2000 20:10:50 -0000 Received: from ml.egroups.com (208.50.144.77) by mx16.rz2.gmx.net with SMTP; 19 May 2000 20:10:50 -0000 X-eGroups-Return: sentto-1101623-280-958767035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 19 May 2000 21:10:37 -0000 Received: (qmail 23444 invoked from network); 19 May 2000 20:10:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 19 May 2000 20:10:34 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta3 with SMTP; 19 May 2000 20:10:34 -0000 Received: from 216-164-139-61.s315.tnt5.lnhva.md.dialup.rcn.com ([216.164.139.61] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12st6P-000716-00 for f-cpu@egroups.com; Fri, 19 May 2000 16:10:33 -0400 Message-ID: <3925CA4D.44E29D49@starpower.net> Organization: Nanosoft; Software That Thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: "f-cpu@egroups.com" From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 19 May 2000 16:12:13 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] I need a... =P Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 10b7e3563f9119bfa7d35b5571b75937 Status: RO X-Status: O Hi,

I'm in one of my "I need a scalable vector supercomputer" moods. Anyone
interested in fork();ing a project/company?

party!

--
If your computer doesn't have an off switch; panic.
http://users.erols.com/alangrimes/
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02496 for ; Sat, 20 May 2000 00:30:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 May 2000 00:30:40 +0200 (MEST) Received: (qmail 26493 invoked by uid 0); 19 May 2000 22:26:24 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 19 May 2000 22:26:24 -0000 X-eGroups-Return: sentto-1101623-282-958775178-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 19 May 2000 23:26:19 -0000 Received: (qmail 6383 invoked from network); 19 May 2000 22:26:17 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 19 May 2000 22:26:17 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta3 with SMTP; 19 May 2000 22:26:17 -0000 Received: from 216-164-139-61.s315.tnt5.lnhva.md.dialup.rcn.com ([216.164.139.61] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12svDk-0001Ro-00 for f-cpu@egroups.com; Fri, 19 May 2000 18:26:16 -0400 Message-ID: <3925EA1A.6CED4EE0@starpower.net> Organization: Nanosoft; Software That Thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <3925CA4D.44E29D49@starpower.net> <3925B9C0.DC567374@nventure.com> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 19 May 2000 18:27:54 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I need a... =P Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b3e1bbf5a4d8bb7f9f02aaf7fbd89189 Status: RO X-Status: O Albert Abramson wrote:
>
> Sounds cool.  How well will it perform on branching code?

Officially: I want it to be somewhere between a Beowulf and a CRAY...
Secretly: I want the #1 spot at www.top500.org =P

--
If your computer doesn't have an off switch; panic.
http://users.erols.com/alangrimes/
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02490 for ; Sat, 20 May 2000 00:30:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 May 2000 00:30:39 +0200 (MEST) Received: (qmail 14055 invoked by uid 0); 19 May 2000 22:07:42 -0000 Received: from hj.egroups.com (208.50.144.90) by mx0.gmx.net with SMTP; 19 May 2000 22:07:42 -0000 X-eGroups-Return: sentto-1101623-281-958774059-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hj.egroups.com with NNFMP; 19 May 2000 22:07:40 -0000 Received: (qmail 29608 invoked from network); 19 May 2000 22:07:38 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 19 May 2000 22:07:38 -0000 Received: from unknown (HELO nvsvr1.nventure.com) (208.186.47.134) by mta1 with SMTP; 19 May 2000 22:07:38 -0000 Received: from nventure.com ([208.186.46.22]) by nvsvr1.nventure.com (Post.Office MTA v3.5.3 release 223 ID# 0-52276U600L100S0V35) with ESMTP id com for ; Fri, 19 May 2000 15:10:58 -0700 Message-ID: <3925B9C0.DC567374@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <3925CA4D.44E29D49@starpower.net> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 19 May 2000 15:01:36 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I need a... =P Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9c92928500616b3c55e4ec536d845bf3 Status: RO X-Status: O Sounds cool.  How well will it perform on branching code?

--Maxx


Alan Grimes wrote:

> Hi,
>
> I'm in one of my "I need a scalable vector supercomputer" moods. Anyone
> interested in fork();ing a project/company?
>
> party!
>
> --
> If your computer doesn't have an off switch; panic.
> http://users.erols.com/alangrimes/
>
> ------------------------------------------------------------------------
> Make new friends, find the old at Classmates.com:
> http://click.egroups.com/1/4052/0/_/3462/_/958767035/
> ------------------------------------------------------------------------
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01587 for ; Fri, 19 May 2000 22:28:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 19 May 2000 22:28:39 +0200 (MEST) Received: (qmail 23413 invoked by uid 0); 19 May 2000 05:37:40 -0000 Received: from fk.egroups.com (208.50.144.73) by mx14.rz2.gmx.net with SMTP; 19 May 2000 05:37:40 -0000 X-eGroups-Return: notify-return-sloyment=gmx.net@egroups.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 19 May 2000 05:37:35 -0000 Received: (qmail 16035 invoked by alias); 19 May 2000 05:37:34 -0000 Date: 19 May 2000 05:37:34 -0000 Message-ID: <958714654.16024@egroups.com> From: f-cpu Moderator To: sloyment@gmx.net Subject: Welcome to f-cpu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-UIDL: c2246e765ad0cbed2684e66fc978c8df Status: RO X-Status: O This is the main mailing list for the Freedom CPU Project. It will be broken down into various topic-specific lists as needed. From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00318 for ; Sat, 20 May 2000 18:01:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 May 2000 18:01:39 +0200 (MEST) Received: (qmail 21975 invoked by uid 0); 20 May 2000 02:33:40 -0000 Received: from cj.egroups.com (208.50.144.68) by mx14.rz2.gmx.net with SMTP; 20 May 2000 02:33:40 -0000 X-eGroups-Return: sentto-1101623-283-958790018-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 20 May 2000 02:33:39 -0000 Received: (qmail 15553 invoked from network); 20 May 2000 02:33:37 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 20 May 2000 02:33:37 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 20 May 2000 02:33:37 -0000 Received: from f-cpu.org (Paris-Raspail-4-84.club-internet.fr [195.36.203.84]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA16727 for ; Sat, 20 May 2000 04:33:34 +0200 (MET DST) Message-ID: <3925F805.21D837ED@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3925CA4D.44E29D49@starpower.net> <3925B9C0.DC567374@nventure.com> <3925EA1A.6CED4EE0@starpower.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 May 2000 04:27:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I need a... {reality check} =P Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d70d9381f78850fbed84d3686bd8c6e Status: RO X-Status: O here goes alan again ;-)

[i was afraid that the list would stall for good...
gimme a month or two and then i'll be ready to make
the SW FC0 simulator in C, but i have to finish the
writing of my master thesis : "Lattice gas cellular
automata and intensive computing : optimisation of
a LGCA software for 5th and 6th generation CPUs"
(in french)...]

Alan Grimes wrote:
>
> Albert Abramson wrote:
> >
> > Sounds cool.  How well will it perform on branching code?
everybody reinvents the CRAY everyday. go to your nearest local
patent office and spend a few hours there... you'll be scared...
so i don't think that branching is a problem anymore.
i have a practical CRAY-2 application that is described
in a doctor thesis, and memory is far more problematic...
(what's the point of branching quickly if the memory doesn't
follow the core frequency ???)

> Officially: I want it to be somewhere between a Beowulf and a CRAY...
> Secretly: I want the #1 spot at www.top500.org =P

top500 doesn't really count REAL sites. and you know that the spooks
won't reveal their real available park.

i gave up with seeking the top absolute performance for several reasons :
- Seymour Cray and the japanese (like at NEC, Fujitsu etc) have invented
everything that needed to be invented. there's not much to compete in
this field anymore. Peta is coming soon
( http://www.superconductorweek.com/scce/feature-petaflops.htm )
and still, boolean logic & de Morgan's rules still apply.
- it takes tens of millions (say, $50M) to launch a new computer of that
kind, and it sells very badly. vectors are dead, real beos are owned
by a few companies (Sun, HP and a few others). profits are not interesting
yet. noone needs one, power consumption and dissipation are difficult to
manage for an individual, so who would buy that ?
- you skip from one project to another all the time. you'll get bored soon
(sphereos does exist for 6 months, and you want to stop already). it takes
around two years to launch a new computer architecture "in the best case".
- Since absolute raw performance is too costly and difficult to manage,
i decided to make not the most powerful ever, but the sexiest CPU architecture.
it's far more interesting. this makes us remember that designing computer
is a real art, not something that we can laugh at. and i'm mostly an artist.

i'm sure that one day or another, you'll know what you can do, and what's
not worth trying. but to know this, you'll have to try anyway, right ?
then go to the nearest CS university and don't go outside before you haven't
read every single book about digital design, computer programming and
applied networking.

And if you really want to be in the beo business, create PCI cards
for 2-feet long PC-to-PC communication (4 or 6 links per card).
since the HW is already at a "ceiling" price, what's missing is the
efficient & cheap communication link (not loosy 10 or 100Mbps ethernet...).

just a few cents i throw in the game...


> If your computer doesn't have an off switch; panic.
i have "shutdown -s now", does that count ?

</rant>

> http://users.erols.com/alangrimes/
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00345 for ; Sat, 20 May 2000 18:01:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 May 2000 18:01:45 +0200 (MEST) Received: (qmail 13653 invoked by uid 0); 20 May 2000 11:41:09 -0000 Received: from hi.egroups.com (208.50.144.89) by mx0.gmx.net with SMTP; 20 May 2000 11:41:09 -0000 X-eGroups-Return: sentto-1101623-284-958822866-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 20 May 2000 11:41:07 -0000 Received: (qmail 9473 invoked from network); 20 May 2000 11:41:06 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 20 May 2000 11:41:06 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (205.152.0.91) by mta3 with SMTP; 20 May 2000 11:41:06 -0000 Received: from default (host-209-215-11-39.bix.bellsouth.net [209.215.11.39]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA13983; Sat, 20 May 2000 07:41:03 -0400 (EDT) Message-ID: <39267A19.4B2E@bellsouth.net> Organization: Erin Greene & Associates X-Mailer: Mozilla 3.01C-BLS20 (Win95; U) To: f-cpu@egroups.com Cc: rhartney@bellsouth.net From: "Richard E. Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 May 2000 06:42:17 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN64 Processor(Food for Thought) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 989461ed549dcc1eb95cc66957320345 Status: RO X-Status: O Have been using the past several days in creating Block Diagrams
of the so-called pipeline structure.  One is a basic Top Level that
shows the Fetch, Execute & Store functions.  There is no decoding in the
execute phase as I am a micro-programmed beast.  Expanding the
instruction to 72 bits is perfect.  There are 72 instructions and a
free-be NOP; which is an all zero's word, making it 73.
      Have added back in the Normalize, Bit Reversal, and Shift Count to
A-Reg (SCA) instructions which are included above.  WHY?  I have decided
to delete Hardware Multiply/Divide and Floating Point options to the
System and add these to the TIPS (Total Information Programming System)
Language.  As I have said before; this is the operating system
I am going to capture with the above functions added to the COMMAND
LIST.  Below is the Language of TIPS from page 6 of the Application
Programmer Reference Manual.

                  THE LANGUAGE OF TIPS

1.0  The TIPS Lexicon
      The TIPS language consists of vocabulary words, variable markers and
punctuation marks which are used to form legal strings called statements
for execution by the system.

COMMANDS      OPERATORS      MODIFIERS      VARIABLE MARKERS

PRINT            FILE            IN FORM            "X" Literal marker

PRIORITY      PAGE            FOR            <X> Value marker

DISPLAY            PART            IF            [X] Numerical position
                                        marker
DEMAND            FORM            ON

SET            +(PLUS)            ENQUE            PUNCTUATION MARKS

DELETE            -(minus)                  /  Step marker
                        SYSTEM
COMPILE            =(equals)      VARIABLES      :  Range of values
                                       marker
WAIT            =>            LP1            ;  Statement terminator

TO            <=            LP2            ,  List delimiter

DO            READER            LP3            @  Keyboard input
                                       terminator
DONE            LIGHTPEN      LP4            . (center dot) subfile
                                      marker
SEND            STEP            TIME            *  Comment marker

RECEIVE            VIDEO            CLOCK

(reserved)      &(Concatenation) BLINK
              OPERATOR
                        UNBLINK

                        $XX$ (1)
                        T1

                        T2

(1) All 4 character variables starting and ending with $ reserved for
Error Handling and Initialization.

      I am adding to the above COMMAND LIST:
            (1)  MUL
            (2)  DIV
            (3)  FADD
            (4)  FSUB
            (5)  FMUL
            (6)  FDIV
            (7)  FSQRT
            (8)  etc.; (other Intrinsics)

      Have not received finalized data on the Quicklogic QL6050 FPGA;
however; based on their progression from 0.50 to 0.35 micron and now to
0.25; the resulting performance of the ERIN64 will be strictly a matter
of choice that can range anywhere from 25 MHZ to 1 GHZ.  Basically the
design consists mainly of FF's and Multiplexers.  Currently have two
Adders, two Subtracters, and two Barrel Shifters.  The faster throughput
results in a binary progression of each.  Thatis; 1 - 2 - 4 - 8 etc.
This requires more Multiplexers to carry thru results.  I can go to
the device maximum which is limited by multiplexers not Logic Gates.
Incidently the QL6050 effectively has Cross-bar capability in its
multiplexer structure, up to 16 wide with a throughput of 2.5 NS.
I will use this capability as an input to the Accumulator (the only on
chip user register) which requires 13 inputs.

      I assume Mr. Guidon has not read any of the data package I sent
him.  Most of that data is now invalid anyway, except for the info on
TIPS.  The performance comparisons are out the window - thanks to me
getting interested in the F-CPU project.

Have a nice day - and incidently to the Gentleman who is interested in
Vector Processing - here in this design is a good starting point.

Sincerely
Richard E. Hartney
Research Director
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04486 for ; Mon, 22 May 2000 08:17:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 May 2000 08:17:42 +0200 (MEST) Received: (qmail 31559 invoked by uid 0); 22 May 2000 06:14:42 -0000 Received: from c9.egroups.com (207.138.41.187) by mx18.rz2.gmx.net with SMTP; 22 May 2000 06:14:42 -0000 X-eGroups-Return: sentto-1101623-285-958976077-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 22 May 2000 06:14:38 -0000 Received: (qmail 28344 invoked from network); 22 May 2000 06:14:36 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 22 May 2000 06:14:36 -0000 Received: from unknown (HELO oyakmenkul.com.tr) (212.15.17.178) by mta2 with SMTP; 22 May 2000 06:14:36 -0000 Received: from oyakwall.oyakmenkul.com.tr [212.15.17.177] by oyakmenkul.com.tr [212.15.17.178] with SMTP (MDaemon.v2.7.SP5.R) for ; Mon, 22 May 2000 01:13:02 +0300 Message-ID: X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: D7644IdT7@mail.at-m.or.jp From: D7644IdT7@mail.at-m.or.jp MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 21 May 00 4:57:01 PM Reply-To: f-cpu@egroups.com Subject: [f-cpu] the internet revolution is passing you by Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 1d58930b71b9cbead47a7c16b7bd111c Status: R X-Status: N Greetings:

ALL new members that come into the club
COMPANY WIDE will go under YOU.

A true VERTICAL downline.
YOU can easily get 200 members
under YOU in a month!

How would you like a GUARANTEED
minimum commission every month?

JOIN FREE!!!!!!!  JOIN FREE!!!!!!!

To join our FREE postlaunch program
reply to this email
and type your FIRST AND
LAST NAME as text. That's it.
We'll handle the rest.

mailto:joinnow@intmall123.com?subject=SignMeUp


Jump On Board! Join US!
RIDE THE WAVE OF SUCCESS!



to re removed from this list mailto:24remo@england.com?subject=remove
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02316 for ; Tue, 23 May 2000 02:21:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 May 2000 02:21:12 +0200 (MEST) Received: (qmail 7867 invoked by uid 0); 22 May 2000 19:24:20 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 22 May 2000 19:24:20 -0000 X-eGroups-Return: sentto-1101623-286-959023454-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 22 May 2000 19:24:14 -0000 Received: (qmail 6648 invoked from network); 22 May 2000 19:24:13 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 22 May 2000 19:24:13 -0000 Received: from unknown (HELO patience.ibsystems.com) (209.157.244.112) by mta1 with SMTP; 22 May 2000 19:24:13 -0000 Received: (from newsagent@localhost) by patience.ibsystems.com (8.9.3/8.9.3) id MAA14241 for f-cpu@egroups.com; Mon, 22 May 2000 12:18:32 -0700 Message-Id: <200005221918.MAA14241@patience.ibsystems.com> X-eGroups-From: newsagent@patience.ibsystems.com From: NewsAdmin@DACafe.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 May 2000 12:18:32 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DACafe News: May 22, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 74f19e738a98980756404aa3d30b6cfa Status: R X-Status: N Cafe News - May 22, 2000

Register for Synchronicity's lunch symposium Learn More about ECS

Cafe' News
EDA News on Your Desktop


Visit the EDAToolsCafe team at DAC 2000 in Los Angeles (Booth #4814) and join in the excitement. We'll be giving away a trip for two to Hawaii. Enter here for your chance to go to paradise. Surf's up!

Monday
May 22, 2000
http://www.dacafe.com

  EDA In the News Today

Tell a Friend about EDA NewsAgent

More EDA News

Save Big on Your Next PCB Fabrication Buy
Connecting Buyers to the Supply Chain
The WebQuote e-Procurement System connects Custom Product Buyers to Manufacturers. Automatic Request for Quote (RFQ) generation coupled with a reverse Auction Forum eliminate inefficiencies associated with conventional procurement methods to benefit both buyers and manufacturers.

Register and test drive WebQuote today!
More Than 500 Products Listed

Show me all:
products I can purchase online
demos I can download now

Feature your company's products in e-Catalog.

Complete Books Online
ASICS...the book! by Michael J. Smith
SMPS Simulation with SPICE 3 by Steven M. Sandler
Spice Hand Book by Steven M. Sandler
Logic Design For Array-Based Circuits by Donnamaie E. White
Bit-Slice Design:Controllers and ALUs by Donnamaie E. White

Featured Presentations
View more than 50 EDA presentations Online

  What's Hot on Your EDAToolsCafe

  Company Specials
Increase your site's traffic by adding hourly updated EDA news, and linking to the EDA industry's best resource portal. Click here to find out how.
Advertise on DACafe
DACafe Statistics
- Ranked #1 EDA web site by Alexa
- 4.3+ Million hits/month
- 400,000+ pageviews/month
- 68,000+ unique visitors/month
- 15,000+ NewsAgent subscribers
Explore our Advertising Opportunities.
You are subscribed as: [f-cpu@egroups.com]
Cafe News is a service for Design Automation professionals. DACafe respects your online time and Internet privacy. If you would prefer not to receive this type of email, please click here . You will be automatically removed from the subscription list. PLEASE NOTE: You can change your keywords and frequency of this message by clicking here and entering your email address as f-cpu@egroups.com . If you have questions about DACafe services, please send email to newsadmin@dacafe.com.

Copyright © 1999. Internet Business Systems, Inc. All rights reserved.

Hitometer

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00327 for ; Wed, 24 May 2000 07:10:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 07:10:35 +0200 (MEST) Received: (qmail 26817 invoked by uid 0); 23 May 2000 13:58:39 -0000 Received: from ho.egroups.com (208.50.144.85) by mx0.gmx.net with SMTP; 23 May 2000 13:58:39 -0000 X-eGroups-Return: sentto-1101623-287-959090279-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ho.egroups.com with NNFMP; 23 May 2000 13:58:05 -0000 Received: (qmail 24631 invoked from network); 23 May 2000 13:57:41 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 23 May 2000 13:57:41 -0000 Received: from unknown (HELO patience.ibsystems.com) (209.157.244.112) by mta1 with SMTP; 23 May 2000 13:57:40 -0000 Received: (from newsagent@localhost) by patience.ibsystems.com (8.9.3/8.9.3) id GAA29842 for f-cpu@egroups.com; Tue, 23 May 2000 06:51:55 -0700 Message-Id: <200005231351.GAA29842@patience.ibsystems.com> X-eGroups-From: newsagent@patience.ibsystems.com From: NewsAdmin@DACafe.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 May 2000 06:51:55 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DACafe News: May 23, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 925c422283a6518df99e3b029f7dc7d5 Status: R X-Status: N Cafe News - May 23, 2000

Register for Synchronicity's lunch symposium Learn More about ECS

Cafe' News
EDA News on Your Desktop


Visit the EDAToolsCafe team at DAC 2000 in Los Angeles (Booth #4814) and join in the excitement. We'll be giving away a trip for two to Hawaii. Enter here for your chance to go to paradise. Surf's up!

Tuesday
May 23, 2000
http://www.dacafe.com

  EDA In the News Today

Tell a Friend about EDA Cafe' News

More EDA News

Save Big on Your Next PCB Fabrication Buy
Connecting Buyers to the Supply Chain
The WebQuote e-Procurement System connects Custom Product Buyers to Manufacturers. Automatic Request for Quote (RFQ) generation coupled with a reverse Auction Forum eliminate inefficiencies associated with conventional procurement methods to benefit both buyers and manufacturers.

Register and test drive WebQuote today!
More Than 500 Products Listed

Show me all:
products I can purchase online
demos I can download now

Feature your company's products in e-Catalog.

Complete Books Online
ASICS...the book! by Michael J. Smith
SMPS Simulation with SPICE 3 by Steven M. Sandler
Spice Hand Book by Steven M. Sandler
Logic Design For Array-Based Circuits by Donnamaie E. White
Bit-Slice Design:Controllers and ALUs by Donnamaie E. White

Featured Presentations
View more than 50 EDA presentations Online

  What's Hot on Your EDAToolsCafe

  Company Specials
Increase your site's traffic by adding hourly updated EDA news, and linking to the EDA industry's best resource portal. Click here to find out how.
Advertise on EDAToolsCafe.com
EDAToolsCafe Statistics
- Ranked #1 EDA web site by Alexa
- 4.3+ Million hits/month
- 400,000+ pageviews/month
- 68,000+ unique visitors/month
- 15,000+ NewsAgent subscribers
Explore our Advertising Opportunities.
You are subscribed as: [f-cpu@egroups.com]
Cafe News is a service for Design Automation professionals. EDAToolsCafe respects your online time and Internet privacy. If you would prefer not to receive this type of email, please click here . You will be automatically removed from the subscription list. PLEASE NOTE: You can change your keywords and frequency of this message by clicking here and entering your email address as f-cpu@egroups.com . If you have questions about EDAToolsCafe services, please send email to newsadmin@dacafe.com.

Copyright © 1999. Internet Business Systems, Inc. All rights reserved.

Hitometer

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00348 for ; Wed, 24 May 2000 07:10:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 07:10:43 +0200 (MEST) Received: (qmail 4427 invoked by uid 0); 23 May 2000 15:36:13 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 23 May 2000 15:36:13 -0000 X-eGroups-Return: sentto-1101623-288-959096164-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 23 May 2000 15:36:06 -0000 Received: (qmail 21190 invoked from network); 23 May 2000 15:34:44 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 23 May 2000 15:34:44 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 23 May 2000 15:34:41 -0000 Received: from f-cpu.org (Paris-Raspail-3-4.club-internet.fr [195.36.203.4]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA02038 for ; Tue, 23 May 2000 17:34:38 +0200 (MET DST) Message-ID: <392AA3A3.1D17398E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 May 2000 17:28:35 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] sinking ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3cf682276b31a167a1640842e3c8e4b5 Status: R X-Status: N hi,

there was not much activity here recently...

i have now the date of my finals for the university,
and i hope i'll have it at the first attempt.
i'll probably restart working on the simulator
in mid-june.

in the same time, i'm doing a french presentation
paper with someone else in my university. it will be later
translated to different langages, uploaded on the web sites
and printed on paper so we can present the project
quickly during trade shows.

the german and french "organisation movement" have stalled...
the association and the verein are not registered.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00393 for ; Wed, 24 May 2000 07:10:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 07:10:53 +0200 (MEST) Received: (qmail 2230 invoked by uid 0); 24 May 2000 01:35:19 -0000 Received: from fk.egroups.com (208.50.144.73) by mx5.rz2.gmx.net with SMTP; 24 May 2000 01:35:19 -0000 X-eGroups-Return: sentto-1101623-289-959132096-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 24 May 2000 01:34:59 -0000 Received: (qmail 28200 invoked from network); 24 May 2000 01:34:55 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 May 2000 01:34:55 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 24 May 2000 01:34:55 -0000 Received: from f-cpu.org (Paris-Raspail-2-219.club-internet.fr [195.36.192.219]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA14723 for ; Wed, 24 May 2000 03:34:51 +0200 (MET DST) Message-ID: <392B3039.FE6A6A26@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <392AA3A3.1D17398E@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 May 2000 03:28:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] sinking ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9b237a9a6c9632c4d1a6ce1ca53a246e Status: R X-Status: N hi,

Yann Guidon wrote:
>
> hi,
>
> there was not much activity here recently...
>
> i have now the date of my finals for the university,
> and i hope i'll have it at the first attempt.
> i'll probably restart working on the simulator
> in mid-june.
oooops ! i meant : "mid - july".
plus i have the intention to spend a few weeks outside of france.
maybe in order to meet the californian or german f-cpuers ?
(moffet field, bielefeld, munich, berlin, etc)

sorry for the wrong detail,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00396 for ; Wed, 24 May 2000 07:10:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 07:10:53 +0200 (MEST) Received: (qmail 3006 invoked by uid 0); 24 May 2000 02:11:53 -0000 Received: from hm.egroups.com (208.50.144.92) by mx0.gmx.net with SMTP; 24 May 2000 02:11:53 -0000 X-eGroups-Return: sentto-1101623-290-959134304-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 24 May 2000 02:11:48 -0000 Received: (qmail 26040 invoked from network); 24 May 2000 02:11:43 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 May 2000 02:11:43 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 24 May 2000 02:11:43 -0000 Received: from f-cpu.org (Paris-Raspail-2-219.club-internet.fr [195.36.192.219]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA10296 for ; Wed, 24 May 2000 04:11:40 +0200 (MET DST) Message-ID: <392B38EB.7DCF0326@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm References: <392AA3A3.1D17398E@f-cpu.org> <392B3039.FE6A6A26@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 May 2000 04:05:31 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] sinking ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 99fc8d00646c38c32e013407ec1cb4ee Status: R X-Status: N hi !

Colin Marquardt wrote:
>
> * Yann Guidon <whygee@f-cpu.org> writes:
>
> > maybe in order to meet the californian or german f-cpuers ?
>
> I am not an active F-CPUer, but I am German and I live in
> California. :-)
>
> Where is Moffet Field (mapquest didn't find it).
>
> Cheers,
>   Colin

Moffet field is a military ground which hosts the Computer Museum
(maintained by the sysad for comp.sys.super). it has a lot of
really interesting and historical machines :-))))))

> --
> Colin Marquardt <colin.marquardt@usa.alcatel.com>
> Alcatel USA, 1420 McDowell Blvd. North, Petaluma, CA 94954
> Phone: (+1 707) 665-8221   Fax: (+1 707) 792-7055

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01338 for ; Wed, 24 May 2000 19:46:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 19:46:18 +0200 (MEST) Received: (qmail 25106 invoked by uid 0); 24 May 2000 13:03:58 -0000 Received: from hi.egroups.com (208.50.144.89) by mx0.gmx.net with SMTP; 24 May 2000 13:03:58 -0000 X-eGroups-Return: sentto-1101623-291-959173435-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 24 May 2000 13:03:55 -0000 Received: (qmail 19209 invoked from network); 24 May 2000 13:03:54 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 May 2000 13:03:54 -0000 Received: from unknown (HELO patience.ibsystems.com) (209.157.244.112) by mta1 with SMTP; 24 May 2000 13:03:54 -0000 Received: (from newsagent@localhost) by patience.ibsystems.com (8.9.3/8.9.3) id FAA06699 for f-cpu@egroups.com; Wed, 24 May 2000 05:58:05 -0700 Message-Id: <200005241258.FAA06699@patience.ibsystems.com> X-eGroups-From: newsagent@patience.ibsystems.com From: NewsAdmin@DACafe.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 May 2000 05:58:05 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DACafe News: May 24, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 207c4cf994a2c6d03c778b845132fc2d Status: R X-Status: N Cafe News - May 24, 2000

Register for Synchronicity's lunch symposium Learn More about ECS

Cafe' News
EDA News on Your Desktop


Visit the EDAToolsCafe team at DAC 2000 in Los Angeles (Booth #4814) and join in the excitement. We'll be giving away a trip for two to Hawaii. Enter here for your chance to go to paradise. Surf's up!

Wednesday
May 24, 2000
http://www.dacafe.com

  EDA In the News Today

Tell a Friend about EDA Cafe' News

More EDA News

Save Big on Your Next PCB Fabrication Buy
Connecting Buyers to the Supply Chain
The WebQuote e-Procurement System connects Custom Product Buyers to Manufacturers. Automatic Request for Quote (RFQ) generation coupled with a reverse Auction Forum eliminate inefficiencies associated with conventional procurement methods to benefit both buyers and manufacturers.

Register and test drive WebQuote today!
More Than 500 Products Listed

Show me all:
products I can purchase online
demos I can download now

Feature your company's products in e-Catalog.

Complete Books Online
ASICS...the book! by Michael J. Smith
SMPS Simulation with SPICE 3 by Steven M. Sandler
Spice Hand Book by Steven M. Sandler
Logic Design For Array-Based Circuits by Donnamaie E. White
Bit-Slice Design:Controllers and ALUs by Donnamaie E. White

Featured Presentations
View more than 50 EDA presentations Online

  What's Hot on Your EDAToolsCafe

  Company Specials
Increase your site's traffic by adding hourly updated EDA news, and linking to the EDA industry's best resource portal. Click here to find out how.
Advertise on EDAToolsCafe.com
EDAToolsCafe Statistics
- Ranked #1 EDA web site by Alexa
- 4.3+ Million hits/month
- 400,000+ pageviews/month
- 68,000+ unique visitors/month
- 15,000+ NewsAgent subscribers
Explore our Advertising Opportunities.
You are subscribed as: [f-cpu@egroups.com]
Cafe News is a service for Design Automation professionals. EDAToolsCafe respects your online time and Internet privacy. If you would prefer not to receive this type of email, please click here . You will be automatically removed from the subscription list. PLEASE NOTE: You can change your keywords and frequency of this message by clicking here and entering your email address as f-cpu@egroups.com . If you have questions about EDAToolsCafe services, please send email to newsadmin@dacafe.com.

Copyright © 1999. Internet Business Systems, Inc. All rights reserved.

Hitometer

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01351 for ; Wed, 24 May 2000 19:46:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 19:46:35 +0200 (MEST) Received: (qmail 29060 invoked by uid 0); 24 May 2000 13:58:14 -0000 Received: from fh.egroups.com (208.50.144.71) by mx7.rz2.gmx.net with SMTP; 24 May 2000 13:58:14 -0000 X-eGroups-Return: sentto-1101623-292-959176672-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 24 May 2000 13:57:54 -0000 Received: (qmail 31384 invoked from network); 24 May 2000 13:56:52 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 24 May 2000 13:56:52 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta3 with SMTP; 24 May 2000 13:56:51 -0000 Received: from 216-164-133-126.s126.tnt3.lnhva.md.dialup.rcn.com ([216.164.133.126] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12ubeU-0003jl-00 for f-cpu@egroups.com; Wed, 24 May 2000 09:56:50 -0400 Message-ID: <392B6121.85F6CF68@starpower.net> Organization: Nanosoft; Software That Thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <200005241258.FAA06699@patience.ibsystems.com> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 May 2000 21:57:05 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DACafe News: May 24, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b51efab40566244d57edda1e25942111 Status: R X-Status: N Who is the stupid dumbfuck who subscribed the entire list to this damn HTML
based newsletter? I'm saving a bullet for you!

--
If your computer doesn't have an off switch; panic.
http://users.erols.com/alangrimes/
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01353 for ; Wed, 24 May 2000 19:46:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 19:46:36 +0200 (MEST) Received: (qmail 25125 invoked by uid 0); 24 May 2000 14:33:38 -0000 Received: from mo.egroups.com (207.138.41.166) by mx17.rz2.gmx.net with SMTP; 24 May 2000 14:33:38 -0000 X-eGroups-Return: sentto-1101623-293-959178807-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 24 May 2000 14:33:34 -0000 Received: (qmail 29940 invoked from network); 24 May 2000 14:31:47 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 May 2000 14:31:47 -0000 Received: from unknown (HELO dichlore.mime.univ-paris8.fr) (193.54.153.26) by mta2 with SMTP; 24 May 2000 14:31:44 -0000 Received: from mime.up8.edu (localhost [127.0.0.1]) by dichlore.mime.univ-paris8.fr (8.9.3/8.9.3) with ESMTP id QAA01168; Wed, 24 May 2000 16:31:53 GMT (envelope-from whygee@mime.up8.edu) Sender: whygee@dichlore.mime.univ-paris8.fr Message-ID: <392C03F9.5C7DFD40@mime.up8.edu> X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: fr-FR, en To: f-cpu@egroups.com References: <200005241258.FAA06699@patience.ibsystems.com> <392B6121.85F6CF68@starpower.net> From: YG MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 May 2000 16:31:53 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DACafe News: May 24, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b3ad4e9502e1a9c7e574a3ae1e090d01 Status: R X-Status: N Alan Grimes wrote:
>
> Who is the stupid dumbfuck who subscribed the entire list to this damn HTML
> based newsletter? I'm saving a bullet for you!

i have no idea at all. i just completed the form to unsub the list.
i hope it will stay this way forever.

WHYGEE
~~~~~~~~~~~~~~~~~~~~
"I'm a poor, a lonesome coder..."
SHARCPAGE: http://www.mime.up8.edu/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01357 for ; Wed, 24 May 2000 19:46:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 24 May 2000 19:46:38 +0200 (MEST) Received: (qmail 2946 invoked by uid 0); 24 May 2000 14:37:49 -0000 Received: from ej.egroups.com (208.50.144.75) by mx14.rz2.gmx.net with SMTP; 24 May 2000 14:37:49 -0000 X-eGroups-Return: sentto-1101623-294-959179061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 24 May 2000 14:37:45 -0000 Received: (qmail 24400 invoked from network); 24 May 2000 14:37:40 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 24 May 2000 14:37:40 -0000 Received: from unknown (HELO janus.hosting4u.net) (209.15.2.37) by mta3 with SMTP; 24 May 2000 14:37:40 -0000 Received: (qmail 18246 invoked from network); 24 May 2000 14:37:40 -0000 Received: from uranus.hosting4u.net (HELO free-ip.com) (209.15.2.18) by janus.hosting4u.net with SMTP; 24 May 2000 14:37:40 -0000 Received: from free-ip.com ([64.32.131.27]) by free-ip.com ; Wed, 24 May 2000 09:37:39 -0500 Message-ID: <392BE8FF.46B9BAE8@free-ip.com> Organization: The Free-IP Project X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en To: f-cpu@egroups.com References: <200005241258.FAA06699@patience.ibsystems.com> <392B6121.85F6CF68@starpower.net> <392C03F9.5C7DFD40@mime.up8.edu> From: David Kessner MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 May 2000 08:36:47 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DACafe News: May 24, 2000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 556aab3bd2536899a8e0abdcfe81de34 Status: R X-Status: N YG wrote:
> i have no idea at all. i just completed the form to unsub the list.
> i hope it will stay this way forever.
>
> WHYGEE

"Whoever" also signed up several other "open source IP" mailing
lists to the same thing.  It's really annoying getting 4 or 5 of
these a day... 

David Kessner
davidk@free-ip.com
http://www.free-ip.com/
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02700 for ; Fri, 26 May 2000 19:14:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 May 2000 19:14:32 +0200 (MEST) Received: (qmail 3962 invoked by uid 0); 26 May 2000 09:34:30 -0000 Received: from ej.egroups.com (208.50.144.75) by mx14.rz2.gmx.net with SMTP; 26 May 2000 09:34:30 -0000 X-eGroups-Return: sentto-1101623-295-959333659-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 26 May 2000 09:34:21 -0000 Received: (qmail 15707 invoked from network); 26 May 2000 09:34:17 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 26 May 2000 09:34:17 -0000 Received: from unknown (HELO dichlore.mime.univ-paris8.fr) (193.54.153.26) by mta1 with SMTP; 26 May 2000 09:34:15 -0000 Received: from mime.up8.edu (localhost [127.0.0.1]) by dichlore.mime.univ-paris8.fr (8.9.3/8.9.3) with ESMTP id LAA02420; Fri, 26 May 2000 11:33:30 GMT (envelope-from whygee@mime.up8.edu) Sender: whygee@dichlore.mime.univ-paris8.fr Message-ID: <392E610A.959B5D47@mime.up8.edu> X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: fr-FR, en To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> From: YG MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 May 2000 11:33:30 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (i) permute, SIMD... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5fec27e7b1ff2de08a7ce4f5e1ced56f Status: R X-Status: N hi,

this old thread is not dead. yet i have not found
the definitive solution to this problem.
i have a rough feeling about the high usefulness
of the permute instruction (same as the popcount :
look at the spooks) but going SIMD is difficult.

another instruction that should be considered is
the scatter/gather type of instruction. think of
this as a lookup table accessed parallelly by each
element ... or think of the load/store instruction,
but parallel... anyway.



WHYGEE
~~~~~~~~~~~~~~~~~~~~
"I'm a poor, a lonesome coder..."
SHARCPAGE: http://www.mime.up8.edu/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02757 for ; Fri, 26 May 2000 19:14:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 May 2000 19:14:46 +0200 (MEST) Received: (qmail 16358 invoked by uid 0); 26 May 2000 15:04:01 -0000 Received: from hk.egroups.com (208.50.144.91) by mx0.gmx.net with SMTP; 26 May 2000 15:04:01 -0000 X-eGroups-Return: sentto-1101623-296-959353420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hk.egroups.com with NNFMP; 26 May 2000 15:03:48 -0000 Received: (qmail 13341 invoked from network); 26 May 2000 15:03:40 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 26 May 2000 15:03:40 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta2 with SMTP; 26 May 2000 15:03:39 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e4QF3cR27439 for ; Fri, 26 May 2000 17:03:38 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e4QF3bT10376 for ; Fri, 26 May 2000 17:03:37 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id RAA10129 for ; Fri, 26 May 2000 17:03:37 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id RAA27005 for ; Fri, 26 May 2000 17:02:21 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <392E9248.C20D37DD@hl.siemens.de> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> <392E610A.959B5D47@mime.up8.edu> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 May 2000 17:03:36 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] URL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6081ee03a941ad61ebae2cf0a951adc6 Status: R X-Status: N Hi,

I have find an URL which is full of links to cpu architecture documents.
http://www.rdrop.com/~cary/html/computer_architecture.html

Especially, this one is interressant about the TTA.
http://cardit.et.tudelft.nl/MOVE/index.html

Maybe, the person who propose the TTA architecture worked for this
project.
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02760 for ; Fri, 26 May 2000 19:14:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 May 2000 19:14:46 +0200 (MEST) Received: (qmail 6198 invoked by uid 0); 26 May 2000 15:16:17 -0000 Received: from b05.egroups.com (207.138.41.189) by mx03.rz2.gmx.net with SMTP; 26 May 2000 15:16:17 -0000 X-eGroups-Return: sentto-1101623-297-959354169-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by b05.egroups.com with NNFMP; 26 May 2000 15:16:12 -0000 Received: (qmail 22904 invoked from network); 26 May 2000 15:15:40 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 26 May 2000 15:15:40 -0000 Received: from unknown (HELO dichlore.mime.univ-paris8.fr) (193.54.153.26) by mta1 with SMTP; 26 May 2000 15:15:36 -0000 Received: from mime.up8.edu (localhost [127.0.0.1]) by dichlore.mime.univ-paris8.fr (8.9.3/8.9.3) with ESMTP id RAA00438; Fri, 26 May 2000 17:15:46 GMT (envelope-from whygee@mime.up8.edu) Sender: whygee@dichlore.mime.univ-paris8.fr Message-ID: <392EB141.16EBA423@mime.up8.edu> X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: fr-FR, en To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> <392E610A.959B5D47@mime.up8.edu> <392E9248.C20D37DD@hl.siemens.de> From: YG MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 May 2000 17:15:45 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] URL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0914feac6791e06a8f47dec953b8f99d Status: R X-Status: N Nicolas Boulay wrote:
>
> Hi,
>
> I have find an URL which is full of links to cpu architecture documents.
> http://www.rdrop.com/~cary/html/computer_architecture.html
>
> Especially, this one is interressant about the TTA.
> http://cardit.et.tudelft.nl/MOVE/index.html
>
> Maybe, the person who propose the TTA architecture worked for this
> project.
> nicO

yes, David Cary is a f-cpuer, not active these days, but constructive
mind as far as i remember. i don't remember his position with TTA.
i wonder what he's doing now...

WHYGEE
~~~~~~~~~~~~~~~~~~~~
"I'm a poor, a lonesome coder..."
the F-CPU : http://www.mime.up8.edu/~whygee/f-cpu.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00313 for ; Sat, 27 May 2000 13:43:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 27 May 2000 13:43:28 +0200 (MEST) Received: (qmail 5669 invoked by uid 0); 27 May 2000 00:00:34 -0000 Received: from ef.egroups.com (207.138.41.172) by mx0.gmx.net with SMTP; 27 May 2000 00:00:34 -0000 X-eGroups-Return: sentto-1101623-298-959385627-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ef.egroups.com with NNFMP; 27 May 2000 00:00:29 -0000 Received: (qmail 8796 invoked from network); 27 May 2000 00:00:26 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 27 May 2000 00:00:26 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 27 May 2000 00:00:26 -0000 Received: from f-cpu.org (Paris-Raspail-4-97.club-internet.fr [195.36.203.97]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA27679 for ; Sat, 27 May 2000 01:49:40 +0200 (MET DST) Message-ID: <392F0FCD.58DD1E5A@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 May 2000 01:59:09 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] new mirror Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7dc54090c3754916b35858390b6491c8 Status: R X-Status: N hi,

with Paul Mota we're setting up a new server account.

i hope that it will become one day fr.f-cpu.org,
if Sven had a few minutes to manage this...

Mathias will shutdown f-cpu.tux.org soon,
compress all the site into a tgz, and redirect all
accesses to f-cpu.org.

OTOH, i hope that the Andercheran (spnish) site
will become one day es.f-cpu.org. and we have to
find a way to manage the e-mails too.

this will need a lot of work for some of us,
we'll have to revamp almost everything. We need
your advices and remarks, as well as help...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00441 for ; Sat, 27 May 2000 14:15:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 27 May 2000 14:15:05 +0200 (MEST) Received: (qmail 20576 invoked by uid 0); 27 May 2000 11:42:30 -0000 Received: from mu.egroups.com (207.138.41.151) by mx0.gmx.net with SMTP; 27 May 2000 11:42:30 -0000 X-eGroups-Return: sentto-1101623-299-959427743-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 27 May 2000 12:42:26 -0000 Received: (qmail 28866 invoked from network); 27 May 2000 11:42:23 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 27 May 2000 11:42:23 -0000 Received: from unknown (HELO mailout05.sul.t-online.com) (194.25.134.82) by mta1 with SMTP; 27 May 2000 11:42:22 -0000 Received: from fwd02.sul.t-online.de by mailout05.sul.t-online.com with smtp id 12veyx-0001Vc-03; Sat, 27 May 2000 13:42:19 +0200 Received: from (0893089296-0001@[193.158.169.255]) by fwd02.sul.t-online.de with smtp id 12veyw-0lj5I8C; Sat, 27 May 2000 13:42:18 +0200 To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> <392E610A.959B5D47@mime.up8.edu> X-Mailer: T-Online eMail 2.3 Message-ID: <12veyw-0lj5I8C@fwd02.sul.t-online.de> X-Sender: 0893089296-0001@t-dialin.net X-eGroups-From: Thilo.Reichelt@t-online.de (Reichelt) From: Thilo.Reichelt@t-online.de MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 May 2000 13:42:18 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (i) permute, SIMD... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 05b7446b26c8ac82c6dd2bb0775b780d Status: R X-Status: N YG schrieb:
> hi,
>
> this old thread is not dead. yet i have not found
> the definitive solution to this problem.
> i have a rough feeling about the high usefulness
> of the permute instruction (same as the popcount :
> look at the spooks) but going SIMD is difficult.
What's wrong with just repeating the same thing for upper half. quarters ...
That would be exactly what was needed for the applications Max Abramson
suggested in his original post. He thought of extracting the alpha channel
>from RGB values for example.

On a second thought, in this example, the extracted values end up far "left"
in the register. Permute would be a good way to get these values "down" to
the least significant byte. Which is impossible, because the bytes cannot cross
a 64-bit boundary with this approach.


Ok let's try a new idea:

The permute instruction is a 3r1w instruction.
The value whichs determines which byte will land where is from a register.
Let's call it the control value for now.
We divide the control value in 8 bytes. Each byte contains a value from 0 to
15 to indicate which byte will be permuted here. Bigger values trap.

When a F-CPU has 128 bit registers, legal values are 0 to 31 to specify 1 byte
out of 2 registers a 128 bit. For 256, values are 0 to 63.
This goes up to a width of 2048 bits, which needs values 0 to 255.

The permute operation has a size flag like other instructions. It's meaning does
depent on the SPR_SIZE registers. The values in the control register are shifted
accordingly if size is bigger than one byte.

So above 2048 register width can only be used wird bigger chunk sizes than
bytes.


Last idea: Let's introduce a new flag, which chooses whether the control values
are 'global' or refer only to the 'bank' they belong.
Hmm, I think this needs an example:
Let's assume the control value 0 means "put the LSB of the first register here".
On a 128-F-CPU permute with global flag set a control register wit all zeros
would copy the LSB of the first register in every byte.
If the global flag is not set, control values are 'local'. So the same operation
would copy the LSB of the first register in all bytes of the lower half of the
destination register and would copy byte 8 (the LSB of the upper half) in all
bytes of the upper half of the destination register. 
In a way this flag chooses between "just do the same thing like for the other
half" and the other aproach.





Thilo Reichelt
thilo.reichelt@t-online.de
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04173 for ; Sun, 28 May 2000 02:25:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 May 2000 02:25:16 +0200 (MEST) Received: (qmail 777 invoked by uid 0); 27 May 2000 21:34:32 -0000 Received: from hj.egroups.com (208.50.144.90) by mx15.rz2.gmx.net with SMTP; 27 May 2000 21:34:32 -0000 X-eGroups-Return: sentto-1101623-300-959463264-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 27 May 2000 21:34:26 -0000 Received: (qmail 12369 invoked from network); 27 May 2000 21:34:24 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 27 May 2000 21:34:24 -0000 Received: from unknown (HELO rly-ip01.mx.aol.com) (205.188.156.49) by mta3 with SMTP; 27 May 2000 21:34:23 -0000 Received: from cm-ta4.proxy.aol.com (cm-ta4.proxy.aol.com [152.163.205.44]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id RAA25818; Sat, 27 May 2000 17:34:15 -0400 (EDT) Received: from mail.stealthost.com (AC9C9B53.ipt.aol.com [172.156.155.83]) by cm-ta4.proxy.aol.com (8.10.0/8.10.0) with SMTP id e4RLWVG29044; Sat, 27 May 2000 17:32:32 -0400 (EDT) Message-ID: X-Apparently-From: ASCOTT353@aol.com From: "GRETEL525@aol.com" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 May 2000 17:26:17 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] The Interrnet Revolution Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 4e659f5d43dd92ec99c9451d8cb369b7 Status: R X-Status: N Get your message to millions of people for less than a penny per person!

Do you have a product, service, or idea you would like to sell on the
Internet but do not have $$$ thousands of dollars to spend on expensive
banner ads and TV spots?  A single ad on AOL can cost as much as $25,000!!

Are you frustrated that you cannot get your message out to enough people to
generate interest in your product or service? There are millions of web sites
and companies attempting to do business on the Internet, most, unsuccessfully.

It is not as easy as just "build it and they will come". Until now....

*Gain an advantage over the competition through DIRECT EMAIL
MARKETING.

*Reach millions of potential customers quickly, easily, affordably and LEGALLY.

*General US consumer Internet mailings start at just $250 for 300,000, $349 for
500,000 or $499 for 1 million! Geographically targeted mailings are available for
$199 per 100,000 and targeted by occupation is $299 for up to 5,000. General
business addresses are also now available starting at $350 for 300,000.

The Direct Mail Center can assist you in almost every aspect of your
Direct Email Offering transmitting the message, handling remove request
and can even assist with web site ideas compatible with commercial email .

Need to market or promote a web site? We can assist you with a custom
designed newsletter or e-zine pbulished weekly!

**********This is what some of our customers have to say:**************

"I doubled hits on my web site within 6 days after sending email!"  - D. Wallingford 2/00

"They sent out 1 million emails and the phones started ringing the next day." - ICW 6/99

"I knew I had a great product, I just didn't have a way to promote it
effectively until now. You made me a believer." - D. Levinson 7/99

"I used direct email to generate hundreds of leads for my sales people!" - K. Alias 12/99

"If you have a product that people want to buy there is no easier or
less expensive way to generate money." - S. Kleven 4/00

The Direct Mail Center has assisted many customers with there
direct marketing needs. Please contact us to discuss your
individual needs. Call before 6/4/00 and receive our free
guide to effective email marketing!

For more information email contact us at: mailto:Corporateinfo@aol.com?subject=info.




............................................................................
62691
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04624 for ; Sun, 28 May 2000 03:43:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 May 2000 03:43:01 +0200 (MEST) Received: (qmail 2250 invoked by uid 0); 28 May 2000 01:16:47 -0000 Received: from fk.egroups.com (208.50.144.73) by mx17.rz2.gmx.net with SMTP; 28 May 2000 01:16:47 -0000 X-eGroups-Return: sentto-1101623-301-959476592-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 28 May 2000 01:16:35 -0000 Received: (qmail 8785 invoked from network); 28 May 2000 01:16:30 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 28 May 2000 01:16:30 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 28 May 2000 01:16:30 -0000 Received: from f-cpu.org (Aubervilliers-2-199.club-internet.fr [195.36.150.199]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA00683 for ; Sun, 28 May 2000 03:16:23 +0200 (MET DST) Message-ID: <3930731C.78802FE@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> <392E610A.959B5D47@mime.up8.edu> <12veyw-0lj5I8C@fwd02.sul.t-online.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 May 2000 03:15:09 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (i) permute, SIMD... (II) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 99ff1dbf0bf4b0a6bf9ee30e34a001a4 Status: R X-Status: N hi !

i'm happy to see some brainstorming on this list :-)
at last, something constructive !

as for the scatter/gather problem (similar to
a parallel load/store unit) i found an interesting article
on comp.arch written by Andy Glew :
Subject: Vector / Matrix Instruction Set Evolution
Date: Fri, 5 Mar 1999 18:43:54 -0600
(10KB of interesting overviews about the use of
longer vectors and complex matrix operations).

Thilo.Reichelt@t-online.de wrote:
> YG schrieb:
> > hi,
> >
> > this old thread is not dead. yet i have not found
> > the definitive solution to this problem.
> > i have a rough feeling about the high usefulness
> > of the permute instruction (same as the popcount :
> > look at the spooks) but going SIMD is difficult.
> What's wrong with just repeating the same thing for upper half. quarters ...
> That would be exactly what was needed for the applications Max Abramson
> suggested in his original post. He thought of extracting the alpha channel
> from RGB values for example.
believe me, there is more use of this than that.
if the terms of S-table or P-permutations are unknown to you,
maybe the terms DES, Blowfish, Khafre or IDEA will ring a bell.
i'm not a cryptofreak but i know that some apparently
"simple features" can make a big difference. i want to make something
general enough so it can benefit to everybody, not only
game and cryptors programmers, but also any possible use of a computer
(communication->DSP, scientific, computer security...)

People seem to stick to 64-bit blocks, but i think that it will explode
soon. currently the practical straight-forward limit is 256 bits in the F-CPU
because that's the size of the number a loadimm-only code can create.
larger immediate numbers are possible with shifts.

but yet, F-CPU is not bound to a certain size.

You/others seem to be happy with channel splitting with 64-bit chunks.
but it would run faster with larger chunks, no ? the larger, the better,
the happier. but F-CPU is a general purpose CPU by essence, and therefore
should not restrict the use/scope of a particular instruction.

> On a second thought, in this example, the extracted values end up far "left"
> in the register. Permute would be a good way to get these values "down" to
> the least significant byte. Which is impossible, because the bytes cannot cross
> a 64-bit boundary with this approach.
that's a problem. well, it could be turned around, but it would then be hackish.


> Ok let's try a new idea:
> The permute instruction is a 3r1w instruction.
> The value whichs determines which byte will land where is from a register.
> Let's call it the control value for now.
> We divide the control value in 8 bytes. Each byte contains a value from 0 to
> 15 to indicate which byte will be permuted here. Bigger values trap.
>
> When a F-CPU has 128 bit registers, legal values are 0 to 31 to specify 1 byte
> out of 2 registers a 128 bit. For 256, values are 0 to 63.
> This goes up to a width of 2048 bits, which needs values 0 to 255.
>
> The permute operation has a size flag like other instructions. It's meaning does
> depent on the SPR_SIZE registers. The values in the control register are shifted
> accordingly if size is bigger than one byte.
>
> So above 2048 register width can only be used wird bigger chunk sizes than
> bytes.

i see the source register, the control register and the destination, but what is
the third operand ? (sorry i seem to miss some points).

i'm not sure to understand everything as well. at least i tried ;-)

> Last idea: Let's introduce a new flag, which chooses whether the control values
> are 'global' or refer only to the 'bank' they belong.
> Hmm, I think this needs an example:
> Let's assume the control value 0 means "put the LSB of the first register here".
> On a 128-F-CPU permute with global flag set a control register wit all zeros
> would copy the LSB of the first register in every byte.
> If the global flag is not set, control values are 'local'. So the same operation
> would copy the LSB of the first register in all bytes of the lower half of the
> destination register and would copy byte 8 (the LSB of the upper half) in all
> bytes of the upper half of the destination register.
> In a way this flag chooses between "just do the same thing like for the other
> half" and the other aproach.

i'm still not sure to understand everything, even though i have a little taste
of it. like often (and it's not a reproach, but an attempt to widen the
design perspective) you and others take a specific instruction and try
to tweak it in order to adapt it to other cases.

OTOH i try to take the most general, common and generic point of view, and see how
it translates in the real world, and fits with the design goals.

let's see.

What do we want to do ? "shuffle" bits. the byte case is only a sub-case of the
bit general case. almost EVERYTHING translates to the "shuffle" case :
word alignment, channel split/merge, rotation/shift, bit stream manipulation
(used in compression soft for LZW or Huffman codes, MP3 and JPEG, etc)...

if we have N bits in a word, we need N words of log2(N) bits to indicate the
destination of each bit.

let's see what instructions are available :
6.2 Bit Shuffling based operations
  6.2.1 Core Shift and Rotate operations
    6.2.1.1 shiftl, sshiftl
    6.2.1.2 shiftr, sshiftr
    6.2.1.3 shiftra, sshiftra
    6.2.1.4 rotl, srotl
    6.2.1.5 rotr, srotr
  6.2.2 Optional Bit Shift and Rotate operations
    6.2.2.1 shiftli, sshiftli
    6.2.2.2 shiftri, sshiftri
    6.2.2.3 shiftrai, sshiftrai
    6.2.2.4 rotli, srotli
    6.2.2.5 rotri, srotri
    6.2.2.6 bitop, sbitop, bchg, bset, bclr, btst, sbchg, sbset, sbclr, sbtst
    6.2.2.7 bitopi, sbitop, bchgi, bseti , bclri, btsti, sbchgi, sbseti, sbclri, sbtsti
  6.2.3 Optional Bit Shuffling operations
    6.2.3.1 bitrev, bitrevo
    6.2.3.2 bitrevi, bitrevio
    6.2.3.3 byterev, sbyterev
    6.2.3.4 mix (mixl, mixh)
    6.2.3.5 expand, (expandl, expandh)
    6.2.3.6 sdup
(missing : sdupi, fdep(i))

all those bit and byte manipulations are special cases, and complex manipulations
are "composite" of these instructions, this means that we have to recognize when
each is best used (we know that compilers are not good at pattern recognition).

In the F-CPU philosphy, N should not be bound. N is at least 32 and a power of two,
it can be determined at runtime. therefore log2(N) should be carefully "chosen"
(as if there was a choice...). We could discuss a lot about the real size, so
i prefer to avoid the problem : use registers instead of immediate (since a register
can have an infinite width, it can represent an infinite width too). We can keep an
immediate value (8-bit and reg values are two valid forms of operands for shift/rotate)
to keep things easy, yet we can use the register form if 256 bits are not enough.

Now, we still have N bits to shuffle : we have seen that we "can" "substitute"
any number with a 6-bit number representing a register containing the real value.
but this number of numbers is limited by the number of registers, and (worse)
the number of registers we can read in an instruction. we can only update/shuffle one
or two bits per cycle/instruction. lookup table ? nahhh....

Anyway, before we go weird doing crazy N^2 computations, let's see how we can do
one single bit. we'll try to improve it later.

let's begin with a simple trick ! it's always good to know it. if YOU
recognize that the bit moving is in fact a bit swapping, it can be done with a XOR :-)
i don't remember the exact algorithm, and there are maybe several ways of doing it,
but the trick is how you make the mask.

N iterations of the above swap can shuffle all the bits of a word in a completely
random fashion. that's not marvelous but we droped from O(n^2) to O(n) hardwarewise.
the other way, in O(log(2)) is using a Programable Logic Array, which is much more
costly, not scalable and not practical at all, we'd spend more time configuring it
than using it. it's a problem worse than coprossessors (remember the 8087 ? heck...).

if you want to shuffle say N bits, duplicate and mask. it's a composite method.
the advantage is that it will run faster when there are more instructions executed
each cycle, and not require any special register or complex unit.
the duplicate instruction will depend on the type of shuffle you want to do.
in the extreme case, there are ways to do some really powerful things with mul/and/rem.
(like bitcount and bit reversing) but that's very expensive (clockcountwise)
and only affects the 5 or 6 LSB.
For the rem (modulo), i have found the "combine" instruction. man/i7/part3.html#ROP2
for the mul, what it does is duplicating the initial pattern. sdup does the trick.
this is valid for 8-bit and maybe 16-bit chuncks at a time.

It becomes clear that the number of instructions depends on the complixity of the
shuffling operation. i think that one way of simplifying the complexity of
the problem is to work at two different levels : byte level, and register level.
the permute instruction as it exists now does not fit in the design constraints
of the F-CPU. word alignment is easily performed with "field deposit" and "field
extraction" instructions as in the SHARC. it's 3R1W and i think it could become
3R2W for boosting bit stream read/writes.

insertion : source is ANDed with a mask of X bits (LSB), then shifted left Y bits,
then ORed with Z.
extraction : source is shifted right, ANDed with mask.

now what sucks is when the stream overlaps two words.



Ouch, i think i lost myself here. i wanted to show that the problem is not
so simple, that's why "permute" is not blindly used in the f-cpu.
it is potentially very powerful but can't be used as is.

sorry for the long rant.

> Thilo Reichelt
> thilo.reichelt@t-online.de
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00310 for ; Mon, 29 May 2000 14:50:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 May 2000 14:50:24 +0200 (MEST) Received: (qmail 23573 invoked by uid 0); 29 May 2000 06:21:38 -0000 Received: from fg.egroups.com (208.50.144.70) by mx18.rz2.gmx.net with SMTP; 29 May 2000 06:21:38 -0000 X-eGroups-Return: sentto-1101623-302-959581292-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 29 May 2000 06:21:36 -0000 Received: (qmail 14040 invoked from network); 29 May 2000 06:21:31 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 29 May 2000 06:21:31 -0000 Received: from unknown (HELO mailout02.sul.t-online.com) (194.25.134.17) by mta3 with SMTP; 29 May 2000 06:21:31 -0000 Received: from fwd02.sul.t-online.de by mailout02.sul.t-online.com with smtp id 12wIva-00083z-02; Mon, 29 May 2000 08:21:30 +0200 Received: from (0893089296-0001@[193.158.171.56]) by fwd02.sul.t-online.de with smtp id 12wIvM-177KAiC; Mon, 29 May 2000 08:21:16 +0200 To: f-cpu@egroups.com References: <3.0.6.32.20000318061703.008fd1e0@mail.mindspring.com> <3.0.6.32.20000318090955.00901b90@mail.mindspring.com> <392E610A.959B5D47@mime.up8.edu> <12veyw-0lj5I8C@fwd02.sul.t-online.de> <3930731C.78802FE@f-cpu.org> X-Mailer: T-Online eMail 2.3 Message-ID: <12wIvM-177KAiC@fwd02.sul.t-online.de> X-Sender: 0893089296-0001@t-dialin.net X-eGroups-From: Thilo.Reichelt@t-online.de (Reichelt) From: Thilo.Reichelt@t-online.de MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 2000 08:21:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (i) permute, SIMD... (II) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 65ba2bd2e1166589a691e2f90bfbb914 Status: R X-Status: N Yann Guidon schrieb:
> Thilo.Reichelt@t-online.de wrote:
> > YG schrieb:
> > > hi,

> > What's wrong with just repeating the same thing for upper half. quarters ...
> > That would be exactly what was needed for the applications Max Abramson
> > suggested in his original post. He thought of extracting the alpha channel
> > from RGB values for example.
> believe me, there is more use of this than that.
I believe. :-)
It was just an example. If that were the only application, it would not be
justified.

> People seem to stick to 64-bit blocks, but i think that it will explode
> soon. currently the practical straight-forward limit is 256 bits in the F-CPU
> because that's the size of the number a loadimm-only code can create.
> larger immediate numbers are possible with shifts.
>
> but yet, F-CPU is not bound to a certain size.
>
> You/others seem to be happy with channel splitting with 64-bit chunks.
> but it would run faster with larger chunks, no ? the larger, the better,
> the happier. but F-CPU is a general purpose CPU by essence, and therefore
> should not restrict the use/scope of a particular instruction.
See the second attempt below

> > Ok let's try a new idea:
> > The permute instruction is a 3r1w instruction.
> > The value whichs determines which byte will land where is from a register.
> > Let's call it the control value for now.
> > We divide the control value in 8 bytes. Each byte contains a value from 0 to
> > 15 to indicate which byte will be permuted here. Bigger values trap.
To put it differently:
Since we have 64-bit register, we can use 8 bits to select the byte which is
going to each destination byte. This works up to a register size of 1024 bit
(128 byte), since there are two source registers.


> >
> > When a F-CPU has 128 bit registers, legal values are 0 to 31 to specify 1
>  byte
> > out of 2 registers a 128 bit. For 256, values are 0 to 63.
> > This goes up to a width of 2048 bits, which needs values 0 to 255.
1024 bits really, as there are 2 source registers

> > The permute operation has a size flag like other instructions. It's meaning
>  does
> > depent on the SPR_SIZE registers. The values in the control register are
>  shifted
> > accordingly if size is bigger than one byte.
permute would work on 16bit-values, 32-bit ... as chosen by the size flag.
If you choose 16bit-values, you can address every 16bit-value of two registers
width width 2048 bit.
>
> i see the source register, the control register and the destination, but what
>  is
> the third operand ? (sorry i seem to miss some points).

permute uses TWO source registers. It can pick any byte in one of the two
source registers and place it in any byte in the destination register.
Since the ISA does only allow to specify 3 registers, permute must destroy
one of its source operands.

> i'm not sure to understand everything as well. at least i tried ;-)
I was in a hurry. As I'm now :-(


Thilo Reichelt
thilo.reichelt@t-online.de
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00337 for ; Mon, 29 May 2000 14:50:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 May 2000 14:50:32 +0200 (MEST) Received: (qmail 16409 invoked by uid 0); 29 May 2000 10:53:01 -0000 Received: from jk.egroups.com (208.50.144.83) by mx16.rz2.gmx.net with SMTP; 29 May 2000 10:53:01 -0000 X-eGroups-Return: sentto-1101623-303-959597561-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 29 May 2000 10:52:42 -0000 Received: (qmail 12314 invoked from network); 29 May 2000 10:52:40 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 29 May 2000 10:52:40 -0000 Received: from unknown (HELO wn1.sci.kun.nl) (131.174.8.1) by mta2 with SMTP; 29 May 2000 10:52:39 -0000 Received: from studs3.sci.kun.nl by wn1.sci.kun.nl via studs3.sci.kun.nl [131.174.124.4] with ESMTP for id MAA23763 (8.8.8/3.29); Mon, 29 May 2000 12:52:38 +0200 (MET DST) To: f-cpu@egroups.com In-Reply-To: <392E9248.C20D37DD@hl.siemens.de> Message-ID: From: Arthur van Leeuwen MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 2000 12:52:38 +0200 (MET DST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] URL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6b01e9dcbce1de1dd203b09752f5e99b Status: R X-Status: N On Fri, 26 May 2000, Nicolas Boulay wrote:

> Especially, this one is interressant about the TTA.
> http://cardit.et.tudelft.nl/MOVE/index.html

Uhuh. It has most of the information on the MOVE architecture. Was really
useful for my master's thesis (which I have yet to finish).

> Maybe, the person who propose the TTA architecture worked for this
> project.

Actually, no. :)

Doei, Arthur.

--
  /\    /  |             Fight Scientology, See URL: http://xenu.xtdnet.nl/ |
/__\  /   | Buttons. Lotsa buttons. I like buttons. [Big Dog]              |
/    \/__  | A friend is someone with whom you can dare to Be yourself.     |
Just Be   +-Arthur van Leeuwen, arthurvl@sci.kun.nl------------------------+
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01059 for ; Mon, 29 May 2000 21:12:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 May 2000 21:12:42 +0200 (MEST) Received: (qmail 7077 invoked by uid 0); 29 May 2000 14:00:24 -0000 Received: from fl.egroups.com (208.50.144.74) by mx18.rz2.gmx.net with SMTP; 29 May 2000 14:00:24 -0000 X-eGroups-Return: sentto-1101623-304-959608801-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 29 May 2000 14:00:07 -0000 Received: (qmail 31305 invoked from network); 29 May 2000 13:59:13 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 29 May 2000 13:59:13 -0000 Received: from unknown (HELO unimidia.com.br) (200.250.41.2) by mta2 with SMTP; 29 May 2000 13:59:10 -0000 Received: from 210.174.77.203 [38.27.42.203] by unimidia.com.br (SMTPD32-5.05) id A69D40A0110; Mon, 29 May 2000 10:54:37 -0300 Message-ID: <00000da72ae9$00003e69$00001c80@151.189.38.22> To: X-Priority: 3 X-MSMail-Priority: Normal Errors-To: larryt358@spire.com X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-eGroups-From: acdtools@lampiviklo.cs.tut.fi From: cashcow@daum.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 2000 06:50:22 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Here is our $420 offer 7296 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ace07aa95cd49cbd8d1dc8bbdfb376e2 Status: R X-Status: N Fill your Bank account with our $420.00 Offer

Imagine if you had owned a piece of the computer industry
back in the '80's or the Wireless Communications Industry today.
A unique investment opportunity has opened due to recent
government deregulations in new technology.
Learn the secrets of the world's richest investors.
Called the World's Most Perfect business
High Yield, Internet friendly, no selling, no mlm
Consistent Trending Market Find out how dimes are turned into
dollars.  Click below for your FREE bonus.

http://204.1.122.206/056ks98r717d/897456t2sd/







To be removed:

mailto:sales@ucansavenow.com?subject=removeoilpromo


















Fill your Bank account with our $420.00 Offer

Imagine if you had owned a piece of the computer industry
back in the '80's or the Wireless Communications Industry today.
A unique investment opportunity has opened due to recent
government deregulations in new technology.
Learn the secrets of the world's richest investors.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01092 for ; Mon, 29 May 2000 21:12:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 May 2000 21:12:51 +0200 (MEST) Received: (qmail 27744 invoked by uid 0); 29 May 2000 18:08:01 -0000 Received: from mw.egroups.com (207.138.41.167) by mx14.rz2.gmx.net with SMTP; 29 May 2000 18:08:01 -0000 X-eGroups-Return: sentto-1101623-305-959623656-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 29 May 2000 18:07:40 -0000 Received: (qmail 5719 invoked from network); 29 May 2000 18:07:36 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 29 May 2000 18:07:36 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 29 May 2000 18:07:35 -0000 Received: from aqua.bocal.cs.univ-paris8.fr (aqua.bocal.cs.univ-paris8.fr [192.168.3.3]) by inferno.cs.univ-paris8.fr (8.10.1/8.10.1) with ESMTP id e4TI71i02142; Mon, 29 May 2000 20:07:02 +0200 (CEST) Received: (from mota@localhost) by aqua.bocal.cs.univ-paris8.fr (8.8.8+Sun/8.8.8) id UAA06089; Mon, 29 May 2000 20:07:03 +0200 (MET DST) To: f-cpu@egroups.com Cc: sven@devcon.net Message-ID: <20000529200703.A3998@aqua.bocal.cs.univ-paris8.fr> References: <392F0FCD.58DD1E5A@f-cpu.org> X-Mailer: Mutt 1.0pre3us In-Reply-To: <392F0FCD.58DD1E5A@f-cpu.org> From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 2000 20:07:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] new mirror Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 107cbeb8b28ec5994668bf09645dce2b Status: R X-Status: N On Sat, May 27, 2000 at 01:59:09AM +0200, Yann Guidon wrote:
> hi,
>
> with Paul Mota we're setting up a new server account.
>

Yes, Sir ;)

> i hope that it will become one day fr.f-cpu.org,

Actually, www.fr.f_cpu.org & ftp.fr.f_cpu.org

> if Sven had a few minutes to manage this...
>

Sven, could you insert a line in the dns which delegates
fr.f-cpu.org to the nameserver ns.mime.univ-paris8.fr ?

Thank you,
--
      Paul
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01101 for ; Mon, 29 May 2000 21:12:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 May 2000 21:12:53 +0200 (MEST) Received: (qmail 29306 invoked by uid 0); 29 May 2000 19:06:50 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 29 May 2000 19:06:50 -0000 X-eGroups-Return: sentto-1101623-306-959627167-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 29 May 2000 19:06:10 -0000 Received: (qmail 1057 invoked from network); 29 May 2000 19:06:01 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 May 2000 19:06:01 -0000 Received: from unknown (HELO mrs-2.smartworld.net) (216.70.64.27) by mta3 with SMTP; 29 May 2000 19:06:00 -0000 Received: from smtp.freewwweb.com (1Cust175.tnt4.beaverton.or.da.uu.net [63.21.231.175]) by mrs-2.smartworld.net (8.9.1a/8.9.1) with SMTP id PAA92259; Mon, 29 May 2000 15:05:29 -0500 (CDT) Received: from mailhost.freebee.com (alt1.freebee.com(208.9.77.000)) by feebee.com (8.8.5/8.6.5) with SMTP id GAA02845 for ; Mon, 29 May 2000 12:01:56 -0600 (EST) To: Dear@mrs-2.smartworld.net, fellow@mrs-2.smartworld.net, safe@mrs-2.smartworld.net, list@mrs-2.smartworld.net, member@mrs-2.smartworld.net Message-ID: <199702170026.GAA08056@freebee.com> Comments: Authenticated sender is From: postalcenter25@netscape.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 00 12:01:56 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] Your email account status!! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 98745632123654789874563212365478 Status: R X-Status: N Hi, Thanks for joining "The Financial Freedom" international newsletter, and our safe opt-in members list.
Our monthly newsletter will come to you on the 1st of each month and includes the best money generating
programs around and our special feature "internet site of the month". Here is this months winner..............
(To unsubscribe from our newsletter, please see bottom of this ad)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

How to receive $400.00  by  tommorw morning by sending one simple fax !!


"Best Kept Secrets Of The Wealthy Revealed" !!


Discover how to generate huge amounts of cash in days and beome literally wealthy overnight......
.......... and we have a $10,000.00 Guarantee to back it up!!!


  You will discover:

  THE GOVERNMENT LOTTERY YOU CAN'T LOSE ! (Your money back if you don't win!)

  HOW TO MAKE $9000 A MONTH FROM ANY BANK YOU CAN FIND !

  HOW TO GET YOUR PART OF THE BILLIONS THE GOVERNMENT IS HOLDING !

  HOW TO EARN A $1000 OR MORE READING NEWSPAPERS !

  HOW TO GET $20,000 WORTH OF FURNITURE FREE !

  HOW TO OWN A BRAND NEW CAR EVERY YEAR ABSOLUTELY FREE !

  HOW TO TRAVEL ANYWHERE IN THE WORLD 2-WAY -FREE !

  HOW TO GET FREE ADVICE FROM "TOP LAWYERS" !

  HOW TO GET REGULAR MAIL POSTAGE FOR 1/2 THE NORMAL PRICE !

  HOW TO REMOVE UNFAVORABLE REMARKS FROM YOUR CREDIT FILE !

  THE SECRET LAW THAT ERASES ALL YOUR DEBT !


These are only a few of the many "insider secrets" that could make you wealthy overnight !

Click here now:http://3506561042/%69%6E%73%74%61%6E%74%63%61%73h%31%31/%73%65%63%72%65t%73%2E%68%74%6D

(If you experience problems finding this site, please write to: < Link2U92@netscape.net> and we will provide you with a link to our homepage)


P.S. Please don't let a moment go by that could keep you from the money and lifestyle you desire and deserve. ACT NOW!


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
***To be removed from our in house opt-in "safe list***

If you wish to be removed from any further offers you may do so by hitting reply to this email with  the word "Remove" in the subject field and you will not receive any further mailings from us,
nor will your name be given out for further use.
Thanks again, for visiting our site!!

Financial Freedom International
9138 Robinson
Overland Park, KS 66212
1-877-290-6930 Ext. 402
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01812 for ; Tue, 30 May 2000 02:04:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 May 2000 02:04:58 +0200 (MEST) Received: (qmail 32579 invoked by uid 0); 29 May 2000 21:08:53 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 29 May 2000 21:08:53 -0000 X-eGroups-Return: sentto-1101623-307-959634521-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 29 May 2000 21:08:41 -0000 Received: (qmail 18996 invoked from network); 29 May 2000 21:08:39 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 29 May 2000 21:08:39 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta2 with SMTP; 29 May 2000 21:08:39 -0000 Received: from 0018728164 (host-209-214-154-13.bix.bellsouth.net [209.214.154.13]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id RAA19007 for ; Mon, 29 May 2000 17:08:35 -0400 (EDT) Message-ID: <000c01bfc9b1$cfcee3a0$0d9ad6d1@0018728164> To: References: <199702170026.GAA08056@freebee.com> Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 May 2000 16:06:50 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BFC987.E5E325E0" X-UIDL: 43f80167adf0a5cbca1b9c4d81f005b7 Status: R X-Status: N ------=_NextPart_000_0009_01BFC987.E5E325E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: postalcenter25@netscape.net=20 To: Dear@mrs-2.smartworld.net ; fellow@mrs-2.smartworld.net ; = safe@mrs-2.smartworld.net ; list@mrs-2.smartworld.net ; = member@mrs-2.smartworld.net=20 Sent: Monday, May 29, 2000 12:01 PM Subject: [f-cpu] Your email account status!! Hi, Thanks for joining "The Financial Freedom" international = newsletter, and our safe opt-in members list. Our monthly newsletter will come to you on the 1st of each month and = includes the best money generating programs around and our special feature "internet site of the month". = Here is this months winner.............. (To unsubscribe from our newsletter, please see bottom of this ad) = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxx =20 How to receive $400.00 by tommorw morning by sending one simple fax = !! "Best Kept Secrets Of The Wealthy Revealed" !! Discover how to generate huge amounts of cash in days and beome = literally wealthy overnight...... .......... and we have a $10,000.00 Guarantee to back it up!!! You will discover: THE GOVERNMENT LOTTERY YOU CAN'T LOSE ! (Your money back if you = don't win!) HOW TO MAKE $9000 A MONTH FROM ANY BANK YOU CAN FIND ! HOW TO GET YOUR PART OF THE BILLIONS THE GOVERNMENT IS HOLDING ! HOW TO EARN A $1000 OR MORE READING NEWSPAPERS ! HOW TO GET $20,000 WORTH OF FURNITURE FREE ! HOW TO OWN A BRAND NEW CAR EVERY YEAR ABSOLUTELY FREE ! HOW TO TRAVEL ANYWHERE IN THE WORLD 2-WAY -FREE ! HOW TO GET FREE ADVICE FROM "TOP LAWYERS" ! HOW TO GET REGULAR MAIL POSTAGE FOR 1/2 THE NORMAL PRICE ! HOW TO REMOVE UNFAVORABLE REMARKS FROM YOUR CREDIT FILE ! THE SECRET LAW THAT ERASES ALL YOUR DEBT ! These are only a few of the many "insider secrets" that could make you = wealthy overnight !=20 Click here = now:http://3506561042/%69%6E%73%74%61%6E%74%63%61%73h%31%31/%73%65%63%72%= 65t%73%2E%68%74%6D (If you experience problems finding this site, please write to: < = Link2U92@netscape.net> and we will provide you with a link to our = homepage) P.S. Please don't let a moment go by that could keep you from the = money and lifestyle you desire and deserve. ACT NOW! = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ***To be removed from our in house opt-in "safe list*** If you wish to be removed from any further offers you may do so by = hitting reply to this email with the word "Remove" in the subject field = and you will not receive any further mailings from us, nor will your name be given out for further use. Thanks again, for visiting our site!! Financial Freedom International 9138 Robinson Overland Park, KS 66212 1-877-290-6930 Ext. 402 -------------------------------------------------------------------------= ----- -------------------------------------------------------------------------= ----- ------=_NextPart_000_0009_01BFC987.E5E325E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
 
----- Original Message -----
Sent: Monday, May 29, 2000 12:01 PM
Subject: [f-cpu] Your email account status!!

Hi, Thanks for joining "The Financial Freedom" international newsletter, and our safe opt-in members list.
Our monthly newsletter will come to you on the 1st of each month and includes the best money generating
programs around and our special feature "internet site of the month". Here is this months winner..............
(To unsubscribe from our newsletter, please see bottom of this ad)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

How to receive $400.00  by  tommorw morning by sending one simple fax !!


"Best Kept Secrets Of The Wealthy Revealed" !!


Discover how to generate huge amounts of cash in days and beome literally wealthy overnight......
.......... and we have a $10,000.00 Guarantee to back it up!!!


  You will discover:

  THE GOVERNMENT LOTTERY YOU CAN'T LOSE ! (Your money back if you don't win!)

  HOW TO MAKE $9000 A MONTH FROM ANY BANK YOU CAN FIND !

  HOW TO GET YOUR PART OF THE BILLIONS THE GOVERNMENT IS HOLDING !

  HOW TO EARN A $1000 OR MORE READING NEWSPAPERS !

  HOW TO GET $20,000 WORTH OF FURNITURE FREE !

  HOW TO OWN A BRAND NEW CAR EVERY YEAR ABSOLUTELY FREE !

  HOW TO TRAVEL ANYWHERE IN THE WORLD 2-WAY -FREE !

  HOW TO GET FREE ADVICE FROM "TOP LAWYERS" !

  HOW TO GET REGULAR MAIL POSTAGE FOR 1/2 THE NORMAL PRICE !

  HOW TO REMOVE UNFAVORABLE REMARKS FROM YOUR CREDIT FILE !

  THE SECRET LAW THAT ERASES ALL YOUR DEBT !


These are only a few of the many "insider secrets" that could make you wealthy overnight !

Click here now:http://3506561042/%69%6E%73%74%61%6E%74%63%61%73h%31%31/%73%65%63%72%65t%73%2E%68%74%6D

(If you experience problems finding this site, please write to: < Link2U92@netscape.net> and we will provide you with a link to our homepage)


P.S. Please don't let a moment go by that could keep you from the money and lifestyle you desire and deserve. ACT NOW!


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
***To be removed from our in house opt-in "safe list***

If you wish to be removed from any further offers you may do so by hitting reply to this email with  the word "Remove" in the subject field and you will not receive any further mailings from us,
nor will your name be given out for further use.
Thanks again, for visiting our site!!

Financial Freedom International
9138 Robinson
Overland Park, KS 66212
1-877-290-6930 Ext. 402
------=_NextPart_000_0009_01BFC987.E5E325E0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00434 for ; Fri, 2 Jun 2000 19:43:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Jun 2000 19:43:36 +0200 (MEST) Received: (qmail 5712 invoked by uid 0); 2 Jun 2000 13:25:08 -0000 Received: from hm.egroups.com (208.50.144.92) by mx15.rz2.gmx.net with SMTP; 2 Jun 2000 13:25:08 -0000 X-eGroups-Return: sentto-1101623-308-959952297-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 02 Jun 2000 13:25:01 -0000 Received: (qmail 6724 invoked from network); 2 Jun 2000 13:24:47 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 2 Jun 2000 13:24:47 -0000 Received: from unknown (HELO qg.egroups.com) (10.1.2.27) by mta1 with SMTP; 2 Jun 2000 13:24:46 -0000 Received: (qmail 29778 invoked from network); 2 Jun 2000 13:24:46 -0000 Received: from mq.egroups.com (10.1.1.36) by iqg.egroups.com with SMTP; 2 Jun 2000 13:24:46 -0000 X-eGroups-Return: sebot@lri.fr Received: from [10.1.10.68] by mq.egroups.com with NNFMP; 02 Jun 2000 13:24:46 -0000 To: f-cpu@egroups.com Message-ID: <8h8cir+957n@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster From: sebot@lri.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Jun 2000 13:24:43 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] How much power for a functional unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40d46b01b2dec94b5c16671dd7de9011 Status: R X-Status: N Hi,
I'd like to have some informations about the power a fonctional unit
(Int, FP) is consuming at 0.18 (copper or not) or 0.25. I know this
depend on the hardware implementation and the kind of instruction
executed. What I'd like to find is either the information per
instruction for a given CPU (recent) or per instruction kind (FP, Int
complex, Int simple ). I didn't find any informations on the web, the
only informations I got are'nt precise enough, I found them int a
paper that will be published in the next ISCA conference (Wattch).

I think you may have these informations because you are designing a
CPU.

I don't need very precise values, averages for a cpu /cycle(or inst)
would be very nice.

Thanks in advance
--
Sebot Julien - PhD in // computer Architecture
LRI - Paris South University - FRANCE
sebot@lri.fr
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01986 for ; Sun, 4 Jun 2000 03:06:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Jun 2000 03:06:05 +0200 (MEST) Received: (qmail 30204 invoked by uid 0); 3 Jun 2000 23:56:47 -0000 Received: from mv.egroups.com (208.50.144.81) by mx15.rz2.gmx.net with SMTP; 3 Jun 2000 23:56:47 -0000 X-eGroups-Return: sentto-1101623-309-960076605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 04 Jun 2000 00:56:45 -0000 Received: (qmail 5447 invoked from network); 3 Jun 2000 23:56:44 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Jun 2000 23:56:44 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (205.152.0.91) by mta1 with SMTP; 3 Jun 2000 23:56:44 -0000 Received: from 0018728164 (host-209-215-11-197.bix.bellsouth.net [209.215.11.197]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id TAA25526; Sat, 3 Jun 2000 19:56:42 -0400 (EDT) Message-ID: <000801bfcdb7$23bc1060$c50bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Jun 2000 18:55:03 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] M2M Architecture Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFCD8D.39D1D940" X-UIDL: 4de8148c671da085040717e9f78ccafc Status: R X-Status: N ------=_NextPart_000_0005_01BFCD8D.39D1D940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To the Gentleman from Australia who showed an interest in this type = of design - I have lost your e-mail address in the process of getting reorganized = here. Had to get a new PC in preparation for the Eclipse software. = PLEASE send me another inquiry. Sincerely Richard E. Hartney ------=_NextPart_000_0005_01BFCD8D.39D1D940 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    To the Gentleman from Australia who showed an interest in this type of design -
I have lost your e-mail address in the process of getting reorganized here.  Had to get a new PC in preparation for the Eclipse software. PLEASE send me another inquiry.
 
Sincerely
Richard E. Hartney
------=_NextPart_000_0005_01BFCD8D.39D1D940-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01989 for ; Sun, 4 Jun 2000 03:06:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Jun 2000 03:06:06 +0200 (MEST) Received: (qmail 20775 invoked by uid 0); 4 Jun 2000 00:19:52 -0000 Received: from mw.egroups.com (207.138.41.167) by mx18.rz2.gmx.net with SMTP; 4 Jun 2000 00:19:52 -0000 X-eGroups-Return: sentto-1101623-310-960077986-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 04 Jun 2000 00:19:47 -0000 Received: (qmail 31491 invoked from network); 4 Jun 2000 00:19:45 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 4 Jun 2000 00:19:45 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta3 with SMTP; 4 Jun 2000 00:19:45 -0000 Received: from 0018728164 (host-209-215-11-197.bix.bellsouth.net [209.215.11.197]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id UAA21468; Sat, 3 Jun 2000 20:19:43 -0400 (EDT) Message-ID: <001901bfcdba$5afffc00$c50bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Jun 2000 19:18:04 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN64 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01BFCD90.710C9D20" X-UIDL: e25d0c523da0eb9e0d877b6478111796 Status: R X-Status: N ------=_NextPart_000_0016_01BFCD90.710C9D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good news and bad news. Completed re-design of all functional = components this morning. I have NO Structural, Data, or Control Hazards = of any kind. The maxiumum potential thru-put is 0.9375 GHZ. As I = completed each component; I ran them thru Place & Route to obtain = general performance and CELL counts. Approximatly 4000 FF's are required and 4500 Cells. THAT IS THE BAD = NEWS. FF's - no problem. Logic cells exceed the number for the maximum = density of the projected ECLIPSE series of FPGA's. The 64-bit structure cannot be = achieved unless ASIC is used at the outset. Very - very undesirable. My only = alternative is to fall back to my original 32-bit stuff - prove the = design; then go ASIC at a later date. So - now I archive ERIN64 to Iomega backup and proceed to 32-Bit. = Should take approx 1 - 2 weeks. Sincerely Richard E. Hartney ------=_NextPart_000_0016_01BFCD90.710C9D20 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    Good news and bad news.  Completed re-design of all functional components this morning.  I have NO Structural, Data, or Control Hazards of any kind.  The maxiumum potential thru-put is 0.9375 GHZ.  As I completed each component; I ran them thru Place & Route to obtain general performance and CELL counts.
Approximatly 4000 FF's are required and 4500 Cells.  THAT IS THE BAD NEWS.
FF's - no problem.  Logic cells exceed the number for the maximum density of the
projected ECLIPSE series of FPGA's.  The 64-bit structure cannot be achieved
unless ASIC is used at the outset.  Very - very undesirable.  My only alternative is to fall back to my original 32-bit stuff - prove the design; then go ASIC at a later date.
    So - now I archive ERIN64 to Iomega backup and proceed to 32-Bit.  Should take approx 1 - 2 weeks.
 
Sincerely
Richard E. Hartney
 
------=_NextPart_000_0016_01BFCD90.710C9D20-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00899 for ; Sun, 4 Jun 2000 22:51:56 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Jun 2000 22:51:56 +0200 (MEST) Received: (qmail 24546 invoked by uid 0); 4 Jun 2000 19:55:18 -0000 Received: from mv.egroups.com (208.50.144.81) by mx15.rz2.gmx.net with SMTP; 4 Jun 2000 19:55:18 -0000 X-eGroups-Return: sentto-1101623-311-960148514-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mv.egroups.com with NNFMP; 04 Jun 2000 20:55:16 -0000 Received: (qmail 22783 invoked from network); 4 Jun 2000 19:55:13 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 4 Jun 2000 19:55:13 -0000 Received: from unknown (HELO devcon.net) (212.15.193.130) by mta2 with SMTP; 4 Jun 2000 19:55:13 -0000 Received: (qmail 11844 invoked by uid 513); 4 Jun 2000 19:55:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jun 2000 19:55:10 -0000 X-Sender: sven@lilly.devconsult.de To: f-cpu@egroups.com In-Reply-To: <20000529200703.A3998@aqua.bocal.cs.univ-paris8.fr> Message-ID: From: void MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Jun 2000 21:55:10 +0200 (CEST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] new mirror Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 722e1f58636b655b64d4c86ec0fa1cf7 Status: R X-Status: N
    Hi *,

On Mon, 29 May 2000, Paul Marques Mota wrote:

> Sven, could you insert a line in the dns which delegates
> fr.f-cpu.org to the nameserver ns.mime.univ-paris8.fr ?

    I'd love to but ns.mime.univ-paris8.fr doesn't exist. :(

    Best regards,
    Sven
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00905 for ; Sun, 4 Jun 2000 22:51:57 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Jun 2000 22:51:57 +0200 (MEST) Received: (qmail 32346 invoked by uid 0); 4 Jun 2000 20:05:46 -0000 Received: from mk.egroups.com (207.138.41.165) by mx16.rz2.gmx.net with SMTP; 4 Jun 2000 20:05:46 -0000 X-eGroups-Return: sentto-1101623-312-960148782-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 04 Jun 2000 19:59:45 -0000 Received: (qmail 27788 invoked from network); 4 Jun 2000 19:59:39 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 4 Jun 2000 19:59:39 -0000 Received: from unknown (HELO devcon.net) (212.15.193.130) by mta1 with SMTP; 4 Jun 2000 19:59:38 -0000 Received: (qmail 12145 invoked by uid 513); 4 Jun 2000 19:59:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jun 2000 19:59:34 -0000 X-Sender: sven@lilly.devconsult.de To: f-cpu@egroups.com In-Reply-To: Message-ID: From: void MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Jun 2000 21:59:34 +0200 (CEST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] new mirror Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bb270708d912fd57f28001a1c7f482ac Status: R X-Status: N
    Hi,

On Sun, 4 Jun 2000, void wrote:

>     I'd love to but ns.mime.univ-paris8.fr doesn't exist. :(
    Ok, checked it on another system than the nameserver.

    Best,
    sven
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04156 for ; Mon, 5 Jun 2000 12:55:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:17 +0200 (MEST) Received: (qmail 11992 invoked by uid 0); 5 Jun 2000 03:13:10 -0000 Received: from ch.egroups.com (207.138.41.144) by mx16.rz2.gmx.net with SMTP; 5 Jun 2000 03:13:10 -0000 X-eGroups-Return: sentto-1101623-313-960174786-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 05 Jun 2000 03:13:08 -0000 Received: (qmail 10878 invoked from network); 5 Jun 2000 03:11:54 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Jun 2000 03:11:54 -0000 Received: from unknown (HELO mail2.primary.net) (216.87.38.218) by mta1 with SMTP; 5 Jun 2000 03:11:53 -0000 Received: from [192.168.1.40] (ip8-htc1.busprod.com [207.150.74.8]) by mail2.primary.net (8.10.0+jb/8.10.0) with ESMTP id e5538Fp05711 for ; Sun, 4 Jun 2000 22:08:16 -0500 X-Sender: cary@www.rdrop.com Message-Id: To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Jun 2000 21:47:50 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] rapid IO Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e5817249374201a4e6309cd712869b4 Status: R X-Status: N
Dear f-cpu developers,

It looks like "open standard" is the new buzzword.

Advanced Microcontroller Bus Architecture (AMBA)
The open standard on-chip bus specification
http://www.arm.com/Pro+Peripherals/AMBA/
http://www.arm.com/Documentation/UserMans/AMBA/

RapidIO(tm) Interconnect Architecture Standard
http://www.mot-sps.com/news_center/press_releases/PR000229A.html
"The new interconnect architecture addresses the networking industry's need for
higher reliability, greater bandwidth and faster bus speeds in an intra-system
interconnect that allows chip-to-chip and board-to-board communications at
performance levels scaling to ten gigabits per second and beyond. "

http://www.rapidio.org/
"This breakthrough interconnect architecture is being offered as an open
standard through membership to the RapidIO Trade Association. "

ESG89001 Electro magnetic compatibility and
printed circuit board (PCB) constraints
http://www.semiconductors.com/acrobat/applicationnotes/u89001.pdf

--
David Cary "mailto:d.cary@ieee.org" "icbmto:N36 08.830' W97 03.443'"
  http://www.rdrop.com/~cary/
Future Tech, Unknowns, machine vision ><> <*> O-
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04159 for ; Mon, 5 Jun 2000 12:55:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:17 +0200 (MEST) Received: (qmail 9846 invoked by uid 0); 5 Jun 2000 05:52:15 -0000 Received: from mu.egroups.com (207.138.41.151) by mx18.rz2.gmx.net with SMTP; 5 Jun 2000 05:52:15 -0000 X-eGroups-Return: sentto-1101623-314-960184332-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 05 Jun 2000 06:52:13 -0000 Received: (qmail 9087 invoked from network); 5 Jun 2000 05:52:10 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Jun 2000 05:52:10 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 5 Jun 2000 05:52:10 -0000 Received: from 0018728164 (host-209-214-154-187.bix.bellsouth.net [209.214.154.187]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id BAA01439; Mon, 5 Jun 2000 01:52:08 -0400 (EDT) Message-ID: <000901bfceb1$f45f9020$bb9ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Jun 2000 00:50:27 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] My Response to Mr. David Cary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BFCE88.0A6C3140" X-UIDL: e63a79c90aa98c691bec042f1ca4bf8b Status: R X-Status: N ------=_NextPart_000_0006_01BFCE88.0A6C3140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe I have stated before - My System Architecture totally = negates any requirement for using NETWORKING HARDWARE/SOFTWARE that is on the market = today. I can very nicely service more than 128 Terminals without NOVEL or other similar devices. The maximum number will be determined by the = performance of my DDP-516 Emulation - the ERIN64 or ERIN32 which is used = as a Language Processor and a companion Peripheral Processor. The = process is inherant in the Software I intend to capture - Hard Disk = Management. The number of Hard Drives is totally dependent on the = System Application. That is - Small Business, Large Business (IRS, DOD = Pentagon, All Military Medical, all Branches of the Federal Government), = Insurance, Inventory, Research, Food Chains, Any business you can = dream of......... Sincerely, Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0006_01BFCE88.0A6C3140 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    I believe I have stated before - My System Architecture totally negates any
requirement for using NETWORKING HARDWARE/SOFTWARE that is on the market today.  I can very nicely service more than 128 Terminals without NOVEL
or other similar devices.  The maximum number will be determined by the performance of my DDP-516 Emulation - the ERIN64 or ERIN32 which is used as a Language Processor and a companion Peripheral Processor.  The process is inherant in the Software I intend to capture - Hard Disk Management.  The number of Hard Drives is totally dependent on the System Application.  That is - Small Business, Large Business (IRS, DOD Pentagon, All Military Medical, all Branches of the Federal Government),  Insurance,  Inventory,  Research, Food Chains,  Any business you can dream of.........
 
 
Sincerely,
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_0006_01BFCE88.0A6C3140-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04180 for ; Mon, 5 Jun 2000 12:55:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:23 +0200 (MEST) Received: (qmail 29518 invoked by uid 0); 5 Jun 2000 08:35:55 -0000 Received: from hj.egroups.com (208.50.144.90) by mx15.rz2.gmx.net with SMTP; 5 Jun 2000 08:35:55 -0000 X-eGroups-Return: sentto-1101623-315-960194140-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 05 Jun 2000 08:35:42 -0000 Received: (qmail 2680 invoked from network); 5 Jun 2000 08:35:39 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Jun 2000 08:35:39 -0000 Received: from unknown (HELO maynard.mail.mindspring.net) (207.69.200.243) by mta1 with SMTP; 5 Jun 2000 08:35:39 -0000 Received: from sehnsucht (user-33qseqs.dialup.mindspring.com [199.174.59.92]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id EAA17132; Mon, 5 Jun 2000 04:35:36 -0400 (EDT) Message-Id: <3.0.6.32.20000605033532.00938810@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, Cc: In-Reply-To: <000901bfceb1$f45f9020$bb9ad6d1@0018728164> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Jun 2000 03:35:32 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My Response to Mr. David Cary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5529e30a059e9d8de054bc26b458680c Status: R X-Status: N but emulating a DDP system is not fully general purpse - for the things you
are designing for, this is a wonderful system/architecture. But, for example,
playing Quake 3, it is a tad lacking.

If I recall, I think the group charter/constitution/whatever we called it,
called for a general purpose CPU.

I think your work really is a great peice of functional art, but the FCPU
aim is to do pretty much everything pretty good (some things great, some
things bad - that's the nature of a general purpose CPU)

Also, I don't believe he was pointing out that we should use said bus so
much as remark on how 'open' anything is a buzzword now. Altho, I am
inclined to read up on that a bit later, it does sound rather interesting.

Even if you have a bazillion terminals off one CPU, the CPU must talk to
your terminals elsewhere - data must be transfered. An array of RS232
ports would work just fine, of course.

-JV

At 12:50 AM 6/5/00 -0500, Richard E.Hartney wrote:
>       I believe I have stated before -  My System Architecture totally
>negates any   I can very nicely service more than 128  Terminals without
>NOVEL           Any business you can dream of.........     Sincerely,
>Richard E. Hartney Research Director &  Associates
>    
> 

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04183 for ; Mon, 5 Jun 2000 12:55:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:23 +0200 (MEST) Received: (qmail 15641 invoked by uid 0); 5 Jun 2000 08:41:00 -0000 Received: from hm.egroups.com (208.50.144.92) by mx7.rz2.gmx.net with SMTP; 5 Jun 2000 08:41:00 -0000 X-eGroups-Return: sentto-1101623-316-960194457-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 05 Jun 2000 08:40:58 -0000 Received: (qmail 18953 invoked from network); 5 Jun 2000 08:40:56 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Jun 2000 08:40:56 -0000 Received: from unknown (HELO maynard.mail.mindspring.net) (207.69.200.243) by mta3 with SMTP; 5 Jun 2000 08:40:56 -0000 Received: from sehnsucht (user-33qseqs.dialup.mindspring.com [199.174.59.92]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id EAA12011; Mon, 5 Jun 2000 04:40:55 -0400 (EDT) Message-Id: <3.0.6.32.20000605034054.009c8100@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Jun 2000 03:40:54 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] rapid IO Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 516e600dab36ef7d1a41342e6568d4d1 Status: R X-Status: N Hrm, it seems somewhat like a bastard offspring of ATM and Rambus :)

8-bit ports at high freq and small packets of data.

Which got me to thinking: By making things simple and only transferring a
specific amount of data at a time (say a 64bit address and 64bit data - well,
as a packet, not all in one cycle necessarily), you might increase the data
transferred, but would the simpler architecture allow higher speeds?

And if so, at what point does the ATM/Rambus bastard offspring exceed the
performance of the traditional variable-length (burst) busses?

Food for thought...

-JV
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04186 for ; Mon, 5 Jun 2000 12:55:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:24 +0200 (MEST) Received: (qmail 6611 invoked by uid 0); 5 Jun 2000 08:43:54 -0000 Received: from hn.egroups.com (208.50.144.84) by mx03.rz2.gmx.net with SMTP; 5 Jun 2000 08:43:54 -0000 X-eGroups-Return: sentto-1101623-317-960194600-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 05 Jun 2000 08:43:23 -0000 Received: (qmail 19009 invoked from network); 5 Jun 2000 08:43:19 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 5 Jun 2000 08:43:19 -0000 Received: from unknown (HELO maynard.mail.mindspring.net) (207.69.200.243) by mta2 with SMTP; 5 Jun 2000 08:43:19 -0000 Received: from sehnsucht (user-33qseqs.dialup.mindspring.com [199.174.59.92]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id EAA19017; Mon, 5 Jun 2000 04:43:18 -0400 (EDT) Message-Id: <3.0.6.32.20000605034316.009b5340@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: <3.0.6.32.20000605034054.009c8100@mail.mindspring.com> References: From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Jun 2000 03:43:16 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] rapid IO Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 049931f444ed9c9e44b5a7182fb68a78 Status: R X-Status: N Also, one of the other features was a switching mechanism, with point to
point links.
Sort of like the (now abandoned) 8- and 16-way Athlon chipset designs from
HotRail.

This would reduce noise and increase speed on each segment, but also
increase pincount.
(hence, I'm sure, the 8-bit width)

Something else to consider..

-JV

At 03:40 AM 6/5/00 -0500, Jonathan Vaughn wrote:
>Hrm, it seems somewhat like a bastard offspring of ATM and Rambus :)
>
>8-bit ports at high freq and small packets of data.
>
>Which got me to thinking: By making things simple and only transferring a
>specific amount of data at a time (say a 64bit address and 64bit data - well,
>as a packet, not all in one cycle necessarily), you might increase the data
>transferred, but would the simpler architecture allow higher speeds?
>
>And if so, at what point does the ATM/Rambus bastard offspring exceed the
>performance of the traditional variable-length (burst) busses?
>
>Food for thought...
>
>-JV
>
>
>------------------------------------------------------------------------
>IT Professionals: Match your unique skills with the best IT projects at
>http://click.egroups.com/1/3381/0/_/3462/_/960194457/
>------------------------------------------------------------------------
>
>
>
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA04192 for ; Mon, 5 Jun 2000 12:55:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Jun 2000 12:55:25 +0200 (MEST) Received: (qmail 23549 invoked by uid 0); 5 Jun 2000 10:08:24 -0000 Received: from jk.egroups.com (208.50.144.83) by mx08.rz2.gmx.net with SMTP; 5 Jun 2000 10:08:24 -0000 X-eGroups-Return: sentto-1101623-318-960199682-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 05 Jun 2000 10:08:04 -0000 Received: (qmail 28035 invoked from network); 5 Jun 2000 10:08:02 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Jun 2000 10:08:02 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 5 Jun 2000 10:08:01 -0000 Received: from f-cpu.org (Paris-Raspail-4-65.club-internet.fr [195.36.203.65]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA13422 for ; Mon, 5 Jun 2000 12:04:51 +0200 (MET DST) Message-ID: <393B7BB1.44C3380A@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20000605033532.00938810@mail.mindspring.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Jun 2000 12:06:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My Response to Mr. David Cary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0dbbc5a467036f498a2d7aa22a98c540 Status: R X-Status: N oooops it's sliding off the ground now...

ok so let's restate the things how i percieve them.

ERIN16/32/64 is NOT the F-CPU. i think it was cleared
during the first days when Richard "joined" the team.
the goals are different, the means and ways as well.
but we can benefit from each other's experience or
ideas, so in the last months it was more like a mutual
project observation. I believe that Richard's problems
with his design (he knows it very well, he works on this
for decades now) is typical and is nothing compared to
the troubles we'll have in the future, so i carefully
read his posts.

David Cary's post was not directed to Richard, but
to the F-CPUers in general. it started like that :
"
Dear f-cpu developers,
It looks like "open standard" is the new buzzword.
"
so i don't understand Richard's reaction. it's not
important anyway, it's a post like a lot of posts here
where people tell about something new etc... just
to keep people informed of the technologies around.

ok now, i put my 2 cents, the gentleman debate can resume,
don't worry guyz. oh btw, i'm doing this now (french) :
http://www.mime.univ-paris8.fr/~whygee/memoire/
that's why before mid-july, i won't be full-steam involved in the
f-cpu. diploms first !

have fun,

Jonathan Vaughn wrote:
> but emulating a DDP system is not fully general purpse - for the things you
> are designing for, this is a wonderful system/architecture. But, for example,
> playing Quake 3, it is a tad lacking.
> If I recall, I think the group charter/constitution/whatever we called it,
> called for a general purpose CPU.
<snip>
> -JV
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00449 for ; Tue, 6 Jun 2000 05:45:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 06 Jun 2000 05:45:29 +0200 (MEST) Received: (qmail 11369 invoked by uid 0); 5 Jun 2000 11:18:15 -0000 Received: from hi.egroups.com (208.50.144.89) by mx18.rz2.gmx.net with SMTP; 5 Jun 2000 11:18:15 -0000 X-eGroups-Return: sentto-1101623-319-960203889-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 05 Jun 2000 11:18:09 -0000 Received: (qmail 19888 invoked from network); 5 Jun 2000 11:18:08 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Jun 2000 11:18:08 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta3 with SMTP; 5 Jun 2000 11:18:07 -0000 Received: from 0018728164 (host-208-60-244-97.bix.bellsouth.net [208.60.244.97]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA09910; Mon, 5 Jun 2000 07:18:03 -0400 (EDT) Message-ID: <000801bfcedf$7d60fbc0$61f43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Jun 2000 06:16:24 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Response to Jonathan Vaughn Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFCEB5.9376C4A0" X-UIDL: 675a27b0277c503a1740c79a3fd2407d Status: R X-Status: N ------=_NextPart_000_0005_01BFCEB5.9376C4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The DDP-516 Emulation IS fully general purpose. The difference old = boy is APPLICATION. I am not interested in GAME playing - at this TIME. The only real difference in the F-CPU is the use of on-chip = registers. I have ONE on-chip register - an Accumulator. I have every = functional capability of the F-CPU - my approach is slightly different. Inputs to the CPU are serial, just as they are on your and my PC. = In my case, I use Fibre channels - mainly to remotely locate the Terminal as far as = possible. The only place I use RS232 is for Modem connections - just as they are = in the PC I am working with. I do not accomodate down-loading Software to execute = because it is, and always will be prone to Virsus problems. A plus side to my approach - 128 PC's used for a business = application. There are 128 CPU chips. I use two CPU chips - no matter = the size of the total system. There are also 128 Hard Drives - generally packed with crap that is = seldom - if ever used. My approach here is to use one(1) possibly two for File = maintenance and additional drives for DATA archive. The number is dependent on the size = of the application. Try again Jon. Sincerely Richard E. Hartney Research Director ------=_NextPart_000_0005_01BFCEB5.9376C4A0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    The DDP-516 Emulation IS fully general purpose.  The difference old boy is
APPLICATION.  I am not interested in GAME playing - at this TIME.
 
    The only real difference in the F-CPU is the use of on-chip registers.  I have ONE on-chip register - an Accumulator.  I have every functional capability of the
F-CPU - my approach is slightly different.
 
    Inputs to the CPU are serial, just as they are on your and my PC.  In my case,
I use Fibre channels - mainly to remotely locate the Terminal as far as possible.
The only place I use RS232 is for Modem connections - just as they are in the PC
I am working with.  I do not accomodate down-loading Software to execute because it is, and always will be prone to Virsus problems.
 
    A plus side to my approach - 128 PC's used for a business application.  There are 128 CPU chips.  I use two CPU chips - no matter the size of the total system.
There are also 128 Hard Drives - generally packed with crap that is seldom - if ever
used.  My approach here is to use one(1) possibly two for File maintenance and
additional drives for DATA archive.  The number is dependent on the size of the
application.
 
    Try again Jon.
 
Sincerely
Richard E. Hartney
Research Director
------=_NextPart_000_0005_01BFCEB5.9376C4A0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00461 for ; Tue, 6 Jun 2000 05:45:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 06 Jun 2000 05:45:33 +0200 (MEST) Received: (qmail 18940 invoked by uid 0); 5 Jun 2000 11:42:10 -0000 Received: from fl.egroups.com (208.50.144.74) by mx5.rz2.gmx.net with SMTP; 5 Jun 2000 11:42:10 -0000 X-eGroups-Return: sentto-1101623-320-960205326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 05 Jun 2000 11:42:08 -0000 Received: (qmail 16638 invoked from network); 5 Jun 2000 11:42:05 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 5 Jun 2000 11:42:05 -0000 Received: from unknown (HELO puma-ether.wmin.ac.uk) (161.74.92.94) by mta2 with SMTP; 5 Jun 2000 11:42:05 -0000 Received: from cougar.wmin.ac.uk ([161.74.160.93] ident=exim) by puma-ether.wmin.ac.uk with esmtp (Exim 2.12 #1) id 12yvGd-0000QX-00 for f-cpu@egroups.com; Mon, 5 Jun 2000 12:42:03 +0100 Received: from collector.hscs.wmin.ac.uk ([161.74.97.54] ident=graham) by cougar.wmin.ac.uk with esmtp (Exim 2.12 #1) id 12yvGb-0007Qb-00 for f-cpu@egroups.com; Mon, 5 Jun 2000 12:42:01 +0100 Received: from localhost (graham@localhost) by collector.hscs.wmin.ac.uk (8.9.3/8.9.3) with ESMTP id NAA26586 for ; Mon, 5 Jun 2000 13:01:04 -0400 To: f-cpu@egroups.com In-Reply-To: Message-ID: From: Graham Seaman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Jun 2000 13:01:04 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] rapid IO Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5fb3efd5665ce5d002786455ab1e527 Status: R X-Status: N

On Sun, 4 Jun 2000, David Cary wrote:

>
> Dear f-cpu developers,
>
> It looks like "open standard" is the new buzzword.

I don't think it's so new; it's a standard tactic when new
technologies or sub-areas of a technology emerge. The very
big companies (eg Intel) will tend to try to impose their
own system as a de facto proprietary standard. Medium sized
companies will go into a loose coalition with others to
develop a shared standard (which seems to result in lots of internal
politicking,
very long delays, and quite often a standard where you have to
pay to get a copy of the spec at the end). It's the small
companies who tend to go the 'open' route: if they can persuade
others to adopt their standard by making it open, they have
a head start since they'll already have designs based on it.

And even then there's 'open' and 'open'. 'Open' doesn't necessarily
mean you can actually use it without paying fees (for example,
I believe AMBA is open but patented by Arm, so you have to be
licensed to use it. Is that correct?)

Graham
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00488 for ; Tue, 6 Jun 2000 05:45:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 06 Jun 2000 05:45:41 +0200 (MEST) Received: (qmail 4948 invoked by uid 0); 5 Jun 2000 16:37:13 -0000 Received: from ck.egroups.com (208.50.144.69) by mx15.rz2.gmx.net with SMTP; 5 Jun 2000 16:37:13 -0000 X-eGroups-Return: sentto-1101623-321-960222858-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 05 Jun 2000 16:34:19 -0000 Received: (qmail 17918 invoked from network); 5 Jun 2000 16:34:01 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 5 Jun 2000 16:34:01 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (205.152.0.91) by mta3 with SMTP; 5 Jun 2000 16:34:00 -0000 Received: from 0018728164 (host-209-215-11-177.bix.bellsouth.net [209.215.11.177]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id MAA24413; Mon, 5 Jun 2000 12:33:58 -0400 (EDT) Message-ID: <000801bfcf0b$9fabf5a0$b10bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Jun 2000 11:32:19 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] More Stuff Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFCEE1.B5A95480" X-UIDL: 063a3b4c7edebd253fb4f51bd042fe93 Status: R X-Status: N ------=_NextPart_000_0005_01BFCEE1.B5A95480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I forgot to say ---- Data to the remote Terminals is also accomplished = with a controlled SERIAL stream with Sync, Clock & Data via Fiber = Channels. Sincerely Richard E. Hartney ------=_NextPart_000_0005_01BFCEE1.B5A95480 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
I forgot to say ---- Data to the remote Terminals is also accomplished with a controlled SERIAL stream with Sync, Clock & Data via Fiber Channels.
 
Sincerely
Richard E. Hartney
------=_NextPart_000_0005_01BFCEE1.B5A95480-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00509 for ; Tue, 6 Jun 2000 05:45:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 06 Jun 2000 05:45:47 +0200 (MEST) Received: (qmail 17717 invoked by uid 0); 5 Jun 2000 23:37:52 -0000 Received: from hp.egroups.com (208.50.144.93) by mx03.rz2.gmx.net with SMTP; 5 Jun 2000 23:37:52 -0000 X-eGroups-Return: sentto-1101623-322-960247778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 05 Jun 2000 23:29:47 -0000 Received: (qmail 27883 invoked from network); 5 Jun 2000 23:29:37 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Jun 2000 23:29:37 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 5 Jun 2000 23:29:36 -0000 Received: from f-cpu.org (Paris-Raspail-3-2.club-internet.fr [195.36.203.2]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10518 for ; Tue, 6 Jun 2000 01:29:34 +0200 (MET DST) Message-ID: <393C379D.1744B696@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Jun 2000 01:28:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] rapid IO Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a0085381741c30dfa5679281907ef7a0 Status: R X-Status: N hi Graham,

Graham Seaman wrote:
> On Sun, 4 Jun 2000, David Cary wrote:
> > Dear f-cpu developers,
> >
> > It looks like "open standard" is the new buzzword.
>
> I don't think it's so new; it's a standard tactic when new
> technologies or sub-areas of a technology emerge. The very
> big companies (eg Intel) will tend to try to impose their
> own system as a de facto proprietary standard. Medium sized
> companies will go into a loose coalition with others to
> develop a shared standard (which seems to result in lots of internal
> politicking,
> very long delays, and quite often a standard where you have to
> pay to get a copy of the spec at the end). It's the small
> companies who tend to go the 'open' route: if they can persuade
> others to adopt their standard by making it open, they have
> a head start since they'll already have designs based on it.
>
> And even then there's 'open' and 'open'. 'Open' doesn't necessarily
> mean you can actually use it without paying fees (for example,
> I believe AMBA is open but patented by Arm, so you have to be
> licensed to use it. Is that correct?)

very good point, Graham, and that's where the F-CPU comes ;-)
having a CPU the way Linux works is another level : no patent,
no need to ask for permission. just respect the fucking licence,
and everybody will be happy.

Freedom is not openness in your scheme. that's the driving
force of this project. Whatever architecture we use, this has
not changed :-)

> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00448 for ; Mon, 12 Jun 2000 19:28:26 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:28:26 +0200 (MEST) Received: (qmail 23205 invoked by uid 0); 9 Jun 2000 17:43:12 -0000 Received: from hi.egroups.com (208.50.144.89) by mx17.rz2.gmx.net with SMTP; 9 Jun 2000 17:43:12 -0000 X-eGroups-Return: sentto-1101623-323-960572580-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 09 Jun 2000 17:43:08 -0000 Received: (qmail 29601 invoked from network); 9 Jun 2000 17:42:59 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 9 Jun 2000 17:42:59 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 9 Jun 2000 17:42:59 -0000 Received: from f-cpu.org (Aubervilliers-3-100.club-internet.fr [195.36.145.100]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA22523 for ; Fri, 9 Jun 2000 19:42:57 +0200 (MET DST) Message-ID: <39412C65.20192552@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Jun 2000 19:41:57 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DATE 2001 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c6ba5626cd320f2211eea76ecea56a02 Status: R X-Status: N
The DATE 2001 conference will be held in Munich in march, 12th to 16th
(Neue Messe, see www.date-conference.com).
I have the firm intention to be there for two reasons : spread the word
about the F-CPU among the EDA specialists, and meet some of the german
f-cpuers. plus, if i am student in Jussieu next year, i may well represent
the ASIME department (that's where they develop Alliance).

I know it's a bit early to organize this now, but better soon than late,
right ? DATE and the 17C3 are two milestones in the f-cpu project and
we have to be there.

I ask you this :
- who will come ? Sven, anybody else ? i know that there are some people
in Munich.
- what about the hosting ? who has some square meters and a carpet left
for someone to sleep ?
- Who has a laptop for making some presentations there ?
- Who can make a german and an english translation of the french brochure
we're currently making ?
- Can we start a thread for discussing seriously about writing
the F-CPU licence ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00493 for ; Mon, 12 Jun 2000 19:28:34 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:28:34 +0200 (MEST) Received: (qmail 8307 invoked by uid 0); 10 Jun 2000 00:04:27 -0000 Received: from ho.egroups.com (208.50.144.85) by mx14.rz2.gmx.net with SMTP; 10 Jun 2000 00:04:27 -0000 X-eGroups-Return: sentto-1101623-325-960595463-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 10 Jun 2000 00:04:24 -0000 Received: (qmail 29958 invoked from network); 10 Jun 2000 00:04:22 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 10 Jun 2000 00:04:22 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 10 Jun 2000 00:04:22 -0000 Received: from f-cpu.org (Paris-Raspail-1-151.club-internet.fr [195.36.192.151]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26271 for ; Sat, 10 Jun 2000 02:04:15 +0200 (MET DST) Message-ID: <394185BB.6F1309F5@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Jun 2000 02:03:07 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-cpu web site Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f84d917b04480a164d925cc46bfcaefc Status: R X-Status: N hello,

as you probably already know, i don't have much free time
for the project. But this shoudln't stop you from contributing !
the web site is lagging a bit and you are encouraged to help
maintaining it. you simply have to write the HTML file(s)
and ask Paul, Sven or me to upload it on the server.
are you ready ? go !
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00496 for ; Mon, 12 Jun 2000 19:28:35 +0200 X-Flags: 1001 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:28:35 +0200 (MEST) Received: (qmail 28455 invoked by uid 0); 10 Jun 2000 00:04:34 -0000 Received: from jj.egroups.com (208.50.144.82) by mx15.rz2.gmx.net with SMTP; 10 Jun 2000 00:04:34 -0000 X-eGroups-Return: sentto-1101623-324-960595462-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 10 Jun 2000 00:04:33 -0000 Received: (qmail 14315 invoked from network); 10 Jun 2000 00:04:20 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 10 Jun 2000 00:04:20 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 10 Jun 2000 00:04:20 -0000 Received: from f-cpu.org (Paris-Raspail-1-151.club-internet.fr [195.36.192.151]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26260 for ; Sat, 10 Jun 2000 02:04:12 +0200 (MET DST) Message-ID: <394185BD.54168805@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Jun 2000 02:03:09 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fcc7012bb9d22bacb5d62aeca50891a9 Status: R X-Status: N hi,
some random babblings, sorry, but hey this was to be done earlier anyway.

This is a proposition and some "meat" for the F-CPU licence rev. 0.01,
as everything it is a subject and basis for constructive discussions
and should not be considered as definitive : it's just a few things
that popped in my brain. Everybody is asked to contribute to this
decisive, non-technical side of the project.

What i've done was simply to list the desirable differences and similarities
between the GPL and the F-CPU licence. maybe we'll "patch" the GPL later
since most of the important things and principles are already written there,
with this "patch" as an adaptation of the original text.


here it goes :

(add your name + revision date at the bottom of the list)
june 10th 2000, YG


(indicate where and what you have modified)

Prologue :
----------

Licences are usually intended to restrict the rights of the end user.
This F-CPU licence defines the terms under which the user is given
rights as well as responsibilities : the licence also defines duties
and the rules of the game for the Intellectual Property transfers
happening when developping the F-CPU.

We stress on the
point that each user and developper is part of a community and
what is good for the community is good for the individual, and vice
versa. This is why there is no notion of "customer" and "reseller"
in this document, but everybody is considered as an individual
who can be a "user" as well as a "developper" according to the
direction of the IP transfer (a "user" uses the IP developped
by the "developper").


Goal(s):
--------

The goal of this licence is to protect the Intellectual Property
of the F-CPU project.

The idea behind the F-CPU project is mainly to transpose the spirit of
the GNU project (including the GPL licence and the sofware developped
for the GNU project) to the microelectronics world (EDA, CPU
architecture, IP blocks, instruction sets, software development
kits...). The goal of this document is NOT to specify the project
goals because it is documented elsewhere and may evolve.

The F-CPU project is NOT the GNU project. There are certain radical
differences : this is not a software-only project, the electronics
industry has a different nature and the GPL can't be used as it
is. The goal of this document is to adapt the GPL and its
spirit to this different context. While the main ideas of freedom
remain (in the sense of the GPL), some details change.

This licence is also a "game rule" of the F-CPU community which
is composed of users and developpers. It defines the way people
interact at a general level.


What is in common with the GPL ?
--------------------------------

The F-CPU licence differs from the GPL on certain aspects but one
can see a parallel between them. The GPL can be applied to a source
code, that is : a textual representation of a program and all the
derived works (compiled files, non-textual representations etc).

The F-CPU licence specifies the terms and conditions of distribution
and development of the project's "Intellectual Property" (IP) which
is more general than a textual source feeding an EDA software suite.
The F-CPU IP consists of texts, source codes in various langages,
manuals, drawings, all the data that describe the CPU, its structure,
its behaviour and its interactions with other components. The IP
spans from high-level schematics and descriptions up to the
mask files (like GDSII) or equivalent files for Programmable Logic
Devices. This generalisation includes the principles and ideas behind
the architectures, all the necessary files in their respective formats
(including but not limited to : VHDL, Verilog, RTL, scripts, pictures,
texts, test vectors...).

The scope of this licence stops when it comes to physical process-dependent
parameters that do not directly influence the performance
or the price of the final product. The thickness of the metal layers,
their chemical composition or the deposition details do not directly
influence the overall architecture in the general case. Otherwise, the
implementor must specify the critical parameters that were used to
fabricate the chip and modify the architecture, so the implementation
can be reproduced.


The general principle is that one can read the GPL and replace "software"
with "F-CPU Intellectual Property". A chip, a final product derived
>from the IP or any material implementation is considered as a "distribution"
when compared to the software world. Hardware has a price, has fabrication,
transportation and marketing constraints but all the informations that
constitute the IP can be easily spread through electronic media. A
"distribution" also has the obvious constraint to be complete and
working, otherwise it is still considered as a "source" ans is freely shared.

Like GPL'ed software, the IP files can be sold on a physical media
(that is : CD-ROM, diskette, magnetic tape or similar persistent medium)
under the condition that the same data are also available for free
download on the Internet (with ftp or http). This is consistent with the
fact that all IP is freely available without restriction (cf : the following
chapter).


Rights and duties :
-------------------

- The distribution, modification and knowledge of the sources
(non physical forms of the IP, as opposed to the "implementation"
of this IP) must not be bound or restricted in ANY way.

In particular, you need not to be a customer of a F-CPU vendor in order
to access the sources of any F-CPU version or derived work.
Similarly, in-progress works must be available upon a single request.

The reason for this break from the GPL principle is simple : the F-CPU
is not the property of an individual or a company, but belongs to
everybody. Anybody must be able to examine, use or modify any version
of any document because it is not the exclusive property of a person.
If you have your kid in a kindergarten, you think it is normal to
visit the location and see if your kid is safe or if nothing wrong
happened. Same goes with software. Secrecy has no advantage in the
F-CPU community and corresponds to a self-exclusion from the group.

- Any implementation of the F-CPU IP must hold a written
mention of the version and an Internet address (URL) where the original
files are stored. This is meant to ensure that any user can easily use
any F-CPU version or variation, simply looking at the chip's package.

For example, this is a recommended format :

* on the chip :

  Zoobidah 125089
(c) 2025 the zoobidah corp, (C) 2000 the F-CPU group
  see http://www.zoobidah.com/125089/

  (or simply : zoobidah.com/125089/)

* on the web :

www.zoobidah.com
|-- index.html indicates where the design files are located in the site.
|-- /125085
|-- /125086  \
|-- /125087   different implementation versions
|-- /125088  /
|-- /125089
|   |-- index.html
|   |-- README.TXT
|   |-- /manuals           \
|   |-- /datasheets         for every design and version
|   |-- /sdk               /
|   |-- /errata (nobody's perfect !)
|   |-- /sources
|  ...
...

If the Zoobidah corp. copied and implemented a design of the Artchoon corp.
without modifying it, the index.html at http://www.zoobidah.com/125089/
must specify it and point to the original location of the files. Zoobidah
may miror the files as well (just in case Artchoon corp. went out of business
without warning).

If there was not enough surface on the package, the hardcopy manual
provided with the chip as well as the website
must ensure that one can find the location of the design files
easily in the server, for example with a general index directly
reachable from the main page of the site. It is not required that the files
are located on the same server, but all the files used to fabricate
the chip MUST be available directly through a simple URL.

Specifying an URL on the chip is important when one has to use/acquire
a new or old hardware : if several vendors offer several versions
of a chip, one can not interpret all the numbers on a package.
A direct URL indirectly helps evaluate the characteristics of
a certain chip without browsing through a hundred books or web sites,
in search of the exact reference. This web hosting is also one part
of the user support that a company owes to a customer. It is not
considered a "fair sale" to sell something without letting the user
know what's inside it. Respecting the practice described in this
chapter is one simple way to be more transparent with the users.


- All software created for simulating, developping and managing
the F-CPU IP must be distributed under the terms of the GPL in order
to promote and keep the openness and freedom of the project.

Existing software that are not distributed under the terms of the GPL
can be ported to a F-CPU platform if these applications are not
platform-specific. For example, it is possible to port Mozilla
(distributed under the terms of the MPL), LaTeX (under LPPL) or
Apache to the F-CPU.

It is not possible to port non-GPL software
that interact directly with the machine : device drivers, OS kernels,
compilers, debuggers or cpu simulators/emulators. This measure is necessary
to keep the platform "free" from industrial pressure, arbitrary biases or
the damages of the discontinuing of a product line. It also ensures that
the new software matches the specific characteristics of the new hardware
with less performance lag (thanks to rewriting rather than recompiling only).

- All documentations written about the F-CPU and the associated software
must be distributed under the terms of the GFDL (GNU Free Documentation
Licence).

- The use and distribution of the F-CPU IP is allowed under the sole
condition that you agree to and respect this F-CPU licence.
You do not have to register yourself in a database, you do not need
any authorization of any kind and you can do whatever you want with the
F-CPU IP, except : changing the copyright notices, altering this licence
or use it against its spirit.

Unlike some "Open" standards and initiatives, you do not need to fill in
a form, pay a fee or a licence to use the F-CPU IP.
In return, you may not restrict the direct access to the IP that you have
modified, even for the sake of collecting statistics or polling (or, in
general, collecting individual/personal data or going through advertising
pages).




When this document will be ready, the big work will be to merge it
with the GPL text. we need help for this, because the F-CPU licence
must not become incompatible, even though some details differ.
see http://www.gnu.org/philosophy/license-list.html
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00511 for ; Mon, 12 Jun 2000 19:28:40 +0200 X-Flags: 1001 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:28:40 +0200 (MEST) Received: (qmail 10468 invoked by uid 0); 10 Jun 2000 07:45:37 -0000 Received: from ci.egroups.com (207.138.41.176) by mx15.rz2.gmx.net with SMTP; 10 Jun 2000 07:45:37 -0000 X-eGroups-Return: sentto-1101623-326-960623134-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 10 Jun 2000 07:45:36 -0000 Received: (qmail 10556 invoked from network); 10 Jun 2000 07:45:33 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Jun 2000 07:45:33 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 10 Jun 2000 07:45:33 -0000 Received: from f-cpu.org (Paris-Raspail-2-229.club-internet.fr [195.36.192.229]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA09660 for ; Sat, 10 Jun 2000 09:45:31 +0200 (MET DST) Message-ID: <3941F1DD.6287DC7E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Jun 2000 09:44:30 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: DATE2001 etc... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1fd9d0fa4e5a9b3f5a002a022b147cb0 Status: R X-Status: N
hallo alle !

Fabian Sturm wrote:
> On Fri, Jun 09, 2000 at 07:37:26PM +0200, Yann Guidon wrote:
> > The DATE 2001 conference will be held in Munich in march, 12th to 16th
> > (Neue Messe, see www.date-conference.com).
..
> > I ask you this :
> > - who will come ? Sven, anybody else ? i know that there are some people
> > in Munich.
>
> Some? I don't know anyone else then me from Munich :(

ah. i made a mistake, then.
it's not a problem though. there will be more people there later ;-)

> > - what about the hosting ? who has some square meters and a carpet left
> > for someone to sleep ?
> Shouldn't be such a problem, but its too early to make it fix.
i know. i'm simply trying to make a little prospection.

> > - Who has a laptop for making some presentations there ?
> Hmm something old but should work, but maybe that changes till
> 2001. Perhaps an fcpu notebook ;)
dream if you want, but i want something that works ;-)
i don't see a f-cpu notebook working before a few years at least...

> > - Who can make a german and an english translation of the french brochure
> > we're currently making ?
> Uff hmm i don't really have time, but send it and we'll see.
dont worry. the french brochure won't be ready before a few weeks.
i'll make a first english version later, leaving some work to the others.
i guess you don't speak french, so you have some time left :-)
anyway, it would be cool to have it ready in december for the 17C3...

> CU in Munich Fabian
as soon as possible :-)

cheers,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00568 for ; Mon, 12 Jun 2000 19:29:05 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:29:05 +0200 (MEST) Received: (qmail 23384 invoked by uid 0); 10 Jun 2000 20:18:39 -0000 Received: from fk.egroups.com (208.50.144.73) by mx11.rz2.gmx.net with SMTP; 10 Jun 2000 20:18:39 -0000 X-eGroups-Return: sentto-1101623-327-960668313-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fk.egroups.com with NNFMP; 10 Jun 2000 20:18:35 -0000 Received: (qmail 30948 invoked from network); 10 Jun 2000 20:18:32 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 10 Jun 2000 20:18:32 -0000 Received: from unknown (HELO mrs-3.smartworld.net) (216.70.64.34) by mta1 with SMTP; 10 Jun 2000 20:18:32 -0000 Received: from smtp.freewwweb.com (1Cust210.tnt2.beaverton.or.da.uu.net [63.21.215.210]) by mrs-3.smartworld.net (8.9.1a/8.9.1) with SMTP id QAA66080; Sat, 10 Jun 2000 16:17:16 -0400 (EDT) Received: from SMTP.MIDWESTMAIL.COM(alt1.MIDWESTMAIL.COM(208.9.77.000)) by MIDWESTMAIL.COM, SMTP.MIDWESTMAIL.COM, HOST.MIDWESTMAIL.COM (8.8.5/8.6.5) with SMTP id GAA07288 for ; Sat, 10 Jun 2000 13:12:20 -0600 (EST) To: Dear.fellow.safe.list.member@MIDWESTMAIL.COM Message-ID: <199702170026.GAA08056@MIDWESTMAIL.COM> Comments: Authenticated sender is From: postalcenter42@netscape.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Jun 00 13:12:20 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] My new email addresss ! (Special Delivery) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 98745632123654789874563212365478 Status: R X-Status: N Hi, Thanks for joining "The Financial Freedom Services newsletter", and our safe opt-in members list.
Our monthly newsletter will come to you on the 1st of each month and includes the best money generating
programs around and our special feature "internet site of the month". Here is this months winner..............
(To unsubscribe from our newsletter, please see bottom of this ad)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

How to earn $400.00  by  tommorw morning by sending one simple fax !!


"Best Kept Secrets Of The Wealthy Revealed" !!


Discover how to generate huge amounts of cash in days and beome literally wealthy overnight......
.......... and we have a $10,000.00 Guarantee to back it up!!!


  You will discover:

  THE GOVERNMENT LOTTERY YOU CAN'T LOSE ! (Your money back if you don't win!)

  How to EARN $9000 A MONTH FROM ANY BANK YOU CAN FIND !

  How to EARN $400 A DAY FOR SENDING ONE SIMPLE FAX!

  How to GET YOUR PART OF THE BILLIONS THE GOVERNMENT IS HOLDING !

  How to EARN A $1000 OR MORE READING NEWSPAPERS !

  How to GET YOUR SHARE OF THE MILLIONS MAGAZINES GIVE-AWAY EACH DAY!

  How to GET $20,000 WORTH OF FURNITURE FREE !

  How to OWN A BRAND NEW CAR EVERY YEAR ABSOLUTELY FREE !

  How to TRAVEL ANYWHERE IN THE WORLD 2-WAY -FREE !

  How to GET UNCLE SAM TO HELP PAY YOUR RENT!

  How to GET REGULAR MAIL POSTAGE FOR 1/2 THE NORMAL PRICE !

  How to REMOVE UNFAVORABLE REMARKS FROM YOUR CREDIT FILE !

  THE SECRET LAW THAT ERASES ALL YOUR DEBT !


These are only a few of the many "insider secrets" that could make you wealthy overnight !

Click here now :http://3506561211/%67%65%74%72%69%63%682%30/no%77%2E%68%74%6D


P.S. Please don't let a moment go by that could keep you from the money and lifestyle you desire and deserve. ACT NOW!


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
***To be removed from our in house opt-in "safe list***

If you wish to be removed from our free monthly newsletter  you may do so by hitting reply to this email with  the word "Remove" in the subject field and you will not receive any further mailings from us,
nor will your name be given out for further use.
Thanks again, for visiting our site!!

Financial Freedom Services
9138 Robinson
Overland Park, KS 66212
1-877-290-6930 Ext. 402
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00577 for ; Mon, 12 Jun 2000 19:29:07 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:29:07 +0200 (MEST) Received: (qmail 12088 invoked by uid 0); 11 Jun 2000 10:32:08 -0000 Received: from hl.egroups.com (208.50.144.86) by mx16.rz2.gmx.net with SMTP; 11 Jun 2000 10:32:08 -0000 X-eGroups-Return: sentto-1101623-328-960719524-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 11 Jun 2000 10:32:07 -0000 Received: (qmail 9092 invoked from network); 11 Jun 2000 10:28:02 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Jun 2000 10:28:02 -0000 Received: from unknown (HELO web1104.mail.yahoo.com) (128.11.23.124) by mta2 with SMTP; 11 Jun 2000 10:27:59 -0000 Received: (qmail 18490 invoked by uid 60001); 11 Jun 2000 10:27:39 -0000 Message-ID: <20000611102739.18489.qmail@web1104.mail.yahoo.com> Received: from [199.203.98.250] by web1104.mail.yahoo.com; Sun, 11 Jun 2000 03:27:39 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Jun 2000 03:27:39 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 44fad381cf862d240dc00c08d218a82a Status: R X-Status: N try to check the suggested protection schems by
OpenIPCore organization.
http://www.opencores.org/OIPC/

Regards,
Jamil


--- Yann Guidon <whygee@f-cpu.org> wrote:
> hi,
> some random babblings, sorry, but hey this was to be
> done earlier anyway.
>
> This is a proposition and some "meat" for the F-CPU
> licence rev. 0.01,
> as everything it is a subject and basis for
> constructive discussions
> and should not be considered as definitive : it's
> just a few things
> that popped in my brain. Everybody is asked to
> contribute to this
> decisive, non-technical side of the project.
>
> What i've done was simply to list the desirable
> differences and similarities
> between the GPL and the F-CPU licence. maybe we'll
> "patch" the GPL later
> since most of the important things and principles
> are already written there,
> with this "patch" as an adaptation of the original
> text.
>
>
> here it goes :
>
> (add your name + revision date at the bottom of the
> list)
> june 10th 2000, YG
>
>
> (indicate where and what you have modified)
>
> Prologue :
> ----------
>
> Licences are usually intended to restrict the rights
> of the end user.
> This F-CPU licence defines the terms under which the
> user is given
> rights as well as responsibilities : the licence
> also defines duties
> and the rules of the game for the Intellectual
> Property transfers
> happening when developping the F-CPU.
>
> We stress on the
> point that each user and developper is part of a
> community and
> what is good for the community is good for the
> individual, and vice
> versa. This is why there is no notion of "customer"
> and "reseller"
> in this document, but everybody is considered as an
> individual
> who can be a "user" as well as a "developper"
> according to the
> direction of the IP transfer (a "user" uses the IP
> developped
> by the "developper").
>
>
> Goal(s):
> --------
>
> The goal of this licence is to protect the
> Intellectual Property
> of the F-CPU project.
>
> The idea behind the F-CPU project is mainly to
> transpose the spirit of
> the GNU project (including the GPL licence and the
> sofware developped
> for the GNU project) to the microelectronics world
> (EDA, CPU
> architecture, IP blocks, instruction sets, software
> development
> kits...). The goal of this document is NOT to
> specify the project
> goals because it is documented elsewhere and may
> evolve.
>
> The F-CPU project is NOT the GNU project. There are
> certain radical
> differences : this is not a software-only project,
> the electronics
> industry has a different nature and the GPL can't be
> used as it
> is. The goal of this document is to adapt the GPL
> and its
> spirit to this different context. While the main
> ideas of freedom
> remain (in the sense of the GPL), some details
> change.
>
> This licence is also a "game rule" of the F-CPU
> community which
> is composed of users and developpers. It defines the
> way people
> interact at a general level.
>
>
> What is in common with the GPL ?
> --------------------------------
>
> The F-CPU licence differs from the GPL on certain
> aspects but one
> can see a parallel between them. The GPL can be
> applied to a source
> code, that is : a textual representation of a
> program and all the
> derived works (compiled files, non-textual
> representations etc).
>
> The F-CPU licence specifies the terms and conditions
> of distribution
> and development of the project's "Intellectual
> Property" (IP) which
> is more general than a textual source feeding an EDA
> software suite.
> The F-CPU IP consists of texts, source codes in
> various langages,
> manuals, drawings, all the data that describe the
> CPU, its structure,
> its behaviour and its interactions with other
> components. The IP
> spans from high-level schematics and descriptions up
> to the
> mask files (like GDSII) or equivalent files for
> Programmable Logic
> Devices. This generalisation includes the principles
> and ideas behind
> the architectures, all the necessary files in their
> respective formats
> (including but not limited to : VHDL, Verilog, RTL,
> scripts, pictures,
> texts, test vectors...).
>
> The scope of this licence stops when it comes to
> physical process-dependent
> parameters that do not directly influence the
> performance
> or the price of the final product. The thickness of
> the metal layers,
> their chemical composition or the deposition details
> do not directly
> influence the overall architecture in the general
> case. Otherwise, the
> implementor must specify the critical parameters
> that were used to
> fabricate the chip and modify the architecture, so
> the implementation
> can be reproduced.
>
>
> The general principle is that one can read the GPL
> and replace "software"
> with "F-CPU Intellectual Property". A chip, a final
> product derived
> from the IP or any material implementation is
> considered as a "distribution"
> when compared to the software world. Hardware has a
> price, has fabrication,
> transportation and marketing constraints but all the
> informations that
> constitute the IP can be easily spread through
> electronic media. A
> "distribution" also has the obvious constraint to be
> complete and
> working, otherwise it is still considered as a
> "source" ans is freely shared.
>
> Like GPL'ed software, the IP files can be sold on a
> physical media
> (that is : CD-ROM, diskette, magnetic tape or
> similar persistent medium)
> under the condition that the same data are also
> available for free
> download on the Internet (with ftp or http). This is
> consistent with the
> fact that all IP is freely available without
> restriction (cf : the following
> chapter).
>
>
> Rights and duties :
> -------------------
>
> - The distribution, modification and knowledge of
> the sources
> (non physical forms of the IP, as opposed to the
> "implementation"
> of this IP) must not be bound or restricted in ANY
> way.
>
> In particular, you need not to be a customer of a
> F-CPU vendor in order
> to access the sources of any F-CPU version or
> derived work.
> Similarly, in-progress works must be available upon
> a single request.
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
Click Here!
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00580 for ; Mon, 12 Jun 2000 19:29:09 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Jun 2000 19:29:09 +0200 (MEST) Received: (qmail 5071 invoked by uid 0); 11 Jun 2000 11:30:52 -0000 Received: from ck.egroups.com (208.50.144.69) by mx18.rz2.gmx.net with SMTP; 11 Jun 2000 11:30:52 -0000 X-eGroups-Return: sentto-1101623-329-960723045-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 11 Jun 2000 11:30:47 -0000 Received: (qmail 26753 invoked from network); 11 Jun 2000 11:30:44 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 11 Jun 2000 11:30:44 -0000 Received: from unknown (HELO web1103.mail.yahoo.com) (128.11.23.123) by mta3 with SMTP; 11 Jun 2000 11:30:44 -0000 Received: (qmail 26205 invoked by uid 60001); 11 Jun 2000 11:30:44 -0000 Message-ID: <20000611113044.26204.qmail@web1103.mail.yahoo.com> Received: from [199.203.98.250] by web1103.mail.yahoo.com; Sun, 11 Jun 2000 04:30:44 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Jun 2000 04:30:44 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5a21a23587bfaa6d6b0119f772fa21e Status: R X-Status: N It is good work
I am going to update the OpenIPCore hardware license
with some items from your license to make it more
generic for OpenHW designs.

My comments are:

--- Yann Guidon <whygee@f-cpu.org> wrote:
> Prologue :
> ----------
>
> Licences are usually intended to restrict the rights
> of the end user.
> This F-CPU licence defines the terms under which the
> user is given
> rights as well as responsibilities : the licence
> also defines duties
> and the rules of the game for the Intellectual
> Property transfers
> happening when developping the F-CPU.
>
> We stress on the
> point that each user and developper is part of a
> community and
> what is good for the community is good for the
> individual, and vice
> versa. This is why there is no notion of "customer"
> and "reseller"
> in this document, but everybody is considered as an
> individual
> who can be a "user" as well as a "developper"
> according to the
> direction of the IP transfer (a "user" uses the IP
> developped
> by the "developper").
>
>
> Goal(s):
> --------
>
> The goal of this licence is to protect the
> Intellectual Property
> of the F-CPU project.

I think this hw work need patent to protect it, your
license is more or less like NDA.

>
> This licence is also a "game rule" of the F-CPU
> community which
> is composed of users and developpers. It defines the
> way people
> interact at a general level.
>
>
> What is in common with the GPL ?
> --------------------------------
>
> The F-CPU licence differs from the GPL on certain
> aspects but one
> can see a parallel between them. The GPL can be
> applied to a source
> code, that is : a textual representation of a
> program and all the
> derived works (compiled files, non-textual
> representations etc).
>
> The F-CPU licence specifies the terms and conditions
> of distribution
> and development of the project's "Intellectual
> Property" (IP) which
> is more general than a textual source feeding an EDA
> software suite.
> The F-CPU IP consists of texts, source codes in
> various langages,
> manuals, drawings, all the data that describe the
> CPU, its structure,
> its behaviour and its interactions with other
> components. The IP
> spans from high-level schematics and descriptions up
> to the
> mask files (like GDSII) or equivalent files for
> Programmable Logic
> Devices. This generalisation includes the principles
> and ideas behind
> the architectures, all the necessary files in their
> respective formats
> (including but not limited to : VHDL, Verilog, RTL,
> scripts, pictures,
> texts, test vectors...).

All these items are copyrightable, so you can use the
GPL directly.

> The scope of this licence stops when it comes to
> physical process-dependent
> parameters that do not directly influence the
> performance
> or the price of the final product. The thickness of
> the metal layers,
> their chemical composition or the deposition details
> do not directly
> influence the overall architecture in the general
> case. Otherwise, the
> implementor must specify the critical parameters
> that were used to
> fabricate the chip and modify the architecture, so
> the implementation
> can be reproduced.

I agree with you that there should be no restriction
on the type of implementation but will you allow
everyone to implement it?

> The general principle is that one can read the GPL
> and replace "software"
> with "F-CPU Intellectual Property". A chip, a final
> product derived
> from the IP or any material implementation is
> considered as a "distribution"
> when compared to the software world. Hardware has a
> price, has fabrication,
> transportation and marketing constraints but all the
> informations that
> constitute the IP can be easily spread through
> electronic media. A
> "distribution" also has the obvious constraint to be
> complete and
> working, otherwise it is still considered as a
> "source" ans is freely shared.
>
> Like GPL'ed software, the IP files can be sold on a
> physical media
> (that is : CD-ROM, diskette, magnetic tape or
> similar persistent medium)
> under the condition that the same data are also
> available for free
> download on the Internet (with ftp or http). This is
> consistent with the
> fact that all IP is freely available without
> restriction (cf : the following
> chapter).
>
>
> Rights and duties :
> -------------------
>
> - The distribution, modification and knowledge of
> the sources
> (non physical forms of the IP, as opposed to the
> "implementation"
> of this IP) must not be bound or restricted in ANY
> way.


but what about selling it? he/she should not include
the cost of R&D only the cost of implementaion like.
In the software distribution you can sell them with no
more than the cost of cdrom and packaging.



> In particular, you need not to be a customer of a
> F-CPU vendor in order
> to access the sources of any F-CPU version or
> derived work.
> Similarly, in-progress works must be available upon
> a single request.
>




===========================

The reason for this break from the GPL principle is
simple : the F-CPU
is not the property of an individual or a company, but
belongs to
everybody. Anybody must be able to examine, use or
modify any version
of any document because it is not the exclusive
property of a person.
If you have your kid in a kindergarten, you think it
is normal to
visit the location and see if your kid is safe or if
nothing wrong
happened. Same goes with software. Secrecy has no
advantage in the
F-CPU community and corresponds to a self-exclusion
>from the group.

- Any implementation of the F-CPU IP must hold a
written
mention of the version and an Internet address (URL)
where the original
files are stored. This is meant to ensure that any
user can easily use
any F-CPU version or variation, simply looking at the
chip's package.

- All software created for simulating, developping and
managing
the F-CPU IP must be distributed under the terms of
the GPL in order
to promote and keep the openness and freedom of the
project.


- All documentations written about the F-CPU and the
associated
software
must be distributed under the terms of the GFDL (GNU
Free Documentation
Licence).

- The use and distribution of the F-CPU IP is allowed
under the sole
condition that you agree to and respect this F-CPU
licence.
You do not have to register yourself in a database,
you do not need
any authorization of any kind and you can do whatever
you want with the
F-CPU IP, except : changing the copyright notices,
altering this
licence
or use it against its spirit.

==========================
I liked these itmes specially that related to software
and documentation license.


Good work but do not forget the physical implementaion

Jamil Khatib

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00326 for ; Wed, 14 Jun 2000 01:02:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 14 Jun 2000 01:02:09 +0200 (MEST) Received: (qmail 7983 invoked by uid 0); 12 Jun 2000 21:50:03 -0000 Received: from ci.egroups.com (207.138.41.176) by mx09.rz2.gmx.net with SMTP; 12 Jun 2000 21:50:03 -0000 X-eGroups-Return: sentto-1101623-330-960846590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 12 Jun 2000 21:49:55 -0000 Received: (qmail 5444 invoked from network); 12 Jun 2000 21:49:49 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 12 Jun 2000 21:49:49 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 12 Jun 2000 21:49:49 -0000 Received: from f-cpu.org (Paris-Raspail-4-75.club-internet.fr [195.36.203.75]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA10770 for ; Mon, 12 Jun 2000 23:49:24 +0200 (MET DST) Message-ID: <39455A8E.32A96052@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000611102739.18489.qmail@web1104.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Jun 2000 23:47:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8cb7f083b4b4d6a635f8a60b949fc663 Status: R X-Status: N

Jamil Khatib wrote:
>
> try to check the suggested protection schems by
> OpenIPCore organization.
> http://www.opencores.org/OIPC/
>
> Regards,
> Jamil

Thank you Jamil,
been there, downloaded, and now i have to read them all ! :-)
later for the answer of the rest,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00335 for ; Wed, 14 Jun 2000 01:02:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 14 Jun 2000 01:02:10 +0200 (MEST) Received: (qmail 32699 invoked by uid 0); 13 Jun 2000 02:57:15 -0000 Received: from hn.egroups.com (208.50.144.84) by mx18.rz2.gmx.net with SMTP; 13 Jun 2000 02:57:15 -0000 X-eGroups-Return: sentto-1101623-331-960865023-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 13 Jun 2000 02:57:11 -0000 Received: (qmail 15142 invoked from network); 13 Jun 2000 02:57:02 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 13 Jun 2000 02:57:02 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 13 Jun 2000 02:57:02 -0000 Received: from f-cpu.org (Paris-Raspail-3-22.club-internet.fr [195.36.203.22]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA11693 for ; Tue, 13 Jun 2000 04:56:57 +0200 (MET DST) Message-ID: <3945A2BA.482AC982@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000611113044.26204.qmail@web1103.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Jun 2000 04:55:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8e3e698f035cdd013e28979c38408a6a Status: R X-Status: N hi again !

i read some files from the site, and found the controversial
article from RMS about open HW. some texts/discussions were
interesting, particularly the problem of what the copyright
protects. i won't die silly ;-)

Jamil Khatib wrote:
> It is good work
well, thanks, i see it more like a personal rant than
a "work" anyway ;-) this "work" will be fruitful if
it helps define a legal ("can be valid in a courtroom")
licence for the f-cpu and similar projects.

> I am going to update the OpenIPCore hardware license
> with some items from your license to make it more
> generic for OpenHW designs.
yo ! is it already fame or what ? ;-P

one remark anyway : i try to remain unafiliated with
OpenCores/OpenIPCores etc simply because i don't feel
that it's the way i see things. This is purely a personal
opinion, and i know and respect the f-cpuers who belong to
other efforts. I'm happy when my work is reused by other
groups. but my gut feeling is that the F-CPU project is
and will remain a wonderful utopy and laboratory where we
can experiment freely. We will certainly get some result(s)
one day, and we know that this effort is a long-term
project, but we're far from business plans and roadmap
like at OpenCores. Part of it is that we slowly realize
that we don't need "that much" funding to get something
cool working. Time is what's lacking (we all work or study
at the same time), not money.

My point (part of it) is that we don't need to open a business,
just be organised and active is enough. We don't need to be
"open" be "free" (in a sense, similar to the open vs free war
in the SW branch). there is no war here, just claims (mine at least)
for a more idealistic, (almost) religious or utopic view of the
rights. Of course we won't burn anyone down ;-)

On Opencores there are things that i don't really get.

OIPC/licgoals.shtml, License Objectives :

<li>Anyone can manufactor the hardware design
<li>Anyone can customize the hardware design for his needs
<li>Anyone can transfer and modify the hardware design.
<li>All changes and modifications should be made public and availalbe for anyone.
<li>The license should restrict the commercial income of the hardware products
<li>The license should be applied to new works and derivative works

i don't get the sense and goal of the 5) : IF F-CPU group is mainly in charge of
the IP and its coherency, what would be the economical advantage of limiting
the price of the chips ? it is not legal (i think) and goes against the freedom
of competition.

or:
OIPC/license.shtml

OpenIP Hardware License is divided into two licenses: one a la GNU GPL and one a la GNU LGPL.
YG----> In the f-cpu utopic world, meant to run any GPL'd OS, i see no reason to have
a second weakened licence, or open to proprietary vices. All the codes i write is under GPL
for a few years.

Basic Licesne terms:
<li> Designs can be altered while keeping list of modifications " the same as in GNU "
<li> No money can be earned by selling the designs them selves, but anyone can get money
by selling the implementation of the design, such as ICs based on some cores, Boards based
on some schematics or Layouts, and even GUI interfaces to text mode drivers. " The same as GPL SW"
<li> Any update to the design should be documented and returned to the design.
YG----> i'm less enthusiastic for this third term : i would place it as "recommended", not
"obligatory", because some projects (and particularly F-CPU) might fork at one point or another.
This way, anybody can take a "lead" on one point, instead of wasting his energy with version checking etc...

<LI> Any derivative work based on the IP should be free under OpenIP License.<br>
Derivative work means any update, change or improvement on the design
YG----> some typing errors corrected ;-)

<LI> Any work based on the design can be either made free under OpenIP licnese or protected by any other licnese.<BR>
Work based on the design means any work uses the OpenIP Licnesed core as a building black without changing anything on it with any other blocks to produce larger design.

There, i get worried. ok, i know, reality always catches you back, but this is a little pun
in the F-CPU philosophy, in a rather conservative/religious/GNU sense. I have nothing against
mixing chips from different makers with different licences, but the GOAL, damnit, the GOAL
is to have a FREE (in the spirit) platform. I see the work of OpenCores as valuable because it
helps transition from a proprietary model to a free one, but for the F-CPU i couldn't accept
that a free work would be spoilt by an obscure technology, even if the core is not modified.
Unless i read the things in the wrong sense ? please help me.

<LI> There is <b>NO WARRANTY</b> on the functionality or preformance of the design on the real hardware implementation.

In France, selling something without warranty is illegal, but F-CPU is safe because it doesn't sell
it :-) the distribution company is then in charge of respecting this law, ie change the device if
there's a flaw. the F-CPU group's goal is not to sell chips and make a business, but to design
new FREE architectures.


Ok, this rant is over, let's move to the other one :

> My comments are:
>
> --- Yann Guidon <whygee@f-cpu.org> wrote:
> > Prologue :
> > ----------
> >
> > Licences are usually intended to restrict the rights of the end user.
> > This F-CPU licence defines the terms under which the user is given
> > rights as well as responsibilities : the licence also defines duties
> > and the rules of the game for the Intellectual Property transfers
> > happening when developping the F-CPU.
> >
> > We stress on the point that each user and developper is part of a
> > community and what is good for the community is good for the
> > individual, and vice versa. This is why there is no notion of "customer"
> > and "reseller" in this document, but everybody is considered as an
> > individual who can be a "user" as well as a "developper" according to the
> > direction of the IP transfer (a "user" uses the IP developped
> > by the "developper").
> >
> >
> > Goal(s):
> > --------
> >
> > The goal of this licence is to protect the
> > Intellectual Property of the F-CPU project.
>
> I think this hw work need patent to protect it, your
> license is more or less like NDA.

well now i think i should rephrase it so it's smoother...
if we are smart enough we don't need patents.

> > This licence is also a "game rule" of the F-CPU community which
> > is composed of users and developpers. It defines the way people
> > interact at a general level.
well, something close to this....

> > What is in common with the GPL ?
> > --------------------------------
> >
> > The F-CPU licence differs from the GPL on certain aspects but one
> > can see a parallel between them. The GPL can be applied to a source
> > code, that is : a textual representation of a program and all the
> > derived works (compiled files, non-textual representations etc).
> >
> > The F-CPU licence specifies the terms and conditions of distribution
> > and development of the project's "Intellectual Property" (IP) which
> > is more general than a textual source feeding an EDA software suite.
> > The F-CPU IP consists of texts, source codes in various langages,
> > manuals, drawings, all the data that describe the CPU, its structure,
> > its behaviour and its interactions with other components. The IP
> > spans from high-level schematics and descriptions up to the
> > mask files (like GDSII) or equivalent files for Programmable Logic
> > Devices. This generalisation includes the principles and ideas behind
> > the architectures, all the necessary files in their respective formats
> > (including but not limited to : VHDL, Verilog, RTL, scripts, pictures,
> > texts, test vectors...).
>
> All these items are copyrightable, so you can use the
> GPL directly.

one point here. but the GNU GPL is aimed toward code,
what i wanted to point is that it is not only code here.

> > The scope of this licence stops when it comes to physical process-dependent
> > parameters that do not directly influence the performance
> > or the price of the final product. The thickness of the metal layers,
> > their chemical composition or the deposition details do not directly
> > influence the overall architecture in the general case. Otherwise, the
> > implementor must specify the critical parameters that were used to
> > fabricate the chip and modify the architecture, so the implementation
> > can be reproduced.
>
> I agree with you that there should be no restriction
> on the type of implementation but will you allow
> everyone to implement it?

why should we restrict anybody from making a F-CPU ?
Intel or Motorola can make one, if they want, as long as they respect
the licence. the more, the happier.
well i know no Microsoft software released under GPL, but we can
hope anyway ? :-) (IBM and others do it already...)

remember that the name is "freedom", we don't compete the usual way,
it's more like a cooperation and everyone should be judged on objective
things. If you don't respect the licence or its intent, then you are
banning yourself...

> > The general principle is that one can read the GPL and replace "software"
> > with "F-CPU Intellectual Property". A chip, a final product derived
> > from the IP or any material implementation is considered as a "distribution"
> > when compared to the software world. Hardware has a price, has fabrication,
> > transportation and marketing constraints but all the informations that
> > constitute the IP can be easily spread through electronic media. A
> > "distribution" also has the obvious constraint to be complete and
> > working, otherwise it is still considered as a "source" ans is freely shared.
> >
> > Like GPL'ed software, the IP files can be sold on a physical media
> > (that is : CD-ROM, diskette, magnetic tape or similar persistent medium)
> > under the condition that the same data are also available for free
> > download on the Internet (with ftp or http). This is consistent with the
> > fact that all IP is freely available without restriction (cf : the following
> > chapter).
> >
> >
> > Rights and duties :
> > -------------------
> >
> > - The distribution, modification and knowledge of the sources
> > (non physical forms of the IP, as opposed to the "implementation"
> > of this IP) must not be bound or restricted in ANY way.
>
> but what about selling it? he/she should not include
> the cost of R&D only the cost of implementaion like.
> In the software distribution you can sell them with no
> more than the cost of cdrom and packaging.

i don't get it here...

let's rephrase it. maybe the definitions weren't clear enough ?

fredom is also having some choice (no monopoly, you know ?)
and i would like to keep the "direct way", that you use when you want
to download the IP. no banners, no checkboxes, just click and download
if you have the right URL. So i don't want the F-CPUers to be restricted
because they haven't java, javascript, a FLASH plugin or a shit like that
on their computer.

When it becomes interesting, is when the business comes in : a company can
propose to sell a CDROM (see OC's CD) or a service around the IP, but
like with the GPL, the IP itself is not sold. BUT this is not a reason for
keeping the IP away from those who don't want to pay the service. ok ?

the IP is a different level than the chips themselves. In fact i guess that
i have not enough knowlege of the market's organisation, even though
i have lotsa hints. I'm a programmer, not an economist. selling chips
is not like selling SW. let's wait and see, but as long as you remain
in the legality, you can do whatever you want with the chips, light
you Xmas tree or decorate your table... Once a chip is fabbed, it's already
oldfashioned, so let's just garantee that the multiple lifes of these
stuffs are garanteed to be fun. particularly, having the garantee that you
can use it, even when it's not fabbed anymore, implies that the company
has a repository of the design files and the minimum SW tools.
This should allow a 20 or 30-y old machine to revive and be useful.
Did you know that the Concorde airplane still uses 30-y old components ?
there is no new equivalent to them. building for the future is like
giving a chance to the past.



> > In particular, you need not to be a customer of a F-CPU vendor in order
> > to access the sources of any F-CPU version or derived work.
> > Similarly, in-progress works must be available upon a single request.

i'll add that over-delaying is a sign of guilt ... but let's remain peaceful :-)


> ===========================
>
> The reason for this break from the GPL principle is simple : the F-CPU
> is not the property of an individual or a company, but belongs to
> everybody. Anybody must be able to examine, use or modify any version
> of any document because it is not the exclusive property of a person.
> If you have your kid in a kindergarten, you think it is normal to
> visit the location and see if your kid is safe or if nothing wrong
> happened. Same goes with software. Secrecy has no advantage in the
> F-CPU community and corresponds to a self-exclusion from the group.
>
> - Any implementation of the F-CPU IP must hold a written
> mention of the version and an Internet address (URL) where the original
> files are stored. This is meant to ensure that any user can easily use
> any F-CPU version or variation, simply looking at the chip's package.
>
> - All software created for simulating, developping and managing
> the F-CPU IP must be distributed under the terms of the GPL in order
> to promote and keep the openness and freedom of the project.
>
> - All documentations written about the F-CPU and the
> associated software must be distributed under the terms of the GFDL (GNU
> Free Documentation Licence).
>
> - The use and distribution of the F-CPU IP is allowed
> under the sole condition that you agree to and respect this F-CPU
> licence. You do not have to register yourself in a database,
> you do not need any authorization of any kind and you can do whatever
> you want with the F-CPU IP, except : changing the copyright notices,
> altering this licence or use it against its spirit.
>
> ==========================
> I liked these itmes specially that related to software and documentation license.

well the problem is to remain reasonable and legal, but still having garanties.
let's hope that some of the ideas i brought will have some success.

> Good work but do not forget the physical implementaion
thanks, and i hope that the thread won't die out...
even though i'm not a lawyer, i'm taking the
initiative to fight for my freedom, too ;-)
so forgive me if my texts are not as precise as a normal licence.
i'm being instinctive and spontaneous <blush>

> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA04436 for ; Thu, 15 Jun 2000 10:06:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 15 Jun 2000 10:06:51 +0200 (MEST) Received: (qmail 12895 invoked by uid 0); 14 Jun 2000 12:52:38 -0000 Received: from ck.egroups.com (208.50.144.69) by mx02.gmx.net with SMTP; 14 Jun 2000 12:52:38 -0000 X-eGroups-Return: sentto-1101623-332-960987102-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 14 Jun 2000 12:51:58 -0000 Received: (qmail 845 invoked from network); 14 Jun 2000 12:51:40 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 14 Jun 2000 12:51:40 -0000 Received: from unknown (HELO web1105.mail.yahoo.com) (128.11.23.125) by mta3 with SMTP; 14 Jun 2000 12:51:40 -0000 Message-ID: <20000614125140.14938.qmail@web1105.mail.yahoo.com> Received: from [199.203.98.250] by web1105.mail.yahoo.com; Wed, 14 Jun 2000 05:51:40 PDT To: f-cpu@egroups.com Cc: openip@opencores.org X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 14 Jun 2000 05:51:40 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6fc5c6d335d31995e2d4ec90fe67d5b5 Status: R X-Status: N |||||||||||||||||||||||||||||||||||||||||||||
Hi,
You have some good points and I have some comments for
you.
What I want is to make a generic protection schem for
all OpenHW designs.
|||||||||||||||||||||||||||||||||||||||||||||

Jamil Khatib wrote:

> I am going to update the OpenIPCore hardware license
> with some items from your license to make it more
> generic for OpenHW designs.
yo ! is it already fame or what ? ;-P

||||||||||||||||||||||||||||||||||||||||||||
The license still under development so that why we
should work together to get good protection schem "Not
only license"

Protection Vs. Freedom:
What I want to emphasize on is that want to make Free
Open HW design but we should not allow anyone to make
use of it to monopolize or to claim the design as its
own. We have to know who did this and that yet every
thing is open and free. we should not allow any one to
sell the design as a work that others did "even if he
contributed to it" he can get money on the expenses he

made for copying or implementation. "I am going to
elaborate on this later on this email"

|||||||||||||||||||||||||||||||||||||||||||
one remark anyway : i try to remain unafiliated with
OpenCores/OpenIPCores etc simply because i don't feel
that it's the way i see things. This is purely a
personal
opinion,

||||||||||||||||||||||||||||||||||||||||||
Do not worry
||||||||||||||||||||||||||||||||||||||||||

Part of it is that we slowly realize
that we don't need "that much" funding to get
something
cool working. Time is what's lacking (we all work or
study at the same time), not money.
||||||||||||||||||||||||||||||||||||||||||
You are right
||||||||||||||||||||||||||||||||||||||||||

My point (part of it) is that we don't need to open a
business,
||||||||||||||||||||||||||||||||||||||||||
Why not we can do it like Redhat!!!
||||||||||||||||||||||||||||||||||||||||||

just be organised and active is enough. We don't need
to be
"open" be "free" (in a sense, similar to the open vs
free war
in the SW branch). there is no war here, just claims
(mine at least)

On Opencores there are things that i don't really get.

OIPC/licgoals.shtml, License Objectives :

<li>Anyone can manufactor the hardware design
<li>Anyone can customize the hardware design for his
needs
<li>Anyone can transfer and modify the hardware
design.
<li>All changes and modifications should be made
public and availalbe
for anyone.
<li>The license should restrict the commercial income
of the hardware
products
<li>The license should be applied to new works and
derivative works

i don't get the sense and goal of the 5) : IF F-CPU
group is mainly in
charge of
the IP and its coherency, what would be the economical
advantage of limiting
the price of the chips ? it is not legal (i think) and
goes against the freedom of competition.

||||||||||||||||||||||||||||||||||||||||||
What I ment here is that no one should sell the design
as is "the same as in GPLed SW you can not sell it as
is".

You can distribute it with the cost of distribution
not cost of design time because it is not belong to
anyone.

You can Implement it but also you can get teh cost of
implementation not the design.
||||||||||||||||||||||||||||||||||||||||||

or:
OIPC/license.shtml

OpenIP Hardware License is divided into two licenses:
one a la GNU GPL
and one a la GNU LGPL.
YG----> In the f-cpu utopic world, meant to run any
GPL'd OS, i see no
reason to have a second weakened licence, or open to
proprietary vices. All the codes i write is under GPL
for a few years.

||||||||||||||||||||||||||||||||||||||||||
There Should be two kinds of protections a la GPL and
LGPL each one has its uses and it depends on the
design and the designer thats why Leon-II is LGPLed
because I think they want to allow porting for many
OS's to it.

In my openian first designs should be LGPLed because
we need more popularity.

Try to read the article about GPL vs LGPL and when to
use each on. You can find it in GNU.org or check a
link for it in OpenIPCore articles page.

||||||||||||||||||||||||||||||||||||||||||
Basic Licesne terms:
<li> Designs can be altered while keeping list of
modifications " the
same as in GNU "
<li> No money can be earned by selling the designs
them selves, but anyone can get money by selling the
implementation of the design, such as ICs based on
some
cores, Boards based on some schematics or Layouts, and
even GUI interfaces to text mode  drivers. " The same
as GPL SW"
<li> Any update to the design should be documented and
returned to the design.
YG----> i'm less enthusiastic for this third term : i
would place it as "recommended", not "obligatory",
because some projects (and particularly F-CPU) might
fork at one point or another.
This way, anybody can take a "lead" on one point,
instead of wasting his energy with version checking
etc...
||||||||||||||||||||||||||||||||||||||||||
Yes I agree with you only if this forked project
aknowledge the original source, but if he got the idea
then designed it in another way it will be new design,
which lead us to the Intelectual properties laws and
patents how to define such work.
Anyhow all suche forked designs should be Open Free
HW.

Regarding the term Foked projects, I think it is
similar to derived work based on the original design.

||||||||||||||||||||||||||||||||||||||||||
<LI> Any derivative work based on the IP should be
free under OpenIP
License.<br>
Derivative work means any update, change or
improvement on the design
<LI> Any work based on the design can be either made
free under OpenIP licnese or protected by any other
licnese.<BR>
Work based on the design means any work uses the
OpenIP Licnesed core as a building black without
changing anything on it with any other blocks to
produce larger design.

There, i get worried. ok, i know, reality always
catches you back, but this is a little pun
in the F-CPU philosophy, in a rather
conservative/religious/GNU sense.
I have nothing against
mixing chips from different makers with different
licences, but the GOAL, damnit, the GOAL
is to have a FREE (in the spirit) platform. I see the
work of OpenCores as valuable because it
helps transition from a proprietary model to a free
one, but for the F-CPU i couldn't accept
that a free work would be spoilt by an obscure
technology, even if the core is not modified.
Unless i read the things in the wrong sense ? please
help me.

|||||||||||||||||||||||||||||||||||||||||||||
This is why we shouold have different kind of
protection methods mainly a la GPL and LGPL.
|||||||||||||||||||||||||||||||||||||||||||||
<LI> There is <b>NO WARRANTY</b> on the functionality
or preformance of the design on the real hardware
implementation.

|||||||||||||||||||||||||||||||||||||||||||||
You are right we do not have any problem with the NO
WARRANTY on the design it self but teh implementation
shoould has
|||||||||||||||||||||||||||||||||||||||||||||
In France, selling something without warranty is
illegal, but F-CPU is
safe because it doesn't sell
it :-) the distribution company is then in charge of
respecting this
law, ie change the device if
there's a flaw.

Ok, this rant is over, let's move to the other one :

> My comments are:
>
> > Devices. This generalisation includes the
principles and ideas
behind
> > the architectures, all the necessary files in
their respective
formats
> > (including but not limited to : VHDL, Verilog,
RTL, scripts,
pictures,
> > texts, test vectors...).
>
> All these items are copyrightable, so you can use
the
> GPL directly.

one point here. but the GNU GPL is aimed toward code,
what i wanted to point is that it is not only code
here.

|||||||||||||||||||||||||||||||||||||||||||||
You are right
|||||||||||||||||||||||||||||||||||||||||||||
> > The scope of this licence stops when it comes to
physical
process-dependent
> > parameters that do not directly influence the
performance
> > or the price of the final product. The thickness
of the metal
layers,
> > their chemical composition or the deposition
details do not
directly
> > influence the overall architecture in the general
case. Otherwise,
the
> > implementor must specify the critical parameters
that were used to
> > fabricate the chip and modify the architecture, so
the
implementation
> > can be reproduced.
>
> I agree with you that there should be no restriction
> on the type of implementation but will you allow
> everyone to implement it?

why should we restrict anybody from making a F-CPU ?
Intel or Motorola can make one, if they want, as long
as they respect
the licence. the more, the happier.
well i know no Microsoft software released under GPL,
but we can
hope anyway ? :-) (IBM and others do it already...)

|||||||||||||||||||||||||||||||||||||||||||||
You are right I hope you got my point on the
implementation and the price of the Final HW that does
not include R&D cost because it is shared by many
designers all over the world.
Anyhow your license does not say anything on the
implementation, here we are talking about HW not SW
unless the target is Programmable logic devices.

|||||||||||||||||||||||||||||||||||||||||||||

remember that the name is "freedom", we don't compete
the usual way,
it's more like a cooperation and everyone should be
judged on objective
things. If you don't respect the licence or its
intent, then you are
banning yourself...

> > The general principle is that one can read the GPL
and replace
"software"
> > with "F-CPU Intellectual Property". A chip, a
final product derived
> > from the IP or any material implementation is
considered as a
"distribution"
> > when compared to the software world. Hardware has
a price, has
fabrication,
> > transportation and marketing constraints but all
the informations
that
> > constitute the IP can be easily spread through
electronic media. A
> > "distribution" also has the obvious constraint to
be complete and
> > working, otherwise it is still considered as a
"source" ans is
freely shared.
> >
> > Like GPL'ed software, the IP files can be sold on
a physical media
> > (that is : CD-ROM, diskette, magnetic tape or
similar persistent
medium)
> > under the condition that the same data are also
available for free
> > download on the Internet (with ftp or http). This
is consistent
with the
> > fact that all IP is freely available without
restriction (cf : the
following
> > chapter).
> >
> >
> > Rights and duties :
> > -------------------
> >
> > - The distribution, modification and knowledge of
the sources
> > (non physical forms of the IP, as opposed to the
"implementation"
> > of this IP) must not be bound or restricted in ANY
way.
>
> but what about selling it? he/she should not include
> the cost of R&D only the cost of implementaion like.
> In the software distribution you can sell them with
no
> more than the cost of cdrom and packaging.

i don't get it here...

|||||||||||||||||||||||||||||||||||||||||||||
I hope you got it now
|||||||||||||||||||||||||||||||||||||||||||||
let's rephrase it. maybe the definitions weren't clear
enough ?

fredom is also having some choice (no monopoly, you
know ?)
|||||||||||||||||||||||||||||||||||||||||||||
Thats the main point. but I am with design
monopolizing not monopolizing the design where the
design holds the monopoly because of its power not a
company that holds the monopoly because of its power.
|||||||||||||||||||||||||||||||||||||||||||||

When it becomes interesting, is when the business
comes in : a company can
propose to sell a CDROM (see OC's CD)

|||||||||||||||||||||||||||||||||||||||||||||
Are you talking about the OpenCores cdrom? OpenTech as
we call it. I hope it will help our concepts
|||||||||||||||||||||||||||||||||||||||||||||

or a service around the IP, but like with the GPL,
the IP itself is not sold. BUT this is not a reason
for
keeping the IP away from those who don't want to pay
the service. ok ?
|||||||||||||||||||||||||||||||||||||||||||||
Thats what I want, you are right.

|||||||||||||||||||||||||||||||||||||||||||||

> > In particular, you need not to be a customer of a
F-CPU vendor in
order
> > to access the sources of any F-CPU version or
derived work.
> > Similarly, in-progress works must be available
upon a single
request.

i'll add that over-delaying is a sign of guilt ... but
let's remain
peaceful :-)


|||||||||||||||||||||||||||||||||||||||||||||
Yes
|||||||||||||||||||||||||||||||||||||||||||||

> ===========================
>
> The reason for this break from the GPL principle is
simple : the
F-CPU
> is not the property of an individual or a company,
but belongs to
> everybody. Anybody must be able to examine, use or
modify any version
> of any document because it is not the exclusive
property of a person.
> If you have your kid in a kindergarten, you think it
is normal to
> visit the location and see if your kid is safe or if
nothing wrong
> happened. Same goes with software. Secrecy has no
advantage in the
> F-CPU community and corresponds to a self-exclusion
>from the group.
>


Jamil Khatib

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA03891 for ; Sat, 17 Jun 2000 01:56:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Jun 2000 01:56:28 +0200 (MEST) Received: (qmail 30022 invoked by uid 0); 16 Jun 2000 00:22:41 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 16 Jun 2000 00:22:41 -0000 X-eGroups-Return: sentto-1101623-333-961114952-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 16 Jun 2000 00:22:38 -0000 Received: (qmail 29412 invoked from network); 16 Jun 2000 00:22:26 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 16 Jun 2000 00:22:26 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 16 Jun 2000 00:22:26 -0000 Received: from f-cpu.org (Aubervilliers-4-187.club-internet.fr [195.36.145.187]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA00939 for ; Fri, 16 Jun 2000 02:18:43 +0200 (MET DST) Message-ID: <39497309.3A84A65E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000614125140.14938.qmail@web1105.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Jun 2000 02:21:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 55e066e7dc14d1d2dd6ec481eb2f95aa Status: R X-Status: N hello,

warning !!! personal, non-technical rant ahead !

Jamil Khatib wrote:
> |||||||||||||||||||||||||||||||||||||||||||||
> Hi,
> You have some good points and I have some comments for you.
> What I want is to make a generic protection schem for all OpenHW designs.

I think that if such a licence fitted to the F-CPU philosophy,
we could use it. otherwise, we'd still have to make our own
but that would isolate the F-CPU project ("yet another free licence...")
I think that it is also the group's responsibility to participate
and influence (lobby ?) the efforts in that domain :
we have to protect our freedom...

> Jamil Khatib wrote:
>
> The license still under development so that why we
> should work together to get good protection schem "Not
> only license"
so there is still a lot of work to do !

> Protection Vs. Freedom:
> What I want to emphasize on is that want to make Free
> Open HW design but we should not allow anyone to make
> use of it to monopolize or to claim the design as its
> own. We have to know who did this and that yet every
> thing is open and free. we should not allow any one to
> sell the design as a work that others did "even if he
> contributed to it" he can get money on the expenses he
> made for copying or implementation. "I am going to
> elaborate on this later on this email"

I agree with this and i think that most people here do.
it's what the GPL says. But what i've tried to add/point
in the past messages is that reality is less pink :
in practice there are several ways to interpret a text
and some companies do not hesitate to make their own
interpretations, for example : refusing to divulgate
a GPL'd code if you're not a customer of that product.
I don't want that, and some other things.


> My point (part of it) is that we don't need to open a
> business,
> ||||||||||||||||||||||||||||||||||||||||||
> Why not we can do it like Redhat!!!

read the goals of the F-CPU project : the goal is to
design, not to make an intercontinental company. get it ?
i think that the design and the distribution should
be separated. this doesn't meant that the people should, too,
but this independence should help a lot to avoid certain
pressures. Then if you make a company which goal is to
distribute F-CPUs and Open Hardware, i see no problem
if you hire me ;-)

you see, even if some companies like Mandrake PAY some
people to MAKE GPL'd software, FSF is NOT RedHat.
F-CPU's goal is not to make money.

> ||||||||||||||||||||||||||||||||||||||||||
> i don't get the sense and goal of the 5) : IF F-CPU
> group is mainly in charge of
> the IP and its coherency, what would be the economical
> advantage of limiting the price of the chips ? it is
> not legal (i think) and goes against the freedom of competition.
>
> ||||||||||||||||||||||||||||||||||||||||||
> What I ment here is that no one should sell the design
> as is "the same as in GPLed SW you can not sell it as is".
of course. but copyright does not extend to the HW you
fabricate. This means that we have no right to ask any control
over it. not counting the fact that once a chip is fabbed,
it is already oldfashioned ;-)

> You can distribute it with the cost of distribution
> not cost of design time because it is not belong to
> anyone.

yep, i know and it's what we all take for granted.
But as noted before, we have no right over the products
of the IP we make, so i restricted my rant on the IP itself.
it was not meant to be a licence as is, you have to
fill the holes with the classical GPL text :-)


> You can Implement it but also you can get teh cost of
> implementation not the design.
yep, but the cost for the customer depends a lot from
different factors, not much from the development.
"freshness" (if the kernel is recent), the devices that
are supported, the latest version of WSDFGHTY, etc,
all influence the price of a package, as we know.
that's the market's way. Once a newer product comes,
the last one's price drops. The licence goal is not
to rule this.

> ||||||||||||||||||||||||||||||||||||||||||
> There Should be two kinds of protections a la GPL and
> LGPL each one has its uses and it depends on the
> design and the designer thats why Leon-II is LGPLed
> because I think they want to allow porting for many
> OS's to it.

???
of course i understand the need for "Lesser" free licences,
but it's not a long-term view.

> In my openian first designs should be LGPLed because
> we need more popularity.

i don't think that popularity is that simple, and the F-CPU
doesn't run for popularity. do not forget that it's
difficult to change the licence of a product.
once it's under "LGPL", you have to rewrite everything
if you want it to become "GPL".

> Try to read the article about GPL vs LGPL and when to
> use each on. You can find it in GNU.org or check a
> link for it in OpenIPCore articles page.

i've read it already, and the F-CPU is in the GPL case.
i'd even stress that i would like some details in the GPL
to be changed.

> ||||||||||||||||||||||||||||||||||||||||||
> <li> Any update to the design should be documented and
> returned to the design.
> YG----> i'm less enthusiastic for this third term : i
> would place it as "recommended", not "obligatory",
> because some projects (and particularly F-CPU) might
> fork at one point or another.
> This way, anybody can take a "lead" on one point,
> instead of wasting his energy with version checking
> etc...
> ||||||||||||||||||||||||||||||||||||||||||
> Yes I agree with you only if this forked project
> aknowledge the original source, but if he got the idea
> then designed it in another way it will be new design,
> which lead us to the Intelectual properties laws and
> patents how to define such work.
> Anyhow all suche forked designs should be Open Free HW.
> Regarding the term Foked projects, I think it is
> similar to derived work based on the original design.
of course, so why bother ? :-)


> <LI> Any work based on the design can be either made
> free under OpenIP licnese or protected by any other
> licnese.<BR>
> Work based on the design means any work uses the
> OpenIP Licnesed core as a building black without
> changing anything on it with any other blocks to
> produce larger design.
>
> There, i get worried. ok, i know, reality always
> catches you back, but this is a little pun
> in the F-CPU philosophy, in a rather
> conservative/religious/GNU sense.
<snip>
> |||||||||||||||||||||||||||||||||||||||||||||
> This is why we shouold have different kind of
> protection methods mainly a la GPL and LGPL.

So what i quoted was a "weak" version ?



> why should we restrict anybody from making a F-CPU ?
> Intel or Motorola can make one, if they want, as long
> as they respect the licence. the more, the happier.
> well i know no Microsoft software released under GPL,
> but we can hope anyway ? :-) (IBM and others do it already...)
>
> |||||||||||||||||||||||||||||||||||||||||||||
> You are right I hope you got my point on the
> implementation and the price of the Final HW that does
> not include R&D cost because it is shared by many
> designers all over the world.
i thought it was already granted :-)

> Anyhow your license does not say anything on the
> implementation, here we are talking about HW not SW
> unless the target is Programmable logic devices.

i only talked about the IP and the text was not
complete. I had just thrown some points that
i thought crucial when one wants to adapt the GNU GPL
to the HW world.


> fredom is also having some choice (no monopoly, you
> know ?)
> |||||||||||||||||||||||||||||||||||||||||||||
> Thats the main point. but I am with design
> monopolizing not monopolizing the design where the
> design holds the monopoly because of its power not a
> company that holds the monopoly because of its power.

if you used punctuation, i would maybe understand :-)

> |||||||||||||||||||||||||||||||||||||||||||||
> When it becomes interesting, is when the business
> comes in : a company can
> propose to sell a CDROM (see OC's CD)
> |||||||||||||||||||||||||||||||||||||||||||||
> Are you talking about the OpenCores cdrom? OpenTech as
> we call it. I hope it will help our concepts
yep that's it, for example.

> |||||||||||||||||||||||||||||||||||||||||||||
>  or a service around the IP, but like with the GPL,
> the IP itself is not sold. BUT this is not a reason
> for keeping the IP away from those who don't want to pay
> the service. ok ?
> |||||||||||||||||||||||||||||||||||||||||||||
> Thats what I want, you are right.
So my point is that you have the right to sell a media
containing the IP, or sell a physical implementation
of the IP, but you don't have the right to restrict
anyone from accessing and using the IP. The GPL
allows some restrictions that some companies use
against the intention of the GPL.

> |||||||||||||||||||||||||||||||||||||||||||||
> > > In particular, you need not to be a customer of a F-CPU vendor in order
> > > to access the sources of any F-CPU version or derived work.
> > > Similarly, in-progress works must be available upon a single request.
> i'll add that over-delaying is a sign of guilt ... but
> let's remain peaceful :-)
> |||||||||||||||||||||||||||||||||||||||||||||
> Yes
> |||||||||||||||||||||||||||||||||||||||||||||
anyway, THAT is a point that is difficult to manage.
But in a sense, if the company is not sincere with its clients,
it will bankrupt in a "free world".

enough for tonight,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00297 for ; Sat, 17 Jun 2000 19:04:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Jun 2000 19:04:43 +0200 (MEST) Received: (qmail 27676 invoked by uid 0); 17 Jun 2000 06:09:05 -0000 Received: from mo.egroups.com (207.138.41.166) by mx5.rz2.gmx.net with SMTP; 17 Jun 2000 06:09:05 -0000 X-eGroups-Return: sentto-1101623-334-961222135-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 17 Jun 2000 06:08:58 -0000 Received: (qmail 10943 invoked from network); 17 Jun 2000 06:08:54 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 17 Jun 2000 06:08:54 -0000 Received: from unknown (HELO cap-pet1.capella.ca) (24.226.36.6) by mta3 with SMTP; 17 Jun 2000 06:08:53 -0000 Received: from hymy (ip92.dayton5.oh.pub-ip.psi.net [38.27.181.92]) by cap-pet1.capella.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NBAFNHQ3; Sat, 17 Jun 2000 02:11:26 -0400 To: cole64@koma.jaeri.go.jp Comments: Authenticated sender is Message-Id: <200006173296QAA11254@fghyjuki9o.capella.ca> X-eGroups-From: cole64@koma.jaeri.go.jp (Body Secrets) From: cole64@koma.jaeri.go.jp MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Reply-To: f-cpu@egroups.com Subject: [f-cpu] Body Secrets Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 17 Jun 00 06:09:06 GMT X-UIDL: bd605b0477482b4a5e11486e7faa1bd5 Status: R X-Status: N Congratulations!

We are pleased to forward this e-mail notification to inform you that a gift certificate has just been issued for you from Body Secrets. 
Your gift certificate, for the amount listed below, may be applied
towards the purchase our product at  Body Secrets.

Gift Certificate value:  50% off retail price.

To claim your gift certificate, visit the Body Secrets website. (click below)


click here >>> http://3463729345/00000.html



Body Secrets respects others right to privacy.  This gift certificate is given to an opt-in recipient and has been delivered via e-mail in compliance with state and federal laws. You may remove your name from our gift certificate account by sending an e-mail to the address below with the word remove in the subject.

toncan391@angelfire.com

666980822223269466701412
lO4
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00312 for ; Sat, 17 Jun 2000 19:04:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Jun 2000 19:04:46 +0200 (MEST) Received: (qmail 30434 invoked by uid 0); 17 Jun 2000 11:09:09 -0000 Received: from hh.egroups.com (208.50.144.88) by mx02.gmx.net with SMTP; 17 Jun 2000 11:09:09 -0000 X-eGroups-Return: sentto-1101623-335-961240146-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 17 Jun 2000 11:09:07 -0000 Received: (qmail 6582 invoked from network); 17 Jun 2000 11:09:05 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 17 Jun 2000 11:09:05 -0000 Received: from unknown (HELO square.inter.net.il) (192.116.202.83) by mta1 with SMTP; 17 Jun 2000 11:09:04 -0000 Received: (qmail 18955 invoked from network); 17 Jun 2000 11:07:43 -0000 Received: from unknown (HELO bizmove.com) (213.8.4.183) by square.inter.net.il with SMTP; 17 Jun 2000 11:07:43 -0000 To: Sender: "Meir Liraz" From: "Meir Liraz" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Jun 2000 14:07:56 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] New Resource For Investors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20000617110910.30442gmx1@mx08.gmx.net> X-UIDL: 06770284a57a8d9f6e8d86df557b2c46 Status: R X-Status: N Hi,

I would like to introduce our new site and kindly request
that you add StockAdvanced.com <http://www.stockadvanced.com>
to your Links/Resources page (or please forward this message
to the person who is responsible for maintaining your Web
site). This will provide your visitors with a very useful
and information packed resource. StockAdvanced.com allows
investors and analysts free access to vital stock market
information.

In recognition of its usefulness, StockAdvanced.com has been
awarded recently with the prestigious USA Today Hot Site award.

StockAdvanced.com features a unique tool that allows visitors to
enter a company symbol into a search form and obtain a customized
page covering more than 30 major information categories about
that specific company. The information includes: stock quotes,
stock performance, earnings estimates, stock valuation, company
performance, analyst opinions, broker reports, company profile,
and much much more.

Linking to InvestMove.com helps you to add value to your website
by presenting your visitors with a useful free investor resource.
Your visitors will find here all the tools and information needed
to make educated investment decisions, and it's all completely free.

In addition, links to relevant and popular sites are known to
increase a Web site's "popularity ranking" in some major search
engines. In other words, linking to http://www.StockAdvanced.com may
actually help increase your Web site's rank in certain search engines
that record this external link.

For your convenient here's a proposed text for the link:

Advanced Stock Information - stock research search engine featuring
stock quotes, news, analyst recommendations, stock picks, investor
resources and more.

Thank you in advance

Meir Liraz,
StockAdvanced.Com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA02056 for ; Thu, 22 Jun 2000 06:39:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Jun 2000 06:39:16 +0200 (MEST) Received: (qmail 23832 invoked by uid 0); 21 Jun 2000 09:12:46 -0000 Received: from fl.egroups.com (208.50.144.74) by mx02.gmx.net with SMTP; 21 Jun 2000 09:12:46 -0000 X-eGroups-Return: sentto-1101623-336-961578287-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 21 Jun 2000 09:04:50 -0000 Received: (qmail 32606 invoked from network); 21 Jun 2000 09:04:45 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 21 Jun 2000 09:04:45 -0000 Received: from unknown (HELO mail.bravo.net) (216.123.96.61) by mta3 with SMTP; 21 Jun 2000 09:04:44 -0000 Message-ID: <5960.72138@mail.bravo.net> X-eGroups-From: sadfsd27633@msn.com From: "sadfsd27633@msn.com" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Jun 2000 04:57:45 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] As featured on CNN!! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 350cdce59150db8e50d83d932dc25e8a Status: R X-Status: N Visit us today and win a trip  
As featured on CNN

Jenifer lopez is one of the
hottest stars in Hollywood.  And we have her NAKED!

CLICK HERE : http://www.freestation.com/al/msfhe45/index.html

Last chance to see the Pamela movie PART II

National Enquire voted this the #1 Hardcore site 30 weeks in a row.

FOR INSTANT ACCESS CLICK HERE
http://www.freestation.com/al/msfhe45/index.html
****************************************************************
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00449 for ; Sun, 25 Jun 2000 14:29:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 14:29:48 +0200 (MEST) Received: (qmail 4116 invoked by uid 0); 23 Jun 2000 11:31:37 -0000 Received: from mu.egroups.com (207.138.41.151) by mx02.gmx.net with SMTP; 23 Jun 2000 11:31:37 -0000 X-eGroups-Return: sentto-1101623-337-961759887-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 23 Jun 2000 12:31:40 -0000 Received: (qmail 31315 invoked from network); 23 Jun 2000 11:31:27 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 23 Jun 2000 11:31:27 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta3 with SMTP; 23 Jun 2000 11:31:26 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5NBVOB13977 for ; Fri, 23 Jun 2000 13:31:24 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5NBVOr23479 for ; Fri, 23 Jun 2000 13:31:24 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id NAA22283 for ; Fri, 23 Jun 2000 13:31:24 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id NAA04428 for ; Fri, 23 Jun 2000 13:29:57 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <39534A8A.95C506CC@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <8cht5u+ljfj@eGroups.com> <20300406150452.E2609@musistation.amazing.ch> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Jun 2000 13:31:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 64 bits processors, an article Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3cefcfb0b535cbd69ee7e8dd79a6cce7 Status: R X-Status: N http://www.realworldtech.com/page.cfm?ArticleID=RWT062000000000

It's an article about the state of art of 64 bits processors. Quite
interresting, with lots of numbers(1 millions transistors for the first
64 bits MIPS).

nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00452 for ; Sun, 25 Jun 2000 14:29:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 14:29:48 +0200 (MEST) Received: (qmail 7872 invoked by uid 0); 23 Jun 2000 13:42:28 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 23 Jun 2000 13:42:28 -0000 X-eGroups-Return: sentto-1101623-338-961767646-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 23 Jun 2000 13:42:22 -0000 Received: (qmail 15396 invoked from network); 23 Jun 2000 13:40:45 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 23 Jun 2000 13:40:45 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 23 Jun 2000 13:40:45 -0000 Received: from mime.up8.edu (Aubervilliers-4-161.club-internet.fr [195.36.145.161]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA26594 for ; Fri, 23 Jun 2000 15:40:43 +0200 (MET DST) Message-ID: <395368A4.5F6C11E3@mime.up8.edu> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8cht5u+ljfj@eGroups.com> <20300406150452.E2609@musistation.amazing.ch> <39534A8A.95C506CC@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Jun 2000 15:39:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 64 bits processors, an article Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 420120e110f3fa84f35862e3b19cbe02 Status: R X-Status: N hi,

Nicolas Boulay wrote:
>
> http://www.realworldtech.com/page.cfm?ArticleID=RWT062000000000
>
> It's an article about the state of art of 64 bits processors. Quite
> interresting, with lots of numbers(1 millions transistors for the first
> 64 bits MIPS).

it's written by Paul Demone, a well known poster on comp.arch.


> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00464 for ; Sun, 25 Jun 2000 14:29:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 14:29:51 +0200 (MEST) Received: (qmail 24387 invoked by uid 0); 23 Jun 2000 17:52:03 -0000 Received: from fk.egroups.com (208.50.144.73) by mx02.gmx.net with SMTP; 23 Jun 2000 17:52:03 -0000 X-eGroups-Return: sentto-1101623-339-961782715-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 23 Jun 2000 17:51:59 -0000 Received: (qmail 31085 invoked from network); 23 Jun 2000 17:51:53 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 23 Jun 2000 17:51:53 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 23 Jun 2000 17:51:52 -0000 Received: from f-cpu.org (Paris-Raspail-4-79.club-internet.fr [195.36.203.79]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA12563 for ; Fri, 23 Jun 2000 19:51:09 +0200 (MET DST) Message-ID: <3953A345.F8B99C10@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8cht5u+ljfj@eGroups.com> <20300406150452.E2609@musistation.amazing.ch> <39534A8A.95C506CC@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Jun 2000 19:49:57 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 64 bits processors, an article Content-Type: multipart/mixed; boundary="------------F6029D522968D373ACD40B56" X-UIDL: 239f5a6e045bec36daddf2ef2f4dbc1f Status: R X-Status: N --------------F6029D522968D373ACD40B56 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Nicolas Boulay wrote:
>
> http://www.realworldtech.com/page.cfm?ArticleID=RWT062000000000
>
> It's an article about the state of art of 64 bits processors. Quite
> interresting, with lots of numbers(1 millions transistors for the first
> 64 bits MIPS).
>
> nicO

ok i downloaded it.

i also delightfuly downloaded the Willamette description,
and let me tell you that THIS is going a tough chip to beat.
this is not a crap like IA64. aaarrgh. the pressure is increasing
on our shoulders.

read it. i've edited it for offline reading.
i've even "edited" the RISC article.

have fun,

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
--------------F6029D522968D373ACD40B56 Content-Type: application/x-zip-compressed; name="willamette.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="willamette.zip" UEsDBAoAAgAAAOJ91yhCz03+lxAAAJcQAAAXAAAAV2lsbGFtZXR0ZS1wdDItZmlnMy5naWZH SUY4OWE9AcIBkQAA////AAAAAAAAAAAALAAAAAA9AcIBAAL/hI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpdMWuC5CjSn1Jx0cq1kq9xubAsBS8Te srm0lUINTzVUDVjL33JE++DGr8/8vl1/BRfHFreXJRjIdohXmJjoB8mXxrg3aElICLaIablY GQnaNclZd3kpyEiaulkY6lo1OviYt3rXKZt6m8n52otke9dm21j5pqjXCKjoJuzr/AwdLT1N XW19jZ2tvc3d7f0NHi4+3nT4eTGszEGWS+6+ya6lwIpxnhDvzh3bgY8/FpZPXJpgp+oYW9AP oaGBjgb+CfhN07JczQ7ea0BmFqZZ/hpPQYx4kZenjQgxlrxXiuIyeh+1SRRJieQ8BuxePlJp ilfLbC9NjdQVUqaYjkRXqdq5jWEyZcFoAQLWbB7DQFSZHWuHFJu/JVuzRut6BKxXaGKHlB2L Nq3atWzbun0LN67cuePO0r1rwS7evRH08v1LE7DgDX4HDy5sGDDixHwXM8br+DHdyJLlUq4M 9zJmt5o3s+3sWS3o0EiFRSV92PRo1BBVs05s+jXj07IF066teDXufPZ2+y6tOrjw4cSLGz+e DgTy5cybO3+OvJfuLySmc7HeA7uL1dqndNfxPUp1kK/Cq+BO3pX5FOi9rbfx/kT7bvGdiBrv Xvr9EfWN//SX8R9/+NGn33UD6lMgBa55QNl8CJaHzkOENXhgUgkqKCFhDFbo0oVYSIiKIa1M JMtiDloIYV6nDdOQIxvdFKGA+aUoD07q/GRjjCIEaJaH/+TYES4ganBihzRiCKRMQt6EWJE8 +RhGbCSu1BQtVWbgZD3nfLIgPybw+AKYyhFZ04YwnaSTll9CydWEQ5npUWAZYrnmkd65WQw6 ToU4YlCkKDVlK+bsoqGd5awjpV+oiASjTkUBxdGLvdWonijQHUfnH6y8+VBUPTG5Uk6ZVmog niwhedSpNvkZJzxzjhqKmB+YuGU9cUI6E06P6kKQkOuw6YCUSOpmopxa7FnMlv/CXsXsUscM mpythvaF1QOTppkXh09OCxC2wVr7q4wEcguuKlTZgQhT11Ir7oOkHrvQo3QIFe6O6cWqI4jA GJWTY1leIysLemWElav91htCwD4ofF6+ukrKK6HS2jvju1hwuRC6JZ7brMOz3gsKw4VSPK7F d7aLosmHomykykz8a43IKMgM65gV41sqye7iDIu2WgGbBMzV0Fxnzyxv63KbR/9MbtA+Ayzd pVJPjSl/VF+NddbE/RYE0a9ynTMQXkOyri9je2vZ2dv12Fi0X7G9123SqK32GXK/LUTdZXQ5 jV2c5mrsjyhVle3XXy0797EooXlR2ay24zfjczc0dOH+X5cparmAZ/5t4JVDTZND0BJqjlVn Ye6oiBbdyHTMckbaiVWtKim4n7HIziXt1OgtXuigzn4Uvx8yfvufi1ebOOi5/m7wrbp3u3nx BSmE9jO8N3wSR4gcNArlqNo+5Ii5A/W5676fO3qvyFD5/eBDqb6os9ez17rYXhrOOd7md33/ 5S2Xbz83bS5/ydtfAP8yv5nBrTH1+0EC92NAB9pmd8HhgXDCsY88QW5QG8yQBhnlQY1BToRn atbtKri+EvbJJyRk4foumEIXmrCFGcxgC8O0NLMhzgo7nMsDreY2HPTQhzELohCNeMCVUdBx M7gbEYuYtx/CYDRStFoU65L/Q7DF5T9a66IXvwjGrA3vZNTRIvI8p7QympGAdmviGqsHnyzS 741V9FgL6gjAkLmRjmNU4hTfyEYzcBGQXqPiHteIR0r98QZd+t1TynYl6MFRjTxbJCMLxrEQ mkR8kjzjITuZxi+hLo6bFNU+AAeWeCgske1DQ62EeCZVdQp9KOyTU1gHSwnqTJTpCNiKHPnI 8NGjRQcjXw0KKUflJMoKsayW9HD1FN19kJTqCeNymLk8Z4YPmo7CVkqoCUolfEdYvsyeNnVl ke5J83mf1JwfeTnAJmKsIsm6jTEieRX1TamcTbNZPBuIP0paMJnyAdkkcdhPBYJMZKzsI0IR 6dBQ/j7UjA2t3US1iMxdro2PCS0oR5PWO4haVKIbFSlIsWfS7BC0aBRN4scAZM2YynSm1gRa 2Gx6UZIKkizgMZofKqrIsQBVch0l20rfWdR3RGKoEc0KUx93UksidafWW8tTA2rUAvqzD1cN Z2mWylPRgLWq2CQjV8Oalq4eVBJ9O+rL0ApXUyFRnDAkWy1bwjdLDVGQeW3nL/Zajr5yFbAl 5cpcA3tYLxD2HYk1bGP1qlavYumxQaPsdSwLDia+TLOKjWyY1MrZzvZUNp4lB023JtfTylRB qj2tS9f6tKa+Vbbi/AWAEEaFsjR0fv3xl2JbOVt2gbOwE/OpcHNrW4Ha/zG4xzXrQP8Z0po5 153THS1Uo1tc5NLWaWG57ciMK1nuNtevAsNtdUup3fF6V6rZPS8amUuE3pp3quh17yWhi1Lp 0ve9OuWfci0HXuruV5fsXW5/+Vvbka43pwBOr3oPTGAGB9W++BWvSiusUCL9drvJ9c+C2ztg DHd3xAVuMIWvm+AHlxi7Bk6xii0c3w+3GMYChu8OCPbfCYcYxTS2LlY9qmEIvrjDRZDvdx0c XiLXOMf5BbGNOxfg+pKXxSbe8Y89TGIJA/fJUuZyLnmcYf16mahjXpiMq1xmMF/MiU1eIHFn rOQl5yshaODwHdEVPzjBtssqWiyQh9w+VbI0xv7Gs/MKA5nkHzXqzVDGrUPkp5mMhqQngO7m kS+9YgQ32GDNm69/+wG/pYTom4iWs8fqGdotazqogAJU/4qMNk8YZJ8xubKpN62k6ej2pQ8D 3qtvfef8NY9PKqG0k9u7rz2jedXfUycuFi3mAH5KeMQ2l5oTHeg/WWfX/NghPaP56xujaZjU fvaQjA3nbBuzzoaGdYQ3+D7CxaaXdDhluscwT2akWtVkhrCZmdxuPROL33Hmc6bnGOT8Djzg bm60fQCuYF7qmuBZJvTBI+7va7v73xqP7Q096WJsb3zkjPadiCsObIYPuuHlxXcvN4zxZQe7 0lTGLGx1u0xMT5nZ//7gEW95jiiqefrMBpeHRODAQXwe+77X1Q7OWaQhfsZ8jKWTX66H/u4z 0lt9RhRLtIp1dF/NQXbhdriWXp66ICWc5MgbNieFLdsmUaTe/DrV2kXu8E11qtY67/eKcQxN aHe86FFCe79K0Rlu313v5Y7Mz8m8KREF0rfZZfzVE09xa8UrGVu3+73PPErmZRPufe+k5XGF eZWvfOnD9eayWETPTPpd9fuke+dBzvrBrz73z4XV6bDeZuDrHoi8xjvCi/v70h+/+MbPG+3Z TaZUU/6zhnw+x9ne8ruf2NYWv/Dwt8p7LE8d5c6HOM2xT3hqQWVgwu+9lq1//eajkvsnN/57 +rP//vGT//7otXfm+e9jJfd/6Ad0klNDsoZnykZ/JWZk2mdluJd324Q79BJ+AThz0RZyKec5 z8Q8/qd/4mZ+8udfH2iAEhg8b/d5stKAGNhjADhAHJhPFPh5ZZV/59d9Ipgm9hRqtFaB/7WC PchyLlh/GCZ3WVdqHmeDQViASwhyxbJ/wadjabaAs6cQo1SBKkh0A3iDGriFQvhnAgh/3peE I0iAyzeDSkiFT8h0Uwh+Z1h+JIiG8XeBQPiGY/hadQiGcBiH32eETPiFc+iGZIiDcoiHgChz LeiHd0iDELh7WriHbNiHigiFjliI9pdx7peHdiiJaSh+g+hWGv51iAXnhZtIiFQWhZfIiGXY ekf4iZzYiZ6IiSDIh3pGh4LIhY8oizUIi7FoiRk4itCni7eIiwpIipCIhI0Yhrz4i6VYjMio h5W4jGLIiz8YiM2Yil1oi/hXi9ZIjJHojWG2jd84i9LYi9TXWmy2Zue4WumojmGEU0iWVGcF insTV14RWaXlikqVVc6wSlFGj2SVVmPFj201jzBnNgSZMAJ5kGK1jwv5ZQ8IkVT1kFK4fWzF kD9Vjw7ZhhKpkUKlkO/IGx8Zj5MYXdP0aMxykjK0QjWkSTMUQyzpKz5hQy/pQTPpkjcpk/pC QzXZkivZkxGJim10kfI4kENpkUUZkP8NCZL6iJEAiRb3mJFfpZQjKRAiGVWFh456kmfRmJBT SZKGOCzdaCxMtG/HWJHGuIvVOIQO5XVreJTJyJXhyCqjloAdA2p1iSzBSF9zQAxXsn6EIyj6 th4Uog4RY5ixRoGzxoq0KJST9iyxQzuZFClbCY41owmkRhug1iiyVpYO+I/uQxKgYhOcJjHa aJl7V0xzWXdBQZlmyJEFQzo3JJn08h6EOUKGuZm3uSvpApa5VVecV28rIhWA6RpZ2YpVWJjE YEIZoSx8CZy3ZIqwIFitdDb42Ju+6WehM5zZKJWSYJyN+ZQ/9Z2vaY/i2ZlnaVp2ZZ1oWTLe GZU7AZVO6ZH/0deONWWQ88mCokiRTCmX5IieWOSZzkIiTheK+olXpYcxAhM591meASp2i9l+ 48iMB+qgfDJMirl1yck9qfSZ4VmhHjGbG5MqVweZgieh/tmdS+citzJt63R5iQVUNXGeWtVi K3p6LGppqEeJleh5BnWKt+BIQUKawOMpmihtibg7fZds+DR2GupqgtIxcWlB9jCj+hMsVvif V1SO7Xmlf+OPlcVG68l8GJGZDAqmcCSmjEmmRSpkUTaeLiF0kFWf1ZeUfSGcbaqXO5pZLkeE qyOOlVl2KWqJdHZoE/qV/bkzNcqeppmJankzM0alouOctrSSGVOaUqp8iJoyvKdB/5O5mktK m2T5cF1Zp1cIbjhSFaKHZya6lmb5ox/hhIHDEqiao7nJfQFCpx6KgZKHm9vDm0OqdsJ4nGn5 P4qaHMlSoi9Ed5UaKFvqmhHKn46aj874rJkaELGqpo36h4EKn9a6ZqMaggUakg6KiNFJrq2R WnOqNVN0V2eXnVVpG9MJL28Kr/FKr11qc4/aNvlahVVarAjEr/1qlADrr+Cmq6mxI2larZAB GgWLNIBkGZmhrs0BoG8xNgqbnw2KolzKGRvLsR1rgRh0F1IXrVvklukJGceEVxPLshO7cxBL lNoKsx1qrjPblDUrag5rsyp7qCq0s0Bpqtf4s9A4po12mf8IOLTcya2yem6klrRT6kVzJkxC +7TcKLW9BqFV67EIIz1Oq7UG2m3NSQkYixtiQra+YbZfe1NfoLNq+7JuW7LNCrf66jxzOy5Y ardwypx9Njg5S5wBm7cKKqwJqkIeGLg8FKbZQquwmbWHK7hoqrh8Z29t67jbeq8SU22Zc7av 0bCx6bOFWrlbGyO8qZLrFrq5aCaka5ONe7o4Cy8QEyo3AritC4y066O2u6m4yxPtqrtLdLm9 GzLvCrzVNLvDazfFa7x7g7zJK1rMqxWb67zRK73TS73Va73Xi73Zq73b2zfySiULx1qAOa3D G6zjRqrI94y625auyrRGSrvxNnp3z8JBE8GXyWZ1rwQTiLd509uiBou5iVl3oomZ+iK+nea8 /fs8U1GrI0qit2lthUa9CEx6OcrAgce4JZS5oGu8Elw8wAoxSFfBlNbBMcGq6jtP7pMxlrqc Jdqkzwma6gIVcsu9M0zDNWzDN4zDOazDO8zDPbxGBQAAO1BLAwQKAAIAAACpfdcoTlI168QI AADECAAAGQAAAFdpbGxhbWV0dGUtcGFydDEtZmlnMi5naWZHSUY4OWEmAcMAkQAA////AAAA AAAAAAAALAAAAAAmAcMAAAL/hI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6 zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvmMTqvX7Lb7DY+7AgFAXY4/ 1u/3vD+4Z9D3R9hDR1eYqLjoNzjICNlyOPkYaalSean5krkJhNiJRelZFGjnFRhKymOqStW6 SjQJtucaa3ibq0E524V4qssqeGA75Rjsc+yLUIwMo+x76JwsPc3Wa41tzcy9e6G9Bb09TDzB W00hrqW+3ecOwVduwS7aPS543gxMnm7PBT4ukz568NDdU6OPmcFCCUnx2tBQTL6Im959A1iQ XxaB/gcXREz1zd8XippGzQP2UaSViR33ZaiFAWMVji1VTiN5yR3OXaZQyXQG6mXPfvGWDe1Y lKhGCbCG9Pql1OXNfCeTplvIyVw3ijDv0azwUysmqkwTHB0rNeQikixXVBqoAGpGDk3Bhg2H NQJBj/x2ZjVrN69elCfR7G3wEKxNvBflil06crGDwwwo5yQrUbKJuzPPFh4ctwxnT3ULnuPk +cRTvy1LP/jqlrC3x7J5OmbMNrVp1h+tavU9GTPocn4te9RNG1Pt35AVBxY8WTNi6JVDJ7dT XDpf4HpHh3A9mPvulM3habdevsRbiOcBi48+w3tc6ohBcKU/P/ES+Wbx//OVF0N2zqU3nX/o pWVeGwMJZw5y+ek3Hn/ESIggU6fN9sR9BiKY0nvWWVTWPlzZ91lMJunB4HAxtceNh9UBSBt5 BPZ34Uuf5VZhdzkmCNiAOz5IIXa3qSjjj8fJl1RuG74Y1YguqpcijyvC2OCQ3Vn5Goswdmjk kVhG9+R2M6r331gQrqPlMGH2aBtOQebwyJcHmihngbw1xhZ2f2FYwy8aksNajCVqWOcIQfqp 1phldmlaooxutVw/PhbJJY4jUknkPCde9aaQIArqHHjBLakRpVUp6h6q/pg6qaN59oWniacU StyjNCqZJ62p2gqrqp7SBWyinwohqiyxalojmf+e6orSppKKyB6fv93n64TVTkjqnCpiquy1 LuHqrIXZLjtoua36SCezHwSVBGxlOcgksuFKyeqzvN7bn56n3mvcgTgCu+aqJaZLsLzqflsY vKEFvCypUW7rzcENo8JiW0rh6uiU0bIZG7e7/bNog/qO9HBw3gbrLbua4qtnoHOkiQ/LLduo Lb0X4dtvi9cWC+bJ6648MnM4R3qdxvwSbbNiDKu5M9KvMczHvDqGtDTTLEvsJdUpj/vrsfK6 au5VMX9d8H5cpyn102fDnDM+XLcdcsZ0Siv3wFmizbHRVTYU58Y00723xxDXXaDgcT/qrtqG i5D4dDUXvjNUbgI4Ocr+PDp8eLyL2+OwTgk1/mI1cLl9I9a9yuzB6EM/frjql0IbYt7wwT7c q6ifrnrFmZc57Oy6s45e7/WdLuXmlBuP+7PCX3nmqM3bmTaQSJYs/YYWJ7h8ZdTfGj33/F1v L/IcFp27+KC3Tr7Y1sb+u+zDu/8+zDXNT3/99t+Pf/76789///7/D8AACnCABCygAQ+IwAR+ YiIMbKADHwjBCEpwghSsoAUviMEMalCD8Cta+OyGLhB+MIQkLKEHT7gtAf1NbyJE4eBGCMMY so9wM1QhC004wxbmEIcvlGEPd5gcG9IQiC4sng5/iMQk3m2FAxPiEY3IQyj6UIpFpCIRr1j/ PCdGcYk3nCIXh6jELz5RjOFThS1CQR80yumMvstPG+fzRrd9SY2uoKMRHYGl9WhGj6QLmRql mL0KBbKOZoxjB43UiUEyqZC8+6LkPBYnPLbxkc3pW/w0tztEGtJqmFzfJotRRzLSLnOBTAuI EjknRtrEXaq8ZCZDuclZxfJHqFyjKAXnIFTOiI/L4yOBfMktS3bykLQ02Sd/acVEegiWrtSO LovJpl6m8o3ApFIrh7k4NjZzlMBDZiO3OSY0QjNr1Dxe3IR5zsehs5s70mYslfkTd5LScNec pzfBialTYnKdsuOnNWeZo2Umc6CzfGY9nbnId0JMn+nco78q2cE0/mqPOvBkJj7hSUWJYlMy GoVjCiWXRxph65Kiw4g/vQjQW2LRimHEZ0tdytKYTtJvYJRpSm8KU5W+dKM7ZedMAYfSnOKU pzYVqlGPmsmeikSLQSWqTovq1KEmVanyq+pSmFpFqfpUq8SE6lS9ulWk5g2rK32qWblqVZ+p da1kzSJNx4hW8UVVrF09a1zZKq0N6nWvfO2rX/8K2MDyVYGEzZ/LgFrYUsTnsIl9huk6sLbG Lpaxz5EsiiIrlMda1rGYxZNmNyuJ7hlKtKC1QbJSsL3S9glQlH2amlqrWhLAdouxvcFsm1rb +NDgtrn9zm57C4jfAvcHvC3rcGVQXKoe/1c5ul2uMJrrXB0kF6zRRa1wq4uD6doVu8xFLnez e93vhle8Y9AueT9x3nV11rU/g+x6jbk/8TTjPYw9rHxDJM74BnOllHWZ8OZL3ZvIw08gbVkt DCI630J2wFHTiYHJNdLb6eIpgKrVzGpTlP6mLsEYbpZsLFK1bHCuwh8mMYgz+zywmXjFJSax fo/nuQHDLsO4gHGECXNip9XPkkmyGo1fu9ZusRjHQ+6KeRnimAILibUPfvBnGZdkBy/Zw6CI WpPTi+Usa3nLXO6yl9OlzO8gWGH2kcmTFRJlAr/3DdKc4o/PrLy5hpN4Pb4FP1ub4yNfNayP 8c1Q9ByZFp2yyqBSIfRtcrwnIPfF0PkidDT3XMpIRHLGFdajyrAFt/ZaK8+cZLApOSxoOLO5 R+84saUhcxZAFxpWpv4QqrlZZzujmdOdHrKFdbyZWcsYWqc2JawRJmsL01jJkPK1ogF9jDeP 7NAuNqcyMt0Ik6DD0Nxhl1xK2hUWJGbaMEEUHK0cYTU3eM2kIYOq8UfmV0iYsKJG0ZffDe94 y3ve9K63/QoAADtQSwMECgACAAAAtn3XKAJaK66sEwAArBMAABkAAABXaWxsYW1ldHRlLXBh cnQxLWZpZzMuZ2lmR0lGODlhLgGQAZEAAP///wAAAAAAAAAAACwAAAAALgGQAQAC/4SPqcvt H6KctNqLs968+w9azwiE5kam6gqd7gvHcswuM1zn+nj3/g/07A5B0PCIlCCXzKYzGYEGnikl 9WqLYrfcbs46BHsR4rGzbE6rseha2/te6+Lyun1Fr2rX+Tup7xcoWLK3A0h1OKiQqNhoxsgA ySTZSOl4iVg4p/nIidlg+Sl6FErkCXc6Spaq2nrGqjclVxpoiaZJi+dG0SRrCPsHfJV7R+nr WxKpgqwbRrYk7PAWTbzL7Lp6/UfErVw1R5qg7UaKOxFbV50OHLU3dUxow11YYfCu5d6ObwrP yYxML9+xd6bm8RB4Lti4LupmCSP4rGAycfb2TYRoBd5Fe/4VOXLMSDHixpH9Om4E9GPdQleH /k18eU3jRZk0PXYbidOlyIQ6k2nkia4iL4UqsUWittNmzJsAIcLs1lPWz5s2lYZk+vRlVWnm WkZ70pDPw6w5F2E96RNqO48EpUKlqhUg27kfhZIMumhltqJG8+qNJ3CvOH33CncEs9YkYHyM DQu91VQwYIkov4Ky3Auzo7B9jebiTLSzZNGkN/09eDpT6k+gS4v6rBlabEWtXWOCvfpV7ku1 bW+ePTpNb4bAfffFzbf0cOOCkDvc/Rs6887OxUqnXSS79u0upCQnzT28+PH1yl03b5u8+vXZ vT+fDgd++uK/zsvfdp+cn+VZ7P/nl/YfC/65Z12AiBiI13fC0YfgVQ1eNmAYDH4x4YNaWThY haYpiOEXHfanoTUcftgMifyEKCCKCZpYookijIhKhBbKCN5HNKZ44zIqBphjjfvtiBqLHgoJ 13tGErkMklsdqQZ/zPUoGpR4ANmClPlZ6VktVHKFpXEXuFgekwt26duXJL4oZidkljkUmE72 B6OS2bwZ3ZZVxinniUQmZAed/ORZ5Zqv2XlnmoBmiKSfiBp6qESJainooo168+iPkY7GXpsK ZRoEG5wOqCghTX065adAeMopgU0GRKqOpqY0TKsSXvpnrQW6Cl9rila36qh4+pUrkLsyGKoY xVoWaqz/Ug4LKqFw2tprqcEu66yk9X13bG7JqobqnM0+Oyu21Vob5HS64lKkfuRSSKtd0I4p rbnCorukusGxK25qSqzEDrLjEkdtVIfFM7C7TrkbLpMoOUophPE+Oe8/fCY2UFozxUXsv9D2 0VPDR2mr8RbnduwWwm7p5Ct6Cvtzz4W2UjwOI9uCFbGDJZeMVkQpJ3wrwjq7/JRUGIEbGsQB 20zXVDdXxSu8786lTUk2eiIzfWj2TPOoGTVmmD52BaYy1m2cTJHUFn/8MDg4Ya0bo2k77fNb WZk9NLC4QgPpUcEQraaqcIv6sdA783JK1TJG1rLBh3elbxnM+t3302MYPslg/jnXHXaYgW7d btORx/150eHslNhjsm3n9t1ihwy46qPLffCNiGnKJU+sUoNzoTxHK3mMbxsSEtkWR+i4V11d pS8E64q4crutr7ih4l4rFrblB/Etk/IA3sv86s5TLu/RSa2Vj08DOQZ697ynnyGN4Bvd7ZwF CW/R0tzjmK/2QEcPvWsjO8iWfcEOgJ6bHKv01zbXsUl8RcrdVC4ksWZ974AIVEzpytU/5dRM JAN8oP169zsD7owrbxGaAnV3rb/s6H8bY8yJbMewAvoOhGYRlVNW8z61EayCk9jg+q7VvCTF ZR6wyKG99gfAHjLwb/z7YR48eLEMog14WRDMDSUY/78fNvFvTzRWxXDoL/tELWkDyx2+lJU6 KXLBi+47IZec8SyU2bB6CdTiGb3XCzc6jIoGWVvOIKfENIqOixUyXghLZL9E+lF9dWTiHZ3I OiM+EoaAm97udJMpQM6QfQA7JHgilkk6hi5bnowSKNmjyU7SUGRhnJYROkTKVWZxkPPR1odi Cbrple98Jrng82jpP2TdMpIUDF5O2lKXKN5vivATIoZw+csSIiaZpgOaJINpS1gSc4QlrGHs khhNFC6wRQ+C5tiSqTR01uuaGszmM7d5v3MExpKNsZsaqSNMbU6Qm6HDoJfy+c59LnONrQwf ORtkTnjq8ZPunJFCOUlQkP45D43OdKhAZUnRex4HoBbNV6pc9aoeHBRBCZXVpkI6g5EaqKQf jQVKU1rRcj50UjXkzTAvWjkeseamvxLQSneqz56q9ElADahQYyqfifKQpDNNwk9vw1NBDtVL Re2oVJGaq6rKFKd40ylUXYpKUYrwDE+1KVjXk8qIktWrZj0pWsXKTIzK9Rts3cxCWYlFpGZP nK+7klbfyLZH8mB7wOSjX79aWLXC1WPgjKtT61qJu85yi0tNl2P7eh+lEtaf/RRsZZHIN/OY NI+I5exYFyuP1ErWR2D56x7tyEgEftC0VD1Qafm6SSC69TFg1OwwfntbwO5FBGyk10A1mtGs 2v+2rbRVpMuyF5OMcdVcwGUubjv23LMsD39XPU517do/7C7FKvbULWwZSjt2pXc/bhSvX9wR 2tie9p+aM816i9FeAtZ0keGUb24XWI36Nie/HMyu3Lb7MM5Rik9VnGsrBGxf1m32uvrtIzUR 7Dq5aE+Fx8VniBhMmxPO7nz7GkrMpMtBDtMVoqb88MwY+1pHqk/DMKtkxQrG4hZnLbhUC1ki eqxhpdQNiiZ0MEt6JGEegvhxLrVWkJ07k9Lxs7at5XF5mHxWnz2ZjHQhb44H8VIOjOkDz7lB igc4N2pO2bXBtY7tOhdGBcvva8R1IW+NzF5V+HaOy2xTnTn2lSU39cH+o9jzDgcKxbII93rl lbGe2VwJVuxVYIum7Hy9C149SxoulI6xpf+bpRAfmV9Lbp9eZKhK1uZ51JsNMtMq7dk/qbC3 6anFRvl15lxf1r83/myjo4TfW7e6wK7+tXyxC+NdUycdOg5cMSHc4ebqrVZXVPaym8TQ7np6 nVwm3zqTvNbJtVPbuz6xGU82NnCHe43YJHd8XTLbP8bXfwyppbuNnea7XG7e9GbDOAPr319S ssSHjraHfdDM85YSr5UyKsC5+/BnRlXhq02uiybu6IVP9kwY72zAFSskQ6splJf0OCxvSnLz ZnylV2N5S1VucqZCm6Z5uzd9X0xza4Mc5er+zjm/d45yn99m0AEVudDxfLo99fzoBt9xyI3O 9P6C+pZRj/R0QRTmrIfU5T3Vute3ziOim/rrZCcP1wWJc6an3eIxR3rVMwP1Rq78y2/f+LS6 vvSjr51baKfSzP3dwHpF5+wRd/uKQVtlTidOhwwP+9XxnVPBf/dg/MWq0/8DTZ0/lmn9iIyN IOhqyjvw2YKjHtwJT3G6R/hnIDmJ1xLtZUXr27lIzjvfC6/6IUUQZ7zUN5+1RuOzRPdmnNn7 5VMv9cgXO9Ef7DR5awJBLrP97n3HEnS7TPvnDzEpZMm++SQPc+rjPvkEKp+NBSfPxVvkeSWe WEDkZ+fjZ1bsTa/+u/yTSn/D27/k4ke+8XP+f6dXfftnc6w2gASIfO1WfWXHgOKBenNnQw0o ge3heHg3gRfYKRVYgESFgEd1f1TXgRsYficXguM3fSRYghB4ghKXgip4eywSd3qXf+XUgi74 gQjVcjX4gjboSiCmgzeYajwXgwA4g44XgET4eBY1hEjogfNne2pXhA/4gzvYdjg4hUHIg4d1 hXY3dWOHgV8IhmKGWo1XO2Fohmf4d8hFhe+Fhm14hmlFhtu2hRrIf11Yf3OogHWIhT+HhwY1 hlx4h33YbHoIdHxIZZUECpaHeAk3gnsIeRwoZNPGaHmxVXAIiPpHaFSxEDiUiDiYV+P+ZwtF xn4FV0ZFZmfmR0BRsw+oOBmn6CiUN25/uIKG90Dmc2691Ee812WCRw8BpE5RxHzkJ2yyuIYY pj+6SBbaNzXIWGqdGH3LqIwk0XqM+GmOaIyExYycdmCid2AVFntBgzzKiGx52IiF+IgbJmW4 qDPEVz9f82rWk29Sw45RNnv9V43meI0k1HvfR4lfRD1Shmzo00uEcWgAaYsDuYQQV45xqHmb N2GCGEjECISYOFgVCZFyF2t2SJGwlo8XWXG4pZG555GegWIHOJL494n+54YraYaWOIu8xZIx 2YAuWYzeIpM3+XU0OZHM9nYJWZP4GGxV55M7eYk8KZQdV4X/s1B3Q4mRlwZmS4mUTjlgPRmV IamUVBlUIqhE9wUoOYh5URgjXJknXnklYBmWT8gaPkiHCShCR1gnTJl0Wgl3cAkpdKmTTdkn bskbaMmQScmWcqKXRPmSYgGVWWmC2IaVDgeKOGlujJly99iXbBiTzuaY6nGXAliGk4l1lWl2 EomXgVhohcOX5AiZRSmMHtaQPVmSi2mXtHWaqpmSEBiYCgmaTOiZmCmHMHlnp2dGrhkKs1lN i0ibGWmNiKZdhxOJh1QKp/aUMJEjqAaUNDRG4DdSuzENxcGcU9lYC5lY0QlRDhR4ohiBerI2 RSSaYvQM9VSQlHQ26AR8egJd/gGd/5GJYQzmg62HjEyRjbm5nNTWbR10PL6HMtAnRqupkri2 fQs2jSQjZJJ2nnAkjgtaTdP5e9roZWr5kRxplXRAoao1fPuVnxran8K3JNNUYN8YTtAnnK6p cYPJoarlobuINPmmbCOqfe1oTNaEZjEajcSZoZ8JQsVjbq9on1zDivP2m/VEcDvkZ6UnGQjh K+3HMD6qhkT5JsUWl+cIeNR5eHAWm0l5pSeqScUipvbipZcZkRqKKlBynROFoerVhKn5kyKp aUNag/NpmsCpR3qKDXjqooxJmZzpgKL1mJvJkoEqqNwhBS+HqG7YqIlKgbPCqCdJqW3GB7a2 avERaqJWDP+apW6RYpdGNzPbQqrOoqdrV6oS9qZWmaV1CmarGlFumiywejpMKZYjt0/Mki12 cqvNQatn6aW6uk28+quWMqppqBq9iknFOpe1QZavqqwi44sL8nnUyo/CUa3AtXhfJZ59op3e mqn1tqnNGa5XGZSa2qeZdq5GCa7iNq7f2q7xyq7imq6Rhanraq7oyhLQGq1byay1+q8A63fI Cq952a/+SidmMmbOSrD3Wpc+drAIqxLEeqrYsasQG7D+CjCjuV/GKquqOqvLkbHyaimdCrJJ xh98KqrglqomK5Wvoa7r8CMOS6/7aq/lKrDagVns9q6EGlaSCVNupaheKAOP+gL/BSuphQqT QYsa4wG0RWuoUIuz9TGpSyu1LIqRGfi0NECzt5mmHYm1YFtyAfagrUqyhEifZEtroKa2chq2 7vq1jta2VTq2hVS2aLpcZhs39XVlLGOnOpmyfhu3G/maNTumEmN662dNdyuRgfuhekunbiut uJmeuQiOMto7c7u1p/Jrmiu2aoqtlGthQ2M2pJi5dtuYqNO5qCu5oPsIeEk/ULMVm8i4dei0 q7s4f+u1eTumvxi7UxpPrGuI/AcZudu6uYmYgyu7d7Gf+Oa5tRleggu5hfu2+tq70ViLi6u7 trsl6fa4h2u8XUu89WNiupmitRuBhYG+kdte0ts+S+u8/wH6Qqq4Z7IjdueEfUjavUDWuWj2 vevSof97ttx5gvjLfdvVG97bv8kmdbcAo6BXv0CatlRzofobM06mnpJTvA9sWQ3sDw8cQUhL wMXovSRWo4XTsQmqwe4Ljx3cpin8jIQLodNrjfi7V/E7RgF5ogpcn9v5wuAkXj1nv0lowB3M Puekww3Evz1cph48Xt7Ivutmie5npLO2vSUKkja8wzu8xPcyafz5wd0owPM6hrWoomD8vxy6 vvYJosa2we8bvNvbt2qJc0OsZBwsosK7wCiKpTwMvQisx/iKtgb2M74ZyF58wO05xucbvlpK t1tKw6vQwr/6w+C7KO03YvQbWv/PS7h1LMFbjLkWrLzUG2tvbMmR/Lqi64zaVVicHMXAZMpw 5cqXqsrcd8antr4ZmcBd3Mm5/HGpPMrkyWfpa8iN/LnDycijPMvJi8pcOMu7rMnHfMLGPMCl WcCHLMNRm17PjM35irenDM7KkgGO3MrdTMvBjI/cbH0aMLzlTM1kPMjX/M6vXL29fMXWbLi7 G87cu84SpczmzMzfLMvmDM0t6s7oDMw5a5najAMMDStnxbQ2GdHwTLVKm74TbbVaK7RXK9Ec TdER9rNEy7Wb+9AbPdIi3dBTW6krfUQsbV08W68uDWm8+2gyPXRrorI2fdMvO9M6XWZh2bM+ bbIUy7H/2ynUbtYlEVvNR72wA6vU3szUV7mtVTbVPR3VCZ3PhXbVIvxdmbjVggzJXv3VH03T Wj3WS514NnvWTW0lz3qza92WDPvU5wzXcb2xcNmaEDnXIIXXdT1mQB3Tfs2qAk3Xgu2dCP3W hg3T1lvTip3VYd3YCg2pkx3SaI0jlI3ZFh3QPpvZnR0eXE2ljl1zKh3aou2y4jvCpi2XOxvP qr3aM0zYrm2ajN3asp2FXa3Ptj3bj43Pus3Tm13bvl2coYvYwv3bxN3MFltcUmqT1qAOeX3C WJ3b+RqMbZxsWEohfvhC0h3cNOte1o3HMQzbeejWUjzdhf3dMxre48h+KaN+jHn9Up+c2Ont LYYKxf6bNL9LkiTGp9Isr/StiatMbBw8jVYxsqe93dn2rgD+jutdNvBVyAID3R4ci4H9xO+I 3bxYpt6ni73pqk6436Y8x5Lwd7eDkDY2iPZo3HFqgCuO4Cru4n+53zH+4tpN44c5jDeO4zOu 4zvep54N5IOKkkFO5EVQlkWO5CXNHAUAADtQSwMECgACAAAAuX3XKEtj9a1JCgAASQoAABkA AABXaWxsYW1ldHRlLXBhcnQxLWZpZzQuZ2lmR0lGODlhPgEBAZEAAP///4CAgAAAAAAAACwA AAAAPgEBAQAC/4SPqcvtD6OctNqLs968+w+G4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofE ovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r1+y2+w2Py+f0uv2Oz+v3/L7/Dxgo OEhYaHiImKi4yNjo+AgZKQkjUDl5+SFwoInZmcEJAOo5OgFqSorqULnKmuqqILr5Oktb2xBr gNuia1vG+vsC3Kumy2tiPMxgiTwoyjysyfnc99uafBuam1jMszxnveW8Fq1dN91Ubbkr3Z3t DuK9lK6udV4ivgOe6W7fDsuIjwu5d1D6MQnIQh8OhB4UKqkmUJrBDgxpzDvm5JQXev4rLuqY WEFYFJBJ1HFUQTJGSmVTRNZDsNKKS4owM17blS2mMocNB94M6TPHQJ0JiD4Y6sLokHg42eUL pVSW1BBI73l86TQhv40zM606kTVqkKrrTsILaqOiCLEsp9b72nIr0HJFIKJQ+xIlW5ZZS9W8 N0JjCp5XugKGuhcm3JB/zy4+XCgxBMEkdBLWQC6x4cposeANPHWv2Rtk4SWV+/by2qurPz3e NxpJac+N7y6QnGviZ5qBO1uN/VMW8KO1e75uiLpj8Fsrd1/Ara3vMdU/ne8cjsF69uOVl6vK TX0y1c2mbbutshg6LHqStYO3u++8ce5e0+WVD7Zo9+e3jf9QBv0PbQEO1t9axVnAFlMYNVMg gQM6Rt9trNEk3Xzq5UZXYQ2ap5+B+LXVIWwZxqfVh1LEcmFxKX4UoX8Hohdeby1iFqN4kNXH 3l0zPoEdWOqhSCNuYgFJkB8rgnijiapU6Np/HBRzZDgb5vfgk1NO5htmm/SIoIRWbRmlShNO Zx+JL+6kJH8jmpnmBoKFGcyVSa6pZZVYmoQcXVFxA5mTccnw45ilcBnBPEOGuJ+fLcG5JZWI qmmlnU/W6KYzjHqHaaaabsppp80YWuZ4oJL30KikimlqqqoCYdChFFy6n18L4dQDSErZyiOk FsX5VHa86VrSJzVcCiuSwHZZZ7D/yVIyQ7GP+gqtm8pKy+yuw7Ipwa1HaHtaWtZiS1x5S1FF K2mANjuGs9R6ym677r4Lb7zyzktvvfa2q2q++u7Lb7/+/gtwwAIPTHDBCa4bbcLHMrbswq8i 7LCsCv86McPCNozsxRpX/DDGFke8MciFQpwxxxKbnC3JH4scrrgoj+xxxyGXzHLLL9s4s8zg 6lzzdzGf3DM2P6c8NMw304z0yknzvDTQTROdM9NKS61ym8bMeDV2zyDD9XDMeH0d2NfZXJTW U3LH55lpgydp1VDhHCLXIMq9pM/Gymn13HbHvXdjdCvmt50nxYYLR/8dLHTfeNP57JnRKd4o 2Y5PXmTb/ooyfnnlBDm5NuZ4E+ly25RrnubX3/19d+M5mQ6541l+mPnanF/JS+fnIZ666qXX 3XpyoitZO5O790662sBvOLvgqduO++LDJw695cdLbjzj1hdv4uvWqya7fMwvT7uHuU++NdyW k1d+9KERn/6AqDuveUCFhy/n/L+j3H6A7zuf//2su88+861PfaPr3pq+V78OgW5niKEeYsS2 HrM5EHM9ytr/7rc9Ca7HaGBSDPMMN5rCsUchzQva+KB2NOJx0ITwE+DUqJatAMhwhjSsoQxX +DQcvtBpO0QhCzE4QR/mMIgKCIAOYSjEHh6Rh0hcYhKb6EIoqjABRowiE6/4/0QsOnGLVsyi F7lIxDAioIpinGIZCShFM6oRjVrsIhjX2MIxvpGNX3SjHc94wjnm8Y5wjCMdi6hHP/6Rj4PE oyD3aEgg9lGRiDwAGZdksEhKcpKUrKQlL2lJCjzyXoTYJCcF4clPAiKUovQDKUvJh1OiUg+q XCUeWulKO8AylnSYJS3lYMtbwiGXunQDL3vJhl8CUw3CHCYaimlMMyAzmWRYJjPF4MxngiGa 0vQCNavJhWtiUwva3CYWuulNK4CzCTYspznPic50qnOd7GynO98Jz3jKc57jZEI9wymFe+IT CvrcpxP66U97BjSYA10DQAuKhIMi1AgKXSgRGupQIf5AlFXqytREfyCRiv7koj7InDQ5WqsB yiQQIO2GoA4SuT+UtFe6KxX28rDSOuZBeDBl0Y7oYCiSCiUyh4xDTJEUJo0G56cehI9y2rQt mtb0WozEEaEQpL0bCZWcaXAPY5Qaq5fKUihYDVZXZTRVqs4Kqa1pz02vQdQHBdV31UxrBOE0 mzxd70thFWhVz/qqUCnnq7XcKVnrgi6+zsGt76GUmX4UDLwO1q+JNapTi1VXJRC2kaEDkFY5 o1if2vSpXnkbh47ayZ1GNVGXhWpm5VrasqV2C5N93GqRM9oUMsez2Trp6eZqzY/Qdh27NVdO eKgbto6hte+hAp66FFuwEv+Tsa8Vn8tsFQ17pEe2XyCuVSPlWNQeaYGDaoN1RfpZzZy2SFyy XW0NylW9kgEuXTVvd4/J3L9GKqXe+q1W3Xu6yM6AuBY57pCSq0DhVgm63uVqb1Hi2j0J+CiZ ka5ha6NfGHzXviWKq5YES1nsniq3swLweFa3Gs4Wda3yzQJ/lxFhlVC4RAQNaVI8rLPgYhi3 NkuxCwib0fFKa8bnPfDIRJwh3Wy4CxOmMbl4/F63MefBm0sDf/sL5B4/Nacfs3ERWjvkzx4W uGWJ8jd9W2LLZrUsK7NyC3Dc00p5FKqM9DKY1owfM68AzU1dl459xl5ZnfZNXIYvU1tKLiNn DM7+eoIUoePn5PoCWlyHNtqh+Qy1R6f5Cji2bYizGyRMhy3LD+Q0lc9A50WDS8FtFiR+JSVn FTw5oi9YNavP/Opmxnq4zdIXWFPV1nOlsY2iXmVMcYVaXqNypSkhSrGZWdKYKFvJvu4Wsxc5 6XlxlFtK3LW9LuoqYWu7XhOF7KwB+e1phlvc4+ZwubN5biKnG93r5uatMQnveMsb3tAU8w97 XUhojy6R+I72P+09RH7vW99h7re/m8tPgFdb4AUfeL4fnuE6R+Geyy4aISMucYNnvOH/zsAN N85xQWNc4yR3+MhDblcM0LDkKK941LZ9cISjfAnOLCedUBTCz6E6gjv+32DjLHWczqHtbDkv G9BBTk56nlOEgXtWCO0HONUxXeo+L7TT5Sc4rD9KI4eDqQ1vfrfvQV1FtTsbAc1rwMqlfewB HlGqc7DyF6E9fGwHe8+jM/e7qwjRavWe0Lr+ylB+MIF/qTvpDG+pAxL+59Lru+IbBHhAuBfx TZd72JHnd+Ut3rWML2rj38Fdaui884UN/eH1njyngw+8dic9hG8niMnr/UB5d33qab96q1ue 6m2P/B9EaIqhG51+Huwg7UD4wc8Av/hZD370RBL02D+b4SKPucupi3Q2XP/eJrf+9Akuczds P+DgD3/1s98c6Vuc+uZv//gXDnE5vN/a3l8nf/nTH4j5wxz9348/0t8+Fv13ci0ngPWHfXEw bwmogAtIMO0GBgUAADtQSwMECgACAAAA033XKMvnV5V/DgAAfw4AABcAAABXaWxsYW1ldHRl LXB0Mi1maWcxLmdpZkdJRjg5YUEBMQGRAAD/////AABmZjMAAAAsAAAAAEEBMQEAAv+Ej6nL 7Q+jnLRaG7Let/sPhuJIluYpaY6Ktu4Lx/IssmlG5/rO9/6B8wR/xKLxiAQERsuk8wmNdoa1 pvSKzSatJq72Cw63vF2x+YzGxMjpttvMRsXf9LpzLrfr90f8mA8YSOPnQih4iEhhWJjY6Fix +BL5SBk4KVn5NLDJ2en5CRoqOkpaanqK+hmQykrB+mqauTAgy9hCO0F7SYJbe9DrS7LrSqzE A+yLHBwynFvcDKIsK708BUPN0AvtgU3ZXT2xLfGdACxuQd6YDv5wDrFuYK4Df0jPruD+Xhzv yZsNbu8egnwP6CEDFnAWtYR8GN4jWHBfPCsOy/2rVrEaxIj+zhDoivcLAK5NIUn+MknLZEiM AtXMMFiu08mRIDmBFHkTpUeALRXlgLnTWC+EOnNavIk0WMZgGznGVHbQwJKhK2kaDYpz5bKl tZo6FSlTQVSpVK+WtVo2aTIoNkNwXeDVwchPszz24zeUbluUJNtm3RqFq8oSceW2alBYba23 J94yHrgjb9ijDBL/VRq4gd/Be8Ge/GD5ol1p3xI/TnPaX92saHPStHoh9GqxUNu9SH0Gt4iF tGEjTenX5TyJcG/zZDtTbWusKUHInh2BXGHdYqhHu7h8OU7fPo8RL37ruJPgdkfPxQsWuLUe QPEONsRdrvie4L131Krt3bfaLOn/17c/DmXyfAWdYtP4919kxJ31F2fNNdjXYJethWACz4kW 3VNzDdBEduqxpph1YIhox4UY6oPVSlN1ZhZlWmFWIRBEtBeiVBMyeKNY81VoYoEE8jeVWX21 iNCO/vXoo3zJLbliecCdx4+LFMaIpI73RbARiVpo+UaVUhJoWwlcYjFmGl5+qWQ4YhrZ05kp oqimaoBRaQSNWK7ZH4JuvgkmBASVKQWgcBxh550jCMoWLIouymijm6ziaKQGSbpojG28tacO mVpaBKaUbMrpD54+Amqo7NWQSammDsdMqqse2Golqr76Eqqy0lrJUrMOgquoY+raVa+i9tkB sLLsaul+/3IKEayw7PGVnk3QouMcU87alx1rDmWELK/XsvpaSdImxK213/70G1VjVVCuL91W yJmTk0X3WkLvenvuqWLeJZy7+R6TGl2xafSvHfNCQnDBdBzcnbkKu8FwCuzc+/A4DlGMb8Vo SNjwMhhrbEvCwlJKcsmvQGpypJpei6gU7wr6caACvbxDzJk9JPPKI8+ccw42I4fzzT4723IU NOvcq4j8BQQKmpqFdC+iP493TUzFJpVONyThUbSBa+zswoMvFrPu0/JxPSMPUydhndhXudec StylNW64VK3imWebASo12CiktR3d6dU0NpQefghWkDiCSEPfSYc9L2yLi70ulP6/4SdUg+ly bFzNfptQOdZyl1T4i0VpPhHhbyPa8tqEhsfc5QIWaTqRqIvUobZxM16r2o83JneEYfVT90zB FR8l8koEr+1n6PqOa9e1e35F67+nPfYMFFsfPaHkZQw09bRKj8T2Pbhe58Rknn+9wz2Lvyr5 RmBcNPozpox//hzqT6kP9l8aPonFQH4DA5nZqNaxsKHhf6gJoKGqdgYGbsyBfpIBAftlQKdh L04QHFQGk9QphA1wgR8E4QYf2EEPljB76eNgCsUgQVdIKF6dQ6AAR0hCR5yFadfRRAIVmEN1 VOUCGbkgn1bQuwjWQz2dcZDemCgTxMGJbT+EnRLrAf8iwwUlQlt0W4Z86MIaqlAQkrsd4z4k OXgYkYWISeIYAbE71V0mW7ybUJqoGEYgXjEQXNwbUaIYvHHppybk0wnn8HGber0RZE2rE79s lCDgRSwLMfyCwDr1SGNEEiKXDEMltzTJZ3GODV5oSiix8ElQHlKU0iClhSS5xjwa8JSR+R4k ZQQZWJpphVEaDzZK+cq/xbKKjIzlKjV5S2QCrw2p1BgXnqmnV/EvFgrRH8quactoTTMURGgm DvVlpZBZIXcmtGA3pTmscjIBkhQ5Eav8h04f8AYGTagnG7smPW++UIYHUaM7czFDZSxhoEe0 I0D7eSXomYohgvuO1+AEOMj+EPSeV5NdQuHHKYYOkV3//GId8UEFg4oUog89IPviZ7G8PUiK UywobVSaRWrYwGvr4OJ2COnQoaE0QLSDaYDUuZOeni6YBfWnUONjUrXpU48evakZiUWjlbKR DPP8qeoiekel7tSq6mIjCNvTVa9RtaOiCetIw8m+pf7NGWXEalK9qqO2ThWtLo3r5dxKVu0p M0Y1RWMgc9pXlf61MnSFq7zQg1iranWvCMJnXsvgNMf6z54ZTWdhQ0ZRecJznJXVLFCFcdmz ftNznE2WZTV4grF+lqk6hSZfT1tXyBYVtt5yLbxoW1LZZhacOt2rWg8Ft4occ7baFG4rQyuZ bKb/tKV6TSZjWwI44So2dobtk2rR2lMiNrW5zn3uPSK6reliLrZZ7W5Vc1RRYmECl7n0D3h7 Obj46g2+Q6Jp6fIW3701jyxPnV5VJJPY+jIPqetlb3t78t5wOdWpAnaefZWTRTmuVKrLy26K oqJgyjUvjdXV7XN/28McRTF26tpMZEs3YsyV2CR4Iy6EU3xXcY2uw6AlaqgSfGHSyfG+4cRw jiU8oRbvVsQ/XrAX53jOrdIuw5oL63tns+SrNlnHuBDyg7FmFAUbmXcWxqhpi1se+gbSpvIV 6YaOl5claRO/kHJxJ5kXYECqOZ/x5C15a+xiAJ10obgVLWGQ22fwfdnO/jS2VZ4V9AMQw3Kb jezNNlE2SUaPIsm8HCY8LjRMWc6Sgm104yIzaGlNr3WXvPSznsNkTlJXmtOdHi0MS51bQiMx 1XtcNRhvuE8wKPrWeMS1GF9NRuG10IYo/LUnEYFXRBO7grT+tB6S/c5eF5u1x8bi5qIFXytK m9murjYZN8pgLYVa1KBTNR/BLdXhuoXVhG02sL+9ujPmOoTkxlOt+eigDeEXdIq8H065Lcx/ e3tKicykPA3ebsjR0mhbUfduEA6whXeX3xJ/wq69p9yI08MyFb8DrDtuwYwjsuCZRvUKQT5A kdtYmA63OKz37T0RJjKIlTamPULTcpe/vA4X/l8Pu+qLpppmQdJEhwWki54KeHI026t18Pv8 tb49T1dZS68eOOin9IuSTt9znJapT+g+dtOTWtXEr+WY/PVA38rqCtW6RRu6pJIXGhHma/vU x3u7KKfdsyITGtL2IdStD1E7T4d64bn78z/m90kObrTfw87r3tbZY1H38o3Vx3bLd5afKt+u ZiA+msSO/MzDlvzkr1REf8IV7cXxTSHtvlWJLEX1Je0yIo8sPcd1j+yiC/1VKWdWJAsW28NT l+KsNK3kp5kbsOczOiIXbxYVhfHmCbzwY6qL+AhOO4Svuumr2XntVkf8/TxdGV0zVCzL7qhF aTF/mswi3YVX8wKy/nduxH/99Y+3bOpHnfW1Qk7UtWD6F2KC9ljM10C8p3eTgx7dd336Zn1o 0U7TMzzo91E5VWAckWZOlBx8EX/5BXP0xk+Np3jyBXQeWH0IRX36NTgcYh4vZTnzxXTeh3iG ES8LGH30ZTyx9jyYd2fuJgOLMDcaAmFAFmM82Dg80xtgF4TiVYQ8pmFHuHfdBnlIADOKpWXy dkbSknf9pXbH8nhfQy/Ft28cmDxPBGDKI4I+uGxi+DlXF4ZjRzQt0S2A0nPaBodilwdzSId6 6GG7p4RtmIHtw4ZW+H3jg3SJyApHp4iO54a8IHFyN2+e9mdUWD6jZmYz+AiS9QeTWARx/oFX 0IZsX1gtnkhp5ZYuiMVSQsR3e2hsl8hyOLJ8ktgYpAgaljg/eKiKeKdDtniLr5iLush9c7cw vsgswPiJ1NYaUbiJxuhzutgHt8AxcqaGklRmpxZtrgiNwZgrxIiJ2JhayJhoi+GNtdiKnbiN p+gN+CE8MYiKsvaH9geLmcCA7miO8FiJ6TiOsMJlMUVtPTiI8siN9IhuWviNyhaQyxKNyZBv DRgw/RZyAqeNDyeR6ghd19BJKQd6ePZwG/l3CJZzxeKRi0YiWTKSBvhxKNeRIXmMkBh+Nbhz 2FZLLNmSh/KSjxiT7qFxMBkNNymHORlmAIOSH0CTCRmTRWmT/4dIlBd0h0AZSXrQlC8hadkw lTWpIdOEWf/CJecljtOGhOs2kVpJiV9ZgAUUWvcYj+eylQcIXL94lu+Ylt+ylk1Xlmb5g2AZ l3I5llOIgG55l3VpaA8zl28pkBhElkQZlmIJhIfZl37JmOnFkYK5l4PpmHwJmevESJO5lxhE mYFZMZ1ZjvhXiqHJe5iZmYtpmaI5mqlZmrGyaagJmjUZm1b5mZqJmnY5m8+oMbOZm2bZmzL3 mpb4mwAgAAJgAMV5nMZJVMNZb/nCm5t5AMhJnMopncHEnF5Zm7AJnQV0nQAXnPPWnWoSnq32 Qc95m8wynglXnraJi6CRniN3cuxpiv9T8J4rB2ry2ZW0qY/YeZrCuZ3cIBsVEZVrCIz1+Q4B WpnrqZ3niZg4p58K6p8MynwOqpvxuaDtiZjepZDNuZv4+Y+7YWBoyaEdeqHzmV6mYZcf56H7 2ZjTYZilRnRUyWjS2AmM2D/E5JTOAioDmqM/mXU9WjBuwqNAipNDSaTfgiRDeqRNaKRLei7P oaROypN5KaX/khhRWqVN+qBZWjEh5RxYyqUfuaVhakBeqghgSqbnY6aIsaZpCmszBVJo2nAq 6YT6wXV0+aUbwAFumkSPMXs/SIt8CpggWoBCJ6jwtoFEEXoeOFRNRBoktkN3eqhvAH042I9n t4N2tGSGJItfk1oHQ/iC6LVlUvh+Xeh/geqpdcp/oQN3zOhfDOh0qTpBg7dFLUJ8XYhV/9dW BCarlnQXZFaGigpFaShsROiQZOiTvaqsy8qszeqszwqt0Sqt00qt1Wqt14qt2aoHBQAAO1BL AwQKAAIAAADYfdcobZLbAkALAABACwAAFwAAAFdpbGxhbWV0dGUtcHQyLWZpZzIuZ2lmR0lG ODlhOgEKAZEAAP////8AAGZmMwAAACwAAAAAOgEKAQAC/4SPqcvtD6OctNqLs96cjw+G4kiW Jtil6sq27gsnQwzN9I3n+r7b/OH7CYfEojD4QxqXzKaTouw9p9TqM6rDWrfc7kqLA3vH5LLD N1Jpxea22xuMdz4Ndu2Ez+v3qLc/iSA3V+dBZveHmCJogAZgQ8foGAc5AxlYOHaYuJkx2Sf5 GNkX6shICoQJx7nqslgaCUSJ+jpLC6uhKfFpupHL+vvg2gh7enqL5LuQfFa7rOAMHF1rO/xa THwskzqIzS39XYEmEis+PvpItws9bZEe+r5+Cz5fUxRve1F5yYvfTv8fzN42DHKu4QKIUJnA XqkaVSOYMCI7Hvfi6aN1sV84if4S7x2MYElbp0royg3kSM9jJ1275HFRiTLTQpAh9qmKCbBc SF0uA7Icp7EKTJwvbeba+UwZnxOGiP5b5EtMFE1peloZ6lSoUVGxAl002TKoUiWewkKxg4wB 1qxTypoaRspdt6ks1Yq0OoEN3aRsv7mSVxNjt4li897FC7Ie38N9f/2ldjcuY8SGbRIzCaor Os2eeq5tzOSxoLjp5uKryPirNcGbi2WUPBn0JsxvvdomuZmfZYi7cWdkjSrwat39PsueeWRg WmHBm4tEZozycTfGeTK0LPmd81IG4Xqezqp64utv1YkjR05ubWuyFoNPJF7xxyF7Y7+njpw3 kbQK7//Dz59PU/4hEp9P83VR4IAxLMUgHx40CGGEVSlIoUwVXtgRhhoilOCGHu73YYjRdChi iTeQaGKKrajIIn4tvmghCyiY5V5hMIZo3EOE1HijiTkSZp+NPWL44zHulNaVdENeWORw3OnG 35IlNnlNblBK6eML3nElSWRYelhCC+aVhNFjX1I4oRSEoXimY0D1EFKUbWoo3Jx2aknjnXr2 kueefubD5p83IiVooYbeJ2Giii7KaKMQHtofpHZJuhulQBoaKJiWXippphV6SuemSmIqqpCk igoqkaWmyuSqpVYKKaufuvrqqHvKiiatteL6HqskyIikfFfoSt9g3hD6TKD/ASzLbLPLmnpr E2vJyQwOzUJwraW8Lpfkel3C2m1mJNnWAbMbAWBurNJ6tSVsZprGnbsapOsPAvT+uW1q7aUH 7npQlYfBswfaG4Cg+WJnrEZRwpYNtAwUfJK9+K6L8HAMNwzvawljC3HEBEe7xCdjWvmtDEgF dmRmJUvQsTcOtNwmr8AIrAbLMGMpMys3u4ztnDlzsjPPPZ/5cyJBCz00zioejXTSSxbtB9NN O90j1G5IPTXVMFptBtZZa90i12R4/TXYKortBdllm52lh2qvzbaIaG/xNtxxfzi3FXV7bMHe CuZNhd/kcSA4ohoWPvAGiE/naOOOPx7A4w6usHit/nb3vUrllg9O+S+ab64fC583MTro54oe TemmW9e5NKqvbqAKr5MOexaogzN77TwqPk/uuvd7ge9OCP/7UMQzcXztMCWP/O8wLI8Q86ar JH3zzouZQvVLaL9ruRxxT2wG4BsxfsgpXyV5+gNEvsfMMenYlu28j6fz+5yGLP+8rGduv5G+ EZe/E82PfvXjyJaetDKKBDB4lfEcSg6oGmTRgETxUBvgKFC+mVRpY2FYYAXedkEMPjBOlFAP IHKwDhC6jnGh8aAIG+hA2fQJhS5k2encp60aRqBuIXwhpSgovhvG8Ic6fMDeeuhDddGQgUIc ohI7yEQo4O5QYWrFryZg/8Er4tBgaRLTm2yYly86EV9iBFaddniWMxawUGX0ogQbwMMZIiKD x1GjG5MRxzcaLVZyfJAeFXDEPv6BjjLs0B8BCSh6EBI0h5wDHhPZu+vxYJFVoCSC1IdJyGWy UUSw5BaQ6AJPTkoIotRKVkq5uxygMn6nvAkpBwTKFqwSeDSYpRNiebuiDMGWFCMKL231gl8a AZeyi9ErDecUYaZKmAD6njF/wEwQJfOZk/SPSroYujO00WSPiJxi7LigIkSzWIqg5R1gCAbt eLNa79KSOK1Zs/sRMHbpvATWfgNMvlkLnuWcBgkdwovzcAkw/DgSbiBmiQjypYQFtVIjl8lP R/6qYzC4uQw2WvLFAzoCoaJoD1maYbFZRGeUu0QmN6CzL4OwZ1/+BCk1EDoKkS7GITG9zCFZ Nc4THqs3Mm0YtSDj00BwdCvFAenC8olTkzZkH90RKZJG+i9xCTVjFbOpu546T2gqFRcJFai/ ulomb4ECo/o4R8dKiE81PnUSYc1qNXs1zXqpqZNbdSaggPhOuPpSQHTVK06YmVS//mNngCVf TucKkJsp1pR0PewSo4fIBKAyqY6FYkJghtmriBNilZ2gRDIrMcaSkrMs/GxoDTBLUBWsY519 nl1Re1oqqBZdB2gtnjaJWwaxb30g2G1uG1RS2tb2bNIMImyP+9gukP92uCkC1T2Wq728sVay zS2ucZdbxOExd7tys24QV6tTusUWuTjybsBoy725tWyxUzJvwGiG2EpSN7LlJSfh4Jvd7c13 v3hz73mTI17+jtcPM2rk5WRUTADrjb5+kecX/PtfBZbBtvRDkXNbJ+GxPaUZBgVgNuM7QBBz gcLy2WACE5ffJKZYuynpKQLHpU/PJjjDYyCxgUw80gDZ13vhTVtO/lkbA49lm3ckMhazoMUR swUmST4RNqPoZCM/wcZcZbKUzQjOD8Ipy1Og8i25fFshGxHJgtTv1sqsBjCreIJozuuL1HxH DIehzX09M33EPGY4TbhqnsJznpG8Z0lGKnv+9/FymDeplt/+ORyKPmZEZZxK7L3sw+50dF0r HWkET1rHArS0YMM5aFDDkdIr8jR4DElSUY9arpDegaFda9kgaXrTTcS0q3MVa3P2k9ZSzLUq cd3pTD940TBUtQ5ebWtjO7hsfkO1Vv+WXF2v7YjR3iewWy3tGJN3f8q+AbKTDWthx5PYbi31 ra/dbYdxbtXFDvevZ+XrfKJ4ATysdi1bFW91z5vB5Zb0sfEdbFkP2wECEAC6Cm4AhO8o4N72 o8JCvfBeYnvZ2kZ4ABSu8FS7u+Hz0WNUfuZsce/6bgIft7WzKRVWtzDfIUcjtzceg8Wt4cUs PQfF7W3uko+c5Df+37cs1x1kuHjnYitneM9XcuSXgxsGMl94NXRU01vivOUuF1a6f865p7sU qDluZs6zDXReV8vowdzp1ssqU6Ljj+U4Z3fsrp5LPnXG5iLTCZ3hPnCdH1i4b4d5KDXF9nyL XeNLx3qoAk92klP974BP/OKrHnG883hDj9c30jE39onH/fCObzu59a7tEHNe85YnNeRFvvc1 E6nRycqtcRPteqaPBM6cdt63ty3XoRBzOrfnu+nDbvtvVM41KwMyWmsuCz/b6dvDn+ho4EVz DrNUVK/WXHRQev3taB1+m/Ly57BAraNqfaC7v+wYL7+a54d0rAgEjrz9ZOPvA8WExWf+67jq XtG73yn+gp7jJnoPOq0FgKZTWQNIgFHTf2sUaAnIPwu4OU+Weucwc58nX/YAZ+VndjtXe4eg Bb+0SNzHHktWeL1mK2BgS5QEgiCYIWFFQuzyLfPngvEyaDTlVGQyYLTTSwIVU8q3CnXyG/Li fgnFL0VVgx3VU0pQSp4kHAwzfRGRfezyhO23fRMRVU5CMgJGPqzETRiDgaQWfl4yflLoHuP3 EMhCSaX0UVZ4dOHBVFyXMTMiGOQ3hi5Fg2JBSJO1UFyhgikxfzBGHC14f12VfyeDf2PFUDOE X8c2WYQoFwXWhRvCPQbIgDajSpI4iUkXc5fIe7mTiJrYGPcfMi+d6InHAYpYJIqjWGilCEiq iIoY4iyvaImt2H8FAAA7UEsDBAoAAgAAAKZ91yilVoWRfxkAAH8ZAAAZAAAAV2lsbGFtZXR0 ZS1wYXJ0MS1maWcxLmdpZkdJRjg5YQMB+AGRAAD///8AAAAAAAAAAAAsAAAAAAMB+AEAAv9E jqnL7Q+jnLTai7N+oPsPettIluaJpioTtuAKx/JM14iLG0fO9/4PDAqHxKLxiPzchMuk8wmN SqdUXxN4rWq33K43mbXuvuSy+bwN99TotvsNF42D7Lj9jpfWcfu8/w/I09cyGGh4mFf4MofY 6JjI+KP4SFlZNSkXYKcZkqWgM7bAlxDFSWTagaoHh5kaeRam+jKrJJIji/QquZj21gq6SctX K2wwvDqkqolb6vb7S6UsaNtJTDjFPF2b/cTN9awLu53NyWzKTc7oObesrCttvNg+n+lKTw0b fqtfhhrqUufTsWqpChqMF+/fQVn+8Fk7h6+cQ4RmwHn70nCiQXP+1gh67ARR2DlSIjtG1KiQ okoyFoM5xBWy2MqFN2AuQ3lyIItqN90hvCmTJT+AQzF2hGlSJcdrJQ/mnKnR6TZjGX+uvHip KEisXeAtnVj148ONMSUuxMkUpCta6hi2ackq0juSpHZunTuyXT1gTdggBQh2Bzux/bTKs4R4 1zfCQrkqMZzYkuNTjBsngxy50mQsbn1htpc5tGgncEebPi3pMzDUrFtvvbzZtWxHpWfbFl37 tm7EuXf7pq0a2u/haHoTPw4ptnDkzNMEtwE9uvTp0WFTv449u3YJ1rd7/w4eenPZsccnM98L vZby6q20j6b6vTb5UJbTr3y/e34w+8H/kOxfBHsA2mPffgICaNeAdBD1WDnx+WbWg++po5Mc Ucl3YH4CpfXYhRMqaMR/Ud2DIIgBWogWUCWaeB5gxMRkIIstcuigh+1luOJroAgm4W849vcj kDIyMSSRRSp2pHtJrrGkkk0O9KSLUXI4ZVBVQlVlkBMmuKV29DWg4Xb3iRKml19ueKaWdPQ4 m4hpFscmeQXaNucpccqpJmt1wmZgnnreyWeMQALKBKHyhIdoeIE2uA4LZBLlJ4GJTmrmml9V VZaHe95FaafULVpMpmdduOlhV8KnXDhhjZgUaKie+mqhl0o5FqRZRXqqcTt+xWg6uJYKq6uW 0vpXqLbGGmx9/8/xehWVNv1qaLK6wtMqtQ3emmwpyxJLpVPmRLtXtqRte2gs/3F5LbLi5kJu ReAKu+4Run7z7q6e3msDqJahim+/NOiLUb3+DjwDwF4AWx8guObi7sL7OCyvwhIXBvGxf1RM 2cUNw4lxxn50bOS+G0/8MckBV1qyxio3ll0gIC+48sktm4zHy1jEC3PKOuPMZMw184xkIjQD TevPPhPdrUs7I510HDYHzTR+vgzNNJhOP+oZmkhbHZfWb2FdtdfOuJl1vSaCXfbToyA8JNll J6d2mnGv/bHZMrItr912zo0h31AaHXXTrFDtHMrazszpp4QYLgbj3Thu73SQYtfddf63Ur44 4uUqPmw+0D7tl96ZWywyZ2rjjffDpJ+8+sHtUoztyDrCPrrspnMcO+2zl56u7rd7njvv4QoP L+uy4q6u8bsrb6rvqZ0usOjLD89878QLYlhN+6wRvT+CaUs99ecWqnrtmcAoRvmdzzfURagP tlYzxQ+PfsjmN29ViOr/fouVreJ/OKnkKS+kCxI6VEUh0uzveWr5nvkciMDPSaVDOvjJSKhS lgjKhEcJsZBCXhE6a1UQgh6MEENeRw0VjaVGZgGgslrIF7JQhSYdtOC3TvgivVxwhjBczfQS yMEd9kSAKNzITCCCRDW8r4cO+uCOIpKSEEopQqPiYaNaN/8qKp5lHu5I1V9UOMOCIHGBLxSg GcP4IiPOb43506JVwBg+NobEjWO8ocHouEVb9JCN/oGRFiXSwj/G0Yf5q2EgAVnDQV5BVHRE JBOLSCB49aUudlSXiEIRRAJGTo5tYccnOIhBvpywkpGUlA4BSQ8QQrIr3QPe/fTHPxd6rHEG Y6UEbWc9WDLwlSeK5S5xWUZg8tGXZBzmL7nnReRhQ3qyJGT1Blm4WtLrls6D5no0KEzsQe9b TmpmNHlpSyxOU5rnCyajaOnNBWpFivpaJzaPR0FtkrOQfezV8zo5o/rRDZzss1Ezn/EUZM4z UktA1+QKGpwUri+dU5xgMZ3ppD3+PnSiKLmgY/KFvQqGUS/onF4DERnKjjJ0hCDlqEDhmVEj 1miXBs0cXdZJESGKNJeAwZREPQrRa9jUoTilKFu0x9NXus2lI/VWIrHCzp6JsYoPVURDAjnT qB4DUzmlafxSWtRCqgip7+znUoNq1ap6ZIxgtaY4c1LSi7aSSVDVJ04LARSyYimscD0qPfe5 UKKiaITEfJz7ODpJriR1FBoN7DHD2iFMavKkeY3YYc15vdThNasBRCl/HutXV/b0mqS8nk/7 ys96ZlOy4iRtaCfrWXaBrqvPNGbypBrO18Z2s8FDLGfnWdsyoo18qK3HbtfUVB4NlTOfpW1u MxtThvX/1lWrmhE/C/q/my1XnprVQ0rKOp/nXneuStUuEx171t6C0pM2jJ8DzRqi7a7Uh5NM CAvZ6ZXFtnelwq1kfMM1X/Ny8Y5ftWgHTWjcAKn3v2rcaFzXAt9ZlDSPfHVvVaE7lY0ymIQk TSZB9qvScx5xrdKoS0mS+EFsdhioJwGxCe2rYBIzGIMhtjBbmoVGpZw2b99dlVzB2MRjddgk N5bxgwdsYz0KOYcuTiNUJexG29LYqAS2K1lPrOM0SviNQ4Zy7TKyYCr3lyxFPqcnT4kic0kQ a+TFLyVBI0Uy71BYn8xxmtFUZjafWZRdbu24VttZO5s2wJSt7DLxHN7jivW2/pZN7ZJHy0y6 Jhq9fLYuNSO7aE4CutB2Fm01XfvnQMtWm5o7HOYSJzmXWk5WnX7hpzcXalBLp3Kcc/Spe9Vq WKd6Sn4r2h1q/aGjKS1w/hucrnmNa6k5g9eCm9qvAxfsXhub2NFdttCY3exhHztq6HgLg6y9 uHglMNuuiy7Iti3sLA0VjoXTh83Ehl1YuWmrJq0JQtMLwsQScLiW6gyC571n8oSZyW29ai81 esZ+czeiQXZyujUkaoVq2aTO3WCBD6xcZz08kW3rn8KffHDBeWXCl5W4wQcuqKK91M0HyvPI Md3dXJ580APSkssT1g2YL8mAgKK5AZGbpGRHG9vQ/s54PwiHbKA7G9o69yfPe150n7OE6C1t GL1Zlm/vwO3pMss3p6MupqknG90cS7TUtV4zqkPd0IJ+W9gjzelLz/bsRbc6Zgn9sJqjHbZj a/ui66p0TcNJ6NIm+10FnPS8H4zvmVbqmp9I3T8TbPEZwHncL57uJTJ+8hVw/FTLSfHp9pHy nI+A5V1Uv+yttecsB21TksxYR5Me5am3GCgxvcTVl/7t+Ww9ZJlu85hjN/bIrJNan47QyXDp kgIRvtxd7s5HW1zw8ewmObasGKq+RMp0p7TrlA8lHAnf2ztvSoED6tZGJ17tls6u93oXV3YP efqFbTMm159chdeKyeM//vTyzQv4spdLyiCW4X9VuUjwN0fO5D19MVbrVn2NRRgZwns900VH xkgQZiwrZkN7hGVJ4Ufdtyd9gGOqpX/z52N29X1HNH8qhD72plVjdRQJaHpfpUdrFhCj51Vq NIBcZkg0kkIBSIMfkYHsR3/FlYAwJEg3NXt701Fxthr5pV8PKBcY1l4EaGaYZ0rKxmhBqIP4 Vn97dX9KRhwERXvW54OC5G8uJHZi9iXIwIJfKH1URISLJHa7woXH8XItqIDMVV+KRW/B94Y7 4XYtd3xdJwOyFzp1OE6b1DgrR3piZnzbdCj31Gfa1kmY0IeclD7ihw0/pSbukzWmhBmTWIS4 /rUevBB+W5gznlMCP6Y1TfiF9lcRCvZ33dRwItN0KbYUFhhurAeGi+GK+jQYirVU57cXjGhP 7sGBfwNyn5iL6aFQoSdGTiRKkJd5eiZYLOcTIeVgmueB4lBiFRVFVZQX63WMqscwxbiMbBhU Dfhz52OADjdxTLVv1XUi5Ohb5WhuMrh0OpUiWYRGNYh6lXYz8thkAYmNrHiPF4ZAaJZJJPJl RrdpCwKQINVkvvKBoUh4E8lW/OCGwoWQQAiKlzBthRgxnoiO2nhrmziOczeSzDYnJEJ+2ZiI ccJFr2ZqnUeTs7gLX6d4NamTKxk5s+ZpO7mTHYd0dyOIRLl6gecy/0XJIkiJHEz5kVtjlIkY lUO5lEppibrhlLcBbgGFHlmJlcCHIYJoLiXkW++mJ1YZbzvYX145S0TnVQLHcKbBlhDylhwX jo8wl7vxLA9oh3Epl1YplPp2lJ93loNZlYZ5NoCpIHmJlVPplodJbFyTI8BmkzeCdFx3hrjn ibzxknOXGIzZJpvJmZ0JmUznmCp5muoIlKvJeYEpa6wJmwPjmqoZm7WJL7OJi7JnCDypd7qJ CLw5Y77ZCMB5lcKZHLiJjKaIduWhYinHGzA5kE7TfchJcJpyGsT5iCR5l7o0S+EHmtHpnFXY dzFVgFfVExrpi+SJSmqBfm6GfgB3MdDZm/91B0QZxmLbaEgZtF3+xo8A13/b6XfZlZ2tqBRm iXg7xlxPsVUVEoze6I5nh5yiiSTN1WBgcYMp6IJhwUjtKILxqX3guWwXGJET1J8LmqHxVEcq taHMt3b/VpyyCINl5gleppDo2YttUU4bEnzJ6Y9QE4fG6TLyGZxAGqQfOp9EepwR96JIapLg taRM+jVGOqRQCqFKOqBUGqUR6pn3aFgyZ4x/IqVPOpwrxpzc2RrY+aOfiY+CV3KhGaZXOqZr umEvmKAmWJ4AChxvmqaSwRTMeJ/52W5q+Z1pKKB7qhl9yo0QqKAGiqfDKaRiupsqSKKnp6Dc Nqi2F4viyadGlo//bbSP0EiEoYGmmnqo6kiJdFZh7CVfeKKllwqLgHOmjwqntPGUmTGquTma JUknsmqoWFp3reqredqqtkms9zKsxYqsiXKsycqsOGmmLtoVBXl0sFocCiStujie1Kqdz6qM 0Tp0l3GJ39qW2OqtBCld58qQ9pN/48qu3DqdWUiFOMim6tqopNhdo/ilmfqq7dOdNqIctqYk 55KQ8aqv94evAFuwAkpu7/o/1VZKz6hEHgOROnSLISOwpyQq9NqWF5uq8EcjhqWRzSevC3pe DFsrJDupaBiQFMuVPjquE1uh0ciOJLuwDmufU2ayJ7twFVuKMCuE6Uqwzumz3pKHL4Zx/8V2 gUcrfzkDsq/Ho+Z3oj87r645tCS4hVXLLKGykO5mqrWnq3KWSneasOgKts9IhV1Ulu32kNoo oStIoFZarym3MItlFCvThz+CttHQqy6bjkuzrdBKroH7t7tWrfCGmTR2uIb7hn6VuNe3uCrL apzVuHszuYz7uJK7mQxYuZRrN79VblvKKdmqH5/rMJ6LuVt3ufKjuLZUManLuHAjrsloaqwb pXbHN9rHTHsmmm0LqU7qrvARMJ5Rkd36u3pbt6JLuIPLiSYgaihwUCfwvD5Jm6sGt9N7iqp2 vdg7AtFLvdqLUb77mtkbviTAveTbvNK7vNVRvbi6XJsyWObKvv8uOavrCr6kWkzuy1rwdqSE +bTyC7j2276E8r76O6V+Nr9GuL79C04h1ERk876NokT526LQlLd9uUa3+mB39A6g+lZpOYGK Nmk9hYL8xo3AWmxYFLEIi4qMIUIDPMFyFILsF3q8amZhy0LwGcFZe475WyxElGfXV1oxTMIk SsMJurIIRhPPQli9NsA9XKA//MIZHH9uO8N6GoxPdXFdylAiBMIsvEES/MTpso7eNTkYSH2j ZML415+yBJBY0sQep0iqsoAPIZELDIJDfBVFnIQ3K4Y5lcJC3MUT2Fwu3IEf7MYSLH0u2KEA zMTp2bGMmsN6FccmV3xiQ8iArKHTZYb/dBZYYru3jYx8Ssy/G4jIP/iDddy7svuqjLzAAgzG tZTDg+y2ZJxNpXjAcYS/UIzAP3THU3zIuvxN9Ru/rRzK+6vJHkxPJuhtrwx3v5vLBYypCvxP TUhyF+vJgdySfCvNbOzKwAyGk+jCIOnMc6HBfyWykoZV8DnJ8Bg+EEzNO3rAqOw/8sxoXLzC CkvLahfBvKDO1yXKwizF+BHJcpvPf/PPt/zNG4xxPQYVGLwO12i2uIyjHoTEEPROOHrDFu3N ghaxCy2A9NyuhHTDOyvRa2zR5iliNJh+KL3Rm5bCEJdlmqLHOuhec4RPuyOBJnrNNUymRPvD 7syEOTbNX3Sh/xA3hp+8zFQFl1a1jgJHcQn2cU+NyNWoir68zhdW1CLY0uEpSVXm1SUNjZ+q nlEW1UJYyh59og1dyvrI1g7l0O/shBjmx5EoKT151QdKSY9yyWgdY/X40y0GYWSyyQD9zKl8 z+XH1NAX0zu81eJI2N0MzfC6zXfNqTdo1sccwuNczIYdzrC8wVMW0zfV2c38v8PsUYWdypfc 1jXo1sxskYXKyqcN2ZGN2TrSwIDtyJTdo6ts2ty82ant2i5dFNY8hRyZr5MN1qP8h7SN2GbF 2hlrzAINA+fLvNRtvoYNWm1stYRqr+l73eO7vdYd3tj9doMwwjIbz2ujAuI93qgmvv9ITcAB VtUPC6LdrbEUOXjwq2F4TXWjHRSsXd/HbcuCi9/0mxZH9opDTbYJztxBC9sFTuCECGMOftgN haFghcEDTrwbLrvnHaq6fRdSaLqTjbd9W64Gfm1aWIbBXXgAreEQzuESbsYjWFrLqccv7pHH i+LGeLDYHKD2jePGm9/xfeAO6k/+3ZALHtJCfuK7LMnWPNws7tjFq+QwbuUyLtzM+WVcZcVj C7kxTodZXns9nuFVnuNDvuNRDFBnJNlBbuZMHuFh3uIjNV6AHN0ULuDhiuZOLo1IZdXHWOba DOdgvopi7nx23uA5+5qX47qH2OjgLOXQLVg33nupI5k/KRz/kL7VRt3jvR239kK6oZ7m4syF 47WVxq3C9wQxI65ay6Hpd67fbl7ptDtNJWfjjW3ApY3ld9a69vHqiU7kui7ndwbEihtr1ise CSzryhK8iDtq3lsD1Pnmet7krNa97q2+j92s3626z4a83r3tFHDm3j6t4B3u3DHoyfu25O0a qDO8V47cWikw7z7uCL2rv0Lv6e7pX4nvtQrmAx3bpHYndaZ7frvu08zP0qq5HenlhfvtGSxX Ot7lqD7t5X7wdKVl5hmzdYqqPuifvUjR/qnW/W7wJv5PGY9KLJvE0A2Hy/iCNv1/IF3w5O7w bwV9B/p9EW+LT6zTKySBwA7kD6/j/yePsxs3xR1ob5mc8x57QCRP88orxZwuqCvkit53xPFH Fxg+7/4O7wMt1O0HZmn733G2kCK90mJVKpdeu5kb4ITepLze6K7G9rDe7XUzQJtb63Mj89n8 9nCPurvb9k0JLnHPL7Eb7/eueHZv+Lz7m+/C+PCdxoNCUIHnN3ufOALVCuu25arJfO7O9fWe phSagz4HjiIPfmzaiee+3vMp+g9qeCRNfQwe+IY/GpOAZe+l1zofYTi7tK1P91Bf+5ABZ/KX tHKx+0adgzO667cGusF8r2j1Ej9Pwv0otUr3+NwtGcJfgkzFxUlL49W/ndefdqwaNDZtompJ xYvcg9bf/P+m0/5JDmui2PFLKBItJuKpqMrML/63p+4zX+gEAB9TlxsDxuBotRefmHl/vpq6 DSw9cYLMlW3IFtZiQxzVGVfqnOfeHhhM/IStXRH5uCWZM2LzBG1KqFXrFZvVbrndrtR0BAO9 ZfMZnb6OQWJ2Th2Xz+XvkR1/t7vzTD5t568PSTCpcDBmCYBPcfEQsedRSBKShYrhKKVSipJs c+onpUbz009HjMQq7HRI8bI0RAMFZZEG1nAh07aWt1Mn93dI5tYF2PaV2DN4eHm1efeDOTla GJp3OtKYervEDbXZd5CxMRwbw1tbujvd2ro8790cB509nrv9Wtr+bV/eqL5dv3z+6q7RwodN oD9nSgKRaxSlVUMJjp6YS6iwDZ6LGDdi9KHRI4yOIS+M1ENyIcpJqvywVPnx5UpkhlzGLGlT ZsWcD3E6MNkTkM6dP5MR7TkTFE+gmJZGUkpIaNN7Ui09hWqUGNaje7Te6mrzq0+qsZbSMXsW bVq1a9lysdEWbly5c+mafVsXb169e9u+HfvXX1RMVgEXRiQ4F2HDi7mGQ8wYMifFp8JGtkzh ccTLm/lN1swZNJTMDEOXpunYs2nVbVLLqrza8mjXMD+7VjGRotCaTtZRHCN7RTzgvks+FKSL 2vGpwd8ZHEiIoDK/PloPLBQIXLHlKc/pE70dItPpGYD+I9f+PN+fb7xPVvvNXjx11L6wP3Xu Xrl7yqRnH8vEUz3NNnghldtS+8a4+kS5IZTxzqmuoYOISyyq9ZZxDkNAoBnlmeg43HCYDy1A hcFoZsFuFxTJq27Cm7wLhpHtLNSvFXxERAq9GEGssSAXs0svIA8dLI6+bejJkUaCTrxPll4u jE5JsTT5r0dJAgzRRP3IGXJECI1MZ0b0rDuPGSZ7lDBIKWtRkcNH8ksxy3tUfHA+2uAE6Mv4 xNxxFj7LjPJFHrd0RAmybLwvww9ImZNILn1yiEIGB6xiMBz3C4pQ4iYdRSlOcXuStCWojOgJ UVjBtMkWyxluONW0CnPEbBxhxYzF1YyCNVY4WKsTNjsTSahVsXadtddiiXWhVmOV7W/F15YF jNVknzU2Wmenparaa7UNgcVgt7W1W2m/NS3bcc1lls5z1a2Wr3bdfRfeNeSLl9567ZXrrnv1 3ZdfNBooAAA7UEsDBAoAAgAAAOh91yhUcZ0QmBoAAJgaAAAXAAAAV2lsbGFtZXR0ZS1wdDIt ZmlnNC5naWZHSUY4OWEzAVICogAA////MzP/AIAA/wAAAAAAAAAAAAAAAAAALAAAAAAzAVIC AAP+CLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6 WYQoICqdVi1UVJZKUGQxXa2U671WvqbtF302PyNhLyN+XtBJ9HzGXdLbwX8nfnIXcXdvDoNT gIRpc497KoqHWFqQjZGIcH9heV1qhoGOcp1zn2NulCOhpXanrw+qIKyYqLANspqEn42loaK5 H769pKLGgsWLu8rMl8iLrcq8mGW6EtPTrti4x3jSzVbbiSvbd1vU3d7DpuKx1hDlkOvAKfGB 887I+K3Z+Y77y2QF06ToGzRu6Lwd4wcuYZ98DA9Fe0Yt4qZ37rqRaRj+jpy/jZTYUGwIMtFG SxrXmOSDkcPAHS91xMwxs+WGmjdw2tBZg6fNNj5jiAQy9EfRn0iTKl3KtKnTp1Cj4uBCtarV q1izat3KtavXr2DDih1LtixWmGbTql3Ltq3bt3C3oo1Lt67du3jznpUZJYDfv4ADCx5MuLDh wAKCylC8mAhLGlQOS55M2XDiI4yFOs68qm/lz6APXzbC+UVpSadneQ7NunWA0UVSQ9lM4RyW x/BWu95NGbZjJLIFBTOkyly63AR4K5/se0hwSbSv+at4PJbuw5EDZP+cHHRzIc/rRb8msZOZ X0C5A+7OnX3l70HCowQf8wrDSzO3T3bvvnL+f+byjULaeHWEMxEz+V2H3XqBraZbX/9JBh9R wBGY0TIQVbdSe1wwqN2HIHanoIQBPoSZhSbdExA9t0VYGH/rZSfjXy5aVqJCAzo3XEeu9MgO GCO+6KFfMIZIY2gTGlWhjnOpd+STyYlIJJFBFpakDzfiGF+WLfrnmX4OyhglklyGUKaZKPZU 5XJsXtnDmbOkCdmabCrnJg9wCiPnDPrV6edreXYQqKB7Lkbnn63dCdOS9DWJ6J+KysTolo4+ WmekNE1K1KDW6eXpp6CGKipVc8Vm6aOc3lSoULjheSqiqWoQaxulOvbqn7My0ihfudZ2q5+9 VsIkr6b+ymawBe7+SlOrMBl7rKZGDWSbsIUwK5OzyyFb26rEwZMikNrCg61y4Uo37EUOhbSH tTSBVhVlNXIHLZbSlleGROuWm0hoRRp26H7zvlnfLwc6BAe7U/E7pL/ZBoxnTeZVoS64xTo5 JY1hfhhZn5Lp6+25H2OYDk5Hvclvh09qTOXFIMp7IsjWqfiNcRTb6u6Q7I15sZT8OozWBLdU I7Q2NTuncMo5t5x0vC/6zFetRt+M9JEiftmyyzkqOxXCOblLVYMZ9+uu08tCDd64LI/9stY5 cb0T2kz7S/bWZseHLcf+zd123UShvZvHF1JKrM1+swb4ODDv5HZPhbd2OEJsKz7q5JT/V265 WHwb1bjheiueOZab97y24Ms+PkXoamdN+tamx436ep2r+bnJr8Mb+5yzu1o7wKNvWtsY1UK8 OGS786667+ZaETIxLVZcfNO9Rwv0dBwZvJLz+329X8PR0/v7t0cl2PrRaRP2b8e38zmwzMUV fbbU5ZvP/fHSF3JvwdZfT7h/C28HoXYQOh+N0meo6clsZPnCXvbARLWVKU109PMeediXDJH9 bnzwe+CUkmYkCMaGWzwa2nlOckEFdgxnDWSZzlL3wcSpCYMW06DKACgl1wnGdBp62uCi5iWU YSxnK7wa1loYuRea8FY2vCEBWZW7Zo0riUrsnsCaeC1n4c12/lJ8GBXb9Ty5ZfFnO3xfF823 RBgMrx5nXMwYoRfBKfLqcnCMoxwpt8WErXEwBBCAHvfIxz768Y+ADKQgA/m4NAoHhndczyAX ychGNrKQwSqZ7hKpSEda8pKOhGQdu0bJSmLyk6DsoybDaLdO0iiUqAzlKEt3xDXmMZWwtOQq D9YPoLlNkk40pXZiyUtGzvJCj6FZ9TrVyjG+spfI/OMvEZcudJVwfwu84g2zhUkq6NGalzym LFelPFxELHDP5CH/UvYiKL7ok9rU5iPV+UhuitCCPmoeNLdHTiGRC518ZKcv0enOe6hkebZE JLz6FzYaGpQ7+NyjOqOg0HTmUZ+L/lwm5AxSHfEV03w+fGDVVMgvdFIln9dMTEhFmhiIDlKi pqDgQZgZTjGOk6MbhFL89pPQkV4TmzhVKD9d+Ag22McTtzSkGcknwxUuzXA1JalNSfrKY5pU kChVn0DpCdMZzsicREpqOkPa1JFic5s8lepFb6i9H2LsaljNajYZWlKHNpStDH0qIfvZAlxW 8YmOS6ZeRUlXKAjVNHBzjVz3isqoGmqqp5JmxwhLWMOyCrF3HCxjd1rEOUHWlZPVq2PN+FcX pLVxks0sWCsr1Tma9rSohUulEompqYgWmZs1jQA319qcvLaXsfXsbBtX253clpe5retuC9fb nvw2lsH1/+tnx1VcyBwXlsklx3D91lw+PTeVm52W/brUyeou5rqFBeHQJppS7lLSu0IBryrF 28xxiK+Hil1YonA4hbVy4ZHA5SYfJLbfYW7opULE43L/gl4zVhOkJw1tRPtpH3hS9IIxdN2A /VJg0xxYpxHNb1gzUhL8BC/CMQKixgIIxQp79sJL/Wpc28ribLL3weCoinmj2S+dWW2mNsJM Ne+LYZE2tatLzSS3CLYilgYUxBzlIM8+Y+K6olipToWyV0Hp2KB188rkJQ8Ua5xCjZJJx9lE sJSjzFUq91W6W0ZhTA8axN7QV8E9lnKZW/xQM2/4sfC9jv+CmNYmQ8G+X72pU/7rHGcX35mz E87ge958XTjz9dCyTTSAmczo4zr60aQ9rLHia6VKvzbQ1TwzaiR9Kz+TQ712zjSeu+tpVI92 dW0j9atMLQlXhxrSuk2trnfN669s0re2zqQuKUyAARj72MhOtrKXzexmOzvZne1M64It7GEn 5tnYzra2nR1tEdiVJtR+5LABte1ymxvb3TZTumsd7oiO+9rnjre8jb1uYdRbC+12t7WLPe9+ l/veggJ4GvJ90nfz298If7a1tNvSgMaG4FA1eMIn3mxmdQuc+dOfcyBOSIlT/OPItjj17OW+ +ACarRmGrtcyyjA7HVzbVKB3FM79cnTXC3wsEd60w/5caGVeWplEjdt0BQPvf4ec5jVX+Pow JJDgPZznQQbkz/2IVbHZkzdF3/bLk55trlccYvczmEUd82SHDtrHcUW5uDPIn4JubLdZh/nR Q37wmR975l5ntsgPKHank/3kYiY0XHuubw49KIU3DjCJkM6FuReb35CX+b+HQ+SZGdnhf5dl 4HVKZiBnM+hTUzKORZP3is9d5naP+QDqPvnp+fTi90pg5jO5+TmPGZ2gT3LoWRP3rp9+9Y6n 991bT0qilL3Hgh/8z6uuZqtarc+l1/vvIx954K/e7l2PpMD7cPKFonzFhPflyvu0Z7TO19yq V73kUQ/5xxOflbO/7dRlPf7pRYP8/tf/tXEtrcrAnh//H7d9siKAq/BboCZLdzN05AaAFEeA JWd8HAd0+8aADah9OxeBouRxFIhwDuh3G4eBGTiBG8iBFthrJniCJ6h/zgWC+aSBIzhvHShP H8iC1+SCLxhvMQgUT0eDiWGDN4h+FriDNEh/pRZ9P8htQRh/IEiEs2aER6h3STiDQ+iDT5h9 JUQyYyeFLMiEp9J7VWhzBoRl04GFFziFIviFWrcjx4EvsqeFEfVR+6Ryhnc+kuaFX9d4vtdv C0dyPiWGmOeGKRd1VDd1IYhk/lKHTjh9NudvCNNgMCYxHggexxeIhZV7C+Jy6Pd7pqeHYGcg 1P6RcUSjhJRodg2Fdg+lduLHdiF2VlFCYt6RiMMXi6h3d+4Xc+oHhsnziJCThZIIeMjHVJ53 aVWXUUcFQFVlf5N3i6zXfsLXjDBHeSqVDejRcBCoeb9oe0C2fJZYjB0EfZkoi8sYi9WXhq43 QvEUe5FoclAnZz72i9qoiroXj6/4jc4YjvVofeRYfEYxibdHZ0qFgPDoZWymeItndOA4fO1H fUCogtYlS3D4VqW4Vbg3h/1RflaHjM+Ih7RYd+4ni/kIf4CYWfPnN59lhwwIi7TIkN/Ff1Tm f7yHkhyIg1HYi5+GigC5aQpokiB3ix/JOkK4hVSIhl+nkunFgz14hv9CiYsgSZNmqEs6mZR0 NxcoOJVUaVpzwYNcaCkwmZT+pUOlg5XjtpVC2ZVlwytgOWxiiYZkSTdm2ZSmlJZfuJZ705ZA iZZQWW5y6Tl0uYRheZfblpey43AD8233cpa6BJdVCJi4kzzBtIvBY5hv6ZfappjqE4bV0z6P uU48Ron9R5EDRS4wWBXS54zxRpkFZEs4NzEtYo2CKEqE2IIBWU7ZAoPNGH3YV5q55Yj4A5gH CFVi5ptyaIgtxxuISZoK12+myUTb1WFZFlCs+Y8qVmfW1JsRF5sWaVCc1iAxCW2sZ5zmlpyc ZZkHopqrmUmb2Y+D15rVOYcotFEy5B/bKY7/1+eR5waesoWaTFdBoMgOz0lm7Thl/1hthsiN PJNWxYmPG3mP82afulWOnnCOlEmdUld7/9mPnxeQBNpl3BGftamg8sagwnWVtHeN/5lT7zig iPd8hsOh1jeOiAmifiWivvSQghaRv3mT8FJWVCJiFwkvjHib10cVQbqg0TVqLFlNJOk4kplt MCpdMipahJiVV8cvS4ptTYoaT8pYElp4v5Kd5lOlz3alaJSlESilsAKmziamYkCmHGemuIKm zaamwsGmEOemwAKnzCanaVCCVdmnfjoqRDlUaGmU1yRqaHRZxkSotLangQpYg0qoRXqoY1U8 r9lohioGiNpFlfpc/5GKqZO6O5tqafoFPDKog/OUSKFqgOzVmB5WqqV0mIpaZSPnmK7aN47z LnhUT+7SffiFXKOamtygc5+aqx0km4LFj4SUqrlZeeRpquLkOPWHUOsoWcraVxFTMLX0hy4F rWAzNcc6rfn0fdKZdsL4YuNJq866rYbTIBvEQXnlizaVfPFKWbD2LQYxD9Oora8qWGS1ZAMm jBRKaEylnicFQq8HoYSJjs+6rh7ir3/Dj1HmnwJraKqGaMM6pd2oq9Lan+5YoxVKsfVqRKfK IWDzNV6KR7warmcnkfSKPEu5r52Uqs8Jsi7rkyOLWUfasvXzsrYKq/Jnk69Ws7F2sagjs/+f dqmHRLShY7RQirR7mqnPw7Qi6bR98KdWe7V60aieBWZG2alJ+xukEatUiwc56AGtNoRjK21E JIoY6LVPu7YhWaZp621lSyhhC6mjmq209IBKcrddu6qYySLpGh9ci5XmClD5qmVwy5Qzep7A CV2/6k0KiyDpSCF+O6IEe1MaVrHvpIv7GULgUbi9mrmk2064tgv/xA68SLiXO7rQKa6m2GJB u7PLc64Yp7hg+5ONq3YRq7nsOLsSdDDRGGNtGLqtG4fzio0AemuqZmU/VV58iyWii7zsKLC9 q7PBa7POMb2j2LH+OH9zq26tw71QRaOyC36lK3Xhqxrje7xQul7/p6tci6uOBhhe8Ytm81uN UAq0Qna/o5a/+4i3/iupucu2cjvAnlrAcdum62tvWPvAEOwWWltX5HvAnJtrAIwlYovAX7u9 7tu2DWy2desSFczAHPy2Csy4WxjCAde+uruEecub3iQQI6wqH2zBIYsfgXuOiTu5rPvCIHxn BYFAgjvDGfwmqlQVE5q+c3Vo+/VNE9XDoPvDBpxynid1lbqsKhXFa1jDslLCrntS2GWtYccR g1AcXpwJQDyzJUWiqZbDxmC7XJwuaawrVRzGXfV9YyzEzKqfzSDFCbsTYEy9Huufbyy07mWO 4wW6JRPIPTHInJmN4de/FyxcLnzHhCzJ/0ysvidctZe8wI3rmh+1pQvWyWT7ySoMw6astilM v4a7ynSLyq6MtrAsvkeMJxtcyfLbyvpLy7qMv7wcwH9by+wbwcZ8zJijj/RigmV0n8osMMz8 RV6pvfRxOI6cEyzsEnVcudDczA36zA9jzdusxnB8WLExzvrqwRXLcJZpPdcsVtXszSHKmDu8 yK3yzuYcz9Jcls5Uz+iQC/j8WDpCX3patd8juVNMErg70Ay9z2x50PeKcQCNztTYzQ49l8LC nB+x0Pq8JQQtq3xnxpf3I5shzh89ZMMrTBoS0Bbb0bf80N5ysPY8QjTcOhS9txetlzwbLSYt zzEKzhP8vzkdmP87vcwN3UZaBNRKPbRDvZhFbdEe7dNOutTUzNNSjaVUHWu9dtVjmtWSs9VN XZlvhMxkXdZ78dR4MhKrwNVr6tWPbNAC8tIYXdWWe8pxHcxghNaL4sl3rc7lLNB4rc31dtLE 7MByHTwsPdJUjMgi69fim9jNudi0y9SOXcyQnUNvks03cdOIRkJS8dct7RSQ+NmkMZNQQdBS cdOX3QSoHRWqzdl8QtrnHNSsLduaPYCtbSK2DdqRJtu5Ldqmfdq7/ctC/dm/3RSvfdzeNty8 jcGkrdxLkdy2Dd1JId2+DdfMLcK0Xdtkm932tt1MQN1IYd3P7d1upNfRbd5Jjd5KId7/P0He xq3eeU3Xri3f/Ezfwm3fc03Z5a3fOo3fT5EasO0E8B3fneHfQALe4Y3gRA3gos3gTu3gyA3h Ys3e6U3h4enW743hGW7h7c3hzuzh1Q3i3yzi403i82ziG063KB4zGm4TpzHgrB3cqd3iU63i K27jc/riMK7jbY3jPe7jjMrjLeHe71Dg/S3k3U3kGGHk1oDkBq7kB87kRy7lSw7kQW7lqqHg BK7l6sbl3O3l2k3lVS7mY47lRW7mZy7hAa7mAQfmC+7mmw3nS+DkBEHjSS7n1ULnda7n68Ln SmDnbwDlee7nEM3mmbK1ZsvWO47mpvHoix7Wp+noik7BkY7U//PN35ItHpd+2A2u6XVt6SQs 6cpJ6aJ+6l9M6h2O6FNhRp0e2Pet1WY967QO6GgC6aOO6dMM6n1b6Tas67EuOZ4eJ3YL7DDN 69KL678+7BXO6tjs6rnO7JPu7IIM7csO68d+Pav7elBc2R4R7di+37tYz9PIhj4c6qhux+H+ 3yzlz8BgDkAl7a+u7t5+3rkBrOBk7qv97cpOzuv+6feen7fLhvsOHdae6sYu7heh0WOIOAXP 6f1O78abaX6g0mvo8DKu2AaP8PK+6vZ6H/0gx+8uy/zu7/W+3u4g01hGKoxM0x1f7CY/8c1t yS8P7tuV8Owu7P++3Nd+8pmu8z4/H/8xv+n2juyZrRk9L/OMbVk1n/TJ0vQ/beqz0Rgcv/PN Luu0nvXILJVa3/URzPVeH/ZWS+KBwhOEbegXjvZqD/Fr3/Za4vZwT+xxP/cwT/d2f/N3n/fb ovd8n4t9//eYDfh0L+iC/+SFf/iEf/iIkPiK/wSM3/hhDvl5//iSH+iVr/eUf/mqrvlanvmc b/Wf3/mhP/eeP/robvpoX/qof/Srr/aq3/p7DfuG/vqy/+y1b1lin/tWAeK63/syxuG+H/wZ 79KJnux1b/T2/fByz/o2D/QUrvx60uvN39jPD9v6whjIAv3Vbf2nP/RMD/zBxF8+0YnIce6D 285VT9IBvYf+tG/LtavNEu8MZh/4nwtQc+z0Glf9TUf/t+tMgYMABMvtvxSEctpWKb43cwJy 4kiW5mmC3sZ4agSEz9p9bCsrskbSad1yvGIxV3E0RCmXzKYoObsRI8OVb3KFBbfFHK/nzGbG OC9O29k51+w2Ui2UVnTc+tNWn0/30ntTLBekx5VFVeiGmKgEFZcnaMfnZ0FGuGd1coiHFQgz iHbIqCg6mgLH+XkUqQo0eaojYbS62Wg5a8unZ4b6YUrq+zvTW2blZRraymtc7KKSibZU2BwM m4ohLHQNrD16jOKM5PYN/tcmPpm9nR6ODlYejmgexRZPwa5+z9RdSv8VZt+eb97+vzT88Bk8 V5DbQUnQFtZL6NChvoMQSUGsCG9gxI3Wmnn8CDKkyJEkS5o8iTKlypUsQXJ8WaKlzJk0a9q8 idMjzJ3Jcvr8CTSoUJc8ixo9ijSp0qVMmzp9CjWq1KlUq1q9ijWr1q1cu3r9Cjas2LFky5o9 izat2rVs27p9Czeu3Ll069q9izev3r18+/r9Cziw4MGECxs+jDix4sWMGzt+DDmy5MmUK1u+ jDmz5s2cO3v+DDq06NGkS5s+jTq16tWsW7t+DTu27LhDgc7uSkCA7t28e/v+DTy4cOAYb+/M PTy58uXJixt/iZy59OnKnT/fGJ269u27rV+XyD38du/+3ymKPy+dfHl82dG7J77eavv39LvH rzq/Pn0xHxOpn52ffu4BMoV1Gt03g4AKZvLff7IFqKB4DMYxR4UV3oIgJhHqN2EZW9BR4DOQ ZNjDhvV1aMcLzPTiYGwQmqgdis9QEwuGJJYI44DjOEIENSHKc2MKOeqYjIfDVIOkkUHiOKSE Szr1YpPLtfgkPFI6WeVSUV45HJVZzsMld15+GUaY45GZVG0/oclmm26+CWeccs5JZ5124qWm T3cuREAAfv4JaKCCDkpooYYSOuaeFBzKaKOONpqookI8Smmlj0YqaQuWbsqpoJhmGkOnonL6 aaZ9jorqpaCqc2qqrhpaqqT/rb5Ka6CxKjprrbryp9M6t5aWq660EujjPCOyGaywrsqoyK+j JassqsyCWE0S2TgrGrTRiiqjtZ1oUSwtcWq7Lak7iqgiNsJgm225w56Ly7d9iDuuu69OywKI Pl4iC5rk2kspKDtAIY0aykz05b8AO8ounQovzGjDcz4MMayrpkNxxYhevE3GGnvKsTYefwyo xHLmmVPIKq/McssuvwxzzDLPjB/KN9E8zwA678xzzz7/DHTQQgNt8rhDH4100kgXDScBSj8N tdJMv+l01FZf3fPUblaNdddRa90m116PvTTOa4hNdtpEmx2G2m6vzXY+b8/NM6/S+Oow3XoT KyI5cn2HrTfdzPo3ceBz43uhIWfYuLXhb3c7sLz71pO342rj21Ekd/dDteWXw0sJtX/T27jn ZGMO7o/hkg646WMLbGFHr1gzDdiZoe261bb7m7vXu5OJe+9P/56w8FgTn2XwxpcdNzTL6948 NDbbFH311vOVAAA7UEsDBAoAAgAAAAt+1yjie4W3Sg4AAEoOAAAXAAAAV2lsbGFtZXR0ZS1w dDItZmlnNS5naWZHSUY4OWE0ATsBkQAA////gICAAAAAAAAALAAAAAA0ATsBAAL/hI8ou+kP o5y0Jmaz3rz7D4biwZTjiT6lkLbuC8fnStf2jef6zvf+DwwKh8SisWahyZaaFfMJjUohrAxm ijVcs9yut1Nthr/MMfmMPpvT6DX7DV+649w5/Y7/2PPQPf8PqBKY5TdoyLeHdAhSuOj4lqgl +QhGaZnX2HgpuNnJlknS4CmhOWoaAwoQVkrJevqKkroKe0Fr+yRLcju529tSeLV16+pbTGrM QYy8rMuc5AxtFU2hPO1bfW2tzbntgN0Nm2hCbfoNfuo3m9x63p3evGH+JR8VLPosN/6YviVq 4s8CA0BViAaNcUWPHK9F79T503WQoMR7eBLWglEFocQI/hQ5zlHn6N1EgRFVZTT58I9FBTI6 ohQm6eM9eyYVdATJcMLJjWscblxY8cVKbtJ+AnW4k2UomIbEZQyo5OUqqFRVCm3Z08kFpih5 JZ1qpmRODzhHDQWaImkFsd5meq1J9Gw9Ri49yZX7sxRbbk/RXvQLCG+nu0IBZjKs021dm/rG tgNc9O/gZYI3mXNZmRBlUk64vrpsNPMUz7RE8szGaKHox790hkatB95q1rES9+1bOkTJ2bRH NIQ4MXdqlrx763ZN/KXw2FuNWz2WvHid496cF/QItgHpS6CJWocjvSl179/ThDc4nnx5MucD dee4/lNvTXWBxW9De/tSiqnu/3tpj0hj2AWDj3/T3XGEItQkGBlZCT6YA3dBtbaWgFToo1d6 mEiIoAt6LbZVTw1WEhiHdJzFCn1UjLhOiZYAuJaHTWgIHXPPsdMhhQWSxWI87pkYB4ozDhcj kdfheKKMPQ5ZpI1H7jNhWkzyuCOJN0KZo5RLblmdkRu+GGVtXDapkJNfIhmkklW2SKaVT4YU 5gxTuomcmXE6lqaObbJZZmLqwQgfmFmKuaaPharQmBuArihoknr2SWeNC44j4qJdogmemnsa WmER1VkqGZyDyjkmpJLa5pZSRrEHZKaP1knlpoiKyBiIB2IKiaamcrqrenmFOk+rub56Kp+w uhmWfP+N5qnloaXCE2s/to4mrLLNyvosZM66iqu1hGK7LbC8nomlo9f2mu2q4955CKiMnnus scWuOyqe3H6LbriqxvqmvcPCO++cAafL6rL3kqpvvIHaWW+77NWnq8KI+kpxwvgZXEeiEQ8c In8EV/xvuf9FJWS6JH98ab8OxwOhDh627HIfP+oGc4pqaKUujRx3XNbCDJv7s5cSj4bZxj5z RuvQAjdMr85HE/KR0e9KbJ9vMwstgs1MY/1009A6zWzQYqd8sNUoi/s12GXLm/XS5kkNMrpD uZuvxW5PvbbaZLOdM9dh84swuFFJUbLdeGs7treAmx1uz2XAvfe6gtG9M7j+i+8c0K34Kt1m ZpQfzrffINP0D1RwtU1s11Ou9nnkXie+ryBgQWR6QoVbXiZvrcceKeqN1zLLTrZDjnZR0u2O OO6hjw48cMExvnnlrp2HvDy35yttVSSdLvrlqlsB4O7WE8+74tDXjb4cf/eud/FqkJ/2yuYv 7z3ob6duv3jzv15/3P/BnzwXXax77Mvf+/DnPwEWjID0cx/OpHc32MVPZP9rXwPLpyplfON6 nJNfBRnIP/ed5oLfk2AA9fdBExKMHzN5inZu80ItZK6DE3SdASmIhfEh0IYxaUZKCBIR4fVn esqrIcYI57volfB5pVPKQyiVMMeJcIo4nIsFQ4j/QR++5S8nSRbuvLhEKlYRF0kMHPYGogic vbAqdVMUBE84RvVdMYI8rBNeIpE/rdkCRYaRYlvcuEMxXmhyS4za2TwYODCiSpFmpGEXaqbH YSgpaZOCYiCz2DDCGIh7+yHCy3wwGQAe8XxwfCAH9dCZaWlGlHGkWQItdEob+fGRV5FkLSk5 sFjyiJEHvGS3oMdLEtKRZbeR4QABZheM9NGIhmsmEXuoFlqyEj2a6581x5U5C63Sl4ik1hwP ibds7u+bV6tmAVVom052ZYHIJCc3UVFGUvZCk++sJ0biic9d0LOdcmTnNYVpllraU57mBKgz LSNQft7zfiAc5mcSqkR4/o4TnGF86DSL2Eh/nvOf33kPJgf6OHemr6OuFKRIyXjSNzoHNMG8 qMxSWlGSDmcvEA0ZRx0qU1kyM58MRSdGV5qeaIIUiTC94Xo8CkSJkuumFD0HUjkZUZtudKrl eWrfGqpRYapokyb1lS7zhtMZOtI6VoXjQQuKxVma1ThlXetYsxrClu60qnqzCPLqaDlAGpWu FYrb8BTYPzsIlqtiNOVPY9rLoJmmq/MBnyVHqtJg0QxmdqmZGDx11rke8wAB4CkyvkqXfjT1 ruLqbE316dJ0CrKtazNtalvJ1CVlCKuSTYBrhwpbqkaVsbwt6G0ValHgCtetvd2mbU9ry+Fm /3SvkU0hAn673D2+VqtFJaoDoEtQ6eKWurR1LmeRq13lZhevb63tdafrL88CkLVS/e5201td nF71sN597nu7qV5usneiAMCuT6sVX5MlQa+D6+kD/BtbhN5XwJ3yGLQoVwgEG1TB4s2vZqWi FpqaNwISlm8yF2y3I+wLwhbocGZzO+GGfki06mwvBEz8GNDqd8CU1HB9OXxdGENDxsrdasps LM0MBOC2Q9YxM3i824/2CchoncCQDVDkJ7cDydElb40KvFkNRDnKU0avfPdrYA5sucjgoPJ4 i0vcJpd4zFLWhpktnOYLw3XNZI6xlxn8XzVTwMg7vnOIA4xSwjYXsv5nVnJ5byxoOZ+Yu3k2 7ia58uYBJ3C+hN7wozUG4loxGc2UDrOB0uhnngkVscxNbDEgeYNPohrLWFl1yxKNYUXTl8ap qjSsuVO0TC+FvKS99S8MWeFDVc3X1oh093pN7JcGW3TITnagk9zOZmdM2i7uLteonUO/9JrV IV02w7CdbVIHOTzGthO4Hb1G0ynnfe0pN+DOfasuPm/eI4NhDGNY6BQ7Cd7S/Me8R53t2cWk dlVOMJH4He4M/zvO5xLrDAGu70EzB+E55M+97QGqZAVvEn/19i6dbWVctFB7F883FmNB8cCo EjbQbjnI+6zrl3PV3TInNs1r3kn9ODXUIP4XXlO0GfJFTxrntmaoBq19aKIzquT4NrpuS91U pW+x5J2uh7RkiO81wkU7kPWx1HXKRKBPBylvCSLHh3gMtOP463zhuDFd5UJ1n33gP6ShWqve ZrZjPdbpppvP0eITuU5R8J2us95xbW9KYYjkahcXHiXA5cMn9465DGPkW5D3TmR+Piuv32I/ OmYXbNkTo5d8zhnE4dCLvvSXUL3ph74BNguZzbSnvRRqj/vc4/71Qrfv5kfA+tZf3hlK0Hm4 T+BaPlfA8Jr/PfFlA1Yxy0D5gKC+JAnvaBBYn/fgQePb5xx77iN04xC3rvbFT2FoGr/bH9g+ +m0qTk+H//2tGP651sG/Z/fT/z7Y0P/++e8B/vd/8UEMzjeAPadlAniABJh/BpgM2tR569QH ELhiC6gewdcsemVH1qWBV2aBnLZvQcdwfIJLs/aBmiJ3uHF/hvYtKfh2KwhVJ2hcKbEbgOdN L6gabieCMoiClkQgJch+WuFCPQR7PKgjYkWEU3ERxbFxycETwGaERJM9XfFYWBeBWbN4jBdN YheFWwNYXcgQCHeFH/hAoQA+YPhp8RNJaMhXNhh1bLgZtOND9saCcOgONqGDOoh9dlhmmnZ2 8gaCfHhqzuM8ShiIgqhPWUiFBBIiiPhyKeeI7gGJkUiJlWiJl4iJmaiJm8iJneiJn/4IiqEo iqNIiqVoiqeIiqmoiqvIiq3oiq8Ii7Eoi7NIi7WIDuuHhRvEbdnXHIyBcqqGi3/0IrhRBpdh iCPjJ3NHHWMoad/3gCOYMXhYjCUVg1JoPDqECsf4jFUHCQdRYBhXE1O4THRhTCRRhtlDFTYz clKhHFlHdeuURsHoEWYogUhgf8z4MHjojlundfcYjsaoeCNxOlTHiPiwjurWR9kRkAPxj9VI TKSDkA1ZjudmcRIphFlhhu/oIBn5cHLHkUP4kNrIkE1HkAEpkTOQgqWjhC3kkBXhjRYZFt7I khoJBoY4kzIpcLh4jBXJjwNZO8T4gh6JhUEpjCQplJJIlP8j+X1G2ZD4KI09OZEcORJACSsM SZQnWZLKmHW+oYKA+I5N1y7o6Ivrxo7myI4OYlhWKGrmWIEYtkzF149shI5mmYtDiHEK6ZaV JSrOaIuo5DAv2ZehhW0W55SBaZiHiZiJqZiCqCB9NW3Z0Y7jKI+zokFOwUYXUpfBWJiYoI3J uIM1KXAD+ZTc6Jks45n8IGv02JK9+Jmf0JkG94ChWWs4iJLZKGfYwJJwhiA26Y93qZJ7l26V wHW5uSrCIJaOOZZWKJcwkSrbs4hOmZtzCY/2iBibWYwL+ZNSCUTZ+ZzERXDEqYEE2YzayZRg KZrKSY+FSTLZeZMDB5NI2H0+uT3/N7mSJimB6zCcOymM6KmZwYOQKVmNtcaUq8kZ8vmVl9l3 fHkiXdmIqjmfMdmghmKVsymQULV+ipGSL7kYAgqgBDqPULlrDkqT1jmBVwmf5RiVNEh2LTKh ONGeSeWhPbmVbbF1rFmf6YmbDAqjzQFDNRqj9WaXCamc4HiXahmb/2h/tRKZcUdr4IieS0qZ u8aW9+lYQRp3V0qk44h4k+lUZRgSXvp8qdmHYhoyk8iVJOpmXLqgaLqYbeqmbwqncYpzeyEg v2mmsgiYo+mgZCqnWJGcCnqeP9qnIkccEEqjqnGnrOhgPGmjejqoj4STeaqfqvmoyOgVkrqn lFqp0YioKjiaqYC6qYQDkiqZKMyZqIrKR6Fqaianquynm60Kq7Eqq7NKq7Vqq5ZQAAA7UEsD BAoAAgAAABZ+1yg1N7t9ZQ8AAGUPAAAXAAAAV2lsbGFtZXR0ZS1wdDItZmlnNi5naWZHSUY4 OWFHAbsBkQAA////AAAAAAAAAAAALAAAAABHAbsBAAL/hI+py+0Po5y02ouz3rz7D4ZgQJbm iabqyrZuK8byTNf2Etw6lO/+DwzKesIfsYhMKpfHJa3pjEqnHyi1es1qtzwLiouwgsdkpfhB PFPV5bbbxmbEr/O3/c6pJ3r8nD/tB0Ai2GcwCNj3p2eI1+g4cmFycMhYKFjJSHjJN9lZsfgY Kur5mXlJSJnJKXkauGdKATo62yh7Ggabpnq7a+VaShssTBqrwLlpeOyq3IprazscvSVbEjao mXwreV19CAUNLS0+FQ7cAT6ejldefJ7Brv7JurPNdi0EH1GtcR/psx/rWzd7+fQRq6GLlxwk Bcc0lIAO1y40OhLCwdGlyEMu/hszepH4iuINRKhI3juZSNOxkAC7YTMSr6PISSgtHfGVLOUm mda4nWy1CqSun8a0NfsFE8MXfU24PUlqapkzkFOzHb1YFVlOSyo73cQ41BocnO+oOvg2kl8/ j0abpoLlleYeniHjYoLL6xdSo1r7+o1xwqw5vBjrPlUL8Kzcu73qBrVqd0ZLbya9LUaFuWfO zCX/IAyscDDQQpR+WkZUjl2Ks4EnJ0qceWBKy/E8vLi9VOmrhKuYAdWqGrdwurVpLU2929Pj Zsyl8tuwurj0SPNCt4vMjPdErmURr50Onina7hOb8/W9lzz17+HbN2BvHSLozTQpb22tCLpa 9+rZ/8NmJZth5IBhkT8aaYZgT7OtRdxHAlpnUYEHRdGgO4RNUOF7QpHyVVQTxgcEWWIJ5mFh AxIIH4b4aFhifBJ+GKKJhokBWmt0xLSiMR3ypeM+Npoho2P1lejbielkGOSGLfqoXHkMJcmh knnBmEQdLqU44lyw9ciZaPSwyOOOBb4YhIhFRbkkY1LMAciFZ755hk26lQnmmGieB+I/XO70 nWuY/WgkmE4qZmKcVEKUY33K9FnTn9s4geShT87EUqOVNKWcZwFi85agUFW05pdZxEFjWx4K 1FJ56LE5aVr8rcFWVun5J1GRr7n54Ku6ukpok2ElN+N2TZII5a7GDmHQqf92aUcVesOuROmx 0gImX2VtblZTYqv5qFO0035rG47gjhuuOpGSC965VaLLrnriqNuuuEfGSy+Gw92Lb7631ctv v/7+C3DAAg9McMEGH4xwwgovzHDDDj8MccQST0xxxRZfjHHGGm/McccefwxyyCKPTHLJJp+M csoqr8xyyy6/DHPMMs9Mc80234xzzjorNd/OGZPp88Q7Bl3x0NLoi3TSwrmn9NKD9XYZfVJL re1XWD4nDLyBGtktc3gSqaoqV+uXNdNaVDc0tPcdhOmwyEajNaTTyNjheDpmWfdhw8TNxNxv ThmaGm3nLdnR4fGdrIArMfv14i1SC/fho6LNoFv+N/XjJ95jz2m4dIhP+zmvtYV+LOkITWf6 rqkX7rnHq+tt7sevsy4vx7O/XfvGt0Oe+8+j9+478HuX8WieC539e+wOibV5ljcKXzaBZ1KD fHG7h3A9iWonDqv180rvaeW8NQ+q9+NkfyjhjXef/LvL11lrUbOjT/vw7x8POKrsmx85GePZ GThc0Ql17iOelLzGrNfRD3f2I17mIEMfbpFugfUzjuzaQ0EDdSyDvAsGB7+Xrv7Zjj8fRJTD hkPCpqlwheQjmgtfCMMYynCGNKyhDW+IwxzqcIc87KEPfwjEIApxiEQsohHfoEIHJk2JL4AY PDKoGgO6Lg9SdJffRmj/IY5k8YpYpCL4yKbFz2wJaxbcYvXAyEXYnaOE3CNjGjn3RgaWaxYP QV9D7CgqSJRxjqPCQhzlOBctJYiN3nLj88y4v9MdL0Jg2yMit2bIRKqRGNtbDCE99Ui56fGQ omsWYVJxSfz5kZOZ7FsenbQ9xomiI9fbSCv1RMk0/cZ4SBTBKzcpySFEJ2qckU0Lw2hLUvKR QhfsIDGDmUuM8eR2MmFmMZEJyVK2SneTXBcgrbnBak4Te9FUpjYPdM1taow4CqwgkLKpSFOa E5whcgkt/xaKCqWuQfMcYDZ++csvrjNR4bTnKQfVxkfI85j79GcnARorRyBpggc1aEPZZrlM /oXyndL8Zz9hiVG6ybKStXzopwqa0fLhT32RUahIxWlMfp4UTvETpEBDGqOVxnSmbiMpQtfI QhjQI6f42ilPUchPADLSa0eMyQNfEkGfTLSoTG2qU58K1ahKdapUrapVr4rVrGp1q1ztqle/ CtawinWsZC2rWc+K1rSqda1sbatb3wrXuMp1rnRFWdru6smo4TWWem1W2pxntL3mArB+zSsE BQu4wxKWkn/tK2MNi1SjjTIviK1sYfmq2MdiNrJmsaxmB+vYXDQ2s6K9LGhJS1nIYs60icVl XV8L29jKdrat4yZtb4vb3Op2t2ecLG+h6dvfCne4xC2ucQuJxuMq/3e5zG1uXVnp3OhKd7rU BSt0q3ud4GJ3uzN0J0XfydGRZjdUNbxW88Z2NcGRCis8K6+QTIhcSa03nXDs7TBrSzdLceee ogVQXzRFGqcMaSfyuxy28qPUuOw3aIZS1lWm55nGOMqSjYsQkwbsLGG1xSlL5VeDTeU8JV0r TFFiHCMlND4BP/hrSIVh20iMKRGp7S1D/a8sbSxiIdG4pt+1GQBBXCSJ4ikQNV5GaWDMtmfd BVomFiA2tes5zFmKU7RhXmx84iiS8FcljdpUliFDlIh+OZ/x8o/4FtThrtpNSkDjbq94WSon uzlXrVWQIsgsxOta9E4XBk5W9SzTO5FYzv5u/vCgzTNnOXB4S35SQaIfDWkNQjnSlK60pak6 Rv/hGVKb7qNt7dAzJhIy1CD7qalPjepUq9ppDCO1Q6rTBlfXLNOvDiWtZ/3SWngQuKDO9Tp2 /ek7LHWiaSbXsE1KtGPrOtm+FrYLlf1rR97XDdB2NrORHW0GN7vX1152tn1WbW7Tkdcd9ba1 tY3tc4N72+Ved7rF7W5zw3uV5KY2u+0t7YrqU93z1lm4272zf+O7ZKt2gb0K3rSAIHyXDfuc HqA43o9q0rU0dSgm7Rtfjx7M4SryX8RhqjAzvSfBXrp45mDNJvvAN6Ap79rKW303kTjn46K8 ceDmq+KEvrnFhf6ZecdPWCzIlrzmwXKRR6j3c0nVmeZPnjbII6xUX4IZRA/feYoAfM9dmobO RIf6ayjDlfQonWC+sFVieyO4pOcqTstxnK/6FHEB/wpsty42MHOsJtQIsOpd/7BeHudfeHqr yWLqM9FDXigHP854fBc8R+fudriIfPA8FhPXCS0wGYtttRq++OEjD6Fl7VjJgt95hTmPaM83 Xd/0TRCXSU7ltL+8M0llVJsQLOWpYR5CuQcQSnR/eXZOOtAgP7ynZ198hHEc+ccPaPI3vnBH Vyv6+lI49W89xXcD3N/3jjWwKT7wb/c7ZwL3frfFv33yd7+K8UZ/+Okd7PG/P/04o/5R2S2H Zm3+x/b5D6eZ8X9gdid/AcRSi1dvRcZmY2dFE6J5BkgxhgZBRrd7kpZ4DsgjKcWAL/Ze3mR8 krU2sraApAU0+IF9QyeBF0KCneZ8yUV/VMchKuZzTsdnL+g44VVfxBImMEhUFxVCxneBCFhv CXhaNTZpfieEPWYwEGhYQ2WDFFiAZ4cmTWiChgaEUkh2aIcgd7YnWQaCAXEpCrJ5W+hLsEYd X5iFJSGGYEeGC8NwtbaGHNGFrzJquSFqJUSH6xeCbshGcXg2JQgzfDg5KqgRfvgyb+iGwkaI hSiIDGFrAgg6xNaI3zd893NpinZ9hnhwl6iCmpiIAbN8kf4kcSaocUm4eg4ifE74fKSIUqI4 ijq3Z+cEfqnIXnlIfGoXirA4Cp9Ii62YcbMIc6vIdLXIfMKoiqeIirLYi63HhqXIir5oihYX PcZ4i8HIi6aHjBXHet9EjCv4irZ4jZnHjNTojM2ojcWoUsfYjcNYjeAIjN74jT64jp4Yju6Y jtwYj/WIjtuojM8IjfR4j/+iizc4jeo4jgkTkAKJj8lYjgVzkAj5j8G3jwY5j+SIgeK4kP24 iwWZkP4IUvaoke3Ib9jIgh/pkRGpfBOZjxXJkSa5cSiZkvHHjwNpjhgJijzoivoYTy55kQ4J kxRpkzT5kiz5kCuZjao3lB6mk/8Z6UVK2ZEMmZRMCZXwSJJOCZIyWJRSKZRUKY0quZQ8OZVA GZMy+ZVWWZNE2ZRk95TNF5RnOTAN+ZNraZRjyY5bGYRXGXRHWS9u2ZOTeJN4yZYWuZN/GZVw iZWB+Y4eV5UjuZdm+ZZzeY6xuJgEmZVomZheyZcKKZgAo5eKyZUlaZjyJpKHKZmQOZqZiZOA aZqRaZmq2ZdyKY+VyZiXaY0b6ZhgGZuyGZeT2ZZpOZuueZe+CZC8WZiNOZzESZu3WZen2Zt+ iTiOqJahiZrGWXrHqZnCCZG6mZufGZywmZ3aeZ2p2S+bWZrgqYDS6Ze/CZys2ZrpiYPn2ZkD qJzFaZ7/7cmeSMmd8vmemDmf9kmXyKmey1mfeWmd9BmgSPifeOieZemfpOmZ5Omd+rmfZNmg DmqgDKqVj+mTEVqhuPma/TmeGtqcTjSg5Qmi97mdHjqhJYqithmdgMGJgiiePPCiRfWizlmJ N4qjpZacj2ajOeqjP4o6gDidI0dTjbaImUhmoHCk7JcoixAO8KKBFyhSTjqYYhmWMIF0hOkO gUWi4ZKlV9pqp4F1nSFBWfcS6oIULwalYspl91GmbUoUEuMcpPFgf9cVN1U4XDqBW7odRLZk 52GnPdpbzpI3CRQb/zAPalqkwlKoSmZ4Ikp6acoYi4KnvHNiXbpFhBo/CRRk/8mkoCMhZfjB hfkxqpg4AvZxHEt6cHYmpndGqmNoqkAqq7NKqyYDaJcmqII0RvaXeSpHZ514MW2GF7k6pZQi rF1kD0NKL8caZyQzPmj4H7spNtBKK3J4Rre3gxtaOi/oZ8r6R5/aKtqRStI6ZMNqV1GYrcTK K+IqeXtaNF02EK4HkPBaZUJaq/cqLbeKr/vKr/3qryHZlbj6rwP7baiXWptlsAa2Wa2VsItV Wgg7WpyVZJ/FsBHbsKF1sKclsailsBpLsB8LsiErssYmddC6sEAasWCmrlaVsh6bqcf1Y0L3 ssZFUjHbS1TmUvUAe7llXpcxWq8aeUwmaLjlp1D4IUU6GBWBl7TACldSYXkQhUBDa7TC5bQH 9LRAuITFpacMaxVY+xhFq61tdVdAay2oOmW/B3wjq7Zry7Zt67ZvC7dxK7ePVgAAO1BLAwQK AAIAAAAdftcoDRrXCGMbAABjGwAAFwAAAFdpbGxhbWV0dGUtcHQyLWZpZzcuZ2lmR0lGODlh sAEEApEAAP///5ORh2ZmMwAAACwAAAAAsAEEAgAC/4SPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9TodaLWGLVe0vQgElDAisCWj twHAuj3ucs06dIN+wGP3wTVC2/YRKDcxGFc2oOBn8HYQEHgI8PUlMuhmITBgmUD5l8gHGtTZ yWGX9wlhikFqkBnY2MUwiQqiqjqRScupSxjq2zPKq5HpKUGcweo2QKa8zMisMDtyDEAt8egq K5z82z0T3Kwp6aW5PBiQKwDnJQeLrsWcS36Q+5oeyA3otvgohyrt5t64cmrMnUlXzYu8RO+c MVCHBlrAcqjeLZrojI1Db/4cS5Azw+8ToIsjAbYb124RpS+uTJUUKUwZnIRwBq2EmXLWozTB dia6ecrnAnStxOX8p4lk0jlJJXZ8+gEcI2fqegFFidUqTqxXuamM6afgz2JaE3w9KZXpqbVZ EVRVBs2kXJzcoNrVILUd0l5ct5YdaKYrr0y5+EZLKidSVpOEAZoErJbvxwUfjc6VPK/u3c0V 8jaz6dcxLdGH2W6c2uaxWX2fyfZF/Tq24cV7G/Rz5PAy7V2ce2e4OM5ST6VCgzMDiKYNUeNY Wx5f6lfRRuC7+xYnjVs5GUDbNRXUvtpSo5dBLyYP2Na3egjzIDsSTvCcwNbsQMLDTZGlwYDq XP+xe2iJYvVVxp9FA/7UyRrMNOLOfWewMRUbBn4xYUX3/bdehhwYNZuGHn74lCtOaQZiiSZW QdguJJ7IYosuvghjjDLOSGONNt6IY4467shjjz7+uGEKMVGWxwVDRoOkLDIcCSSPTLqwogNR IpnPkx5Z2eSNWLawpZIWiHTHkllmqUt7k7S1kiRqphnLVWrG0mZthIyGIIJwhmEnJ33Vuaac A/nD1pxjNjlam0UGduefiM4CJphvMmroo7M5GppVvEkaZ6OJrrkppV0OCiOdRW76KKJwYvpm n2ee+g9grOrJ6aioljmqo6nCFBqdq6YKqpOltXrrqa+S2iqtw8YqK63/c/xRq6zHjvWqrdUZ y2uvOhYaK56UErutpd0GG6mnxlKbZ7XAIntmt9CqC6i1O+q6VqOi/tlnu+VCqi2f4PAibWAH qghrnKcwhatrKH3qLotbdnkkwj9gm3DEX0rAsJRQUCtxxhSzN6UeAzeBh8caj0xyySafjHLK Kq/McssuXxswxVOC4PDLNm/gGXvCbozMzDf/jHPMOq8SdM1Ag0hHmmP9e9hW+XaI5rrQLsZr fbemW/Cl9ca789E0svs0uLCuO6y0mNJlqapJJj3wt82a6rTXOPK7K7AxBVNs201HW6upAUM8 tdmugmu33FqOfWy2pCwb7LmIN94ss0lWfWjk/pInW7bhNrIrNrKI9yv5uHf6S3a1ieedKLa2 imu65qHqynTXH/vjeHq0C3qwaYsT7Im+kZEVNuNGu17j8E8ZT7yMyHO0fPIuioy089JPT331 1l+Pffbab899995/D3744o9Pfvnmn49++uqvz/4vkxHdfvzOOsym/OpD3Jmz9p+PP97SZE2v /YWvPZ2KFLosJ8Dvme0/9QtcoBIIPsdtw4G18xkEkyfBAuIqb4K7IPaSJicQDg5SHiyhCU+I whSqcIUsbKEoLOjC8b3PSDCM4c8ItAoM2VB6lemhD38IxCAKcYhELKIRj4jEJCpxiUxsohOf CMUo+pBLBPySDnf4/6PmWbGG7cIioZY0PC16MXpJEOMYPWRGLp3xi2VcI5DSyAI4urE3clRB Hed4lzuiQI94PJ4S+NhH5v0xkO8aJCFzBEiPHBKRhlzk5hrpyK9BMpLKmyQlQ2XJSz4vk5pU GCc7aaJEkkCUoMzCJ0v5IVKCAZUvUmUI7ibFWMpylrSsJRBP5kqaEYl9uUxlJnvJMmBqSJhB mtz9cPnL9hFzPcvEyy7X10zfRBN+QkPfNDlzzYkZM33ZzGMyeYnMNm7TmuFEwjaUWc4jnBOc JutmGZ55zHZ+E5rpNMI66SlPcVaTf/Uswj17Z8uACnSgUXxnPs0JT/1hcALuhEpDebbPh/5W EqIkk+jQIlq9hfWTCP9UKPE0elB1JlR2rgNpySz6gI6SVHMmreg8L8dDhm50CCptXUllGlJ7 jtSmOM2pxXzK0Z0aD6XeaOnIiBqmcfKUoi5lqsaQ6iWMOnOmO5UYVIVa1Z6eVKtHfalHDQrU qDYVoUodKsqM+lSvrrSsOJulQ7maVn3C9KuU4VfQVulHp2bsqmxVqpIwZqQR8FWwcN2rWpf6 uLVGAI6DxetiqSoKrEK0dtp85Vv1atXDtrSDYNVlXh8bViHU1KhTo6ZnO4JWw8rVo2jlIl2n itrCZna1skutWR0rSMxGrLGszapfw0jYz150rCLtK2h9m9Lgxv9WtwnjbW2RO9d9Hve0uZ1u V2nbutRG17oecG5UZLtbzZbGr9tNLm6LCt7mildFo+CueS0r3PcSV6fGBeiu5Dvc78b3p1CC Xkqb518YeHe0RUyvdO+6XPfasWauHe8NBgzdtlE2qQpG8B3ctDRXBbgG2hVSMxus3OIeGGAj LnF5LbzLbQXvtTbo8B4niJTg6QGEeboiDSBMXum62MSB5e/szsXZHOzYBKxQy++MLKqbaMt2 3zhsZ/HrY/1SuIDCKi0wDExku9npyOWqa7y2nE0c8zjKZJ6ylL3EOcoRdchX6tueilEloCBZ yE7GMotPDNsL25d3d26xnUfptC17+b7+XD5YlzlcZ+aOGbGmhS8Q2CzYGZKOUXxir+/qBGJH ixjPFc7xop985of9OQYzvIKYOZ3fMos11B3YMA4gTWpUO+HUfVZ1hBXb6G7AmtSufgKtcQ1l M9s6z+hVtLV+zehgr3rYyLhsp92F7NtyNxk1BbX7Rj2maKOYzFWsNrapsGsyJfrZ232fXYFL XdF+W8AEo1sX6UvWT98aMkGkErGLCeghWnvZOvifu40M703XWtgEJyC5mn1h3/UugGwzGpYq ZuwbF2tI7fXnuFMtbI+VycYGRl2aJ45ujBOc30Le1wbzxVdt3zvjYgUslqV2X7EFOeLJHjhS J70XN9H04sr+njf+au7pbAkNyMBm9sCBDtUly9lP6sautEX+TBr3+L2cyzCpck3yrAf9xl/e jc6bHm9ZG93mIZ5yXpT87sr23OePpsu93h7wuBd95Gw/r6jJLXagx/ppKCedxZ2+bbpvXe2P pvncvVsFlSMc73PfNw8e7vjBD0rxWNe6vA2PaMYfHrKFl7zl887YoGoe6Zy/++UXHW7Mc330 qX+jkN7tWm9rDfTrHv2CZZ930odWvxnE+sN1COvQ9yyN3cZ867P4YpmvfGFmGrXwadhrRDSf 9bVHvh1fS9Aflr272XeizAqseja+vvFlZj7bqG93hnIcLwYPv/utP369l//7W//+1POhD4Yi vx/q6r0++QuOWU+CMPdXeT3zef+3fz0iShM2dbmHXPSzfYRHZAk4dqBCStHnXk/neQ5IgfK3 cvOWP7vXead3Yg4XgSEYf2v3geEFeB8YcunWgCcAeSfIgmF3dJK1eDAogYpke9X3Ak0kejaI gNGFPAQYgxPYgx24Ai84ggI3hPqzPEa4g6OkhCDYZDnYhHLngTEDYDTog1O4gV+oRlhoek64 hZejRVKIgntUhWEYa2ToA5TXY2KkhpGnaRUIhv22gjsghxNjRnUohnZ4g4G4hHuohy1ogHfY Xfj2YvrmhXQGh1eGiAVoiJTYhlkYh5WYQ454iVBihf7+p4h5mIIyuHORyIh4eIZ+5oZsmH5r +IOFCHZHuIjoJ4SpiISh6IqeCIqYKIiWeHR9mHm42Iu3yIqRZYqBB4LAuHrCSIiaOIvG6IvR qHfKeIXM2ImiqIOP54zY2HjUKCatOIw8OIqZeIzOCHG16E6AeI25KI682IyDd45mqI78V45J mI2P+GrbyI7JyHPciIqBSEwLWIrS6I/xqIXzqIIEKXjj2I5l6I8FGY58+In2OIgUWZH3CI6H qJDDaJB/R4IJCZIPuZDFSJIthnshqWfwGJEayYEWaYsjSY8lSYwmGTL6WFc1SYvyiI8ouZIT iZHWyG4MZJM36Tc86Y0ZiIz/SfmOGzmUrwR+RONWi2VE/ZiSLWmVPHmAs1aN9nWRTyhhtYZ4 1mZWLrePSrmO2viNC/eRSEc3duWSQXiVV6eBz1iPvraVJMWEUuKWKskHJ0l1XemVMImVp8SQ WZmV68eXe+CXPjZzb+mTcemRAvaFv9cxZymRqwiFL4mQg4ldcTSZ3zeDMWmXmNk1ILaZ/0iY MimYB1hqghmWhTWXmrmTnFmLnpmAVtKahwkKizlyedlqp2gFAfmZ/5WbiYkFvJl1JpiRlsmS r3ib4Riax/mYa8Vgs4manQmLFtmRrrmb04lYELicjhmLzqmd0MmckDhm1Caaa7ma7bkEwvmc znee//kIj8Bne6fpnqlJivFpeNFpaj43fesZmIaZn+R1TfBZns5HRLsZlZqHnwRaYpn2k6oJ oZ/2mujJMefnoNZZoLh2oHd5nb9olrpGf6i3lIBZZdXBKXjiGh+algLKj035nwoWfBwaVYuS KYdSOC8JlPuZoBR4oROKksdHmzClZaBTNTEHomP4oy4ZpKxWlpL3oPDkcSlKOAMqpDMZot04 ote2jUS6pfOjKaiyNWdDn2/YpDDqnab0pSc6oIWiZBhicMUpmS9KnErUk+zJpnW5eeE5XE9K mr/ZnCLZl13apz0qX4Cqp4bKpEwpnW26jkU4O3tapxgqi/sVpSbqp0Wqhf+2aamEqpiMCqYd CplwSZ5n6qgzyjF1ZzDJUkWgGqimqoufmqkkKpU4OW32OT98GqaReaoPxqjdCZpKWnABSjmp WqoDWamoeql/tKBEiafDWm+7iqwoKn1CRIV2qoq8qqy96h6HypVVhphvKZDiGavBmp2b4Z9b JKV7w4VXKanhijXyt650+avbqq5Aaph7+a5dGa+po6OC9mdyhKDMahf1KqgbSq3NqlUNRGU0 R7BLuoz5aq6aelx02oH/FjmNmZ7ZiqYG62ycioejWqHGNKYsSqbrGbHaGowUq6byGamMKEIK NzMIC5yNCqx0dJY1uqneOrAeu6w5i007C7OI6rP/EAu099qy3lSxtBez6GqOSTurIIupa7qv bsqj5fqy8ymyUhuyR9uuTyujDJusVju2WsqgtzZUvEmya/qH6tm01gq1hamYurq14QquXeu2 t4qbdqu3Zsut6eo+xuqt5la0WWp0GCthxAq4i3q2DTlrTCStBdWz19p90ZqhsiSxm1u3Gtq1 7ZeTUFqriks79fO3g7q0oaBxQKp/ajql9ddrqxu3+Cq0XmqclyqAsHq3Tvtfukmptcu0u6uC 4Gm0qxmbjUu1nFtswjts1Vm5Vxu1v0u7B0u0JYulsTqqNvuelzm0s2tTvnmztYqi2qufUxu8 pytVgZuxYki+2MmyVXuu/yP1r4hrvIaqqNdbvIXqvWSpu5/LvlyrtBN7vmDbr+E7txYrjffL ozYaqvsrt/hbqtkLwOY7vV9LquZFhwwctnyqwOkoTUT7hxqMwGT7wKj7DRJ6Mc+af8+7vqzL iVEQZuM6wGhrwI+re69zuSqcIYj3uiNsr9kmw9RbvuI7pCJcPCisqrV5wLxLvzBDRu6rvhvc xIz0xEpsw20bv5hUxWZYw/1pxMVTIjz8xXn7w5MXxtvLwlIsuuK2xZ26xGSXxofTxr5axkS8 wFncSmc8xHnqwwl7bHoMxdVKxn7cKwocx8Bbx+Z5yGA8x7JKyCRcwmWrxb60xwCJtYY8ntbT w/9MvMbi90FjfMPOg8ndm7+sKsrbs8lwHFPak8qDzFKoDMpYvFWsHMtYO1vZ08qhvFC0vMiu bDij7LJTrMYfBcu9rMvEzMulPMw3lczC3Mev3Myd7MXTA8wz/MgPWc22CzJIfDEiPK9eVqbM PJpRDI3OjEPQys2qNc6CLInKXLoN86rQPM73Ehtz+pqbHM+WRs0wbC/0sjpXygSpHMRBfEP8 nDnEcjXrLM13mrn73M0HPSvmcs9j3DHZ7AuASnRcMTrLwrHlvNC9K5XU86R8x9FJ9mYgA8rl Y9F3zMXB2qC8FksSt0R8bMVJ/NGRDMHsjMfVup3gls7dmsjIy9LkTMD/PE3TN4OfxCfA14yz djzUKpPUxtzFkOyjVJ3TKRPV7uzMRW3VMYrLHKrUytvVXottK51g9BvW72vDU42KZs2305rJ TG29ba3DzJuMdc2pPX3WXE3DLl257SvJIhq6Tu3WKuvIbI3T02h8f73Y3FrYIXlVWY3WjT3Z gx2Rj12BkQ3WjG3Zft3ZlB3MfA25ci3Uem2hnA2j4DvXiTfBpO3YqG2UsN3W+ojZ3AnUru24 uQfYiW3auk3bH+y9ZO3ZlZ3ast2eqi3UAd3aiE3Yxk2gac14vR3bOhvcKe150G3YbirdXPra 1G3XnkrcN110293cn23ey4u+FDrc4l1z5H3Z/6AtkpgNt9+9wtuEsl2N3QEkdm1Z2u7asQ4W l+4tBcVX3cNXcayinNcIYwcebASugw7e4H4b36hFuBecZUK5MwketwtelOVnuKGIQwj74Qp5 v0D41jl8RCUs4JN7SycO11ExlS7e4puI16orp8utfhqahkfNb5KmVz4O4qArckI+1szTuvTt lHu549p9k7ebdk+dXUce4fzavxftu7TaOam44rl65Q8U2KV5Nz++2rWN21dNjAwI32UOljzu 1dOt03tt4TiLgc/t3G0e1E4epmSO2Jpd57993vid5mwOv7lNt34e3rNdvLvtlXpuv4e93nf+ 3wrOkUfN6NEb18wN5f/kveXF/eeiLaxIXujdfejH3eenTdTWnNyjjen5ndmCbuqc/ubVld5V zd6sbtuS/rPDOcmz3teGXuuB/uikfupCDOrq7euQvt+u7tudHufHU+PtPOqr/uyr/dzTPp2V 7t3R/sbI7tTCXeDo3dLHrua9aus8jty7Hu6izt7UXu7/O+zMhMaJbszHe8VvjO1bXcGrPu/b vrdne+/rbsLBjunsvu/+7sSBDOhaPb4Ff+r/zu3A8NKZS7mPG/FFbmlIdPCrbNCnLNLSK88a /9Ac79Abv8sjH/IlD/IKLc4pr5Usj8wk//Iur9ysRPM1b/M3j/M5r/M7z/M97/M/D/RBL/T/ Q0/0RW/0R4/0Sa/0S8/0Te/0Tw/1US/1U0/1VW/1On/OF21u0HPfD7b1cQblV2ImXM84k8d0 afsX4/XTrVYbVQI1EK872vD2PvJ1aC8bBpOObT9BXy6Deg/OZp5KgYZpuxNjG9R2mPH3cK+i rcpRuZL4xzan9bJ0Gs24rxb5AP54lz97/qT5jG+Bfg9mv4J2LxT3CH74aX/2NOX3pr9bIeR2 ADWpc85upZ/QD7P6ta9Ot5/6Zh8o/tZ1aMNkJVf6Z8eHq0/8qj/88xL2aNSahr9nk9Z2Y/+q BN1f0n9F1E+TDNT8su96c3/1X7T7308ohS/+5W/+54/+6a/+hUxj/5jmz363zRvnXDO29ics /xU1+lTzQCPtbmXU/wQAH1OX2/+NoSS0F2e9eUdyMsCjEpMy9NS1Kb+UjTeXhOVbpUUb7/0/ NqkIUy7e6FVEAj1LEOxZC410TIdzCYjupkOeVYOlbbUoLxidlhG15RppYTuj1Jk5e+d2m4V1 xl1vr0uPys+O7SzPjHDI0PHxby/QiGIsKgsyAlGJEakqUxFPkGsRFAMwlHTQlNVw1ajoJG82 qbUSdTSQlvVSNFHn01Zq8630TRiZ6ZXT5JjRZBUZEPa5TRd0mrM0OrmYOJVwt3t8hYoI1tKL j5T86Rx9vSzY0V0evgv/S7pXLJ6MHGBAgf4DCRY0eBBhQoULGTZ0+BBiRIkTKVa0eBFjRo0b OXb0+BFkSJEjSZY0eRKlKy4s9KFp6SyLmDjtDk1JeVPNoHkQbKrkCUUO0EjJXv6JhRPpD2NN xIHZ2SLoC6P7ZjBLepVlPnmC8HXiZmXdLz5KLK10ZgrdSnhSsbbtQE2tWCxnwZKtl2pR2UTX MuXNp1OoW8GHYGoDXDin4Unf9nKFy+svuMZPB1em9VjsYrrKFFPLrPdI0TpLc00WbXkwZsW5 NKfx7IuxqNKbIW2TLJsyasFj7UmJ25UvkLDnet81bi4wZN9bPZHJrdvt8zCnb0ivTj1xOezQ 224/RQ880XLcyf5T6OG9uh/0OZmWd/8efnz58+nXt38ff379+/n39/8fwAAFHJDAAg08EMEE FVyQwQYdfBDCCCWckMIKLbwQwww13JDDDj38EMQQRRyRxBJNPBFFdhJbT6lGNnLHqoRgpM2h GZsSiLS6Wsnxom1YtMVHi4I0qCzXfrzug454VGhJiZrEEai7fDNnq7iGUe6WKflprB3AbDSr y1C+rBIhv8bEBC2h9rqDuHvAwSa0xfooxEUo5/rsSKeciy04O197xjo9pVqzl0q8ebOvlh7T pc6AqkBFym4ejQ3NgSYt7Z80B4WNLRUx7VO9L/bs9MZxLs0MSkNRZTLOVakClBlO//5kDU44 CCUVVKJaxYOOME/g05qDTuW1J2H2BEYdu9ocK881+nnH02b8TCLSSoGMCcYoZcT2zEBrazYk cHcU91WOvC23sj4gOjdVJcmlx9qr2JU0XlbnFbbeFPXdl99+/f0X4IBBzFSjQgrmkiEqM1LY SXHf5axUihBOWLYeK37o3iQtPergijLG1+Lf/qGSYHq1ZQ64bZGTs6B6GM5345XTIlJZWl21 89PDtvVK51SZRXTnn2ltdxTTqmkZLhcjpRlWVQjC02mKm7bnYR3xwo3Yp73JK+Kns36S3qk/ Hlfsql3qDOujHdVKNWlB9msWs32AOhyp4a475mWXpppMgP6I45vRseHN9m+YxyW8SsP9Jrxw wckWGPK1I5/cZLkpvxzzzDXfnPPOPf98cseBzLKWkRQvU/TFLT97KNTjiJOk1A+XXdfTibTX 0F9Loh0bGiOKMdFNlG3ORuIdQyvwdMiy0lQ2h4G9dq6enwpndaaf6dplc7bp7pWDrS1uWXU2 uHntJ+Y9K/MvhsNr9YOzXVCn8Yx1i5nTbE4zodFHUv7198+hZhP7HtFctr6+1Uocc2Eesn61 Op4c41ak+V8QgGetCb6lgsFw4Hky+JILWiBpA5TEp6xBiVy5ZFP5e0XXrgVBEequeS70YMnC FrcXhm92yylg8fxBvA1egTdSOkeOVlS3PMBRq3I6zNSYujSzpdGwfPDjEBMbQsWJWFFYGtsX FJykRSF5cSFQNJEY7fXD+5kRdGlU4xrZ2EY3vhGOcZTjHAlUAAA7UEsDBBQAAgAIAIaM1yiP rM03H0YAALjOAAAPAAAAV2lsbGFtZXR0ZS5odG1sxFtpcxtHkv1sR/g/1GJ3wlIMeFOU5KA4 y0sSV6KIEOmRZ78VugtAW41ubB8E4V+/72VW9QFCV8RGLMMWju6uysrj5cuswvHbu+v3J7/8 8vPx28vTC77h+yqpUnfyaWarX0vz+8J8SqoZ/klTO3dV5f5hnoxsUZm9p8c7eisf2pk5G4cR zm4u/mXO3pzfvL/5+Grw76/lb2DuLv+4w8dd+RuY91cf3vmPvPpP//l89/DwHJdPm+uvX+N2 P/ZPPx2ffTyRNz8dv90/OT6//HB3+fH7xPX3Hu/gQR0CYxw2Y5ytzPGpefvx8vWrwdwmaZX/ tojdPM/cfxbOpsu8SOPKRbPtKJ8PTka2Ts2Fu8bl453TkyHmjm3l4t/MtS3M7sHQ7GNl3UkP mzX8dDw6Ob46uZslpcF/1cyZSVKUlUmysrJpOncZ3xtrqmW+taD8+D+JUmfsOK+rzvqG8nTm HiozdZkrbJXkmXl4cWQWRR65sswLE7symWZmUuRzc5VVLt02Vxw/Smtcwiz4NyqShTyaT2TE 2N27NF+IJEWeVyUvtNMam8Vy39iWSSQXZ/nSJLyvmNos+UsF4W35IogVJ5OJK0qVxNkiTVxh RkddyRupSwhJDUzqqi5cs/4rs4QQxj3YeZI5v/iloV2yPM2nK5ly4iyfWhcaKp3nBRdXwb5y Z7lwUZ3CcAaTU/xkvkgdly3yDFvpbWqimS1sVLkiKSFNOZQRcH2SF3ObRW77eOcKlh6FQAi2 f3twIno3F0W+KKH80tymLp66mZ3PXQHfODhpPMU/OzrpCq5OEuUxlovvDGaEbrjyWTKdbTnI QZvPkwgzNIaPuFidWbSWZFWRx3UEveVLW8Q6Kh/2Vl/BKNumP/H/1InYm0876LRKsmnHuSgJ Fr/yxhV/cbbMM6hnnCMWxTRJZFXfcPkqL/hRnbDr/Xg2KVy6knVtdGFdy8yWWBq0UC+wLkxR wpfVFxb5Euaoda57+BpMB68ZjI4GZk0vS4zSKCSmb3CAEYWo52ZU5Pxq7+XLZ+sKsWmZ62TN gBXgxwuHxU0TOAuWUc3yejrDIiuzzOs0zn6tsDTMldH34aklwifWN7gnH98neV3ic5zDdas8 tqttc5cjBDhancVYT6WBR73ZbAonwisWuHTQyj3taqY5Ro0+822JIM7EqJAa3y9n+AjNLWpY 0tSlxmJdVgWRS3WJhSWFOXxxdPHHvilXZeXmJYaHwpydOhF7aRNxAnVAXXarCxmFcZvBKcRZ iWpID3QyPFLPx67Y7kTJCMFhVCNQ94EOCDC/tQhCc54i5h57AgacY8mx+RPiw3+ypJw5TqGO PHrGR/50UQX8V5M+1XivgCRca158ZsjLzc+3G8+iI2B1og9dn2oHwAKFKhg4wjKUC2Dmh3VP bYGTQtLJDO9MU5cOBdUBsnDN1C4WmGRiyxnQZdv8TvuqacOUQ7VYGyGyar9YjZwOdH54rCV4 lSy47K23+8zf99unOB2jhfeULsrpaZwwKUN0zJM4xg0eLXrj7HVm96qH8+KuGZQmwQb9Rchd spq8Lrbolwoq9wgpM3bV0mG11Hk/VGX6mU0niETqo2+7xqRAA9zX8Zph40rIMbqSzLxFLJfj HOF9U7gpRqFomlX3XiA9ZNWsFE+xJs0rSWxASp0Tnr/S5BW7NIENGQVrqKGLhlgybgtIR4db Y5iDzsIIhNrG0GRZRwFCFFMgqcvukxJKZWznGta2yBH+YBSwQJpS4fCQrBQsZcYNiEK9miqZ M6uXCsu2fCwh4q0kfmI5ZaOjAFyUPcQOfCByi6oWOIMh3BxCl+b0+gIPvHthBmUnjQ2Ui/iF PlrZu+fmtJqlcPVe7HttYcYpJigZwxlXAt+wuHkKdRBFJc8EUV0GSR3RC2OTmyV/OcVg8CCk M5qFisbVo0MDaXyqhqeseI0GcCCvMKHC1cer2/MO9RgqXsMlmfIRuJxvKohqV7KYFCkO/n2q dlE8hto9jDjJlIQSPIJwxxAJ+YFO9tYtU+QSMwJK07VwjwcN+AvTeZdSBHW2EYFclxeLnIEH me5tkVh6EoXE4KDRn7psSLz17QhKG3xKwB7gx/FA1VSKH+XCekaFi8TpsKRohoQfCesSvdjO N+I7QOlD0UIXoSW+YrAPghoW3ItStcLmnB5RwTF9oIvPeRf2+pwswI8kn9MtjN2VEB+wEGhG Vs77xCZbb0eNGYamm1BI/grzOcuXGYPl2hWgAxrF+r6JBhvnC8rmcUfl9zSRslOR4BP1ONVM VC4EICRXF1NXaUDDX6OZoqktPrvKCyA+JJBY+0Tgqd7gCpkeoTvox82ZZMsjDxpb4OFUYoe9 EH+QWhYLSdUkqikgQ1P53MbCFSIIgwwmTnefp/WcHDMr8VoIe8LSyqDu0ZGAMZye/Mdu9nzF +boKwEgbQVVPVJNPNQCopxiYIv5AydSKkV3YcZImVQNa62XNGtVgzkScVDWM4AT9PEQMH5Uw WIM3ZjBUg08lB7zHFS0NwGITVASVVjhJoxFdEXP3Y4IXiiFdR+wWab6SacsIpKQmznu3JoSk yWLoHXu88hlnGMbI+J0wtm1zSfYGVUh5glext9cBnAz10EqUkVqIGSsA+lUqftH8zHnetMpn X/T96JMnc1RelgdfH5rrHOoAbLy3KOtgCADOmPPVwrOQCRIShDqqiPAdvMkLVhaynLiw06mg AXEc/qNOqnEj2A0LFeJ9eElpLvG2bkVlboXbh2XZkiQasaQENGOiKBk+QqHLjsKhZSDRUL7t 4qmvjqWUkhChZTy6p3n+GQFiP3NALMC/lXxdqPV8JIQ1kNpzkHqxyMsQ3wg0Si7lPeoZK3lG BAKDNvLlJIWSteqwwRU9tKlpaQgkPkhMRwoMRdUAqwiSdlYlYDd2IexEKeU64EI4vcWhpgPn EoqKUCatM+ATU+Wy16PfEeRK1EoikI8CnzNZJys4S8WpGLauyRlwpSnPeG+otLoADhph3h01 ro/XdsXhnnfPe3HcQLGPYmgKiYzkrxRaepouZtZc/hO+Vpcdv2x8Xrovnbq8oYNQ6keWS1Pt bQSqcaFEj0peK9N/lvB5X0efkz72nGbxyrwhprCeoL+i3pKUKNX2dNrQacULRAVUCE8HJRNV 2wk9OkjgaWo3dnyyVdFCQjpq2H6nvNESZq0zpDB+pxWsqJPmA9PJpuqSZQTOPmwz6Oh5lx/C 42JpmEw20a0tpVsEOqbtVTBfWzB2pDnY75DiNaGGXaRlJkR6O3o+FFlzgnQiV4BCwNK5R/Zp cu8LJh9GbcukU8SHVIJVFbmN53bBOHWiYSz/BqCGGlXB0ncpMtQCUcr0jJKsmvkE3RnTtxOg DoUBSy8t24hFXquAS+Mil6e9B6T5sm3eaCixhMaDwgIq4E8WFMl6grFX1uKOKC2wQO/Z6ozs glJYFVR6K01fAp6jxav0V1xcdoTf9owe85CDE64atr6hqPQTpCtNmTa+pzyxpkcJZKHLo65R MV6uzT9pCnnM7xA3OFYX0BbE3TSPPptoJX1PKCnC8KTk/Jr2hrtDngSuAB4KafygkwL45rIo kRLZi9RQJL8IzFJPrDDGgMIJaitbhPWKTmStdcGuFnNfnjQYL97y2KERE7vbqCPBwXS6d887 dYWIzJyHxbbtMrDEyO30Fp8nxHyNIXARmzltDNmqYmtHLWoVornqoa/MFUvhVN2mXutbPifV WehHQMBuLSTWJ4dmd02ktSYmKoDseZqnARaiZ+mAakqdPfFFRNm5BDvQX3qWYkQ63tCsEpfG oW3apgOlJ5L6pRYJpgqaPGdRUUi/NxDcq6srHabhaytaEXL7qX0Xaomah3qLWMbajRX3vViP lw4Pd8/+AA4mixK66sTV61zDPbXswcwK54x0PlFsa3Mt6KNtLvTbVORw+Lpt/SVS44/lnSZa pAqYzZuM/aGt2YqlVFuDBNL7AaND12L9QjuSzLdpNVv1snRoqDwWjorr1m5NPR3qGIzj+5XS fhhzmHmNsmVSS8ko6UX6IpJjQhppWGkldUUs5FVxT5BCotFCcXkFPHXBApoG3YRcftucIVnC o+SKmKz0rc26yFiYeYWAA4Jy5GH8gvAWSa+VuBfmT+d5WTXIGbPVuTJ/5p9d6HUxGld55hnU 6By8YeUbCxplMEzBJlbK7isREoGucMA2qOR9GQNxqKyF+yCdvFAyYku6pJ1adkI91kpjCPVD 6WjRpe9VEZdAEpXrBG3CMTJwylXIJubJQOauEQupuY7eJVnqVv82eBoWhWtzMCnSRmkeb40B CShSI3YVc8g6YbS//v3CPJloxRkx12ABun0i7vUUt2O19OKO5A3zats5LRposIEA50JCZPNM epmhjoSjVHkFv+5qCAQBAFhqyLZwITqDGfa2n715+1fYKQAxyRjipU3vc+0oVzkzCuXKuKuD CevpNNU9EgFIJx1Q3gB0iEWQCJ4AjKPHQ77YQ5/vQFACmCFdlZXsQsWOhURYpVachKv7UKaz TGVLWCYkOigqhCxZsPECKe5JFBEw7dp/ZYnOUIMkDeCsMdTbQKtHzAq/STa9UHTpKPGTFHwf tfbYyFTv8v4Wgutkz6jp6fZYEsKW3fXuZlvANWEalbaGW9LT1D6v6WDtxkOnfyDkRqvflsB6 EGQCbNoNnVZGs8fV33Zqd5aIR2Xl/UyM6Ar2L3wz9sg3YwvHPChYbwHziFsG2lA68nW1lU+2 8oK9F/fgolowFIUdhsEUiJJ+MbWcoeCTxSM99qjLuEhQ362Mi1JmkrhXka11GsPGw1JKnkw3 bZBTtdx73rR7O9r4lShtZvWU3bFpXfjOp1b8MADbtJlSgz9JFha5opQgoXR61jQJ46bkSuNa 7FlW3CrUXb852LNvUwgCFExn1IM4EXcQu2mSyN3uo0yJwb7ppKGIwdstuZYaBsco7CKJtaWR JhOne1LSQlWA9fxYZ2g6ak2REljPOWhNwZacttgasVvqoAVeYBCBQ8nDfzh4UF8sZm9JgE0X Uh1WMLTL4kShTv2PCiAizO2f0rIlKCnZAbVo26/SpgcCLKWmvhPP3OuqtAGCu9Oz95fm09XF 3dtXg2e7fxuYs5uPF5cfXw325KzEmw+vBnrvwJxfvn8/Or24uPrw5tVgf4Cxju8IAz8d3110 zmVcyN/g5Pj27uPNhzcn/0K4Hu/4D8c7dxfffmSki/7Bp65uT81lo4Ifn5K88dFjeKGawjpP uHPbGfFkd/sZueRZcn59c9u9YLZM76PsFXfi7bvHP/g/n+D5+gQ7u9v7SonX57i+/mNtlnfA cVvNBh3H//JML/oz7T/7rkkGyEPRrAawdWcxOxJGPKgzOM/vkbqqPBuEuJSvrxFreZRkefv1 F0V7+b2iDc27D1c7t7eXfRnf2Qoo0BWwkfB759x78YNzthXLN+fdkcjmx9c3H+7M7dV/X77a P/FQAM7OLb4Vk2JnL/McuHS8w/sfZfleqRJqTU3E1SZQC0UkORJnke10zT6Kum2iaA9flGDD SgRLId6IYtnNJMwLK/qP/V0z9qlLdrwztvvB2Tw8+mu6N17kE0+kpV5kz3qaoDpRGJYDRoF2 9LciJFsF8HytuXAvNGyaC9ImtJJ8kyyyRdix6ZIMSQbCP/eOzLsz834P5DeaeWnp9nwNpkYR FPkTQXWW9OD8iXDUZie1w2GaprHkhhe9WZ5uQvyr6zfm9uP5q0FLyeQo2N4W0v7e9jSZABR5 GK7vOUEP5qZ7DqtV3Kix5yYv6giirbgEWXe1dvBpgxkCH2SLJnbSdFP2ThLJojR1D5ptl74x qH2JTmYs13s+TRrupk8dHN6MchH1HnKwlJsgGWk4i9EbU/gDhRAGVDg/edGe6+J2Msf0XCPK 2anmWSkhdHoozaLsSst2k1DOWW3xLBeGrfG6bU75qsX4JHnAaLohOzR7QA82OWUTJIzObVi/ Yy2TS4HaiDTUaoIfyWXzGtP72pwktuT2VCwnseR2VZTepvVbew3CsOei234s0MJ+Ojd+9QQg xlQLQX++IRumvrdpLS2TWaih53MX83SMv6RdwWYyG8dSR3Hzk+2m36ki1s+TZjcc8ivJHtek TlKyYnhV3FpgiYJgXBbQoS3ij830+PqTm5ubpx3WDv9U7zvcFesQ5XLZTTpNdc9OuwtSqzUe JT0PXoCbVCwr4Fm+tRe8+UiHW3NUxZL+uiQS5CSD9p6GAUjVjBCfmwIHnfGkzek7IuTwxb3q 1Nc122uhiSV3VqwdHJk0Kcs6yKsr3CyzbkP74JgonW0HhATqdmAvdMb2Ci1TqocGc3caoP6q uipzFxRsKyvf++M7XKCkTulVyua33+0PANsC6lAdFxO1229rMU5GPdTqQnKF2M09LKwWpTO3 SX6/04BS3uyuXetuO8i+nvQyJC+Gak9SmOSlhxfPjfQzXo96uCNZiEWn7pD4nV8dTfJJD6RE W+FU4e3V9QWHY+M3WaRYkMaxjw1pX3hFdVaxt76KL4i+Bo6PSm0WgUu/51x8SXo1HeWb64ZC kBl2Sr4s7Q9nuf1vZbl9cyZmQJK4bJY/ShYuTbJv5TY14MLf3D+23Ca4ds9jnWnsc29aEllP p9yykS3VLJnX0s3Y2+8GnrQWJ6k0OIsGioIYtKhtjsWGQcYustzgbBq+etS1BOvS8xKYJXbS IfQm3QAgTT+Yc/HLKWR5IZZ8yb229tEejm16am9XHtsD2bokiqxHpLqi893h9oC3a0/57aEc 4xj72wrRw3areMEGIjtVoS8ldAIqLNlv8weX+XyDa9255cRkUWfSJURoSn9odK5RitwRAqr0 aNTcytAbXZ6/fAYZs2jGbgN8PglH7Jnd1+fy/RfZOven2ve297Vp+dxvQUADJOHT5hDfHuo4 vxEzt+z/x5TId3Ga80o8I8DGQqT0KUmZKv1yeBiYfSVS5kZWrGHIr0ulOdIZZbNpK00++5Pj HZhuD7Vy1om95+5U4aaJHKaQTp5/33fusJ0WZCrXZRrLHsTcFdye7eo77AM3Xbmglo1WFET0 N/SCZ/3GJ+ejq6eiiVDsdG2sSB1UpFRkrd2y///VbjkLYv1gA4ScaueqVcEPPn7e6vFqXY/f 6qlc24fLi9NupYsw7H98/oVH79xDMt986zeeHHGjRHrf/fsP+x/3v/D45QOoe/fW/e8V+RNw sH/ny/44h194kDACcYEkT+b2gQj+tD/O0eaPXxuHrDt7+lUN7H1lmMniy9Ic9Fe12x1GXnyD YmOLYl85/ro7Me6+5mkSsR3e8cvPTwQ+B6NOI/28qTrX0nK3rA7l7IDQc7FtzmbSmf5slab9 17a5EGi8ury8NG9H56fmdjVH7uQAbLE9/QpNaKoFwSiSa9nLaNM2UltDIBKpDCduyZeXkgR2 PWoNfUfl5e7f/BrmyhP2NFkc9jHOnzAXzBYo5s9i2HhW4GQmYoNc9uNjoHSRjJX5sIiK/Gnt cTLPY26N6EY4qATPuuZjOfXN+oNF0bNdmX9/9+9h7iexW/gjPZ6Ud87ii5A8RVaX/kM4a7Ey kliahjrpI7/FatmCN3OHrLRSs+t73Y/Ttzonu+iiaMlJc9QxelZEDgYKD5BmiSihaH+JY5ul 9nTBGhCKElqEAr4sNcm3tttUY5lTsRN/axCcTdMTnm8ebn4LoeRMzND+cEKP98gIVn5qhvmR Fw/IpQsb1LzsnLr0wrCol6wN/hM5scDp+9/bpgCEiyJAkj9hd5aPzXme8gTGMPhi7+z2tewk F/43JDx+pisqmx93+M0uaaRobtTzRlqoY7La7yOV+ZY/pQ2HbYkgp5xpX6DpxoRz6OS9zyjn /m7j1nmxuQyhJxzskoLCnLwL9FhPt8tBmH5h9YVdUgbGWfNbxLaY2LwVOtvM9zubn53z9o+p /8E2VP+FM6FDHzTaOIsdf61DQ2/+RSKVbqXF4dS9h3oyWvYdtwK2xPSEMrgCD9JxvzkJv3lr t/JCNGIU5wi8fgRBQJ7ukoPOYzLrGf0M1LM9vm71iIc/RTXGV8sk5q/r5Edg+kudiZVfOY5O DFX5Q8XcQbeY21zOHZhHXcuOrr7Wr+wYtqNMwQgaLsvv9RSubjwronRppN7+5GpL3vxvbV/X 3MaRZPu+Efsf+iriXpO7EM0vUfKNveOgpZmRwpatGMnrnccG0AR7BHRjuwHSmF9/65zMrMrq btDSw87DrkUS6Or6yMo8efLkqZggwhdh9WVSZe088seRSjJweWjKjbB2V1258VgUDtkM5lFI g9GBbh5wjRHs0sfGePzGUDEdQSQs12qq0oPkDKexIFUrRjXYZ4cOygGVjQ7UvlwyMBLSJ0PK 1sEny+p5OP1b8hUHe0VMvAKuukgj1DV8Ge1mTM6GkM5IZifrNthlMrwGmJ29E18VdliPpVtR 4io0+x7/1ex7X/Cr903Xrtc4JielfBeHS3JBrxzbyAmXKevb7T2hbeacU3DDuGJbiTXeb/lt p1KN1i0fcXiJl9RwE8RUhouiXdT6NUvAzf+sBI3qByDel52a6z+CQK4VAnEH5augkNuxebue Da0h0Vmmg2BXMOPRMjliWlgaBqDB5Hu0YGfoW3UMhQIMbTH4dfZZN510ZILXE644LEa2vfId clcc2r2h28sMX/nD741HLX73T5fRMsMlY0XPTu5IAS6Eclku47CU3si9vClZgPMtER+fU+AX DMYu/2534WBKmSxPhQ69t7GHr56zFiN8dddKmkquT0T+Q5xYD3Bwp9wZDu5WCcoksPRS2G7B MSx3UtcW/OLcIY1VqMH/6Ej0K3eE7I1sooZruAzD14NPB294Z983GlwcGYi3SCsuK6k7kVtJ cRMtyOitekFRsqNfBmfkwrshWT2TZpm4dRUufi43xN8r4ZV9KHeo/iq3NGBjk4iqk034pjdV v613lRJ+FruE6SBQkL+P92/V23RiKQUbSgGCuJVk9IOOs25jWvZK/oZ1Le0Od8iAOr3cM2wY TUc/SH948jqe0RivFFAjQSTQf7pm4oWFeRWuRfA7QxyzEpYkc0/xJkzTY2BTX6HshQ4Hhk8O 08RycTQbxEfD4h2aoB65Aa6EnqAKFOBSog18YuLOWq/aLpzzzUl/GuMaSkrswezigZfSmG7f JP9GjpDEGk1i3Za70dwpnSzzoDyVUZmvMWPapOqayDf/pPTGAvNq8ZxVG7A6y6VYyZyzJ/kp 4pP4nE0IGVErsJO6U2K81e8Luc10BYYjPQsOGGDJ+cj8A9XdYubBevLETgvXgl+U0/nN7RIO QF7DGasKS/D0GykBAS+IVF+mSldITG2Fca2UeOLc9Yb171ysCqTgjIP2H++gJuAq2LdKbKDb 84SKyJ77+Zifzl0+NGdGlQWrHE6CeOnwBqkvktRAxD3d/uk/7rvwg62M9WvUay6H6jX/8j8h XHO77Yrz60nhmn85IlujkzylW1P8j+jW+LJgPoCLckRihOl2PCJfTOS39OaK1Yn0AkTCJpep 0fIPReWzAfY6njAX2W57943fW49t/viw0OOo8LkWD+ebi4WyssES0FLSkCFDHc7JKvxfJjSL E2y+07T7zMzBqeduLh/CT4nZeTcEj4G12UgKAtof2OsoTAh37GI34is7W2P7+4z72QXjHyqR RvihCsdUHLD/rGoCEB+rRbjyDpNhOfMxLD7YVFra/4DifnhcfsjcSlJ64/idA+2bnebRTGtF aquTgoPWxKYyFGPgv7bqejHA+17wNH2q8L/vtdBE65R/Pft4VvxsKkHhFfcdsnK3KyzYWfG2 fURuYqboC5MQO6m3ZB616cPc8jUlNIm1hCoME0aBuHtpWJ4VeUCx49aKr97j9cO5Fi79ye37 N6czKbmSyjt90ej+aEzyIGNY7xedRMgDou+H18a7tQmNXmJ+8sLiLO49T21eQSHht3BMKnVi fI0kKgly53Mu9AdXmCVHy8mTZDISM4wkRyFrJWzVuEPLBgGnbCQZHI6JkYxXXfuIidGX0wIh igMIlqfVH3sxBeAktyyPFAuzumctNAo0GHbHMqRa1EqsCIrGKh3dqbon81qmq5wyfrWmgQ2Z bLg3swqu4BjtdetSFWfJsuhqHR4RN3itxYVJ4STWfbnSNrEiVniMAe63uusnYbI7irlYMaC9 lBodZqljUTHwzWhR38S0YPGXtttvZsMK9+RsSLR5vIAkw8cmC0mKv77951nxl30HnwouLtwg NTNWQa/VykL0+CNbOyyZ2Cpt/Y8BOhDHOKwrGdQn2obqEGL/VjQb/K62BLqTpambzzQIFnvF k5hKWe6r9ZabM1gf4P07QZxSbJuClCTfEEIN27m8jkD9ACfTKP/Rkphx6Y9MN99rEI0OlObc 1Ekiul2HOJnehZQAkkCwqX+nOQgfWAfvj7OQeZrLugc9gDfp/GA2xhLCtM5bJCRw/rn3cL2B JrVMdV58fjBJpRZ7snBfQoykbsAUt066G/sJCozDZ25m5xevZi9V1SL86/JqdvHq8nSWCwqZ 5lwtxVOi07MoEX+qYxqmGHoCyvFYx7IbF/FjWcL3oH7HDyV6FI8MXOhiMyWUDnQH0xG9gTPx OTkE5WlWvyN93wvcmMYa633CcZNaSiEwdh0lc+7KdU//mA9pUIuCHdjJFuFrhau/giCFSVuk 2YbQUFftktlJTt83BD52qoMAdSldSqmcQpHi3DIXYfuu2jBkuzmliiXO4gm9HTxafJxTv/eR yag2kO6AvgXkkZbViqWeQH1774FgU3QUBKNAUpzcavm0XGC620SFqN+NNQSdDoZfVkwHTE+6 +4+mQqwKvCw+8QC/xob5/mgihHVBXttPt9BQO7EfuqgSsXqfNXOcyxzjHqPtMFyPijpTigpl Y8Gvn40CLYXBE/Z+Apzt1AvLDSlI88POKLPimo+/1UDzPoJ1ZCrOD+YfiURHgqiJ4XkgfxJs b3lKK6KLmgvtVpXDanhFMn82Tjv58Rn+pbV6YWuGww74iKZ2WZeSAEDKUIEaAJRA7f2g85Aq xrEjySCUJ6hrmGr/x+z6Lwawd5eJp25EmqvLi2fF2z+/++vbT+Ef5y8Sq4aCr5+OfkOIj65e XlwUP2BVBQ03Pkvi/Q9TR2XxXqYFU/D6w6/mPr+eSL045ssYIv+53clVXkakM9vaPugIvwo+ A+/htAYCl5re6kT6jfAzxtyVj3E3cgs7GavnKTBUL6pdNbV8QTCkPVEdZpldUk9oBHiRI3ma do7CX5J16fRL3py/WnYE2e6rY9WR1JmsmiWhf1jgqBZKxjvua3pN1NKpl1JxigkrIbKX+/2c gjDmNXOoaejGg/2SeoHXYNdLaFLuEqHQna/87IwpnV+5vS/z7X1xnbb35c3Nl2zvS93el69e nT+xvS/PnsqM8gZ3xv5rdnPmgh3L92HqY/Yj2Fxl9Tctobqq845oPA3h4j5yFlRDrHEjGSdO TaOi7jeKv+qzzAdUQ50yJXGUlUIz6t5mOwCcS/LyiTRqZQjuoeENEr9p4MKKum3wrw4SnyJE NQcDfmvi6uZ4jhFzNEbo7f5LJaSstj0rMPJn8tG+WhFTm+/r9ZK/f2bmh2UkcrzG2Rc5TZo5 zs6Mhf8pGzE181pPL1PQC2EpZrwY30rVVyUZGGcAszfGDxObR6k7vXJqsIFWvEzphq8E59YK /E7EI0p5w7CBQryO/KuwUIwxYdNjRjl5JZGwxVxxMDPzAzg89OximHcI06T5wVElBb3ExOoZ PI8JRIphLv32+HXbNlZLEy+h/KPDhaJUZF88swwp1zjhivjnLM2XLOtSyuaGCyjWeSonKiif krJlgpJvax/35y1hhQkuyieI+95OIs/T6DgmLpcK99joJ4c4qk8ZOFrjoz5ZFqa4rvmmtRDW TDBu1ba5sz3NMojodpTaRvDCuGs2cV7CaoB40GdC0dQnGal5IpNK0TtN5ECRlNvXbwm3FSRk sVEesQlCq4u1GuF5dbvsY9mW1FhyzDrMW6Zj2i5E9DvNrBD5Cc4s5tfq+WT7l+TRKfSjIymb Yysg8P+HG1hVr32EL+U24du7AgGR4xw/Ijfb3/THH4igHj6MgnMw8PMqPQKlRLPift8sO8h4 iF5LQ+3GvlQ5EOKu/iTfxsxGnCepq6r7mL7NdXRnGa3LjL2OIn1IYCHZnqrpzESvS7IPNmLc HeOF1xKGWqoI92JKGHdJGU6wm/LcWXZrsD7oXhSZLfcqfCOg47ZXhLHQWzpAlMWjPFDwfZu9 ZuDVFE4YytIYi+vDWfGTlnpRBNtv8pnzPMJCax1lXMAoDyg4hnoo8SVZqrZ+gGFTyoH+xQoq 6iZdMxqbyJ0Bv93ZB5Z1V2l+m5TJAWkCM9YumA9axlK2GupEWyRGB1BfrJREGdkOplANhmJr llfKBjUjlMUCF5ocSrWX9pbBEcaltpaGBXSABnc70DN7QBp8pByo4EWnqDiDVhzw5ILky+fh RbcpIzQnv9hXownMLOF9FNhGXjB87+G5FDtOUlMiC0BvYD0U4UcVS7chUwb/ZHQjH+eizMjS Is5hieC6N5oE7XwIfeRqYt17coRcVdYgNodrYYccsqHQd5JOFPwrq4wUHAyCutzWEmPVmm+E iAg0xDKuDYLAalHVD5K2ySdH4ifd6HVvT74jZBZZNS6Dyn4T1g7gmBlJzTye4goxC9WJrEtk MnI5dehHqbkpMCneZSyAo5jUEUQkzjihkV6akogPDegqmDGFYxjm9a7+WF1K411EPjMRn7Lr gt1TZy+3X24ZpwrDKZfjv3lXruTrlKmUsYynmcRfGXJeDULOlynkvH5x/iUh55WGnNeX1y+f CDnD0PzK+fDzyfjyU24GtZtCn9OcLTiYR/KmbPd8+nV7u1SAXU66MDrLuC36XuA15nqlY0Yk +RWvb98XJyQDNLvn+lm6t1aXII/oK+QVtLkKc4ba64TPPHkGW1B2z07jvvAGMq18OJ2qMhjG EW67s2BA8re/rydRTuqURSpiPhfim/XFCSOh3hzs0+RNp72s0xK/SZfDXduC+DC/REwyeKcN D3Wqj3BH4+SxK1VHfDdsGSN/ETZUU+EZJWZThOkGfyivA8Nb7YisMoErfof4oGUjxROTm6D2 lF0kz/iMcoL15x4xYCEOvvKo2dSg7Kjb5XY7RHvHUTZMjiBhmfYFKG1M9pwoYnAwvxS0NClY cdrMOqCEuSQmrUXSyZI9e/3u4+vDs6Lt4jMnh7VAfqEj/tEs11H8FKkkVAtJOCKh5I4QDb3E 4Fnsd2NQgxAb+TPPFthBy2c5W54hIGFEAcsB4C/ouL4zr9ZdQ1KoUvBFMle/7pODWy1nExBI OJC9e434ICxld7D9pafWiLflSn99Z3yRqSMnCRpbr5IVXqQDrPZVhEqH5+/dlIebpUq4Q81p hOeSNPimR+/tjFHw6wjjpndPWfCNlgzIGeNQUx55fqB3YU+yZeskOpA7s0pdLEbJExGwEDRv Evc4sgstluej41NnTyVCxIECBBju3fVgkaKRi3aQpDIuRvLdzAJCsxq7yHoiVL9LHVY+Gp05 ONtdJXcJGQFOki4bi05J7HPmxIoRASHMoGo+jws5rKpaCkETdM4bYoyj4qSpfckFdTeQM9gT nsY1JGry7/FelJfImb54JEEO0C5eQH39u4xCnSAdjCmKwLd9htj42bFIIr+yLCIevKcQCu32 UHOnolVqDFTtKsYC7o+Ql5W4R1UE45eaFAGtonxg3i4PwxcPI0OWkr3hmoHhWFbUsTWSbjm9 UKbQu5zxAcQgSNGr1q6s03xYNXgJeNDTl7aXmglwCEVglrA2TkGly5QyNzGVmIxl2AiMlqzb 2EYSWWZYMdDhGzggk1HHwkxI5rzptRrzLs4l+rifq7cR91PulmMvMuwCiQnQ2UnXPvan0/tb Jgx3leVd0yHhXyW/vBRAhLVM4W+4jFNem61Fr9YSo/MlRot7QZgiUM1Main0TJznBpLk4Zyr JHDJcFijEo7sa3NL17mjf+4c/RffXX+Jo3+tjv7Nq/NXTzj61+rnf9Q1zxJNv6W5eoOZvcVk Pen/vzuOV43O/+AS763BFHocbcZlPkcgwBNSAQBQJdfYyzWBxoIyrCNG6A7UFFE7MbdKv0ih RPxBKhR6tOBXv/1EWH24o6RDiogV8a9//uVDf6rxBDo1VVKMEhskptKnQYsjcDG6Wt02A3Lh jPVbXB351EC7Hr0AR/NT4lLr011I+sy9fh4RDuUAHKyuzrRJcmzCnwqg7O/T38RNiz8hMmAN +E6qmsfjJiUtFsF5FCoFK3w3lX87iExXqvLK43YavTvh+5iti2vE73zsMDRXRTU0Dov7thaP 6lHuQ7Y8cpGkcFgjHYzMrpOf/vbradbwr3xo6yWvaTzRes7AMkc/J35FKQXQ+eY/ifJmvFoT mOohaoKUpyrjdl/SO7E+rOlSnx+O3Mx6PihmliN5YXfSEpXJFoXVaLvTIx7CE2d37MLKoc2g YE3ZjwMP0N+Aki4zjznHQC2iGyTMyImVU5EwX+KwvSEU+rdaw64fwBnETr04VfF3gpMRCcWN z5tYikiejDcuT6cCTanuZUnN1j7WlWgRwe+9Op2KPKU6nj3AiIlADphptOLk5lp7Ca1W4Xw4 TMlnych9Oz07ns+PpdS73Es/kuaSTUA1UOy6K/MqseCHanfMpZlE4rzRZRo7csrWh5mTNhq/ EIfBHH9MpW8q1CYjGblLvTZxyiyIe0RvxPWDBJrlYIBnxXshFa73vS5NJPceiTJkrnqzXOIt +hYke+HF+tafUliMM8jZjWJ7WN6z4oTIz3Ad6ljTsd1vttXyNIFYqmfRb1BFMrwS1KIJsbHC nmmIq1Fw9erFOVQ5gGERIlajoJ74zmh+CzAoeiHQVmW0rq6GV6SZkqzYqEKVLcIeQObJJ0q6 tOAF+gotY8XExSfLlUfMzS8LmJjooGZgEtsWMCut2ehJScKUnnZXumtn80fEyKa4XQZvFCv4 EY6BXNBfxJY0hyLXedWyPpgflfvsCYs4MkKOEw8kIPZNdjHgjgmbYL02V+ODznVqdJyZVxiR e2Z60dBPuxjR5VFkX8fmCLeCY4gmCYeLnkDacbRab6U0lQzoGGb6d95ZrfQGPsZA+vCnCtm1 4M0h7bEbTMB0wDrggnugGHNKOeFsTo9bEjGfqlY67Bt5+eJGwotwmV5L/9PwX07W8zGip6zD 7vmJfwt/+28F/j9Gws0iVdrhG787L34Uph6qm/52+z4dZ0EAhf457CEHnWF8jF0PF+6wGc3v jgXBpNqwWgI6uHkJpbCoZhkqZA41p9a4G8Pp1K4o2vND9xyH6QQqwjf2aRADMq9hWDA2sh6D fJ9qS4scj3nDV9fH2tdq/92L+PvULgZjOVIakzrhlMLsWNzvm882kbK3/YMYcT6WSJJKu2CF opw+yJz5P6uM8mRnd+O+bR+lRTfM6z/2y5Xy7GlTpAwZ0Mf9YQs8Wwhwtk38d35ffCSFHQY9 rsD3qMCtrbPgTuEn/i78qjEBY1FxumPMZNpG3HVKUrBuhqWV3AiHn5UcBnxMumlyeXuBvqTo 8+72+dXl+GNxwWPnl/CDKxFCvDp7qURW2Hp+08BASFXB1dkL/buTSzGgp7HaM8lwTvBOIqI5 o18vYzbBLVOJBOShPTyDw84UR8TZF4c4IR+kcMPtZVN4mJC43JI8ghhBm0erjVIcPw3G3e9N kgJRwSwsIT8PLE3UeEcHKkPM2krAGwHwjgD9vPwFtDc6wCgfLsWIo/xAVJcIN3lHa9FbFiDv tlaKooyrJbSXQivDLzsB/gpAi6WeOSFYpyS66RIicbIuXjija5IdYb+wP/Mz/YpniYs5GTYJ g3UXE1fozlOueSfIoQuG+bPZLupDoI+3bKd3UQwgLKuNJttTqg367hvWywOPW7py1Mgu0wrS eB2Y+eftnWRo59SRrpdEC30DsGFhMdYIL/dYNtpvVqKL3eA7s8Rj6xZZy35T6zYVpgZLyYvd bMrPKoWyhjueBMBI7tmuWwmXLXnao29WuSZgR9/yC5WQtErB9dCDYQQa0Fmvo2lfz0/LbSrj +4lB66+ujG/S1fslOc7zmg5FcCy6bVejSEvLzWDnBlXtUg+EPmVS/ThZPsjoEI8mEQ8ab0o3 dPLnwlNXXykj2BKFT9EXCEJKrOVXRSkkgkZO5D6KuC+DpezD7kGZwMz8Eu3KsHtE2ZdxbnMf 0z4fpvPnN2pJTSRWxOC1viJ8zabsPzM03LGPA2rc4HG4VdzpeGvxXiV0dOUA+h5KqvFEqFFg 5uyrT7ZA1mnfUVfFbCAeKB2oG7ZkTULs9iZWP9xX0nNLecOxCOF3puDf//pfVX9qdytfo2Hs WI5RlRdfi/u+GOC+r1zJzMUXlcy8sJKZmxdP4b4vzvJSmI8CIlK2ky/1Gq1VV/vujzkfRlc2 CTzuh0z+SzfKXQ1qr7AuVHTawS6xuQCbFtBAr0shZiWkL4oiklply4a7R/q+y86o4JU9+/mZ Ibo6olJqIptC2eDuO1UZRyAZYKGy8lzr7Oly2JJio+hgGMSZsjSNOpfYX/r4uo8vtKuQ4JFb J367fmmcrtb6ohmxb+od//0CN90dPGYBcXptJia8r+H0C2AtvHj8gXVyTzNR3/nBmIYeXgPe TjMh9S3mwN8X1I/PcKpPRAaoscEZo2KKdYIOTy1Vh1LadgkynaqKR1BF8VgxZhVSRNJxEXLg vTaHRQTHHnaoqC1XUpIXZTzZnMQbkuE+TgtIR0VKnAhh8z5M+3tq63G2qHFglkKNjTX5HG3i kzdUK704ncn3ww565VFeR35b6geswtgCPm7nNlFF/XLqR67EvY5EjxAg1HT7Qjyq2gs+5Sgf 1jYLYu05rfp+jrPNpbT8dnmv5ZlOK+bYFj75WO1wDYQXD2MrfhOSZXAlBO6b3hWxsRzvvkkt /7L/v3EXmgmLZvhPr/ldH0iZL04uvpV//y1892lR/J/Vrvh/RaGrUvy7/tdl/K+r8F8y7E9h 2KKHEq2jPiyZyGN3oO1NSWnhe5etoXt8OTkr2NnRdVedWVX9B/mmZRAZtm1LfvKtBYrdfq2n Z7+Zc8JYleAm8f2HX630OQaS1FgwvcvS68rWaeAyWCwT7l04R+a+q2d0QwnYl0nVzLTa5OlS qSD76QzyDzzJW/YxFv0Ad95JI57+Aui7nZ2fFw07wgbDIM0QpYSXz31sQSxYiLAFBu2PlB6X OQvaEvJwfibDPz97ia/OygPiy9fGqaFsZmuZB0UWgrP1rflaxaLuFnt0Qbm1LhksdtJf899d lZREvPPmHKIQYiw+o9xGYxv1lN0LlqCtoCFtaShsNH5LSwmCXR5C+bm1QjGA0GcpGQlR7Rk5 IDSwZB8W2CmVKdiV68/a5Eb43fJrmkW08GXTCRlm+dQ7W1NkhDcqYdEGP3CjGIBO8Cw10uzY VwFPcw06BGvuLDG1EtYpQDGAHgC8Cyhq1IrCRTStwJpYwzVJRGiWUinlAg3J43QRdfXNz2k7 f67jtUD1MtBgdkAX2IXtiW4D6thdZA0EtCtjEmiPguf+h5+iRIX/abJlwWV9+89M9p3262gD vFeZQr1grVevBrL1L4rNuCneRfZH3xXo73jsId+NH3I9fMj51EMuMwX/F0895Ltz/6dvPxQf bp+jLcYXPCX/KACqp56TifFLz4LXxc351aAH5eSTXuVPevI5L6ee89fBY66OTFv2nIsnn/Pd 1HOQoww2w3aSdmS8jA8LQcbJx1/eIawEYuv/7kV8uHzq5gaPxwfkO/vTY30H7Na2I3rLg+gb BQQb+D5T/woxNjYxZWj4Kk/ELqQzyO7LpIaOCoKLM1d3qaOJdIUOtxJ5aOE7cFHjQqZtfFQh lmAFrZVkMBvhptirqHZwixpcVKZjZC1pIDZWSvty1S4ycaSEQMSsJrUH+ahaC5+/XC6c6epw CMIT/pdSx8uFir0skOxmqg3zJO38RJfCuv4JeZBw+7Zdq9diRKzY1VZxXjaN36VQQN5HWq/J RVPqxTQwuIzbxeoGG93FEhS5eXiyYkersDYfXoXY16Y7Smz+mqSNMq/IseFEoWgO3I+DQjYz wWiZIr8Df8+o4pR62UGWX8aJh+jcEheVaZDUUDvnU4cqNL7RcNnkrq116sNII9dDL5xyN0Yf JDCI45JEIxOMyO737GtMhCnKbcWtNRDUQzlRvaqR9jIZh5g2HtBXM/BNX142KFMwAqRRrkLy LbUIzzhVWUObqIOfROyLk7VW8h73nbWYS9uzS1d2ugXeZQR6A38nJpKlTlncxrKvpYXcGumx 3iRdvcbVWZGaXUc0TvHi0vL7j/flZpOi+7ArnT2hCxl1qwDqklDsOyaBYTt4f82996MBcSbV FCy00k0yYNqKg6UQbZOK3Xr1oWpPFaNup9futkP/aFpL0akGDpljAfxZlFF2LS3cc3KUzzjy WjAyWiytiSvvdiqD4x/nuKfqa9dSe/j3yp+m8A3iXWqjreUkE4RBTNkvymU1OfocqJJOlpkb K4n2JgYWEOV5qEZNre60syCVB5BXGmJgjfTrw1z4OXAgJzHGxWe9IRSs+WV92GyD18tumfok YGgX58XnDdir4betyiE8Kqx0EUImiB7198cYE28VrHlbQTWlRaRwKN60bFJ3nCNhZm2CfxMV CLEykOnXmks63D2O5r4fCgerFh/uE4I745AU/rdnVPiCDX4zMWS9SJyV2bXtWZRc25O5i+5y 3PCRiEQ70MQTafhVfpTFsjnDTUkc8Ec1Lg+BLYW+H3NTv8SjYkjPIpbOUqKSkGlZddne3ak6 Frek9XxRQ8ON4kiDsC33Kp8hbJqqBRRQbsp/qgCEBnzCWRIJLjcxbNMjCZ5SmChAb2wKdCa7 qGWSOxirdTsHR8CJSiduv6SmlzUZRKq7rGr6wqxyqWj5BsyQVFtAPKXxeBvRI31n+WOrZFWs KQ5acdRS+kIc/Zzsti5YDNVFDdft3JBFrcBWmqbKA0hRFrGT4m5db5/frUkK1kJUnapeleZs vhAYo7URBtLnI2Gl8X3doTnS7r61RxDMOUTuVSr3kU/pjawgrmue265WtKB+gZwgaT/V4uks Q/Ztq3q1vvvgIChNhENtt1HM0KktJgXEgdvaR7BYKL3EA+14hmHPQATDdlYFECgIzlwTSbTW BZ1ub7qTR15PJ1YQXPlLIfHxHrxv8RUQLdRvJibXId3XCUuYa+T2G82q20P9xBOsRYG+jpYB oRCbUpxkWzYHUWdUdctct9h0t8pxPtA1YibM6t/ag+RyAsWZixSc4SILxyPXogPWyF4Gvqc3 OdCaocR9uxQW3z34aY180iS8dY5SI67wA04ic4WitR/PWznWttYT/6C3PeCgzvRdo0C+K7JS 1lwUxa3Hfcn4DI5D2OO55NUEDfrmaxN2NwONO1+RfX31JQm7G0vYfXf9lMbdzVnx1jMqBt7k a7sFZAmfDHo/tuiszIbmPgyDE8T5Q/ZarrVddOClQN5yqlZC2FdlEnrLQk7T2xUv/52KQEN2 S/3ItZTU4PneRaS2QjI288oV/iraeX52yXBPWoYl6uKd3SWxJKK3zV269IAfZYzNitf0/s3g PbAia4G9SJ8eLoRyrnzRU/Rrad4R7kuS6HrQyUPHiKS06ehm8W0vFQi7dlkevhcT4hv8Ug9l B4UeStNuWtyqf6YSkyWtN9BLgi5BuBZIyqKCBHlZ/W6/JLQf7jJ0JduYwJcjKCRgk3hqYpou mWAQokGnEAMi9Z3aUmY+QwAqfG3sy06SEi9eCORZlCocAzci71wMIRJONYcZovAd2n8gdmb3 B0y+91awXX3zkVm0iGH7ybtILXDVscuMSk/BfVfYOLFOCJGDIic5Kn3tQTdbdC4cAkvmrUlS BmXkJIQm0KK2YgA6cBgENTPMn5DbuET1eWfMPgnZaqLh5VnenQmkpnqpGV5rNc8hcmMBjRFm m3W6iEOQIgkrq5Y3rjMtaXkTKYVx7C4J9Dlg7NuJNEJ4bU0fmM/BrI//jjlh9ch8K8MSEesQ iXcRaliSmnGBH37H/+me2kL2Wro5bMttJsQd5fRTN+xShb7aO5QExYXT/un8dCdZMsYbnIjn ffngshICkFCzy/LhYeTIouV/zcZ41iWNlI/gmStftv8sTSoxzR6WCGfe3Y/wctWTRJaLXWjY 8G+jeVW5GrGXHsLBajv70rrieJbB7QNQEGagT7XWg0EGZ4k19yDhGbZluTVmy4ptCMx0zmeG dJWatGr6R6la5a/PixM3yFP55Hn4XwgtT+RtZaCnLCx9rATbq2yzLrvykUQDc3OHExrlxkR1 T8EU5vZLkRfKkUDKLie33M+gFF6H73etjupd7DSwZbQezzeIa7PJ7XCvjnHmHgm5YkxQov4B YlctRdEv6aXSW/N1M5UCQv5Jwyq5oMwvSkhMktigcp0c1qS1JMtzNrjM39FN/mzBT1dNiKgN 5lu8Uxip9C4GLzo71mgz01Ej2MiZoAgzlfQj+6ycnNZUDMepIbj93B0obheCeFLSIzOEowBC 5hAQtu9SJ/D87EJdAhIS6ybCv0hNRLV+CUPlq/KucMqhoMGL1JnJ3WUnU4NWu+cZS+scCx/M wCBP2lCjWIrSfelb6KQe9ng16YpLapN3jxSZwq2j5T1Smi4PpKGmkkwCj7Nc+cmR1ZRfnzqs LT7R5FDu9e30DbQzGWJleC+pRkSzt0NXSbYvV/Lq8nl+WTaZAEGfqsWHjftc+YiOhZz4dh07 IONsrkuLBVOjIFZ/0/3Brf9crn1ZzpMffnp9GldO2+aItHEqQH1628i1jOYpSymlxQ/C1+bf qmstH0DgzG+QyMb9sQqfRo9mscbukV/y6D5hnxS9Tg0aI1EgfYzM41T1K7676s5Hpfm0o8hq l+q4s+JjuE+k12FpQx4hyOw9gW023H0976U+JW2KnNyQk45kK2ojYuuW7MBwU88QToGUUsxN eIejZFWu44TWTewpMJ0g4sa+PxJkyQKkAHkYOb5UIYfswqv7nKiQKKIjMyzFG6Vrh53CizCr aTJHsHjcnWpny9TnD8kom5mkU3z3x8aNjn5U1jRLhmPKM+raQJM7zF/vktbcgKp2dvqVUfXL LKq+vrp08gcXXySt/VKj6pfnTyrHv3wyqGay+XgoPcDLP+wlO/VuB/9DpSImcfJ3O7djDTCf H0ibifmJ6WZzS4duWMc5N2phsAxSiog7CtPmKNk/MKwW6hnmJWFjkS4Mroo49Kwa52lcq/p3 u2L6EsE6720pUVq12o58Xn1f/IbATbBre6NEhTGb6foWeBymUSMtN9rmEBvH2RmJrMxqmdry EmWnUCRN22ObHJjhxcEeLcvi2RuAa89O9Y4NQQt6Gs4ZVaMffMUiHcGdJh0eTc+0kt4ZVdum doOV8I5ImSWQyWgCMiedFput9nRUpkuTs7aSsefWi/P/nTdt9E2CYnA71WYy7z1iBs8jvTuJ f7gLasqwHXRxY4M4rP5wjGa7fYUj9H+bCPLexRlkMzq9smX3I5RFWYots6AnpYbMy0qKLLsq ZoS05eswBWSr8hkdZrga2sdIHiwJBLbq8nLMylRrnvcL6TNn7TwkZ5o4D1ZZ2zukPqY2jDwn 1dvsapou17yPFiav9h2P0hHFDZCS74dq5+VBDDp5hETgGcixyxYo2udG01HefcQNtdyvHRq7 Zf8zcB5GHx7ns76Z6qAaG14/tt1n7S4VPunKfrQsZ17FhuPSlJVxTzsP69OoAtdIS6zJiYew RSrOJcQAlxSXzCG4C5pJZv1jLsP+w94shlVVD1q2AhSSy9ZV/mbi44Krl73I9YX//+FmVJaX vkWqV6h3ZdnKnLxJnOSxHQPetN80tpPGZibSIFPDcZf8oy0ok4uZdAxm7nA61q+9ryc7kcRm DyOVnUxhLdsrR3qDiEz8zPVmV7H4vEe7xcXL/cLaLyvzvQ93lV5CSTo3KodoI+ooxCkY15Ni kElIWrWEtVhgoWJv4YvIQJ1oJ+CdQJxy5SIDfNS6aT9hXSWzITq/zVKu9GiaTR2u329RLusY x6XJQQ4bpCO1CO+KwKFAO5wm17v0+hVWguAynouG5HJML6+zX0gvpczwq4O4agGmI9uMTlip J2h+djYyEL2YLs9Z5JtupalWxMevgqJtUv8pTKOJQ/qO8LjzLDIcNSyexb6Urk5UylTKOcPC 1M3Pj806qQkkFwVUUsXlH9+dZEHEm0FlL+BtrLj0ghSLHZKdQrjpzrPc47bQlBcABOkBqi/a H4KDsoG0R5iwZvlYL+G/xajPrUvV/KM9qBqI6epMaQb80tgllzUd08O5MJWu0Yobt93mh17X VMP5Qd/oyOrA2zEjLdAW5lZEctkMNNaQ8z1MIZuGM7WjkkSgLQ0pUC5EzztdSWNPIgH0Enk5 6X1gJ2+ieyhvaedl2R7GSboa/DgMTMRTw+QBwjORyWSZ8WZ8cN+SC99UyFCZaBcNnKx8S+wN nNmcEirVrxqmnrJvXndgQryokLnWmP+/96DHDz0zfVvOaHIh03ilyT3g5ad8JDRt/fDabTqj pyotv9juOzYr9GdY9mGYoOjahv/2W9S5qSMT6wc/oUwRvsm828HMs+ObzT39qRBplIb49u34 HkSKZFsPPc6NirmU6aGjAu06s+fSMt1bqvzjN9fFjz8MP/vjy6w3cK19L9fS0FdLSFKLzkE7 cnJVH1rwIQh4ygPHfYxiazC21hJZc+vtIyY2zWtqjlHR43GPDKvOxBWR2xH7UDp8pWWTrJQL XJIHs6feMzIM9GNmpgonlAgKnqw0sXFzXvxW7qTrIyf1SNj9OhLNpmPtURhcOhKq89UHVAwr LYl0NMGqOHaRzMmiIc0A5mZoh82ruTapWLdr7YHHZ75WOYZyxUXKzkTeFWZHNDimc+CIy06q dfFxILTnaVIPld4kRMhaqmWREKcmUxKqTbiy9GJj1c1Eu4NMp1GUo/vj8hNOrku0BVhgKOG1 9U9Q1RsrWQzftTGKJOGFrE2dajM3vfVkZbinkLFIGakuw04cNKTIH9Sh9G3Bkg97rE2fnQ0o hlovEvj4Um4YNYYnm47Ft9mU/2g7r6AFZ40+qmOaxxdaJq3E4DpGVcBR356nWNaeCShjdbl9 UmXG/Yul7j/r/aklDdZVq5SM9PGzEdFoJP/RHturGycOARi4NUQUlmzz+WlAXZQBMxYyglvW gtMuTqE+aosTMJXvD0wdyUcHODLPh8kQm6SBcFp683KV1rcbVxfXfdJykAEPdSB0NBG/Sagt tWJ76dHsdnGKFxnE1Dm7PbymcrqInA/DQS5ScG919kgnjdhCpKVOyyAoTZ11AJMBYpRCQVwd MQjj7ZCgIZh1Rox9LLUDHhrGKnc+kTnIbDWxEJgjI951pPjKmdqvq9G2FkhhgA+2phWSWp2v ob8T7EhluEPwL8Lah2+nGdD8Gz6613xe+BI4ZKw+6fQQhpF17UN8QLgD5Tr/XLm4bNH2SpLh Lo8hvfBm7Si06G9sHvKPr/Lb02oJ+0h7ew4GYbDKYZ8KoinLhFjNDgBsS/j1epk8WOJbwBtE qfnhkJq3h1dAZVumlRKLQz/3O0ebax+fV6THdvDFxFWehZhPOKXrQ0yW4jDp2fhLSwZN9LoB 2Ii6x05DBLoOiRco9b7hF4fidr29L4s//+fNq2giP37482vI2ger8tgwLElVzffaZopvzLWo 1fFI1bFxxgBBhK35PjjN1fLbd+HSoz7Y7fPgc2W0Sn5Rybflp8MKVus7W3mNR++87ztTcU/+ uaSsQ1wtujaqyU/4+KHKICppDLbfhCcdRsL2xkVQ+KogqatZMkKKLdw1vBZx8Hd3jp4HnqkC 3hi70k835co0UkW/JMKlcm7Fl6y74m0YSD9vuzbuWoAqpMy9X/xYN+tKRtwMm03bjpBiPd0y euh7YVamjnm8fuLHVSlQHqhQTZavqEVS8SFE6xsXTn77wy9v/v6nfw3/jX+8/fT+J/3H/wdQ SwECFAAKAAIAAADifdcoQs9N/pcQAACXEAAAFwAAAAAAAAAAACAAtoEAAAAAV2lsbGFtZXR0 ZS1wdDItZmlnMy5naWZQSwECFAAKAAIAAACpfdcoTlI168QIAADECAAAGQAAAAAAAAAAACAA toHMEAAAV2lsbGFtZXR0ZS1wYXJ0MS1maWcyLmdpZlBLAQIUAAoAAgAAALZ91ygCWiuurBMA AKwTAAAZAAAAAAAAAAAAIAC2gccZAABXaWxsYW1ldHRlLXBhcnQxLWZpZzMuZ2lmUEsBAhQA CgACAAAAuX3XKEtj9a1JCgAASQoAABkAAAAAAAAAAAAgALaBqi0AAFdpbGxhbWV0dGUtcGFy dDEtZmlnNC5naWZQSwECFAAKAAIAAADTfdcoy+dXlX8OAAB/DgAAFwAAAAAAAAAAACAAtoEq OAAAV2lsbGFtZXR0ZS1wdDItZmlnMS5naWZQSwECFAAKAAIAAADYfdcobZLbAkALAABACwAA FwAAAAAAAAAAACAAtoHeRgAAV2lsbGFtZXR0ZS1wdDItZmlnMi5naWZQSwECFAAKAAIAAACm fdcopVaFkX8ZAAB/GQAAGQAAAAAAAAAAACAAtoFTUgAAV2lsbGFtZXR0ZS1wYXJ0MS1maWcx LmdpZlBLAQIUAAoAAgAAAOh91yhUcZ0QmBoAAJgaAAAXAAAAAAAAAAAAIAC2gQlsAABXaWxs YW1ldHRlLXB0Mi1maWc0LmdpZlBLAQIUAAoAAgAAAAt+1yjie4W3Sg4AAEoOAAAXAAAAAAAA AAAAIAC2gdaGAABXaWxsYW1ldHRlLXB0Mi1maWc1LmdpZlBLAQIUAAoAAgAAABZ+1yg1N7t9 ZQ8AAGUPAAAXAAAAAAAAAAAAIAC2gVWVAABXaWxsYW1ldHRlLXB0Mi1maWc2LmdpZlBLAQIU AAoAAgAAAB1+1ygNGtcIYxsAAGMbAAAXAAAAAAAAAAAAIAC2ge+kAABXaWxsYW1ldHRlLXB0 Mi1maWc3LmdpZlBLAQIUABQAAgAIAIaM1yiPrM03H0YAALjOAAAPAAAAAAAAAAEAIAC2gYfA AABXaWxsYW1ldHRlLmh0bWxQSwUGAAAAAAwADAA8AwAA0wYBAAAA --------------F6029D522968D373ACD40B56 Content-Type: application/x-zip-compressed; name="RISC64.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="RISC64.zip" UEsDBBQAAgAIAM2d1yjFhYQcJTgAAACtAAALAAAAUklTQzY0Lmh0bWzVfet229iV5u9krX4H dM0kllZTtERdLFdc7pFl2VbKKmssVap7/oEESCIGAQYXyazHmCee/X17n4MDSrLoxLlMr8mU BQLnss++386Ld9cX71++eHd28vrliyZr8vTl9TyN3pflIitm0au4kUdRVkRHB9GrrInex0Xy 4qm++OLpPI2Tl//2b7998erD6/+OXr09/fD+w8cfvvsfb/h/30XXZ/91LX/u8v++i96f//Sj /Ylf/2R/n+4eHJzKzyf+9zdv5HUO/G708sXp2U/XZx83WZe9+eKpfMavD/zXr1bRi5Po3cez Nz98t4izvCm/XybpoizS/1WlcX5bVnnSpJP5cFIuvnt5Gbd59Dq9kJ9fPD15OYh+XiZxkybf R39si2i0O5D/7e6GEx5wQvf3u/2Xp3lcz6NyGjWy7uusiYtaXtt/6T+S9/HJJTdWFrMSG/tU ZNM0mmazeRON0+Y2TYvovGjSPJINRicXr6NpWUUCgySq53GV8nFdTj6lTQ1wYLL90c5YQPL5 +ChaxJX8sszjSRrN41qGlPFusyTNV9GyHefZJPs1TYbR9TyTz+soaQnUZVw1UVNytGk8kX/P 4yaSMW+zPJdBomVV3mQJFryQJ1lZ1Njp5Wk0bldpVct7zTzKFos0yQRsMplsf5aN5cjGaZFO M1nstCoXnKCKl1kiszZVmbSTRgbDWNO4btIKE03Sui5lzPEqGpcybC3LrwdRnAvMdCKMEk/k 4JZxscKillUmG560Mo2Mln7O6oaPZVv1MDpvsNU4r0vu1/a5lHWXRZxHGKeVuf8vADoR5Kjl W9mCYE1RN/L3IqpKRb5luWzzuJKZ8qat0mH0iy4nqwnkSqZelrX8Mlg7RJxcXS7SJluktZxE 485OXq7KmcBM5xBAxAKKm7JKk2guH8hqb4uoXpayk6jBWuxDoAQP4aacCApVZVvjjGXHWR0X nFh+ke3N5KdlrSCWYyP+tEsMiIMDuOKJAnn44umlx9Lo5asWeJDKygG9osS/5YzxZVw0A/mt bGfzKJfjkh8+FbLQQXd+0VhJNlcKdqdgqwcJLhyxCNDSos5uBGrL8lbGmrfFrFoNormQRbTM ip1J2RaNkD7xPECRtk6BSVG8XApqxw0Rs25lP4L7/DqV7YLMiwywEKr/VDf2HiCRpIDYIi2a WA9L/pVWgk61oJMQtIyWVjcCKJBMKg+fjLNZlFVl8SRcR50Kmcg6bsq8xQE3t2VUVgkBPBVE mhVZ0yYABrYnxFWERJukN4K+QHFZADClnDZCtkRqOaxMSC6uQFOlIId8KmvMKmDGcqec7ggE d/KsSIUah9FPqSxWnuBQANsapJsKNcwyQZBBlE2Jhrcg77QuZa/ZZCC4NKnKYDtJJYeh6BnL SDynVEl+HJB/UuayMP5T/jtLPSVF9UqIeVGDxqJVGleD6Haeyano8S5wQPJR2Vb+w0rQKjgX UJ6AjA8IeuNs5IakN56uPJwJ2IUxJrcAHNmVsCEBR9EIxNpCzmBWAsPyEhgGargFycqzIgZ/ wi6NQQpWC39cgu+DPaVVIROmk7IoFyuHq9OWhB9QSiACsM7LPAZHvJ/1R3zFI6bCi1xVdyf7 mghD0MUraUzylguXUwQmYh1GBx/Pr04DepvGgidZ2uE/vj8Fj/xLdJIv5/Egunp7Hl2cX14N oneX0eXJDkYQTvXqIrrEwSgCXonAu7o8+SjYdJIbjSszg0CZxwkxCLNg4kgQCeiCTYDL/1da FsGiiJgCyxKozz0bPQ24PGA/mazJgVpgEFeTeSYkCzgDIPsjQbqmJgrlwIPCH4YiT4/4Kbgq 2YKMBjjvYM6FcDhZiIzhYCPCPR7HNYeLZykYgEfardevLq62CQuH0DuxYAi4RZ3Nimjr9OT1 9kD+WuCdbiHTXOaOk6QCXOqlyGDyOzlDPJA1H0Rvx6smtVWWhRyyqDNrPG0SFyZuRb70pQjF oQj3gjIsnnwi/gqMFH0GIo0bMhDVLeJx2VKKyyL+0gpMoySbiqjAZm/jlRDWG1IT1l/L/rPP JNY6mFXwZB7fpKpHCJ9K83LJoaMivSUGCu/5lPYPTThtLtA6P9mR3akmUQgaC/TkO0rtJhM+ kjUiY8sk1Vfkm/K2xmrB5iCrcYpAkEkJSGD/stMm/oT5sehxmSd2StAlgFWZcHE5xCWAnX4W npW4lzFQb5FbZSEqQzwTIf/v24qi01a4xxOjrnlZJk8M56q0kdfcULGtHV9UKRiHW2mezuLJ Shfcl6XnirBG3DxDYgRJybAZ2xBWLVyo5iFO4qrKBI5yiEotbmWOfXRkZuzDtLUJBo2F9lQA A/mEv98Cg6E+QV5GUzk+PWw5liVwg1uTGW8EhrIint6QLAN0HxeFyGDII6cagkNCBREwVKlq nBgC/GWNNZEKwBwWovdVohiqFuv34QiPup3inuJON8IwOm2rjDrOQMkAXAujGIcDwABVf0q1 nPWv5XIu8M4mghQiXdIZOUcJGsBrbl4wggQMQwdemzoyIs+qCKqYEPdSUAgseW2XQ1BLhmOd ihgRfF55JS9e4DgXS7AeQJTPY6pXKyWwEL6pwtZpxgpd25eswhi3MvyVQU1P6+cimHwuPP0G XF2WVafYqBwV8Cuxb/oQFLyJRZ/C0fLAzV6QgZKsnoj4lLXFjgeQYVZlnCxiEpuKRb+008uf jclBgW4mc4ol6lWqW09FiSbNBTKVkucCqog7mEyFmCj+IjSF2sHOSLHgViSlRE+yKQeib0Wy tkJoMobozn7NzFwYOOh4cYaJsMdFnKhaLoqCUJ8IMYK5KEX9q419Qt3tYH9VCqvHGYtmEzcd EgG0nGUQnGlRGqHLj0Q6wy3FN6e06L71gERXE30USCBElSVKURTGsv+qDvQBqCs1wRjX3lCb lQ8oJqdeqbiaZ0tycBM8lx59v6SxiIitys/ZAnYKGLjYMaQAMXYyoCkG3PJkBOydyW6BXNO8 VDgtRSQ1UAhFgxO5OUm3gTedthPfiJFOjWydza1rpwL+eg5SFCp6k82Ad3uqIwajO6aq7OTJ abmUH6EXPokuQVrtIjo/P5cPd6O3734l9zaNvOOqzmg06ZVEJIsqpQidpLolm9kA4Xm5MXpi mtuIHmRvfKjmCyqcjvwcboq9JQy6AWIITqtYdIQoI52dwiEB63oyB/cHXxKjtKaCnDU98eN9 Ii/OL95GVx9Pf/hO/SkC6Wk22xvOsul30S/nr6/f/XA4GkXvzs7fvrv+4eBg7+WLV/LV1fXH Dz+9fdnB+l506nTSDqeirR6jFyhvv3hqwwXOlGCpP5VN6nmjnV5gKnXAg0on9F47hiyos9KZ HPqF2GB2P4QQ3xEwTgRmwOd4OoWplsDfQJWbtlas2q18szvcO44EXWxqtSbLvBRhslXYy0J7 +HRd7CmaQjTJKlo4VtpKDVZ7KfUG8e5QAM/ZRpyNYnJ7GF2Uwuuc7ZHHs1oArn6NTm0gPcoZ PGAQ3HGdXKSVCJqn5yIKSAd9gTfwTp/1RTtIeAjA2jCNAuMWonJRiwRfv01zYRAL0WnmtWLj b//tt7/5zW9CtkSz5ImMAfO51EF+SeEHKhRzzugUKrajN2JxN2sc6rfemebVquDE8zSGQya7 awdFZ386eibjg7TptXDG0mhvdHRwsg11jhxNkPBI3rx496sSuX5tRgB9MSDUKp0oLVDtauYV RUwN0SuaFDTuDO4ip211DijY1naIIlnetUktILiIa1EkbmNIi2k8plwhEWzJVHTT0UWEQ8/T zzCYhI4pjeX567PTJ3gLyoMc2BSy0WwbUf+96CTWAI9mmSibYsnE8vu4Tv/S4tV4IrZCx81e Z7MMzpEzeapi/7Qz1sVWOjvdBuU4NWxNVxIy0xfp/bM9yp6uRC+7rcdttXK+SNrbBBh0NZqD AxGfbe2RXPYLtdvQXg4xwPVJKUSmJzPgqZCZJnZk0NRBo5Dn8jm4gMyRcI8ypWfe+K5jDIpB w8j8YNEsLehmEyGcTuiaAO8p22qSemKUGeCToe+HS3RrmpTtMjcFnG+SDY0FXrdZIo8AOJjI OQ5PbIjrui2EfnlOtIppxqp5JbAQq6QKORE1NlhQ4Z7VbLmHKshEssKLkQF2TiKEfioPp8vn hwNvGXiJ784xYHHcTwe0GiMszMg+3P0dtylAdAxACPaXexiGsgmHRMI22xwSMaqdeCH7yypB XseEaO51AhewBhIMOpKWR8fQCknWrwzP1Nc2CHXaJjq/ujo9jRQS8s64zXIazXGxzv3VxFbA KmYmmSwz+1VNmkUKUjEOUbXwnXm3t3D2Q4wE7mOLoVoF72umcnssJr2ohGJU9a1kjzTes314 fAzHqCjab0+E4CefYjOqZogLGECOVcX2Hzm1Wl3tupWkTOviSUOHLHah+jj5/7rfvp4LP/mk rHAi2qsQqWjfMvSkDk7h2AtK+rwpAccpUFuWe00Fb29dID0wmjK+y+PDo+GhH3XLwZFfH/7O lrXtWE/31TEfwco5vfhwdXy1fpapAp2glpnLIsRSL6auT169P4teffj4+uzjD3vR6dn796LH nZ7/9PaHEf+6PHn9Gn89Mw3q+e7vZJAX1x/5/79++ftiXC//8OKp/FMfhNuCfuV2tB284wXV Md6Yr8ZiDXD9T/HyfYMd21DcYjhUB4B733h6jU26xUKgiupRy0EIaN6/uPr51cukim8LUdvk n8GwtujeE478NU8enzwVu4nW9n0L2F0ffPf56M58B/0nv8+bPwCS+xsu45rLKD/fmf9gLzoJ /tw/6v+5++Cvd2bDGVZifxay0x4OtGKw9Ba/2SM1dh6c7mKPriYQXCJMRKzzHsCO9tZB+PzO k8M7kD94/iV4Xoy+OOXx8eNTHh3cefLFI7zY/6opP6ZTuO4R/v1bJj34wqR7w2f7/eFGw9Ha BGKPHn/llIdfmHI0PNhgyqPdr5zy6AtT/vT05BGwChxG60sYHX1xwmcbT3h3f/3f75vqKXm8 cv7A3jVhNVS1hBICkuljiogaIoZ0gZAPQtA46XLppMsDlq7Kl9emWzEIwKitKA4MU2Uan3SK 6h0FxMtZmmlwPYsGE2pgiDekdHzvwbcxjKI36p0zlakvrWlrQ+Kv3PSmrfStXk5mNrd5xkYQ vgv4+iuvBQ1M4eurhKrb+qcFtFFoG4kFBOVw63ax5LYZHFUfaEagqMY2jE5slW5lHQwQgWDK AQIRyY3YNNCGbJNuhWu2AoIMCRyaiEBUmrNQc0llsUPj6L3wLNmwzPwqXZUwRqlRYTtRvBhD HRZb4OLyZ6fvQZnwIScLc7lYiIL7maqj+3BGXtuTLPA/26F8Xl8swzpJAu+TRpq29kQjukAs afvOegf+ySJdlNXKwiMAwlNaWWLSpxrqmyICW6eNRXaTrEonZhNlGgfvlrFYtIVF2RDV++Tz KoQakoyUCfeyWRZO1aSGD8t3GFqIUEm82dxp4kRF/EYncJrLYsTsh0LIY64bmL+dUwIYrnpS YI+oQ8ZPi7XIiGIVmw6I6cXeq7OxRljFUtVfRnL8eSaw2pH/J8p9K5aYbHzr6sP5tptAkFCp Y+/58+e6yg5Eb8pKsNJ2ubYpatWC9VlCnpIy3Ser61ZjzwME+du8ET4JnMI/RbkVlZxUvHV1 cb0teHHM8xKll4aonsTa/hVdbp351HPgEHwM0yKhaXdEAwfURD0OFiq0hgGt0E8gaMI/m0QC AW+P5GkHC0Fh+CLhfcumXfYFzgwu/rqdzdK66QDQP7kqzfULYIyPRzjXEz35C2xGEFH9zmYz hgH4ux4lC0B8H/1UNtFrAWD032nz7w84juip0RBprVYS3LqD6F16m6dNE13CrqoSQZ5LwdaM 5uZJGEMMwzB0OpTUGhWvGTKFHb50FjicCR9TeGvhrBz4aAk+/ZQuycVr7x6awuXluJi69mQ9 6hcrJ5O4JqEa31PYwLoXhnCTBlHdKYSU+p6MwyAkU8yauXqS7vWhWLpGBgJWD6d8ndMBToMD IDkyI1at7s5AN0+w21wGx81CxSVcOrcIW/BFl7yj4oY2nXx0TCtc5xccyZQzKttDSJdOovd7 yuvooP2UpnCJTlJFozssgQh4izwmih8ZkIilguYWiWOx2sQaSqkFjBlyuGTbe8e76v4Dr8PK Z9kNT3UhMCecwwifN3wLdefLo55/EbsbBbuLi3Dm0YGb6y0nQYA9R3KgfT0TEIhoa+UrDHS4 u0vmZsfhrGKYlQNNClBeQLQMfE9ecjAU6mSHwZNicdK4KZWWQcRioYsAKeBWl1eUycmsdbmc 02ZnCGN3uO88HCrf3DpvQzepoqsP/tVzIRCITiGVtkh32qXG9AE9xvs62B3t7g4jpziNU82b ScgZoHAVjcY9/Xk4mPhz6YY6xDEE4yqqkUQmVdYwWUwYHlxbqbCtpR7qFNksskrMbOqZgq2X WSAbs/wN2dNo93c9B5xlGKYWi11FFWWBkWYTZ7kj+Z6/KNAcfRRTo80+SgsRnTVODt9CS3ZJ OWHGAFIuNS2H+EvvjqNVOxINCPTzcJroz4h2QV6TQzh0Iv4N8Hss4gNcRgYZ80yKMpq3lSgg mt1Bj2Rbq8enoYENjjCMPmhygG7Er8WCywNNQRHCTHDA04witUqh6XkHri6pjnb8kT4Lz/eY Hk5zD+HBcyDSdfcqM2HTWk5+rFE+0ciAAmB8HkPquejanzQJz+mgKjMpITtF2ZxajraMUbmD J8ujw3C8oodUBhzhqEmUuqwuBTfYj8rGtsly9TaaXOYC3ORhBi7cj0weMY/Y1HJ9XJ5pXyQ7 RzdCyVAf4BOkQn0l2jy19ndlvlCGW5RNNknvLtCtQr2gtNPS3sFR41BGAB4oVLyMlw4JMZKc 9W06FvDIT+TY+jGokbgJ8YjclFCjc7P6mLC3206YSJikmLnpMyGR1CKEFl9WOqlGBSDqbdar U2saZ0iq1y571lJxsoJ8QO2c8q6GZMhKXDU8jTTnexXILOjzWdFCjmUFsh6KOVgLZKyyqQ4i 8Ix6c6/yqgcyKmY7uYiZxIncNT1gGJ15DUzkU9lqJlVm0lTOidmxONbaZVMHQYabNPfT3rup 2qW1Op4zenH18+VL5PTjv3x5n48q9yjQeu+k6FxMfsyKPF3xu9eprEXU1yTI1clXQ1EJo6Rs x40BIxdG6DIFZD/g2rAvNJMd/AjKfSaoLBxsLbJK9rloIRcZs2cKSZLOwJaQ1CBqIBUVLhZx Fpik0alsN76PwEuRAVlBc8NZ5pfn4XymlE2QsrZkSkDtUgJkgzxx0U9hOnQBqS7+g80EmuoA GQzy3lwlhaxBRJxsRTSTA9indTlQs65kUifyjRfjuKrkuBn+cxHJJ8j9FCNvyUc+hsaQAfU7 pJjdTaZyURMZnEksS2ZRwD7RhNKy0gTAXLML1Tb2ibIP6f0Wy/4+umrBUE7yvFxhM9flZ5Ep vyDg8Z/3WgHnjaXeIB1HZVdOH8fYon4LBOAtQVhAjSwczTqMk3KJdZu+2xOX4LWWEhXkMgko 2wJwTYt78ha95k0bQGyTMfi3grKvRCsZAtlUr0fMEEvXLEDFMOX5/Uh/qKXLiEhTDSJoKdwy WkXgost6el9M0FVpj8eJsV8zowe24/RzjMEwizDoIHcATJ0mcB1URiyAUlXHL11FCr+ns2ja 5tENcgREx25rZPVa8FieKfsT3MlA2PUaK1aprjnhOctG5FRjn+vo1HJqdSKqm9LcN0qNW2ef kWacQXpcCiGLOpwLlDvQnDoc3R5EszKtGc1z9tPenp0V1Qf4DwFFEMafBZAqTDQWKazofTzu XA2AS3BuNfC7lmXFvVoZCktVib1+RlgIq6cRmSLLRYWgvsaii0R5AEGimYE8o9IhYy+c3YW9 g4mdVkH5F7BohNxLBKSdm0gTkDPK1o71IRRsCb1kRImTB3M5m/uQsYd8jnF2qVko1/GVTDAM d7Jmpyb57NRNi8KjrR/Pr6623Q6FxReTbJl3IXw9MDJM2QxwUMacuE2RecVtQdHvraKaOMoU ot4ByUcpi0ccQ1+WBcU0z0s4STvpEo/qTOxyxThZCnB7Fv0pFenzHsHSENV+kQOJtv70/vyX bTo/rcLlL23q1G8tbSgZyk7g+F2Rh5nPqVdBo0VdRbZgKRRdhRHpk4xE9ZdCU52jvC0Ea31i qdOpQfo10xVL3all3cCoUhFb+CwOzVyAiQSgqpI9ZrFNVt2Uq5iZKyTCIM/afIwqLZcN19pj S6JpJm3OILdl+lLeM3FUUAOJdMjKTui8zWeCOM18sT6y49hll+5h5WFctM8hBmMTBFRjs3RY n3IGX4BQh7a9eRxTTy4BLcXIUO2cqPo1qH5gZ+mlkPq5LQDvVsU0Juzx7kpKQdBUeBAmvZ2r j6iGPuec7ZYBi/iBDqfcZipWqB6uLE7OW0xyd3qtSiCm2WOiumW+sVn2wQr0gwoOZZeaiDw0 4T2NapW18AbZzBqL7oLxvhqSCOUsPGK7sWvWb62QJaNYZEhAVeJeJrl1CqIWYIC4t60ajfUk qIZgXmmolMZdRSZ3I5usOBHzzFUrYQUIy6UKqxTKgmQgIb0r0aJQRVTFGgaJhQLTX3cExMzw XyK3KqsXvpIQXCGf7uCM4LSNWR1oWip4jGbz61JsIWD/ZUUu6twI9GuTJXv3H18ehNBMqY4J LgRe6qzqUaLDshru4cU4K4IMJnm1YymDO2mVY9Y4TpG0FXiNESLxxVrOTT0rSxTe0amBVOkb RMMXDvHhlNRTNrUrXjLwxhxz54WxDKXSCvW6SVCmdi+OBHixiFdMt2XStpO5gzC5q1pTgii8 LXHL5y1DtBu6hozO3tZc8ka9VMLEkFfeIsRlaSjhBDSgYI5QyxD0iLbO319uewsd5E7W1s7C iNdOrzyFfmI/jVYPAnYm0XLTLCD9oQuQ+YhAozTTDNVZFS+UymIxX6YIDCTqvO/YV6wp/WrC e/8s7BtSnLrHoIi/fyVSBmHRgaprVbuE172ZbOPntmjrFhhts2YFamQV5zRMEHKKP7bKVuMA vY36JlofNUE9ReO5Oxy2NcvoELIhg6NXq9BvGQdTr20vBV90lsknF1k0boZBFmIwyfes2Fy3 1dZmVp0yL+PE1QyUhXpyAA26Limd9chdSi+hNs/kfUEdPUrIX8vPsvrPEGMCeZItU9qnDEeK ZicLIZ0obU5WE2EhjKZCoFvhkCtypKZjSmoPUuNVUButBj9Lrrsc5EWZEOuYr5MmTpumgVzT mY2qY7GtKtITEk5Z4dmpLA3zPjt9KEDeYXTlqmCRrfoIRVtkPKWRza0QngQ4N4LAsivqkKXh K1j5Fi/tzglwb/2O14hJQY4qj2InSalMU3fxhyLKlRxUHonIm2tERoQvSxORhlpRX1XVGjN4 juXYTlesKGoh3NlVOkNwCcwY76Wf5wJbgVdPhpaOiwP/rG7MWzNyWsRWweNyVjDazTiRwNYV RdN9EegCIMiiVBe/A4mZ/UojExduyqqeZkExEUc3MXwozNqNYV1MQg0enCJlUmvdmQSed04o H2Qm2PKQC2O6M8KSOZ+k+CCbpybUUQctHR+yVJGM3ePNrJq0i7pR05GlkWa7iigoG0UYfwbe xX/Pcvhn1XYnpidosdf4psx8WWKSklvr4JrrZqX6eR187/BrknUVA9zZuEwI27wsl7LoK9kY AtdgUuA5a8t0Ww00a5xeHi8RCHTCyfyDPhXZyMIqIniu1gvgXgY0XmkmsttiKAspq6xQkDxx rKkVzu4I9zm8o6uwKDREXVdBp5rEPI1vEIll5A7J2W2x43B4mtE4oCAzdc2viwZF9muH3z7/ NxSnTnMPtzPNsyU6AsT1Ey3OoOlSwLmVtH0TpVZ5Nc8Kb54SiLfoNBDoSdyz5wWq1nurp10E cPbmSGhq00b2WhtriR1s50zB9WuTxz5+Mq5i2HW95bpIvGgESa5M2S9rB+YEUcBpZjaCSb1+ anyXzt35HKqVlu0F9hfUbR0F2pASlJ/RxvgzBD8bOFh0huqr0p7tAXhCdZ5xRpYF2ltZowFt 8iv8uG58hD7sG8G/CYwuFAoIm55OPffsNMeBZTHcUI963BZZqw9SPi68VSANnUGDxZpRn1Zg dqbGySdj+u3JTS0lOyh7J2kFf25lw3QIt22aJGkSJABxW/e2w6AmpjaVMnQQjo9liT7xuayo 5RoJu5KTOl3A24eoYhlWJIhBwzph5/gpxzd0UGe++L1THkTRmfZYuXeBOyfNPMtLxJrRE8Sj BLw6cMit6GpkhoCASEvfIZ9Rs+dcmD3/qdkI+tP51QmRxsdGmRXBYGfnd9fIauoSPCz+2wFS gCgIwmPRGuKugL6fS2JBqYbRKllHgIEfCoiDqdaZJy7fhNBgMN+t4VaZghUlhgrhWjeFmm7Z oD6rH9EtfFaSbtkBNnC59+v0FWqaiZFkNez0hiXOQXGOb2Gkzjo0VHHVB+Yn/5I3mehRCYHG eacGrvm+g6IX+tDvLx24122uv9Xp2pxrgcPRt6kCOOyqAH7DPO1gTss+5fM3XOl5b6Xh79d+ v+HTE1HpmM6/WIy2e6/7zPVaf7d+Lffk+//GpZ/jrMIxkHHbCxyEP/Yz+Pno97PmD/u7u9FW Wje9xYwOhwfRwxO7UP9ouLs2vQUl+/OGSed8tH/wrPfn8PnDc2nt7Z+er030cy78nb89Ntdo FP55OBw9PJdmIJ381+XaZKO93T6gd4fPDtfmGe333tgbHh0/PBF7LZyfn6/N8/FAYHe1tqPj 9R3tHa/NtH+4eVa0IP1dwju3jN3zO2QHuQXub0XnwnO/kB29Ftrj6XwfXYZJNCxZOoPhDOY2 uzey9x6uQt/kZq23wJPaqrFd1M08KkEMIGPek7BdIQXVijtXz53ODyc0JHoT6vCZZlK0FTvX bcnut80sXGRJAnk6c0kflj1HCOnXtxYttey4Dln1i+7vfu4eouu+nhP+yrIyYw2ZK6PnvZyo IjH7Um3Bbsyd8/No6+cr+c92r+K7LTTtqGnM4xhD97qxMB06YdGcNWUcibBo3iXDcywfD/VF tp2X/OCQGXDWdAUx1dsYGgH+BwdCb23nlqdg8nTiklbUc1iWYvEguQhwcuPqAromZD6urf0J uppXjZBRkoutzkwHlUdUjUbf72HbqJMUJeH5IVVjl/fdK1KvvT6lSW/2FaorscRQ/3znYirW 7SEmijOH9LGs0IAwqpgpZmGCY1pY5FGDNVmtyQc2QZ1aVxVYJmIaGxZ0aO/7PMmUPPoi8Gc8 oErCvcP0dx+RxpfWOURjMBpkq8tpQ10OiasKXLUsH2ptdU8Gq6qnRXmjejhdZcAnwtGtaI/P R10w3vJl4ajee368+6RmGtr62EC8WTZjX7BusdCPBqYHQbFPNWG7W65vcaUR2C4rOPJKpjfe RNspc020qJBlE/1cZJ8VUWT9g7s9UbTkHMYB+7H0uqrk5QouldKZ37bN86ugzx1PEt4NZFtG yM7UPooAryv45dzCImdodgLaCFBMtKWqmbCn34N1/ZBL36Nmf2Ga8GkvfVRzNC4gEx7l3NqS TGHhyqZp49fmsqYMXGs/VcBqAyXIbquybCwWbyTkmXsCMzEkJR5Gq1mJ5wUJZaATkKeW3eyz mC0jaMpoNuzAjkmwZIBCfD19fnwd9ks4LyZDat1GaidqTyVd/kB0VtwgTk4Ta+vk9GybKIQ+ NC3bP+49f75H17PzZN6kzqhiVxLt1EMPoHa4c0FxcqJ5Vd76DB6wq3k6Q1/UlaOuS0rFT0hc V+mgzZ0yy43ilnqyb8qWf+C7Yr3IZrKw74HGN/oOoTyPl7UXtrLDuxscRVtq5YZBANKkaxQg JMTsaNST2G4gdFb0WAC4jC+T1k/qLPaZ4guymHGJfB+kcVdmT1tTTFaVAOZ3jw5IwO4IlUqD K810id5WsVioEzvbrau3kJgnSs7kuDSmPR65YFGSIgOvCuyVgO3Sf2gmU78BjtIBdTwVb/yn 5tWX1gKgXfqkghz5xWhFtWDmUSKvH+DLc4L5UA1Dw8HBAwkfA5/ard299tDRN9qS//64raoH C/U1eh1WfiFyXCKzjJntYfmbxpGslkb4r+8PuD/ikZoetGa4O5RRxVcsd0uzZwjFNWeFp27d 99FrEqhgCwSbNlfjhB8P9nvJkMZCf9JuZyVegz+1jGbs6QW0ldOcp/nS8SIm3lmaqSuY04at uTAdUzL1vMl0+qd7J7uKrUUpGgXqrvtuhChEjX5fUzJy67kLXHPbulUBv8iqis1kjbidouIQ 4Bn7kU1w/IyhsF8VIAiFq0/qPOla/c6qML5TufpOj6xrYeaSiDVHzreS63qMCOrTRVeu96Jh CDZPpw2XddPmSCcwelkL9LqOSQMBBlXvd5d69M5pjxFM/ybhMw9SUJaL/bg3+rHXdTHoapUV hsTTiuudWM6FZS5bbVer0eWu/dC9bZlqBZrzHh8oKej0momGFDaXQitLgG9W+FMpGofmbLHF pnUZcz0p6YDWkGFzm2pLxFhhxjxAgUa79JOGIrtrONP33PWLs6AsFExcOmfClq+r6DPFFe2M LMkQPYOC+JbqtarPsypONEemXrqg19QtcYpCNu2XzJJTnI1hbhrq530idtFKJlCqXYBYLRMV NCdae9y1aLYWspu7XQw9irovqcFGlsAKh1CXZk0Qe0ahWYREJLVAyIP3Dn7U9pSiFTbaIRNn Latx1keQG6GxsaLjyXa8vjzTDXr0o/N8K2sPChs5RlcHlVi+qCsu2GrIq35kpQ86PG939cIG 3qPdXXhZuDi2m0JU2DsetSTHnZOmkntlyW1ey3hieXD8oxXqBt2jNLUodnlVaKg+RCld3S5i K7/kl09gkzT2pYaAHLvqkqrt7BGFWvq87bCfnqnWtWZJFJ01X6dkZtZlmT53VzGMjHBtVwO0 AYBD6YJ1tYwka1oh1QSXFrYUxRt22eOpySxWYIPd6LrKlveqvG+0AKojLOa6ytHXptpZKqEp jcGLrpIDZcxFl7aIPlUTnMA4nZZaQgCIpDkYpi4JoTTRgTTiu27uZcWdbma+n3wsUuUzVKB4 ZmLk2UH0x3KOHNjJJ7PBUuKry3Rl/K6xia/n5ULG+uMw+iVukOr10eXDnrL9tswy0x63PlFW cUFzUtn/yjKgHGcIbEVAsmACeWKtq0Q4pss5t/9ZM1ysdNEPD45iCX20x7QBtJoL7JUN7apX y3e8u+eyd12qQx5niWZBq2Nd2LtpLY4R38no7/Hz4FDdB2tWSXeqsFx7HO7crFfuhHYGqmlj 7bgr0qqmYVhN0i58bL26xe5vRZdembUKUlmkzbwkZug6wc+6lp4Tq4uRk/6fR7sDKp9lpRbz 2el7bVmlW0NIXTgtle06EmGK1KeKRmtc3y0cAZnDZNhxao52GGcn/mkFhYuruLX2iCLpJ9Cy btMcXp8h9xxWAta0ifQEM9Y5VLCafblRcIh6zYJ3m3hAq6/On8UCqSIzDcLUS1Roaw9O9lRN uvZvFF8mvuFQilfgOzH0Nub7NytGpY2yXseiU0aXzH2vLQhNenqXFkhwZzQtZSU7NBoyaU3w VHrplmdtxBVhLQXDGKPVw50+/XjtMNasWqSgpi6kSqWE3MfZt7TsPJaUY9faQMsQG49pXVC3 jsclM9K6hYmYgxrfQ1kygxq5R4kBy2ybq6dHWgVsLU41YVRdVYMumWtg2MIyu7VYz9bH8w9X 28os1I9wT4fqyw+/nH0M+sIGk1uc2Gd4J6FnyrWaPV3jkD5HoK89svsyCiKgy7EYIuz0dk83 uUE0EWALkmriEglK/QnM+LOEjKB5nJl9WhJEZzMtolA3vVugNdC+I0gYqTRjYq1Z612bCe1S 0eTg4sOVSTQhSN+jDscVcNKuYHJ3+AzfQb8IGg2aTkG/JDSs+2umOcvIfML0c1nzwrCbCQ9y 4I71o5wKz18sdL5/Ku9rgzD5aTTQ7HumkzA1CheiXJRV2tltQGmIOzPRwTNEEdgZ57yMI1jE 3Qgjl+IRDKvf73qWAXC6EP2FPna2/rQfXRuG7TXebp7K53vRyRIIdOq4N10OpGNKMqZiUpdY c6Gudek+En3t9J6iNku9v0C/6aas594T5MQF0nKILsjlqDK7OcO/n7pSlLClyUUpFkaZx9Gx zHpPKZ0mW5HNIMMQXRa4SWVzqvHgU1XYjTA1E9bKqNC5Gfa3m8g1GZFdu7JlPemgcf39HAHH cnlqPQN6lcB6sJXlvzMDaaqSPAAQbzq5DrrX9JmvjX4kcofEEsgqETpATihyVuVcOpeURiJ0 fo87MgzCaN6WAIDGbd3ZEDDApo2ewpYC9DYuLBAky8LOtfMFzzMrUFW10BxGR9I1HFmWDHHa dbqZqNgxmF3JwVWO/vFf9T659uLuUJw7XCvXnCPc9RC/JbVN6dXeMfNk39re7x50pSZHo124 6s168AAd7ZqyQ4Xd/GZrLSLdy+G5d9093RBBSZ2azF1lnd1MYikXifZucp4vPM+KVSQ6TtFo WremNzlrR1Y2hYFjqT2qumodiQjVPJuFjFb9Q1Z2WK81WX5gXy5a+PHq6OAPkW9Ua0VSOUv3 XQim16NA2ELDPBBfneIVTi22jk6unsKa1bYBU5YLBQzh2iYVbsZ8q5+gDaKkTWsAnSUdJGGw JNrdDBIyx0AJ3nZX7oStPCDaEN9Kk6ycVD2pZuLXR6R40RFLU5jq2d21Eoo1bYJJluXr5qBt 5ivXG9IZRneEoXU9WeldDYH7iBQJxzrvQmEEMFAd7o1gwR0zp/4TagY+ldupl4P1rrF3/Aa9 PhG8kkgOfs3gy8KbUdZ6q3sbz0F4YC1PwgrRAMhjqMDWvlaX5M6XsYig51FwxU93/Rj1E9PV fSBLA2aWFk3HkAMWsytp4LAwOXHuI0ZrZSWfTP2m+cqU8/uz0zKXb0wtrmuFbNEqS+EXKzQr lPqbyVytC3+PAh2V1jQ14SqpOJvDt2KSYqtWEG8aKMeZlxkTn8IHdlBWhd0ThVHgykvKheuI UkG5SDzMfeHsEo00tF+Xet2XVeoA05QQyeoaScDCfB16cInI+t0h5hNHC485g7HuGKdTvZvL 1fRps1nerVAymdqraxRQB93hdkUX4WT9luJhJ4fReluNLOiLGfbY6LXyRSKcoZaA9cX5y+a2 fPH0/GV0uNM12LqbhaluWb3LxOlwYRzgAR4rItexJdzxFeZydldCrAVBelcAsSWfJn6ig7ir p7LGbgO95C+5p6lbHKZxmpOj64e0718rXH8U19dtjWVs0tjNuhNX9AoSMnY7Dwtl9JwF+yap b/bijyBxLkGNjwcGmig2rfCBrYvTi+2B7po3z9kxanM/O22VUOzTzb0U6Jg29tVdMgQQbGGJ Jf5SG7BZK2N1Nwu6Wa9lVneYzWqZkpohPXQ2JrzHs9KuT6jXXA60XFTtt93LeIOuS5Y2RDwY HgIUc01UiHmn3qCPn+6mgDRPfTA+vrP3453beHUnq4C83iAXMIaYYND6eFde1j/kgVmMih3n Tz906PCQ0/K6o4TT7lqie1yXT9ET982Hn661kS03SO9qhguUNL7rexkP7rl+QBe1ltpjPmTw X6/8aE2aO9fwzqCwm7jiC3Rn31bcEaxzAHNw1WDjh9ihcYbwOrbedRLKVrsk1eBiAbs2y7UN CiPlr1LeZakJ/ZYQHTZXd9mzauXj+AtXbhvekKdgbJemn9oW0InS7lzUZp1aLmHNSsE/eEGp m6O7NgJdEOBesGbk1rDT51xbQas1BtCCci12qR+8pGU9s96Dh0Oj7aV1gyEvPv5sfW4skXjw eMkmicAl31NFhp10twquNnp5BoGMykayHBC5NgXo5Usrc1Fljfq9dRCFDwW9HWNrAbQWs7yL v44zxIyQWDTdlTCvL52s556VU1po25y9A7f8fkcbFi04JbFEezgrY6m70AdZ9noMt2vN3t2h M7q3/fm9N8aMwhtj9p8duRtjDg927+SLutGjM7/Fy3CLBGj8Z1ma8RvB4y+3zg1bKGr2QmL5 6v0bIqgrCVdIrctFJ+cfaGvhbMyHkMknrBCbQwwO7860hvrQFL2iiFsTY+ubRWOwSGeat6M1 X5AXi/gzK3w61WFg5fBdVwziynIdfPI/OVXnwFXErjrEexRdezzqet5dpLEWFHYdiKl5+4uL fLkkuNS92fg9G25gNxgvgrtPfOufNczUXON9Ub1dID+seqBOduAvTrrJKnM84qpaLak0Yya4 7IGCuh+LYRT375P03+v9r+nZkJXR1fn/OfthpIniIBY2+jcxusHLzx571/ASb5sc+sovnj3+ hZYNyPuKX5u/br26HvtAs/LlA6btnvdfv5MM39uLuyqC1xx8eRY4H57C7nj8xU3ewd0M32Kc b7aeva+AGxJ0GmqLYkA+Nva4zT8NhBX+o98TO3AQnbbfarhXf9PyvgjO98LbN8TB3eejb/TS aHcDxDn4B75z+BUQQ1VTZCVNXx547/n+fa+c99/aP9yFK+CxwQ6Onm8w2OjowcHW3rR6qG/z dm8JBwdfAc2wFOwxcB4OR4tHX9rdffyd/fvfOb9zfIuNNnw4PNhovMPdzcbbX3wFAM936FR5 bNCjgx8H0ej2G712uDeS9w4efe/Z0fGD762TgRvxcQD952MvcKz1XXwRiq//GVDc2x0dbALF veHhxT8BitzFwddA0TkCHxt5ZxNq4aaPN9rKzreY8PmRbPfo24Bu5yuAdkpTauvi3a+PC5S9 +zXeu4xmI059tNlou5uNdrzZaKO/crQvK9NMwNj6ZXuDFTzbVOYJtDd88/mmL24+9+E3eLN/ 1l+jY2vE7pUYwTvqkN96++pp/Sh+7g9HG6HA8BjOXphNo2P5d7acPM3KTXYhTOFgEy1oeLiR oB3uPQq24cHjo3yNvvMGF40/ZYOrRzW+f4EXjjaA9tFG6uvXqDQIiW0Go6O/+YV/DIyeb0Sj XwGjjym6aWwGpL29v/2N/0/B5OufN8Hjw2/N7g82HfHZpi8e7v4j1vgoSFEc/k0l6N7GduvG p7T55MffXirfJ+g3QdTRjxthy8YL3t341YONfQFHB5vj1sbouvk6R38dwm4E2c2Xsbc5vPY3 xu3ND/ZoczIYbT7o7tdi7TmSPSzavYle9m5joO29293bSIf73xuZHaNNh3v3dx5ug7Y1+8P7 +tb8hHo6uyPTgpDvENc+Q/ZqGI3UIbe62NdNnLea4SPbYCvnSY3Fb98Xt9QrCBigZ7FJhjgY 0n16169b/oH90E/a6tL29CVXajfVQozSulnrJLwCpR6wUoZ983qVNmGmJLKTUOWAukNuvHdh Fbu/60Uw0awV4BWNu+bkTtVY/6KaZSnTrN8+X2vTUP+pdZgd6NXz6H2C+KCGWBk7jZd669QC t6poitFDN9z1kubt67BXaa1Xf/LiI40498F6f8eRIFZZsx1ZWTVsUz+N2I1b/pix0YJ8p9m/ 04zY5rog52X5yRLzcbt7t3xmrKBkC6Vs3EGX6GxN0y2HwEKhByj5DnKC1g4qTIgQUKHy3825 YyDNNMVQU5mZ4aI1+l3DNjX4LUE41RRXttRAwZe2k2XC3228GrrLudAk0ZpJyty8y9CHxoMl Bp1sYmYscU0Df9dKji4dzIhC8qbeX9fd/NnwPjHfmFPbm8t7evSRWdZBVQwIZS2HChmA1tIu 03TxQvOJtNmPNY9zPWldI1CLvgsv6M7HFb0wmm3V2f22cpq8j+KSMAXmWQfkA92d4ultSjzr Lz9Y78BKYFz4FKVTmiuIrP9+a79a0+zLW9f2xDXIyNNZPGHPvry8De+p1RY9OEqmGHQXL4YA 9MnwXXm56xTTPoSVyOlHEjY7uv4Tg+wbRac3jJE/9hrOdrPo9ubqQI/sg15oj2YNPBoA/Y9H 3/jbhzj96zxkJIS/fYdfubq/Yoqv2d/FZUjW33rqv+b4vnINm5zelTXLYsIHuOk/ZKsn3/qF L0erg467V8rsH93Bf/z9T+vVzrfc5NolfJciiFeb7varV/JXHPnp1y7iy7RJvRpyLjpjQfKj 0+/867GnLycFeK0ft0qlN9+CLk++NYd5dIQvbvHM3QSy8Q5f/f13+LiM/JpTvETKHa/v3HiP p/8KkuY/vtpiP8CV6dZj/crqwGi032OoR2+c1fbeLK43av18MZ340jVXpw74BJa4KLjsSLpk iay/y0xXsSpb086zxcJEm6veMkPAtYrsrvDoWvLrtTyuVMjKGPqZvizKrVG2n/GWTitYCq44 8h0LtGAtq+2qbtbR+TZ26Ojp7iXx3StveIlltHV+9adt36KCF3hW/Yp/bxUOtPUfCjtiu/vF Oq2Zvb5+82WsRgS63rFUq0rYacCvDffnFMGNHzg62CzhTUpN8NmHMxSJ+eIDV/qhDTOHQTq2 rgcuG73HQduO8CIFPzYL7/STS69Qs4qeI7h2m+FFwP2k+w/wfLQV++gQ+s4Ls5SHrSZKZ4u4 ynh7NNwcc16lhRoof2Ml2vXkdoO2dkfrRI9d1ajXZ+LGhomvnEURhmaMZ9ZVro55deF67n/X 01MvVoAdyNKH3mERMri2sXG34WSVb3ESo5uloYarKxq3K+380XU54f0IrHNWoLv+SLyIerjW 3971a/U+FFfqaSv3TWmsMSMa76KX3Tz1XfjNCI3Dspd169elypMxqkNhveNAJwe7Fx+C+BNt YLUjY5TTJ/e00rc6T3k1aLqZ+tp29PtT7+J6O0MtJ4VDI60WPDjcCa81sL1+dKFJrT0P6ia8 imXdkwWoOB/WMPISsdurA3zdu+TEtzibfLKaVCLNml9spS4865vGuwjQO0CbR/g+m1nT24Tv CAHutkYHdHUQkbUziV0eca6XYS69sOuW35Stq7PjYWOsKsX1hGO2CUnCq6kUpfycO1bVAyID xNnGh/65FCXr6A9nl2/YHYO8NHrrzc+vt61+oKudck3H+KKy1nrovZdWftBrs8J7hudoirS6 29y0o22sBfVrMy2DHq96rQ+dE8pfEzxnnicP8PUZHDLoxGo+RdcCjO1n0L7UGl3LmNq6doga P3iB4DgMrq64VNcU99CtTFsXoOMGbw6Fy5eXCLHFRtLmvOXD3zNT3+k31fmdlWnoBex0P/pq NbsSmFUcerkFa2Zuoy1cC7Jt7TlYxxf0m2GNb5poy6GO9Tx99eH1f4vEf3d98f7l/wNQSwME FAACAAgAYH3XKDMBGuKmHwAAYCIAABEAAABCYXR0bGU2NC1maWcyLmdpZu3X5VobDKAkYOCD Ii20uBaKOxR3dwhOILgUDe5e3Aka3C24uxd3KFJcirsU9+w5exu777+5gJnnGTkFWX4BUy9E MqQHhP8rA2ESYRIOR0hNTX17e0P4//6//2dQPiEjIiCgILD8b/jfToijwRE+opHJ1+X3haDh MhmM1hUMRHyhVsyWry8ciiHiAq+P1heNxH+TiiZTaChWiEFAoAEoJFggprEDMdzQuSyV0nls W7rGXE1UUvgtnhcEFugls2WSp8+err9phEiqKuYoNldIF36pN4KAmyuXak0Gor8qtVStNFrP VxhOtFSvtWIifkpXaq3Z6PRCLZ6caGU3rMELASN33RQC+pUaVaQ/tdbLtXtQzqSw6Nbuj6Zc avScpdXvzuRLfaS54mjcmvdRLrqwSwi0nbMwjclV7gw8W23D3pye8j0/3ehGteVBF277l1Sh c7NR6eeuiPi7SClPpbsj8HCx0TYiF0c88PLvQAycQlVUfPz6aD5ErLZHxHtmZCMzHBDQYNk1 eaq9+ZrW+BNhFhHtm+cSCig/CNmIzyR4DrPtbxAq27Kh16a/ToE3gWUkue+pTdtmGEmw9WYY jQ+oMApvmE/fZcpm2CwGbk9P7b48ZV0UTNVRSh4h2DHyI/68r3QnQdqB1jxRntxzz+wbK7GO 2VeBsS/K8bQ2+ykgy/L9VAOP4/00k3DGg3Tz1PJUFWvycqCnHcHCASACm9fAk9diiCjLDYuW KNuBE3ioavmB6Sg/lECPVk15Flkrl2WfeL7QiY2ktNCPlwlanGqUCSuS3UBmzI34x1hRUJwK rkgfytHTqKhwGANXUnZHY9gm9WKPMwIbpjuoYkv3R2yNeDbbDOv6wXyUCRIHkWe+42xCudAO WShZwN3KIVXd29OIWd1n2XSTVkxRtJoQTCqG7fjNKC+qcDreiZqOi7hHo4izxTWWplnR253a nvcTs3pOnI9O7iOC+pvxH2IinPoZD07r5FtFWf5JPgpq/UsOkRibHVIJI9kfhH+LYLkepUmz ux5jkBvjSLUWbXEZpz/XPcwLnBrDL+ObR7fWVJSgBWeLxDPd/uaCH8NgwmOA40lFasybeTU5 1rsFreRQhkJusWfG+VTZ57JFBXcIXq6xb/VdSY5PDmNREZbO3ZoTYabtutG0SNmGW6egbXW7 TDafjJdxO3vt2/NL3vYjurBTWwwpaW3fR66zgj08jemqfYzSEpKA8gJtr+Y/J2ltR4vTcs/G g0lCX1vRmNp8TisIiTqDb3v0X84vK/R9w7ouy672rrWN2K8Gfiy/XGLU+nZ1d9aWCuwUScVn 3MKD1vg9F41VhQ4oXNi7HuKlyN8b2GPOHrbU0wK0kq9JvV/rnUisujhmzvMCgKsnRbXw99eH Szjc2ZUUAbUtqeZt0kbuJkPDXBvKw3rOkK9oMht5UF52FhuMPJn/gW+0D8vnKoSuU68w8B4G OI6yTIrG+21n9gv7hIVBIAb0SVeeN5fjSyj/ZIEWEp84+Ukdpeir8ZeAsqylZcXAH8RmqKhL af08I1HjpmYxeJ5FF9xsLoL9hfHDcqLhzs5SxmeJBMn7MjZAdrdfhaqeaoeVb2UcYnYd8QEN Kax89x+FdoMTyJ0XBJdQyvTRNDcvxAdhVoZxXkMvapS9hFSynJyGw5o0XUmEo960M0kETKCH i5SCfbiEUrQNNxlejlQ3kWFiNBfJblz/I4u25WxMkibtk4ECpZ5gPPieujD6qqTnuv0zNX6R hgx/OM/AXpLZoybANH2B3pIX9wfvQgl3qYIy7VgUa8K1JmKEN5f9nGPwhB3x7M+nKTCTdPZn u8yV1BYu4sWzIAulQ4yvjwD0+z3GVSiu2bXV9M/nmzwEzDJx5/8UD/EWBIj/Ea3i4FYYMzVl f2Slk6JQ7M0+qsxNOdGc+mAtKOiios9+ckQGl0zYYnDOjxM4VlQUyAjxwWJjkjkWN+AiWRts MudLOS6PE0jKVpwv6UYCWzV4Kp5jA1LFJcEa9u1Fb1ELempfbQ6pXDviLWHLsjicOu33RyOi lvge+3PF34SkR/WoapO3mG3pZiq0D86ny1nsbQw0fyz8wb6DAkRARncn3fo+X6JkNYjF0nR/ 0f5zYyYVqlIhnFgeFryvT4DYjc6ZqzoRTBUGdpusdRD3NgFbLOT9FLOoiHg/YrVkYgPsMYXu 6eqO0ZmLgZQrdHfTi+RTLW3N5/Y8Mvr4kjL1SZg1TqRFjY0C0ep03A4Y7bzltduTgczz586q j/12WA8d3jeMKvWdXzJXh2Hv82ye3cjr8ZEPEZL2Zj5prktBBTi1/sAKogcf+Pe2nYg4tY31 pqsJY01ONMkdpO+7LeP5CHAdcWHwKUhqr6ah5S4JtXMj5O259VDvsZ9oui6cb3Iby/dx4BtW faTMJ8lfihODz5L1nDM2O9d6dnUdX2tjrQC7JGuPw/wqzv+ZljEgvy8yplZXzRy4raCTL3XU 8JC6s4L09pBORv/hxSbP2poukbe3dkLOVzB86f0bptroAS7pI1W8URWprX+GtNALsiw5Dh+n nOJc4dFZlpuyGS1/RPJzToX1XHrSmx+5tj/uA46sc1p/owq4JQLA0tIh0rMUbhwIlN2VbXFz xml0674ba0YqDzxe/964/T+j9xyOOce9RG0eF2ae2LZ74/XqDH361go2OS3BqvrA+f1++Xl0 O1Hek4GqkjoIsnhA3LnU40FTFjJl15zLW08d19JUqnwO1n9ZXZ5uaZECkOL3PjYJs7K3dX8l JFLKHNqd3lLNPT/y6HzZuIrzzJZY21WcbcwVISDNDDn4UfhN13pHy2TkVdqB5Ef7pElMvZ2n /oEy/tJ45d25rfNBOcZq1cD1dNsw3/S/uNoy9fHmRtebHKsDXuG9ldt9R0LBazyC9d3v8E8l JbxwV0zO1U6BKu/JUpeLiqNsB2gUNak6K6FaiezRN5FnEshPNxBXzpHtLXscWaicAzDnRIdQ x0gAuQL7H1vfVbA5HaU3Sz1JQ+r4s0/H9I0BWry/pIWV79IS01hL59cLo9LisMnluSd+Z3b1 S9+F/z4/8u4oHFufde5kqXjxhE+cIDVSUayEdi/sW/f11rys/nHQbjr1P8unoDk8xBLed347 tY4Q8sWAjVlE5N5lfPbfdB3pxHV8uW+b6b7wnHnZfDFaVU7SmEnJ/h0q+EWUXcer3ffpeqIC 1OhRwW82BqiHXLw+L8+8d/V2pSorl/8lNHq0dey8PnTwfsVLK19bFrAggTdQ/J0yzEt8gPT/ Z/YlD3kr6lPGtUr/c0A+r6sqGrKq3SKXrZlq5h/JSz6nrQdlQigXppcy8ZKfhIfZqmcQUXoQ SVsQ2XIQeSRZ74j9MI3L4J7VsI7YnmyQU6NRhbZiN5QBfz9QCdHlO5EynkUILn7IbFMIEYp5 TqHa5z9qxNKs9//UNdxtpBl0MiXwZ4ZVzw50pW+1oiLcFCNZK1vIZG6DiJxdDZbDDEaDa4Y1 EP6GmYPCLb3CY+msIj6Ez/+w+S5jLWZl7bQs5ZQaHszpR4wdsRDq6lkWTFgQIUUUHMwf2SuH EHoUccClkwGzcecxgYC8//GAHXTAz9QaMjpyJa6a/BnWxLL8rIdmOsjaJss3gm100VtJJiMH CqHSdhO72j3h3lN0pvcygvmu4Mw2sCaRV1kRsF7KG84T7X/LirwYU5Zu13Ij/4tXob8o1prW Y4RfgAbOGcM2Gp7+L/KXPPUVimjSsvc/WshCY+T3BhsE6rhdBmN9GvDa8nc9NPtTBg6v9CBV kMp1MoekCyhyOeTmRlV5WXfoQfQdDaCGlnDOn4Csm/DBOwEtIwGjPQFNQfe1VVU0XEKMVwVm EQhDSZSgTvys639VmtgPtCAdC5Q5SDTgStxNSyQT4MZGl/iy7MgsnZS4n8BgkwSnF//tKXWF l/Agl0zHqMdCHyI4liApAMVsT5reC2Hoiw9KhCIzSoqPqnE9OknKg7w+pBjzpiwQOo8VB3xB cf74FMdsBdDGjZfWTY2SjQBHpjp/iKzrT53bS61AShOw0ghBSiWgTBMcjAhyN0vDD0pz9YgM JE5ftoyMOILM/RenuWAzJBkXYxNnjheVZ0kenmH8ZhoKlAdCBYBRuNHG+6xLXrYlDCalXt5W h9H1EQrVXuw2VnanSQIp1mFp2ILPKFnWTawddLG53loFkVkwLzbTQ7vRcJnqI59kkIA5vekl nCMjMiRdtTi9X1Jm2lvrWD4bupsuWphdKA3R0NGJfcpezCDfQs+db/e0fPI3181t7ktbIYw/ +/DjOhLnhQjnEN0NeJ2LlBEPtyaSEAAcreS9P+UhkOQjCeYj6+UrJOnmYgdS2eSuDSaZEnMB WnTjYCr3Vo6YJCromcns5eLYPIHwcF35m0DKDB4cxUJa3UJB6YI7whRCpngMRQlpmPl3c7xN whTreRW0I248JtWP5tAPz0XiJMWSgsV9zlKv7ThIT5xi3uofjqFiRKE9KCXb5kUSDABQuwoH QQH3aootL/REl/eKMe9Gofj8KI3HEtYUBOOCwQr7YLv7sHzE0mUx2lJH04hj7/iVEmafFXsv RT43EoLVKMFoojI5K4jhXeQ2umyiQO6uQk69OdhMvizzCbJhQ50CLo9dLYvtKIuFY5QDgRnB JOG1qaHNK+DsWXAzqGzgCAjzKitkzGwdc6/Szbzvj25U9GxzpcIIz7a6ix0pii4niqHbKa8d Nm6Myij3CUtjzGrxAuYLsLU+yRWDbLuI2IaJFQaTY8faYkuWKmciKyHFdh1c2VGh0SPENb/l c60oyyeJZUKZvCNJcoDQ8hgmcDYTeNAn/ey5Jo3k+3V0+RGotoCgbiNS1FgRZu9ctz+WW8Ih dqCdd8YVr9KWN9eQ8g877xy9/tE77+9B/O6iKEFMHZVQA41+A51vA0NWg7FZcYypPwOJP4OP o0BH/n1y4I8OUDtQj+HYkfok4fRD0O6gI3ZGML5AcqiFrK5vf4PwWpGkfoEgcwCyTpPQWuHv 0gZt32ZQVrNeZ7PBRzUWXzH5irx79JYfvioox8W80urpDSE4KFCeBTVtwZA9K2ekkRKDaAPj lVITEqKb8lbDGP+ADr4l/DZ7gTZHm7YO6Ta4+o9Sy8K6eF4DXz26OFsjpGajc6aKbf6ypf9q 949k9EvL6/bakZlFLaD4K94d6bB2L3fFwqzvUR2UBacdt0ydJZXseSS2mY9aKoTALqWYB1rB to8avQxCnei1jQPAzmHbKV7To1WRjY7q9mehQViXw5/MIzOFYt3sYz2f6WV5WhwIzLYqnbii YwIc5Rk6XsGap+g2wPxtKAa4PJqx8jF7OkZ+j6lyabx6dqIyChlSJsc+ad27sqqYfltti9Jt htrTEmOTatteYauTM9wOWekotq2tIVVq1O9LGPB8nftVePsr+752UbGTRrguIaSv6JQlyqfR 97g1gBk/+dS5zy0PrnCsNMsTzwwrxosBqFH5PVpzyLebwQlbXEi5xotd+Fla8Cuhv6VbJkeg gmiDUixDagotmmSDgNd+va4hg/Uho9eh3bB8q2uH09S6t6VAvxhHHHm/oHtAHa0+i0HUdVrj +eFPfLzUU74ABWoLMd+C571h9A5x4fbhkyULpNGmaatC4NowQfuIqq/fYYiql1KK3gqvmv6o 1kuSgn4TBkOzrmVjHEsBp+1obmwA4D+Je+IRlX2LCINCVdhYLlnCp9vx+NjER4bk0jNlK4NW SIlF9R8r2x8juJ6JNw+NlSkGv2KtOKA/QSzOJLg/pwxaImWDIo/66Sv9DsqLOT4Nr69PIW++ Tv2Fk03vCE/vGUwfAKCvFZH0aMnKkxOTxQO6gEElc5szPT8qKI8/r6SSh0svQHKxxNLkxFyp c6YYZYJMZubkU8JDdos2cQmmSAmbVgn4ozqNTuvGQoutfhD+sCyBZUxBJn9Hm9sjIuCbjpUS QQAe35jOoksF/oylUCs+rTXrrZgGmi11WGh+Zk/Fa4mJzRSJodlURUz9SrjNIBmgeBxRb/6k s3OCo6e7krB61trgtMpxcBbon9FwQLXGSRK7lmcb+dth9I8fLqnrI5EJ6/9s3qKNzWJi5m+H grZkbZLgDFPHtkVJrUVP+6XtO0s+nTRRTGl3/kXW2AXa5lQNkWUjxKXtvyXLJvVTn/qWLY6X N9wNXzD61xn73wVzapXAUOu6EPCK7J/aDMyMYsO6XP/FeeuyQhGWrOruP+Xlm+mmwYRzEp6m 5N0xfrdeRvsxNYLuAaHump7u7qXe0bfR5fSeRRH0OaU+WaXrjqVs4cRdrSLlVZbzzym2y8rf OmTdOzOyap/XbJp7cXi7Ears2gS16+RNvXc9ZVkX5BjCJP17rpS66p7X8ohiN8+zejJ8Xt+i S588mk7cEf2yez94mOFvqOT8BXUvwMZ7+ssEFzCiH0WEctA391k330+rpyozJ5R715gz4LW6 Itr2culCXk40bk2G3kWM3vlU2/Go8sMx9AkMvh70f5OX3Z2X1k3kuuvkfL79XLVXnqlQ1sLJ Vqyegqy77tWg782jra42rsYVrRCvr5BCVqGCe+HR1CU5e3WGUa5v+ybkByT3RUn+01uWB4HP S2RL9WxTxXPC/v/z169C8kJzRK/LOSlw827T643W6rBt/TCE6u17Bt8H55ftaPywjo5h9dab R3HvRwnkx0mix1Cj49Sfx+m5x5k9x3LQSdsip4OR5KqSlHoevf0l3QK2E5ao/HftA3W0Jggg +ZuewxN3k6ZSI6FhvOiJrt7zQVLYRBTL6VfFU2UlfzHWszDKYYBGZwEy6JAM+Uzvfgw66bRT emIIpp/Db24ia66enI5HOQc3qEouJneuB2wSFMn6FnKOj9VPGv5VOevo+lnn4PLVe6gOqB92 x1W9rjINnz5+f79EoLj61ma1zn1EcMTZtXDJc98cSj6l5EePGgA9jWyx5FXX9P43U3XJchsC BIxq9v/7BAnhGQ3C3fgnY3ednRIyZnRNfTwo5jF7sV78U2XAk+2KN+AGJTpcsPdGeOtGFH4j 7hjusyGWMCUmM0MrVyumUEurBOdTjqdVvSwF60ZoziwBA2CGynQ1NaRB/suQyoPkjTt1Rxz9 gNRwQwaLLRJI7j0Kxz215oqkA0Qt92v1wypj9t7y2C+Vnvb0qVWNnw/pRVe+TyvOFLW6Rg8M XfteFDu6U24X3X9jPb1UNzTuIUDOmp2Ht51eyFOa8UOv7l+haZYw6G42ps+k2/n62NjjLmnX iA84a8Bo6CWm0QNiILON+7O7paOrztcDsyWzbzHzBLRfI+b1JrNBjj9XRxEL8uyKA72gWm4R /NxGEF3/q6iwMqFz41KD9JN9fCVq6LNMKiMQWvvaoBodkSnno7XN9b5d3h6LGd4d7SM/ZN0L T25380R+fwa6PVxGpdRuISAiBCIEI6HisHh9KUAIwcDFkF7+QiUVhMhC0gXC/iEbhcDyoexR 3VwugZIvmiXKZU8unky1EFlN/ACQyWO/OZiheaiSK+L/joyB9wuhUAZCLpMJLRMvUc4hyGlT O9Gq0ChS4QEBmYdSmbp/AolxzkB1ZmO5YcRa53ot9hs9+wK3xwbFgONNwxOn080wnaf3/Wht p+G+kCkCOlLcC7NhyNfWlJi0GsMx1zekTR/ixsW0yF7y+zN8t6O6eOU82Ry9O/AiGLMl/Kv+ vd1qs/0W7InkwWGz2x/+4R3k6bQzBKGQw/L1cjmYyukkENX8t3MMnyf+GBsjcmFzDqkUQzVe 93Eb2aglJFLtFn6+PRnohW+Q1/g9LJBmwj4bWv5sed2GW9m3P110qvy6weCeEYXf/lcngUoR +l0Snb64TvIj++B3KUy+vTqpz2LIHNLYcjT10riq0hwy+Drm9TKExqEcssRWxfWypI6DHHJf Pffq5SgCkDnlKSOkf4tnHXE1FFETTrL2va1SOynQtyvVUQ+ld9koUvXNN8DYViZsxtN7oGxi 1HmAS8DCZGXNFKvCQtyvi4Ou67Hv802upRw5XTgK30teuGZE6l1vZvgnpHHVpG+4m2b4US1u 1RWI/ZN5BQnttQrF024bFNiNf9wIKQrxcOtq0FYCbrROD27dtO4x7Be0AOzVTbx6//lDNbMr Xm+ntauhtcqgJ7J4kCHKOVDb4OMUcMXCttkdxIdqz6sEmpBumDF804JqKPPJJE9v0/AsTovk 2KcauNWHwlsMPbfC+Iy8D0tajXwvh/iM/R/2W40D4Cj8JkHV+B5ioyeD8YYiY+sefwkc/Scm nz5tNtOrh2gsb2OOSNf+CNF5S9+NwyYgNo1X4tVRT2Kkc9fXVpX12IvnCU/eidHhJbbMcNVc +ZGic58xlRd60QzK6yx5GoptFXKaKs4LFwSXl8I6wItovwRtq1sPOmxrez8I2dWP0HXaNc7I Ctk3L1kKnVKg15FIt/lnC11gnR5gO3byLOiP9Dz0XDmSoaBmS/bbC3ddoeGWJjoPfXVbH6qh 1Zo/GaVd8ukfr+whc63isfI6meYodXKtkHv4AvqjY9XtvmQcIeKxYlXa7bHmOGL91RPJZeSt bZTJNZrzbxbOz8cO7rVPzN1JtWDuOdDJifdsMTz2eaaw9Z1qC/L53fMinun9pSvVapPpeuLy 48tZTqmR/+lGAMXP4zRtldfi/lYK+GWjZO/TzUup/L0JVe8TuhPth1BypGa4Fdkl5q9vWHZo Wulz4mjB8e67MfnItI/iReZfgnGIjZ9JrhMi5Gn8qWIV5RhwEvFakKnZoaPyZuniRzmhNGSI 6ADz5YSkNjVqrq5RBO/lAQgoKvz7LVod2JrguTk8ODGo8CF3WZwR5/Jnb8iOxsmcxMeTfT9U dXkiXeuUSOisnyUATWmBaJDs5Cow4liRbKNNVrBhFjIbkvdclzbYECoT5+FG+RWOlnRujx2C dWbyiDcm8VlyPzqq+BN+O5rCjc0wJTUZNQaP7hcVI5x4gb2ir6fLsvw95pFe5oVf7srGBeI4 o3Jsij7p9I/wZ7pEhpr/fSNrVzKim0voRt6i9swYgpsgJQdY01BLJWQocBnhME9++osttqKo caEOXRTOZy4lVHKw1My6nqdmQm8ctmmoj0IU3FTjb5PA0P6SdIa3KcjD3+PNex0CNaekeyrt 5zrgyqMThtEfgpTIN52y+d3GWB115ZLw/kV83Nj9hLk6gIjVFK6kZU15fjgBcWkqokD+BkxA Fb8XqS2mA5rwoXjN/c525TlfpwC0l/ZmxOH583YzIioMzKXCtEqF3sqtDCpIMkjiYTxv1mhS qzMlsJlSCfwKVc1MHBSsO2WYr4F2GI5gtYe7qfbdyW4diTZRULO+ZXf6RLjlYpF3RLXEDdYc FZ3OaDZQynFf13uTqeFuMC6lkgh32phVdul9mUfKy97WGJ8GlJefUucKYZ6g0s9r0raugkDm AonWQK0O95WPCkT6Ir6lwYl/mkpl7MHATr3FlsXm2jB7Owsh/dXFxZbWIXsH9079zfvF1l7M U3+DimId7GjrGkSgM1cWi53/hIWA7cVpYAxHEeaRfDVS2lBFJ6OoBZ/W5FRlc13WxjEczAeM TMKFXnEzy6UA9KMECdo2hTYvNdJ6IofsfQhROACU59p6nGrQSFKjJ7YloHJFbeuV0NrNXHRv jV5KU5J7GbrSWc8b7WU/m8FmNWdl9wxOrQG7e42xQHQ35stCM8Z6wxfm9AH2cOdYC+EfJEvL w3zDznHuXT/IH5ZHxD64JIQJ7zUTVEXhYdlZc/HqUeV5mZn6cLYS0UDpOsN+MPy3MoYVxpW1 n9IfepIxnc/Nzb4WOyFUyTkfSHeQEZZRm5RTm9FJ1sSimfGLcXfFZ96AYkjyvsT3g1s+ioi1 T/PU7whZt0L8jZaNwjjLOFnW4q90NvMaeiapWMwwRNhxjcsqpnHuNFPZEy14KFHPGAZvIVsy d1vZyBf846DPk2y1e6IzLyhZNQypFii1Rdt+5u26ILwMFbEzI1xb7t/cqE/ptrPk0zeV8R9X Z/3v/C8tDzvNkI1lvk/3k33n900spZdfEILcVIt16j4Q4I+Ipq3UlzX4rlJ7u/2ca17JZqHd cffUxvlTCWk5nBfc2Vht73Ups1k4+9CHqSn+U4dnG/2hlYCWXOajIlkiYa+X8L7kJIuLXxIp Kt1wPcOw5X1JEu0lDaeSjVRkKldCjdvTRLmeil8ld3wwDb1UvcI4X2ZyuCgq7STi8UA0m5N1 srS5+jnSdRT1Rg5gpo0yj2iSSW99Y5ymiEsmUpY92i0lEG8Pzk0dfaW++Jq58MlipQ/rFhTd eNjwyXNWX0C+f90gzjmWf7iaDVAmZXip1Nq2JVOjJG/mfImruynedKGqQqe5v21eyLr17tpW uXC9vt6u1HWsrNfydcvpteulv125hf7qQMLRd5O2/aEUznly59YtmEXuW4x7swpxfN1RSH/h TBKGeGYLA2dUXLd9f56n5/nyGjqoZ2uSPw1S+K/Hi01LaOfReqPmNhUp2zPrvXCibPmohEWq z4v5VaATPmiS9mie6ci+bKzl/epTvXpnNLh4EhUbOK5+f8tqekvyFtvZFi0hEu8i4p/mF6/V F3tNZoLq/UrhFIPjRrtzVSC5dccpNonXZonBvcUH68Rc5sXyd8Swob98//FIriXiSveRqffh dyUSuEmwlLNwJrMwkzK9q+HSZfX1VUh8EOAc2KkSauRqu+4bGce5wkho5qfXnWiEIbLQCXPS 0UjSIkuSc0vCTDlIBr+L2PQve/HSn33+j7mKqoqZ6ayPQ3rgaygn5UI/16d+lgV000TJSTOc w8IagS7Jm+h+2qY+UjI25+PvduqSLrqc7gVS/G590lqDMuaDsl2QQAQEof8DUEsDBBQAAgAI AOJ81yjtQ19aZxMAACkWAAARAAAAQmF0dGxlNjQtZmlnMS5naWbt1PcjFADjx/GUiqRUZEQl ss5MxqFhc2birEPC2bN0d0aE46yzOTOr43DJusNZOfPsdeYZyU6RLeP5Pn/H93n99v4DPh9N bQ15oO21i7V0Bxf+KzU19fT09ML//M//P7xH9HQXLly8IPrf+O8mXjKcX7jMwK31Lfd7KAPz RbOub3nkCBY+UJZWRX57NIe0y0xXRUFn3EPVKG7tysLuJI47JZDuRN6eNEk7SpZ2FbYvU/7d +kx3VdHA55eh19zrJHnVcsQjRKwo1biRIsMCUDbI18Go2LTUhUapKR0vf0O+2AdiaWnJv9i7 zg8g4KeJXouUbFdWPCVca3OY1kMst8G7XF4Xkz/8PUkOYXukT5L3+tEhNynSRiJszfVgpF33 1+DSet0Oqqa/f9XtDregtV9AG7gqrEfLzMmyevd4l+pye2Y70kmEP3MtoY5X8Pu8ryKSTJhs 0CZSOyu9kQ+Mm8x2zXsGq1zn+huLdsdGi0pTf9MaA0YmxxhNDQI5An/1/7LMPPi/g9D/u7Oz MffghOQ/O7Et+BDSwew077vAiJz7dF129aEp0xnrQigr2GnBjO6GzALydHJl1o2uQ/Cza4W5 IzWSH93Fa3NvOWU+SrJDyM5K4q3ZYoz8IxQEfVIDn/EIcehajFeTXS2w7ec1+5moqwDnT6Re RtglGYOFZ5Iu6DsvpUI8NsId7FU+CC9jggKdk9LtXeBsqDi2NDPwRKDWo0wRrDkUIzuFW8nx zzvizAmgsn1JNVBndYoL9kldzYuRLRHIOxBbdypMerJehE60sljDZkVdxb0aeTxeiFJe35/y I45xPMgWTp0QjsioF3EtK6cqCOMlFiwWStwpYMirFqzWSrnvVEbBV7C2y6/K8kf+aZW9Gv6A aiAQsFljbOF6r2biQyaWkOMH8MDPRyn8rkuxVrCuXSW4ChPXHzuXkHb/movbblFLJWIO+kl/ miH7pfwt9I6ZnnoX2cu2fBiLfCXN6OjnLdvu6EAy29nHz6leZCZY2TZZ2luJtZ3dzo2ruzo9 4G/nZzBTZaekJ3G7xyovoJKSMwnh6gdWce8MvIRF3I9qr1d/anc+hLzrpt25JDCy1u27O6ps 6r43ZiYtOjX4d+rqeuB9wpQP1f6mZl6XylqW9EAGrpFz2v1fwya6IMWdOOgdbnHQx3aQvd3m A7N6r+s0515rLB1HS512J8dyLqYDz+DzBN7NHwvnw3014zfIgnND83j2+izzR/rSpvEvxI9s cDYEhY1kS9+jgV/u9x+vFKrQNuYzuURq4i/Xl9Wa4avO/Gza//kq/a24Kbox8/IDGtFFNHhA DZMAhf3Zsn0cd/LXHzHAfrggJzJgvKAcx36aGY/k8WtY8/YEeOuExpwZ/IgwOIMcjdS8OF9W 7FsrE2yZv3VuCMImzZkedzaftyM/+XjPX7pUnPyPZyskwShXV3TiDsNzw5BZ2wcrEAf2qtxf L3KS+qgq7SULn7bEJFh1fkhOpOwNxWsw6ppfjySSf++xvG0+yjN18k3epG2hAnl/lGuRlXPg LOIGYXksjU/URYy2Xmn1PvK4AufmOe6LDmKyc4aiZOoRnU/EeXtKrMnqcQnejiZqVtyTF4sG xF6B1i+9vJBYKb4GLIcqN+SHTMk/u+SyHcPFz81bdFud+NTH23sGxP9YuCv36ZB+tJL9jQIf 7Wwlo/DIwh/8pU9ARmCf0HC1+cRDsxf56UPol6CCOqp9/m2oUZJjPqfDtZHurAAjuLVulYNL WJ2m5dmQzYbi0JunezoPL6JlPWeSUlXMn0EqV1OXQwpGt2S+IVlfp1PeY9Bt5iUbxVvCfZA3 D/Mi9fgsdrJZXIqaq80rJb7+SsdGCigddGsj7ld57xc6UqjpMwZBJYmfGcSSlU+FDJvGXscc iArJkDCDUTmeCQj6Ag0eBcMAtHdeY/Uq3R7jYITHe0f601W1pBqjhKjkQvFY3Jas8EhGf/Vn sZq157YlIzlGrACmPWHmOxGJ+Vx7xVp6JUZplFGswh5ON2VI8tWdUYjRXgmsdV351KcTf/a1 9Dp+KiMMV22VKBNpN+aSfoPL6ENFTYlKbClkBcRmzSiOfDxMA0YAAV3V8V+DaWzGV3UmWrn2 v6H0yt6yu5Kvtcp8gy3iNkDdWhTQ42zwbrHj+uu+F0uslaqX1+yUdc5l+zWYbQseu3PuCMiP fpQVweDTHWwVLYtHqYSiZEMXE1eZkcQdbEMsAAFJ/z5P8a1dEBXXTJs2TL4hVb7JiPUwXsbu NzKWp1pOeRqUdo1DR2pVQbwmMKLpoTL7R8IIAAcBkNYvsjdYuWwgWkcn4jfvNkkW2Ijg/YZr 6mKyjFXt/AmKKthXvY2zepYgvT1QAbIY9WeTw7u7R233Y7+atevUCdevefpXr5sOaWn2cWY2 Jx0lcecxM+7Zt6drqmV5xbCF0MY2ix2VOPQB83arH9nWQP1mmwI2Lahah5WNDti1+XdzR2l6 joifSIwAbiWKwayao8Q/+kV3J2VWOnQqiWiS34C+0UQgjc31f7KIVYCWZNFmPr4jyB6dtEj7 yfJuZGq/bmQFeFeXwnGMFrGyBuVejVz5Rp3sBFp3UVE3Y3vUpY/j0ffnckdk13K3OAeZsN55 NCUxD4JGo/2VOBSL2+ybV/LQBHQZg7ZpHRzJRebnzp4wDFzRNH06dlb61FDcapLzICY7U/89 L+91A8ilD82xX2vwt/x+iPr7TlKN34YCme9Y24DHD8kEg+rGzZkPB52t4fu1GadNrNGW0R3P iXvDp9+Dj9nz+1OE9Mbw2h9Gpr32mw4wKbQZWBySJA5GJUvp1tyicMxmdBObVE6rQz7fzaLu pSxTYtWQG4qud5sPx8ae/FaF2ezwUsPdsXf6Pe2Q01VIa1i3M35bcuCekyC7SCdvh7sgNUCQ txNfHlH1N9XOaxnTmz1QgWJ1fOG/Sq+0/RF3mphFzGioZYq1uHJjbyXWr2U6pUo3q/9Hwo5S QpusHHrUbcsszbJBbTabTjvQUw+BjpTSVCgKFj/gOYC0136KZOQpLhF+7bfifWm/p7N61sgd venmaUOJC4S1hjpsf/riT2MSQAD9Ggp51A/Hr744Ips07TzyUFrt2T96NjeTVHTgsO5d6Uf1 v5dQYIr4xvvgH/P2QNM+BhD4WSIO1nfVela+vXFFXSKgYmpgVVPio2fc3FQhphc6IMiw+0Xi dPXmzyMqO8N++edAOt3z47Gi54d1Eh83I4JOlgWb90nnp7vlzSezL5r/LZafHXmen64ePP+3 ZBD070/z2Sl78IFj0Ennx/OIIHqG4CsMQZeEgi93BV8tDrqOCbDGBvzDKpcLfLirpdhG/HQ0 9mmO7F9yCZ6w41e1+One1RChYsl6YkjvcEgj1Kh3z7UJxim5GkLoRMgL2YrUhubB/KVX7R+t KlhHcMqthr4bD9USsgfVhmlTw26N+sl+94UIIGVskaZOIZSlMKVphjCIE8z6EJkMc4wxCYfC w50w4S614Y94wz1Q8uAOxfF30GpTsfddJsapEb7FWt6rsNvUCH8t+WCnMNiE4PdFL9BrlGct KmYChS62FMoHQvl1hGWVnPc0dQ9QsCf6WfIOFimQMbYop3Do5SLfDCGTj4UaSV0awzUmcCkw nB7sdRtWZBZNMON3w0TX10Y3TEQ3mRkrwKOHfcIISKS0MhIBjbE0DZNlQLZOKPYfxozcDh+G i7kRkGNOsTJU8302FE9hjMUV9JgAWq8zxpwtZlJL/CbVTjcVPXV+6NDVaa2MQuyYhfDD0XLQ F9Wr6EuJ92xXfE44xMZr5ehwThtmb2km8RK16GW1+DNwHJ9ZaBIfXOOqwgVcPPDw/QU5Rw5n n12HBPaj+FOBsNvaYayMIr9NFHgYOWSpiUeol/JUYJGR/lIb+sUXw1mO+Nw791+HvJ3wdXhR lyCHk3soHAdgjPhD1pQx961QUxFmfMQMs+WtE6PvsNHs1v6Khbf+SETAPwD4VVZkUioX4/kn 7Xc5PE0SwKBJEK44tecnuO4d2KfLaHMpghGR8s7p/mECxD4yLVYl5iOCl9wey50e4kV81sNv /ZsVnC7v0aKKgQETHTm9HIpStH18/Uz5pSKLlNRRbrlqPIAxjHRlUr3UI6i6NwboSj6Mc5fC qOBg/7r4I9hl4O0uSKeotdaMz8DUd9ppLEDz8/bU88KoB61RGI5MEWX0khYfEJj8dxjaxYkZ OF/IaDwS7RPO9tO2KU8HDEVmm1YKDSKyaUZwZUKaSuRbViclVXk2ztrbXUJOy10m9cYJtEnh TZzdWVfKJod7fqT3NDxnF+h7ExO0KRh8yyz3Eir3an3uneJgltVclvUg5qjgGxx5V1zyGBRy b4NyuSzyWOuDuaPyeKaCH2YEPzjO5fXLpz8OOmJMBxMxs5xC1MRXUn5CuztvQ3+AZUT0ZMIz 3wANZGXcqUDOflVNzy9g17uCQdjExEl/aBKH0ZU41iJUk1HGNiZrOxI8avaaRAcNUI965Win XOd1nTHyybgMzB66rp755Uq4ATvoNJLlD471nV/IdaTdaxmD6veF119rCFG6bwdFqaLC42eE cxSv8QQjiq8M5z9fz4ziem8EyvmH8wjjMr+J/ZQgnJhhkWoLTUKkfnkQgfYlFPKxxXaol2g7 lqBZiyU7SnymVFNARbkuqJ+Wx8XbX0oIIia1GaUnlaUN1wBNoHcbOKWvfiztLmUWE2nNFo8j j8O26ETxauCBqeQu/qzPy1F7CNHv9S87LVh8r6Wiik1jvFWAoGQs8A30wx3aOr6by5ad9U1x Iga1nKiVkcxJyNY1K9UmuphSy2+Nm94iquGefBGtxXuo2Tvb47XIOh3vi8o58IFPo8MpZVdI ZfpGFamCoXoKCY9xX/JdKhaQFRJLOPPRsm75Ml6nbH5/r/QiowdM5sUZbsd+Jd5Too+YKk/h VfLRQm/Yc6Frhc2MigdCn59FYyfrq6qPK7Xu8Z38FMA6KecLueTfxuS/BtQIFeTesai5X1Lz uL7GdLrmzb0a655cEQsCO6iGUyQfkFHj7EowJBGcdAhgANFuOlcvE6pJqrb5Uu3HVKZuqSI5 ReS1rNZXrAiJjnvpUGta+/VCbYXAZEUeV0CEDr+AYl3Lq7r3lFrW9VoVpjptQF1qKV76Xn0I rqowuhjrXz+UUD8eXpkoW529UZlbWt+oUH+ELPc78DKD6q9ZeJfpWH7VeZavIcqok1QI5DEW dG3sqbz1mBRpaZE2CTBNSaz3xxMjSYf7pKi7jYaCUX0H5fOgb3kOpGpX/inLpk1KYaZCelZU ah/JfMX/U1TPp/OfPQZSAMi2JbJBrvnJJMuci3OVBXiPydFmIf1JWrMspflQsUWpJB4T3ZQp R9oEfJ4tqbPYaOLQ9bneAL1/2KLvk3zfzfnuSTNJtpWuQf1emeA1UQ/eEzHAr9diMVF1f5FS 178nMMnCUoh4roa6K6QsRGKyOVTBjfwrsmVoO6UZqTIwybFqnnV63Prn+MkqDuRJynvXQ/CJ rvGObl9alxw44PXf/XjRgltU5NPrIsVb0k9NAggQxXyPMoIHgGDLRDRtaP8A6YRDiDBInkdE gMx0xtjo0ySnxgZza6PJ4iXnNotFLkIV6XKHVc2iW2yAR+CMCAbUdtGoG3ytEBNQwSg848FF atpfrau82EvMzsr+HBMt3XuvfxIhIyqdcze6EOrCzBjdYJm9u0+ZkjJp+5FSUJwMty+vKOqR d0R+2HvqfKvDhZhyJxXbvkruvdSmv90pK6Raq9n7DaLaHtFX0klmpu9bTGp6i6BEl3T9PKkb 8O9fzqSsK2Uvn8DylL57vmv1B3zf7K3CBgwU9/SXrve9Yuhf4uvbudx+rDR4BBm8vtPP0Ji5 3zC49L2vTK71NvPgGV8/eG3wiG6Io4c2eHm36tbaUNx05VbPwL3NBnnz4Z28ISH3Qe7G4VKd YaWfA7miw5zc39d+DT/ha+/S6JN/hiubCVB1K7vDM9CsOcIVoyXbNvLMCsOZPKrcOPqch3N7 NcCTu9NrpuN9WSdCqRNcNmbdN+Z2MuajRDVnprq6UU1ix6xiqaY0ggsP1W3zg+LpqGHfqCBP dZvIiKHagH5BXBlu1JdG4eGZkAgcNHw6+pCH9KfUOVxv4v70MNp9eER3POFZYbzVpGbgpHDm BEKPQsccIBc7ib7rnpwvNsiuPvg7cgLO05djNZBnNZXYN/yNeQr2bLoicIqgN50UO9WNm8r6 R8bTxiWzpy+XDbYx+2ec1qsxV8tYjfLRJjpP4R08NIrCxCgthhxIcwbSppen83srNNxHavC0 uNOpn1aUbvwLPzF1VuaXWHfaSmz/Is+c0HXarlXbZOAcyX1OqnHmQePE01b49BZ+jr6VRi8+ wVY7RembLOOZ1XCav+oxGfkvmtV64e7HBQ7r8FtNC9yzC9+AqGnWJlRZ3yN0Y7veF3oVLwHx tw9nBYV+/5Bo0tuK6rGU6gE0eYnlwKRyUK7XFv3M0oVnFxtTFoXPFvnO4Irii2aOaVo5P++f /TS8v2T0fMlYXK/GzUqVLMKMENCxjpLTn/cU7tUh6FxI9UVYpEjfwJqcydxi8sIBGzosNcd1 Ft98XXq5Vj4lIzpM6n328afr/bagph7GZJ7VMOtVMXaWC4r/AVBLAQIUABQAAgAIAM2d1yjF hYQcJTgAAACtAAALAAAAAAAAAAEAIAC2gQAAAABSSVNDNjQuaHRtbFBLAQIUABQAAgAIAGB9 1ygzARriph8AAGAiAAARAAAAAAAAAAAAIAC2gU44AABCYXR0bGU2NC1maWcyLmdpZlBLAQIU ABQAAgAIAOJ81yjtQ19aZxMAACkWAAARAAAAAAAAAAAAIAC2gSNYAABCYXR0bGU2NC1maWcx LmdpZlBLBQYAAAAAAwADALcAAAC5awAAAAA= --------------F6029D522968D373ACD40B56-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00527 for ; Sun, 25 Jun 2000 14:30:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 14:30:22 +0200 (MEST) Received: (qmail 12042 invoked by uid 0); 24 Jun 2000 14:40:50 -0000 Received: from hj.egroups.com (208.50.144.90) by mx02.gmx.net with SMTP; 24 Jun 2000 14:40:50 -0000 X-eGroups-Return: sentto-1101623-340-961857543-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 24 Jun 2000 14:40:44 -0000 Received: (qmail 29644 invoked from network); 24 Jun 2000 14:39:03 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 Jun 2000 14:39:03 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 24 Jun 2000 14:39:03 -0000 Received: from welfen-netz.com [213.6.82.82] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Sat, 24 Jun 2000 16:38:55 +0200 Sender: kai@pop.gmx.net Message-ID: <39553D57.3D7C857B@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Jun 2000 00:59:35 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bf39b557e61152cc941d733e073eadbf Status: R X-Status: N Hi,

after reading some mails in the mailing list archives I just
re-joined the list, so I'm not well-informed about what has
been going on here.

- I've read about "xRISC" in a mail.  Is there a description or
  web page for it somewhere or a specific mail where it was explained ?

- Could someone pass me the e-mail address of Albert Abramson (or similar),
  who took part in the discussion a few weeks ago ?

- Where can I download the latest description of the fcpu F1 ISA, the
  general state of the project, what tools have been decided on, etc ?

- Has an integer adder been designed yet and can a description and/or
  it's logic be downloaded ?

- Is the F1 going to be a (full- or semi-) custom ASIC and has the
  target size (or number of transistors) been decided on ?

The RISC-article is quite interesting, btw.

Best regards,
kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00530 for ; Sun, 25 Jun 2000 14:30:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 14:30:22 +0200 (MEST) Received: (qmail 10542 invoked by uid 0); 24 Jun 2000 15:58:16 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 24 Jun 2000 15:58:16 -0000 X-eGroups-Return: sentto-1101623-341-961862285-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 24 Jun 2000 16:58:09 -0000 Received: (qmail 22678 invoked from network); 24 Jun 2000 15:58:04 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 24 Jun 2000 15:58:04 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 24 Jun 2000 15:58:04 -0000 Received: from f-cpu.org (Aubervilliers-2-214.club-internet.fr [195.36.150.214]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA28586 for ; Sat, 24 Jun 2000 17:58:01 +0200 (MET DST) Message-ID: <3954DA56.E184D2D@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Jun 2000 17:57:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 33f1b2f689d05c56b38d7fd92e761984 Status: R X-Status: N hi !

Kai Wetzel wrote:
> Hi,
>
> after reading some mails in the mailing list archives I just
> re-joined the list, so I'm not well-informed about what has
> been going on here.

welcome back :-)

> - I've read about "xRISC" in a mail.  Is there a description or
>   web page for it somewhere or a specific mail where it was explained ?
i don't think so. maybe there is, but no URL was published IMHO.

> - Could someone pass me the e-mail address of Albert Abramson (or similar),
>   who took part in the discussion a few weeks ago ?
Albert Abramson : maxx@nventure.com

> - Where can I download the latest description of the fcpu F1 ISA, the
>   general state of the project, what tools have been decided on, etc ?
no tool has been "decided" : "freedom" means that you can use any tool
you wish to use, as long as the files are in a publicly known format
(no proprietary format).

> - Has an integer adder been designed yet and can a description and/or
>   it's logic be downloaded ?
not yet. i've come up to a certain organisation but nothing's sure yet.
it's a 2-stage pipeline PG adder, one stage is 8*8bit adder/subber,
the second stage performs the SIMD packing/carry propagation between bytes.
i've made a C code for it (it's surely on the mail archive).
it's pretty ugly and a drawing would be better.

> - Is the F1 going to be a (full- or semi-) custom ASIC and has the
>   target size (or number of transistors) been decided on ?
i personnally target <1M transistors for the first protos.
the goal is to test some design choices, the performance is not the main
goal. testability, debugging and ease of use/fabbing are very important.

my plan :
- during this summer i'll work on the organisation of the project with the
mailing lists and the sites, i'll try to update the manual and prepare the
school year
- starting in spetember i'll probably study microelectronics in Jussieu.
with some luck i'll probably study the f-cpu architecture and fabbing during
this year so i may come up with a proto before the next summer.
this way, i won't sacrifice my studentship for the project, and the group will
benefit from it :-) i hope other microelectronics students do the same sooner
or later...

> The RISC-article is quite interesting, btw.
? which one ? :-)

> Best regards,
i hope you'll stay subscribed longer ;-) things are going to heat soon !
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01352 for ; Sun, 25 Jun 2000 18:39:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Jun 2000 18:39:52 +0200 (MEST) Received: (qmail 19868 invoked by uid 0); 25 Jun 2000 12:45:15 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 25 Jun 2000 12:45:15 -0000 X-eGroups-Return: sentto-1101623-342-961937107-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 25 Jun 2000 12:45:13 -0000 Received: (qmail 23256 invoked from network); 25 Jun 2000 12:45:05 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 25 Jun 2000 12:45:05 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta3 with SMTP; 25 Jun 2000 12:45:05 -0000 Received: from welfen-netz.com [213.6.78.120] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Sun, 25 Jun 2000 14:44:33 +0200 Sender: kai@pop.gmx.net Message-ID: <39567439.AD5BFF30@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Jun 2000 23:06:01 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 577b2cbd2f2ee41496ddc2d618e758b7 Status: R X-Status: N Yann Guidon wrote:
[...]
> > - Where can I download the latest description of the fcpu F1 ISA,= the
> >   general state of the project, what tools have been de= cided on, etc ?
> no tool has been "decided" : "freedom" means that = you can use any tool
> you wish to use, as long as the files are in a publicly known format > (no proprietary format).

Ok, but isn't there something to suggest ?  I personally havn't found = a tool
which supports graphical layout as well as gate-level simulation mixable with larger-scale simulation, and physical simulation might be handy, too := =B0)
If someone has a good suggestion ...

[...]
> > - Is the F1 going to be a (full- or semi-) custom ASIC and has th= e
> >   target size (or number of transistors) been decided o= n ?
> i personnally target <1M transistors for the first protos.
> the goal is to test some design choices, the performance is not the ma= in
> goal. testability, debugging and ease of use/fabbing are very importan= t.

With 1M maybe scaling the 64bit layout down to 32bit just before
production could be useful as it'll leave us some space for a cache.

> my plan :
> - during this summer i'll work on the organisation of the project with= the
> mailing lists and the sites, i'll try to update the manual and prepare= the
> school year
> - starting in spetember i'll probably study microelectronics in Jussie= u.
> with some luck i'll probably study the f-cpu architecture and fabbing = during
> this year so i may come up with a proto before the next summer.
> this way, i won't sacrifice my studentship for the project, and the gr= oup will
> benefit from it :-) i hope other microelectronics students do the same= sooner
> or later...

Do you plan a meeting in Europe for the summer ?

> > The RISC-article is quite interesting, btw.
> ? which one ? :-)

the RISC64.zip one.

kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00361 for ; Mon, 26 Jun 2000 19:39:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Jun 2000 19:39:42 +0200 (MEST) Received: (qmail 21482 invoked by uid 0); 26 Jun 2000 01:37:01 -0000 Received: from f19.egroups.com (207.138.41.182) by mx02.gmx.net with SMTP; 26 Jun 2000 01:37:01 -0000 X-eGroups-Return: sentto-1101623-343-961983414-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 26 Jun 2000 01:36:56 -0000 Received: (qmail 11757 invoked from network); 26 Jun 2000 01:36:53 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 26 Jun 2000 01:36:53 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 26 Jun 2000 01:36:53 -0000 Received: from f-cpu.org (Paris-Raspail-1-171.club-internet.fr [195.36.192.171]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA05020 for ; Mon, 26 Jun 2000 03:36:50 +0200 (MET DST) Message-ID: <3956B37C.4F914705@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Jun 2000 03:35:56 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: bbf5d776bf89208a1e6f828fffc7cdad Status: R X-Status: N hi !

Kai Wetzel wrote:
> Yann Guidon wrote:
> [...]
> > > - Where can I download the latest description of the fcpu F1= ISA, the
> > >   general state of the project, what tools have be= en decided on, etc ?
> > no tool has been "decided" : "freedom" means = that you can use any tool
> > you wish to use, as long as the files are in a publicly known for= mat
> > (no proprietary format).
> Ok, but isn't there something to suggest ?  I personally havn't f= ound a tool
> which supports graphical layout as well as gate-level simulation mixab= le
> with larger-scale simulation, and physical simulation might be handy, = too :=B0)
> If someone has a good suggestion ...
nothing's perfect yet in the GNU world.
I think that i'll use Alliance because i'll maybe study where
they make it, so i'll be both at the place where the silicon
and the software are made. VHDL will certainly be used.

but today you can't have everything, you can't do the noise extraction
>from the schematic input interface, with the current technologies.
things are getting worse and worse, i don't think that this trend will ever= end.

> [...]
> > > - Is the F1 going to be a (full- or semi-) custom ASIC and h= as the
> > >   target size (or number of transistors) been deci= ded on ?
> > i personnally target <1M transistors for the first protos.
> > the goal is to test some design choices, the performance is not t= he main
> > goal. testability, debugging and ease of use/fabbing are very imp= ortant.
> With 1M maybe scaling the 64bit layout down to 32bit just before
> production could be useful as it'll leave us some space for a cache. oh, no need to downscale. 2 or 4MT are realistic for mid-volume.
cache is not very important if you can enhance two things : the memory band= width
and the software's quality. this helps anyway, but that's not a problem
that we have to solve.

> Do you plan a meeting in Europe for the summer ?
i didn't but this would be a cool idea :-)
probably something in Paris then somewhere in germany ?
if people feel concerned, we'll have to organize it quickly.

> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00364 for ; Mon, 26 Jun 2000 19:39:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Jun 2000 19:39:43 +0200 (MEST) Received: (qmail 18053 invoked by uid 0); 26 Jun 2000 02:00:48 -0000 Received: from hp.egroups.com (208.50.144.93) by mx02.gmx.net with SMTP; 26 Jun 2000 02:00:48 -0000 X-eGroups-Return: sentto-1101623-344-961984842-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 26 Jun 2000 02:00:44 -0000 Received: (qmail 8566 invoked from network); 26 Jun 2000 02:00:42 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 26 Jun 2000 02:00:42 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta1 with SMTP; 26 Jun 2000 02:00:42 -0000 Received: from [192.168.1.40] (ip30-htc1.busprod.com [207.150.74.30]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e5Q1xbl25815 for ; Sun, 25 Jun 2000 20:59:37 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <000801bfcf0b$9fabf5a0$b10bd7d1@0018728164> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Jun 2000 20:25:27 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN64 PROCESSOR Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b449b2721b7800fe10eaf5f101cf7036 Status: R X-Status: N
Dear Richard E.Hartney,

I have enjoyed reading your posts. I think it is great that we are talking
about 2 different processors (ERIN and F-CPU-0), targeted to 2 completely
different applications.

I'm glad your processor is so very, very different from the processors I am
most familiar with. There's no way the f-cpu will be far superior to other
processors if we just do everything the same way "everyone else" does it.
You remind us that there are alternatives.

I hope that we will be able to share the work -- there is bound to be some
common design details already worked out for one processor that can be
re-used for the other.

Will the box that will contain your ERIN processor have more than 128
sockets on the back ? one for each terminal it will plug into ? Or are you
doing something a little more clever ?

I agree that when communicating reasonable data rates over long (meters)
distances, the price/performance of serial data streams always wins out
over parallel. I've seem several low-cost converter boxes that are designed
for
computer-(RS-232)-converter_box=====(fiber)
on one end of a long fiber pair (one transmit fiber and one recieve fiber), and
  (fiber)=====converter_box-(RS-232)-terminal.
on the other end.

I agree that for business applications, it is not necessary to allow
application downloads. Is it really possible to rule them out at the
hardware level ?

I assume you are going to use commodity off-the-shelf (COTS) text terminals
and PC terminal emulators and hard drives. Have you looked at good
explainations of the "redundant array of inexpensive disks" (RAID) concept ?

>From: "Richard E.Hartney" <rhartny@bellsouth.net>
>Date: Mon, 5 Jun 2000 00:50:27 -0500
>Subject: [f-cpu] My Response to Mr. David Cary
...
>        I believe I have stated before -  My System Architecture totally
>negates any requirement for using NETWORKING HARDWARE/SOFTWARE  that is on
>the market today.  I can very nicely service more than 128  Terminals
>without NOVEL or other similar devices.  The maximum number  will be
>determined by the performance of my DDP-516 Emulation - the ERIN64 or
>ERIN32 which is used as a Language Processor and a companion Peripheral
>Processor.  The process is inherant in the Software I intend to  capture -
>Hard Disk Management.  The number of Hard Drives is totally  dependent on
>the System Application.
...
>Sincerely, Richard E. Hartney Research Director Erin Greene &  Associates

>To: <f-cpu@egroups.com>
>Organization: Erin Greene & Associates
>From: "Richard E.Hartney" <rhartny@bellsouth.net>
>Date: Mon, 5 Jun 2000 11:32:19 -0500
>Subject: [f-cpu] More Stuff
...
>    I forgot to say ---- Data to the remote Terminals  is also
>accomplished with a controlled SERIAL stream with Sync, Clock & Data  via
>Fiber Channels.
> Sincerely Richard E. Hartney

>To: <f-cpu@egroups.com>
>From: "Richard E.Hartney" <rhartny@bellsouth.net>
>Date: Mon, 5 Jun 2000 06:16:24 -0500
...
>Inputs to the CPU are serial,  just as they are on your and my PC.  In my
>case, I use Fibre channels - mainly to remotely locate  the Terminal as
>far as possible. The only place I use RS232 is for Modem connections  -
>just as they are in the PC I am working with.  I do not accomodate
>down-loading Software to execute because it is, and always will be prone
>to  Virsus problems.       A plus side to my approach - 128  PC's used for
>a business application.  There are 128 CPU chips.  I use  two CPU chips -
>no matter the size of the total system. There are also 128 Hard Drives -
>generally packed  with crap that is seldom - if ever used.  My approach
>here is to use one(1)  possibly two for File maintenance and additional
>drives for DATA archive.  The  number is dependent on the size of the
>application.
...
>Sincerely Richard E. Hartney Research Director

--
David Cary "mailto:d.cary@ieee.org" "icbmto:N36 08.830' W97 03.443'"
  http://www.rdrop.com/~cary/
Future Tech, Unknowns, machine vision ><> <*> O-
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00367 for ; Mon, 26 Jun 2000 19:39:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Jun 2000 19:39:45 +0200 (MEST) Received: (qmail 12948 invoked by uid 0); 26 Jun 2000 02:04:44 -0000 Received: from mo.egroups.com (207.138.41.166) by mx02.gmx.net with SMTP; 26 Jun 2000 02:04:44 -0000 X-eGroups-Return: sentto-1101623-345-961984850-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 26 Jun 2000 02:04:44 -0000 Received: (qmail 26979 invoked from network); 26 Jun 2000 02:00:50 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 26 Jun 2000 02:00:50 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta1 with SMTP; 26 Jun 2000 02:00:49 -0000 Received: from [192.168.1.40] (ip30-htc1.busprod.com [207.150.74.30]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e5Q1xel26088 for ; Sun, 25 Jun 2000 20:59:44 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <3945A2BA.482AC982@f-cpu.org> References: <20000611113044.26204.qmail@web1103.mail.yahoo.com> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Jun 2000 20:57:44 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f99dbc49926e7454d36d9dd3488d729 Status: R X-Status: N
Dear Yann Guidon and other f-cpu designers,

Thanks for sharing your thoughts on a f-cpu license. You have lots of good
stuff in there... but does it have to be so looooong ? I hate to force
hundreds of people all over the planet to carefully read pages and pages of
legal jargon.

Allow me to try to trim it up -- deleting a bunch of good and even
essential stuff in the process. Then you can try to put all the crucial
stuff back in. Or (preferable in my opinion) you could accept my challenge
to make it even shorter.

Perhaps it would be A Good Thing to have our license *be* just "patch" to
the GPL -- have our license be just a few paragraphs long, and then say
something like "everything else is covered by the LGPL where it does not
conflict with the above paragraphs, see COPYING.LIB". (As opposed to having
a document slightly longer than the GPL, with lots of duplicated text).

Is this really legal, to copy someone else's legal document ? Aren't
documents written by lawers covered by copyright just as much as documents
written by anyone else ?

    F-CPU licence rev. 0.02 // not a legal document (yet)
    ----
    (add your name + revision date at the bottom of the list)
    2000-06-10: YG: original text rev. 0.01
    2000-06-24: DAV: made random changes rev. 0.02
    (indicate where and what you have modified)

    Prologue :
    ----

    Licences are usually intended to restrict the rights of the end user.
  | This F-CPU license is intended to guarantee your freedom to
  + build hardware, make changes to it, and share it with others.

[Should we try to make this license apply *only* to f-cpu and its
descendents, or should we make it general-purpose and encourage any chip
designer who wants to use it to copy it verbatim ?]
  + This license agreement applies to any intellectual property (IP)
  + (including EDA, CPU
  | architecture, IP blocks, instruction sets, software development
  | kits...)
  + which has been tagged with a notice saying it may be distributed
  + under the terms of this license.

    Terms and conditions for copying, distribution, and modification.
    ----

  + A "implementation" is a material product derived
  + from the IP, for example a chip.

  | "Intellectual Property" (IP) covers all the information
    necessary to reproduce an implementation,
  + in the preferred form for making modifications to it.
[perhaps use the Patent Office terminology here, "... to one skilled in the
art ..." ... how does that go again ?]

  + For example,
  | text descriptions,
  | pictures,
  | schematics,
  | source codes in various langages (VHDL, Verilog, RTL, scripts),
  | mask files (like GDSII),
  | fuse maps for programmable logic devices,
  | manuals, drawings, all the data that describe the CPU, its structure,
  | its behaviour,
  | its interactions with other components,
  | manufacturing parameters critical to the chip's function,
  + and test vectors and validation suites
  + may all be needed to reproduce and modify an implementation.


    Rights and duties :
    -------------------
[
YG states:
>The reason for this break from the GPL principle is simple : the F-CPU
>is not the property of an individual or a company, but belongs to
>everybody.

DAV:
I don't understand. In what sense does GPL'ed software *not* belong to
everybody ?
]

  | A internet address (URI) must be written on each
    implementation of the F-CPU IP.

  | All the information necessary to reproduce a functionally-identical
  + implementation must be stored at that URI.
    This ensures that you can easily use
    any F-CPU version or variation, simply looking at the chip's package.

    For example, this is a recommended format :

    * on the chip :

    Zoobidah 2025-51 125089
    see http://www.zoobidah.com/125089/
  -
[DAV: Few chips have copyright strings on them now; is this something we
want to force people to add ? I think just the URI is adequate.]

    * on the web :

    http://www.zoobidah.com
     |-- index.html indicates where the design files are located in the site.
     |-- /125085
     |-- /125086  \
     |-- /125087   different implementation versions
     |-- /125088  /
     |-- /125089
     |   |-- index.html
     |   |-- README.TXT
     |   |-- /manuals           \
     |   |-- /datasheets         for every design and version
     |   |-- /sdk               /
     |   |-- /errata (nobody's perfect !)
     |   |-- /sources
     |  ...
    ...

    If the Zoobidah corp. copied and implemented a design of the Artchoon corp.
    without modifying it, the index.html at http://www.zoobidah.com/125089/
    must specify it and point to the original location of the files. Zoobidah
    may mirror the files as well (just in case Artchoon corp. went out of
    business without warning).
[change "may" to "must" ?]

    If there was not enough surface on the package,
[YN suggested:
>the hardcopy manual
>provided with the chip as well as

Huh ? I've never seen a manual come with a chip. I've seen "Data Manual"s
that describe hundreds of different chips ... but generally one buys that
first, then selects a chip out of it.
]
    the website
    must ensure that one can find the location of the design files
    easily in the server, for example with a general index directly
    reachable from the main page of the site. All the files used to fabricate
    the chip MUST be available directly through a simple URL.

  -
    A direct URL on the chip indirectly helps you evaluate
  | a certain chip and the new or old hardware of which it is a piece.
  -
    It is not
    considered a "fair sale" to sell something without letting the user
    know what's inside it.
  -

[YG wrote:
    <li>
    All software created for simulating, developing and managing
    the F-CPU IP must be distributed under the terms of the GPL in order
    to promote and keep the openness and freedom of the project.

    Existing software that are not distributed under the terms of the GPL
    can be ported to a F-CPU platform if these applications are not
    platform-specific. For example, it is possible to port Mozilla
    (distributed under the terms of the MPL), LaTeX (under LPPL) or
    Apache to the F-CPU.

    It is not possible to port non-GPL software
    that interact directly with the machine : device drivers, OS kernels,
    compilers, debuggers or cpu simulators/emulators. This measure is necessary
    to keep the platform "free" from industrial pressure, arbitrary biases or
    the damages of the discontinuing of a product line. It also ensures that
    the new software matches the specific characteristics of the new hardware
    with less performance lag
    (thanks to rewriting rather than recompiling only).

DAV:
The previous 3 paragraphs looks far too restrictive. For example, say
someone ports Wine to the f-cpu. Am I not legally allowed to use any of the
many shareware programs that run on top of Wine ?
On the other hand, I love the crazy optimism it conveys.
]

    <li>
    All documentation written about the F-CPU and the associated software
    must be distributed under the terms of the GFDL (GNU Free Documentation
    Licence).

    <li>
    The use and distribution of the F-CPU IP is allowed under the sole
    condition that you agree to and respect this F-CPU license.
    You do not have to register yourself in a database, you do not need
    any authorization of any kind and you can do whatever you want with the
    F-CPU IP, except : changing the copyright notices, altering this licence
    or use it against its spirit.

    Unlike some "Open" standards and initiatives, you do not need to fill in
    a form, pay a fee or a licence to use the F-CPU IP.
    In return, you may not restrict direct access to the IP that you have
    modified, even for the sake of collecting statistics or polling (or, in
    general, collecting individual/personal data or going through advertising
    pages).


It is important that the F-CPU licence not become incompatible with the
GPL, even though some details differ.
see
  http://www.gnu.org/philosophy/license-list.html
  http://www.opencores.org/OIPC/

--
David Cary "mailto:d.cary@ieee.org" "icbmto:N36 08.830' W97 03.443'"
  http://www.rdrop.com/~cary/
Future Tech, Unknowns, machine vision ><> <*> O-
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00391 for ; Mon, 26 Jun 2000 19:39:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Jun 2000 19:39:52 +0200 (MEST) Received: (qmail 5318 invoked by uid 0); 26 Jun 2000 08:02:24 -0000 Received: from hk.egroups.com (208.50.144.91) by mx02.gmx.net with SMTP; 26 Jun 2000 08:02:24 -0000 X-eGroups-Return: sentto-1101623-346-962006536-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 26 Jun 2000 08:02:19 -0000 Received: (qmail 16680 invoked from network); 26 Jun 2000 08:02:15 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 26 Jun 2000 08:02:15 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta3 with SMTP; 26 Jun 2000 08:02:15 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5Q82DR17784 for ; Mon, 26 Jun 2000 10:02:13 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5Q82Cg27268 for ; Mon, 26 Jun 2000 10:02:12 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id KAA00416 for ; Mon, 26 Jun 2000 10:02:12 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id KAA03767 for ; Mon, 26 Jun 2000 10:00:44 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <39570E02.6C8A7E0C@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Jun 2000 10:02:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a684d6fba9ff942cdd93a581ede1da43 Status: R X-Status: N > > - Where can I download the latest description of the fcpu F1 ISA,
the
> >   general state of the project, what tools have been decided on, etc ?
> no tool has been "decided" : "freedom" means that you can use any tool
> you wish to use, as long as the files are in a publicly known format
> (no proprietary format).
>

In infineon, they use VHDL to made the rtl simulation but the gate level
simulation is made in Verilog (a program translate the VHDL in Verilog).
If you mixes a lot of different description (schematics,...), the
problem are to simulate all the description together, and it could be
very tricky !

It's possible to begin to code some operation units, but first of all
the C (or C++) model must be written before. It's the proof of concept.
The simulator must be enought flexible to evoluate but very quick too,
to simulate some behavior (like running some code made by the port of
gcc).

I know a speak more than i work but the time...
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01975 for ; Tue, 27 Jun 2000 00:19:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Jun 2000 00:19:44 +0200 (MEST) Received: (qmail 24226 invoked by uid 0); 26 Jun 2000 19:07:26 -0000 Received: from fh.egroups.com (208.50.144.71) by mx11.rz2.gmx.net with SMTP; 26 Jun 2000 19:07:26 -0000 X-eGroups-Return: sentto-1101623-348-962046428-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 26 Jun 2000 19:07:08 -0000 Received: (qmail 29473 invoked from network); 26 Jun 2000 19:07:07 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 26 Jun 2000 19:07:07 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta2 with SMTP; 26 Jun 2000 19:07:07 -0000 Received: from welfen-netz.com [193.194.149.172] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Mon, 26 Jun 2000 21:05:32 +0200 Sender: kai@pop.gmx.net Message-ID: <39580678.56911666@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 03:42:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0576a2dca7aec6b1ecdd08426507d4d8 Status: R X-Status: N Yann Guidon wrote:

[...]
> nothing's perfect yet in the GNU world.
> I think that i'll use Alliance because i'll maybe study where
> they make it, so i'll be both at the place where the silicon
> and the software are made. VHDL will certainly be used.

How much is a copy of Alliance ?
What's your opinion on "Electric" (just downloaded it, not
yet compiled) ?

[...]
> > Do you plan a meeting in Europe for the summer ?
> i didn't but this would be a cool idea :-)
> probably something in Paris then somewhere in germany ?

I think Paris would be nice.

[...]
kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01978 for ; Tue, 27 Jun 2000 00:19:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Jun 2000 00:19:45 +0200 (MEST) Received: (qmail 5330 invoked by uid 0); 26 Jun 2000 19:08:15 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 26 Jun 2000 19:08:15 -0000 X-eGroups-Return: sentto-1101623-347-962046428-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 26 Jun 2000 19:07:20 -0000 Received: (qmail 29475 invoked from network); 26 Jun 2000 19:07:07 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 26 Jun 2000 19:07:07 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 26 Jun 2000 19:07:07 -0000 Received: from welfen-netz.com [193.194.149.172] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Mon, 26 Jun 2000 21:05:34 +0200 Sender: kai@pop.gmx.net Message-ID: <39580806.3A09D8ED@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 03:48:54 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Gate depth of FUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ffcef4985b38d7a70f380927d1559e96 Status: R X-Status: N Hi,

do you have estimates on gate depth (t) for the various FUs used
in the FCPU arch. ?  I'd find this info very useful to test
dependency checking in software.

E.g. I could guess 20-25 gates for a simple 64bit unsigned int
two-input SIMD adder, but I don't know how much to add for overflow,
subtraction, signed, three-input, etc., let alone multiplier, sqrt,
or even floating point instructions.  Any figures out there ?

kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01981 for ; Tue, 27 Jun 2000 00:19:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Jun 2000 00:19:46 +0200 (MEST) Received: (qmail 12986 invoked by uid 0); 26 Jun 2000 21:15:13 -0000 Received: from hh.egroups.com (208.50.144.88) by mx02.gmx.net with SMTP; 26 Jun 2000 21:15:13 -0000 X-eGroups-Return: sentto-1101623-349-962054088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 26 Jun 2000 21:15:11 -0000 Received: (qmail 442 invoked from network); 26 Jun 2000 21:14:46 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 26 Jun 2000 21:14:46 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 26 Jun 2000 21:14:46 -0000 Received: from f-cpu.org (Paris-Raspail-1-178.club-internet.fr [195.36.192.178]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA03489 for ; Mon, 26 Jun 2000 23:14:41 +0200 (MET DST) Message-ID: <3957C791.E4CFD152@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39570E02.6C8A7E0C@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Jun 2000 23:13:53 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6f30075fe3f9cb4c1ecd12b076f519cb Status: R X-Status: N hi !

Nicolas Boulay wrote:
>  > > - Where can I download the latest description of the fcpu F1 ISA, the
> > >   general state of the project, what tools have been decided on, etc ?
> > no tool has been "decided" : "freedom" means that you can use any tool
> > you wish to use, as long as the files are in a publicly known format
> > (no proprietary format).
>
> In infineon, they use VHDL to made the rtl simulation but the gate level
> simulation is made in Verilog (a program translate the VHDL in Verilog).
> If you mixes a lot of different description (schematics,...), the
> problem are to simulate all the description together, and it could be
> very tricky !

we're not responsible of how fucked up a software is made ;-)

> It's possible to begin to code some operation units, but first of all
> the C (or C++) model must be written before. It's the proof of concept.
> The simulator must be enought flexible to evoluate but very quick too,
> to simulate some behavior (like running some code made by the port of
> gcc).
>
> I know a speak more than i work but the time...
yes i know ;-)


Any comment about a european meeting this summer ?
we could make a "F-CPU Camp" and meet at a common place,
in order to work altogether on the project ? wow :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01985 for ; Tue, 27 Jun 2000 00:19:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Jun 2000 00:19:47 +0200 (MEST) Received: (qmail 15937 invoked by uid 0); 26 Jun 2000 21:16:44 -0000 Received: from b05.egroups.com (207.138.41.189) by mx02.gmx.net with SMTP; 26 Jun 2000 21:16:44 -0000 X-eGroups-Return: sentto-1101623-350-962054091-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 26 Jun 2000 21:15:05 -0000 Received: (qmail 4909 invoked from network); 26 Jun 2000 21:14:45 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 26 Jun 2000 21:14:45 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 26 Jun 2000 21:14:44 -0000 Received: from f-cpu.org (Paris-Raspail-1-178.club-internet.fr [195.36.192.178]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA21054 for ; Mon, 26 Jun 2000 23:14:38 +0200 (MET DST) Message-ID: <3957C790.BF855462@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000611113044.26204.qmail@web1103.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Jun 2000 23:13:52 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc1f176a7b594ad712b32671c22463ba Status: R X-Status: N David Cary wrote:
> Dear Yann Guidon and other f-cpu designers,
hi David !

> Thanks for sharing your thoughts on a f-cpu license. You have lots of good
> stuff in there... but does it have to be so looooong ?
the licence itself shouldn't be much longer than the original GNU GPL.
the discussions, OTOH, should be as extensive as possible.

> I hate to force hundreds of people all over the planet to
> carefully read pages and pages of legal jargon.
hey, when someone installs LINUX or Windows, does he reads all
the tiny letters ? no of course ;-)
it has to be irrefutable anyway "just in case there's a problem".

> Allow me to try to trim it up -- deleting a bunch of good and even
> essential stuff in the process. Then you can try to put all the crucial
> stuff back in. Or (preferable in my opinion) you could accept my challenge
> to make it even shorter.
i thank you very much for actively participating in this debate.
as i said before, my first post was just a bunch of ideas that i wanted
to voice out loud, then we'd see if it's so good or not. i never claimed
it would be definitive :-)

> Perhaps it would be A Good Thing to have our license *be* just "patch" to
> the GPL -- have our license be just a few paragraphs long, and then say
> something like "everything else is covered by the LGPL where it does not
> conflict with the above paragraphs, see COPYING.LIB". (As opposed to having
> a document slightly longer than the GPL, with lots of duplicated text).

well, the "patch" idea is similar to what i have in mind. the "addendum
to the GPL" is not that good anyway because the licence should be self-contained
and we have to track any incoherency.

maybe we can rework the GPL by analyzing each paragraph on this mailing list ?

> Is this really legal, to copy someone else's legal document ? Aren't
> documents written by lawers covered by copyright just as much as documents
> written by anyone else ?

the copyright of the GPL is owned by the Free Software Foundation, Inc.
we would have to ask the FSF and write in our licence "this licence
is based on the GNU Pubilc Licence v1.0" etc... but that should be possible.

>     F-CPU licence rev. 0.02 // not a legal document (yet)
>     ----
>     (add your name + revision date at the bottom of the list)
>     2000-06-10: YG: original text rev. 0.01
>     2000-06-24: DAV: made random changes rev. 0.02
>     (indicate where and what you have modified)
>
>     Prologue :
>     ----
>
>     Licences are usually intended to restrict the rights of the end user.
>   | This F-CPU license is intended to guarantee your freedom to
>   + build hardware, make changes to it, and share it with others.
>
> [Should we try to make this license apply *only* to f-cpu and its
> descendents, or should we make it general-purpose and encourage any chip
> designer who wants to use it to copy it verbatim ?]

two things here :
- f-cpu only, or not ?
- f-cpu copying only, or development etc ?

for the first point, Jamil (i think it's him) asked for collaboration
about the writing of a more general licence. i see no reason to refuse it.
so we can work on the "f-cpu licence" and then rename it to a more
general name (after some little adaptations) for a more general
adoption. let's see what comes out the f-cpu licence writing first, then.

for the second point, i think that this licence should be both about
the development and the distribution of the F-CPU IP, like the GPL.
let's keep the things simple and monolithic :-)

>   + This license agreement applies to any intellectual property (IP)
>   + (including EDA, CPU
>   | architecture, IP blocks, instruction sets, software development
>   | kits...)
>   + which has been tagged with a notice saying it may be distributed
>   + under the terms of this license.

well written :-)

>     Terms and conditions for copying, distribution, and modification.
>     ----
>
>   + A "implementation" is a material product derived
>   + from the IP, for example a chip.
++ a simulator, an emulator, assembler, compiler, optimizer ...
(?)

>   | "Intellectual Property" (IP) covers all the information
>     necessary to reproduce an implementation,
>   + in the preferred form for making modifications to it.
> [perhaps use the Patent Office terminology here, "... to one skilled in the
> art ..." ... how does that go again ?]

i don't know.

>   + For example,
>   | text descriptions,
>   | pictures,
>   | schematics,
>   | source codes in various langages (VHDL, Verilog, RTL, scripts),
>   | mask files (like GDSII),
>   | fuse maps for programmable logic devices,
>   | manuals, drawings, all the data that describe the CPU, its structure,
>   | its behaviour,
>   | its interactions with other components,
>   | manufacturing parameters critical to the chip's function,
>   + and test vectors and validation suites
>   + may all be needed to reproduce and modify an implementation.
>
>     Rights and duties :
>     -------------------
> [
> YG states:
> >The reason for this break from the GPL principle is simple : the F-CPU
> >is not the property of an individual or a company, but belongs to
> >everybody.
>
> DAV:
> I don't understand. In what sense does GPL'ed software *not* belong to
> everybody ?
> ]

ok some explanations : as written (more or less clearly) in the GPL text,
the GPL uses and modifies the american constitution (1st amendment :
expression right), the copyright and the author's rights.
since you have the right to do whatever you want with what you have
created, you have the right to give otheres the right to modify your
creation according to the rules you have defined (that is : the GPL).

For the F-CPU project the background is different but the mean can be the
same : the copyright & constitution etc can be used to legally justify
that you do whatever you want with your work. The difference is that
it is not the work of an individual but it is a group work, and the F-CPU
group has no legal existence. All i did for the F-CPU, and i guess it's the
same for everybody else, is for the group, not for me and my author's rights.
in this situation, what i try to change from the GPL is : i try to remove
the rights of someone to remove the rights from others.
that's getting complex, no ? :-)

>   | A internet address (URI) must be written on each
>     implementation of the F-CPU IP.
>
>   | All the information necessary to reproduce a functionally-identical
>   + implementation must be stored at that URI.
>     This ensures that you can easily use
>     any F-CPU version or variation, simply looking at the chip's package.
>
>     For example, this is a recommended format :
>
>     * on the chip :
>
>     Zoobidah 2025-51 125089
>     see http://www.zoobidah.com/125089/
>   -
> [DAV: Few chips have copyright strings on them now; is this something we
> want to force people to add ? I think just the URI is adequate.]

yep. you're right. it was a bad habit.

>     * on the web :
>
>     http://www.zoobidah.com
>      |-- index.html indicates where the design files are located in the site.
>      |-- /125085
>      |-- /125086  \
>      |-- /125087   different implementation versions
>      |-- /125088  /
>      |-- /125089
>      |   |-- index.html
>      |   |-- README.TXT
>      |   |-- /manuals           \
>      |   |-- /datasheets         for every design and version
>      |   |-- /sdk               /
>      |   |-- /errata (nobody's perfect !)
>      |   |-- /sources
>      |  ...
>     ...
>
>     If the Zoobidah corp. copied and implemented a design of the Artchoon corp.
>     without modifying it, the index.html at http://www.zoobidah.com/125089/
>     must specify it and point to the original location of the files. Zoobidah
>     may mirror the files as well (just in case Artchoon corp. went out of
>     business without warning).
> [change "may" to "must" ?]

i don't know. it's recommended as a precaution, but we have no right or
justification to force it. i guess that in practice, an implementation based
on another will have to modify at least a few things, plus people need to leave
their "mark", so i presume that people will usually modify (even slightly but it's
enough) the IP, so they're forced to mirror everything as well as the changes
(in the form of a new archive or a patch to an old archive (that must reside at the
same location)).

>     If there was not enough surface on the package,
> [YN suggested:
> >the hardcopy manual
> >provided with the chip as well as
>
> Huh ? I've never seen a manual come with a chip. I've seen "Data Manual"s
> that describe hundreds of different chips ... but generally one buys that
> first, then selects a chip out of it.
> ]

well, you have probably seen Intel's PIIs or a motherboard box, it comes
with a sheet which says the jumper configuration and the voltage etc...

Today the de facto standard is Intel, so the characteristics are
"in the public domain", it's well known what voltage etc...

In the F-CPU world, there will be different versions,
each specific and adapted to a certain case, so you have to provide at least
a sheet indicating the socket type etc... with every single chip
that is sold to the end consumer (like when you buy a CPU from
RadioSpares or RadioShack, you see ?). If it's meant to be sold
to other companies that embed the CPU chip on a motherboard
(like, when you sell the chips to DELL for being resold on the market)
then the URI on the chip is necessary because the CPU is not sold with the
datasheet.


>     the website
>     must ensure that one can find the location of the design files
>     easily in the server, for example with a general index directly
>     reachable from the main page of the site. All the files used to fabricate
>     the chip MUST be available directly through a simple URL.
>
>   -
>     A direct URL on the chip indirectly helps you evaluate
>   | a certain chip and the new or old hardware of which it is a piece.
>   -
>     It is not
>     considered a "fair sale" to sell something without letting the user
>     know what's inside it.
>   -
>
> [YG wrote:
>     <li>
>     All software created for simulating, developing and managing
>     the F-CPU IP must be distributed under the terms of the GPL in order
>     to promote and keep the openness and freedom of the project.
>
>     Existing software that are not distributed under the terms of the GPL
>     can be ported to a F-CPU platform if these applications are not
>     platform-specific. For example, it is possible to port Mozilla
>     (distributed under the terms of the MPL), LaTeX (under LPPL) or
>     Apache to the F-CPU.
>
>     It is not possible to port non-GPL software
>     that interact directly with the machine : device drivers, OS kernels,
>     compilers, debuggers or cpu simulators/emulators. This measure is necessary
>     to keep the platform "free" from industrial pressure, arbitrary biases or
>     the damages of the discontinuing of a product line. It also ensures that
>     the new software matches the specific characteristics of the new hardware
>     with less performance lag
>     (thanks to rewriting rather than recompiling only).
>
> DAV:
> The previous 3 paragraphs looks far too restrictive. For example, say
> someone ports Wine to the f-cpu. Am I not legally allowed to use any of the
> many shareware programs that run on top of Wine ?
> On the other hand, I love the crazy optimism it conveys.
> ]

it's not even optimism, it's utopism (as everything in this project).
In fact i don't expect these rules to be closely followed by everybody.
the is meant to make everybody understand the goals of this project :
freedom. everybody is born free, we have the right to die free.
We created the F-CPU free, we don't want it to become propietary.
These 3 paragraphs were meant to define the rules of the utopic world.
btw, you won't even be able to run Wine because you'd have to emulate
the x86 :-) it's not forbiden to emulate another CPU with a F-CPU,
but it was not intended to do it (there's no emulation facility).
OTOH, every F-CPU simulator written must AT LEAST be bound by the GPL
(as long as the f-cpu licence is not ready).

to fully answer your question, there is no "risk" running a x86 emulator
as long as the emulator conforms the f-cpu (utopic) rules. the x86 emulator
offers an abstraction level so the freeware (or any other software) written
for the PC does not directly access the real HW. The emulator does access the
HW and must conform the rules described above.

of course, there is some "crazy optimism", but we have nothing to lose
in fact, because nothing exists yet ;-P this is one part of the freedom
it conveys : it give us the right to hope, imagine and dream. that is
probably the hidden message of the project.


have fun,
mom made a quiche lorraine and it's smelling good in the house :-P
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01988 for ; Tue, 27 Jun 2000 00:19:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Jun 2000 00:19:50 +0200 (MEST) Received: (qmail 28211 invoked by uid 0); 26 Jun 2000 21:51:49 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 26 Jun 2000 21:51:49 -0000 X-eGroups-Return: sentto-1101623-351-962056301-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 26 Jun 2000 21:51:52 -0000 Received: (qmail 17674 invoked from network); 26 Jun 2000 21:51:39 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 26 Jun 2000 21:51:39 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 26 Jun 2000 21:51:39 -0000 Received: from f-cpu.org (Paris-Raspail-2-211.club-internet.fr [195.36.192.211]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA04439 for ; Mon, 26 Jun 2000 23:51:32 +0200 (MET DST) Message-ID: <3957CFE5.62020B37@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Jun 2000 23:49:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6455b12d8de1c1a71db51bf8e09d2fd Status: R X-Status: N hi !

Kai Wetzel wrote:
(some common questions for the newbies too :-D)

> Yann Guidon wrote:
> [...]
> > nothing's perfect yet in the GNU world.
> > I think that i'll use Alliance because i'll maybe study where
> > they make it, so i'll be both at the place where the silicon
> > and the software are made. VHDL will certainly be used.
> How much is a copy of Alliance ?
nada. nothing. nichts. it's GPL'd.
i even have 2 copies on CD. it takes a few hundreds of megabytes for
the whole archive, some tens of MB for a working version.
it can be downloaded from the web (URL was on a post some months ago)

> What's your opinion on "Electric" (just downloaded it, not
> yet compiled) ?
i don't know. i still have to test all the things i had found months ago ;-)

> [...]
> > > Do you plan a meeting in Europe for the summer ?
> > i didn't but this would be a cool idea :-)
> > probably something in Paris then somewhere in germany ?
> I think Paris would be nice.
if it's ok, i can host one or two people, maybe three with some efforts
(and a sleeping bag :-D) if this happens when one person of my family
is in vacations, it will be even easier :-)

now, let's find a date. preferably not before three weeks.


> do you have estimates on gate depth (t) for the various FUs used
> in the FCPU arch. ?  I'd find this info very useful to test
> dependency checking in software.

i designed the FC0 around a very short pipeline, around 10 transistors
or 6 logic gates but this varies with the associated wire lengths.
it equals the complexity of approximately a 8-bit adder plus a few things around
(xor for the substraction).

> E.g. I could guess 20-25 gates for a simple 64bit unsigned int
> two-input SIMD adder, but I don't know how much to add for overflow,
> subtraction, signed, three-input, etc., let alone multiplier, sqrt,
> or even floating point instructions.  Any figures out there ?

for addition, it takes 1 cycle for 8-bit and 2 cycles for more (16->64).
for multiplication, it takes a variable time, but i have no idea yet,
it will be pipelined.
for multiplication, i think that we'll hardwire a special unit
that is not pipelined, something close to microcoded and separate from
the usual pipeline. it shouldn't impact on the overall performance
because it's not used often, and the die space can be optimized.
for the sqrt, we'll use Newton-Raphson with a first approximation
that goes through the INC then the SHIFT unit. this is a "normalisation"
where the actual number of bits is divided by two. (first : count
the number of bits, two : shift out by that number/2). A few multiplies
will do the rest.

about the floating point : no idea yet, but some classical component
libraries should do the trick for the first versions.

> [...]
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01746 for ; Fri, 30 Jun 2000 19:26:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:34 +0200 (MEST) Received: (qmail 16391 invoked by uid 0); 27 Jun 2000 14:59:45 -0000 Received: from mw.egroups.com (207.138.41.167) by mx10.rz2.gmx.net with SMTP; 27 Jun 2000 14:59:45 -0000 X-eGroups-Return: sentto-1101623-352-962117941-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 27 Jun 2000 14:59:23 -0000 Received: (qmail 20276 invoked from network); 27 Jun 2000 14:41:52 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Jun 2000 14:41:52 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 27 Jun 2000 14:41:51 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5R8SAR19160 for ; Tue, 27 Jun 2000 10:28:10 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5R8S9C10677 for ; Tue, 27 Jun 2000 10:28:09 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id KAA24409 for ; Tue, 27 Jun 2000 10:28:09 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id KAA22638 for ; Tue, 27 Jun 2000 10:26:42 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <39586598.828508F5@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 10:28:08 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70017b418e9694f9957241f84e8faec9 Status: R X-Status: N Yann Guidon wrote:
>
> hi !
>
> Kai Wetzel wrote:
> (some common questions for the newbies too :-D)
>
> > Yann Guidon wrote:

> > do you have estimates on gate depth (t) for the various FUs used
> > in the FCPU arch. ?  I'd find this info very useful to test
> > dependency checking in software.
>
> i designed the FC0 around a very short pipeline, around 10 transistors
> or 6 logic gates but this varies with the associated wire lengths.
> it equals the complexity of approximately a 8-bit adder plus a few things around
> (xor for the substraction).

If i remember correctly 8 bits adder need to propagate the carry, so you
need 8 or 10 gates layer. You could even use 3 4 bits adder (2 for the
msb) and then use multiplexor depending on the carry of the lsb, but i
think that should be the same number of gate (8 bits is very short !).
Adding some multiplexors add much more gates !

>
> > E.g. I could guess 20-25 gates for a simple 64bit unsigned int
> > two-input SIMD adder, but I don't know how much to add for overflow,
> > subtraction, signed, three-input, etc., let alone multiplier, sqrt,
> > or even floating point instructions.  Any figures out there ?
>
> for addition, it takes 1 cycle for 8-bit and 2 cycles for more (16->64).

The problem are always the carry. If you split a adder in 2 pieces like
that to make a pipeline, i think that the second pieces could much
tricky than the first (and mucher longer to go thought).

> for multiplication, it takes a variable time, but i have no idea yet,
> it will be pipelined.
> for multiplication, i think that we'll hardwire a special unit
> that is not pipelined, something close to microcoded and separate from
> the usual pipeline. it shouldn't impact on the overall performance
> because it's not used often, and the die space can be optimized.

It's depend what you make !  A simple multiplier isn't so hard to make.
It's just big !(array of adder)

> for the sqrt, we'll use Newton-Raphson with a first approximation
> that goes through the INC then the SHIFT unit. this is a "normalisation"
> where the actual number of bits is divided by two. (first : count
> the number of bits, two : shift out by that number/2). A few multiplies
> will do the rest.
>
> about the floating point : no idea yet, but some classical component
> libraries should do the trick for the first versions.
>
> > [...]
> > kai
> WHYGEE

But like i soon said, no simulator works, so it's a little bit too soon
to think of the design of the FC0. Bevore the architecture will ended, i
think that some FU will be finished.
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01749 for ; Fri, 30 Jun 2000 19:26:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:35 +0200 (MEST) Received: (qmail 489 invoked by uid 0); 27 Jun 2000 15:05:46 -0000 Received: from fk.egroups.com (208.50.144.73) by mx02.gmx.net with SMTP; 27 Jun 2000 15:05:46 -0000 X-eGroups-Return: sentto-1101623-353-962118237-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fk.egroups.com with NNFMP; 27 Jun 2000 15:04:12 -0000 Received: (qmail 6827 invoked from network); 27 Jun 2000 14:45:32 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Jun 2000 14:45:32 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 27 Jun 2000 14:45:31 -0000 Received: from dotcom.fr (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA26508 for ; Tue, 27 Jun 2000 08:00:53 GMT Message-ID: <39585F4C.FC893157@dotcom.fr> Organization: DotCom S.A. X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <39580806.3A09D8ED@welfen-netz.com> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 10:01:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Gate depth of FUs Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 844718021b3742ae570a63cfef59fcc5 Status: R X-Status: N Kai Wetzel a =E9crit :
[...]
> E.g. I could guess 20-25 gates for a simple 64bit unsigned int
> two-input SIMD adder, but I don't know how much to add for overflow, > subtraction, signed, three-input, etc., let alone multiplier, sqrt, > or even floating point instructions.  Any figures out there ?

Hi
I'm a bit puzzled: how do you count your gates?
For a 64 bits, two inputs thing, you'll need at least one gate per bit
(one gate combines 2 bits, one from each operand) I think. How can you
get less than 64 gates for such a thing?
What am I getting wrong?
--
Nicolas MATRINGE          = ; DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      92400 COURBEVOIE
Fax +33 1 46 67 51 01      FRANCE
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01776 for ; Fri, 30 Jun 2000 19:26:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:41 +0200 (MEST) Received: (qmail 11350 invoked by uid 0); 27 Jun 2000 20:58:31 -0000 Received: from ml.egroups.com (208.50.144.77) by mx02.gmx.net with SMTP; 27 Jun 2000 20:58:31 -0000 X-eGroups-Return: sentto-1101623-354-962137155-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 27 Jun 2000 21:19:44 -0000 Received: (qmail 20489 invoked from network); 27 Jun 2000 19:41:47 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 27 Jun 2000 19:41:47 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 27 Jun 2000 19:41:47 -0000 Received: from 0018728164 (host-208-60-244-59.bix.bellsouth.net [208.60.244.59]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id OAA14377; Tue, 27 Jun 2000 14:34:06 -0400 (EDT) Message-ID: <001e01bfe066$19437300$3bf43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 13:32:48 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Adders/Subtractors Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01BFE03C.2F519AC0" X-UIDL: 3b119ae8655d315ed9343883465d53cc Status: R X-Status: N ------=_NextPart_000_001B_01BFE03C.2F519AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The circuit I described in my last e-mail includes gates for full carry = over the 4 Bits. The number of gates for this purpose is: 10. The Generate output is 4 = gates and the Propagate output is one (1) gate. These were all = inclusive in the 32 gates I specified. I did not include gates = necessary for expansion beyond 4 bits. There are four (4) gate delays = >from Input args to output Sum/Diff. There is no magical way to do it = any differently and expect CORRECT results. Be carefull in the way MARKETEERS use numbers for the general = public. For example the recent article distributed on the Willamette by = Intel. It indicates that a 1 GHZ Add is obtained - that is for the = least significant BIT of the Adder which at best is 2 gate delays. = There is no manufacturing process known to man - at the present time = that will give you a 64 bit Add at 1 Nanosecond. Included in the 32 gates are four(4) XOR gates. These are required = for BOTH Add and Subtract. Their output is the Sum/Difference. =20 Sincerely Richard E Hartney Erin Greene & Associates Research Director ------=_NextPart_000_001B_01BFE03C.2F519AC0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
The circuit I described in my last e-mail includes gates for full carry over the 4 Bits.
The number of gates for this purpose is: 10.  The Generate output is 4 gates and the Propagate output is one (1) gate.  These were all inclusive in the 32 gates I specified.  I did not include gates necessary for expansion beyond 4 bits.  There are four (4) gate delays from Input args to output Sum/Diff.  There is no magical way to do it any differently and expect CORRECT results.
    Be carefull in the way MARKETEERS use numbers for the general public.  For example the recent article distributed on the Willamette by Intel.  It indicates that a 1 GHZ Add is obtained - that is for the least significant BIT of the Adder which at best is 2 gate delays.  There is no manufacturing process known to man - at the present time that will give you a 64 bit Add  at 1 Nanosecond.
    Included in the 32 gates are four(4) XOR gates.  These are required for BOTH Add and Subtract.  Their output is the Sum/Difference. 
 
Sincerely
Richard E Hartney
Erin Greene & Associates
Research Director
------=_NextPart_000_001B_01BFE03C.2F519AC0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01788 for ; Fri, 30 Jun 2000 19:26:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:44 +0200 (MEST) Received: (qmail 11664 invoked by uid 0); 27 Jun 2000 23:14:14 -0000 Received: from ck.egroups.com (208.50.144.69) by mx02.gmx.net with SMTP; 27 Jun 2000 23:14:14 -0000 X-eGroups-Return: sentto-1101623-355-962141849-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.143] by ck.egroups.com with NNFMP; 27 Jun 2000 21:37:39 -0000 Received: (qmail 9609 invoked from network); 27 Jun 2000 21:25:02 -0000 Received: from unknown (10.1.10.26) by m7.onelist.org with QMQP; 27 Jun 2000 21:25:02 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 27 Jun 2000 21:25:02 -0000 Received: from welfen-netz.com [213.6.89.140] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 27 Jun 2000 23:24:06 +0200 Sender: kai@pop.gmx.net Message-ID: <395990EF.BAA4490@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39580806.3A09D8ED@welfen-netz.com> <39585F4C.FC893157@dotcom.fr> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 07:45:19 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Gate depth of FUs Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d0e9bd3c74aebb2a376edc9adbb8777d Status: R X-Status: N Nicolas Matringe wrote:
>
> Kai Wetzel a =E9crit :
> [...]
> > E.g. I could guess 20-25 gates for a simple 64bit unsigned int > > two-input SIMD adder, but I don't know how much to add for overfl= ow,
> > subtraction, signed, three-input, etc., let alone multiplier, sqr= t,
> > or even floating point instructions.  Any figures out there = ?
>
> Hi
> I'm a bit puzzled: how do you count your gates?

Well, I got carried away a little : I counted a select delay
as only taking as long as a single gate =3D)

> For a 64 bits, two inputs thing, you'll need at least one gate per bit=
> (one gate combines 2 bits, one from each operand) I think. How can you=
> get less than 64 gates for such a thing?

Well, it's a compromize between size and speed - my
calculation was based on an adder which calculates 16 * 4bit
chunks in parallel, for the carry=3D0 and carry=3D1 cases each (adding
up to 32 4bit adders), the adders beeing very fast (but also big).  Pi= cking
the right result for each is done by running over the 16(15)
individual results, propagating the carry with just a single
"select" delay (which I counted as one gate, wrongly) for each. (This was my 3 + 16 calculation, but it's not "gates", and
there are various options in this approach (from the AlphaRISC
guy, I hope I didn't misunderstand it completely) as well as somewhat
different designs (carry select adder (?), carry-look-ahead adder which the=
above is supposed to be a variant of, IIRC)
I don't know what approach today's processors usually take ?

In the actual layout some other points will play a role, such allowing
new operants to enter way before the "current" result is computed= .

kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01791 for ; Fri, 30 Jun 2000 19:26:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:44 +0200 (MEST) Received: (qmail 10388 invoked by uid 0); 27 Jun 2000 23:31:41 -0000 Received: from hp.egroups.com (208.50.144.93) by mx02.gmx.net with SMTP; 27 Jun 2000 23:31:41 -0000 X-eGroups-Return: sentto-1101623-356-962141849-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.143] by hp.egroups.com with NNFMP; 27 Jun 2000 21:39:37 -0000 Received: (qmail 9611 invoked from network); 27 Jun 2000 21:25:02 -0000 Received: from unknown (10.1.10.26) by m7.onelist.org with QMQP; 27 Jun 2000 21:25:02 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 27 Jun 2000 21:25:02 -0000 Received: from welfen-netz.com [213.6.89.140] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 27 Jun 2000 23:23:59 +0200 Sender: kai@pop.gmx.net Message-ID: <39598D9A.F636DE93@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> <39586598.828508F5@hl.siemens.de> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 07:31:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8e56eb337ea24f4a5e0a6611f8af653a Status: R X-Status: N Nicolas Boulay wrote:
[...]
> But like i soon said, no simulator works, so it's a little bit too soon
> to think of the design of the FC0. Bevore the architecture will ended, i
> think that some FU will be finished.

What's the status of our FCPU simulators ?

> nicO
>
> ------------------------------------------------------------------------
> IT Professionals: Match your unique skills with the best IT projects at
> http://click.egroups.com/1/3381/1/_/3462/_/962117941/
> ------------------------------------------------------------------------

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01794 for ; Fri, 30 Jun 2000 19:26:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:46 +0200 (MEST) Received: (qmail 12619 invoked by uid 0); 27 Jun 2000 23:50:56 -0000 Received: from jj.egroups.com (208.50.144.82) by mx10.rz2.gmx.net with SMTP; 27 Jun 2000 23:50:56 -0000 X-eGroups-Return: sentto-1101623-357-962141924-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 27 Jun 2000 21:39:08 -0000 Received: (qmail 5537 invoked from network); 27 Jun 2000 21:25:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Jun 2000 21:25:05 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 27 Jun 2000 21:25:05 -0000 Received: from welfen-netz.com [213.6.89.140] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 27 Jun 2000 23:24:03 +0200 Sender: kai@pop.gmx.net Message-ID: <39598EFC.BA19ADD2@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 07:37:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7bb661128017dfe2cfb65b3a7a5b4760 Status: R X-Status: N Yann Guidon wrote:
[...]
> > How much is a copy of Alliance ?
> nada. nothing. nichts. it's GPL'd.
> i even have 2 copies on CD. it takes a few hundreds of megabytes for
> the whole archive, some tens of MB for a working version.

Hmm, maybe you could send me one which I could copy and then send back ?

> it can be downloaded from the web (URL was on a post some months ago)

Yeah, 28.8 modem here :^(

[...]
> > I think Paris would be nice.
> if it's ok, i can host one or two people, maybe three with some efforts
> (and a sleeping bag :-D) if this happens when one person of my family
> is in vacations, it will be even easier :-)
>
> now, let's find a date. preferably not before three weeks.

Between July 15 - July 25 is ok, July 25 to August 10 isn't, then
>from mid-August is fine.

[...]
Regards,
kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01797 for ; Fri, 30 Jun 2000 19:26:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:46 +0200 (MEST) Received: (qmail 27615 invoked by uid 0); 28 Jun 2000 00:01:52 -0000 Received: from hk.egroups.com (208.50.144.91) by mx02.gmx.net with SMTP; 28 Jun 2000 00:01:52 -0000 X-eGroups-Return: sentto-1101623-358-962146616-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 27 Jun 2000 22:58:10 -0000 Received: (qmail 32646 invoked from network); 27 Jun 2000 22:56:56 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Jun 2000 22:56:56 -0000 Received: from unknown (HELO elvis.paf.net) (212.72.66.171) by mta1 with SMTP; 27 Jun 2000 22:56:55 -0000 Received: by elvis.paf.net (Postfix, from userid 1002) id 9AE0B7B; Wed, 28 Jun 2000 00:28:54 +0200 (CEST) To: f-cpu@egroups.com Message-ID: <20000628002854.B72862@elvis.paf.net> References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> <39598EFC.BA19ADD2@welfen-netz.com> X-Mailer: Mutt 1.0.1i In-Reply-To: <39598EFC.BA19ADD2@welfen-netz.com>; from k.wetzel@welfen-netz.com on Wed, Jun 28, 2000 at 07:37:00AM +0200 Sender: sturm@elvis.paf.net From: Fabian Sturm MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 00:28:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 074a0ac77f8f3056fc29a8dffb7c62ac Status: R X-Status: N Hello!

On Wed, Jun 28, 2000 at 07:37:00AM +0200, Kai Wetzel wrote:
> Yann Guidon wrote:
> > > I think Paris would be nice.

Perhaps Germany would be also good,
perhaps we can combine a meeting of all
people with the creation of the germany f-cpu association?

Would be a nice party.

CU Fabian
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01803 for ; Fri, 30 Jun 2000 19:26:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:47 +0200 (MEST) Received: (qmail 15600 invoked by uid 0); 28 Jun 2000 05:04:59 -0000 Received: from ef.egroups.com (207.138.41.172) by mx09.rz2.gmx.net with SMTP; 28 Jun 2000 05:04:59 -0000 X-eGroups-Return: sentto-1101623-359-962168679-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 28 Jun 2000 05:04:43 -0000 Received: (qmail 23627 invoked from network); 28 Jun 2000 05:04:38 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 28 Jun 2000 05:04:38 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta1 with SMTP; 28 Jun 2000 05:04:38 -0000 Received: from 0018728164 (host-209-214-154-221.bix.bellsouth.net [209.214.154.221]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id GAA19331; Tue, 27 Jun 2000 06:46:37 -0400 (EDT) Message-ID: <000801bfe024$c9a15060$dd9ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 05:45:17 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Adders/Subtractors Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFDFFA.DFAF7820" X-UIDL: 151117a042fb3cf2d35fc0b9f7629361 Status: R X-Status: N ------=_NextPart_000_0005_01BFDFFA.DFAF7820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To he who ASKED. =20 A 4-bit Adder requires 32 gates of various types. The circuit has 4-A = inputs; 4-B inputs and a Carry Input. There are four Sum/Difference = outputs and a Generate, Propagate output for Carry-Look Ahead. An 8-Bit = Add time is equal to that of a 16 Bit Add. A 32 bit Add requires one = additional gate delay. A 64 bit Add requires still another gate delay. = Therefore a 64 bit Add requires 512 gates plus carry look ahead gates. = An Add will be one gate delay faster than a Subtract because the B Input = has to be Complemented for the Subtract. I have no idea how this would = translate to transistors due to virtually no experience in this area of = design. Others will have this answer. Sincerely Richard E. Hartney Erin Greene & Associates Research Director ------=_NextPart_000_0005_01BFDFFA.DFAF7820 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
To he who ASKED. 
 
A 4-bit Adder requires 32 gates of various types.  The circuit has 4-A inputs; 4-B inputs and a Carry Input.  There are four Sum/Difference outputs and a Generate, Propagate output for Carry-Look Ahead.  An 8-Bit Add time is equal to that of a 16 Bit Add.  A 32 bit Add requires one additional gate delay.  A 64 bit Add requires still another gate delay.  Therefore a 64 bit Add requires 512 gates plus carry look ahead gates.  An Add will be one gate delay faster than a Subtract because the B Input has to be Complemented for the Subtract.  I have no idea how this would translate to transistors due to virtually no experience in this area of design.  Others will have this answer.
 
Sincerely
Richard E. Hartney
Erin Greene & Associates
Research Director
------=_NextPart_000_0005_01BFDFFA.DFAF7820-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01806 for ; Fri, 30 Jun 2000 19:26:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:49 +0200 (MEST) Received: (qmail 31206 invoked by uid 0); 28 Jun 2000 06:21:52 -0000 Received: from cj.egroups.com (208.50.144.68) by mx02.gmx.net with SMTP; 28 Jun 2000 06:21:52 -0000 X-eGroups-Return: sentto-1101623-360-962172778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 28 Jun 2000 06:12:59 -0000 Received: (qmail 20039 invoked from network); 28 Jun 2000 06:12:58 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Jun 2000 06:12:58 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 28 Jun 2000 06:12:58 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000628061257.LHFW5585.mail.rdc1.wa.home.com@nventure.com> for ; Tue, 27 Jun 2000 23:12:57 -0700 Message-ID: <395995A1.2FCF8B12@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Jun 2000 23:05:21 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a0e513517414e6e2fe1e0d2b8b42afb7 Status: R X-Status: N "Richard E.Hartney" wrote:
    Be carefull in the way MARKETEERS use numbers for the general public.  For example the recent article distributed on the Willamette by Intel.  It indicates that a 1 GHZ Add is obtained - that is for the least significant BIT of the Adder which at best is 2 gate delays.  There is no manufacturing process known to man - at the present time that will give you a 64 bit Add  at 1 Nanosecond.


As a matter of fact, HBT's (heterojunction bipolar transistors) Silicon Germanium or Gallium Arsenide (which were discussed in a much earlier thread) currently allow something on the order of 10-16 64-bit adds in one nanosecond.  This is why the technology is being pursued by designers of supercomputers.  Both Seymour Cray and Tera supercomputing (which recently bought Cray Research) chose GaAs -- not Silicon -- becuase of its characteristics.

You're right that Intel has tended to bend the truth in the past, but 32-bit adds are being performed right now on advanced pipeline processors.  ECL, another bipolar technology from the olden days of mainframes, now offer lower power characteristics, making it a viable option for microprocessors.  Exponential used these transistors to build their 704 version of the PowerPC, realizing clock rates more than twice as high as those being fabbed by Big Blue and Motorola using CMOS.

I'd still like to see what kind of performance could be achieved using a VLIW processor without decode fabbed using ECL transistors... probably something beyond 2GHz using .18 um.

--Maxx

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01809 for ; Fri, 30 Jun 2000 19:26:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:49 +0200 (MEST) Received: (qmail 7143 invoked by uid 0); 28 Jun 2000 07:38:06 -0000 Received: from ck.egroups.com (208.50.144.69) by mx06.rz2.gmx.net with SMTP; 28 Jun 2000 07:38:06 -0000 X-eGroups-Return: sentto-1101623-361-962177810-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 28 Jun 2000 07:36:51 -0000 Received: (qmail 28181 invoked from network); 28 Jun 2000 07:36:49 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 28 Jun 2000 07:36:49 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 28 Jun 2000 07:36:49 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5S7amR20639 for ; Wed, 28 Jun 2000 09:36:48 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5S7alr22377 for ; Wed, 28 Jun 2000 09:36:47 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id JAA11142 for ; Wed, 28 Jun 2000 09:36:47 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id JAA04758 for ; Wed, 28 Jun 2000 09:35:19 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <3959AB0D.4DD00634@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 09:36:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2e78983e1c08fbb0577168633efe8ccc Status: R X-Status: N > "Richard E.Hartney" wrote:

>     Be carefull in the way MARKETEERS use numbers for the general
> public.  For example the recent article distributed on the Willamette
> by Intel.  It indicates that a 1 GHZ Add is obtained - that is for the
> least significant BIT of the Adder which at best is 2 gate delays.
> There is no manufacturing process known to man - at the present time
> that will give you a 64 bit Add  at 1 Nanosecond.

I have recently read the characteristics of the new TDMC .15 um process,
they speak about 18 ps of delay for a nand gate. They don't precise the
delay in the wire which should longer than the gate one, nowadays. But
you could put a lot of gate layers bevore going to 1 ns.

IBM ,for his new process, speak about a speed of 3 Ghz for this PPC...

>
> Sincerely
> Richard E Hartney
> Erin Greene & Associates
> Research Director
> ----------------------------------------------------------------------
>
> ----------------------------------------------------------------------
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01815 for ; Fri, 30 Jun 2000 19:26:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:26:51 +0200 (MEST) Received: (qmail 10650 invoked by uid 0); 28 Jun 2000 09:17:18 -0000 Received: from mq.egroups.com (207.138.41.138) by mx02.gmx.net with SMTP; 28 Jun 2000 09:17:18 -0000 X-eGroups-Return: sentto-1101623-362-962183631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mq.egroups.com with NNFMP; 28 Jun 2000 09:13:42 -0000 Received: (qmail 27419 invoked from network); 28 Jun 2000 09:13:50 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Jun 2000 09:13:50 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 28 Jun 2000 09:13:48 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5S9DkR09553 for ; Wed, 28 Jun 2000 11:13:46 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5S9Dj420259 for ; Wed, 28 Jun 2000 11:13:45 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id LAA16499 for ; Wed, 28 Jun 2000 11:13:45 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id LAA09681 for ; Wed, 28 Jun 2000 11:12:16 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <3959C1C7.28CF4AF6@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:13:43 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: multipart/mixed; boundary="------------DB100DACB251A8B335A3470A" X-UIDL: 38afad46c7610b831ddd9260f1563f00 Status: R X-Status: N --------------DB100DACB251A8B335A3470A Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I don't remember where i found this paper. But after a cross read, i think that it could be a good way to make more than 1 instruction per clock cycle efficiently and having a goog way to increase speed in the futur with keeping the compatibility. --------------DB100DACB251A8B335A3470A Content-Type: application/postscript; name="smtcompiler.ps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="smtcompiler.ps" %!PS-Adobe-3.0 %%BoundingBox: (atend) %%Pages: (atend) %%PageOrder: (atend) %%DocumentFonts: (atend) %%Creator: Frame 4.0 %%DocumentData: Clean7Bit %%EndComments %%BeginProlog % % Frame ps_prolog 4.0, for use with Frame 4.0 products % This ps_prolog file is Copyright (c) 1986-1993 Frame Technology % Corporation. All rights reserved. This ps_prolog file may be % freely copied and distributed in conjunction with documents created % using FrameMaker, FrameBuilder and FrameViewer as long as this % copyright notice is preserved. % % Frame products normally print colors as their true color on a color printer % or as shades of gray, based on luminance, on a black-and white printer. The % following flag, if set to True, forces all non-white colors to print as pure % black. This has no effect on bitmap images. /FMPrintAllColorsAsBlack false def % % Frame products can either set their own line screens or use a printer's % default settings. Three flags below control this separately for no % separations, spot separations and process separations. If a flag % is true, then the default printer settings will not be changed. If it is % false, Frame products will use their own settings from a table based on % the printer's resolution. /FMUseDefaultNoSeparationScreen true def /FMUseDefaultSpotSeparationScreen true def /FMUseDefaultProcessSeparationScreen false def % % For any given PostScript printer resolution, Frame products have two sets of % screen angles and frequencies for printing process separations, which are % recomended by Adobe. The following variable chooses the higher frequencies % when set to true or the lower frequencies when set to false. This is only % effective if the appropriate FMUseDefault...SeparationScreen flag is false. /FMUseHighFrequencyScreens true def % % PostScript Level 2 printers contain an "Accurate Screens" feature which can % improve process separation rendering at the expense of compute time. This % flag is ignored by PostScript Level 1 printers. /FMUseAcccurateScreens true def % % The following PostScript procedure defines the spot function that Frame % products will use for process separations. You may un-comment-out one of % the alternative functions below, or use your own. % % Dot function /FMSpotFunction {abs exch abs 2 copy add 1 gt {1 sub dup mul exch 1 sub dup mul add 1 sub } {dup mul exch dup mul add 1 exch sub }ifelse } def % % Line function % /FMSpotFunction { pop } def % % Elipse function % /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add % sqrt 1 exch sub } def % % /FMversion (4.0) def /FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def /FMPColor FMLevel1 { false /colorimage where {pop pop true} if } { true } ifelse def /FrameDict 400 dict def systemdict /errordict known not {/errordict 10 dict def errordict /rangecheck {stop} put} if % The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk FrameDict /tmprangecheck errordict /rangecheck get put errordict /rangecheck {FrameDict /bug true put} put FrameDict /bug false put mark % Some PS machines read past the CR, so keep the following 3 lines together! currentfile 5 string readline 00 0000000000 cleartomark errordict /rangecheck FrameDict /tmprangecheck get put FrameDict /bug get { /readline { /gstring exch def /gfile exch def /gindex 0 def { gfile read pop dup 10 eq {exit} if dup 13 eq {exit} if gstring exch gindex exch put /gindex gindex 1 add def } loop pop gstring 0 gindex getinterval true } bind def } if /FMshowpage /showpage load def /FMquit /quit load def /FMFAILURE { dup = flush FMshowpage /Helvetica findfont 12 scalefont setfont 72 200 moveto show FMshowpage FMquit } def /FMVERSION { FMversion ne { (Frame product version does not match ps_prolog!) FMFAILURE } if } def /FMBADEPSF { (PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X ) dup dup (X) search pop exch pop exch pop length 4 -1 roll putinterval FMFAILURE } def /FMLOCAL { FrameDict begin 0 def end } def /concatprocs { /proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx }def FrameDict begin /FMnone 0 def /FMcyan 1 def /FMmagenta 2 def /FMyellow 3 def /FMblack 4 def /FMcustom 5 def /FrameNegative false def /FrameSepIs FMnone def /FrameSepBlack 0 def /FrameSepYellow 0 def /FrameSepMagenta 0 def /FrameSepCyan 0 def /FrameSepRed 1 def /FrameSepGreen 1 def /FrameSepBlue 1 def /FrameCurGray 1 def /FrameCurPat null def /FrameCurColors [ 0 0 0 1 0 0 0 ] def /FrameColorEpsilon .001 def /eqepsilon { sub dup 0 lt {neg} if FrameColorEpsilon le } bind def /FrameCmpColorsCMYK { 2 copy 0 get exch 0 get eqepsilon { 2 copy 1 get exch 1 get eqepsilon { 2 copy 2 get exch 2 get eqepsilon { 3 get exch 3 get eqepsilon } {pop pop false} ifelse }{pop pop false} ifelse } {pop pop false} ifelse } bind def /FrameCmpColorsRGB { 2 copy 4 get exch 0 get eqepsilon { 2 copy 5 get exch 1 get eqepsilon { 6 get exch 2 get eqepsilon }{pop pop false} ifelse } {pop pop false} ifelse } bind def /RGBtoCMYK { 1 exch sub 3 1 roll 1 exch sub 3 1 roll 1 exch sub 3 1 roll 3 copy 2 copy le { pop } { exch pop } ifelse 2 copy le { pop } { exch pop } ifelse dup dup dup 6 1 roll 4 1 roll 7 1 roll sub 6 1 roll sub 5 1 roll sub 4 1 roll } bind def /CMYKtoRGB { dup dup 4 -1 roll add 5 1 roll 3 -1 roll add 4 1 roll add 1 exch sub dup 0 lt {pop 0} if 3 1 roll 1 exch sub dup 0 lt {pop 0} if exch 1 exch sub dup 0 lt {pop 0} if exch } bind def /FrameSepInit { 1.0 RealSetgray } bind def /FrameSetSepColor { /FrameSepBlue exch def /FrameSepGreen exch def /FrameSepRed exch def /FrameSepBlack exch def /FrameSepYellow exch def /FrameSepMagenta exch def /FrameSepCyan exch def /FrameSepIs FMcustom def setCurrentScreen } bind def /FrameSetCyan { /FrameSepBlue 1.0 def /FrameSepGreen 1.0 def /FrameSepRed 0.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 1.0 def /FrameSepIs FMcyan def setCurrentScreen } bind def /FrameSetMagenta { /FrameSepBlue 1.0 def /FrameSepGreen 0.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 1.0 def /FrameSepCyan 0.0 def /FrameSepIs FMmagenta def setCurrentScreen } bind def /FrameSetYellow { /FrameSepBlue 0.0 def /FrameSepGreen 1.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 1.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMyellow def setCurrentScreen } bind def /FrameSetBlack { /FrameSepBlue 0.0 def /FrameSepGreen 0.0 def /FrameSepRed 0.0 def /FrameSepBlack 1.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMblack def setCurrentScreen } bind def /FrameNoSep { /FrameSepIs FMnone def setCurrentScreen } bind def /FrameSetSepColors { FrameDict begin [ exch 1 add 1 roll ] /FrameSepColors exch def end } bind def /FrameColorInSepListCMYK { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsCMYK { pop true exit } if } forall dup true ne {pop false} if } bind def /FrameColorInSepListRGB { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsRGB { pop true exit } if } forall dup true ne {pop false} if } bind def /RealSetgray /setgray load def /RealSetrgbcolor /setrgbcolor load def /RealSethsbcolor /sethsbcolor load def end /setgray { FrameDict begin FrameSepIs FMnone eq { RealSetgray } { FrameSepIs FMblack eq { RealSetgray } { FrameSepIs FMcustom eq FrameSepRed 0 eq and FrameSepGreen 0 eq and FrameSepBlue 0 eq and { RealSetgray } { 1 RealSetgray pop } ifelse } ifelse } ifelse end } bind def /setrgbcolor { FrameDict begin FrameSepIs FMnone eq { RealSetrgbcolor } { 3 copy [ 4 1 roll ] FrameColorInSepListRGB { FrameSepBlue eq exch FrameSepGreen eq and exch FrameSepRed eq and { 0 } { 1 } ifelse } { FMPColor { RealSetrgbcolor currentcmykcolor } { RGBtoCMYK } ifelse FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind def /sethsbcolor { FrameDict begin FrameSepIs FMnone eq { RealSethsbcolor } { RealSethsbcolor currentrgbcolor setrgbcolor } ifelse end } bind def FrameDict begin /setcmykcolor where { pop /RealSetcmykcolor /setcmykcolor load def } { /RealSetcmykcolor { 4 1 roll 3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat setrgbcolor pop } bind def } ifelse userdict /setcmykcolor { FrameDict begin FrameSepIs FMnone eq { RealSetcmykcolor } { 4 copy [ 5 1 roll ] FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and { 0 } { 1 } ifelse } { FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind put FMLevel1 not { /patProcDict 5 dict dup begin <0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def <8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -1 -1 moveto 9 9 lineto stroke } bind def <03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def end def /patDict 15 dict dup begin /PatternType 1 def /PaintType 2 def /TilingType 3 def /BBox [ 0 0 8 8 ] def /XStep 8 def /YStep 8 def /PaintProc { begin patProcDict bstring known { patProcDict bstring get exec } { 8 8 true [1 0 0 -1 0 8] bstring imagemask } ifelse end } bind def end def } if /combineColor { FrameSepIs FMnone eq { graymode FMLevel1 or not { [/Pattern [/DeviceCMYK]] setcolorspace FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor } { FrameCurColors 3 get 1.0 ge { FrameCurGray RealSetgray } { FMPColor graymode and { 0 1 3 { FrameCurColors exch get 1 FrameCurGray sub mul } for RealSetcmykcolor } { 4 1 6 { FrameCurColors exch get graymode { 1 exch sub 1 FrameCurGray sub mul 1 exch sub } { 1.0 lt {FrameCurGray} {1} ifelse } ifelse } for RealSetrgbcolor } ifelse } ifelse } ifelse } { FrameCurColors 0 4 getinterval aload FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and FrameSepIs FMcustom eq and { FrameCurGray } { 1 } ifelse } { FrameSepIs FMblack eq {FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse graymode FMLevel1 or not { [/Pattern [/DeviceGray]] setcolorspace FrameCurPat setcolor } { graymode not FMLevel1 and { dup 1 lt {pop FrameCurGray} if } if RealSetgray } ifelse } ifelse } bind def /savematrix { orgmatrix currentmatrix pop } bind def /restorematrix { orgmatrix setmatrix } bind def /dmatrix matrix def /dpi 72 0 dmatrix defaultmatrix dtransform dup mul exch dup mul add sqrt def /freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def /sangle 1 0 dmatrix defaultmatrix dtransform exch atan def /dpiranges [ 2540 2400 1693 1270 1200 635 600 0 ] def /CMLowFreqs [ 100.402 94.8683 89.2289 100.402 94.8683 66.9349 63.2456 47.4342 ] def /YLowFreqs [ 95.25 90.0 84.65 95.25 90.0 70.5556 66.6667 50.0 ] def /KLowFreqs [ 89.8026 84.8528 79.8088 89.8026 84.8528 74.8355 70.7107 53.033 ] def /CLowAngles [ 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 ] def /MLowAngles [ 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 ] def /YLowTDot [ true true false true true false false false ] def /CMHighFreqs [ 133.87 126.491 133.843 108.503 102.523 100.402 94.8683 63.2456 ] def /YHighFreqs [ 127.0 120.0 126.975 115.455 109.091 95.25 90.0 60.0 ] def /KHighFreqs [ 119.737 113.137 119.713 128.289 121.218 89.8026 84.8528 63.6395 ] def /CHighAngles [ 71.5651 71.5651 71.5651 70.0169 70.0169 71.5651 71.5651 71.5651 ] def /MHighAngles [ 18.4349 18.4349 18.4349 19.9831 19.9831 18.4349 18.4349 18.4349 ] def /YHighTDot [ false false true false false true true false ] def /PatFreq [ 10.5833 10.0 9.4055 10.5833 10.0 10.5833 10.0 9.375 ] def /screenIndex { 0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for } bind def /getCyanScreen { FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getMagentaScreen { FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getYellowScreen { FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse screenIndex dup 3 1 roll get 3 1 roll get { 3 div {2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat FMSpotFunction } } {/FMSpotFunction load } ifelse 0.0 exch } bind def /getBlackScreen { FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse screenIndex get 45.0 /FMSpotFunction load } bind def /getSpotScreen { getBlackScreen } bind def /getCompositeScreen { getBlackScreen } bind def /FMSetScreen FMLevel1 { /setscreen load }{ { 8 dict begin /HalftoneType 1 def /SpotFunction exch def /Angle exch def /Frequency exch def /AccurateScreens FMUseAcccurateScreens def currentdict end sethalftone } bind } ifelse def /setDefaultScreen { FMPColor { orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer } { orgxfer cvx settransfer } ifelse orgfreq organgle orgproc cvx setscreen } bind def /setCurrentScreen { FrameSepIs FMnone eq { FMUseDefaultNoSeparationScreen { setDefaultScreen } { getCompositeScreen FMSetScreen } ifelse } { FrameSepIs FMcustom eq { FMUseDefaultSpotSeparationScreen { setDefaultScreen } { getSpotScreen FMSetScreen } ifelse } { FMUseDefaultProcessSeparationScreen { setDefaultScreen } { FrameSepIs FMcyan eq { getCyanScreen FMSetScreen } { FrameSepIs FMmagenta eq { getMagentaScreen FMSetScreen } { FrameSepIs FMyellow eq { getYellowScreen FMSetScreen } { getBlackScreen FMSetScreen } ifelse } ifelse } ifelse } ifelse } ifelse } ifelse } bind def end /gstring FMLOCAL /gfile FMLOCAL /gindex FMLOCAL /orgrxfer FMLOCAL /orggxfer FMLOCAL /orgbxfer FMLOCAL /orgxfer FMLOCAL /orgproc FMLOCAL /orgrproc FMLOCAL /orggproc FMLOCAL /orgbproc FMLOCAL /organgle FMLOCAL /orgrangle FMLOCAL /orggangle FMLOCAL /orgbangle FMLOCAL /orgfreq FMLOCAL /orgrfreq FMLOCAL /orggfreq FMLOCAL /orgbfreq FMLOCAL /yscale FMLOCAL /xscale FMLOCAL /edown FMLOCAL /manualfeed FMLOCAL /paperheight FMLOCAL /paperwidth FMLOCAL /FMDOCUMENT { array /FMfonts exch def /#copies exch def FrameDict begin 0 ne /manualfeed exch def /paperheight exch def /paperwidth exch def 0 ne /FrameNegative exch def 0 ne /edown exch def /yscale exch def /xscale exch def FMLevel1 { manualfeed {setmanualfeed} if /FMdicttop countdictstack 1 add def /FMoptop count def setpapername manualfeed {true} {papersize} ifelse {manualpapersize} {false} ifelse {desperatepapersize} {false} ifelse { (Can't select requested paper size for Frame print job!) FMFAILURE } if count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for } {{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped { (Can't select requested paper size for Frame print job!) FMFAILURE } if {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop } ifelse FMPColor { currentcolorscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def cvlit /orgbproc exch def /orgbangle exch def /orgbfreq exch def cvlit /orggproc exch def /orggangle exch def /orggfreq exch def cvlit /orgrproc exch def /orgrangle exch def /orgrfreq exch def currentcolortransfer FrameNegative { 1 1 4 { pop { 1 exch sub } concatprocs 4 1 roll } for 4 copy setcolortransfer } if cvlit /orgxfer exch def cvlit /orgbxfer exch def cvlit /orggxfer exch def cvlit /orgrxfer exch def } { currentscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def currenttransfer FrameNegative { { 1 exch sub } concatprocs dup settransfer } if cvlit /orgxfer exch def } ifelse end } def /pagesave FMLOCAL /orgmatrix FMLOCAL /landscape FMLOCAL /pwid FMLOCAL /FMBEGINPAGE { FrameDict begin /pagesave save def 3.86 setmiterlimit /landscape exch 0 ne def landscape { 90 rotate 0 exch dup /pwid exch def neg translate pop }{ pop /pwid exch def } ifelse edown { [-1 0 0 1 pwid 0] concat } if 0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 0 paperheight lineto 0 0 lineto 1 setgray fill xscale yscale scale /orgmatrix matrix def gsave } def /FMENDPAGE { grestore pagesave restore end showpage } def /FMFONTDEFINE { FrameDict begin findfont ReEncode 1 index exch definefont FMfonts 3 1 roll put end } def /FMFILLS { FrameDict begin dup array /fillvals exch def dict /patCache exch def end } def /FMFILL { FrameDict begin fillvals 3 1 roll put end } def /FMNORMALIZEGRAPHICS { newpath 0.0 0.0 moveto 1 setlinewidth 0 setlinecap 0 0 0 sethsbcolor 0 setgray } bind def /fx FMLOCAL /fy FMLOCAL /fh FMLOCAL /fw FMLOCAL /llx FMLOCAL /lly FMLOCAL /urx FMLOCAL /ury FMLOCAL /FMBEGINEPSF { end /FMEPSF save def /showpage {} def % See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714. % "...the following operators MUST NOT be used in an EPS file:" (emphasis ours) /banddevice {(banddevice) FMBADEPSF} def /clear {(clear) FMBADEPSF} def /cleardictstack {(cleardictstack) FMBADEPSF} def /copypage {(copypage) FMBADEPSF} def /erasepage {(erasepage) FMBADEPSF} def /exitserver {(exitserver) FMBADEPSF} def /framedevice {(framedevice) FMBADEPSF} def /grestoreall {(grestoreall) FMBADEPSF} def /initclip {(initclip) FMBADEPSF} def /initgraphics {(initgraphics) FMBADEPSF} def /initmatrix {(initmatrix) FMBADEPSF} def /quit {(quit) FMBADEPSF} def /renderbands {(renderbands) FMBADEPSF} def /setglobal {(setglobal) FMBADEPSF} def /setpagedevice {(setpagedevice) FMBADEPSF} def /setshared {(setshared) FMBADEPSF} def /startjob {(startjob) FMBADEPSF} def /lettertray {(lettertray) FMBADEPSF} def /letter {(letter) FMBADEPSF} def /lettersmall {(lettersmall) FMBADEPSF} def /11x17tray {(11x17tray) FMBADEPSF} def /11x17 {(11x17) FMBADEPSF} def /ledgertray {(ledgertray) FMBADEPSF} def /ledger {(ledger) FMBADEPSF} def /legaltray {(legaltray) FMBADEPSF} def /legal {(legal) FMBADEPSF} def /statementtray {(statementtray) FMBADEPSF} def /statement {(statement) FMBADEPSF} def /executivetray {(executivetray) FMBADEPSF} def /executive {(executive) FMBADEPSF} def /a3tray {(a3tray) FMBADEPSF} def /a3 {(a3) FMBADEPSF} def /a4tray {(a4tray) FMBADEPSF} def /a4 {(a4) FMBADEPSF} def /a4small {(a4small) FMBADEPSF} def /b4tray {(b4tray) FMBADEPSF} def /b4 {(b4) FMBADEPSF} def /b5tray {(b5tray) FMBADEPSF} def /b5 {(b5) FMBADEPSF} def FMNORMALIZEGRAPHICS [/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall fx fw 2 div add fy fh 2 div add translate rotate fw 2 div neg fh 2 div neg translate fw urx llx sub div fh ury lly sub div scale llx neg lly neg translate /FMdicttop countdictstack 1 add def /FMoptop count def } bind def /FMENDEPSF { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMEPSF restore FrameDict begin } bind def FrameDict begin /setmanualfeed { %%BeginFeature *ManualFeed True statusdict /manualfeed true put %%EndFeature } bind def /max {2 copy lt {exch} if pop} bind def /min {2 copy gt {exch} if pop} bind def /inch {72 mul} def /pagedimen { paperheight sub abs 16 lt exch paperwidth sub abs 16 lt and {/papername exch def} {pop} ifelse } bind def /papersizedict FMLOCAL /setpapername { /papersizedict 14 dict def papersizedict begin /papername /unknown def /Letter 8.5 inch 11.0 inch pagedimen /LetterSmall 7.68 inch 10.16 inch pagedimen /Tabloid 11.0 inch 17.0 inch pagedimen /Ledger 17.0 inch 11.0 inch pagedimen /Legal 8.5 inch 14.0 inch pagedimen /Statement 5.5 inch 8.5 inch pagedimen /Executive 7.5 inch 10.0 inch pagedimen /A3 11.69 inch 16.5 inch pagedimen /A4 8.26 inch 11.69 inch pagedimen /A4Small 7.47 inch 10.85 inch pagedimen /B4 10.125 inch 14.33 inch pagedimen /B5 7.16 inch 10.125 inch pagedimen end } bind def /papersize { papersizedict begin /Letter {lettertray letter} def /LetterSmall {lettertray lettersmall} def /Tabloid {11x17tray 11x17} def /Ledger {ledgertray ledger} def /Legal {legaltray legal} def /Statement {statementtray statement} def /Executive {executivetray executive} def /A3 {a3tray a3} def /A4 {a4tray a4} def /A4Small {a4tray a4small} def /B4 {b4tray b4} def /B5 {b5tray b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end statusdict begin stopped end } bind def /manualpapersize { papersizedict begin /Letter {letter} def /LetterSmall {lettersmall} def /Tabloid {11x17} def /Ledger {ledger} def /Legal {legal} def /Statement {statement} def /Executive {executive} def /A3 {a3} def /A4 {a4} def /A4Small {a4small} def /B4 {b4} def /B5 {b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end stopped } bind def /desperatepapersize { statusdict /setpageparams known { paperwidth paperheight 0 1 statusdict begin {setpageparams} stopped end } {true} ifelse } bind def /DiacriticEncoding [ /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute /Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis /atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis /iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve /ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex /udieresis /dagger /.notdef /cent /sterling /section /bullet /paragraph /germandbls /registered /copyright /trademark /acute /dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef /yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown /exclamdown /logicalnot /.notdef /florin /.notdef /.notdef /guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde /Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright /quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis /fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl /periodcentered /quotesinglbase /quotedblbase /perthousand /Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute /Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve /Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron /breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron ] def /ReEncode { dup length dict begin { 1 index /FID ne {def} {pop pop} ifelse } forall 0 eq {/Encoding DiacriticEncoding def} if currentdict end } bind def FMPColor { /BEGINBITMAPCOLOR { BITMAPCOLOR} def /BEGINBITMAPCOLORc { BITMAPCOLORc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUECOLOR } def /BEGINBITMAPTRUECOLORc { BITMAPTRUECOLORc } def } { /BEGINBITMAPCOLOR { BITMAPGRAY} def /BEGINBITMAPCOLORc { BITMAPGRAYc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUEGRAY } def /BEGINBITMAPTRUECOLORc { BITMAPTRUEGRAYc } def } ifelse /K { FMPrintAllColorsAsBlack { dup 1 eq 2 index 1 eq and 3 index 1 eq and not {7 {pop} repeat 0 0 0 1 0 0 0} if } if FrameCurColors astore pop combineColor } bind def /graymode true def /bwidth FMLOCAL /bpside FMLOCAL /bstring FMLOCAL /onbits FMLOCAL /offbits FMLOCAL /xindex FMLOCAL /yindex FMLOCAL /x FMLOCAL /y FMLOCAL /setPatternMode { FMLevel1 { /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def freq sangle landscape {90 add} if {/y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def bstring yindex bwidth mul xindex 8 idiv add get 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if {/onbits onbits 1 add def 1} {/offbits offbits 1 add def 0} ifelse } setscreen offbits offbits onbits add div FrameNegative {1.0 exch sub} if /FrameCurGray exch def } { pop pop dup patCache exch known { patCache exch get } { dup patDict /bstring 3 -1 roll put patDict 9 PatFreq screenIndex get div dup matrix scale makepattern dup patCache 4 -1 roll 3 -1 roll put } ifelse /FrameCurGray 0 def /FrameCurPat exch def } ifelse /graymode false def combineColor } bind def /setGrayScaleMode { graymode not { /graymode true def FMLevel1 { setCurrentScreen } if } if /FrameCurGray exch def combineColor } bind def /normalize { transform round exch round exch itransform } bind def /dnormalize { dtransform round exch round exch idtransform } bind def /lnormalize { 0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop } bind def /H { lnormalize setlinewidth } bind def /Z { setlinecap } bind def /PFill { graymode FMLevel1 or not { gsave 1 setgray eofill grestore } if } bind def /PStroke { graymode FMLevel1 or not { gsave 1 setgray stroke grestore } if stroke } bind def /fillvals FMLOCAL /X { fillvals exch get dup type /stringtype eq {8 1 setPatternMode} {setGrayScaleMode} ifelse } bind def /V { PFill gsave eofill grestore } bind def /Vclip { clip } bind def /Vstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /N { PStroke } bind def /Nclip { strokepath clip newpath } bind def /Nstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /M {newpath moveto} bind def /E {lineto} bind def /D {curveto} bind def /O {closepath} bind def /n FMLOCAL /L { /n exch def newpath normalize moveto 2 1 n {pop normalize lineto} for } bind def /Y { L closepath } bind def /x1 FMLOCAL /x2 FMLOCAL /y1 FMLOCAL /y2 FMLOCAL /R { /y2 exch def /x2 exch def /y1 exch def /x1 exch def x1 y1 x2 y1 x2 y2 x1 y2 4 Y } bind def /rad FMLOCAL /rarc {rad arcto } bind def /RR { /rad exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def mark newpath { x1 y1 rad add moveto x1 y2 x2 y2 rarc x2 y2 x2 y1 rarc x2 y1 x1 y1 rarc x1 y1 x1 y2 rarc closepath } stopped {x1 y1 x2 y2 R} if cleartomark } bind def /RRR { /rad exch def normalize /y4 exch def /x4 exch def normalize /y3 exch def /x3 exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def newpath normalize moveto mark { x2 y2 x3 y3 rarc x3 y3 x4 y4 rarc x4 y4 x1 y1 rarc x1 y1 x2 y2 rarc closepath } stopped {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if cleartomark } bind def /C { grestore gsave R clip setCurrentScreen } bind def /CP { grestore gsave Y clip setCurrentScreen } bind def /FMpointsize FMLOCAL /F { FMfonts exch get FMpointsize scalefont setfont } bind def /Q { /FMpointsize exch def F } bind def /T { moveto show } bind def /RF { rotate 0 ne {-1 1 scale} if } bind def /TF { gsave moveto RF show grestore } bind def /P { moveto 0 32 3 2 roll widthshow } bind def /PF { gsave moveto RF 0 32 3 2 roll widthshow grestore } bind def /S { moveto 0 exch ashow } bind def /SF { gsave moveto RF 0 exch ashow grestore } bind def /B { moveto 0 32 4 2 roll 0 exch awidthshow } bind def /BF { gsave moveto RF 0 32 4 2 roll 0 exch awidthshow grestore } bind def /G { gsave newpath normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /Gstrk { savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /Gclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GG { gsave newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /GGclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GGstrk { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /A { gsave savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /Aclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /Astrk { Gstrk } bind def /AA { gsave savematrix newpath 3 index 2 div add exch 4 index 2 div sub exch normalize 3 index 2 div sub exch 4 index 2 div add exch translate rotate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /AAclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /AAstrk { GGstrk } bind def /x FMLOCAL /y FMLOCAL /w FMLOCAL /h FMLOCAL /xx FMLOCAL /yy FMLOCAL /ww FMLOCAL /hh FMLOCAL /FMsaveobject FMLOCAL /FMoptop FMLOCAL /FMdicttop FMLOCAL /BEGINPRINTCODE { /FMdicttop countdictstack 1 add def /FMoptop count 7 sub def /FMsaveobject save def userdict begin /showpage {} def FMNORMALIZEGRAPHICS 3 index neg 3 index neg translate } bind def /ENDPRINTCODE { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMsaveobject restore } bind def /gn { 0 { 46 mul cf read pop 32 sub dup 46 lt {exit} if 46 sub add } loop add } bind def /str FMLOCAL /cfs { /str sl string def 0 1 sl 1 sub {str exch val put} for str def } bind def /ic [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 {0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx} {10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx} {19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12} {13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh} {4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh} {13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl} {7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl} {0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl} {10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl} ] def /sl FMLOCAL /val FMLOCAL /ws FMLOCAL /im FMLOCAL /bs FMLOCAL /cs FMLOCAL /len FMLOCAL /pos FMLOCAL /ms { /sl exch def /val 255 def /ws cfs /im cfs /val 0 def /bs cfs /cs cfs } bind def 400 ms /ip { is 0 cf cs readline pop { ic exch get exec add } forall pop } bind def /rip { bis ris copy pop is 0 cf cs readline pop { ic exch get exec add } forall pop pop ris gis copy pop dup is exch cf cs readline pop { ic exch get exec add } forall pop pop gis bis copy pop dup add is exch cf cs readline pop { ic exch get exec add } forall pop } bind def /wh { /len exch def /pos exch def ws 0 len getinterval im pos len getinterval copy pop pos len } bind def /bl { /len exch def /pos exch def bs 0 len getinterval im pos len getinterval copy pop pos len } bind def /s1 1 string def /fl { /len exch def /pos exch def /val cf s1 readhexstring pop 0 get def pos 1 pos len add 1 sub {im exch val put} for pos len } bind def /hx { 3 copy getinterval cf exch readhexstring pop pop } bind def /h FMLOCAL /w FMLOCAL /d FMLOCAL /lb FMLOCAL /bitmapsave FMLOCAL /is FMLOCAL /cf FMLOCAL /wbytes { dup dup 24 eq { pop pop 3 mul } { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse } bind def /BEGINBITMAPBWc { 1 {} COMMONBITMAPc } bind def /BEGINBITMAPGRAYc { 8 {} COMMONBITMAPc } bind def /BEGINBITMAP2BITc { 2 {} COMMONBITMAPc } bind def /COMMONBITMAPc { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def r /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} image bitmapsave restore grestore } bind def /BEGINBITMAPBW { 1 {} COMMONBITMAP } bind def /BEGINBITMAPGRAY { 8 {} COMMONBITMAP } bind def /BEGINBITMAP2BIT { 2 {} COMMONBITMAP } bind def /COMMONBITMAP { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def r /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} image bitmapsave restore grestore } bind def /ngrayt 256 array def /nredt 256 array def /nbluet 256 array def /ngreent 256 array def /gryt FMLOCAL /blut FMLOCAL /grnt FMLOCAL /redt FMLOCAL /indx FMLOCAL /cynu FMLOCAL /magu FMLOCAL /yelu FMLOCAL /k FMLOCAL /u FMLOCAL FMLevel1 { /colorsetup { currentcolortransfer /gryt exch def /blut exch def /grnt exch def /redt exch def 0 1 255 { /indx exch def /cynu 1 red indx get 255 div sub def /magu 1 green indx get 255 div sub def /yelu 1 blue indx get 255 div sub def /k cynu magu min yelu min def /u k currentundercolorremoval exec def % /u 0 def nredt indx 1 0 cynu u sub max sub redt exec put ngreent indx 1 0 magu u sub max sub grnt exec put nbluet indx 1 0 yelu u sub max sub blut exec put ngrayt indx 1 k currentblackgeneration exec sub gryt exec put } for {255 mul cvi nredt exch get} {255 mul cvi ngreent exch get} {255 mul cvi nbluet exch get} {255 mul cvi ngrayt exch get} setcolortransfer {pop 0} setundercolorremoval {} setblackgeneration } bind def } { /colorSetup2 { [ /Indexed /DeviceRGB 255 {dup red exch get 255 div exch dup green exch get 255 div exch blue exch get 255 div} ] setcolorspace } bind def } ifelse /tran FMLOCAL /fakecolorsetup { /tran 256 string def 0 1 255 {/indx exch def tran indx red indx get 77 mul green indx get 151 mul blue indx get 28 mul add add 256 idiv put} for currenttransfer {255 mul cvi tran exch get 255.0 div} exch concatprocs settransfer } bind def /BITMAPCOLOR { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def FMLevel1 { colorsetup /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} {is} {is} true 3 colorimage } { colorSetup2 /is w d wbytes string def /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {cf is readhexstring pop} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPCOLORc { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def FMLevel1 { colorsetup /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} {is} {is} true 3 colorimage } { colorSetup2 /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {ip} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPTRUECOLORc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris} {gis} {bis} true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUECOLOR { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop } { cf gis readhexstring pop } { cf bis readhexstring pop } true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUEGRAYc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris gis bis w gray} image bitmapsave restore grestore } bind def /ww FMLOCAL /r FMLOCAL /g FMLOCAL /b FMLOCAL /i FMLOCAL /gray { /ww exch def /b exch def /g exch def /r exch def 0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul b i get .114 mul add add r i 3 -1 roll floor cvi put } for r } bind def /BITMAPTRUEGRAY { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop cf gis readhexstring pop cf bis readhexstring pop w gray} image bitmapsave restore grestore } bind def /BITMAPGRAY { 8 {fakecolorsetup} COMMONBITMAP } bind def /BITMAPGRAYc { 8 {fakecolorsetup} COMMONBITMAPc } bind def /ENDBITMAP { } bind def end /ALDsave FMLOCAL /ALDmatrix matrix def ALDmatrix currentmatrix pop /StartALD { /ALDsave save def savematrix ALDmatrix setmatrix } bind def /InALD { restorematrix } bind def /DoneALD { ALDsave restore } bind def /I { setdash } bind def /J { [] 0 setdash } bind def %%EndProlog %%BeginSetup (4.0) FMVERSION 1 1 0 0 612 792 0 1 33 FMDOCUMENT 0 0 /Times-Bold FMFONTDEFINE 1 0 /Times-Roman FMFONTDEFINE 2 0 /Times-Italic FMFONTDEFINE 3 0 /Helvetica FMFONTDEFINE 4 0 /Helvetica-Bold FMFONTDEFINE 5 0 /Courier FMFONTDEFINE 6 0 /Courier-Bold FMFONTDEFINE 7 0 /Helvetica-Oblique FMFONTDEFINE 32 FMFILLS 0 0 FMFILL 1 0.1 FMFILL 2 0.3 FMFILL 3 0.5 FMFILL 4 0.7 FMFILL 5 0.9 FMFILL 6 0.97 FMFILL 7 1 FMFILL 8 <0f1e3c78f0e1c387> FMFILL 9 <0f87c3e1f0783c1e> FMFILL 10 FMFILL 11 FMFILL 12 <8142241818244281> FMFILL 13 <03060c183060c081> FMFILL 14 <8040201008040201> FMFILL 16 1 FMFILL 17 0.9 FMFILL 18 0.7 FMFILL 19 0.5 FMFILL 20 0.3 FMFILL 21 0.1 FMFILL 22 0.03 FMFILL 23 0 FMFILL 24 FMFILL 25 FMFILL 26 <3333333333333333> FMFILL 27 <0000ffff0000ffff> FMFILL 28 <7ebddbe7e7dbbd7e> FMFILL 29 FMFILL 30 <7fbfdfeff7fbfdfe> FMFILL %%EndSetup %%Page: "1" 1 %%BeginPaperSize: Letter %%EndPaperSize 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K J 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 628.57 553.55 720 R V 0 14 Q 0 X (Tuning Compiler Optimizations for Simultaneous Multithreading) 109.43 686.67 T 1 12 Q (Jack L. Lo, Susan J. Eggers, Henry M. Levy, Sujay S. Parekh, and Dean M. Tullsen*) 101.72 660 T 58.5 536.26 292.38 627.83 R 7 X V 0 X (Dept. of Computer Science and Engineering) 69.13 619.83 T (Box 352350) 145.94 605.83 T (University of Washington) 113.11 591.83 T (Seattle, WA 98195-2350) 115.61 577.83 T 1 11 Q ({jlo, sparekh, eggers, levy}@cs.washington.edu) 69.47 564.5 T 319.5 536.38 553.5 628.12 R 7 X V 1 12 Q 0 X (*Dept. of Computer Science and Engineering) 327.19 620.12 T (University of California, San Diego) 350.68 606.12 T (9500 Gilman Drive) 389.84 592.12 T (La Jolla, CA 92093-0114) 375.5 578.12 T 1 11 Q (tullsen@cs.ucsd.edu) 391.41 564.79 T 58.5 181.83 292.5 535.55 R 7 X V 0 F 0 X (Abstract) 155.04 528.21 T 2 10 Q 1.9 (Compiler optimizations ar) 76.5 505.88 P 1.9 (e often driven by speci\336c) 185.49 505.88 P 0.42 (assumptions about the underlying ar) 58.5 493.88 P 0.42 (chitectur) 206.49 493.88 P 0.42 (e and imple-) 241.67 493.88 P 0.9 (mentation of the tar) 58.5 481.88 P 0.9 (get machine. For example, when tar-) 139.99 481.88 P 0.1 (geting shar) 58.5 469.88 P 0.1 (ed-memory multipr) 103.51 469.88 P 0.1 (ocessors, parallel pr) 180.17 469.88 P 0.1 (ograms) 262.5 469.88 P 1.86 (ar) 58.5 457.88 P 1.86 (e compiled to minimize sharing, in or) 67.02 457.88 P 1.86 (der to decr) 227.51 457.88 P 1.86 (ease) 274.73 457.88 P (high-cost, inter) 58.5 445.88 T (-pr) 119.41 445.88 T (ocessor communication.) 131.26 445.88 T -0.11 (This paper r) 76.5 433.88 P -0.11 (eexamines several compiler optimizations) 125.36 433.88 P 2.13 (in the context of simultaneous multithr) 58.5 421.88 P 2.13 (eading \050SMT\051, a) 222.96 421.88 P 0.45 (pr) 58.5 409.88 P 0.45 (ocessor ar) 67.02 409.88 P 0.45 (chitectur) 109.04 409.88 P 0.45 (e that issues instructions fr) 144.22 409.88 P 0.45 (om multi-) 253.44 409.88 P 2.94 (ple thr) 58.5 397.88 P 2.94 (eads to the functional units each cycle. Unlike) 87.46 397.88 P 0.58 (shar) 58.5 385.88 P 0.58 (ed-memory multipr) 75.91 385.88 P 0.58 (ocessors, SMT pr) 153.05 385.88 P 0.58 (ovides and bene-) 223.57 385.88 P 1.83 (\336ts fr) 58.5 373.88 P 1.83 (om \336ne-grained sharing of pr) 80.8 373.88 P 1.83 (ocessor and memory) 206.08 373.88 P 4.55 (system r) 58.5 361.88 P 4.55 (esour) 95.73 361.88 P 4.55 (ces; unlike curr) 117.58 361.88 P 4.55 (ent unipr) 189.06 361.88 P 4.55 (ocessors, SMT) 229.62 361.88 P 2.6 (exposes and bene\336ts fr) 58.5 349.88 P 2.6 (om inter) 156.76 349.88 P 2.6 (-thr) 192.78 349.88 P 2.6 (ead instruction-level) 207.41 349.88 P 2.45 (parallelism when hiding latencies. Ther) 58.5 337.88 P 2.45 (efor) 227.09 337.88 P 2.45 (e, optimiza-) 242.83 337.88 P -0.08 (tions that ar) 58.5 325.88 P -0.08 (e appr) 106.88 325.88 P -0.08 (opriate for these conventional machines) 132.26 325.88 P 0.74 (may be inappr) 58.5 313.88 P 0.74 (opriate for SMT) 117.39 313.88 P 0.74 (. W) 182.59 313.88 P 0.74 (e r) 195.74 313.88 P 0.74 (evisit thr) 206.94 313.88 P 0.74 (ee optimiza-) 242.6 313.88 P 3.36 (tions in this light: loop-iteration scheduling, softwar) 58.5 301.88 P 3.36 (e) 288.06 301.88 P 1.62 (speculative execution, and loop tiling. Our r) 58.5 289.88 P 1.62 (esults show) 245.04 289.88 P -0.1 (that all thr) 58.5 277.88 P -0.1 (ee optimizations should be applied differ) 100.71 277.88 P -0.1 (ently in) 262.88 277.88 P 0.02 (the context of SMT ar) 58.5 265.88 P 0.02 (chitectur) 144.85 265.88 P 0.02 (es: thr) 180.04 265.88 P 0.02 (eads should be paral-) 205.51 265.88 P 2.27 (lelized with a cyclic, rather than a blocked algorithm;) 58.5 253.88 P -0.2 (non-loop pr) 58.5 241.88 P -0.2 (ograms should not be softwar) 105.43 241.88 P -0.2 (e speculated, and) 223.18 241.88 P 0.27 (compilers no longer need to be concerned about pr) 58.5 229.88 P 0.27 (ecisely) 265.29 229.88 P 1.06 (sizing tiles to match cache sizes. By following these new) 58.5 217.88 P 0.15 (guidelines, compilers can generate code that impr) 58.5 205.88 P 0.15 (oves the) 259.86 205.88 P (performance of pr) 58.5 193.88 T (ograms executing on SMT machines.) 130.9 193.88 T 319.5 81 553.5 535.31 R 7 X V 0 12 Q 0 X (1) 319.5 527.31 T (Introduction) 337.5 527.31 T 1 10 Q 5.7 (Compiler optimizations are typically driven by) 337.5 509.14 P 3.2 (specific assumptions about the underlying architecture) 319.5 497.64 P 1.33 (and implementation of the target machine. For example,) 319.5 486.14 P 5.53 (compilers schedule long-latency operations early to) 319.5 474.64 P 2.08 (minimize critical paths, order instructions based on the) 319.5 463.14 P 1.13 (processor\325s issue slot restrictions to maximize functional) 319.5 451.64 P 1.29 (unit utilization, and allocate frequently used variables to) 319.5 440.14 P 2.35 (registers to benefit from their fast access times. When) 319.5 428.64 P 4.31 (new processing paradigms change these architectural) 319.5 417.14 P 4.64 (assumptions, however, we must reevaluate machine-) 319.5 405.64 P 1.97 (dependent compiler optimizations in order to maximize) 319.5 394.14 P (performance on the new machines.) 319.5 382.64 T 5.99 (Simultaneous multithreading \050SMT\051 [32][31][21]) 337.5 370.99 P 4.58 ([13] is a multithreaded processor design that alters) 319.5 359.34 P 3.97 (several architectural assumptions on which compilers) 319.5 347.84 P 7.15 (have traditionally relied. On an SMT processor,) 319.5 336.34 P 4.9 (instructions from multiple threads can issue to the) 319.5 324.84 P 2.9 (functional units each cycle. To take advantage of the) 319.5 313.34 P 5.8 (simultaneous thread-issue capability, most processor) 319.5 301.84 P 5.3 (resources and all memory subsystem resources are) 319.5 290.34 P 5.16 (dynamically shared among the threads. This single) 319.5 278.84 P 0.44 (feature is responsible for performance gains of almost 2X) 319.5 267.34 P 4.66 (over wide-issue superscalars and roughly 60% over) 319.5 255.84 P 4.8 (single-chip, shared memory multiprocessors on both) 319.5 244.34 P 4.12 (multi-programmed \050SPEC92, SPECint95\051 and parallel) 319.5 232.84 P 2.13 (\050SPLASH-2, SPECfp95\051 workloads; SMT achieves this) 319.5 221.34 P 2.75 (improvement while limiting the slowdown of a single) 319.5 209.84 P (executing thread to under 2% [13].) 319.5 198.18 T 9.97 (Simultaneous multithreading presents to the) 337.5 186.68 P 1.01 (compiler a different model for hiding operation latencies) 319.5 175.18 P 0.4 (and sharing code and data. Operation latencies are hidden) 319.5 163.68 P 2.48 (by instructions from) 319.5 152.18 P 2 F 2.48 (all) 410.55 152.18 P 1 F 2.48 ( executing threads, not just by) 421.11 152.18 P 2.41 (those in the thread with the long-latency operation. In) 319.5 140.68 P 9.96 (addition, multi-thread instruction issue increases) 319.5 129.18 P 1.41 (instruction-level parallelism \050ILP\051 to levels much higher) 319.5 117.68 P 1.5 (than can be sustained with a single thread. Both factors) 319.5 106.18 P 4.76 (suggest reconsidering uniprocessor optimizations that) 319.5 94.68 P 58.33 79.5 294.17 180.33 R 7 X V 3 9 Q 0 X 2.89 (Copyright 1997 IEEE. Published in the Proceedings of) 58.33 174.33 P 0.68 (Micro-30, December 1-3, 1997 in Research Triangle Park,) 58.33 165.33 P 0.97 (North Carolina. Personal use of this material is permitted.) 58.33 156.33 P 1.79 (However, permission to reprint/republish this material for) 58.33 147.33 P 2.25 (advertising or promotional purposes or for creating new) 58.33 138.33 P 1.97 (collective works for resale or redistribution to servers or) 58.33 129.33 P 1.25 (lists, or to reuse any copyrighted component of this work) 58.33 120.33 P 0.97 (in other works, must be obtained from the IEEE. Contact:) 58.33 111.33 P 3.79 (Manager, Copyrights and Permissions / IEEE Service) 58.33 102.33 P 0.47 (Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ) 58.33 93.33 P (08855-1331, USA. Telephone: + Intl. 908-562-3966.) 58.33 84.33 T 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "1" 1 %%Page: "2" 2 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 0.48 (hide latencies and expose ILP at the expense of increased) 58.5 713.33 P 3.71 (dynamic instruction counts: on an SMT the latency-) 58.5 701.83 P 4.98 (hiding benefits may not be needed, and the extra) 58.5 690.33 P 1.41 (instructions may consume resources that could be better) 58.5 678.83 P (utilized by instructions in concurrent threads.) 58.5 667.33 T 0.66 (Because multiple threads reside within a single SMT) 76.5 655.83 P 0.4 (processor, they can cheaply share common data and incur) 58.5 644.33 P 1.28 (no penalty from false sharing. In fact, they benefit from) 58.5 632.83 P 4.33 (cross-thread spatial locality. This calls into question) 58.5 621.33 P 6.9 (compiler-driven parallelization techniques, originally) 58.5 609.83 P 2.74 (developed for distributed-memory multiprocessors, that) 58.5 598.33 P 2.2 (partition data to physically distributed threads to avoid) 58.5 586.83 P 0.85 (communication and coherence costs. On an SMT, it may) 58.5 575.33 P 0.85 (be beneficial to parallelize programs so that they process) 58.5 563.83 P (the same or contiguous data.) 58.5 552.33 T 7.49 (This paper investigates the extent to which) 76.5 540.83 P 3.08 (simultaneous multithreading affects the use of several) 58.5 529.33 P 2.89 (compiler optimizations. In particular, we examine one) 58.5 517.83 P 0.2 (parallel technique \050loop-iteration scheduling for compiler-) 58.5 506.33 P 0.76 (parallelized applications\051 and two optimizations that hide) 58.5 494.83 P 11.98 (memory latencies and expose instruction-level) 58.5 483.33 P 4.64 (parallelism \050software speculative execution and loop) 58.5 471.83 P 0.7 (tiling\051. Our results prescribe a different usage of all three) 58.5 460.33 P (optimizations when compiling for an SMT processor.) 58.5 448.83 T 1.65 (We found that, while blocked loop scheduling may) 76.5 437.33 P 3.91 (be useful for distributing data in distributed-memory) 58.5 425.83 P 5.58 (multiprocessors, cyclic iteration scheduling is more) 58.5 414.33 P 1.69 (appropriate for an SMT architecture, because it reduces) 58.5 402.83 P 2.64 (the TLB footprint of parallel applications. Since SMT) 58.5 391.33 P 1.59 (threads run on a single processor and share its memory) 58.5 379.83 P 1.31 (hierarchy, data can be shared among threads to improve) 58.5 368.33 P (locality in memory pages.) 58.5 356.83 T 1.15 (Software speculative execution may incur additional) 76.5 345.33 P 5.7 (instruction overhead. On a conventional wide-issue) 58.5 333.83 P 0.81 (superscalar, instruction throughput is usually low enough) 58.5 322.33 P 7.3 (that these additional instructions simply consume) 58.5 310.83 P 1.41 (resources that would otherwise go unused. However, on) 58.5 299.33 P 4.31 (an SMT processor, where simultaneous, multi-thread) 58.5 287.83 P 1.68 (instruction issue increases throughput to roughly 6.2 on) 58.5 276.33 P 1.47 (an 8-wide processor, software speculative execution can) 58.5 264.83 P 4.84 (degrade performance, particularly for non-loop-based) 58.5 253.33 P (applications.) 58.5 241.83 T 0.81 (Simultaneous multithreading also impacts loop tiling) 76.5 230.33 P 0.54 (techniques and tile size selection. SMT processors are far) 58.5 218.83 P 1.47 (less sensitive to variations in tile size than conventional) 58.5 207.33 P 4.8 (processors, which must find an appropriate balance) 58.5 195.83 P 2.84 (between large tiles with low instruction overhead and) 58.5 184.33 P 1.87 (small tiles with better cache reuse and higher hit rates.) 58.5 172.83 P 2.43 (SMT processors eliminate this performance sweet spot) 58.5 161.33 P 4.3 (by hiding the extra misses of larger tiles with the) 58.5 149.83 P 11.56 (additional thread-level parallelism provided by) 58.5 138.33 P 5.17 (multithreading. Tiled loops on an SMT should be) 58.5 126.83 P 0.69 (decomposed so that all threads compute on the same tile,) 58.5 115.33 P 1.38 (rather than creating a separate tile for each thread, as is) 58.5 103.83 P 2.55 (done on multiprocessors. Tiling in this way raises the) 58.5 92.33 P 319.5 81 553.5 720 R 7 X V 0 X 2.64 (performance of SMT processors with moderately-sized) 319.5 713.33 P (memory subsystems to that of more aggressive designs.) 319.5 701.83 T 1 (The remainder of this paper is organized as follows.) 337.5 690.33 P 4.81 (Section 2 provides a brief description of an SMT) 319.5 678.83 P 5.42 (processor. Section 3 discusses in more detail two) 319.5 667.33 P 10.53 (architectural assumptions that are affected by) 319.5 655.83 P 2.86 (simultaneous multithreading and their ramifications on) 319.5 644.33 P 1.77 (compiler-directed loop distribution, software speculative) 319.5 632.83 P 5.45 (execution, and loop tiling. Section 4 presents our) 319.5 621.33 P 0.44 (experimental methodology. Sections 5 through 7 examine) 319.5 609.83 P 10.25 (each of the compiler optimizations, providing) 319.5 598.33 P 4.98 (experimental results and analysis. Section 8 briefly) 319.5 586.83 P 1.69 (discusses other compiler issues raised by SMT. Related) 319.5 575.33 P (work appears in Section 9, and we conclude in Section 10.) 319.5 563.83 T 0 12 Q (2) 319.5 543 T (The microarchitecture of a simultaneous) 337.5 543 T (multithreading processor) 319.5 529 T 1 10 Q 4.76 (Our SMT design is an eight-wide, out-of-order) 337.5 508.33 P 0.42 (processor with hardware contexts for eight threads. Every) 319.5 496.83 P 1.89 (cycle the instruction fetch unit fetches four instructions) 319.5 485.33 P 2.8 (from each of two threads. The fetch unit favors high) 319.5 473.83 P 2.56 (throughput threads, fetching from the two threads that) 319.5 462.33 P 0.47 (have the fewest instructions waiting to be executed. After) 319.5 450.83 P 4.1 (fetching, instructions are decoded, their registers are) 319.5 439.33 P 1.38 (renamed, and they are inserted into either the integer or) 319.5 427.83 P 2.66 (floating point instruction queues. When their operands) 319.5 416.33 P 0.97 (become available, instructions \050from any thread\051 issue to) 319.5 404.83 P 2.7 (the functional units for execution. Finally, instructions) 319.5 393.33 P (retire in per-thread program order.) 319.5 381.83 T 8.04 (Little of the microarchitecture needs to be) 337.5 370.33 P 9.64 (redesigned to enable or optimize simultaneous) 319.5 358.83 P 0.57 (multithreading -- most components are an integral part of) 319.5 347.33 P 5.89 (any conventional, dynamically-scheduled superscalar.) 319.5 335.83 P 3.49 (The major exceptions are the larger register file \05032) 319.5 324.33 P 4.24 (architectural registers per thread, plus 100 renaming) 319.5 312.83 P 0.42 (registers\051, two additional pipeline stages for accessing the) 319.5 301.33 P 6.21 (registers \050one each for reading and writing\051, the) 319.5 289.83 P 2.48 (instruction fetch scheme mentioned above, and several) 319.5 278.33 P 0.86 (per-thread mechanisms, such as program counters, return) 319.5 266.83 P 2.31 (stacks, retirement and trap logic, and identifiers in the) 319.5 255.33 P 0.82 (TLB and branch target buffer. Notably missing from this) 319.5 243.83 P 6.51 (list is special per-thread hardware for scheduling) 319.5 232.33 P 7.8 (instructions onto the functional units. Instruction) 319.5 220.83 P 3.35 (scheduling is done as in a conventional, out-of-order) 319.5 209.33 P 2.43 (superscalar: instructions are issued after their operands) 319.5 197.83 P 2.48 (have been calculated or loaded from memory, without) 319.5 186.33 P 0.78 (regard to thread; the renaming hardware eliminates inter-) 319.5 174.83 P 0.58 (thread register name conflicts by mapping thread-specific) 319.5 163.33 P 5.75 (architectural registers onto the processor\325s physical) 319.5 151.83 P (registers \050see [31] for more details\051.) 319.5 140.18 T 2.95 (All large hardware data structures \050caches, TLBs,) 337.5 128.68 P 4.59 (and branch prediction tables\051 are shared among all) 319.5 117.18 P 4.79 (threads. The additional cross-thread conflicts in the) 319.5 105.68 P 1.73 (caches and branch prediction hardware are absorbed by) 319.5 94.18 P 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "2" 2 %%Page: "3" 3 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 2.25 (SMT\325s enhanced latency-hiding capabilities [21], while) 58.5 713.18 P 3.72 (TLB interference can be addressed with a technique) 58.5 701.68 P (described in Section 5.) 58.5 690.18 T 0 12 Q (3) 58.5 669.35 T (Rethinking compiler optimizations) 76.5 669.35 T 1 10 Q 4.49 (As explained above, simultaneous multithreading) 76.5 651.18 P 1.9 (relies on a novel feature for attaining greater processor) 58.5 639.68 P 2.34 (performance: the coupling of multithreading and wide-) 58.5 628.18 P 7.86 (instruction issue by scheduling instructions from) 58.5 616.68 P 3.53 (different threads in the same cycle. The new design) 58.5 605.18 P 6.59 (prompts us to revisit compiler optimizations that) 58.5 593.68 P 4.2 (automatically parallelize loops for enhanced memory) 58.5 582.18 P 3.91 (performance and/or increase ILP. In this section we) 58.5 570.68 P 2.8 (discuss two factors affected by SMT\325s unique design,) 58.5 559.18 P 4.9 (data sharing among threads and the availability of) 58.5 547.68 P 6.13 (instruction issue slots, in light of three compiler) 58.5 536.18 P (optimizations they affect.) 58.5 524.68 T 0 11 Q (Inter-thread data sharing) 58.5 504.51 T 1 10 Q 10.62 (Conventional parallelization techniques target) 76.5 486.18 P 8.25 (multiprocessors, in which threads are physically) 58.5 474.68 P 2.57 (distributed on different processors. To minimize cache) 58.5 463.18 P 1.92 (coherence and inter-processor communication overhead,) 58.5 451.68 P 5.48 (data and loop distribution techniques partition and) 58.5 440.18 P 3.21 (distribute data to match the physical topology of the) 58.5 428.68 P 8.57 (multiprocessor. Parallelizing compilers attempt to) 58.5 417.18 P 0.86 (decompose applications to minimize synchronization and) 58.5 405.68 P 7.97 (communication between loops. Typically, this is) 58.5 394.18 P 2.89 (achieved by allocating a disjoint set of data for each) 58.5 382.68 P 7.66 (processor, so that they can work independently) 58.5 371.18 P ([34][10][7].) 58.5 359.53 T 1.03 (In contrast, on an SMT, multiple threads execute on) 76.5 348.03 P 1.57 (the same processor, affecting performance in two ways.) 58.5 336.53 P 1.51 (First, both real and false inter-thread data sharing entail) 58.5 325.03 P 2 F 0.66 (local) 58.5 313.53 P 1 F 0.66 ( memory accesses and incur no coherence overhead,) 78.5 313.53 P 5.21 (because of SMT\325s shared L1 cache. Consequently,) 58.5 302.03 P 0.92 (sharing, and even false sharing, is beneficial. Second, by) 58.5 290.53 P 2 (sharing data among threads, the memory footprint of a) 58.5 279.03 P 2.72 (parallel application can be reduced, resulting in better) 58.5 267.53 P 2.69 (cache and TLB behavior. Both factors suggest a loop) 58.5 256.03 P 3.36 (distribution policy that clusters, rather then separates,) 58.5 244.53 P (data for multiple threads.) 58.5 233.03 T 0 11 Q 3.34 (Latency-hiding capabilities and the availability) 58.5 212.86 P (of instruction issue slots) 58.5 201.86 T 1 10 Q 1.54 (On most workloads, wide-issue processors typically) 76.5 183.53 P 2.94 (cannot sustain high instruction throughput, because of) 58.5 172.03 P 0.44 (low instruction-level parallelism in their single, executing) 58.5 160.53 P 7.64 (thread. Compiler optimizations, such as software) 58.5 149.03 P 0.68 (speculative execution and loop tiling \050or blocking\051, try to) 58.5 137.53 P 0.89 (increase ILP \050by hiding or reducing instruction latencies,) 58.5 126.03 P 1.03 (respectively\051, but often with the side effect of increasing) 58.5 114.53 P 3.68 (the dynamic instruction count. Despite the additional) 58.5 103.03 P 6.3 (instructions, the optimizations are often profitable,) 58.5 91.53 P 319.5 81 553.5 720 R 7 X V 0 X 1.97 (because the instruction overhead can be accommodated) 319.5 713.33 P (in otherwise idle functional units.) 319.5 701.83 T 4.8 (Because it can issue instructions from multiple) 337.5 690.33 P 1.51 (threads, an SMT processor has fewer empty issue slots;) 319.5 678.83 P 2.96 (in fact, sustained instruction throughput can be rather) 319.5 667.33 P 3.11 (high, roughly 2 times greater than on a conventional) 319.5 655.83 P 1.27 (superscalar [13]. Furthermore, SMT does a better job of) 319.5 644.18 P 1.14 (hiding latencies than single-threaded processors, because) 319.5 632.68 P 2.33 (it uses instructions from one thread to mask delays in) 319.5 621.18 P 3.73 (another. In such an environment, the aforementioned) 319.5 609.68 P 2.6 (optimizations may be less useful, or even detrimental,) 319.5 598.18 P 2.62 (because the overhead instructions compete with useful) 319.5 586.68 P 5.49 (instructions for hardware resources. SMT, with its) 319.5 575.18 P 10.41 (simultaneous multithreading capabilities, naturally) 319.5 563.68 P 1.22 (tolerates high latencies) 319.5 552.18 P 2 F 1.22 (without) 417.32 552.18 P 1 F 1.22 ( the additional instruction) 447.33 552.18 P (overhead.) 319.5 540.68 T 0 12 Q (4) 319.5 519.85 T (Methodology) 337.5 519.85 T 1 10 Q 3.54 (Before examining the compiler optimizations, we) 337.5 501.68 P 2.08 (describe the methodology used in the experiments. We) 319.5 490.18 P 0.57 (chose applications from the SPEC 92 [12], SPEC 95 [30]) 319.5 478.53 P 3.27 (and SPLASH-2 [35] benchmark suites \050Table 2\051. All) 319.5 466.87 P 5.76 (programs were compiled with the Multiflow trace) 319.5 455.37 P 1.49 (scheduling compiler [22] to generate DEC Alpha object) 319.5 443.72 P 2.05 (files. Multiflow was chosen, because it generates high-) 319.5 432.22 P 0.66 (quality code, using aggressive static scheduling for wide-) 319.5 420.72 P 10.52 (issue, loop unrolling, and other ILP-exposing) 319.5 409.22 P 1.62 (optimizations. Implicitly-parallel applications \050the SPEC) 319.5 397.72 P 0.85 (suites\051 were first parallelized by the SUIF compiler [15];) 319.5 386.07 P (SUIF\325s C output was then fed to Multiflow.) 319.5 374.57 T 2.02 (A blocked loop distribution policy commonly used) 337.5 363.07 P 2.8 (for multiprocessor execution has been implemented in) 319.5 351.57 P 2.12 (SUIF; because we used applications compiled with the) 319.5 340.07 P 1.07 (latest version of SUIF [5], but did not have access to its) 319.5 328.41 P 7.7 (source, we implemented an alternative algorithm) 319.5 316.91 P 0.51 (\050described in Section 5\051 by hand. SUIF also finds tileable) 319.5 305.41 P 5.79 (loops, determines appropriate multiprocessor-oriented) 319.5 293.91 P 2.49 (tile sizes for particular data sets and caches, and then) 319.5 282.41 P 3.16 (generates tiled code; we experimented with other tile) 319.5 270.91 P 3.59 (sizes with manual coding. Speculative execution was) 319.5 259.41 P 1.41 (enabled/disabled by modifying the Multiflow compiler\325s) 319.5 247.91 P 8.7 (machine description file, which specifies which) 319.5 236.41 P 3.55 (instructions can be moved speculatively by the trace) 319.5 224.91 P 7.47 (scheduler. We experimented with both statically-) 319.5 213.41 P 6.19 (generated and profile-driven traces; for the latter,) 319.5 201.91 P 0.76 (profiling information was generated by instrumenting the) 319.5 190.41 P 3.47 (applications and then executing them with a training) 319.5 178.91 P 3.87 (input data set that differs from the set used during) 319.5 167.41 P (simulation.) 319.5 155.91 T 1.06 (The object files generated by Multiflow were linked) 337.5 144.41 P 3.01 (with our versions of the ANL [4] and SUIF runtime) 319.5 132.76 P 5.26 (libraries to create executables. Our SMT simulator) 319.5 121.26 P 1.88 (processes these unmodified Alpha executables and uses) 319.5 109.76 P 0.91 (emulation-based, instruction-level simulation to model in) 319.5 98.26 P 1.45 (detail the processor pipelines, hardware support for out-) 319.5 86.76 P 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "3" 3 %%Page: "4" 4 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 3.64 (of-order execution, and the entire memory hierarchy,) 58.5 125.33 P 3.83 (including TLB usage. The memory hierarchy in our) 58.5 113.83 P 3.01 (processor consists of two levels of cache, with sizes,) 58.5 102.33 P 3.82 (latencies, and bandwidth characteristics, as shown in) 58.5 90.83 P 1 6 Q (Application) 69.08 696 T (Data set) 160.9 696 T (Instruc-) 239.46 710 T (tions) 242.95 703 T -0.67 (simulated) 237.12 696 P (L) 267.54 703 T (D) 267.29 696 T (S) 277.87 710 T (S) 277.87 703 T (E) 277.7 696 T (T) 287.87 696 T 1 7 Q (S) 61.5 679.33 T (P) 61.5 672.33 T (E) 61.5 665.33 T (C) 61.5 658.33 T (f) 61.5 651.33 T (p) 61.5 644.33 T (9) 61.5 637.33 T (5) 61.5 630.33 T (applu) 72.14 679.33 T (33x33x33 array) 111 679.33 T (, 2 iterations) 154.67 679.33 T (272 M) 239.55 679.33 T (X) 267.29 679.33 T (X) 277.45 679.33 T (hydro2d) 72.14 664.33 T (2 iterations) 111 664.33 T (474 M) 239.55 664.33 T (X) 267.29 664.33 T (X) 277.45 664.33 T (mgrid) 72.14 649.33 T (64x64x64 grid, 1 iteration) 111 649.33 T (3.2 B) 241.2 649.33 T (X) 267.29 649.33 T (X) 277.45 649.33 T (su2cor) 72.14 634.33 T (16x16x16x16, vector len. 4K, 2 iterations) 111 634.33 T (5.4 B) 241.2 634.33 T (X) 267.29 634.33 T (X) 277.45 634.33 T (swim) 72.14 619.33 T (512x512 grid, 10 iterations) 111 619.33 T (419 M) 239.55 619.33 T (X) 267.29 619.33 T (X) 277.45 619.33 T (tomcatv) 72.14 604.33 T (513x513 array) 111 604.33 T (, 5 iterations) 151.17 604.33 T (189 M) 239.55 604.33 T (X) 267.29 604.33 T (X) 277.45 604.33 T (S) 61.5 589.33 T (P) 61.5 582.33 T (L) 61.5 575.33 T (A) 61.5 568.33 T (S) 61.5 561.33 T (H) 61.5 554.33 T (-) 61.5 547.33 T (2) 61.5 540.33 T (f) 72.14 589.33 T (ft) 74.35 589.33 T (64K data points) 111 589.33 T (32 M) 241.3 589.33 T (X) 277.45 589.33 T (LU) 72.14 574.33 T (512x512 matrix) 111 574.33 T (431 M) 239.55 574.33 T (X) 277.45 574.33 T (radix) 72.14 559.33 T -0.09 (256K keys, radix 1K, 512K max key value) 111 559.33 P (6 M) 243.05 559.33 T (X) 277.45 559.33 T (water) 72.14 544.33 T (-) 87.55 544.33 T (nsquared) 72.14 536.33 T (512 molecules, 3 timesteps) 111 544.33 T (870 M) 239.55 544.33 T (X) 277.45 544.33 T (water) 72.14 521.33 T (-) 87.55 521.33 T (spatial) 72.14 513.33 T (512 molecules, 3 timesteps) 111 521.33 T (784 M) 239.55 521.33 T (X) 277.45 521.33 T (S) 61.5 498.33 T (P) 61.5 491.33 T (E) 61.5 484.33 T (C) 61.5 477.33 T (i) 61.5 470.33 T (n) 61.5 463.33 T (t) 61.5 456.33 T (9) 61.5 449.33 T (5) 61.5 442.33 T (compress) 72.14 498.33 T (train input set) 111 498.33 T (64 M) 241.3 498.33 T (X) 277.45 498.33 T (go) 72.14 483.33 T (train input set, 2stone9) 111 483.33 T (700 M) 239.55 483.33 T (X) 277.45 483.33 T (li) 72.14 468.33 T (train input set) 111 468.33 T (258 M) 239.55 468.33 T (X) 277.45 468.33 T (m88ksim) 72.14 453.33 T (test input set, dhrystone) 111 453.33 T (164 M) 239.55 453.33 T (X) 277.45 453.33 T (perl) 72.14 438.33 T (train input set, scrabble) 111 438.33 T (56 M) 241.3 438.33 T (X) 277.45 438.33 T (S) 61.5 423.33 T (P) 61.5 415.33 T (E) 61.5 407.33 T (C) 61.5 399.33 T (9) 61.5 391.33 T (2) 61.5 383.33 T (mxm from) 72.14 423.33 T (NASA7) 72.14 415.33 T (matrix multiply of 256x128 and 128x64) 111 423.33 T (arrays) 111 415.33 T (29 M) 241.3 423.33 T (X) 287.62 423.33 T (gmt from) 72.14 400.33 T (NASA7) 72.14 392.33 T (500x500 Gaussian elimination) 111 400.33 T (354 M) 239.55 400.33 T (X) 287.62 400.33 T (adi) 72.14 368.33 T (integration) 72.14 360.33 T (1Kx1K stencil computation for solving) 111 368.33 T (partial dif) 111 360.33 T (ferential equations) 138.29 360.33 T (16 M) 241.3 368.33 T (X) 287.62 368.33 T 4 10 Q 1.08 (T) 58.5 341.33 P 1.08 (able 1: Benchmarks.) 63.87 341.33 P 3 8 Q 0.86 ( The last three columns identify the) 163.28 341.33 P 0.17 (studies in which the applications are used. \050LD = loop distribution,) 58.5 330.67 P (SSE = software speculative execution, and T = tiling\051.) 58.5 320.67 T 1 7 Q (L1 I-cache) 147.97 303.33 T (L1 D-cache) 198.39 303.33 T (L2 cache) 253.88 303.33 T (Cache size \050bytes\051) 64.4 288.33 T (128K / 32K) 146.5 288.33 T (128K / 32K) 198.29 288.33 T (16 M / 2 M) 250.66 288.33 T (Line size \050bytes\051) 64.4 275.33 T (64) 159.53 275.33 T (64) 211.32 275.33 T (64) 263.11 275.33 T (Banks) 64.4 262.33 T (8) 161.28 262.33 T (8) 213.07 262.33 T (1) 264.86 262.33 T (T) 64.4 249.33 T (ransfer time/bank) 68.43 249.33 T (1 cycle) 153.02 249.33 T (1 cycle) 204.81 249.33 T (4 cycles) 255.23 249.33 T (Accesses/cycle) 64.4 236.33 T (2) 161.28 236.33 T (4) 213.07 236.33 T (1/4) 262.13 236.33 T (Cache \336ll time \050cycles\051) 64.4 223.33 T (2) 161.28 223.33 T (2) 213.07 223.33 T (8) 264.86 223.33 T (Latency to next level) 64.4 210.33 T (10 / 18) 153.3 210.33 T (10 / 18) 205.09 210.33 T (68) 263.11 210.33 T 4 10 Q 0.76 (T) 58.5 194.33 P 0.76 (able 2: Memory hierarchy parameters.) 63.87 194.33 P 3 8 Q 0.61 (When there) 250.54 194.33 P 0.42 (is a choice of values, the \336rst \050the more aggressive\051 represents a) 58.5 183.67 P 1.64 (forecast for an SMT implementation roughly three years in the) 58.5 173.67 P 1.67 (future and is used in all experiments. The second set is more) 58.5 163.67 P 1.86 (typical of today\325) 58.5 153.67 P 1.86 (s memory subsystems and is used to emulate) 117.21 153.67 P (larger data set sizes [29]; it is used in the tiling studies only) 58.5 143.17 T (.) 266 143.17 T 58.5 719.75 58.5 354.25 2 L V 0.5 H 0 Z N 69.14 689 69.14 353.75 2 L V N 108 720.25 108 689 2 L V N 106.75 687 106.75 354.25 2 L V N 109.25 687 109.25 354.25 2 L V N 233.29 720.25 233.29 353.75 2 L V N 264.29 720.25 264.29 353.75 2 L V N 274.45 720.25 274.45 353.75 2 L V N 284.62 720.25 284.62 353.75 2 L V N 294.79 719.75 294.79 354.25 2 L V N 58.25 720 295.04 720 2 L V N 58.25 688 295.04 688 2 L V 2 H N 68.89 673 295.04 673 2 L V 0.5 H N 68.89 658 295.04 658 2 L V N 68.89 643 295.04 643 2 L V N 68.89 628 295.04 628 2 L V N 68.89 613 295.04 613 2 L V N 58.75 599.25 294.54 599.25 2 L V N 58.75 596.75 294.54 596.75 2 L V N 68.89 583 295.04 583 2 L V N 68.89 568 295.04 568 2 L V N 68.89 553 295.04 553 2 L V N 68.89 530 295.04 530 2 L V N 58.75 508.25 294.54 508.25 2 L V N 58.75 505.75 294.54 505.75 2 L V N 68.89 492 295.04 492 2 L V N 68.89 477 295.04 477 2 L V N 68.89 462 295.04 462 2 L V N 68.89 447 295.04 447 2 L V N 58.75 433.25 294.54 433.25 2 L V N 58.75 430.75 294.54 430.75 2 L V N 68.89 409 295.04 409 2 L V N 58.75 378.25 294.54 378.25 2 L V N 58.75 375.75 294.54 375.75 2 L V N 58.25 354 295.04 354 2 L V N 58.4 312.75 58.4 205.25 2 L V N 135.88 312.75 135.88 205.25 2 L V N 138.38 312.75 138.38 205.25 2 L V N 188.92 313.25 188.92 204.75 2 L V N 240.71 313.25 240.71 204.75 2 L V N 292.5 312.75 292.5 205.25 2 L V N 58.15 313 292.75 313 2 L V N 58.15 296 292.75 296 2 L V 2 H N 58.15 283 292.75 283 2 L V 0.5 H N 58.15 270 292.75 270 2 L V N 58.15 257 292.75 257 2 L V N 58.15 244 292.75 244 2 L V N 58.15 231 292.75 231 2 L V N 58.15 218 292.75 218 2 L V N 58.15 205 292.75 205 2 L V N 319.5 81 553.5 720 R 7 X V 1 10 Q 0 X 1.41 (Table 2. We model the cache behavior, as well as bank) 319.5 713.33 P 2.24 (and bus contention. Two TLB sizes were used for the) 319.5 701.83 P 2.95 (loop distribution experiments \05048 and 128 entries\051, to) 319.5 690.33 P 5.3 (illustrate how the performance of loop distribution) 319.5 678.83 P 4.84 (policies is sensitive to TLB size. The larger TLB) 319.5 667.33 P 0.46 (represents a probable configuration for a \050future\051 general-) 319.5 655.83 P 1.22 (purpose SMT; the smaller is more appropriate for a less) 319.5 644.33 P 4.38 (aggressive design, such as an SMT multimedia co-) 319.5 632.83 P 1.13 (processor, where page sizes are typically in the range of) 319.5 621.33 P 3.28 (2-8MB. For both TLB sizes, misses require two full) 319.5 609.83 P 3.4 (memory accesses, incurring a 160 cycle penalty. For) 319.5 598.33 P 4.79 (branch prediction, we use a McFarling-style hybrid) 319.5 586.83 P 1.46 (predictor with a 256-entry, 4-way set-associative branch) 319.5 575.33 P 3.74 (target buffer, and an 8K entry selector that chooses) 319.5 563.83 P 0.79 (between a global history predictor \05013 history bits\051 and a) 319.5 552.33 P 5.06 (local predictor \050a 2K-entry local history table that) 319.5 540.83 P (indexes into a 4K-entry, 2-bit local prediction table\051 [24].) 319.5 529.18 T 1 (Because of the length of the simulations, we limited) 337.5 517.68 P 0.45 (our detailed simulation results to the parallel computation) 319.5 506.18 P 4.03 (portion of the applications \050the norm for simulating) 319.5 494.68 P 1.21 (parallel applications\051. For the initialization phases of the) 319.5 483.18 P 2.13 (applications, we used a fast simulation mode that only) 319.5 471.68 P 1.68 (simulates the caches, so that they were warm when the) 319.5 460.18 P 1.45 (main computation phases were reached. We then turned) 319.5 448.68 P (on the detailed simulation model.) 319.5 437.18 T 0 12 Q (5) 319.5 416.35 T (Loop distribution) 337.5 416.35 T 1 10 Q 2.38 (To reduce communication and coherence overhead) 337.5 398.18 P 7.82 (in distributed-memory multiprocessors, parallelizing) 319.5 386.68 P 0.54 (compilers employ a) 319.5 375.18 P 2 F 0.54 (blocked) 402.49 375.18 P 1 F 0.54 ( loop parallelization policy to) 433.59 375.18 P 7.58 (distribute iterations across processors. A blocked) 319.5 363.68 P 2.86 (distribution assigns each thread \050processor\051 continuous) 319.5 352.18 P 0.68 (array data and iterations that manipulate them \050Figure 1\051.) 319.5 340.68 P 6.32 (Figure 2 presents SMT speedups for applications) 319.5 329.18 P 2.04 (parallelized using a blocked distribution with two TLB) 319.5 317.68 P 0.97 (sizes. Good speedups are obtained for many applications) 319.5 306.18 P 0.49 (\050as the number of threads is increased\051, but in the smaller) 319.5 294.68 P 3.96 (TLB the performance of several programs \050hydro2d,) 319.5 283.18 P 0.79 (swim, and tomcatv\051 degrades with 6 or 8 threads. The 8-) 319.5 271.68 P 5.26 (thread case is particularly important, because most) 319.5 260.18 P 0.78 (applications will be parallelized to exploit all 8 hardware) 319.5 248.68 P 6.44 (contexts in an SMT. Analysis of the simulation) 319.5 237.18 P 1.81 (bottleneck metrics indicated that the slowdown was the) 319.5 225.68 P 1.6 (result of thrashing in the data TLB, as indicated by the) 319.5 214.18 P (TLB miss rates of Table 3.) 319.5 202.68 T 3.53 (The TLB thrashing is a direct result of blocked) 337.5 191.18 P 1.44 (partitioning, which increases the total working set of an) 319.5 179.68 P 0.75 (application because threads work on disjoint data sets. In) 319.5 168.18 P 2.86 (the most severe cases, each of the 8 threads requires) 319.5 156.68 P 1.61 (many TLB entries, because loops stride through several) 319.5 145.18 P 3.17 (large arrays at once. Since the primary data sets are) 319.5 133.68 P 1.21 (usually larger than a typical 8KB page size, at least one) 319.5 122.18 P (TLB entry is required for each array.) 319.5 110.68 T 1.56 (The swim benchmark from SPECfp95 illustrates an) 337.5 99.18 P 0.36 (extreme example. In one loop, 9 large arrays are accessed) 319.5 87.68 P 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "4" 4 %%Page: "5" 5 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 498.33 R V 1 10 Q 0 X 5.39 (on each iteration of the loop. When the loop is) 58.5 327.67 P 2.24 (parallelized using a blocked distribution, the data TLB) 58.5 316.17 P 3.53 (footprint is 9 arrays * 8 threads = 72 TLB entries,) 58.5 304.67 P 2.07 (excluding the entries required for other data. With any) 58.5 293.17 P 2.2 (TLB size less than 72, significant thrashing will occur) 58.5 281.67 P (and the parallelization is not profitable.) 58.5 270.17 T 0.94 (The lesson here is that the TLB is a shared resource) 76.5 258.67 P 0.82 (that needs to be managed efficiently in an SMT. At least) 58.5 247.17 P 0.79 (three approaches can be considered: \0501\051 using fewer than) 58.5 235.67 P 0.68 (8 threads when parallelizing, \0502\051 increasing the data TLB) 58.5 224.17 P (size, or \0503\051 parallelizing loops differently.) 58.5 212.67 T 1.93 (The first alternative unnecessarily limits the use of) 76.5 201.17 P 1.69 (the thread hardware contexts, and neither exploits SMT) 58.5 189.67 P 0.75 (nor the parallel applications to their fullest potential. The) 58.5 178.17 P 0.82 (second choice incurs a cost in access time and hardware,) 58.5 166.67 P 0.72 (although with increasing chip densities, future processors) 58.5 155.17 P 1.74 (may be able to accommodate.) 58.5 141 P 1 8 Q 1.39 (1) 184.6 145 P 1 10 Q 1.74 ( Even with larger TLBs,) 188.6 141 P 58.5 115 292.5 130 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 67.5 128 211.5 128 2 L 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 1 8 Q 0 X 0 0 0 1 0 0 0 K 0.71 (1.) 58.5 109.67 P 0.71 (W) 64.5 105.67 P 0.71 (e found that 64 entries did not solve the problem. However) 71.41 105.67 P 0.71 (, a 128-) 266.86 105.67 P 2.38 (entry data TLB avoids TLB thrashing, and as Figure 2b indicates,) 58.5 95.67 P (achieves speedups, at least for the SPECfp95 data sets.) 58.5 85.67 T 1 7 Q (Application) 91.46 471.67 T (Number of threads) 172.65 486.67 T (1) 141.1 469.67 T (2) 167.84 469.67 T (4) 195.86 469.67 T (6) 223.89 469.67 T (8) 251.91 469.67 T (applu) 89.86 456.67 T (0.7%) 136.99 456.67 T (0.9%) 165.02 456.67 T (1.0%) 193.04 456.67 T (0.9%) 221.07 456.67 T (1.0%) 249.09 456.67 T 0 F (hydr) 89.86 443.67 T (o2d) 104.13 443.67 T 1 F (0.1%) 136.99 443.67 T (0.1%) 165.02 443.67 T (0.1%) 193.04 443.67 T (0.7%) 221.07 443.67 T 0 F (6.3%) 247.92 443.67 T 1 F (mgrid) 89.86 430.67 T (0.0%) 136.99 430.67 T (0.0%) 165.02 430.67 T (0.0%) 193.04 430.67 T (0.0%) 221.07 430.67 T (0.1%) 249.09 430.67 T (su2cor) 89.86 417.67 T (0.1%) 136.99 417.67 T (5.2%) 165.02 417.67 T (7.7%) 193.04 417.67 T (6.2%) 221.07 417.67 T (5.5%) 249.09 417.67 T 0 F (swim) 89.86 404.67 T 1 F (0.2%) 136.99 404.67 T (0.2%) 165.02 404.67 T (0.2%) 193.04 404.67 T 0 F (27.6%) 216.4 404.67 T (49.4%) 244.42 404.67 T (tomcatv) 89.86 391.67 T 1 F (0.1%) 136.99 391.67 T (0.1%) 165.02 391.67 T (0.1%) 193.04 391.67 T (2.0%) 221.07 391.67 T 0 F (10.7%) 244.42 391.67 T 4 10 Q 2.77 (T) 56.66 373.67 P 2.77 (able 3: TLB miss rates.) 62.03 373.67 P 3 8 Q 2.22 (Miss rates are shown for a) 187.6 373.67 P 1.9 (blocked distribution and a 48-entry data TLB. The bold entries) 56.66 363 P 1.69 (correspond to decreased performance \050see Figure 2\051 when the) 56.66 353 P (number of threads was increased.) 56.66 343 T 85.86 498.08 85.86 386.58 2 L V 0.5 H 0 Z N 128.87 498.08 128.87 386.58 2 L V N 131.37 498.08 131.37 386.58 2 L V N 155.57 481.58 155.57 386.08 2 L V N 183.6 481.58 183.6 386.08 2 L V N 211.62 481.58 211.62 386.08 2 L V N 239.65 481.58 239.65 386.08 2 L V N 267.67 498.08 267.67 386.58 2 L V N 85.61 498.33 267.92 498.33 2 L V N 131.62 481.33 267.92 481.33 2 L V N 85.61 464.33 267.92 464.33 2 L V 2 H N 85.61 451.33 267.92 451.33 2 L V 0.5 H N 85.61 438.33 267.92 438.33 2 L V N 85.61 425.33 267.92 425.33 2 L V N 85.61 412.33 267.92 412.33 2 L V N 85.61 399.33 267.92 399.33 2 L V N 85.61 386.33 267.92 386.33 2 L V N 319.5 81 553.5 720 R 7 X V 1 10 Q 0 X 0.38 (however, it is desirable to reduce the TLB footprint on an) 319.5 462.33 P 0.41 (SMT. A true SMT workload would be multiprogrammed:) 319.5 450.83 P 1.09 (for example, multiple parallel applications could execute) 319.5 439.33 P 7.48 (together, comprising more threads than hardware) 319.5 427.83 P 4.23 (contexts. The thread scheduler could schedule all 8) 319.5 416.33 P 3.43 (threads for the first parallel application, then context) 319.5 404.83 P 2.21 (switch to run the second, and later switch back to the) 319.5 393.33 P 0.02 (first. In this type of environment it would be performance-) 319.5 381.83 P 0.36 (wise to minimize the data TLB footprint required by each) 319.5 370.33 P 3.49 (application. \050As an example, the TLB footprint of a) 319.5 358.83 P 5.3 (multiprogrammed workload consisting of swim and) 319.5 347.33 P (hydro2d would be greater than 128 entries.\051) 319.5 335.83 T 1.93 (The third and most desirable solution relies on the) 337.5 324.33 P 1.86 (compiler to reduce the data TLB footprint. Rather than) 319.5 312.83 P 1.92 (distributing loop iterations in a blocked organization, it) 319.5 301.33 P 1.47 (could use a) 319.5 289.83 P 2 F 1.47 (cyclic) 371.39 289.83 P 1 F 1.47 ( distribution to cluster the accesses of) 394.71 289.83 P 7.29 (multiple threads onto fewer pages. \050With cyclic) 319.5 278.33 P 1.02 (partitioning, swim would consume 9 rather than 72 TLB) 319.5 266.83 P 1.27 (entries\051. Cyclic partitioning also requires less instruction) 319.5 255.33 P 2.8 (overhead in calculating array partition bounds, a non-) 319.5 243.83 P 8.41 (negligible, although much less important factor.) 319.5 232.33 P 1.65 (\050Compare the blocked and cyclic loop distribution code) 319.5 220.83 P (and data in Figure 1.\051) 319.5 209.33 T 0.89 (Figure 3 illustrates the speedups attained by a cyclic) 337.5 197.83 P 4.38 (distribution over blocked, and Table 4 contains the) 319.5 186.33 P 1.16 (corresponding changes in data TLB miss rates. With the) 319.5 174.83 P 2.66 (48-entry TLB all applications did better with a cyclic) 319.5 163.33 P 0.4 (distribution. In most cases the significant decrease in data) 319.5 151.83 P 1.19 (TLB misses, coupled with the long 160 cycle TLB miss) 319.5 140.33 P 3.55 (penalty, was the major factor. Cyclic increased TLB) 319.5 128.83 P 1.24 (conflicts in tomcatv at 2 and 4 threads, but, because the) 319.5 117.33 P 6.77 (number of misses was so low, overall program) 319.5 105.83 P 0.48 (performance did not suffer. At 6 and 8 threads, tomcatv\325s) 319.5 94.33 P 58.14 469 553.5 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.85 504.33 360.31 720 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 2 Z 0 X N 65.84 684 238.14 716.75 R 7 X V 4 7 Q 0 X (a\051 original loop) 65.84 712.08 T 5 6 Q (for \050j = 1; j < n; j++\051) 74.84 704.75 T (for \050i = 0; i < m; i++\051) 83.84 697.75 T (u1[j][i] = u2[j][i] +) 92.84 690.75 T (t1/8.0 * Z[j][i]) 172.04 690.75 T 63.5 600.17 244.81 683.33 R 7 X V 4 7 Q 0 X (b\051 blocked parallelization) 63.5 678.67 T 6 6 Q (for \050j = max\050n * myid / numthreads + 1, 1\051;) 72.5 671.33 T ( j < min\050n * \050myid+1\051 / numthreads + 1, n\051;) 72.5 664.33 T ( j++\051) 72.5 657.33 T 5 F (for \050i = 0; i < m; i++\051) 81.5 650.33 T (u1[j][i] = u2[j][i] + t1/8.0 * Z[j][i]) 90.5 643.33 T 4 F (c\051 cyclic parallelization) 63.5 629.33 T 6 F (for \050j = myid + 1; j < n; j += numthreads\051) 72.5 622.33 T 5 F (for \050i = 0; i < m; i++\051) 81.5 615.33 T (u1[j][i] = u2[j][i] + t1/8.0 * Z[j][i]) 90.5 608.33 T 64.58 505.83 357.11 597.09 R 7 X V 4 10 Q 0 X (Figure 1: A blocked and cyclic loop distribution example.) 64.58 590.42 T 3 8 Q 2.51 (The code for an example loop nest is shown in a\051. When using a blocked) 64.58 579.76 P 0.71 (distribution, the code is structured as in b\051. The cyclic version is shown in c\051. On) 64.58 569.76 P 1.36 (the right, d\051 and e\051 illustrate which portions of the array are accessed by each) 64.58 559.76 P 0.62 (thread for the two policies. \050For clarity) 64.58 549.76 P 0.62 (, we assume 4 threads\051. Assume that each) 201.11 549.76 P 0.37 (row of the array is 2KB \050512 double precision elements\051. With blocked distribution) 64.58 539.76 P 2.51 (\050d\051, each thread accesses a dif) 64.58 529.76 P 2.51 (ferent 8KB page in memory) 186.35 529.76 P 2.51 (. With cyclic \050e\051,) 293.15 529.76 P 1.95 (however) 64.58 519.76 P 1.95 (, the loop is decomposed in a manner that allows all four threads to) 94.37 519.76 P (access a single 8KB page at the same time, thus reducing the TLB footprint.) 64.58 509.76 T 248.97 597.33 358.14 717.58 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 248.97 597.33 358.14 717.58 R 7 X 0 0 0 1 0 0 0 K V 260.77 691.53 301.27 701.65 R 1 X V 260.77 681.4 301.27 691.53 R 3 X V 260.77 671.28 301.27 681.4 R 4 X V 260.77 661.15 301.27 671.28 R 7 X V 301.27 642.58 301.27 640.05 260.77 640.05 260.77 642.58 4 Y 2 X V 301.27 640.05 301.27 637.52 260.77 637.52 260.77 640.05 4 Y 4 X V 301.27 637.52 301.27 634.99 260.77 634.99 260.77 637.52 4 Y 5 X V 301.27 634.99 301.27 632.46 260.77 632.46 260.77 634.99 4 Y 7 X V 301.27 632.46 301.27 629.92 260.77 629.92 260.77 632.46 4 Y 2 X V 301.27 629.92 301.27 627.39 260.77 627.39 260.77 629.92 4 Y 4 X V 301.27 627.39 301.27 624.86 260.77 624.86 260.77 627.39 4 Y 5 X V 301.27 624.86 301.27 622.33 260.77 622.33 260.77 624.86 4 Y 7 X V 301.27 622.33 301.27 619.8 260.77 619.8 260.77 622.33 4 Y 2 X V 301.27 619.8 301.27 617.27 260.77 617.27 260.77 619.8 4 Y 4 X V 301.27 617.27 301.27 614.74 260.77 614.74 260.77 617.27 4 Y 5 X V 301.27 614.74 301.27 612.21 260.77 612.21 260.77 614.74 4 Y 7 X V 301.27 612.21 301.27 609.68 260.77 609.68 260.77 612.21 4 Y 2 X V 301.27 609.68 301.27 607.15 260.77 607.15 260.77 609.68 4 Y 4 X V 301.27 607.15 301.27 604.61 260.77 604.61 260.77 607.15 4 Y 5 X V 301.27 604.61 301.27 602.08 260.77 602.08 260.77 604.61 4 Y 7 X V 5 7 Q 0 X (i dimension) 265.44 705.92 T (i dimension) 265.44 646.96 T (j dimension) 0 -270 255.13 661.75 TF (j dimension) 0 -270 255.13 602.68 TF 301.27 642.58 301.27 640.05 260.77 640.05 260.77 642.58 4 Y 0.5 H 0 Z N 301.27 640.05 301.27 637.52 260.77 637.52 260.77 640.05 4 Y N 301.27 637.52 301.27 634.99 260.77 634.99 260.77 637.52 4 Y N 301.27 634.99 301.27 632.46 260.77 632.46 260.77 634.99 4 Y N 301.27 632.46 301.27 629.92 260.77 629.92 260.77 632.46 4 Y N 301.27 629.92 301.27 627.39 260.77 627.39 260.77 629.92 4 Y N 301.27 627.39 301.27 624.86 260.77 624.86 260.77 627.39 4 Y N 301.27 624.86 301.27 622.33 260.77 622.33 260.77 624.86 4 Y N 301.27 622.33 301.27 619.8 260.77 619.8 260.77 622.33 4 Y N 301.27 619.8 301.27 617.27 260.77 617.27 260.77 619.8 4 Y N 301.27 617.27 301.27 614.74 260.77 614.74 260.77 617.27 4 Y N 301.27 614.74 301.27 612.21 260.77 612.21 260.77 614.74 4 Y N 301.27 612.21 301.27 609.68 260.77 609.68 260.77 612.21 4 Y N 301.27 609.68 301.27 607.15 260.77 607.15 260.77 609.68 4 Y N 301.27 607.15 301.27 604.61 260.77 604.61 260.77 607.15 4 Y N 301.27 604.61 301.27 602.08 260.77 602.08 260.77 604.61 4 Y N 301.27 642.58 301.27 640.05 260.77 640.05 260.77 642.58 4 Y 1 X V 0 X N 301.27 640.05 301.27 637.52 260.77 637.52 260.77 640.05 4 Y 3 X V 0 X N 301.27 637.52 301.27 634.99 260.77 634.99 260.77 637.52 4 Y 4 X V 0 X N 301.27 634.99 301.27 632.46 260.77 632.46 260.77 634.99 4 Y N 301.27 632.46 301.27 629.93 260.77 629.93 260.77 632.46 4 Y 1 X V 0 X N 301.27 629.93 301.27 627.4 260.77 627.4 260.77 629.93 4 Y 3 X V 0 X N 301.27 627.4 301.27 624.87 260.77 624.87 260.77 627.4 4 Y 4 X V 0 X N 301.27 624.87 301.27 622.33 260.77 622.33 260.77 624.87 4 Y N 301.27 622.34 301.27 619.8 260.77 619.8 260.77 622.34 4 Y 1 X V 0 X N 301.27 619.8 301.27 617.27 260.77 617.27 260.77 619.8 4 Y 3 X V 0 X N 301.27 617.27 301.27 614.74 260.77 614.74 260.77 617.27 4 Y 4 X V 0 X N 301.27 614.74 301.27 612.21 260.77 612.21 260.77 614.74 4 Y N 301.27 612.21 301.27 609.68 260.77 609.68 260.77 612.21 4 Y 1 X V 0 X N 301.27 609.68 301.27 607.15 260.77 607.15 260.77 609.68 4 Y 3 X V 0 X N 301.27 607.15 301.27 604.62 260.77 604.62 260.77 607.15 4 Y 4 X V 0 X N 301.27 604.62 301.27 602.09 260.77 602.09 260.77 604.62 4 Y N 260.77 699.12 301.27 701.65 R 1 X V 0 X N 260.77 696.59 301.27 699.12 R 1 X V 0 X N 260.77 694.06 301.27 696.59 R 1 X V 0 X N 260.77 691.53 301.27 694.06 R 1 X V 0 X N 260.77 689 301.27 691.53 R 3 X V 0 X N 260.77 686.47 301.27 689 R 3 X V 0 X N 260.77 683.93 301.27 686.47 R 3 X V 0 X N 260.77 681.4 301.27 683.93 R 3 X V 0 X N 260.77 678.87 301.27 681.4 R 4 X V 0 X N 260.77 676.34 301.27 678.87 R 4 X V 0 X N 260.77 673.81 301.27 676.34 R 4 X V 0 X N 260.77 671.28 301.27 673.81 R 4 X V 0 X N 260.77 668.75 301.27 671.28 R N 260.77 666.22 301.27 668.75 R N 260.77 663.69 301.27 666.22 R N 260.77 661.15 301.27 663.69 R N 298.74 661.16 301.27 701.65 R N 296.21 661.16 298.74 701.65 R N 293.68 661.16 296.21 701.65 R N 291.15 661.16 293.68 701.65 R N 288.62 661.16 291.15 701.65 R N 286.08 661.16 288.62 701.65 R N 283.55 661.16 286.08 701.65 R N 281.02 661.16 283.56 701.65 R N 278.49 661.16 281.02 701.65 R N 275.96 661.16 278.49 701.65 R N 273.43 661.16 275.96 701.65 R N 270.9 661.16 273.43 701.65 R N 268.37 661.16 270.9 701.65 R N 265.84 661.16 268.37 701.65 R N 263.31 661.16 265.84 701.65 R N 260.77 661.16 263.31 701.65 R N 312.31 678.53 318.13 685.28 R 1 X V 0 X N 312.31 671.78 318.13 678.53 R 3 X V 0 X N 312.31 665.03 318.13 671.78 R 4 X V 0 X N 312.31 658.28 318.13 665.03 R 7 X V 0 X N 3 8 Q (Thread 0) 321.8 680.63 T (Thread 1) 321.8 673.29 T (Thread 2) 321.8 665.95 T (Thread 3) 321.8 658.61 T 4 7 Q (d\051 blocked) 257.71 712.48 T (e\051 cyclic) 257.71 653.41 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.14 469 553.5 720 C 365.58 472.36 553.07 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 365.58 472.36 553.07 720.55 R 7 X 0 0 0 1 0 0 0 K V 4 9 Q 0 X (a\051 48-entry data TLB) 404.64 710.7 T 522.18 599.48 528.55 599.48 528.55 605.55 522.18 605.55 4 Y V 0 H 0 Z 1 X N 3 7 Q 0 X (1) 531.74 600.36 T 522.18 599.48 528.55 599.48 528.55 605.55 522.18 605.55 522.18 599.48 5 L 0.5 H 1 Z N 522.18 593.41 528.55 593.41 528.55 599.48 522.18 599.48 4 Y 2 X V 0 H 0 Z 1 X N 0 X (2) 531.74 594.3 T 522.18 593.41 528.55 593.41 528.55 599.48 522.18 599.48 522.18 593.41 5 L 0.5 H 1 Z N 522.18 587.35 528.55 587.35 528.55 593.41 522.18 593.41 4 Y 4 X V 0 H 0 Z 1 X N 0 X (4) 531.74 588.23 T 522.18 587.35 528.55 587.35 528.55 593.41 522.18 593.41 522.18 587.35 5 L 0.5 H 1 Z N 522.18 581.28 528.55 581.28 528.55 587.35 522.18 587.35 4 Y 6 X V 0 H 0 Z 1 X N 0 X (6) 531.74 582.16 T 522.18 581.28 528.55 581.28 528.55 587.35 522.18 587.35 522.18 581.28 5 L 0.5 H 1 Z N 522.18 575.21 528.55 575.21 528.55 581.28 522.18 581.28 4 Y 0 H 0 Z 1 X N 0 X (8) 531.74 576.09 T 522.18 575.21 528.55 575.21 528.55 581.28 522.18 581.28 522.18 575.21 5 L 0.5 H 1 Z N 371.77 476.57 550.1 496.43 R 7 X V 4 10 Q 0 X 1.55 (Figure 2: Speedups over one thread) 371.77 489.76 P (for blocked parallelization.) 371.77 479.76 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 3 8 Q (Number) 514.68 624.05 T (of) 525.57 616.05 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (threads) 518.9 608.05 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 399.7 644.05 505.54 644.05 2 L N 399.7 644.05 399.7 707.41 2 L N 3 6 Q (applu) 0 -270 407.26 622.55 TF (hydro2d) 0 -270 422.38 615.55 TF (mgrid) 0 -270 437.42 622.23 TF (su2cor) 0 -270 452.61 619.22 TF (swim) 0 -270 467.73 623.56 TF (tomcatv) 0 -270 482.86 616.22 TF (average) 0 -270 497.98 615.55 TF 399.7 644.05 401.35 644.05 2 L N 399.7 654.56 401.35 654.56 2 L N 399.7 665.15 401.35 665.15 2 L N 399.7 675.73 401.35 675.73 2 L N 399.7 686.24 401.35 686.24 2 L N 399.7 696.83 401.35 696.83 2 L N 399.7 707.41 401.35 707.41 2 L N 399.7 644.05 402.58 644.05 2 L N 399.7 665.15 402.58 665.15 2 L N 399.7 686.24 402.58 686.24 2 L N 3 7 Q (0.0) 385.36 641.72 T (1.0) 385.36 662.81 T (2.0) 385.36 683.91 T (3.0) 385.36 705.08 T (Speedup) 0 -270 379.68 661.72 TF 399.7 707.41 402.58 707.41 2 L N 401.71 644.05 401.71 665.15 403.94 665.15 403.94 644.05 401.71 644.05 5 Y V 0 H 0 Z 1 X N 416.83 644.05 416.83 665.15 419.06 665.15 419.06 644.05 416.83 644.05 5 Y 0 X V 1 X N 431.95 644.05 431.95 665.15 434.18 665.15 434.18 644.05 431.95 644.05 5 Y 0 X V 1 X N 447.07 644.05 447.07 665.15 449.3 665.15 449.3 644.05 447.07 644.05 5 Y 0 X V 1 X N 462.19 644.05 462.19 665.15 464.42 665.15 464.42 644.05 462.19 644.05 5 Y 0 X V 1 X N 477.31 644.05 477.31 665.15 479.54 665.15 479.54 644.05 477.31 644.05 5 Y 0 X V 1 X N 492.43 644.05 492.43 665.15 494.66 665.15 494.66 644.05 492.43 644.05 5 Y 0 X V 1 X N 401.71 644.05 401.71 665.15 403.94 665.15 403.94 644.05 401.71 644.05 5 L 0.5 H 1 Z 0 X N 416.83 644.05 416.83 665.15 419.06 665.15 419.06 644.05 416.83 644.05 5 L N 431.95 644.05 431.95 665.15 434.18 665.15 434.18 644.05 431.95 644.05 5 L N 447.07 644.05 447.07 665.15 449.3 665.15 449.3 644.05 447.07 644.05 5 L N 462.19 644.05 462.19 665.15 464.42 665.15 464.42 644.05 462.19 644.05 5 L N 477.31 644.05 477.31 665.15 479.54 665.15 479.54 644.05 477.31 644.05 5 L N 492.43 644.05 492.43 665.15 494.66 665.15 494.66 644.05 492.43 644.05 5 L N 403.94 644.05 403.94 672.78 406.1 672.78 406.1 644.05 403.94 644.05 5 Y 2 X V 0 H 0 Z 1 X N 419.06 644.05 419.06 671.55 421.22 671.55 421.22 644.05 419.06 644.05 5 Y 2 X V 1 X N 434.18 644.05 434.18 684.37 436.34 684.37 436.34 644.05 434.18 644.05 5 Y 2 X V 1 X N 449.3 644.05 449.3 671.7 451.46 671.7 451.46 644.05 449.3 644.05 5 Y 2 X V 1 X N 464.42 644.05 464.42 675.44 466.58 675.44 466.58 644.05 464.42 644.05 5 Y 2 X V 1 X N 479.54 644.05 479.54 677.39 481.7 677.39 481.7 644.05 479.54 644.05 5 Y 2 X V 1 X N 494.66 644.05 494.66 675.51 496.82 675.51 496.82 644.05 494.66 644.05 5 Y 2 X V 1 X N 403.94 644.05 403.94 672.78 406.1 672.78 406.1 644.05 403.94 644.05 5 L 0.5 H 1 Z 0 X N 419.06 644.05 419.06 671.55 421.22 671.55 421.22 644.05 419.06 644.05 5 L N 434.18 644.05 434.18 684.37 436.34 684.37 436.34 644.05 434.18 644.05 5 L N 449.3 644.05 449.3 671.7 451.46 671.7 451.46 644.05 449.3 644.05 5 L N 464.42 644.05 464.42 675.44 466.58 675.44 466.58 644.05 464.42 644.05 5 L N 479.54 644.05 479.54 677.39 481.7 677.39 481.7 644.05 479.54 644.05 5 L N 494.66 644.05 494.66 675.51 496.82 675.51 496.82 644.05 494.66 644.05 5 L N 406.1 644.05 406.1 681.99 408.33 681.99 408.33 644.05 406.1 644.05 5 Y 4 X V 0 H 0 Z 1 X N 421.22 644.05 421.22 679.69 423.45 679.69 423.45 644.05 421.22 644.05 5 Y 4 X V 1 X N 436.34 644.05 436.34 700.86 438.58 700.86 438.58 644.05 436.34 644.05 5 Y 4 X V 1 X N 451.46 644.05 451.46 674.43 453.7 674.43 453.7 644.05 451.46 644.05 5 Y 4 X V 1 X N 466.58 644.05 466.58 681.27 468.82 681.27 468.82 644.05 466.58 644.05 5 Y 4 X V 1 X N 481.7 644.05 481.7 700.79 483.93 700.79 483.93 644.05 481.7 644.05 5 Y 4 X V 1 X N 496.82 644.05 496.82 686.46 499.05 686.46 499.05 644.05 496.82 644.05 5 Y 4 X V 1 X N 406.1 644.05 406.1 681.99 408.33 681.99 408.33 644.05 406.1 644.05 5 L 0.5 H 1 Z 0 X N 421.22 644.05 421.22 679.69 423.45 679.69 423.45 644.05 421.22 644.05 5 L N 436.34 644.05 436.34 700.86 438.58 700.86 438.58 644.05 436.34 644.05 5 L N 451.46 644.05 451.46 674.43 453.7 674.43 453.7 644.05 451.46 644.05 5 L N 466.58 644.05 466.58 681.27 468.82 681.27 468.82 644.05 466.58 644.05 5 L N 481.7 644.05 481.7 700.79 483.93 700.79 483.93 644.05 481.7 644.05 5 L N 496.82 644.05 496.82 686.46 499.05 686.46 499.05 644.05 496.82 644.05 5 L N 408.33 644.05 408.33 688.04 410.49 688.04 410.49 644.05 408.33 644.05 5 Y 6 X V 0 H 0 Z 1 X N 423.45 644.05 423.45 680.27 425.61 680.27 425.61 644.05 423.45 644.05 5 Y 6 X V 1 X N 438.58 644.05 438.58 701.58 440.73 701.58 440.73 644.05 438.58 644.05 5 Y 6 X V 1 X N 453.7 644.05 453.7 675.51 455.86 675.51 455.86 644.05 453.7 644.05 5 Y 6 X V 1 X N 468.82 644.05 468.82 654.56 470.98 654.56 470.98 644.05 468.82 644.05 5 Y 6 X V 1 X N 483.93 644.05 483.93 704.75 486.1 704.75 486.1 644.05 483.93 644.05 5 Y 6 X V 1 X N 499.05 644.05 499.05 684.08 501.21 684.08 501.21 644.05 499.05 644.05 5 Y 6 X V 1 X N 408.33 644.05 408.33 688.04 410.49 688.04 410.49 644.05 408.33 644.05 5 L 0.5 H 1 Z 0 X N 423.45 644.05 423.45 680.27 425.61 680.27 425.61 644.05 423.45 644.05 5 L N 438.58 644.05 438.58 701.58 440.73 701.58 440.73 644.05 438.58 644.05 5 L N 453.7 644.05 453.7 675.51 455.86 675.51 455.86 644.05 453.7 644.05 5 L N 468.82 644.05 468.82 654.56 470.98 654.56 470.98 644.05 468.82 644.05 5 L N 483.93 644.05 483.93 704.75 486.1 704.75 486.1 644.05 483.93 644.05 5 L N 499.05 644.05 499.05 684.08 501.21 684.08 501.21 644.05 499.05 644.05 5 L N 410.49 644.05 410.49 692.22 412.73 692.22 412.73 644.05 410.49 644.05 5 Y 0 H 0 Z 1 X N 425.61 644.05 425.61 673.07 427.85 673.07 427.85 644.05 425.61 644.05 5 Y N 440.73 644.05 440.73 701.65 442.97 701.65 442.97 644.05 440.73 644.05 5 Y N 455.86 644.05 455.86 676.81 458.09 676.81 458.09 644.05 455.86 644.05 5 Y N 470.98 644.05 470.98 653.05 473.21 653.05 473.21 644.05 470.98 644.05 5 Y N 486.1 644.05 486.1 686.31 488.33 686.31 488.33 644.05 486.1 644.05 5 Y N 501.21 644.05 501.21 680.55 503.45 680.55 503.45 644.05 501.21 644.05 5 Y N 410.49 644.05 410.49 692.22 412.73 692.22 412.73 644.05 410.49 644.05 5 L 0.5 H 1 Z 0 X N 425.61 644.05 425.61 673.07 427.85 673.07 427.85 644.05 425.61 644.05 5 L N 440.73 644.05 440.73 701.65 442.97 701.65 442.97 644.05 440.73 644.05 5 L N 455.86 644.05 455.86 676.81 458.09 676.81 458.09 644.05 455.86 644.05 5 L N 470.98 644.05 470.98 653.05 473.21 653.05 473.21 644.05 470.98 644.05 5 L N 486.1 644.05 486.1 686.31 488.33 686.31 488.33 644.05 486.1 644.05 5 L N 501.21 644.05 501.21 680.55 503.45 680.55 503.45 644.05 501.21 644.05 5 L N 4 9 Q (b\051 128-entry data TLB) 404.64 599.52 T 399.7 533.05 505.54 533.05 2 L N 399.7 533.05 399.7 596.41 2 L N 3 6 Q (applu) 0 -270 407.26 511.55 TF (hydro2d) 0 -270 422.38 504.55 TF (mgrid) 0 -270 437.42 511.23 TF (su2cor) 0 -270 452.61 508.22 TF (swim) 0 -270 467.73 512.56 TF (tomcatv) 0 -270 482.86 505.22 TF (average) 0 -270 497.98 504.55 TF 399.7 533.05 401.35 533.05 2 L N 399.7 540.97 401.35 540.97 2 L N 399.7 548.89 401.35 548.89 2 L N 399.7 556.81 401.35 556.81 2 L N 399.7 564.73 401.35 564.73 2 L N 399.7 572.65 401.35 572.65 2 L N 399.7 580.57 401.35 580.57 2 L N 399.7 588.49 401.35 588.49 2 L N 399.7 596.41 401.35 596.41 2 L N 399.7 533.05 402.58 533.05 2 L N 399.7 548.89 402.58 548.89 2 L N 399.7 564.73 402.58 564.73 2 L N 399.7 580.57 402.58 580.57 2 L N 3 7 Q (0.0) 385.36 530.72 T (1.0) 385.36 546.56 T (2.0) 385.36 562.4 T (3.0) 385.36 578.24 T (4.0) 385.36 594.08 T (Speedup) 0 -270 379.68 550.72 TF 399.7 596.41 402.58 596.41 2 L N 401.71 533.05 401.71 548.89 403.94 548.89 403.94 533.05 401.71 533.05 5 Y V 0 H 0 Z 1 X N 416.83 533.05 416.83 548.89 419.06 548.89 419.06 533.05 416.83 533.05 5 Y 0 X V 1 X N 431.95 533.05 431.95 548.89 434.18 548.89 434.18 533.05 431.95 533.05 5 Y 0 X V 1 X N 447.07 533.05 447.07 548.89 449.3 548.89 449.3 533.05 447.07 533.05 5 Y 0 X V 1 X N 462.19 533.05 462.19 548.89 464.42 548.89 464.42 533.05 462.19 533.05 5 Y 0 X V 1 X N 477.31 533.05 477.31 548.89 479.54 548.89 479.54 533.05 477.31 533.05 5 Y 0 X V 1 X N 492.43 533.05 492.43 548.89 494.66 548.89 494.66 533.05 492.43 533.05 5 Y 0 X V 1 X N 401.71 533.05 401.71 548.89 403.94 548.89 403.94 533.05 401.71 533.05 5 L 0.5 H 1 Z 0 X N 416.83 533.05 416.83 548.89 419.06 548.89 419.06 533.05 416.83 533.05 5 L N 431.95 533.05 431.95 548.89 434.18 548.89 434.18 533.05 431.95 533.05 5 L N 447.07 533.05 447.07 548.89 449.3 548.89 449.3 533.05 447.07 533.05 5 L N 462.19 533.05 462.19 548.89 464.42 548.89 464.42 533.05 462.19 533.05 5 L N 477.31 533.05 477.31 548.89 479.54 548.89 479.54 533.05 477.31 533.05 5 L N 492.43 533.05 492.43 548.89 494.66 548.89 494.66 533.05 492.43 533.05 5 L N 403.94 533.05 403.94 553.93 406.1 553.93 406.1 533.05 403.94 533.05 5 Y 2 X V 0 H 0 Z 1 X N 419.06 533.05 419.06 553.64 421.22 553.64 421.22 533.05 419.06 533.05 5 Y 2 X V 1 X N 434.18 533.05 434.18 563.29 436.34 563.29 436.34 533.05 434.18 533.05 5 Y 2 X V 1 X N 449.3 533.05 449.3 558.61 451.46 558.61 451.46 533.05 449.3 533.05 5 Y 2 X V 1 X N 464.42 533.05 464.42 556.59 466.58 556.59 466.58 533.05 464.42 533.05 5 Y 2 X V 1 X N 479.54 533.05 479.54 560.84 481.7 560.84 481.7 533.05 479.54 533.05 5 Y 2 X V 1 X N 494.66 533.05 494.66 557.82 496.82 557.82 496.82 533.05 494.66 533.05 5 Y 2 X V 1 X N 403.94 533.05 403.94 553.93 406.1 553.93 406.1 533.05 403.94 533.05 5 L 0.5 H 1 Z 0 X N 419.06 533.05 419.06 553.64 421.22 553.64 421.22 533.05 419.06 533.05 5 L N 434.18 533.05 434.18 563.29 436.34 563.29 436.34 533.05 434.18 533.05 5 L N 449.3 533.05 449.3 558.61 451.46 558.61 451.46 533.05 449.3 533.05 5 L N 464.42 533.05 464.42 556.59 466.58 556.59 466.58 533.05 464.42 533.05 5 L N 479.54 533.05 479.54 560.84 481.7 560.84 481.7 533.05 479.54 533.05 5 L N 494.66 533.05 494.66 557.82 496.82 557.82 496.82 533.05 494.66 533.05 5 L N 406.1 533.05 406.1 555.95 408.33 555.95 408.33 533.05 406.1 533.05 5 Y 4 X V 0 H 0 Z 1 X N 421.22 533.05 421.22 559.76 423.45 559.76 423.45 533.05 421.22 533.05 5 Y 4 X V 1 X N 436.34 533.05 436.34 576.03 438.58 576.03 438.58 533.05 436.34 533.05 5 Y 4 X V 1 X N 451.46 533.05 451.46 562.57 453.7 562.57 453.7 533.05 451.46 533.05 5 Y 4 X V 1 X N 466.58 533.05 466.58 560.55 468.82 560.55 468.82 533.05 466.58 533.05 5 Y 4 X V 1 X N 481.7 533.05 481.7 575.6 483.93 575.6 483.93 533.05 481.7 533.05 5 Y 4 X V 1 X N 496.82 533.05 496.82 565.09 499.05 565.09 499.05 533.05 496.82 533.05 5 Y 4 X V 1 X N 406.1 533.05 406.1 555.95 408.33 555.95 408.33 533.05 406.1 533.05 5 L 0.5 H 1 Z 0 X N 421.22 533.05 421.22 559.76 423.45 559.76 423.45 533.05 421.22 533.05 5 L N 436.34 533.05 436.34 576.03 438.58 576.03 438.58 533.05 436.34 533.05 5 L N 451.46 533.05 451.46 562.57 453.7 562.57 453.7 533.05 451.46 533.05 5 L N 466.58 533.05 466.58 560.55 468.82 560.55 468.82 533.05 466.58 533.05 5 L N 481.7 533.05 481.7 575.6 483.93 575.6 483.93 533.05 481.7 533.05 5 L N 496.82 533.05 496.82 565.09 499.05 565.09 499.05 533.05 496.82 533.05 5 L N 408.33 533.05 408.33 560.12 410.49 560.12 410.49 533.05 408.33 533.05 5 Y 6 X V 0 H 0 Z 1 X N 423.45 533.05 423.45 562.43 425.61 562.43 425.61 533.05 423.45 533.05 5 Y 6 X V 1 X N 438.58 533.05 438.58 576.32 440.73 576.32 440.73 533.05 438.58 533.05 5 Y 6 X V 1 X N 453.7 533.05 453.7 564.8 455.86 564.8 455.86 533.05 453.7 533.05 5 Y 6 X V 1 X N 468.82 533.05 468.82 560.91 470.98 560.91 470.98 533.05 468.82 533.05 5 Y 6 X V 1 X N 483.93 533.05 483.93 583.31 486.1 583.31 486.1 533.05 483.93 533.05 5 Y 6 X V 1 X N 499.05 533.05 499.05 567.97 501.21 567.97 501.21 533.05 499.05 533.05 5 Y 6 X V 1 X N 408.33 533.05 408.33 560.12 410.49 560.12 410.49 533.05 408.33 533.05 5 L 0.5 H 1 Z 0 X N 423.45 533.05 423.45 562.43 425.61 562.43 425.61 533.05 423.45 533.05 5 L N 438.58 533.05 438.58 576.32 440.73 576.32 440.73 533.05 438.58 533.05 5 L N 453.7 533.05 453.7 564.8 455.86 564.8 455.86 533.05 453.7 533.05 5 L N 468.82 533.05 468.82 560.91 470.98 560.91 470.98 533.05 468.82 533.05 5 L N 483.93 533.05 483.93 583.31 486.1 583.31 486.1 533.05 483.93 533.05 5 L N 499.05 533.05 499.05 567.97 501.21 567.97 501.21 533.05 499.05 533.05 5 L N 410.49 533.05 410.49 562.43 412.73 562.43 412.73 533.05 410.49 533.05 5 Y 0 H 0 Z 1 X N 425.61 533.05 425.61 563.65 427.85 563.65 427.85 533.05 425.61 533.05 5 Y N 440.73 533.05 440.73 576.68 442.97 576.68 442.97 533.05 440.73 533.05 5 Y N 455.86 533.05 455.86 565.38 458.09 565.38 458.09 533.05 455.86 533.05 5 Y N 470.98 533.05 470.98 561.06 473.21 561.06 473.21 533.05 470.98 533.05 5 Y N 486.1 533.05 486.1 587.63 488.33 587.63 488.33 533.05 486.1 533.05 5 Y N 501.21 533.05 501.21 569.48 503.45 569.48 503.45 533.05 501.21 533.05 5 Y N 410.49 533.05 410.49 562.43 412.73 562.43 412.73 533.05 410.49 533.05 5 L 0.5 H 1 Z 0 X N 425.61 533.05 425.61 563.65 427.85 563.65 427.85 533.05 425.61 533.05 5 L N 440.73 533.05 440.73 576.68 442.97 576.68 442.97 533.05 440.73 533.05 5 L N 455.86 533.05 455.86 565.38 458.09 565.38 458.09 533.05 455.86 533.05 5 L N 470.98 533.05 470.98 561.06 473.21 561.06 473.21 533.05 470.98 533.05 5 L N 486.1 533.05 486.1 587.63 488.33 587.63 488.33 533.05 486.1 533.05 5 L N 501.21 533.05 501.21 569.48 503.45 569.48 503.45 533.05 501.21 533.05 5 L N 367.64 475.16 552.85 720.21 R 2 Z N 58.14 469 553.5 720 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "5" 5 %%Page: "6" 6 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 2.73 (blocked data TLB miss rate jumped to 2% and 11%,) 58.5 387.33 P (causing a corresponding hike in speedup for cyclic.) 58.5 375.83 T 1.57 (Absolute miss rates in the larger data TLB are low) 76.5 364.33 P 0.33 (enough \050usually under 0.2%, except for applu and su2cor,) 58.5 352.83 P 0.47 (which reached 0.9%\051 that most changes produced little or) 58.5 341.33 P 0.47 (no benefit for cyclic. In contrast, su2cor saw degradation,) 58.5 329.83 P 6.09 (because cyclic scheduling increased loop unrolling) 58.5 318.33 P 1.7 (instruction overhead. This performance degradation was) 58.5 306.83 P 3.04 (not seen with the smaller TLB size, because cyclic\325s) 58.5 295.33 P (improved TLB hit rate offset the overhead.) 58.5 283.83 T 3.42 (Mgrid saw a large performance improvement for) 76.5 272.33 P 3.87 (both TLB sizes, because of a reduction in dynamic) 58.5 260.83 P 1.27 (instruction count. As Figures 1b and 1c illustrate, cyclic) 58.5 249.33 P 1.23 (parallelization requires fewer computations and no long-) 58.5 237.83 P (latency divide.) 58.5 226.33 T 0.44 (In summary, these results suggest using a cyclic loop) 76.5 214.83 P 1.45 (distribution for SMT, rather than the traditional blocked) 58.5 203.33 P 3.96 (distribution. For parallel applications with large data) 58.5 191.83 P 10.24 (footprints, cyclic distribution increased program) 58.5 180.33 P 1.87 (speedups. \050We saw speedups as high as 4.1, even with) 58.5 168.83 P 7.11 (the smallish SPECfp95 reference data sets.\051 For) 58.5 157.33 P 3.12 (applications with smaller data footprints, cyclic broke) 58.5 145.83 P 1.84 (even. Only in one application, where there was an odd) 58.5 134.33 P 3.83 (interaction with the loop unrolling factor, did cyclic) 58.5 122.83 P (worsen performance.) 58.5 111.33 T 3.48 (In a multiprocessor of SMT processors, a cyclic) 76.5 99.83 P 1.37 (distribution would still be appropriate within each node.) 58.5 88.33 P 1 7 Q (Application) 61.72 512.21 T 1 6 Q (48-entry TLB) 129.74 533.88 T (128-entry TLB) 224.91 533.88 T (Number of threads) 123.83 521.88 T (Number of threads) 220.5 521.88 T (1) 106.16 509.88 T (2) 125.49 509.88 T (4) 144.83 509.88 T (6) 164.16 509.88 T (8) 183.49 509.88 T (1) 202.83 509.88 T (2) 222.16 509.88 T (4) 241.49 509.88 T (6) 260.83 509.88 T (8) 280.16 509.88 T 1 7 Q (applu) 61.5 497.21 T 1 6 Q (0%) 106.33 497.88 T (50%) 122.66 497.88 T (58%) 141.99 497.88 T (53%) 161.33 497.88 T (15%) 180.66 497.88 T (0%) 202.99 497.88 T (91%) 219.33 497.88 T (98%) 238.66 497.88 T (85%) 257.99 497.88 T (69%) 277.33 497.88 T 1 7 Q (hydro2d) 61.5 484.21 T 1 6 Q (0%) 106.33 484.88 T (0%) 125.66 484.88 T (14%) 141.99 484.88 T (91%) 161.33 484.88 T (99%) 180.66 484.88 T (0%) 202.99 484.88 T (0%) 222.33 484.88 T (0%) 241.66 484.88 T (0%) 260.99 484.88 T (14%) 277.33 484.88 T 1 7 Q (mgrid) 61.5 471.21 T 1 6 Q (0%) 106.33 471.88 T (0%) 125.66 471.88 T (0%) 144.99 471.88 T (0%) 164.33 471.88 T (50%) 180.66 471.88 T (0%) 202.99 471.88 T (0%) 222.33 471.88 T (0%) 241.66 471.88 T (0%) 260.99 471.88 T (0%) 280.33 471.88 T 1 7 Q (su2cor) 61.5 458.21 T 1 6 Q (14%) 103.33 458.88 T (99%) 122.66 458.88 T (99%) 141.99 458.88 T (99%) 161.33 458.88 T (97%) 180.66 458.88 T (0%) 202.99 458.88 T (0%) 222.33 458.88 T (98%) 238.66 458.88 T (91%) 257.99 458.88 T (94%) 277.33 458.88 T 1 7 Q (swim) 61.5 445.21 T 1 6 Q (0%) 106.33 445.88 T (0%) 125.66 445.88 T (0%) 144.99 445.88 T (99%) 161.33 445.88 T (99%) 180.66 445.88 T (0%) 202.99 445.88 T (0%) 222.33 445.88 T (0%) 241.66 445.88 T (0%) 260.99 445.88 T (0%) 280.33 445.88 T 1 7 Q (tomcatv) 61.5 432.21 T 1 6 Q (0%) 106.33 432.88 T (-60%) 120.66 432.88 T (-60%) 140 432.88 T (96%) 161.33 432.88 T (99%) 180.66 432.88 T (0%) 202.99 432.88 T (-60%) 217.33 432.88 T (-60%) 236.66 432.88 T (-60%) 256 432.88 T (-60%) 275.33 432.88 T 4 10 Q 3.19 (T) 58.5 414.21 P 3.19 (able 4: Improvement \050decrease\051 in TLB miss) 63.87 414.21 P (rates of cyclic distribution over blocked.) 58.5 403.21 T 58.5 540.62 58.5 427.12 2 L V 0.5 H 0 Z N 96.74 540.62 96.74 427.12 2 L V N 99.24 540.62 99.24 427.12 2 L V N 117.33 517.12 117.33 426.62 2 L V N 136.66 517.12 136.66 426.62 2 L V N 155.99 517.12 155.99 426.62 2 L V N 175.33 517.12 175.33 426.62 2 L V N 193.41 540.62 193.41 427.12 2 L V N 195.91 540.62 195.91 427.12 2 L V N 213.99 517.12 213.99 426.62 2 L V N 233.33 517.12 233.33 426.62 2 L V N 252.66 517.12 252.66 426.62 2 L V N 271.99 517.12 271.99 426.62 2 L V N 291.33 540.62 291.33 427.12 2 L V N 58.25 540.88 291.58 540.88 2 L V N 99.49 528.88 291.58 528.88 2 L V N 99.49 516.88 291.58 516.88 2 L V N 58.25 504.88 291.58 504.88 2 L V 2 H N 58.25 491.88 291.58 491.88 2 L V 0.5 H N 58.25 478.88 291.58 478.88 2 L V N 58.25 465.88 291.58 465.88 2 L V N 58.25 452.88 291.58 452.88 2 L V N 58.25 439.88 291.58 439.88 2 L V N 58.25 426.88 291.58 426.88 2 L V N 58.5 545.88 552.92 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 61.23 545.88 551.64 716.96 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 61.23 545.81 551.64 716.96 R 7 X 0 0 0 1 0 0 0 K V 3 6 Q 0 X (3.5) 0 -270 193.73 694.3 TF (4.1) 0 -270 208.39 695.46 TF 374.03 613.52 525.23 613.52 2 L 0.5 H 1 Z N 374.03 613.52 374.03 699.91 2 L N 3 7 Q (applu) 0 -270 384.83 591.53 TF (hydro2d) 0 -270 406.43 583.36 TF (mgrid) 0 -270 428.03 591.15 TF (su2cor) 0 -270 449.63 587.64 TF (swim) 0 -270 471.23 592.71 TF (tomcatv) 0 -270 492.83 584.14 TF (mean) 0 -270 514.43 591.14 TF 374.03 613.52 375.68 613.52 2 L N 374.03 624.32 375.68 624.32 2 L N 374.03 635.11 375.68 635.11 2 L N 374.03 645.91 375.68 645.91 2 L N 374.03 656.71 375.68 656.71 2 L N 374.03 667.52 375.68 667.52 2 L N 374.03 678.32 375.68 678.32 2 L N 374.03 689.11 375.68 689.11 2 L N 374.03 699.91 375.68 699.91 2 L N 374.03 613.52 376.91 613.52 2 L N 374.03 656.71 376.91 656.71 2 L N 3 8 Q (0.0) 357.36 610.52 T (1.0) 357.36 653.71 T (2.0) 357.36 696.91 T (Speedup versus blocked) 0 -270 349.98 612.91 TF 4 9 Q (b\051 128-entry data TLB) 403.62 709.45 T 374.03 699.91 376.91 699.91 2 L N 376.91 613.52 376.91 656.71 380.07 656.71 380.07 613.52 376.91 613.52 5 Y V 0 H 0 Z 1 X N 398.51 613.52 398.51 657.15 401.67 657.15 401.67 613.52 398.51 613.52 5 Y 0 X V 1 X N 420.11 613.52 420.11 677.02 423.27 677.02 423.27 613.52 420.11 613.52 5 Y 0 X V 1 X N 441.71 613.52 441.71 654.55 444.87 654.55 444.87 613.52 441.71 613.52 5 Y 0 X V 1 X N 463.31 613.52 463.31 656.71 466.47 656.71 466.47 613.52 463.31 613.52 5 Y 0 X V 1 X N 484.91 613.52 484.91 656.71 488.07 656.71 488.07 613.52 484.91 613.52 5 Y 0 X V 1 X N 506.51 613.52 506.51 658.88 509.67 658.88 509.67 613.52 506.51 613.52 5 Y 0 X V 1 X N 376.91 613.52 376.91 656.71 380.07 656.71 380.07 613.52 376.91 613.52 5 L 0.5 H 1 Z 0 X N 398.51 613.52 398.51 657.15 401.67 657.15 401.67 613.52 398.51 613.52 5 L N 420.11 613.52 420.11 677.02 423.27 677.02 423.27 613.52 420.11 613.52 5 L N 441.71 613.52 441.71 654.55 444.87 654.55 444.87 613.52 441.71 613.52 5 L N 463.31 613.52 463.31 656.71 466.47 656.71 466.47 613.52 463.31 613.52 5 L N 484.91 613.52 484.91 656.71 488.07 656.71 488.07 613.52 484.91 613.52 5 L N 506.51 613.52 506.51 658.88 509.67 658.88 509.67 613.52 506.51 613.52 5 L N 380.07 613.52 380.07 661.47 383.24 661.47 383.24 613.52 380.07 613.52 5 Y 2 X V 0 H 0 Z 1 X N 401.67 613.52 401.67 657.58 404.84 657.58 404.84 613.52 401.67 613.52 5 Y 2 X V 1 X N 423.27 613.52 423.27 676.59 426.44 676.59 426.44 613.52 423.27 613.52 5 Y 2 X V 1 X N 444.87 613.52 444.87 651.96 448.04 651.96 448.04 613.52 444.87 613.52 5 Y 2 X V 1 X N 466.47 613.52 466.47 656.71 469.64 656.71 469.64 613.52 466.47 613.52 5 Y 2 X V 1 X N 488.07 613.52 488.07 656.28 491.24 656.28 491.24 613.52 488.07 613.52 5 Y 2 X V 1 X N 509.67 613.52 509.67 658.88 512.84 658.88 512.84 613.52 509.67 613.52 5 Y 2 X V 1 X N 380.07 613.52 380.07 661.47 383.24 661.47 383.24 613.52 380.07 613.52 5 L 0.5 H 1 Z 0 X N 401.67 613.52 401.67 657.58 404.84 657.58 404.84 613.52 401.67 613.52 5 L N 423.27 613.52 423.27 676.59 426.44 676.59 426.44 613.52 423.27 613.52 5 L N 444.87 613.52 444.87 651.96 448.04 651.96 448.04 613.52 444.87 613.52 5 L N 466.47 613.52 466.47 656.71 469.64 656.71 469.64 613.52 466.47 613.52 5 L N 488.07 613.52 488.07 656.28 491.24 656.28 491.24 613.52 488.07 613.52 5 L N 509.67 613.52 509.67 658.88 512.84 658.88 512.84 613.52 509.67 613.52 5 L N 383.24 613.52 383.24 671.4 386.34 671.4 386.34 613.52 383.24 613.52 5 Y 4 X V 0 H 0 Z 1 X N 404.84 613.52 404.84 658.01 407.94 658.01 407.94 613.52 404.84 613.52 5 Y 4 X V 1 X N 426.44 613.52 426.44 676.16 429.54 676.16 429.54 613.52 426.44 613.52 5 Y 4 X V 1 X N 448.04 613.52 448.04 654.55 451.14 654.55 451.14 613.52 448.04 613.52 5 Y 4 X V 1 X N 469.64 613.52 469.64 656.71 472.74 656.71 472.74 613.52 469.64 613.52 5 Y 4 X V 1 X N 491.24 613.52 491.24 656.71 494.34 656.71 494.34 613.52 491.24 613.52 5 Y 4 X V 1 X N 512.84 613.52 512.84 661.04 515.94 661.04 515.94 613.52 512.84 613.52 5 Y 4 X V 1 X N 383.24 613.52 383.24 671.4 386.34 671.4 386.34 613.52 383.24 613.52 5 L 0.5 H 1 Z 0 X N 404.84 613.52 404.84 658.01 407.94 658.01 407.94 613.52 404.84 613.52 5 L N 426.44 613.52 426.44 676.16 429.54 676.16 429.54 613.52 426.44 613.52 5 L N 448.04 613.52 448.04 654.55 451.14 654.55 451.14 613.52 448.04 613.52 5 L N 469.64 613.52 469.64 656.71 472.74 656.71 472.74 613.52 469.64 613.52 5 L N 491.24 613.52 491.24 656.71 494.34 656.71 494.34 613.52 491.24 613.52 5 L N 512.84 613.52 512.84 661.04 515.94 661.04 515.94 613.52 512.84 613.52 5 L N 386.34 613.52 386.34 664.06 389.51 664.06 389.51 613.52 386.34 613.52 5 Y 6 X V 0 H 0 Z 1 X N 407.94 613.52 407.94 658.01 411.11 658.01 411.11 613.52 407.94 613.52 5 Y 6 X V 1 X N 429.54 613.52 429.54 676.16 432.71 676.16 432.71 613.52 429.54 613.52 5 Y 6 X V 1 X N 451.14 613.52 451.14 654.12 454.31 654.12 454.31 613.52 451.14 613.52 5 Y 6 X V 1 X N 472.74 613.52 472.74 656.71 475.91 656.71 475.91 613.52 472.74 613.52 5 Y 6 X V 1 X N 494.34 613.52 494.34 656.71 497.51 656.71 497.51 613.52 494.34 613.52 5 Y 6 X V 1 X N 515.94 613.52 515.94 660.17 519.11 660.17 519.11 613.52 515.94 613.52 5 Y 6 X V 1 X N 386.34 613.52 386.34 664.06 389.51 664.06 389.51 613.52 386.34 613.52 5 L 0.5 H 1 Z 0 X N 407.94 613.52 407.94 658.01 411.11 658.01 411.11 613.52 407.94 613.52 5 L N 429.54 613.52 429.54 676.16 432.71 676.16 432.71 613.52 429.54 613.52 5 L N 451.14 613.52 451.14 654.12 454.31 654.12 454.31 613.52 451.14 613.52 5 L N 472.74 613.52 472.74 656.71 475.91 656.71 475.91 613.52 472.74 613.52 5 L N 494.34 613.52 494.34 656.71 497.51 656.71 497.51 613.52 494.34 613.52 5 L N 515.94 613.52 515.94 660.17 519.11 660.17 519.11 613.52 515.94 613.52 5 L N 389.51 613.52 389.51 660.17 392.67 660.17 392.67 613.52 389.51 613.52 5 Y 0 H 0 Z 1 X N 411.11 613.52 411.11 658.01 414.27 658.01 414.27 613.52 411.11 613.52 5 Y N 432.71 613.52 432.71 676.16 435.87 676.16 435.87 613.52 432.71 613.52 5 Y N 454.31 613.52 454.31 653.69 457.47 653.69 457.47 613.52 454.31 613.52 5 Y N 475.91 613.52 475.91 656.71 479.07 656.71 479.07 613.52 475.91 613.52 5 Y N 497.51 613.52 497.51 656.71 500.67 656.71 500.67 613.52 497.51 613.52 5 Y N 519.11 613.52 519.11 659.31 522.27 659.31 522.27 613.52 519.11 613.52 5 Y N 389.51 613.52 389.51 660.17 392.67 660.17 392.67 613.52 389.51 613.52 5 L 0.5 H 1 Z 0 X N 411.11 613.52 411.11 658.01 414.27 658.01 414.27 613.52 411.11 613.52 5 L N 432.71 613.52 432.71 676.16 435.87 676.16 435.87 613.52 432.71 613.52 5 L N 454.31 613.52 454.31 653.69 457.47 653.69 457.47 613.52 454.31 613.52 5 L N 475.91 613.52 475.91 656.71 479.07 656.71 479.07 613.52 475.91 613.52 5 L N 497.51 613.52 497.51 656.71 500.67 656.71 500.67 613.52 497.51 613.52 5 L N 519.11 613.52 519.11 659.31 522.27 659.31 522.27 613.52 519.11 613.52 5 L N 374.03 656.71 525.23 656.71 2 L 1 X N 97.5 611 248.7 611 2 L 0 X N 97.5 611 97.5 697.4 2 L N 3 7 Q (applu) 0 -270 108.3 589.01 TF (hydro2d) 0 -270 129.9 580.84 TF (mgrid) 0 -270 151.5 588.63 TF (su2cor) 0 -270 173.1 585.12 TF (swim) 0 -270 194.7 590.19 TF (tomcatv) 0 -270 216.3 581.62 TF (mean) 0 -270 237.9 588.62 TF 97.5 611 99.16 611 2 L N 97.5 621.8 99.16 621.8 2 L N 97.5 632.6 99.16 632.6 2 L N 97.5 643.4 99.16 643.4 2 L N 97.5 654.2 99.16 654.2 2 L N 97.5 665 99.16 665 2 L N 97.5 675.8 99.16 675.8 2 L N 97.5 686.6 99.16 686.6 2 L N 97.5 697.4 99.16 697.4 2 L N 97.5 611 100.38 611 2 L N 97.5 654.2 100.38 654.2 2 L N 3 8 Q (0.0) 80.84 608 T (1.0) 80.84 651.2 T (2.0) 80.84 694.4 T (Speedup versus blocked) 0 -270 73.46 610.4 TF 4 9 Q (a\051 48-entry data TLB) 129.85 707.77 T 97.5 697.4 100.38 697.4 2 L N 100.38 611 100.38 654.63 103.55 654.63 103.55 611 100.38 611 5 Y V 0 H 0 Z 1 X N 121.98 611 121.98 654.63 125.15 654.63 125.15 611 121.98 611 5 Y 0 X V 1 X N 143.58 611 143.58 674.5 146.75 674.5 146.75 611 143.58 611 5 Y 0 X V 1 X N 165.18 611 165.18 652.04 168.35 652.04 168.35 611 165.18 611 5 Y 0 X V 1 X N 186.78 611 186.78 654.2 189.95 654.2 189.95 611 186.78 611 5 Y 0 X V 1 X N 208.38 611 208.38 654.2 211.55 654.2 211.55 611 208.38 611 5 Y 0 X V 1 X N 229.98 611 229.98 656.36 233.15 656.36 233.15 611 229.98 611 5 Y 0 X V 1 X N 100.38 611 100.38 654.63 103.55 654.63 103.55 611 100.38 611 5 L 0.5 H 1 Z 0 X N 121.98 611 121.98 654.63 125.15 654.63 125.15 611 121.98 611 5 L N 143.58 611 143.58 674.5 146.75 674.5 146.75 611 143.58 611 5 L N 165.18 611 165.18 652.04 168.35 652.04 168.35 611 165.18 611 5 L N 186.78 611 186.78 654.2 189.95 654.2 189.95 611 186.78 611 5 L N 208.38 611 208.38 654.2 211.55 654.2 211.55 611 208.38 611 5 L N 229.98 611 229.98 656.36 233.15 656.36 233.15 611 229.98 611 5 L N 103.55 611 103.55 657.22 106.72 657.22 106.72 611 103.55 611 5 Y 2 X V 0 H 0 Z 1 X N 125.15 611 125.15 655.06 128.32 655.06 128.32 611 125.15 611 5 Y 2 X V 1 X N 146.75 611 146.75 674.07 149.92 674.07 149.92 611 146.75 611 5 Y 2 X V 1 X N 168.35 611 168.35 658.09 171.52 658.09 171.52 611 168.35 611 5 Y 2 X V 1 X N 189.95 611 189.95 654.2 193.12 654.2 193.12 611 189.95 611 5 Y 2 X V 1 X N 211.55 611 211.55 653.77 214.72 653.77 214.72 611 211.55 611 5 Y 2 X V 1 X N 233.15 611 233.15 658.09 236.32 658.09 236.32 611 233.15 611 5 Y 2 X V 1 X N 103.55 611 103.55 657.22 106.72 657.22 106.72 611 103.55 611 5 L 0.5 H 1 Z 0 X N 125.15 611 125.15 655.06 128.32 655.06 128.32 611 125.15 611 5 L N 146.75 611 146.75 674.07 149.92 674.07 149.92 611 146.75 611 5 L N 168.35 611 168.35 658.09 171.52 658.09 171.52 611 168.35 611 5 L N 189.95 611 189.95 654.2 193.12 654.2 193.12 611 189.95 611 5 L N 211.55 611 211.55 653.77 214.72 653.77 214.72 611 211.55 611 5 L N 233.15 611 233.15 658.09 236.32 658.09 236.32 611 233.15 611 5 L N 106.72 611 106.72 655.93 109.82 655.93 109.82 611 106.72 611 5 Y 4 X V 0 H 0 Z 1 X N 128.32 611 128.32 655.49 131.42 655.49 131.42 611 128.32 611 5 Y 4 X V 1 X N 149.92 611 149.92 673.64 153.02 673.64 153.02 611 149.92 611 5 Y 4 X V 1 X N 171.52 611 171.52 663.27 174.62 663.27 174.62 611 171.52 611 5 Y 4 X V 1 X N 193.12 611 193.12 654.2 196.22 654.2 196.22 611 193.12 611 5 Y 4 X V 1 X N 214.72 611 214.72 653.77 217.82 653.77 217.82 611 214.72 611 5 Y 4 X V 1 X N 236.32 611 236.32 658.52 239.42 658.52 239.42 611 236.32 611 5 Y 4 X V 1 X N 106.72 611 106.72 655.93 109.82 655.93 109.82 611 106.72 611 5 L 0.5 H 1 Z 0 X N 128.32 611 128.32 655.49 131.42 655.49 131.42 611 128.32 611 5 L N 149.92 611 149.92 673.64 153.02 673.64 153.02 611 149.92 611 5 L N 171.52 611 171.52 663.27 174.62 663.27 174.62 611 171.52 611 5 L N 193.12 611 193.12 654.2 196.22 654.2 196.22 611 193.12 611 5 L N 214.72 611 214.72 653.77 217.82 653.77 217.82 611 214.72 611 5 L N 236.32 611 236.32 658.52 239.42 658.52 239.42 611 236.32 611 5 L N 109.82 611 109.82 655.93 112.98 655.93 112.98 611 109.82 611 5 Y 6 X V 0 H 0 Z 1 X N 131.42 611 131.42 658.95 134.58 658.95 134.58 611 131.42 611 5 Y 6 X V 1 X N 153.02 611 153.02 673.21 156.18 673.21 156.18 611 153.02 611 5 Y 6 X V 1 X N 174.62 611 174.62 664.13 177.78 664.13 177.78 611 174.62 611 5 Y 6 X V 1 X N 196.22 611 196.22 697.4 199.38 697.4 199.38 611 196.22 611 5 Y 6 X V 1 X N 217.82 611 217.82 658.52 220.98 658.52 220.98 611 217.82 611 5 Y 6 X V 1 X N 239.42 611 239.42 668.45 242.58 668.45 242.58 611 239.42 611 5 Y 6 X V 1 X N 109.82 611 109.82 655.93 112.98 655.93 112.98 611 109.82 611 5 L 0.5 H 1 Z 0 X N 131.42 611 131.42 658.95 134.58 658.95 134.58 611 131.42 611 5 L N 153.02 611 153.02 673.21 156.18 673.21 156.18 611 153.02 611 5 L N 174.62 611 174.62 664.13 177.78 664.13 177.78 611 174.62 611 5 L N 196.22 611 196.22 697.4 2 L N 199.38 697.4 199.38 611 196.22 611 3 L N 217.82 611 217.82 658.52 220.98 658.52 220.98 611 217.82 611 5 L N 239.42 611 239.42 668.45 242.58 668.45 242.58 611 239.42 611 5 L N 112.98 611 112.98 655.49 116.15 655.49 116.15 611 112.98 611 5 Y 0 H 0 Z 1 X N 134.58 611 134.58 673.21 137.75 673.21 137.75 611 134.58 611 5 Y N 156.18 611 156.18 674.07 159.35 674.07 159.35 611 156.18 611 5 Y N 177.78 611 177.78 662.41 180.95 662.41 180.95 611 177.78 611 5 Y N 199.38 611 199.38 697.4 202.55 697.4 202.55 611 199.38 611 5 Y N 220.98 611 220.98 684.87 224.15 684.87 224.15 611 220.98 611 5 Y N 242.58 611 242.58 675.37 245.75 675.37 245.75 611 242.58 611 5 Y N 112.98 611 112.98 655.49 116.15 655.49 116.15 611 112.98 611 5 L 0.5 H 1 Z 0 X N 134.58 611 134.58 673.21 137.75 673.21 137.75 611 134.58 611 5 L N 156.18 611 156.18 674.07 159.35 674.07 159.35 611 156.18 611 5 L N 177.78 611 177.78 662.41 180.95 662.41 180.95 611 177.78 611 5 L N 199.38 611 199.38 697.4 2 L N 202.55 697.4 202.55 611 199.38 611 3 L N 220.98 611 220.98 684.87 224.15 684.87 224.15 611 220.98 611 5 L N 242.58 611 242.58 675.37 245.75 675.37 245.75 611 242.58 611 5 L N 277.23 663.25 285.72 663.25 285.72 672.33 277.23 672.33 4 Y V 0 H 0 Z 1 X N 3 7 Q 0 X (1 thread) 289.97 665.46 T 277.23 663.25 285.72 663.25 285.72 672.33 277.23 672.33 277.23 663.25 5 L 0.5 H 1 Z N 277.23 654.18 285.72 654.18 285.72 663.25 277.23 663.25 4 Y 2 X V 0 H 0 Z 1 X N 0 X (2 thread) 289.97 656.38 T 277.23 654.18 285.72 654.18 285.72 663.25 277.23 663.25 277.23 654.18 5 L 0.5 H 1 Z N 277.23 645.11 285.72 645.11 285.72 654.18 277.23 654.18 4 Y 4 X V 0 H 0 Z 1 X N 0 X (4 thread) 289.97 647.31 T 277.23 645.11 285.72 645.11 285.72 654.18 277.23 654.18 277.23 645.11 5 L 0.5 H 1 Z N 277.23 636.04 285.72 636.04 285.72 645.11 277.23 645.11 4 Y 6 X V 0 H 0 Z 1 X N 0 X (6 thread) 289.97 638.24 T 277.23 636.04 285.72 636.04 285.72 645.11 277.23 645.11 277.23 636.04 5 L 0.5 H 1 Z N 277.23 626.96 285.72 626.96 285.72 636.04 277.23 636.04 4 Y 0 H 0 Z 1 X N 0 X (8 thread) 289.97 629.17 T 277.23 626.96 285.72 626.96 285.72 636.04 277.23 636.04 277.23 626.96 5 L 0.5 H 1 Z N 97.5 654.2 248.7 654.2 2 L 1 X N 63.22 553.25 548.04 578.38 R 7 X V 4 10 Q 0 X 1.37 (Figure 3: Speedup attained by cyclic over blocked parallelization.) 63.22 571.71 P 3 8 Q 1.1 (For each application, the execution time for) 388.48 571.71 P 0.86 (blocked is normalized to 1.0 for all numbers of threads. Thus, each bar compares the speedup for cyclic over blocked with the same) 63.22 563.04 P (number of threads.) 63.22 555.04 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 545.88 552.92 720 C 59.81 551.33 552.65 718.5 R 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 319.5 81 553.5 545.83 R 7 X 0 0 0 1 0 0 0 K V 1 10 Q 0 X 5.35 (A hybrid parallelization policy might be desirable,) 319.5 539.17 P 1.61 (though, with a blocked distribution across processors to) 319.5 527.67 P (minimize inter-processor communication.) 319.5 516.17 T 0 12 Q (6) 319.5 495.33 T (Software speculative execution) 337.5 495.33 T 1 10 Q 4.04 (Today\325s optimizing compilers rely on aggressive) 337.5 477.17 P 2.24 (code scheduling to hide instruction latencies. In global) 319.5 465.67 P 1.93 (scheduling techniques, such as trace scheduling [22] or) 319.5 454.01 P 0.63 (hyperblock scheduling [23], instructions from a predicted) 319.5 442.36 P 1.58 (branch path may be moved above a conditional branch,) 319.5 430.86 P 0.37 (so that their execution becomes speculative. If at runtime,) 319.5 419.36 P 3.94 (the other branch path is taken, then the speculative) 319.5 407.86 P 2.25 (instructions are useless and potentially waste processor) 319.5 396.36 P (resources.) 319.5 384.86 T 7.1 (On in-order superscalars or VLIW machines,) 337.5 373.36 P 1.65 (software speculation is necessary, because the hardware) 319.5 361.86 P 0.81 (provides no scheduling assistance. On an SMT processor) 319.5 350.36 P 0.42 (\050whose execution core is an out-of-order superscalar\051, not) 319.5 338.86 P 8.19 (only are instructions dynamically scheduled and) 319.5 327.36 P 11.7 (speculatively executed by the hardware, but) 319.5 315.86 P 3.11 (multithreading is also used to hide latencies. \050As the) 319.5 304.36 P 6.83 (number of SMT threads is increased, instruction) 319.5 292.86 P 1.42 (throughput also increases.\051 Therefore, the latency-hiding) 319.5 281.36 P 0.46 (benefits of software speculative execution may be needed) 319.5 269.86 P 6.33 (less, or even be unnecessary, and the additional) 319.5 258.36 P 0.86 (instruction overhead introduced by incorrect speculations) 319.5 246.86 P (may degrade performance.) 319.5 235.36 T 4.71 (Our experiments were designed to evaluate the) 337.5 223.86 P 1.42 (appropriateness of software speculative execution for an) 319.5 212.36 P 2.88 (SMT processor. The results highlight two factors that) 319.5 200.86 P 5.67 (determine its effectiveness for SMT: static branch) 319.5 189.36 P (prediction accuracy and instruction throughput.) 319.5 177.86 T 1.09 (Correctly-speculated instructions have no instruction) 337.5 166.36 P 4.04 (overhead; incorrectly-speculated instructions, however,) 319.5 154.86 P 6.78 (add to the dynamic instruction count. Therefore,) 319.5 143.36 P 1.41 (speculative execution is more beneficial for applications) 319.5 131.86 P 3.82 (that have high speculation accuracy, e.g., loop-based) 319.5 120.36 P 3.98 (programs with either profile-driven or state-of-the-art) 319.5 108.86 P (static branch prediction.) 319.5 97.36 T 3.23 (Table 5 compares the dynamic instruction counts) 337.5 85.86 P 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "6" 6 %%Page: "7" 7 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 11.68 (between \050profile-driven\051) 58.5 366.67 P 1 8 Q 9.34 (2) 168.2 370.67 P 1 10 Q 11.68 ( speculative and non-) 172.2 366.67 P 1.37 (speculative versions of our applications. Small increases) 58.5 355.17 P 5.45 (in the dynamic instruction count indicate that the) 58.5 343.67 P 2.71 (compiler \050with the assistance of profiling information\051) 58.5 332.17 P 1.72 (has been able to accurately predict which paths will be) 58.5 320.67 P 5.73 (executed.) 58.5 306.5 P 1 8 Q 4.58 (3) 96.54 310.5 P 1 10 Q 5.73 ( Consequently, speculation may incur no) 100.54 306.5 P 1.13 (penalties. Higher increases in dynamic instruction count,) 58.5 295 P 1.34 (on the other hand, mean wrong-path speculations, and a) 58.5 283.5 P (probable loss in SMT performance.) 58.5 272 T 12.2 (While instruction overhead influences the) 76.5 260.5 P 0.73 (effectiveness of speculation, it is not the only factor. The) 58.5 249 P 4.74 (level of instruction throughput in programs without) 58.5 237.5 P 1.21 (speculation is also important, because it determines how) 58.5 226 P 5.35 (easily speculative overhead can be absorbed. With) 58.5 214.5 P 7.8 (sufficient instruction issue bandwidth \050low IPC\051,) 58.5 203 P 2.2 (incorrect speculations may cause no harm; with higher) 58.5 191.5 P 58.5 165.27 292.5 180.27 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 67.5 178.27 211.5 178.27 2 L 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 1 6.4 Q 0 X 0 0 0 1 0 0 0 K -0.13 (2.) 58.5 161 P 1 8 Q -0.16 (W) 63.3 157.8 P -0.16 (e used pro\336le-driven speculation to provide a best-case comparison to) 70.21 157.8 P 1.26 (SMT) 58.5 147.8 P 1.26 (. W) 74.36 147.8 P 1.26 (ithout pro\336les, more mispredictions would have occurred and) 86.84 147.8 P 1.16 (more overhead instructions would have been generated. Consequently) 58.5 137.8 P 1.16 (,) 290.5 137.8 P 1.9 (software speculation would have worse performance than we report,) 58.5 127.8 P (making its absence appear even more bene\336cial for SMT) 58.5 117.8 T (.) 240.53 117.8 T 1 6.4 Q 1.5 (3.) 58.5 108.87 P 1 8 Q 1.87 (All the SPECfp95 programs, radix from SPLASH-2, and compress) 63.3 105.67 P 1.36 (from SPECint95, are loop-based; all have small increases in dynamic) 58.5 95.67 P (instruction count with speculation.) 58.5 85.67 T 1 7 Q (Specfp95) 63.48 702.33 T (%) 107.21 710.33 T (increase) 98.66 702.33 T (SPECint95) 132.99 702.33 T (%) 186.97 710.33 T (increase) 178.42 702.33 T (SPLASH-2) 216.95 702.33 T (%) 272.99 710.33 T (increase) 264.43 702.33 T (applu) 61.5 687.33 T (2.1%) 107.77 687.33 T (compress) 128.35 687.33 T (2.9%) 190.45 687.33 T 0 F (fft) 211.03 687.33 T (13.7%) 271.79 687.33 T 1 F (hydro2d) 61.5 674.33 T (1.9%) 107.77 674.33 T 2 F (go) 128.35 674.33 T (12.6%) 186.95 674.33 T 0 F (LU) 211.03 674.33 T (12.5%) 271.79 674.33 T 1 F (mgrid) 61.5 661.33 T (0.5%) 107.77 661.33 T 0 F (li) 128.35 661.33 T (7.3%) 189.28 661.33 T 1 F (radix) 211.03 661.33 T (0.0%) 276.46 661.33 T (su2cor) 61.5 648.33 T (0.1%) 107.77 648.33 T 2 F (m88ksim) 128.35 648.33 T (4.0%) 190.45 648.33 T 1 F (water) 211.03 648.33 T (-nsquared) 226.44 648.33 T (3.0%) 276.46 648.33 T (swim) 61.5 635.33 T (0.1%) 107.77 635.33 T 2 F (perl) 128.35 635.33 T (4.9%) 190.45 635.33 T 1 F (water) 211.03 635.33 T (-spatial) 226.44 635.33 T (3.0%) 276.46 635.33 T (tomcatv) 61.5 622.33 T (1.2%) 107.77 622.33 T 4 10 Q 8.38 (T) 58.5 605.33 P 8.38 (able 5: Percentage increase in dynamic) 63.87 605.33 P 1.79 (instruction count due to pro\336le-driven software) 58.5 594.33 P -0.13 (speculative execution.) 58.5 583.33 P 3 8 Q -0.1 (Data are shown for 8 threads. \050One) 167.73 583.33 P 0.36 (thread numbers were identical or very close\051. Applications in bold) 58.5 573.67 P 0.85 (have high speculative instruction overhead and high IPC without) 58.5 564.67 P (speculation; those in italics have only the former) 58.5 555.67 T (.) 228.36 555.67 T 1 7 Q (SPECfp95) 61.7 528.33 T (spec) 98.47 528.33 T (no) 121.65 536.33 T (spec) 118.93 528.33 T (SPECint95) 139.05 528.33 T (spec) 177.85 528.33 T (no) 201.03 536.33 T (spec) 198.32 528.33 T (SPLASH-2) 218.22 528.33 T (spec) 257.57 528.33 T (no) 280.76 536.33 T (spec) 278.04 528.33 T 2 F (applu) 61.5 515.33 T 1 F (4.9) 103.17 515.33 T 2 F (4.7) 123.63 515.33 T 1 F (compress) 138.38 515.33 T (4.1) 182.55 515.33 T (4.0) 203.02 515.33 T 0 F (fft) 217.77 515.33 T 1 F (6.0) 262.27 515.33 T 0 F (6.4) 282.74 515.33 T 2 F (hydr) 61.5 502.33 T (o2d) 74.07 502.33 T 1 F (5.6) 103.17 502.33 T 2 F (5.4) 123.63 502.33 T 1 F (go) 138.38 502.33 T (2.4) 182.55 502.33 T (2.3) 203.02 502.33 T 0 F (LU) 217.77 502.33 T 1 F (6.7) 262.27 502.33 T 0 F (6.8) 282.74 502.33 T 2 F (mgrid) 61.5 489.33 T 1 F (7.2) 103.17 489.33 T 2 F (7.1) 123.63 489.33 T 0 F (li) 138.38 489.33 T 1 F (4.5) 182.55 489.33 T 0 F (4.6) 203.02 489.33 T 2 F (radix) 217.77 489.33 T 1 F (5.4) 262.27 489.33 T 2 F (5.4) 282.74 489.33 T (su2cor) 61.5 476.33 T 1 F (6.1) 103.17 476.33 T 2 F (6.0) 123.63 476.33 T 1 F (m88ksim) 138.38 476.33 T (4.2) 182.55 476.33 T (4.1) 203.02 476.33 T 2 F (water) 217.77 476.33 T (-) 233.57 476.33 T (nsquar) 217.77 468.33 T (ed) 236.95 468.33 T 1 F (6.4) 262.27 476.33 T 2 F (6.1) 282.74 476.33 T (swim) 61.5 455.33 T 1 F (6.5) 103.17 455.33 T 2 F (6.2) 123.63 455.33 T 1 F (perl) 138.38 455.33 T (3.8) 182.55 455.33 T (3.7) 203.02 455.33 T 2 F (water) 217.77 453.33 T (-) 233.57 453.33 T 1 F (6.4) 262.27 455.33 T 2 F (6.5) 282.74 455.33 T (tomcatv) 61.5 442.33 T 1 F (6.2) 103.17 442.33 T 2 F (5.9) 123.63 442.33 T (spatial) 217.77 444.33 T 4 10 Q -0.04 (T) 58.5 424.33 P -0.04 (able 6: Throughput \050instructions per cycle\051 with) 63.87 424.33 P (and without pro\336le-driven software speculation) 58.5 413.33 T (for 8 threads.) 58.5 402.33 T 3 8 Q (Programs in bold have high IPC without) 124.63 402.33 T (speculation, plus high speculation overhead; those in) 58.5 392.67 T 7 F (italics) 248.38 392.67 T 3 F ( have) 268.38 392.67 T (only the former) 58.5 383.67 T (.) 111.41 383.67 T 58.5 719.75 58.5 617.25 2 L V 0.5 H 0 Z N 94.9 720.25 94.9 616.75 2 L V N 124.1 719.75 124.1 617.25 2 L V N 126.6 719.75 126.6 617.25 2 L V N 171.74 720.25 171.74 629.75 2 L V N 206.78 719.75 206.78 630.25 2 L V N 209.28 719.75 209.28 630.25 2 L V N 257.76 720.25 257.76 629.75 2 L V N 294.04 719.75 294.04 630.25 2 L V N 58.25 720 294.29 720 2 L V N 58.25 695 294.29 695 2 L V 2 H N 58.25 682 294.29 682 2 L V 0.5 H N 58.25 669 294.29 669 2 L V N 58.25 656 294.29 656 2 L V N 58.25 643 294.29 643 2 L V N 58.25 630 294.29 630 2 L V N 58.25 617 126.85 617 2 L V N 58.5 543.75 58.5 437.25 2 L V N 94.46 544.25 94.46 436.75 2 L V N 114.92 544.25 114.92 436.75 2 L V N 134.13 543.75 134.13 437.25 2 L V N 136.63 543.75 136.63 437.25 2 L V N 173.84 544.25 173.84 449.75 2 L V N 194.3 544.25 194.3 449.75 2 L V N 213.52 543.75 213.52 437.25 2 L V N 216.02 543.75 216.02 437.25 2 L V N 253.56 544.25 253.56 436.75 2 L V N 274.02 544.25 274.02 436.75 2 L V N 294.49 543.75 294.49 437.25 2 L V N 58.25 544 294.74 544 2 L V N 58.25 523 294.74 523 2 L V 2 H N 58.25 510 294.74 510 2 L V 0.5 H N 58.25 497 294.74 497 2 L V N 58.25 484 294.74 484 2 L V N 58.25 463 294.74 463 2 L V N 58.25 450 213.27 450 2 L V N 58.25 437 136.88 437 2 L V N 213.27 437 294.74 437 2 L V N 319.5 81 553.5 720 R 7 X V 1 10 Q 0 X 3.78 (per-thread ILP or more threads, software speculation) 319.5 424.33 P 1.7 (should be less profitable, because incorrectly-speculated) 319.5 412.83 P 4.34 (instructions are more likely to compete with useful) 319.5 401.33 P 2.11 (instructions for processor resources \050in particular, fetch) 319.5 389.83 P 2.4 (bandwidth and functional unit issue\051. Table 6 contains) 319.5 378.33 P 2.32 (the instruction throughput for each of the applications.) 319.5 366.83 P 6.25 (For some programs IPC is higher with software) 319.5 355.33 P 1.37 (speculation, indicating some degree of absorption of the) 319.5 343.83 P 2.07 (speculation overhead. In others, it is lower, because of) 319.5 332.33 P 1.74 (additional hardware resource conflicts, most notably L1) 319.5 320.83 P (cache misses.) 319.5 309.33 T 3.6 (Speculative instruction overhead \050related to static) 337.5 297.83 P 2.75 (branch prediction accuracy\051 and instruction throughput) 319.5 286.33 P 2 F 0.7 (together) 319.5 274.83 P 1 F 0.7 ( explain the speedups \050or lack thereof\051 illustrated) 352.83 274.83 P 1 (in Figure 4. When both factors were high \050the non-loop-) 319.5 263.33 P 5.5 (based fft, li, and LU\051, speedups without software) 319.5 251.83 P 2.64 (speculation were greatest, ranging up to 22%.) 319.5 237.67 P 1 8 Q 2.12 (4) 518.11 241.67 P 1 10 Q 2.64 ( If one) 522.11 237.67 P 0.61 (factor was low or only moderate, speedups were minimal) 319.5 226.17 P 3.49 (or nonexistent \050the SPECfp95 applications, radix and) 319.5 214.67 P 0.54 (water-nsquared had only high IPC; go, m88ksim and perl) 319.5 203.17 P 2.23 (had only speculation overhead\051.) 319.5 189 P 1 8 Q 1.78 (5) 453.94 193 P 1 10 Q 2.23 ( Without either factor,) 457.94 189 P 3.5 (software speculation helped performance, and for the) 319.5 177.5 P 3.7 (same reasons it benefits other architectures -- it hid) 319.5 166 P 3.73 (latencies and executed the speculative instructions in) 319.5 154.5 P 319.5 133.13 553.5 148.13 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 328.5 146.13 472.5 146.13 2 L 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 1 6.4 Q 0 X 0 0 0 1 0 0 0 K 0.57 (4.) 319.5 128.87 P 1 8 Q 0.72 (For these applications \050and a few others as well\051, as more threads are) 324.3 125.67 P 0.99 (used, the advantage of turning of) 319.5 115.67 P 0.99 (f speculation generally becomes even) 429.59 115.67 P -0.14 (lar) 319.5 105.67 P -0.14 (ger) 327.8 105.67 P -0.14 (. Additional threads provide more parallelism, and therefore, specu-) 337.57 105.67 P 0.07 (lative instructions are more likely to compete with useful instructions for) 319.5 95.67 P (processor resources.) 319.5 85.67 T 319.5 431.41 557.79 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 320.29 434.33 554.17 718.86 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 2 Z 0 X N 321.83 434.5 553.25 716.08 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 321.83 434.5 553.25 716.08 R 7 X 0 0 0 1 0 0 0 K V 359.79 642.27 458.59 642.27 2 L 0.5 H 1 Z 0 X N 359.79 642.27 359.79 700.59 2 L N 3 7 Q (applu) 0 -270 367.71 621.69 TF (hydro2d) 0 -270 383.5 613.52 TF (tomcatv) 0 -270 399.28 614.3 TF (mgrid) 0 -270 415.07 621.31 TF (su2cor) 0 -270 430.85 617.8 TF (swim) 0 -270 446.63 622.87 TF 359.79 642.27 361.4 642.27 2 L N 359.79 653.94 361.4 653.94 2 L N 359.79 665.6 361.4 665.6 2 L N 359.79 677.27 361.4 677.27 2 L N 359.79 688.93 361.4 688.93 2 L N 359.79 700.59 361.4 700.59 2 L N 359.79 642.27 362.59 642.27 2 L N 359.79 665.6 362.59 665.6 2 L N 3 8 Q (0.0) 343.27 639.5 T (0.5) 343.27 662.83 T (1.0) 343.27 686.16 T (Speedup over speculation) 0 -270 337.09 617.27 TF 4 9 Q (a\051 SPECfp95) 382.65 709.53 T 359.79 688.93 362.59 688.93 2 L N 361.96 642.27 361.96 688.44 364.28 688.44 364.28 642.27 361.96 642.27 5 Y V 0 H 0 Z 1 X N 377.74 642.27 377.74 686.11 380.06 686.11 380.06 642.27 377.74 642.27 5 Y 0 X V 1 X N 393.53 642.27 393.53 688.93 395.84 688.93 395.84 642.27 393.53 642.27 5 Y 0 X V 1 X N 409.31 642.27 409.31 688.44 411.63 688.44 411.63 642.27 409.31 642.27 5 Y 0 X V 1 X N 425.1 642.27 425.1 685.62 427.41 685.62 427.41 642.27 425.1 642.27 5 Y 0 X V 1 X N 440.88 642.27 440.88 687.96 443.2 687.96 443.2 642.27 440.88 642.27 5 Y 0 X V 1 X N 361.96 642.27 361.96 688.44 364.28 688.44 364.28 642.27 361.96 642.27 5 L 0.5 H 1 Z 0 X N 377.74 642.27 377.74 686.11 380.06 686.11 380.06 642.27 377.74 642.27 5 L N 393.53 642.27 393.53 688.93 395.84 688.93 395.84 642.27 393.53 642.27 5 L N 409.31 642.27 409.31 688.44 411.63 688.44 411.63 642.27 409.31 642.27 5 L N 425.1 642.27 425.1 685.62 427.41 685.62 427.41 642.27 425.1 642.27 5 L N 440.88 642.27 440.88 687.96 443.2 687.96 443.2 642.27 440.88 642.27 5 L N 364.28 642.27 364.28 689.37 366.59 689.37 366.59 642.27 364.28 642.27 5 Y 2 X V 0 H 0 Z 1 X N 380.06 642.27 380.06 687.52 382.38 687.52 382.38 642.27 380.06 642.27 5 Y 2 X V 1 X N 395.84 642.27 395.84 688.44 398.16 688.44 398.16 642.27 395.84 642.27 5 Y 2 X V 1 X N 411.63 642.27 411.63 688.44 413.94 688.44 413.94 642.27 411.63 642.27 5 Y 2 X V 1 X N 427.41 642.27 427.41 685.62 429.73 685.62 429.73 642.27 427.41 642.27 5 Y 2 X V 1 X N 443.2 642.27 443.2 689.37 445.51 689.37 445.51 642.27 443.2 642.27 5 Y 2 X V 1 X N 364.28 642.27 364.28 689.37 366.59 689.37 366.59 642.27 364.28 642.27 5 L 0.5 H 1 Z 0 X N 380.06 642.27 380.06 687.52 382.38 687.52 382.38 642.27 380.06 642.27 5 L N 395.84 642.27 395.84 688.44 398.16 688.44 398.16 642.27 395.84 642.27 5 L N 411.63 642.27 411.63 688.44 413.94 688.44 413.94 642.27 411.63 642.27 5 L N 427.41 642.27 427.41 685.62 429.73 685.62 429.73 642.27 427.41 642.27 5 L N 443.2 642.27 443.2 689.37 445.51 689.37 445.51 642.27 443.2 642.27 5 L N 366.59 642.27 366.59 687.96 368.84 687.96 368.84 642.27 366.59 642.27 5 Y 4 X V 0 H 0 Z 1 X N 382.38 642.27 382.38 687.52 384.62 687.52 384.62 642.27 382.38 642.27 5 Y 4 X V 1 X N 398.16 642.27 398.16 687.96 400.4 687.96 400.4 642.27 398.16 642.27 5 Y 4 X V 1 X N 413.94 642.27 413.94 688.44 416.19 688.44 416.19 642.27 413.94 642.27 5 Y 4 X V 1 X N 429.73 642.27 429.73 687.03 431.97 687.03 431.97 642.27 429.73 642.27 5 Y 4 X V 1 X N 445.51 642.27 445.51 686.6 447.75 686.6 447.75 642.27 445.51 642.27 5 Y 4 X V 1 X N 366.59 642.27 366.59 687.96 368.84 687.96 368.84 642.27 366.59 642.27 5 L 0.5 H 1 Z 0 X N 382.38 642.27 382.38 687.52 384.62 687.52 384.62 642.27 382.38 642.27 5 L N 398.16 642.27 398.16 687.96 400.4 687.96 400.4 642.27 398.16 642.27 5 L N 413.94 642.27 413.94 688.44 416.19 688.44 416.19 642.27 413.94 642.27 5 L N 429.73 642.27 429.73 687.03 431.97 687.03 431.97 642.27 429.73 642.27 5 L N 445.51 642.27 445.51 686.6 447.75 686.6 447.75 642.27 445.51 642.27 5 L N 368.84 642.27 368.84 687.96 371.15 687.96 371.15 642.27 368.84 642.27 5 Y 6 X V 0 H 0 Z 1 X N 384.62 642.27 384.62 687.96 386.93 687.96 386.93 642.27 384.62 642.27 5 Y 6 X V 1 X N 400.4 642.27 400.4 687.52 402.72 687.52 402.72 642.27 400.4 642.27 5 Y 6 X V 1 X N 416.19 642.27 416.19 688.44 418.5 688.44 418.5 642.27 416.19 642.27 5 Y 6 X V 1 X N 431.97 642.27 431.97 688.44 434.29 688.44 434.29 642.27 431.97 642.27 5 Y 6 X V 1 X N 447.75 642.27 447.75 686.11 450.07 686.11 450.07 642.27 447.75 642.27 5 Y 6 X V 1 X N 368.84 642.27 368.84 687.96 371.15 687.96 371.15 642.27 368.84 642.27 5 L 0.5 H 1 Z 0 X N 384.62 642.27 384.62 687.96 386.93 687.96 386.93 642.27 384.62 642.27 5 L N 400.4 642.27 400.4 687.52 402.72 687.52 402.72 642.27 400.4 642.27 5 L N 416.19 642.27 416.19 688.44 418.5 688.44 418.5 642.27 416.19 642.27 5 L N 431.97 642.27 431.97 688.44 434.29 688.44 434.29 642.27 431.97 642.27 5 L N 447.75 642.27 447.75 686.11 450.07 686.11 450.07 642.27 447.75 642.27 5 L N 371.15 642.27 371.15 642.27 373.47 642.27 373.47 642.27 371.15 642.27 5 Y 0 H 0 Z 1 X N 386.93 642.27 386.93 687.96 389.25 687.96 389.25 642.27 386.93 642.27 5 Y N 402.72 642.27 402.72 687.52 405.03 687.52 405.03 642.27 402.72 642.27 5 Y N 418.5 642.27 418.5 688.44 420.82 688.44 420.82 642.27 418.5 642.27 5 Y N 434.29 642.27 434.29 687.96 436.6 687.96 436.6 642.27 434.29 642.27 5 Y N 450.07 642.27 450.07 686.6 452.38 686.6 452.38 642.27 450.07 642.27 5 Y N 371.15 642.27 373.47 642.27 371.15 642.27 3 L 0.5 H 1 Z 0 X N 386.93 642.27 386.93 687.96 389.25 687.96 389.25 642.27 386.93 642.27 5 L N 402.72 642.27 402.72 687.52 405.03 687.52 405.03 642.27 402.72 642.27 5 L N 418.5 642.27 418.5 688.44 420.82 688.44 420.82 642.27 418.5 642.27 5 L N 434.29 642.27 434.29 687.96 436.6 687.96 436.6 642.27 434.29 642.27 5 L N 450.07 642.27 450.07 686.6 452.38 686.6 452.38 642.27 450.07 642.27 5 L N 486.66 680.84 493.57 680.84 493.57 688.13 486.66 688.13 4 Y V 0 H 0 Z 1 X N 3 8 Q 0 X (1 thread) 497.02 681.71 T 486.66 680.84 493.57 680.84 493.57 688.13 486.66 688.13 486.66 680.84 5 L 0.5 H 1 Z N 486.66 673.55 493.57 673.55 493.57 680.84 486.66 680.84 4 Y 2 X V 0 H 0 Z 1 X N 0 X (2 thread) 497.02 674.42 T 486.66 673.55 493.57 673.55 493.57 680.84 486.66 680.84 486.66 673.55 5 L 0.5 H 1 Z N 486.66 666.26 493.57 666.26 493.57 673.55 486.66 673.55 4 Y 4 X V 0 H 0 Z 1 X N 0 X (4 thread) 497.02 667.14 T 486.66 666.26 493.57 666.26 493.57 673.55 486.66 673.55 486.66 666.26 5 L 0.5 H 1 Z N 486.66 658.97 493.57 658.97 493.57 666.26 486.66 666.26 4 Y 6 X V 0 H 0 Z 1 X N 0 X (6 thread) 497.02 659.85 T 486.66 658.97 493.57 658.97 493.57 666.26 486.66 666.26 486.66 658.97 5 L 0.5 H 1 Z N 486.66 651.68 493.57 651.68 493.57 658.97 486.66 658.97 4 Y 0 H 0 Z 1 X N 0 X (8 thread) 497.02 652.56 T 486.66 651.68 493.57 651.68 493.57 658.97 486.66 658.97 486.66 651.68 5 L 0.5 H 1 Z N 359.79 688.93 456.4 688.93 2 L 1 X N 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 360.52 531.02 544.67 531.02 2 L 0 X N 360.52 531.02 360.52 589.34 2 L N 3 7 Q (LU) 0 -270 369.71 519.44 TF (go) 0 -270 388.09 520.6 TF (fft) 0 -270 406.54 522.55 TF (li) 0 -270 424.92 525.28 TF (perl) 0 -270 443.36 516.72 TF (m88ksim) 0 -270 461.74 500.39 TF (water-) 0 -270 480.19 508.94 TF (water-) 0 -270 498.57 508.94 TF (compress) 0 -270 517.02 498.05 TF (radix) 0 -270 535.4 513.22 TF 360.52 531.02 362.13 531.02 2 L N 360.52 542.68 362.13 542.68 2 L N 360.52 554.35 362.13 554.35 2 L N 360.52 566.01 362.13 566.01 2 L N 360.52 577.67 362.13 577.67 2 L N 360.52 589.34 362.13 589.34 2 L N 360.52 531.02 363.32 531.02 2 L N 360.52 554.35 363.32 554.35 2 L N 3 8 Q (0.0) 344 528.25 T (0.5) 344 551.58 T (1.0) 344 574.9 T (Speedup over speculation) 0 -270 337.09 513.1 TF 4 9 Q (b\051 SPLASH2 and SPEC95 int) 385.78 597.86 T 360.52 577.67 363.32 577.67 2 L N 362.62 531.02 362.62 580.93 365.5 580.93 365.5 531.02 362.62 531.02 5 Y V 0 H 0 Z 1 X N 381.07 531.02 381.07 577.19 383.88 577.19 383.88 531.02 381.07 531.02 5 Y 0 X V 1 X N 399.45 531.02 399.45 580.93 402.33 580.93 402.33 531.02 399.45 531.02 5 Y 0 X V 1 X N 417.9 531.02 417.9 581.37 420.71 581.37 420.71 531.02 417.9 531.02 5 Y 0 X V 1 X N 436.28 531.02 436.28 576.7 439.15 576.7 439.15 531.02 436.28 531.02 5 Y 0 X V 1 X N 454.73 531.02 454.73 578.11 457.53 578.11 457.53 531.02 454.73 531.02 5 Y 0 X V 1 X N 473.11 531.02 473.11 575.78 475.98 575.78 475.98 531.02 473.11 531.02 5 Y 0 X V 1 X N 491.56 531.02 491.56 578.6 494.36 578.6 494.36 531.02 491.56 531.02 5 Y 0 X V 1 X N 509.94 531.02 509.94 581.37 512.81 581.37 512.81 531.02 509.94 531.02 5 Y 0 X V 1 X N 528.39 531.02 528.39 577.67 531.19 577.67 531.19 531.02 528.39 531.02 5 Y 0 X V 1 X N 362.62 531.02 362.62 580.93 365.5 580.93 365.5 531.02 362.62 531.02 5 L 0.5 H 1 Z 0 X N 381.07 531.02 381.07 577.19 383.88 577.19 383.88 531.02 381.07 531.02 5 L N 399.45 531.02 399.45 580.93 402.33 580.93 402.33 531.02 399.45 531.02 5 L N 417.9 531.02 417.9 581.37 420.71 581.37 420.71 531.02 417.9 531.02 5 L N 436.28 531.02 436.28 576.7 439.15 576.7 439.15 531.02 436.28 531.02 5 L N 454.73 531.02 454.73 578.11 457.53 578.11 457.53 531.02 454.73 531.02 5 L N 473.11 531.02 473.11 575.78 475.98 575.78 475.98 531.02 473.11 531.02 5 L N 491.56 531.02 491.56 578.6 494.36 578.6 494.36 531.02 491.56 531.02 5 L N 509.94 531.02 509.94 581.37 512.81 581.37 512.81 531.02 509.94 531.02 5 L N 528.39 531.02 528.39 577.67 531.19 577.67 531.19 531.02 528.39 531.02 5 L N 365.5 531.02 365.5 583.7 368.3 583.7 368.3 531.02 365.5 531.02 5 Y 2 X V 0 H 0 Z 1 X N 383.88 531.02 383.88 579.04 386.68 579.04 386.68 531.02 383.88 531.02 5 Y 2 X V 1 X N 402.33 531.02 402.33 584.67 405.13 584.67 405.13 531.02 402.33 531.02 5 Y 2 X V 1 X N 420.71 531.02 420.71 578.6 423.51 578.6 423.51 531.02 420.71 531.02 5 Y 2 X V 1 X N 439.15 531.02 439.15 577.19 441.96 577.19 441.96 531.02 439.15 531.02 5 Y 2 X V 1 X N 457.53 531.02 457.53 579.52 460.34 579.52 460.34 531.02 457.53 531.02 5 Y 2 X V 1 X N 475.98 531.02 475.98 577.19 478.79 577.19 478.79 531.02 475.98 531.02 5 Y 2 X V 1 X N 494.36 531.02 494.36 580.93 497.17 580.93 497.17 531.02 494.36 531.02 5 Y 2 X V 1 X N 512.81 531.02 512.81 581.85 515.62 581.85 515.62 531.02 512.81 531.02 5 Y 2 X V 1 X N 531.19 531.02 531.19 578.11 534 578.11 534 531.02 531.19 531.02 5 Y 2 X V 1 X N 365.5 531.02 365.5 583.7 368.3 583.7 368.3 531.02 365.5 531.02 5 L 0.5 H 1 Z 0 X N 383.88 531.02 383.88 579.04 386.68 579.04 386.68 531.02 383.88 531.02 5 L N 402.33 531.02 402.33 584.67 405.13 584.67 405.13 531.02 402.33 531.02 5 L N 420.71 531.02 420.71 578.6 423.51 578.6 423.51 531.02 420.71 531.02 5 L N 439.15 531.02 439.15 577.19 441.96 577.19 441.96 531.02 439.15 531.02 5 L N 457.53 531.02 457.53 579.52 460.34 579.52 460.34 531.02 457.53 531.02 5 L N 475.98 531.02 475.98 577.19 478.79 577.19 478.79 531.02 475.98 531.02 5 L N 494.36 531.02 494.36 580.93 497.17 580.93 497.17 531.02 494.36 531.02 5 L N 512.81 531.02 512.81 581.85 515.62 581.85 515.62 531.02 512.81 531.02 5 L N 531.19 531.02 531.19 578.11 534 578.11 534 531.02 531.19 531.02 5 L N 368.3 531.02 368.3 583.7 371.11 583.7 371.11 531.02 368.3 531.02 5 Y 4 X V 0 H 0 Z 1 X N 386.68 531.02 386.68 580.01 389.49 580.01 389.49 531.02 386.68 531.02 5 Y 4 X V 1 X N 405.13 531.02 405.13 586.52 407.94 586.52 407.94 531.02 405.13 531.02 5 Y 4 X V 1 X N 423.51 531.02 423.51 581.85 426.32 581.85 426.32 531.02 423.51 531.02 5 Y 4 X V 1 X N 441.96 531.02 441.96 577.19 444.77 577.19 444.77 531.02 441.96 531.02 5 Y 4 X V 1 X N 460.34 531.02 460.34 579.04 463.15 579.04 463.15 531.02 460.34 531.02 5 Y 4 X V 1 X N 478.79 531.02 478.79 576.7 481.6 576.7 481.6 531.02 478.79 531.02 5 Y 4 X V 1 X N 497.17 531.02 497.17 580.93 499.98 580.93 499.98 531.02 497.17 531.02 5 Y 4 X V 1 X N 515.62 531.02 515.62 581.37 518.42 581.37 518.42 531.02 515.62 531.02 5 Y 4 X V 1 X N 534 531.02 534 578.11 536.8 578.11 536.8 531.02 534 531.02 5 Y 4 X V 1 X N 368.3 531.02 368.3 583.7 371.11 583.7 371.11 531.02 368.3 531.02 5 L 0.5 H 1 Z 0 X N 386.68 531.02 386.68 580.01 389.49 580.01 389.49 531.02 386.68 531.02 5 L N 405.13 531.02 405.13 586.52 407.94 586.52 407.94 531.02 405.13 531.02 5 L N 423.51 531.02 423.51 581.85 426.32 581.85 426.32 531.02 423.51 531.02 5 L N 441.96 531.02 441.96 577.19 444.77 577.19 444.77 531.02 441.96 531.02 5 L N 460.34 531.02 460.34 579.04 463.15 579.04 463.15 531.02 460.34 531.02 5 L N 478.79 531.02 478.79 576.7 481.6 576.7 481.6 531.02 478.79 531.02 5 L N 497.17 531.02 497.17 580.93 499.98 580.93 499.98 531.02 497.17 531.02 5 L N 515.62 531.02 515.62 581.37 518.42 581.37 518.42 531.02 515.62 531.02 5 L N 534 531.02 534 578.11 536.8 578.11 536.8 531.02 534 531.02 5 L N 371.11 531.02 371.11 583.7 373.92 583.7 373.92 531.02 371.11 531.02 5 Y 6 X V 0 H 0 Z 1 X N 389.49 531.02 389.49 580.93 392.3 580.93 392.3 531.02 389.49 531.02 5 Y 6 X V 1 X N 407.94 531.02 407.94 531.02 410.74 531.02 410.74 531.02 407.94 531.02 5 Y 6 X V 1 X N 426.32 531.02 426.32 585.59 429.12 585.59 429.12 531.02 426.32 531.02 5 Y 6 X V 1 X N 444.77 531.02 444.77 578.11 447.57 578.11 447.57 531.02 444.77 531.02 5 Y 6 X V 1 X N 463.15 531.02 463.15 578.11 465.95 578.11 465.95 531.02 463.15 531.02 5 Y 6 X V 1 X N 481.6 531.02 481.6 576.7 484.4 576.7 484.4 531.02 481.6 531.02 5 Y 6 X V 1 X N 499.98 531.02 499.98 580.93 502.78 580.93 502.78 531.02 499.98 531.02 5 Y 6 X V 1 X N 518.42 531.02 518.42 576.27 521.23 576.27 521.23 531.02 518.42 531.02 5 Y 6 X V 1 X N 536.8 531.02 536.8 531.02 539.61 531.02 539.61 531.02 536.8 531.02 5 Y 6 X V 1 X N 371.11 531.02 371.11 583.7 373.92 583.7 373.92 531.02 371.11 531.02 5 L 0.5 H 1 Z 0 X N 389.49 531.02 389.49 580.93 392.3 580.93 392.3 531.02 389.49 531.02 5 L N 407.94 531.02 410.74 531.02 407.94 531.02 3 L N 426.32 531.02 426.32 585.59 429.12 585.59 429.12 531.02 426.32 531.02 5 L N 444.77 531.02 444.77 578.11 447.57 578.11 447.57 531.02 444.77 531.02 5 L N 463.15 531.02 463.15 578.11 465.95 578.11 465.95 531.02 463.15 531.02 5 L N 481.6 531.02 481.6 576.7 484.4 576.7 484.4 531.02 481.6 531.02 5 L N 499.98 531.02 499.98 580.93 502.78 580.93 502.78 531.02 499.98 531.02 5 L N 518.42 531.02 518.42 576.27 521.23 576.27 521.23 531.02 518.42 531.02 5 L N 536.8 531.02 539.61 531.02 536.8 531.02 3 L N 373.92 531.02 373.92 584.67 376.72 584.67 376.72 531.02 373.92 531.02 5 Y 0 H 0 Z 1 X N 392.3 531.02 392.3 580.44 395.17 580.44 395.17 531.02 392.3 531.02 5 Y N 410.74 531.02 410.74 587.93 413.55 587.93 413.55 531.02 410.74 531.02 5 Y N 429.12 531.02 429.12 582.34 432 582.34 432 531.02 429.12 531.02 5 Y N 447.57 531.02 447.57 579.52 450.38 579.52 450.38 531.02 447.57 531.02 5 Y N 465.95 531.02 465.95 578.11 468.83 578.11 468.83 531.02 465.95 531.02 5 Y N 484.4 531.02 484.4 577.19 487.21 577.19 487.21 531.02 484.4 531.02 5 Y N 502.78 531.02 502.78 580.44 505.66 580.44 505.66 531.02 502.78 531.02 5 Y N 521.23 531.02 521.23 579.04 524.04 579.04 524.04 531.02 521.23 531.02 5 Y N 539.61 531.02 539.61 577.67 542.48 577.67 542.48 531.02 539.61 531.02 5 Y N 373.92 531.02 373.92 584.67 376.72 584.67 376.72 531.02 373.92 531.02 5 L 0.5 H 1 Z 0 X N 392.3 531.02 392.3 580.44 395.17 580.44 395.17 531.02 392.3 531.02 5 L N 410.74 531.02 410.74 587.93 413.55 587.93 413.55 531.02 410.74 531.02 5 L N 429.12 531.02 429.12 582.34 432 582.34 432 531.02 429.12 531.02 5 L N 447.57 531.02 447.57 579.52 450.38 579.52 450.38 531.02 447.57 531.02 5 L N 465.95 531.02 465.95 578.11 468.83 578.11 468.83 531.02 465.95 531.02 5 L N 484.4 531.02 484.4 577.19 487.21 577.19 487.21 531.02 484.4 531.02 5 L N 502.78 531.02 502.78 580.44 505.66 580.44 505.66 531.02 502.78 531.02 5 L N 521.23 531.02 521.23 579.04 524.04 579.04 524.04 531.02 521.23 531.02 5 L N 539.61 531.02 539.61 577.67 542.48 577.67 542.48 531.02 539.61 531.02 5 L N 360.52 577.67 544.67 577.67 2 L 1 X N 3 7 Q 0 X (nsquared) 0 -270 487.97 497.21 TF (spatial) 0 -270 507.88 506.57 TF 327.64 435.48 550.97 491.31 R 7 X V 4 10 Q 0 X 1.54 (Figure 4: Speedups of applications executing) 327.64 484.64 P 9.71 (without software speculation over with) 327.64 473.64 P 0.76 (speculation \050speculative execution cycles / no) 327.64 462.64 P 0.5 (speculation execution cycles\051.) 327.64 451.64 P 3 8 Q 0.4 (Bars that are greater) 476.41 451.64 P (than 1.0 indicate that no speculation is better) 327.64 441.98 T (.) 485.96 441.98 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 319.5 431.41 557.79 720 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "7" 7 %%Page: "8" 8 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X (otherwise idle functional units.) 58.5 713.33 T 8.64 (The bottom line is that, while loop-based) 76.5 701.83 P 9.53 (applications should be compiled with software) 58.5 690.33 P 2.92 (speculative execution, non-loop applications should be) 58.5 678.83 P 3.82 (compiled) 58.5 667.33 P 2 F 3.82 (without) 102.04 667.33 P 1 F 3.82 ( it. Doing so either improves SMT) 132.05 667.33 P 3 (program performance or maintains its current level --) 58.5 655.83 P (performance is never hurt.) 58.5 641.67 T 1 8 Q (6) 164.02 645.67 T 0 12 Q (7) 58.5 620.83 T (Loop tiling) 76.5 620.83 T 1 10 Q 2.53 (In order to improve cache behavior, loops can be) 76.5 602.67 P 1.24 (tiled to take advantage of data reuse. In this section, we) 58.5 591.17 P 3.35 (examine two tiling issues: tile size selection and the) 58.5 579.67 P (distribution of tiles to threads.) 58.5 568.17 T 1.07 (If the tile size is chosen appropriately, the reduction) 76.5 556.67 P 1.73 (in average memory access time more than compensates) 58.5 545.17 P 0.42 (for the tiling overhead instructions [20][11][6]. \050The code) 58.5 533.51 P 4.43 (in Figures 6b and 6c illustrates the source of this) 58.5 522.01 P 3.39 (overhead\051. On an SMT, however, tiling may be less) 58.5 510.51 P 9.48 (beneficial. First, SMT\325s enhanced latency-hiding) 58.5 499.01 P 2.34 (capabilities may render tiling unnecessary. Second, the) 58.5 487.51 P 4.97 (additional tiling instructions may increase execution) 58.5 476.01 P 3.41 (time, given SMT\325s higher \050multithreaded\051 throughput.) 58.5 464.51 P 2.8 (\050These are the same factors that influence whether to) 58.5 453.01 P (software speculate.\051) 58.5 441.51 T 1.81 (To address these issues, we examined tileable loop) 76.5 430.01 P 6.14 (nests with different memory access characteristics,) 58.5 418.51 P 2.2 (executing on an SMT processor. The benefits of tiling) 58.5 407.01 P 3.04 (vary when the size of the cache is changed. Smaller) 58.5 395.51 P 2.94 (caches require smaller tiles, which naturally introduce) 58.5 384.01 P 2.52 (more instruction overhead. On the other hand, smaller) 58.5 372.51 P 0.68 (tiles also produce lower average memory latencies -- i.e.,) 58.5 361.01 P 0.42 (fewer conflict misses -- so the latency reducing benefit of) 58.5 349.51 P 1.13 (tiling is better. We therefore varied tile sizes to measure) 58.5 338.01 P 0.45 (the performance impact of a range of tiling overhead. We) 58.5 326.51 P 3.63 (also simulated two memory hierarchies to gauge the) 58.5 315.01 P 1.45 (interaction between cache size, memory latency and tile) 58.5 303.51 P 4.98 (size. The larger memory configuration represents a) 58.5 292.01 P 5.21 (probable SMT memory subsystem for machines in) 58.5 280.51 P 4.19 (production approximately 3 years in the future \050see) 58.5 269.01 P 1.33 (Section 4\051. The other configuration is smaller, modeling) 58.5 257.51 P 0.68 (today\325s memory hierarchies, and is designed to provide a) 58.5 246.01 P 1.65 (more appropriate ratio between data set and cache size,) 58.5 234.51 P 1.23 (modeling loops with larger, i.e., more realistic, data sets) 58.5 223.01 P 2.92 (than those in our benchmarks. For these experiments,) 58.5 211.51 P (each thread was given a separate tile \050the tiling norm\051.) 58.5 200.01 T 2.4 (Figure 5 presents the performance \050total execution) 76.5 188.51 P 5.4 (cycles, average memory access time, and dynamic) 58.5 177.01 P 1.52 (instruction count for a range of tile sizes and the larger) 58.5 165.51 P 1.01 (memory configuration\051 of an 8-thread SMT execution of) 58.5 154.01 P 1.89 (each application and compares it to a single-thread run) 58.5 142.51 P 58.5 123.13 292.5 138.13 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 67.5 136.13 211.5 136.13 2 L 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 1 6.4 Q 0 X 0 0 0 1 0 0 0 K 0.09 (5.) 58.5 118.87 P 1 8 Q 0.12 (Even though it has few \337oating point computations, water) 63.3 115.67 P 0.12 (-spatial had a) 249.61 115.67 P -0.19 (high IPC without speculation \0506.5\051. Therefore the speculative instructions) 58.5 105.67 P 1.45 (bottlenecked the integer units, and execution without speculation was) 58.5 95.67 P (more pro\336table.) 58.5 85.67 T 319.5 81 553.5 720 R 7 X V 1 10 Q 0 X 3.5 (\050approximating execution on a superscalar [13]\051. The) 319.5 412.18 P 0.43 (results indicate that tiling is profitable on an SMT, just as) 319.5 400.68 P 0.43 (it is on conventional processors. Mxm may seem to be an) 319.5 389.18 P 0.35 (exception, since tiling brings no improvement, but it is an) 319.5 377.68 P 2.27 (exception that shows there is no harm in applying the) 319.5 366.18 P 1.69 (optimization. Programs executing on an SMT appear to) 319.5 354.68 P 4.92 (be insensitive to tile size; at almost all tile sizes) 319.5 343.18 P 1.86 (examined, SMT was able to hide memory latencies \050as) 319.5 331.68 P 0.47 (indicated by the flat AMAT curves\051, while still absorbing) 319.5 320.18 P 3.35 (tiling overhead. Therefore SMT is less dependent on) 319.5 308.68 P 4.34 (static algorithms to determine optimal tile sizes for) 319.5 297.18 P 7.71 (particular caches and working sets. In contrast,) 319.5 285.68 P 0.3 (conventional processors are more likely to have a tile size) 319.5 274.18 P 2.99 (sweet spot. Even with out-of-order execution, modern) 319.5 262.68 P 3.41 (processors, as well as alternative single-die processor) 319.5 251.18 P 5.94 (architectures, lack sufficient latency-hiding abilities;) 319.5 239.68 P 8.03 (consequently, they require more exact tile size) 319.5 228.18 P (calculations from the compiler.) 319.5 216.68 T 1.03 (Tile size is also not a performance determinant with) 337.5 205.18 P 5.39 (the less aggressive memory subsystem \050results not) 319.5 193.68 P 2.34 (shown\051, indicating that tiling on SMT is robust across) 319.5 182.18 P 319.5 163.13 553.5 178.13 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 328.5 176.13 472.5 176.13 2 L 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 1 6.4 Q 0 X 0 0 0 1 0 0 0 K -0.06 (6.) 319.5 158.87 P 1 8 Q -0.07 (Keep in mind that had we speculated without run-time support \050the pro-) 324.3 155.67 P 0.62 (\336ling\051, the relative bene\336t of no speculation \050versus speculation\051 would) 319.5 145.67 P 0.36 (have been higher) 319.5 135.67 P 0.36 (. For example, at 8 threads water) 374.42 135.67 P 0.36 (-nsquared breaks even) 481.26 135.67 P 1.67 (with pro\336le-driven speculation; however) 319.5 125.67 P 1.67 (, relying only on Multi\337ow\325) 454.6 125.67 P 1.67 (s) 550.39 125.67 P 2.54 (static branch prediction gives no speculation a slight edge, with a) 319.5 115.67 P 1.56 (speedup of 1.1. Nevertheless, the general conclusions still hold: both) 319.5 105.67 P -0.11 (good branch prediction and low multi-thread IPC are needed for software) 319.5 95.67 P (speculation to bene\336t applications executing on an SMT) 319.5 85.67 T (.) 499.12 85.67 T 305.17 419.54 553.5 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 305.61 419.54 551.78 719.27 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 305.61 407.1 551.78 719.27 R 7 X 0 0 0 1 0 0 0 K V 306.77 423.93 550.29 718.14 R 0.5 H 2 Z 0 X N 312.64 426.47 545.89 481.49 R 7 X V 4 10 Q 0 X 1.91 (Figure 5: T) 312.64 474.83 P 1.91 (iling results with the larger memory) 367.4 474.83 P 6.41 (subsystem and separate tiles/thread.) 312.64 463.49 P 3 8 Q 5.13 (All the) 518.53 463.49 P 0.29 (horizontal axes are tile size. A tile size of 0 means no tiling; sizes) 312.64 454.16 P 1.07 (greater than 0 are one dimension of the tile, measured in array) 312.64 446.16 P 2.87 (elements. The vertical axes are metrics for evaluating tiling:) 312.64 438.16 P (dynamic instruction count, total execution cycles and AMA) 312.64 430.16 T (T) 517.91 430.16 T (.) 521.91 430.16 T 316.62 661.66 316.62 704.85 382.96 704.85 382.96 661.66 316.62 661.66 5 L 1 Z N 316.62 661.66 316.62 662.81 2 L N 319.34 661.66 319.34 662.81 2 L N 322.12 661.66 322.12 662.81 2 L N 324.9 661.66 324.9 662.81 2 L N 327.68 661.66 327.68 662.81 2 L N 330.39 661.66 330.39 662.81 2 L N 333.17 661.66 333.17 662.81 2 L N 335.95 661.66 335.95 662.81 2 L N 338.73 661.66 338.73 662.81 2 L N 341.45 661.66 341.45 662.81 2 L N 344.23 661.66 344.23 662.81 2 L N 347.01 661.66 347.01 662.81 2 L N 349.79 661.66 349.79 662.81 2 L N 352.51 661.66 352.51 662.81 2 L N 355.29 661.66 355.29 662.81 2 L N 358.07 661.66 358.07 662.81 2 L N 360.85 661.66 360.85 662.81 2 L N 363.56 661.66 363.56 662.81 2 L N 366.34 661.66 366.34 662.81 2 L N 369.12 661.66 369.12 662.81 2 L N 371.9 661.66 371.9 662.81 2 L N 374.62 661.66 374.62 662.81 2 L N 377.4 661.66 377.4 662.81 2 L N 380.18 661.66 380.18 662.81 2 L N 382.96 661.66 382.96 662.81 2 L N 316.62 661.66 316.62 662.81 2 L N 330.39 661.66 330.39 662.81 2 L N 344.23 661.66 344.23 662.81 2 L N 358.07 661.66 358.07 662.81 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 315.51 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (5) 329.28 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 342.01 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (15) 355.84 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 369.68 656.72 T 0 0 0 1 0 0 0 K 371.9 661.66 371.9 662.81 2 L N 316.62 661.66 317 661.66 2 L 1 X N 316.62 670.29 317 670.29 2 L N 316.62 678.93 317 678.93 2 L N 316.62 687.5 317 687.5 2 L N 316.62 696.14 317 696.14 2 L N 316.62 704.85 317 704.85 2 L N 382.96 661.66 382.58 661.66 2 L N 382.96 670.29 382.58 670.29 2 L N 382.96 678.93 382.58 678.93 2 L N 382.96 687.5 382.58 687.5 2 L N 382.96 696.14 382.58 696.14 2 L N 382.96 704.85 382.58 704.85 2 L N 316.62 661.66 317.38 661.66 2 L N 316.62 670.29 317.38 670.29 2 L N 316.62 678.93 317.38 678.93 2 L N 316.62 687.5 317.38 687.5 2 L N 316.62 696.14 317.38 696.14 2 L N 316.62 704.85 317.38 704.85 2 L N 382.96 661.66 382.2 661.66 2 L N 382.96 670.29 382.2 670.29 2 L N 382.96 678.93 382.2 678.93 2 L N 382.96 687.5 382.2 687.5 2 L N 382.96 696.14 382.2 696.14 2 L N 382.96 704.85 382.2 704.85 2 L N 0 F 0 X (0) 312.22 660.32 T (10) 310.22 668.96 T (20) 310.22 677.6 T (30) 310.22 686.17 T (40) 310.22 694.81 T (50) 310.22 703.52 T 3 7 Q (mxm) 341.68 709.57 T 316.62 686.35 324.9 699.46 327.68 694.27 330.39 692.61 338.73 689.16 347.01 688.15 349.79 688.15 360.85 687.29 363.56 687.29 382.96 687.21 10 L N 315.1 686.35 318.14 686.35 2 L N 316.62 688.08 316.62 684.62 2 L N 315.61 685.2 317.63 687.5 2 L N 315.61 687.5 317.63 685.2 2 L N 323.38 699.46 326.41 699.46 2 L N 324.9 701.18 324.9 697.73 2 L N 323.89 698.3 325.91 700.61 2 L N 323.89 700.61 325.91 698.3 2 L N 326.16 694.27 329.19 694.27 2 L N 327.68 696 327.68 692.54 2 L N 326.67 693.12 328.69 695.42 2 L N 326.67 695.42 328.69 693.12 2 L N 328.88 692.61 331.91 692.61 2 L N 330.39 694.34 330.39 690.89 2 L N 329.38 691.46 331.4 693.77 2 L N 329.38 693.77 331.4 691.46 2 L N 337.22 689.16 340.25 689.16 2 L N 338.73 690.89 338.73 687.43 2 L N 337.72 688.01 339.74 690.31 2 L N 337.72 690.31 339.74 688.01 2 L N 345.49 688.15 348.53 688.15 2 L N 347.01 689.88 347.01 686.42 2 L N 346 687 348.02 689.3 2 L N 346 689.3 348.02 687 2 L N 348.27 688.15 351.31 688.15 2 L N 349.79 689.88 349.79 686.42 2 L N 348.78 687 350.8 689.3 2 L N 348.78 689.3 350.8 687 2 L N 359.33 687.29 362.36 687.29 2 L N 360.85 689.02 360.85 685.56 2 L N 359.84 686.14 361.86 688.44 2 L N 359.84 688.44 361.86 686.14 2 L N 362.05 687.29 365.08 687.29 2 L N 363.56 689.02 363.56 685.56 2 L N 362.55 686.14 364.57 688.44 2 L N 362.55 688.44 364.57 686.14 2 L N 381.44 687.21 384.48 687.21 2 L N 382.96 688.94 382.96 685.49 2 L N 381.95 686.06 383.97 688.37 2 L N 381.95 688.37 383.97 686.06 2 L N 385.79 648.82 395.59 648.82 2 L N 384.07 648.82 387.52 648.82 2 L N 385.79 650.55 385.79 647.09 2 L N 384.64 647.67 386.95 649.97 2 L N 384.64 649.97 386.95 647.67 2 L N 393.86 648.82 397.31 648.82 2 L N 395.59 650.55 395.59 647.09 2 L N 394.43 647.67 396.74 649.97 2 L N 0 6 Q (Dynamic instruction count in millions) 398.03 647.49 T 394.43 649.97 396.74 647.67 2 L N 316.62 585.16 316.62 628.35 382.96 628.35 382.96 585.16 316.62 585.16 316.62 586.31 6 L N 319.34 585.16 319.34 586.31 2 L N 322.12 585.16 322.12 586.31 2 L N 324.9 585.16 324.9 586.31 2 L N 327.68 585.16 327.68 586.31 2 L N 330.39 585.16 330.39 586.31 2 L N 333.17 585.16 333.17 586.31 2 L N 335.95 585.16 335.95 586.31 2 L N 338.73 585.16 338.73 586.31 2 L N 341.45 585.16 341.45 586.31 2 L N 344.23 585.16 344.23 586.31 2 L N 347.01 585.16 347.01 586.31 2 L N 349.79 585.16 349.79 586.31 2 L N 352.51 585.16 352.51 586.31 2 L N 355.29 585.16 355.29 586.31 2 L N 358.07 585.16 358.07 586.31 2 L N 360.85 585.16 360.85 586.31 2 L N 363.56 585.16 363.56 586.31 2 L N 366.34 585.16 366.34 586.31 2 L N 369.12 585.16 369.12 586.31 2 L N 371.9 585.16 371.9 586.31 2 L N 374.62 585.16 374.62 586.31 2 L N 377.4 585.16 377.4 586.31 2 L N 380.18 585.16 380.18 586.31 2 L N 382.96 585.16 382.96 586.31 2 L N 316.62 585.16 316.62 586.31 2 L N 330.39 585.16 330.39 586.31 2 L N 344.23 585.16 344.23 586.31 2 L N 358.07 585.16 358.07 586.31 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 315.51 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (5) 329.28 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 342.01 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (15) 355.84 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 369.68 580.22 T 0 0 0 1 0 0 0 K 371.9 585.16 371.9 586.31 2 L N 316.62 585.16 317 585.16 2 L 1 X N 316.62 593.79 317 593.79 2 L N 316.62 602.43 317 602.43 2 L N 316.62 611.08 317 611.08 2 L N 316.62 619.71 317 619.71 2 L N 316.62 628.35 317 628.35 2 L N 382.96 585.16 382.58 585.16 2 L N 382.96 593.79 382.58 593.79 2 L N 382.96 602.43 382.58 602.43 2 L N 382.96 611.08 382.58 611.08 2 L N 382.96 619.71 382.58 619.71 2 L N 382.96 628.35 382.58 628.35 2 L N 316.62 585.16 317.38 585.16 2 L N 316.62 602.43 317.38 602.43 2 L N 316.62 619.71 317.38 619.71 2 L N 382.96 585.16 382.2 585.16 2 L N 382.96 602.43 382.2 602.43 2 L N 382.96 619.71 382.2 619.71 2 L N 0 F 0 X (0) 312.22 583.82 T (10) 310.22 601.1 T (20) 310.22 618.38 T 3 7 Q (8 threads) 334.67 633.07 T 316.62 593.58 324.9 597.4 327.68 595.38 330.39 594.88 338.73 593.72 347.01 593.36 349.79 593.51 360.85 593.22 363.56 593.22 382.96 593.65 10 L N 0 Z 90 450 1.52 1.73 316.62 593.58 A 90 450 1.52 1.73 324.9 597.4 A 90 450 1.52 1.73 327.68 595.38 A 90 450 1.52 1.73 330.39 594.88 A 90 450 1.52 1.73 338.73 593.72 A 90 450 1.52 1.73 347.01 593.36 A 90 450 1.52 1.73 349.79 593.51 A 90 450 1.52 1.73 360.85 593.22 A 90 450 1.52 1.73 363.56 593.22 A 90 450 1.52 1.73 382.96 593.65 A 316.62 588.25 324.9 586.31 327.68 586.31 330.39 586.31 338.73 586.31 347.01 586.52 349.79 586.52 360.85 586.67 363.56 586.67 382.96 587.75 10 L 1 Z N 315.1 589.98 316.62 586.52 318.14 589.98 315.1 589.98 4 L N 323.38 588.04 324.9 584.58 326.41 588.04 323.38 588.04 4 L N 326.16 588.04 327.68 584.58 329.19 588.04 326.16 588.04 4 L N 328.88 588.04 330.39 584.58 331.91 588.04 328.88 588.04 4 L N 337.22 588.04 338.73 584.58 340.25 588.04 337.22 588.04 4 L N 345.49 588.25 347.01 584.79 348.53 588.25 345.49 588.25 4 L N 348.27 588.25 349.79 584.79 351.31 588.25 348.27 588.25 4 L N 359.33 588.4 360.85 584.94 362.36 588.4 359.33 588.4 4 L N 362.05 588.4 363.56 584.94 365.08 588.4 362.05 588.4 4 L N 381.44 589.47 382.96 586.02 384.48 589.47 381.44 589.47 4 L N 385.79 574.22 395.59 574.22 2 L N 0 Z 90 450 1.73 1.73 385.79 574.22 A 90 450 1.73 1.73 395.59 574.22 A 0 6 Q (Total execution cycles in millions) 398.03 572.89 T 385.79 568.89 395.59 568.89 2 L 1 Z N 384.07 570.62 385.79 567.17 387.52 570.62 384.07 570.62 4 L N (Average memory access time in cycles \050AMAT\051) 398.03 567.56 T 393.86 570.62 395.59 567.17 397.31 570.62 393.86 570.62 4 L N 316.62 503.26 316.62 546.46 382.96 546.46 382.96 503.26 316.62 503.26 316.62 504.41 6 L N 319.34 503.26 319.34 504.41 2 L N 322.12 503.26 322.12 504.41 2 L N 324.9 503.26 324.9 504.41 2 L N 327.68 503.26 327.68 504.41 2 L N 330.39 503.26 330.39 504.41 2 L N 333.17 503.26 333.17 504.41 2 L N 335.95 503.26 335.95 504.41 2 L N 338.73 503.26 338.73 504.41 2 L N 341.45 503.26 341.45 504.41 2 L N 344.23 503.26 344.23 504.41 2 L N 347.01 503.26 347.01 504.41 2 L N 349.79 503.26 349.79 504.41 2 L N 352.51 503.26 352.51 504.41 2 L N 355.29 503.26 355.29 504.41 2 L N 358.07 503.26 358.07 504.41 2 L N 360.85 503.26 360.85 504.41 2 L N 363.56 503.26 363.56 504.41 2 L N 366.34 503.26 366.34 504.41 2 L N 369.12 503.26 369.12 504.41 2 L N 371.9 503.26 371.9 504.41 2 L N 374.62 503.26 374.62 504.41 2 L N 377.4 503.26 377.4 504.41 2 L N 380.18 503.26 380.18 504.41 2 L N 382.96 503.26 382.96 504.41 2 L N 316.62 503.26 316.62 504.41 2 L N 330.39 503.26 330.39 504.41 2 L N 344.23 503.26 344.23 504.41 2 L N 358.07 503.26 358.07 504.41 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 315.51 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (5) 329.28 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 342.01 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (15) 355.84 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 369.68 498.32 T 0 0 0 1 0 0 0 K 371.9 503.26 371.9 504.41 2 L N 316.62 503.26 317 503.26 2 L 1 X N 316.62 511.89 317 511.89 2 L N 316.62 520.54 317 520.54 2 L N 316.62 529.17 317 529.17 2 L N 316.62 537.82 317 537.82 2 L N 316.62 546.46 317 546.46 2 L N 382.96 503.26 382.58 503.26 2 L N 382.96 511.89 382.58 511.89 2 L N 382.96 520.54 382.58 520.54 2 L N 382.96 529.17 382.58 529.17 2 L N 382.96 537.82 382.58 537.82 2 L N 382.96 546.46 382.58 546.46 2 L N 316.62 503.26 317.38 503.26 2 L N 316.62 520.54 317.38 520.54 2 L N 316.62 537.82 317.38 537.82 2 L N 382.96 503.26 382.2 503.26 2 L N 382.96 520.54 382.2 520.54 2 L N 382.96 537.82 382.2 537.82 2 L N 0 F 0 X (0) 312.22 501.92 T (10) 310.22 519.2 T (20) 310.22 536.48 T 3 7 Q (1 thread) 336.42 551.17 T 316.62 531.12 324.9 525.58 327.68 524.06 330.39 523.56 338.73 523.27 347.01 524.71 349.79 524.85 360.85 526.22 363.56 526.73 382.96 528.89 10 L N 0 Z 90 450 1.52 1.73 316.62 531.12 A 90 450 1.52 1.73 324.9 525.58 A 90 450 1.52 1.73 327.68 524.06 A 90 450 1.52 1.73 330.39 523.56 A 90 450 1.52 1.73 338.73 523.27 A 90 450 1.52 1.73 347.01 524.71 A 90 450 1.52 1.73 349.79 524.85 A 90 450 1.52 1.73 360.85 526.22 A 90 450 1.52 1.73 363.56 526.73 A 90 450 1.52 1.73 382.96 528.89 A 316.62 516.86 324.9 505.27 327.68 505.13 330.39 504.41 338.73 503.9 347.01 503.9 349.79 503.9 360.85 503.9 363.56 504.98 382.96 514.13 10 L 1 Z N 315.1 518.59 316.62 515.14 318.14 518.59 315.1 518.59 4 L N 323.38 507 324.9 503.54 326.41 507 323.38 507 4 L N 326.16 506.86 327.68 503.4 329.19 506.86 326.16 506.86 4 L N 328.88 506.14 330.39 502.68 331.91 506.14 328.88 506.14 4 L N 337.22 505.63 338.73 502.17 340.25 505.63 337.22 505.63 4 L N 345.49 505.63 347.01 502.17 348.53 505.63 345.49 505.63 4 L N 348.27 505.63 349.79 502.17 351.31 505.63 348.27 505.63 4 L N 359.33 505.63 360.85 502.17 362.36 505.63 359.33 505.63 4 L N 362.05 506.71 363.56 503.26 365.08 506.71 362.05 506.71 4 L N 381.44 515.85 382.96 512.4 384.48 515.85 381.44 515.85 4 L N 385.79 493.3 395.59 493.3 2 L N 0 Z 90 450 1.73 1.73 385.79 493.3 A 90 450 1.73 1.73 395.59 493.3 A 0 6 Q (Total execution cycles in millions) 398.03 491.97 T 385.79 487.97 395.59 487.97 2 L 1 Z N 384.07 489.7 385.79 486.24 387.52 489.7 384.07 489.7 4 L N (Average memory access time in cycles \050AMAT\051) 398.03 486.64 T 393.86 489.7 395.59 486.24 397.31 489.7 393.86 489.7 4 L N 399.63 661.66 399.63 704.85 465.36 704.85 465.36 661.66 399.63 661.66 5 L N 399.63 661.66 399.63 662.81 2 L N 407.83 661.66 407.83 662.81 2 L N 416.03 661.66 416.03 662.81 2 L N 424.23 661.66 424.23 662.81 2 L N 432.49 661.66 432.49 662.81 2 L N 440.69 661.66 440.69 662.81 2 L N 448.89 661.66 448.89 662.81 2 L N 457.09 661.66 457.09 662.81 2 L N 465.36 661.66 465.36 662.81 2 L N 399.63 661.66 399.63 662.81 2 L N 416.03 661.66 416.03 662.81 2 L N 432.49 661.66 432.49 662.81 2 L N 448.89 661.66 448.89 662.81 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 398.52 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 413.81 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 430.27 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 446.67 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 463.13 656.72 T 0 0 0 1 0 0 0 K 465.36 661.66 465.36 662.81 2 L N 399.63 661.66 400.01 661.66 2 L 1 X N 399.63 670.29 400.01 670.29 2 L N 399.63 678.93 400.01 678.93 2 L N 399.63 687.5 400.01 687.5 2 L N 399.63 696.14 400.01 696.14 2 L N 399.63 704.85 400.01 704.85 2 L N 465.36 661.66 464.98 661.66 2 L N 465.36 670.29 464.98 670.29 2 L N 465.36 678.93 464.98 678.93 2 L N 465.36 687.5 464.98 687.5 2 L N 465.36 696.14 464.98 696.14 2 L N 465.36 704.85 464.98 704.85 2 L N 399.63 661.66 400.38 661.66 2 L N 399.63 670.29 400.38 670.29 2 L N 399.63 678.93 400.38 678.93 2 L N 399.63 687.5 400.38 687.5 2 L N 399.63 696.14 400.38 696.14 2 L N 399.63 704.85 400.38 704.85 2 L N 465.36 661.66 464.61 661.66 2 L N 465.36 670.29 464.61 670.29 2 L N 465.36 678.93 464.61 678.93 2 L N 465.36 687.5 464.61 687.5 2 L N 465.36 696.14 464.61 696.14 2 L N 465.36 704.85 464.61 704.85 2 L N 0 F 0 X (0) 395.25 660.32 T (10) 393.25 668.96 T (20) 393.25 677.6 T (30) 393.25 686.17 T (40) 393.25 694.81 T (50) 393.25 703.52 T 3 7 Q (adi) 420.87 709.57 T 399.63 675.05 417.66 678.29 419.35 677.14 425.92 676.56 427.55 677.35 432.49 676.2 439.07 675.98 440.69 676.56 458.78 675.62 460.41 676.05 10 L N 398.13 675.05 401.13 675.05 2 L N 399.63 676.78 399.63 673.32 2 L N 398.63 673.9 400.63 676.2 2 L N 398.63 676.2 400.63 673.9 2 L N 416.15 678.29 419.16 678.29 2 L N 417.66 680.02 417.66 676.56 2 L N 416.66 677.14 418.66 679.44 2 L N 416.66 679.44 418.66 677.14 2 L N 417.85 677.14 420.85 677.14 2 L N 419.35 678.86 419.35 675.41 2 L N 418.35 675.98 420.35 678.29 2 L N 418.35 678.29 420.35 675.98 2 L N 424.42 676.56 427.42 676.56 2 L N 425.92 678.29 425.92 674.83 2 L N 424.92 675.41 426.92 677.71 2 L N 424.92 677.71 426.92 675.41 2 L N 426.05 677.35 429.05 677.35 2 L N 427.55 679.08 427.55 675.62 2 L N 426.55 676.2 428.55 678.5 2 L N 426.55 678.5 428.55 676.2 2 L N 430.99 676.2 434 676.2 2 L N 432.49 677.93 432.49 674.47 2 L N 431.49 675.05 433.49 677.35 2 L N 431.49 677.35 433.49 675.05 2 L N 437.56 675.98 440.57 675.98 2 L N 439.07 677.71 439.07 674.26 2 L N 438.07 674.83 440.07 677.14 2 L N 438.07 677.14 440.07 674.83 2 L N 439.19 676.56 442.2 676.56 2 L N 440.69 678.29 440.69 674.83 2 L N 439.69 675.41 441.7 677.71 2 L N 439.69 677.71 441.7 675.41 2 L N 457.28 675.62 460.29 675.62 2 L N 458.78 677.35 458.78 673.9 2 L N 457.78 674.47 459.79 676.78 2 L N 457.78 676.78 459.79 674.47 2 L N 458.91 676.05 461.91 676.05 2 L N 460.41 677.78 460.41 674.33 2 L N 459.41 674.9 461.41 677.21 2 L N 459.41 677.21 461.41 674.9 2 L N 399.63 585.16 399.63 628.35 465.36 628.35 465.36 585.16 399.63 585.16 399.63 586.31 6 L N 407.83 585.16 407.83 586.31 2 L N 416.03 585.16 416.03 586.31 2 L N 424.23 585.16 424.23 586.31 2 L N 432.49 585.16 432.49 586.31 2 L N 440.69 585.16 440.69 586.31 2 L N 448.89 585.16 448.89 586.31 2 L N 457.09 585.16 457.09 586.31 2 L N 465.36 585.16 465.36 586.31 2 L N 399.63 585.16 399.63 586.31 2 L N 416.03 585.16 416.03 586.31 2 L N 432.49 585.16 432.49 586.31 2 L N 448.89 585.16 448.89 586.31 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 398.52 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 413.81 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 430.27 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 446.67 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 463.13 580.22 T 0 0 0 1 0 0 0 K 465.36 585.16 465.36 586.31 2 L N 399.63 585.16 400.01 585.16 2 L 1 X N 399.63 589.47 400.01 589.47 2 L N 399.63 593.79 400.01 593.79 2 L N 399.63 598.11 400.01 598.11 2 L N 399.63 602.43 400.01 602.43 2 L N 399.63 606.76 400.01 606.76 2 L N 399.63 611.08 400.01 611.08 2 L N 399.63 615.4 400.01 615.4 2 L N 399.63 619.71 400.01 619.71 2 L N 399.63 624.04 400.01 624.04 2 L N 399.63 628.35 400.01 628.35 2 L N 465.36 585.16 464.98 585.16 2 L N 465.36 589.47 464.98 589.47 2 L N 465.36 593.79 464.98 593.79 2 L N 465.36 598.11 464.98 598.11 2 L N 465.36 602.43 464.98 602.43 2 L N 465.36 606.76 464.98 606.76 2 L N 465.36 611.08 464.98 611.08 2 L N 465.36 615.4 464.98 615.4 2 L N 465.36 619.71 464.98 619.71 2 L N 465.36 624.04 464.98 624.04 2 L N 465.36 628.35 464.98 628.35 2 L N 399.63 585.16 400.38 585.16 2 L N 399.63 593.79 400.38 593.79 2 L N 399.63 602.43 400.38 602.43 2 L N 399.63 611.08 400.38 611.08 2 L N 399.63 619.71 400.38 619.71 2 L N 399.63 628.35 400.38 628.35 2 L N 465.36 585.16 464.61 585.16 2 L N 465.36 593.79 464.61 593.79 2 L N 465.36 602.43 464.61 602.43 2 L N 465.36 611.08 464.61 611.08 2 L N 465.36 619.71 464.61 619.71 2 L N 465.36 628.35 464.61 628.35 2 L N 0 F 0 X (0) 395.25 583.82 T (10) 393.25 592.46 T (20) 393.25 601.1 T (30) 393.25 609.74 T (40) 393.25 618.38 T (50) 393.25 627.02 T 3 7 Q (8 threads) 410.94 633.07 T 399.63 608.7 417.66 590.63 419.35 590.63 425.92 590.48 427.55 590.41 432.49 590.41 439.07 590.27 440.69 590.27 458.78 590.2 460.41 590.2 10 L N 0 Z 90 450 1.5 1.73 399.63 608.7 A 90 450 1.5 1.73 417.66 590.63 A 90 450 1.5 1.73 419.35 590.63 A 90 450 1.5 1.73 425.92 590.48 A 90 450 1.5 1.73 427.55 590.41 A 90 450 1.5 1.73 432.49 590.41 A 90 450 1.5 1.73 439.07 590.27 A 90 450 1.5 1.73 440.69 590.27 A 90 450 1.5 1.73 458.78 590.2 A 90 450 1.5 1.73 460.41 590.2 A 399.63 618.99 417.66 595.38 419.35 596.03 425.92 594.44 427.55 594.23 432.49 594.01 439.07 593.22 440.69 593.15 458.78 592.35 460.41 592.35 10 L 1 Z N 398.13 620.72 399.63 617.27 401.13 620.72 398.13 620.72 4 L N 416.15 597.11 417.66 593.65 419.16 597.11 416.15 597.11 4 L N 417.85 597.76 419.35 594.3 420.85 597.76 417.85 597.76 4 L N 424.42 596.17 425.92 592.71 427.42 596.17 424.42 596.17 4 L N 426.05 595.96 427.55 592.5 429.05 595.96 426.05 595.96 4 L N 430.99 595.74 432.49 592.28 434 595.74 430.99 595.74 4 L N 437.56 594.95 439.07 591.49 440.57 594.95 437.56 594.95 4 L N 439.19 594.88 440.69 591.42 442.2 594.88 439.19 594.88 4 L N 457.28 594.08 458.78 590.63 460.29 594.08 457.28 594.08 4 L N 458.91 594.08 460.41 590.63 461.91 594.08 458.91 594.08 4 L N 399.63 503.26 399.63 546.46 465.36 546.46 465.36 503.26 399.63 503.26 399.63 504.41 6 L N 407.83 503.26 407.83 504.41 2 L N 416.03 503.26 416.03 504.41 2 L N 424.23 503.26 424.23 504.41 2 L N 432.49 503.26 432.49 504.41 2 L N 440.69 503.26 440.69 504.41 2 L N 448.89 503.26 448.89 504.41 2 L N 457.09 503.26 457.09 504.41 2 L N 465.36 503.26 465.36 504.41 2 L N 399.63 503.26 399.63 504.41 2 L N 416.03 503.26 416.03 504.41 2 L N 432.49 503.26 432.49 504.41 2 L N 448.89 503.26 448.89 504.41 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 398.52 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 413.81 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 430.27 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 446.67 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 463.13 498.32 T 0 0 0 1 0 0 0 K 465.36 503.26 465.36 504.41 2 L N 399.63 503.26 400.01 503.26 2 L 1 X N 399.63 507.58 400.01 507.58 2 L N 399.63 511.89 400.01 511.89 2 L N 399.63 516.21 400.01 516.21 2 L N 399.63 520.54 400.01 520.54 2 L N 399.63 524.85 400.01 524.85 2 L N 399.63 529.17 400.01 529.17 2 L N 399.63 533.42 400.01 533.42 2 L N 399.63 537.82 400.01 537.82 2 L N 399.63 542.14 400.01 542.14 2 L N 399.63 546.46 400.01 546.46 2 L N 465.36 503.26 464.98 503.26 2 L N 465.36 507.58 464.98 507.58 2 L N 465.36 511.89 464.98 511.89 2 L N 465.36 516.21 464.98 516.21 2 L N 465.36 520.54 464.98 520.54 2 L N 465.36 524.85 464.98 524.85 2 L N 465.36 529.17 464.98 529.17 2 L N 465.36 533.42 464.98 533.42 2 L N 465.36 537.82 464.98 537.82 2 L N 465.36 542.14 464.98 542.14 2 L N 465.36 546.46 464.98 546.46 2 L N 399.63 503.26 400.38 503.26 2 L N 399.63 511.89 400.38 511.89 2 L N 399.63 520.54 400.38 520.54 2 L N 399.63 529.17 400.38 529.17 2 L N 399.63 537.82 400.38 537.82 2 L N 399.63 546.46 400.38 546.46 2 L N 465.36 503.26 464.61 503.26 2 L N 465.36 511.89 464.61 511.89 2 L N 465.36 520.54 464.61 520.54 2 L N 465.36 529.17 464.61 529.17 2 L N 465.36 537.82 464.61 537.82 2 L N 465.36 546.46 464.61 546.46 2 L N 0 F 0 X (0) 395.25 501.92 T (10) 393.25 510.56 T (20) 393.25 519.2 T (30) 393.25 527.84 T (40) 393.25 536.48 T (50) 393.25 545.12 T 3 7 Q (1 thread) 412.69 551.17 T 413.28 546.46 417.66 525.79 419.35 524.49 425.92 527.38 427.55 530.33 432.49 529.39 439.07 538.61 440.69 537.74 458.78 533.14 460.41 534.65 10 L N 0 Z 90 450 1.5 1.73 417.66 525.79 A 90 450 1.5 1.73 419.35 524.49 A 90 450 1.5 1.73 425.92 527.38 A 90 450 1.5 1.73 427.55 530.33 A 90 450 1.5 1.73 432.49 529.39 A 90 450 1.5 1.73 439.07 538.61 A 90 450 1.5 1.73 440.69 537.74 A 90 450 1.5 1.73 458.78 533.14 A 90 450 1.5 1.73 460.41 534.65 A 402.57 546.46 417.66 517.8 419.35 517.94 425.92 515.06 427.55 514.49 432.49 513.62 439.07 512.47 440.69 512.11 458.78 510.74 460.41 510.45 10 L 1 Z N 416.15 519.53 417.66 516.07 419.16 519.53 416.15 519.53 4 L N 417.85 519.67 419.35 516.21 420.85 519.67 417.85 519.67 4 L N 424.42 516.79 425.92 513.33 427.42 516.79 424.42 516.79 4 L N 426.05 516.21 427.55 512.76 429.05 516.21 426.05 516.21 4 L N 430.99 515.35 432.49 511.89 434 515.35 430.99 515.35 4 L N 437.56 514.2 439.07 510.74 440.57 514.2 437.56 514.2 4 L N 439.19 513.84 440.69 510.38 442.2 513.84 439.19 513.84 4 L N 457.28 512.47 458.78 509.02 460.29 512.47 457.28 512.47 4 L N 458.91 512.18 460.41 508.73 461.91 512.18 458.91 512.18 4 L N 480.61 661.66 480.61 704.85 545.13 704.85 545.13 661.66 480.61 661.66 5 L N 480.61 661.66 480.61 662.81 2 L N 485.65 661.66 485.65 662.81 2 L N 490.69 661.66 490.69 662.81 2 L N 495.73 661.66 495.73 662.81 2 L N 500.76 661.66 500.76 662.81 2 L N 505.8 661.66 505.8 662.81 2 L N 510.84 661.66 510.84 662.81 2 L N 515.88 661.66 515.88 662.81 2 L N 520.92 661.66 520.92 662.81 2 L N 525.96 661.66 525.96 662.81 2 L N 530.99 661.66 530.99 662.81 2 L N 536.03 661.66 536.03 662.81 2 L N 541.07 661.66 541.07 662.81 2 L N 480.61 661.66 480.61 662.81 2 L N 490.69 661.66 490.69 662.81 2 L N 500.76 661.66 500.76 662.81 2 L N 510.84 661.66 510.84 662.81 2 L N 520.92 661.66 520.92 662.81 2 L N 530.99 661.66 530.99 662.81 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 479.5 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 488.46 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 498.54 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 508.62 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 518.69 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (50) 528.77 656.72 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (60) 538.85 656.72 T 0 0 0 1 0 0 0 K 541.07 661.66 541.07 662.81 2 L N 480.61 661.66 480.98 661.66 2 L 1 X N 480.61 665.9 480.98 665.9 2 L N 480.61 670.29 480.98 670.29 2 L N 480.61 674.61 480.98 674.61 2 L N 480.61 678.93 480.98 678.93 2 L N 480.61 683.26 480.98 683.26 2 L N 480.61 687.5 480.98 687.5 2 L N 480.61 691.9 480.98 691.9 2 L N 480.61 696.14 480.98 696.14 2 L N 480.61 700.54 480.98 700.54 2 L N 480.61 704.85 480.98 704.85 2 L N 545.13 661.66 544.76 661.66 2 L N 545.13 665.9 544.76 665.9 2 L N 545.13 670.29 544.76 670.29 2 L N 545.13 674.61 544.76 674.61 2 L N 545.13 678.93 544.76 678.93 2 L N 545.13 683.26 544.76 683.26 2 L N 545.13 687.5 544.76 687.5 2 L N 545.13 691.9 544.76 691.9 2 L N 545.13 696.14 544.76 696.14 2 L N 545.13 700.54 544.76 700.54 2 L N 545.13 704.85 544.76 704.85 2 L N 480.61 661.66 481.35 661.66 2 L N 480.61 670.29 481.35 670.29 2 L N 480.61 678.93 481.35 678.93 2 L N 480.61 687.5 481.35 687.5 2 L N 480.61 696.14 481.35 696.14 2 L N 480.61 704.85 481.35 704.85 2 L N 545.13 661.66 544.39 661.66 2 L N 545.13 670.29 544.39 670.29 2 L N 545.13 678.93 544.39 678.93 2 L N 545.13 687.5 544.39 687.5 2 L N 545.13 696.14 544.39 696.14 2 L N 545.13 704.85 544.39 704.85 2 L N 0 F 0 X (0) 476.27 660.32 T (100) 472.27 668.96 T (200) 472.27 677.6 T (300) 472.27 686.17 T (400) 472.27 694.81 T (500) 472.27 703.52 T 3 7 Q (gmt) 504.05 709.57 T 480.61 692.26 492.65 698.95 499.72 701.33 509.8 696.07 524.91 693.91 545.13 693.41 6 L N 479.13 692.26 482.08 692.26 2 L N 480.61 693.98 480.61 690.53 2 L N 479.63 691.1 481.59 693.41 2 L N 479.63 693.41 481.59 691.1 2 L N 491.18 698.95 494.13 698.95 2 L N 492.65 700.68 492.65 697.22 2 L N 491.67 697.8 493.64 700.1 2 L N 491.67 700.1 493.64 697.8 2 L N 498.24 701.33 501.19 701.33 2 L N 499.72 703.05 499.72 699.6 2 L N 498.74 700.17 500.7 702.48 2 L N 498.74 702.48 500.7 700.17 2 L N 508.32 696.07 511.27 696.07 2 L N 509.8 697.8 509.8 694.34 2 L N 508.81 694.92 510.78 697.22 2 L N 508.81 697.22 510.78 694.92 2 L N 523.44 693.91 526.39 693.91 2 L N 524.91 695.64 524.91 692.18 2 L N 523.93 692.76 525.9 695.06 2 L N 523.93 695.06 525.9 692.76 2 L N 543.65 693.41 546.6 693.41 2 L N 545.13 695.14 545.13 691.68 2 L N 544.15 692.26 546.11 694.56 2 L N 544.15 694.56 546.11 692.26 2 L N 480.61 585.16 480.61 628.35 545.13 628.35 545.13 585.16 480.61 585.16 480.61 586.31 6 L N 485.65 585.16 485.65 586.31 2 L N 490.69 585.16 490.69 586.31 2 L N 495.73 585.16 495.73 586.31 2 L N 500.76 585.16 500.76 586.31 2 L N 505.8 585.16 505.8 586.31 2 L N 510.84 585.16 510.84 586.31 2 L N 515.88 585.16 515.88 586.31 2 L N 520.92 585.16 520.92 586.31 2 L N 525.96 585.16 525.96 586.31 2 L N 530.99 585.16 530.99 586.31 2 L N 536.03 585.16 536.03 586.31 2 L N 541.07 585.16 541.07 586.31 2 L N 480.61 585.16 480.61 586.31 2 L N 490.69 585.16 490.69 586.31 2 L N 500.76 585.16 500.76 586.31 2 L N 510.84 585.16 510.84 586.31 2 L N 520.92 585.16 520.92 586.31 2 L N 530.99 585.16 530.99 586.31 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 479.5 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 488.46 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 498.54 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 508.62 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 518.69 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (50) 528.77 580.22 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (60) 538.85 580.22 T 0 0 0 1 0 0 0 K 541.07 585.16 541.07 586.31 2 L N 480.61 585.16 480.98 585.16 2 L 1 X N 480.61 589.47 480.98 589.47 2 L N 480.61 593.79 480.98 593.79 2 L N 480.61 598.11 480.98 598.11 2 L N 480.61 602.43 480.98 602.43 2 L N 480.61 606.76 480.98 606.76 2 L N 480.61 611.08 480.98 611.08 2 L N 480.61 615.4 480.98 615.4 2 L N 480.61 619.71 480.98 619.71 2 L N 480.61 624.04 480.98 624.04 2 L N 480.61 628.35 480.98 628.35 2 L N 545.13 585.16 544.76 585.16 2 L N 545.13 589.47 544.76 589.47 2 L N 545.13 593.79 544.76 593.79 2 L N 545.13 598.11 544.76 598.11 2 L N 545.13 602.43 544.76 602.43 2 L N 545.13 606.76 544.76 606.76 2 L N 545.13 611.08 544.76 611.08 2 L N 545.13 615.4 544.76 615.4 2 L N 545.13 619.71 544.76 619.71 2 L N 545.13 624.04 544.76 624.04 2 L N 545.13 628.35 544.76 628.35 2 L N 480.61 585.16 481.35 585.16 2 L N 480.61 593.79 481.35 593.79 2 L N 480.61 602.43 481.35 602.43 2 L N 480.61 611.08 481.35 611.08 2 L N 480.61 619.71 481.35 619.71 2 L N 480.61 628.35 481.35 628.35 2 L N 545.13 585.16 544.39 585.16 2 L N 545.13 593.79 544.39 593.79 2 L N 545.13 602.43 544.39 602.43 2 L N 545.13 611.08 544.39 611.08 2 L N 545.13 619.71 544.39 619.71 2 L N 545.13 628.35 544.39 628.35 2 L N 0 F 0 X (0) 476.27 583.82 T (100) 472.27 592.46 T (200) 472.27 601.1 T (300) 472.27 609.74 T (400) 472.27 618.38 T (500) 472.27 627.02 T 3 7 Q (8 threads) 495.3 633.07 T 480.61 602.87 492.65 590.55 499.72 590.91 509.8 590.12 524.91 590.2 545.13 590.12 6 L N 0 Z 90 450 1.47 1.73 480.61 602.87 A 90 450 1.47 1.73 492.65 590.55 A 90 450 1.47 1.73 499.72 590.92 A 90 450 1.47 1.73 509.8 590.12 A 90 450 1.47 1.73 524.91 590.2 A 90 450 1.48 1.73 545.13 590.12 A 480.61 589.98 492.65 585.23 499.72 585.23 509.8 585.23 524.91 585.44 545.13 585.37 6 L 1 Z N 479.13 591.71 480.61 588.25 482.08 591.71 479.13 591.71 4 L N 491.18 586.96 492.65 583.5 494.13 586.96 491.18 586.96 4 L N 498.24 586.96 499.72 583.5 501.19 586.96 498.24 586.96 4 L N 508.32 586.96 509.8 583.5 511.27 586.96 508.32 586.96 4 L N 523.44 587.17 524.91 583.71 526.39 587.17 523.44 587.17 4 L N 543.65 587.1 545.13 583.64 546.6 587.1 543.65 587.1 4 L N 480.61 503.26 480.61 546.46 545.13 546.46 545.13 503.26 480.61 503.26 480.61 504.41 6 L N 485.65 503.26 485.65 504.41 2 L N 490.69 503.26 490.69 504.41 2 L N 495.73 503.26 495.73 504.41 2 L N 500.76 503.26 500.76 504.41 2 L N 505.8 503.26 505.8 504.41 2 L N 510.84 503.26 510.84 504.41 2 L N 515.88 503.26 515.88 504.41 2 L N 520.92 503.26 520.92 504.41 2 L N 525.96 503.26 525.96 504.41 2 L N 530.99 503.26 530.99 504.41 2 L N 536.03 503.26 536.03 504.41 2 L N 541.07 503.26 541.07 504.41 2 L N 480.61 503.26 480.61 504.41 2 L N 490.69 503.26 490.69 504.41 2 L N 500.76 503.26 500.76 504.41 2 L N 510.84 503.26 510.84 504.41 2 L N 520.92 503.26 520.92 504.41 2 L N 530.99 503.26 530.99 504.41 2 L N 0 0 0 1 0 0 0 K 3 4 Q (0) 479.5 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (10) 488.46 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (20) 498.54 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (30) 508.62 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (40) 518.69 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (50) 528.77 498.32 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (60) 538.85 498.32 T 0 0 0 1 0 0 0 K 541.07 503.26 541.07 504.41 2 L N 480.61 503.26 480.98 503.26 2 L 1 X N 480.61 507.58 480.98 507.58 2 L N 480.61 511.89 480.98 511.89 2 L N 480.61 516.21 480.98 516.21 2 L N 480.61 520.54 480.98 520.54 2 L N 480.61 524.85 480.98 524.85 2 L N 480.61 529.17 480.98 529.17 2 L N 480.61 533.42 480.98 533.42 2 L N 480.61 537.82 480.98 537.82 2 L N 480.61 542.14 480.98 542.14 2 L N 480.61 546.46 480.98 546.46 2 L N 545.13 503.26 544.76 503.26 2 L N 545.13 507.58 544.76 507.58 2 L N 545.13 511.89 544.76 511.89 2 L N 545.13 516.21 544.76 516.21 2 L N 545.13 520.54 544.76 520.54 2 L N 545.13 524.85 544.76 524.85 2 L N 545.13 529.17 544.76 529.17 2 L N 545.13 533.42 544.76 533.42 2 L N 545.13 537.82 544.76 537.82 2 L N 545.13 542.14 544.76 542.14 2 L N 545.13 546.46 544.76 546.46 2 L N 480.61 503.26 481.35 503.26 2 L N 480.61 511.89 481.35 511.89 2 L N 480.61 520.54 481.35 520.54 2 L N 480.61 529.17 481.35 529.17 2 L N 480.61 537.82 481.35 537.82 2 L N 480.61 546.46 481.35 546.46 2 L N 545.13 503.26 544.39 503.26 2 L N 545.13 511.89 544.39 511.89 2 L N 545.13 520.54 544.39 520.54 2 L N 545.13 529.17 544.39 529.17 2 L N 545.13 537.82 544.39 537.82 2 L N 545.13 546.46 544.39 546.46 2 L N 0 F 0 X (0) 476.27 501.92 T (100) 472.27 510.56 T (200) 472.27 519.2 T (300) 472.27 527.84 T (400) 472.27 536.48 T (500) 472.27 545.12 T 3 7 Q (1 thread) 497.05 551.17 T 480.61 546.46 492.65 510.74 499.72 511.32 509.8 510.45 524.91 509.81 545.13 509.66 6 L N 0 Z 90 450 1.47 1.73 492.65 510.74 A 90 450 1.47 1.73 499.72 511.32 A 90 450 1.47 1.73 509.8 510.46 A 90 450 1.47 1.73 524.91 509.81 A 90 450 1.48 1.73 545.13 509.66 A 480.61 509.3 492.65 503.4 499.72 503.4 509.8 503.4 524.91 503.4 545.13 503.4 6 L 1 Z N 479.13 511.03 480.61 507.58 482.08 511.03 479.13 511.03 4 L N 491.18 505.13 492.65 501.67 494.13 505.13 491.18 505.13 4 L N 498.24 505.13 499.72 501.67 501.19 505.13 498.24 505.13 4 L N 508.32 505.13 509.8 501.67 511.27 505.13 508.32 505.13 4 L N 523.44 505.13 524.91 501.67 526.39 505.13 523.44 505.13 4 L N 543.65 505.13 545.13 501.67 546.6 505.13 543.65 505.13 4 L N 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 305.17 419.54 553.5 720 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "8" 8 %%Page: "9" 9 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 0.93 (memory hierarchies \050or, alternatively, a range of data set) 58.5 453.33 P 3.87 (sizes\051. Execution time is, of course, higher, because) 58.5 441.83 P 2.39 (performance is more dependent on AMAT parameters,) 58.5 430.33 P 0.68 (rather than tiling overhead. Only adi became slightly less) 58.5 418.83 P 3.6 (tolerant of tile size changes. At the largest tile size) 58.5 407.33 P 1.05 (measured \05032x32\051, its AMAT increased sharply, because) 58.5 395.83 P 2 (of inter-thread interference in the small cache. For this) 58.5 384.33 P 0.73 (loop nest, either tiles should be sized so that all fit in the) 58.5 372.83 P 5.35 (cache, or an alternative tiling technique \050described) 58.5 361.33 P (below\051 should be used.) 58.5 349.83 T 2.56 (The second loop tiling issue is the distribution of) 76.5 338.33 P 9.33 (tiles to threads. When parallelizing loops for) 58.5 326.83 P 4.31 (multiprocessors, a different tile is allocated to each) 58.5 315.33 P 2.21 (processor \050thread\051 to maximize reuse and reduce inter-) 58.5 303.83 P 0.42 (processor communication. On an SMT, however, tiling in) 58.5 292.33 P 0.54 (this manner could be detrimental. Private, per-thread tiles) 58.5 280.83 P 0.54 (discourage inter-thread tile sharing and increase the total-) 58.5 269.33 P 2.84 (thread tile footprint on the single-processor SMT \050the) 58.5 257.83 P 0.85 (same factors that make blocked loop iteration scheduling) 58.5 246.33 P (inappropriate for SMT\051.) 58.5 234.83 T 2.07 (Rather than giving each thread its own tile \050called) 76.5 223.33 P 2 F 0.9 (blocked) 58.5 211.83 P 1 F 0.9 ( tiling\051, a single tile can be shared by all threads,) 89.6 211.83 P 2.44 (and loop iterations can be distributed cyclically across) 58.5 200.33 P 3.66 (the threads \050) 58.5 188.83 P 2 F 3.66 (cyclic) 115.25 188.83 P 1 F 3.66 ( tiling\051. \050See Figure 6 for a code) 138.57 188.83 P 0.63 (explanation of blocked and cyclic tiling, and Figure 7 for) 58.5 177.33 P (the effect on the per-thread data layout\051.) 58.5 165.83 T 4.26 (Because the tile is shared, cyclic tiling can be) 76.5 154.33 P 1.41 (optimized by increasing the tile size to reduce overhead) 58.5 142.83 P 3.7 (\050Figure 7c\051. With larger tiles, cyclic tiling can drop) 58.5 131.33 P 5.21 (execution times of applications executing on small) 58.5 119.83 P 4.81 (memory SMTs closer to that of SMTs with more) 58.5 108.33 P 0.58 (aggressive memory hierarchies. \050Or, put another way, the) 58.5 96.83 P 5.22 (performance of programs with large data sets can) 58.5 85.33 P 58.5 460.98 278.99 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 59.07 463.85 273.38 720.24 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 2 Z 0 X N 66.88 483.69 272.31 718.86 R 7 X V 6 8 Q 0 X (a\051 original loop) 66.88 713.52 T 5 6 Q (for \050j = 1; j < N; j++) 66.88 704.86 T (for \050k = 1; k < L; k++\051) 75.88 697.86 T (for \050i = 1; i < M; i++\051) 84.88 690.86 T (c[j][k] += a[i][k]*b[j][i];) 93.88 683.86 T 6 8 Q (b\051 blocked tiling) 66.88 667.52 T 5 6 Q (ub = min\050N*\050myid+1\051/numthreads+1, N\051;) 66.88 658.86 T (lb = max\050N*myid/numthreads+1, 1\051;) 66.88 651.86 T (for \050jT=lb; jT <= ub; jT+=jTsize\051) 66.88 644.86 T (for \050kT=1; kT <= L; kT+=kTsize\051) 75.88 637.86 T (for \050iT=1; iT < M; iT+=iTsize\051) 84.88 630.86 T (for \050j=jT; j <= min\050N,jT+jTsize-1\051;) 93.88 623.86 T (j++\051) 219.88 623.86 T (for \050k=max\0501, kT\051;) 102.88 616.86 T ( k <= min\050L,kT+kTsize-1\051; k++\051) 120.88 609.86 T (for \050i=iT; i <= min\050M,iT+iTsize-1\051;i++\051) 111.88 602.86 T (c[j][k] += a[i][k]*b[j][i];) 120.88 595.86 T 6 8 Q (c\051 cyclic tiling) 66.88 579.52 T 5 6 Q (ub = min\050N * \050myid + 1\051/numthreads + 1, N\051;) 66.88 570.86 T (lb = max\050N * myid / numthreads + 1, 1\051;) 66.88 563.86 T (for \050jT = lb; jT <= ub; jT += jTsize\051) 66.88 556.86 T (for \050kT = 1; kT <= L; kT += kTsize\051) 75.88 549.86 T (for \050iT = 1; iT < M; iT += iTsize\051) 84.88 542.86 T 6 F (for \050j = jT+myid;) 93.88 535.86 T 5 F (j <= min\050N,jT+jTsize-1\051;) 158.68 535.86 T ( j += numthreads\051) 111.88 528.86 T (for \050k=max\0501, kT\051;) 102.88 521.86 T ( k <= min\050L,kT+kTsize-1\051;) 120.88 514.86 T ( k++\051) 210.88 514.86 T (for \050i=iT;) 111.88 507.86 T ( i <= min\050M,iT + iTsize-1\051;) 147.88 507.86 T ( i++\051) 129.88 500.86 T (c[j][k] += a[i][k]*b[j][i];) 120.88 493.86 T 63.08 465.28 268.32 486.35 R 7 X V 4 10 Q 0 X 4.57 (Figure 6: Code for blocked and cyclic) 63.08 479.69 P (versions of a tiled loop nest.) 63.08 467.69 T 0 0 612 792 C 319.5 82.5 553.5 721.4 R 7 X 0 0 0 1 0 0 0 K V 1 10 Q 0 X 2.84 (approach those with smaller.\051 For example, Figure 8c) 319.5 270.74 P 1.16 (illustrates that with larger tile sizes \050greater than 8 array) 319.5 259.24 P 3.54 (elements per dimension\051 cyclic tiling reduced mxm\325s) 319.5 247.74 P 0.37 (AMAT enough to decrease average execution time on the) 319.5 236.24 P 1.34 (smaller cache hierarchy by 51% \050compare to blocked in) 319.5 224.74 P 2.79 (Figure 8b\051 and to within 35% of blocked tiling on a) 319.5 213.24 P 2.72 (memory subsystem several times the size \050Figure 8a\051.) 319.5 201.74 P 0.39 (Only at the very smallest tile size did an increase in tiling) 319.5 190.24 P 4.28 (overhead overwhelm SMT\325s ability to hide memory) 319.5 178.74 P (latency.) 319.5 167.24 T 1.22 (Cyclic tiling is still appropriate for a multiprocessor) 337.5 155.74 P 2.55 (of SMTs. A hierarchical [8] or hybrid tiling approach) 319.5 144.08 P 1.87 (might be most effective. Cyclic tiling could be used to) 319.5 132.58 P 0.73 (maximize locality in each processor, while blocked tiling) 319.5 121.08 P 0.77 (could distribute tiles across processors to minimize inter-) 319.5 109.58 P (processor communication.) 319.5 98.08 T 292.18 478.54 553.5 721.4 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 297 478.54 548.42 720.21 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 297 456.34 548.42 720.21 R 7 X 0 0 0 1 0 0 0 K V 401.72 644.46 450.46 647.51 R 2 X V 401.72 641.41 450.46 644.46 R 4 X V 401.72 638.37 450.46 641.41 R 5 X V 401.72 635.32 450.46 638.37 R 7 X V 401.72 632.28 450.46 635.32 R 2 X V 401.72 629.23 450.46 632.28 R 4 X V 401.72 626.18 450.46 629.23 R 5 X V 401.72 623.14 450.46 626.19 R 7 X V 401.72 620.09 450.46 623.14 R 2 X V 401.72 617.05 450.46 620.09 R 4 X V 401.72 614 450.46 617.05 R 5 X V 401.72 610.96 450.46 614 R 7 X V 401.72 607.91 450.46 610.96 R 2 X V 401.72 604.86 450.46 607.91 R 4 X V 401.72 601.82 450.46 604.87 R 5 X V 401.72 598.77 450.46 601.82 R 7 X V 401.72 644.46 450.46 647.51 R 0.5 H 0 Z 0 X N 401.72 641.41 450.46 644.46 R N 401.72 638.37 450.46 641.41 R N 401.72 635.32 450.46 638.37 R N 401.72 632.28 450.46 635.32 R N 401.72 629.23 450.46 632.28 R N 401.72 626.18 450.46 629.23 R N 401.72 623.14 450.46 626.19 R N 401.72 620.09 450.46 623.14 R N 401.72 617.05 450.46 620.09 R N 401.72 614 450.46 617.05 R N 401.72 610.96 450.46 614 R N 401.72 607.91 450.46 610.96 R N 401.72 604.86 450.46 607.91 R N 401.72 601.82 450.46 604.87 R N 401.72 598.77 450.46 601.82 R N 447.41 598.78 450.46 647.51 R N 444.36 598.78 447.41 647.51 R N 441.32 598.78 444.37 647.51 R N 438.27 598.78 441.32 647.51 R N 435.23 598.78 438.27 647.51 R N 432.18 598.78 435.23 647.51 R N 429.14 598.78 432.18 647.51 R N 426.09 598.78 429.14 647.51 R N 423.05 598.78 426.09 647.51 R N 420 598.78 423.05 647.51 R N 416.95 598.78 420 647.51 R N 413.91 598.78 416.95 647.51 R N 410.86 598.78 413.91 647.51 R N 407.82 598.78 410.86 647.51 R N 404.77 598.78 407.82 647.51 R N 401.73 598.78 404.77 647.51 R N 401.72 693.19 450.46 696.24 R 2 X V 401.72 690.15 450.46 693.19 R 4 X V 401.72 687.1 450.46 690.15 R 5 X V 401.72 684.05 450.46 687.1 R 7 X V 401.72 681.01 450.46 684.05 R 2 X V 401.72 677.96 450.46 681.01 R 4 X V 401.72 674.92 450.46 677.96 R 5 X V 401.72 671.87 450.46 674.92 R 7 X V 401.72 668.83 450.46 671.87 R 2 X V 401.72 665.78 450.46 668.83 R 4 X V 401.72 662.73 450.46 665.78 R 5 X V 401.72 659.69 450.46 662.73 R 7 X V 401.72 656.64 450.46 659.69 R 2 X V 401.72 653.6 450.46 656.64 R 4 X V 401.72 650.55 450.46 653.6 R 5 X V 401.72 647.51 450.46 650.55 R 7 X V 401.72 693.19 450.46 696.24 R 0 X N 401.72 690.15 450.46 693.19 R N 401.72 687.1 450.46 690.15 R N 401.72 684.05 450.46 687.1 R N 401.72 681.01 450.46 684.05 R N 401.72 677.96 450.46 681.01 R N 401.72 674.92 450.46 677.96 R N 401.72 671.87 450.46 674.92 R N 401.72 668.83 450.46 671.87 R N 401.72 665.78 450.46 668.83 R N 401.72 662.73 450.46 665.78 R N 401.72 659.69 450.46 662.73 R N 401.72 656.64 450.46 659.69 R N 401.72 653.6 450.46 656.64 R N 401.72 650.55 450.46 653.6 R N 401.72 647.51 450.46 650.55 R N 447.41 647.51 450.46 696.24 R N 444.37 647.51 447.41 696.24 R N 441.32 647.51 444.37 696.24 R N 438.27 647.51 441.32 696.24 R N 435.23 647.51 438.27 696.24 R N 432.18 647.51 435.23 696.24 R N 429.14 647.51 432.18 696.24 R N 426.09 647.51 429.14 696.24 R N 423.05 647.51 426.09 696.24 R N 420 647.51 423.05 696.24 R N 416.95 647.51 420 696.24 R N 413.91 647.51 416.95 696.24 R N 410.86 647.51 413.91 696.24 R N 407.82 647.51 410.86 696.24 R N 404.77 647.51 407.82 696.24 R N 401.73 647.51 404.77 696.24 R N 7 X 90 450 3.65 3.65 407.99 689.5 G 0 X 90 450 3.65 3.65 407.99 689.5 A 4 8 Q (0) 405.76 686.85 T 7 X 90 450 3.65 3.65 407.99 677.32 G 0 X 90 450 3.65 3.65 407.99 677.32 A (4) 405.76 674.67 T 7 X 90 450 3.65 3.65 407.99 665.14 G 0 X 90 450 3.65 3.65 407.99 665.14 A (8) 405.76 662.48 T 7 X 90 450 3.65 3.65 420.17 689.16 G 0 X 90 450 3.65 3.65 420.17 689.16 A (1) 417.95 686.51 T 7 X 90 450 3.65 3.65 420.17 676.98 G 0 X 90 450 3.65 3.65 420.17 676.98 A (5) 417.95 674.33 T 7 X 90 450 3.65 3.65 432.79 689.16 G 0 X 90 450 3.65 3.65 432.79 689.16 A (2) 430.57 686.51 T 7 X 90 450 3.65 3.65 432.79 676.98 G 0 X 90 450 3.65 3.65 432.79 676.98 A (6) 430.57 674.33 T 7 X 90 450 3.65 3.65 443.52 689.16 G 0 X 90 450 3.65 3.65 443.52 689.16 A (3) 441.3 686.51 T 7 X 90 450 3.65 3.65 443.52 676.98 G 0 X 90 450 3.65 3.65 443.52 676.98 A (7) 441.3 674.33 T 327.78 684.05 376.51 696.24 R 2 X V 327.78 671.87 376.51 684.05 R 4 X V 327.78 659.69 376.51 671.87 R 5 X V 327.78 647.51 376.51 659.69 R 7 X V 327.78 693.19 376.51 696.24 R 0 X N 327.78 690.15 376.51 693.19 R N 327.78 687.1 376.51 690.15 R N 327.78 684.06 376.51 687.1 R N 327.78 681.01 376.51 684.05 R N 327.78 677.96 376.51 681.01 R N 327.78 674.92 376.51 677.96 R N 327.78 671.87 376.51 674.92 R N 327.78 668.83 376.51 671.87 R N 327.78 665.78 376.51 668.83 R N 327.78 662.73 376.51 665.78 R N 327.78 659.69 376.51 662.74 R N 327.78 656.64 376.51 659.69 R N 327.78 653.6 376.51 656.64 R N 327.78 650.55 376.51 653.6 R N 327.78 647.51 376.51 650.55 R N 373.47 647.51 376.51 696.24 R N 370.42 647.51 373.47 696.24 R N 367.38 647.51 370.42 696.24 R N 364.33 647.51 367.38 696.24 R N 361.29 647.51 364.33 696.24 R N 358.24 647.51 361.29 696.24 R N 355.19 647.51 358.24 696.24 R N 352.15 647.51 355.19 696.24 R N 349.1 647.51 352.15 696.24 R N 346.06 647.51 349.1 696.24 R N 343.01 647.51 346.06 696.24 R N 339.96 647.51 343.01 696.24 R N 336.92 647.51 339.97 696.24 R N 333.87 647.51 336.92 696.24 R N 330.83 647.51 333.88 696.24 R N 327.78 647.51 330.83 696.24 R N 327.78 635.32 376.51 647.51 R 2 X V 327.78 623.14 376.51 635.32 R 4 X V 327.78 610.96 376.51 623.14 R 5 X V 327.78 598.77 376.51 610.96 R 7 X V 327.78 644.46 376.51 647.51 R 0 X N 327.78 641.41 376.51 644.46 R N 327.78 638.37 376.51 641.41 R N 327.78 635.32 376.51 638.37 R N 327.78 632.28 376.51 635.32 R N 327.78 629.23 376.51 632.28 R N 327.78 626.18 376.51 629.23 R N 327.78 623.14 376.51 626.19 R N 327.78 620.09 376.51 623.14 R N 327.78 617.05 376.51 620.09 R N 327.78 614 376.51 617.05 R N 327.78 610.96 376.51 614 R N 327.78 607.91 376.51 610.96 R N 327.78 604.86 376.51 607.91 R N 327.78 601.82 376.51 604.87 R N 327.78 598.77 376.51 601.82 R N 373.47 598.78 376.51 647.51 R N 370.42 598.78 373.47 647.51 R N 367.38 598.78 370.42 647.51 R N 364.33 598.78 367.38 647.51 R N 361.29 598.78 364.33 647.51 R N 358.24 598.78 361.29 647.51 R N 355.19 598.78 358.24 647.51 R N 352.15 598.78 355.19 647.51 R N 349.1 598.78 352.15 647.51 R N 346.06 598.78 349.1 647.51 R N 343.01 598.78 346.06 647.51 R N 339.96 598.78 343.01 647.51 R N 336.92 598.78 339.97 647.51 R N 333.87 598.78 336.92 647.51 R N 330.83 598.78 333.88 647.51 R N 327.78 598.78 330.83 647.51 R N 387.73 588.84 394.47 596.44 R 2 X V 0 X N 387.73 581.25 394.47 588.84 R 4 X V 0 X N 442.39 588.84 449.14 596.44 R 5 X V 0 X N 442.39 581.25 449.14 588.84 R 7 X V 0 X N 5 F (Thread 0) 398.72 591.65 T (Thread 1) 398.72 583.4 T (Thread 2) 453.38 590.33 T (Thread 3) 453.38 582.07 T (i dimension) 325.75 701.27 T (j dimension) 0 -270 320.99 622.49 TF 4 F (c\051 optimized cyclic) 459.17 712.78 T 7 X 90 450 3.65 3.65 334.05 690.18 G 0 X 90 450 3.65 3.65 334.05 690.18 A (0) 331.82 687.53 T 7 X 90 450 3.65 3.65 334.05 678 G 0 X 90 450 3.65 3.65 334.05 678 A (0) 331.82 675.34 T 7 X 90 450 3.65 3.65 334.05 665.82 G 0 X 90 450 3.65 3.65 334.05 665.82 A (0) 331.82 663.16 T 7 X 90 450 3.65 3.65 334.05 653.63 G 0 X 90 450 3.65 3.65 334.05 653.63 A (0) 331.82 650.98 T 7 X 90 450 3.65 3.65 346.23 689.84 G 0 X 90 450 3.65 3.65 346.23 689.84 A (1) 344 687.19 T 7 X 90 450 3.65 3.65 346.23 677.66 G 0 X 90 450 3.65 3.65 346.23 677.66 A (1) 344 675.01 T 7 X 90 450 3.65 3.65 346.23 665.48 G 0 X 90 450 3.65 3.65 346.23 665.48 A (1) 344 662.82 T 7 X 90 450 3.65 3.65 346.23 653.29 G 0 X 90 450 3.65 3.65 346.23 653.29 A (1) 344 650.64 T (a\051 blocked) 327.07 712.78 T 7 X 90 450 3.65 3.65 358.85 689.84 G 0 X 90 450 3.65 3.65 358.85 689.84 A (2) 356.62 687.19 T 7 X 90 450 3.65 3.65 358.85 677.66 G 0 X 90 450 3.65 3.65 358.85 677.66 A (2) 356.62 675.01 T 7 X 90 450 3.65 3.65 358.85 665.48 G 0 X 90 450 3.65 3.65 358.85 665.48 A (2) 356.62 662.82 T 7 X 90 450 3.65 3.65 358.85 653.29 G 0 X 90 450 3.65 3.65 358.85 653.29 A (2) 356.62 650.64 T 7 X 90 450 3.65 3.65 369.58 689.84 G 0 X 90 450 3.65 3.65 369.58 689.84 A (3) 367.36 687.19 T 7 X 90 450 3.65 3.65 369.58 677.66 G 0 X 90 450 3.65 3.65 369.58 677.66 A (3) 367.36 675.01 T 7 X 90 450 3.65 3.65 369.58 665.48 G 0 X 90 450 3.65 3.65 369.58 665.48 A (3) 367.36 662.82 T 7 X 90 450 3.65 3.65 369.58 653.29 G 0 X 90 450 3.65 3.65 369.58 653.29 A (3) 367.36 650.64 T 7 X 90 450 3.65 3.65 334.48 641.79 G 0 X 90 450 3.65 3.65 334.48 641.79 A (4) 332.26 639.13 T 7 X 90 450 3.65 3.65 334.48 629.6 G 0 X 90 450 3.65 3.65 334.48 629.6 A (4) 332.26 626.95 T 7 X 90 450 3.65 3.65 334.48 617.42 G 0 X 90 450 3.65 3.65 334.48 617.42 A (4) 332.26 614.77 T 7 X 90 450 3.65 3.65 334.48 605.24 G 0 X 90 450 3.65 3.65 334.48 605.24 A (4) 332.26 602.58 T 5 F (i dimension) 399.69 701.27 T (j dimension) 0 -270 394.93 622.49 TF 4 F (b\051 cyclic) 404.79 712.78 T 475.67 644.46 524.4 647.51 R 2 X V 475.67 641.41 524.4 644.46 R 4 X V 475.67 638.37 524.4 641.41 R 5 X V 475.67 635.32 524.4 638.37 R 7 X V 475.67 632.28 524.4 635.32 R 2 X V 475.67 629.23 524.4 632.28 R 4 X V 475.67 626.18 524.4 629.23 R 5 X V 475.67 623.14 524.4 626.19 R 7 X V 475.67 620.09 524.4 623.14 R 2 X V 475.67 617.05 524.4 620.09 R 4 X V 475.67 614 524.4 617.05 R 5 X V 475.67 610.96 524.4 614 R 7 X V 475.67 607.91 524.4 610.96 R 2 X V 475.67 604.86 524.4 607.91 R 4 X V 475.67 601.82 524.4 604.87 R 5 X V 475.67 598.77 524.4 601.82 R 7 X V 475.67 644.46 524.4 647.51 R 0 X N 475.67 641.41 524.4 644.46 R N 475.67 638.37 524.4 641.41 R N 475.67 635.32 524.4 638.37 R N 475.67 632.28 524.4 635.32 R N 475.67 629.23 524.4 632.28 R N 475.67 626.18 524.4 629.23 R N 475.67 623.14 524.4 626.19 R N 475.67 620.09 524.4 623.14 R N 475.67 617.05 524.4 620.09 R N 475.67 614 524.4 617.05 R N 475.67 610.96 524.4 614 R N 475.67 607.91 524.4 610.96 R N 475.67 604.86 524.4 607.91 R N 475.67 601.82 524.4 604.87 R N 475.67 598.77 524.4 601.82 R N 521.35 598.78 524.4 647.51 R N 518.31 598.78 521.35 647.51 R N 515.26 598.78 518.31 647.51 R N 512.22 598.78 515.26 647.51 R N 509.17 598.78 512.22 647.51 R N 506.12 598.78 509.17 647.51 R N 503.08 598.78 506.12 647.51 R N 500.03 598.78 503.08 647.51 R N 496.99 598.78 500.03 647.51 R N 493.94 598.78 496.99 647.51 R N 490.9 598.78 493.94 647.51 R N 487.85 598.78 490.9 647.51 R N 484.8 598.78 487.85 647.51 R N 481.76 598.78 484.8 647.51 R N 478.71 598.78 481.76 647.51 R N 475.67 598.78 478.71 647.51 R N 475.67 693.19 524.4 696.24 R 2 X V 475.67 690.15 524.4 693.19 R 4 X V 475.67 687.1 524.4 690.15 R 5 X V 475.67 684.05 524.4 687.1 R 7 X V 475.67 681.01 524.4 684.05 R 2 X V 475.67 677.96 524.4 681.01 R 4 X V 475.67 674.92 524.4 677.96 R 5 X V 475.67 671.87 524.4 674.92 R 7 X V 475.67 668.83 524.4 671.87 R 2 X V 475.67 665.78 524.4 668.83 R 4 X V 475.67 662.73 524.4 665.78 R 5 X V 475.67 659.69 524.4 662.73 R 7 X V 475.67 656.64 524.4 659.69 R 2 X V 475.67 653.6 524.4 656.64 R 4 X V 475.67 650.55 524.4 653.6 R 5 X V 475.67 647.51 524.4 650.55 R 7 X V 475.67 693.19 524.4 696.24 R 0 X N 475.67 690.15 524.4 693.19 R N 475.67 687.1 524.4 690.15 R N 475.67 684.05 524.4 687.1 R N 475.67 681.01 524.4 684.05 R N 475.67 677.96 524.4 681.01 R N 475.67 674.92 524.4 677.96 R N 475.67 671.87 524.4 674.92 R N 475.67 668.83 524.4 671.87 R N 475.67 665.78 524.4 668.83 R N 475.67 662.73 524.4 665.78 R N 475.67 659.69 524.4 662.73 R N 475.67 656.64 524.4 659.69 R N 475.67 653.6 524.4 656.64 R N 475.67 650.55 524.4 653.6 R N 475.67 647.51 524.4 650.55 R N 521.35 647.51 524.4 696.24 R N 518.31 647.51 521.36 696.24 R N 515.26 647.51 518.31 696.24 R N 512.22 647.51 515.26 696.24 R N 509.17 647.51 512.22 696.24 R N 506.13 647.51 509.17 696.24 R N 503.08 647.51 506.13 696.24 R N 500.03 647.51 503.08 696.24 R N 496.99 647.51 500.04 696.24 R N 493.94 647.51 496.99 696.24 R N 490.9 647.51 493.94 696.24 R N 487.85 647.51 490.9 696.24 R N 484.81 647.51 487.85 696.24 R N 481.76 647.51 484.81 696.24 R N 478.71 647.51 481.76 696.24 R N 475.67 647.51 478.71 696.24 R N 7 X 90 450 3.65 3.65 488.21 683.7 G 0 X 90 450 3.65 3.65 488.21 683.7 A (0) 485.99 681.05 T 7 X 90 450 3.65 3.65 488.21 659.43 G 0 X 90 450 3.65 3.65 488.21 659.43 A (2) 485.99 656.78 T 7 X 90 450 3.65 3.65 488.21 635.16 G 0 X 90 450 3.65 3.65 488.21 635.16 A (4) 485.99 632.51 T 7 X 90 450 3.65 3.65 512.05 683.85 G 0 X 90 450 3.65 3.65 512.05 683.85 A (1) 509.83 681.19 T 7 X 90 450 3.65 3.65 512.05 659.58 G 0 X 90 450 3.65 3.65 512.05 659.58 A (3) 509.83 656.92 T 5 F (i dimension) 473.63 701.27 T (j dimension) 0 -270 468.88 622.49 TF 298 485.64 545.62 577.37 R 7 X V 4 10 Q 0 X 0.67 (Figure 7: A comparison of blocked and cyclic tiling) 298 570.7 P 3.89 (techniques for multiple threads.) 298 560.7 P 3 8 Q 3.11 (The blocked tiling is) 466.04 560.7 P 2.18 (shown in a\051. Each tile is a 4x4 array of elements. The numbers) 298 552.03 P 0.97 (represent the order in which tiles are accessed by each thread. For) 298 544.03 P 0.54 (cyclic tiling, each tile is still a 4x4 array) 298 536.03 P 0.54 (, but now the tile is shared by) 438.22 536.03 P 0.78 (all threads. In this example, each thread gets one row of the tile, as) 298 528.03 P 0.55 (shown in b\051. With cyclic tiling, each thread works on a smaller chunk) 298 520.03 P 0.68 (of data at a time, so the tiling overhead is greater) 298 512.03 P 0.68 (. In c\051, the tile size) 477.76 512.03 P 1.45 (is increased to 8x8 to reduce the overhead. Within each tile, each) 298 504.03 P 2.87 (thread is responsible for 16 of the elements, as in the original) 298 496.03 P (blocked example.) 298 488.03 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 292.18 478.54 553.5 721.4 C 295.97 484.03 551.6 720.28 R 0.5 H 2 Z 0 X 0 0 0 1 0 0 0 K N 0 0 612 792 C 316.29 277.58 553.5 478.54 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 318.68 282.15 551.83 476.72 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 2 Z 0 X N 319.96 283.25 551.21 474.64 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 319.96 283.25 551.21 474.64 R 7 X 0 0 0 1 0 0 0 K V 484.41 433.9 484.41 466.3 541.71 466.3 541.71 433.9 484.41 433.9 5 L 0.5 H 1 Z 0 X N 484.41 433.9 484.41 434.77 2 L N 486.77 433.9 486.77 434.77 2 L N 489.17 433.9 489.17 434.77 2 L N 491.54 433.9 491.54 434.77 2 L N 493.94 433.9 493.94 434.77 2 L N 496.34 433.9 496.34 434.77 2 L N 498.7 433.9 498.7 434.77 2 L N 501.11 433.9 501.11 434.77 2 L N 503.51 433.9 503.51 434.77 2 L N 505.87 433.9 505.87 434.77 2 L N 508.27 433.9 508.27 434.77 2 L N 510.64 433.9 510.64 434.77 2 L N 513.04 433.9 513.04 434.77 2 L N 515.44 433.9 515.44 434.77 2 L N 517.8 433.9 517.8 434.77 2 L N 520.2 433.9 520.2 434.77 2 L N 522.6 433.9 522.6 434.77 2 L N 524.97 433.9 524.97 434.77 2 L N 527.37 433.9 527.37 434.77 2 L N 529.74 433.9 529.74 434.77 2 L N 532.14 433.9 532.14 434.77 2 L N 534.54 433.9 534.54 434.77 2 L N 536.9 433.9 536.9 434.77 2 L N 539.3 433.9 539.3 434.77 2 L N 541.71 433.9 541.71 434.77 2 L N 484.41 433.9 484.41 434.77 2 L N 496.34 433.9 496.34 434.77 2 L N 508.27 433.9 508.27 434.77 2 L N 520.2 433.9 520.2 434.77 2 L N 3 7 Q (0) 482.65 427.23 T (5) 494.58 427.23 T (10) 504.57 427.23 T (15) 516.5 427.23 T (20) 528.43 427.23 T 532.14 433.9 532.14 434.77 2 L N 484.41 433.9 541.71 433.9 2 L 1 X N 484.41 440.38 541.71 440.38 2 L N 484.41 446.86 541.71 446.86 2 L N 484.41 453.29 541.71 453.29 2 L N 484.41 459.77 541.71 459.77 2 L N 484.41 466.3 541.71 466.3 2 L N 484.41 433.9 541.71 433.9 2 L N 484.41 440.38 541.71 440.38 2 L N 484.41 446.86 541.71 446.86 2 L N 484.41 453.29 541.71 453.29 2 L N 484.41 459.77 541.71 459.77 2 L N 484.41 466.3 541.71 466.3 2 L N 484.41 452.42 488.7 466.3 2 L 0 X N 493.43 466.3 493.94 463.71 496.34 460.2 503.51 455.23 510.64 454.1 513.04 454.1 522.6 453.23 524.97 453.23 541.71 453.13 9 L N 483.53 452.42 485.28 452.42 2 L N 484.41 453.72 484.41 451.13 2 L N 483.82 451.56 484.99 453.29 2 L N 483.82 453.29 484.99 451.56 2 L N 493.07 463.71 494.81 463.71 2 L N 493.94 465.01 493.94 462.42 2 L N 493.36 462.85 494.52 464.58 2 L N 493.36 464.58 494.52 462.85 2 L N 495.47 460.2 497.21 460.2 2 L N 496.34 461.5 496.34 458.9 2 L N 495.76 459.34 496.92 461.07 2 L N 495.76 461.07 496.92 459.34 2 L N 502.63 455.23 504.38 455.23 2 L N 503.51 456.53 503.51 453.94 2 L N 502.92 454.37 504.09 456.1 2 L N 502.92 456.1 504.09 454.37 2 L N 509.76 454.1 511.51 454.1 2 L N 510.64 455.39 510.64 452.8 2 L N 510.05 453.23 511.22 454.96 2 L N 510.05 454.96 511.22 453.23 2 L N 512.16 454.1 513.91 454.1 2 L N 513.04 455.39 513.04 452.8 2 L N 512.46 453.23 513.62 454.96 2 L N 512.46 454.96 513.62 453.23 2 L N 521.73 453.23 523.48 453.23 2 L N 522.6 454.53 522.6 451.94 2 L N 522.02 452.37 523.19 454.1 2 L N 522.02 454.1 523.19 452.37 2 L N 524.1 453.23 525.84 453.23 2 L N 524.97 454.53 524.97 451.94 2 L N 524.39 452.37 525.55 454.1 2 L N 524.39 454.1 525.55 452.37 2 L N 540.83 453.13 542.58 453.13 2 L N 541.71 454.42 541.71 451.83 2 L N 541.12 452.26 542.29 453.99 2 L N 541.12 453.99 542.29 452.26 2 L N 484.76 374.76 484.76 407.16 542.06 407.16 542.06 374.76 484.76 374.76 484.76 375.62 6 L N 487.12 374.76 487.12 375.62 2 L N 489.53 374.76 489.53 375.62 2 L N 491.89 374.76 491.89 375.62 2 L N 494.29 374.76 494.29 375.62 2 L N 496.69 374.76 496.69 375.62 2 L N 499.06 374.76 499.06 375.62 2 L N 501.46 374.76 501.46 375.62 2 L N 503.86 374.76 503.86 375.62 2 L N 506.23 374.76 506.23 375.62 2 L N 508.63 374.76 508.63 375.62 2 L N 510.99 374.76 510.99 375.62 2 L N 513.39 374.76 513.39 375.62 2 L N 515.79 374.76 515.79 375.62 2 L N 518.16 374.76 518.16 375.62 2 L N 520.56 374.76 520.56 375.62 2 L N 522.96 374.76 522.96 375.62 2 L N 525.32 374.76 525.32 375.62 2 L N 527.72 374.76 527.72 375.62 2 L N 530.09 374.76 530.09 375.62 2 L N 532.49 374.76 532.49 375.62 2 L N 534.89 374.76 534.89 375.62 2 L N 537.26 374.76 537.26 375.62 2 L N 539.66 374.76 539.66 375.62 2 L N 542.06 374.76 542.06 375.62 2 L N 484.76 374.76 484.76 375.62 2 L N 496.69 374.76 496.69 375.62 2 L N 508.63 374.76 508.63 375.62 2 L N 520.56 374.76 520.56 375.62 2 L N 532.49 374.76 532.49 375.62 2 L N 484.76 374.76 542.06 374.76 2 L 1 X N 484.76 381.24 542.06 381.24 2 L N 484.76 387.72 542.06 387.72 2 L N 484.76 394.2 542.06 394.2 2 L N 484.76 400.68 542.06 400.68 2 L N 484.76 407.16 542.06 407.16 2 L N 484.76 374.76 542.06 374.76 2 L N 484.76 387.72 542.06 387.72 2 L N 484.76 400.68 542.06 400.68 2 L N 0 X (0) 479.49 373.31 T (10) 475.59 386.27 T (20) 475.59 399.23 T 484.76 382.32 491.89 391.01 494.29 386.21 496.69 385.07 503.86 383.08 510.99 383.72 513.39 383.94 522.96 382.54 525.32 383.29 542.06 382.54 10 L N 0 Z 90 450 0.87 1.3 484.76 382.32 A 90 450 0.87 1.3 491.89 391.01 A 90 450 0.87 1.3 494.29 386.21 A 90 450 0.87 1.3 496.69 385.07 A 90 450 0.87 1.3 503.86 383.08 A 90 450 0.87 1.3 510.99 383.72 A 90 450 0.87 1.3 513.39 383.94 A 90 450 0.87 1.3 522.96 382.54 A 90 450 0.87 1.3 525.32 383.29 A 90 450 0.87 1.3 542.06 382.54 A 484.76 377.46 491.89 377.08 494.29 377.46 496.69 378.65 503.86 377.46 510.99 381.62 513.39 382.91 522.96 377.35 525.32 380.16 542.06 377.35 10 L 1 Z N 483.89 378.76 484.76 376.16 485.63 378.76 483.89 378.76 4 L N 491.02 378.38 491.89 375.79 492.76 378.38 491.02 378.38 4 L N 493.42 378.76 494.29 376.16 495.17 378.76 493.42 378.76 4 L N 495.82 379.94 496.69 377.35 497.57 379.94 495.82 379.94 4 L N 502.99 378.76 503.86 376.16 504.73 378.76 502.99 378.76 4 L N 510.12 382.91 510.99 380.32 511.86 382.91 510.12 382.91 4 L N 512.52 384.21 513.39 381.62 514.27 384.21 512.52 384.21 4 L N 522.09 378.65 522.96 376.06 523.83 378.65 522.09 378.65 4 L N 524.45 381.46 525.32 378.86 526.2 381.46 524.45 381.46 4 L N 541.19 378.65 542.06 376.06 542.94 378.65 541.19 378.65 4 L N 370.69 434.56 370.69 466.96 427.99 466.96 427.99 434.56 370.69 434.56 5 L N 370.69 434.56 370.69 435.42 2 L N 373.06 434.56 373.06 435.42 2 L N 375.46 434.56 375.46 435.42 2 L N 377.82 434.56 377.82 435.42 2 L N 380.22 434.56 380.22 435.42 2 L N 382.62 434.56 382.62 435.42 2 L N 384.99 434.56 384.99 435.42 2 L N 387.39 434.56 387.39 435.42 2 L N 389.79 434.56 389.79 435.42 2 L N 392.16 434.56 392.16 435.42 2 L N 394.56 434.56 394.56 435.42 2 L N 396.92 434.56 396.92 435.42 2 L N 399.32 434.56 399.32 435.42 2 L N 401.72 434.56 401.72 435.42 2 L N 404.09 434.56 404.09 435.42 2 L N 406.49 434.56 406.49 435.42 2 L N 408.89 434.56 408.89 435.42 2 L N 411.26 434.56 411.26 435.42 2 L N 413.66 434.56 413.66 435.42 2 L N 416.02 434.56 416.02 435.42 2 L N 418.42 434.56 418.42 435.42 2 L N 420.82 434.56 420.82 435.42 2 L N 423.19 434.56 423.19 435.42 2 L N 425.59 434.56 425.59 435.42 2 L N 427.99 434.56 427.99 435.42 2 L N 370.69 434.56 370.69 435.42 2 L N 382.62 434.56 382.62 435.42 2 L N 394.56 434.56 394.56 435.42 2 L N 406.49 434.56 406.49 435.42 2 L N 418.42 434.56 418.42 435.42 2 L N 370.69 434.56 427.99 434.56 2 L 1 X N 370.69 441.04 427.99 441.04 2 L N 370.69 447.52 427.99 447.52 2 L N 370.69 453.95 427.99 453.95 2 L N 370.69 460.42 427.99 460.42 2 L N 370.69 466.96 427.99 466.96 2 L N 370.69 434.56 427.99 434.56 2 L N 370.69 441.04 427.99 441.04 2 L N 370.69 447.52 427.99 447.52 2 L N 370.69 453.95 427.99 453.95 2 L N 370.69 460.42 427.99 460.42 2 L N 370.69 466.96 427.99 466.96 2 L N 1 F 0 X (0) 365.81 433.15 T (20) 362.31 446.11 T (40) 362.31 459.02 T 370.69 453.08 377.82 462.91 380.22 459.02 382.62 457.78 389.79 455.19 396.92 454.43 399.32 454.43 408.89 453.78 411.26 453.78 427.99 453.73 10 L N 369.82 453.08 371.57 453.08 2 L N 370.69 454.38 370.69 451.79 2 L N 370.11 452.22 371.27 453.95 2 L N 370.11 453.95 371.27 452.22 2 L N 376.95 462.91 378.7 462.91 2 L N 377.82 464.2 377.82 461.61 2 L N 377.24 462.05 378.4 463.77 2 L N 377.24 463.77 378.4 462.05 2 L N 379.35 459.02 381.1 459.02 2 L N 380.22 460.32 380.22 457.73 2 L N 379.64 458.16 380.81 459.89 2 L N 379.64 459.89 380.81 458.16 2 L N 381.75 457.78 383.5 457.78 2 L N 382.62 459.08 382.62 456.48 2 L N 382.04 456.92 383.21 458.64 2 L N 382.04 458.64 383.21 456.92 2 L N 388.92 455.19 390.67 455.19 2 L N 389.79 456.48 389.79 453.89 2 L N 389.21 454.32 390.37 456.05 2 L N 389.21 456.05 390.37 454.32 2 L N 396.05 454.43 397.8 454.43 2 L N 396.92 455.73 396.92 453.14 2 L N 396.34 453.57 397.5 455.3 2 L N 396.34 455.3 397.5 453.57 2 L N 398.45 454.43 400.2 454.43 2 L N 399.32 455.73 399.32 453.14 2 L N 398.74 453.57 399.9 455.3 2 L N 398.74 455.3 399.9 453.57 2 L N 408.02 453.78 409.76 453.78 2 L N 408.89 455.08 408.89 452.49 2 L N 408.31 452.92 409.47 454.65 2 L N 408.31 454.65 409.47 452.92 2 L N 410.38 453.78 412.13 453.78 2 L N 411.26 455.08 411.26 452.49 2 L N 410.67 452.92 411.84 454.65 2 L N 410.67 454.65 411.84 452.92 2 L N 427.12 453.73 428.86 453.73 2 L N 427.99 455.02 427.99 452.43 2 L N 427.41 452.86 428.57 454.59 2 L N 427.41 454.59 428.57 452.86 2 L N 333.44 374.76 333.44 407.16 390.74 407.16 390.74 374.76 333.44 374.76 333.44 375.62 6 L N 335.81 374.76 335.81 375.62 2 L N 338.21 374.76 338.21 375.62 2 L N 340.57 374.76 340.57 375.62 2 L N 342.97 374.76 342.97 375.62 2 L N 345.38 374.76 345.38 375.62 2 L N 347.74 374.76 347.74 375.62 2 L N 350.14 374.76 350.14 375.62 2 L N 352.54 374.76 352.54 375.62 2 L N 354.91 374.76 354.91 375.62 2 L N 357.31 374.76 357.31 375.62 2 L N 359.67 374.76 359.67 375.62 2 L N 362.07 374.76 362.07 375.62 2 L N 364.48 374.76 364.48 375.62 2 L N 366.84 374.76 366.84 375.62 2 L N 369.24 374.76 369.24 375.62 2 L N 371.64 374.76 371.64 375.62 2 L N 374.01 374.76 374.01 375.62 2 L N 376.41 374.76 376.41 375.62 2 L N 378.77 374.76 378.77 375.62 2 L N 381.17 374.76 381.17 375.62 2 L N 383.57 374.76 383.57 375.62 2 L N 385.94 374.76 385.94 375.62 2 L N 388.34 374.76 388.34 375.62 2 L N 390.74 374.76 390.74 375.62 2 L N 333.44 374.76 333.44 375.62 2 L N 345.38 374.76 345.38 375.62 2 L N 357.31 374.76 357.31 375.62 2 L N 369.24 374.76 369.24 375.62 2 L N 381.17 374.76 381.17 375.62 2 L N 333.44 374.76 390.74 374.76 2 L 1 X N 333.44 381.24 390.74 381.24 2 L N 333.44 387.72 390.74 387.72 2 L N 333.44 394.2 390.74 394.2 2 L N 333.44 400.68 390.74 400.68 2 L N 333.44 407.16 390.74 407.16 2 L N 333.44 374.76 390.74 374.76 2 L N 333.44 387.72 390.74 387.72 2 L N 333.44 400.68 390.74 400.68 2 L N 333.44 381.08 340.57 383.94 342.97 382.43 345.38 382.05 352.54 381.19 359.67 380.92 362.07 381.02 371.64 380.81 374.01 380.81 390.74 381.13 10 L 0 X N 0 Z 90 450 0.87 1.3 333.44 381.08 A 90 450 0.87 1.3 340.57 383.94 A 90 450 0.87 1.3 342.97 382.43 A 90 450 0.87 1.3 345.38 382.05 A 90 450 0.87 1.3 352.54 381.19 A 90 450 0.87 1.3 359.67 380.92 A 90 450 0.87 1.3 362.07 381.02 A 90 450 0.87 1.3 371.64 380.81 A 90 450 0.87 1.3 374.01 380.81 A 90 450 0.87 1.3 390.74 381.13 A 333.44 377.08 340.57 375.62 342.97 375.62 345.38 375.62 352.54 375.62 359.67 375.79 362.07 375.79 371.64 375.89 374.01 375.89 390.74 376.7 10 L 1 Z N 332.57 378.38 333.44 375.79 334.32 378.38 332.57 378.38 4 L N 339.7 376.92 340.57 374.33 341.45 376.92 339.7 376.92 4 L N 342.1 376.92 342.97 374.33 343.85 376.92 342.1 376.92 4 L N 344.5 376.92 345.38 374.33 346.25 376.92 344.5 376.92 4 L N 351.67 376.92 352.54 374.33 353.42 376.92 351.67 376.92 4 L N 358.8 377.08 359.67 374.49 360.55 377.08 358.8 377.08 4 L N 361.2 377.08 362.07 374.49 362.95 377.08 361.2 377.08 4 L N 370.77 377.19 371.64 374.6 372.52 377.19 370.77 377.19 4 L N 373.13 377.19 374.01 374.6 374.88 377.19 373.13 377.19 4 L N 389.87 378 390.74 375.41 391.61 378 389.87 378 4 L N 409.14 374.76 409.14 407.16 466.44 407.16 466.44 374.76 409.14 374.76 409.14 375.62 6 L N 411.51 374.76 411.51 375.62 2 L N 413.91 374.76 413.91 375.62 2 L N 416.27 374.76 416.27 375.62 2 L N 418.67 374.76 418.67 375.62 2 L N 421.07 374.76 421.07 375.62 2 L N 423.44 374.76 423.44 375.62 2 L N 425.84 374.76 425.84 375.62 2 L N 428.24 374.76 428.24 375.62 2 L N 430.61 374.76 430.61 375.62 2 L N 433.01 374.76 433.01 375.62 2 L N 435.37 374.76 435.37 375.62 2 L N 437.77 374.76 437.77 375.62 2 L N 440.17 374.76 440.17 375.62 2 L N 442.54 374.76 442.54 375.62 2 L N 444.94 374.76 444.94 375.62 2 L N 447.34 374.76 447.34 375.62 2 L N 449.7 374.76 449.7 375.62 2 L N 452.11 374.76 452.11 375.62 2 L N 454.47 374.76 454.47 375.62 2 L N 456.87 374.76 456.87 375.62 2 L N 459.27 374.76 459.27 375.62 2 L N 461.64 374.76 461.64 375.62 2 L N 464.04 374.76 464.04 375.62 2 L N 466.44 374.76 466.44 375.62 2 L N 409.14 374.76 409.14 375.62 2 L N 421.07 374.76 421.07 375.62 2 L N 433.01 374.76 433.01 375.62 2 L N 444.94 374.76 444.94 375.62 2 L N 456.87 374.76 456.87 375.62 2 L N 409.14 374.76 466.44 374.76 2 L 1 X N 409.14 381.24 466.44 381.24 2 L N 409.14 387.72 466.44 387.72 2 L N 409.14 394.2 466.44 394.2 2 L N 409.14 400.68 466.44 400.68 2 L N 409.14 407.16 466.44 407.16 2 L N 409.14 374.76 466.44 374.76 2 L N 409.14 387.72 466.44 387.72 2 L N 409.14 400.68 466.44 400.68 2 L N 409.14 388.04 416.27 387.45 418.67 386.37 421.07 386.05 428.24 387.4 435.37 387.45 437.77 387.4 447.34 387.5 449.7 387.67 466.44 387.45 10 L 0 X N 0 Z 90 450 0.87 1.3 409.14 388.04 A 90 450 0.87 1.3 416.27 387.45 A 90 450 0.87 1.3 418.67 386.37 A 90 450 0.87 1.3 421.07 386.05 A 90 450 0.87 1.3 428.24 387.4 A 90 450 0.87 1.3 435.37 387.45 A 90 450 0.87 1.3 437.77 387.4 A 90 450 0.87 1.3 447.34 387.5 A 90 450 0.87 1.3 449.7 387.67 A 90 450 0.87 1.3 466.44 387.45 A 409.14 389.66 416.27 385.51 418.67 385.78 421.07 385.88 428.24 388.48 435.37 388.75 437.77 388.58 447.34 388.85 449.7 389.12 466.44 388.85 10 L 1 Z N 408.27 390.96 409.14 388.37 410.01 390.96 408.27 390.96 4 L N 415.4 386.8 416.27 384.21 417.14 386.8 415.4 386.8 4 L N 417.8 387.07 418.67 384.48 419.55 387.07 417.8 387.07 4 L N 420.2 387.18 421.07 384.59 421.95 387.18 420.2 387.18 4 L N 427.37 389.77 428.24 387.18 429.11 389.77 427.37 389.77 4 L N 434.5 390.04 435.37 387.45 436.24 390.04 434.5 390.04 4 L N 436.9 389.88 437.77 387.29 438.64 389.88 436.9 389.88 4 L N 446.47 390.15 447.34 387.56 448.21 390.15 446.47 390.15 4 L N 448.83 390.42 449.7 387.83 450.58 390.42 448.83 390.42 4 L N 465.57 390.15 466.44 387.56 467.31 390.15 465.57 390.15 4 L N 0 0 0 0 1 1 1 K 537.21 319.09 537.21 329.74 575.88 329.74 575.88 319.09 4 Y 7 X 0 0 0 0 1 1 1 K V 0 H 0 Z N 0 0 0 1 0 0 0 K 368.58 360.35 378.37 360.35 2 L 0.5 H 1 Z 0 X 0 0 0 1 0 0 0 K N 0 Z 90 450 1.73 1.73 368.58 360.35 A 90 450 1.73 1.73 378.37 360.35 A (Total execution time in millions of cycles) 387.57 357.21 T 368.58 351.71 378.37 351.71 2 L 1 Z N 366.85 353.07 368.58 350.36 370.31 353.07 366.85 353.07 4 L N (Average memory access time in cycles \050AMAT\051) 387.57 348.58 T 376.64 353.07 378.37 350.36 380.1 353.07 376.64 353.07 4 L N (Dynamic instruction count in millions) 394.71 419.75 T 0 0 0 1 0 0 0 K J 0 0 0 1 0 0 0 K 3 F (0) 368.94 427.23 T (5) 380.87 427.23 T (10) 390.86 427.23 T (15) 402.79 427.23 T (20) 414.72 427.23 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (0) 407.31 367.67 T (5) 419.25 367.67 T (10) 429.23 367.67 T (15) 441.17 367.67 T (20) 453.1 367.67 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (0) 482.71 367.3 T (5) 494.64 367.3 T (10) 504.63 367.3 T (15) 516.56 367.3 T (20) 528.5 367.3 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (0) 331.39 367.58 T (5) 343.33 367.58 T (10) 353.31 367.58 T (15) 365.25 367.58 T (20) 377.18 367.58 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (0) 404.02 372.94 T (10) 400.13 385.9 T (20) 400.13 398.86 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (0) 328.3 372.85 T (10) 324.4 385.8 T (20) 324.4 398.76 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 1 F (0) 479.84 431.84 T (20) 476.34 444.8 T (40) 476.34 457.71 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K (b\051) 434.4 409.42 T (c\051) 511.14 409.42 T 4 F (a\051) 356.27 409.25 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 325.36 285.66 549.77 335.54 R 7 X V 4 10 Q 0 X 1.03 (Figure 8: T) 325.36 328.87 P 1.03 (iling performance of 8-thread mxm.) 378.37 328.87 P 3 9 Q 0.37 (T) 325.36 318.54 P 0.37 (ile sizes are along the x-axis. Results are shown for a\051) 330.53 318.54 P 2.98 (blocked tiling and the larger memory subsystem, b\051) 325.36 308.54 P 0.98 (blocked tiling with the smaller memory subsystem, and) 325.36 298.54 P (c\051 cyclic tiling, also with the smaller memory subsystem.) 325.36 288.54 T 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 316.29 277.58 553.5 478.54 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "9" 9 %%Page: "10" 10 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 0 12 Q 0 X (8) 58.5 712 T (Other compiler optimizations) 76.5 712 T 1 10 Q 0.58 (In addition to the optimizations studied in this paper,) 76.5 693.83 P 2.47 (compiler-directed prefetching, predicated execution and) 58.5 682.33 P 2.84 (software pipelining should also be re-evaluated in the) 58.5 670.83 P (context of an SMT processor.) 58.5 659.33 T 6.44 (On a conventional processor, compiler-directed) 76.5 647.83 P 3.32 (prefetching [26] can be useful for tolerating memory) 58.5 636.18 P 1.79 (latencies, as long as prefetch overhead \050due to prefetch) 58.5 624.68 P 1.19 (instructions, additional memory bandwidth, and/or cache) 58.5 613.18 P 2.24 (interference\051 is minimal. On an SMT, this overhead is) 58.5 601.68 P 2.03 (more detrimental: it interferes not only with the thread) 58.5 590.18 P 4.07 (doing the prefetching, but also competes with other) 58.5 578.68 P (threads.) 58.5 567.18 T 1.27 (Predicated execution [23][16][28] is an architectural) 76.5 555.53 P 1.2 (model in which instruction execution can be guarded by) 58.5 544.03 P 1.23 (boolean predicates that determine whether an instruction) 58.5 532.53 P 1.44 (should be executed or nullified. Compilers can then use) 58.5 521.03 P 2.06 (if-conversion [2] to transform control dependences into) 58.5 509.37 P 4.38 (data dependences, thereby exposing more ILP. Like) 58.5 497.87 P 4 (software speculative execution, aggressive predication) 58.5 486.37 P 2.71 (can incur additional instruction overhead by executing) 58.5 474.87 P 2.76 (instructions that are either nullified or produce results) 58.5 463.37 P (that are never used.) 58.5 451.87 T 12.66 (Software pipelining [9][27][18][1] improves) 76.5 440.22 P 2.62 (instruction scheduling by overlapping the execution of) 58.5 428.72 P 3.26 (multiple loop iterations. Rather than pipelining loops,) 58.5 417.22 P 1.69 (SMT can execute them in parallel in separate hardware) 58.5 405.72 P 5.26 (contexts. Doing so alleviates the increased register) 58.5 394.22 P 3.14 (pressure normally associated with software pipelining.) 58.5 382.72 P 3.26 (Multithreading could also be combined with software) 58.5 371.22 P (pipelining if necessary.) 58.5 359.72 T 2.88 (Most of the optimizations discussed in this paper) 76.5 348.22 P 2.48 (were originally designed to increase single-thread ILP.) 58.5 336.72 P 2.99 (While intra-thread parallelism is still important on an) 58.5 325.22 P 3.36 (SMT processor, simultaneous multithreading relies on) 58.5 313.72 P 5.44 (multiple threads to provide useful parallelism, and) 58.5 302.22 P 0.86 (throughput often becomes a more important performance) 58.5 290.72 P 0.75 (metric. SMT raises the issue of compiling for throughput) 58.5 279.22 P 0.92 (or for a single-thread. For example, from the perspective) 58.5 267.72 P 5.06 (of a single running thread, these optimizations, as) 58.5 256.22 P 3.75 (traditionally applied, may be desirable to reduce the) 58.5 244.72 P 3.08 (thread\325s running time. But from a global perspective,) 58.5 233.22 P 1.18 (greater throughput \050and therefore more useful work\051 can) 58.5 221.72 P (be achieved by limiting the amount of speculative work.) 58.5 210.22 T 0 12 Q (9) 58.5 189.39 T (Related work) 76.5 189.39 T 1 10 Q 2.48 (The three compiler optimizations discussed in this) 76.5 171.22 P 6.14 (paper have been widely investigated in non-SMT) 58.5 159.72 P 5.81 (architectures. Loop iteration scheduling for shared-) 58.5 148.22 P 0.62 (memory multiprocessors has been evaluated by Wolf and) 58.5 136.72 P 3.04 (Lam [34], Carr, McKinley, and Tseng [7], Anderson,) 58.5 125.07 P 2.48 (Amarasinghe, and Lam [3], and Cierniak and Li [10],) 58.5 113.41 P 3.99 (among others. These studies focus on scheduling to) 58.5 101.91 P 1.56 (minimize communication and synchronization overhead;) 58.5 90.41 P 322 79.33 556 718.33 R 7 X V 0 X 1.48 (all restructured loops and data layout to improve access) 322 711.67 P 0.72 (locality for each processor. In particular, Anderson et al.,) 322 700.17 P 2.8 (discuss the blocked and cyclic mapping schemes, and) 322 688.67 P (present a heuristic for choosing between them.) 322 677.17 T 11.02 (Global scheduling optimizations, like trace) 340 665.67 P 1.6 (scheduling [22], superblocks [25] and hyperblocks [23],) 322 654.01 P 1.13 (allow code motion \050including speculative motion\051 across) 322 642.51 P 2.08 (basic blocks, thereby exposing more ILP for statically-) 322 631.01 P 2.3 (scheduled VLIWs and wide-issue superscalars. In their) 322 619.51 P 2.54 (study on ILP limits, Lam and Wilson [19] found that) 322 607.86 P 4.64 (speculation provides greater speedups on loop-based) 322 596.36 P 3.59 (numeric applications than on non-numeric codes, but) 322 584.86 P 3.21 (their study did not include the effects of wrong-path) 322 573.36 P (instructions.) 322 561.86 T 1.65 (Previous work in code transformation for improved) 340 550.36 P 0.76 (locality has proposed various frameworks and algorithms) 322 538.86 P 9.58 (for selecting and applying a range of loop) 322 527.36 P 6.54 (transformations [14][33][6][17][34][7]. These studies) 322 515.71 P 3.63 (illustrate the effectiveness of tiling and also propose) 322 504.21 P 4.24 (other loop transformations for enabling better tiling.) 322 492.71 P 1.53 (Lam, Rothberg, and Wolf [20], Coleman and McKinley) 322 481.05 P 6.37 ([11], and Carr et al., [6] show that application) 322 469.4 P 3.46 (performance is sensitive to the tile size, and present) 322 457.9 P 1.33 (techniques for selecting tile sizes based on problem-size) 322 446.4 P 1.85 (and cache parameters, rather than targeting a fixed-size) 322 434.9 P (or fixed-cache occupancy.) 322 423.4 T 0 12 Q (10) 322 402.57 T (Conclusions) 340 402.57 T 1 10 Q 1.84 (This paper has examined compiler optimizations in) 340 384.4 P 0.53 (the context of a simultaneous multithreading architecture.) 322 372.9 P 4.84 (An SMT architecture differs from previous parallel) 322 361.4 P 4.19 (architectures in several significant ways. First, SMT) 322 349.9 P 0.94 (threads share processor and memory system resources of) 322 338.4 P 1.13 (a) 322 326.9 P 2 F 1.13 (single) 330.07 326.9 P 1 F 1.13 ( processor on a fine-grained basis, even within a) 353.96 326.9 P 1.13 (single cycle. Optimizations for an SMT should therefore) 322 315.4 P 0.68 (seek to benefit from this fine-grained sharing, rather than) 322 303.9 P 2.08 (avoiding it, as is done on conventional shared-memory) 322 292.4 P 9.48 (multiprocessors. Second, SMT hides intra-thread) 322 280.9 P 1.09 (latencies by using instructions from other active threads;) 322 269.4 P 0.85 (optimizations that expose ILP may not be needed. Third,) 322 257.9 P 3.79 (instruction throughput on an SMT is high; therefore) 322 246.4 P 0.49 (optimizations that increase instruction count may degrade) 322 234.9 P (performance.) 322 223.4 T 2.48 (An effective compilation strategy for simultaneous) 340 211.9 P 2.86 (multithreading processors must recognize these unique) 322 200.4 P 1.14 (characteristics. Our results show specific cases where an) 322 188.9 P 1.73 (SMT processor can benefit from changing the compiler) 322 177.4 P 1.97 (optimization strategy. In particular, we showed that \0501\051) 322 165.9 P 5.67 (cyclic iteration scheduling \050as opposed to blocked) 322 154.4 P 1.3 (scheduling\051 is more appropriate for an SMT, because of) 322 142.9 P 3.7 (its ability to reduce the TLB footprint; \0502\051 software) 322 131.4 P 0.94 (speculative execution can be bad for an SMT, because it) 322 119.9 P 2.71 (decreases useful instruction throughput; \0503\051 loop tiling) 322 108.4 P 2.28 (algorithms can be less concerned with determining the) 322 96.9 P 0.33 (exact tile size, because SMT performance is less sensitive) 322 85.4 P 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "10" 10 %%Page: "11" 11 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 10 Q 0 X 2.15 (to tile size; and \0504\051 loop tiling to increase, rather than) 58.5 713.33 P 1.65 (reduce, inter-thread tile sharing, is more appropriate for) 58.5 701.83 P 3.73 (an SMT, because it increases the benefit of sharing) 58.5 690.33 P (memory system resources.) 58.5 678.83 T 0 12 Q (Acknowledgments) 58.5 658 T 1 10 Q 1.31 (We would like to thank John O\325Donnell of Equator) 76.5 639.83 P 5.3 (Technologies, Inc. and Tryggve Fossum of Digital) 58.5 628.33 P 4.15 (Equipment Corp. for the source to the Alpha AXP) 58.5 616.83 P 7.24 (version of the Multiflow compiler; and Jennifer) 58.5 605.33 P 1.57 (Anderson of the DEC Western Research Laboratory for) 58.5 593.83 P 5.95 (providing us with SUIF-parallelized copies of the) 58.5 582.33 P 3.35 (SPECfp95 benchmarks. We also would like to thank) 58.5 570.83 P 3.53 (Jeffrey Dean of DEC WRL and the referees, whose) 58.5 559.33 P 1.37 (comments helped improve this paper. This research was) 58.5 547.83 P 2.29 (supported by the Washington Technology Center, NSF) 58.5 536.33 P 1.21 (grants MIP-9632977, CCR-9200832, and CCR-9632769,) 58.5 524.83 P 1.58 (DARPA grant F30602-97-2-0226, ONR grants N00014-) 58.5 513.33 P 3.45 (92-J-1395 and N00014-94-1-1136, DEC WRL, and a) 58.5 501.83 P (fellowship from Intel Corporation.) 58.5 490.33 T 0 12 Q (References) 58.5 467.5 T 1 8 Q ([1]) 58.5 447.17 T -0.44 (A.) 75.18 447.17 P -0.44 (Aiken and A.) 84.96 447.17 P -0.44 (Nicolau. Optimal loop parallelization. In) 128.95 447.17 P 2 F -0.44 (ACM SIG-) 258.95 447.17 P -0.03 (PLAN \32588 Conf. on Programming Language Design and Implemen-) 75.2 438.17 P (tation) 75.2 429.17 T 1 F (, p. 308\320317, June 1988.) 93.88 429.17 T ([2]) 58.5 417.17 T -0.49 (J.) 75.18 417.17 P -0.49 (Allen, et al. Conversion of control dependence to data dependence.) 82.29 417.17 P -0.09 (In) 75.2 408.17 P 2 F -0.09 (Conf. Record of the Tenth Ann. ACM Symp. on Principles of Pro-) 83.77 408.17 P (gramming Languages) 75.2 399.17 T 1 F (, p. 177\320189, January 1983.) 145.2 399.17 T ([3]) 58.5 387.17 T 0.17 (J.) 75.18 387.17 P 0.17 (M. Anderson, S.) 82.29 387.17 P 0.17 (P. Amarasinghe, and M.) 137.3 387.17 P 0.17 (S. Lam. Data and com-) 217.6 387.17 P 1.52 (putation transformations for multiprocessors. In) 75.2 378.17 P 2 F 1.52 (Fifth ACM SIG-) 237.91 378.17 P 0.09 (PLAN Symp. on Principles & Practice of Parallel Programming) 75.2 369.17 P 1 F 0.09 (, p.) 282.4 369.17 P (166\320178, July 1995.) 75.2 360.17 T ([4]) 58.5 348.17 T 1.28 (J.) 75.18 348.17 P 1.28 (Boyle, et al.) 82.29 348.17 P 2 F 1.28 (Portable Programs for Parallel Processors) 126.78 348.17 P 1 F 1.28 (. Holt,) 271 348.17 P (Rinehart, and Winston, Inc., 1987.) 75.2 339.17 T ([5]) 58.5 327.17 T 0.16 (E.) 75.18 327.17 P 0.16 (Bugnion, et al. Compiler-directed page coloring for multiproces-) 84.07 327.17 P 0.52 (sors. In) 75.2 318.17 P 2 F 0.52 (Seventh Int\325l Conf. on Architectural Support for Program-) 101.79 318.17 P -0.22 (ming Languages and Operating Systems) 75.2 309.17 P 1 F -0.22 (, p. 244\320255, October 1997.) 203.63 309.17 P ([6]) 58.5 297.17 T 0.7 (S.) 75.18 297.17 P 0.7 (Carr and K.) 83.63 297.17 P 0.7 (Kennedy. Compiler blockability of numerical algo-) 124.57 297.17 P (rithms. In) 75.2 288.17 T 2 F (Supercomputing \32592) 108.32 288.17 T 1 F (, p. 114\320124, November 1992.) 173.42 288.17 T ([7]) 58.5 276.17 T 0.32 (S.) 75.18 276.17 P 0.32 (Carr, K.) 83.63 276.17 P 0.32 (S. McKinley, and C.) 111.94 276.17 P 0.32 (W. Tseng. Compiler optimizations) 180.66 276.17 P -0.4 (for improving data locality. In) 75.2 267.17 P 2 F -0.4 (Sixth Int\325l Conf. on Architectural Sup-) 171.85 267.17 P 0.55 (port for Programming Languages and Operating Systems) 75.2 258.17 P 1 F 0.55 (, p. 252\320) 263.4 258.17 P (262, October 1994.) 75.2 249.17 T ([8]) 58.5 237.17 T 0.17 (L.) 75.18 237.17 P 0.17 (Carter, J.) 84.07 237.17 P 0.17 (Ferrante, and S.) 115.34 237.17 P 0.17 (F. Hummel. Hierarchical tiling for im-) 168.34 237.17 P 0.81 (proved superscalar performance. In) 75.2 228.17 P 2 F 0.81 (Proceedings of the Ninth Int\325l) 193.72 228.17 P (Parallel Processing Symp.) 75.2 219.17 T 1 F (, p. 239\320245, April 1995.) 160.31 219.17 T ([9]) 58.5 207.17 T -0.05 (A.) 75.18 207.17 P -0.05 (E. Charlesworth. An approach to scientific array processing: The) 84.96 207.17 P -0.38 (architectural design of the AP-120B/FPS-164 family.) 75.2 198.17 P 2 F -0.38 (IEEE Comput-) 245.56 198.17 P (er) 75.2 189.17 T 1 F (, 14\0509\051:18\32027, December 1981.) 81.87 189.17 T ([10]) 58.5 177.17 T 0.83 (M.) 75.18 177.17 P 0.83 (Cierniak and W.) 86.29 177.17 P 0.83 (Li. Unifying data and control transformations) 142.6 177.17 P 1.59 (for distributed shared-memory machines. In) 75.2 168.17 P 2 F 1.59 (ACM SIGPLAN \32595) 225.77 168.17 P 1.14 (Conf. on Programming Language Design and Implementation) 75.2 159.17 P 1 F 1.14 (, p.) 281.36 159.17 P (205\320217, June 1995.) 75.2 150.17 T ([11]) 58.5 138.17 T 0.12 (S.) 75.18 138.17 P 0.12 (Coleman and K.) 83.63 138.17 P 0.12 (S. McKinley. Tile size selection using cache or-) 138.09 138.17 P 1.07 (ganization and data layout. In) 75.2 129.17 P 2 F 1.07 (ACM SIGPLAN \32595 Conf. on Pro-) 177.4 129.17 P 0.12 (gramming Language Design and Implementation) 75.2 120.17 P 1 F 0.12 (, p. 279\320290, June) 233.47 120.17 P (1995.) 75.2 111.17 T ([12]) 58.5 99.17 T 0.78 (K.) 75.18 99.17 P 0.78 (Dixit. New CPU benchmark suites from SPEC. In) 84.96 99.17 P 2 F 0.78 (COMPCON) 253.39 99.17 P (\32592 digest of papers) 75.2 90.17 T 1 F (, p. 305\320310, February 1992.) 138.98 90.17 T 319.5 81 553.5 720 R 7 X V 0 X ([13]) 319.5 714.67 T -0.44 (S.) 336.18 714.67 P -0.44 (J. Eggers, et al. Simultaneous multithreading: A platform for next-) 344.63 714.67 P (generation processors. In) 336.2 705.67 T 2 F (IEEE Micro) 418.4 705.67 T 1 F (, October 1997.) 457.28 705.67 T ([14]) 319.5 693.67 T -0.41 (D.) 336.18 693.67 P -0.41 (Gannon, W.) 345.96 693.67 P -0.41 (Jalby, and K.) 386.42 693.67 P -0.41 (Gallivan. Strategies for cache and local) 429.82 693.67 P 0.39 (memory management by global program transformation.) 336.2 684.67 P 2 F 0.39 (J. of Par-) 522.28 684.67 P (allel and Distributed Computing) 336.2 675.67 T 1 F (, 5\0505\051:587\320616, October 1988.) 440.44 675.67 T ([15]) 319.5 663.67 T 0.03 (M.) 336.18 663.67 P 0.03 (W. Hall, et al. Maximizing multiprocessor performance with the) 347.29 663.67 P (SUIF compiler.) 336.2 654.67 T 2 F (IEEE Computer) 387.98 654.67 T 1 F (, 29\05012\051:84\32089, December 1996.) 439.31 654.67 T ([16]) 319.5 642.67 T 1.56 (P.) 336.18 642.67 P 1.56 (Hsu and E.) 344.63 642.67 P 1.56 (Davidson. Highly concurrent scalar processing. In) 385.07 642.67 P 2 F 0.49 (13th Ann. Int\325l Symp. on Computer Architecture) 336.2 633.67 P 1 F 0.49 (, p. 386\320395, June) 493.36 633.67 P (1986.) 336.2 624.67 T ([17]) 319.5 612.67 T 0.29 (K.) 336.18 612.67 P 0.29 (Kennedy and K.) 345.96 612.67 P 0.29 (S. McKinley. Maximizing loop parallelism and) 400.74 612.67 P -0.4 (improving data locality via loop fusion and distribution. In) 336.2 603.67 P 2 F -0.4 (Languag-) 522.39 603.67 P 1.08 (es and Compilers for Parallel Computing, 6th Int\325l Workshop) 336.2 594.67 P 1 F 1.08 (, p.) 542.42 594.67 P (301\320319. August 1993.) 336.2 585.67 T ([18]) 319.5 573.67 T -0.12 (M.) 336.18 573.67 P -0.12 (Lam. Software pipelining: An effective scheduling technique for) 347.29 573.67 P 1.44 (VLIW machines. In) 336.2 564.67 P 2 F 1.44 (ACM SIGPLAN \32588 Conf. on Programming) 406.29 564.67 P (Language Design and Implementation) 336.2 555.67 T 1 F (, p. 318\320328, June 1988.) 459.08 555.67 T ([19]) 319.5 543.67 T 1.16 (M.) 336.18 543.67 P 1.16 (Lam and R.) 347.29 543.67 P 1.16 (Wilson. Limits of control flow on parallelism. In) 389.16 543.67 P 2 F 1.38 (19th Ann. Int\325l Symp. on Computer Architecture) 336.2 534.67 P 1 F 1.38 (, p. 46\32057, May) 498.7 534.67 P (1992.) 336.2 525.67 T ([20]) 319.5 513.67 T -0.17 (M.) 336.18 513.67 P -0.17 (S. Lam, E.) 347.29 513.67 P -0.17 (E. Rothberg, and M.) 382.95 513.67 P -0.17 (E. Wolf. The cache performance) 449.77 513.67 P -0.49 (and optimizations of blocked algorithms. In) 336.2 504.67 P 2 F -0.49 (Fourth Int\325l Conf. on Ar-) 475.24 504.67 P 1.85 (chitectural Support for Programming Languages and Operating) 336.2 495.67 P (Systems) 336.2 486.67 T 1 F (, p. 63\32074, April 1991.) 361.53 486.67 T ([21]) 319.5 474.67 T -0.3 (J.) 336.18 474.67 P -0.3 (L. Lo, et al. Converting thread-level parallelism to instruction-lev-) 343.29 474.67 P 2.18 (el parallelism via simultaneous multithreading.) 336.2 465.67 P 2 F 2.18 (ACM Trans. on) 499.57 465.67 P (Computer and Systems) 336.2 456.67 T 1 F (, 15\0503\051, August 1997.) 409.53 456.67 T ([22]) 319.5 444.67 T 0.2 (P.) 336.18 444.67 P 0.2 (G. Lowney, et al. The Multiflow trace scheduling compiler.) 344.63 444.67 P 2 F 0.2 (J. of) 539.52 444.67 P (Supercomputing) 336.2 435.67 T 1 F (, 7\0501/2\051:51\320142, May 1993.) 388.64 435.67 T ([23]) 319.5 423.67 T -0.29 (S.) 336.18 423.67 P -0.29 (A. Mahlke, et al. Effective compiler support for predicated execu-) 344.63 423.67 P -0.1 (tion using the hyperblock. In) 336.2 414.67 P 2 F -0.1 (25th Int\325l Symp. on Microarchitecture) 429.92 414.67 P 1 F -0.1 (,) 551.5 414.67 P (p. 45\32054, December 1992.) 336.2 405.67 T ([24]) 319.5 393.67 T 0.45 (S.) 336.18 393.67 P 0.45 (McFarling. Combining branch predictors. Technical Report TN-) 344.63 393.67 P (36, DEC-Western Research Laboratory, June 1993.) 336.2 384.67 T ([25]) 319.5 372.67 T -0.19 (W.W.) 336.18 372.67 P -0.19 (Hwu, et al. The superblock: An effective technique for VLIW) 357.28 372.67 P -0.08 (and superscalar compilation.) 336.2 363.67 P 2 F -0.08 (J. of Supercomputing) 429.74 363.67 P 1 F -0.08 (, 7\0501/2\051:229\320248,) 497.8 363.67 P (May 1993.) 336.2 354.67 T ([26]) 319.5 342.67 T 0.07 (T.) 336.18 342.67 P 0.07 (C. Mowry, M.) 345.07 342.67 P 0.07 (S. Lam, and A.) 393.2 342.67 P 0.07 (Gupta. Design and evaluation of a) 443.85 342.67 P 0.07 (compiler algorithm for prefetching. In) 336.2 333.67 P 2 F 0.07 (Fifth Int\325l Conf. on Architec-) 460.54 333.67 P 0.12 (tural Support for Programming Languages and Operating Systems) 336.2 324.67 P 1 F 0.12 (,) 551.5 324.67 P (p. 62\32075, September 1992.) 336.2 315.67 T ([27]) 319.5 303.67 T -0.27 (B.) 336.18 303.67 P -0.27 (R. Rau and C.) 345.52 303.67 P -0.27 (Glaeser. Some scheduling techniques and an easily) 391.82 303.67 P 0.67 (schedulable horizontal architecture for high performance scientific) 336.2 294.67 P 0.16 (computing. In) 336.2 285.67 P 2 F 0.16 (14th Ann. Workshop on Microprogramming) 383.42 285.67 P 1 F 0.16 (, p. 183\320) 525.17 285.67 P (197, October 1981.) 336.2 276.67 T ([28]) 319.5 264.67 T 1.06 (B.) 336.18 264.67 P 1.06 (R. Rau, et al. The Cydra 5 departmental supercomputer.) 345.52 264.67 P 2 F 1.06 (IEEE) 536.17 264.67 P (Computer) 336.2 255.67 T 1 F (, 22:12\32035, January 1989.) 368.2 255.67 T ([29]) 319.5 243.67 T -0.14 (J.) 336.18 243.67 P -0.14 (P. Singh, J.) 343.29 243.67 P -0.14 (L. Hennessy, and A.) 381.25 243.67 P -0.14 (Gupta. Scaling parallel programs) 448.15 243.67 P 0.81 (for multiprocessors: Methodology and examples.) 336.2 234.67 P 2 F 0.81 (IEEE Computer) 499.36 234.67 P 1 F 0.81 (,) 551.5 234.67 P (27\0507\051:42\32050, July 1993.) 336.2 225.67 T ([30]) 319.5 213.67 T (SPEC.) 336.18 213.67 T 2 F (SPEC CPU \32595 Technical Manual) 359.3 213.67 T 1 F (. August 1995.) 469.52 213.67 T ([31]) 319.5 201.67 T -0.42 (D.) 336.18 201.67 P -0.42 (M. Tullsen, et al. Exploiting choice: Instruction fetch and issue on) 345.96 201.67 P 1.07 (an implementable simultaneous multithreading processor. In) 336.2 192.67 P 2 F 1.07 (23rd) 538.39 192.67 P (Ann. Int\325l Symp. on Computer Architecture) 336.2 183.67 T 1 F (, p. 191\320202, May 1996.) 474.19 183.67 T ([32]) 319.5 171.67 T 0.83 (D.) 336.18 171.67 P 0.83 (M. Tullsen, S.) 345.96 171.67 P 0.83 (J. Eggers, and H.) 395.18 171.67 P 0.83 (M. Levy. Simultaneous multi-) 454.33 171.67 P -0.36 (threading: Maximizing on-chip parallelism. In) 336.2 162.67 P 2 F -0.36 (22nd Ann. Int\325l Symp.) 484.6 162.67 P (on Computer Architecture) 336.2 153.67 T 1 F (, p. 392\320403, June 1995.) 420.2 153.67 T ([33]) 319.5 141.67 T -0.05 (M.) 336.18 141.67 P -0.05 (E. Wolf and M.) 347.29 141.67 P -0.05 (S. Lam. A data locality optimizing algorithm. In) 399.15 141.67 P 2 F 0.58 (ACM SIGPLAN \32591 Conf. on Programming Language Design and) 336.2 132.67 P (Implementation) 336.2 123.67 T 1 F (, p. 30\32044, June 1991.) 386.42 123.67 T ([34]) 319.5 111.67 T 0 (M.) 336.18 111.67 P 0 (E. Wolf and M.) 347.29 111.67 P 0 (S. Lam. A loop transformation theory and an al-) 399.29 111.67 P 0.07 (gorithm to maximize parallelism.) 336.2 102.67 P 2 F 0.07 (IEEE Trans. on Parallel and Dis-) 445.15 102.67 P (tributed Systems) 336.2 93.67 T 1 F (, 2\0504\051:452\320471, October 1991.) 388.87 93.67 T 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "11" 11 %%Page: "12" 12 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] 7 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 58.5 746 553.5 756 R 7 X 0 0 0 1 0 0 0 K V 58.5 38.5 553.5 48.5 R V 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 58.5 81 292.5 720 R V 1 8 Q 0 X ([35]) 58.5 714.67 T 1.09 (S.) 75.18 714.67 P 1.09 (C. Woo, et al. The SPLASH-2 programs: Characterization and) 83.63 714.67 P -0.42 (methodological considerations. In) 75.2 705.67 P 2 F -0.42 (22nd Ann. Int\325l Symp. on Comput-) 184.6 705.67 P (er Architecture) 75.2 696.67 T 1 F (, p. 24\32036, June 1995.) 123.86 696.67 T 319.5 81 553.5 720 R 7 X V 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "12" 12 %%Trailer %%BoundingBox: 0 0 612 792 %%PageOrder: Ascend %%Pages: 12 %%DocumentFonts: Times-Bold %%+ Times-Roman %%+ Times-Italic %%+ Helvetica %%+ Helvetica-Bold %%+ Courier %%+ Courier-Bold %%+ Helvetica-Oblique %%EOF --------------DB100DACB251A8B335A3470A-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01818 for ; Fri, 30 Jun 2000 19:27:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:27 +0200 (MEST) Received: (qmail 4898 invoked by uid 0); 28 Jun 2000 09:20:22 -0000 Received: from ch.egroups.com (207.138.41.144) by mx02.gmx.net with SMTP; 28 Jun 2000 09:20:22 -0000 X-eGroups-Return: sentto-1101623-365-962184014-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 28 Jun 2000 09:20:16 -0000 Received: (qmail 30669 invoked from network); 28 Jun 2000 09:20:14 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 28 Jun 2000 09:20:14 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 28 Jun 2000 09:20:13 -0000 Received: from f-cpu.org (Paris-Raspail-2-226.club-internet.fr [195.36.192.226]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA17525 for ; Wed, 28 Jun 2000 11:20:06 +0200 (MET DST) Message-ID: <3959C312.59FCCCE6@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> <39598EFC.BA19ADD2@welfen-netz.com> <20000628002854.B72862@elvis.paf.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:19:14 +0200 Reply-To: f-cpu@egroups.com Subject: meeting (was : Re: [f-cpu] Some Questions) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f133f5b913c653b3d246c62a0045343a Status: R X-Status: N hallo !

Fabian Sturm wrote:
>
> Hello!
>
> On Wed, Jun 28, 2000 at 07:37:00AM +0200, Kai Wetzel wrote:
> > Yann Guidon wrote:
> > > > I think Paris would be nice.
>
> Perhaps Germany would be also good,
> perhaps we can combine a meeting of all
> people with the creation of the germany f-cpu association?
>
> Would be a nice party.

I have nothing against that : as i said, i wanted to go
during 2 weeks in Germany but : where ?

anyway, if you have any idea, don't hesitate to say it :-)

> CU Fabian
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01821 for ; Fri, 30 Jun 2000 19:27:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:27 +0200 (MEST) Received: (qmail 22364 invoked by uid 0); 28 Jun 2000 09:20:27 -0000 Received: from c3.egroups.com (207.138.41.143) by mx02.gmx.net with SMTP; 28 Jun 2000 09:20:27 -0000 X-eGroups-Return: sentto-1101623-363-962184005-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 28 Jun 2000 09:20:07 -0000 Received: (qmail 30350 invoked from network); 28 Jun 2000 09:20:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Jun 2000 09:20:05 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 28 Jun 2000 09:20:04 -0000 Received: from f-cpu.org (Paris-Raspail-2-226.club-internet.fr [195.36.192.226]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA09561 for ; Wed, 28 Jun 2000 11:20:00 +0200 (MET DST) Message-ID: <3959C30E.BF14EE99@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:19:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 57751ed317e451b39d48e2e11db9a611 Status: R X-Status: N hi,

Albert Abramson wrote:
>
> "Richard E.Hartney" wrote:
> >
<gate delays><gate delays><gate delays>

ok, i think that some ASCII art or even a GIF would help
understand the discussion ;-)

Now, being worried about the <gate delays> is a good thing,
as long as it doesn't shadow the rest of the work.
i try to be as independent as possible from the
technology, because it evolves all the time.
Boole's law, OTOH, doesn't change.
So i try to generalize the design characteristics
and rules, and incorporate them in the schematic
layout, but whether it's in SOI, ECL, AsGa, InP
or Germanium doesn't matter.
"let's make it work first" ;-)
we know that the performance jump of x86 is mostly
due to technology enhancements, not only architecture,
so let's make an architecture that doesn't ONLY
rely on silicon process enhancements to evolve.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01824 for ; Fri, 30 Jun 2000 19:27:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:28 +0200 (MEST) Received: (qmail 19568 invoked by uid 0); 28 Jun 2000 09:20:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx02.gmx.net with SMTP; 28 Jun 2000 09:20:29 -0000 X-eGroups-Return: sentto-1101623-366-962184017-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 28 Jun 2000 09:20:19 -0000 Received: (qmail 4235 invoked from network); 28 Jun 2000 09:20:17 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 28 Jun 2000 09:20:17 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 28 Jun 2000 09:20:16 -0000 Received: from f-cpu.org (Paris-Raspail-2-226.club-internet.fr [195.36.192.226]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA29580 for ; Wed, 28 Jun 2000 11:20:13 +0200 (MET DST) Message-ID: <3959C31A.5BCA9A7@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:19:22 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] "it's alive !... alive !!!" Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 140eb464b347b734caeac9d8f0a181eb Status: R X-Status: N wow :-)
lots of traffic on the mailing lists today,
i'm happy :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01827 for ; Fri, 30 Jun 2000 19:27:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:29 +0200 (MEST) Received: (qmail 5933 invoked by uid 0); 28 Jun 2000 09:20:59 -0000 Received: from ch.egroups.com (207.138.41.144) by mx02.gmx.net with SMTP; 28 Jun 2000 09:20:59 -0000 X-eGroups-Return: sentto-1101623-364-962184009-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 28 Jun 2000 09:20:20 -0000 Received: (qmail 27059 invoked from network); 28 Jun 2000 09:20:09 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 28 Jun 2000 09:20:09 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 28 Jun 2000 09:20:04 -0000 Received: from f-cpu.org (Paris-Raspail-2-226.club-internet.fr [195.36.192.226]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA18867 for ; Wed, 28 Jun 2000 11:20:01 +0200 (MET DST) Message-ID: <3959C30F.42D56385@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39553D57.3D7C857B@welfen-netz.com> <3954DA56.E184D2D@f-cpu.org> <39567439.AD5BFF30@welfen-netz.com> <3956B37C.4F914705@f-cpu.org> <39580678.56911666@welfen-netz.com> <3957CFE5.62020B37@f-cpu.org> <39586598.828508F5@hl.siemens.de> <39598D9A.F636DE93@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:19:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fe6abd9619e947c2f847c2f0a56df49f Status: R X-Status: N hi !

Kai Wetzel wrote:
> What's the status of our FCPU simulators ?
"we think about it" ;-)

the real problem is NOT to write (more) code,
but that the code must be coherent with something
realistic, so before we write the simulator, we must
be sure about what is been done : the discussion
about the adder is an example. Should it be split
and how... etc. this deeply influences the architecture,
more than "will we use VHDL or Verilog" :-)

> > > How much is a copy of Alliance ?
> > nada. nothing. nichts. it's GPL'd.
> > i even have 2 copies on CD. it takes a few hundreds of megabytes for
> > the whole archive, some tens of MB for a working version.
> Hmm, maybe you could send me one which I could copy and then send back ?
if you want. i could send it and you'd give it back when you come to Paris ? :-)

> > it can be downloaded from the web (URL was on a post some months ago)
> Yeah, 28.8 modem here :^(
mee too ;-)
i went directly to the university's rooms where the Alliance site is,
and within a few minutes they burnt me a CD. they're cool :-)
but you can also do the same, go to one university next door,
ask someone to  burn you the CD out off the ftp.

> [...]
> > > I think Paris would be nice.
> > if it's ok, i can host one or two people, maybe three with some efforts
> > (and a sleeping bag :-D) if this happens when one person of my family
> > is in vacations, it will be even easier :-)
> >
> > now, let's find a date. preferably not before three weeks.
>
> Between July 15 - July 25 is ok, July 25 to August 10 isn't, then
> from mid-August is fine.
could be ok.
we'll have to manage this with the whole group, so i expect others
to give their opinion :-)

> [...]
> Regards,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01830 for ; Fri, 30 Jun 2000 19:27:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:29 +0200 (MEST) Received: (qmail 21693 invoked by uid 0); 28 Jun 2000 09:29:06 -0000 Received: from mo.egroups.com (207.138.41.166) by mx12.rz2.gmx.net with SMTP; 28 Jun 2000 09:29:06 -0000 X-eGroups-Return: sentto-1101623-367-962184536-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 28 Jun 2000 09:29:00 -0000 Received: (qmail 16280 invoked from network); 28 Jun 2000 09:28:56 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Jun 2000 09:28:56 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 28 Jun 2000 09:28:55 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5S9SsR17481 for ; Wed, 28 Jun 2000 11:28:54 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5S9Sr429372 for ; Wed, 28 Jun 2000 11:28:53 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id LAA17529 for ; Wed, 28 Jun 2000 11:28:53 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id LAA10561 for ; Wed, 28 Jun 2000 11:27:24 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <3959C553.48B948EB@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 11:28:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 721b2f0ab90610493716d846c3a3eb01 Status: R X-Status: N Yann Guidon wrote:
>
> hi,
>
> Albert Abramson wrote:
> >
> > "Richard E.Hartney" wrote:
> > >
> "let's make it work first" ;-)
> we know that the performance jump of x86 is mostly
> due to technology enhancements, not only architecture,
> so let's make an architecture that doesn't ONLY
> rely on silicon process enhancements to evolve.

Aaaah ! A good point of view. On a C simulator, it's (relatively ;-))
easy to simulate the behavior of 30 (or 5, if you are more shy) millions
transistors that you don't have todays. So it will be possiblw to say,
the ISA doesn't change, but but the better way to do a 1 MT (millions
transistor) FCPU is this one and a 5 MT FCPU is this other one, but with
the same ISA ! I think the compatibility is a very important feature. If
not the tools (like gcc,... ) will hard to be created.

>
> WHYGEE
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01833 for ; Fri, 30 Jun 2000 19:27:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:30 +0200 (MEST) Received: (qmail 24203 invoked by uid 0); 28 Jun 2000 09:33:21 -0000 Received: from mv.egroups.com (208.50.144.81) by mx11.rz2.gmx.net with SMTP; 28 Jun 2000 09:33:21 -0000 X-eGroups-Return: sentto-1101623-368-962184777-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mv.egroups.com with NNFMP; 28 Jun 2000 10:32:59 -0000 Received: (qmail 32273 invoked from network); 28 Jun 2000 09:32:57 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 28 Jun 2000 09:32:57 -0000 Received: from unknown (HELO panther.wmin.ac.uk) (161.74.55.127) by mta1 with SMTP; 28 Jun 2000 09:32:56 -0000 Received: from cougar.wmin.ac.uk ([161.74.160.93] ident=exim) by panther.wmin.ac.uk with esmtp (Exim 2.12 #1) id 137ED9-0006Eh-00 for f-cpu@egroups.com; Wed, 28 Jun 2000 10:32:47 +0100 Received: from collector.hscs.wmin.ac.uk ([161.74.97.54] ident=graham) by cougar.wmin.ac.uk with esmtp (Exim 2.12 #1) id 137EDB-0001xn-00 for f-cpu@egroups.com; Wed, 28 Jun 2000 10:32:49 +0100 Received: (from graham@localhost) by collector.hscs.wmin.ac.uk (8.9.3/8.9.3) id KAA03953 for f-cpu@egroups.com; Wed, 28 Jun 2000 10:51:54 -0400 Message-Id: <200006281451.KAA03953@collector.hscs.wmin.ac.uk> To: f-cpu@egroups.com In-Reply-To: <3959C30F.42D56385@f-cpu.org> from "Yann Guidon" at Jun 28, 0 11:19:11 am From: Graham Seaman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 100 10:51:54 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a07c0a5a2ab463c7da12d7c13b7e6e95 Status: R X-Status: N > > > > How much is a copy of Alliance ?
> > > nada. nothing. nichts. it's GPL'd.
> > > i even have 2 copies on CD. it takes a few hundreds of megabytes for
> > > the whole archive, some tens of MB for a working version.
> > Hmm, maybe you could send me one which I could copy and then send back ?
>
> > > it can be downloaded from the web (URL was on a post some months ago)
> > Yeah, 28.8 modem here :^(
> mee too ;-)
> i went directly to the university's rooms where the Alliance site is,
> and within a few minutes they burnt me a CD. they're cool :-)
> but you can also do the same, go to one university next door,
> ask someone to  burn you the CD out off the ftp.
>
Jamil Khatib of OpenIPCores has put together a CD with a lot of
free EDA stuff, available at cost price. I haven't used the CD
myself, but Alliance is listed on it. There's an order page at
http://www.opencores.org/OIPC/projects/OpenTech/cdrom.shtml

Graham
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01848 for ; Fri, 30 Jun 2000 19:27:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:34 +0200 (MEST) Received: (qmail 1998 invoked by uid 0); 28 Jun 2000 10:15:19 -0000 Received: from hm.egroups.com (208.50.144.92) by mx10.rz2.gmx.net with SMTP; 28 Jun 2000 10:15:19 -0000 X-eGroups-Return: sentto-1101623-369-962187237-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 28 Jun 2000 10:14:05 -0000 Received: (qmail 10189 invoked from network); 28 Jun 2000 10:13:57 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Jun 2000 10:13:57 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 28 Jun 2000 10:13:52 -0000 Received: from f-cpu.org (Aubervilliers-2-195.club-internet.fr [195.36.150.195]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA04919 for ; Wed, 28 Jun 2000 12:13:49 +0200 (MET DST) Message-ID: <3959CF9D.ED915466@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 12:12:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8de9f7e519f50ad3fc1deee45f49f8b9 Status: R X-Status: N

Nicolas Boulay wrote:
>
> I don't remember where i found this paper. But after a cross read, i
> think that it could be a good way to make more than 1 instruction per
> clock cycle efficiently and having a goog way to increase speed in the
> futur with keeping the compatibility.
>

tu aurais au moins pu le comprimer ;-)

SMT is a good way to increase the CPU utilization.
i've been thinking about it for some years, but the first problem
is the huge register bank it requires, so it won't be useful for
the first protos. It will be useful anyway the day we'll want to
beat the Alpha 21464 :-)

before we start adding instructions we should first analyze what's
really needed. but there's no hurry even if i believe more
in SMT than VLIW because it transforms a hazard into a "switch".
OTOH i fear that it will make people believe that it's still OK
to code badly.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01857 for ; Fri, 30 Jun 2000 19:27:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:36 +0200 (MEST) Received: (qmail 5749 invoked by uid 0); 28 Jun 2000 10:41:08 -0000 Received: from mu.egroups.com (207.138.41.151) by mx11.rz2.gmx.net with SMTP; 28 Jun 2000 10:41:08 -0000 X-eGroups-Return: sentto-1101623-370-962188658-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 28 Jun 2000 11:37:55 -0000 Received: (qmail 17799 invoked from network); 28 Jun 2000 10:37:38 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 28 Jun 2000 10:37:38 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta1 with SMTP; 28 Jun 2000 10:37:37 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5SAbaB28499 for ; Wed, 28 Jun 2000 12:37:36 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5SAbZr17243 for ; Wed, 28 Jun 2000 12:37:35 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id MAA20562 for ; Wed, 28 Jun 2000 12:37:35 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id MAA13249 for ; Wed, 28 Jun 2000 12:36:07 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <3959D56D.A388F73A@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 12:37:33 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 69fc0c8f347340f1a87808c7e2425529 Status: R X-Status: N Yann Guidon wrote:
>
> Nicolas Boulay wrote:
> >
> > I don't remember where i found this paper. But after a cross read, i
> > think that it could be a good way to make more than 1 instruction per
> > clock cycle efficiently and having a goog way to increase speed in the
> > futur with keeping the compatibility.
> >
>
> tu aurais au moins pu le comprimer ;-)
>

J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
pas oser.

> SMT is a good way to increase the CPU utilization.
> i've been thinking about it for some years, but the first problem
> is the huge register bank it requires, so it won't be useful for
> the first protos. It will be useful anyway the day we'll want to
> beat the Alpha 21464 :-)
>
> before we start adding instructions we should first analyze what's
> really needed. but there's no hurry even if i believe more
> in SMT than VLIW because it transforms a hazard into a "switch".
> OTOH i fear that it will make people believe that it's still OK
> to code badly.
>

It's always possible to create a 2 ways SMT or even a one ways ;-) and
used some special register to describe this feature. The most important
is to have the ISA adapted to this feature. In few years when it's
reasonnable to design a 8 ways SMT processor, if the ISA change, i don't
think users will like that. (compatibility is the only raison of the x86
succes).

So my opinion is to design an ISA which don't need to be change bevore
"some" years (never ?) but enought flexible (in the way well design) to
addapt new technologie at the minimum cost (!= x86 !). I think that this
is a chalenge. Not to have a SMT, VLIW processors with specific cache
(like L1 in the new p7?) but, in the futur, when it will be implemented,
the processor look like a processor design for this new technologie. So
it's possible to minimise the size of the new control area.

I kwnow that it will be hard to guess the futur but trying is permit ;-)
nicO
> WHYGEE
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01887 for ; Fri, 30 Jun 2000 19:27:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:42 +0200 (MEST) Received: (qmail 16803 invoked by uid 0); 28 Jun 2000 13:58:45 -0000 Received: from mu.egroups.com (207.138.41.151) by mx02.gmx.net with SMTP; 28 Jun 2000 13:58:45 -0000 X-eGroups-Return: sentto-1101623-371-962200716-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mu.egroups.com with NNFMP; 28 Jun 2000 14:58:51 -0000 Received: (qmail 32236 invoked from network); 28 Jun 2000 13:56:54 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 28 Jun 2000 13:56:54 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta1 with SMTP; 28 Jun 2000 13:56:54 -0000 Received: from 0018728164 (host-208-60-244-101.bix.bellsouth.net [208.60.244.101]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id JAA21629; Wed, 28 Jun 2000 09:56:49 -0400 (EDT) Message-ID: <001701bfe108$86b41500$65f43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Jun 2000 08:55:30 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Erin16/32/64 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01BFE0DE.9C8E5B80" X-UIDL: 710a92f1d1307f64cd8c631c1f2b9023 Status: R X-Status: N ------=_NextPart_000_0014_01BFE0DE.9C8E5B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First; I want to thank you all for your excellent comments. Over the past month I have designed each Arithmetic and Logic function = as Single entities. Was ready to implement and pondered a whille. Then = I took a look at the following Instruction Mix: Branch 16% (Unconditional/Conditional) Store 9% ALU 45% Load 26% Shift 4% This tells me how many of each function to consider - for example, how = many Adders for my target pipeline depth. I have the advantage of = looking at what was a working Software Package (TIPS). The results are: four (4) = adder/subtractors, two (2) Xor, two (2) And, two (2) Shift, and one (1) Increment. =20 Next I looked at the intended Addressing modes which are/were Direct, = Indexed, Indirect, Pre-Indexed, and Post Indexed. So I designed a circuit that = performs these functions prior to entering the Execute Phase. It = requires a lot of logic in this functional group and to prevent data stalls; requires four (4) of each. = And this is using an external 4-Port Ram having two Read Ports and one = Write Port, with the fourth being used for FBC Data transfers (no = interleaving of data transfers and Instructions as is required with a = DMA). Again I was ready to commence hooking all the pieces together. = This required a re-design of my external memory architecture. = Instruction Memory is two-port where one port is dedicated to Boot Load = process. Data Memory is all four-port Ram as described above. Next, I studied the Micro Instruction Format which is 108 Bits in width, = classical Writable Control Store with no Instruction Decode required. Combined = the Branch Logic such that a Branch Direct Instruction is the logical OR = of 16 discrete functions. More than one condition is selectable for = example: Branch Equal OR Bit "N" equal Xero. This feature can also be combined to execute one or = more instructions from the other types. I essentially had an Address = field that could only be used for Load or Store. More thought. If I had a both a Source and = Destination Address field, I could do both at the same time. Thatis, = execute two instructions at the same time. Then, looking into the = future as someone suggested; I am now implementing 1024 x 32 on chip RAM = in such a way that it is a CROSSBAR. I am currently implementing both = the Source and Destination Address fields for Memory Reference class of = Instructions and the Source and Destination fields for the on-chip Ram = (Register File). In my case the Ram is all general purpose and need not = be saved in whole or in part. I am currently retaining the single = Accumulator (A-Reg) which retains all of the RAM for other things. The main reason I am concerned about circuit delays now is so I can = design and expect an FPGA to work without too many iterations and have = the maximum possible performance - whatever that turns out to be. As = someone said - stick to the target Application - we do have common = problems and we can all benefit from sharing those problems. I will address Mr. David Cary's questions at a later time. He should be = interested in this e-mail however. Sincerely Richard E. Hartney Erin Greene & Associates Research Director ------=_NextPart_000_0014_01BFE0DE.9C8E5B80 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
First; I want to thank you all for your excellent comments.
 
Over the past month I have designed each Arithmetic and Logic function as Single entities.  Was ready to implement and pondered a whille.  Then I took a look at the following Instruction Mix:
            Branch    16% (Unconditional/Conditional)
            Store        9%
            ALU        45%
            Load       26%
            Shift         4%
This tells me how many of each function to consider - for example, how many Adders for my target pipeline depth.  I have the advantage of looking at what was a
working Software Package (TIPS).  The results are:  four (4)  adder/subtractors,
two (2) Xor, two (2) And, two (2) Shift, and one (1) Increment. 
 
Next I looked at the intended Addressing modes which are/were Direct, Indexed,
Indirect, Pre-Indexed, and Post Indexed.  So I designed a circuit that performs these functions prior to entering the Execute Phase. It requires a lot of logic in this
functional group and to prevent data stalls; requires four (4) of each.  And this is using an external 4-Port Ram having two Read Ports and one Write Port, with the fourth being used for FBC Data transfers (no interleaving of data transfers and Instructions as is required with a DMA).  Again I was ready to commence hooking all the pieces together.  This required a re-design of my external memory architecture.  Instruction Memory is two-port where one port is dedicated to Boot Load process.  Data Memory is all four-port Ram as described above.
 
Next, I studied the Micro Instruction Format which is 108 Bits in width, classical
Writable Control Store with no Instruction Decode required.  Combined the Branch Logic such that a Branch Direct Instruction is the logical OR of 16 discrete functions.  More than one condition is selectable for example: Branch Equal OR
Bit "N" equal Xero.  This feature can also be combined to execute one or more instructions from the other types.  I essentially had an Address field that could only
be used for Load or Store.  More thought.  If I had a both a Source and Destination Address field, I could do both at the same time.  Thatis, execute two instructions at the same time.  Then, looking into the future as someone suggested; I am now implementing 1024 x 32 on chip RAM in such a way that it is a CROSSBAR.  I am currently implementing both the Source and Destination Address fields for Memory Reference class of Instructions and the Source and Destination fields for the on-chip Ram (Register File).  In my case the Ram is all general purpose and need not be saved in whole or in part.  I am currently retaining the single Accumulator
(A-Reg)  which retains all of the RAM for other things.
 
The main reason I am concerned about circuit delays now is so I can design and expect an FPGA to work without too many iterations and have the maximum possible performance - whatever that turns out to be.  As someone said - stick to the target Application - we do have common problems and we can all benefit from sharing those problems.
 
I will address Mr. David Cary's questions at a later time.  He should be interested
in this e-mail however.
 
Sincerely
Richard E. Hartney
Erin Greene & Associates
Research Director
 
 
 
 
------=_NextPart_000_0014_01BFE0DE.9C8E5B80-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01911 for ; Fri, 30 Jun 2000 19:27:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:48 +0200 (MEST) Received: (qmail 24028 invoked by uid 0); 28 Jun 2000 22:14:39 -0000 Received: from hl.egroups.com (208.50.144.86) by mx02.gmx.net with SMTP; 28 Jun 2000 22:14:39 -0000 X-eGroups-Return: sentto-1101623-373-962230476-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 28 Jun 2000 22:14:37 -0000 Received: (qmail 15667 invoked from network); 28 Jun 2000 22:14:35 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 28 Jun 2000 22:14:35 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 28 Jun 2000 22:14:35 -0000 Received: from f-cpu.org (Aubervilliers-4-157.club-internet.fr [195.36.145.157]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03336 for ; Thu, 29 Jun 2000 00:14:32 +0200 (MET DST) Message-ID: <395A788E.7862927F@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 00:13:34 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c620370c50f6ab01f3314af903adaca7 Status: R X-Status: N Nicolas Boulay wrote:
> Yann Guidon wrote:
> > Nicolas Boulay wrote:
> > > I don't remember where i found this paper. But after a cross read, i
> > > think that it could be a good way to make more than 1 instruction per
> > > clock cycle efficiently and having a goog way to increase speed in the
> > > futur with keeping the compatibility.
> > tu aurais au moins pu le comprimer ;-)
> J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
> pas oser.
et GZIP, ou COMPRESS, c'est pour les chiens ? ;-)

> > SMT is a good way to increase the CPU utilization.
> > i've been thinking about it for some years, but the first problem
> > is the huge register bank it requires, so it won't be useful for
> > the first protos. It will be useful anyway the day we'll want to
> > beat the Alpha 21464 :-)
> >
> > before we start adding instructions we should first analyze what's
> > really needed. but there's no hurry even if i believe more
> > in SMT than VLIW because it transforms a hazard into a "switch".
> > OTOH i fear that it will make people believe that it's still OK
> > to code badly.
> >
>
> It's always possible to create a 2 ways SMT or even a one ways ;-) and
> used some special register to describe this feature. The most important
> is to have the ISA adapted to this feature.
i'm pretty convinced that the current ISA is ready for SMT.
if anyone has an idea or detects a flaw, tell me :-)

> In few years when it's
> reasonnable to design a 8 ways SMT processor, if the ISA change, i don't
> think users will like that. (compatibility is the only raison of the x86
> succes).
dat's su'e ;-) let's have something solid as the Gibraltar Rock :-)

> So my opinion is to design an ISA which don't need to be change bevore
> "some" years (never ?) but enought flexible (in the way well design) to
> addapt new technologie at the minimum cost (!= x86 !). I think that this
> is a chalenge.
but an interesting one ;-)

> Not to have a SMT, VLIW processors with specific cache
> (like L1 in the new p7?) but, in the futur, when it will be implemented,
> the processor look like a processor design for this new technologie. So
> it's possible to minimise the size of the new control area.
for the FC0 i try to keep it as clean as possible, as well as scalable to
crazy extents.

I'm reworking the load/store instructions and HW now, i'm adapting them for
an even simpler scheme, but it's more "far fetched".
be ready for a major f-cpu headache ;-) i'll discuss it soon.

> I kwnow that it will be hard to guess the futur but trying is permit ;-)
anticipating is even better ;-)
i failed to follow the technology, so i decided to lead it.
if you don't know, invent ;-)

i still have to read your PS anyway.

> nicO
> > WHYGEE
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01914 for ; Fri, 30 Jun 2000 19:27:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:49 +0200 (MEST) Received: (qmail 7247 invoked by uid 0); 28 Jun 2000 22:14:43 -0000 Received: from mv.egroups.com (208.50.144.81) by mx02.gmx.net with SMTP; 28 Jun 2000 22:14:43 -0000 X-eGroups-Return: sentto-1101623-372-962230472-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 28 Jun 2000 23:14:40 -0000 Received: (qmail 829 invoked from network); 28 Jun 2000 22:14:31 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Jun 2000 22:14:31 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 28 Jun 2000 22:14:31 -0000 Received: from f-cpu.org (Aubervilliers-4-157.club-internet.fr [195.36.145.157]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03296 for ; Thu, 29 Jun 2000 00:14:28 +0200 (MET DST) Message-ID: <395A788C.383246B9@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001701bfe108$86b41500$65f43cd0@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 00:13:32 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Erin16/32/64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f5258cf257668270ece2a25200d8a370 Status: R X-Status: N hi !

> "Richard E.Hartney" wrote:
>
> First; I want to thank you all for your excellent comments.
>
> Over the past month I have designed each Arithmetic and Logic
> function as Single entities.  Was ready to implement and pondered
> a whille.  Then I took a look at the following Instruction Mix:
>             Branch    16% (Unconditional/Conditional)
>             Store        9%
>             ALU        45%
>             Load       26%
>             Shift         4%
> This tells me how many of each function to consider - for example,
> how many Adders for my target pipeline depth.  I have the advantage
> of looking at what was a working Software Package (TIPS).  The results
> are:  four (4)  adder/subtractors, two (2) Xor, two (2) And, two (2)
> Shift, and one (1) Increment.

<snip>

> The main reason I am concerned about circuit delays now is so I can
> design and expect an FPGA to work without too many iterations and
> have the maximum possible performance - whatever that turns out to
> be.  As someone said - stick to the target Application - we do have
> common problems and we can all benefit from sharing those problems.
>
> I will address Mr. David Cary's questions at a later time.  He should be interested
> in this e-mail however.
>
> Sincerely
> Richard E. Hartney
> Erin Greene & Associates
> Research Director

this was a very interesting mail, as were the others too :-)
i hope you'll find your way soon (after all the work you've made,
it's normal).

as for the f-cpu perennity, i may have a deal with my current university.
i'll discuss it tomorrow with the department director.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01932 for ; Fri, 30 Jun 2000 19:27:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:53 +0200 (MEST) Received: (qmail 30960 invoked by uid 0); 29 Jun 2000 05:27:58 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 29 Jun 2000 05:27:58 -0000 X-eGroups-Return: sentto-1101623-374-962256343-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 29 Jun 2000 05:27:42 -0000 Received: (qmail 21027 invoked from network); 29 Jun 2000 05:25:42 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 29 Jun 2000 05:25:42 -0000 Received: from unknown (HELO bjsmtp1.163.net) (202.108.255.250) by mta1 with SMTP; 29 Jun 2000 05:25:07 -0000 Received: by bjsmtp1.163.net (Postfix, from userid 1005) id 529421D0CA2F3; Thu, 29 Jun 2000 13:30:30 +0800 (CST) Message-Id: <395ADEF5.27128@bjsmtp1.163.net> To: f-cpu@egroups.com X-Priority: 3 X-Originating-IP: [202.110.200.130] From: zwpkt@163.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 13:30:29 +0800 (CST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: d8b527011f3211ce9b6f1a56974e2a1e Status: R X-Status: N unsubscribe ------------------------www.163.net---------------------- Èç¹ûÄúÒѾ­»ñµÃÁËCNNICµÄÓÅÐãÍøվͶƱȨ£¬Çë±ð³ÙÒÉ£¬¸Ï¿ìΪ Äú×î³£·ÃÎʵÄÍøվͶÉÏһƱ¡£(www.163.net) ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html ------------------------------------------------------------------------ Want insight into hot IPOs, investing strategies and stocks to watch? Red Herring FREE newsletters provide strategic analysis for investors. http://click.egroups.com/1/5176/1/_/3462/_/962256343/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01941 for ; Fri, 30 Jun 2000 19:27:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:27:55 +0200 (MEST) Received: (qmail 6769 invoked by uid 0); 29 Jun 2000 07:19:19 -0000 Received: from mo.egroups.com (207.138.41.166) by mx02.gmx.net with SMTP; 29 Jun 2000 07:19:19 -0000 X-eGroups-Return: sentto-1101623-375-962263154-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mo.egroups.com with NNFMP; 29 Jun 2000 07:19:17 -0000 Received: (qmail 6350 invoked from network); 29 Jun 2000 07:19:09 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 29 Jun 2000 07:19:09 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 29 Jun 2000 07:19:09 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000629071909.UUZE18210.mail.rdc1.wa.home.com@nventure.com> for ; Thu, 29 Jun 2000 00:19:09 -0700 Message-ID: <395AF6A5.1A8580D7@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 00:11:39 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 020d8fcd15beeddef7c1a1af39a64913 Status: R X-Status: N All I've been suggesting lately was building a pure VLIW core with no
decode -- only execution resources -- so that whatever technology we
chose to use would allow us to fit the maximum number of cores on one
die, whatever material and whatever transistors we'd be using.

Scalability is done, then, not by widening the data paths with new
instructions, but by adding more cores, which would be almost all
hardware.

The reason I've been looking at ECL is because you can now get up into
the 2-5 million transistor range, easily enough to build VLIW processors
of decent width.  Most of the real estate on uP's these days is becoming
wire, anyway, and CMOS cannot take advantage of the benefits of sub .1
anyway.

This protracted "debate" is important because the underlying technology
and the methods used to optimize software really do affect architecture,
which must adapt to these concerns.

Those on the other side of this have asserted that we should simply wait
to see what comes out.  Others have made this mistake.  We already know
what will come out of this.  Tying too many transistors to one clock is
a mistake.

10**lots transistors is not always the best approach.  Studies, and now
experience, are showing that the simulators were wrong.  The drain on
the clock becomes too great.  Designs done at Stanford and elsewhere
with large CMOS devices have been disappointing, as well as the 21264
and Itanium, the latter of which is running about 20% slower than
originally planned, as well as being TWO YEARS behind schedule.  Given
the price-performance levels and competition in the x86 market, I would
say there's a good chance that IA-64 is already doomed, at this point.

The point is, more transistors are not always better.  That was my beef
with the crossbar.  Too much pipelining means more control hardware,
which can already use up 3/4 of all logic on these things, and that's
getting worse, not better.

If you want the really high throughput rates, do it with new
technology.  CMOS and 10**wow transistors is a dead end.

Albert "Maxx" Abramson
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01983 for ; Fri, 30 Jun 2000 19:28:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:04 +0200 (MEST) Received: (qmail 28634 invoked by uid 0); 29 Jun 2000 15:03:24 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 29 Jun 2000 15:03:24 -0000 X-eGroups-Return: sentto-1101623-376-962290977-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 29 Jun 2000 15:03:01 -0000 Received: (qmail 19038 invoked from network); 29 Jun 2000 15:02:56 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 Jun 2000 15:02:56 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (205.152.0.91) by mta1 with SMTP; 29 Jun 2000 15:02:56 -0000 Received: from 0018728164 (host-208-60-244-106.bix.bellsouth.net [208.60.244.106]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id LAA00581; Thu, 29 Jun 2000 11:02:50 -0400 (EDT) Message-ID: <000a01bfe1da$eb6750c0$6af43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 10:01:08 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Erin/16/32/64 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFE1B0.F21947E0" X-UIDL: 597d074abedede9317ad9f3a0d891c57 Status: R X-Status: N ------=_NextPart_000_0005_01BFE1B0.F21947E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maxx - I agree with you in all respects. The device technology must be = a consideration - but not till you have a proven design using whatever - = in my case this is a QL6500 - an FPGA. This device has nine (9) Global = Clock Networks that can be connected to an on-chip Phase Lock Net. = There are four of these with an 1x,2x,4x selectable output. the GCN's = are used such that selected Register groups all clock at the same time. = The GCN has a one (1) NS delay from input to output. Other mfg = technologys wouls naturally be different. A later consideration. And, I do have a VLIW - specifically, 108 Bits. Redesigned the format = last night and this morning. I will complete implementation of the 1024 = x 32 Register File (Crossbar) sometime today. Since this requires both an A and a B Source = Address as well as an A and B Destination Address; I thought a little = longer. So I have implemented both a Source and Destination Address for = Memory Operands. What does this do for me?? Remember, I doing an Emulation of the = DDP-516 ISA. The current Micro Instruction allows me to execute up to FIVE = Instructions with one Instruction Fetch. Further; a pin count says - I = can Fetch TWO Instructions at the same time; my Memory Architecture will allow this. What does this = tell me?? I could execute as many as TEN Instructions with ONE off-chip fetch. I = still don't use CACHE of any type. Since I have the Address reach required for my Application (20 Bits); I = have retained only two Address Modes. These are Direct and Post = Indexed. This is all that is required for Multi-User, Multi-Task = situations from a Software standpoint. Further; since I use two Processors; one for Language and one Peripheral = - same design - I don't have a feel for the amount of software required to = handle a Page Scanning Device, and I must provide for up to 128 Scanners. So, in = order to pass the buck - so to speak - This software, should it be too = large to fit in the current Program Memory; will be Stored in a totally separate Memory (Boot = Loadable at power on) and selected with the MOVE Instruction upon receipt of an = appropriate Interrupt. Time penalty equal Interrupt Break plus one MOVE - don't = have to overlay as is done in current PC's. The Processor has provision = for eight (8) Vectored Interrupts. The Language Processor uses three of = these. The highest priority is assigned to Terminal Inputs, next is = Inter-Processor Interrupt and last is end-of-block FBC Data Transfer. I = haven't had time to concentrate on the Peripheral side - however there = is an inter-processor interrupt and up to seven others that are device = dependent. At this point I will keep ERIN64 in the back of my mind and concentrate = on 32. I WILL eventually be ERIN64 whatever it takes. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01BFE1B0.F21947E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Maxx - I agree with you in all respects.  The device technology must be a consideration - but not till you have a proven design using whatever - in my case this is a QL6500 - an FPGA.  This device has nine (9) Global Clock Networks that can be connected to an on-chip Phase Lock Net.  There are four of these with an 1x,2x,4x selectable output.  the GCN's are used such that selected Register groups all clock at the same time.  The GCN has a one (1) NS delay from input to output.  Other mfg technologys wouls naturally be different.  A later consideration.
 
And, I do have a VLIW - specifically, 108 Bits.  Redesigned the format last night and this morning.  I will complete implementation of the 1024 x 32 Register File
(Crossbar) sometime today.  Since this requires both an A and a B Source Address as well as an A and B Destination Address; I thought a little longer.  So I have implemented both a Source and Destination Address for Memory Operands.
What does this do for me??  Remember, I doing an Emulation of the DDP-516 ISA.
The current Micro Instruction allows me to execute up to FIVE Instructions with one Instruction Fetch.  Further; a pin count says - I can Fetch TWO Instructions at
the same time; my Memory Architecture will allow this.  What does this tell me??
I could execute as many as TEN Instructions with ONE off-chip fetch.  I still don't use CACHE of any type.
 
Since I have the Address reach required for my Application (20 Bits); I have retained only two Address Modes.  These are Direct and Post Indexed.  This is all that is required for Multi-User, Multi-Task situations from a Software standpoint.
 
Further; since I use two Processors; one for Language and one Peripheral - same
design - I don't have a feel for the amount of software required to handle a Page
Scanning Device, and I must provide for up to 128 Scanners.  So, in order to pass the buck - so to speak - This software, should it be too large to fit in the current
Program Memory; will be Stored in a totally separate Memory (Boot Loadable at
power on) and selected with the MOVE Instruction upon receipt of an appropriate
Interrupt.  Time penalty equal Interrupt Break plus one MOVE - don't have to overlay as is done in current PC's.  The Processor has provision for eight (8) Vectored Interrupts.  The Language Processor uses three of these.  The highest priority is assigned to Terminal Inputs, next is Inter-Processor Interrupt and last is end-of-block FBC Data Transfer.  I haven't had time to concentrate on the Peripheral side - however there is an inter-processor interrupt and up to seven others that are device dependent.
 
At this point I will keep ERIN64 in the back of my mind and concentrate on 32.  I
WILL eventually be ERIN64 whatever it takes.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
 
 
------=_NextPart_000_0005_01BFE1B0.F21947E0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01989 for ; Fri, 30 Jun 2000 19:28:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:07 +0200 (MEST) Received: (qmail 25620 invoked by uid 0); 29 Jun 2000 15:38:05 -0000 Received: from mw.egroups.com (207.138.41.167) by mx0.gmx.net with SMTP; 29 Jun 2000 15:38:05 -0000 X-eGroups-Return: sentto-1101623-377-962293073-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 29 Jun 2000 15:38:02 -0000 Received: (qmail 6473 invoked from network); 29 Jun 2000 15:36:01 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 Jun 2000 15:36:01 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 29 Jun 2000 15:35:56 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5TFZoR15137 for ; Thu, 29 Jun 2000 17:35:55 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5TFZnP00067 for ; Thu, 29 Jun 2000 17:35:49 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id RAA25421 for ; Thu, 29 Jun 2000 17:35:49 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id RAA13669 for ; Thu, 29 Jun 2000 17:34:20 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <395B6CD4.F41781FF@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 17:35:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 87ef8e9ee4ee721bbc134d33fe86ec9e Status: R X-Status: N Albert Abramson wrote:
>
> All I've been suggesting lately was building a pure VLIW core with no
> decode -- only execution resources -- so that whatever technology we
> chose to use would allow us to fit the maximum number of cores on one
> die, whatever material and whatever transistors we'd be using.
>

That the idea of lot of people, but how maintain a binary compatibility
with futur core with pure VLIW (without recompiling)?

> Scalability is done, then, not by widening the data paths with new
> instructions, but by adding more cores, which would be almost all
> hardware.
>
> The reason I've been looking at ECL is because you can now get up into
> the 2-5 million transistor range, easily enough to build VLIW processors
> of decent width.  Most of the real estate on uP's these days is becoming
> wire, anyway, and CMOS cannot take advantage of the benefits of sub .1
> anyway.

I don't want to launch a flame ware. But this technologie desarper
little by little. Some AsGa guru thanks handy to give us work but some
compagny launch new product using Si.

The price of a 2 inch AsGa wafer is the price of a 30 cm Si wafer... And
it couldn't change : investments in Si research is much too big compar
to those in AsGa, or other...

The specificity of the Si is the SiO2 and its very clean interface,
which is the O in the MOS technologie. The Si is the only process which
could make MOS transistor. Why it is so important ? Because when a MOS
transistor don't change is state, the leak current is around zero. That
is not the case in other technologie like ECL. That's why, you need a
specific and very expensive cooling system.

The other advantage of MOS transistor is that it is very simple compare
to bipolar. So it's easy to make it small and it's build with less masks
during a process so it's cheaper.

And todays, your close futur speak about 1 or 2 millions transistor but
scientistique speak about billions... To make SOC (system on chip).
Nowdays the only probleme for performance is the memory bandwith. In
SOC, you could have a path of 256 or 1024 bits without any pb (in the
playstation II, the graphic chip have a bus of more than 10000 bits !).
Todays memory bandwith are around 1 Gb/s, with SOC you run about 15 Gb/s
(technologie today availlable by Infineon).

>
> This protracted "debate" is important because the underlying technology
> and the methods used to optimize software really do affect architecture,
> which must adapt to these concerns.
>

I'm not against making a small core. Because the futur is arrays of
core. Some scientiste speak about sparcs but why not fcpu ? We can put 8
or 16 cpus in a chip or even more.(2 millions of transistor it's only
the equivalent of 256KBytes memory, which is very few !)

> Those on the other side of this have asserted that we should simply wait
> to see what comes out.  Others have made this mistake.  We already know
> what will come out of this.  Tying too many transistors to one clock is
> a mistake.
>
> 10**lots transistors is not always the best approach.  Studies, and now
> experience, are showing that the simulators were wrong.  The drain on
> the clock becomes too great.  Designs done at Stanford and elsewhere
> with large CMOS devices have been disappointing, as well as the 21264
> and Itanium, the latter of which is running about 20% slower than
> originally planned, as well as being TWO YEARS behind schedule.  Given
> the price-performance levels and competition in the x86 market, I would
> say there's a good chance that IA-64 is already doomed, at this point.
>

I don't understand what you are saying exactly. there are a lot of
research about how cut the clock or even the power of some blocks to
reduice the overall power dissipation. (more than 50% of the power is
lost in the clock tree, and the 90% of the rest is lost by the
transistors driving the pins )

> The point is, more transistors are not always better.  That was my beef
> with the crossbar.  Too much pipelining means more control hardware,
> which can already use up 3/4 of all logic on these things, and that's
> getting worse, not better.
>
> If you want the really high throughput rates, do it with new
> technology.  CMOS and 10**wow transistors is a dead end.
>

When i saw how much money is spend in research in the Si (cf SOI, Cu,
low capacitance layer, SiGe, ...), i couldn't understand you.

> Albert "Maxx" Abramson
>
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02121 for ; Fri, 30 Jun 2000 19:28:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:35 +0200 (MEST) Received: (qmail 29414 invoked by uid 0); 29 Jun 2000 23:04:26 -0000 Received: from fg.egroups.com (208.50.144.70) by mx02.gmx.net with SMTP; 29 Jun 2000 23:04:26 -0000 X-eGroups-Return: sentto-1101623-378-962319850-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 29 Jun 2000 23:04:17 -0000 Received: (qmail 2530 invoked from network); 29 Jun 2000 22:47:56 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 29 Jun 2000 22:47:56 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 29 Jun 2000 22:47:56 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000629224750.OYVV18210.mail.rdc1.wa.home.com@nventure.com> for ; Thu, 29 Jun 2000 15:47:51 -0700 Message-ID: <395BD04F.76B62CCA@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 15:40:17 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc631b3746bad39151e4732f27bf1bb5 Status: R X-Status: N

Nicolas Boulay wrote:

> Albert Abramson wrote:
> >
> > All I've been suggesting lately was building a pure VLIW core with no
> > decode -- only execution resources -- so that whatever technology we
> > chose to use would allow us to fit the maximum number of cores on one
> > die, whatever material and whatever transistors we'd be using.
> >
>
> That the idea of lot of people, but how maintain a binary compatibility
> with futur core with pure VLIW (without recompiling)?
>

The future core would be the same core, without any redesign.  Widening a
core negatively impacts its clock rate.  With much of today's work, you can
spin off many threads to run on other cores in parallel.  The decode overhead
on VLIW is very small, and you get a significant one time boost in overall
performance with VLIW that can't be ignored.

>
> > Scalability is done, then, not by widening the data paths with new
> > instructions, but by adding more cores, which would be almost all
> > hardware.
> >
> > The reason I've been looking at ECL is because you can now get up into
> > the 2-5 million transistor range, easily enough to build VLIW processors
> > of decent width.  Most of the real estate on uP's these days is becoming
> > wire, anyway, and CMOS cannot take advantage of the benefits of sub .1
> > anyway.
>
> I don't want to launch a flame ware. But this technologie desarper
> little by little. Some AsGa guru thanks handy to give us work but some
> compagny launch new product using Si.
>
> The price of a 2 inch AsGa wafer is the price of a 30 cm Si wafer... And
> it couldn't change : investments in Si research is much too big compar
> to those in AsGa, or other...
>

GaAs has shown a great deal of promise precisely because so much work has
been done with it.  First with SDI, then academia, then Cray Supercomputing,
now Tera.  It has shown terrific results for supercomputing, just not low
cost devices yet.

Anyway, I was suggesting bipolar on Silicon, not GaAs.

>
> The specificity of the Si is the SiO2 and its very clean interface,
> which is the O in the MOS technologie. The Si is the only process which
> could make MOS transistor. Why it is so important ? Because when a MOS
> transistor don't change is state, the leak current is around zero. That
> is not the case in other technologie like ECL. That's why, you need a
> specific and very expensive cooling system.
>
> The other advantage of MOS transistor is that it is very simple compare
> to bipolar. So it's easy to make it small and it's build with less masks
> during a process so it's cheaper.
>

Bipolar is getting much cooler as we go down in feature size, and getting
much denser and faster.  It is impossible to explain to some, but bipolar now
offers the possibility of LOWER power consumption per clock signal per
device.

The density improvements are appearing because so much of processor real
estate these days is just wire, not logic.

>
> And todays, your close futur speak about 1 or 2 millions transistor but
> scientistique speak about billions... To make SOC (system on chip).
> Nowdays the only probleme for performance is the memory bandwith. In
> SOC, you could have a path of 256 or 1024 bits without any pb (in the
> playstation II, the graphic chip have a bus of more than 10000 bits !).
> Todays memory bandwith are around 1 Gb/s, with SOC you run about 15 Gb/s
> (technologie today availlable by Infineon).

1024 bit wide data paths are not a problem with these other technologies.
Remember that they are still using gold or copper wires, not GaAs or SiGe for
the interconnects, so this isn't the bottleneck.  In fact, bandwidth improves
considerably.  Such a path on a SiGe chip may move as much as 2048 GB/s from
L1, twice as much with Harvard cache architecture.

>
> >
> > This protracted "debate" is important because the underlying technology
> > and the methods used to optimize software really do affect architecture,
> > which must adapt to these concerns.
> >
>
> I'm not against making a small core. Because the futur is arrays of
> core. Some scientiste speak about sparcs but why not fcpu ? We can put 8
> or 16 cpus in a chip or even more.(2 millions of transistor it's only
> the equivalent of 256KBytes memory, which is very few !)
>

Caching techology is coming to favor bandwidth, not latency or even high hit
rates.  Remember the lessons of Tera's multithreaded machine.

>
> > Those on the other side of this have asserted that we should simply wait
> > to see what comes out.  Others have made this mistake.  We already know
> > what will come out of this.  Tying too many transistors to one clock is
> > a mistake.
> >
> > 10**lots transistors is not always the best approach.  Studies, and now
> > experience, are showing that the simulators were wrong.  The drain on
> > the clock becomes too great.  Designs done at Stanford and elsewhere
> > with large CMOS devices have been disappointing, as well as the 21264
> > and Itanium, the latter of which is running about 20% slower than
> > originally planned, as well as being TWO YEARS behind schedule.  Given
> > the price-performance levels and competition in the x86 market, I would
> > say there's a good chance that IA-64 is already doomed, at this point.
> >
>
> I don't understand what you are saying exactly. there are a lot of
> research about how cut the clock or even the power of some blocks to
> reduice the overall power dissipation. (more than 50% of the power is
> lost in the clock tree, and the 90% of the rest is lost by the
> transistors driving the pins )
>

Suffice to say the biggest logic cores out there are running much slower than
expected.  Simulations predicting 1GHz clocks are coming back with 100-500MHz
devices.  It is easy to see the impact on CPI with simulations.  It is much
more difficult to guess the negative impact on the clock rate that many of
these frills and features will create.

>
> > The point is, more transistors are not always better.  That was my beef
> > with the crossbar.  Too much pipelining means more control hardware,
> > which can already use up 3/4 of all logic on these things, and that's
> > getting worse, not better.
> >
> > If you want the really high throughput rates, do it with new
> > technology.  CMOS and 10**wow transistors is a dead end.
> >
>
> When i saw how much money is spend in research in the Si (cf SOI, Cu,
> low capacitance layer, SiGe, ...), i couldn't understand you.
>

SiGe is one of the promising technologies I've been writing about.  Yields
tend to be better than GaAs, and it makes use of already large investmets
with Si.

>
> > Albert "Maxx" Abramson
> >
> nicO
>
> ------------------------------------------------------------------------
> IT Professionals: Match your unique skills with the best IT projects at
> http://click.egroups.com/1/3381/1/_/3462/_/962293073/
> ------------------------------------------------------------------------
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02148 for ; Fri, 30 Jun 2000 19:28:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:42 +0200 (MEST) Received: (qmail 13152 invoked by uid 0); 30 Jun 2000 05:59:46 -0000 Received: from ck.egroups.com (208.50.144.69) by mx02.gmx.net with SMTP; 30 Jun 2000 05:59:46 -0000 X-eGroups-Return: sentto-1101623-379-962344783-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 30 Jun 2000 05:59:44 -0000 Received: (qmail 2186 invoked from network); 30 Jun 2000 05:59:43 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 30 Jun 2000 05:59:43 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 30 Jun 2000 05:59:43 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000630055942.INLY6302.mail.rdc1.wa.home.com@nventure.com> for ; Thu, 29 Jun 2000 22:59:42 -0700 Message-ID: <395C3588.9029A35D@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Jun 2000 22:52:12 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] SHP uP's [was Adders/Subtractors] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e56740c418ca32f752a3e65b44ce6ad Status: R X-Status: N It is unlikely that serious improvements will be seen in excess of what
has been seen with commercial CMOS devices.  To be honest, I think that
the needed factor of two in price performance over Intel's chips will
not be obtained doing RISC with CMOS.  ALPHA has already gone as far as
possible along this path.

We know that VLIW and bipolar hold out the possibility of reaching .5 ns
latency on integer operations.  We know that we can reach fp latencies
of 1-1.5 ns.  Who can say that?  Realisitically, fcpu's technology path
puts us around 700-750 MHz, which isn't very good considering the poor
CPI that will result on an in-order advance pipelined processor with 3-5
cycle (5-8ns) latency on data dependencies.  A VLIW core would be
smaller, faster, and more flexible.  If we need to expand the
microarchitecture, we ought to provide a programming model that permits
the description of a virtual machine with a hazy kind of reg-mem-message
passing model that is simulated by either some advanced hardware or some
dynamic optimization software.

In this way, we can go from an open standard architecture that any
processor can read and turn it into optimized, native code.  Doing so,
however, means asking a whole different set of questions.  How then, do
we handle loops that cycle a couple of hundred thousand times?  How do
we include hints in the opcode?  How do we build hardware to efficiently
handle all of this?  How do we manage the movement of large numbers of
registers to memory?  Can we allow the mapping of all registers to
memory?  Could these other "registers" then be read by other running
cores to enable superior fine-grain multi-threading?

Super high performance processors in the future will depend on getting
around some of the limitations that we are just recognizing today.

Architectural features don't need to be proven, not in my mind.
Everything can be accomplished using proven techniques.

BTW, with the shear number of companies investing in Silicon Germanium,
as well as its success in attaining high clock rates and reasonable
yields, I would venture a guess that this material is the what will make
up microprocessors of the future.  Even the early advocates of CMOS are
recognizing its impending death.  The characteristics of bipolar are
just much better as feature size is reduced.

--Maxx

Your elected officials will never take you seriously until they see that
you are willing to put your vote behind someone who will address these
issues more honestly.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02157 for ; Fri, 30 Jun 2000 19:28:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:44 +0200 (MEST) Received: (qmail 11152 invoked by uid 0); 30 Jun 2000 08:42:45 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 30 Jun 2000 08:42:45 -0000 X-eGroups-Return: sentto-1101623-380-962354324-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 30 Jun 2000 08:38:46 -0000 Received: (qmail 15461 invoked from network); 30 Jun 2000 08:38:44 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 30 Jun 2000 08:38:44 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 30 Jun 2000 08:38:44 -0000 Received: from 0018728164 (host-209-215-11-192.bix.bellsouth.net [209.215.11.192]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id EAA24763; Fri, 30 Jun 2000 04:38:41 -0400 (EDT) Message-ID: <001301bfe26e$6cba6ca0$c00bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 03:37:26 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Erin16/32/64 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BFE244.8249EE80" X-UIDL: 76cc4c29073fd7fdfc8e0407939fa484 Status: R X-Status: N ------=_NextPart_000_0010_01BFE244.8249EE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Completed the 1024 x 32 Register File (Crossbar) design. I then went = into Windows Explorer and deleted the entire mess of shit. The = so-called Crossbar is really nothing more than a Four-Port Memory. I can't afford to use the = amount of logic required for support using an FPGA. Back to my Original = M2M. Right again Maxx. I am supported off-chip with Four Port Ram for Operand = Load/Store. I am however retaining the Source/Destination Address field as part of the = Micro Instruction. Single Address vs Two Address trade-off. Will continue with Fetching two Instructions and see where it takes me. = Will keep you posted. On the surface it appears that I have to "look = back" instead of "look ahead". Sincerely Richard E. Hartney Erin Greene & Associates Research Director ------=_NextPart_000_0010_01BFE244.8249EE80 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Completed the 1024 x 32 Register File (Crossbar) design.  I then went into Windows Explorer and deleted the entire mess of shit.  The so-called Crossbar is
really nothing more than a Four-Port Memory.  I can't afford to use the amount of logic required for support using an FPGA.  Back to my Original M2M.  Right again
Maxx.  I am supported off-chip with Four Port Ram for Operand Load/Store.  I am
however retaining the Source/Destination Address field as part of the Micro
Instruction.  Single Address vs Two Address trade-off.
 
Will continue with Fetching two Instructions and see where it takes me.  Will keep you posted.  On the surface it appears that I have to "look back" instead of "look
ahead".
 
Sincerely
Richard E. Hartney
Erin Greene & Associates
Research Director
------=_NextPart_000_0010_01BFE244.8249EE80-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02163 for ; Fri, 30 Jun 2000 19:28:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:45 +0200 (MEST) Received: (qmail 1945 invoked by uid 0); 30 Jun 2000 08:49:19 -0000 Received: from b05.egroups.com (207.138.41.189) by mx02.gmx.net with SMTP; 30 Jun 2000 08:49:19 -0000 X-eGroups-Return: sentto-1101623-381-962354947-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 30 Jun 2000 08:49:09 -0000 Received: (qmail 29467 invoked from network); 30 Jun 2000 08:49:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 08:49:07 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 30 Jun 2000 08:49:07 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5U8n2R13373 for ; Fri, 30 Jun 2000 10:49:02 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5U8n2005446 for ; Fri, 30 Jun 2000 10:49:02 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id KAA21695 for ; Fri, 30 Jun 2000 10:49:02 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id KAA13552 for ; Fri, 30 Jun 2000 10:47:33 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <395C5EFC.29A74153@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 10:49:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a799fd816b1c060fb7b7e74a2d7b700d Status: R X-Status: N Albert Abramson wrote:
>
> Nicolas Boulay wrote:
>
<snip>
> >
> > The specificity of the Si is the SiO2 and its very clean interface,
> > which is the O in the MOS technologie. The Si is the only process which
> > could make MOS transistor. Why it is so important ? Because when a MOS
> > transistor don't change is state, the leak current is around zero. That
> > is not the case in other technologie like ECL. That's why, you need a
> > specific and very expensive cooling system.
> >
> > The other advantage of MOS transistor is that it is very simple compare
> > to bipolar. So it's easy to make it small and it's build with less masks
> > during a process so it's cheaper.
> >
>
> Bipolar is getting much cooler as we go down in feature size, and getting
> much denser and faster.  It is impossible to explain to some, but bipolar now
> offers the possibility of LOWER power consumption per clock signal per
> device.

I would know how it could be possible ! Bipolar transistor need to be
polarised, to that little currant sources are used. So even in static,
the bipolar technology have a worse power consumption than MOS.

>
> The density improvements are appearing because so much of processor real
> estate these days is just wire, not logic.
>

Few years ago, they are only 2 metal layers, so base cells are made with
metal 1 and polysilicon but to connect wire, you need some area between
blocs. Todays, the Pentuim II used a 7 metal layers process, tochiba for
the emotion engine of the playstation is in a 5 metal layers process.
Almost each um square are used to draw transistor and the wire run over.
When a new technologie came, for exemple, to .25 to .18, you reduice the
averall core size of ~30%(.25^2/.18^2=2 almost 50 % but it's depend on
the size of the wire, too.). Per mm square, the chip is more expensive
but, the same chip are cheaper.

> >
> > And todays, your close futur speak about 1 or 2 millions transistor but
> > scientistique speak about billions... To make SOC (system on chip).
> > Nowdays the only probleme for performance is the memory bandwith. In
> > SOC, you could have a path of 256 or 1024 bits without any pb (in the
> > playstation II, the graphic chip have a bus of more than 10000 bits !).
> > Todays memory bandwith are around 1 Gb/s, with SOC you run about 15 Gb/s
> > (technologie today availlable by Infineon).
>
> 1024 bit wide data paths are not a problem with these other technologies.
> Remember that they are still using gold or copper wires, not GaAs or SiGe for
> the interconnects, so this isn't the bottleneck.  In fact, bandwidth improves
> considerably.  Such a path on a SiGe chip may move as much as 2048 GB/s from
> L1, twice as much with Harvard cache architecture.
>

I know that 1024 bit wasn't a problem for other technologie but the
probleme are where do you put the 4 MBytes of the L2 cache ? If you use
embedded DRAM to improve thoughput, you need more than 2 mT per chip !
If your memory is outside the cheap you will always limited by the 400
Mhz and 128 bits wide bus (like graphic chip).

> >
> > >
> > > This protracted "debate" is important because the underlying technology
> > > and the methods used to optimize software really do affect architecture,
> > > which must adapt to these concerns.
> > >
> >
> > I'm not against making a small core. Because the futur is arrays of
> > core. Some scientiste speak about sparcs but why not fcpu ? We can put 8
> > or 16 cpus in a chip or even more.(2 millions of transistor it's only
> > the equivalent of 256KBytes memory, which is very few !)
> >
>
> Caching techology is coming to favor bandwidth, not latency or even high hit
> rates.  Remember the lessons of Tera's multithreaded machine.
>

When the cores are in the same die, you can reduice latency and increase
bandwidth.

> >
> > > Those on the other side of this have asserted that we should simply wait
> > > to see what comes out.  Others have made this mistake.  We already know
> > > what will come out of this.  Tying too many transistors to one clock is
> > > a mistake.
> > >
> > > 10**lots transistors is not always the best approach.  Studies, and now
> > > experience, are showing that the simulators were wrong.  The drain on
> > > the clock becomes too great.  Designs done at Stanford and elsewhere
> > > with large CMOS devices have been disappointing, as well as the 21264
> > > and Itanium, the latter of which is running about 20% slower than
> > > originally planned, as well as being TWO YEARS behind schedule.  Given
> > > the price-performance levels and competition in the x86 market, I would
> > > say there's a good chance that IA-64 is already doomed, at this point.
> > >
> >
> > I don't understand what you are saying exactly. there are a lot of
> > research about how cut the clock or even the power of some blocks to
> > reduice the overall power dissipation. (more than 50% of the power is
> > lost in the clock tree, and the 90% of the rest is lost by the
> > transistors driving the pins )
> >
>
> Suffice to say the biggest logic cores out there are running much slower than
> expected.  Simulations predicting 1GHz clocks are coming back with 100-500MHz
> devices.  It is easy to see the impact on CPI with simulations.  It is much
> more difficult to guess the negative impact on the clock rate that many of
> these frills and features will create.
>
> >
> > > The point is, more transistors are not always better.  That was my beef
> > > with the crossbar.  Too much pipelining means more control hardware,
> > > which can already use up 3/4 of all logic on these things, and that's
> > > getting worse, not better.
> > >
> > > If you want the really high throughput rates, do it with new
> > > technology.  CMOS and 10**wow transistors is a dead end.
> > >
> >
> > When i saw how much money is spend in research in the Si (cf SOI, Cu,
> > low capacitance layer, SiGe, ...), i couldn't understand you.
> >
>
> SiGe is one of the promising technologies I've been writing about.  Yields
> tend to be better than GaAs, and it makes use of already large investmets
> with Si.
>

The Ge in the SIGe is a new way to increase the number of charge in the
die without dopping. Because dopping create too much dispersing in the
perfomance (depending where is the atom under a transistor) when the
size is reduiced. So it's alwas a Si technologie, made to continue with
Si and make MOS transistors. An IBM process exist and are used to create
some RF chip.

Bipolar will be always a much complex (so bigger and more expensive
without speaking about the price of a um square die) technologie because
we need more masks to draw bipolar transistor than MOS transistor.

> >
> > > Albert "Maxx" Abramson
> > >
> > nicO
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02202 for ; Fri, 30 Jun 2000 19:28:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:55 +0200 (MEST) Received: (qmail 14769 invoked by uid 0); 30 Jun 2000 12:43:53 -0000 Received: from f19.egroups.com (207.138.41.182) by mx12.rz2.gmx.net with SMTP; 30 Jun 2000 12:43:53 -0000 X-eGroups-Return: sentto-1101623-382-962369023-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 30 Jun 2000 12:43:44 -0000 Received: (qmail 32372 invoked from network); 30 Jun 2000 12:43:43 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 30 Jun 2000 12:43:43 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 30 Jun 2000 12:43:42 -0000 Received: from f-cpu.org (Aubervilliers-4-178.club-internet.fr [195.36.145.178]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA09815 for ; Fri, 30 Jun 2000 14:43:38 +0200 (MET DST) Message-ID: <395C95C9.19B9848D@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> <395C3588.9029A35D@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 14:42:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SHP uP's [was Adders/Subtractors] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: de3e4c08c5bdca0f771351403d54bf67 Status: R X-Status: N Albert Abramson wrote:
<snip>

as for the technology : whether it's ECL or SiO2, i don't care.
it's the implementor's right to chose what technology he'll use,
according to its goals and budget (mass market with low margin,
high-end market with expensive technology etc...). this is one
side of the freedom that the project is meant to allow.
so let's concentrate on microarchitecture now.

what qualities should the F-CPU microarchitecture have ?
we know that it must be very efficient, that's sure.
OTOH we know that we have a handicap : we're not a
big company with thousands of very skilled engineers
(organisation is another problem). we know we can't
beat big companies from a purely technical ground.
so let's make the coolest CPU ever.

RISC vs VLIW ? an interesting debate. 3 years ago,
nobody knew what it is. But the IA64 is not the first (pseudo-)VLIW
ever, and VLIW is as old as the RISC concept.
I estimate that RISC has a faster acceptation way than VLIW.
mostly because of the compilers, the way VLIW fist the applications,
the marginal efforts and the more complex management.

OTOH RISC vs VLIW are on the same level when it comes to
"scalability" : extending RISC makes the core more complex while
VLIW needs recompilation. trying to have both RISC and VLIW
leads to HP/Intel's shit. i believe in SMT though.
But VLIW/RISC have the same electronical problems when it comes
to clock trees : it depends on the die surface, not the complexity
of the core(s). So if you put several cores on one die, you'll
have as much pain with the clock as with one big complex core.


> We know that VLIW and bipolar hold out the possibility of reaching .5 ns
> latency on integer operations.  We know that we can reach fp latencies
> of 1-1.5 ns.  Who can say that?
i answer : who has said that ?
"absolute latency" is not the problem : we know it will decrease
and decrease in the future. supraconducting technologies reach 500GHz today.
so i don't care at all, at all. what matters is boole's laws and
the speed of the light because they aren't going to change soon...

>  Realisitically, fcpu's technology path
> puts us around 700-750 MHz, which isn't very good considering the poor
> CPI that will result on an in-order advance pipelined processor with 3-5
> cycle (5-8ns) latency on data dependencies.
that's a rather "advanced" prediction. as written before, technologies
will evolve and the best we can do is stay a few years BEHIND the best available
technologies because we don't have a big fundry to back us.
"absolute performance is not our problem" because others will have the
technological advantage. What we can do to reduce the price is to
"use" technology at its best : what's the use of having 7 metal layers and 0.1u
wires if your EDA suite is bad, if your microarch sucks etc...

that's why i don't bother giving operating frequencies : this means nothing
at all.

>  A VLIW core would be smaller, faster, and more flexible.
i demand to be convinced, why don't you prove it with a practical example ?

>  If we need to expand the
> microarchitecture, we ought to provide a programming model that permits
> the description of a virtual machine with a hazy kind of reg-mem-message
> passing model that is simulated by either some advanced hardware or some
> dynamic optimization software.
that's getting pretty complex for a "simple device"...

don't you forget a major paramater ? how (easily) will you program it in
a high-level langage ?

> In this way, we can go from an open standard architecture that any
> processor can read and turn it into optimized, native code.
you mean that you reinterpret the code in the core or with some software
(either like the Willamette or Transmeta) ? Isn't it pretty complex for
a difficuly access to the raw CPU power ?

>  Doing so,
> however, means asking a whole different set of questions.  How then, do
> we handle loops that cycle a couple of hundred thousand times?
that's a programing question ? just loop, then.

in FC0 the problem is solved easily.

>  How do we include hints in the opcode?
"include hints in the opcode" is the answer.

>  How do we build hardware to efficiently handle all of this?
that's not my cup of tea...

>  How do we manage the movement of large numbers of registers to memory?
"with the necessary instructions".

>  Can we allow the mapping of all registers to memory?
that's something i don't encourage "as is".

>  Could these other "registers" then be read by other running
> cores to enable superior fine-grain multi-threading?
yuk. argh. you're a kamikaze.

> Super high performance processors in the future will depend on getting
> around some of the limitations that we are just recognizing today.
is SMT some part of the answer ? i guess, in part.


if you want to make a VLIW FC1, go ahead and program/draw some
prototypes. i don't like to discuss like that, without tangible
facts (other than articles in the press).

have fun,


> --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02211 for ; Fri, 30 Jun 2000 19:28:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:58 +0200 (MEST) Received: (qmail 2587 invoked by uid 0); 30 Jun 2000 13:10:33 -0000 Received: from hl.egroups.com (208.50.144.86) by mx02.gmx.net with SMTP; 30 Jun 2000 13:10:33 -0000 X-eGroups-Return: sentto-1101623-383-962370441-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 30 Jun 2000 13:07:26 -0000 Received: (qmail 8212 invoked from network); 30 Jun 2000 13:07:21 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 13:07:21 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 30 Jun 2000 13:07:20 -0000 Received: from f-cpu.org (Paris-Raspail-2-245.club-internet.fr [195.36.192.245]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA03084 for ; Fri, 30 Jun 2000 15:07:16 +0200 (MET DST) Message-ID: <395C9B45.B94CA87A@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:06:13 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: efe0949b9d2a9e94ed9976753b7d0970 Status: R X-Status: N hi again,

just to note something i forgotten :

Nicolas Boulay wrote:
>
> Albert Abramson wrote:
> >
> > All I've been suggesting lately was building a pure VLIW core with no
> > decode -- only execution resources -- so that whatever technology we
> > chose to use would allow us to fit the maximum number of cores on one
> > die, whatever material and whatever transistors we'd be using.
> That the idea of lot of people, but how maintain a binary compatibility
> with futur core with pure VLIW (without recompiling)?
that's a major question. nobody wants to reinterpret opcodes either in HW or SW.

> > The reason I've been looking at ECL is because you can now get up into
> > the 2-5 million transistor range, easily enough to build VLIW processors
> > of decent width.  Most of the real estate on uP's these days is becoming
> > wire, anyway, and CMOS cannot take advantage of the benefits of sub .1
> > anyway.

there i stop you and let you remember a little single FACT :
where it takes 1 CMOS or bipolar transitor, it takes 6 ECL transistors
to make a gate. i guess that on average the surface needed for ECL is
4x the surface needed otherwise. so if you can have 5MT in ECL, you end up
having one million gates only. not terrific...

i just wanted to make this detail clear, re-read you digital electronics books
and your P&H bible(s). I see ECL today in transmission lines, not in the digital
computation logic gates : it's used for communication on the CPU bus at 100Mhz++
for example. and it draws a LOT of power. no wonder CMOS is alive and well.

but as noted before, that's not my problem. Si will be suplanted by
supraconductors in 20 or 30 years. by or before 2010, the US gov. will have
its PETAFLOPS computer ready, made of a few thousands of terahertz CPUs.
there, the challenges you're raising will be funny problems compared to
what i expect... imagine a computer that requires almost one million
CPU cycles to access the main memory, in a fridge that keeps the temperature
at around 3 degrees Kelvin, and that can contain several cubic meters
of liquid nitrogen...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02214 for ; Fri, 30 Jun 2000 19:28:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:28:59 +0200 (MEST) Received: (qmail 19226 invoked by uid 0); 30 Jun 2000 13:30:56 -0000 Received: from cj.egroups.com (208.50.144.68) by mx02.gmx.net with SMTP; 30 Jun 2000 13:30:56 -0000 X-eGroups-Return: sentto-1101623-384-962371683-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by cj.egroups.com with NNFMP; 30 Jun 2000 13:28:05 -0000 Received: (qmail 6692 invoked from network); 30 Jun 2000 13:28:03 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 30 Jun 2000 13:28:03 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta1 with SMTP; 30 Jun 2000 13:28:02 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5UDS0B28571 for ; Fri, 30 Jun 2000 15:28:00 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5UDS0n20458 for ; Fri, 30 Jun 2000 15:28:00 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id PAA05818 for ; Fri, 30 Jun 2000 15:27:59 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id PAA26670 for ; Fri, 30 Jun 2000 15:26:30 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <395CA05E.B06001CC@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:27:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 147752041e8dcdfcb2708d324c4d75a4 Status: R X-Status: N Yann Guidon wrote:
>
> Nicolas Boulay wrote:
> > Yann Guidon wrote:
> > > Nicolas Boulay wrote:
> > > > I don't remember where i found this paper. But after a cross read, i
> > > > think that it could be a good way to make more than 1 instruction per
> > > > clock cycle efficiently and having a goog way to increase speed in the
> > > > futur with keeping the compatibility.
> > > tu aurais au moins pu le comprimer ;-)
> > J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
> > pas oser.
> et GZIP, ou COMPRESS, c'est pour les chiens ? ;-)
>

Justement winzip est incompatible avec gzip

> > > SMT is a good way to increase the CPU utilization.
> > > i've been thinking about it for some years, but the first problem
> > > is the huge register bank it requires, so it won't be useful for
> > > the first protos. It will be useful anyway the day we'll want to
> > > beat the Alpha 21464 :-)
> > >
> > > before we start adding instructions we should first analyze what's
> > > really needed. but there's no hurry even if i believe more
> > > in SMT than VLIW because it transforms a hazard into a "switch".
> > > OTOH i fear that it will make people believe that it's still OK
> > > to code badly.
> > >
> >
> > It's always possible to create a 2 ways SMT or even a one ways ;-) and
> > used some special register to describe this feature. The most important
> > is to have the ISA adapted to this feature.
> i'm pretty convinced that the current ISA is ready for SMT.
> if anyone has an idea or detects a flaw, tell me :-)
>
Ready : what does it mean ? I supposed that for SMT you need some more
PC, and to make it flexible "some" should not be fixed. And we need to
prouve that a compilation for a 2 ways SMT work for a 8 ways. This
permit very (very) deep pipeling without many probleme with
dependancies.
But you need more registers, it isn't really a probleme a flip-flop is
composed by around 40 transistors so it's <164000 transistors for
register banks of 64 registers of 64b. That's not a so big deal.

<snip>
>
> > nicO
> > > WHYGEE
> WHYGEE
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02220 for ; Fri, 30 Jun 2000 19:29:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:00 +0200 (MEST) Received: (qmail 18685 invoked by uid 0); 30 Jun 2000 13:36:09 -0000 Received: from mo.egroups.com (208.50.144.78) by mx02.gmx.net with SMTP; 30 Jun 2000 13:36:09 -0000 X-eGroups-Return: sentto-1101623-385-962372094-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mo.egroups.com with NNFMP; 30 Jun 2000 13:35:55 -0000 Received: (qmail 24877 invoked from network); 30 Jun 2000 13:34:11 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 30 Jun 2000 13:34:11 -0000 Received: from unknown (HELO sxpert.dyndns.org) (212.43.199.14) by mta1 with SMTP; 30 Jun 2000 13:34:11 -0000 Received: (from sxpert@localhost) by sxpert.dyndns.org (8.9.3/8.8.7) id PAA30249 for f-cpu@egroups.com; Fri, 30 Jun 2000 15:00:02 +0200 To: f-cpu@egroups.com Message-ID: <20000630150002.B30097@sxpert.localhost> References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> <395CA05E.B06001CC@hl.siemens.de> X-Mailer: Mutt 1.0pre3us In-Reply-To: <395CA05E.B06001CC@hl.siemens.de> From: Amaury JACQUOT MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:00:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 198718b0b11e0db2136b4238e3ee8088 Status: R X-Status: N On Fri, Jun 30, 2000 at 03:27:58PM +0200, Nicolas Boulay wrote:
> Yann Guidon wrote:
> >
> > Nicolas Boulay wrote:
> > > Yann Guidon wrote:
> > > > Nicolas Boulay wrote:
> > > > > I don't remember where i found this paper. But after a cross read, i
> > > > > think that it could be a good way to make more than 1 instruction per
> > > > > clock cycle efficiently and having a goog way to increase speed in the
> > > > > futur with keeping the compatibility.
> > > > tu aurais au moins pu le comprimer ;-)
> > > J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
> > > pas oser.
> > et GZIP, ou COMPRESS, c'est pour les chiens ? ;-)
> >
>
> Justement winzip est incompatible avec gzip
desole de te contredire sur ce coup la... tu devrais mettre ton winzip
a jour... (ca marche pour moi)...

Amaury
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02223 for ; Fri, 30 Jun 2000 19:29:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:01 +0200 (MEST) Received: (qmail 19631 invoked by uid 0); 30 Jun 2000 13:38:35 -0000 Received: from hm.egroups.com (208.50.144.92) by mx0.gmx.net with SMTP; 30 Jun 2000 13:38:35 -0000 X-eGroups-Return: sentto-1101623-387-962372277-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 30 Jun 2000 13:38:03 -0000 Received: (qmail 18218 invoked from network); 30 Jun 2000 13:37:57 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 13:37:57 -0000 Received: from unknown (HELO sxpert.dyndns.org) (212.43.199.14) by mta1 with SMTP; 30 Jun 2000 13:37:56 -0000 Received: (from sxpert@localhost) by sxpert.dyndns.org (8.9.3/8.8.7) id PAA30284 for f-cpu@egroups.com; Fri, 30 Jun 2000 15:03:48 +0200 To: f-cpu@egroups.com Message-ID: <20000630150348.D30097@sxpert.localhost> References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> <395CA05E.B06001CC@hl.siemens.de> <20000630150002.B30097@sxpert.localhost> <395CA25E.EED8B6C8@hl.siemens.de> X-Mailer: Mutt 1.0pre3us In-Reply-To: <395CA25E.EED8B6C8@hl.siemens.de> From: Amaury JACQUOT MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:03:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 99eaea400d64b3df136e5a1c26a63476 Status: R X-Status: N On Fri, Jun 30, 2000 at 03:36:30PM +0200, Nicolas Boulay wrote:
> Amaury JACQUOT wrote:
> >
> > On Fri, Jun 30, 2000 at 03:27:58PM +0200, Nicolas Boulay wrote:
> > > Yann Guidon wrote:
> > > >
> > > > Nicolas Boulay wrote:
> > > > > Yann Guidon wrote:
> > > > > > Nicolas Boulay wrote:
> > > > > > > I don't remember where i found this paper. But after a cross read, i
> > > > > > > think that it could be a good way to make more than 1 instruction per
> > > > > > > clock cycle efficiently and having a goog way to increase speed in the
> > > > > > > futur with keeping the compatibility.
> > > > > > tu aurais au moins pu le comprimer ;-)
> > > > > J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
> > > > > pas oser.
> > > > et GZIP, ou COMPRESS, c'est pour les chiens ? ;-)
> > > >
> > >
> > > Justement winzip est incompatible avec gzip
> > desole de te contredire sur ce coup la... tu devrais mettre ton winzip
> > a jour... (ca marche pour moi)...
> >
>
> C'est dans l'autre sens que cela ne marche pas
>
dans l'autre sens, va chercher le package unzip (voir freshmeat)
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02226 for ; Fri, 30 Jun 2000 19:29:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:02 +0200 (MEST) Received: (qmail 10224 invoked by uid 0); 30 Jun 2000 13:42:48 -0000 Received: from ch.egroups.com (207.138.41.144) by mx02.gmx.net with SMTP; 30 Jun 2000 13:42:48 -0000 X-eGroups-Return: sentto-1101623-386-962372195-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 30 Jun 2000 13:36:38 -0000 Received: (qmail 31228 invoked from network); 30 Jun 2000 13:36:35 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 30 Jun 2000 13:36:35 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta1 with SMTP; 30 Jun 2000 13:36:34 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5UDaXB01276 for ; Fri, 30 Jun 2000 15:36:33 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5UDaV027093 for ; Fri, 30 Jun 2000 15:36:32 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id PAA06183 for ; Fri, 30 Jun 2000 15:36:31 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id PAA26998 for ; Fri, 30 Jun 2000 15:35:02 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <395CA25E.EED8B6C8@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> <395CA05E.B06001CC@hl.siemens.de> <20000630150002.B30097@sxpert.localhost> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:36:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ffb298cd4cdf694a613df49bc4c5e147 Status: R X-Status: N Amaury JACQUOT wrote:
>
> On Fri, Jun 30, 2000 at 03:27:58PM +0200, Nicolas Boulay wrote:
> > Yann Guidon wrote:
> > >
> > > Nicolas Boulay wrote:
> > > > Yann Guidon wrote:
> > > > > Nicolas Boulay wrote:
> > > > > > I don't remember where i found this paper. But after a cross read, i
> > > > > > think that it could be a good way to make more than 1 instruction per
> > > > > > clock cycle efficiently and having a goog way to increase speed in the
> > > > > > futur with keeping the compatibility.
> > > > > tu aurais au moins pu le comprimer ;-)
> > > > J'y ai penser mais vu que je n'arrivais pas a decomprimer tes .zip, j'ai
> > > > pas oser.
> > > et GZIP, ou COMPRESS, c'est pour les chiens ? ;-)
> > >
> >
> > Justement winzip est incompatible avec gzip
> desole de te contredire sur ce coup la... tu devrais mettre ton winzip
> a jour... (ca marche pour moi)...
>

C'est dans l'autre sens que cela ne marche pas

> Amaury
>
> ------------------------------------------------------------------------
> IT Professionals: Match your unique skills with the best IT projects at
> http://click.egroups.com/1/3381/1/_/3462/_/962372094/
> ------------------------------------------------------------------------
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02235 for ; Fri, 30 Jun 2000 19:29:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:04 +0200 (MEST) Received: (qmail 17942 invoked by uid 0); 30 Jun 2000 14:03:50 -0000 Received: from c3.egroups.com (207.138.41.143) by mx02.gmx.net with SMTP; 30 Jun 2000 14:03:50 -0000 X-eGroups-Return: sentto-1101623-388-962373473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 30 Jun 2000 13:57:55 -0000 Received: (qmail 12062 invoked from network); 30 Jun 2000 13:57:53 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 30 Jun 2000 13:57:53 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta1 with SMTP; 30 Jun 2000 13:57:53 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NN9KR6LH; Fri, 30 Jun 2000 15:56:21 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 15:57:52 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE241@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 15:56:46 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] A propos de WINZIP/UNZIP/GZIP Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ef882ead7125dee5b1f9fd891b759084 Status: R X-Status: N Bonjour =E0 tous.

J'interviens dans le d=E9bat car =E7a va mal tourner :-).

  WINZIP 7.0 peut d=E9compresser des unzip,gzip, des tar zipp=E9es. Je l'ai fait pour les fichiers re=E7us dans cette mail list.

  Voila.

            A +.

              &= nbsp;   Olivier.
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02244 for ; Fri, 30 Jun 2000 19:29:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:06 +0200 (MEST) Received: (qmail 31398 invoked by uid 0); 30 Jun 2000 14:15:41 -0000 Received: from hk.egroups.com (208.50.144.91) by mx02.gmx.net with SMTP; 30 Jun 2000 14:15:41 -0000 X-eGroups-Return: sentto-1101623-389-962374410-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 30 Jun 2000 14:13:36 -0000 Received: (qmail 12198 invoked from network); 30 Jun 2000 14:13:29 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 30 Jun 2000 14:13:29 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 30 Jun 2000 14:13:27 -0000 Received: from dotcom.fr (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id OAA22062 for ; Fri, 30 Jun 2000 14:13:25 GMT Message-ID: <395CAB13.C3177AC5@dotcom.fr> Organization: DotCom S.A. X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <098A4E5B420CD3118F690008C75DD5DD029AE241@NTS40.sbf.bourseparis.com> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 16:13:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] A propos de WINZIP/UNZIP/GZIP Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 515c924e130c91d71b7e57680666a7b9 Status: R X-Status: N JEAN Olivier a =E9crit :
>
>  Bonjour =E0 tous.
>
>  J'interviens dans le d=E9bat car =E7a va mal tourner :-).
>
>   WINZIP 7.0 peut d=E9compresser des unzip,gzip, des tar zip= p=E9es.
>  Je l'ai fait pour les fichiers re=E7us dans cette mail list.
>
>   Voila.
>

Est-ce qu'=E0 l'inverse, il peut produire des fichiers d=E9compressibles pa= r
gzip ? (je crois que le probl=E8me est l=E0, non?)

--
Nicolas MATRINGE          = ; DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      92400 COURBEVOIE
Fax +33 1 46 67 51 01      FRANCE
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02247 for ; Fri, 30 Jun 2000 19:29:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:06 +0200 (MEST) Received: (qmail 12472 invoked by uid 0); 30 Jun 2000 14:48:04 -0000 Received: from hi.egroups.com (208.50.144.89) by mx0.gmx.net with SMTP; 30 Jun 2000 14:48:04 -0000 X-eGroups-Return: sentto-1101623-390-962376226-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 30 Jun 2000 14:43:52 -0000 Received: (qmail 24804 invoked from network); 30 Jun 2000 14:43:41 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 14:43:41 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta1 with SMTP; 30 Jun 2000 14:43:41 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NN9KR7VG; Fri, 30 Jun 2000 16:42:10 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 16:43:41 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE242@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 16:42:36 +0200 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] A propos de WINZIP/UNZIP/GZIP Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 84d859106fea39e88f4465b777dfb4d4 Status: R X-Status: N
>
JEAN Olivier a =E9crit :
>
>  Bonjour =E0 tous.
>
>  J'interviens dans le d=E9bat car =E7a va mal tourner :-).
>
>   WINZIP 7.0 peut d=E9compresser des unzip,gzip, des tar zip= p=E9es.
>  Je l'ai fait pour les fichiers re=E7us dans cette mail list.
>
>   Voila.
>

Est-ce qu'=E0 l'inverse, il peut produire des fichiers d=E9compressibles pa= r
gzip ? (je crois que le probl=E8me est l=E0, non?)

> Pour unzip c'est sur. Mais je pense que gzip aussi.
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA02253 for ; Fri, 30 Jun 2000 19:29:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 30 Jun 2000 19:29:08 +0200 (MEST) Received: (qmail 21042 invoked by uid 0); 30 Jun 2000 15:06:21 -0000 Received: from hj.egroups.com (208.50.144.90) by mx06.rz2.gmx.net with SMTP; 30 Jun 2000 15:06:21 -0000 X-eGroups-Return: sentto-1101623-391-962377526-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hj.egroups.com with NNFMP; 30 Jun 2000 15:05:30 -0000 Received: (qmail 6998 invoked from network); 30 Jun 2000 15:05:25 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 30 Jun 2000 15:05:25 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta1 with SMTP; 30 Jun 2000 15:05:25 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NN9KR8BJ; Fri, 30 Jun 2000 17:03:54 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 17:05:25 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE244@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 17:04:19 +0200 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 56191eee37b69f3c47cbf14df0b00259 Status: R X-Status: N hi again,

just to note something i forgotten :

Nicolas Boulay wrote:
>
> Albert Abramson wrote:
> >
> > All I've been suggesting lately was building a pure VLIW core wit= h no
> > decode -- only execution resources -- so that whatever technology= we
> > chose to use would allow us to fit the maximum number of cores on= one
> > die, whatever material and whatever transistors we'd be using. > That the idea of lot of people, but how maintain a binary compatibilit= y
> with futur core with pure VLIW (without recompiling)?
that's a major question. nobody wants to reinterpret opcodes either in HW o= r
SW.

> > The reason I've been looking at ECL is because you can now get up= into
> > the 2-5 million transistor range, easily enough to build VLIW pro= cessors
> > of decent width.  Most of the real estate on uP's these days= is becoming
> > wire, anyway, and CMOS cannot take advantage of the benefits of s= ub .1
> > anyway.

there i stop you and let you remember a little single FACT :
where it takes 1 CMOS or bipolar transitor, it takes 6 ECL transistors
to make a gate. i guess that on average the surface needed for ECL is
4x the surface needed otherwise. so if you can have 5MT in ECL, you end up<= BR> having one million gates only. not terrific...

i just wanted to make this detail clear, re-read you digital electronics books
and your P&H bible(s). I see ECL today in transmission lines, not in th= e
digital
computation logic gates : it's used for communication on the CPU bus at
100Mhz++
for example. and it draws a LOT of power. no wonder CMOS is alive and well.=

but as noted before, that's not my problem. Si will be suplanted by
supraconductors in 20 or 30 years. by or before 2010, the US gov. will have=
its PETAFLOPS computer ready, made of a few thousands of terahertz CPUs. there, the challenges you're raising will be funny problems compared to
what i expect... imagine a computer that requires almost one million
CPU cycles to access the main memory, in a fridge that keeps the temperatur= e
at around 3 degrees Kelvin, and that can contain several cubic meters
of liquid nitrogen...

> Well. I've worked on Supraconductor. I think It's not for tomorrow th= at
the
supraconductor will replace the Si technology. The highest temperature
reached is about
82=B0K. And at the moment, the physicist don't find an another compound to = get
a supraconductor
at the ambiant temperature. They have reached a stage but perhaps, one day<= BR> ...
But one day, the dream will be a reality.


            Olivier.

PS : Nitrogen =3D azote =3D> 72 =B0K, not 3=B0K ( I'm sorry I don't rem= ember
exactly the true value )
      Hydrogen =3D> 3=B0K
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01924 for ; Sun, 2 Jul 2000 02:38:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:25 +0200 (MEST) Received: (qmail 16894 invoked by uid 0); 30 Jun 2000 17:28:28 -0000 Received: from fk.egroups.com (208.50.144.73) by mx0.gmx.net with SMTP; 30 Jun 2000 17:28:28 -0000 X-eGroups-Return: sentto-1101623-392-962384862-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 30 Jun 2000 17:07:48 -0000 Received: (qmail 741 invoked from network); 30 Jun 2000 17:07:42 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 30 Jun 2000 17:07:42 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta1 with SMTP; 30 Jun 2000 17:07:42 -0000 Received: from 0018728164 (host-209-214-154-60.bix.bellsouth.net [209.214.154.60]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id NAA20071; Fri, 30 Jun 2000 13:07:40 -0400 (EDT) Message-ID: <000a01bfe2b5$86e86b80$3c9ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 12:06:24 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Language Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BFE28B.9CD37AE0" X-UIDL: fa0c2c8ded24121295b76d2a21492b9a Status: R X-Status: N ------=_NextPart_000_0007_01BFE28B.9CD37AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I studied the French Language in Grammer School some 60 years ago. Due = to lack of useage - its gone. I speak American English. If I continue = to receive stuff I can't read or understand, in any other Language; I will remove = myself from distribution and you may contact me at - rhartney@bellsouth.net. Gaday ------=_NextPart_000_0007_01BFE28B.9CD37AE0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
I studied the French Language in Grammer School some 60 years ago.  Due to lack of useage - its gone.  I speak American English.  If I continue to receive
stuff I can't read or understand, in any other Language; I will remove myself from
distribution and you may contact me at  -  rhartney@bellsouth.net.
 
Gaday
------=_NextPart_000_0007_01BFE28B.9CD37AE0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01929 for ; Sun, 2 Jul 2000 02:38:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:28 +0200 (MEST) Received: (qmail 6851 invoked by uid 0); 30 Jun 2000 17:58:46 -0000 Received: from hi.egroups.com (208.50.144.89) by mx0.gmx.net with SMTP; 30 Jun 2000 17:58:46 -0000 X-eGroups-Return: sentto-1101623-395-962387921-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 30 Jun 2000 17:58:42 -0000 Received: (qmail 5120 invoked from network); 30 Jun 2000 17:58:40 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 17:58:40 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 30 Jun 2000 17:58:40 -0000 Received: from f-cpu.org (Paris-Raspail-2-247.club-internet.fr [195.36.192.247]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA02073 for ; Fri, 30 Jun 2000 19:58:37 +0200 (MET DST) Message-ID: <395CDF92.103A0557@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> <395CA05E.B06001CC@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 19:57:38 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cbf25d165818a0ead3522a1d31aa1f7c Status: R X-Status: N Nicolas Boulay wrote:
> Yann Guidon wrote:
> > Nicolas Boulay wrote:
> > > Yann Guidon wrote:
> > > > SMT is a good way to increase the CPU utilization.
> > > > i've been thinking about it for some years, but the first problem
> > > > is the huge register bank it requires, so it won't be useful for
> > > > the first protos. It will be useful anyway the day we'll want to
> > > > beat the Alpha 21464 :-)
> > > >
> > > > before we start adding instructions we should first analyze what's
> > > > really needed. but there's no hurry even if i believe more
> > > > in SMT than VLIW because it transforms a hazard into a "switch".
> > > > OTOH i fear that it will make people believe that it's still OK
> > > > to code badly.
> > > >
> > >
> > > It's always possible to create a 2 ways SMT or even a one ways ;-) and
> > > used some special register to describe this feature. The most important
> > > is to have the ISA adapted to this feature.
> > i'm pretty convinced that the current ISA is ready for SMT.
> > if anyone has an idea or detects a flaw, tell me :-)
> Ready : what does it mean ? I supposed that for SMT you need some more
> PC, and to make it flexible "some" should not be fixed. And we need to
> prouve that a compilation for a 2 ways SMT work for a 8 ways. This
> permit very (very) deep pipeling without many probleme with
> dependancies.

The idea behind SMT is that the CPU core "shares" the Execution Units
between the different threads "on the fly" (dynamically).
the instruction set should need no modification, you have to make some HW
modifications but that does not influence the instructions themselves.

unless there's something i didn't know.

> But you need more registers, it isn't really a probleme a flip-flop is
> composed by around 40 transistors so it's <164000 transistors for
> register banks of 64 registers of 64b. That's not a so big deal.
well, it's very relative :-)
what about access time and wire lengths...

> <snip>
idem.

> > > nicO
> > > > WHYGEE
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01932 for ; Sun, 2 Jul 2000 02:38:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:30 +0200 (MEST) Received: (qmail 21579 invoked by uid 0); 30 Jun 2000 17:59:01 -0000 Received: from hm.egroups.com (208.50.144.92) by mx02.gmx.net with SMTP; 30 Jun 2000 17:59:01 -0000 X-eGroups-Return: sentto-1101623-394-962387914-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 30 Jun 2000 17:58:35 -0000 Received: (qmail 5786 invoked from network); 30 Jun 2000 17:58:34 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 30 Jun 2000 17:58:34 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 30 Jun 2000 17:58:33 -0000 Received: from f-cpu.org (Paris-Raspail-2-247.club-internet.fr [195.36.192.247]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA15220 for ; Fri, 30 Jun 2000 19:58:31 +0200 (MET DST) Message-ID: <395CDF94.90AFB81B@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000a01bfe2b5$86e86b80$3c9ad6d1@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 19:57:40 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Language Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d5f8af0fa0cc54e6ca75983058e677e6 Status: R X-Status: N

> "Richard E.Hartney" wrote:
>
> I studied the French Language in Grammer School some 60 years ago.&nbs= p; Due to lack of useage - its gone.  I speak American English.  = If I continue to receive
> stuff I can't read or understand, in any other Language; I will remove= myself from
> distribution and you may contact me at  -  rhartney@bellsout= h.net.
>
> Gaday

sorry Richard, it ain't my fault :-)

i know that others are frustrated. but sometimes the frenchies don't realiz= e :-)


Ok les gars, il y a une list f-cpu_france@egroups.com
sur laquelle le d=E9bat a commenc=E9 =E0 tourner. RV l=E0-bas.

(we're such kids, sometimes...)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01936 for ; Sun, 2 Jul 2000 02:38:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:31 +0200 (MEST) Received: (qmail 14484 invoked by uid 0); 30 Jun 2000 17:58:45 -0000 Received: from b05.egroups.com (207.138.41.189) by mx02.gmx.net with SMTP; 30 Jun 2000 17:58:45 -0000 X-eGroups-Return: sentto-1101623-393-962387907-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 30 Jun 2000 17:58:38 -0000 Received: (qmail 4640 invoked from network); 30 Jun 2000 17:58:27 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 17:58:27 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 30 Jun 2000 17:58:27 -0000 Received: from f-cpu.org (Paris-Raspail-2-247.club-internet.fr [195.36.192.247]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA04321 for ; Fri, 30 Jun 2000 19:58:23 +0200 (MET DST) Message-ID: <395CDF8D.51F1A75@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <098A4E5B420CD3118F690008C75DD5DD029AE244@NTS40.sbf.bourseparis.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 19:57:33 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ac524a81cf60963022df710c868eebb9 Status: R X-Status: N

JEAN Olivier wrote:

> Well. I've worked on Supraconductor. I think It's not for tomorrow tha= t the
> supraconductor will replace the Si technology.
no, but after :-)

> The highest temperature reached is about 82=B0K.
that's not the problem. there are some people (financed by the US tax payer= s)
who have enough money to build a huge refrigerator.

> And at the moment, the physicist don't find an another compound to get=
> a supraconductor at the ambiant temperature. They have reached a stage=
> but perhaps, one day ... But one day, the dream will be a reality.
i hope i'll still be alive :-)

>            = ;     Olivier.
>  PS : Nitrogen =3D azote =3D> 72 =B0K, not 3=B0K ( I'm sorry I= don't remember
> exactly the true value, Hydrogen =3D> 3=B0K
well, what you mention is the liquid/gaz transition temperature.
i think that nothing keeps you from going below :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01963 for ; Sun, 2 Jul 2000 02:38:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:36 +0200 (MEST) Received: (qmail 1553 invoked by uid 0); 30 Jun 2000 21:27:38 -0000 Received: from c3.egroups.com (207.138.41.143) by mx02.gmx.net with SMTP; 30 Jun 2000 21:27:38 -0000 X-eGroups-Return: sentto-1101623-398-962400445-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 30 Jun 2000 21:27:33 -0000 Received: (qmail 7208 invoked from network); 30 Jun 2000 21:27:24 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 30 Jun 2000 21:27:24 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 30 Jun 2000 21:27:24 -0000 Received: from welfen-netz.com [213.6.143.60] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 30 Jun 2000 23:26:50 +0200 Sender: kai@pop.gmx.net Message-ID: <395D7D78.D2033B42@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> <3959C1C7.28CF4AF6@hl.siemens.de> <3959CF9D.ED915466@f-cpu.org> <3959D56D.A388F73A@hl.siemens.de> <395A788E.7862927F@f-cpu.org> <395CA05E.B06001CC@hl.siemens.de> <395CDF92.103A0557@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 07:11:20 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b67e6be1be96713523b1d49986693a9b Status: R X-Status: N Yann Guidon wrote:
[...]
> The idea behind SMT is that the CPU core "shares" the Execut= ion Units
> between the different threads "on the fly" (dynamically).
And that's the problem with the SMT approach:  It makes a more
advanced control logic necessary and increases complexity of the
core just as all the other dynamic stuff potentially does:
beyond beleive ;=B0>

I think a statically interleaved multi-threaded design is the way to go: It looks like a multi-core processor with a shared cache and the
complexity is in the individual units and the register-file to units
busses*.  4-way multi-threaded should be feasible, 8-way could
probably be accomplished with some tweaks.

* and the cache design has to be pretty good !

> the instruction set should need no modification, you have to make some= HW
> modifications but that does not influence the instructions themselves.=

It depends: while a static in-order-issue RISC core would allow
dynamically resceduling of instructions (and units) it would
really be a complexity-nightmare, so that approach doesn't favour
SMT but leads to "only" static MT.

> unless there's something i didn't know.
>
> > But you need more registers, it isn't really a probleme a flip-fl= op is
> > composed by around 40 transistors so it's <164000 transistors = for
> > register banks of 64 registers of 64b. That's not a so big deal.<= BR> > well, it's very relative :-)
> what about access time and wire lengths...

Good point, must be considered.

[...]
Regards,
kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01966 for ; Sun, 2 Jul 2000 02:38:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:37 +0200 (MEST) Received: (qmail 5407 invoked by uid 0); 30 Jun 2000 21:27:40 -0000 Received: from ho.egroups.com (208.50.144.85) by mx09.rz2.gmx.net with SMTP; 30 Jun 2000 21:27:40 -0000 X-eGroups-Return: sentto-1101623-396-962400445-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ho.egroups.com with NNFMP; 30 Jun 2000 21:27:34 -0000 Received: (qmail 7203 invoked from network); 30 Jun 2000 21:27:24 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 21:27:24 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 30 Jun 2000 21:27:24 -0000 Received: from welfen-netz.com [213.6.143.60] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 30 Jun 2000 23:26:46 +0200 Sender: kai@pop.gmx.net Message-ID: <395D798A.FCA91720@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 06:54:34 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f98e70cb3cdaeb76281430ecb63ef4d5 Status: R X-Status: N Nicolas Boulay wrote:
>
> Albert Abramson wrote:
> >
> > All I've been suggesting lately was building a pure VLIW core wit= h no
> > decode -- only execution resources -- so that whatever technology= we
> > chose to use would allow us to fit the maximum number of cores on= one
> > die, whatever material and whatever transistors we'd be using. > >
>
> That the idea of lot of people, but how maintain a binary compatibilit= y
> with futur core with pure VLIW (without recompiling)?

Hmm, I think we gain a lot if we decouple binary compatibility from
the instruction set used by the CPU:

1. secondary isa describes a machine language for the FCPU arch.
2. primary instruction set specifies the machine language of a
   specific implementation fed into the core.

The secondary ISA including hints for parallellism, etc. and could be turne= d
into
primary instructions:
1. on load/install/... or on demand
2. re-hinted if the FCPU implementaion provides (optional) statistical serv= ices.

Decoupling ISA from primary instruction set enables us to innovate
within a significantly increased range at either level, but most importantl= y
regarding specific core design (number of units, issue-width, etc.)

Tying the ISA to the core is not a good idea: Either we limit ourselves
severely or the converter logic becomes increasingly complex (see 80x86 := =B0)

[...]
kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01969 for ; Sun, 2 Jul 2000 02:38:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:38 +0200 (MEST) Received: (qmail 23339 invoked by uid 0); 30 Jun 2000 21:27:42 -0000 Received: from fk.egroups.com (208.50.144.73) by mx02.gmx.net with SMTP; 30 Jun 2000 21:27:42 -0000 X-eGroups-Return: sentto-1101623-399-962400445-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 30 Jun 2000 21:27:34 -0000 Received: (qmail 1556 invoked from network); 30 Jun 2000 21:27:24 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 30 Jun 2000 21:27:24 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 30 Jun 2000 21:27:24 -0000 Received: from welfen-netz.com [213.6.143.60] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 30 Jun 2000 23:26:54 +0200 Sender: kai@pop.gmx.net Message-ID: <395D835C.557A870B@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> <395C3588.9029A35D@nventure.com> <395C95C9.19B9848D@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 07:36:28 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SHP uP's [was Adders/Subtractors] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: af0760067495314669fad5ed8b099554 Status: R X-Status: N Yann Guidon wrote:
>
> Albert Abramson wrote:
[...]
> what qualities should the F-CPU microarchitecture have ?
> we know that it must be very efficient, that's sure.
> OTOH we know that we have a handicap : we're not a
> big company with thousands of very skilled engineers
> (organisation is another problem). we know we can't
> beat big companies from a purely technical ground.
> so let's make the coolest CPU ever.

Good point.

> RISC vs VLIW ? an interesting debate. 3 years ago,
> nobody knew what it is. But the IA64 is not the first (pseudo-)VLIW > ever, and VLIW is as old as the RISC concept.
> I estimate that RISC has a faster acceptation way than VLIW.
> mostly because of the compilers, the way VLIW fist the applications, > the marginal efforts and the more complex management.

If VLIW doesn't mean each and every word actually has to be large, VLIW
becomes a misnomer, in a way : The question is whether resceduling
in hardware, OOO execution, dynamic branch prediction, and their friends ar= e
worth the die space they're on - or not =3D=B0)  I don't think they ne= ed to
be implied by the term "RISC", do they ?

> OTOH RISC vs VLIW are on the same level when it comes to
> "scalability" : extending RISC makes the core more complex
And marginal utility of adding a few transistors decreases at top rate...
[...]
> >  If we need to expand the
> > microarchitecture, we ought to provide a programming model that p= ermits
> > the description of a virtual machine with a hazy kind of reg-mem-= message
> > passing model that is simulated by either some advanced hardware = or some
> > dynamic optimization software.
> that's getting pretty complex for a "simple device"...

Well, the complexity is not in the _device_, I think that's the whole point= :O)

> don't you forget a major paramater ? how (easily) will you program it = in
> a high-level langage ?

>From another point of view: why should hardware designers acommondate for lousy or plain dumb software ?  If a static core can be instructed eff= iciantly
at all, though the statistics package is not included, then it's IMO not of major concern whether software has reached that level yet - that would only keep us down at the bottom.

[...]
> >  Could these other "registers" then be read by oth= er running
> > cores to enable superior fine-grain multi-threading?
> yuk. argh. you're a kamikaze.

Yes, sharing registers could easily become a nightmare...

> > Super high performance processors in the future will depend on ge= tting
> > around some of the limitations that we are just recognizing today= .
> is SMT some part of the answer ? i guess, in part.
>
> if you want to make a VLIW FC1, go ahead and program/draw some
> prototypes. i don't like to discuss like that, without tangible
> facts (other than articles in the press).

Well, I'm not well-informed on th concept of VLIW but making a design
which _requires_ dynamic resceduling in hardware sounds like
a complication of the CPU which could really hold us back due
to our limited design capacity, I think.  Whether _VLIW_ is the right = answer,
I don't know.

kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01972 for ; Sun, 2 Jul 2000 02:38:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:39 +0200 (MEST) Received: (qmail 8570 invoked by uid 0); 30 Jun 2000 21:27:50 -0000 Received: from mv.egroups.com (208.50.144.81) by mx02.gmx.net with SMTP; 30 Jun 2000 21:27:50 -0000 X-eGroups-Return: sentto-1101623-397-962400445-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 30 Jun 2000 22:27:45 -0000 Received: (qmail 7209 invoked from network); 30 Jun 2000 21:27:24 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Jun 2000 21:27:24 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 30 Jun 2000 21:27:24 -0000 Received: from welfen-netz.com [213.6.143.60] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 30 Jun 2000 23:26:57 +0200 Sender: kai@pop.gmx.net Message-ID: <395D8449.40373CD1@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 07:40:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 084fd43475c2142e2e74a42588d8f2b8 Status: R X-Status: N Albert Abramson wrote:
>
> All I've been suggesting lately was building a pure VLIW core with no
> decode -- only execution resources -- so that whatever technology we
> chose to use would allow us to fit the maximum number of cores on one
> die, whatever material and whatever transistors we'd be using.

I think the idea of no decode is a very good one!  Do I get it wrong
or is the main point of VLIW replacing dynamically reordered run-time
8-issue by an instruction-encoded 8-issue (for example) ?

> Scalability is done, then, not by widening the data paths with new
> instructions, but by adding more cores, which would be almost all
> hardware.

Good.

[...]
> The point is, more transistors are not always better.  That was my beef
> with the crossbar.  Too much pipelining means more control hardware,
> which can already use up 3/4 of all logic on these things, and that's
> getting worse, not better.

Wasted transistors are really sad ...

Regards,
kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01975 for ; Sun, 2 Jul 2000 02:38:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:40 +0200 (MEST) Received: (qmail 32567 invoked by uid 0); 30 Jun 2000 21:44:30 -0000 Received: from ci.egroups.com (207.138.41.176) by mx12.rz2.gmx.net with SMTP; 30 Jun 2000 21:44:30 -0000 X-eGroups-Return: sentto-1101623-400-962401466-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 30 Jun 2000 21:44:28 -0000 Received: (qmail 16967 invoked from network); 30 Jun 2000 21:44:15 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 30 Jun 2000 21:44:15 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta1 with SMTP; 30 Jun 2000 21:44:15 -0000 Received: from modem-28.arkansas.dialup.pol.co.uk ([62.137.55.28] helo=sargon.chrystal.gbr.xerox.com) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 1388a5-0008Hj-00 for f-cpu@egroups.com; Fri, 30 Jun 2000 22:44:13 +0100 To: f-cpu@egroups.com Message-ID: From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 22:37:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Language Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: bc35e4924d4f8871de0bab7bfed5ca1f Status: R X-Status: N > "Richard E.Hartney" wrote:
>
> I studied the French Language in Grammer School some 60 years ago.&nbs= p; Due
to lack of useage - its gone.  I speak American English.  If I co= ntinue to
receive
> stuff I can't read or understand, in any other Language; I will remove=
myself from
> distribution and you may contact me at  -  rhartney@bellsout= h.net.
>
> Gaday

sorry Richard, it ain't my fault :-)

i know that others are frustrated. but sometimes the frenchies don't
realize :-)


Ok les gars, il y a une list f-cpu_france@egroups.com
sur laquelle le d=E9bat a commenc=E9 =E0 tourner. RV l=E0-bas.

(we're such kids, sometimes...)


*** Jeff Davies:  Peut etre tu est pas l'enfant ici!!!  Monsieur = H. est
comme les anglais qui aller en vacances (en autres pays) et jamais essayer =
parler une autre langue. Je suis pas si bon en francais mais j'essaye.
JD

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01984 for ; Sun, 2 Jul 2000 02:38:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:42 +0200 (MEST) Received: (qmail 19569 invoked by uid 0); 1 Jul 2000 01:07:46 -0000 Received: from fl.egroups.com (208.50.144.74) by mx02.gmx.net with SMTP; 1 Jul 2000 01:07:46 -0000 X-eGroups-Return: sentto-1101623-401-962413649-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 01 Jul 2000 01:07:31 -0000 Received: (qmail 21499 invoked from network); 1 Jul 2000 01:07:29 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 1 Jul 2000 01:07:29 -0000 Received: from unknown (HELO orinoco.portland.co.uk) (212.15.64.41) by mta1 with SMTP; 1 Jul 2000 01:07:28 -0000 Received: from yo (1Cust19.tnt2.rehoboth.de.da.uu.net [63.39.61.19]) by orinoco.portland.co.uk (AIX4.3/8.9.3/8.8.8) with SMTP id BAA56224; Sat, 1 Jul 2000 01:06:09 GMT Message-Id: <200007010106.BAA56224@orinoco.portland.co.uk> X-Priority: 3 X-MSMail-Priority: Normal From: homecareeropp@acton-london.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Jun 2000 16:16:05 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Discover The Ultimate Opportunity Content-Type: multipart/mixed; boundary="----=_NextPart_000_0BCC_000004BF.000011E4" To: sloyment@gmx.net X-UIDL: 2a511c75aed57aec10a851aa55e832ec Status: R X-Status: N ------=_NextPart_000_0BCC_000004BF.000011E4 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit LOOKING FOR GEMS!

It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!

Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme?

If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need.

Call NOW our TOLL FREE, PRE-RECORDED Message:1-800-320-9895 ext. 6215

We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you.

You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now!

The call is FREE, and there is absolutely no obligation, So what have you got to lose?

Call Toll Free 1-800-320-9895 ext. 6215

P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life!

Please, serious inquiries only.







To be removed from future mailings send a blank email with remove in the subject line and
the email address or addresses to be removed in the body to
homecareer@acton-london.co.uk

------=_NextPart_000_0BCC_000004BF.000011E4-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02026 for ; Sun, 2 Jul 2000 02:38:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:50 +0200 (MEST) Received: (qmail 16717 invoked by uid 0); 1 Jul 2000 14:52:23 -0000 Received: from mu.egroups.com (207.138.41.151) by mx02.gmx.net with SMTP; 1 Jul 2000 14:52:23 -0000 X-eGroups-Return: sentto-1101623-403-962463140-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 01 Jul 2000 15:52:22 -0000 Received: (qmail 8730 invoked from network); 1 Jul 2000 14:52:19 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 1 Jul 2000 14:52:19 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 1 Jul 2000 14:52:19 -0000 Received: from f-cpu.org (Paris-Raspail-1-143.club-internet.fr [195.36.192.143]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA21412 for ; Sat, 1 Jul 2000 16:52:13 +0200 (MET DST) Message-ID: <395E0565.71B986E3@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 16:51:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Language Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2d55b6a123a71b237d9c520cf6d61a32 Status: R X-Status: N Jeff Davies/CDPTEST wrote:
> > "Richard E.Hartney" wrote:
> (we're such kids, sometimes...)
>
> *** Jeff Davies:  Peut etre tu est pas l'enfant ici!!!  Monsieur H. est
> comme les anglais qui aller en vacances (en autres pays) et jamais essayer
> parler une autre langue. Je suis pas si bon en francais mais j'essaye.

:-) that's fun anyway :-) [thanks for your support]

if you want to practice more, you're welcome on the french mailing list :-)

> JD
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02029 for ; Sun, 2 Jul 2000 02:38:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:51 +0200 (MEST) Received: (qmail 2329 invoked by uid 0); 1 Jul 2000 14:52:24 -0000 Received: from mw.egroups.com (207.138.41.167) by mx10.rz2.gmx.net with SMTP; 1 Jul 2000 14:52:24 -0000 X-eGroups-Return: sentto-1101623-402-962463140-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 01 Jul 2000 14:52:23 -0000 Received: (qmail 25154 invoked from network); 1 Jul 2000 14:52:19 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 1 Jul 2000 14:52:19 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 1 Jul 2000 14:52:19 -0000 Received: from f-cpu.org (Paris-Raspail-1-143.club-internet.fr [195.36.192.143]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA13247 for ; Sat, 1 Jul 2000 16:47:46 +0200 (MET DST) Message-ID: <395E056A.EF838114@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 16:51:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9df679b1644fda0bae882825d36de7c8 Status: R X-Status: N hi,

just a criticism, to cool Maxx's optimism :

Kai Wetzel wrote:
> Albert Abramson wrote:
> > Scalability is done, then, not by widening the data paths with ne= w
> > instructions, but by adding more cores, which would be almost all=
> > hardware.
>
> Good.

this kind of organisation looks very fine, until you want to program it. this fits special needs, like signal processing (some DSP use this
organisation) but when it comes to run "real-world" spreadsheet o= r,
say, tetris, from a C source, that's a different problem.

what i say is : don't forget Amdahl's laws. don't forget that the
maximum overal ILP that can be extracted from a C source is 3 instructions<= BR> per cycle on an ideal case (no cache miss, no misprediction, infinite
registers, and most of all : zero pipeline stage). i don't trust/believe in=
compilers, too.

this means that you've got to prove that you can make a C compiler
that exploits 100% of your architecture for a wide range of common applicat= ions.
don't forget that RISC can also mean "Relegate the Important Stuff to = the
Compiler". You seem to relegate too much, based on your architectural<= BR> estimations, but you don't seem to have a clue about the compiler behind. On a RISC machine, the compiler must be designed along with the microarchit= ecture
(that's why i also (try to) run the GNL project). If you have no clue about= how Bison
and Flex work, i'd advice you to read some of the litterature (for example<= BR> the "Dragon Book") and try to make a toy compiler yourself, so yo= u see the
gap between the ideal world and the reality.

go look at IBM's and other's project for VLIWs : they come with a
complex and sophisticated compiler/HW codesign.





Kai Wetzel wrote:
>
> Yann Guidon wrote:
> >
> > Albert Abramson wrote:
> [...]
> > RISC vs VLIW ? an interesting debate. 3 years ago,
> > nobody knew what it is. But the IA64 is not the first (pseudo-)VL= IW
> > ever, and VLIW is as old as the RISC concept.
> > I estimate that RISC has a faster acceptation way than VLIW.
> > mostly because of the compilers, the way VLIW fits the applicatio= ns,
> > the marginal efforts and the more complex management.
> If VLIW doesn't mean each and every word actually has to be large, VLI= W
> becomes a misnomer, in a way : The question is whether resceduling
> in hardware, OOO execution, dynamic branch prediction, and their frien= ds are
> worth the die space they're on - or not =3D=B0)  I don't think th= ey need to
> be implied by the term "RISC", do they ?

i don't know exactly, this is a complex question. RISC is meant to
simplify CPU design : no more microcode, no more complex exception
handling hardware, no more variable-width instructions that take
ages to decode. think like in a CRAY 1.

As well as the RISC concept becomes more fuzzy, VLIW becomes less
and less precise. more people work on it now and the general sense
of the term is blurred. yes, the idea was to have a very large
statically scheduled instruction word, but THAT WAS IN 1980 !
CPU cores have evolved and RISC succeeded to follow this trend,
while VLIW is still very complex in practice, both in HW and SW.
OTOH some microcoded machines like Richard's ERIN can claim to have
"very long instruction words" and that's a different (false) prob= lem.

> > OTOH RISC vs VLIW are on the same level when it comes to
> > "scalability" : extending RISC makes the core more comp= lex
> And marginal utility of adding a few transistors decreases at top rate= ...
that should be solved with SMT.

> [...]
> > >  If we need to expand the
> > > microarchitecture, we ought to provide a programming model t= hat permits
> > > the description of a virtual machine with a hazy kind of reg= -mem-message
> > > passing model that is simulated by either some advanced hard= ware or some
> > > dynamic optimization software.
> > that's getting pretty complex for a "simple device"...<= BR> > Well, the complexity is not in the _device_, I think that's the whole = point :O)
and you end up in the Transmeta case, where they sell "wind"... you believe that you win months in the HW design phase, while in fact you c= an't
run anything because the reinterpretation SW takes ages to design.

> > don't you forget a major paramater ? how (easily) will you progra= m it in
> > a high-level langage ?
> From another point of view: why should hardware designers acommondate = for
> lousy or plain dumb software ?
because you can't force SW to be intelligent.
sometimes, "dumbness" is just "old SW compiled for a differe= nt machine",
or "wrong/inefficient algorithm" or anything else.

as for the "accomodate", i believe that i didn't decrease the pre= ssure
on the SW with the FC0.

don't forget that a 10MHz pipeline stagein a 1.5u has nothing to do
with a 500MHz 0.18u pipeline stage : that is a "hidden" part of t= he complexity
that Albert claims to solve. in order to reduce drastically the CPU complex= ity,
it should have only one or two stages, like decode and execute, but the fre= quency
drops dramatically. if you want to sustain high frequencies, you have to sp= lit
everything, down to the logic level, and this takes some logic, too,
but this logic is NECESSARY to increase the frequency.

>  If a static core can be instructed efficiantly
> at all, though the statistics package is not included, then it's IMO n= ot
> of major concern whether software has reached that level yet - that wo= uld
> only keep us down at the bottom.
i'm not sure to understand 100% what you said, but that's a bogus point of = view for
me. would you think i'm sane/honnest if i tell you :
"i made this terrific 100GHz cpu, but due to memory bandwidth restrict= ions,
you can't execute an instruction at every clock cycle". change the mem= ory
bandwidth with either the compiler or the application, and that's the same = :
what's the point of having, say, a 16-way VLIW system if you can seriously<= BR> execute only 3 instructions in a cycle ????

> [...]
> > > Super high performance processors in the future will depend = on getting
> > > around some of the limitations that we are just recognizing = today.
> > is SMT some part of the answer ? i guess, in part.
> >
> > if you want to make a VLIW FC1, go ahead and program/draw some > > prototypes. i don't like to discuss like that, without tangible > > facts (other than articles in the press).
>
> Well, I'm not well-informed on th concept of VLIW but making a design<= BR> > which _requires_ dynamic resceduling in hardware sounds like
> a complication of the CPU which could really hold us back due
> to our limited design capacity, I think.  Whether _VLIW_ is the r= ight answer,
> I don't know.

someone (i don't know his name, a great musician anyway) said :
"before you play two notes, learn to play one note.
and before you play a single note, ask yourself why you have to play it.&q= uot;

same goes for the instructions : VLIW is fine, but let's start with
one instruction first : that's 70% of the work. there are many ways to exte= nd
this, but there's no point executing even 2 instructions if you can't execu= te
1 instruction correctly, right ? there are several problems that can arise,=
like exceptions or context switches, that can become seriously difficult. Maxx doesn't seem to care, so i expect/fear the worse if he tries to
over-oversimplify VLIW. like a x86, this can become a nightmare to program,=
not even thinking of "efficiently".

As for the FC0, i guess that you understand the concept of "scoreboard= ing",
if it's dynamically "scheduled", it's not a major pain to impleme= nt,
there's  no out of order decoding like in the PPC or the PII, so don't= worry,
this "old trick" (40 years old) ain't gonna hold us back ;-)


> [...]
> > The idea behind SMT is that the CPU core "shares" the E= xecution Units
> > between the different threads "on the fly" (dynamically= ).
> And that's the problem with the SMT approach:  It makes a more > advanced control logic necessary and increases complexity of the
> core just as all the other dynamic stuff potentially does:
> beyond beleive ;=B0>

hum, there's some points that you miss. mainly : utilization vs die space.<= BR> let's take a virtual CPU, with an execution unit utilization of 50%
(that is : at any time, roughly 50% of the units (add/sub, load/store,
whatever) are in use (and vice versa). that's a statically scheduled
RISC (or a dynamic x86 ;-P).

now you have two solutions to run two similar threads : either duplicate the original core (utilization =3D 50%, die space =3D x2) or you go SMT
(utilization=3D90%, die space =3D x1.4). compare the die space vs utilisati= on :
SMT may take a bit longer to run the same program but there is no
idle unit, at a marginal cost. duplicated cores still use only 50%
of each unit and take twice more space.

now, the killing argument is that it requires a marginal modification
of the original core, and requires almost no programming change
(OS kernel). OK dynamically rescheduling is a bit more complex
but the principle is simple and yields better results per mm2 of
silicon. in the near future, all the ALPHAs will be using this technique, without recompilation of the applications.

> I think a statically interleaved multi-threaded design is the way to g= o:
> It looks like a multi-core processor with a shared cache and the
> complexity is in the individual units and the register-file to units > busses*.  4-way multi-threaded should be feasible, 8-way could > probably be accomplished with some tweaks.
>
> * and the cache design has to be pretty good !

i don't see exactly what you mean. can you be more precise ?

> > the instruction set should need no modification, you have to make= some HW
> > modifications but that does not influence the instructions themse= lves.
> It depends: while a static in-order-issue RISC core would allow
> dynamically resceduling of instructions (and units) it would
> really be a complexity-nightmare, so that approach doesn't favour
> SMT but leads to "only" static MT.

??? can you explain ?



Kai Wetzel wrote:
> Nicolas Boulay wrote:
> > Albert Abramson wrote:
> > > All I've been suggesting lately was building a pure VLIW cor= e with no
> > > decode -- only execution resources -- so that whatever techn= ology we
> > > chose to use would allow us to fit the maximum number of cor= es on one
> > > die, whatever material and whatever transistors we'd be usin= g.
> > That the idea of lot of people, but how maintain a binary compati= bility
> > with futur core with pure VLIW (without recompiling)?
> Hmm, I think we gain a lot if we decouple binary compatibility from > the instruction set used by the CPU:
>
> 1. secondary isa describes a machine language for the FCPU arch.
for example ?
> 2. primary instruction set specifies the machine language of a
>    specific implementation fed into the core.
>
> The secondary ISA including hints for parallellism, etc. and could be = turned
> into primary instructions:
> 1. on load/install/... or on demand
> 2. re-hinted if the FCPU implementaion provides (optional) statistical= services.
do you mean "standard instructions" and "machine specific in= structions" ?
we have plenty of free opcodes for the F-CPU project, if that's what you're=
saying.

> Decoupling ISA from primary instruction set enables us to innovate
> within a significantly increased range at either level, but most impor= tantly
> regarding specific core design (number of units, issue-width, etc.) there i'm not sure to understand what you mean.

> Tying the ISA to the core is not a good idea: Either we limit ourselve= s
> severely or the converter logic becomes increasingly complex (see 80x8= 6 :=B0)
that's true, but look at CPU families like SPARC or MIPS : they don't suffe= r
all the pain that x86 does. except few things, like the delayed branch, the=
coprocessors or the mul/div instructions. Anyway, that's not so severe
for an almost 20y old family. we see that the ALPHA reuses most of MIPS' features (except those that were complex like mentionned above).

then, if the instruction set is carefully designed, there's less worries to have. the current ISA should be ok for at least 10 or 20 years.

> [...]

> Regards,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02032 for ; Sun, 2 Jul 2000 02:38:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 02:38:54 +0200 (MEST) Received: (qmail 6413 invoked by uid 0); 1 Jul 2000 15:05:57 -0000 Received: from mq.egroups.com (208.50.144.79) by mx02.gmx.net with SMTP; 1 Jul 2000 15:05:57 -0000 X-eGroups-Return: sentto-1101623-404-962463929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 01 Jul 2000 15:05:43 -0000 Received: (qmail 3897 invoked from network); 1 Jul 2000 15:05:29 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 1 Jul 2000 15:05:29 -0000 Received: from unknown (HELO localhost.localdomain) (200.210.69.43) by mta1 with SMTP; 1 Jul 2000 15:05:26 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with SMTP id MAA03314 for ; Sat, 1 Jul 2000 12:05:18 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> In-Reply-To: <395E056A.EF838114@f-cpu.org> Message-Id: <00070112045200.00429@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 1 Jul 2000 12:02:57 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 73fbc06ad23384b5a392b5ffb5d4c81e Status: R X-Status: N Yann Guidon wrote:
> go look at IBM's and other's project for VLIWs : they come with a
> complex and sophisticated compiler/HW codesign.

Good idea. See:

       http://www.research.ibm.com/vliw/pubs.html

-- Jecel
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00321 for ; Sun, 2 Jul 2000 18:00:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 18:00:48 +0200 (MEST) Received: (qmail 27721 invoked by uid 0); 2 Jul 2000 02:11:01 -0000 Received: from fk.egroups.com (208.50.144.73) by mx02.gmx.net with SMTP; 2 Jul 2000 02:11:01 -0000 X-eGroups-Return: sentto-1101623-405-962503859-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 02 Jul 2000 02:11:00 -0000 Received: (qmail 31377 invoked from network); 2 Jul 2000 02:10:58 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 2 Jul 2000 02:10:58 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 2 Jul 2000 02:10:58 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000702021058.WBEJ6302.mail.rdc1.wa.home.com@nventure.com> for ; Sat, 1 Jul 2000 19:10:58 -0700 Message-ID: <395EA4B1.ADB07DEF@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 01 Jul 2000 19:11:13 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors; xRISC again Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6c288b1ae954a9677fd7e6fc18f0c015 Status: R X-Status: N

Yann Guidon wrote:

> hi,
>
> just a criticism, to cool Maxx's optimism :
>
> Kai Wetzel wrote:
> > Albert Abramson wrote:
> > > Scalability is done, then, not by widening the data paths wi= th new
> > > instructions, but by adding more cores, which would be almos= t all
> > > hardware.
> >
> > Good.
>
> this kind of organisation looks very fine, until you want to program i= t.
> this fits special needs, like signal processing (some DSP use this
> organisation) but when it comes to run "real-world" spreadsh= eet or,
> say, tetris, from a C source, that's a different problem.
>
> what i say is : don't forget Amdahl's laws. don't forget that the
> maximum overal ILP that can be extracted from a C source is 3 instruct= ions
> per cycle on an ideal case (no cache miss, no misprediction, infinite<= BR> > registers, and most of all : zero pipeline stage). i don't trust/belie= ve in
> compilers, too.
>
> this means that you've got to prove that you can make a C compiler
> that exploits 100% of your architecture for a wide range of common app= lications.

Amdahl never said 100%.  Adding another execution unit on a uP has cos= ts and benefits.
The fact that you can sometimes issue another instruction to that unit is g= ood, but
often at the cost of a lower clock rate and yield.  The same is true f= or adding a lot of
dynamic reordering capability.  If it speeds things up in the end, do = it.  If not,
don't.

You can always get one instruction per cycle in the absence of exceptions a= nd cache
misses.  Good optimization usually helps to get bunches of several ins= tructions at a
time, though you still have many cycles where only one instruction can issu= e.

MIPS was originally a kind of one-at-a-time VLIW.  Microprocessor with= out Interlocking
Pipelines forced the compiler to generate pipeline stalls, which gave their= original
processor a good boost in the clock rate.  However, to maintain code c= ompatability with
wider implementations (and keep code size down), the designers chose to dum= p this
feature, forcing the hardware to generate stalls at run time, a slight spee= d
disadvantage.

VLIW just takes the other approach.  For multiple issue (VLIW has seen= much success in
commercial applications like PS2 where 2-issue is prefered), obviously more= software
interlocks must be generated, inserting nops into optimized code to keep th= e hardware
simple.

There is another approach which has drawn a great deal of interest, and I'v= e gotten
several e-mails asking about the topic of xRISC.  It was never fully e= xplained, but it
offers all of the advantages of an in-order RISC design (code density, scal= ability,
compatability) while reducing the volume of bookkeepping logic that holds d= own
performance on wide-issue processors. eXplicit RISC is a form of shallow de= code RISC
that enables six- and eight-issue designs that don't suffer the huge clock = penalties
these processors normally take.

For any running instruction, a compiler generated Data Dependency Template = (ala IA-64,
but without all of those other frills) specifies how many of the subsequent= instruction
words may issue in that cycle.  Presently, xRISC still has to figure o= ut if there is
enough hardware for the entire package, but that can be changed, too, at th= is point.

The problems with scheduling lots of instructions grows quadratically. = ; That is to say,
what did nothing to impede the clock rate at two-issue is already a signifi= cant
bottleneck at four-issue and getting worse.

>
> don't forget that RISC can also mean "Relegate the Important Stuf= f to the
> Compiler". You seem to relegate too much, based on your architect= ural
> estimations, but you don't seem to have a clue about the compiler behi= nd.
> On a RISC machine, the compiler must be designed along with the microa= rchitecture
> (that's why i also (try to) run the GNL project). If you have no clue = about how Bison
> and Flex work, i'd advice you to read some of the litterature (for exa= mple
> the "Dragon Book") and try to make a toy compiler yourself, = so you see the
> gap between the ideal world and the reality.
>

Intel is assuming that compilers are going to get a LOT smarter in the futu= re. With
little experience in multithreading on a single die, they chose ILP, "= the Holy Grail of
computing." Yeah right.  We've seen what it takes to get more the= n four instructions per
cycle on the SPECmarks; ILP is more like the Shroud.  It's been around= forever, and
everyone figures it for a scam.  The question is, can you save time wi= th ILP.

In fact, there are studies that show 10-16 IPC could be achieved on SPECmar= ks with a
sufficiently large program window.  Since Intel bases performance almo= st entirely on
these benchmarks, it is targetting IA-64 processors toward having compilers= look over
this large window (hundreds or even thousands of instructions), using predi= cation to
break through enormous block boundaries and statically tie lots of work int= o one program
counter.

Once you extend your window that far, though, message passing is no longer = such a big
deal.  One thread sends a parameter out to the cache, and another thre= ad just picks it
up and goes with it.  It's a two cycle penalty, but it's usually faste= r just to read an
answer from memory the cache than it is to wait and calculate when you're s= ure you'll
need it.  I was working on a register scheme for xRISC that banks two = register files and
allows one to write to the other seemlessly, so you can always pass a param= eter quickly
to another running thread.  Asynchronously running threads can usually= do okay on their
own, especially when you consider that different cores can run on their own= clock
signals, so you have face as much of the slowdown you would get trying to r= un 20 million
transistors off of one thread, and therefore, one clock tree.

On the other hand, statically tying so many threads together forces contagi= ous stalls
which inhibit performance.  Itanium is very suseptible to stalls that = processors like
the 21264 can get around almost easily.

If it were up to me, though, I would just break a chip like Itanium into tw= o or four,
smaller processors, each running their own thread.

>
> go look at IBM's and other's project for VLIWs : they come with a
> complex and sophisticated compiler/HW codesign.
>

I have.  It shows some of the limitations of trying to get a decent CP= I.  Avg 4.15 was
the best they could get with a VLIW arch. that looked a lot like IA-64.&nbs= p; If you want
something better than that, you'll have to get much smarter run time analys= is, which
requires either software reoptimization or much smarter hardware or both.&n= bsp; ILP is good
for 2-3 IPC avg.  It's not worth the compromises you have to make to g= et beyond that.
Once the window gets that large, why not just spin off another thread?

>
> Kai Wetzel wrote:
> >
> > Yann Guidon wrote:
> > >
> > > Albert Abramson wrote:
> > [...]n a CRAY 1.
>
> As well as the RISC concept becomes more fuzzy, VLIW becomes less
> and less precise. more people work on it now and the general sense
> of the term is blurred. yes, the idea was to have a very large
> statically scheduled instruction word, but THAT WAS IN 1980 !
> CPU cores have evolved and RISC succeeded to follow this trend,
> while VLIW is still very complex in practice, both in HW and SW.
> OTOH some microcoded machines like Richard's ERIN can claim to have > "very long instruction words" and that's a different (false)= problem.
>

The question, then, is how much hardware vs software scheduling do we inten= d to use?  If
you want the minimum of clock penalty, the software gets to do all of the s= cheduling.
Since compilers aren't that bright, and since JIT optimization technology i= sn't that
great yet, it may be better just to focus on a virtual machine ISA.  I= nstructions might
even be predicated, and loops could be better described, but the client sid= e could
simply be given that ISA with all of its compiler generated hints ahead of = time, and
that would free designers work on the whole platform.

x86, for example, has been used as a starting point, but its small register= set and
other characteristics make it difficult to properly reinterpret and reoptim= ize, whether
that task has been handled in software or hardware or both.

>
> someone (i don't know his name, a great musician anyway) said :
> "before you play two notes, learn to play one note.
>  and before you play a single note, ask yourself why you have to = play it."
>

I've already played one.  I've gotten into pipelining, and that starts= to make things
difficult, of course.  However, a Very Long Instruction Word treats ea= ch word as one.
While there are lots of function fields and register numbers to read, VLIW = is easier to
implement by hardware designers than most RISC processors, especially if it= is small and
fixed.  A single, two-issue VLIW processor can run as fast as a four w= ay RISC chip
because of its higher clock, smaller penalties, and greater die area left f= or caching.
Predication and elaborate compiler optimizations are not necessary in order= to get a low
CPI.  You just abandon the idea in favor of smaller cores with faster = clock rates.

>
> same goes for the instructions : VLIW is fine, but let's start with > one instruction first : that's 70% of the work. there are many ways to= extend
> this, but there's no point executing even 2 instructions if you can't = execute
> 1 instruction correctly, right ? there are several problems that can a= rise,
> like exceptions or context switches, that can become seriously difficu= lt.
> Maxx doesn't seem to care, so i expect/fear the worse if he tries to > over-oversimplify VLIW. like a x86, this can become a nightmare to pro= gram,
> not even thinking of "efficiently".
>

Aaargh!  It's pipelining that's hard!  Are you ignoring that part= ?  You have to convince
the program that it is running one instruction at a time.  That, by it= self, can easily
turn into the critical path.  Exception detection takes just a wee lon= ger than the
actual integer operation.  To keep data hazard latency to a minimum, w= e might even go so
far as to use a two stage execution pipeline, where most operations deliver= results
after one cycle, but results aren't written back to registers until two.&nb= sp; So the results
of instructions from the two previous cycles are kept in the feedforward, f= orcing
renaming.  Or, with VLIW, you can use architecturally specific renames= .  Well, that's
off topic.

My point is, a simple RISC isn't the problem.  If that's all you want,= you can tweak the
example in P&H until you get something like f-cpu.  When you try t= o build... aaargh,
again!  Dangit, if I'da known this thread would go on this long, I'da = just designed the
whole thing myself as it is.

>
> As for the FC0, i guess that you understand the concept of "score= boarding",
> if it's dynamically "scheduled", it's not a major pain to im= plement,
> there's  no out of order decoding like in the PPC or the PII, so = don't worry,
> this "old trick" (40 years old) ain't gonna hold us back ;-)=
>

First, look at the instruction format to identify where sources and destina= tions are.
Then, compare each source with each previous destination.  From that i= nformation, you'll
find that some instructions are independent of the first, but dependent on = subsequent
instructions. The number of comparisons you have to perform grow quadratica= lly with each
doubling of instruction issue. You then have to AND the results of all of t= hose checks
for each instruction to see of there is ANY dependency.  On an in-orde= r processor, you
also have to AND that with any dependencies that may exist on any previous = instructions
that won't issue.

THEN you can access registers (unless you want to try to access them all au= tomatically)
OR the feedforward which has the latest results for instructions from the l= ast issue
group.  But wait, there's more.  Once you try to access many regi= ster at once, you have
to add many ports.  A six-ported register file is slower than one with= only two reads
and one write port.  Many modern processors are using eight read and f= our write in
addition to using lots of renames.  There's no doubt that negatively i= mpacts the clock
rate, but those additional resources tend to be hard to make use of

>
> > [...]
> > > The idea behind SMT is that the CPU core "shares" = the Execution Units
> > > between the different threads "on the fly" (dynami= cally).
> > And that's the problem with the SMT approach:  It makes a mo= re
> > advanced control logic necessary and increases complexity of the<= BR> > > core just as all the other dynamic stuff potentially does:
> > beyond beleive ;=B0>
>
> hum, there's some points that you miss. mainly : utilization vs die sp= ace.
> let's take a virtual CPU, with an execution unit utilization of 50% > (that is : at any time, roughly 50% of the units (add/sub, load/store,=
> whatever) are in use (and vice versa). that's a statically scheduled > RISC (or a dynamic x86 ;-P).
>
> now you have two solutions to run two similar threads : either duplica= te
> the original core (utilization =3D 50%, die space =3D x2) or you go SM= T
> (utilization=3D90%, die space =3D x1.4). compare the die space vs util= isation :
> SMT may take a bit longer to run the same program but there is no
> idle unit, at a marginal cost. duplicated cores still use only 50%
> of each unit and take twice more space.
>

Well, that's certainly one way of doing it.  VLIW can't run that way, = of course.  If, in
any given cycle, you're only able to schedule two instructions from one thr= ead, the next
one in the other thread could just be another load-store -- the unit may al= ready be in
use.  Actual utilization, though, is pretty good.  You can almost= always get one more
instruction in their with each running thread.

Problem, most CPU time is spent waiting for memory to show up.  Large = OOO windows let
you speculatively issue instructions in spite of a miss, looking for that n= ext
load-store that might also generate a miss.  However, the core itself = isn't any faster
in the absence of cache misses than a simpler core with a higher clock.

An alternate method is to run one thread at a time on each running core.&nb= sp; On a cache
miss, rather than stalling the processor, you branch to an alternate thread= , which runs
until it, too, missses the cache.  Tera's machines run this way, and t= hey run lots and
lots of threads at one time.

Using this scheme, a processor's only responsibility is getting to the next= miss just as
quickly as possible in order to give up control to the next thread.

xRISC runs only two at a time, so there are only two sets of register files= .  Any
instruction is able to write to either its own or the other register file.<= BR>
>
> now, the killing argument is that it requires a marginal modification<= BR> > of the original core, and requires almost no programming change
> (OS kernel). OK dynamically rescheduling is a bit more complex
> but the principle is simple and yields better results per mm2 of
> silicon. in the near future, all the ALPHAs will be using this techniq= ue,
> without recompilation of the applications.
>
> > I think a statically interleaved multi-threaded design is the way= to go:
> > It looks like a multi-core processor with a shared cache and the<= BR> > > complexity is in the individual units and the register-file to un= its
> > busses*.  4-way multi-threaded should be feasible, 8-way cou= ld
> > probably be accomplished with some tweaks.
> >
> > * and the cache design has to be pretty good !
>

Right on!  However, you can still run multiple cores, each one moving = >from thread to
thread.  With the same 10 million transistors as the leading brand, yo= u get four cores
running eight or more threads with much faster message passing, and therefo= re better
utilization of resources.

> [...]

>
> > Regards,
> > kai
> WHYGEE

--Maxx

A:What kind of movie do we want to see tonight, bush or gore?

B:Is there even a difference?
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00324 for ; Sun, 2 Jul 2000 18:00:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 02 Jul 2000 18:00:51 +0200 (MEST) Received: (qmail 19786 invoked by uid 0); 2 Jul 2000 04:16:28 -0000 Received: from hm.egroups.com (208.50.144.92) by mx02.gmx.net with SMTP; 2 Jul 2000 04:16:28 -0000 X-eGroups-Return: sentto-1101623-407-962511379-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 02 Jul 2000 04:16:21 -0000 Received: (qmail 16555 invoked from network); 2 Jul 2000 04:16:18 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 2 Jul 2000 04:16:18 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 2 Jul 2000 04:16:17 -0000 Received: from f-cpu.org (Paris-Raspail-2-218.club-internet.fr [195.36.192.218]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA19876 for ; Sun, 2 Jul 2000 06:16:14 +0200 (MET DST) Message-ID: <395EC1DF.16A391F3@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> <395EA4B1.ADB07DEF@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 02 Jul 2000 06:15:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors; xRISC again Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 055232c731dc81f231efb784d8b3561c Status: R X-Status: N hi !

Albert Abramson wrote:
<snip>

your project, which i would call "cameleon" because it
is never what it seems, looks pretty interesting and i would
be glad to see a working architectural simulation of your idea.
what can i say more ? i have no time left to fully answer your latest
message. gotta sleep (at last).
have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA27599 for ; Mon, 3 Jul 2000 02:56:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 03 Jul 2000 02:56:12 +0200 (MEST) Received: (qmail 3641 invoked by uid 0); 2 Jul 2000 16:25:15 -0000 Received: from mo.egroups.com (208.50.144.78) by mx02.gmx.net with SMTP; 2 Jul 2000 16:25:15 -0000 X-eGroups-Return: sentto-1101623-408-962555112-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 02 Jul 2000 16:25:13 -0000 Received: (qmail 19965 invoked from network); 2 Jul 2000 16:25:11 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 2 Jul 2000 16:25:11 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 2 Jul 2000 16:25:11 -0000 Received: from welfen-netz.com [193.194.149.138] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Sun, 02 Jul 2000 18:25:04 +0200 Sender: kai@pop.gmx.net Message-ID: <395FE269.15EB8FA7@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 03 Jul 2000 02:46:33 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d7878def93c996c0b99becb11b7ac823 Status: R X-Status: N Yann Guidon wrote:
[...]
> this means that you've got to prove that you can make a C compiler
> that exploits 100% of your architecture for a wide range of common app= lications.
> don't forget that RISC can also mean "Relegate the Important Stuf= f to the
> Compiler". You seem to relegate too much, based on your architect= ural
> estimations, but you don't seem to have a clue about the compiler behi= nd.

Regarding compiler optimization and other interesting stuff there is
a page put together by the "IMPACT" research group:
http://www.crhc.uiuc.edu/IMPAC= T/
They got several cool papers online as well as some software.

> On a RISC machine, the compiler must be designed along with the microa= rchitecture
> (that's why i also (try to) run the GNL project). If you have no clue = about how Bison
> and Flex work, i'd advice you to read some of the litterature (for exa= mple
> the "Dragon Book") and try to make a toy compiler yourself, = so you see the
> gap between the ideal world and the reality.

Fortunately the language front-end is not our main concern.  In even an existing machine code (such as MIPS) could be taken as input for the
optimization stage, in any way, an existing C language front-end would
be used unless the flexibility is going to be passed on to the
programmer in part, e.g. decide what loops are there not to
be unrolled (to save space) and which should be taken into consideration for optimitzation, etc.

> go look at IBM's and other's project for VLIWs : they come with a
> complex and sophisticated compiler/HW codesign.

Makes sense to me...

[...]
> > > >  If we need to expand the
> > > > microarchitecture, we ought to provide a programming mo= del that permits
> > > > the description of a virtual machine with a hazy kind o= f reg-mem-message
> > > > passing model that is simulated by either some advanced= hardware or some
> > > > dynamic optimization software.
> > > that's getting pretty complex for a "simple device"= ;...
> > Well, the complexity is not in the _device_, I think that's the w= hole point :O)
> and you end up in the Transmeta case, where they sell "wind"= ...
> you believe that you win months in the HW design phase, while in fact = you can't
> run anything because the reinterpretation SW takes ages to design.

Well, making it "close to optimal" will be an on-going effort. Mere executaion is always possible in a step-by-step manner using nops ;=B0= )

[...]
> > > > Super high performance processors in the future will de= pend on getting
> > > > around some of the limitations that we are just recogni= zing today.
> > > is SMT some part of the answer ? i guess, in part.
> > >
> > > if you want to make a VLIW FC1, go ahead and program/draw so= me
> > > prototypes. i don't like to discuss like that, without tangi= ble
> > > facts (other than articles in the press).
> >
> > Well, I'm not well-informed on th concept of VLIW but making a de= sign
> > which _requires_ dynamic resceduling in hardware sounds like
> > a complication of the CPU which could really hold us back due
> > to our limited design capacity, I think.  Whether _VLIW_ is = the right answer,
> > I don't know.
>
> someone (i don't know his name, a great musician anyway) said :
> "before you play two notes, learn to play one note.
>  and before you play a single note, ask yourself why you have to = play it."
>
> same goes for the instructions : VLIW is fine, but let's start with > one instruction first : that's 70% of the work. there are many ways to= extend
> this, but there's no point executing even 2 instructions if you can't = execute
> 1 instruction correctly, right ? there are several problems that can a= rise,
> like exceptions or context switches, that can become seriously difficu= lt.

Of course there are many problems that can arise - I fail to see
why most of these concerns are a result of static-issue/VLIW.
In a static decoding approach most data hazard can be treated
with one of the following: a) Undefine them up-front or b) treat
them as illegal.  In the most radical approach b) would only be used in cases where a) is technically impossible and the result would
be "undefined" :=B0>

[...]
> > > The idea behind SMT is that the CPU core "shares" = the Execution Units
> > > between the different threads "on the fly" (dynami= cally).
> > And that's the problem with the SMT approach:  It makes a mo= re
> > advanced control logic necessary and increases complexity of the<= BR> > > core just as all the other dynamic stuff potentially does:
> > beyond beleive ;=B0>
>
> hum, there's some points that you miss. mainly : utilization vs die sp= ace.
> let's take a virtual CPU, with an execution unit utilization of 50% > (that is : at any time, roughly 50% of the units (add/sub, load/store,=
> whatever) are in use (and vice versa).

Going multi-core is the way to go _after_ other means of speeding
things up have been exploited to a high degree.  I thing multi-core is a technique for the flag-ship or end-of-line processor, right before
adding huge amounts of (L1) cache, or as a means to increase power
if design effort is to be kept small.

I'm only saying that the way SMT is described in the paper that
was pointed out some days ago (increasing ILP by mixing multiple
threads, sort of) will not only complicate decoding/issue but
is also extremely hard if not even impossible to mix with some other
approaches presented here, including Maxx's VLIW design or the similar
ideas I'm trying to get across (and so far failed to explain well).

> that's a statically scheduled RISC (or a dynamic x86 ;-P).

=3DO)

[...]
> > I think a statically interleaved multi-threaded design is the way= to go:
> > It looks like a multi-core processor with a shared cache and the<= BR> > > complexity is in the individual units and the register-file to un= its
> > busses*.  4-way multi-threaded should be feasible, 8-way cou= ld
> > probably be accomplished with some tweaks.
> >
> > * and the cache design has to be pretty good !
>
> i don't see exactly what you mean. can you be more precise ?
>
> > > the instruction set should need no modification, you have to= make some HW
> > > modifications but that does not influence the instructions t= hemselves.
> > It depends: while a static in-order-issue RISC core would allow > > dynamically resceduling of instructions (and units) it would
> > really be a complexity-nightmare, so that approach doesn't favour=
> > SMT but leads to "only" static MT.
>
> ??? can you explain ?

We have 3 orthogonal proposals meant to allow running multiple threads
inside one core:

1) "SMT" thread-mixing to use more FUs at the same time then the = ILP of a single
   thread would allow.  (Please correct me if I got this one= wrong).

2) Having "idle" threads to take over if the sister thread stalls= due to
   cache-miss or memory-latency.

3) multi-threaded FUs as described by AlphaRISC/AlphaGhost (hope I got it right):
  
   The basic idea is that a FU, such as an adder that could start= one add
   in a cycle could start several adds with a minimal offset (gat= e or select
   delay) which will as a result propagate through the adder in a= serial manner.

   This leads to a design where, say, four, threads are running &= quot;in parallel",
   given equal share of resources, or in fact, given the same FU = access they
could
   expect of a single-threaded design.

   For many FUs size increases very little, an that's the reason = for taking this
   road.

Some notes:
- 1, 2, 3 can be combined.
- in any of the above register files are duplicated
- 1 doesn't go well with VLIW or similar. 

> Kai Wetzel wrote:
> > Nicolas Boulay wrote:
> > > Albert Abramson wrote:
> > > > All I've been suggesting lately was building a pure VLI= W core with no
> > > > decode -- only execution resources -- so that whatever = technology we
> > > > chose to use would allow us to fit the maximum number o= f cores on one
> > > > die, whatever material and whatever transistors we'd be= using.
> > > That the idea of lot of people, but how maintain a binary co= mpatibility
> > > with futur core with pure VLIW (without recompiling)?
> > Hmm, I think we gain a lot if we decouple binary compatibility fr= om
> > the instruction set used by the CPU:
> >
> > 1. secondary isa describes a machine language for the FCPU arch.<= BR> > for example ?
> > 2. primary instruction set specifies the machine language of a > >    specific implementation fed into the core.
> >
> > The secondary ISA including hints for parallellism, etc. and coul= d be turned
> > into primary instructions:
> > 1. on load/install/... or on demand
> > 2. re-hinted if the FCPU implementaion provides (optional) statis= tical services.
> do you mean "standard instructions" and "machine specif= ic instructions" ?
> we have plenty of free opcodes for the F-CPU project, if that's what y= ou're
> saying.
>
> > Decoupling ISA from primary instruction set enables us to innovat= e
> > within a significantly increased range at either level, but most = importantly
> > regarding specific core design (number of units, issue-width, etc= .)
> there i'm not sure to understand what you mean.
[...]

I think it's been describe more clearly by calling the first a virtual mach= ine
ISA while the second is the instructions optimized for a specific core.

Say, for example, we got the following instructions:

add r1, r2, r3; result is put in 'r3'
mul r3, r4, r5; 'r3' is used as input

In the abstract ISA ("secondary") this sequence includes a data depency.  If it was meant to be interpreted directly, one could
call it a data hazard.

In the machine-dependend ISA ("primary") I propose, the above seq= uence
does not contain a data dependency at all.  Quite intuitively,
the thing that is added to r4 in the second instruction may
be anything - it will certainly not be described correctly as the
result of the first instruction, because the first instruction
will only write-back way after the second instruction reads from r3.

The machine-dependend instructions depend on the actual core, such as
4/6/8-issue, pipeline depth, number of adder units, etc.
The abstract ISA describes the outcome of the operation and forms
an overall framework for what kind of core efficiently maps these
instructions.

Binaries are distributed using the abstract ISA and converted
(i.e. optimized for a specific core) when needed.

Regards,
kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA27614 for ; Mon, 3 Jul 2000 02:56:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 03 Jul 2000 02:56:16 +0200 (MEST) Received: (qmail 28636 invoked by uid 0); 2 Jul 2000 17:35:39 -0000 Received: from hm.egroups.com (208.50.144.92) by mx0.gmx.net with SMTP; 2 Jul 2000 17:35:39 -0000 X-eGroups-Return: sentto-1101623-409-962559294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 02 Jul 2000 17:35:28 -0000 Received: (qmail 21584 invoked from network); 2 Jul 2000 17:34:54 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 2 Jul 2000 17:34:54 -0000 Received: from unknown (HELO mail.laplata.ne.jp) (202.217.56.192) by mta1 with SMTP; 2 Jul 2000 17:34:52 -0000 Received: from 195.17.112.19 (max1-40.kansascity.corecomm.net [209.81.129.168]) by mail.laplata.ne.jp (8.9.3/3.7W) with SMTP id CAA17701; Mon, 3 Jul 2000 02:07:39 +0900 Message-ID: <00004c530b36$00002cd6$00002a77@193.128.179.65> To: X-Priority: 3 X-MSMail-Priority: Normal Errors-To: 69chevelle@hongkong.com X-eGroups-From: investwisely@hongkong.com From: admin@notodrugs.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 02 Jul 2000 12:36:52 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Take advantage of high gasoline prices 10871 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 45bda67c7a8c8c9e1e633facf8a8a904 Status: R X-Status: N Current Market Information. 
New strategy could realize up to 40% or greater returns.

Free video
Free "How to" manual for successfully trading in the oil marketplace
Free trade to help you get started
Find out where today's profits are
Learn how to take advantage of high gasoline prices!

Act Now -- click below for complete information.


http://204.1.122.218/







To be removed:
mailto:remove@joesusedpc.com











Current Market Information. 
New strategy could realize up to 40% or greater returns.

Free video
Free "How to" manual for successfully trading in the oil marketplace
Free trade to help you get started
Find out where today's profits are
Learn how to take advantage of high gasoline prices!
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00300 for ; Mon, 3 Jul 2000 15:36:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 03 Jul 2000 15:36:50 +0200 (MEST) Received: (qmail 5041 invoked by uid 0); 3 Jul 2000 01:56:51 -0000 Received: from hl.egroups.com (208.50.99.197) by mx02.gmx.net with SMTP; 3 Jul 2000 01:56:51 -0000 X-eGroups-Return: sentto-1101623-410-962589403-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 03 Jul 2000 01:56:50 -0000 Received: (qmail 18569 invoked from network); 3 Jul 2000 01:56:43 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Jul 2000 01:56:43 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 3 Jul 2000 01:56:42 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000703015642.DMV4628.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 2 Jul 2000 18:56:42 -0700 Message-ID: <395FF2DA.F9DC10F2@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> <395FE269.15EB8FA7@welfen-netz.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 02 Jul 2000 18:56:47 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors; virtual ISA Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f940f1fa7a3677e399a709a5e818ff6e Status: R X-Status: N I am starting to think that compiling to a virtual ISA is the best way
to go overall.

To offer the greatest degree of flexibility, though, we might design
towards a larger design.  Here is my rationale.

-By addressing a larger register file, a client side compiler can avoid
issues that hurt x86 recompilation, like looking for store-reloads.

-By specifying a loop counter, software can more easily unroll loops.

-By pointing to specialized use registers (like condition registers),
the compiler can describe Boole values that will only be treated as
Boole's, easier to predict and feedforward.

Floating point operations should specify exactly how much accuracy is
needed, so that software isn't overdoing the accuracy at the expense of
speed. Compound operations like multiply-add should be put together into
one instruction to avoid forcing the use of an additional register.

Message passing among threads should be specified as direct through
architecturally specific registers.  If the hardware chooses to use an
area of memory to represent all or part of these locations at any given
time, that area should be mapped out ahead of time.

-By using more complex branching and addressing mechanisms, hardware
designers can make use of schemes that might better serve specialized
markets, or experiment with making use of those schemes.

-By using a larger instruction set, compilers can specify which
instructions they intend to use if they are available.

-Allowing the compiler to specify smaller threads, to tie them to
conditions, and to allow one or more cores to run one or more threads
asynchronously, would help leave open as of yet unthought of design
options.

This is to say, it is easier to break down larger operations than it is
to put them back together.  The client side can almost always offer
software that breaks down compound operations into simpler, RISC-like
operations.  A real problem on x86 is identifying which operands have
been stored to memory but are still in a rename register.  This was hard
for Transmeta to deal with.  Even if the program won't use something it
just stored, even if it is just temporary, hardware and software
emulators still have to replicate the store-reload operation faithfully.

A lot of these key problems with x86 recompilers could be solved if we
allowed compilers to offer a VirtualISA binary, readable and
reoptimizable by any client side software or hardware.

That, I think, is way beyond anything tackled by this group, and would
allow hardware designers of major tech companies to make better use of
their existing designs and even allow engineers, researchers, and
students to justify weird experimentation with odd architectural ideas
using existing binaries.

The end result would look a lot like IA-64, but recompiling software for
RISC and VLIW processors could be used to break down this code without
sacraficing portability, scalabilty, flexibility, or performance.

That's the direction I think this project should take.  A standard RISC
design (or even an existing RISC chip) could be used to test both the
ISA and the transaltion concept.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00339 for ; Mon, 3 Jul 2000 15:36:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 03 Jul 2000 15:36:59 +0200 (MEST) Received: (qmail 11576 invoked by uid 0); 3 Jul 2000 11:20:58 -0000 Received: from hp.egroups.com (208.50.144.93) by mx02.gmx.net with SMTP; 3 Jul 2000 11:20:58 -0000 X-eGroups-Return: sentto-1101623-411-962623245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 03 Jul 2000 11:20:50 -0000 Received: (qmail 18435 invoked from network); 3 Jul 2000 11:20:45 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Jul 2000 11:20:45 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 3 Jul 2000 11:20:44 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e63BKhR21764 for ; Mon, 3 Jul 2000 13:20:43 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e63BKhq19910 for ; Mon, 3 Jul 2000 13:20:43 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id NAA07759 for ; Mon, 3 Jul 2000 13:20:42 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id NAA13626 for ; Mon, 3 Jul 2000 13:19:12 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <39607709.9D2B30C3@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 03 Jul 2000 13:20:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 43735df8d8d95698c4366268f61dcdbf Status: R X-Status: N Yann Guidon wrote:
>
> hi,
>
> just a criticism, to cool Maxx's optimism :
>
> Kai Wetzel wrote:
> > Albert Abramson wrote:
> > > Scalability is done, then, not by widening the data paths with new
> > > instructions, but by adding more cores, which would be almost all
> > > hardware.
> >
> > Good.
>
> this kind of organisation looks very fine, until you want to program it.
> this fits special needs, like signal processing (some DSP use this
> organisation) but when it comes to run "real-world" spreadsheet or,
> say, tetris, from a C source, that's a different problem.
>
> what i say is : don't forget Amdahl's laws. don't forget that the
> maximum overal ILP that can be extracted from a C source is 3 instructions
> per cycle on an ideal case (no cache miss, no misprediction, infinite
> registers, and most of all : zero pipeline stage). i don't trust/believe in
> compilers, too.

Like the idea to use a lot a different techniques (oooc + SMT +...) to
acheive a great power rather than use one strong idea(vliw only).

To achieve a great processor which can evoluate in the futur, we could
have some variable and some constant. For exemple, the SIMD technique
could reach 1024 bit in the futur and even more. We can say it's a
variable. The 64 register is a constant. But if an optimous ilp is 3,
why don't use this fixed number even in the futur. We can say all fcpu
are 3 ways vliw (static). But in the futur we can had ooo like register
renaming and have more issue but dynamicly.


>
> this means that you've got to prove that you can make a C compiler
> that exploits 100% of your architecture for a wide range of common applications.
> don't forget that RISC can also mean "Relegate the Important Stuff to the
> Compiler". You seem to relegate too much, based on your architectural
> estimations, but you don't seem to have a clue about the compiler behind.
> On a RISC machine, the compiler must be designed along with the microarchitecture
> (that's why i also (try to) run the GNL project). If you have no clue about how Bison
> and Flex work, i'd advice you to read some of the litterature (for example
> the "Dragon Book") and try to make a toy compiler yourself, so you see the
> gap between the ideal world and the reality.
>
> go look at IBM's and other's project for VLIWs : they come with a
> complex and sophisticated compiler/HW codesign.
>

The advantage for vliw compiling is that a program is seen in this
entire content. A processor can only see a narrow windows of the code
~100 instructions. But for vliw the analysis is static not dynamic and
it's hard to guess the futur...


For the fcpu we can had the concept of SMT. With SMT you don't made more
instructions per cycle but if a thread are waiting (cache miss, data
depencies) an other run. So this technique could avoid the ooo
techniques which are a lot die consuming (these techniques have always
the goal of a better use of the FU but could be used to achieve more
instructions per cycle). And we can make very (very) long pipeline
without having the data latencies problem like in the willamette and
having a hudge clock frequency.

The point is how compiling to manage this or is it possible to run in
the same time many different process which don't come from the same
source code ? This last option is great because making a new  SMT
compiler should be tricky. Maybe the two option could be used in the
same times (following the principle : A little from each technique).

SMT technique are useful for a very simple cpu, too and could make a
tiny core but with great efficiency.

The HW needed is something which keep trace of the runnning thread and
which one are waiting, which one could be run. Things could be a little
more complicated if we take into a count, cache friendly scheduler. We
can see, if the L1 and L2 cache aren't with a big number of way (issue
?) the number of cache miss could became annoying. But with simulation,
we can see the better technique to use for this scheduling (we can also
manage the probleme used with true jump, and switch to a different
thread to avoid branch mispredicted,...).

SMT seems to be a good answer to all the probleme see in the pipelining
technique (maybe not for exception but i don't know much about this).
Mmmmmh, i like that more and more ;-) Now, what about good compiler ?
tricky or not, that is the question.
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA08012 for ; Tue, 4 Jul 2000 03:36:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 04 Jul 2000 03:36:49 +0200 (MEST) Received: (qmail 14193 invoked by uid 0); 3 Jul 2000 22:57:38 -0000 Received: from hm.egroups.com (208.50.99.198) by mx02.gmx.net with SMTP; 3 Jul 2000 22:57:38 -0000 X-eGroups-Return: sentto-1101623-412-962665055-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 03 Jul 2000 22:57:37 -0000 Received: (qmail 16173 invoked from network); 3 Jul 2000 22:57:35 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 3 Jul 2000 22:57:35 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 3 Jul 2000 22:57:35 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000703225733.DLZ13350.mail.rdc1.wa.home.com@nventure.com> for ; Mon, 3 Jul 2000 15:57:33 -0700 Message-ID: <39611A5D.D578EA9E@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> <39607709.9D2B30C3@hl.siemens.de> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 03 Jul 2000 15:57:37 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c8906c94cb073c76ef6f23e604e38a7 Status: R X-Status: N

Nicolas Boulay wrote:

> Yann Guidon wrote:
> >
> > hi,
> >
> > just a criticism, to cool Maxx's optimism :
> >
> > Kai Wetzel wrote:
> > > Albert Abramson wrote:
> > > > Scalability is done, then, not by widening the data paths with new
> > > > instructions, but by adding more cores, which would be almost all
> > > > hardware.
> > >
> > > Good.
> >
> > this kind of organisation looks very fine, until you want to program it.
> > this fits special needs, like signal processing (some DSP use this
> > organisation) but when it comes to run "real-world" spreadsheet or,
> > say, tetris, from a C source, that's a different problem.
> >
> > what i say is : don't forget Amdahl's laws. don't forget that the
> > maximum overal ILP that can be extracted from a C source is 3 instructions
> > per cycle on an ideal case (no cache miss, no misprediction, infinite
> > registers, and most of all : zero pipeline stage). i don't trust/believe in
> > compilers, too.
>

As a matter of fact, according to recent studies, IPC's of between 10 and 45 could be
attained under ideal conditions with a large enough window.  Intel is targetting that, but
I think that MT is a better way to attain that.  Unfortunately, cache misses are the
growing bottleneck, not a lack of ILP.

>
> Like the idea to use a lot a different techniques (oooc + SMT +...) to
> acheive a great power rather than use one strong idea(vliw only).
>

Remember, though, you can get two to four times as many VLIW cores as dynamic RISC cores.
You can architect features like delayed branch without having to worry about the future
imapct of such design decisions.  You can simply design one core that works best given all
considerations.

>
> To achieve a great processor which can evoluate in the futur, we could
> have some variable and some constant. For exemple, the SIMD technique
> could reach 1024 bit in the futur and even more. We can say it's a
> variable. The 64 register is a constant. But if an optimous ilp is 3,
> why don't use this fixed number even in the futur. We can say all fcpu
> are 3 ways vliw (static). But in the futur we can had ooo like register
> renaming and have more issue but dynamicly.
>

As it just so happens, we could pack 3 VLIW instructions into a 128-bit word.  It's
interesting that you used the number three, since it is also about the best you can do
with ILP these days.  Some have suggested that the problem is getting worse, not better,
that programs are being built out of dynamic function calls, that the compiler cannot
optimize.  Many developers are not even allowing the most aggressive optimization schemes
to be used, as they make it more difficult to do patch work out in the field.  Intel is
gambling on more being done on the developer's side to gain performance, but my feeling is
that things are going the other way.

Instruction windows of 2K or larger need to be looked at to get beyond IPC's of even 4.
Hardware is not capable of that, not with unlimited renames and perfect branch
prediction.  Without branch profiling (which many developers seem unwilling to do),
compilers cannot look very far up the instruction stream with any real certainty about the
path of the programs they're running.

If any REAL optimization is going to happen on future processors, it will have to happen
on the client system, perhaps with software that reads the contents of the cache tags and
branch history tables, perhaps analyzing memory activity, running as a background thread
that takes no time from the active thread, but performing speculative loads for it at run
time, or even writing to a new area of memory, building up reoptimized code that will run
faster than what the application developer offered.

If a patch is ever offered, it modifies the original program, so the dynamic optimization
software has to start over from scratch.

>
> >
> > this means that you've got to prove that you can make a C compiler
> > that exploits 100% of your architecture for a wide range of common applications.
> > don't forget that RISC can also mean "Relegate the Important Stuff to the
> > Compiler". You seem to relegate too much, based on your architectural
> > estimations, but you don't seem to have a clue about the compiler behind.
> > On a RISC machine, the compiler must be designed along with the microarchitecture
> > (that's why i also (try to) run the GNL project). If you have no clue about how Bison
> > and Flex work, i'd advice you to read some of the litterature (for example
> > the "Dragon Book") and try to make a toy compiler yourself, so you see the
> > gap between the ideal world and the reality.
> >
> > go look at IBM's and other's project for VLIWs : they come with a
> > complex and sophisticated compiler/HW codesign.
> >
>
> The advantage for vliw compiling is that a program is seen in this
> entire content. A processor can only see a narrow windows of the code
> ~100 instructions. But for vliw the analysis is static not dynamic and
> it's hard to guess the futur...
>
>
> For the fcpu we can had the concept of SMT. With SMT you don't made more
> instructions per cycle but if a thread are waiting (cache miss, data
> depencies) an other run. So this technique could avoid the ooo
> techniques which are a lot die consuming (these techniques have always
> the goal of a better use of the FU but could be used to achieve more
> instructions per cycle). And we can make very (very) long pipeline
> without having the data latencies problem like in the willamette and
> having a hudge clock frequency.
>

Wait wait wait! BEFORE you go any further, remember what I wrote after you sent off this
email: two to four VLIW cores (each with their own thread) in the same area as one
dynamically scheduled RISC core.  That means I can have six to twelve functional units
instead of sharing four or five among running threads.  Unless one wants to issue four or
five at a time while the others twiddle their thumbs, the multiple VLIW approach works
better IF you can deal with the message passing efficiently, critical for making MT work.

Just doing IPC, recall that you can always do one and usually two from one thread in any
given cycle in the absense of a cache miss.  In the presence of a cache miss, you get
nothing unless you invested a lot of die space in dynamic reordering hardware (which also
hurts the clock by at least 30%, or at least 50% vs software scheduled).  Running separate
threads on separate cores ensures that stalls will not be contagious, that other threads
can take up the slack if any are running.  This is also true of running multiple threads
on one core, but the scheduling hardware isn't getting any work done.  For the same number
of transistors, you could lay down two-four times as many FU's.  If each is running its
own thread, we can feel relatively confident that an IPC of between 3 and 10 will be
maintained in the absence of cache misses.

>
> The point is how compiling to manage this or is it possible to run in
> the same time many different process which don't come from the same
> source code ? This last option is great because making a new  SMT
> compiler should be tricky. Maybe the two option could be used in the
> same times (following the principle : A little from each technique).
>
> SMT technique are useful for a very simple cpu, too and could make a
> tiny core but with great efficiency.
>
> The HW needed is something which keep trace of the runnning thread and
> which one are waiting, which one could be run. Things could be a little
> more complicated if we take into a count, cache friendly scheduler. We
> can see, if the L1 and L2 cache aren't with a big number of way (issue
> ?) the number of cache miss could became annoying. But with simulation,
> we can see the better technique to use for this scheduling (we can also
> manage the probleme used with true jump, and switch to a different
> thread to avoid branch mispredicted,...).
>
> SMT seems to be a good answer to all the probleme see in the pipelining
> technique (maybe not for exception but i don't know much about this).
> Mmmmmh, i like that more and more ;-) Now, what about good compiler ?
> tricky or not, that is the question.
> nicO
>

The major problem (and this one is getting worse as technology marches onward) is not
getting lots of instructions into the FU's at once, but overcoming the growing problem of
wait time from memory.  Remember also, that a 2GHz three-issue core always outperforms
1GHz six-issue processors, except that the latter can often find work to do in spite of a
cache miss if it is OOO.

That solution, though, looks less and less viable as core speeds outrun memory systems.
Here, it is preferable to switch to a different thread on the same core until the
requested value form memory comes back.  The way things are going, compilers are going to
have to find lots and lots of threads in order to keep hardware busy in spite of cache
misses.  In order for them to do that, message passing overhead has to be kept to a
minimum.  We may simply have to share a register file among many running threads.  The
question, then, is how you keep them all separate.  Each thread could address its own set
of 8 plus a globally shared eight.  A one-bit prefix would select between the two, and the
hardware would keep track of which local bank belongs to each thread.

For 64 registers in all, each core could run up to seven threads in addition to a control
thread which would have access to all 64.  This, I think, is the most efficient mechanism
for passing the results of operations between threads without complex connection networks
(as seen in Stanford's J-Machine).

To make this setup even more elegant and powerful, we might go so far as to add a four-bit
register to each general register.  As the result of each operation, we write GT, LT, EQ,
and Update as the result of comparisons between operands.  You can then make more
interesting branch and conditional operations as the result of these bits, and it makes it
easier to tell whether or not another thread has returned the results of a function.  To
see if the value in a register is updated, you just look at its update bit.  This cuts our
overhead by yet one more cycle, and the technique can be reused for other conditional
operations, while saving some registers to boot.

VLIW gives you that one time boost in performance.  It not only increases throughput, but
reduces data hazard latency as well, which OOO designs spend enormous amounts of hardware
trying to get around.  Compiler scheduled processors really are fast.  They are smaller
and easier to design.  They can be expanded in the future, in the same way that x86 and
RISC are being expanded today, by adding new instructions and finding ways to get more
work into the same instruction word.  If necessary, we could take legacy VLIW code and use
dynamic optimization hardware or SMT and read it as RISC code, but you'll lose that one
time performance boost that you got with the software scheduled designs.  I wouldn't chose
to build a processor that way.

Recalling the VirtualISA concept, we could allow the compiler to generate the entire
program to that ISA, then offer alternate VLIW binaries for critical code.  The VirtualISA
keeps the software portable.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00427 for ; Tue, 4 Jul 2000 21:16:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 04 Jul 2000 21:16:14 +0200 (MEST) Received: (qmail 21635 invoked by uid 0); 4 Jul 2000 11:53:37 -0000 Received: from hk.egroups.com (208.50.144.91) by mx02.gmx.net with SMTP; 4 Jul 2000 11:53:37 -0000 X-eGroups-Return: sentto-1101623-413-962711496-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 04 Jul 2000 11:51:37 -0000 Received: (qmail 30016 invoked from network); 4 Jul 2000 11:51:35 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Jul 2000 11:51:35 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 4 Jul 2000 11:51:35 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000704115135.CMA642.mail.rdc1.wa.home.com@nventure.com> for ; Tue, 4 Jul 2000 04:51:35 -0700 Message-ID: <3961CFC5.52B5FDEB@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> <39607709.9D2B30C3@hl.siemens.de> <39611A5D.D578EA9E@nventure.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 04 Jul 2000 04:51:45 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors, MT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 246ee5a0605fbe920c281a63b8fb28f7 Status: R X-Status: N I forgot to leave tangible examples of code that would benefit from that
previously described scheme.  Heregoes.

//critical path through the program

while (this == TRUE)
    DLL.InefficientlyWrittenMicrosoftFunc (A, B, C);
loop...

MyCode (D, E, F);
MoreStuff...

Since we have no idea what's on the other side of that DLL, we might
want to spawn a thread right away for MyCode.  Since MyCode will
necessarily generate a number of cache misses, the compiler may want to
spawn another thread for MoreStuff.

When the DLL is taken, we give it its own register bank to work with,
writing A, B, and C to global registers, or to main memory if the DLL
expects it.  We don't know for certain if the results of MyCode or
MoreStuff will be used, but we're pretty sure, so we allocate for each a
bank of eight more local registers to run, since they won't share
parameters without missing the cache at least once on average.  That
really is the cutoff point for spawning horizontal threads, since there
is very little overhead at runtime for doing this and lots of cycles to
be saved by filling in memory stalls with useful work.

Registers G0-G7 always point to globals, and L0-L7 always point to the
thread's own local values, giving access to 16 registers for execution.

BTW, if register contention is still a problem, we can specify G0-G23 as
24 globally accessible registers, and allow threads that need more
registers to spill over a bit.  Alternately, we could split threads that
need more registers into ever more threads, giving them access to more
locations to read to and write from.

In any case, small context switches occasionally need to be performed to
make room for new threads when the old ones have grown stale, have been
proven invalid through a change in one of the parameter's they've
depended on, or conditions in a program's execution otherwise change the
thread schedule priority.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA06707 for ; Wed, 5 Jul 2000 00:48:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 00:48:18 +0200 (MEST) Received: (qmail 15832 invoked by uid 0); 4 Jul 2000 22:30:34 -0000 Received: from mr.egroups.com (208.50.144.80) by mx12.rz2.gmx.net with SMTP; 4 Jul 2000 22:30:34 -0000 X-eGroups-Return: sentto-1101623-414-962749827-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 04 Jul 2000 22:30:32 -0000 Received: (qmail 24581 invoked from network); 4 Jul 2000 22:30:27 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 4 Jul 2000 22:30:27 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 4 Jul 2000 22:30:27 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000704223023.DRM16975.mail.rdc1.wa.home.com@nventure.com> for ; Tue, 4 Jul 2000 15:30:23 -0700 Message-ID: <3962657E.E4385B6C@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395D8449.40373CD1@welfen-netz.com> <395E056A.EF838114@f-cpu.org> <39607709.9D2B30C3@hl.siemens.de> <39611A5D.D578EA9E@nventure.com> <3961CFC5.52B5FDEB@nventure.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 04 Jul 2000 15:30:25 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors, MT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fa195754ddc9f8e417a8db2b20ac5170 Status: R X-Status: N Oh yeah, something needs to be reiterated from a previous message about
multithreading processors:

1. Running multiple processors, each with their own thread.

2. Running multiple threads in tandem on one core; i.e., pulling
instructions from mulitple threads in eac cycle.

3. Use of alternate threads to take over execution in the event of a
memory stall.

I have been discussing 1 and 3, since 2 necessarily forbids software
scheduling and complicates hardware.  With 3 in particular, VLIW could
be a viable alternative to existing RISC designs.  Even the lower CPI
can be addressed by using dynamic optimization software, still
undeveloped.  Since we can better profile and examine all code at run
time, we can generate a more efficient instruction stream.

Look, so what if we haven't developed it yet.  This is the way all
computers will work one day.  That's just how code will be optimized.
Application developers are able to do less and less as time goes by, as
programs are developed by stringing together dynamic function calls and
objects.  Without extensive profiling, compilers cannot determine what
code is most critical, let alone which way branches will go.  This
prediction accuracy is key to being able to look ahead in the code.

Every other approach is a dead end.

--Maxx

Electrical engineers do it with greater frequency.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00303 for ; Wed, 5 Jul 2000 23:08:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:27 +0200 (MEST) Received: (qmail 19918 invoked by uid 0); 5 Jul 2000 00:52:16 -0000 Received: from hn.egroups.com (208.50.144.84) by mx12.rz2.gmx.net with SMTP; 5 Jul 2000 00:52:16 -0000 X-eGroups-Return: sentto-1101623-415-962758321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 05 Jul 2000 00:52:08 -0000 Received: (qmail 9744 invoked from network); 5 Jul 2000 00:52:00 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Jul 2000 00:52:00 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 5 Jul 2000 00:52:00 -0000 Received: from f-cpu.org (Aubervilliers-3-124.club-internet.fr [195.36.145.124]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA08748 for ; Wed, 5 Jul 2000 02:51:57 +0200 (MET DST) Message-ID: <39628680.3F42881B@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm References: <396140B3.99BB7BDC@f-cpu.org> <20000704164349.A83586@elvis.paf.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 05 Jul 2000 02:51:12 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: [fcpu-ger] f-cpu meeting Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8c4c035b6a4663b37578d33db62dfdd3 Status: R X-Status: N Fabian Sturm wrote:
> On Tue, Jul 04, 2000 at 03:41:07AM +0200, Yann Guidon wrote:
> > someone (Nicolas Boulay) proposed M=FCnchen before the end of Jul= y.
> > that would be cool too. i don't mind going there then to Berlin := -)
>
> Yes Munich would be nice, especially for me ;)
>
> Hmm vote?
>
> CU (somewhere in Germany) Fabian

ooops, so... what to do ?

i put this discussion on the main mailing list so more people
can take part.

In Munich, i know 3 people : you, Nicolas and a personal friend.

In Berlin, i know the CCC people who hosted me, and one of his friends.
I think that there are also other f-cpu people there but i have no
name. Could the concerned people complete this list ?

we have to hurry up, now : buying tickets and preparing the hosting
is not always easy at the last minute.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00315 for ; Wed, 5 Jul 2000 23:08:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:30 +0200 (MEST) Received: (qmail 13074 invoked by uid 0); 5 Jul 2000 06:43:26 -0000 Received: from ci.egroups.com (207.138.41.176) by mx02.gmx.net with SMTP; 5 Jul 2000 06:43:26 -0000 X-eGroups-Return: sentto-1101623-416-962779400-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 05 Jul 2000 06:43:22 -0000 Received: (qmail 23426 invoked from network); 5 Jul 2000 06:43:19 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Jul 2000 06:43:19 -0000 Received: from unknown (HELO mailout03.sul.t-online.com) (194.25.134.81) by mta1 with SMTP; 5 Jul 2000 06:43:19 -0000 Received: from fwd07.sul.t-online.com by mailout03.sul.t-online.com with smtp id 139ity-0004ie-01; Wed, 5 Jul 2000 08:43:18 +0200 Received: from (0893089296-0001@[62.158.204.11]) by fwd07.sul.t-online.com with smtp id 139itw-2BZNx3C; Wed, 5 Jul 2000 08:43:16 +0200 To: f-cpu@egroups.com References: <396140B3.99BB7BDC@f-cpu.org> <20000704164349.A83586@elvis.paf.net> <39628680.3F42881B@f-cpu.org> X-Mailer: T-Online eMail 2.3 Message-ID: <139itw-2BZNx3C@fwd07.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net X-eGroups-From: Thilo.Reichelt@t-online.de (Reichelt) From: Thilo.Reichelt@t-online.de MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 5 Jul 2000 08:43:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: [fcpu-ger] f-cpu meeting Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 52290a01a56863ced3f91cdb59b988c4 Status: R X-Status: N Yann Guidon schrieb:
> Fabian Sturm wrote:
> > On Tue, Jul 04, 2000 at 03:41:07AM +0200, Yann Guidon wrote:
> > > someone (Nicolas Boulay) proposed M=FCnchen before the end o= f July.
> > > that would be cool too. i don't mind going there then to Ber= lin :-)
> >
> > Yes Munich would be nice, especially for me ;)

Same for me.

> In Munich, i know 3 people : you, Nicolas and a personal friend.

> In Berlin, i know the CCC people who hosted me, and one of his friends= .
> I think that there are also other f-cpu people there but i have no
> name. Could the concerned people complete this list ?

Either Munich or Berlin --- is there a chance to found the F-CPU Verein on this occasion ? (I think of the "seven people in a room" probl= em)

> we have to hurry up, now : buying tickets and preparing the hosting > is not always easy at the last minute.
>
> WHYGEE

Thilo Reichelt
thilo.reichelt@t-online.de
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00333 for ; Wed, 5 Jul 2000 23:08:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:33 +0200 (MEST) Received: (qmail 27708 invoked by uid 0); 5 Jul 2000 10:57:10 -0000 Received: from hh.egroups.com (208.50.144.88) by mx06.rz2.gmx.net with SMTP; 5 Jul 2000 10:57:10 -0000 X-eGroups-Return: sentto-1101623-417-962794620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 05 Jul 2000 10:57:00 -0000 Received: (qmail 26194 invoked from network); 5 Jul 2000 10:56:58 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 5 Jul 2000 10:56:58 -0000 Received: from unknown (HELO as104.tel.hr) (205.219.255.36) by mta1 with SMTP; 5 Jul 2000 10:56:58 -0000 Received: from AOP2 (ad2-m51.tel.hr [195.29.225.51]) by as104.tel.hr (0.0.0/0.0.0) with SMTP id MAA226495 for ; Wed, 5 Jul 2000 12:56:56 +0200 (MEST) Message-ID: <002c01bfe670$f173ffa0$c90110ac@AOP2> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 From: "kordun" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 5 Jul 2000 12:55:39 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5fcd115fd6f6ba82b155499c5cd0939 Status: R X-Status: N UNSUBSCRIBE
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00345 for ; Wed, 5 Jul 2000 23:08:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:35 +0200 (MEST) Received: (qmail 22356 invoked by uid 0); 5 Jul 2000 12:51:51 -0000 Received: from mu.egroups.com (207.138.41.151) by mx02.gmx.net with SMTP; 5 Jul 2000 12:51:51 -0000 X-eGroups-Return: sentto-1101623-418-962801419-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 05 Jul 2000 13:50:27 -0000 Received: (qmail 7674 invoked from network); 5 Jul 2000 12:50:11 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Jul 2000 12:50:11 -0000 Received: from unknown (HELO bjsmtp1.163.net) (202.108.255.250) by mta1 with SMTP; 5 Jul 2000 12:50:09 -0000 Received: by bjsmtp1.163.net (Postfix, from userid 60001) id B337C1D102603; Wed, 5 Jul 2000 20:55:13 +0800 (CST) Message-Id: <39633031.15916@bjsmtp1.163.net> To: f-cpu@egroups.com X-Priority: 3 X-Originating-IP: [202.110.200.130] From: zwpkt@163.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 5 Jul 2000 20:55:13 +0800 (CST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 50eae3a568e542c8877ef9786f6db328 Status: R X-Status: N unsubscribe ------------------------www.163.net---------------------- Èç¹ûÄúÒѾ­»ñµÃÁËCNNICµÄÓÅÐãÍøվͶƱȨ£¬Çë±ð³ÙÒÉ£¬¸Ï¿ìΪ Äú×î³£·ÃÎʵÄÍøվͶÉÏһƱ¡£(www.163.net) ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html ------------------------------------------------------------------------ CLICK HERE AND START SAVING ON LONG DISTANCE BILLS TODAY! http://click.egroups.com/1/4125/1/_/3462/_/962801419/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00357 for ; Wed, 5 Jul 2000 23:08:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:38 +0200 (MEST) Received: (qmail 5459 invoked by uid 0); 5 Jul 2000 18:11:53 -0000 Received: from cj.egroups.com (208.50.144.68) by mx10.rz2.gmx.net with SMTP; 5 Jul 2000 18:11:53 -0000 X-eGroups-Return: sentto-1101623-419-962820702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 05 Jul 2000 18:11:46 -0000 Received: (qmail 9510 invoked from network); 5 Jul 2000 18:10:02 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Jul 2000 18:10:02 -0000 Received: from unknown (HELO beta) (130.149.145.48) by mta1 with SMTP; 5 Jul 2000 18:10:01 -0000 Received: (from marco@localhost) by beta (8.9.3/8.9.3) id UAA01217 for f-cpu@egroups.com; Wed, 5 Jul 2000 20:12:56 GMT (envelope-from marco) To: f-cpu@egroups.com Message-ID: <20000705201254.B1122@beta> Mail-Followup-To: f-cpu@egroups.com References: <396140B3.99BB7BDC@f-cpu.org> <20000704164349.A83586@elvis.paf.net> <39628680.3F42881B@f-cpu.org> X-Mailer: Mutt 1.0pre2i In-Reply-To: <39628680.3F42881B@f-cpu.org> From: Marco Wertejuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 5 Jul 2000 20:12:55 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: [fcpu-ger] f-cpu meeting Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d5a175d83a3aa980d4a9a0fe4a55f02a Status: R X-Status: N Hi,

| In Berlin, i know the CCC people who hosted me, and one of his friends.
| I think that there are also other f-cpu people there but i have no
| name. Could the concerned people complete this list ?

I don't know whether it's neccessary, but I'm belonging as
part to those CCC people and to those who tried to not fall
asleep during 16C3 and therefore talked to everyone ;)

No it's not that way but to make it short, yes I'm in
Berlin and of course would I try to come.

--
-Marco-
PGP Key fingerprint = 23 87 B6 63 A2 6B C8 83  18 6F BB A3 49 C1 A6 45
"What  you  really  value  is  what  you  miss,  not  what  you have."
Jorge Luis Borges
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00360 for ; Wed, 5 Jul 2000 23:08:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 05 Jul 2000 23:08:39 +0200 (MEST) Received: (qmail 27547 invoked by uid 0); 5 Jul 2000 18:16:13 -0000 Received: from fk.egroups.com (208.50.144.73) by mx02.gmx.net with SMTP; 5 Jul 2000 18:16:13 -0000 X-eGroups-Return: sentto-1101623-420-962820903-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 05 Jul 2000 18:15:13 -0000 Received: (qmail 11294 invoked from network); 5 Jul 2000 18:15:03 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Jul 2000 18:15:03 -0000 Received: from unknown (HELO beta) (130.149.145.48) by mta1 with SMTP; 5 Jul 2000 18:15:02 -0000 Received: (from marco@localhost) by beta (8.9.3/8.9.3) id UAA01272 for f-cpu@egroups.com; Wed, 5 Jul 2000 20:17:57 GMT (envelope-from marco) To: f-cpu@egroups.com Message-ID: <20000705201755.D1122@beta> Mail-Followup-To: f-cpu@egroups.com References: <396140B3.99BB7BDC@f-cpu.org> <20000704164349.A83586@elvis.paf.net> <39628680.3F42881B@f-cpu.org> <139itw-2BZNx3C@fwd07.sul.t-online.com> X-Mailer: Mutt 1.0pre2i In-Reply-To: <139itw-2BZNx3C@fwd07.sul.t-online.com> From: Marco Wertejuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 5 Jul 2000 20:17:56 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: [fcpu-ger] f-cpu meeting Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8528e42bbe41293d1999d7ee70682e1e Status: R X-Status: N Hi,

| Either Munich or Berlin --- is there a chance to found the F-CPU Verein
| on this occasion ? (I think of the "seven people in a room" problem)

this is quite a goog idea, I think it won't be a problem
to find this room in Berlin, I'll ask for those from the
CCC Berlin.


-Marco-
--
PGP Key fingerprint = 23 87 B6 63 A2 6B C8 83  18 6F BB A3 49 C1 A6 45
"What  you  really  value  is  what  you  miss,  not  what  you have."
Jorge Luis Borges
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00300 for ; Thu, 6 Jul 2000 21:41:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 06 Jul 2000 21:41:43 +0200 (MEST) Received: (qmail 10081 invoked by uid 0); 6 Jul 2000 00:18:51 -0000 Received: from mu.egroups.com (207.138.41.151) by mx02.gmx.net with SMTP; 6 Jul 2000 00:18:51 -0000 X-eGroups-Return: sentto-1101623-421-962842718-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 06 Jul 2000 01:18:46 -0000 Received: (qmail 32056 invoked from network); 6 Jul 2000 00:18:37 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 6 Jul 2000 00:18:37 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 6 Jul 2000 00:18:37 -0000 Received: from f-cpu.org (Aubervilliers-3-87.club-internet.fr [195.36.145.87]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA28267 for ; Thu, 6 Jul 2000 02:18:35 +0200 (MET DST) Message-ID: <3963D025.99A1D4A4@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <396140B3.99BB7BDC@f-cpu.org> <20000704164349.A83586@elvis.paf.net> <39628680.3F42881B@f-cpu.org> <20000705201254.B1122@beta> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 06 Jul 2000 02:17:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: [fcpu-ger] f-cpu meeting Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d4f0ecce6669009e5a6179fc85ff5b44 Status: R X-Status: N Marco Wertejuk wrote:

> Hi,
>
> | In Berlin, i know the CCC people who hosted me, and one of his frien= ds.
> | I think that there are also other f-cpu people there but i have no > | name. Could the concerned people complete this list ?
>
> I don't know whether it's neccessary, but I'm belonging as
> part to those CCC people and to those who tried to not fall
> asleep during 16C3 and therefore talked to everyone ;)
;-)
<Sven, btw, i'm still looking for your CD of the presentation>

> No it's not that way but to make it short, yes I'm in
> Berlin and of course would I try to come.
well, not "exactly" that way. it was incredile anyway :-D
lotsa fun and surprise at the 16C3 and outside too. I LOVE Berlin,
did i say it already ? :-) well, M=FCnchen too, as well as other
cities... but Berlin is VERY special. looks like i'm going there
before mid-august ? :-)

> | Either Munich or Berlin --- is there a chance to found the F-CPU Ver= ein
> | on this occasion ? (I think of the "seven people in a room"= ; problem)
> this is quite a goog idea, I think it won't be a problem
> to find this room in Berlin, I'll ask for those from the
> CCC Berlin.

well, then, go Berlin :-) can we prepare already the things there ?
(sorry for those who don't live in Berlin, i know it's far).

Before we go there, we'll organise a meeting in/around Paris at the
end of July. non-parisians/non-french welcome, of course :-) i can host
someone, i think (if you're worried about the hosting).

> -Marco-
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html


PS : after my comeback to the 3D/raytracing world, i go further into
my childhood and just bought myself a flying B2 with two micro-engines
(860mm span). terrrrrrific ! 140 grams :-) if someone has a spare 4-way rad= io
controller and a battery recharger, it would be nice :-)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00315 for ; Thu, 6 Jul 2000 21:41:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 06 Jul 2000 21:41:46 +0200 (MEST) Received: (qmail 833 invoked by uid 0); 6 Jul 2000 11:34:03 -0000 Received: from mv.egroups.com (208.50.144.81) by mx02.gmx.net with SMTP; 6 Jul 2000 11:34:03 -0000 X-eGroups-Return: sentto-1101623-422-962883199-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 06 Jul 2000 12:33:23 -0000 Received: (qmail 11848 invoked from network); 6 Jul 2000 11:33:19 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 6 Jul 2000 11:33:19 -0000 Received: from unknown (HELO ns.empi.net) (194.206.141.141) by mta1 with SMTP; 6 Jul 2000 11:33:17 -0000 Received: from anatole.empi.net (anatole.empi.net [155.132.171.52]) by ns.empi.net (8.8.8/8.8.8/DG,ns13.mc, V13, 5/jan/2000) with SMTP id HAA23653 for ; Thu, 6 Jul 2000 07:31:57 +0200 (CEST) (envelope-from daniel.germain@empi.net) To: Message-ID: <02294a09$c1f4cdc0$34ab849b@anatole.empi.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 From: "Daniel GERMAIN" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Jul 2094 07:39:48 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_02294A1A.857D9DC0" X-UIDL: be9d10baa18f044e35ac33f6a021ea68 Status: R X-Status: N ------=_NextPart_000_0026_02294A1A.857D9DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscripe ------=_NextPart_000_0026_02294A1A.857D9DC0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
unsubscripe
where you set the price
------=_NextPart_000_0026_02294A1A.857D9DC0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00321 for ; Thu, 6 Jul 2000 21:41:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 06 Jul 2000 21:41:48 +0200 (MEST) Received: (qmail 3141 invoked by uid 0); 6 Jul 2000 13:15:05 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 6 Jul 2000 13:15:05 -0000 X-eGroups-Return: sentto-1101623-423-962889295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 06 Jul 2000 13:14:56 -0000 Received: (qmail 32522 invoked from network); 6 Jul 2000 13:14:54 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 6 Jul 2000 13:14:54 -0000 Received: from unknown (HELO ra.goalasic.com) (216.46.16.170) by mta1 with SMTP; 6 Jul 2000 13:14:53 -0000 Received: (qmail 34171 invoked from network); 6 Jul 2000 13:14:47 -0000 Received: from max.goalasic.com (maxfranc@192.168.219.103) by ra.goalasic.com with SMTP; 6 Jul 2000 13:14:47 -0000 To: f-cpu@egroups.com In-Reply-To: <02294a09$c1f4cdc0$34ab849b@anatole.empi.net> Message-ID: From: "Maximiano C. Francisco III" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 6 Jul 2000 09:18:35 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d3bce590b5422612c617da915f3b2509 Status: R X-Status: N unsubscripe
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00330 for ; Thu, 6 Jul 2000 21:41:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 06 Jul 2000 21:41:50 +0200 (MEST) Received: (qmail 20849 invoked by uid 0); 6 Jul 2000 16:30:01 -0000 Received: from hp.egroups.com (208.50.99.201) by mx11.rz2.gmx.net with SMTP; 6 Jul 2000 16:30:01 -0000 X-eGroups-Return: sentto-1101623-424-962900864-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 06 Jul 2000 16:27:57 -0000 Received: (qmail 21470 invoked from network); 6 Jul 2000 16:27:43 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 6 Jul 2000 16:27:43 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 6 Jul 2000 16:27:43 -0000 Received: from f-cpu.org (Aubervilliers-3-101.club-internet.fr [195.36.145.101]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA20702 for ; Thu, 6 Jul 2000 18:27:39 +0200 (MET DST) Message-ID: <3964B351.A3580A8A@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 06 Jul 2000 18:26:57 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d95825459ffb069e9ecd7190ddc75125 Status: R X-Status: N "Maximiano C. Francisco III" wrote:
> unsubscripe

to those who didn't know :
- it is incorrectly spelled
- this is not the right way to unsub. check your complete mail headers
and see : "List-Unsubscribe: mailto:f-cpu-unsubscribe@egroups.com"
you posted to the wrong address.
- why do you leave us when things are going to heat soon ? :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03098 for ; Fri, 7 Jul 2000 07:58:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 07 Jul 2000 07:58:46 +0200 (MEST) Received: (qmail 10072 invoked by uid 0); 7 Jul 2000 05:33:23 -0000 Received: from hi.egroups.com (208.50.144.89) by mx02.gmx.net with SMTP; 7 Jul 2000 05:33:23 -0000 X-eGroups-Return: sentto-1101623-425-962947968-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 07 Jul 2000 05:33:14 -0000 Received: (qmail 14117 invoked from network); 7 Jul 2000 05:32:47 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 7 Jul 2000 05:32:47 -0000 Received: from unknown (HELO ns.empi.net) (194.206.141.141) by mta1 with SMTP; 7 Jul 2000 05:32:45 -0000 Received: from anatole.empi.net (anatole.empi.net [155.132.171.52]) by ns.empi.net (8.8.8/8.8.8/DG,ns13.mc, V13, 5/jan/2000) with SMTP id HAA25566 for ; Fri, 7 Jul 2000 07:26:43 +0200 (CEST) (envelope-from daniel.germain@empi.net) To: Message-ID: <02294ad2$41e66ac0$34ab849b@anatole.empi.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 From: "Daniel GERMAIN" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Jul 2094 07:35:02 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_02294AE3.056F3AC0" X-UIDL: befedfc7ad7b35152a2c3a3616373c06 Status: R X-Status: N ------=_NextPart_000_000C_02294AE3.056F3AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable UNSUBSCRIBE ------=_NextPart_000_000C_02294AE3.056F3AC0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
UNSUBSCRIBE
------=_NextPart_000_000C_02294AE3.056F3AC0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00641 for ; Mon, 10 Jul 2000 20:47:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 10 Jul 2000 20:47:54 +0200 (MEST) Received: (qmail 14918 invoked by uid 0); 8 Jul 2000 18:09:44 -0000 Received: from fg.egroups.com (208.50.144.70) by mx02.gmx.net with SMTP; 8 Jul 2000 18:09:44 -0000 X-eGroups-Return: sentto-1101623-426-963079778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 08 Jul 2000 18:09:39 -0000 Received: (qmail 23759 invoked from network); 8 Jul 2000 18:09:37 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 8 Jul 2000 18:09:37 -0000 Received: from unknown (HELO mercury.Sun.COM) (192.9.25.1) by mta1 with SMTP; 8 Jul 2000 18:09:37 -0000 Received: from dunaserv.Hungary.Sun.COM ([129.159.190.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05151 for ; Sat, 8 Jul 2000 11:09:32 -0700 (PDT) Received: from wyvern (wyvern [129.159.190.122]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id UAA20395 for ; Sat, 8 Jul 2000 20:09:25 +0200 (MET DST) Message-Id: <200007081809.UAA20395@dunaserv.Hungary.Sun.COM> To: f-cpu@egroups.com Content-MD5: 2YQfA4yVodcSrrUxBN2OQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_14 SunOS 5.8.1 sun4u sparc From: Erik Fischer - Systems Engineer Sun Hungary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 8 Jul 2000 20:09:10 +0200 (MEST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ac34a9447ee9644732d68f20a0d92ab2 Status: R X-Status: N Maybe this guy is in the same situation as myself. I was unsubscribed
several months ago, but automagically now I am again in the list.
If I send a mail to the alias, I get back that I not subscribed, so there is no way to unsubscribe me... :)
Wonderful list processor... If you have any idea...
Rgds,
Eric

~~> X-eGroups-Return:
sentto-1101623-424-962900864-eric=3DHungary.Sun.COM@returns.onelist.com
~~> X-Accept-Language: en
~~> To: f-cpu@egroups.com
~~> From: Yann Guidon <whygee@f-cpu.org>
~~> MIME-Version: 1.0
~~> Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.co= m
~~> Delivered-To: mailing list f-cpu@egroups.com
~~> List-Unsubscribe: <mailto:f-cpu-unsubscribe@egroups.com>
~~> Date: Thu, 06 Jul 2000 18:26:57 +0200
~~> Subject: Re: [f-cpu] unsubscribe
~~> Content-Transfer-Encoding: 8bit
~~> X-MIME-Autoconverted: from quoted-printable to 8bit by
dunaserv.Hungary.Sun.COM id SAA16455
~~>
~~> "Maximiano C. Francisco III" wrote:
~~> > unsubscripe
~~>
~~> to those who didn't know :
~~> - it is incorrectly spelled
~~> - this is not the right way to unsub. check your complete mail heade= rs
~~> and see : "List-Unsubscribe: mailto:f-cpu-unsubscribe@egroups.c= om"
~~> you posted to the wrong address.
~~> - why do you leave us when things are going to heat soon ? :-)
~~>
~~> WHYGEE
~~> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
~~> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
~~>
~~> --------------------------------------------------------------------= ----
~~> Where do sports heroes like Derek Jeter, Mia Hamm,
~~> Vince Carter and Peyton Manning hang out? Where else?
~~> Click now and find =91em all here!
~~> ht= tp://click.egroups.com/1/6211/1/_/3462/_/962900864/
~~> --------------------------------------------------------------------= ----
~~>
~~>

3D"ICplanet
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00690 for ; Mon, 10 Jul 2000 20:48:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 10 Jul 2000 20:48:18 +0200 (MEST) Received: (qmail 17905 invoked by uid 0); 9 Jul 2000 06:38:04 -0000 Received: from mw.egroups.com (207.138.41.167) by mx02.gmx.net with SMTP; 9 Jul 2000 06:38:04 -0000 X-eGroups-Return: sentto-1101623-427-963124678-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 09 Jul 2000 06:37:58 -0000 Received: (qmail 28291 invoked from network); 9 Jul 2000 06:37:57 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 9 Jul 2000 06:37:57 -0000 Received: from unknown (HELO bjsmtp1.163.net) (202.108.255.250) by mta1 with SMTP; 9 Jul 2000 06:37:57 -0000 Received: by bjsmtp1.163.net (Postfix, from userid 60001) id 520E41CA0096B; Sun, 9 Jul 2000 14:42:08 +0800 (CST) Message-Id: <39681EBE.10217@bjsmtp1.163.net> To: f-cpu@egroups.com X-Priority: 3 X-Originating-IP: [202.110.200.130] From: zwpkt@163.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 9 Jul 2000 14:42:06 +0800 (CST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] help Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 97954d603c60233de62bcd0430baae66 Status: R X-Status: N help ----------------------------------------------- 163µç×ÓÓʾ֣¬¸øÄú¸üÍêÃÀEmail·þÎñ£¡ http://www.163.net ------------------------------------------------------------------------ Make new friends, find the old at Classmates.com: http://click.egroups.com/1/5530/1/_/3462/_/963124678/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00747 for ; Mon, 10 Jul 2000 20:48:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 10 Jul 2000 20:48:35 +0200 (MEST) Received: (qmail 19053 invoked by uid 0); 10 Jul 2000 01:22:15 -0000 Received: from fl.egroups.com (208.50.144.74) by mx11.rz2.gmx.net with SMTP; 10 Jul 2000 01:22:15 -0000 X-eGroups-Return: sentto-1101623-428-963192133-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 10 Jul 2000 01:22:13 -0000 Received: (qmail 26243 invoked from network); 10 Jul 2000 01:22:12 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 10 Jul 2000 01:22:12 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 10 Jul 2000 01:22:12 -0000 Received: from f-cpu.org (Raspail-2-213.club-internet.fr [195.36.192.213] (may be forged)) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA21179; Mon, 10 Jul 2000 03:22:03 +0200 (MET DST) Message-ID: <39692513.C77B14DD@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 10 Jul 2000 03:21:23 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Berlin : f-cpu meeting / f-cpu Treffen Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 125626cc0c279f4ef0a9e89bb34d823e Status: R X-Status: N Hi !

i have not yet bought any ticket but i've decided
to take a night bus to go to Berlin (around 750FF A/R).
i'll try to stay 10 days there, i don't know where i'll
stay : if you have some spare room and a carpet, i'll
take it ;-) i don't know if Paul Mota is still ok
for the trip (h=E9 Paul, r=E9veille-toi ou je pars sans toi !).
for the dates : between 1 and 15 august, nothing exact yet.
The Paris meeting will take place the week before : we
can probably host people here.

i hope that these meetings will be a good occasion to
discuss a lot, make some technical advances, update the
websites, discuss and correct the manuals, and most of all :
see each others, sometimes for the first time :-)
This time i won't bring my trumpet (lots of worries)
but probably a tiny RC flying B2 :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D"ICplanet=
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01396 for ; Tue, 11 Jul 2000 12:19:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 11 Jul 2000 12:19:58 +0200 (MEST) Received: (qmail 30616 invoked by uid 0); 10 Jul 2000 19:17:52 -0000 Received: from ej.egroups.com (208.50.144.75) by mx12.rz2.gmx.net with SMTP; 10 Jul 2000 19:17:52 -0000 X-eGroups-Return: sentto-1101623-429-963252766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 10 Jul 2000 18:12:50 -0000 Received: (qmail 7698 invoked from network); 10 Jul 2000 18:11:47 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Jul 2000 18:11:47 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 10 Jul 2000 18:11:47 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000710181147.JPBL24904.mail.rdc1.wa.home.com@nventure.com> for ; Mon, 10 Jul 2000 11:11:47 -0700 Message-ID: <396A11E3.D0B561FA@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 10 Jul 2000 11:11:48 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8111cd1bb3302630253cb14075b1f251 Status: R X-Status: N This is the main mailing list for the Freedom
CPU Project. It will be broken down into various
topic-specific lists as needed. To subscribe,
send an empty message to
f-cpu-subscribe@makelist.com To unsubscribe,
send a message to f-cpu-unsubscribe@makelist.com
List Owner: f-cpu-owner@makelist.com

That's straight from the egroups Web site.  If that fails go to

http://www.egroups.com/

and hit "Contact Us" at the bottom of the page.

I can certainly understand why any would want to unsubscribe

-Most engineers who like to work with processors like to work with
architecture, one of the major legacy bottlenecks of modern uP's.  Very
few messages have been covering this.

-Most messages lately have been discussing meetings in Berlin or why
various suggestions wouldn't work.

-There has been little elaboration on useful ideas.

-Critics have been quick to shoot their mouths off without understanding
what they're criticizing.

-Alternatives to the existing f-cpu architecture (including my own) have
been shouted down without serious consideration, despite the fact
original assumptions behind f-cpu have proved invalid, the solutions
provided have proven too complex to implement.

-emails have simple been far too numerous.

-There has been no way to simply look at the subject of an e-mail to
determine whether it's even worth reading.  Threads have jumped from
idea to idea without the originator being very careful about modifying
the subject line to accomodate.

-Responses should often go directly back to the individual who is being
"debated," yet the whole group has had to hear the ravings of one guy
who doesn't understand what he is criticizing.

-emails have been too long, quoting things that have nothing to do with
the current message.

-Maxx

BTW, if anyone is in disagreement with any part of this, please reply
directly to maxx@nventure.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00993 for ; Thu, 13 Jul 2000 13:45:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 13:45:29 +0200 (MEST) Received: (qmail 16323 invoked by uid 0); 11 Jul 2000 14:11:39 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 11 Jul 2000 14:11:39 -0000 X-eGroups-Return: sentto-1101623-430-963324689-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 11 Jul 2000 14:11:38 -0000 Received: (qmail 19089 invoked from network); 11 Jul 2000 14:11:00 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Jul 2000 14:11:00 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 11 Jul 2000 14:11:00 -0000 Received: from f-cpu.org (Raspail-3-28.club-internet.fr [195.36.203.28]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA13192 for ; Tue, 11 Jul 2000 16:10:56 +0200 (MET DST) Message-ID: <396B2ACA.571457AE@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 11 Jul 2000 16:10:18 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6cd2d88e9d92ce12b37b5586fa575cb0 Status: R X-Status: N hi !

Albert Abramson wrote:
> This is the main mailing list for the Freedom
> CPU Project. It will be broken down into various
> topic-specific lists as needed. To subscribe,
> send an empty message to
> f-cpu-subscribe@makelist.com To unsubscribe,
> send a message to f-cpu-unsubscribe@makelist.com
> List Owner: f-cpu-owner@makelist.com
>
> That's straight from the egroups Web site.  If that fails go to
>
> http://www.egroups.com/
>
> and hit "Contact Us" at the bottom of the page.

thank you for this little detail.
let's hope that others will notice.

> I can certainly understand why any would want to unsubscribe
>
> -Most engineers who like to work with processors like to work with
> architecture, one of the major legacy bottlenecks of modern uP's.  Very
> few messages have been covering this.

this has been covered during years, now. we have to go forward and
see the details : how the execution units are designed and synchronized,
for example. This is very important because otherwise, we'd discuss
all the time and never DO something real. If you want strictly theoretical
discussions, there is comp.arch, but there, they discuss about REAL
(existing, or almost) architectures. we have to move on, too.

> -Most messages lately have been discussing meetings in Berlin or why
> various suggestions wouldn't work.

so what ? you feel frustrated by not being able to come ? i'm not
responsible, and others too. it's up to you, then, to organize a meeting
near you, and gather people around the project.

> -There has been little elaboration on useful ideas.

like a popcorn machine ? almost everything has been designed,
the "toughest" has been done one year ago. Now that we have a manual
(it's currently being translated to Latex) is almost ready for the
version 0.2, i hope that you understand that "the devil is in the detail".
Why do a super-incredible-architecture if you don't go down to
the implementation details ? it's gotta be real one day, so let's do it
now. if you want "useful" ideas, they are hidden behind the execution units.
if you want me to elaborate here on the LSU or the decoder, just ask.

> -Critics have been quick to shoot their mouths off without understanding
> what they're criticizing.

trying to be dumb is hard, you know. not only the f-cpu should be cool,
but it should run one day, with a lot of support from people who understand
it : that's why the RISC idea is a good starting point. Believe me, if
i was only responsible of the f-cpu, we'd have done something completely
different. but i have had to accept some "compromises" and you don't seem
to accept them. it took time for me, so i'm patient with you. i don't believe
that you idea is bad, i simply believe that it is not going to be accepted
by the user base soon. this acception factor is crucial for the project's
success and that's why other/precedent f-cpu archs have failed. there
is no easy success : the more chances we have, the easier we can move on
to another "better" architecture. what matters for most is not how cool the
architecture is, what they want is a chip that does not hold the Intel/Motorola
logo. if they can reuse their tools and embed this chip EASILY (electronically
and softwarewise) in other applications, they'll kill for this.
Now, if you require the soft to be dynamically compiled, the integration
will be difficult and the real-time guys will be scared : they need something
that they can blindly rely on and the less technologic levels, the easier it is
to garantee the response time of a routine.

today we can't force people to change their mind like that. Maybe, later,
we can, but we can't afford it today. Be patient. the f-cpu project is an
everyday work.

> -Alternatives to the existing f-cpu architecture (including my own) have
> been shouted down without serious consideration, despite the fact
> original assumptions behind f-cpu have proved invalid, the solutions
> provided have proven too complex to implement.

1) your xRISC architecture is too advanced for being widely accepted
today. we have to start with something simple, but this does not mean that
your idea is bad. please be serious. as i said previously and you force me
to repeat, go ahead ! don't be blocked now, start programming and writing
a manual for your core and it will easily become FC1 (F-CPU Core #1).

2) ""despite the fact original assumptions behind f-cpu have
    proved invalid, the solutions provided have proven too
    complex to implement.""
are you speaking about the FC0 or the original projects here ?
remember that there are months and months of difficult negociations
on this mailing list about the FC0 that you want to completely
invalidate "just because we don't like your core". come on, be a grown-up guy.
you're not forced to spit on what exists just because you feel that we don't
understand you. The FC0 is a BIG work, and i don't want to do that everyday
just because someone else comes with a "super idea". the f-cpu is the place
to experience with cores, but also a place where the ideas are confronted
to REALITY. here, you learn the sense of the words "patience" and "compromise".
An example ? my own ideas are well hidden behind the "RISC" acronym and
architecture. I have "reinvested" notions that i had developped alone,
and they can be easily understood by anyone because it's a "RISC-like",
even though some things are "slaughtered". I dislike page memory,
but i have accepted to include it in the FC0 because it would
be easier to implement today's OS : THAT is a compromise. If you want YOUR
ideas to be accepted, they have to be "envelopped" around something
they understand. people don't understand VLIW, people ignore the difficulties
behind it, compilers are not ready yet. This does not mean that you must not
work on your idea, this means that you have to ADAPT it. it takes time,
but don't worry.

> -emails have simple been far too numerous.
heh. do you want people to stop writing here ?
(just so that they're quiet and listen only to you ?)

> -There has been no way to simply look at the subject of an e-mail to
> determine whether it's even worth reading.  Threads have jumped from
> idea to idea without the originator being very careful about modifying
> the subject line to accomodate.
oh, come on... is it THAT important ? is the traffic THAT big you can't
keep up ? look at the threads 1 year ago, and tell me if you could
have followed.

> -Responses should often go directly back to the individual who is being
> "debated," yet the whole group has had to hear the ravings of one guy
> who doesn't understand what he is criticizing.
who are you speaking about ? anyway, it's a mailing list :
- where people don't like secrecy. everything should be said openly to
avoid hidden tensions. it's a matter of honnesty. if you're not interested
by a mail, don't read it, but you won't be able to say that you didn't know.
- where the main subject has always been computer architecture, and beside
some organisational stuffs, it is rather stable.

> -emails have been too long, quoting things that have nothing to do with
> the current message.
these like that can happen.

> -Maxx
>
> BTW, if anyone is in disagreement with any part of this, please reply
> directly to maxx@nventure.com
and if i don't disagree ? (oooops, this may sound like i disagree.) :-)


i repeat again and again, i don't believe that your arch is bad,
simply work on it. i even think that the group can help you on technical
matters (implementation, synthesis, fundry) but it is not as mature
as the current FC0. i'll quote one of my teachers : "that cool what you could do,
but what can you DO now ?" you have NO ISA, you have almost nothing.
work, Maxx. and don't EVER say that i discourage you, it's up to you to
prove what you claim with facts, pulling others down with you is not a good
idea.

Rue Tabaga.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01110 for ; Thu, 13 Jul 2000 13:45:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 13:45:59 +0200 (MEST) Received: (qmail 21083 invoked by uid 0); 12 Jul 2000 18:46:44 -0000 Received: from hm.egroups.com (208.50.99.198) by mx02.gmx.net with SMTP; 12 Jul 2000 18:46:44 -0000 X-eGroups-Return: sentto-1101623-431-963427517-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 12 Jul 2000 18:45:57 -0000 Received: (qmail 25085 invoked from network); 12 Jul 2000 18:45:14 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 12 Jul 2000 18:45:14 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 12 Jul 2000 18:45:14 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000712184513.WJUI24904.mail.rdc1.wa.home.com@nventure.com> for ; Wed, 12 Jul 2000 11:45:13 -0700 Message-ID: <396CBCBA.9229C4E0@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 12 Jul 2000 11:45:15 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e80ad51869c33fe991b4f827940265c7 Status: R X-Status: N Here's the simple, easy to implement VLIW:

Since each thread sees 8 local plus 8 global registers, we'll leave four
bits for registers.  Since each instruction is two source plus one
destination (on the simple implementation) we'll say that's 3 * 4 or 12
bits for registers plus 8 for opcode.  That means we can comfortably fit
three instructions into one 64 bit instruction word.  We'll allow the
last field to represent a 24 bit immediate for branch, constant, and
memory access, so we use a mechanism in the second instruction that
tells the hardware to treat that last field as a nop, so it doesn't
write anything back.

This, admittedly, places some real limitations on what you can do in one
cycle, but this is where I'm starting from, the smallest, most efficient
core I can make.

I'll go back to P&H and try to build an actual design out of this.  You
already know the kind of instruction mix I like, so you probably already
have a pretty good idea of what the end product will look like.

This, admittedly, will be the one-threaded version of my multi-threaded
VLIW design, but we'll see where the whole project goes, how scalable it
is, and how to handle synchronization and message passing later.

I'll get this done, then we'll see where we can go on the VLIW tangent.
Does anyone have a site I can post the results to? (ISA, FU layout, data
paths, caching, etc.)

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01131 for ; Thu, 13 Jul 2000 13:46:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 13:46:03 +0200 (MEST) Received: (qmail 31217 invoked by uid 0); 13 Jul 2000 02:28:46 -0000 Received: from jj.egroups.com (208.50.144.82) by mx02.gmx.net with SMTP; 13 Jul 2000 02:28:46 -0000 X-eGroups-Return: sentto-1101623-432-963435335-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 12 Jul 2000 20:56:10 -0000 Received: (qmail 22865 invoked from network); 12 Jul 2000 20:55:35 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 12 Jul 2000 20:55:35 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 12 Jul 2000 20:55:35 -0000 Received: from f-cpu.org (Aubervilliers-1-80.club-internet.fr [195.36.145.80]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA05958 for ; Wed, 12 Jul 2000 22:55:30 +0200 (MET DST) Message-ID: <396CDB0F.AD625078@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396CBCBA.9229C4E0@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 12 Jul 2000 22:54:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d578d8f7ebddd9c391807550fb4b3acd Status: R X-Status: N hi Albert,
sorry to answer publicly ;-)

Albert Abramson wrote:
> Here's the simple, easy to implement VLIW:
>
> Since each thread sees 8 local plus 8 global registers, we'll leave four
> bits for registers.  Since each instruction is two source plus one
> destination (on the simple implementation) we'll say that's 3 * 4 or 12
> bits for registers plus 8 for opcode.  That means we can comfortably fit
> three instructions into one 64 bit instruction word.  We'll allow the
> last field to represent a 24 bit immediate for branch, constant, and
> memory access, so we use a mechanism in the second instruction that
> tells the hardware to treat that last field as a nop, so it doesn't
> write anything back.

ouch ! 8 regs*2 ? only ? you might be kidding...
if RISC CPUs usually have 32 registers, it's not a random fact.
the more you have registers, the least you need to access memory
with common code (that is : not speaking about memory intensive stuff
like memory multiplies ...). you're making a "Load/Store architecture",
so you know that the less registers you have, the more L/S instructions
you have to emit.

> This, admittedly, places some real limitations on what you can do in one
> cycle, but this is where I'm starting from, the smallest, most efficient
> core I can make.

efficiency is such a subjective concept...

> I'll go back to P&H and try to build an actual design out of this.
just a warning (in case you didn't notice) : P&H is "outdated".
history doesn't change, true, but nobody knows the future, unless he writes it.
P&H were still valid 4 years ago, but now we're like 2 generations ahead
of the writing. (1 generation being like 3 years, cf moore's law).

>  You already know the kind of instruction mix I like, so you probably already
> have a pretty good idea of what the end product will look like.
no, but i'd like to see it and "discuss" about it :-)

> This, admittedly, will be the one-threaded version of my multi-threaded
> VLIW design, but we'll see where the whole project goes, how scalable it
> is, and how to handle synchronization and message passing later.
start studying the "Dragon book" too...

> I'll get this done, then we'll see where we can go on the VLIW tangent.
> Does anyone have a site I can post the results to? (ISA, FU layout, data
> paths, caching, etc.)

we can arrange a web hosting at f-cpu.org if you want.
or if you have a site, we can link it.

have fun,
> --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
Click here for 1 month of FREE* MSN Internet Access!
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01155 for ; Thu, 13 Jul 2000 13:46:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 13:46:15 +0200 (MEST) Received: (qmail 31770 invoked by uid 0); 13 Jul 2000 08:36:31 -0000 Received: from mk.egroups.com (207.138.41.165) by mx06.rz2.gmx.net with SMTP; 13 Jul 2000 08:36:31 -0000 X-eGroups-Return: sentto-1101623-436-963477386-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 13 Jul 2000 08:36:30 -0000 Received: (qmail 537 invoked from network); 13 Jul 2000 08:36:26 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 13 Jul 2000 08:36:26 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 13 Jul 2000 08:36:25 -0000 Received: from f-cpu.org (Raspail-3-27.club-internet.fr [195.36.203.27]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA15448 for ; Thu, 13 Jul 2000 10:36:23 +0200 (MET DST) Message-ID: <396D7F43.265C9B0E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <1cb3b0eb.36799ab3@aol.com> <396D640C.68CB4B7A@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 10:35:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Interesting snippet: SMT vs. 'multithreaded cpu' Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d95dbed326c585369d41fe41f237e37e Status: R X-Status: N yum ! some history resurfaces :-)

Kai Wetzel wrote:
> Hi folks,
>
> apparently the idea of multithreaded CPU as I presented it about
> one week ago is more clearly put in AlphaRISC's original words ?
> So here it goes:
> AlphaRISC@aol.com wrote:
<snip>

> > Anyway a more complex pipeline is slower, so nope, I don't like this
> > particular idea. Got any others?
hey, this is an arithmetical problem : there's no other way than splitting
the pipeline more and more, if you want raw MHz performance. there's no other way.
</rant>

> See ?  IIRC no attempts have been made on this list
> to explain why such an approach would not work, right ?
i don't know, i came just after that thread...

> (Admitedly I had it only partly right but things look a little
> different in the light of a traditional RISC/VLIW design, anyway,
> when compared to a TTA)

TTA is very different and poses a whole new set of questions.
but if you have the heart, why not make a VLIW TTA ? :-D
if we have 256 "registers", we can pack 4 instructions in a 64-bit
word.

> [...]
>
> Regards,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01688 for ; Thu, 13 Jul 2000 19:32:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 19:32:39 +0200 (MEST) Received: (qmail 24215 invoked by uid 0); 13 Jul 2000 12:18:13 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 13 Jul 2000 12:18:13 -0000 X-eGroups-Return: sentto-1101623-438-963489719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 13 Jul 2000 12:02:04 -0000 Received: (qmail 28916 invoked from network); 13 Jul 2000 12:01:59 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 13 Jul 2000 12:01:59 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta1 with SMTP; 13 Jul 2000 12:01:58 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e6DC1uB07131 for ; Thu, 13 Jul 2000 14:01:56 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e6DC1tC20234 for ; Thu, 13 Jul 2000 14:01:55 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id OAA18666 for ; Thu, 13 Jul 2000 14:01:55 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id OAA11488 for ; Thu, 13 Jul 2000 14:00:23 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <396DAFB2.A48DF99C@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 14:01:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0a15e009361b6743ce10e12a07c67123 Status: R X-Status: N Why not using all what was done for the fc0 ? You can built an vliw
processor with the current ISA. I don't know the optimal lenght, 3 or 4
ways ? So it's a processor with 3*32b = 96 bits plus maybe some bits to
manage the bloc.

I think that 8 local register is far to few (minus the PC and the stack
pointer there isn't any more general purpose register ). It's increase
the probleme with L/S but also the write after read dependancies (you
should more often reuse registers so you could make more depencies
between instructions and it's very annoying with long pipeline).

Or you can use a windowed register bank. I know that Whygee didn't like
this technique at all but this way you can artificially add some
registers (maybe a rotation of 4 register each function call ?).

I try to find some threads about windowed register bank but i didn't
find anything. So, if some people are interrested to give some (good)
arguments...

nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02229 for ; Thu, 13 Jul 2000 23:59:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 23:59:58 +0200 (MEST) Received: (qmail 31373 invoked by uid 0); 13 Jul 2000 19:26:54 -0000 Received: from hh.egroups.com (208.50.99.210) by mx02.gmx.net with SMTP; 13 Jul 2000 19:26:54 -0000 X-eGroups-Return: sentto-1101623-433-963447794-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 13 Jul 2000 00:23:19 -0000 Received: (qmail 28498 invoked from network); 13 Jul 2000 00:23:13 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 13 Jul 2000 00:23:13 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 13 Jul 2000 00:23:13 -0000 Received: from welfen-netz.com [193.194.149.179] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Thu, 13 Jul 2000 02:23:06 +0200 Sender: kai@pop.gmx.net Message-ID: <396D640C.68CB4B7A@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <1cb3b0eb.36799ab3@aol.com> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 08:39:08 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Interesting snippet: SMT vs. 'multithreaded cpu' Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a93aac3d4c244fc1a099cbdc58e19326 Status: R X-Status: N Hi folks,

apparently the idea of multithreaded CPU as I presented it about
one week ago is more clearly put in AlphaRISC's original words ?
So here it goes:

AlphaRISC@aol.com wrote:
>
> In a message dated 11/30/98 9:10:02 AM Central Standard Time,
> mtorni@freenet.hut.fi writes:
>
> >
> >  There's one thing I haven't fully understood yet, and that's the word
> >  "multithreaded cpu", does that mean multiple concurrent execution streams
> >  or multiple instructions executing in parallel inside a logical (software)
> >  stream?
>
> Multiple seperate threads executing on one chip, each with its own state.

[...]

> >  Instead of having one completion queue per thread in each FU, let's assume
> >  that instead of specifying physical destinations in the instruction word,
> >  we'll say that those are opcodes, that is; they don't specify an exact
> >  destination but instead specify a specific kind of a FU. The functional
> >  unit then stores the originating thread ID and doesn't respond to future
> >  requests until the thread has read back the result.
>
> This is simpler? The resoning behind multithreading is that you basically
> multiplex the threads through each bit of logic. The justification is that the
> logic is faster than the wires connecting it. So if an adder can operate in
> .5ns but it takes 4 ns to get the result across the chip, what are you going
> to do for the next 3.5ns? My answer is to do 7 other threads in the pipeline.
> Now, because those other threads are invisible to the first one the extra
> latency of the chip is hidden from the software. If it's a 2GHZ CPU it looks
> to each thread like it a 250MHz CPU. To sum it up we can pipeline the thing
> out the wazoo, and not pay penalties for branches, load/stores and cache
> misses per thread.
>
> Anyway a more complex pipeline is slower, so nope, I don't like this
> particular idea. Got any others?

See ?  IIRC no attempts have been made on this list
to explain why such an approach would not work, right ?

(Admitedly I had it only partly right but things look a little
different in the light of a traditional RISC/VLIW design, anyway,
when compared to a TTA)

[...]

Regards,
kai
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02232 for ; Thu, 13 Jul 2000 23:59:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 13 Jul 2000 23:59:58 +0200 (MEST) Received: (qmail 29534 invoked by uid 0); 13 Jul 2000 19:43:59 -0000 Received: from fh.egroups.com (208.50.144.71) by mx02.gmx.net with SMTP; 13 Jul 2000 19:43:59 -0000 X-eGroups-Return: sentto-1101623-435-963477384-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 13 Jul 2000 08:36:40 -0000 Received: (qmail 381 invoked from network); 13 Jul 2000 08:36:23 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 13 Jul 2000 08:36:23 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 13 Jul 2000 08:36:23 -0000 Received: from f-cpu.org (Raspail-3-27.club-internet.fr [195.36.203.27]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA10346 for ; Thu, 13 Jul 2000 10:36:17 +0200 (MET DST) Message-ID: <396D7F42.A0647233@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 10:35:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5c0c1e24ad4e743a94d65478b3e82cb7 Status: R X-Status: N cool, some constructive comments :-)

Kai Wetzel wrote:
> [Please keep in mind that my high respect for the FC0 design as well >  as the manual rev. 2 doesn't come across over large parts of thi= s
>  respose.  It's briefly mentioned, though]
i am very tolerant and self-critic, don't worry :-) i perfectly know
it is not a perfect thing, and i count on everybody to help correct the
problems. i can't do everything alone ;-)

> Yann Guidon wrote:
> > hi !
> > Albert Abramson wrote:
> [...]
> > > -Critics have been quick to shoot their mouths off without u= nderstanding
> > > what they're criticizing.
> > trying to be dumb is hard, you know. not only the f-cpu should be= cool,
> > but it should run one day, with a lot of support from people who = understand
> > it : that's why the RISC idea is a good starting point.
> You once wrote:
(long ago ;-D)
> : The MIPS/SPARC goals were to increase performance by decreasing the = transistor
> : count, increasing the clock frequency, simplify the processor and ov= erall
> : computer achitecture and Relegate the Important Stuff to the Compile= r (RISC :-D)
>
> :=B0) ...then, realizing that compilers wouldn't take the important st= uff, things
> like superscalar, dynamic branch prediction, OOO execution and what no= t were
> invented.  They still dared to call it RISC, funnily.

that was put as another layer above the original idea. But RISC is not a co= ncept
reduced to the canonical MIPS R2000. it was a major break from the microcod= ed era.
it was the starting of a qualitative and quantitative analysis of the depen= dencies
of the computer architecture with the software and the compiler. As long as= the
added "layers" (OOO, branch prediction etc) did fit the efficienc= y equation
(work done/core speed/transistor number/transistor budget/selling price/etc= ),
you can still call it whatever you want. On top of that, remember that 20y = ago,
we couldn't fit more than 10K or 20K transistors on a chip. Add to that tha= t you
can't increase the memory bandwidth like you increase the clock frequency, = and the
external pins consume more and more power, you then understand the increasi= ng complexity
of today's cores. it is a very complex problem.
yet, 20 years after the idea and the acronym appeared (even though
it was more or less existing in the CDC era computers made by Seymout Cray,=
then in the Crays and the IBM 701), we need a new name because the RISC acr= onym
has lost its sense...

> The (somewhat superficial) approach I'm taking is to go back and let's=
> see what we can cut away (branch prediction, OOO excution, register > renaming, et al.)  (As I see it we're left with a static pipeline= d
> _RISC_ design to start out from ...)
mmmm, good idea. but now, remember that the problems are still there :
very high memory latency and lower bandwidth, to name the most crucial ones= .

> I've lately learned that VLIW is a natural extension of "simple R= ISC"
> by adding static wide-issue. (If I'm not confusing things).  The = question
> is not RISC vs. VLIW, really, since what is NOT RISC about VLIW ?

the question is to be put differently, because things are not black or whit= e,
but complex and interleaved. In the beginning, that may be the first idea :=
static, simple EU, highly parallel, 256-bit instruction words.

but look at the problems it causes : with roughly 8 instructions per word,<= BR> the register set EXPLODES ! it requires at least 8 write ports and 16 read = ports.
heh.
look at the IBM protos and see how they struggle to exceed 30 MHz with TTL = parts :-)

that's one problem. Another one is the convergence between the holly concep= t of
instruction atomicity and the fact that it's smoother to have a dynamically= scheduled
core. programmers take as granted that an instruction completes or fail, an= d anything
between two instructions (IRQ or fault) should not modify the program's sta= te (unless
asked, like in a SW trap to the OS). With VLIW it's broken : instructions a= re packed
insecably, you can't even jump in the middle of a packet without "comp= lex hardware".
Since the 80's VLIW has been used in specialized hardware, in niche applica= tions like DSPs.
Now Intel chooses to use HP's technology (which they bough from another fir= m that was bought
>from another firm etc) and now everybody has VLIW on their mouth. yet, nobo= dy knows
how to make GOOD a compiler for this. fashion effect ?

you ask : "what is NOT RISC about VLIW ?"
my personal feeling about it is that it breaks some golden rules about prog= ram
flow. OTOH, to be realistic, one has to break something in order to advance= , but
the turnaround is not ready. thus people "patch" around it (look = at the IA64)
because they still want their "comfort" and it looks more like a = superscalar CPU.
come on : RISC, like pure VLIW, is an ideal case, a schoolbook example.
reality always catch you back and what remains is the constraints you put w= hen you
started the design. furthermore, 20years have gone since this "VLIW&qu= ot; (as well as "RISC"
term) was first mentionned : we face completely different problems now.

you can't understand today the problems that led to microcoding, todays it'= s the
same for VLIW and RISC. Now things have evolved and we learnt from the past= and
the idealistic "wonderful" ideas. we have to move on and make som= ething new with
all the things we pretend to know.

"what is NOT RISC about VLIW ?" i'll answer : "what is RISC = ? What is VLIW ?"
because you can't reduce RISC to MIPS/SPARC and VLIW to a packeted instruct= ion machine.
everything is connected to the rest.


> The central question that remains is whether/how a design which does N= OT follow
> the "simple hardware, smart compiler" approach can gain sign= ificantly better
> price/performance ratio then the chips designed by MIPS, digital, Sun,= etc.
> at all.  (I do not doubt, btw, that IF the answer to this questio= n was yes,
> FC0 would be a perfect candidate to fulfill the promise).

like i've written before, i have a certain kind of mindset, coming from
the DSP and HPC cultures. the kind of applications i usually program is sin= gle-threaded
and mono-user, it uses 100% of the machine time and memory space. in my &qu= ot;world",
a computer computes, nothing else. if you have ever computed fractals, rayt= racing,
physical modeling, sound processing or image filtering, you may understand = what i mean.

Albert's point of view, which is not better or worse, is to take a usual pr= ogram,
usually C++ or generated by another program (YACC for example), where peopl= e want
it to work and then they buy a faster computer to run it faster when they g= et frustrated.
For example, Netscape or M$ Office are huge software that require megabytes= of source
code and are written for "portability, time-to-market and easy bug-tra= cking".
they blindly rely on the compiler and don't care a fuck about the running t= ime.
and then, they dare to ask for more performance ;-)

my POV is to look at what the algo does. ok i know, it depends on the persp= ective.
memory is slower ? then we need more control over its access. OOO and SMT a= re only
ways to "displace" the problem, still using dumb algos. IF you ar= e smart enough to
recognize a sequential (linear block) access to an array, then you can incl= ude this
hint to the code, a bit like "vectorized" code. we don't have vec= tors but the idea
is similar and doesn't require complex reordering.
etc etc.
after we have extracted everything we could from the algo, then we can safe= ly extract
more infos from the instruction stream's ordering (like OOO, renaming, SMT,= whatever...)

> > Believe me, if i was only responsible of the f-cpu,
> > we'd have done something completely different.
> BTW, did you abandon PFQs or did I miss something in the manual ?
i have left it for after. it's hidden in a corner of my brain and is waitin= g for the
right moment to jump out of the bush ;-P

let's make a simple, canonical F-CPU first, then add the bells and whistles= when it works :-)

> > but i have had to accept some "compromises" and you don= 't seem to accept them.
> Hmm, I simply don't see _what_ aspects of FC0 will make it the
> CPU architecture of choice for the next 20 years or so (as you
> suggested), reaching performance levels unknown to even exist
> (by factor two has been suggested here a few days ago, IIRC)
it's not one or two aspects, but a conjunction of factors that
make an architecture...

> > it took time for me, so i'm patient with you. i don't believe
> > that you idea is bad, i simply believe that it is not going to be= accepted
> > by the user base soon.
>
> Hmm, who would that be ?  I was assuming that the biggest short-t= ime
> markets for an alternative full-blown 64bit CPU would be something lik= e:
>
> - low-cost/high-performance entry-level workstations for geeks (BeBox)=
>   (may also be daughter-boards to start out)
> - engineering/graphics workstations with multiple (some, <=3D16) CP= Us
> - scientific computing multi-processor machines (>32)
> (as well as servers if memory architecture, reliability, etc. is beein= g
> worked on by third parties.)

the first protos have to be VERY handy, even if they are limited.
the fact that you can gluelessly plug commercial SDRAMs is an example.
then, when the architecture gets known and accepted, we can add the "f= eatures".
if we skip the "acception" stage, we have less chances to success= easily.
remember that the first users of the f-cpu will be poor hobbyists like us,<= BR> they don't want any complex stuff, they want something that they can use ou= t of
the bow, without 3 months of design analysis in a specialized office with a=
10-engineer staff.

> Why should these people not accept a CPU which is plain _fast_ ?
they need a power that they can access easily (without complex programming<= BR> and plugging etc). and, seriously, we can't pretend to make a Athlon or Alp= ha-killer
without having something working first. there are a lot of difficulties tha= t
we have to face one by one. let's make something, then push the "turbo= " button :-)

> (Where I worked as an intern for a few weeks some years ago they
> even built a little transputer-based workstation thinking this was goi= ng
> to be the future, so much for coolness doesn't count (below) ;=B0><= BR> ah, the transputers... i guess that it's the kind of dream we should try to= reach.
The SHARC is cool too.

> > this acception factor is crucial for the project's
> > success and that's why other/precedent f-cpu archs have failed. > Well, I don't quite know what you mean, Albert even calls it "xRI= SC" and
> I never said it's anything but RISC, even with some of the more
> complicated parts left out ! :^)
with the usual "post-RISC" cores, like we know today, the complex= ity can be
understood through the architecture and we can have a rough feeling of
the execution time of a known program. With its xRISC, we can't inter/extra= polate
>from previous known experiences. It's a common fact, that people prefer
error better than uncertainty. what i tried to do with the fc0 is to give them a fainted feeling of security ;-) just take a usual RISC, swap a few t= hings,
and you can program it...

> > there is no easy success : the more chances we have, the easier w= e can move on
> > to another "better" architecture.
> Ok.
but before we can move on, we have to walk this first step that people are = awaiting
for two years :-)

> > what matters for most is not how cool the architecture is, what t= hey want
> > is a chip that does not hold the Intel/Motorola logo. if they can= reuse
> > their tools and embed this chip EASILY (electronically and softwa= rewise)
> > in other applications, they'll kill for this.
> > Now, if you require the soft to be dynamically compiled, the inte= gration
> > will be difficult and the real-time guys will be scared : they ne= ed something
> > that they can blindly rely on and the less technologic levels, th= e easier it is
> > to garantee the response time of a routine.
> I think you're exaggerating about "requiring" dynamically co= mpiled
> software.  It's just good for "optimal" speed.  If= it's their wish
> they can compile for the specific CPU they "embed" and there= are no
> more surprises about reliability then usual...
i agree. but who am i to speak about a CPU with no published ISA ? :-)

> > today we can't force people to change their mind like that. Maybe= , later,
> > we can, but we can't afford it today. Be patient. the f-cpu proje= ct is an
> > everyday work.
> Hmm, IMHO we can show them what's possible.
let's first show that a bunch of hobbyists can fund a chip.
then, they'll care about the core. the industrial mentality can be so
dumb, sometimes... what they want is dollars, not dreams.

>  If people realize that they
> can run their stuff at ten times the speed and they are not getting > this today because their favorite vendor takes no risc and the compile= rs
> usually suck there could be some movement ... else it's all gonna stay= as it is.
the first movement that we have to trigger is to show that the bazaar-style=
development can work in the IP and microelectronics industry.
The core is just a facade, because (like Albert wrote), anybody can design<= BR> a CPU core (OpenCores more or less ripped off P&H, so there's no wonder= ...).
the real challenge is not to design a CPU, the problem is to makeit real and economically efficient. Then, a lot more of people will do their own st= uffs,
innovation and variety will explode. let's make a chip first, a toy,
a physical proof of concept.

> > > -Alternatives to the existing f-cpu architecture (including = my own) have
> > > been shouted down without serious consideration, despite the= fact
> > > original assumptions behind f-cpu have proved invalid, the s= olutions
> > > provided have proven too complex to implement.
> >
> > 1) your xRISC architecture is too advanced for being widely accep= ted
> > today. we have to start with something simple, but this does not = mean that
> > your idea is bad. please be serious. as i said previously and you= force me
> > to repeat, go ahead ! don't be blocked now, start programming and= writing
> > a manual for your core and it will easily become FC1 (F-CPU Core = #1).
>
> I'm not up-to-date with all the details of xRISC, so I can't comment o= n
> that, really.
me too : that's why i ask a serious and extensive work on it.
>  In general I don't see why you'd call an approach which
> is basically KISS should be "too advanced to be widely accepted t= oday"
> (such as a simple (VLIW- ?)RISC processor :)  How should anything= be
> widely accepted today which is not advanced ?  (Ok, I know the an= swer, it's
> called "marketing").
"too advanced" was meant in the sense that there is no way (other= than by hand)
to program it efficiently. usually, i program by hand, see what algo is mos= t
efficient, and program that algo in C. With Albert's core, there is NO code= today.
i call that "too advanced" :-)

> > 2) ""despite the fact original assumptions behind f-cpu= have
> >     proved invalid, the solutions provided ha= ve proven too
> >     complex to implement.""
> > are you speaking about the FC0 or the original projects here ? > > remember that there are months and months of difficult negociatio= ns
> > on this mailing list about the FC0 that you want to completely > > invalidate "just because we don't like your core". come= on, be a grown-up guy.
> > you're not forced to spit on what exists just because you feel th= at we don't
> > understand you. The FC0 is a BIG work, and i don't want to do tha= t everyday
> > just because someone else comes with a "super idea". >
> Yes, I like the manual!  It's well-written and carefully done.&nb= sp; It's
> even fair on TTA.  (Hey, it's even fair on M2M or else you could = have included
> AlphaRISC's comment, something like "you can't kill it twice, job= done." ;=B0>
>
> Many of the aspects of FC0 are great, including the innovative
> functional units you've come up with over time, SIMD, OOO completion, = ...

hey, can i quote that in the manual ? :-P </egobooster>

> At that point I'm wandering why you stopped there, why you didn't take=
> it a step further. Ok, ok, it has been explained, the "compilers = are not ready"
> stuff :=B0(
not only the compiler is not yet written (the GNL project has just started,= more or less)
but too much at once is not sane. i could go on and on, but i don't know ye= t how much
i can handle at once hardwarewise. softwarewise, i can handle 150K of x86 a= sm,
but i have not seen my limits with CPU architecture. so i prefer to start s= afely,
instead of hitting a hard wall at the first attempt ;-)

> > the f-cpu is the place to experience with cores, but also a place= where
> > the ideas are confronted to REALITY. here, you learn the sense of= the words
> > "patience" and "compromise".
> > An example ? my own ideas are well hidden behind the "RISC&q= uot; acronym and
> > architecture. I have "reinvested" notions that i had de= velopped alone,
> > and they can be easily understood by anyone because it's a "= RISC-like",
> > even though some things are "slaughtered". I dislike pa= ge memory,
> > but i have accepted to include it in the FC0 because it would
> > be easier to implement today's OS : THAT is a compromise.
>
> IMO the process has to be put down clearly:
> - what's the problem _exactly_ ?
> - what are possible solutions to the problem ?
> - what are the trade-offs involved ?
> - why has a particular solution be chosen ?
>
> You've probably done something like this here, I wasn't around for
> almost a year, after all, so I can't tell.
more or less, it's written in the manual (that you seem to have read, thank= you :-)))
for more details, hey, there is the mail archive, but i doubt that you want= to read
around 3K mails in a row... you'd get sick quickly :-P

>  It's hard for newcomers to
> accept such compromises if the rationale of the decision making is not=
> clearly visible and they might expect political compromises rather the= n
> technical ones.
politics, politics... i'd rather say : diplomacy ;-)

> > If you want YOUR
> > ideas to be accepted, they have to be "envelopped" arou= nd something
> > they understand. people don't understand VLIW, people ignore the = difficulties
> > behind it, compilers are not ready yet. This does not mean that y= ou must not
> > work on your idea, this means that you have to ADAPT it. it takes= time,
> > but don't worry.
> I like you're line of thinking that FC0 may be succeeded by a differen= t FCx.
hey, that's the whole point : we can't pretend to have the best ever cpu. we have to provide a lot of braking points, turnarounds, evolution paths...=
i know that the work we did for FC0 will be void in ten years, yet i know t= hat
it will influence a lot of things long after that. that's wht i try to push= some
SW/algo "features" from the start, so we can add SMT, VLIW, reg r= enaming, whatever,
safely and later.

>  I was wandering though, couldn't FC0 be reused as a virtual mach= ine ISA
> for a second generation (FC1, or FC2) ?
the ISA is more or less separated from the real core. they are dependent, b= ut
the specs make the ISA more or less interpretable on another machine with t= he
necessary features (registers, decoder, ALU). a big effort about instructio= n
ordering and atomicity has been made to avoid problems later.

>  I only see some points about the ISA which are somewhat limiting= , such as
> needing two result buses (e.g. in case of SIMD carry) as well as some = others.
as for the 3R2W R7, it's a concious choice. it's particularly necessary for= the
load/store instructions with register increments (common sense). Then, once= it's
accepted, we realize that it benefits a lot of cases.
if you dislike this (3R2W R7) then you will HATE the HP/PA RISC ;-)
it has some instructions which have 5 register fields, and performs 2 arith= . op
in one instruction, and it's 3R2W (while the FC0 is limited to 2R2W or 3R1W= ).

>  What I'm saying is that with some changes FC0 could serve as a &= quot;we can do it"
> CPU AND a virtual ISA for the next generation architecture.
well, i think that you understood the manual quite well ;-)

> I'm still saying, though, that it would be better to test some designs=
> before deciding on them and putting them in stone (silicon).
i'll be doing this during the coming year (starting in october).
i still have a LOT of things to program and write.

> IMHO this
> holds true for any design, let it be FC0, or a VLIW approach, or even = TTA -
> if problems show up we must remain flexible enough to alter our ideas.=
> IMO pointing out potential problems in advance helps this validation p= rocess
> so we won't be surprised by low performance chips.
yup. but the big problem today is that we ignore completely the electronica= l problems.
synthesis, simulation, routing, noise extractions... design rules...
how can we pretend to make a chip if we ignore all that ???

> > i'll quote one of my teachers : "that cool's what you could = do,
> > but what can you DO now ?" you have NO ISA, you have almost = nothing.
> But to be fair, a VLIW core is easier to design then, say, FC0, so
> despite the work put in FC0 the lag isn't as severe.
hum... he has not even decided about the packet size and the number of
registers. even though he can make something within a night, he won't gain<= BR> much experience from it. The FC0 took a LONG time to appear and each point<= BR> (number of registers, size of the instruction field etc) was the subject of=
a long debate. the endian debate, for example... gawd...

>  By reusing
> a significant portion of work done for FC0, such as FUs, arriving
> at FC1 could take much less time then it took us to arrive
> at FC0.
i agree. that's why, in order to reduce the amount of debates and work,
Albert should reuse most of the f-cpu characteristics. he's not forced
to reuse EVERYTHING, he has the choice to select what's ok for him and what= 's not,
but the "core instruction set" is a good starting point. there ar= e also
free opcodes for explicit register renaming or explicit thread management.<= BR> enhancement ideas are also welcome and can be reused in the FC0.

> > work, Maxx. and don't EVER say that i discourage you, it's up to = you to
> > prove what you claim with facts, pulling others down with you is = not a good
> > idea.
>
> So, what could be done to encourage people with ideas for architechtur= es
> past FC0 to assemble and line-up behind the FCPU-team, possibly formin= g
> sub-teams investigating other paths, sharing ideas and designs among e= ach
> other and working towards a common goal in an inspiring and fruitful m= anner
> in spite of the fact that their ideas may come too late for FC0 ?

huh, something roughly like that ... :-)

remember, the FC0 is not "the end of it all", just the "star= t of it all"...
it may or may not be implemented, but cristalizes most of the essence of th= e
project. this doens't mean in any way that we can't do better, far from it.=

> Best regards,
thanks for the chat, and see you in Berlin,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02292 for ; Fri, 14 Jul 2000 00:00:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 14 Jul 2000 00:00:07 +0200 (MEST) Received: (qmail 16528 invoked by uid 0); 13 Jul 2000 20:35:52 -0000 Received: from hh.egroups.com (208.50.99.210) by mx02.gmx.net with SMTP; 13 Jul 2000 20:35:52 -0000 X-eGroups-Return: sentto-1101623-437-963485251-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 13 Jul 2000 10:52:14 -0000 Received: (qmail 14871 invoked from network); 13 Jul 2000 10:47:23 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Jul 2000 10:47:23 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 13 Jul 2000 10:47:23 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000713104723.SYGC24904.mail.rdc1.wa.home.com@nventure.com> for ; Thu, 13 Jul 2000 03:47:23 -0700 Message-ID: <396D9E3B.91CF0B87@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 03:47:32 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d11a3399a5c70b31fccf565d65dd0d1f Status: R X-Status: N The latest design from the mind of me is the aforementioned VLIW of 64 bits.  Here are some useful innovations...

Like the Cray 1, keeps address and data registers separate.  Aside >from the aforementioned register shortage (8 local, 8 global), handling addresses separately (always unsigned integers) keeps hardware simpler.  Fewer operations actually work on the address registers, so the hardware is simplified.

The 64 bit word is broken up into three operation fields plus a suffix (op1, op2, op3, sufx).  The last field plus the suffix can be used for the last 30 bits of a 32 bit immediate.  Another two bits can be found in op2 when immediates are used.

Each op field then looks like this:
op    4
rD    4
rA    4
rB    4

with the exception that two additional bits are available for op2 and that an rC field is available for op3.

The restrictions then break down thusly:

-Branches, load-stores, and imm operations must use op2 field.  This limits such throughput to one a time, but code heavy with this tends to be branch intensive, anyway.

-Compound operations (macc) use op1 or op3 in order to read their respective rC in the suffix field.  This would leave a total of eight read ports (and three write ports) for the register file.  However, by splitting them, six reads and two writes are attained on each.

-Since there are separate address and data registers, and global and local sets, we gain access to a total of 32 registers.  In addition, data registers are 128 bits wide (and may be expanded further) packing many operands into one register.

-Four condition bits are added to each data register.  One for LT, GT, EQ, and Update.  This makes for more efficient message passing, as a single register (for example, a global) can read the contents of a register to determine whether or not its contents are updated or a stale value.  The results of comparisons can then be seen just by reading these bits.  Moreover cmovs and cbranches become much more powerful, allowing all sorts of complex decision making to be folded into a single operation.

Since the first design does not take multithreading into account yet, we get to avoid the intracacies of branch-on-miss, managing stacks of threads, allocating global registers, fine/coarse-grain parallelism, message passing, and memory protection.
  

the question is to be put differently, because things are not black or white,
but complex and interleaved. In the beginning, that may be the first idea :
static, simple EU, highly parallel, 256-bit instruction words.

but look at the problems it causes : with roughly 8 instructions per word,
the register set EXPLODES ! it requires at least 8 write ports and 16 read ports.
heh.
look at the IBM protos and see how they struggle to exceed 30 MHz with TTL parts :-)


That's why I'm suggesting narrow VLIW.  Perhaps a different name?  NSVLIW?

Point being that it's really hard to consistantly issue more than two or three instructions per cycle.  Counting memory latency, no one is even getting better than .55 on well optimized code.  The largest OOO windows, the best branch prediction, and the widest issue still don't get us down to .50.  Only multithreading offers that possibility, and it does it without so much of the clock penalty.

Admittedly, the design I'm working on is restrictive, and the limited number of operations of one type can add a cycle here and there... as well as the smallish register set.

Still, a three issue design isn't so bad.  It's as good as G3, anyway; and we don't have to tear our hair out trying to get another instruction done every cycle.  ILP isn't worth pursuing at the expense of all else.  VLIW is useful because it allows much higher clock rates to be obtained.  If it is compromised for very wide issue, and you just end up with a lower clock rate.  You can't get a good CPI on software scheduled processors, not until dynamic optimization software comes into its own.
  

Albert's point of view, which is not better or worse, is to take a usual program,
usually C++ or generated by another program (YACC for example), where people want
it to work and then they buy a faster computer to run it faster when they get
frustrated.
For example, Netscape or M$ Office are huge software that require megabytes of source
code and are written for "portability, time-to-market and easy bug-tracking".
they blindly rely on the compiler and don't care a fuck about the running time.
and then, they dare to ask for more performance ;-
The client -- our end customer -- wants the best performance he can get.  The application developers don't seem to be willing to work very hard or compromise very much to help the client machine operate more efficiently.  People get frustrated with how slowly a word processing program runs on our post-modern gigaflops supercomputers (that are never fast enough for us), but Craposoft Word and Corap Wordperfect and Loada CrapSuite REALLY SUCK.  Big application developers just don't give a rat's ass about the performance of their product.

Formula 1 isn't going into our machines.  We get ARCO, and that's what we have to design for. That's why IA-64 will perform well on SPECmarks and poorly on real world apps.  Extremely short clock rates and fast task switching can go a long way toward improving performance on this type of work, but basically, you know what you're shoveling into your cup, and it ain't Taster's Choice.  What's going on inside Intel is one of those tragic stories we read about afterward where everyone already knew the thing was going to fail inside and out, yet no one from inside can turn it around because they take internal criticism like treason or something... and everyone has to get behind the going strategy or they'll show weakness, which can often be worse than a bad product, which Itanium is.

However, for the really computationally intensive stuff, VLIW works because it doesn't waste hardware with decode and checking and dynamic rescheduling and all of those other horrible things that do no useful work.

Now, these are ideas.  Do they have to be accompanied by a whole instruction set?  Do we have 16 instructions or 160?  Who knows, we just look at each one.  The point is, we can prove feasability of individual concepts or argue instructions set mixes and poke holes in people's ideas.  I prefer to explore feasibility.  Compilers deliberately put work together that can issue in parallel, so bundling them into one word doesn't sound like too much extra work to me.  Getting compilers to speculatively schedule work that might be useful into one static stream is much tougher, and the functionality involved in doing so usually hurts the clock rate too much anyway.  The problem with trying to issue lots of instructions at one time -- even if you can do it -- is that the hardware actually slows down to accomodate everything. 

> > i'll quote one of my teachers : "that cool's what you could do,
> > but what can you DO now ?" you have NO ISA, you have almost nothing.
> But to be fair, a VLIW core is easier to design then, say, FC0, so
> despite the work put in FC0 the lag isn't as severe.
hum... he has not even decided about the packet size and the number of
registers. even though he can make something within a night, he won't gain
much experience from it. The FC0 took a LONG time to appear and each point
(number of registers, size of the instruction field etc) was the subject of
a long debate. the endian debate, for example... gawd...
In other words, VLIW isn't that hard.  One could even make a VLIW version of FCO.  It just means that whatever work is going to move forward in one cycle is written out explicitly in one Very Long Instruction Word.  Since use of the wider registers depends on a recompile, what the hey!

Issues like packet size and register size and instruction mix should be saved until simulations can be run.
  

>  By reusing
> a significant portion of work done for FC0, such as FUs, arriving
> at FC1 could take much less time then it took us to arrive
> at FC0.
i agree. that's why, in order to reduce the amount of debates and work,
Albert should reuse most of the f-cpu characteristics. he's not forced
to reuse EVERYTHING, he has the choice to select what's ok for him and what's not,
but the "core instruction set" is a good starting point. there are also
free opcodes for explicit register renaming or explicit thread management.
enhancement ideas are also welcome and can be reused in the FC0.
I don't really like the instruction set for f-cpu as it stands.  That was one of my first criticisms of the existing architecture.  The instruction set I came up with for xRISC a while back was only 30 instructions or so, and much more effective than f-cpu's less than orthogonal set.

--Maxx

hey, Kai, maybe we should just split off on this VLIW/xRISC thing and see what comes of it... eh?  I know I could have something done in VLIW in less time it has taken to get "permission" from Yawn "WHYMEE" Guidon.

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02752 for ; Fri, 14 Jul 2000 01:39:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 14 Jul 2000 01:39:54 +0200 (MEST) Received: (qmail 9577 invoked by uid 0); 13 Jul 2000 22:15:15 -0000 Received: from fl.egroups.com (208.50.144.74) by mx12.rz2.gmx.net with SMTP; 13 Jul 2000 22:15:15 -0000 X-eGroups-Return: sentto-1101623-434-963447927-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 13 Jul 2000 00:26:02 -0000 Received: (qmail 23237 invoked from network); 13 Jul 2000 00:25:18 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 13 Jul 2000 00:25:18 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 13 Jul 2000 00:25:18 -0000 Received: from welfen-netz.com [193.194.149.179] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Thu, 13 Jul 2000 02:23:12 +0200 Sender: kai@pop.gmx.net Message-ID: <396D7F7E.5F459EA9@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 13 Jul 2000 10:36:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribers, rationale Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 376a56f9c6079db278f0fb466a83bd7f Status: R X-Status: N [Please keep in mind that my high respect for the FC0 design as well
as the manual rev. 2 doesn't come across over large parts of this
respose.  It's briefly mentioned, though]

Yann Guidon wrote:
>
> hi !
>
> Albert Abramson wrote:
[...]
> > -Critics have been quick to shoot their mouths off without unders= tanding
> > what they're criticizing.
>
> trying to be dumb is hard, you know. not only the f-cpu should be cool= ,
> but it should run one day, with a lot of support from people who under= stand
> it : that's why the RISC idea is a good starting point.

You once wrote:
: The MIPS/SPARC goals were to increase performance by decreasing the trans= istor
: count, increasing the clock frequency, simplify the processor and overall=
: computer achitecture and Relegate the Important Stuff to the Compiler (RI= SC
:-D)

:=B0) ...then, realizing that compilers wouldn't take the important stuff, = things
like superscalar, dynamic branch prediction, OOO execution and what not wer= e
invented.  They still dared to call it RISC, funnily.

The (somewhat superficial) approach I'm taking is to go back and let's
see what we can cut away (branch prediction, OOO excution, register
renaming, et al.)  (As I see it we're left with a static pipelined
_RISC_ design to start out from ...)

I've lately learned that VLIW is a natural extension of "simple RISC&q= uot;
by adding static wide-issue. (If I'm not confusing things).  The quest= ion
is not RISC vs. VLIW, really, since what is NOT RISC about VLIW ?

The central question that remains is whether/how a design which does NOT fo= llow
the "simple hardware, smart compiler" approach can gain significa= ntly better
price/performance ratio then the chips designed by MIPS, digital, Sun, etc.=
at all.  (I do not doubt, btw, that IF the answer to this question was= yes,
FC0 would be a perfect candidate to fulfill the promise).

> Believe me, if
> i was only responsible of the f-cpu, we'd have done something complete= ly
> different.

BTW, did you abandon PFQs or did I miss something in the manual ?

> but i have had to accept some "compromises" and you don't se= em
> to accept them.

Hmm, I simply don't see _what_ aspects of FC0 will make it the
CPU architecture of choice for the next 20 years or so (as you
suggested), reaching performance levels unknown to even exist
(by factor two has been suggested here a few days ago, IIRC)

> it took time for me, so i'm patient with you. i don't believe
> that you idea is bad, i simply believe that it is not going to be acce= pted
> by the user base soon.

Hmm, who would that be ?  I was assuming that the biggest short-time markets for an alternative full-blown 64bit CPU would be something like:
- low-cost/high-performance entry-level workstations for geeks (BeBox)
  (may also be daughter-boards to start out)
- engineering/graphics workstations with multiple (some, <=3D16) CPUs - scientific computing multi-processor machines (>32)
(as well as servers if memory architecture, reliability, etc. is beeing
worked on by third parties.)

Why should these people not accept a CPU which is plain _fast_ ?
(Where I worked as an intern for a few weeks some years ago they
even built a little transputer-based workstation thinking this was going to be the future, so much for coolness doesn't count (below) ;=B0>

> this acception factor is crucial for the project's
> success and that's why other/precedent f-cpu archs have failed.

Well, I don't quite know what you mean, Albert even calls it "xRISC&qu= ot; and
I never said it's anything but RISC, even with some of the more
complicated parts left out ! :^)

> there is no easy success : the more chances we have, the easier we can= move on
> to another "better" architecture.

Ok.

> what matters for most is not how cool the architecture is, what they w= ant
> is a chip that does not hold the Intel/Motorola logo. if they can reus= e
> their tools and embed this chip EASILY (electronically and softwarewis= e)
> in other applications, they'll kill for this.
> Now, if you require the soft to be dynamically compiled, the integrati= on
> will be difficult and the real-time guys will be scared : they need so= mething
> that they can blindly rely on and the less technologic levels, the eas= ier it is
> to garantee the response time of a routine.

I think you're exaggerating about "requiring" dynamically compile= d
software.  It's just good for "optimal" speed.  If it's= their wish
they can compile for the specific CPU they "embed" and there are = no
more surprises about reliability then usual...

> today we can't force people to change their mind like that. Maybe, lat= er,
> we can, but we can't afford it today. Be patient. the f-cpu project is= an
> everyday work.

Hmm, IMHO we can show them what's possible.  If people realize that th= ey
can run their stuff at ten times the speed and they are not getting
this today because their favorite vendor takes no risc and the compilers usually suck there could be some movement ... else it's all gonna stay as i= t is.

> > -Alternatives to the existing f-cpu architecture (including my ow= n) have
> > been shouted down without serious consideration, despite the fact=
> > original assumptions behind f-cpu have proved invalid, the soluti= ons
> > provided have proven too complex to implement.
>
> 1) your xRISC architecture is too advanced for being widely accepted > today. we have to start with something simple, but this does not mean = that
> your idea is bad. please be serious. as i said previously and you forc= e me
> to repeat, go ahead ! don't be blocked now, start programming and writ= ing
> a manual for your core and it will easily become FC1 (F-CPU Core #1).<= BR>
I'm not up-to-date with all the details of xRISC, so I can't comment on
that, really.  In general I don't see why you'd call an approach which=
is basically KISS should be "too advanced to be widely accepted today&= quot;
(such as a simple (VLIW- ?)RISC processor :)  How should anything be widely accepted today which is not advanced ?  (Ok, I know the answer,= it's
called "marketing").

> 2) ""despite the fact original assumptions behind f-cpu have=
>     proved invalid, the solutions provided have pr= oven too
>     complex to implement.""
> are you speaking about the FC0 or the original projects here ?
> remember that there are months and months of difficult negociations > on this mailing list about the FC0 that you want to completely
> invalidate "just because we don't like your core". come on, = be a grown-up guy.
> you're not forced to spit on what exists just because you feel that we= don't
> understand you. The FC0 is a BIG work, and i don't want to do that eve= ryday
> just because someone else comes with a "super idea".

Yes, I like the manual!  It's well-written and carefully done.  I= t's
even fair on TTA.  (Hey, it's even fair on M2M or else you could have = included
AlphaRISC's comment, something like "you can't kill it twice, job done= ." ;=B0>

Many of the aspects of FC0 are great, including the innovative
functional units you've come up with over time, SIMD, OOO completion, ...
At that point I'm wandering why you stopped there, why you didn't take
it a step further. Ok, ok, it has been explained, the "compilers are n= ot ready"
stuff :=B0(

> the f-cpu is the place to experience with cores, but also a place wher= e
> the ideas are confronted to REALITY. here, you learn the sense of the = words
> "patience" and "compromise".
> An example ? my own ideas are well hidden behind the "RISC" = acronym and
> architecture. I have "reinvested" notions that i had develop= ped alone,
> and they can be easily understood by anyone because it's a "RISC-= like",
> even though some things are "slaughtered". I dislike page me= mory,
> but i have accepted to include it in the FC0 because it would
> be easier to implement today's OS : THAT is a compromise.

IMO the process has to be put down clearly:

- what's the problem _exactly_ ?
- what are possible solutions to the problem ?
- what are the trade-offs involved ?
- why has a particular solution be chosen ?

You've probably done something like this here, I wasn't around for
almost a year, after all, so I can't tell.  It's hard for newcomers to=
accept such compromises if the rationale of the decision making is not
clearly visible and they might expect political compromises rather then
technical ones.

> If you want YOUR
> ideas to be accepted, they have to be "envelopped" around so= mething
> they understand. people don't understand VLIW, people ignore the diffi= culties
> behind it, compilers are not ready yet. This does not mean that you mu= st not
> work on your idea, this means that you have to ADAPT it. it takes time= ,
> but don't worry.

I like you're line of thinking that FC0 may be succeeded by a different
FCx.  I was wandering though, couldn't FC0 be reused as a virtual mach= ine ISA
for a second generation (FC1, or FC2) ?  I only see some points about = the
ISA which are somewhat limiting, such as needing two result buses (e.g. in = case
of SIMD carry) as well as some others.  What I'm saying is that with some changes FC0 could serve as a "we can do it" CPU AND a virtua= l
ISA for the next generation architecture.

I'm still saying, though, that it would be better to test some designs
before deciding on them and putting them in stone (silicon).  IMHO thi= s
holds true for any design, let it be FC0, or a VLIW approach, or even TTA -=
if problems show up we must remain flexible enough to alter our ideas.
IMO pointing out potential problems in advance helps this validation proces= s
so we won't be surprised by low performance chips.

[...]
> i repeat again and again, i don't believe that your arch is bad,
> simply work on it. i even think that the group can help you on technic= al
> matters (implementation, synthesis, fundry) but it is not as mature > as the current FC0.

Good point.

> i'll quote one of my teachers : "that cool what you could do,
> but what can you DO now ?" you have NO ISA, you have almost nothi= ng.

But to be fair, a VLIW core is easier to design then, say, FC0, so
despite the work put in FC0 the lag isn't as severe.  By reusing
a significant portion of work done for FC0, such as FUs, arriving
at FC1 could take much less time then it took us to arrive
at FC0.

> work, Maxx. and don't EVER say that i discourage you, it's up to you t= o
> prove what you claim with facts, pulling others down with you is not a= good
> idea.

So, what could be done to encourage people with ideas for architechtures past FC0 to assemble and line-up behind the FCPU-team, possibly forming
sub-teams investigating other paths, sharing ideas and designs among each other and working towards a common goal in an inspiring and fruitful manner=
in spite of the fact that their ideas may come too late for FC0 ?

Best regards,
kai
3D"where
=
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02761 for ; Fri, 14 Jul 2000 01:39:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 14 Jul 2000 01:39:59 +0200 (MEST) Received: (qmail 11797 invoked by uid 0); 13 Jul 2000 23:10:12 -0000 Received: from ho.egroups.com (208.50.99.200) by mx09.rz2.gmx.net with SMTP; 13 Jul 2000 23:10:12 -0000 X-eGroups-Return: sentto-1101623-439-963529806-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ho.egroups.com with NNFMP; 13 Jul 2000 23:10:11 -0000 Received: (qmail 2739 invoked from network); 13 Jul 2000 22:22:51 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Jul 2000 22:22:51 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 13 Jul 2000 22:22:50 -0000 Received: from f-cpu.org (Raspail-4-97.club-internet.fr [195.36.203.97]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA25890 for ; Fri, 14 Jul 2000 00:22:46 +0200 (MET DST) Message-ID: <396E4109.13F30053@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> <396DAFB2.A48DF99C@hl.siemens.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 00:22:01 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 27f245e052358e78ef209e614a379c4a Status: R X-Status: N hi !

Nicolas Boulay wrote:
> Why not using all what was done for the fc0 ?
it may be unperfect, but at least the specs are ready.

> You can built an vliw processor with the current ISA.
months and months ago (february ?) we talked about having a special
VLIW instruction that describes a packet. it eats up 8 bits
>from a 128-bit packet (or better, 256) but it is interpreted
as a NOP on other machines so the binaries can run anywhere.

> I don't know the optimal lenght, 3 or 4
> ways ? So it's a processor with 3*32b = 96 bits plus maybe some bits to
> manage the bloc.
these bits can be put in a special instruction described above.

> I think that 8 local register is far to few (minus the PC and the stack
> pointer there isn't any more general purpose register ). It's increase
> the probleme with L/S but also the write after read dependancies (you
> should more often reuse registers so you could make more depencies
> between instructions and it's very annoying with long pipeline).
Albert expects that the SMT will reduce this problem.
that's an interesting optimism :-)

> Or you can use a windowed register bank. I know that Whygee didn't like
> this technique at all but this way you can artificially add some
> registers (maybe a rotation of 4 register each function call ?).
even SPARC has a total of 32 registers, with 4 windows made of 8 registers.
and everybody knows it doesn't compete with the monolithic MIPS.
the window management soon reduces or counters the benefits of the window.
look at the IA64... Albert wants statically scheduled code, right ?
there's no better way to assign the registers. the API only increase the
complexity of the generated code.

Two "facts" :
1) EXA (exa.com) runs CFD code on SPARC and MIPS platforms.
with the same clock frequency and overall architecture, MIPS outperforms SPARC.
2) now, SAME CPU (PowerPC) but two compilers : Apple (MAC) and IBM worstation.
IBM outperforms Apple by a factor of 3 because of a better register allocation.
more precisely : IBM's compiler just don't care about the API and uses all
the 32 registers, while Apple respects the POWER API and uses only 16 registers
for the computations.

And now, don't tell me that you'll be happy with 8 regs. i've programmed
enough crap with only 8 regs (x86/MMX) and that's the most shitty CPU i'll
ever program in my life.

> I try to find some threads about windowed register bank but i didn't
> find anything. So, if some people are interrested to give some (good)
> arguments...
well, one argument is : windows are like register block renaming.
instead of renaming each individual reg, you rename a block of 8 regs.
this looks easier but leads to the same thing as normal renaming : you add
some pipeline stages, which invalidates the claims of a "simple pipeline"
because it becomes fat and the clock rate drops. that's why you can't make
both simple and fast. if you're too simple, you can't go fast and vice versa.

i guess that there are other arguments about reg windows but i don't have
much time now.

> nicO

PS: nico, quand tu es en France, appelle-nous pour le meeting sur Paris.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02767 for ; Fri, 14 Jul 2000 01:40:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 14 Jul 2000 01:40:01 +0200 (MEST) Received: (qmail 14854 invoked by uid 0); 13 Jul 2000 23:16:49 -0000 Received: from ci.egroups.com (207.138.41.176) by mx06.rz2.gmx.net with SMTP; 13 Jul 2000 23:16:49 -0000 X-eGroups-Return: sentto-1101623-440-963529881-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.39] by ci.egroups.com with NNFMP; 13 Jul 2000 23:16:46 -0000 Received: (qmail 2767 invoked from network); 13 Jul 2000 22:22:51 -0000 Received: from unknown (10.1.10.27) by m5.onelist.org with QMQP; 13 Jul 2000 22:22:51 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 13 Jul 2000 22:22:51 -0000 Received: from f-cpu.org (Raspail-4-97.club-internet.fr [195.36.203.97]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA20273 for ; Fri, 14 Jul 2000 00:22:45 +0200 (MET DST) Message-ID: <396E4108.7A616958@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 00:22:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f581b386afe7cbb600da4167fdcbc7f4 Status: R X-Status: N hi !

Albert Abramson wrote:
> The latest design from the mind of me is the aforementioned VLIW of 64= bits.
> Here are some useful innovations...
you seem to love this word :-)

> Like the Cray 1,
there you're committing suicide :-) (see above)
why speak about innovation when you copy a design ? (more or less, of cours= e).

> keeps address and data registers separate.
remember that the CRAYs were not intended for "general purpose computi= ng"
and spreadsheet processing. In particular, "pointer chasing" and = stuffs like
that litterally kill your performance. if you're simply doing a DSP, it's o= k,
but if you're going to run games or other IA-powered applications, you'll burn your CPI artificially.

>  Aside from the aforementioned register shortage (8 local, 8 glob= al),
> handling addresses separately (always unsigned integers) keeps hardwar= e
> simpler.
that is an interesting thing. it's the same argument as for the alpha,
with its separated register set (FP/int). then later (21264) they used a hu= ge
monolithic register set with register renaming. so why bother about such problems which proved false ?

with a "logically unified" register set, you are not forced to ke= ep
everything at one place only. for example, in the L/SU and the fetcher,
i use "shadow" registers for faster memory access.

>  Fewer operations actually work on the address registers, so the = hardware
> is simplified.
if i can notice something, you make a mistake here : you don't make a diffe= rence
between a logical and a physical architecture. ok, i know, when you want something both simple and efficient, you're forced to lay everything down to one layer only. but we can't live on a "throwable ISA" and we = have to
determine what is done independently from how it is done. "langage is = not
semantics". so what you think is simpler under-utilizes some units at<= BR> any time : what if you don't use pointers during a certain time ? and
what if you don't compute something else ? when you buy a CRAY, you're mean= t
to have enough money to don't care about under-utilized units in a machine<= BR> which counts thousands of ASICs. In a CPU, the problem is different :
it is a single chip and every transistor has to be used, otherwise it must = be
thrown away. a CRAY is not a microprocessor, and i think that we're doing a microprocessor, no ?

CRAYs are not the only example of split address/data register set (68K). but on a general purpose CPU this artificially reduces the total amount
of usable registers (look at my comment of IBM vs Apple on PowerPC).

> -Since there are separate address and data registers, and global and > local sets, we gain access to a total of 32 registers.
ok but how do you access them all linearly ?

>  In addition, data registers are 128 bits wide (and may be expand= ed further)
> packing many operands into one register.
one word, four letters : SIMD. do you call that innovation ? :-)

> -Four condition bits are added to each data register.
there it's getting interesting :-) looks like what is done on the FC0 !
except that we have "zero", "LSB" and "MSB".<= BR>
>  One for LT, GT, EQ, and Update.  This makes for more effici= ent
> message passing, as a single register (for example, a global)
> can read the contents of a register to determine whether or not
> its contents are updated or a stale value.  The results of compar= isons
> can then be seen just by reading these bits.  Moreover cmovs and = cbranches
> become much more powerful, allowing all sorts of complex decision maki= ng
> to be folded into a single operation.
in practice, it's not used much. but it's better than nothing.

> Since the first design does not take multithreading into account yet,<= BR> ? i thougt it was your only "raison d'=EAtre" ?

> we get to avoid the intracacies of branch-on-miss, managing stacks
> of threads, allocating global registers, fine/coarse-grain parallelism= ,
> message passing, and memory protection.
heh. there's nothing for free in this world. now, i think that you understa= nd
why CPUs are getting so comple :-)

> > the question is to be put differently, because things are not bla= ck or white,
> > but complex and interleaved. In the beginning, that may be the fi= rst idea :
> > static, simple EU, highly parallel, 256-bit instruction words. > >
> > but look at the problems it causes : with roughly 8 instructions = per word,
> > the register set EXPLODES ! it requires at least 8 write ports an= d 16 read ports.
> > heh.
> > look at the IBM protos and see how they struggle to exceed 30 MHz= with TTL parts :-)
>
> That's why I'm suggesting narrow VLIW.  Perhaps a different name?=   NSVLIW?

        L    OO  L         L   O  O L
        LLL  OO  LLL

i wrote previously that we needed a new name, RISC and now VLIW (thanks to = the joint
efforts of Intel and Albert) have lost any common sense.

maybe you don't understand the acronym : VLIW means "Very Large Instru= ction Word".
it's meant to be at least 256 bits, a lot of explicitly emitted instruction= s (at least 8)
in one cycle. it puts a lot of pressure on the instruction scheduling and t= hat was all
the point.

now what you propose is 3-way VLIW ??? the PowerPC does that, Alpha does 4 = decodes,
and we call that ... superscalar. so, any name with "superscalar"= and without "VLIW" would
be ok, like "explicitly scheduled superscalar CPU" or something l= ike that. but "narrow VLIW"
sounds as funny as "tiny giant".

</laugh>

i hope that you don't take offense of this, but this was really amusing.
> Point being that it's really hard to consistantly issue more than two = or three instructions
> per cycle.  Counting memory latency, no one is even getting bette= r than .55 on well optimized
> code.
hey, it depends on WHAT code ...
there are some mathematical approximations (Newton-Raphson for divide and s= qrt) that take
tens of clock cycles. OTOH there are codes that do only access memory (bitb= lt or blkmov).

>  The largest OOO windows, the best branch prediction, and the wid= est issue still don't
> get us down to .50.  Only multithreading offers that possibility,= and it does it without
> so much of the clock penalty.
yet i'd like to see your implementation.

> Still, a three issue design isn't so bad.
Intel does the same, so why be afraid ? :-)

>  It's as good as G3, anyway;
but less than 21264 :-P
if you want to see a more or less "real VLIW", look at the TMS320= C6xx.
8-issue...

> and we don't have to tear our hair out trying to get another instructi= on done every
> cycle.  ILP isn't worth pursuing at the expense of all else. = ; VLIW is useful because
> it allows much higher clock rates to be obtained.
this last argument is false : clock rate only depends on the critical datap= ath.
it's up to you then to balance your datapath, but clock rate does not depen= d on other
things. don't over-generalize...

>  If it is compromised for very wide issue, and you just end up wi= th a lower clock rate.
>  You can't get a good CPI on software scheduled processors, not u= ntil dynamic optimization
> software comes into its own.
i'm not sure to understand what you mean by "software scheduled proces= sors". at runtime
or compile time ? i guess that you're refering to the second one.

> > and then, they dare to ask for more performance ;-
> The client -- our end customer -- wants the best performance he can ge= t.
add to that : the best price/performance for the money he can spend.
otherwise you simply buy a NEC SX-5.

> However, for the really computationally intensive stuff, VLIW works be= cause it doesn't
> waste hardware with decode and checking and dynamic rescheduling and a= ll of those other
> horrible things that do no useful work.
here, you got to the right point : "do the work".
do windowed registers DO the work ? nah...
does a separate register file DO the work ? neither...
but sometimes we have to make compromises, or we wouldn't fetch the instruc= tions at all :-D

> Now, these are ideas.  Do they have to be accompanied by a whole = instruction set?
> Do we have 16 instructions or 160?  Who knows, we just look at ea= ch one.  The point
> is, we can prove feasability of individual concepts or argue instructi= ons set mixes
> and poke holes in people's ideas.  I prefer to explore feasibilit= y.
cool :-)

>  Compilers deliberately put work together that can issue in paral= lel, so
> bundling them into one word doesn't sound like too much extra work to = me.
do it by hand first...

>  Getting compilers to speculatively schedule work that might be > useful into one static stream is much tougher, and the functionality > involved in doing so usually hurts the clock rate too much anyway.
???

>  The problem with trying to issue lots of instructions at one tim= e
> -- even if you can do it -- is that the hardware actually slows down > to accomodate everything.
euh... here i don't get it.

> > hum... he has not even decided about the packet size and the numb= er of
> > registers. even though he can make something within a night, he w= on't gain
> > much experience from it. The FC0 took a LONG time to appear and e= ach point
> > (number of registers, size of the instruction field etc) was the = subject of
> > a long debate. the endian debate, for example... gawd...
> In other words, VLIW isn't that hard.  One could even make a VLIW= version of FCO.
so what are you complaining about ?

>  It just means that whatever work is going to move forward in one= cycle is written
> out explicitly in one Very Long Instruction Word.  Since use of t= he wider registers
> depends on a recompile, what the hey!
let me tell you that the difficulty was NOT about the architecture itself b= ut about
the ISA and the available features. the endianness has nothing to do with t= he way
the instructions are emited. same for a lot of different details. i guess t= hat you
misunderstood why i said the FC0 was difficult work. the same kind of discu= ssions
occured as here : how many registers, what memory access schemes, how to fl= ush
the register set, what to do when an interrupt comes, etc etc. We only scra= tched
to surface of your xRISC, while the FC0 is already ok, and the debates were=
so tough that i don't want to fight again like i did, EVEN if it's not the = best CPU ever.

> Issues like packet size and register size and instruction mix should b= e
> saved until simulations can be run.
are you volunteering for writing the simulator ? cool ! :-)

> > >  By reusing a significant portion of work done for FC0,= such as FUs, arriving
> > > at FC1 could take much less time then it took us to arrive a= t FC0.
> > i agree. that's why, in order to reduce the amount of debates and= work,
> > Albert should reuse most of the f-cpu characteristics. he's not f= orced
> > to reuse EVERYTHING, he has the choice to select what's ok for hi= m and what's not,
> > but the "core instruction set" is a good starting point= . there are also
> > free opcodes for explicit register renaming or explicit thread ma= nagement.
> > enhancement ideas are also welcome and can be reused in the FC0.<= BR> > I don't really like the instruction set for f-cpu as it stands.
it's a compromise that was long to find, so if you're unhappy, reread the w= hole
email archive.

>  That was one of my first criticisms of the existing architecture= .  The instruction
> set I came up with for xRISC a while back was only 30 instructions or = so, and much
> more effective than f-cpu's less than orthogonal set.
remember that it's roughly the number of opcodes for the first MIPS and SPA= RCs.
now, they have XXX much more opcodes...

> --Maxx
>
> hey, Kai, maybe we should just split off on this VLIW/xRISC thing and = see what comes of it... eh?
do whatever you want, it's your freedom of yours, as long as you respect ot= her's freedom
as well as their work. i'm willing to help, you know it (i hope) as long as= criticisms are
constructive.

>  I know I could have something done in VLIW in less time it has t= aken
> to get "permission" from Yawn "WHYMEE" Guidon.
you don't need any permission of any kind : just be sure to stand the respo= nsibility you take.
the f-cpu project is a LOT of personal involvement and leaving in the middl= e is not seen as
a good/fair practice. if you want to start working on the FC1 inside of the= f-cpu project,
i guess that nobody will disagree. you can make a poll, just in case :-)
have fun with your tiny giants,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D"where
=
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00348 for ; Sun, 16 Jul 2000 21:49:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:10 +0200 (MEST) Received: (qmail 31049 invoked by uid 0); 14 Jul 2000 16:31:02 -0000 Received: from hi.egroups.com (208.50.99.211) by mx02.gmx.net with SMTP; 14 Jul 2000 16:31:02 -0000 X-eGroups-Return: sentto-1101623-441-963583948-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 14 Jul 2000 14:15:24 -0000 Received: (qmail 19501 invoked from network); 14 Jul 2000 14:12:26 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 14 Jul 2000 14:12:26 -0000 Received: from unknown (HELO david.siemens.de) (192.35.17.14) by mta1 with SMTP; 14 Jul 2000 14:12:25 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e6EECOR00987 for ; Fri, 14 Jul 2000 16:12:24 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6EECNb03849 for ; Fri, 14 Jul 2000 16:12:23 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id QAA11690 for ; Fri, 14 Jul 2000 16:12:23 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id QAA10858 for ; Fri, 14 Jul 2000 16:12:21 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <396F1FC6.1F18640D@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> <396DAFB2.A48DF99C@hl.siemens.de> <396E4109.13F30053@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 16:12:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd10b0b5f580ccc3dbab169fdbb2805c Status: R X-Status: N Yann Guidon wrote:
>
> hi !
>
> Nicolas Boulay wrote:
> > Why not using all what was done for the fc0 ?
> it may be unperfect, but at least the specs are ready.
>
> > You can built an vliw processor with the current ISA.
> months and months ago (february ?) we talked about having a special
> VLIW instruction that describes a packet. it eats up 8 bits
> from a 128-bit packet (or better, 256) but it is interpreted
> as a NOP on other machines so the binaries can run anywhere.
>

The advantages is to better manage bloc without dependancies but don't
you think, that it could be more complicated to have this
none-fixed-size bloc to implement. And small blocks (3-5 instructions)
will explod the size of the code. But you can keep this instruction to
describe block of 3-ways instructions.

> > I don't know the optimal lenght, 3 or 4
> > ways ? So it's a processor with 3*32b = 96 bits plus maybe some bits to
> > manage the bloc.
> these bits can be put in a special instruction described above.
>
> > I think that 8 local register is far to few (minus the PC and the stack
> > pointer there isn't any more general purpose register ). It's increase
> > the probleme with L/S but also the write after read dependancies (you
> > should more often reuse registers so you could make more depencies
> > between instructions and it's very annoying with long pipeline).
> Albert expects that the SMT will reduce this problem.
> that's an interesting optimism :-)
>
> > Or you can use a windowed register bank. I know that Whygee didn't like
> > this technique at all but this way you can artificially add some
> > registers (maybe a rotation of 4 register each function call ?).
> even SPARC has a total of 32 registers, with 4 windows made of 8 registers.

No Sparc has 256 registers but the code see 32 registers.

> and everybody knows it doesn't compete with the monolithic MIPS.
> the window management soon reduces or counters the benefits of the window.
> look at the IA64... Albert wants statically scheduled code, right ?
> there's no better way to assign the registers. the API only increase the
> complexity of the generated code.
>
> Two "facts" :
> 1) EXA (exa.com) runs CFD code on SPARC and MIPS platforms.
> with the same clock frequency and overall architecture, MIPS outperforms SPARC.
> 2) now, SAME CPU (PowerPC) but two compilers : Apple (MAC) and IBM worstation.
> IBM outperforms Apple by a factor of 3 because of a better register allocation.
> more precisely : IBM's compiler just don't care about the API and uses all
> the 32 registers, while Apple respects the POWER API and uses only 16 registers
> for the computations.
>
> And now, don't tell me that you'll be happy with 8 regs. i've programmed
> enough crap with only 8 regs (x86/MMX) and that's the most shitty CPU i'll
> ever program in my life.
>

I never said how many register to see in the same times. 64 is a good
number, but we can have 256 or more register. And each function call the
window move to 8 or 16 registers. So you can have more register for your
program than with a fixed number of register.

> > I try to find some threads about windowed register bank but i didn't
> > find anything. So, if some people are interrested to give some (good)
> > arguments...
> well, one argument is : windows are like register block renaming.
> instead of renaming each individual reg, you rename a block of 8 regs.
> this looks easier but leads to the same thing as normal renaming : you add
> some pipeline stages, which invalidates the claims of a "simple pipeline"
> because it becomes fat and the clock rate drops. that's why you can't make
> both simple and fast. if you're too simple, you can't go fast and vice versa.
>
> i guess that there are other arguments about reg windows but i don't have
> much time now.
>
It's "just" a translation of the address of the register.
> > nicO
>
> PS: nico, quand tu es en France, appelle-nous pour le meeting sur Paris.
>
> WHYGEE
nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00354 for ; Sun, 16 Jul 2000 21:49:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:11 +0200 (MEST) Received: (qmail 17499 invoked by uid 0); 14 Jul 2000 17:48:46 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 14 Jul 2000 17:48:46 -0000 X-eGroups-Return: sentto-1101623-443-963596841-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 14 Jul 2000 17:48:44 -0000 Received: (qmail 22363 invoked from network); 14 Jul 2000 17:45:32 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 14 Jul 2000 17:45:32 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 14 Jul 2000 17:45:32 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6EHkuS02116; Fri, 14 Jul 2000 13:46:56 -0400 Message-Id: <200007141746.e6EHkuS02116@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu@egroups.com From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 13:46:56 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] I'm back Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8adc156dc1fc630f0b69419efdc2463d Status: R X-Status: N Okay... I'm seeing arguments about simplicity, style, etc.  Good.
Now can anyone fill me in in 25 words on where this is going?
I've finally found employment and will be able to participate clear of worries about bills, etc.

Rares



Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00357 for ; Sun, 16 Jul 2000 21:49:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:12 +0200 (MEST) Received: (qmail 11043 invoked by uid 0); 14 Jul 2000 17:50:33 -0000 Received: from hn.egroups.com (208.50.99.199) by mx02.gmx.net with SMTP; 14 Jul 2000 17:50:33 -0000 X-eGroups-Return: sentto-1101623-442-963595204-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 14 Jul 2000 17:20:19 -0000 Received: (qmail 4582 invoked from network); 14 Jul 2000 17:18:30 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 14 Jul 2000 17:18:30 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 14 Jul 2000 17:18:28 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id OAA09432 for ; Fri, 14 Jul 2000 14:25:20 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39681EBE.10217@bjsmtp1.163.net> <396DAFB2.A48DF99C@hl.siemens.de> <396E4109.13F30053@f-cpu.org> In-Reply-To: <396E4109.13F30053@f-cpu.org> Message-Id: <00071414122901.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 13:54:23 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 802f1264177378d17a2f0ef96a758a3d Status: R X-Status: N On Thu, 13 Jul 2000, Yann Guidon wrote:
> even SPARC has a total of 32 registers, with 4 windows made of 8 registers.
> and everybody knows it doesn't compete with the monolithic MIPS.
> the window management soon reduces or counters the benefits of the window.
> look at the IA64... Albert wants statically scheduled code, right ?
> there's no better way to assign the registers. the API only increase the
> complexity of the generated code.

Sorry - I just couldn't let that pass. Each register window on a Sparc
has 32 logical registers, typical implementations have 192 or more
physical registers. They are mapped as follows:

     0 to 7  are the incoming registers
     8 to 15 are the local register
     16 to 23 are the outgoing registers
      24 to 31 are the global registers

When the window "slides", the global registers remain as they were
while the outgoing registers become the new incoming registers. So to
the program this is no more restrictive than what the MIPS has. One
problem that plagued the Sparc until version 9 (UltraSparc) was that
when you wanted to slide the window and you had run out of physical
registers you got a trap into the OS to spill some registers to the
main memory. This trap was slooooooooow.

Another reason MIPS tended to be faster the Sparcs was that the MIPS
guys would license the optimized layout for their chips, while the
Sparc people would license Verilog descriptions so each client could
synthesize their own layout. The latter approach gives the client more
options in terms of fabrication process, but will result in slower
chips unless the client is willing to put in a lot of effort.

-- Jecel
P.S.: in my own cpu design I use 16 threads and schedule them in such a
way as to totally hide the pipeline from the branch instruction.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00366 for ; Sun, 16 Jul 2000 21:49:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:15 +0200 (MEST) Received: (qmail 10059 invoked by uid 0); 14 Jul 2000 18:44:22 -0000 Received: from ch.egroups.com (208.50.99.226) by mx02.gmx.net with SMTP; 14 Jul 2000 18:44:22 -0000 X-eGroups-Return: sentto-1101623-444-963600248-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.39] by ch.egroups.com with NNFMP; 14 Jul 2000 18:44:21 -0000 Received: (qmail 12294 invoked from network); 14 Jul 2000 18:44:07 -0000 Received: from unknown (10.1.10.27) by m5.onelist.org with QMQP; 14 Jul 2000 18:44:07 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 14 Jul 2000 18:44:07 -0000 Received: from f-cpu.org (Raspail-2-243.club-internet.fr [195.36.192.243]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA14291 for ; Fri, 14 Jul 2000 20:44:04 +0200 (MET DST) Message-ID: <396F5F51.50B761E4@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396DAFB2.A48DF99C@hl.siemens.de> <396E4109.13F30053@f-cpu.org> <00071414122901.00382@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 20:43:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9a2fd258539e4bedd749562163a7fa01 Status: R X-Status: N hi !

Jecel Assumpcao Jr wrote:
> On Thu, 13 Jul 2000, Yann Guidon wrote:
> > even SPARC has a total of 32 registers, with 4 windows made of 8 registers.
> > and everybody knows it doesn't compete with the monolithic MIPS.
> > the window management soon reduces or counters the benefits of the window.
> > look at the IA64... Albert wants statically scheduled code, right ?
> > there's no better way to assign the registers. the API only increase the
> > complexity of the generated code.
>
> Sorry - I just couldn't let that pass. Each register window on a Sparc
> has 32 logical registers, typical implementations have 192 or more
> physical registers. They are mapped as follows:
>
>      0 to 7  are the incoming registers
>      8 to 15 are the local register
>      16 to 23 are the outgoing registers
>       24 to 31 are the global registers

ok i know and i'm sorry for the partial over-simplification.
i had no time to teach everyone how a SPARC is made (and i'm not the
right guy for this). accept my apologies. you could also explain how
the windows overlap etc. so we can understand that, unless you code by
hand and forget the API, you can't use all the 32 registers (otherwise
you have to call a subroutine into the subroutine, which is unnecessary).

You know that my opinion is : the more register the better. more registers
means deeper and more pipelines, with less memory accesses, but unless you
can explicitely address one window with a special instruction (like :
"now, slide to window #564") you have a lot of difficulties with windowed
registers. And no, my concern is not about running faster Netscape or
Staroffice.

> When the window "slides", the global registers remain as they were
> while the outgoing registers become the new incoming registers. So to
> the program this is no more restrictive than what the MIPS has.
this is : if you want to use all your 192 registers (or whatever your
chip has) you have to manually "slide" the window, that is : make a
function call. and unless you need no argument, you have 8 registers
that are dangling (unless you really have a very, very smart compiler,
but i never believe in compilers anyway). SPARC has been designed for
fast function call and return in C and LISP environment, that's all.

> One problem that plagued the Sparc until version 9 (UltraSparc) was that
> when you wanted to slide the window and you had run out of physical
> registers you got a trap into the OS to spill some registers to the
> main memory. This trap was slooooooooow.
heh. and what solution have they found ?

> Another reason MIPS tended to be faster the Sparcs was that the MIPS
> guys would license the optimized layout for their chips, while the
> Sparc people would license Verilog descriptions so each client could
> synthesize their own layout. The latter approach gives the client more
> options in terms of fabrication process, but will result in slower
> chips unless the client is willing to put in a lot of effort.

hum, that could be a reason, but i won't engage myself into this debate.
i gotta eat and watch the fireworks :-)

have fun,

> -- Jecel
> P.S.: in my own cpu design I use 16 threads and schedule them in such a
> way as to totally hide the pipeline from the branch instruction.
do you have any C sim ? or VHDL model ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00369 for ; Sun, 16 Jul 2000 21:49:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:16 +0200 (MEST) Received: (qmail 32176 invoked by uid 0); 14 Jul 2000 18:45:57 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 14 Jul 2000 18:45:57 -0000 X-eGroups-Return: sentto-1101623-445-963600251-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 14 Jul 2000 18:45:15 -0000 Received: (qmail 5137 invoked from network); 14 Jul 2000 18:44:10 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 14 Jul 2000 18:44:10 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 14 Jul 2000 18:44:10 -0000 Received: from f-cpu.org (Raspail-2-243.club-internet.fr [195.36.192.243]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA18205 for ; Fri, 14 Jul 2000 20:44:08 +0200 (MET DST) Message-ID: <396F5F53.80D47130@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007141746.e6EHkuS02116@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 20:43:31 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I'm back Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 05a2c275a5507fcf0ddf7128515a4aa4 Status: R X-Status: N hi Rares !

welcome back :-)

Rares Marian wrote:
> Okay... I'm seeing arguments about simplicity, style, etc.  Good.
OTOH i would like to see a chip... :-)

> Now can anyone fill me in in 25 words on where this is going?
i won't. i don't want to seem partial :-)
anyway, the great f-cpu whell turns and there comes again "someone with a super idea"
(i know, i was one of those before...). 6 months ago, that would happen every month...

> I've finally found employment and will be able to participate clear of worries about bills, etc.
what will you do for us ? :-)
what has your other OS project become ?
have you seen other eastcoasters in the last 6 months ?

> Rares
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00372 for ; Sun, 16 Jul 2000 21:49:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:16 +0200 (MEST) Received: (qmail 2926 invoked by uid 0); 14 Jul 2000 19:08:04 -0000 Received: from mo.egroups.com (207.138.41.166) by mx02.gmx.net with SMTP; 14 Jul 2000 19:08:04 -0000 X-eGroups-Return: sentto-1101623-446-963601666-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 14 Jul 2000 19:08:03 -0000 Received: (qmail 12441 invoked from network); 14 Jul 2000 19:07:45 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 14 Jul 2000 19:07:45 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 14 Jul 2000 19:07:45 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6EJ99x08889; Fri, 14 Jul 2000 15:09:09 -0400 Message-Id: <200007141909.e6EJ99x08889@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 15:09:09 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I'm back Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a3380f442d93f36bcb189b58ba5a10aa Status: R X-Status: N Yann Guidon <whygee@f-cpu.org> wrote:

>hi Rares !
>
>welcome back :-)
>
>Rares Marian wrote:
>> Okay... I'm seeing arguments about simplicity, style, etc.  Good.
>OTOH i would like to see a chip... :-)

Yep.

>> Now can anyone fill me in in 25 words on where this is going?
>i won't. i don't want to seem partial :-)
>anyway, the great f-cpu whell turns and there comes again "someone with a super idea"
>(i know, i was one of those before...). 6 months ago, that would happen every month...

Well I've become more sane in the past few months so you won't see any freaky ideas from me.  Just simpliciticity.

>> I've finally found employment and will be able to participate clear of worries about bills, etc.
>what will you do for us ? :-)

Turn this dark cloud of technophobia around.  I don't know how bad the phobia is in Europe, but it's frightening how scared people are in the United States.

So expect a few FPGA based kids' toys.  If there's one in every house it's going to be harder to make up bullshit news articles.

I'm also close to solving two $1Million contests. :)

>what has your other OS project become ?

Well we're awaiting the release of a better contender (me I'm waiting for my AmigaSDK).  Oh and my new Athlon is going to be great for compiling etc.

I'm well on my way with Gnu FS Manager you'll see soon.

>have you seen other eastcoasters in the last 6 months ?

We talk alot but no visits.  no point really I got into the college in Massachussetts, so I'll be within a 90 minutes of Nate and within 5-10 minutes of every geek in MA (there's hundreds of them :) ).

>> Rares
>WHYGEE
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
>SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
>------------------------------------------------------------------------
>Get great brand name shoes with just the click of a mouse. Check out
>the huge selection at Zappos.com, the Web's Most Popular Store!
>http://click.egroups.com/1/6994/1/_/3462/_/963600251/
>------------------------------------------------------------------------
>
>


Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00375 for ; Sun, 16 Jul 2000 21:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:17 +0200 (MEST) Received: (qmail 2792 invoked by uid 0); 14 Jul 2000 20:01:35 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 14 Jul 2000 20:01:35 -0000 X-eGroups-Return: sentto-1101623-447-963604882-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 14 Jul 2000 20:01:32 -0000 Received: (qmail 9539 invoked from network); 14 Jul 2000 20:01:21 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 14 Jul 2000 20:01:21 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 14 Jul 2000 20:01:15 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id RAA09858 for ; Fri, 14 Jul 2000 17:08:04 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39681EBE.10217@bjsmtp1.163.net> <00071414122901.00382@gandalf> <396F5F51.50B761E4@f-cpu.org> In-Reply-To: <396F5F51.50B761E4@f-cpu.org> Message-Id: <00071416551003.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 16:19:50 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] windows and threads (was: VLIW 64) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 13f1f8890cbc945bfc612f5ad4e712e1 Status: R X-Status: N Yann Guidon wrote:
> ok i know and i'm sorry for the partial over-simplification.
> i had no time to teach everyone how a SPARC is made (and i'm not the
> right guy for this). accept my apologies. you could also explain how
> the windows overlap etc. so we can understand that, unless you code by
> hand and forget the API, you can't use all the 32 registers (otherwise
> you have to call a subroutine into the subroutine, which is unnecessary).

You can't use all 32 registers in a MIPS or all 16 registers in an ARM
unless you code by hand. So?
 
> You know that my opinion is : the more register the better. more registers
> means deeper and more pipelines, with less memory accesses, but unless you
> can explicitely address one window with a special instruction (like :
> "now, slide to window #564") you have a lot of difficulties with windowed
> registers. And no, my concern is not about running faster Netscape or
> Staroffice.

Do you know the old AMD 29K processor? You could address any register
directly or use a kind of register window, depending on what you wanted
to do.

I have a problem with a large, flat register space. The Philips
Trimedia has 128 registers (this is probably the most popular VLIW chip
ever made, so I would encourage people interested in this kind of
architecture to look into it:
http://www-us.semiconductors.philips.com/trimedia/) which is great when
your compiler has unrolled a lot of loops and inlined a lot of
subroutines, but how do you deal with them when you have to switch
contexts?

> > [...] This trap was slooooooooow.
> heh. and what solution have they found ?

They made the trap fast :-)

Really - it was just a matter of letting the handler run in user mode
instead of supervisor mode.

> > [MIPS = hard core, Sparc = soft core]
>
> hum, that could be a reason, but i won't engage myself into this debate.
> i gotta eat and watch the fireworks :-)

Good choice. But I would like to repeat this once more since I think it
is very important for this project. Look at what Chuck Moore did with
his MISC Forth chips (http://www.ultratechnology.com/) - he got them to
run at up to 800 MHz with a 0.8 micron process. Most people had
problems getting more than 50 MHz with this technology! You will never
get anything like this compiling from a VHDL design. As always, there
is a price to pay. His design is simple and can't scale, and he even
has problems when moving from one production line to another in a given
factory.

> > P.S.: in my own cpu design I use 16 threads and schedule them in such a
> > way as to totally hide the pipeline from the branch instruction.
> do you have any C sim ? or VHDL model ?

Sorry - I use Self (a Smalltalk dialect) as my HDL. But the
architecture is simple enough that I could write a simulator in C very
quickly. It is, however, very software intensive like the Transmeta
Crusoe. The internal architecture is a four bus MOVE (TTA) processor,
but the external architecture is a bytecoded stack machine (Self, but
could be Smalltalk or Java for those who prefer these languages). You
can see the board level design at

    http://www.merlintec.com/merlin6/e_main.html

The pipeline is:

       1) output address to cache SRAMs
       2) ---
       3) latch data (4 move instructions) from SRAMs
       4) MOVE

If one of the MOVE instructions changes the contents of the PC, then it
will effect only the instruction that will be executed 4 clocks later.
The would mean I would have to deal with 3 "delay slots", most likely
meaning 12 NOPs in a row :-(

The scheduler puts out a 4 bit thread number in every cycle. This
number is combined with the instruction bits to generate the actual
register addresses: if the thread is 3 and it wants to read register 6,
then it would actually read register 0x36. There are no shared
registers between threads.

Once a scheduler assigns a given thread on a certain clock, it won't
schedule that same thread again for the next 3 clocks. So to some
thread it looks as if the very next instruction after it changed the PC
is the one it requested. This makes life so much easier for the "code
morpher".

-- Jecel
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00381 for ; Sun, 16 Jul 2000 21:49:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:20 +0200 (MEST) Received: (qmail 8370 invoked by uid 0); 14 Jul 2000 20:56:35 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 14 Jul 2000 20:56:35 -0000 X-eGroups-Return: sentto-1101623-448-963608177-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 14 Jul 2000 20:56:27 -0000 Received: (qmail 11068 invoked from network); 14 Jul 2000 20:56:16 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 14 Jul 2000 20:56:16 -0000 Received: from unknown (HELO strawberry.raspberrymedia.com) (206.184.14.85) by mta1 with SMTP; 14 Jul 2000 20:56:16 -0000 Received: from cichon.com (strawberry.raspberrymedia.com [206.184.14.85]) by strawberry.raspberrymedia.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA05582 for ; Fri, 14 Jul 2000 13:54:30 -0700 Sender: gordon@strawberry.raspberrymedia.com Message-ID: <396F802D.CC560238@cichon.com> X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <00071414122901.00382@gandalf> <396F5F51.50B761E4@f-cpu.org> <00071416551003.00382@gandalf> From: "Gordon F. Cichon" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 23:03:41 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] windows and threads (was: VLIW 64) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7242e25b19b5df578e89261318e3530e Status: R X-Status: N have your every thought about why Merced does not get to its
performance?
Here's my explanation: Because it has too large a register file. (among
others)
A register bank of n registers creates a routing overhead inside a chip
for the crossbar interconnect of n^2. And for a certain size n, this
hurts.

And a word about Sparc: The register windows are really broken!
Nice idea to have a nice register stack inside the cpu and avoiding
using the real stack in memory for subroutine calls.
However, every on chip register stack eventually overflows.
Conlusion: You have to reserve memory to store these registers on the
ordinary stack anyway. And if you do it anyway, you can also do it
transperently with a stack cache, like many i386 clones do. And if you
don't do it, you could at least save the registers in the stack frame of
the subroutine the registers belong to, and not the next one as by
Sparc.

In this sense, I think ARM with its 16 registers is a quite good design.
And I think even Intel appreciates that.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00384 for ; Sun, 16 Jul 2000 21:49:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:20 +0200 (MEST) Received: (qmail 10370 invoked by uid 0); 14 Jul 2000 21:14:00 -0000 Received: from fl.egroups.com (208.50.144.74) by mx06.rz2.gmx.net with SMTP; 14 Jul 2000 21:14:00 -0000 X-eGroups-Return: sentto-1101623-449-963609230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 14 Jul 2000 21:13:58 -0000 Received: (qmail 18636 invoked from network); 14 Jul 2000 21:13:50 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 14 Jul 2000 21:13:50 -0000 Received: from unknown (HELO wn1.sci.kun.nl) (131.174.8.1) by mta1 with SMTP; 14 Jul 2000 21:13:49 -0000 Received: from studs3.sci.kun.nl by wn1.sci.kun.nl via studs3.sci.kun.nl [131.174.124.4] with ESMTP for id XAA27054 (8.8.8/3.29); Fri, 14 Jul 2000 23:13:48 +0200 (MET DST) To: f-cpu@egroups.com In-Reply-To: <396F5F51.50B761E4@f-cpu.org> Message-ID: From: Arthur van Leeuwen MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 23:13:48 +0200 (MET DST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 107aae2bd8986fe3259fbdd2eb7fa238 Status: R X-Status: N On Fri, 14 Jul 2000, Yann Guidon wrote:

> hi !

And hello.

> Jecel Assumpcao Jr wrote:
> > On Thu, 13 Jul 2000, Yann Guidon wrote:
> > > even SPARC has a total of 32 registers, with 4 windows made of 8 registers.

[snip]
> >
> > Sorry - I just couldn't let that pass. Each register window on a Sparc
> > has 32 logical registers, typical implementations have 192 or more
> > physical registers. They are mapped as follows:
> >
> >      0 to 7  are the incoming registers
> >      8 to 15 are the local register
> >      16 to 23 are the outgoing registers
> >       24 to 31 are the global registers

> ok i know and i'm sorry for the partial over-simplification.
> i had no time to teach everyone how a SPARC is made (and i'm not the
> right guy for this). accept my apologies. you could also explain how
> the windows overlap etc. so we can understand that, unless you code by
> hand and forget the API, you can't use all the 32 registers (otherwise
> you have to call a subroutine into the subroutine, which is unnecessary).

Well... actually... you can use all 32 registers. But you'll have to fix
them up right to conform to the calling convention upon call or return.
This, ofcourse, incurs a performance penalty. Which is why the sliding
register windows are not as useful as they were supposed to be.

> > When the window "slides", the global registers remain as they were
> > while the outgoing registers become the new incoming registers. So to
> > the program this is no more restrictive than what the MIPS has.
> this is : if you want to use all your 192 registers (or whatever your
> chip has) you have to manually "slide" the window, that is : make a
> function call. and unless you need no argument, you have 8 registers
> that are dangling (unless you really have a very, very smart compiler,
> but i never believe in compilers anyway). SPARC has been designed for
> fast function call and return in C and LISP environment, that's all.

I have a few gripes here: you do not need 192 registers. Really. See
Hennessy&Patterson. There's a graph in there somewhere (sorry, don't own the
book and it has been slightly over a year since last reading it) that charts
performance increase scheduled against number of registers. This chart
really drops low beyond 16 registers.

The second gripe is with you not believing in compilers. I have yet to see a
compiler that does in fact optimize and does not do better than I would do
naively translating from naive high level code. And when you are at the level
of algorithms, changing algorithms does a lot more than wringing out every
last cycle by hand. Not that there's no place for that... mind you, there
is. Just not in most workstation code.

Doei, Arthur. (Great believer in compiler technology. Let the computer do
               the dumb work.)

--
  /\    /  |             Fight Scientology, See URL: http://xenu.xtdnet.nl/ |
/__\  /   | Buttons. Lotsa buttons. I like buttons. [Big Dog]              |
/    \/__  | A friend is someone with whom you can dare to Be yourself.     |
Just Be   +-Arthur van Leeuwen, arthurvl@sci.kun.nl------------------------+
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00405 for ; Sun, 16 Jul 2000 21:49:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:28 +0200 (MEST) Received: (qmail 2149 invoked by uid 0); 15 Jul 2000 00:13:43 -0000 Received: from fl.egroups.com (208.50.144.74) by mx02.gmx.net with SMTP; 15 Jul 2000 00:13:43 -0000 X-eGroups-Return: sentto-1101623-451-963620016-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 15 Jul 2000 00:13:39 -0000 Received: (qmail 21234 invoked from network); 15 Jul 2000 00:13:36 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 15 Jul 2000 00:13:36 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 15 Jul 2000 00:13:36 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000715001335.SBIV24904.mail.rdc1.wa.home.com@nventure.com> for ; Fri, 14 Jul 2000 17:13:35 -0700 Message-ID: <396FACAF.F98483FB@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> <396E4108.7A616958@f-cpu.org> <396FA489.76DBD3F9@nventure.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 17:13:38 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64; remarks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ed60fd51d777eca504d456de951ee90e Status: R X-Status: N I apologize to everyone on this list for that last e-mail.  I was
despondent about a pattern of responses from Whygee that I did not feel
were leading to anything productive.  I was frustrated, and I'm sorry to
have brought everyone else into that.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00408 for ; Sun, 16 Jul 2000 21:49:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:29 +0200 (MEST) Received: (qmail 11892 invoked by uid 0); 15 Jul 2000 00:29:33 -0000 Received: from ml.egroups.com (208.50.99.214) by mx02.gmx.net with SMTP; 15 Jul 2000 00:29:33 -0000 X-eGroups-Return: sentto-1101623-450-963617930-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 15 Jul 2000 00:39:07 -0000 Received: (qmail 27982 invoked from network); 14 Jul 2000 23:38:49 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 14 Jul 2000 23:38:49 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 14 Jul 2000 23:38:49 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000714233849.REMB24904.mail.rdc1.wa.home.com@nventure.com> for ; Fri, 14 Jul 2000 16:38:49 -0700 Message-ID: <396FA489.76DBD3F9@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> <396E4108.7A616958@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 16:38:51 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e89b74caa7475e345830c977ffddfcd2 Status: R X-Status: N All right, Yann, if you're just going to spend all of your e-mail being
negative about people, making personal attacks and "laughing at so
called innovation", how bout we name the architecture after you:

Computer with Literal Instruction Translation, Orthogonal Reduction, and
Implicit Synchronization.

--Maxx

I'm fed up with your fucking attacks.  If you're just going to tear into
people all of the time, don't call yourself an engineer.  It doesn't
inspire people to introduce ideas when you belittle them personally for
suggesting something you don't understand.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00414 for ; Sun, 16 Jul 2000 21:49:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:30 +0200 (MEST) Received: (qmail 23586 invoked by uid 0); 15 Jul 2000 01:58:04 -0000 Received: from ch.egroups.com (208.50.99.226) by mx02.gmx.net with SMTP; 15 Jul 2000 01:58:04 -0000 X-eGroups-Return: sentto-1101623-452-963626280-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 15 Jul 2000 01:58:04 -0000 Received: (qmail 9316 invoked from network); 15 Jul 2000 01:57:59 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 15 Jul 2000 01:57:59 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 15 Jul 2000 01:57:59 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000715015756.UTBH24904.mail.rdc1.wa.home.com@nventure.com> for ; Fri, 14 Jul 2000 18:57:56 -0700 Message-ID: <396FC523.624773A6@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 18:58:02 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70559da4d45417636bc4ba633543f9cb Status: R X-Status: N In fact the design I was offering gives the user 32 registers in total:
8 address and 8 data, one set of local plus one set of global.  It's up
to the compiler to decide how many threads to run in parallel, thereby
splitting the globals up among them.

For implementations capable of managing three threads simultaneously,
two sets of 32 registers would be hardware accessible.  Since
multithreading here is intended to target the long wait times for
memory, one might scale on processors that more greatly outstrip memory
latency by handling more threads at one time.  Still, three threads
seems like enough to consider for now, leaving two sets of 32.  Fast
context switching with memory can be done via an eight-register swap
with an L0 cache, but again, these are forward thinking ideas.

As for keeping address and data registers separate, there is a degree of
polarity between the two.  The trend beyond 32 bit addressing doesn't
really want to go up to 64 bits, since latency on a 64-bit add is so
long.  Alpha chose some weird number like 43 bits, which struck me
immediately as just the kind of crazy scheme DEC's engineers liked to
use to keep the clock period down.  I would be satisfied with flat 48,
but that's just too damned weird for data, which likes 2^n bits and SIMD
features.  I remember reading something about branch registers in both
IA-64 (8 regs) and even f-cpu.  This is fine, but why not throw data
addressing in as well as instruction addressing.  Exception and link
registers could keep values there also, allowing for 8 local plus 8
global for data exclusively, about as many as you get on MIPS, if you
need that many.

Sound complicated?  It really isn't.  It just means that instruction and
data addressing are handled differently.  Interestingly enough,
addressing is done almost exclusively using word sized addu and addiu,
while data works on many different data types: byte, half-word, word,
doubleword, single, double, etc.  I have been told that there are lots
of media algorithms that benefit from 20 regs, most code benefits from
being able to reuse results of long forgotten values (rather than having
to store them immediately), and wide-issue, advanced piped processors
need many registers to draw from--those values have to sit there latent
in the rf while their respective operations flow through the pipes.

A narrow, software scheduled processor can get away with smaller
register files and faster circuitry.  What's more, you also get a much
smaller device count, and can hand design a single mask, improving
processor performance over time by hand-tweaking the wire and logic,
instead of leaving it up to software to take Verilog or VHDL and turn it
into a mask.

Since parallelism is primarily extracted through SIMD issue on loops
with many iterations, we need not focus too much attention on
superscalar.  Branching code generally has too many interdependencies,
anyway, so I'm not putting too much faith in ILP.

Finally, smaller cores mean more cores and more caching, both of which
contribute more to improved CPI than having wider-issue designs.  If we
want to do multithreading, we still have to keep the register file small
enough to avoid the huge clock penalty of a huge rf.

As for the simplicity of the overall design, the hardware itself has
very little work to do on its part with a narrow VLIW (or SSS,
Statically Scheduled Superscalar, for Whypee), so there are no obvious
limitations to attaining ever higher clock rates.  This benefit allows
the processor to move quickly from cache miss to cache miss, keeping the
memory system busy.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00423 for ; Sun, 16 Jul 2000 21:49:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:32 +0200 (MEST) Received: (qmail 32041 invoked by uid 0); 15 Jul 2000 02:55:42 -0000 Received: from ck.egroups.com (208.50.144.69) by mx02.gmx.net with SMTP; 15 Jul 2000 02:55:42 -0000 X-eGroups-Return: sentto-1101623-453-963629739-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 15 Jul 2000 02:55:41 -0000 Received: (qmail 30145 invoked from network); 15 Jul 2000 02:55:38 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 15 Jul 2000 02:55:38 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 15 Jul 2000 02:55:38 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6F2v2117644; Fri, 14 Jul 2000 22:57:02 -0400 Message-Id: <200007150257.e6F2v2117644@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 22:57:02 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 27a4b5b1ac371dca5292300b50e752a1 Status: R X-Status: N Albert Abramson <maxx@nventure.com> wrote:

>addressing in as well as instruction addressing.  Exception and link
>registers could keep values there also, allowing for 8 local plus 8
>global for data exclusively, about as many as you get on MIPS, if you
>need that many.

Sounds like a Level -1 cache to me.

>--Maxx
Rares

Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00426 for ; Sun, 16 Jul 2000 21:49:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:33 +0200 (MEST) Received: (qmail 28436 invoked by uid 0); 15 Jul 2000 04:05:58 -0000 Received: from ei.egroups.com (207.138.41.177) by mx02.gmx.net with SMTP; 15 Jul 2000 04:05:58 -0000 X-eGroups-Return: sentto-1101623-456-963633955-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ei.egroups.com with NNFMP; 15 Jul 2000 04:05:58 -0000 Received: (qmail 21815 invoked from network); 15 Jul 2000 04:05:54 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Jul 2000 04:05:54 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 15 Jul 2000 04:05:54 -0000 Received: from f-cpu.org (Raspail-3-54.club-internet.fr [195.36.203.54]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA17009 for ; Sat, 15 Jul 2000 06:05:48 +0200 (MET DST) Message-ID: <396FE2EF.770A993C@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007141909.e6EJ99x08889@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 06:05:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I'm back Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 343df0a630b158d17a50de3bda5447a4 Status: R X-Status: N Rares Marian wrote:
> Yann Guidon <whygee@f-cpu.org> wrote:
> >> Now can anyone fill me in in 25 words on where this is going?
> >i won't. i don't want to seem partial :-)
> >anyway, the great f-cpu whell turns and there comes again "someone with a super idea"
> >(i know, i was one of those before...). 6 months ago, that would happen every month...
> Well I've become more sane in the past few months so you won't see any freaky ideas from me.
> Just simpliciticity.
<sad>
i'm sorry, because you were our grain of funny madness and unseriousness.
i hope we don't loose in the change :-)

i think that making computer is an art, and as artists, we should escape both
>from reality and dreams. both are dangerous : reality because it keeps us from
looking around and invent new things, and dreams keeps us aways from our real goals.
Rares and some others were good at remembering us that we have to be both
more serious and more open, yet conforming to our common goal (make this fucking chip).

> >> I've finally found employment and will be able to participate clear of worries about bills, etc.
> >what will you do for us ? :-)
> Turn this dark cloud of technophobia around.  I don't know how bad the phobia is in Europe,
> but it's frightening how scared people are in the United States.
i didn't remark.
OTOH, in France, things are getting worse and the senators blew another fuse.
not speaking about the software patent debates etc...
heeeeelppp....

> So expect a few FPGA based kids' toys.  If there's one in every house it's
> going to be harder to make up bullshit news articles.
>
> I'm also close to solving two $1Million contests. :)
???

> >what has your other OS project become ?
> Well we're awaiting the release of a better contender (me I'm waiting for my AmigaSDK).
> Oh and my new Athlon is going to be great for compiling etc.
> I'm well on my way with Gnu FS Manager you'll see soon.
at last, something real :-)))

> >have you seen other eastcoasters in the last 6 months ?
> We talk alot but no visits.  no point really I got into the college
> in Massachussetts, so I'll be within a 90 minutes of Nate and within
> 5-10 minutes of every geek in MA (there's hundreds of them :) ).
ok fine for you, i wish you much luck !

thank you for delurking,
and expect something new and C before september :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00429 for ; Sun, 16 Jul 2000 21:49:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:33 +0200 (MEST) Received: (qmail 22599 invoked by uid 0); 15 Jul 2000 04:06:03 -0000 Received: from mv.egroups.com (207.138.41.150) by mx02.gmx.net with SMTP; 15 Jul 2000 04:06:03 -0000 X-eGroups-Return: sentto-1101623-457-963633955-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 15 Jul 2000 05:06:01 -0000 Received: (qmail 20010 invoked from network); 15 Jul 2000 04:05:55 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Jul 2000 04:05:55 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 15 Jul 2000 04:05:54 -0000 Received: from f-cpu.org (Raspail-3-54.club-internet.fr [195.36.203.54]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA13941 for ; Sat, 15 Jul 2000 06:05:48 +0200 (MET DST) Message-ID: <396FE2F1.F7AE7A18@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <00071414122901.00382@gandalf> <396F5F51.50B761E4@f-cpu.org> <00071416551003.00382@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 06:05:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] windows and threads (was: VLIW 64) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8d8a3d1d0b56e3abeda966c5825cdbf6 Status: R X-Status: N hi !

Jecel Assumpcao Jr wrote:
> Yann Guidon wrote:
> > ok i know and i'm sorry for the partial over-simplification.
> > i had no time to teach everyone how a SPARC is made (and i'm not the
> > right guy for this). accept my apologies. you could also explain how
> > the windows overlap etc. so we can understand that, unless you code by
> > hand and forget the API, you can't use all the 32 registers (otherwise
> > you have to call a subroutine into the subroutine, which is unnecessary).
> You can't use all 32 registers in a MIPS or all 16 registers in an ARM
> unless you code by hand. So?
as noted before, it's a problem with the compiler too...
but the compiler has to feal with the core's complexity.

> > You know that my opinion is : the more register the better. more registers
> > means deeper and more pipelines, with less memory accesses, but unless you
> > can explicitely address one window with a special instruction (like :
> > "now, slide to window #564") you have a lot of difficulties with windowed
> > registers. And no, my concern is not about running faster Netscape or
> > Staroffice.
> Do you know the old AMD 29K processor? You could address any register
> directly or use a kind of register window, depending on what you wanted
> to do.
i might have the databook somewhere... but that's not such an impressing CPU.
it's cool for specific applications but there might be something missing
for a general purpose CPU. i know there was one workstation based on it
but that's not well known.

> I have a problem with a large, flat register space. The Philips
> Trimedia has 128 registers (this is probably the most popular VLIW chip
> ever made, so I would encourage people interested in this kind of
> architecture to look into it:
> http://www-us.semiconductors.philips.com/trimedia/)
thank you for the link !!! i heard about it for a long time but never had
any ressource.

> which is great when
> your compiler has unrolled a lot of loops and inlined a lot of
> subroutines, but how do you deal with them when you have to switch
> contexts?
look at the f-cpu manual ;-)
take a look at the register number discussion and the SRB mechanism.
it's a rather simple idea with low overhead (some Kgates max) and low impact
on the switching time, yet the response time is similar to a banked reg file,
without the implied silicon surface. it's a compromise between raw switching
time and silicon occupation, it is acceptable because on average a PC doesn't
switch more than 1K times per second and the few "lost cycles" are negligeable
and less worrying than the memory access time.
yes, memory access time is a constraint and we need to compute and output the
address of the regfile backup in memory... whether you have a banked file or
not (we know that the RF overflows...)


> > > [...] This trap was slooooooooow.
> > heh. and what solution have they found ?
>
> They made the trap fast :-)
>
> Really - it was just a matter of letting the handler run in user mode
> instead of supervisor mode.

argh.
i thought they'd find something much smarter.
i'm disapointed.

> > > [MIPS = hard core, Sparc = soft core]
> >
> > hum, that could be a reason, but i won't engage myself into this debate.
> > i gotta eat and watch the fireworks :-)
>
> Good choice.
indeed. the fireworks were rather nice and the melon juicy :-)

> But I would like to repeat this once more since I think it
> is very important for this project. Look at what Chuck Moore did with
> his MISC Forth chips (http://www.ultratechnology.com/) - he got them to
> run at up to 800 MHz with a 0.8 micron process.
i saw it one year ago : interesting. What i would have had is his CAD
software : my methodology is rather close to his and his sowftware would be
a cool thing to work on. it would solve the SPICE, Alliance and other's
problems :-)))

> Most people had
> problems getting more than 50 MHz with this technology!
0.8u ? i think we could do roughly 100MHz. but who am i to speak thusly
when i haven't done it yet ?...

> You will never get anything like this compiling from a VHDL design.
yup, he's doing his designs at the transistor level with his own tools,
that are perfectly suited to his needs.

> As always, there
> is a price to pay. His design is simple and can't scale, and he even
> has problems when moving from one production line to another in a given
> factory.
he has problems everywhere.
he's deeply endebted and refuses help. he makes a design to pay the last debts
but gets more endebted everytime. he's stuck to 3 metal layers. etc.
i don't care anyway, i'd like to have his CAD SW. please help me.

> > > P.S.: in my own cpu design I use 16 threads and schedule them in such a
> > > way as to totally hide the pipeline from the branch instruction.
> > do you have any C sim ? or VHDL model ?
>
> Sorry - I use Self (a Smalltalk dialect) as my HDL. But the architecture
> is simple enough that I could write a simulator in C very quickly.
wow, that could be the thing to do as soon as you can ;-)

> It is, however, very software intensive like the Transmeta
> Crusoe. The internal architecture is a four bus MOVE (TTA) processor,
> but the external architecture is a bytecoded stack machine (Self, but
> could be Smalltalk or Java for those who prefer these languages). You
> can see the board level design at
>
>     http://www.merlintec.com/merlin6/e_main.html
thanks, i'll take a look !

> The pipeline is:
>        1) output address to cache SRAMs
>        2) ---
>        3) latch data (4 move instructions) from SRAMs
>        4) MOVE
it's a 32-bit machine, right ?

> If one of the MOVE instructions changes the contents of the PC, then it
> will effect only the instruction that will be executed 4 clocks later.
> The would mean I would have to deal with 3 "delay slots", most likely
> meaning 12 NOPs in a row :-(
>
> The scheduler puts out a 4 bit thread number in every cycle. This
> number is combined with the instruction bits to generate the actual
> register addresses: if the thread is 3 and it wants to read register 6,
> then it would actually read register 0x36. There are no shared
> registers between threads.
looks simple and cool :-)

> Once a scheduler assigns a given thread on a certain clock, it won't
> schedule that same thread again for the next 3 clocks. So to some
> thread it looks as if the very next instruction after it changed the PC
> is the one it requested. This makes life so much easier for the "code
> morpher".
:-)

thank you for the comments,
> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00432 for ; Sun, 16 Jul 2000 21:49:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:35 +0200 (MEST) Received: (qmail 30727 invoked by uid 0); 15 Jul 2000 04:06:37 -0000 Received: from mo.egroups.com (207.138.41.166) by mx02.gmx.net with SMTP; 15 Jul 2000 04:06:37 -0000 X-eGroups-Return: sentto-1101623-455-963633954-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 15 Jul 2000 04:06:20 -0000 Received: (qmail 19999 invoked from network); 15 Jul 2000 04:05:54 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 15 Jul 2000 04:05:54 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 15 Jul 2000 04:05:54 -0000 Received: from f-cpu.org (Raspail-3-54.club-internet.fr [195.36.203.54]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA02059 for ; Sat, 15 Jul 2000 06:05:49 +0200 (MET DST) Message-ID: <396FE2F4.29C25163@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 06:05:08 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f9fb12ae0892975874c02293ca7efca0 Status: R X-Status: N Arthur van Leeuwen wrote:
> On Fri, 14 Jul 2000, Yann Guidon wrote:
> > hi !
> And hello.
and re-hello :-)

"do i see a pattern here ?" :-D
(like someone used to remark)

> > Jecel Assumpcao Jr wrote:
> > > On Thu, 13 Jul 2000, Yann Guidon wrote:
> > ok i know and i'm sorry for the partial over-simplification.
> > i had no time to teach everyone how a SPARC is made (and i'm not the
> > right guy for this). accept my apologies. you could also explain how
> > the windows overlap etc. so we can understand that, unless you code by
> > hand and forget the API, you can't use all the 32 registers (otherwise
> > you have to call a subroutine into the subroutine, which is unnecessary).
> Well... actually... you can use all 32 registers. But you'll have to fix
> them up right to conform to the calling convention upon call or return.
> This, ofcourse, incurs a performance penalty. Which is why the sliding
> register windows are not as useful as they were supposed to be.

as noted before, SPARC was meant to speed up LISP interpreters or bad C code, which use
a lot a function calls, nearly 30% of the CPU time in the studied case.
Today we don't "call" that much, and i'm surprised that SPARC is so well and alive.

> > > When the window "slides", the global registers remain as they were
> > > while the outgoing registers become the new incoming registers. So to
> > > the program this is no more restrictive than what the MIPS has.
> > this is : if you want to use all your 192 registers (or whatever your
> > chip has) you have to manually "slide" the window, that is : make a
> > function call. and unless you need no argument, you have 8 registers
> > that are dangling (unless you really have a very, very smart compiler,
> > but i never believe in compilers anyway). SPARC has been designed for
> > fast function call and return in C and LISP environment, that's all.
>
> I have a few gripes here: you do not need 192 registers. Really. See
> Hennessy&Patterson. There's a graph in there somewhere (sorry, don't own the
> book and it has been slightly over a year since last reading it) that charts
> performance increase scheduled against number of registers. This chart
> really drops low beyond 16 registers.

i have a big problem with that one, too.
first, the 192 regs in sparc (or whatever) can't be accessed linearly so your remark doesn't apply.
Second, this graph is dumb because time flies faster than you'd think :
- memory was already a bottleneck, but not as much as today (it has become incredible)
- the compiler technology has evolved
- we have deeper and deeper pipelines, as well as wider superscalar machines !!!
- it depends a lot on the addressing modes available, and its memory-oriented instruction set
(reg-mem or reg-reg)
- remember the VAX and its lack of address bits ? same goes for the registers...
all these parameters were not integrated in the study (might be in QA because
i don't find it in my "HS/WS interface").

but this is all written in the manual.

> The second gripe is with you not believing in compilers.
that's a personal opinion based on personal experience. what's wrong with that ? :-)
my answer to classical compilers is the GNL project, but it's not the right place to
speak about it.

> I have yet to see a
> compiler that does in fact optimize and does not do better than I would do
> naively translating from naive high level code.
that's where my other gripe is : compilers would be ok if they had something else
than textual langages to churn. textual langages (HLL) can be SOOOOO dumb and dry...

> And when you are at the level
> of algorithms, changing algorithms does a lot more than wringing out every
> last cycle by hand. Not that there's no place for that... mind you, there
> is. Just not in most workstation code.

i've been on this road for years : program, debug, search the bottleneck
and at the end the algo is still unsatisfactory. at the end, you realize that
it's the computer that is not suited for the kind of task you ask it to do :
you can't short-circuit the API more than once, and you still have to make
your operations, yet the architecture requires unnecessary operations.

> Doei, Arthur. (Great believer in compiler technology. Let the computer do the dumb work.)
and what happens when you ask someone dumb to make a smart job ?
my programming is not dumb. i don't write Netscape or at M$, my HPC algos are all
tested in HLL but with ASM in mind. the compiler CAN'T second-guess the programmer.
a compiler can do a very good job compared to a CS student, but an experienced programer
can beat a compiler because he knows the tradeoffs, the tricks, and most of all the thing
to be done better than a software. read Michael Abrash's Zen and its experiment with
the Game of Life. Now i'm far past that level. Well, the level of 1995. Michael and
the others (Hsieh etc) have been working at their top level and i have specialized
in other domains.

>   /\    /  |             Fight Scientology, See URL: http://xenu.xtdnet.nl/ |
>  /__\  /   | Buttons. Lotsa buttons. I like buttons. [Big Dog]              |
> /    \/__  | A friend is someone with whom you can dare to Be yourself.     |
>  Just Be   +-Arthur van Leeuwen, arthurvl@sci.kun.nl------------------------+


"Gordon F. Cichon" wrote:
> have your every thought about why Merced does not get to its performance?
i wonder who cares about what "performance" is...
anyway, i have a personal definition that might not be agreed on by others
but who cares.

> Here's my explanation: Because it has too large a register file. (among others)
> A register bank of n registers creates a routing overhead inside a chip
> for the crossbar interconnect of n^2. And for a certain size n, this hurts.
this is not exactly a good reason, the mathematics are a bit different, but let's
compare this first IA64 implementation by Intel (HP has done its own for long,
without x86 support) and other CPUs of the same era : look at the 21264 for example.
it has a huge register file, too, similar in size to this of the Merced, so what ?

Intel's sin is to remain Intel and when it had a good occasion of making something
simple and cool, they made something awfull and complex that i don't want to ever
program. the Willamette is a frightening microarchitectural art piece compared to
the Merced (see the package i have sent here some weeks ago).

to speak about performance, i'll give my personal definition :
"ease of access to the ressources" or something close to this. This is clear
and direct. this can relate to a single product (this is an "absolute rating)
and it holds just enough subjectivity and objectivity. Accessing the power of
a x86 is difficult, it requires to know a LOT of things and details, read all the
manuals and look at a lot of examples. Even though the IA64 is meant to be VLIW,
their compromises on this concept has led to a similar complexity. IA64 is everything,
and nothing, of VLIW, RISC, superscalar, it's just a bunch of features that are
put together by its tormented history. And here, i only speak about the ISA.
the microarchitecture is plain dumb, far more complex for what's really needed,
but they were stuck with the x86 compatibility.

> And a word about Sparc: The register windows are really broken!
> Nice idea to have a nice register stack inside the cpu and avoiding
> using the real stack in memory for subroutine calls.
> However, every on chip register stack eventually overflows.
> Conlusion: You have to reserve memory to store these registers on the
> ordinary stack anyway. And if you do it anyway, you can also do it
> transperently with a stack cache, like many i386 clones do. And if you
> don't do it, you could at least save the registers in the stack frame of
> the subroutine the registers belong to, and not the next one as by
> Sparc.
it could look suspect, buti agree rather well with this analysis.
BTW who uses windows today ? (huh, except IA64 but we already know it sucks)
with the huge renamed register files, we don't need windows at all.

> In this sense, I think ARM with its 16 registers is a quite good design.
> And I think even Intel appreciates that.
ARM is a very special case : it's meant to be compact and designed by a
reduced team (the first design was done by a closed group of 3 guys).
OTOH it is not meant to grow much. it's a cool thing that has the best
MIPS/Watt performance but it is rather limited to the microcontroller branch
of applications, despite its astonishing electrical characteristics.
For the F-CPU we need something much more scalable.


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00435 for ; Sun, 16 Jul 2000 21:49:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:37 +0200 (MEST) Received: (qmail 30893 invoked by uid 0); 15 Jul 2000 04:06:46 -0000 Received: from ef.egroups.com (207.138.41.172) by mx02.gmx.net with SMTP; 15 Jul 2000 04:06:46 -0000 X-eGroups-Return: sentto-1101623-454-963633954-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ef.egroups.com with NNFMP; 15 Jul 2000 04:06:45 -0000 Received: (qmail 19966 invoked from network); 15 Jul 2000 04:05:54 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Jul 2000 04:05:54 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 15 Jul 2000 04:05:53 -0000 Received: from f-cpu.org (Raspail-3-54.club-internet.fr [195.36.203.54]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA17008 for ; Sat, 15 Jul 2000 06:05:48 +0200 (MET DST) Message-ID: <396FE2F6.A6D877A3@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> <396D9E3B.91CF0B87@nventure.com> <396E4108.7A616958@f-cpu.org> <396FA489.76DBD3F9@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 06:05:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a9da026648811a1f4f3bea8730e49329 Status: R X-Status: N hi,

Albert Abramson wrote:
> All right, Yann, if you're just going to spend all of your e-mail being
> negative about people, making personal attacks and "laughing at so
> called innovation", how bout we name the architecture after you:
>
> Computer with Literal Instruction Translation, Orthogonal Reduction, and
> Implicit Synchronization.

i don't know, it's your choice.
i'm sorry if you feel that my remarks are negative.
as a newcomer, you didn't take much time to get used to the group
and its history. it's your choice too, then don't complain.

i have learnt to be detached from the things i do, i remain calm
and am trying all my best to be as open as possible. i have not closed
the door to anybody because i'm not the "god" here, i'm just trying to
make something constructive. OTOH you look very eager to see YOUR idea
at work : that is OK but the f-cpu is a group project. there are a lot
of things that i have not chosen and that i respect because otherwise,
the project would split and lose its strength and unity. it is your
choice to decide if you want to belong to the group or not.

> --Maxx
>
> I'm fed up with your fucking attacks.
i have nothing to win from attacks. plus, there is NOTHING personal :
i respect you as well as your ideas which are far from dumb and look
better than things that we have seen in the past here :-) you wanted
to speak about architecture, ok you have it. what do you want now ?

>  If you're just going to tear into
> people all of the time, don't call yourself an engineer.
first, i don't call myself an engineer. Unless someone delurks,
we're all rather young (except Richard) hobbyists, technology enthousiasts
(see Rares), students or young electronicians (some frenchies). there is
no guru. i'm not a guru either : i just invest time and money and work
to make this project survive and maybe succeed, but it requires a lot of
management : everybody has "super architecture ideas" but if everybody wants
to implement his own CPU we'll never make anything. i better make compromise
and have a working chip rather than lose time and work, every month, on a
new architecture that someone throws on the table. the current F-CPU has reached
a rather stable consensus, we have studied a LOT of alternatives and prepared
a lot of breaking points or extension possibilities for the future.
if you have something to add, do it. it's not about being or being called
whatever, it's about having the guts to DO something rather than discussing
all the time.

>  It doesn't inspire people to introduce ideas when you belittle
> them personally for suggesting something you don't understand.
first : i won't ever claim that i know what you know. I can't read in
the minds, and i doubt you do, so don't say i don't understand. thanks.
i have a "certain understanding" but it's up to you to enlighten my point of
view.
Second : it's not my fault if people lurk, are shy or discouraged, at least i hope.
i try to be pragmatic, based on my own and the group's history and culture.
people who have met me could say (please confirm or infirm) that i don't eat people,
i'm sometimes picky, that's all. if you don't have the courage to stand your opinions,
if you can only justify your claims with gut feelings and faith, it's not my fault.
but please don't consider me as a basher, i'm a builder.

> I apologize to everyone on this list for that last e-mail.  I was
> despondent about a pattern of responses from Whygee that I did not feel
> were leading to anything productive.  I was frustrated, and I'm sorry to
> have brought everyone else into that.
frustration is a cool thing to evacuate. we think better when we're cold blood.
sorry for being picky, but one day we'll have to make this fucking chip.

> --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00438 for ; Sun, 16 Jul 2000 21:49:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:38 +0200 (MEST) Received: (qmail 5494 invoked by uid 0); 15 Jul 2000 06:41:54 -0000 Received: from mq.egroups.com (207.138.41.138) by mx02.gmx.net with SMTP; 15 Jul 2000 06:41:54 -0000 X-eGroups-Return: sentto-1101623-458-963643310-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mq.egroups.com with NNFMP; 15 Jul 2000 06:41:53 -0000 Received: (qmail 31321 invoked from network); 15 Jul 2000 06:41:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Jul 2000 06:41:50 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 15 Jul 2000 06:41:50 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000715064149.GYO24904.mail.rdc1.wa.home.com@nventure.com> for ; Fri, 14 Jul 2000 23:41:49 -0700 Message-ID: <397007AD.D9402009@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007150257.e6F2v2117644@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 14 Jul 2000 23:41:55 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cfcc8f7e734904f0a0553f946d417f68 Status: R X-Status: N Rares Marian wrote:

> Albert Abramson <maxx@nventure.com> wrote:
>
> >addressing in as well as instruction addressing.  Exception and link
> >registers could keep values there also, allowing for 8 local plus 8
> >global for data exclusively, about as many as you get on MIPS, if you
> >need that many.
>
> Sounds like a Level -1 cache to me.

I must have explained it too vaguely.  Like 68k, you have 8 address regs,
each 48 bits wide.  Like G4, you also have data regs, but they're 128 bits
wide, packing four or more operands in each register.  This part is not
inconsistant with the idea that you could have registers that expanded
further in width to improve throughput.  I just happen to favor multiple
processor cores, instead.

The major limitation to improved performance in computers is wait time for
memory.  Processors spend most of their time just waiting for memory to show
up.  Some alternate work has to be found at run time to fill the growing
gaps while accessing memory.  It's worth taking a penalty on peak
performance in order to overcome this bottleneck.

Running programs tend to use just one or two registers for addressing, and
MIPS uses two more for linking and exceptions (IIRC), so you've already
freed up three or four regs, moving them over to address.  Moreover, you're
using those same address registers for branching.  The hardware is all the
same, just 48-bit unsigned addition with and without immediates.  This is
nothing like the kind of work normally performed on data, so I tend to view
them as separate.  Putting them all into the same gprf is traditional, but
there seems to be an opportunity for some specialization, here.

In other words, you have 8 local address and 8 local data.  That's not quite
so stuffy.  If it is, you can make use of the global registers, giving you
up to 16 of each.  The hardware sees only a large flat register file, but
each running thread has its own ThreadID number, seeing just local and
globals flatly.  That number is appended to the local register number at run
time (only one thread is running at one time).  If a thread is assigned an
ID number of 2, a register specifation of r5 is changed to r25.  Writing
results to global R3, however, will be visible by any thread that takes
over, so globals have to be carefully allocated.

On a permitting load-store, a cache miss causes a branch on miss operation.
Another thread is loaded into the program counter, and begins running.  It
sees the 8 global data and 8 global address registers, but it also sees its
own registers as well.  At any time, any thread can read from and write to
local and global registers, giving it access to 32 in total.  The hardware
gives the appearance of four sets of 8 regs, so a thread does not need to
specify which set of local register it will use.

That's the primary benefit of this kind of banking scheme.  You can
transparently switch contexts without the program having to know what other
running threads are doing.

The downside is greatly reduced when we consider the fact that just one
thread can be scheduled to run, giving access to all 16 data and all 16
address registers simultaneously (as well as the 16 condition fields).
Alternately, a small number of running threads can allocate two or three
additional registers from the global sets.  As it just so happens, I've
already accounted for separate condition fields on the data registers,
including an Update bit.  A running thread can check that bit on a global
data register to determine if the register is already in use by another
thread.

Regarding L1, one or two cache blocks can be used as L0, giving fast access
to 256 bytes of data in much less time than it would take to access L1.  I
had an earlier design with 16 cache blocks -- it turns out you tend to get
hit rates around 80-90% -- and the access time would have been short enough
to fit everything into one short clock cycle.  I happen to favor the L0
approach, whether it's one cache block or 16.

Either way, good compilers look at the register file as a kind of cache
where values are moved in from memory before they are likely to be used.
These prefetches are one of those nice things you can do ahead of a branch.
Intel is betting on speculative loads preceding most of these loads, and the
compiler having enough time and a high enough level of confidence to get
ahead of misses -- 60 or more cycles ahead of a miss, on a design that is
supposed to issue four or five instructions per cycle on average... in other
words, through 50 or more branches.  Itanium has no way of handling work in
the event of a cache miss, which will leave it's CPI far behind even the
21164, which had already exceeded Itanium's clock rate when COMPAQ
discontinued it for new systems.  Most application developers I know of
don't even have an IA-64 path; only Intel and Wall Street still think
they've got something big.

Provided that a fast L0 is available, provided that the compiler is smart
enough to look ahead through one branch, provided that we're not trying to
issue more than one ALU per load-store (no one does, but you can widen to
two load-stores plus two ALU ops per cycle if you don't mind the penalty),
we can generally accept that 8 data plus 8 address registers will be enough
for a three issue processor -- and if it is not, globals are available to
use.

>
> >--Maxx
> Rares
>
> Windows the other 70's technology.
> ----------------------
> Do you do Linux? :)
> Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00444 for ; Sun, 16 Jul 2000 21:49:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:41 +0200 (MEST) Received: (qmail 11688 invoked by uid 0); 15 Jul 2000 11:09:40 -0000 Received: from jj.egroups.com (208.50.144.82) by mx11.rz2.gmx.net with SMTP; 15 Jul 2000 11:09:40 -0000 X-eGroups-Return: sentto-1101623-459-963659377-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 15 Jul 2000 11:09:39 -0000 Received: (qmail 15676 invoked from network); 15 Jul 2000 11:09:36 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 15 Jul 2000 11:09:36 -0000 Received: from unknown (HELO ci8.africaonline.co.ci) (208.160.145.16) by mta1 with SMTP; 15 Jul 2000 11:09:34 -0000 Received: from ci4.africaonline.co.ci (ci4 [199.103.178.4]) by ci8.africaonline.co.ci (8.9.1b+Sun/8.9.1) with SMTP id LAA06077 for ; Sat, 15 Jul 2000 11:07:56 GMT Received: (qmail 18927 invoked from network); 15 Jul 2000 11:04:12 -0000 Received: from ppp232.africaonline.co.ci (HELO guerrier.local) (199.103.178.232) by ci4.africaonline.co.ci with SMTP; 15 Jul 2000 11:04:12 -0000 Received: from guerrier.local [192.168.0.21] by guerrier.local [127.0.0.1] with SMTP (MDaemon.v2.8.5.0.R) for ; Sat, 15 Jul 2000 11:10:07 +0000 Message-ID: <39704557.E030A25F@guerrier.local> Organization: AZERTY X-Mailer: Mozilla 4.6 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: Olivier@guerrier.com From: OLIVIER MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 11:04:55 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Manual and specifications ? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d8d66f012c4eec53dbe966c59919e8fc Status: R X-Status: N Hi there,

I follow your discussions for two months now.

1=B0) I'm happy to see more technical discussion this week.

2=B0) Where can I get the technicals infos about f-cpu,
what is already done, what is to be done, choosen specs, etc...

The f-cpu web site doesn't contain theses, and the links to manual are
broken.

Olivier.
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00456 for ; Sun, 16 Jul 2000 21:49:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:49:48 +0200 (MEST) Received: (qmail 16982 invoked by uid 0); 15 Jul 2000 12:45:33 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 15 Jul 2000 12:45:33 -0000 X-eGroups-Return: sentto-1101623-460-963665127-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 15 Jul 2000 12:45:32 -0000 Received: (qmail 6175 invoked from network); 15 Jul 2000 12:45:27 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Jul 2000 12:45:27 -0000 Received: from unknown (HELO public2.zz.ha.cn) (202.102.224.112) by mta1 with SMTP; 15 Jul 2000 12:45:19 -0000 Received: from public ([202.111.158.160]) by public2.zz.ha.cn (8.9.1a/8.9.1) with SMTP id UAA20547 for ; Sat, 15 Jul 2000 20:44:23 +0800 (CST) Message-ID: <000901bfee59$48752500$b723440a@public.zz.ha.cn> To: References: <39704557.E030A25F@guerrier.local> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Oliver Liu" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 20:35:39 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] the manual Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BFEE9C.3E2B57C0" X-UIDL: 37d5c39f7edafb34d8b8d05ffe92752d Status: R X-Status: N ------=_NextPart_000_0007_01BFEE9C.3E2B57C0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =0D
----- Original Message ----- =0D
From: OLIVIER <olivier@guerrier.com>=0D
To: <f-cpu@egroups.com>=0D
Sent: Saturday, July 15, 2000 7:04 PM=0D
Subject: [f-cpu] Manual and specifications ?=0D
=0D
=0D
> Hi there,=0D
> =0D
> I follow your discussions for two months now.=0D
> =0D
> 1=B0) I'm happy to see more technical discussion this week.=0D
> =0D
> 2=B0) Where can I get the technicals infos about f-cpu,=0D
> what is already done, what is to be done, choosen specs, etc...=0D
> =0D
> The f-cpu web site doesn't contain theses, and the links to manual are= =0D
> broken.=0D
> =0D
> Olivier.=0D
> =0D
> =0D
> =0D
> ----------------------------------------------------------------------= --=0D
> In Europe, more than 219 million people will access Internet services= =0D
> using mobile phones by 2003, according to Forrester Research.=0D
> Learn Wireless Development on=0D
> http= ://click.egroups.com/1/6222/1/_/3462/_/963659378/=0D
> ----------------------------------------------------------------------= --=0D
> =0D
> =0D
> =0D
3D""
------=_NextPart_000_0007_01BFEE9C.3E2B57C0 Content-Type: application/x-zip-compressed; name="fcpu.zip" Content-Disposition: attachment; filename="fcpu.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAHKVTyf7tthAmC4AAJguAAAIAAAARjEtMy5naWZHSUY4N2EmAoACgAAAAAAA//// IfkEAAAAAAAsAAAAACYCgAJAAv+Mj6nL7Q+jnLTai7PevPsPhuJIlgeAoubKtu4Lx/JM13aXqg9w 9/4PDAqHxFiO5zlCkAtm8TlzrqRDaskKzU4rWIQymVs2utpyiHzOokFrs1vT9i7D4JSYEX/rKXlO P/rytzc4xjVnV6fj0CVI6Cjn0ggjeUH5SPi39oVDt1h4CTphaQg1yheKeid6qOjX+dmUKovH+rpa GjirC3m7aAv3q8C4S2zaWzSaZ0xcReqLyAkNKywkRWV9ipmLG3HUuJyWMGyAxMSjY35Slln7sTkt zqwLroq8LZ/KvhOM8U77jw+VMnIEsz3RVylgPmdj+FVyqA6gwksDIcWhN+Kin4mToRA2lLbBXyyJ HLXdaiUBowhBTiqWdOQRD0QuMwOMe2nSEw41KTfizNlzH0hgQ6mR/OlGJbxmkZAOitmkpqiaN50m vWevqdU3UIVJTUl1KREsZHcpPVoNq5myI0F1Ffe1W1i0Ww+qZdribN2MDGUW7Td3Ha8MLSda0Tt2 B1BThTlqittO8VOfLw+XRIP4roXM3J6h/yT6uZokxjVC522rEDMQ0/X6leYcErJQ1kbEdvPCthXt JLZZWF6VO2K8TuigyY6nc1JvyeRyt+RclQYZkYQhqmTpOqS7zdJRB1RNAntC7bz7Avq4m491m4SF c3fPvP149tkLnjZqOD4c+Abp3yb/nn8BCnjadMehNx2B9aWjjjUaDVYff8wxSJCD3eGXmn472VeY hf9JaB5CFLLnYXcG/vUQiiQut1cQsNmX1X0t8nTKielNpeI5LOrYXHGhnQPSO+UcaIgKv4RhmS1C 9ojSiwqmpVUh5iASDJBNvjKkirwZORSSsSiJJZPY1OgZONQ1yOKMPjjpZIRbqNlZTzaauf9edHBC eUc5AwrojZ4gXrOnfMndiZecZbpTZ5qEXtianx/GOBWMrdnwoHezsDMnojk+KWliko0pUFCOHqPg qGIaiZ+p8D0I6qSLrlnkoYkkaOerPYC3oV3ZqKqorcqRiaCmtPFoqa+UqqUqsRx2ul+Uxt4aa7Cz elLrs+fJCOmb+pnaJk6YyhrNsJyOa+2v2Hp6brnXGiptuLQ2ixxdCbpabJqa9DZvePO42CtfLSrr lZbqbcpInwYfjHDCCi/McMMOPwwxwuHsY5M0Vk6ZJZOWshUvhJoVhGrFHruS3nOXkntmiuJWq+7H gmpIqm8rdayHjt3ak+m0UvZ7A5de4XZOwiY3rjbfsdDu2cbNe33bLskr89zyzIFK2piE3gzqXaun Pkpq0lHnyq5fQ8tF8NfbLZvuuqUVPe6IZrMtRs7uUvv2xC6ba3RfXtftZtzg/zr9Lt/ZlrcqiFjD o/UVNNOlLchZR0QhoLACKzadZVceceaab855530SbgJZimBJ3d4yJF6v4DDT3XRsl6euOtQBKj04 16bHHhRwf7v+NON5XR3wlSmnBRvt6PZHruG4w/7l7qAFzrxvJvcY9PQ/K19b8TMac/vyq+/c+vOs R+89s2xgf9nd5aM/nPPVvR685/LPT3/9Y1NWl/FtuR061/sLFzlYyQ1w48PQ+nxnt62YyS3+O9zi eoYyIkUFfg88oBy09y/ZfU9/+GBa5YQFPQNSjA1Ku1/QNoLBpWnQgeZTnQcnaEL3oQmB4dGLaWLo L8W10Fv48thvyIc83GBshs8VS4dujtih5iQPf7cZIO9CWEEL7jCBVmFZ39hnthfGD4QslCKe8rfC Hh7wGzLMmxc7hhgO8mtqUzwjGCPxBYF9BC5D/EHVcvhG8xhOjT/hI96uMCWgnbCI1FMiXKIiSJEZ UofQ2R7c9uhGEXYwknS0n8Ecyca2UXJk8vBjZdSXvkymapNYXAgpl3g2FYoyjHXzpLMoCTB9ZXCV 1OgW6h6pK8dQKpB0VCT1PoNE41iPS8vgHxWdwqba8CJIPKrj6EYnRDNmSBY4VGbakGJJiZ3/0pXX 9GJmjHk+GHGTPo3c5im92b9lWqyZeEsjgKwmL0n+EHKQTKcuzfnKKnISdLD8JD7LqcpuSnGcjVuT UqqZkWxecpa/U6hDHwpRgtpzk+WUqNom2s9QkjKZDJUZPs85RkemkKL+3Ggpr4hNbRFUaMPTgkVl adJ8IhOUp0NO1cBZqGmKZpCL9KUiEWrPb2JSoHHaw0vxmNEtHPWPGI3kUo95Ro4G1KMxBalVr4rV rGp1q1yNDA27Ctaw5iNRYi2rWWEKQ8v1DohalWrt0HpWVF6wjJshK1uz6tbjFfSsWqykWqG4z7Dm NadNNWtfhQhUvxYwioKlqTQLW9bDVi+xDYgF7EmxOtgv7tWw0fr/oM5oYUWwUuItRIMXvcQqWTFx EXx3xWw9RksjubSxtTIlpB6N2tm0rha0rESq5GBYOJBJkKhd/OpjbcpY41pzmRZxFLEC6NLcbvGz zVMuXmlp3Yv+g1ffayzldEvdWvaWpLUtLXG5mtoiUnaylp3tVvsAvJhpFrKola5iw9u+7F71XmDT K329q7vwvW+tkoysY9eGo5YGVrT2rexuq0tbq2Z2jed9b4PZ+2Dx6le7BOJWRw7MKKpe5XEdBkoT 6UoTCi64qxM2r4jjml4FJ7i9amDMU495Y34WmCs2TqkTxcfat5KGhzs2S3cJ697iTvLHA6ZxbF92 z+SeTMlrYWL665gMmE2d7o67okN81StXMKwYrkn+MJVDx+WTeFlIdmiTbiCI4oGJ67+XbRDwwBQy qR1Zh1IeJRE7JTmcwvbM/d0wie7MzDxDtc+7lCNYBMa96uAyiNiViXZzXGhGUxosk5bvbWUbYs/O bc8nDk6FULppMpl6RZfWqKHptupY5g7KCZE1Of9c09n89bRhe89AhkzGQdsywjAhdYDH82ufBFs+ JfQqATcY1zHreL58jjZpMYzfHXfPcUfxMNrQmixAb4xqAHx1pRF83t/Yydv+cSc9kfvAQMcLnNdW bbajiGkFIquBRfY0Uvn6aWz/j7qL+dZnee04bU1fN9UCfzbBo0szdpu5wu/cVoodXebNxjG47fby ZBhu74GLMdrJW6C0QVxxgINcvbuGNsnDzMR6W7naMA54yB0+cmuj/Lf/prnK/d3wJ5624DM9+OTS be6oyVzGjy7ZeJP6YiSTmbMrZzrZnE5rlPlu29bl78O3rmecCubb1nRbq4aLL0RjfOxxnvHQXw5z fosw3LgOrp9ckkrKPAdjyeD5dD8XKl1nOHVPfeYhJ3luOhudJFyPqs1ZPnhtw52M4GU5OtKar+3e OX6NtzivLbh0tDvY2I5f7mC0Nk9NYi1xtzw5hFRDdAZWXfRBJ3b5bsbH3LOtr/MDfbzVnZ103FlS qXE/n60nCmm11bF6zD/h3uuea6DfXOikh3vGUR1u1nO79QXlPeh9T/vpE/6cxQy+633+Su+HdPZr F7zLqyrUjnZN7r1n/3rFL/ld8jTR+z+MK1tMZHpDf99nfy33dfC3WSm1eOsTeu0XZ6G1fsTHUCNy U6c3c1F3V7iCcO4ncuZnfefXSW+VgAqngUcnYFmGdbbXSnX2eFF2gVV2fDYzayrYc/f/1YHj91EY qIA0mH8MCH4OeIL7BF8l8lMGcniItEiGx1M+lYS85EtH9CHxN1UKJ3exx3YzWHk4xzhW+Ajaw4WL VhViB4ECWGLcJm5m6Fzldn0tuGK/x4E5B3UjGID9lklfWFSfB3n3hoVuBIAlRYefZoe5FHlwtlER BYTF0AtGpIbsZYiN6IgR44doBkzFsYQ+snfXMEzOdB1ryIY6lWpjeHuR6FTIN1Sf+HRKJ4p8SIry t4fMcnz194G2EogJV30sKDizKH0RqIN91Gmn2DK42IroxIm56II5ZEtCs4h3N2/vVnw1yAy08yND IkhQuISV1FNK2FOuMVL6ZovBCIv5d5GDigOM7+RuVQWO5iiHeUd2ZngfAIVqkJR6RXYxg0Qch7hy l/KI+aiPDINyneSI5JeKpeeO3EhxyzOOeOiD3TiArpaOuuiJBnWESkiN2WhG5ZhHsbgoB3mFsqSR 77ho35ga+yiSI+mGpkWQuwiS3wGQC3iOUkhe/8U4ittocBIoGqi3joL4kHZUMIkEgwWJeD4ZOx3p i+oihUKZeCmHNBZYKmfYbj7kivaIlCEYjooHk+hXehiJlVmplVvJlV3plV8JlmEplmM5YpZXkmSJ lmk5jGrJllRnlh7XlnF5e9rUjK4wlMIIlKZHlRbWieH0llRylylplS7WkOhFCgmjkJLmgarIkuiG kgymHteCmKpHcn14NHkJUvowmXUZG4FJgJjZj1lnYJEZfZMJim0Vmkw1mAAmKnRZQqe5cKDZmC/I mqBWdtoEm641mxzmjLWZJ64ZBbm5X6lJnEc5nKR5mwfTQkY5ZbLpnPfIl2qmnGupmDwYh3vpmASF GZ2c/1aauOmZDgmdifmYfqlzXTadnAkM35mQZQKER5UMxLidtmkupqmeoRgfQGKcetmJzElNhwmc W1afKnMi+bmBgzJoOPkJ3EVoesl9fwhxkdKd0ymc3Vdg0HVoaHiH8Cme2plpl6k8cJmM4cehwnWe rxmgA8IxDAJNp4ahCKqh1PmYFhqescmdyblQE5qZBOqexYmOv1miwXmiwncSGbej/6GgQRqUNCGZ 3rmYVzmehOiNtXic0rlQ6FmdDoqaiYhFRYqQUiphShqhN4qkLsSjT2qlZ3qdn/KfRoCjK2mkRPpk s4Z3NYec88mk1jmKXoqnq3lIaTamt+ifPwqgTYqXp5PIpVcXF/xpShBqo4DXplPJpx66oH/KN5q5 ppPwqD0aqVA6orrJqHYqoZS6grsZfWaapVQKeGhaV6L6NpbJqdhJo/J5D/RJqDXEZpiIi656XFNX Y7caMF0YqFVqorWaUBu3pxRmqqEGqzpprFgap3OwpKFKrHrmZzdpYstaqp1qgsu4iLhlnsIKpNO6 nsnKm9RKp5//Oqt36qyeSq7Ziq1f+q2pOqwjBmwMCaNcoacbWK+V0Wyn0qx3OGQg6K1USBH5mp1n 6nfP6K/EEa4DK5o/KbDFNqku2pf4GK1i+nEmeY4Re60E618EamabOa81Q5sKu64FO7Ei+KIWG6ap eiGjUbIcqayqWmUp6y8wG5VvknuXiogn64pPkrBTB420xXfPh4M0u2BD67NAy7Qe+0iKmip0mY44 66exZJHHSmniUYnwBG98Qov3Kn1UOzJWS2c7K6gdMacri7Vjo7RU2GbxVRTEtHzPBFQluBJpG6UL CaZ6+656J7Ud2qVLy7ER27aD67BYy4k4q7G9yKqch4yD2h7C/1axKviKn6KfUDtF9FC5OiFzgQth vtawoIqxAFK00VSXASsopdt8hbuhZVmrkUM6R2qzTstcNweYCCayoZu6R9iUivuwWsqTithqVWm4 /xO80Me3s1u7W8ui0tGvf3l5C/JLcBu9mSuefgoQGSOv1Yu0MIO5JUc42ku9o4IrqOsS4stS5KtM uQu5i1ujM2pp7iurMvW9dhuzDcG40Cq/+qu7UUKriPuZ7aqfvFpf8Qq3/cs+meexMqqH3jsfFFim 2vq7H6pBDHyDe0h5TXlZ9+cM//uHvLJu2du6vuCUSzl3Imw+unqwmwrCS5GiI4y//EF3i/PCKRys 8orAbUQl61T0q6vrJW97Fp+zTnzHhEOsWlZiW7QLsqQ6wbZFOj1cSEqAxFDJnkjcfGAmPKYrxYQU t3sruo7auF8zWFS8Xiocqz4Kru2rxJoKV6Bids0lsGbMrvP/KyMevMYvabnFZ5Noo74mDL/2Mnk3 fMBqXLxpinlrd6j7C7buksFGVqfpKq0AjGMMW8iEKSvwJT0bfJhJ5kmPe2vLUr0qWnCWeraYGsby FSR3jKyc24xE6IRpKE4yKnESLLTMKLwa/Mkk+8j+q66qvFduDMPbilFv9rNkt6Je+8mVInaCC6mc y7NwdMq/aLBoxMGAm6CY/HKZ8Lx2XMmM6YvWs8Syw72eO8dojMOEHMyC2cbuwW4Q3MTq+HPvC8mj y8xs7FvsvJz4/M5fC5moOshsGs1E2Y9f1psfyYi9VKh0TFXcnM4BTMsRnLdl+L2Sas7/bMriap/P +dDYdRMT5+2uI9Som4fR3iPHH03AvqmmpRwImYrHG63RER2f/PvFIn1FCkzBXYrNVMYyNr0l3bs2 myszsmY8Hn3NKg3NWcfTWofTVfd2YKeODSrJ89fNkya8AwlMAY0oFwvGI22QBi3DTKmirJzL5JyA TcKURBFmfRyyz/w7WG0tGKER9Wi0VNPFipy/4Tw7Dc1jWk3T9TwFiWbFUgnPskeePj3AvAi9y1xD bk02E9SE/SeNGUrWBc3EUG3YxqLNfP2vvoxmvLvD/VeNz5q8fevVJDbNWSTInnzRUZ3Rm3Z28YZv nvfVbbh7oy2ku/9cx7081Qndiq89trG9ejQsZY1MmURN0SmdxgDtWkA92CZ92MG9WHmKrrwcyeUs wOY6s41i20lqwKq90jF93aUtwJZt3K8K0jO92fCqy+bdjuzo10WjuRtZ0d591GJpQ91ax3rNeNvd X7BchrkMXX6U2S3b12Apk+w8xDd0wsrH31rIf4WkMVcs4KlNycpt391Ed6WzfZxNhqctxl48z1vN 2q9Sfhw+jEHb4DGX4qPqz/Td1lxNKMW0MKUo1R6Oiri90Lqt37JIc+Xts+Ttpq1p1C8+4hl52SYO rEk52YCK4yql44sMGIl0JcEb2UyYNy55kjWuvCwu5Mm92u+dnj6c9eBWzpMFiuUzaddHzuNNHlRP ruYk/uZQjrIvLc3dXeFfjuTPUtIm++Y+vsIkTODpveNwHtRDxUvsRI9jvdtvTeHGkcNxHuMqZej6 bMyDK4Oq6aCX3j6dvM1uzpZ+vuj8fNInZb9Gw74WDuZ1TueEfb+i7ayl/hqaDaKpLtBM3LPW3Blv bK3JxU1Z4uXfDeN3wtw5O4fEXrPVB+vO/yvrt1vkkS7ntD7n0M7ShN7idw7sQETQnYnO+U3a+0Ko 027kbM5nDF1mWSzmTpiN2Ogj10iJvFuEVS5MVa4YB76D0s7Y3l7tjr7tMDfloP3Y1/OEr6yJZf7v AV+J6tfciH20AL7w/Z3wHtnqoZ3b1Z3nPZPI+gLq9YQa2EuZd8txag3L/GOhZ47c54zqFe8rRUnj gRUmcChy8b4qdDvXIkOBVEzO1ZyIbp7xzo3dRbe2996cXW7ymB6XO9/xgGv0PQ/oIa1gJOn0IwnR E2fvwa7wFzf0BdrS3R70Jg7uzk68wjiQaF5qmy6XUgf24Y3vpkj1ajLRxePG34CJSGiCV3Er9sHY 9bX+9YCE7u1e8BIv8/X414248lUI9Bubk96s5kZP3EIY5IfvpDLLioS/9oMv2FkvNYpP1dxqz7du +aNur7Y97F19GU9P+o8Y9ayutpAu7GXv+FWf+kl/+vKN+C7dn/kJ+7YusQio9bW/n4Me7v95/330 7voYb3rLp0TORUwSTk44P7nRDqS7cUP+p+2FvfuLivbwzbWKzmp+HOowbf1sur3TCM7nPolSPv61 turOX/3jzvuGD0fCM0RIZPCch1hOHNikS/umFPazr5LNTADxMVXhemGUk1Zr37vbcf/BUBS10Twx VF1Ztmy7F57hUl5vWt/bnP8hPuCQWBG6eI2X0gbQKIFO6ZRatV6rp6kjuxBuvcHIs4g4lpNo9Toc 3ZE7hkz8jDPr6hLnvZ2AMmzi5ProBAPyUBDZFhkbHVMeF+fetKTMwDww/fYuDy3lOD25QmkUI0NM T1UvUlFX1SbxXmcTaWtscUECS3PdfHufgSlagxmIjYOwkpWTj2eGP56bHaOPqaUl+ZyvkX63ia2/ H7sSSbEP07xru9N7wYPdVco5P0NJ7eFNYnnZ8/n9/4vgq7SJS0FPGe6Jk2UIIAeBehriemhrYkQc yzBmrFhtyEaLWj4SChnJ466RRjqeVOVxFUuVmVK+nOCSoUw2NG3mPIUzF5x9Om/a5AlUzDqi52gO PepH6FJYMZ2eMxoV291LpVT/UML6I6tCPkukXTVHFSpLsa/M1lw5iO0oYGfXwEWmCZRckG21bZ1K 9qdKu8g6HXQLKjBJqVqj8vy7YfFdqy2b1C1ct3GxvToV9wv8x+Rhe9nACqp3mDRUv3xN86rMKDM3 vD49W44t1aSMzqlHrn68sPTR1qirngYeHLHT38P7IleOlqzu5c+hR5c+nXp169exZ9e+nXt379/B hxc/nnx58+fRp1e/nn179yjxvpc/vzts2fTx59fuXH9//7T4+0/AAXtQiykCEUwQDftIMHCQABWM ELwvHP/EwweNMMxQww057NDDD0EcB60QSSzRxBNRTJEu+AAcQ8IKXWPusgFNOYvB+w588biWcEuw RmFgZKzCrnKUcMe1ZhTwRwrji+LCF5tMDkmuoOxtJggdxBK1I3fqEcEfFwzySSi5NCzJ/8CEKEpd hrRyTQLL9IpKMh1ysy2xysnGSC/lJE7BGrW0M9Dm+JymUCXrDPPNLKuM09Az/UvTxUUTtROpSXU8 lDVNI62TSUtLGTNTSIMiVT9AJcJ0T1OfYhU/SYm4schZ/+S01DlHZQVISoVclEg9I3S0EWHR9FRN UJ0RdVVcZWQ2WIcCVfZZV8sgttNeqxVT1WmdndJPHysjxRQeWR/ctlZqA7L1VGPFXVDac7vtEl35 UKXIXHDnVVezXCH/yZbXd/GFKVwe83UP1j7GbRPgL13BttlvGRbyUzwXhpPNgb2FRlc6GYv23ojj NVMYLDbml8V0//3Y4pE/c5jghk/mtt921bH01yCvPVYUjVssuL0lj6VYZRp35XXoYSHRZ+Y+RcOY o45TLarPHMiV2pgzmHE5Y4iUjvlRYDdpYg558nzY61+wPtrfmi4ke2yx7fUZ4lu2rkNpn6pmumia HaOw4lbZLjo02nCOC+alt7aMCp7lBRbv+B5/h12phbYaabBDi7xpZL8WuGSzFad1b70lI+iJeQz5 JGpWPLactRUvWaIrekQrW+QxSNa6cdyt8HxZxNEeHeyA5+68OJnPjM4xYV8FbdR33W+fibDn4U1h YnfVzhk+23V+WXrCnQYZg9ZFqv77rr+fBRHUqSc++arSdt39K40WPXrhP0cef+XjUTj7/qx1q+Ih SmJBw578xHel3gHvfnNZ4PuIBrW4lW9+20IfBRuIQeitLH9l2R/nANgx2jGQdBrsYAW7h7D+Me9v BAxZCelmMiBd/69aLSxW0kA4vAwC4gonTODIVocj86npgv8zXLjW57wNIiZ+JnThADclwfrlMD8H k83ybNY8jqXwYuqbGeyMWMXJqbCGYXwVyx5IQuPx5ndGIJ8QUajD9u0Qjkt8IgR508Q6chCKY0nf 4fT3R8qtMIs21N7xEodAH/IRJTQMiCFDKDdESimOgJngHiP4wjVS8oeC9KAnC7cuSbJxkp3kIv9q 5jcz0ieAR9TkHWdowDIqMpN9FGApGQnES4ZNRb305S9BpC9FcQWYxTTmMbO2SCZ+cFB6eWUUn3nI D26ub1xb5TCvCBp2tBJwttwhbPLWM105MlaQ9KMOmxm+GIKOk13itF86QamHN9pvd+hsCDexiUsv YhCep7xmNeNJRVfO6m7pwOfavFnCzNFzl9O8EyFVSUtxiEh1gzGoMBGqzxEtzqIdvdoYszlLJ94w mrck5RDp19BQinGU7SzQFtX/mEdmKrGkA9UoSWM6G4CKoW3I9OlPgdpLigSVqEU1qoZAispHftQa N/vIDfo5giNElSlNFeg25zlBq07RG1CVyVTDstJBfhVwenTnVXFE1faptYsSNdtWxXqNJmIxomfl qvzYCry8zjGu57wrBfdqPVku9WkNyolXd/PPejLusFltx77IikmAgLWrkBUKnrRVWEAKh6GTDajk pEqUuULUmppta2LleM/PvsWyZCVnR9QK18h29h+U3YZsLyuRo3YoH7sFqhd8e0wFBpe3UiXub9eG Jac6FI+q6WZfw+rPdA0DtynRUjhL9qnknpaxwcvnX+W6WlxRt7XwgyYZQ2Ib8DaBhWqTQaSNRuoC c3KXtlIiL3utxr2XpvZnbnUdQlTHhD0kxb/rFCv7ChEluxlYsnlp8H8pQ4YtEDi+Jx3v5QocUhep 18LQLW8qEFs6QGjzNfyVLloNm2Gl8vTBKa5whx+ayhM75p9Eml3qNmLWHoHYcbTisH3AGFNi3beq JJ4eg1vsysDWF8XVpfGMHWzi0H1FLS2bzY3pK+XyvpjJUOZrl79jxeYy145JjpGHTWvmL3NZy17O KZiRbF7Fqhi6Tu7um5G8ZGWimMxqRjN42QxoO/BtX1gjESqKS4IQITqowD3uL4drIkZvqLfB1IVR Bf/3XGg8Y7lzFvSRYXKVEJ/EtuRwBY9Dq+hTa3ol0Shipvc85qJw+s9O07OQV0hrrtp5ezATNWZZ 2FZdF47XOhv2p3V3azyC4zYuy0OxVXVsPmvstSnWMc8QzBYJZ7nMu8o2+C713Wl/1M0b+3YsOl1u Orfh3A+Vy2jF7blRj3DNsh6snuiNMjjfVrzyJkS+u93v9M372/pWH7NTR9AF7xuOigCnwlmtbIc+ 5OGOW3ib7+XwhFv8JsAupLATHHIbR9uyF7/ygbaNcRfXGrSeLrG2UR4Dejb7eSaHw0LLpfLQVtvX fZ51z71d6EQNeyijzo3Ae93FhcMVTETPKHoNfun/VUtx6puu+o5nu+6UUhta/eA0reE7VN49muxl N/vZ0Z52tHd9uxt2+XoOGnUY17KR9041suZ7xpZG+abSFC924zxueWYCbq0eMdtFjOyA23TuxiV8 7CBzeKpXVKDRsqF+8x5jA7fC6P1q794Dv1/c+ZPzLLdc6f2sUzjr9yd1fbA+imjlwQG+0J2JjORV r9PP15TVfP95yHEPZGoy0fbuBbXwNb/6LCp++Iq8OCbedTrom95cP274FTmae+r7vPehr91oIBxh zfne+qLj8EECbCAxG1nuOIM9zH0MueYPGvjJL1v5qbn7hMbb+/CH//nrb/zOrGvAqfMKKvlUzvLe UE494i5WMGo+6kXfXI/h6OUBHRD0zANoCO3uro35GDA1yMXkNsulYOnvtm+DJO6pTCP7Aqyipi/I kG7LcikGYSHzINDcUG/jgA/ndK4B3yMC/y/w47SuApMO1XSwSPTvr9yhA2ewtMZqp1QmBS1ifV4t 2tyGIEYBwCBv8cQPBj0wPdZv/i5DCiPCB0eJCemO+2pwAcEwu0Lpuiyw/96EDO+K9RxsAnXuBmOm CvMwCHEohyqDauahHlDnCnOOtQpoA61tphqKB78Qw/ZP6QSJx/jwBFcuxpBP9x5RmODt6SxR9NZk cC5qfLzw3wTsdATDoybs+Ogh/TBwBM9v9gKH3GLtddjQpcDvExnv94ywSQiwyFDJEQExwriwlFpw MAqQ9ugIuIYJD3WR/hjiALcJB7sL/6ospJLw2eQPz0RpnOxuEQPK8sAg+xJvGtfhFD2qHNYnTMCy sDCoMI1okJXUSQxfiA49S926RzfMsL+K8YACTQ/HTkS4sft4sRYjiXWa0QlTjwjZEA57pRI3MQOT iv04kBFlKDlQbSL2kT3CEAH5xB5rCwRjR2wIcSTvLhIBciDXcAh/UCR7Y+T879M2Eu4QLwidMSLL Y0d+Ef12AR9m8gMT8QmFLhxpKjha8B7GkRDtMB5H0JTURhmhkQJb0lUAEBQbD6fsLS5skCFR0g/7 ThZxki+A8JNYjCUNJg5f0b+E8Tw0UCgrkihhqu9MigTF7xmHoyO1/28Mi1Iud9H3+EkqowMvbdEs +ZH3+M8qTYjyxmMsvass/5Er+ZIgzwylFFLDhpL09vIq/You/W7GoJKQFnIqDdMT/dIpCZOYAlLt VHM1WbM1XfM1e4jqyDIMXC0xaUkEwwgN53Bocmwp38I3k8B24AIkgxLq3hIfh0e7Ugs3VUw3tcg2 Xwoie0Y66WYnD7MpBk4yQUk526TPNM4EnQ85ja0H/6L45vI1Ki4qJ0UU+U3sYPGUuLPCvtMzo1A8 y6cq1dCNYBA/h9OCHkQx+waq7s8fgJP+blLwaFI9LelOaoPKohEZDXIMwQ8/Vc3zVIvnJBEuL/IS wy8W0TNPJkE6KfPOQ0YMLBXPytKqNG6tE9svLBdzMhdU+27v5WpnZ1QyKyMUMYFCAU8zQUHTPkGs FEPTgg4NZaizDD3uQImTHwTCbgo0Fb3yyfIKQDFj+RDUI/eIRw0C1Mpw02AzRapRP7/0S+cRS+ux HZigRN1GKaF0n8o0Ld9UJJgTPQRTErbSXQTU+Gz0STczP+UQJdmzR62DMS/M7QT1DVBxMgZxS/n0 PJlSR1t0EnHUO9rSOMERMw9uTQmD8taRS1XKTyE1SvdwUuvjTT+zZoa0MKHnNgJVRY+GPavSOeWU VLmjTjvuFtnyzrZxV3tMomA1RZmyVVMVOwj/Vc4cc1h9dFWR0PxmTlIxh7ZyMBT7cDsq1TKPMwrH NFspbY5EsVWFFVR+laD89FvBjSNN1S7tc0IalUN5Mq04SiA7C1YXB14dzZhE80ZFigiPlF0jVVRH h0mWNJFGr+2OVR77FS1/dGn0L2AXS3owlHFktQ0PFk770VVBlVrP1UUfVTxEDRL70lk3dj/i1E4P EmFR9WPzkVYxVjYbkzZL1km0tUS4zkyvFFqotCkbtjJX7FoPdWXfYV3jAWgXMd087gsHBS9P9cmq 5GKLUFH29SQ5p2jB7XFu7shubjFsVSuXtmJPpjZKAt9cMmQBCcByERO/r+C0EwslUGe3FlfDtHNV yRFd/ZNpD0dzUm5qN6cxqnVnL9VtX7Y0VU8av49XvXJOc7XMklYG2xYwF+kXAzVECTds0zU7snYl F1dsSaji5ipNGXdsVVZkWbZQC3ZaQVdxE7aDBJRKw8797rXuFBHoMFVVObRJFU1Ie9bZPpdyM7Zm 1Ylhl7FxuzBmEw136ZZYR/ZWb1c6XOJpu7Tmctd4Q9dYXTZ5A5ONfDdY6+t6N4lt6RFiLdJc7VJ7 r4lc5fYud/93dZF1UDV2fVuOeDH3OirXH9O3OnyKUJy3eOG3JmezGO7U1FhR+tyRJFeDeblWte73 fdW3OK21b99Waw2CU0vygRMVEr/Wmdx3cqE31hIXakm3EjQBgqUPQIV2nSo4MTgke1sXfxHVb6Uo IRS1bQhmee2Xgx/TZ8cnIQ21hj14RtvVJHnIdolJuLCiSBGYfieye/1NQ8FXhi04MsPsfLtPfM+r hI3DZPO3gGGLhZ+DiqXYUmGUTvW3ZflXi5eDibtYcRBiTyMjgnVYdxWYb2G3Pg0GmWY4PQM3OYXX NaGY/84YZdWhj43MPEmD5kSINLvsZm/2Ooelf904ygCZDgaVbBC1sBW1ENvYV8qWbhsJWL5weHQv V1d3lJ36aD6pt0EeNokx+JMf+ZJB+SvtSB9hzZDzWI8pNhzIQdIMGeNKzWMjr5S32IrNUWlpsdx2 eTDXNofnlzp+chSF2ZZjsJix4ZQrhQlX2eCoeCmwiNzQB3InLmcp8iOnkokT43R/dqqAE5oddaLI WDnqt4lHUmYdaJaDK4z/RXd62xh6xbmKb5eRy/iIaRaV5VhVr9k3cJWf2XmPZfleB1q0CnqdCRqL nSQ3R1R+bzjV8hmbG9qX9RkhCdaezQwp25QYca+HRWEd4UZ1UdGkeSek5UmIx3mfHZqh3/ib47iB 3Uhtd4b1XJgZrXaCbZRL2TioeXg9u9KA77lZyQNpy1eDHE52NuMLnHpBhfqFJW+qWbFrNZOzMOmD hdNt45aG+fVkVdhC/mccdpqkf/qdA5hR2VFPrVqN9TSZ76OaK6YnrxGmOzivO5cGRzhDPZmVcZqT ebpPB42uA9pis7QH5EHmtC1y2KdqGbSxnbjTNhiOkfpn6NidGQWJDZqItIJRrU+OQXOxstWQRf2V d6fDjGc4sYkto0UutM3W/0LUbidbt2IaOLh4tfdajqo5VAfbJrkXtZUXmJlZrjvbfGcaiaf5e5PV iVUQr48aOZQasGdOnleTuCsLuuVaLI/Xjz8ZX5s3ujf7RaN3mW67krBTvHczqVs5L/26vXMSu9tT vZ+TY/fLOXpbvlM5mI37vA8rvcF3NKcwNRctnq37qADcR9NCsxXI0b47u/uLwl76DyE7v/+b+wMl fKNR0L91++jOcn0Nm6+OW5kTPFTY+mIm1KcJ27ezDng1+qBbPFkEsU13GkTzFLQFI5FrmsVRy8Xp e7hj3ELOelFPPLB7eq1lIcMxWsQ5nMEHnDjYOKdn1MYHm3v62mEFPLw3/MWlu8RrIG5r3BJacaSB mqvNmzO12se3u3qDHIxruX3VfLeNuM0Pt/U6/H1GPLW93M0pIcR7t8knPM2Bss/v/HsJuc4FXWLt 3Mljt/4GPdH5vKgnK7Nl18MrHc1JDb5j7sN7/NGd+8lH9tAl8sG3pNCxl9NJndH3/NQv/akOXO30 O7q6e6lLnc5HPcuNumItHNebYdclfdYhnxvYhZvNO13Rh53Wg8ggRT2+bZ3ZL/qhu3uTvVTHf1yR /0Nyjl3aOCj9HMXartIrnH+dQNFBKXjwamVbE3Ma2eX8sezUnFP3twmP4vQa0EUZVckdx1xxahHs XbcwbcX9VnV6xo388WJkoUP5zZdV89IYbx1bubOaSZE3rSVZgqP6qn+aTdMaxcMd4hG+mXt91YNT bV14yG3DzIvcU+PdXlVdQUniyn/32vO1yI8RSqmc4kVszDXj2WX62NV95WEeq4LI4KtUyT3d0gOc hAmF6I0901E9L/x8wVsd1Dly25ec1xsZ0hHd6UmJtO/702sV5Jndkc+c568O03+T3te9J1LY7Dfr sSHZuqx+kO8TCkD0WdXSu3/+wtl+ZvMP4Mb+T2Y3TDERmac4tcoalEbJPvFb7dXXrpbTc7apex8p 1Kk5N3Bi0+6BjNpNN9XBfragvm4jd2+S8PjyVu4fnvONHqOVPtKZPup5/DRWP+tTv+j3HtQ/X++D /ei9Ptd3v3Sx/tZvH9o3PoH/ix2MY/+/O77Wiz9Xj7/zyVn2v53Tg3/nh3/Ol//Wqx/Cs1/Pm529 QdzUXz88rlcfNTIQFf/82T3ur/j65TeS3Z+qt3RTmr/7Uf/3KdqqSV5Opv/g67/qCSA+pi53AnjR wFPDpVO77v8Dis42mieaKqUKQi8cyzNd2zee6zsvtz8wxQqqfJwjZgNLKodElPOJsUirVk/0mr1y u96tN0wSk8tSMDGCNrMZ63Q7Lv+851o7Pj8Vq/V+ilnd3+CPIGHRYSKX4YmS4hwj4uNkUCQl1mWm UKBmmSVUZ6iLaCWpqRvn6Z2naiugayOs6mesLByrLSltLm9vy25vCfCYr+ZwRDFy8sKx7QRzw7Oy VXRmj/U1drb2NjW0tAl3z/djN2X5eGEqOube1/rhOfk7YXzIPPHr4v1ffWL/Ph0E8f51GigQoB6C /4MUIkTVrgvDS/2c+bPHIuKZexgbCgy3g6MEjzkqLrPHJNRGPClBUgyzkqS7h/6aLMmHUiNISAch 5qTC0yc9iztNSsTZs42wmD0VvoRWUybNm/OausmSIYkum/qOMj2K1Ci8ixWuSug4UyQOr129qltH dVkTsxaEOXu7QuuqpW2rAT1ldy+/uHPlziW7cGjenGt/mc1g+OnYF3KfMokrWYNhXO/+Yr588upj zkSnIWYJeESMvkll7hniyKZrvFRF82F7ukpLvZolqd4Zm/Xrh7/BbKTt0rYntGm53i5y4bJnyKAj C+5ceIXnr1ORk5mIt+Fi7j83iz8+njX45uVLbUFfv7W7WvXuGbefj1t+/dr2709V7v8/gNbgR15y ARp4IILG7Sdegg16tCCEEUo4IYUVWnghhhlquCGHHXr4IYghig04IoklmngiiimqGEcBADtQSwME FAAAAAgAeSGQJwz9cv5QJAAAX5UAAAoAAABwYXJ0NS5odG1s5Fx7UxtXlv9fVfoOt5SqNdQIgcAQ jwPsgg0Tao3tAJ7U7lSquOq+ku7Q6qv0A6F8+v2dc+7tbglBLMaVmd1NKjb049zzfncOf7y5/HDc bqnDH89O3tMPSh3eXNx8ODs+f/f5i7o8+fjl5IO6OvtrT+30+mpLfT65ulH7h9vykLxweXZzon68 ufm8dfbTl4u/HnWuzDSZbxWuoyKXFiYtjjqz8XxkzH9M7MT0yumbnonLTvP1jyeXZ0edv5x9PLs6 ufl01VHvPn28Oft4c9T5md98lauJHtlIDW06MlmuXKrGNlf3Ni30yKg7Mx84ncUM9HDbk3N4+un9 f+Fv/HQOeOr64r/Pjrb6uHK+RfS9N7kdperG6Mnh6RVdXkH14Ta9S9B+vBJYn4//LR3k0x8aPz7/ J2Fy3EDhT7vHn3VWqH311kM/3D49Xg15+UfCo398MzZKaLhI8yIro8K6lGi4NoU6yaKxLUxUlJkB L/pfCTn82PhFuALClTq9Ojv5T/olCCsvJxOdzTvA/eT48TtQiauz8+qx3riYJN9V71zLD/Sq0BQe n4Ivr5ce/pyZe+vKXNFNtfF6c/VrB0uvfTQPhX/loH6l3fpKiTVB7wtoS7z+vnO8D1sQ3YE2Kp0q WwtB5abgw5gNLz9r6LKJLnI6bLcpZOVvfIszLq5PJi4uEzpkT5FO4YriSzqzxfxbnLGb9WcE/zXD p988BeBbrGyRK4jJpDlI+yY0XWqbnid6xJzbV/zjenBffva1/c3UZ0NJ6IIa/qEoXFy+b6Cwq+gC o/BHYXBxdnbWwGBP0YU/FINrXbzTWQOH1yrXcIa6MNuRzrL5H4rNp2JsmsjsK0dXRC3UtspMbrJ7 EyO0mST+JjbwaXqpp3TagYLvTOzEpvCIyk0jFxsE0qly9zjTmlnDLa5w+pXPX7xVBwFxiCECvEPA Prs6PvwCAn7XR1LoQ1DcxsPb4cWv98+tT2lkFPgIb5UXalimsZ4g09CJGhqStcnZv0RjnemoMJnN CxshbRjySxQ4x/retAbGpEqPMgP+l1OXduGRFPIKPJSq1EQmz4lzhVOxQeohRy5R0gPera/D+txl DIHyjHBU6grkSZNpYgqTzBVAazsaF1vwkjNkNF1l7oFLMXblaMwv60Z4B4AW9Jr0KbcEw3tVFTsj oG0aJSWkPrAj/Jy6e0145z12x5kBw6aZGyRmohKLVywdZVqAD7D23qiZBvljyBAMxXmxiWwMZvEx SO5GZFWxf434KoCbAWs5JWltIMpsqqGOSEgqAZIQC1JFJj0t8i5DN/cusUABcchLREFOOC0velWs isG0DOpt8lYNaUnmQ8/0YckcG5hIl7lBBmlUpNNXBb2ApJK4ltg7A0CkHkBcq9xFdxAw/DipW+5g O+n80QEVEnxMYocmn0LhRddas7FLaqERBkQdmP53sAOkJolXKgmLJBwV2zxKXA7GQrLQ8RI6PjDM I3A/M3FLgyNmMnUZqScBBIy5mllA8+TMLOlMQUpgI9NTJ2A+Dpt3+ThiHj89MF6141aeuBnd10PQ o4yOxqRUyAVYjNE8Ah0zRsjzTsWZnhFWUDEO4MQ1gg7+DssEUoFYgJsYEgkSPNGck9mIcozgkpy4 wzUs6dp1V9niAgcc6EgrXYIui4oMDDhtvPXVltfybFCDuVc2V04hejcxHiDVIHNvjvrOqGkCFfbc YgWzGeQEyRaumE+hkiALUp+K5QxKm4jmZoyA4A+FyOC3WB6PnUFACdlSQeVOgfqpBR7OkJ2JW41B NXw5zLjIbHQnR5WkOfBZRueGU6wYzyRuSh5yHW9F9Dxm88xlnLiZZNiFPlioCVDb24WLIf7HoCwo 7DAxD3YAQggjpr3VgERGzZSJQxTZmQcYSUGu6dfSkrGoe+SiGh5KpeVkAFaDfjcFyWksPp4Daa91 QwZA1I/YH9ZOaWLjODHB9QP7JCZTpl8IYw67ZIYuEkUHMWCcNRnDDCq6odWbrfp5xlzEkwcmNHjE yrVJoKD2JbtIPA+zaRlgXKMSqw2P5Yfr081gyAAMz5IKOpkZwc+AbgDz3JIEgiBt0K+XeFVwtZOJ iS2OU7EuNJtoxqYwzNxEHZBO9A+IauHcTKw4hAiyavKVMycntKqjA79D1JjAT5P+ZQ5ggdcQkqst RzIbYQrBhyJMTDbCA+STJL7UvEJp71k8G3OgMxzW2BRMylGPjukq78aXaBRxyDEtpDmZm5Gq/bwA C9yEauVkygLLU86lR/w02I1G7G23atrKnF0pbI5zAwoncMiTkjzmlJ0CilUHlwe13RSLC9lRlTsN 7QjB4A0nT63Di8u/qOurd0cdOIJ+b2SHHc4CW2qxc8Edky/H8q56Q0nUl+PFJM9ndkHJmlpJESan /gj3HFpV4tX6ep/wMysndU1We1/IF3qHeq7kZCtEtzqVWrB/r+8tRkxCGHgpWgZPAmCBiko6Ihiv H5XLRpwTf56YYUEiYajgCKQ+T/FLbnOvFBA9pX6K+gSc9T2PpDCNNYb9k3cURrSBU3bGd16FUw4L sPcogn3DSpK5R8hmlKg2SA8HI8paRMNWfTfA4iAkrhPEUcPLAD2f6oXEpjJTQWeBG4jAcGZzsS3Q ENCvDVW4nVOl+ojZtSnUKFXZTtxioIEIX9UsPhyOi9cIO4yOQVYRS0yDe0DcA36SBNZVTK/1ifLG MsslmGamPjckg+Kh2CETu3wOKDAQNE6JVcMmXMBLiwrOXepmKbldzbG368V4r5PSBN+GUOMTKLxp hRmielUqQLKY6Nh4OU6MDsHPJyPnfQr7oBAZWxcOmk2ZEgHEgIFFHjxv4T2oh8kK+F4WcY10Uzhi EGyIwa/DO1eZfcjoXCapGV0y4YpHLzGwj3yFWTAzocudINZOk3PMFEAVzBKNFGDiKOVgXQ9CpJsM hJXYDuePHAlKDEd2AxGObCQy4nbRvJbBIm+IvXdmWoT4mEMn4IQTynoC3TrPzQSpSCtBQKSWMXOl pz6lydxL1aT+YBKszyHjMqMrBOFlSZQXOGJI7EDQnE1iFuoZWDfxApnAncjM6Az4sH1zPSvuwBsm JZMstcqnrSxIGxlupVQ99dEhO0Lo54qByrjcJzukmK1QFRl2ML6Grs0J2jz/zZd9VJyUeb6cKTe6 BFLHN3rFVTNzdadgZYPzH2sQtNmNSIucEid1dXH9bovqO7JKUmh4A+b43u5WSFwXglOv3Uz/qrDz ZqtOc7lEqryvz1jpsINGphisrMqa2i3JEcigiYvkl2qXK1bUSGzZPQ8daQ1p4sa0DvabyEkoM0aC M3YzRf8VFIm8Y3LZSKcwOTjf6RqM+8gFo6py82UOiEG1Wx8Mmfg1dXiGFkcW6pQSy+CauDHDBC6n kTUQdekWQbRbBGOhShqQI0yRh5FUugu2rIItUz1UhQdfGvAJNm+jCkPJrN768qymSDorUhR7Bi/l sL72WZJNu3Kc3s+EI6Vvwa5ffMrKPL6nqAtkHjTH8Lcyx7i5IUvQcdwbqKzfzXa72R6pP9K9HxQu C22DeVE7ckI341qa/UPW59PxJnUUywSFKMU2nLsHTT7cvrmpWopracPNgigXsrdgqFR0vfUtxNq4 iaqT0w9najCK4Pmyo85352/o3w7ywySZgiro89Ee/0YWQb/tqAGL64iHVkV2TOO8Im7C4H86cKPQ mqNORr2yzjGnL2/9w/4WslCwu3P8ZvXlg290eQ0sufDyWB7vKGHx+n997yG8WeOd/p5/qf96nbf+ 7N/aXQfb3f3w1sEab+311+JlyJWfkvontvHV97gbv/rWlRmpvadv7T59q89Wpk8Tc1zbwr+0Bbz+ Rvbyr2oB/X7Q+d0Xn/T/zwIuJhP1hAr8n7OAJ4jp/3N1/SuVPWhm/+V29MxfbWo18T/fFPj/dst4 SjVW67+g7/Otv6HQG4RZArWgXfoLP7ddZUyPX6pKqHpXY3UNtWp/4xuWUEsVJpWNcoyMWV1KbQkq fW5vI6Ttr14tzCZub6n8d0iMX71qN5u/Ujv6XsjMldRZp9FKeDHiOnZhZOCqAUmd79MtJPr4PZvZ 0ECc0mSd5nZSPdPIzyOxQI4vlqitFfk+fVam3GrgAlH6vjaNbeSrcU+tTBg08wNHjHUWzyzNHa6n qK5xypXP+PPeWly/KKr5SZnCD+aFc3FdjlUMXiUTQ2UYWIQa954KWq1QKdqJTtqtpaYS9010FGUu p3njcGh4DrXUeeipEx542inzKdBIowIqrKAEmVmQ7qKwwDUzNfgjLajGoiGEtAnDJLMeRluaUtGz VLFJhZMaQ6NmCJgrDYjSl3+WGrd6Ok28SPzle20THhRBkuPUd1t8qaaTkYNJjCdU168ljp+J8Twp 9KPbmb9QadO/qxPS/KwMU6ZyMuh65XyscHnoy7VbnbCr0BHxyuxOCtIwPsCdjIcgzGoWAD0WeC+2 8KAim0Ullc7tVqO8FCx4BSjSU113yzKDFyckGWmeUzPdQSdG1AecVzNyLe9q5pwpbNRulan15t84 HdizJUSaPAI9IiYISjPWpq2BXi4fu9JFGCZO0yxza+os6d/yE9QFlPNt9Hh4cH11SjN5PeJTFu6j TAeGJiWNiKvZEokRDJ+6lDt9ZzxtJAv6QnS5ukOvA6sqizBxj43T5g3huPo+9Yizksa23ua87+QB tAyacMRgriTrCQ0Cchnt1iPKFjEDL6grS6+VKVfiVef3iaEZ3FamYWQ5N3afDS2yorc6rHzN2t63 DDPQF2iKtDsuP32+3r68+Hyt2E+QbfHksrn/AnYO8MpdYOjIJfA27VZtjMC+2aPTfmrcry9y92jB nVKDTTxgT11LKFoSkQctaJOjEoNgQ6A5agVcgj4dQcsIAx3d+WlQ/Qicd7fd4umkeEeGB7s3jYeq vpYAJELIxhysNHXpFrU3l8wjg3VNdHZHvjJXh4PjPUjxcHtwTGqOX3ezXfnVd8pU7KKSFLlLzxfU SJxQPoX7w6SkSCqh0DfJicPMBz9T8RJcjh833FrPy+nUZYtuc4PwJq+62XtGORv7nKs11O94fgsl XOBfPta8fhBGLvX2AYIrhFFYk4f9B3rSt9tub7l1SHmOKwsKckFXmn1UmkVadu7EHbgTW+UiYRtJ 3JUwt8ucx5MU4In53JjnuAB3I51lfjzXkypi0PJPmOHUPe+RSauwu86eIfFHht+xYzejE1JLnnnz yXPI/GHF1DmMR+H12DKQudGLU78CCcrEHMwDrVOBtklqJi6Ft89dtWikk5meS9gapX6K1DzEZxD6 3lnplbZbIJlWsYRWXhoZ5Lx+FeBX4+fGfhJwoYDFki5oUAUG0oxIBEjG2W5BPrGEpubQtIZKU9qw ssLJ8eIWBq1XbJD9uYytb5M5kNL6GF/O87Ed0iac3PX8qpGtD2IloO09Tb1wdgpVy18luiBkmaC4 9MuSTYQTRytNvJQCEX3JG8thJJf6XLKCOK73abg4J3folZ89BbIxg9BvH+8F0JZL70nzbqxMe/P+ 8mh3WrYc1suhU9n2CFEyUJWLiUkCz9UKsQRp61RnMB122PVmj/i7JtPCBMM1iK9LEBrDVCUMrwF4 vRRFxw8D3unS1J7nMWdzTyDEhXrWw8Odt4FlUmpyT4VqzKpL8lwrZbGD8vWlLjN/g+YNm088UA6H 9sHX8h/BuucO2tl5os+y+vKpB3uK49WzcJ8A8ERb572H+96V4OsWgX8Oev8JrJ9om/7kof9U6vj3 YT+B+RN9KgqVQRLHn6JC8wFq42eowGaz63C4XWvJOlOeC7Fbn7Aujdcazo49g+SZMivTFLwKqEJY /axma1a85e1tb/DqVReW1ov937/C3hCJNJlIHVjrDN2vRCItKnjvOHa0pRtKWnHYVBkiZwJOPeWR 14Oq3NeCrUet4dSAOpXKsLTb237/1Su8XG+E85xYxsHtFpI+HpC7NHhFeUNxEOexOVxe7EHt4MaG rEDmm7JdaDkS+MDFDldn5HDbLd778xlRPXGcaKS1qVlvVhvW3GRTZ2FlaiGfFgrqLKCRaIi/hs5M M1OETspQCGCe+aUu3+bIfXMjq5obPvTWaw2iRRBuQSUDcYhCZmJocDpvYlr4SpqUaCa5FaIj0s+B uzd+o9QPwLkOJcaFzalQzoOdvNuH0tPQMpe0ZJaW6NVQI6qShjrV3+URflft7h/ID/v9Xfmhv7P7 mif3poieL5kan9kshK3G9zYviFo344WVBQK1BTK59qyF15Op+WI5IiEIMYMWaMDhdotEzMIazv2K U+7VhCJ6wav0XBlAGryi7jh8U6MLdlZS821cpndhD6Kii1bWXerVIg+5mNyR8+g7Ar+L8OjAF6p3 zVVf5FLNVKn5wIx5Y4nXOzTuZxPZvhKGdeVwXr1YXNmQjpNn24KT8zuIzJjwOK+gOr8v1Ji/dzm0 f0MCF4hjuGJYi+iwtHBnWEL/xaBgGo2chcGFHeXqapWhL8mZFEr8KzBgX+VTt3XouaYqADoZSTJp fz+sLEs2hBVkZpSWZYbTjKXgIkYuW5NN22a5oDImiaIQA4Dq44/FNlOVsv1Oa6TxMduCnTe+anuB nZ+vRupx70sYF0RITKFjv99/LZ03q7koJywolFWpptRmInPGMy+gGewH+UsLOVUts4LFNXPwqBSy 3kpEpi3pLHPcso2lSrV51S3vLnxrBK87XQo0lUb6pZSw3pSZ6pu8mMxqYHVe7bkGdaja2fwhAwO2 U5NwZu63kEMf5t2ONGiHGkox95+ppA400gfoVnZ8KO+mb5qa5Qm12uEW0sJ/xBFO4KovNKsDYCuR lBJ5cjnWlVnVq5+GD/nYYTao4HYd8xLu0cRV89TS5zsFU8jt0wiJj45gNSF9kMI3d12idslRLfZZ urSUJ63vMX/+QXxhycfGe0PJsnhpB+RKe/i5vsvCR5QLur/ya8oXRTtiUtgqKxsLhfxhGRhPNY2Q l5cDiukiMkoAJiTK6dI6OUt9Qd0q1Wx8VDO03Khpdun8wpkEKu67SYeX+uUUzd5Kp2SNieWWgnZK R9CoMXIR/yU64X57OyND0ZkrU+TEm90XQA8iUBu3t1FipwQGdvQCSNL9XEQTJqdTUf4q+MEtcMXr 03V2AtV225/6aiOl7+1TAyAD2MXmet2lzI4gcSufipqHyEylbUM9MdIxy1uspNa/lnSsS6shhQ2T Q/p+DRKf+f1ESYBVRN9KIR4hYLspfQTgv50iigU2UVvltXKp7g0z5Ihju+/RNvrP9deT/oOaVbD5 sxpxU0sLgwKdUzVU7fzEwKTw9kXVYGZt3GosNS7vya692+k3O9khMY6EMNjrx2zGL49XHPjuYI+y xIawuzV98EzBwkb0/YdvcyPPFw8cZEQvdEhBOo30JW8cslN9SUYNtjBJBfd21iOw9rzVOi413KiQ qDTYT3x/M5nDGRuhIYOAV5vlpk/2gugmoXTckMJWkdEp8qXefiT5qNQ/yM/7oUDoZk+9X3bldzbl T8KqQNytPzWCOVrmFCVUJubusnOZFNBIkbwXQPRfe6lT9BNgPBAxKR/VJEIHcVK6tZS8UdnFZSHc jx/2+4zNtwNoyAYbQbhN5pJMBz7XoXODGL7J2XOV+RHljUreg1ufPOjywMYxKbmbDMIS7sYAXk1F spxA8tykDz5g4QP/1SS3TTlNkubgKDVw0Q0ekRKZLBQ9zvkFCINQAZE20pudhzc7Ozt8d+fh+/Pz czZeJKdE1s7DTn2TVljWI/AilS4sqR1/WtfUtdAoZgGLrU7sw9hK3LQPiXs0KArNlXjV+Lgv2+yc qHv6uMUim/ALkdlblp8xhJYxPNjS9MzH00NeSl4jWnF7vBwMGlvSitrkP6hs70jI76rs9dHA0XeA awdDgGf+EPi9bva6m+178NTRlXyavAmXfuSnEqo6uasPRIi92evAZe80UmrA778Qk7GtMTlYiQmF 7LVQOfCcl31wVrqvU7k6ctTBbQOq0hFed9TfIJhf2Gt2CCtcQI7mL/CukMMl1Jy/sGPblNki6YUf LvrMr45v1XdAMmmEKj0zaay/kOPZFI9/+P9qQKZM1YH/KM536BvfyFMnDomxrC5IVYEkPy6NDIPq Ga20Gxuz4fzpscYZPLzmuaUkzz513ldy4x9pEH1wOt6+Lh4tRgWzhxX/T3Pn15xGjgTw963Kd5hN Hs7ekNhgx7GvXE4RDPFcgSEDziW3tZXCeMbWLgMcg1P2fvpTd0uDJGYahj+pe8jYaDD8piV1t7pb isAtd1iHsZfse1YkSCcuQgSBLfpkbeIwhsoPuQqRTeaiENWD9g3mYk7TuCBgXfCAqz3InmG+KHmW oosTywmYbyZLS1lgU/0I9+V7f8q1FMSP7kpz0IFc+xHiHNktYaGcuHTWZ3JRg/srSAVJ9+xxOoEc uVEtpCtPMPZhfKaRo7bKYwz6dhdpjYR+RF5CSYv/xS/GN5EdIUeaSYFBhCdeGCsnHt3wrmCVvoMB Yw4LErX2UnHX80tQtkiQQGadtvphyAAUzm0IQUCoRkjj7zgtpSC8l/RnL9FlUkEa2Z06d91PKH5T C6rfvN5RHacmeROyU9JKtDiESSqSWI05ZVuMchz4JF0o2DzoUqEMbYknArVWefHLNMQPxQNHrBBn s3uzj+UOuvOlCOYIstunb34IKvW5DKot77Y/+kuOH/nx0lqCRwmMo3CYeBhUH6D0oFoHOh6+7Nl0 P95CoRjOAkjTq5LCNKSgVNNDOJx4NOBBzSUhpCaxPiWtpaOoquqcEmW9sW3SB++GErt6pUxU0gpD mGx0X8KcsN6kpBMESBXK50aPDR7zjiKK2C+jcboUx5pMKvrSE7hgGUG66FcdmohhiOWBtGBOnUDU 8XpDsqnq4Q//McMegy4DUcFnUikdF9IwT2KyIhon/JFMa8y7qt4Dp+ppVBkGloTj7nNSeLR9Wu2Q NmIQ6e5BqoylUjb4k+dQbcRCB/ZBu66DYdgH0e0d0mjGClB6CHJUVRrE2jWr0jz2gULGTvM+FVOS DntWnWYVFGk5lXTflVR1GtaGhvEEjpC7vcAnS9TTK/2Z7nyEj06V9HyXr+ceXwOaDIuFVcJHfo6p DaQ+IbdAm3SczfAFZv2glNoBRECVvwpVXSqcQbYqNaLQAa/K5fnxJumQAEW2kH7R+2Rx8ywdfuPE lTvOUKQTurIrmpae2rV5rZN8IiwuoEQT7YwcpKc24KBIq2ntWh4qgFQ5WnWyC6oU+xQkqUvEQEiV +5xREkQnn+j4hRKNSlyfE9eKxQ1cjv1VdvOYKf4HvZxTEVEDLTeGCwbZ8nYPyGfKKZiAv/Lh0oLL Zfa76jcqyQ81XdO/Ev4J9f6mrGMwpcheXrQ736uXlzTK8J2ytYT7SdXr39TPvdnhPhR5Os3VruYp 45TA0zVgUjWvuyraOJ9L3t7nfdWpPHZFY1tHm5z7F4ZhVqP+w/mBf5GewKofYaB+1ePZeIRK/iPs SZMdlwD94PM+T6g3S+YIVmjJ+rZoRRaXOC1zgi1AdcxTyfWX5urefLTJ5D3qd7laLya8vafKfnHU dwyq5rQhkRDW9kVHZgGqk40GngG3s4Gn93rlyE1owfm25HY88E4Zqhi2JEmo1k3TYJKtcArYcEU9 47fWoNL739brTQn3QIgPBTp1LVBdSJYnP6EF6NsSzOnVLYmvzFmPuD8gqGrNZOoPSlCnlKtCjjLZ Xq816MqbmQkopyLY3P7dKi1nMiQuSvPS/2JIU7ZC3vZHxhx5c9HLnCaX65ClZmMtOcq3xIgZ5/U6 wS5OlbVgOcMBtFqOvi3I1RXgelgnDFY8Jk+r1TY9Ldlagj2SvNS2hMeZDckgNJ9vA+5aapzdmMCQ exzNEK3T7tTaN9c9A0/fzxHffgbkB+e9LNsZwyZGpP38a1P7ydYsmCxpXdcKoFQ483AXEspl3USR rbtB4WzCKLxHlOv6JwNFtu4GpcKg9G8TcnU/dk0/N8+3hQMyNwfiNHwy6I/IN6tVr03fTLaXvGFy W8brYen8dnoR40t5PczG/bAFWG6tMIgn5LPVWh3TaYP2LKIsNZXSdFSeBeIusB6klKmRQFgCyil8 ABIpqe+gFtBeKa3SXgC5RHlVOJUPXx+mYHUHLMwC2xYWp+rxy+cCq7sSC3csMnad0H9SHuVXy6N8 ykJiR1wBIE7JG0C+TbRbKR2xqwFBaqTlm1pEtu5QSkfsQkCMhCbybaQdi4nT/8l4So5Dtx2YTkOC +YAsSS26p+swcSZgqCNuTTvkBu0r9l5zvvRYRckfcUp+qMMsTTvOAu07wuFU+bAilK/XrPiWo4d3 sohy7Xaz1r7+UgSMU+XyyytD5e31KqY5xDvZYJnuZ2EsTpXjJlDi6l75jZ4JRvecb8/ov+7VTaPR rAfqZUYI98MSQk6hE4UwEP0FxmwVcZIhPId1vspYNiU5Fe8KMXABp4WFuDLYMafmF2QXLMhuunvZ HXOKX+1CNhCrC4j9HYqPVf9qh7QJtyjA/k+QIGcQpmM19oK2NX2hvbDgVlEox5w9gG8VKY7v8Kwt qpW4OMNgSimwqYrPzpVoOGtgSSlwpLT+lFyJizMHUnOPJ8j10e+1OwYX3il5t4OHe3mFnWOwCrsd DKfy5SzJcYe2AsxZB8QSc2LfRRbELAhapNSCsHcras5owBHZ4Q9NHtS/2OTy3hKRWu1r0L1LLcda AVtiHGfBHG0RkrMdCyL0F2S4fPGwMeFm+QOFmSlHcbrN7uZsCJzAkIryW6/uDEe6mwWS46Ouw8dZ lVioRbRvrerFE6T/xFNu6sVA+3UDNM6whE+T/ohWZPWvneq1uSaje5KRftk1JmdxkrtHUuzdyxtT r0N7FtaWkDhjg//vAq3V2p98M+6Md6C4Ef6NsOgVFbf8KV89QfsIrtA2Gs9KsBVbXrAs2BqHlcWn CNqdSpEn4KwPcor5I/juMwhkFym8gAcS+AgFNZOBPUoPX8MyIfjPMqCi7+2SB+GMUaSDCg07qBBh IQ9cdfws0go5w7g3ii3kT7ilS6TjCg07rhBhAQdcd0HEWZtIlyA07BqECIsQ4LoSUasQELc8idJY R8OJdeAdyQQ/FqA2zGidcHYEYhlRGuVoOFGOCMrt5Y+tI3GmIxL9yZSsR8OvdgLTgNA9KSj8uQpW o3nTK0LGWQ6TrPs56C3QJf+dzogQK+DSl7sA5WxHpAsLGnZlQYSlBXBNifR4zRj5hXqUsxsoiLnY XImBdpA/FpA2HWScIYikticiaQdMINlegv179ynO0ZZwWHUu/Q3CkS6JiSPbJY68bhvnPavLdZlP w67zibDQB64LOBk1M6DLXxdTn+9ZfW7UMjYWihkjXc2ofllFYEDoPRXxLt5z+n047t+VlXNRtUL9 8kbJg2voEOx19h1/0nIimoWs4Xs2DUFwv7FYtqNLbEaOxGV7Xcxav2fzEhJDpMLzHUxBnCIP9PfZ 4R/gi20Nlc1ZSJIoRW04qBGhRj9JppwdQJHNSX0XVShWkQu7dblydgKOJA5pAnV77cBMn+Mt2F81 xk3D2ObMoco0B7EIHpvYgC+v2FMoiyurw/MiLGtIkE1sAIeYS9B3UYVizZ1IAJsfxiiOe8qmOwAl muM2XNxI4bKTaXuyPWUTHyg3g9ZfwBWaN39CbV2+nEHCLX5xjMi1au2q3moZyOpuNmgpd0YV8TJO OYsUj39QrUyr/cWc69DuvRmVvDduBWy5lmcorRev6GAsT320d7gEcplZgv+UIFWitfZ111GjA6xm skhF+WQF0ApsBz1OD6Pdw9OAl6SWTpdZJqB5snC/ZvA+/TxgzkLdh7Qw+FQ3lwX34czBy43/Fglu nXLGR36n0Ci+zZId+ckTWDEkthT2UVXB3lgFsI+ucLLnaTEOzqrIbxQaxLdJckWzOdIZZzlgGMfp IG85A5zRaUeZYDa+/n8dYRGvj3ulk2Xfvl0StDtbakHiuQExseneRtwqO53iL5mXZ5zl+DOeUIr/ X62Omd+Hdmf0PZSkWVtRM8ciSWCr/z+9BzGaJcvFuWxFI9d603QYyDVh4IwEuI/BGP3iTr0aT+RX wDlV1rNwa7FidvlsmVEBGGGhu2sefIcFL9xwea4SKgjL2xSVYW62rQQztLvi8/crv5f/yBfgQbFq 5TM2QfIMZ7OoKp5v3Vq1adVC0d0Snj2ZIbXl02klQM6iPPSHpL+vqk1TgUO7Q7ScYnUkzqJMI/K4 gobpcE0jd0m1TR52vTK9/Z70lRvYDT5+71YtV1DfXw9rZcbyIbtKkRDTMJn1H6dz0KDe7VVvAhdW v2/nwKyd+X8E5qxNEk6F/IO/FW098KtN/z8Wqn7HdjgP8DCBixfmufjyRSeo0y8H6W/GQQ3nVwH8 hVU1AA/xDh8CjqV665VP4JiSfz8834dhWjdwfvCxffkNf7nqtZoX/wNQSwMECgAAAAAAqSJqJ7JY 0hUiIQAAIiEAAAgAAABJU0ExLmdpZkdJRjg5YQcCEwGzAAAAAACAAAAAgACAgAAAAICAAIAAgIDA wMCAgID/AAAA/wD//wAAAP//AP8/Pz////8sAAAAAAcCEwEABP7wyUmrvTjrzbv/YCiOZGmeaKqu bOu+cCzPdG3feK7vfF8BwKBwSCwaj8ikcslsOp9Mn3RKrVqvGQB2y51ou+CweEz+ks84M3rNbrtR 6rccPq/b7+04fr/R8/+AgTR+goCEhYiJih6Hi3WNjpGShZAaRBhBFJcScXpDI5WYm1Khk6ancqUX lWatP5yvsbA5qjW1qLi5YLeafbGds14WwGlXvLrIyT7HwZi/z72yzUA/1NNaX9iHnp1q2g+ZdMrj 5FvM4L6r0MLS6LOu7+zW887R8K3Z2eLl/P0855+GiRLCrqBBd96axZN30GBCdwgLnmvor6LFFwDT CVQXreO7gP7gHoqkCDEkQU36gk1UeLGlyxMZq1EjRoiYx4hZGOos6bEmNpUkQax8SbRlzJz26jWk mXThSJbTmuKEOHRo0av9jiKlutXPw4Vcw9KDyjMlQrPwTFjFylaZ1izWyHKKK5PuXJkOf4bdiLLa 1LQl1rYdjEvwmq9sDBNeHEnxGcCJGUsm6vix3ciTM1usrNlS58/lOIPmO7o0KtGm5aZeLQh1ates Y1eBXZq27Nv/cLOwrbu3rXYaQ5gVcRmNVd6+k8Ow2YFZVWTIlUtfwZyD832Fp2s3/oxuuEw/Ac+b 2VfY5XAhe4XX5q34XYX41ANrL5Fi9O34if9Kee99Wv5AUf41XIDxpWcgWhz9t9NYf4EFmWr5RdgD U2AtaCFOT/E0VYMEenZhhv2VpE94Sklo4hQUCihViE2BuJGLARpIGoImfVffWSeRWNOJPJKyjk00 bujUii8SGSNUX+mloYhiqUMiRz1GScuPHe5FI4AXSsVhkywludeGSg43Ijo7SmmmDSleSWCIah5Z pZVZaqnklmTe6GWJZ+aJEZVzxUcffXcB6qaId1rpnoxLIcakF0Bupeeju0EalKSUClXpfZVqh+lk m2aqXKeMgeppb6ISVuqot53alqqossYqVq+2alqsRdEqK2i2vpTrrZpNhNiAaJLm5nkH2WWsYbvy yqla5v7tVAxw4sHn0JvABqbstZNa12yFaHbzYrTyRJuQotZie62v20bEoEpznrfjuN1NG4+46t1U rrm8rjSmilvm42y1XUoD7qJMwpvtB8niuypMXCnIZYVi4llWR4UuOtbFayWsMKwMu+Iwizh+BxK0 N4FbHXmBMrokKBvfqm/DN9YZ1ZKheFKyvNUtJey9LY/6sscxhynnzDsrarIsBsNCLgka96wrdgQD He6/ctkcsE5WPxwk1E5T+lxP8vYlqMqODurt1X2i1B6yXfucW9gXNd32Zm8PWpHcc/tzn7t4U9F3 3qFdCrjXgg8O6d/kIG44dFA07vjjkEcueeOLV255H/4ncXFo5sJxjsWh71kyCrOhM0325amMboxP njenuhWgIzrQyKAUyLTtqOcRF3qrrzJeLejxDnsjwvuutlqCxZ67ZX6Z49XY1p39+TbFDyN97dQp vnx5zc/E95/4BM9eN99Ej/DzgX4vdvi7j4+Xe96b33yf5LNfvvfHigze2uArv70Mxfkd50YRkCLQ L3MGlJ/rjFcj3hEwR5swAqNoNzXMWW+CDoTg/g4ovk940H4g9N//MII+k6TNP+Ph3oF+d8LqzW+B FzShDFfor9PRsIUsFJ0CT5fD9oWuhykkmw9lqL8TjpAWJfRODVEIlyWuUIWiEEoSAaXE0uEFUUG0 Yv4Mddg9KpbwiTac4A+dmEXZHdEWUyyPBM0YQS9CcYuMSKMQE/i9MtoREspzFwfbV0Um2rCNc1Qj 9M44CDmiEJBqu58bw/jCODKwj2vMnyIF+cZGMlCQo0NggfpYIzB68pMiJKQKAkhGJ6oQkovUIiNh 2EVKXhKLpSxd7PLIDVXGcIiodCUoYynKGxzrj6YEpi53GcXbzS+Xr0SmH225ykYO0YIyuqMslyhN WPbSl3wUYzRxKSiRcS+HO5Ni+LSZzWVuk5c35KI6Zyi+MbrTmud8ZxHheU00jiyBHAQmIsdIwQa6 sIkDzCRIlLjPc7bOktZT3QM1GT94RnKD+ZxmPf6xKTz8JRR63qSnCUn5uuhVlD0XhWJGOblRPLKi o55LaUM5mdGSJvKU2gNcKFsT04lKZ6aBwKlNL6fTP/R0p4v76R6ECtSiGvWoSE2qUo86uaY69alQ japUp0rVqlr1qljNqlarWpetevWrYA2rWMdK1rKa9axNqAYD1srWtrYVCG6NK1vhKte40rWubwUA Xt16170yoK97BSxegSCAwhr2sIclLGIXW1jFMhaxjn2sYSMrWQFQVrJAcIBmN8tZzma2s6DV7GdD 29nRknazpj2tA1J7WiAg4LWwjW1sXSvb2r6WtraVLW5zC9vd8hYBvuUtEA5A3OIa17jDPa5yif6b 3OUet7nOLS50o3uA6Ub3WH6dq16z+9ftZlewdQWvXMVrV+/6lbx8BUBlE6ve9Ta2ve697GPly1j6 Lpa1pMVvaPULWv6WFgCq9SyAAyxaAPx2tgY+8G0TrODg5tbBtoVwba3rXAov18LKxfBzAUBd5HK4 w8ztBne7O2L05rXE5g1sige74vC2eLzwXa99IRvjys6Yve59b44tO2AC+1fABC5wkFfb4wD/GLUM PrCEdZvk3y4ZwQpecJSB+2EQa9jDIA5xlqtb5Q5fWboi5q6JtYviMov5xeU183drjFk2z9fN9YXz feVM4x0fWchBvjORh6znPjdZuH9+cKAjPP7oCReayVP+spazrGgub7nRkA7zmtV8XjSnl9IqxjSL 7UxnHOf4xpPtdKg5zeciq9bPpU51ng8N5Sg/ubeshnWiY73gR3eZupG2ta4ZLelKa9rFv4ZxsNN8 Zk4b+9Oi1jGySb1qVfvY1K2Fdn6lvV9aU3nW2Ha1tV9da17v2sq3vm64KzzuC/c602ce9qXTze5J F3vZ8I5vsnl8bHk728jU7m++/3vvU2/739luMMC1/W0vlzvDB99wwXF9bhar+8Tt9nXE0b3mest4 3qBWtryZ/ex+R9vj0y51wJU8cIGP3MkJx7K3Vw7uhYtbrRN3eMyBPXNh17y8Frcxxnee8/42g7za P9d30P97ckAXXdBHJ7TLyb10czcd4TB3t9QlPnWKU/3qKu75m7UeZ67PeehAbrbYO77qpBva7IjW 9qyfrnCWG5ztHo461mVedbrPneZ1d7HX6xzvi++dvWBHcuDxTPZno73VJle74gUOdzA3ftEt57Xc rU55u1ce73e3ecX7rvO/j5rzPh87vge/Z9H7+/CyXjzJUd/tyLv+7W5nuK0nb/naY/7yms88sTe/ cdBv3fddRzbpUW36j5dd9Shn/bWRD+jHOzr24nY+dm++7rznHve71316Pa9xvwN/zhwfffFDPn6g Hz/x6F8985FOcOgz3f1Ohz/UUfJwMv5TH+LWzz72t/99vvf+/95nb+UndAPIbwUoYMrHbcuXfsnX fq8ne/LXdg/4cvR3f/aXf9WnffingdrFffTWf54GgDo3fPsWdoUnfoa3foSWgCVHctKXco4XgSoH brR3e7Z3fTeofzmYgVkHgp8ngm3mgcR3gv5GgiKngmeHhGnHgM0ngzE4ge8HheZWgzhog1ZYhVio g1eIcz7YfZ3XhR8ogERofGNIfmVYbSyYhkqIYC/Yhk4YYlSohVnIgzu4gftnh5sGhhkXhgHYhyN4 gIIHiISHgvimhkzIfoeodG/4fFKIcC8Yh3S4hZE4h3goiZUIY0LIc3q4c0YoiKV3hv76Zojql4hJ yHiLmGunCINwWIEYeIly+IqTCIuuyH9A+Hu1GHy3+HWeOISEWITnN4rA2ICkuIQumIpu2IgbBomz uIwXyIFrNWbPaGnMGI2ZWI2b2ImgaIDZiIBrmHrDiHjB2ITIOIOwN45PaHDK2Ix3qI51yI6W6I6Y uInWmIs0ho29SIb3OG2iKIzhiIjFaI6QV44CCYE0yIrOSGIWGI31p5AJ2V3z6IdBeI27WIKBuI0V WYjdKGUZuYD9qIgAyYgDGX2pmI4M2YrwKIsnGYsqmVcP+YX0GIIXZ4++aJGDeHobqYA42YIod4wh GYU9OYUGuY4leZDQiJAmOZQ9+P6SPwiRtsiUcSaT+DiT+YiGN6mTRleVPEmQP+mIkheU7YiUX2mU RCmNKcmS8niWSvleUGmGU0mAKfiN3tiRpSiXTJaVIvmRkUaSYimUexmWRfmXZEmNaOmU4CeRNPmJ bamNicmNcKmRjcmR/LiTxjiZeNlw7wiWl9mXmQmYKNaSEZmWfPiHh8mLUlma0baPV/mYOWmXPqmV rkmBGIRWsjmbtFmbtnmbuJmbaZVIutmbvvmbwBmcwjmc03eUmkmJZZmcmImcggmae/icmuic0UmY /ked7IWa/hiZqfmPWymB3UmOr0luesmZDUmexgmYntmULmmdS7me7vmZ7OmFbf6GnStYlWtHmd95 juEJlIyykMeJkssJoP+5kh04mO+pnvB5oLgYn6GZoA76ZvQ5l9qZneKYnwG5n1xZmeMZmAM6jR2q nB8aoLTIoNCZnguqoIUpnZkYocQ4ofVpipXJmvFXkP1ZnhxqnmPpnyVqoA96oj2aoiQ6nShKYywK ji4qoRWKod6ppOB5l+jolZt5o1Kqo1P6birKowiapT6qpUA6pDCpc0Ual0faoknqpEyqn2aapuIJ pcwZom6Ko3yJnli6pXTapT9anV7annf6pfNpn36qmqoIkmd6oWo6o09ao+dZpYlKpZ05p3bKpXi6 p3oKqXxKqZMaZ2HqmHRppP5l2pqFmqEWKqiwOReMaqOlmqgm+qh1GqmWKp+t2qCvCp2ZCpnbOaZs iJ+DKqqeuqaImqOm+quo6qisuqqVSqyXqqrIOqzJep1/uqliWqudaqi5iooayqYCCqd+qahjmarK 2q3FuqzH6q3h+q3i+l6zmpMsKKOgOq2BWpy+uqjAuq3CSq70Oq726qrGiq/gqq9E2qy2+qwUKmjq uqSfSrC8SqrxGqfaqrCNeqUOG6TcWq/8KrE8dq5WGbAeGarUqrHtapltiq1ReqqVFrH3Cqv5arL7 irLlqrIUi67+Cq0Ya2gD26S7Kq2jGhIiy7AJm60kO7Elu6MPm6c+O7QV+/6yMUumR3urMYqrBRt3 1kqgIuqhIPuxUtqzLPuzQiqpRAu0QWqxFjuzaFqz63qzU3utC5utVGq1XCu0V7u1WRurO+e1Rpux 7Aq2hHqwOLuzIau3VKu2b3uya6u1bTu4sjq3SJq0AEu3TRu2Niu2BsufCAuvkvuu8hq0ghu4cOu3 K2q4SPuiztp6HGu3ugq5eTu5Omu6PDuvWKu5quu2nCa3gHqfSzu7HLuhOYu2fMuFlpu5rUu4f5uy hRu7nMupAsu0jkuzjUu6ZQu1b3q2e8t7ENu7mAu4v7uywfu5tIq4mvqvoFu3xpu889erp0u546uw rLu71Hu+XTu8iXu4nv4rmbTrvdUqvriLus9budGLvsBbvS3Lv1gLu9i7mt87tsfLuOEbueRbvwkc perLttO7vw3cp8I7wQHcsaK7sQxnu7nLvMsrtf7rutL7wb7rtwDMvdmruAV8t+D7uASsvM5Ltbd7 v0mZvzTswCL8wNYbt+y7vTD7vtHawkDMwkKMvAdcugsMwxvswRHMu/qbwyS8wyfsvlJclwM8xAZs xatIvzKswOWbuk3cv0ucviFcwj08xUobulVMxMn4tB4cw0gcrF+8uiEcxvtLxtobxVQcv4urwkHs tLFJnIAcyII8yIRcyErQVYacyIq8yIzcyGGlwfb7xkesuzV8uTcMAP4KkMmavMmbDASc/Mma7Mmg /MmiPMqdjMmmfMqpfMp27MN3jMF7PLp9fMV+jMBdvMW43LdzHMKrHMqo3MulvMrBnMrDbMrFPMou S8EmLMB6nMKyjMVcBsmTzMEvbLZ07MTI1suZfMygzM2k/MvCDM7ELM7GfLGufM5m3L55jMbNvMK1 bMS3LMnxbM27HMfvpc0K4M2crM+qrM387Mv4nMwV/LVpTMsGzcdrrMXyzMUMzcD1XMlvFtDkjMwT 3c0V/c0SLdGtnM48XLztPMsIrcbv3MEgStJRW9JV+9A2zGkZ7c8Xvc8v3c/AHNO+vNGdy9FUdsEW PJJsjNJubLZpq/7SlszSLt3SM23U4azRUCzQy7zTHw3NednTJz3VzfvT1HzNYJzNRb3VR83VSe3S Nk286LzO8svOtSvVVZ3EPm2jWC3H8obU4wzX5SzXFB3W6izWMlvQIX3QzzzS1UzNVt3GVgrRYiyd dG3Rh43RXj3Odt3RY33GZR3Zseyu8wzYak3VOJzV9sxjiQ3TnS3TXz3TjY3HeE3Wk+3UZp3BaG3S aR3J9LzZmY21nw3Qiz3XtV3XS23OOA3Lzszb7gxm0lzZgu3aI7rSQh3Rt43Yya3YXS3auU3QTy3S fB3VCg3Ul93a+GvcsL1zs73NNO3d3Z3P3y3eo83UPwzVqC3ZeP7L2uz918M9ssdd2BcX3v8M3svt 2WD93Lmt0zod3A290LlMydpN2PtL3+Nd3+Jt4OWt26bd2+l92rO32u691sStxPENwVrd3KG94XF9 36ys38p83tK91yTe19PtsdZd4RSe3UN94TRm4DDu4TUN4gPtgKkN4Txd3Zat4pg94c1J4Nhs2DJu 3xre4UVezguernpt4iVO3bb83yk+zRa+3X4b40dO0QpO400tuzfu4I8o4YG94sJdoFTOy0Oe4GeO 4GrO4KXd5nf95t2L49F94v4d4Dsu5WQO5JodpFbO4bZ95Rad5Fi55L4N0tEM5tfd3kFd5tvd50bu 51ie3yH+yv5sDmv8Tegofudj3uOLruduzedpfuCinuWT/thwTtqWjun9jeg8jt2b7pAuvuc65+h/ DunK7dylvtuVHuderupdqePv/eqKPtgDXuyWTOuRDujMHc6CDqiXPudZ/OR2HuxQftWx/umzHurI fuvMruVlfNMN/ttN/uAOXucAfu5RPsPGzsSgruz47e6g/eiM7e2UzuXqLe5Mnu+UXe3UPu0o3dYg /NbaPvDwPuO5Du5u7th5De36Tu4uHOacnugpzeiefs8Eb+vLLu9ITu+mrvDhbuiFjt4R/seOXPIm f/Ion/L4tEcq3/Iu//Iw75vmnu78LuZ5SPHZXvBEjvHvzv7z8V7r837wCY/qHg/Zct7l+L7v/h7x rS6nON9m257xQD/1ye7zBl/jQn/qIT/iDf/lwG7zS+/qXlzxvhv1Pa/xVY/23B70WN/2Tf3sSF/E w970Pt68AM/ZF6/2Up/2VL/2G5/1Ra/1/wb39y73dT/3eN7jd7/mZv/zfP/4fo/bgE/0lM/McS/y OS7t6K7pNa/4127xOo/moc/4ef/3bv/tQ2/5hY/586v5NB/2iK/uLS7koz/qpQ/5ex/oHK/r9n70 q8/1Sr/5/S78//75eF/7jU/byC/pp1/vg87wW0/nrJ74Yg/7l5yJyb/zen/2fZ/739zsFUz4vk+2 h1/+EP5v98ZP+su//lav/aa/5bv/8ax/+cCf6cP/+sTv+U+P3Oy//Y4PAUpOBQDF2GZeb9cAZCTL 0jJTElVTtj1FOJ7j48bz3NJ7nPf1gMEdgKgbHg+WR7NpYUSl0ymUeo1asVTtVtr1MsDe8baMtQjU azY73Yar3/H2nL7egCh5vYTf/9MLBBnsKOQ4zHipWZxphHlsiVSZdDFSukk60iTiDPL0ARUCcHoC CKs6Rc1SXT27euVqRY1NXWW9qwPIddvllfP9TQzpmxje+yg+Nk4GbBZ8JpSpQag0saahrp5m5Ha8 xBRFAlcSL8LMJN8kLa39mg1zZ70VgyezN8NH04cN5v61ywXwjkA6y/xEM4QQkUJFDIkV8wAxIkRs K7xBuigpI6WNlrRtQ7dEXaeRn0qGOjkqJJN2/GTRk1cPpktbt2Le9Bcw58CdBXvGMThRmUNkEoMe JcrMaMdrTLNRqzgi6raP5n6kHLcS6zl0VtOVeoBz5libNN+RdWUW1y8BBIH+hOM2btKDS+1SpCvU 2d2hVZ1a9BtY21SvIrUe7rr1qlawYsuipaVW5mPKadm2havrslxdfPfi9QwttLSlgqH+lYqa6mDV hV0rToc4HGyRjSU7Tgs53m3eMzdn7vX79+iExBcab4g8hOluzL85xyi7HO3X0tfZ1n0ve77t+7r3 E/7OlnNw8XmRKi8KWv3Q0qyha3zP0a91kvRN2keJvXLk7y/37+4vlfCEAQ6PAoFBT6n1PmNvQdHw is8j9yY8bb7E8FPpQg1n0y+3/7T7kLsQvStrwH8OxGw4B0lbsbgWj3uxoQibmvGp5ljDMKsNp8ux iA75G7GfAM8K0j/LyjNRJxUbZJJBJx9sEkpnagSMwhsrxHHHdXpcTEuSfgSwyJo8JBPIMndLkqc0 fUqwrhgfipLFOBOiMrU6V8PyNC5j8/K+PvNrach5xCTyTBANzWfNtxSdq029pIRUziclheZOwlrD 1MLZ9jTszww5DJTQQRElkVQhRa2HUc2QLM/R8/7eTG9OGPuy8rlaMbKUOl05rS4xMA81M9gwTTVS 2HtUJY/AJSd1UdbkYFXQ2eVuhY9a+ay1hNddPdURVCdwM1ZEYscMt9TIkDUQXQShdVPaWJmdFV4Z saWRXhtt1ZNbrjbVt0tvTRF0snELLffUgddSltWECXTVPIcbbjhXie21SFuL+/0q1IMFLrjYYTsm F02FT1QXM4jZfZRSlZudkmI7Xcbzym4u5rdmHn3VGGSCP+YZ2J7FPXdkJYXm6WR3o5UXzqSRmThP mfGdGeNObd5Sapa+tSBrrbfmumuvvwY7bLHHJrtss89GO22112a7bbffhjtuueemu260bbM7b/69 9+a7b7//BjxwwQcn/O6cfzYXcYN1HpXxVIlmE+VXj253aaQjZRnzeDV/lvKUE6L5ZqrrwxnrgMFV 3GOfV08U8reMtrxyzpWe/d3aL19589w7j92D0Kse3c9/w+oNVdRZTxx58FxvVPKHnYf9dtl3p516 263HHXSrtw0eJcYOV151oFMPOfzyW1/4xOixnz5z9j/X3X3546efd+nhb+h30rv/dLpfxzffzgLY OPIJEH0kaxX0FOi5yfWugfd74PuQoj/hic6C1wEfADWYvA0uroAEPBbzOrNABz6PgSYs4frmZz8J cu+C+3thBTFoOuMVb2PH66AsShbBFVavh/7X+2H26ufDIQKxiEJkYRAPQkHvbe97NLyhDR2HQw7u Y4cohCAWW6jCI7avi/gjYhK/2Cv+dSuGTRweFT04QI59sI1sHE+6EnhCLorRjmHEoxHvqMc8IrGP XsyfEwVZRh9lsIprzOH5Dim+RQpIhL2o4x/ByEdK+rGSgJQkD8eoRe0R0l9n7B/w/GdIRDbSgKYE YSJPubz06SSSl5ykJWWJSVhqco+zjCUtcUlGUJpRlL/8EikZWUpiDtOYiiymI1tZNBJm8ZW75OQm n6lLavpukL3cFzav8j9UvlGVqeymGnX4SANNM5fntGUmo3nLaqazlg5jYihhCEyTcDOZq/48Jj6R mU9wshKBDGvmFgOqRHSuU53mnOA16YlGbWYMilOUohvFuU9l/lN9A5UmRtlZUIQa9J1Liacv5znS egqTovpEaT/56c1woiiO66KjRg8q04/SFJoNC2k2FyrPkj5UohGFI1C/+bhlRi6mR02hTdvp0Zsq 1Zqe5BNUp9bQ2pg0pSy9p0pPqtWrvjRFc0wqUp3pVHc2VawtzOkndyrSngKshqcTakt9Q06YhtWu Yz0rQcu61I6mNapUfY09VzrRrsY1q0S1qCvJylS+Lrajj8WLX6e6Vp0G06dBhWtma3hFyOY1o57d 6F456jzJ8pKy27QqV1WL1cEatrWcdf5sbEE709nW9ISldeFpHerWKGq2t5ulq8lke1eB1tasxNUr PBVKUobqtqqXHSphVytd1lZ0aAA1bmOzO9rtita7ypWqaZnLU0BBV65vRW8UYdtdxnIXuZ99b2jb K14ZjpetzbUsbyHq2/0Ct6ivGy5e40vbAdu2wMzALW4Fu9XqFpa/P13vgbUrYfcK2MLFLWGCl9tW 4j0Ys+mFaIQvnNzOUvi7JYaGhsOrqwU7GMQ/hauIMTxi+NJYviiesTRUDFgWp7bB03Utg6nrVSLP 18g4JnGAc5zcHTs3sC0pXJSlPGUqV9nKV8Zyls+GNy132ctfBnOYxTzmwYHFzGdGc/6a1bxmNrfZ zW+Gc5zlPGc619nOd8ZznvW8Zz732c9/BnSgBT1oQhfa0IdGdKIVvWhGN9rRj4Z0pCU9aUpX2tKX xnSmNb1pTnfa058GtaS3huirHfprpgi1nkutaJasGs3sgHPXYp1qWtfazbI2tKsJfWri2drOujY1 O4DdEjl77daw9nWyfZ01rCFb0MMO9LChrew0T3vQ1iZ2nEvNbDZjm9rftvSqvY3nce9Z2s4G95rL 7edyr7vX2VY3utM973DLu9Wk4DaUna01MzN72/n+87n1vW8mXI3fn7438YRtcHzfm+Cu9vfCB26K fB/8zBBH9qgVznCA09vjrLb3wv41TvF/W3zjFR85u+WNapKjfOQp37TDI85trp282QDHNcf5rfGa XxzdOp+5zDv+caLvOuQUR7rCWU5zhyf93UNXNa6fnnFYN/3dV4+5yJNudaZjbetcl7jXsW512/Q7 7EuvOtWLvvZC6zrhYne72sd+dqzz2dgsxxvep07rt1+97wzXe9/3bvaz/9vnZvc53aHMdsZH++hz 17vY0Z7tu6u82lQ/uOFJDuq/px3vgD951+GOedGHPu6Iv7ngQ9941vf59JCve+DpLnSo51ngmxd8 yVd+6c6PXvK0z33hI/55qcP798Ofe8F333rmx/rxmn/95H3f9t0HX/aH73Tvpffvd8VLfvDQ93y3 fz574Ru/+ecvNsG9r33wU375dq8++a+Pek5rf/Dcj/z6w97+/GP/+O7XP/QTwPRLuwIkvv0jO7AL P8t7NeHTOqXDv+wrv+0DPZQbPQRstgP0Pv1bwNLjuAEEwTcrvhE0uZ5rOaB7v1+LvxNEQZGrPd6b wPsDvdVLvbe7u8yDuRrUPRxUPhMMwR+8vI7rQcIjvPFrOH17thX8usXTOc6LQfvTPSLsPAe8uSA0 uSX8uu4Dwi0UPy5sQC8EwzD0Qndjuw8UwzNEw/Mjw7UrvjR0wzf8uDVkwyuEwzq0wzvEwzzUwz3k wz70wz8shQgAADtQSwMECgAAAAAApyNoJ+L52PmHGAAAhxgAAA0AAABzY3JhbWJsZXIuZ2lmR0lG ODlhrQHeAYAAAAAAAP///ywAAAAArQHeAQAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm6sq27rsB MkzX9o3nei33+w8MCofEVc9XTCqXzOZvFjg6p9Sq9UqBGqTYrvcLfgIU3LD5jE53tImy+g2Pv9lk pPyOzzvpC7f+DxhIw8fgJ3iImOhB2GCo+AgZ2TdWYSd5ianI+LCZ6fk5R1kpqnJkeoqaqrrK2ur6 ChsrO9sKqtbZSJpCy9vr+wsc/Gubhluoi2JMvKO8vIcc0fwh7WxDXZ10vQVtoo3t4v0d5B2eUS6+ y43eRK5Ocr7e7R6fPX/cAk8/kq8P045vrx8LfpACQrC0z2AbhYsYCjxB8JHDPgcmZrEYUULG/oca NiKyiIAUSI0YR2LwyPECSkGUxsyw4zJmSyMlAaa8sTJQy51btvmMAjRnxZoDTd5cY1TSzJ5MRTmN srTEv6JHeSSNFPUpUKZBQw4VZkrl1YtVB42VyFWr1q4Vv4JFSNJm2RdC/2RtuzWvS69SidKcS/es prR41y4VPEmsXMBUH95tilcv4sQW6tZhvBgzM7+lTMKNppEMVxGTo76brJnD1L8nI08wiAx1G9Kd U4tR3Ljy7Cyhd3ejnc72ZtysdfP92ROKj73I8xZOrovOZ58iY0e3vnWmdOaVZQsnTjZ3pUZpDyN/ zJenXsKjC6tN/9x908fhLH+P2z0zb4rx/rOzh7wbffCR159/AB5o4HuuhXefNZwFp1IhAybommkA qhVWc8dll2FsE1KIIEj2NcjJg8mIGOCE5o1mIYgGSihagQs6Z9qKLzrHIIn+mAgRih8KuJ6MLtb4 X4UssifSkS8SCZ6O4PAojzlGBunikjGihyV/WjCp4HwHYniSd04eBGVfHfHBBpjXbXhhhdep81JI 2Ml5mY3V4fiamGM6sFpte9IY5p9PNnmioGvlJ6h4eern5HT4JernKG/BAqlqelY6lFiTvoLpmZ0W imhxn44yapShRlrqoqkmRGiPq+b4akOtmhormbWC0CeEvcX4WwzTpKmhco7A+Oitls5q/uaudOlg WLBMglassZ6equtBPOQQHWRPWQibqtLGUOZpysJEp3ZwJgmdU0mmuSWdbeGSrX/btqcQbJd2miuo 1iIpH1TthUhlVnby+9M80Gj3Lr2vRfstsnze6+6+eHI5I7ps3Qjkj0Uegy53zMULra0NT0uqogQ2 R/G/p2y4ExeGdaziwm3a+O/JJY5MMqz6csJryhPb3CKVBH/JZ4ryIoinzQ/jbE64rIasIMwqH+ex kl3SjB5/8SF8Y9LE3nzIsBDVcWm+rkLdn3qHFlg10W5fPaNvcAMss8g6sbmL3GeXLOrS2xwap9AR B7mlxeoCbnjNf8c8nyXNapgLS7yW/uKb17JSuzPPmivOBMQh223Xlf4u5JV60JHujphm0yrxyZ6/ w4y3oQfos3LlIZk667JX2zrHHDE04jiis/1fxpbruXqyTGd6t9GNIzFnl16/uanDTy8POR4eApr0 ncYfTHb1mO+NffBAbC+121Zyj7e44+vOtPnnU117v49L1zfDmlKKffZ5uBGTy7hpfdRZiNiQYj2S xKJ//vtIHJKns3swUH5LeN2OEhgNezFwdEp5oNP0R5n+UfBPENxd5CZoQUN9MIMgbNgI91TCFpIO hRs0IQuPdUMRppCEKwSd33RYQxmeEFxCNNYLxxTDHIINiEH0YRGV+MPy7RCGPVyi/hWXd8RGTcRR EQyhFJvoxIcRpBlZPEoZSURGLr4vfJtqoxvfCEdXgPGKk/BIGuOIxzzqcVJzjGL43DeeKSlpkOwr pMUMybJEChKRizykIxXZRyi6xTvkgCQjCfnIRloyk5jcpCc1CcpIOlEKOalkKC+JSk6m8pOdPKUq X9k+UQrwb+pS3n5aictVupKVuswlLHcZN1nO0A+lxAgvf+nLYyoTmMlkZiGFWcfPFDNCzkRmL69p zWwus5nQ5BgjpmkcbmJzm+OsJjm1GcxuQiV1lDSmOd8pTnTG85zkVCffSOPOecKznPrsJz9Rac8u IjCc/5RnQem5T4MeMqA2vFwg/v2pUIRCVKIH1YQpezcFcD60ohNNKEUj6kzJcU5pJH2GLevG0ZSC tKMsBSggQKasol1Bo7dU6Udv6tGcErJ5A3xXyy4GrJm2k5otXalNdXrUkd4BTrdL0NysQFOUGnWq OC1qVS2nva8BCXBKrcdJx3VVqiJVrC3laeW2OqWD7XGtvSBqUt9KVrjW86XOW1/WgsbWvMqiNWMN q1/7uk+zYoxgXMXqOuKK2L9aNbA8TV/UGJeSxAJ2sZT9Z9jQlDh/rSmd8ZBsZT0r11MydKaKDe1n S6vK0UIVtaydrGmfqVoqgHa2rT0tZ2OrBNq6Vre27SpuicDb1wYXtL/dQ22F/ntc4ha3c8lt7m5L u1zmPne6vUVudI1LXetWV7nXLcJwnbvdq3Y3G+DVrnmNOl7vlve72UVveofA3vC2V7zvFUJ8z7ve udZ3fvPtr3zLul/+/he//rVsgJ+Q3wLf15oHRrCCEzxgBjeYWRAmcIR5OWEKP3jDFxZthnGw4AqH eJEfBrGIT8xhw5YYHyjusIthu+JBtNjCNF5ojGWc4hG/2MY37oxefwxkvfY4HUEuspHhOOTMxW+K Ez5jZJncYCf/DsoHlrJjqBxgKwtEy+Plsj68fF0wdxbL+xXzYclcXzOjQ82/ZfM33BxbOFdDzqOl 8zLsHFA820LP6uTzJ/xM/g81MgvNV7ZnhoBL6C0nOjUrQ/QGAT1mWsJ30V+mNGbYBWZIY0LTa7YO lzmtFEsz5puCzh/OQP1mdjoZ1QURNWCMcUDeLdnQ9joiqyXiah/vkBvIA16p8fnoXCcjlr2a3PXy lMJbW1SkxIbdLAEp0K+eWtjFfg5mS4cyDhZwNr3GYAiUnQhwo9RL3KvlkujDa/I1FH7TZjbxyh2Z 733t2OuW9sjEHdPBrhN6ApReunMRDG/jitrYwPfn6Aa+TMlba9Ecxhrt7UKCO1tj8B7asypH7yd+ W+LOMPjnzO1Y+8Xbf91+OLSxyPHTAOvaA7wrdzAObJNnvN2XSLnAB4cq/pRvGg5J3Hiwdx6Kmzv0 i32u4q9+XnShD5SJ3ez5wJHedKMPXedJl3nMmQ5Npx+dhlW/Z85n3fVonxzsUVc6DrEuTK1PnexZ l/rSiV52q/uc63H3uqxpXnexz/zeNle02YlI97b/PWdUz3u9x453wcv96YFPu9vPDnfF213JiXf8 4JsGdcnr/eqRt/zit452War97YXX/OH3HnFaXz5QjbfLr789b86fXvZsn51vYc9w1Pvx7nx39+2n 4UXdD9HUvResvOaUnGxv52cln7y6a/+/K9XOTuiO/dydz258LvQwYUHFvqF36Nw3+vvbq1nZ+g78 utbvbbFs/uavL5WR/g+IqcGEKbYXxK37K4zySx3e82w3TO9mbLQnSfyXfjJCM2c1b+m2ffuXfFTz dVmlfuZXLkMzPc9XgBiIK3VVJQoofhLSgDiyLnrDe3KAPhR3PwIIc/A3eyy4Dx/YNZbEJgknOPm3 MS+ngf0Xb+vHIcVDcjm4ewY4cNXRIbQEU95HfsRyODARfmuDg9mnPY6jbdmmcEUSOAPoghkIhS+4 f0GzUzvoTS8DhpOEhRAXNjz3eIAXfx/SgTJIYl0IgfKHfyYzGEH3eWuHewiING7ogHMognA4g3QY bmi4eoUoMU64h2/Yh4Coh3/YbAQYSaMHeX0Rgl5II41Wft3DfM+m/ohmCEaSqIadtypgsT95lXmv Qord8WOnKHppSHjQJ0qg+IqVhwYJ52pDdYekB4tmkDv25YkSJIipx3MyJTyIF0ZAKC0edzo+lS3m 5oja9jHLhzq/GHwl+C3KODrScx4++CVZUm64iH3UeID5phoH14MBkWzot1EJKDQLtzYV93u5OIXW mIfjtgbmKCTWt4VfIDXlh4nu4TKD84+3NYvHuI8buFGLgI+JmHtCyI/z1zMgGDf+yHDg+H6MN2wC +YfSmHwew2Pk0i7jt3LxOIm1CJEkSBiFlYIqmIUGKY7lmDbRE5PbKDiEsyIZ0y7EFwYAGIPpczEE tJLkJnzAqJN5/uiTaZU2SAlzj6VvPPaSqxVU+INzE+NIHFmFxkhHDnmAR7lTPLmEPKmRbcIhAUmQ GGl6GmeWxcaV7BM4j7OC3HiTFRmMcySLmJc3ViOXhCOHPZmUIOKTr4ONm+aKdpmR6uMuYNKOG6OX YvlUKpaWrWiI4WiWQcVta5I10FhH8sd9zNNUERiJg8l6d6kHFhSYNQeakbmQwziXn3ia8igl0cco sdiakmlE6hhos3mRqGibkeaaBSmMhoeWoCeKsomaLRgrpRlqxRmco7ibZ6acWniNzdlpz+mSySid 4lCXoTmcn0mdWVl8wAmdWBmdqtebhLmdfZSd3YlG15lq6jl8/qXnebQJib95luE5lLeCnFiBm8ap m+Qpny1Jn/GZm3j4nfVZnfdZK/nZau5JlPAJmeWpnQ4KQ8jYoPRYm5jifvxJoAFKRRRajVqJn+wJ Bk8IoEHooQkqojt5ojO0mhdaKRm6nLpIixMKcMDAoB9aoIYiRjYKoTcqHApaQSs6lSCKohgqpJxZ lNZppAeJo0xapGGnoTKaow/6n485o9zZo1maKEC6bJIyKK1HnMi2aynapeAZTWbBimG6ow6Spljq TSBGpuEWp8RAaq93pKnCpXL6R1KWp7cwp3tGhM7IpmCKpcSEZn1aDH8KCuM3pIHRpug5LHyqqDox qZ7ARZL6/qiqhamEGmeHWqmu12Wemql1JqqcqqmlGnpthqrnearY8qmj+arYuaoSilubmqq1Oqu7 2KmuOqoMZausSqq8aqrBCqe9mmeeemTJqqwB112SuqzPCq0L1Kyx2qJJJlQ3gahZRq1Jaq3X+mTd mqjYuq0llq0ICq4m9a3nyovjaqGQmk+bI1vsSqRN9I4YpY8VJK93KkJvWVINyQ756qRBdITr8lMe +YjeBbBP+WgEAnJCeZnoOmW+qlWEpZQGFK0Xi7EZq7FvkVETu5gq2XAbK7IjS7Il23fxEnIEFIO7 Wmkdi4JbU7HFVa5Sql54SbF9uVwzW5L4inw2KYJOSay3/qmuduiqQeY77zm0O5loRhaGFZq0/Li0 U1Sn0pSwH6ZlL0RqktaoT4sFVyu1vBaoSMq1UDscjlqNpFS1Gea1F4Sj4Te2XrC2ZsuJFvu2Ixq1 bDu3f1S3XXu3csuiJaKz6RW3X5q3Nbq38ap9beW3Wwtwhwuxv+ILePu3Ueq4VjGf3mlsKHtAWaul lduuVTq5EomkFxe6DWSinns+pSEi6HiJbAi2TnugqFusJXq6+gdUizhJSAi6siu5G4q5ctg29pe7 jEq5vFutuyu2WsOUwkty+2m8lxuhp3docdl+r9u5zwu9fwcvzvMxb8m5yIu9numbv+uId/KMpTuP 9hm+/otLs+SLsodJbN87oOv7ufNruuCjuZdqveBLvwFbvFi7v/bbv2a4iuxrukg7wGhao2vVu8mr vglsjdpQH18Lu+QLweKbvhZcwRqYnhe8sw6swU3Kwc7rwQ8nwavbwAe8wSUshCccvZ7ZwSz8wiBc uzVsbzEswya8RatrtCKMwDncwjscJj1cuCEMxFZKwz8cu3uHw0esQG00w/zXxE5MJm4UxSPso1Qc oxOcwhlsxDhhp+O4OP75vxTswyusYSR5j3FopjaMxsY4xRNXlgjZiXQpxFlcuHHMhfDBcg+4cpZJ jAIaoyoMxyS8xyI3k+eGO/0Kqa4JwG9cxLEzgfA4/jcfmbaU6shmHMlKLMkoWIQBSDf+6qZiygtd rMfA8bKT05Ysya+sqYqKS7jo+8U4lsrqs3B17Mr8Kw0A5LYmesqoLBk267MBEyxzbKyyHMKZNcfy W7yB8cfP5j1W+IRhfKtufMY/c76+7BfEy1eUJLsujEEneLBGqLsMwryB5M2oC85WJ87LzArEcc77 kc6eu87yiT69/MOrMbAGpJnrpMWz7MUa3M67HMDeAjLeyJQvZbILXWSZbI6kq83wPL1s+LEswdAX LWS6zLocqEHXPEvOKJKZZYn/TMjIbM3KfHvM/CgoHZFiSdKQzLjWvG94g44FvdKTXMlqLMP1LMAf /qzPJLiSAOgj40zRMnXJmVDAsRzTwOiPb1KBPUhQJPmuoWqKBhzQnIwTZcjIgRyqDm3VvwyT2+Ys BbuM53GFmBm4/3PH19tFYO0rDguX5DYwi5mNUPrAm3zDhpzEmvOXU2NXMEvJdr3EeF3IDHpRHTO9 /Yh/1GuYVFrGpqzXS93SDHmzwczYKuvYg3zVee2j1wCyfTnXywtZgnzXJs3ZbI3VgchBCM1+dU3X 9drIGk3Eph2yeZRvZ70dtYQl0di6e5nZpS0nsy3ZbKRHL03YtO3RkOjWe03FPN3MoTjcyA3dxl3S 0S3dLbncaQ2syX3dSOzW2r3dxy3e2B3Zm03S/s6t2T5d3tQN0Fz81es9ZxgdrfPK3DBN3ni8Z45B 39Xd3cJp3fWtGUe9xv5LzrMA2fi9qPp9pzyq1ADe32Uh4GGtsObdpE2Nafpr3w4+agpO4BQeySiN iLC73B3H4RPu3gxbMbgLwiN+ZyUunhm+1w9rg7WNz4O94Vu23x5u2pTZiDQeazAO4S5urhq+1MLb MhjO3UQ+FxH+1h1+4sM30OwE5OBNy8PrmBZbp8FNLjRd46JcUufn1Sju10CbwSxOp0AT1crrh0be yh3h5f4N3DGumDOex/BN4h5bUzD4vjTd5q/Z5x8s08gM4n7Ytnbe4hNrlY+45z2+5sHcU4eJ/iY5 /uRL6RZ8XugI/mdAYzy39W+M3oVPlTI0aOIo/N6YbqloHspkWIYiuZQTbbMpK+oqx1YHjtqHhepj CRcGo49sruZb88ntc35V3eD8reRBjucjTZVnvbLZfIGv3pCxPuTEXuxSaub5fexfqOtFzeydrtig /ea+C+Q67t2GfubXnoj24JaT3X6QFerf3r7h/shJLu3Gnpe9rdXB3WzT0elUCDmFc+/gLu/zTu3k bu0OJOEvHvDiDufzTuX+UIdNPupXnH3VnuAfcRVgLttANuVMfi04vuA8rPEB3/DL4vFOTurDrvAp XxUc7+cRb+plTvAV3w8YL8DxPt7TbkZC/p69N4/z083wLO/wJe/ytZ6BFJ/p5EeigLvlYEvmCpf0 XE1/0L7zD67y6v3yQIfLC7iC6S7mW9TnUk+7CW/zDz7y4OCBec7r+Tg8Xn+wYI/Egf7fC5/yZc9i iZTojY4Q75uTQdF9Gml/5sKM//7uYq/JZA/0JN9T2giIUi/UgH01mQjV7Hjl4wvvhR/3VY+tZw/R rD49lIlWTanngP3nPq/0paw0+cvjjs7zmB9Zmk/OmUvZcc2Yr6+JjINXku5wFGG+oez5Nh3n9D5I yL7nkI+Ts4+Fiy75NF+CLxeVtEM/G6+jkLT5RkP8Fmf858692K+v5slt+meDbQPzV19z/q6v/aLP xlHD2A/LjW04+dzPwSOnjVyj+oYf/YK0+1iOmPwMvN2LMUArhQSQwPDUsh9GORtgFGdpJ/PuACtQ 8awT5bRIXd0XjuWZXq8az/X9uXmo9cMEe6hRCHkrkSop54wolE6pOl8Vm5VdpdGsVylCLHti5KLD zXi1bXdV/Za74zw2/Bo+o/fJYjMNqm6OsNDGELFt0GrxBwxIhO/iAzCB626oMXGzUJPz81ALcyoq r6/E6EiVbTQQ9JXTE3a2TFQ2pxXPFeaE1nfu9vc1OCbXkZhx16ZXuPnLGZpFEVkQkbUxNVrbcVub 2sUpXHycPJvwWsO8e73GZ7L2m8Zd/pqv9lQJnyI+vbzfP9zapTjq2BXcQi8EpX0HIUEiswreEYUd DK5ZuEVgGmMVOTa0N0Zip3xA3kmk5OBdSY8dSQZUZmkjS5nzUIZUoQfNJHeX9oAso3LJyYQ/7RWV acnlBp0xj7I0NfTMTTMkJoakuNJPz49ER6g0epTpMVcEm5bdcPbDyYcPszJRhfVUpbclpUpCirBs WDsCyZr1+xVq4Kptk6SAyQxvpME4kZqI6hPuzIvF+Or9W9FUWog1FUd6qw8vW7Z9PpN+avZfatWI SU6+HC1z182CI1r1XJpu7dmBeZ/Ouxp4v9fDi12dC5HuYMJwhZKhGXWqUMDEqVf/fsSzaHMWkOvJ PetxpOkiS8eDtn4efaLJXl3/ap8efvzvdrZWfy8ff/yFpSwXvJ8fQOv+0y/AAg3k5cAdBkyQQaca xGHBByVcJ0L0KpwQQ2cuFDDDDuXb0D4PRbRwxFBKPPEyEKlTEcUWpwkOxhhlnBE4F228EcccddyR xxMLAAA7UEsDBBQAAAAIALCSZScMvSSneB4AAFUfAAAOAAAAZi1jcHVfbG9nby5naWbdl/c/FI7j x2+6QVZWOrIOZ14lWZVxOCeckWxH9rxsEoez19lbNhmRHdFlZRVJUrZEZhKV8r739/35N76vH18/ vh6P1/PxeOrq6SgpO4wCRgFbAAAIBDGMEwPpQFoHbHQ0FUBSkOV1r4gKNU0fnJyITHQ0lXEUDrKC ZGZmc3JymZiYga5AZma8HB2dCpOKKyqqjo6OxQXFrAg2IiJiUlYyIjpi6+sbfn4BV64oJCWlgBwh AwNDjD8prf02glIokCGEQLjN2AlntWNxNHeamZlV5FHwiwgwv2KGRLJU5Fbx86NUVNQyk7LFpcRc ShV6BmyQVixWVjYgFUhNWpULwYnBKG5tbQ8LC+fU5CptvU3wu50UncL4SS0sLPbw8Kqvb/zz50zc RGxnZ298fNKcoMY4CP/0afGKoAIrK0vPiE1Pz3OXTAUdHRxIDrKzHhBRg9P0w8nJyQjyiNmZ2MzM eVWkVckJykiJyygqyqSlpfA4cjEYKSJyYiBzyBV+BSYkSkRQTPOmQm5atricGNIOwnOTy8XQKSwi nJXAIm4u1j9iw8T0354ympo4VnGUjg8uLu6/AakgO0hubjYPD5e5uRlIEeLi4lSaVFxTU/Xz57GU oIygB0pTDhdUquZj4iUuLra5uREUFDAyMmRoeHtublZQEHXzppqdnU1nZ3taXEppabGPj9eTJ40M xtnBwd6bN5PLy4v9/c/NCWb1uY1WhjYgFwjIBAK6CeHU4RKREuO045KSkqlPa5QykfEw9EpLSgmK CMhNyo6uwc3NeSnyKyCRqIiIcMYOlcGoYvxMYRxQe0acdtbDFRUVGIxspB0L4P91hBmsBg5OzkLB 7gFuQrp6BkSAzP/q/70DAGcAhuEofEvZyxj4eSmb0ZbywXh2UUJxNy1qOJnvqsfi6NPKV+lCWkko vdaqsSwUtMJmrLV6Ig97L8wM01bzukjJP6nqcVvt1CN1vSMWQnvd22KtdCnbcbO6/BpiJWE4P6D+ fcOtBsel8Ws1c09Ig7lnUv5CtW1u7+ptJzqbFrrIn8dL9H/tvSt1ckg61YQBo6UoYGbB290ta4MJ 56XtJrsvR18KtdXxwTCZPULkX/VcnnzWtjVVppUsaNDT7iJbI95slpppmqqbzjX6RKu3c3+h2393 +XVv17cVeox0nX/SucReRcsiLlOwrpd5W4z+I8O+nsDVVm6uuwfHLs7zjQMM3ReG/c9Pf3Q4a93q iD7v1/ztpFTpxOaMzPb7x+7K1IsX//4LYJJcpUCQ+KKw3YJ1O4PFWLMLD5FUXkFvNbzbWiyfS91a HCro61q8UNxoDG8gTlLwwbmI7ArdJy9dRAICV4XjuQVm3T6nKm3WfU5T+/n1c7o602kldwbNrTxo ZPjVTBLm2t1LKYE4YAzK2Mz9S46Fy+MvuTZB21/ySHGnaFEB/LR6IqfIWJWOp8vxkqju3Jo2wjTJ faskZPOxa34KHUuFBaLGlqMzMaGZfD9uKC8WY/e2v1bSdAqrUSmTV4YK5D1qy8rv3ZfikmS3wl8s ycz12HnsMA6Mgdg9715GMryvsHsmJ41Iouu7N+sbUG1c21KZr2S3H8cYuhAWmnrEG7yqnrcmbSZ6 NWJkJVerMRKPJ1waZEvrGRfcCmNYVbO6McL89SEfFHv2e/bCxnarp8TxbrUS90E7WY0p9T69Zz89 q+sbGUkiz7w4izmaRtajGl+w/JhoaI4W12smdiSYeGb/VWz83vM6M387iMl6yNa5GuAgU3mxdtKn i4L8ZDc6XnARHJ3s2HD0+mN/Mqa76MDpMGaqoE7+DW7ruUeDXEMN/wDHmxryiLZu6u4gPkb6adLG lS2bd0Q5mZMPdUGo5sL1TTR7B/nTFnCc1CXQ+Ugn+u9R91Vo5tiFqTmWDsZCuFa9/7Jg9ypw7lKq 30t2ZAi7g4CgWGvwCu0bgtyQ3FoBwwzquEDEjcUca3iNdOVU2voU1R1F/bJp4DXBZ+V6Iom4l3CY YrpPb+nrTzSVPc+W5YzdlkE7kKjZsk94aT3TVO83FJDtLziRK/Ls2HFcGHb88pdh8G7zrUs3TlZj 3G/8nPD998GvRHX5h7/3jML6jj4FcxX82I5cYfxzN43t1o+Lb5tvMgAp0YzWV7dSf09FAL1WABMS t+4LkB8iICug8xwv/B5uRHGYrf6Fu/Vvln+LvMCyApHuzjh9yB6VeY+K1Jpv4eDBivINCbA0HkYT WwaQMk75zKrzL85rThsy6gfAcPHLibwb0/aqXqvQh5LPcOwZCQZKji8y3TQOoGxUx+gonqbryeJC 0QmytIpBxVG6VOm3JMkzThbNp5CPiEMoHlDJt6A9zKlCS1yPATIJXU60DKCEkCGiLCrsScTJ6JB/ RUyFVYm1yir1aVBrEf7IbrROGCXBzOSOkAQQwKegCT+Hp3LPouNZj8fZVJUgopov4bqEtBSucGEd x9/VrGrfE/MoL8UryRN67EDw0L0vTOJPY/TZjUGxbtXSz6D6nDozScuVVbkub0FqtytArGR1yYAL r/RkothkR7Wun2CTLemUBCxZndlCY0gngFQwKWYvE+qmrhaNAKsyhCqUG9r1YCkzNNxGFLfmd4gI iI4cE6sQwQKmVDVmDIKLq/IPHxsFerdCzaxEOSyN4dJqb9n7inHC/Mghl/EjkfYzTu2/bm994owJ 5fNuwl6hr3my28DmLaACvNWNrJnzcT/N3G9ajhvlmetVZq1KGigjwNz102FqBjlGOfDXf/RM9aWX XLnkwmbzxTsqjY7viTcFv6/b9K13OS7DDZollPMc0Xhf190NJY4KG4I4YuFQYdUyqbaI7XKzRDeF 4VlgkOEA02UpHHPKmJ70JAjMJ7QufERM8Od8ytnz+aWYCZb5RQ9zU1D2BulUIdm6NZqjb0MDxqeP 0x8V5mJTYmjKC7yVmApCtPBeXrMaHPoAHyuv1FqNUY4nRrPOk+DPCZBLhSrTwurxbC+8q7w7qNYZ iLl6dZSYKAYK9vcwjl068TFtuvu42OeX8Qb0W3AJ8r1URk7jwQPfB77mtpa2vMlBUs2Y4YZhxp8P 6Uo3vomOZX8gsrTT4LJOwthDXTlOzlb2NLKwePEHxPXf9lerWqL8VaahU+0Z9Zpudspeq1o/zUrf UOvcnu4SlWejwCg81dT19ueb28CRxhB1V2c+JIvCAEckHMORTkTcQq2np0hGCSsKIZBKp2OGOkOc XBrOuvAotvNPTKXRGpBb6tHgDMp9MVYgAokfYG6TFGR879mDsVGVJyPcAKzVSetZVmLV4ZkU2i8Z Jz1qRaONVDU3y4MJpBlpKvx35fnTSTdovkmQIulY9p0NWgdXOCVa/YMRoTJRVuPBw2URXXV6pq9u lMQRm6+N9nmcAOMSKTLHU0XDEuM1JyWRbKv0cndv8A2FgcI+nKZgIRJ8U2GdXeOgGhZy6EiYSOOI WtfgKE2g6kuS3qyD969OKX1SvTyATAZQbB+NggH0csTHSZfzhauw2E+fFsqnf8iGHoJKMrvAyXAo PtGCqkYL5kmW3Jf923SXfI/O2ecFkP47G8WrVpaXSdFK5MDQNaJ72b96DdzOKdhX8eevLu03FWTg HurfIP21PydRIZyJGCLK/ElMs6AGLKkSqOfvc6AeOeAt9fyjVlp7zVWc5INb4PKXKxC4lAFV6737 9X5Fw2FhwLFHbjHV9/RY+dx+iTEsbpjGtetkc7V7SXwHNFSqVMkEN4NrDHHy1AGCgYCKlm/ysZ7Y wI7Ecvu795/21WQd33c1/smduZ14bnLxa6zkV9m+wwPZnMy8LPboj31h+iV27ul9ClSO9KRP1gek A1v+U7Edsp+BP/nbjUXvUqwQ1Q4pqJ8TRq438EY3/zp62yWLE+MnxQhMpB0Zob7kaN5PoOlk/PD7 N3NWYi2q66rtN3eDhyvfzeAkU4Fvd6RMwXGMrWntFvNyOirrUnXvOA25Qhi6fnNR9d+hqUh3Dnuv CLXyS5/q1/P+zEms7za3w2mKA78cruCFv8BS4yUaFLxz8i7nB+vH0WC7eeF2A2GTW+Ho9wFv7xrV x0c+iQ/OngHpwSikGWAqu0mA9oPZWCBmWn+rVkpWHdGHo7B9DS17hX5/PepHcBgv3OxCiMS1EH00 UQvZCZcnuxsDou0dtYQ7IhdN4Jh8CnftA+E7oH7e4Csh1DmxyKn4mJNfAb9exZxeR3DR5GEmCMp1 hHaIBJ8QQvgOJnOQ2tdOkm/xoTL558aH3/mKNi+zDKS5c+MjF0aCiXkSN5Q8LoVILHfFMdKzpGLL 4H3t8EC6Kzc7eUYrdv96TM4GLo+UKLAVL+US6b4R2wcBCVJgVXwe/6EoyC+hz8y6+zzSPkA/GRvf BQE5BqKz8biDLbTAITmnJfRhXWyk5MOouqguLmj2NQe+Q5AsHVY3ass4SUmgAj//xHklqDL/xsUe gjLUIb1BkDQSmIVJo0sJkUkM6PlNxq8mh8JSSkZjH7lJxNRFouDgZEqSAfeNI+idYW5obBlAODDu QTSQqyw6YtZYuQPP5Zq8F2y5Y6H3dZ5WNJoW1eFoC0+3r6OCqMAKF/DODDB91DWSGCBAT+lTgFTH x4ELKNsnZjMKaZGrlC0lBmI7JMa5PZZikeHImR4f+1BbKVOcBxoj7m5cpS38BQjlc8vWVJsRpUnl J1ivZ2I/onuVEDmktBcWWS8Tot7BkqJeZenp3dcYczOmBjqHWOo+Qzs5Gr7hgd7epjrOSPRRDSgu 0Mmv8MLfdz/NpV0/TVMOzVBTNmCMumlfF80L0q8xM39RbRnXlY25EG6oZys4r6/2AR07DVDMj7V4 nDeQkOV1Eht2mGdpgmkj4qv0ClU6Aup+JhnNAlwLbinhcHgKMOVjtsj1oFk36mkWDM6LKAu1DlXO KHWLtq7ICidnzp7kXKvJPjgx7DODtJGgDq6k3pGQtu1cZT0I+mPhBEPPlO8wP+1X0bNA+3DMTZUx ZOR/qIaGGgVABHJo9Y6e6K6AuTZ4eID+glix67x+Ng3meSqfzq2Lb4H/3rZbdbflUi61NcGUT0Ps pvXjywxAPJgVc1BfFdyi9i7UEi4aoj+GwwjQUtuYkmnO+PZf3km/cJrTpcOVUnwk6AmClq9sVFeb MwgXN3AG25XFCWsD1dgR6splUZ0EAXIF7j+1Q4ITibDaEH351XJFIYicRXnSqlOfxE2Aq78R1fJj NiyUYlyojUOTSxUwlcrz7qq/0WU6CVn0h9UmhFgS2OuVm1FLegoxvDIO3hcaSJ0tE77mbEFIuwqt gnhEMRSfFcBVQlBlcKFVeCNRmGcArEr0zo4uXREvylAHrnRZVihBUtjTfKiwxmm4Ira+ygMcT0fa CQG7t0OwREtBUlFfO1CQ4vHPhUoMU/EBvMonCQgdcYA9I1WK1UW+l4B3wENpPv8xmq/srmlrBU+X 6GZgSGSHzvhvEJrovmuu5S7eGDOe2N2Tt6hiu3jH8PP7GqiHPYz/ybscmZNqa+vTa0+77CMCSBx/ 8EvoJpWAJwdWlfZXmRsBiERyE7oMFgIgxNNSw0/w04+xoQTdP1KlO+NybZSSgi7PLDKE8Kqp6Rhn /uzyPvIp7Yd3OeW+Nwxw7RiHwRaEDsDlPzCe8v94us2vnA2CGZl5prTAo5QRWtMtCH6kHQmeQSoO rbBdPrWkFuao/H7ifb4gi+ip/hhmdAwJH5W9SjXV1i/FqUPUdot0GwoUxgvsB9sNPaFsurgQtCqX ItGG15F24iDdQ3gq/ggy0vDyj7xXL/zir9LLUIQ88cm9sIa1C20Vop1jXMlGs+HHvxMAZYAEIeC/ ELAgERFHgddXm66YB+CGiM9N4Fqr8IsUiG5uS/1RUEgZXJ+MgOmL2hMgbFjI76Q8279NcfxPzwba BdUtM05wbC0GQYRyHJV4kQDMIN3WJoHjcG65q5SIqrjU3WhdLL5owSeSDraSQMQyiI/QEnXYi8WV g+126sAxcVNz0lOLHvhRLvxaNuxED39LB6e/6puMxeGnIa/4nZJI+HLS7Ys0GB8AZtxzx24YCaAA OzzCCjC99g/qjO/1iikjcknPl94DDepMjQ4BgBbPnDsEkGueOQU4eNzvroMTxDKjSdCkVzA+dsQ+ pMQcC8kqgztq4wz/Ep5e7F5U7TbagPLfxcjWZydPhxWbiQqwRJj5BZyZG5qvRn+7iMxVRmhTKEZD SAOS/992QsWFAQPVjkhPVxaKa7hWt56yvTcCpvulN+nQx4/eTsgbWs6GReriwgAw+UOQTaGv4B1j iMcNU5FBK68Gm71hho9Wt/WVEV1oKIYy4nFWTJh8sWTmuWuKMWpPD33+yvIMz/afPoiOWuRkOsmo hqrjsul+JQTcxRYDr7N+c3rtnY+Nqx1wYysY3elG5YaFH/3Vjy+vLgW7CsMU60EA5RR/dmogBgEo gETicBXmZPfXv7yTU8xUinxvuIDrdNzq4oidYjYdaohz05AvVX154YPhV0X5VgdwG/AmJOX5OgDz EZRMvxsvZo1kN2Sdpl55Nel9Zp36DJxCh1X8jCxvqWoUgg13AT3cX/i1AOti1FaKG4T133zg6kdZ gFL4+outCHxlIX91KOHOU9+k0cmH1UbtQKcBaT4KjKiGMBJiJDooI9q/vr7mVba6pyhlFqTI6Rmc dyulDLbC4xmGffz8KIgTC6nzf9TqP150XQt7CAg7BGgW6nkqMCe2zOJt3Z08wYnqs9bFE7bPJ0za Mg2/dEFU7q10VNSbGG7O2q2IWydgg8O85l57dK0Fzvk+aEYkTlwtbD9DGi1p48T17JnPPYk4sZYL h6RsfJBPfXLZwOSiKiLTbX7ZY5DF23yoDTys3VvT2pchcMf5n57TsPm/yM7dJFzkjd5yA4X8c/PV +/OciI91JZ8w/p+q9j813/iE8PrYun+9PfVD2cOFT6CFjtcL8kULLvXt9D7Z/qYFpM3intSiUHDN +NLCZNPEG8Y/ixN+i4MlH2abZOaWFodKlno5l6xvLC2XSC/ILi3dWHYAL1NSljealm1eL2/vfxRi Xnm/v7xusJJpsrz2cPl36sJR6tg/N679fL0CNBxMP/euwHb1q/LqfNNq7tlKou2Skbbt+eX3hx1X WPoXsmaAfDRfIR2tk59ankOvTfgKy4ViNXcfNTPByNOgr5sAg2nQic7j1U2AidvCbgi9UWDB8Qqz L9LkIuBO9UavSgnafNoArx5F1n0jp4pBs1c/YMr4CvWu7dbkY11D2Om3seumlcGshyqC3t+1cISq FCZ34jM3+UbuXi+8KIU4GVk798fEexy+YQO0Cf4CS5u3XEYzIhS8Gw9BvJ2EOYnNTjhMyHnTPNoD dQhQMiMkTsMfXBV13t2UqjJNkVXnvUmSJ+tlk7dQWWtj/zyAb0GXEv2I+k+pEehQspvqIWgqFB+m 5pCTapoNQAgkoQUAHUNDxIcDGSXvbZ2OvjhpiiIs7QJ37XjyYOc+bTdVSQHFbes57WpwajjVsj/n 1NgOAX06FlI2OFailulMPfcqMC5nx7x1JwuASJ54sF88Gy9kvdbtwUXbJ2bt4jZgBuxI+VWc0gcg qzqERh8KcyYFqkNQw4Tqdnj4qnNJoUvYLJDWAk5dTZ9crhdYBaoKQSyC8eckYOcAsAwK7OvuzvQa 4zNKQrwvd9/Jqo6JCv1kN5BMgn74E1GRC7IvrLj5RpdM1ssiHdyJPsglFekeFgvtA9jYq7UPYVzE bz1P4IFCEMzYI1SLxxIOKL86kCPkG1521281GoX1xLCTY8viVLEQzMftqVA9jBBwP642lo5MepWQ l9OWJUR09GsaG4UT/gFUkVyDaUDJll5vffrVFXSgBKKN2HluuiJLCEim1z6fsd0MxLOS3fDq+LxN 2Bh8iBXL3K+GQE1DAi0e9PjAI8iIoOFH85636wOfsgJgHycNrD+AeNUQGS1wKRvI6TIkZX6b2A0M +Qva1wGyYn3qxH0xdLg8PSEOUEJimIDQ6g7PC2ep9GF+IbgzvWFmBRj7Aq1QdBDAMhQqhMihNxjY wM9OHVFkuBrNMF4HcnYK4toFeG8DjNkLLBJ2ewyBshTG5HwJ4DvorZguoKK9DJtISuJCnowa4zXe 0vWE7LzyN6AxKBY7ceMd2hZ+JNWcIBn+dn2misvABUgcdX3LzIZsGk3MNN16U4yuoEpxKUgyMcvw obQLs6P4LhNKli9kUJKnywXCjxY/ijiWE9W4eEz4FBvRCEeJHDcTh5m01HIlSa8o4TUxGIw7DB57 jQC7gfyo46CQfAemHMtvFya8NZyZJM/38isArCXWjSVNDqRorJVrGiPXGKfzGrtiz41dNIqHRoGZ evpHuCjlxJicJ0ittdmGdxLE+thuwM79V+4mNYNZy89idDx8Wdqe7LyuZOeMI8Z7/dUADWSgY/GH OEsQCFKh7zfzxFsVVw5+truf+SY5p9mexXgDO2D/+7BCko/fx431lk4j0TfTUvPlVCuxyroKO63u oVmugsyIwcaSLJo6PjgWvUY2iz+T7SolrKZKyeUT751fS7Gux/Ck99w7/6WmAglu8GMeFtXGjg6m p/MgoDHaq0S6OIubtVOG6OWze01qJAuneL1Sdk7O2EKskbAgKoHluvIGHM0RezYaw7G4d9VrfKix zCsTj5KExHC6ABmemfrZXk8gLOpESTYWq0O4Oiy8Hd8qkh4inB7Fhbnaidd8fCCtgzt+fH3F0Otz DLelzIE23zf4vWf8Je92r3SQ6trSivykcPDYCopGM+/A0e3JWyR4dUyOOIaawZuUj+MQRl2+KqFM koyCxzJoqwr3hAfdEu1ctym9HVx1Tpw3sHXunFoW398mE72ICZzy/HBmqjw3oYpmWZhdxi7NkK6K sZQwBpikiz/bmywhSL40WenE3zc1tD3OjlK9SdMwK/cK96lldXF3y0SG0AFMiyrkwEyc+HA9uxaB MsSuvbdHctRNmi8D4Y757jaJHpPn+jm5Tu/FoHU8IE7KBAZNbOuWCQnaSkQhGjKRbBuAeb20VWEu M29SihBexliIk6+RTs8ol8ZuRNlIKw+wE1Br9xCEyZ90sNYk00umyAd/Hl+XMzzGDVOtFy+OsGl2 cDn2uTwFXZVWASjXTmAbCiS2uguHWwfSl/j9+Pi2Vw8Hp9Q6Yzglfpr4TbxWm0Z+0lTe77cxYBtO 0rv84Qw/5XrZf3fUu7a4c4A5XsHZQzg1/GBJ5osjs5HCfu+7/gwtMDv/JXHuBvnare2Js03FoDDg i3bfsG8vmhkPdtp4X/zdV34xdfu4eevm3x+9vLcYP/9FZ4RwnRgKrn1xDuiuT9CGkABQJXUQzzQF pkaqZuzFYTZOUn1ZqRl8m2QoC1YiDD5EYrrWrcHKxE4CSZfy839V/6JMO1+Sr8E5SnzJv1QXI091 YHGuK+opgPv+jiEhfonHGZYNcKsI0ZEFnwcu8LxN0J18fbjn8pxjkxiJUHVA2XCAsJRyZk3U+39p 3dpyfuwkNOd4IpJJY13tu3ZxN5A74BBpQQexqHSLMF/SGZKbe5sGMSs7V0DDxGQYx8uoCHO5cUQr FtJTSfAKVLzfS1XFmYweBN93+Bzuys1pUzfqAL+DA/48HydLO3ZQCqT7Sjc3M5nA8vncX4uxWyra LNeVALJ2L8cMgmZSn8BjfsTVaZv+9IsjsRC+pzG6COaFxhgJFor0PH7CsJDOqoIFIG6+faF0eSbv wx7pn72gW448/mwrEFelX0SKRuPTgqLGL1fdAUDDw2+hjEEXNWW8GlNQVo5vvubNWiHmiJ/+yMc0 Z9mCx4ZAmrpDWYWL/8YzImTEPVGkXULaAMAkZfI0ifecBnxPiGh18yrIBFu3wv/zjRICoyeh7U64 02OS2zlbLR/rftsZacoieeRze9Qah/aAuQ4MsN6CeggXueufh2jARL7i8BmtLcQMM5JRrIdZtcqd evP39Xdj67EYS727Km3cF6EeRGUP/XTxQKXJSnHz9z3mnZ3vmxZQonftxeJKo681XhRouBq4yoDA JU8wB+GeJKjq/Mvl9nNK2Q33vyKTm/8cP9H03rxaQiQaCdc+pg57uVwreq+3o/A0ANpwbxBp2Rcx 2yxjlc9idplprnOuoznW28tZ1frT3Fxn17C3j3VDtKCQ4tOkk3pbXelpV5GTdnlNQ7+cXptNxQ/P pmJ9AqpVbXfMu56xzO/49nrEjyxzN5fISCNSEm2mPD4839L2HRhvsO2Ro9dWcDfYfQhdPJ770P9r uPkh78LSqz9mMIUyrwioGgnEG/LkjVk0OeYPUiB/js4WR6buMlsx4t7XjeSQ4649XxNg4u0PIpEh k+MOnHn5g2UPfS0uoJL7C+eH5SMOHXf/vMNxw/hGro98p+7uWDC5lg8rM/nRbu1O9lwJAYjy+GXm FGN7WDsKbuLBplVqzlJ3P47fHfHL7XjuLBf8ccKeyT9/WCaOAgCo/h9QSwMEFAAAAAgA7iGQJz4j kGjxbQAAkewDAAoAAABwYXJ0Ni5odG1s7F1pc+O4dv3eVfoPKL+ajJ3xos1Lv9h68aa0K+3ujpd5 laRSbyAKlJDmoiEoW86vz70XADdTsuSWbXpGnmkSIAng4GI7BwSow083l587tQ/s8NP58Rk6GDu8 ubj5fN7pnn67ZZfHX26PP7Or81+3WX27wbbYt+OrG7Z3uKMf0gEuz2+O2aebm29b5/9xe/Hr0dqV GHkPW3G4xpwwiEUQH63dDx8GQvyrL32xPR4dbIv+eC0b/Mvx5fnR2r+dfzm/Or75erXGTr9+uTn/ cnO09ncK+bNiPh9Ih7kyGIhIsTBgQ6nYnQxiPhDsu3johTzqU6SHOyY7hydfz/4TzuDqQnzs+uK/ zo+2GnClu4X5OxNKDgJ2I7h/eHKFl0tyfbiDYTG2T1c6rm+dfwp6avQvGefsIyLpZCD80ux841HM 9thfTeyHOyed8piLTsTR6Gj8F4GKo7ETS7DGtYhZP+JuDLlvzBmXdWY82g6QVcZOrs6P/x09tnjU 2Pd59LAGaI87j8NAJbg67yaPbQ9j3/tLEuZaOzCozoV9fASW2C08/C0SdzIcK4Y32fruRhKsEHC/ EPCLmMQm0H420JyllI16T0fd5zH3eSBHa509aALHkYyHvoihKn4diYij7RUlREaYJ53nYzkNI0EA CAugwQtZSOHSID0/XBlw3u8byAAaPIhuEx2Kjs4mU3DSR6VPTnXQq3HPom8y8Gj04OjR0YUjnPTR nNzqoPfHnkXfYuDR6MExpKPSR/AoOOuj8ShzGlYnM315ZzPTZuDRmQGHoqOvjwgczvpoPL45qddo qF9HcaadNqGrwEbJvXfSVqXBrRurNPWdnFVqlAlMapUWJjmr1PoSmNT8LExyVqldJTCpYVmY5KyO NcO+RbnLwGP6spAGDTjp4w818aUDTuy6h0CT4g+r1Jh87liU+0C0HWNX7ig6DvWRjMwdfTSeoTlV yObIIeyI3dw+YNqfUo5xz1AMPWibS9XBPwpHTjgOYpuDj8xeMXUn8b7CSJanv9CFJUOZDJxI+KDu tnpciX5lxzPAabDDcAYeY0R0Vaf7FQnGJgOP7XxFhTAGYmAxthh4DEZ0VYcUODywINsMfZYUgHOT earXoGMdOjRy++iufVD6jtK3lL6Hp3p18ub4I8/mbZehz+SNnJWCKSzOPcIpMkBFtZBKi3SfkMoM 0goNz2S4BOqBNmoWq6gQWN5TFulHBh6rHqo0xPp8kowJdeA2E8vKwFUdkDLpyxoNBj4LElxVsmRS MRtNNKVMbVklhiuDFGcLrSlTc1ZJ1oZRnOCEIQy8dghD5+vMXXz+cq0xtFO69zkccJq8kA77MvZ7 ImLXDyoWfmWJn5fMOraB+XnJtKMiZ3VgJmKlDeTPS+cXyVkdmE1pJUkbCCB5LVByV4jwx03PIm0z 8iakH91zIy2P/3oo3fgqJGM02YmM2fVw7LqeDAZs2VJoXkz4IoBwESj7ZoCuMB70GcDlsahsU1UI 1DPYAb32245Pe6oFNrJgmxpslAUbVQ0st2hbBi3PweXVwRuFaT1oM/QZpOSsEsykBuwizCiF+UOl Py8AGJcz7T3zhkH3R++q3UuTiaThy1zLrxI7o+aS4LVtP4c3qhxengBOmn8eMa8QZGznCV7dA8hM F1AtpGlV0J1ABmmVqkFPxuHIIt1j5DVIyb3Jes5wAEclYnR7ERxjFeN9vFH7oPQtpe8pvFmx7CUl sa/zJx9nUOocSqbzKHUmJWVP36ZsSpNPaTL6QwU5bx6oP0cWqbPRKnbolmBWtScHM0fizoCHjlz7 dRlod1g1sNKibRqEMgtXVgnvQywy1m0xc8FWceOr0GTLxGJtM/AgTrYODm8TvcON6kAVkxHwJIt2 l2m/Nuy69gBo7agSbtUfjyzqPYa+xfqD8lgvuQw+hwNJb6NajJxvpGZTGFbNLhvNcgvEy+DF6Sb0 6moURvgv2ERCTgdwTvBioI9hjAd0Yc17pRm+FG0zN8dXdQtLA9qa2PTZYDmpbSvR2JIsvMDAXZ6i 64UjepnRZl0vBJvAAPwtlEH8Bms/u988cSe8BsGB3H9GH2u8HLDlFp5rJmPb1DrcdDLWpYWfeJwY X4VewbhmbrZNEz1uOjfr0toRPE6Mr0qozZLPNk34uMmaT+XSCk88ToyvSqjtBHObpn7czAQzuTf1 pYn1Vwg6Tiu7FvouzTi7Bjq5N/WlifVXyeqSj6KJxb7HtF+D124yOLkSR6Va6O9RnMvDPkuvmXwk /glqvdRLTTe594q9eFODbZpevPluenGz/rpNA7CbLMBGF1lTr7omb8XqiIXd1NUhUzMQOJ7N6Q3r Qevd1APgXho6snP0GXuCi+oBnM2pSvUAZJxFDdUAfAY1uAg1nM2pUqO5XpzbJuXvJqtz0YWokxW5 VcKcrsFt0ySAm12EazyW7+lluPbij3J2X/gh7gTbg4H4ktzs2HGEUm+kYwEDgbEq9qUwLbcAoRvq Nwxuklrc8HV0VWgNn4rBpgnQJiO/oV7o/CGo84IA/ZyUckZNv5+SbhrslS/pBOiSS3r5JpUWaYsM KVObyqoZNYHa1paUGatWCSwaz7VYd8mWbmpWt2oVIIG6p4s9g1VWCSyVcwJ2X5e7m6kDlQObmvbA 1NIs3EoZ1+HOUPh2bNj+yMyFxcaAKUwnvBM0O7nHznjMGfrfiuQkUCzNeQlEyy0aBGcgA2j0VW9g dsBqFmOT2SvVxDmxQFsJ0Em1kA5EbDG2GXiqhW40TtDtMvC8VvtF9po23wx/rX4TxnrmG9yGuy7Y s740QhqREoiGtVYMI7QEaRG2sF3IyjWMBF8bW8aC+KaMzGEQRyG9J9nPfUin64X3MIbR3Tf6xstp BpsdUKdClOmNijXP//VH3OQBcoG+6nUfvN+PLEY9wuKVlKqjr0qbRULoi6HcHyxmHGzNpWoaV1qk 7cSeMm9eWTH7WsC7ZNqKjScPyuGe7Rlw5Y++oC0aR3xUHaxD7sUW6D5DX7VsGbnCwjtg4HmzHj7D ud5hL6+i3j8UvzO2pEX85kr1cEaCCJiF2mSZixVDKyLJPfl/CdYWSy4h0ic/2pe/R4nor/hlvuih Izr81OzsTfu0HX6hEO4fjvKRZL5EZyNpdbSSnv5NOoqrVYD+LR8xLROiooDc/P3i7ObT0W79J/PJ wE9tnYb+LhVF17bQjs/OJKZC3sMbfuIJ1gujvoiO6qw3cEIvjI7W/iIO8L81di/78fDo48FPzBGe N8JvWwWDo12GgeOocxj3O4e9DqYStTZZ1IR/jcOdHlyM4BF8V5W9YS86jy6qQhTJxcfhVTGCHcqF zeB8dek09IEhC4i9wY4gIvYLxLjYRxB1tjGzUHJuGPmK8QBXsIiBiOiDYNQ9hS6Lh4LF9yFT4Thy jEwM+qr2YT1qYcLNDdqEBIAUPQstbezFEBX5+tDuZMB1ZDooW48aG9u2st3it0kPPdlhN/A44FJQ +QmY6/EBRNOXDse8xkMeszLckAx+ZDTFrFO+H4ZeCpeFEdzwHvAu1x+PNHmzT2znYVxfXJ4tAgMh +JBxOYJUs1gwLVVIjK2jh3Kqbyihn8NYpAKruTIQfdZ7oFBFq6iNAljF43GEe8DmANwP4WIQxpjU b7/dA5v4+Wcm3VzZKdaTA6wIEFhbM4N1msUcHkUPUxFgQHEHHHYMIyA9igDuuDcWmN499CWxgLRC ADGQKobEA70DHarLL1Bh2IULsHVQIBoAUcDzAxFgzyP6mxgdJhIIORj2oLKmEUH8jid4BBZdr0/q 9Y1NFsKj0b0Eu2OYz9cnaZRKxPRYg6y8QxW0Zr7Kenr+5eac+uGb45PP55k+p3uA/63lepoW+dSI O+ir266qYfof/Ipt3M/GQX9rDAaAQXC0FkFGgFyR6f9qHja3HDCkAE1zUH55b0mXF0DZk1DLDcpO nemOZvHTvonhYIEwjZYJ1GgvEuqjCdVcBG1z14baWyBUq7GQLd1xoNnhlFL/+u0fMBKW3+ti/1B+ 60oMWGv6reb0WwjfDFTgMj23Hn4Xr++F+POWIvh565UHu34IYj4xhfErdiMm152utd6sVA+2bPFv /77Jtvs4Pmz32ChUsStttDnOZj5ffA2tkUCudf5ZsyJ69Ix6bJX2lRCEAzeC3mcWjEbdhFdbbBSJ NOkGdsnQExWil5kemPIIXRuNVDMTaZhY1oMwEOxBxBu2nZrzFQxA0R10jzOjMRWks6UKdiqAvdaj EcLDkWBmnLbpbjmz4zylbp8GlnUcbJpR8x6HGraRrZpUOXWt0f11r3M+4fjtJOibaGjCp3XitiYf 3nauQV3zCKnmbVq/rxr0ZXMOoozVJ90Dtn4vNIXAtx6yT6OjYKDfwIW7syzlscOOMjuJrprZiOpd Q15vOpaGQb2LGpvAB4FQIca/ApsDXgfP7rN1oAIcx+SeGHL8XHZkYtVB1dSw3S5bV0lB5AI5MxIE TtomV4Ot01BrQ+5owN+MxbDOZe2Vt1ad/roH+oxxSaRde+0tGCZwOiMWfrl1TEhzbuZtpWYaS//t m3NrpunUTNsZEBZFi5WbUs22ZRFPYlr91zDnOrOWTq1seljDNiCpb5pl8gAY+Hr3tE4VcQNLANTK TspKTIU+nwhnTA3wNgCDU0Gx435/53rco0smD7edz8CdAufBPAKF+ABMiUFa7IDKCoXkJmvq64pu NPboDjA1U574TBLhzTAKx4MhyIEkzrS3AodJAV3H17fbM3UirS58UifSh4HzOvH69kTFEXeWrhUx pYJWpIzjR8GzN+xF9/HFQhTJxfKr2QjSnu7H1OLWM9QireuE7rZMLeKXVa21HyvG2odEg6Fi3Jql GOdRiwwHqYJeJGhTdM8j5EYv5lEvTTMuBMUKxjI8c+pGDKofnaobE0iPdKPrhWE0D+JZolEJ6MD7 CcQS8ejKSIHtAlFIHppjFN6n6UMv64N4VlrkbZRJSB2kNp90zCtHHfTZ0rGoGcsfRvEIQLYaVjti da2t1ONKPeKpKuoRxsfyeyv1+LrqkZln/1Ty0Z0t9bo4KC2gHIt2L0R3orv9t5OO9d1lScf9ghwa 96bLv/PZ+geY5QzlwtaJGWywbIBZiVltg6pTj7NJ2GcIx/puIpoWFI5WbTUKlpplqkLQJ4TjE5bL /TWtHXPBn0LSPbfB84ox0aP1xMa1lWLs5BQjbYp/UjHSb7TkFePl7Wdk4kg3l60ZMa0yzYi/wfRI 8+FPMZVefPyoKkScXCx/9HG0qhhvbUkCc/IMgUkfMJgiMI1MMoXzpMScPOOlJL7ORKlwYwdg0kuJ AkkHZpN44W3oUwJ11os5LEa8XRSoxVwvJFExggQcu4j1U4k99NCTlbRTLbTge9FibjI5EYUsqeXK 3BmvR4E5zIP5XnpeMkTXjChMTA26ESPS6YoJ9ILY3OmZy+uTQpJD4OJzJ8k9FepVw8qmiuGnlhDK WirU+zD6jpUUyl5JXyITcbkaYnWJQxuVk06dm5js62nSqGNvkYZ6C2TP59F301VjbIV66lBvkNBL hQucsEyHgt894PK1BxwIxvjGGyuh2grdLWjK1MtRPPjLn2BreAjyNIJaS9+vLGl1m9AYpDNkMf8u lK7gXA8WtQ8Q2tRAW6VhDNy2w8VKiK+EuAn1tkIcaEf5vZUQX73GfWkd/tRrXBw155fhw9mxfcIB 8fVEeF5WNltLkuCtvbywhDFrqprbayZKMhWASM9nhUDJl7z7TWz2zJewrPT/+SV1efiCtJ5lgqlR JHp4pj2mBU+NVP5Azlr/jfLEgybcZx5QsAhZgwALAO/C8hYgpIFwEA/rQT8Iwlo48PD/mNr4ArL6 wsiaS014Hmbp63HwPQjvA3Z8c7kJvHckiPTPWJM3XVbnohpFYY/3IO3pYvvi8patj+RIeES2U3q2 MVuD0+ejntTg9AOkeQ1+dvGrVMtW35hK2epe/NHg7A170S+9WLKQtxBxcrH80cfRqmK8taWo7xbb gfgWVd+YmZwGzahv/HVYVaq7C4uBd571ajeV3KmsA/4+zOlwapZqFGLtB2pfrP1FNV57lhB/ZIRY 6+jUAK+ysrgIo5ZV0Fksr7Gy+DonnfvIhPxHFAatoIbh2OtjFxpHAt+qYoIg48aBEc1gJuOiN7dF q1yG/bEXpkmpkXCkK7PvfiNQnmAuqJImz9YYJm+ZF8HZkdwuIK6li3nnaxc3Q6mye3IgZ/RiG1oH 83kMQzPNEhtLAMFuZl+CJyuOj+pUySUUQTKhDBXaWIvfhcBG+tCbQYR2HTfQrGRvhdperDGXKPSk 0jxbm1MM4csJ89U78pU0N6eqSHNgI+X3VtJ8Jc3flzT3Z8dmht63EueN+rLej+/mpSkMWtOlZSvR oMjDZzyXUZuNxzK89lLi8AxG3L54U2kofse9WoZNeSZtqOExS1RhmRRMhODXUZzZPgpqsPPoUbOh NLM5evam0qmiE/vHJ1VnU+8pleWbStmF74u+hHwuVYBSghD1wWMNqkruLWc7KMa5vVAkj8gu8kPz TslUgd9+A7y47jPzVA/qEL7aN0zPVjrIW16SMTcKfVMdnRAq9joS3hBC08s5ep2GFHWD3mvhGk3o VmC8iUIIhmsIdFBdG5CyklrZBOJJd8aKD5IKH9m+Fie4MBuxntzBt3V9qZyxUqL/Y6ya2Po9NlCb wc1cK/H5A5J78xaPFsKKyYgmluC6w8dmESkYFN803pMasBfdMcC1TQzsAWIvoj4xpB3RYWbFNWto w3JIOQIL2C2TPu7PxmRrHw7QDGqDaVtEAjSAD10FADFUH5OUgbPTF062aBUUEU2U3XGoBD1PbGSR g0TPhAVlBt0+dCOQiKb+WILc9ODGKMk78ndC8dsLPf3+KH5CWhrNZ6f07jdRXpTfnMHxsWstv7Oi +CuKbyj+D5Hm4muY7gFuiOvW27vd7kGz/P0NxZ3ZUyihHOqTg/3y1yrZGOsfEyZM4fpzhavXM+HU Ewke7O93P+7Bcf/09GDvUcAZKTb2u5AoHE5PMcXaD3LvP9hqR6AB85Be2iAnp26QeyHei2kSD2Ul xDe5uSTi20Ti22BbhvguQu3mIr6Ad2nEFyFuTOO/m0TJSBdgaoKTxMpQYrYERgwgV5S4GpQ434/V VpR4RYkXCPUiO8NWlHhFiV+TEhMTnJ++/ZEInD/25iFwtF+lMGuZ37BS4HDLY3GUsCyfvaR7y5+9 nFB6L0DiAO+SSRzSLuRvW3o7AECIc/OXObKGu1SqMn+Jyfh2+VmVV+yv2NGKHVVquf6KHa3Y0StP GC7ztfIfd83xPESKFh0XiJRddfxiFIqSnEKh6N7yKdTO8ufBfvsNsAJ9QspEFeHRV3909UjIEK4A 1d/ogepCjI4WQeqV9mYlpV1Iid+0x1ZG04XFtZOr5Y8rqrOiOq9NdaBbfDOqo19mrYjOiugsPgn0 /tfPZWiNHz79Qwn4M6nwXGF26OvZ2AuX+j4P0yjbSAXXS7Y8FZ5OLuYeXcp2p5+esd0J0U3b7uTr 1bBPbXb66VmbnWrP+0JIEW5svhBioL7KtqQiiFruwx4Jkve/KelPuknIFOHzJwMpfIEi+1x9p9gv r0/KN+ut9gq9e7KcP/0pP+PxdfVrDCu6XN29QqI//26hSk1X/lFY/DyTk3s4BBff8hKPf6EVepTc lJ0pJfeWMTH5E8X5DLouf4yv25Sf8XkCOyeZrtNDJrb+t2WT+Vf+ysBb0/mXZNlUZCuW/Wf6VN5q Qvrp07vn2Kt37yuOXc2ViX8qOsudOdjsPoxKToHM2rUHONIdnzpj4BtL57TcKZ+l5s7jWWq4OCy9 WDahzUt+97c0VlUarXoU7xIIdYP9wtaZ+eI221iYV3MHLbTcb25z/NnjDLk2VW3GlPiNrdvEDhOu +qjOF3i93l6yNgAP1CMgaQ9rAMqdmhouUbiXDsZLdB4iNp3LkEf9e2CIzAED9ENcxZm8ZVr054mx npTR+7QDeyV+X8BRy/L7BEx1PsFt4L7mJ7izSWrbk1kwo6aMKIoh91xRtI+ibZhUCEDJhZY0P/Qp 7bL1Nz4MzoALdEAfuXlWNXwXUSA8kxsZ3IXeHa1b9gX7LnFhjotmhMt6MMJfVImg76fungfce1BS fxjefvkykbb0lczaB65bcSAEZHYgYqOiIv3BvlQ+Gbtwx/TnmBrtkqJ2yGPOwjuogx7+aleymHkc 2Aqk8CedPdmLbIuXAQ5h+nWMXh5tPv/Wfwi4L6EX5sGAfviLfo9MTBxAqO2DT2Vt5IXhiOBG5nm2 Bsk73x9Y+nOOa0yAvINsPVPaNRNxVyi+SHDqCCORrcBQMpiacEONiUNcJ51W1Lg/3DnpZHoJXa6U yTRrEe59wwaIG4hxf5l+NuUJUGyRM5SxcDB/XsrJ1LtaSb16Y/L/7X17d9tIcu//OoffoaM9yZA7 FE1S8mvG1kbWY0Y5sqUrybuzcZwNSIIS1iDAAUA9Nne/5v08tx7djQYIkKBE2aLcTnZoA/1Gd9Wv Hl1VodZqS3M7u8XvrMXESnP3kuaWYzF5gMDntdlmExkW4tHEOSep5XQzE4qiMxX/3JmRAPnVi1fZ gGlY9dN5yHG2ZwXlpkybs0Jz8yi+QlhuHE5Q5Wbht3Wa/3Hn7GNtrdBzXgll6ENfKtOj0FYh2XK3 9Upw0axkr0OoYV8PlnxZ9lwk3vOrAll8uo75PF9hWeHX4ATgSmDc4amUywuKlLAFv6koafRf+wYi 5DeRqXzviysODs458gY10fcnhpBxsLF78lHHfoAlAsIVXjP3BDjP8TMzcJ4WkNqbgd5FGXhv8pCw eeA1sdfzfC+5pRxP8uPA6UoudWInvphqJpSWMhQlWE68kduyHlRWHhg/qlBsNimxFQmqiwQby3NY moe8v1IuIYYkpXD6+es0EvH+3jSwfvqx0ErR6xijMkyCpAJ+fS1U4SyCPTk+UcrL3eOPH86XClx1 l1nYGk89vzf6DHp/Q8ZVj7oLG4PUYMgiRH+TCmCOnxXS2aXAWbi9AdMixsCUG65p7iF3EvxnhXwv s809U0E47m6T0ev8GAwzhYOpPQlojbrqi5AsMiTkx5PxOIySdCBDL4phizB8Bqg7jk0QjfYJD7YR ZjPF7C9A8/8BdScshqfqcCD1uL08NASB6IemPRTd2VvLcGFC64bZposMDDZajuKppp3aWj8CdI3m ChhWcu1KI8Zh0OeSUnufoY5NFURmELo8PJDYycrvBkjcKCjccOKbaxWLurSu6KaxdgOX7e8TODdD Xi4yPwGEByaD2WH5VOIM+RrETnB77dw2ZRg7c+G1hIHua5j7l0E/7mUnYOUKaQWAZ9F2dvyLkLzc yDEugN2TqJA3ua8s49XIMDhenAarkVFuxHAC0ouLG0xSaStjWBlD1vq2Mgbw+MWNDu3ix1a6sNLF Q0gX7U53c+v5i5evXu+8293bP+BWlIiQAkYUEZR80JXRmc0/3fb9JQRVrURG+Mhq6tn6cMUef4jF cd0PL7p1/NiNBn6Y23Airh1iUqjJwvKijvyP9HIOgAIo8UPkEldFTBCGXxrz9eYF3mtmShJguWlC kimRQiYk2UwTkuhYrhs9B3WGBjr7SWYlqe7Fjq7yGSCAXkcELyUSRPfzyxR3yCiytOpebPJ16dFN PhWhGiuuNYezdciVg5oaG98aneGB0QMk9Q2kRLzb5X3agv28w3gzHCC6IAhAGIzHGYV9N44R65Bg QNKAE+grtbU1lYGeI8Vgj+Rg379kv43AQAmsp0SfFQYlJtK4ciJPrjNagADojceuEwn0npj1ib1g vnviZquD3zUrAh5+2OXlXqrsh93kxD7z0XLsDZ0ao62q2zAP3dVGk+Q4I3fR91WAPAXjtPEUCqcN hHcYlEMpbTyOv0wuQLjN1c4ZsAjIsYGuI2cco9cKkDW5XyPXAdFAunWNnBtvNBlx6dZC0zw0dxo7 C6Zxmbl3ffVDZZskf6Qvrjum4grbwp72XH+gL5KocVhoa6GtqvVtoS3QruJ3FtlaZPs4kO3BQfv5 q9edbgfwbbtTloc+A3eRUyp9+BTYffFqp7PZ2dp6AVi3Mw12a8t3DzHR2Gyl+CwNd1avffhRAtpa GZ4ZuFXwTFdgroIMntnbfwg8g93k8Iz5aBl4ZuO+eAYG9GjxjBcsEc/oiVo8Y/FMrtZqRx/ct3iG P4TFMzM7eSJ45mC/vfXqVafT6W5ttdsHB6uPZ0qN9YF7UQHPbAool8UzH/Z/oY2xVDiDveTgjPno /gb5MEFj/P11NDAqR5naHxzQLOQ7UGQJ1v0mobgOoy9K7deNN9jzmzYeaxARGsW3cFpqa3VZS11C lSpGvlgqrb/xpPd3t08+Jektrmfqjhn5S0PzsXVwtIgGfx4LogHqVfzOIhqLaFYX0QBbKtHQdA7e vXy5v7+/9+4dNNwWTxjSxH0nqIBptgQWzIKapWVbhZY/BZ8/RZ+n7sbE0+/ouR/3OvkH7cyDUb7E KF8inmoknmolnmomNtu5P8bC+f0NNs/foGsEW/cDWthaIcwiHKe9nNCTTXlENkWcANFBIKMThR2d vWuyc5rhIwkUi+9nkNcedCydY1mXkzpMKsdhFYJuWFszBuRpxU1TqXUo+Fks/uFGYZNtqdeezEWK XfyhLdgOG5BHWJwOpLOYDmpqtTDTmUprRo50PXLkAzQmu5djhoV4Rh5sGvzJscVNdPREHzY8G7GL V2D0KvtOrFrEpTbN1HLYsPVxC5LTqkcBTICeOux8LI8FnYS0bHtWWS4Mp118hd3Dk/oq+8ccEVQj XlV3KO6FGzeWsY3UCo/mfI3oa67wjPV9vyrn01jY2Vv3q67szL273LV9+L1bs76qVlzkn0eTh3l3 50PxSysvWnkxIy/KVpYVHCOYHc7iA+khaaAUqWlmozpGRjS70XdesnFqgEbVsrktU3E2npZnlyPN sjAzLcu+lvIf48eiEh1dYlTSxlbbLFLYyGZBuIzairsx1FIpuQ/froKU/FxgwayUvBu+P0ENNWKQ I7xmuVQbAPU3HVUinnp+R0kVR467uiA2OTvAugldMyPQWI6HnH4fZgoT0HfsGPXIvIoZspF6E3t5 X2IyEIDEFYSZCAFkLpC3pQasb0+yLQ0dGgZZErThAAAaBpejO7Ac1lp9pwvKuBOheCfTJV474wJ0 SVMPUqoioRygxN33J0f77FzBDXsxz+4K6Mygtkb+yNiVTucjo8bVkQou9JmmQ3XnsDFA4x8S9Kyg uBHY6eH+/r4Y+qFD2HccegHfbuW7eemAaWHJcEFjbFhnC4s1+eexYE08Z8UvbeQFizen8OZd7RNl 1okCOFcrvBrFf57L381iQFcQaEFWeCl/OxI8KBMGsvnyIGaZP9oxw6gGdTol1dDuwX90NcYUFbpq t2vZy1urbSLBebsV0N8LQn/uHPiHB2wfA5kvHQe6ZUDQtUjwnkgQAFvE4eeb4j6QMI8IabwECcWK IkKrfbSIkH4eEyLcL35rIaGFhN83JORTheiO/1SEhAeZP98PJKzNBoXzMyNutl4SKPTmgULK2/Yw qRK5fzMfosigQ+++6PDMG3mApXzK+4bkt8nTwYwsakZm9Kc0GhKCiA2VvKHRrK31vw7QLFTKPRkE VnvkGMzmu5v/s/oYzCa8sxDsAazAFVyGl4vAqO0MuvLgS0DtrebcSEYGwGJOW63aUwFLtZwOrQpe esVKtLmASWnRHho5ucVppmP5btnQad9iJ6u9ssjpu0ZO+xY6Wej0NKGTOws7Ke3SgfyTwU7u9wae 0vxGvbgCbnotoFwWNO28O8MUmjK8y1KREfaVA0Tmo3tfi6obd88p3ub7s3foU//27SpdRdcXAKAy OfLXYRoNneg3cy+AoYoMWI8oBQfqXbkNLMrWT46TA+/wZgL0L3pO/wuFH2WEJsEbNNZEouf6MWx3 tn86Pqb0vJUXB2Srxs2DPp4N3//a1+ft3fklPbbmyMcK6IAIF7+zdyEslMtAuZW6Ow/cvuzufPv5 y5dGY6t/L6AUmY2cmyrhmtsYCTgLzd7v/Iah9JaKybCTAgew/ON7Y7NoE3d4HT/4G/xHg5GGjIC4 EH6o4ldmXMNUAZUlfsIaUss0fReztqYA0V2VVpwvpEj3hIlG5iufrGuUxSL883gSl/9W/M46Rlk8 sjQ88nV0S4s7RgH3mOcqr6pupvcdkXtWqpLFOKuObLwqQYE6HYwJnEM2hx+Wj2wwaV8Bssk9Xiay 2f7KyEaGVl4RZFOzQScstuGfR4NtDhePOWGxjcU2TwTbeME8bKP6NMI9IP+sUmUlsU1tpt6miitS p0sah0LNzQN5HFF/hf5GBW/ujXewOUOXQ/+02pyngnmss9D8n5XX51hXIYt5Hp2rUBFyqQJ5Mrqa 1FNoLj7ZMtU1XtVaTw7VeEElVLNJ2oYipQ0gAHf0AKAGuivR3zwspNn+6pDGqnEspCn8sZCmshrH QhoLaZ4ipAHeMB/SbKk2TS3NXEij/mzVnhakicMoqQJptgSWzCpqzo5Pz5cKY6iLAhgz9fw+IOZ/ tSUK2/pRZhX9Z6FdSpXtGmU3xT8fH8ChVkyVDxQuunf2Y2cBKFRbq4aFKl0Uk9GnjMrk9y2n+ebd djfqXr959m4bWxlZ+9djA07Zn+8y6DqQu+KX1gBmkdMUcnpqBjBkwpUtYMgvt2b7/TBTr2QcK22N z8hKozGAXdul6Ox4nBx9OJP4jBHZJiGyLXFMaZUcXxyFF8DJk8uR1xcf+M7PGX3kdMfyrbXN7eqX jmBjQvV+CBiCblyp3ODE4p1AuFewPBgbIJ6Mx/ghJR8vHUxtrf7mcBsm8+bZ4XYDbywdbOyefBQY 1d/T6aEIJ4WAkUaYwQXvIcnmDxSgOCFAkc4MgMKHkAJBOpw0CrpQl5soZ1R/EkUwVoA2eMXJvem7 MIvNLiWXEr1JwpiGSl46wYUrL1PV1jiTOsMlShHT6QgVHUAvBxQeAfnS16oMeMONKmiEc6Gs67d4 l0yOlS60ESjSQ4flHcpIm7C6tJWTdJjyohaQEkzu7g1Ucvbi3eMDi5iL7bdaHYEFs9D+CIa/s7dH KXCWCvGpqwKIP/X8/q5mXfEj+Zuli8vLab3GLbLkn8eCLI/gqBW/tMhSIctZnVpgqY6q/K2qlTPR 0kIQCakp/ROvkQtPXTp2B40SuDQJvgThdVAOl2SBeW7TfjzpVeBpXYEFp3na2cd3HMl6uUwN+ypi avnny2BqG5apWaY24+fRMDU4a8UvLVOzTO17ZGp5tpYytS7IjxW42qagktNsDaTLww/nqMyR8vRy 2Rt1mudtmYf3YWy4XTCfxJXju/jNwiGyuSkOp+wfStS2fK/iKC3fm/HzAHyvC0ex+K0NSGKZXkWm J3+AnwT4CcUoHLhPhe8ZnA+IeXd+2k/kfFQyy/mQ5QFTQAb4QJyPO81xvuzDB+N8WT6nuJ+V+Czn e6ycD85jd/FUkZbzWc5XJO4pG9tT4Xpo6J16pvjg2aU3TE5DFAJ/7QLP64p3MLKzy8lw6CP77zlo RMwZdLvb/L1LW90NI5danrIgd1sdgW8FvSbvMehdR0LPGo1L24+x8jz2DV1BZ1w05z/46+HBuThy YQB+eOH1l5ywUXZZ5E84/WYZmtl/85Of8X/QcOq/Vq0tNDJz8FHEAJt4ipIIqAZ8kYFi/TKgJxQg vha47gBe9m7pJfl20HZxIwqtauGBhQf882j85/C421TSFiN8W5XwXb3Csgx5mZ5h787KHPWznDaq wGm7zGmjIk57ikf14VhtVMpqo+Wz2j+86P5M/4GmHwunpS9h2a1lt7LWI2C3p8WvLbu1DuuW387U TDPjciqw3E3Jcp1ynrtDPtFu4vUfgO065XzXeVjGS3qDsVTUyF19ESya4MLkx10r+VpWXFTrCbDi neL3lhdbXmx58QzZNwor6Zi3BBbM8uDT43NedVQyL5X1Ul8FfHfq+TKY7pt/v5+Ua7mq5aqFtVaa q8Lhttpky1IfK0v95gy1VLQFHhVVYKjPkaFGJQyV5Nplc9RCDfLU82Vw1H/fthzVctRZP98pR7UK Y8tRLUddlKMejxPTz2oqpIdyuuqmYTuW4Hg1LxZtl9y8ZNlS16uHCbOvei2MtF/8cqkuWNj03fk7 x7j97ji8Df46/+cp+GDZ+K+Wx3/l+K9PxAOrCstVLliFLJftwZrnsjfWAxiFZ3HeqZdLNgxb3mt5 7zTftLyXrMCW91rea3nvXXivU4X5amesGdw39cZ6SOEXhzCDB0+9fQAmXOyfZVmzZc2ZH8uapYOW 5c2WN1vevLh3VhXGzO5ZOa5M5mT3IfXQ3GkhHy56tSwd9L9bIdhy2ukfy2nRacuyWctmV4/Nfmsu W0n3zD5bxVw2p3peuvNWOZt9EIXzv1tls+Wzls8WfRnpymX5rOWzVpyt5MllsFogVOG4Aqt9Iahk ltXGMGTo7N3huTg+kZ9gqYyW+vx08yx+1n+WfC7wl4YxlJeh973+5cX0Q9hKBSX9aPphEk+XjAsb jQtbjQubjQvbXQJUOKgrcslNd8SbN9BPYyHQcMgxOUl170ZN4UAzcLL43wPhowIj2hSJN3I5o2c/ HPU8TCd+7SWXXNfth8FA5f0U9agLh8zp92FH4D6XuEOT9gMxoCMN3MD1w2sk9bwB+dBua4hxb/qq yaHEPCVM5Yjjxoi5zEeTntICmFeMJlQ6pnZJVMjjEv9kohmKGOZf0i4E8k3nIp7Zbaf4+c6HvQ/l He/6rhOVdI1bXXXdr0Lo889/mzXlXUpZVtY1nEjV9U0V8l8w6/Ku3zvxl5KO8SCrjhM8w4nTY2CQ Ji6Uu7na6ctA9geKjld75JDd3r6oUGulITuAhuOT4rf2+oXF7CVEuxpmL2+mm97iuGmKflMQ7VbL 3m5v6I4OarOxv8xTWzVN7StG4tkctAcH7eevXne6nc2t5+1Ou12cvJY6VIlpGXkW5pHNtAZ/JPbv MSKoUKdj1iHUumA/hGln5biVeWx1Hcxmq86iuvayumJVVqiqosB8ybDBmy9WPZAmMys8keLyxVwZ K1dMi1mFz2HvFZf3o8LnsIeKnsdlHcRlPcRlXcRlfTyU+IU9LV8Aw1ZXVAR7mkKXl0pd3syOH0Ls Sjvvz+z8QQSvtPOb2Z0vX/RKu06w6yLh666iFx0way2Rj0ug9ZORyEwjyncrjy1uQzkofoxnp/iN FdOsmPaYxLRlCGQeSXgLy2QVq+XFsrv0RpyyrNqTFM5qZc4lFL0A+17n0AWcKsYsKcMXbKbhC7ID LohdwNVn/5fhxfTcEUjgUTvY2D35KPoO7Dg/DnE6uNAihHeR2WcCaAxOPmzr29pahOEUaFARiwf4 d2ScLXEI3HM8iYDQuARjQtEnHEedwVOPPovsHKs0a2vXl17/kvv3gr4/GQAlwK2PAkTvNnFF5FLm OegEHxFBACL8JbssrRnLD61BG3Nl481WR3DRrGyMQvHp/p9hDEsXhLGvIgsjvwqNd7VliIrQ7N94 NV0UzcT2tqgjPd9Aax1t4RA1MD+SA1BH/F9Rn1lFSLq0iJh5SoGdhl4UJ9j2hmx7gDsi0NImYQhm NRva7LdY2OND3mQboRgCQyNR1k1gu+HDyI0nfoLPtAgLUNoRx6epKIskGsg2GURgX7hDTObkUaXr yEvgnejBLsQ9jivWwqMG74CoA3jvK/Y1iRnD9/k7wBnArIOA0scDBz8L0PreBBqLhv6tgEeO4OoT GCKdDRd6lQaZS7rM3FXHh1ZH/V1Vwu2iCvcnUYQz8IKBe6OSHuqStbW64187tziGoRt58OVhnN3/ xu+K5yzqqHYwNZYaOB5xfO6IN++2N6PO9Ztn77Yzk0YCAjJ/QF804mULJVG7T+DqpRil4DC7fWcS qy/pwL4CKJDo7wJMxhtPfIfVKdgI0Ru1hTCRGX7SlvgLbleH1wbON3wugArqg8Naw/b5u4Jqek/J zQgNO1/g+ziwNDAPQiLpSsvW6A0QmUkwiBygujBIEMfh1Oh8ljplpbkTsntI1P8+iRMaDzZ9G07E NXyU4Acgr9fQfaNFih96SQPQe7EHywbrIedMQ3QHTYGcAqgZTWuETfdcxTVwIfmrM/8nEoYkLbM9 VCW5ToBuHFhN/NTUx0geORwMgELggzQhGIYbxDChAdDGW+F7I4+4Dhbj7f0TbjzhMvRC7VX3+YsN Yh9yJvQRNruEqq6BdANJxJWMCNZi+k8ctzwqwIDc5NqFL9ymOb0AMhyHxqC64ujsncDvJ89QH1Ul sC9WTPC2Ns8KtVZdxgbsUvzaGj1XUpoGLpLtOydOA4oxQI5mPoCrgWYSZ5vZzTKjzmlRuJrBUtSn 6HajyIi5BSWnEI4quTlbumY2RyzBZLd5EVti82LL4m4q5Sqgniu4VSRT7z4JKXeWCRLWYr4NcrPV lXLWNzVCUv9FFyqU+OWFy75UUSpMYT8LS2BUSSxm5ctgans3414Q6fGbFRaBObk2ngDosbczLOip DHpkM8tDPHnlf4Hq/2vBmBlq+DySAZ43XfYJg5ksnEmhDADQKirjbqvTFrJwTmn813P3YbTGsrcs Zonzj++CVUhVz0fUDQBzBQHqoTgaPwU6miSxecq8gJSfKhV7tV52fJ/aIJ0+2hYypoiRc0sKp3gy HodRIgYTx98wBsNazNraUegMnp0lqFxECNIkWwTZJ5jChMME9VvUntTzCNLwofbGMGyEQ9QIAwb6 AocP9VCowo21wpKUStjgyAu8Efyb7XFxEzVlSCZQjzWc+Kg5Qh3vCAbTZ9yqhtASp+7Iib401T4B KnrpoFoN64qfNuSRXRHwVKIUeF38+HGCJ81UOp07tyZ/Vhwn/RW23B20QyUOXdVB0qpApHsjJLP7 bYRGZACohHju6TRRjlNSlBJLmDILpExBj2IHBeCmKeqQhG4gpiDHtMdAJ0UgstrvVG3LRB9GNayy 9byzqavFM7oDLPP84KDTffUaq2R6i2d0177BKlg119s9wM43hDozTOMj76aCvmYT+N9NFt+8P/xt qbAGOvBzl1Ph0WXeOn4XXPMexp5ch8B1/Ss3lsZEMnFWgjVqrYbexSRyX2+zUKM//+H7X8TZ6S4t ZevCG8Jy0scRbw6OP5zDUfzP/bcbnW34VtyAeC2/1J4b9yNvbHpE4CobxjIcwTNsxdhFKWqtOv09 d4wACr0l2MoIq31Jdjlpi7xEu/K1S9coL4F3wN9QnsstlAJQvuuAGNRiVVLGBh1OIjgA/ctJ8IVA 1AClu5GyrmvBD3uNFdRKJ6usp4CmUA2V9iWtdUR01rWBcl0MnfiS1i6SHiIgBAnfSxIfYV8Sweeo rR1rWAgnDP1clOkRbfKRi1Fb4KF7A2cMVVzs/TI0dwP8yzR6kmTZd6LoVu8Pa+uztr5HAeeAJi8M 5b4zQ9+sTh8M0G0szUdVlt7wcWwbl7mxtUlc3fCReXb475fy1a+wieaPdNl2v7jqVUX0Ae22N9tb 7eftF+2XpRAzD07br9qv2zvtd+3d9l57v30gIYnEoYgpEBUWG/GwL6wG/VFVBQwRdqS1criQRoqd 4mih49XHheNCXOjejIHxV4CGW4KLZtHh/m8nOx/2lgoQuZs8RuSnS4OJErxUg4g5TFkCGDvtUsTI g68EGjvtctQoP0AV4LgAbFSqMJ4146tUyJRd83HJO3m1HivotHjN4rXx48FrTCWLX1vItmTIJuS/ LGZ7fJhNIzbJ5OETloC219DpO+h0Dzo9aL/UoE3igLRiHre9gvHuwHh3Ybz77RdPxXhZjN7iwWR+ gL3N1nOBBbPI7cwbDcTexxNf2rGWiuGou3vCtL3JmMbmxgaI0NBBw7UsWmN0lgcPhnMAu/lbGGFh RPVajya3ChzX4pcPacKzAGIegHjcnDmjKUHCrHinYpxdZpwvs/+X2s+wCqtJ8kwaNSrG/7JVfqcq efYsh6p+nwR7zpncfp1+VktZ9nv4eBSLZl1dD8YqXeDUm4Ke568Ad7P1d8PIna6Pt4rxWiu+LW5m M9uMbzRRBh2gQWiSSmaxA2yvay+Gjo5/OdxdKnCgzlo38Ad3D0OIzdRfm3ym9WP5KJh6xtcap55N F7wpaDAofBgmBc8KyuW6NoEP74fZ/zUdyfGQDet0VBuCL4gO+UomfxLNMa4v8Rp2Ek3QFxJj1JCJ TUVckvdBTUTzcZtdleTO/u34VMSX4cQfZKxmMBC6uHgdSj/xmK/e/T4BGpjcNtWtPkRZ8aRnzWQW L/HPY8FLRJ4WBkzL1LosDpnKxpqCnmnEUwx3sNyn3we9zxksE5dW6bSpRrtDFYb1drPdKC/cyRbu zCzczbfcmVF4M99yp2Gsai70FrAMIEnIIJAwYnQLz2EypZlJu9NhIVShEyTRs2ug+5BZ46ZCH+1M DeQXM2t02lM15vTRwaArmRpzJ9LJDmtsUOclwavT45PuPVGVlN2z4ArbrRBsxQRCRSiGYVE3DbZS Co1K8Rqt5Ly7bpvoIM5s2ZsBlR7ojhv3y6jJuMhm4CbYKV72lcZERc/DqOjpzdTj+1+UG9apwWUj nKqDUUEiEuobmvTR9zwKw5GgSDiy5ci98ADqRBm3IcMOJqONZAcdk1UrcgeTPgOqrZY4FJfo6NTH 6QT4THYuYmcEc5pqQPnBywQZRpdxS/zVTQoiV/SjCWyVWzHyYrxmKbVheiX7BPNGzi0gvR5OggLx 6DUMKbjlaim+bAqm+T9PAMh901t+qwXkNiQ8u0n6MdXKEhacXVksUwJUnpiJK7xWnAdU3pwKSR5P zatwk+8hmFejv/JIpxSDDP1wHGsIUhhSbksc+CFHazvBEEfieBrjcKXZ/62tHQcuOdCiN61LYXoc eWeLXGIHHt5FxMcD9yJy2SdmqPqm8EqG+4i83kWam3XfvXL9eL2JfA2ZDV43j1UsIZG4/csgxI8J bQ68fgLLywGDDk4EVRVt5afi9IB/9oFjQt/w9tKJBngFq6kb4/LA3SLXid1Y9agKwpiHqM8Yobps 6DoUhktfb5cn4r76bknfJFU8NGIj/Zc4ovGpJS+iQyV6+5IoxyXEbHPGuIYwJ0neiyv/cdHH5V3F k97X6mqEl/S+Slew07vDZ8Mu/H6tyXnOOLppimH8e5TQ379WxwPvSnab6XHhjst7gINf1HR5D+VN uTfjZTU1cvrLagqOW/4YzG9NSVj63haSqGp0PEM58XKDQBqe6nkjVN1K2O/Ecdj3KDLI2diFv/ni VMk8MiKikyTuaIxEHoSdULjEI6mHjFQyxcNy/ErztIMTGllnfVuzMBChmS52KjCzcmYJCz1HXN8i wwYWzArrB1k2trO35y3dNYJ6LUw2mH9DT/HhzdTTeOrx/UXxqCt+RKMDbInD/f39jZfPt8gGAFAL 1oLwk4wAU611NVec4ZgBGEr2GiromzZSnkY7g/TylGklAOLWYWgwqm6jxDs349ohq2GtzQZDBwOJ 6I2fTkpHj9ATVtPkZXzz8Qg/nu9tU2No2UT4jTNicRuAr/JQcRJROOMEb7ELY7Z84q4vQz+dKFqj EZPiW0c7uSSXaYkWNkKuuql/CvmvaDg2jEhrwY60F26UFvyJ24YFxkYoKhArJ2Q8CngHBMDDwI+i 3u40CFi/2OKYQLju9XabH252Of5vdlFI/7DIouAwgE8nHgbQMFcGZx7nps4hMAx3ntjlctiKoQWS 7jv5jxQ3cqPdv+m77FZdMGRvmBkwbxrs6MINcCehE7asHov6NcYG5aBJDbq3RglQSMyQAZbUxsIm 4gRmAwBUxhSlaARKa4MhazFSgG4dH6o+B2m8TWGEtO2BDMSaGxOt027fGJBbNm6La+dWht1kzMyL 6NHqUe91WDhYQwdabcAYQdKgkY+9sevDwopJkHgcyQFovatFI4zGgM4IQ09+UPradMdOTSE9cgkw QdiSGFi0l6rcpFgxCN0YA5XqKdCHHY0jYESxueDk7Q5HMiPe1ayZ0ZoZF6i1fO3UAeCE4pfWt3vR EFSf/vSnz3nH6bb4ScXzPThB/NPuwBPp5XQgPeJWI3XFxs1UcCtgFPEXbyxVIHGiVg45h4Yq/QqO aN27OqLl3NBSfZgJqkF0qQCquwILzgTVZx/fgbjg9JcPrLHnYmCde8PAGh4WAev846UA641lA2uc URmwhnd6heeC641VAtdTs5aYyLiu9h2i6/yq1Ex0nd0Mjwdhq0FbhG0RtkXYi2Dl7xFhA2gofmkR tkXYK4CwMzZm/s5Tamtg2RUQ9qbAgjMR9vuPR8j7H+JeH/VdjLFzbxhjw8MijJ1/vBSMfbNsjI0z KsPYEl+pGKDzUPbNKqHsqXlblF2wKjUTZee3w+PB2WrYFmdbnG1x9iKI+XvE2QAdil9anG1x9hPR ZKO/VgWgDUAKS85E2jDjww/nBFSAf8hA98sF3DSGabRtPmaojU9ucjg78+wuIPt//ofa+OEHOb8k A4J5EWQOIYy9oVyGMDUpBk5zMNirRHJcrCmRBVaXwGIUDiQWbOqYHl6Sba+j4azllZZXylrfmFd2 4egXv53BLL+jaByWUVIrX4lRqim5eK3LD6/lv08xrTApLIDKxrN4JTcqEwNkav3EHE0WuMvOKxg7 bZmpEYrS8m26nfwBk+/GiahrMa+8Al2BOQ+vHQwq3i4vyPeeVcEND+RAEAhvZ1TItPyjWWHKXbdM 20e+4xVQyHNBJbMoRGEO2Ec5QPJAKITHMIVCMo/pET3JoZDss7uhEGojg0ICrSKahT/yWKW2Jks/ GaBhLz/O/1ltoAGnvXtQ/NYCDQs0lgg05mGDrBxN94/WZ7OvF4KLEZ9DDlYgRB8GHHN652R8Gv7m jdhqdWLuvfuL0TSKHAfjh3mZOVMSnsW5YndhYHoE2LVwxuMovMGJyi3lyRXguJb1N4fbnWdR982z w+1Gat+5dP2xwCx2Dt9i9CJ3IPww/DIZc0iEEvMSp7hhs0tmZ2GcJ2iNA2j2gAMGAX4Uuin0wb1O wmDj1BlfxmjO8S/CCAYyUnGh8OaPIwbelYdYQ2rl+/1J5PRv6VImtpkZHKvxY2U6gjVQ1pL00maa jfjDKXBmOVYYox+H+QYAl9IKqF51I4Z5BdX83KbNXGy5Ov88GvXB4c7J6W/Fry1bt2z9m7F1fbV4 Dmt/adxCnsXez/7PBM30p2F4/nVYvR5VJXY/VZpYvn56b7ZvrNEc1k+78HdarCgMZZTr2hrDgTfD EN0jnL77Nr4d9UJ/+/+9eYbPtlcBKBjTsljBYgX1Y7FCVffX/3N6bvGCxQuPCC/MCevQNcM6dGVY h+69wjqAtDkTkmAERiw0C4zsSYl12ZgDui1wi8XHRe6vudKEOPJF74o3sO0yp1Ulr89xV90UzxZ0 VxX1qMPeqsDQC9xVp11yrT3f2vP559Ew2b3DPxe/tL5vlsUumcWW97E03zeTWWeE+zlMtMtyfUWR /iGE9yJOis8LWGm+OLLSqaL3Ed1LeSmvRE5ep12bYagsv8+X3ufzWslZTWZbeDVk9XmtFWjn/zwB gbb4rZVlLaN9ZLLspinLbkpZdvNesqwfXsxkw5jKCQvN4sJHx784pGtdNg+GfotYMDwuEmZzpUmY zRe9//1OXIt40tvGpAP4WwcBdcX0tFaErFBrtdkaHMnil1aEtJztiYiQ81kXSJDuzXgW69r/7QTG FSSe4y+beUHPRcwLHhcxr1xpYl75ovdnXrgalnlZ5lX482iYFxzK4peWeVnm9USY18jpz2FeGF/H 6c9iXu851gd7kezs9iejiY8Z3ZbMyGAURYwMHhcwslxh5GP5gvdnYxSKvS5UqB3Fwqo1paa0lIA6 PALWmsL6ZbSmSVhiody0FkrLoWWtFY3OsfNts9laDm059ENzaIey5Mxh0ltClpvFp1X2FuISmajT S+bUPJQiZs1vStK3TAeljosqLIFvb1IKFVqHqPOjfISBnxfm4HLY5MvsIf+Gh92oe80PjAxnFEJL 8/lemFzmTKe1NVxO/X3KYlbr4HJmYD8Z4c5yZ8udH1cWCBum1jLoJ8qgTfvodApSxb5H7iiMbpF7 d4FVPxfv6d9ip9/HvNp6rdhE2qXwF1Otq7Z2w8iF+jJIBgMAtME+b3UEvpvd+OZUw8YwgRMNOnOi bzynHHFYMht84+h4Zw8YH88Ub56MVKwJHUWCxdK/T2K+MrMfDODLwZ6JqYnlZX2HoWUBBz5y7wMc ThTHZr01DbzuNmGyn6Lu58ZiydVppYZu0r+Up9FcMwIBnBe9d0tD7l86wYUro826es2mA4bxOzoH zULHKeWJhZkMhx5eXiI6oK44LTQJug5lIhtMjSuDgBJCMaOoAkihr4ojGLiUe5YAT+ThrSjKODzx 8Sv6Hn7BHTy4lGGXgtkQiPpJYP7dMOLUtEdn79RseMEiinkL1IgdwNJbUBj6FiYLowNChdWunAgT 6eprYTqSrsypqwOWiiBMgIb44bWYBERL4LPIT+XQ2XJVsFwY84lz4WaGi435oVTbAN3EQL59DmKL YVi4+ZEzHqdJ5mki0JU4P3rXBCAob2Mdn4kv8Nz1xQiPzmQ8wCi1XgIfeYgzh33U/4LriVF84VBE uDsi3DQYD9gbYAweOnpMEIh1c6RVWHQF+mEGOEjYlDx+zrxcbS8c8vD7Toyxj2Gi9E9T26RJAMw7 anO83w8fj470iwbGxg3S+L+w09P9Q66Ejhe7A3kNz9x3eC4FEW3KZkzQe2xOxShcWyP8jS3E8QQW PnavgDr6nHY6Vik9cXQAuSfwQn84rCRxOw/DFaqX2hqNAf45xihM5pG+9KD5qH952+S9GoWJy8Me uXiuvXjEUZhhn2W2QG3t0hsM3EAGg6YvGwgYbUDD0ovDI8Eti+dPRd1NvBHeSEyuXTeQHauhqk0l 50dPkYDI0XNpvZcFjHHgS9JdNC8gISELNVONXnswp0vnCh77I+DpGPzY59TgTdwmAa49Votclpm4 R5gpnIwWcV0rxVgpRtX6tlIM8uzil9YxcxHx5femaA3wjLd6OaAvhyH/dYaH8GAeoleofcPNi0TA gH0vSXyFihAFolDU8y7kE1mSQej8rjqp8LDRFq2W2Hg5JYbR846WZbQsgdQbyeNZAshnJH5FLRye 3/RDI60DDsz8haSZ+sFum0L7IzhCGKuC9jJW/ri9r+O0f8Q47VDo47Y4AqD77CxBJoZPmYlD4SOm u7JUV/E7KasxWAcS7GPu61sFRySt700wC0ETQNAAhcURhuKvrdV7k4SwWEOESMOvgT23dH/nl1E4 ubjESHLcZccQCMeIWXAA9Lejs4+iPnadL43pHNlKLolxRlUEk66golnJpFDkYO3n+fHpvomQvUDO eqkSCY8pK5LQs+XIJFIKMQUTvAmxEJznleCVig1pgpYKIy50puWN/VTeYF0lTknKKbSlJEJX6RuI sUJdXmFAr/xNNEjOiz5WIDn/fgWSqh8dlv7ZGZNAFbACCCd+e4nWeU3pBKYkiBY7xaOaQsMn9iLY vjo1xjXn8UgxKh5aejNFJN2oJQ6HsjBB6RD2+gSQMAbdgOWorWU+FnyD3yeoz5KygeqS1vTagQnJ AwIbNKRzFyf0TXFRs8S5tkY18eC4NMQBGwEsgrYI+rEgaOIwxW8thLYQmvtcGQhNyioJnzOkWFw6 mk/Efph8E9w8bYgw7AfH46TYfNAVx4SPgN/fz4TQnYvUu3c0ITSL7QeEJiQMMSDYA5gVpnwZpGnh fn4JGsr/VGJgqK6NrfJfgHuUGfBHGPfjs1wsaLVgjbCM7o4aUGnhdEYI+PoYPN/hR30806ogHkPO rwc0RCaWizYNm+j1pQfQbeR8QTk5KXfpANAXCO2zwROqrZl9Nacbl9HjsLixbeGTKOEBRsT7EF/g MaDKvu/6tTUtKcjV18ezJT6E1BTquIfYYz8ErgODFe3m1BKAkBbLbG8wkp/oPSmSEb3ziv3DjUKV ggan7MIRgM+h8T1/Janaz0aJq7ahrNBmrUhqL1grkrUiTTe6BCvSYuqEngu9eeEkypMGeWLCnnsb K8YVU0ZLGBXfOHcTrw9bcwKPkBYDE0omKgCn+eX1Qqi2aZbXkTOGhjDvS6qIXIye7tBRpkVUHMns V3Ii5qvUZ89FF8MR4HzmRvh+DwiHqO85iQOixJUX0ddQFOEcSELs83k8CsMvQIOBw74j7Nug6KZI RzReVxPUJARzmQ6uEJ/Dx9mJRRyipyNv9/HlbQw0Nu0Mxv4lCK8Dve+R9EDLuEspoKnakUwqcMTe sLYWuFjOQR0jnlAkao7cTv1wNKLFDyWxgeEKpfy5kYRTrrwmSYQl8DQUjYPny5vhgnw0Od0ysyo+ EwOvT7plwhS1tYEXucod1GA9vCx8ks2DlJEvWlapY5U6q20WtZ6dVq/zzfU6fEtxAI8mPXrQ+trG UkZ/WXCRkLiZXKL2SHZb74qds48gq3eIMTce1shaRXVT3cjanGFh/Ro6m29ieH04Xc0TMOlOa2tQ mlpIXSOqaGtIFt2MOpXUNaKytqa2tqi6RlTR1sDizlXXiEW0NZhx0KprrLpmtrqm6ke3NvZiG/vC y2h1C19Pt/AYZfeadcmw0rt1ybCiuxXdrei+RNEdnRC8CpL7JjldeA/rdSEN1LD9DkeACzx8zdB8 6f4YHnbxqsglw1ueT8bX9cjACa2+T8buBKS8SeyTxZIMpWxS7RQ6UOBpwnlLC06MrV0EG2iPgbM4 YEnCEQE0f4kkJhWdUkn0GkYvtQBkGZK23BTDoUgsCxRjuFEIFaw8jDWt+4J1X8DRWfcF675gVQyl KoZVd19InSVR+9Fj9R4x4of0X1hkQ7xz+84kTQNMyFD9w9PoEleumR4iOGJRGFKqXQYobC+IWU65 VHIKLhCRQapINM+B5cb9rc9yula03dahQNjHPtfNJiWjVdy0tqaWRFN8aDD4QsfOEZKmxQmcrpiZ 7gpphWwSovk/q+/TcVj8doZWCMlG8RurGFpFxZAsn/05y/EJq+r5Nl4aVXQ9W2yQyyl7luWmIWVy 2FYPquSRUyjw4PBW0YUDz8zqO3HgW/KhiOnrv1L9yq2hxNNY3ZkpcsLAU2VVPlblIz9qYl0grAuE 1U98exeIr6QEqJmOEFbgtQJv9VoP5AbxbSReEyxbaddKu9+ptEsSbnk8iWGJuJsKu8/JsWFoyrpZ iVk3oWq8YLBWXIU8CKaqvGTviRm9TNd5JaXwTKV7ycdKOq6tSSeIYS4qhTrz9C7jBkE5NpRUXVaN XxbWk9Mv786b0V9pRfn23g4b52gyNUWzmA6kvDYAeDVkkB7gmfXlZQO6TYA2V5KWpawohaDa2jAV POn90HP9gaijBOMGuM/J0NCQEi/M9IAmRmUJx5OxQYG1MOhfemMNz+PbGI5tU1AfQyC7hJuwIJp1 GIjDwXEvbltp0yMX8CH905/EZNolUAdwDPGkMuz2JxFIXQlMvueywEmQz8V0X3QpACBxhKA0aCiJ LAA0T8j5FmmCbFSJhMEPXACR4BfXBRgt+uH4Vs5ITl/NGodI6cYAMk76rp4RCzRofY6cmOan7Z9A 32OvBwfCIWxOgjJXdOHbwce8SokZFKGzsRhyf480FvBoH6icLw3RsQu0G0QKlEk8khiMWfwk1kko YvWEWh6YsLvO8yWRAz+Ue0WSLAF1rIKLBptqBMLU8FZdu4Avlv+q9D2lnsNcnwsQASY+Sjzw4d/d opoGxeumFhKnN1rIEoaclmwfXvDsf+KDWG2hNvgD00fjXVQih8KZWqxdPXxqz70ZgwABQukQNzIe AikeaWUArckSusChU1vTfeVMprSj/qLaONDLS5d/ULLimEWaofF6X1+GvrnDSZsVuUnEO4PoTq4j 1X9WKEKxXp0E+SknIMK7GaFeq1bqMA0U4HpSLwt7G7ZowL4D0J/IVYClHrhaRSDFNuX2nkyxfSIM ehYtoZcF7yhRN0M+MLELTwZCelb03Au8v8QqAlw36QCG2gImbkMvinlPNSW9ZRNsoCPipCZxqBoB VFFTYHiCSrbMwlFjMQ3MCyYudziGaW6MQ7Sdx7AG/CuPh+uM4JghlVdtZr6eAITiREA812m/uIN1 un4mCaUknECIQG7WegScOZuqPV2SKICHSpIFNvFftH6OYKHBznhLpGgqJczsLuDBiBWRps9AxKW2 pnwHaCNKrQer/HiDxw4qXJTFW62BnLpUnPq3+SOjN6Rx0ewiNLTQ2XN8J3ULDjLVF9HhJpTBnUTt VJmppuLS4ptAl6eqSD2czEGIi3YBgwwvXKgbEQe+Vgkv17VPRhyO4D0TcEfqc/Czyo3NSsj1VquF A3WSH2IYIbLfHwYwZXQWuHbihBUvwDLOQtSrwTJOgoD1ZjzLvH2HVms0qmDgeS1k2Sy03N3Z/XVf BXB77wTOhYsq5aWaZVTH90rFFiRR6MfSV84RPTjlX0hRjiwXiFgGyeGpxE61zjjvg8XfmRrRVGiu IUPpCUktJMkgjwP6S/cQlb5vfhSZUxWg2BUiBXRUCzy82wlH5Nqh89XnNWEyK9GCdpEDmq0UzwAw nH4/CtFtV7rMoXYfdrg8yCNoDzXsTsTLYo4D3zERQUSKN2XJ043UgZoIGhikSZwvEKSKxZ0kqQ/x EmQEMPhpj0RWyE4iF/MBZ2EwDl+PEg0b8IPnKkHVJ5Jz2gDKcY/Ru4tWDMXQgCHBvqlzKj3pcwXd uDderDznFox+nV8jctBibafrIY3QLpnEfbTqM1YuohuC8DigRvVBaBJAS2JcIrln5chNn0T6lkpb rS8co9JUEmDAyyFuZHIeJM5GrZD+m8EpN6SMeXr7+u5Qd+z0wivVfUuNWLm6ojYFqGqcDrvnIsM0 aLlsNMCBAG+UBmRqT3fsxLiT5AwWW/7D9EY2M7mjLPSCUWgJid+fwhZC9ZapouaBMO8ZjcMoQcVM ak0y3MhoOi3ohaWp9SP45zrLHnCCnF5MHU0CLGYsi5Yg+QssvMN2pTM9MbJ4MsYxEkAiwxyd/9GY rADpmlNZhhRyQzRxi6OthsuiSdcsRfEooZAULAaotneQ6F060eAaNtbi45aeagrwZQ6KYpskVtIC OeIMne6Aqp1K77dWATX0KAjArf5STB7kCR9prsV5rNJ01LQdcLaw11j7hrv07P0uLsre+x2zlX54 SbZHyRqOz1K/S1paXOSRAzsI7TGJA6A7TndLH0gf+XKykkD592LRyB37Tp+GpzEYy7SacLuk0Voh I8dito9Vv+uZ/ekoM0RnthlitY0cBAvfvy9+/5C3Pa2Jo4KJY6gaQ1FxY1xg8GB9nzR0KNYt3+9p U+xwQUvHJ/+z/NsRscRzxeuU9ZolHSCYycxmu7lm+6rZPffZruJqDOyVOvV2ZoObG/pYqjbbGy9V q+8NJCjqsesy/Sbgct0w9t7J9uI7r2A4e0UHo93GobAKVJA5/6jD1L+0ncPCdjpGO4em0DO3vd2i 9jrmuCYBqSDE7sx2Cg9+h8b1aRLgHvhcWvdj4cbmMQyHNIiPchCzJ3NU2FDHbAg2qdahlbbzS+G+ zwzoFz/szW/oz4UN0YD+LN02JNSoI7gCsSD+Ym4+I2ssyMz7Nw45syj7ILe4mND85vzcEL+HFyJy mlGP24NXEiLGIuqByIp5zgG6RZRbHLBL6iFVW2OlJCEwU6qC7ZJ4vrgwl6cldoJb9enqR52mOAKp H2Vqv9VqNVTMIuwktUGwBJERH0giZN0i+984WR9Twk5hBEMch6SklPIonlOXrr/hsFG/VXeuHM+n A49wbzhJQM5EStVoMUJN8aIOmERzRVUMh5sCKfwCRZWILuhIqRmeX5NyCEWFvEKCV8YB0hHhdEEa DVOAqnGfXEYvY/sZp3bi1j0+93iS/9z9cOy5ptxGI858asbPyIyiXnrxz5BLgWC6UWYTgGgtvZKa cifIz90gWZRkKXmg1XlSx2BdyYfrSrfLEhb1i/o0lHExQgDK/D1Xj6PvhzELcfLjsIOSluI1iH4I o3v9T40yO/skkPe3SOl9k6RajxkWb8oMYYg6+D1IC4gnCUXMH2LMDHE9pQOsFSVuUHpBclVVCaRf ML/BZ8XJoxeV8fKG0+R2LLUqg5CUM3QkgA5kV3SW4Z7SVMtBZzNNvFCJqksnMTPDBFaYox59QTmq qeWMbhQtFaRmoKm9P/7zvhHlQNDtdScgb4ilqktpILnUEXfRmR4eYHyit29FG89JwJEJou7CAv0V ImAV7ShmF0CXA3oEE98nw+PhUASe35Q+u0RpSBEDVbTDuaYH2XTy0qSi1prsO26ckPmUwR90YgaX CAZsqSeJHNaqtmbcTNReyqYpVF4FBvCeflGq2kSzgNIbOXE6CuBdjn+Npg6y7rgDstorH1rSCtCH 5xTzQttDyCvWNX0lse+fyHJGKllYkPr7s3eNJjpnt8Q+EOtUWygNdIF7gWwPCQB3EqpEK6TnwlKG +zuzKKToi+lqPoSJRwoyGLrede0m/T974KNbJiIahy9TQ6EgHNMrUn7FAmhfOOCVa9+05Z8Wms+v UqsLZrgJQmmaz5Pomo1qZaNaLVBr+ZoOJOvFL2eoOb6zmNSzOq2k7QBu/Ovp/sHbdQR0z1uXycj/ A+o8aIzr239E9qxVAEOyz08ziplKl1Q5orw5O+juKEmpfPQB/4XbQWr2DXI/SwmyoRUWdQq4cesm DXU+UdkiuSCpW/DfQN/p76h7ASovi+5W6kzH14rNaWRuO8kXZ/pZbOhyFpcm4bX0sEvjyd60O92t zecvXr56vfNud2//QOJXKNrNFz3Y39t9t/P61csXz7c2uyA5E7BiWQSZCmyGqNOU9X4WdL0tX+tg X3cAs8X7RxEDssUrv1+sMnywOoNWtJ82zJaizls4efdoiMQuqdhPv0bK+ZYhnuCGLBFHOtJ7tv5b z4ka5RJIJ+dpa968m+NqC9sgrgCuu0IVLowltnv84ezcIQEzMQOJLRVVqxG0KNBY58W9oHXUqQcN 2ATU0v0M/VJ4BjwbX3pDYP3UJvoQIN5iL04AsR4dX6Bb+I7DT6BrkXIYZIyOEadho6JQfaXeMIIk QRoBMMXzGlBYa3wLe64pe0QfhsnYl/Y/ib1x6wgkWZ0XG+jb3sP7UHw1MIPDY9cHdAf1sCNRV0Nv yEun0LZ0hNJoP07orqF0fpIEjm9zkorW+GQ31NS014DpbHcBm3qMFjk2jUYuOiw4wneii7Q79spT 22tx0ya6jngYjQg1SFJtBOR3EkkY7YjeBN3VYNK4tXFfp3ckYQTS2L978hE+QEKef/KCHamnPP1N tAXRES+2aOH1FHjJycl+iH5O0sde2oN9YJQLXlKL2WBueNHypciUR1LH8kLgK3nBVr6VMdjNWFLk hYdlKMZTuotjPNqd7iuajoq+pP3FyFUyfa+ni4bpcIIaBdJL8iEBSUppAHiyqyJOlADDzqMWHBS+ 6yzQJlSRf6p3/JgimuDRLS7wofgx0dDiV9MWTh76kqAZn8thiFew8YxkNHN0rGZgtNqayRrbUBRf I28UCux0COxAr5tbsldqQQElXbkDpbD9GZV191OVu1AKB1hSOTP2qcqbcoYFlacm/jRgGdeqAM5u KqCzTY3ObhaCZ+w0RD7h7m9SDHkQyHazFMx2pL3WPMI7BiiQekk9MQyTwfo8I2Rp6kovgZoEY0B1 WTkoLoHESKyl+KMRxBGxCS6WOzAQmyxG7npGDAaTxapxUh84jOuyPiJ3RDRiEqS+5IusUBG+ir2R ByAKMYLxReiQkZd7YsqmGrwSQK2t0UIRTUoygPYGFo6XTMWP0fhQgSBjLWNWnOZwbboOGVxbihHl B3UD8j13GDBSy/l5ZQioviNiflx0r/N8n1198WVProOEdaQgJrU0MoPQiNhg7LqY/Q9E9787z78K FP3NYlGLRS0WXUks+tuKgNFiYHnD4BD+FOE7+QdfG/juCYC0sQnNFiHuKZgnisaGOJe/DVK7S2Ab eKd21FPBoqfZ2LO8AoWTfGnGJm2NziQJR04izfcXbkBXPeT9RaTiHoYyZvsp4Bd3BMwhYljxZhyh EePZH/GAqY163tpFpviXX//6y/6+EJ0toMfjBKoBY+q8fo3nF5j+VUugyf1DCH/pvhZ15ejz6/n7 I2BOk+FQ/CgC91rEZJto4PIJeU0Q2IM/Gcwboor6hG4kWJfulw2dPt4ovMGV/QlBSXrzGeg6R63H i1dAgOU9L+DyWJvfCoK/wPmZNVGgHLzOwqM7QTfvAd0mi8QvJ0fw+I/P8NUf5IjFOrTse73W5Xru oRfSM3gqbyW83/nt7PA/9wFqAl0Ph3Vyj6L/wDwaDVx0w23JG7j09V4J7hBeqjD6JBoqMqPvezsm diHPKunhRA1chR5giZGX/E1xvvokkMg1MxDRxygR8g0gMIpgC4P7X1wO/QLGGRHIJhv1Jzm17e3O 558FjtRFn34Hb7iP6fPAh1TTZ680HJMQhQNImpOfjZf4KH7bpkf00Yd4g/3i7dt2Q/yvYgPDcQTl hnX5mdf/KxD7UURWejgTP/CVTZdvpEtg3Rb/Faw3NCNxb7ykvtFp/CxE5jukEaUwwR+cWGoWKEbC N00cvgHAHwf9ChA+/fEZDfWfvIlwxP3Z49WG+n8dwKiauOS0kLvoqCAX65/4H9dHPx1uEEYr/leU NemHF16/1YE/ygMg1/aZmxS2XO9vv3j+fPN549+ANv0M/xT0F7HRb7x922/oWUATjhgTYkewdh02 SXogHC/pLjxH0MBXMiXY5i7xzyCE4cc//viz6G9vv+38LP6JHmNIoPv/AqtFgxx60rcO7Ucp05/7 p25cSxnzIcbvx6AeyaRBNxvpkHD+8faLTVxY6N2cncAga6x6xgvKnr5ZpaGkDA3hANBgxTqLg39q GHPGP9NfStpR2jf/2t76TX2omD/VrJo9XFoonv282Xr/1DscPzBNq2DU8H14bjKoxewRY7+eyPQb F/Sa7ivqFp3Hvngsq8kohWk3k7d9XZk2Bi6/3E6yMMn0RG8+k6GiT1kG1J1C0lmYw07eTozFo3rx 57eJ3M3tG0RvRoHJ2wTo1wvjCW5NPR+1NevJv7ydNGQj9fhNPaV9jUY6/3hj42c+/fgH5sIJBHjp s/kh3qcBHemIxEkaciJMiuZGp1RO6L/5d6PzuaEm9gqAl9zAVJF9lqrtwZvWvw5y+1DETdnX9Ibk ac5v9u6tFmxfD4ltQLe3IvcHFAkpSCCpWZgnhriF8G2r1cpN/OFGLIwhq7/KTRNvv1VfBAiaF887 X0taNvjPPxF1M6Yr0SpeuEkFfeIWwMgkq0n8Zf+cNqdWejmsWXNSxz46psx6PYm0UkPdMrWKOLh7 elaS5HJ2clqPuo2FwP0vLh/S/J1H1E4BtXNv1DXzMenWOEqFy4ZLtRrYPSvPOJSIXkCYGJpwR2MZ 2kWnN0i9Ihca7JmHopWRf4U8/oCG9kmFSZIQYxlFqTPhJzy+sk1JaDD+o7yYbUa8lfHIMhFXycES iRm69rNNGW/3c8mzU03gZcwlCmUJp2YC4OvKwzCV8P+TQF8/l56bjIaRZvq35XfTEZM46Pc7GqEn NsYp8QHsoT6MgDk7qNJlJ74vTwk9WgD9SV9F4WuVWzoIphNnwWu/uD2w1xMcB/qZgmzm9UFEcCPY Ld4/YDuvZ9WTfH1CX1DV4VpZ2wnLno3SytcS5AVhoi68vMzlSWWn9L7OkOO73dJI1MVq2I9D72IS yYsRmfvoLELQFVs3uPKikIMTDyaR0tkqKYPumRA3lkKt1G0TeeBA1V29D27dJL01jtcTbke90Idl CUD+itPRqcgidd/7wtxSxuyauhfw2DVznRLV3Kq7l2oGVL3KavuWAtsrfreMa7I8aua9D6wNkxdb ytVgsoCoT2Lpy5RJEtbIq8I0ooAmKiCK50J2lSKKk49TiCK1tbGdMo8wlgsjcET3hBESQeCtjM5C fOIU6RwaKRkpxAQVeCWkoDkFMHTAD4xkY8AHjD2W5plTIbieDHZo3gs5GMgDPzevsDaipdcPJc/H tfx94kUuXY4ZOcmCyEMUAA9k4RZ5WORhkYdFHgsgD2CPFnkUIo9fqaVi/cbxOCm7g9oVx+oS3t3u oaKeZjQX63RbHXI/yEXpI0+s99INXAOa2AzSuHTPq9Ey7qCSKwUglXTIOsYAjT3aNOJkKQer9Ka/ CsHHqIXW9h7uTPqa6NnpuzRSHjIXGqZysyelC7CacBKn6CjOB8T0tAmVeIDkNfpoumPPDy9kvEJm WX0fHcAwJMXp4dku8vEoxOufPjmmoZdQqgvTl8AXth1nEz4xM1IxQKVBcLrIiMIHupqjprPmQAoT 39/w3eACHW7SwKXZ9eQm4KPB+etBfyPyK+q5AXDQJE4/MxTGZaUt6pkhC9Erh/ykHIVldSBlI6Aq MmVcMRW/mJqT/m6x3Ecc9JN6YKibWQLOpaptdRIxY4DWC0r3IjPSD91rAYc8uqRYZRKqwEfzPRVe 9mOgGX5AuWV8M2wcDIyj2WYM77RpCNeaYJbaQZcs2og5h6LVgQ/2tmyFWiuf7bMkKtgMZHHvq7IP ADpUgq57Ao8ZHJ9CMldh+V2O3pzj+ZzLr4DpJ+FDsHw5hCXwfA5FPZvpS1H1G7J8HuUcnq+XugLH B25elePLFIuW5VuWb1m+ZfmPm+UTH7I83yxQZs24cJN5uZaR32+iqT6XabmKh4Shw3foRpTMpEx1 OBjxV3Kg8JZyh146UVBTy/aj4ItI1pXiO3alqHsNZdOgv37XZg15HpZu2aj2NWjXYPYKXAwYDVI7 j7zx0Dn8kraHXDUTONHH8L2RJ5OZy0CVDtnF+GaY3CKcJgh9kV9MEYWYjzjFEFRjqMMJb3CEdxn8 Mo3DsfPhr7W1NDX2VHPGgdV5Ahx5dcK0Nq8WkFvJ62Dy5y63wrI/Ne0bedexPSKfk5LktCVg7W6X xZaEyL6V00kVmLaF0CEH02a5nUhSNAXbaIGX7nyyDAiWoq/FfVCie/mg8JqUuaFg2xZ3WdxlcdeS cReSr2+Lu4BUWNxlcdfTw11wtCzuItyVN4nNCFPf5xSG6zJQ/UszoYk4wOgouzLJYYZZ/KQj10/1 ZcaT39WtZ715XqqI8tV7m+na8/fR2JmDJ19SiHksmMWT/zF5fyJ2enHoTxJ3qRCR+voUbTY/o0vj J8SJnynwwie+U0+8CHkSWnpujfSVn+8abL4eqPC6vx2fClg/t95XMW+b0WajIc5/3f/A+6pKo9U6 JjXiye6ymz3ZXTxY/mEuqrBg5svJL5DPonFVlkiTIrviRKKJ3XASMAKurcXOFQMVCbF7wHb7lxxc x2DJOXPpdPij6zD6wsYmTO078m50PknOZwBNo01/wQyMKqgnuUFzgHxRVxGczJvzf2inWZsppSB5 R0OJdiOPOjhDeswBp2TeVSc1r2LQAgYUk1hJCeh8zZng5UquAyDDmPsYMXq9JY5RhLgm8F6POm9l n1p2g2/sYYi8ONHYLxc5yoEZAp31xd8no/Hihtl0J8jx5ZrP5ozFAvoIUaT/NI5qk1Fwcjt25SuZ aVStPllR6fYuGaVDnZuBEkDSveEIL8Y39FSN0GbpOPWHq8OBbalYrVewWfGtqmIkPOB9SWZm5wsM ga25GDUDwawa3U9UNh09FP+HG4WzRo0VdLwmWQlGak536rDhdpQRv6fs2vi+LbJpt/WOpNQU7cU+ 8AGMVnE+jFcVYs50T4cvAJoaYdrNEce0NTJExIkRtQUf4eai2Tk+Sr63eArCvqcOQWYW1I4OwGNQ gqYphmio7LALJpbJbD4oCjuOEupEFFINznMdTd8qqLCnklz3EWVwrDA1LKTnHFBLdac/Bx/AdaUC 0MOWcR1UmvBEJed2B6ZfZaNVW6PM8etGV+ua0HAuJRLzwlBQ0nW14pmlDsVYZ7zLL7n2OHHI2o9h C/EzyMhlGFJmcIUzbnLgZCQeKhCMUMHqAiSlOu0QB1NbnDicKZWGmh9fvnGMZCcZiZDzoLBLxh2k wLxDQgLQ9gI31HVo6jPqOkcurAoI3bizcT+MIy/E/M6IMic+Qg3fQ5ixg8iVxGPKtUKn9SdxHFCK 6C6F4kgvVcAuaGa4l5z51gZGemEU7A5avD4HGyiU69s2DoZEAuwpCyl3IROptfSoTlBHYA4IG9Sf npQcmLRXsk01jBFqRLR3iM5If3h+9K6Z5no9PhNf4AWcidEEOAeHLoI9oiIOZchZmloLhWbS9MAi EnHKqIxw6M9gXd9kglxZz4+vKs7O+vkePT/+4/3JTvHLh06NIkWPp5IHVu1Y+fsJY4SREvCzwk/A TXpOz0PoQ5kAZ7VrpDrJpVl5tClPCPrN7FEdr9xS1RmhuAPWKqTb4+EDABL/UrhgOIXdUDqQcI0Z Rm1NsqTeBO0ETYoEp/F9HRXzownmOAwjt5GiixmpAZWiZef8/VT2v8y9IuQyFRQQnIaDsOD07SI0 ZIHc5V25Ymdv75Tyyj9oMg4ah+FqDNtHPR7o53f1KwLR7kexBf/DhjioEeNRieDoX3vPDilFO3Jj F2UcVmcp8MiffOG8alILALPcw3nhZTGF8hAF1zsszPE1Muzei7NKf3lSTeUUFiMZJZ0KC/5RFlPk BZ71VJJYx88phUYsdvTsrLZGZ0EaAA5wzi5ZnjCyr4gnBFBaYl8vDQ9cxcvNrJPSQ+B61dagycxb HP/Ii2OKZ/ltoPLKXMEtI8nFzx8nrpJ/eb1AZaiyQOnVv0WDRLa4wF7x42Xc3K0tx3qwMxg8O5v0 ZvnSmqwTJKx/eYvqlSphdGdxunAMM4tuK7A6zGkgS+d53fGJgCme/pVJ1pLZmurzvn6xkn8lWj9W wL5QLr2vIiBNCa0kVcl9AsxfnFFXUgJZTq80cqIvDHl4trSSbI7FJWiJHTZ1ZBTRHkecpzs5pD5O 2V3k9h2/P0H4gWliDSgSDofINJ1EuHxVNhyDqJ27K3HHybMhXFqZKdCinLs6nrnxJ5foibLHjMjB SyPwTznAOueEW9g8/53xtnJVwt251RLY1eJ1a4vbre9QZUUY1gzO9K3YD0p29+c3LI3M8xV8STEv dek7yFZMXDJ3OpiuPIjQlfccNAQvb2C+u7fwJduy8tdKy1/TbNNICqQl+d5E3g7FgNm5bcyGRPgi Z9qaV1vL5A2iBSdXucU/uJUQZz5+3BKi/F3Ig6y2iKi4UOFHx3BLXMpKRMSSlIULeZp9fRFxGXJh BRb9nKWHaWkQ/VW6JKd2xKXD5MO9GaNfwHK99qn/ewVXIPYK/9kQneoOT8+eicMDrIVCOPlgibt4 N9FaYTJ233fZY6wfkQt6rHyUiDkyLQ/9gfSzMZw6WpI5A4lO31/LFUd/kJS/me5On6Lu59QBnsRO CuLuSr+doQPkHf5+7dwyRwrH3JAvtxvWuh3LFDcqsw8JcDTUNIgXOkD4zp0cfSboBoFLRLqFZ7RY yKQpgY8j/vLr4dE+8eW942f0D96NaWh/+mcfPcBwvKz4T90RQKTGf3oJyKrSvZwE5464xZwM+Al+ 7KSSMdXMdtXUAGXooVVbXhqGvjY6OGGxGgx3aMMizmOtC1ddjEWuuur1+KT45SPSrx4Gff5nHQiG yUnZ0WoSOFcOAPCe7zZKeKukcvfkrPFtjESzAnN9IWTZLH+VtDW4EGd/PUvckdjdOTpaKk9V3U6J tEnkjO8pzLJfHkpi+mbWiMg5yqv03WQiMHwLH/sP6qrf3cTVcxw6jtoQV5mRocfrBnedBqMRFx7m uZyMBUUm4kxmFEFIxFBGBoTAiMTAHFHV2UfXPgxGpMZbx7azgZGQVbJjGN46W5gPAj+iTx4MFFuo o+eAZA7sqiddOFkmdKKLCXmPIXO/CMIodYUl50yKRYTN4T08FXkJBemAM+MFHGgZlwOBBuwG3GVx OEywKvSBvsgwI/eKP5Xuj0sCkpBF2ZmLYvFguZwLdcZLccFlUcijae6VH/AeYqo6N/zh8PbaBCV5 0gnRWLKBPmT+YUpJ7A4psS5scQcvYMorfXHqwmZcZmTV/aUDK9F5sWFO0BhJzP7BMB7pFOsYu5+3 YP5eVgvIFU8N8+Hh/msWDlvOjd13YW74XckLYvqiKLuMm97GeBnxxhtNRiK9IGZckFTLGjPKcWDo eJDM3Sx9OCKVThGx3tAPr630b6X/xwZSgFkioyx+v1hg50cq+0vXpvnOT8sAJy+B6vm5/BG/7hyd K2lzqYAEu7qz7fcX9Hb2MPkbX3CmtK/SN1uEfWDy8cLowgv4xgwSb+l9vSiImI0TKJoiUHTUNfNt BTIeJ078ZeUu426tmOgmfxYjc0U/92/hAeggHtJSaqcPmKZJZZQiGroVqMQrAeWyROLUTSZRIA4Q ++2rc7hUagFd3plYnLocwxRP3Dhy+y4FgDCPXbV2dvhikssBMNAKiWscTcaJOJOSwinnsG1mCRLn qeTUy+JMw0QA1VyNY2FmsDRfAGJEp6kNjFiwrCIDo2ZnFAaujM85RYcsfanyY+lLCX05Pdi/B3nJ XWs3s0iU3zw38kgsdvu8HAdFvb/hbeG5JA5zS6jCWTqHHlnqbAELP9v58/7UCf1BRlC8SZZrFFEj ujMZfAdSY0CyLU1sirIA/sFjBAItYh6AK7vvF3SbOyRbO9A2QmEUmpP1DKR5wtA+eKfM8TcYN7lB 7JGvh75rkQkKjeYNFEF7IWeU1xfx5AeguDAaTikZOVIUeOq+I4npSh2lv29qOqCVGbuuvPXLLU/G lnRW+bGks0xEPX33N6QTS4BnuGcl669Aw7rCKD+TjJ3ucwh9fOQ78cOTMTmoJVCyyIB2euisg1w6 LYsY5FLjhrBJVC1XlEYhKYgXXIX+Ffnr4nrD2pfcxU415XlHopRExaGSxdFoWlvLOC8FLvpBOdEt 5zpnpDiY9F2ToElbr6VqVX4sVZtB1STZWAZhk9HuqpC1TaFLZ4kaEIKxPhycI97TmRFkPIUlkzI1 kE+jz5/iz59uPt+Zou2FwQ9JxlY2da+g5w4VpdM37uMETnNtTTpi4sSVX06E1wAUlFEBTFKgdU/X RkBuk8iMbpJ2gV6ZMVtPZHxBeChjQPClheCWyWU4iTFAYxxPpE+pbF1GU5HQdEiXkPsYv2ZA4C9y M4Dxp2UHNNoQ7/l6quHvUkf8mkROEDtS2kBLmI6nKFV/GL8RH+MIj84+CozLGDeWPz6tS47late1 vQYvWuh8HhjqEpZc2tP6sHt6oRMNtG3xAYaGHI7v+tZznfLG5MwfaIAchYDXFcRQzEmPOA7piowz GJEvkMy5kw/N0XPl9rmDBTYTDwfHuu6HF2T1hc0KTDNZF/WdD3sNYuh8Iwf6H3hX3mCC12CMHVhb c7V2n9LjBBjTUgX4KalFplQ3sXy4yo/lw2V8eP/0cOfo8D9LuLAZxECxpZOUA65qvAhZeGNUFNYB PR/kv6cJuSQws1pXttaNmzmtZ016sehN4ttZDafhKOKSFpF6VhhhZ3NjU5qxt9XRkr9mGIg3zxL0 fMIP+ExTF/6/jDqOE70eHH84F2ewk95udLbHTpS8aF0mIx+9V1ui8wK9J/5yeXvhgtSGRanVd8d7 f6W//Hr+/mj7/wNQSwMECgAAAAAANyANJxmZD1UqWAAAKlgAAAgAAABGMS0yLmdpZkdJRjg5YTQD fgOAAAAAAAD///8sAAAAADQDfgMAAv6Mj6nL7Q+jnLTai7PevPsPhuJIluaJpurKtu4Lx/JM1/aN 5/rO08APDAqHxKLxiEwql8ym8wmNNnvUqvWKzWq3Man3Cw6Lx+QygItOq9fstltljsvn9Hr8jc/r 9/z+DugX2AOoYWd4iJiouMjY6PgIafZCKFh5Q4kRqbnJ2en5CRoqirlCankKY1oxytrq+gobK2s3 +YN622VbqIvbe6XqG4wKfEIsfMxhHKGM3MzC7By9Bi1iSnRwJo2TjS3kYUzdEK5N/s1bjq42/mG9 sJ4+wm0gH0B/wW3fnU/xDu+/fO6fQCr9kgWsJ27gpAT29k3AJ+7gKokKK0ooaDEjCf6MuxomVHCG Ush5mILok1fynMl5CBGsrCey5UtsMCFmexlSZUqUMV2CPMnSpwOHHGtqPArQIdKlxSg2beiNJkiI MIMGRdnyqlSqWKsKZdlVV9duW28K5WV2q9q1Uttipac0rtOLc5lqLGo378O6Gw8SdXe2rcyfbAVb HcyQsNbDcAMzfpwVMcOVcIcIThtZMYOiePU66+w5tDu+8fx+TMw27FScOqku/nrZqmXYmFUXxofW sWGZUV1r3kx6aHDR6UATP26cn+nNgFPr3o36OebdtjNHl1xdsvXp07cf9vkXAufhx8klL+/5PF2P zKc6vx25tmzI7MHqHkvy/VWu9/7pX3+d1UjtPTCeUugVR96BCpJkYF/1/QZWbkBNWBNPFrrU02Ro ZVjhTxziZBSFITI4UmOEzRSfhk4VuGBF6rV41IviJdicLw3WuAeLMAok444u0tgBXjf2MeR/eejo Izw9JskjkAYVeVovUEL3BpJMlrPklUo6uUGWWspg5ZfReCmmNmSuVmaOXDKYpjRntonMmxhOCSdB a45YpzBy5inlnZn4GaWRQwkKG547QThooQKCV+NM11RIZph84rLnpMMAakGl1kUEoIZfyRcgoQN+ tyhN+XBHJZ1B3qmppTW06mogms56EWIGjgWqb5sG2hh7Jvo6aimsYhqrFrAWy/7HrMSeqJaJjAKS 06j8vdarWNfZVNh82uJYKBzDqoqsOsuGe4yy4C6jbamZpXVTd/SxC+9kpl47736z2UclpLihWIKk 5BI57r82BpxUv+lue3Cov9mCW4DqVucRtt+te6213Hp7Lpt7aSzvnBYaoW9AEvnF2hFeeQzVqbfy y/FoKQFH4qMh7CnWyJW1BnIRHe980r45p0yyygSyjOdqOsEcMtH9EjxjxgQmrGtvCKcKobPYeViv d4oye3EK/nLa4c46J22Syfm513PZSJxMtsdou3yvPsA9SlHNIFfDNNj8bjhbEmQ3/HbbfuMcFYmB q1i43HD3to/dYwvr9J+Rf/40LUJxUdu11lu7temini9spLsTe/2tcoZ3fCjPZ2NI1tukvA6V4rLv 3bjIRwftad3tPpM30rS3bE3sYgvdctEky87x7y57Shbuc7LNOvS5TJ5p3vGGevnVmlUOauvYB4sf qduLvutTXZLneGWre8/++q3b3L77x7u/euLS0882w8LLqzv+S1O/MUihbn/xg9/9NjQa1Z3MgAKM 3uHWp78HVqV/96sFAJVzwegwDDKn+dzCWvO8xLyOV92yGlDaxTj7Oeh8UKqZoVAIEAm6EG3Dmd+K dvcyCbqOJ0PzXQaH9sMeTvBoRUOaA6NnwBoK74b5yaECEwjBlfnQBuYyGP660BBENnxtivnzmRCP +D7iKZGGRNldF6H4RSKCjYy8y6LezFg/ZcxvgFAcIx25qEYwGjGPaLyjD3oXETfeyI3FQMcW6wjD KBJtjt5LYpFsWMaziYR4aeShcMxmNrwREpHJ+xgF9YhANtJFlJwcEQOFw766+O1vLqhiPGaExU2K y2njmGGIgnbKmBXOkQFEYiQXaEs9Hi6UgbxbJmcGSFISApeUTBtrShlDPyozmPEbJuCKObZjYsyC AsPCIUnplRsSUJfPBOcXw/hGX/ZxbvdSZe38t0LeRRGewTNaO8X4yCX+koi5XFw51yhNMCVzed20 wjelCS25PJCX5kRlQP7VKbd+Iq5vUoQm6WSJ0AgClH4MfehGw7nPC0kUZRQ9J0T/iFE0FbQKBz1p zDg6zgNec57W3CEabQcM+DFQp++sYDyFJT/KxJSRjVRfNW1n06T2zIis26nQKDjQgrUyqivNQEvR qSLgEVWmswNhCAu4L+ZJb5E45WrxEsrFbcpzrMv0KigpOckLfRWmyDMl0OaWO7iWFaopbRo3qzqI 0gUQl85sJv4Ix0zlHfFuMBWnZZhITmqGkbEgoBkcKfS4t/ZRZoUdqicddVd2egOybatg+uJ20b8C 9g+CHaVMb/ZLYUIPHGRdqGLnurhqBtWJA6QsO6gqSZXB9qOfLB7imP7a2K0W8bj0hK0lyehbFJhr FtStrhdYuFo19TW7bpiudb8L3lVaFbjclS55yztLC4Z3vexV2nrQW6XzwpcLx5rvkeRr38riN7+/ 2C9/47vd/+o3wALuL4ELDGAEb6G+Ct6GfxscywND+B4PnvCrKmxhb2I4w5fksJ427OHASjjEfiUx pUBs4hwwOMViZXElVuxiB4/4wjjVmXjXOSYUR9i5j11bbn804xjrAMZTvefPtInbHAd5GjJb242d CWQhu0nHatWYHS9JZRojJXVXxqtxEbRkKVMxy+Zt6EftaUgyG1SfvUSumlX8ZjFDbmCxhaVrzRNn EZ8ZudFsUpjlPP4DIreAZV02qZKXQuh8TuTPa2Y0oFOR5//thLO6xfFnIi3iSaMWngQdiKAfXeQ4 lYzSnH5iMz69Y59t2qdZjTKog4FqSF/W0HsWtaO1KNlaJ9nPr4Y1pklXatla+tS/7m+wK11XhcS6 1+a9tbfMzGddf9jZGob2sIX9j2Uz2wTa5rZXC+1QPFPbwCEEt6k9Xextr2rczd4lks1NbHY32t3R dSepwazuW3S73RNVIbxtbRcU+RjbpeV1vk+x7wwn/OBAZLglFj5hiDu80xMHmLw5LPGK71rjCeY4 Mi/u8RaHvOMjX3fJyX1ykqd8vCA/ecZXHkiYd0TmPHg5zUV+8/735lzGO49wzzH48zG3POjJJjrF ja5apNtp6BC2ucadvnOo/1fqDqc6za1uX6znW+sr5zp6vc5ssJdc7NklO6jN7nG0V1XtcmZ7xd3e TbgLWe4Mpzu57M5ivKtb78XiO4n93mvAW0rwGE/3zwnPJ8RbWPFtN3yBGd90x0e9vZSvvOUvj/lX KH3eme+85z8P+tB/YfMsFb3pT4/61Hee9BFXIesp7N7Xy37Brp/9XmJv+9wvHfJrr73uf59pycd4 1cAv/pB9b3x7Mj35tic+8yf6/OhfAvnSd770r48x3q/U+tjvvqSF72Lue3/8A9Z+QcVP/vSz0Pxx p7763y859v4LDP3wr/965P8v+tt//9hcfuNxz38B6E/wp3/7p3oHiIAJqIALyIBSsCMNCIERKIET SIGV94AViIEZqIEbyIGJcIEdCIIhKIIjSIL4p0kliIIpqIIraHofyIIvCIMxKIOw4ILgJ2UFWHw4 WH86mHw8qHs+qH5ACHxCOHtEOH5GmHtIyHpKiH1MKHtOqHRQGH1SSHpUSHRW2IPu14RayHxYaHxe aHRgOHkAGIBiGHRmeHNomIRcWH1s+IVuaH9qOIYmGC5yWIRw2IV4+Ht2+IR6+IZkmIWAaIB+mIOE 2HyGSH58eHWI2IeCGIeMuIaOOISQ2H2KKHOWOHaUuIWSGP6IdIgsmLh5oJhyoph2mnh9pJiJnPiD ptiGqliIrniIsJiIrLiEtBiGtpiHsriKuvh6qHiFuBiFwHh4wviKkTKDx4iMyRiDTGKGyuiMzwiN HMiMxBhZ0WiN14iNoTeNvFhigZZSzhUbtzdVNTduZGaO5YiO5EiO/tcGzYhhNVQI9JIi4nhF+WJn TxOPE1GP1UMnpHEu7+CPXVI9+4hBCRKQkjOQ4hF/U3KQsMeP22iMYQaPViWP4dNwBPmP1FM7/aiR jaKPQeKRpgOS0UZr95A5fSaQisGQHZkobZaPGrRoEDlQK2ZHcTVrVoMq9KiQ3eKSFBkoKPmSwXKP KfmTJf6ZKdJ2batwkkMZlPZolEpZlE/JDyGpkzWIUTT5SFiDL+GzSzwZc18lVBo1SUWFLtESXGOV kE9jliB1QB+plsDURKfiloOyli6kEuWDlJYDl0MkIndGl3upUXgplfYRSoHplEk5L4VZl4eJcwvi jhKZlYZTOYaRHS1UN9+zlfUiILPGHNZiFqLDkWX5mZmJKINpOaOpl9sRmgrpmaSZNT0JGK2Zmrgy lwkhm5vpNrXZmaiJm6ISbnTJm9qxXBfpI495YQ8xH65hQpUJdG4jMbNJGbQxSAozmYx5boyCOZoj km+ZnY2jm7H5Htnhl7YZnkJpmh40mbrClJ1Znr6Zl/7oCR+j02FJYpx/hJyYOZubAyCWSZvP2Zvy yGpZMy1y+Z1aSZ3iQ2FlyTnCaZ3IJqBr4UkFKkILSj4rqaBQ8ykSip0HSjEJypoUykEryY64xo3E KVBTGTZCdVy4sg4l8aASA6O2Mp0xCppp+ZeZmZMeyp35maMW+qE4OjqruaO42aMa+qKuqTCwaaBE iqA2Sp5AOo+CqVLFSY3DOWgXNGKw4ziS2VVk+aO88ZoN6qD4AqZk2kBKOqH7EaYAOaNlEaby+ZtP WqapWXTnSZ3P+WV2yhV4KqUkmaZz+jA04oknOJPvGDkl6pBXqo6stajH16hw9qg8R59VipXZaKmX iv6pYCCTV2momeqpnwqqmQUj9emNcMBcUSpVa+WojMqqq+qqkNqqcDaiTIaoX1mqteKT4WiR87mT YnqdvlqacWqeOredLfmQRgqnuFqsUdk0BjmdCImsffpjaOqVqVqVo0qphnqfmVCR1Xp0JPQn3+Bl y5qrGUqu3KqS0UqQBIeY2+qtprmuSTqe5bqU7aqs5nqtLUKqJ+paNik/3Sqm1GBC52qSzJqX8fqu OnSUxgqU9MquCguV7ims6CqxB9ur9Wqv8aqeJoqttTqu/Lqun5OjL8VB1mpXW2o3XhqghAk4hpms fvosLbuWCfurLItOIxOtJSKz+SOtD6uzN+tFOf57mkALrGOql4qJlkJblziknDE5qR77rbWwrWWT LR26n825pJhJo2rKmsFZo0rrtUHqpLsJpTG1nrEZthQjpMBZtvg6r2jbtn3ZsHDLoxOjKgF5m8LJ prM6SxF5nLjqn5QJsC8rclRLppsZnZfRpt2JsRD7oBxKs457uAkTrDD7uOlJuJJLp7kyrO8JuUVK sH/KuRWrufB5tZm7cQeyr7lwn4E7svO4q7aKnyIrtm6xuBxKoKG7oQNKuqWbpOzSuZY7uYsRobr7 uLYSvPbqQci7oNR6vMAbub7btNqxsbxqlalln63bVtQ0Wp/Sonc5uTEat3irmQzas0ZLu/lZtP7H lr7/Ka9zm7XBWbnCu7mDAbrOG75IWr2eu7VWq7Tle7/Eer3N9rfiKmutFpaeQ0zEdKOA2jljC55c S6dn+rZZu0DrIqi3C0fqgro+e6drmsEX6sA3A8EWnBsDW8GiWz8YzJF8mwarC2lPMmOVco6ROn02 PGY4XMCyuqnY642hCsRBjKk9TMAoJcRHjMTOSMTmk73Sdaqx+7HPFqsOpsNNDKuvSsWs5cKpxqmQ 6a4Lq6vRa6X/kZEI+8Xw27tTir/n25h22pRoLMYoI7TQarwdfKopHMepK7sd67eDprl2DDrxKcAM W8YjqcZ4jKIwWcf32ryIfMZGW7OMDMgPq/6xvoopt6KuF9vIJquv2UpgSNWvfHOTg3u+ApvGkWzG bLyyknzKl4yPa2zGIWzIeQzJmjzJtfzKjYvKtvy+3TjATNxGlOwd4ksqIBKwZXU6atNJKvuXSLsc i/yzZ4mz0Dy00py7jny0O3uXa0uezhy01Ly0cbm+qxzNbPnMa1zOdjm9+eqYnlxkM/XKhsugOFmy vry7WgvAEsy2dfvAYBu3p0zO4WS/dsvNZMvPvVLCIpS2tAnOC52bDf3PRYu3Dq3HUdzJUHvIF5Vr 7RG4Teofxzxcrkuy+EG+jDu/yvu5dqujDTy6Jx3Jpku9k1zS2uOd4NyeU3O2Jly1d6vBlP7byxx7 0eGwXquMOcTsv69roiKNpOEY0NP7tTaNobTc1CC6Kz46pBAqx1CNu8krvVTN0Oj8u50CLjPNu5ts z0GtROyFogm8Wxtku87an0eKz9dz1fIL0GQ90Kj6vxG9v/TbvuZb0BF80G4Lx3Ltvn2N0v2LwoWd v+qL00DdzoA41MuSpTWWzNDSpXEkwhvcz1rN2cUL1nsKwoFtwnwq0z19wSS81yPcxhNb2msarl/6 2a29x2idTzz9ySq6fgKV21V8q1h8w1Mc3MAtdEt81pzMb9WYxMvN3CVo3JB93MD8N81N3dWdgc9t vezcFLtMlCSr19Dtbb4NsldM3llM3P47LKlUKtlAkjrVfDrvnRMWOZEU+9F2bMpSHdBvnNMAXaeu zd956t/4fdqpjGVWzbBYC9aw56wEnt3IrSD61w8ZYkY5GRZ9Pd8FG8YgzciFnAwWvd8RS9gfnsgh Dq+8fGzcfeCqjMspjth/bOKWzJKKrN2qy4YRLiHmypzfLcwpe9lkLB0ITsjjZcBc7eK5rMsrbrBs 7Mr0i+JFyeHdPc5LTuRNbp4tTtvlAeHs7VaYC7veeuGNzZXGbN/InKJoZVfM3M3a/CDYnM5Me+Ts 697q/OZT7c0bGtqAubSy/JZ1fstwHs58eddtyuc/3eCRLdRaTqBcnuNM7jBuPc+kzP6f7Anm+Tyn +8yknR3aFB3oohnRJ+7BedsdHCziEcLXMM7pgy23o17Nl77mbC7Qdg3gtU2ooAdEh47bVB3TsGvh kdnR/tvlGu6chp24jIHa1Tngsu3Tt4zXkNvKxR6fpK3CzB7Hy87lSu7snaLi1C7IItpu2ljgt52o yfPWH2Mq7tS6hq2fuS7ASu3YtIG+YQ3YCX3PxPvfy868Lv3pXp3Vdx7V+P7uTh2iq13W62vv0PvY hf5xolfraR3u1QDL9oJCNynPjc7tnKPUiu3nlH7Nro7xUd7TsG7l+d7px17X+mvqyA7yJ1/y7a7i U13qgOwlcCdHNY7oVsTYI36lw/5V5o4+lpqN7Kk95y7P2kvl2Sus2kUP9P7+725qpmPs1x/c9Gy6 2UZf78XOp3tbxLJib7be8DPz8MXE2+Mo3Dk89ug93OV99un9Py+29Qx/rD9s3XEv9xWY9X4w8+t9 60Y893vP9wlY9xa38OD+9uPNZFIrgGIW8zbo4Gkz4wivqN11YIp/+KGR+Fu8+LrU+LIu9u0Y+ZY/ +emRTDLf9oLvtL/NbWW2+Z+fd6Ev+eCN+YMM+4ZfSEqv6nij+sPH+p7v+vqS+R6e+jYv4EX+W1VH KLuq+65S+Wy/Mnjf9TFMsfEdtG0V63YWV2yypVaWSER9g8WPl8c/eLmv/IHf+/5R+/uJnL5qe/Ax dPHDW776vHfw/KbBH3bgLwh3z/WDz7rPP7tcSsH66CwEgPgiMQ++PamgshdnvXn3HwzFkSzNsnIo y2hbp0KmiIqZE8/1ne/9cPbLBIXFHFEjQXaWoKbRk0KxGgsq41U9Zqkrmfca1tagZfMZnbZmsVb3 Wszlqul1+50lhT7xZX5NSeSPY1BNb0RGrkrxa+UEoi3SkTGu67APM1PzEW7RjVIpERBys9T0dKNw RxXVZDD0Juryg/VsFuglcHQ34tYpEStmEiaYFDCvNVk5s7GxE3TI2XGZutrPt6fWmgkbVhA7FTxN HIg5FhGHfHudPWq499OT8v5trt3+nvu8SBv/OL+Wnz9N6miZS5dOXz+F+GIFi+dCGIx3MxIutGgt IAqCCl+F+lYxX6mN1EbyKHkRJceUK1kSOonoZbuOun6BdGnTEE52MRG29OlT50+h6zKSKGpvJsCS R3/wPOXUVdChU6lWtZpTKsKsHLt5xLVVoMGUUDVeNXsWbVofTL9aTaouI9tssOjWtXsXb169e/n2 9fsXcGDBgwkXNnwYcWLFixk3dvyYLhq5295KjUtWB2TNmzl39vwZdGjRo0mXNh3ZFmaSXWnSWqpa bWzZs2nXfgo7Ce5klT9GBWsbeHDhw4mb1I1hMkbWSn8nL/4cenTpaJ3fdP67HO7r39O5d/f+3WL1 cNuRYresHXx69evZlyffuyrvthrft7d/H39+o8cviFcmvybf9BuQwAINnM8M/3YzD7796jsQwggl BE5B5Pi7zSZvEITpwQk9/BDEoSrs70JTAHStuRJDXJHFFlsZMY8OlcvQqwDpcxHHHHVECcawRGRw wwZ3HJLIIl9UsUeRgLTRQSOdfBLKOpJMcpMTZUlRxii13FLLKVWsckkUBeSSzDLNvFKyLwcKE80b z3wTzjK9zHI1Gltrs8k49dzTyDmvs5O5MfkclFAW/YyPzZDcLJTRRiE8lCorFc3T0UotvQ/SqSS1 btFLPf20u0x/BDQ7LP5BPRXV50QVatPxBE0V1lhjW/WnVnMzVdZcdf0zTVIP8eVXcl6yNRpcdz0W 2ZVoJRE1MlwqtqbtiLXQ2GStvda9XmWhNkZXSVSBG2cpHS/QTrE9F90F6fT2WQu7vdXdrsTl8Mpy x00X33wxWRaZaHhh9oYUgBXF3GLtpfdcG/TRo7W8iLnzkmCDcFhiiXO79c6HNQQ4oRpjzBivi/2V aGRIQpaV33n7BZkIgQF9JFFO701W4XNc1pBiu/p192OPcua44SUirgtoj3XuOehmNfZ452+JKRmi o2NNGVyeTf5WCpfxrFrMf0p91dqaoQ442JGd5npnJNS2uRhu/20a7v6JcVobGLfRlhsmkVlWGe1c qR6ajKxdiLuiGr/2+rxqwwaGYYLPhrtvcAHn+262Ia+a6cnPBmdyzcumvF2rIXb88qmRlBdqZ21A +okJXM9qWmbBplmUlut2zWynOz8v9XACF1xk0bcN1/fIV/9Gb4h0txzZvxcm+PialU4740nJPXzm 5qEn++PhH1/5edCDB7/d4ynf3fvik18f+d6B71tNKJ03+2aHjA//XSExxh5hbKPXGmnqgxwAhYeL 3rEPb7kDH9HEJz7zLY+BClTd7STHvGPNT3bioskDLyc3gsQuf/27lvkowrYmVGxj6DNgAdlHMs1B sFmoayEMN8YzFv6WkG/xe5LzlPa+34UOaCRj0vUSNzvtzYuDGfze0hLIQtw50YlJvF8DI7dE8h3w FzP8nwRRdjpfWZBrVxMgwEJovf0VsWBHDKMYxwg//Kkwi1BcnuxeeEUgjk+OFcwbFl+Xw3W9iWpj iRm7RLg4lXnlc0v0XEO4p8BELpJadcTc3N6IPzeW7o4EHAXpqHiqQPJokPBK4wU5+TQhntKPwfOg En30yMbZj4yO1CQhXfhKwsESQU3s3iW190doIcpX+guSfnyZoFJucHqpzF0ypTZAsvXQhM+DZjOp GUEmPtOakbSdwZRJymKyclT14p8w8/PNPZQSldXrpg19pM02ov6Qiyes4Sbn+bDrGUxod9na+ZKo Qyd98iIgbOcQB2ROfR0UKF7kFeLI2bWFIFNgevQC6Ta4Rjn4E6EZpYxCgSlONGZPJv3RwvYmAb1p wIMGquuCRllKG4CGJ5S/BOlOhiBST7zjpva8acBO2lKfyualD42p3Qp5D5vZtA04TSpPd2pTVP4U qgs1pkGVFMxhEtSoNbXESp2xVKRudaVhjepYw5kaqoLJqlhVa0jFoFSwNvWtXe0qWela1qlKlYgN 3SdDPJhUuOY0EIo4RtvqWtiWBJUraXVoUQ3bWI0ith8CfWq0TlNZy14Ws5nV7GY521nPgkZb/lql TH9HWKKqYP50MsvrVVH0Wde+Fraxle1saVtb14ZWmyazneG8YbQUzvMWkr2MbYlbXOMeF7nJVW5n cZtBXTTxZryALmEbp9oz6nVWnNMuJc/6T4ySBDpB8WUhqHQkS67xkBRtZHXR20DhfrdOi6WlKP0G X3UVh7y4yW93USHPx0nvuY2cYBRxSdrrshao25UvfbvIX0H0tEPStO9/1LlJIexXLf5tGoBxuGFO cpCN880tdjOs4L0amD1nlcYomYGcpuBzwv2tJz3phGFOFOQI+3jh+4IrYIna8YdmhDGJ02JjIaN4 Szqx025cvJbclrcazaQxZow8BRy/eAvn9SGPfUzAWTINyf5BRHB2ubvgMEdJySfWSjEi8UwauG6X C8BmWE9mEjrIqM7XJEuVjeKEfWRmxwKOYZfZrMuBnnbIYy5xmdUMzhRPVIM/NuVgpxFgxjn6IG1F qVwnclKTjrTSDrPzvuijTz1Phs9OzUUzopvSBXaPpLV0YKC/t7b/MpKRZy5joteaYEYfGdHrifWw PR1qnKaUqZO9sVNdLY1mHHuuFh7Drkfdh/qkehUmTsIVvjCPTnwVDGDodqWRLeKdKHmomJ4NtoPd 7vREu9lvdXWzn1vsQ7tCq24Fdbn37VV5qxvQEdm0pykY2AHLuorKBrhWzExuSUjCioybx1IN3lN3 b7TX9P4kMnW0bV0GtwfeIdd4v+0tcdOuIt/xJjm/9c3UjukG4g8peVtzEW6Ir5jaF4fZr/MNjXBr +tjyAGtDmK3zZVR44Rrb+FnYnXSFg0fkgLX4yl0+9af3WdPRtt+zVz5vnN87xz/XOlIrHo+Swtnq YFe7Ed1duzDEnA1NhrvMhT5vp1NYvOnOua8b7nQoR4rc+va6sQdf+Ks7iM1c7dZcEx/4p9Vj72Gn x9DBrXh/E12sftdvx0Vb99H6dRH1Q2kvOG3uw+p97Rznuekj/52o+7XxlA69MS7deqbDPA5xv5vD 327zSkx77agWtV76e04HWxv1h1d9323/dyI5P7461v6a444qkIpH1IWYbDrip5lN5PMH+nd47/Fn xPzgx7hF4ce7SPBthO1zn2XJ1BT6m3vgjC/a/IdXf472b941ceib3g/+Xg7MIoX+zMqjls4sBFAA L6X/ZIz8Nmr1su0PCtAAI9AOxm84GJDzYOUBMQS/OpAC869WEumc7iz5PhAC868BLcU5HGxdVND/ Gk3y3AH/2OmOFK0pUvAATUQEjU4GiSMA4UtajE9KlgsJD6P+9mg/jlCxaPAGgU3zMHA6hhADi9D9 dCgJt5AwlrB9mhAFn1AKyYwFf3BHrNDJ5My5SEGwHs8YJm1wcu7vuJAOAWMJV2e33AxreGtopMn8 Zv6M9aLQ43Qt9YhJ7ibG8ZBuEG8sIi5v7H7P5bgO+OawBwtkVTis9gYNNWpIE5FOA4WDAycwQoiu 6v4K+KAQHUxR8HBOElVuycIQVC6x4GDJywCohGgRF8dQ6XRw+VCxBQ0x1Cgi8JJNAXEM9rAP9iyu FUNuFiiRCidEFtPr4ICsGT8sDrWPB5/xvnzRDA/E3zrt7ALiBR2P8oZRq5yNHKfOGWORo+bIHY/G h6StGuVP7QDx42ojFEmQQNqQ5b6OsRgxrloOHZfRHNVRCytxH9sRyCQKHgVti86IDz4xOPIRFS0x p/hN4E5RF1PxGHmKe2LvorBv9gLxwhCyoBRyGv4PrsfcMSVRC3aycQO78fy0cVYiiR5CUnHW7SBp 8lFQUtJ+jMtYcro8bBEDiBdvTxSB0CShcSnxYB0/JRorxx8GjYYsDaI8ESZBUSb1rylHsSszcCfZ karySRqRiL00qMMG6v3skRCLbCt/0VGCcE1g8CvtA7L4SgyLkgy5MSk9qS5hETA95S6NKit18mSI 79Qw0QJd8C+xwgnF0gsTKi9J8k+sKc8u09RSRS7NgS550ht9sgQn8x7JrJ6k7JpgbDO90jPR6jGh EjQlMwGPsjJbBxDpkR5dczXnsjUF8zVPTzTbEikHpgKxMjUlpDidMixxMzJ9Mzbvzy37svkaM/4h c5Mzd/Mavgs7n3Ews4WhZHMBy8HPwlNXjlP8ktP4FvMEy7M6EbCjutM5UbMO4/OynnMizVP67m4t InDCtlMmCvMj5BNA57MXbeMps5CLrgE51/Ou2vMmDuYrAhRCTYM+KcQ+S1IUbU1wco02JWwP6Ug7 e5MlJLIYfYo8jZBCO3OqCPAq+8rkCi0PX7TQpkxBrxOv7E8f8ROqSjQLqXNfKlT6bA0tqcch82fL qEthNmc/QVRZ/NM7SVQ685NHv886r/PLrjEl2QtLc02LtFRK2fMCm/NGbW+sdPQ+T3RK2bMaCWwT tfQs5dHHEm4clFSQftPogDOqyNRC8S4Jcf50LkAnS4sGxKzxXR6oTctzLJ+U4dwzTAsxRxHVOKKU DvkUDFkyyKixcNgUUym1UMHyUKM0TxW1Iuv0Th11BNVlT8V055SoFqmHnY7ULFl1Krm0//jz3OhU UpVvVD2VRrdxSfXwPJNmRauUD31rWH0G19BzOaG0RnltUXG1UXXVRGewV2+11EQMSE9Lt+YrwO7H Sg01WacVVDfSTp91QqW1SjJvQ/BU2OQUlGwVVan1sUg14NbPREqVUeOEVomCSe8vBotvOst1Bet1 Xt8VX9k1oPa178SDJ6EVphi2TM1VebgthCKWlaIG7Vppt+BVTgy2YcE0VJOuX8/1Mx32U/4h9hhV LW1QFokUjxxPTl3VI18l0GPFVecu9Q3DMRg5dKLmzOZucfbaTFVjkmR3EFKzRu6KbsWSFsL+zR8z Vjm9dP7c9V7rMRVqDdTQkdmor+SwliAlJx3rc2iVlVfHAGuZdmnJ1mxP0Wl5s1OXdcSa9OoSr/rs zvBmTt6crd4K7xvDS16zjF7PlhjtrkXPlvSusmL7ljtitvzCVS8DsWN6ThlHjs62Nm+pzm5HUlUQ N1XHFvMCV2nVtsnodtvC4mXfjWOFSmqdtfUet6ZAL+hCV29H13K7bm6FFmBBUKzKNug+F/MEV3bX 1gFPN7FmtnFHs+gmd/J+j3BHj2uRt/5rvzFsz5RBAzbSCJcWVRZtExF5T6l0oU54IwthodBmPVcY 3ybOKBYOyWjc/qUj0dUwb9cHPdJoiQp9SfccwSlpNJZMFDfKwpdmH2wPNjZ6H/VvNVI8e9RXg7dt p9dGP5Zgr8z9BBh+q+p4U3FGu9f1vhcviZcyRfWJ/ECCB5R6DRiCu3RqAUmDCTN1xVFz5aeFWeyC a9CEVRdO+Df6GnSc3jNXJ5g1QzRDIRNq7Wq1dFh/DwqDB9a8TnXKIlQ+v3VOOdh4/3cXY0lyaZhL jthvTRUJAZWJ49OJ2xWKx5Vge3ffstd1BwWLEzWJt5h1utiLg5hV/Ld4j5cVI/eM+f4kjTd3A8Ez VLbSdhmYWR34XquPkFOOhFF4gO0VbJuV7wQZH1/4D5H1VrWhdwsZaSslj9nO14QTkp04kznVbcWM iOUQRs/Y5GCXUT55phZNnW5TK6EzBBMZhqe4WSn5fo+2ahlTlrOYQL3PNIXQj185lI1ylAf5lisP lRtFlf/xOS0zMzMXloF5l5m5ih3ZlkM32VhXl3lY9UwNMaGZkd8XkN+2mFV3YeJMbRURkWfT+wSx g0mzIfMMnMdZlGu5k4tkmT1Kkq8CLlm5+1wZbAM0jD34gVsqn/X5npF4jl3Kl9s5lgWacd+5oFnq oPVZmB3Zn+dRnQMaQAd6khN6SP4qWpz+WIoNk5OnmaP5iy0J+oQpGqTDOWphmpsneof2eS42+oRF Wkd02gZJeqEphI8JZaWJ1kGLOXNY9Jwr+JSVcajLKX7cmDSouaXbGKq5cJOf2qat+JpZdncNOak7 15BBBMqqWjSk2oq5mKzZOKPDsKjDFKxdrHbnAEtxuYI9ZKzT+jPMminwuonhWaWzmoVhJ5fD2iNr jXfD+kPuGqVrVa9jgqd7ebHXDKtxWqs3Qm0G297q7hMMJ5BVMzA9m8j2+qUX2a/ZOocbrpXveGmw d+Lo2n2Z8q8jW2ZD27FH20xLGyvaGqP/LfMG9826etpke4MdE7Yb+z0e+5GFu/7UJlu3pfitRcqS Ka8V6Va5uTNOq/voPiiYJbqGbbu1mPu0HbiSkfnnoJtln/u1jXOy7Vq7o7mk1xm3r7u5f1razheP xM4SitVivXuE4dhAKHm7o7hQkDuid3S+udugfyVaQVsHRRu7L3qtczu839ulubRkGdw5HRyII1y+ J5y+nTSBiZa9X9K9Pxy+ObxXDlzA6aqvFrwnSVymCVycUdysVFyMQby+L/zFjZuXFfiqY9vGWTrB 9xsyRpzH1djH4zvFPVyi6/h8ibVyyQ6RWtehQa6si5u2j5u/GfrBHxS8P6oYP8x5sRmzefuQkvkk ifwxjDzLe3yblbzGmXzFj/62FM3btQ3b6uQazYlJelx8ZI9cj5OcxlNUzsV4fV83ctPZaqrWcxmc sleZz2F8t6c6hAedSgudoCWxabGZs2+Osy/ykK08xMVWvSWdwmm60pv5y0dU2RqmIFUUEbft5gb7 c//ciggYyxu8trv8ti39V8HcOwcyz4+ZzhH9avfcqWtXxHM9w3d9w1UdyDGdT4U9uKsddM1Om98g 7fBDsdlc17Wc1yH7x00b2Ec5aUHPybV5b5GWjC1xvZm9DMH92bt51eH2muM61uEaZ85731E53Hu4 rhV5x9scyd/c1w1c2lEdoa5Vx239290ck7cch6O93GXaiH94R7292eX9af4P/kcTntIXXvQyHt75 EuLjUuKHeMkrftJFXuL8/L/bO8ZTfi893kKDvIj15XU6Q+Pj/eSVmeY7+9JZ/tQzajR63uQLPuL/ vcA/nug//IRkt8w5EcxePtGbOjp2njOQfiM1vOOhndxZfauVfc/b3XVJ8c59N8X6nORLHdA1ecCD npxXXuw/qLeZQNbpONHLm7qX13Rjr+Fj3tRNPOe7RO7rOc6fvsnvHhGFpox5e93vPnvXddRvmuuL 1+vZdtwlXPHnPNiQce9NOfTLiJCzep4xSaEH/uGVHuWZfuLD3t41GmXLjuW4Orq5OmXv3PV3NeBT 3+E3/udT+fCJme5jX/6w9772V9vabz/tax1m393tCT7QDR7sOb/uj9/awTF3r/6Y0Ru4Kf+zVR/4 WR/od7+BCb3zDb23L0+pJ3+8rRd7t70KoR/DfZ78hd/8hf7Xrz97KDYZCSA+BCyf8kLuNQctTHPz 7j8YiiPJVSWKaSnbui9sRuTp1eCKzDHf+z+QtgsSf5lcUXcZ3UTNZBIJnVKrz+K1qt1+sjLpxjsZ UrjmM7pLTqOPWzdzHRKzS+A6Hk/37fP+V58BXWBN4N8hYodhIgycVYbQnZokY6Vl3SKg3CXnpN2m SuRKZmfpG6ip5tLj6hyq4muq7GwLaW0sbaXhIK7gkm1ucGOv8CRwiv6jKyXscrGz8zFK9LPWkfU1 dra2dRm1d9C0cPLUuKc08Xe6ZXhcs3radrz8/PW7vQt7bnkUZDsy+r2AbPIpE3iIHsKE3Aga1Acw 3T4s/Zw8ZNjwYgyLNh5iBLKLI45fIDtCG/ksIhGUYSqaJOlymLseGl8WjATuxEyajHJ2UulxYs1P MXUShXlqaNGM6CwWapm0p1NxQMlNNSf0KdafSI1mhfJxK8UxUbsm4snJp5GqG8GaJduxrRK3EpEy XQlW7iW4utTOJcTyLl6yersF5rN0bEjAhRENLss35WO7/xQvTjq4MdGvrCqXpNz5cmSxbBFzfks6 cWmldE8zSx0M8/7B0GlboT6n8Dbu3Lp38+7tOx5hKrBpahbO2rVxz8XQGqZtVdTv6NKnU69uPQFo 5aWLU9WOnMtwP8xlyo5r+zr69OrXWw/e/fut1d5rwzcVPs94Hvkz3a9v/7gCkvl3lU3JDVhKf5iU R55za012YGAzkZEgRtx5BSCEDGa2oH4c8odhhlLNJ1ooIdJH0YgOmrgTiGdxqJpfo6W44nIArkLh RRbyMyONXBH3IkwxPtjjUxKKxKNcOuonIJHitZgXkKoIaVuTlrHnXpVKKkVilfg9uU6U+Hj4V5cb sodjQ1r6iGWZZqB5Rn4wEvMhkm26uB6bRKoppXl2tvHlXg32Nf4nma3xwViTRlbwpkB7irkooH4y +VKcQRIqoyISyCRemYqOEmlRZyKUp6Tv6VSplJcOGYamS+LXqY1DMBqQqLeVCieoStS6azYFEtjF F9iN4csMn8pxY3DIanBkgMSO8kCJzQoWK5dt8grcrDQOdy233PhDJbCs6jBsDsJKe+65yz6bri+C WOBus+W2G2+rSdo4aZc49pPtitt2+6+q4GbqLLrSLiuuvO9qmjDDKhQLb8MQbxcpv+/oi1Out/oL cLe+ejzswArTC/I4EUO8b70HjywxvKRilZ2fF5ebcakbc3ztxyiGbALP6ypMickrixyxyiwXXOdJ FNNM6dJiVf57azU039zxt7+CvPPBPgdYNLoMr2sy0S2vXDTSnR0Vc9Mi9wn1ZqeGGd+UVjsMRitI /KJrsBI0tcPMEWSNd8vG1psVzHZWXHGIiHeXXdw5AxIF2/GdbXjaz0V+YdlQCgrZ5vjqvCnklwts IOWZSy66qT92rlXjVWtCDupyY4626SwoDuHtOzIesOyxU1O4tZWr6DvnZu4+FJ3EqwM8rLWvqvxs xiu9erSOQ//a9LSD6TzbuQ/q/H6FOiGu2oOT76ysVamLE8Jvv5x96dtfr5X04I+JaRxXm1/+4Hb3 Ty7JEKY/5DAvX8Iz1Pw05DbqNad1nxtfwvgnQXOJzWgp6/5aBYVWsNQUMEsH/EICm1O/ozgwKHNg F7n4hiUKHi2DX9uZBTc4Mftxz0zyC2GHahgbBjKohCfCQeBWsjAXtkoKXAsisQYYL/cVCX7B06Hr cPioEUaNhy5DoMOG5q4LhO1qWouhwYRIRAzWp4OJ+qDnpPg8l6DqUT60XLi2eD6V2Q0ORhyjJI6o QSj+zonNu6Eap7jA41kPjjZ41x2HSEZF/kyAFdTjEfmYNBpqL1CBVAUVWfHG4Z0QA2IcWQQR6cVR PvKCpSyjHw0oyR9esncVYuJ5eFfI8xGRfUhMYd0mUscb5NKK9qJk/CzZStuh0U2wFMomsQgN5ZlR T8Ws3v4wZ2mQNsJNllFcDjNT6cFVGjKarDSNLy2FPPF5806TeyIgy/lApoUzVePEnzo1d84/CjOe JmTjMaHzzjUC0VWHUiKcaLA/WTSzR4d7prYQWkVCXvOeccQHFgAaUBNyE5NVrCSLKqrKTCYnmSBk QkYiKsGJjm+g/wEmOutpz27mKJ/t8GgaeQY4CjyrWH7bos+M1bd03XR9NVVX3vxH08BdQagOQSk9 M7pSh4KToetsqEzZ5TWWAXVsYiObUB+2sKoaFVqi1NtVo5rBVEgopqdQg1ePms61sdWiZgXFK+pB noEoVJPTg+nT4phIo9ERiS9kJBm1Rrb/kTKRoSSsWv4hk1dc3aEBdWWqk3Z5I2rqqglZgGtVReOt YYRkLhxdnDWfesgx8pWqjPSpVk8p2Ft21a/ta1BrCRqrnephDZAS0Vr59qlxvW5eM/0kWoHrW6p4 dpB3DS1kybdXq4LytGM97GCde0oA4rGTJoUKkiar0b3xNrFK7W67JqQY8WYRFmER7nD5UVzVOTW5 nNTrV0vbXKpyDasBDGsYp0uv1dZXrDJE0GxtqtFuNIVNuUyrMQc8qU2Q15NOe7B5Mesev1mWbrts jU2j1Uun6baxjwUtDfEKzdESrMT53RprKbjhrJb3xEYshGaJymCJAhhPbyrZZmna4aUddGYus236 Xv68QuzkcbMUBrIMKhvkfenUp+jbMWo/yt7j7nN0/RSMSLFXK8ZUeLdJJHDaejw3XhZVwMGabHo1 7OVjCbm76TNPhuelWzfPOc3e41x7v6ln/xYpdFpWzxUT3GbwOrhyYu6TeMssKIzxVsKFzuyY0fzo B5uZ0nUcrhfufJN2uhG5e+az2/ysZWlW9suRJTOE0ZfmBKezwamOsXk9WWc3NDjOmnUENtJr6wPr WCSwNmuaXIoiEbd1qZEltYnRBCkfOxjMqwZPXQss60vnLdbjmgeCvWrrZj/aW7W+sJzlymYLK1jQ VEb2Yo3tpSpT9IDc1TWkt/2nclePvK4es7XDK/7XV8eZzUnONre1beFwb6Tg6X4lp6vJbnSre56f DjiFumzqOjtbQfRmK8UpXqIyE/rZhJn1wD/5Zt/eNq27ZvbIAa5p1p0bqixt+LzR/WJuKrrXUOYi zaOdaO0659239jczdLk+9Jo8GeJuMpxxLVlyfxZzxDY1zNfNcGA/Aq1HtgtQDa1zpscUycoM+LSp rXIPjziJ20Y1xmf+9aa2XLTujTq0F27lba4VPvem68UX2va3SxnuFp/6wQ269Qxp/O/GDbGnX+73 i7qc74kbPO4oS7/DkzDx7108YwFfdmfmPdAcLObKZ5Nnxfcd85lv/MNNdGjMh76Be0891U0/O/7U k/7xnW+9a3Cfw9FfXhlT+z3wg38/Qab0u6z/sNNfX/ufC7/5zscZ7XvP+bpHXfdyQrzch/387XMf T9Ff+/RV6nfri7Py2Xe87Iv3/dLTXfxwJ787za95+Cfw6ZsX/O2RfyD6K1z+6y92+pGO2/3fgFjW sZke/xFTwimg/SUg9NgfAOLfq8GD/hVgBeKZ8knf8gVg9BDg/SUUbdVW59le0+mO5YEfB+6I5kUg CP4W3smeA8YS9s3fBUYTBELdRunYAR7fCIKY/w3gBqZgDq0gDtJd88FgDbLcDHpgDBLPDXoe4W0f EvZg8i0hEGqgEG4aEUJh5BFZ8E1hCX4PDf5SoTo9YRMKk7C51eKd4UtlIApq4HI1AqKo3gkGoQXq 1A6uYRKKnhuyX3JNyD/pQfhdIexFYQgaHg+GIQae356x0Hxs1yCinx9GIsDFHALuoetZoSRGoCMG FcksigsmW7Kwj5OVAR7ilIYRTh1iYb/YVh6OHyb2UB/G3lvdUsr4j7z0l9pkli6m1nxNFXN1hRnG Ii2snh6SoRjqHSOy1AtxkXJVF2IJTS/OjWlJFzJaIiHaoX8YIyxe46bx3huiYC7SUn4Z1lQEDWpF VzWCDQsu0BayoWPknzfaHTFe3w9uYhFeUBzKETRiDX7RjSn1lXSNlA15YDvSoTyCIeUp4/4Ykpid NRJ/4VdA/pV8rWMjVaQqLiM+biPkJeJC2pVGiiM5DlX/gKKJtZgXomQW/Y0oyth1kcQwziNuuV/1 1WP5MSQT3kuWhVBMYlQ8KuSUaWIhfiBEiVr9rWI4IiT1wVxOdF97YB1SEuU/wI4U4ZXaBZPxHaMJ OuVvnFlITmIWauH3JZpPcplMEhCGcCV1eGVDhqUAop/PJdVLMp5HKpY7QuVX0qJbrkkhaldZuptN VkZTnqUC/VxbgpQjXaSSOdaTReNc5mA2qhoX7l+QveL7pSVhDiFeHmZJ3Zdi0lIk6ddjbhOgwaNZ hiI2aqVEFKRh5uRqUFpigmYtyabo8P5KJaUh8ammXaoOW7rmJ8CmZ9LmHQHkWGnMlZjmDtkcxwDl TbAmvvmmQNVUPwpncMZXbSIlk2XmLHAfc/6EcyoZZ7YYivGjYTnkEiELDF2OVWKMdsqWFwJfd6bF dzYmdCKmuUBScQZWeo5m8cFlZQYTbp5OXTbnXbZmZAaeTN3ndA6QHuVne37DeiJoK56iCManYcxn r4XnleWUFsFQg/7Xg3qDVeplF0pl2wyodxbocx6oiRbRLS6ZrFQnePKnXA4liVKm2CGibhIob25m fe7lem3kQZIgjcWdhc6Vis4oiw4pkOamjUqoUtIkU2ImhoYPPDWpWC4plBJpVnajev4lKX1q6WRi qSuBpRIh5x9w42XWSWA6aZhuJJp2D3aCW3+e5iWyaYgK6IrCaZvOz3oeImT+5J1+aY8aKJ/KB4wB ZDpGWjz9qeBgpaCiqHyCaYb+qHUFkaJOV542UV7q4JhyZEIO6mpSqpXy00NVoyKVp7qdyaeiUqhK 6oWS6vDN3anOV6rG5krZJqTaKawiaaHu6ZNOpqq6GB4FqKSwapxKnZQ23GBW6ay6Ut0kJoe20H95 k6MO3a4mp6juJjv1ppjuQmx2IrVuqpV0ql9ma5r2aYRQqaxaUfIIVHCK67Au1Z+2aIku66qy668q 6aHaASkRllGRa6jM6ZYa4lIyq/6+dquPfuthRGv5LOpiNip23ugdHmy+4qmzuis5kakIGWQ+UqK2 9mqHZGwDqusDRiXFgqrFGluztmvJCqwTomzB3muXrimhKqyhBmuyGmenmumEriy9Jiw+kdvLcmyW CunHSiC+sqzQwuS4Fa3RdqCYMinNRuqOpui+vqnO/gVxYmlPoqtl1iTGuqzMjmkEfWgWfm2dhuzV TmrWVirD0oUjwSw99mzKuirQ5mrTgpO39iu8IlJP9Y10tupR2u3M4mje2lPLvm2p0qp5gpJAnowt Km7ZUi3iLm3Qji3jPqv1OOxFUmQwIqzh2uvl1qzY3uzQ9u3Wyu19fQ3KWG5VVv5u0rYg5uqt5uIs sGojuLYuYO0P3eJusMKuytYu5d5u6i6s3/5tOQKWOv7u8U7t7P4s8Uqs8Tot0ZYtneBiEdlS9A6T 2tYo23rpqG6uxl5p1KrGO5qsPE1vGe4twqmu7qpvzI6u8OIt+5bT4gKv1sav814n/XYvl1qt+HLr 8+YuK/rs+Zbp3QKwwd6vtbpvS13v6O5szcgu4X6Hmp7u+Oov3CZvAvOlNtZv3SYu9aKu9cLvAS/w B88sMFDwCzqwDUJwsEmwhq6wqSZlCjew6U5p9fIt8q6uDYNwDiNwAPNq28Yq+b6sWi4xE+dG+jbx Em8PFE8xoG1wAfPr6lKxFv5vcfl2GhcfYaB8sRj3hgn7cM7y7xinsVo+sRrDZxi3MRxjmxWf8A+H cBCf3tHesPLKocfecaP07zc1rh+vbx47bh+3qAsPcmeR7f8q8olOnp7GkqVAryNbDCAbkiBXshFL rQIq3HihRSJrMtG9bx0PsSjTJSR38mS0Ua7Z8SmL6CX3Xia/coWqXyRrX6VogyvTckmQrAXzMicH syEHXSvjco4dLjDDsi83cjIXZirrMSUjsvw2c3Al8S9TsxBr5i0rsMxNMzb/mzUz8ze7qTNDM9IW bLLGsTrLMQHT8Rmb8jiXc8du8xZKcywr5zrnc/5e8f7Cczyjry2rMj0PM/7p1og+H7SxetwMozAO //M8PzNBB69eprM3Z2QZk/I7N7RDazNEc7NEo3NFI/MD9zBGG7BGb3Q2A/RARzOTUvQ9U6qvcvAs o3SQCrNH73JLT/NViuyWMHI90/Qh7/IxhEMfnCFZbiuPyjTnAnVA23Q9E3UvGPV/8jRn+XRQM/VH Z/VQR0VR6zR7HunIWvXnkKLgqmQoH+tsqaE5j6VXL9uZGeq+neQGde1adNk5PsHSLaaACR1sLZoM T9PTqorrWlAvftE4K4paR/SB6vMK6U/AVrPJgVoztBbQMJspmc8+PiyDEvEtLLNN7NU0Mi9KIzY5 /zQDIzQgPqOM8o9hs/5QfmI2QVKri9JmbIM2n+2zO5v0R3FvaBP2aKd1aV81FDI2L11Z744Ufmb2 mRJkY3Wocb+2bbM0ZPNzB/9QdKGjRP4zaa/0ORe0PWTnSMI2iD73F032HD2uWJl3kS6XO+C2Geu2 ZFBkby8RjYrydgs0fgd3UxXbOXoRrpG3Y/rX0qnQpXrqmRrdgdfcHL83FpsDb/+WsoR07Nz3WuM0 A/8xoKY3UOSRcXfVZKuPQ254rSp3PwOUe5d0g/tzZwI1hSu2iqswhNIpfO3na6PQZZtnbA3UYdH2 deV4gl90BDM0Z0sDVl+wVpsEVL/04+6BYZtUcxvMvqn3LqK3jXtoeP6TVnqeeJCX8knv8W9nF5KH uXactXVHFYcv+Wz/K5r3OHA1eWwBjWr/+IKjeIkPeZG7eIW/+IVb+He74pTTOKaB7movd48fInSR I5w7ton/NYYLOYzfuZ4fOWUkOV7gNW0UGY6l9pkf81zrNaxBF2zhJYE7tl+T9JZntJ1DunCnukh7 t1ei9jaAdU+Hs2mreqtH81aPOazTg6xXNa2vurWwyqSbTVPjOau/+q4X8xHHNHXPNE8K++MYdE0b +6NzBpmfelInBmI4WiFXN5/HzGciA1REulCL+dpqcDsju64bXLc7Ow4N1t4MLk6FZkpC+FT/5rHj urmDL7pne+lNg/7UBLY4Q03KFTaEuTaRifby1ni+iXB35/q58zCQd1wlnkNqpniXT3goIZ1sM9fZ 3o1ExXrHtfhNk7u1J/tBT3zFC1yeFBjaXZ0Qu/uzn5g0Yvl1f+aj7jnYGXm5T7qErxvKr7PKO1pc e5uRpeO+o3q1HyvO/+N58yMK7TiJs/utP3zSk2bQx/HQF9nEWXalFV3XJ7a3mzy4p5DCD5q8Ezg7 0vx55bvV+7yS2zoSN/yk1f21UZu8jYSld/ElDeco9pSwp/a8ryTUAbzIezIoHz6wy71pLPK/fVvD 91uO0qrMk+mO411cI35XK/viM35LOb4YQT44E1y26b3A1/r4Ff4pY0lepDUsK/+857st1dOZpXEY 3kPayjNV5e+ln+/QAr76KtvCtce+xVt34WUc7ku+l23z7hO/ts/I27jP8Dt//vjehoud0de+cop9 81M/2bu9kU+/94P+8wvXUcMbwRk+DXe+rSONcniG+I//7EOJTXc/82U9/ue//u8//+/KnBNAfExd 7gbg5IJR1TpP1gh/MBRHsjRPNFVXtnVfOJZnurZvPNd3vmc74MYSJBYfQ+MFQvkAOUFfVDqlVq1X bFa75Xa3yckSPC6KyUIk+hk2O9tneFw+p9ftd3xev+f3/X/AwIS1uTfBQ0IDELc0jcRDyEjJScpK y0vMTM29R/44w826x8WOTodSUNRU1VXWVtdXWLbGuM/Yss9Rx1rTt9mANF9Vi4hgCttjyOJCZOZm Z6hdsuhnBtEm0mkm4OpBZOVu6nC84m8nU3H0dNDTsWx1awzGWyRiYw9vKHX9M3K5/n2AAQGxA+Mu HTyCaObdo8chnpgnZnoNg/hrSDyL2xQpglhvCcWLHX9xHGZR4L4MITuCLKdQJUiSLU/OpHlEJhGD t3glDIXrmq6bJDcMHbnxYtGjJUsSZah06FGm9YxOHQn1KdWqS2vOC4ot50aOYMFqLRpGiFikaLtu ZRuQp047u0IEQpjzrUKxWqVWjUm20cuye4lhvJrxI9W9av7SJmXalo2Hv0naTJxFT41ewhIs982b 2fHntneh3akV8asnn553LuQc2DXZxhoZY03cDbZTvvcQv24M2t4FvDi55QVOdLNfUrqPqz1GrlTl n7oNv4yuOtdlUcXRlkUqoploN6R9TRyY+i14h7YL554tdTlt3ttd78adm3187r61g+ud/LfV2JhL q7/hxlJOwFjGa+g36cI6sEH5Jtust5YiOytA/pwBDxvxwvujLpnQq0g5h1IKTiKNDJsPo+zwwg2m mBAbMT/9YkuPQM0gm7G/kAREzpEL35sQlvH2w4pH9Yy0sMElaSzQRiaNZGZDXToEqjzoVLOJtVXW qnESq/5+zIe4/BQUzMTuDrsSsKUesqWyJ+0j0LJyUuSvyQr3EwxCJ5s7zcOersRSm/P+pNIPLb8U JioEzSFzSEX5gJNBAJ0M0yw+yYwSyAz3RJKaQzXz8rGdRm3HPLsM/TNSVgvUK9McDdS0VU4Y3LTM /3TEJUPp7JyuND1ljTCcUHmxsppVaUE1RFVNpZXWHglZK1qJnu1jUu3sxDaYJvukrtsHgh1wWFCT JTVQZJ2VZll5cDLX2lbzLANTePPA9s5Ocw0XwiK383XfWxMD15t3jY2LW3XXzbLQroqtV1HyYD3X wekeDsVW47yTb9w4/5210XPyPXJgPxNm4thBTD514f5UGy7YYogTXfllmP2TstKP57OUVxoh5U7e W0369BmHkRVvrhEGVULmpbms+enmoA5ZCcg2FpZiSMGVkE+fAcb1QnKJpvnkg5HWGFF2vfJibbbb 3kFqm6e8LjNu+/I1Ohyt+2+udLv1WWVKiiZ7KxAZcftwxBP/Ae5YoQaccWUfB7umwg1X/HLMM0dH qccJS2psyEPnB/SUQ0vbXtJFfzP1wB1U+T2OVZddaXQJP30c1mdvRfBLXqXlwdh1Fx51ySmm/Paj h7e9eEl89wR42JSXvpDchV6e0Op1nH4m3i1xnh/ord5+fCO6r5qtyokn363sk8m5oAd3XH9+d5lv H/6V9HFnnv7A7xfk+9FtDWf8I2C6UEaT/CWvgOIw3wId+LAGGg+ByCtb5ix4wRS0CygY5GAHPfhB EEbQev/bn6hYVkK7hVCFidOgLFb4QhjGUIY6OGB5EEHBnqAQbazw38paKCph9NBpD5yfCIVoNBKe kBNH1AMTT4W/lgFqHU70ChEJaEQdGowuOKSDCLfIwywWJIocSoUXfWhF+mGxfIbQ0ho+UprUJbBs YgMjFJnFrCCGsX5oTGP1TsO3X+mqRHO7jsKwp8OINJFnT5yXDRG1xyqSUTGVQNM2vhE9yVCRj6az X1BQJJSMgG0lk/tk5A65xAEuQ2JrrGOt1nhHQP5tDUxq+tekuhZJTNytT40bk5T8kSl1+U18u/Pj TSJWuhGaJGLHNOTSzAjKXf5ulXAJoqQyCUtJkmxQt/GlmIZISV7GrZHdfN4/2kHOaOaxhlrsG0WQ GKSzNTNlTDNljKCJor/gkyVCM83kqEbGwYzyYIRy3UpUEhZalnKePzTYQcuET6EY1EUwCo6usqJM 8QlURSN8pmTCySmPYiydyTEn/BaJSWJ2cjQG5KeCkJk01CixidXy12Lyhh/3FCan74yVwHRGvVy9 ajb3sc9OtYdLUrUJQXtSaqWM2pAleURWdUsSUUOZCRbFaDD3FAmMtgpKYAyyoGH9KmMOk9Wrtv5J JJ0xCuda6s4yFnOlZ5EleZa5PznmkFEbpc48mapTtA4zmVODCt6UFVTifK6Sbb1R05AKxAF5Mz71 2SdLoJotoqI0MGiKXUfLdxWzJlanr+HmhCwpLsreJ7T0WU9k+ZnZ1k5RpXNd61WtV1usLSimp5zp pS7lrfX8dWc4kmBP3wdUzAo1tk0VKcM8RK2sjbaok2Vpr2C7S+XOyrPjlOpULPs14abJp2PhLN0M tNq/XsOgntJUd7+rxzPWTm2DHAXfjgnIAPJWfaJl7VJxOq6catYgTjHtQJPL3+kydzcLfawWLxlc 1w71qUe17lP/IWEAa5Je3eULNw+E4aH+9/57Cu4wfGrzWuuGb6cew6pch8iiy/qTMl3kIvUAY0+I +hXH5VVoNFLFWIrSmKCb3SdYAdsjxwqqSsVN8o04p08iM1jHnnowX0tE4d6BVssiNjGEC9weDL3I vbwBM5iNQ2ZhnVgTakRfjf2hYflCUaRzfjM2l3wZaYpxVMGsbu+cbCKH2tY9M6qsjvlqz6ki1KZo dbKRHyrawspvE2y+njP9t90ltnKRdK6nkidGGnnOlStb2iS94Ebp48l0v9+BLyMnPcY7y3bNcHZc 6FA9QVXrj45dajUkPQ1ZO86616WudJy55+ZOy03TwmboEdTZ4mETG9frFEheaRxtY7862P4NdnZc sb0aaU/v1sfO9dFmeG4tNLud6GZ3u919bmqzr9wVfHe938btddtb3/vmd9viDRBr27jfA4eBug9J cIQnXOE3+DdKkL1bDX1b1NA2+D+3nUtahxvgLr5WxqEpSER6/LC8vrgspPhqifdZ47obt7kxrXK7 oXLX1ZQ1vgdXc4ynfOUH4fhM/bnFees14sumuM0tjnM/63znDOw57pB5w6Bfe+ZxLbkJT87soi99 di2PM60DXuepyxnpVpfk2Ckpcq2Xa7aOTMbD8zt0kpud1LFGOdbTrjqurxrq+tU13Gled6M/Xe6z VPrdWb32jqf868kmGNFzXnHBA/7xhv4XXd4bnni+K5DVjk865M9X9bMXnvIluzxyCZ/5Ofqd6oPX xtWz3vnRQ87y2U4i6oW++bhL3uRl17330B771SF+2pYOuehdvfreg5vudoc98KU2eyH3L+o2DvsU QT/3TzPf98Z3fkpL/+bQ2/7aCyc/CTyPnfKnX/3rN+zIiw1yVLJ//edPofztf/9+f39zbg9143Ov feXLvtfbvu57vqYjN/GjPtUTu+TDPmBjvUh4uQIUG+FDQOKTuQW0PgiUMgGcPA+cQIuBvnfgv/hS tv8bwAB8wAY8PRCEGRHkuekDuwzUtg3EMhUEQOlrQRc8wJNYPIjDvb/DQZjrtutjQf4drJcX3L8Y ZDw/4TwCDLzPq8HaO0Ik5MFqI0E9qz4aXMHW4z0hbJ7fo0IpZKU2W8IfNMEgREEH5BHuS7LmE0No sUJ5S0AZBELk+0I3jMLBUkMjhMN4kcONM8O3s0MGxEMOxLIwHMI+9MNISUKmE8T+a8IT/ECyc6af 40MwbENGzEEDez/swEBC1EAuzEM820NKDL9NZBVHJBYsvCYtnLUiPDjzS8QuPMVU9I1VVDs6jBz8 Iz/L6UVgDMby079H3MWYEkaE+8US+BVkbEZn7CBiZEVILEH/S0NbfCXcGsW208Rb3MZo1MUL7K1X bLFYrB8kK0dv7MYvyUUKNMZBRP7DO8REXzPFN3xCddQPdoy4aczCGYTFMfw0WiRFTrxHXAREh9tH V+xHcvzHjwrIQ0RFggSNfDw8d4zE1XFCiKS9eszIiOSkb2zHcNS7aozHa0SNZyvJjuxBg9QHH3zH kSxEeVyXk9zIlBw+jQzEiqRGSbRGmnQ/hkQbbqxJUIw+T4w5cVRIjEPH49PGvRPKMvxIfcxJfgzF LTTEpbTKKXTKVINKigzJvqNKf2RKMZpJe9RKC7zJg5TKhATLhRTLTCJLjjTLOezErfRKzYNHmERJ mfQ2rJRLcERLlmxFbHzGfdMfwjxMxGQhurRJ+OutxKw3w3xMyZxMLOBKuUHIV/4ax6T8yYnrS9rx y7kEzBHEzG+6yEnsSZPky5gEzb8kyrr0q0tzSGoiSdQcHbgcSNZMy8U8y8YUyZ2kzbJ0Tbf8zNwc TcskGNKcx5cURc+czeH8ENksTib0Scb8xKNky818Tne5zUWUzmLcTZVMTmgIys6sytUcS9XUS+9E zuMkPbtMPez0M6VEz/kEuvU0TvC8QvGkP54My+bczvSszft0T9GEQbXMTKSUT850PfXMygFtTdN7 zd78SrxkzvN8ywANzgftygJVwgMtzQQhz0vUUPDL0LjcUPbMz9Cc0LtcTvNsUAytT+JE0RTt0O+E zeLTTAXVzvKE0Rml0eBrz/4gfc8cokwjPVIkTVIZENIQ3c/5UlIojVIphVImJRLB5IopzVIt3VJn rNJXaEnZaz8gpbxCMsvo9M1A2p4yHVMyFVOhPFMKtU5xc1M21bo1dUo4bVGjnFN6qtOVu9M3FVE9 TVM+lUA/xTs6Tck8hU8WHR5APdQ/TdSOXNTba1TheVRIDTdMnVRBZVQ5lZ5NzdRSC1WCpFSpI1KW k1RR3SRSvUdTVUAcHZ9WXVUimtVufNU6tNRU7VNaRSNbvUVcnc5ffZph7VX+KVZGDNYzRD8ubVZn fdZm9VJXABForVZrvdbJlFbvIz5s7VZv/db701YwOiFwLVdzPVd+E1deI/5XdG1Xd31XFVLX24RX eq1Xe7UgeTVRQgVVVTXWB0JWP1RWl9xTfuVVf3UggIVDgbXIhK1Cgz3YAmpYKlxYndxX5ZFYiHXU fnXVTq3UT73Yjc3YPnpYdaTYqdTVrQtZkV0fjNVBk11LlJWdll1ZRCXZW+3YU41VNVVZmt1ZmwVW nIXVmK1ZQ+3ZOPzZVHxZBNXZQlVao73Moo1Uj0TVlEXap71Unk3aoM1VZr1Xr/1asJWCfL2+sC1b sz1bHBhbuUNbtm1bt0UBtW3At51bup3buMXBus1bvQ3bu1XDvf1bwH3XvvXRpt3aq33EqNU4p1XO BZrZw3WcrN3ExR1PX/6N3Mcl2skN06mtVcu9XFvrXIU13GVtXND13FMr3YkV3YGNWNQ1XWJtXZf1 RStyXNd12MTVVNnlXKut3dPd3YDN3X+FXd613cwd3soTXuN9FtpN3glcXuaNGd99XjF0XunFR+St XuejXuz9DO3d3rTrXu9dntsNX90dX/KVRvM9X9aNXvWtEfBtX2J7X/g9yPSdX5a9Xvslt/rNX5/d X/6dVvz931ENYAEOTPYt4Eg9YAQOT/9d4DoLXAiOYPUDWgmuYAsmOAq+YA3e4HajYP/MXwK+SvVt YKxtw+LlWBKmx/BN4ar9YPsNYfqcXxaW2YA84ZJVYOFs3xmuWReWYf4cjlD43eHjNWHVlUsYjlEf LmKH7eEg/uESfWEbtl4iLuAjJkMoVmJ4SeEozuApBuEtlsgaxmI8dWLq1OEv5t4wpmIyTs0r9uC2 5N8qdk4zFmPlTWMBjmMAbWOt7eL/xeMeJV8h/lw+huM1tk0vpuOjZeI5tmM9llxGJmQtRuRSPWPH iGQ1tuRDduPshORHbmJJVsVOvuJQHmFK3twd5eRB9mRNPuVDHuXzDeQwTWVRlmVS/uRGdOVFpuVX LuWnfONW1mVA5uWi7J9LxuUVFmYJ9b1iBuZjtmXoVeRaNmbvhWXGweQ+LuS9bORkleZgtuYkXmVl vmNsFuFdduZ15P7mZkbn6qXm3oXmclZn6WVnA2Tmd6bn7ZVnyLXndNbndUbm6jy7ZXbne/Zn3vwo pxPn89ihTN5jR5EUc77hhO44SAbnhoIyFe7AXH4ui34Xgi5AfH7dEAEOM7NiVG5oLxMsdlJlhrYZ N7kakr7lNgI5NyqVbkokcMCvJrULxSisbNbPFqm/W0K0ObFpEvHjdHTkkP4vlE5piOGZfvElkMET cvnkjc2un5JjlHDqOCGu6BIZC3noFAzdpAaxpeapRgyWe4mtsBkvhigOqn5YqzYqrGZJtG6u4aow rumZsr7RbTamHcvGPFbFuiantK4q4LppxPVrKwPsPz6IwT6pu/42hlv66l5GalUy5HjBrLDZK4n5 LW61LCwWXpPh5agaGs7m6tOWadAOT4oetTJeR83Wa3zZNJ156jND32DiHdKOba0x7dk+bOD55+mF Z8Jx60IiK88wk8DS6pH60nGOYbcwbrxBbmnJN6uh7GFOXX5GH7fmFV3Ka9kQ6e7GbYEmlvGmEO/W 6vA2bJdm7ZU+RswW7ODGkI3RluGCndtWO9Bh392e70ZJazqxB/xub/1s7dnkaLBWGKIOmsJe7qhY cPIy6iJNGFlCYnmD8P/GGAfvDJoq6uc+Ue1+HtpeviSmGW0i8XI2cK/h8L0+ul8WjjuRNAbtZhXf aqVqbrOeZf4Yj58Wj7w5rnHY5HEcv7kXny8h37ME/90kR2NPypaAgm4d76UHt625pvH3Fqcex+ho bnKohvJaBnIvJGdB1qeUiKeRYXITB5yONsdvCagyPZMlr9gQ50VnWXNQ8+8RH7Q4b6cHrvM9Pyc8 X6UJq+M/z24wdFTEnhrJnqZAJO5KTvQVT5JUcl87x0lfxrut3rRcKPQgv/TM5jRvmW5r+eia8eYW btS6YTEG3m4wpm5tOjFOZ9zhZnXIJa6M+hpOcvSCtHXswnVCB3MSIh/Nqu/qQHNad1/BUrVYB9Ej NHVMD/SbOvELP3buhvbr/pkQrHTd3GSZhfRMl5MsJ29Pl/7v/P52ts5ibTfg8s5nMu8FbpD2Rqf2 Mmx3FhOYD6/Rvl73gXb2L7/ycL5mfk9xfwdohNZ14yX1HZT35JVwFLdyyx73jIb4Zgb2Lyp4ha9d hM/2ix9ehtfyaU53/OT2KBf5fn94kvdkg+d4kDdQia9nfX/ejIeglF/4e6/yiR94Yrb4l2femF/i lu/mmcf4lffQn9/nnaf5ZXfvk4/4pb95k2flkYf6ks/3ov/4gHd4qm96l6/6eB56vv73kuZ6mPd6 aTz6sb96p896qUf5jTfdnkf3thd6tLd6ime7sNf6fa976Axosed5sodQggf4oHfdtx/1wefdjr/B qVdys2H3+7nPe5yfJb7He+wt/F/v+65//Mr/e5CkfKs/fM+1/ETG/LMH/csV/T+Me8Kv+cBW6acH +yL3/MzXe4UWfNV/XNQHZQ7efd5/IS7ufeAPfs3ZY+EvfuN3GwdOfuVHhQIAADtQSwMECgAAAAAA Sx0KJ+M9MHHkFQAA5BUAAAgAAABTUkIxLmdpZkdJRjg5YeUBPAGAAAAAAAD///8sAAAAAOUBPAEA Av6Mj6nL7Q+jnLTai7PevPsPhuJIluaJpurKtu4Lx/JM1/aN5/rO9woADAqHxKLxiEwql8yi7wmN SqcOAFVmvWq33G4q61WBw+Sy+ZwYo0XqtfvNsLbhX3pobs+f5foV/ieUFmQwRHjQ9mdIk9jXqMXn eMJ4GIcAaQiG2DG5wUl3GeAZ+QI6yiaBp0mZaQlEmOmaNTh4KAv7Gkgh+nbpaqpT+vvhmUspSMuq CAm6HKroDD3WDI3q5usbil34LGwT3M1BLEhtbFkum32Nvv5sqz69uyuF7kyPaQ7R/CdNXim/1w9c uGoL+Kmixu5HvXsIuSW0F+EfFHfT0mmLuPBBsv4qDE198/Yu5D5dGsTFQVYQG65XK6PFcshyJb14 1mCSY1ZhnbaL9dxlE5gR2Cpz/AZmkIgFBlIft1p2DKiRz8NaGYsK/LgoDVF8MmXu5GZhaQtapEaJ LciwYsKfUDGQLZZrW6FtFlvVQlbsaQ68fFUaTLv1KFCCesgOA2xvrV7BT3H+5RoU4cbIj5nevEy1 arSujAdr9MwYHs9lPDtpPd24X+XNrFMP3cFqtSZ9iEve3QTIcKWweXdPODsRbeFrClfF7QtxJi7i 5SLvZY4pL8p0rGfZbugWLGaSn5sL/10YdaNgslUHVjbd9WI7wDmqpvtWHWV8O0nLsRUT81fNPf7V tA+uHRyxnTeffwQ6diCBn6g0AizKBdWLS5JNR1tRitGFWDIVtVXTf/PU52ByFt0XH3QF9oYVaOBp pdyAgGEX3UtVzWRdcz5Jo2FrHNbkgVUqmuYhUIlV15CLQ76mzGUi2rgZOy3a1IeH7QW5Roo/5nMb kdQ5pRZ9DvZnjInwyVddLAxSaVmPxMXHUi/35cegI1Ze6d4NaIb1XXg93iPiWg9uKOeOAOYpBkh3 4llclIctRCNtSdbV23iCDgqZH3QSyt6iUtUG4aMBBnooCwaWdal4eUi5JnpunrefR5NGMdlYnb3q nKncQZmdpFmVimQYc5qA1KiVDutdTomKFf6qUFgki8av88wQbJZkpirtMVziqNOnhF0wyVI+5sqr nbTCCm2uUxkYYXTnNNkOn8Xeyi2WEn0bb7jiMitqufXqJCN16c6X4WidzqrLO06xFRObW+JXL8El 4BscxIUmta9rTq5rlaP0DQwudxEemWSf7o5L7Ir27ilxHRQjurCGL2ELFoX5Lexpwx4X2e5dolWo 27aI4nXtmwjzxV+cn5D8RMq+GXsFshUbyWSY7DJ6nbkvavYkk1MpqrQk+tpMKdi/Gawjjo/OwpzR GIV2taPHZaZPzwIinWYMXXdxt93XbY11gI+ZyDVAK4ebt1JIYElz0JK1RGFTgZtR+LtM9/5aksth Oo7bYIxAhPjJLAqut2kKWl301FKCtvmrcnvuLLmDd3Yu45hnHTvdDXir7Z4Tew6s7TxEnjt4pFFd u9lsoS376VV3PvkplPN+h++wfW0bPFT3R2KO6IqnfLwwyw6349ahKSNwJtVplvTKhj6Q9n0Xu7X1 nC9vrMAunh3Ypg2WbPLSzIMKOqWgTGrHIxPCEga3zBzQKN7b2P1cYrCL3eEgVZgWnPDjky2pD28b xAHwOti/D7IMTxbCGQFDNrJFJep2DjTd1ErnKhGqUIAoIBsVcFdCDW6kPuDb3e0ogj39mHB+jyvD B2XoumeBIBXiKM/7YJg+JGaOfYT7UP6DZlPBpjBsaBDEXwwDSCp7SXFwRHTBGC11RvqZsQlsbKMb 3whHIlylS9Sb4Or4h776gRF6R6tZGAHGCzz6L3ppdBgfecRFcQnSCxb60o0YNhq1+WOPh6wSV4BH r0KqSWYSxN9qhEfJSgYwVmtsiyYZGMSHNAonC5RXKEVpxEvWYCSB7NWFygYZmpxyhLBsliyXlcdR XlAqkYTJHScJuV7WMmc07I4w8ta6sCkzlphaXySO2btdNm+aybSVrP7HTVd2M5zkTEkFy1kNbcIL nezkkCSTxkIPfm6c7Sxnv+bZNHnG83kcrKc9h1XGpO2HRFka5nLIlq2hnck8XFCnP/4ZeRqHFqdC beuI/DjFt8VIdIUPnYgSyCjER8RIf3RsF+1MV6PtcVSJHU3iD9/5sJJutIWvoePHUPi+HPIThN9s 6e/umQ9obix4P9VimYyXOH5VS6EqrWbdfLoXBfavhliUHCLFlp04anWrXO2qV78K1rCK9aMzm+rD TuLNZsEUnFndJ0uhqs9W+syMaa3nR2ZKVLiSAqhm3R+m8OorqACWp3olAe6outLBOtN5VkXmIn9X 2B44TWV+syRb1/ZYyimWsJGNniEnqKO6biGDLQufAseX152OtrPTO8pYMYSVzQrHTyH9G3/S+UrW UpGXNQwmRF/IyuNQlGTRhKdu4/6K1SUKUrYTtWhIcUpSkjA3s8f14TYNO6fpDpW0O/xSaYnL2TpW 93V9PetlGzoxXeZ2vPlKLhtEod3GbiKgjiVDfC/VRvd6trzsLO5T2bvf87o1qj71r2QBbFj+mtNS 6/SngSGLYMYKeDl7VfA/7xutUI3kvr1DBVnFO0i7qk5Jn/mk7kioX28+OH2Qyy6HLcMJVgIUO3cy n1xUlcie6FiuVaRm8NYaTv+O703foFFBefszThkzp6lF3dx+CNXiSlAxVLFtx0gnmiW7DZtXiq+J pfpQKY+Mymcr32dvdlvnXDS8gWpxaO1SYKRNeT3FO/OKGqXD/JX5kC+m13r6S/431KJntsmzc4Sv zEgK+lHEh4oWog8tOvsOkr7kXDGUcwLkAUM60n08YZjZvNtNqxG9C/a0g0HdTJUBDp0Yruqi22np 2VJ6hl7TEqwtW7NZczPWEX21hGtt6n+6GWSkvHWQRgWxlGXs1D4GWLEBfexfAru3Q731Mj31YshG G1fmVbWvd01PVTyb1ZzlXLIZnGNAD9ux2Z7etuNCWWqvtNK4Vsi4L6xcpwZY3vJVZqvP2W9wU0nR 3RY1p3+72HYLxT9GcKnBDV1vhUeVllOQuOboOWCLe8Od+Xz4wRMdTI3PkuM39PjHAzvplsa2Fa/9 z5RaLvIOG/Gu8yY3xVHN0/4pFfyZjpY0/PRN75tr+MSjJvozeezbZgtW5SRvMpJTPFda/wJzE654 gmqO76UNfYpF53pKLM7wqDe0pKINctMh+I+euTxzkQoqwVme6dUCouod93XMyyV0ZmJWWCdPstNj BfPAh/XSIR67vQuf9a+nhyYxE3x+YbR30WKo3ljHeU/HgfigE+Teh+d719EM3lJsLu5yz7zIb87o zQc82Gs3Cud7XXbLj1zT1DVu5e+eFJO0PSoMRWVouDx3zwNd6ZLfw9tX30tnbd33jzb68H1u+ogv NvWY/TXEq7/v56M8+uueFO71dj7rN/+6Uq888eHe8Gb/6vtlCX/2x9/g8v7Hfvvav2rSNY/9fDMf 6hDXeCJi7meZJ3Bi53XXR3fw53SlV3/2FU3sR1fup399R37OZ37Qt4Dnd3+PsHu1h3yqNX8IaGEE uH8f2E8CaHxPp4Bptz+UtnwSGH8USIKkZoIY6HZu1FqDxhnIU0CXE2OQN3d+NYKYlmDTZ39whl9w BBvw1jc5hCCgZFW8doEZ6ITvF4MKCGaZwi1IaE3Zg1KqElxNlFa6NoEoCHryx4FR4XiPd4XDQYZf d4PORmLbIYcs9HavN4YFYz4dmH8V+IIrQ3pFSIRo+IZbNGSWoySZVmQrtG2VA3zos4i0Z4D5wlfj 0YCYJltKkz0floBSGP4RYFWFnPiIIKGH4RaC1qKBXZOI3BOBbrGB2xKKURiIyNUNECiIrBMQc/Bs rQiLbhhpTPSH3bKK1tRmf1aFjXhxwvdtdjiKM4g4FMd4nNiHGzd1gMKMR7Yru7iMh/eEO6KMm1iN HPF/HQiMZiiNRydfafeH0+Y8GdZYMKWLfLiHvIGG8jCOMKhIHnF8m2iMXzBQOlQaRPYT0/JO1Bh7 3ZhzBXgs0eiNkHiP18R9eKhPw9Ul0fUnb+aBi2SQreeCeld1r0hgTvaNB7MrXOg2Q1GSkKItyrdz kQiNIOiRsqgrPwiL+0htTbgha7YkGyaCG1mKBwh1L9mQ1+Rqn0iTkv7Qj3hWU16UNnToYS1nj3j4 Wj4Zj0HJYnbHG9MlMVD4iU8pfkHIf+RFia2RCleJN+koGOSTavxGjm14jQ5pSzNplkeHln+kllx5 h7N3FSpGlrY4l3SFbsH4eXjpltqBi3t5Mlp5hnYJmF7JliAWJTRHlHE5dWxWOJgIhAgJk4OZWIYp RpSZluqomD0ZamGpaejogGfZlXUpc4sJgo55KthnmryDmNnImFTIkwrZlj+CjLV4mJ5Jl6CJma0J lnqScFl4mm1lm8C5ksH5laP5mADnjUU5i745FpLZmNe5k7lZlTJpO9Ipl6kZU96JnbhJnsPJhmNp kNbIK7N5UGk4ef7LWZvl6Zyv+XM+2JSyKXti8I6heZf96ZqaKZbGiZ9eZp3+OZ5S+ZuK8pb22YnH 2UAYp5y3KZqfGZbEtoziSaGINy/5+ZeqGZ8TmqDDGKDRWaB+mX9iiE8W6KESmp3/yR5DiaIsV3fX 0hj6g3QXWXIdyp9TWY4ACmYxqp62N0QLhEEWOTolGG9raaDzaY7B1qAz+kAL1STYxJ7meZlKKp8Z Sp+b2Z0lenlQE1zEmKKX2F7JeaAmahYEB6Qi6VE2tJRJeaPOhXBJuqMIiqau8i5rqkGdqacfSafM eaaXJ5RGWitPypccuqJXWqexSJUKSoxxiaFR5GVlyprNqaU+av6Eljig7smpnTp4WGqlnSYokOql /7VOQqOiEdqomfmc3RIspXpgV2ajc5qoPfqGeMp7AipQhCiQipMwpHU1SFqrgnmrcgJfrKhNJQQ1 T2RlTcVclimkxeqoLcqLTLEkM2JmLmM9VyeDf+qn0tplyPostJWTQ/ogOGp1OiqM6zqtPJpFu3pa 0OGmPORd6PpWw6qd32qsIBqk+IWo3jqEpqqvmIqNkeqQGEapEBar+Oh9ruWgKAahq6mwEyuiqSOu h1qoAwSfAbuwFNuk2LinVURmh1FjCymcoZqvxJmx0mOwAPSDxARJ3iU3BpRSBjWJG7uqOXsqBGmy LSsp4nY9a/6WOydVO9+mqOzKqjFpSg47oLlRkUCkULsRCOcCNIR6tAObtDvLpRfbmxREkZWVpzah MXqmrlirs6I6Y0yLsZgHs+2QQasjPgjFXf9Ktyd7qZOZmP1KJ62jbJb6oSjrok/Gnerjs0VkpyxJ m34bome7INposiG7nnUrsapqq0irtNeqq127XmZKrJartRbKiE3bbX3qrpybsox7bWEaumvLWKVh uqAKuLG7pUZrqJobsK5bqeBZuWaLhYT5uJBbKlUqNenJr4HZubz7okt7FoUbHlunhLr7urJ7t7Ob opnLpwVHvNS6qHfquclLeGpru5eZvaWbu8ebtWgbktV6vf7ot58112gJC66o+7Fcu74gW59Xy7Ee i7yC25LvyrpbKb1/y6Tmy4YMCZH/m7cDHL0KHLi9C4+8Wb+KCHPbi7iLu7utmr7qK7Ju1YLGW76n e8Gzm4+aisBRg79LCqgEHMIA6nKw2rwcjLNZKsDT28BXJWOd4MKvmXf5W8EeXMMMzAtkh8MPq0da R2EknMAAbLc0HMDSR1jMq8MwzKD7tJuB2sOC2r2NW72rG75OK6+3wnCeKsZiHK1Km6nhkMOZonvi qGYUvMR7q5tLlMZHs8Z/57sp/ME9tp1JrMGRq3tFCVQaCbD4OY0PfJ8lbL+MisIzDMfTmbgnQcTS pb1WbP7IjByuhUy6/tvF/UvJSqy4l7ydwgvFajzJi2zA0NuZQoJdkTyFisyirrzA/oqrODfKdFzK MnzKsdzIDJsstZyqK+vJsHzLPhy5jhyepcQovVpov3obRuYVjivMb5zBV6wixznHpshgmxI/c0gk deZnPPvInCzOryzLAnIE+omKMoOtvOol2TpSCOS4//e+eAy7wevAe4WKW5FRJlyuI5uIAQjM1BzM pgzK14bPyNy2i9MyGSOzAklKoie1qEy+9VzOBr1GSMQseViH4TzQv0vQcYy+1YnRlIsRhamKFJ3L eVzM/HvQfNkEHe3RMV28IM3SFy26tgLQn5zIH13N9/5s0zN6uPUFtqZEk4KMr3rcIcvifyQbhinJ xvTsxiCJSJHjy+9lH/4o04AEzQk505VMzrvsS3wMvk91kmJaxNw4er8Y1Z3sGdlm0iJtRUzmL0w9 qp3zjF9NzPbsYNecYCU5ssjZkU9tyQLd1i98QcfcpjiGZ6dDi2vN0V0t1bbsQlf0rGg0zJft1Xld 0TfEqyGSilY9dpZJDBMM1aW92emaUVf92H1sz32JxZPLZ6Q2tW5bs6uNzRHs2NJM2BcndzpVOpms ybht2iit2WCdo0zFKlQnx6yMW7qc25Bd2IDY0ps83M+N2ZHNgFJU1Unt3NW926q818xd0hJN3t7d 0/7hfdPEbd46fd52xdfcrdLdrdvtTd9cLNyDjd/sjd28PV/iLU7xDeB4TdPRvUnpbd08zZmV5N8D 996W5Nrwu8oNTr3gQD4SDhAVPsYZruEbzuEd7uGHk9Vzg7D8uN0qm5d2FOIivrnDYOE+TeEoHre5 FEUrHmH+XW5vUVEwTS4jbnK2LU07fWRvjRI2BN+//HDfl10FHuQtBNw7TuMIdomdzS4tbhjX2kkt LkA83uOSm2+3dD1U5Rc5PqtcXiha3uNkWhfHk0LZdCazs5QljndPDmBoXpidZF5wfuFyzl5oXkCO lOKogefJZOYmZ+MojshWSOhhhuWSNugeV+hjXf7li15yjX7k9DYickTmEaPn4/XoJ9vpwsvEUG7p E/1FEVvpZhc+Oc3CmV7eey5s28yPfKLMC21aOWizXzZYnd6x09QiuDuE2vwiN+xJGDWHkHncW67r FQNFwKLO9sHOPOjXVdtUmd3E1ZXsLPOm52aSwcrPYvtCCpIiM3XtWQw9PRjryZwYbxvmBvVdOH6R GzXu+8tHFgvEAp3kDpfowpbSsB3gRPHh/w7wAe+J+j7NPxvU3LvlBK/jKj7O9Z7wsV3w8lSy4Ziu D69uQA7CQLLv8mvx877xojJQ9OqPOBTxod7x5Y7x6+hCc0a6n33sJ4/qC9/lKLmE3C7Jpg7zydgn 8zOvrGNmtSW26TmP1KzOm9n+MjgG2EYu9LA0vtaF36BuwUsP8UQfzW5XPUEv9a1t4LSa9f6G8pTe 9Qr+9Vgf9gV9391a9kw/9jif9oR86CLV9jq/9cIa97b484UN9nXvx1Q/rmSv9xQu6RCV93+v128P 1IR/sHBR1A7hoFCP8IhvuMJefU2OXoMP+QyvHrS+oNbM9wd++eP6vDAykTkymZb/+Q6uZzsUoL59 sH5/+iJVGf+4+tU242z/+qgP7aY4JGH3nbcf9/Hu+8Ev/MNP/MVv/D1QAAAAO1BLAwQKAAAAAAAI XAgnDKra9AQLAAAECwAACAAAAFJPUDIuZ2lmR0lGODlhEAE1AYAAAAAAAP///ywAAAAAEAE1AQAC /oyPqcvtD6OctNqLs968+w+G4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofEovE4AiiRzGYQcIA6 pwGl9YrNarfcrvcL7mqk1DK5nDlb1FUDG+17wydy+tKNnz+j10S/+ndWVxf1QkhBdqcHlMgg2Fb4 6BhySOeRWLlY07jA9ijZSXk5VgiZqSnDqeCJAAXKd2fFl9fnqharKAtou7qha4oaB3u7GtjqF5nc 5hopJamK55xXGlyNPO3GfH1MPW2r2xje7RwoKw3ZbW0Nzd0+vq19HT/PTRxNu62+nv7Omi5+bxk6 eqUACgTmbswvfTnYtQLXaeGwbJhomftHceI5/nu+EjLcxCjFKQf+PtoY2eIPCpST8pmcwRJVzF4u X8aYuQinR502QfCkqGgXpl8SIfyk2ZFfT0McntU75tDoh6NAl4JMiq9gwphUsTW1epWU1rFeQTGL BWjUVLA0jmJ5J5Sjt7QCu6LrYJctBrdPydY0eHatYL0w+Po9V3Og4nhfBxN2YTirZKWm6DHGivdx 4cbeiBaTuMSy1zQ+NTPVmzevaQmqmaRenZLwa9grWiOZTVskot2HqMplXTq3bktIQzXo+gYlbuEm lBtvCR0z5eicmZfIVI5cxoOwsvlBmyuo0Ggjl1tPIjUg92Rm7y6WBk2cc8fnRVQKV0vjXYNz/vEv lL8bffUFR5IyZAVGzWWAuZfgeumpNaB9D4q22H4G9mdge5c9YF6EEJIETi5VKYjWd4iRcwtEDB5H oIcC9tShi9ItFaOMpKHWoo0zwpijjjc+14ttu8gjHordPZiZj9Ulph6Bn/STIZJLKnkBIaog5iRU UKp3X49UVmBlg8tsVNWQ24mJkGIVjlbclF8GCB0n4HG5pnv/HdkZLuIB6eabwBWI4JqW1aKSmley +RufO/oZQW91NQjfhSsaKmZyTHq0Fy+MwskiNnKeWKeG7TC2IIdJTrdpm8+1t1+IQ31WVol4FqUo mMkJKVyMuHpJXKep+uqLILTugNOeEf1K/h2NVYKJrKo8MrtGs5jaxJJOu8qGba97SRtXGN5+C264 3nK6LLcu+mZuhHZdm64ZorSb67vwwmYbu/MeUe+9puFqr75C8Osvjs0FDNa1/RJM7HAIm2TvwQvf 0PDDDCss8T4qOFzxTbVlbDHFHOe08ceaYIyxyBfHZvIcJKesMsosu8tCyS9f5/LMTqxs882n5Xzb zjwbIbPMP58a89D4+mz0v0gnHRJkTBMR9NNDRC31Hk5X3XTNHIM71bd/ak1wFsAOY6wjbyFytrOf hdFoo15f8ja+ZdcKq9mqgRZRoW7rjWjarPnNIeBsAjU3DoUnC+J3NIuIJ9yvDJvG3JBP/ps3D4eP 7TZdNHunXXMbbdi14tr+3ZBY0a5k4sFpG6wpuXbAbLnaJySKXrnbTiH016X3kDvEwiTMO1u9S+l7 8AX/rsPwph5vfPLIK9v87rEzP73z0T9bvfTAW6V8gdt/jz34xWcfvvXmi68PFydt0Rb7m7hfDeST ez7I5fZJbn8S+Hev/+u1ldev/GlOJABs2elQd8DNQQuBC8TdjxSYQAndbmATbMJPdnVBEmQQgrbr WZ8+6DoQju5FEYQaCU0nwgYuCoUrfB7RUqjCB76whR20mrxoWMEcfoiFO/xBvmYIxBgGsYRDPN8N dXjCtmkQhkhEXw+J+MQRJlF3R7we/q9CGEUqXlGKWTTc7HhYRS2GkYtTDMsSZShBKJbRexx04hox N0bixVGJbTRiGmt4Ryy+EXFbfN/sisW6NQSySoO0XCFt9UdBJpKQizRkIxHpOUVGkpGTJN8Z1dhH us2RjRS0ZO0wuUdUhZJymUyFx8hYykulUnarXNonhZhHOnYSlpuEySnFGEs55lKWdRzfLPXYysHV ko/D1BgDaRnMSRWTlaME2yuB2cyI4fGZ2uulLpcpyi5y0ppm5OY2L4nKZgozmUU7JjS1qUlyKlOd JzNnONHJTHimU5wh++I0d/lNauISm1ezJyjlSUp6StOT+FyeP99ZxHwWtC235CU4/vepzoG6MaIN VSg/s5lQW7oTotGsqEF/Wc2HIpSJAQWoKunZzoOeM6PxZOk8TdpPkHIUpusUqEcZulGH6vOj3oTj QjWq0pHisKUkPSlNyxnUmbq0pEs1alNj2lNiJlOiKy0qVEWqVKvW9KhbfaozfyrVjub0muy8KVep qlOwvtSrSJVpWi+K1qwO1ZhJfetUzRpWrqbUrWQVa137qle8anWcfuUrT7EKMXGJK1OK5ZqtGhu3 x0KWbVOzW/0EOE2+OVWNvZkfCB2ls+JYCqM6fAVRaRkm0jaRsPzjYUlGI6REDWKnynztHEFrQVXJ 9qG2ZSpnMQcwn6rWirbt7Q6N/kvY1c52s/dkrQP/At1nIrerv01WcMPaWjRaSLRtNC1z9Zja5IJR lNltombLhNXzDpeMncVsc2ta3vd2ia/zjSN2xgrf5+bVYMJd7z7v+9f8hna/f63vFQFsWNy6xqL+ RS1gm4tgbirYgwSm74Ore9iCTvho/RXveLf6w7WyK7x5zdpL+Vth+9q1ixsGGoM9rN3khrilI35x fDFpYNrmOIsRRqxzB3ziAl/YwUOO8Y9ze5zJKnnJTG6ykyeb4SJsMKodXi2Tamzkyn44sDNWKJat rLQts7XBF5bDl98b5iyPGcZVNTN+i0xQOzx5znSus50XC+SJqjnKp1WrTHxI/tsVk3nNsIuzmPn8 3Ysa0IqEPkXubtxWPYMZ0b4NtDogPegXUzrTc/2zC7ksVz+PDNCiJuqjNUgUlXiWynQtq6Nb7Rgs EeSqIW10qBWNJFmridZeLPVmT31HXUdFsLAGtaBZzSkUyUpomGazUNdKXUtXEEtzcWWvce1hYN+Q 2rv+qi9RSl1tt4jbw34zTrEd7mI7Liqr9vFJpK1pZ5d1JXeut73vje986/sLAkP3qzfzsi4js9K+ vpfA26xuvKT6Trk5+EjFHWtPmYk2Ds8qxD+ka3l/pOLHjnbBcy1xjTOE42VOOGaU7V3NkHzTIic0 sLjd8kvDu8ox73SyB9fs/nO7+tbzjg7MPf6Slccb6D23LGVyDtSdd3zmhdm3058O9ahLXQzI4sm/ rY01OP/a5FkfeomJDm4QhWfhBj90zc2eQGFz2kNW53nYfR7ytasL7RcnWsblPqC2L/3jH0V5oqmk d62/HUg/R7oeAs9ydz8Q5oY/PN25vnjYBgzxXud74Bj3kHa/ifI0VzxMpg760It+9ExuVlz32nW3 /xPZqQf76j3P2KGMvezmZr3u1H72udce9mmPe+7zTmzLv9z3rrfR6YOvLb/PYl7H330Df/77+jQ/ wJFfZ+MLbfvBc5dB5f7V9A2rEMxnnvbUB//nSY/+9Kt//aZHfushH9j37dfT/PLXefbrH2ne4x/g 5d8//F3uf/c3cAHIf/RHgN5WdAeYgImngKinfw3ofGgHgRG4ZxPofmhmgRf4ehkogFXFgQ9YgR8I gpMmgiOIgSXIdBKIgtrHgCsYf6rngiQ4WDEogzZHgyoYgjcYOe4lWToITrFFcD7oUK0xXUJYQkTY Z0b4TUj4d0qoKEwYhE4Id690fVWjXgrHg1KohVvIhV0YfUbnhTZ4QFVohcVHR2QoNQSxLmOBhjkj J9Gnal9Ig1eCGxURhn+TalniHXcoJdqwhlnRhjNDDNAnSIwTiHyIiImoiIvIiI0oNQUAAAA7UEsD BAoAAAAAAKlDCCdvk+m+wEAAAMBAAAAGAAAARjAuZ2lmR0lGODlhEAR4A4AAAAAAAP///ywAAAAA EAR4AwAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqX zKbzCY1Kp9Sq9YrNarfcrvcLDoupgPL4jE6r1+y221oGBOPvuv2Oz+v3/AAd+NcnOEhYaHiIuBLo s5jo+AgZKTnJ1shjSZmpucnZ6WmDqRP6SVpqeoqKOoqzmur6Chsr29YKajaLm6u7y/tUW/PbKzxM XGz8ETyTfMzc7PzcuxwjDV1tfY0tSf2yne39DR6u1t1CLn6Onq7OZK54uw4fLz9v1K5iT5+vv89/ gY/yr5/AgQTzBTRxsKDChQyvJSTxsKHEiRRzRRRxsaLG/o0cN2UE8bGjyJEk+4T0cLKkypUsx6Tk 8LKlzJk0o8TUcLOmzp08f+TE8LOn0KFEy71jdLSo0qVMhwS18LSp1KlUF0SlcLWq1q1Fs0rwyjWs WJlgIZQdizbtxrMO2Kp9C5egWwZz49q9G6+uAr14+/r1xhdB4L+E8cQ5jDix4sWMGzt+DDmy5MmU K1u+jDnzYhmDDXQuDJqW5tGkS5s+jTq16sick15yHTo2r9W0a9u+jTs35NZyAMGWDXzW54FXPw8P jpzL8X7Ff+dYnjw6HOdvm/f2SV26dk7Q91mfk327+End9d287jkp+mkJGq0fD/9ReYPhQ6Bf9J79 Afxf/uP71zMfPT9dF0h+nO33joF7Kfhfg2gEOE9Qvf3BoH4UflWfgxp2AaE8T8lBR4UHhohhhhue iEWHeZmI0WHYBYMYijKKoSI81umWmx847shjjz7+CGSQQg5JZJGGscjVjUUuyWSTTj4JZZRSTknl Znd045hg1CEJlIg4eanjPWAiyAqXIFVJmY5orslmm26+CWecu11ppppWKmZVnRHcoueeYPaJlZd8 jplCVDEiBaOLMwJX4wlYVphgfoA+MCmGlpb5GqEgqelHDyCa8WejiwpY6RWPtrWea6XSpWkGGa6K UqtiygpTehPuMCGfJY4qm6glnNqAeqmGOGx6nOZJ/iCx7Ql77LJHbQnqsJLCht+nYYZZbbTOLtts i7TihCCBz4W736W8guYrRHVCy62W2mpp66HxEvuunQXiGe69rCaWb7bP8mvvtXcqO2+kANsH657u CnbDfc/2dy66CU/x6MDtwnstmc3+q/GgGmesr60iZ3xxyCAn+/GgKG+8cqQpu+wtC9K2B8y2DEc8 XrojVIwvs+36DHSxHpMscLF5Grvgz0ZbwizHRA89dMdGn/ltB8ZNjHN1WNu0LoM+Yxy00qwiHTbG /SJ9MdlW2ml22lGrDTfYUyOz9a6+VZ21XzrH7I/Xc8cttdhHFy34y7mi3XbR+JKLeNtvEw554Ilb /l23n3jPmvd/eyNMK7uTPw764fBCvXTpcg8uuVmik+l02aE3PvF3d2fu3+ZUd0npyiUnuzraMEcN 89OrU2igwR9HHvzbKr/su+5f0335l9EDVDntW9kOPe6oymu2xd0DTLC9wauN529rLx5wv8rnenD4 iz8f6/Rdyo9Q9dZXhX382ueuoLDWCm8z1s0scQY7HLT+x7gALux4HmMaAkd2PKJRjn5Qsd8E75cz Cy4hf2vQIOd4Ax4KYjAsHISJB2FxwuxNI4XzG+F2SrgBGD5IhIVi4QJf5ELtyNBVNlQFDan3Q7vh MIfR2WEL/yK7IRJxKXJCnxCM+IwkImqJTGni/sGc0kOSSNFTWaSih6yoKCJA0RlbzJQXlaKi7oyx GWXEVRfPuI40vrFvQdxJG0UxRziiQ451VBcNGRNBaqnqbxC8oSHTVsGkcSuPLrjjcxipx3DwsR5Y AyTi3HPFf0krjO+7YgQrMMikQVJmXbxaHyPpnVEeUYwa/F0Ymyc3TDIPlo2rZaAUObpTulGXwVLl vlDZk0kW4SWurNbu5kXAB2KLkIDSpMNsmaJS+hJZwOSJMFmpy/Fd0nRuE5o3EbnMZ37OYa37lDgZ WK9CHpKUvPzl7Kqpk2tiMZu6Q2fh7JnLRTKzZ/t0lzi9J7X2ZdKTmFthO6UHz3hOE5QL3R71/sa5 u97BjnfNG94gW0ZIyAHPlYUzmdMkWMODLkikq0woWRo6ATXa76OB5CcuC6ayQ62tpbRUJOloerKJ 6hSARiHpOndpUprI84nVY+knOZXOo4YPqeSUYNlAqlGLdlSiMZXpTAsKA1MGdSZDDaGjzjk5faJu bGOF6PegGi9/JlOAOLWkJdkJwndulSVdlau6wmrUpG5TrPk0K/MOSE6w5lSbjwtrI6Xp0womdq7Z qKsSd5bRrxWWpzmtqSDryb2RBnatyDQcPknGQkeWabGMdQhKhTjP+hnWfy4y3ybvJS8nwnSAqHop ZbslvgL6S0KI9WppVeLYKf5KsErVZnGn/oXcXuJWnWW9LWgvK7ziZVG0DTvtb3cRXC4etJmkvSUp EWndn7qju6i9bkeya0Z3xJC85hITLsMrXqwK17wiQS9QtRGTV8J0mL21K33XAl+H8pe9UjiPc8pD XVsQ+L/EsC8eF1yRBAMjwAx2hYMfCWGKSJgGa6wwHy48WsJsWBkU9vApQFzdDE9kxHE1sYZLTM0B i7i/j3VxQ1Cs4BmTVqs2XjGMR0pJFUuExQbtsY+FzFAkC1hvNJ6vkReC4wkrGcpN1u6Tb/xjBRJ1 ygohclazfGVKRJnDYI5QldMb5oKMmcRcVvOZ75tmuZSZuXcDo53vnJoWOznOzJnzcuuM/udAC/oy erYyn4njZ5UOetGMntOX2/znQ5MK0vyT9Fch3WFLn2HNmracbztNH0ovGdS38y+pbZRoP1ORx6f+ oqh7+epqsrrVqI51jGl9QVPj+hyc3nV8Q+xrdfQ62JHGMLHTMexgz/rY4Ei2r5fNbMCk2taohHa0 seHsXVv72tbINq63zW1oeJvW4A43Gadt7pSGN9Pp9gW62606TKsa3jR6N71h/el7n5vaWtb3r1Ps 7yjaO+D/zjHBmTHuVpf74LpI+KkXznBcOJzUEI+4LCYO6opbHIUDZ7jGN27hjh/84yD3Ib8LDm+S l9wUGO+0yldOipZr+uUw94TMLU3z/ppzR+QEz7nONXFzSfv852LmecCHTnT8njyBEUd60iER9EM7 /emOiDqfp051RFg9zljPuiG2nuaue50QYA+z2McuiLJf+exo/7DR/c32tgPo7fqOu9yPtHQ6H33d 8747NtnR9xza3e91UPuTB094Nww78PFBfOIrQXc/ZVzL7KWtZx5f9LwX23Kaz5khF9zUcikM827X PDkmy/UEZpiil5c86ffAadSn/lhCZl/r4/162EdeuUe9OlI99XvO537upjdTKDOu3we/KvnDV/zu m8t4HQZ6to2uvvWvj/0fDbf4rXItxaef/fCLf/zkR832Aa8pz818+rktv/vfD//y/p9/g0hSv9CZ P9rls7vmGUFxeKLPKMGHKwLIP503fP33fOFme50iCiMTKgaYewjIfR6neuMCQaHSfOg3f0qADwAY HKF3exz2eRCTgUkggRpoQjNHeTVzSBBYgvjmRyi4XuTGdy74gp4Wg/QXPR4oHY53g8aWgxxYKTxY RDX4g1twgjpIOTQobzZ4hDAIWRO4cT74hFK2gSZIhJlDhVXIZleIBB3ohC9khFw4HUHkbFmIHFtI ho/mhUcAhkyYb2vINWaYgLkDh7omh02QhEK4g2EofU2YhxRTN2fohz04hoEIBXuIhYVIO2qIiPL1 QUo4hYf4iHo4iHVYWwpHiZUo/olRKINfcoc1xomL2IZBtoSaCIij+ImRyIen+HCbqIpueIlSOIOo GIexaIpBSIopaIt4iItbVooyNomp+IuySIe02HSwWIzAqItfOISMmByOuIwq5ImdCIq9KIrT6Ism hIw8FIp7po3buF7duD/fR4zheIvUuIu1+IrniI7ZqD/W6I3YCI7viGZ804rDmI72+GDB+Hf6KI78 aIXNaIyuaI77KJAAR5C5yI4HGZAJWWillo8NiXzuCJHAVo0TeY3tiJAX2YULKYwU6XLK6JFkdoyr WI4V2ZElyYYg+Y8WJ40siXsumVoACY8y2ZIZuY4b6ZA3iZOHdZLymJIjaZE//rkvTYSSffONhmaU BSgnSZlI9MiUTQlrSCmUSimV90iVt8aQOzmPHPmQRhkghmdkMRmIY4mJCkiSW6l3K+mWrgeWPrmV aEmOWBmX9ciWbRmWeMlQS6mVecl0IemVQ7l+RQmYdAmVfZmVcAaYKPeXXfmVPcmXbImYV7l3hpmX lamRHreWlAlmhOiXjNmYeimXb6k6odmPo+mYolmQvHiXU6mamjmYdimZsDmasumMfYiaQKiapDmZ zCiShWmaP4mbrQmTnTmXn5mW3GaWeVickEmYOIecVPmcghmZKrmXOFmdL8mT2FmaTbmdNRmc0omZ nnlyoLmYqdmbm/ed7WmH/unJm70ZnsCZjOWZnOe5nNfWnHI4n8OZia/5mIepnHUZlQDKmo3Zn9nJ ewaqnvI5oInpXQwan7H5oJapmBKKkQ6KnwR6obUZoJlZoZs5ctMJniE6m5fpnzKZoO75n1K3giLY gghqorlpkC7KdKA3gmbhkSv6m+0ldBXICkD6nhDJo7ZJmzjngANIezhIpDNqnN2JpCRyCQRYlTvq pNB5pIV5Wpl1lNAYbUX6oXWHZ9QXf2VqpmdaVFdqnSN6Z+2Hpm8Kp+R3aSfKnddJlHZGpnGqp3s6 aHNKoxYaoRW5pfjnLGg4VyEBpgdaoC5HpUEqpQV4gGm6oRCqbhSXpA24/qQz+XqIqqZ1Gp1hJ6Sg EKoLSnqcOqmAWqkqeKMNk6OUEql9lKgNem+Wx4DK8KJkaKp0Kp71maIZmKt/KqI9R6I/+KtPCqy8 qqC+Kqm6Sp+caZ9PWKxYuqbC+qxHGK3Tiq1wN6w3eK2eKq3NpWzb+oLduqvHWmlfKq4lSK7Naqzn emz7CXLr2quyqqnhWq3Euqzm2q71qm3pqqyw2qnlWl67maFnma/7mq3u+m3+2nzymqz0qm5vdX/3 yq0H+60CG7FXdXUM+6p+irDeyqQLS7HjarEJy64hK7Lz2rH1c6rBqrD9OrLqWrIgS7PuRGzwapM0 yaJhCmTMhrPHCbAt/susqymcD7uy/mi0Bdui78qxETizGGuyZNV7Ute0m/q0Jxu1haq13tmj1nq1 Kqu0o9ZvGxuz/+qxF4u1Uqu2Ewu2Vhu0Q7uXrbB/avGzyIq0O6uo4GpbZNu2pfq1SauQcLm0fAu4 fvu2+oq2hgVOXFe1hnu2Weue9WGohVG3zvq4NZu2e6u3Zte4mOeweAuxNiu6VFu2Dfu3oDuhQ7q2 pNu3nnu6XcuiozC3dNu5j/e5sIu7aaVWXGuka3i7vYu5yKKxbFu4rnu4Hwu18UaorFu8tvu6wJu8 Ylq6R6uzucuz9Fa5bHq50Zu5s1q7ife71xu3k0GUreu8x5u44ysZ/uXbvOD7vOKLuqPLvPHrttvb vebLNrwLvxWLvpBrvUeJoYGLiOGbt9yLsuxLv47LsnBLv8s7v/9ruv0bvEnrwA8MvVVIwKE7wVxJ sAJssBJswMlaweSJv4SXwambvrtrryXss+yHvPdLtMSbwGo5pojrv2lStDPMnC6cwriLwyTcvuja ebGKwigaxC08xAELw+2WvT1WI0Qctkasw/qpalDswYO7uWv3vUJsiUJrw1k8tVo8vUxcxUo8nPCD VmLMwkybxF78wpyluGp8xGzcxQzsw/2UwxCccmXsxj2MxpOrY2t8s3xsxxcMx2F8eFuMxHX8xSG8 U3GcyGOcbk9s/sbjC06AjESKTMeUqsdRXFbHB8RTzMWcbMiW7Fcy3MmTTMiNvMRuOrxhp8mD3MaF vL8/jMqlTK2M/MZzHMAGp3OU3Mf+a25NbGPATMsFvLjPFssrTMr7i8tp3MG+zH+rvMuR66WNt8zK PMs2/H/L60BcCk3sCcnw6clAq8vSCljgvFwSG87JgMliKMnDTM3o3D/+I0p/I0vyS6qbLMqL3MyK emDTcs+XnFG+icjkfMUlZ8zcLF2kOj6CFMbuTL55/Mzaus0I631q+9ACHc7irD5ZQtHOLL3njK0Z PVYbjToHlKqj3M/87LL7aNLvNTUQ3dESvcPxTMMkDbIxHVEC/jU42WHTVIzTN63TUMvTsQRQpyO2 WKzNgszMqIqXAZ3SHA3KQG0i7/yHTt3U/xy6AU1bNG3PHe3RYo3Q0gxzC43R56PWyvVW3TwmWG2I Qy3URY217JxZUu1Ebt0iCJzK8nzRPcwNInIQI1zM2QyzdK3VscKv80PYLkbMjj3PwizSmgXXTCbX LP3SvAyUjN3YZWnYKcvVRbzBH03WnHvZ/gzVFV3Ld33NvfLZ0ZzYQPTPoVDZlh3bsK3ZkFjN4pPM FjzZ2BvZo63aLtXLA/nLwe3IevzKvo3MlhvaYftKj1Go73FVIB2YijW7WnPaLn3MHjwwjfHRziRQ dv2M6mza/rdd1uh9hdmiuZhUTzX1suPY2oGc24f93AIMysU11T/9gHsd0s2tvfctzb+Q3/eUOvHt mrf823v819bpwAWu1AYOhXTD16rtvQ3uqQRVS1LtVLwjWw9R22NBq5V3q+Ys4MY93dBXz2Qa3hfl 36C6qqIa41CB2d1t1j17ykqz1gec4GY3qjC6MZ+a3vUt26q74SsOUrI3tuNZlpdqgRdCRzXOyk4G 4TR9TDbV3wjD2XzK5Z2diI3Kqo+aZPOd1Sdukp8H4bhlMhGO4EzulF0O52Fg3grWNdlN36mtlcPr WugD1uAdw4IbKHAu6GRO2X3qyoOO6IvWU4ita4Sazpob/k7VfdUTrVgKRejT3aeJrunZt+hm/pGZ jenWnWSWXm+NlqebjupWOV6M3tKBDWF2/nW1PedSVuch3hI5gdaAveDVW1+VbU612oBiHuiXXhO4 jtytbOELXOxwvYC15+SjLmsplOuSDeCrvuyXznrAzoJBnqVwZOwYntzJfrcjYUQgqO0HMuOgBE/f zup9jeJnfu3KUeL6EZjEniTSfuzqbb85yVUh/tgzwu6eHpG6vu8lkWn/LiMBj+fV7u4S2e/2btDw DssiNe3C/du6VTGkLuevvWr4Du7ILtKcpOEDS1f+zvFLpPCg3vCfjrLLU1InNT2EEvPjqO+C5/Ht Lu7l/ry3xhWxGo8Mo4dQQd/qkZTyNv7uu+1A103yK5EQgoISNE/kXlT0U57zCb26z/Xyt/5/otcp INL1MbUX3F6rtA31Q69HU7/bGpzcVg7NEw7zOnp7/3MrwD7TcW/3YS/0K7/uNy/wRbbwkts5ti4f ktv1DCguhn8zXI/4rQcpZa/30U7x+R71IbXSTL3YJe/0Xj/3i+9J93H3kYY3CI8iaE/wVj/agJ/1 mK8wmn/3m28VN3P4iS/7UT75KM/3C4/USc/hPf/3Vh34EB8JMML1h+/6dW/4my8pjl/1W0X61K44 A4VW9YeJVs1DwA911IL3Yz/8usswxpTtNDPmyy3x/ucNV/cdOhgFxhyc9rKrJ7BeCElPBqIu2pAd +R//nlUtUaW95BavX16+/wQQH1OX2x9GOWm19wKdNMAftLqRDE2nO9WVbd0XjuX5SGnEvuWc2gKf 4/kJh8EMUPfiSUjN0DIZlU6pDN6oems6sw9oFxwWj8m07w5Zrpy9wrTBB0y/I2w1il7nPvN3/z8r pwSQb8sO7JBQcZGxESSxBXJR0qhIIY5ojqinz5FSq9NRdJTTzfAUNVV1lbV17+6TVHaWFjHUJfYv 15IOEydzs7QW7jZqdxhZd8OVudn5GRXwOJm62npiGiObbNf30vS3Jhi7WHE7svxaXcwG2v0d/lQ6 /n293l79fI1+flyPeMGbOEtH+o2ixEzbvnsLzcjBUk8VP4YTKeJTWChZN3CVBv67SKygqIOuEoas eBLNpofrIioziRJmTDX5hCHT+O8XsCDTaHbpOeQlnqAyiX5Y8nNmKolFmTa1NZQF0io3gb56k03q FJorCTr1ipGjxWguv5Y1GyOr0IwXMQ0Kt/PRxzL5uHY9exfCF6g25Rrrixfw2bQNBvvdC+svu8R0 Ewc+WXhS44aHHVcWLJkcZbKzIIPSnPMzQMyW73UmZNoEatKrqakGuTa04tjc5NaNO5s1Q9eIcevY nRu4wdF6esum9RvXR6TIg0cufnw4DObNqW9O/jI9avTr2qXksp2ae3XO4RlhzywefdHd5lWwN0re 977v4J+nH+Y+EPz2+u33n8s/J9igqy+/wwbDz7+pALTutAUTfJCK9RxEa8LsCFRwL4TsghAlBCOs cEMORRTQMBJl8bCkzFhJccSKUOwORBFibJHG/S7Ma0YLB+TrxttqnOjFEp37kUiRJgxSxh7jU1LI MZAs0kb1cjwPyiqX2o7JJkl5kkonp7RSui99EhPHLME8M0kYzVxyx/vIfA3NaricrLw347RSwjU9 a7OWkVph8U4epdSTvkAN1epIO98jVAlFQ2zjz0cP3dJRLa+cFFMKGYXTzU3R8bRRUNXK9MRK/rGs U1RS8Uw01U/5fDWMOVUVrVXjhpwV1xPyNJHSWqOkzddca5JJVqCEPRZQNgUdL9hC6cOt2GOjDbPZ MpG9dlhlO4W1VMqQMGRRbBusFkNUxT131FOX7XZd4t7CSVJ0bSXWVLjkvVccT6dNt9d2cXxXoHjx LXBQcwe+d1d/jSQ3XCaCuSq0fXGV2NVbD0Y34W2ZVZiwh8dRrl5xKdbR4otFZpVX4RhOto2w4NVn ZYRDprNkk6/NuM+Z+d3YYZc7ytbmD2O2lMGgpUWZ40ZGttcfgF8G2miiH9PZ2KiRxZlbT6iGlByX j1k6U7B1pVpsq6fWd2uuec7ZQJ187tJs/nXpHfobuuMuC+u1+9XYYbc4TfNuuWMqtuzAF8qbXb0V d5dpgQ1Pzu49a378UMT3TpztFf4q3FDOGzYnbcrPVjPlhZMuV/SUCp489TgtVzlr2NFhuXWS5za4 9kBfN33xy8cGOXJsPafdj+Fz51vbzHuXvZD5rD2+4ttZhx7K3bUOfmfMS9rGeDS7hxl36sG0XunQ G1++TL+JF399bHr4Hf7p2a+R/PCZj73jQRYzf9at6kitBs4CHfbmBxGkIe9+6KvbUXrzvfFJZigN DCBYBljAVaGNgM/TngLPFzAfWfCDAJngD0joARO25WNVIyEc8oUCAY4LhNU7oPI2WMP8/jHwhTEE nxVGeEIWrlAlHHHDBDPBwxwWTYcjqp/8mFg+b3FhfxkUlh1MWMIfAvGKKxwhFn/4kucQjn9J5CDk Sne900FKfY4TY/5cWMUhdhEkR8HBFYHRj/qAUYprxB+1yujEMxKHe2EkFRWt+EYumiSIWkzhHDVH NkHqcVHxkOQkwfVHGCJwe197JKYOUUQ6wnGLA3ljHEJJIDxC8myUVKUq+2g/G0ayfajsoCJ7WMuq XEKFRajjAhtoqpbI0oCrFKYkW9lEV4InlsD829PsgaRfKvMaDgyQJS81RqlBs4XT1I0vlYLNaG6S cZg0ozitEMGIgbNy35Jm3VwiD29a/mOdy7QmEn3Xsn+pEZqCcN436fbMd1KThgFN4CtF4zPg/ZOd VRnmQhna0HggtDXoVBs5jznQjhn0nHmc2DIc2lGPfnQVEC3mSP04z0s2zYMphdo/2wFSl770oyIF 6B7HSdCa3lOlP4MbRPUZT20mZSwypelMT1pPm3rtYxkVai73CU9uBnWpRuUnSat5VKdBLJnKZKBG PwdUd0ZVqk7lKq2GakyVYhWfWkXrNvvZTbBaVKxUpSdcC+o0nfZtqXqhyCnfWlaBmpQ3M9XEN7IK TJ9OtKh9pWtEx5pQq5o1jiFNq2El2tWqKrakzZQo2ArnpxVNVpaHzV7xKitUn0oi/iB17cVGQhhW 3nmpsWErLWifgtnH/rWczHzLanW7w9smtramnS3gKmjbxcq1LeVk7W57GdvORuegwo1t/Ipr3Juy pBzJJetdU1vYub5WRTuJrkxFy0bIWhe2h8uuKSDWXZxE0a/AFUoJXuFbkZZXuRVFL2mnG0572uYh vL2rfY+r37pGlrr3HS6Bv7tfoKoXKr5QJy/suFzv8lewSf3igh/YXwrK18GBLc16PaISH3LXwrQV MW5z+7YLQxK/261uiC8b16Z5A8cV7u1KMxvftR6RpRzeaYNpPK9g9ozC701xkj9c4PP+uMkIjbFj QVzk9I44wqxdiUOE2Nz41vjA/jm1rJSFjNfzWhlRHkYsHuC15V1yCr6AJbJdMTNlEdn5p2BGc3A1 m+WXTThfXPmqmX+rZ4w2Us26K7N/Db1n1PUZyYBmJhQGzWjwmhTKreXpojVYZUcTTHO0onQao1zo B1OUsC5WsR7xnM0Zf9rIAMQlwDyGaLliGNXilSxxFZzoF4Ma1lfWlRZDSexFJvjLp2axqHfN4CD7 etWPDnas6kzsLNqSA7/Ktad7TG1oe4/Ta57ztJP3iFKK8Nrp/vW42c1t0kl3da8mt7TNfW07Ftva Yzb1fzxMFTE7+52tlieu5z2m4jyMkdlW94bVzFl0xqIuTRX3s+Pt7oLPgC4K/l84vhl+6xV/mQ08 CfePBJ7LRl9cdc1zy703jmw585uooajNyOlH8/yeGeXRMwq6853IhAPZtTgneKdlDHBvlpyvOU/z Ewhjb5/vmNfJhvm2/63qiQfc5kU/udLJWG9011ehF+Kcw/udjmKMt9ePOV+zPIZwrmOc02N/5HMz ZM51i3HKJn46In76bdEdPO6bnfvDzW73aOM963SUw0xc7XfKNea0gncu4euOUqNjE8/sVXes4OT4 xzHG865ettA/fnXR85iePTlDyEOy4FafsIq6MFboAydxS0+VqMoGuRdjE60tBDqQaWT9RQccdAjP jNRvB77LcU/1dm994NG//j1pPcjluJx1+Dh1fjBh2n3vfx/84Rc/7F+a++frXs4Rx4ojjTDYhITF eWdPNNLHX3/73x//+de/+YfuZHmn7/c0TRlaDPtSza7CoQ84qtZsj/TkRP8eEAIjUAIbKuxiKhIu z/QuTQON74ZAr05MDqP0jrBGrfgqSZfkjvbQKHiSr5nkBCIACfAKQioMBN+mz//6b99SboDUZz5a qsL2wL0az20q6/VmTxqMcK8kTywAiflAUNb+5+eGLAeFTep08KQ0YfWST58CJgFrjcn4zyY6r3jE kK3AiQW7Rf5i8Oa2y+1USAR5bvMy8Lo28AYlB3Tepgu7sP2GkL68MAin/rBPGo/x4Oz4yI4BncP2 IC8PVi+A3M6TPCnf4FAKORD6oE9Dom4AEdALF4j4BOJP3O8PKRGe+o4bSJH7zpAfwK5XVHHWSs0J Ee4Rs82Q4pAWR0sUcfAWLxEDvWQP8VALF9AEr2ojiDDr2k7jfGLtsKvSEDEAmSUYrTDPWo6LFK4N JRH16NDAus0VbTApqs9t7CULxSwPvRHqsBFIHCkFKxAVveoZFwaqNGUNo7AROS6yElAAAdHbwJAT 9Y2/3Ez41OkHvyMPV07z9NHjgC0JG871KiQLWQ6XIJGRImwbzfH/6vCGJrL0oi/TTu8AS2wTlZAo ki4hDzIbQyUezy2L/mDR3qwRE/GRz6pwlloS69LRFtGPrUiyAe/RCWkJJacRImtwF0uyEs9PvLQt 7UISHTsEJG3smlhv7wiRI+vxM1AQJqeOIO4o8e4sK6MRF7EMJysSGqOy6TLSJQ0ODJdjKyGE/ggo 75bSAUGlId2nKy3SKqXuECfx6NJS+uryHBXS734jLpmAKOcyJ4EFZnqk5PxjLYWSKUfv5YAOtYZy MKkQsA5ELxNkMQuzLGPtK3WS7jozH7dPF68xny5TJPsSNCfTMykvNc1SNEni8JIoM8HyyAxSNfnx M23TNR3z3cjLNJNydHSTLOFOBllTOOltM22NKS7TKGHiNG/yOPnS/g5jkiK1cQ5vcTrpxZ4AYzYt rjGrUjIh0zi3bzir85rMgjmJTinZMvGosvkEhyvpkjBp0zqV67NkEj1pUidHUjOxMzzp0yS1Ljlf Uj5tsgP9CS/vECDzK7V66g098c0gDSnZUz/FskC903ao8zr9Uzo5NCydCIWuIAAdwgfZyx9D1Csn lDHfsjXLEx4F1ENdFED7M0PBy/raLMe48BtJlBxrU3pm9DsfE0hr1EI39EJDkzfP8w4L8GdyLKme pkFHrjv/EzwN8z3LrUjr80gJdECbMDJAQ3/8sI5MTCq76y67NEZ7kz/JU0tflMqE1EDbVE7V1EjA NMDElGlC9E5h/pRFVZRGzfNPO5Q4TxJNkdNID3XpSqUjm3TJcpQADXAJQ00etYGPAnVOVxRRA/RN C1VoqpQzd1M44G9HHfULAU3SyuwnqvHuuNFKXcQtGStRNzVNBRVTb7PrKEXXADJMl6/zgLDtFi1V j9HrdI5K4ZRWPVUmc5NNj/VS4VNr+DQFonQTTa69IGwebynQAgQWF0/xZLBShxRWo7NVnXUvmxVc 4xRQsRS7rA44ttDYUlLxhOiTeFJYlfNcxRUhw7UpxzNJbfVT81Wzqq45BGGLxnQWq9GQZpElvZRZ I3VZLZXQNNRcMVRGa3VQ+/JMK4Ng6xFe3/XnElYsleQ5rRVf/v/1Q3cyXSkWXTNVSR1WMbk1EhNp 72S22BySWP31NiZQZ3eWZ3sWNh+WMjmVH/MSEmmWiJj0kEC2FW92PonTZ58WaqN2AlvUULeUaWey YEV0GV5jW8k0Quu1OXE2kqSWbMvWbLuPajsVaL/1KH9UZa9WaGMVOiV0bZEUWe21bYEkGTkvzzZl eDwHvyLPL+8WVO1202oFLk2RHRRXCWTVWBu2T+m2X5sWYjFSrRA3caGyFDU3TCQ2Zd+WcMWWS1n2 Xk+WaAtXC8hwENuBZsr1c4vVaku3YmHXZNXWNzGXIZFwDKPVM762biFXX310cmdXdtn2cA2OITNW TQAkTH0N/nBtTnDTVm4fF24xD//U8WzJFmVnFXill3Irl1xjF28PN3vLNwIj93dfV3xHd2JFl2FL 8/6w13yfdnvXl32VkWTTF2C5t3rhF3nhUnkNg3nv1HmJsUKjt2TDV33dNG/TLHF5V/Yg2GmzdIGJ 13stGHSDln+JlOL2F+NUdy5AmG3/1oBdNQXdM24V2HYbGEa0QhBDmHMbxXNJF3zd93uL13BTGD+t F3FdWPTI5UEjUVLjU4dV+EpdNnTptIhJ83LVrm8X94mNuIJX9oireIOrdopvlYWDE4eBbomzM0Ul N4lb1mJNl4crjnb384pzWIyRmHo9OIv7t4n9tIstl4br/viOv/hi9ZiB2Rhr6TiDw3aMsdiNrdh+ lXiN33eO3TaNhzaRUbeNDTmO4TiP93iLTbiMx3d4A/mRMbiRV/iNNbmDGdmGg7J9P7mGx3WQ1fWQ 7Ti0fpNCITmU/Rh/w3iTuxeVvfiMATmXTTmTPfmWWxmUJ/l+h3mUBwc4CVmYjVl4mY6XNGwGX5WY ZVmZFxmZY5mSl3l6bdmZhfVb2NWXObmYT9mM/ZeXS5mJKxmdxTb25PEpTUma1ZmKEfmPSfmGNTWB mbmWAejYEs5mXRmPqzmVY1OHpnSdI1Z/a1eS5dLaHPKf1VieFfqX8fl4z/metTihabmQRaAn/Xlh CRqX/ud5oHfYnO0ZmDl4lsc5SDn6Y3nuoR05ojWanPuYzCqUT0Wapld5myN5DY7RoT+apGdaokc6 nFkNlidal4HPKdvrH/0kePM3k7bMpYG6qA+6dXUapEHIoC9ajuU3V7W2GZtxzdZxiMH25rjqiaBl qn16aZNaqGUaqbv6lW3acXHaeB/1z7Awp7Srfv9GVdHCiBgHrat6UkEppabVreM6mxVblOv5mhm7 sAQMxcTxxAT2hc36Aql6mgY7ncfy65o6mgc3pQVaiimLrmcYrstZt0IxCBfRnH5Sxk5s5UQpiK4g PlmXhUatiHi0Eb/xh93QH+dIAaEaqy15tAEaxo6a/qhr8gBZu1F/0L8QiYh+chh9smixbbOrz6M7 omiH6GB7CCJ9blRPOJ7fWoMX27TR2KrVM8xwlPg2ErWw8JuF24U81rBB6a9xu6FXcmY79r6ncV73 29gCT7T5+K6peZdN2q4p2j599b0r7RAJSRq/rqUFXGE1LMD/27/v22iPdrstnIif+rhLO6AF2bGd M5n12U7d7MHBDuJkbsLDbsMvvItcnJRWMmZXfMalEscVCYpC/IJVvMTRm8RRaatPurF9ccdC0XXr WsPtm8MjkhprsWqoe8K9tWA3rw1hOyUJPMhZeZoVOb0tGslNXMlX27fbm9BYTiVR8uloHMB77sZB /py+3bzCHVHjrHzAybvAO3mnidzIR+Ovs5pQuRqlz5xab1TNIxZhPRzH37zNsA266TXA4ZzSxRu7 Lx27ETij/zzME3uuowKzGfpGRra0JRt7FzXVia6pSwkL2tljYe9jXVtpsxa2bTvLf7vC/RrIM/t9 INq8ETzYDz3Bh62wf12IgX2ocxpShZEEDxQSnveAHaRtoKW8IRvQwXiUY0/QtHa/N9bHpVuuVVq1 Yzqkg3nnelrZl/vAtZnQC8hdO9y65ZUnuTzZ153cmd3A9X2j1WbLYbZ+rb3P3R3MhXyRw5tX+9vR Fbatk/zciZ3gi9z8dnvKDdveqVwOh520xXnc/pO7uwNMyju61vWq3Rcco9G9zP2zzeOc2zFb4L9c 2yO+swP9upf2u++8Zkcd1PO95P3c4NEXCvO85QYd45nb3IUd23fe4ze9Y9OcW6u7xxnc0B1e5mN+ nwVThLjcREMOuXtZ4tebsGUT4Lt9a3U3tyfMdxXq5KfezH3e0/s9sGWRHu9d59nb7a96xGHamlEc mzee3fGem/NC6M/N0hs+7E3+4RG/3EPdRfaW76K44Kse8Hm6vqG83jO97jM+6cn471l177vDh3nd SRgXF5xc8o078KM7toH85fPZ6o8e4j/fL0If3Ec/hpMDtTff7xO6rQb+03/+69cIOwBThG1f/r8Z mITnD3ohz+vffsh3H/WP2YFdWIJhwew1Je2LO/iR1W5Q+O4jn55Pt0CSd07I+nf42vXDH+6xHuxf //mBH/xN2/7kd357tq9hf9lh/rxPv+PbP0EJID6mLrc/jHLSaq8FevPuPxiKI1maJ5qqK7thLwy5 MV0Hs53rCL77b+8nVASHv6JRiEw6lswnNCrFtKqkmzWr3XK5WMDU6AzHxmSx5hw1qyvs9uMNl6Xn B7k9r98b8EdOWAcfEeCT4NcgUF2i2yKjjt9jk6NkHGVlQmSiJhoY5idoZ1uhFJiL5yYiaicqJ6Pr IGzo3eVshKwe7mitrS4kr22wMN1qIPCQ/udMcV5y3bJPjy/z8az0p/UrNSj2FDeZNwz48Pj085q5 GG0rX+siug2l+Lf2Nj05j/24fGl+bH/2O2MB7xGs9m/HQGj4ViWEwtBRQyqEImLax4/iPYtzNBo6 mMsjO5BKRBYsWc7krUzx7BQLgrEMyZAvAaK0NNPgTZn6YrLk+StnzaAChU7gSMMoA6RMlIoiOtFp H58bpc4DevKjVahaoVEVxpRK1wxhd2W9uhUR1K9/yp5Ri3BsOLhn51Jwa1aSXbQF8/6ky3ep3G6B AbMlu+cvXa2I1Sy2abhkY5iFKw7uOZlx5abkIkdOHLSz4MsjRdfNfI50Vb+mH2dcvZYg/mfXnmeD vnhN9lPIuJHtxowa697e8IT3BT77OGHkUX8Xb0ucK3Pbc2s33/xcMuzrKqMrp62dNd7n1C+Mb8Td uNPyRb+DPZ8ktvvu09k7jx/Xfu7g+Hnv962Y/n079ffWgEkBKF9rBVp2m4LqlaZgdf9BmFx2Eypi IXboIbhhgMo5qFdqumF41IGaEfUhMQJWeFiJHAaD4mgMgpegiKqNGOOKw8DYAHwu+khei6fJ6F+N +tkooZE6Bvkgizf+2MuSHTlpYINRmlfkWTsCOeWWKtKo4ZNh8mjle2SCKFAXaaq5JpttuvkmnHHK OSedddqZZpNi6jkml0JSVuWdgQo6/iihhRp6KKKJKuoFmHs6qiWBQ9a3KKWVWnoppplquimbeTr6 6XLdfQgpqKWaeiqqJqbqI6k5jGrmqrHKOiutfNbKYavD9bndrb36+iuw0gXr3a5SSjossskqu+wC uTJ7pYdmOvsstdVaC8e0105SLIWVZKstuOGKW8O346ojqrSwmrsuu+2ux627KUYL75nx2nsvvp7m ixO69Ja7L8AB0/qvuQSL5a+6Aiu88K0Gi+swk38yPDHFFd+SMMAQv3usxR17zLDG2oZ8McL0fnwy yvOmvKDKEq/8MswPY7zvyPJ6O3PMOevsFc741uyYyzsLPXSvP1NrtK1BE70006ci/s3s082ma3LT VVtd39X89ctx1l177VnUyobNq9Jfm312ej3fO/ZCXKP9NtzWUR0w2+eWHTfeedczd8Zqkzu13oEL Hh6nhRuu5tZ3D74441Ud/jjkLCR+M9+NW8505JlrbsLkhF/+OeilyDB6EynFcboEA6mOOus8kl56 680++Wrlodu+8+qxE2E67K6n/rrvwfcufFLAFz88roDfvjzzRxkvO/LHR59JUc/vPv312PNgPfXa t0x58+GLXxf323t/R/l9VK979tKff0P66rNvPqvKj38//t2/H1BCuRO/f/z6Fz/4zY9+7kteyfKn wPz573/6A+D70FdACTqwfQeE/h4EK9i5R9RtgR78VQMv+EANUlCEJjTgCeU3QRWSkIUpJGD9EvjB Gd4uhBh8oQtvqMMMtlCAK4RhC4G4QwTRjoZGBJ0NLajEIY5wiThMIgqfOEAolhCBbjsiFvNGxSo6 sYldzGEQtyhEKf5QjLVDCNm4yLIsslFvYhyjF78IxiiGMYC8q2MZf5iltqlxjW3849veyL87vjAi gtTjIfMYwT2Gao5+BCQkvZbIIMIxjn1kIh0t6chMcvKSntxkJY/TjGR4LpKm7NokcRjKTxpyioh0 pSIp6RdVgO+UtqxaKjHZSVC2MpaqzKUuefmjQ5TylsYcGjA1+clVMnOXzRwk/ix5WMjZba6aWjgm NmETzV/a8Xe+DCYon7lNcBLLmuZcQTbTqaNxyjGc0CQkON8pzXh2M4bnvOcJ1KnParBTme7U4z9X 6MN5tlOeGyImB/32mn0y1Fv9dKY4FxnR8w0UjwSF6CxPUUsXdbChzUsmRM24vosuc6IW7SFHG1ms jkrtjB49JUhLKlJvkjScJiUjRXFlt2YSiaMKfSkgY2rTmcKzoK/8Jj0lmhY+2jREPnUpUCEpVJ4S 9aG7rChOT0pOxaSxqaEZ5k+jysapYjWYvawpVa26TIMe1H5WFCtcGaPWtAp0pFpt502TmlOwyvCp cf1rIOZaVjme9a7+zKtR/uvK1yt+D7COfY9gi6rMwmaVnFNFLEYTU8QYPraz6UDqYasK2slK1plk pWZf3+rZ1UIisq4t7VqPilbMlhRsbm0rVFm7wNO+dq7MHKw/ectZxW1Qt8YlT28Nm1nhzpa5qi3m c48rXfKNVqb19C1b9arcq6KWschh6XTR5tzK4jWge61ubBU73I1GN7zu3S4rYStMmsKXrs29bns3 EdYIvbe/wcUveQ9rXpRiN7m49a4o9+tfJBpYu1ulbXwLjF6e2ja1B14whtN7XrRS1sF4vaxoL8xe EWd4weP1sIAhPN8Jq/i33SVuY0vc3xMnVpYtzm6N6+vixcL4uwqW8eJo/vxfiQrZtBK28ZF6nODc AtlyRdawKgc8zSPXl8nQQTCxmuzfJ0u5vDeWrY5DTMTbjtnKWh4cl1Xc4RxblspTXi90SXxm6aZZ zAEmrZtRnNkkj7jMc3ZvnQEcZjDf2chKnY+F/fzn6QZavXkO7aPxDOeEmtlVP1403Bq9YRbjeMj3 PXSWyCwf8GI6ZpomsHzVnGoQA1Szoi5uqTt76jdH2rqcFvSoXx3jWMu6wWz28qz1bGgkIxrLFea1 boNNWLsWeqi1jvCkaRJtZANW2ZJ+tn0H7eh5iQAr3c51pan9NWtzl77Nzva5VY1bEMiE3YoW92PJ DW1sA3fYVX6qB/T7/oH8wlus8l4xvVcdcHyPZ9/87jdQ/71jgW873Wl2tXoQ+m6Ex1Xhnf71srGt 7mn7I9x/8zjFm2bxVo/81qBm5DVeHPKG4rPlj2OQyzWHrUuvPGcxv7mmYI7zl8+o5uncOdAppfOg c2rmIPf5y0jdMF2Diy9KR/raaB6uzbbL6VKHOsoKrpbe4Izq7LL60bF+stq4+xzz4FmixwV2sf+8 RNGQDddr5/V1rZ3t2ATNJeDen64zXWTXebrd6e52bSDBJaZ4SEsOb47Cvx0LbeN72mUGIcAHXu0t IsV2SGHwLzgj38tB6OY5745ClJ1fSr5W3StvS+p4nhauj8rrQTT6/p1CpB12U0btd2r6Plt+8ldX /cTKQ8x4HF4lsI/98Yl/fOTjY/mOb/6L+o76v/8e+AvbLC+U//zPH0L72ldH56HP/L0Zu1qpt75U YRV+qRl/+6InfeKdv33cO//7u49zwagfdvQrDO/LWL/red9DjEn7CSD05Z743R+lxcv58V8b+R/i xd7sLZ/9dZ7tSeAFosX3kcrc5Z/v7Z8D9g2XlN7mlWDiDV/omeC+EV/rKaC0VZ3+hWBQLQnmMZUN up/uOd4SFAH84WCoQJ6X+QkMfqAM/hHlyYrhdRwDxmARjlX1WcvbTckR9txXNWEWTeGq4EANPpIH Gp0VXuETmp8F/g7eZbDBG1xB9oUelQwFFX7hboXh0aRB0enKFnIfNaDh4pVe5ilFA7qhB2FhqvDc 34wfBVJE3uVhV4mf3hGhH9IQIKLKKWzKcLRfAvogAVIiJsqf/LlGHzYiA8Hhs+AeBE5iJeJgPhyi gRAC+5Wi1rShJ47PIzrN6JEhKRJiJlqCKq5iDqaiEGLNK/4hKEJN7UmhVNhfS5VGLk5ECyaNQzDh LyqQ1oGMMXIhWNziDdJBMu5hHSZit/jiM37irgRjjuxZM7LFNLIiLlqjKd7hfnTiN34UDYJgTXRg NaKjJWKjOqLiJVZhT70jLMajNEaeWKjjPaYjOuojL/KjN/qj/viwXgTmB68A4CYq3w7WQhL2DD3W Y0HGRTZWItk5I0OGj0OCH+JhnrttYOuRYEquZKtk5JZsoyZejDIKQggYpLAsZEgyz0jOXwYioAbG XyHS3gAGZSFClUu2Bz42wkwCgh7q4k06VU7qZJBYYEdK5PMZ4AECJUVqZW4dpd8xYlRK5QiW5EJ4 Hla+Xk2uY0y+H/3JTfnFIViGZQ1d3v/NollyZQGeJF621F1+Ce9JnhfK5fJ8JC8Cw1kmHzocpg4m ZldKHxSCpGAiEV1iIPJNoF7MYmU2AyVaJgIqlFdOX1xG5uf43x6WZRSiIEtqHlCyJUlappIIZNNB pmg62eBB/uQu/uAJruNqTuQzJKFbnt5jhuZsNg5pckWyfGZwBuZwXk5xvsVxOqYYCudyolkwiqNC LqC7uON0ulF1yqMr6svXyeZ2Bk4smgpyRqdyjid1eidcvmUoiqd64k15lsp5tud3xqd4EZ1+FsrQ 7SempCd+apF/Dqid9CeBCt19Bui4HSiDwomBNiiiAKiC6pNFeIN9sCeUWIU06ILRzOeE9l6ZlOFq eGgvdsnHkQh7kuiHxmZ0YIPErYV1/uXGnGiGIMmK7lOFUoUaEghMfmWN/ihSboWK3mhyqsqFLKOl 7ejUxcSG8kSHxiiR9l9l+MIIQEdTsiiQXgiKhhqGRmnw/k2pk15Bkn4biHbIlmapUAyplwpji4aF UahpiKKpiZppWkDpmtIMmIqoe8CpkULLmdJp2nTpnQpMjuppOdoLLjRpVjypoA6qCMYpf+FIdjJp MYZpitqpoyJqnkaKsSyhhlbqosIhn2YqCG1qpC7UpH6qOVoql5Lq6plqkh6qp8rpwfxpnTaqq2pq mxpqp6Yqrfqplgoppuaq4O0qp3ZjeKqqrthqoBJrJBXqsUKqrwJqsFJrmg6rswJmn1orqg7hr0YM t84jtmYrlm5rtUqrt4YrsAapjZKrExrrqV7ZrKoruJ5rs7rru6IrjSJrsX7rjNIrluDrEUFrvEZr svpr/uqwqrDiqsAuKbzGaq+mq71ObK0ubMNiEcFCLL92IcAmbKheKsNeLGjqK7O24rRS7JyirLiG rMiip7myK8lyrMqua8rea8t+UMYua8QebMeSTMleK8veLJvGbM/+bJnObL3CrM0KLTTCqs5u7NEq LdL6rMUy7Rs+7NMSrbZOrcca7cpa7dVqrdRKqsSObc2eLdCCbdNi7b6KbblyLdUW7W+q7f3kbNu+ 7NuabcXKrZfQ7T+yrdcabL/yLTPCrV/6rUg67d2abNmireMm7YmMK+IuHeAi7OLKrN7S7N7e6uQ2 pOIGbsHm7eNqLul+befCY+USbuaK7uaqLjem7emK/qXbti7j8qzhAo3rZmjsyi7e0i7Z2u7q/uvt 9u3uho7dgq7GNq7vjm7XVm3xGu/nWi7yjmzuvm7posSoPu+uCa70du97KuvlXq9JZK/2Ltnsim/y Ai/zCm/wJkn5Mmf0Vi/kYu76Nq/8kt/7wm/qDi//Lkuigur0jmP+cmeVoiiZ9m/9+q+Y2sQBE0MD 88kDB+wAC2haftyVLq+8euAF86WSMnAHU8kGC/AEUzCSSkYJJ3AAs+kJQ/CLeuwKs3CPivAIy+cL H6k1vKnklkMMg7AsfLAHPyH5zvCtBkYLIzAGs6hIFPGDkIQSj28OC3GYHK/3GjGy/O+qfmyrQrHg /pyHaOBw0L4CubRWGGexFqcqhJ4xGqexGq8xGx+oR7UxHMexHM8xHdcxobyxHeexHu8xH/fxHuPx F5dxkwWxAgeyIMsYIYvNEx+yiS2yzzgyI79XIj+nIUdyI1cynmLyo4Qjd+BGEvePJiPcJFcxJIsJ E4voWv6CYLSH6oSysLJIKtOvOo1ynXKkKpsdPwBJLEvSjVilU9onQ9Fy2tiypeWyMSvlRh5TP5Ty +cIUM1MT7DFeO8hh8RmjFkZiIlIzKBffNTaS9WJzN2elTfKgT/JmkBmiK0Pt3T0zWNnhMI6h6Kml O3MeT6KmEpddCqbmaapmE++wXZZkBhblDsdh/jRjZgAa9DdTc/1d8zAqcjrPK3GOEmUipjejJFpq JlFeJmMKZWZOtPshtGtCpEVi9FVeoEXvshjOsz1H4j6/cw/a4efN87AIM7DQ9LVOpDdftEeSdEFT tDizomJapUL/tE4fpGquIjnXZV4S5GOqlCg6NVVmdD0jpkTzpC3Wik37SlaLK07HdFF3dRr69FfH pAAaXFgTNVWXMEvfo11m3k67MzvjcjlLZGfu5Vj/9DlidVwPbkR3NUd/tF0vtTyfY1n35S8L9Sip 9TSf9S5ec176cEoDNlrXtVkHdjyXNGTHylZTLvz6NV4P5V0PNWJ7NvP5cmlzc2jz9CSEsyWO/jRY P/RULPRkD2VanmVbjmETI+Fey/IWqzYArh9K9iRGc2ZAs/U0d3RGuyZIgzZTbeNvkzRxB/RuA4Zs j3Vd76NPX3cya/V0by3jjDb3nQsLrjRV/nNIp6E+u7R5AzRDw2S+MR5JmqZptvdmr0d1i7Vk37dB Pzd0Mzd3w7by9rZnX2RvDnUOGnhOy/MasuAa2qZ45yYDN/ZDdjM436bM3HdJJ+B6zzdws5soDnQW drfDWvKXYjhd+3dFcnNbZ7iFF42Isy6Jk2p9D8yLx3jF1Tj12niuzvis8LiOzyCAq++PD6qPazaO DzkgJzmSZ2qRh3iQL/mNPzlvQ/mNNnkg3x45lc8ylgNzlkeplUPilne5Mof50Iq5l5N5IZv5mUt5 1Kr5hH65LLK5m2u5nI/4nH8onJsnmt+5Ee45JfP5m/s5Kdc5oN9SntOnoBe6ER06qDC6oo9mogeL oz86bRK6j1L6eE76nmg6pq+nknf6cnK6KUc6qOOPqEcxqZf63366qkfmqatcqwvmq/NYrMt6qv93 rbv6rbu4pef6DM06x/n6NwK7Xwl7VBI7Avmxsi87sze7s5sTID+7tE87tVe7tc9JtF+7tm87t3e7 t++6sYe7uI87uZe7uZ87uotPAQAAO1BLAwQKAAAAAABUI9cm30wEgfYZAAD2GQAABgAAAEYxLmdp ZkdJRjg5YZMB8wGAAAAAAAD///8sAAAAAJMB8wEAAv6Mj6nL7Q+jnLTai7PevPsPhuJIluaJpurK tu4Lx/JM1/aN5/rO9/4PDAqHP4DxiEwql8ym8wmNSqfUqvWKzVaJXI/2Cw6Lx+SyWdpNa87stvsN jzvVdMuxjs+H7vr+gu8XKAgBONhXaJhoiKhIx9gIifcYSVTYlADghZPJwEmZ4olp9Ok4ihBqEGrK gSqzqtBKKvJ6SisrhNjKORqb13sL2mkLXESr+rco8UtIDCu83JyTe4o8CH1w3ZAd2TsZrZObVK0d wDdda16+igT7mgkoXq6O6hk/r8ouvn4M//g+3c/dvXbGCh77M+wbOGPUnGnbhw3bQXXzMDVMFbHi Rf5T6yRexJix3i6LGTWWlIduI8OQAk/WK/kSJEGFQM7J/DgO5c2YDk+CnEiv08eJ9+50I7lTlD2f OoOS1HXzZ8+mz2gWc+oAGlGgQnHq9Bj1qMuhOXFuRUoOKdaQDqGm6sZTqVUfNtPa/cq1rNu3VL0m Hcv0q1myftHKXCv16VTBvAKbnLsQcdmpZ6P63MtT8t/Ngi2HJezYa9zOIxUb7otaLuQddbverfx3 L+qOaEtzXmsbJVZ4lNuBBkwR+OzDoyVuW93C0qSlKTWac/dcOXRe/6Tv4ohd5L7p2rU3ZWc8VnV8 1qmBR0dv+7/HxpFHdq/m+AP5ILzBf2H/Pg/6d/5Z5Ne/wn8AbqIJfgkN6N+BCEpToAsCLljCgxDG cB4GFaog4YR7KKhhhwjx5+EGGYY44YgkrsHhiR6aqOIFLKIAomstwpjijCLW6GJCB6ani4Kytada c5NNkI9R2XnGxYs2KoNjBcX5uFGUMgYn5WFV1rKGWg012YOSSxLCpTK1MfPZYioxZhpbfsV42WZs 3uDll1mFGcFuWg1mpmeI5abbaZ05adFuvtApZ52Ezqclov39qadhfD46JAVBwVbKm4VWtYdpOmY1 U55obplmo+cVKVabEQVU3VvhcBfhoZc+ZKlenIX2qS2lApeXnrD9sieWbvKlamyFseLqqx/OEv4q Y7xy6mueHPmKT6OJMmrlaLuWuURRxc4Zq7FA1pesZkiaGimSt4oGE7PyWAsapH92ayi83sYp66eO XSMutYyeyxQ/ivYp26Rnvovhtt5++4FTuE0p4zLLRvowWfhSFXCg6BWnb30GH8xeg7lKyxK5EDM8 LpVoTvxSxeaFdhBRGstrLL2YCqmrPczxWuEwOt95Ycl4NlfXjuWRIPPBRYuYMC7+KXU0ijC/2nQG 8j5N9NLozhD1pVnbkXQQVKtLMNYbGz12iWXP19KwCX4t59YAno02QW7bAbfWdXOsyNxL6o13IHzP +HffegSuIuGC12E4iYkfnsbiK8oBeeSST/5Oec+Mx1t55ppvzvkUl9Pdeeiij17556afjnrqqq/O euuuvw577LLPTnvttt+Oe+667857777/fjrpwlsOPOALsl38N8j7nXyhy/vxfPO3RD+49F9S74v1 ex+vvY3YS9K98Qh+H34i5DtSfuHcp6/4+uyv6P77Gp4fn/zwj29/h/Q3nv/88fc/oP11QYAAHOD/ CngfAlYCgfhrIAP1o8AhRPCBRTggBSEzQa9dMIEW3CBNMlgTD7oHhBUU4WpISBcTnrCDKiQGCrvU wrloBTxHKoqqSBUdk9BQCTckD1j+88IYwiAbgjpZYlqWrlMlpkzDIZMQlVcnUSyxXkvkk/6fXHYd n2nxiZAgohT71B8kTtFZeHqWE7nowiiurDt7GpWaSIZFjLxDjWhM4xl1cyuFSclhOdGjyRZVx094 cUt5DFVM+NgbUP2RZIHkBh2tZC97ZUY44pkWxjzVyEbMMIffkQ6QtsM0mi0lIFsMYiZPYEpwnFIW qWTQKgXJwlcKopUEkqUjUakcuQXLSMwZAS1t2aCqCQcvkCQmKoHZRRMg0lxJDBAyNalMclxykhnr 2jOTESFp3mtUhPvlNaUWzXFYsZjj9OU3sSlMuZWTms485yyP+ca42EaeMHLnO3F5JFTtkjq9RJY9 oRfLfyYpoAKVIEELqkEHIhR9Cl0o//4a6tCBQjSiBp0oRRMawIs+NKMalShHO1rRj4IUo28baUhL alKSQjClKuUgS0so0pey5qAypRBNa4qfm+I0OTrdaTtj6tMaeFOoQXUlUIvqip4iNZxHXWpOLepU nkI1qj9FKVVtOtWr0mh4wtNq9ohkIRd59YOSCivXxurRDsgnRiAaKlqbxYqyivWsb8XF2NZqVkDV 1a4bw+tc9brXmhBPrmL6K2EDq1auKjZbiPXCYh/ruKLerZ+AfeRhwdrYxPpSZn6l62Uza6GvFa2z lcUsaFG0WWta1rSfPa2TRAsu1rb2jq59bQhli9vV1pZI3iTtbP+1W9vCVLfEBW5wef4rKcgqdww4 5ZJbKfHc8DnXddHt3nRbV13tXZd12bXedlfXXel9V3Xhbd5141FD9PKQhxXRp7au40lgeYOx6rUZ jn6U0u8WUWBgFGNq5ghGJrKzYT8L8CYx2VH9frGcTDRwySppKjMCssEUnkx5k6dgaD14TH1Z5m/w 6DMr+jGSDLtw8TKsRDY6yo1jvGIZ14U2W4WywmYyMfBQ/JNCKhKSHh5maTgk4jTlq1/NJa3CdPzG DoPNxzk2boFpfBob/w7HSv4wO+kZmCKmplyauWSUiyzX+hInvs7xDnpEmTNQ6utC9e0RvnIG5twG L86F5S6di/s5KftuvKnTc+/4jP46P/POucst9BfuTNtAI9rJiq4poOfsaN/2edFLnnSkw7zDYNnw vdraZ3d6mJ3p/FBobYYvN4m4EplS+ZAW6++O6fnjnw24jwWe579cll8jL3jDhGE1IOMYnDtN6Ufb wLVJVx3rML6a1xwOWcaCvGy1fTjXhxWYis3C4gAPCdhz3CSxeSNtKIN01cBKZJJ9DccXLzJZtRJZ iSn9mqcgeYro3ra6gaxsRzFa0Lsj9xiB3URjgoyctKJWlwvOr2P7VcydFLWm1RweNJM5HbDiUag7 xa20vfTRpuO37jieZ3gzsuMiL1fILy1nkqOcSYZuuRVKnnIHgfO4NCIWCNnk8f6IbqvbRM0rzVuV JW0PceY/B3pevYwhohc9tXG1Ac6XbnSkOV3pUNeYWuFE9ao79upT97nWt970nhv265oNOw2eTvaE dYuEaE972aUuds+6HbVmx1rW554jrse9tHjPe92T6vW+003vZ7+74JH7d6yO/fDJJbzdA894Jjke 8IuPvKEmr3i5W/7yiR865Dc/J8x7vvKgf4jon0r60iPk9DL/vOp9k3iXby7Gsg9d29ZucsT5c8IQ yjmFcI9g3Weq0v67HvD9VL3h816pbzt+uOun/JEzH4LOLzhDV6955Pf+9pj3fY/rLP2s6q/6W9zo w+XLT3UyQX3G7775qgHglP6F3/dJb3/s37/rTC9S2O2zP9yfb34wJoByRGTEVyLcd38bokwTczHp x1jSRn/B4H9Bp30UmE7LF1pPIA3Ys3MI+H/Wl3rBFH4hWE2tJ4GGpzjkV4LIxSMz4UNS1IIuESv8 h3X1h4Ih0le5h3gQgX6j5oNUwoMHd2uMRnst+IKedipuNmNI6BGWEoEOooLw8jFCF2FX4mBZ1F7e QXEYuBhYGGwi0SxYiB1gsWJJWG6uh4NRGExsJGH6JnD0JUfxR4ACaGsGOGHnYmz+NWapNkzZdyI5 GHysNU3D9ivwF4fPkg9qAQWgQxtduCY7Rm9fBoJ2mIbuV3Y8+IU/mIlACP6GrsZfAkaEmIWHj5hk 2iYZxvZblZiAW+dwNKNpWNKKDVdmZSaGoUiInFhuGveDQfhkm3iDj2OJ1rB7I6hOQYIwo7QexjgQ ptYj6xZzwLiK9xRbXGhV3qOG6KRaOliNgHONg8M57Lc33fhV2USJ4jc/4gg+4cYV+mCL5mg2wTiO gthMNHg/4QiP4GMUAwGEVYJ0K+hS9hiN+DgWyUZwIQaO1niPwtcYOdaGV9aOTZWCoEOKyUeHIuOQ 5QiRqmhaGONnqTIeD8dJxUSMKzWBdMSRAMVUI/mPCIlpWVZ7pZNxLzl7JYmGqFeAN4k3EaN9T+gK 9CFhL4Rfp3g4OjksPP75e4ACYP5ogzhJGkN5h9QYkckFbjV4NUxpNE+pktCYW0BZY5LYN0TJMvPC H5ZgVEyJX/OCldrojRQxhmyZjJloJF+0kZNYVZYhlIIDluNilHzRGD+2Hsm2kMoCWP1ogmYZiNeT lod5CFJBQ0dURaThk7lYlnbplTmZmBV4TyPhR4CpRHJpgXvXlFVpmYyUl4tAHW7pkclYQ+8SmStT S6IZml95mQB4VGGSLVxZmbE5miOTlSTpmWqEiplHmbB5laQJldQnDESHm7B5ljEzm3SplSzXiF3H nIrpPc9ZfhoJftB5goaJmW2DnUqZjjnik2Opi4WXm80JNeG5l+XIVv6RmZTL6Z20KT68qZaD4pZZ yJf01ZZwFUXxOZm6KaDFaZ/W+VULKYfB5poJSoZicp6PV53fiZjG2ZsLpEiauYVgSB7pwXo2OZxW iZYUep9JsplzmEQ8t00dWpgfyqIcU5qlKQnccZoOSKPpxx6ASJXzyZ0HiXwwWikRhKPUqaPZWZ+e 4qONM1gFI5E7Ck8RSp9QmJxx4591WRhHSqKkM5hMmpItqp5CBRdg8ptUei/H6TVdRViEKVVOqqVK in2hN6VL2aNkWqaR9abMMp2gSWwGCqVtanp1Wk8iqqdzCqQqSHlDKp7J8aVS2qBWU6ASOkB303id J5wC2qVnl6huuv6oYspMFWpXYrOkNSOTkeN3sIepZ0ieoao5iZYgWTpwGdmnpPqqpuqH21cMrBo2 zKcjbxamfFd8dGGeeQgK4kE1k0WXuQqmfrqd+iNYCXmBasNW5uSMurSEH/Jpv+iqXlpaSfmkhmel ciqdtmet28ga5cmOgUqtvsGhecRNZ/iWXHdfjJCkp/Ym7QmtvqpXwDqN/dmfVtZMvgh32hqryGqq HfiHy3p0I1pxWCZw7nYlwVlZKdIz8epeNXmtlvpaU7mt5vYxXQZnt+FYo/OZylqrrQVhFqiwlGIX CnuoDfNmtmIf8hqyvdolvzqRSteJQTiIexQt0ZqtnAerUZqpvP56gCMLVgBqrroULdDBsz0Eg1l0 NgB7rD/Lp0urqrRqr2VltI5qFe1Ke9L6DNVKseK6EEiJr8eDpeHqmzPLrBzUJBH7shNLghXrqWea ZQdYnkAbsATbf1fLWxgbHqgaB6O6q7+ptzhosKJYsyJVbJeat07Io+OqnAjrNEJ7LOlUI27rI3A7 q9O3qhebuH+qtVVrc6ITs0PLtw66ZUS6tnGrnKjmspmrHqVrtWqLtam7sjMqht+WZulasjp0KHo4 tUFLuI5bsETroGVrW4H5JFwGe3xIYp8Fu27mMJpLuZwbIOiIuAFXt+/GsGiasJ0ju9bLpnPZqtk7 a7fald27pv6QmXFee643FL7u2JMXe6eqqybn27uVeXCOO2TOCLEcGr9yO79h9rmFVYcy1hOn6IWi gjRtC69vG7tou5L70Xb5y3L5uZ9/i3GbFodMU6mYA65hm7YUTL8nmVbP+J/HgbnTG8HbSa/DSMIk K7nomYpFK5XS277wi3j2u0LGe8HbK0EPcleMaKZ7S7vki74CHHHT6rVJShwZi0GHW2ccCbiQw4ju 28RA5C5GHMOiaMJKtViPO7YBGZMxCGpMPI0i2LI4XHFLXKpQLENSvGT1q5S5ci3ru7nA9b+vy8Jg y3sszKkfSMNHfGtZS5/Aq7JwzLpfG8KpN73D1ayQ+8MuJv6PklSlUgoRBuHBYymw+nhmbazDn8dH vxQ9vWWetqtrlgzE6rKzZ9l2Joq3nVwQgrxhLfsYD8yJ0suGxshLGhy6Q/SeqwwmfnttjnqyZBR4 0YvFS+jERJgqkIipb9mWCGyRpKq0sPy8Y0zLCydrGNmvy3u07zWTonyRtDVilFppC4OZpry64kQu 3frNIPrKsvrJ9fy+nkx6QEFZUcZeuKbL/DxK1PrBFkvGYDNgCWenU3ir8LnOjBvLhTttK9ic+2qQ IGp9/YutBT0zEIfPZwym+aQeSki2fcvGX+vG+VzAFtaJfOmI7ZKL/uyGp3t3L+w0pIuClpMfvTRf F8PTyv5oHRY30HO7zXarwg+szKG8yEvZW3IMeTQNTncbvD8L0RC6smlKyDNdxXIguLIMwBJcMJAa fV0cs05tVmvl0FM71TIr1jNN1CS9zPXczN48wpI81DwbXnd1tiI8wXQ91js6VFKooF2LxnDtJWQt gnzN1vb71wXCtfd80llcLIatogRd1+tixh5dhHIBX76bydK8f6KGKo2cx0oMzMFI0Racb5i4j4rI lru40qu9szlsz5A9r2K8gabdi/6I0KDqa1imzq1WgsaqqPRcw6RtILjNsHWcbRa2RyLJjA/a2KA8 28xc2La9Cd0IcHDMYLrZ24DxfeKcqqoq2ZIKJ9i9wP4LbVxeeJ55MU+526CV5MB8LNvNvCnFK9NN ncE97YqMzMtslo9xibsbfDPKzVXWXd7tjBy/WtL3TN+7Lb7BiuA9LFxSK9XFxm5qjdhNndWBS79v 7cZxvWv2fdX4PbvfmteG68Mkvj5FLd/SDeIaJuJrreL4E98LTttzNd60fNsavd9S011FnNTwwc48 /su2yIA8VeMeHsovPsNRnOKVZ+HZ+Hz7s90UTrWzHMBiu+OVvW8G0YzqGtqX3csIM8c+O7j+mdam O+JQ7sKvDRPnPSv+/NododrD5m1K7slMHs5by9Rsbll2grF5uii/ndyb/I1ePUJ9nn1RXoXxvCZs 1v7Sdslec3zng/3h1R3jGe7nd3TOKjtIXEqcnG7mXH3myYrh2tzXf36zA0PHkXRIc27NRx6pVo7m xMvFmr7ow6zJZ5a0ayzSx4i5ph61pT6wto7i973p8lun/0vsoqvspR17Gw4HWy28tX4j0i45il69 o/eQa37lXV1HQSqkco3rzN7JIiTuoBnIGU3riwrW3kWohUruqE7q5+5B6T7I877lzY7lgYTvVK3v 1x3LaJ3jARTvk7rulM3v4I5G/y7v3qp6Do/wTQ56Es/tAf+a6QYyBZ/gB3/xEG+puboz/qDn/WPx HgryD7/Om8rxHR+5PFyv3f4eM4OBLY9BtU2FE/6/5x//nfP17jfGv1UdyQn/eyIP3wQDtSZkMHQK lRdGjwR49DYvQx6P8kTPP5vy81M2g9h+4iLZrwK19ATqyx6MfcIK8/IT9iEKzaWYYsiQ9Og+g8Q9 6+NaaqBmZkbe5STP9LST9kJ/yRhvWNldh+kMxKityPnT99i78yl3lwhXjEDt91yU+GSP1Dqt37sL 0mPfFYLOLhw8oD1Pag0f93HeFrU2LQKmmRUYscwM3F6/8gnszk80+RHWmH0IrzEN1FCCzlu22QBt 1LcvdASpQrP/GXqIdLqoZURKlIL+3rDv/IYO/TFE/EZ0bq3a3VY4ZMsf+8lP5j3+bI0U9valT/7P HZOeWfeaj8VtJuAdu0ZuH/miT95FCvXuL/UsmeWZHt2WrXOj75xNavUEEB9Tl9sfRjlptQGAm/T2 HwyvTjyyM+PQtGzdF45D9iMnWo7wys4xmNQzBH1F4xFp2Y14SYjQKYGCiIpqFJvVlpbK5pYDlj4f wlPjLFav2YjulzJVaWgrE2qYquPz6fPeRi/QzmuO746wTXGRkeEtjkfOqoMurCeI8sdkKCyPc9Mt U/Oz0A20c9SxrJG1FUhy7OYT9nKl0pQ0l9L2FJVUNBcSFeoqNM0Q1lV52eFR9vm22bd39BJXbsp6 FrfUGO2Nlll8PC6Z7DkVbTr61xe4fUG7+v4QzuX9mjxf/24mkg6bXiJCiTAM5EPQ4D8zGySFm3TM mLN9ExdJ1EHRibl4D7sQpGYFY0hmFs+JjEGvXjCQ0gpubGkSJhuSq2IyIqZyG0h2m3bW9JlRYzNb Q4kWNXoUaVKlS5ka5UgMZZ90UoP+tMqlqj0PWT9erEjzathxM4FsZcjk68tOZMW2xUL2Jlq5KWMp qnSzp1u9YuDWOvu3G7o2f+LpUcd1b+IRQY9BFDb3cWSYhFUhVnzZk5Q/jgXTrSs5pkfKmEnfaHoa dWrVSq/m7cO2tOLVs2nXZsrKdRnDlWP3trcZdtfPoL3a3b0RoOPRvplvBQQ4cOfhg1Eut/70jXNz 7U/8QiZe/Lua3B7HWN7OPG506dPByzyus7Dw8/PBmLeM2HwR0e95UgtEH0Ak7INuvTXGqy4nRKIK kMEWBvSuvbGmmmelBi3UwbYMNdxwNRXkU+fCEGsQ0SxTikklPxJVxGlFsHKqhbwWZXRxRhoxqbDG HNnTcR0efaTiRxCDHLJEIrkxEskdg0wxSR2ZtPDJJmeMkkEqpVzRSgCzvFLELefzkksorwQzzCrH LBPNCYckM80vz2yTSzabkxPOOd+ss0k6fdMTz9j49LPPPO8MlMgU94uoMY0CMsMPQRRacERCjWTy xP80sdRFTHWBB8UX/pQ0MUqPTO9IVe6EVPMKNj8FVS9RT+lpIYeQEy5VFoFkdcl+Xp0qVhpNpPUQ SG/F1UdXE5SHU5cqvGfXBLUitlhdZ0EQUZaeYrHWHFaFtjVps/Xvw06r6QWYYrLcltufDA3WUUTc zS4iqgDZRaGCYow03RrRlS3fHPcNtV99Bw1YxX/3MphgihB2a+GE9WlYLIgdllBKiSceaeCLG7TY Ko41bsVjn0L+2KaMSaZv5NBOFrPilTc22WXtUp4s5gBnNunmmrXIOSSedY7CZ4V/drPlobcLeiKk jdYP5qUxU/php+fkkOqqreZF6qy13prrrr3+GuywIygAADtQSwMEFAAAAAgAPSKQJ7NqKFSpFQAA RogAAAwAAABzdW1tYXJ5Lmh0bWzVXVtz2ziyfneV/wNKU7Wb1LEl6+rLOtqVbTnWOXbskZ2dM/uy BZGQhAlJcAnSlubh/PbT3QAoylZm4khRmFSFAkAS/XWjbwBh8vTq4ea6u7vDTq/6vQssMHb6MHi4 7ncvz+8+spveh4+9azbs/7PKDqp1ts/uP97c9Ia/ntbMVeaOm/5Dj109PNzt93/+OPjnu8pQxMF8 P1UV5qkoFVH6rvI0nU+E+EcoQ1HN4qOq8LNK8fYPvZv+u8r7/of+sPdwO6yw89sPD/0PD+8qv9Cd f9Us5BPpsbGMJiLRTEVsKjV7lFHKJ4J9EvOR4olPnZ7WLD+nZ7cXv8IvlO66f4lGOv7b6dkQT5xD 3/0hXXwJlNj94F/9d//VIEiXiRC+ChmK4C5RvwkvNXdBx3gxlC738eSF0HISsQfBQ3PBRcLHKfsL D+O/saH4TyZ0yi5Vws5VGIIYWP34+Lhab1TrHTaas195FLH3HwcXtx8sqmWQ0PDQO7vus7Pb4UV/ +K7OfhlcPFy9a7UPuqcPQ/h/tZoBEOqCP/xX7JUaVg1v4bS53nZVK8jK8Q8KcNWFwxAPiJHa8gs/ K+/Twc17y0WlcXBQYffD83eV8b4XZ/8O1ERVJ3Jc6RZ6+lw/BZ7r0H4XCK4F0yLyQedI2JqliqVT wcxYhVwGoDoskDAmPIWuQGeH/UtL/R9ikqgs1lW4u9J90XRa63WryCLx/4ecXg0ZOxv2e/+zckAd /o/d07MuqIZ4UonPTk5rZ9Drx0XPcCdeb+7+4+PuTv9RJPN0iuzJCHgGu/CVl5HKQXmcJVJlOpiz 00E3TkQgQxnxZH5aG3QZR4lNORgV2NQYjJU9yXSqMpBQpFLpiSqzwv0kREz9q8yb0lUkXhISmiNW lqVMXQvvE50KeArmsLuTxT6W3B1qPJae5IEdpicxYlqmokrC+1IBPDxn+c35W/aQj/17gliwVoIG l3FQliDgI5XwVD4KBoPxCSj3InAm/px5PGIxT0AKMgbMywolxmOVGCZHAlREQG8p9h2KcCQSNHCd jbSXyBFIZHfH3vxCQin/hHWk4wj4UnuZ1lJFusp+VRnjCWATAVKhjqDjUKZsrrKESR9Gh3pKRIyI RJKoBG78RdB94IK1h+MPXfN0WTt2d3Qqg4DcNJeRtveyUZYCPUMWRIL4YLjegCfjIEog9fe3CDSk zlMepcG8+iqNfSBJRBmMO8DRcQDcgGppAZoMbSgMaFbA1txIBodiJJhRHhi7yBcxGLuIgvkeQMn0 7g6IAYGiAOEWHgQiIPSgYgVFNaOj2QkMF14fABDlS1BCUAFg0hIKuQ+itqbAIggI1LdiUw56gt09 TRXcu1C6iEnAbLQ8xwkqEr5OMhDuABkGZiegv7Mz4fEMLFCSbpMWKSCCo81HAMIMPvepEmejwDGD 5HkKGn0bCeIMoqcP3f8CVjZK1JMGPYXLeED9obBD7oEfEUZmQCwOeCTSPWMwRJ4HMC7ocNDRxtxL 93Z34MyUkzmJBBWJVXQ6D0TFqBzclGngJMDu9ScaPqaAjWQFWI20cvPb3aHBmRPTGtTdE8bzILZU zEDbfZmiXiI+8Pu+5KCMTES/KXNTInQWpM6pYRM4NhhO5JATCzIw9LEBJADa7lfZgPEJpAGWgRTG 1ftkRB8rsMwRGHEKBBRYEJ+DLkhwiTEmIrkpPcGde2RJxuQENJO2B2KcW3osVByQLgFCMMQ04ZFG HQIzx7ucjTh5WRmBhkIJbk8g/QHFrKJ+rRWKhuJRosNBwYI8558PSR5oGqr2f2cg56M9ymnQ2eXx FD1cqk5WZnwmmcNoyt6Y9CeTvoreGlDUZf0AbdP3gYRGrxoCo1Vzvl5Pp3iOx9a2UNqgiprGD0R6 d3FpjHaBZpqm8Umt9vT0VAUHMddPGM5r0zQMwHRrlS5a2sXtOQV4Q+Wo1thjR7UjPBzjod50gOYi fQEKLm8DYorkqNucjUBf3uDw74MM9tjDQ28PFBI0M4qEBv0GPYEx22O/ZWHMwH0i+mq1+tYxWcP+ QpFMoDdihkgaBYhUtM8TsNEUstIMfaVNsXUuoxpkl4jnEdJQQVYLpkfSIq8yAk2211qFwHHFKIMO gtTXIzthPAObSXJXkLs6GGyx7+JYYRSX06o/UoMVjYUBWEuRr+axSADZpyXxfl6dH17mIJh/gASf qxAlhdU0m1VVMqnhRGPlCWSk0PdSQHChCHM/InVD9o3Y2ElBdgWlLcqo9n9GcLUx5svGN1R/l3EB y5fe8gzlUlbyknWynvd5NlzDywzbz0ivvgiJ/dmwEvdmFqizMIT0FOcBvT8f8HtzdWGE754l6I4Z TCTqVTT9SvcOk4r6SSFJtDO9PfDUmLTFpDYYVuKpDJRW8XROQitYzp/F8pW0f4oNoUq3DlPqiwIx qxwGjr3qtSRXEbzs/YzEGjixhTkpZmusR3H4Z5yhYpr5OjJrQakTFmD97ivluhb1hqHeYA9KBdtk u2kIN1lv4b3FFum3DP0WuxMJZRGRt03ybUO+jUshMJeyCdQWAXQMgA4AALd0l8DMtnYH+eSUZg0L IOsYmkokRHaNlJrkWSYCIr7Uy5Z99zWWvR4otDl2ZTK7bdIFa2sYF2uX1N5/+Fh7f3f9V8yTvoMd ICYwxCa43UcRqNjNFx28IiYIg1JrcJBuiQQmlLhKsk2sYLSt7XoqpAq2inYaeUGGU4JtkgYr7bBe jFN7OWM9migMaIED81fOrO50WvuYZE/lZLq7Ey8cGkZND3JsuNan1Z5t4T6sdA8XuM8It1Wq/cs6 8yUtpnBWgwQbMqwaoIY0nOYBkF/MNcyBA9SxBHJvkYChSk9vC/tRpXu0wE4zIXYtJrQ0Q/pfw2UD EK/Mm9Z3lXaaia6yxXo0ZQInaRzkdLuO6qZxQzAgJYHitqjCrNBQbeAEcWtUE+4PB/fnhjQEKahL zABhaLF9M3GQVgUTLmFWioTaFAKMQbLCucIcZKmXRjFHb5yw9xBFcabrfyZXXitHbljIy7YHcQvU wc6MIrTMgl1ugJxEIWQesvIk/XSK9EykLJzRtADbbJCvg8teGSZXU07E5CDhOkOKTTYUE2BKJOwA V6YquIi4z/X+7yJRtSwyC6O4qljZBOlOC4iTaFuFeRcuHHZaLLFINiLeR54QbC1/F0ivXaBHy/7u gn28YhE1NkH7fnBzgTQ7yzSxeR/cLUy/hL8JOhNjFSA3pHb4TKL2LHDnb1a0OhYYCCzZo2dk7dnN kowgZEK0RHrHz+hFitE5FivwKGIjAxip8/MhOYCDl9TAfRmHCSVf5Hxugq5ZIiTC9WXdMWdAnTci TrP8SHQaBTqZhlCPS9g+PiN5dfxdTev85owINQuEMLgLs5aOq3PCrMSnXH/Cde5zXM6cpbs7NwSC nQXK+7QRvn0xygzbRfeDi574bAXhAFp6amyeC+3DwMaEazNiTxTOLEB1CEP7uejxcVSIDwMWF8JA 4KNZqen58+7OqmDZLAbL5h8HS6R1js8NfjpYiyND86exdwBzKYiTvZF9tAIkDsAwtjChsxB0Btl/ LGMRyEgQGBu2EQg+WSyef6Xb/XpUt7e35wZMIweDUmE0wGZzAqjd6aCLcoPRUYkvkt0dfBoViJTm XIMuc7jNsvWWBIo47U4aZKCZM+CUNL9gW5D+d8QTA6b1HIyXKK3h9Ca0WTyqIDPm2YRx67vqwno2 YjRZJDErbhYk258Jz5D6iCe3Jdfh7V2DgFiTqVADQ4Db07aEh6OAwhECMeZSwXy3cGqrkGTkJWSi IjGYzDhV8vbtwuldXBgYRve579d0NtoqhDALUhkHc4OjbWcpqZjAtMGd2yqgwcVHg6WzhMWXjzBH 2iqS63sDxGTf14r7tXvMbrYKgh4ML9wK5OS32EIYPjvHbhXThtYJ6/mPuIDmQ/oTrzvHbdn0wO5u w0VMcDFus9smuo6UmHkiNt66Zd1G3rQR9PfDM+zaWP99qEDKi9kyPkOnvUSF9GyVlNtFKbeLTxsH i2k+uxfpGk+FVpI0CwyHlW7bPGOUkwiXGiHpKKwvMC3We77YzgcaN6UgscYSY/bEJmgM7nuh8rMA iZgxgRZGTTCVf+2TpNU0Gkn9Cfs3rhZrlgO7+wkmYrNURHptFbP0briMLgM+Icm1GRW/udOwtO/l 72JBG5QEG9h4qxAGNxcFCA1aIiEI20Iw6Pf7BQRNhg1bRXDP03OeFDC0mOa4rycVNY8nMP/dJpo+ rTMgGgOmzUzLdkWSJoKHCxAdZlrYFQT6rSKhMFoYm47bhIdNrIZbC0XyiDvRpAj8jbiE2/iGx0it w+4WG7WZimm1KeQxU49AU4qnQsh51lWnGHQ6J58JOD7+qcJakA2dn3ye8hCiIMDu4FoAeONpCJNY j93C3JtvZ3uJxYKLGwSAsAAaWu0oQFIbg/T1960CDnm9hQygoYLo9rCg6ejtgVvwfXPU5scrD3qY kTj0DdybbtBDYUTHMRzhxxztz7g86EPMKgz6Jk5oDHooTOmozREqGn7N0Va0/ZmWhxmYBDlmWjgj MsxAQdMxNEcEDr/maCuh/fm2z507zs+lBTttgKuwDyF/DFuVFrcxVmn1nYplMsocJlmlg0nFMllf DpPMz8GkYpnsKodJhuVgUrE80lS+Q9nG2ZH1ZYqCBvyY41omvnHAuVw79Jc4bvhVmYwp5J5DeYh/ I2Plyj1Nx6k5kpC5Z462MrU/JZI55hAuYuMjXFNfpBzZyKYYJmjbpvLgjzEdzqLUcXDMXIvVnby6 hUi2nP6CC8tDWb5ivD/iGv/gqKTxDHBa7BDOoGKFiKXyuF+RY2wwqDjnK0qEMcItEQZjk0HFYsRS eZICD3cYGJAthjWXFEBxjwV6VKfjATg0KodY3t3R5ow2p7Q5hz8H5eHNC+PA8dZmWLO8UbFUMIXD 2SGcogBUlAupdEgPCaksIC1ReCbB5VCPjFCLWEWJwPKRdkiPGVTc7KFMITbkszwmHEBuM3NZGZTK A1LmvqxeZ1BzIOVa+743LslcMesNFKVcyLJMGa6MFjibKE25EGeZprUqSXOcEMKg6kIYFrezdnH9 4d5gaC3SvWs14bR4IT32IaNXQNzPdSrC0iZ+Qb7qiM9ng3zZUVOxPDDzyQo+6Q0W64tULA/MhnRT EnxsTFUHlMolSvjTRuCQthhV86Qfy1+MdHX/91M5ToeKhNFgZzJl99NsPKY/MN70VOhLMeGDAMJF oNyTAWqhp7sAl7ailtRUNQINLHZAb+rO8ZlKucAmDmzDgE2KYJOygeUObdOi5UtweXnwJmqhBy2G NYuUimWCmWtAG2EmC5hrjf6XAoC4XLD3whMG449+KLuXlonc8OWS5ZcpOyNzyfE621/Cm5QOL88B 5+a/jJiXCDLaeY7XeABZcAHlQrpQBeMECkjLpAYjmarYIe0wqlqkVN5jI286gaPGd2GNvCCBY6pT PI8ndne0OaXNOY0nS8ZePhKHhj/5kkFpOJTM8CgNk5LYM6eJTWn5lJbRtQbyS3kgf45ZpGGj+dyh uwSzrJ4cxJyIRwseHLmpmzEwZVU2sNKhbViEsghXlgnvPBUF6TaZbXAqbmslWmyZOawtBhXEyd5A IdjD6vRteaCKWQx5kkPbZqZuBPvGVAC0KZQJt/az2KHuMKy9zh+s7hW37F6riaSnUU1Gxe80m13A cLPZTaPZ7IAEBby43IRVo0Yqwf8RvWSSDlCcYWNkjirFA5ZQ87a0wrdA21ha4yu7hKUF7URsfTZI ThrZShS2JAm/InCvpjgOVEwPM1rsMlAcX0XJ7vAvsb/D3s/LuwBf6lMnOMD9NdZY/dsB2+zgje1i bIusY7xYjB3Txk88zmytRI9gxnZttkULPePF2uyY9o7gcWZrZUJtt3y2aMFnnO/51GPa4YnHma2V CbVbYG7R0s+4sMBM5T3TNHP1EkHHZeWxg96mFeexhU7lPdM0c/UySV3yOJk57B1m6ga8KZPAqZQX SmWh/0nSJR4O2aLN8pHXZzjXW1TJdPNzW/TiDQO2Yb1444fx4nb/dYsC8DjfgI0lkqbZdU3VkumI g90w6lDQDASOv/bnO+pB84fRA8i9DHTMzrFm5Qkl0gP4tT9l0gOYxjnUoAZQs6ihRKjh1/6UKpqb zbktmvmP8925WELU+Y7cMmFe7MFt0SLAuLgJ11Zcvme24brGdXN283IfpNxm9h07PQ9ff/Wd5rGA gcC4Wey3wrTZAQQ35NctbppqcZuvY6lEe/joZUs50IZ5+ZJNvbC4FtQvBQHz53yUC7PpH2ekGxZ7 6Uc6B7rhkd68SKVD2iRByoVMZdmEmkNtGUnKglTLBBaFN3ZY2yTL8UKs47IpQA61Y4a9gFWWCSyN cw720Iz7uKADpQO7EO2R1dIi3FIJ1+PeVIQuNlSPmW14XQz4TKajHgWtTnbYBU85w/r3SnJyKC7N +RaINjs0CM5CBtBYK19gxrcJO4wN5lrKiXPmgDZzoLNyIZ2I1GFssclrXw70rdHFWY6uzaCyLfvF 7HVhvoX8tfwmjHoWWtw2d32lZ/3WCCki5RBt1loyjGAJ0iFsol3I0hlGjq+FlvFKfJ+JzCpKE0XP SQ6X3h5zGagnek0vnP1O73g5L2BzAfWzEItvVC/XwP0WxtzyAFxgrXzug/t+4jCaCIsti1Qda2X6 YxEFvhjGfe4wY7C1TeUUrnRIW7k85bJ4Zcnk6wC3SbQliydz7fHAeQbc+WMajETThMflwTrlQeqA HjKslUuWyVg4eEcMKt/Nwxdyrh/Qy+tk9G/NH60saRO/bSkfzkRQAuagNlihsWRoRSLp+xYOa5Pl TYh0d+Xb8g/pZvtuvMMT/BbbJOFhmH8I7PXfk/kKFgwK3BWRqEoXM5gBFn2jvtsiT+/GR+eIr1dH I7vTIvPVfqF9AWW38BlOlOvAfL19nJlPpVHbEpGjoqSPiq++7cVx/s3nM/N+wwG+bnvM7RcJX/R1 XOzr+IQN3Gv0Xw7b3Qqspx+7l3KS4UcnTuhd+l+bGbvvHlBn9UrXFFidGfbc+/rxwwNjFfj0kTv6 XDpixNfYV9dKzJfIN3LyDUt+LBOduq9aTGWMH5KIlebBBqk2c6pNoNqj7yADHeFJLfYMgn2epiKM HZLCdyg2iKOV42gRjnQqE/8lxc0RbOcE8ePMF+Zj3vbLAPjefHrb9gYZ7OT08GPOt/aln47iff5y /K940/gzsq0i2cOc7OESmwq02n6jjegPz8xbUHd38I/ofBx/WfxeyXqSaBchHeWQjtjJ8ltRn0lF Pnv19HpvZO0UQRznII5JLi++rRLKWZH+5ijXDxZ+5mA1bbP5/jn5JT/4rHJ6hdBOL28/PLD7wb/6 7/brXfvVZaKNI1pl9Q5+6tt9sh0vxptqZ7cXv1IBPycOhf8HUEsDBBQAAAAIAIMBkCfdCaMLS1MA AMPqAAAKAAAAcGFydDEuaHRtbMRbWXPbRpd9R5X/Qw+naixVuFiys46ifJQs2arRFklOJjM1Dw2g SSIGAXxoQDTz6+ec242FspISnSnNQ2KKArrveu65t1sH7+8uzg8DdfD+ZPoW/yp1cHd2d35yeHp8 /UFdTC8/TM/VzckvY/VqvKdG6np6c6f2DibuIXn+4uRuqt7f3V2PTn7+cPbLj4MbU6TrUZUPVJRn lcmqHwerxXpuzD+WydKM6+K7sYnrQe/ty+nFyY+DdyeXJzfTu6ubgTq+urw7ubz7cfCrvPjSqqWe J5GaJdnclFblmVokVt0nWaXnRn006zDXZcw1DyZOlYOjq7e/Hb4IXgQHp1hN3Z7918mPoz18czqi bm+NTeaZujN6eXB0w68f0fhgwnfxy4P3N26t68N/y0Jb/Hvv41//Hw8eHfZE+Gr/8FqXldpTP/jV DyZHh4+v/PAj5dg7vFsY5XS4LvPfTVQNqUBsbFQmRZXANjqLVbFI0tzmxWINi+wdPmn95mPvB2cb qK/U0c3J9D/4Q+MwWy+XulwPoMH08PN3EBU3J6ftY+NFtUz/tX3n1n3gq6JZ74UC9tl/8Pil+VQp /kLt7O/2XnqiC/pL77mlC2e8weEeIvttz3r5TFWtif1TsqOo9eUbnk5/5mb76rQ0/6yRF+laTe1H E6ufa2O5td1um78lyp7IAtWve4HybLvvu9331V2ep8+p9mu38Ws1LaNFUsG1dWmecf83bv836tqU s7xc6ix6zu2/dtt/rY7zZaGrJEzSpHpOx3/jBPgGAthqcl0mkZlc1/CFtsD2TpC/k2h5mcyTzHKn 14poOTcZ0N5uZvb1l2T23xOKOafeJ7bKy2ezOfdFtu2LIYA8Js6X6t3lh8m76/OXwB79/5AHlAmJ +Bqwe2/SvIDnnWO8eH2Z1A8qsRYAKVUNcZKmBiTg2TCDsiJp3zwvUnFX5CrzNIvS2qI4POfWyNJv 1LQoTBYnn9SUW6uz2GirgFlKKx8737wZhUkFKjZfvAiKDtBYNSNjLZ6NhWY9l9zfDg6/7eQ+Erl9 UI1O91ScGMSW0WoCamorNYHUOvoIaokARAG0SaRTxlipo8qUSNQkss8l+3eDw+862Y9F9nMzh0A+ /iekvzBv0n7196Fy4cCIUPlGTRW9CZB0ALl4XqC62L8QMUBJ8PG5dr27m7pdAZB302fbtdTxzdnt sdsaRQo/J2SAcC2//7+pg2i/bFVqNElSC7+WEuASUvV+16fgf0X7N3/nGbt0Ap4kSx8QHByjczu5 OTz4ABWeRK7ZCaFHmuCFSfPy9WHQ3+1JVgi6zmhe5nWhWPIz0+wJaFo3W1p8oytVlWtV5QC1NM1X 8pD5pJdFapRd5KssCNfy5XmS1Z+aV4dqtUiiBX+8BwbKOlpleTaK8uXSlJKf+GVcQ7NIZ8rWZaGt Dcwn5LZN7o3rz8q8KBNTobtpnrZj9VCDCo9YiqgLNNXYDCoNShMlhRkE+JrSvUfnuwKsybLkdTWw q+lvV3mZxkNlsU9FlFsl1ULeGiyg9Brb6CQdwEQBrRM1b7cVGOVXbJdElNej+pjueapLIHFdocZH rbtXmn7B5lrFQGPU+0o2CQ2AOKOUYQ2bzihItcq9KWwBqmoDKrmsYX8zQ7mpLNxh1ELDqhDeiKlU qbFcSaVDuJKv4yVXubAf1bYAev5SlotSAzdtkA6aKYcQViNyZ0nUMBRX5FjjxgDn6qVVi7wwPpgW /JCUcaCryiyLivHHL+d5HksgcjMfL7BFlVfrglulKVRXEUSrSMiydZVAE5vnWd/Q29j8YYIxDLGF mFAh53NlwbxKBOoOAqvMPyVLNAM+MrO8QhosdG351W5ARIHDSpXqNYcvogGjP4nF6F0fIa9jeYNY weruyyCuy8Z8aTJr07GRbWdWgvIxiH9lEEO223xW8fMugAHZ/zStRw2tR90uFtTNMcYzijPTCNxg J6wRLvByYQ3SOCyTGERyPB7vyjbb7HKcQ9QzIsUSjbyW5j3YSVC6YZVaSAR2GdJqpblPyN/srvpv xqBHmKE63cN/+/jvNUT4ny8Swaod9jalE0C2m+klzG7sbvBgt+NX/B/2NFW0/W5nLBfAKGL4ranE tB+sKUdUjllWEhnQyDlWstXaID0pmJesfQSKA0RsvbbFYleFGAKhdru2SEDENvIoJroIgI/S5CPs ssWKb0skQLmNQj1V7NMTdgroleRCdSb/s2CqAHkOiOBCRpX/SVKFQJ0T4Fy5WJLJJssCYKgzPyNL bMAUe+i0/swD8W8i5LhRieDDy0pAaKHRXInNBJckoQXIgAqBRg0lL2aB4zaCBMQWc5+nQI/VwmQO Bk20yPI0n68nQrQlQP3iY3XlHhIdAN1ZPBRpF00dWwJ5WoAJXUBs4gzrA1/psRgSe5UiCDtbjIGE WoRfLVwhTzqDWJb4Oo1VWWecJ2sojO1KikiI6loYqX396mCHAb4eMHQjJuGgM0TPhHjEroCu+Nja JayBOJV/xG5RRqdSnKGhpPe6LRoPrJO6yqWMRoF09qUHzScToayLCFajtuhemA4DWgAVktW2eSBv c8lKLjksjU3KhOgeg/J1CtvLpnEym5kScBj0zIxKuzBxnXKpsoZ/wEUKIxypRLnH2iUkKDgHcnv0 2kjwoRMq0lfcGzlpoNew4LTVbDBL9T1QCC5hsiNgW6FUVi9DyA7XbkSBt02swPWidUSo7N5ZmiU6 IGWTPyh4pyBYVdx828SiRdWS8PVx1SZtCISeIYkkefEkUm6GUs9AannGDinNbrB9YAi/ivOopjEY 6hq0p45dKYaYH4VOaU6/WA4q6QDQRyafs/F+iA+DFjsbpsKFuOgsKZGePa7LUqe6MqR2ojw2mebr g9O9wS5hqickeXCKlHXcqLepdnAj2CGNeIje3JE3TzpS8m1HeqO6FA+B41UNpQgGKHIDFy5aWHOJ 0Itc3OslFpLultaI4B4b1VYKM9NfSC6oMLVMEZaBpzLCzN0KmVmRYoIB7Yglc0vEyx3vpKzOw/fa J9aulzUQhEYwUF4gVmSKpv8Q3hoaoIMXx8Tb+h6ZQr7hjn9CY3sO9SlTLWDD+QI4br3zkg3i4gZr MJpvP45fBWJCB/pIEBlA3ZvG9BvUsumGmJcScgQmVhWHPoKP4gzYoWF88OnKJfuypvtsu7Hznc9x rOJZeyoWZN2zCVTSpTTJwWeMHTlIcIt14SnZVsY0XR6JFjuk9rMa7cJuU+BKXSRxuvbBAWFRaRh/ y9y3X+5DfE/4ijdirAvtf9ZOY9jXm1i3OXmPaBGHDn3ZhQiZNDVQfpnH7EWc09qWox+1Ss9L4xrG pf4Ih54JF9hk9Mok9M3QCaxJPebeRURfK1OIGdZR0ofMUkBl7dz0W15LnQXargMDAyBr5y4pedaL AJQy4+Kk077jGlke5rEvX3FOHengdV6Lp5phh+/5Dz4c3tKhsZsSi2ekhnBg8EFmBDxDVgd1KofJ /Jgmh2JZP90XRAQ/QetdJrIAhJPOHXujeyty6+hrlQd+G9ec+dqfkBiE+g+ty5Gt1njQZPdJmWdc a+wHKlHiXVzSe+Qs657yPr0yi+a/fhRrxsGG9KbJPeCdjvkQBbnPZVaxQlLtVP3YCQYR290Y+Ems BVNgq0m//p4nDR1jk+3EaJw04qrQOAt6XzblKJ+x55VOecBVIMRAbIEoXOn1WKmTe6E0wMBAMi9F YlaO9UDwj1m+Alg7JkW06LuQ6U3gC5itUIW9YT9+HppDZcJIXKma8zNU91NdsIlcIQr9WMuxwNBg zcadlAk5lK47eApN8xW85DaVQYHjQJqnI8G763PpF6AYcNsa2Ug72zaLaBc4aicR2dYOzol0Mywl 9ZI1S9sKpQDpuCmoJF9Wo8kR/OLP1qQpqXACmrLKlNxIkBk6+hDXn/u2UuYjpISOLziJ3O55ENL7 iEKmMNW+R6iJqHqOsjt+0TfvrzIQV1qIizex+VSVhji6DMkSapuRVcsvu8QaBpRhRWOj25R0oilC lknmDllpQzjoWjRghkSUjI8nBPksEIhpWZNkmkyrHEXjOIRHgul6Y1TWNAlDRA+3F82JWmSAdGGV pPxeiFgdURRA+EZI3UA5UsGhklTzMNqcPfWOBpt1DsJDZNrBJDwE8FfJiM1pSvjE5ws2B1Ri6Fo1 RX+6X3GQw+geK2flQGZeUGbk9/qXvlSXVABgi/gewob8AaWzyDNBV/keQJRUzvkFw4oFS3Be6pFE mGuIyG0ZLCX8B3Bajh1MToCTW095mxnv6fTnx+e7f3Wf4SmT3XPkhy9tePUH9Xpv8urryfffS9d9 cHbY/gqo6q4DDdX3k729yd73eGhyJldbNgXd85IefXbFwQvEygH5f97Dfr+ykMZ5w5zoQ8dwQC39 2PAn0aB4IpV4EUyx7FnlFnC8u4Urx5b8YNAdVKPaeoSTNniDhiv/7lB5KPcnt4rVxIy3kEkYltOT ZaNTTtJQsm8JcJMkc4uz2gd9ZEHT3yX16Z6A0VD9zm4d9AFFvP8gSMcKTGzdHBlGebFmZgu8TtxE vYVf6UUydfx2dHN1AZ5xNQvILQi7WPZlaTwfyV2UC7tw820Ho/ajcB48WwYzdIAIfHaMofxahNLo uVZIoArtqO0Db9wwEMHcoKZVu3mPGJiRsi+RshbboTdJiXeoY1cSKTsrQZKrvsevUGF2vyhyHAMQ ACP7YS3RQtbT7lIX+6Og6UfZOoemWhk/ZeDW6laGcfDpvTB9xz97MRcwrGTU6mYu/jkHVmHiWAxf SDnNFrDMfCN0yrhT2wSegGIz+U6M4L9im8hMQHEy7Ox6YgeMU46klpzMy4vioZkHafjaTa6Grmi7 aBaXxAG6GyF4NcDTs+h5rUtgMl4eq9O6JP3tMzRX+CzrJnW1ge9AZnJwQHdsk2nArKmjDdCzaVg8 J2bq7iAB1HVah3hGnfvnmuHAA7ecUgIh/LvUA2kqxwT4GenJIbaHBR1aX1Y3m4lGjMoPwqQ36rro QTtzk5qWEnUQZtcyv6/WA0k/ErYAu8atBoiM0qCJb49FZB4yaGr5oDtlcr94fPFxcMtJEDsaEM0h n/dx39AmfEVrpGRywkBa/1MdGROGPEiA68p7mVa88MdYtvrhyVPbF8Gorf4+sCj6o0IjPTOOFYhb br4lUgiv2Xj5OnjspNO3fYxqsDisNHOopoWoOFzTlZZknZ6fyxctnwqSTCZjrrLKdMOdGRFdAcXj L9W4JNuwZmQyIINhrveSynW1gJr1X1jFj4v/hgRtKWjst81aTS99eXWnCpdXWJhk97MDVWC89Tv4 pKj88Sv72zPOZnM0NbRvQGolLepDIu36celkw7VrzenRcUA6IkfpTjJ3etUjJvvNVdmj/vXHR0kJ acLJ2yn24hNShpmLDLAvLyoLbd24Sas0l2FYbEIZoBFGEhvYOnRxelbJpevEHdMiq9sK8wu6kTR3 s8Bf3r89Z8V4mcqRdwjrrCki0pBjMU6nmzljmFeLLVH0V0/v3dBKToebMY+Hx40JEKC2RrHKgd8r EAD0GUTH452vvtqVqhbJWFan1qWpFNcMpGBA/w46YweuUJUyJje69BT+ZY8I8f3PT/sBr1XABrFA y1yRuunMjcGa8QcDT8alDK3Syjq97iZoFBv7QOrH0QbDfb0ZSJvXWf+E5L70Q0c31B5V+ciPtzes eIZ6p3mGHXIQ8JOCH65KCQ5ekFEOIxiCZ4ctIdLtLJ+rNp8353PSTJM4OYtwgNfNWewXxfTF/oXc JUCxBl/RTjt+0Q5TO7ZKCGBMScbb7qoB9ZC8X+i4PUbAc76tjUVPGejxLw1QhPBE8Ji2G1YEuIu+ nJMpXi2Rv4T4BNqN+I3YFAaIVFTmtdqReuJPQhhbVvtzeFaZvDS72yAhJL9zrl75+SBhm+NfP626 vTlCAHBugL4QOZDeS+MD7zJ/U7MMPF1PtXXX4cRTfeUeBOdTRELgyCDOH0n146J1Go8FcvLx0Mzy 0ueKn/J7si+3WMDhHM7+CUv/zTUMbL3l8MMFsgwBYWJ2W6eoBl8Ub3odmi29cZmP1RG8uUpiABfd WpDEyVmEt7gd/5k6r33TEefkwoR/Wxc83FS3F9dfpALfcyNRKeSj/mjlwakAMPt2DYgj01EXdVol o2uXrwTELfZ9UB6qco2EmwlwsNfeExJ7CtftblkfGM88YWoHcg5j1AB7QXppMeS0ZeD4EdNcHpV5 OEefjTnPTk5O1CzN3ZGng293Xmhl8Lcy/oi8eaGXIMHtxZ0/JW1ZfIcvMpBdadBbD7ZRvpCerTvD NaR1kYkDPxpGZy1Vju3l7SjUxLHC3VHtMtd1nDJRYsWRoiLtFWf2gbTzXib2MpGO2CRwGSM3uhgD 93kSOy4U1lbZLM8L27aJyMjKBHJa5oN3/Ai5eTAgerNZlTb+yOHPJi8Ub2VkQh9JQCBJl0L2+xeK W8PCOMe99H1yFyr5a2jm0UfYnZcnfhiBF1zyKlTJKSdbEF4lk/tcuZqbSgbUza/74mwX/Q6KfAyB 6i9kXiqXwvoqNhxhZQLBOaezjUrOLNTOp+++YebaVI4Aenc3Fu6oM+zuYqV+Jp+nnGeDvKN7Egr0 UuasqDvSAAqZmUfRxMyj5oxOKF/AhZKU48h++XToxeh30xuQpaefr0nCnp9dfvhPWebd8bEwLGai yxcwvLk06bzwyH37tnFd7tIalqtxcNq/2MSlmnEBL5OAn9+eXbyVRkp4n+RZhD7FsdmuZ/JaBk1z 7A/vNjrkTnPu06SsHE2SeahBmOcV76AUAz9JDrrcbwrldpDWnoP681vmqhzGS6Pooqe12cXV9e3k 4uz61t2xCZoDrSHMK9OLPbXjz/l4YiE3vJfCKoQOAM9MWSQF2E5mOgcE7emibBKluZxuy5g3EolK XjFpzmflYBZdFwGsvfkzlsmPR70WRZrD3fukZAtJ9dyon9dkNm6RqEUi5/s8YJ0ndPttA8Rs+eOk GyntvXp18f4PB4KyyF7/jgdP6JADcpmBUgdyzcPdW9KWFm6sinUUTJ5K+Suaa3WMRKAAtIvHvjHz Z2+hlkWhRtAkpJ+X9BwlvbGD8wEycqB2YDhd7D5iMve09CmI5qAnFt3sl1FEgg0+pqaxj1e8XWft pSio3GaCEusP5aSAMvIaEmdxjoQ1VzKN/igR5e+EOS8/Afi/3gT+B39e9hj0M5G6/NoAL6cntfyp PeZ9OsiDcG03FS+7A73Lqz+5btYNV4MOEChh18FssyvPBtwloQXQXI566gw2yWJejDBNG+scmvAP gGITcDtu3f3a8ho0UOhulWRDflgZXtmz7UrodEw6c9OcYLXIUzO6Pn5kgaM8WnD6kfmrAfC9Na1s DBdaKMiMAyEK23D5hxfFhu2i7ZhfLhoEbldmllibVE3uRgHlkpI3slHYtp2y8kBX8ktsGTpY9M03 1CZRFVuEKa0ht/CgjEx3qYNIN+EY6uj2rSAGh5w/NWy8jffChXtzCkDxz/rnv0Vaz3vB7MgXh2fs o28Bnci1b4fqllgrHzh72fP/7vt/p4BlWlT+kP0LT5xeCrPPs3lOzd1oZ0ubvmN1lHNluZDXNGho Uo2mmzgp/OzmmEQHDdJOyFgWnObfcg7C2F36UQj1s9t0UTdAaexI2Dg6u7ptUifk9UM/6Bm6btHd 7LbdE4A7na5RW4YNsfUTZjBy8hf3NyHNe5OeB6yvn18gKIPEiu4T9Hp20tU+97cUNIZsKZK4P0gI Bk2h5KYDp0/3Is8LIS3CeOjmVly4JVCoO7M69Y07/xCl2UGU9i2LtMIedGcoEq60eTcKuWyuXLsz v2Vz0CYL7XBo0jtyQ2zVc7YkuyIY4TI1n/63tW9tbuNIsv1eEf4PbezsDKkBQZF62EPZ8lCUZHNH lBiUZM9G3IiJJtAkegWgaXRDNB037m+/eU5mVlWDlC141hGjIcFGd3U98nny5B+YLLi415V5uNel AXRKDTZfVFWCLRJUdtEDA4jM6No/YGUdvjr94ZAAGFhOivPgvQxO4K7qeeWzhx10jTKYy2mSyHLW Xvy48zDNXN9odBHwO+69nC7Z1B+q5aLyQG92D338HxEHaqS7atOX0FDqqHjDo4jPWiKFtABKLTZa +DLR/e8nNA3DrPJqFX2mlOrREFsG9NlQ8jxbdRbpvTYIuCVuHcUao745mAgRW7VWLfxb3cKVajRN zf5WFXxduV8f+CR9LvNmVXqZ0eiTS/fQl072yuWynNvC9dSCAcvTYv6RVXT/hasSnTXfZ2t24LOy 1WRa6Mtm1di2sVLwvCetM5V1d4J+U0Ui7pKZyfDkFAqdOVcX9YVsnAw2LIMVGz++r59BfsWBgpnF KLtFRBSlGl0zAHDFsQ0pqkLQa9e4n1fQ+9yFwQCz5o4Q+5pR+7hv1H6CsuBTxm1vK5yvkEWxIy3y eyJn7g/uBsYn2mbDMGSnQWHfA9FG4i+O5MWcQlTIekTEALQAaj08nZlDWr/8rTDsD8211umtSTTW g/zBd1ctAXAhY3leLCObZ4qnQZcTy1BONoXG0CRQqGip1igkPYJrV109ZyF4AUwT6l/UIioX5gqo 8cnXSrV0sG3fv/2TeG7Dor4o5P/Ftbyu8sF99toxu8m0VfbCMYEHaAVseSoxrpBoaYTRs/iJ1teg XsHXXAOCanOosZHKI2BbGDgYLwVIwWymt9DogjpFerLOITFtW7VVHI3DElLKNMUFiNkKfxSHZuQe d2PRfp/u425EWi9h+zkLIzvS5p8Qv1Z11RQJwwV1pGNlVLPSHI/gcnhqard6BVdHfGezCAjmEWJk RUSau4nWawHAbDNhILDzc4VKHL1RxJOVK7lsqRbiakEvntWucnIKw21ywB8qka3NIqrYPo49BkZd jUUUw6FVu9YKzMXbyNeHwRNoP0cAYElAoG2HNBlMhqXqh3LR4nBMVAYtWIttASim7QNfGPEcrSVV x1Y3rroV6YnnFQsy+AapLC5FV5HdU6ObG9FTumq/Tau5iBpCw2lZd0CtiVzB3fRxF4b7gL9KExFP YzwMp4IBUZCFYccqqpgW/LciAf5TzonYz9+iDgSO0OVYzsPy28F/vHz4cv/li0FRjMV/vyongA5/ +4i/tVcE2Xx7XxyDpXjx397H2eiWT7/pJoTI58dknWnsgf328vDoxbeDw7Pjw1cDjTBmWNc+D5IR kkVesqCKrUdfdsdNg7ji4owVz2GDzFqx2XbNtXJUN5eGEe2z8qKsZsVZVc+ajwp1OavBuTEpvm8a hpvyUQS+2aPicHUJS23vb3/7utBBySx/8+Lk6WHOZgMqkp08cmwUJf369cyarRcw4wEHH4qGOd+5 1qLmmUgtlHawXCJD/H+zK0/k+tq0cySZaNpLRsPvzlqfC+jW3K8Jwc+kgqANz3R4BFva3CgOXxOp V6hz9GM5ryeImsv1sE1ChdoElP0YuDxFvwjGahaXOzz4yUyUg4WqKOoofhLUnYnzHDVCvZRnM6og d9j2iC/hR3m5170NCndgMUKxugRQObZorhqUQXN/TY3cQfY8GVQUJ7cI68ErcXPp2jmsTd9Cz/33 y1Jhlyx7TgXKwUWz6TpVjnL/geaZdvJay0EWpQuuEAzeB7UgVplbD8tqVmZ5CCLjdXf23yK0BqIb Fs2qm5R0VcvrD9c4UBibKGhWc0D1HK2V+YkZVVzKvLXhWrU4bCuNqR0X5VwGcVEttXp/g1wPloR7 ofoF2DyE9gneLNVVlJunrVPbfBCq2VpcBpViLP7Fm2u53kUEQpq30jUd0wcve1UE2VlFOb6uXA6Z fuLQeQ2AOyrZriO60So+YLchWmhBGtsUtVbZi/U0/lBcX1+PLherUbO83B4VMHmh/4a8LArZug1Z cYxRUzDM4wjbu+obqJU119AhDjJrtYxQJm9qPBfi1GlAqcvYY375+rGljE+PNlixlzAbLAPK0yT7 bVlXRldBrADch66ru9WEGw/qUfaoFmkEK3krMohidFJ7gFagplYLckUQlwFKD/lKNx1jV19ajrbv vquFPZEDofOV+/88AlnuQFzkmNgbqggUf6VDXWY/cqnbz084ItQXOgd+wUcAUGWoKpzkw/6LECpm BXZyrZwicbuXq3lDTDmnDY9oi3fN8mM5m2ighdYGSkFr4lXvmDUxAm0OzpFVu6Q8c7xG8fr5oVcc 4+R4IBQIqMg9EUR0V4kI9NrSSU59glLkGLRpr+qlcT7lb4ca/TCl3EHWYEi0RKHGqC/RWlr13Ewu pJuXqTwxrGerWNgYK6jEqquuKPmvGXTN8/9eMxHUml4t6OJ4GEDu65BhjVfidFhWQctneH8b7Hjm KIkNDsWxW73VRyIAUM1gdDOTIq/adX3xsVSogKbcMdQ1OHe2c4emDjNsGQOrdZs+GYXTVdfZ3QEf vG56DnjXiBRjKeexqL96/AElbUsQ50wKB8VhZ4vbxkJ5BlfN/srsriHwnQt7zNyXLt9fACsEF4Ii lmYUzTcqKvS44S//xNvKems4SZHvM9SXLi8rY1qrRqORezMLvQkWDYP7svjBSh/58PGy/FUEknEH 4V2GYV4tLz1RTPzlAgRAsc6JN74wfH+tfHWZyZm98kFmW50+XXMv9zew4T6TV/EuuzqZdp9L8wXF ahi4ItU7R9dHXuo9yJyLb14dP024seu472RVzB6OcA4jLzC7UDOFURkyODcrTrNShbb67pvdV3Dg 73jMPBXnJAltVrf5yi0ht4gUa86Atg6LnLkpxCylfYjz0TZRiigM4RxJ7TbQFFI7vVzkJa1RqvFq Xf8tTBHsv5Wf0kDmCtNDVkwdcVVtrkwVyxzVNBY53FZk2/0JQdzLME1xOo7WKmB9SuTnegm9Manm DYA+Mss6DSublaECvWAaUtGsWgVNtKslLWWODgxN5aKp1ZlqURXQtZ8clbsAqfhWIQoiQ71yRqTw vUjDcC/cc6tcjZIyk98xviNf2UeMKwK1II9DrIRfNzy1JJlimlvQBJnB6YNX1mNttnA3FeM+1d/s Yp9/tjtkOT/TfyZERawSbzYGlARvkKhFWfGj9SPltqqAzKOkjJEVyUx9XKJUKFTWPW0nl/NO53on bvW79kJWfLybW6EmK0OdF15ceeHFEmHKNot+yBGJW1ZBvbj7JjwIIqYpzOXVNS2y9Rtvv019qAC3 zqqXbjG4jl2N0EBI3oi+cvQF1Ixbqs9zGync4qUs5F93B4zafWYQdW+7OGmWtzEmWJDcYBz9VMUa 7kLZrAKr1IAHHI/V8urzLTlq0L+F2yWvN/RqRqbV7EpOsEzrJUE3CMThNEU2GNWpnC0N5zah9eLM 264bRK887rviWQID1pr9kvOzQAGPGD0euFdZU7Bo5ba5FzNHQ8bAfYn6EH6YXng/nn4MjGanorcw SP/a+CaUqIpud+TBOwpokIN8T+5/b82K9vTZJkDC/e3iZUnIvTl4uSk/Eg2PHO0CqXLx4LA7SzUb g3M74junR2vn9Jq59Npr5dbvC5glCBcHCJUaNmCg0DoqYV21Vkx8uwK19m032HajMNSTumlvZLpk qqs8874rY3En3hBnDFqYJ6gVmeJOx1AlMJqwutdQSor5tBhAQhkAgTwJzflHB7l208QwkQf0ZUQR Aq751ki7IJsI5TTUhr1ZSUgCGY4B2uSBVPKqaIbmf4l71WXxjN5dcMaGNoVwu2Y3URXh4bn8YeDm xr64o250HmHZxOftG4o0WiMfyK38cR8d368Q9WyHkvcCOLOVobHwpwHgg+LhjtuBT6kF04lB9qTS tWoqnET3KXoDGZh8lZ2HDW2LCs3WgnBI8wSf5PkBVn7kiZBqEmSwOwjdafKKM+v46trxLwVyWCPQ fSyVzYDuLuhf1DDnwdGM3MHO9udPfoyVoGgXsSKRJ3MmtleGe3MnpIUrNDQdK95tpqexZogs2VQW GgFSm4rHQRbmfFuDJJnODa5zPXR3t25VjuVRnzHh1Jlmeh7Dgw08hs9kPQ+fYD3/X4wSP69n5/Km st2WXYOUBqr1uR4z1mQgmXfQm+B7tRiBpUIJecZheU7qy/mXhcIhbAOfuzrhbDat7RtkwhFNDNHe U2U1v6o6LWMvHamBwPsVoO4mKWWbl0x9XoQU6dByLN7kp+q8ILFpl7yZzPMAItds0WFQQoXMV8ud op6KhehM8CQGQbDXgyiWHn3QlxvFRhlkhRlquUNsYzHoK/Hf3kT/zYMPZauZeFY5wy3KbGPL+hof yfGzE3r7J03XLJtZyZXAszRkKtoDy3C+bD7ABMXHNk+wxdvobwVRC+MZyM2YemuT+QYh7LGtFHpy tIsVI4fM2LD7U0ti8gzx/fNKK/V5Q7yl8t2o/bcAd6nM/Bn50qCvZA1uiu+pDZAevaw/soAV2w9l txqdpkjVanP3hgaK0Be9IQIkgoVGxRvd0LJ28jK6F+hqhZ73+ckcUMHiLSXCxZ6WyzdACQYNGFLk 0a5jcETpNLOQfyxO5e2pXX9YyZuEs8pYVvP3wly+WV7KXPxaWhxYpqNhoZUeY6MTCyxIhA3tetgq pHBGflRIPohl4wYbFhpM1J1Ra5WwwoPtqFtAe4L85+LSMep+r9fNAlVjovtDPkCOi7cCxw3BJ7kk dHHjEyXvnTF4ySjufFk1z2PutgS3dSdbDcZX+vqoOGG9QreawAyDMBlHUMeHqqJYvqqaK3Vq2znQ /TwPEzsQwxS9VxoARGW5Buq0zEjan1GTwm60snQxkSDohh58UYdRV172mRwOZDATWWFgAmW1tArt Kp7KISbnX/Ke/+LMMeJh4ADo0AUC89OwJkoZrlZtC++/RuIaHGMqmVeXlzd2ZEGKHDyAAGn0rq9B 7w6iw3n3MvsLvgiQaOWsIk2nmfogUNy1dFueHlTwTbTQFWGjIZBPH8WyZtJAbbdMoDvHSCyo9n2J c1aPVxqX5FTnun83olRY2PexnK0qTrTL+RH9yMYNFzMCyRVfGFhfc6glTLLhrTnyQIIs3XkFqhGu nqa+Uj15MAlD4u2RhzzefHbIo5+HIi+grIeF6llfhYNnHOlTAAtzzxuC1L+T4goG1NPQQhMlaDnz oKNHmbTAUiSXmtWYnmpGe5NUZnUr1gbCVliz2nubIA2fFLecjnntlln1sVYcxUBkelvRfH5WTqwd yVY33/5OTI8m4v7wrf9ZGfXctcLevketHU6cfNFCSGbEcdiHKoztSSjVXJmmStyXDRMq7W7G3Cpy QQkCiozhXGmL8OwcCVscwh0cki6UAwVp4KTyik+lirWcGWphwKu3+C4/gD/5N3WrVewFMnMN+1vB oe/CsfkgSHbOqotu4B6TBe447rI19pgEE/iONp0xAeAiJVryDIz6GOb09Qfr0CSSxQBEHWM+VMkq IbVEKyNlhNmVbYPvrEBUYQj05kVyD3Ua3Bc+N7I727gePZNfI3AUPyuK3e6bD/XYYI19i3EFBpCM 4OFFT8Az9TeENmT4RowQSuhJYxI6z+fWJE8e8OQNcHBCJqb8PY9pdmdclHJmYMUYGQpe6MorQoPu Mh/abv4wCoy1bQNBygUkRw2VG5gH5LpUhOX6lgU+Msf6p1B3uYE3OF/dDHQFUJ1Zyv5qbsoZ5Env kUcIyJdLMs82Rcb35LJ4qFK4nK35p22kzDEzwBZFJUqj2NQoiN/5DgxrXm4KZ182nEors7sHpPc9 2rEWtCiZEoqJCDml8iX0xQClt50LG0PkGpqJlqxyjoKgxwBHA5iCFgm4azFwIAsnTUwDfGxmkOlQ dSD7ueqsTioAsjdxluyqH+BO8OTf9+YsyN3PCHk4mKeOHKSs4IxhnbjllCqxWFuA/sweyPpqfslN AnsmM+UpkuQFvJ8CH5msF8trBfsJXLdzlHPih7IS1V6uOvtt1TUER1bp9AVl9hFbJtm2pZnx2vBj eBsFpk+W/XWBBegP1ZPFXFAYF1BIquc8BBf0+wZj8ixvHMixuwLTvIcJhamaj0vQByvLHcKko8tR AQbKCfSgPyPla/oi1NM1MlcI+VlJX/R7b0T/xOJtqNxZBt+PgLe1mx+VZn33repbuQkKWZ31bPNE DlvqdVmvetz6aoroKA6XdA6ssCkFAMpexIBbZC0x9l0RR+aXsawM2ipPC/z46u2xW6q3TkwK1PRC NA83CNHEZm+30rbredsN8FAGrsLEteWNTMhBMTDtQxoHaBVyOcDJhTkcprSWxRQfOP8QBfSAJrYS rSk7VCyN6PtPytGKP6hjnH1vSomA+uVldbUyyemMjYw4XxH7FTolOxr0bXCGuPlsGdrbFCee25Zh nX1DIoquyVhfcYqRuW2vyCe3aqP9MStZgDMWXf6E2LMUsS7EhciYXHA1oz2GAfaQZ4mN3pl3Evr5 3WTXV+1BQYAjSFavW3emcjrmlkjQ0Irqlh/ffn/yavf0+ctddEouepg9PrqaEPu8y+CBVrgmGqfi BELeM9/14mJZOowZEfjdyMfFyHrX+GFIZ9jer42LUyi6S56eXfPs3U+jDdTFM0LAsaHoDHJXMdhA w0Y1qAiGaXnV5qEvrmO4qUAPVmjOj972NfBbBdMGzWIRU8p+h8Zqqi61AqsLwPwYILRuM+PXROhP L149T0UpNiPA6oot+qxafhCxc6NUbYxBMcxuoG+1jWLua02fhXhTIPiaBZFdlhG5FXsgzYC9Ad0K kijBRJE1+5d8418qbode3lR0pEqAHe3nMX+T0Rdr0ikXTo82EE79npC/Byz5/GjwuEneWAv0Dhxx ql09iD10iWIjqf3XUpO7FM6JSrBZ9nWPfdNq+8iComjlRW4jcAPF63BERBLdxAATI6ZccACRKVXy rCmX4pOPJmEtr/S4OsPT6y6UKC21of4l9/9XUPBJJxaFX40mkTCLCnuKqiCZ/1NFmJJ+nZk8y/vK qbc9zzembCy9cuBLfHNnh5vk3kGExGtc5BC6VS5DGFt+arRXJZx0EaRXpKhDu8ZwOh09H7E8CFcx 4VSIQSOvZMGyJ46Fwn0RfKuwcKj7WcDJCapPLP/5XsGPlhs8Em8dfH5dPVJwMOM1O/pIhNPUiggn /bikXiVG8twAur4xLCLj3WA4o8TtLMKLTpHWV0aQBVkxJwPVWP5lp5AsCtQWW8dET4t6onX5bFn+ Wivcq5x74Bw4tPqjrp0cdpiFTL2plFi1qhIXN4FGozxgsjLlUS/uyAzYNGrxB8OD2HFEKoYps6vy tcxO4WgSn2MPCMiBan2XlSWEGP8l/MBNJRGUzaW1bvlE7pu7JuO+xzWnkMyrOTJ/xcm7s7PIYtW7 x/5ob+R3akOewFSjayE258zjWKI2RetVMeXogdrcZLbYHnZLhEdMZVOuWGVm6YhJXV4uGFzFn49u lvUvxeNfvn4cBkdiXg8QlbT0hwXstR64TD396ltAkmILZJPh2tjd1UFbVpr1hF2vj0Gce7Ttm1mH j+oGpdCKQGwmKnz7xrfS97a+g45Am2TuQbiGspYTnlXTZqb1Fr2ANPvPxD6azkstw/rhzU/v3myr RndB8GKk5THFn2fdE/twxE/+XnaLi9G4lfMwKld/vuye8HtWZiObwipt8MXlUn/5u/jk43a0Go9k n/tXDteKePCFEp+d49e/i68viw+wO7/Qz4r2EZSPN9Bn/UbDvw+UlHv+diviHlorukB2Dv2e+w+L /wLIDvVEGznaNY1zJT3X9pXwPzOUqjp+4BRNDzcH0mhVfa9ZkNWygMdrOiwify5WEDkh3szY/BkP dle8bqPhYgFYHhX0D2AbE+QrFW4HjgUjDKOFHhWQ7K9K8xG9wJ4XcSuniEbcLuhtLwCpKdubUQ9p eDRtaieitkUB/9BV2aGMcTJBPgM1QOPqwC2LkByPtzA7QPfvU6yhq4g+6D/rh9XFxRwKZqEET72+ Y1V34CiSVutdd41jY+dpYAl5afQaGSt/r10s0ANN14mFUI0/9EYZGUiQyqzcWGLQEdPeHxfJv8tE qga0+w6Show39ZqRwRjpplq3SYV3xbqscH4DIhe8ehGtGfJyfpTRHPkPmOcLsI0q84vVMSJU8CXW Fm8VcirTC9JhDfuYc3y8YLPSVuu3yzYA8Meo29oQ9obFPmxpo8BAQO2rHeI1CucUs/wFLwfd90oT XUHbrtF8eghg7wK8/MPi6/58TKrqqjAOqtySw8aSKektOB1WUOX9vKpWVfbYB/t6MapUK3GJGQRa u+GJ1QciQ8XwJCBIi+Ls8AQ+XNsLhCqTEaFbYW3HAffTVvNzLLPmaZW8fPuO8cvBeCcLh0pJX2nO 4nJ1BTfiqvQI1dp3T0kA2Kr69HTE+uucKM3eg+evm+svi8i9tHbZSzS3woIBeOzJepK9yYfic+GN 14f+cm89LFjs7X8NXrk2MayScUyP/MP7/FuIfzMZgNH/1ltmMnzeiM3T0MhNTLkDpM4HbtusfftF RvUamTfn2oxxi0p70aiwZgS/dj6uMGuaD5TAYhfId1tP8ZWM1cniM/IhOwPxKXEXZsUWujQ34eF3 8o23HrU/X0FKsGXLqrWGR2QmZFIadYRILyT1QFuYFDtiqu8YV4sOe/3Mff2PZ8VDv+TVHiqU2B2F Es6s6nqhTAEyNwGHcAdLiiAFf7kQL296a/oZekuObqGObhn2CnlgJDmWPb421fGdHz+UC9l48tV+ 72BiI3JDcIhyyJcrRglCqZAb8QDQ9q53V0BaLjXfqI5ZfQmr6fnJoZpbzYz1XQ/2mR6CxfrbN7BT Fb96UDy4z5i95cDsChncXrDusZkfE/8ufybB0u1vrj3+fpKIcct+Wfx3dWVJWbpfRsSt/xfmoPtb oCRzTaaY1f+ryGZ536u2Wk0S7TSdNbgt84aZxtuzoC9WKESYEXUe93xJjZYa+/tjBQKHahJ6f//2 aXG/2Pq1WjbbRZ/KujAe6y/7D37diBUmb9/dWKI3E+qa3NeOBxDMQ4YnRQ0xSknazv7N3jgVIw6e bNcOSlH0aH0JNQqnGAVXLhFA6bQuTJQ91y4wuBRPysMP5MRti78WD08ovxbtbTnJBPGPb09P/BbJ T7H77P2jIHsQNwXvuH4LcbtuCa90m2IraxRCH62xkr9wKm7b9gECyCCx094e8jJsOI8DxUfi1pjb LeUC46S/fn9yOCSA/Fzcjut1QX7sG/T01SuvJuqjsue8tWmnulo+YScQW3cWeuyBBbbY578P+O/i FyzS/dGjgshw+ufDIGMV40Mkz5qxiLjTycl7J2xTaIo5pw07EXheGKtvs4Yey1Xxurru8oWiLJKJ mVVUrS+OjgprfCkWZP+y54w4pgddiAmyd/KMwrfoCd84r0DbYj6tCaDOSWTDttJ3GeJLUhO12/0H 3qp+iQlXUREHCdUrQjjNw3kVAKFEwL9HXDxg+HJwyO5j/IN98mX8jTioRWDXHYNpERGVdyXzCojk OXifMlrecDe8T5lGAeU8P7HqH9IAKdl2DMlrfaqVW9ZtgDbLc9NZGCS2T/nYh+X2iRZeaUwNbs5n uWZWya4xYAfMFo51Z2wdpaXgq7meKvo0eo/KXKbZybaI5i4ye3dBkHr1O5ZCDT+dvethJzQBXKlP canmd+GNAeERjA1kYjV4PoAmAullWVkdTCAcEiY3eldlZrWu8tDZalxMvguHmpNeVp7kLzKwZr2Y klgXxbok9NUMdG8JbE9/RxeT+JgNUtBWcEo0jUG5tSAmT0/2Js99oqARc/kWZnDLSn2t6IsFDOZ5 RsrNZpnVaDjdhIUUZY1rhvAuLni+LejK7GNyon8jfPHVBuGLr1L44tnvorORA3j21I7VjpjSk5pH rix2FYS/W2iZLHEaDPICSjgtEWuuluShauWiaEyLrPGIhhGkPBpuGtP4L2vghkjAHKbj0jIiWgrA PaxIQyM+REwXgk5kojkYKIQstiB2SDgM2+eyWlP7DtCym0y2N8lYnVVa7gsrfF7+Us9Xc/JZwfnY L+bzfeusBHAw4DsoRgwAeO5+vSMPnBbXpXh9omW1aslxhkCl6CHQv8tW+aFaoN8l24WGU+0HhqNI 6vy9vc1GDfWDBBOW+aau5BB+S93ohQs2+OLRzqy8keffH+0/Uq6aBUMUWz/8WQb65NQf/2BYrK4m DhIWhxcJi0KhhOh311qz7WDWAgvuGkBSRTDu3d/Z24v81sxXkn6mxfhAt0GciHI0tQfh8c5X8WJP aLkF/3Dn0a2/QapvMjmHbbtC4RQn3ifnb4/+c2jQNqbTss/lzSoFMOGkECz0p0f37++KfpcNu3/f KLrbXZm4TcZxGg8c7ysP+9P+o51H93WzqOn0R9Y8kV3FRex6W7TUY2PFN+FPXz3a2ZP3YUrsCH4r ZoCcWM0vGlqmAjd3PckJbFRx6OjcKgyueP+WcDn8+K6sr8uFFiqB95LaAzhn/pWzHzJLRnnsrPTn wUgm+A/N5YFG1WPQ0ML3WdVxu1qKbYBnqr1yHDpvk2DWoDdMYr129rqqTI6qGbBCOlOAFMW2ES42 JwC2pObbOE/oWWdtDl8pX56aM7BrY2Oo/O5iXncyxg+7FyVuM6MW9rwJwvVVF8nZgn+J4G2m5LyE b5MpPDrW2CUrCD8xjSXtmtYg756Mv0a1qs+cceIr13TOLS2u/ksEeIdmsll8twRDRjCqs6xBJp5s N3Ge5IPix+ND5ssYo1UWGEiP0L9Q9TEKCGCMdbeqqDGHZGztmAdG34E64//IePG3dI3UjKotA3vR pGpzGVDwp8KDbKeVDJQhGQiFYSriceAoCG5ukv0ashnatTXQCrDC5oSSFX5qrTH8WAds9p/c8xI2 yg1a9trsNzkVeL4IqSO6vOjZy2Or9nqCIpxUPCV3EZG9jzvVBHlRNigZALCGI/SHXILWv0tEKETE Lm68hsHezyHwd+yHIbHTtsNWV+L5KfNSvSxOj493s4MGOgVN185u8h2PYBnoXGk3tFWxxqNdJfCK xsvZAEFJd66NicnQbufVQhzcjutPFB+Ac3M6TBM1JJAj+EUflfQc0hA+9FsoRhx8eTPcDuEMRJsK vXIYWH2zNDpMYwgS/SbWzQ6nK31UdWMURXzeIX6dqo8N7YkByWb7WGXl4g1Nf5qncSrNwUxolJrF E+N6OWbVlCIKixcvTpfeB5NIdERlSpNL/mWwpVsNwr69IlPNxk7umjvI25r55NXcXkXuCapKxSyE zaTySxpyPeLRxEzJzj2OrJQRG2QQD7SX3UgKKoRCabZKkelN1zByGsdju5JyBHnqOQm7KC4plZia Q8boN2A3X29g53+d7Pyjz0xTvlKYu9Zx7tKsWSjWgR/924b7T9VaypDbysMaqWVSr+I+dZQNn4AN brJOFjFQ9+AqQj1jCf2nni1bqZ5NQgmjddQrHVVsZHHHsyADD+xUKbS7NLMmauT3b4O8k5o8Q1pa +HgOn7BsP2j3EwC1+WFnnSy0KzQ2VmZ+D4tHhdrkuQNBrjJRrzxVNwDQ/bxC8bYS/47EYvrHzqN/ RIsbqDniw/TbQ+TSVLBegUW62IIPgOOzHT0CHYtT1wHdS16VjdyOw0XORKzHWJPl8U3Vt3OGpw71 c1Vn3OHnaqZphzEnf/xTIabgBx63PxWgM/7HkPeUT+/vKL2xG67tJmN93aAyoSQ7+JWKJbQhN8vm 2slD2opiBbYPx42Tj2al7XhZK9UZtGYbzbpajBRTgKy50Zvo9ed2bIIHZXrhNZ2pVPtebFlxlG1q rTO58iL6KCQ5Qfd3adL7wbIAxlCHy7T6DpLuu5Zh167FHLmhgERvo0Jnh/huvinYvFRM5+JYFzIW 4Y5xPVyFWKvbNjNrzhS5rINpQN17Xb+d+wIhfb0rAS/GjcCyhrySaTPZ0KJaAig1q3S06oSmKyNF tJYCjorn1dyQREriFjTgY2OWuV9Qss1uRsWTnU0csne/JYbGRt7dLCfAtlVuiASWKO1Gkb0L7DBZ wEvWq0YjwyO5rHH29QhiXPy8Uh5PVrcvWvrsMcqFLKK56iQp9Gb3ui81eYdNc2mIjJ5MP1mKDQTy y3m5SLdkx2+GJ0ekzNW3Z2iL6mi3Wz7l/yGERsazZ2xO/MOZcW7fVmFRV06VpvZuzu2HxSG7ikGq kGnbrs6YtvGkrUOaHoxZ/IKpb6yIIJZGuNnGm1jsnuHJdMj1kpB6hCVYWM4UtB25ve/Qy/ZOJ/sn rv3f4y1Ge+wne4AB347affZO05OdtTUgrXzh7V1kU+tPg7D1zfFTeSJIqLf72QEKGoAyUFxYTRJX UeT3tjkCh9a8YptKQIsCQZDWuFbvspasI1wWpRwrFPIT3oGPrPa/ijnyfvYjWFQhTwkO6Yc38cbZ n0nUxKo9NQVIB5H+7HjAAK+zW6Jtw0TpCPQmpDIRqW0MVqllNfA6zWIBMXcs5uxcncfIAkQo/yh4 u02+zqxcLdimLm2sK8eAJwaoBkwSHgpAjcYHsge5i0pLEnMQOwdaQqb4hyZkRsWhxfLF6PcFiDe0 aIaxXKTHsglNUPS7yAkRar1jm07fu3eH/Z26z07Md+/UDeg/NF52x159h9AgonLvZL9dQrGEnCV8 UGxpT1/dumondFMl8rBaEnX7Ov8++cjsrpFQWks941GOiCCGxVqt8OtFkK0dOfZvnVSh4WzgTE4Y INR3Gfh+G6ROrgrzQiDBMmy8Qb2gGwb7q8NP2hbHRM2tUR228kTo89b0ZqXIs/RNvLk3IO8adcCa lMKOnURlWn2LKXmcp3mY5DDxmI3JfLSeqIinQ7a1eN2cac5ruWgQtli1xeHsaloCLDaMe5uj5+ff i0klN/5B7zQh7ss7GxDqghF3sMWAasY1ME84MsIX/QW06n8GC4VHel09YtcjEjGt5xswNMkJ+OHs xctvByjP6ZqD8w8Xq2m79/ey6y5nzXk5Gy2qbvD02RIYgJfyJxwTNpLW7oc4Jo3H6ljgo5XtqoNL qKjTp9+8e/eZlkRh/+G2DOooBtWPy048Lj1S/VHBnaw01gr8b4sQCxw0KkUXVv+ZKl/ktVmbqCGF yLiBd4DQ1pBf47Wo0LXjp7GEutOnLUjG4FZX/KqLShaGazBUTkXA/eblpQWdYHqsrI8mabzsi4oC 1y9F5YKDyLOiiPW0zeMexwJwADBItSer+HvGaQnvK2evDm9karfiXXaSAMl3/XZhWBmdCm3KBeq1 w+fPi7MH8kZne8PibH+oD8BysYdhpGg7efNjgUvKyeSJ/rKf/SI/yLcfjApV6M14Fa29W3A/Kykh ESlMx1qZUqwSQB4e8HR9MqvirD6ud6sDPHZb4aeqcTjlXt8mu6W5UivHFHHWm9SrcGy+sdyNlc/Y ZP+3XGEk8Tc6BkPgVerGLqD002d4RmJ1Y2QB0yr7PDw//nH0za4cF8ZRNj82SsbQ9Q4DynhdRWrb Y9Cq6GhjJOH4L/MicCHs/S6NmTZLXGBLmc6uQM6oFej15aIxboYaIOvAF0p4Lzy+yxk+NIxCrB5w 0Tskm2VVl01GyNfXXEwtZrLkAIVo2zyhbKAhgeFrOxKrcZGVDHYUO1LXoEm4Jii8Fa/hDnO2JqO3 giuj80ekrTi6CnulMtFWt0NTpjYhMMchhr4vl+dII4KJ4tJ+TjMox8Y/BGKmQD/24idIATmUVuEM 9SO7fKIbOKMo5C7D0Qp+Bv0IuoaI9RTMJ5vS63T+dcLbImLm1so3xQElq17Httx6PJTYeY/3P9v3 k2G6XE9rAGpzORSV1ekT+Tskas0P+NI8AZd+Rbo1b2Da1+6nXwd829cis4kvalSeAzP8QEvTmR8I Rofec0+UOwahTVUg0/JXxuHxi9KgcxhqkxeBVVGuT/P9YZyf6FhVe0WKCkOWa8p7ctcpwQFZjiZ+ DriVlxV7ymg2JdlZprAiGowyI8BuIAARaN4ndyxpAukX1ayFF+qigrJiQ1FRFccvd4+f6x4nGJVy vFbywWQ2gqNNdqSHRVbyQrSxAhUVtU+qxl03KT33ZeybmgDHBg5bMVG5rZEoWsZoiKT5hbdnR8Pn L96+ixUNV2UNJ4yD4arFyYGF2Jomr1vHoKa9fr5ysevxKO3XTL0eFPxD/98UwGVjj5GJiJShzJf4 NmLPMpyi/FW51ExjZA1UeZCN3jqS4Oo0fRD3yYbgkE2swFChS9qY+vj0yNlPSJcCJLDJUNmeb3C1 E2eEH18d/3RAdXXyXuYtw/K4boow+DlLNqi7IZjkE3bsHsLIKKLhNCbu86OGbJoLNTLMGeAM2gll KPRKTERxvoLbPCoWtW+AlaapDd7q+Zbv8n694y2WiWhBLkzsi8yOpRZNvmy29eiLez0v2ViNq44C zjWpGHrnRymBdLgRNkDbFEdIXLyzF09pSHzOfzLtYed/47+QmUl3Pqn/UnJ4TzCXZ3s7T1VSfuK/ IyZ1MsEXMhPsU19a+2biVeaj4rP3f+fZb8lZcevwUXLiBtg4oVj7b0tvuXBAX9QehVYITdU+2A6Z 9XjXw+N/t2fAxs8H7Tz99NffGk9MT4rhRgjfL6tbQ//Uf39oHj713xmfnQ9JZD/2bLQT32XypRfw 9PZpDEXNnaPblFVKkosUZGs8O09J4BtvDtYC7uqwKCOokJEtOY/PDKCaJHL0CrCa8L68sXmOCZgb c4PjZdG3Qqwb/s0sfd0MFsbWEjA1FIkhhU3WC19gcoPzqEU9AMxnaRweZa7JsCCjf0OHvoiRi5oF 5wvmd2JCB++PEYm4kBc7WiJQpk9mmKMIp+j+N/l3RpAXMhjJkg1HsS2tF/tN4pJAfl4kyYpGAEuF uKFeuFkOlU2JfFs3mj2zqjplfPLZpUCnKRRyziNqFio4NWZz3rtSFZbqXbpVHcgRW249TdevE7ez osyiPh3BQ4oT+DfmLCdij2ukypR+XuKugnfjq2o6myWLMTrea+CuN7sSMdHd6N628ySKGKpZVeJS 5qqGMg+KHLxYtwwSbbP+adDOy2XC8fImk9X8vPBylkFxNa1nTQvKAotvGXjEen2J1hxqREWtkuUK wGt4BSDtRF19kY8lGsAwHCKh2BLV+h5tjuc8WHAOg7rU2v/8dfS+y6ah8tZGr7/i2W+SfDJgDaUG k/ZDY45Awcn5rCk1BEayT2zYFEz1Nk3AwzhbuKXpNG59Ky7UJrKLeCWfvlXOziuIQDWJmJuVBy/L +Tkl30XZTuWJlFCIrdPKb5XmhjIFb0zzEdtjDruunHgBu/HX06oWI6tcavxMo6go1uIpWl0VwLSh rXErjw50SNWI0nY03Q2IU2H/vGyW7u1exK5WgFKGadddHezuomsaas9hWy3K0bjc/X/n5c2HZlcB 8PZ/o2k3Vw4H/x6II+tuVHUjkE3MLrrRYrYrKvdFoVNpDZKMWQRBTHV/4jhizmlSdTI1NORl5z2h g67WILoro34mAwYWVyuE2lJlMEFbRjyUeHD6zZIozjO829AlPyqtkaZtDTeoMnDM+uvidLZqDV+W KMNQPGHNrDVqWHfm5ZFPhKs3JYnrjjnbpV8Ah2KVzk/JRo3i3GikwJgMtpmeMe/RO9Z43DbpZeVW +3dE21tEFnN2OuRxnBPLrWBy7IlUu2Hz9TzWxCivOpUbZH9zbQIRDXg7Y7cxxY3XhfwxJmSN1ycZ Su2puYokyRwE2BaRzmbSV/ZIF0FGlKkq2yRikRVDAf6AZDzTEbT+UbLDFSSAJKvyW8Zcw8Haxya0 J0hRMdTDO3kU7CY6NrIDssCh2wG9UXOTYNxRa47YlGvY85Do8nveik+MPZKYJBkWUWoGvsYgDQaX i0c/sJcZ9t+zcLrjTRrWNJG1T+VeWruhnU616HQpCi+NHd9oLS6o9s1ZLXvToUWaC+1NwZ5ntZpN eFGxJHoGb22BTVayo33eWGEouIltOhELNjPGUK3t0ZVKTYxJsMGWi8TTuXWDykzaldtJaTFOYFYO IyJ55ObzZ+1VhQ2MOghsyYPibfGt6Jm/nm8X94qt8c5EEUlWJzEqyuH5cDycZJTyA5o9g2FImxG5 EJgpHkoemeeKw1/K/86Lsfw74e97/6fY3S8eyL8PTUD8lf/u2G+P/o/8s/s4Cg+5MPkj99KP//er 9PNbdzs+n4zdFp7Jjgc7PB5Kt54m1XdznSjLlCy3H8RHlxJwFE+QH/3rcGd4DwAPkPxnB/GO09w7 tJYHtNwjOkFzI3oMFQCmzminii1nTSge8YLH2yNb1VIrKyIIr1tWEDeoZdHuuIjJkBZpqXhBGZIY keWybudhC6w/w75YoErVQt+anD9to9AsERS6xAgFLB8NZZuEt++fFcvH2C3h5P2rYvnVUP6wfGxr E7aSRWW8QmJi3xTOlqPtlmSStzdr1GjnUtcJS8P9SRpX1qRHXBZ/qxdjbTdq51V5XdBNwGJd8j7D wiiKYFT4zhiq2XytFWjtyJhX7Zm2fPiTJ5tXDqb1QCGk8EKdBudnLK21m8YflzTOIB/oXqD6TSdK rZYYjuNOJI0ioUHORa7VIeD+EGMGbUfTvgpqwpV2v15OOmbaWAXKfFZa3flHTMjesMRPsr57w7F9 tj88R4O2dAN72b+ep9tv27f2RX7cca0Im7VrZdvsDeXm9vP+EFvqjm/ey79n2+vzYWEaTcY8D7SA amBanR+JWG4r/4SAYqcJRru+CFqIvTCdq0ytmHLG/WwAAxSwjMLxrRSiyoG9x4RPgRaTiQG0q2qL v/FT2W8sxjWwAZxAL12zprgNWynQCGTsIeel19cKWi8AbIcS1ZPjqrxs3BpGSnzEA4S9zVt5ogrb /0rpxGvcGziAFczpbrUgvG3o8Q/6Dwu4D0pXlM0lZkZjvVOwifNJnKVqofCdtqahdF5fGoQEjmRb kOBGTiz5beRFw6HZacuYHpOrqpxaHCM5PDvhNcNcgw0RSG9XbDHNLHuj5wdyj7YxKvRQUGhuWyPO fnUdu0QkFkKQjQ97cQM8M+ps/0JDxTIK3pqN2yADumEgeDa+I74V9YFMFVT+tipY1HTUWXuGjlZp 1vsVMqCdlh8q1Q05g6kuxKQaExtGWPlByDcp0B2OG0D2V2WEaach+6VHZLDFN84r0fQGD7ONc4H1 R7wj/IQkmqurcnZ7k7u1x3f6n6q5gi/3a0U4tPYYFi9k5h2+8OGRdSg1P+hjzY5M9EVC7K1hGWIN gfp+eUOryHPEm1iStPGteiybKgzHAqQkCVTskLyxsWsfBAWlK/y+vCm+xuWaKHr80M4x33zOs/1o b18OABKBIZ53QxxDNbCwco5ida4TGKq8snn0aOUZ21HIwhTXKSEo9jta752XWn4r22eDGThsfY9B F/EIWJcQkxm9uiXfxN4J06aM5IEMa/puT7sIK8r+ZACBxhaSmSzmpUqoGsZKJaYoZoxgByzBWHNs jgsxXdl9UU3zrs397V2V1r/I/QM1BO4Pxxx0xcOeu54y/7FoIUNXYnFEZmFv7TylkWE8vw2BhxfL RruhlFE2hazkHm/EXTHPsNt3TZlZIAnQrcwPuHzw8mhPTMqXR/cLczK40fGo7d4mILhTezPiAE+N bBrjupw2bcIs6/spZEu7eLPFwgb7BDF1ue9f2nhM6tbl/E3hUQoMt2mc4VOO+2So2TMeUdoYfHCh 7U+WVZaW6xV/nteLEplXUaJkNEskbVdNHVkOBgTwTwb6B2/arS8L23d+1Y3CC5h/3G/9rgHjuF7n VabqVdKzZaiSNJnx1DsHa2q90HDT0P+UHQbvcGDGKV5XbTFnf/HIlPask2fZCRpk9x/ABNQWRBFM ml0ZcY+bGNAom1I8rqJuWGpqidHIDee2q7YG/nlVKQ29T0mocZd0h9Z3YBZMkTtwyfDDx7q6HurS seIbmH8gbNu08La7FAuanRv7GmRGBWEI7wpiwor5HeMbTGGkdq2qLa7xYqS5SvgUPQ42EI69mkQ7 SGWQBsXHMyzomBXqXqB6u0lgApq/W5YTnNg+hvcBYINRX/JE/7vQ8w7lqTmcd4lymdSQOTMQgqHG WRyzKEmpO/OmWJD8GpXmsPptUrXUbHob6B7Au+TKqdFoAK57/uqfBuE/1zBR5FQo/hzJFjS+dHJy /E/7CQ9G+YuWbPXOyNBzbbbKqILFO5b+OUcdYd7cgMqscrmsrhHrSbqBq38NDygypo1tyvSZ0bBb A/AYFNmEgB9rxLKImhPza5Eq8OplrImInrz1ezV0iH2fe9A8xzCztBTa2FToAdnU3iExdbFa5wYZ xdSWM/UotkCVuoPOWOzDZjH65LqNxPaj27yud1WIsPmy7/Cs1dndJSKPeH5tFbKrsxIRL9hI/tsG 2/8LLfLJ1FodG1xNYUg12KfQBjDuGQHQA6DevEsbBP8pWL5wYzkRqo7JNr5cVUnyW8EiiOQBBrTI u+o9yNJUG/6FA72X2mUkEQxpwAY8WRwOHpuXLZ/aEFCiQLDyRmH3wbtIKZ2i++BuBQY0ASgWa0ec GUdkojHgUNTrxOjsLZXkLvKi5flSu+hRNWv+J6y399G9hoxZv/Gy67BEmHG1rJslaQmHeL7XHONP hDHR+DSRPkbbzFg48btzsjcqfhTpIyOa+flXyjTIIaahW7riIk6WtE1g22X9hVHCmTifNnjw/qg4 zfNBYo7I5qt/pQfYVssdEoVGXsm6Vdot4PM+VpNQeEFUTofYKwWw/U4F571OI4mvyeVNBvxg1IOx i+S/qNqrUqORhlSM5hFnc5O7PwTXGZJgSgfEsKRsHlKF+WEBho0Y84lnLQbBEVFPUV6oRhs5d1s9 I//xSEwnhMHYz6hFKo/E+p+tRmGzsmBqNW/pmXs1xCfq/g4Kj/IPSPl852kZDEPsVMoDsLhhH3ZC 2HAoWfJaGAtoLJYgHKUGSLV0D6z1h4MNwYCdVZvVMhkwGln01hO0ZJ9o08HGheucUsQWUDRkPeud lFBbeeFr378WoaStLF+JOlIS/f+KDRVwyavj1+//Wbx521fB8Kai1REFrZ57zJs9NHYi56we55N5 6qLH8oQkilDUKSYznN/0YQB5uaxNGPgramWUTX/rrZjSu7YRzB3LGLaHeACM4pqbtbR2STwMdGZn VWL68FVuDKlbLy5mCkIpTZ/4GkMl8n7h9fPDkYHRYzoQ3CjnYIbHYNmhxU3vNpoSA7XERF0MoqvM lxtMm/PzGxRoDNQnZdAMdfeKGm4BkC8RJgZOKnckp1U0f7Dpq0lWoLTmJZN8Qg7cyuAFcT3+0vLG vYieNxSwZKGZdck9NEYdWSZvj7XLlt9ao0h5L9O8e10ZztTv3Q4TH69lWa2rMiODamixCKwYE+ik eK4NUwwaMKxln0AWDU3TK2aCs8LVZp9BAMNgAmCH4sTRyqMXY6kPbwcfcmtId402o/T9orsgdiWF KqyNkUSjYzbdWNy/OK0qzRfu8VuKwFU1/IOszs444PsRggG304JWe3zQIDlVsWJzFsNk4KpdECbF BXp5+v2hJtBkU17v8Ei2VbnTXOxcgviHdz98e3zUBrMMqmRMcD8hca4cMC270OOZ1IOUHCyGpeCv HYFViMyf7Yi126FXYtb3KcvjgZNn2dAXmtcWALgwf0WOeNcomiUeMYxdBxF+XoGESxmT3009VPCL RSd5v2oSb1ZRdiYnSV/45dF9nRNE2EHRMPkiJDq2gt1f4y30dJPbKIWH9ooTZV/L9aclAUDzYtTR X8R+BW4c1PR518PX49WS2QwSDsQmytMVQjMXltky2a2mscfYi957nrnXtmHMdXCnnB9EQEhmq7bF jz88f4XH/vji7PjVm+8JzPajEwVu0CSaI0Fp/DaT+uJGbBpiRpUDGRGIKG+bCxRspqxsBhXhOhjw jh2gEh9Ply1Si9nVbRH9YH2JLpr+dCh75wf6RW8aKy7ykne15xKozZ5sjp72QkV/oa73VAZHQagl L4II+kecKyIseJ6VMJC3ViE8Tr1OZQpbD4sgqtfMQH91NYVFqiBL9FfvKgt02qTLUbRcI/dFLIvF 35mZUhZPVb+4LKcB9Rf/InbxxXjw8k1msNRo1HbLfXG7GNd8f/pK1YQe3pvsxrgTSLFmZYcJj3tL mcvsHBiz5Ibbl0EiZiJz86VXQMNnm49nf9XwtUojJs9MJBEXDH2goY8sqGoiPcWyzKGGrXfbLB28 flOcvXj79s37s6MXWnPx7EXx7M37188HFm22CEMsa1d9ziBnMcD275QvdzKwkhSkInCCVD1Q1dG6 cT8vlGt2Jb+nGYzmQldE9LwSYXktkfhFptjTjHF1ltoannItWGxH7VovA6nNmCKNT8sd7iayD26Y hXYAV2JMppxdwr+cugJODsYoNRXlEpIsTE+8ts/mJCFeEifHrRlX6XmAYxgrvL2DqG08WmHWOc0d TkMQoXd1KqzOSPBKuMeeKDCKA9VnC2+MOVg25WReXg30bOMG8C2RiIUF4mWLU0WzwJu5XoQLSroo t7h/LIQRG93nw1iQpSUavYZNlI2E7Aw40jJvBQGokrQxd4SV8G+i3drZe4qQ1J4CP8XOGTE1flP8 NL25rCoj20LYaffZm+f/jZafaMn49P8DUEsDBAoAAAAAAM41cidcBDiB1SQAANUkAAAHAAAAbWl4 LmdpZkdJRjg5YVgCkAGAAAAAAAD///8sAAAAAFgCkAEAAv6Mj6nL7Q+jnLTai7PevPsPhuJIluaJ purKtu4Lx/JM1/aN5/rO9/4PDAqHxKLxiEwql8ym8wmNSqfUqvWKzWq33K73C+4AxuSy+YxOq9ds dPgNj8tf7br9js+b5/y+v68XKDhI2PZ3iJhYVLjHxNioGCk5GfJIBmY5RrnJ2flIadkpOhomSBph eqq66mjH+oH3KjvrELhhWKnHWQerm5u36EvrYZtRTMFbcuzpirFMLCz0PKwxjQwwoYmKi6K9HZNZ BhObjS3h3VserE4tZv5t/A6B3rDmQl8rfxJ+d9//gK+ePnfshgRkcLBdhYQKGM4bKDCfG3AQEVbk wC+UP/42Ec9djFdQ2scEDhXCO3mh5IGAE2uoNPCyXLNf3FrYazgSQcyQAHPmiLnT5AKgPjuiTPOz aICgQ2euqLkREkylTB/yBEJUaDWqSpuyQ6ojqzOOOMjSObOSqwixBtVqHXv1mky0Pdh6VCOyZVS6 KKHF9WH3rVyPW+de+hFYIF4kYPeK60uQMJHEgiEbTemTL1a3Fhc3aXxWqsW1nEX+rZzvtGWdojf/ vTkFtE3NOEmr3kEZdWrJcBU/bsvTMxa9LGSzts3bdHLdVpcvrNioqgy2xrUQT6GN9lTkq+uWZt7z dnich5d2dclVeCntyuTRlr67O4/c4GunvWwBn1T44/6KVo/D3gj6Dchdc8A5V59X5iXEH0v08HfW QwHOcV2BKykIAn3zfZdgUxM2CJ19B3rYmiIlZsghRikCtmKHaZ24HUgIskjihInAqKJ4+bW4oY7M VUjSeUH6eMOA5Zk3io0yytcbk2HxCB6QImJGpA1GTsnMkX7NWBiXPXqp238YUgnmkw2NdoqSz1VZ 5n2TQSmYGxoaSGcQc0qiJpEQjjneiHX+yNed8f2JGJygaLkkobcYWhaj1BAnKH6D2ukonoiS6eSO bNIQKS0VdsrnpK61uclvifaZDqlFVrqKmKBiKWqhm1p6qap7wiqprKqqImaMmeaKpp+ozoJjrMGm +v7rqrPukieSu9pXq6/KRevso6Z+xdCtQy5orHdTfaTtIb1uSy2ISDIo5AyarHtRuH8U6xW7wBYm 77GUnttuurRe+029ocrlL640BrytQvAOSfBxueA7b48JuynLuBE9LK2mFFdr2sXuistvahrr6zE2 6K7zMbHNjlYySCkDt7JW1CIscr62tXwvzUmeHDLGBVNps6w9G/ySvCMv/LO3RU8iMWFHW7W0mU17 qpLQMhMdc8O4VT20KFLC9fTEVdvrWtcm5yS11Tx//e/AaAtsIs7qiK1guSD39223Jr2cXbZzoyn3 OtyaDYjbg/V9qt1XL9uq3ogDXvGoyQJ4cJePk/5HTlvA1BetNYtebnnlNwqOGeehe06p6IBCFw00 pm+2euCRu9O6nnv7szgrl76a7MbdsMoF6JIrauvss9VuO4HP5i58cbxnsTUJuCs8OafLD6Pl88Ma bubxV/geWfTQA/+l99Z6Yz32ECsnfmzcdw9++9/fq307j5XPuM6Ou2/d6+0tTn+E8ct/if6lbYDh w9/29GcC+glweP8DYMfAlqMG+i99TkDgPqbXuPpZCYNAe9n72Hc9XVFwCesTEAcXqDzijY+DEGyh tySYBAti54QsdExGoJImD2ZwUSpMIQyNUML9NRCFsLuhEdWDiIPpjogqYGLpdIci/tXwLkesYv44 XFeSJU7RhyN80wOVNcQtfsuKYhzjJ9bjQS328CllZJEOpSfFTR0xeDb8R/6+uMPfhZBGPyzUG9ET RzBdEYTmY6MdqcAuxS2sj2xc44b+CMgwGkYjCWwjTXDYijFqkI5vcmRSILnBQNZoEOqyZHswyZh3 PFCNjGyiKdEDylBKknKxmw7qdhYMsxwBHR1jZRcZ+MsnxVKWZ8LlmmgpQ1t2JogbRCL86kbAJhkQ jMFcFR5FyBp9mAtWUKzkMpP2xOYlhSSbRJ7fqgnLbjYySEfaJjpnKCFnplKckXyn/cpZSk/acpjj zOaD5ubE3U0SnH5kphDtGdAL6rM/6gTmgv4g4s5pErM5tWSdQReJ0FceVKKPbCgwVwlQjTqvRU7x 4kUJic89RjN79owKFPKWNUxxFI6kSkYuT1q4lBbynnxsqSE9asOdrvR8z5ypTTvHzyi2Mo9sK6BK Laq+a7pTkSOi6ujk2dFrepOpvrTqM72K1KjicZuEO1BZNwcbi2oVOWfdUltH9Va1InJr5hpr8hpp V9KktaBAhRlYc5TXTgbWpHOla0iXwlOmHm5tTVURKpuZTIsldrJcm2xfo8hYY7rxsrMRR2Y/OBjL 3tWVRNWsCXUpzLXykKuj9dVfe/raqyV1s+WJ7UlsezjWMpSgnVVtk3CLKeD2U7R54azyAv6oSnAd VredZC5FsLpP3x6TuBgVbqNKC9rUFjZv2O0ub6xLTfDubq+ljKxRxPtd5Z4TvaEx7k+T613K9om9 +XSuNaHrGKVSV7/0VaZ9ZdtayGoTvjqVb3xz69Ne8LaS5s3uUKc70/omuIhiHYgCU6fWknpnwaec rRk17FjSZfionwxwOiGK4WtUFMCHDGeDizhbzW1lxalt8X23+00Qy+6cET4xTp8jXdM+OLQ9pshC Q4xjFzb2qUJ2qlBZ/OIZB9nAipUpk1la5A6L9coH5nKVh5vlEkd5LEEOaEK3OmEyb9nLVFZykxEc Zih7mMyQNLNITXhkOktBiTTM80j9XP7eMe9orXYGtIWezGATB9o/fV7qSMnoXhhPOcRZtOSZN8rm C85ZzDvOqZvfC2ka+3jTQM6cpe986AIrWNHRhXCml9xlvYbaiHwlNRUPUmhHK1TXg2b1bjU1yzSf MdZf9qeNBWzrbfAr12lO9ac1HelES/PVb3bwVUVd7DZL5LHRTXY8eXlqQ2M0zpuLwqSzHVFqG/vY RFb3tzkMbW9vm3zh5jWmEY2iaD863fgmtrZl7Okh0xneHTYuWphNbi4mfHRPaPCFxSNiPNt7lOc+ bcV7/UdfLpy0E992wy+O7uVaJuK7bnaO5T1wzr5O4+42cseX+fFNP1wy7FZ4yyWN8v6UuxJeLO+3 y03OTl/3Nnkzfzd+affyW4NcdTlH5s2fne2JPr3XMR8tSwTOtprXE5f69s3SJT1eGPVc1UgH+ouq Pm5oWptQqMWmsaMO6q6/fasnGjvUqblxCVXw61y/Fr8f+uOSB13QFm/6JDdaK7tjnaZA57v0UP5P 401b7XBnPMXlbnShv1viOrl7p4Xl81K3wvF9R7EeQz/BntBzt5gHfGsRPnWHxj6eo28ouG8ZcFhf V+mEzzfpGa7fvLe59a5GvbI1H3ah03tqkye77Hdz9PYa/vh3hb3xn+981dcenn/zvO61vfXrRX/o yPf6ljIq7uDPXjHbh+dgrXx9m/4ba/xx73YE0Z909ce/M+2foVRFLnyC91T0B2rPFWP1ZnbnF4Ca pAS/p3qV1iVxxUcSiEzld3gGCDIwtX9uQoFf0oFS1oDTR3GhVzbeB0dwQ4DJZ38W81mVxzQtCH4n CIPdJILStheJFVExVVQ6SH0OGA8+eGvAlkcax4PYVIRoFUM16CEOloPMhz44GFK9J2X6hkDgln3f c4QvNISvB4Rh92veNVVZGD6mRmlK+IBUKF3Ld4UQQ4bN1X3fR0XzZIGDd3YmqDAfmD14yHtz6HV8 +CJuoYfHFIhgNIjHJ4esZw6FCC0jQXyDw4gBFnilhoY6xF0bGCMO0YjYsn5dmP5ofqhJlVhgibR+ pIU3ihaJKmaGQfeCjzgzmOiJ9OKKTLdLnDhv+MKKKvNFmag0uchqBMd0k8iKYgeJMdOGLMOLsmhS wJiIxCiG06SL5tSJqUhLX3h3igeH4Xd9tChrr8iAwxeFJLdh4LiN3HiKHndy3JZyJDZi6GiIydhq f6h1mdd2taaO8UaO2kgi5ziPaBWPNaZjc3FT3PhQg/eP0Ah6a7iH0ueHrWF9CClQEoSPvyiQy9Zo CYhSdohzniiF7ehv1lhtYHZzEQljgTZkf4eRP7eAqPiKIulPa+eSQpiSfxZGAil6JFmSADiKgXdp KqmRLNmNDXmSdPM/0jhj6f5UPya5eINUfA75gz65kWfojc62eBLWY0SpZ4+nXsHmPrPGSfeViuWY j0A5lf7lPT55VSe2U0jZVBhGCEdJk314XO51Mh75krsXPWYpiQLGZmppTOw4UNexk/w4h09pfo4W mFJ5jW/IYnq5lzgZH+RVeGBxmIL5Xr2lT5Opf5tklSrJmI15el4Dlme4ejGokJX5U4aJamknVJup dJ3pmblHkM/oelolmye3cwZHicOYfsjijKz5bV75efBnm/SYeG8pichHmNM4iiHHY16WnFMInMEJ k8PpYgxpnBh3m8jJjJYYlW5oQHhJfY0SFEWXY34jHLXZg/6nnd2YmL3ZnP7mA56iKZ5CQp4V+J5I gZ5BqIJ0B1KI+ZF2iT++WZg3Np0kiGLzc52v4YvIpnycuHwO4p91iXdXJqCjVGLNF5RGUlsJWiah qZ6a14W3F5TVyKEGyX/zKZsVV5+UR5pkKZ+116A0qE0OiZm8OYAVOncXCpsSmjYWVqK9OZqL2YkR 6m/SeT83yqHPeZU7WqTfl59gc0sLumi+1nti2Z4uqlLxqZw6enq4h6FjiZI8FXk4OnDxZqPcWaMK uEdamqNcqke345hMiWYDiSseWnjQdqY0mpqZ2UI4qqRNqYDW+ZkjWnbsuYV/Oo5adpFg6pbvmSt+ yqYDen8lwpc8io2I4v6KiHpJBXd/wpemi8pNrWen2JkOwjiojJp6hho1o+p7vehhVvqfEyoqAqqp pLpqihirT/ovpkIUkXqW+5aBCBiTnFcn8cmqeXlJt9gbuFpfG+oe51Grt6qoZMKs41GtLndW4Hms yJqsWck1M/ij4VEv7ZQu0YqMFvetUNiK6ipY4PqHiEhbkcmu0tSMWKaGLmhGQASEFmSFhDol9Qpm Q6OtvmqOmwqGAAiwANqvLQqPATmtyZGwRBaxEyWwRGmuVJeoBys5/fVzkYev66avrroT9IamBOav XKRI0ritgwasJBuKzyqniDdgMMiTukqH2wixThioOns/I6OyFwtkwP6KMRP7rzxrhDNra0GKlSbG Z0yomxrrnejylUAbtHc6tEb7Nu7arvZTpVT7qzTRL1qLWWKbMeBqhl6rn7J2HHCziN46LQ6Sc2jL mTgLfRzbEdcqlHJzWSvLrWB7h3b7qZ3qG0NaXPuWlk9rkYJbsAUXrlvqtxIKItjmlf0IncXFtKYm uX+5j+EojmAXTlYbm37Zh/VIW5Q7hY3ruNJagaJbs6zLoKT7i2GltvoImUbqdovbsp+LrrmKuMNK pA5KsBz5uDd5qlcaprjLuHK1ux3Zu8v5kLUIusprsI3KpB8rlOGZndI7vLBqqZb3TcnqjrP7ml9q vNf7mwXIOkLbnf58iqqFaqESibo1Er3US76xKnUhw4d8q2JCy71N6r3kwbDrZrNtqrruWb0BnKp1 m79yq3eRKazOK4DsZL0fFrIPa8D1271Uaa0WG7yDm7H4l7irFSwQwsBzu7xdKZwnu07wMLBk6sHT 66l7mqdqBx8lbMIwjMIFGrMyeVubqb/Yi8MqzLyO+oZVYcOoaMG2q8RaSCct7MLyS7clu5tqWodw d8SGkcRLbKJFNSzGesUE7Ll6OsUoxavp8cRYrL4pzKiBK8J/QqsdfLO3arckep/Vkxk/3JQiuzcr usPEKn6i+sX5WqrHqJp9fGiY+oiBfL7zq8bly8bFq1mQesYNe/5+lNq83CmAFDm6sxiipMbHQsx9 qyHJ+cl3tyd5M9y+DtVLBzrJaWu4VPyyY6y4wEKwivx1Hlu+dOydYoq0A/y9hAuq9uuk8Uu8MOea BNqloLy+TwgTKKO0KEqlv/fJqSx/DfPEgQxyQOmjRHx5xAyVwIzKjizDsKxkHYzNB3iZByrM/1ue MIqnfoy1OXykhnPGeJyPGOy/bgwJvtxl9jyS70ysxQnJGYyl2DPJ/tySjbzObBcd3mxaKeiPMWp7 yQWnA53PBQ04rXzFk2alz6zBs0mz2sup/CnQB8zPzEl7/jifOqzMmdrKCqwZJw2yXviQhIzPE+y+ hQTHlAxZS/7Z0mSD0D0oqCG7t/iYSG7L0tS8wt+504KMllp80x5Nfv2ZjNp5trQZp8ocwW5JysG7 cg88bwd9dL4s1baqnhTkslqNZuL10hT81AYyxxiiOFIqmIGC1FllgbWKoAYaXzKd1ljX1k69aD0s xc5Vu91KF3+dy8mX1065oXytmAvtX7ga2IB3zHET1207q5uLcUikgYacx4Pp2IeBt5+t1kJE2ZVd wsVi2krNgbbFlqTEN5ktr6aJvqUtMvuVMboNkHz11vHC2wRBs5UGaUoT3FMq2qONNcf9NsxtNM6t fU9klBMD3ZXFXkoJMNUdlz/LwciFWIDLjPHsMDbNsnkx3f7xQt5+YapyjGfrPaXS51Lb4d7Bddci BN4ObajtNcL1LcK0vcL+ncfUGJfQA959jd9syN9xaLk2WTAA7loJPoYQHo3RdrF+Z7JrPM7BTNDv arkTicjpLMttDMGiSeHmOtRonWKlC7sKLrsCDtKcnY6uO2oyXoYYqN/dfNhCTePIveOqGL4CDnAx DuMR3ePXhoE9KbWdO77MnI2VnbqWidLsu9jYd9ofJndA+34hmeGzfLJNHdasF+XhLNnHG7N0fbou PswWjdNUTs1e/s032L9rXs1qbc98i9Wi5LuFrMJuDr0uFecInNN6Gql2TmgVmedSPub3TNTwipoh ruaAbv7lxknonVKpF03moMznyJu9jZ5/Yr7h8DjKythukB3Cj74xipzS8Q3Ch+7plj6bkwvmox7L nU7Orp3fncNQIE7rGu6/EJ28sS7rGbrlIo7JkU1YG8HppW7SXeHrIw3swY7hjr7sr3yIUO68jzzt Qi1mHp5U0zzlc27rCZ2EuJlGlwzaiG5tzR6NR27qWR3uW13lTp7qjH3tw97u+rjt3L4n3p7oCdzH 8v6ApIi3unyQUGrm4GvjvG692H7TkB7dIdhXrf3tkHvgKK3uEz7YtS7O0t7wQJXpQMzDxdjqcr7U JO7lZX2uGp/oDK/Qn97bED/R2fTTHN/ykY66dd61eP4+4vd27h+/efAMoYVsx9z84ipOkzppYcJO 80k98QH/GT44pk2fQTkOZwL8pCgvkTLrpTVP8hyXgAC/yDYqGmM35AA6d7V58Py4a3Xn7lL/vKzO ojCvmh+u5y8e1D06YPku6UrqKm3f74Fe5Yref2Qc7kFTkP4e+JrrY9mprFzv8CVf7Jouh0QH1nd7 +KEM96uboHYqTpXe9Zi/85LPybfy53C74jyc+aBOplh/w1q+9D797sJLQktX+kB9+Qr/+Dqeiaw/ UDof+agf+k7/9K9a+Z4X5I7vUUVe24y/zEz/92zu9ki8d+ic7FmWCtmO2Bs9qnYdSOkNVyIfGubW 7f7LSLQsDP51bbrO4v3XdvGMm9zkeusLv4zBz1aND99oR632HxmxOOGpA4oEEN8AkDsVRhldtRfj qXL3YWo4cLnGj+FOa0Xd11xaZ4ZthLr1Pa41uRTjiYAZ35C1US6ZTefziOQppZ0QrfjTqSDC6hdL ikbBSXIZjeuiuOOgtP0mpl1Q+x1Kh1P1xFz4L+xG5SGp74uQxPDQKJBRT+Ij8ejsZVJO7XELj9NR c5BP80qohBKT7c30cyr1tHC1whMWUVbw1XYvM9Z11qp1sZcu9HPU63YOVBc3WPJ3lzllDboqslEZ mdp5eVrrQJV7bwO22Nqbt9KQCxhcS/2ZXQweqf42032bVfFbPj3rft9X3Cxy1uxhgzFCmr9/iuKt 40ZvIUBerxIanFfKTURBFaNpbDRsVUBUDyaie+fLY0cPJkVxTCnRobFcKyfuM8mSXZNgA5v1BIXn pTmgNl0G7eGqE5ikRpcGZQJN5EFOm4Y6nfoPotFoLpuGu6O1a8Sn03jWuWrjZk15acUW1epnBlta Pq3SxbrkYVlLas1tsptS7sKsb0m2CDwTJVO+x/KObexW6l+zkjUevguZcOEglodwrryYIVmd4KJe pHxa4V3UOTFnFoMQNM7Es196bol3rd4dtmmuJuqb9GDCkXgn660YOJrRuaspjw06tcq6xwELf/5b WqZp6rWfM3rStnma4uVoV08evPXw8N2ynQ/uXqoT8OvFdzde3uN4orK5pw+NmDzu4KPJsfzog8Q+ tBIUcLv++KsuvQezm/CzAc0o8DPdnLPwGvYYxM9B6KxqTcKYTGyLQ6EwzPBA7xbcK8Ve9BPMP7Ba 7GuuBg208Dsbb3xkxhOjyy1G0WoMMaMcQURRx12WUwy7cV6crEkml4RSxApfE/K+AM2r8rUVkTyy jyBP8nJHMEcsEZ4TamFzSBynS6yq60DKq0gz8VQTS9ek29KizqbUUiIx7YzyPT49XDTNKw+FEyo5 1oP0T0YJvfBO13C71FL3KAVyUE2toxEubf4AlBPVL0tF9FFWf8OBSzRjJVJRH8lkDQtJs5TVUFJz 1XBNV30l6UwYa8X1WFt3FS2WQPFZ1Q5aLfo0JPlEVaOGEvVkNlll1SuyWGw7GXXDbpnJw09l3lyW MQqtlDVdFdmVMVS/CBw3UyXhfczaeHWhR9t6VTO3VeQI3tdZcfG9NdxZb0PX32cgChjcais2kGGB BFaQx4V7rdRdYfCN+F4yKD54p41J/jFRRzlG2UmPe3R5L5kzjpjl/4yluU2VV875XJ+p5FlQm40+ +iySqTrjZKJbRlhped/t1F6ny0Qa6zqjzibCeWEraV4piXU4amA1Hrvh3TACW9msZ96amP4uIKO4 IJArrLtDuGMOe0O8UxU0n3P4jjtwsvW+rAh9ImN68JZ0jlNvsx1nXKl+DMeT8sPVk1stuuduHFRA 09Z8K2rxmRj0vlC3UXTISUeP8yQ59rvduy23+/XSTU+G9sdPvz1v232vPff9Egf+75F63x3Bwkcv Xt7UZ0eeeL+Wl/5q512HXmPYtE+4t+tZF5/7o24GnPz20hdw/fJZc/P4y+dof0f63dcd+57sV/t7 3End/3700lX/gueTz7GuIc8LYJiY140D5uiB04ngAoOGia+FzGkNrM/FIge09sDMcBosl9Uo6JxT bAt/b4PQV0poPhGmsF9eiRaWZthCKf4hJWk1Y2GwIGbDvb1QMz28iNYwtkMfgkpwRBwJCMXGRO5J rktUiyIGX0XCI6qNbSBEYdA4WDxhVQ1qkXEi4cZ4RYBI0X8ZzJ/Iugi9L4rRimFM3tSoaMaiybF6 akRgHG34xiXysY5zHBYe7aggvmxRkOAbGCD76EdC7g6R9GpjIbGVrKYRck+M9KEjA5nHl2nSYmWk ZCUt6TWhPQ2No/zV+SIZwjVuUJSU9KAnC1jKPWJSlUF8UCsVWMtF4jKXpRoaMH2ZxioSM5icpGUi P4lMScbSjLNkZjFTOc2eTfKK+XIdJE+ZSWfmUprWXKYrb1nNYLpwMbzc5itH+M1Rhv5TnMOzpcFA eU5tjlOeU5RfpLDZQnjG85LmRGUnz/mRG6lTkcaUljujeT58BpSg3hRoQQuVrW7Oc04MPSK5yKnP Xl4TmhQtDUIVGk+JRlSVHO1oMyfKrXpSFFoAxR5JQxfS8kHxkabsJxttClMGUm97GP2QNz76zn+u FI4adVxPffrTi+qRnkJJaEpVmlMwtpSfTG3qT0NKUxcJ06QbPapAIbpPLmp1q1zFqlWjGr2qlnCs bGUpSrP60rSik67wsiA7y2AKnPrzrZ7SKVort9O7ulVwhfVDSZGFTr6mS5lJJepUCQpEfa31sAZ0 CzfBis+T/tCyrXpsuzhS1qIO1P6smd2O4rSju7DW1aCRhZtsm0kO0wYVtphVrVxPJbV8HpM999Qc be3Fk9tStrFK3S1jfyvZFJYzO5t6HXGxeFCdWnd8ABvtVuOQ2LlMKq5iw+4qwzufwLJCL5dkbaPk GdqmrmC9z6rdX1NWSzdIF7LURS8F4muXLGb0v8sFUIBbCwK8XorAmKIv7M67tOYk+I+y+5CEBQy4 PHL2wsI9az5x8iTzNtjBD4YwXSjcqBJXuGon5l+Gdbndoam4ogsWGX4fJg345RVHJnOxdnSM4pn0 GII1ga9+FQvkENP4ah9LMng9eTIjM+jJPi6ukGeKEUsR+cdUpoUQhxjDGh/Ie/44poiWDRZlKb/M zM9KM2J3jIw179dt47phr8Kc2jHr9my/da9P63xazVZTyX21sph1GGcsm4XLbibzXO2cZ7ui2KsP TaeXYfloRCOteyokqymV+GFNn7nQia5uDZvh4S0bEaakvrSqVy1qGnUa1KVGddFm3WoZO9bUVM21 IWsda1/L0tW/hhaShV1sY9v608uV87GZ3exRLzuZNnP2tKlNa5kFENPV1va2BW00f2GN2+EWd9wM XW5za3jc6VY3Es/d7l6vG97x7pm7DS3veTtUaXu29743h28ZpSB3b+b3wCkoqcwYfLqLJvi29a0p gA/n4aSVwXDbvHBsK7yC/v4uxRQi/rhEPCTiG59sw1GyBhsDYTO9s7iABU6MjqMlARyHVcwNPPKK u3CyNE+F8fhQ5z7fG1Iif3a+y1u2mzdr5lugeYhzXvOdk0ZOV3j6vMfm836QfCUvP8jSlZ70eCE8 vw05eQI517qQdNwwbhp5AmF+C6l7HSpJPyHcM3nj0IhYMFq3BNcHofeD+71tUh80Q9CtnJAvfTOI 17nMFS8Cuu/k4U+femPtPmRTtQntukr84vENdo9PXCyZn9+rqz54e4w902pf++GdzvjFr57v52K9 5I8e3JQfIyFYt8Lscy50kQ8O7EJ3eu2zLneuD15alU856j2LiKjjvfev7/569Guuc+I7PuR7rT7l b3/3P+g+tpuXPvWF/xMbz3zyPBd/65sOUu/jfsjUFI/xWUD+2O89+6P/e/vr3v0b290mnu/7pu73 OkMATe7xcuIAESIBXUr5SAn+/g39JlD6ClAUGjA/+K//csz0kA/zqA/pqs8Cd4P+0K4yStDrrs8Y HlAzUEX3gq/x2I8Bt+8Q1m9zhuUBTw6o4o4CK7Dxyq/tYI/97k8Be3AIaZD7OFB1uq/5qAH7dCb3 QM8Dk2zlsIL3fpAiiLAOrtD6TpD+aA8H/a8DI7AKy1ASnjDtfuH3+MaC/ubjrDD/OkIFgSEH4cdy wM8M83AcMPA6+FAP//4wD23w6zQQEAvxD/2NOQxREReRERvRER8REiNREieREivREiexIuBr7Ziw CS/RE7Mp7b5QBAeoBu3vBzcPFT9RFVPNFEXQ7bCwTJ5wCH1PCOdwFdWN3nJR09oQ9mhx/EZLE3sx BqPnFouRBtznhCbPFwXx1vBv+5aR/2zRGNdt+fZqbYSvFQ6pZIIQDXvQF/3Q+X4RFl3xGT0xEwkw 5jixuWbsT1JRHfGwFIkw8eYxBbWQG52xFWcxBrExFsdx0CRPCClR/L7R9MbR5fzR5oQRCctGA3eO HpsOFdeG8wxs7jhw4/6xG32Q8LzRHrmmUibhI6Xx2HhRIwfy+PbQBP7J0STL8XCWT+se8iTTUSYp kiITJyMd0iYX8hzlkO9CcRqvBSIREn8cjSVTMfaaMQPvzxr5Mfpy4CGlEA1NDiSP8CcLav2g8Sih LiaNEglFEhIgEvRmMiibEvugEgivciZHsCrBqRaF8ghvjiv1kRzfcrgIESYD0gLNsiapUiVbLy/X 0p5aESMV8uhWMiK3MiC3RhClSietUV0KECpFj1j+EjCjjRRVpycv84ZCkip9si7XQhgqUzRF6n2+ cjRPM6WQETVXs5C8Mh5ZEzb7SDXhyvpcMza1zTZNc+tYkinEMjdv09l+c/7aLv0AQywXEjjN8Qxh JSznMgQ1ADnxcf4LR5GHDCM5jTFBphI60skJkY0me1Mnr7MYszMyHXL4UC4LrMwpL3I68c/zjLMr xbMtB/E8ZTPrJi4srZMQ2BMk+dMvm9MIiBPw4PA9r5MpIcs3/ekM8ZM6mdMHIdNB2TM6j3E3C/TV qkE4B873MrT4mpNDdTNAGVQtI9MvJ5Ko9HJCZbFkzs8pYlI+qQBAA89Cn2hBaXJES9RG01EvUXQ7 K1RFvXAxDbQn6bMiFyg2JhId1xBtpFAiNzJFB7T+4rNFRxHEVLH8PhQ6pbTgZnM6SVI+cWZIEZQG sRREvehLgW0UyJS8ZlBBb+pMZSkr/eRA25RG39SOzlJMgxTbuNjUTjcqTh2OShERUOu0TwtVTAnV UBO1D1cvRl0PIHEP8ZjQOhWVUsFTJhn0g/4jPRVvBnkUHCsVVHnwUnO0L8fQQb+zEM6yPHG0OEPV VbVyVHPSLD01JUvV/vYTP1v1VXcV8k6UVCX0ImPHSw2TRJ8SRzuSV5PVOyL0O4H1OM/BCCG0/ZTx U5XVWvuKWYv1RGm1HovyWU2URJ/0Wsc1HE0RLU01JQnwQAFwUsnVXcu0+KpVVN+VXpUCHwX1NetV X+eBT/fVX/vOTf9VYHlNFwu26AYWYYunAAAAO1BLAwQUAAAACAB6AZAnknJvt6MtAACchQAACgAA AHBhcnQyLmh0bWy8W2tz20h2/Y6q+Q9dTFUsbUhaD9txtLK8lCyPVbFsDSWPd5NKpZpAk0SEBwcN iOL++txzb3cDoJQZOVFla2vGQwD9uI9zz334+NPN5eeTSB1/Op98oH8rdXxzcfP5/OTj2dU3dTn5 8m3yWU3Pfx2rvfG+GqmryfRGHRy/lJf4/cvzm4n6dHNzNTr/5dvFr+8GU7PKNqO6HKi4LGpT1O8G 6+VmYcxf8jQ342b1dmySZtD5+svk8vzd4OfzL+fTyc3X6UCdff1yc/7l5t3gO3/4wqpcL9JYzdNi YSqrykItU6vu0qLWC6NuzWZW6irBmscv5SrHp18//O3kp+in6PgjraauL/7t/N1on375OMLdPhib Lgp1Y3R+fDrFz4/c+PglvqWHx5+mstbVyT8WM7v6c+ePv/9PevH0pHOEfzo4udJVrQ7UkVv9+OXp yeMrb/8R59g/+dkUptKZSoyNq3RVp2WBG5RzVS+N4tuREPafuKb/Y+c/RB50ZaVOp+eTf8V/eCXZ Js91tRnQqScnD78hS5iefwyvjZd1nv1D+OZa/oBP5Tb+9RVJZH/r5avK3KVlYxUeqp393cc/O9z6 7Iu5r90nh+0nP0VP1FV36QNZOl7qSse1qVJbp7EdnByQK9yQqHOdFoqets94P5bE/367tLB11cRQ 6zpN6iX2O+D9Ok+s0pVRhwejWVores08x86VWexV2jbY8VBNzYIuZSq1p8jVBpXRyUjb0d9NVb5s irxM0nmqZ5kZPMfWb17R5izaV3xV8dGlturNK1W5kzyLeO90xce26d8N9nvd2Y/uqZV/YYQ31Koq Y2NtWT3H3tcXlx+w55v+nvh5VFYpQaVJnmOfhSAEyQ27/fOWRN1Tul3yvKK1KxOnYdu3W9u6p8+7 ZVHaWse32O9ftvYrSsXP1KqkMGGeRYFFeXY2ZQDYe7gbRbskhXPSnxIT7vkc+xpaWRe88X7fduQJ mfOziHNFUbZg7e0fdPZprAEML8hgcpOXDsH/j3udXZ7yRoedjWxdVrQV4hjprjaKgppWtba3BH7q DHTivv4puuRDqNOsjG+f5d6JmTVy7S78xLrA1fk4dFo6F5kUyQfYUJsVn+t5xF6VtWFc5zO83ha9 pm3zVcZo5F4kRVDkKVKbSyD+g/Ddf9bG863YxlH9qRf59iAQdpcCvfl2EuEx7iFkZUYWtDQUuSDa GSRbNotlrTTuGFclAe2dqaKZqdfGFPTb9GBvb4+WTldqp6yU0VW2UZPPV58mu0oXCb1x9uHszRu8 U+arhnYfq+syN3BGCpZ0rlpCJQkwzXSljqJAklTe2BqnADiJfLHkylTzssp1wcda0ZlSigZj9bEq czYFPtNQUeBNC7pMSjvM6RkvPL24PntcHFl6a4i/3pMEOLB0g/mQ1/WAoayp+STsBvRu5Kgdi6Fe 6hqOPysbemW2kSdNVVH0UGQcy6LMysVmrC4KMVyRz1B9PNsDf07Evcy9iRtsHtl4aXIjR7Ax+R9T afnvvMnqlA2PLpNlJmu/U02Bm+OcOYEwe2qWqSP+ji63SivN65Mwlc1ByPh06W8NezjdwmhyrllZ L2EdIOMs/qpcVDrPyc/GZLbRk6yRzWxeZlm5pu8UUEKCOfx0NNuIv3YIcxCpCI6MKjF3JitXK9IP W8eYLXtudN0AktYpXY5shYDH0LtIcTo2TQePFgYGQfpLzIpQmVYdKluymVjSLdlnjp8ToAjIFPbP 2XL4JDPSflHg9EejXfXd+B3p12idkoxYH5D0TFtKhRxEbVnZzMz5gKmNGwuskgPTMekxBV9ImD5J 1uQTo3DQyDaz/yJcseMWKEj0HiS2GamgxNMUwyjxFPr67QQSJ1GlNtKK/QqpndMTubLEVroD+1jg ZeQ83ldmRGzmMEr66H/wtAj7FmXtJcS620BGQzLt2KxqBXuNTVXDiYuUnEPp1Soj6fECY3V+Z8Sz 8pQQCyluRYZHqEU2fmtY22lxp6Fp8k4+bFyKCZEWe+cKxxoDl58k0G1JylIOTjuXUpAs657ut9ab cXTBR4szwlBxP63234gCyirBEi9qzthxcVMAmImz6djAYJnRHI5KAkdIuydSum2Z3YnfFSz8QPFY NfxR4EWWHQvnAioDqg9ejfi9V29xmqh7ua6WZ00NsW/4w4zgvBZfEh2J8K3aYZz9cH21682C/LTE 1ea8tiI3L5ja48r4MksLHOpirtZ0qBj7OZaDMgMJckM8BD7HMA3khS8Dw8qSo05m7sfRqYm15wqB nCEQEE5oSmJY0OE6Q/9LzyeW+g5GbPjeFHhMMozWLKt6XT50H9LNLb3iBMOeE8IcyeXA+1fvw/WS xAVlRwh8dUlGPMSPhPH+kDolxYk50DuWbL/2OgOmZgRquOWlqWIS4s7F5M2rXbEoIsLR/sHb7V3Z wEh6RmNrsTCYyyGZBpsEqyqEPw9L8YYW4VAsPhJdpwVZI2kJgg6cqBuzsM7MaQLnGrE17Pz6+eL7 LuuK7lmJ9IhnUOys0vh2E5G0XNgZYvnM1BI6AbCC9zFhFD2iX1m2MzBPfmeVrgwsSBFqAFdIXwQb xiRQXr1sIDAXlTQjnSIHElwLy9ebFZuTC65iRFbnxl+xj2BtkGS8fhoOi+xa62Tw0hVRChBKCnFq zVkMISNhaAEIqbfikoNi2huxYhjV25i+1En3Fuw9/SsHB3B33vHiI93ZhnDCUpDS1TAqm3pUzikp Tgw5C/QHK6WM4A4KQGBu5NAIkjGF09rsjtVE4FXce/iI/YNaRdaYnMU9M+6GFFTjZZnGhsGfhZ7G ab1he+IjzdIM/50Wnc3HlJD0omhJ1CJPrZirx+ScIgFEwTulhaY03yIwIKhsIFbOi+cU0UHEkibD b1VDGR17Nku5E4DkxhTs6Z9VU2Dlkq1yrsnzN0CuGUzc+eMdHEVAqjagLOl8bsB4IljeOAox3td+ JLZ3acBPPxLpf6hs1Av5hVwjzjTxFlCVAULnwDMw5XlvbsDMYWZgjwQf7FqMH0njTFxghR42RT2O eAtY953OGmzNWkYqkdKGbYhhIH3ApKEu+HOrpyWSikgTAa/ZJj3jDUaWlBxQ+LhJk8/otInehDA6 uP52qqb7Q/7/gH/moDzdjzx2kdViT7bSuakJNulln5m08YRoG5Ic2RUyWBNrEhEQ4SDujvgBaAcz X8PFCxc0k9JFC/BYv73TRkbOBPCFyJZpQqbt7VfSr8uLq+voKWKzDYzNU1xa+TYFHZh7rYV8YOhB OzIMy8zWmVmltDi/Wobbi4I9pQClIVKcbXwEXzvzIHWRQSBfMrTuw2yrpzADxVRqAQYhhNnFdeZl 16UPkfhwuvcO2WZBPMKf4JZ4I68qIZJXMPlqCdIA2QXT6R5jHH2EGd5r7DTkjcQyDtkyDgY+VtNR NPjjdJ91PD0Y+hIe29RtUa5VOlcLRsEKgcj81uhsGDkEqihZ0QjVhF4f9wl7ZK+zy6vOXt7y8Cvs 18dYV7STQ6TW5X1ytAiFL5SegsmQkwL0e3a5o+c4ljNB4WIxIrB4EERaNDnx/ZiLg85sjTdO1idI PTgR0fLNrihlcPn1V/aivYEYMAuIOXZRhgPNOrQM7s9RaLonRAbYtGH5FdEOZ0VpJe4BtNp9PBmS SvUPpECuUvL7de1vJ97EtrKbqJP5kDQY0Q8P2k/H6rIUdITgKwqmC44SFETF51xqhyXvXOLNMcWl 3BL3hBK5tJZIFwmqiCWB0SorObtHCSA3zOp3eOWsLG+lrkEJW73knJa2DgWuwqztEQxnDJ4xOAl/ hOwoWn829QtZxXGN/Ig1O9lVgwsmk4EM30EtgNq33dwCHDjrZCuAdc6QdbYoCQmXRJAGrOooocPN UA6irxZkbcAIzoEo4YfpIBGh4A3clmMRSSCFCANYkoPxjcnr46yxEDCoLp+O47scfOSSfVLF188f CMWaZDNsn4QLUTJhWFQU8csym7EE/JE9Ilj/pctF1t7XpLKVauZkrHcJLztGElMWRa4XBV0o9qkn ndYSDZWkyK1Idu7+1M8QjOBfXhb+CCg8Cb3jE1QlA3q7s8/7sLnVKDHdkSD9r8RLMlp5169Gvj35 /H3yt2vBmKArpxHafeBgp4UlTh0c65XKjjAJIUXMieEAiV7VEhc4yuAOhDVW2HXAMvwwVDtg+ukd IgEtd3xxQgacHb+8OEG6khF9TNKEsCralI1g7Ptdf4FlycpkMurrVaTR+7dvunQC61Iyns/IpzJi wNyppoUsGxSlWcW8ycRkxmMBtRuO3IyDGlgLiyaXl+zB+WHrAKmVWlLgPcxTcNNaEn/SV0lK4+qk qHqMyhKgmG8kVTiYDeOmxYVYQJxRi21kqIuRuFpi1s0apKAir45sras7pvIUlQhLQvkp9NxoldJy QYHpxFYtUW7C9cmo5KN0640O0qUoeAqMmLuQiyMgGc8bMpJWPCEeUzxgk+XKjlCPrsUPuGjJ7NKn 2y0+dpMW65wbtUz6fUZ5AZIqyNnZmiWTp7xgAiom56J36Th2CDkh8tHP7ykSVOylIeWlZxoVz6EP hzMEctp6ubEuLro3XUy/S6u6QUSIzH0dyoq62LSfcIlEpHVG0oJp5RIqvMyCqGTbrMRwBQyy1rfO ZcguSKa+Hs8NDxAMHcN+MrMwkdQ8q2ZVW8FaR+SdBXva3i1NkSFzQaEYqpScrQD1AtZe0EoZe9aK Ep/9gy7YkzMhoVfv379/WqdF9QpeUgST0/zp4+T65k8ynHJf+zuKalNrG8kPgr+VMxlDkAuhDOHc pFPONveplZo95Lo2zsHoglyACNpbEwEGAOzQ6lpdX02mZ7vD9vFMF7eRnAdGKrUsuvmH6yu7C7k7 R6vLkfPOni+qHeTv7AW8+65kkEVZ+Dpq7u2nscIHQxWlU4HXlEVXlhlDzcyXXYJyeGKzNbsQpVWR s3qwZM6UGXBEfoJlrv/gS9GlDxHcLuIsN2PPgMFJGHZB/ujpxdBR6D1gXQRw1mMsvgHEB3mUg7j0 2lQvbMR52E6KhOFF1SuXCyn9ei35w65yxa6OiuJbyirETlLX1uHNKyNJakQ5k+thohZv6+GP3Kfv /07Ls4b0gYoCq41JWd96Ixhs0boiAn5t7EPpcHmqbtGdLC7hmr7cRYqqO100i3o9sRhfakvWBg5l pcZzdSBVicTLijYl2VLghHBhk0iXUIBKdn9EFtr1jUKIrWQfvia59d1DvUCx0i65mP5CUFIkmWHQ b3NMEVSb/DVWjEUSbvgKqY+STh2yalRfbdlUFAWGEVo6IlAweVfrku96lWtsu4kzj7ck3i9f2wAt mIMA17WuyHIPiRfjj7mLNzdr3FxqqBTLeJEOEWDYsIFA0A3n5AFgi5Lqi2djn8F1XqLdFmo0pyy1 wZBE7btCLay5/NOlj5azBlvOa35L160ahIiarg5UaFlJX7at/7dZ1RPrShNZ0Dlaao+i46vpOeHL 9Jf//DT58uHz+fQIo4S+iqH4f3920t/HI2ZBlDf/e5rn/xEeHbSPDrceHeLR1yvOLw+G08POgq/8 I/xO2Wfn0Ws8Eu6FzaaH7YJvIqJ44+j4JR/dgbAOFBUX5Ni0LpssaQuTndIrfdIx6ac3jKLv3bJp sBmHMWhqrFGf9LkljBP/Jjm6XqKT45Du1P/pgKGBhNP79dBVkeQmYBLqsJ9g9C/aOnPyxzp2wt0X df2B1ltN+Jd/xw7cy4fbL///WsbTtXrzO+4sCZIL7MGvw8CIKEA3dYnOSiyRkuRvo5Zuhbb0yk9h ugSf4I8gqOvpDEczI6w66NJxABlV8PnuIz2bbhFQqwEGFIR+DDopMexM4Jm4SaYX0YoJprv1DlAz BLbwc0i3cbcELIvRdY6AtOvLs21pPGKGg0qb1A+xFkWLKnSXu0V4F5HQm5AWv/NoSHghzEp6BG2d 1NXsXI7NrWCzViQOwmpfX/167Zyng8Fu7iDMGkSuSoN0qGJ6f8MoGyoTEu5tn3mlzu26VSfle+E+ dyIr9EmocHg6PGVtnHAf4R/0tSu1vH/6aEbbeWICD7X0qL107Trdn27CxcbFaUvQ66qskE+5tLj3 zHLaaft2gPc93LFZ03nA5TFgoiYwKXRbRGz0FmVqnTaVwBSfYqcHYiG+796HJhY6l/Vy9/6wm4RS VnZXpknwLQy2ZZljTuxA1vzG5Ta2CrDPh53QFIUpZJUWwuRI3N80WOnjh5QpG3dxBnlMq7DsOtRO WnrtQaUQJqMK8iWdomdBIh7ucNJtXo2EFnd1SSQJ7VWOLa/bQ1sMd9ihoxhSSXTZhDOxsfrM5WwG DJBNqfSwP8AuNcoqoHMPkmgZOug0EHuDR49fHQ3Hbs1ICGPziMNs6OtOvVFLmoR2pkDeE0kNn6RV SI/193ToGGaikqbC5aSJDqVK1u4aoVxYtiIeNldzL03Mh/LxARqvetW5aSI3Q6ecxiJfwtuu1HhL Zbzz9K9Lf6Vt36+ghxJ6dwT76ROHisvoTx/X/nbiWn/8mszpEA2yKAFadKX7/WzlJxgkaFAg4sCI gZAVxO8JrfvrI4uSlhHrle7OBiVEuvYaQY3bJXUqXWPUFHEUX3ZxUyHIKlxNgbZcpuzACEnSifYl 5Ynt4iFMmzu96K8ZzN04M0h0zc32etmbT6nTxbIm6EBhlPQUbb0qIEQWiBm5mMfxuGflUgfP3znH x45OZCh0lkIof538NRIx4GqoTZNokclj0Lwsk1DOxreoe+o1qp5cResMH0j8xLnH7t7foaDaDVMo mdDg2Rw+Pi0WWtkMUTak+ZibQK6LiQIcy/oBcAoaYVyOoGdOBI97i/yYJYvXFoEcW7Uzbzt0Ui3x H43kIzrW5Prs4iKaNwUbPhGLG/Th2FO5l+mk7bIhPt0sXThYlYkLujuPDsAwy0z8zDdE144CMDPp 1sPmbbk2XApKcXcI8wcyJYSfS84rQ64pWgs8nFBMu+awG4JipLHNDIPKP5JvOEoId3gw3Mj1dS2W sZaeOBftPQOaZzLQyuJx1iYSNJGkPqG62law8ZKz584XHZNxVQMHtlLZ641yDDud9xdoDXLhBM85 M3InDSt0AgcX1P3sXFOEi5CYG4p/Ubdy0n5PSJS6AUGGfmKClnw6LsPIm7Hd3qXU1wjSCY/TO6nJ hGaqbwDzKCXGYQjq0qIxMsHK0y3ehlk+qfMhP9OLlCCVv4USrdrpW1e7TP19Yrja5eVfh+r6+nyo Jtlqqa/Ohurq6gx2x8XMXgyw6KZL9ZAML9qqjkAqNthwaOhbN2j95hUXBgXiOFiCNOLeB6/fYLiR 2U13UeGRqD7D+TwR5EAH09iifm1HHxHCK2aRIg3aJgdj9RXMoKmsGfq6Pvx21qSZjJ+oq5+vRjNa 49Yw5ZGzvN73A0jiktwrcbZVcEoug2KiqK6lMLw7yXfUNBS67s2dRNWZIIjSTlbN0EPGA6yFI7g1 NspNE6guErKeHb2Q1j3/yQCh3cB893BkRIKsoSEXtk1SshNMU6NZT7yb29Y+kngXbYNQ8F7/ty2c izNbuGHHuK8VeJuftDjiGMJDZe+fPPvmZzPb2VvLmlZVKmTY5TkWVS1gJJdKuaTKedBQBgDbQoyu SK0VEQ9KGx+AuYCbB3KGqyH/FQPQCqfTjj9uC3zoZUXWLdBZ1y7PZGD0AYKFIfN67myPw+A6kCJX p4kCmfsBUIcy6Eg6JJKhEGiXrHzMotEl59r2/toEDwRcnHAoZOzPNXobpj/NF7nhtV6WjLYoOwb/ tYecXUsGMQMPcZVrSb8pBHeHYYVGRezdYUSvW9cIQIdWssna+rBbTwZdNUOgBEXG9yP3eerzpfbv XLjunTHub090IWT8A8K+LrmAQEGBi760ZR/rSaDwvbSsUpZpvRUwA0vg4OTLeqSh7WFCn39x2MBf UVgUWAZvhVSAosk8XTSVnz6sl6GR3huqilwGioZ7ls4q7QbRKLdbSWhkesJte4l6jpapZkWGKnPh jq234Rd8yddQYFcoygniJhtkM7HivarNDwn4q69IeAAD7Q/3l0S6/zcrHuMXPSlpTIIU/93Z1TW3 jRzb96nyf0D4EIsVipZkrWvjyKqSvHLsir3asuRy8pSCRFBEliJ5CVJa/fs753T3fIBkLGQftmSS GAxmevrj9OmGD2pFKGxgfN46Gtl1jL+azMBodiGFm1AE5krZY2qGguwLO2TK9NGjAzIP0nWLqF4v rxLtKsVW43I99cpu6YcNDMt5Ud2vgSulGP21AWubavj5GjgRQwsR5ABP5tOonyTXHv0PydUPnD/7 9NPzMKia+ee5VcV3zwALnNAa/k6qJf091+r1zQFarkoumUg+JXCxhKeC+RyJZ6HbzPUm3qhqO2cR +nU0rrR+f3J+KtHhWRrb/H3NApdzCQI5oEAJ/hzfoIqIe8GTHKZTaTAIz/Mt6WfvL369vvACfnJ9 dv75oritptNFOcICvXvNf6FWA/86KG6Ierw7RDeE66+nJ9e/nNrlHz6f/f2qSD9BUwLMH2UOTfbN 90+/XH/kV35NTl75kTbHOwDKnV2lSLz+l37zsx/j47YxDtu/PNo5xuGbHYMcbkzkeOcgr492DbIx k593DvLmWAbx/8eGnJ680i+er4a+ScY5E8wiz45M57eMyjYFUEirGACQzEByhrxMVKzS81WeAimK UjWuq2kkjMwfBXZaPc4NGiqfmGlkQlguJcPBfNLMl/fCUU3HYqqzJ6FVoSMa8LoEIg+WWOVf6Jl+ 1kKNOd6sFx9uqSJjpGrOz8YVMgUfMwGJ58IuYgEtdAgVuTiEAl9MiCgMUBhy5112QRO1Mowr6O+z fKxJ8vHLOF5NXPuuAbLPGKWY36S+m0A7BeeIjxxUUVNEPwVhp0udFdF8QydA2v+gDAoe53e9n346 6G0R/St9ipBLmsHybkh9tlnb1YZBITs0xtVvX/8NnfPvg/bRLjZvB7K/ut3UU1Bf7w4OdhzfMPRh a5ij5458+KORj1rDHD9z5MMfzvl1W/M8d+QfzvnL2T+zYdYzsoOKSHnub97rS/lHfb++V79HXJuA V7DDzG7l9/yQwqIIiZcBNNW3gE0UBbKKrXCkkrJGyxaY125pLxfynKowEoJpLOIFdxQ5ndQ7tW+D horBdd+8W//herlF0VgpOXONfBiwYObLFm7PTgZK/lCsjnwd1LYxIExq1GbCtt2Hq7dvVXUA+VXN Kz/e2O12MmWCVGkgf3GtmvliQjeWtiTew55YYAioKS2hTeKkPPDHR8w8Dpw4oqQGm2b2n49RMGqr 4dfAr9RKBAdkl7xISXY9smkcCw8Q0zbrBdN2BlWbx/vmGAIwUOEYheiTgbePk+8XxGRjkJHw+vvi z23u3R7QQMXO4Df3tdoRwfLALG+UInHwe5gVstQy6MQMNhlajJJ49vSIapZYUy5NXGcmWpaATUYD //iPM6lMja5uhxr4s5UXGB9kWCl/KFtzSR5Xjj4zrkDWNKPIKwJIGyuq24U6yPgR6uQRKZQXuj3J rb7EnQ+jvGBUoasHC7AkaaUC9SEgZvjX3C+k1H75cf3kagVKptVqFSx9QB/wEGYjBcNBAInYiZQD 0HPvyno2LD75kGWh7hWcILctB2QHopnDsUFKfRSdr02n3iZdopyOKxWyHTYScKaZwBKPkuZIAiB1 SJg9LD4cxquC0Dp1HTK7qwdHBZ5rksr8vYkyXRiL9YbFuZ+Dnt3jg79K6bekDaN+pQdKrMBCsUYJ ZFzOwvSQXodpPCBbhcRaOczqBpMuI4CWuyb6/nuPpG+nRYbYw/v1sv/k2lA9Fi9mViPMbIoNmdKQ US0srxlxYj0GLPJ3qGu7FWVnaceiyfsoaUa1QqTtQ9q0eFRkZd2EL9P8s01YRIVT2gKY0/rHZ0AU AA1JfavFnlgoxpgMUFdzF/JktUEyFLd0NVobF/Yt9pHqunvP7Dn17XTwwplbI1TxVgqOCVPitlSq lsqTRGiejNNLhi/oWhBC0nT+nCVQigcE0xaYUU2d0UOV/lz5ZbtdBcCzXr0Im9S0xArMqFdSe0l2 SkyaRCqFFk1FeCuW6r8wMsvqEWcpp7T0lZXzbJ9KZh/KnMLjaoclaL0NEJeFj8LNWkalhsskZ+3i Wimy0khQIxoMilf7pRhznPZG8tBhBlmpj1fVFVI7bx2bQGDshVesrD+jCOyTNmZ5GiEkMbEYmPmt DK7oxmHxkYsJvAytC/JNGMcMaSZCRSZCGn8DL/M+00LYM6kHYLKizkRLBTwGn8Qcgj1uwG+cQojt 1zN+l+aYxVd0QfUyM1OSMF+xspMO8L2fkv/e+3S3XplIdaCtU1gcf7e6Mc9Ox12WT/uoy6QaYaE7 4D7sZl/SquFqmpF4Pdl1LGFbIAUpUOuZVnpETjC9PYo4WfTiaAakuUrEmmpS0c24sEyQhV41WJgs C/fRKqGURbgnzbj6cdTeYj6f9op4RpEwIAOuYy+hpkI3Ny8izaPQYTKFkfhTetLtq/QUWIeeeiEe 2YfDgYuBjDYSE8ZUaIMQPT9bMSagQb7MmE7lSDUNDqe2mxDjskqrnlLRt0mXrb4OsplCtqI3PxBV SzWUoS2c6yiyygbFJhurjM4iii7D2q2q8r54W4hlC/OCafBuDMu8K3b46i20zLfXFyxWrcKIwYur 8wwHnpOHiJi2GodBwtPIzvWgqFa3lkl7UoKEuy/Z9MnPMzJKNuuuNJmNIybNF4Txup5JILktr+Tk 3v40PdTVowaj9rCNVWApaD9KCbniK0jGx+gvIbicL107tsyLQapWG6foh8UGjc+351K9/Ixmjt9O 1aistMrM2bSik22iLXgCP32oVzjrChoZtA/ELgHrumUqo2JOlLJx7okY0pmVc0W0sWS2bVtei/NB u5zoTjO30hbEELpKKdh8GfLB8AdVzSuxRnWG9kxw3tmeJbs4LIQxq24CU6fCaaibAMTYxFfbn5Yx qpBGcKff/d+4/8mn07immnCAeUGXt32QnQf6N3EKpEWXM/MSkaB+8oNLpmXrEuN2xHu9evbKSRsx 5HlFL0AvmzypGLCVnj+KPcVsyfvYStUpBOgU/ZT0ZxPPfTVfS/HcqgVT+wM8bPc1sXOhXUS7Hoof dxxFh5PLJafqvI0HNWJgpeAzlOaMFJPJriM5PRuwpBwRjEBtT9IvI1OnaXFf5HFZ5e8leLe0Ogk0 nd1YfBMnvk0IqENZ9pgtB/0c3uc9ChTv+r91vYxiwdZKjQAciHcgkfc5YyWwfxbrZlL82c9ikZ89 mUhoQhiek/lQrV7k80j0Jp9sI5Ibxq6TjPrrHmbP/5GVLLIFgxaBx0YfjXhx/gydnX/C4elzUWyx tUcUewWwL9i9tw20WaGbZdJGDgpCf1rPvL9DHzLTKI0a6nqZADPW/EnYY6hMZ7FOfl2o1n2cIxc/ ZdVYyorCdTRYEna4NwciBsp/AVON1XvLpAQjrFytXMCzPPVCMarTsDpyHmWPkLp/JcYh6w3GjUE7 hYU/hfsMsRi47EFD9/0TLDSARr8lgU5qS8ss/HrsAzbL5Fjs5ROKdwJ/EmjhW4mkvJhZfVEhZT7D N8dWl/OXn61IC0KZ/I4zT364H374LIURqyCgvkICCh9oKab0+aF7GdZwk9OKfwphYmSnFhyX8sGH CMQjQA4ZU/koMyRZ7I6En531RcER9vNjcaBC0qZ7bvKWEoJpoAzZBX51ebeEY7Ne+IV4qkKDOT/7 +1KYQjcblZriXqBSCcdHnSDpD9+wAnaal1PS7YUetAY81agIUUfaNY++gLJwyVhTszJ80bIYLxKT 8f79164Go1PXaNgOKVLypzdEnIEJZIXH97ExosakCKdX3j1gw4VQFxUxWihH/w2qmGduvJTqE3E5 d1SPvBW/Q4IveEr0zI1nXsbSDaW3+PDvAe6/tUfl4ewofIHCwQCibtKgi95T6EdBdT0umwl+/bYo s+ig8lrI/4WGPtqib+jOipuljygnElCHDUhpqLzUKi/qcWtQjrYnw2XZAhc42TZocDy9LK4Xg+in TGK7DvWGSyMoVtJeAmucMtDdDm+/32Flz9cr4oKoDikZcAoizJBS9jd9UL8YWL0eesf0TBuhkbDp Lm3K4R/hiQ1mCipjdDdY3qUIGYusM/GSeCgl6kgpWhF644raKF2P/UjwNpHFk8USiktA2VlExTKL 4jO5rLExLySRvi+u6oUf9xBGxVgzo/1ES2rXtaJJxsGDbaGs92VDNHtjbbK4kEmgJ5lAUEwzZQXe hbe1fj2HxffQbcy+hpKXkNN7dRLCiDGQTLy12VigyjGy0AWTvFlTy/lFZCkAnkp2EKg5Wq5q8dOb 1/B3lsjaQXwlr5DN8VGHHGA8yin1cLVS6gKBJcM+0clLS3BUpHtpjaUXndtJr7gjYw2/qVdryU+m PWK2tWlDhbzUdc1d0v3GZHE+zs50LnTBDj9tBuCKu8sTwl8NQEqo24e3FW2P6N8dxzJktJbGGHfK L0FjU4hQh/ad18lkbssl3IVpeafaDfU9akPodMkPMmcsBrrq+aIt971JfD3LbSxXQNUsx6IRVQwf MC2a00apIEtb9svJtofvNAnIEsiGdKO4BmqjoqPYXkHJcpEh6QKLTyakGdYvv+QmC2R1MemxsFdz MMBGkfX0Oh2NL3dEgvI6hc52vfVShl58K0Mvy1WpNaK/AeK4/A4S5R3clZ+ifgA0wTER7vVOM34S FOBmPvJO8PU8ZD2jVUy6D8IxllGk9kDORnC+3aYSjq6BcLlMGbOTzE1dSoSDwjZNtHH4GSm5IuLZ oDwVAu6HUgnrQmfGfFTdgGeq/G4WvNV0SfTY+1uw+tp7YIgYx+slFy7tBzwIliKrdA5dBVuvWvhJ XrVwwbl/8Iendyp/8yTpi4K2iYS8E6OzSPzg/RlAy+YWyvEh8Lgi12Y+F8v6oYSyBTSMrrja9Slp 4Ja0yIK6Rn+mYfGbv5NkT1K+G0QD1AODzwcBuLekqf6Ys+FQL+1O7AOumRzoyLmonV9jUzUyYUUH geVtHJzo8BtVFvWzmg33DtxarWDs3b/5GolnOzf7Is2oLJagjylRc8nIiRlk6Zbjf5wPitdH+P/R T2/+cU5xPjo4/hmf7LAySXMuOG32TgHAIHuwvkQu1QYymkGigwGNV3cr9Bov/vT8LjjZM4UgC8pt aTCmrB+q1ODqj6c+bBVjhSgNR+P3xu1Vuk/Tp+DUTNZ3OnCn6VwGnikM//JBAw7pFG/IZtpAblL7 5V/eTihiE7A7oDCIbUackPPo4MfKsuA+ll1XWrX6pUlGVr4wDDoKhwWrth5sbuvycnPiV4pGy0Ml JnymYCnTqoRGm2jLLq9yTBvtJZBagaJko0z4xJD3iAHGHBIazkJr0k6keiPkO+JpdeG0Fgk4pH33 auGZhjZSK1EB3LdGkiY90wK9Qjv93LOXtazXl4urT8JRuZ1PO+8P4Qn4YNefz8UW2M32b+29CZlv Im5im4vaUNPo6xZGFUL9LV1N6kb6bRH6ohdDFVBNF1bKVsqRFQqSf8ilbKLAo+5shk2LVF/EmYL5 V5IAZbWSvY2I/ttWgEJR11IHdgFxMB99FiHtsEBQ2cU1J7bnF6ufOKrLqpVmu6mUHgyEDtoMNd58 Hi3R3lBr/kei1cTB3Ttk+fbro0x74RyATTJw4U5kqdj5SE18f2BC/tv1hd+ZppGsiDXcMgIgswFo 9jteT1l8iGpH92yv91NUwYQuCy2us+aQae8KOd7K47J6oxm9ofG4vgVxyM835Bo+f/r12z/5egAR TPw1fdJEG37AutlmzYZodrqzityMKulnw4NItaa1spBFyJ05sqMHTJTpn9/9rlfTrHRMX5FDgqh1 qhPNEedP8U1OaZI6z1ypOQCLkJbfuMrvo1c4d08u6JjYNuXjdwNzoFS9TR5EtSGuOH8mKyLL1WKM KrfPhbnVt+HZW0Qjc7Hefznv/E6Z7u8NK7LXhhV7/q59wmwvNKNl+SsX7ZKIPDNMdg680Kddpa++ nidKKC6kHgV1mrxWqrX9QiD9QvVRb2PkaFeszyQfz99MWuuhKawZF7RpkGcwHwXhkYbjaYGdwBu1 CaAopiXURRNXSP1oacBq+UPAI6F4BMIk+410AiofLFIzw8LXYfDQa+tZRWJjla/QJujPOkaTtjnh gIuKiK1rLcbWt4+kUYcaJ7+BBo+qd9mFLbtVLDDeqJb0ipR9RqZf9PyAh6HdaXiyklXmlVP808qZ jca8V1cD5S432jVGO/j7X3pdf8FOC9N5eP+OWhbOxDv87m7qNfKUnJ1W1rUjqirMFD8VPkFwx2RD ZxEDm0GtTouexvy9KBrcDIInTkkIyWaFCoHtmYN4UMy+SSv2jO56YPTuFIji4jD/Jk/gw9A+rpxW 49Cty5+VVJ4EVXUloifAXlPNyxOEmMybyio2TSfKQe+4oJBBKsewc6vcVobcalJerE5AqJbXMiYv ZE7Xj8GgZX/oWucbE7ej21Sx4YrRZ9og5KJabnkMH+lGB6WkFRTSFHKHYrH54755bfXLFV9AkaxA eNQWp8DtaXMZTdYQNg3Ym5/JyyZRc8PhsN+RLZkviu2VShSe4mWTeo17DLIEEmCOYIaPR33FOZNf GuyvZ0SiasAaqfIam+BaYfuKr+Zo5p1In4943wF0L890SEpD0TBCwWNIynRU8E2XmD0DXC+0/9Eo JVgXl1s0qXfvAePrcYSe7MHUOxo9uaVIhf6EJxVYQ7KY4e0ueOi/haW1xUnkhFpTm6NmDQqpitEn hSbLPeIAmwHIs77JdFnnqLPLZh3dhaDU3S31PxNeynkI87xlslneaqTNLlvtE0PPZpUcnQCuHp50 eQH1taBj4UWFpiuqPyb+AK3QtcLOarRHWAfZ/LzTTU6cMeuknRR1lLyDtPBuaOLtFXjhLhthGY1A jF/10TGZqFh3Iq0UxM6o2v/welbkUd31PP2pQCXJbxeS+hJ3aJaiWg8KTSr/YVTs6WsCy4Lvk+h3 wKcO+8UVsoCpbsFsdOEiBpa8auOtiRKFvLHfyjFGL+sCby/xoww2D6cmXvwlh8xWwvKhmAOPYQ0R TUewK6euRJeE4hGfKZX5jXrYXJn6qXYY/nW/uNCDVxZfP1xklnXP+6br5UxhSQvc++IEfscW84qY yQ1BosLdUo+15SSncy5SXeN26poNx6wFrUtNDibFxrIqiX5B5HonenOW64/2oIOghlqtCJDZkJnv oTdr37XkxHgA0Cay89UfCwiCTDP8DGeKk/QHePoUeoEE5zCgTbKTgzxskHnonKl8O9WvSU5LldaX q68Bss50TPvYKuiNx2BjvlYXDCevH4ogOU5BTkCylZHb89B0mPblCpaN5YmtqSntm8rKIJwtcD+R QWAVtnKRPEC4Ai/oWEm/CVzYRiil4ChUlwhtO/tNfEVdf6c6jp5e90i86/uqmRATK1psqU9lK/XG xRfywhzpgFi1V6T4PdTCZcHLi8XfSJvK4VUk0NGYEvELq6phmIgspTR030yTaMsA+nC4G1WuvGHQ RhkDHcH3l1dD16YInXzk27c/XP56zRLQd/uHp/FV33D0hsXhGyiP75Onu6o6eYWfCrfo1fnlL/9C VfXH6y+fT/8fUEsDBBQAAAAIAHUBkCeZugh/vygAAFJ6AAAKAAAAcGFydDMuaHRtbLxbbXPbOJL+ zir9BxSnbmLXyUrs5Ob2Mo527cSZuC6JfY692btvEAlJXFOkliAta3799dMNgKDi5Jy5raRSiUSR QKNfnn66AR6/u/7wfjpK1PG7s5M3+KDU8fX59fuz6dvXlzfqw8nHm5P36ursrxP1bHKoDtTlydW1 en78VG6SBz6cXZ+od9fXlwdn/3Vz/tdX6ZVZl9uDtk5VVletqdpX6Wa5XRjzl1WxMpNu/aeJybs0 fvzjyYezV+lvZx/Prk6uL65S9fri4/XZx+tX6Wd+8olVK70oMjUvqoVprKortSysuiuqVi+MujXb Wa2bnAc9fuqWc3x68ea/6X/69JbGU5/O/+fs1cEhXXl7gPW9MbZYVOra6NXx6RUuP7Dq46d4FqO9 u5KxLqc/VzO7/jX6+O1/Ick0EuFfj6aXumnVc/XSjX789HT68Mi7HyHH4fQ3U5lGlyo3NmuKdVvU FVZQz1W7NIqX8bpujPrpGSnj8JFD+4/RF1ELrVyp06uzk//EF28t261WutmmJPzJ9MtnyCeuzt6G 2ybLdlX+FJ75JB/wqCzK374mxRzt3HzZmLui7qzCj2rvaP/hx17sPPbR3LfukRf9I6PkkSaLh34u Q8+zZ+n0OUXCyazuWqfrZ+TmjeHxeeWPGf6Pi2C7tWnWxdqURWVYGBLn2glCETH4Pf9RUl1cXLwW YY6CMNCKKlbr0qwIA6zSlTo+n0Jv5KZ1k5tmlGQ1fmf3fXo+VV7u46c30x+mUMjpwAMLeB4W0FlD Uqv+hh8l0t9muhFhXuwKkzW1tfTz94ny8DTmri476B5zHakz/1UFGHn2z5imq4rWYopes2f3JpOp bvDjj9Lr1cXlEQviQiblCwoC/jhva/RqRj6+EEEkXNJZ0aropx8qUlFlDYeoaUQmsVMarv9YcU7e vBExxPd1nj+13eyHirDqyrYgDiNy/BvLQUTDEPNQ/rcfKtD5mxuR5ZeBLHlxV+Tmh0ry/pMI8u8s yPta508/tQD6HylETejU9LAy+ZO6wBWWwUaJ/gEaE1jM8Kee1lCK59STHL8m/nl2NQV1u/lK0gd/ u2HydvzU3345TR61/OSdacxYbYyya6NvlebRs6VudEahWNi2yCzNplulG74pK+bEgNs6iLCXCo91 VC/dHye6ypW5MxXdU3eLJW7dkr/My85UmeEnF4E7EpkuBoCP0cbyzEpv1YzCb0Yj1hVRiVFSVHzX vGu7xkzIAYhu0N8NqV5GJtnzDYQ11YKyOFmEfl6YtiVMUyumAxUlmTuTT3r9Q19e+QPyImZ4lCrF QN8mQjfTCWydfF6SdnJm/hBLq1VBSXXd1Jmxtm7GVFoYr5B50dhW/aMzltVEo1IlQwYprGiy0VVX 6qZot/REgkt+QvXntNdQVbecuknZGSm+sLajsetGpW29VWFqmxItcqJFlte5XrcmT+ZNvVLmHo5B cvdPjdXMu+VhPxtGhjNQYll1tAiy5Z1paDbT0MwrXVHCKZxLJLJOGrKt2+3aTCYT9ZZEcWNm2sJR g5l37laboizxdaZnpTiNenv52wkthtxRnXw6f80SilzzriwPMpKI9Jkti/W4l4iEWem2RXnHzjIz mSbaw3O65cpcNFLCvlkahANIpGkhR7vsFYTB7URdRqPrcqO3Nkyiqy19F/WRb9ddk2CpmA+uytyv bWoaqzXZsqrLesH2W5Je6cN6oj4bRW6eQ924oyBPEbs1RmdLI15i9cokKcWvyVOR0Zb1hoIjjLpF ODzO0z9J9Jt/dNq75EvQah5evSKblgVV3dHY6r73vFy3eq1JgpIitF2Cc49hpngA/h8MnZy4JQe3 pE/yhXtVdasZSY3QCJetDGHrfmHxrxwSdUVeQYqGqQi11VxbiSD6avLOodKXMu5prhn0mmx/X5DR ijuTIBJXvPRx8A9OByj0SNFs2BjvCrs/UaS1qt7Ah/vgXRH4rXSZ1OR/okuC4owmdP7IK+JqheKm pEQHp2JJybFkufOyWB/My3pt1Z8ZWx5lQmBUbtb0PKlSN3VHUdoCsXu9ifPBrynmC4tQaDeG7pl3 VQZZdQnMQXzrlu7I6Nsk+SzyE2vTFA1Z0WQd5UNxyKW+M34yW9wr78sLutVCECdRA8KlTLFYtgcg pWJ0O0lea4mJVt9C1lpGtFzfsSBs1nTWFSVralbW2a1Ne3Ba1DWmzmUUkilhHf4iojhBxARPCLNo GiXV4T2sWC0szFfQZGVdMflxfmKpNOp0ST62IAdRs6Jpl4lDBTwMYKISlKDgM+aDR6i0LFZFy1ZP EfrkCzmnYl2SK/OP/nmvZ3hxUkExlKebg7Y+CF/Q5qrozppQ2xuKqQjD95oKtoIkIEjtGngqsG2s yLltTU6nbaL5brhzvQJm1EH4sYqum4L9HESIlktZ5ncAyp5WlIEWUEt9263JPkBF+AEhJEUH5Q0y qrnXGHAfBk4tsQvtH6fV60oiaENF+RhgEmXN8+k+ojtAYlUL4rV1wsGe15sqBmgan/4iKrXdVtmS 4BONmz8CdYiTyrTKzOcmayUlkwSzQkNHxDPIT+9blChk+zlyLuVjSO08ClYL6diiTWiD6zFFArjk uTAgr+QUq0oDtCACaLkuIWXbrGRQpyfZ6VyKJ4giS1ctq6RCmqKLMCGJQOLMtmpJrgKMipJRS7oB Q2N4oREQNI52BEiyas+tgH7dTxBKDUF/0bjUwug3p6kEnHwO6kNizgFPNmY2ZCnidRNRBxq+RjHR JHm3psThgJVcaU0+2dRlyRSJh6C7SqPvcMG02YRQ9TTKz06/zFSXdUM3j8VpElxi7e3aolfjmI3y BFRyK6QD/FpcmGILoNEgy+6SuklyitTNkM5ZBjlLgym3XpW01r/jK9bQ1jnSvSXjg/9GamCahdDf HT+mqaOep6Ld9f309FutsWSnNaa+0RkD+hKrdlqNXIoZogavW5TmgGlm4h/s2ejHi2vcFDkEgrZr D+r5gcxNshjfoeHZ9+gOWjNVAESIuswxDxqewIF4zsoElE+ZrTpkRX7zKSIoVaFiYTIZDyc24DHZ X1mQyfclVUqOuYZCybiUAy2HNaWOXIAjW9ZFFrKP0FEikwMh6DGEDZIclpOAuyliHIFnkkm8KudU pwXcWDmLkuuDWrtSScqzCEwKmwxdbOySiwubWBrhujOYuBK4BpK47DeQmvJitkw2dVfmjtkZB8rB +G/7JEBJZY5ct4GgWBYNPmtAGeJH3EAkGuWnX14wGfBoyaFdeVEitCoL0hu6Epbvcr0Shytws5Uh RVFCzRB5QgAyMGXKwJ7czxtjfhdZNss68hz1K3Z9GB85XQEWxt69GrMg6mQ4MfvPyYqw1WJavolI KDgmAxqZamXyAou+02XH5tVhkKD5VZf1bB1wRSZnYE2QFQggxBMcVOVcOXJeMbqh+T6cX36KEqMv gnDLDtL0d00e30B4b4CZyPvEAlkxA68QL5dkLUgq7gufm7dGyrvcuOTBoKxeJgi548urs2kyIN4+ 971U+HOo4j9Hg2/PB99eJAf/1D8JbIhIW0n9sHjpJpLrVDy3Cci6YKG4G99CkZ3DgRukZ/rzc9n+ Km7ITPIl5bsc1cMK5pgOxpOPNF0/3GC0nymsfuVRdkedJkJFQoiItPw0X6tyCNOXIH5eGpdiJ0Fr YUlFDQ8xcUv96tOH0Wdvk3g4xQEBpQ10x+NZ4rEEjkNNUv57Cld4NGVzFQinUvL0InPlsO1YJ/Cj gYtSolnpLaeYGX6iIsTQP1U75kCB87qqK3FLCGndZAY3DsabqPcoQogS6uY2AH2LdhbF5hPBe4kI X5f7lhXX8lw91QL2Fv8T+cjKzrKsLx/OGD7AxCMIy1l9iYcShh9EXkc6xZhcy4wfHstHqA9nzj5c kHOaSFimwROuS8c45eCYcYoRkujdPIZ9iOhaXgLDVKKxswgQ6wiKx0JfG1lbSOI73rwfd0DIlnfk r1x+WGSrpOcsZF9pZ5WEpTYwsCFc1ZLrmM7QiDQerZmfRZ/SLp1W+pw8UReV8Z0FU0nWkVwv7QXP HYeJjWhkOq9Lgu90zPUQTXhLXxLOXkW1Q456ZFanTHJA+MlyPLhtrTRkKWnFXs5JfS2VeiLlKzmQ N4AP3rEf3Dn5KjiQ7zWI1wsPOlBXpu9CBAAIHT9X6Lq2ngY/tK0TrXdH+HiUFCASGrtIXQzxk6BA LoOFdDyQW6iiNiWlVy/ba/ZxSAdq1IFF9dlNKogQ3YERcVPbcRupmH2fj3MTIagf/vMXSnFNEvAS Kc5cvR/Gdk4W0RMX3xxjSRxj4k0nvRYiSN7zrZL+0qCiZq7w1VHhbVq1m9qNu9dD+n40ouvRoH9g Kk+D867x6NfjnRjp8cRY+rgwp0AjaPHYqdGxHWtkbhKBKjz4DIkrWWCGbeeJOq+4CSyKBsAkuIWZ kw3tZTyBPtauCmS2FBFn23TAcPfAkwrD/UAseT+BHOumqNFT/y76Tyu8BdWnBNEzLq6zMCQk0Pmd ltNCrG3AZewckiH6pgYIG3pYScREm3rR6BX4c++HkvhRvfiUhZgx89p1y3sjIzAYyUAcyS5JQOaA yJxF2E3ZhyNunJsSveuZh6ANi3trzFr1lDhUbYlEE8V4zs2bolF/r2cxpjpSwz+5hbidpdgvvoON XqAP0TWW7U0CEhpYyaJrsKSuMZ6+I1iK0vSEOLgVRxYvJXlwowM4kpGqCV9804MdV/r6a13krqnf 7y89Uvpr4E0xn1NZCvT0bTwqeqNKnOfHpaDnQDKGV6nqY7RJZKtn4AZWDep8DOkyKEcotwIzNPhy lUZT4zr2h5K0oQtuwzWVySkQi5z7pzszFaE3x34rRbXrWYGj+WYSBq0oXvM0yhSCSRS2PEZrUNxq 9lGB397Ht+z+XoqcrYh2b+JSx84yCGkJMukH8vB0bjS2E23qqyh9Vxd5n3aippYcdptxgyBhH8vr rEPBDy2OaWzO4ENTxM0u/vkS1dzla1b85S8MEXZf1GT0bRL3U1xq3UmEIDeeh+6sjMqxt+dvL7hf wqB3ZS6gc3LU5LSDdxHluLo43WfXd+P1+yoh8tBGsMM90n6Huj+P9P0tqG8ebrqZ7rQqZLVYITmm 41nY/CqdS8c9o4rN2OtFdoiFntFoG+JYlsJBNiEdnXypsE3WL5tjWc1LvRDnKyznpo1vZzicQsXd NWi48nYjlOsYtmun4N4veksMoMwz2gJbiDKPm2LuDNZ7P8kMFXH3fMjtXQDx1iHNUWTYK1gycGwx nqkAdvIATdPjv9CPal7SI45yu867S5m917pqHNrCpr/rn8zD40x+uN+g29D6TLiZ+31NM7I19GBD AqOclEGvHCvsw7qlRZK/mhRky8bbstvwWE4wws9J9YsNDx/9dG/j+4Nb2TZixwI/yLcEO1RSzAxd L7CXwntablBL9+aKDYBtMRwbwNpOYwEkbdcZeQQpiPlHNELYVYQZo9AeiykPuBFyICWbLdpO9/7C jy9NdhtFfggW8W3fe+pKdnymC76/FLEcV7dwq8V1v0EhAt2KDhxgw0btSYXfeEa130eIQyTcsEU0 if+R2k1FS8tALAZ52FDN4B59Jm1CDMFFb+GKu2d+Q5TdyNxnhusWPkmS10Ym5KUht3It85192V5t so2g4b8b2Ywj//q0qikKekFPdXbbrVOiRBmBTWFXUt4xgwiBlvgMzXahwbIlc2Vtb4fAGZ/twbnK 78fMb5zBZMTs5QiNR0CKB6I+qIWT+fB56Sqb87AjTc5QREjLRWoqmcn3cftnKK/h8BfkSeFAc95v LMs+g5PXrrUFZXS5XDZmpHojstEyYBEldEsALUz6Gi3y4Gha2bG3/2fieiTt8qFMY0D+pi6d23od cyolGf/G+kYvAO1cLGRf6r+MZOXdHJzzdlFE9EtEvl7ulDmF2yjytYoHd78ZJ6zC3KFzJeFyVzTS 8u01Xjj07mkrhpKlQ0euy/GQ8WUXYUVfMu1OrPgzZSCB2LcWYg7vYcn6jIStWtLEjnlZKas6lxM6 Vcz+JOs5e+4nReQ0mLBHgTDkk99NUz8JruuZHgbyUAj94y6WnctAvysAI3yn+WEfWBYbuQbNjHbH YE/sTvKVKcY4H4B4f6FSSpEM8akUq2rPGtOfGvxpXiwIOI7SqXxQR4j/feEJzD7myDqIEdAKbORn rQBjBMtFReyCW3BkLXxkKfArDzG0skBbSj5a/F5jMyoNZXQrtNslIlcebYqcNMmZSU7K7c22LczJ 2/Gmzfb/WECJLktu35eyBR2FrNPjINYcvpU1RxIB7lxn7IpJdDZlIjDgdqG175fM+X0cPg1QU14T n+bSeM6HglyAIQikmJb9JTmxiHsXNXosc44ljE7lBGBo51QMaEm57ZtX5JZy9CQ6DkSZuIZv9oeX KCFKkaDg8G5qy0m84Spm7HkLt0cDjmMf0PbdGyu7CpBW9gRjb3WqDU0cSfc5kbi+q+RoZjLAJOYr jgh6HoqgkH4jBzV6jexiuw30QYiPkz5oBfH9PpaHu+EuF4p0uhtadpU5x6IU2eH8iGtDJYJR9+1w KXIp6palO/iU7v+BWrwIe2ryMg83CP3x0xrwCkPljeb/X8oZUncAtz/JywF/6E7znn/4TX26ev0q fftssijmqfp8/ub63av/ePYvfGQ5UcNXxPjVtBsPGody0JeJQOgjo53DbeRwiMsbDq+g8WtdSTgW PDhJEFGS8A7GNJw3vsGR46+9kAFBcNr4ZnDi+LGvZ7wpbNZZbpPLFmAeLozDDNwv41NeVB4u9dr1 y1YcCwV3KKgcn4wC1sgBDI3jNzmlSpxhrhZGIDYqFppQUIezGneF2UQnNaRQHyXi4F1j3BkSKRo4 qnxX19m+ZzYbB9S0KmSiulkQd/ydnXKU+Kp0Wawno6+6ytEXrnLIriIO8i3/OIr8Q07Hys4/HxWk ha1rq0vsprmX/WLLPdZ2MrabzjFGmcvHQVCF/OjPebMNbeRD41EScIyPb5CWsnF0tlD69f54igQ2 15Y8Cow2UScOYrjDO0oCeuRFLqUTQy5QQs78qoxLCAEP35eKzqYY1wIdJcuCxG6yJQ6Nir/IkWhX Urt9F8OtXrNat1uVyrsAMkzU+nHDQzpOPhvuFfK2SL/Xy4MGqdl1eT9tMnyD4BsQ8/xLvzk4+n6Q ee6c6MQd7KGCukAVx0Y+wJllWqxzrOi9z4fQ5o861nPnPj6cHGnlrbss7Mu4XrWcN0HHjoxF1Ay8 aTJyTQU+CNYi/dCzSMfurB4xxd4XOTyE6TKdkOYQN+aRp+0IfNhWOI0GRwKbeDoorEWm0BSJ/Sg6 gWnucQaFW3jiCOSvkScx13GwIg13hvcZ9+sstoUyyoA4xeh6lfHOcjgEkM7ROLbpKNmTOGz9BsAM Oyf+Nswr50vjNqIclnWK5iKWERWJjrkoyctL3ZdTUryrGZuC1yoIfv3+1PcvNujQ8a2+u4DbxEQS rLhHOM4DQcogYMMmqsllL4vvw0gyXwi3URJnxgYvl6Ad8UYO1+BWsmvNeTskHfvgTpQcth1xcRHY f78nFTFXKtcaVyfhqgR4hg4GSYsKt2G430m9LkhGO2H8wr/IHMfx8z4DjHbDdzSM3xchfkWsLyN1 FEJ19P+P1RcR1Lt2KHpLbRdDPUwm6dnvj1euhuMbDp0zDEKmT7YL3S7Z8HICWIJSvDRvCtfHiz0b ETpK4AN21/c41uUUuj9673g4R610Eu12tTJoaUnBXVsuLPnlIydCi16lH/KLYHWnT0p/3IkPMLjd bdeswxqRELAGAljuoJDkyIN5V5oBwknQGYcrss+HoIggKISbNTiX3ULUkFwHav2ibYqORViLjx1h TWRZh63rkkqwXI0SikwbIimc2uJ60x+X5GMrlCg5gdNV3pBR7oRvdOC8P5L+QIpzIcEyf8FJv/oG 78O09PE71EZL4ZYTDpf12u/pKD6DMSvwtsMYy8MmFTCIaKNsZTsgOD6ffvFO8fk02Tu7cZjJ7ez3 Z79dqBm5V8DaHJtvG3dARzv2k+m1zIlU5TTenwJJ3vvOuNSxWe146tZVY46ruDM1/ftOq3C4wb1x wOe5XZ0T2JZ/ks9kNv/b2rX2tm0l0e8E8h+4+hIJKyumuwkCo2nhrFs0QOJsbQfbxaIL0DZls5VF Q6SS6N/vnDMz917KUmo5QYHGepC8z7nzOOcILRhquTlJncsjZcvdNXOuAffb2lHWABiq5KvLajYj +AicF5xusi/qqkcMmpb4SnQF/1xNJjukGsBf9C5bXY6L3jb3vEJfUTCUSci7QEKhZUkOFa3HEJs9 yY5a7SpQWGPbOOTkaOJK24k14J22ot6hbJl6yuzJrJqytNboQYSPMyft4nPk8uUsach0cUiJBe8y 2fLEajYdRZPXIiV7U17UTlpiJswwt9x/zJKTWqTWge7TbTlfedaAE/oJ2URLg8hiG/e27Z2sSTwv Yzq27ZjVa+5YMHBrjZWFAUsABXPNP1Fm5XMnZmo95dESsE9UBdP4lUZ1lfozPgsG+1cYTbmoYhIj sH0iUyu7z9SyPcKZX95G8/LYtFW9CLX4zhLVshF0p2MxcR2F/tyVTEyKlWPOLkM6fA/p8D2mw4/e fgjgPs2+YayxOjh5mn6q507Atfwdubgl8TfapqyVMxZhvpvdNq0DgsVbWaCMVgYmLMuT0Sh4AjaD 1VnOxTPVdGOSteU90vyLBUvpqQNkRv5vL4uGh9UtoFw8MsYaZKupTDK0KdnKN5U8BYCKTW1ocYRm G/F6Nal5AdzdNtOOQMrN5wmUFpRHvUF8wWnURzuwp53NQHs4K2XFYUkOtH/ERiBRCRjK4g4nZ+3J dyIxZTcDKY5NHbs9ycxZhdWhu0BiHUlY2BEJOmwa6ifmJZe3jZkSJCMrA3Lskgs/CQTFZCKYwKs7 87Kr/EcjsYkBY0669QwJpv/gf/Lfq+JF5hswudNY7bzWNF7y65rHYQd0Bazn0c6PXr/9iQfJnZrK V9/psSI7Dq/2JbCDAXuFSPb7cznyz4+Dy3CUH2ZQk4rv7G99UfRewEk+P91wy9dfvmWx/ZN7t4Tn 3r/Tfv9l0XtZ9D8tinvX/+zn0f0HPWwM+i/ssn++/enoFBUNgrP2R0BMIDU+wcvb5iOSvcD1Xu9/ m+cWdtlRfnRynL9+9E37U9G76bNvdNfY1OEVweao/452uff29eItfubjMBRrUAMMLMMeuiHnxcfq Gz3Re/P62/Rmy/j/9v50t0ndftM4/A+45xdGenNDT3jTIZhq/9Un/P5Xg/HAZ3i7ceuhjcjjb71x nHFrnUfLNT5wOh/4mN7IP/NR8qW62zj99RbAzY++tjN/ve6f2TrqbzR28PdHP2nLLjixPW2r62uH bePknP10ji4U+XCv8FvL/3GgrknFPFT24bayeMCKfsbXBVxI6Xw1qCpXCTGAQAMEtR/FiRmNjROS ObZpAK7jID/YCxektOPoVRTyBToJ+/gjfmcUBAf8yQED9o8YnhExZh6stt/0NthmAl8XTXObaa2o Y6LC08lLnm6mytBSbiAdBgnklizYDiSOuarmLeCr/IgtkzAOxN+Xm3s4lrkp/IO0fimrYsTuFuww P080IoY2s0gyiT8IcYlzT8hI29HS7kZCK6JYNXAqEePGaFiZVpEgNPkKr2vdQ9KhSd/BJOfrb7qz Yuty7Sb7+/trLwvdONwp264p1l7ux2uebbuo6D+o8ItolTdfUxTF2jXWuC9c0u9PYf2zU2bbNcXa NfaY3750Ub8/RbEf27ZtDNb6U4QxOElHe6PleKDhsK0G5RUHnusGCltLs5IIkFxRh9CJmVOCPQ9R VzNwhTqnCZSzNHHGVRZiZyNSOxvZ8yz3cgc7goXiNgpB7zQQ7PQhKMu79UEhgjlsiXs/ATS0kqC6 +1TNu1U+/HGUwloAyiGZ6LAXt2qy/fmaJFioECCGTWrEawWCWBt4brWB46or65knfXG1IuLvlYaz ncbFTHXQYNKwXyElCqDnmPPhjIOtBKM5j3FE5yLah/5IkiWMiMChJZcH3aKqBt6JaBsvlggzE27U pBel031oZcgpLiPfUwkPTXveQwGso98T+LvLJHo+4Qsaio/LLMho1reWMbCSBXJKGvuHRCPvj0xJ hk0kHpKNt7L9SojZzGaT/AjHDlIQV54nC9POzAKyh1lSe8Y3lJPeA5+x+qD4a81S6dd1aL1S4kCH C0tPBXRTaDSrrQ12LF4sAuqXE4ZqRKaPBBwP+SrNnliZolbEGkr+beCotDfL6TQdce4iGgvWfEtu xcwKJwDrIddow4N/LywLB9Sb2I2PciZ6S/ERkine2KSdTJUoCyTJf+W3lakaGMZuN/ui9whUSiRX CBw4tGKe46mCIkJYruxfmWSiLsrFoprpwCvWqszfg0t4MJyPRjb9jsjOpmUNwYBekSeUUxOZOVSj 41wuFuUqG5aB+JYg3vjZKDQ42s1OtUPkn/fDAoKBne07QF7lHgpqTewiOhYMy9qnOaj24+wiqLDQ IGBFtQ5d6mtNsO15cfBynB88f4Ek/PPiIHMnEQm2Yn8vuX8YA6U9ZsdKibwz7bkaVOrkFLtbVHvt ai6t6AgZCysjssJ2SS8amhPLNIFtinl/dxz1GBOvmaUIfgrsJnAH6Igt/tv6cw3o/P3T5cW208Ws WbV4yBHzwo6Y97KBUlzVWTCJ7M/GkyYY2sTOJrKwbmg3C8P2bezDR7du/UD2w8FxFro5elwkhiw9 VSOkuucAzc5It1M/3GRftGRSA8p9ZVGSVkrbQD3KAs6Vfou42qoUsrxoO2UoNKjG1nOqIbXpuRaP tdSvB8NJ8U6UlYIAkvFE2woBigdmikGvxqhoz4hwdiB2boYQrhpMKBLJpOuVimzAvRTxVV9V5Y6e E5QHGh5BYfrInp6j7Vb+smF2JrV8F6IY8kC06jD7T7NEQVaDObtEPlvQGIUy4tuz1xg2wrLl/YqY ngviBlHoWzXLbFrTWBbgmldyGMh7uUR7xt0vtJSzHxWLOIikE5PkQQK/yvq4dKU8FEWRAaT+xjas 1+EvnuE4SppmWzUlezM3yYeyhWusi4Vtx2EMxzhwyxb4OYJ5E60LJLxuJM6zhXEbUMM9cYqdnHaV KwzxtU5YeIfmSGJOm8dDvK/V4caGPmNhkEdrl3gR1oPcYOwJLshpoVdXid3MZPwgJqYP9DHPBxhu sceAV8iQE0Hf1+FI6m0ZiuzK09fDvVr02kRfoEvu/k5uLjMlU1l/fuwI+gqQUICaezJE+hYHwYWJ qs+xLZUdoWxWsHzj7JNxppBNKecJMZU/HcECUuqm0XOb5G+CH6bfg+5T1VmdsEunQHq+N5z/vRh5 zoWegt33j+X1NS13RyI3KRc6vwC76LErnfoDDPxS/PI1V38wSkUPzeXgzDhhki0pL3haJ25nmR+0 e2oGuMB6ZkImhvJ5j5yaE2ILYdJ8zRIwmExJ+5A1+zSZpacyTbrgZJBWVSCUwxHHMnLl4+QSHWY1 I2pCLkCnto4iwAn3tDNIpuD7Nz8YqkglTWSHuz4mTx+Y5XjGgNY/VM8cdQIzmGDtXVOh0yWlDPq/ gREIt0h2A22gEmHr2QYEiPpPHo7xZtGg2zZVuln+/esf9oHUyflngT/HeeF/yruFfwNQkAez/GB0 uQiRuUErQoHSB2gc97cO9zu12GpUkevobgJ3geuc+I3kFmFTJSxg7ZvJkXGRx467aleVaIYp24Ts Llii0oyeGmyKnq7ZsbNOHWgkJtfyJTQZGP3UmMDF1bzjPfaQqWUc+l0CmkdG/Laec/zROrwsP+Nl Tx+vFzLhMtDKP9K1odspa/NpTSZeIdMo/xxo3/HGK7x8qogocvMX5Z1EHi3dm8tGfFVZ9kAEXM7q O3Wq4QoB7MoHRM2SVpbFKJh3diHRBKnmjiXoy9MFE2TOlwkUajxNx+xvOTPcOEx55tptzAVETLoK 3p9piAO9EmANF+JZUXB5yHAlUZo0FJR+AVIaEiOIT6jzi87skGn5WfUVJSgGB6k0T1ERdphsuN26 0D3fpWsde1f2KLY+OdsGDRsk1mYwdsRRkAbu7GTGYo6Ro1IPLatl4zmYI5+XCI5brQb0/pummV1A Ik6lrRvDokyyI1O/5upxjJGHqwwfZXmQILRUqtOiCuGkyXqosG7Gw1sjwD6u/2lrbGf2aSdw2Rvb z5YmiZAfmHeDnBrgzHWPPN5B/EXpoC3QxqPjYw9o7v/ExGMSRh+MNnYpo7bagx5feWP6cIwCXEPW aUKRTtZFUcmQU8iCJm0ajuD1YWDaJIkExxSq/jbmhRtSGvBxlQUKdatnzdohOPZckkL53Sco85cu 94hxWZOHOo9ZJQ118WC9gDmqQAugIPSwCJQPiWYA7Z5mB6MgL996yKYud7gW8K/60kRpYG8Zg4hX mikucnUv1K9cS/Wiz4B0TbI93VcwD2h2lupV2Dpbgy7FFePwQV82X/hFkMesn1/4QxAMcFS6jtlD 35JcRTbsNJAcdUD3kEqVHlvqqd9RmqFqzxWRg0UcajoXC9Y4f0o/vZdrHJHn6Ru+Nx/TIKnqiSeD IWfrkxJArOtD6yP75viDD+rWnzZ5zJCelSq9hT65CilG8YSihJ7XU91hGTt7mnj2pDYb+k7WETyC snPpBpI+o3ABvjsgvUsc8pXqaISzsVvU1+hIiXTZXaiLQBCoNjZlj2G/eXzenvnwbPzBla8BzpUm xaISbHo8+N6R4FaVTnsFnrqN8nwTJhUcBFdH7ULugz/nIAKXmkqgz0odsBA/e1BvpttXn+Hlkd2r dFjc57v3Ce7gQisA++K2iblTrOjbZ2cfgj++Ylh1bawBJQz4SewM6CwmjnVviGv0DNsFBWj6dWzU SSJtSayg8xUZ50UEw9ok59Oqu8SxbfmtZefPj2jXNNf7cP/boaA6svMmT4TD4PxoZ7F1Z8v2RgeH xtpWeqjcgwwMFDmr1iGl49cHkQQObeSNdzdkZs6DhNitWB2jwr6xU+eqskU27jXUVxCsnfPKwPJp rQYfycb6aYaW9YleHFUDtnYLw+wHYTRnhpC25GTqrr5eItHoBA+CIuLa3k3exJphg4QRHXD4BxZR RJqK4ioSEr6+CRFPsd4r8UXfdHmiD5GopEAggcRWe5qWg5Ztby4vY2tsq2VxJtQ5TPU7fOw/aZxw iTRWSOXFFVSZ8JoiYqe1Xp31Hqd029bqgDFxGwRkUtWLsNpC7+wuh1nywsZziE1MrY+lldBaaYXm BxICEFOG7S1qUjIHN8u5czwyW+K95alPIC8GEgdbMMvxZ6bcCPd+aOpReW/ILTVafdOwweLjNUy7 1WcR2/pofqocIHPjUBhmODImnkNa047PhhPP8ANx61PEjVdX+c//SmsiPSpTa4Q5NvKyjB7UbUn2 pukCtcEniEWhci5O/lWcTroy7hsEo5zZebzp3GT0I+agWiwal99e4FexdO2vM3qpKfHwX5KATOxA lkp5N3BxHcPn3ITfUNgyLXWCM+Keaa41Gq4vM9vH4HdO8tMKSjSqc6ZKsBSCBNVHpUrK/LsDesnJ LdS504EDiwbWV3+AB5NzVVcA4F+yjZNcAjbL7qRwpF9Pz8UR//U0qK1L2KbuDKJbM/BZsG3oTZBW DEthqIWYdgaDxTLfFTZ6ZAq+O3ttSCexnqzQNvMgwWSLzsitzXUYvFgutXiVUUmgCpDoyrwGKb/k qARBZm1l+/BJ5hmYrm97+iUTCx9LOZSZxFdehIV8LMyl/nto9JMspWSVne6ldBawL5Q7X6bisEOF w2F8XQlf67BPMmMlLgPJq8xPqk9dM987Le9uULhKNNfxanbdcKVgGQWChRNMn2SxPpnyowYtf2mK Vjxq/Jy+f6f4nnayRvp7Yr9s3C8sxp/bQ6FhkhcvsHT015gDiRU0Vv7GsvzL35L+P1BLAwQUAAAA CAC4HZAn+gemmHMbAACoRwAACgAAAHBhcnQ0Lmh0bWysW2Fz2ziS/c6q+Q84bdWNXScrk0l26iqX 8Z7jyBPfJrbXdnb29hskQRLPFKkhSGu0v/7e6wZAUk62nKurmklsiQTQjdevXzeQtx/uP308/S4z bz9Mz97zB2Pe3l/ef5yeXpzffDafzq4+n300t9O/TswPk5fmxNyc3d6b129f6EP6wqfp/Zn5cH9/ czL9y+fLv/48unXbYn/SVCMzr8rGlc3Po916v3LuPzf5xk3a7b9P3KId9V+/Ovs0/Xn0y/Rqent2 f307MufXV/fTq/ufR7/Km997s7GrfG6WeblytTdVada5N4952diVMw9uP6tsvZBB374I5rx9d/3+ v/E3frrAeObu8u/Tn09e4pOLE9r33vl8VZp7Zzdv393y4y9Y/fYF3+VoH251rJvTfy1nfvsfvR// +Z9cyWlvCf/24+mNrRvz2rwJo7998e70yyMf/sh1vDw9Wzzacu4Wpqm2+dzD4pfPfD/+2PtFbYd5 xry7nZ79mb/ELfHtZmPr/QgrPDt9+g42/nZ6kR6brJtN8Yf0zp3+wFd15fHxLax/dfDwTe0e86r1 hl+ao1fHX37tjwevXbnfm/DKH7tXvsueuS/9oV/r0MuqdruqXrwenb4G6C/CrzK2WP1/H7qs3O9z t23yquTgP5r7tTPpI///McXd7TsO/UqGvttUVbM2t26V+8bVZmbnD+3WbNx8bcvcb3r++gIaEhiG X3XoSJ6K6DhHyE5vT4n2zwPnEeifBeVvX8SHbk6fZWZ2Zny7dfU237oiL4F5BukcA5tF5bwpqwZs UOxNvtkWOT5oYHjrnamW5tHWuZ0VzhSuXDXrLI7hJ+au2jgDN9R2Ds/APQgjvsK3L85/MLZc6M/C FHlpVq50tS3MLi8KM8PkuZ+33rtFtna1G/PhvbFYVVrQaOls09bOj8ysbcxC2Wa7zovKV/hL1mob ealwdmFme5lyvq7yufNZ+jJNxXXwiWVe+4D6sORFNW83oNpJt1nwb5a2qoe8r2zWIRi/vGXfZc/d tG1dwQhf1VyiLffmIYdLj84v787H5hZ/GnzFz4FQQNPW83XeuDkddhyc3cAJ1ry9PC2q5u2Ly1OO 1C1wDG9g6+p22+DnprZbL7vm98D6xsxtUXhzpJsjiQhE4Xd5M1/D8XBrxo2i77YVBjqemKmdr02E iPGSWOa2TIsx3j0KBDBpVYfN4wDXd2bT+iZDUC0KzLZb5xipdr+1ee16z9ktEDq3XL28YEb4usEu juRrmrCVTfZN3c75WAYfce152eL1JWM4PjnBfiEDdqgPk+zWFQAfDZZpgFZvH91iLDjU1f2Jwfy8 vTzHWHVViC9mMnnpl3Ars0+wfwzPd9th1BG17LAsNn1CRJf7BjpgnOnPwdEBx9H9E3Nm5oX1Hjlf wJL2ZV5ttohXmHzE3U5IOc4AFDASEGLhEyeAefN8K0/M5YW57Fxvlg5QMW8QZlje0rZF802DvR8M tnDzauEwWl4+2iIfbLKCd/gJTHzMC7cawmHyLSuY/g3/uXnbcNoFhsP8YJh/uLoamwpIXhbVbixb cDmdTs3FDTQWsoWgezL5prk+TT/x/6oGBc4Z9gO/0ZyKsU1PyPDPH/sqsqlfV22hnNxRS1Pnq1UI CqSEGnMkqB3N3NwyEQzDNiOMq/m8rSObestUsJ8XIB4GSB7Cxha+wlzOu/rREcvLovXrwVyCXZ89 BS95KIdCk1xCyBaucSE5VVsiVjj2+vp6zPkQyE1VZfrg74yrRYVM08BmrMMUlRD9rF0uKX5pz35H ZjPWm51DQsLfklOYxxANyCVV9fDg3BZ6eZxpyO+Ezr7HgMslczKDpZqp6Kqd9VjQxPyKBOY0tPk6 7Z8j2jrezQCYnd2PU4a0s7zImz3f8JCjA0+EeDcM+GQP0h9WlS1sY5W2drKzgS9hB7eD0YIRwTe1 c78LjBcTyWnPgg1zmSc3OtlIEFMJlz86pSy4GxiCMNjQ84t83qjP9mZVVdg5V3oGzcY+wAJ4t+ln xkzBY4lLWFrYOSh/5iiGQjphzZPjvb3Cn9P2ghj7V0Yi7/xULrLoALtY5HwQkIU+WeyQqwLZb5xl YmZKvLo2l1d397efz+8vr6/M5R3+u/s8fS8sdm/Oz67M/e3lL79MbzP8OP3b+fSGD2oarZk7Q+Kl PEP+xJBnHz92D96ZT5/v7s27qTn/MD3/MwY+uzfvp+fX76fm/vLTNDu7M/fX5gZlEsSBuf8ABri4 vf5krs/PP99eXv2C5fFTjDg9/yxrvLm8mX68vJpyDd/ALtxK3RYymIQaXKEiSQInZL5afisrMxI6 9VVbz90I8AniFyESAv7T5c1dBlkHuJ9hd3uah2oLpLFaNyakUyEH2WQBfJBjdjPLV22+zIEafgwf MiFmko3n0DHFniSgHsaHVd3YslEzkJo9dtqVX1k+xAueR3ET4p0aAEKhxEIWyRpoSthDjdOpwptq 5+qb84kIuW0opwBCCM95nc/wIOimy6RZruKZtQDzDEOVTBLCGq+QSwrDON0yMSS57WVdZllXmz5Y Az19Y5Sqj7i3UThhXXZGolCmZeRYaAsKPt/TwnTZxHyqEOCRxYp8kzdKrRBjj5ECDERlaeuqLRde vRMEdMcBb0TdgCEXjonqadR7+kezeCZsRj+tqx2E1LPNhc6+kIklL1FeD9IkZ8ifCBBOptEi7465 yFhm2JmvipZow54I/ZBNndYoyBJJd9CUknoQGYbcO9Aamqj4CATXcAmU7rpC8MOcNC0EAla25n/a zXYcRHwGR+eFrQdiBTUWdnQ/SNISmiXdpuWG9fve7kR2zno70zCg7Uolcn9twH+iVzLazDUIjDFC RMMVaZUZx9jsUF6ZowOFXlCxRK495sKBteXhjBSYuRcHxIw01lkIFpHkd4I3ApV5Ft89X2Z/l10v sT1t7Z1MbvvIoB/Uiy6ViX2DEO2KlrbMm6gorPANfIkSl1xJVZFTtgAu6QVFBuUUGUfAEnKZDkIx gMxr/ksKCXkR6FUx+i3AvwMQscF95H9RCn9F+AY5+ivgNBPGGCecy+5GbYFsVoN637utKxdAOhuF grv9VnMHHu5etdpGy564s5JahuBGmI1N31V0R5InAQeGTichzEDPpegW6bREYZhYWxHJj1LvRjs2 +GPYlkksPseE5SAqfbaoCK+o0xCNokzxm1ByX1gwLFQF81POIoaDBjaACqViWlLm2VSRNmpnwcHy YZxN4leSHhTj2pVDMRNbJKOS/Q8KoVH2ZIUVJF+vIP7eD0wcP/GbDil1bMxRWYr/fmUtj4bCGozG fUxKGlIU6tNzY6Os/GYkQ4nVQyBL2SRrUZTei26g6co21Nmh3jruMgrqVyxPxMixCblY6IN9HIYc h9HKrKgwEmj7hrgcaklJc9aMpHTIieYR0GBXmgsoyP0Ttsi9b13WQqQWwc0+kMzI26UbjTUp7/IA m/C9ONaLWZr+pIESyF1UPjlQrB+x3vScK1ScchagSoHzgPdzUSZMtqo9QqbSbgA3TKLy79Pba+Ye JARUTc1e00/e9b1Y1zLOI1QmKLvlGxFu0mgIhU8WUnu+fGIUgMVFilHiHPFo4Ww96qo1cSHbdP2p XZa+/zYUXYDpgZovK4Fx4kbIq5rJqYeuX7UrRWGE+WuTOj8bt2EBrsVNcCzzpA68qm3ZIkWzVJvB /Qgxr+2bbt4sEGrY0n7ZPl+7+QMd3U8RwKU4P44yMe+k0Skv4fN+DqPcZN0aNdkbbougF2Qjo8sw 0eBElPBDixTNhpaV9m+eTGrY251kl8vBm0mmCk/5bRV1BR55tFApbAjzfd8lym6Z31CYXLF9IqYP 1IratBYoNxClRzK49BHKJqQU86djYh7AjgINQJW6KPvoGnAhqW4DAuv4O+yutle0gwmVuqH8Xdti GVEZlcmQJf4l8VK/Ftb1cnBrooBLSSj6TCJwFONvxOCTRrmzoqACQTPsU4GqMpRpwer2caYdkNe4 Mg6byjLviF7Iv5Xu999mth5n0gRg2ZSa8vx8kLcSOOKQPUyQBFidS1eHPm921VgIRboOuTQ8Fntp gfDTy/dKPNxPNlWJCb+FJwv1VMSnDVIMVm6xAdjPpnqiHmhRv50dKIlxKS1lHavHTNpp0s+xoqyP 5prF2ZiRky/3kbuSUxELH19iCLyrAgQP7AXYIFvxEp4QsZvNbPkQ8Y4HBwJQBjCqF/BhVFvPbPWX qf6KgcBsu1qn6jY1njys0JpUjQX+oQ6E03uhzjzJbHeIih506OOJSb3BuGlSExU7u/dE9bItYj9P HYxIaDcO1QUL5Yn5IEcDNlTpo8GuouAAP9q9slsg2ITZXMZfsASxUSyOs9AfF5LT6aWdphsMm0yv O63rtlCWu57KIXtU0uSk6+xK4wC/YRVF/uDMy5/M0U+vX7xmdwPFbGjbEfLHQRTlXtO/9tRII0Cj xCoRl9khj0iygDKpajYXAudKdMRsSs7ggL4bkcZok1HrK/Px9nPW8UbrlfpfS55eVDvmqrYMo5EJ 2D3cRdWI0IOarFZl/g+yWlwf4/MFOcMNi9W8UeyoqolCXUwO+IfBY7bwFvqI9b6a51YpkYaG1quC Kfv44k6KJnM0+Fa8/SZFD6NMAqhHIVL7pge0+aHhc8yWTd6EM6kQsx07IW1WlNa1Y+VLGEHKr5Ro JARSShuYF/At5gXHbZkZvODKfmECOQ1zzcBVGceamF6tKaZaLaRSAMiWyzx53dGNzC8KfNHWKgbk mCnrztVEQRE/4VwG1rVNRbfOpSMqjWqt3pt4YspYSrrNzry0xqpl5n7XbloAYGhzHZYJka8xm3aS JL4AMm4x6uU2NDf6rsmox9eAWK+NHQg3RLGADKt/N724vp0eFMMMigSc3Ifz51LOk+UsK1M4RG3U tbrJbcTeC6mDYixKYUz/hQiRPgxkFNRKVII84hLALmq7k8JWIfKlOxXLfIW082p0qj+YVywojR4Y HEBxx/1ooOUW32XBvzTsMwz7tj6eUKnKEdvvqarCDZ1Ver0r3/ptOVVNMwdS4K6L0pvouAo8lkZ2 3sQccHl3JtwO8STqvy3CHCvXiPRs8tVa2kEC77wE88k1Ag8YIpWkIyS2afcCloMFxTMdTWle7YjN l2yUDDxh82hkUjHZlcH92wRY2UNJKqTtnYXmWjBbIgt0nUZV4ZwYWySpRMaRggaK33ZSj8c9sLV/ aJ/od7Ev7YY3phjvWUe8GBelwIZtQFkaA8LHrRNn9Z8ANZEUCz2E5VUIOUJmeSY6UMi92wINDWkz U4ZLE6xE6S8RvWmD3OhNoCSajoDaEjW9ptjlUME29gHYYLiVgACyF1OKOaL7eDsMAKmrajPWpogA jE1a1Xe5z+D74+HdiO4ay93tu6/ciXjeLZqv3ZR4nnryvf784HqHd6kHKxwSbniM41ODyP9RI/+n 12BePzod/fT6u6w7K5D4D51zyaLUxgenYkncgF0WIsDGkvJ6hw6aTCBQlbdOmuokMlhP7vpQV6Re BovpQx++Ex+OzBEkIPxPCZhxs/wamv9YM1rMG7357SPWhVTRJLVXAvCtLbJw10arQ+Ae9UoM8a6G Urbubv38o+umdpWF9pCe9sQia4W7RTBqyRstulmMshFcuqogWdYbjQO9itHhhImxn6TGmRzfag8i ooCLFNo7kgZ+lNLwvZOarLZSdVQSTsdK0hDCVCuDrifDE1bCN1rhYakqSks4RRXEoOloNiBBOW7d VI+9Rl24KykeQcTmJIPAxaG3WsnxejEAwfhpRVQO+n1QtstGjzblKtaiBg5rFRAPwKUrvKxIm5zr /qnoGF+UtKs+iEhW0pPsOnpY6lmsZ13mv0kLIVZaM5UcsaHzDYnuA1Q8VyjqNffJizLcn6D2iyI2 FeQj4ngnVWOjfYk3vUsEcfmZlMBVTw28wGvsrYgy3EWVJbifRxWuBUh3vB7PceJMiI5MFB+v6uj2 aaETzzlC2kg5n2ImhtYG6UlTz8JIXA4vUAnviuHpTlDvcGJwFShGDRuyHHkB6skGkvB4LFcHtI8Z 59HuQX+gvHcEElRbJaOGc/eO7noXpS5v/4K8gLxcstfk002MJDc96zO5TCTEy71h6Sn9Ye1tIdT7 BdpAuKmx3KmTjVxlq1VM6W/DlmsWC03OdywBWOtJXrOjpuF8xAfXMUIROAqfJQ+OAIX4ofKLfJKF x+hbt5QOmdzEYPd7KLZlw3gHkRH81JuREHjQw93oObR3u4F4DDOKrsNnGxm/Mq6UQ0gRu/OK5pXz /TcEVyrnBb9xPcpHYW41TsOfh54CmnKRcJCWPI6Vv4yVN1FWQISDjgL1yDlgoWP3TxCgqniE0JZe q2q7sNuGo3hXLGPhOM9rJGT4GUHniYTayYFI1PyBk9JRfyDLJW8GIMjovEzr/1CxfOHax1idmc5M umyUCV5H0V4ooFSkzZxWZpst+4B6GnAsrES2A622pcT1HFX8g3bIfMf2AdmpuoG1ykSsJWOs9f3M dCV9EJoSysbQvdPiNT2byRj8qqhW+RwYrkQUyzF6aERSrEGzSw9U4axvzBwKhBwVa5D6erHvxBy9 PA49lu+byCH9Gx9FRREre/c1D2ks9VzbON4cbb0ydxpNTjvSudjR3vHOqOjq0OjVixRyUUBuaKlv 2cMRMyMw+HQqDnr64rc2nz8U0r+Xt9O1kUm09cdjLjXq3RgNh1ZLnckt4YKlotpAoctVlYOTfjUl lFnfcw9Hi1yavNJwiOLZbNt6W3lpjmoDlAmLDE0zB3jgl12jNy38lWxSOKpiXzUHyEdcH7yoHYXB qRUbeKnrtl3vvVxESZPIZdt0GDg4ru7aukRT0HYdZ33pdKjrmc0YET472BdfpaWw+QT+QERLnjao AtnX97xlRInRBEDEfg0jJ0gpGVXdy77YqGuADVk5Hol1pJzeEe3KQykVFtmBadHZr4+7I9keWxMu qd9/lDKLtNiO/yl+MvXz3oWbBSGt9XJK4Djp0ArY1O/ChzqLZQDGbnsSPuHwunbuMAg7rNHZeafT +0lVzk4YVnrrYaT7N3rSkO9OOhMFCE46H48kiHJepMip4GMIBKzLAE+PD6LL7w/8IP0oKJx8Pg6Q +V4vYTeVXPBuS7lw0qSwC6SrB1DmTLYNA2YBFpKS6cLkwXi7awge37p4ISAKHbnqIXWQEF1bl6pp lmIN5BFZjjmQA9GutpQn7GOVLwhg3lbSFHHEFfC7Ly6Ch3hhTrlvGtJqeibeyk30Gw+qQKKX/AcC vZaRXLD0scd4iLJxJtfo4CMfDxEB5UIjf+ZWbZlYsQ82PHxy3L/e2ndodgTFddxtYN+apH5UL2lX RMUYl6UNHWn+hMUGUydZ9vyzxF4/VvhonaPoK9vNzMm/n1B6YgzF9mRVLnhLVeIitnwuUJ4htdxJ gvlkUY1Bax818Z8JSDFuQ+Rob5FXn5apqab/QsXVx3qOy4+WVaGnMV1tmzo7dGTGTsIblMI82uAp g+Y8pZVeUSNjSaU85Bmkb+sffDgaETKNd2d+TLciUpJgk55Rz2MPrilGK+SNCF5BJ5VMmuQPL0dC LVm3fL0TIfRbkq56srEjyZhdwvWWrjDRAkjvAPtDFX9wRqt9FmlrSONCSbHoNVSUjwih8GQmh3Lx 2Y6+o8CTYKmkmunOfNMj3c3yzIbjeZ+Kktgs11ab9ATkliVGW7flglklRPqTcmyS/aonPfR64U70 jkT/8rLskzT4Zvhtly+adeQ+ad2FuX784YcwCbk/nDxRO7ZyKanv4kmkpDTgCZa5qvcq7ZOGD2hJ p1NNVYFCG/6LKt90fY5YrISmTHcTIF2xfn6hkgi/A1UuJ8aJPgjtEKmhLECoSA3+06tu96OwftHb oq/iWA6LtbsZDzfgLDayMtnWNLleyzWxBS2SnEml164ahYwZmyRH4lHhiPqYqy8lPczykpcCG+Tn 2DAJORgRKJ09HYaWLsK9er3ZIzugj0JjjzMWH65wUTRE3RRlEwRULv9ITNrBgnztOofvuwqoV4rD x1nvClwIV25NHL2fwoN8+N9KrqYljiCI3hv8D8tesoI7EgLxYg6iJAgRQkByCCGs7igTdmeGGT2Y X5969aqqu9dLvMWw81Hd1fXx6r0pK4zcWFeFaOK06a7V3sFCYwWV8Sniz+NzEJHKtQqWpdmsQTK2 cjXwqo8fiHM60GCOgMhpf6Kt9fFd0elxR9PN5uXOmBtoH30uJOX1RgKqxjXJeOrVIdjUedCZot0Z 7L6++SL2XX5aipHvm8fuYakq1LSoVdPntz5POiPivbhiFhkYkQpWFlaLqwgrtlCQIOvkBQw6yoo5 Thpt8BFixM+gE+LogOX/l5RwlH5YfH9VohPe2lKxWbX9qHk9oyiomW0BHK1BvVNeQgmYKdwIqtxJ 5dpWQBaEGB6HEhJiw0EY7/oqkfpGr5T/6Q/yCS7Is/qVFZEbI2/sO6Uwbxd/qPgT6+U1hh0ORdMc N0k5zb3ChUCgcmTUUl87uTDe+NHqWegcYYFYPh+/kduP28tN+/sOHmoBUba27bcGju5B4BxzSnHM fg7OJptXblGTLuSq52mNAFiO8wyjDoYCArvCg44pUCwLvolZqaQTjcj9kMAaFivfYN2FVibRfZaF ABkpwPS0som9p2yZpL0a6KsQvoTLwG0Bc+F5P7qvwGcti+ZJrrcjrskkmhfiCZtpOw3ZE6wJNeyl HdqLSWtWUXjAz4Wo2sSKihNrDi88kz8pX2AaUEXIr02AxtfkTMWlE/MIjj6IJCoeu5dOA1uW+J5Y 0Xmgd7C6abc+NrRHSqdiWQLpxutV2e/JGi4jAinc8PBSkaq4HvOrFWkis+exCI4HdtPgLOyc/OC3 bJziWfi3bJv1q85m8N4Ft8oE0cWFAtOvxMjWamAyl+xU4p6BoKHvH8ZOE7B4tT2e9E0wZ3OfZBqP 8v4nyShSVk7KBpbMcVlU0FiDIileCnxS0gzI30NeVBSF7RMZ4QmdAgrGXReYBzsif2WOKXzaQoaB e5M6/bv5YPF1GFYUhTqGX0/DHZRqwcE9IJM4tQlG2WhCeto3nONLDZ73pnCO0Ug9gSd7S95tud+M S4TcdgIZNeKzOGgk/WSLZqQ83yQ5V1+/3xaW6CPyMCgDvXqhq7tnHvaUNWSMKjNKbYP1OS6zgmGz W+sZs59RNBvAbTcdurxOdyid8aUHot0sPoOf3E57PYuozmIcezALKrtLKmKsGHeRVUE0rMXprmdd qRag157+mD7urEaLr6lovj1vVeUYIrw/iE8PiS8ahEfKi+hhmIyNbS+B5y+jKJ5gv2B8qz+I8a1g BvzUuorwQCuJ9VcUJ4dXHNkHY+oiKn+pA2VRA0KfVKb8yE3+0sypfbjm/FS/0PMPUEsDBAoAAAAA ANQ6cichyLqi+xsAAPsbAAAKAAAAZXhwYW5kLmdpZkdJRjg5Yb4BjwGAAAAAAAD///8sAAAAAL4B jwEAAv6Mj6nL7Q+jnLTai7PevPsPhuJIluaJpurKtu4Lx/JM17YB5Lh+9/7vyAF2Q6DxyBISkcwm TBmAOqfUDFRazWo3V972Cz50i+GyWTE+q9FSrPLtFQvJ8HhUl56v9w39Uj5Ux9aGh3UXyGPIFzbn lXbYiNCYOOlYSTS5qAlpWTQWCehX2QmquKlFKelJV7fqivmnJ/p4upYqtxMKGUvZCztLVovqi9kJ uECbTHworKbsx/yX8CxN21w1qhpHGAwbHc1dbXe9la17LH0e/m1N7mTuLc5aasy+bOpOBb+Lbk8/ Ly9dPib4+AXcRc3fwYHDumkLtk7WvYmvGDZ5tg4csf6I9TJa1Ecx46OEHB1+/DEx16+RFFe2PImt 4h2VCFnK/MSvIMwamXi5AsUpYdCXO98BtXn0ksJi7Yr2gOamEKJugpYuEeqUoEdBhqpulSow6xed YstWIGs2Ldq0bPuMa9t2bdlRdN+OqEs3hdwYePdp6KsUBeCeJPbOGAw0BGJoJxYbtmL3huPIZyer mGzyI+bCmZF1Vvx5Wuh8lEV7KK3q8mhcWVGzFuGaZuPVsiXkLRN7ZofcubnQ1u2U9+/KE3r//Y05 uV+eyIcHaa66uPNawjlLjy5aufbkfKHv9i4YfNHqd8Wb2D74Ofrl5a9/dx8e/njzH8iX195deXvb 0/4Z2J8t307/gTDgcY65BcRmHBSIAYP7RWAcdfSdNiF/B/I3xYUWOLhhhbB5yBCHvgX4wGJskJgh Yij6159nK374YogOvRUhhja6ld5zMcaUo4s3jvjjeSAOZIcpNUJonokUiAiGkrXp+F6QJTBJGlU0 tggBeT1eQKUZGmaJpWlSWjemZlaadCSYSAJW35CLOMkihTu2Oac729iVZomfsfngQ4SZWReCUSKJ HaGtQYRnmFBmFxiAg6go459iLuimnGVaREqcfYYCR6F+ordJPT5SWuegah7az4mbCpTnkrStx16K pZ5qaHyXyvjaqKDNCmStjMJqFK+L0uqorwLKpP4rgZWaqieXwD61LLHN6hVtM1Ltqaigxk5Z7Zrc ydDlttoWKy1MYA2rrLCQqduggiuEW+64QrIbamLJ0nlruvkKCSm505K6r6XiAopaq/Kiyy29nOE1 b8AD30vmw5EWnK2mEut7MbiBwuhwvBb7i/BJ9kLMbMirHpzgbQJ73KHCxHVs7VoGf/wvyCgfoXKv LL+c8co1H+vazD7qJPSpRFf8QqzuHW0p09SGldqhU5lMaiE3w2g1zVk02nLWJHeNyNW7eq3qfGFH VrRpZE8K4NpR4zYyhm7netxMaCOt5txPAmp3Z2mnpjdwbYetdZNxNxu40FbfHV3ieDPSKePtOf7e OOFfj3V4nJS/t3l8nZsbud+PA2552YMLzrYzmZ/4ed2tJ/z6xGeLbl3sk5eeui2r42I72Ki/fbrk IkfS+4jFp3s83GgtTjvnuAM/b/LChP473fg6bSv29ZK1zOWuQm09mdpPrNv4+PZcstiqM5a7+rP+ 7X74dt6Cfodf8gunhPi469v93Po/v17kr00AvM8ATxE3/hnogAbsV6Q4tSWM7UyCP5se+6pXOGe5 7Hsw2wNUuvW+0cVvbxYsEggz6L3zTRCBd9rgCDHIsfp58IMuJGEKfUY1/bUPhTqrYMRWuD1W1BCG pmuYDHVnpSEWMYcUZKL+ArfEdinRhzzUxP4F4cUzIKaviiW84AupeMMthhGJMzph/eDHRfkFcC+K M2PLOqg8NLkRjFE8WRpjhkUnqnFXcDRcoqYIPT2KsY7kO+IL0ThGRKaseYbsmCJ3OEY8rqaNgERZ UsjhRRsSsoeCBFgjg1gaSqYqkD+E4POsaD4cbLJufdRgK1GZyT1ykCld8JQpH1MO7pXRhKXsJCe/ aEGDRHJYfLIVi3JGRmn9CZF5XNcr3/STzIjyUwyz46OUxqNJzkMRzJzjLLV4jRbeEYgFzKKeIpii 2CBTls785BvdCU1J+LKTlmknrRgILZmtk51SfOY36Ugkb/LzSfhMpDQdaIPMbQyc5pynPf4BWqUh Uqmg4fpWEtiHUIc6UoTjfOTWBKpJSOKoLyIt6TH100DLNHOjttRovSTqRotCFEywqmkxSTnOhgLz oS5FJUyVKFOcfsem2zkjR4loUhzulIU/9ae30uPRkxIVlyEV6i9zykp48mGlBq1cPZGwT1dq9ZBH XaVVA9rUsUoJVBoLaz/V2tWnOVV3aWVoVs+5HmXdVIUzFatdebrUl84VqWflKzGnOlUj/vVGlIkq TRpb1mHscZqQLVRlaYrYvRrxshxL5X48iylkmdVGoOVjaaVT0+6Ar6pSjCVh5eRax8oqtki7Vk+J Q1ux2DaweSOibPHg28h+NArBhW1xn/52yoGGMxDHjSFni/XcY022tkLkLc+iC7rpRgy728WWbquL VW1x90HjDa12yetduTZ3Puf1ZHn5uF7parKb7YVueoMD3mGK9772ve1W8ztasb4XYwOO6HypW9/N 8le+8TWsdf/p3xnWta+eXKxg4XpNdC6soAEtZ2U8rFcOVwnEkCExhUyMya/2T8QnZnGKUfxOC8eY wjGbcIRZiqrBBvi1g0xqim384BB+t5KsLXKFaRzMwXJ1xjdWHZF5DOWr6pepSgapUYesYx9H+a5I zqxs6YngLIMZyxjW8m/F42W2GlPGZhaucr98ESvv+Mx4TbOd4bfkNrc0yHQV85vd/P7YxP4PpVxu cp4hzGcn45S+fv4VfhbpYj33uLBKDS+VwcfoMhdVuSjJaEfDXOYx5xjTR13yphNNA0//udJT9iuS JaQNS18ZtRc6NM5IKukjNxmccNbKKCntaiaqONcsXKitjUznRmPu15xGNM1gDOVep7qacD32rPEb jx3rVKqadXarvbRQQ8uZwtK+9Wq3HKNhF3q/kgJlu5tN1j3L2qdIzTQ1sSllWj4LcuyZJpu9re1g 6rKXQ6FqsAtuZ8kG5dvEVuyriz3wk10i2Y7mk03jzKiAx1u9/57h8kotR0LsOdwrpnangTzvbTP8 vx8neMoBrmX7kXzaKF+5kKWmTf6X2xzH4XFrC6xtbV4DOp05t6bG39pxmb/7ojU/+sFf7vGixzDp 13aBz20GdWQPPejgfhXInzznoatn6Q4XN9gbPjx1fl3ZYc+na6f+8LiuOe7QHHfUTnu9AieN7PrC O2n1HiW/S/Lc9JWe82BY7qdGlXmJZnzWCWX4LvYN1WwTHrksD+lHinPngsN8wtSYeLcjivLA8/wP Td/p3SEd9TFmPXwRL/ZbR4X0rykIxW0f+wUafFG4F1jv1fv7tAMn+KYFPMAELxnVcxD502I+K53P csJB/+90f1koc99ivNHv8dvnvNFCE3rmrCKkhb++V6vf1t2TDvwIjrjnzE+wXP64f2yxpLNCsR/i bF2Lkcar/9an4nolxDv+p3NOx2S0t3e7B3R2t3GFFG0gB226p2G59Hbc1m3OEoElFmksd28ml38T +CEZCFYVmGEXqHQgCBoi2HWIooJCJ2/el1DKt2qTBm9Ih36Yk0TKxnWiFn3R4m83yHMB1HZGF3Pr 9nipp09NV4SAdYQgUUZPtoMNCEsUo4TApmsIKHtyBIUM+GldxH5VWINPB4NxdiVbeHZWGH7vgnw/ uGvkhn9PsD9c+IAvaIAfFYBW6IZ0uIQ4yH9AKHdYN4ZaUYZVdoYziEc8+Hp+6IIjxkuEyHa5kxhp qBrGZ2+KmIcOOIeDQnxlp/4UkthzX4gGgah1eoiHUTd+johwYchkHlh3o2FC41CJbYiIHSaD6GYx KNhEt6R+WegrkhKLWDiEBMNGoKZvV2eEFVeLI6h2TCGKmTh3skiBC4hZJqhyJYhvRkCC+oaFUdiF ZrOMNFiM13iJGwiH+oRNv9iEswg6LQeOqEOODEKO1IJ74mhk1biHYliHPWh8lzhSuCaF/ahq+HMm 1HiPi/iMwKhwBNiOxpFRzaRmKfgt3OiMgJiPEpZtpfiPtBZprXJnmdWNcAeNH8lezGaLfyiBINhN HYmLhpiIIWmS2SVP3CeHungb0nZnTNiMEhmMI1ltM4mMKzltXHOMFSmSZf6HkMOFilSnTKdWjvR4 cyB5lCzJYFSnk0l1cQTkjy25jT6Jhm+YMmBYj0M5KSrJlESIkUFolOkIOWBZkgfIRWTplAu5dtPn SnRJb3YpJni5fPtogY8Gh4T3dZHXf7A3ZIKpI4a5LojJVIrZi334eTbkiTEoVP52hytTmT8GemsH mf83mV55cplpmY55eqJpJp3ZXS5ZNnwJawfmewv2mKp5abDZmFEpG5e5XKZpKrapM7qZZJs5mrTZ eaRpXqCZm8L5ery5mr55O4SJXMnVlvHEmKzjnPY3nZ7pA46Xk6JVkNYnm3fZnXn5nXvpmsMDmAW4 nTB3lhdGlVwplTAZav40aYzZB5QvFo99yYobFpCyM58nSJBYmZ+0+J8auZ8lN6BeWKBPSZHnaZE9 WYijOGpKiXbmmZ70xqCP2JVkBqEXynGWCDdsSXEZupY6yJ4Oim1JyaEZSZ4i2qATOY1ExRweypkW GhNmKKMkCpct6JacV5UaWqLvSaIUeaNpZpaqGKFDGpbJSULo2IyqglgCqUA2aHY1yqLu+Q0KWpQQ WZbJp4LSKKU7OqMkqaREGY57FZn8GZ8/KpYTao9q+l+xlp30kqViehi4yKU++pIpWqVWeqf2SW1e moAzN6VQCpx+KiurFaYipW486m7LZGWESqjBIkx6upMR+KjiB6gyuf6ilepreSqpbRag/MiIQomp XTqihQp/UDmmooqTTKqq+rg6bDiopRos89dEn7qqXnYGYQWranmlaUerhnWfqxKk1tlah7OrS1qk ocWOINmJMdqBG3OVm3qRR9qrRvqcPQiiBMUYH6qNbdSfGgOjpEik0WenjiqH3/pzjVqqmqqMUqeV vLqnWMp36RquG4qaDeGuuQivOymPraqG9XqQ+9oQKkqqK2qNnlmn2RqvtEiwdsqvVheXDjaqDpus HUajFKuoc5qMcslqcgqqvnqx4QkfIhuC2ehe4ylgKOtcKsuICXY+JFsrMCuvgGYJUdpgpwmc7Qpg nXp3Mtt8PluyHv7VPWI6tDwrKHqZq8DgkkXLpksDtCk1lzDLtOPqtCy7XNL3tPJ3s5Oztdc5r63V tbgVtsgztpIHXFlrN2VrXGiLn6NztlZ7Hc55rXGrtsWmtWi7f7HKCTnrn8ijkFXzt4OziS3bN4Pb mvf6NmzrpIfbeDvbtIwFt3YbaEvruFQLuYgrkJoYuTG7uSeLudgocqxprdz6ubOhfgl7otV6iO0p n+hKKTiqpQb3pO0CuwLqulH3rGdqpsEatAeahf0xuxhYn8JrqxyYuxGLoGmJrBBrsmi6qkarupKb sRK7vKwbR8OBuqXLrkH5sB0LvQvrR3KRvXorpTE4iOW6rrLKvP5Bo66Zqr5BqYUNq7DdS0au2L4F W77wG71parlVF0Qf+7yP678Qh6Ica698mx+de6weq47b08AGHLDVG7v7m7yPySkCLIgKrJnzW7Gt +ISoaLjC2hNlOmg+FL+oKsGBKnnT+1YqQ7q8uz72m3Hfa64GK3rW+06+K4YwHL6NiVEbnLrgC3FQ pKevqMM9k5U9bCjvdqgYDMBrZLILnKobS1a3O8EWcn8S2r8GKYz3q3g8vIjDe1Hm6K9NvMVPDKAA O8WPAY/Fq4bz6K80nL42rLMVejEc1iVB1a8DmcSU6750rLOgeIVY1ZAg9JAfWGvnOsf562u5BcEf BmMcOayHjP7D+fa99Ducgcu/1OoZicrJLTrJ4qvIf8zII0iSc+u8M1tNNplwggqvNVzK5iYGNsvB x3upote8aDzIKby9oKvGDkfJ6aq7aEm9DFzAw2nHtcxP0TpUfey9TszCo0usyffLFvwvoSzGxPzM Z/zAyLyepJwx2Bx7EgnLGPulyRzEmGy7frl3NKrJn/fOKRrPdRnCnVXPuBKp0Mwap+oo/Cxf/uxM AC0+gjySAn146aw2MowqVHjQ2iu3nwydCo01SCs3FO1kjgy4irt+nVtjGD02yuk5IM1ep6ijzMWc IX3SIy3SEoScq2ecaEWcFdbSfjXTFJrSLP3SKlTT8RTTu/6Z06GJwKbc035707BTnYV51Ie3098T nRFd1E2j0fsc1SBRnoE31eVz1ZBq0eqsrykMqejs0IAsy+hbu1jsxgZqxQCZ1rSbza7qzM181hoY 10N8xD95y6oMxlBc1938rl6NcSYa1rHsy/KL0NHszX5YzspM1YQd2Oa82GBNvo5dqOgLzoo92d+M v5L91Qqb2K8mpOAK2JFt2ZsdxJ2NLuJ818VcxIus2X9N2Zmt1qitx5YswKYd1GOdpEDc2AjHzr3r yRXsyrz8vkJNaloM0Wbd27Eb1+MrsIaNz8UtzXjdIyS8u3Gcyvh4yR1sYNCNwnUYp9ycfrzL3MIt 1oPNqf7gfd2xTVK9vMd+Md7GTMHzc8pmXFWezN5jXJNebNn37bXTit5TGsnDDb/W3b+23dxfutWe Ksb8Hd5fK8X6HN+YadC7vMa5LIXIG42q+uD/zdUR9auVNtfh7JFruRwbftzA3cWlfVAEvkXDipQL t9qVXdjZJNHvOsxGqCDM/JUzXOCsPdpkyNCoSg/yduN1ltqqFdoHnt6YuJUyfq9rbc20PONLzrCc 7eNTPqYvmuTkLdiQ9tqSvb1HrrxEe+WlaxReZ9yoPMD4TcXbfOJUrtoQHo2MLdpYbuS7mKNk7uS3 vUgXu98CPnZ4juJ5nt3OvUbufNVT++ZQmz1Sq51yzv6qHE3A5/3f2AnfLtLUpmvhuJXUgPvUy7nU SUs9r/zQap43NQ66m17R3xzkp2Pnv0tY5ZfoAGjmBCpCu4WpHh09CU6BhSvpcdvpwfPT5qvqCJLp A/jpE53sVzs7y+46wb7rzp552tfsuQ7tRi3tOjR5oa4511473n7mlHTs8gfuys7tfEju2a5B4w55 5Q7kBmPpMc7up67usITs5x7pgc3r66soiq7m/p5s+050Uv3r2hzdon4k713olaztcM7WIV7dRf67 0xG8EY/hxLvX6A6fFw/Kb+3bHs+HzlHxkAzxJJ/xvW7LXxvcl97h+AovJm7quiy9DB/AHK7dIW/w hP4O6TdvvIZe84vOxfoY9D8f83zdikK88gvv8Pw24XoO26+uvy2P3Tvv8yuowW5e9Md89Eg/9TZf 9Qiv9ejp9TQfw2FP9KTL538a4UOf5tT9P0Z/9s7645Yq9WwvwrM3eGaf9FRP9tja9/eE7xXUrHlv SW/69LXudn9/zfDwwmLO9EsJi7pd54h/w3V68g+T1/jqw10h+UquwvQ5jD5T1mkE8k6I5jAux3vu +RNfhaMvHFCusc1BdvSd9Wv/RKdP4XbN4hvX1nv8xQL/+X3N8nbIvlhvxKXfvb0ftOo9yoef9kjY 9GJPfv+ZxyOPn7pfi7SP9quPcVn8yL8vlA753f6vG5HND+aAvuP5vOhcNdsvJ9vBS85l/vz9fQ4x XmW/nZLvn/O0PfZLf5sEEAfyVtcfnhbdpBebtHnnGsjEUfLME+3Ix8La1Q3HFybp6K71nRdfmQXs IYSxoS2VPC5jJiYR+awULzkpdEa9brml6NI67QanSeXYl7qGGVqwG8JmykFo+5aOPebzQ7kZcEMq EM6vUIyL7/BJ8c5xbtHr7euuEYQQM/NszBIvss6x83FUR7THlPNTj0KzVW0UFZLSLpbU1ihLNjdU tQ/H9eS2bXYwROX3UeE4TlXYVvkDeXKZjJdIUNpZG5ka0XM4m1Yox3e7chyuPJy8+RSdtd1cHP6c ucuiUL10vCpePpWBny4NAa1JIOhP3r2Da4BYyVdjgsN+CL+BCudO0sV/FutRNBcR38QMIBeiIQnP 48eGIQVKTLayZMpnMFEmkhHmIYwGOEXK3HPzUE5wPF9y7Ojz1s6gPQkSLegU6Uyj1X5O9TZv1dGo sIDiqggVK9itT5fqErvx7FiTXWOaLUvWq9pzVukZopsx7Fu5c7NSZUhsY5q9BQVP2sW38OC1gCFl eulY8VrIPyeLqxzZ02VGmh5jwpxK845WnQl9tsfZdGrVq1m3dv0admzZs2nXtn0bd27du3n39v0b OOg20UpQ6YntEvJLw2V7KE78GkDpRZzoQ/4HPXoFd9eVZ18e23ly5eO1IyiDvYrBgdLNr1df6j31 +O6ZypTfPs786ThO6fd/Hz76ysPvpvdcuy8d/9Zzox0EywMwHwf3A2if1yRk4cEM8xNNQ/UgnOjC BbWr8MAOBxRxQgxXCLE9B0E0scUT3WuNRQNjTFHGFWEscL8XcbzRRvxohNFGHj3kT6cNj2SFBy1q VLHEH9mbEsgcdYQSRSQDlNFIJi0kMkghq6QyC+4iSq/Je5YJCrw1w/tuxjHDXFFN4vDZbjjk2ITt zergFLNLMq8ksCE0/YivUC/5zCiSRJfEsj/6HFUyUkLnjHNIixotEtNODc2SwBN9fDRU9v7q84lE Bnf0VKQQJxVyVFBffTVKASkdM9BLtQQVV0F9WBVQT1l7MthiVeXwx0BJTDLZOHOtlVdOjd11BgVL LXbLWfU7FSlir732WGS/BdfKam39T9hhwTyX3FvLJHMl4/AMMt7nhEpJXj+9Ky7PM+fFtN5y36WX X/G4RSjfN/f9s8/gHH4Y4oglnpjiii2+GOOMNd6Y4449/hjkkEUemeSSTT4Z5ZRVXpnlll1+GeaY ZZ6Z5pptvhnnnHXemeeeff6ZH2CEHlpooI3+7GC5kj6aaVquMU6pnabsjlp4qDa36ayjMkZLrgda 9tlKt9SabI+8FjVUsD0Eikeuz56a7f6vQVm67Lr7605euQ0stMC+zYNGzFL3ATxsuw2HJfDAo1H7 a2z41jvvp5drO93DLecE1rffhtVUxSGXc1K/b6T78tKZDHfzXkeP0W2vIxfd9WhNn32NxL9zEup3 5pY7V92jo9x22oU/1GyThj+eEYTvdQH55onXjXTnLY++W+mtZxb667X/dTfqt9fae/u+H19JFczs 3CCq9xwpeEjJH59W0VnXVE7mubfh/fzHnV9E2L91e3KCkBoUFic/XemvefE6SaJiJ7/BAfBvBPwc BI2xufAhsGe0woKdVne2wWUpdhFMH/8AhEHtxU9vzJlf6IDkPxHy7nO+MiHyUPhCAfXBRFkkFGEF V6hDGc5weArUHIQ4p77RxQ1ySBxgCYHovAsWr4nWeyJFphhFmlXRH1i0Ysy0+JEtOpE3Xfxiy8So jTKOUWVnFIYa0Xgy4KVuD1OTVIpOkhU2trFkfoPgZvDCwxZucIIzuiMeR6bHCBoJdjQZoQ2VAbAQ NlCQhKSdIXnov0buEEuOcuCRGtnJZUlyejB8ZAcFaER0SZBclvwhKMEnyg72T4YVkmUKscW5A7Ky aZT8Y+N8KEdbGpByLqwcLpmmSRBSSFNOwhFNUqXIFgySmBxrkPu2Fs3DNeM6ioGmNTO2zVBw025E E+c4SwPOshUAAAA7UEsDBBQAAAAIAL0BkCfsgmKy2woAABEaAAAKAAAAcGFydDcuaHRtbK1Z/Y/b uBH93YD/B1YFers4f9xu0qRIHaPexOkummy2G+eubXAFaGlk8VYSdaRkx/9935CULDvBIVscDsh5 ZXI4H++9Gcqz69W7t/PhQMyul4vX/EGI2epm9XY5f/Pq7qN4t7j9uHgr7pc/TsQPkwsxFneL+5V4 Ppv6RX7Du+VqIa5Xq7vx8p8fb358Gd1Tle/HtY5ErMuayvpltMv2G6K/FaqgSVP9ZUJJE/W33y7e LV9Gf1/eLu8Xq/f3kXj1/na1vF29jH5yO7+zopAbFYtUlRsyVuhSZMqKrSpruSHxQPu1liZxRmfT EM7s6v3rf+P/+PQG9sSHm/8sX44v8OTNmON7TVZtSrEiWcyu7vnxV6KeTXkvW7u+97bu5n8q17b6 a+/jb//Lnsx7Lnx/Ob+TphbPxYtgfTa9mn/d8ulH9uNifmf0xsiiQDZEnZFw8SDui2+00n7s/eEz gCCFuLpfLv7Bf7SFsU1RSLOP4Odi/uUelP9++aZbNsnqIv9jt+eD/8Bbvf/t8go5eHay+M7QVunG Cv5SnD0777aJuDEGYMr3QpWMLFubJq6VLifeDf/fb8Zz/F0vQMDI6C6868v5c8D9hh8m/gyuFB7P Krfv24q+sGJnVA0GiDWl2tBIVF+rm8ikFVIkKk2JIxRRLW1NkdBGRClRjtXRcLCmWDaWhE7dVk6Q iptcGrYak7VY7nPSGBKyTNyyxGO8ylSura6y/UTc6hr8QR5tnIGIbH444LWqTNRWJY3M8bFLrxUg mioqbWpZ1iOxbureTndIcItknImmVHV3ekGFNvvhQMbsIDlTe6oFntLBJpbKUtCWTEjURFwTp4tN gNqi1qIig28KWcZ4DoMmzlRNHCu8tTCVq1jVe3eyJWCF/wBQXJZf/cAH9zyFnb2IbEWcwFptSaS5 3NiI8yDhPrwrkSXvtlrnxC6E/canwC1UZZo3BJ/cl2vKJKPXtDXaZRpbUeKJg/C3AmfVIWOjkTMk phRpY2ARCUKIea53vdQbdo4++wyQ40eiYlmTsLogEWVAt41Erh7I1zlCbaF5IeaJWJT90vuTY1QE wOE6YYsNCQqRkzIukzuV58NBAkQjiTH82gsqM9nmo1ezNiOyYjelo5RKgfqUdr58JEyTI1rOvSEu TU3JaDjYIc8OGrydPav3FTE1Yochy44kk2Pq3x2LF/yw8E6aY4ZfijtLTaLHvRX/D8+PBO2JF7R/ rfm0VQBfw9CXIjbaWnzBToizyK05Z5Bqk/gqGrDKJ284MLRRkAHQGywRZVOs8ZnhDbqjVMTJg064 RyAdUmRRvW7Xel9Ji7ZJMQqibDERK3TM4SCGwjBnnMCGqgSCMORjzbX47FleydK1WimQmg0d7WFU iyUz3vkHDQMrcXzgU6Y2GfwrdeM9TAyeWpFr4HanUOAR2KGw+5fG1ipV+A7QVrWl3NtPZexJ5jHL yXJCiSVC79AB9nFOLcMrVbFMEhsl/0ijpjjYA2ptdLPJ6pbFy88gPmNwOPhYskH2sNsJ55q89hs7 AZfxQ7u7S7Gl2mcV6UEhXHYCIBm32Bb5KrCAH22Fn6rO3KOM8qrNqWVMu0HGy8sDUQXdMvJAIBgf DsLnQ8dw2eFCl5Tbx4nNDZoDDgB/g+A6WzLhzImLsU8zigqVc0LMylkyq3OHlaYOZO71Y5+TgoCe VlBrkZMHq3YyBr2hivBPWfe3igJogI7iGbKELVtK8Ge9I67NTotu13DQb1ET8cboAu7j3EpjM6dr q2h33HKl4FLkNFbWNh3sIT+KqV/r4eB49eWYhebJeCfRLHsi0TVctILjrgwWYmnGjGgxiaaMEfWR VfkJ/Zp8PE4yQQ9IqTuil/WTRj3yGxI0jfK72m10JXMph07LWqLzbqk4ybr1aIOwBhHngDoouFFB s4a/4Id71xrWB84B647gms+0DUNSpFyNfl0rqQznFNyqjQqnMpvLo8RCVB6ZqNURbSBvGcUPvte7 eFvAxJxCr57cT0HvAiRX0DoP8XEL8aO8cBzDwQatkWXLaB8Bq8NE3NRhqDBuZvGld7hFjK49a+iy 0XkO1dPgcUeCesdk82lDE6x0mDEiOAuJo+iE3bGuFAsm8gWbG3ItGJW0RwLeG4kI/fB9kEFHNyhD EtDhW4zPUGgqMCK3EhxgJ1qJ8tmSzvcQhxsUC8VCyq1iryjnFRutoZ6opNO0wo8MwMjT4PjjCvoK oxsuAPl+dHI05h6rOzYELXZkh7OhFZWYJiBdqADuhhKjWSco+EslPES7WhFvakcoartBB+mJeF+G rUnjBxbqH9dLUuC/b1Kf2uffq6KgRPE2naboEz+3bvGhhU7c5FJpvh0rR7lE8sUWgbN6Agqz9Twc BuI23dA0m67ngAeaeql+7YXHPcd3MOlbr5+80bfKZKcSrktYafF/ybQ9uK74i5JS7oSp11H034bd 6kjehd5UCYfF4HBccwEdhozFBsZHHdaHg6ddjfxYTaycuOu5XgLEgo0+tSQfHPn4QtC57bMBvQU0 C883GW4vaAeHIck6VfLSH6BhJYbfGEegfbEMcxsStSpCm0t5Tu9aucsOiMyEi7ma3Gs6Avp5+ZFA vjq5r4WbLc/ImNV9CbrEWXHWv41wdnnk2AAR/UR7W2hTbUr7wyMQEvPMxbq2pWMhQ/AJxYw7143O fQqhPPVYlbFxLQGCdMCok3TMaXF9SNIvTVHNbuafptwlfp5Nb+aupBBwHgExrXfdkAMOxgAvKx5K HtkC+fjLfm/A956CmOMPxKu4GhwQL8+1h3+ryC26vUGcOOLpEZyJMG3pGMTjkYvJgpqfktYhryVI a3nCPdcNgEzM9myeDvxVF8WikodITrlMtv4i6lZvVICwu50AYK4YXDKvCu35YVZdvb0aHUd34IRr WR0Fg4vgiGFxRxc2PKH0dsIWwgKaYt/UXYVVeqRVfHsvnfw9ejCMtqg/xg7XvyLWF+PJxBOiMXJv GZHOaQZCGIsoGbWI9552KGdfeN7lmQH1qoPQheso31O9vvmbgZuM27wmhFgK5vFZqvsX4H7bO/c7 h4O30w+CJ3v3BhJU6w0EAPYUIfkjQoZ5JkHizvD8w+v7xTvWn4fzI3ENsuz0ZDhgVyNAgs85HhjC Nf1wkQsSFE6qMyNtxr4jfma8SvdutvB+Ow8xPjZorCAPO6XLMQKs2uuSWxEmsDRvLMApZOqE2VK4 x3TrfADuCuKh6H3hVRvd6mSB/AT3HgkQNwC5rgyd0Oh4GLQSN/YECeD0HGsMvj9+tdTTrxYvIQ1f eROD3R59+R4TP6pFnyVfV0fMcj+5+23AU8L3WeQOAFCbBsKLa1N7JewC9iNLmHC/bO/izFyeu2wn OjSNFnov/EuGlXszvJ7nWiYKAPInXI7Dh4vzkbkcmSezas7IHg4mkzPLbzNOX7Exs84nE/fe4Qtz T1pzl7+LuaetuSe/i7k/t+aenpqbTV163qegYWNYpFvrqEqivO2WZKi+ZQl74akaem9Mh+vfoacQ itnu862FIY35pdXYw/iV8pCKYT09Nat4dkMxxeV/L55hGOf6c6UdjQSHyO+YP3Mi/MsWNE6M8u6y MBEf0WMLyW/bRj1pOXgX7moetgHigbWshZvwyur4pdUsdnPp/BOzgVcydssGqP+D2G8mAi03rDh5 1eV+mTj+jYNfRjx376K48U/ExTNWHP9ryuEnjWn4hWQ2dT8F/Q9QSwMEFAAAAAgARxqQJ1EqR9JI AQAACgIAAAoAAABpbmRleC5odG1sdVJBT4MwGL2b+B++9KAnYDtoTFaI3VZkCTDsyozeYFRoHGUZ oPLvLYzELdFTv7587/W9l2KPB75zfQXYo2TZDwA4oJyAx3lk0Od4tbURoy6jGw/BYh1yGnIbTWYQ M9+u27JMjp1ZNOUejWy+4j513EUUQ0DCmPjA6NaEiTkFAyLCONxh67T033PisO+MpkKwq1QjVGOj r6LLhXgsZSnM9vBgiqxF5/SQBNRGTzSkjPA1O3P6MjBvayiTXO7gXapcHGuoFBSyhk+pmiQX8CG6 tEqO2SCKrbEMPF8vX/WpJ1frwWb1Rm1jqhHX6PMtRS1zBVwkJZ6zHv4jNbZ6bq/m9Ss4cnghtBvV JntIRS5VDUkDjQax7kF3baPLXscbtohjDmYi50al9WGmh1H0wp5UmfgeuJCJnQnTe0g7OBXx68Ya w+m0/R/4AVBLAwQUAAAACADWqqYo1sOxV60HAABfDwAACAAAAGZjcHUuZW1srZdtc9q4FsdfX2b4 Due+SrIbG2yeabcNBZKmN6Rpkj7dTqcjbIG12JKvZIeSF/vZ718ypEnTnel0lkwA29J5+J+fjsQl j7i44fGQFlpl9OfK50utytz4ES73v7v+FDb7fqfpB+223299PqjX/jXfUF7OUxGF/u2tnzA/krTf 9wd+wBru44DWokjoanZ9QSKml6NR2Al7IaYulKankhdfBZPLo++tPHtCx1ocUodmbENhs9mkZm8Y tIdhj35v9nG5P766RggfPH7iQvQueVFqOSTDZVEoLwiaQTdseWE39HZu/vjezZF2k4yvJE+FKWye 9drlQ1k+BcjZx1ur85mQ8XeyuATPz49nF0+o2f4Wb9gaNvvDVps8XDXvW93/X8ZESt1+t0dC3qgV jytPiHOt9OrgCT2203psx80p5UqqNWTfRRm0wwMbZhbcZaX0sgrzzezNxS8Zfzk9e21vyaLnI/dU cO0v9AG8Dtp+0EGtu36nV/ktWOtb1X/kLfwbbwsvyksX7P4F0wIlZSaHUl7gBe3Aj9Jy7glZcA2d 4B2FGXT8VtcPBiGyDj4794+CrIBsNc7Vl0uess3v+HKVs+zL7GQ8GDTDsL2FdLqj9MVoFPR7vc4P GAyGwLATgsHQMjibXtPEcTjjxrAl904nQ3raGgRhMxxN/S7MDCad6dFdas/qtdd6yaS4ZYVQwHVk jIqEu6Bjb3zx1jI9Q9ZcD2mmbkWaMmr7nYA+cfmZ9t8LOUBkp479URTxvPDOwHYJ70Pisl67VkNa JbA4PxKcc+v1kBYZPXVBHN1jF8GMI3hhRSKYoRdaIQkdY+Sgk7G5PopjP0pYmnFtfMOf2YotuOYy 4qZKMwiOw5HfedFshePj9tGGJUo5y9XT7hR1C1svmp3WqH9PhOpp7/h47Hem0KgZBPfm1mvHwGFI H5mUdFKKGNI8XSebJecPhJydzqbeO8TmhAx8EGWFE3LpnQH7IVn46VHWTygCIizaPvIAONf3B9Rr E6ybGyQae1bMrDL6N+bqtQsNjmOrypDmZbqq16x776005dxEWsxx/6k1Uqhh5bL89ui7ekxYgdGO u+Yj8MJuBZ6tQ55uXHA/iOeqnP/JI+TveEK2WW5xov01ijykSzj45KZ9pgk3YilpgeeGIPN4AuWB 1hgKoY9615scowv+tWjkKRMS2iVMG1788fbKG12NT0/vjdVMGuDhTWWkYgg2pN5cFD8x4IP39nRy NqRWfxEOevPeoLnohr1mGDdb83nU68/n3TDu9Xi9Vq8l4tB+vGIZWuh/HOa01gqq1WvPHiDz7a79 e8/3YlRwxalQxMyKNqoksSBRkDCUg3wxT91DIdFpYm4HaIqdQIaYjHeWYhWVGfKp1uyddFhDBvr5 1TC1gO4llILgRcK3pciYLFlqHcYgBOUvC/T+Usaojh11cjw5q+bvn5y/BQac0+SBuzMRWdAOKje7 kE4f5QHnaexyzFPOEEbKC8o42X5O60REyTbyWLlRayaLnbWs0iiObdYwbChVUeXe5clpzef3A0iK Ih82Guv12s9Exv1Sihsvty28jwbc+Ktau40FkPtSSeDfipyU/uXpxfLWzrX/azBAbK7KgnhWpqxQ 2hwSRZAAxSMfr+fV2ERVkmiaa46eR088oC4oYTecmE3MQEKkvtai4Ie0RA+wYjBa8DVloDgxsGbx e3H9/tBRlG1753zXO6tIrEh36w4j5NIQbiXMCi45/fvOr+Q3dogWAAGucSDBV9y3FnIWrdDWq93R IPCI49i05C4IcY/nTGgcpywCEtFaPXEM0jDsgq2qaqscMXnX/JBYLNC5inRj18EOApiAj6wq9y4Z R7a2vcVaslbs8IKnKZUGymi+HYoQnu8Kc7qHx7nmqCS3gTkza85XHFQZZWEU+IaV8nBF7SwZFypu G8faRJFU6L9WgMIm7dxnO89M2r2fWzlUCrRI5Vwm6+0ChnNQUi2KObfmcsyxNPMEqV2+nlmhUJq9 gnAE0xsnnCCWbTOw/f/k/AxFxw211CzL7C3nzB5lPwRBA9x+PSS3wHCKs49tNvVapuJy21qyXOmC xo5Ni6YVbI0tnliaYt6OPVoqFVeD9ue8wJGnXkMGaG3j8TYLh02sDpx3bNHKVBqgTRe2gC6BV0oy N+8dK5fJ/Zb4m5Ei/21XqolL3EqrnLQZA1em1K4JUiWLkCyGzwKMgJgboeCIO5dSSe/kwjUuNDTa s2XYa+zZAuwBUTQsw7EkUbbCipJznQljN23LncTeaVfOxkFdheO9elfJX3l29bbwYEVZTPxd06oW LiLQPGN6Rc9JoLrpdv0wtwwhv2sZe4a0WCagyuJo9/zYHhftMnN75yHmGuAjlS0wWmhmydTcdk8b td2nbDkrWpy6NtT7+1C99v7lx5PptF7765detsbbnWL4003RnYeSIkux778cXY4vRifTn55tsJlH OVrM1kK95v1DL5zhLqdTMonIc8h3SK2mN8Fp5lzRm5Ibt9CrX2wgI8bZaOPaLVuzjanX7L6TlVFy 6N63Daag2/8q7JXulOPTR9vIs9KICIAwDVwBlkH352iu2/wj0Pfg11ojaLR6rW6j2fjSaLW7IT4G nV67H/SCVuOfzN62k/8DUEsBAhQACgAAAAAAcpVPJ/u22ECYLgAAmC4AAAgAAAAAAAAAAAAgALaB AAAAAEYxLTMuZ2lmUEsBAhQAFAAAAAgAeSGQJwz9cv5QJAAAX5UAAAoAAAAAAAAAAQAgALaBvi4A AHBhcnQ1Lmh0bWxQSwECFAAKAAAAAACpImonsljSFSIhAAAiIQAACAAAAAAAAAAAACAAtoE2UwAA SVNBMS5naWZQSwECFAAKAAAAAACnI2gn4vnY+YcYAACHGAAADQAAAAAAAAAAACAAtoF+dAAAc2Ny YW1ibGVyLmdpZlBLAQIUABQAAAAIALCSZScMvSSneB4AAFUfAAAOAAAAAAAAAAAAIAC2gTCNAABm LWNwdV9sb2dvLmdpZlBLAQIUABQAAAAIAO4hkCc+I5Bo8W0AAJHsAwAKAAAAAAAAAAEAIAC2gdSr AABwYXJ0Ni5odG1sUEsBAhQACgAAAAAANyANJxmZD1UqWAAAKlgAAAgAAAAAAAAAAAAgALaB7RkB AEYxLTIuZ2lmUEsBAhQACgAAAAAASx0KJ+M9MHHkFQAA5BUAAAgAAAAAAAAAAAAgALaBPXIBAFNS QjEuZ2lmUEsBAhQACgAAAAAACFwIJwyq2vQECwAABAsAAAgAAAAAAAAAAAAgALaBR4gBAFJPUDIu Z2lmUEsBAhQACgAAAAAAqUMIJ2+T6b7AQAAAwEAAAAYAAAAAAAAAAAAgALaBcZMBAEYwLmdpZlBL AQIUAAoAAAAAAFQj1ybfTASB9hkAAPYZAAAGAAAAAAAAAAAAIAC2gVXUAQBGMS5naWZQSwECFAAU AAAACAA9IpAns2ooVKkVAABGiAAADAAAAAAAAAABACAAtoFv7gEAc3VtbWFyeS5odG1sUEsBAhQA FAAAAAgAgwGQJ90JowtLUwAAw+oAAAoAAAAAAAAAAQAgALaBQgQCAHBhcnQxLmh0bWxQSwECFAAK AAAAAADONXInXAQ4gdUkAADVJAAABwAAAAAAAAAAACAAtoG1VwIAbWl4LmdpZlBLAQIUABQAAAAI AHoBkCeScm+3oy0AAJyFAAAKAAAAAAAAAAEAIAC2ga98AgBwYXJ0Mi5odG1sUEsBAhQAFAAAAAgA dQGQJ5m6CH+/KAAAUnoAAAoAAAAAAAAAAQAgALaBeqoCAHBhcnQzLmh0bWxQSwECFAAUAAAACAC4 HZAn+gemmHMbAACoRwAACgAAAAAAAAABACAAtoFh0wIAcGFydDQuaHRtbFBLAQIUAAoAAAAAANQ6 cichyLqi+xsAAPsbAAAKAAAAAAAAAAAAIAC2gfzuAgBleHBhbmQuZ2lmUEsBAhQAFAAAAAgAvQGQ J+yCYrLbCgAAERoAAAoAAAAAAAAAAQAgALaBHwsDAHBhcnQ3Lmh0bWxQSwECFAAUAAAACABHGpAn USpH0kgBAAAKAgAACgAAAAAAAAABACAAtoEiFgMAaW5kZXguaHRtbFBLAQIUABQAAAAIANaqpijW w7FXrQcAAF8PAAAIAAAAAAAAAAEAIAC2gZIXAwBmY3B1LmVtbFBLBQYAAAAAFQAVAIoEAABlHwMA AAA= ------=_NextPart_000_0007_01BFEE9C.3E2B57C0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00474 for ; Sun, 16 Jul 2000 21:50:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:29 +0200 (MEST) Received: (qmail 24384 invoked by uid 0); 15 Jul 2000 18:10:25 -0000 Received: from f19.egroups.com (207.138.41.182) by mx12.rz2.gmx.net with SMTP; 15 Jul 2000 18:10:25 -0000 X-eGroups-Return: sentto-1101623-461-963684564-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 15 Jul 2000 18:10:21 -0000 Received: (qmail 6206 invoked from network); 15 Jul 2000 18:09:23 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 15 Jul 2000 18:09:23 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 15 Jul 2000 18:09:23 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6FIAjf29728; Sat, 15 Jul 2000 14:10:45 -0400 Message-Id: <200007151810.e6FIAjf29728@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu@egroups.com From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 14:10:45 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cfae3a8f035f19c08c71fcc3b5b24df6 Status: R X-Status: N Albert Abramson <maxx@nventure.com> wrote:

>Rares Marian wrote:
>
>> Albert Abramson <maxx@nventure.com> wrote:
>>
>> >addressing in as well as instruction addressing.  Exception and link
>> >registers could keep values there also, allowing for 8 local plus 8
>> >global for data exclusively, about as many as you get on MIPS, if you
>> >need that many.
>>
>> Sounds like a Level -1 cache to me.
>
>I must have explained it too vaguely.  Like 68k, you have 8 address regs,
>each 48 bits wide.  Like G4, you also have data regs, but they're 128 bits
>wide, packing four or more operands in each register.  This part is not
>inconsistant with the idea that you could have registers that expanded
>further in width to improve throughput.  I just happen to favor multiple
>processor cores, instead.

As long as you can get the damned things to cooperate.

>The major limitation to improved performance in computers is wait time for
>memory.  Processors spend most of their time just waiting for memory to show
>up.  Some alternate work has to be found at run time to fill the growing
>gaps while accessing memory.

Like caching? :)  I don't mean to snipe, I've just been through two microkernel discussions (weeks long) that ended the same way: Got stuck on efficiently putting the cart before the horse (which works sometimes).  While you might be talking about addresses in registers, structurally I see the same design as cache.  I mean it could work.  I just have this disease where I see old ideas resurfacing in new clothing.  I see ghosts :)  Blame it on intimacy with 2 microkernels :)

>It's worth taking a penalty on peak performance in order to overcome this bottleneck.

Ok.  Let's see it.

>Running programs tend to use just one or two registers for addressing, and
>MIPS uses two more for linking and exceptions (IIRC), so you've already
>freed up three or four regs, moving them over to address.

Moving registers around an rf doesn't give more regs unless you store some to memory.  Maybe we could add two other caches datareg cache ands instrreg cache.

>Moreover, you're
>using those same address registers for branching.  The hardware is all the
>same, just 48-bit unsigned addition with and without immediates.  This is
>nothing like the kind of work normally performed on data, so I tend to view
>them as separate.

There's no such thing as a fractional address so why waste the wire to FP?  
That's the theory anyway.  I'm curious why Alpha dropped it.

>Putting them all into the same gprf is traditional, but
>there seems to be an opportunity for some specialization, here.
>In other words, you have 8 local address and 8 local data.  That's not quite
>so stuffy.  If it is, you can make use of the global registers, giving you
>up to 16 of each.  The hardware sees only a large flat register file, but
>each running thread has its own ThreadID number, seeing just local and
>globals flatly.  That number is appended to the local register number at run

Jecel had a similar idea.  I had a really bizarre concept: revolving register windows.  Every request for a register just moved to the next register available.  Then it wrapped around.  It would reduce context switches to simple recalls of stored registers.  The problem: getting a specialized ALU to be part of the load store unit.  References to registers would be based on a base register address that was also part of the ALU.  This would get changed when ever a new thread was active.  Many could be stored but few were active.  The result: a complete decoupling of register file size from software design.  You could write a program that requires 1024 registers fop a 16 register machine. 

Replace the chip with a 64 reg chip and you don't have to recompile.  I may just do this anyways for a project Nate is working on.  I haven't talked to him about it yet.

Now I know there's something wrong with your software if you really need all that.  Unless you're an Amiga then you're allowed a million registers because Amiga knew what they were doing.  Just a note: it occurs to me Amiga mastered special purpose TTA.  Did an excellent job with that.  But then again their TTA chip had 800 actual registers.

>time (only one thread is running at one time).  If a thread is assigned an
>ID number of 2, a register specifation of r5 is changed to r25.  Writing
>results to global R3, however, will be visible by any thread that takes
>over, so globals have to be carefully allocated.

That's not going to be good.  Too much hassle especially since it bypasses security.
>On a permitting load-store, a cache miss causes a branch on miss operation.
>Another thread is loaded into the program counter, and begins running.  It
>sees the 8 global data and 8 global address registers, but it also sees its
>own registers as well.  At any time, any thread can read from and write to
>local and global registers, giving it access to 32 in total.  The hardware
>gives the appearance of four sets of 8 regs, so a thread does not need to
>specify which set of local register it will use.

Neither does a revolving window.

>That's the primary benefit of this kind of banking scheme.  You can
>transparently switch contexts without the program having to know what other
>running threads are doing.

Hmm doesn't (god what was it called?) restoring regs as a thread is ready to leave the CPU take care of this, like they do normally in interrupt handling?

>The downside is greatly reduced when we consider the fact that just one
>thread can be scheduled to run, giving access to all 16 data and all 16
>address registers simultaneously (as well as the 16 condition fields).
>Alternately, a small number of running threads can allocate two or three
>additional registers from the global sets.  As it just so happens, I've
>already accounted for separate condition fields on the data registers,
>including an Update bit.  A running thread can check that bit on a global
>data register to determine if the register is already in use by another
>thread.

Let's see it.

>the event of a cache miss, which will leave it's CPI far behind even the
>21164, which had already exceeded Itanium's clock rate when COMPAQ
>discontinued it for new systems.  Most application developers I know of
>don't even have an IA-64 path; only Intel and Wall Street still think
>they've got something big.

Wall Street likes to talk.

>Provided that a fast L0 is available, provided that the compiler is smart
>enough to look ahead through one branch, provided that we're not trying to
>issue more than one ALU per load-store (no one does, but you can widen to
>two load-stores plus two ALU ops per cycle if you don't mind the penalty),
>we can generally accept that 8 data plus 8 address registers will be enough
>for a three issue processor -- and if it is not, globals are available to
>use.

Okay as a short term project I like it.  Let's prove we can design the chip first.  Afterwards we can go balistic with revolving windows.

>>
>> >--Maxx
>> Rares
> Maxx
Rares

Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00477 for ; Sun, 16 Jul 2000 21:50:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:30 +0200 (MEST) Received: (qmail 7602 invoked by uid 0); 15 Jul 2000 18:32:12 -0000 Received: from jj.egroups.com (208.50.144.82) by mx02.gmx.net with SMTP; 15 Jul 2000 18:32:12 -0000 X-eGroups-Return: sentto-1101623-462-963685928-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 15 Jul 2000 18:32:07 -0000 Received: (qmail 25043 invoked from network); 15 Jul 2000 18:32:07 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 15 Jul 2000 18:32:07 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 15 Jul 2000 18:32:07 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000715183206.JCQV24904.mail.rdc1.wa.home.com@nventure.com> for ; Sat, 15 Jul 2000 11:32:06 -0700 Message-ID: <3970AE26.65251CAF@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007151810.e6FIAjf29728@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 11:32:08 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: edd0a989b69a8e204122998aa5b75341 Status: R X-Status: N 
>Provided that a fast L0 is available, provided that the compiler is smart
>enough to look ahead through one branch, provided that we're not trying to
>issue more than one ALU per load-store (no one does, but you can widen to
>two load-stores plus two ALU ops per cycle if you don't mind the penalty),
>we can generally accept that 8 data plus 8 address registers will be enough
>for a three issue processor -- and if it is not, globals are available to
>use.

Okay as a short term project I like it.  Let's prove we can design the chip first.
Afterwards we can go balistic with revolving windows >Rares
Okay, I'm with you there.  As a matter of fact, the one-threaded design is the simplest arch I've come up with.  BTW, the reason for keeping the global and locals all in one flat rf is to allow zero-overhead context switching.  Since L1 cache misses are common, it is often useful to be able to start work up right away in spite of a cache miss.  Unrolled loops tend to need more registers and rarely miss the cache, so load-stores may choose not to make use of branch-on-miss in that case, instead opting to monopolize the global registers as well.

Nothing wrong with designing a one-threaded version first.

--Maxx

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00480 for ; Sun, 16 Jul 2000 21:50:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:31 +0200 (MEST) Received: (qmail 10353 invoked by uid 0); 15 Jul 2000 19:02:52 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 15 Jul 2000 19:02:52 -0000 X-eGroups-Return: sentto-1101623-463-963687767-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 15 Jul 2000 19:02:51 -0000 Received: (qmail 30454 invoked from network); 15 Jul 2000 19:02:47 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Jul 2000 19:02:47 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 15 Jul 2000 19:02:47 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6FJ48931801; Sat, 15 Jul 2000 15:04:08 -0400 Message-Id: <200007151904.e6FJ48931801@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 15 Jul 2000 15:04:08 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cbf6d08bb5ae282712a54dc11b7da524 Status: R X-Status: N Albert Abramson <maxx@nventure.com> wrote:

>Provided that a fast L0 is available, provided that the compiler is smart
>>enough to look ahead through one branch, provided that we're not trying to
>>issue more than one ALU per load-store (no one does, but you can widen to
>>two load-stores plus two ALU ops per cycle if you don't mind the penalty),
>>we can generally accept that 8 data plus 8 address registers will be enough
>>for a three issue processor -- and if it is not, globals are available to
>>use.
>
>Okay as a short term project I like it.  Let's prove we can design the chip first.
>Afterwards we can go balistic with revolving windows >Rares

>Okay, I'm with you there.  As a matter of fact, the one-threaded design
>is the simplest arch I've come up with.  BTW, the reason for keeping
>the global and locals all in one flat rf is to allow zero-overhead context
>switching.  Since L1 cache misses are common, it is often useful to
>be able to start work up right away in spite of a cache miss.  Unrolled
>loops tend to need more registers and rarely miss the cache, so load-stores
>may choose not to make use of branch-on-miss in that case, instead opting
>to monopolize the global registers as well.
>Nothing wrong with designing a one-threaded version first.
>--Maxx

Join me in #f-cpu on varley.openprojects.net.



Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00492 for ; Sun, 16 Jul 2000 21:50:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:33 +0200 (MEST) Received: (qmail 5561 invoked by uid 0); 16 Jul 2000 09:26:11 -0000 Received: from fj.egroups.com (208.50.99.207) by mx11.rz2.gmx.net with SMTP; 16 Jul 2000 09:26:11 -0000 X-eGroups-Return: sentto-1101623-464-963739569-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 16 Jul 2000 09:26:10 -0000 Received: (qmail 1110 invoked from network); 16 Jul 2000 09:26:08 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 16 Jul 2000 09:26:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 16 Jul 2000 09:26:08 -0000 Received: from f-cpu.org (Aubervilliers-4-217.club-internet.fr [195.36.150.217]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA24218 for ; Sun, 16 Jul 2000 11:26:04 +0200 (MET DST) Message-ID: <39717F8C.1729A68F@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39704557.E030A25F@guerrier.local> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 11:25:32 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Manual and specifications ? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: df72aa005aa0232e505149a7a12bdd00 Status: R X-Status: N hi !

OLIVIER wrote:
> Hi there,
>
> I follow your discussions for two months now.
>
> 1=B0) I'm happy to see more technical discussion this week.
thank you for delurking AT LAST :-)

> 2=B0) Where can I get the technicals infos about f-cpu,
> what is already done, what is to be done, choosen specs, etc...
>
> The f-cpu web site doesn't contain theses, and the links to manual are=
> broken.

????

even at f-cpu.org ???

> Olivier.
>
> ----------------------------------------------------------------------= --
> In Europe, more than 219 million people will access Internet services<= BR> > using mobile phones by 2003, according to Forrester Research.
> Learn Wireless Development on
> http= ://click.egroups.com/1/6222/1/_/3462/_/963659378/
> ----------------------------------------------------------------------= --

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00495 for ; Sun, 16 Jul 2000 21:50:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:34 +0200 (MEST) Received: (qmail 5096 invoked by uid 0); 16 Jul 2000 10:59:06 -0000 Received: from f19.egroups.com (207.138.41.182) by mx02.gmx.net with SMTP; 16 Jul 2000 10:59:06 -0000 X-eGroups-Return: sentto-1101623-465-963745138-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 16 Jul 2000 10:58:58 -0000 Received: (qmail 16269 invoked from network); 16 Jul 2000 10:58:57 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 16 Jul 2000 10:58:57 -0000 Received: from unknown (HELO web1103.mail.yahoo.com) (128.11.23.123) by mta1 with SMTP; 16 Jul 2000 10:58:57 -0000 Received: (qmail 7217 invoked by uid 60001); 16 Jul 2000 11:00:01 -0000 Message-ID: <20000716110001.7216.qmail@web1103.mail.yahoo.com> Received: from [199.203.98.250] by web1103.mail.yahoo.com; Sun, 16 Jul 2000 04:00:01 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 04:00:01 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the manual Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 48715356f216b612f17cf584fb7b4226 Status: R X-Status: N Hi, Should I consider this file as a new update that I have to add to my new release of the OpenTech cdrom? Regards Jamil Khatib --- Oliver Liu wrote: > > ----- Original Message ----- > From: OLIVIER > To: > Sent: Saturday, July 15, 2000 7:04 PM > Subject: [f-cpu] Manual and specifications ? > > > > Hi there, > > > > I follow your discussions for two months now. > > > > 1°) I'm happy to see more technical discussion > this week. > > > > 2°) Where can I get the technicals infos about > f-cpu, > > what is already done, what is to be done, choosen > specs, etc... > > > > The f-cpu web site doesn't contain theses, and the > links to manual are > > broken. > > > > Olivier. > > > > > > > > > ------------------------------------------------------------------------ > > In Europe, more than 219 million people will > access Internet services > > using mobile phones by 2003, according to > Forrester Research. > > Learn Wireless Development on > > > http://click.egroups.com/1/6222/1/_/3462/_/963659378/ > > > ------------------------------------------------------------------------ > > > > > > > > ------------------------------------------------------------------------ > The future belongs to Wireless. > Learn Wireless Development Now! > http://click.egroups.com/1/6355/1/_/3462/_/963665127/ > ------------------------------------------------------------------------ > > > ATTACHMENT part 2 application/x-zip-compressed name=fcpu.zip __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ ------------------------------------------------------------------------ The future belongs to Wireless. Learn Wireless Development Now! http://click.egroups.com/1/6355/1/_/3462/_/963745138/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00498 for ; Sun, 16 Jul 2000 21:50:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:35 +0200 (MEST) Received: (qmail 24885 invoked by uid 0); 16 Jul 2000 11:51:14 -0000 Received: from hp.egroups.com (208.50.99.201) by mx02.gmx.net with SMTP; 16 Jul 2000 11:51:14 -0000 X-eGroups-Return: sentto-1101623-466-963748271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 16 Jul 2000 11:51:11 -0000 Received: (qmail 10133 invoked from network); 16 Jul 2000 11:51:10 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Jul 2000 11:51:10 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 16 Jul 2000 11:51:10 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA22949 for ; Sun, 16 Jul 2000 13:51:06 +0200 (MET DST) Message-ID: <3971A181.CD6B618E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:50:25 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] webring ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fc0f2f65ed7385493ee0fc5c668baaa8 Status: R X-Status: N hello,

this might sound superfluous, but...
could we make a f-cpu webring ?
if you have a f-cpu-related webpage, we could
thus link them together...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00501 for ; Sun, 16 Jul 2000 21:50:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:35 +0200 (MEST) Received: (qmail 24942 invoked by uid 0); 16 Jul 2000 11:51:15 -0000 Received: from hp.egroups.com (208.50.99.201) by mx02.gmx.net with SMTP; 16 Jul 2000 11:51:15 -0000 X-eGroups-Return: sentto-1101623-467-963748271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 16 Jul 2000 11:51:11 -0000 Received: (qmail 8273 invoked from network); 16 Jul 2000 11:51:10 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Jul 2000 11:51:10 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 16 Jul 2000 11:51:10 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA26004 for ; Sun, 16 Jul 2000 13:51:06 +0200 (MET DST) Message-ID: <3971A184.8D680526@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:50:28 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: Re: OKAD] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4fe05ead9fffef51a256a66add4d1de4 Status: R X-Status: N hi !

i followed the link given by Jacel and mailed about OKAD.
I've read and heard about OKAD as being the best and smallest
LSI CAD SW, designed in FORTH by FORTH's inventor himself,
in order to make a FORTH chip (F21). this is the answer i got :

-------- Original Message --------
Date: Sat, 15 Jul 2000 01:47:19 -0700
From: Jeff Fox <fox@ultratechnology.com>
Organization: UltraTechnology
To: whygee@f-cpu.org
Subject: Re: OKAD

OKAD is not available for a free download.  The equations
>from an early version of OKAD have been published at my site,
but not the latest ones with the thermal modeling.  OKAD is
Chuck's tool rights are owned by iTV.  Since they pay hundreds
of K for other CAD packages they figure people that serious
people will not balk at half million dollar type numbers.

Chuck has said that he would like to give OKAD into the public
domain, but I think that unless his situation with iTV changes
that it will never happen.  Anyway OKAD encapusulates some of
Chuck's trade secrets and he isn't likely to give away the
thing any time soon in any event.

I have earlier copies of OKAD with my custom chips but
I am not at liberty to give that software away nor can I
give away the layout of my chip.  I have made available
much of what Chuck and Ting did give away about the
stuff they had done but there no "evaluation copy of
OKAD" at my site.  It would be nice.  All the menus
and most of the equations are documented for an early
version of OKAD at my site, but not the CAD program
or chip layouts that I bought from Chuck.

Jeff Fox


Yann Guidon wrote:
>
> hello,
> i'm one of the designers of the F-CPU project and we're interested in using
> the OKAD system (much lighter than Alliance ;-D) but i can't find it in the download page.
> help ! :-)
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00504 for ; Sun, 16 Jul 2000 21:50:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:36 +0200 (MEST) Received: (qmail 11429 invoked by uid 0); 16 Jul 2000 11:51:16 -0000 Received: from fl.egroups.com (208.50.144.74) by mx02.gmx.net with SMTP; 16 Jul 2000 11:51:16 -0000 X-eGroups-Return: sentto-1101623-468-963748271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 16 Jul 2000 11:51:14 -0000 Received: (qmail 10154 invoked from network); 16 Jul 2000 11:51:11 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Jul 2000 11:51:11 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 16 Jul 2000 11:51:10 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA13769 for ; Sun, 16 Jul 2000 13:51:06 +0200 (MET DST) Message-ID: <3971A183.CB3CDD8E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39704557.E030A25F@guerrier.local> <000901bfee59$48752500$b723440a@public.zz.ha.cn> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:50:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the manual Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 080bd9a8d79814df2af0b1b117f1fc53 Status: R X-Status: N Oliver Liu wrote:
> ----- Original Message -----
> From: OLIVIER <olivier@guerrier.com>
> To: <f-cpu@egroups.com>
> Sent: Saturday, July 15, 2000 7:04 PM
> Subject: [f-cpu] Manual and specifications ?
>
------------------------------------------------------------------------------------------
>                Name: fcpu.zip
>    fcpu.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>            Encoding: base64

ouch. let my modem cool (279KB in the inbox at 28K...).
it ain't even the last version...

if you have time, d/l a newer version of your choice at :
http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.zip
http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.tgz

look at
http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
or
http://www.f-cpu.org
for other files and news.

And Olivier Jean is doing a LATEX version of the manual,
which will be used for the definitive version of the revision 0.2.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00507 for ; Sun, 16 Jul 2000 21:50:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:37 +0200 (MEST) Received: (qmail 10084 invoked by uid 0); 16 Jul 2000 11:51:17 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 16 Jul 2000 11:51:17 -0000 X-eGroups-Return: sentto-1101623-470-963748271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 16 Jul 2000 11:51:15 -0000 Received: (qmail 29001 invoked from network); 16 Jul 2000 11:51:11 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 16 Jul 2000 11:51:11 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 16 Jul 2000 11:51:10 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA01262 for ; Sun, 16 Jul 2000 13:51:06 +0200 (MET DST) Message-ID: <3971A17E.83FF6F29@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007151810.e6FIAjf29728@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:50:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64, 8 regs?! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ce63bfdfb3c44b74ca5a6c6d3a5dc1d7 Status: R X-Status: N hi !

Rares Marian wrote:
> Albert Abramson <maxx@nventure.com> wrote:
> >Rares Marian wrote:
> >> Albert Abramson <maxx@nventure.com> wrote:
> >> >addressing in as well as instruction addressing.  Exception and link
> >> >registers could keep values there also, allowing for 8 local plus 8
> >> >global for data exclusively, about as many as you get on MIPS, if you
> >> >need that many.
> >> Sounds like a Level -1 cache to me.
> >I must have explained it too vaguely.  Like 68k, you have 8 address regs,
> >each 48 bits wide.  Like G4, you also have data regs, but they're 128 bits
> >wide, packing four or more operands in each register.  This part is not
> >inconsistant with the idea that you could have registers that expanded
> >further in width to improve throughput.  I just happen to favor multiple
> >processor cores, instead.
> As long as you can get the damned things to cooperate.
>
> >The major limitation to improved performance in computers is wait time for
> >memory.  Processors spend most of their time just waiting for memory to show
> >up.  Some alternate work has to be found at run time to fill the growing
> >gaps while accessing memory.
> Like caching? :)  I don't mean to snipe, I've just been through two microkernel
> discussions (weeks long) that ended the same way: Got stuck on efficiently putting
> the cart before the horse (which works sometimes).  While you might be talking about
> addresses in registers, structurally I see the same design as cache.
> I mean it could work.  I just have this disease where I see old ideas
> resurfacing in new clothing.  I see ghosts :)  Blame it on intimacy with
> 2 microkernels :)

<snip>

maybe i'll finally like better our new Rares :-)
today, computers is not about inventing, but moving things around.
maybe there's nothing left to invent, only ideas to put together
in different ways. exciting, huh ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00510 for ; Sun, 16 Jul 2000 21:50:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:38 +0200 (MEST) Received: (qmail 10110 invoked by uid 0); 16 Jul 2000 11:51:18 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 16 Jul 2000 11:51:18 -0000 X-eGroups-Return: sentto-1101623-469-963748271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 16 Jul 2000 11:51:15 -0000 Received: (qmail 1969 invoked from network); 16 Jul 2000 11:51:11 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 16 Jul 2000 11:51:11 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 16 Jul 2000 11:51:10 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA06257 for ; Sun, 16 Jul 2000 13:45:54 +0200 (MET DST) Message-ID: <3971A17F.B66595D@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:50:23 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d69e5fe4009ca117ade7d6856c1514df Status: R X-Status: N hi,

i've been thinking about SMT for quite a while now...
and Albert's reason for using it is that it reduces the
impact of the memory latency and bandwidth.

but now, if you have N tasks/threads each accessing
memory, don't you simply displace the problem ?
if all your threads have cache misses, the core stalls.
i believe that there's something to solve here.
We can criticize OOO but it solved this problem.
ideas are welcome (realistic ideas preferred).

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00513 for ; Sun, 16 Jul 2000 21:50:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:39 +0200 (MEST) Received: (qmail 4383 invoked by uid 0); 16 Jul 2000 11:51:52 -0000 Received: from jj.egroups.com (208.50.144.82) by mx11.rz2.gmx.net with SMTP; 16 Jul 2000 11:51:52 -0000 X-eGroups-Return: sentto-1101623-471-963748307-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 16 Jul 2000 11:51:51 -0000 Received: (qmail 29769 invoked from network); 16 Jul 2000 11:51:46 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 16 Jul 2000 11:51:46 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 16 Jul 2000 11:51:46 -0000 Received: from f-cpu.org (Raspail-4-117.club-internet.fr [195.36.203.117]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA01346 for ; Sun, 16 Jul 2000 13:51:44 +0200 (MET DST) Message-ID: <3971A1AE.49C3573E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000716110001.7216.qmail@web1103.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 13:51:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the manual Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5ecb71aa594c02249f95e094dc72c5b8 Status: R X-Status: N no, this is an old version.

Jamil Khatib wrote:
>
> Hi,
>
> Should I consider this file as a new update that I
> have to add to my new release of the OpenTech cdrom?
>
> Regards
> Jamil Khatib
>
> --- Oliver Liu <netxiang@public2.zz.ha.cn> wrote:
> >
> > ----- Original Message -----
> > From: OLIVIER <olivier@guerrier.com>
> > To: <f-cpu@egroups.com>
> > Sent: Saturday, July 15, 2000 7:04 PM
> > Subject: [f-cpu] Manual and specifications ?
> >
> >
> > > Hi there,
> > >
> > > I follow your discussions for two months now.
> > >
> > > 1=B0) I'm happy to see more technical discussion
> > this week.
> > >
> > > 2=B0) Where can I get the technicals infos about
> > f-cpu,
> > > what is already done, what is to be done, choosen
> > specs, etc...
> > >
> > > The f-cpu web site doesn't contain theses, and the
> > links to manual are
> > > broken.
> > >
> > > Olivier.
> > >
> > >
> > >
> > >
> >
> ----------------------------------------------------------------------= --
> > > In Europe, more than 219 million people will
> > access Internet services
> > > using mobile phones by 2003, according to
> > Forrester Research.
> > > Learn Wireless Development on
> > >
> >
> http= ://click.egroups.com/1/6222/1/_/3462/_/963659378/
> > >
> >
> ----------------------------------------------------------------------= --
> > >
> > >
> > >
> >
> >
> ----------------------------------------------------------------------= --
> > The future belongs to Wireless.
> > Learn Wireless Development Now!
> >
> http= ://click.egroups.com/1/6355/1/_/3462/_/963665127/
> >
> ----------------------------------------------------------------------= --
> >
> >
>
> > ATTACHMENT part 2 application/x-zip-compressed
> name=3Dfcpu.zip
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail =96 Free email you can access from anywhere!
> http://mail.yahoo.com/
>
> ----------------------------------------------------------------------= --
> The future belongs to Wireless.
> Learn Wireless Development Now!
> http= ://click.egroups.com/1/6355/1/_/3462/_/963745138/
> ----------------------------------------------------------------------= --

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00519 for ; Sun, 16 Jul 2000 21:50:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:41 +0200 (MEST) Received: (qmail 3956 invoked by uid 0); 16 Jul 2000 12:51:50 -0000 Received: from hp.egroups.com (208.50.99.201) by mx02.gmx.net with SMTP; 16 Jul 2000 12:51:50 -0000 X-eGroups-Return: sentto-1101623-472-963751897-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 16 Jul 2000 12:51:41 -0000 Received: (qmail 9261 invoked from network); 16 Jul 2000 12:51:35 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 16 Jul 2000 12:51:35 -0000 Received: from unknown (HELO web1104.mail.yahoo.com) (128.11.23.124) by mta1 with SMTP; 16 Jul 2000 12:51:35 -0000 Received: (qmail 1471 invoked by uid 60001); 16 Jul 2000 12:52:41 -0000 Message-ID: <20000716125241.1470.qmail@web1104.mail.yahoo.com> Received: from [199.203.98.250] by web1104.mail.yahoo.com; Sun, 16 Jul 2000 05:52:41 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 05:52:41 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the manual Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 883b8d5858e6ce356ed9ba301eab9fa3 Status: R X-Status: N Hi all, Could you please keep my opentech cdrom up to date with your latest design. You can upload what you want to add to the cdrom on the OpenCores ftp server. 1. login to ftp.opencores.org as anonymous, 2. upload your files "compressed if it is possible I'll extract what should be extracted on the cdrom" to the /incomming/OpenTech/Designs/[your project name] 3. inform me that you added new version Regards Jamil Khatib --- Yann Guidon wrote: > no, this is an old version. > > Jamil Khatib wrote: > > > > Hi, > > > > Should I consider this file as a new update that I > > have to add to my new release of the OpenTech > cdrom? > > > > Regards > > Jamil Khatib > > > > --- Oliver Liu wrote: > > > > > > ----- Original Message ----- > > > From: OLIVIER > > > To: > > > Sent: Saturday, July 15, 2000 7:04 PM > > > Subject: [f-cpu] Manual and specifications ? > > > > > > > > > > Hi there, > > > > > > > > I follow your discussions for two months now. > > > > > > > > 1°) I'm happy to see more technical discussion > > > this week. > > > > > > > > 2°) Where can I get the technicals infos about > > > f-cpu, > > > > what is already done, what is to be done, > choosen > > > specs, etc... > > > > > > > > The f-cpu web site doesn't contain theses, and > the > > > links to manual are > > > > broken. > > > > > > > > Olivier. > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > In Europe, more than 219 million people will > > > access Internet services > > > > using mobile phones by 2003, according to > > > Forrester Research. > > > > Learn Wireless Development on > > > > > > > > > > http://click.egroups.com/1/6222/1/_/3462/_/963659378/ > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > The future belongs to Wireless. > > > Learn Wireless Development Now! > > > > > > http://click.egroups.com/1/6355/1/_/3462/_/963665127/ > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > ATTACHMENT part 2 application/x-zip-compressed > > name=fcpu.zip > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail – Free email you can access from > anywhere! > > http://mail.yahoo.com/ > > > > > ------------------------------------------------------------------------ > > The future belongs to Wireless. > > Learn Wireless Development Now! > > > http://click.egroups.com/1/6355/1/_/3462/_/963745138/ > > > ------------------------------------------------------------------------ > > -- > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > the F-CPU: > http://www.mime.univ-paris8.fr/~whygee/f-cpu.html > SHARCPAGE: > http://www.mime.univ-paris8.fr/~whygee/sharcpage.html > > ------------------------------------------------------------------------ > To email plain text is conventional, to add graphics > is divine. > We'll show you how at www.supersig.com. > http://click.egroups.com/1/6811/1/_/3462/_/963748307/ > ------------------------------------------------------------------------ > > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ ------------------------------------------------------------------------ BTW: Did you buy that new car yet? If not, check this site out. They're called CarsDirect.com and it's a pretty sweet way to buy a car. http://click.egroups.com/1/6847/1/_/3462/_/963751897/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00537 for ; Sun, 16 Jul 2000 21:50:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:44 +0200 (MEST) Received: (qmail 2447 invoked by uid 0); 16 Jul 2000 16:04:51 -0000 Received: from ef.egroups.com (207.138.41.172) by mx02.gmx.net with SMTP; 16 Jul 2000 16:04:51 -0000 X-eGroups-Return: sentto-1101623-473-963763480-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 16 Jul 2000 16:04:44 -0000 Received: (qmail 31517 invoked from network); 16 Jul 2000 16:04:40 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 16 Jul 2000 16:04:40 -0000 Received: from unknown (HELO public2.zz.ha.cn) (202.102.224.112) by mta1 with SMTP; 16 Jul 2000 16:04:39 -0000 Received: from public ([202.102.254.154]) by public2.zz.ha.cn (8.9.1a/8.9.1) with SMTP id AAA08481 for ; Mon, 17 Jul 2000 00:11:32 +0800 (CST) Message-ID: <001401bfef3f$627e84a0$9afe66ca@public.zz.ha.cn> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Oliver Liu" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 00:00:20 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Reading-list Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01BFEF82.008A16E0" X-UIDL: 58a4c3e3b4bd33ec9d8ddd507c38f33d Status: R X-Status: N ------=_NextPart_000_0011_01BFEF82.008A16E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgICANCiAgIE5vdyBpIGZvdW5kIGkgY2FuJ3QgZm9sbG93IHlvdXIgZGlzY3Vzc2lvbnMgYmVj YXVzZSBpIGtub3cgYSBsaXR0bGUgYWJvdXQgZGVzaWduIGNoaXAuSSB3YW50IHRvIGtub3cgdGhh dCBpIG11c3QgdG8gbGVhcm4gLA0KZXhhbXBsZSBkb2N1bWVudHMsbWFudWFsLGJvb2tzLi4uIFNv LCBpIG5lZWQgeW91ciBoZWxwLiANCiAgICANCiAgIFRoYW5rcyENCiAgIExpdQ0KICAgICAgICAg ICAgICAgICAgICAgIA0K ------=_NextPart_000_0011_01BFEF82.008A16E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Hi  
   Now i found i can't follow your discussions because i know a little about design chip.I want to know that i must to learn ,
example documents,manual,books... So, i need your help.
   
   Thanks!
   Liu
                     
------=_NextPart_000_0011_01BFEF82.008A16E0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00564 for ; Sun, 16 Jul 2000 21:50:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:50:49 +0200 (MEST) Received: (qmail 28476 invoked by uid 0); 16 Jul 2000 18:20:49 -0000 Received: from fj.egroups.com (208.50.99.207) by mx11.rz2.gmx.net with SMTP; 16 Jul 2000 18:20:49 -0000 X-eGroups-Return: sentto-1101623-474-963771641-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 16 Jul 2000 18:20:48 -0000 Received: (qmail 10400 invoked from network); 16 Jul 2000 18:20:41 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Jul 2000 18:20:41 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 16 Jul 2000 18:20:41 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6GILxD20447; Sun, 16 Jul 2000 14:21:59 -0400 Message-Id: <200007161821.e6GILxD20447@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 14:21:59 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90eda877ca7baa51d7bb7fe92d4ec6de Status: R X-Status: N Yann Guidon <whygee@f-cpu.org> wrote:

>hi,
>
>i've been thinking about SMT for quite a while now...
>and Albert's reason for using it is that it reduces the
>impact of the memory latency and bandwidth.
>
>but now, if you have N tasks/threads each accessing
>memory, don't you simply displace the problem ?
>if all your threads have cache misses, the core stalls.
>i believe that there's something to solve here.
>We can criticize OOO but it solved this problem.
>ideas are welcome (realistic ideas preferred).

I don't know if it's possible without designing new ICs.  Or turning cache on its head.  This memory bottleneck is a lot like Token Ring versus Ethernet.  With token ring you've got one frame of data moving on the whole network.
Slow as all hell.

Now let's see:
Albert's global registers do allow threads to allocate extra registers.  There's a point where some threads have access to their local registers and lower priority threads get the global regs.  It puts pressure on either the OS or the compiler.

Now I've got an idea:

What if we modify SRB to be used dynamically rather than when threads must be scheduled out?  It's not exactly my revolving window mechanism(which has the penalty of a combined ALU/LSU) but it's a start.  That is the context switching becomes only partial.  It becomes more frequent but not as large as a continous context switch at thread exit.

Thread 1 needs 20 registers. 1-20 (Reg0 is reserved).
Thread 2 needs 5 registers.
Thread 3 needs 2 registers.
Thread 4 needs 13 registers.

Each thread is awake for 500 cycles.
T1 allocates 5 registers, 1-5.
T2 comes in and takes 3 regs, 1-3; 1-3 from T1 get stored once, 3 stores of 500 cycles is nothing. 500 cycles out of 100Mhz is 1/2000th of a second.  Out of a 1Ghz chip it's 1/20000th of a second.
T3 takes 1-2; 2/500 again not a problem.
T4 takes 1-7.

Now T1 comes back.  It may only need regs 5-12.  Only 1 reg is actually restored. 2 need to be saved.  The old method reloaded 1-5.  And it also saved 1-7 in the process. 

You could call this partial cascaded windowing. :)

And there is no reason Albert's setup can't be adapted to this.  Perhaps we could use Albert's setup as a high load mode.

>WHYGEE
Rares

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
>SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
>------------------------------------------------------------------------
>To email plain text is conventional, to add graphics is divine. 
>We'll show you how at www.supersig.com.
>http://click.egroups.com/1/6820/1/_/3462/_/963748271/
>------------------------------------------------------------------------
>
>


Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00570 for ; Sun, 16 Jul 2000 21:51:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 16 Jul 2000 21:51:10 +0200 (MEST) Received: (qmail 23785 invoked by uid 0); 16 Jul 2000 19:35:28 -0000 Received: from ei.egroups.com (207.138.41.177) by mx02.gmx.net with SMTP; 16 Jul 2000 19:35:28 -0000 X-eGroups-Return: sentto-1101623-475-963776116-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ei.egroups.com with NNFMP; 16 Jul 2000 19:35:25 -0000 Received: (qmail 29264 invoked from network); 16 Jul 2000 19:35:16 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 16 Jul 2000 19:35:16 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 16 Jul 2000 19:35:15 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000716193515.BGIO24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 12:35:15 -0700 Message-ID: <39720E73.346FC5FC@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <3971A17F.B66595D@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 12:35:16 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b29997367c3c7d53f5286220028bf451 Status: R X-Status: N

Yann Guidon wrote:

> hi,
>
> i've been thinking about SMT for quite a while now...
> and Albert's reason for using it is that it reduces the
> impact of the memory latency and bandwidth.
>

Oh no! Just the opposite on bandwidth.  Even Tera admits that cache demands
move from short latency to high bandwidth.  Luckily, with on chip
integration of cache, you can get much higher bandwidth.  Latency is almost
impossible to overcome, but bandwidth still has a ways to go.  The demands
of the latter increase in proportion to the number of threads a processor
is running at one time.  With the 7-at-a-time proposal (two sets of 64
regs), you would need to move at least four times as much data through the
memory system to keep up.

>
> but now, if you have N tasks/threads each accessing
> memory, don't you simply displace the problem ?
> if all your threads have cache misses, the core stalls.
> i believe that there's something to solve here.
> We can criticize OOO but it solved this problem.
> ideas are welcome (realistic ideas preferred).
>

Look at it from the standpoint of the memory system (as though the
processor is infinitely fast).  Instead of running one thread's memory
stalls sequentially, you're handling multiple requests in parallel, so the
total load of memory stalls is handled a handful at a time, instead of
sequentially.  Remember, it takes 60ns to bring back one word from main
memory.  During the next 60ns, however, you can bring back six or eight
with modern SDRAM.  In the near future, it will be more like 12-20.
Currently, that's only used for filling caches.  It could be used for
handling misses on alternate threads.

That's the value of multi-threading.

--Maxx

>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
> ------------------------------------------------------------------------
> To email plain text is conventional, to add graphics is divine.
> We'll show you how at www.supersig.com.
> http://click.egroups.com/1/6820/1/_/3462/_/963748271/
> ------------------------------------------------------------------------
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00793 for ; Mon, 17 Jul 2000 01:19:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 01:19:17 +0200 (MEST) Received: (qmail 20472 invoked by uid 0); 16 Jul 2000 22:05:28 -0000 Received: from ci.egroups.com (207.138.41.176) by mx02.gmx.net with SMTP; 16 Jul 2000 22:05:28 -0000 X-eGroups-Return: sentto-1101623-476-963785119-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 16 Jul 2000 22:05:21 -0000 Received: (qmail 23862 invoked from network); 16 Jul 2000 22:05:19 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 16 Jul 2000 22:05:19 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 16 Jul 2000 22:05:18 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000716220504.DLTT24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 15:05:04 -0700 Message-ID: <39723190.D37C8733@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007161821.e6GILxD20447@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 15:05:12 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70898b3d54d44459aacd45addb6a1c8c Status: R X-Status: N

Rares Marian wrote:

> Yann Guidon <whygee@f-cpu.org> wrote:
>
> >hi,
> >
> >i've been thinking about SMT for quite a while now...
> >and Albert's reason for using it is that it reduces the
> >impact of the memory latency and bandwidth.
> >
> >but now, if you have N tasks/threads each accessing
> >memory, don't you simply displace the problem ?
> >if all your threads have cache misses, the core stalls.
> >i believe that there's something to solve here.
> >We can criticize OOO but it solved this problem.
> >ideas are welcome (realistic ideas preferred).
>
> I don't know if it's possible without designing new ICs.  Or turning cache on its head.  This memory bottleneck is a lot like Token Ring versus Ethernet.  With token ring you've got one frame of data moving on the whole network.
> Slow as all hell.
>
> Now let's see:
> Albert's global registers do allow threads to allocate extra registers.  There's a point where some threads have access to their local registers and lower priority threads get the global regs.  It puts pressure on either the OS or the compiler.
>

Maybe it should be the other way around.  Since low priority threads aren't expected to run as fast, perhaps they should just try to stay out of the way of the primary thread.  T1 gets access to any unused global regs, and the rest just have to make do with 8 data and 8 address.

>
> Now I've got an idea:
>
> What if we modify SRB to be used dynamically rather than when threads must be scheduled out?  It's not exactly my revolving window mechanism(which has the penalty of a combined ALU/LSU) but it's a start.  That is the context switching becomes only partial.  It becomes more frequent but not as large as a continous context switch at thread exit.
>
> Thread 1 needs 20 registers. 1-20 (Reg0 is reserved).
> Thread 2 needs 5 registers.
> Thread 3 needs 2 registers.
> Thread 4 needs 13 registers.
>

Ahah!  Good.  You just allocate as many local registers as you need.  Impressive thinking.  The additional hardware needed isn't that great, but each thread needs to keep two numbers handy for each register access: the start point (the number you add to each reg access) and the number of regs used.  Intel, though, is doing this for fast procedure
calls on IA-64, and it gets into some ugly renaming.

No thread really NEEDS 13 registers.  It's just that if there aren't enough, there is going to be a lot more high-level memory activity.

On my earlier description for multi-threading, I may have been rather rash in keeping the design simple.  At run time, the processor simple appends the ThreadID number to the register number.  Since the hardware sees only a large, flat register file, the ThreadID number suffices for the upper two or three bits of the register field.  Of course,
for globals, R1-R7 (R0 is just set to zero for both address A0 and data) are not translated.

> Each thread is awake for 500 cycles.
> T1 allocates 5 registers, 1-5.
> T2 comes in and takes 3 regs, 1-3; 1-3 from T1 get stored once, 3 stores of 500 cycles is nothing. 500 cycles out of 100Mhz is 1/2000th of a second.  Out of a 1Ghz chip it's 1/20000th of a second.
> T3 takes 1-2; 2/500 again not a problem.
> T4 takes 1-7.
>
> Now T1 comes back.  It may only need regs 5-12.  Only 1 reg is actually restored. 2 need to be saved.  The old method reloaded 1-5.  And it also saved 1-7 in the process.

Hmm... that's not exactly what I was thinking.  It almost sounds like you're talking about time sharing.  Branch-on-miss is exactly what it says it is.  When a permitting load-store misses the cache, it takes it as branch mispredict, fetching the next thread for execution.  The point being that you're doing away with the context switching
overhead altogether.  An L1 cache miss can cause a 5-10 cycle stall.  Even small OOO windows allow the processor to look ahead for more work to do, often involving further cache accesses.  However, since we are lacking the capacity to build a large OOO design, and because even large OOO windows can do little to overcome main memory access
latency, we must have a better alternative.

Here's how the wait time breaks down on Alpha 21164, IIRC:
Issue 8%
Traps 4%
cache 30%
memory 50%

On the 21264 (big OOO window), the first three are reduced, especially cache access, but memory is still there and getting worse.

MT helps alleviate the main memory wait, but if the context switching overhead is too big, you lose any value in trying to do something else while waiting.  That's why I prefer register banking.  There is no overhead.

As for the other MT debate, I prefer smaller, statically scheduled cores to issuing instructions from multiple threads on one core.  Reason being that, for all of that extra scheduling hardware, you could just add another core.  3/4 of the logic on processors these days is for bookkeepping, not doing any useful work.  Plus, there's that infamous
clock penalty.  A higher clock rate helps overcome most architectural restrictions (including a shortage of registers) but does nothing to speed up memory.

> You could call this partial cascaded windowing. :)
>
> And there is no reason Albert's setup can't be adapted to this.  Perhaps we could use Albert's setup as a high load mode.

I still want to make sure that the first design is well balanced.  Making a core capable to two load-stores and two ALU's per cycle obviates the need for wider instructions, more registers, more hardware, and more careful branching and pipelining, all resulting in a slower clock and poorer code density, resulting in a lower hit rate on the
ICACHE.

When having to compromise, it is generally better to to favor smaller and simpler when more than one processor can be integrated into one die.  The only downside is the complexity of the network crossbar, but two or more processors on one chip may have their own separate caches anyway, letting them all queue up and pass messages at the L2 level.

In the end, the whole point is reducing the obstacles to multi-threading, empowering compilers to spawn work that would normally have to be handled sequentially.  Too much work is still handled the old fashioned way just because it's not worth it to split up a task that may be better handled as two or more independent tasks.  Many of the int
SPECmarks suffer from this overhead -- there IS no fine-grain parallelism on separate processors.  Getting the overhead down to one cycle would help a lot to enable the breaking up of tasks that want to run independently.

Anyway, let's work on making that one-threaded design work.

--Maxx

> >WHYGEE
> Rares
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00796 for ; Mon, 17 Jul 2000 01:19:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 01:19:18 +0200 (MEST) Received: (qmail 23936 invoked by uid 0); 16 Jul 2000 22:37:25 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 16 Jul 2000 22:37:25 -0000 X-eGroups-Return: sentto-1101623-477-963787039-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 16 Jul 2000 22:37:22 -0000 Received: (qmail 3944 invoked from network); 16 Jul 2000 22:37:13 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Jul 2000 22:37:13 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 16 Jul 2000 22:37:13 -0000 Received: from f-cpu.org (Raspail-3-17.club-internet.fr [195.36.203.17]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29099 for ; Mon, 17 Jul 2000 00:37:11 +0200 (MET DST) Message-ID: <397238F6.C7811EB1@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000716125241.1470.qmail@web1104.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 00:36:38 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the manual Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 72f93d506c6458d71a724bf44f480659 Status: R X-Status: N hi,

Jamil Khatib wrote:
>
> Hi all,
>
> Could you please keep my opentech cdrom up to date
> with your latest design.
>
> You can upload what you want to add to the cdrom on
> the OpenCores ftp server.

ok, just remember us from time to time :-)

i hope we'll have a stable CVS tree one day...
Paul is meant to deal with this.

> Regards
> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00799 for ; Mon, 17 Jul 2000 01:19:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 01:19:19 +0200 (MEST) Received: (qmail 9216 invoked by uid 0); 16 Jul 2000 22:37:37 -0000 Received: from hl.egroups.com (208.50.99.197) by mx02.gmx.net with SMTP; 16 Jul 2000 22:37:37 -0000 X-eGroups-Return: sentto-1101623-478-963787040-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 16 Jul 2000 22:37:27 -0000 Received: (qmail 26003 invoked from network); 16 Jul 2000 22:37:16 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 16 Jul 2000 22:37:16 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 16 Jul 2000 22:37:16 -0000 Received: from f-cpu.org (Raspail-3-17.club-internet.fr [195.36.203.17]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29109 for ; Mon, 17 Jul 2000 00:37:13 +0200 (MET DST) Message-ID: <397238F8.D521BD86@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001401bfef3f$627e84a0$9afe66ca@public.zz.ha.cn> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 00:36:40 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Reading-list Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2a020713cb78b17accb4551ea01e7765 Status: R X-Status: N > Oliver Liu wrote:
>
> Hi
>    Now i found i can't follow your discussions because i know a little
> about design chip. I want to know that i must to learn ,
> example documents,manual,books... So, i need your help.
>
>    Thanks!
>    Liu

i'm sorry : i don't think we can't help you directly. we can give you advices
but nothing can replace :
- experiments (playing with the soldering iron)
- a good library in a technical university
- some teachers
- and a lot of good will and patience.

Internet can help you but can't replace anything, it's just something different.
so : read the list, follow the links that appear in the list, read a lot, ask questions,
and make your own opinion. this "long way" is worth it.

books to read (but they're getting old) : Patterson & Hennessy,
two books : one named "a Quantitative Approach" (the "QA") and
"The Hardware/Software Interface" (HW/SW-I). they're excellent
to give historical backgrounds and the necessary technical concepts
(electronics and boolean logic).
There are also of course : the "dragon book" (Aho, Ullman and Sethi,
the french title can be translated as "Compilers : princples, techniques
and tools"), Knuth's books, and a book co-written by Conway, which describes
the "Mead-Conway" methods for VLSI design. I have a copy of a similar
and valuable book, "Computational aspects of VLSI design" (1984) by
Jeffrey Ullman.

If you have a public library near you, just go there and read.
Computer history and the discussions on this group show that there's
not much left to invent, but there are essential building blocks and
concepts that create all the rest.

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00802 for ; Mon, 17 Jul 2000 01:19:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 01:19:20 +0200 (MEST) Received: (qmail 9238 invoked by uid 0); 16 Jul 2000 22:37:38 -0000 Received: from hl.egroups.com (208.50.99.197) by mx02.gmx.net with SMTP; 16 Jul 2000 22:37:38 -0000 X-eGroups-Return: sentto-1101623-479-963787040-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 16 Jul 2000 22:37:28 -0000 Received: (qmail 29657 invoked from network); 16 Jul 2000 22:37:18 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Jul 2000 22:37:18 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 16 Jul 2000 22:37:18 -0000 Received: from f-cpu.org (Raspail-3-17.club-internet.fr [195.36.203.17]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13815 for ; Mon, 17 Jul 2000 00:37:15 +0200 (MET DST) Message-ID: <397238FA.ADAE5F7E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007161821.e6GILxD20447@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 00:36:42 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f1619e17d6219bdfadae008f2cfc46ba Status: R X-Status: N Rares Marian wrote:
> Yann Guidon <whygee@f-cpu.org> wrote:
<snip>
> I don't know if it's possible without designing new ICs.  Or turning cache on its head.
> This memory bottleneck is a lot like Token Ring versus Ethernet.  With token ring you've
> got one frame of data moving on the whole network. Slow as all hell.
>
> Now let's see:
> Albert's global registers do allow threads to allocate extra registers.  There's a point where
> some threads have access to their local registers and lower priority threads get the global regs.
>  It puts pressure on either the OS or the compiler.
<snip>
> You could call this partial cascaded windowing. :)
>
> And there is no reason Albert's setup can't be adapted to this.  Perhaps we could use Albert's setup as a high load mode.

i don't see where this register thing could solve the memory bandwidth problem.
let's have some mathematics :
each thread T uses in average 1 byte of memory per instruction, and each instruction is
4 bytes each (and may not be in the cache too).

Now, SMT comes and we have N threads so we need N*5 bytes of bandwidth instead of only 5.
that's where my conceptual problem lies.

SMT is designed to shadow the latencies of a very deep pipeline, not to reduce the bandwidth,
but the contrary. The bandwidth problem is even greater and the big problem is not latency
or bandwidth, but the ability to have a lot of instructions in fly, just like memory
addresses in a pipelined memory system ("transactional").

i know that SMT is a very interesting feature, but i'm puzzled now. the CPU cores simply go TOO FAST
and cache misses can never be avoided.

> >WHYGEE
> Rares
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00319 for ; Mon, 17 Jul 2000 17:00:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:31 +0200 (MEST) Received: (qmail 6776 invoked by uid 0); 16 Jul 2000 23:56:33 -0000 Received: from ml.egroups.com (208.50.99.214) by mx02.gmx.net with SMTP; 16 Jul 2000 23:56:33 -0000 X-eGroups-Return: sentto-1101623-480-963791788-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 17 Jul 2000 00:56:32 -0000 Received: (qmail 25715 invoked from network); 16 Jul 2000 23:56:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 16 Jul 2000 23:56:27 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 16 Jul 2000 23:56:27 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000716235627.FBPM24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 16:56:27 -0700 Message-ID: <39724BAA.3D5DBCEC@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007161821.e6GILxD20447@tbird.iworld.com> <397238FA.ADAE5F7E@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 16:56:38 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 402cb8d81dd398394a0ee1ccc5ecf721 Status: R X-Status: N Aaargh!  Use your imagination, Whygee!
>8{


Yann Guidon wrote:

> Rares Marian wrote:
> > Yann Guidon <whygee@f-cpu.org> wrote:
> <snip>
>
> > Now let's see:
> > Albert's global registers do allow threads to allocate extra registers.  There's a point where
> > some threads have access to their local registers and lower priority threads get the global regs.
> >  It puts pressure on either the OS or the compiler.
> <snip>
> > You could call this partial cascaded windowing. :)
> >
> > And there is no reason Albert's setup can't be adapted to this.  Perhaps we could use Albert's setup as a high load mode.
>
> i don't see where this register thing could solve the memory bandwidth problem.
> let's have some mathematics :
> each thread T uses in average 1 byte of memory per instruction, and each instruction is
> 4 bytes each (and may not be in the cache too).
>
> Now, SMT comes and we have N threads so we need N*5 bytes of bandwidth instead of only 5.
> that's where my conceptual problem lies.
>
> SMT is designed to shadow the latencies of a very deep pipeline, not to reduce the bandwidth,
> but the contrary. The bandwidth problem is even greater and the big problem is not latency
> or bandwidth, but the ability to have a lot of instructions in fly, just like memory
> addresses in a pipelined memory system ("transactional").
>
> i know that SMT is a very interesting feature, but i'm puzzled now. the CPU cores simply go TOO FAST
> and cache misses can never be avoided.
>

Okay okay okay, okay?  Remember that during any long running process, you are currently spending about 50% of your time
waiting for main memory (let alone caching), though some contend that we are already spending 70-80% of our time waiting for
DRAMs.

While the processor is waiting, nothing is happening at L1, either.  During that time, you could be doing something else.

As far as L2/L3 is concerned, systems currently address the problem by loading in an entire page (4KB), based on the locality
idea that more accesses will be made to that page.  That much is speculative work.  Less speculative is to handle another
thread's misses instead, justifying a smaller page size represented in cache.  This reduces the demand for frontside
bandwidth.  We could follow up by loading in the rest of the page later, or just depend more on prefetching.

Closer to the processor, L1 bandwidth currently goes unused during that 60ns wait time.  Since the processor is active less
than 50% of the time, L1 and L0 bandwidth go unused most of the time.  With a MT design, it gets to make use of that bandwidth
while the memory system is working on something else.  You actually get much closer to peak utilization, here, and the whole
memory system gets used at run time.

Your argument that cpu cores are TOO FAST is valid only for single-threaded processors.  Cache misses cannot be avoided, but
they don't have to produce stalls.  MT gives the whole system more work to chew on, even while a lower level of cache is
looking for something it misplaced.

A 4-way 1GHz processor has a peak execution rate of 4 BIPS, but will spend most of those cycles waiting for memory.
Increasing it to 8-way and adding more registers will tend to slow it to around 700MHz, 500 or so with sufficient dynamic
prediction and scheduling to feed it.  The "register thing" allows for seemless switching of tasks in spite of very short
stalls.

> > >WHYGEE
> > Rares
> WHYGEE

--Maxx

For all of the administration's failures over the last eight years, have we ever heard Bill Clinton say, "I take full
responsibility for..."?
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00322 for ; Mon, 17 Jul 2000 17:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:32 +0200 (MEST) Received: (qmail 10259 invoked by uid 0); 17 Jul 2000 00:21:33 -0000 Received: from ci.egroups.com (207.138.41.176) by mx12.rz2.gmx.net with SMTP; 17 Jul 2000 00:21:33 -0000 X-eGroups-Return: sentto-1101623-481-963793290-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 17 Jul 2000 00:21:31 -0000 Received: (qmail 26662 invoked from network); 17 Jul 2000 00:21:29 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 17 Jul 2000 00:21:29 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 17 Jul 2000 00:21:29 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000717002129.FMFK24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 17:21:29 -0700 Message-ID: <39725189.76814F74@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <001401bfef3f$627e84a0$9afe66ca@public.zz.ha.cn> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 17:21:41 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Reading-list Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5c7131e2662ac0c4487cd019ce18e21 Status: R X-Status: N >Hi
>   Now i found i can't follow your discussions because i know a little
about >design chip.I want to
>know that i must to learn ,
>example documents,manual,books... So, i need your help.
>
>   Thanks!
>   Liu

Well, here are some definitions and facts.

CISC - like Intel's x86 processors, uses elaborate decode and a
memory-memory instruction set architecture intended

RISC- Reduced Instruction Set Computer. A class of register-register
designs that
simplify the hardware by making the compiler schedule the instruction
stream.  Modern "RISC" processors are getting very complicated, with
register renaming and dynamic scheduling, which increases the number of
machine states, the complexity of the hardware, thereby reducing the
clock rate in order to gain a better CPI.

VLIW - Very Long Instruction Word, a kind of processor with no decode,
usually targetted toward very wide implementations without absorbing the
huge penalty of run time checking.  The compiler explicitly states in
one instruction word what can and cannot be issued in a given clock
cycle.

Multi-threading - a technique in which a single processor or integrated
set of processors is given many tasks to handle at once in order to fill
general or pipeline stalls, thereby keeping the hardware busy, even with
branching code.

There, that's all you need to know about this discussion.  I would
recommend P&H HW/SW Interface.  It's everything you ever wanted to know
about microprocessor design and more.  If you have any specific
questions, I'm sure that anyone on this list would be more than happy to
take them.

And DEFINITELY, don't be afraid to offer suggestions.  Good ideas come
>from new people who don't yet know what is impossible.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00325 for ; Mon, 17 Jul 2000 17:00:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:33 +0200 (MEST) Received: (qmail 13409 invoked by uid 0); 17 Jul 2000 00:27:26 -0000 Received: from f19.egroups.com (207.138.41.182) by mx12.rz2.gmx.net with SMTP; 17 Jul 2000 00:27:26 -0000 X-eGroups-Return: sentto-1101623-482-963793639-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 17 Jul 2000 00:27:25 -0000 Received: (qmail 25388 invoked from network); 17 Jul 2000 00:27:19 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 17 Jul 2000 00:27:19 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 17 Jul 2000 00:27:18 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6H0Sa201326; Sun, 16 Jul 2000 20:28:36 -0400 Message-Id: <200007170028.e6H0Sa201326@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 20:28:36 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 157c531cb401c5b9de40754f8fb3c251 Status: R X-Status: N Yann Guidon <whygee@f-cpu.org> wrote:

>i don't see where this register thing could solve the memory bandwidth problem.
>let's have some mathematics :
>each thread T uses in average 1 byte of memory per instruction, and each instruction is
>4 bytes each (and may not be in the cache too).
>
>Now, SMT comes and we have N threads so we need N*5 bytes of bandwidth instead of only 5.
>that's where my conceptual problem lies.
I can't see how to do it without a bizarre hack.
We can't just use an internal RLE compression scheme.
The popular way to deal with this sort of thing is to
make it more complicated then make most of the
complications harmless.

I'd rather just underclock the chip.  It's less bloody.

But let's suppose we did try to fix this.

Each register passes its contents along to a particular
destination where it eventually gets stored.  Inter-register
routing rather than hardwired decoding would get your data
to where it needed to be.

Look at it like a chess board... 1a - 7i.  The first column might be:
R1, R10, R19, R28, R37, R46, R55.  If we talk about several instructions allocating registers in the first column, R1 would go first.  R10 could be in flight almost at the same time as R1 because R1 keeps going further while R10 stops sooner.  Again this requires creating a bouncing register.  I don't at the moment know what that would look like.

Now the critical part is this: We can use the register bounce to move
data between registers and execution units.

Rather than a wire to each register, you would have a stop on the way.

The problem is we have a new concept: Instructions we can't execute right now might be able to be constantly in flight.    

Oh and something else:
When I begin a project I clear my work space and then "cycles" later I do my work.

Maybe we can create a chip from that point of view?

>> >WHYGEE
>>Rares
>WHYGEE
Rares

Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00328 for ; Mon, 17 Jul 2000 17:00:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:34 +0200 (MEST) Received: (qmail 1010 invoked by uid 0); 17 Jul 2000 00:36:33 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 17 Jul 2000 00:36:33 -0000 X-eGroups-Return: sentto-1101623-483-963794187-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 17 Jul 2000 00:36:30 -0000 Received: (qmail 2198 invoked from network); 17 Jul 2000 00:36:26 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Jul 2000 00:36:26 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 17 Jul 2000 00:36:26 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6H0bi201604; Sun, 16 Jul 2000 20:37:44 -0400 Message-Id: <200007170037.e6H0bi201604@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 20:37:44 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b94c8de1305c3db4aeb1496ffe3fde3c Status: R X-Status: N Albert Abramson <maxx@nventure.com> wrote:

>Aaargh!  Use your imagination, Whygee!

>Closer to the processor, L1 bandwidth currently goes unused during that 60ns wait time.  Since the processor is active less
>than 50% of the time, L1 and L0 bandwidth go unused most of the time.  >Your argument that cpu cores are TOO FAST is valid only for single-threaded processors.  Cache misses cannot be avoided, but
>they don't have to produce stalls.  MT gives the whole system more work to chew on, even while a lower level of cache is
>looking for something it misplaced.

That's the problem.  The chip has no room for all that work if you want to process multiple threads at the same time.  Or do you just intend to schedule multiple threads at the same time.

>A 4-way 1GHz processor has a peak execution rate of 4 BIPS, but will spend most of those cycles waiting for memory.
>Increasing it to 8-way and adding more registers will tend to slow it to around 700MHz, 500 or so with sufficient dynamic
>prediction and scheduling to feed it.  The "register thing" allows for seemless switching of tasks in spite of very short
>stalls.

Thanks, but whygee is speaking of bandwidth problems on the chip itself.  It's great to have a ton of threads.  It sucks if you can't do shit because there's no flight spcae.  I'd argue he's coming from the position of using your idea and having it fail because it works to well.

>> > >WHYGEE
>> > Rares
>> WHYGEE
>
>--Maxx
Rares

Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00331 for ; Mon, 17 Jul 2000 17:00:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:35 +0200 (MEST) Received: (qmail 17619 invoked by uid 0); 17 Jul 2000 00:55:34 -0000 Received: from jj.egroups.com (208.50.144.82) by mx02.gmx.net with SMTP; 17 Jul 2000 00:55:34 -0000 X-eGroups-Return: sentto-1101623-484-963795330-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 17 Jul 2000 00:55:31 -0000 Received: (qmail 26813 invoked from network); 17 Jul 2000 00:55:30 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 17 Jul 2000 00:55:30 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 17 Jul 2000 00:55:30 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000717005526.FZEM24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 17:55:26 -0700 Message-ID: <3972597D.CDC16BC@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 17:55:39 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 29c6c63e4a5bc7391cd541b174b26eb2 Status: R X-Status: N Rares Marian wrote:

> Albert Abramson <maxx@nventure.com> wrote:
>
> >Aaargh!  Use your imagination, Whygee!
>
> >Closer to the processor, L1 bandwidth currently goes unused during that 60ns wait time.  Since the processor is active less
> >than 50% of the time, L1 and L0 bandwidth go unused most of the time.  >Your argument that cpu cores are TOO FAST is valid only for single-threaded processors.  Cache misses cannot be avoided, but
> >they don't have to produce stalls.  MT gives the whole system more work to chew on, even while a lower level of cache is
> >looking for something it misplaced.
>
> That's the problem.  The chip has no room for all that work if you want to process multiple threads at the same time.  Or do you just intend to schedule multiple threads at the same time.
>

Less room for each thread, that's why I allocate just 8 address and 8 data regs per thread.  The caches tend to share a lot of what's in the caches, so there isn't too much of a problem with that.

>
> >A 4-way 1GHz processor has a peak execution rate of 4 BIPS, but will spend most of those cycles waiting for memory.
> >Increasing it to 8-way and adding more registers will tend to slow it to around 700MHz, 500 or so with sufficient dynamic
> >prediction and scheduling to feed it.  The "register thing" allows for seemless switching of tasks in spite of very short
> >stalls.
>
> Thanks, but whygee is speaking of bandwidth problems on the chip itself.  It's great to have a ton of threads.  It sucks if you can't do shit because there's no flight spcae.  I'd argue he's coming from the position of using your idea and having it fail because it works to well.

I'm not sure what you mean.  Once the compromises have been made, multithreaded processors have worked quite well; e.g., Tera, though that uses many threads in order to keep busy from one access to the next.

Multi-threading works.  There are problems to solve.  Max out the bandwidth, adjust the page and block size, recalulate the cache sizes, etc.  You end up with a pretty good processor that runs fast even with just two active threads.

>
>
> >> > >WHYGEE
> >> > Rares
> >> WHYGEE
> >
> >--Maxx
> Rares
>

Maxx Power

>
> Windows the other 70's technology.
> ----------------------
> Do you do Linux? :)
> Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
>
> ------------------------------------------------------------------------
> The future belongs to Wireless.
> Learn Wireless Development Now!
> http://click.egroups.com/1/6355/1/_/3462/_/963794187/
> ------------------------------------------------------------------------
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00334 for ; Mon, 17 Jul 2000 17:00:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:36 +0200 (MEST) Received: (qmail 10770 invoked by uid 0); 17 Jul 2000 01:12:32 -0000 Received: from ci.egroups.com (207.138.41.176) by mx02.gmx.net with SMTP; 17 Jul 2000 01:12:32 -0000 X-eGroups-Return: sentto-1101623-485-963796347-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 17 Jul 2000 01:12:27 -0000 Received: (qmail 22292 invoked from network); 17 Jul 2000 01:12:26 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 17 Jul 2000 01:12:26 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 17 Jul 2000 01:12:26 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6H1DiS02601; Sun, 16 Jul 2000 21:13:44 -0400 Message-Id: <200007170113.e6H1DiS02601@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 21:13:44 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64c9cbeeb17d62ff734bb06ca52740b1 Status: R X-Status: N Albert Abramson <maxx@nventure.com> wrote:

>Rares Marian wrote:
>
>> Albert Abramson <maxx@nventure.com> wrote:
>>
>Less room for each thread, that's why I allocate just 8 address and 8 data regs per thread.  The caches tend to share a lot of what's in the caches, so there isn't too much of a problem with that.

Okay this is how it works see:

We're not talking about storage space.  We're talking about wire space.
If I've got 5 instructions operating at the same time I need 5x the wires.
I need 5x the execution units.  The point is your idea is good, it just has a ceiling.  A ceiling that may not allow filling the wait time with threads.

We need numbers to see how it works.  What you say we code something?

>>
>> >A 4-way 1GHz processor has a peak execution rate of 4 BIPS, but will spend most of those cycles waiting for memory.
>> >Increasing it to 8-way and adding more registers will tend to slow it to around 700MHz, 500 or so with sufficient dynamic
>> >prediction and scheduling to feed it.  The "register thing" allows for seemless switching of tasks in spite of very short
>> >stalls.
>>
>> Thanks, but whygee is speaking of bandwidth problems on the chip itself.  It's great to have a ton of threads.  It sucks if you can't do shit because there's no flight spcae.  I'd argue he's coming from the position of using your idea and having it fail because it works to well.
>
>I'm not sure what you mean.  Once the compromises have been made, multithreaded processors have worked quite well; e.g., Tera, though that uses many threads in order to keep busy from one access to the next.

>Multi-threading works.  There are problems to solve.  Max out the bandwidth, adjust the page and block size, recalulate the cache sizes, etc.  You end up with a pretty good processor that runs fast even with just two active threads.

Okay let's code this thing.  Methinks we al protest too much.

By the way whatever happened to Matthias?
>>
>>
>> >> > >WHYGEE
>> >> > Rares
>> >> WHYGEE
>> >
>> >--Maxx
>> Rares
>>
>
>Maxx Power

Rares


Windows the other 70's technology.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00343 for ; Mon, 17 Jul 2000 17:00:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:38 +0200 (MEST) Received: (qmail 22644 invoked by uid 0); 17 Jul 2000 03:07:36 -0000 Received: from fl.egroups.com (208.50.144.74) by mx06.rz2.gmx.net with SMTP; 17 Jul 2000 03:07:36 -0000 X-eGroups-Return: sentto-1101623-486-963803248-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 17 Jul 2000 03:07:29 -0000 Received: (qmail 30289 invoked from network); 17 Jul 2000 03:07:27 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 17 Jul 2000 03:07:27 -0000 Received: from unknown (HELO ms1.tomail.com.tw) (210.200.129.221) by mta1 with SMTP; 17 Jul 2000 03:07:25 -0000 Received: (qmail 48427 invoked from network); 17 Jul 2000 03:08:06 -0000 Received: from h45.s38.ts32.hinet.net (HELO nt021) (163.32.38.45) by ms1.tomail.com.tw with SMTP; 17 Jul 2000 03:08:06 -0000 Message-ID: <003f01bfef9c$2faf0880$0301fea9@nt021> To: References: <001401bfef3f$627e84a0$9afe66ca@public.zz.ha.cn> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 11:05:48 +0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Reading-list Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BFEFDE.F6B4B780" X-UIDL: 1263e9dc4b916e81ad0cd994706aff9f Status: R X-Status: N ------=_NextPart_000_000C_01BFEFDE.F6B4B780 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi =20 Now i found i can't follow your discussions because i know a little = about design chip.I want to know that i must to learn , example documents,manual,books... So, i need your help.=20 =20 Thanks! Liu =20 -------------------------------------------------------------------------= ----- Follow Test ! If You can see this ,Ur post is ok=20 http://www.f-cpu.de -------------------------------------------------------------------------= ----- ------=_NextPart_000_000C_01BFEFDE.F6B4B780 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
 

Hi  
   Now i found i can't follow your discussions because i know a little about design chip.I want to know that i must to learn ,
example documents,manual,books... So, i need your help.
   
   Thanks!
   Liu
                     
------=_NextPart_000_000C_01BFEFDE.F6B4B780-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00349 for ; Mon, 17 Jul 2000 17:00:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:40 +0200 (MEST) Received: (qmail 28416 invoked by uid 0); 17 Jul 2000 06:18:54 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 17 Jul 2000 06:18:54 -0000 X-eGroups-Return: sentto-1101623-487-963814727-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 17 Jul 2000 06:18:46 -0000 Received: (qmail 31651 invoked from network); 17 Jul 2000 06:18:46 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Jul 2000 06:18:46 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 17 Jul 2000 06:18:46 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000717061845.LJID24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 16 Jul 2000 23:18:45 -0700 Message-ID: <3972A545.B628176A@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170113.e6H1DiS02601@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 16 Jul 2000 23:18:51 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd7aa90a0d0f44be17306f191d01fca7 Status: R X-Status: N 
>Rares Marian wrote:
>
>> Albert Abramson wrote:
>>
>Less room for each thread, that's why I allocate just 8 address and 8 data
regs per thread.  The caches tend to share a lot of what's in the caches, so
there isn't too much of a problem with that.

Okay this is how it works see:

We're not talking about storage space.  We're talking about wire space.
If I've got 5 instructions operating at the same time I need 5x the wires.
I need 5x the execution units.  The point is your idea is good, it just has a
ceiling.  A ceiling that may not allow filling the wait time with threads.
I dunno if you were around when we talked about the three types of MT.
1. one thread per processor, multiple processors
2. multiple threads per processor, filling each others' pipeline stalls
3. multiple threads per processor, filling each others' general stalls

I've been talking VLIW, so that means no dynamic scheduling, ruling out no.2.  No. 1 is doable, and I've favored that to one large processor, but no. 3 is the solution I've been offering for making use of the processor during wait time.  This puts downward pressure on the time allowable for a context switch, but that's no biggy.

I've tended to favor narrow, statically scheduled processors because of the obstacles to extracting further ILP.  Those techniques that are effective either dull the clock, force the compiler to work for days, instead of hours, and

Maxx's Law: Each additional IPC you want to squeeze through one program counter doubles the amount of time spent compiling and optimizing an application.

The fact is, software developers are only willing to compromise software development so much in order to make their applications run more efficiently.  Any further improvements in code will depend on dynamic optimization software running on the client machine.

No.2 is possible, but it means dynamic hardware scheduling, fully interlocking pipelines, and much more decode hardware.
  

We need numbers to see how it works.  What you say we code something
I also offered a generic programming example with a dynamic function call followed by two static function calls, with no certainty of the outcome of the DLL from the compiler's vantage point.

OH NO, I'M A NERD!!!!!!!!

Oh, well.

Anywhose, any code fragment to prove the usefulness of this would have to be big.  However, assume the following code fragments load-stores are all probable misses.

load r1, A2, imm
complt r2, r3, r4
.
load r5, A2, imm
cmovlt r5,

well anyway, I'm tired of coding.  The point is, the stuff on the other side of that stall can be spawned before that load, those operations that are likely to be needed after the stall (after a few conditions have been tested) can be left as background work to be handled during stalls. (The previous example shows off some of the limiting effect of a small register file, and also the ability to hand off some of that work to another rf.)

Proving the workability of this depends of very large code fragments.  Still, here it is in a generic sense.

MSSomeCrappyMSCode(someval);

MyFunc(somenum);
SomeoneElsesFunc(nuthernum);

MSAnotherCrappyFunc(anotherval);

Oddviously, we have no idea what the dynamic functions are going to do or if it will EVER give MyFunc control of the cpu again.  Since the compiler can't even insert prefetches for DLL's, it can set MyFunc() and SomeoneElsesFunc() in the ready queue by moving their start addresses into the appropriate registers (maybe the global address registers, eh?) and icbt'ing them for the ICACHE.  Since MSAnotherCrappyFunc()'s sources are indeterminant, we can't just spawn it as a thread.  If operands need to be passed among these threads the global registers act as an efficient way of doing just that.  Condition fields associated with each data register offer a sticky Update bit to let the accepting thread know whether or not the value has been returned yet.

Well, that's probably more information than you wanted.  However, if more info is desired, go to Cray's Web site and look at details of the Cray MTA.  Each processor is able to represent 128 threads (virtual processors), far more than the 7 I've proposed.  With fast, efficient message passing, it gets relatively easy to break large programs up into many horizontal threads; hence the flat register space, one-cycle context switch, and zero-overhead message passing.  Threads smaller than 20 instructions can be spawned to fill upcoming general stalls.  This creates many opportunities for the compiler to find parallelism where it would be difficult or impossible to integrate into a static instruction stream.

--Maxx

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00379 for ; Mon, 17 Jul 2000 17:00:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 17:00:46 +0200 (MEST) Received: (qmail 2852 invoked by uid 0); 17 Jul 2000 10:27:42 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 17 Jul 2000 10:27:42 -0000 X-eGroups-Return: sentto-1101623-488-963829656-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 17 Jul 2000 10:27:40 -0000 Received: (qmail 31722 invoked from network); 17 Jul 2000 10:27:35 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Jul 2000 10:27:35 -0000 Received: from unknown (HELO goliath.siemens.de) (194.138.37.131) by mta1 with SMTP; 17 Jul 2000 10:27:35 -0000 X-Envelope-Sender-Is: emstud2@hl.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e6HARUB29116 for ; Mon, 17 Jul 2000 12:27:30 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6HARQB05456 for ; Mon, 17 Jul 2000 12:27:26 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id MAA20009 for ; Mon, 17 Jul 2000 12:27:26 +0200 (MET DST) Received: from hl.siemens.de (klee.hl.siemens.de [172.29.25.116]) by christl.hl.siemens.de (8.9.3+Sun/8.9.3) with ESMTP id MAA04133 for ; Mon, 17 Jul 2000 12:27:23 +0200 (MET DST) Sender: emstud2@hl.siemens.de Message-ID: <3972DF8D.B598BE9B@hl.siemens.de> X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3971A17F.B66595D@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 12:27:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7c8ce16c40a7db377397284daca136dc Status: R X-Status: N Yann Guidon wrote:
>
> hi,
>
> i've been thinking about SMT for quite a while now...
> and Albert's reason for using it is that it reduces the
> impact of the memory latency and bandwidth.
>
> but now, if you have N tasks/threads each accessing
> memory, don't you simply displace the problem ?
> if all your threads have cache misses, the core stalls.
> i believe that there's something to solve here.
> We can criticize OOO but it solved this problem.
> ideas are welcome (realistic ideas preferred).
>

With SMT, the idea is to beg that the cache have the data for the next
thread and during a wait, this thread is run. You have more chance not
"to stall".But the bandwith will always be the bottleneck.

Recently i have read some benchs in the tom hardwar's site for memory
bandwidth for the different x86 core. All the bench show a speed of ~500
MByte/s. It's the half of the theoritical maximum. So we can try to
increase the efficiency of the management of the memory. We can create
specific instruction to manage caches.

Each SDRAM have 4 banks, so you can interleave 4 address demands and use
burst mode to fill the cache. An intelligent L/S unit could mix the
request from the different threads.

nicO
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01500 for ; Mon, 17 Jul 2000 22:35:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 22:35:46 +0200 (MEST) Received: (qmail 3470 invoked by uid 0); 17 Jul 2000 18:03:58 -0000 Received: from cj.egroups.com (208.50.144.68) by mx02.gmx.net with SMTP; 17 Jul 2000 18:03:58 -0000 X-eGroups-Return: sentto-1101623-490-963857033-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 17 Jul 2000 18:03:56 -0000 Received: (qmail 14435 invoked from network); 17 Jul 2000 18:03:53 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Jul 2000 18:03:53 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta1 with SMTP; 17 Jul 2000 18:03:53 -0000 Received: from modem-5.magnesium.dialup.pol.co.uk ([62.136.11.5] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13EFEj-000350-00 for f-cpu@egroups.com; Mon, 17 Jul 2000 19:03:26 +0100 Sender: root@pop.gmx.net Message-ID: <39734CF6.8868C109@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 19:14:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 068eea6ad02348337e0a38e32c336bf9 Status: R X-Status: N Albert Abramson wrote:

> Rares Marian wrote:
>
> > Albert Abramson <maxx@nventure.com> wrote:
> >
> > >Aaargh!  Use your imagination, Whygee!
> >
> > >Closer to the processor, L1 bandwidth currently goes unused during that 60ns wait time.  Since the processor is active less
> > >than 50% of the time, L1 and L0 bandwidth go unused most of the time.  >Your argument that cpu cores are TOO FAST is valid only for single-threaded processors.  Cache misses cannot be avoided, but
> > >they don't have to produce stalls.  MT gives the whole system more work to chew on, even while a lower level of cache is
> > >looking for something it misplaced.
> >
> > That's the problem.  The chip has no room for all that work if you want to process multiple threads at the same time.  Or do you just intend to schedule multiple threads at the same time.
> >
>
> Less room for each thread, that's why I allocate just 8 address and 8 data regs per thread.  The caches tend to share a lot of what's in the caches, so there isn't too much of a problem with that.
>
> >
> > >A 4-way 1GHz processor has a peak execution rate of 4 BIPS, but will spend most of those cycles waiting for memory.
> > >Increasing it to 8-way and adding more registers will tend to slow it to around 700MHz, 500 or so with sufficient dynamic
> > >prediction and scheduling to feed it.  The "register thing" allows for seemless switching of tasks in spite of very short
> > >stalls.
> >
> > Thanks, but whygee is speaking of bandwidth problems on the chip itself.  It's great to have a ton of threads.  It sucks if you can't do shit because there's no flight spcae.  I'd argue he's coming from the position of using your idea and having it fail because it works to well.
>
> I'm not sure what you mean.  Once the compromises have been made, multithreaded processors have worked quite well; e.g., Tera, though that uses many threads in order to keep busy from one access to the next.
>
> Multi-threading works.  There are problems to solve.  Max out the bandwidth, adjust the page and block size, recalulate the cache sizes, etc.  You end up with a pretty good processor that runs fast even with just two active threads.

Perhaps it is time to start putting together some C++ ,models of the processor.I think we should start with some primitives of the type OR/AND/NOT and a LATCH
perhaps also a TRISTATE buffer. Therefore each electrical node should have 3 states (can be
char or an enumerated type, of 1,0 and X for tristate).

Connecting the nodes up ....  perhaps
==========================================================

NODE a,b,c,d,e;
// NODE is enumerated type so could have          unsigned int a,b,c,d,e instead         etc etc

ORGATE o1(a,b,c);    // in1 in2 out1
LATCH l1(c,d,e);    //data clk out

File *datafile = fopen ("/root/mydatafile.txt","r");
File *outfile = fopen ("/root/mydatafile.txt","w");

while not(feof(datafile)) {
         fscanf(datafile,"%d %d %d",&a,&b,&d); // orgate in1 and 2 and latch clock
         o1.process();
         l1.process();
         printf(outfile,"%d %d \n\r",c,e);
};

fclose(datafile);
fclose(outfile);


//ORGATE and LATCH are classes where const pointers are passed in at init time,
//and perform the function when process(); is called.

//alternatively, all components could be added to an array (like CArray in VC), and at process time,
//all compents enumerated, with object->process() called..



Comments please..??

I know ultimately we have to get the design into VHDL, but C++ is available on most Linux systems.
We need to start building components into circuits like the above.

Jeff Davies
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01503 for ; Mon, 17 Jul 2000 22:35:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 17 Jul 2000 22:35:47 +0200 (MEST) Received: (qmail 2241 invoked by uid 0); 17 Jul 2000 18:24:20 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 17 Jul 2000 18:24:20 -0000 X-eGroups-Return: sentto-1101623-491-963858179-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 17 Jul 2000 18:23:09 -0000 Received: (qmail 7919 invoked from network); 17 Jul 2000 18:22:59 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 17 Jul 2000 18:22:59 -0000 Received: from unknown (HELO mail1.digital.com) (204.123.2.50) by mta1 with SMTP; 17 Jul 2000 18:22:59 -0000 Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id LAA02014 for ; Mon, 17 Jul 2000 11:22:59 -0700 (PDT) Received: by pachyderm.pa.dec.com; id LAA29392; Mon, 17 Jul 2000 11:22:58 -0700 (PDT) Message-Id: <200007171822.LAA29392@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client srcdhcp96-134.pa.dec.com, user sebot) To: f-cpu@egroups.com In-Reply-To: <39734A4B.232E13D9@f-cpu.org> X-eGroups-From: sebot@pa.dec.com (Julien Sebot) From: sebot@pa.dec.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 11:22:58 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 84642ce0095093e2732c8249b675109f Status: R X-Status: N Hi,
The current topic is SMT and memory bandwidth, with current memory  bus
implementations for the x86 architecture,  a lot of applications are already
limited by memory bandwidth. SMT is a well known technique used for improving
the ILP and recovering memory latency by computations (which was already
the goal of OOO execution). The biggest problem with SMT (out of the core
s complexity) is that you need an increased memory bandwidth which is
generally available at high costs and advanced thread scheduling techniques
to avoid multiple thread access the main memory simultaneously. Non
simultaneous multithreading has been implemented in the TERA machine but
needs a lot of threads (more than 100) to be  efficient and very efficient
context switching techniques.

I don t know if you have already talked of decoupling the memory access
>from the computations, but it is a very efficient technique for non integer
computations (the address computations can be easily found).

I think that discussing about SMT is very interressant but that the
requirements of SMT in term of complexity are maybe a little high for a first
free CPU implementation.
--
Sebot Julien
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00300 for ; Tue, 18 Jul 2000 17:03:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:28 +0200 (MEST) Received: (qmail 21456 invoked by uid 0); 17 Jul 2000 21:54:11 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 17 Jul 2000 21:54:11 -0000 X-eGroups-Return: sentto-1101623-492-963870846-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 17 Jul 2000 21:54:09 -0000 Received: (qmail 559 invoked from network); 17 Jul 2000 21:54:06 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Jul 2000 21:54:06 -0000 Received: from unknown (HELO hi.egroups.com) (10.1.10.41) by mta1 with SMTP; 17 Jul 2000 21:54:06 -0000 X-eGroups-Return: nicolas.boulay@ifrance.com Received: from [10.1.10.127] by hi.egroups.com with NNFMP; 17 Jul 2000 21:54:04 -0000 To: f-cpu@egroups.com Message-ID: <8kvv9r+54qn@eGroups.com> In-Reply-To: <39734CF6.8868C109@llandre.freeserve.co.uk> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster From: nicolas.boulay@ifrance.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 21:54:03 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f70875de14764b9db893edf43d396dd4 Status: R X-Status: N --- In f-cpu@egroups.com, Jeff Davies <jeff@l...> wrote:
> Albert Abramson wrote:
>
> > Rares Marian wrote:
> >
> > > Albert Abramson <maxx@n...> wrote:

> Connecting the nodes up ....  perhaps
> ==========================================================
>
> NODE a,b,c,d,e;
> // NODE is enumerated type so could have          unsigned int
a,b,c,d,e instead         etc etc
>
> ORGATE o1(a,b,c);    // in1 in2 out1
> LATCH l1(c,d,e);    //data clk out
>
> File *datafile = fopen ("/root/mydatafile.txt","r");
> File *outfile = fopen ("/root/mydatafile.txt","w");
>
> while not(feof(datafile)) {
>          fscanf(datafile,"%d %d %d",&a,&b,&d); // orgate in1 and 2
and latch clock
>          o1.process();
>          l1.process();
>          printf(outfile,"%d %d \n\r",c,e);
> };
>
> fclose(datafile);
> fclose(outfile);
>
>
> //ORGATE and LATCH are classes where const pointers are passed in
at
init time,
> //and perform the function when process(); is called.
>
> //alternatively, all components could be added to an array (like
CArray in VC), and at process time,
> //all compents enumerated, with object->process() called..
>
>
>
> Comments please..??
Euh,... you are [totaly] crazy ?
>
> I know ultimately we have to get the design into VHDL, but C++ is
available on most Linux systems.
> We need to start building components into circuits like the above.

The first step is to design the architecture: How is manage the
different units ? So in the (first) model, the '+' operation is a +
in
C++. But you can make a model cycle accurate. And then you can write
it in vhdl.

The units are caraterized by latencies only (in clock cycle). In my
mind, we are very far away from the gate level ! We can begin the
implementation of the different functionnal unit. But we didn't
need them to write the simulator (the only difference is the
latencies
of an operator).
>
> Jeff Davies
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00303 for ; Tue, 18 Jul 2000 17:03:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:29 +0200 (MEST) Received: (qmail 13188 invoked by uid 0); 17 Jul 2000 22:06:15 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 17 Jul 2000 22:06:15 -0000 X-eGroups-Return: sentto-1101623-493-963871571-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 17 Jul 2000 22:06:14 -0000 Received: (qmail 32209 invoked from network); 17 Jul 2000 22:06:11 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 17 Jul 2000 22:06:11 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 17 Jul 2000 22:06:11 -0000 Received: from f-cpu.org (Raspail-2-233.club-internet.fr [195.36.192.233]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA11067 for ; Tue, 18 Jul 2000 00:06:08 +0200 (MET DST) Message-ID: <39738329.67934489@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 00:05:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 282583273a641ac8e61d7b19f3ebb36f Status: R X-Status: N hi Jeff ! welcome back :-))))

Jeff Davies wrote:
> Albert Abramson wrote:
> > Rares Marian wrote:
> > > Albert Abramson <maxx@nventure.com> wrote:
> > > >Aaargh!  Use your imagination, Whygee!
sorry, i'm tired...

anyway, i think that it was a good idea to ask about the
SMT/bandwidth problem. it helped wake the list up.
but i wonder if we are "going the good way". It seems that
Albert's discussions, relayed by Rares, burry the work
that the list has done for one year on the FC0.
OK i know, it must be fun to design a CPU but it is no fun at all
to see that all our previous work is burried by a newcomer.
If we want to see our chip made, we'll have to stop babbling
all the time and MAKE things. we've completed one part of the work
for the FC0, and now we're thinking everything again for a new
stuff. i don't call this constructive.


> Perhaps it is time to start putting together some C++ ,models of the processor.
we've started to do this for the FC0 for a long time. There's even a GCC port
going on (see sourceforge).

> I think we should start with some primitives of the type OR/AND/NOT and a LATCH
> perhaps also a TRISTATE buffer. Therefore each electrical node should have 3 states (can be
> char or an enumerated type, of 1,0 and X for tristate).
<snip>
> Comments please..??

1) did you think about the synchronicity problems ?
will you simulate at the clock cycle level, or at the picosecond (thus having to
simulate the propagation delays etc...) ? in VHDL, i think it's the difference between
dataflow and (something else i don't remember its name).

2) isn't plain C easier to code ? i mean, instead of having an external text file,
the textfile should be the C source ... and we can directly use OR, AND, XOR etc,
without having to use the SLOW fscanf functions...

> I know ultimately we have to get the design into VHDL, but C++ is available on most Linux systems.
> We need to start building components into circuits like the above.

thank you for the effort :-)
of course using C is easier. my personal bias toward plain C instead of C++ is only a detail.
since we can't get OKAD and because Alliance is so difficult to master, C sims are a path
that we have already started to use. there are some sources, previously released on this
mailing, that simulate some Execution Units of the FC0.

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00306 for ; Tue, 18 Jul 2000 17:03:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:31 +0200 (MEST) Received: (qmail 26464 invoked by uid 0); 17 Jul 2000 22:07:05 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 17 Jul 2000 22:07:05 -0000 X-eGroups-Return: sentto-1101623-494-963871620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 17 Jul 2000 22:07:05 -0000 Received: (qmail 1938 invoked from network); 17 Jul 2000 22:07:00 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 17 Jul 2000 22:07:00 -0000 Received: from unknown (HELO ci.egroups.com) (10.1.2.81) by mta1 with SMTP; 17 Jul 2000 22:07:00 -0000 X-eGroups-Return: nicolas.boulay@ifrance.com Received: from [10.1.10.93] by ci.egroups.com with NNFMP; 17 Jul 2000 22:06:59 -0000 To: f-cpu@egroups.com Message-ID: <8l0020+9tmv@eGroups.com> In-Reply-To: <39734A4B.232E13D9@f-cpu.org> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster From: nicolas.boulay@ifrance.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 22:06:56 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8535648e2b8a8a6c5951bdd41cb64bd4 Status: R X-Status: N --- In f-cpu@egroups.com, Yann Guidon <whygee@f...> wrote:
> hi !
>
> Nicolas Boulay wrote:
> >
> > Yann Guidon wrote:
> > >
> > > hi,
> > >
> > > i've been thinking about SMT for quite a while now...
> > > and Albert's reason for using it is that it reduces the
> > > impact of the memory latency and bandwidth.
> > >
> > > but now, if you have N tasks/threads each accessing
> > > memory, don't you simply displace the problem ?
> > > if all your threads have cache misses, the core stalls.
> > > i believe that there's something to solve here.
> > > We can criticize OOO but it solved this problem.
> > > ideas are welcome (realistic ideas preferred).
> > >
> > With SMT, the idea is to beg that the cache have the data for the
next
> > thread and during a wait, this thread is run. You have more
chance
not
> > "to stall".But the bandwith will always be the bottleneck.
>
> Ok, Albert recently apologized for his claim, and we're getting
slowly
> closer to reality. it was a good idea to ask people...
>
> your comment about cache/noncache is interesting, might be a track
to follow.

Like with multi cpu design ?

>
> > Recently i have read some benchs in the tom hardwar's site for
memory
> > bandwidth for the different x86 core. All the bench show a speed
of ~500
> > MByte/s. It's the half of the theoritical maximum.
>
> let's see : 133MHz * 8 bytes ? around 1GB/s. now, if you run
constantly in
> a cached system, you need one half of the bandwidth to read the
data
and one
> other half for the cache spilling (write back the modified items).
this sounds
> logical for me, in a sense : i've been analysing CPU bandwidth for
almost
> two years now.
>
> > So we can try to increase the efficiency of the management of the
memory.
> > We can create specific instruction to manage caches.
> it's already existing. although it's rather generic, it exists.
> but i don't think that it's the best solution.
>
> i have included caching hints in the L/S instructions, i believe
that
> it is much more useful.
>
> > Each SDRAM have 4 banks, so you can interleave 4 address demands
and use
> > burst mode to fill the cache.
> ok, but as noted before : we need more than 4 ongoing transactions.
> does that mean that we must interleave the SDRAM DIMMs ? with 4
DIMMs
> we could have 16 ongoing transactions (but the electronics is
getting crazy).
>
And the number of wire and SDRAM bank, too! The problem is to send
good request at the goog time. Alwas to be at the maximum bandwidth.

> > An intelligent L/S unit could mix the request from the different
threads.
> that's not that complex, i think that we can do it. there might
even
be free
> IP for this in VHDL/Verilog.
>
Yes and no, because the idea is: a thread send a memory request and
then a second running thread send an other one. The L/s unit must
manage to interlace the call (and not only wait the answer of the
first request).
> furthermore, in the L/S instructions, we can explicitely specify 8
streams
> (incl. the default one) which can be directly mapped to SDRAM banks.
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00309 for ; Tue, 18 Jul 2000 17:03:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:32 +0200 (MEST) Received: (qmail 10077 invoked by uid 0); 17 Jul 2000 22:31:55 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 17 Jul 2000 22:31:55 -0000 X-eGroups-Return: sentto-1101623-495-963873104-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 17 Jul 2000 22:31:54 -0000 Received: (qmail 1052 invoked from network); 17 Jul 2000 22:31:44 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 17 Jul 2000 22:31:44 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 17 Jul 2000 22:31:43 -0000 Received: from welfen-netz.com [193.194.149.170] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 18 Jul 2000 00:29:58 +0200 Sender: kai@pop.gmx.net Message-ID: <3973FE90.516D974F@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 08:52:00 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2f95db51acb1b7087071ea036b87579e Status: R X-Status: N Jeff Davies wrote:
>
> Albert Abramson wrote:
[...]
> > Multi-threading works.  There are problems to solve.  M= ax out the bandwidth,
> > adjust the page and block size, recalulate the cache sizes, etc.&= nbsp; You end up
> > with a pretty good processor that runs fast even with just two ac= tive threads.
>
> Perhaps it is time to start putting together some C++ ,models of the p= rocessor.

Very good idea.  VERY good idea. (Though if speed turns out to be a pr= oblem we
may switch to a simple C/C++-"structs" model :^>

> I think we should start with some primitives of the type OR/AND/NOT an= d a LATCH

Cool, maybe take some primitive gates / standard cells from a library
of some "test case" process with delay specifications in ns, dime= nsions, etc.
(nand, nor, and, or, inverter, xor, nand3, muxes, latches, etc., things to = make
building a processor more easy.)  The cells could export "in"= ; and "out" ports or
so.  Wires should also have node characteristics as well as delay prop= erties
derived from a graphical "layout" front-end if preferred ?

Maybe a simulation based on idealized level changes would be good ?
E.g. a "port" gets notified of "high" or "undefine= d" or "low" with a "time"
argument as parameter.  The simulator would only drive the ports, I gu= ess.

The nodes (gates and wires) would be notified by its in-ports:
"gate.notify(this, time);" or similar =3D=B0)

Ports and nodes could carry names as well, for easier debugging.

> perhaps also a TRISTATE buffer. Therefore each electrical node should = have 3
> states (can be char or an enumerated type, of 1,0 and X for tristate).=
>
> Connecting the nodes up ....  perhaps
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> NODE a,b,c,d,e;
> // NODE is enumerated type so could have     =      unsigned int a,b,c,d,e instead   &n= bsp;     etc etc

A node index or what is this ?

> ORGATE o1(a,b,c);    // in1 in2 out1
> LATCH l1(c,d,e);    //data clk out
>
> File *datafile =3D fopen ("/root/mydatafile.txt","r&quo= t;);
> File *outfile =3D fopen ("/root/mydatafile.txt","w"= ;);
>
> while not(feof(datafile)) {
>          fscanf(datafile,= "%d %d %d",&a,&b,&d); // orgate in1 and 2 and latch c= lock
>          o1.process(); >          l1.process(); >          printf(outfile,&= quot;%d %d \n\r",c,e);
> };
>
> fclose(datafile);
> fclose(outfile);
>
> //ORGATE and LATCH are classes where const pointers are passed in at i= nit time,
> //and perform the function when process(); is called.

Or have a special latch/register kind which fakes/triggers i/o ?

> //alternatively, all components could be added to an array (like CArra= y in VC), and at process time,
> //all compents enumerated, with object->process() called..
>
> Comments please..??
>
> I know ultimately we have to get the design into VHDL, but C++ is avai= lable on most Linux systems.
> We need to start building components into circuits like the above.

I'd love to.  I tried to do it in Electric but laying out p and n tran= sistors
indivudally was a little too advanced for me with my weak semiconductor
background :)

kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00312 for ; Tue, 18 Jul 2000 17:03:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:33 +0200 (MEST) Received: (qmail 7666 invoked by uid 0); 17 Jul 2000 22:49:41 -0000 Received: from mq.egroups.com (207.138.41.138) by mx02.gmx.net with SMTP; 17 Jul 2000 22:49:41 -0000 X-eGroups-Return: sentto-1101623-496-963874171-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 17 Jul 2000 22:49:40 -0000 Received: (qmail 14689 invoked from network); 17 Jul 2000 22:49:26 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Jul 2000 22:49:26 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 17 Jul 2000 22:49:24 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA01942 for ; Mon, 17 Jul 2000 19:50:20 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39681EBE.10217@bjsmtp1.163.net> <00071416551003.00382@gandalf> <396FE2F1.F7AE7A18@f-cpu.org> In-Reply-To: <396FE2F1.F7AE7A18@f-cpu.org> Message-Id: <00071719415005.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 19:11:22 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cad (was: windows and threads) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9dee8bad5a18960530bbbf94c08957e8 Status: R X-Status: N > > Do you know the old AMD 29K processor? You could address any register
> > directly or use a kind of register window, depending on what you wanted
> > to do.
> i might have the databook somewhere... but that's not such an impressing CPU.
> it's cool for specific applications but there might be something missing
> for a general purpose CPU. i know there was one workstation based on it
> but that's not well known.

It was a very nice chip, but AMD was making so much more money from
their X86 related products that they dropped it. You might like the was
it handled registers, and the way it used software instead of hardware
to refill the MMU TLBs was interesting (MIPS had this too but with
hardware support, as did later Sparcs and most modern RISCs).

> look at the f-cpu manual ;-)

Thanks to Oliver I did read it, even if it wasn't quite the latest
version.

> take a look at the register number discussion and the SRB mechanism.

The PicoJava does something similar with its stack cache. Of course,
stack accesses are easier to predict right. I didn't fully understand
the SRB, though. If I am in the middle of task A, get a timer interrupt
and the OS decides to resume task B instead of returning to A will
everything be saved/restored properly? My impression was that some
things were going to the wrong place.

> OKAD

It is a pity that he keeps saying he hopes everyone will use his tools
but he doesn't give them away or even sell them for a reasonable price!
Forth people tend to be selfish that way, while we Self people really
help others go forth ;-)

I will make my own VLSI tools available (my old 1990 CMOS simulator
already is, for example), but that won't help many people until Self
runs on PCs (right now it runs on Sparcstations and Power Macintoshs).

> 0.8u ? i think we could do roughly 100MHz. but who am i to speak thusly
> when i haven't done it yet ?...

Some 0.8 micron CPUs (from
http://www.adoc-services.com/TechBrief/CPU9708.html):

  Intel 486DX 50 Mhz
  AMD am386 40 Mhz
  Intel 486DX2 66 Mhz
  Intel Pentium (BiCMOS) 66 Mhz

All faster chips used 0.6 micron or smaller processes, so I don't think
anybody but DEC (Alpha) got to 100 Mhz with this kind of process.

-- Jecel
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00324 for ; Tue, 18 Jul 2000 17:03:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:36 +0200 (MEST) Received: (qmail 427 invoked by uid 0); 18 Jul 2000 00:09:58 -0000 Received: from ci.egroups.com (207.138.41.176) by mx12.rz2.gmx.net with SMTP; 18 Jul 2000 00:09:58 -0000 X-eGroups-Return: sentto-1101623-498-963878989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 18 Jul 2000 00:09:56 -0000 Received: (qmail 5786 invoked from network); 18 Jul 2000 00:09:49 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Jul 2000 00:09:49 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 18 Jul 2000 00:09:48 -0000 Received: from welfen-netz.com [193.194.149.183] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 18 Jul 2000 02:09:25 +0200 Sender: kai@pop.gmx.net Message-ID: <397414FA.8E5823DF@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> <39738329.67934489@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 10:27:39 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 08395b9c2207f0d33f75ff4ec8d23b34 Status: R X-Status: N Yann Guidon wrote:
>
> hi Jeff ! welcome back :-))))
>
> Jeff Davies wrote:
> > Albert Abramson wrote:
> > > Rares Marian wrote:
> > > > Albert Abramson <maxx@nventure.com> wrote:
> > > > >Aaargh!  Use your imagination, Whygee!
> sorry, i'm tired...
>
> anyway, i think that it was a good idea to ask about the
> SMT/bandwidth problem. it helped wake the list up.
> but i wonder if we are "going the good way". It seems that > Albert's discussions, relayed by Rares, burry the work
> that the list has done for one year on the FC0.

Good point.  I don't see this happening, though.
The new stuff is just beeing discussed more actively because
it's in a less mature state.  And if we want FC1 to be sucessful
work should better start sooner then later.

I'd like to give it a try and design an int adder following
the rules put down in the FC0 manual.  This would then be given
to the group to take a look and lough at it (peer review).
But you said you had actually started one already ?

> OK i know, it must be fun to design a CPU but it is no fun at all
> to see that all our previous work is burried by a newcomer.
> If we want to see our chip made, we'll have to stop babbling
> all the time and MAKE things. we've completed one part of the work
> for the FC0, and now we're thinking everything again for a new
> stuff. i don't call this constructive.

Hmm, babbling about new stuff and completing FC0 is orthogonal to
me.  And as a side effect we get new ideas for FC0, e.g. "stalled= threads"-
multi-threading is a thing which could show useful for a classic RISC
(FC0) road as well - as could concurrent multi-threading/pipelined FUs,
but it seems not to be worth it to mention it every day again :=B0|

> > Perhaps it is time to start putting together some C++ ,models of = the processor.
> we've started to do this for the FC0 for a long time. There's even a G= CC port
> going on (see sourceforge).
>
> > I think we should start with some primitives of the type OR/AND/N= OT and a LATCH
> > perhaps also a TRISTATE buffer. Therefore each electrical node sh= ould have 3 states (can be
> > char or an enumerated type, of 1,0 and X for tristate).
> <snip>
> > Comments please..??
>
> 1) did you think about the synchronicity problems ?
> will you simulate at the clock cycle level, or at the picosecond (thus= having to
> simulate the propagation delays etc...) ?

The latter is the way to go IMHO.

> in VHDL, i think it's the difference between
> dataflow and (something else i don't remember its name).
>
> 2) isn't plain C easier to code ? i mean, instead of having an externa= l text file,
> the textfile should be the C source ... and we can directly use OR, AN= D, XOR etc,
> without having to use the SLOW fscanf functions...

- fscanf doesn't have to be used for scanning the file. "read" an= d
  a hand-made string scanner can be used if necessary.
- C or text files can be used for setting up the simulator; done only once,=
anyway.
- the input vector is easier to do in an external file I think, but
  it can be turned into a static for speed fanatics.
- in the high-level simulated units you can of course use ~, &, | and t= he like.

> > I know ultimately we have to get the design into VHDL, but C++ is= available on most Linux systems.
> > We need to start building components into circuits like the above= .
>
> thank you for the effort :-)
> of course using C is easier. my personal bias toward plain C instead o= f C++ is only a detail.

C++ has some nice points, e.g. you can write "inline" instead of = "__inline__"
which
is already saving some work.  You can also fetch yourself a cup of cof= fe during
compilation which may actually improve code.

> since we can't get OKAD and because Alliance is so difficult to master= , C sims are a path
> that we have already started to use. there are some sources, previousl= y released on this
> mailing, that simulate some Execution Units of the FC0.

Where can I dl them ?  www.mime...fr isn't in DNS it seems, what was t= he
alternate name again ?

> > Jeff Davies
> WHYGEE
[...]

kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00327 for ; Tue, 18 Jul 2000 17:03:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:38 +0200 (MEST) Received: (qmail 15068 invoked by uid 0); 18 Jul 2000 00:10:03 -0000 Received: from cj.egroups.com (208.50.144.68) by mx02.gmx.net with SMTP; 18 Jul 2000 00:10:03 -0000 X-eGroups-Return: sentto-1101623-497-963878989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by cj.egroups.com with NNFMP; 18 Jul 2000 00:10:02 -0000 Received: (qmail 27058 invoked from network); 18 Jul 2000 00:09:49 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 18 Jul 2000 00:09:49 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 18 Jul 2000 00:09:48 -0000 Received: from welfen-netz.com [193.194.149.183] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 18 Jul 2000 02:09:21 +0200 Sender: kai@pop.gmx.net Message-ID: <397405A8.7C7FB636@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8kvv9r+54qn@eGroups.com> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 09:22:16 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d3a35ec901e0faa00bf5edc37f6d5118 Status: R X-Status: N nicolas.boulay@ifrance.com wrote:
[...]
> > Comments please..??
> Euh,... you are [totaly] crazy ?
> >
> > I know ultimately we have to get the design into VHDL, but C++ is=
> > available on most Linux systems.
> > We need to start building components into circuits like the above= .
>
> The first step is to design the architecture: How is manage the
> different units ? So in the (first) model, the '+' operation is a + > in C++. But you can make a model cycle accurate. And then you can
> write it in vhdl.

But these "high-level" FU simulators could be combined with
units which are already put down at the logic- or even transistor
level!  E.g. a "64 bit input" connector node would convert the input of the 64 one-bit ports to an "INT64" type and pass it = on
to the behavioral sim. unit.

> The units are caraterized by latencies only (in clock cycle). In my > mind, we are very far away from the gate level !

Well, I'm thinking of a mixed top-down/bottom-up design if you like ;=B0>= ;

> We can begin the
> implementation of the different functionnal unit. But we didn't
> need them to write the simulator (the only difference is the
> latencies of an operator).

For the first FC0 arch. sim. a fairly accurate "gate delay" will = do
but estimating the delay, unit size, and maximum throughput of
the units won't always be enough for a CPU where it's exposed in the ISA whether a unit takes 3 cycles to complete or 4 !
For example I can't start thinking about pipelined FUs if it's
not even clear what the limits are :=B0(

Regards,
kai

> > Jeff Davies
>
> ----------------------------------------------------------------------= --
> Still looking for the complete Application Server solution?
> Find answers and a $75 gift certificate at the Intraware App Server > Webinar. Sign up at:
> http= ://click.egroups.com/1/6756/1/_/3462/_/963870846/
> ----------------------------------------------------------------------= --
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00330 for ; Tue, 18 Jul 2000 17:03:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:39 +0200 (MEST) Received: (qmail 17307 invoked by uid 0); 18 Jul 2000 01:24:15 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 18 Jul 2000 01:24:15 -0000 X-eGroups-Return: sentto-1101623-499-963883438-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 18 Jul 2000 01:24:04 -0000 Received: (qmail 23718 invoked from network); 18 Jul 2000 01:23:57 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 18 Jul 2000 01:23:57 -0000 Received: from unknown (HELO mail4.svr.pol.co.uk) (195.92.193.211) by mta1 with SMTP; 18 Jul 2000 01:23:57 -0000 Received: from modem-21.arizona.dialup.pol.co.uk ([62.137.54.21] helo=llandre.freeserve.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13EM6y-0001OY-00 for f-cpu@egroups.com; Tue, 18 Jul 2000 02:23:53 +0100 Sender: root@pop.gmx.net Message-ID: <3973B415.F23EB6B7@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> <39738329.67934489@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 02:34:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f94047aff4a1d5d9913207765bb5228 Status: R X-Status: N Yann Guidon wrote:

> hi Jeff ! welcome back :-))))
>
> Jeff Davies wrote:
> > Albert Abramson wrote:
> > > Rares Marian wrote:
> > > > Albert Abramson <maxx@nventure.com> wrote:
> > > > >Aaargh!  Use your imagination, Whygee!
> sorry, i'm tired...
>
> anyway, i think that it was a good idea to ask about the
> SMT/bandwidth problem. it helped wake the list up.
> but i wonder if we are "going the good way". It seems that
> Albert's discussions, relayed by Rares, burry the work
> that the list has done for one year on the FC0.
> OK i know, it must be fun to design a CPU but it is no fun at all
> to see that all our previous work is burried by a newcomer.
> If we want to see our chip made, we'll have to stop babbling
> all the time and MAKE things. we've completed one part of the work
> for the FC0, and now we're thinking everything again for a new
> stuff. i don't call this constructive.
>
> > Perhaps it is time to start putting together some C++ ,models of the processor.
> we've started to do this for the FC0 for a long time. There's even a GCC port
> going on (see sourceforge).
>

Vache I forgot. Perhaps the recent conversations made me think FCPU not as advanced as thoughtformerly.

> > I think we should start with some primitives of the type OR/AND/NOT and a LATCH
> > perhaps also a TRISTATE buffer. Therefore each electrical node should have 3 states (can be
> > char or an enumerated type, of 1,0 and X for tristate).
> <snip>
> > Comments please..??
>
> 1) did you think about the synchronicity problems ?
> will you simulate at the clock cycle level, or at the picosecond (thus having to
> simulate the propagation delays etc...) ? in VHDL, i think it's the difference between
> dataflow and (something else i don't remember its name).
>

I suppose you could modify the objects to take two or more cycles for in to get to out.I was just
thinking of a more Node-like model.


> 2) isn't plain C easier to code ? i mean, instead of having an external text file,
> the textfile should be the C source ... and we can directly use OR, AND, XOR etc,
> without having to use the SLOW fscanf functions...
>

Yeah, my original F00 16 bit sim works just like Nicholas Boulay says - using + for +.(Do you remember
- I had my compiler compiling a hello world app, and running on the
sim, outputing to a 'virtual terminal' (stdout).

The only reason for the C++ is so that the netlist is more similar to VHDL.
(In fact very very similar).
Anyway no need to go starting from scratch again. Keep going.

> > I know ultimately we have to get the design into VHDL, but C++ is available on most Linux systems.
> > We need to start building components into circuits like the above.
>
> thank you for the effort :-)
> of course using C is easier. my personal bias toward plain C instead of C++ is only a detail.
> since we can't get OKAD and because Alliance is so difficult to master, C sims are a path
> that we have already started to use. there are some sources, previously released on this
> mailing, that simulate some Execution Units of the FC0.
>
> > Jeff Davies
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jeff Davies
jeff@llandre.freeserve.co.uk
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00336 for ; Tue, 18 Jul 2000 17:03:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:41 +0200 (MEST) Received: (qmail 8381 invoked by uid 0); 18 Jul 2000 01:35:50 -0000 Received: from f19.egroups.com (207.138.41.182) by mx12.rz2.gmx.net with SMTP; 18 Jul 2000 01:35:50 -0000 X-eGroups-Return: sentto-1101623-500-963884138-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 18 Jul 2000 01:35:45 -0000 Received: (qmail 20654 invoked from network); 18 Jul 2000 01:35:38 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 18 Jul 2000 01:35:38 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta1 with SMTP; 18 Jul 2000 01:35:37 -0000 Received: from modem-21.arizona.dialup.pol.co.uk ([62.137.54.21] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13EMIJ-0002Fs-00 for f-cpu@egroups.com; Tue, 18 Jul 2000 02:35:36 +0100 Sender: root@pop.gmx.net Message-ID: <3973B6D3.D492D8CB@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> <39738329.67934489@f-cpu.org> <397414FA.8E5823DF@welfen-netz.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 02:45:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af66dc198eac007c06e0d043fdd70073 Status: R X-Status: N Kai Wetzel wrote:

> Yann Guidon wrote:
> >
> > hi Jeff ! welcome back :-))))
> >
> > Jeff Davies wrote:
> > > Albert Abramson wrote:
> > > > Rares Marian wrote:
> > > > > Albert Abramson <maxx@nventure.com> wrote:
> > > > > >Aaargh!  Use your imagination, Whygee!
> > sorry, i'm tired...
> >
> Good point.  I don't see this happening, though.
> The new stuff is just beeing discussed more actively because
> it's in a less mature state.  And if we want FC1 to be sucessful
> work should better start sooner then later.
>
> I'd like to give it a try and design an int adder following
> the rules put down in the FC0 manual.  This would then be given
> to the group to take a look and lough at it (peer review).
> But you said you had actually started one already ?
>

I'm getting the feeling we ought to have two work threads on simulation:

1. Functional Simulator. In this a '+' is peformed by the '+' in C.
2. Node level simulation. Ideally this would be in VHDL. But this is arse pain in Alliance and worse
in non-command line programs.
Therefore C++. Perhaps Kai's event driven version is better. Clock function call can come from some
relevant place like timer (interactive) or file io (when reads a value to inputs, then calls clock...

Just perhaps a little more complicated...

BTW it is easy to use Alliance to generate Adder's Subtractors etc to 128 bits. Utilities generate VHDL.
So you
could probably convert that to C++ node list pretty easily.
(also regfile etc).


Jeff Davies.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00339 for ; Tue, 18 Jul 2000 17:03:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:42 +0200 (MEST) Received: (qmail 14146 invoked by uid 0); 18 Jul 2000 02:32:40 -0000 Received: from fj.egroups.com (208.50.99.207) by mx11.rz2.gmx.net with SMTP; 18 Jul 2000 02:32:40 -0000 X-eGroups-Return: sentto-1101623-501-963887555-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 18 Jul 2000 02:32:38 -0000 Received: (qmail 30506 invoked from network); 18 Jul 2000 02:32:35 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 18 Jul 2000 02:32:35 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 18 Jul 2000 02:32:35 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000718023234.JWQG24904.mail.rdc1.wa.home.com@nventure.com> for ; Mon, 17 Jul 2000 19:32:34 -0700 Message-ID: <3973C13D.B726996E@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <3971A17F.B66595D@f-cpu.org> <3972DF8D.B598BE9B@hl.siemens.de> <39734A4B.232E13D9@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 19:30:23 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 178f259d422d60f9d40f0e168cce45ff Status: R X-Status: N Yann Guidon wrote:

> hi !
>
> Nicolas Boulay wrote:
> >
> > Yann Guidon wrote:
> > >
> > > hi,
> > >
> > > i've been thinking about SMT for quite a while now...
> > > and Albert's reason for using it is that it reduces the
> > > impact of the memory latency and bandwidth.
> > >
> > > but now, if you have N tasks/threads each accessing
> > > memory, don't you simply displace the problem ?
> > > if all your threads have cache misses, the core stalls.
> > > i believe that there's something to solve here.
> > > We can criticize OOO but it solved this problem.
> > > ideas are welcome (realistic ideas preferred).
> > >
> > With SMT, the idea is to beg that the cache have the data for the next
> > thread and during a wait, this thread is run. You have more chance not
> > "to stall".But the bandwith will always be the bottleneck.
>
> Ok, Albert recently apologized for his claim, and we're getting slowly
> closer to reality. it was a good idea to ask people...
>

WRONG!  I said MT would INCREASE the demand for bandwidth.  Whygee misquoted me
there.  It reduces the demand for short latency caching.  In fact, the Cray MTA
has NO data cache at all.

>
> your comment about cache/noncache is interesting, might be a track to follow.
>
> > Recently i have read some benchs in the tom hardwar's site for memory
> > bandwidth for the different x86 core. All the bench show a speed of ~500
> > MByte/s. It's the half of the theoritical maximum.
>
> let's see : 133MHz * 8 bytes ? around 1GB/s. now, if you run constantly in
> a cached system, you need one half of the bandwidth to read the data and one
> other half for the cache spilling (write back the modified items). this sounds
> logical for me, in a sense : i've been analysing CPU bandwidth for almost
> two years now.
>

Aaaargh!  A large backside L3 coupled with an integrated L2 will go a long way
toward keeping up with bandwidth requirements. (VLIW leaves a lot of room on the
die for an integrated L2.)  What's more, there's no reason that page sizes need
to be 4K or more.  We can get away with 1K paging on caches, thereby cutting
bandwidth demands a lot.  Many pages are mostly zeros anyway, and we can afford
more cache misses on a MT design.

>
> > So we can try to increase the efficiency of the management of the memory.
> > We can create specific instruction to manage caches.
> it's already existing. although it's rather generic, it exists.
> but i don't think that it's the best solution.
>

I believe we oughta have Instruction AND Data touches to improve hit rates, as
well as page touches for lower levels, and a prefetch for L0.  PowerPC has a lot
of memory management instructions, but they aren't really used as often as they
should be, IMHO.

>
> i have included caching hints in the L/S instructions, i believe that
> it is much more useful.
>

This is a good point, I have always included a lot of memory management hints in
load-store instructions to cut down on these stalls.

>
> > Each SDRAM have 4 banks, so you can interleave 4 address demands and use
> > burst mode to fill the cache.
> ok, but as noted before : we need more than 4 ongoing transactions.
> does that mean that we must interleave the SDRAM DIMMs ? with 4 DIMMs
> we could have 16 ongoing transactions (but the electronics is getting crazy).
>

With the aforementioned proposal, you could have 8 outstanding transactions.  The
way SDRAM works, that would be okay for 60ns latency, 133MHz memory.  SLDRAM
offers latency around 30ns and 200 MHz clock rates -- sufficient for six
outstanding transactions.  I am confident that this superior memory technology
will come to replace SDRAM -- because it is cheap.

>
> > An intelligent L/S unit could mix the request from the different threads.
> that's not that complex, i think that we can do it. there might even be free
> IP for this in VHDL/Verilog.
>
> furthermore, in the L/S instructions, we can explicitely specify 8 streams
> (incl. the default one) which can be directly mapped to SDRAM banks.
>
> > nicO
> WHYGEE

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00345 for ; Tue, 18 Jul 2000 17:03:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:43 +0200 (MEST) Received: (qmail 16434 invoked by uid 0); 18 Jul 2000 04:49:02 -0000 Received: from hl.egroups.com (208.50.99.197) by mx02.gmx.net with SMTP; 18 Jul 2000 04:49:02 -0000 X-eGroups-Return: sentto-1101623-502-963895735-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 18 Jul 2000 04:48:56 -0000 Received: (qmail 15445 invoked from network); 18 Jul 2000 04:48:55 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 18 Jul 2000 04:48:55 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 18 Jul 2000 04:48:55 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000718044854.NEHC24904.mail.rdc1.wa.home.com@nventure.com> for ; Mon, 17 Jul 2000 21:48:54 -0700 Message-ID: <3973E12E.48283B1F@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> <39738329.67934489@f-cpu.org> <397414FA.8E5823DF@welfen-netz.com> <3973B6D3.D492D8CB@llandre.freeserve.co.uk> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 17 Jul 2000 21:46:44 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] C++ F-CPU Simulator vs. MT VLIW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0651cc13b00c5eaee88ca7fd985f9038 Status: R X-Status: N 
Yann Guidon wrote:
> 
> hi Jeff ! welcome back :-))))
> 
> Jeff Davies wrote:
<snip>
> OK i know, it must be fun to design a CPU but it is no fun at all
> to see that all our previous work is burried by a newcomer.
> If we want to see our chip made, we'll have to stop babbling
> all the time and MAKE things. we've completed one part of the work
> for the FC0, and now we're thinking everything again for a new
> stuff. i don't call this constructive.

Hmm, babbling about new stuff and completing FC0 is orthogonal to
me.  And as a side effect we get new ideas for FC0, e.g. "stalled threads"-
multi-threading is a thing which could show useful for a classic RISC
(FC0) road as well - as could concurrent multi-threading/pipelined FUs,
but it seems not to be worth it to mention it every day again :°|


Okay, fair enough.  By a weird set of coincidences, it would be perfectly feasable to retrofit everything good from fc0 into MT VLIW.  All 64 regs are available to the thread scheduler in MT VLIW.  The locals are accessed by changing the value in the ThreadID register.  If 64 SIMD regs are needed, they're there.  A VLIW version of fc0 is not difficult.  In fact, we would save the process of implementing the decode hardware, since the compiler-assembler decides what can issue in any cycle.  Other MT issues can be saved for later.  The difference is whether you're running in User Mode or Global Mode.  The latter is more like the original fc0.
  

Good point.  I don't see this happening, though.
The new stuff is just beeing discussed more actively because
it's in a less mature state.  And if we want FC1 to be sucessful
work should better start sooner then later.

I'd like to give it a try and design an int adder following
the rules put down in the FC0 manual.  This would then be given
to the group to take a look and lough at it (peer review).
But you said you had actually started one already ?
I did, in fact, get pretty far on xRISC, but I can just ditch of that decode stuff and go for uP w/out interlocking pipes.

I actually prefer the one-threaded version of VLIW first, since it offers the fewest hardware problems.  It almost designs itself.  Before splitting regs, we could just use 64 gprs, 64-bits each, ala fc0.  This isn't fast, but it is simple to design functionally.  A one-at-a-time RISC w/out interlocking pipelines would be a good start point.  We can debate software vs. hardware scheduled from that point.

Alternately, we could just take the fastest processor there is -- the 21264 -- and remove the decode hardware.  That would work, but without so much of the clock penalty associated with dynamic scheduling hardware.  If the compiler wanted OOO, it could schedule it all using predication and software renaming.

All of this still leaves me wanting to get down and design this thing.  Again, it is simplest to implement, and there are people on this list who could do it right now.  This, I feel, is the simplest, best proven approach.

There, let's do it.  Whoever implements first gets to choose the architecture.

--Maxx

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00369 for ; Tue, 18 Jul 2000 17:03:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:49 +0200 (MEST) Received: (qmail 15870 invoked by uid 0); 18 Jul 2000 10:24:06 -0000 Received: from mq.egroups.com (207.138.41.138) by mx12.rz2.gmx.net with SMTP; 18 Jul 2000 10:24:06 -0000 X-eGroups-Return: sentto-1101623-503-963915802-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mq.egroups.com with NNFMP; 18 Jul 2000 10:23:28 -0000 Received: (qmail 22010 invoked from network); 18 Jul 2000 10:23:22 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Jul 2000 10:23:22 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 18 Jul 2000 10:23:22 -0000 Received: from modem-9.amoxicillin.dialup.pol.co.uk ([62.136.78.137] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13EUWv-0006bd-00 for f-cpu@egroups.com; Tue, 18 Jul 2000 11:23:14 +0100 Sender: root@pop.gmx.net Message-ID: <39743281.8647F176@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <200007170037.e6H0bi201604@tbird.iworld.com> <3972597D.CDC16BC@nventure.com> <39734CF6.8868C109@llandre.freeserve.co.uk> <39738329.67934489@f-cpu.org> <397414FA.8E5823DF@welfen-netz.com> <3973B6D3.D492D8CB@llandre.freeserve.co.uk> <3973E12E.48283B1F@nventure.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 11:33:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] C++ F-CPU Simulator vs. MT VLIW Content-Type: multipart/alternative; boundary="------------1E423C61F0C3B1BB99FECE27" X-UIDL: 20871a8702ffff1866926d3fa64b8933 Status: R X-Status: N --------------1E423C61F0C3B1BB99FECE27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > There, let's do it. Whoever implements first gets to choose the > architecture. > This is good and bad.GOOD: lots of alternatives is good (turns up lots of ideas) competition is good BAD: splits effort... or does it? If we keep a common standard of components, or at least tool chain (we all face the same problems) then one mans gain is another mans gain (if you see what I mean). i.e. components maxx comes up with will be usable by folks using Whygee's FC0 base and vice versa. This whole memory bandwidth thing by the way doesn't have a single answer as far as I can tell. Do you have 3 caches of fast, less fast, slow and externally SDRAM, or should you trim the CPU as much as possible, have a massive level1 cache and no others.. My opinion is have incredibly simple CPU with buckloads of RAM on board, possibly even no external ram and join up twenty of them in a single PC using some kind of ultrafast inter-cpu comms. (run beowulf, or hurd on a mach microkernel). Lots of people can offer opinions anywhere between the extremes. I guess the optimum is somewhere in between and is moving all the time (with new processes, new layouts or whatever). We keep getting these conflicts of ideas which at times make people storm off. I think FC0 initiative should continue but Maxx should work on his own ideas, but neither should think they alone is right. (there is no "right" here). For the first cut of silicon perhaps we will compare the designs with some benchmarks, winner gets first cut? However there might be enough resources for both designs to be cut in silicon. A common pool of common bits is what we need to establish (I guess functional units will be similar between the two initiatives, and work on assemblers etc particularily is common: HOW TO MAKE GAS/GCC work with my new CPU design - please someone volunteer to write that manual ). Jeff Davies > --Maxx > ----------------------------------------------------------------------- > > ----------------------------------------------------------------------- > --------------1E423C61F0C3B1BB99FECE27 Content-Type: multipart/related; boundary="------------31BBAF55CE24A04488160ED5" --------------31BBAF55CE24A04488160ED5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 

There, let's do it.  Whoever implements first gets to choose the architecture.
 

This is good and bad.GOOD:
lots of alternatives is good (turns up lots of ideas)
competition is good

BAD:
splits effort... or does it?

If we keep a common standard of components, or at least tool chain (we all face the same problems)
then one mans gain is another mans gain (if you see what I mean). i.e. components maxx comes up with
will be usable by folks using Whygee's FC0 base and vice versa.

This whole memory bandwidth thing by the way doesn't have a single answer as far as I can tell.
Do you have 3 caches of fast, less fast, slow and externally SDRAM, or should you trim the CPU as much as
possible, have a massive level1 cache and no others..
My opinion is have incredibly simple CPU with buckloads of RAM on board, possibly even no external ram
and join up twenty of them in a single PC using some kind of ultrafast inter-cpu comms.
(run beowulf, or hurd on a mach microkernel).

Lots of people can offer opinions anywhere between the extremes. I guess the optimum is somewhere in between and is moving all the time (with new processes, new layouts or whatever).

We keep getting these conflicts of ideas which at times make people storm off. I think FC0 initiative should continue but Maxx should work on his own ideas, but neither should think they alone is right.
(there is no "right" here).
For the first cut of silicon perhaps we will compare the designs with some benchmarks, winner gets first cut?
However there might be enough resources for both designs to be cut in silicon.

A common pool of common bits is what we need to establish (I guess functional units will be similar between
the two initiatives, and work on assemblers etc particularily is common: HOW TO MAKE GAS/GCC work with my new CPU design - please someone volunteer to write that manual ).

Jeff Davies
 
 
 

--Maxx 

  --------------31BBAF55CE24A04488160ED5 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="/tmp/nsmail3974328200400B9.gif" R0lGODdh1AE8APsAMQAAAAQE/PwEBExM/Hx8/PxMTIyM/PyMjLS0/MTE/PzExNTU/Nzc/Pzc 3Ozs/P///ywAAAAA1AE8AAAE//DJSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//A oHBILBqPyKRyyWw6n9CodEqtWq/YrPZ6KAgKh5FAIBlzut+wyFwZjwuNDZvjHqs78zU5BeBb +kQAghqAG4Uzh1tHXRIKAncfbGwNkBOMD46VeHsUbAcCcRl5EpQWk48eoxylD6okiRiwD4Wy gRWytbc2uYpAjqElqqq/J8J7DaiinBPGzMsartDPfhy4E7xBidbVu71Inxd2ap8CChRdyHtm dRXgFpRvoeIS6M1lBZZj5mXlYPyjc+aQ20cPjiR1nBR4OZBuXUIvBMc0KACH0AVBgDDeGjRr Fq1rHP91hfT4MWQfkx1JStB4cuRKjxQ0vuzocmZKlTZh0eL4caZMmrpyovR5M4srifTKIdv3 SQE5flDbTHvA8AEyfK1AJXVqL+vWpfwOZIraac9YqkrLbX3qta0jBcjCHGxU7i0/uF8sBk25 DSbfnH8yAvabUTDha0SLgkz89/Bew40VRz6J+GXPmpcrX8Ym5SgnL/ckgG47VyqGBlwRThjd lQ1rrJJgT6uT7MFr0apJ7xntLOpt3Xpjar5YuTGvzIwhKx8eWXjy539uIpe8HChl6TZFFq/O WQrvss7YAR9P4fuEuOnIlgYfOqv40s3ihncTFX7u3uPtBwcps+/0n85NNtj/f8xBFmBh/Q2m 3YDFMfcXZQjyFAt20HUXBTGm4WYBa7kNo1WG63FoyjHJmEeabCPStY+JIo5nXmm/rUfcXg1u 52CNFBKYo43GzdgcdAvumF2F1g0pmWU8TqcIRXThI1BaWDXlSIdTMYlJXl6gtp6U9nwSSlNX hSVfW+zZtgeYeaGlwJS4aWlWWnLl9pZd+U2j04089mikjpsBaZiBSRYIaIM6OtcThUL6mOig WpDzSBx5kFNVQem1NWY7blQ1UQFskkmVQbNlCgxaj/Iz0R2XknWWpMDUcwxFlV5ZqnxzKMQp fjKuhBFPJunEHX8+7nSoYEPpihxm2w3VUgbajLRr/3TGHhhTsdACyx+j3mSr7bZG6sCZhTyA y+245HIrLgzfKnFuuey2e8W6LhwH7y7zumvvvfjmq+++/Pbr778AByzwwAQXbPDBCCes8MIM 23IkNRNGHG+1DVdsMQvatHAcsxSXIG69imZz8cg+ZIzxfjR2K8LHJztM8ssj/HQdgIMQWxNO 0SIJEy7X4bwsztOWdEjN0P4sM0oIBp2zcM4Wa7OuSluW9NIwV11tYQw65t+Af97pGF9/Bgu1 cV5LiCjWi3ZrNp9ocxe2glbHTV2gifU147BXZ/1j0Q6W3fffjOGIqI14Ewmk3IjPbazZeqa8 uIJeg51g4EH/uqfeuyr37P/SWz+u89mLW0514jBHbjrll/uZt+J7pz244axvfGShPRd++uyk W0171p23nSfdAuL+dXWGAh588DzXPbS0sBMPcu4Ayxy152hvNPTMlV90tLA7aX/85sX7JCyh TXcv0vVFLQ+502P7DP378J8A7vPx128/uh/Qf//+/JvQ3c39C6AAB0jAAhrwgAhMoAIXGIQA MPCB+QqAAx+wgAEEgAAvkGAMHECACzrgAQ6QoAglgAAJImACJQzACUlowgtosAYvfCEMZOjC CWKAhiWIoQ0tgEMK9BCCN3ihBWPwQxUQYAEBWAAGGRAAA1CghAlIgAofAEUpnrCKU6xAEV2g Qwn/MMCJLdjiA8TYwy+GoIs33KEW1QjEIE5QjCeAowkcaMMSLoACHZTABR+QxzFisI977EEP 5SgCMrLRh2wkJCI7sEVFtjGMdBzhBDr4wRBikIoWXOEY35jIJA5gAHcEoQEkSAAGMBGMDxgl A1LZQgsMoI+stCAYu0hLTvKQkwz4ZCgrgABZflCCBrjkKLMogWAi0ZYiZGMvm1jJYZZSj00U 5hF/aEwZDlOTEkzAAGYpSQws0wC/tCUJfblJChITmhUE5QSuOQFgCrOVjwQBGlEYgAQ8wIpU rCc+y8lPRCLAkhJ4ZggHwMcAVHKPUESiJunJTFY6AJ+1hCY/B8nJBAzU/wJQDKETJbjKfCZA oSxMQAol2k96WrSJfFzlRTfZUSiOlJf1fGlCs2jCfYoxoyhFI043atBzQvOfgZzpCjkaUpDG 8wPz9CJKVVlQPV4yqSSVIQMQ0EEHgtSODxiiHy+QQlTqkaARLSdUJypOCmi1nTbUaiDVKs4e nnUCU60qSbNa1gmwVQJqfeobCVpSV6oRjW/d5CtrSNK8ztWwR/XAWC24UjSOFY1IBKcQB+CA T0IzmTcs4RrJytnHtrWTm72sJB1b17lKILIhLKtno5rMz5r2lqGFajI7ukiyYrafrT1kYgnb V1aOEoyA1OtrOUvcEo5yhYF14Ri1SNDgNnWrzv+NbWnpGlrqVuCuxDXrX12L1+liN7kx5KsY AwvY7SLxkrUVImi7u9szTveYSQzpPin50vROkLFStKEIP+hRgFZgmmakJD6xeEV9TpHAsM2u SQEqQ5xe0qWkxWg9AYrfeUJYmTF9oYN/atSxblinE96jBku40OKGWLgh9W97NTDWTRoUhZ/U ZAVLSVGSprO+JH4iMPlLAQZ0kADNDMAANMnOYsKzyNIdbj4bSsOu8tgAoIRsIHXc0BsnFcrH vACWG7xjaOYSveft7ZLBmV0n85MAlLUvQ8lcUjOv+AQ/ZoJuD8jBN28ht3jOs573zOc++/nP gA60oAdN6EIb+tCITvQpn+08AlKWmNGQjrSkJ03pSlv60pjOtKY3zelOe/rToLZfBAAAAAAA AAAAOw== --------------31BBAF55CE24A04488160ED5-- --------------1E423C61F0C3B1BB99FECE27-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00372 for ; Tue, 18 Jul 2000 17:03:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 18 Jul 2000 17:03:51 +0200 (MEST) Received: (qmail 21723 invoked by uid 0); 18 Jul 2000 10:32:43 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 18 Jul 2000 10:32:43 -0000 X-eGroups-Return: sentto-1101623-504-963916349-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 18 Jul 2000 10:32:32 -0000 Received: (qmail 1567 invoked from network); 18 Jul 2000 10:32:29 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 18 Jul 2000 10:32:29 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 18 Jul 2000 10:32:28 -0000 Received: from modem-9.amoxicillin.dialup.pol.co.uk ([62.136.78.137] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13EUfq-0000th-00 for f-cpu@egroups.com; Tue, 18 Jul 2000 11:32:27 +0100 Sender: root@pop.gmx.net Message-ID: <397434B0.F5B3821F@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 18 Jul 2000 11:42:56 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GNL and XML thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 67561d919fe39d5d073877a63ba840fd Status: R X-Status: N There is a really cool XML editor (free) called xeena (written in java)
available from www.alphaworks.ibm.com
it displays your document as a tree of tags, and it has a context
sensitive tag bar (drag the relevant tag
and drop into your document)
and there is a XSLT designer also free on the same site (Visual XML
Tools). The XSLT designer actually allows you to graphically design your
XSLT, and then produce a Java stand-alone program to do it in future!!

What has this to do with fcpu I hear???

Well with the graphical programming initiative ->

you could have the following:



<Unconditional-Block name="myfunction">

    <Conditional-Block>
        <Condition>R0==0</Condition>

        <Move Source="R0" Destination="R1"/>
    </Conditional-Block>
<Unconditional-Block>



Perhaps the XSLT could directly compile the above into binary!!!

In the same way the XML tree could be used for a higher level language.

(perhaps Microsoft's C sharp big secret is this kind of thing? well our
archives show part of this idea stretching back some time in the past).


What think f-cpuers??

Jeff Davies
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00374 for ; Wed, 19 Jul 2000 19:11:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 19 Jul 2000 19:11:04 +0200 (MEST) Received: (qmail 18763 invoked by uid 0); 19 Jul 2000 02:27:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx02.gmx.net with SMTP; 19 Jul 2000 02:27:11 -0000 X-eGroups-Return: sentto-1101623-506-963973629-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 19 Jul 2000 02:27:09 -0000 Received: (qmail 23446 invoked from network); 19 Jul 2000 02:27:09 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 19 Jul 2000 02:27:09 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 19 Jul 2000 02:27:08 -0000 Received: from f-cpu.org (Raspail-3-36.club-internet.fr [195.36.203.36]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA23806 for ; Wed, 19 Jul 2000 04:27:02 +0200 (MET DST) Message-ID: <397511D6.F7B0B503@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <397434B0.F5B3821F@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 19 Jul 2000 04:26:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GNL and XML thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 455edbc5f07bae90ef45b8da1c650396 Status: R X-Status: N hi !

Jeff Davies wrote:
> There is a really cool XML editor (free) called xeena (written in java)
<snip>

> What think f-cpuers??
might be worth the effort of trying it out, if this spares us
some months of coding. although i'm not JAVA fan.
One of my goals with such an  IDE is to have complete control
of the machine, i don't like to be stuck because it has
to chew some million lines of code. JAVA is known to be slow
and i expect to handle thousands of instructions at once,
so the design quality of the code is very important for me.

or simply it could be used as a background task or a filter.
the editor is half (at least) of the GNL project.

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00377 for ; Wed, 19 Jul 2000 19:11:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 19 Jul 2000 19:11:05 +0200 (MEST) Received: (qmail 28008 invoked by uid 0); 19 Jul 2000 02:27:13 -0000 Received: from fk.egroups.com (208.50.99.208) by mx02.gmx.net with SMTP; 19 Jul 2000 02:27:13 -0000 X-eGroups-Return: sentto-1101623-505-963973623-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 19 Jul 2000 02:27:11 -0000 Received: (qmail 4690 invoked from network); 19 Jul 2000 02:27:02 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 19 Jul 2000 02:27:02 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 19 Jul 2000 02:27:02 -0000 Received: from f-cpu.org (Raspail-3-36.club-internet.fr [195.36.203.36]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA01750 for ; Wed, 19 Jul 2000 04:26:59 +0200 (MET DST) Message-ID: <397511D3.E0A5DBCB@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 19 Jul 2000 04:26:27 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] rebirth of the f-cpu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c19d6ef3355ce051479873d22303137c Status: R X-Status: N hi again,

i didn't follow/read each and every post for a few days
because i need to free my mind from a lot of stresses.
i slowly realize that health is important too and with the
summer i need to relax and let old dreams come true.

i won't abandon the f-cpu project for any reason : i've spent
so much time and money, i've met so many guys and made so many
promises that i believe that it's only the beginning. so
if i stay mute for a while, it's only a little stop to re-start
better and faster in September. With the planned meeting in Paris,
i keep in touch with everybody and more people take responsibilities
in the project.

may i remember those people :
- Paul Mota, who's setting up a server (an old SUN IPX)
that will become the f-cpu.org site. Paul will be the
webmaster of this computer, the DNS is still more or less
sponsored by Devcon.net (Germany). f-cpu.com and f-cpu.net
will be redirected to f-cpu.org, f-cpu.de will stay at Devcon
to be used by the german team.
- JEAN Olivier has taken the responsibility of managing the
manual. he's almost completed the new LATEX version.
- Mathias Brossard and some others are/were working on the
GCC port. the files are available from the sourceforge site
(see f-cpu.org).

As you see, making a CPU is not only a matter of "the nicest core".
At one point or another we have to change of core and instruction
set, like a lizzard/snake changes his skin. yet we shouldn't forget
that we have to organize a lot of things if we want to make this
chip one day. so it's not ONLY a matter of architecture.
At one point, when the complete description of the CPU will be
ready, when the simulations will be ok, it will become the toughest
stage : the EDA phase (Alliance etc). And i'm not speaking about
the choice of the fundry.

i have to rest a bit and finish the writing of my master thesis,
then i'll get back at the anal work on the FC0. in the same time,
we can begin to organize the meeting in Paris : the schedules,
the places and what we'll do. Priority #0 is to update and
homogenize all the websites. we'll need several people and we
can be helped through IRC and mail during the working sessions.

be ready.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00323 for ; Thu, 20 Jul 2000 19:24:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:01 +0200 (MEST) Received: (qmail 20555 invoked by uid 0); 19 Jul 2000 21:16:47 -0000 Received: from hn.egroups.com (208.50.99.199) by mx02.gmx.net with SMTP; 19 Jul 2000 21:16:47 -0000 X-eGroups-Return: sentto-1101623-507-964041400-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 19 Jul 2000 21:16:40 -0000 Received: (qmail 30139 invoked from network); 19 Jul 2000 21:16:39 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 19 Jul 2000 21:16:39 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 19 Jul 2000 21:16:39 -0000 Received: from 0018728164 (host-209-215-24-28.bix.bellsouth.net [209.215.24.28]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id RAA07322; Wed, 19 Jul 2000 17:16:36 -0400 (EDT) Message-ID: <000801bff1c6$82b9da60$1c18d7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 19 Jul 2000 16:15:46 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFF19C.986AEE00" X-UIDL: c37accf47908b7258d9365485469feb8 Status: R X-Status: N ------=_NextPart_000_0005_01BFF19C.986AEE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Somehow; I am not getting thru loud and clear - possibly because my = design is M2M with all Schematic input. You can get a FREE download of the = QuickLogic software at Quicklogic.Com --- it contains the VHDL design environment. = Users choice. I prefer Schematic because I have complete visability of EVERY = COMPONENT - EVERY WIRE. And when I run the design thru the CHIP creation = process; my output can be then run thru the Simulation process to = determine timing problems due to PLACE & ROUTE. No way can you put the cart = before the horse as one person desired. You HAVE to do the design FIRST = before you can determine time of each Execution Component such as ADD, = SUB, COMPARE etc. The person that thinks FPGA's are tinker toys must have an infinite = R & D budget. Its a damn good stepping stone. I will have my design complete = in the next week or two with a Two-Level Pipeline in a 60,000 gate = device; the QL3060. This will tell me exactly what I have to do to increase Pipe depth. = Beyond Four; I will have to wait for the Eclipse Software release. I have a feeling = THAT will be the maximum without ASIC. This may be all that is required to meet my = system objectives. I have used virtually every design trick in the book = for added performance. Instruction Look-ahead, Operand Look- ahead and = others. Upon completion I will write another piece entitled DAMN IT - DON'T = INVENT - INNOVATE PART V. That's for you MAXX, don't stop. I think it would be = a pleasure to work with you - we seem to think alike. Richard Hartney Erin Greene & Associates Research Director ------=_NextPart_000_0005_01BFF19C.986AEE00 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Somehow; I am not getting thru loud and clear - possibly because my design is
M2M with all Schematic input.  You can get a FREE download of the QuickLogic
software at Quicklogic.Com --- it contains the VHDL design environment.  Users
choice.  I prefer Schematic because I have complete visability of EVERY COMPONENT - EVERY WIRE. And when I run the design thru the CHIP creation process; my output can be then run thru the Simulation process to determine
timing problems due to PLACE & ROUTE.  No way can you put the cart before the horse as one person desired.  You HAVE to do the design FIRST before you can determine time of each Execution Component such as ADD, SUB, COMPARE
etc.
    The person that thinks FPGA's are tinker toys must have an infinite R & D
budget.  Its a damn good stepping stone.  I will have my design complete in the next week or two with a Two-Level Pipeline in a 60,000 gate device; the QL3060.
This will tell me exactly what I have to do to increase Pipe depth.  Beyond Four;
I will have to wait for the Eclipse Software release.  I have a feeling THAT will be the
maximum without ASIC.  This may be all that is required to meet my system objectives.  I have used virtually every design trick in the book for added performance.  Instruction Look-ahead, Operand Look- ahead and others.
    Upon completion I will write another piece entitled DAMN IT - DON'T INVENT -
INNOVATE PART V.  That's for you MAXX, don't stop.  I think it would be a pleasure to work with you - we seem to think alike.
 
Richard Hartney
Erin Greene & Associates
Research Director
------=_NextPart_000_0005_01BFF19C.986AEE00-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00329 for ; Thu, 20 Jul 2000 19:24:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:02 +0200 (MEST) Received: (qmail 4417 invoked by uid 0); 19 Jul 2000 22:16:39 -0000 Received: from ck.egroups.com (208.50.144.69) by mx06.rz2.gmx.net with SMTP; 19 Jul 2000 22:16:39 -0000 X-eGroups-Return: sentto-1101623-508-964044992-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 19 Jul 2000 22:16:31 -0000 Received: (qmail 27712 invoked from network); 19 Jul 2000 22:16:31 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 19 Jul 2000 22:16:31 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 19 Jul 2000 22:16:31 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000719221630.MRMB24904.mail.rdc1.wa.home.com@nventure.com> for ; Wed, 19 Jul 2000 15:16:30 -0700 Message-ID: <397628BF.2251C953@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 19 Jul 2000 15:16:31 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c2e3ed2a311066cf9d72adb336eec29 Status: R X-Status: N  
"Richard E.Hartney" wrote:
Somehow; I am not getting thru loud and clear - possibly because my design isM2M with all Schematic input.  You can get a FREE download of the QuickLogicsoftware at Quicklogic.Com --- it contains the VHDL design environment.  Userschoice.  I prefer Schematic because I have complete visability of EVERY COMPONENT - EVERY WIRE. And when I run the design thru the CHIP creation process; my output can be then run thru the Simulation process to determinetiming problems due to PLACE & ROUTE.  No way can you put the cart before the horse as one person desired.  You HAVE to do the design FIRST before you can determine time of each Execution Component such as ADD, SUB, COMPAREetc.    The person that thinks FPGA's are tinker toys must have an infinite R & Dbudget.  Its a damn good stepping stone.  I will have my design complete in the next week or two with a Two-Level Pipeline in a 60,000 gate device; the QL3060.This will tell me exactly what I have to do to increase Pipe depth.  Beyond Four;I will have to wait for the Eclipse Software release.  I have a feeling THAT will be themaximum without ASIC.  This may be all that is required to meet my system objectives.  I have used virtually every design trick in the book for added performance.  Instruction Look-ahead, Operand Look- ahead and others.    Upon completion I will write another piece entitled DAMN IT - DON'T INVENT -INNOVATE PART V.  That's for you MAXX, don't stop.  I think it would be a pleasure to work with you - we seem to think alike. Richard HartneyErin Greene & AssociatesResearch Director

One of Seymour Cray's best strategies was to make use of proven technology that others had already used -- often without success.  He let othes stumble over brand new technology, then made the best designs he could out of slightly more mature ideas.  The result was that nearly all of his early designs were major commercial successes in an era when most new supercomputers flopped.  Everyone said, "Look at how our peak performance is better than Cray's, " while their actual performance on real applications sucked.  If you can't get operands in, processed, and out in a hurry, your design will suffer for it.

Point being that I like VLIW more for these very reasons.  It's not only proven technology that we can understand (knowing more about its shortcomings than its early implementors), but performance improvements can come by tweaking the wire and the design by hand.  It's still small enough and simple enough to hand optimize at the gate level.  It's like the difference between hand assembled code and compiler optimized code.  A smart software engineer can always outperform any computer generation program.  VLIW lets you make one mask and then tweak it forever to get better performance out of it.

What good is scalability when applications developers won't make that extra effort to properly develop and optimize code?  You have to design the engine around the fuel, and we're not getting Formula 1 here.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00344 for ; Thu, 20 Jul 2000 19:24:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:05 +0200 (MEST) Received: (qmail 30202 invoked by uid 0); 20 Jul 2000 04:57:59 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 20 Jul 2000 04:57:59 -0000 X-eGroups-Return: sentto-1101623-509-964069076-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 20 Jul 2000 04:57:57 -0000 Received: (qmail 20797 invoked from network); 20 Jul 2000 04:57:55 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 20 Jul 2000 04:57:55 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 20 Jul 2000 04:57:55 -0000 Received: from f-cpu.org (Raspail-2-238.club-internet.fr [195.36.192.238]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA02715 for ; Thu, 20 Jul 2000 06:57:52 +0200 (MET DST) Message-ID: <397686B3.21148D70@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <397434B0.F5B3821F@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 20 Jul 2000 06:57:23 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GNL and XML thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b3121590722ffc57a9229be828bb69ad Status: R X-Status: N Jeff Davies wrote:
> There is a really cool XML editor (free) called xeena (written in java)
> available from www.alphaworks.ibm.com
<re-snip>
> What think f-cpuers??

i've looked and seen that it is not "free". not GPL, and limited
in time : it's not a good tool to start developping with.
maybe someone will make a GPL'd version of it if it's successful ?

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00359 for ; Thu, 20 Jul 2000 19:24:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:08 +0200 (MEST) Received: (qmail 10726 invoked by uid 0); 20 Jul 2000 06:16:12 -0000 Received: from jk.egroups.com (208.50.144.83) by mx02.gmx.net with SMTP; 20 Jul 2000 06:16:12 -0000 X-eGroups-Return: sentto-1101623-510-964073771-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 20 Jul 2000 06:16:10 -0000 Received: (qmail 28093 invoked from network); 20 Jul 2000 06:16:10 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 20 Jul 2000 06:16:10 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 20 Jul 2000 06:16:10 -0000 Received: from f-cpu.org (Raspail-4-97.club-internet.fr [195.36.203.97]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA04663 for ; Thu, 20 Jul 2000 08:16:07 +0200 (MET DST) Message-ID: <39769908.EFBEA223@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 20 Jul 2000 08:15:36 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 81dd925516449387003742ce566d1387 Status: R X-Status: N hi Richard !

> "Richard E.Hartney" wrote:
>
> Somehow; I am not getting thru loud and clear
> - possibly because my design is M2M with all Schematic input.
>  You can get a FREE download of the QuickLogic software at Quickl= ogic.Com
> --- it contains the VHDL design environment.  Users choice.
thank you

>  I prefer Schematic because I have complete visability
> of EVERY COMPONENT - EVERY WIRE.
the same goes (to a certain extent) with the pen&paper approach.
even though it's not the perfect tool, it works and lets you do more
than a mouse can ever do. then, for the entry, i have a scanner ;-)

> And when I run the design thru the CHIP creation process; my output > can be then run thru the Simulation process to determine
> timing problems due to PLACE & ROUTE.  No way can you put the= cart
> before the horse as one person desired.  You HAVE to do the desig= n
> FIRST before you can determine time of each Execution Component
> such as ADD, SUB, COMPARE etc.
yup, but some simple design rules can help get you there.

>     The person that thinks FPGA's are tinker toys<= BR> > must have an infinite R & D budget.
well said ;-)

>  Its a damn good stepping stone.  I will have my design comp= lete
> in the next week or two with a Two-Level Pipeline in a 60,000 gate dev= ice; the QL3060.
you previously said it's 32 bits, rights ? "not enough gates for 64&qu= ot;...

> This will tell me exactly what I have to do to increase Pipe depth. >  Beyond Four; I will have to wait for the Eclipse Software releas= e.
>  I have a feeling THAT will be the maximum without ASIC.  Th= is may
> be all that is required to meet my system objectives.  I have use= d
> virtually every design trick in the book for added performance.
>  Instruction Look-ahead, Operand Look- ahead and others.
i hope that it will finally be implemented :-)

>     Upon completion I will write another piece ent= itled
> DAMN IT - DON'T INVENT - INNOVATE PART V.  That's for you MAXX, d= on't stop.
hey ! why Maxx only ? there are a lot of people like him in this group.
maybe a bit different and with less verve, but they also need a certain enc= ouragement too.

>  I think it would be a pleasure to work with you - we seem to thi= nk alike.
hehe, maybe you're not as old as you said ;-)
(yes it's a compliment)

> Richard Hartney
> Erin Greene & Associates
> Research Director


Albert Abramson wrote:
> One of Seymour Cray's best strategies was to make use of proven
> technology that others had already used -- often without success.
mmm like ... indium phosphide ? ;-)
CRAY's life was long and prolific, he has made great things and great error= s, too,
that we can also take lesson from, always keeping in mind that "times = have changed".

>  He let others stumble over brand new technology, then made the > best designs he could out of slightly more mature ideas.  The
> result was that nearly all of his early designs were major commercial<= BR> > successes in an era when most new supercomputers flopped.
remember that : "at that times, every computer was a "super compu= ter""
(Eugene Miya, comp.sys.super FAQ) What Cray fought was corporatism,
that's how he won his challenges. and with some tens of millions of dollars= , too.

>  Everyone said, "Look at how our peak performance is better = than Cray's, "
> while their actual performance on real applications sucked.
>  If you can't get operands in, processed, and out in a hurry,
> your design will suffer for it.
>
> Point being that I like VLIW more for these very reasons.
maybe you're missing a point or two with VLIW : if it's good at executing a= lot
of instructions, shoving them down in a fixed pipeline, that's all it's goo= d for.
OTOH Crays usually are good at "computing", in the arithmetic sen= se of the term.
ie the CRAY2 took 2 cycles to decode an instruction.

but when it comes to efficiency of the said instructions, the perspective i= s different.

>  It's not only proven technology that we can understand (knowing = more about
> its shortcomings than its early implementors),
VLIW in the "orthodox" sense will still need some time to be prov= en.
what you're doing is a sort of superscalar CPU, this technique
is known for a long time.

> but performance improvements can come by tweaking the wire
> and the design by hand.
you seem to be patient enough :-)

>  It's still small enough and simple enough to hand optimize
> at the gate level.
like, huh, the F21 ?  :-)

> What good is scalability when applications developers won't
> make that extra effort to properly develop and optimize code ?
that is probably a more important question than VLIWvsRISC.
working at the level of the development tools can get you more
MOPS than you'd think.

>  You have to design the engine around the fuel,
> and we're not getting Formula 1 here.
"le li=E8vre et la tortue" (the hare and the turtle)
by Jean de la Fontaine, you remember the cartoons ?
better get there than never.

have fun, and enjoy the sun
> > --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00377 for ; Thu, 20 Jul 2000 19:24:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:13 +0200 (MEST) Received: (qmail 31833 invoked by uid 0); 20 Jul 2000 07:16:18 -0000 Received: from hh.egroups.com (208.50.99.210) by mx06.rz2.gmx.net with SMTP; 20 Jul 2000 07:16:18 -0000 X-eGroups-Return: sentto-1101623-511-964077363-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 20 Jul 2000 07:16:02 -0000 Received: (qmail 12365 invoked from network); 20 Jul 2000 07:16:02 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 20 Jul 2000 07:16:02 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta1 with SMTP; 20 Jul 2000 07:16:02 -0000 Received: from 0018728164 (host-209-215-11-80.bix.bellsouth.net [209.215.11.80]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id DAA08383; Thu, 20 Jul 2000 03:15:59 -0400 (EDT) Message-ID: <001301bff21a$3e9532e0$500bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 20 Jul 2000 02:15:10 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VLIW Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BFF1F0.549A32E0" X-UIDL: 2bcb136f5010c32ada7ff8e95e2029d2 Status: R X-Status: N ------=_NextPart_000_0010_01BFF1F0.549A32E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MAXX - I agree with you in all respects. For example - Mr. Guidon = doesn't like LDA/STA machines. I don't either. Although I am using = Micro-Programming techniques; our designs are similar. To the Software Engineer; he sees: LDA STA BRANCH AREG =3D Zero At my level: Hardware Engineer, I see: LDA,STA Using both Instruction and Operand Look-ahead - which I have = implemented; the AREG is loaded, the Operand is passed to Store Pipe; and the BRANCH = is fully transparent if taken. If not taken; will execute a NOP. What I = accomplish at Hardware Level should not have ANY impact on the way a Programmer does = his thing - as long as it is a LOGICAL sequence. I'm certain you could HAND = CODE some of the stuff on the market today and cause failures in execution. I also use a Condition Code Register for Conditional Branches. The = decision logic is simply ONE Tri-State Gate. I also use ALL Four-Port = SRAM with the exception of Display Memory. Here I use Two-port. =20 As the Pipe-Line gets longer; I may Look-Ahead two Instructions for = JMP, JST, BRA and Interrupt. Incidently; the Interrupt Break - which is = essentialy a JST; is also transparent. Enough for today as I have to make a short trip and will be quiet = for a few days. Sincerely Richard E. Hartney Erin Greene & Associates Research Director ------=_NextPart_000_0010_01BFF1F0.549A32E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
MAXX - I agree with you in all respects.  For example - Mr. Guidon doesn't like
LDA/STA machines.  I don't either.  Although I am using Micro-Programming
techniques; our designs are similar.
    To the Software Engineer; he sees:
 
                LDA
                STA
                BRANCH AREG = Zero
 
    At my level: Hardware Engineer, I see:
 
                LDA,STA
 
    Using both Instruction and Operand Look-ahead - which I have implemented;
the AREG is loaded, the Operand is passed to Store Pipe; and the BRANCH is
fully transparent if taken.  If not taken; will execute a NOP.  What I accomplish at
Hardware Level should not have ANY impact on the way a Programmer does his
thing - as long as it is a LOGICAL sequence.  I'm certain you could HAND CODE
some of the stuff on the market today and cause failures in execution.
    I also use a Condition Code Register for Conditional Branches.  The decision logic is simply ONE Tri-State Gate.  I also use ALL Four-Port SRAM with the exception of Display Memory.  Here I use Two-port. 
    As the Pipe-Line gets longer; I may Look-Ahead two Instructions for JMP, JST,
BRA and Interrupt.  Incidently; the Interrupt Break - which is essentialy a JST; is
also transparent.
    Enough for today as I have to make a short trip and will be quiet for a few days.
 
Sincerely
Richard E. Hartney
Erin Greene & Associates
Research Director
 
 
------=_NextPart_000_0010_01BFF1F0.549A32E0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00380 for ; Thu, 20 Jul 2000 19:24:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 20 Jul 2000 19:24:14 +0200 (MEST) Received: (qmail 13066 invoked by uid 0); 20 Jul 2000 07:44:34 -0000 Received: from fl.egroups.com (208.50.144.74) by mx19.rz2.gmx.net with SMTP; 20 Jul 2000 07:44:34 -0000 X-eGroups-Return: sentto-1101623-512-964079072-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 20 Jul 2000 07:44:32 -0000 Received: (qmail 21384 invoked from network); 20 Jul 2000 07:44:32 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 20 Jul 2000 07:44:32 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 20 Jul 2000 07:44:32 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000720074431.WMK24904.mail.rdc1.wa.home.com@nventure.com> for ; Thu, 20 Jul 2000 00:44:31 -0700 Message-ID: <3976ADDE.77DBA34E@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> <39769908.EFBEA223@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 20 Jul 2000 00:44:33 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0a6df48064ac5cc7f231be58d1136ab4 Status: R X-Status: N Times change but tech strategies do not.  Developing the best proven
technology has always been the best strategy.  Tinkering with unproven
stuff tends to result in failure because problems with the technology
become insurmountable for small firms to tackle.  That, ultimately, was
why Cray failed with the Cray 3 and 4.  They simply ran out of money
even as the world's fastest supercomputer was being finished.  Cray
broke with his old strategy, trying to make GaAs work, despite it being
a new technology.  Now GaAs is being slowly abandoned despite its
incredible promise.  More likely is SiGe, since it makes good use of
enormous investments in Si process techology.

IIRC, both Crusoe and MAJC were 4-way VLIW's, but I'm not 100% sure
about either.  MAJC implementations will probably suffer a low clock
rate, though, because of their large rf's, 128 in total.  Experience
tells us you cannot have a large register file and a high clock rate, so
64 really is the limit.  That holds us down to 4-6 IPC before adding a
second LSU, and dual-ported data caches tend to be big and slow.  Two or
three IPC is the best you can get from one rf before adversly impacting
the clock.  Modern code has trouble doing better than this (never mind
streaming code, which is different).  I have designed everything around
three-way V/LIW with a small rf.  Such a small design enables the use of
unusual technology like bipolar and SiGe.  Remember that with a much
higher clock rate, rf-L1/0 bandwidth increases also, so a small rf isn't
as confining as one might think.  Moreover, setting the processor for
global mode, the running thread can move the "ThreadID Reg" around,
using the locals as a window, so you still get access to all 64 address
plus 64 data if you need them.  What's more, you can still leave one or
two banks empty to run background threads to fill memory stalls, none of
which need to know what has them running in Global Mode.

If the name VLIW still bothers you, remember Computer with Literal
Instruction Tranlation... etc.  That acronym may be better.


> >  Everyone said, "Look at how our peak performance is better than
> Cray's, "
> > while their actual performance on real applications sucked.
> >  If you can't get operands in, processed, and out in a hurry,
> > your design will suffer for it.
> >Point being that I like VLIW more for these very reasons.
> maybe you're missing a point or two with VLIW : if it's good at
> executing a lot
> of instructions, shoving them down in a fixed pipeline, that's all
> it's good for.
> OTOH Crays usually are good at "computing", in the arithmetic sense of
> the term.
> ie the CRAY2 took 2 cycles to decode an instruction.

VLIW is good for removing the major bottleneck that is the decode
hardware that has absolutely no reason for being.  A small, statically
scheduled core will always outperform the biggest, most elaborate
processors that use every cheap architectural frill to shorten the wires
around their artificially created obstacles.  V/LIW keeps everything
small and tight to begin with.  I really do believe in these
technologies.  If my life depended on it, I would build a bipolar
multi-threaded VLIW processor on Silicon Germanium.  All of these
technologies have had multiple companies invest millions into them.
There is plenty of technical expertise in all of these areas, and lots
of suppliers to choose from.

I simply believe that explicit parallelism is a more natural growth path
>from the original Microprocessor without Interlocked Pipelines than the
dynamically scheduled approach that has been taken in recent years; and
with improved register scheduling by compilers, the SIMD nature of the
data hardware, the use of multi-threading to overcome memory problems,
and the building of a processor consisting almost entirely of execution
hardware and caching, I feel relatively confident that such a small
design could outperform most competing proposals.

--Maxx
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA05315 for ; Fri, 21 Jul 2000 02:24:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 21 Jul 2000 02:24:41 +0200 (MEST) Received: (qmail 5189 invoked by uid 0); 20 Jul 2000 18:11:45 -0000 Received: from mk.egroups.com (207.138.41.165) by mx09.rz2.gmx.net with SMTP; 20 Jul 2000 18:11:45 -0000 X-eGroups-Return: sentto-1101623-513-964116697-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 20 Jul 2000 18:11:41 -0000 Received: (qmail 5747 invoked from network); 20 Jul 2000 18:11:36 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 20 Jul 2000 18:11:36 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 20 Jul 2000 18:11:35 -0000 Received: from f-cpu.org (nas1-132.ras.club-internet.fr [195.36.192.132]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA09321 for ; Thu, 20 Jul 2000 20:11:27 +0200 (MET DST) Message-ID: <397740A5.367470B0@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8kvv9r+54qn@eGroups.com> <397405A8.7C7FB636@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 20 Jul 2000 20:10:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: multipart/mixed; boundary="------------AC00874EBF094113DC2988E0" X-UIDL: 9b6d38b7f1e104ce04494d62f2044c5c Status: R X-Status: N --------------AC00874EBF094113DC2988E0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi !

old message :

Kai Wetzel wrote:
<snip>
> nicolas.boulay@ifrance.com wrote:
> [...]
> > > Comments please..??
<snip>
> > We can begin the
> > implementation of the different functionnal unit. But we didn't > > need them to write the simulator (the only difference is the
> > latencies of an operator).
>
> For the first FC0 arch. sim. a fairly accurate "gate delay" = will do
> but estimating the delay, unit size, and maximum throughput of
> the units won't always be enough for a CPU where it's exposed in the I= SA
> whether a unit takes 3 cycles to complete or 4 !
> For example I can't start thinking about pipelined FUs if it's
> not even clear what the limits are :=B0(

i believe that some of you have already written a more or less accurate
or working CPU simulator. like :

main () {
  for () {
    inst=3Dfetch();
    IP+IP+4;
    switch(inst[0]) { /* opcode byte */
       case load : load(); break;
       case store : store(); break;
       case nop : nop(); break;
       ...
       default: error("wrong opcode"= ;);
    }
  }

etc...

Now the goal is to go one step further : expose every pipeline stage and un= it.
they are described in the manual...

i have included some files, dated 4/4/2000 which start to secribe it.
it is not meant to be compiled (yet) because the decoder/registerset/Xbar parts are not correct yet, and i've redesigned the LSU.


As you may know, it is not possible to know excatly the propagation time of one unit in advance : as we get further down the micrometer, and faster<= BR> in GHz, the 3D RC-extraction ect are very difficult to make and it would no= t
be feasible to do a transistor-based time estimation : the geometry is
very important and it can only be done at the geometry level, and that's to= o
early now. The goal today is to prove that the pipeline is "foolproof&= quot;, stable,
has no side effect etc... there are design rules, however, that are applied= at
the schematic level (using a pen, a paper, and a brain), and they're used to design the units which are coded in C. Going to the transistor now would=
be suicidal because there's too much variety in the processes today and the=
design would be so specialized that nobody could fab it.

The design goals are rather weak when it comes to the latencies : this is due to the strong instruction ordering at the decode phase. if one unit
appears to be too slow, it can be easily split and if there's a remaining fraction left, it can be merged with the following stage of the pipeline. fixed size :
ROP2/combine : 1 cycle
ASU : 1 cycle (8-bits) or 2 cycles (16-64 bits)
INC/FindFirst : 1 cycle
POPCOUNT : unconstrained (mmm could be merged with the findfirst unit...)<= BR> L/SU : unconstrained
IMU : unconstrained but pipelined and less stages when the SIMD chunks are= smaller
IDU : idem but pipelined is not necessary (slow and not used much,
   could be hardwired in a small machine...)

That is valid for the FC0. The F-CPU in general does not specify instructio= n
latencies, because they are expected to vary greatly in the future. The num= bers
given above are not "firm" and can vary, depending on the impleme= ntation constraints.
The architecture simulator is meant to copy the behaviour of the pipeline s= tages
and should be modified accordingly.

OK OK i still have to scan and comment the schematics. sorry, i have to fin= ish my master
thesis before... :-(

have fun, and don't compile the code i sent, thank you for your compiler ;-= )

> Regards,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
--------------AC00874EBF094113DC2988E0 Content-Type: application/x-unknown-content-type-H_auto_file; name="SR.h" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="SR.h" LyoKIChDKSBmZWJydWFyeS1hcHJpbCAyMDAwIGJ5IFlhbm4gR1VJRE9OCiBmaXJzdCBwcm90 byBhdHRlbXB0LCBwcm9vZiBvZiBjb25jZXB0LCB0cmljayBnYWxsZXJ5Li4uCgpUaGlzIGRv Y3VtZW50IGlzIGRlcml2ZWQgZnJvbSB0aGUgYnVnZ3kgRi1DUFUgbWFudWFsIHJldi4gMC4x CmFuZCB3aWxsIGNoYW5nZSBxdWlja2x5LiBCZSBzdXJlIHRvIGRvd25sb2FkIHRoZSBtb3N0 IHJlY2VudAp2ZXJzaW9uIGFuZCBuZXZlciByZWx5IG9uIGl0LiBJdCBpcyBub3QgbWFkZSB0 byBiZSBjb21waWxlZApidXQgZ2l2ZXMgaW1wbGVtZW50YXRpb24gaGludHMgZm9yIHRyYW5z bGF0aW9uIHRvIEhETCAhCgpUaGlzICBpcyAgZnJlZSBzb2Z0d2FyZSA7IHNlZSB0aGUgR1BM IGZvciBjb3B5aW5nIGNvbmRprQp0aW9ucy4gIFRoZXJlIGlzIE5PIHdhcnJhbnR5IDsgbm90 IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWQpvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRS4gQnkgZGVmaW5pdGlvbiwgaXQKaXMgY29tcGxldGVseSBidWdneS4gWW91J3Zl IGJlZW4gd2FybmVkLgoKQXR0ZW50aW9uIDogc29tZSBwYXJ0cyByZWx5IG9uIFdPUkRfU0la RT09OCAod2hlcmUgbm90ZWQpLgoKY29udGFjdCB3aHlnZWVAZi1jcHUub3JnIG9yIGYtY3B1 QGVHcm91cHMuY29tCgoqLwoKI2lmbmRlZiBXT1JEX1NJWkUKI2RlZmluZSBXT1JEX1NJWkUg OAojZW5kaWYKCi8qIHByZWxpbWluYXJ5IGRlZmluaXRpb24sIG5vdCBmdWxseSBjb21wbHlp bmcgd2l0aCB0aGUgcmVhbCBJU0EgOiAqLwovKiAoZGVmaW5lZCBpbiBvcmRlcikgKi8KCiNk ZWZpbmUgU1JfTlVNQkVSUyAgICAgIDAKI2RlZmluZSBTUl9OVU1CRVJTX3ZhbCAgMTAgICAg ICAvKiAxMCBTUnMgYXJlIGltcGxlbWVudGVkIGluIHRoaXMgbW9kZWwgKi8KCiNkZWZpbmUg U1JfRkFNSUxZICAgICAgIDEKI2RlZmluZSBTUl9GQU1JTFlfdmFsICAgMHhGQzAgICAvKiBG LUNQVSBjb3JlIG51bWJlciwgb3Igd2hhdGV2ZXIgKi8KCiNkZWZpbmUgU1JfU1RFUFBJTkcg ICAgIDIKI2RlZmluZSBTUl9TVEVQUElOR192YWwgMHgxICAgICAvKiByZXZpc2lvbi9pbXBs ZW1lbnRhdGlvbiAqLwoKI2RlZmluZSBTUl9NQVhfU0laRSAgICAgMwojZGVmaW5lIFNSX01B WF9TSVpFX3ZhbCBXT1JEX1NJWkUgIC8qIGluIGJ5dGVzLCBhIHBvd2VyIG9mIHR3byA+PSA0 ICovCgojZGVmaW5lIFNSX1NJWkVfMSAgICAgICA0CiNkZWZpbmUgU1JfU0laRV8xX3ZhbCAg IDEgICAgICAgLyogU2l6ZSBhdHRyaWJ1dGUgMSwgaGFyZHdpcmVkIGlmIFNSX01BWF9TSVpF IDw9IDggKi8KCiNkZWZpbmUgU1JfU0laRV8yICAgICAgIDUKI2RlZmluZSBTUl9TSVpFXzJf dmFsICAgMiAgICAgICAvKiBTaXplIGF0dHJpYnV0ZSAyLCBoYXJkd2lyZWQgaWYgU1JfTUFY X1NJWkUgPD0gOCAqLwoKI2RlZmluZSBTUl9TSVpFXzMgICAgICAgNgojZGVmaW5lIFNSX1NJ WkVfM192YWwgICA0ICAgICAgIC8qIFNpemUgYXR0cmlidXRlIDMsIGhhcmR3aXJlZCBpZiBT Ul9NQVhfU0laRSA8PSA4ICovCgojZGVmaW5lIFNSX1NJWkVfNCAgICAgICA3CiNkZWZpbmUg U1JfU0laRV80X3ZhbCAgIDggICAgICAgLyogU2l6ZSBhdHRyaWJ1dGUgNCwgaGFyZHdpcmVk IGlmIFNSX01BWF9TSVpFIDw9IDggKi8KCiNkZWZpbmUgU1JfQ1lDTEUgICAgICAgIDgKCiNk ZWZpbmUgU1JfUEFHSU5HICAgICAgIDkKCgoKLyogcmVhZCBhbmQgd3JpdGUgbWFza3MgOiAq LwojZGVmaW5lIFNSX1JFQURfTUFTSyAgIDB4M0ZGICAgLyogd2UgY2FuIHJlYWQgYWxsIDEw IFNScyAqLwojZGVmaW5lIFNSX1dSSVRFX01BU0sgIDB4MzAwICAgLyogb25seSBTUiAjOCBh bmQgIzkgYXJlIHdyaXRlYWJsZSAqLwo= --------------AC00874EBF094113DC2988E0 Content-Type: application/x-unknown-content-type-H_auto_file; name="f-cpu_map.h" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f-cpu_map.h" DQojaWZuZGVmIF9fRkNQVV9NQVBfXw0KI2RlZmluZSBfX0ZDUFVfTUFQX18NCg0KLyoNCg0K ICAgIEYtQ1BVIE9QQ09ERSBNQVAsIFBSRUxJTUlOQVJZIFZFUlNJT04NCg0KICAgIChDKSBZ YW5uIEd1aWRvbiB2ZW4gbWFyIDMxIDE3OjA2OjQyIENFU1QgMjAwMA0KDQpUaGlzIGRvY3Vt ZW50IGlzIGRlcml2ZWQgZnJvbSB0aGUgYnVnZ3kgRi1DUFUgbWFudWFsIHJldi4gMC4xDQph bmQgd2lsbCBjaGFuZ2UgcXVpY2tseS4gQmUgc3VyZSB0byBkb3dubG9hZCB0aGUgbW9zdCBy ZWNlbnQNCnZlcnNpb24gYW5kIGluY2x1ZGUgaXQgYXMgImYtY3B1X21hcC5oIiBpbiB5b3Vy IGZpbGVzLg0KDQpUaGlzIGlzIGZyZWUgc29mdHdhcmUgOyBzZWUgdGhlIEdQTCBmb3IgY29w eWluZyBjb25kaa0NCnRpb25zLiBUaGVyZSBpcyBOTyB3YXJyYW50eSA7IG5vdCBldmVuIGZv ciBNRVJDSEFOVEFCSUxJVFkNCm9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF Lg0KDQp3aHlnZWVAZi1jcHUub3JnIG9yIGYtY3B1QGVHcm91cHMuY29tDQoNCg0KICBPcmdh bml6YXRpb24gb2YgdGhlIG9wY29kZXMgOg0KVGhlIGRlZmluZWQgbnVtYmVycyBhcmUgYSBi eXRlIGxvY2F0ZWQgaW4gYml0cyAwIHRvIDcgaW4gdGhlIGluc3RydWN0aW9uIHdvcmQuDQpU aGUgIi1JIiBzdWZmaXggaXMgb2RkLCBtZWFuaW5nIGk4cnIgZm9ybWF0ICh0aGlzIGNvdWxk IGJlIGNoYW5nZWQsIHRvIGEgTVNCIGZvciBleGFtcGxlKS4NClRoZSBpbnN0cnVjdGlvbiAi YmxvY2tzIiBhcmUgbm90IG11Y2ggbW9yZSB0aGFuIDMyIG9wY29kZXMgc28gdGhleSBjYW4g YmUgcGFja2VkDQogd2l0aCB0aGlzIGdyYW51bGFyaXR5Lg0KQWxsIHRoZXNlIG51bWJlcnMg d2lsbCBiZSByZW9yZ2FuaXplZCBsYXRlciBmb3IgdGhlIFZMSVcgYm91bmRhcnkgdHJpY2su DQoNCiB0b3RhbCBjb3VudCA6IDEwNCwgd2l0aG91dCBjb3VudGluZyBtdWx0aXBsZSBvY2N1 cmVuY2Ugb2YgQklUT1AoSSksDQpDT01CSU5FKHh4KSBhbmQgTE9BRENPTlMoWCkgDQoNCklm IGkgaGF2ZSB0aW1lIGFuZCBlbmVyZ3ksIGknbGwgbWFrZSBhIG5pY2UgY29sb3JlZCBIVE1M IHRhYmxlIG9uZSBkYXkuDQoqLw0KDQoNCi8qDQogRm9ybWF0IHplcm8gOiBSUlINCiAtLS0t LS0tLS0tLS0tLS0tLQ0KIGNvdW50PTQzDQoNCnRoaXMgdGFrZXMgb25lIGhhbGYgb2YgdGhl IHdob2xlIG9wY29kZSB0YWJsZSAoMjU2IGluc3RydWN0aW9ucykNCg0KKi8NCg0KLyogbm90 IGEgcmVhbCAib3BlcmF0aW9uIiBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgZGF0YSBhcmUgbm90 IG1vZGlmaWVkICovDQojZGVmaW5lIF9PUF9NT1ZFICAgICAgICAgMA0KLyogc28gTk9QIGlz IGRldGVjdGVkIHdpdGggYW4gaW5zdHJ1Y3Rpb24gZXF1YWwgdG8gemVybyAqLw0KDQovKiBJ bnRlZ2VyIGFyaXRobWV0aWNzICovDQojZGVmaW5lIF9PUF9BREQgICAgICAgICAgMg0KI2Rl ZmluZSBfT1BfU1VCICAgICAgICAgIDQNCiNkZWZpbmUgX09QX01VTCAgICAgICAgICA2DQoj ZGVmaW5lIF9PUF9ESVYgICAgICAgICAgOA0KI2RlZmluZSBfT1BfTU9EICAgICAgICAgIDEw DQojZGVmaW5lIF9PUF9BRERTVUIgICAgICAgMTINCiNkZWZpbmUgX09QX01BQyAgICAgICAg ICAxMw0KDQovKiBub3QgcmVhbGx5IGFyaXRobWV0aWMuLi4gKi8NCiNkZWZpbmUgX09QX1BP UENPVU5UICAgICAxNA0KDQovKiBJTkMtYmFzZWQgaW5zdHJ1Y3Rpb25zICovDQojZGVmaW5l IF9PUF9DTVBMICAgICAgICAgMjQNCiNkZWZpbmUgX09QX0NNUExFICAgICAgICAyNg0KI2Rl ZmluZSBfT1BfTUFYICAgICAgICAgIDI4DQojZGVmaW5lIF9PUF9NSU4gICAgICAgICAgMzAN CiNkZWZpbmUgX09QX1NPUlQgICAgICAgICAyMQ0KMTQNCi8qIExOUyBvcGVyYXRpb25zICov DQojZGVmaW5lIF9PUF9MQUREICAgICAgICAgMzINCiNkZWZpbmUgX09QX0xTVUIgICAgICAg ICAzMw0KDQovKiBTSEwgKCJzaHVmZmxlciIpIG9wZXJhdGlvbnMgKi8NCiNkZWZpbmUgX09Q X1NISUZUTCAgICAgICAzNg0KI2RlZmluZSBfT1BfU0hJRlRSICAgICAgIDM4DQojZGVmaW5l IF9PUF9TSElGVFJBICAgICAgNDANCiNkZWZpbmUgX09QX1JPVEwgICAgICAgICA0Mg0KI2Rl ZmluZSBfT1BfUk9UUiAgICAgICAgIDQ0DQojZGVmaW5lIF9PUF9CSVRPUCAgICAgICAgNDYN CiNkZWZpbmUgX09QX0JJVFJFViAgICAgICA0OA0KLyogU0lNRCBhbmQgYnl0ZS1zaHVmZmxp bmcgKi8NCiNkZWZpbmUgX09QX01JWCAgICAgICAgICA1Mg0KI2RlZmluZSBfT1BfRVhQQU5E ICAgICAgIDUzDQojZGVmaW5lIF9PUF9TRFVQICAgICAgICAgNTQNCg0KLyogUk9QMiB1bml0 IChub3QgY29tcGxldGUgOiBjb21iaW5lIGlzIG5ldykgKi8NCiNkZWZpbmUgX09QX0xPR0lD ICAgICAgICA1Ng0KI2RlZmluZSBfT1BfQ09NQklORV9PUiAgIDU4DQojZGVmaW5lIF9PUF9D T01CSU5FX0FORCAgNTkNCg0KLyogRlAgKG5vdCBjb21wbGV0ZSkgKi8NCiNkZWZpbmUgX09Q X0ZBREQgICAgICAgICA2NA0KI2RlZmluZSBfT1BfRlNVQiAgICAgICAgIDY1DQojZGVmaW5l IF9PUF9GTVVMICAgICAgICAgNjYNCiNkZWZpbmUgX09QX0ZESVYgICAgICAgICA3MQ0KI2Rl ZmluZSBfT1BfRk1BQyAgICAgICAgIDc1DQojZGVmaW5lIF9PUF9GQUREU1VCICAgICAgNzYN Cg0KLyogTFNVLCBkb21lIGZvcm1zIGFyIGFsc28gaW4gaW50ZXJtZWRpYXJ5IGZvcm1hdCAq Lw0KI2RlZmluZSBfT1BfTE9BRCAgICAgICAgIDgwDQojZGVmaW5lIF9PUF9MT0FERiAgICAg ICAgODINCiNkZWZpbmUgX09QX1NUT1JFICAgICAgICA4NA0KI2RlZmluZSBfT1BfU1RPUkVG ICAgICAgIDg2DQojZGVmaW5lIF9PUF9DQUNIRU1NICAgICAgODgNCg0KLyogTUlTQyA6ICov DQovKiBTUkIgOiAqLw0KI2RlZmluZSBfT1BfTE9BRE0gICAgICAgIDEwOA0KI2RlZmluZSBf T1BfU1RPUkVNICAgICAgIDExMA0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZpbmUg X09QX0pNUEEgICAgICAgICAxMTYNCg0KDQovKg0KIGludGVybWVkaWFyeSBmb3JtYXQgOiBS Ug0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIGNhbiBiZWxvbmcgdG8gZWl0aGVyIFJS UiBvciBJOFJSIChSUlIgc2VlbXMgYmV0dGVyKQ0KIGNvdW50PTE1DQoqLw0KDQovKiBJTkMt YmFzZWQgaW5zdHJ1Y3Rpb25zICovDQojZGVmaW5lIF9PUF9JTkMgICAgICAgICAgMTYNCi8q IHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25zIGNhbiBiZQ0KICAgZW5jb2RlZCBpbiB0aGUgYml0 cyAxMiBhbmQgMTMgDQogICAjZGVmaW5lIF9PUF9ERUMgICAgICAgICAgMTcNCiAgICNkZWZp bmUgX09QX05FRyAgICAgICAgICAxOA0KICAgI2RlZmluZSBfT1BfQUJTICAgICAgICAgIDE5 DQoqLw0KI2RlZmluZSBfT1BfU0NBTiAgICAgICAgIDIwDQoNCi8qIExOUyBvcGVyYXRpb25z ICovDQojZGVmaW5lIF9PUF9MMklOVCAgICAgICAgMzQNCiNkZWZpbmUgX09QX0lOVDJMICAg ICAgICAzNQ0KDQovKiBTSU1EIGFuZCBieXRlLXNodWZmbGluZyAqLw0KI2RlZmluZSBfT1Bf QllURVJFViAgICAgIDUwDQoNCi8qIEZQLCBub3QgY29tcGxldGUgKi8NCiNkZWZpbmUgX09Q X0YySU5UICAgICAgICA2Nw0KI2RlZmluZSBfT1BfSU5UMkYgICAgICAgIDY4DQojZGVmaW5l IF9PUF9GSUFQUlggICAgICAgNjkNCiNkZWZpbmUgX09QX0ZTUVJUSUFQUlggICA3MA0KI2Rl ZmluZSBfT1BfRlNRUlQgICAgICAgIDcyDQojZGVmaW5lIF9PUF9GTE9HICAgICAgICAgNzMN CiNkZWZpbmUgX09QX0ZFWFAgICAgICAgICA3NA0KDQovKiBNSVNDIDogKi8NCi8qIFNQUiA6 ICovDQojZGVmaW5lIF9PUF9HRVQgICAgICAgICAgMTA0DQojZGVmaW5lIF9PUF9QVVQgICAg ICAgICAgMTA2DQoNCi8qIGNvbnRyb2wtcmVsYXRlZCAqLw0KI2RlZmluZSBfT1BfTE9PUCAg ICAgICAgIDExNw0KDQovKg0KIEZvcm1hdCBvbmUgOiBJOFJSDQogLS0tLS0tLS0tLS0tLS0t LS0NCiAocGx1cyBzaWduIGJpdCBpbiBhIDl0aCBiaXQpDQogY291bnQ9MjcNCg0KIGNoYWxs ZW5nZSA6IG1hcCBpdCBzbyBpdCBjb3JyZXNwb25kcyB0byB0aGUgUlJSIGZvcm1hdCB3aGVu ZXZlciBwb3NzaWJsZS4NCg0KKi8NCg0KLyogSW50ZWdlciBhcml0aG1ldGljcyAqLw0KDQoj ZGVmaW5lIF9PUF9BRERJICAgICAgICAgMw0KI2RlZmluZSBfT1BfU1VCSSAgICAgICAgIDUN CiNkZWZpbmUgX09QX01VTEkgICAgICAgICA3DQojZGVmaW5lIF9PUF9ESVZJICAgICAgICAg OQ0KI2RlZmluZSBfT1BfTU9ESSAgICAgICAgIDExDQoNCi8qIElOQy1iYXNlZCBpbnN0cnVj dGlvbnMgKi8NCg0KI2RlZmluZSBfT1BfQ01QTEkgICAgICAgIDI1DQojZGVmaW5lIF9PUF9D TVBMRUkgICAgICAgMjcNCiNkZWZpbmUgX09QX01BWEkgICAgICAgICAyOQ0KI2RlZmluZSBf T1BfTUlOSSAgICAgICAgIDMxDQoNCi8qIG5vdCByZWFsbHkgYXJpdGhtZXRpYyAqLw0KI2Rl ZmluZSBfT1BfUE9QQ09VTlRJICAgIDE1DQoNCi8qIFNITCAoInNodWZmbGVyIikgb3BlcmF0 aW9ucyAqLw0KI2RlZmluZSBfT1BfU0hJRlRMSSAgICAgIDM3DQojZGVmaW5lIF9PUF9TSElG VFJJICAgICAgMzkNCiNkZWZpbmUgX09QX1NISUZUUkFJICAgICA0MQ0KI2RlZmluZSBfT1Bf Uk9UTEkgICAgICAgIDQzDQojZGVmaW5lIF9PUF9ST1RSSSAgICAgICAgNDUNCiNkZWZpbmUg X09QX0JJVE9QSSAgICAgICA0Nw0KI2RlZmluZSBfT1BfQklUUkVWSSAgICAgIDQ5DQovKiBT SU1EIGFuZCBieXRlLXNodWZmbGluZyAqLw0KI2RlZmluZSBfT1BfU0RVUEkgICAgICAgIDU1 DQoNCi8qIFJPUDIgdW5pdCAobm90IGNvbXBsZXRlIDogY29tYmluZSBpcyBuZXcpICovDQoj ZGVmaW5lIF9PUF9MT0dJQ0kgICAgICAgNTcNCiNkZWZpbmUgX09QX0NPTUJJTkVfT1JJICA2 MA0KI2RlZmluZSBfT1BfQ09NQklORV9BTkRJIDYxDQoNCi8qIExTVSAqLw0KI2RlZmluZSBf T1BfTE9BREkgICAgICAgIDgxDQojZGVmaW5lIF9PUF9MT0FESUYgICAgICAgODMNCiNkZWZp bmUgX09QX1NUT1JFSSAgICAgICA4NQ0KI2RlZmluZSBfT1BfU1RPUkVJRiAgICAgIDg3DQoj ZGVmaW5lIF9PUF9DQUNIRU1NSSAgICAgODgNCg0KLyogU1JCIDogKi8NCiNkZWZpbmUgX09Q X0xPQURNSSAgICAgICAxMDkNCiNkZWZpbmUgX09QX1NUT1JFTUkgICAgICAxMTENCg0KLyoN CiBGb3JtYXQgdHdvIDogSTE2Ug0KIC0tLS0tLS0tLS0tLS0tLS0tDQogY291bnQ9MTINCiAq Lw0KDQovKiBNSVNDIDogKi8NCi8qIGNsb3NlIHRvIF9PUF9NT1ZFICovDQojZGVmaW5lIF9P UF9MT0FEQ09OUyAgICAgOTYgICAvKiA0LW9wY29kZSByYW5nZSBzbyB3ZSBjYW4gY3JlYXRl IDI1Ni1iaXQgaW1tZWRpYXRlcyAqLw0KI2RlZmluZSBfT1BfTE9BRENPTlNYICAgIDEwMCAg LyogaWRlbSAqLw0KLyogU1BSIDogKi8NCiNkZWZpbmUgX09QX0dFVEkgICAgICAgICAxMDUN CiNkZWZpbmUgX09QX1BVVEkgICAgICAgICAxMDcNCg0KLyogY29udHJvbC1yZWxhdGVkICov DQojZGVmaW5lIF9PUF9MT0FEQUREUiAgICAgMTE0DQojZGVmaW5lIF9PUF9MT0FEQUREUkkg ICAgMTE1DQoNCi8qDQogRm9ybWF0IHRocmVlIDogSTI0DQogLS0tLS0tLS0tLS0tLS0tLS0t DQogY291bnQ9Nw0KKi8NCg0KLyogU1JCIDogKi8NCiNkZWZpbmUgX09QX1NSQl9TQVZFICAg ICAxMTINCiNkZWZpbmUgX09QX1NSQl9SRVNUT1JFICAxMTMNCi8qIGNvbnRyb2wtcmVsYXRl ZCAqLw0KI2RlZmluZSBfT1BfU1lTQ0FMTCAgICAgIDExOA0KI2RlZmluZSBfT1BfUkZFICAg ICAgICAgIDExOQ0KI2RlZmluZSBfT1BfSEFMVCAgICAgICAgIDEyMA0KI2RlZmluZSBfT1Bf U0VSSUFMSVpFICAgIDEyMQ0KI2RlZmluZSBfT1BfSU5TX1BBQ0sgICAgIDEyMg0KDQoNCg0K LyogRkMwIEV4ZWN1dGlvbiBVbml0cyAgKi8NCg0KLyogQWRkL1N1YiBVbml0ICovDQojZGVm aW5lIEZDMF9FVV9BU1UgICAgICAgICAgMQ0KLyogSW50ZWdlciBNdWx0aXBseSBVbml0ICov IA0KI2RlZmluZSBGQzBfRVVfSU1VICAgICAgICAgIDINCi8qIEludGVnZXIgRGl2aWRlIFVu aXQgKi8NCiNkZWZpbmUgRkMwX0VVX0lEVSAgICAgICAgICAzDQovKiBiaXQgIlNodWZmbGVy IiAqLw0KI2RlZmluZSBGQzBfRVVfU0hMICAgICAgICAgIDQNCi8qICJJbmNyZW1lbnRlciIg Ki8NCiNkZWZpbmUgRkMwX0VVX0lOQyAgICAgICAgICA1DQovKiBib29sZWFuIG9wZXJhdGlv bnMgKi8NCiNkZWZpbmUgRkMwX0VVX1JPUDIgICAgICAgICA2DQovKiBMb2FkL1N0b3JlIFVu aXQgKi8NCiNkZWZpbmUgRkMwX0VVX0xTVSAgICAgICAgICA3DQovKiBTcGVjaWFsIFJlZ2lz dGVyIFVuaXQgKi8NCiNkZWZpbmUgRkMwX0VVX1NSVSAgICAgICAgICA4DQovKiBQT1B1bGF0 aW9uIGNvdW50ICovDQojZGVmaW5lIEZDMF9FVV9QT1AgICAgICAgICAgOQ0KDQojZGVmaW5l IE1BWF9GQzBfRVUgICAgICAgICAgMTANCi8qIHdpbGwgY2hhbmdlIGxhdGVyICovDQoNCg0K I2VuZGlmDQo= --------------AC00874EBF094113DC2988E0 Content-Type: application/x-unknown-content-type-C_auto_file; name="Arch5.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Arch5.c" Lyo8aHRtbD48dGl0bGU+PC90aXRsZT48Ym9keSBmZ2NvbG9yPSIjMDAwMDAwIiBiZ2NvbG9y PSIjRkZGRkZGIj48UFJFPgoKIChDKSBmZWJydWFyeS1hcHJpbCAyMDAwIGJ5IFlhbm4gR1VJ RE9OCiBmaXJzdCBwcm90byBhdHRlbXB0LCBwcm9vZiBvZiBjb25jZXB0LCB0cmljayBnYWxs ZXJ5Li4uCgpUaGlzIGRvY3VtZW50IGlzIGRlcml2ZWQgZnJvbSB0aGUgYnVnZ3kgRi1DUFUg bWFudWFsIHJldi4gMC4xCmFuZCB3aWxsIGNoYW5nZSBxdWlja2x5LiBCZSBzdXJlIHRvIGRv d25sb2FkIHRoZSBtb3N0IHJlY2VudAp2ZXJzaW9uIGFuZCBuZXZlciByZWx5IG9uIGl0LiBJ dCBpcyBub3QgbWFkZSB0byBiZSBjb21waWxlZApidXQgZ2l2ZXMgaW1wbGVtZW50YXRpb24g aGludHMgZm9yIHRyYW5zbGF0aW9uIHRvIEhETCAhCgpUaGlzIGlzIGZyZWUgc29mdHdhcmUg OyBzZWUgdGhlIEdQTCBmb3IgY29weWluZyBjb25kaa0KdGlvbnMuIFRoZXJlIGlzIE5PIHdh cnJhbnR5IDsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWQpvciBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4gQnkgZGVmaW5pdGlvbiwgaXQKaXMgY29tcGxldGVseSBi dWdneS4gWW91J3ZlIGJlZW4gd2FybmVkLgoKPGZvbnQgY29sb3I9IiNDMDAwMDAiPkF0dGVu dGlvbiA6IHNvbWUgcGFydHMgcmVseSBvbiBXT1JEX1NJWkU9PTggKHdoZXJlIG5vdGVkKS48 L2ZvbnQ+Cgpjb250YWN0IHdoeWdlZUBmLWNwdS5vcmcgb3IgZi1jcHVAZUdyb3Vwcy5jb20K CiovCgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8 c3RyaW5nLmg+CgovKiB0aGUgb3Bjb2RlIG1hcCA6ICovCiNpbmNsdWRlICJmLWNwdV9tYXAu aCIKCi8qPGZvbnQgY29sb3I9IiMwMDAwQzAiPgogZGVmaW5pdGlvbiBvZiB0aGUgYXJjaGl0 ZWN0dXJlIHBhcmFtZXRlcnMgaGVyZSA6CiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPC9mb250PiAqLwoKLyogaW5zdHJ1Y3Rpb24gc2l6ZSA9 IDQgYnl0ZXMgKGl0J3Mgbm90IHdvcnRoICNkZWZpbmluZyBpdC4uLikgKi8KCi8qIHNpemUg b2YgYSByZWdpc3RlciB3b3JkIDogNjQgYml0cyAqLwojZGVmaW5lIFdPUkRfU0laRSAgICAg IDgKCi8qIHdpZHRoIG9mIGEgY2FjaGUgbGluZSA6IDI1NiBiaXRzKi8KI2RlZmluZSBDQUNI RUxJTkVXSURUSCAzMgoKLyogd2lkdGggb2YgdGhlIG1haW4gbWVtb3J5IGJ1cyA6IDY0IGJp dHMgKi8KI2RlZmluZSBNRU1PUllCVVNXSURUSCA4CgovKiB0aGVyZSBhcmUgOCBtZW1vcnkg YnVmZmVyIGxpbmVzIG9mIDI1NiBiaXRzIGVhY2guICovCiNkZWZpbmUgTElORUNPVU5UICAg ICAgOAoKLyogdGhlcmUgaXMgMktCIG9mIGluc3RydWN0aW9uIGNhY2hlIG1lbW9yeSAqLwoj ZGVmaW5lIElDQUNIRUxJTkVTICAgIDI1NgoKLyogTWF4aW11bSBwaXBlbGluZSBkZXB0aCA6 IChhcmJpdHJhcnkpICovCiNkZWZpbmUgTUFYREVQVEggOAoKI2luY2x1ZGUgIlNSLmgiCgoK dHlwZWRlZiBzdHJ1Y3QgcmVnX3N0cnVjdCB7CiAgdW5zaWduZWQgY2hhciB2YWxbV09SRF9T SVpFXTsKCiAgdW5zaWduZWQgaW50IGZzbTsgICAgICAgICAvKiBmaW5pdGUgc3RhdGUgbWFj aGluZSwgb3Igc2hpZnQgcmVnaXN0ZXIgKGhlcmUpICovCiAgICAgIC8qIHZhbHVlcyA6CiAg ICAgICAwIDogbm90aGluZyB0byBkbywgcmVnaXN0ZXIgcmVhZHkKICAgICAgIDEgOiB3cml0 ZSB0aGUgcmVnaXN0ZXIgZHVyaW5nIHRoaXMgY3ljbGUKICAgICAgIDIgOiB2YWx1ZSBpcyBh dmFpbGFibGUgb24gdGhlIFhiYXIKICAgICAgIG1vcmUgOiB2YWx1ZSBpcyBiZWluZyBjb21w dXRlZAogICAgICAqLwogIHVuc2lnbmVkIGludCB3YWl0X2ZsYWc7ICAgLyogc2V0IGlmIHdl IGFyZSB3YWl0aW5nIGZvciB0aGUgcmVzdWx0IG9mIGFuIGFzeW5jaHJvbm91cyB1bml0ICov CiAgICAgLyogaXQncyBwYXJ0IG9mIHRoZSBGU00gbWVjaGFuaXNtLi4uICovCgogIHVuc2ln bmVkIGludCB6ZXJvOyAvKiBlYWNoIGJpdCByZXByZXNlbnRzIGEgYnl0ZSBvZiB0aGUgcmVn aXN0ZXIsCiAgICAgdGhhdCBpcyB6ZXJvIGlmIHRoZSBieXRlIGlzIGNsZWFyZWQuIGl0IHJl cHJlc2VudHMgYSAyLWxldmVsLCA2NC1pbiBPUiBnYXRlLAogICAgIHdoZXJlIG9ubHkgdGhl IGJ5dGUgaW50ZXJtZWRpYXJ5IGJ5dGUgcmVzdWx0cyBhcmUgc3RvcmVkIChsYXRjaGVkKSwg bm90IHRoZSB0b3AtbGV2ZWwgcmVzdWx0LiAqLwoKfSBSN1s2NF07IC8qIFswXSBpcyBub3Qg dXNlZC4uLiBoYXJkd2lyZWQuLi4gKi8KCi8qIHRoaXMgdGFibGUgZ2l2ZXMgdGhlIGxhdGVu Y3kgb2YgZXZlcnkgc3VwcG9ydGVkIGluc3RydWN0aW9uIDogKi8KdW5zaWduZWQgaW50IElu c3RydWN0aW9uTGF0ZW5jeVsyNTZdOyAKICAvKiBtdXN0IGJlIGNvbXB1dGVkIHNvbWV3aGVy ZSAqLwoKLyogdGhlIENvbnRyb2wgRklGTyAqLwp0eXBlZGVmIHN0cnVjdCBmaWZvX3N0cnVj dCB7CiAgLyogZm9yIGVhY2ggY3ljbGUgdGhlcmUgYXJlIHR3byBwb3NzaWJsZSBidXNzZXMg Zm9yIHdyaXRlcyA6ICovCiAgdW5zaWduZWQgaW50IHcxYnVzeSwKICB1bnNpZ25lZCBpbnQg dzFyZWdpc3RlciwKICB1bnNpZ25lZCBpbnQgdzFFVSwKICB1bnNpZ25lZCBpbnQgdzJidXN5 LAogIHVuc2lnbmVkIGludCB3MnJlZ2lzdGVyLAogIHVuc2lnbmVkIGludCB3MkVVCn0gRklG T1tNQVhERVBUSF07CgovKiA8Zm9udCBjb2xvcj0iIzAwQjAwMCI+IHRoZXJlIGlzIDEgYml0 IGZvciB0aGUgImJ1c3kiIGJpdCAocmF0aGVyIHRoYW4gYSBPUiBvZiB0aGUgcmVnaXN0ZXIg ZmllbGQpLgoKRklGTygwKSBpcyB0aGUgcmVnaXN0ZXIvdmFsdWUgcHJlc2VudCBhdCB0aGUg bW9tZW50IG9uIHRoZSBYYmFyIHBvcnRzLgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCgpBZHZpY2UgZm9yIGEgNjQtYml0IGltcGxlbWVudGF0aW9u IGZvbGxvd3MgOgoKIDMgYml0cyBmb3IgdGhlICJidXN5IiBmb3JtYXQgOgotIDEgYml0IGZv ciB0aGUgdHlwZSBvZiBmb3JtYXQgKDAgZm9yICJsb2FkY29ucyIgZm9ybWF0LCAxIGZvciAi cmVnaXN0ZXIiIGZvcm1hdCkKLSAyIGJpdHMgZm9yIHNpemUvZGlzcGxhY2VtZW50CgogIGYg ICBjb25zICByZWcKICAwICAgYjAgICAgOExTQgogIDEgICBiMTYgICAxNkxTQgogIDIgICBi MzIgICAzMkxTQgogIDMgICBiNDggICA2NExTQgoKdGhlcmUgYXJlIDUgImRvbWFpbnMiIDog KGlmIHdlIGFyZSBpbiBhIDY0LWJpdCBDUFUpCiAgICAgICAgICAgICAgICAgICAgIGIwICAg IGIxNiAgICBiMzIgICAgYjQ4ICAgIDhMU0IgIDE2TFNCIDMyTFNCIDY0TFNCCmYwICAgICAg ICAgICAgICAgICAgICAgICAgICogICAgICAgICAgICAgKiAgICAgICAgICAgICogICAgICAg ICAgICoKZjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogICAgICAqICAgICAg ICAgICAgICAgICAgKiAgICAgKgpmMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAqICAgICAqICAgICAqICAgICAqCgogLSBkMD0gYml0c1swOjddICAg PSAqICAgICAgICAgICAgICAgICAgICAgICAgICAqICAgICAqICAgICAqICAgICAqICAgICAg PSBmMisgLyhmMCtmMSkKIC0gZDE9IGJpdHNbODoxNV0gID0gKiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKiAgICAgKiAgICAgKiAgICAgID0gCiAtIGQyPSBiaXRzWzE2OjMx XSA9ICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogICAgICogICAg ICA9CiAtIGQzPSBiaXRzWzMyOjQ3XSA9ICAgICAgICAgICAgICAqICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICogICAgICA9IAogLSBkND0gYml0c1s0ODo2M10gPSAgICAgICAg ICAgICAgICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAqICAgICAgPSBmMC5mMQoK VGhhdCdzIGZvciB0aGUgaW1wbGVtZW50YXRpb24gYWR2aWNlcyBhbmQgdGhlIHNpbXBsaWZp Y2F0aW9uLiBZZXQsIG5vdGhpbmcga2VlcHMgdXMgCmZyb20gdXNpbmcgYSBkdW1iIGJ5dGUg bWFzay4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCjwv Zm9udD4qLwoKCgovKiBpbnRlcm5hbCBkYXRhIG9mIHRoZSBTUiB1bml0IDogKi8KdW5zaWdu ZWQgY2hhciBTUl9idWZmZXIgW1NSX05VTUJFUlNdW1dPUkRfU0laRV0sCgovKiBkZWNvZGlu ZyBzdGFnZSwgcmVnaXN0ZXIgcmVhZCAqLwoKCi8qIGRlY29kaW5nIHN0YWdlLCByZWdpc3Rl ciB3cml0ZSAqLwoKLyogWGJhciBidWZmZXJzIDogKi8KCgovKiBpbnB1dCBvZiB0aGUgZXhl Y3V0aW9uIHVuaXRzIDogKi8KICBYYmFyUmVhZDFPdXQyW1dPUkRfU0laRV0sWGJhclJlYWQy T3V0MltXT1JEX1NJWkVdLFhiYXJSZWFkM091dDJbV09SRF9TSVpFXSwKCgovKiBvdXRwdXQg b2YgdGhlIGV4ZWN1dGlvbiB1bml0cyA6ICovCiAgUk9QMl9vdXRbV09SRF9TSVpFXSwgLyog Y29ubmVjdGVkIHRvIGJvdGggWGJhciByZXN1bHQgYnVzIDEgYW5kIDIgKi8KICBBU1Vfb3V0 MXJlc3VsdFtXT1JEX1NJWkVdLCAvKiBBU1UgcGlwZSBzdGFnZSAjMSAqLyAvKiBjb25uZWN0 ZWQgdG8gYm90aCBYYmFyIHJlc3VsdCBidXMgMSBhbmQgMiAqLwogIEFTVV9vdXQycmVzdWx0 W1dPUkRfU0laRV0sIC8qIEFTVSBwaXBlIHN0YWdlICMyICovIC8qIGNvbm5lY3RlZCB0byBi b3RoIFhiYXIgcmVzdWx0IGJ1cyAxIGFuZCAyICovCiAgQVNVX291dDFjYXJyeVtXT1JEX1NJ WkVdLCAgLyogQVNVIHBpcGUgc3RhZ2UgIzEgKi8gLyogY29ubmVjdGVkIG9ubHkgdG8gWGJh ciByZXN1bHQgYnVzIDIgLi4uICovCiAgQVNVX291dDJjYXJyeVtXT1JEX1NJWkVdOyAgLyog QVNVIHBpcGUgc3RhZ2UgIzIgKi8gLyogLi4uIGNveiB3aGVuIGl0J3MgdXNlZCwgaXQncyBv bmx5IGluIDJyMlcgbW9kZSAqLwoKdW5zaWduZWQgaW50IHNpbWRfc2l6ZSxzaW1kX3NpemUw LHNpbWRfc2l6ZTEsc2ltZF9zaXplMjsgLyogcGlwZWxpbmUgZm9yIHRoZSBzaXplIG9mIHRo ZSBTSU1EIHBhY2tldHMgKi8KCi8qIGxpdHRsZSBieXRlLW9yaWVudGVkIHV0aWxpdHkgKi8K dm9pZCBzZXQodW5zaWduZWQgY2hhciAqZGVzdCwgdW5zaWduZWQgaW50IHZhbCwgdW5zaWdu ZWQgaW50IHNpemUpIHsKICBpbnQgaT0wOwogIHdoaWxlICh2YWwpIHsKICAgIGRlc3RbaSsr XT0odmFsICYgMjU1KTsKICAgIGlmIChpPj1zaXplKQogICAgICByZXR1cm47CiAgICB2YWw+ Pj04OwogIH0KfQoKdm9pZCBwcmludF82NCh1bnNpZ25lZCBjaGFyICpwKSB7CiAgcHJpbnRm ICgiICUwMlglMDJYJTAyWCUwMlglMDJYJTAyWCUwMlglMDJYICIsKihwKzcpLCoocCs2KSwq KHArNSksKihwKzQpLCoocCszKSwqKHArMiksKihwKzEpLCpwKTsKfQoKdm9pZCBwcmludF9p bnN0cnVjdGlvbih1bnNpZ25lZCBjaGFyICpwKSB7CiAgcHJpbnRmICgiICUwMlglMDJYJTAy WCUwMlggIiwqcCwqKHArMSksKihwKzIpLCoocCszKSk7Cn0KCgp2b2lkIGN5Y2xlX0FTVSgp eyAvKiB3YXJuaW5nICEgNjQtYml0IHZlcnNpb24gb25seSAodGVzdGVkIGFueXdheSkgKi8K ICBzaWduZWQgaW50IGk9MCwgaiwgaywgbDsKCiAgLyogbGFzdCBwYXJ0IG9mIHRoZSBwaXBl bGluZSwgYmVmb3JlIHdlIGZsdXNoIHRoZSB0ZW1wb3JhcnkKICAgICAgcmVzdWx0IChlY29u b215IG9mIEMgd3JpdGluZywgTk9UIGhhcmR3YXJlIGFjY3VyYXRlICEpICovCgogIGlmICgo QVNVX29wZXJhdGlvbjIhPTApJiYoc2ltZF9zaXplMiA+IDEpKSB7IC8qIGRvbid0IGNvbXB1 dGUgaWYgd2UgbmVlZGVkIGEgYnl0ZSByZXN1bHQgb25seSAqLwogICAgd2hpbGUgKGkgPCBX T1JEX1NJWkUpIHsgLyogc2NhbiB0aGUgd29yZCAqLwogICAgICBqPTA7IC8qIGNsZWFyIHRo ZSBjYXJyeSAqLwogICAgICBsPWk7IC8qIHJlbWVtYmVyIHdoZXJlIHdlIHN0YXJ0ZWQgLT4g c2NhbiBjYXJyeSBsYXRlciAqLwogICAgICBmb3IgKGs9MDtrIDwgc2ltZF9zaXplMjtrKysp IHsgLyogY291bGQgaXQgYmUgbW9kaWZpZWQgdG8gYSAibWFzayBhbmQgdGVzdCIgYWxnbyA/ Li4uICovCglqKz0oQVNVX291dDFyZXN1bHRbaV18KChzaWduZWQgY2hhcilBU1Vfb3V0MWNh cnJ5W2ldKSA8PCA4KTsKCUFTVV9vdXQycmVzdWx0W2krK109KHVuc2lnbmVkIGNoYXIpajsK CWo+Pj04OwogICAgICB9CiAgICAgIGZvciAoaz0wO2sgPCBzaW1kX3NpemUyO2srKyl7CglB U1Vfb3V0MmNhcnJ5W2wra109ajsgLyogaiBzaG91bGQgYmUgemVybywgMSBvciAtMSAqLwoJ aj4+PTg7IC8qIHNoaWZ0IG91dCAxLCBvciBrZWVwIC0xICovCiAgICAgIH0KICAgIH0KICB9 ICAKICAgIAovKiBwcm9wYWdhdGlvbiBpbiB0aGUgcGlwZWxpbmUgOiAoY291bGQgYmUgYXZv aWRlZCBpZiBzZWVuIHdpdGggYSBsYXJnZXIgYW5hbHlzaXMgW2NvbnRyb2wgc2lnbmFsc10p ICovCiAgQVNVX29wZXJhdGlvbjI9QVNVX29wZXJhdGlvbjE7CiAgc2ltZF9zaXplMj1zaW1k X3NpemUxOwoKICAvKiBmaXJzdCBwYXJ0IG9mIHRoZSBwaXBlbGluZSA6IDggKiA4LWJpdCBh ZGRlcnMgKi8KICBpZiAoQVNVX29wZXJhdGlvbjEpIHsKICAgIGlmIChBU1Vfb3BlcmF0aW9u MT09MSkgeyAvKiBBREQgKi8KICAgICAgZm9yIChpPTA7IGkgPCBXT1JEX1NJWkU7IGkrKykg ewoJaj1YYmFyUmVhZDJPdXQyW2ldK1hiYXJSZWFkM091dDJbaV07CiAgICAgICAgQVNVX291 dDFyZXN1bHRbaV09KHVuc2lnbmVkIGNoYXIpajsKICAgICAgICBBU1Vfb3V0MWNhcnJ5W2ld PSh1bnNpZ25lZCBjaGFyKShqPj44KTsKICAgICAgfQogICAgfSBlbHNlIHsgLyogU1VCICov CiAgICAgIC8qIGNvdWxkIGhhdmUgdXNlZCB0aGUgY2FycnkreG9yIHRyaWNrICovCiAgICAg IGZvciAoaT0wOyBpPCBXT1JEX1NJWkU7IGkrKykgewoJaj1YYmFyUmVhZDJPdXQyW2ldLVhi YXJSZWFkM091dDJbaV07CiAgICAgICAgQVNVX291dDFyZXN1bHRbaV09KHVuc2lnbmVkIGNo YXIpajsKICAgICAgICBBU1Vfb3V0MWNhcnJ5W2ldPSh1bnNpZ25lZCBjaGFyKShqPj44KTsg IC8qIG5vdGljZSB0aGF0IHRoZSBjYXJyeSBvdXRwdXRzIGFyZSBvbmx5IC0xLCAwIG9yIDEg Ki8KICAgICAgfQogICAgfQogIH0KfQoKY2hhciByZXN1bHRfcm9wMltXT1JEX1NJWkVdOwoK dm9pZCBjeWNsZV9ST1AyKCl7CiAgLyogc3RheSB0dW5lZCAqLyAgCiAgCn0KCmNoYXIgcmVz dWx0X2luY1tXT1JEX1NJWkVdOwoKdm9pZCBjeWNsZV9JTkMoKXsgICAgLyogb25seSB3b3Jk IGluY3JlbWVudCBpcyBkb25lIHlldCAqLwogIHNpZ25lZCBpbnQgaT0wLCBqLCBrLCBsOwog IHdoaWxlIChpIDwgV09SRF9TSVpFKSB7CiAgICBqPTE7CiAgICBmb3IgKGs9MDtrIDwgc2lt ZF9zaXplMTtrKyspIHsKICAgICAgais9WGJhclJlYWQyT3V0MltpXTsKICAgICAgcmVzdWx0 X2luY1tpKytdPSh1bnNpZ25lZCBjaGFyKWo7CiAgICB9CiAgfSAKCn0KCnZvaWQgY3ljbGVf UE9QKCl7CiAgLyogcmVnaXN0ZXIgMSA6IHNvdXJjZSByZWdpc3RlciwgcmVnaXN0ZXIgMiA6 IHN1YnN0cmFjdCBhbW91bnQgKi8gIAoKCn0KCgovKiBTcGVjaWFsIFJlZ2lzdGVyIFVuaXQg KFNSVSkgKi8KCiAgLyo8Zm9udCBjb2xvcj0iIzAwQjAwMCI+IGluIHRoaXMgZXhhbXBsZSwg d2UgZG9uJ3QgZG8gbXVjaCB0aGluZ3Mgd2l0aCB0aGUgU1JzLAogICAgIGEgbG90IG9mIHRo aW5ncyBhcmUgbWlzc2luZyA6IHN1cGVydmlzb3IgYml0cywgcmFuZ2UgY2hlY2tpbmcsIGV0 Yy4KICAgICB3ZSBvbmx5IHJlYWQgYWxsIHRoZSBTUiBhbmQgd3JpdGUgdG8gdGhlIGN5Y2xl IGNvdW50ZXIKICAgICBCVVQgaXQgaXMgYW4gYXN5bmNocm9ub3VzIHVuaXQgOiB0aGUgZGVj b2RlciB3YWl0cyBmb3IgYSBSRUFEWSBzaWduYWwuIDwvZm9udD4qLwoKLyo8Zm9udCBjb2xv cj0iI0IwMDAwMCI+V2FybmluZyA6IG5vdCB5ZXQgbG9naWNhbGx5IGNvbm5lY3RlZCB0byB0 aGUgWGJhcjwvZm9udD4qLwoKLyogaW50ZXJmYWNlIHdpdGggdGhlIGNvbnRyb2wgc2lnbmFs cyBhbmQgdGhlIFhiYXIgKi8KdW5zaWduZWQgY2hhcgogU1JfYWRkcmVzc1tXT1JEX1NJWkVd LCAgICAvKiB0aGlzIGNvbWVzIGZyb20gdGhlIFhiYXIgZnJvbSB0aGUgcmVnaXN0ZXIgcmVh ZCBwb3J0ICMyIG9yIGZyb20gdGhlIGltbWVkaWF0ZSBmaWVsZCBvZiB0aGUgaW5zdHJ1Y3Rp b24gKi8KIFNSX3dyaXRlX3BvcnRbV09SRF9TSVpFXSwgLyogY29ubmVjdGVkIHRvIHRoZSBY YmFyLCByZWFkL3dyaXRlIHBvcnQgIzEsICovCiBTUl9yZWFkX3BvcnRbV09SRF9TSVpFXTsg IC8qIHRoZSB3cml0ZSBwb3J0IGlzIHJvdXRlZCBieSB0aGUgWGJhciB0byBSNydzIHdyaXRl IHBvcnQgIzEgb3IgIzIgYWNjb3JkaW5nIHRvIHRoZSBzY2hlZHVsZXIuICovCgp1bnNpZ25l ZCBpbnQKIFNSX3NpZ25hbCwgLyogPT0xIGlmIHRoZSBkZWNvZGVyIGRlY29kZXMgYSBHRVQg b3IgUFVUIGluc3RydWN0aW9uICovCiBTUl9yZWFkLCAgIC8qID09MSBpZiBHRVQsID09MCBp ZiBQVVQgKGFjdGl2ZSBpZiBTUl9zaWduYWwgaXMgdmFsaWQpICovCiBTUl9wZW5kaW5nLC8q ID09MSB3aGVuIHRoZSBTUlUgaXMgInRoaW5raW5nIi4gKi8KIFNSX3RyYXA7ICAgLyogIT0w IDogc29tZXRoaW5nJ3Mgd3JvbmcgISByb3V0ZWQgdG8gdGhlIGRlY29kZXIsIGZldGNoIHRo ZSBTUiB0cmFwIGhhbmRsZXIuICovCiAgIC8qICdkaWFnbm9zdGljJyBpcyBjdXJyZW50bHkg bWVyZ2VkIHdpdGggdGhpcyBzaWduYWwsIGJ1dCBub3QgaW4gdGhlIGNpcmN1aXQuICovCgov KiBhdCByZXNldCB0aW1lLiAqLwp2b2lkIGluaXRfU1IoKSB7CiAgbWVtc2V0IChTUl9idWZm ZXIsc2l6ZW9mKFNSX2J1ZmZlciksMCk7CiAgc2V0KFNSX2J1ZmZlcltTUl9OVU1CRVJTXSxT Ul9OVU1CRVJTX3ZhbCw4KTsKICBzZXQoU1JfYnVmZmVyW1NSX0ZBTUlMWV0sU1JfRkFNSUxZ X3ZhbCw4KTsKICBzZXQoU1JfYnVmZmVyW1NSX1NURVBQSU5HXSxTUl9TVEVQUElOR192YWws OCk7CiAgc2V0KFNSX2J1ZmZlcltTUl9NQVhfU0laRV0sV09SRF9TSVpFLDgpOwogIHNldChT Ul9idWZmZXJbU1JfU0laRV8xXSxTUl9TSVpFXzFfdmFsLDgpOwogIHNldChTUl9idWZmZXJb U1JfU0laRV8yXSxTUl9TSVpFXzJfdmFsLDgpOwogIHNldChTUl9idWZmZXJbU1JfU0laRV8z XSxTUl9TSVpFXzNfdmFsLDgpOwogIHNldChTUl9idWZmZXJbU1JfU0laRV80XSxTUl9TSVpF XzRfdmFsLDgpOwoKICAvKgogICAgIFNSX0NZQ0xFPTAgOiBjb2xkIGJvb3QsIGNvdW50ZXIg Y2xlYXJlZAogICAgIFNSX1BBR0lORz0wIDogcGFnaW5nIGlzIG5vdCBlbmFibGVkCiAgKi8K fQoKCi8qIGNhbGxlZCBldmVyeSBjeWNsZSA6ICovCnZvaWQgY3ljbGVfU1IoKSB7ICAgICAg ICAgIC8qIDxmb250IGNvbG9yPSIjQjAwMDAwIj53YXJuaW5nIDogdGhpcyBwYXJ0IGhhcyBu b3QgYmVlbiB0ZXN0ZWQgb3IgY29tcGlsZWQgeWV0ICEgVGhpcyBpcyBub3QgZXZlbiBjeWNs ZSBhY2N1cmF0ZSAhPC9mb250PiAqLwogIHVuc2lnbmVkIGludCBpPTA7CgogIC8qIGluY3Jl bWVudCB0aGUgY3ljbGUgY291bnRlciAqLwogIGRvIHsKICAgIFNSX2J1ZmZlcltTUl9DWUNM RV1baV0rKwogIH0gd2hpbGUgKChTUl9idWZmZXJbU1JfQ1lDTEVdW2krK10hPTApICYmIChp IDwgV09SRF9TSVpFKSk7CgogIGlmICghU1JfcGVuZGluZykgewogICAvKiBpZiBub3RoaW5n IGlzIHBlbmRpbmcsIHdlIGNhbiBjaGVjayBpZiB0aGUgZGVjb2RlciBoYXMgYSBHRVQvUFVU IGluc3RydWN0aW9uICovCiAgICBpZiAoU1Jfc2lnbmFsKSB7CiAgICAgIFNSX3BlbmRpbmc9 MTsKCiAgICAgIC8qIGZpcnN0IGNoZWNrIHRoZSBhZGRyZXNzICovCiAgICAgIC8qIGFzc3Vt ZSBTUl9OVU1CRVJTPDI1NiAhICovCiAgICAgIGlmIChTUl9hZGRyZXNzWzBdPj1TUl9OVU1C RVJTX3ZhbCkKICAgICAgICBTUl90cmFwPTE7CiAgICAgIGVsc2UgewogICAgICBmb3IgKGk9 MTsgaSA8IFdPUkRfU0laRTtpKyspCiAgICAgICAgaWYgKFNSX2FkZHJlc3NbaV0hPTApCiAg ICAgICAgICBTUl90cmFwPTE7CiAgICAgIH0KICAgICAgCiAgICAgIGlmIChTUl90cmFwPT0w KSB7IC8qIGlmIHN0aWxsIG9rICovCgogICAgICAgICAgLyogdGVzdCByZWFkIG9yIHdyaXRl IDogY2hlY2sgdGhlIHJlYWQgbWFzayBvciB3cml0ZSBtYXNrICovCiAgICAgICAgaWYgKFNS X3JlYWQpIHsKICAgICAgICAgIGlmICghKCgxIDw8IFNSX2FkZHJlc3NbMF0pJlNSX1JFQURf TUFTSykpCiAgICAgICAgICAgIFNSX3RyYXA9MjsKICAgICAgICAgIGVsc2UgewovKiBhY3Rp b24gISAqLwogICAgICAgICAgICAvKiBoZXJlLCB0aGUgb25seSB0aGluZyB3ZSBjYW4gZG8g aXMgcmVhZCB0aGUgcmVnaXN0ZXJzLiBubyBjb21wbGV4IGJhaGF2aW91ci4gKi8KICAgICAg ICAgICAgbWVtY3B5KFNSX3JlYWRfcG9ydCxTUl9idWZmZXJbU1JfYWRkcmVzc1swXV0sV09S RF9TSVpFKTsKLypoZXJlLCB3ZSBzaG91bGQgZG8gc29tZXRoaW5nIGZvciBTUl9wZW5kaW5n Li4uICovCgovKiBsYXRlciwgdGhpcyBwYXJ0IHdpbGwgYmUgcmF0aGVyIC4uLiBjb21wbGV4 LiBLZWVwIGl0IGNsZWFuICEgKi8KCiAgICAgICAgICB9CiAgICAgICAgfSAKICAgICAgICAg IC8qIHdyaXRlIG1hc2sgKi8KICAgICAgICBlbHNlIHsKICAgICAgICAgIGlmICghKCgxIDw8 IFNSX2FkZHJlc3NbMF0pJlNSX1dSSVRFX01BU0spKQogICAgICAgICAgICBTUl90cmFwPTM7 CiAgICAgICAgICBlbHNlCiAgICAgICAgICAgIG1lbWNweShTUl9idWZmZXJbU1JfYWRkcmVz c1swXV0sU1Jfd3JpdGVfcG9ydCxXT1JEX1NJWkUpOwovKmhlcmUsIHdlIHNob3VsZCBkbyBz b21ldGhpbmcgZm9yIFNSX3BlbmRpbmcuLi4gKi8KCi8qIGlkZW0gaGVyZSBmb3IgbGF0ZXIu Li4gKi8KCiAgICAgICAgfQogICAgICB9CiAgICB9CiAgfQp9CgoKCmludCBtYWluKCl7CiAg cmV0dXJuIDA7Cn0K --------------AC00874EBF094113DC2988E0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00379 for ; Sat, 22 Jul 2000 19:06:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 22 Jul 2000 19:06:14 +0200 (MEST) Received: (qmail 7718 invoked by uid 0); 22 Jul 2000 00:20:30 -0000 Received: from c9.egroups.com (208.50.99.230) by mx02.gmx.net with SMTP; 22 Jul 2000 00:20:30 -0000 X-eGroups-Return: sentto-1101623-514-964225225-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 22 Jul 2000 00:20:28 -0000 Received: (qmail 23661 invoked from network); 22 Jul 2000 00:20:24 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 22 Jul 2000 00:20:24 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 22 Jul 2000 00:20:24 -0000 Received: from f-cpu.org (nas1-229.aub.club-internet.fr [195.36.150.229]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA21728 for ; Sat, 22 Jul 2000 02:20:20 +0200 (MET DST) Message-ID: <3978E893.4F24EA12@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 22 Jul 2000 02:19:31 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] clocks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d241420c6b6964c5791b75413a65b54d Status: R X-Status: N hello,

i cleaned my inbocks from all the messages i didn't sort,
and all those comp.arch posts i didn't read after d/l.

i gound this post : (the whole thread is interesting too,
but this ones lit a lamp over my head)


Andy Glew wrote:
-------- Original Message --------
Path:
club-internet!grolier!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!enews.sgi.com!uwvax!news
From: "Andy Glew" <glew@cs.wisc.edu>
Newsgroups: comp.arch
Subject: Re: Asynchronous Designs (Was: Re: CMOS&Power Issues at 1GHZ)
Date: Fri, 10 Dec 1999 13:44:17 -0600
Organization: U. Wisc. & Intel (not official)
Lines: 108
Message-ID: <82rkoq$d5q@spool.cs.wisc.edu>
References: <82cauk$knj$1@autumn.news.rcn.net> <rz74sdx6z7l.fsf@corton.inria.fr> <384AC04C.AA6FC83F@bellatlantic.net>
<y4yab88lx2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de> <82hnlc$nol@crl3.crl.com> <82prsd$fc9@spool.cs.wisc.edu>
<y4emcvdwhl.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>
NNTP-Posting-Host: egeus.cs.wisc.edu
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Xref: club-internet comp.arch:38614
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> > Anyway...   while I love to think about the potential for asynch,
> > the circuits guys tend to go crazy when I raise them.
>
> In the age of chips with 10^9 transistors running at 10+ GHz, will they
> have a choice?

Yes.

Totally asynchronous circuits look like they will always suffer a
performance disadvantage relative to synchronous circuits,
for small circuits. Asynchronous circuits suffer the costs of
having the model that generates the handshake, in either time
or area.

However, nobody that I know of is planning to run gigatransistor
chips totally synchronous.  The approaches, from most to least
likely to happen soon, include:

a) mesosynchronous clocking

        Multiple clock generators scattered around the chip
        synchronized to each other.
            Basically, this will mean that skew will depend on
        how far a signal is being sent: send a signal a short
        distance, and you have low skew, send it a long distance
        and you have high skew.

b) pipeline ordered clocking

        Dstribute the clock forward along with the pipeline.
        Not backwards in the global skew minimizing approach;
        Forward pipeline clocking maximizes performance,
        and reportedly has been done in some very high performance
        designs.
            Somewhat similar to source synchronous clocking;
        indeed, source synchronized clocking can be used
        for bidirectional (actually, multipoint) busses.
            Unlike strict physical distance, logical distance is
        what matters in the pipeline ordered world.  Send a
        signal to the next pipestage, lowest skew; the previous
        pipestage, a bit more skew; more than one pipestage
        away, still more skew.

        I believe that I have discussed pipeline ordered clocking
        in comp.arch in the past few years.

c) GALS - Globally Asynchronous, Locally Synchronous

        Although mesosynchronous and pipeline ordered clocking
        can be considered asynchronous techniques on some level,
        I prefer to reserve the term "GALS" for designs that use
        classic asynchronous handshaking between locally
        synchronous clock domains.  The problem, of course,
        is that classic asynchronous handshaking, even via
        Sutherland's micropipelines, has overhead: a pipeline
        implemented as several different GALS pipestages will
        have more overhead than a pipeline implemented in
        mesosynchronous or pipeline-ordered clocking,
        where clock domain buffering between pipestages is
        not necessary.

Now, I am rather attached to the concept of pipeline ordered
clocking; I may not be the first inventor of it, but I independently
came up with the scheme in 1996.  (By the way, although I have
talked to circuits people who say that pipeline ordered clocking
has been used, I have never seen publications. Any references
that can be sent me would be appreciated.)

However, I must agree with the circuits people that
mesosynchronous clock domains are likely to happen sooner,
and may have enough advantages to beat pipeline ordered clocking
at all times. Mesosynchronous clocking needs very few changes
to design tools - perhaps just a design rule checking for physically
long wires - whereas pipeline ordered clocking needs DRCs
based on logical proximity. As in many such things, we architects
are ready to live in this Brave New World; the process people are
anxious to stop having to worry about global clock skew; but the
people in the middle who actually design the gates have to get
tools to arrive.

As for GALS - my excursion into pipeline ordered clocking was inspired
by reflections on the overhead of a pipeline network laid across GALS
clock domain boundaries.  In pipelines, we have something approximating
nearest neighbour communication, and we worry about adding extra layers
of overhead because pipeline latency does matter.
    However, GALS is certainly viable between units that don't have the
nearest neighbour property, and which don't worry about an extra few time
units crossing such boundaries.  Low bandwidth intercommunication
across the GALS domain boundaries, or, possibly, high bandwidth but
no latency concerns.
    Possibly, independent pipelines could use GALs. Or, chip level
multiprocessing (although mesosynchronous is so easy here...)
    And circuit people in industry still fear validation and testing of asynchronous
logic.  I've interviewed Caltech graduates who say that testing asynch is a solved
problem, but that message has not propagated far in industry, if it is true.
It may be generational.

Probably the future holds a melange:
    ++ mesosynchronous clocking, using classic design and test tools,
with trivially augmented physical DRCs.
    ++ possibly the mesosynchronous clock domains will be "shaped"
in a pipeline ordered manner
    ++ GALS handshakes for far distant, independent, infrequently
communicating units.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i sent it back to Andy :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

hello,

i'm cleaning my archives ... and found this post to comp.arch.
did you finally get answers about pipeline ordered clocking ?
This looks like an interesting approach. I don't know if the
FC0 as it exists today can benefit from this but it could be adapted.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i just got his answer :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No answers. You may see it implemented some day, but it's
not here yet.

I would *NOT* recommend it for FC0.
In fact, I would recommend that you do FC0
at as high a level as possible, in RTL.
Be aware of the lower level tradeoffs,
but don't wire them into your assumptions.

My perception of the way architecture and circuit
technologies overlap is that it is best to decouple
them: have an RTL design that can work in globally
clocked CMOS, now. Maybe lay it out.  When and if
a new circuit tecnology comes along, the RTL should
only need slight tweaks - maybe a few latches, e.g.
to go to mesosynchronous clocking or globally ordered
clocking.  Redo the layout, automatically if you
have the right tools.

But keep the high level design as reusable, and as independent
of low level circuits, as possible.

Make it circuit aware --- do your best to eliminate all of the
paths that would make it hard to do pipeline ordered --- but
not circuits dependent.


====


Of course, depends on what you are trying to do with FC0.
I thought you were trying to make an Open Source core,
i.e. a chip design that might really get built.
If you are just doing a fun design, do whatever.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

here's my answer :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

thank you for your answer. Of course, this is a purely imaginary thought,
and it doesn't impact the F-CPU ISA at any point. i have done my best to decouple
everything as much as possible in the F-CPU project
(ISA/u-architecture/technology/asm langage/etc).
the first protos will be as dumb as possible,
only to make sure that the higher level concepts are valid in practice, and
because it's more important to make a chip work first, before we hit the GHz ;-)

Anyway, i thought that the idea of the "pipeline ordered clocking"
might solve some problems on a case-by-case basis. The FC0 implements
an "out of order completion" (it emits in order but the scoreboard allows
us to perfom several long operations at the same time) pipeline that is meant
to work at high frequency (very tight pipe stages). the clock tree, after
the protos work, will be a major trouble (among others). The design is completely
synchronous but i read your description this way :

there is no central clock (like in the 21064, with its huge central transistor)
with big jitter/skew constraints (like <0.1ns in the whole die) but an "entry point" with the clock tree
following the pipeline tree. we might consider that, for the FC0, the entry point is
located at the instruction decoder : that's where everything is scheduled and where
we "plug" the Xtal pin. then the signal is propagated from neighbour to neighbour,
amplified with a low factor and low jitter to the following neighbours :
the register set, the Xbar, the prefetcher, and finally (after some steps) to
the Execution Units (add/sub, mult, dic etc). This can allow us to break from
an arbitrary clock tree and classical (?) hierarchical design, with a purely
geometric analysis. this is purely synchronous, but not a flat spread tree :
we can have more jitter with no impact on the pipeline scheduling if the jitter
"follows" the pipeline.

One interesting thing is that the clock signal can change its state at different
times at a different places, impacting on the power consumption, but this might be
pure speculation, like the rest.

Once my master thesis will be finished (*) (as it ought to be for... one year ?)
i'll restart the "technical" work on the FC0 similator, written in pure C.
this is purely independent from any clock tree technics, but it's purely
synchronous. it's so simple this way.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

for those who don't know, Andy Glew is one of the most skilled posters
of comp.arch, working in a University in Wisconsin and at Intel.
due to his contracts, he can't work with us (on an open design) and refused to
join us, but he doesn't seem to dislike it anyway :-)

everybody is encouraged to do the same with his professors, friends, whoever is interested
or might contribute to the project. the more, the merrier ;-)

As for "pipeline ordered clocking", this was just an idea to tweak more picoseconds
out of a particular design. this is not something "F-CPU", just a design trick that could
be tried, among with other techniques.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00382 for ; Sat, 22 Jul 2000 19:06:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 22 Jul 2000 19:06:17 +0200 (MEST) Received: (qmail 32266 invoked by uid 0); 22 Jul 2000 01:24:09 -0000 Received: from mk.egroups.com (207.138.41.165) by mx06.rz2.gmx.net with SMTP; 22 Jul 2000 01:24:09 -0000 X-eGroups-Return: sentto-1101623-515-964229044-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 22 Jul 2000 01:24:08 -0000 Received: (qmail 20208 invoked from network); 22 Jul 2000 01:24:04 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 22 Jul 2000 01:24:04 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 22 Jul 2000 01:24:03 -0000 Received: from welfen-netz.com [213.6.80.212] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Sat, 22 Jul 2000 03:24:00 +0200 Sender: kai@pop.gmx.net Message-ID: <39795BE3.59679A9E@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200007170113.e6H1DiS02601@tbird.iworld.com> <3972A545.B628176A@nventure.com> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 22 Jul 2000 10:31:31 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT and bandwidth Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0868fdff5b4edebb358c47360b1c21c1 Status: R X-Status: N Albert Abramson wrote:
>
> > >Rares Marian wrote:
> > >
> > >> Albert Abramson wrote:
[...]
> I dunno if you were around when we talked about the three types of MT.=
> 1. one thread per processor, multiple processors
> 2. multiple threads per processor, filling each others' pipeline stall= s
> 3. multiple threads per processor, filling each others' general stalls=

... and (4) concurrent/interleaved multi-threading:
The basic point is that a functional unit which uses 2 cycles
to complete (e.g. an adder) will be entered by one data pair
(instruction) each cycle resulting in a throughput of 1 per
cycle.  Said adder could handle a much higer throughput, at least
by a factor of two or four.  Feeding it with more data to compute
for a single thread can lead to two things: Smaller pipeline
stages resulting in more pipeline overhead compared to the
cycle time and a instruction level paralellism which is way too hard
to handle (just think of the register set which must be encoded !).
Now the idea is to use multiple threads running concurrently or
actually with a small offset which can move data to the FUs right after
the last threads's data are "through the door".  2 or 4 thre= ads
could easily be achieved, more depends on the cycle length and
our ability to predict and control local skew as well as some other
control issues.
Further features of this approach:
- each thread has its full register set (usually 64 registers)
- the decode stage is likely to be non-shared as well.

IIRC AlphaRISC estimated that 8-way MT should be the limit of what's
useful for the TTA and I think 4-way is more likely to be in our reach.

It's important to note that the first sillicon of any FC* won't likely
to be MT in this way, but FUs should be designed for it from the start.

> I've been talking VLIW, so that means no dynamic scheduling, ruling ou= t no.2.
> No. 1 is doable, and I've favored that to one large processor, but no.= 3 is
> the solution I've been offering for making use of the processor during= wait
> time.  This puts downward pressure on the time allowable for a co= ntext switch,
> but that's no biggy.
>
> I've tended to favor narrow,

Hmm, I think that the average time needed to issue an instruction
is larger with the 3-issue you proposed then with wider issue,
so I'm tending to favour 4-issue to 8-issue I think :=B0)
I agree that total decoding time has to be taken into account as
it may at one point limit machine frequency.

[...]
> > We need numbers to see how it works.  What you say we code s= omething
> >
> I also offered a generic programming example with a dynamic function c= all
> followed by two static function calls, with no certainty of the outcom= e of the
> DLL from the compiler's vantage point.
>
> OH NO, I'M A NERD!!!!!!!!
>
> Oh, well.
>
> Anywhose, any code fragment to prove the usefulness of this would have= to be
> big.  However, assume the following code fragments load-stores ar= e all
> probable misses.
>
> load r1, A2, imm
> complt r2, r3, r4
> .
> load r5, A2, imm
> cmovlt r5,
>
> well anyway, I'm tired of coding.  The point is, the stuff on the= other side
> of that stall can be spawned before that load, those operations that a= re
> likely to be needed after the stall (after a few conditions have been = tested)
> can be left as background work to be handled during stalls. (The previ= ous
> example shows off some of the limiting effect of a small register file= , and
> also the ability to hand off some of that work to another rf.)
>
> Proving the workability of this depends of very large code fragments.&= nbsp; Still,
> here it is in a generic sense.
>
> MSSomeCrappyMSCode(someval);
>
> MyFunc(somenum);
> SomeoneElsesFunc(nuthernum);
>
> MSAnotherCrappyFunc(anotherval);

Well, if these functions are not called often they're fine, since
they are saving the virtual memory from beeing used.  If they are
used frequently, or even on a data vector inside a loop, the crap
is not our fault and it's not us who have to fix it.

(But language designers and system software people are free to
offer a notion of static functions which are merged (inlined) with the
main application's code at link time, no problem with that.)

> Oddviously, we have no idea what the dynamic functions are going to do= or if
> it will EVER give MyFunc control of the cpu again.  Since the com= piler can't
> even insert prefetches for DLL's, it can set MyFunc() and SomeoneElses= Func()
> in the ready queue by moving their start addresses into the appropriat= e
> registers (maybe the global address registers, eh?) and icbt'ing them = for the
> ICACHE.  Since MSAnotherCrappyFunc()'s sources are indeterminant,= we can't
> just spawn it as a thread.  If operands need to be passed among t= hese threads
> the global registers act as an efficient way of doing just that. = Condition
> fields associated with each data register offer a sticky Update bit to= let the
> accepting thread know whether or not the value has been returned yet.<= BR>
I'm very skeptical, but maybe it's paranoia ;=B0)

> Well, that's probably more information than you wanted.  However,= if more info
> is desired, go to Cray's Web site and look at details of the Cray MTA.=   Each
> processor is able to represent 128 threads (virtual processors), far m= ore than
> the 7 I've proposed.  With fast, efficient message passing, it ge= ts relatively
> easy to break large programs up into many horizontal threads; hence th= e flat
> register space, one-cycle context switch, and zero-overhead message pa= ssing.
> Threads smaller than 20 instructions can be spawned to fill upcoming g= eneral
> stalls.  This creates many opportunities for the compiler to find= parallelism
> where it would be difficult or impossible to integrate into a static > instruction stream.
>
> --Maxx

kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00385 for ; Sat, 22 Jul 2000 19:06:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 22 Jul 2000 19:06:18 +0200 (MEST) Received: (qmail 8142 invoked by uid 0); 22 Jul 2000 01:26:11 -0000 Received: from ej.egroups.com (208.50.144.75) by mx02.gmx.net with SMTP; 22 Jul 2000 01:26:11 -0000 X-eGroups-Return: sentto-1101623-516-964229169-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 22 Jul 2000 01:26:11 -0000 Received: (qmail 17660 invoked from network); 22 Jul 2000 01:26:09 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 22 Jul 2000 01:26:09 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 22 Jul 2000 01:26:08 -0000 Received: from welfen-netz.com [213.6.80.212] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Sat, 22 Jul 2000 03:24:05 +0200 Sender: kai@pop.gmx.net Message-ID: <39796A36.3A91D779@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8kvv9r+54qn@eGroups.com> <397405A8.7C7FB636@welfen-netz.com> <397740A5.367470B0@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 22 Jul 2000 11:32:38 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] C++ F-CPU Simulator (was: Re: SMT and bandwidth) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6b707a5e42ab20bb19cc0e9dc8fc6071 Status: R X-Status: N Yann Guidon wrote:

[snip]

> i believe that some of you have already written a more or less accurat= e
> or working CPU simulator. like :
>
> main () {
>   for () {
>     inst=3Dfetch();
>     IP+IP+4;
>     switch(inst[0]) { /* opcode byte */
>        case load : load(); break; >        case store : store(); break;=
>        case nop : nop(); break;
>        ...
>        default: error("wrong o= pcode");
>     }
>   }
>
> etc...
>
> Now the goal is to go one step further : expose every pipeline stage a= nd unit.
> they are described in the manual...
>
> i have included some files, dated 4/4/2000 which start to secribe it.<= BR> > it is not meant to be compiled (yet) because the decoder/registerset/X= bar
> parts are not correct yet, and i've redesigned the LSU.
>
> As you may know, it is not possible to know excatly the propagation ti= me
> of one unit in advance : as we get further down the micrometer, and fa= ster
> in GHz, the 3D RC-extraction ect are very difficult to make and it wou= ld not
> be feasible to do a transistor-based time estimation : the geometry is=
> very important and it can only be done at the geometry level, and that= 's too
> early now.

Well, I didn't propose to do anything at the transistor level for now.
Working at the logical gate level makes sense to me.  Assuming that an AND gate is going to take more time then a NAND gate isn't too
bad for a CMOS process I suppose.  Having an event-driven simulator with some decent assumptions is not a big step from having one with
a universal gate delay of "1.0".

Designing a tightly multi-threaded FU in any CMOS process will
also make it easier to do a second one in the process we'll actually
use IMO, so it's not totally useless to start some work at the layout
level even before everything else is done.

> The goal today is to prove that the pipeline is "foolproof",= stable,
> has no side effect etc... there are design rules, however, that are ap= plied at
> the schematic level (using a pen, a paper, and a brain), and they're u= sed
> to design the units which are coded in C.

Hmm, entering the schematics in the computer and then use it
in the simulator directly sounds better to me, not only for
avoiding "pen and paper" but for avoiding coding them in C" = :=B0)
(I like P&P, but drawing a complete 64bit multiplier is annoying at bes= t...)

Anyway, did you write all the simple units already or are there some
left (integer, shuffle, rop2/combine, popcount, or "find first") = ?
If not I could help out with that (at the "function" level), but<= BR> not the control stuff (lsu, xbar, cache control, ...) or FP units.

> Going to the transistor now would
> be suicidal because there's too much variety in the processes today an= d the
> design would be so specialized that nobody could fab it.
>
> The design goals are rather weak when it comes to the latencies : this= is
> due to the strong instruction ordering at the decode phase.

Well, that's a specific feature of FC0.  Even here we may come to
a point where we have to decide whether an FU has to be a little
faster or whether it can be a little slower, saving some space.

> if one unit
> appears to be too slow, it can be easily split and if there's a remain= ing
> fraction left, it can be merged with the following stage of the pipeli= ne.
> fixed size :
>  ROP2/combine : 1 cycle

I think you mentioned it before: how long was a cycle, again ?

>  ASU : 1 cycle (8-bits) or 2 cycles (16-64 bits)
>  INC/FindFirst : 1 cycle
>  POPCOUNT : unconstrained (mmm could be merged with the findfirst= unit...)

Maybe 2 cycles ?  What is "unconstrained" in this context ?<= BR>
>  L/SU : unconstrained
>  IMU : unconstrained but pipelined and less stages when the SIMD = chunks are smaller
>  IDU : idem but pipelined is not necessary (slow and not used muc= h,
>    could be hardwired in a small machine...)
>
> That is valid for the FC0. The F-CPU in general does not specify instr= uction
> latencies, because they are expected to vary greatly in the future. Th= e numbers
> given above are not "firm" and can vary, depending on the im= plementation constraints.
> The architecture simulator is meant to copy the behaviour of the pipel= ine stages
> and should be modified accordingly.

Ok.

> OK OK i still have to scan and comment the schematics. sorry, i have t= o finish my master
> thesis before... :-(
[...]
I don't want to push you.  I just can't await it =3DO)

Best regards,
kai
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00397 for ; Sat, 22 Jul 2000 19:06:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 22 Jul 2000 19:06:22 +0200 (MEST) Received: (qmail 28520 invoked by uid 0); 22 Jul 2000 05:29:15 -0000 Received: from hp.egroups.com (208.50.99.201) by mx11.rz2.gmx.net with SMTP; 22 Jul 2000 05:29:15 -0000 X-eGroups-Return: sentto-1101623-517-964243751-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 22 Jul 2000 05:29:14 -0000 Received: (qmail 11138 invoked from network); 22 Jul 2000 05:29:11 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 22 Jul 2000 05:29:11 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 22 Jul 2000 05:29:11 -0000 Received: from f-cpu.org (nas1-196.aub.club-internet.fr [195.36.150.196]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA15783 for ; Sat, 22 Jul 2000 07:29:07 +0200 (MET DST) Message-ID: <397930FD.B7EC6D78@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8kvv9r+54qn@eGroups.com> <397405A8.7C7FB636@welfen-netz.com> <397740A5.367470B0@f-cpu.org> <39796A36.3A91D779@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 22 Jul 2000 07:28:29 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] C sim Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9937f4e14fbba8351abfc851fae02c8a Status: R X-Status: N hi ev'ybody !

Kai Wetzel wrote:
> Yann Guidon wrote:
> [snip]
> > As you may know, it is not possible to know excatly the propagati= on time
> > of one unit in advance : as we get further down the micrometer, a= nd faster
> > in GHz, the 3D RC-extraction ect are very difficult to make and i= t would not
> > be feasible to do a transistor-based time estimation : the geomet= ry is
> > very important and it can only be done at the geometry level, and= that's too
> > early now.
>
> Well, I didn't propose to do anything at the transistor level for now.=
> Working at the logical gate level makes sense to me.  Assuming th= at
> an AND gate is going to take more time then a NAND gate isn't too
> bad for a CMOS process I suppose.  Having an event-driven simulat= or
> with some decent assumptions is not a big step from having one with > a universal gate delay of "1.0".
even that is not acurate, we need an estimation of the wire length or
geometry and this must be done with P&P first... at my level anyway. i have no will to rewrite a logic simulator. C is enough pain for me ;-)
> Designing a tightly multi-threaded FU in any CMOS process will
> also make it easier to do a second one in the process we'll actually > use IMO, so it's not totally useless to start some work at the layout<= BR> > level even before everything else is done.

i guess that layout must be done on a case-per-case basis, and we're not ready yet : we have no target technology for example. and technology is
quickly deprecated. don't try to push too many technologies at a time :-)
of course our work will be reused, so we need to make as general as possibl= e.
re-read Andy Glew's answer in my last post :-)

I guess that we can make some limited studies of the layout for each execut= ion
unit : transistor count, throughput, scalability, influence of the number o= f
layers, etc. this can reuse the work done by Alliance. This is important to select the best strategy, for example for the ASU (what architecture wil= l we
choose ? "PG" tree seems best in theory but in practice ???). OTO= H if the control
can benefit from this experience, it should remain as flexible as possible.=


> > The goal today is to prove that the pipeline is "foolproof&q= uot;, stable,
> > has no side effect etc... there are design rules, however, that a= re applied at
> > the schematic level (using a pen, a paper, and a brain), and they= 're used
> > to design the units which are coded in C.
>
> Hmm, entering the schematics in the computer and then use it
> in the simulator directly sounds better to me, not only for
> avoiding "pen and paper" but for avoiding coding them in C&q= uot; :=B0)
> (I like P&P, but drawing a complete 64bit multiplier is annoying a= t best...)

well i don't know schematics entry tools that generate C code.
i can do a better code with my brain in any case ;-)
in fact the problem is to decouple the principle from the implementation :<= BR> there are many ways to code a loop or a vector, for example, and
"the best implementation" is judged with many factors that a dumb= code
generator can't discriminate.

The purpose of the work is to implement the "heart" of the CPU wh= ich is
not made of monotonic or similarly common components : that's why the
work on the divider or the multiplier is less interesting than the control<= BR> and scheduling part. they can be studied rather independently.

> Anyway, did you write all the simple units already or are there some > left (integer, shuffle, rop2/combine, popcount, or "find first&qu= ot;) ?
> If not I could help out with that (at the "function" level),= but
> not the control stuff (lsu, xbar, cache control, ...) or FP units.

i think that i can handle the control stuff but i rely on the specialists to choose the best solution for the shifter, the multiplier, the divider and maybe some others. The incrementer is half-designed (some P&P in my= archives),
and could be merged with the popcount stuff to make a certain class of inst= ructions :
i can see that alone. the ROP2/combine is almost straight-forward, i was la= zy
to program it. The ASU is finished in C, not in layout (could be done now).=
I think i made a ROP2 unit before, i gotta look at my archives.
The discussion on the shuffler is not finished, we need to incorporate some=
instructions and see how it can be merged with the ROP2 unit.

> > The design goals are rather weak when it comes to the latencies := this is
> > due to the strong instruction ordering at the decode phase.
> Well, that's a specific feature of FC0.
no. any classical CPU enforces a strong ordering, and can have any latency<= BR> one wants behind the scene. That's why you can still run 8086 code on a Pen= tium :
the instruction at [x] will always be executed before the instruction at [x= +1] :-)
then the scheduling details are a case-by-case problem.

>  Even here we may come to
> a point where we have to decide whether an FU has to be a little
> faster or whether it can be a little slower, saving some space.
this choice should be left to the end implementor, according to its
own design goals and rules. we can propose things but sticking too strictly=
to something would discourage users....

> > if one unit
> > appears to be too slow, it can be easily split and if there's a r= emaining
> > fraction left, it can be merged with the following stage of the p= ipeline.
> > fixed size :
> >  ROP2/combine : 1 cycle
> I think you mentioned it before: how long was a cycle, again ?
ASAP :-) (As Short As Possible).
like 10 transistors, or equivalent to 6 simple logic gates, including the delay involved by the wires. this makes a simple 8-bit add/sub block.
the pipeline latches are not counted here for simplicity.

This remembers me that the ASU i proposed in C doesnt include saturation II= RC.
Can anyone include it ?

> >  ASU : 1 cycle (8-bits) or 2 cycles (16-64 bits)
> >  INC/FindFirst : 1 cycle
> >  POPCOUNT : unconstrained (mmm could be merged with the find= first unit...)
> Maybe 2 cycles ?  What is "unconstrained" in this conte= xt ?
it means that there's no specific goal, it's left to the implementor (reaso= nably).
for the POPCOUNT, the difficulty is that it embeds a 6-bit saturated substr= action
in the adder tree. usually, it's simply a tree of adders, but the POPCOUNT = instruction
has an optional parameter that is substracted to the result (see the manual= v0.2).
if the result is below than the sub value, the result is simply zeored, oth= erwise the result
is substracted. using a special HW for this is a good thing because we can = optimize the
function with some gates without needing extra cycles to go through the ASU= , and the
design challenge is interesting.

> > OK OK i still have to scan and comment the schematics. sorry, i h= ave to finish my master
> > thesis before... :-(
> [...]
> I don't want to push you.  I just can't await it =3DO)

don't worry : me too :-)
i've been waiting for so long ...

but my master thesis proved to myself that i can handle complex designs, if= i only
take all the necessary time to become accustomed to all the details and the= ir behaviour
when they're assembled. I guess that the best thing to do is to discuss abo= ut them
on the list.

> Best regards,
have fun,
> kai
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00406 for ; Sat, 22 Jul 2000 19:06:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 22 Jul 2000 19:06:24 +0200 (MEST) Received: (qmail 10054 invoked by uid 0); 22 Jul 2000 09:07:47 -0000 Received: from ch.egroups.com (208.50.99.226) by mx02.gmx.net with SMTP; 22 Jul 2000 09:07:47 -0000 X-eGroups-Return: sentto-1101623-518-964256854-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ch.egroups.com with NNFMP; 22 Jul 2000 09:07:35 -0000 Received: (qmail 16150 invoked from network); 22 Jul 2000 09:07:33 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 22 Jul 2000 09:07:33 -0000 Received: from unknown (HELO mail3.bellsouth.net) (205.152.111.6) by mta1 with SMTP; 22 Jul 2000 09:07:33 -0000 Received: from 1Cust65.tnt6.knoxville.tn.da.uu.net_[63.10.103.65] (1Cust65.tnt6.knoxville.tn.da.uu.net [63.10.103.65]) by mail3.bellsouth.net (3.3.5alt/0.75.2) with SMTP id TAA16760; Fri, 21 Jul 2000 19:38:55 -0400 (EDT) Received: from by 1Cust65.tnt6.knoxville.tn.da.uu.net with ESMTP; Fri, 21 Jul 2000 19:37:18 -1200 Message-ID: <0000625909e2$000001ae$000052e0@> To: X-Priority: 3 X-MSMail-Priority: Normal From: ema34@earthlink.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 21 Jul 2000 19:37:11 -1200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Let Us Help You Make Money Now! 21216 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c7f8aec530f17ba8243b5c3b64ca6071 Status: R X-Status: N

FOLLOW ME TO FINANCIAL FREEDOM!!



I Am looking for people with good work ethic and extrordinary desire

to earn at least $10,000 per month working from home!



NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the

training and personal support you will need to ensure your success!



This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in

control of your time,your finances,and your life!



If you've tried other opportunities in the past that have failed to

live up their promises,



THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!



THIS IS NOT A GET RICH QUICK SCHEME!



YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!



CALL ONLY IF YOU ARE SERIOUS!



1-800-345-9708



DONT GO TO SLEEP WITHOUT LISTENING TO THIS!



"ALL our dreams can come true- if we have the courage to persue them"

-Walt Disney



Please Leave Your Name And Number And Best Time To Call



DO NOT RESPOND BY EMAIL



------------------------------------------------------------------------

This message is sent in compliance of the new email bill section

301.PerSection

301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal

requests.Just Put Remove

------------------------------------------------------------------------


From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02018 for ; Mon, 24 Jul 2000 23:32:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:18 +0200 (MEST) Received: (qmail 28556 invoked by uid 0); 22 Jul 2000 22:15:12 -0000 Received: from fh.egroups.com (208.50.144.71) by mx02.gmx.net with SMTP; 22 Jul 2000 22:15:12 -0000 X-eGroups-Return: sentto-1101623-519-964304108-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 22 Jul 2000 22:15:10 -0000 Received: (qmail 13642 invoked from network); 22 Jul 2000 22:15:07 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 22 Jul 2000 22:15:07 -0000 Received: from unknown (HELO stirling.tzl.de) (195.127.27.7) by mta1 with SMTP; 22 Jul 2000 22:15:07 -0000 Received: from i1-server1.imaging-one.de ([192.168.6.51]) by stirling.tzl.de (8.9.1a/8.9.1) with ESMTP id AAA28964; Sun, 23 Jul 2000 00:14:58 +0200 Received: from cS8HrhGVI (slip-32-102-49-115.tx.us.prserv.net [32.102.49.115]) by i1-server1.imaging-one.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3GCQ7SFD; Sun, 23 Jul 2000 00:13:29 +0200 Message-ID: <8u8Hn81ZytOc4aFXBo8> From: Y36h5125c@golfersnews.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 22 Jul 00 5:23:59 PM Reply-To: f-cpu@egroups.com Subject: [f-cpu] WAZZZUUUUPPPPPP? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: d813dc4916e996fe54360a10004f204c Status: R X-Status: N
Build a residual income from time you spend on the Internet placing FREE
advertisements like this. Successful Internet company wants you to help
them market their products and services online. Place FREE pre-written
ads and get paid commissions on any sales that you bring to the company.
A FREE Web Site, and complete training and instructions will be provided
to you.  To Register with the program and to begin receiving
instructions, simply
mailto:theclub@england.com?subject=RegisterMe
AND INSERT YOUR FIRST AND LAST NAME AS TEXT








to be removed from this list mailto:smsvc@china.com?subject=remove
Finding business information just got easier.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02021 for ; Mon, 24 Jul 2000 23:32:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:19 +0200 (MEST) Received: (qmail 12180 invoked by uid 0); 23 Jul 2000 00:13:31 -0000 Received: from c3.egroups.com (208.50.99.225) by mx02.gmx.net with SMTP; 23 Jul 2000 00:13:31 -0000 X-eGroups-Return: sentto-1101623-520-964311208-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 23 Jul 2000 00:13:30 -0000 Received: (qmail 27980 invoked from network); 23 Jul 2000 00:13:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 23 Jul 2000 00:13:27 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 23 Jul 2000 00:13:27 -0000 Received: from modem-62.altace.dialup.pol.co.uk ([62.136.76.190] helo=llandre.freeserve.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13G9OS-0003Fr-00 for f-cpu@egroups.org; Sun, 23 Jul 2000 01:13:21 +0100 Sender: root@pop.gmx.net Message-ID: <397A3B2D.8A732353@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 01:24:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] C++ sim of circuit components Content-Type: multipart/mixed; boundary="------------472A7EEE22D2127E23E6ED9B" X-UIDL: 575c9b5a52d0f791f0a156bee6ffc2c2 Status: R X-Status: N --------------472A7EEE22D2127E23E6ED9B Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit FAO Kai and anyone else interested in this:

Here is a simulation of some basic gates, I've only tested the AND so
far.. but it's the technique that is important. My objective is to make
a C++ structure which would be fairly trivial to convert to VHDL node
list.

     to compile:
           g++ f00.II.cpp -o sim
     to run:
           sim

    binary version attached is Linux 2.0.30/X86

This is so that many people can run simulations, and change their
designs etc without having to
necessarily have a suitable EDA tool like Alliance running.

OK this is a million miles from Superscalar pipelined OOO processors,
but it's an 'ordinary joe' (provided
joe knows C++) type experience, although when the Class library is done
Electronics engineers will
recognise the node list.


What I'll be doing over the next couple of weeks:
--------------------------------------
I have designed the architecture of a small 32 bit RISC (f00.II) that I
will be creating and testing using this C++
method (again not to supplant FC0, but just as a sort of test). Long
time FCPUers might remember I got
very close to having a working 16 bit Risc using Xilinx Foundation, then
ran out of CLBs on the FPGA
I was trying to port it to. (Having created a very simple assembler and
simulator that assembled a hello world
and ran it).
I then moved to Alliance, but ran out of steam as simulation of a large
item through Alliance is not so easy.
This time, the MMU will be external, and Functional Units are bare
minimum, and C++ is the first step.
Although Supervisor/User mode is supported as well as interrupts and
traps and vitual machine (these all take insignificant resources on a
primitive risc).

This risc has only about 15 instuctions, but might be a base for others
to develop.. who knows.

Anyway, don't expect the risc for this week, probably next week.

Jeff Davies
jeff@llandre.freeserve.co.uk
--------------472A7EEE22D2127E23E6ED9B Content-Type: text/plain; charset=us-ascii; name="f00.II.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f00.II.cpp" #include #define NODE bool #define HI true #define LO false // ########## 2 input AND Gate ################### class and2 { public: NODE *in1, *in2, *out; and2::and2 (NODE *_in1, NODE *_in2, NODE *_out) { in1=_in1; in2=_in2; out=_out; }; void and2::delta () { *out=*in1 && *in2; }; }; //end class and2 // ########### 2 input NAND Gate ################# class nand2 { public: NODE *in1,*in2,*out; nand2::nand2 (NODE *_in1, NODE *_in2, NODE *_out) { in1=_in1; in2=_in2; out=_out; } void nand2::delta () { if(*in1 && *in2) { *out=LO; } else { *out=HI; }; }; }; //end class nand2 //###################### Tristate Buffer ################# class tribuf1 { public: NODE *in,*enable,*out; tribuf1::tribuf1 (NODE *_in, NODE *_enable, NODE *_out) { in=_in; enable=_enable; out=_out; }; void tribuf1::delta () { if(enable) *out=*in; }; }; //end class tribuf1 //################### D Type Flip Flop ####################### class dtype1 { public: NODE oldclock,*in,*clock,*out; dtype1::dtype1 (NODE *_in, NODE *_clock, NODE *_out) { in=_in; clock=_clock; out=_out; }; void dtype1::delta () { if (oldclock == LO && *clock == HI) { //positive edge so *out=*in; }; oldclock = *clock; }; }; //end of class dtype1 //--------------------------------------------------- //parts to complete: //dtype1_32 //tribuf1_32 //and2_32 //nand2_32 //invert1_32 //add2_32 perhaps join up many add2_4?? void main() { NODE a,b,c; and2 gate1(&a,&b,&c); a=HI; b=HI; gate1.delta(); if (c) { printf ("and (11) results in TRUE\n\r"); } else { printf ("and (11) results in FALSE\n\r"); }; a=HI; b=LO; gate1.delta(); if (c) { printf ("and (10) results in TRUE\n\r"); } else { printf ("and (10) results in FALSE\n\r"); }; a=LO; b=HI; gate1.delta(); if (c) { printf ("and (01) results in TRUE\n\r"); } else { printf ("and (01) results in FALSE\n\r"); }; a=LO; b=LO; gate1.delta(); if (c) { printf ("and (00) results in TRUE\n\r"); } else { printf ("and (00) results in FALSE\n\r"); }; //buses will be done thus //const buswidth=32; //NODE a[buswidth]; } //end main --------------472A7EEE22D2127E23E6ED9B Content-Type: application/octet-stream; name="sim" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sim" f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAA8IMECDQAAAAgCQAAAAAAADQAIAAFACgAFwAUAAYA AAA0AAAANIAECDSABAigAAAAoAAAAAUAAAAEAAAAAwAAANQAAADUgAQI1IAECBMAAAATAAAA BAAAAAEAAAABAAAAAAAAAACABAgAgAQINAcAADQHAAAFAAAAABAAAAEAAAA0BwAANJcECDSX BAjUAAAA2AAAAAYAAAAAEAAAAgAAAGgHAABolwQIaJcECKAAAACgAAAABgAAAAQAAAAvbGli L2xkLWxpbnV4LnNvLjEAABEAAAARAAAAAAAAAA4AAAACAAAAAAAAAA0AAAAAAAAACQAAAAAA AAAEAAAAAwAAAAgAAAALAAAAAAAAAAUAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAAAAAAAQAAAAwAAAAAAAAACgAAAAAA AAAAAAAAAAAAAAAAAAAOAAAAaJcECAAAAAARAPH/FwAAAEiXBAgAAAAAEQDx/y0AAACAgwQI AAAAABIABwAzAAAAUIYECAAAAAASAAoAOQAAAMiDBAigAAAAEgAAAD4AAAA0lwQIBAAAABEA DABIAAAAuIMECDgAAAASAAAAcwAAAJiDBAgoAAAAIgAAAHoAAAA0lwQIBAAAACAADACCAAAA qIMECEYAAAASAAAAjgAAANiDBAg+AAAAEgAAAJkAAAAImAQIAgAAABEAEQCnAAAASIYECAAA AAARAPH/rgAAAAiYBAgAAAAAEQDx/7UAAAAImAQIAAAAABEA8f/BAAAADJgECAAAAAARAPH/ AGxpYmcrKy5zby4yNwBfRFlOQU1JQwBfR0xPQkFMX09GRlNFVF9UQUJMRV8AX2luaXQAX2Zp bmkAZXhpdABfX2Vudmlyb24AYXRleGl0AGxpYnN0ZGMrKy5zby4yNwBsaWJtLnNvLjUAbGli Yy5zby41AHByaW50ZgBlbnZpcm9uAF9fbGliY19pbml0AF9fc2V0ZnB1Y3cAX19mcHVfY29u dHJvbABfZXRleHQAX2VkYXRhAF9fYnNzX3N0YXJ0AF9lbmQAAAAImAQIBQwAAFSXBAgHCAAA WJcECAcKAABclwQIBwcAAGCXBAgHBQAAZJcECAcLAADoiwIAAMIAAP81TJcECP8lUJcECAAA AAD/JVSXBAhoAAAAAOng/////yVYlwQIaAgAAADp0P////8lXJcECGgQAAAA6cD/////JWCX BAhoGAAAAOmw/////yVklwQIaCAAAADpoP///wAAAAAAAAAAWYnjieCD5PiJygHSAdIB0IPA BDHtVVVVieVQU1G4iAAAALsAAAAAzYCLRCQIozSXBAgPtwUImAQIUOip////g8QE6HH///9o UIYECOh3////g8QE6Df////oWgAAAFDodP///1uNdCYAjbwnAAAAALgBAAAAzYDr9420JgAA AABVieVTu0SXBAiDPUSXBAgAdA6J9osD/9CDwwSDOwB19Itd/InsXcOJ9o28JwAAAABVieWJ 7F3DkFWJ5YPsEI1F/VCNRf5QjUX/UI1F8FDoFQEAAIPEEMZF/wHGRf4BjUXwUOjZAAAAg8QE gH39AHQQaFiGBAjorv7//4PEBOsOkGhzhgQI6J7+//+DxATGRf8BxkX+AI1F8FDoogAAAIPE BIB9/QB0EWiPhgQI6Hf+//+DxATrD4n2aKqGBAjoZv7//4PEBMZF/wDGRf4BjUXwUOhqAAAA g8QEgH39AHQRaMaGBAjoP/7//4PEBOsPifZo4YYECOgu/v//g8QExkX/AMZF/gCNRfBQ6DIA AACDxASAff0AdBFo/YYECOgH/v//g8QE6w+J9mgYhwQI6Pb9//+DxAQxwOsDjXYAiexdw1WJ 5VOLRQiLUAgwyYsYgDsAdAqLWASAOwB0ArEBiAqLXfyJ7F3DifZVieVWU4t1CItVDItNEItd FIkWiU4EiV4IifDrA412AI1l+Fteiexdw5CQkJCQkJCQkJCQkJCQkFWJ5VO7OJcECIM9OJcE CP90Don2iwP/0IPD/IM7/3X0i138iexdw4n2jbwnAAAAAFWJ5YnsXcOQAAAAAAAAAADoG/7/ /8IAAGFuZCAoMTEpIHJlc3VsdHMgaW4gVFJVRQoNAGFuZCAoMTEpIHJlc3VsdHMgaW4gRkFM U0UKDQBhbmQgKDEwKSByZXN1bHRzIGluIFRSVUUKDQBhbmQgKDEwKSByZXN1bHRzIGluIEZB TFNFCg0AYW5kICgwMSkgcmVzdWx0cyBpbiBUUlVFCg0AYW5kICgwMSkgcmVzdWx0cyBpbiBG QUxTRQoNAGFuZCAoMDApIHJlc3VsdHMgaW4gVFJVRQoNAGFuZCAoMDApIHJlc3VsdHMgaW4g RkFMU0UKDQAAAAAA/////wAAAAD/////AAAAAGiXBAgAAAAAAAAAAJ6DBAiugwQIvoMECM6D BAjegwQIAQAAAAEAAAABAAAATwAAAAEAAABfAAAAAQAAAGkAAAAMAAAAgIMECA0AAABQhgQI BAAAAOiABAgFAAAAiIIECAYAAAB4gQQICgAAAMYAAAALAAAAEAAAABUAAAAAAAAAAwAAAEiX BAgCAAAAKAAAABQAAAARAAAAFwAAAFiDBAgRAAAAUIMECBIAAAAIAAAAEwAAAAgAAAAAAAAA AAAAAABHQ0M6IChHTlUpIDIuNy4yLjIAAEdDQzogKEdOVSkgMi43LjIuMgAAR0NDOiAoR05V KSAyLjcuMi4yAAgAAAAAAAAAAQAAADAxLjAxAAAACAAAAAAAAAABAAAAMDEuMDEAAAAIAAAA AAAAAAEAAAAwMS4wMQAAAAAuc3ltdGFiAC5zdHJ0YWIALnNoc3RydGFiAC5pbnRlcnAALmhh c2gALmR5bnN5bQAuZHluc3RyAC5yZWwuYnNzAC5yZWwucGx0AC5pbml0AC5wbHQALnRleHQA LmZpbmkALnJvZGF0YQAuZGF0YQAuY3RvcnMALmR0b3JzAC5nb3QALmR5bmFtaWMALmJzcwAu Y29tbWVudAAubm90ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GwAAAAEAAAACAAAA1IAECNQAAAATAAAAAAAAAAAAAAABAAAAAAAAACMAAAAFAAAAAgAAAOiA BAjoAAAAkAAAAAMAAAAAAAAABAAAAAQAAAApAAAACwAAAAIAAAB4gQQIeAEAABABAAAEAAAA AQAAAAQAAAAQAAAAMQAAAAMAAAACAAAAiIIECIgCAADGAAAAAAAAAAAAAAABAAAAAAAAADkA AAAJAAAAAgAAAFCDBAhQAwAACAAAAAMAAAARAAAABAAAAAgAAABCAAAACQAAAAIAAABYgwQI WAMAACgAAAADAAAACAAAAAQAAAAIAAAASwAAAAEAAAAGAAAAgIMECIADAAAIAAAAAAAAAAAA AAAQAAAAAAAAAFEAAAABAAAABgAAAIiDBAiIAwAAYAAAAAAAAAAAAAAABAAAAAQAAABWAAAA AQAAAAYAAADwgwQI8AMAAFgCAAAAAAAAAAAAABAAAAAAAAAAXAAAAAEAAAAGAAAAUIYECFAG AAAIAAAAAAAAAAAAAAAQAAAAAAAAAGIAAAABAAAAAgAAAFiGBAhYBgAA3AAAAAAAAAAAAAAA AQAAAAAAAABqAAAAAQAAAAMAAAA0lwQINAcAAAQAAAAAAAAAAAAAAAQAAAAAAAAAcAAAAAEA AAADAAAAOJcECDgHAAAIAAAAAAAAAAAAAAAEAAAAAAAAAHcAAAABAAAAAwAAAECXBAhABwAA CAAAAAAAAAAAAAAABAAAAAAAAAB+AAAAAQAAAAMAAABIlwQISAcAACAAAAAAAAAAAAAAAAQA AAAEAAAAgwAAAAYAAAADAAAAaJcECGgHAACgAAAABAAAAAAAAAAEAAAACAAAAIwAAAAIAAAA AwAAAAiYBAgICAAABAAAAAAAAAAAAAAABAAAAAAAAACRAAAAAQAAAAAAAAAAAAAACAgAADwA AAAAAAAAAAAAAAEAAAAAAAAAmgAAAAcAAAAAAAAAPAAAAEQIAAA8AAAAAAAAAAAAAAABAAAA AAAAABEAAAADAAAAAAAAAAAAAACACAAAoAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAgAAAAAA AAAAAAAAuAwAAOADAAAWAAAAKQAAAAQAAAAQAAAACQAAAAMAAAAAAAAAAAAAAJgQAACBAQAA AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1IAECAAAAAADAAEAAAAAAOiA BAgAAAAAAwACAAAAAAB4gQQIAAAAAAMAAwAAAAAAiIIECAAAAAADAAQAAAAAAFCDBAgAAAAA AwAFAAAAAABYgwQIAAAAAAMABgAAAAAAgIMECAAAAAADAAcAAAAAAIiDBAgAAAAAAwAIAAAA AADwgwQIAAAAAAMACQAAAAAAUIYECAAAAAADAAoAAAAAAFiGBAgAAAAAAwALAAAAAAA0lwQI AAAAAAMADAAAAAAAOJcECAAAAAADAA0AAAAAAECXBAgAAAAAAwAOAAAAAABIlwQIAAAAAAMA DwAAAAAAaJcECAAAAAADABAAAAAAAAiYBAgAAAAAAwARAAAAAAAAAAAAAAAAAAMAEgAAAAAA PAAAAAAAAAADABMAAAAAAAAAAAAAAAAAAwAUAAAAAAAAAAAAAAAAAAMAFQAAAAAAAAAAAAAA AAADABYAAQAAAAAAAAAAAAAABADx/wwAAAAQhgQIAAAAAAAACQAbAAAAEIYECAAAAAACAAkA MQAAADyXBAgAAAAAAQANAD4AAABAhgQIAAAAAAIACQBJAAAAOJcECAAAAAABAAwAVwAAAESX BAgAAAAAAQAOAGQAAAAAAAAAAAAAAAQA8f9rAAAAYIQECAAAAAAAAAkAAQAAAAAAAAAAAAAA BADx/wwAAABwhAQIAAAAAAAACQBwAAAAcIQECAAAAAACAAkAhgAAAECXBAgAAAAAAQAOAJQA AACghAQIAAAAAAIACQBJAAAAOJcECAAAAAABAAwAnwAAADiXBAgAAAAAAQANAK0AAAAAAAAA AAAAAAQA8f8MAAAAqIQECAAAAAAAAAkAuAAAAJiDBAgoAAAAIgAAAL8AAABolwQIAAAAABEA 8f/IAAAASIYECAAAAAARAPH/zwAAADSXBAgEAAAAEQAMANkAAACAgwQIAAAAABIABwDfAAAA qIMECEYAAAASAAAA6wAAADSXBAgEAAAAIAAMAPMAAACwhQQIJgAAACIACQAAAQAACJgECAIA AAARABEADgEAAPCDBAiAAAAAEgAJABUBAADwgwQIAAAAABAACQAkAQAACJgECAAAAAARAPH/ MAEAAKiEBAgIAQAAEgAJADUBAABQhgQIAAAAABIACgA7AQAAuIMECDgAAAASAAAAQgEAAAiY BAgAAAAAEQDx/0kBAABIlwQIAAAAABEA8f9fAQAADJgECAAAAAARAPH/ZAEAAMiDBAigAAAA EgAAAGkBAADYhQQIKQAAACIACQB2AQAA2IMECD4AAAASAAAAAGNydHN0dWZmLmMAZ2NjMl9j b21waWxlZC4AX19kb19nbG9iYWxfY3RvcnNfYXV4AF9fQ1RPUl9FTkRfXwBpbml0X2R1bW15 AGZvcmNlX3RvX2RhdGEAX19EVE9SX0VORF9fAGNydDAuUwBkb25lAF9fZG9fZ2xvYmFsX2R0 b3JzX2F1eABfX0RUT1JfTElTVF9fAGZpbmlfZHVtbXkAX19DVE9SX0xJU1RfXwBmMDAuSUku Y3BwAHByaW50ZgBfRFlOQU1JQwBfZXRleHQAX19lbnZpcm9uAF9pbml0AF9fbGliY19pbml0 AGVudmlyb24AZGVsdGFfXzRhbmQyAF9fZnB1X2NvbnRyb2wAX3N0YXJ0AF9fX2NydF9kdW1t eV9fAF9fYnNzX3N0YXJ0AG1haW4AX2ZpbmkAYXRleGl0AF9lZGF0YQBfR0xPQkFMX09GRlNF VF9UQUJMRV8AX2VuZABleGl0AF9fNGFuZDJQYk4yMQBfX3NldGZwdWN3AA== --------------472A7EEE22D2127E23E6ED9B-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02027 for ; Mon, 24 Jul 2000 23:32:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:22 +0200 (MEST) Received: (qmail 9962 invoked by uid 0); 23 Jul 2000 01:23:34 -0000 Received: from hl.egroups.com (208.50.99.197) by mx02.gmx.net with SMTP; 23 Jul 2000 01:23:34 -0000 X-eGroups-Return: sentto-1101623-521-964315410-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 23 Jul 2000 01:23:33 -0000 Received: (qmail 23436 invoked from network); 23 Jul 2000 01:23:29 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 23 Jul 2000 01:23:29 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta1 with SMTP; 23 Jul 2000 01:23:29 -0000 Received: from modem-33.seaborgium.dialup.pol.co.uk ([62.136.73.33] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13GAUK-00051b-00 for f-cpu@egroups.com; Sun, 23 Jul 2000 02:23:28 +0100 Sender: root@pop.gmx.net Message-ID: <397A4B9F.555A7B39@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 02:34:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] A newer version of C++ circuit sim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 19818c6c58101f2cecb54f9218647d39 Status: R X-Status: N With a 32 way 2 input  and gate test.
Jeff Davies

jeff@llandre.freeserve.co.uk
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02029 for ; Mon, 24 Jul 2000 23:32:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:22 +0200 (MEST) Received: (qmail 11308 invoked by uid 0); 23 Jul 2000 01:26:18 -0000 Received: from cj.egroups.com (208.50.144.68) by mx02.gmx.net with SMTP; 23 Jul 2000 01:26:18 -0000 X-eGroups-Return: sentto-1101623-522-964315576-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 23 Jul 2000 01:26:17 -0000 Received: (qmail 27789 invoked from network); 23 Jul 2000 01:26:16 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Jul 2000 01:26:16 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta1 with SMTP; 23 Jul 2000 01:26:15 -0000 Received: from modem-33.seaborgium.dialup.pol.co.uk ([62.136.73.33] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13GAWu-0005A2-00 for f-cpu@egroups.com; Sun, 23 Jul 2000 02:26:09 +0100 Sender: root@pop.gmx.net Message-ID: <397A4C41.99388390@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 02:37:05 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: A newer version of C++ circuit sim] Content-Type: multipart/mixed; boundary="------------2E6D5A501A67FF49AC0DF92A" X-UIDL: bfea1e75e52b88ebd990994193ed692d Status: R X-Status: N --------------2E6D5A501A67FF49AC0DF92A Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Oops, files are here:

32 way 2 input AND works
Jeff Davies
jeff@llandre.freeserve.co.uk
--------------2E6D5A501A67FF49AC0DF92A Content-Type: text/plain; charset=us-ascii; name="f00.II.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f00.II.cpp" #include #define NODE bool #define HI true #define LO false // ########## 2 input AND Gate ################### class and2 { public: NODE *in1, *in2, *out; and2::and2 (NODE *_in1, NODE *_in2, NODE *_out) { in1=_in1; in2=_in2; out=_out; }; void and2::delta () { *out=*in1 && *in2; }; }; //end class and2 // ########## array of 32 AND Gates ############ class and2_32 { public: and2 *thegates[32]; and2_32::and2_32 (NODE _in1[32], NODE _in2[32], NODE _out[32]) { int x; for (x=0;x<32;x++) thegates[x]=new and2(&_in1[x],&_in2[x],&_out[x]); }; //end of constructor and2_32::~and2_32 () { int x; for (x=0;x<32;x++) delete thegates[x]; }; void and2_32::delta() { int x; for (x=0;x<32;x++) { thegates[x]->delta(); }; }; //end of delta function }; //end of class and2_32 // ########### 2 input NAND Gate ################# class nand2 { public: NODE *in1,*in2,*out; nand2::nand2 (NODE *_in1, NODE *_in2, NODE *_out) { in1=_in1; in2=_in2; out=_out; } void nand2::delta () { if(*in1 && *in2) { *out=LO; } else { *out=HI; }; }; }; //end class nand2 //###################### Tristate Buffer ################# class tribuf1 { public: NODE *in,*enable,*out; tribuf1::tribuf1 (NODE *_in, NODE *_enable, NODE *_out) { in=_in; enable=_enable; out=_out; }; void tribuf1::delta () { if(enable) *out=*in; }; }; //end class tribuf1 //################### D Type Flip Flop ####################### class dtype1 { public: NODE oldclock,*in,*clock,*out; dtype1::dtype1 (NODE *_in, NODE *_clock, NODE *_out) { in=_in; clock=_clock; out=_out; }; void dtype1::delta () { if (oldclock == LO && *clock == HI) { //positive edge so *out=*in; }; oldclock = *clock; }; }; //end of class dtype1 //--------------------------------------------------- //parts to complete: //dtype1_32 //tribuf1_32 //and2_32 //nand2_32 //invert1_32 //add2_32 perhaps join up many add2_4?? void main() { //################# 2 input AND test ############### printf ("AND 2 input test\n\r"); NODE a,b,c; and2 gate1(&a,&b,&c); a=HI; b=HI; gate1.delta(); if (c) { printf ("and (11) results in TRUE\n\r"); } else { printf ("and (11) results in FALSE\n\r"); }; a=HI; b=LO; gate1.delta(); if (c) { printf ("and (10) results in TRUE\n\r"); } else { printf ("and (10) results in FALSE\n\r"); }; a=LO; b=HI; gate1.delta(); if (c) { printf ("and (01) results in TRUE\n\r"); } else { printf ("and (01) results in FALSE\n\r"); }; a=LO; b=LO; gate1.delta(); if (c) { printf ("and (00) results in TRUE\n\r"); } else { printf ("and (00) results in FALSE\n\r"); }; //buses will be done thus //const buswidth=32; //NODE a[buswidth]; NODE a32[32],b32[32],c32[32]; and2_32 thegate(a32,b32,c32); int x; int count1=0; int count2=0; printf ("\n\rStarting 32 bit test\n\r"); printf ("Test 1 HIHIHILO on a, HILO on b\n\r"); for (x=0;x<32;x++) { if (count1==0) { a32[x]=HI; } else { a32[x]=LO; }; count1++; if (count1==2) count1=0; if (count2==0) { b32[x]=HI; } else { b32[x]=LO; }; count2++; if (count2==5) count2=0; }; thegate.delta(); printf("A32 = "); for (x=0;x<32;x++) { if (a32[x]==HI) printf("H"); else printf("L"); }; printf("\n\r"); printf("B32 = "); for (x=0;x<32;x++) { if (b32[x]==HI) printf("H"); else printf("L"); }; printf("\n\r"); printf("C32 = "); for (x=0;x<32;x++) { if (c32[x]==HI) printf("H"); else printf("L"); }; printf("\n\r"); } //end main --------------2E6D5A501A67FF49AC0DF92A Content-Type: application/octet-stream; name="sim" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sim" f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAcIQECDQAAABkDQAAAAAAADQAIAAFACgAFwAUAAYA AAA0AAAANIAECDSABAigAAAAoAAAAAUAAAAEAAAAAwAAANQAAADUgAQI1IAECBMAAAATAAAA BAAAAAEAAAABAAAAAAAAAACABAgAgAQIbgsAAG4LAAAFAAAAABAAAAEAAABwCwAAcJsECHCb BAjcAAAA4AAAAAYAAAAAEAAAAgAAAKwLAACsmwQIrJsECKAAAACgAAAABgAAAAQAAAAvbGli L2xkLWxpbnV4LnNvLjEAABEAAAATAAAAAAAAABAAAAACAAAAAAAAAA8AAAAAAAAACwAAAAYA AAAEAAAAAwAAAAoAAAANAAAABQAAAAcAAAAAAAAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAAAAAAAABAAAADgAAAAAA AAAMAAAAAAAAAAAAAAAAAAAAAAAAAA4AAACsmwQIAAAAABEA8f8XAAAAhJsECAAAAAARAPH/ LQAAAOCDBAgAAAAAEgAHADMAAAAgigQIAAAAABIACgA5AAAAOIQECCAAAAAiAAAASgAAAFiE BAhDAAAAIgAAAFgAAAAohAQIoAAAABIAAABdAAAAcJsECAQAAAARAAwAZwAAABiEBAg4AAAA EgAAAJIAAAD4gwQIKAAAACIAAACZAAAAcJsECAQAAAAgAAwAoQAAAAiEBAhGAAAAEgAAAK0A AABIhAQIPgAAABIAAAC4AAAATJwECAIAAAARABEAxgAAABiKBAgAAAAAEQDx/80AAABMnAQI AAAAABEA8f/UAAAATJwECAAAAAARAPH/4AAAAFCcBAgAAAAAEQDx/wBsaWJnKysuc28uMjcA X0RZTkFNSUMAX0dMT0JBTF9PRkZTRVRfVEFCTEVfAF9pbml0AF9maW5pAF9fYnVpbHRpbl9k ZWxldGUAX19idWlsdGluX25ldwBleGl0AF9fZW52aXJvbgBhdGV4aXQAbGlic3RkYysrLnNv LjI3AGxpYm0uc28uNQBsaWJjLnNvLjUAcHJpbnRmAGVudmlyb24AX19saWJjX2luaXQAX19z ZXRmcHVjdwBfX2ZwdV9jb250cm9sAF9ldGV4dABfZWRhdGEAX19ic3Nfc3RhcnQAX2VuZAAA AABMnAQIBQ4AAJCbBAgHCgAAlJsECAcMAACYmwQIBwkAAJybBAgHBwAAoJsECAcFAACkmwQI Bw0AAKibBAgHBgAAAAAAAAAAAADo+wUAAMIAAP81iJsECP8ljJsECAAAAAD/JZCbBAhoAAAA AOng/////yWUmwQIaAgAAADp0P////8lmJsECGgQAAAA6cD/////JZybBAhoGAAAAOmw//// /yWgmwQIaCAAAADpoP////8lpJsECGgoAAAA6ZD/////JaibBAhoMAAAAOmA////AAAAAAAA AABZieOJ4IPk+InKAdIB0gHQg8AEMe1VVVWJ5VBTUbiIAAAAuwAAAADNgItEJAijcJsECA+3 BUycBAhQ6Jn///+DxAToUf///2ggigQI6Ff///+DxAToF////+haAAAAUOhU////W410JgCN vCcAAAAAuAEAAADNgOv3jbQmAAAAAFWJ5VO7gJsECIM9gJsECAB0Don2iwP/0IPDBIM7AHX0 i138iexdw4n2jbwnAAAAAFWJ5YnsXcOQVYnlgez8AAAAaCiKBAjovf7//4PEBI1F/VCNRf5Q jUX/UI1F8FDoXQQAAIPEEMZF/wHGRf4BjUXwUOghBAAAg8QEgH39AHQQaDuKBAjofv7//4PE BOsOkGhWigQI6G7+//+DxATGRf8BxkX+AI1F8FDo6gMAAIPEBIB9/QB0EWhyigQI6Ef+//+D xATrD4n2aI2KBAjoNv7//4PEBMZF/wDGRf4BjUXwUOiyAwAAg8QEgH39AHQRaKmKBAjoD/7/ /4PEBOsPifZoxIoECOj+/f//g8QExkX/AMZF/gCNRfBQ6HoDAACDxASAff0AdBFo4IoECOjX /f//g8QE6w+J9mj7igQI6Mb9//+DxASNRZBQjUWwUI1F0FCNhRD///9Q6MsCAACDxBDHhQj/ //8AAAAAx4UE////AAAAAGgXiwQI6Ir9//+DxARoMIsECOh9/f//g8QEx4UM////AAAAAIO9 DP///x9+B+mSAAAAifaDvQj///8AdRONRdCJwgOVDP///8YCAesRjXYAjUXQicIDlQz////G AgD/hQj///+DvQj///8CdQrHhQj///8AAAAAg70E////AHUQjUWwicIDlQz////GAgHrDo1F sInCA5UM////xgIA/4UE////g70E////BXUKx4UE////AAAAAP+FDP///+li////ifaNhRD/ //9Q6FgBAACDxARoUosECOi3/P//g8QEx4UM////AAAAAIO9DP///x9+Bes7jXYAjUXQicID lQz///+AOgF1EGhZiwQI6IL8//+DxATrDpBoW4sECOhy/P//g8QE/4UM////672NdgBoXYsE COha/P//g8QEaGCLBAjoTfz//4PEBMeFDP///wAAAACDvQz///8ffgPrOZCNRbCJwgOVDP// /4A6AXUQaFmLBAjoGvz//4PEBOsOkGhbiwQI6Ar8//+DxAT/hQz////rv412AGhdiwQI6PL7 //+DxARoZ4sECOjl+///g8QEx4UM////AAAAAIO9DP///x9+A+s5kI1FkInCA5UM////gDoB dRBoWYsECOiy+///g8QE6w6QaFuLBAjoovv//4PEBP+FDP///+u/jXYAaF2LBAjoivv//4PE BGoCjYUQ////UOhFAAAAg8QIMcDrAon2iexdw1WJ5YPsBFOLXQjHRfwAAAAAg338H34F6xeN dgCLRfyLFINS6NQAAACDxAT/Rfzr4Ytd+InsXcOQVYnlg+wEVlOLdQiLXQzHRfwAAAAAg338 H34F6xeNdgCLRfyLFIZS6Ej7//+DxAT/Rfzr4YnYg+ABhcB0C1boMfv//4PEBOsAjWX0W16J 7F3DjXYAVYnlg+wEV1ZTi10Mi3UQi30Ux0X8AAAAAIN9/B9+Bes7jXYAifgDRfxQifADRfxQ idgDRfxQagzoA/v//4PEBInAUOhQAAAAg8QQicCLVfyLTQiJBJH/RfzrvpCLRQjrA412AI1l 8FteX4nsXcOJ9lWJ5VOLRQiLUAgwyYsYgDsAdAqLWASAOwB0ArEBiAqLXfyJ7F3DifZVieVW U4t1CItVDItNEItdFIkWiU4EiV4IifDrA412AI1l+Fteiexdw5CQkJCQkJBVieVTu3SbBAiD PXSbBAj/dA6J9osD/9CDw/yDO/919Itd/InsXcOJ9o28JwAAAABVieWJ7F3DkAAAAAAAAAAA 6Mv6///CAABBTkQgMiBpbnB1dCB0ZXN0Cg0AYW5kICgxMSkgcmVzdWx0cyBpbiBUUlVFCg0A YW5kICgxMSkgcmVzdWx0cyBpbiBGQUxTRQoNAGFuZCAoMTApIHJlc3VsdHMgaW4gVFJVRQoN AGFuZCAoMTApIHJlc3VsdHMgaW4gRkFMU0UKDQBhbmQgKDAxKSByZXN1bHRzIGluIFRSVUUK DQBhbmQgKDAxKSByZXN1bHRzIGluIEZBTFNFCg0AYW5kICgwMCkgcmVzdWx0cyBpbiBUUlVF Cg0AYW5kICgwMCkgcmVzdWx0cyBpbiBGQUxTRQoNAAoNU3RhcnRpbmcgMzIgYml0IHRlc3QK DQBUZXN0IDEgSElISUhJTE8gb24gYSwgSElMTyBvbiBiCg0AQTMyID0gAEgATAAKDQBCMzIg PSAAQzMyID0gAAAAAAAAAP////8AAAAA/////wAAAACsmwQIAAAAAAAAAAD+gwQIDoQECB6E BAguhAQIPoQECE6EBAhehAQIAQAAAAEAAAABAAAAbgAAAAEAAAB+AAAAAQAAAIgAAAAMAAAA 4IMECA0AAAAgigQIBAAAAOiABAgFAAAAsIIECAYAAACAgQQICgAAAOUAAAALAAAAEAAAABUA AAAAAAAAAwAAAISbBAgCAAAAOAAAABQAAAARAAAAFwAAAKCDBAgRAAAAmIMECBIAAAAIAAAA EwAAAAgAAAAAAAAAAAAAAABHQ0M6IChHTlUpIDIuNy4yLjIAAEdDQzogKEdOVSkgMi43LjIu MgAAR0NDOiAoR05VKSAyLjcuMi4yAAgAAAAAAAAAAQAAADAxLjAxAAAACAAAAAAAAAABAAAA MDEuMDEAAAAIAAAAAAAAAAEAAAAwMS4wMQAAAAAuc3ltdGFiAC5zdHJ0YWIALnNoc3RydGFi AC5pbnRlcnAALmhhc2gALmR5bnN5bQAuZHluc3RyAC5yZWwuYnNzAC5yZWwucGx0AC5pbml0 AC5wbHQALnRleHQALmZpbmkALnJvZGF0YQAuZGF0YQAuY3RvcnMALmR0b3JzAC5nb3QALmR5 bmFtaWMALmJzcwAuY29tbWVudAAubm90ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGwAAAAEAAAACAAAA1IAECNQAAAATAAAAAAAAAAAAAAABAAAAAAAAACMA AAAFAAAAAgAAAOiABAjoAAAAmAAAAAMAAAAAAAAABAAAAAQAAAApAAAACwAAAAIAAACAgQQI gAEAADABAAAEAAAAAQAAAAQAAAAQAAAAMQAAAAMAAAACAAAAsIIECLACAADlAAAAAAAAAAAA AAABAAAAAAAAADkAAAAJAAAAAgAAAJiDBAiYAwAACAAAAAMAAAARAAAABAAAAAgAAABCAAAA CQAAAAIAAACggwQIoAMAADgAAAADAAAACAAAAAQAAAAIAAAASwAAAAEAAAAGAAAA4IMECOAD AAAIAAAAAAAAAAAAAAAQAAAAAAAAAFEAAAABAAAABgAAAOiDBAjoAwAAgAAAAAAAAAAAAAAA BAAAAAQAAABWAAAAAQAAAAYAAABwhAQIcAQAAKgFAAAAAAAAAAAAABAAAAAAAAAAXAAAAAEA AAAGAAAAIIoECCAKAAAIAAAAAAAAAAAAAAAQAAAAAAAAAGIAAAABAAAAAgAAACiKBAgoCgAA RgEAAAAAAAAAAAAAAQAAAAAAAABqAAAAAQAAAAMAAABwmwQIcAsAAAQAAAAAAAAAAAAAAAQA AAAAAAAAcAAAAAEAAAADAAAAdJsECHQLAAAIAAAAAAAAAAAAAAAEAAAAAAAAAHcAAAABAAAA AwAAAHybBAh8CwAACAAAAAAAAAAAAAAABAAAAAAAAAB+AAAAAQAAAAMAAACEmwQIhAsAACgA AAAAAAAAAAAAAAQAAAAEAAAAgwAAAAYAAAADAAAArJsECKwLAACgAAAABAAAAAAAAAAEAAAA CAAAAIwAAAAIAAAAAwAAAEycBAhMDAAABAAAAAAAAAAAAAAABAAAAAAAAACRAAAAAQAAAAAA AAAAAAAATAwAADwAAAAAAAAAAAAAAAEAAAAAAAAAmgAAAAcAAAAAAAAAPAAAAIgMAAA8AAAA AAAAAAAAAAABAAAAAAAAABEAAAADAAAAAAAAAAAAAADEDAAAoAAAAAAAAAAAAAAAAQAAAAAA AAABAAAAAgAAAAAAAAAAAAAA/BAAADAEAAAWAAAAKQAAAAQAAAAQAAAACQAAAAMAAAAAAAAA AAAAACwVAADMAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1IAECAAA AAADAAEAAAAAAOiABAgAAAAAAwACAAAAAACAgQQIAAAAAAMAAwAAAAAAsIIECAAAAAADAAQA AAAAAJiDBAgAAAAAAwAFAAAAAACggwQIAAAAAAMABgAAAAAA4IMECAAAAAADAAcAAAAAAOiD BAgAAAAAAwAIAAAAAABwhAQIAAAAAAMACQAAAAAAIIoECAAAAAADAAoAAAAAACiKBAgAAAAA AwALAAAAAABwmwQIAAAAAAMADAAAAAAAdJsECAAAAAADAA0AAAAAAHybBAgAAAAAAwAOAAAA AACEmwQIAAAAAAMADwAAAAAArJsECAAAAAADABAAAAAAAEycBAgAAAAAAwARAAAAAAAAAAAA AAAAAAMAEgAAAAAAPAAAAAAAAAADABMAAAAAAAAAAAAAAAAAAwAUAAAAAAAAAAAAAAAAAAMA FQAAAAAAAAAAAAAAAAADABYAAQAAAAAAAAAAAAAABADx/wwAAADgiQQIAAAAAAAACQAbAAAA 4IkECAAAAAACAAkAMQAAAHibBAgAAAAAAQANAD4AAAAQigQIAAAAAAIACQBJAAAAdJsECAAA AAABAAwAVwAAAICbBAgAAAAAAQAOAGQAAAAAAAAAAAAAAAQA8f9rAAAA4IQECAAAAAAAAAkA AQAAAAAAAAAAAAAABADx/wwAAADwhAQIAAAAAAAACQBwAAAA8IQECAAAAAACAAkAhgAAAHyb BAgAAAAAAQAOAJQAAAAghQQIAAAAAAIACQBJAAAAdJsECAAAAAABAAwAnwAAAHSbBAgAAAAA AQANAK0AAAAAAAAAAAAAAAQA8f8MAAAAKIUECAAAAAAAAAkAuAAAAPiDBAgoAAAAIgAAAL8A AACsmwQIAAAAABEA8f/IAAAAGIoECAAAAAARAPH/zwAAAIyIBAg3AAAAIgAJAN8AAABwmwQI BAAAABEADADpAAAA4IMECAAAAAASAAcA7wAAAAiEBAhGAAAAEgAAAPsAAABwmwQIBAAAACAA DAADAQAAiIkECCYAAAAiAAkAEAEAAEycBAgCAAAAEQARAB4BAABwhAQIgAAAABIACQAlAQAA cIQECAAAAAAQAAkANAEAAEycBAgAAAAAEQDx/0ABAAAohQQIZAMAABIACQBFAQAAIIoECAAA AAASAAoASwEAABiEBAg4AAAAEgAAAFIBAADEiAQIUQAAACIACQBeAQAAGIkECG4AAAAiAAkA bgEAAEycBAgAAAAAEQDx/3UBAACEmwQIAAAAABEA8f+LAQAAUJwECAAAAAARAPH/kAEAACiE BAigAAAAEgAAAJUBAACwiQQIKQAAACIACQCiAQAAOIQECCAAAAAiAAAAswEAAEiEBAg+AAAA EgAAAL4BAABYhAQIQwAAACIAAAAAY3J0c3R1ZmYuYwBnY2MyX2NvbXBpbGVkLgBfX2RvX2ds b2JhbF9jdG9yc19hdXgAX19DVE9SX0VORF9fAGluaXRfZHVtbXkAZm9yY2VfdG9fZGF0YQBf X0RUT1JfRU5EX18AY3J0MC5TAGRvbmUAX19kb19nbG9iYWxfZHRvcnNfYXV4AF9fRFRPUl9M SVNUX18AZmluaV9kdW1teQBfX0NUT1JfTElTVF9fAGYwMC5JSS5jcHAAcHJpbnRmAF9EWU5B TUlDAF9ldGV4dABkZWx0YV9fN2FuZDJfMzIAX19lbnZpcm9uAF9pbml0AF9fbGliY19pbml0 AGVudmlyb24AZGVsdGFfXzRhbmQyAF9fZnB1X2NvbnRyb2wAX3N0YXJ0AF9fX2NydF9kdW1t eV9fAF9fYnNzX3N0YXJ0AG1haW4AX2ZpbmkAYXRleGl0AF8uXzdhbmQyXzMyAF9fN2FuZDJf MzJQYk4yMQBfZWRhdGEAX0dMT0JBTF9PRkZTRVRfVEFCTEVfAF9lbmQAZXhpdABfXzRhbmQy UGJOMjEAX19idWlsdGluX2RlbGV0ZQBfX3NldGZwdWN3AF9fYnVpbHRpbl9uZXcA --------------2E6D5A501A67FF49AC0DF92A-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02033 for ; Mon, 24 Jul 2000 23:32:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:24 +0200 (MEST) Received: (qmail 16552 invoked by uid 0); 23 Jul 2000 01:42:08 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net with SMTP; 23 Jul 2000 01:42:08 -0000 X-eGroups-Return: sentto-1101623-523-964316519-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 23 Jul 2000 01:42:02 -0000 Received: (qmail 13133 invoked from network); 23 Jul 2000 01:41:59 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 23 Jul 2000 01:41:59 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 23 Jul 2000 01:41:59 -0000 Received: from f-cpu.org (nas3-9.ras.club-internet.fr [195.36.203.9]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA20749 for ; Sun, 23 Jul 2000 03:41:49 +0200 (MET DST) Message-ID: <397A4D38.F22E0ADB@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <397A4C41.99388390@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 03:41:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] [Fwd: A newer version of C++ circuit sim] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ddb994444d80317b62ce8b4741adecd Status: R X-Status: N cool :-)
maybe one day i will use it ?

still, you're missing the geometric dimension.
with wire length data, it would maybe become even more interesting.

Jeff Davies wrote:
>
> Oops, files are here:
>
> 32 way 2 input AND works
> Jeff Davies
> jeff@llandre.freeserve.co.uk
>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02036 for ; Mon, 24 Jul 2000 23:32:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:25 +0200 (MEST) Received: (qmail 22167 invoked by uid 0); 23 Jul 2000 04:41:37 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 23 Jul 2000 04:41:37 -0000 X-eGroups-Return: sentto-1101623-524-964327292-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 23 Jul 2000 04:41:35 -0000 Received: (qmail 19309 invoked from network); 23 Jul 2000 04:41:32 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 23 Jul 2000 04:41:32 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 23 Jul 2000 04:41:32 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6N4gVl21328; Sun, 23 Jul 2000 00:42:31 -0400 Message-Id: <200007230442.e6N4gVl21328@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 00:42:31 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] No clocks. This could be of use Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1aa70853cf2025b74dcb092e93f5c22b Status: R X-Status: N <rares> downix did you see andy glew's post on f-cpu?
<rares> or rather yg's paste of his post elsewhere
<-- ArcWave has quit ([x]chat)
<downix> No, why what's up?
<rares> some stuff about globally asynchronous locally syncronous components on the cpu
<rares> multiple clocks
<rares> weird idea
<rares> might just work
<Eagle> I think I've heard about that.
<rares> I still think nanocomputing is the same bastard child of com,puting as supercolliders are of physics
<rares> there's a better way of doing things
<downix>  would work if you got rid of the clocks altogether
<rares> your chip would fry guaranteed
<rares> wait hmm
<rares> no it wouldn't work
<rares> or would it
<rares> hmm
<rares> you'd need a way to synch parts
<downix> no you don't
<downix> the f21 CPU doesn't have any clock signals at all
<rares> oh shit you're right
<downix> and neither does Eddas
<Eagle> hows it work?
<Eagle> hows it work?
<downix> Eagle:  ready signals
<downix> Eagle:  A process isn't transmitted til it recieves a ready signal from another part
<Eagle> whats the diff?
<rares> which are already part of the CPU
<rares> registers on the F-CPU already have ready bits
<downix> Eagle:  the only parts powered in this case are the parts in-use
* downix nods
<downix> right
<rares> damn
<rares> betcha I post it first :) (wait till netscape loads)
<downix> Eddas took this to it's limited, having no clock signals anywhere in the system

Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02039 for ; Mon, 24 Jul 2000 23:32:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:27 +0200 (MEST) Received: (qmail 24060 invoked by uid 0); 23 Jul 2000 04:46:53 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 23 Jul 2000 04:46:53 -0000 X-eGroups-Return: sentto-1101623-525-964327603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 23 Jul 2000 04:46:53 -0000 Received: (qmail 20867 invoked from network); 23 Jul 2000 04:46:42 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 23 Jul 2000 04:46:42 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 23 Jul 2000 04:46:42 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e6N4lfb21572; Sun, 23 Jul 2000 00:47:41 -0400 Message-Id: <200007230447.e6N4lfb21572@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 00:47:41 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Addendum Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ced05524aac874009303c2643b7da5a2 Status: R X-Status: N <Eagle> well, only powering the parts used makes since. great for a laptop.  so the ready signals are clock signals for individual parts?
<downix> Eagle: pretty much.  Also, through this system things move only as fast as the system can feed it.
<downix> which means a VERY high Mhz
<Eagle> how high?
<downix> A prototype SPARC re-designed for asynch operation had it's egffective Mhz jump from 100 to 1200
<Eagle> wow
<Eagle> so what will be the speed of your cpu?<downix> depends on the size of the gates
<downix> on a 0.25 micron I could end up with 600Mhz, on a 0.18 up to 1.3Ghz
<Eagle> oh
<Eagle> so use 0.08.  lol
<downix> hehe
<downix> the surve would flatten out at 0.12
<Eagle> so there is no reason you cant use .18
<rares> downix don't forget AMD hit 1Ghz with .25 I think
* downix nods
<downix> rares:  I'm not
<Eagle> so at .18 they could do 1.5G?  or 2G?
<downix> no, they could do 1.6
<downix> there is a trade off
<Eagle> o

Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02069 for ; Mon, 24 Jul 2000 23:32:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:36 +0200 (MEST) Received: (qmail 31666 invoked by uid 0); 23 Jul 2000 11:23:10 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 23 Jul 2000 11:23:10 -0000 X-eGroups-Return: sentto-1101623-526-964351383-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 23 Jul 2000 11:23:03 -0000 Received: (qmail 20673 invoked from network); 23 Jul 2000 11:23:02 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 23 Jul 2000 11:23:02 -0000 Received: from unknown (HELO mail.rdc1.wa.home.com) (24.0.2.66) by mta1 with SMTP; 23 Jul 2000 11:23:02 -0000 Received: from nventure.com ([24.10.43.202]) by mail.rdc1.wa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000723112302.EOTV24904.mail.rdc1.wa.home.com@nventure.com> for ; Sun, 23 Jul 2000 04:23:02 -0700 Message-ID: <397AD596.F848D7C3@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <200007230447.e6N4lfb21572@tbird.iworld.com> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 04:23:05 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Addendum Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ad82eba0237eb4dd6eda3c3e2ed2a391 Status: R X-Status: N 
 downix don't forget AMD hit 1Ghz with .25 I think
* downix nods
 rares:  I'm not
so at .18 they could do 1.5G?  or 2G?
 no, they could do 1.6
 there is a trade off
Not exactly.  Both AMD and Intel hit 1GHz using .18, and both used smaller feature sizes on certain critical gates in order to reach that level.  It wasn't enough just to take the poor yields, they were already doing that.  They had to go further and cut out some devices even smaller.

Point being, even with every extreme being pushed (including 20 stage pipelines with Williamette), the really high clock rates (2GHz) will never be exceeded under any technology, at least not by very much, and that path will be very slow.  Moreover, the performance gains won't be very great with the higher clock rates.  There just aren't enough transistors left for cache.

--Maxx

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02075 for ; Mon, 24 Jul 2000 23:32:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:37 +0200 (MEST) Received: (qmail 9614 invoked by uid 0); 23 Jul 2000 11:59:16 -0000 Received: from fj.egroups.com (208.50.99.207) by mx02.gmx.net with SMTP; 23 Jul 2000 11:59:16 -0000 X-eGroups-Return: sentto-1101623-527-964353554-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 23 Jul 2000 11:59:15 -0000 Received: (qmail 7741 invoked from network); 23 Jul 2000 11:59:13 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Jul 2000 11:59:13 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta1 with SMTP; 23 Jul 2000 11:59:13 -0000 Received: from modem-10.einsteinium.dialup.pol.co.uk ([62.136.69.10] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13GKPQ-0007rL-00 for f-cpu@egroups.com; Sun, 23 Jul 2000 12:59:05 +0100 Sender: root@pop.gmx.net Message-ID: <397AE09A.2DCFEAB@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 13:10:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] The Minimal Risc I'm going to implement in c++ circuit sim Content-Type: multipart/mixed; boundary="------------3248F4C77DEA00A75256BFB5" X-UIDL: 6a760c30d1f55912793d3791877748b2 Status: R X-Status: N --------------3248F4C77DEA00A75256BFB5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Kai etc, this is the minimalist risc I'm going to implement,

Files:

Instructions (shows special regs in regfile and instructions)
xfig architecture diagram
gif version of above

JeffDavies
jeff@llandre.freeserve.co.uk
--------------3248F4C77DEA00A75256BFB5 Content-Type: text/plain; charset=us-ascii; name="Instructions.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Instructions.txt" f00.II Instruction set: ====================== Note- the only data size available is 32bit!! Instruction word is initially 32 bit long, consisting of 8 bit instruction code, and two off 12 bit register address It is unlikely that 4K registers would be needed, so long term, two 16 bit instructions could be packed in the same 32 bit value. AND R1,R2 - R1+R2 -> R2 ADD R1,R2 INVERT R1,R2 COPY R1,R2 //hate the term 'move' since it is actually a copy SKIPONZERO R1 //if R1==0 skip next instruction LOAD R1,# // is specified in next 32 bit value STORE R1,# LOAD R1,(R2) STORE R1,(R2) JUMP # //vector in next 32 bit value JUMP R1 SOFTINT optional ZERO R1 //since we have access to 0 constant INCR R1,R2 //R1+1->R2 since we have access to a 1 constant Supervisor only instruction UJUMP R1 // jump and change to user mode REgFile: ======== R0 SUPERONLY Exception Routine Pointer R1 Exception Code (HWint,SWInt,Fault,VirtInstruction,SuperInUserMode) R2 Context Pointer - used by exception code to empty regfile R3 ?? for future use R4-R15 user registers. --------------3248F4C77DEA00A75256BFB5 Content-Type: text/plain; charset=us-ascii; name="f00.II.fig" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f00.II.fig" #FIG 3.1 Landscape Center Inches 1200 2 1 3 0 1 -1 7 0 0 -1 0.000 1 0.0000 1425 1050 75 75 1425 1050 1425 1125 1 3 0 1 -1 7 0 0 -1 0.000 1 0.0000 4125 3600 75 75 4125 3600 4200 3600 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 5325 300 6450 300 6450 6225 5325 6225 5325 300 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 2625 675 3825 675 3825 2025 2625 2025 2625 675 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 3675 2475 4200 2475 4200 3150 3675 3150 3675 2475 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 1275 375 1875 375 1875 975 1275 975 1275 375 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 5325 1275 3825 1275 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 3150 2025 3150 2850 3675 2850 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 1575 975 1575 1575 2625 1575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 4200 2850 5325 2850 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 3600 3450 4050 3450 4050 3900 3600 3900 3600 3450 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 3900 3450 3900 3150 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2850 3600 3600 3600 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2850 3750 3600 3750 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 3225 4125 3750 4125 3750 3900 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 3225 4275 3900 4275 3900 3900 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 1425 1125 1425 1425 975 1425 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 600 300 600 600 1275 600 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 3150 150 3150 675 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 4 1 0 1.00 60.00 120.00 3150 375 2250 375 2250 750 1875 750 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2250 525 1875 525 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 4200 3600 4500 3600 4500 3900 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 7125 1200 7650 1200 7650 1950 7125 1950 7125 1200 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 8400 450 9450 450 9450 1800 8400 1800 8400 450 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 7125 2325 7650 2325 7650 3150 7125 3150 7125 2325 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 8325 2325 8850 2325 8850 3150 8325 3150 8325 2325 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 6450 750 8400 750 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 6450 1575 7125 1575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7125 2700 6450 2700 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 8325 2700 7650 2700 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 9225 1800 9225 2775 8850 2775 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7650 1575 8400 1575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7350 975 7350 1200 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7350 3450 7350 3150 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 8550 3525 8550 3150 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9900 1275 9450 1275 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 7200 3900 7650 3900 7650 4650 7200 4650 7200 3900 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 8250 3900 8700 3900 8700 4650 8250 4650 8250 3900 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7200 4275 6450 4275 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 8250 4275 7650 4275 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9225 4575 8700 4575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7425 5025 7425 4650 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 7275 5400 7725 5400 7725 6000 7275 6000 7275 5400 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 6450 5625 7275 5625 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 7725 5625 8325 5625 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 2175 4950 3600 4950 3600 5550 2175 5550 2175 4950 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 3525 5925 4575 5925 4575 6300 3525 6300 3525 5925 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 4725 6750 5625 6750 5625 7125 4725 7125 4725 6750 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 4725 7275 5625 7275 5625 7650 4725 7650 4725 7275 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 5625 6975 6000 6975 6000 6225 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 6150 6225 6150 7500 5625 7500 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 4575 6075 5325 6075 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2775 5550 2775 6150 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2775 6150 3525 6150 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2775 6225 2775 6975 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 4125 7125 4125 6900 4725 6900 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 4725 7500 4125 7500 4125 7200 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 1 2 1 0 1.00 60.00 120.00 1 0 1.00 60.00 120.00 4125 7200 3450 7200 2 2 2 1 -1 7 0 0 -1 3.000 0 0 -1 0 0 5 2175 6975 3450 6975 3450 7650 2175 7650 2175 6975 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 5325 5175 3600 5175 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 1725 5250 2175 5250 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 4200 5700 4200 5925 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 5400 8025 5400 7650 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 4950 6525 4950 6750 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 2550 8025 2550 7650 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 3075 8025 3075 7650 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 7725 6825 8400 6825 8400 7575 7725 7575 7725 6825 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 10275 6150 10800 6150 10800 6675 10275 6675 10275 6150 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 9225 7350 9750 7350 9750 7950 9225 7950 9225 7350 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 10200 7350 10800 7350 10800 7950 10200 7950 10200 7350 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 4 1 0 1.00 60.00 120.00 8400 7200 8850 7200 8850 7575 9225 7575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9750 7650 10200 7650 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 10500 7350 10500 6975 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 1 0 1.00 60.00 120.00 10500 6975 9525 6975 9525 7350 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9525 7950 9525 8325 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 10575 8175 10575 7950 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 8025 7875 8025 7575 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 4 1 0 1.00 60.00 120.00 6450 6075 6900 6075 6900 7200 7725 7200 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9675 6300 10275 6300 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 9675 6525 10275 6525 2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 1.00 60.00 120.00 10800 6375 11400 6375 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 75 7725 1950 7725 1950 8625 75 8625 75 7725 2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5 150 7800 1875 7800 1875 8550 150 8550 150 7800 4 0 -1 0 0 0 12 0.0000 4 135 360 5475 600 BUS\001 4 0 -1 0 0 0 12 0.0000 4 135 885 2850 1050 REGISTER\001 4 0 -1 0 0 0 12 0.0000 4 135 390 2850 1275 FILE\001 4 0 -1 0 0 0 12 0.0000 4 135 150 1500 750 &\001 4 0 -1 0 0 0 12 0.0000 4 135 330 4200 1200 data\001 4 0 -1 0 0 0 12 0.0000 4 135 615 3300 2325 data out\001 4 0 -1 0 0 0 12 0.0000 4 135 405 1875 1500 clock\001 4 0 -1 0 0 0 12 0.0000 4 135 465 3750 2850 TBUF\001 4 0 -1 0 0 0 12 0.0000 4 135 150 3750 3750 &\001 4 0 -1 0 0 0 12 0.0000 4 135 495 4050 3375 enable\001 4 0 -1 0 0 0 12 0.0000 4 180 825 2475 3600 uc.reg2bus\001 4 0 -1 0 0 0 12 0.0000 4 180 780 2475 4200 regaddr[3]\001 4 0 -1 0 0 0 12 0.0000 4 180 780 2475 4425 regaddr[2]\001 4 0 -1 0 0 0 12 0.0000 4 180 1305 1500 3825 supervisor-mode\001 4 0 -1 0 0 0 12 0.0000 4 150 300 525 1500 trap\001 4 0 -1 0 0 0 12 0.0000 4 135 1005 525 1725 to instruction\001 4 0 -1 0 0 0 12 0.0000 4 135 600 525 1950 decoder\001 4 0 -1 0 0 0 12 0.0000 4 180 690 375 225 uc.regclk\001 4 0 -1 0 0 0 12 0.0000 4 180 1230 3300 225 register address\001 4 0 -1 0 0 0 12 0.0000 4 180 360 1950 375 ra[3]\001 4 0 -1 0 0 0 12 0.0000 4 180 360 2025 975 ra[2]\001 4 0 -1 0 0 0 12 0.0000 4 180 885 4350 4050 trap to instr\001 4 0 -1 0 0 0 12 0.0000 4 135 600 4350 4275 decoder\001 4 0 -1 0 0 0 12 0.0000 4 135 420 8625 900 ALU:\001 4 0 -1 0 0 0 12 0.0000 4 135 435 8625 1350 invert\001 4 0 -1 0 0 0 12 0.0000 4 135 270 8625 1575 and\001 4 0 -1 0 0 0 12 0.0000 4 135 270 8625 1800 add\001 4 0 -1 0 0 0 12 0.0000 4 135 375 7200 1650 latch\001 4 0 -1 0 0 0 12 0.0000 4 135 300 7200 2775 tbuf\001 4 0 -1 0 0 0 12 0.0000 4 135 375 8400 2775 latch\001 4 0 -1 0 0 0 12 0.0000 4 135 225 7425 975 clk\001 4 0 -1 0 0 0 12 0.0000 4 135 225 8625 3600 clk\001 4 0 -1 0 0 0 12 0.0000 4 135 495 7425 3600 enable\001 4 0 -1 0 0 0 12 0.0000 4 135 1020 9975 1350 function code\001 4 0 -1 0 0 0 12 0.0000 4 135 1545 9300 4650 bit 0 from microcode\001 4 0 -1 0 0 0 12 0.0000 4 135 1365 8550 4200 constant '0' or '1'\001 4 0 -1 0 0 0 12 0.0000 4 135 300 7275 4125 tbuf\001 4 0 -1 0 0 0 12 0.0000 4 135 495 7350 5175 enable\001 4 0 -1 0 0 0 12 0.0000 4 135 330 7350 5700 or32\001 4 0 -1 0 0 0 12 0.0000 4 135 2055 8325 5700 zero - detects 0 on the bus\001 4 0 -1 0 0 0 12 0.0000 4 135 1650 8325 5925 to instruction decoder\001 4 0 -1 0 0 0 12 0.0000 4 135 1020 2400 5325 address latch\001 4 0 -1 0 0 0 12 0.0000 4 135 300 3675 6150 tbuf\001 4 0 -1 0 0 0 12 0.0000 4 135 300 4875 7050 tbuf\001 4 0 -1 0 0 0 12 0.0000 4 135 300 4950 7575 tbuf\001 4 0 -1 0 0 0 12 0.0000 4 135 615 2325 7275 external\001 4 0 -1 0 0 0 12 0.0000 4 135 600 2325 7500 memory\001 4 0 -1 0 0 0 12 0.0000 4 135 225 1425 5325 clk\001 4 0 -1 0 0 0 12 0.0000 4 135 495 4050 5625 enable\001 4 0 -1 0 0 0 12 0.0000 4 135 495 5025 6525 enable\001 4 0 -1 0 0 0 12 0.0000 4 135 495 5250 8175 enable\001 4 0 -1 0 0 0 12 0.0000 4 135 600 2325 8250 memreq\001 4 0 -1 0 0 0 12 0.0000 4 135 1050 3075 8175 readNotWrite\001 4 0 -1 0 0 0 12 0.0000 4 135 810 7800 7050 instruction\001 4 0 -1 0 0 0 12 0.0000 4 135 375 7800 7275 latch\001 4 0 -1 0 0 0 12 0.0000 4 105 390 9300 7575 state\001 4 0 -1 0 0 0 12 0.0000 4 135 630 9300 7800 machine\001 4 0 -1 0 0 0 12 0.0000 4 105 390 10275 7575 state\001 4 0 -1 0 0 0 12 0.0000 4 135 375 10275 7800 latch\001 4 0 -1 0 0 0 12 0.0000 4 135 225 7875 8100 clk\001 4 0 -1 0 0 0 12 0.0000 4 135 225 10425 8325 clk\001 4 0 -1 0 0 0 12 0.0000 4 135 525 9225 8475 control\001 4 0 -1 0 0 0 12 0.0000 4 180 540 9225 8700 signals\001 4 0 -1 0 0 0 12 0.0000 4 135 420 10350 6375 super\001 4 0 -1 0 0 0 12 0.0000 4 135 375 10350 6600 latch\001 4 0 -1 0 0 0 12 0.0000 4 135 330 9225 6375 data\001 4 0 -1 0 0 0 12 0.0000 4 135 225 9375 6600 clk\001 4 0 -1 0 0 0 12 0.0000 4 105 240 11400 6450 out\001 4 0 -1 0 0 0 12 0.0000 4 135 1485 10275 2925 ** NOTE CIRCUIT\001 4 0 -1 0 0 0 12 0.0000 4 180 1665 10275 3150 ROUTING reg addres\001 4 0 -1 0 0 0 12 0.0000 4 135 1875 10275 3375 FROM Instruction Latch\001 4 0 -1 0 0 0 12 0.0000 4 135 2235 10275 3600 TO REG FILE nont shown **\001 4 0 -1 0 0 0 12 0.0000 4 135 405 300 8025 f00.II\001 4 0 -1 0 0 0 12 0.0000 4 135 1005 300 8250 Architectural\001 4 0 -1 0 0 0 12 0.0000 4 180 645 300 8475 Diagram\001 --------------3248F4C77DEA00A75256BFB5 Content-Type: image/gif; name="f00.II.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f00.II.gif" R0lGODdhTgNUAvAAAAAAAAAAACwAAAAATgNUAgAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6 SlpqeoqaqrrK2ur6ChsrO0tba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHS09TV1tfY2d rb3N3e39DR4uPk5ebn6Onq6+zt7u/g4fLz9PX29/j5+vv8/f7/8PMKDAgQQLGjyIMKHChQwb OnwIMaLEiRQrWryIMaPG/o0cO3r8CDKkyJEkS5o8iTKlypUsW7p8CTOmzJk0a9q8iTOnzp08 e/r8CTSo0KFEixo9ijSp0qVMmzp9CjWq1KlUq1q9ijWr1q1cu3r9Cjas2LFky5o9izat2rVs 27p9Czeu3Ll069q9izev3r18+/r9Cziw4MGECxs+jDix4sWMGzt+DDmy5MmUK1u+jDmz5s2c O3v+DDq06NGkS5s+jTq16tWsW7t+DTu27Nm0a9u+jTu37t28e/v+DTy48OHEixs/jjy58uXM mzt/Dj269OnUq1u/jj279u3cu3v/Dj68+PHky5s/jz69+vXs27t/Dz++/Pn069u/jz+//v38 /vv7/w9ggAIOSGCBBh6IYIIKLshggw4+CGGEEk5IYYUWXohhhhpuyGGHHn4IYogijkhiiSae iGKKKq7IYosuvghjjDLOSGONNt6IY4467shjjz7+CGSQQg5JZJFGHolkkkouyWSTTj4JZZRS TklllVZeiWWWWm7JZZdefglmmGKOSWaZZp6JZppqrslmm26+CWeccs5JZ5123olnnnruyWef fv4JaKCCDkpooYYeimiiii7KaKOOPgpppJJOSmmlll6Kaaaabsppp55+Cmqooo5Kaqmmnopq qqquymqrrr4Ka6yyzkprrbbeimuuuu7Ka6++/gpssMIOS2yxxh6L/myyyi7LbLPOPgtttNJO S2211l6Lbbbabsttt95+C2644o5Lbrnmnotuuuquy2677r4Lb7zyzktvvfbei2+++u7Lb7/+ /gtwwAIPTHDBBh+McMIKL8xwww4/DHHEEk9MccUWX4xxxhpvzHHHHn8Mcsgij0xyySafjHLK Kq/McssuvwxzzDLPTHPNNt+Mc84678xzzz7/DHTQQg9NdNFGH4100kovzXTTTj8NddRST011 1VZfjXXWWm/Ndddefw122GKPTXbZZp+Ndtpqr812226/DXfccs9Nd91234133nrvzXfffv8N eOCCD0544YYfjnjiii/OeOOOPw555JJPdk555ZZfjnnmmm/Oeeeefw566KKPTnrppp+Oeuqq r856666/Dnvsss9Oe+2234577rrvznvvvv8OfPDCD0988cYfj3zyyi/PfPPOPw999NJPT331 1l+Pffbab899995/D3744o9Pfvnmn49++uqvz3777r+vbAEAOw== --------------3248F4C77DEA00A75256BFB5-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02078 for ; Mon, 24 Jul 2000 23:32:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:40 +0200 (MEST) Received: (qmail 20783 invoked by uid 0); 23 Jul 2000 12:37:22 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 23 Jul 2000 12:37:22 -0000 X-eGroups-Return: sentto-1101623-528-964355838-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 23 Jul 2000 12:37:20 -0000 Received: (qmail 19760 invoked from network); 23 Jul 2000 12:37:17 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Jul 2000 12:37:17 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 23 Jul 2000 12:37:12 -0000 Received: from f-cpu.org (nas3-123.aub.club-internet.fr [195.36.145.123]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA13904 for ; Sun, 23 Jul 2000 14:37:06 +0200 (MET DST) Message-ID: <397AE6D7.1EFE62B0@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007230442.e6N4gVl21328@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 14:36:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] No clocks. This could be of use Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6cba66163255276ba1b1f1bd29ff35ad Status: R X-Status: N Rares Marian wrote:
<snip IRC>

hey guys, it's fun ! post more like this :-)
with a nice {IRC} tag in the subject so we
can distinguish/sort them. i count on you.
hum, and a date/hour indication would be fine,
too :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02081 for ; Mon, 24 Jul 2000 23:32:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:40 +0200 (MEST) Received: (qmail 30186 invoked by uid 0); 23 Jul 2000 12:37:25 -0000 Received: from jj.egroups.com (208.50.144.82) by mx02.gmx.net with SMTP; 23 Jul 2000 12:37:25 -0000 X-eGroups-Return: sentto-1101623-529-964355843-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 23 Jul 2000 12:37:23 -0000 Received: (qmail 16308 invoked from network); 23 Jul 2000 12:37:23 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 23 Jul 2000 12:37:23 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 23 Jul 2000 12:37:18 -0000 Received: from f-cpu.org (nas3-123.aub.club-internet.fr [195.36.145.123]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA13902 for ; Sun, 23 Jul 2000 14:37:05 +0200 (MET DST) Message-ID: <397AE6D6.6C2F2551@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200007230447.e6N4lfb21572@tbird.iworld.com> <397AD596.F848D7C3@nventure.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 14:36:38 +0200 Reply-To: f-cpu@egroups.com Subject: clock rates (was : Re: [f-cpu] Addendum) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d0d4541360e1be93b053379a6a3a2141 Status: R X-Status: N hello,

Albert Abramson wrote:
>
> >  downix don't forget AMD hit 1Ghz with .25 I think
> > * downix nods
> >  rares:  I'm not
> > so at .18 they could do 1.5G?  or 2G?
> >  no, they could do 1.6
> >  there is a trade off
> >
> Not exactly.  Both AMD and Intel hit 1GHz using .18, and both used smaller
> feature sizes on certain critical gates in order to reach that level.
>  It wasn't enough just to take the poor yields, they were already doing that.
>  They had to go further and cut out some devices even smaller.

> Point being, even with every extreme being pushed (including 20 stage pipelines
> with Williamette), the really high clock rates (2GHz) will never be exceeded
> under any technology, at least not by very much, and that path will be very slow.
>  Moreover, the performance gains won't be very great with the higher clock rates.
>  There just aren't enough transistors left for cache.

what awaits us in the future, when silicon/whatever semiconductor technology will
have reached its physical limits, is a new kind of switching element made of
supraconducting material. i guess that in the next years, some research labs
will reach 1THz. The reason why it's not widely used yet is because of the refrigerating
engines (to keep the temperature below the supraconducting temperature). It uses
the same process machines as silicon, so it benefits from the huge investments in
these technology.

When silicon will be out of breath, people will still want faster computers and will
be forced to invest in a "fridge". but then, the real problem is architectural :
at 1THz, the light of speed says that it takes thousands or much more cycles
to travel a few centimeters... i guess that streaming technologies, dataflow computers
and "long vector" machines will be necessary to reduce the high losses in memory latency.

The technology i'm refering to is studied for the american Petaflop Computer Project.
so, when i see people picking about whether to use .18 or .25u, i think it's completely
pointless : by the time we have something ready to fab, 0.05 will be ready and we won't
have scratched the surface of the problems that will happen in the long-range future...
you can't go faster than the light of speed...

> --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02090 for ; Mon, 24 Jul 2000 23:32:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:42 +0200 (MEST) Received: (qmail 18968 invoked by uid 0); 23 Jul 2000 13:16:43 -0000 Received: from mo.egroups.com (207.138.41.166) by mx12.rz2.gmx.net with SMTP; 23 Jul 2000 13:16:43 -0000 X-eGroups-Return: sentto-1101623-530-964358200-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 23 Jul 2000 13:16:41 -0000 Received: (qmail 27986 invoked from network); 23 Jul 2000 13:16:40 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Jul 2000 13:16:40 -0000 Received: from unknown (HELO ms1.tomail.com.tw) (210.200.129.221) by mta1 with SMTP; 23 Jul 2000 13:16:38 -0000 Received: (qmail 10886 invoked from network); 23 Jul 2000 13:17:23 -0000 Received: from h115.s38.ts32.hinet.net (HELO ipad) (163.32.38.115) by ms1.tomail.com.tw with SMTP; 23 Jul 2000 13:17:23 -0000 Message-ID: <000d01bff4a8$542299a0$732620a3@ipad> To: References: <200007230442.e6N4gVl21328@tbird.iworld.com> <397AE6D7.1EFE62B0@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "y.s.l." MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 21:17:18 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [HELP CPU DATASHEET] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2aefa2a6fbc54bb05ac93b0efa28eb53 Status: R X-Status: N [Core Voltage] Wanted!
Please reply to  wdh3222833@ionet.net.tw
or ciscoya@tomail.com.tw
Thankx a  lot!

     CPU Oberseite:
    ---------------------
    -   intel (R)     &nb= sp; -
    -  pentium (R)      -
    -  A80502100 SX963  -   '100' =3D 10= 0 MHz; 'SX963' =3D SX Nummer (s.u.)
    -  ICOMP INDEX=3D815  -   ICOMP Inde= x (Intels CPU Leistungsindex)
    -  L6031231-0373 -
    -o INTEL(M)(C)'92'93-   'o' =3D weisser Punkt = (zeigt wo Pin 1 liegt)
    \--------------------   '\' =3D abgeschraegte = Ecke



__________________________________________________________
PC home =A7K=B6O=B9q=A4l=ABH=BDc=A1A=A5=D3=BD=D0=BD=D0=A6=DC: http://www.pchome.com.tw
  =B7|  =AD=FB  =B2=C4  =A4@  =A1A  =A5x = ; =C6W  =B3=CC  =A4j  =AA=BA  =A4J  =A4f  =BA= =F4  =AF=B8
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02093 for ; Mon, 24 Jul 2000 23:32:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:43 +0200 (MEST) Received: (qmail 14295 invoked by uid 0); 23 Jul 2000 13:19:06 -0000 Received: from mr.egroups.com (208.50.144.80) by mx02.gmx.net with SMTP; 23 Jul 2000 13:19:06 -0000 X-eGroups-Return: sentto-1101623-531-964358336-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mr.egroups.com with NNFMP; 23 Jul 2000 13:18:59 -0000 Received: (qmail 12965 invoked from network); 23 Jul 2000 13:18:55 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 23 Jul 2000 13:18:55 -0000 Received: from unknown (HELO ms1.tomail.com.tw) (210.200.129.221) by mta1 with SMTP; 23 Jul 2000 13:18:54 -0000 Received: (qmail 12255 invoked from network); 23 Jul 2000 13:19:38 -0000 Received: from h115.s38.ts32.hinet.net (HELO ipad) (163.32.38.115) by ms1.tomail.com.tw with SMTP; 23 Jul 2000 13:19:38 -0000 Message-ID: <001c01bff4a8$a510fbe0$732620a3@ipad> To: X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "y.s.l." MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 21:19:31 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [HELP CPU DATASHEET] Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 43e41e9420a9b662a6a4d8863f85a2d4 Status: R X-Status: N [Core Voltage] Wanted! Please reply to wdh3222833@ionet.net.tw or ciscoya@tomail.com.tw Thankx a lot! CPU Oberseite: --------------------- - intel (R) - - pentium (R) - - A80502100 SX963 - '100' = 100 MHz; 'SX963' = SX Nummer (s.u.) - ICOMP INDEX=815 - ICOMP Index (Intels CPU Leistungsindex) - L6031231-0373 - -o INTEL(M)(C)'92'93- 'o' = weisser Punkt (zeigt wo Pin 1 liegt) \-------------------- '\' = abgeschraegte Ecke Ref: http://www.tlr.de/tlr/faq/taktfaq.htm __________________________________________________________ PC home §K¶O¹q¤l«H½c¡A¥Ó½Ð½Ð¦Ü: http://www.pchome.com.tw ·| ­û ²Ä ¤@ ¡A ¥x ÆW ³Ì ¤j ªº ¤J ¤f ºô ¯¸ ------------------------------------------------------------------------ Shoes? On the web? Click Here! http://click.egroups.com/1/7061/1/_/3462/_/964358336/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02096 for ; Mon, 24 Jul 2000 23:32:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:43 +0200 (MEST) Received: (qmail 15820 invoked by uid 0); 23 Jul 2000 13:36:30 -0000 Received: from hk.egroups.com (208.50.99.220) by mx02.gmx.net with SMTP; 23 Jul 2000 13:36:30 -0000 X-eGroups-Return: sentto-1101623-532-964359384-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hk.egroups.com with NNFMP; 23 Jul 2000 13:36:24 -0000 Received: (qmail 8997 invoked from network); 23 Jul 2000 13:36:24 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 23 Jul 2000 13:36:24 -0000 Received: from unknown (HELO ms1.tomail.com.tw) (210.200.129.221) by mta1 with SMTP; 23 Jul 2000 13:36:23 -0000 Received: (qmail 22638 invoked from network); 23 Jul 2000 13:37:08 -0000 Received: from h115.s38.ts32.hinet.net (HELO ipad) (163.32.38.115) by ms1.tomail.com.tw with SMTP; 23 Jul 2000 13:37:08 -0000 Message-ID: <00b601bff4ab$16a8a800$732620a3@ipad> To: X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "y.s.l." MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 21:36:58 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] RE: [HELP CPU DATASHEET] Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 39fb8ed4a435cf71c181b051a0501166 Status: R X-Status: N I found it! >from http://www.tlr.de/tlr/faq/taktfaq.htm 3.4 *Pentium Codes* Prozessor SX Nummer Vcc Praegung --------------------------------------- P100 SX963 STD iPP STD bedeutet 3.135-3.465 V ('3.3 V', Standard) __________________________________________________________ PC home §K¶O¹q¤l«H½c¡A¥Ó½Ð½Ð¦Ü: http://www.pchome.com.tw ·| ­û ²Ä ¤@ ¡A ¥x ÆW ³Ì ¤j ªº ¤J ¤f ºô ¯¸ ------------------------------------------------------------------------ Make new friends, find the old at Classmates.com: http://click.egroups.com/1/7075/1/_/3462/_/964359384/ ------------------------------------------------------------------------ From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02120 for ; Mon, 24 Jul 2000 23:32:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:32:49 +0200 (MEST) Received: (qmail 14752 invoked by uid 0); 23 Jul 2000 15:55:32 -0000 Received: from mk.egroups.com (207.138.41.165) by mx02.gmx.net with SMTP; 23 Jul 2000 15:55:32 -0000 X-eGroups-Return: sentto-1101623-533-964367728-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 23 Jul 2000 15:55:31 -0000 Received: (qmail 7441 invoked from network); 23 Jul 2000 15:55:27 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 23 Jul 2000 15:55:27 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 23 Jul 2000 15:55:27 -0000 Received: from f-cpu.org (nas4-166.aub.club-internet.fr [195.36.145.166]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA02660 for ; Sun, 23 Jul 2000 17:55:25 +0200 (MET DST) Message-ID: <397B1552.A1B84874@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <397AE09A.2DCFEAB@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 17:54:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The Minimal Risc I'm going to implement in c++ circuit sim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d5b9ea58b0fef1fe1b4515fdae86df2a Status: R X-Status: N hi,

i don't know what happened but the GIF appears plain black for me.

Jeff Davies wrote:
>
> Kai etc, this is the minimalist risc I'm going to implement,
>
> Files:
>
> Instructions (shows special regs in regfile and instructions)
> xfig architecture diagram
> gif version of above


have fun with your new toy, and don't forget to post here sometimes :-)

> JeffDavies
> jeff@llandre.freeserve.co.uk
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02171 for ; Mon, 24 Jul 2000 23:33:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:33:01 +0200 (MEST) Received: (qmail 31493 invoked by uid 0); 23 Jul 2000 21:18:54 -0000 Received: from hm.egroups.com (208.50.99.198) by mx02.gmx.net with SMTP; 23 Jul 2000 21:18:54 -0000 X-eGroups-Return: sentto-1101623-534-964387118-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 23 Jul 2000 21:18:42 -0000 Received: (qmail 27035 invoked from network); 23 Jul 2000 21:18:37 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 23 Jul 2000 21:18:37 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta1 with SMTP; 23 Jul 2000 21:18:36 -0000 Received: from modem-150.oxygen.dialup.pol.co.uk ([62.136.7.150] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13GT8a-0001kQ-00 for f-cpu@egroups.com; Sun, 23 Jul 2000 22:18:17 +0100 Sender: root@pop.gmx.net Message-ID: <397B63A9.99BC11F@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <397AE09A.2DCFEAB@llandre.freeserve.co.uk> <397B1552.A1B84874@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 23 Jul 2000 22:29:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The Minimal Risc I'm going to implement in c++ circuit sim Content-Type: multipart/mixed; boundary="------------0D3893F258350D56FA944C81" X-UIDL: 1fe39ec16ea5d790a688bd2e69db9cb4 Status: R X-Status: N --------------0D3893F258350D56FA944C81 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Yann Guidon wrote:

> hi,
>
> i don't know what happened but the GIF appears plain black for me.
>

Sorry here it is again.  (my xfig always does that -should get a later
version- exported from xfig as xpm, imported to gimp, exported as gif:

Also error in "Instructions.txt" - Reg 5 is not general purpose, it's the
Program Counter. (but not supervisor only).

> Jeff Davies wrote:
> >
> > Kai etc, this is the minimalist risc I'm going to implement,
> >
> > Files:
> >
> > Instructions (shows special regs in regfile and instructions)
> > xfig architecture diagram
> > gif version of above
>
> have fun with your new toy, and don't forget to post here sometimes :-)

Ta, will do.

Jeff Davies
--------------0D3893F258350D56FA944C81 Content-Type: image/gif; name="f00.II.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f00.II.gif" R0lGODlhTgNUAoAAAP///wAAACH+Dk1hZGUgd2l0aCBHSU1QACwAAAAATgNUAgAC/oSPqcvt D6OctNqLs968+w+G4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq 9YrNarfcrvcLjgQCgHE4SiaZD+uz+w2Py2vp9PxusOfx/L7/D8i2F6ikl2FoSKi4yNioRtbW trcmOUZpVzfoaAJZp2dpyWYGmpcpWfYZOYpaihBamrgpO0srl1mm2Yq7e9s7WasRKzroy0ss yIt4bJy8XCwMHC09jbasgPlajHxKLeaATen8KRp+Xf5M7ukK3d3u/u6jnYA5Hzn/C//ATr/O r+ufy5nAXQTXGcyHMKFCGOhcDWM28NZChw2wWWMmMVyi/obaNA6cCDKkSA6rWE1SBe5hKHUi ob1ClXJlJU+dNkJqpY4UrJ08R/r8CbQEwKAL2H1DRjSp0qXVAlKRSbOH0YpImVq9ijXIyysZ q+aYWpFb1rFkyybc6BUHWLNs27qV1klXwYJrX9R9izevXgl3nZzTtLUvC8HtQBk+jDix4sWM G+vcC5ka4SWpJCKdnALzNM1qI3uG64WfZcBSiXK+cfqz6jOpi4i2NrRz0NY0aK++vcW2VlW4 UqZFbdov7uGKdE9wjBz5cQbJmzt3HLyJceLUoUz3pqKusJs8rjPy3gJ89fFIxFPNfpzb1q/R mZgnD1/I+6IrTs8/1J5y/P2s/hnWJ/nDfX4IyAl/BobmH3obEGgBg3g4OAKEWTxHYYXKHVhI gpkBGE9+9TyWzSglDQaPhBxiWJ6GKNgXoIf3yDWOReGVmISJKC6o4gmxrHdeabMddZlD48z4 jo3B3JiiXf/BMlqP3blIkUl0yeWCkVVYiQGWSFYA4X1xfQhdd4+NtM+YQ8KkZJE1bmlEl0vC 1CRzPs4V0j5Rnkmlgu5o2SCbruVYoDlr8XkNnXUCSZogeOpZ2Jp+DgGeWIaqceIO3P1kJ4w5 sUSimkk+qlWBZr6JX2mEIsicYWCe5OCpT7jKF6jyWXghOZNGWKkOl/oEa5+eHtGrrP+NSoGk ELDY/uGP0tH4qbBgSHpXnMfmqiuUwDJ7rbN8ROsUdkcmC1SwxWLbprbbclnTuDia+6J75P7J 7hzaZcMltQ3Sim++jNki3K/lxsuvGFHVu+63TcEh7nL+wgswwrH+Nm3BpR78RsIP7+lowxXz FRW3gl48sXUBu0sLtBlr3B/HIhIMZ7f0SfzqyPqV3DLEoaLshpdSptOYvSQ7LJ2+Qg9NdK07 WSwnzilvyKTLuEqBNNM/y1LTot6i2U9PH0St9NNSZ81ozHFwjSjV2/n6m9UdkN01CDrXNgXb QvWL8bhqq+1z21i8PYPcEQM9dTd97bojRbb5rTfMgfYdt8wZLqxPkIXa/mxw4rmRWqyIAytM cc50A/ulbCrbM7nTlVs+IeYK+zN442N/nu2pHhNUOOUho7636iAnyrnIry/7uOy9QySjsafj bgXfhV6SVmyRQ+34ybNuYzqRx6J0WD/O3478lbqrdNGU6na+9MyQCsQn4oh3P/6KZdPrVesC 64SYrQOvBOdi+Z/9e+BAKLMzOkiPfa77Wuk6UrrdIaocxOBURrhjCsM9pF0bA975JJi+ARKQ fHPrUUNox7K/QSRKIBRfLmrXrfWFQIW2qxZGqtepbG3wKd/DGisgCKIQPs8kr0laAE8ouR/e ClX++1/H8hQD9c3wSkXb1wUyNbxvgIh+YKsM/gVVxST+Ac58T2oWw5aYOxLC0G1lu9rzzjSa 2FTiTtTzYQWLKLp/yRCMyXtZC92mHuPZ8W/OQyMQq4JCLb6Ri5bSoHzoyBUnKRFklmEJ6ZgH SAmmLXpedOEcv4hI6LlxkdcDR/aadjQbYq1+L1EPJS9pSTmqMpMc/CMqLTjIx1lqTBd8JSth eUVDEjIY62PhGDUkN07e0nd7FKbYPNBL2LHHb8YcpjLn0kxcKu6XjJNmZ5ipS2fK0inRhOO9 iheiQloTONispDaDxqMhtkiT6/qgtGTgS3Uyrpy2PKc3uykoUs4Ei2HLEmAYKEobxFNc+Pyf PQuYQEy+r4QkFFBq/jjSxjhuU5z1NOhBWynPOYmQd3ekFIfcSc0aKpQ95jzkRYmZUCJoJ6Jo CenakInDZtyQpN4ERkFPukoxqjQ98KMTP/sZhoEypIk/TWI2cTpSl0p0gRxtqvv6t0ugbk2A Cqzm4ri3tnhiyklJ3aNTJaTVvHVVR1c1akmnqlHLueSoOmWdKw2otdSN86ketSpcjxdQf+q1 rIlb61lXdTRV1e9NVOSCUNNUV3hyrDeOdOT+kJkOpX5sZaHjIT81sqNUgE2IGvNrRdeUR6KK VmjPvCta7XrGiDRQslQJ7XPaBVHiqVaSsQ2rQjybUwsW9nJzJWsHUQskX1yCgYeLbEb5/jhb yX0wIBxJZ8NwO1YNOtd7veUrGeH2MOHGr6NVne74YqvcjzA3uXqD7k7ZGUu2JlYEVlop8YrH 0JcurraJWu4L7wtQlJm3lij1XHV/6zXFzk8mzNXcBKd5XZwQeGdYHG4AZ2KQzSltvybFKBGj alrIYvezSOUvBQ8BFj2275jp/at1TytgDnf4Zl7FaotdjOEvHLZKJ7ZeblecUvaK+MWszTGP n4hQ/9a0xvIFrodxnM8vDTdaPR2xTtNzGc2GD8joFXKMfbteQB0ZybAFrxST3Byurm62ERSr erUwYxuzl6oqXjFA4Dev/JqZq/bdsRlLK2M8YznAZt3afGxL/hy33hddupkMAOXRmyL3t3wT FemcMwzjFXKZqeQ1MnboO8K9Ljqoeibyo+mKYk9z+bI38S6Ns3Q/Kcs00meW65ABvOYNC+wk m93zpKm81C2/mre75rOkZZ1a/Er11lW1NIs3/axOA9jOB/6wlsPiZVETO1WEuqmJDavs9QqG wmoObqVhPe1Gf0WQJLayuP3sxklx20vk9rawIR3u85oqMEFmdKuBTKwogxIlP15zvmdNCua9 B9CTHi3RPnTc6GIbnaNF+KFhI94sGvwU+Lt2vJ2d5Qz9u9z2tjh+Nu6boTRJZxuX98VL1O7/ 8vrKJCE3SCX55Eek2+Txpg1hCL5D/mTnWeV8fjmiEy7tLl6cfogotRUFu2DLTpHW2b7xznsd a56UBJJJ73GCnV7wiJL5n1vvOtRp3vE2R93XiMX6qLWOXz9GvIc/97jCV35uUI+9z6g+iNzD 3cM2SlnQadT7lN0Odk7zfO6/Nvbw/nzy+r4IvGyH+Lu/ruunsxzcV6e7poGO12lDkmdxCczS OZW/f6wM8hUusdgLT/ZTL9ZWcaV84m9bb8GTXsMZV33Eou361yOE4DjH9eRrT/sUz+/bwNf9 u5ru6t+nPviWd7d9c298yA0+jLNXNOHLHuznFz/6japy2M0O/U/bWh8xzQm8uS+Z2Cd7+pVH fRInPnHj/jO7KL2/fvXVD/7tI9j06Me4kweEfxcWd+PXflDVfzOnQ3/Ae6eUf8tnfQx4gKWk agzGG4wlLwHYBWkWQw74ff2HaR9Yf77HcbKnfPbHfBCIfr3QZO+2WygIeInEfqHmfi4YfYj2 cINmdTTkfSQ4gEF3eTQof6uVaCz4D5iXfCO4fve3fw9ogAcYYT0BYcPQMfN3hMhHfSU4gwW4 RU4YLhi4cErISwbXByHIhaWHhJLXg8NBhmVoURaWgVb4GWvIhuCicwJ4b3E4h124g0mIhXiY h7wCf4E4WFt4h54hh3/4hsoChnhxiIgId2QCh4boiGpoLQ24Go04iVfIK5EY/hmYmIl1pIh9 KImfqBqemEppiBumSIp7CBIaCB+quIp1uBCuSB6wGIucKDi4uBe2eIuLaFO6qBe82ItpSIWN QIvjIYzDaHHJGH6RRx3MqIxvl3IJaIcvOIrR+BZGIYH7llkKVjN8iIq3AY3YaIaL9xF993g8 WIidSI7Z6G6jVGtEaG7rCBnj2I7rlDQ+Z444CI70uIv32BaZoo+09XeJ6ItuYY8AKXSp0gyN BU2aBXrVeHp+qJBkkZC2F446JoZ2EX9LWJFJcZHdZo0nqIV3V5JR9JFMEZIbmJFZKIPDxoTU mJJKsZKO5ow+KII2mXn/N5MgWYlvx4Ee2Yw7iZI9/vmTswiMRCl+LkmSMmmUegiVotiUU0mA L+mUT7mJodiSJ7mUXCmUG4WVWgmJMUiVXWmVZXlnYblVYjmSMYmW+qeUaamWY/kIG3mQwKaT rDaUegmWc0mXQRmX5diWZsmTJnmWRemXrYiTaCOVFCWSh7mYV1lsiTkRkRKZC7mVkPmVgMmX OUeZLXGZiAmUbfiYb8mZP8iYn3koe4maE5lWedmahmmaZaSalRmakzma+FiablmVsylmtQl7 rJmTg0lTu0mYvHmcMQec+WCZwkmHmembqQmbwymZy9l9cNmZpAmdyLmZJsidfWmdx+eVgXls 25mccimb3+mZ4cmct4me/rn5nN8jYtqoIlRoLMjCnmfhnuBpibrJksoJQ24CoAiYg0aYn5vQ nNipndJVjCO2PS2UWQnqMut2ngdaHPu5nsQpOi04dgEncOmyQCvofuC0eemEnxYqfZpJngua Iq4lWrBFfPfgokS1j13BjwbqfygKGsvWM1KnGEkJHPtWVo2XaXbEoSPKeiLHTRWqowp4VdoF IzCHo6fIoBJaQtqHcaYGMy+HdlPKXU1qjNaFJ2/2VuZZnCxJpO/0pZU3kCNHf4MCpnWTcWhE prRzjP3ZfgYmhfIkoD4qUw5GccYFp3Gai5RXGWu0DUXlj2c6ndIJkwAyo/pDqOlnqA0VSXYK /qQC9WzRqaITc6Q62DxW9I1GE0pQ4Xk4RBOmqqVcaKVvVad4g6ev+ajdyZRMuKr6UWpDeGAO +UKLQnX6ZlmXiqV5aB8pR6cq0UgqNY2xyqmF2ZvqyUS+YXcjBECmMySvykZoV5OlCKn0hnCP pT1Cej4lp6HZSZ3pyaQal2i7oqvsakLxpW76hlvoGIuklTWRIohD43CZeq7QWqvpSki1U2aW yjP+50nvdK05+pRVM6C0Cjfk6prNKpoYSptjeAwt5UrVCqPwSrAa65cm45x9s6zw2amx+awA S30QJEawKj6CZkIJ27CU2arlqqnY968h66wXiKx5Mqb1UIR/VKKO/hWziTmzEeuY/zmep9mv toCo3+ijikp0IKp0RedgrbecRcusR9uo1amgSzuplIizWkuzXruiN1u2X3uNShufY+uoJWu2 5oq27Bi2VMq2XAu3btu2cQu2Xbu2Rouy/Uaxv6m3e6u2suq3Dmu33vm3g4sVWEuymLm1OTu3 77k3P2UmS/aj+xRKMtds+em4gXe4Z5u4b2uyrkZ1PQulDCZ6Q9qkn3uTr8u3o5u0pXuFyXqp GQuzBVpG24ozriuYoXu3khu7wguKM7WxrqooyXsUm+e0FBgTwcp6aum75bmooku8iou4aHCk dZqxFxuPf5FpIBijMzm9LAq8tGu9/pq3/mj2Vbf7st7bVoLKTeDbEeFEtIGLl3V7vWRbuPtb QNz7rmo3hFYjcqYkj33Eu0hSvv5ZvcE7sZPLn+ybqFTCvAIMvQbMQynUdfClph+5wH2btYur sPgLuFxRgbTktCEitXYaWtHLI1NXfhIoYWEJf/yav5nRkVWSw+6ou4w7j/orvWvqwyVcvI0Z ueZbHbc6xBX7iEBMuqC7xADjrk18vnNjW1McxfGCxVXoxFN1xV6axQeyxegyrWJbxZTyxQms PT9qXELEb+cXj1Ams2C8sgzcxZCVxo4QIzsrJRTnsbn2wB4sxOlGUDYcdVr1oBabSy9bdCM8 tI4suMqpxgps/jOYZXel1Lk3HMJ0hciDvDQP5FP4oKsXe3QeOnpTe8I/1I0188bSi8Ib7HU1 e5ca2aBiosRjE7VyNrDsmqZcJ4+/vKSydaMLK0XgC48YcctwTL2MSpZvhEA1Gr56J8A26HfR /DHw2sGCTGewTMfDa8ZB6oaKnK3vO8Abu3fhBU3VTK/VnM7dvIplgg/i684SS7eAbMT2dq0O FESKN2i9fKVrp84B/bHkly4CN0pVC873rMyPmzMyjKxvvDlQcUP7xBug12BTyHl7esGnTMMd CMWyLIth7Cy2eKcgfYYirS0kbcj9i8QoPdIeDbvCd9IuLSsq3cxHbMc0ncRNpIkN/nyyd6zT Csi83hzJMx3T5TGBzRdh0DhYKPxJg1hxnGfKa1zLcsymatWl2Cu7Z2x4uNRewQY0phCRmNqy Y73HwdzDTOxPuTrGnZXWRc2/ZmrPsPPV7ygzBCyl7ovWGMudhdbKO93HylDB3hpOf73VGRrO vxsPYn3JpMNZd/dIb20+fE3WeedB7TteUahk66HCB0FgVbeuoV2La+dl/pzNcO0riqrQCX0z HxhxYYMO46hGYHKwJ+THPWUTL8zNBHnAU/bHz1iQnuR4ZMYZhdbOK63Ui23McNZAVX3Vj52E lG271pytsx3MmDatzWWBRUrJ3I3Njk1eVe3XRKzYDG15/q49z9Y3sFuE1071rnvtY9y8HYzX rpJdjwD9s3wXy/RHoDBW0h89S/G8waftW8N6YUPdsoZj1gekdTeIe9g9It59IzCsKK2sqlqz ClrKsJ4cyf991KhhYAbd2Xk1VJvr3K9C0de8PzKc2zGBdJY7eoBq0TJOwf9UWbiTr7ed3rdi IfW8yUGdeIncrU0bFoh5cz5u3kD+esl8L/1dkPF95MzM1UpOzHb9ZfGN2DLt01Te0eRH4kIC yU6+qUnO5XNZJnI2OaodyMb54WUuLAxy4hmG0GqNvmxe3m5ObAkzr7gZ1zgt5XiueQK1rICa 5XWOtFMO6DRJWRtehLnswoy9/jyVpblINCzeSm03Tt5rfug/nuhXgd5CK88v8+lUvcNoYtww xeQkrOWd3okwq4LElcGq+17MfcCp/lIQ68BGOtcAzup5Qb/hQw9vZuCjDk8j2+fTUm3I3etZ WVvrHdnpmOYDbt/ZS+d9kuw3vewqCWErLNE2Lkpzfq+b/YRfvurpKyfXPsvZnhWTrOl8Xi/o vtrqXhbs7u6HXe02C9TyPhtxfgenjrcLndP6PtCzW+92vswCP/D/zukmjfBEy9MwmO6oVjT1 8fANj1Q2p+zre+zmLuYWbxXcxsWIvvGF/sSU6/EqidoaT/KS6+EAb/IKf+8n75OFczgeKnq3 HZEZ/l7KoL3jyW3w7U7tKS/zP0Lzhffrx42OjIdC8b64yqO+Qw+aRZ9gokqvSS+E7t3zYy6f U0HZqk7vUD8jUn9a/ozO7Bzr8YrtZ0mfWF7yEQz2UFmtxcXPVT9ev2zsba5ttrP0P23vb797 2yXZpMZYq4zzi36oe7/lEjPVE51XTi/Cfm9TtKTmqm7oAY+mAo34EMz2kP8USW3q4M6UfVru C58rpp3pTY/DULhtws75G9VSLrt8rcLvQf/nl7/f097xff/uoRPlgdr6u5tSQr5/Nh3xImj6 mw/zQu9eMEfg5siygC7ugiqqpm68eh36MH3n/aSnOGEojm/V1K+5RMd0/q+cyJac+6x+9J/+ QIdPo+cPqkxP+6dP7cR+/Lqej5TO4VQu3LPudRgr+nhEAPAxFSL2YTROVnvxo5nf3TVQ/DKS OqfpW5uUcZeNRNA3msVc3/ne/4FB4ZDoOZhartoSNpMVJTifFEP9WaFCbPYY3F5HCaZN1VSe QzDFGPLlvuFx+Zxe9x7ZtjG7RnZri/7SoATtjAy7gAp1FtH2HBMfNRySYtDaEDM1Nzk7PT0q G2RCKctOKEWbKsnmGitSy/BoWEZTVnNcP1kNcwe5cldThVFZTIdj126TVahgdZ+ho6WnpxJx b+x60yS5HbWtqaM2v8XiyGnC09XX2dupnxix/uvO0fVgTSAZ7sHc18bv4NBT049gQYMHEVZR 1sEZHoElAOkpV08SuB0Pef1TZA5gQo8fQYYUuQ7jEhTd7NnidxBHwywPWy6Mt3FkTZs3cebs qKiUvlqyZJ0iVg3hqCQYMdH02YfoSp1PoUaV+kZUVatXsWbVWnWqRYKokm0VO/bqHWVk0XJV 2pVtW7chgzlpcU/m25cJjTK9q1QtzJ12AQcWLA3fRHi7BgfCG6NuRKcO//JAmphyZcvi6mW2 Nvky4n6cIa7d+7hzadODweqbdZQWZLBOvJ6+uFiT34CRZefWHfVoPpSnBq7Y3QO0nOKHSCsW PZx5c7gO+fSWOJ1V/mHnII7fro2biO3r38F/tejst5mBnsPLY6kxeXfu6eHH7/STaXk/5tHL n7h++3Ll7fULUMCASDEqKFOMkc6q2AY87zP2mvrlvQYprFBCB0PzxcL82MnulQlBZGjDEUn8 TxsrPESNtky8uxDAEmGMsYTGQJErRcFuJARC4jjyT8YfgQxynhURaXG0CIVMUsklHTMoRw0l 6/FFJqms0kooH+xvSh+vudLLL8HkkKQdo9RuyyusC8sS94agMcw34XySTRZDPDNDqkBRTbMx 4ezTzz3F0xJJHf1zicc1N9uvwz8Z7VPONsmczcym+tKCtaUSdU3P3ubCp1NkOAUOKGR8/hq1 0VOXfLTJjLhcNcqz0trKsEvwU8W34G5NaTr79ELVVxlVrdPFQf+jdB+A8rgvM3gqytW6ZLkx 9NdpRwy2VSmJnZNYaSWFdrxMm92VVmX1Qonac2G01s4jD8XzWmTH/XTZSPKhV1zqeFWiV3T5 1U/dbFsRtl2A22RNVGb8KTWWYwpUbcFNSZlF4gMV7tfiAP8dmJdY0TKHY7IuDllk3ogc2eST Uc6m5GkyTtnllylrWdJ0ZIbZ5pu7qrnLcHrC2eefKdQ5DJrFBNroo3cTGjt1ekba6ad1U1pE oqWG2uqrOan6TsIYxNrrr0kuimgMwS7b7JG0roJmtc5u222Q/tJGjue36a6bv7vntlvvvcfG +x2+AQ9cl7gtIJxswRFPfNiCDC9a8cchL9NvliOv3PJ1KWf68s05n3pyrjsPXXQs3Wm88dGf /lj11Vn/OOmVQUdd9plyfl1szWfPfWm2To+0dD51D15uqXoXlHHghU8+qdqjhj2a4pV/GXqC K5te0b+jz/76sHOzHlAni9H+cu9nlo38w7PsWnzBz9/ZfOeP/359xNsfunv4PQl14op/mp/9 tuqHrfiBLl/38h/gAui5992OMMcy0L3YdsC9JZADFFxcoGLnrHpJEIEAZIwFNYbB551Eg7oC IQc3dMLCQQd9vMPffDqVmrkojC4q/kRhhWwoDli1joc99KGsGHhDIRpDgAwJn2QK4aZlHSsx 7cvhEC+2L23Zr4Vqq+DWEBazF0JxfVLEhRS+kabyyc9x6qveFrkovFCM6xoRFERcDCTD1mRx M0I5GLcSdr8gplF8j4iJ6sQww0P8poD26kO4SHcZJ/LRf4VRotrcOCP7YEpPpKrjIWf1oebt kZHRc2QZCwdGK04yJvvL1S68SEbLLLKTfTxlsTBDShIa8JSIRNQCP9dKNQpFV7CMQk8EGcMH kucWdDEhL930RIFlTpfNxNxzNplLZ07zii6MppOomU33Ec920tTmNxOZE2W+q2/gNKd6pjLO Zz7vnO1c/l46u4nNT/zwYe50mjrziEt55m+Z9jwZPrdXGlbyk5z+TBlAVXlGThpPcgYFGkLN qMWF0qmgDjUZRKuoookWqZ8WjaIHi3REaAx0Ph31aL8wCkpYao2kWTPpSdGVUnWJcXBoDFhF YWoxmRbMFkckj6lculFWrTOn56LnUZE6logUMFkMTV9JcVrUuj2xUn5QkL4eWcSnBjWUD4xo h7KDR4WEUqq/w8knIchGru4Tqpp8wWFUWs7upIZ2mCkr8mrCqRKKSmYt9Vg4NSQcnlA0n3Yd hCvgis675u2sMYTYWw1Gx7UOMGCRDGRPvSJYMESQkpt6rCSB0pfwiVazcsHs/mqGAlQa0lWs i9Xqn5yY1LQEsmm74uWeZEtbZzU1KRUxV32+RUtyxauEruXor/x6G8saMo+w2QhnVSEd6jCj mFg9JBNttR+0lsuQLomWcX3np+RSRZQUOc++YIIi3NprhdNVVnBNldhwMQtDzcoqeCGFXJsa J5OYhOuNTKIStW5jYVYVMCarQ9dXDtezzBUufvmrX6Gq7LKrtaNmydswYlYQmBHjXzEMJa3I FpMrkV2NxFIL4SFZ05t4DS8VVay3nU4YdwQlaoyhNuMW17it1MNx2XTMVspOtqE/pluQhyxC Io/RyG6DaD2VHGWn1rXJTmZeXJ8x3uPe2JdTzNMX/qu83+ecT8tD9bFGtxnmrUKltmt2M2HP zOXCDm93aVZzOzDaZrPumA5GIoQxUVzJUi2oxPSpp/7URKq4nLjA970zheFJZjFPKoSEcq8s i2uuvW5a0I8eKUj5zNgeV9pEuLLtvDbIYG/ZQ7q7bbWnP81iIUsZzqSeE3enK136otLBuMZ1 r00Na3bKOslv3nKcKWXq3wJb1cQ1YVpP/VZhZ/BUZYY0sqdwMOp+qiGH7jBq+Sovim04vh1O 8bTnOQ7ZrhsrL3bxlO2M7nu6m9rXLnatiyzv1NF72Pg2tpltre+H8jvW/t7zqPMt8KP9a3oM n7S75KxwnUL3pgcHOK1D/opUic87o11ehmEhfux7bxyceq44yOd8wRWHmuTNNHmED4tylc8V sDxu+Tlf/lpMGdOxMJfQcmd982/mnNLaXXCG2Q3lQeMlqULv4ot3zVt26QjoI4ex05Pn8OVp uuiBKC/L6Yz14KVIJuotrs59bvU6i92ixMAwYyrmMCwnvM8PlznbZ5f0dp+44QTHXsSxpveU CtHtCa33yoNO5f95HO9jveWi4A15wF8NNIPXZd8j/27FB67yjfeyze2N8atz3tKP1rrFsyF4 1TvarYnrPKxPj2eFGpxJrKd9wH8ce8nDs+Yh99LpXu9p3WteJ83wO5C+Po/kuyrMwwf9U0zu /vzae1i0/K36oF/T7ZOkMvfqXn1ua7f80Ne+lmQDv6bMC+0Adxy/lm9O9I+fruiqobXP7XaF XQ1c2NsN/pkP0rLnbgTEr8Hmy/BizP2GI7HYj/GSBAB1j1dmaQFfARiGCAG7qSXiL12+LdwC UDS0D7Ja46fsD1aIiOKe7sgoTvr4Jokk6ah0S/0q0FcWreskML8UhwWtaLO86+gOyAKVjOze 6eJITyH+IL16K9UkyAe3Cgh7b+ZWsPQuxJYaqUoQDVTWyJLeQwUnCAp/AcSwcH6UUCOYasBs TQtljAubj0qqapi8wfbCrgaZj1HE7dgcrS7CsG3usNbGcOq+yglh/gsO/2IRjG//pu/A9or7 4q0Do+r3ANGIAiuRBlH4qNCxLiW1aojxzPBLrhARX+X+loi6rBADCfFHMO/xxu9N/OiDXJDv +ss8mioPzQYW0Y6ZUq7uGsWRPKTw4IuJ0MoAVUwWaVDUAsoW5XBWwmr5fCuTfBHCgNH3iC8T r4TrTg7aqLEPmfH/MA4aoxGZvnBSeG5hkImm0hBYTJAWh3EaF+/zqqwZLa14IlHk0tEGTQ/5 FBEerRENO4gBu48U61EIG3HyrCb45pEfoecd/fEJ9RHH2JHqjE0b30bwhG0h8VEYl3EiPS90 JDIh+60W0fEiRycj1ZEi71EjPbJyQBLN/jgy7UpSdE6SCL8PkJhsJENyJcdHQFiK7voR92gy clryDRFOgc5RJXdyc3qyvTZy9P4R24ZyCP3FHNcuKGdxKemnHJ3jJmMyKXWyz15S6aQyPhQQ PKxy87ASJw+SD7syPYju/ZwSKCuSJIXSGc8SLXOSdwbQxhLRIaNyJuOyKucy/DzxKJ+yLfUS 8d5yL68jLT/i/BAmLO8yA/3QIg1TLdnMLP7yBrYAKcIoCE9R5HIxMuUDn4zQFAFrMjKzCc3S HuHSM/lyMoPxvUyzmsSyL2OzLBULOYpSNe2CCVVxtRzGDe8Oi2RSHtdqhuBoKQqP+rzttHBz gA6jOTPlvZwT/j+iEzqDUylnM+rI8CJ8SDMJc0cwDQbProG2koeWE+yu0hWR0DqBkxhHbQ9K y8HAJT2zrDyrBe2w070A8jXdUoDyQNfgEz0frOBE0qNy6FF0E1GkUT1zEDU5M9OY7T450TFp kz7XUi97DkFIEzJb89rK4kKNc9xo4VKwb0Dn8zaN7EDncz9VNDUf8/k+zUT3kUWXLD9nczNP c/coB0anpUBt9KXyMhELc0IHU664RkcP8EeFFEiRdEkXUUBjx0ivcUP9r0allD2DlPjSbSwp tCPnajw5RkNltEdX1ElHqP7ayVp80yepBS+9MYkawdqydCmh9MoYFOAEMTD/rabQ/o0c5MRM f4kep5SnHq8u5w5O7fIAa6EsPOsYRoXssCsMqNImJbQTg0G77CgUYTPxyPSkzO4JEIyveND+ woI8Gc1CGM5LSay2kjFA26DpWiFSfxK8lisvAJSGPObVlgZWm9KFqo4NlW09ldQGCWdOQ0YU XbPZ8DPDkEg/JTNnkLFeetEoFXQ2DIdYo4gJrkvAwBOagmb2yo9VmfU3GZJIOfWXgENEh2Eo KtFPkfIurFU0c5PRgincFExc8fTnXHRLc5RAUHW2xlScxDRTOaJa9VX2OvPwaDQxAxZYb1RP C1ZzDhYwmxRgu/M8GzZOi4pHKy6sKnRab8JAfdRiHfZh/v+OYxHWY20CZCeWe0iWZXSVLCdV WnFkYRdUAJPOC16yZSt2SOsUZomNSVuvXbOSYUP2BFOWZn329pKW96x0aWtzZcNVaHWWZ4c2 SaX2Z6uUaGW2aFOSawmvNycm+8KWktL0ZOMwVlE2r5B2a9kSauFVOM+U09wzOzX1bGc0bdFm bYP2XvFWMIMVijrVujgNslqUap1Wtbq2Zr1WJFQW8ASyag/38lKNlGRzZC/2bbX0cQOjcdNW c0XWbQHXGwyxGsu2Y+3W6J529NiVO+N1Z//WXg0Sc/nW/AQW57gtHMUWYr5SYbO20M713Gin qqiUTq+0bWs3XelV27T0vIQJ/hxFlHUZSVUi9lW/LwcTFFJthFSbSG/tVWb54BJ+DUm+F18O 511vZk6L8EFXQng/k3tTd2sqFTKsqro8EMN4UazMF2ZKd2ZtM1TxdHWvqXhrt239k3xll4A/ tVagd2pZDkIzV/5c92q7cbvgs9WMZHyzNT/yF1jOqoPH6gMRU00lNYJnFx16dQbnVbIqFwlG 69viLnEZOE8D1Sv7FWc7hhX/dYEXN4YxNkUtRxeXF4a1NmF5OGbDNFW+glAhl20NF4U09mjN lvy4FW7J6oCJuIiVdobpkYI890OuL4d78Dmnc4zFuIyl8zkbq19vGExCGEuRCCbR74ixmEAr 14gt/qmNTbgy69ANNrjawJSDY6qOtfhp3/RZB9iK2+6PY6SPNxZutiUQIVGE6ThDGRlSjao6 NzJ3FW2YSmEGgdLQnrf+NliNSZndlMs9KjlXjeplbW4Pt08+QW5VpQ6TTQN9TxlSUllEcjlr cTQ6fO20LvWT5Ve+0GeU4aMzKdlK8DhMLIiChQtbZ9l7oVUZo/Y0bNlFSoKWMUabpdiR028M FSRC18uApJCbFemYIS6bgxgszVlJmpnv5OiY3K7QVFhuvvGzGLWaaxncSrmf11iQR7UkWDmF BpqNGVeRJfmKN9dv3eLtENp4GxClDhqMEXmJr+kkHZqiu5cf+eWdNRoq/kH3nNuZNddZhz+X owN5ik8Xold6NUv6Yxm6hE8akFPam5t4bz96lWJa1lB0h3e1pnn3pje6b70VC27rhdN1ol+6 omUapcM4p0cap+VSfX4XbFFtins6pEc4CR9aqql4qsvXDIh5qeEsqxU6PHbZpb/6dS1aj8xP kKQt2EAoo4VacZGYg7qYrSP3ouXBU3cxb6N6qCWYpntQ72x49QaErsH3WHcXb8yaqH9aBusV 1KZKlfzrr5UaoJmapbFxTckaR93YVC27BOu1sdnqsds6hS5Zs2VPhnFotOnop5Iaq4F2iAkb tu6TssckrW8Jo3f6kCG7fW8REtyvIFnbmn+b/mmPu4EEDX97bgdjRqQimiIQ0Lh5O598O7Ah L37VQ7ElSru/45OK+0GuW1Gy+7Mzh7stFVRMmpuSW7jLGfr2rLzB4byXW7m0rTjj2sDIlrl8 V3mZTjkrSQQ7jRwXsxvlu7XvW6TRm7YDHDwLqTd75qrotrVducEREqwAWLiriI/F0VKwpX5o NYv2sAs6OT5BMTEdaJjbkL7dWsGd+gvSl4TXQsSDKxnnK7/Za65bcVvxWvRUO6JCWIlBerPr ysYb7ZUo3LmqY8fFmWdmCQIx/Axdu1uF/D5CeV2fV3cZ5rMWvMmpVcH0B9H0u1W9KoVnVaSa 87mP2iOSuhItrJ5d/qnKG8S7obOQHLDAklVb+FRu9Tya55gkCvpu69OMDu3GwfdRc9tWvfFQ TGLJowvQA71vqnWyIbiYzZjZeA3VEvjL7XyQnG182WvSjwf4ppzBOaQXvxOYAHTRj6TPo43V 8SXKSX09TP3LUb0ZCoTckJdeyy1BEnXDqSiMbncxb5eYvKrWyfsdXJ1EPn17wXutlX1urBJb AfXUiWRYp13tvBPBgxzbgyhuhH3b7XhxInCR35tlXZyH0+Z6RTvaoRjcyX0SD7zAvx3Xs33e VdO7FRXfMXbdyX1/izWh+oeyAT7gvcbOn92D5V3fKVawbUbhX7C56XlRLT2THd6aR4vL/uO5 4VGR4MuBkMIzgw7+LPE8vgfO0EOexXMN0sup5LvSmREMXI1G4h/0Cn2cFmFeKmX+jPd84UD+ z2vFgf3dfXZeTge32TmufB/mnmdbwjVZ5zO+lltYjnhd4HUq3RU4qIt+6hVS64+V64/e61M+ iMf95cne5MG++NY+7SOy7Rm+691eVvnZn+1eK+B+7u/smvVepx0xFtG57zkcbPhe8MGa8APf 8HNT3AjNp+Q3IO8+8ldH8Vv3wn+e8jF/WdWXxL098z1fO7Fq8zv/80kf1F0zwks/9Tnstt78 dz1U9WF/ZsY+9l3LtGn/9gtm9nF/93m/933/94E/+IV/+Im/HfiN//iRP/mVf/mZv/md//mh P/qlf/qpv/rdqQAAADs= --------------0D3893F258350D56FA944C81-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02228 for ; Mon, 24 Jul 2000 23:33:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:33:15 +0200 (MEST) Received: (qmail 30471 invoked by uid 0); 24 Jul 2000 07:21:51 -0000 Received: from hm.egroups.com (208.50.99.198) by mx02.gmx.net with SMTP; 24 Jul 2000 07:21:51 -0000 X-eGroups-Return: sentto-1101623-535-964423306-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 24 Jul 2000 07:21:47 -0000 Received: (qmail 8223 invoked from network); 24 Jul 2000 07:21:45 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 Jul 2000 07:21:45 -0000 Received: from unknown (HELO legolas.mdh.se) (130.243.77.20) by mta1 with SMTP; 24 Jul 2000 07:21:45 -0000 Received: by legolas.mdh.se (8.9.3/8.9.3) id JAA25132; Mon, 24 Jul 2000 09:21:43 +0200 (MET DST) X-Sender: elt95rhi@legolas.mdh.se To: f-cpu@egroups.com In-Reply-To: <002c01bfe670$f173ffa0$c90110ac@AOP2> Message-ID: From: Raimo Haukilahti MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 24 Jul 2000 09:21:43 +0200 (MET DST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ecf441dce92483cc4e00b29e20b2b889 Status: R X-Status: N UNSUBSCRIBE
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02234 for ; Mon, 24 Jul 2000 23:33:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 24 Jul 2000 23:33:17 +0200 (MEST) Received: (qmail 16382 invoked by uid 0); 24 Jul 2000 08:36:58 -0000 Received: from ef.egroups.com (207.138.41.172) by mx0.gmx.net with SMTP; 24 Jul 2000 08:36:58 -0000 X-eGroups-Return: sentto-1101623-536-964427806-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 24 Jul 2000 08:36:47 -0000 Received: (qmail 11643 invoked from network); 24 Jul 2000 08:36:45 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 24 Jul 2000 08:36:45 -0000 Received: from unknown (HELO jester.ti.com) (192.94.94.1) by mta1 with SMTP; 24 Jul 2000 08:36:45 -0000 Received: from dlep7.itg.ti.com ([157.170.134.103]) by jester.ti.com (8.10.1/8.10.1) with ESMTP id e6O8ZiX09928 for ; Mon, 24 Jul 2000 03:35:44 -0500 (CDT) Received: from dlep7.itg.ti.com (localhost [127.0.0.1]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id DAA19973 for ; Mon, 24 Jul 2000 03:36:36 -0500 (CDT) Received: from mailsvr.india.ti.com (mailsvr.india.ti.com [157.87.101.6]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id DAA19926 for ; Mon, 24 Jul 2000 03:36:33 -0500 (CDT) Received: from akash.india.ti.com (akash.india.ti.com [157.87.99.107]) by mailsvr.india.ti.com (8.8.8/8.8.8) with ESMTP id NAA08916; Mon, 24 Jul 2000 13:27:20 +0530 (IST) Received: from india.ti.com (localhost [127.0.0.1]) by akash.india.ti.com (8.6.12/8.6.10) with ESMTP id NAA03563; Mon, 24 Jul 2000 13:27:08 +0530 Sender: a0756645@india.ti.com Message-ID: <397BF6D3.FC422B7E@india.ti.com> X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: From: "S. N. Karanth" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 24 Jul 2000 13:27:08 +0530 Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6f3575e5c43645cdb1c163c30107c8ef Status: R X-Status: N UNSUBSCRIBE

--
Have a good day.

Regards
Karanth
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00318 for ; Tue, 25 Jul 2000 23:43:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 25 Jul 2000 23:43:44 +0200 (MEST) Received: (qmail 10002 invoked by uid 0); 24 Jul 2000 21:55:00 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 24 Jul 2000 21:55:00 -0000 X-eGroups-Return: sentto-1101623-537-964475692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 24 Jul 2000 21:54:53 -0000 Received: (qmail 1170 invoked from network); 24 Jul 2000 21:54:51 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 24 Jul 2000 21:54:51 -0000 Received: from unknown (HELO ns.empi.net) (194.206.141.141) by mta1 with SMTP; 24 Jul 2000 21:54:50 -0000 Received: from anatole.empi.net (anatole.empi.net [155.132.171.52]) by ns.empi.net (8.8.8/8.8.8/DG,ns13.mc, V13, 5/jan/2000) with SMTP id XAA06472 for ; Mon, 24 Jul 2000 23:51:15 +0200 (CEST) (envelope-from daniel.germain@empi.net) To: Message-ID: <01bff5bb$8eaf3600$34ab849b@anatole.empi.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 From: "Daniel GERMAIN" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 25 Jul 2000 00:07:29 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu]UNSUBSCRIBE Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01BFF5CC.52380600" X-UIDL: 1da7249d43d33dd5348731baceeac494 Status: R X-Status: N ------=_NextPart_000_000E_01BFF5CC.52380600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable UNSUBSCRIBE ------=_NextPart_000_000E_01BFF5CC.52380600 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
UNSUBSCRIBE
------=_NextPart_000_000E_01BFF5CC.52380600-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00323 for ; Tue, 25 Jul 2000 23:43:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 25 Jul 2000 23:43:47 +0200 (MEST) Received: (qmail 1911 invoked by uid 0); 25 Jul 2000 00:34:19 -0000 Received: from fl.egroups.com (208.50.144.74) by mx02.gmx.net with SMTP; 25 Jul 2000 00:34:19 -0000 X-eGroups-Return: sentto-1101623-538-964485252-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 25 Jul 2000 00:34:17 -0000 Received: (qmail 21163 invoked from network); 25 Jul 2000 00:34:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 25 Jul 2000 00:34:12 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 25 Jul 2000 00:34:11 -0000 Received: from f-cpu.org (nas2-212.ras.club-internet.fr [195.36.192.212]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA02332 for ; Tue, 25 Jul 2000 02:34:10 +0200 (MET DST) Message-ID: <397CE063.DB3ABDDE@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 25 Jul 2000 02:33:39 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] clocks [Fwd: RE: Asynchronous Designs (Was: Re: CMOS&Power Issues at 1GHZ)] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 01fe2c1a03378f3708a54ce796092729 Status: R X-Status: N i just got this.
it looks interesting anyway, but let's stay far from the
implementation...


From: "Glew, Andy" <andy.glew@intel.com>
To: "'whygee@f-cpu.org'" <whygee@f-cpu.org>

You've understood pipeline ordered clocking.
It's pretty simple.
You just have to make sure that you never connect
two units that are far apart in the clock
tree, without accounting for skew.

Unfortunately, existing tool chains can't do that.
Yet, I hope.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00385 for ; Tue, 25 Jul 2000 23:44:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 25 Jul 2000 23:44:24 +0200 (MEST) Received: (qmail 20628 invoked by uid 0); 25 Jul 2000 07:58:57 -0000 Received: from hp.egroups.com (208.50.99.201) by mx02.gmx.net with SMTP; 25 Jul 2000 07:58:57 -0000 X-eGroups-Return: sentto-1101623-539-964511804-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 25 Jul 2000 07:56:48 -0000 Received: (qmail 21053 invoked from network); 25 Jul 2000 07:56:44 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 25 Jul 2000 07:56:44 -0000 Received: from unknown (HELO mercury.Sun.COM) (192.9.25.1) by mta1 with SMTP; 25 Jul 2000 07:56:44 -0000 Received: from dunaserv.Hungary.Sun.COM ([129.159.190.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA02933 for ; Tue, 25 Jul 2000 00:56:41 -0700 (PDT) Received: from wyvern (wyvern [129.159.190.122]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA16761 for ; Tue, 25 Jul 2000 09:56:38 +0200 (MET DST) Message-Id: <200007250756.JAA16761@dunaserv.Hungary.Sun.COM> To: f-cpu@egroups.com Content-MD5: YGJ4nqYysjdcfJxfXFvLWQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_16 SunOS 5.9 sun4u sparc From: Erik Fischer - Systems Engineer Sun Hungary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 25 Jul 2000 09:56:30 +0200 (MEST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6d94f7561ececebdd72b4c41c155ca29 Status: R X-Status: N UNSUBSCRIBE
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01277 for ; Wed, 26 Jul 2000 22:22:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 26 Jul 2000 22:22:02 +0200 (MEST) Received: (qmail 16259 invoked by uid 0); 26 Jul 2000 10:39:42 -0000 Received: from fj.egroups.com (208.50.99.207) by mx19.rz2.gmx.net with SMTP; 26 Jul 2000 10:39:42 -0000 X-eGroups-Return: sentto-1101623-540-964607979-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 26 Jul 2000 10:39:40 -0000 Received: (qmail 32667 invoked from network); 26 Jul 2000 10:39:38 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 26 Jul 2000 10:39:38 -0000 Received: from unknown (HELO hotmail.com) (216.33.237.86) by mta1 with SMTP; 26 Jul 2000 10:39:38 -0000 Received: (qmail 82650 invoked by uid 0); 26 Jul 2000 10:39:38 -0000 Message-ID: <20000726103938.82649.qmail@hotmail.com> Received: from 193.153.198.2 by www.hotmail.com with HTTP; Wed, 26 Jul 2000 03:39:38 PDT X-Originating-IP: [193.153.198.2] To: f-cpu@egroups.com From: "CONDE CERO" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 26 Jul 2000 03:39:38 PDT Reply-To: f-cpu@egroups.com Subject: [f-cpu] UNSUSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 03abcbae838cd719ad902a2af0e7223c Status: R X-Status: N unsuscribe !!!!
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01286 for ; Wed, 26 Jul 2000 22:22:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 26 Jul 2000 22:22:27 +0200 (MEST) Received: (qmail 8539 invoked by uid 0); 26 Jul 2000 13:03:39 -0000 Received: from mw.egroups.com (207.138.41.167) by mx19.rz2.gmx.net with SMTP; 26 Jul 2000 13:03:39 -0000 X-eGroups-Return: sentto-1101623-541-964616614-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 26 Jul 2000 13:03:37 -0000 Received: (qmail 20388 invoked from network); 26 Jul 2000 13:03:33 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 26 Jul 2000 13:03:33 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 26 Jul 2000 13:03:33 -0000 Received: from f-cpu.org (nas4-102.ras.club-internet.fr [195.36.203.102]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA06449 for ; Wed, 26 Jul 2000 15:03:30 +0200 (MET DST) Message-ID: <397EE184.FDEBFF76@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000726103938.82649.qmail@hotmail.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 26 Jul 2000 15:03:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] UNSUSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ca1dcac0d9ad9919c351e0b6b4a61ec6 Status: R X-Status: N It seems like people subscribe without reading the
notice, particularly about unsubscribing.

in the header of EVERY message there is this line :
List-Unsubscribe: <mailto:f-cpu-unsubscribe@egroups.com>

CONDE CERO wrote:
>
> unsuscribe !!!!

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00520 for ; Sun, 30 Jul 2000 20:47:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 30 Jul 2000 20:47:48 +0200 (MEST) Received: (qmail 3279 invoked by uid 0); 30 Jul 2000 03:38:56 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 30 Jul 2000 03:38:56 -0000 X-eGroups-Return: sentto-1101623-542-964928333-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ml.egroups.com with NNFMP; 30 Jul 2000 03:38:55 -0000 Received: (qmail 8996 invoked from network); 30 Jul 2000 03:38:52 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 30 Jul 2000 03:38:52 -0000 Received: from unknown (HELO mail5.primary.net) (216.87.38.199) by mta1 with SMTP; 30 Jul 2000 03:38:51 -0000 Received: from [192.168.1.40] (ip142-htc1.busprod.com [207.150.74.142]) by mail5.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e6U3Y0F13915 for ; Sat, 29 Jul 2000 22:34:01 -0500 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 29 Jul 2000 22:39:05 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] yet another GPL'd CPU. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af79c078ae2ef8223480d130877f32f4 Status: R X-Status: N
yet another GPL'd CPU.

>Date: Sun, 11 Jun 2000 19:32:16 -0700
>From: Steve Wilson <stevew@home.com>
>To: geda-dev@geda.seul.org
>Subject: gEDA: New release of Icarus Verilog test suite.
...
>This is to announce the latest release of the Icarus verilog test suite.
...
>One interesting addition to the suite is PIC.V by Tom Coonan.  This is a pic
>processor implementation
>that can be synthesized!  Tom GPL'd the design for inclusion in the test
>suite.  Thank you Tom!!!
>This is a non-trivial design that IV runs just fine.
>
>Please fine the latest release at:
>
>ftp://icarus.com/pub/eda/verilog/tests/ivl_tests-20000611.tgz
>
>Enjoy
>
>Steve Wilson (aka the OTHER SteveW.)

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA02600 for ; Wed, 2 Aug 2000 15:53:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 02 Aug 2000 15:53:00 +0200 (MEST) Received: (qmail 19882 invoked by uid 0); 2 Aug 2000 13:19:09 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 2 Aug 2000 13:19:09 -0000 X-eGroups-Return: sentto-1101623-543-965222151-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 02 Aug 2000 13:19:06 -0000 Received: (qmail 30578 invoked from network); 2 Aug 2000 13:15:51 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 2 Aug 2000 13:15:51 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 2 Aug 2000 13:15:50 -0000 Received: (qmail 23452 invoked from network); 2 Aug 2000 13:15:33 -0000 Received: from unknown (HELO pandora.be) ([212.123.14.131]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 2 Aug 2000 13:15:33 -0000 Sender: root@pop.gmx.net Message-ID: <39881ED3.A1C4FE13@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 15:14:59 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6a6f7edc65ed03e72bb3185bc5849e5b Status: R X-Status: N Dear Sir,

What is the current status of th F-CPU project ?
Are there already some FPGA prototypes ?
Hoping to receive some positive reaction, I meanwhile remain,

Prof. ind. ing. P. Pelgrims
Hogeschool voor Wetenschap en Kunst
Campus NARAFI
V. ROusseaulaan 75
B-1190 Brussels
Belgium
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00843 for ; Thu, 3 Aug 2000 10:06:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:09 +0200 (MEST) Received: (qmail 20428 invoked by uid 0); 2 Aug 2000 14:33:05 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 2 Aug 2000 14:33:05 -0000 X-eGroups-Return: sentto-1101623-544-965226762-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 02 Aug 2000 14:33:01 -0000 Received: (qmail 31817 invoked from network); 2 Aug 2000 14:30:40 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 2 Aug 2000 14:30:40 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 2 Aug 2000 14:30:40 -0000 Received: (qmail 13765 invoked from network); 2 Aug 2000 14:30:37 -0000 Received: from unknown (HELO pandora.be) ([212.123.14.131]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 2 Aug 2000 14:30:37 -0000 Sender: root@pop.gmx.net Message-ID: <39883066.47013BDB@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 16:29:58 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] "Educational" prices for MPW projects ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4d7edb1823f7051e0edbf6315d0ca30f Status: R X-Status: N     Dears,

Here you can find some "educational" prices for the processing of= the
F-CPU :-)
These prices are only valid if there is an educational aspect on the
project !!
Why not working together with a few educational institutes on F-CPU?

The processing is done in Belgium :-) by Mietec !

They can offer the following Digital Technology Processes (Prices in
Euro/mm)

Cat 1       Cat 2
Alcatel Microelectronics 0.7 =B5m CMOS C07M-D     = 155 (2)  240 (2)
Alcatel Microelectronics 0.5 =B5m CMOS C05M-D     = 215 (1) 360 (1)
Alcatel Microelectronics 0.35 =B5m C035M-D     &nb= sp;         305 (1) 560 (1)
etc ....
            &nb= sp;         (1) : min. fabrication = cost is the cost for 10
sqmm
            &nb= sp;         (2) : min. fabrication = cost is the cost for 5 sqmm

How many sqmm will the F-CPU be ?

Cat. 1 : EC-subsidised educational price applies to all EUROPRACTICE
registered Academic Members from all EU countries and Norway, Iceland,
Liechtenstein, Israel, Cyprus, Bulgaria, Czech Republic, Estonia,
Hungary, Latvia,  Lithuania, Poland, Romania, Slovakia and Slovenia wh= o
submit designs for educational use only.
Cat. 2 : Standard price that applies for all circuits not belonging to
Cat.1

In addition IMEC offers a low cost, flexible and coordinated packaging
service using industrial
qualified packaging houses. A wide variety of packages are available
ranging from DILs to PGAs. Customers can have the standard unpackaged,
untested prototypes packaged in the package  they want at low cost. Ju= st
indicate at design submission/registration the type of package and
the number of chips you want to have packaged.

The price structuce of the packages :

Unit price is valid for all packages (see table below)
Minimum cost : cost of 10 packages

            &nb= sp;            =             &nb= sp;            =         UNIT PRICES
            &nb= sp;            =             &nb= sp;           Type EUR&nb= sp; Type EUR
            &nb= sp;            =             &nb= sp;           DIL 16 15 J= LCC 44 34
            &nb= sp;            =             &nb= sp;           DIL 18 16 J= LCC 68 45
            &nb= sp;            =             &nb= sp;           DIL 24 20 J= LCC 84 51
            &nb= sp;            =             &nb= sp;           DIL 28 22&n= bsp; PGA 84 44
            &nb= sp;            =             &nb= sp;           DIL 40 27&n= bsp; PGA 100 51
            &nb= sp;            =             &nb= sp;           DIL 48 31&n= bsp; PGA 120 59
            &nb= sp;            =             &nb= sp;        SOIC 16 36  PGA 144 71             &nb= sp;            =             &nb= sp;       CSOIC 20 39 PGA 208 99
            &nb= sp;            =             &nb= sp;         CSOIC 24 45 PGA 256 129=
            &nb= sp;            =             &nb= sp;         CSOIC 28 47 CQFP 64 45<= BR>             &nb= sp;            =             &nb= sp;          CLCC 44 25 CQFP 1= 20 60
            &nb= sp;            =             &nb= sp;          CLCC 68 35 CQFP 1= 60 75
            &nb= sp;            =             &nb= sp;          CLCC 84 41 CQFP 2= 08 95

Price is per unit and includes Package and Lid, Sealing or Taping, Die
attach and bonding.
When you want to order a package which is not in the list, you have to
take following into
account :
            &nb= sp;            =          An extra charge of 250 EUR= O will be
charged
            &nb= sp;            =          Delivery date extends with= 4-5 weeks.

Maybe we  (Dept Electronics) can also do some XILINX prototyping for FREE since we have ALL the Xilinx tools in home :-)



ind. ing Patrick Pelgrims
Hogeschool voor Wetenschap en Kunst
Campus NARAFI
V. Rousseaulaan 75
B-1190 Brussels
Belgium
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00879 for ; Thu, 3 Aug 2000 10:06:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:19 +0200 (MEST) Received: (qmail 22262 invoked by uid 0); 2 Aug 2000 16:12:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 2 Aug 2000 16:12:40 -0000 X-eGroups-Return: sentto-1101623-545-965232737-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 02 Aug 2000 16:12:39 -0000 Received: (qmail 11129 invoked from network); 2 Aug 2000 16:12:16 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 2 Aug 2000 16:12:16 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 2 Aug 2000 16:12:15 -0000 Received: from ici.net (downix@dialup-209.245.96.229.Manchester1.Level3.net [209.245.96.229]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id MAA24506 for ; Wed, 2 Aug 2000 12:11:58 -0400 (EDT) Sender: downix@ici.net Message-ID: <39884856.DBCEA916@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14-storm i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 12:12:06 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c4920552d8ac79f7e398c06247156eb3 Status: R X-Status: N pelgrims p wrote:

> Dear Sir,
>
> What is the current status of th F-CPU project ?
> Are there already some FPGA prototypes ?
> Hoping to receive some positive reaction, I meanwhile remain,

Well, while most of the list has been messing around discussing a wide
variety of topics, I've been working on a VHDL model of the F-CPU, which
should be completed by the end of the month.  Once that's done, I will
be putting it into an FPGA for demonstration.


>
>
> Prof. ind. ing. P. Pelgrims
> Hogeschool voor Wetenschap en Kunst
> Campus NARAFI
> V. ROusseaulaan 75
> B-1190 Brussels
> Belgium
>
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00882 for ; Thu, 3 Aug 2000 10:06:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:20 +0200 (MEST) Received: (qmail 32718 invoked by uid 0); 2 Aug 2000 17:56:11 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 2 Aug 2000 17:56:11 -0000 X-eGroups-Return: sentto-1101623-546-965238966-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 02 Aug 2000 17:56:07 -0000 Received: (qmail 28210 invoked from network); 2 Aug 2000 17:56:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 2 Aug 2000 17:56:05 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 2 Aug 2000 17:56:05 -0000 Received: (qmail 330 invoked from network); 2 Aug 2000 17:56:04 -0000 Received: from unknown (HELO pandora.be) ([212.123.14.131]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 2 Aug 2000 17:56:04 -0000 Sender: root@pop.gmx.net Message-ID: <3988608C.74164E29@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 19:55:24 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1629dad9dc6400058265ba531c2b0344 Status: R X-Status: N Nathaniel Downes wrote:

> pelgrims p wrote:
>
> > Dear Sir,
> >
> > What is the current status of th F-CPU project ?
> > Are there already some FPGA prototypes ?
> > Hoping to receive some positive reaction, I meanwhile remain,
>
> Well, while most of the list has been messing around discussing a wide
> variety of topics, I've been working on a VHDL model of the F-CPU, which
> should be completed by the end of the month.  Once that's done, I will
> be putting it into an FPGA for demonstration.
>
> > Prof. ind. ing. P. Pelgrims
> > Hogeschool voor Wetenschap en Kunst
> > Campus NARAFI
> > V. ROusseaulaan 75
> > B-1190 Brussels
> > Belgium
> ------------------------------------------------------------------<e|-
> Get a NextCard Visa, in 30 seconds!
> 1. Fill in the brief application
> 2. Receive approval decision within 30 seconds
> 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
> http://click.egroups.com/1/6631/1/_/3462/_/965232737/
> --------------------------------------------------------------------|e

Is the model available ?
So we can look to it, and corntibute to the project :-).
P. Pelgrims
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00912 for ; Thu, 3 Aug 2000 10:06:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:27 +0200 (MEST) Received: (qmail 18729 invoked by uid 0); 3 Aug 2000 01:03:47 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 3 Aug 2000 01:03:47 -0000 X-eGroups-Return: sentto-1101623-547-965264610-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 03 Aug 2000 01:03:43 -0000 Received: (qmail 2404 invoked from network); 3 Aug 2000 01:03:30 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Aug 2000 01:03:30 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 3 Aug 2000 01:03:29 -0000 Received: from f-cpu.org (nas4-183.aub.club-internet.fr [195.36.145.183]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA08014 for ; Thu, 3 Aug 2000 03:03:25 +0200 (MET DST) Message-ID: <3988C4C3.7FA0CBF1@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39883066.47013BDB@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 03:02:59 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] "Educational" prices for MPW projects ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bbec939d3ce124088a098db34e8e245f Status: R X-Status: N hi,

for the technologies, read the roadmap at
http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
your comments are welcome.


the first "hard proto" will probably have around 144 pins in cheap plastic
PGA or PLCC package. cheap interface to asynchronous SRAM to ease the debugging.
no need of a ultradeep submicron technology, approx 500K to 1M transistors
with some KBytes of cache memory, just for proving that it works.
no surface estimate available now : the Alliance gods are not (yet) with
us, we have to praise them to come down here help us :-)
plus, it depends a lot on the chosen technology : the wire thickness
and the number of metal layers...

As for the proto development with FPGA, some previous attempts (JD?)
showed that the macroblocks and all those stuffs don't ease the development
and the fitting. a CPU needs very fine granularity and much parallelism
so the target chip must be correctly chosen... otherwise you'll need 10 million
equiv. gates for a dumb stuff that the synthethiser didn't get right.

We'll be happy to work with you (who wouldn't be ? :-)) and i hope that
we will cooperate. maybe we'll finally have a proto before next july ? :-)


OH btw, i met just Nicolas Boulay in Paris and discussed about the control logic of
the FC0. he lent me a book to read while he's in Canada and i'll learn some
VHDL serious backgrounds (i only practiced with 22V10s :-D). Damn, Nico is a good
semiconductor engineer :-)


pelgrims p wrote:
<snip EUROPRACTICE>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00915 for ; Thu, 3 Aug 2000 10:06:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:28 +0200 (MEST) Received: (qmail 1851 invoked by uid 0); 3 Aug 2000 01:03:51 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 3 Aug 2000 01:03:51 -0000 X-eGroups-Return: sentto-1101623-548-965264610-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 03 Aug 2000 01:03:45 -0000 Received: (qmail 2397 invoked from network); 3 Aug 2000 01:03:30 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Aug 2000 01:03:30 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 3 Aug 2000 01:03:29 -0000 Received: from f-cpu.org (nas4-183.aub.club-internet.fr [195.36.145.183]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA23589 for ; Thu, 3 Aug 2000 03:03:26 +0200 (MET DST) Message-ID: <3988C4C8.573FD5E6@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 03:03:04 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 272239cf7ee3c0b10e9c045c009410b5 Status: R X-Status: N hi !

Nathaniel Downes wrote:
> Well, while most of the list has been messing around discussing a wide
> variety of topics, I've been working on a VHDL model of the F-CPU, which
> should be completed by the end of the month.  Once that's done, I will
> be putting it into an FPGA for demonstration.
hey, i hope to see it work one day :-)

if you do this wonder before december, i guess that you'll be invited
in Europe to demonstrate it :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00927 for ; Thu, 3 Aug 2000 10:06:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:30 +0200 (MEST) Received: (qmail 1701 invoked by uid 0); 3 Aug 2000 03:01:14 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 3 Aug 2000 03:01:14 -0000 X-eGroups-Return: sentto-1101623-549-965271662-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 03 Aug 2000 03:01:11 -0000 Received: (qmail 19041 invoked from network); 3 Aug 2000 03:01:01 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Aug 2000 03:01:01 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 3 Aug 2000 03:01:01 -0000 Received: from ici.net (downix@dialup-209.245.103.149.Manchester1.Level3.net [209.245.103.149]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id XAA16131 for ; Wed, 2 Aug 2000 23:00:59 -0400 (EDT) Sender: downix@ici.net Message-ID: <3988E07E.B4C9967@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14-storm i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> <3988608C.74164E29@pandora.be> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 23:01:18 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 72e1261133a8281362c974c0224ab166 Status: R X-Status: N pelgrims p wrote:

> Nathaniel Downes wrote:
>
> > pelgrims p wrote:
> >
> > > Dear Sir,
> > >
> > > What is the current status of th F-CPU project ?
> > > Are there already some FPGA prototypes ?
> > > Hoping to receive some positive reaction, I meanwhile remain,
> >
> > Well, while most of the list has been messing around discussing a
> wide
> > variety of topics, I've been working on a VHDL model of the F-CPU,
> which
> > should be completed by the end of the month.  Once that's done, I
> will
> > be putting it into an FPGA for demonstration.
> >
> > > Prof. ind. ing. P. Pelgrims
> > > Hogeschool voor Wetenschap en Kunst
> > > Campus NARAFI
> > > V. ROusseaulaan 75
> > > B-1190 Brussels
> > > Belgium
> >
> ------------------------------------------------------------------<e|-
>
> > Get a NextCard Visa, in 30 seconds!
> > 1. Fill in the brief application
> > 2. Receive approval decision within 30 seconds
> > 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
> > http://click.egroups.com/1/6631/1/_/3462/_/965232737/
> >
> --------------------------------------------------------------------|e
>
> Is the model available ?
> So we can look to it, and corntibute to the project :-).
> P. Pelgrims
>
>

Not yet, I'm a perfectionist, and I want to get rid of the errors I'm
getting in simulation.  (Also, we never figured out the licensing for
F-CPU last I knew)
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00930 for ; Thu, 3 Aug 2000 10:06:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:31 +0200 (MEST) Received: (qmail 8194 invoked by uid 0); 3 Aug 2000 03:04:02 -0000 Received: from mw.egroups.com (207.138.41.167) by mx0.gmx.net with SMTP; 3 Aug 2000 03:04:02 -0000 X-eGroups-Return: sentto-1101623-550-965271805-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 03 Aug 2000 03:04:00 -0000 Received: (qmail 26635 invoked from network); 3 Aug 2000 03:02:33 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 3 Aug 2000 03:02:33 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 3 Aug 2000 03:02:33 -0000 Received: from ici.net (downix@dialup-209.245.103.149.Manchester1.Level3.net [209.245.103.149]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id XAA16189 for ; Wed, 2 Aug 2000 23:02:28 -0400 (EDT) Sender: downix@ici.net Message-ID: <3988E0D7.3D7F7847@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14-storm i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> <3988C4C8.573FD5E6@f-cpu.org> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Aug 2000 23:02:47 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c43509885e4fb9a051fc7b1b108816b9 Status: R X-Status: N Yann Guidon wrote:

> hi !
>
> Nathaniel Downes wrote:
> > Well, while most of the list has been messing around discussing a
> wide
> > variety of topics, I've been working on a VHDL model of the F-CPU,
> which
> > should be completed by the end of the month.  Once that's done, I
> will
> > be putting it into an FPGA for demonstration.
> hey, i hope to see it work one day :-)
>
> if you do this wonder before december, i guess that you'll be invited
> in Europe to demonstrate it :-)

I'm supposed to be in Brittan next month and Germany the month after as
well, demonstrating my Eddas project, which is using my VHDL core for
the F-CPU.


>
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00963 for ; Thu, 3 Aug 2000 10:06:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 Aug 2000 10:06:39 +0200 (MEST) Received: (qmail 22482 invoked by uid 0); 3 Aug 2000 07:57:33 -0000 Received: from mk.egroups.com (207.138.41.165) by mx0.gmx.net with SMTP; 3 Aug 2000 07:57:33 -0000 X-eGroups-Return: sentto-1101623-551-965289111-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 03 Aug 2000 07:52:00 -0000 Received: (qmail 15729 invoked from network); 3 Aug 2000 07:51:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Aug 2000 07:51:50 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 3 Aug 2000 07:51:49 -0000 Received: (qmail 6538 invoked from network); 3 Aug 2000 07:45:07 -0000 Received: from unknown (HELO pandora.be) ([212.123.14.131]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 3 Aug 2000 07:45:07 -0000 Sender: root@pop.gmx.net Message-ID: <398922DE.B19CE452@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39883066.47013BDB@pandora.be> <3988C4C3.7FA0CBF1@f-cpu.org> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 09:44:31 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] "Educational" prices for MPW projects ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 91ca7dbcb9ce915dc4237c395c3a0430 Status: R X-Status: N Yann Guidon wrote:

> OH btw, i met just Nicolas Boulay in Paris and discussed about the control logic of
> the FC0. he lent me a book to read while he's in Canada and i'll learn some
> VHDL serious backgrounds (i only practiced with 22V10s :-D).

And the title and ISBN number of that book is ?

> Damn, Nico is a good
> semiconductor engineer :-)
>
> pelgrims p wrote:
> <snip EUROPRACTICE>
> WHYGEE
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00505 for ; Fri, 4 Aug 2000 09:45:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:45:47 +0200 (MEST) Received: (qmail 27263 invoked by uid 0); 3 Aug 2000 08:54:10 -0000 Received: from fh.egroups.com (208.50.144.71) by mx19.rz2.gmx.net with SMTP; 3 Aug 2000 08:54:10 -0000 X-eGroups-Return: sentto-1101623-552-965292845-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 03 Aug 2000 08:54:05 -0000 Received: (qmail 11348 invoked from network); 3 Aug 2000 08:54:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 3 Aug 2000 08:54:05 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 3 Aug 2000 08:54:05 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA17232 for f-cpu@egroups.com; Thu, 3 Aug 2000 04:54:04 -0400 Message-Id: <200008030854.EAA17232@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <3988E0D7.3D7F7847@ici.net> from "Nathaniel Downes" at Aug 02, 2000 11:02:47 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 3 Aug 2000 04:54:04 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d276ae2ae5e717468c26d9cc267712b5 Status: R X-Status: N > > I'm supposed to be in Brittan next month and Germany the month after as > well, demonstrating my Eddas project, which is using my VHDL core for > the F-CPU. > Where in Britain will u be demonstrating the Eddas project? Graham From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00535 for ; Fri, 4 Aug 2000 09:46:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:46:20 +0200 (MEST) Received: (qmail 21570 invoked by uid 0); 3 Aug 2000 13:44:10 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 3 Aug 2000 13:44:09 -0000 X-eGroups-Return: sentto-1101623-554-965310240-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ho.egroups.com with NNFMP; 03 Aug 2000 13:44:06 -0000 Received: (qmail 16834 invoked from network); 3 Aug 2000 13:44:00 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Aug 2000 13:44:00 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 3 Aug 2000 13:43:59 -0000 Received: from f-cpu.org (nas4-110.ras.club-internet.fr [195.36.203.110]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA12899 for ; Thu, 3 Aug 2000 15:43:56 +0200 (MET DST) Message-ID: <3989770D.5E616EDA@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39883066.47013BDB@pandora.be> <3988C4C3.7FA0CBF1@f-cpu.org> <398922DE.B19CE452@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 15:43:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] "Educational" prices for MPW projects ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a3ce3b11e5d865d12297f9d515c1271c Status: R X-Status: N hi,

pelgrims p wrote:
> Yann Guidon wrote:
> > OH btw, i met just Nicolas Boulay in Paris and discussed about th= e control logic of
> > the FC0. he lent me a book to read while he's in Canada and i'll = learn some
> > VHDL serious backgrounds (i only practiced with 22V10s :-D).
> And the title and ISBN number of that book is ?

if you want to know :

Philippe Larcher, "VHDL - Introduction =E0 la synth=E8se logique"=
Ed. Eyrolles 1997 ISBN 2-212-09584-8

that's a sort of "bootstrap" for the beginners like me.
for example i didn't know that a user could make a packeage :-D


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00538 for ; Fri, 4 Aug 2000 09:46:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:46:23 +0200 (MEST) Received: (qmail 27485 invoked by uid 0); 3 Aug 2000 13:44:19 -0000 Received: from mw.egroups.com (207.138.41.167) by mx0.gmx.net with SMTP; 3 Aug 2000 13:44:19 -0000 X-eGroups-Return: sentto-1101623-553-965310240-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 03 Aug 2000 13:44:18 -0000 Received: (qmail 2251 invoked from network); 3 Aug 2000 13:43:59 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 3 Aug 2000 13:43:59 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 3 Aug 2000 13:43:58 -0000 Received: from f-cpu.org (nas4-110.ras.club-internet.fr [195.36.203.110]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA25381 for ; Thu, 3 Aug 2000 15:43:55 +0200 (MET DST) Message-ID: <3989770B.F20ACF84@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> <3988608C.74164E29@pandora.be> <3988E07E.B4C9967@ici.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 15:43:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d4c9cccf16c7cbee62d3dd795b69b804 Status: R X-Status: N Nathaniel Downes wrote:
> > Is the model available ?
> > So we can look to it, and corntibute to the project :-).
> > P. Pelgrims
>
> Not yet, I'm a perfectionist,
like me, but does this forbids you to show what you have done ?

> and I want to get rid of the errors I'm getting in simulation.
that's only a "detail" :-) if you publish a first version,
we might help solve the problems together.

>  (Also, we never figured out the licensing for F-CPU last I knew)
??


> > if you do this wonder before december, i guess that you'll be invited
> > in Europe to demonstrate it :-)
>
> I'm supposed to be in Brittan next month and Germany the month after as
> well, demonstrating my Eddas project, which is using my VHDL core for
> the F-CPU.

well, you could as well spend some days on France between Germany and England,
so you can use the channel tunnel etc :-) and maybe show us your toys during
a meeting in Paris. that's an invitation :-)


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00586 for ; Fri, 4 Aug 2000 09:46:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:46:59 +0200 (MEST) Received: (qmail 8835 invoked by uid 0); 3 Aug 2000 20:24:18 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 3 Aug 2000 20:24:18 -0000 X-eGroups-Return: sentto-1101623-555-965334249-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 03 Aug 2000 20:24:15 -0000 Received: (qmail 28100 invoked from network); 3 Aug 2000 20:24:08 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 3 Aug 2000 20:24:08 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 3 Aug 2000 20:24:08 -0000 Received: from ici.net (downix@dialup-209.245.100.31.Manchester1.Level3.net [209.245.100.31]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id QAA14870 for ; Thu, 3 Aug 2000 16:24:06 -0400 (EDT) Sender: downix@ici.net Message-ID: <3989D4FC.EFCA534D@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14-storm i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200008030854.EAA17232@belegost.mit.edu> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 16:24:28 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8c53f84439f42f8b786002bbd533971a Status: R X-Status: N graham@belegost.mit.edu wrote:

> >
> > I'm supposed to be in Brittan next month and Germany the month after as
> > well, demonstrating my Eddas project, which is using my VHDL core for
> > the F-CPU.
> >
> Where in Britain will u be demonstrating the Eddas project?

Not sure, my companies partners are attempting to get me into a computer
show next month to show off Eddas and another smaller project I've been
working on.


>
>
> Graham
Don't Just Travel. Travel Right.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00589 for ; Fri, 4 Aug 2000 09:47:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:47:01 +0200 (MEST) Received: (qmail 22542 invoked by uid 0); 3 Aug 2000 20:26:50 -0000 Received: from ci.egroups.com (207.138.41.176) by mx12.rz2.gmx.net with SMTP; 3 Aug 2000 20:26:50 -0000 X-eGroups-Return: sentto-1101623-556-965334391-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 03 Aug 2000 20:26:39 -0000 Received: (qmail 31880 invoked from network); 3 Aug 2000 20:26:31 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 3 Aug 2000 20:26:31 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 3 Aug 2000 20:26:30 -0000 Received: from ici.net (downix@dialup-209.245.100.31.Manchester1.Level3.net [209.245.100.31]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id QAA14960 for ; Thu, 3 Aug 2000 16:26:23 -0400 (EDT) Sender: downix@ici.net Message-ID: <3989D585.FE991F05@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14-storm i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> <3988608C.74164E29@pandora.be> <3988E07E.B4C9967@ici.net> <3989770B.F20ACF84@f-cpu.org> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 16:26:45 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e7075ad1a9d93604e810a28d42c0143 Status: R X-Status: N Yann Guidon wrote:

> Nathaniel Downes wrote:
> > > Is the model available ?
> > > So we can look to it, and corntibute to the project :-).
> > > P. Pelgrims
> >
> > Not yet, I'm a perfectionist,
> like me, but does this forbids you to show what you have done ?

Alright, I'll put it up at the end of the weekend.  I want to finish the
interim memory controller.


>
>
> > and I want to get rid of the errors I'm getting in simulation.
> that's only a "detail" :-) if you publish a first version,
> we might help solve the problems together.

I know, I am still a perfectionist, as you know.


>
>
> >  (Also, we never figured out the licensing for F-CPU last I knew)
> ??
>
>
> > > if you do this wonder before december, i guess that you'll be
> invited
> > > in Europe to demonstrate it :-)
> >
> > I'm supposed to be in Brittan next month and Germany the month after
> as
> > well, demonstrating my Eddas project, which is using my VHDL core
> for
> > the F-CPU.
>
> well, you could as well spend some days on France between Germany and
> England,
> so you can use the channel tunnel etc :-) and maybe show us your toys
> during
> a meeting in Paris. that's an invitation :-)

We'll see what happens.  It's not like my company is funded, you know.


>
>
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00592 for ; Fri, 4 Aug 2000 09:47:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:47:03 +0200 (MEST) Received: (qmail 15958 invoked by uid 0); 3 Aug 2000 20:27:35 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 3 Aug 2000 20:27:34 -0000 X-eGroups-Return: sentto-1101623-557-965334441-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 03 Aug 2000 20:27:31 -0000 Received: (qmail 2035 invoked from network); 3 Aug 2000 20:27:19 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Aug 2000 20:27:19 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 3 Aug 2000 20:27:19 -0000 Received: from f-cpu.org (nas4-170.aub.club-internet.fr [195.36.145.170]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA13909 for ; Thu, 3 Aug 2000 22:27:15 +0200 (MET DST) Message-ID: <3989D594.C5A50DA8@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008030854.EAA17232@belegost.mit.edu> <3989D4FC.EFCA534D@ici.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Aug 2000 22:27:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5d7ff25e297d0675d6244ca964a6741 Status: R X-Status: N hello,

Nathaniel Downes wrote:
> graham@belegost.mit.edu wrote:
> > > I'm supposed to be in Brittan next month and Germany the month after as
> > > well, demonstrating my Eddas project, which is using my VHDL core for
> > > the F-CPU.
> > >
> > Where in Britain will u be demonstrating the Eddas project?
>
> Not sure, my companies partners are attempting to get me into a computer
> show next month to show off Eddas and another smaller project I've been
> working on.

remember : March 2001, there is DATE2001 in Munich.
there's even a design contest, so you can participate.

> > Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00643 for ; Fri, 4 Aug 2000 09:47:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 04 Aug 2000 09:47:37 +0200 (MEST) Received: (qmail 26183 invoked by uid 0); 4 Aug 2000 01:43:39 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 4 Aug 2000 01:43:39 -0000 X-eGroups-Return: sentto-1101623-558-965353413-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 04 Aug 2000 01:43:38 -0000 Received: (qmail 1047 invoked from network); 4 Aug 2000 01:43:33 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 4 Aug 2000 01:43:33 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 4 Aug 2000 01:43:32 -0000 Received: from f-cpu.org (nas1-218.aub.club-internet.fr [195.36.150.218]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA10543 for ; Fri, 4 Aug 2000 03:43:21 +0200 (MET DST) Message-ID: <398A1F92.726EC596@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39881ED3.A1C4FE13@pandora.be> <39884856.DBCEA916@ici.net> <3988608C.74164E29@pandora.be> <3988E07E.B4C9967@ici.net> <3989770B.F20ACF84@f-cpu.org> <3989D585.FE991F05@ici.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 04 Aug 2000 03:42:42 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] What is the current status of F-CPU ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 98f84d31ebe08a451be12de9b0337c01 Status: R X-Status: N hi,

Nathaniel Downes wrote:
> Alright, I'll put it up at the end of the weekend.  I want to finish the
> interim memory controller.

ok :-) don't feel forced, just feel our impatience :-)

> > > and I want to get rid of the errors I'm getting in simulation.
> > that's only a "detail" :-) if you publish a first version,
> > we might help solve the problems together.
> I know, I am still a perfectionist, as you know.
as some of us are :-)

yet, i'm looking forward seeing you in Paris to discuss design with you and others :
most constructive things come from discussions. the mailing is is ok but not as
good as a chat around a glass of whatever...


> We'll see what happens.  It's not like my company is funded, you know.
i know.

but you know that you won't have to pay the hostel in Paris :-)
only the trip from London/wherever...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00317 for ; Mon, 7 Aug 2000 10:42:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 Aug 2000 10:42:17 +0200 (MEST) Received: (qmail 6403 invoked by uid 0); 7 Aug 2000 00:43:03 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 7 Aug 2000 00:43:03 -0000 X-eGroups-Return: sentto-1101623-559-965608980-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 07 Aug 2000 00:43:01 -0000 Received: (qmail 18408 invoked from network); 7 Aug 2000 00:42:59 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 7 Aug 2000 00:42:59 -0000 Received: from unknown (HELO mail4.one.net) (206.112.192.132) by mta1 with SMTP; 7 Aug 2000 00:42:59 -0000 Received: from port-33-29.access.one.net ([209.50.99.91] HELO tsunami ident: IDENT-NOT-QUERIED [port 55848]) by mail2.one.net with SMTP id <47583-372>; Sun, 6 Aug 2000 20:42:55 -0400 Sender: "Gregory Junker" To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-eGroups-From: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 6 Aug 2000 20:42:51 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2e2a14af6f61ac9ba3aef4dfe69d032 Status: R X-Status: N just checking

looking at the times of last update on the site, it seems the project has
experienced a slowdown in progress?

I have some comments to the comments in the 0.1 FCPU Manual, and I just want
to make sure that this list is still operational...

greg
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00320 for ; Mon, 7 Aug 2000 10:42:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 Aug 2000 10:42:18 +0200 (MEST) Received: (qmail 25460 invoked by uid 0); 7 Aug 2000 00:48:48 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 7 Aug 2000 00:48:48 -0000 X-eGroups-Return: sentto-1101623-560-965609317-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 07 Aug 2000 00:48:45 -0000 Received: (qmail 1358 invoked from network); 7 Aug 2000 00:48:37 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 7 Aug 2000 00:48:37 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 7 Aug 2000 00:48:37 -0000 Received: from f-cpu.org (nas3-121.aub.club-internet.fr [195.36.145.121]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA15802 for ; Mon, 7 Aug 2000 02:48:34 +0200 (MET DST) Message-ID: <398E0755.64916899@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 Aug 2000 02:48:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d68b28ac988822bddd3c5a7f1ad46e3b Status: R X-Status: N hello !

gjunker@one.net wrote:
>
> just checking
>
> looking at the times of last update on the site, it seems the project has
> experienced a slowdown in progress?
>
> I have some comments to the comments in the 0.1 FCPU Manual, and I just want
> to make sure that this list is still operational...

the v0.2 is up and can be downloaded at the usual places.
i don't have all the passwords so some sites are not updated.

http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.zip or
http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.tgz (same data)

> greg
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00323 for ; Mon, 7 Aug 2000 10:42:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 Aug 2000 10:42:19 +0200 (MEST) Received: (qmail 2626 invoked by uid 0); 7 Aug 2000 02:11:31 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 7 Aug 2000 02:11:31 -0000 X-eGroups-Return: sentto-1101623-561-965614275-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 07 Aug 2000 02:11:16 -0000 Received: (qmail 31786 invoked from network); 7 Aug 2000 02:11:12 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 7 Aug 2000 02:11:12 -0000 Received: from unknown (HELO mail4.one.net) (206.112.192.132) by mta1 with SMTP; 7 Aug 2000 02:11:08 -0000 Received: from port-33-29.access.one.net ([209.50.99.91] HELO tsunami ident: IDENT-NOT-QUERIED [port 61737]) by mail2.one.net with SMTP id <47897-372>; Sun, 6 Aug 2000 22:10:48 -0400 Sender: "Gregory Junker" To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-eGroups-From: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 6 Aug 2000 22:10:40 -0400 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] test, comments and question Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BFFFF3.45D4C110" X-UIDL: 0a217e5c671b6026ad4ba98fe89487e3 Status: R X-Status: N ------=_NextPart_000_000D_01BFFFF3.45D4C110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit got it, thanks, that answers most of my ???   at present, I'll sit back, read, investigate, etc...find out where exactly everything is regarding progress, see where I can help....I am a Computer Engineer, architecture my minor (unfortunately, I decided that I would rather not spend 80 hour weeks doing a VLSI senior design project) and software my specialty...it seems you are the driving force behind the project (regardless of your disclaimer in the manual/FAQ about there not being any "leadership"). I'll peruse the message backlogs to catch up, and hope I can help....   I am also involved somewhat in the ReactOS ( www.reactos.com) development, so the organizational concepts involved here are hardly foreign to me :) I have a hazy notion of some common ground and complementary features between the two projects, which I will investigate and pursue independently as the two projects progress....   peace greg   PGP Key available at ldap://certserver.pgp.com or http://pgpkeys.mit.edu:11371   -----Original Message----- From: Yann Guidon [mailto:whygee@f-cpu.org] Sent: Sunday, August 06, 2000 8:49 PM To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question hello ! gjunker@one.net wrote: > > just checking > > looking at the times of last update on the site, it seems the project has > experienced a slowdown in progress? > > I have some comments to the comments in the 0.1 FCPU Manual, and I just want > to make sure that this list is still operational... the v0.2 is up and can be downloaded at the usual places. i don't have all the passwords so some sites are not updated. http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.zip or http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.tgz (same data) > greg WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html _____ _____ ------=_NextPart_000_000D_01BFFFF3.45D4C110 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
got it, thanks, that answers most of my ???
 
at present, I'll sit back, read, investigate, etc...find out where exactly everything is regarding progress, see where I can help....I am a Computer Engineer, architecture my minor (unfortunately, I decided that I would rather not spend 80 hour weeks doing a VLSI senior design project) and software my specialty...it seems you are the driving force behind the project (regardless of your disclaimer in the manual/FAQ about there not being any "leadership"). I'll peruse the message backlogs to catch up, and hope I can help....
 
I am also involved somewhat in the ReactOS (www.reactos.com) development, so the organizational concepts involved here are hardly foreign to me :) I have a hazy notion of some common ground and complementary features between the two projects, which I will investigate and pursue independently as the two projects progress....
 
peace
greg
 

PGP Key available at ldap://certserver.pgp.com or http://pgpkeys.mit.edu:11371

 
-----Original Message-----
From: Yann Guidon [mailto:whygee@f-cpu.org]
Sent: Sunday, August 06, 2000 8:49 PM
To: f-cpu@egroups.com
Subject: Re: [f-cpu] test, comments and question

hello !

gjunker@one.net wrote:
>
> just checking
>
> looking at the times of last update on the site, it seems the project has
> experienced a slowdown in progress?
>
> I have some comments to the comments in the 0.1 FCPU Manual, and I just want
> to make sure that this list is still operational...

the v0.2 is up and can be downloaded at the usual places.
i don't have all the passwords so some sites are not updated.

http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.zip or
http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.tgz (same data)

> greg
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
------=_NextPart_000_000D_01BFFFF3.45D4C110-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00326 for ; Mon, 7 Aug 2000 10:42:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 Aug 2000 10:42:20 +0200 (MEST) Received: (qmail 12478 invoked by uid 0); 7 Aug 2000 02:38:33 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 7 Aug 2000 02:38:33 -0000 X-eGroups-Return: sentto-1101623-562-965615909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 07 Aug 2000 02:38:33 -0000 Received: (qmail 21500 invoked from network); 7 Aug 2000 02:38:29 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 7 Aug 2000 02:38:29 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 7 Aug 2000 02:38:28 -0000 Received: from f-cpu.org (nas1-159.ras.club-internet.fr [195.36.192.159]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA10266 for ; Mon, 7 Aug 2000 04:38:25 +0200 (MET DST) Message-ID: <398E2114.EA5E007F@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 Aug 2000 04:38:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eda4a82195497f3c2cff2d7b955b5786 Status: R X-Status: N greg wrote tonight :
> got it, thanks, that answers most of my ???
what's interesting is the remaining questions :-)
someone is currently doing a LATEX version, so it's never too late,
don't worry. I even guess that we'll stick during some time to v0.2,
adding and correcting things because i don't expect big changes in the
content and form. The changes will be incremental, details.
your imput is welcome, like everyone's.

> at present, I'll sit back, read, investigate, etc...find out where
> exactly everything is regarding progress, see where I can help....
> I am a Computer Engineer, architecture my minor (unfortunately, I
> decided that I would rather not spend 80 hour weeks doing a VLSI
> senior design project) and software my specialty...it seems
> you are the driving force behind the project (regardless of
> your disclaimer in the manual/FAQ about there not being any
> "leadership"). I'll peruse the message
> backlogs to catch up, and hope I can help....

if you're a VHDL god, you have your reserved place here ;-P

even though in practice a lot of things are on my shoulders, i try as much
as possible to relegate as much responsibilities as i can. when it was an emerging
project it was possible to do a lot of things at the same time (particularly
as a student with not much "responsibilities"). Now that things grow,
that we have several web sites (see http://www.f-cpu.org !), archives
(anyone want to be responsible of the f-cpu group's archives ? i have
most of the items in my room), a manual (still waiting for the updated v0.2),
lobbying activities etc... i want to concentrate on the architectural
stuff, and stop "wasting" time in organisational things (that are necessary
anyway, we can't cut that !). Yet in reality not many people have enough
time to spend on the project and most of the things remain on my shoulders.
organize meetings, lobby around, write articles, because this is necessary
and vital for the project to be widely known.
we have also to write the f-cpu licence, fund the associations/Vereins (in France and
germany). I'd like a US F-CPU club, or something like that, to appear, because
the americans are not organised, much less than the europeans.

 
> I am also involved somewhat in the ReactOS (www.reactos.com) development,
> so the organizational concepts involved here are hardly foreign to me :)
poor you ! :-)

> I have a hazy notion of some common ground and complementary features
> between the two projects, which I will investigate and pursue independently
> as the two projects progress....

if you want to be our ambassador with reactos, it would be cool :-)
we can only succeed and grow through cooperation.

this is fundamentally a hobbyist's project, but a single man can't do much
in its corner. Through organisation and reunion, we can dream louder :-)

There is no really working assembler, or compiler, yet, so we can't start the
OS/applications development now. there's no kernel in the design pipeline as of
today (as far as i know). So if the reactos guys are interested to join the software
side of te project, or give some advices when the feel the need, they are welcome.

have fun,
and stay far away from the loudspeakers :-)

> peace
and music
> greg
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA01006 for ; Mon, 7 Aug 2000 16:29:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 Aug 2000 16:29:43 +0200 (MEST) Received: (qmail 28475 invoked by uid 0); 7 Aug 2000 09:46:54 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 7 Aug 2000 09:46:54 -0000 X-eGroups-Return: sentto-1101623-563-965641609-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 07 Aug 2000 09:46:50 -0000 Received: (qmail 13220 invoked from network); 7 Aug 2000 09:46:48 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 7 Aug 2000 09:46:48 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta1 with SMTP; 7 Aug 2000 09:46:48 -0000 Received: from 0018728164 (host-209-214-154-121.bix.bellsouth.net [209.214.154.121]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id FAA16610; Mon, 7 Aug 2000 05:46:45 -0400 (EDT) Message-ID: <000801c00054$59bd3980$799ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 7 Aug 2000 04:46:23 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0002A.6FDAA380" X-UIDL: c8edac9bf58e65858aaa91c9f5371dda Status: R X-Status: N ------=_NextPart_000_0005_01C0002A.6FDAA380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gentlemen: To date all I have seen is remarks concerning Software this sof= tware that; Compiler this, compiler that. Guys you can't do a f---ing thin= g wothout hardware and I don't see any remarks in this respect. Mr Wygee sa= id it all in the very first paragraph of his FC0 description. Here is whe= re the Hardware Guy comes in. Wrong - he should have been there from the S= TART. My Compiler is already written - 147 Instructions and will be less that= that when FULLY Optimized at the Micro Level. I could take the time to re-write it n= ow but there are too many other thing to be concerned about. I am not concerned about licenscing - you shouldn't either - nothing to= licensce. My design has been described in previous mail; it consists of 18 Processing= Elements (PE's); seven (7) of which are Instruction Execution Units. All = are in schematic form which I will provide to anyone requesting them. It w= ill cost you the price of mail and reproduction. Use as you damn well see = fit. Most can be used in FC0. I will NOT provide an interconnection diagr= am. Since you seem to be concerned about using VHDL - convert them to VHDL= .=20=20 Later today, I will send a System Summary of where I am as of this date= - which is much farther than FC1 There will be data for you aspiring Comp= uter Architects, Hardware designers and Transistor counters & System Architects. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C0002A.6FDAA380 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Gentlemen:  To date all I have seen is remarks concerning Software this software that; Compiler this, compiler that.  Guys you can't do a f---ing thing wothout hardware and I don't see any remarks in this respect. Mr Wygee said it all in the very first paragraph of his FC0 description.   Here is where the Hardware Guy comes in.  Wrong - he should have been there from the START.
    My Compiler is already written - 147 Instructions and will be less that that when
FULLY Optimized at the Micro Level.  I could take the time to re-write it now but there are too many other thing to be concerned about.
    I am not concerned about licenscing - you shouldn't either - nothing to licensce.
My design has been described in previous mail; it consists of 18 Processing Elements (PE's); seven (7) of which are Instruction Execution Units.  All are in schematic form which I will provide to anyone requesting them.  It will cost you the price of mail and reproduction.  Use as you damn well see fit.  Most can be used in FC0.  I will NOT provide an interconnection diagram.  Since you seem to be concerned about using VHDL - convert them to VHDL. 
    Later today, I will send a System Summary of where I am as of this date - which is much farther than FC1  There will be data for you aspiring Computer Architects,
Hardware designers and Transistor counters & System Architects.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_0005_01C0002A.6FDAA380-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00540 for ; Tue, 8 Aug 2000 12:14:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 Aug 2000 12:14:16 +0200 (MEST) Received: (qmail 14251 invoked by uid 0); 7 Aug 2000 16:47:18 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 7 Aug 2000 16:47:18 -0000 X-eGroups-Return: sentto-1101623-564-965666836-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 07 Aug 2000 16:47:15 -0000 Received: (qmail 9367 invoked from network); 7 Aug 2000 16:47:15 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 7 Aug 2000 16:47:15 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 7 Aug 2000 16:47:15 -0000 Received: from ici.net (downix@dialup-209.245.109.135.Manchester1.Level3.net [209.245.109.135]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id MAA27528 for ; Mon, 7 Aug 2000 12:47:13 -0400 (EDT) Sender: downix@ici.net Message-ID: <398EE82A.4BBC5583@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.4.0-test2 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000801c00054$59bd3980$799ad6d1@0018728164> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 Aug 2000 12:47:38 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN32 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 905fab614e287df249460c4cd0045bda Status: R X-Status: N "Richard E.Hartney" wrote:

>  Gentlemen:  To date all I have seen is remarks concerning Software
> this software that; Compiler this, compiler that.  Guys you can't do a
> f---ing thing wothout hardware and I don't see any remarks in this
> respect. Mr Wygee said it all in the very first paragraph of his FC0
> description.   Here is where the Hardware Guy comes in.  Wrong - he
> should have been there from the START.
>
> Ahem, I have been there from the start.
>
>
>      My Compiler is already written - 147 Instructions and will be
> less that that whenFULLY Optimized at the Micro Level.  I could take
> the time to re-write it now but there are too many other thing to be
> concerned about.    I am not concerned about licenscing - you
> shouldn't either - nothing to licensce.
>
> There you are wrong.  I personally wouldn't like my work to be usurped
> by some mega corp and I get nothing for it.
>
>  My design has been described in previous mail; it consists of 18
> Processing Elements (PE's); seven (7) of which are Instruction
> Execution Units.  All are in schematic form which I will provide to
> anyone requesting them.  It will cost you the price of mail and
> reproduction.  Use as you damn well see fit.  Most can be used in
> FC0.  I will NOT provide an interconnection diagram.  Since you seem
> to be concerned about using VHDL - convert them to VHDL.
>
> For testing/debugging, VHDL is easy to work with/quick to optimize.
> From there you can make the system gates, the register transfer
> architecture, the system loops, etc. all the way down to the
> gate-level for making a mask.
>
> And I would love to see your design work, I said this before.
>
>
>
>      Later today, I will send a System Summary of where I am as of
> this date - which is much farther than FC1  There will be data for you
> aspiring Computer Architects,Hardware designers and Transistor
> counters & System Architects. SincerelyRichard E. HartneyResearch
> DirectorErin Greene & Associates
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00543 for ; Tue, 8 Aug 2000 12:14:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 Aug 2000 12:14:17 +0200 (MEST) Received: (qmail 3678 invoked by uid 0); 7 Aug 2000 16:58:17 -0000 Received: from fg.egroups.com (208.50.144.70) by mx11.rz2.gmx.net with SMTP; 7 Aug 2000 16:58:17 -0000 X-eGroups-Return: sentto-1101623-565-965667492-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 07 Aug 2000 16:58:15 -0000 Received: (qmail 5694 invoked from network); 7 Aug 2000 16:58:12 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 7 Aug 2000 16:58:12 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 7 Aug 2000 16:58:11 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id LAA23719 for ; Mon, 7 Aug 2000 11:58:10 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <398EE82A.4BBC5583@ici.net> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 7 Aug 2000 11:58:10 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN32 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6d75d6f4878b21846947b16536b1a823 Status: R X-Status: N Okay sorry for this newbie mail.

Do you plan or is there an emulator for your processor?

Else I'm interessed to implement it.

Send me the contact for the concerning people

thanks

svdh
where you set the price
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00641 for ; Fri, 11 Aug 2000 12:49:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:49:47 +0200 (MEST) Received: (qmail 28065 invoked by uid 0); 9 Aug 2000 11:59:28 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 9 Aug 2000 11:59:28 -0000 X-eGroups-Return: sentto-1101623-566-965822361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 09 Aug 2000 11:59:22 -0000 Received: (qmail 2617 invoked from network); 9 Aug 2000 11:59:21 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Aug 2000 11:59:21 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta1 with SMTP; 9 Aug 2000 11:59:20 -0000 Received: from 0018728164 (host-209-215-11-6.bix.bellsouth.net [209.215.11.6]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA14308; Wed, 9 Aug 2000 07:59:07 -0400 (EDT) Message-ID: <000901c001f9$2d9ca920$060bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 9 Aug 2000 06:57:52 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C001CF.236A4900" X-UIDL: 9671a76962fac6486925f056955d25f4 Status: R X-Status: N ------=_NextPart_000_0005_01C001CF.236A4900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C001CF.236A4900" ------=_NextPart_001_0006_01C001CF.236A4900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0006_01C001CF.236A4900 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
 
------=_NextPart_001_0006_01C001CF.236A4900-- ------=_NextPart_000_0005_01C001CF.236A4900 Content-Type: application/msword; name="DOC1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DOC1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAawAAAAAAAAAA EAAAbQAAAAEAAAD+////AAAAAGoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAACE0AAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIm4AADd8AAA3fAAA7UgAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAOQBAAAAAAAA5AEAAOQB AAAAAAAA5AEAAAAAAADkAQAAAAAAAOQBAAAAAAAA5AEAABQAAAAAAAAAAAAAAPgBAAAAAAAAhB4A AAAAAACEHgAAAAAAAIQeAAA4AAAAvB4AAAwAAADIHgAAbAAAAPgBAAAAAAAAeD4AALYAAABAHwAA AAAAAEAfAAAiAAAAYh8AAAAAAABiHwAAAAAAAGIfAAAAAAAAYh8AAAAAAABiHwAAAAAAAGIfAAAA AAAAGz4AAAIAAAAdPgAAAAAAAB0+AAAAAAAAHT4AAAAAAAAdPgAAAAAAAB0+AAAAAAAAHT4AAAAA AAAuPwAAIAIAAE5BAADiAAAAHT4AABUAAAAAAAAAAAAAAAAAAAAAAAAA5AEAAAAAAABiHwAAAAAA AAAAAAAAAAAAAAAAAAAAAABiHwAAAAAAAGIfAAAAAAAAYh8AAAAAAABiHwAAAAAAAB0+AAAAAAAA XCgAAAAAAADkAQAAAAAAAOQBAAAAAAAAYh8AAAAAAAAAAAAAAAAAAGIfAAAAAAAAMj4AABYAAABc KAAAAAAAAFwoAAAAAAAAXCgAAAAAAABiHwAAogEAAOQBAAAAAAAAYh8AAAAAAADkAQAAAAAAAGIf AAAAAAAAGz4AAAAAAAAAAAAAAAAAAFwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYh8AAAAAAAAbPgAAAAAAAFwoAADmBAAAXCgAAAAAAABCLQAA xgAAAGc8AACQAAAA5AEAAAAAAADkAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGz4AAAAAAABiHwAAAAAAADQfAAAMAAAA4Cg78PgB wAH4AQAAjBwAAIQeAAAAAAAABCEAABgHAAD3PAAAFAAAAAAAAAAAAAAAGz4AAAAAAABIPgAAMAAA AHg+AAAAAAAACz0AABABAAAwQgAAAAAAABwoAABAAAAAMEIAAAAAAAAbPgAAAAAAAFwoAAAAAAAA +AEAAAAAAAD4AQAAAAAAAOQBAAAAAAAA5AEAAAAAAADkAQAAAAAAAOQBAAAAAAAAAgDZAAAADQ0N ICAgICAgICAgICAgICAgICAgICAgICAgRVJJTiBHUkVFTkUgJiBBU1NPQ0lBVEVTDUJ1c2luZXNz IEluZm9ybWF0aW9uIE1hbmFnZW1lbnQgU3lzdGVtcw0yNjEzIE5vcnRoIDExdGggU3RyZWV0DU9j ZWFuIFNwcmluZ3MsIE1pc3Npc3NpcHBpICAzOTU2NC04MzY0DQ0NUGhvbmUgMjI4LTg3NS02MDAz DWUtbWFpbCAgcmhhcnRuZXlAYmVsbHNvdXRoLm5ldA0NDQ0NDQ0NDQ0NDQ1TWVNURU0gT1ZFUlZJ RVcNDQ0NDQ0NDQ0NDQ0NDQ0NDQ1BVUdVU1QgMjAwMA0MU1lTVEVNIE9WRVJWSUVXDQ0NMS4gIFRI RSBQUk9EVUNUDQlUaGUgb2JqZWN0aXZlIGlzIHRvIHByb2R1Y2UgYSBsb3cgY29zdCwgaGlnaCBw ZXJmb3JtYW5jZSwgdXNlciBvcGVyYXRlZA1MaWdodHBlbi9Nb3VzZS1jb250cm9sbGVkIERpc3Bs YXkgVGVybWluYWwgU3lzdGVtLg0NCVRoZSByZXN1bHRpbmcgc3lzdGVtIG1heSBiZSB1c2VkIGlu IHZpcnR1YWxseSBhbnkgQ29tbWVyY2lhbCBTbWFsbC9MYXJnZQ1CdXNpbmVzcyBBcHBsaWNhdGlv biBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkIHRvIEZlZGVyYWwvU3RhdGUvTG9jYWwgR292ZXJu bWVudCwNd2hlcmUgcHJlc2VudCBkYXkgdXNhZ2UgaXMgdGhlIFBlcnNvbmFsIENvbXB1dGVyIChQ Qykgd2l0aCBvciB3aXRob3V0IE5ldHdvcmsNU2VydmVyIEhhcmR3YXJlL1NvZnR3YXJlLiAgU2lt cGx5IGRpc2NhcmQgdGhlIFRvd2VyL1NlcnZlciB3aXRoIHdoYXRldmVyIHRoZXkNY29udGFpbjsg cmV0YWluIHRoZSByZW1haW5pbmcgZGV2aWNlczsgYW5kIHBsdWcgaW4gdGhlICBuZXcgUHJvY2Vz c2luZyBIYXJkd2FyZQ1hbmQgQXBwbGljYXRpb24gUHJvZ3JhbXMuICBUaGlzIHN5c3RlbSBpcyBv cGVuLWVuZGVkIHRvIGFsbCB0eXBlcyBvZiBQZXJpcGhlcmFsIGRldmljZXMuDUEgdHlwaWNhbCBh cHBsaWNhdGlvbiBjb3VsZCBiZSBBTEwgRGVwYXJ0bWVudHMgYW5kIEFMTCBhc3NvY2lhdGVkIGZ1 bmN0aW9ucyBpbiBhDUhvc3BpdGFsIG9yIEdST1VQIG9mIEhvc3BpdGFscy4gIE9yIGl0IGNvdWxk IGJlIHVzZWQgYnkgTkFTQSBhcyBwcmUvcG9zdCBsYXVuY2gNU3lzdGVtcyBNb25pdG9yIGFuZCBS ZW1vdGUgQ29udHJvbCBTeXN0ZW0uIElmIHlvdSBhc2sgdGhlIHF1ZXN0aW9uIJYgQ0FOIElUIERP PyCWDVRoZSBhbnN3ZXIgaXMgWUVTLg0NCVRoZSBzeXN0ZW0gaXMgcHJvZ3JhbW1lZCBpbiBhIGxh bmd1YWdlIGNhbGxlZCBUSVBTLiAgVElQUyBpcyBhbiBhY3JvbnltIGZvcg1UT1RBTCBJTkZPUk1B VElPTiBQUk9HUkFNTUlORyBTWVNURU0uICBUSVBTIGlzIGFuIGludGVycHJldGl2ZSBsYW5ndWFn ZQ13aGljaCBwcm92aWRlcyB0aGUgQXBwbGljYXRpb24gUHJvZ3JhbW1lciB3aXRoIHRoZSBjYXBh YmlsaXRpZXMgdG8gQ29sbGVjdCwgU3RvcmUsIA1NYW5pcHVsYXRlLCBTdHJ1Y3R1cmUgYW5kIFJl dHJpZXZlIGJsb2NrcyBvZiBkYXRhLiAgVGhlIGxhbmd1YWdlIGlzIHRoZXJlZm9yZSBGSUxFLCBG T1JNLCBQQUdFLCBhbmQgUEFSVCBvcmllbnRlZC4gIFRJUFMgaGFzIGJlZW4gc3BlY2lmaWNhbGx5 IGRlc2lnbmVkIHRvIGZ1bmN0aW9uIGluIGEgTXVsdGktdXNlciwgTXVsdGktcG9ydCBlbnZpcm9u bWVudCAmIG9jY3VwaWVzIG9ubHkgODAsMDAwIGJ5dGVzIG9mIE1lbW9yeSCWIG1vcmUgc3BlY2lm aWNhbGx5IJYgIDksOTY3IEluc3RydWN0aW9ucy4gIFRoZSBBcHBsaWNhdGlvbiBQcm9ncmFtbWVy IG1heSBjcmVhdGUgRm9ybXMgYXQgYW55IFVzZXIgU3RhdGlvbjsgZW50ZXIgcmVsYXRlZCBQcm9n cmFtczsgVGVzdCBhbmQgTW9kaWZ5IGFzIG5lZWRlZCwgYmVmb3JlIG9yIGFmdGVyIHRoZSBzeXN0 ZW0gaXMgT24tTGluZS4gIFRoZXNlIGZlYXR1cmVzIGFyZSBub3QgaW5oZXJlbnQgaW4gcHJlc2Vu dCBkYXkgUEOScy4gIFRoZSBzeXN0ZW0gaXMgZGVzaWduZWQgdG8gYWNjb21tb2RhdGUgZnJvbSAx IHRvIDEyOCBVc2VyIFN0YXRpb25zLiAgQSBwYXJhbGxlbCBleHBhbnNpb24gcG9ydCBpcyBwcm92 aWRlZCBmb3Igk06UIHN1Yi1zeXN0ZW1zLg0NCVRoZSBVU0VSIFNUQVRJT04gY29uc2lzdHMgb2Yg YSBDUlQvRmxhdCBQYW5lbCBNb25pdG9yLCBLZXlib2FyZCwgTGlnaHRwZW4vTW91c2UsIFByaW50 ZXIsIElEIFJlYWRlciwgYW5kIGEgc21hbGwgYXNzZW1ibHkgY29udGFpbmluZyBJbnRlcmZhY2Ug TG9naWMuICBUaGUgYXNzZW1ibHkgYWxzbyBwcm92aWRlcyBjb25uZWN0b3JzIGZvciB0aGUgbG9j YWwgY29tcG9uZW50cyBhbmQgb25lIGNvbm5lY3Rpb24gdG8gYSByZW1vdGUgQ29tcHV0ZXIgQXNz ZW1ibHkuICBBIHN0YXRpb24gbWF5IGluY2x1ZGUvZXhjbHVkZSB0aGUgUHJpbnRlciBhbmQgSUQg UmVhZGVyLg0NCVRoZSByZW1vdGUgQ09NUFVURVIgQVNTRU1CTFkgY2FuIGFjY29tbW9kYXRlIHVw IHRvIDEyOCBVc2VyIFN0YXRpb25zIHdpdGhvdXQgbm90aWNlYWJsZSBkZWdyYWRhdGlvbiBpbiBy ZXNwb25zZSB0byB1c2VyIHJlcXVlc3RzLiAgVGhlIG1vdW50aW5nIHJhY2sgY29udGFpbnMgYSBM YW5ndWFnZSBQcm9jZXNzb3Igd2l0aCByZXF1aXJlZCBTUkFNIE1lbW9yeSByZXNvdXJjZXMgYW5k IElucHV0L091dHB1dCBDb250cm9sbGVyczsNYW5kIGEgUGVyaXBoZXJhbCBQcm9jZXNzb3Igd2l0 aCBpdHMgcmVxdWlyZWQgU1JBTSBNZW1vcnkgcmVzb3VyY2VzIGFuZCBJbnB1dC9PdXRwdXQNQ29u dHJvbGxlcnMuICBUaGUgdHdvIHByb2Nlc3NvcnMgYXJlIGlkZW50aWNhbCBFUklOMzIgRlBHQSBk ZXZpY2VzIGhhdmluZyBpZGVudGljYWwgSW5zdHJ1Y3Rpb24gU2V0cy4gIEFsc28gcHJvdmlkZWQg aXMgdGhlIG5lY2Vzc2FyeSBQb3dlciBTdXBwbHksIENvb2xpbmcgRmFuIEFzc2VtYmx5LCBFTUkN TGluZSBGaWx0ZXJzLCBhbmQgY29ubmVjdG9ycyBmb3Igc2hpZWxkZWQgdHdpc3RlZCBwYWlyIGNh Ymxpbmcgb2YgRGlmZmVyZW50aWFsIERyaXZlci9SZWNlaXZlcnMuDUZpYmVyIE9wdGljcyBtYXkg YmUgdXNlZCB3aGVyZSBkaXN0YW5jZSBpcyBhIGZhY3RvciAoY29zdCBtdXN0IGJlIGNvbnNpZGVy ZWQpLg0MMi4gSElTVE9SWSBPRiBUSEUgTEFOR1VBR0UNDVRoZSBsYW5ndWFnZSBvZiBUSVBTIGlz IGJhc2VkIHVwb24gSk9TUyAoSk9ITk5JQUMgT3Blbi1TaG9wIFN5c3RlbSB3aGljaA13YXMgZGV2 ZWxvcGVkIGJ5IHRoZSBSYW5kIENvcnBvcmF0aW9uIGluIHRoZSBlYXJseSAxOTYwknMuDQ1Ob3Rl OiAgUmVmZXIgdG86IEpPU1M6IEEgREVTSUdORVKSUyBWSUVXIE9GIEFOIEVYUEVSSU1FTlRBTCBP Ti1MSU5FIENPTVBVVEVSIFNZU1RFTSBCWSBKLkMuIFNoYXcgb2YgdGhlIFJhbmQgQ29ycG9yYXRp b24sIFNhbnRhIE1vbmljYSwgQ2FsaWZvcm5pYQ1QUk9DRUVESU5HUyCWIEZBTEwgSk9JTlQgQ09N UFVURVIgQ09ORkVSRU5DRSwgMTk2NC4NDQlPdGhlciBlZmZvcnRzIGluIHNpbWlsYXIgZGV2ZWxv cG1lbnRzIHdlcmUgdW5kZXJ0YWtlbiBieSB0aGUgVW5pdmVyc2l0eSBvZiBQaXR0c2J1cmcgKFBJ TCkgliBQaXR0c2J1cmcgSW50ZXJwcmV0aXZlIExhbmd1YWdlKSBhbmQgU2FuZGVycyBBc3NvY2lh dGVzIEluY29ycG9yYXRlZCAoRk9QUyApIJYgRmlsZQ1PcmllbnRlZCBQcm9ncmFtbWluZyBTeXN0 ZW0uDQ0zLiAgT0xEIFNZU1RFTSBBUkNISVRFQ1RVUkUNDQlUaGUgU2FuZGVycyBlZmZvcnQgd2Fz IHN0YXJ0ZWQgaW4gMTk2NSBhbmQgdGVybWluYXRlZCBpbiAxOTcyLiBUaGUgc3lzdGVtIHVzZWQg dHdvIEhvbmV5d2VsbCBtaW5pY29tcHV0ZXJzLCBhIEREUC01MTYgYW5kIGEgRERQLTQxNi4gIFRo ZSA0MTYgaGFkIGEgcmVkdWNlZCBpbnN0cnVjdGlvbiBzZXQgYW5kIGJ1dCBvdGhlcndpc2UgaWRl bnRpY2FsIHRvIHRoZSA1MTYuICBUaGUgdG90YWwgc3lzdGVtIHdhcyBzdGF0ZS1vZi10aGUgYXJ0 IGF0IHRoZSB0aW1lLiAgTXVjaCBlZmZvcnQgd2FzIGRvbmUgaW4gbWFya2V0aW5nIJYgdG9vIG5v IGF2YWlsIJYgZHVlIHRvIGNvc3QgliBhbmQgdGhlIGVudGlyZSBEZXBhcnRtZW50IHdhcyBkaXNi YW5kZWQuDQ0JCVN5c3RlbSBkZWZpY2llbmNpZXMgaW5jbHVkZWQ6DUluYWRlcXVhdGUgQ29yZSBN ZW1vcnkgZm9yIHRoZSBMYW5ndWFnZSBQcm9jZXNzb3IgJiB0aGVyZWZvcmU6DVVzZXIgU2xvdHMg bGltaXRlZCB0byBmb3VyICg0KSAmIHRoZXJlZm9yZToNRGlzayBzd2FwcGluZyB3YXMgbmVjZXNz YXJ5ICYgdGhlcmVmb3JlOg1EaXNrIGFjY2VzcyB3YXMgOTAgbWlsbGktc2Vjb25kcyBhdmVyYWdl ICYgdGhlcmVmb3JlOg1TaXggKDYpIG9yIG1vcmUgVXNlcnMgb2YgcmFwaWQgTGlnaHRwZW4gc3Ry aWtlcyByZXN1bHRlZCBpbiBub3RpY2VhYmxlDVNsb3dpbmcgaW4gcmVzcG9uc2UgdGltZS4gIEtl eWJvYXJkIGlucHV0cyB3ZXJlIG5ldmVyIGEgcHJvYmxlbS4NCQ1UaGUgc2l4dGVlbiAoMTYpIGJp dCBjb21wdXRlciBoYWQgbGltaXRlZCBhZGRyZXNzaW5nIGNhcGFiaWxpdHkgYW5kIGZvcmNlZCBJ bmRpcmVjdCBvcg1JbmRleGVkIEFkZHJlc3NpbmcgZm9yIE1lbW9yeSBSZWZlcmVuY2UgSW5zdHJ1 Y3Rpb25zIGluIHRvbyBtYW55IGluc3RhbmNlcy4gIFByaW9yIHRvIGJlaW5nIGRpc2JhbmRlZCwg YW4gZWZmb3J0IGluIHJlZGVzaWduIG9mIHRoZSBERFAtNTE2IHdhcyBwdXJzdWVkIGJ1dCBub3Qg Y29tcGxldGVkLg0NCURpc2sgc3RvcmFnZSB3YXMgbGltaXRlZCB0byBlaWdodCAoOCkgdW5pdHMg d2hpY2ggcHJvdmlkZWQgNi40IE1ieXRlcyBmb3IgQXBwbGljYXRpb24gUHJvZ3JhbXMgYW5kIERh dGEuICBBIGRpc2sgU2VjdG9yIGNvbnRhaW5lZCAzMiAxNi1CaXQgV29yZHMsIGluY2x1ZGluZyBv dmVyaGVhZCAocG9pbnRlcnMsIGRlc2NyaXB0b3JzKS4NDQlUaGUgQ1JUIE1vbml0b3JzIHdlcmUg cGh5c2ljYWxseSBwYWdlLW9yaWVudGVkIGNhcGFibGUgb2YgZGlzcGxheWluZyAxMDE5IGNoYXJh Y3RlcnMNSW5jbHVkaW5nIGZvcm1hdCB0eXBlcy4gIEFsbCBjYWJsaW5nIHdhcyBkaXJlY3QgdHdp c3RlZCBwYWlyLXBhcmFsbGVsIGRhdGEuDQwNNC4gIE5FVyBTWVNURU0gQVJDSElURUNUVVJFDQ0J VGhpcyBkZXNpZ24gaXMgc2ltaWxhciB0byBpdHMgcHJlZGVjZXNzb3Igd2l0aCB0d28gbWFqb3Ig ZXhjZXB0aW9ucy4gIFRoZSB0d28gcHJvY2Vzc29ycyBhcmUgaWRlbnRpY2FsIEZQR0EgZGV2aWNl cyB3aXRoIHNpbWlsYXIgSVNBIChJbnN0cnVjdGlvbiBTZXQgQXJjaGl0ZWN0dXJlKSBhcyB0aGUg RERQLTUxNi4gIFRoaXMgZGVzaWduIGNlYXNlZCBiZWluZyBhbiBFbXVsYXRpb24gd2hlbiAzMiBC aXQgRGF0YSB3YXMgaW5jb3Jwb3JhdGVkLiAgU2V2ZXJhbCBub24tdXNhYmxlDUluc3RydWN0aW9u cyB3ZXJlIGRpc2NhcmRlZCBhbmQgc2V2ZXJhbCBpbnN0cnVjdGlvbnMgd2VyZSBhZGRlZC4gIFRo ZSBwdXJwb3NlIGluIHJldGFpbmluZyB0aGUgSVNBIGlzIHRvIG1pbmltaXplIGNoYW5nZXMgdG8g Y2FwdHVyZSBFWElTVElORyBTT0ZUV0FSRS4gIFRoZSBvdGhlciBtYWpvciBkaWZmZXJlbmNlIGlz IHRoZSB1c2Ugb2YgU1JBTSBpbiBsaWV1IG9mIERpc2sgZm9yIEFwcGxpY2F0aW9uIFByb2dyYW1z IGFuZCBEYXRhIFN0b3JhZ2UNDVRoZSBwcm9jZXNzb3IocykgUHJvZ3JhbSBNZW1vcnkgaXMgRm91 ci1Qb3J0IHdoZXJlOg0JUG9ydCAxID0gSW5zdHJ1Y3Rpb24gU291cmNlDQlQb3J0IDIgPSBWZWN0 b3IgKEpNUCwgSlNUIChDQUxMKSwgSk1QSSAoUlROKSwgQlJBTkNILCBJbnRlcnJ1cHQgKENBTEwp DQkJICBUaGlzIFBvcnQgdXNlcyB0aGUgQWRkcmVzcyBSZWFkLWJhY2sgb2YgIHRoZSBvbi1jaGlw IFByb2dyYW0NCQkgIENvdW50ZXIgYWxzbyBoYXZpbmcgZWl0aGVyIExvYWQgKFZlY3Rvcikgb3Ig SW5jcmVtZW50IChQQysxKSBmZWF0dXJlcy4NCQkgIEFORCBJbnN0cnVjdGlvbiBMb29rLUFoZWFk IGZvciB0aGUgYWJvdmUgSW5zdHJ1Y3Rpb25zDQlQb3J0IDMgPSBCb290IExvYWQNCVBvcnQgNCA9 IFJlc2VydmVkDQlUaGVyZSBhcmUgdGhyZWUgKDMpIFNJTU0vRElNTSBwYWNrYWdlcywgZWFjaCBw cm92aWRpbmcgNjRLIFggMzY7DQl5aWVsZGluZyBhbiAxMDggQml0IE1pY3JvIEluc3RydWN0aW9u LiAgDQ1UaGUgcHJvY2Vzc29yKHMpIExvY2FsIE1lbW9yeSAoSGFydmFyZCBBcmNoaXRlY3R1cmUp IGlzIEZvdXItUG9ydCB3aGVyZToNCVBvcnQgMSA9IFJlYWQgT25seSAoT3BlcmFuZCBMb29rLUFo ZWFkKQ0JUG9ydCAyID0gUmVhZCBPbmx5IChPcGVyYW5kIExvb2stYWhlYWQpDQlQb3J0IDMgPSBX cml0ZSBPbmx5LCBTaGFyZWQgd2l0aCBCb290IExvYWQNCVBvcnQgNCA9IEZCQyAoRnVsbHkgQnVm ZmVyZWQgQ2hhbm5lbCkNCQkgRnJvbS9UbyBHbG9iYWwgTWVtb3J5ICYNCQkgRnJvbS9UbyBBc3Nv Y2lhdGVkIFBlcmlwaGVyYWxzDQlMYW5ndWFnZSBwcm9jZXNzb3IgUGVyaXBoZXJhbHMgYXJlIENJ Q1UgKENvbnNvbGUgSW5wdXQgQ29udHJvbCBVbml0KSwgQ1JUDQlSZWZyZXNoIE1lbW9yeSwgTXVs dGlwbHkvRGl2aWRlL1NxdWFyZSBSb290ICYgRmxvYXRpbmcgUG9pbnQuIFdoZXJlIHRoZQ0JUGVy aXBoZXJhbCBwcm9jZXNzb3Igc2VydmljZXMgdXAgdG8gMTI4IFByaW50ZXJzLCBSZWFsIFRpbWUg Q2xvY2ssIEZheCwgTW9kZW0sDQl1cCB0byAxMjggUGFnZSBTY2FubmVycywgSW9tZWdhIERpc2ss IGFuZCB1cCB0byCTTpQgSGFyZCBEaXNrcy4NDQ0JVGhlcmUgYXJlIGZvdXIgKDQpIFNJTU0vRElN TSBwYWNrYWdlczsgZWFjaCBwcm92aWRpbmcgNjRLIFggMzYgDQlhbmQgaXMgYWxsb2NhdGVkIGZv ciBlYWNoIG9mIHRoZSAxMjggVVNFUlMgYXMgZm9sbG93czoNNEsgQnl0ZXMgliBEaXNwbGF5IE1l bW9yeQ0xMksgQnl0ZXMgliBBcHBsaWNhdGlvbiBQcm9ncmFtIGFuZCBMb2NhbCBNMk0gUmVnaXN0 ZXJzDQ1UaGUgcHJvY2Vzc29yKHMpIEdsb2JhbCBNZW1vcnkgaXMgVHdvLVBvcnQgd2hlcmU6DQlQ b3J0IDEgPSBGQkMgICBGcm9tL1RvIExhbmd1YWdlIFByb2Nlc3NvciBMb2NhbCBNZW1vcnkNCVBv cnQgMiA9IEZCQyAgIEZyb20vVG8gUGVyaXBoZXJhbCBQcm9jZXNzb3IgTG9jYWwgTWVtb3J5DVN5 c3RlbSBQcm9ncmFtbWVycyB3aWxsIGFsbG9jYXRlIGFuIGFyZWEgb2YgdGhpcyBtZW1vcnkgZm9y DUludGVyLXByb2Nlc3NvciBtYWlsLWJveC4gIEFuIGludGVyLXByb2Nlc3NvciBJbnRlcnJ1cHQg aXMgcHJvdmlkZWQNDA0JQSBTeXN0ZW0gQ1JUIE1vbml0b3Igd2l0aCBLZXlib2FyZCBpcyBwcm92 aWRlZCBwcmltYXJpbHkgZm9yIERlYnVnZ2luZyBTeXN0ZW0NU29mdHdhcmUgb2YgZWl0aGVyIHBy b2Nlc3Nvci4gIEEgQ29udHJvbCBQYW5lbCBpcyBhbHNvIHByb3ZpZGVkIGZvciBTaW5nbGUgliBT dGVwcGluZyB0aHJ1IGENUHJvZ3JhbS4gIFRoZSBwcm9jZXNzb3JzIGFyZSBzd2l0Y2ggc2VsZWN0 YWJsZS4gVGhlIFByb2dyYW1tZXIgY2FuIG1vZGlmeSBlaXRoZXIgUHJvZ3JhbSBNZW1vcnkgb3Ig TG9jYWwgTWVtb3J5IGFzIG5lY2Vzc2FyeS4gVGhlIEVuZC1JdGVtIEhhcmR3YXJlIHdpbGwgTk9U IGhhdmUgdGhpcyBjYXBhYmlsaXR5Lg1BcyBhIHJlc3VsdCCWIGl0IGlzIElNUE9TU0lCTEUgZm9y IFZJUlVTIHRvIGVudGVyIHRoZSBzeXN0ZW0uDQ01LiAgU1lTVEVNIFNPRlRXQVJFDQ0JQXMgcHJl dmlvdXNseSBzdGF0ZWQ7IHRoZSBPcGVyYXRpbmcgU3lzdGVtIGNvbnNpc3RzIG9mIDksOTY3IElu c3RydWN0aW9ucyBpbmNsdWRpbmcgSGFyZA1EaXNrIG9wZXJhdGlvbnMgZm9yIHN0b3JhZ2UvcmV0 cmlldmFsIG9mIGRhdGEgYW5kIEFwcGxpY2F0aW9uIFByb2dyYW1zLiAgVGhpcyBmdW5jdGlvbiBp cyByZW1vdmVkDWZyb20gdGhlIExhbmd1YWdlIFByb2Nlc3NvciBhbmQgYWxsb2NhdGVkIHRvIHRo ZSBQZXJpcGhlcmFsIHNpZGUgd2hpY2ggaW5jbHVkZXMgRGlyZWN0b3J5ICYgRmlsZSBNYWludGVu YW5jZSBmb3IgdGhlIExvY2FsIHN5c3RlbSBhbmQgdXAgdG8gk06UIHN1YnN5c3RlbXMuICBUaGlz IHJlZHVjZXMgdGhlIGluc3RydWN0aW9uIGNvdW50IHRvIGFwcHJveGltYXRlbHkgOSwwMDAuICBU aGlzIGlzIEZVTExZIE9wdGltaXplZCBIYW5kIENvZGluZyB1c2luZyBhIFByb2dyYW0gQXNzZW1i bGVyIJYgbm90IGEgQ29tcGlsZXIuICBUaGUgc3lzdGVtIHByb2dyYW1tZXIgaXMgVE9UQUxMWSBv YmxpdmlvdXMgdGhhdCB0aGUgbWFjaGluZSBkb2VzIG9yIGRvZXMgbm90IGVtcGxveSBQaXBlbGlu ZSBkZXNpZ24uICBPbmNlIHRoZSBTeXN0ZW0gUHJvZ3JhbW1lciBpcyBmdWxseSBzYXRpc2ZpZWQg d2l0aCBoaXMgZGVzaWduIJYgdGhpcyBwZXJzb24sIGluIGFzc29jaWF0aW9uIHdpdGggYSBNaWNy by1Qcm9ncmFtbWVyIHdpbGwgZnVydGhlciBvcHRpbWl6ZSB0aGUgY29kZSB1c2luZyB0aGUgZnVs bCBjYXBhYmlsaXRpZXMgb2YgdGhlIEVSSU4zMiBQcm9jZXNzb3IuDQlUbyBmdWxseSBkZWZpbmUg dGhlIGhhcmR3YXJlIHJlcXVpcmVtZW50cyBvZiB0aGUgRVJJTjMyOyB0aGUgZm9sbG93aW5nIElu c3RydWN0aW9uIG1peCBpcyB1c2VkOg0JCUJSQU5DSAkJMTYlDQkJU1RPUkUJCSAgOSUNCQlBUklU SC9MT0dJQwk0NSUNCQlMT0FECQkJMjYlDQkJU0hJRlQJCQkgIDQlDQ0JQW4gYW5hbHlzaXMgb2Yg dGhlIDksOTY3IEluc3RydWN0aW9ucywgd2hpY2ggaXMgYSBnb29kIGJhc2lzIGZvciB0aGVzZSBw ZXJjZW50YWdlcywgc2hvd3MgdGhhdCB0aGV5IGFyZSBhcHByb3hpbWF0ZWx5IGNvcnJlY3QuICBB IGZ1cnRoZXIgYW5hbHlzaXMgd2FzIGFjY29tcGxpc2hlZCwgcmVzdWx0aW5nIGluOg0JCQkJCQkJ UmVkdWNlcyB0bzoNCQlKTVAJCTEzMTgJCQlmdWxseSB0cmFuc3BhcmVudA0JCUpTVAkJICA3NjQJ CQlmdWxseSB0cmFuc3BhcmVudA0JCUxEQS9TVEEJICAzOTAgcGFpcnMJCTM5MA0JCUJSQU5DSAkg IDUwMCBwYWlycwkJNTAwDQkJTERBL0FERAkgIDExNiBwYWlycwkJMTE2DQkJTERBL1NVQgkgICAg ODYgcGFpcnMJCSAgODYNCQlMREEvQU5BCSAgMTQ4IHBhaXJzCQkxNDgNCQlMREEvRVJBCSAgICAz NiBwYWlycwkJICAzNg0JCUxEQS9BT0EJICAgIDE2IHBhaXJzCQkgIDE2DQkJTERBL0NNQQkgICAg ICA4IHBhaXJzCQkgICAgOA0JCUxEQS9UQ0EJICAgIDEwIHBhaXJzCQkgIDEwDQkJTERBL0NBUwkg ICAgNzQgcGFpcnMJCSAgNzQNDA0JCUxEQS9JTUEJICAgIDIyIHBhaXJzCQkgIDIyDQkJTERBL0xH UgkgICAgMTMgcGFpcnMJCSAgMTMNCQlMREEvQVJSCSAgICAgIDMgcGFpcnMJCSAgICAzDQkJTERB L0xHTAkgICAgMTUgcGFpcnMJCSAgMTUNCQlMREEvQUxTCSAgICAgIDMgcGFpcnMJCSAgICAzDQkJ TERBL0FSUwkgICAgICAxIHBhaXIJCSAgICAxDQkJTERBL0FMUgkgICAgICAyIHBhaXJzCQkgICAg Mg0NCQkJCVRvdGFsIFJlZHVjdGlvbgkxNDQxDQkJCQlUb3RhbCBJbnN0IGFmdGVyCQk3NTU5DQ1P dGhlciByZWR1Y3Rpb25zIGNhbiBhbmQgd2lsbCBiZSBtYWRlIHdoZXJlIDc1MDAgaXMgYSBnb29k IG51bWJlciBmb3IgY29udmVyc2F0aW9uLiAgV2h5IGNvbmNlbnRyYXRlIGluIHRoaXMgYXJlYT8/ ICBGb3IgZnV0dXJlIFJlc2VhcmNoIHdpdGggcG9zc2libGUgQVNJQyBhcHBsaWNhdGlvbi4NDTYu IFRIRSBQUk9DRVNTT1INDQlUaGUgRW5kLUl0ZW0gUHJvY2Vzc29yIGlzIGEgUXVpY2tsb2dpYyBD b3Jwb3JhdGlvbiBRTDY1MDAgRlBHQSwgNTE2IFBpbiBkZXZpY2UNb2YgdGhlIEVjbGlwc2UgRmFt aWx5LiAgVGhlIGRldmVsb3BtZW50IHNvZnR3YXJlIGZvciB0aGlzIGZhbWlseSBpcyBjdXJyZW50 bHkgaW4gQmV0YSBUZXN0aW5nLg1JdHMgY2FwYWJpbGl0eSBpczoNCQkJTWF4IEdhdGVzCSA9IDQ4 OCwwNjQNCQkJTG9naWMgQ2VsbHMJID0gMzA3Mg0JCQlNYXggRkaScyAJID0gNzQ4OA0JCQlNYXgg SS9PICAJID0gNDQ4IHBpbnMNCQkJUmFtIE1vZHVsZXMJID0gMzIgdW51c2VkDQkJCVBhY2thZ2UJ ID0gQkdBDQkJCVBMTAkJID0gNCwgd2l0aCAxeCwyeCw0eA0JCQlETEwNCQkJR2xvYmFsIENsb2Nr IE5ldHMgPSA5DQlUaGUgcHJpbWFyeSByZWFzb24gZm9yIHNlbGVjdGluZyB0aGlzIGRldmljZSBp cyBJL08gcGlucyB3aGVyZSBJIHJlcXVpcmUgMzk1OyBub3QgYmVjYXVzZSBJIGFtIGxvZ2ljIGxp bWl0ZWQuICBJbiBvcmRlciB0byBvYnRhaW4gYSByZWFzb25hYmx5IGNsb3NlIHZpZXcgb2YgdGhl IGRlc2lnbiwgSSByZW1vdmVkIHRoZSBGQkMgbG9naWMgYW5kIHRoZSBhc3NvY2lhdGVkIHBpbnMg YW5kIHdlbnQgdGhydSBQTEFDRSAmIFJPVVRFIHVzaW5nIGEgUUwzMDYwLTQgd2l0aCB0aGUgZm9s bG93aW5nIHJlc3VsdHM6DQkJTG9naWMgQ2VsbHMJCTEzMTcgb2YgMTU4NA0JCUNsb2NrIE9ubHkg Q2VsbHMJMyBvZiA4DQkJRkaScwkJCTg3Mw0JCUJpLURpcmVjdGlvbmFsIENlbGxzCTMwOCBvZiAz MDgNCQlSb3V0aW5nIFJlc291cmNlcwkzODAzOCBvZiAxMDI5MTYgKHdpcmVzKQ0JCQkJCVRoaXMg aXMgd2hlcmUgZGVsYXlzIGFyZSBpbnZvbHZlZCBpbiBhZGRpdGlvbiB0byBnYXRlDQkJCQkJZGVs YXlzIGFzIGEgZnVuY3Rpb24gb2YgTE9BRElORy4gIEFsbCBsb2FkaW5nIGlzIGhlbGQNCQkJCQli eSBkZXNpZ24gdG8gYSBtYXhpbXVtIG9mIDguIEhlcmUgdGhlIHRlcm0gZmFuLW91dCBoYXMNCQkJ CQl0aGUgc2FtZSBtZWFuaW5nLg0JCVZpYUxpbmsgUmVzb3VyY2VzCTMzMTAwIG9mIDI3NjIyOTAg KGZ1c2UgbGlua3MpDQlEZWxheXMgdGhhdCBhZmZlY3QgdGhlIGRlc2lnbiBleHRlcm5hbCB0byB0 aGUgZGV2aWNlIGFyZSBiYXNlZCBvbiB0aGVzZSBhc3N1bXB0aW9ucy4gIFNSQU0gYWNjZXNzID0g NU5TLCAgYWRkcmVzcyBzZXQtdXAgPSA1bnMgZnJvbSBJL08gcGluIHRvIFJBTSBwaW4uLCAgUkFN IGRhdGEgdG8gaW5wdXQgcGluDT0gNU5TLiAgVGhlc2UgYXJlIGNpcmN1aXQgYm9hcmQgZGVsYXlz Lg0JVGhlIFByb2Nlc3NpbmcgRWxlbWVudHMgKFBFknMpIGFuZCBFeGVjdXRpb24gVW5pdHMgKEVV knMpIGluY2x1ZGUgdGhlIGZpcnN0IGxldmVsIG9mIFBpcGVsaW5lIHdoZXJlIG5lY2Vzc2FyeS4g IEVhY2ggY29udGFpbiB0aGVpciBTdGF0ZSBMb2dpYyBUaW1pbmcsIFNjb3JlYm9hcmQsIFdhaXQg TG9naWMgZm9yDW9wZXJhdGlvbnMgcmVxdWlyaW5nIHJlc3VsdHMgb2YgcHJldmlvdXMgaW5zdHJ1 Y3Rpb24gJiBhIE11bHRpcGxleGVyIFN0ZWVyaW5nIG91dHB1dC4gSW4gdGhlc2UgZGVzaWducyB5 b3Ugd2lsbCBzZWUgZGlmZmVyZW50IG1ldGhvZHMgb2YgbG9hZGluZyBkaXN0cmlidXRpb24gdGVj aG5pcXVlcyBhcyBkZXNjcmliZWQgaW4gdGhlIFF1aWNrbG9naWMgTWFudWFsLiAgRWFjaCBQRSBo YXMgYmVlbiBGVUxMWSBoYW5kIGxvZ2ljIG9wdGltaXplZCCWIGl0IGlzIGZ1cnRoZXIgb3B0aW1p emVkIGluIHRoZSBDSElQIGdlbmVyYXRpb24gcHJvY2VzcyB3aGljaCBtb2RpZmllcyB5b3VyIHJl cXVlc3RlZCBmdW5jdGlvbiB0byB0aGF0IG9mIHRoZSBMb2dpYyBDZWxsIHN0cnVjdHVyZS4gIEEg cHJpbnQtb3V0IGlzIGF2YWlsYWJsZSBvZiB0aGUgYWZmZWN0ZWQgYXJlYXMuICBBbGwgZGVzaWdu IHVzZXMgU0NIRU1BVElDIGlucHV0DU9OTFkuICBUaGVyZSB3aWxsIG5vdCBiZSBhbnkgVkhETCBz b3VyY2UgdXNlZC4gSW4gYW55IG9mIG91ciBkZXNpZ25zLg0NCUFMMzIJCVRoaXMgRVUgcGVyZm9y bXMgYWxsIG9mIHRoZSByZXF1aXJlZCBBcml0aG1ldGljL0xvZ2ljIGZ1bmN0aW9ucy4gIFRoZXJl IGlzIA0JCQlubyBtYWdpYyBoZXJlIJYgcHVyZSB0ZXh0IGJvb2sgLSBUVEwgIC0gU043NDE4MSBB TFUgd2l0aCB0aGUgU043NDE4Mg11c2VkIGZvciBDYXJyeSBMb29rLUFoZWFkLiAgVHdvIG9mIHRo ZXNlIEVVknMgYXJlIHJlcXVpcmVkIGZvciB0aGUgU2luZ2xlIExldmVsIFBpcGVsaW5lLiBJdCBz YXRpc2ZpZXMgYWxsIGZ1bmN0aW9ucyBvZiBGQzAgYW5kIHdpbGwgcHJvdmlkZSBhZGRpdGlvbmFs IEluc3RydWN0aW9uIGNhcGFiaWxpdHkgdG8gdGhlIEVSSU4zMi4gIE9uZSB0aGluZyB0byBub3Rl DQloZXJlIGlzIEZDMCBpbXBsZW1lbnRhdGlvbiBvZiBTSU1EIJYgd2hpY2ggSSBkb26SdCBzZWUg YXMgYmVpbmcgYQ1uZWNlc3NpdHkuICBJbiBteSBvcGluaW9uIHRoaXMgaXMgdGhlIEludGVsL01v dG9yb2xhL0FNRCBtZXRob2Qgb2YgYmFja3dhcmQgY29tcGF0YWJpbGl0eS4gIEZ1cnRoZXI7IHRo ZSB0aW1lIHRvIGRvIGFuIDgtQml0IEFkZCBpcyBpZGVudGljYWwgdG8gYW4xNi1CaXQgQWRkLiAg QW5kIGEgMzIvNjQtQml0IEFkZCBpcyBvbmx5IE9ORSBhZGRpdGlvbmFsIGxldmVsIG9mIGNhcnJ5 LiBZb3UgYXJlIHVzaW5nIGhlbGx1dmEgbG90IG9mIHNpbGljb24gYXJlYSB0YWtpbmcgeW91ciBz cGVjaWZpZWQgYXBwcm9hY2guICBJIHRyaWVkIGl0IJYgYW5kIGJhY2tlZCBvZmYgYWZ0ZXIgd2Fz dGluZyBhIHdlZWsgb2YgdGltZS4NDUFNVVgJVGhpcyBQRSBpcyBhIHNpbXBsZSBtdWx0aXBsZXhl ciAgdGhhdCByZWNlaXZlcyBpbnB1dCBmcm9tIHRoZSBBTDMyLCB0aGUNCQlCYXJyZWwgU2hpZnRl ciAob25lIGlucHV0IEFTIElTIGF0IHRoZSBvdXRwdXQsIGFuZCBpcyBhbHNvIGJpdCByZXZlcnNl ZCBmb3INCQlSaWdodCBTaGlmdHMpLiAgVHdvIGlucHV0cyBhcmUgZnJvbSB0aGUgTG9hZCBQRSBh bmQgb25lIGZyb20gdGhlIENTVEINCQlFVS4NDUFSRUcJCVRoaXMgUEUgaXMgYSBzaW1wbGUgMzIg Qml0IFJlZ2lzdGVyL0FjY3VtdWxhdG9yLiAgRGF0YSBpbnB1dHMgYXJlIGZyb20gdGhlDUFNVVg7 ICBTaWduIGNvbnRyb2wgYW5kIENsZWFyIGZ1bmN0aW9ucyBhcmUgcmVjZWl2ZWQgZnJvbSB0aGUg VURSUyAob3RoZXJzKSBQRSwgc3VjaCBhcyBQUyAoUHJlc2V0IFNpZ24pLCBSUyAoUmVzZXQgU2ln biksIENsZWFyIHNlbGVjdGVkIEJ5dGUsIGFuZCBDUkEgKENsZWFyIEEtcmVnKS4gIFRoZSBBWiAo QXJlZz1aZXJvKSBvdXRwdXQgaXMgZXNzZW50aWFsbHkgb25lIGJpdCBvZiB0aGUgQ0NSIChDb25k aXRpb24gQ29kZSBSZWdpc3RlcikgdXNlZCBmb3IgQ29uZGl0aW9uYWwgQnJhbmNoLg0NQlJBTglU aGlzIEVVIGNvbnRhaW5zIGEgMTYgQml0IEluc3RydWN0aW9uIFJlZ2lzdGVyIG9mIHRoZSB0eXBl IG9mIEJyYW5jaCB0aGUgUHJvZ3JhbW1lciB3YW50cyB0byBleGVjdXRlLiAgSGUgbWF5IHNlbGVj dCBvbmUgb3IgbW9yZSBDb25kaXRpb25zLiBUaGVyZSBpcyBhIDE2IEJpdCBPUiBnYXRlIHdob3Nl IG91dHB1dCBpcyBCUkFOLiBUaGlzIG91dHB1dCBpcyBhcHBsaWVkIHRvIHRoZSBWRUNUT1IgRVUu DQ1DQVMJVGhpcyBFVSBwZXJmb3JtcyBhbiBBcml0aG1ldGljIENvbXBhcmUgb2YgdHdvIG9wZXJh bmRzIGFuZCBSZWdpc3RlcnMNCXRoZSByZXN1bHQgIGluIDMgYml0cyBvZiB0aGUgQ0NSLiAgVGhl c2UgYXJlIEFMQiwgQUdCLCBhbmQgRVFVLiAgVGhlDQlkZXNpZ24gdXNlcyB0aGUgVFRMIFNONzQx ODUgYXMgYnVpbGRpbmcgYmxvY2suICBQdXJlIHRleHRib29rIGRlc2lnbi4NDUNTVEIJVGhpcyBp cyBhIGNsYXNzaWNhbCBEYXRhIFNlbGVjdG9yL011bHRpcGxleGVyIGRlc2lnbiB0aGF0IHBlcmZv cm1zIHRoZSBDbGVhciBCaXQsIFNldCBCaXQgYW5kIFRlc3QgQml0IEluc3RydWN0aW9ucyBhbmQg aXMgYmFzZWQgb24gVFRMIFNONzQxNTAuIFRoZSBUU1Qgb3V0cHV0IGlzIGFwcGxpZWQgdG8gdGhl IEJSQU4gRVUuICBUaGUgRGF0YSBPdXRwdXRzIGFyZSBhcHBsaWVkIHRvIHRoZSBBTVVYLg0MSU5E RVgJVGhlIGRlc2lnbiB1c2VzIHRocmVlICgzKSBvZiB0aGVzZSBFVZJzLiAgVGhleSBlZmZlY3Rp dmVseSBpbXBsZW1lbnQgdGhlDQlIYXJ2YXJkIEFyY2hpdGVjdHVyZSBjaG9zZW4uICBIZXJlOyB0 aGUgUHJvZ3JhbW1lciBoYXMgbWFueSBPcHRpb25zLg0JVGhlIEEtU291cmNlIGFuZCBCLVNvdXJj ZSBJbmRleCBSZWdpc3RlciAod2l0aCBJbmNyZW1lbnQgY2FwYWJpbGl0eSkNCWFyZSBhcHBsaWVk IHRvIFNSQU0gUmVhZCBPbmx5IFBvcnRzIGFzIHByZXZpb3VzbHkgZGVzY3JpYmVkLiBUaGlzDQlz b3VyY2UgbWF5IGJlIGFueSBjb21iaW5hdGlvbiBDb21tb24gRGF0YSBQb29sIGFuZCBVU0VSIHNs b3QuDQlUaGUgRGVzdGluYXRpb24gKFdyaXRlKSBJbmRleCBSZWdpc3RlciBoYXMgdGhlIHNhbWUg dmFyaWFibGUgYXZhaWxhYmxlLg0JVGhleSBtYXkgYmUgcmFuZG9tbHkgSW5jcmVtZW50ZWQgb3Ig TG9hZGVkIG9uZSwgdHdvLCBvciBhbGwgdGhyZWUgc2VsZWN0aXZlbHkuICBUaGUgk1iUIG91dHB1 dCBpcyBhcHBsaWVkIHRvIHRoZSBTdG9yZSBFVS4NDUlSUwlJbmNyZW1lbnQsIFJlcGxhY2UgKFN0 b3JlKSAmIFNraXAgaWYgWmVybyA9IEREUC01MTYuICBJbmNyZW1lbnQsIFJlcGxhY2UgJiBSZWdp c3RlciByZXN1bHQgPSBFUklOMzIuICBUaGlzIGlzIG9uZSBiaXQgb2YgdGhlIENDUiBhbmQgdXNl cw0JdGhlIHRlcm0gTlouICBUaGlzIGRlc2lnbiB1c2VzIGEgMzIgQml0IEluY3JlbWVudGVyIHdo ZXJlIHRoZSBJTkRFWCBFVQ0JdXNlcyBhIDIwIGJpdCBJbmNyZW1lbnRlci4gIFRoZSBOWiBvdXRw dXQgaXMgYXBwbGllZCB0byB0aGUgQlJBTiBFVS4NCVRoZSBJbmNyZW1lbnRlZCB2YWx1ZSBpcyBh cHBsaWVkIHRvIHRoZSBTVE9SRSBFVS4uICBUd28gb2YgdGhlc2UgRVWScw0JYXJlIHJlcXVpcmVk IGZvciB0aGUgU2luZ2xlIExldmVsIFBpcGVsaW5lIHRoYXQgaXMgaW1wbGVtZW50ZWQuDQ1MT0FE CVRoaXMgRVUgIHJlY2VpdmVzIERhdGEgZnJvbSBhIFJlYWQgT25seSBQb3J0IGFuZCBzZXJ2aWNl cyB0aGUgTERBDQkoTG9hZCBBY2N1bXVsYXRvcikgYW5kIExEQiAoTG9hZCBTZWxlY3RlZCBCeXRl IGluIFNlbGVjdGVkIEJ5dGUNCVBvc2l0aW9uKSwgd2l0aCBvciB3aXRob3V0IGJpdCA4IElOSCAo SW5oaWJpdCkgSW5zdHJ1Y3Rpb25zLiBCaXQgOCBpcyBkZWZpbmVkIGFzIHRoZSBDVVJTT1IgQklU LCAgd2hlcmUgU29mdHdhcmUgaXMgcHJpbWFyaWx5IGludGVyZXN0ZWQgaW4gdGhlIHJlbWFpbmlu ZyBBU0NJSSBDaGFyYWN0ZXIsIElOSCBpcyBzcGVjaWZpZWQuICBUaGUgb25seSBleGNlcHRpb24g dG8gdGhpcw0JaXMgdGhlIG5vcm1hbCBDUlQgRWRpdCBwcm9jZXNzLiAgV2hlcmUgdHlwaW5nIHNh eXMgliBlbnRlciB0aGUgcmVxdWlyZWQNCWNoYXJhY3RlciBhbmQgU3RlcCB0aGUgQ3Vyc29yLiAg VGhpcyBjYW4gYmUgZG9uZSB3aXRoIHRoZSBTRVRCIChTZXQgQml0KSBJbnN0cnVjdGlvbi4NDVNU T1JFCVRoaXMgRVUgcmVjZWl2ZXMgc2VsZWN0ZWQgaW5wdXRzIGJhc2VkIG9uIGV4ZWN1dGlvbiBv ZiAgU1RBIChTdG9yZQ0JQWNjdW11bGF0b3IpLCBTVEIgKFN0b3JlIFNlbGVjdGVkIEJ5dGUgaW4g dGhlIFNlbGVjdGVkIEJ5dGUgUG9zaXRpb24sIHdpdGggb3Igd2l0aG91dCBJTkgpLCBTVFggKFN0 b3JlIFNlbGVjdGVkIEluZGV4KSwgSVJTLCBBTFUsIG9yIFNoaWZ0Lg0JVGhlIGRlc2lnbiBjdXJy ZW50bHkgdXNlcyBhIFNpbmdsZSBMZXZlbCBQaXBlbGluZTsgaG93ZXZlcjsgdGhpcyB3aWxsIGhh dmUgdG8gaW5jcmVhc2UgdG8gcHJvcGVybHkgbWF0Y2ggU1RPUkUgcmVxdWVzdHMgKFF1ZXVlKSB0 byB0aGUgc3BlZWQgb2YgdGhlDQlTUkFNLiAgQSBMb2dpYyBFUlJPUiBpZiB5b3UgbGlrZSB0aGUg dGVybSCWIEkgZG8uDQ1VRFJTCShPdGhlcnMpICBUaGlzIEVVIGNvbnNpc3RzIGVudGlyZWx5IG9m IEluc3RydWN0aW9ucyBpbiB0aGUgQ29udHJvbCBjYXRlZ29yeS4NCVN1Y2ggYXMgQ1JBLCBTU00g KFNldCBTaWduIE1pbnVzKSwgU1NQIChTZXQgU2lnbiBQbHVzKSwgQ01BIChDb21wbGVtZW50IFNp Z24gb2YgQXJlZykuICBJdCBjb250YWlucyB0aGUgQ0ZGIHdoaWNoIGlzIG9uZSBCaXQgb2YgdGhl IENDUi4gIEl0IG1heSBiZSBjb250cm9sbGVkIHdpdGggU0NCIChTZXQgQy1iaXQpLCBhbmQgUkNC IChSZXNldCBDLWJpdCkNCUluc3RydWN0aW9ucy4gIE90aGVyIGNvbnRyb2wgb2YgdGhlIENGRiBp cyB0aGUgcmVzdWx0IG9mIFNoaWZ0IEluc3RydWN0aW9ucy4NDVZFQ1RPUglUaGlzIEVVIHJlY2Vp dmVzIEpNUCBVbmNvbmRpdGlvbmFsIEp1bXApLCBKU1QgKEp1bXAgYW5kIFN0b3JlUmV0dXJuKSwg QlJBIChDb25kaXRpb25hbCBCcmFuY2gpICBhbmQgUlROIChKdW1wIEluZGlyZWN0KSBmcm9tIFBv cnQgMiBvZiBJbnN0cnVjdGlvbiBNZW1vcnkuICBUaGUgRU5CIChFbmFibGUgSW50ZXJydXB0cyks IElOSCAoSW5oaWJpdCBJbnRlcnJ1cHRzKSBJbnN0cnVjdGlvbnMgYXJlIHJlY2VpdmVkIGZyb20g UG9ydCAxLiAgSGVyZSBJIHVzZSB0aGUgdGVybSBWZWN0b3IsIHdoZXJlIHRoZSBuZXh0IEluc3Ry dWN0aW9uIGlzIFBDKzEgb3IgZ28gd2hlcmUgVmVjdG9yZWQuICBBdCBIb25leXdlbGwgd2UgY2Fs bGVkIHRoaXMgk1NwbGF0dGVylC4gIFRoZXJlIGlzIHByb3Zpc2lvbiBmb3IgZWlnaHQgKDgpDQlW ZWN0b3JlZCBJbnRlcnJ1cHRzLCB3aGVyZSA4IGlzIHRoZSBoaWdoZXN0IGxldmVsLiAgVGhlIGhp Z2hlc3QgTGV2ZWwgaXMgYXNzaWduZWQgdG8gSW50ZXItUHJvY2Vzc29yIEludGVycnVwdCwgdGhl biA3IGlzIEZCQyBUZXJtaW5hdGlvbiBJbnRlcnJ1cHQsDQlUaGUgcmVtYWluZGVyIGFyZSBhc3Np Z25lZCB0byBQZXJpcGhlcmFsIERldmljZXMgZGVwZW5kaW5nIG9uIHRoZSBQcm9jZXNzb3IgYXBw bGljYXRpb24sIGkuZS4sIExhbmd1YWdlIG9yIFBlcmlwaGVyYWwuICBUaGVzZSBtYXkgY2hhbmdl IGFmdGVyIGRpc2N1c3Npbmcgd2l0aCBTb2Z0d2FyZSBndXJ1knMuICBBIFRUTCBTTjc0MTQ4IGlz IHVzZWQgYXMgdGhlIFByaW9yaXR5IEVuY29kZXIuICBGdXJ0aGVyIHRpbWluZyBhbmFseXNpcyBt YXkgcmVxdWlyZSBJIExvb2stQWhlYWQNCXR3byByYXRoZXIgdGhhbiB0aGUgY3VycmVudCBvbmUu IFRoaXMgaXMgZHVlIHRvIHRoZSBjbG9jayB0byBvdXQgb2YgYQ0JSktGRiwgb25lIGZvdXIgaW5w dXQgZ2F0ZSBhbmQgdGhlIHRyYW5zaXRpb24gdGltZSBvZiBCaS1EaXJlY3Rpb25hbA0JSS9PIFBh ZC4gIEkgc2hvdWxkIG5vdGUgdGhhdCB0aGUgZGVzaWduIGRvZXMgaGF2ZSBhIEhMVCAoSGFsdCkN CUluc3RydWN0aW9uIGFzIGRvZXMgdGhlIEREUC01MTYgliBob3dldmVyIHRoZSA1MTYgdmlydHVh bGx5IGNhbWUgdG8gYSBIQUxULiAgQ3VycmVudGx5OyBTeXN0ZW0gU29mdHdhcmUgaXMgaW4gYSBj b250aW51b3VzIGxvb3AgaW4gdGhlDQlTa2VkdWxhciBSb3V0aW5lIGxvb2tpbmcgZm9yIHNvbWV0 aGluZyB0byBkby4gVGhpcyB3aWxsIENIQU5HRS4NCVRoZSByb3V0aW5lIHdpbGwgbWFrZSBhIHNp bmdsZSBwYXNzLCBhbmQgaWYgVW4tSW50ZXJydXB0ZWQgd2lsbCBleGVjdXRlDQlBIEhMVC4gIEkg aGF2ZSBtYWRlIHByb3Zpc2lvbiBmb3IgSW50ZXJydXB0IGZyb20gSEFMVC4gIFRoaXMgYWxzbw0J QXBwbGllcyB0byB0aGUgUGVyaXBoZXJhbCBQcm9jZXNzb3IuDQ1XQURFCVRoaXMgRVUgaXMgbmFt ZWQgZm9yIG15IEdyYW5kc29uIFdhZGUuICBUaGlzIHdhcyBhIGZ1biBkZXNpZ24gYW5kDQl0aGUg bGl0dGxlIGZlbGxvdyBpcyBGVU4uICBJVCBpcyBtb3JlIGFwcHJvcHJpYXRlbHkgY2FsbGVkIFNI SUZULiAgVGhlDQlkZXNpZ24gaXMgYmFzZWQgb24gdGhlIFRUTCBBTTI1UzEwIChBTUQpLCA3NEYz NTAgKEZhaXJjaGlsZCkgb3INCVNONzRTMzUwIChUSSkuICBBbGwgdGhyZWUgc291cmNlcyBwcm92 aWRlZCBleGNlbGxlbnQgQXBwbGljYXRpb24gRGF0YQ0JU2hlZXRzLiAgVGhlIG1ldGhvZCBJIGNo b3NlIHdhcyB0byBoYXJkLXdpcmUgYSBTaGlmdCBMZWZ0LiAgUmlnaHQgU2hpZnRzDQlhcmUgQml0 IFJldmVyc2VkIHByaW9yIHRvIGFwcGxpY2F0aW9uIHRvIHRoZSBhcnJheS4gIFRoaXMgcmV2ZXJz YWwgaXMgYXBwbGllZCB0byB0aGUgQU1VWCB3aGVyZSBpdCBpcyByZXZlcnNlZCBmb3IgdGhlIGNv cnJlY3QgdmFsdWUuICBUaGUgRU5ETA0JKEVuZCBMb2dpYykgcHJvdmlkZXMgdGhlIG5lY2Vzc2Fy eSBpbnB1dCBkZXBlbmRpbmcgb24gdGhlIHR5cGUgb2Ygc2hpZnQuDQlUaGUgRlVOIHBhcnQgd2Fz IEhPVyB0byBhY2NvbXBsaXNoIHRoZSBBTFMgKEFyaXRobWV0aWMgU2hpZnQgTGVmdCkNCXdoaWNo IGlzIHJlcXVpcmVkIHRvIHNldCB0aGUgQ0ZGIGZvciBhIGNoYW5nZSBpbiBTaWduIHJlc3VsdGlu ZyBmcm9tIHRoZSBTaGlmdC4gIFRoaXMgaXMgbmVjZXNzYXJ5IHRvIG1haW50YWluIEFyaXRobWV0 aWMgY29ycmVjdG5lc3MuICBJIGNob3NlIHRvDQlkbyBhbiB1bi1yZWdpc3RlcmVkIE5vcm1hbGl6 ZSAoU2hpZnQgTGVmdCB0aWxsIHR3byBNU0KScyBub3QgRXF1YWwuKS4NCVRoaXMgaXMgYWNjb21w bGlzaGVkIGJ5IFhPUiBvZiB0aGUgU2lnbiBhZ2FpbnN0IGVhY2ggQml0OyAgYXBwbHkgdGhpcyB0 byBhDQlQcmlvcml0eSBFbmNvZGVyIChTTjc0MTQ4KTsgIGVuY29kZSB0aGUgb3V0cHV0cyBvZiB0 aGUgMTQ4knMgYW5kIGRvIGENCUxvZ2ljYWwgQ29tcGFyZSAoU043NDE4NSkgb2YgdGhlIHJlcXVl c3RlZCBTaGlmdCBhbW91bnQgd2l0aCBFbmNvZGVkDQlWYWx1ZSCWIGlmIEVxdWFsIHRvIG9yIExl c3MgVGhhbiCWIGNsZWFyIENGRiwgaWYgR3JlYXRlciCWIHNldCBDRkYuICBNYXkNCW5vdCBiZSB0 aGUgb25seSBzb2x1dGlvbiwgYnV0IGZvciBhbiBhcnJheSBzaGlmdGVyLCBJkm0gb3BlbiBmb3Ig b3RoZXIgZGVzaWduDQlhcHByb2FjaGVzLiAgVHdvIG9mIHRoZXNlIEVVknMgYXJlIHJlcXVpcmVk IGZvciBhIFNpbmdsZSBMZXZlbCBQaXBlbGluZS4NCQ0JDQ0JCQ0NDQ0NDQ0NCQkgDQkNCQ0NDQ0N DQ0NCQ0NCQ0JCQ0JDQkNCQkgIA0JCSAgDQ0NE1BBR0UgIBUNDQ0TUEFHRSAgFDEwFQ0NDQ0NAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAAABBAAAAwQAADQEAABpBAAAawQAAM4EAADPBAAACAUAABgFAABU CgAAWgoAAIIKAACVCgAACwsAABoLAADtTAAA7kwAAPRMAAD1TAAA9kwAAPhMAAD5TAAA/0wAAABN AAACTQAAA00AAARNAAAITQAA+gD6APgA9ADxAPQA9AD0AOrn6ucA6ufq3+rnAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADzBKEABtSAAEbkgABHUIAQQwShAAAA0DagAAAAAwShAAVQgBBENKIAAABjUIgVwIgQAD SCoBCjUIgUNKJABcCIEcAAQAAAEEAAACBAAAAwQAADQEAABcBAAAcwQAAJoEAACbBAAAnAQAAK8E AADOBAAAzwQAANAEAADRBAAA0gQAANMEAADUBAAA1QQAANYEAADXBAAA2AQAANkEAADaBAAA6gQA AOsEAADsBAAA7QQAAO4EAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAA AAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAEDAAAEAAADJAFhJAEAAQAA AAUBAA6E5P1dhOT9ABwABAAA7UwAAAdNAAD9/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQEAAEBAu4EAADvBAAA8AQAAPEEAADyBAAA8wQAAPQEAAD1BAAA9gQAAPcEAAD4BAAA +QQAAPoEAAD7BAAABwUAABgFAAAZBQAAGgUAACoFAABzBQAApgUAAKcFAADxBQAAQwYAAJEGAADf BgAALwcAAIgHAADZBwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAQAAAMkAWEkAQAc2QcAACkIAAB7CAAAjggAAI8IAADcCAAAJAkAAHgJAADoCwAA6QsAACwNAAAt DQAAIw4AAHcOAAAlDwAAhg8AANUPAADxDwAA8g8AADsQAAB2EAAAdxAAAAoRAAA+EQAAPxEAAPER AAAOEgAADxIAACsSAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAD4TQ Al6E0AIAAQAAABwrEgAALBIAAKATAAChEwAAwRMAAAAUAAAsFAAAVRQAAIsUAADSFAAAExUAABUV AABsFQAAFxYAABgWAADYFgAA2RYAAC8XAAB7FwAAfRcAAJkXAACaFwAArRgAAK4ZAACvGQAA4xkA AAAaAABIGgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAA AAAAAADsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAABGE0AJghNACAAUAAA+ECAdehAgHBQAACiYA C0YDAAABAAAAG0gaAACJGgAA1BoAAA4bAAAiGwAANRsAAHcbAAChGwAAohsAAOsbAAAUHAAAPRwA AGkcAACQHAAAqxwAAM0cAAAYHQAAYR0AALEdAADyHQAA8x0AAPQdAAA1HgAAbR4AAIceAAC/HgAA wB4AAPIeAAAqHwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAQAABQAACiYAC0YEAAAFAAAR hNACYITQAgAcKh8AAGQfAACgHwAA5B8AAOYfAAA1IAAAkiAAAEUhAACDIQAAhCEAAJghAACZIQAA 8yEAAFUiAACtJAAADiUAABwlAAAqJQAAPCUAAEklAABYJQAAWSUAAA0mAAAgJgAAQCYAAGEmAAB8 JgAAliYAALEmAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAUAABGE 0AJghNACAByxJgAAziYAAOkmAAAGJwAAIycAAEInAABfJwAAfCcAAH4nAACbJwAAuCcAANcnAAD0 JwAAEygAADEoAABQKAAAUSgAAGooAACFKAAAhigAAC8pAAAwKQAAQSkAAEIpAACSKQAA8SkAAAQq AAAcKgAAMyoAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAPhNACXoTQ AgABAAAAHDMqAABIKgAAYSoAAH0qAACPKgAAqyoAALIqAADLKgAA7isAAAosAAAkLAAAMSwAAFMs AAB/LAAAuiwAAPUsAAAxLQAASC0AAHotAAArLgAAUy4AAAYvAADaMAAAIDEAACExAAB0MQAAvDEA AI0yAADQMgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAUAAA+EoAVehKAFAAUAAA+EcAhehHAI AAEAAAAc0DIAADA0AAAxNAAAfjQAAMw0AAAUNQAAGjUAABs1AABsNQAAhzYAAIg2AABzNwAAdDcA AL03AAADOAAASjgAAEs4AAA2OQAAhjkAAMw5AAASOgAAVToAAJQ6AADdOgAAWTsAAFo7AADoOwAA MDwAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAA AAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA 6QAAAAAAAAAAAAAAAAAAAAAJAAAPhHAIEYRg+l6EcAhghGD6AAUAABGE0AJghNACAAUAAA+EcAhe hHAIABswPAAAdjwAAL08AAD+PAAA/zwAAEY9AACHPQAAYT4AAKo+AAABPwAAAj8AAEs/AADYPwAA bUAAAKBAAAChQAAA80AAAL9BAAANQgAADkIAAK9DAABFRAAAWEUAAJ9FAADkRQAAJEYAAKxGAADt RgAANkcAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAAAAAAAREAAAkAAA+EcAgRhGD6XoRwCGCE YPoAHDZHAAB5RwAAn0cAAKBHAADnRwAAL0gAAHBIAAC3SAAAAUkAAJJJAADcSQAAIEoAALRKAAD7 SgAAR0sAAI5LAADUSwAAHkwAAG1MAAC3TAAAuUwAALtMAAC8TAAAv0wAAMBMAADBTAAAwkwAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAABQAAD4RwCF6EcAgABQAAEYTQAmCE0AIACQAAD4RwCBGEYPpehHAIYIRg +gAawkwAAMNMAADETAAAxUwAAMZMAADKTAAAzEwAAM5MAADPTAAA0EwAANFMAADSTAAA00wAANRM AADVTAAA10wAANhMAADaTAAA3UwAAN9MAADhTAAA5kwAAOtMAADsTAAA7UwAAPZMAAD3TAAA+QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABDwAACA8AGIT8/xmEAQAbJmAjJAIABQAAEYTQAmCE0AIAAQAAAAUAAA+EcAhehHAI ABr3TAAA+EwAAARNAAAFTQAABk0AAAdNAAAITQAA/QAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAIDwAYhPz/GYQBABsmYCMkAgABAAAA BiAAMZBoAR+w0C8gsOA9IbCgBSKwOAQjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FAASAAoAAQBpAA8AAwAAAAAAAAAAADgAAEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABD ShgAX0gBBGFKGABtSAkEc0gJBHRICQQyAAFAAQACADIADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAA CAABAAYkAUAmAAYANQiBXAiBOAACAAEAAgA4AAwACQBIAGUAYQBkAGkAbgBnACAAMgAAAA4AAgAD JAEGJAFAJgFhJAEGADUIgVwIgTYAA0ABAAIANgAMAAkASABlAGEAZABpAG4AZwAgADMAAAAOAAMA AyQBBiQBQCYCYSQBBABDSiQAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0 ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAACwAIEABAPIALAAMAAYA RgBvAG8AdABlAHIAAAANAA8ADcYIAALgEMAhAQIAAAAmAClAogABASYADAALAFAAYQBnAGUAIABO AHUAbQBiAGUAcgAAAAAARABDQAEAEgFEAAwAEABCAG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUA bgB0AAAAEgARAA+EcAgRhKz5XoRwCGCErPkAAAAAAAAISQAABAAAbgAAAAD/////AAAAAAEAAAAC AAAAAwAAADQAAABcAAAAcwAAAJoAAACbAAAAnAAAAK8AAADOAAAAzwAAANAAAADRAAAA0gAAANMA AADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAA APEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAABwEAABgBAAAZAQAA GgEAACoBAABzAQAApgEAAKcBAADxAQAAQwIAAJECAADfAgAALwMAAIgDAADZAwAAKQQAAHsEAACO BAAAjwQAANwEAAAkBQAAeAUAAOgHAADpBwAALAkAAC0JAAAjCgAAdwoAACULAACGCwAA1QsAAPEL AADyCwAAOwwAAHYMAAB3DAAACg0AAD4NAAA/DQAA8Q0AAA4OAAAPDgAAKw4AACwOAACgDwAAoQ8A AMEPAAAAEAAALBAAAFUQAACLEAAA0hAAABMRAAAVEQAAbBEAABcSAAAYEgAA2BIAANkSAAAvEwAA exMAAH0TAACZEwAAmhMAAK0UAACuFQAArxUAAOMVAAAAFgAASBYAAIkWAADUFgAADhcAACIXAAA1 FwAAdxcAAKEXAACiFwAA6xcAABQYAAA9GAAAaRgAAJAYAACrGAAAzRgAABgZAABhGQAAsRkAAPIZ AADzGQAA9BkAADUaAABtGgAAhxoAAL8aAADAGgAA8hoAACobAABkGwAAoBsAAOQbAADmGwAANRwA AJIcAABFHQAAgx0AAIQdAACYHQAAmR0AAPMdAABVHgAArSAAAA4hAAAcIQAAKiEAADwhAABJIQAA WCEAAFkhAAANIgAAICIAAEAiAABhIgAAfCIAAJYiAACxIgAAziIAAOkiAAAGIwAAIyMAAEIjAABf IwAAfCMAAH4jAACbIwAAuCMAANcjAAD0IwAAEyQAADEkAABQJAAAUSQAAGokAACFJAAAhiQAAC8l AAAwJQAAQSUAAEIlAACSJQAA8SUAAAQmAAAcJgAAMyYAAEgmAABhJgAAfSYAAI8mAACrJgAAsiYA AMsmAADuJwAACigAACQoAAAxKAAAUygAAH8oAAC6KAAA9SgAADEpAABIKQAAeikAACsqAABTKgAA BisAANosAAAgLQAAIS0AAHQtAAC8LQAAjS4AANAuAAAwMAAAMTAAAH4wAADMMAAAFDEAABoxAAAb MQAAbDEAAIcyAACIMgAAczMAAHQzAAC9MwAAAzQAAEo0AABLNAAANjUAAIY1AADMNQAAEjYAAFU2 AACUNgAA3TYAAFk3AABaNwAA6DcAADA4AAB2OAAAvTgAAP44AAD/OAAARjkAAIc5AABhOgAAqjoA AAE7AAACOwAASzsAANg7AABtPAAAoDwAAKE8AADzPAAAvz0AAA0+AAAOPgAArz8AAEVAAABYQQAA n0EAAORBAAAkQgAArEIAAO1CAAA2QwAAeUMAAJ9DAACgQwAA50MAAC9EAABwRAAAt0QAAAFFAACS RQAA3EUAACBGAAC0RgAA+0YAAEdHAACORwAA1EcAAB5IAABtSAAAt0gAALlIAAC7SAAAvEgAAL9I AADASAAAwUgAAMJIAADDSAAAxEgAAMVIAADGSAAAykgAAMxIAADOSAAAz0gAANBIAADRSAAA0kgA ANNIAADUSAAA1UgAANdIAADYSAAA2kgAAN1IAADfSAAA4UgAAOZIAADrSAAA7EgAAO1IAAD4SAAA BEkAAAVJAAAJSQAACkAAAAEwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAAAAmEAAAAAwAAAA AAAAAIAAAAAACEAAAAEwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAA AIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIAD AAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAA mEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAA AAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAw AAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAA AAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAKEAAAAMwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAA AAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAA AAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAA AAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEADIAAwAAAAAAAAAIDaAAAAmEADIAAwAQAAAAAAAIDaAAAAmEADIAAwAgAAAAAAAIDaAAAAmEAD IAAwAwAAAAAAAIDaAAAAmEADIAAwBAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAA AAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAA AIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDa AAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAA mEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAA AAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAAAAAw AAAAAAAAAIDaAAAAmEAAAAAwAAAAAAAAAIDaAAAAmEAEIAAwAAAAAAAAAIDaAAAAmEAEIAAwAQAA AAAAAIDaAAAAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAABEwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmkAAAAAwAAAAAAAA AIAAAACAmEAAAA8wAAAAAAAAAIAAAACAmEAAAA8wAAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAABkAAAAZAAAAGQAAABwA AAAABAAACE0AACgAAAAABAAA7gQAANkHAAArEgAASBoAACofAACxJgAAMyoAANAyAAAwPAAANkcA AMJMAAD3TAAACE0AACkAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAAABAAAB00AACoAAAAAAAAABwAAAAsAAAASAAAAFQAAABwAAAATIZUAEyHU/5WAAAAA AHMBAAB7AQAAKwgAADMIAACLDQAAlA0AAJ0NAACmDQAAaBAAAG0QAACqEAAAshAAAF8lAABpJQAA OiYAAD4mAAAmKAAAKigAAEopAABRKQAAhyoAAIgqAACMKgAAPysAAEorAADDKwAAzSsAAOUtAADp LQAAHC8AACkvAAC5LwAAwC8AAEowAABVMAAACzIAAA0yAAAQMgAAGzIAABwyAAAgMgAAaTQAAHI0 AAB9NAAAYDUAAGQ1AAAROAAAHDgAAD84AABKOAAAuDgAALw4AABEPQAASD0AAE0+AABYPgAArUIA ALVCAADoRgAA7UYAAIhIAACMSAAA7EgAAO1IAAD1SAAA+EgAAANJAAAGSQAACUkAAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHAAcAHAAHAAcAHAAHAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHAAIABwAHAAcABwACAAAAAABzAAAAggAAAJQAAACaAAAArwAAALAAAADOAAAAcwEAAKUBAACm AQAAQwIAAEgCAACRAgAA3wIAAOYCAAAvAwAAMgMAAEoDAADZAwAA+AMAAP0DAAAoBAAAKQQAANwE AAABBQAAAwUAACQFAAApBQAAeAUAAOwFAAB/BgAAhwYAAJcGAACxCQAAIQoAACIKAAAjCgAAJgoA AHcKAADeCgAAIQsAACQLAAAlCwAAOwwAAD4MAAB2DAAACg0AAD0NAAA+DQAAPw0AAOMNAADpDQAA 8Q0AAGwRAAC3EQAAuREAABgSAAA/EgAAShIAAIMSAABQFAAAaRQAAHUUAACaFAAASBYAAHEWAAB4 FgAAiRYAADUXAAB1FwAAdhcAAHgXAACAFwAAoRcAAM0YAADXGAAA8BgAABgZAACxGQAAshkAALQZ AADyGQAA9BkAABoaAAAbGgAANhoAADkaAABtGgAAoBsAALAbAAC4GwAAuxsAADUcAABSHAAAVBwA AJkdAACuHQAArx0AAPMdAAA6HgAAPB4AAFUeAABZHgAA8h4AAPskAAAuJQAALyUAAEIlAACLJQAA kSUAAJIlAACUJQAAqiUAAI8mAACkJgAAqiYAAKsmAAC6KAAAvygAAMUoAADhKAAA9SgAAPooAAD8 KAAAFykAADEpAAA2KQAAOSkAAEgpAADRKQAA4ikAAOwpAAArKgAABisAABArAABcKwAA1ysAADQs AABBLAAAiywAAJQsAAC6LAAACS0AAB8tAAAgLQAAdC0AAHctAAB5LQAAvC0AAMAtAADYLQAAjS4A AI4uAACSLgAA0C4AANkuAADcLgAALC8AADMvAAA0LwAAcC8AADEwAABKMAAAWzAAAH4wAADMMAAA zjAAANwwAADeMAAAbDEAAHAxAAB3MQAAFDIAABozAAA0MwAAOTMAAEozAAB0MwAAiTMAAJYzAAC+ MwAAwTMAAOEzAAADNAAABDQAAAo0AAA0NAAASTQAAEo0AAClNQAAqTUAAKo1AADMNQAAEjYAABM2 AAAWNgAAUDYAAFU2AABWNgAAXDYAAJQ2AADoNwAA6TcAAOw3AAD3NwAAMDgAADE4AAA1OAAATTgA AHY4AACnOAAAqTgAAKs4AAC9OAAAvjgAAME4AAD+OAAA/zgAAAk5AAAVOQAARjkAAMU5AADnOQAA 7zkAAEY6AABhOgAAYjoAAGQ6AACDOgAAqjoAAKs6AAC0OgAAyzoAAAI7AAA8OwAAQzsAAEw7AADX OwAA2DsAAKE8AACtPAAAtDwAAPM8AABMPQAAXD0AAGU9AAB+PQAADj4AAHI+AAB4PgAAsT4AAK8/ AADNPwAAzz8AAOQ/AABFQAAASkAAAFdAAADuQAAA9EAAAPdAAABYQQAAWUEAAFxBAAB6QQAA50MA AOhDAADrQwAAA0QAAC9EAAAwRAAANkQAAHFEAAB/RAAAgUQAAMFEAADYRAAA2kQAAPREAAACRQAA BUUAACFGAAAmRgAAtUYAALdGAAA0RwAAPEcAAGJHAABrRwAA4EcAAOVHAAAfSAAAIkgAAG5IAAB4 SAAA7EgAAO1IAAD1SAAA+EgAAANJAAAGSQAACUkAAAcABwAzAAcABwAzAAcABwAzAAcABwAzAAcA BwAzAAcAMwAHAAcAMwAHADMABwAHADMABwAHADMABwAHAAcAMwAHAAcABwAzAAcAMwAHAAcABwAz AAcABwAzAAcABwAzAAcABwAHADMABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcA MwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAzAAcABwAHADMABwAHADMABwAHAAcAMwAH ADMABwAHADMABwAHADMABwAHAAcAMwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcA MwAHAAcABwAzAAcABwAzAAcABwAHADMABwAzAAcABwAzAAcABwAHADMABwAzAAcABwAHADMABwAz AAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcAMwAHAAcA BwAzAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAH AAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHADMABwAHAAcA MwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcAMwAHAAcABwAzAAcABwAHADMABwAH AAcAMwAHADMABwAHAAcAMwAHAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwACAAcA BwAHAAcAAgAAAAAA7UEAAJ5DAACfQwAAtkgAAOxIAADtSAAA9UgAAPhIAAADSQAACUkAAAMABAAD AAQAAwACAAcAAgAHAAIA//8UAAAAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEA cgB0AG4AZQB5ABgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAxAC4AZABv AGMAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5ABgAQwA6AFwA TQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAxAC4AZABvAGMAFgBSAGkAYwBoAGEAcgBk ACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5ABgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUA bgB0AHMAXABEAE8AQwAxAC4AZABvAGMAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABI AGEAcgB0AG4AZQB5ABgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAxAC4A ZABvAGMAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5AEgAQwA6 AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkA YwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2 AGUAIABvAGYAIABEAE8AQwAxAC4AYQBzAGQAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUA IABIAGEAcgB0AG4AZQB5ABgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAx AC4AZABvAGMAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5ABgA QwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAxAC4AZABvAGMAFgBSAGkAYwBo AGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5AEgAQwA6AFwAVwBJAE4ARABPAFcA UwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABc AFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAE8A QwAxAC4AYQBzAGQAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5 ABgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABEAE8AQwAxAC4AZABvAGMAFgBSAGkA YwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5AEgAQwA6AFwAVwBJAE4ARABP AFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYA dABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABE AE8AQwAxAC4AYQBzAGQABwBnWGoFHgNwa/8P/w//D/8P/w//D/8P/w//DxAAhEfyBfz+xLP/D/8P /w//D/8P/w//D/8P/w8QAOIouxP0Uh47/w//D/8P/w//D/8P/w//D/8PEADoPug1Tmemf/8P/w// D/8P/w//D/8P/w//DxAAMETcN2IpKBD/D/8P/w//D/8P/w//D/8P/w8QADdAvFni3yTk/w//D/8P /w//D/8P/w//D/8PEACdTZVhtpxcEv8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAgAAAAAAAAAA AAAAAAAAAAAAAxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/m8oAAMAKAAAACkAAQAAAASAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/gIAAQAuAAEAAAACggEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhHgPEYRM/xXGBQABeA8GXoR4D2CETP8CAAIALgABAAAAAIAB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+AgADAC4AAQAAAASA AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/gIABAAuAAEAAAAC ggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOgXEYRM/xXGBQAB6BcGXoToF2CETP8CAAUALgABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S4GhGEmP4VxgUAAbgaBl6EuBpghJj+AgAGAC4AAQAA AASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EiB0RhJj+FcYFAAGIHQZehIgdYISY/gIABwAuAAEA AAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFggEYRM/xXGBQABWCAGXoRYIGCETP8CAAgALgAB AAAAAAACAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+bygAAwAo AAAAKQABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+ AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EqAwRhEz/FcYFAAGoDAZehKgMYIRM /wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CE mP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJg hJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EGBURhEz/FcYFAAEYFQZehBgV YIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOgXEYSY/hXGBQAB6BcGXoTo F2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S4GhGEmP4VxgUAAbgaBl6E uBpghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EiB0RhEz/FcYFAAGIHQZe hIgdYIRM/wIACAAuAAIAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP5vKAACAAAALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUA AaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYF AAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4V xgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/ FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkR hEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAkAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNAC EYSY/hXGBQAB0AIGXoTQAmCEmP5vKAACAAAALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgA AA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAY AAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAkAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAACAAAALgABAAAABIABAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAkAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAACAAAALgABAAAA BIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAA AAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEA AAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgAB AAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4A AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAu AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYA LgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAH AC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIA CAAuAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5v KAACAAAALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVg hJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAI YIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRA C2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6E EA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZe hOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMG XoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQ GQZehFAZYIRM/wIACAAuAAcAAADiKLsTAAAAAAAAAAAAAAAAnU2VYQAAAAAAAAAAAAAAAIRH8gUA AAAAAAAAAAAAAABnWGoFAAAAAAAAAAAAAAAA6D7oNQAAAAAAAAAAAAAAADdAvFkAAAAAAAAAAAAA AAAwRNw3AAAAAAAAAAAAAAAA////////////////////////////////////////BwAAAAAAAAAA AAAAAAAAAAAA//8HAAAAEgDIN4wWGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAHgP ThMZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQb AAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8A CQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQb AAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQT/QAIQ AAAAAAAAAAhJAABAAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA //8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAA AAAAAAAAAAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIA BQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsG BAICAgICBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAACIABAAxCIgYAPDQAgAA aAEAAAAACkFIRrZJSGazSUhmLQDQAwAAjAoAACE8AAABAB4AAAAEAAMQgAAAAAAAAAAAAAAAAQAB AAAAAQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0AIGBEjAA ABAAGQBkAAAAGQAAANdJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAyg1EA8BAACAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAMAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABFAFIASQBOACAARwBSAEUARQBOAEUAIAAmACAAQQBTAFMATwBD AEkAQQBUAEUAUwAAAAAAAAAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQA bgBlAHkAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP aBCrkQgAKyez2TAAAADIAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA3AAAAAQAAADoAAAABQAA AAgBAAAGAAAAFAEAAAcAAAAgAQAACAAAADABAAAJAAAAUAEAABIAAABcAQAACgAAAHgBAAALAAAA hAEAAAwAAACQAQAADQAAAJwBAAAOAAAAqAEAAA8AAACwAQAAEAAAALgBAAATAAAAwAEAAAIAAADk BAAAHgAAADEAAAAgICAgICAgICAgICAgICAgICAgICAgICBFUklOIEdSRUVORSAmIEFTU09DSUFU RVMAZW5lHgAAAAEAAAAAICAgHgAAABcAAABSaWNoYXJkIEV1Z2VuZSBIYXJ0bmV5ACAeAAAAAQAA AABpY2geAAAAAQAAAABpY2geAAAABwAAAE5vcm1hbAAgHgAAABcAAABSaWNoYXJkIEV1Z2VuZSBI YXJ0bmV5ACAeAAAAAwAAADQ1AGgeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMABuQAAAAADgeliI AAAAQAAAAABqDxb4AcABQAAAAACk1m0YAcABQAAAAAA8WYH4AcABAwAAAAEAAAADAAAAjAoAAAMA AAAhPAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss +a4wAAAAMAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJQAAAAGAAAAnAAAABEAAACkAAAAFwAA AKwAAAALAAAAtAAAABAAAAC8AAAAEwAAAMQAAAAWAAAAzAAAAA0AAADUAAAADAAAABEBAAACAAAA 5AQAAB4AAAAZAAAARXJpbiBHcmVlbmUgJiBBc3NvY2lhdGVzAAAgAAMAAACAAAAAAwAAAB4AAAAD AAAA10kAAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAADEA AAAgICAgICAgICAgICAgICAgICAgICAgICBFUklOIEdSRUVORSAmIEFTU09DSUFURVMADBAAAAIA AAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAD+ ////OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAA AFUAAABWAAAAVwAAAFgAAABZAAAA/v///1sAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAAD+//// YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAP7////9////bAAAAP7////+/////v////////// //////////////////////////////////////////////////////////////////////////// ////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA AMpC8PgBwAFuAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAwQgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBQAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJuAAAAAAAABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAAAAABAA AAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGIAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAADKQvD4AcABAMpC8PgBwAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAD+//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVu dAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= ------=_NextPart_000_0005_01C001CF.236A4900-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00653 for ; Fri, 11 Aug 2000 12:50:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:01 +0200 (MEST) Received: (qmail 27420 invoked by uid 0); 9 Aug 2000 12:22:36 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 9 Aug 2000 12:22:36 -0000 X-eGroups-Return: sentto-1101623-567-965823742-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 09 Aug 2000 12:22:31 -0000 Received: (qmail 13171 invoked from network); 9 Aug 2000 12:22:21 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 9 Aug 2000 12:22:21 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 9 Aug 2000 12:22:21 -0000 Received: (qmail 13082 invoked from network); 9 Aug 2000 12:22:19 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 9 Aug 2000 12:22:19 -0000 Sender: root@pop.gmx.net Message-ID: <39914CD8.A4BAD014@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 Aug 2000 14:21:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0769f78a2e2fe0e090a479e109359d2c Status: R X-Status: N "Richard E.Hartney" wrote:

Very nice, I have already red the System overvieuw :-)
Are the schematic's also available for downloading ?

Greatings,

    P. Pelgrims
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00680 for ; Fri, 11 Aug 2000 12:50:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:07 +0200 (MEST) Received: (qmail 18461 invoked by uid 0); 9 Aug 2000 20:06:06 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 9 Aug 2000 20:06:06 -0000 X-eGroups-Return: sentto-1101623-568-965851556-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 09 Aug 2000 20:06:04 -0000 Received: (qmail 29753 invoked from network); 9 Aug 2000 20:05:56 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 9 Aug 2000 20:05:56 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 9 Aug 2000 20:05:52 -0000 Received: from f-cpu.org (nas4-182.aub.club-internet.fr [195.36.145.182]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA00640 for ; Wed, 9 Aug 2000 22:04:58 +0200 (MET DST) Message-ID: <3991B95F.E6FDB174@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> <39914CD8.A4BAD014@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 Aug 2000 22:04:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4bca13a45e8714029cff4ddd912ae7dd Status: R X-Status: N hello,

pelgrims p wrote:
> "Richard E.Hartney" wrote:
>
> Very nice, I have already red the System overvieuw :-)
> Are the schematic's also available for downloading ?

i have a hardcopy of an 'old' version of his system in France.
Richard has no online version that i know of.

as for the f-cpu, the online version is (still) at
http://www.f-cpu.de/man/i7/part1.html

have fun,
> Greatings,
>
>     P. Pelgrims
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00719 for ; Fri, 11 Aug 2000 12:50:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:15 +0200 (MEST) Received: (qmail 9609 invoked by uid 0); 10 Aug 2000 07:58:12 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 10 Aug 2000 07:58:12 -0000 X-eGroups-Return: sentto-1101623-569-965894289-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ei.egroups.com with NNFMP; 10 Aug 2000 07:58:12 -0000 Received: (qmail 17117 invoked from network); 10 Aug 2000 07:58:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 10 Aug 2000 07:58:07 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 10 Aug 2000 07:58:07 -0000 Received: (qmail 29047 invoked from network); 10 Aug 2000 07:58:03 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 07:58:03 -0000 Sender: root@pop.gmx.net Message-ID: <39926067.2607B0AC@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> <39914CD8.A4BAD014@pandora.be> <3991B95F.E6FDB174@f-cpu.org> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 09:57:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b9f5fe93e0deb0ee8e1f13c70fb7bd82 Status: R X-Status: N Patrick :

> hello,
>
> i have a hardcopy of an 'old' version of his system in France.

Can we have a copy of it ?

>
> Richard has no online version that i know of.
>
>    P. Pelgrims
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00755 for ; Fri, 11 Aug 2000 12:50:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:23 +0200 (MEST) Received: (qmail 723 invoked by uid 0); 10 Aug 2000 12:08:38 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 10 Aug 2000 12:08:38 -0000 X-eGroups-Return: sentto-1101623-570-965909312-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 10 Aug 2000 12:08:36 -0000 Received: (qmail 5510 invoked from network); 10 Aug 2000 12:08:31 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 10 Aug 2000 12:08:31 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 10 Aug 2000 12:08:31 -0000 Received: from f-cpu.org (nas1-162.ras.club-internet.fr [195.36.192.162]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA18367 for ; Thu, 10 Aug 2000 14:08:28 +0200 (MET DST) Message-ID: <39929B31.F3B92A7@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> <39914CD8.A4BAD014@pandora.be> <3991B95F.E6FDB174@f-cpu.org> <39926067.2607B0AC@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 14:08:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3775733f7ea1ebb9c2a6c3f389908fe0 Status: R X-Status: N pelgrims p wrote:
> Patrick :
> > hello,
> > i have a hardcopy of an 'old' version of his system in France.
> Can we have a copy of it ?

i don't know. it has already cost him $23 to send all the papers to Paris.
a website would be really better :-) of course, if webspace is the
problem, we can arrange this.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00776 for ; Fri, 11 Aug 2000 12:50:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:28 +0200 (MEST) Received: (qmail 28766 invoked by uid 0); 10 Aug 2000 12:44:11 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 10 Aug 2000 12:44:11 -0000 X-eGroups-Return: sentto-1101623-571-965911440-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 10 Aug 2000 12:44:10 -0000 Received: (qmail 8913 invoked from network); 10 Aug 2000 12:44:00 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Aug 2000 12:44:00 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 10 Aug 2000 12:44:00 -0000 Received: (qmail 3616 invoked from network); 10 Aug 2000 12:43:58 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 12:43:58 -0000 Sender: root@pop.gmx.net Message-ID: <3992A368.94791EAC@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> <39914CD8.A4BAD014@pandora.be> <3991B95F.E6FDB174@f-cpu.org> <39926067.2607B0AC@pandora.be> <39929B31.F3B92A7@f-cpu.org> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 14:43:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8e676790cef9a2ecfd2eff2b75492f80 Status: R X-Status: N Yann Guidon wrote:

> pelgrims p wrote:
> > Patrick :
> > > hello,
> > > i have a hardcopy of an 'old' version of his system in France.
> > Can we have a copy of it ?
>
> i don't know. it has already cost him $23 to send all the papers to Paris.

$23 a lot of paper :-) ?

> a website would be really better :-) of course, if webspace is the
> problem, we can arrange this.

Hoping to find those 'data' soon on the F-cpu page maybe ? , I remain,
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00797 for ; Fri, 11 Aug 2000 12:50:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:33 +0200 (MEST) Received: (qmail 27390 invoked by uid 0); 10 Aug 2000 14:59:49 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 10 Aug 2000 14:59:49 -0000 X-eGroups-Return: sentto-1101623-572-965919582-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 10 Aug 2000 14:59:48 -0000 Received: (qmail 1187 invoked from network); 10 Aug 2000 14:59:41 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Aug 2000 14:59:41 -0000 Received: from unknown (HELO cmailg4.svr.pol.co.uk) (195.92.195.174) by mta1 with SMTP; 10 Aug 2000 14:59:41 -0000 Received: from modem-11.neptunium.dialup.pol.co.uk ([62.136.66.11] helo=sargon.chrystal.gbr.xerox.com) by cmailg4.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13Mto2-0007Jf-00 for F-cpu@egroups.com; Thu, 10 Aug 2000 15:59:39 +0100 To: F-cpu@egroups.com Message-ID: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 15:58:40 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Erin and licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b668175d342e275e4024c87f09e03bba Status: R X-Status: N The licence is the most important thing.
There are already truckloads of CPU designs in the world. But they are not
GPLd (GNU Public Licenced).
Freedom to make and modify the design, or to tack it onto something else
(would not require releasing a companies
own IP) is essential to the Freedom CPU.

The first incarnation must be credible in only a small way. The thing with
GPL projects on the web is that there a millions of
small iterations improving the end product. And you don't have to work for
a certain company or wear a certain hat to do it.
You might work in a cafe bar, having been unable to get 'the right job'
after graduation (or simply leaving school), be self taught
or whatever. At the end of the day, if your idea works, people will
incorporate it into a free project.

The post modern industrial world (he he I've always wanted to say that) has
come up with a high tech world where everything is 'wizarded' -
cars will drive themselves, your computer writes a complaint letter for you
with you just waving a bank charge notification letter at it.
The neat tech stuff is done by a group of back room boffins who create a
product, and stuff you if you don't like it because they know better.
Just give them your money.
Utter claptrap. Many many people are capable of much more than they are
allowed to believe.

With millions of people being in a position to contribute, the product will
inevitably become far superior in areas that matter than products designed
by a group of people who consider themselves to be some kind of elite.

The GNU Public Licence was the thing that really created secure free
software.
Therefore, if Erin is going to be totally public licence, then it's
interesting.
If it isn't public licence, then forget it.

Jeff Davies
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00806 for ; Fri, 11 Aug 2000 12:50:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:35 +0200 (MEST) Received: (qmail 4844 invoked by uid 0); 10 Aug 2000 15:38:08 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 10 Aug 2000 15:38:08 -0000 X-eGroups-Return: sentto-1101623-573-965921846-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 10 Aug 2000 15:37:36 -0000 Received: (qmail 31155 invoked from network); 10 Aug 2000 15:37:25 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Aug 2000 15:37:25 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta1 with SMTP; 10 Aug 2000 15:37:25 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id KAA03033; Thu, 10 Aug 2000 10:37:25 -0500 Received: from eceultra6 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id KAA07677; Thu, 10 Aug 2000 10:37:23 -0500 (CDT) Received: from localhost by eceultra6 (8.8.8+Sun/ECESolaris-Client) id KAA06077; Thu, 10 Aug 2000 10:35:17 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 10:35:17 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Erin and licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 93baf8fa7aa2c6a8f02f3e10032aacbb Status: R X-Status: N On Thu, 10 Aug 2000, Jeff Davies/CDPTEST wrote:

> The licence is the most important thing.
> There are already truckloads of CPU designs in the world. But they are not
> GPLd (GNU Public Licenced).
> Freedom to make and modify the design, or to tack it onto something else
> (would not require releasing a companies
> own IP) is essential to the Freedom CPU.

Correct me if I'm wrong, but I thought that the GPL would not allow a
GPLed design to be tacked on to a non-GPLed design to create a derivative
work.  So the GPL would require releasing a company's own IP in this
case.  I thought that was the distinction between the GPL and the LGPL
(which would not require releasing any IP in this case).

Dave
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00836 for ; Fri, 11 Aug 2000 12:50:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:43 +0200 (MEST) Received: (qmail 20849 invoked by uid 0); 10 Aug 2000 17:25:18 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 10 Aug 2000 17:25:18 -0000 X-eGroups-Return: sentto-1101623-574-965928311-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 10 Aug 2000 17:25:16 -0000 Received: (qmail 21555 invoked from network); 10 Aug 2000 17:25:10 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 10 Aug 2000 17:25:10 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 10 Aug 2000 17:25:10 -0000 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA10608 for ; Thu, 10 Aug 2000 19:25:07 +0200 (MET DST) Message-ID: <3992E568.28BC0434@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 19:24:56 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9d91640dc331b325d0355c244020264d Status: R X-Status: N hi jeff !

Jeff Davies/CDPTEST wrote:
<snip>
> The GNU Public Licence was the thing that really created secure free software.
> Therefore, if Erin is going to be totally public licence, then it's interesting.
> If it isn't public licence, then forget it.

As richard wrote it already (don't ask me the references)
his ERIN CPU is a project separate from the F-CPU.
his goals are to run a certain software, nothing more.
so there is no problem with the licence on his CPU.
i guess that it is even close to public domain. the CPU is
only one part of his work.


As for the F-CPU, you seemed to volunteer to make a f-cpu lincence ;-)
unfortunately, the GPL as it is can't be applied to every part of our
project. the manual is protected by the GFDL, the C sources are protected
by the GPL, but the VHDL or the mask files can't be protected with any of them.
they can be copyrighted, that's all.
If anybody has any things to add, i'd be glad to discuss this again.

> Jeff Davies


> Correct me if I'm wrong, but I thought that the GPL would not allow a
> GPLed design to be tacked on to a non-GPLed design to create a derivative work.
correct. In the f-cpu, too.

>  So the GPL would require releasing a company's own IP in this case.
to the great benefit of the whole community :-P

>  I thought that was the distinction between the GPL and the LGPL
> (which would not require releasing any IP in this case).
maybe it's more subtle, but i'm not an expert.

> Dave


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00839 for ; Fri, 11 Aug 2000 12:50:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:44 +0200 (MEST) Received: (qmail 11593 invoked by uid 0); 10 Aug 2000 17:25:28 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 10 Aug 2000 17:25:28 -0000 X-eGroups-Return: sentto-1101623-575-965928320-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 10 Aug 2000 17:25:26 -0000 Received: (qmail 2222 invoked from network); 10 Aug 2000 17:25:19 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 10 Aug 2000 17:25:19 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 10 Aug 2000 17:25:19 -0000 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA09238 for ; Thu, 10 Aug 2000 19:25:09 +0200 (MET DST) Message-ID: <3992E56A.3BBF474A@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000901c001f9$2d9ca920$060bd7d1@0018728164> <39914CD8.A4BAD014@pandora.be> <3991B95F.E6FDB174@f-cpu.org> <39926067.2607B0AC@pandora.be> <39929B31.F3B92A7@f-cpu.org> <3992A368.94791EAC@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 19:24:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c7a4c23cc4d0aa4b90ee3c3e13f8aa55 Status: R X-Status: N hello,

pelgrims p wrote:
> Yann Guidon wrote:
> > pelgrims p wrote:
> > > Patrick :
> > > > hello,
> > > > i have a hardcopy of an 'old' version of his system in France.
> > > Can we have a copy of it ?
> > i don't know. it has already cost him $23 to send all the papers to Paris.
> $23 a lot of paper :-) ?
around 1kg.

> > a website would be really better :-) of course, if webspace is the
> > problem, we can arrange this.
> Hoping to find those 'data' soon on the F-cpu page maybe ? , I remain,
well, if the data are available, there is no reason to refuse.
the problem is that, except the paper version i have, there's nothing else
available, and what Richard sent is not "widely" available.

i hope that he converts some screenshots to GIFs, and make a simple yet
useful page.


OT: i just found 3 high density connectors, usually used for industrial PCI
sockets. very nice and $1 each : very cheap for prototyping purposes :-)
i guess that it can be used up to 50MHz or so without difficulties : it's
completely shielded.


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00842 for ; Fri, 11 Aug 2000 12:50:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:45 +0200 (MEST) Received: (qmail 18216 invoked by uid 0); 10 Aug 2000 17:44:18 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 10 Aug 2000 17:44:18 -0000 X-eGroups-Return: sentto-1101623-576-965929446-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 10 Aug 2000 17:44:15 -0000 Received: (qmail 28896 invoked from network); 10 Aug 2000 17:44:06 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 10 Aug 2000 17:44:06 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 10 Aug 2000 17:44:05 -0000 Received: (qmail 27308 invoked from network); 10 Aug 2000 17:44:00 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 17:44:00 -0000 Sender: root@pop.gmx.net Message-ID: <3992E9BE.36EE7B58@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> <3992E568.28BC0434@f-cpu.org> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 19:43:26 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8434b086490d93b7c4680c5ffd680c78 Status: R X-Status: N Yann Guidon wrote:

> hi jeff !
>
> Jeff Davies/CDPTEST wrote:
> <snip>
> > The GNU Public Licence was the thing that really created secure free software.
> > Therefore, if Erin is going to be totally public licence, then it's interesting.
> > If it isn't public licence, then forget it.
>
> As richard wrote it already (don't ask me the references)
> his ERIN CPU is a project separate from the F-CPU.
> his goals are to run a certain software, nothing more.
> so there is no problem with the licence on his CPU.
> i guess that it is even close to public domain. the CPU is
> only one part of his work.
>
> As for the F-CPU, you seemed to volunteer to make a f-cpu lincence ;-)
> unfortunately, the GPL as it is can't be applied to every part of our
> project. the manual is protected by the GFDL, the C sources are protected
> by the GPL, but the VHDL or the mask files can't be protected with any of them.
> they can be copyrighted, that's all.
> If anybody has any things to add, i'd be glad to discuss this again.

What type of licence is used for the functional units on the www.opencores.org  ?
Is it not possibel to define a new type of GPHardwareL (GPHL) licence unther which
one can put they "own" designs. VHDL is a hardware description and the implementation
can also be protected by that new type of licence.
It is my opinion to make work of that type of license since many persons don't
contribute since there is no "security" now. It is just GPL that have done very well
for e.g. Linux :-).
So why should it not work for hardware ?
This new type of licence can protect also the things that are not included in the
orther types.

Greatings P. Pelgrims

> > Jeff Davies
>
> > Correct me if I'm wrong, but I thought that the GPL would not allow a
> > GPLed design to be tacked on to a non-GPLed design to create a derivative work.
> correct. In the f-cpu, too.
>
> >  So the GPL would require releasing a company's own IP in this case.
> to the great benefit of the whole community :-P
> >  I thought that was the distinction between the GPL and the LGPL
> > (which would not require releasing any IP in this case).
> maybe it's more subtle, but i'm not an expert.
>
> > Dave
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
>

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00845 for ; Fri, 11 Aug 2000 12:50:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:46 +0200 (MEST) Received: (qmail 30854 invoked by uid 0); 10 Aug 2000 17:57:41 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 10 Aug 2000 17:57:41 -0000 X-eGroups-Return: sentto-1101623-577-965930249-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 10 Aug 2000 17:57:39 -0000 Received: (qmail 6669 invoked from network); 10 Aug 2000 17:57:28 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 10 Aug 2000 17:57:28 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 10 Aug 2000 17:57:28 -0000 Received: from ici.net (downix@dialup-209.245.97.144.Manchester1.Level3.net [209.245.97.144]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id NAA20059 for ; Thu, 10 Aug 2000 13:57:26 -0400 (EDT) Sender: downix@ici.net Message-ID: <3992ED19.E0906E99@ici.net> X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.16 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> <3992E568.28BC0434@f-cpu.org> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 13:57:45 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1a60a771874a9fcd95376756415782a3 Status: R X-Status: N Yann Guidon wrote:

> hi jeff !
>
> Jeff Davies/CDPTEST wrote:
> <snip>
> > The GNU Public Licence was the thing that really created secure free
> software.
> > Therefore, if Erin is going to be totally public licence, then it's
> interesting.
> > If it isn't public licence, then forget it.
>
> As richard wrote it already (don't ask me the references)
> his ERIN CPU is a project separate from the F-CPU.
> his goals are to run a certain software, nothing more.
> so there is no problem with the licence on his CPU.
> i guess that it is even close to public domain. the CPU is
> only one part of his work.
>
>
> As for the F-CPU, you seemed to volunteer to make a f-cpu lincence ;-)
>
> unfortunately, the GPL as it is can't be applied to every part of our
> project. the manual is protected by the GFDL, the C sources are
> protected
> by the GPL, but the VHDL or the mask files can't be protected with any
> of them.
> they can be copyrighted, that's all.
> If anybody has any things to add, i'd be glad to discuss this again.
>
> > Jeff Davies
>
>
> > Correct me if I'm wrong, but I thought that the GPL would not allow
> a
> > GPLed design to be tacked on to a non-GPLed design to create a
> derivative work.
> correct. In the f-cpu, too.
>
> >  So the GPL would require releasing a company's own IP in this case.
>
> to the great benefit of the whole community :-P
>
> >  I thought that was the distinction between the GPL and the LGPL
> > (which would not require releasing any IP in this case).
> maybe it's more subtle, but i'm not an expert.
>
> > Dave
>
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>

Well, if that is such an issue, I'll have my lawyers draft up a license
proposal.  Does that sound workable?

BTW, I've been reviewing your F-CPU manual YG.. and what I've creaqted
doesn't comply with it entirely.  Mine is more like MIPS, due to my
familiarity with MIPS probably.  But it's still pretty close to your
design.

I also have a MISC CPU design I've worked on I'll post as well.  You
might be surprised, it is 5x faster than the F-CPU design I came up
with, and solves some of the problems of a traditional MISC design
(namely it's C-code execution speed)
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00848 for ; Fri, 11 Aug 2000 12:50:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:47 +0200 (MEST) Received: (qmail 760 invoked by uid 0); 10 Aug 2000 18:17:24 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 10 Aug 2000 18:17:24 -0000 X-eGroups-Return: sentto-1101623-578-965931423-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 10 Aug 2000 18:17:21 -0000 Received: (qmail 6616 invoked from network); 10 Aug 2000 18:17:02 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 10 Aug 2000 18:17:02 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 10 Aug 2000 18:17:02 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e7AIH4x05403; Thu, 10 Aug 2000 14:17:04 -0400 Message-Id: <200008101817.e7AIH4x05403@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 14:17:04 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4063bfb6f67fb7a5cee5f1fa52c45c7e Status: R X-Status: N I was thinking there's some redundant things going on in CPU and ISA design.  So let's eliminate them if possible. 

1. Implied destination registers

Take out the destination in the instruction format.
This saves 6+ bits per instruction.
Create four classes of registers (something with the number four popping up in my designs lately... odd)
bit 0 - load flag
bit 1 - destination flag

00 - free register
01 - instruction output on right of load register
11 - inverse instruction output on left of load register
10 - register loaded with value to be used in computation

Or drop the inverse instruction bit and add implied source 2 registers
This saves an additional 6+ bits over the bits saved in the above spec-let (oh god, I said spec-let!)

bit 0 - source 1 flag
bit 1 - source 2 flag

00 - free register
10 - source 1
01 - source 2
11 - destination register

That would put registers close to each other for every operation.

2. I don't even know if this is possible:(which makes #1 harder to do)

Load a stream of source 1 registers like a string into a memory space. 
Think of it as an instruction framebuffer (please don't kill me for that one).
Load a stream of source 2 registers aligned with the first framebuffer.
Finally load the streams vertically into two register columns side by side. 
Perform instructions.
Read from registers.
Reading from registers should imply the destination registers which are in the third column.  You could have a debug read instruction that reads register by register as in the old way.

This can easily be optimized by the compiler, plus it allows the compiler even define a width for the framebuffer allowing software to adapt to the register layout available.

This brings up a question:
If this is set up properly, when do we really need mov?  I mean at all.

For example this is useless code:

mov r1, r2
mov r2, r3
mov r3, r4
add r1, r4, r5

Load Store Unit needs to be redesigned to take care of this.  However I can say this is a great way to get SIMD, Vector, TTA, and RISC features all at once.

With this design the compiler can kill that code and just say add r1, r1, r2.

The framebuffer also brings some optimization options outside of the OS.  Perhaps a dynamic compilation chip could be could be developed just for this design.  That is if the framebuffer becomes inefficient for whatever reason, the chip can access and optimize the framebuffer just the same way my TV card pumps an image from my Amiga1200 to the video framebuffer.

If this seems similar to Brian Fuhs' TTA, it is because it is TTA almost.  The instruction units haven't been integrated into the registers as his TTA would require.

I think it also reduces the register the ports required.  I haven't looked at it very closely.

Rares

Note: This is copyright 2000 Rares Marian and/or FCPU whichever is prepared to claim it. (Until we get a proper license set up, that's the way it goes.)











Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00857 for ; Fri, 11 Aug 2000 12:50:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:49 +0200 (MEST) Received: (qmail 26218 invoked by uid 0); 10 Aug 2000 18:58:26 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 10 Aug 2000 18:58:26 -0000 X-eGroups-Return: sentto-1101623-579-965933878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 10 Aug 2000 18:58:25 -0000 Received: (qmail 20271 invoked from network); 10 Aug 2000 18:57:56 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 10 Aug 2000 18:57:56 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 10 Aug 2000 18:57:56 -0000 Received: (qmail 9846 invoked from network); 10 Aug 2000 18:57:54 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 18:57:54 -0000 Sender: root@pop.gmx.net Message-ID: <3992FB0B.868503C4@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> <3992E568.28BC0434@f-cpu.org> <3992ED19.E0906E99@ici.net> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 20:57:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 779eb1d97cfff642d83447d6f7fb02d0 Status: R X-Status: N Nathaniel Downes wrote:

> Yann Guidon wrote:
>
> > hi jeff !
> >
> > Jeff Davies/CDPTEST wrote:
> > <snip>
> > > The GNU Public Licence was the thing that really created secure free
> > software.
> > > Therefore, if Erin is going to be totally public licence, then it's
> > interesting.
> > > If it isn't public licence, then forget it.
> >
> > As richard wrote it already (don't ask me the references)
> > his ERIN CPU is a project separate from the F-CPU.
> > his goals are to run a certain software, nothing more.
> > so there is no problem with the licence on his CPU.
> > i guess that it is even close to public domain. the CPU is
> > only one part of his work.
> >
> >
> > As for the F-CPU, you seemed to volunteer to make a f-cpu lincence ;-)
> >
> > unfortunately, the GPL as it is can't be applied to every part of our
> > project. the manual is protected by the GFDL, the C sources are
> > protected
> > by the GPL, but the VHDL or the mask files can't be protected with any
> > of them.
> > they can be copyrighted, that's all.
> > If anybody has any things to add, i'd be glad to discuss this again.
> >
> > > Jeff Davies
> >
> >
> > > Correct me if I'm wrong, but I thought that the GPL would not allow
> > a
> > > GPLed design to be tacked on to a non-GPLed design to create a
> > derivative work.
> > correct. In the f-cpu, too.
> >
> > >  So the GPL would require releasing a company's own IP in this case.
> >
> > to the great benefit of the whole community :-P
> >
> > >  I thought that was the distinction between the GPL and the LGPL
> > > (which would not require releasing any IP in this case).
> > maybe it's more subtle, but i'm not an expert.
> >
> > > Dave
> >
> >
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> > SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
> >
>
> Well, if that is such an issue, I'll have my lawyers draft up a license
> proposal.  Does that sound workable?
>
> BTW, I've been reviewing your F-CPU manual YG.. and what I've creaqted
> doesn't comply with it entirely.  Mine is more like MIPS, due to my
> familiarity with MIPS probably.  But it's still pretty close to your
> design.
>
> I also have a MISC CPU design I've worked on I'll post as well.

Did you mean that you will send it to us ?
We would like to find it nice :-). We can learn somthing out of it ?

> You might be surprised, it is 5x faster than the F-CPU design I came up
> with, and solves some of the problems of a traditional MISC design
> (namely it's C-code execution speed)
>
>

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00860 for ; Fri, 11 Aug 2000 12:50:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:50 +0200 (MEST) Received: (qmail 29545 invoked by uid 0); 10 Aug 2000 18:59:54 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 10 Aug 2000 18:59:54 -0000 X-eGroups-Return: sentto-1101623-580-965933986-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hj.egroups.com with NNFMP; 10 Aug 2000 18:59:53 -0000 Received: (qmail 27888 invoked from network); 10 Aug 2000 18:59:45 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 10 Aug 2000 18:59:45 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 10 Aug 2000 18:59:45 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e7AIxm011553; Thu, 10 Aug 2000 14:59:48 -0400 Message-Id: <200008101859.e7AIxm011553@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 14:59:48 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9ff779d7bc568610ae413f18bc4c4d76 Status: R X-Status: N Nathaniel Downes <down@ici.net> wrote:

>Well, if that is such an issue, I'll have my lawyers draft up a license
>proposal.  Does that sound workable?
>
>BTW, I've been reviewing your F-CPU manual YG.. and what I've creaqted
>doesn't comply with it entirely.  Mine is more like MIPS, due to my
>familiarity with MIPS probably.  But it's still pretty close to your
>design.
>
>I also have a MISC CPU design I've worked on I'll post as well.  You
>might be surprised, it is 5x faster than the F-CPU design I came up
>with, and solves some of the problems of a traditional MISC design
>(namely it's C-code execution speed)

The bit that annoyed me was the idea that VHDL isn't copyrightable.  VHDL is source.

A big score for the defendants in the DeCSS case is that the Judge was convinced by testimony that source is speech.

What's patentable is not the VHDL but the description that one sends to the patent office.  The description sent to the patent office never talks in terms of bits or gears but the way the thing function as a whole. In fact the details expressed in the F-CPU manual are closer to what a patent application would look like.  You cannot patent a blueprint, That's just there to aid in understanding the machine.

Rares


Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00863 for ; Fri, 11 Aug 2000 12:50:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:51 +0200 (MEST) Received: (qmail 20916 invoked by uid 0); 10 Aug 2000 19:44:55 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 10 Aug 2000 19:44:55 -0000 X-eGroups-Return: sentto-1101623-581-965936686-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ho.egroups.com with NNFMP; 10 Aug 2000 19:44:54 -0000 Received: (qmail 11719 invoked from network); 10 Aug 2000 19:44:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 10 Aug 2000 19:44:34 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 10 Aug 2000 19:44:31 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id QAA10101 for ; Thu, 10 Aug 2000 16:58:22 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <200008101859.e7AIxm011553@tbird.iworld.com> In-Reply-To: <200008101859.e7AIxm011553@tbird.iworld.com> Message-Id: <00081016494403.00385@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 16:38:37 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f4dffc962443c91168160c301bf1ea55 Status: R X-Status: N Rares,
> The bit that annoyed me was the idea that VHDL isn't copyrightable.  VHDL is source.

Source code is exactly what is copyrightable. In the 1980s a special
"patch" to the copyright law was created to allow you to use copyright
protection for integrated circuit layouts.
  
> A big score for the defendants in the DeCSS case is that the Judge
> was convinced by testimony that source is speech.

I think you are a bit confused, here. Note that the copyright owners
for DeCSS want to distribute it and are being sued by a third party to
keep them from doing so. So the judgement reinforces copyright instead
of weakening it (which I think is the impression you got).

> What's patentable is not the VHDL but the description that one
> sends to the patent office.  The description sent to the patent office
> never talks in terms of bits or gears but the way the thing function
> as a whole. In fact the details expressed in the F-CPU manual are
> closer to what a patent application would look like.  You cannot
> patent a blueprint, That's just there to aid in understanding the
> machine.

There are two parts to a patent application. The bulk has explanatory
text and drawings and has no legal value at all. Only the small number
of terse paragraphs at the end, called the "claims", actually define
what is covered by the patent.

It is very likely that the F-CPU will infringe quite a few patents, so
having a few of its own as a bargaining chip might be a good idea. I
would hate to have to get into this game, however....

-- Jecel
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00878 for ; Fri, 11 Aug 2000 12:50:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:54 +0200 (MEST) Received: (qmail 2942 invoked by uid 0); 10 Aug 2000 20:27:44 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 10 Aug 2000 20:27:44 -0000 X-eGroups-Return: sentto-1101623-582-965939253-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 10 Aug 2000 20:27:43 -0000 Received: (qmail 676 invoked from network); 10 Aug 2000 20:27:33 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 10 Aug 2000 20:27:33 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 10 Aug 2000 20:27:28 -0000 Received: (qmail 17447 invoked from network); 10 Aug 2000 20:27:17 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.176]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 20:27:17 -0000 Sender: root@pop.gmx.net Message-ID: <39930FFE.DD7EFD09@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200008101859.e7AIxm011553@tbird.iworld.com> <00081016494403.00385@gandalf> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 22:26:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64d9c3aa9baa9ac829fd9f741e447fc4 Status: R X-Status: N Is this not a good starting point for GPHardwareL

http://www.lart.tudelft.nl/LICENSE

Patrick Pelgrims
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00902 for ; Fri, 11 Aug 2000 12:50:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:58 +0200 (MEST) Received: (qmail 16669 invoked by uid 0); 10 Aug 2000 22:39:31 -0000 Received: from ck.egroups.com (208.50.144.69) by mx11.rz2.gmx.net with SMTP; 10 Aug 2000 22:39:31 -0000 X-eGroups-Return: sentto-1101623-583-965946613-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 10 Aug 2000 22:30:16 -0000 Received: (qmail 29775 invoked from network); 10 Aug 2000 22:30:13 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Aug 2000 22:30:13 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 10 Aug 2000 22:30:12 -0000 Received: from f-cpu.org (nas3-98.aub.club-internet.fr [195.36.145.98]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA11451 for ; Fri, 11 Aug 2000 00:30:08 +0200 (MET DST) Message-ID: <39932CD1.63C7CBB9@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> <3992E568.28BC0434@f-cpu.org> <3992ED19.E0906E99@ici.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 00:29:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 731edb73641c1e320921a6cd0cb2533e Status: R X-Status: N hi !

Nathaniel Downes wrote:
> Well, if that is such an issue, I'll have my lawyers draft up a license
> proposal.  Does that sound workable?
if the debate is open and constructive, i'm sure that it will take some time
(months ?) but we'll succeed. why don't your lawyers join the discussion here ? :-)

some time ago (1 or 2 months) i proposed some amendments to the GPL in order
to make a f-cpu licence in a rather radical way. To me, the GPL is not enough.
it's ok in a general case BUT we're doing a HW project and we're not safe from
any company monopolizing the design through licence tricks. I've seen some
occurences already with the GPL and i don't want that to happen in the
utopic F-CPU world.

Of course i don't expect these rules to be followed closely. there are two
reasons : either you're

> BTW, I've been reviewing your F-CPU manual YG.. and what I've creaqted
> doesn't comply with it entirely.  Mine is more like MIPS, due to my
> familiarity with MIPS probably.  But it's still pretty close to your
> design.

i'm eager to see your stuff soon !!! don't worry if it doesn't comply 100%.
it'll take some time for everybody to understand the techniques that are described.
even the descriptions do not satisfy me :-)

but don't get stuck by simply mapping or complying with the instruction set.
there are big opportunities in the instruction set so you have NO EXCUSE
to make something crappy ;-P

> I also have a MISC CPU design I've worked on I'll post as well.  You
> might be surprised, it is 5x faster than the F-CPU design I came up
> with, and solves some of the problems of a traditional MISC design
> (namely it's C-code execution speed)

wow...


Rares wrote :

> The bit that annoyed me was the idea that VHDL isn't copyrightable.  VHDL is source.
VHDL is copyrightable. But VHDL is not in itself a program source code. it can't be protected
by the GPL.

> A big score for the defendants in the DeCSS case is that the Judge was convinced by testimony that source is
> speech.
that's terribly poetic :-)

> What's patentable is not the VHDL but the description that one sends to the patent office.  The description sent
> to the patent office never talks in terms of bits or gears but the way the thing function as a whole. In fact the
> details expressed in the F-CPU manual are closer to what a patent application would look like.  You cannot patent
> a blueprint, That's just there to aid in understanding the machine.

thanks for this precision :-)

in fact the manual is meant to be a one-fit-all document, except a holy bible (let's remain critic).
but now the description it holds is what ?

i hate to think about legal problems. I really hate it. so i leave the subject to those who have more
balls and/or time.

> Rares

Jecel :
> There are two parts to a patent application. The bulk has explanatory
> text and drawings and has no legal value at all. Only the small number
> of terse paragraphs at the end, called the "claims", actually define
> what is covered by the patent.
>
> It is very likely that the F-CPU will infringe quite a few patents, so
> having a few of its own as a bargaining chip might be a good idea. I
> would hate to have to get into this game, however....

i don't think it's our goal to play this old silly game : i believe that the idea
of freedom behind the f-cpu (U for Utopia) is that we wouldn't need patents anymore.
we're not playing this game. If we want to be creative and efficient etc,
we have to forget this problem, and "fix" if we are really urged to. But we design,
we don't implement ! that's all the trick :-) we can say "this is that" but
this is the guy who has to fund/make the chip who actually infringes the patent (if this
can ever be proved).

The f-cpu project can't afford or waste time, money, ressources and corrupt itself
into the system from which we want to get out. we can play the game of copyright,
author rights, as well as constitutional right where this applies. We protected
the F-CPU in France through a group action by using the trademark system (btw, if anyone
can trademark the f-cpu brand with its logo in the US and anywhere else, please
talk about it on the list). the patent issue is much more complex and ressource-wasting.
it's not worth at our current level. Even at Nate's level. We're gentlemen, right ?

> -- Jecel

> Is this not a good starting point for GPHardwareL
> http://www.lart.tudelft.nl/LICENSE
> Patrick Pelgrims

i'll take a look. can others do the same ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00905 for ; Fri, 11 Aug 2000 12:50:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:50:59 +0200 (MEST) Received: (qmail 4470 invoked by uid 0); 10 Aug 2000 22:54:47 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 10 Aug 2000 22:54:47 -0000 X-eGroups-Return: sentto-1101623-584-965948082-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 10 Aug 2000 22:54:43 -0000 Received: (qmail 23130 invoked from network); 10 Aug 2000 22:54:42 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Aug 2000 22:54:42 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta1 with SMTP; 10 Aug 2000 22:54:42 -0000 Received: from 0018728164 (host-209-214-154-25.bix.bellsouth.net [209.214.154.25]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id SAA03212; Thu, 10 Aug 2000 18:54:39 -0400 (EDT) Message-ID: <001d01c0031d$ebe8a080$199ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 17:54:19 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: ERIN32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C002F4.01DCD7A0" X-UIDL: 9867d0a7effd5ef7271e718214ae6a23 Status: R X-Status: N ------=_NextPart_000_001A_01C002F4.01DCD7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry I caused all the legalese talk. My recent System Overview releas= e has been reviewed/modifed and more information added to the point you will all = have the same stuff as Yann Guidon. He will know what to shit can & what to ret= ain. Data entry is time consuming on this damn PC. Am using the latest and = greatest GATEWAY 750MHZ, 256mbyte RAM (It blows my mind that ANY computer r= equires this much Program space to reduce Program swapping. And what good is 750mhz for data entry - as I am doing - NONE. The Software I = am going to CAPTURE will do the same as virtually ALL of the MICROSOFT crap an= d much more efficiently. 7500 lines of code - period. None of this irrita= ting crap I am getting with Microsoft Word 2000. Major difference - NO GAMES. I play= a Timed game of Solitaire occassionally and when I win a game the response is= so good - I can't see my Bonus Score. Am I impressed? NO. Are you impressed with wait time of your Local Network, for those of you that are using it. A= ll I hear is complaints. With my System architecture this is G-O-N-E!! While your syst= em is doing its Giga-bit serial transfer with EDAC - my approach already has s= tored the data on the required Hard Drive or retrieved the data and is displaying= it. Sorry for getting stirred up - I must get back to writing. Sincerely Richard E. Hartney Research Director Erin Greene & Associates. ------=_NextPart_000_001A_01C002F4.01DCD7A0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
    Sorry I caused all the legalese talk.  My recent System Overview release has
been reviewed/modifed and more information added to the point you will all have
the same stuff as Yann Guidon.  He will know what to shit can & what to retain.
    Data entry is time consuming on this damn PC.  Am using the latest and greatest GATEWAY 750MHZ, 256mbyte RAM (It blows my mind that ANY computer requires this much Program space to reduce Program swapping.  And
what good is 750mhz for data entry - as I am doing - NONE.  The Software I am
going to CAPTURE will do the same as virtually ALL of the MICROSOFT crap and much more efficiently.  7500 lines of code - period.  None of this irritating crap
I am getting with Microsoft Word 2000.  Major difference - NO GAMES. I play a
Timed game of Solitaire occassionally and when I win a game the response is so
good - I can't see my Bonus Score.  Am I impressed? NO.  Are you impressed
with wait time of your Local Network, for those of you that are using it. All I hear is
complaints.  With my System architecture this is G-O-N-E!!  While your system
is doing its Giga-bit serial transfer with EDAC - my approach already has stored
the data on the required Hard Drive or retrieved the data and is displaying it.
    Sorry for getting stirred up - I must get back to writing.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates.
------=_NextPart_000_001A_01C002F4.01DCD7A0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00908 for ; Fri, 11 Aug 2000 12:51:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:00 +0200 (MEST) Received: (qmail 2371 invoked by uid 0); 10 Aug 2000 23:01:10 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 10 Aug 2000 23:01:10 -0000 X-eGroups-Return: sentto-1101623-585-965948466-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 10 Aug 2000 23:01:09 -0000 Received: (qmail 18588 invoked from network); 10 Aug 2000 23:01:04 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Aug 2000 23:01:04 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 10 Aug 2000 23:01:04 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e7AN16J17085; Thu, 10 Aug 2000 19:01:06 -0400 Message-Id: <200008102301.e7AN16J17085@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 19:01:06 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eacb874665e95afe9d016c790dde685a Status: R X-Status: N Yann Guidon <whygee@f-cpu.org> wrote:

>thanks for this precision :-)
>
>in fact the manual is meant to be a one-fit-all document, except a holy bible (let's remain critic).
>but now the description it holds is what ?
>
>i hate to think about legal problems. I really hate it. so i leave the subject to those who have more
>balls and/or time.

I'm closer to being focused on my own projects.  I don't need the distraction either.  Between some projects that entail NDAs (at work and elsewhere), my 3 domain names, and F-CPU (comments on the last idea?) I've got my hands full, but I do want to have fun.

>> Rares

>we don't implement ! that's all the trick :-) we can say "this is that" but
>this is the guy who has to fund/make the chip who actually infringes the patent (if this
>can ever be proved).

It's my idea but it's your money.  I like that.

>The f-cpu project can't afford or waste time, money, ressources and >corrupt itself
>into the system from which we want to get out.
>(btw, if anyone
>can trademark the f-cpu brand with its logo in the US and anywhere else, please
>talk about it on the list). the patent issue is much more complex and ressource-wasting.
>it's not worth at our current level. Even at Nate's level. We're gentlemen, right ?

You can't trademark something people don't recognize yet.

>> -- Jecel
>
>> Is this not a good starting point for GPHardwareL
>> http://www.lart.tudelft.nl/LICENSE
>> Patrick Pelgrims
>
>i'll take a look. can others do the same ?

My vote: yes it's definitely a good start perhaps in f-cpu-licensing-list?

>WHYGEE
Rares


Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00911 for ; Fri, 11 Aug 2000 12:51:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:02 +0200 (MEST) Received: (qmail 19230 invoked by uid 0); 10 Aug 2000 23:10:16 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 10 Aug 2000 23:10:16 -0000 X-eGroups-Return: sentto-1101623-587-965949010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 10 Aug 2000 23:10:14 -0000 Received: (qmail 11497 invoked from network); 10 Aug 2000 23:10:09 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 10 Aug 2000 23:10:09 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 10 Aug 2000 23:10:09 -0000 Received: from f-cpu.org (nas3-36.ras.club-internet.fr [195.36.203.36]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA25928 for ; Fri, 11 Aug 2000 01:10:06 +0200 (MET DST) Message-ID: <39933641.F90482AD@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008101859.e7AIxm011553@tbird.iworld.com> <00081016494403.00385@gandalf> <39930FFE.DD7EFD09@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 01:09:53 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e2c2051c361ee18a4c0ef4608de85719 Status: R X-Status: N pelgrims p wrote:
> Is this not a good starting point for GPHardwareL
> http://www.lart.tudelft.nl/LICENSE
> Patrick Pelgrims

ok, this is a "weak" copyright notice with the usual
disclaimers. it's terribly weak for our purpose.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00914 for ; Fri, 11 Aug 2000 12:51:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:02 +0200 (MEST) Received: (qmail 9667 invoked by uid 0); 10 Aug 2000 23:10:17 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 10 Aug 2000 23:10:17 -0000 X-eGroups-Return: sentto-1101623-586-965949010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 10 Aug 2000 23:10:12 -0000 Received: (qmail 29535 invoked from network); 10 Aug 2000 23:10:09 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Aug 2000 23:10:09 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 10 Aug 2000 23:10:09 -0000 Received: from f-cpu.org (nas3-36.ras.club-internet.fr [195.36.203.36]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA16489 for ; Fri, 11 Aug 2000 01:10:06 +0200 (MET DST) Message-ID: <39933643.C58462B1@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008101817.e7AIH4x05403@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 01:09:55 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9964ec1780b568ac557bfaff12a4a807 Status: R X-Status: N wow, rare's cerebral gears are at it again :-)

Rares Marian wrote:
<snip>


i don't see the point of reducing the number of bits in the instruction.
today's difficulties are to execute MORE instructions per unit of time,
not to reduce the size taken by the instructions. this is just a constructive
comment, of course this is not personal. as always. i just wanted to point
that it was off-topic. anyway.
some of your precedent attemps almost convinced me : try harder ! :-)

later,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00920 for ; Fri, 11 Aug 2000 12:51:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:04 +0200 (MEST) Received: (qmail 27073 invoked by uid 0); 10 Aug 2000 23:19:38 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 10 Aug 2000 23:19:38 -0000 X-eGroups-Return: sentto-1101623-588-965949572-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 10 Aug 2000 23:19:35 -0000 Received: (qmail 3587 invoked from network); 10 Aug 2000 23:19:31 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 10 Aug 2000 23:19:31 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 10 Aug 2000 23:19:31 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id SAA23062 for ; Thu, 10 Aug 2000 18:19:30 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39933643.C58462B1@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 18:19:30 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 11e409f3f3216b4a4de3887a76db680f Status: R X-Status: N

On Fri, 11 Aug 2000, Yann Guidon wrote:

> wow, rare's cerebral gears are at it again :-)
>
> Rares Marian wrote:
> <snip>
>
> 
> i don't see the point of reducing the number of bits in the instruction.
> today's difficulties are to execute MORE instructions per unit of time,
> not to reduce the size taken by the instructions. this is just a constructive
> comment, of course this is not personal. as always. i just wanted to point
> that it was off-topic. anyway.
> some of your precedent attemps almost convinced me : try harder ! :-)
>

There is a guy working in the office next to me,and his thesus was about
code compression: make the code smaller. And one of his conclusions was
that programs would load faster and run a littel bit faster...

It reduce also the need for memory, and as the F-cpu will be a cheap chip
(no copy wrights) it will probably used in systems with a minimal amount
of memory.

So if you look only on the scale of a microprocessor, okay it doesn't
realy  matter, but on a operational system it can.



--SVDH
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00923 for ; Fri, 11 Aug 2000 12:51:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:04 +0200 (MEST) Received: (qmail 2094 invoked by uid 0); 11 Aug 2000 00:28:39 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 11 Aug 2000 00:28:39 -0000 X-eGroups-Return: sentto-1101623-589-965953713-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 11 Aug 2000 00:28:39 -0000 Received: (qmail 23878 invoked from network); 11 Aug 2000 00:28:32 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Aug 2000 00:28:32 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 11 Aug 2000 00:28:32 -0000 Received: from f-cpu.org (nas4-163.aub.club-internet.fr [195.36.145.163]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA02252 for ; Fri, 11 Aug 2000 02:28:28 +0200 (MET DST) Message-ID: <39934899.DA7548DB@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008102301.e7AN16J17085@tbird.iworld.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 02:28:09 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2df589821d76113e1e7a02e536ec0cb Status: R X-Status: N hi again,

Rares Marian wrote:
> >we don't implement ! that's all the trick :-) we can say "this is that" but
> >this is the guy who has to fund/make the chip who actually infringes the patent (if this
> >can ever be proved).
> It's my idea but it's your money.  I like that.
easier to say than to do. but worse the bet. as we both know, we have no time to loose
with the crancky, money-hungry, legal vampires.

the idea behind this is that our project is a design project. The goal/constitution
of the project is not the make and sell, but design a CPU. As long as what we do is
describe, it's ok : you can reproduce a patent without infringing it. Same as with
texts. but this changes when you build the damn stuff. As long as the F-CPU project is
"in the sky", thinking about this or that, it doesn't infringes ANYTHING.
you know the painting, "this is not a pipe". if there's a patent on a pipe, describing
it doesn't infringe this patent. This is a legal protection that's worth the rest for me.

> >The f-cpu project can't afford or waste time, money, ressources and >corrupt itself
> >into the system from which we want to get out.
> >(btw, if anyone
> >can trademark the f-cpu brand with its logo in the US and anywhere else, please
> >talk about it on the list). the patent issue is much more complex and ressource-wasting.
> >it's not worth at our current level. Even at Nate's level. We're gentlemen, right ?
>
> You can't trademark something people don't recognize yet.

we did in France. So i presume that it's possible otherwise.
If you're not happy, or if there's a need for proofs of existence,
we have some archives. I can even send you an issue of a US magazine
that speaks about us in the edito. as long as your check is backed by
your bank, i guess they won't ever ask for prior art certification.

> >> Is this not a good starting point for GPHardwareL
> >> http://www.lart.tudelft.nl/LICENSE
> >> Patrick Pelgrims
> >i'll take a look. can others do the same ?
> My vote: yes it's definitely a good start perhaps in f-cpu-licensing-list?
do you want to open the mailing list ?
i guess that it's the right time to do this.
subscribe me if you do.

> >WHYGEE
> Rares
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00926 for ; Fri, 11 Aug 2000 12:51:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:05 +0200 (MEST) Received: (qmail 22594 invoked by uid 0); 11 Aug 2000 00:57:52 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 11 Aug 2000 00:57:52 -0000 X-eGroups-Return: sentto-1101623-590-965955464-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 11 Aug 2000 00:57:49 -0000 Received: (qmail 20670 invoked from network); 11 Aug 2000 00:57:43 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 11 Aug 2000 00:57:43 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 11 Aug 2000 00:57:43 -0000 Received: from f-cpu.org (nas4-168.aub.club-internet.fr [195.36.145.168]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA18024 for ; Fri, 11 Aug 2000 02:57:40 +0200 (MET DST) Message-ID: <39934F6D.A22032D6@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 02:57:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 052d2f5edd12ca519f7ed6da4e8426f9 Status: R X-Status: N hi,

Steve Van der Hoeven wrote:
> There is a guy working in the office next to me,and his thesus was about
> code compression: make the code smaller. And one of his conclusions was
> that programs would load faster and run a littel bit faster...

what would be interesting is : read this thesis. if it's online,
it's even better :-)

> It reduce also the need for memory, and as the F-cpu will be a cheap chip
> (no copy wrights) it will probably used in systems with a minimal amount
> of memory.

my own experience is that with a superscalar, pipelined x86 CPU with the code
running in Icache (no Icache hit), the code size doesn't impact the performance.
scheduling and register allocation do (since it's register-starving).

The problem might change if the code misses the cache : then the problem
is about bandwidth arithmetics. If the code loads faster, the bandwidth
is decreased and there's more bandwidth for the data. But i see nothing,
no argument towards smaller instruction words : the counter-example is the
the VLIW trend ;-P


> So if you look only on the scale of a microprocessor, okay it doesn't
> realy  matter, but on a operational system it can.

it could. But the f-cpu is a general purpose CPU, meant to be extended
to any techniclly possible extent. the 8-bits, 16-bits and 32-bits CPU markets
are already saturated, we have no "industrial" chance to succeed in that branch.
there's more room free in the 64-bit branch because (except the ALPHA) most of the
CPUs there are "extended" 32-bitters. We are an alternative (among others)
but we can't compete even in the 32-bit world, there's nothing left to invent there.

good night, i gotta work ;-)
> --SVDH
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00929 for ; Fri, 11 Aug 2000 12:51:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:06 +0200 (MEST) Received: (qmail 7391 invoked by uid 0); 11 Aug 2000 01:48:41 -0000 Received: from hn.egroups.com (208.50.99.199) by mx06.rz2.gmx.net with SMTP; 11 Aug 2000 01:48:41 -0000 X-eGroups-Return: sentto-1101623-591-965958073-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 11 Aug 2000 01:48:39 -0000 Received: (qmail 3191 invoked from network); 11 Aug 2000 01:41:13 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Aug 2000 01:41:13 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 11 Aug 2000 01:41:13 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e7B1fEe27459; Thu, 10 Aug 2000 21:41:14 -0400 Message-Id: <200008110141.e7B1fEe27459@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 21:41:14 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e8bb1677806b0d3375911c73cb3ebb32 Status: R X-Status: N Yann Guidon <whygee@f-cpu.org> wrote:

>wow, rare's cerebral gears are at it again :-)

Okay, how's this:
If the arrangement is predefined there's less work for the rest of the system to do.

By saving the bits you get to shove more instructions into the system. 
Perhaps you could load both streams of registers at the same time.
You would be able to literally flood the thing with work to do.  And you would still be able to optimize at runtime.

But I guess I'll have to present the HDL to prove this.  Fine :)

>Rares Marian wrote:
><snip>
>
>
>i don't see the point of reducing the number of bits in the instruction.
>today's difficulties are to execute MORE instructions per unit of time,
>not to reduce the size taken by the instructions. this is just a constructive
>comment, of course this is not personal. as always. i just wanted to point
>that it was off-topic. anyway.
>some of your precedent attemps almost convinced me : try harder ! :-)

>later,
>WHYGEE

Rares


Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00932 for ; Fri, 11 Aug 2000 12:51:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:07 +0200 (MEST) Received: (qmail 23024 invoked by uid 0); 11 Aug 2000 03:19:56 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 11 Aug 2000 03:19:56 -0000 X-eGroups-Return: sentto-1101623-592-965963986-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 11 Aug 2000 03:19:54 -0000 Received: (qmail 9530 invoked from network); 11 Aug 2000 03:19:45 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Aug 2000 03:19:45 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 11 Aug 2000 03:19:45 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id WAA26119 for ; Thu, 10 Aug 2000 22:19:44 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39934F6D.A22032D6@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 22:19:44 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c7fa593a7288f87d6206d13473f00b0c Status: R X-Status: N

On Fri, 11 Aug 2000, Yann Guidon wrote:

> hi,
>
> Steve Van der Hoeven wrote:
> > There is a guy working in the office next to me,and his thesus was about
> > code compression: make the code smaller. And one of his conclusions was
> > that programs would load faster and run a littel bit faster...
>
> what would be interesting is : read this thesis. if it's online,
> it's even better :-)
>
http://www.iro.umontreal.ca/~latendre/publications/these.ps

Sorry it's in french...


svdh
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00935 for ; Fri, 11 Aug 2000 12:51:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:08 +0200 (MEST) Received: (qmail 1602 invoked by uid 0); 11 Aug 2000 03:20:52 -0000 Received: from ef.egroups.com (208.50.144.95) by mx19.rz2.gmx.net with SMTP; 11 Aug 2000 03:20:52 -0000 X-eGroups-Return: sentto-1101623-593-965964044-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ef.egroups.com with NNFMP; 11 Aug 2000 03:20:50 -0000 Received: (qmail 31142 invoked from network); 11 Aug 2000 03:20:44 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Aug 2000 03:20:44 -0000 Received: from unknown (HELO mail2.primary.net) (216.87.38.218) by mta1 with SMTP; 11 Aug 2000 03:20:44 -0000 Received: from [192.168.1.40] (ip119-tc3.busprod.com [207.150.72.119]) by mail2.primary.net (8.10.0+jb/8.10.0/8.10-0+tht) with ESMTP id e7B3EUN11747 for ; Thu, 10 Aug 2000 22:14:34 -0500 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: In-Reply-To: <395C5EFC.29A74153@hl.siemens.de> References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 20:21:34 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Adders/Subtractors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 39ad56abba5ed4082591f4b720e2b839 Status: R X-Status: N
Dear Nicolas Boulay,

Yes, even when the clock is stopped, bipolar transistor logic draws
"static" current. This includes ECL (emitter coupled logic) and IIL
(integrated injection logic).

So if a CPU usually has its clock stopped (but power turned on), then it
will draw far less power if implemented in CMOS than in some bipolar
transistor logic.

All my ECL books (looking for info on IIL) show that bipolar transistor
logic uses roughly the same amount of power no matter what clock frequency
is used. While the power used by CMOS is roughly proportional to clock
frequency.

So if a CPU usually runs at a very high clock rate, then it will draw far
less power if implemented in bipolar transistor logic than in CMOS.

I've seen graphs showing this in many different books. The first one that
comes to hand is
  _Signetics High-Speed CMOS Data Manual_ (1986)
which shows a cross-over frequency of 1 MHz (above which the 74LS00 uses
less power than the 74HC00).

I presume that you want to design a CPU with a clock rate faster than 1 MHz.

Other graphs on the same page show that different functions cross over at
different frequencies -- 20 MHz (74LS138 vs. 74HC138), and one that never
crossed over (at any given frequency, 74HC243 always consumed less power
than the 74LS243).

>From: Nicolas Boulay <emstud2@hl.siemens.de>
>Date: Fri, 30 Jun 2000 10:49:00 +0200
>Subject: Re: [f-cpu] Adders/Subtractors
...
>> Bipolar is getting much cooler as we go down in feature size, and getting
>> much denser and faster.  It is impossible to explain to some, but
>>bipolar now
>> offers the possibility of LOWER power consumption per clock signal per
>> device.
>
>I would know how it could be possible ! Bipolar transistor need to be
>polarised, to that little currant sources are used. So even in static,
>the bipolar technology have a worse power consumption than MOS.
...
>nicO

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00938 for ; Fri, 11 Aug 2000 12:51:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:09 +0200 (MEST) Received: (qmail 668 invoked by uid 0); 11 Aug 2000 03:21:03 -0000 Received: from b05.egroups.com (208.50.144.96) by mx12.rz2.gmx.net with SMTP; 11 Aug 2000 03:21:03 -0000 X-eGroups-Return: sentto-1101623-594-965964054-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by b05.egroups.com with NNFMP; 11 Aug 2000 03:20:57 -0000 Received: (qmail 8366 invoked from network); 11 Aug 2000 03:20:53 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Aug 2000 03:20:53 -0000 Received: from unknown (HELO mail2.primary.net) (216.87.38.218) by mta1 with SMTP; 11 Aug 2000 03:20:53 -0000 Received: from [192.168.1.40] (ip119-tc3.busprod.com [207.150.72.119]) by mail2.primary.net (8.10.0+jb/8.10.0/8.10-0+tht) with ESMTP id e7B3EhN12259 for ; Thu, 10 Aug 2000 22:14:43 -0500 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: In-Reply-To: <395C95C9.19B9848D@f-cpu.org> References: <001e01bfe066$19437300$3bf43cd0@0018728164> <395995A1.2FCF8B12@nventure.com> <3959C30E.BF14EE99@f-cpu.org> <3959C553.48B948EB@hl.siemens.de> <395AF6A5.1A8580D7@nventure.com> <395B6CD4.F41781FF@hl.siemens.de> <395BD04F.76B62CCA@nventure.com> <395C3588.9029A35D@nventure.com> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 20:23:19 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] fast clock + slow clock Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b40059b409f9087c15825dc7d7f19b86 Status: R X-Status: N
Dear team mates,

While Y.G. has far more clues than most people I know, I want to nitpick
one little statement:

>From: Yann Guidon <whygee@f-cpu.org>
>Date: Fri, 30 Jun 2000 14:42:49 +0200
>Subject: Re: [f-cpu] SHP uP's [was Adders/Subtractors]
...
>But VLIW/RISC have the same electronical problems when it comes
>to clock trees : it depends on the die surface, not the complexity
>of the core(s). So if you put several cores on one die, you'll
>have as much pain with the clock as with one big complex core.
...
>WHYGEE

Yes, the clock tree problem gets worse and worse with larger designs. But I
think having lots of almost-independent CPUs (is that what you mean by
"several cores" ?) might have much less pain than one big complex CPU.

If you have lots of independent CPUs, each with its own (small) L1 cache,
then they can all run pretty much independently of each other, only
occasionally synchronizing. Maybe we could give each CPU its own PLL, so
that the "big clock tree" that runs all over the entire chip could run
relatively slowly (think 200 MHz), while each core could run independently
(until it needs to synchronize with others or access global resources like
the L2 cache) at a much higher speed (think 1 GHz).

Even though the nodes of a Transputer communicated serially at 1 Mbps (is
that right ?), the (independent) clock of a particular node was much faster.

I know that running a "big clock tree" is a lot easier to do at lower
frequencies. And I know that running at very high frequencies is a lot
easier when it only needs to run a short distance, rather than all over the
chip. Would those benefits more than make up for the extra complexity of
having both a fast clock and a slow clock ?

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00944 for ; Fri, 11 Aug 2000 12:51:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:10 +0200 (MEST) Received: (qmail 8051 invoked by uid 0); 11 Aug 2000 03:56:49 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 11 Aug 2000 03:56:49 -0000 X-eGroups-Return: sentto-1101623-595-965966082-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 11 Aug 2000 03:55:12 -0000 Received: (qmail 28656 invoked from network); 11 Aug 2000 03:54:31 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 11 Aug 2000 03:54:31 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 11 Aug 2000 03:54:31 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id WAA26539 for ; Thu, 10 Aug 2000 22:54:30 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 10 Aug 2000 22:54:30 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fast clock + slow clock Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c6205d3c188b4c461631ce0064a82d6c Status: R X-Status: N

On Thu, 10 Aug 2000, David Cary wrote:

>
> Dear team mates,
>
> While Y.G. has far more clues than most people I know, I want to nitpick
> one little statement:
>
> >From: Yann Guidon <whygee@f-cpu.org>
> >Date: Fri, 30 Jun 2000 14:42:49 +0200
> >Subject: Re: [f-cpu] SHP uP's [was Adders/Subtractors]
> ...
> >But VLIW/RISC have the same electronical problems when it comes
> >to clock trees : it depends on the die surface, not the complexity
> >of the core(s). So if you put several cores on one die, you'll
> >have as much pain with the clock as with one big complex core.
> ...
> >WHYGEE
>

If I understand, the "tree clock" is a distribution of a signal clock
signal (multiplied or not) over the complet cpu to synchrnize it.

And at high frequency the different units, if they are too fare from each
other get desynchronized due to interferences and reflexion in the
circuit.

There is a wierd processor the MuP21. I cannot find the exact info 
again, but I had read one day, it uses the external clocks only for
synchronization with the "external world", inside it used data
synchronization. So there is no need to distribute the clock...
each unit works at it's maximum speed, when there is data.


http://www.ultratechnology.com/chips.htm


--svdh
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00947 for ; Fri, 11 Aug 2000 12:51:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:11 +0200 (MEST) Received: (qmail 30277 invoked by uid 0); 11 Aug 2000 04:23:07 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 11 Aug 2000 04:23:07 -0000 X-eGroups-Return: sentto-1101623-596-965967785-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 11 Aug 2000 04:23:06 -0000 Received: (qmail 28620 invoked from network); 11 Aug 2000 04:23:04 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Aug 2000 04:23:04 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 11 Aug 2000 04:23:04 -0000 Received: from f-cpu.org (nas4-188.aub.club-internet.fr [195.36.145.188]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA11649 for ; Fri, 11 Aug 2000 06:22:48 +0200 (MET DST) Message-ID: <39937F6F.DB4CAE26@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 06:22:07 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Design ideas Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ab0a84dc82ec83f8f5d6b5f6bbefe4e Status: R X-Status: N hi !

Steve Van der Hoeven wrote:
> On Fri, 11 Aug 2000, Yann Guidon wrote:
> > hi,
> > Steve Van der Hoeven wrote:
> > > There is a guy working in the office next to me,and his thesus was about
> > > code compression: make the code smaller. And one of his conclusions was
> > > that programs would load faster and run a littel bit faster...
> > what would be interesting is : read this thesis. if it's online,
> > it's even better :-)
> http://www.iro.umontreal.ca/~latendre/publications/these.ps
thanks !
> Sorry it's in french...
maybe i can read my mother's langage ? :-P

ok don't worry, i'll comment it whenever i can download it.

> svdh
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00950 for ; Fri, 11 Aug 2000 12:51:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:12 +0200 (MEST) Received: (qmail 4437 invoked by uid 0); 11 Aug 2000 04:26:59 -0000 Received: from mr.egroups.com (208.50.144.80) by mx06.rz2.gmx.net with SMTP; 11 Aug 2000 04:26:59 -0000 X-eGroups-Return: sentto-1101623-597-965968010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mr.egroups.com with NNFMP; 11 Aug 2000 04:26:58 -0000 Received: (qmail 4446 invoked from network); 11 Aug 2000 04:26:49 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Aug 2000 04:26:49 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 11 Aug 2000 04:26:49 -0000 Received: from f-cpu.org (nas4-188.aub.club-internet.fr [195.36.145.188]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA26363 for ; Fri, 11 Aug 2000 06:20:06 +0200 (MET DST) Message-ID: <39938062.99E6BD19@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 06:26:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fast clock + slow clock Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b0c5bb5002c306e49e74f413eb877e2 Status: R X-Status: N hi again,

Steve Van der Hoeven wrote:
> If I understand, the "tree clock" is a distribution of a signal clock
> signal (multiplied or not) over the complet cpu to synchrnize it.
more or less, yes...

> And at high frequency the different units, if they are too fare from each
> other get desynchronized due to interferences and reflexion in the
> circuit.
more or less, too...

> There is a wierd processor the MuP21. I cannot find the exact info
> again, but I had read one day, it uses the external clocks only for
> synchronization with the "external world", inside it used data
> synchronization. So there is no need to distribute the clock...
> each unit works at it's maximum speed, when there is data.
>
> http://www.ultratechnology.com/chips.htm
oh it's Chuck Moore's CPU. it's really weird, completely hand-made and
reduced number of transistors. they have a lot of problem, ie to scale it
or to use different SiO2 processes.

a recent discussion (about POC or "Pipeline Ordered Clocking") concluded that
the tools (EDA) are not ready to do anything as smart. too bad.

> --svdh
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00974 for ; Fri, 11 Aug 2000 12:51:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:19 +0200 (MEST) Received: (qmail 7872 invoked by uid 0); 11 Aug 2000 07:21:38 -0000 Received: from hj.egroups.com (208.50.99.212) by mx11.rz2.gmx.net with SMTP; 11 Aug 2000 07:21:38 -0000 X-eGroups-Return: sentto-1101623-598-965978494-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hj.egroups.com with NNFMP; 11 Aug 2000 07:21:36 -0000 Received: (qmail 6783 invoked from network); 11 Aug 2000 07:21:34 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 11 Aug 2000 07:21:34 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 11 Aug 2000 07:21:33 -0000 Received: from dotcom.fr (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA02121 for ; Fri, 11 Aug 2000 07:21:32 GMT Message-ID: <3993A9A5.A88441E3@dotcom.fr> Organization: DotCom S.A. X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <6742DE8EC0C0CE0D80256937004FA7E5.0000000000000000@chrystal.gbr.xerox.com> <3992E568.28BC0434@f-cpu.org> <3992E9BE.36EE7B58@pandora.be> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 09:22:13 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b9e275ae68701b20a1676209c3b6095b Status: R X-Status: N pelgrims p a =E9crit :
>
> Yann Guidon wrote:

> > As for the F-CPU, you seemed to volunteer to make a f-cpu lincenc= e
> > ;-) unfortunately, the GPL as it is can't be applied to every par= t
> > of our project. the manual is protected by the GFDL, the C source= s
> > are protected by the GPL, but the VHDL or the mask files can't be=
> > protected with any of them. they can be copyrighted, that's all.<= BR>
> What type of licence is used for the functional units on the
> www.opencores.org  ?
> Is it not possibel to define a new type of GPHardwareL (GPHL) licence<= BR> > unther which one can put they "own" designs. VHDL is a hardw= are
> description and the implementation can also be protected by that new > type of licence.

I don't understand why source code (VHDL or Verilog) can't be protected
by existing public licenses (GPL or whatever). It's only source code,
like C.
HDL is only a *functionnal* description. Different synthesis tools won't produce exactly the same hardware from the same source code (that's why
I am currently running the same design through 2 synthesizers to see
which is the best).
I don't think EDIF netlists (synthesis output format) can be protected
by existing licenses but HDL source code should.

--
Nicolas MATRINGE          = ; DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.dotcom.fr/
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00987 for ; Fri, 11 Aug 2000 12:51:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 11 Aug 2000 12:51:22 +0200 (MEST) Received: (qmail 5117 invoked by uid 0); 11 Aug 2000 08:25:39 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 11 Aug 2000 08:25:39 -0000 X-eGroups-Return: sentto-1101623-599-965982335-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 11 Aug 2000 08:25:38 -0000 Received: (qmail 17571 invoked from network); 11 Aug 2000 08:25:34 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Aug 2000 08:25:34 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 11 Aug 2000 08:25:34 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA04976 for f-cpu@egroups.com; Fri, 11 Aug 2000 04:25:34 -0400 Message-Id: <200008110825.EAA04976@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <39934899.DA7548DB@f-cpu.org> from "Yann Guidon" at Aug 11, 2000 02:28:09 AM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 04:25:33 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e43d68464cb95d626cae56250f07b79a Status: R X-Status: N > > My vote: yes it's definitely a good start perhaps in f-cpu-licensing-list?
> do you want to open the mailing list ?
> i guess that it's the right time to do this.
> subscribe me if you do.

Some time ago I realised two things: that license discussions tend
to dominate mailing lists when they start (and really annoy people
who just want to get on with work), and that the same discussions
get repeated independently in different groups, each time going
through exactly the same points... To try and get round this I
set up a mailing list just for hardware license discussion. It didn't
take off; after a long discsussion with Richard Stallman, its
been quiet for several months. You can see the archives from
http://opencollector.org/hardlicense/licensezone.html

In the mean time I've been trying to write a gpl-inspired
license, but still have problems I can't solve. I was planning
to try to revive my mailing list by cross-posting Whygee's earlier
license proposals to it, and maybe some of my own suggestions. What
do you think? If you can use my existing list, I'll try to put more
work into supporting the list, adding useful links etc. Otherwise,
I'll happily join an f-cpu-licensing-list list...

Graham
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00304 for ; Tue, 15 Aug 2000 09:44:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:44:36 +0200 (MEST) Received: (qmail 29901 invoked by uid 0); 11 Aug 2000 11:35:22 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 11 Aug 2000 11:35:22 -0000 X-eGroups-Return: sentto-1101623-600-965993715-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 11 Aug 2000 11:35:15 -0000 Received: (qmail 13290 invoked from network); 11 Aug 2000 11:35:14 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 11 Aug 2000 11:35:14 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 11 Aug 2000 11:35:14 -0000 Received: from 0018728164 (host-209-214-154-135.bix.bellsouth.net [209.214.154.135]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA14608; Fri, 11 Aug 2000 07:35:12 -0400 (EDT) Message-ID: <000a01c00388$2cfd3080$879ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 06:34:55 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] System Summary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0035E.4309D1A0" X-UIDL: 9b0b17ac7d53b068f8a9df62176beee4 Status: R X-Status: N ------=_NextPart_000_0007_01C0035E.4309D1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On completion of this short note, I will send an updated version of my Syst= em Summary - discard previous copy. I will appreciate any input pro/con. I a= ssure you I will not be affended in any way - as long as you cuss me in English. Richard E. Hartney Research Director Erin Greene & Associates. ------=_NextPart_000_0007_01C0035E.4309D1A0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
On completion of this short note, I will send an updated version of my System
Summary - discard previous copy.  I will appreciate any input pro/con.  I assure
you I will not be affended in any way - as long as you cuss me in English.
 
Richard E. Hartney
Research Director
Erin Greene & Associates.
 
------=_NextPart_000_0007_01C0035E.4309D1A0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00307 for ; Tue, 15 Aug 2000 09:44:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:44:36 +0200 (MEST) Received: (qmail 1431 invoked by uid 0); 11 Aug 2000 11:37:39 -0000 Received: from fg.egroups.com (208.50.144.70) by mx06.rz2.gmx.net with SMTP; 11 Aug 2000 11:37:39 -0000 X-eGroups-Return: sentto-1101623-601-965993840-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 11 Aug 2000 11:37:26 -0000 Received: (qmail 15485 invoked from network); 11 Aug 2000 11:37:20 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Aug 2000 11:37:20 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta1 with SMTP; 11 Aug 2000 11:37:19 -0000 Received: from 0018728164 (host-209-214-154-156.bix.bellsouth.net [209.214.154.156]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA00067; Fri, 11 Aug 2000 07:36:59 -0400 (EDT) Message-ID: <000901c00388$6c995e80$9c9ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 06:36:07 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C0035E.6DFD4D60" X-UIDL: b292b77dd5aae6795695db1a14e6d52a Status: R X-Status: N ------=_NextPart_000_0005_01C0035E.6DFD4D60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C0035E.6DFD4D60" ------=_NextPart_001_0006_01C0035E.6DFD4D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0006_01C0035E.6DFD4D60 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
 
------=_NextPart_001_0006_01C0035E.6DFD4D60-- ------=_NextPart_000_0005_01C0035E.6DFD4D60 Content-Type: application/msword; name="DOC1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DOC1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAmgAAAAAAAAAA EAAAnAAAAAEAAAD+////AAAAAJgAAACZAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAPHYAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIqwAADd8AAA3fAAAIXIAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAB4DAAAAAAAAHgMAAB4D AAAAAAAAHgMAAAAAAAAeAwAAAAAAAB4DAAAAAAAAHgMAABQAAAAAAAAAAAAAADIDAAAAAAAAqjgA AAAAAACqOAAAAAAAAKo4AAA4AAAA4jgAAAwAAADuOAAAxAAAADIDAAAAAAAAEF0AALYAAAC+OQAA AAAAAL45AAAiAAAA4DkAAAAAAADgOQAAAAAAAOA5AAAAAAAA4DkAAAAAAADgOQAAAAAAAOA5AAAA AAAAs1wAAAIAAAC1XAAAAAAAALVcAAAAAAAAtVwAAAAAAAC1XAAAAAAAALVcAAAAAAAAtVwAAAAA AADGXQAAIAIAAOZfAADiAAAAtVwAABUAAAAAAAAAAAAAAAAAAAAAAAAAHgMAAAAAAADgOQAAAAAA AAAAAAAAAAAAAAAAAAAAAADgOQAAAAAAAOA5AAAAAAAA4DkAAAAAAADgOQAAAAAAALVcAAAAAAAA VEcAAAAAAAAeAwAAAAAAAB4DAAAAAAAA4DkAAAAAAAAAAAAAAAAAAOA5AAAAAAAAylwAABYAAABU RwAAAAAAAFRHAAAAAAAAVEcAAAAAAADgOQAAEgQAAB4DAAAAAAAA4DkAAAAAAAAeAwAAAAAAAOA5 AAAAAAAAs1wAAAAAAAAAAAAAAAAAAFRHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA4DkAAAAAAACzXAAAAAAAAFRHAACGBAAAVEcAAAAAAADaSwAA xgAAAP9aAACQAAAAHgMAAAAAAAAeAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs1wAAAAAAADgOQAAAAAAALI5AAAMAAAAoP6fRogD wAEyAwAAeDUAAKo4AAAAAAAA8j0AAAoJAACPWwAAFAAAAAAAAAAAAAAAs1wAAAAAAADgXAAAMAAA ABBdAAAAAAAAo1sAABABAADIYAAAAAAAAPxGAABYAAAAyGAAAAAAAACzXAAAAAAAAFRHAAAAAAAA MgMAAAAAAAAyAwAAAAAAAB4DAAAAAAAAHgMAAAAAAAAeAwAAAAAAAB4DAAAAAAAAAgDZAAAADQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICBFUklOIEdSRUVORSAmIEFTU09DSUFURVMNQnVzaW5l c3MgSW5mb3JtYXRpb24gTWFuYWdlbWVudCBTeXN0ZW1zDTI2MTMgTm9ydGggMTF0aCBTdHJlZXQN T2NlYW4gU3ByaW5ncywgTWlzc2lzc2lwcGkgIDM5NTY0LTgzNjQNDQ1QaG9uZSAyMjgtODc1LTYw MDMNZS1tYWlsICByaGFydG5leUBiZWxsc291dGgubmV0DQ0NDQ0NDQ0NDQ0NDVNZU1RFTSBPVkVS VklFVw0NDQ0NDQ0NDQ0NDQ0NDQ0NDUFVR1VTVCAyMDAwDQxTWVNURU0gT1ZFUlZJRVcNDQ0xLiAg VEhFIFBST0RVQ1QNCVRoZSBvYmplY3RpdmUgaXMgdG8gcHJvZHVjZSBhIGxvdyBjb3N0LCBoaWdo IHBlcmZvcm1hbmNlLCB1c2VyIG9wZXJhdGVkDUxpZ2h0cGVuL01vdXNlLWNvbnRyb2xsZWQgRGlz cGxheSBUZXJtaW5hbCBTeXN0ZW0uDQ0JVGhlIHJlc3VsdGluZyBzeXN0ZW0gbWF5IGJlIHVzZWQg aW4gdmlydHVhbGx5IGFueSBDb21tZXJjaWFsIFNtYWxsL0xhcmdlDUJ1c2luZXNzIEFwcGxpY2F0 aW9uIGluY2x1ZGluZyBidXQgbm90IGxpbWl0ZWQgdG8gRmVkZXJhbC9TdGF0ZS9Mb2NhbCBHb3Zl cm5tZW50LA13aGVyZSBwcmVzZW50IGRheSB1c2FnZSBpcyB0aGUgUGVyc29uYWwgQ29tcHV0ZXIg KFBDKSB3aXRoIG9yIHdpdGhvdXQgTmV0d29yaw1TZXJ2ZXIgSGFyZHdhcmUvU29mdHdhcmUuICBT aW1wbHkgZGlzY2FyZCB0aGUgVG93ZXIvU2VydmVyIHdpdGggd2hhdGV2ZXIgdGhleQ1jb250YWlu OyByZXRhaW4gdGhlIHJlbWFpbmluZyBkZXZpY2VzOyBhbmQgcGx1ZyBpbiB0aGUgIG5ldyBQcm9j ZXNzaW5nIEhhcmR3YXJlDWFuZCBBcHBsaWNhdGlvbiBQcm9ncmFtcy4gIFRoaXMgc3lzdGVtIGlz IG9wZW4tZW5kZWQgdG8gYWxsIHR5cGVzIG9mIFBlcmlwaGVyYWwgZGV2aWNlcy4NQSB0eXBpY2Fs IGFwcGxpY2F0aW9uIGNvdWxkIGJlIEFMTCBEZXBhcnRtZW50cyBhbmQgQUxMIGFzc29jaWF0ZWQg ZnVuY3Rpb25zIGluIGENSG9zcGl0YWwgb3IgR1JPVVAgb2YgSG9zcGl0YWxzLiAgT3IgaXQgY291 bGQgYmUgdXNlZCBieSBOQVNBIGFzIHByZS9wb3N0IGxhdW5jaA1TeXN0ZW1zIE1vbml0b3IgYW5k IFJlbW90ZSBDb250cm9sIFN5c3RlbS4gSWYgeW91IGFzayB0aGUgcXVlc3Rpb24gliBDQU4gSVQg RE8/IJYNVGhlIGFuc3dlciBpcyBZRVMuDQ0JVGhlIHN5c3RlbSBpcyBwcm9ncmFtbWVkIGluIGEg bGFuZ3VhZ2UgY2FsbGVkIFRJUFMuICBUSVBTIGlzIGFuIGFjcm9ueW0gZm9yDVRPVEFMIElORk9S TUFUSU9OIFBST0dSQU1NSU5HIFNZU1RFTS4gIFRJUFMgaXMgYW4gaW50ZXJwcmV0aXZlIGxhbmd1 YWdlDXdoaWNoIHByb3ZpZGVzIHRoZSBBcHBsaWNhdGlvbiBQcm9ncmFtbWVyIHdpdGggdGhlIGNh cGFiaWxpdGllcyB0byBDb2xsZWN0LCBTdG9yZSwgDU1hbmlwdWxhdGUsIFN0cnVjdHVyZSBhbmQg UmV0cmlldmUgYmxvY2tzIG9mIGRhdGEuICBUaGUgbGFuZ3VhZ2UgaXMgdGhlcmVmb3JlIEZJTEUs IEZPUk0sIFBBR0UsIGFuZCBQQVJUIG9yaWVudGVkLiAgVElQUyBoYXMgYmVlbiBzcGVjaWZpY2Fs bHkgZGVzaWduZWQgdG8gZnVuY3Rpb24gaW4gYSBNdWx0aS11c2VyLCBNdWx0aS1wb3J0IGVudmly b25tZW50ICYgb2NjdXBpZXMgb25seSA4MCwwMDAgYnl0ZXMgb2YgTWVtb3J5IJYgbW9yZSBzcGVj aWZpY2FsbHkgliAgOSw5NjcgSW5zdHJ1Y3Rpb25zLiAgVGhlIEFwcGxpY2F0aW9uIFByb2dyYW1t ZXIgbWF5IGNyZWF0ZSBGb3JtcyBhdCBhbnkgVXNlciBTdGF0aW9uOyBlbnRlciByZWxhdGVkIFBy b2dyYW1zOyBUZXN0IGFuZCBNb2RpZnkgYXMgbmVlZGVkLCBiZWZvcmUgb3IgYWZ0ZXIgdGhlIHN5 c3RlbSBpcyBPbi1MaW5lLiAgVGhlc2UgZmVhdHVyZXMgYXJlIG5vdCBpbmhlcmVudCBpbiBwcmVz ZW50IGRheSBQQ5JzLiAgVGhlIHN5c3RlbSBpcyBkZXNpZ25lZCB0byBhY2NvbW1vZGF0ZSBmcm9t IDEgdG8gMTI4IFVzZXIgU3RhdGlvbnMuICBBIHBhcmFsbGVsIGV4cGFuc2lvbiBwb3J0IGlzIHBy b3ZpZGVkIGZvciCTTpQgc3ViLXN5c3RlbXMuDQ0JVGhlIFVTRVIgU1RBVElPTiBjb25zaXN0cyBv ZiBhIENSVC9GbGF0IFBhbmVsIE1vbml0b3IsIEtleWJvYXJkLCBMaWdodHBlbi9Nb3VzZSwgUHJp bnRlciwgSUQgUmVhZGVyLCBhbmQgYSBzbWFsbCBhc3NlbWJseSBjb250YWluaW5nIEludGVyZmFj ZSBMb2dpYy4gIFRoZSBhc3NlbWJseSBhbHNvIHByb3ZpZGVzIGNvbm5lY3RvcnMgZm9yIHRoZSBs b2NhbCBjb21wb25lbnRzIGFuZCBvbmUgY29ubmVjdGlvbiB0byBhIHJlbW90ZSBDb21wdXRlciBB c3NlbWJseS4gIEEgc3RhdGlvbiBtYXkgaW5jbHVkZS9leGNsdWRlIHRoZSBQcmludGVyIGFuZCBJ RCBSZWFkZXIuDQ0JVGhlIHJlbW90ZSBDT01QVVRFUiBBU1NFTUJMWSBjYW4gYWNjb21tb2RhdGUg dXAgdG8gMTI4IFVzZXIgU3RhdGlvbnMgd2l0aG91dCBub3RpY2VhYmxlIGRlZ3JhZGF0aW9uIGlu IHJlc3BvbnNlIHRvIHVzZXIgcmVxdWVzdHMuICBUaGUgbW91bnRpbmcgcmFjayBjb250YWlucyBh IExhbmd1YWdlIFByb2Nlc3NvciB3aXRoIHJlcXVpcmVkIFNSQU0gTWVtb3J5IHJlc291cmNlcyBh bmQgSW5wdXQvT3V0cHV0IENvbnRyb2xsZXJzOw1hbmQgYSBQZXJpcGhlcmFsIFByb2Nlc3NvciB3 aXRoIGl0cyByZXF1aXJlZCBTUkFNIE1lbW9yeSByZXNvdXJjZXMgYW5kIElucHV0L091dHB1dA1D b250cm9sbGVycy4gIFRoZSB0d28gcHJvY2Vzc29ycyBhcmUgaWRlbnRpY2FsIEVSSU4zMiBGUEdB IGRldmljZXMgaGF2aW5nIGlkZW50aWNhbCBJbnN0cnVjdGlvbiBTZXRzLiAgQWxzbyBwcm92aWRl ZCBpcyB0aGUgbmVjZXNzYXJ5IFBvd2VyIFN1cHBseSwgQ29vbGluZyBGYW4gQXNzZW1ibHksIEVN SQ1MaW5lIEZpbHRlcnMsIGFuZCBjb25uZWN0b3JzIGZvciBzaGllbGRlZCB0d2lzdGVkIHBhaXIg Y2FibGluZyBvZiBEaWZmZXJlbnRpYWwgRHJpdmVyL1JlY2VpdmVycy4NRmliZXIgT3B0aWNzIG1h eSBiZSB1c2VkIHdoZXJlIGRpc3RhbmNlIGlzIGEgZmFjdG9yIChjb3N0IG11c3QgYmUgY29uc2lk ZXJlZCkuDQwyLiAgSElTVE9SWSBPRiBUSEUgTEFOR1VBR0UNDVRoZSBsYW5ndWFnZSBvZiBUSVBT IGlzIGJhc2VkIHVwb24gSk9TUyAoSk9ITk5JQUMgT3Blbi1TaG9wIFN5c3RlbSB3aGljaA13YXMg ZGV2ZWxvcGVkIGJ5IHRoZSBSYW5kIENvcnBvcmF0aW9uIGluIHRoZSBlYXJseSAxOTYwknMuDQ1O b3RlOiAgUmVmZXIgdG86IEpPU1M6IEEgREVTSUdORVKSUyBWSUVXIE9GIEFOIEVYUEVSSU1FTlRB TCBPTi1MSU5FIENPTVBVVEVSIFNZU1RFTSBCWSBKLkMuIFNoYXcgb2YgdGhlIFJhbmQgQ29ycG9y YXRpb24sIFNhbnRhIE1vbmljYSwgQ2FsaWZvcm5pYQ1QUk9DRUVESU5HUyCWIEZBTEwgSk9JTlQg Q09NUFVURVIgQ09ORkVSRU5DRSwgMTk2NC4NDQlPdGhlciBlZmZvcnRzIGluIHNpbWlsYXIgZGV2 ZWxvcG1lbnRzIHdlcmUgdW5kZXJ0YWtlbiBieSB0aGUgVW5pdmVyc2l0eSBvZiBQaXR0c2J1cmcg KFBJTCkgliBQaXR0c2J1cmcgSW50ZXJwcmV0aXZlIExhbmd1YWdlKSBhbmQgU2FuZGVycyBBc3Nv Y2lhdGVzIEluY29ycG9yYXRlZCAoRk9QUyApIJYgRmlsZQ1PcmllbnRlZCBQcm9ncmFtbWluZyBT eXN0ZW0uDQ0zLiAgT0xEIFNZU1RFTSBBUkNISVRFQ1RVUkUNDQlUaGUgU2FuZGVycyBlZmZvcnQg d2FzIHN0YXJ0ZWQgaW4gMTk2NSBhbmQgdGVybWluYXRlZCBpbiAxOTcyLiBUaGUgc3lzdGVtIHVz ZWQgdHdvIEhvbmV5d2VsbCBtaW5pY29tcHV0ZXJzLCBhIEREUC01MTYgYW5kIGEgRERQLTQxNi4g IFRoZSA0MTYgaGFkIGEgcmVkdWNlZCBpbnN0cnVjdGlvbiBzZXQgYW5kIGJ1dCBvdGhlcndpc2Ug aWRlbnRpY2FsIHRvIHRoZSA1MTYuICBUaGUgdG90YWwgc3lzdGVtIHdhcyBzdGF0ZS1vZi10aGUg YXJ0IGF0IHRoZSB0aW1lLiAgTXVjaCBlZmZvcnQgd2FzIGRvbmUgaW4gbWFya2V0aW5nIJYgdG9v IG5vIGF2YWlsIJYgZHVlIHRvIGNvc3QgliBhbmQgdGhlIGVudGlyZSBEZXBhcnRtZW50IHdhcyBk aXNiYW5kZWQuDQ0JCVN5c3RlbSBkZWZpY2llbmNpZXMgaW5jbHVkZWQ6DUluYWRlcXVhdGUgQ29y ZSBNZW1vcnkgZm9yIHRoZSBMYW5ndWFnZSBQcm9jZXNzb3IgJiB0aGVyZWZvcmU6DVVzZXIgU2xv dHMgbGltaXRlZCB0byBmb3VyICg0KSAmIHRoZXJlZm9yZToNRGlzayBzd2FwcGluZyB3YXMgbmVj ZXNzYXJ5ICYgdGhlcmVmb3JlOg1EaXNrIGFjY2VzcyB3YXMgOTAgbWlsbGktc2Vjb25kcyBhdmVy YWdlICYgdGhlcmVmb3JlOg1TaXggKDYpIG9yIG1vcmUgVXNlcnMgb2YgcmFwaWQgTGlnaHRwZW4g c3RyaWtlcyByZXN1bHRlZCBpbiBub3RpY2VhYmxlDVNsb3dpbmcgaW4gcmVzcG9uc2UgdGltZS4g IEtleWJvYXJkIGlucHV0cyB3ZXJlIG5ldmVyIGEgcHJvYmxlbS4NCQ1UaGUgc2l4dGVlbiAoMTYp IGJpdCBjb21wdXRlciBoYWQgbGltaXRlZCBhZGRyZXNzaW5nIGNhcGFiaWxpdHkgYW5kIGZvcmNl ZCBJbmRpcmVjdCBvcg1JbmRleGVkIEFkZHJlc3NpbmcgZm9yIE1lbW9yeSBSZWZlcmVuY2UgSW5z dHJ1Y3Rpb25zIGluIHRvbyBtYW55IGluc3RhbmNlcy4gIFByaW9yIHRvIGJlaW5nIGRpc2JhbmRl ZCwgYW4gZWZmb3J0IGluIHJlZGVzaWduIG9mIHRoZSBERFAtNTE2IHdhcyBwdXJzdWVkIGJ1dCBu b3QgY29tcGxldGVkLg0NCURpc2sgc3RvcmFnZSB3YXMgbGltaXRlZCB0byBlaWdodCAoOCkgdW5p dHMgd2hpY2ggcHJvdmlkZWQgNi40IE1ieXRlcyBmb3IgQXBwbGljYXRpb24gUHJvZ3JhbXMgYW5k IERhdGEuICBBIGRpc2sgU2VjdG9yIGNvbnRhaW5lZCAzMiAxNi1CaXQgV29yZHMsIGluY2x1ZGlu ZyBvdmVyaGVhZCAocG9pbnRlcnMsIGRlc2NyaXB0b3JzKS4NDQlUaGUgQ1JUIE1vbml0b3JzIHdl cmUgcGh5c2ljYWxseSBwYWdlLW9yaWVudGVkIGNhcGFibGUgb2YgZGlzcGxheWluZyAxMDE5IGNo YXJhY3RlcnMNSW5jbHVkaW5nIGZvcm1hdCB0eXBlcy4gIEFsbCBjYWJsaW5nIHdhcyBkaXJlY3Qg dHdpc3RlZCBwYWlyLXBhcmFsbGVsIGRhdGEuDQwNNC4gIE5FVyBTWVNURU0gQVJDSElURUNUVVJF DQ0JVGhpcyBkZXNpZ24gaXMgc2ltaWxhciB0byBpdHMgcHJlZGVjZXNzb3Igd2l0aCB0d28gbWFq b3IgZXhjZXB0aW9ucy4gIFRoZSB0d28gcHJvY2Vzc29ycyBhcmUgaWRlbnRpY2FsIEZQR0EgZGV2 aWNlcyB3aXRoIHNpbWlsYXIgSVNBIChJbnN0cnVjdGlvbiBTZXQgQXJjaGl0ZWN0dXJlKSBhcyB0 aGUgRERQLTUxNi4gIFRoaXMgZGVzaWduIGNlYXNlZCBiZWluZyBhbiBFbXVsYXRpb24gd2hlbiAz MiBCaXQgRGF0YSB3YXMgaW5jb3Jwb3JhdGVkLiAgU2V2ZXJhbCBub24tdXNhYmxlDUluc3RydWN0 aW9ucyB3ZXJlIGRpc2NhcmRlZCBhbmQgc2V2ZXJhbCBpbnN0cnVjdGlvbnMgd2VyZSBhZGRlZC4g IFRoZSBwdXJwb3NlIGluIHJldGFpbmluZyB0aGUgSVNBIGlzIHRvIG1pbmltaXplIGNoYW5nZXMg dG8gY2FwdHVyZSBFWElTVElORyBTT0ZUV0FSRS4gIFRoZSBvdGhlciBtYWpvciBkaWZmZXJlbmNl IGlzIHRoZSB1c2Ugb2YgU1NSQU0gaW4gbGlldSBvZiBEaXNrIGZvciBBcHBsaWNhdGlvbiBQcm9n cmFtcyBhbmQgRGF0YSBTdG9yYWdlDQ1UaGUgcHJvY2Vzc29yKHMpIFByb2dyYW0gTWVtb3J5IGlz IEZvdXItUG9ydCB3aGVyZToNCVBvcnQgMSA9IEluc3RydWN0aW9uIFNvdXJjZQ0JUG9ydCAyID0g VmVjdG9yIChKTVAsIEpTVCAoQ0FMTCksIEpNUEkgKFJUTiksIEJSQU5DSCwgSW50ZXJydXB0IChD QUxMKQ0JCSAgVGhpcyBQb3J0IHVzZXMgdGhlIEFkZHJlc3MgUmVhZC1iYWNrIG9mICB0aGUgb24t Y2hpcCBQcm9ncmFtDQkJICBDb3VudGVyIGFsc28gaGF2aW5nIGVpdGhlciBMb2FkIChWZWN0b3Ip IG9yIEluY3JlbWVudCAoUEMrMSkgZmVhdHVyZXMuDQkJICBBTkQgSW5zdHJ1Y3Rpb24gTG9vay1B aGVhZCBmb3IgdGhlIGFib3ZlIEluc3RydWN0aW9ucw0JUG9ydCAzID0gQm9vdCBMb2FkDQlQb3J0 IDQgPSBSZXNlcnZlZA0JVGhlcmUgYXJlIHRocmVlICgzKSBTSU1NL0RJTU0gcGFja2FnZXMsIGVh Y2ggcHJvdmlkaW5nIDY0SyBYIDM2Ow0JeWllbGRpbmcgYW4gMTA4IEJpdCBNaWNybyBJbnN0cnVj dGlvbi4gIA0NVGhlIHByb2Nlc3NvcihzKSBMb2NhbCBNZW1vcnkgKEhhcnZhcmQgQXJjaGl0ZWN0 dXJlKSBpcyBGb3VyLVBvcnQgd2hlcmU6DQlQb3J0IDEgPSBSZWFkIE9ubHkgKE9wZXJhbmQgTG9v ay1BaGVhZCkNCVBvcnQgMiA9IFJlYWQgT25seSAoT3BlcmFuZCBMb29rLWFoZWFkKQ0JUG9ydCAz ID0gV3JpdGUgT25seSwgU2hhcmVkIHdpdGggQm9vdCBMb2FkDQlQb3J0IDQgPSBGQkMgKEZ1bGx5 IEJ1ZmZlcmVkIENoYW5uZWwpDQkJIEZyb20vVG8gR2xvYmFsIE1lbW9yeSAmDQkJIEZyb20vVG8g QXNzb2NpYXRlZCBQZXJpcGhlcmFscw0JTGFuZ3VhZ2UgcHJvY2Vzc29yIFBlcmlwaGVyYWxzIGFy ZSBDSUNVIChDb25zb2xlIElucHV0IENvbnRyb2wgVW5pdCksIENSVA0JUmVmcmVzaCBNZW1vcnks IE11bHRpcGx5L0RpdmlkZS9TcXVhcmUgUm9vdCAmIEZsb2F0aW5nIFBvaW50LiBXaGVyZSB0aGUN CVBlcmlwaGVyYWwgcHJvY2Vzc29yIHNlcnZpY2VzIHVwIHRvIDEyOCBQcmludGVycywgUmVhbCBU aW1lIENsb2NrLCBGYXgsIE1vZGVtLA0JdXAgdG8gMTI4IFBhZ2UgU2Nhbm5lcnMsIElvbWVnYSBE aXNrLCBhbmQgdXAgdG8gk06UIEhhcmQgRGlza3MuDQ0NCVRoZXJlIGFyZSBmb3VyICg0KSBTSU1N L0RJTU0gcGFja2FnZXM7IGVhY2ggcHJvdmlkaW5nIDY0SyBYIDM2IA0JYW5kIGlzIGFsbG9jYXRl ZCBmb3IgZWFjaCBvZiB0aGUgMTI4IFVTRVJTIGFzIGZvbGxvd3M6DTRLIEJ5dGVzIJYgRGlzcGxh eSBNZW1vcnkNMTJLIEJ5dGVzIJYgQXBwbGljYXRpb24gUHJvZ3JhbSBhbmQgTG9jYWwgTTJNIFJl Z2lzdGVycw0NVGhlIHByb2Nlc3NvcihzKSBHbG9iYWwgTWVtb3J5IGlzIFR3by1Qb3J0IHdoZXJl Og0JUG9ydCAxID0gRkJDICAgRnJvbS9UbyBMYW5ndWFnZSBQcm9jZXNzb3IgTG9jYWwgTWVtb3J5 DQlQb3J0IDIgPSBGQkMgICBGcm9tL1RvIFBlcmlwaGVyYWwgUHJvY2Vzc29yIExvY2FsIE1lbW9y eQ1TeXN0ZW0gUHJvZ3JhbW1lcnMgd2lsbCBhbGxvY2F0ZSBhbiBhcmVhIG9mIHRoaXMgbWVtb3J5 IGZvcg1JbnRlci1wcm9jZXNzb3IgbWFpbC1ib3guICBBbiBpbnRlci1wcm9jZXNzb3IgSW50ZXJy dXB0IGlzIHByb3ZpZGVkDQwNCUEgU3lzdGVtIENSVCBNb25pdG9yIHdpdGggS2V5Ym9hcmQgaXMg cHJvdmlkZWQgcHJpbWFyaWx5IGZvciBEZWJ1Z2dpbmcgU3lzdGVtDVNvZnR3YXJlIG9mIGVpdGhl ciBwcm9jZXNzb3IuICBBIENvbnRyb2wgUGFuZWwgaXMgYWxzbyBwcm92aWRlZCBmb3IgU2luZ2xl IJYgU3RlcHBpbmcgdGhydSBhDVByb2dyYW0uICBUaGUgcHJvY2Vzc29ycyBhcmUgc3dpdGNoIHNl bGVjdGFibGUuIFRoZSBQcm9ncmFtbWVyIGNhbiBtb2RpZnkgZWl0aGVyIFByb2dyYW0gTWVtb3J5 IG9yIExvY2FsIE1lbW9yeSBhcyBuZWNlc3NhcnkuIFRoZSBFbmQtSXRlbSBIYXJkd2FyZSB3aWxs IE5PVCBoYXZlIHRoaXMgY2FwYWJpbGl0eS4NQXMgYSByZXN1bHQgliBpdCBpcyBJTVBPU1NJQkxF IGZvciBWSVJVUyB0byBlbnRlciB0aGUgc3lzdGVtLg0NNS4gIFNZU1RFTSBTT0ZUV0FSRQ0NCUFz IHByZXZpb3VzbHkgc3RhdGVkOyB0aGUgT3BlcmF0aW5nIFN5c3RlbSBjb25zaXN0cyBvZiA5LDk2 NyBJbnN0cnVjdGlvbnMgaW5jbHVkaW5nIEhhcmQNRGlzayBvcGVyYXRpb25zIGZvciBzdG9yYWdl L3JldHJpZXZhbCBvZiBkYXRhIGFuZCBBcHBsaWNhdGlvbiBQcm9ncmFtcy4gIFRoaXMgZnVuY3Rp b24gaXMgcmVtb3ZlZA1mcm9tIHRoZSBMYW5ndWFnZSBQcm9jZXNzb3IgYW5kIGFsbG9jYXRlZCB0 byB0aGUgUGVyaXBoZXJhbCBzaWRlIHdoaWNoIGluY2x1ZGVzIERpcmVjdG9yeSAmIEZpbGUgTWFp bnRlbmFuY2UgZm9yIHRoZSBMb2NhbCBzeXN0ZW0gYW5kIHVwIHRvIJNOlCBzdWJzeXN0ZW1zLiAg VGhpcyByZWR1Y2VzIHRoZSBpbnN0cnVjdGlvbiBjb3VudCB0byBhcHByb3hpbWF0ZWx5IDksMDAw LiAgVGhpcyBpcyBGVUxMWSBPcHRpbWl6ZWQgSGFuZCBDb2RpbmcgdXNpbmcgYSBQcm9ncmFtIEFz c2VtYmxlciCWIG5vdCBhIENvbXBpbGVyLiAgVGhlIHN5c3RlbSBwcm9ncmFtbWVyIGlzIFRPVEFM TFkgb2JsaXZpb3VzIHRoYXQgdGhlIG1hY2hpbmUgZG9lcyBvciBkb2VzIG5vdCBlbXBsb3kgUGlw ZWxpbmUgZGVzaWduLiAgT25jZSB0aGUgU3lzdGVtIFByb2dyYW1tZXIgaXMgZnVsbHkgc2F0aXNm aWVkIHdpdGggaGlzIGRlc2lnbiCWIHRoaXMgcGVyc29uLCBpbiBhc3NvY2lhdGlvbiB3aXRoIGEg TWljcm8tUHJvZ3JhbW1lciB3aWxsIGZ1cnRoZXIgb3B0aW1pemUgdGhlIGNvZGUgdXNpbmcgdGhl IGZ1bGwgY2FwYWJpbGl0aWVzIG9mIHRoZSBFUklOMzIgUHJvY2Vzc29yLg0JVG8gZnVsbHkgZGVm aW5lIHRoZSBoYXJkd2FyZSByZXF1aXJlbWVudHMgb2YgdGhlIEVSSU4zMjsgdGhlIGZvbGxvd2lu ZyBJbnN0cnVjdGlvbiBtaXggaXMgdXNlZDoNCQlCUkFOQ0gJCTE2JQ0JCVNUT1JFCQkgIDklDQkJ QVJJVEgvTE9HSUMJNDUlDQkJTE9BRAkJCTI2JQ0JCVNISUZUCQkJICA0JQ0NCUFuIGFuYWx5c2lz IG9mIHRoZSA5LDk2NyBJbnN0cnVjdGlvbnMsIHdoaWNoIGlzIGEgZ29vZCBiYXNpcyBmb3IgdGhl c2UgcGVyY2VudGFnZXMsIHNob3dzIHRoYXQgdGhleSBhcmUgYXBwcm94aW1hdGVseSBjb3JyZWN0 LiAgQSBmdXJ0aGVyIGFuYWx5c2lzIHdhcyBhY2NvbXBsaXNoZWQsIHJlc3VsdGluZyBpbjoNCQkJ CQkJCVJlZHVjZXMgdG86DQkJSk1QCQkxMzE4CQkJZnVsbHkgdHJhbnNwYXJlbnQNCQlKU1QJCSAg NzY0CQkJZnVsbHkgdHJhbnNwYXJlbnQNCQlMREEvU1RBCSAgMzkwIHBhaXJzCQkzOTANCQlCUkFO Q0gJICA1MDAgcGFpcnMJCTUwMA0JCUxEQS9BREQJICAxMTYgcGFpcnMJCTExNg0JCUxEQS9TVUIJ ICAgIDg2IHBhaXJzCQkgIDg2DQkJTERBL0FOQQkgIDE0OCBwYWlycwkJMTQ4DQkJTERBL0VSQQkg ICAgMzYgcGFpcnMJCSAgMzYNCQlMREEvQU9BCSAgICAxNiBwYWlycwkJICAxNg0JCUxEQS9DTUEJ ICAgICAgOCBwYWlycwkJICAgIDgNCQlMREEvVENBCSAgICAxMCBwYWlycwkJICAxMA0JCUxEQS9D QVMJICAgIDc0IHBhaXJzCQkgIDc0DQwNCQlMREEvSU1BCSAgICAyMiBwYWlycwkJICAyMg0JCUxE QS9MR1IJICAgIDEzIHBhaXJzCQkgIDEzDQkJTERBL0FSUgkgICAgICAzIHBhaXJzCQkgICAgMw0J CUxEQS9MR0wJICAgIDE1IHBhaXJzCQkgIDE1DQkJTERBL0FMUwkgICAgICAzIHBhaXJzCQkgICAg Mw0JCUxEQS9BUlMJICAgICAgMSBwYWlyCQkgICAgMQ0JCUxEQS9BTFIJICAgICAgMiBwYWlycwkJ ICAgIDINDQkJCQlUb3RhbCBSZWR1Y3Rpb24JMTQ0MQ0JCQkJVG90YWwgSW5zdCBhZnRlcgkJNzU1 OQ0NT3RoZXIgcmVkdWN0aW9ucyBjYW4gYW5kIHdpbGwgYmUgbWFkZSB3aGVyZSA3NTAwIGlzIGEg Z29vZCBudW1iZXIgZm9yIGNvbnZlcnNhdGlvbi4gIFdoeSBjb25jZW50cmF0ZSBpbiB0aGlzIGFy ZWE/PyAgRm9yIGZ1dHVyZSBSZXNlYXJjaCB3aXRoIHBvc3NpYmxlIEFTSUMgYXBwbGljYXRpb24u DQ02LiAgVEhFIFBST0NFU1NPUg0NCUEuICBJTlRST0RVQ1RJT04NCQlUaGUgRVJJTjMyIGlzIGEg MzItYml0IGJpbmFyeSBkYXRhIHdvcmQgZ2VuZXJhbCBwdXJwb3NlIGNvbXB1dGVyIHdpdGggYQ0J NSBOYW5vLXNlY29uZCBTeW5jaHJvbm91cyBTdGF0aWMgUmFtIChTU1JBTSkgbWVtb3J5LiAgVGhl IG1hY2hpbmUgb3JnYW5pemF0aW9uDQlwZXJtaXRzIERpcmVjdCwgSW5kZXggUmVsYXRpdmUsIGFu ZCBJbmRpcmVjdCBhZGRyZXNzaW5nIG1vZGVzLiBUaGlzIGFsbG93cyBhZGRyZXNzaW5nDW9mIDEs MDQ4LDU3NiAoMjAgYml0cykgZGF0YSBvciBpbnN0cnVjdGlvbiB3b3Jkcy4gU3RhbmRhcmQgZmVh dHVyZXMgaW5jbHVkZSBhIGZsZXhpYmxlIGluc3RydWN0aW9uIHJlcGVydG9pcmUgb2YgNjcgY29t bWFuZHMsIHRocmVlIGhhcmR3YXJlIGluZGV4IHJlZ2lzdGVycyAoSGFydmFyZCBBcmNoaXRlY3R1 cmUpLCA4IHZlY3RvcmVkIGludGVycnVwdHMgYW5kIGEgcG93ZXJmdWwgSS9PIGJ1cyBzdHJ1Y3R1 cmUgd2hpY2ggdXNlcyBhbiBGQkMgKEZ1bGx5IEJ1ZmZlcmVkIENoYW5uZWwpIGZvciBkYXRhIHRy YW5zZmVyLiAgQSBTeW1ib2xpYyBBc3NlbWJsZXIgaXMgdXNlZCB0byBnZW5lcmF0ZSBtYWNoaW5l IGNvZGUgaGF2aW5nIGFuIDEwOCBiaXQgaW5zdHJ1Y3Rpb24gd29yZC4gIE9wdGlvbnMgaW5jbHVk ZSBoaWdoLXNwZWVkIGFyaXRobWV0aWMgTXVsdGlwbHksIERpdmlkZSwgU3F1YXJlIFJvb3QgYW5k IEZsb2F0aW5nIFBvaW50LCBhbmQgYSBmdWxsIGxpbmUgb2YgcGVyaXBoZXJhbCBlcXVpcG1lbnQu DQlUaGUgRVJJTjMyIGlzIGRlc2lnbmVkIGZvciBib3RoIG9wZW4tc2hvcCBzY2llbnRpZmljIGFw cGxpY2F0aW9ucyBhbmQgcmVhbC10aW1lDW9uLWxpbmUgZGF0YSBwcm9jZXNzaW5nIGFuZCBjb250 cm9sLiAgQSBicm9hZCB2YXJpZXR5IG9mIGFwcGxpY2F0aW9ucyBjYW4gYmUgdGFpbG9yZWQgdG8N aW5jbHVkZSBkYXRhIHJlZHVjdGlvbiwgcHJvY2VzcyBjb250cm9sLCBpbnN0cnVtZW50YXRpb24s IHNpbXVsYXRpb24sIG9wZW4tc2hvcCBzY2llbnRpZmljDWFuZCBlbmdpbmVlcmluZyBjb21wdXRh dGlvbiBvciBhbnkgY29tYmluYXRpb24gb2YgdGhlc2UuDQlQcm9ncmFtbWluZyB0aGUgRVJJTjMy IGlzIHNpbWlsYXIgdG8gcHJvZ3JhbW1pbmcgb3RoZXIgZHVhbCBzb3VyY2UsIHNpbmdsZQ1kZXN0 aW5hdGlvbiBhZGRyZXNzIGNvbXB1dGVycyB1c2luZyB0d2+ScyBjb21wbGVtZW50IG5vdGF0aW9u LiAgVGhlcmVmb3JlLCBubyBtYWpvciBkaWZmZXJlbmNlcyBjb25mcm9udCB0aGUgcHJvZ3JhbW1l ciB3aG8gaXMgbmV3IHRvIHRoZSBFUklOMzIuDQkNCUIuICBERVNDUklQVElPTg0JCVRoZSBFbmQt SXRlbSBQcm9jZXNzb3IgaXMgYSBRdWlja2xvZ2ljIENvcnBvcmF0aW9uIFFMNjUwMCBGUEdBLCA1 MTYgUGluIGRldmljZQ1vZiB0aGUgRWNsaXBzZSBGYW1pbHkuICBUaGUgZGV2ZWxvcG1lbnQgc29m dHdhcmUgZm9yIHRoaXMgZmFtaWx5IGlzIGN1cnJlbnRseSBpbiBCZXRhIFRlc3RpbmcuDUl0cyBj YXBhYmlsaXR5IGlzOg0JCQlNYXggR2F0ZXMJID0gNDg4LDA2NA0JCQlMb2dpYyBDZWxscwkgPSAz MDcyDQkJCU1heCBGRpJzIAkgPSA3NDg4DQkJCU1heCBJL08gIAkgPSA0NDggcGlucw0JCQlSYW0g TW9kdWxlcwkgPSAzMiB1bnVzZWQNCQkJUGFja2FnZQkgPSBCR0ENCQkJUExMCQkgPSA0LCB3aXRo IDF4LDJ4LDR4DQkJCURMTA0JCQlHbG9iYWwgQ2xvY2sgTmV0cyA9IDkNCVRoZSBwcmltYXJ5IHJl YXNvbiBmb3Igc2VsZWN0aW5nIHRoaXMgZGV2aWNlIGlzIEkvTyBwaW5zIHdoZXJlIEkgcmVxdWly ZSAzOTU7IG5vdCBiZWNhdXNlIEkgYW0gbG9naWMgbGltaXRlZC4gIEluIG9yZGVyIHRvIG9idGFp biBhIHJlYXNvbmFibHkgY2xvc2UgdmlldyBvZiB0aGUgZGVzaWduLCBJIHJlbW92ZWQgdGhlIEZC QyBsb2dpYyBhbmQgdGhlIGFzc29jaWF0ZWQgcGlucyBhbmQgd2VudCB0aHJ1IFBMQUNFICYgUk9V VEUgdXNpbmcgYSBRTDMwNjAtNCB3aXRoIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoNCQlVc2FibGUg UExEIEdhdGVzCTYwLDAwMA0JCUxvZ2ljIENlbGxzCQkxMzYwIG9mIDE1ODQNCQlDbG9jayBPbmx5 IENlbGxzCTMgb2YgOA0JCUZGknMJCQk4NzYNCQlCaS1EaXJlY3Rpb25hbCBDZWxscwkzMDggb2Yg MzA4DQkJUm91dGluZyBSZXNvdXJjZXMJMzkzMjggb2YgMTAyOTE2ICh3aXJlcykNCQkJCQlUaGlz IGlzIHdoZXJlIGRlbGF5cyBhcmUgaW52b2x2ZWQgaW4gYWRkaXRpb24gdG8gZ2F0ZQ0JCQkJCWRl bGF5cyBhcyBhIGZ1bmN0aW9uIG9mIExPQURJTkcuICBBbGwgbG9hZGluZyBpcyBoZWxkDQkJCQkJ YnkgZGVzaWduIHRvIGEgbWF4aW11bSBvZiA4LiBIZXJlIHRoZSB0ZXJtIGZhbi1vdXQgaGFzDQkJ CQkJdGhlIHNhbWUgbWVhbmluZy4NCQlWaWFMaW5rIFJlc291cmNlcwkzNDMyNyBvZiAyNzYyMjkw IChmdXNlIGxpbmtzKQ0JCQ1EZWxheXMgdGhhdCBhZmZlY3QgdGhlIGRlc2lnbiBleHRlcm5hbCB0 byB0aGUgZGV2aWNlIGFyZSBiYXNlZCBvbiB0aGVzZSBhc3N1bXB0aW9ucy4gIFNTUkFNIGFjY2Vz cyA9IDVOUywgYWRkcmVzcyBzZXQtdXAgPSA1bnMgZnJvbSBJL08gcGluIHRvIFJBTSBwaW4uLCAg U1NSQU0gZGF0YSB0byBpbnB1dCBwaW4NPSA1TlMuICBUaGVzZSBhcmUgY2lyY3VpdCBib2FyZCBk ZWxheXMuDQ0JVGhlIFByb2Nlc3NpbmcgRWxlbWVudHMgKFBFknMpIGFuZCBFeGVjdXRpb24gVW5p dHMgKEVVknMpIGluY2x1ZGUgdGhlIGZpcnN0IGxldmVsIG9mIFBpcGVsaW5lIHdoZXJlIG5lY2Vz c2FyeSBpbmNsdWRpbmcgMzIgYml0IEFyZ3VtZW50IFJlZ2lzdGVycy4gIEVhY2ggY29udGFpbiB0 aGVpciBTdGF0ZSBMb2dpYyBUaW1pbmcsIFNjb3JlYm9hcmQsIFdhaXQgTG9naWMgZm9yIG9wZXJh dGlvbnMgcmVxdWlyaW5nIHJlc3VsdHMgb2YgcHJldmlvdXMgaW5zdHJ1Y3Rpb24gJiBhIE11bHRp cGxleGVyIFN0ZWVyaW5nIG91dHB1dC4gSW4gdGhlc2UgZGVzaWducyB5b3Ugd2lsbCBzZWUgZGlm ZmVyZW50IG1ldGhvZHMgb2YgbG9hZGluZyBkaXN0cmlidXRpb24gdGVjaG5pcXVlcyBhcyBkZXNj cmliZWQgaW4gdGhlIFF1aWNrbG9naWMgTWFudWFsLiAgRWFjaCBQRSBoYXMgYmVlbiBGVUxMWSBo YW5kIGxvZ2ljIG9wdGltaXplZCCWIGl0IGlzIGZ1cnRoZXIgb3B0aW1pemVkIGluIHRoZSBDSElQ IGdlbmVyYXRpb24gcHJvY2VzcyB3aGljaCBtb2RpZmllcyB5b3VyIHJlcXVlc3RlZCBmdW5jdGlv biB0byB0aGF0IG9mIHRoZSBMb2dpYyBDZWxsIHN0cnVjdHVyZS4gIEEgcHJpbnQtb3V0IGlzIGF2 YWlsYWJsZSBvZiB0aGUgYWZmZWN0ZWQgYXJlYXMuICBBbGwgZGVzaWduIHVzZXMgU0NIRU1BVElD IGlucHV0IE9OTFkuDQ0JQUwzMgkJVGhpcyBFVSBwZXJmb3JtcyBhbGwgb2YgdGhlIHJlcXVpcmVk IEFyaXRobWV0aWMvTG9naWMgZnVuY3Rpb25zLiAgVGhlcmUgaXMgDQkJCW5vIG1hZ2ljIGhlcmUg liBwdXJlIHRleHQgYm9vayAtIFRUTCAgLSBTTjc0MTgxIEFMVSB3aXRoIHRoZSBTTjc0MTgyDXVz ZWQgZm9yIENhcnJ5IExvb2stQWhlYWQuICBUd28gb2YgdGhlc2UgRVWScyBhcmUgcmVxdWlyZWQg Zm9yIHRoZSBTaW5nbGUgTGV2ZWwgUGlwZWxpbmUuIEl0IHNhdGlzZmllcyBhbGwgb2YgdGhlIGZ1 bmN0aW9uYWxpdHkgb2YgdGhlIEREUC01MTYgYW5kIHdpbGwgcHJvdmlkZSBhZGRpdGlvbmFsIElu c3RydWN0aW9uIGNhcGFiaWxpdHkgdG8gdGhlIEVSSU4zMi4NDUFNVVgJVGhpcyBQRSBpcyBhIHNp bXBsZSBtdWx0aXBsZXhlciAgdGhhdCByZWNlaXZlcyBpbnB1dHMgZnJvbSB0aGUgQUwzMiwgdGhl DQkJQmFycmVsIFNoaWZ0ZXIgKG9uZSBpbnB1dCBBUyBJUyBhdCB0aGUgb3V0cHV0LCBhbmQgaXMg YWxzbyBiaXQgcmV2ZXJzZWQgZm9yDQkJUmlnaHQgU2hpZnRzKS4gIFR3byBpbnB1dHMgYXJlIGZy b20gdGhlIExvYWQgUEUgYW5kIG9uZSBmcm9tIHRoZSBDU1RCDQkJRVUuDQ1BUkVHCQlUaGlzIFBF IGlzIGEgc2ltcGxlIDMyIEJpdCBSZWdpc3Rlci9BY2N1bXVsYXRvci4gIERhdGEgaW5wdXRzIGFy ZSBmcm9tIHRoZQ1BTVVYOyAgU2lnbiBjb250cm9sIGFuZCBDbGVhciBmdW5jdGlvbnMgYXJlIHJl Y2VpdmVkIGZyb20gdGhlIFVEUlMgKG90aGVycykgUEUsIHN1Y2ggYXMgUFMgKFByZXNldCBTaWdu KSwgUlMgKFJlc2V0IFNpZ24pLCBDbGVhciBzZWxlY3RlZCBCeXRlLCBhbmQgQ1JBIChDbGVhciBB LXJlZykuICBUaGUgQVogKEFyZWc9WmVybykgb3V0cHV0IGlzIGVzc2VudGlhbGx5IG9uZSBiaXQg b2YgdGhlIENDUiAoQ29uZGl0aW9uIENvZGUgUmVnaXN0ZXIpIHVzZWQgZm9yIENvbmRpdGlvbmFs IEJyYW5jaC4gIEV2ZXJ5DWluc3RydWN0aW9uIGhhdmluZyBBcmVnIGRlc3RpbmF0aW9uICh3aGlj aCBpcyBtb3N0IG9mIHRoZSB0aW1lKSB3aWxsIGNhdXNlIEFaDVRvIGNoYW5nZS4NDUJSQU4JVGhp cyBFVSBjb250YWlucyBhIDE2IEJpdCBJbnN0cnVjdGlvbiBSZWdpc3RlciBvZiB0aGUgdHlwZSBv ZiBCcmFuY2ggdGhlIFByb2dyYW1tZXIgd2FudHMgdG8gZXhlY3V0ZS4gIEhlIG1heSBzZWxlY3Qg b25lIG9yIG1vcmUgQ29uZGl0aW9ucy4gVGhlcmUgaXMgYSAxNiBCaXQgT1IgZ2F0ZSB3aG9zZSBv dXRwdXQgaXMgQlJBTi4gVGhpcyBvdXRwdXQgaXMgYXBwbGllZCB0byB0aGUgVkVDVE9SIEVVLg0N Q0FTCVRoaXMgRVUgcGVyZm9ybXMgYW4gQXJpdGhtZXRpYyBDb21wYXJlIG9mIHR3byBvcGVyYW5k cyBhbmQgUmVnaXN0ZXJzDQl0aGUgcmVzdWx0ICBpbiAzIGJpdHMgb2YgdGhlIENDUi4gIFRoZXNl IGFyZSBBTEIsIEFHQiwgYW5kIEVRVS4gIFRoZQ0JZGVzaWduIHVzZXMgdGhlIFRUTCBTTjc0MTg1 IGFzIGJ1aWxkaW5nIGJsb2NrLiAgUHVyZSB0ZXh0Ym9vayBkZXNpZ24uDQ1DU1RCCVRoaXMgaXMg YSBjbGFzc2ljYWwgRGF0YSBTZWxlY3Rvci9NdWx0aXBsZXhlciBkZXNpZ24gdGhhdCBwZXJmb3Jt cyB0aGUgQ2xlYXIgQml0LCBTZXQgQml0IGFuZCBUZXN0IEJpdCBJbnN0cnVjdGlvbnMgYW5kIGlz IGJhc2VkIG9uIFRUTCBTTjc0MTUwLiBUaGUgVFNUIG91dHB1dCBpcyBvbmUgYml0IG9mIHRoZSBD Q1IgYW5kIGlzIGFwcGxpZWQgdG8gdGhlIEJSQU4gRVUuICBUaGUgRGF0YSBPdXRwdXRzIGFyZSBh cHBsaWVkIHRvIHRoZSBBTVVYLg0NSU5ERVgJVGhlIGRlc2lnbiB1c2VzIHRocmVlICgzKSBvZiB0 aGVzZSBFVZJzLiAgVGhleSBlZmZlY3RpdmVseSBpbXBsZW1lbnQgdGhlDQlIYXJ2YXJkIEFyY2hp dGVjdHVyZSBjaG9zZW4uICBIZXJlOyB0aGUgUHJvZ3JhbW1lciBoYXMgbWFueSBPcHRpb25zLg0J VGhlIEEtU291cmNlIGFuZCBCLVNvdXJjZSBJbmRleCBSZWdpc3RlciAod2l0aCBJbmNyZW1lbnQg Y2FwYWJpbGl0eSkNCWFyZSBhcHBsaWVkIHRvIFNSQU0gUmVhZCBPbmx5IFBvcnRzIGFzIHByZXZp b3VzbHkgZGVzY3JpYmVkLiBUaGlzDQlzb3VyY2UgbWF5IGJlIGFueSBjb21iaW5hdGlvbiBvZiBD b21tb24gRGF0YSBQb29sIGFuZCBVU0VSIHNsb3QuDQlUaGUgRGVzdGluYXRpb24gKFdyaXRlKSBJ bmRleCBSZWdpc3RlciBoYXMgdGhlIHNhbWUgdmFyaWFibGUgYXZhaWxhYmxlLg0JVGhleSBtYXkg YmUgcmFuZG9tbHkgSW5jcmVtZW50ZWQgb3IgTG9hZGVkIG9uZSwgdHdvLCBvciBhbGwgdGhyZWUg c2VsZWN0aXZlbHkuICBUaGUgk1iUIG91dHB1dCBpcyBhcHBsaWVkIHRvIHRoZSBTdG9yZSBFVS4N DUlSUwlJbmNyZW1lbnQsIFJlcGxhY2UgKFN0b3JlKSAmIFNraXAgaWYgWmVybyA9IEREUC01MTYu ICBJbmNyZW1lbnQsIFJlcGxhY2UgJiBSZWdpc3RlciByZXN1bHQgPSBFUklOMzIuICBUaGlzIGlz IG9uZSBiaXQgb2YgdGhlIENDUiBhbmQgdXNlcyB0aGUgdGVybSBOWi4gIFRoaXMgZGVzaWduIHVz ZXMgYSAzMiBCaXQgSW5jcmVtZW50ZXIgd2hlcmUgdGhlIElOREVYIEVVIHVzZXMgYSAyMCBiaXQg SW5jcmVtZW50ZXIuICBUaGUgTlogb3V0cHV0IGlzIGFwcGxpZWQgdG8gdGhlIEJSQU4gRVUuICBU aGUgSW5jcmVtZW50ZWQgdmFsdWUgaXMgYXBwbGllZCB0byB0aGUgU1RPUkUgRVUuLiAgVHdvIG9m IHRoZXNlIEVVknMgYXJlIHJlcXVpcmVkIGZvciB0aGUgU2luZ2xlIExldmVsIFBpcGVsaW5lIHRo YXQgaXMgaW1wbGVtZW50ZWQuDQ1MT0FECVRoaXMgRVUgIHJlY2VpdmVzIERhdGEgZnJvbSBhIFJl YWQgT25seSBQb3J0IGFuZCBzZXJ2aWNlcyB0aGUgTERBDQkoTG9hZCBBY2N1bXVsYXRvcikgYW5k IExEQiAoTG9hZCBTZWxlY3RlZCBCeXRlIGluIFNlbGVjdGVkIEJ5dGUNCVBvc2l0aW9uKSwgd2l0 aCBvciB3aXRob3V0IGJpdCA4IElOQiAoSW5oaWJpdCkgSW5zdHJ1Y3Rpb25zLiBCaXQgOCBpcyBk ZWZpbmVkIGFzIHRoZSBDVVJTT1IgQklULCAgd2hlcmUgU29mdHdhcmUgaXMgcHJpbWFyaWx5IGlu dGVyZXN0ZWQgaW4gdGhlIHJlbWFpbmluZyBBU0NJSSBDaGFyYWN0ZXIsIElOQiBpcyBzcGVjaWZp ZWQuICBUaGUgb25seSBleGNlcHRpb24gdG8gdGhpcyBpcyB0aGUgbm9ybWFsIENSVCBFZGl0IHBy b2Nlc3MuICBXaGVyZSB0eXBpbmcgc2F5cyCWIGVudGVyIHRoZSByZXF1aXJlZCBjaGFyYWN0ZXIg YW5kIFN0ZXAgdGhlIEN1cnNvci4gIFRoaXMgY2FuIGJlIGRvbmUgd2l0aCB0aGUgU0VUQiAoU2V0 IEJpdCkgSW5zdHJ1Y3Rpb24uDQ1TVE9SRQlUaGlzIEVVIHJlY2VpdmVzIHNlbGVjdGVkIGlucHV0 cyBiYXNlZCBvbiBleGVjdXRpb24gb2YgIFNUQSAoU3RvcmUNCUFjY3VtdWxhdG9yKSwgU1RCIChT dG9yZSBTZWxlY3RlZCBCeXRlIGluIHRoZSBTZWxlY3RlZCBCeXRlIFBvc2l0aW9uLCB3aXRoIG9y IHdpdGhvdXQgSU5IKSwgU1RYIChTdG9yZSBTZWxlY3RlZCBJbmRleCksIElSUywgQUxVLCBvciBT aGlmdC4NCVRoZSBkZXNpZ24gY3VycmVudGx5IHVzZXMgYSBTaW5nbGUgTGV2ZWwgRGF0YSBQaXBl bGluZTsgaG93ZXZlcjsgdGhpcyB3aWxsIGhhdmUgdG8gaW5jcmVhc2UgdG8gcHJvcGVybHkgbWF0 Y2ggU1RPUkUgcmVxdWVzdHMgKFF1ZXVlKSB0byB0aGUgc3BlZWQgb2YgdGhlIFNTUkFNLiAgVGhl IFN0b3JlIEFkZHJlc3MgcXVldWUgd2lsbCBoYXZlIHRvIGluY3JlYXNlIGEgbGlrZSBhbW91bnQu ICBBIExvZ2ljIEVSUk9SIGlmIHlvdSBsaWtlIHRoZSB0ZXJtIJYgSSBkby4NDVVEUlMJKE90aGVy cykgIFRoaXMgRVUgY29uc2lzdHMgZW50aXJlbHkgb2YgSW5zdHJ1Y3Rpb25zIGluIHRoZSBDb250 cm9sIGNhdGVnb3J5Lg0JU3VjaCAgYXMgIENSQSwgIFNTTSAgKFNldCBTaWduIE1pbnVzKSwgIFNT UCAoU2V0IFNpZ24gUGx1cyksICBDU0EgKENvbXBsZW1lbnQgU2lnbiBvZiBBcmVnKS4gIEl0IGNv bnRhaW5zIHRoZSBDRkYgd2hpY2ggaXMgb25lIEJpdCBvZiB0aGUgQ0NSLiAgSXQgbWF5IGJlIGNv bnRyb2xsZWQgd2l0aCBTQ0IgKFNldCBDLWJpdCksIGFuZCBSQ0IgKFJlc2V0IEMtYml0KQ0JSW5z dHJ1Y3Rpb25zLiAgT3RoZXIgY29udHJvbCBvZiB0aGUgQ0ZGIGlzIHRoZSByZXN1bHQgb2YgIEFy aXRobWV0aWMgYW5kIFNoaWZ0IEluc3RydWN0aW9ucy4gKE92ZXJmbG93L1VuZGVyZmxvdykNDVZF Q1RPUglUaGlzIEVVIHJlY2VpdmVzIEpNUCBVbmNvbmRpdGlvbmFsIEp1bXApLCBKU1QgKEp1bXAg YW5kIFN0b3JlIFJldHVybiksIEJSQSAoQ29uZGl0aW9uYWwgQnJhbmNoKSBhbmQgUlROIChKdW1w IEluZGlyZWN0KSBmcm9tIFBvcnQgMiBvZiBJbnN0cnVjdGlvbiBNZW1vcnkuICBUaGUgRU5CIChF bmFibGUgSW50ZXJydXB0cyksIElOSCAoSW5oaWJpdCBJbnRlcnJ1cHRzKSBJbnN0cnVjdGlvbnMg YXJlIHJlY2VpdmVkIGZyb20gUG9ydCAxLiAgSGVyZSBJIHVzZSB0aGUgdGVybSBWZWN0b3IsIHdo ZXJlIHRoZSBuZXh0IEluc3RydWN0aW9uIGlzIFBDKzEgb3IgZ28gd2hlcmUgVmVjdG9yZWQuICBB dCBIb25leXdlbGwgd2UgY2FsbGVkIHRoaXMgk1NwbGF0dGVylC4gIFRoZXJlIGlzIHByb3Zpc2lv biBmb3IgZWlnaHQgKDgpIFZlY3RvcmVkIEludGVycnVwdHMsIHdoZXJlIGxldmVsDTggaXMgdGhl IGhpZ2hlc3QgbGV2ZWwuICBUaGUgaGlnaGVzdCBMZXZlbCBpcyBhc3NpZ25lZCB0byBJbnRlci1Q cm9jZXNzb3IgSW50ZXJydXB0LCB0aGVuIDcgaXMgRkJDIFRlcm1pbmF0aW9uIEludGVycnVwdC4N CVRoZSByZW1haW5kZXIgYXJlIGFzc2lnbmVkIHRvIFBlcmlwaGVyYWwgRGV2aWNlcyBkZXBlbmRp bmcgb24gdGhlIFByb2Nlc3NvciBhcHBsaWNhdGlvbiwgaS5lLiwgTGFuZ3VhZ2Ugb3IgUGVyaXBo ZXJhbC4gIFRoZXNlIG1heSBjaGFuZ2UgYWZ0ZXIgZGlzY3Vzc2luZyB3aXRoIFNvZnR3YXJlIGd1 cnWScy4gIEEgVFRMIFNONzQxNDggaXMgdXNlZCBhcyB0aGUgUHJpb3JpdHkgRW5jb2Rlci4gIEZ1 cnRoZXIgdGltaW5nIGFuYWx5c2lzIG1heSByZXF1aXJlIEkgTG9vay1BaGVhZCB0d28gcmF0aGVy IHRoYW4gdGhlIGN1cnJlbnQgb25lLiBUaGlzIGlzIGR1ZSB0byB0aGUgY2xvY2sgdG8gb3V0IG9m IGEgSktGRiwgb25lIGZvdXIgaW5wdXQgZ2F0ZSBhbmQgdGhlIHRyYW5zaXRpb24gdGltZSBvZiBC aS1EaXJlY3Rpb25hbCBJL08gUGFkLiAgVGhpcyBpcyB0aGUgVE9UQUwgIEp1bXAvQnJhbmNoIGRl Y2lzaW9uIHRpbWUuICAgIEkgc2hvdWxkIG5vdGUgdGhhdCB0aGUgZGVzaWduIGRvZXMgaGF2ZSBh IEhMVCAoSGFsdCkgSW5zdHJ1Y3Rpb24gYXMgZG9lcyB0aGUgRERQLTUxNiCWIGhvd2V2ZXIgdGhl IDUxNg12aXJ0dWFsbHkgY2FtZSB0byBhIEhBTFQuICBDdXJyZW50bHk7IFN5c3RlbSBTb2Z0d2Fy ZSBpcyBpbiBhIGNvbnRpbnVvdXMgbG9vcCBpbiB0aGUgU2tlZHVsYXIgUm91dGluZSBsb29raW5n IGZvciBzb21ldGhpbmcgdG8gZG8uIFRoaXMgd2lsbCBjaGFuZ2UuIFRoZSByb3V0aW5lIHdpbGwg bWFrZSBhIHNpbmdsZSBwYXNzLCBhbmQgaWYgVW4tSW50ZXJydXB0ZWQgd2lsbCBleGVjdXRlIGEg SExULiAgSSBoYXZlIG1hZGUgcHJvdmlzaW9uIGZvciBhbiBJbnRlcnJ1cHQgZnJvbSBIQUxULiAg VGhpcyBhbHNvDQlhcHBsaWVzIHRvIHRoZSBQZXJpcGhlcmFsIFByb2Nlc3Nvci4gSW50ZXJydXB0 cyBtdXN0IGJlIEVOQUJMRUQuDQ1XQURFCVRoaXMgRVUgaXMgbmFtZWQgZm9yIG15IEdyYW5kc29u IFdhZGUuICBUaGlzIHdhcyBhIGZ1biBkZXNpZ24gYW5kDQl0aGUgbGl0dGxlIGZlbGxvdyBpcyBG VU4uICBJVCBpcyBtb3JlIGFwcHJvcHJpYXRlbHkgY2FsbGVkIFNISUZULiAgVGhlDQlkZXNpZ24g aXMgYmFzZWQgb24gdGhlIFRUTCBBTTI1UzEwIChBTUQpLCA3NEYzNTAgKEZhaXJjaGlsZCkgb3IN CVNONzRTMzUwIChUSSkuICBBbGwgdGhyZWUgc291cmNlcyBwcm92aWRlZCBleGNlbGxlbnQgQXBw bGljYXRpb24gRGF0YQ0JU2hlZXRzLiAgVGhlIG1ldGhvZCBJIGNob3NlIHdhcyB0byBoYXJkLXdp cmUgYSBTaGlmdCBMZWZ0LiAgUmlnaHQgU2hpZnRzDQlhcmUgQml0IFJldmVyc2VkIHByaW9yIHRv IGFwcGxpY2F0aW9uIHRvIHRoZSBiYXJyZWwgc2hpZnRlciBhcnJheS4gIFRoaXMgcmV2ZXJzYWwg aXMgYXBwbGllZCB0byB0aGUgQU1VWCB3aGVyZSBpdCBpcyByZXZlcnNlZCBmb3IgdGhlIGNvcnJl Y3QgdmFsdWUuICBUaGUgRU5ETA0JKEVuZCBMb2dpYykgcHJvdmlkZXMgdGhlIG5lY2Vzc2FyeSBp bnB1dCBkZXBlbmRpbmcgb24gdGhlIHR5cGUgb2Ygc2hpZnQuDQlUaGUgRlVOIHBhcnQgd2FzIEhP VyB0byBhY2NvbXBsaXNoIHRoZSBBTFMgKEFyaXRobWV0aWMgU2hpZnQgTGVmdCkNCXdoaWNoIGlz IHJlcXVpcmVkIHRvIHNldCB0aGUgQ0ZGIGZvciBhIGNoYW5nZSBpbiBTaWduIHJlc3VsdGluZyBm cm9tIHRoZSBTaGlmdC4gIFRoaXMgaXMgbmVjZXNzYXJ5IHRvIG1haW50YWluIEFyaXRobWV0aWMg Y29ycmVjdG5lc3MuICBJIGNob3NlIHRvDQlkbyBhbiB1bi1yZWdpc3RlcmVkIE5vcm1hbGl6ZSAo U2hpZnQgTGVmdCB0aWxsIHR3byBNU0KScyBub3QgRXF1YWwuKS4NCVRoaXMgaXMgYWNjb21wbGlz aGVkIGJ5IFhPUiBvZiB0aGUgU2lnbiBhZ2FpbnN0IGVhY2ggQml0OyAgYXBwbHkgdGhpcyB0byBh DQlTZXJpZXMgb2YgUHJpb3JpdHkgRW5jb2RlcnMgKFNONzQxNDgpOyBlbmNvZGUgdGhlIG91dHB1 dHMgb2YgdGhlIDE0OJJzIGFuZCBkbyBhIExvZ2ljYWwgQ29tcGFyZSAoU043NDE4NSkgb2YgdGhl IHJlcXVlc3RlZCBTaGlmdCBhbW91bnQgd2l0aCBFbmNvZGVkDQlWYWx1ZSCWIGlmIEVxdWFsIHRv IG9yIExlc3MgVGhhbiCWIGNsZWFyIENGRiwgaWYgR3JlYXRlciCWIHNldCBDRkYuICBNYXkNCW5v dCBiZSB0aGUgb25seSBzb2x1dGlvbiwgYnV0IGZvciBhbiBhcnJheSBzaGlmdGVyLCBJkm0gb3Bl biBmb3Igb3RoZXIgZGVzaWduDQlhcHByb2FjaGVzLiAgVHdvIG9mIHRoZXNlIEVVknMgYXJlIHJl cXVpcmVkIGZvciBhIFNpbmdsZSBMZXZlbCBQaXBlbGluZQ0NQy4gIElOU1RSVUNUSU9OIFNFVA0N TWVtb3J5IFJlZmVyZW5jZSBJbnN0cnVjdGlvbnM6CQlBZGRyZXNzaW5nDQ1KTVAJVW5jb25kaXRp b25hbCBKdW1wCQkJRCwgWCwgSQ0NSlNUCVVuY29uZGl0aW9uYWwgSnVtcAkJCUQsIFgNCSYgU3Rv cmUgUmV0dXJuDQ1MREEJTG9hZCBBY2N1bXVsYXRvcgkJCUQsIFgNCUEtU291cmNlIHRvIEFyZWcN DVNUQQlTdG9yZSBBY2N1bXVsYXRvcgkJCUQsIFgNCUFyZWcgdG8gRGVzdGluYXRpb24NDUNBUwlB cml0aG1ldGljIENvbXBhcmUJCQlELCBYDQlDb21wYXJlIEEtU291cmNlIHRvIEItU291cmNlLA0J QUxCLCBFUVUsIEFHQiBpbnRvIENDUg0NSVJTCUluY3JlbWVudAkJCQlELCBYDQlBLVNvdXJjZSAr IDEgdG8gRGVzdGluYXRpb24NDUxEWAlMb2FkIFNlbGVjdGVkIEluZGV4IFJlZ2lzdGVyCQlELCBY DQlBLVNvdXJjZSB0byBYbg0NU1RYCVN0b3JlIFNlbGVjdGVkIEluZGV4IFJlZ2lzdGVyCQlELCBY DQlYbiB0byBEZXN0aW5hdGlvbg0NTERCCUxvYWQgU2VsZWN0ZWQgQnl0ZSBvZiBBLVNvdXJjZQlE LCBYDWluIHRoZSBTZWxlY3RlZCBCeXRlIFBvc2l0aW9uDQ1TVEIJU3RvcmUgU2VsZWN0ZWQgQnl0 ZSBpbgl0aGUJCUQsIFgNCURlc3RpbmF0aW9uIFNlbGVjdGVkIEJ5dGUgUG9zaXRpb24NDUlNQQlJ bnRlcmNoYW5nZSBNZW1vcnkJCQlELCBYDUEtU291cmNlICYgQWNjdW11bGF0b3IsDUFyZWcgdG8g RGVzdGluYXRpb24NDUFERAlBZGQgQS1Tb3VyY2UgKyBCLXNvdXJjZQkJRCwgWA0JdG8gQXJlZywg T3ZlcmZsb3cgaW50byBDRkYNDVNVQglTdWJ0cmFjdCBCLVNvdXJjZSBmcm9tIEEtU291cmNlLAlE LCBYDQlUbyBBcmVnLCBVbmRlcmZsb3cgaW50byBDRkYNDUFOQQlMb2dpY2FsIEFORCBvZiBBLVNv dXJjZQkJRCwgWA0JJiBCLVNvdXJjZSB0byBBcmVnDQ1FUkEJTG9naWNhbCBFeGNsdXNpdmUgT3Ig b2YgQS1Tb3VyY2UJRCwgWA0JJiBCLVNvdXJjZSB0byBBcmVnDQ1PUglMb2dpY2FsIE9yIG9mIEEt U291cmNlCQlELCBYDQkmIEItU291cmNlIHRvIEFyZWcNDU5PUglMb2dpY2FsIE5vciBvZiBBLVNv dXJjZQkJRCwgWA0JJiBCLVNvdXJjZSB0byBBcmVnDQ1YTlIJTG9naWNhbCBFeGNsdXNpdmUgTm9y IG9mIEEtU291cmNlCUQsIFgNCSYgQi1Tb3VyY2UgdG8gQXJlZw0NTkFOCUxvZ2ljYWwgTmFuZCBv ZiBBLVNvdXJjZQkJRCwgWA0JCQkmIEItU291cmNlIHRvIEFyZWcNDUFOQglMb2dpY2FsIEEgYW5k IE5vdCBCIG9mIEEtU291cmNlCUQsIFgNCSYgQi1Tb3VyY2UgdG8gQXJlZw0NTkFCCUxvZ2ljYWwg Tm90IEEgYW5kIEIgb2YgQS1Tb3VyY2UJRCwgWA0JCQkmIEItU291cmNlIHRvIEFyZWcNDU9USEVS IEFSSVRITUVUSUMNDUNNQQlDb21wbGVtZW50IEEJCQlOQQ0NVENBCVR3b5JzIENvbXBsZW1lbnQg QQkJCU5BDQ1BT0EJQWRkIE9uZSB0byBBcmVnLCAJCQlOQQ0JT3ZlcmZsb3cgaW50byBDRkYNDUFD QQlBZGQgQ0ZGIHRvIEFyZWcsCQkJTkENCU92ZXJmbG93IGludG8gQ0ZGDQ1BTU8JQXJlZyBNaW51 cyAxLAkJCQlOQQ0JVW5kZXJmbG93IGludG8gQ0ZGDQwNTm90ZTogIEFsbCBvZiB0aGUgYWJvdmUg QXJpdGhtZXRpYyBhbmQgTG9naWMgJiBMREEgaW5zdHJ1Y3Rpb25zIG1heSBpbmNsdWRlIGFuIG9w dGlvbmFsIFN0b3JlLiAgRm9yIGV4YW1wbGU6IExEQS9TVEEgb3IgQUREL1NUQS4gIEluIHRoZXNl IGNhc2VzIGENCURlc3RpbmF0aW9uIEFkZHJlc3MgaXMgc3BlY2lmaWVkLiAgVGhlIHJlc3VsdHMg d2lsbCBhbHdheXMgYmUgdG8gdGhlIEFyZWcNVGhlIEEtU291cmNlIGlzIGVpdGhlciB0aGUgQXJl ZyBvciBtZW1vcnkuDQ1EID0gRGlyZWN0DVggPSBJbmRleCBSZWxhdGl2ZQ1JID0gSW5kaXJlY3Qg KEN1cnJlbnRseSBKTVAgb25seSCWIHRoaXMgY2hhbmdlIHRvIGFsbCBNZW0gUmVmIEluc3RydWN0 aW9ucykNDVNISUZUIElOU1RSVUNUSU9OUw0NTEdMCUxvZ2ljYWwgTGVmdA0JVGhlIEFyZWcgb3Ig QS1Tb3VyY2UgaXMgc2hpZnRlZCBsZWZ0IChuKSBwb3NpdGlvbnMuDQlaRVJPknMgZmlsbCBpbiB2 YWNhdGVkIGJpdCBwb3NpdGlvbnMgb2YgTGVhc3QgU2lnbmlmaWNhbnQNRW5kLiAgQTMyIGlzIHNo aWZ0ZWQgdG8gdGhlIENGRi4gIFJlc3VsdCB0byBBcmVnIGFuZA1EZXN0aW5hdGlvbiBpZiBzcGVj aWZpZWQuIChMR0wvU1RBKQ0JDUxHUglMb2dpY2FsIFJpZ2h0DQlUaGUgQXJlZyAgb3IgQS1Tb3Vy Y2UgaXMgc2hpZnRlZCByaWdodCAobikgcG9zaXRpb25zLg0JWkVST5JzIGZpbGwgaW4gdmFjYXRl ZCBiaXQgcG9zaXRpb25zIG9mIE1vc3QgU2lnbmlmaWNhbnQNCUVuZC4gIEExIGlzIHNoaWZ0ZWQg dG8gdGhlIENGRi4gIFJlc3VsdCB0byBBcmVnIGFuZA0JRGVzdGluYXRpb24gaWYgc3BlY2lmaWVk LiAgKExHUi9TVEF9DQ1BTFIJTG9naWNhbCBMZWZ0IFJvdGF0ZQ0JVGhlIEFyZWcgb3IgQS1Tb3Vy Y2UgaXMgc2hpZnRlZCBsZWZ0LCBlbmQtYXJvdW5kIChuKSBwb3NpdGlvbnMuDQlBMzIgaXMgc2hp ZnRlZCB0byBBMSBhbmQgdGhlIENGRi4gIFJlc3VsdCB0byBBcmVnIGFuZA0JRGVzdGluYXRpb24g aWYgc3BlY2lmaWVkLiAgKEFMUi9TVEEpDQ1BUlIJTG9naWNhbCBSaWdodCBSb3RhdGUNCVRoZSBB cmVnIG9yIEEtU291cmNlIGlzIHNoaWZ0ZWQgcmlnaHQsIGVuZC1hcm91bmQgKG4pIHBvc2l0aW9u cy4NCUExIGlzIHNoaWZ0ZWQgdG8gQTMyIGFuZCB0aGUgQ0ZGLiAgUmVzdWx0IHRvIEFyZWcgYW5k DQlEZXN0aW5hdGlvbiBpZiBzcGVjaWZpZWQuICAoQVJSL1NUQSkNDUFMUwlBcml0aG1ldGljIExl ZnQgU2hpZnQNCVRoZSBBcmVnIG9yIEEtU291cmNlIGlmIHNoaWZ0ZWQgbGVmdCAobikgcG9zaXRp b25zLg0JWkVST5JzIGZpbGwgaW4gdmFjYXRlZCBiaXQgcG9zaXRpb25zIG9mIExlYXN0IFNpZ25p ZmljYW50DQlFbmQuIElmIHNoaWZ0aW5nIGNhdXNlcyBhIGNoYW5nZSBpbiBzaWduIG9mIEFyZWcg b3IgQS1Tb3VyY2UNCWF0IGFueSB0aW1lIGR1cmluZyB0aGUgaW5zdHJ1Y3Rpb24sIHRoZSBDRkYg aXMgc2V0LiAgSWYgdGhlIHNpZ24NCWlzIG5vdCBjaGFuZ2VkLCB0aGUgQ0ZGIGlzIHJlc2V0LiAg UmVzdWx0IHRvIEFyZWcgYW5kDQlEZXN0aW5hdGlvbiBpZiBzcGVjaWZpZWQuICAoQUxTL1NUQSkN DA1BUlMJQXJpdGhtZXRpYyBSaWdodCBTaGlmdA0JVGhlIEFyZWcgb3IgQS1Tb3VyY2UgaXMgc2hp ZnRlZCByaWdodCAobikgcG9zaXRpb25zLg0JVGhlIHNpZ24gYml0IChBMzIpIGRvZXMgbm90IGNo YW5nZTsgaXQgaXMgc2hpZnRlZCBpbnRvIHZhY2F0ZWQNcG9zaXRpb25zIG9mIHRoZSBBcmVnIG9y IEEtU291cmNlIChTaWduIEV4dGVuZGVkKS4gIFRoZSBDRkYNdGFrZXMgdGhlIHN0YXRlIG9mIHRo ZSBsYXN0IGJpdCBzaGlmdGVkIG91dCBvZiB0aGUgcmVnaXN0ZXIuICBSZXN1bHQNdG8gQXJlZyBh bmQgRGVzdGluYXRpb24gaWYgc3BlY2lmaWVkLiAgKEFSUy9TVEEpDQ1Ob3RlOiAgU2hpZnQgYW1v dW50IChuKSwgd2hlcmUgKG4pID0gMSB0byAzMQ0NQ09OVFJPTCBJTlNUUlVDVElPTlMNCQkNCQlJ UlgJSW5jcmVtZW50IFNlbGVjdGVkIEluZGV4DQkJDQkJU1hTCVNlbGVjdCBBLVNvdXJjZSBJbmRl eA0NCQlTWEQJU2VsZWN0IEItU291cmNlIEluZGV4DQ0JCVNYVwlTZWxlY3QgRGVzdGluYXRpb24g SW5kZXgNDUNMQglDbGVhciBCaXQgKG4pDQlDbGVhciB0aGUgc2VsZWN0ZWQgYml0DQ1TQlQJU2V0 IEJpdCAobikNCVNldCB0aGUgc2VsZWN0ZWQgYml0DQ1UU0IJVGVzdCBCaXQgKG4pDQlUZXN0IHRo ZSBzZWxlY3RlZCBiaXQNDUNCWQlDbGVhciBCeXRlIChuKQ0JQ2xlYXIgdGhlIHNlbGVjdGVkIGJ5 dGUNCVJpZ2h0IEJ5dGUgPSAwDQ1SQ0IJUmVzZXQgQ0ZGDQ1TQ0IJU2V0IENGRg0NQ1NBCUNvcHkg U2lnbiBhbmQgU2V0IFNpZ24gUGx1cw0JQTMyIHRvIENGRiwgQ2xlYXIgQTMyDQkoSGF2ZSBhIGxv Z2ljIGVycm9yIGhlcmUpDUNIUwlDb21wbGVtZW50IEFyZWcgU2lnbg0NQ1JBCUNsZWFyIEFyZWcN DUlOSAlJbmhpYml0IEludGVycnVwdA0NRU5CCUVuYWJsZSBJbnRlcnJ1cHQNDUhMVAlIYWx0LCBv ciBXYWl0IGZvciBJbnRlcnJ1cHQgaWYgRU5BQkxFRCB3aXRoIHByaW9yIEVOQg0NTk9QCU5vIE9w ZXJhdGlvbg0NQlJBTkNIIElOU1RSVUNUSU9OUw0NQkxUCUJyYW5jaCBMZXNzIFRoYW4NCVJlc3Vs dCBvZiBwcmV2aW91cyBDQVMNDUJFUQlCcmFuY2ggRXF1YWwNCVJlc3VsdCBvZiBwcmV2aW91cyBD QVMNDUJHVAlCcmFuY2ggR3JlYXRlciBUaGFuDQlSZXN1bHQgb2YgcHJldmlvdXMgQ0FTDQ1CTloJ QnJhbmNoIE5vdCBaZXJvDQlSZXN1bHQgb2YgcHJldmlvdXMgSVJTIChOWikNDVRCWglUZXN0IEJp dCBaZXJvDQ1UQk5aCVRlc3QgIEJpdCBOb3QgWmVybw0NU1JDCUJyYW5jaCAgaWYgQ0ZGIHJlc2V0 DQ1TU0MJQnJhbmNoIGlmIENGRiBzZXQNDVNaRQlCcmFuY2ggQXJlZyBaZXJvIChBWikNDVNOWglC cmFuY2ggQXJlZyBOb3QgWmVybyAoQVopDQ1TTE4JQnJhbmNoIEExID0gT25lDQ1TTFoJQnJhbmNo IEExID0gWmVybw0NU1BMCUJyYW5jaCBBMzIgPSBaZXJvIChwb3NpdGl2ZSBzaWduKQ0NU01JCUJy YW5jaCBBMzIgPSBPbmUgKG5lZ2F0aXZlIHNpZ24pDQ1TVzEJQnJhbmNoIFN3aXRjaCAxIFNldCAo T04pDQlBbiBBcHBsaWNhdGlvbiBQcm9ncmFtbWVyIGlzIERlYnVnZ2luZywNCURPIE5PVCBIQUxU IE9OIEVSUk9SUw0NU1cyCUJyYW5jaCBTd2l0Y2ggMiBTZXQgKE9OKSwNQ2FsbCBTeXN0ZW0gUHJv Z3JhbW1lciBEZWJ1ZyBSb3V0aW5lDQ1CUkEJIEJyYW5jaA0NTm90ZToJQWxsIG9mIHRoZSBhYm92 ZSBlc3RhYmxpc2ggYSBjb25kaXRpb24gdGhhdCB3aWxsIGJlIFRFU1RFRCB1cG9uDQlFeGVjdXRp b24gb2YgQlJBLiAgT25lIE9SIG1vcmUgb2YgdGhlc2UgY29uZGl0aW9ucyBtYXkgYmUgDWVzdGFi bGlzaGVkIHByaW9yIHRvIEJSQS4gIEZvciBleGFtcGxlOyBDQVMgZXN0YWJsaXNoZXMgb25lIG9m DXRocmVlIGNvbmRpdGlvbnMuICBJIG1heSBleGVjdXRlIEJSQSBvbiBFcXVhbCBvciBMZXNzIFRo YW4gaWYNQkVRL0JMVCBpcyBwcmV2aW91c2x5IHNwZWNpZmllZCBvciBtYXkgZXhlY3V0ZSBCUkEv QkVRL0JMVA1pbiB0aGUgc2FtZSBpbnN0cnVjdGlvbi4NDUlOUFVUL09VVFBVVCBJTlNUUlVDVElP Tg0NCQlNb3YJTW92ZSBBLVNvdXJjZSBkYXRhIG9yIG9uZSBvZiB0aGUgZm9sbG93aW5nIGNvbnRy b2xzDQkJCSAwID0gQ2xlYXIgaW50ZXJydXB0IExldmVsIDEgKExvd2VzdCkNCQkJIDEgPSBDbGVh ciBpbnRlcnJ1cHQgTGV2ZWwgMg0JCQkgMiA9IENsZWFyIGludGVycnVwdCBMZXZlbCAzDQkJCSAz ID0gQ2xlYXIgaW50ZXJydXB0IExldmVsIDQNCQkJIDQgPSBDbGVhciBpbnRlcnJ1cHQgTGV2ZWwg NQ0JCQkgNSA9IENsZWFyIGludGVycnVwdCBMZXZlbCA2DQkJCSA2ID0gQ2xlYXIgaW50ZXJydXB0 IExldmVsIDcNCQkJIDcgPSBDbGVhciBpbnRlcnJ1cHQgTGV2ZWwgOCAoSGlnaGVzdCkNCQkJIDgg PSBTZW5kIEludGVyLVByb2Nlc3NvciBJbnRlcnJ1cHQgUHVsc2UNCQkJIDkgPSBGQkMgR2xvYmFs IE1lbW9yeSBXcml0ZQ0JCQkgQSA9IEZCQyBQb3J0IDQgV3JpdGUNCQkJIEIgPSBGQkMgUmVmcmVz aCBNZW1vcnkgV3JpdGUNCQkJIEMgPSBDSUNVIFJlYWQgdG8gRkJDIFBvcnQgNCBXcml0ZSAoTGFu Z3VhZ2UgUHJvY2Vzc29yKSwNICAgICAgICBSZXNlcnZlZCAoUGVyaXBoZXJhbCBQcm9jZXNzb3Ip DQkJCSBEID0gUmVzZXJ2ZWQNCQkJIEUgPSBSZXNlcnZlZA0JCQkgRiA9IFJlc2VydmVkDQ1Nb3Zl IEEtU291cmNlIERhdGEgZnJvbS90byBHbG9iYWwgcmVxdWlyZXMgdHdvIE1PViBJbnN0cnVjdGlv bnMgdG8gc2V0dXAgR2xvYmFsIFR3by1Qb3J0IEFkZHJlc3Mgd2l0aCBCYW5rIFNlbGVjdCBhbmQg TG9jYWwgRkJDIFBvcnQgNCBBZGRyZXNzLCBCYW5rIFNlbGVjdCBhbmQgUmFuZ2UgQ291bnQuIENv bnRyb2wgZmllbGQgZGV0ZXJtaW5lcyBkaXJlY3Rpb24uDQ1Nb3ZlIEEtU291cmNlIERhdGEgZnJv bS90byBSZWZyZXNoIE1lbW9yeSByZXF1aXJlcyB0d28gTU9WIEluc3RydWN0aW9ucyB0byBzZXR1 cCBSZWZyZXNoIE1lbW9yeSBUd28tUG9ydCBBZGRyZXNzIGFuZCBMb2NhbCBQb3J0IDQNQWRkcmVz cywgQmFuayBTZWxlY3QgYW5kIFJhbmdlIENvdW50LiAgQ29udHJvbCBmaWVsZCBkZXRlcm1pbmVz IGRpcmVjdGlvbi4NDE9QVElPTkFMIElOU1RSVUNUSU9OUw0NVGhlIG9wdGlvbmFsIE11bHRpcGx5 L0RpdmlkZSBQcm9jZXNzb3IgcmVxdWlyZXMgYW4gYWRkaXRpb25hbCBGUEdBIGRldmljZS4NQm90 aCBJbnN0cnVjdGlvbnMgYXJlIHRyZWF0ZWQgYXMgYXN5bmNocm9ub3VzIHBlcmlwaGVyYWwgZGV2 aWNlcyBhbmQgbWF5IGJlIGluaXRpYXRlZCBpbiBhbnkgc2VxdWVuY2UgliBlZmZlY3RpdmVseSBl eGVjdXRpbmcgaW4gcGFyYWxsZWwuIEJvdGggYXJlIGluaXRpYXRlZA13aXRoIHRoZSBNb3YgSW5z dHJ1Y3Rpb24uDQ1NVUxUSVBMWSCWIFRoZSBkZXNpZ24gcGVyZm9ybXMgYW4gVW4tU2lnbmVkIDMy IFggMzIgVGltZS1TZXF1ZW5jZWQsIHBpcGVsaW5lZCBtdWx0aXBseS9hZGQgd2l0aCBOaWJibGUg U2tpcC4gKE5pYmJsZSA9IDQgYml0cykuICBUaGUgbXVsdGlwbGllciBtdXN0IGJlIGFwcGxpZWQg Zmlyc3QgaW4gc2VxdWVuY2UgZm9yIGV4YW1pbmF0aW9uIG9mIHRoZSBkYXRhLiAgVGhlIHJlc3Vs dCBpcyBhIDY0IEJpdCBQcm9kdWN0IHdoaWNoIHJlcXVpcmVzIHR3byBNb3YgaW5zdHJ1Y3Rpb25z IGZvciBpbnB1dHRpbmcgdGhlIE1TUCAoTW9zdCBTaWduaWZpY2FudCBQcm9kdWN0KSBhbmQgdGhl IExTUCAoTGVhc3QgU2lnbmlmaWNhbnQgUHJvZHVjdCkuIEluc3RydWN0aW9uIGNvbXBsZXRpb24g aXMgc2lnbmFsZWQgd2l0aCBhbiBJbnRlcnJ1cHQuICBJbmZvcm1hdGlvbiBvbiBUaW1lDVNlcXVl bmNlIE11bHRpcGx5IG1heSBiZSBvYnRhaW5lZCBmcm9tIEFNRCBEYXRhIEJvb2tzIGZvciBhcHBs aWNhdGlvbiBvZiB0aGUgQU0yNVMwNSwgYSAyIFggNCBUd2+ScyBDb21wbGVtZW50IE11bHRpcGxp ZXIuDQ1ESVZJREUgliBUaGUgZGVzaWduIHBlcmZvcm1zIGFuIFVuLVNpZ25lZCAzMiBYIDMyIHBp cGVsaW5lZCBkaXZpZGUsDVNraXBwaW5nIG92ZXIgc3RyaW5ncyBvZiBPbmWScyBhbmQgWmVyb5Jz LiAgVGhlIGRlc2lnbiBpcyBiYXNlZCBvbiB0aGUgdGV4dCBpbg2TVGhlIExvZ2ljIG9mIENvbXB1 dGVyIEFyaXRobWV0aWM6IGJ5IEl2YW4gRmxvcmVzLCBQcmVudGljZS1IYWxsLCBJbmMuLCB0aGUN TGlicmFyeSBvZiBDb25ncmVzcyBDYXRhbG9nIENhcmQgTnVtYmVyIDYzLTE0NzI3LiAgVGhlIHJl c3VsdCBpcyBhIDMyIEJpdA1RdW90aWVudCBhbmQgMzIgQml0IENvcnJlY3RlZCBSZW1haW5kZXIu ICBUaGUgRGl2aXNvciBtdXN0IGJlIGVxdWFsIHRvIG9yDWdyZWF0ZXIgdGhhbiB0aGUgRGl2aWRl bmQuICBUaGUgRGl2aXNvciBtdXN0IGJlIGFwcGxpZWQgZmlyc3QgZm9yIGENTm9ybWFsaXphdGlv biBwcm9jZXNzIHRvIG9jY3VyLiAgT3V0cHV0dGluZyB0aGUgRGl2aWRlbmQgd2lsbCBjYXVzZSBh bg1FcXVhbGl6YXRpb24gcHJvY2VzcyB0byBvY2N1ci4gIFR3byBNb3YgaW5zdHJ1Y3Rpb25zIGFy ZSByZXF1aXJlZCB0byBmaXJzdA1pbnB1dCB0aGUgUXVvdGllbnQgYW5kIHRoZW4gdGhlIGNvcnJl Y3RlZCByZW1haW5kZXIgaWYgZGVzaXJlZC4gIEluc3RydWN0aW9uDWNvbXBsZXRpb24gaXMgc2ln bmFsZWQgd2l0aCBhbiBJbnRlcnJ1cHQuDQ1UaGVzZSBkZXNpZ25zIHdlcmUgY29tcGxldGVkIGJ1 dCBub3QgdGVzdGVkIGluIDE5OTcgdXNpbmcgYSBRdWlja2xvZ2ljDVFMMzA2MC00LiAgVGhlIHJl c3VsdHMgb2YgUGxhY2UgJiBSb3V0ZSBhcmU6DQ0JTG9naWMgQ2VsbHMJCSAgICAgICAgICA4MTQg b2YgMTU4NA0JQ2xvY2sgQ2VsbHMJCSAgICAgICAgICAgICAgMiBvZiAgOA0JQmkgRGlyZWN0aW9u YWwgQ2VsbHMgICAgICAgCTQyIG9mIDMwOA0JUm91dGluZyBSZXNvdXJjZXMJICAgICAgMjMyMTMg b2YgMTAyOTE2DQlWaWFMaW5rIFJlc291cmNlcwkgICAgICAxOTk1MSBvZiAyNzYyMjkwDQlDZWxs IEZGknMJCSAgICAgICAgICA0Mjcgb2YgMTU4NA0NVGhpcyBkZXNpZ24gd2lsbCB1c2UgdGhlIFFM NjI1MCBvZiB0aGUgUXVpY2tsb2dpYyBFY2xpcHNlIFNlcmllcyB0byBvYnRhaW4NdGhlIGJlc3Qg cG9zc2libGUgcGVyZm9ybWFuY2UuICBTbGlnaHQgY2hhbmdlcyB3aWxsIGJlIHJlcXVpcmVkIHRv IGNvbmZvcm0NdG8gdGhlIE1vdiBpbnN0cnVjdGlvbiBhbmQgSW50ZXJydXB0IEdlbmVyYXRpb24u DQwNRkxPQVRJTkcgUE9JTlQNDU11c3QgZmlyc3Qgb2J0YWluIHRoZSBsYXRlc3QgSUVFRSBTcGVj aWZpY2F0aW9uLiAgQmFzZWQgb24gbXkgZXhwZXJpZW5jZSBpbiAxOTc5LTgwIGF0IHRoZSBIb25l eXdlbGwgU21hbGwvTWVkaXVtIEluZm9ybWF0aW9uIFN5c3RlbXMgRGl2aXNpb24gdGhpcyBkZXNp Z24gc2hvdWxkIHRha2UgYXBwcm94aW1hdGVseSB0d28gbW9udGhzLiAgRGl2aXNpb24gV0FTIGFj Y29tcGxpc2hlZCBpbiB0aGUgU0FNRSBtYW5uZXIgYXMgZGVzY3JpYmVkIGFib3ZlLiBNdWx0aXBs aWNhdGlvbiBNQVkgYmUgYWNjb21wbGlzaGVkIGluIHRoZSBzYW1lIG1hbm5lciBhcyBhYm92ZSBo b3dldmVyIGF0IEhvbmV5d2VsbCwgdGhpcyB3YXMNYWNjb21wbGlzaGVkIGJ5IGV4YW1pbmF0aW9u IG9mIE9uZZJzIGFuZCBaZXJvIHN0cmluZ3MgYXMgZGVzY3JpYmVkIGJ5IEZMT1JFUy4gIFRoaXMg ZGVzaWduIHdpbGwgdXNlIHRoZSBRTDY1MDAgRlBHQSBhbmQgc2hvdWxkIHVzZSB0aGUgZXF1aXZh bGVudCBvZiAyNTAgVFRMIE1TSSBjb21wb25lbnRzLiAgVGhlIG9uLWNoaXAgUkFNIHdpbGwgYmUg dXNlZCBmb3Igc3RvcmluZyBQcm9ncmFtcy9Db25zdGFudHMgcHJlc2VudGVkIHRvIGl0IGZyb20g RkJDIFBvcnQgNCBvZiB0aGUgTGFuZ3VhZ2UgUHJvY2Vzc29yIGZvciBleGVjdXRpb24uICBJIHdp bGwgYXNzdW1lIHRoZSBJRUVFIHN0YW5kYXJkIGlzIDggQml0IEV4cG9uZW50IGFuZCAyNCBCaXQg TWFudGlzc2EgYW5kIHByb2NlZWQgYWNjb3JkaW5nbHkuICBJdCB3aWxsIGNvbmZvcm0gdG8gdGhl IE1vdiBpbnN0cnVjdGlvbiBhbmQgZ2VuZXJhdGUgYW4gaW50ZXJydXB0IG9uIGNvbXBsZXRpb24g b2YgYSByZXF1ZXN0ZWQgc2VyaWVzLg0NR0VORVJBTCBDT01NRU5UUw0NWW91IHdpbGwgbm90aWNl IEkgdXNlIGEgZGlzdHJpYnV0ZWQgcHJvY2Vzc2luZyBzY2hlbWUuICBUaGlzIHdpbGwgYWxsb3cg QUxMDVByb2Nlc3NvcnMgdGhlIGJlc3QgcG9zc2libGUgUGxhY2UgJiBSb3V0ZSwgZmV3ZXN0IHdp cmVzIGFuZCBiZXN0IHBvc3NpYmxlIHBlcmZvcm1hbmNlLiAgDQ0NCQkNCQ0NCQkNDQ0NDQ0NDQkJ IA0JDQ0NCQ0NCQ0JCQ0JDQkNCQkgIA0JCSAgDQ0NE1BBR0UgIBUNDQ0TUEFHRSAgFDE4FQ0NDQ0N AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA AQQAAAMEAAA2BAAAawQAAG0EAADQBAAA0QQAAAoFAAAaBQAAHAUAACwFAABWCgAAXAoAAIQKAACX CgAADQsAABwLAADYDwAA9A8AABISAAAuEgAAgBcAAJwXAACIIQAAnCEAADQpAABGKQAASCkAAFkp AABwLgAAgC4AALphAAC7YQAAimUAAItlAACYaQAAr2kAAKZyAACpcgAAvnIAAMJyAADtcgAA8HIA AJF1AACUdQAA9nUAAPd1AAAhdgAAInYAACh2AAApdgAAKnYAACx2AAAtdgAAM3YAADR2AAA2dgAA N3YAADh2AAA8dgAA+gD6APgA9ADxAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0 APQA6ufq5wDq5+rf6ucAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8wShAAbUgABG5IAAR1 CAEEMEoQAAANA2oAAAAAMEoQAFUIAQRDSiAAAAY1CIFcCIEAA0gqAQo1CIFDSiQAXAiBPAAEAAAB BAAAAgQAAAMEAAA2BAAAXgQAAHUEAACcBAAAnQQAAJ4EAACxBAAA0AQAANEEAADSBAAA0wQAANQE AADVBAAA1gQAANcEAADYBAAA2QQAANoEAADbBAAA3AQAAOwEAADtBAAA7gQAAO8EAADwBAAA+QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAA8gAAAAAAAAAAAAAAAAABAwAABAAAAyQBYSQBAAEAAAAFAQAOhOT9XYTk/QAcAAQAACF2 AAA7dgAA/f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQLwBAAA8QQA APIEAADzBAAA9AQAAPUEAAD2BAAA9wQAAPgEAAD5BAAA+gQAAPsEAAD8BAAA/QQAAAkFAAAaBQAA GwUAABwFAAAsBQAAdQUAAKgFAACpBQAA8wUAAEUGAACTBgAA4QYAADEHAACKBwAA2wcAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAEAAADJAFhJAEAHNsHAAArCAAA fQgAAJAIAACRCAAA3ggAACYJAAB6CQAA6gsAAOsLAAAuDQAALw0AACUOAAB5DgAAJw8AAIgPAADX DwAA9A8AAPUPAAA+EAAAeRAAAHoQAAANEQAAQREAAEIRAAD0EQAAERIAABISAAAuEgAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAA+E0AJehNACAAEAAAAcLhIAAC8SAACj EwAApBMAAMQTAAADFAAALxQAAFgUAACOFAAA1RQAABYVAAAYFQAAbxUAABoWAAAbFgAA2xYAANwW AAAyFwAAfhcAAIAXAACcFwAAnRcAALAYAACyGQAAsxkAAOcZAAAEGgAATBoAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAFAAARhNACYITQAgAFAAAPhAgHXoQIBwUAAAomAAtGAwAAAQAAABtMGgAAjRoAANga AAASGwAAJhsAADkbAAB7GwAApRsAAKYbAADvGwAAGBwAAEEcAABtHAAAlBwAAK8cAADRHAAAHB0A AGUdAAC1HQAA9h0AAPcdAAD4HQAAOR4AAHEeAACLHgAAwx4AAMQeAAD2HgAALh8AAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAAAAAAAAAEAAAUAAAomAAtGBAAABQAAEYTQAmCE0AIAHC4fAABoHwAApB8A AOgfAADqHwAAOSAAAJYgAABJIQAAhyEAAIghAACcIQAAnSEAAPchAABZIgAAsSQAABIlAAAgJQAA LiUAAEAlAABNJQAAXCUAAF0lAAARJgAAJCYAAEQmAABlJgAAgCYAAJomAAC1JgAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAFAAARhNACYITQAgActSYAANImAADtJgAA CicAACcnAABGJwAAYycAAIAnAACCJwAAnycAALwnAADbJwAA+CcAABcoAAA1KAAAVCgAAFUoAABu KAAAiSgAAIooAAAzKQAANCkAAEYpAABHKQAAWSkAAKMpAADzKQAASioAAFEsAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAD4TQAl6E0AIAAQAAABxRLAAAoiwAAPssAABW LQAAjy0AANstAABtLgAAby4AAIAuAADRLgAAMC8AAEMvAABbLwAAci8AAIcvAACgLwAAvC8AAM4v AADqLwAA8S8AAAowAAAtMQAARzEAAGMxAAB9MQAAijEAAKwxAADYMQAAEzIAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAAAAAAABAAAABQAAD4TQAl6E0AIABQAAEYTQAmCE0AIAHBMyAABOMgAAijIAAKEy AADTMgAA1jIAAIgzAACwMwAAsTMAAGI2AABjNgAAtjYAAP42AADPNwAA0DcAAB44AABsOAAAtDgA ALo4AAC7OAAADDkAAC46AAB8OgAAhzoAAIg6AABzOwAAdDsAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAA AAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAAAAAAAAJAAAPhHAIEYRg+l6EcAhghGD6 AAUAAA+EcAhehHAIAAUAABGE0AJghNACAAUAAA+E0AJehNACAAEAAAAadDsAAL07AAADPAAASjwA AEs8AABQPQAAUT0AAKA9AADmPQAALD4AAG8+AACxPgAA+j4AAHY/AAB3PwAAGEEAABlBAABgQQAA oUEAABlDAAAaQwAAY0MAAPBDAAD7RAAA/EQAAE5FAAAgRgAAk0YAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAO8AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAFAAARhNACYITQAgAJAAAPhHAIEYRg+l6EcAhghGD6ABuTRgAAlEYAAFZIAADQSAAA D0sAADFMAABzTAAAdEwAALtMAAADTQAARE0AAItNAADVTQAAdU4AAL9OAAADTwAAl08AAN5PAAAq UAAAwFAAAApRAABZUQAAolEAAKNRAAC3UQAAuFEAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQUAAAURABGE AABghAAAAAUAAA+EcAhehHAIAAkAAA+EcAgRhGD6XoRwCGCEYPoAGbhRAADjUQAA5FEAAAVSAAAG UgAAJFIAADRSAAA1UgAAUVIAAGNSAABkUgAAgVIAAJZSAACXUgAAtVIAANRSAADsUgAA7VIAAANT AAAgUwAAIVMAAEhTAABYUwAAWVMAAIFTAACUUwAAlVMAAL1TAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA 6wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAAAAAAAAkA AA+EcAgRhGD6XoRwCGCEYPoACQAAD4RwCBGEMP1ehHAIYIQw/QAbvVMAANtTAADcUwAAAVQAACVU AAAmVAAARFQAAFxUAABwVAAAcVQAAJNUAACvVAAAsFQAANpUAAD3VAAA+FQAABpVAAAuVQAAL1UA AFlVAABtVQAAblUAAI5VAACiVQAAo1UAAMVVAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOUA AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADbAAAAAAAA AAAAAAAA2wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAA AO8AAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAA AAAAAAAAAAAA5QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAA AAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADl AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAA+EoAURhNACXoSgBWCE0AIACQAAD4RwCBGEMP1ehHAI YIQw/QAJAAAPhHAIEYRg+l6EcAhghGD6AAUAAA+EcAhehHAIABnFVQAA2VUAANpVAAAFVgAAGVYA ABpWAAA9VgAAU1YAAFRWAAB9VgAAkVYAAJJWAAC7VgAA0VYAANJWAADjVgAA5FYAAPpWAAD7VgAA F1cAABhXAAAzVwAARlcAAEdXAABhVwAAdFcAAHVXAACNVwAAoVcAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAAAAAAABBgAAAQAAAAkAAA+EcAgRhDD9XoRwCGCEMP0AHKFXAACjVwAANlgAAIFYAACsWAAA rVgAALhYAADLWAAAF1kAABhZAAArWQAALFkAAD1ZAAByWQAArVkAAOJZAAAGWgAACFoAABpaAABR WgAAi1oAAMBaAADmWgAA51oAAP9aAABAWwAAd1sAAJ1bAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB BwAABQAAD4RwCF6EcAgACQAAD4RwCBGEMP1ehHAIYIQw/QAbnVsAAJ5bAAC3WwAA+VsAADBcAABW XAAAV1wAAHFcAACmXAAA4VwAAB9dAABhXQAAmF0AAL5dAADAXQAA210AABFeAABRXgAAjV4AANJe AAADXwAABF8AADFfAAAyXwAAR18AAEpfAABpXwAAbF8AAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAA AAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEH AAAFAAAPhHAIXoRwCAAJAAAPhHAIEYQw/V6EcAhghDD9ABtsXwAAiF8AAIlfAAClXwAApl8AAMVf AADGXwAA2F8AAPBfAADxXwAAAWAAABdgAAAYYAAAKWAAAEBgAABBYAAAVGAAAG1gAAB9YAAAfmAA AIxgAACNYAAAmWAAAJpgAAC6YAAA0WAAAOxgAAAFYQAABmEAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAFAAAPhKAFXoSgBQABAAAAHAZhAAAVYQAAFmEAACxhAAAtYQAAQmEA AENhAAB9YQAAfmEAAI9hAACQYQAApGEAAKVhAAC6YQAA0mEAANNhAADkYQAA/GEAAP1hAAAVYgAA LWIAAC5iAABCYgAAX2IAAGBiAAByYgAAc2IAAItiAACMYgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEEAAAFAAAPhKAFXoSgBQAcjGIAAKViAACmYgAAvGIAAL1iAADXYgAA 2GIAAPZiAAD3YgAAC2MAAAxjAAAhYwAAImMAAEhjAABJYwAAbmMAAG9jAACMYwAAtWMAAMxjAADN YwAA62MAABBkAAARZAAAHWQAAB5kAABkZAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAA AAAAAAAAAAAAAOUAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAACQAAD4TQAhGE0AJehNACYITQAgAJ AAAPhKAFEYTQAl6EoAVghNACAAUAAA+EoAVehKAFABpkZAAAoGQAAN9kAAAdZQAAWGUAAHFlAABy ZQAAi2UAAIxlAADGZQAA72UAAA9mAAAvZgAAT2YAAG9mAACPZgAAr2YAANlmAAAGZwAAJmcAAD9n AABgZwAAnGcAAMRnAADVZwAA5mcAAPdnAAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAAAAAAAAAA AAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAA AAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAA AOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAAAAAAAABQAAD4RwCF6EcAgAAQAAAAEHAAAJAAAPhKAFEYTQ Al6EoAVghNACAAkAAA+E0AIRhNACXoTQAmCE0AIAGvdnAAD4ZwAAyWgAAMpoAABMaQAAl2kAAK5p AACvaQAA+mkAAJhqAACyagAAs2oAAGtsAADmbAAA52wAACttAAB6bQAAxm0AABBuAABabgAAnm4A AOVuAAAwbwAAfW8AAKdvAACobwAA728AABxwAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAA AAAAAAAA7QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAPhKAF EYTQAl6EoAVghNACAAUAAA+EcAhehHAIAAEAAAAbHHAAAB1wAABBcAAAZXAAAIxwAAC1cAAA33AA AAFxAAACcQAATXEAAJhxAADJcQAAy3EAANpxAADbcQAAPHMAADZ1AAA3dQAASHUAAEl1AACVdQAA 73UAAPB1AADxdQAA9HUAAPZ1AAD3dQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAA AAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAA+EcAgR hGD6XoRwCGCEYPoAAQgAAAUAAA+EcAhehHAIABr3dQAA+nUAAPt1AAD8dQAA/XUAAP51AAD/dQAA AHYAAAF2AAAFdgAAB3YAAAh2AAAJdgAAC3YAAAx2AAAOdgAAEXYAABN2AAAVdgAAGnYAAB92AAAg dgAAIXYAACp2AAArdgAALHYAADh2AAD5AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAIDwAYhPz/GYQBABsmYCMkAgAB AAAABQAAD4RwCF6EcAgABQAAEYTQAmCE0AIAGjh2AAA5dgAAOnYAADt2AAA8dgAA/QAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEPAAAEIAAxkGgBH7DQLyCw4D0hsKAFIrA4BCOQoAUkkKAF JbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABIACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4 AAwABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBDIAAUABAAIA MgAMAAkASABlAGEAZABpAG4AZwAgADEAAAAIAAEABiQBQCYABgA1CIFcCIE4AAIAAQACADgADAAJ AEgAZQBhAGQAaQBuAGcAIAAyAAAADgACAAMkAQYkAUAmAWEkAQYANQiBXAiBNgADQAEAAgA2AAwA CQBIAGUAYQBkAGkAbgBnACAAMwAAAA4AAwADJAEGJAFAJgJhJAEEAENKJAA6AARAAQACADoADAAJ AEgAZQBhAGQAaQBuAGcAIAA0AAAAEAAEAAYkAQ+EoAVAJgNehKAFBgA1CIFcCIFCAAVAAQACAEIA DAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAAGAAFAAYkAQ+EcAgRhGD6QCYEXoRwCGCEYPoGADUIgVwI gUIABkABAAIAQgAMAAkASABlAGEAZABpAG4AZwAgADYAAAAYAAYABiQBD4RwCBGEMP1AJgVehHAI YIQw/QYANQiBXAiBQgAHQAEAAgBCAAwACQBIAGUAYQBkAGkAbgBnACAANwAAABgABwAGJAEPhNAC EYTQAkAmBl6E0AJghNACBgA1CIFcCIE6AAhAAQACADoADAAJAEgAZQBhAGQAaQBuAGcAIAA4AAAA EAAIAAYkAQ+EcAhAJgdehHAIBgA1CIFcCIEAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAg AFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAsACBAAQDyACwADAAGAEYA bwBvAHQAZQByAAAADQAPAA3GCAAC4BDAIQECAAAAJgApQKIAAQEmAAwACwBQAGEAZwBlACAATgB1 AG0AYgBlAHIAAAAAAEQAQ0ABABIBRAAMABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4AZABlAG4A dAAAABIAEQAPhHAIEYSs+V6EcAhghKz5AAAAAAAAPHIAAAQAAKwAAAAA/////wAAAAABAAAAAgAA AAMAAAA2AAAAXgAAAHUAAACcAAAAnQAAAJ4AAACxAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA 1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADz AAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAAAAkBAAAaAQAAGwEAABwB AAAsAQAAdQEAAKgBAACpAQAA8wEAAEUCAACTAgAA4QIAADEDAACKAwAA2wMAACsEAAB9BAAAkAQA AJEEAADeBAAAJgUAAHoFAADqBwAA6wcAAC4JAAAvCQAAJQoAAHkKAAAnCwAAiAsAANcLAAD0CwAA 9QsAAD4MAAB5DAAAegwAAA0NAABBDQAAQg0AAPQNAAARDgAAEg4AAC4OAAAvDgAAow8AAKQPAADE DwAAAxAAAC8QAABYEAAAjhAAANUQAAAWEQAAGBEAAG8RAAAaEgAAGxIAANsSAADcEgAAMhMAAH4T AACAEwAAnBMAAJ0TAACwFAAAshUAALMVAADnFQAABBYAAEwWAACNFgAA2BYAABIXAAAmFwAAORcA AHsXAAClFwAAphcAAO8XAAAYGAAAQRgAAG0YAACUGAAArxgAANEYAAAcGQAAZRkAALUZAAD2GQAA 9xkAAPgZAAA5GgAAcRoAAIsaAADDGgAAxBoAAPYaAAAuGwAAaBsAAKQbAADoGwAA6hsAADkcAACW HAAASR0AAIcdAACIHQAAnB0AAJ0dAAD3HQAAWR4AALEgAAASIQAAICEAAC4hAABAIQAATSEAAFwh AABdIQAAESIAACQiAABEIgAAZSIAAIAiAACaIgAAtSIAANIiAADtIgAACiMAACcjAABGIwAAYyMA AIAjAACCIwAAnyMAALwjAADbIwAA+CMAABckAAA1JAAAVCQAAFUkAABuJAAAiSQAAIokAAAzJQAA NCUAAEYlAABHJQAAWSUAAKMlAADzJQAASiYAAFEoAACiKAAA+ygAAFYpAACPKQAA2ykAAG0qAABv KgAAgCoAANEqAAAwKwAAQysAAFsrAAByKwAAhysAAKArAAC8KwAAzisAAOorAADxKwAACiwAAC0t AABHLQAAYy0AAH0tAACKLQAArC0AANgtAAATLgAATi4AAIouAAChLgAA0y4AANYuAACILwAAsC8A ALEvAABiMgAAYzIAALYyAAD+MgAAzzMAANAzAAAeNAAAbDQAALQ0AAC6NAAAuzQAAAw1AAAuNgAA fDYAAIc2AACINgAAczcAAHQ3AAC9NwAAAzgAAEo4AABLOAAAUDkAAFE5AACgOQAA5jkAACw6AABv OgAAsToAAPo6AAB2OwAAdzsAABg9AAAZPQAAYD0AAKE9AAAZPwAAGj8AAGM/AADwPwAA+0AAAPxA AABOQQAAIEIAAJNCAACUQgAAVkQAANBEAAAPRwAAMUgAAHNIAAB0SAAAu0gAAANJAABESQAAi0kA ANVJAAB1SgAAv0oAAANLAACXSwAA3ksAACpMAADATAAACk0AAFlNAACiTQAAo00AALdNAAC4TQAA 400AAORNAAAFTgAABk4AACROAAA0TgAANU4AAFFOAABjTgAAZE4AAIFOAACWTgAAl04AALVOAADU TgAA7E4AAO1OAAADTwAAIE8AACFPAABITwAAWE8AAFlPAACBTwAAlE8AAJVPAAC9TwAA208AANxP AAABUAAAJVAAACZQAABEUAAAXFAAAHBQAABxUAAAk1AAAK9QAACwUAAA2lAAAPdQAAD4UAAAGlEA AC5RAAAvUQAAWVEAAG1RAABuUQAAjlEAAKJRAACjUQAAxVEAANlRAADaUQAABVIAABlSAAAaUgAA PVIAAFNSAABUUgAAfVIAAJFSAACSUgAAu1IAANFSAADSUgAA41IAAORSAAD6UgAA+1IAABdTAAAY UwAAM1MAAEZTAABHUwAAYVMAAHRTAAB1UwAAjVMAAKFTAACjUwAANlQAAIFUAACsVAAArVQAALhU AADLVAAAF1UAABhVAAArVQAALFUAAD1VAAByVQAArVUAAOJVAAAGVgAACFYAABpWAABRVgAAi1YA AMBWAADmVgAA51YAAP9WAABAVwAAd1cAAJ1XAACeVwAAt1cAAPlXAAAwWAAAVlgAAFdYAABxWAAA plgAAOFYAAAfWQAAYVkAAJhZAAC+WQAAwFkAANtZAAARWgAAUVoAAI1aAADSWgAAA1sAAARbAAAx WwAAMlsAAEdbAABKWwAAaVsAAGxbAACIWwAAiVsAAKVbAACmWwAAxVsAAMZbAADYWwAA8FsAAPFb AAABXAAAF1wAABhcAAApXAAAQFwAAEFcAABUXAAAbVwAAH1cAAB+XAAAjFwAAI1cAACZXAAAmlwA ALpcAADRXAAA7FwAAAVdAAAGXQAAFV0AABZdAAAsXQAALV0AAEJdAABDXQAAfV0AAH5dAACPXQAA kF0AAKRdAAClXQAAul0AANJdAADTXQAA5F0AAPxdAAD9XQAAFV4AAC1eAAAuXgAAQl4AAF9eAABg XgAAcl4AAHNeAACLXgAAjF4AAKVeAACmXgAAvF4AAL1eAADXXgAA2F4AAPZeAAD3XgAAC18AAAxf AAAhXwAAIl8AAEhfAABJXwAAbl8AAG9fAACMXwAAtV8AAMxfAADNXwAA618AABBgAAARYAAAHWAA AB5gAABkYAAAoGAAAN9gAAAdYQAAWGEAAHFhAAByYQAAi2EAAIxhAADGYQAA72EAAA9iAAAvYgAA T2IAAG9iAACPYgAAr2IAANliAAAGYwAAJmMAAD9jAABgYwAAnGMAAMRjAADVYwAA5mMAAPdjAAD4 YwAAyWQAAMpkAABMZQAAl2UAAK5lAACvZQAA+mUAAJhmAACyZgAAs2YAAGtoAADmaAAA52gAACtp AAB6aQAAxmkAABBqAABaagAAnmoAAOVqAAAwawAAfWsAAKdrAACoawAA72sAABxsAAAdbAAAQWwA AGVsAACMbAAAtWwAAN9sAAABbQAAAm0AAE1tAACYbQAAyW0AAMttAADabQAA220AADxvAAA2cQAA N3EAAEhxAABJcQAAlXEAAO9xAADwcQAA8XEAAPRxAAD2cQAA93EAAPpxAAD7cQAA/HEAAP1xAAD+ cQAA/3EAAAByAAABcgAABXIAAAdyAAAIcgAACXIAAAtyAAAMcgAADnIAABFyAAATcgAAFXIAABpy AAAfcgAAIHIAACFyAAAscgAAOHIAADlyAAA9cgAACkAAAAEwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAAAAmEAAAAAwAAAAAAAAAIAAAAAACEAAAAEwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIAD AAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAA mEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAA AAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAw AAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAA AAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAmEAAAAAwAAAAAAAAAIADAAAAKEAAAAMwAAAAAAAA AIADAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAA AAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAA AAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAA AIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAA AAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAA AAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAA AIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAA AAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAA AAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAA AIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEADIAAwAAAAAAAAAIDcAAAAmEADIAAwAQAAAAAAAIDcAAAAmEAD IAAwAgAAAAAAAIDcAAAAmEADIAAwAwAAAAAAAIDcAAAAmEADIAAwBAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAA AAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAA AIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAA AAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAA AAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAA AIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDc AAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAA mEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAA AAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAw AAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIDcAAAAmEAEIAAwAAAA AAAAAIDcAAAAmEAEIAAwAQAAAAAAAIDcAAAAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA ABEwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACASEAA AAUwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAWEAAAAYwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAaEAAAAcwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAaEAAAAcwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAOEAAAAQw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAaEAAAAcwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAeEAAAAgw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmkAAAAAwAAAAAAAAAIAAAACA mEAAAA8wAAAAAAAAAIAAAACAmEAAAA8wAAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAABkAAAAZAAAAGQAAABwAAAAABAAA PHYAADwAAAAABAAA8AQAANsHAAAuEgAATBoAAC4fAAC1JgAAUSwAABMyAAB0OwAAk0YAALhRAAC9 UwAAxVUAAKFXAACdWwAAbF8AAAZhAACMYgAAZGQAAPdnAAAccAAA93UAADh2AAA8dgAAPQAAAD8A AABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAA AE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAAAQAADt2AAA+AAAAAAAAAAcAAAALAAAA EgAAABUAAAAcAAAAEyGVABMh1P+VgAAAAAB1AQAAfQEAAC0IAAA1CAAAjg0AAJcNAACgDQAAqQ0A AGsQAABwEAAArRAAALUQAACmJQAAqiUAAJ4qAACoKgAAeSsAAH0rAAB/LQAAgy0AAKMuAACqLgAA 5S8AAOYvAADqLwAAwTAAAMwwAABFMQAATzEAACczAAArMwAA6TMAAPQzAACrNQAArTUAALA1AAC7 NQAAvDUAAMA1AABBNgAARTYAAGk4AAByOAAAfTgAAHo5AAB+OQAALTwAADg8AABaPAAAZTwAANM8 AADXPAAApUEAAKlBAABkRwAAbEcAAMtLAADQSwAAdE0AAHhNAABeTgAAYk4AAIJOAACGTgAAVU8A AFdPAACCTwAAhE8AAFxQAABgUAAAl1AAAJtQAADeUAAA4lAAAClRAAAtUQAAaFEAAGxRAACdUQAA oVEAANRRAADYUQAAFFIAABhSAAAmUgAAKlIAAE5SAABSUgAAjFIAAJBSAADMUgAA0FIAACdTAAAr UwAAVlMAAFpTAAB5UwAAfVMAAHxUAACAVAAAnFQAAKBUAAABVQAABFUAAEJVAABGVQAAc1UAAHlV AADZVQAA3VUAAB9WAAAjVgAAUlYAAFhWAAC3VgAAu1YAAARXAAAIVwAAblcAAHJXAAC8VwAAwFcA ACdYAAArWAAAdlgAAHpYAACnWAAArVgAAA5ZAAASWQAAj1kAAJNZAADgWQAA5FkAAGJaAABmWgAA 1VoAANlaAAD7XAAA/1wAABBdAAAUXQAAyF4AAMxeAADjXgAA514AAI5hAACRYQAAoWYAAKRmAAC1 ZwAAuGcAAAlrAAAMawAA5GsAAO5rAAC2bAAAvWwAAOVsAADpbAAAKW0AADNtAACfbQAAom0AAOdw AADqcAAAIHIAACFyAAApcgAALHIAADdyAAA6cgAAPXIAAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcABwAcAAcA HAAHAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwACAAcABwAHAAcAAgAAAAAAdQAAAIQAAACWAAAAnAAA ALEAAACyAAAA0AAAAHUBAACnAQAAqAEAAEUCAABKAgAAkwIAAOECAADoAgAAMQMAADQDAABMAwAA 2wMAAPoDAAD/AwAAKgQAACsEAADeBAAAAwUAAAUFAAAmBQAAKwUAAHoFAADuBQAAgQYAAIkGAACZ BgAAswkAACMKAAAkCgAAJQoAACgKAAB5CgAA4AoAACMLAAAmCwAAJwsAAD4MAABBDAAAeQwAAA0N AABADQAAQQ0AAEINAADmDQAA7A0AAPQNAABvEQAAuhEAALwRAAAbEgAAQhIAAE0SAACGEgAAUxQA AGwUAAB4FAAAnRQAAEwWAAB1FgAAfBYAAI0WAAA5FwAAeRcAAHoXAAB8FwAAhBcAAKUXAADRGAAA 2xgAAPQYAAAcGQAAtRkAALYZAAC4GQAA9hkAAPgZAAAeGgAAHxoAADoaAAA9GgAAcRoAAKQbAAC0 GwAAvBsAAL8bAAA5HAAAVhwAAFgcAACdHQAAsh0AALMdAAD3HQAAPh4AAEAeAABZHgAAXR4AAPYe AAD/JAAAMiUAADMlAACjJQAA0SUAANclAADaJQAA8yUAAPQlAAD7JQAAMyYAAEomAABMJgAAyCYA ANYmAACyJwAAtCcAANAnAACiKAAApCgAAMgoAAD7KAAAAikAAFYpAABZKQAAkCkAANIpAADUKQAA 2ikAANspAADmKQAAGyoAAIAqAADKKgAA0CoAANEqAADTKgAA6SoAAM4rAADjKwAA6SsAAOorAAAT LgAAGC4AAB4uAAA6LgAATi4AAFMuAABVLgAAcC4AAIouAACPLgAAki4AAKEuAAAsLwAAbC8AAG4v AACILwAARjAAAEswAABSMAAA3jAAAFkxAAC2MQAAwzEAAA0yAAAWMgAAPDIAALYyAAC5MgAAuzIA AP4yAAACMwAAGjMAANAzAADpMwAA+jMAAB40AABsNAAAbjQAAHw0AAB+NAAADDUAABA1AAAXNQAA tDUAAC42AAA5NgAAfDYAAIY2AACHNgAAGjcAADQ3AAA5NwAASjcAAHQ3AACJNwAAljcAAL43AADB NwAA4TcAAAM4AAAEOAAACjgAADQ4AABJOAAASjgAAL85AADDOQAAxDkAAOY5AAAsOgAALToAADA6 AABqOgAAbzoAAHA6AAB2OgAAsToAABM8AABTPAAAWTwAAGg8AACSPAAAwjwAAMQ8AADGPAAAGT0A ACM9AAAvPQAAYD0AAN89AAABPgAACT4AAGA+AAAaPwAAVD8AAFs/AABkPwAA7z8AAPA/AAD8QAAA CEEAAA9BAABPQQAAV0EAAL1BAADGQQAA30EAADBCAABXQgAAZUIAAH5CAABWRAAAWEQAAFpEAACr RAAAr0QAANVEAADiRAAAeUUAAH9FAACCRQAAd0YAAINGAACORgAAqEYAAA9HAAAYRwAAM0cAADRH AACSRwAAMUgAADJIAAA5SAAAV0gAALtIAAC8SAAAv0gAANdIAAADSQAABEkAAApJAABFSQAAU0kA AFVJAACVSQAArEkAAK5JAADISQAA1UkAANZJAADZSQAAGkoAAANLAAAESwAACUsAAFVLAACXSwAA mEsAAJpLAADeSwAAF0wAAB9MAADMTAAA0UwAAAtNAAAOTQAAWk0AAGRNAAC9TwAAv08AAJRQAACW UAAAH1YAACdWAAAgWQAAIlkAAGJZAABkWQAAUVoAAFpaAACNWgAAkloAANJaAADUWgAAeF4AAIFe AACQXgAAml4AAKpfAACzXwAAZWAAAHZgAACgYAAAq2AAAMZgAADHYAAA32AAAORgAABYYQAAWmEA ABpkAAAiZAAA9GQAAPxkAABMZQAAcWUAAJhmAACcZgAAmmcAAKdnAADGaQAA92kAAFpqAABhagAA nmoAAL1qAADlagAAA2sAADBrAAA1awAAfWsAAIdrAABfbAAAZGwAAE1tAABQbQAAmG0AAJptAAA8 bwAASG8AAJVxAADscQAAIHIAACFyAAApcgAALHIAADdyAAA6cgAAPXIAAAcABwAzAAcABwAzAAcA BwAzAAcABwAzAAcABwAzAAcAMwAHAAcAMwAHADMABwAHADMABwAHADMABwAHAAcAMwAHAAcABwAz AAcAMwAHAAcABwAzAAcABwAzAAcABwAzAAcABwAHADMABwAHADMABwAHAAcAMwAHAAcABwAzAAcA BwAHADMABwAHAAcAMwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAzAAcABwAHADMABwAH ADMABwAHAAcAMwAHADMABwAHADMABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAzAAcAMwAHADMA BwAHADMABwAHADMABwAzAAcAMwAHADMABwAzAAcABwAHADMABwAzAAcABwAHADMABwAHAAcAMwAH AAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAzAAcABwAHADMABwAzAAcA BwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAzAAcAMwAHAAcABwAzAAcABwAHADMABwAzAAcABwAH ADMABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcA BwAHADMABwAHAAcAMwAHADMABwAHAAcAMwAHADMABwAzAAcABwAHADMABwAHAAcAMwAHADMABwAz AAcAMwAHAAcABwAzAAcABwAzAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHADMABwAHAAcA MwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAAgAHAAcABwAHAAIAAAAAAKZuAACpbgAAvm4AAMJuAADtbgAA8G4AABxvAACKbwAAIHIAACFy AAApcgAALHIAADdyAAA9cgAAAwAEAAMABAADAAQAAwAEAAMAAgAHAAIABwACAP//FAAAABYAUgBp AGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAgAEQA bwBjAHUAbQBlAG4AdABzAFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAgAEUAdQBn AGUAbgBlACAASABhAHIAdABuAGUAeQBIAEMAOgBcAFcASQBOAEQATwBXAFMAXABBAHAAcABsAGkA YwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1 AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARABPAEMAMQAuAGEAcwBkABYA UgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAg AEQAbwBjAHUAbQBlAG4AdABzAFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAgAEUA dQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABz AFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABhAHIA dABuAGUAeQAYAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwARABPAEMAMQAuAGQAbwBj ABYAUgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0A eQAgAEQAbwBjAHUAbQBlAG4AdABzAFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAg AEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4A dABzAFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABh AHIAdABuAGUAeQBIAEMAOgBcAFcASQBOAEQATwBXAFMAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4A IABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBv AHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARABPAEMAMQAuAGEAcwBkABYAUgBpAGMAaABhAHIA ZAAgAEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBl AG4AdABzAFwARABPAEMAMQAuAGQAbwBjABYAUgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAA SABhAHIAdABuAGUAeQAYAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwARABPAEMAMQAu AGQAbwBjAAcAZ1hqBR4DcGv/D/8P/w//D/8P/w//D/8P/w8QAIRH8gX8/sSz/w//D/8P/w//D/8P /w//D/8PEADiKLsT9FIeO/8P/w//D/8P/w//D/8P/w//DxAA6D7oNU5npn//D/8P/w//D/8P/w// D/8P/w8QADBE3DdiKSgQ/w//D/8P/w//D/8P/w//D/8PEAA3QLxZ4t8k5P8P/w//D/8P/w//D/8P /w//DxAAnU2VYbacXBL/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAAAAIAAAAAAAAAAAAAAAAAAAAA AAMYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5vKAADACgAAAApAAEAAAAEgAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4R4DxGETP8VxgUAAXgPBl6EeA9ghEz/AgACAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP4CAAQALgABAAAAAoIBAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4ToFxGETP8VxgUAAegXBl6E6BdghEz/AgAFAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/gIABgAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhIgdEYSY/hXGBQABiB0GXoSIHWCEmP4CAAcALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RYIBGETP8VxgUAAVggBl6EWCBghEz/AgAIAC4AAQAAAAAAAgAA AAAAAAAAAAAAAAAAAAAAAxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/m8oAAMAKAAAACkAAQAA AASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/gIAAQAuAAEA AAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKgMEYRM/xXGBQABqAwGXoSoDGCETP8CAAIALgAB AAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+AgADAC4A AQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/gIABAAu AAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBgVEYRM/xXGBQABGBUGXoQYFWCETP8CAAUA LgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+AgAG AC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/gIA BwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIgdEYRM/xXGBQABiB0GXoSIHWCETP8C AAgALgACAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+ bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRw CGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAG XoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbAT Bl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQAB UBkGXoRQGWCETP8CAAgALgAJAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUA AdACBl6E0AJghJj+bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM /xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RACxGE mP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EEA4R hJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQ EYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Sw ExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E gBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP hFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgAJAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAA D4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAA AAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAA AAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAA AAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgAJAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAAC4AAQAAAASAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIAB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASA AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAAC ggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgADAAAA AAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAAC4A AQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAu AAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIA LgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgAD AC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIA BAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8C AAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY /gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCE TP8CAAgALgAHAAAA4ii7EwAAAAAAAAAAAAAAAJ1NlWEAAAAAAAAAAAAAAACER/IFAAAAAAAAAAAA AAAAZ1hqBQAAAAAAAAAAAAAAAOg+6DUAAAAAAAAAAAAAAAA3QLxZAAAAAAAAAAAAAAAAMETcNwAA AAAAAAAAAAAAAP///////////////////////////////////////wcAAAAAAAAAAAAAAAAAAAAA AP//BwAAABIAyDeMFhkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgB4D04TGQAJBBsA CQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZ AAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsA CQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZ AAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkE/0ACEAAAAAAAAAA8 cgAAQAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAAAwAAAEcWkAEAAAICBgMFBAUCAwSHOgAAAAAAAAAAAAAA AAAA/wAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH OgAAAAAAAAAAAAAAAAAA/wAAAAAAAABBAHIAaQBhAGwAAAAiAAQAMQiIGADw0AIAAGgBAAAAAApB SEajWUim41hIplQAfAYAAIIQAAAbXgAAAQAwAAAABAADEMgAAAAAAAAAAAAAAAEAAQAAAAEAAAAA AAAAIQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAWgBbQAtACBgRIwAAAQABkAZAAA ABkAAACRcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAMoNRAPAQAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//8SAAAAAAAAADAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAARQBSAEkATgAgAEcAUgBFAEUATgBFACAAJgAgAEEAUwBTAE8AQwBJAEEAVABF AFMAAAAAAAAAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5ABYA UgBpAGMAaABhAHIAZAAgAEUAdQBnAGUAbgBlACAASABhAHIAdABuAGUAeQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAA AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAMgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADcAAAA BAAAAOgAAAAFAAAACAEAAAYAAAAUAQAABwAAACABAAAIAAAAMAEAAAkAAABQAQAAEgAAAFwBAAAK AAAAeAEAAAsAAACEAQAADAAAAJABAAANAAAAnAEAAA4AAACoAQAADwAAALABAAAQAAAAuAEAABMA AADAAQAAAgAAAOQEAAAeAAAAMQAAACAgICAgICAgICAgICAgICAgICAgICAgIEVSSU4gR1JFRU5F ICYgQVNTT0NJQVRFUwBlbmUeAAAAAQAAAAAgICAeAAAAFwAAAFJpY2hhcmQgRXVnZW5lIEhhcnRu ZXkAIB4AAAABAAAAAGljaB4AAAABAAAAAGljaB4AAAAHAAAATm9ybWFsACAeAAAAFwAAAFJpY2hh cmQgRXVnZW5lIEhhcnRuZXkAIB4AAAADAAAAODQAaB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4w AG5AAAAAAOg55ucAAABAAAAAAFJhCW8DwAFAAAAAAKTWbRgBwAFAAAAAAIquLogDwAEDAAAAAQAA AAMAAACCEAAAAwAAABteAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAAAwAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAlAAAAAYAAACcAAAA EQAAAKQAAAAXAAAArAAAAAsAAAC0AAAAEAAAALwAAAATAAAAxAAAABYAAADMAAAADQAAANQAAAAM AAAAEQEAAAIAAADkBAAAHgAAABkAAABFcmluIEdyZWVuZSAmIEFzc29jaWF0ZXMAACAAAwAAAMgA AAADAAAAMAAAAAMAAACRcwAAAwAAAKAKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AB4QAAABAAAAMQAAACAgICAgICAgICAgICAgICAgICAgICAgIEVSSU4gR1JFRU5FICYgQVNTT0NJ QVRFUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA GQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAn AAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUA AAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAA AEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAA UgAAAFMAAABUAAAAVQAAAFYAAAD+////WAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABg AAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4A AABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAA AH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAA/v///4kAAACKAAAA iwAAAIwAAACNAAAAjgAAAI8AAAD+////kQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAP7////9 /////f///5sAAAD+/////v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAAKD+n0aIA8ABnQAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXAAAAyGAAAAAAAABXAG8AcgBkAEQAbwBj AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAirAAAAAAA AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAiAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACQAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAA bwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAACg/p9GiAPAAaD+n0aIA8ABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdv cmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------=_NextPart_000_0005_01C0035E.6DFD4D60-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00319 for ; Tue, 15 Aug 2000 09:44:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:44:53 +0200 (MEST) Received: (qmail 4317 invoked by uid 0); 11 Aug 2000 16:00:53 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 11 Aug 2000 16:00:53 -0000 X-eGroups-Return: sentto-1101623-602-966009645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 11 Aug 2000 16:00:52 -0000 Received: (qmail 3543 invoked from network); 11 Aug 2000 16:00:44 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Aug 2000 16:00:44 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 11 Aug 2000 16:00:43 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA21474 for ; Fri, 11 Aug 2000 18:00:40 +0200 (MET DST) Message-ID: <3994231F.A014FDE8@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008110825.EAA04976@belegost.mit.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 18:00:31 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: acadb30a78940467c980f57e58d9b0ab Status: R X-Status: N hi !

graham@belegost.mit.edu wrote:
<snip>

if there is an existing ml at the opencollector, let's join it :-)
it would be silly to not benefit from Graham's efforts.
you can subscribe me there and i'll link the mailing list
>from the other sites.


while we're discussing it,
can anyone get the full text of the copyright laws ?
i wonder several things. for example, what is the status of
the f-cpu group, regarding the comyright law, if there is no
legal representation.

> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00322 for ; Tue, 15 Aug 2000 09:44:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:44:54 +0200 (MEST) Received: (qmail 3308 invoked by uid 0); 11 Aug 2000 16:10:54 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 11 Aug 2000 16:10:54 -0000 X-eGroups-Return: sentto-1101623-603-966010242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 11 Aug 2000 16:10:53 -0000 Received: (qmail 3459 invoked from network); 11 Aug 2000 16:10:41 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Aug 2000 16:10:41 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 11 Aug 2000 16:10:41 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA00021 for ; Fri, 11 Aug 2000 18:10:35 +0200 (MET DST) Message-ID: <39942572.57E26542@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008110825.EAA04976@belegost.mit.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 11 Aug 2000 18:10:26 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64745940a3356a4f31bd49d38f806bad Status: R X-Status: N ok i subscribed to the hardlicence mailing list.
anybody else comes ?

just send "subscribe hardlicense-discuss youremail"
to "majordomo@seul.org" and you're subbed after an authentication
confirmation.

see you there.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00460 for ; Tue, 15 Aug 2000 09:45:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:03 +0200 (MEST) Received: (qmail 5790 invoked by uid 0); 12 Aug 2000 07:59:11 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 12 Aug 2000 07:59:11 -0000 X-eGroups-Return: sentto-1101623-604-966067148-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 12 Aug 2000 07:59:12 -0000 Received: (qmail 9314 invoked from network); 12 Aug 2000 07:59:08 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 12 Aug 2000 07:59:08 -0000 Received: from unknown (HELO perex-ext.sk) (195.168.41.130) by mta1 with SMTP; 12 Aug 2000 07:59:07 -0000 Received: from jckhjubkl ([38.33.103.214]) by perex-comm.perex-ext.sk with SMTP id <119140>; Sat, 12 Aug 2000 09:55:36 +0200 To: doimele98@envir.ee Comments: Authenticated sender is Message-Id: <200008123303AAA52878@hygbvfcd3s.perex.sk> X-eGroups-From: doimele98@envir.ee (Edward) From: doimele98@envir.ee MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 12 Aug 2000 09:52:03 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Investigate Anyone Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dec6237a251b139efbdffd0f6b066445 Status: R X-Status: N
          Cyber Investigator
"EASY WAY TO FIND OUT ANYTHING ABOUT ANYONE"


Cyber Investigator TAKES YOU BEYOND WHAT SEARCH ENGINES CAN DO!

Cyber Investigator is an amazing new tool that allows you to find EVERYTHING
you ever wanted to know about your EMPLOYEES, FRIENDS, RELATIVES, SPOUSE,
NEIGHBORS, even your BOSS!

You can check out ANYONE, ANYTIME, ANYWHERE, right on the internet...

Here's the best part: With our SECURE ORDER SYSTEM
you can have this amazing tool in your hands right away and you
can be doing your own on-line investigations IMMEDIATELY.

To find out more about what Cyber Investigator can do for YOU!

CLICK HERE

http://3463729345/55280.html



Rem send email to simon4065@excite.com




675809822552699476
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00508 for ; Tue, 15 Aug 2000 09:45:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:14 +0200 (MEST) Received: (qmail 14458 invoked by uid 0); 12 Aug 2000 12:41:59 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 12 Aug 2000 12:41:59 -0000 X-eGroups-Return: sentto-1101623-605-966084115-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 12 Aug 2000 12:41:55 -0000 Received: (qmail 8114 invoked from network); 12 Aug 2000 12:41:55 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 12 Aug 2000 12:41:55 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 12 Aug 2000 12:41:54 -0000 Received: from 0018728164 (host-208-60-244-2.bix.bellsouth.net [208.60.244.2]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id IAA06728; Sat, 12 Aug 2000 08:41:52 -0400 (EDT) Message-ID: <000801c0045a$a73af300$02f43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 12 Aug 2000 07:41:34 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Update of System Overview Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C00430.BD585D00" X-UIDL: 657778a3ce8b9321158dd3d6f8a8a3cd Status: R X-Status: N ------=_NextPart_000_0005_01C00430.BD585D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More info added for completness - 20 pages. A later update will remove sen= timentality from the WADE description and describe as SHFT. All references= to Logic errors have been removed (fixed). You will all have basically th= e same data as Yann Guidon with the exception of two Appendices. One is t= en page or so article on JOSS and a 15 page document of a typical Hospital = Application. All other info he has is - GARBAGE. Have a good day.=20 Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C00430.BD585D00 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
More info added for completness - 20 pages.  A later update will remove sentimentality from the WADE description and describe as SHFT.  All references to Logic errors have been removed (fixed).  You will all have basically the same data as Yann Guidon with the exception of two Appendices.   One is ten page or so article on JOSS and a 15 page document of a typical Hospital Application.  All other info he has is - GARBAGE.  Have a good day.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
 
------=_NextPart_000_0005_01C00430.BD585D00-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00511 for ; Tue, 15 Aug 2000 09:45:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:16 +0200 (MEST) Received: (qmail 32692 invoked by uid 0); 12 Aug 2000 12:44:29 -0000 Received: from c9.egroups.com (208.50.99.230) by mx11.rz2.gmx.net with SMTP; 12 Aug 2000 12:44:29 -0000 X-eGroups-Return: sentto-1101623-606-966084258-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 12 Aug 2000 12:44:20 -0000 Received: (qmail 4815 invoked from network); 12 Aug 2000 12:44:17 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Aug 2000 12:44:17 -0000 Received: from unknown (HELO mail0.lig) (205.152.0.90) by mta1 with SMTP; 12 Aug 2000 12:44:17 -0000 Received: from 0018728164 (host-209-214-154-17.bix.bellsouth.net [209.214.154.17]) by mail0.lig (3.3.5alt/0.75.2) with SMTP id IAA15577; Sat, 12 Aug 2000 08:43:53 -0400 (EDT) Message-ID: <000901c0045a$eef56040$119ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 12 Aug 2000 07:43:00 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN GREENE & ASSOCIATES Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C00430.F05AD5C0" X-UIDL: cfc257667391b4ec346df51633b8e861 Status: R X-Status: N ------=_NextPart_000_0005_01C00430.F05AD5C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C00430.F05AD5C0" ------=_NextPart_001_0006_01C00430.F05AD5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0006_01C00430.F05AD5C0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
 
------=_NextPart_001_0006_01C00430.F05AD5C0-- ------=_NextPart_000_0005_01C00430.F05AD5C0 Content-Type: application/msword; name="DOC1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DOC1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAsgAAAAAAAAAA EAAAtAAAAAEAAAD+////AAAAALAAAACxAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA84cAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIsQAADd8AAA3fAAA2IMAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAB4DAAAAAAAAHgMAAB4D AAAAAAAAHgMAAAAAAAAeAwAAAAAAAB4DAAAAAAAAHgMAABQAAAAAAAAAAAAAADIDAAAAAAAAbD4A AAAAAABsPgAAAAAAAGw+AAA4AAAApD4AAAwAAACwPgAA3AAAADIDAAAAAAAA9HQAALYAAACYPwAA AAAAAJg/AAAiAAAAuj8AAAAAAAC6PwAAAAAAALo/AAAAAAAAuj8AAAAAAAC6PwAAAAAAALo/AAAA AAAAl3QAAAIAAACZdAAAAAAAAJl0AAAAAAAAmXQAAAAAAACZdAAAAAAAAJl0AAAAAAAAmXQAAAAA AACqdQAAIAIAAMp3AADiAAAAmXQAABUAAAAAAAAAAAAAAAAAAAAAAAAAHgMAAAAAAAC6PwAAAAAA AAAAAAAAAAAAAAAAAAAAAAC6PwAAAAAAALo/AAAAAAAAuj8AAAAAAAC6PwAAAAAAAJl0AAAAAAAA Ck0AAAAAAAAeAwAAAAAAAB4DAAAAAAAAuj8AAAAAAAAAAAAAAAAAALo/AAAAAAAArnQAABYAAAAK TQAAAAAAAApNAAAAAAAACk0AAAAAAAC6PwAA5AQAAB4DAAAAAAAAuj8AAAAAAAAeAwAAAAAAALo/ AAAAAAAAl3QAAAAAAAAAAAAAAAAAAApNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAuj8AAAAAAACXdAAAAAAAAApNAADmBAAACk0AAAAAAADwUQAA igEAAIdxAAAcAQAAHgMAAAAAAAAeAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAl3QAAAAAAAC6PwAAAAAAAIw/AAAMAAAAIDdZxVoE wAEyAwAAOjsAAGw+AAAAAAAAnkQAAAgIAACjcgAAIgAAAAAAAAAAAAAAl3QAAAAAAADEdAAAMAAA APR0AAAAAAAAxXIAANIBAACseAAAAAAAAKZMAABkAAAArHgAAAAAAACXdAAAAAAAAApNAAAAAAAA MgMAAAAAAAAyAwAAAAAAAB4DAAAAAAAAHgMAAAAAAAAeAwAAAAAAAB4DAAAAAAAAAgDZAAAADQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICBFUklOIEdSRUVORSAmIEFTU09DSUFURVMNQnVzaW5l c3MgSW5mb3JtYXRpb24gTWFuYWdlbWVudCBTeXN0ZW1zDTI2MTMgTm9ydGggMTF0aCBTdHJlZXQN T2NlYW4gU3ByaW5ncywgTWlzc2lzc2lwcGkgIDM5NTY0LTgzNjQNDQ1QaG9uZSAyMjgtODc1LTYw MDMNZS1tYWlsICByaGFydG5leUBiZWxsc291dGgubmV0DQ0NDQ0NDQ0NDQ0NDVNZU1RFTSBPVkVS VklFVw0NDQ0NDQ0NDQ0NDQ0NDQ0NDUFVR1VTVCAyMDAwDQxTWVNURU0gT1ZFUlZJRVcNDQ0xLiAg VEhFIFBST0RVQ1QNCVRoZSBvYmplY3RpdmUgaXMgdG8gcHJvZHVjZSBhIGxvdyBjb3N0LCBoaWdo IHBlcmZvcm1hbmNlLCB1c2VyIG9wZXJhdGVkDUxpZ2h0cGVuL01vdXNlLWNvbnRyb2xsZWQgRGlz cGxheSBUZXJtaW5hbCBTeXN0ZW0uDQ0JVGhlIHJlc3VsdGluZyBzeXN0ZW0gbWF5IGJlIHVzZWQg aW4gdmlydHVhbGx5IGFueSBDb21tZXJjaWFsIFNtYWxsL0xhcmdlIEJ1c2luZXNzIEFwcGxpY2F0 aW9uIGluY2x1ZGluZyBidXQgbm90IGxpbWl0ZWQgdG8gRmVkZXJhbC9TdGF0ZS9Mb2NhbCBHb3Zl cm5tZW50LCB3aGVyZSBwcmVzZW50IGRheSB1c2FnZQ1pcyB0aGUgUGVyc29uYWwgQ29tcHV0ZXIg KFBDKSB3aXRoIG9yIHdpdGhvdXQgTmV0d29yayBTZXJ2ZXIgSGFyZHdhcmUvU29mdHdhcmUuICBT aW1wbHkgZGlzY2FyZCB0aGUgVG93ZXIvU2VydmVyIHdpdGggd2hhdGV2ZXIgdGhleSBjb250YWlu OyByZXRhaW4gdGhlIHJlbWFpbmluZyBkZXZpY2VzOyBhbmQgcGx1ZyBpbiB0aGUgIG5ldyBQcm9j ZXNzaW5nIEhhcmR3YXJlIGFuZCBBcHBsaWNhdGlvbiBQcm9ncmFtcy4gIFRoaXMgc3lzdGVtIGlz IG9wZW4tZW5kZWQgdG8gYWxsIHR5cGVzIG9mIFBlcmlwaGVyYWwgZGV2aWNlcy4NQSB0eXBpY2Fs IGFwcGxpY2F0aW9uIGNvdWxkIGJlIEFMTCBEZXBhcnRtZW50cyBhbmQgQUxMIGFzc29jaWF0ZWQg ZnVuY3Rpb25zIGluIGEgSG9zcGl0YWwgb3IgR1JPVVAgb2YgSG9zcGl0YWxzLiAgT3IgaXQgY291 bGQgYmUgdXNlZCBieSBOQVNBIGFzIHByZS9wb3N0IGxhdW5jaCBTeXN0ZW1zIE1vbml0b3IgYW5k IFJlbW90ZSBDb250cm9sIFN5c3RlbS4gIElmIHlvdSBhc2sgdGhlIHF1ZXN0aW9uIJYgQ0FOIElU IERPPyCWIFRoZSBhbnN3ZXIgaXMgWUVTLg0NCVRoZSBzeXN0ZW0gaXMgcHJvZ3JhbW1lZCBpbiBh IGxhbmd1YWdlIGNhbGxlZCBUSVBTLiAgVElQUyBpcyBhbiBhY3JvbnltIGZvciBUT1RBTCBJTkZP Uk1BVElPTiBQUk9HUkFNTUlORyBTWVNURU0uICBUSVBTIGlzIGFuIGludGVycHJldGl2ZSBsYW5n dWFnZSB3aGljaCBwcm92aWRlcyB0aGUgQXBwbGljYXRpb24gUHJvZ3JhbW1lciB3aXRoIHRoZSBj YXBhYmlsaXRpZXMgdG8gQ29sbGVjdCwgU3RvcmUsIE1hbmlwdWxhdGUsIFN0cnVjdHVyZSBhbmQg UmV0cmlldmUgYmxvY2tzIG9mIGRhdGEuICBUaGUgbGFuZ3VhZ2UgaXMgdGhlcmVmb3JlIEZJTEUs IEZPUk0sIFBBR0UsIGFuZCBQQVJUIG9yaWVudGVkLiAgVElQUyBoYXMgYmVlbiBzcGVjaWZpY2Fs bHkgZGVzaWduZWQgdG8gZnVuY3Rpb24gaW4gYSBNdWx0aS11c2VyLCBNdWx0aS1wb3J0IGVudmly b25tZW50ICYgb2NjdXBpZXMgb25seSA4MCwwMDAgYnl0ZXMgb2YgTWVtb3J5IJYgbW9yZSBzcGVj aWZpY2FsbHkgliAgOSw5NjcgSW5zdHJ1Y3Rpb25zLiAgVGhlIEFwcGxpY2F0aW9uIFByb2dyYW1t ZXIgbWF5IGNyZWF0ZSBGb3JtcyBhdCBhbnkgVXNlciBTdGF0aW9uOyBlbnRlciByZWxhdGVkIFBy b2dyYW1zOyBUZXN0IGFuZCBNb2RpZnkgYXMgbmVlZGVkLCBiZWZvcmUgb3IgYWZ0ZXIgdGhlIHN5 c3RlbSBpcyBPbi1MaW5lLiAgVGhlc2UgZmVhdHVyZXMgYXJlIG5vdCBpbmhlcmVudCBpbiBwcmVz ZW50IGRheSBQQ5JzLiAgVGhlIHN5c3RlbSBpcyBkZXNpZ25lZCB0byBhY2NvbW1vZGF0ZSBmcm9t IDEgdG8gMTI4IFVzZXIgU3RhdGlvbnMuICBBIHBhcmFsbGVsIGV4cGFuc2lvbiBwb3J0IGlzIHBy b3ZpZGVkIGZvciCTTpQgc3ViLXN5c3RlbXMuDQ0JVGhlIFVTRVIgU1RBVElPTiBjb25zaXN0cyBv ZiBhIENSVC9GbGF0IFBhbmVsIE1vbml0b3IsIEtleWJvYXJkLCBMaWdodHBlbi9Nb3VzZSwgUHJp bnRlciwgSUQgUmVhZGVyLCBhbmQgYSBzbWFsbCBhc3NlbWJseSBjb250YWluaW5nIEludGVyZmFj ZSBMb2dpYy4gIFRoZSBhc3NlbWJseSBhbHNvIHByb3ZpZGVzIGNvbm5lY3RvcnMgZm9yIHRoZSBs b2NhbCBjb21wb25lbnRzIGFuZCBvbmUgY29ubmVjdGlvbiB0byBhIHJlbW90ZSBDb21wdXRlciBB c3NlbWJseS4gIEEgc3RhdGlvbiBtYXkgaW5jbHVkZS9leGNsdWRlIHRoZSBQcmludGVyIGFuZCBJ RCBSZWFkZXIuDQ0JVGhlIHJlbW90ZSBDT01QVVRFUiBBU1NFTUJMWSBjYW4gYWNjb21tb2RhdGUg dXAgdG8gMTI4IFVzZXIgU3RhdGlvbnMgd2l0aG91dCBub3RpY2VhYmxlIGRlZ3JhZGF0aW9uIGlu IHJlc3BvbnNlIHRvIHVzZXIgcmVxdWVzdHMuICBUaGUgbW91bnRpbmcgcmFjayBjb250YWlucyBh IExhbmd1YWdlIFByb2Nlc3NvciB3aXRoIHJlcXVpcmVkIFNSQU0gTWVtb3J5IHJlc291cmNlcyBh bmQgSW5wdXQvT3V0cHV0IENvbnRyb2xsZXJzOyBhbmQgYSBQZXJpcGhlcmFsIFByb2Nlc3NvciB3 aXRoIGl0cyByZXF1aXJlZCBTUkFNIE1lbW9yeSByZXNvdXJjZXMgYW5kIElucHV0L091dHB1dCBD b250cm9sbGVycy4gIFRoZSB0d28gcHJvY2Vzc29ycyBhcmUgaWRlbnRpY2FsIEVSSU4zMiBGUEdB IGRldmljZXMgaGF2aW5nIGlkZW50aWNhbCBJbnN0cnVjdGlvbiBTZXRzLiAgQWxzbyBwcm92aWRl ZCBpcyB0aGUgbmVjZXNzYXJ5IFBvd2VyIFN1cHBseSwgQ29vbGluZyBGYW4gQXNzZW1ibHksIEVN SSBMaW5lIEZpbHRlcnMsIGFuZCBjb25uZWN0b3JzIGZvciBzaGllbGRlZCB0d2lzdGVkIHBhaXIg Y2FibGluZyBvZiBEaWZmZXJlbnRpYWwgRHJpdmVyL1JlY2VpdmVycy4gRmliZXIgT3B0aWNzIG1h eSBiZSB1c2VkIHdoZXJlIGRpc3RhbmNlIGlzIGEgZmFjdG9yIChjb3N0IG11c3QgYmUgY29uc2lk ZXJlZCkuDQwyLiAgSElTVE9SWSBPRiBUSEUgTEFOR1VBR0UNDVRoZSBsYW5ndWFnZSBvZiBUSVBT IGlzIGJhc2VkIHVwb24gSk9TUyAoSk9ITk5JQUMgT3Blbi1TaG9wIFN5c3RlbSkgd2hpY2gNd2Fz IGRldmVsb3BlZCBieSB0aGUgUmFuZCBDb3Jwb3JhdGlvbiBpbiB0aGUgZWFybHkgMTk2MJJzLg0N Tm90ZTogIFJlZmVyIHRvOiBKT1NTOiBBIERFU0lHTkVSklMgVklFVyBPRiBBTiBFWFBFUklNRU5U QUwgT04tTElORSBDT01QVVRFUiBTWVNURU0gQlkgSi5DLiBTaGF3IG9mIHRoZSBSYW5kIENvcnBv cmF0aW9uLCBTYW50YSBNb25pY2EsIENhbGlmb3JuaWENUFJPQ0VFRElOR1MgliBGQUxMIEpPSU5U IENPTVBVVEVSIENPTkZFUkVOQ0UsIDE5NjQuDQ0JT3RoZXIgZWZmb3J0IGluIHNpbWlsYXIgZGV2 ZWxvcG1lbnRzIHdlcmUgdW5kZXJ0YWtlbiBieSB0aGUgVW5pdmVyc2l0eSBvZiBQaXR0c2J1cmcg KFBJTCkgliBQaXR0c2J1cmcgSW50ZXJwcmV0aXZlIExhbmd1YWdlIGFuZCBTYW5kZXJzIEFzc29j aWF0ZXMgSW5jb3Jwb3JhdGVkIChGT1BTKSCWIEZpbGUgT3JpZW50ZWQgUHJvZ3JhbW1pbmcgU3lz dGVtLg0NMy4gIE9MRCBTWVNURU0gQVJDSElURUNUVVJFDQ0JVGhlIFNhbmRlcnMgZWZmb3J0IHdh cyBzdGFydGVkIGluIDE5NjUgYW5kIHRlcm1pbmF0ZWQgaW4gMTk3Mi4gVGhlIHN5c3RlbSB1c2Vk IHR3byBIb25leXdlbGwgbWluaWNvbXB1dGVycywgYSBERFAtNTE2IGFuZCBhIEREUC00MTYuICBU aGUgNDE2IGhhZCBhIHJlZHVjZWQgaW5zdHJ1Y3Rpb24gc2V0IGFuZCBidXQgb3RoZXJ3aXNlIGlk ZW50aWNhbCB0byB0aGUgNTE2LiAgVGhlIHRvdGFsIHN5c3RlbSB3YXMgc3RhdGUtb2YtdGhlIGFy dCBhdCB0aGUgdGltZS4gIE11Y2ggZWZmb3J0IHdhcyBkb25lIGluIG1hcmtldGluZyCWIHRvbyBu byBhdmFpbCCWIGR1ZSB0byBjb3N0IJYgYW5kIHRoZSBlbnRpcmUgRGVwYXJ0bWVudCB3YXMgZGlz YmFuZGVkLg0NCQlTeXN0ZW0gZGVmaWNpZW5jaWVzIGluY2x1ZGVkOg1JbmFkZXF1YXRlIENvcmUg TWVtb3J5IGZvciB0aGUgTGFuZ3VhZ2UgUHJvY2Vzc29yICYgdGhlcmVmb3JlOg1Vc2VyIFNsb3Rz IGxpbWl0ZWQgdG8gZm91ciAoNCkgJiB0aGVyZWZvcmU6DURpc2sgc3dhcHBpbmcgd2FzIG5lY2Vz c2FyeSAmIHRoZXJlZm9yZToNRGlzayBhY2Nlc3Mgd2FzIDkwIG1pbGxpLXNlY29uZHMgYXZlcmFn ZSAmIHRoZXJlZm9yZToNU2l4ICg2KSBvciBtb3JlIFVzZXJzIG9mIHJhcGlkIExpZ2h0cGVuIHN0 cmlrZXMgcmVzdWx0ZWQgaW4gbm90aWNlYWJsZQ1TbG93aW5nIGluIHJlc3BvbnNlIHRpbWUuICBL ZXlib2FyZCBpbnB1dHMgd2VyZSBuZXZlciBhIHByb2JsZW0uDQkNVGhlIHNpeHRlZW4gKDE2KSBi aXQgY29tcHV0ZXIgaGFkIGxpbWl0ZWQgYWRkcmVzc2luZyBjYXBhYmlsaXR5IGFuZCBmb3JjZWQg SW5kaXJlY3Qgb3INSW5kZXhlZCBBZGRyZXNzaW5nIGZvciBNZW1vcnkgUmVmZXJlbmNlIEluc3Ry dWN0aW9ucyBpbiB0b28gbWFueSBpbnN0YW5jZXMuICBQcmlvciB0byBiZWluZyBkaXNiYW5kZWQs IGFuIGVmZm9ydCBpbiByZWRlc2lnbiBvZiB0aGUgRERQLTUxNiB3YXMgcHVyc3VlZCBidXQgbm90 IGNvbXBsZXRlZC4NDQlEaXNrIHN0b3JhZ2Ugd2FzIGxpbWl0ZWQgdG8gZWlnaHQgKDgpIHVuaXRz IHdoaWNoIHByb3ZpZGVkIDYuNCBNYnl0ZXMgZm9yIEFwcGxpY2F0aW9uIFByb2dyYW1zIGFuZCBE YXRhLiAgQSBkaXNrIFNlY3RvciBjb250YWluZWQgMzIgMTYtQml0IFdvcmRzLCBpbmNsdWRpbmcg b3ZlcmhlYWQgKHBvaW50ZXJzLCBkZXNjcmlwdG9ycykuDQ0JVGhlIENSVCBNb25pdG9ycyB3ZXJl IHBoeXNpY2FsbHkgcGFnZS1vcmllbnRlZCBjYXBhYmxlIG9mIGRpc3BsYXlpbmcgMTAxOSBjaGFy YWN0ZXJzDWluY2x1ZGluZyBmb3JtYXQgdHlwZXMuICBBIJNSYWNldHJhY2uUIGNoYXJhY3RlciBn ZW5lcmF0b3Igd2FzIHVzZWQuICBBbGwgY2FibGluZyB3YXMgZGlyZWN0IHR3aXN0ZWQgcGFpci1w YXJhbGxlbCBkYXRhLg0MDTQuICBORVcgU1lTVEVNIEFSQ0hJVEVDVFVSRQ0NCVRoaXMgZGVzaWdu IGlzIHNpbWlsYXIgdG8gaXRzIHByZWRlY2Vzc29yIHdpdGggdHdvIG1ham9yIGV4Y2VwdGlvbnMu ICBUaGUgdHdvIHByb2Nlc3NvcnMgYXJlIGlkZW50aWNhbCBGUEdBIGRldmljZXMgd2l0aCBzaW1p bGFyIElTQSAoSW5zdHJ1Y3Rpb24gU2V0IEFyY2hpdGVjdHVyZSkgYXMgdGhlIEREUC01MTYuICBU aGlzIGRlc2lnbiBjZWFzZWQgYmVpbmcgYW4gRW11bGF0aW9uIHdoZW4gMzIgQml0IERhdGEgd2Fz IGluY29ycG9yYXRlZC4gIFNldmVyYWwgbm9uLXVzYWJsZSBJbnN0cnVjdGlvbnMgd2VyZSBkaXNj YXJkZWQgYW5kIHNldmVyYWwgaW5zdHJ1Y3Rpb25zIHdlcmUgYWRkZWQuICBUaGUgcHVycG9zZSBp biByZXRhaW5pbmcgdGhlIElTQSBpcyB0byBtaW5pbWl6ZSBjaGFuZ2VzIHRvIGNhcHR1cmUgRVhJ U1RJTkcgU09GVFdBUkUuICBUaGUgb3RoZXIgbWFqb3IgZGlmZmVyZW5jZSBpcyB0aGUgdXNlIG9m IFNTUkFNIGluIGxpZXUgb2YgRGlzayBmb3IgQXBwbGljYXRpb24gUHJvZ3JhbXMgYW5kIERhdGEg U3RvcmFnZQ0NVGhlIHByb2Nlc3NvcihzKSBQcm9ncmFtIE1lbW9yeSBpcyBGb3VyLVBvcnQgd2hl cmU6DQlQb3J0IDEgPSBJbnN0cnVjdGlvbiBTb3VyY2UNCVBvcnQgMiA9IFZlY3RvciAoSk1QLCBK U1QgKENBTEwpLCBKTVBJIChSVE4pLCBCUkFOQ0gsIEludGVycnVwdCAoQ0FMTCkNCQkgIFRoaXMg UG9ydCB1c2VzIHRoZSBBZGRyZXNzIFJlYWQtYmFjayBvZiAgdGhlIG9uLWNoaXAgUHJvZ3JhbQ0J CSAgQ291bnRlciBhbHNvIGhhdmluZyBlaXRoZXIgTG9hZCAoVmVjdG9yKSBvciBJbmNyZW1lbnQg KFBDKzEpIGZlYXR1cmVzLg0JCSAgQU5EIEluc3RydWN0aW9uIExvb2stQWhlYWQgZm9yIHRoZSBh Ym92ZSBJbnN0cnVjdGlvbnMNCVBvcnQgMyA9IEJvb3QgTG9hZA0JUG9ydCA0ID0gUmVzZXJ2ZWQN CVRoZXJlIGFyZSB0aHJlZSAoMykgU0lNTS9ESU1NIHBhY2thZ2VzLCBlYWNoIHByb3ZpZGluZyA2 NEsgWCAzNjsNCXlpZWxkaW5nIGFuIDEwOCBCaXQgTWljcm8gSW5zdHJ1Y3Rpb24uICANDVRoZSBw cm9jZXNzb3IocykgTG9jYWwgTWVtb3J5IChIYXJ2YXJkIEFyY2hpdGVjdHVyZSkgaXMgRm91ci1Q b3J0IHdoZXJlOg0JUG9ydCAxID0gUmVhZCBPbmx5IChPcGVyYW5kIExvb2stQWhlYWQpDQlQb3J0 IDIgPSBSZWFkIE9ubHkgKE9wZXJhbmQgTG9vay1haGVhZCkNCVBvcnQgMyA9IFdyaXRlIE9ubHks IFNoYXJlZCB3aXRoIEJvb3QgTG9hZA0JUG9ydCA0ID0gRkJDIChGdWxseSBCdWZmZXJlZCBDaGFu bmVsKQ0JCSBGcm9tL1RvIEdsb2JhbCBNZW1vcnkgJg0JCSBGcm9tL1RvIEFzc29jaWF0ZWQgUGVy aXBoZXJhbHMNCUxhbmd1YWdlIHByb2Nlc3NvciBQZXJpcGhlcmFscyBhcmUgQ0lDVSAoQ29uc29s ZSBJbnB1dCBDb250cm9sIFVuaXQpLCBDUlQNCVJlZnJlc2ggTWVtb3J5LCBNdWx0aXBseS9EaXZp ZGUvU3F1YXJlIFJvb3QgJiBGbG9hdGluZyBQb2ludC4gV2hlcmUgdGhlDQlQZXJpcGhlcmFsIHBy b2Nlc3NvciBzZXJ2aWNlcyB1cCB0byAxMjggUHJpbnRlcnMsIFJlYWwgVGltZSBDbG9jaywgRmF4 LCBNb2RlbSwNdXAgdG8gMTI4IFBhZ2UgU2Nhbm5lcnMsIElvbWVnYSBEaXNrLCBhbmQgdXAgdG8g k06UIEhhcmQgRGlza3MuIFRoZXJlIGFyZSBmb3VyICg0KSBTSU1NL0RJTU0gcGFja2FnZXM7IGVh Y2ggcHJvdmlkaW5nIDY0SyBYIDM2IGFuZCBpcyBhbGxvY2F0ZWQgZm9yIGVhY2ggb2YgdGhlIDEy OCBVU0VSUyBhcyBmb2xsb3dzOg00SyBCeXRlcyCWIERpc3BsYXkgTWVtb3J5DTEySyBCeXRlcyCW IEFwcGxpY2F0aW9uIFByb2dyYW0gYW5kIExvY2FsIE0yTSBSZWdpc3RlcnMNDVRoZSBwcm9jZXNz b3IocykgR2xvYmFsIE1lbW9yeSBpcyBUd28tUG9ydCB3aGVyZToNCVBvcnQgMSA9IEZCQyAgIEZy b20vVG8gTGFuZ3VhZ2UgUHJvY2Vzc29yIExvY2FsIE1lbW9yeQ0JUG9ydCAyID0gRkJDICAgRnJv bS9UbyBQZXJpcGhlcmFsIFByb2Nlc3NvciBMb2NhbCBNZW1vcnkNU3lzdGVtIFByb2dyYW1tZXJz IHdpbGwgYWxsb2NhdGUgYW4gYXJlYSBvZiB0aGlzIG1lbW9yeSBmb3IgYW4NSW50ZXItcHJvY2Vz c29yIG1haWwtYm94LiAgQW4gaW50ZXItcHJvY2Vzc29yIEludGVycnVwdCBpcyBwcm92aWRlZC4N DA1DUlQgTW9uaXRvci9GbGF0IFBhbmVsIERpc3BsYXkgliBUaGUgbW9uaXRvciBpcyBjYXBhYmxl IG9mIGRpc3BsYXlpbmcgdXAgdG8gMjA0OCBjaGFyYWN0ZXJzIG9yZ2FuaXplZCA4MCBjaGFyYWN0 ZXJzIHBlciBsaW5lIGFuZCB1cCB0byAyNS42IGxpbmVzIGluIGEgVGFidWxhciBmYXNoaW9uLiAg VGhlIFRhYnVsYXIgZGlzcGxheSBvZiBjaGFyYWN0ZXJzIGlzIG5lY2Vzc2FyeSBmb3IgTGlnaHRw ZW4vTW91c2Ugb3BlcmF0aW9uIHN1Y2ggdGhhdCBlYWNoIFZpZGVvIG9jY3VyYW5jZSBpcyBkaXJl Y3RseSByZWxhdGVkIHRvIGEgcmVmcmVzaCBtZW1vcnkgYWRkcmVzcy4gIEEgY29tcGxldGUgcGFn ZSBvZiBkYXRhIGlzIGxpbWl0ZWQgdG8gNDA5NiBDaGFyYWN0ZXJzLHdoZXJlIHNjcm9sbGluZyBt dXN0IGJlIHVzZWQgZm9yIGNvbXBsZXRlIHZpc2FiaWxpdHkuDQ0NVGhlIENSVCBNdWx0aXBsZXhl ciBmdW5jdGlvbiBpcyB0byBhZGRyZXNzIHRoZSBSZWZyZXNoIE1lbW9yeSB3aG9zZSBBU0NJSSBv dXRwdXQgaXMgYXBwbGllZCB0byB0aGUgYXBwcm9wcmlhdGUgQ2hhcmFjdGVyIEdlbmVyYXRvciAo Q0cpLiAgVGhlIENoYXJhY3RlciBHZW5lcmF0b3IgaXMgdGltZS1zaGFyZWQgYmV0d2VlbiBlaWdo dCAoOCkgQ1JUIE1vbml0b3JzLiAgVGhlIENSVCBNdXggYWxzbyBjb250YWlucyB0aGUgbmVjZXNz YXJ5IHRpbWluZyBmb3IgYWRkcmVzc2luZyB0aGUgQ0eScyB3aG9zZSBvdXRwdXQgaXMgZWZmZWN0 aXZlbHkgYSA3IHggOSBwaXhlbCBtYXRyaXggd2hpY2ggaXMgdHJhbnNtaXR0ZWQgc2VyaWFsbHkg dmlhIERpZmZlcmVudGlhbCBMaW5lIERyaXZlcnMgaWYgY29tcHV0ZXIgZ3JhZGUgdHdpc3RlZCBw YWlyIGNhYmxpbmcgaXMgdXNlZCBvciB2aWEgRmliZXIgT3B0aWMgVHJhbnNtaXR0ZXJzIHdoZXJl IEZpYmVyIENhYmxpbmcgaXMgdXNlZC4gIFRoZSB0cmFuc21pc3Npb24gZGlzdGFuY2UgZnJvbSB0 aGUgUHJvY2Vzc29yIGxvY2F0aW9uIHRvIHRoZSByZW1vdGUgQ1JUIG1vbml0b3JzIGFuZCBQcmlu dGVycyBpcyB1cCB0byAxMDAwIGZlZXQuICBUaGUgdXNlIG9mIEZpYmVyIENhYmxpbmcgd2lsbCBw ZXJtaXQgdGhlIHJlbW90ZSBkaXN0YW5jZSBvZiBvbmUgKDEpIGtpbG9tZXRlci4gIFN5bmMgYW5k IENsb2NrIGFyZSBhbHNvIHByb3ZpZGVkIHRvIGVhY2ggQ1JUIE1vbml0b3IuDVRoZSBSZWZyZXNo IE1lbW9yeSBpcyBUd28tUG9ydCBTU1JBTSB3aGVyZSBQb3J0IDEgaXMgY29udHJvbGxlZCBieSB0 aGUgQ1JUIE11eCBpbiB0aGUgYWJvdmUgbWFubmVyIGFuZCBQb3J0IDIgaXMgY29ubmVjdGVkIHRv IFBvcnQgNCBvZiB0aGUgTGFuZ3VhZ2UgUHJvY2Vzc29yIExvY2FsIE1lbW9yeSAoRkJDKS4gIFBv cnQgMiBpcyB1c2VkIGZvciBhbGwgQ1JUIE1vbml0b3IgZWRpdCBmdW5jdGlvbnMuDQ1UaGUgS2V5 Ym9hcmQvTW91c2UgaW50ZXJmYWNlIHRvIHRoZSBDSUNVIChDb25zb2wgSW50ZXJydXB0IENvbnRy b2wgVW5pdCkgaXMgc2VyaWFsIHdoZXJlIHRoZSBDSUNVIHBlcmZvcm1zIGEgY29udHJvbGxlZCBz aGlmdCAoQ2xvY2sgaW4sIENsb2NrIG91dCkgb2YgdGhlIFN0YXJ0IEJpdCwgSUQgQml0IGZvbGxv d2VkIGJ5IHRoZSBkYXRhLiAgVGhlIFN0YXJ0IEJpdCB3aWxsIGhhbHQgdGhlIENJQ1UgU2Nhbm5l cjsgZXhhbWluZSB0aGUgSUQgQml0IChDaGFyYWN0ZXIvTW91c2UpIGFuZCBzaGlmdCBpbiB0aGUg cmVxdWlyZWQgbnVtYmVyIG9mIGJpdHMuICBVcG9uIGNvbXBsZXRpb24gb2YgdGhlIHNoaWZ0LCB0 aGUgQ0lDVSB3aWxsIGdlbmVyYXRlIGFuIEludGVycnVwdCB0byB0aGUgTGFuZ3VhZ2UgUHJvY2Vz c29yIChhIGRlZGljYXRlZCBWZWN0b3IpOyBwZXJmb3JtIGEgU2luZ2xlIFdvcmQgcmVhZCB2aWEg RkJDIFBvcnQgNCB3aGljaCBjb250YWlucyB0aGUgVXNlciBOdW1iZXIsIGEgQ2hhcmFjdGVyL0Z1 bmN0aW9uIENvZGUgb3IgUmVmcmVzaCBNZW1vcnkgQWRkcmVzcyBvZiB0aGUgTW91c2UgQ2xpY2ss IHRoZW4gY29tbWVuY2UgcHJvY2Vzc2luZy4gIFRoZSBDSUNVIGlzIHJlYWRpZWQgZm9yIG90aGVy IGlucHV0cyB1cG9uIGNvbXBsZXRpb24gb2YgdGhlIHJlYWQuICBEb3VibGUgY2xpY2tpbmcgaXMg TkVWRVIgcmVxdWlyZWQuICBUaGUgTW91c2UgSW50ZXJydXB0IGlzIGRlcGVuZGVudCB1cG9uIHRo ZSBUSVBTIExpZ2h0cGVuIE9wZXJhdG9yIGFuZCBTeXN0ZW0gVmFyaWFibGVzIExQMSwgTFAyLCBM UDMgYW5kIExQNCB1c2VhZ2UgaW4gYW4gQXBwbGljYXRpb24gUHJvZ3JhbS4NDVRoZSBJRCBSZWFk ZXIgaXMgYW4gb3B0aW9uYWwgZGV2aWNlIGZvciBnYWluaW5nIGFjY2VzcyB0byBzeXN0ZW0gdXNl YWdlLiAgVGhlIJNJbml0aWFsaXpllCBjb2RlIGlzIHNlbnQgdG8gdGhlIENJQ1Ugd2hlbmV2ZXIg YSBjYXJkIGlzIHBsYWNlZCBpbiB0aGUgUmVhZGVyLiAgVGhlIJNTaWduYXR1cmUgY29kZSBpcyBz ZW50IHRvIHRoZSBDSUNVIGJ5IGRlcHJlc3NpbmcgdGhlIGFwcHJvcHJpYXRlIGtleSBvbiB0aGUg S2V5Ym9hcmQgYW5kIHNpZ25pZmllcyB0aGF0IGRhdGEgdG8gZm9sbG93IGlzIGFuIGlkZW50aWZp Y2F0aW9uIGNvZGUuICBBbiBBcHBsaWNhdGlvbiBQcm9ncmFtIHdpbGwgZGV0ZXJtaW5lIFdITyBh bmQgV0hFUkUgYW5kIFdIQVQgVFlQRSBvZiBEQVRBIHRoZSBjYXJkIHVzZXIgbWF5IGdhaW4gYWNj ZXNzIHRvIGluIHRoZSBzeXN0ZW0uICBJbiB0aGlzIGNhc2UgdGhlIFVzZXIgbWF5IGJlIFlPVSBv ciBhIFN5c3RlbSBBcHBsaWNhdGlvbnMgUHJvZ3JhbW1lci4NDQkJQSBTeXN0ZW0gQ1JUIE1vbml0 b3Igd2l0aCBLZXlib2FyZCBpcyBwcm92aWRlZCBwcmltYXJpbHkgZm9yIERlYnVnZ2luZyBTeXN0 ZW0NU29mdHdhcmUgb2YgZWl0aGVyIHByb2Nlc3Nvci4gIEEgQ29udHJvbCBQYW5lbCBpcyBhbHNv IHByb3ZpZGVkIGZvciBTaW5nbGUgliBTdGVwcGluZyB0aHJ1IGENUHJvZ3JhbS4gIFRoZSBwcm9j ZXNzb3JzIGFyZSBzd2l0Y2ggc2VsZWN0YWJsZS4gVGhlIFByb2dyYW1tZXIgY2FuIG1vZGlmeSBl aXRoZXIgUHJvZ3JhbSBNZW1vcnkgb3IgTG9jYWwgTWVtb3J5IGFzIG5lY2Vzc2FyeS4gVGhlIEVu ZC1JdGVtIEhhcmR3YXJlIHdpbGwgTk9UIGhhdmUgdGhpcyBjYXBhYmlsaXR5LiBBcyBhIHJlc3Vs dCCWIGl0IGlzIElNUE9TU0lCTEUgZm9yIFZJUlVTIHRvIGVudGVyIHRoZSBzeXN0ZW0uDQwNNS4g IFNZU1RFTSBTT0ZUV0FSRQ0NCUFzIHByZXZpb3VzbHkgc3RhdGVkOyB0aGUgT3BlcmF0aW5nIFN5 c3RlbSBjb25zaXN0cyBvZiA5LDk2NyBJbnN0cnVjdGlvbnMgaW5jbHVkaW5nIEhhcmQNRGlzayBv cGVyYXRpb25zIGZvciBzdG9yYWdlL3JldHJpZXZhbCBvZiBkYXRhIGFuZCBBcHBsaWNhdGlvbiBQ cm9ncmFtcy4gIFRoaXMgZnVuY3Rpb24gaXMgcmVtb3ZlZA1mcm9tIHRoZSBMYW5ndWFnZSBQcm9j ZXNzb3IgYW5kIGFsbG9jYXRlZCB0byB0aGUgUGVyaXBoZXJhbCBzaWRlIHdoaWNoIGluY2x1ZGVz IERpcmVjdG9yeSAmIEZpbGUgTWFpbnRlbmFuY2UgZm9yIHRoZSBMb2NhbCBzeXN0ZW0gYW5kIHVw IHRvIJNOlCBzdWJzeXN0ZW1zLiAgVGhpcyByZWR1Y2VzIHRoZSBpbnN0cnVjdGlvbiBjb3VudCB0 byBhcHByb3hpbWF0ZWx5IDksMDAwLiAgVGhpcyBpcyBGVUxMWSBPcHRpbWl6ZWQgSGFuZCBDb2Rp bmcgdXNpbmcgYSBQcm9ncmFtIEFzc2VtYmxlciCWIG5vdCBhIENvbXBpbGVyLiAgVGhlIHN5c3Rl bSBwcm9ncmFtbWVyIGlzIFRPVEFMTFkgb2JsaXZpb3VzIHRoYXQgdGhlIG1hY2hpbmUgZG9lcyBv ciBkb2VzIG5vdCBlbXBsb3kgUGlwZWxpbmUgZGVzaWduLiAgT25jZSB0aGUgU3lzdGVtIFByb2dy YW1tZXIgaXMgZnVsbHkgc2F0aXNmaWVkIHdpdGggaGlzIGRlc2lnbiCWIHRoaXMgcGVyc29uLCBp biBhc3NvY2lhdGlvbiB3aXRoIGEgTWljcm8tUHJvZ3JhbW1lciB3aWxsIGZ1cnRoZXIgb3B0aW1p emUgdGhlIGNvZGUgdXNpbmcgdGhlIGZ1bGwgY2FwYWJpbGl0aWVzIG9mIHRoZSBFUklOMzIgUHJv Y2Vzc29yLg0JVG8gZnVsbHkgZGVmaW5lIHRoZSBoYXJkd2FyZSByZXF1aXJlbWVudHMgb2YgdGhl IEVSSU4zMjsgdGhlIGZvbGxvd2luZyBJbnN0cnVjdGlvbiBtaXggaXMgdXNlZDoNCQlCUkFOQ0gJ CTE2JQ0JCVNUT1JFCQkgIDklDQkJQVJJVEgvTE9HSUMJNDUlDQkJTE9BRAkJCTI2JQ0JCVNISUZU CQkJICA0JQ0NCUFuIGFuYWx5c2lzIG9mIHRoZSA5LDk2NyBJbnN0cnVjdGlvbnMsIHdoaWNoIGlz IGEgZ29vZCBiYXNpcyBmb3IgdGhlc2UgcGVyY2VudGFnZXMsIHNob3dzIHRoYXQgdGhleSBhcmUg YXBwcm94aW1hdGVseSBjb3JyZWN0LiAgQSBmdXJ0aGVyIGFuYWx5c2lzIHdhcyBhY2NvbXBsaXNo ZWQsIHJlc3VsdGluZyBpbjoNCQkJCQkJCVJlZHVjZXMgdG86DQkJSk1QCQkxMzE4CQkJZnVsbHkg dHJhbnNwYXJlbnQNCQlKU1QJCSAgNzY0CQkJZnVsbHkgdHJhbnNwYXJlbnQNCQlMREEvU1RBCSAg MzkwIHBhaXJzCQkzOTANCQlCUkFOQ0gJICA1MDAgcGFpcnMJCTUwMA0JCUxEQS9BREQJICAxMTYg cGFpcnMJCTExNg0JCUxEQS9TVUIJICAgIDg2IHBhaXJzCQkgIDg2DQkJTERBL0FOQQkgIDE0OCBw YWlycwkJMTQ4DQkJTERBL0VSQQkgICAgMzYgcGFpcnMJCSAgMzYNCQlMREEvQU9BCSAgICAxNiBw YWlycwkJICAxNg0JCUxEQS9DTUEJICAgICAgOCBwYWlycwkJICAgIDgNCQlMREEvVENBCSAgICAx MCBwYWlycwkJICAxMA0JCUxEQS9DQVMJICAgIDc0IHBhaXJzCQkgIDc0DUxEQS9JTUEJICAgIDIy IHBhaXJzCQkgIDIyDQkJTERBL0xHUgkgICAgMTMgcGFpcnMJCSAgMTMNCQlMREEvQVJSCSAgICAg IDMgcGFpcnMJCSAgICAzDQkJTERBL0xHTAkgICAgMTUgcGFpcnMJCSAgMTUNCQlMREEvQUxTCSAg ICAgIDMgcGFpcnMJCSAgICAzDQkJTERBL0FSUwkgICAgICAxIHBhaXIJCSAgICAxDQkJTERBL0FM UgkgICAgICAyIHBhaXJzCQkgICAgMg0NCQkJCVRvdGFsIFJlZHVjdGlvbgkxNDQxDQkJCQlUb3Rh bCBJbnN0IGFmdGVyCQk3NTU5DQ1PdGhlciByZWR1Y3Rpb25zIGNhbiBhbmQgd2lsbCBiZSBtYWRl IHdoZXJlIDc1MDAgaXMgYSBnb29kIG51bWJlciBmb3IgY29udmVyc2F0aW9uLiAgV2h5IGNvbmNl bnRyYXRlIGluIHRoaXMgYXJlYT8/ICBGb3IgZnV0dXJlIFJlc2VhcmNoIHdpdGggcG9zc2libGUg RVJJTjY0IEFTSUMgYXBwbGljYXRpb24uDQ02LiAgVEhFIFBST0NFU1NPUg0NCUEuICBJTlRST0RV Q1RJT04NCQlUaGUgRVJJTjMyIGlzIGEgMzItYml0IGJpbmFyeSBkYXRhIHdvcmQgZ2VuZXJhbCBw dXJwb3NlIGNvbXB1dGVyIHdpdGggYQ0JNSBOYW5vLXNlY29uZCBTeW5jaHJvbm91cyBTdGF0aWMg UmFtIChTU1JBTSkgbWVtb3J5LiAgVGhlIG1hY2hpbmUgb3JnYW5pemF0aW9uDQlwZXJtaXRzIERp cmVjdCwgSW5kZXggUmVsYXRpdmUsIGFuZCBJbmRpcmVjdCBhZGRyZXNzaW5nIG1vZGVzLiBUaGlz IGFsbG93cyBhZGRyZXNzaW5nDW9mIDEsMDQ4LDU3NiAoMjAgYml0cykgZGF0YSBvciBpbnN0cnVj dGlvbiB3b3Jkcy4gU3RhbmRhcmQgZmVhdHVyZXMgaW5jbHVkZSBhIGZsZXhpYmxlIGluc3RydWN0 aW9uIHJlcGVydG9pcmUgb2YgNjcgY29tbWFuZHMsIHRocmVlIGhhcmR3YXJlIGluZGV4IHJlZ2lz dGVycyAoSGFydmFyZCBBcmNoaXRlY3R1cmUpLCA4IHZlY3RvcmVkIGludGVycnVwdHMgYW5kIGEg cG93ZXJmdWwgSS9PIGJ1cyBzdHJ1Y3R1cmUgd2hpY2ggdXNlcyBhbiBGQkMgKEZ1bGx5IEJ1ZmZl cmVkIENoYW5uZWwpIGZvciBkYXRhIHRyYW5zZmVyLiAgQSBTeW1ib2xpYyBBc3NlbWJsZXIgaXMg dXNlZCB0byBnZW5lcmF0ZSBtYWNoaW5lIGNvZGUgaGF2aW5nIGFuIDEwOCBiaXQgaW5zdHJ1Y3Rp b24gd29yZC4gIE9wdGlvbnMgaW5jbHVkZSBoaWdoLXNwZWVkIGFyaXRobWV0aWMgTXVsdGlwbHks IERpdmlkZSwgU3F1YXJlIFJvb3QgYW5kIEZsb2F0aW5nIFBvaW50LCBhbmQgYSBmdWxsIGxpbmUg b2YgcGVyaXBoZXJhbCBlcXVpcG1lbnQuDQlUaGUgRVJJTjMyIGlzIGRlc2lnbmVkIGZvciBib3Ro IG9wZW4tc2hvcCBzY2llbnRpZmljIGFwcGxpY2F0aW9ucyBhbmQgcmVhbC10aW1lDW9uLWxpbmUg ZGF0YSBwcm9jZXNzaW5nIGFuZCBjb250cm9sLiAgQSBicm9hZCB2YXJpZXR5IG9mIGFwcGxpY2F0 aW9ucyBjYW4gYmUgdGFpbG9yZWQgdG8NaW5jbHVkZSBkYXRhIHJlZHVjdGlvbiwgcHJvY2VzcyBj b250cm9sLCBpbnN0cnVtZW50YXRpb24sIHNpbXVsYXRpb24sIG9wZW4tc2hvcCBzY2llbnRpZmlj DWFuZCBlbmdpbmVlcmluZyBjb21wdXRhdGlvbiBvciBhbnkgY29tYmluYXRpb24gb2YgdGhlc2Uu DQlQcm9ncmFtbWluZyB0aGUgRVJJTjMyIGlzIHNpbWlsYXIgdG8gcHJvZ3JhbW1pbmcgb3RoZXIg ZHVhbCBzb3VyY2UsIHNpbmdsZQ1kZXN0aW5hdGlvbiBhZGRyZXNzIGNvbXB1dGVycyB1c2luZyB0 d2+ScyBjb21wbGVtZW50IG5vdGF0aW9uLiAgVGhlcmVmb3JlLCBubyBtYWpvciBkaWZmZXJlbmNl cyBjb25mcm9udCB0aGUgcHJvZ3JhbW1lciB3aG8gaXMgbmV3IHRvIHRoZSBFUklOMzIuDQkNCUIu ICBERVNDUklQVElPTg0JCVRoZSBFbmQtSXRlbSBQcm9jZXNzb3IgaXMgYSBRdWlja2xvZ2ljIENv cnBvcmF0aW9uIFFMNjUwMCBGUEdBLCA1MTYgUGluIGRldmljZQ1vZiB0aGUgRWNsaXBzZSBGYW1p bHkuICBUaGUgZGV2ZWxvcG1lbnQgc29mdHdhcmUgZm9yIHRoaXMgZmFtaWx5IGlzIGN1cnJlbnRs eSBpbiBCZXRhIFRlc3RpbmcuDUl0cyBjYXBhYmlsaXR5IGlzOg0JCQlNYXggR2F0ZXMJID0gNDg4 LDA2NA0JCQlMb2dpYyBDZWxscwkgPSAzMDcyDQkJCU1heCBGRpJzIAkgPSA3NDg4DQkJCU1heCBJ L08gIAkgPSA0NDggcGlucw0JCQlSYW0gTW9kdWxlcwkgPSAzMiB1bnVzZWQNCQkJUGFja2FnZQkg PSBCR0ENCQkJUExMCQkgPSA0LCB3aXRoIDF4LDJ4LDR4DQkJCURMTA0JCQlHbG9iYWwgQ2xvY2sg TmV0cyA9IDkNCVRoZSBwcmltYXJ5IHJlYXNvbiBmb3Igc2VsZWN0aW5nIHRoaXMgZGV2aWNlIGlz IEkvTyBwaW5zIHdoZXJlIEkgcmVxdWlyZSAzOTU7IG5vdCBiZWNhdXNlIEkgYW0gbG9naWMgbGlt aXRlZC4gIEluIG9yZGVyIHRvIG9idGFpbiBhIHJlYXNvbmFibHkgY2xvc2UgdmlldyBvZiB0aGUg ZGVzaWduLCBJIHJlbW92ZWQgdGhlIEZCQyBsb2dpYyBhbmQgdGhlIGFzc29jaWF0ZWQgcGlucyBh bmQgd2VudCB0aHJ1IFBMQUNFICYgUk9VVEUgdXNpbmcgYSBRTDMwNjAtNCB3aXRoIHRoZSBmb2xs b3dpbmcgcmVzdWx0czoNCQlVc2FibGUgUExEIEdhdGVzCTYwLDAwMA0JCUxvZ2ljIENlbGxzCQkx MzYwIG9mIDE1ODQNCQlDbG9jayBPbmx5IENlbGxzCTMgb2YgOA0JCUZGknMJCQk4NzYNCQlCaS1E aXJlY3Rpb25hbCBDZWxscwkzMDggb2YgMzA4DQkJUm91dGluZyBSZXNvdXJjZXMJMzkzMjggb2Yg MTAyOTE2ICh3aXJlcykNCQkJCQlUaGlzIGlzIHdoZXJlIGRlbGF5cyBhcmUgaW52b2x2ZWQgaW4g YWRkaXRpb24gdG8gZ2F0ZQ0JCQkJCWRlbGF5cyBhcyBhIGZ1bmN0aW9uIG9mIExPQURJTkcuICBB bGwgbG9hZGluZyBpcyBoZWxkDQkJCQkJYnkgZGVzaWduIHRvIGEgbWF4aW11bSBvZiA4LiBIZXJl IHRoZSB0ZXJtIGZhbi1vdXQgaGFzDQkJCQkJdGhlIHNhbWUgbWVhbmluZy4NCQlWaWFMaW5rIFJl c291cmNlcwkzNDMyNyBvZiAyNzYyMjkwIChmdXNlIGxpbmtzKQ0JCQ1EZWxheXMgdGhhdCBhZmZl Y3QgdGhlIGRlc2lnbiBleHRlcm5hbCB0byB0aGUgZGV2aWNlIGFyZSBiYXNlZCBvbiB0aGVzZSBh c3N1bXB0aW9ucy4gIFNTUkFNIGFjY2VzcyA9IDVOUywgYWRkcmVzcyBzZXQtdXAgPSA1bnMgZnJv bSBJL08gcGluIHRvIFJBTSBwaW4uLCAgU1NSQU0gZGF0YSB0byBpbnB1dCBwaW4NPSA1TlMuICBU aGVzZSBhcmUgY2lyY3VpdCBib2FyZCBkZWxheXMuDQ0JVGhlIFByb2Nlc3NpbmcgRWxlbWVudHMg KFBFknMpIGFuZCBFeGVjdXRpb24gVW5pdHMgKEVVknMpIGluY2x1ZGUgdGhlIGZpcnN0IGxldmVs IG9mIFBpcGVsaW5lIHdoZXJlIG5lY2Vzc2FyeSBpbmNsdWRpbmcgMzIgYml0IEFyZ3VtZW50IFJl Z2lzdGVycy4gIEVhY2ggY29udGFpbiB0aGVpciBTdGF0ZSBMb2dpYyBUaW1pbmcsIFNjb3JlYm9h cmQsIFdhaXQgTG9naWMgZm9yIG9wZXJhdGlvbnMgcmVxdWlyaW5nIHJlc3VsdHMgb2YgcHJldmlv dXMgaW5zdHJ1Y3Rpb24gJiBhIE11bHRpcGxleGVyIFN0ZWVyaW5nIG91dHB1dC4gSW4gdGhlc2Ug ZGVzaWducyB5b3Ugd2lsbCBzZWUgZGlmZmVyZW50IG1ldGhvZHMgb2YgbG9hZGluZyBkaXN0cmli dXRpb24gdGVjaG5pcXVlcyBhcyBkZXNjcmliZWQgaW4gdGhlIFF1aWNrbG9naWMgTWFudWFsLiAg RWFjaCBQRSBoYXMgYmVlbiBGVUxMWSBoYW5kIGxvZ2ljIG9wdGltaXplZCCWIGl0IGlzIGZ1cnRo ZXIgb3B0aW1pemVkIGluIHRoZSBDSElQIGdlbmVyYXRpb24gcHJvY2VzcyB3aGljaCBtb2RpZmll cyB5b3VyIHJlcXVlc3RlZCBmdW5jdGlvbiB0byB0aGF0IG9mIHRoZSBMb2dpYyBDZWxsIHN0cnVj dHVyZS4gIEEgcHJpbnQtb3V0IGlzIGF2YWlsYWJsZSBvZiB0aGUgYWZmZWN0ZWQgYXJlYXMuICBB bGwgZGVzaWduIHVzZXMgU0NIRU1BVElDIGlucHV0IE9OTFkuDQ0JQUwzMgkJVGhpcyBFVSBwZXJm b3JtcyBhbGwgb2YgdGhlIHJlcXVpcmVkIEFyaXRobWV0aWMvTG9naWMgZnVuY3Rpb25zLiAgVGhl cmUgaXMgDQkJCW5vIG1hZ2ljIGhlcmUgliBwdXJlIHRleHQgYm9vayAtIFRUTCAgLSBTTjc0MTgx IEFMVSB3aXRoIHRoZSBTTjc0MTgyDXVzZWQgZm9yIENhcnJ5IExvb2stQWhlYWQuICBUd28gb2Yg dGhlc2UgRVWScyBhcmUgcmVxdWlyZWQgZm9yIHRoZSBTaW5nbGUgTGV2ZWwgUGlwZWxpbmUuIEl0 IHNhdGlzZmllcyBhbGwgb2YgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIEREUC01MTYgYW5kIHdp bGwgcHJvdmlkZSBhZGRpdGlvbmFsIEluc3RydWN0aW9uIGNhcGFiaWxpdHkgdG8gdGhlIEVSSU4z Mi4NDUFNVVgJVGhpcyBQRSBpcyBhIHNpbXBsZSBtdWx0aXBsZXhlciAgdGhhdCByZWNlaXZlcyBp bnB1dHMgZnJvbSB0aGUgQUwzMiwgdGhlDQkJQmFycmVsIFNoaWZ0ZXIgKG9uZSBpbnB1dCBBUyBJ UyBhdCB0aGUgb3V0cHV0LCBhbmQgaXMgYWxzbyBiaXQgcmV2ZXJzZWQgZm9yDQkJUmlnaHQgU2hp ZnRzKS4gIFR3byBpbnB1dHMgYXJlIGZyb20gdGhlIExvYWQgUEUgYW5kIG9uZSBmcm9tIHRoZSBD U1RCDQkJRVUuDQ1BUkVHCQlUaGlzIFBFIGlzIGEgc2ltcGxlIDMyIEJpdCBSZWdpc3Rlci9BY2N1 bXVsYXRvci4gIERhdGEgaW5wdXRzIGFyZSBmcm9tIHRoZQ1BTVVYOyAgU2lnbiBjb250cm9sIGFu ZCBDbGVhciBmdW5jdGlvbnMgYXJlIHJlY2VpdmVkIGZyb20gdGhlIFVEUlMgKG90aGVycykgUEUs IHN1Y2ggYXMgUFMgKFByZXNldCBTaWduKSwgUlMgKFJlc2V0IFNpZ24pLCBDbGVhciBzZWxlY3Rl ZCBCeXRlLCBhbmQgQ1JBIChDbGVhciBBLXJlZykuICBUaGUgQVogKEFyZWc9WmVybykgb3V0cHV0 IGlzIGVzc2VudGlhbGx5IG9uZSBiaXQgb2YgdGhlIENDUiAoQ29uZGl0aW9uIENvZGUgUmVnaXN0 ZXIpIHVzZWQgZm9yIENvbmRpdGlvbmFsIEJyYW5jaC4gIEV2ZXJ5DWluc3RydWN0aW9uIGhhdmlu ZyBBcmVnIGRlc3RpbmF0aW9uICh3aGljaCBpcyBtb3N0IG9mIHRoZSB0aW1lKSB3aWxsIGNhdXNl IEFaDVRvIGNoYW5nZS4NDUJSQU4JVGhpcyBFVSBjb250YWlucyBhIDE2IEJpdCBJbnN0cnVjdGlv biBSZWdpc3RlciBvZiB0aGUgdHlwZSBvZiBCcmFuY2ggdGhlIFByb2dyYW1tZXIgd2FudHMgdG8g ZXhlY3V0ZS4gIEhlIG1heSBzZWxlY3Qgb25lIG9yIG1vcmUgQ29uZGl0aW9ucy4gVGhlcmUgaXMg YSAxNiBCaXQgT1IgZ2F0ZSB3aG9zZSBvdXRwdXQgaXMgQlJBTi4gVGhpcyBvdXRwdXQgaXMgYXBw bGllZCB0byB0aGUgVkVDVE9SIEVVLg0NQ0FTCVRoaXMgRVUgcGVyZm9ybXMgYW4gQXJpdGhtZXRp YyBDb21wYXJlIG9mIHR3byBvcGVyYW5kcyBhbmQgUmVnaXN0ZXJzDQl0aGUgcmVzdWx0ICBpbiAz IGJpdHMgb2YgdGhlIENDUi4gIFRoZXNlIGFyZSBBTEIsIEFHQiwgYW5kIEVRVS4gIFRoZQ0JZGVz aWduIHVzZXMgdGhlIFRUTCBTTjc0MTg1IGFzIGJ1aWxkaW5nIGJsb2NrLiAgUHVyZSB0ZXh0Ym9v ayBkZXNpZ24uDQ1DU1RCCVRoaXMgaXMgYSBjbGFzc2ljYWwgRGF0YSBTZWxlY3Rvci9NdWx0aXBs ZXhlciBkZXNpZ24gdGhhdCBwZXJmb3JtcyB0aGUgQ2xlYXIgQml0LCBTZXQgQml0IGFuZCBUZXN0 IEJpdCBJbnN0cnVjdGlvbnMgYW5kIGlzIGJhc2VkIG9uIFRUTCBTTjc0MTUwLiBUaGUgVFNUIG91 dHB1dCBpcyBvbmUgYml0IG9mIHRoZSBDQ1IgYW5kIGlzIGFwcGxpZWQgdG8gdGhlIEJSQU4gRVUu ICBUaGUgRGF0YSBPdXRwdXRzIGFyZSBhcHBsaWVkIHRvIHRoZSBBTVVYLg0NDUlOREVYCVRoZSBk ZXNpZ24gdXNlcyB0aHJlZSAoMykgb2YgdGhlc2UgRVWScy4gIFRoZXkgZWZmZWN0aXZlbHkgaW1w bGVtZW50IHRoZQ0JSGFydmFyZCBBcmNoaXRlY3R1cmUgY2hvc2VuLiAgSGVyZTsgdGhlIFByb2dy YW1tZXIgaGFzIG1hbnkgT3B0aW9ucy4NCVRoZSBBLVNvdXJjZSBhbmQgQi1Tb3VyY2UgSW5kZXgg UmVnaXN0ZXIgKHdpdGggSW5jcmVtZW50IGNhcGFiaWxpdHkpDQlhcmUgYXBwbGllZCB0byBTU1JB TSBSZWFkIE9ubHkgUG9ydHMgYXMgcHJldmlvdXNseSBkZXNjcmliZWQuIFRoaXMNCXNvdXJjZSBt YXkgYmUgYW55IGNvbWJpbmF0aW9uIG9mIENvbW1vbiBEYXRhIFBvb2wgYW5kIFVTRVIgc2xvdC4N CVRoZSBEZXN0aW5hdGlvbiAoV3JpdGUpIEluZGV4IFJlZ2lzdGVyIGhhcyB0aGUgc2FtZSB2YXJp YWJsZSBhdmFpbGFibGUuDQlUaGV5IG1heSBiZSByYW5kb21seSBJbmNyZW1lbnRlZCBvciBMb2Fk ZWQgb25lLCB0d28sIG9yIGFsbCB0aHJlZSBzZWxlY3RpdmVseS4gIFRoZSCTWJQgb3V0cHV0IGlz IGFwcGxpZWQgdG8gdGhlIFN0b3JlIEVVLg0NDUlSUwlJbmNyZW1lbnQsIFJlcGxhY2UgKFN0b3Jl KSAmIFNraXAgaWYgWmVybyA9IEREUC01MTYuICBJbmNyZW1lbnQsIFJlcGxhY2UgJiBSZWdpc3Rl ciByZXN1bHQgPSBFUklOMzIuICBUaGlzIGlzIG9uZSBiaXQgb2YgdGhlIENDUiBhbmQgdXNlcyB0 aGUgdGVybSBOWi4gIFRoaXMgZGVzaWduIHVzZXMgYSAzMiBCaXQgSW5jcmVtZW50ZXIgd2hlcmUg dGhlIElOREVYIEVVIHVzZXMgYSAyMCBiaXQgSW5jcmVtZW50ZXIuICBUaGUgTlogb3V0cHV0IGlz IGFwcGxpZWQgdG8gdGhlIEJSQU4gRVUuICBUaGUgSW5jcmVtZW50ZWQgdmFsdWUgaXMgYXBwbGll ZCB0byB0aGUgU1RPUkUgRVUuLiAgVHdvIG9mIHRoZXNlIEVVknMgYXJlIHJlcXVpcmVkIGZvciB0 aGUgU2luZ2xlIExldmVsIFBpcGVsaW5lIHRoYXQgaXMgaW1wbGVtZW50ZWQuDQ0NTE9BRAlUaGlz IEVVICByZWNlaXZlcyBEYXRhIGZyb20gYSBSZWFkIE9ubHkgUG9ydCBhbmQgc2VydmljZXMgdGhl IExEQQ0JKExvYWQgQWNjdW11bGF0b3IpIGFuZCBMREIgKExvYWQgU2VsZWN0ZWQgQnl0ZSBpbiBT ZWxlY3RlZCBCeXRlDQlQb3NpdGlvbiksIHdpdGggb3Igd2l0aG91dCBiaXQgOCBJTkIgKEluaGli aXQpIEluc3RydWN0aW9ucy4gQml0IDggaXMgZGVmaW5lZCBhcyB0aGUgQ1VSU09SIEJJVCwgIHdo ZXJlIFNvZnR3YXJlIGlzIHByaW1hcmlseSBpbnRlcmVzdGVkIGluIHRoZSByZW1haW5pbmcgQVND SUkgQ2hhcmFjdGVyLCBJTkIgaXMgc3BlY2lmaWVkLiAgVGhlIG9ubHkgZXhjZXB0aW9uIHRvIHRo aXMgaXMgdGhlIG5vcm1hbCBDUlQgRWRpdCBwcm9jZXNzLiAgV2hlcmUgdHlwaW5nIHNheXMgliBl bnRlciB0aGUgcmVxdWlyZWQgY2hhcmFjdGVyIGFuZCBTdGVwIHRoZSBDdXJzb3IuICBUaGlzIGNh biBiZSBkb25lIHdpdGggdGhlIFNFVEIgKFNldCBCaXQpIEluc3RydWN0aW9uLg0JDQ1TVE9SRQlU aGlzIEVVIHJlY2VpdmVzIHNlbGVjdGVkIGlucHV0cyBiYXNlZCBvbiBleGVjdXRpb24gb2YgIFNU QSAoU3RvcmUNCUFjY3VtdWxhdG9yKSwgU1RCIChTdG9yZSBTZWxlY3RlZCBCeXRlIGluIHRoZSBT ZWxlY3RlZCBCeXRlIFBvc2l0aW9uLCB3aXRoIG9yIHdpdGhvdXQgSU5IKSwgU1RYIChTdG9yZSBT ZWxlY3RlZCBJbmRleCksIElSUywgQUxVLCBvciBTaGlmdC4NCVRoZSBkZXNpZ24gY3VycmVudGx5 IHVzZXMgYSBTaW5nbGUgTGV2ZWwgRGF0YS9BZGRyZXNzIFBpcGVsaW5lLg0NDVVEUlMJKE90aGVy cykgIFRoaXMgRVUgY29uc2lzdHMgZW50aXJlbHkgb2YgSW5zdHJ1Y3Rpb25zIGluIHRoZSBDb250 cm9sIGNhdGVnb3J5Lg0JU3VjaCAgYXMgIENSQSwgIFNTTSAgKFNldCBTaWduIE1pbnVzKSwgIFNT UCAoU2V0IFNpZ24gUGx1cyksICBDU0EgKENvbXBsZW1lbnQgU2lnbiBvZiBBcmVnKS4gIEl0IGNv bnRhaW5zIHRoZSBDRkYgd2hpY2ggaXMgb25lIEJpdCBvZiB0aGUgQ0NSLiAgSXQgbWF5IGJlIGNv bnRyb2xsZWQgd2l0aCBTQ0IgKFNldCBDLWJpdCksIGFuZCBSQ0IgKFJlc2V0IEMtYml0KQ0JSW5z dHJ1Y3Rpb25zLiAgT3RoZXIgY29udHJvbCBvZiB0aGUgQ0ZGIGlzIHRoZSByZXN1bHQgb2YgIEFy aXRobWV0aWMgYW5kIFNoaWZ0IEluc3RydWN0aW9ucy4gKE92ZXJmbG93L1VuZGVyZmxvdykNDA1W RUNUT1IJVGhpcyBFVSByZWNlaXZlcyBKTVAgVW5jb25kaXRpb25hbCBKdW1wKSwgSlNUIChKdW1w IGFuZCBTdG9yZSBSZXR1cm4pLCBCUkEgKENvbmRpdGlvbmFsIEJyYW5jaCkgYW5kIFJUTiAoSnVt cCBJbmRpcmVjdCkgZnJvbSBQb3J0IDIgb2YgSW5zdHJ1Y3Rpb24gTWVtb3J5LiAgVGhlIEVOQiAo RW5hYmxlIEludGVycnVwdHMpLCBJTkggKEluaGliaXQgSW50ZXJydXB0cykgSW5zdHJ1Y3Rpb25z IGFyZSByZWNlaXZlZCBmcm9tIFBvcnQgMS4gIEhlcmUgd2UgdXNlIHRoZSB0ZXJtIFZlY3Rvciwg d2hlcmUgdGhlIG5leHQgSW5zdHJ1Y3Rpb24gaXMgUEMrMSBvciBnbyB3aGVyZSBWZWN0b3JlZC4g IEF0IEhvbmV5d2VsbCB3ZSBjYWxsZWQgdGhpcyCTU3BsYXR0ZXKULiAgVGhlcmUgaXMgcHJvdmlz aW9uIGZvciBlaWdodCAoOCkgVmVjdG9yZWQgSW50ZXJydXB0cywgd2hlcmUgbGV2ZWwNOCBpcyB0 aGUgaGlnaGVzdCBsZXZlbC4gIFRoZSBoaWdoZXN0IExldmVsIGlzIGFzc2lnbmVkIHRvIEludGVy LVByb2Nlc3NvciBJbnRlcnJ1cHQsIHRoZW4gNyBpcyBGQkMgVGVybWluYXRpb24gSW50ZXJydXB0 LiBUaGUgcmVtYWluZGVyIGFyZSBhc3NpZ25lZCB0byBQZXJpcGhlcmFsIERldmljZXMgZGVwZW5k aW5nIG9uIHRoZSBQcm9jZXNzb3IgYXBwbGljYXRpb24sIGkuZS4sIExhbmd1YWdlIG9yIFBlcmlw aGVyYWwuICBUaGVzZSBtYXkgY2hhbmdlIGFmdGVyIGRpc2N1c3Npbmcgd2l0aCBTb2Z0d2FyZSBn dXJ1knMuICBBIFRUTCBTTjc0MTQ4IGlzIHVzZWQgYXMgdGhlIFByaW9yaXR5IEVuY29kZXIuICBG dXJ0aGVyIHRpbWluZyBhbmFseXNpcyBtYXkgcmVxdWlyZSBhIExvb2stQWhlYWQgdHdvIHJhdGhl ciB0aGFuIHRoZSBjdXJyZW50IG9uZS4gVGhpcyBpcyBkdWUgdG8gdGhlIGNsb2NrIHRvIG91dCBv ZiBhIEpLRkYsIG9uZSBmb3VyIGlucHV0IE9SIGdhdGUgYW5kIHRoZSB0cmFuc2l0aW9uIHRpbWUg b2YgQmktRGlyZWN0aW9uYWwgSS9PIFBhZC4gIFRoaXMgaXMgdGhlIFRPVEFMICBKdW1wL0JyYW5j aCBkZWNpc2lvbiB0aW1lLg1JdCBzaG91bGQgbm90ZWQgdGhhdCB0aGUgZGVzaWduIGRvZXMgaGF2 ZSBhIEhMVCAoSGFsdCkgSW5zdHJ1Y3Rpb24gYXMgZG9lcyB0aGUgRERQNTE2IGhvd2V2ZXIgdGhl IDUxNiB2aXJ0dWFsbHkgY2FtZSB0byBhIEhBTFQuICBDdXJyZW50bHk7IFN5c3RlbSBTb2Z0d2Fy ZSBpcyBpbiBhIGNvbnRpbnVvdXMgbG9vcCBpbiB0aGUgU2tlZHVsYXIgUm91dGluZSBsb29raW5n IGZvciBzb21ldGhpbmcgdG8gZG8uIFRoaXMgd2lsbCBjaGFuZ2UuIFRoZSByb3V0aW5lIHdpbGwg bWFrZSBhIHNpbmdsZSBwYXNzLCBhbmQgaWYgVW4tSW50ZXJydXB0ZWQgd2lsbCBleGVjdXRlIGEg SExULiAgVGhlcmUgaXMgcHJvdmlzaW9uIGZvciBhbiBJbnRlcnJ1cHQgZnJvbSBIQUxULiAgVGhp cyBhbHNvIGFwcGxpZXMgdG8gdGhlIFBlcmlwaGVyYWwgUHJvY2Vzc29yLiBJbnRlcnJ1cHRzIG11 c3QgYmUgRU5BQkxFRC4NDVdBREUJVGhpcyBFVSBpcyBuYW1lZCBmb3IgbXkgR3JhbmRzb24gV2Fk ZS4gIFRoaXMgd2FzIGEgZnVuIGRlc2lnbiBhbmQNCXRoZSBsaXR0bGUgZmVsbG93IGlzIEZVTi4g IElUIGlzIG1vcmUgYXBwcm9wcmlhdGVseSBjYWxsZWQgU0hJRlQuICBUaGUNCWRlc2lnbiBpcyBi YXNlZCBvbiB0aGUgVFRMIEFNMjVTMTAgKEFNRCksIDc0RjM1MCAoRmFpcmNoaWxkKSBvcg0JU043 NFMzNTAgKFRJKS4gIEFsbCB0aHJlZSBzb3VyY2VzIHByb3ZpZGVkIGV4Y2VsbGVudCBBcHBsaWNh dGlvbiBEYXRhDQlTaGVldHMuICBUaGUgbWV0aG9kIEkgY2hvc2Ugd2FzIHRvIGhhcmQtd2lyZSBh IFNoaWZ0IExlZnQuICBSaWdodCBTaGlmdHMNCWFyZSBCaXQgUmV2ZXJzZWQgcHJpb3IgdG8gYXBw bGljYXRpb24gdG8gdGhlIGJhcnJlbCBzaGlmdGVyIGFycmF5LiAgVGhpcyByZXZlcnNhbCBpcyBh cHBsaWVkIHRvIHRoZSBBTVVYIHdoZXJlIGl0IGlzIHJldmVyc2VkIGZvciB0aGUgY29ycmVjdCB2 YWx1ZS4gIFRoZSBFTkRMDQkoRW5kIExvZ2ljKSBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IGlucHV0 IGRlcGVuZGluZyBvbiB0aGUgdHlwZSBvZiBzaGlmdC4NCVRoZSBGVU4gcGFydCB3YXMgSE9XIHRv IGFjY29tcGxpc2ggdGhlIEFMUyAoQXJpdGhtZXRpYyBTaGlmdCBMZWZ0KQ0Jd2hpY2ggaXMgcmVx dWlyZWQgdG8gc2V0IHRoZSBDRkYgZm9yIGEgY2hhbmdlIGluIFNpZ24gcmVzdWx0aW5nIGZyb20g dGhlIFNoaWZ0LiAgVGhpcyBpcyBuZWNlc3NhcnkgdG8gbWFpbnRhaW4gQXJpdGhtZXRpYyBjb3Jy ZWN0bmVzcy4gIEkgY2hvc2UgdG8NCWRvIGFuIHVuLXJlZ2lzdGVyZWQgTm9ybWFsaXplIChTaGlm dCBMZWZ0IHRpbGwgdHdvIE1TQpJzIG5vdCBFcXVhbC4pLg0JVGhpcyBpcyBhY2NvbXBsaXNoZWQg YnkgWE9SIG9mIHRoZSBTaWduIGFnYWluc3QgZWFjaCBCaXQ7ICBhcHBseSB0aGlzIHRvIGENCXNl cmllcyBvZiBQcmlvcml0eSBFbmNvZGVycyAoU043NDE0OCk7IGVuY29kZSB0aGUgb3V0cHV0cyBv ZiB0aGUgMTQ4knMgYW5kIGRvIGEgTG9naWNhbCBDb21wYXJlIChTTjc0MTg1KSBvZiB0aGUgcmVx dWVzdGVkIFNoaWZ0IGFtb3VudCB3aXRoIEVuY29kZWQNCVZhbHVlIJYgaWYgRXF1YWwgdG8gb3Ig TGVzcyBUaGFuIJYgY2xlYXIgQ0ZGLCBpZiBHcmVhdGVyIJYgc2V0IENGRi4gIE1heQ0Jbm90IGJl IHRoZSBvbmx5IHNvbHV0aW9uLCBidXQgZm9yIGFuIGFycmF5IHNoaWZ0ZXIsIEmSbSBvcGVuIGZv ciBvdGhlciBkZXNpZ24NCWFwcHJvYWNoZXMuICBUd28gb2YgdGhlc2UgRVWScyBhcmUgcmVxdWly ZWQgZm9yIGEgU2luZ2xlIExldmVsIFBpcGVsaW5lDQwNQy4gIElOU1RSVUNUSU9OIFNFVA0NTWVt b3J5IFJlZmVyZW5jZSBJbnN0cnVjdGlvbnM6CQlBZGRyZXNzaW5nDQ1KTVAJVW5jb25kaXRpb25h bCBKdW1wCQkJRCwgWCwgSQ0NSlNUCVVuY29uZGl0aW9uYWwgSnVtcAkJCUQsIFgNCSYgU3RvcmUg UmV0dXJuDQ1MREEJTG9hZCBBY2N1bXVsYXRvcgkJCUQsIFgNCUEtU291cmNlIHRvIEFyZWcNDVNU QQlTdG9yZSBBY2N1bXVsYXRvcgkJCUQsIFgNCUFyZWcgdG8gRGVzdGluYXRpb24NDUNBUwlBcml0 aG1ldGljIENvbXBhcmUJCQlELCBYDQlDb21wYXJlIEEtU291cmNlIHRvIEItU291cmNlLA0JQUxC LCBFUVUsIEFHQiBpbnRvIENDUg0NSVJTCUluY3JlbWVudAkJCQlELCBYDQlBLVNvdXJjZSArIDEg dG8gRGVzdGluYXRpb24NDUxEWAlMb2FkIFNlbGVjdGVkIEluZGV4IFJlZ2lzdGVyCQlELCBYDQlB LVNvdXJjZSB0byBYbg0NU1RYCVN0b3JlIFNlbGVjdGVkIEluZGV4IFJlZ2lzdGVyCQlELCBYDQlY biB0byBEZXN0aW5hdGlvbg0NTERCCUxvYWQgU2VsZWN0ZWQgQnl0ZSBvZiBBLVNvdXJjZQlELCBY DWluIHRoZSBTZWxlY3RlZCBCeXRlIFBvc2l0aW9uDQ1TVEIJU3RvcmUgU2VsZWN0ZWQgQnl0ZSBp bgl0aGUJCUQsIFgNCURlc3RpbmF0aW9uIFNlbGVjdGVkIEJ5dGUgUG9zaXRpb24NDUlNQQlJbnRl cmNoYW5nZSBNZW1vcnkJCQlELCBYDUEtU291cmNlICYgQWNjdW11bGF0b3IsDUFyZWcgdG8gRGVz dGluYXRpb24NDUFERAlBZGQgQS1Tb3VyY2UgKyBCLXNvdXJjZQkJRCwgWA0JdG8gQXJlZywgT3Zl cmZsb3cgaW50byBDRkYNDVNVQglTdWJ0cmFjdCBCLVNvdXJjZSBmcm9tIEEtU291cmNlLAlELCBY DQlUbyBBcmVnLCBVbmRlcmZsb3cgaW50byBDRkYNDA1BTkEJTG9naWNhbCBBTkQgb2YgQS1Tb3Vy Y2UJCUQsIFgNCSYgQi1Tb3VyY2UgdG8gQXJlZw0NRVJBCUxvZ2ljYWwgRXhjbHVzaXZlIE9yIG9m IEEtU291cmNlCUQsIFgNCSYgQi1Tb3VyY2UgdG8gQXJlZw0NT1IJTG9naWNhbCBPciBvZiBBLVNv dXJjZQkJRCwgWA0JJiBCLVNvdXJjZSB0byBBcmVnDQ1OT1IJTG9naWNhbCBOb3Igb2YgQS1Tb3Vy Y2UJCUQsIFgNCSYgQi1Tb3VyY2UgdG8gQXJlZw0NWE5SCUxvZ2ljYWwgRXhjbHVzaXZlIE5vciBv ZiBBLVNvdXJjZQlELCBYDQkmIEItU291cmNlIHRvIEFyZWcNDU5BTglMb2dpY2FsIE5hbmQgb2Yg QS1Tb3VyY2UJCUQsIFgNCQkJJiBCLVNvdXJjZSB0byBBcmVnDQ1BTkIJTG9naWNhbCBBIGFuZCBO b3QgQiBvZiBBLVNvdXJjZQlELCBYDQkmIEItU291cmNlIHRvIEFyZWcNDU5BQglMb2dpY2FsIE5v dCBBIGFuZCBCIG9mIEEtU291cmNlCUQsIFgNCQkJJiBCLVNvdXJjZSB0byBBcmVnDQ1PVEhFUiBB UklUSE1FVElDDQ1DTUEJQ29tcGxlbWVudCBBCQkJTkENDVRDQQlUd2+ScyBDb21wbGVtZW50IEEJ CQlOQQ0NQU9BCUFkZCBPbmUgdG8gQXJlZywgCQkJTkENCU92ZXJmbG93IGludG8gQ0ZGDQ1BQ0EJ QWRkIENGRiB0byBBcmVnLAkJCU5BDQlPdmVyZmxvdyBpbnRvIENGRg0NQU1PCUFyZWcgTWludXMg MSwJCQkJTkENCVVuZGVyZmxvdyBpbnRvIENGRg0MDU5vdGU6ICBBbGwgb2YgdGhlIGFib3ZlIEFy aXRobWV0aWMgYW5kIExvZ2ljICYgTERBIGluc3RydWN0aW9ucyBtYXkgaW5jbHVkZSBhbiBvcHRp b25hbCBTdG9yZS4gIEZvciBleGFtcGxlOiBMREEvU1RBIG9yIEFERC9TVEEuICBJbiB0aGVzZSBj YXNlcyBhDQlEZXN0aW5hdGlvbiBBZGRyZXNzIGlzIHNwZWNpZmllZC4gIFRoZSByZXN1bHRzIHdp bGwgYWx3YXlzIGJlIHRvIHRoZSBBcmVnDVRoZSBBLVNvdXJjZSBpcyBlaXRoZXIgdGhlIEFyZWcg b3IgbWVtb3J5Lg0NRCA9IERpcmVjdA1YID0gSW5kZXggUmVsYXRpdmUNSSA9IEluZGlyZWN0IChD dXJyZW50bHkgSk1QIG9ubHkgliB0aGlzIG1heSBiZSBjaGFuZ2VkIHRvIGluY2x1ZGUgYWxsIE1l bW9yeSBSZWZlcmVuY2UgSW5zdHJ1Y3Rpb25zKQ0NU0hJRlQgSU5TVFJVQ1RJT05TDQ1MR0wJTG9n aWNhbCBMZWZ0DQlUaGUgQXJlZyBvciBBLVNvdXJjZSBpcyBzaGlmdGVkIGxlZnQgKG4pIHBvc2l0 aW9ucy4NCVpFUk+ScyBmaWxsIGluIHZhY2F0ZWQgYml0IHBvc2l0aW9ucyBvZiBMZWFzdCBTaWdu aWZpY2FudA1FbmQuICBBMzIgaXMgc2hpZnRlZCB0byB0aGUgQ0ZGLiAgUmVzdWx0IHRvIEFyZWcg YW5kDURlc3RpbmF0aW9uIGlmIHNwZWNpZmllZC4gKExHTC9TVEEpDQkNTEdSCUxvZ2ljYWwgUmln aHQNCVRoZSBBcmVnICBvciBBLVNvdXJjZSBpcyBzaGlmdGVkIHJpZ2h0IChuKSBwb3NpdGlvbnMu DQlaRVJPknMgZmlsbCBpbiB2YWNhdGVkIGJpdCBwb3NpdGlvbnMgb2YgTW9zdCBTaWduaWZpY2Fu dA0JRW5kLiAgQTEgaXMgc2hpZnRlZCB0byB0aGUgQ0ZGLiAgUmVzdWx0IHRvIEFyZWcgYW5kDQlE ZXN0aW5hdGlvbiBpZiBzcGVjaWZpZWQuICAoTEdSL1NUQX0NDUFMUglMb2dpY2FsIExlZnQgUm90 YXRlDQlUaGUgQXJlZyBvciBBLVNvdXJjZSBpcyBzaGlmdGVkIGxlZnQsIGVuZC1hcm91bmQgKG4p IHBvc2l0aW9ucy4NCUEzMiBpcyBzaGlmdGVkIHRvIEExIGFuZCB0aGUgQ0ZGLiAgUmVzdWx0IHRv IEFyZWcgYW5kDQlEZXN0aW5hdGlvbiBpZiBzcGVjaWZpZWQuICAoQUxSL1NUQSkNDUFSUglMb2dp Y2FsIFJpZ2h0IFJvdGF0ZQ0JVGhlIEFyZWcgb3IgQS1Tb3VyY2UgaXMgc2hpZnRlZCByaWdodCwg ZW5kLWFyb3VuZCAobikgcG9zaXRpb25zLg0JQTEgaXMgc2hpZnRlZCB0byBBMzIgYW5kIHRoZSBD RkYuICBSZXN1bHQgdG8gQXJlZyBhbmQNCURlc3RpbmF0aW9uIGlmIHNwZWNpZmllZC4gIChBUlIv U1RBKQ0NQUxTCUFyaXRobWV0aWMgTGVmdCBTaGlmdA0JVGhlIEFyZWcgb3IgQS1Tb3VyY2UgaWYg c2hpZnRlZCBsZWZ0IChuKSBwb3NpdGlvbnMuDQlaRVJPknMgZmlsbCBpbiB2YWNhdGVkIGJpdCBw b3NpdGlvbnMgb2YgTGVhc3QgU2lnbmlmaWNhbnQNCUVuZC4gSWYgc2hpZnRpbmcgY2F1c2VzIGEg Y2hhbmdlIGluIHNpZ24gb2YgQXJlZyBvciBBLVNvdXJjZQ0JYXQgYW55IHRpbWUgZHVyaW5nIHRo ZSBpbnN0cnVjdGlvbiwgdGhlIENGRiBpcyBzZXQuICBJZiB0aGUgc2lnbg0JaXMgbm90IGNoYW5n ZWQsIHRoZSBDRkYgaXMgcmVzZXQuICBSZXN1bHQgdG8gQXJlZyBhbmQNCURlc3RpbmF0aW9uIGlm IHNwZWNpZmllZC4gIChBTFMvU1RBKQ0MDUFSUwlBcml0aG1ldGljIFJpZ2h0IFNoaWZ0DQlUaGUg QXJlZyBvciBBLVNvdXJjZSBpcyBzaGlmdGVkIHJpZ2h0IChuKSBwb3NpdGlvbnMuDQlUaGUgc2ln biBiaXQgKEEzMikgZG9lcyBub3QgY2hhbmdlOyBpdCBpcyBzaGlmdGVkIGludG8gdmFjYXRlZA1w b3NpdGlvbnMgb2YgdGhlIEFyZWcgb3IgQS1Tb3VyY2UgKFNpZ24gRXh0ZW5kZWQpLiAgVGhlIENG Rg10YWtlcyB0aGUgc3RhdGUgb2YgdGhlIGxhc3QgYml0IHNoaWZ0ZWQgb3V0IG9mIHRoZSByZWdp c3Rlci4gIFJlc3VsdA10byBBcmVnIGFuZCBEZXN0aW5hdGlvbiBpZiBzcGVjaWZpZWQuICAoQVJT L1NUQSkNDU5vdGU6ICBTaGlmdCBhbW91bnQgKG4pLCB3aGVyZSAobikgPSAxIHRvIDMxDQ1DT05U Uk9MIElOU1RSVUNUSU9OUw0JCQ0JCUlSWAlJbmNyZW1lbnQgU2VsZWN0ZWQgSW5kZXggUmVnaXN0 ZXIocykNCQkNCQlTWFMJU2VsZWN0IEEtU291cmNlIEluZGV4DQ0JCVNYRAlTZWxlY3QgQi1Tb3Vy Y2UgSW5kZXgNDQkJU1hXCVNlbGVjdCBEZXN0aW5hdGlvbiBJbmRleA0NQ0xCCUNsZWFyIEJpdCAo bikNCUNsZWFyIHRoZSBzZWxlY3RlZCBiaXQNDVNCVAlTZXQgQml0IChuKQ0JU2V0IHRoZSBzZWxl Y3RlZCBiaXQNDVRTQglUZXN0IEJpdCAobikNCVRlc3QgdGhlIHNlbGVjdGVkIGJpdA0NQ0JZCUNs ZWFyIEJ5dGUgKG4pDQlDbGVhciB0aGUgc2VsZWN0ZWQgYnl0ZQ0JUmlnaHQgQnl0ZSA9IDANDVJD QglSZXNldCBDRkYNDVNDQglTZXQgQ0ZGDQ1DU0EJQ29weSBTaWduIGFuZCBTZXQgU2lnbiBQbHVz DQlBMzIgdG8gQ0ZGLCBDbGVhciBBMzINCQ1DSFMJQ29tcGxlbWVudCBBcmVnIFNpZ24NDUNSQQlD bGVhciBBcmVnDQ1JTkgJSW5oaWJpdCBJbnRlcnJ1cHQNDUVOQglFbmFibGUgSW50ZXJydXB0DQ1I TFQJSGFsdCwgb3IgV2FpdCBmb3IgSW50ZXJydXB0IGlmIEVOQUJMRUQgd2l0aCBwcmlvciBFTkIN DU5PUAlObyBPcGVyYXRpb24NDUJSQU5DSCBJTlNUUlVDVElPTlMNDUJMVAlCcmFuY2ggTGVzcyBU aGFuDQlSZXN1bHQgb2YgcHJldmlvdXMgQ0FTDQ1CRVEJQnJhbmNoIEVxdWFsDQlSZXN1bHQgb2Yg cHJldmlvdXMgQ0FTDQ1CR1QJQnJhbmNoIEdyZWF0ZXIgVGhhbg0JUmVzdWx0IG9mIHByZXZpb3Vz IENBUw0NQk5aCUJyYW5jaCBOb3QgWmVybw0JUmVzdWx0IG9mIHByZXZpb3VzIElSUyAoTlopDQ1U QloJVGVzdCBCaXQgWmVybw0NVEJOWglUZXN0ICBCaXQgTm90IFplcm8NDVNSQwlCcmFuY2ggIGlm IENGRiByZXNldA0NU1NDCUJyYW5jaCBpZiBDRkYgc2V0DQ1TWkUJQnJhbmNoIEFyZWcgWmVybyAo QVopDQ1TTloJQnJhbmNoIEFyZWcgTm90IFplcm8gKEFaKQ0NU0xOCUJyYW5jaCBBMSA9IE9uZQ0N U0xaCUJyYW5jaCBBMSA9IFplcm8NDVNQTAlCcmFuY2ggQTMyID0gWmVybyAocG9zaXRpdmUgc2ln bikNDVNNSQlCcmFuY2ggQTMyID0gT25lIChuZWdhdGl2ZSBzaWduKQ0NU1cxCUJyYW5jaCBTd2l0 Y2ggMSBTZXQgKE9OKQ0JQW4gQXBwbGljYXRpb24gUHJvZ3JhbW1lciBpcyBEZWJ1Z2dpbmcsDQlE TyBOT1QgSEFMVCBPTiBFUlJPUlMNDVNXMglCcmFuY2ggU3dpdGNoIDIgU2V0IChPTiksDUNhbGwg U3lzdGVtIFByb2dyYW1tZXIgRGVidWcgUm91dGluZQ0NQlJBCSBCcmFuY2gNDU5vdGU6CUFsbCBv ZiB0aGUgYWJvdmUgZXN0YWJsaXNoIGEgY29uZGl0aW9uIHRoYXQgd2lsbCBiZSBURVNURUQgdXBv bg0JRXhlY3V0aW9uIG9mIEJSQS4gIE9uZSBPUiBtb3JlIG9mIHRoZXNlIGNvbmRpdGlvbnMgbWF5 IGJlIA1lc3RhYmxpc2hlZCBwcmlvciB0byBCUkEuICBGb3IgZXhhbXBsZTsgQ0FTIGVzdGFibGlz aGVzIG9uZSBvZg10aHJlZSBjb25kaXRpb25zLiAgSSBtYXkgZXhlY3V0ZSBCUkEgb24gRXF1YWwg b3IgTGVzcyBUaGFuIGlmDUJFUS9CTFQgaXMgcHJldmlvdXNseSBzcGVjaWZpZWQgb3IgbWF5IGV4 ZWN1dGUgQlJBL0JFUS9CTFQNaW4gdGhlIHNhbWUgaW5zdHJ1Y3Rpb24uDQ1JTlBVVC9PVVRQVVQg SU5TVFJVQ1RJT04NDQkJTW92CU1vdmUgQS1Tb3VyY2UgZGF0YSBvciBvbmUgb2YgdGhlIGZvbGxv d2luZyBjb250cm9scw0JCQkgMCA9IENsZWFyIGludGVycnVwdCBMZXZlbCAxIChMb3dlc3QpDQkJ CSAxID0gQ2xlYXIgaW50ZXJydXB0IExldmVsIDINCQkJIDIgPSBDbGVhciBpbnRlcnJ1cHQgTGV2 ZWwgMw0JCQkgMyA9IENsZWFyIGludGVycnVwdCBMZXZlbCA0DQkJCSA0ID0gQ2xlYXIgaW50ZXJy dXB0IExldmVsIDUNCQkJIDUgPSBDbGVhciBpbnRlcnJ1cHQgTGV2ZWwgNg0JCQkgNiA9IENsZWFy IGludGVycnVwdCBMZXZlbCA3DQkJCSA3ID0gQ2xlYXIgaW50ZXJydXB0IExldmVsIDggKEhpZ2hl c3QpDQkJCSA4ID0gU2VuZCBJbnRlci1Qcm9jZXNzb3IgSW50ZXJydXB0IFB1bHNlDQkJCSA5ID0g RkJDIEdsb2JhbCBNZW1vcnkgV3JpdGUNCQkJIEEgPSBGQkMgUG9ydCA0IFdyaXRlDQkJCSBCID0g RkJDIFJlZnJlc2ggTWVtb3J5IFdyaXRlDQkJCSBDID0gQ0lDVSBSZWFkIHRvIEZCQyBQb3J0IDQg V3JpdGUgKExhbmd1YWdlIFByb2Nlc3NvciksDSAgICAgICAgUmVzZXJ2ZWQgKFBlcmlwaGVyYWwg UHJvY2Vzc29yKQ0JCQkgRCA9IFJlc2VydmVkDQkJCSBFID0gUmVzZXJ2ZWQNCQkJIEYgPSBSZXNl cnZlZA0NTW92ZSBBLVNvdXJjZSBEYXRhIGZyb20vdG8gR2xvYmFsIHJlcXVpcmVzIHR3byBNT1Yg SW5zdHJ1Y3Rpb25zIHRvIHNldHVwIEdsb2JhbCBUd28tUG9ydCBBZGRyZXNzIHdpdGggQmFuayBT ZWxlY3QgYW5kIExvY2FsIEZCQyBQb3J0IDQgQWRkcmVzcywgQmFuayBTZWxlY3QgYW5kIFJhbmdl IENvdW50LiBDb250cm9sIGZpZWxkIGRldGVybWluZXMgZGlyZWN0aW9uLg0NTW92ZSBBLVNvdXJj ZSBEYXRhIGZyb20vdG8gUmVmcmVzaCBNZW1vcnkgcmVxdWlyZXMgdHdvIE1PViBJbnN0cnVjdGlv bnMgdG8gc2V0dXAgUmVmcmVzaCBNZW1vcnkgVHdvLVBvcnQgQWRkcmVzcyBhbmQgTG9jYWwgUG9y dCA0DUFkZHJlc3MsIEJhbmsgU2VsZWN0IGFuZCBSYW5nZSBDb3VudC4gIENvbnRyb2wgZmllbGQg ZGV0ZXJtaW5lcyBkaXJlY3Rpb24uDQxPUFRJT05BTCBJTlNUUlVDVElPTlMNDVRoZSBvcHRpb25h bCBNdWx0aXBseS9EaXZpZGUgUHJvY2Vzc29yIHJlcXVpcmVzIGFuIGFkZGl0aW9uYWwgRlBHQSBk ZXZpY2UuDUJvdGggSW5zdHJ1Y3Rpb25zIGFyZSB0cmVhdGVkIGFzIGFzeW5jaHJvbm91cyBwZXJp cGhlcmFsIGRldmljZXMgYW5kIG1heSBiZSBpbml0aWF0ZWQgaW4gYW55IHNlcXVlbmNlIJYgZWZm ZWN0aXZlbHkgZXhlY3V0aW5nIGluIHBhcmFsbGVsLiBCb3RoIGFyZSBpbml0aWF0ZWQNd2l0aCB0 aGUgTW92IEluc3RydWN0aW9uLg0NTVVMVElQTFkgliBUaGUgZGVzaWduIHBlcmZvcm1zIGFuIFVu LVNpZ25lZCAzMiBYIDMyIFRpbWUtU2VxdWVuY2VkLCBwaXBlbGluZWQgbXVsdGlwbHkvYWRkIHdp dGggTmliYmxlIFNraXAuIChOaWJibGUgPSA0IGJpdHMpLiAgVGhlIG11bHRpcGxpZXIgbXVzdCBi ZSBhcHBsaWVkIGZpcnN0IGluIHNlcXVlbmNlIGZvciBleGFtaW5hdGlvbiBvZiB0aGUgZGF0YS4g IFRoZSByZXN1bHQgaXMgYSA2NCBCaXQgUHJvZHVjdCB3aGljaCByZXF1aXJlcyB0d28gTW92IGlu c3RydWN0aW9ucyBmb3IgaW5wdXR0aW5nIHRoZSBNU1AgKE1vc3QgU2lnbmlmaWNhbnQgUHJvZHVj dCkgYW5kIHRoZSBMU1AgKExlYXN0IFNpZ25pZmljYW50IFByb2R1Y3QpLiBJbnN0cnVjdGlvbiBj b21wbGV0aW9uIGlzIHNpZ25hbGVkIHdpdGggYW4gSW50ZXJydXB0LiAgSW5mb3JtYXRpb24gb24g VGltZQ1TZXF1ZW5jZSBNdWx0aXBseSBtYXkgYmUgb2J0YWluZWQgZnJvbSBBTUQgRGF0YSBCb29r cyBmb3IgYXBwbGljYXRpb24gb2YgdGhlIEFNMjVTMDUsIGEgMiBYIDQgVHdvknMgQ29tcGxlbWVu dCBNdWx0aXBsaWVyLg0NRElWSURFIJYgVGhlIGRlc2lnbiBwZXJmb3JtcyBhbiBVbi1TaWduZWQg MzIgWCAzMiBwaXBlbGluZWQgZGl2aWRlLA1Ta2lwcGluZyBvdmVyIHN0cmluZ3Mgb2YgT25lknMg YW5kIFplcm+Scy4gIFRoZSBkZXNpZ24gaXMgYmFzZWQgb24gdGhlIHRleHQgaW4Nk1RoZSBMb2dp YyBvZiBDb21wdXRlciBBcml0aG1ldGljOiBieSBJdmFuIEZsb3JlcywgUHJlbnRpY2UtSGFsbCwg SW5jLiwgdGhlDUxpYnJhcnkgb2YgQ29uZ3Jlc3MgQ2F0YWxvZyBDYXJkIE51bWJlciA2My0xNDcy Ny4gIFRoZSByZXN1bHQgaXMgYSAzMiBCaXQNUXVvdGllbnQgYW5kIDMyIEJpdCBDb3JyZWN0ZWQg UmVtYWluZGVyLiAgVGhlIERpdmlzb3IgbXVzdCBiZSBlcXVhbCB0byBvcg1ncmVhdGVyIHRoYW4g dGhlIERpdmlkZW5kLiAgVGhlIERpdmlzb3IgbXVzdCBiZSBhcHBsaWVkIGZpcnN0IGZvciBhDU5v cm1hbGl6YXRpb24gcHJvY2VzcyB0byBvY2N1ci4gIE91dHB1dHRpbmcgdGhlIERpdmlkZW5kIHdp bGwgY2F1c2UgYW4NRXF1YWxpemF0aW9uIHByb2Nlc3MgdG8gb2NjdXIuICBUd28gTW92IGluc3Ry dWN0aW9ucyBhcmUgcmVxdWlyZWQgdG8gZmlyc3QNaW5wdXQgdGhlIFF1b3RpZW50IGFuZCB0aGVu IHRoZSBjb3JyZWN0ZWQgcmVtYWluZGVyIGlmIGRlc2lyZWQuICBJbnN0cnVjdGlvbg1jb21wbGV0 aW9uIGlzIHNpZ25hbGVkIHdpdGggYW4gSW50ZXJydXB0Lg0NVGhlc2UgZGVzaWducyB3ZXJlIGNv bXBsZXRlZCBidXQgbm90IHRlc3RlZCBpbiAxOTk3IHVzaW5nIGEgUXVpY2tsb2dpYw1RTDMwNjAt NC4gIFRoZSByZXN1bHRzIG9mIFBsYWNlICYgUm91dGUgYXJlOg0NCUxvZ2ljIENlbGxzCQkgICAg ICAgICAgODE0IG9mIDE1ODQNCUNsb2NrIENlbGxzCQkgICAgICAgICAgICAgIDIgb2YgOA0JQmkg RGlyZWN0aW9uYWwgQ2VsbHMgICAgICAgCTQyIG9mIDMwOA0JUm91dGluZyBSZXNvdXJjZXMJICAg ICAgMjMyMTMgb2YgMTAyOTE2DQlWaWFMaW5rIFJlc291cmNlcwkgICAgICAxOTk1MSBvZiAyNzYy MjkwDQlDZWxsIEZGknMJCSAgICAgICAgICA0Mjcgb2YgMTU4NA0NVGhpcyBkZXNpZ24gd2lsbCB1 c2UgdGhlIFFMNjI1MCBvZiB0aGUgUXVpY2tsb2dpYyBFY2xpcHNlIFNlcmllcyB0byBvYnRhaW4N dGhlIGJlc3QgcG9zc2libGUgcGVyZm9ybWFuY2UuICBTbGlnaHQgY2hhbmdlcyB3aWxsIGJlIHJl cXVpcmVkIHRvIGNvbmZvcm0NdG8gdGhlIE1vdiBpbnN0cnVjdGlvbiBhbmQgSW50ZXJydXB0IEdl bmVyYXRpb24uDQwNRkxPQVRJTkcgUE9JTlQNDU11c3QgZmlyc3Qgb2J0YWluIHRoZSBsYXRlc3Qg SUVFRSBTcGVjaWZpY2F0aW9uLiAgQmFzZWQgb24gbXkgZXhwZXJpZW5jZSBpbiAxOTc5LTgwIGF0 IHRoZSBIb25leXdlbGwgU21hbGwvTWVkaXVtIEluZm9ybWF0aW9uIFN5c3RlbXMgRGl2aXNpb24g dGhpcyBkZXNpZ24gc2hvdWxkIHRha2UgYXBwcm94aW1hdGVseSB0d28gbW9udGhzLiAgRGl2aXNp b24gV0FTIGFjY29tcGxpc2hlZCBpbiB0aGUgU0FNRSBtYW5uZXIgYXMgZGVzY3JpYmVkIGFib3Zl LiBNdWx0aXBsaWNhdGlvbiBNQVkgYmUgYWNjb21wbGlzaGVkIGluIHRoZSBzYW1lIG1hbm5lciBh cyBhYm92ZSBob3dldmVyIGF0IEhvbmV5d2VsbCwgdGhpcyB3YXMNYWNjb21wbGlzaGVkIGJ5IGV4 YW1pbmF0aW9uIG9mIE9uZZJzIGFuZCBaZXJvIHN0cmluZ3MgYXMgZGVzY3JpYmVkIGJ5IEZMT1JF Uy4gIFRoaXMgZGVzaWduIHdpbGwgdXNlIHRoZSBRTDY1MDAgRlBHQSBhbmQgc2hvdWxkIHVzZSB0 aGUgZXF1aXZhbGVudCBvZiAyNTAgVFRMIE1TSSBjb21wb25lbnRzLiAgVGhlIG9uLWNoaXAgUkFN IHdpbGwgYmUgdXNlZCBmb3Igc3RvcmluZyBQcm9ncmFtcy9Db25zdGFudHMgcHJlc2VudGVkIHRv IGl0IGZyb20gRkJDIFBvcnQgNCBvZiB0aGUgTGFuZ3VhZ2UgUHJvY2Vzc29yIGZvciBleGVjdXRp b24uICBJIHdpbGwgYXNzdW1lIHRoZSBJRUVFIHN0YW5kYXJkIGlzIDggQml0IEV4cG9uZW50IGFu ZCAyNCBCaXQgTWFudGlzc2EgYW5kIHByb2NlZWQgYWNjb3JkaW5nbHkuICBJdCB3aWxsIGNvbmZv cm0gdG8gdGhlIE1vdiBpbnN0cnVjdGlvbiBhbmQgZ2VuZXJhdGUgYW4gaW50ZXJydXB0IG9uIGNv bXBsZXRpb24gb2YgYSByZXF1ZXN0ZWQgc2VyaWVzLg0NR0VORVJBTCBDT01NRU5UUw0NWW91IHdp bGwgbm90aWNlIHdlIHVzZSBhIGRpc3RyaWJ1dGVkIHByb2Nlc3Npbmcgc2NoZW1lLiAgVGhpcyB3 aWxsIGFsbG93IEFMTA1Qcm9jZXNzb3JzIHRoZSBiZXN0IHBvc3NpYmxlIFBsYWNlICYgUm91dGUs IGZld2VzdCB3aXJlcyBhbmQgYmVzdCBwb3NzaWJsZSBwZXJmb3JtYW5jZS4NDSBFWElTVElORyBE T0NVTUVOVEFUSU9ODUxvZ2ljIERpYWdyYW1zLCBFUklOMzIgUHJvY2Vzc29yDUxvZ2ljIERpYWdy YW1zLCBNdWx0aXBseS9EaXZpZGUNVElQUyBTb2Z0d2FyZSBMaXN0aW5nLCBSZWxvY2F0YWJsZSwg U3lzdGVtIEs2IGRhdGVkIDIzIEF1Z3VzdCAxOTcxDVBlcmlwaGVyYWwgUHJvY2Vzc29yIFNvZnR3 YXJlLCBSZWxvY2F0YWJsZSwgIFN5c3RlbSBLNiBkYXRlZCAyMyBBdWd1c3QgMTk3MQ1BcHBsaWNh dGlvbiBQcm9ncmFtbWVycyBSZWZlcmVuY2UgTWFudWFsIChUSVBTKSwgMTYwIHBhZ2VzLCBzaW5n bGUtc2lkZWQNRERQLTUxNiBQcm9ncmFtbWVycyBSZWZlcmVuY2UgTWFudWFsDVByb2dyYW1tZXJz IFJlZmVyZW5jZSBNYW51YWwgZm9yIHRoZSBDTElOSS1DQUxMKiBEQVRBDU1BTkFHRU1FTlQgU1lT VEVNIFJldi4gRywgMTEgTm92ZW1iZXIgMTk2OQ0MVEhFIExBTkdVQUdFIE9GIFRJUFMNVGhlIFRJ UFMgTGV4aWNvbg0NVGhlIFRJUFMgbGFuZ3VhZ2UgY29uc2lzdHMgb2Ygdm9jYWJ1bGFyeSB3b3Jk cywgdmFyaWFibGUgbWFya2VycyBhbmQNUHVuY3R1YXRpb24gbWFya3Mgd2hpY2ggYXJlIHVzZWQg dG8gZm9ybSBsZWdhbCBzdHJpbmdzIGNhbGxlZCBzdGF0ZW1lbnRzIGZvciBleGVjdXRpb24NYnkg dGhlIHN5c3RlbS4NDUNPTU1BTkRTCU9QRVJBVE9SUwlNT0RJRklFUlMJCVZBUklBQkxFIE1BUktF UlMNDVBSSU5UCQkJRklMRQkJCUlOIEZPUk0JCZNYlCAgLSBMaXRlcmFsIG1hcmtlcg0NUFJJT1JJ VFkJCVBBR0UJCQlGT1IJCQk8WD4gLSBWYWx1ZSBtYXJrZXINDURJU1BMQVkJCVBBUlQJCQlJRgkJ CVtYXSAgLSBOdW1lcmljYWwgcG9zaXRpb24gbWFya2VyDQ1ERU1BTkQJCUZPUk0JCQlPTg0NU0VU CQkJKyAocGx1cykJCUVOUVVFCQlQVU5DVFVBVElPTiBNQVJLUw0NREVMRVRFCQktIChtaW51cykJ CQkJCS8gICAtIFN0ZXAgbWFya2VyDQkJCQkJCVNZU1RFTQ1DT01QSUxFCQk9IChlcXVhbHMpCQlW QVJJQUJMRVMJCTogICAtIFJhbmdlIG9mIHZhbHVlcyBtYXJrZXINDVdBSVQJCQk9PgkJCUxQMQkJ CTsgICAtIFN0YXRlbWVudCB0ZXJtaW5hdG9yDQ1UTwkJCTw9CQkJTFAyCQkJLCAgIC0gTGlzdCBk ZWxpbWl0ZXINDURPCQkJUkVBREVSCQlMUDMJCQlAICAgLUtleWJvYXJkIGlucHV0IHRlcm1pbmF0 b3INDURPTkUJCQlMSUdIVFBFTgkJTFA0CQkJLiAgLSAoY2VudGVyIGRvdCkgc3ViZmlsZSBtYXJr ZXINDVNFTkQJCQlTVEVQCQkJVElNRQkJCSogICAtIENvbW1lbnQgbWFya2VyDQ1SRUNFSVZFCQlW SURFTwkJQ0xPQ0sNDShSRVNFUlZFRCkJCSYgKENvbnRlbmF0aW9uCUJMSU5LDQkJCSAgICAgIG9w ZXJhdG9yKQ0JCQkJCQlVTkJMSU5LDQ0JCQkJCQkkWFgkICAoMSkNDQkJCQkJCVQxDQ0JCQkJCQlU Mg0NQWxsIDQgY2hhcmFjdGVyIHZhcmlhYmxlcyBzdGFydGluZyBhbmQgZW5kaW5nIHdpdGggJCBy ZXNlcnZlZCBmb3IgRXJyb3IgSGFuZGxpbmcgYW5kIEluaXRpYWxpemF0aW9uLg0NVGhlIGZvbGxv d2luZyBmdW5jdGlvbnMgd2lsbCBiZSBhZGRlZC4NCShGb3IgU2VjdXJlIHZpc2FibGUgZGF0YSBl bnZpcm9ubWVudHMpDUJMQU5LICh0aWxsIFVuYmxhbmspDVVOQkxBTksgKHRpbGwgQmxhbmspDUNs ZWFyIEJsYW5rIChEaXNwbGF5IGFsbCkNRGlzcGxheSBCbGFuayAoRGlzcGxheSBvbmx5IHRoZSBC bGFua2VkIEZpZWxkcykNDU90aGVycw1NVUwNRElWDVNjcm9sbCBTY3JlZW4gb25lIGxpbmUgVXAN U2Nyb2xsIFNjcmVlbiBvbmUgbGluZSBEb3duDUZsb2F0aW5nIFBvaW50DQ1Ob3RlOiAgk0hvbWWU IGlzIHRoZSBmaXJzdCBjaGFyYWN0ZXIgcG9zaXRpb24gb2YgdGhlIGZpcnN0IGxpbmUuICBEYXRh IENvbXByZXNzaW9uIHRlY2huaXF1ZXMgYXJlIHVzZWQgdG8gcmVkdWNlIEhhcmQgRHJpdmUgc3Rv cmFnZS4NDQ0NICANDQ0JCQ0JDQ0JCQ0NDQ0NDQ0NCQkgDQkNDQ0JDQ0JDQkJDQkNCQ0JCSAgDQkJ ICANDQ0TUEFHRSAgFQ0NDRNQQUdFICAUMjEVDQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAAAMEAAA2 BAAAawQAAG0EAADQBAAA0QQAAAoFAAAaBQAAHAUAACwFAABWCgAAXAoAAIQKAACXCgAADQsAABwL AADYDwAA9A8AABASAAAsEgAAqxcAAMcXAACGLAAAmiwAADU0AABHNAAASTQAAFo0AABxOQAAgTkA AAJsAAADbAAA0m8AANNvAADgcwAA93MAAO18AADwfAAABX0AAAl9AAA0fQAAN30AANl/AADcfwAA 7oEAABWCAAAZggAAHYIAAPCCAADxggAArIMAAL6DAADtgwAA9IMAAAmEAAAUhAAAFYQAABiEAAAq hgAAUYYAAK2HAACuhwAA2IcAANmHAADfhwAA4IcAAOGHAADjhwAA5IcAAOqHAADrhwAA7YcAAO6H AADvhwAA84cAAPoA+gD4APQA8QD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0 APQA9AD0APQA9AD0APQA9ADq5+rnAOrn6t/q5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8wShAAbUgABG5IAAR1CAEEMEoQAAAN A2oAAAAAMEoQAFUIAQRDSiAAAAY1CIFcCIEAA0gqAQo1CIFDSiQAXAiBTAAEAAABBAAAAgQAAAME AAA2BAAAXgQAAHUEAACcBAAAnQQAAJ4EAACxBAAA0AQAANEEAADSBAAA0wQAANQEAADVBAAA1gQA ANcEAADYBAAA2QQAANoEAADbBAAA3AQAAOwEAADtBAAA7gQAAO8EAADwBAAA+QAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAA AAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADwAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAAABAwAABAAAAyQBYSQBAAEAAAAFAQAOhOT9XYTk/QAcAAQAANiHAADyhwAA/f0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQLwBAAA8QQAAPIEAADzBAAA 9AQAAPUEAAD2BAAA9wQAAPgEAAD5BAAA+gQAAPsEAAD8BAAA/QQAAAkFAAAaBQAAGwUAABwFAAAs BQAAdQUAAKgFAACpBQAAXQYAAIoHAACRCAAAkggAAOoLAADrCwAALg0AAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAAAAAAAAAUAABGE0AJghNACAAEAAAAEAAADJAFhJAEAHC4NAAAvDQAA1w8AAPQPAAD1 DwAAPxAAAHoQAAB7EAAADhEAAEIRAABDEQAADxIAABASAAAsEgAALRIAAKETAACiEwAAwhMAAAEU AAAtFAAAVhQAAIwUAADTFAAAFBUAABYVAABtFQAAGBYAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAOYAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAEYTQAmCE0AIA BQAAD4QIB16ECAcFAAAKJgALRgMAAAUAAA+E0AJehNACAAEAAAAaGBYAABkWAADZFgAA2hYAADAX AACpFwAAqxcAAMcXAADIFwAA3RkAAN4ZAAASGgAALxoAAHcaAAC4GgAAAxsAAD0bAABRGwAAZBsA AKYbAADQGwAA0RsAABocAABDHAAAbBwAAJgcAAC/HAAA2hwAAPwcAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAEYTQAmCE0AIAAQAAABz8HAAARx0AAJAdAADgHQAAlh4A ALAeAADoHgAA6R4AABsfAABTHwAAjR8AAMwfAAARIAAAEyAAAMUhAADGIQAAxyEAALMkAACaJQAA myUAAO0oAADuKAAA5SoAAOYqAAA2KwAAkysAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOwAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA 4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAA AAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADiAAAAAAAAAAAA AAAA7AAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAPhNACEYTQAl6E0AJghNACAAEA AAUAAAomAAtGBAAABQAAD4SgBV6EoAUABQAAEYTQAmCE0AIAGZMrAACELAAAhiwAAJosAACbLAAA 9SwAAFctAACvLwAAEDAAAB4wAAAsMAAAPjAAAEswAABaMAAAWzAAAA8xAAAiMQAAQjEAAGMxAAB+ MQAAmDEAALMxAADQMQAA6zEAAAgyAAAlMgAARDIAAGEyAAB+MgAA+QAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAFAAAPhNACXoTQAgAcfjIAAJkyAAC2MgAA1TIAAPIyAAAR MwAALzMAAE4zAABPMwAAaDMAAIMzAACEMwAANDQAADU0AABHNAAASDQAAFo0AACkNAAA9DQAAEs1 AABSNwAAozcAAPw3AABXOAAAkDgAANw4AABuOQAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA 5wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAABGE0AJghNACAAUA AA+E0AJehNACAAEAAAAJAAAPhNACEYTQAl6E0AJghNACABpuOQAAcDkAAIE5AADSOQAAMToAAEQ6 AABcOgAAczoAAIg6AAChOgAAvToAAM86AADrOgAA8joAAAs7AAAuPAAASDwAAGQ8AAB+PAAAizwA AK08AADZPAAAFD0AAE89AACLPQAAoj0AANQ9AADXPQAAiT4AAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AAAAAAAFAAAPhNACXoTQAgAFAAARhNACYITQAgABAAAAHIk+AACxPgAAsj4AAGNBAABkQQAAt0EA AP9BAADQQgAA0UIAAB9DAABtQwAAtUMAALtDAAC8QwAADUQAAC9FAAB9RQAAiEUAAIlFAAB0RgAA dUYAAL5GAAAERwAAS0cAAExHAABRSAAAUkgAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAA AAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAPhHAIEYRg+l6EcAhg hGD6AAUAAA+EcAhehHAIAAEAAAAFAAARhNACYITQAgAaUkgAAFNIAACiSAAA6EgAAC5JAABySQAA tEkAAP1JAAB5SgAAekoAAHtKAAAcTAAAHUwAAB5MAABlTAAApkwAAB5OAAAgTgAAIU4AAGpOAAD3 TgAAOE8AADlPAAA6TwAAjE8AAF5QAADRUAAA01AAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAF AAARhNACYITQAgAJAAAPhHAIEYRg+l6EcAhghGD6ABvTUAAAllIAAOdUAACtVgAArlYAAPVWAAA9 VwAAflcAAMVXAAAPWAAAr1gAAPlYAAA9WQAA0VkAABhaAABkWgAA+loAAERbAACTWwAA3FsAAN5b AADyWwAA81sAAB5cAAAfXAAAQFwAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA5QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA4wAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAA AAAAAAAAAAAAAAAJAAAPhHAIEYQw/V6EcAhghDD9AAEFAAAJAAAPhHAIEYTQAl6EcAhghNACAAUA AA+EcAhehHAIAAkAAA+EcAgRhGD6XoRwCGCEYPoAGUBcAABBXAAAX1wAAG9cAABwXAAAjFwAAJ5c AACfXAAAvFwAANFcAADSXAAA8FwAAA9dAAAnXQAAKF0AAD5dAABbXQAAXF0AAINdAACTXQAAlF0A ALxdAADPXQAA0F0AAPhdAAAWXgAAF14AAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAOsAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOsAAAAAAAAA AAAAAADrAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAA+EcAhehHAIAAkAAA+EcAgRhGD6 XoRwCGCEYPoACQAAD4RwCBGEMP1ehHAIYIQw/QAaF14AADxeAABgXgAAYV4AAH9eAACXXgAAq14A AKxeAADOXgAA6l4AAOteAAAVXwAAMl8AADRfAABWXwAAal8AAGtfAACVXwAAqV8AAKpfAADKXwAA 3l8AAN9fAAABYAAAFWAAABZgAABBYAAA9QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADrAAAA AAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAAAAkAAA+EoAURhNACXoSgBWCE0AIACQAAD4RwCBGEYPpe hHAIYIRg+gAJAAAPhHAIEYQw/V6EcAhghDD9ABpBYAAAVWAAAFZgAAB5YAAAj2AAAJBgAAC5YAAA zWAAAM5gAAD3YAAADWEAAA5hAAAfYQAAIGEAADZhAAA3YQAAU2EAAFRhAABvYQAAgmEAAINhAACd YQAAsGEAALFhAADJYQAA3WEAAN9hAAByYgAAvWIAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAB BgAAAQAAAAkAAA+EcAgRhDD9XoRwCGCEMP0AHL1iAADoYgAA6WIAAPRiAAAHYwAAbGMAAG1jAACA YwAAgWMAAJJjAADHYwAAAmQAADdkAABbZAAAXWQAAG9kAACmZAAA4GQAABVlAAA7ZQAAPGUAAFRl AACVZQAAzGUAAPJlAADzZQAADGYAAE5mAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAA AAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAA AO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAA AAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAPhHAIEYQw /V6EcAhghDD9AAEHAAAFAAAPhHAIXoRwCAAbTmYAAIVmAACrZgAArGYAAMZmAAD7ZgAANmcAAHRn AAC2ZwAA7WcAABNoAAAVaAAAMGgAAGZoAACmaAAA4mgAACdpAABYaQAAWWkAAIZpAACHaQAAnGkA AJ9pAADKaQAAzWkAAOlpAADqaQAABmoAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEHAAAFAAAPhHAI XoRwCAAJAAAPhHAIEYQw/V6EcAhghDD9ABsGagAAB2oAACZqAAAnagAAOWoAAFFqAABSagAAYmoA AHhqAAB5agAAimoAAKFqAACiagAAtWoAAM5qAADeagAA32oAAO1qAADuagAA+moAAPtqAAAbawAA MmsAADRrAABNawAATmsAAF1rAABeawAAdGsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAFAAAPhKAFXoSgBQABAAAAHHRrAAB1awAAimsAAItrAADFawAAxmsAANdrAADYawAA 7GsAAO1rAAACbAAAGmwAABtsAAAsbAAARGwAAEVsAABdbAAAdWwAAHZsAACKbAAAp2wAAKhsAAC6 bAAAu2wAANNsAADUbAAA7WwAAO5sAAAEbQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEEAAAFAAAPhKAFXoSgBQAcBG0AAAVtAAAfbQAAIG0AAD5tAAA/bQAAU20AAFRtAABp bQAAam0AAJBtAACRbQAAtm0AALdtAADUbQAA/W0AABRuAAAVbgAAM24AAFhuAABZbgAAZW4AAGZu AACsbgAA6G4AACdvAABlbwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAAAAAA AAAAAAAA4wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAA AO8AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAACQAAD4TQAhGE0AJehNACYITQAgAJAAAPhKAFEYTQ Al6EoAVghNACAAUAAA+EoAVehKAFABplbwAAoG8AALlvAAC6bwAA028AANRvAAAOcAAAN3AAAFdw AAB3cAAAl3AAALdwAADXcAAA93AAACFxAABOcQAAbnEAAIdxAACocQAA5HEAAAxyAAAdcgAALnIA AD9yAABAcgAAEXMAABJzAACUcwAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA6wAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAPhHAIXoRwCAABAAAAAQcA AAkAAA+EoAURhNACXoSgBWCE0AIAG5RzAADfcwAA9nMAAPdzAABCdAAA4HQAAPp0AAD7dAAAs3YA AC53AAAvdwAAc3cAAMJ3AAAOeAAAWHgAAKJ4AADmeAAALXkAAHh5AADFeQAA73kAAPB5AAA3egAA ZHoAAGV6AACJegAArHoAANN6AAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAD4SgBRGE0AJe hKAFYITQAgAFAAAPhHAIXoRwCAAb03oAAPx6AAAmewAASHsAAEl7AACUewAA33sAABB8AAASfAAA IXwAACJ8AACDfQAAfX8AAH5/AACPfwAAkH8AAN1/AAA1gAAANoAAAE6AAABvgAAAj4AAANKAAAAe gQAAZ4EAAIyBAADCgQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAA AAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAACiYAC0YKAAUAAAomAAtG CQAAAQgAAAUAAA+EcAhehHAIABrCgQAA7YEAAAOCAAAUggAAFYIAAFqCAACxggAAwIIAAMGCAADw ggAA8YIAAB+DAAAggwAASoMAAEuDAACBgwAAgoMAAJSDAACVgwAAvoMAAL+DAADngwAA9IMAADGE AAAyhAAAX4QAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOgAAAAAAAAA AAAAAADiAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA 4AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAA AAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAA AAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgA AAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAAAAAAAAAAA Bg8ADcYGAuAQwCEAAAEBAAAFAAAPhNACXoTQAgABAAAFAAAKJgALRgsAAAUAAA+EQAtehEALAAkA AA+E0AIRhNACXoTQAmCE0AIAGV+EAABghAAAhYQAAIaEAAC4hAAAuYQAAPGEAADyhAAAHIUAAB2F AAAzhQAANIUAAFWFAABohQAAdoUAAHeFAACHhQAAiIUAAJGFAACShQAAm4UAAJyFAAABhgAAAoYA ACmGAABRhgAAZoYAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADjAAAA AAAAAAAAAAAAAAAAAAAAAAAFAAAKJgALRg0AAAUAAA+E0AJehNACAAkAAA+E0AIRhNACXoTQAmCE 0AIFAAAKJgALRgwAAAEAAAAaZoYAAHuGAACVhgAAxYYAAMaGAADNhgAA0YYAANWGAADvhgAAC4cA ABqHAAAbhwAAoIcAAKGHAACihwAAo4cAAKaHAACnhwAAqIcAAKuHAACthwAArocAALGHAACyhwAA s4cAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAA AAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANUAAAAAAAAA AAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAABGE0AJghNAC AAkAAA+EcAgRhGD6XoRwCGCEYPoABQAAD4RwCF6EcAgABQAAD4TQAl6E0AIAAQAABQAACiYAC0YO AAABBwAFAAAKJgALRg0AABizhwAAtIcAALWHAAC2hwAAt4cAALiHAAC8hwAAvocAAL+HAADAhwAA wocAAMOHAADFhwAAyIcAAMqHAADMhwAA0YcAANaHAADXhwAA2IcAAOGHAADihwAA44cAAO+HAADw hwAA8YcAAPKHAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAIDwAYhPz/GYQBABsmYCMkAgAFAAARhNACYITQAgAF AAAPhHAIXoRwCAABAAAAGvKHAADzhwAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAABIAAxkGgBH7DQLyCw4D0hsKAFIrA4BCOQoAUkkKAFJbAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAUABIACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBt AGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBDIAAUABAAIAMgAMAAkASABlAGEA ZABpAG4AZwAgADEAAAAIAAEABiQBQCYABgA1CIFcCIE4AAIAAQACADgADAAJAEgAZQBhAGQAaQBu AGcAIAAyAAAADgACAAMkAQYkAUAmAWEkAQYANQiBXAiBNgADQAEAAgA2AAwACQBIAGUAYQBkAGkA bgBnACAAMwAAAA4AAwADJAEGJAFAJgJhJAEEAENKJAA6AARAAQACADoADAAJAEgAZQBhAGQAaQBu AGcAIAA0AAAAEAAEAAYkAQ+EoAVAJgNehKAFBgA1CIFcCIFCAAVAAQACAEIADAAJAEgAZQBhAGQA aQBuAGcAIAA1AAAAGAAFAAYkAQ+EcAgRhGD6QCYEXoRwCGCEYPoGADUIgVwIgUIABkABAAIAQgAM AAkASABlAGEAZABpAG4AZwAgADYAAAAYAAYABiQBD4RwCBGEMP1AJgVehHAIYIQw/QYANQiBXAiB QgAHQAEAAgBCAAwACQBIAGUAYQBkAGkAbgBnACAANwAAABgABwAGJAEPhNACEYTQAkAmBl6E0AJg hNACBgA1CIFcCIE6AAhAAQACADoADAAJAEgAZQBhAGQAaQBuAGcAIAA4AAAAEAAIAAYkAQ+EcAhA JgdehHAIBgA1CIFcCIEAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwBy AGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAsACBAAQDyACwADAAGAEYAbwBvAHQAZQByAAAA DQAPAA3GCAAC4BDAIQECAAAAJgApQKIAAQEmAAwACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAA AEQAQwABABIBRAAMABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4AZABlAG4AdAAAABIAEQAPhHAI EYSs+V6EcAhghKz5AAAAAAAA84MAAAQAAMQAAAAA/////wAAAAABAAAAAgAAAAMAAAA2AAAAXgAA AHUAAACcAAAAnQAAAJ4AAACxAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA 2QAAANoAAADbAAAA3AAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2 AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAAAAkBAAAaAQAAGwEAABwBAAAsAQAAdQEAAKgB AACpAQAAXQIAAIoDAACRBAAAkgQAAOoHAADrBwAALgkAAC8JAADXCwAA9AsAAPULAAA/DAAAegwA AHsMAAAODQAAQg0AAEMNAAAPDgAAEA4AACwOAAAtDgAAoQ8AAKIPAADCDwAAARAAAC0QAABWEAAA jBAAANMQAAAUEQAAFhEAAG0RAAAYEgAAGRIAANkSAADaEgAAMBMAAKkTAACrEwAAxxMAAMgTAADd FQAA3hUAABIWAAAvFgAAdxYAALgWAAADFwAAPRcAAFEXAABkFwAAphcAANAXAADRFwAAGhgAAEMY AABsGAAAmBgAAL8YAADaGAAA/BgAAEcZAACQGQAA4BkAAJYaAACwGgAA6BoAAOkaAAAbGwAAUxsA AI0bAADMGwAAERwAABMcAADFHQAAxh0AAMcdAACzIAAAmiEAAJshAADtJAAA7iQAAOUmAADmJgAA NicAAJMnAACEKAAAhigAAJooAACbKAAA9SgAAFcpAACvKwAAECwAAB4sAAAsLAAAPiwAAEssAABa LAAAWywAAA8tAAAiLQAAQi0AAGMtAAB+LQAAmC0AALMtAADQLQAA6y0AAAguAAAlLgAARC4AAGEu AAB+LgAAmS4AALYuAADVLgAA8i4AABEvAAAvLwAATi8AAE8vAABoLwAAgy8AAIQvAAA0MAAANTAA AEcwAABIMAAAWjAAAKQwAAD0MAAASzEAAFIzAACjMwAA/DMAAFc0AACQNAAA3DQAAG41AABwNQAA gTUAANI1AAAxNgAARDYAAFw2AABzNgAAiDYAAKE2AAC9NgAAzzYAAOs2AADyNgAACzcAAC44AABI OAAAZDgAAH44AACLOAAArTgAANk4AAAUOQAATzkAAIs5AACiOQAA1DkAANc5AACJOgAAsToAALI6 AABjPQAAZD0AALc9AAD/PQAA0D4AANE+AAAfPwAAbT8AALU/AAC7PwAAvD8AAA1AAAAvQQAAfUEA AIhBAACJQQAAdEIAAHVCAAC+QgAABEMAAEtDAABMQwAAUUQAAFJEAABTRAAAokQAAOhEAAAuRQAA ckUAALRFAAD9RQAAeUYAAHpGAAB7RgAAHEgAAB1IAAAeSAAAZUgAAKZIAAAeSgAAIEoAACFKAABq SgAA90oAADhLAAA5SwAAOksAAIxLAABeTAAA0UwAANNMAACWTgAA51AAAK1SAACuUgAA9VIAAD1T AAB+UwAAxVMAAA9UAACvVAAA+VQAAD1VAADRVQAAGFYAAGRWAAD6VgAARFcAAJNXAADcVwAA3lcA APJXAADzVwAAHlgAAB9YAABAWAAAQVgAAF9YAABvWAAAcFgAAIxYAACeWAAAn1gAALxYAADRWAAA 0lgAAPBYAAAPWQAAJ1kAAChZAAA+WQAAW1kAAFxZAACDWQAAk1kAAJRZAAC8WQAAz1kAANBZAAD4 WQAAFloAABdaAAA8WgAAYFoAAGFaAAB/WgAAl1oAAKtaAACsWgAAzloAAOpaAADrWgAAFVsAADJb AAA0WwAAVlsAAGpbAABrWwAAlVsAAKlbAACqWwAAylsAAN5bAADfWwAAAVwAABVcAAAWXAAAQVwA AFVcAABWXAAAeVwAAI9cAACQXAAAuVwAAM1cAADOXAAA91wAAA1dAAAOXQAAH10AACBdAAA2XQAA N10AAFNdAABUXQAAb10AAIJdAACDXQAAnV0AALBdAACxXQAAyV0AAN1dAADfXQAAcl4AAL1eAADo XgAA6V4AAPReAAAHXwAAbF8AAG1fAACAXwAAgV8AAJJfAADHXwAAAmAAADdgAABbYAAAXWAAAG9g AACmYAAA4GAAABVhAAA7YQAAPGEAAFRhAACVYQAAzGEAAPJhAADzYQAADGIAAE5iAACFYgAAq2IA AKxiAADGYgAA+2IAADZjAAB0YwAAtmMAAO1jAAATZAAAFWQAADBkAABmZAAApmQAAOJkAAAnZQAA WGUAAFllAACGZQAAh2UAAJxlAACfZQAAymUAAM1lAADpZQAA6mUAAAZmAAAHZgAAJmYAACdmAAA5 ZgAAUWYAAFJmAABiZgAAeGYAAHlmAACKZgAAoWYAAKJmAAC1ZgAAzmYAAN5mAADfZgAA7WYAAO5m AAD6ZgAA+2YAABtnAAAyZwAANGcAAE1nAABOZwAAXWcAAF5nAAB0ZwAAdWcAAIpnAACLZwAAxWcA AMZnAADXZwAA2GcAAOxnAADtZwAAAmgAABpoAAAbaAAALGgAAERoAABFaAAAXWgAAHVoAAB2aAAA imgAAKdoAACoaAAAumgAALtoAADTaAAA1GgAAO1oAADuaAAABGkAAAVpAAAfaQAAIGkAAD5pAAA/ aQAAU2kAAFRpAABpaQAAamkAAJBpAACRaQAAtmkAALdpAADUaQAA/WkAABRqAAAVagAAM2oAAFhq AABZagAAZWoAAGZqAACsagAA6GoAACdrAABlawAAoGsAALlrAAC6awAA02sAANRrAAAObAAAN2wA AFdsAAB3bAAAl2wAALdsAADXbAAA92wAACFtAABObQAAbm0AAIdtAACobQAA5G0AAAxuAAAdbgAA Lm4AAD9uAABAbgAAEW8AABJvAACUbwAA328AAPZvAAD3bwAAQnAAAOBwAAD6cAAA+3AAALNyAAAu cwAAL3MAAHNzAADCcwAADnQAAFh0AACidAAA5nQAAC11AAB4dQAAxXUAAO91AADwdQAAN3YAAGR2 AABldgAAiXYAAKx2AADTdgAA/HYAACZ3AABIdwAASXcAAJR3AADfdwAAEHgAABJ4AAAheAAAIngA AIN5AAB9ewAAfnsAAI97AACQewAA3XsAADV8AAA2fAAATnwAAG98AACPfAAA0nwAAB59AABnfQAA jH0AAMJ9AADtfQAAA34AABR+AAAVfgAAWn4AALF+AADAfgAAwX4AAPB+AADxfgAAH38AACB/AABK fwAAS38AAIF/AACCfwAAlH8AAJV/AAC+fwAAv38AAOd/AAD0fwAAMYAAADKAAABfgAAAYIAAAIWA AACGgAAAuIAAALmAAADxgAAA8oAAAByBAAAdgQAAM4EAADSBAABVgQAAaIEAAHaBAAB3gQAAh4EA AIiBAACRgQAAkoEAAJuBAACcgQAAAYIAAAKCAAApggAAUYIAAGaCAAB7ggAAlYIAAMWCAADGggAA zYIAANGCAADVggAA74IAAAuDAAAagwAAG4MAAKCDAAChgwAAooMAAKODAACmgwAAp4MAAKiDAACr gwAArYMAAK6DAACxgwAAsoMAALODAAC0gwAAtYMAALaDAAC3gwAAuIMAALyDAAC+gwAAv4MAAMCD AADCgwAAw4MAAMWDAADIgwAAyoMAAMyDAADRgwAA1oMAANeDAADYgwAA44MAAO+DAADwgwAA9IMA AApAAAABMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAAJhAAAAAMAAAAAAAAACAAAAAAAhA AAABMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAA MAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAA AAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAA AACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACA AwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAA AJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACAAwAAAJhA AAAAMAAAAAAAAACAAwAAAChAAAADMAAAAAAAAACAAwAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAyAAMAAAAAAAAACA3AAAAJhAAyAAMAEAAAAAAACA3AAAAJhAAyAAMAIAAAAAAACA3AAA AJhAAyAAMAMAAAAAAACA3AAAAJhAAyAAMAQAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhABCAAMAAAAAAAAACA3AAAAJhABCAAMAEAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAA AACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA 3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAA AJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAJhA AAAAMAAAAAAAAACA3AAAAJhAAAAAMAAAAAAAAACA3AAAAEhAAAAFMAAAAAAAAACA3AAAAJhAAAAA MAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAA AAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAA AACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA 3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcA AJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhA AAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAA MAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAA AAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAA AACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA 3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcA AJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhA AAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAA MAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAA AAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAA AACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA 3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcA AJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhA AAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAA MAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAA AAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAA AACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACA 3lcAAFhAAAAGMAAAAAAAAACA3lcAAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0A AJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhA AAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAA MAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAA AAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAA AACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACA Dl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACADl0A AJhAAAAAMAAAAAAAAACADl0AAGhAAAAHMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACAbV8AAJhA AAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAA MAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAA AAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAA AACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACA bV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8A AJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhA AAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAA MAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAA AAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAA AACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACA bV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8A AJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhAAAAAMAAAAAAAAACAbV8AAJhA AAAAMAAAAAAAAACAbV8AAGhAAAAHMAAAAAAAAACADl0AAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAA MAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAA AAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAA AACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACA h2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UA AJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhA AAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAA MAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAA AAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAA AACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACA h2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UA AJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhA AAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAAJhAAAAA MAAAAAAAAACAh2UAAJhAAAAAMAAAAAAAAACAh2UAADhAAAAEMAAAAAAAAACA3AAAAJhAAAAAMAAA AAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAA AACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA 2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcA AJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhA AAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAA MAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAA AAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAA AACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA 2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcA AJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhA AAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAA MAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAA AAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAA AACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA 2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACA2GcA AJhAAAAAMAAAAAAAAACA2GcAAGhAAAAHMAAAAAAAAACA2GcAAJhAAAAAMAAAAAAAAACAumsAAJhA AAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAA MAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAA AAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAA AACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACA umsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsA AJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhA AAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAA MAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAA AAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAA AACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACA umsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsA AJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhA AAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAA MAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAA AAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAA AACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACA umsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsA AJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhA AAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAJhAAAAA MAAAAAAAAACAumsAAJhAAAAAMAAAAAAAAACAumsAAHhAAAAIMAAAAAAAAACAumsAAJhAAAAAMAAA AAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhAAAAAMAAAAAAA AACAfnsAAJhACSAAMAAAAAAAAACAfnsAAJhACiAAMAAAAAAAAACAfnsAAJhACiAAMAEAAAAAAACA fnsAAJhACiAAMAIAAAAAAACAfnsAAJhACiAAMAMAAAAAAACAfnsAAJhACiAAMAQAAAAAAACAfnsA AJhACiAAMAUAAAAAAACAfnsAAJhACiAAMAYAAAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhA AAAAMAAAAAAAAACAfnsAAJhACyAAMAAAAAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhAAAAA MAAAAAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhAAAAAMAAAAAAAAACAfnsAAJhAAAAAMAAA AAAAAACAfnsAAAhAAAABMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAwX4AAJhAAAAPMAAAAAAA AACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACA wX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4A AJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhA AAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAA MAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAA AAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAA AACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACA wX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4A AJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhA AAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAA MAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAA AAAAAACAwX4AAJhADCAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhAAAAAMAAAAAAA AACAwX4AAJhAAAAAMAAAAAAAAACAwX4AAJhADSAAMAAAAAAAAACAwX4AAJhADSAAMAEAAAAAAACA wX4AAJhADSAAMAIAAAAAAACAwX4AAJhADSAAMAMAAAAAAACAwX4AAJhADSAAMAQAAAAAAACAwX4A AGhAAAAHMAAAAAAAAACAwX4AAJhADiAAMAAAAAAAAACAxoIAAJhADiAAMAEAAAAAAACAxoIAAJhA DiAAMAIAAAAAAACAxoIAAJhADiAAMAMAAAAAAACAxoIAAJhADiAAMAQAAAAAAACAxoIAAJhAAAAA MAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAA AAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAA AACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACA AAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAA gJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhA AAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAA MAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAA AAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAA AACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACA AAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAAgJhAAAAAMAAAAAAAAACAAAAA gJhAAAAAMAAAAAAAAACAAAAAgJpAAAAAMAAAAAAAAACAAAAAgJhAAAAPMAAAAAAAAACAAAAAgJhA AAAPMAAAAAAAAACAAAAAgAoAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAsAAAAZAAAAGQAAABkAAAAcAAAAAAQAAPOHAABFAAAAAAQAAPAEAAAuDQAA GBYAAPwcAACTKwAAfjIAAG45AACJPgAAUkgAANNQAABAXAAAF14AAEFgAAC9YgAATmYAAAZqAAB0 awAABG0AAGVvAACUcwAA03oAAMKBAABfhAAAZoYAALOHAADyhwAA84cAAEYAAABIAAAASQAAAEoA AABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAA AFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAAAEAADyhwAARwAAAAAAAAAHAAAA CwAAABIAAAAVAAAAHAAAABMhlQATIdT/lYAAAAAAdQEAAH0BAAAtCAAANQgAAI4NAACXDQAAoA0A AKkNAABpEAAAbhAAAKsQAACzEAAA7xwAAPccAAAdHQAAJh0AAIQdAACUHQAAuR0AAMMdAADPHQAA 2h0AAKEeAACkHgAA2x4AAN8eAAD+IAAAASEAAI4kAACWJAAAyyQAANEkAAAvJQAANSUAAKcwAACr MAAAnzUAAKk1AAB6NgAAfjYAAIA4AACEOAAApDkAAKs5AADmOgAA5zoAAOs6AADCOwAAzTsAAEY8 AABQPAAAKD4AACw+AADqPgAA9T4AAKxAAACuQAAAsUAAALxAAAC9QAAAwUAAAEJBAABGQQAAakMA AHNDAAB+QwAAfEQAAIBEAAAxRwAAPEcAAF5HAABpRwAA10cAANtHAADjSwAA50sAAKJRAACqUQAA BVYAAApWAACuVwAAslcAAJlYAACdWAAAvVgAAMFYAACQWQAAklkAAL1ZAAC/WQAAl1oAAJtaAADS WgAA1loAABlbAAAdWwAAZVsAAGlbAACkWwAAqFsAANlbAADdWwAAEFwAABRcAABQXAAAVFwAAGJc AABmXAAAilwAAI5cAADIXAAAzFwAAAhdAAAMXQAAY10AAGddAACSXQAAll0AALVdAAC5XQAAuF4A ALxeAADYXgAA3F4AAJdfAACbXwAAyF8AAM5fAAAuYAAAMmAAAHRgAAB4YAAAp2AAAK1gAAAMYQAA EGEAAFlhAABdYQAAw2EAAMdhAAARYgAAFWIAAHxiAACAYgAAy2IAAM9iAAD8YgAAAmMAAGNjAABn YwAA5GMAAOhjAAA1ZAAAOWQAALdkAAC7ZAAAKmUAAC5lAABDZwAAR2cAAFhnAABcZwAAEGkAABRp AAAraQAAL2kAANZrAADZawAA6XAAAOxwAAD9cQAAAHIAAFF1AABUdQAALHYAADZ2AAD9dgAABHcA ACx3AAAwdwAAcHcAAHp3AADmdwAA6XcAAC57AAAxewAAoHsAAKJ7AACmfAAAsXwAAPF8AAD8fAAA 4oAAAOmAAABCgQAAQ4EAAE6BAAA2ggAAPYIAAF2CAABkggAA14MAANiDAADggwAA44MAAO6DAADx gwAA9IMAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAcAAcAHAAH ABwABwAHABwABwAHABwABwAcAAcABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAHABwABwAcAAcAHAAHAAcA HAAHABwABwAcAAcAAgAHAAcABwAHAAIAAAAAAHUAAACEAAAAlgAAAJwAAACxAAAAsgAAANAAAAB1 AQAApwEAAKgBAABdAgAAXwIAABQDAAAcAwAATAMAAPwDAAD/AwAAVAQAAFcEAADIBAAAzwQAAAYF AAANBQAArgUAAO4FAACBBgAAiQYAAJkGAAA/DAAAQgwAAHoMAAAODQAAQQ0AAEINAABDDQAASg0A AG0NAAAPDgAAbREAALgRAAC6EQAAGRIAAEASAABLEgAAhBIAADATAAA5EwAASRMAAH4UAACXFAAA oxQAAMgUAAB3FgAAoBYAAKcWAAC4FgAAZBcAAKQXAAClFwAApxcAAK8XAADQFwAA/BgAAAYZAAAf GQAARxkAAOAZAADiGQAAIBoAAMwbAADcGwAA5BsAAOcbAABZHQAAjh0AAJQdAADFHQAAsyAAAN4g AAAgIQAAZyEAANkiAABzIwAAeiMAAPgjAAA2JwAAUycAAFUnAACbKAAAsCgAALEoAAD1KAAAPCkA AD4pAABXKQAAWykAAPQpAAD5LwAAMzAAADQwAACkMAAA0jAAANgwAADbMAAA9DAAAPUwAAD8MAAA NDEAAEsxAABNMQAAyTEAANcxAACzMgAAtTIAANEyAACjMwAApTMAAMkzAAD8MwAAAzQAAFc0AABa NAAAkTQAANM0AADVNAAA2zQAANw0AADnNAAAHDUAAIE1AADLNQAA0TUAANI1AADUNQAA6jUAAM82 AADkNgAA6jYAAOs2AAAUOQAAGTkAAB85AAA7OQAATzkAAFQ5AABWOQAAcTkAAIs5AACQOQAAkzkA AKI5AAAtOgAAbToAAG86AACJOgAARzsAAEw7AABTOwAA3zsAALc8AADEPAAADj0AABc9AAC6PQAA vD0AAP89AAADPgAA6j4AAPs+AABvPwAAfT8AABFAAAAYQAAAL0EAADpBAAB9QQAAh0EAADVCAAA6 QgAAikIAAJdCAAC/QgAAwkIAAAVDAAALQwAANUMAAEpDAADFRAAAxkQAAC9FAAAyRQAAc0UAAHlF AABXRwAAXUcAAMZHAADIRwAAKEgAADRIAAAGSQAADkkAAFtKAABiSgAAa0oAAPZKAABGSwAATUsA AI1LAACVSwAA+0sAAARMAACVTAAAo0wAAJhOAACaTgAA604AAO9OAAAUTwAAIU8AALhPAAC+TwAA xVAAANBQAADxUAAA9lAAAHFRAAByUQAA9lIAAPlSAAA+UwAARFMAAH9TAACNUwAA5lMAAOhTAAAQ VAAAE1QAAD5VAABDVQAA0lUAANRVAABRVgAAWVYAAGVWAABrVgAABlcAAAtXAABFVwAASFcAAJRX AACeVwAA+FkAAPpZAADPWgAA0VoAAHRgAAB8YAAAdWMAAHdjAAC3YwAAuWMAAKZkAACvZAAA4mQA AOdkAAAnZQAAKWUAAMBoAADJaAAA2GgAAOJoAADyaQAA+2kAAK1qAAC+agAA6GoAAPNqAAAOawAA D2sAACdrAAAsawAAoGsAAKJrAABibgAAam4AADxvAABEbwAAlG8AALlvAADgcAAA5HAAAOJxAADv cQAADnQAAD90AACidAAAqXQAAOZ0AAAFdQAALXUAAEt1AAB4dQAAfXUAAMV1AADPdQAAlHcAAJd3 AADfdwAA4XcAAIN5AACPeQAAkHsAAMl7AADdewAANHwAAPx8AAAFfQAAZn4AAJB+AACxfgAAs34A AAmAAAAVgAAAPoAAAEWAAABqgAAAcYAAAMqAAADRgAAA1oAAANyAAABegQAAZoEAAC+CAAA1ggAA 14MAANiDAADggwAA44MAAO6DAADxgwAA9IMAAAcABwAzAAcABwAzAAcABwAzAAcABwAzAAcAMwAH AAcABwAzAAcABwAzAAcAMwAHAAcABwAzAAcABwAzAAcABwAzAAcABwAHADMABwAHADMABwAHAAcA MwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHADMABwAHAAcAMwAHAAcAMwAHAAcABwAz AAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAzAAcABwAHADMABwAzAAcABwAzAAcABwAzAAcA BwAHADMABwAHAAcAMwAHAAcAMwAHADMABwAzAAcABwAzAAcABwAzAAcAMwAHADMABwAzAAcAMwAH AAcABwAzAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcAMwAHAAcABwAzAAcABwAHADMABwAHAAcA MwAHAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAQABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHAAIABwAHAAcABwACAAAAAACgewAAonsAAJuCAACcggAAxIIAAMyCAADN ggAAzYIAAAuDAACfgwAA14MAANiDAADggwAA44MAAO6DAAD0gwAAAwAEAAMABAADAAQAAwAEAAMA BAADAAIABwACAAcAAgD//xQAAAAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQBy AHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEQATwBDADEALgBkAG8A YwAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBlAHkASABDADoAXABX AEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIA bwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAg AG8AZgAgAEQATwBDADEALgBhAHMAZAAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgA YQByAHQAbgBlAHkASABDADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBu ACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMA bwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEQATwBDADEALgBhAHMAZAAWAFIAaQBjAGgAYQBy AGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8AYwB1AG0A ZQBuAHQAcwBcAEQATwBDADEALgBkAG8AYwAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAg AEgAYQByAHQAbgBlAHkASABDADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkA bwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBl AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEQATwBDADEALgBhAHMAZAAWAFIAaQBjAGgA YQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAEQATwBDADEALgBkAG8AYwAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4A ZQAgAEgAYQByAHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEQATwBD ADEALgBkAG8AYwAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBlAHkA GABDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEQATwBDADEALgBkAG8AYwAWAFIAaQBj AGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8A YwB1AG0AZQBuAHQAcwBcAEQATwBDADEALgBkAG8AYwAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBl AG4AZQAgAEgAYQByAHQAbgBlAHkAGABDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEQA TwBDADEALgBkAG8AYwAOAGdYagUeA3Br/w//D/8P/w//D/8P/w//D/8PEACER/IF/P7Es/8P/w// D/8P/w//D/8P/w//DxAAPizZCKx/Qhz/D/8P/w//D/8P/w//D/8P/w8QAOIouxP0Uh47/w//D/8P /w//D/8P/w//D/8PEACsdnYk9pWED/8P/w//D/8P/w//D/8P/w//DwAAp1LELjqMzDP/D/8P/w// D/8P/w//D/8P/w8AAO4BqC/Kt3J3/w//D/8P/w//D/8P/w//D/8PEADoPug1Tmemf/8P/w//D/8P /w//D/8P/w//DxAAMETcN2IpKBD/D/8P/w//D/8P/w//D/8P/w8QALRsUzwmb/hd/w//D/8P/w// D/8P/w//D/8PEABJDdI/Aq+CG/8P/w//D/8P/w//D/8P/w//DxAAKl5rSeDNHBn/D/8P/w//D/8P /w//D/8P/w8QADdAvFni3yTk/w//D/8P/w//D/8P/w//D/8PEACdTZVhtpxcEv8P/w//D/8P/w// D/8P/w//DxAAAQAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJ YISY/m8oAAMAKAAAACkAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EqAwRhJj+FcYFAAGo DAZehKgMYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHgPEYRM/xXGBQAB eA8GXoR4D2CETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RIEhGEmP4VxgUA AUgSBl6ESBJghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EGBURhJj+FcYF AAEYFQZehBgVYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOgXEYRM/xXG BQAB6BcGXoToF2CETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S4GhGEmP4V xgUAAbgaBl6EuBpghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EiB0RhJj+ FcYFAAGIHQZehIgdYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFggEYRM /xXGBQABWCAGXoRYIGCETP8CAAgALgABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QIBxGE mP4VxgUAAQgHBl6ECAdghJj+bygAAwAoAAAAKQABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgA AA+EqAwRhEz/FcYFAAGoDAZehKgMYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAY AAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EGBURhEz/FcYFAAEYFQZehBgVYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4S4GhGEmP4VxgUAAbgaBl6EuBpghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EiB0RhEz/FcYFAAGIHQZehIgdYIRM/wIACAAuAAEAAAAAAAIAAAAAAAAAAAAAAAAA AAAAAAMYAAAPhKAFEYQw/RXGBQABoAUGXoSgBWCEMP1vKAADACgAAAApAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP4CAAEALgABAAAAAoIBAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4TYCRGETP8VxgUAAdgJBl6E2AlghEz/AgACAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/gIAAwAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP4CAAQALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RIEhGETP8VxgUAAUgSBl6ESBJghEz/AgAFAC4AAQAAAACAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/gIABgAuAAEAAAAEgAEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP4CAAcALgABAAAAAoIB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S4GhGETP8VxgUAAbgaBl6EuBpghEz/AgAIAC4AAgAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAAuAAEA AAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgAB AAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4A AQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAu AAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQA LgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAF AC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIA BgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4C AAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/ AgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAABhgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw /TUIAG8oAAMAAAAuADAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAABhgAAA+EoAURhDD9FcYFAAGg BQZehKAFYIQw/TUIAG8oAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAABhgAAA+EcAgR hDD9FcYFAAFwCAZehHAIYIQw/TUIAG8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAA AAAAAAYYAAAPhEALEYQw/RXGBQABQAsGXoRAC2CEMP01CABvKAAHAAAALgABAC4AAgAuAAMAAQAA AAAAAQMFBwkAAAAAAAAAAAAAAAAABhgAAA+EeA8RhMj7FcYFAAF4DwZehHgPYITI+zUIAG8oAAkA AAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAABhgAAA+ESBIRhMj7FcYF AAFIEgZehEgSYITI+zUIAG8oAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0A AAAAAAAAAAAAAAYYAAAPhIAWEYRg+hXGBQABgBYGXoSAFmCEYPo1CABvKAANAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAABhgAAA+EUBkRhGD6FcYFAAFQ GQZehFAZYIRg+jUIAG8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMF BwkLDQ8RAAAAAAAAAAAABhgAAA+EiB0RhPj4FcYFAAGIHQZehIgdYIT4+DUIAG8oABEAAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAcAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAP hGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKAADAAAALgAwAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAA AAMYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5vKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAA AAAAAAAAAAMYAAAPhHAIEYQw/RXGBQABcAgGXoRwCGCEMP1vKAAFAAAALgABAC4AAgABAAAAAAAB AwUHAAAAAAAAAAAAAAAAAAADGAAAD4RACxGEMP0VxgUAAUALBl6EQAtghDD9bygABwAAAC4AAQAu AAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhHgPEYTI+xXGBQABeA8GXoR4D2CE yPtvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhEgS EYTI+xXGBQABSBIGXoRIEmCEyPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUH CQsNAAAAAAAAAAAAAAADGAAAD4SAFhGEYPoVxgUAAYAWBl6EgBZghGD6bygADQAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhFAZEYRg+hXGBQAB UBkGXoRQGWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJ Cw0PEQAAAAAAAAAAAAMYAAAPhIgdEYT4+BXGBQABiB0GXoSIHWCE+PhvKAARAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAABAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QIBxGE mP4VxgUAAQgHBl6ECAdghJj+bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E 2AkRhJj+FcYFAAHYCQZehNgJYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP hKgMEYRM/xXGBQABqAwGXoSoDGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgA AA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAY AAAPhBgVEYRM/xXGBQABGBUGXoQYFWCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhIgdEYRM/xXGBQABiB0GXoSIHWCETP8CAAgALgAJAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAA AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACggEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgAJAAAAAAABAAAA AAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAAC4AAQAAAASA AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAAC ggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAA AASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEA AAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgAB AAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4A AQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAu AAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgA LgAHAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+bygA AgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY /gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHgPEYRM/xXGBQABeA8GXoR4D2CE TP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJg hJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EGBURhJj+FcYFAAEYFQZehBgV YISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOgXEYRM/xXGBQAB6BcGXoTo F2CETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S4GhGEmP4VxgUAAbgaBl6E uBpghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EiB0RhJj+FcYFAAGIHQZe hIgdYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFggEYRM/xXGBQABWCAG XoRYIGCETP8CAAgALgABAAAABAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QIBxGEmP4VxgUAAQgH Bl6ECAdghJj+bygAAgAAAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E2AkRhJj+FcYF AAHYCQZehNgJYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKgMEYRM/xXG BQABqAwGXoSoDGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4R4DxGEmP4V xgUAAXgPBl6EeA9ghJj+AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+ESBIRhJj+ FcYFAAFIEgZehEgSYISY/gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBgVEYRM /xXGBQABGBUGXoQYFWCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4ToFxGE mP4VxgUAAegXBl6E6BdghJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EuBoR hJj+FcYFAAG4GgZehLgaYISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIgd EYRM/xXGBQABiB0GXoSIHWCETP8CAAgALgABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAADGAAAD4Tu AhGEev4VxgUAAe4CBl6E7gJghHr+bygAAwAoAAAAKQABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAA AAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAA AAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAA AAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAkAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAACAAAALgABAAAABIABAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIAB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKC AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAMAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAACAAAALgAB AAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4A AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAu AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMA LgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAE AC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIA BQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4C AAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+ AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM /wIACAAuAA4AAADiKLsTAAAAAAAAAAAAAAAAnU2VYQAAAAAAAAAAAAAAAIRH8gUAAAAAAAAAAAAA AABnWGoFAAAAAAAAAAAAAAAA6D7oNQAAAAAAAAAAAAAAADdAvFkAAAAAAAAAAAAAAAAwRNw3AAAA AAAAAAAAAAAAtGxTPAAAAAAAAAAAAAAAAKdSxC4AAAAAAAAAAAAAAAA+LNkIAAAAAAAAAAAAAAAA rHZ2JAAAAAAAAAAAAAAAACpea0kAAAAAAAAAAAAAAABJDdI/AAAAAAAAAAAAAAAA7gGoLwAAAAAA AAAAAAAAAP////////////////////////////////////////////////////////////////// //////////8OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//DgAAABIAyDeMFhkACQQb AAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgB4D04TGQAJBBsACQQPAAkEGQAJBBsACQQPAAkE GQAJBBsACQQSACReLr4ZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQb AAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEAAAAABIAiNhWoRkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAHgpY4BkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgCcq0QAGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAOK1mnwZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQT/QAIQAAAA AAAAAPODAABAAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8B AAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAA AAAAAAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUB AgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAIC AgICBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAACIABAAxCIgYAPDQAgAAaAEA AAAACkFIRuphSMbXYUjGZwCFBwAAEhMAALZsAAABADcAAAAEAAMQ5wAAAAAAAAAAAAAAAQABAAAA AQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0AIGBEjAAABAA GQBkAAAAGQAAAIGFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAyg1EA8BAACAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAMAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIABFAFIASQBOACAARwBSAEUARQBOAEUAIAAmACAAQQBTAFMATwBDAEkA QQBUAEUAUwAAAAAAAAAWAFIAaQBjAGgAYQByAGQAIABFAHUAZwBlAG4AZQAgAEgAYQByAHQAbgBl AHkAFgBSAGkAYwBoAGEAcgBkACAARQB1AGcAZQBuAGUAIABIAGEAcgB0AG4AZQB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA AMgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADcAAAABAAAAOgAAAAFAAAACAEAAAYAAAAUAQAA BwAAACABAAAIAAAAMAEAAAkAAABQAQAAEgAAAFwBAAAKAAAAeAEAAAsAAACEAQAADAAAAJABAAAN AAAAnAEAAA4AAACoAQAADwAAALABAAAQAAAAuAEAABMAAADAAQAAAgAAAOQEAAAeAAAAMQAAACAg ICAgICAgICAgICAgICAgICAgICAgIEVSSU4gR1JFRU5FICYgQVNTT0NJQVRFUwBlbmUeAAAAAQAA AAAgICAeAAAAFwAAAFJpY2hhcmQgRXVnZW5lIEhhcnRuZXkAIB4AAAABAAAAAGljaB4AAAABAAAA AGljaB4AAAAHAAAATm9ybWFsACAeAAAAFwAAAFJpY2hhcmQgRXVnZW5lIEhhcnRuZXkAIB4AAAAE AAAAMTAzAB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAG5AAAAAAF5d6wwBAABAAAAAAGq1DVgE wAFAAAAAAKTWbRgBwAFAAAAAAJwztVoEwAEDAAAAAQAAAAMAAAASEwAAAwAAALZsAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAAwAQAADAAA AAEAAABoAAAADwAAAHAAAAAFAAAAlAAAAAYAAACcAAAAEQAAAKQAAAAXAAAArAAAAAsAAAC0AAAA EAAAALwAAAATAAAAxAAAABYAAADMAAAADQAAANQAAAAMAAAAEQEAAAIAAADkBAAAHgAAABkAAABF cmluIEdyZWVuZSAmIEFzc29jaWF0ZXMAACAAAwAAAOcAAAADAAAANwAAAAMAAACBhQAAAwAAAKAK CQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAMQAAACAgICAgICAgICAg ICAgICAgICAgICAgIEVSSU4gR1JFRU5FICYgQVNTT0NJQVRFUwAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAt AAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsA AAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAA AEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAA WAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAAD+////ZAAAAGUAAABm AAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQA AAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAA AIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAA kQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACf AAAA/v///6EAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAAD+////qQAAAKoAAACrAAAArAAAAK0A AACuAAAArwAAAP7////9/////f///7MAAAD+/////v////7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////1IAbwBvAHQA IABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAACA3WcVaBMABtQAAAIAA AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABjAAAArHgAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAixAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAAQAAAAAAAABQBEAG8AYwB1 AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAAAABAA AAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAgN1nFWgTAASA3WcVaBMABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////wEA/v8DCgAA//// /wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERv YwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0005_01C00430.F05AD5C0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00568 for ; Tue, 15 Aug 2000 09:45:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:52 +0200 (MEST) Received: (qmail 16911 invoked by uid 0); 13 Aug 2000 15:50:28 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 13 Aug 2000 15:50:28 -0000 X-eGroups-Return: sentto-1101623-607-966181801-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 13 Aug 2000 15:50:02 -0000 Received: (qmail 32462 invoked from network); 13 Aug 2000 15:50:00 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 13 Aug 2000 15:50:00 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (205.152.0.91) by mta1 with SMTP; 13 Aug 2000 15:50:00 -0000 Received: from 0018728164 (host-209-215-24-97.bix.bellsouth.net [209.215.24.97]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id LAA18463; Sun, 13 Aug 2000 11:49:57 -0400 (EDT) Message-ID: <000801c0053e$17ed1ae0$6118d7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 10:49:04 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] System Overview Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C00514.18FD1D60" X-UIDL: fdf863c9c7d65c0ec3f35b17dd0775d1 Status: R X-Status: N ------=_NextPart_000_0005_01C00514.18FD1D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After making indicated changes required - "logic errors" - also made change= s to the Index Register such that LDA/LDX can be programmed; ran the design= thru Place and Route with the following results: Usable PLD Gates 60,000 Logic Cells 1573 of 1584 Clock Only Cells 3 of 8 Cell FF's 945 of 1584 Pad FF's 32 of 316 Bi-Directional Cells 308 of 308 Routing Resources 44031 of 102916 Via Link Resources 38538 of 27622290 Instruction count is reduced to 7445, where now a good conversational numbe= r is 7000. AND keep in mind - the above is for a SINGLE Instruction Pipeline= . Each additional level will present a new SET of problems and in some cases, tota= lly destroy what you achieved in the previous. Super Pipeline is a nice ac= ronym but you must take care in getting there. In my case - where the Processor perf= ormance will meet system objectives - this is where I STOP. At this point,= all I can do is be my own "Devil's Advocate" and critique the design as is= ; untill I receive the Eclipse development software. Have a good week-end. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C00514.18FD1D60 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
After making indicated changes required - "logic errors" - also made changes to the Index Register such that LDA/LDX can be programmed; ran the design thru Place and Route with the following results:
            Usable PLD Gates              60,000
            Logic Cells                     1573 of 1584
            Clock Only Cells                  3 of 8
            Cell FF's                          945 of 1584
            Pad FF's                            32 of 316
            Bi-Directional Cells            308 of 308
            Routing Resources        44031 of 102916
            Via Link Resources        38538 of 27622290
 
Instruction count is reduced to 7445, where now a good conversational number
is 7000.  AND keep in mind - the above is for a SINGLE Instruction Pipeline.  Each
additional level will present a new SET of problems and in some cases, totally destroy what you achieved in the previous.  Super Pipeline is a nice acronym but
you must take care in getting there.  In my case - where the Processor performance will meet system objectives - this is where I STOP.  At this point, all I can do is be my own "Devil's Advocate" and critique the design as is; untill I receive the Eclipse development software.  Have a good week-end.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_0005_01C00514.18FD1D60-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00574 for ; Tue, 15 Aug 2000 09:45:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:55 +0200 (MEST) Received: (qmail 16845 invoked by uid 0); 13 Aug 2000 19:21:33 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 13 Aug 2000 19:21:33 -0000 X-eGroups-Return: sentto-1101623-608-966194489-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 13 Aug 2000 19:21:29 -0000 Received: (qmail 15484 invoked from network); 13 Aug 2000 19:21:28 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Aug 2000 19:21:28 -0000 Received: from unknown (HELO mail5.primary.net) (216.87.38.199) by mta1 with SMTP; 13 Aug 2000 19:21:28 -0000 Received: from [192.168.1.40] (ip148-tc3.busprod.com [207.150.72.148]) by mail5.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e7DJEwq11386 for ; Sun, 13 Aug 2000 14:15:01 -0500 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 14:22:28 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GNL project Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab32c3fa25a0c393ad1daa25f60fcc21 Status: R X-Status: N
Someone mentioned working on the "GNL project". Is that a GNL that is more
relevant to f-cpu than
  GNL's Not Lao
  _TaoDeChing_ by Lao Tze
  http://www.chinapage.org/gnl.html
?

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00577 for ; Tue, 15 Aug 2000 09:45:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:45:55 +0200 (MEST) Received: (qmail 17537 invoked by uid 0); 13 Aug 2000 19:35:38 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 13 Aug 2000 19:35:38 -0000 X-eGroups-Return: sentto-1101623-609-966195331-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 13 Aug 2000 19:35:31 -0000 Received: (qmail 16378 invoked from network); 13 Aug 2000 19:35:30 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 13 Aug 2000 19:35:30 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 13 Aug 2000 19:35:30 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA31448 for f-cpu@egroups.com; Sun, 13 Aug 2000 15:35:29 -0400 Message-Id: <200008131935.PAA31448@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: from "David Cary" at Aug 13, 2000 02:22:28 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 15:35:29 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GNL project Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a66e30943f03d1947c33c18a9692cb54 Status: R X-Status: N >
>
> Someone mentioned working on the "GNL project". Is that a GNL that is more
> relevant to f-cpu than
>   GNL's Not Lao
>   _TaoDeChing_ by Lao Tze
>   http://www.chinapage.org/gnl.html
> ?
>
Venezuelan liquified natural gas ('proyecto gnl')? :-)


Graham
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00598 for ; Tue, 15 Aug 2000 09:46:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:46:01 +0200 (MEST) Received: (qmail 32756 invoked by uid 0); 14 Aug 2000 03:53:47 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 14 Aug 2000 03:53:47 -0000 X-eGroups-Return: sentto-1101623-610-966225221-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 14 Aug 2000 03:53:45 -0000 Received: (qmail 7053 invoked from network); 14 Aug 2000 03:53:41 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 14 Aug 2000 03:53:41 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta1 with SMTP; 14 Aug 2000 03:53:40 -0000 Received: from [192.168.1.40] (ip148-tc3.busprod.com [207.150.72.148]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e7E3l8U15410 for ; Sun, 13 Aug 2000 22:47:10 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <396CBCBA.9229C4E0@nventure.com> References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 22:54:48 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] putting design ideas online Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 75210d366fa47255575ef8b06baff728 Status: R X-Status: N
Dear Albert Abramson,

If you emailed me your documents (<1 MB at a time), I'd be happy to put
them online in my "mirror/" directory.

But I think you'd be much happier creating your own web site. Check out
  http://www.rdrop.com/~cary/html/get_online.html
for a list of places that give away free server space.

You might consider putting identical copies of your web pages on several
machines, so it is still accessible even when one machine goes offline.

Please post the URI to f-cpu@egroups.com wherever you put those documents.

>From: Albert Abramson <maxx@nventure.com>
>Date: Wed, 12 Jul 2000 11:45:15 -0700
>Reply-To: f-cpu@egroups.com
>Subject: Re: [f-cpu] unsubscribers, rationale
...
>Does anyone have a site I can post the results to?
...
>--Maxx

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00601 for ; Tue, 15 Aug 2000 09:46:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:46:03 +0200 (MEST) Received: (qmail 8954 invoked by uid 0); 14 Aug 2000 04:19:33 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 14 Aug 2000 04:19:33 -0000 X-eGroups-Return: sentto-1101623-611-966226768-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 14 Aug 2000 04:19:30 -0000 Received: (qmail 31783 invoked from network); 14 Aug 2000 04:19:27 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 14 Aug 2000 04:19:27 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta1 with SMTP; 14 Aug 2000 04:19:27 -0000 Received: from [192.168.1.40] (ip148-tc3.busprod.com [207.150.72.148]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e7E4CtU30805 for ; Sun, 13 Aug 2000 23:12:57 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <396D9E3B.91CF0B87@nventure.com> References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> <396D7F7E.5F459EA9@welfen-netz.com> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 23:20:35 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW 64 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2746751a54f3ff251cf08f398cf463f Status: R X-Status: N
>From: Albert Abramson <maxx@nventure.com>
>Date: Thu, 13 Jul 2000 03:47:32 -0700
...
>Each op field then looks like this:
>op    4
>rD    4
>rA    4
>rB    4
...
>-Since there are separate address and data registers, and global and local
>sets,

I think I understand what you're going to do with the "local" registers
(replicate a independent, seperate set for each task in SMT, to switch
between during stalls). I'm not so sure I understand what you're going to
do with the "global" registers. Would it make any sense to have, say, 14
local registers and 2 global registers ? or make 3 of the data registers
global, and all the other (data and address) registers local ?

>we gain access to a total of 32 registers.

I think I'm missing something obvious here. To access 1 of 32 registers,
you have 5 bits of selection. Are you saying that there are enough
instructions that *only* apply to addresses, and enough other instructions
that *only* apply to data, that specifying the (4 bit) opcode implies a lot
of these bits ?

...
>hey, Kai, maybe we should just split off on this VLIW/xRISC thing and see
>what comes of it... eh?  I know I could have something done in VLIW in
>less time it has taken to get "permission"
...

Excellent idea. Go ahead and *do* the parts you find interesting that you
can hack out quickly.

Then ask us for help on the hard / less interesting bits, and also help the
rest of us on our hard / less interesting bits.

I think it's a *good* thing to have multiple designs going in parallel.
(You can see "my" instruction set on my website -- it's really quite ugly).

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00604 for ; Tue, 15 Aug 2000 09:46:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 Aug 2000 09:46:04 +0200 (MEST) Received: (qmail 28389 invoked by uid 0); 14 Aug 2000 05:06:42 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 14 Aug 2000 05:06:42 -0000 X-eGroups-Return: sentto-1101623-612-966229588-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 14 Aug 2000 05:06:39 -0000 Received: (qmail 26849 invoked from network); 14 Aug 2000 05:06:20 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 14 Aug 2000 05:06:20 -0000 Received: from unknown (HELO femail3.sdc1.sfba.home.com) (24.0.95.83) by mta1 with SMTP; 14 Aug 2000 05:06:20 -0000 Received: from nventure.com ([24.10.43.202]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000814050554.BABS8672.femail3.sdc1.sfba.home.com@nventure.com> for ; Sun, 13 Aug 2000 22:05:54 -0700 Message-ID: <39977E4C.8E2474CF@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <39681EBE.10217@bjsmtp1.163.net> <396A11E3.D0B561FA@nventure.com> <396B2ACA.571457AE@f-cpu.org> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 13 Aug 2000 22:06:24 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] putting design ideas online Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0f9f8646407e824490062d413f874cfd Status: R X-Status: N Oops.  I haven't been paying too much attention to this list recently.  The
VLIW64 idea has been slowly marinading in my mind, but no new details yet,
just trying to push the limits of what is possible.

Let me know if there's anything specific you want, though.

--Maxx

David Cary wrote:

> Dear Albert Abramson,
>
> If you emailed me your documents (<1 MB at a time), I'd be happy to put
> them online in my "mirror/" directory.
>
> But I think you'd be much happier creating your own web site. Check out
>   http://www.rdrop.com/~cary/html/get_online.html
> for a list of places that give away free server space.
>
> You might consider putting identical copies of your web pages on several
> machines, so it is still accessible even when one machine goes offline.
>
> Please post the URI to f-cpu@egroups.com wherever you put those documents.
>
> >From: Albert Abramson <maxx@nventure.com>
> >Date: Wed, 12 Jul 2000 11:45:15 -0700
> >Reply-To: f-cpu@egroups.com
> >Subject: Re: [f-cpu] unsubscribers, rationale
> ...
> >Does anyone have a site I can post the results to?
> ...
> >--Maxx
>
> --
> David Cary "mailto:d.cary@ieee.org" ><> <*> O-
>   http://www.rdrop.com/~cary/
> "icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
>
>

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA00401 for ; Wed, 16 Aug 2000 11:12:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 Aug 2000 11:12:33 +0200 (MEST) Received: (qmail 814 invoked by uid 0); 16 Aug 2000 05:35:23 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 16 Aug 2000 05:35:23 -0000 X-eGroups-Return: sentto-1101623-613-966404118-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 16 Aug 2000 05:35:21 -0000 Received: (qmail 20366 invoked from network); 16 Aug 2000 05:35:17 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Aug 2000 05:35:17 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 16 Aug 2000 05:35:17 -0000 Received: from f-cpu.org (nas2-231.ras.club-internet.fr [195.36.192.231]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA29792 for ; Wed, 16 Aug 2000 07:35:14 +0200 (MET DST) Message-ID: <399A2809.3C3EB25F@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 Aug 2000 07:35:05 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] index.html updated a bit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 51a72eae07ea39c4871db22bfae76e6c Status: R X-Status: N hello,
i took some minutes to update the "gateway" at f-cpu.org
and include the latest comments, mainly about the manual and
the licence discussion with G. Seaman.

btw, look at what's going on at the opencollector.org site :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA00446 for ; Wed, 16 Aug 2000 11:12:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 Aug 2000 11:12:43 +0200 (MEST) Received: (qmail 17469 invoked by uid 0); 16 Aug 2000 08:04:42 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 16 Aug 2000 08:04:42 -0000 X-eGroups-Return: sentto-1101623-614-966413074-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 16 Aug 2000 08:04:35 -0000 Received: (qmail 11881 invoked from network); 16 Aug 2000 08:04:32 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 16 Aug 2000 08:04:32 -0000 Received: from unknown (HELO mis-interscan.masterlink.com.tw) (203.69.92.66) by mta1 with SMTP; 16 Aug 2000 08:04:32 -0000 Received: from mis-interscan.masterlink.com.tw ([192.168.4.14]) by mis-interscan.masterlink.com.tw with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 16 Aug 2000 15:57:58 +0800 Received: from 192.168.4.10 by mis-interscan.masterlink.com.tw (InterScan E-Mail VirusWall NT); Wed, 16 Aug 2000 15:57:56 +0800 Received: from mis-interscan.masterlink.com.tw ([192.168.4.14]) by email.masterlink.com.tw (Netscape Messaging Server 3.5) with SMTP id 310; Wed, 16 Aug 2000 15:56:44 +0800 Received: from 168.191.92.26 by mis-interscan.masterlink.com.tw (InterScan E-Mail VirusWall NT); Wed, 16 Aug 2000 15:57:45 +0800 Message-ID: <00006de70cd4$000071b5$00002faa@chat.ru> To: Undisclosed.Recipients@masterlink.com.tw X-Priority: 3 X-MSMail-Priority: Normal Errors-To: undel_03@yahoo.com X-Mailer: Microsoft Outlook Express 5.00.2919.6600 From: kkiju@home.ro MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 Aug 2000 04:03:37 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Looking for a Great Home Based Business? 12202 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-UIDL: b98617ce2f54e7e39247de13f01fffdf Status: R X-Status: N I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! 1-800-533-9350 (Free, 24 hour, 2 minute recorded message) DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" - Walt Disney To be removed from future mailings, send an email to: Not_OK_03@yahoo.com and type "Remove" in the subject line. Tired of the 40 X 40 X 40 Plan? You know: Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! Is working for a "boss" too demeaning and unrewarding? Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future? If you're determined to retire in the next 2 - 5 years with enough income to have REAL Financial Independence and Freedom, and are not afraid to work for it, I can help you. --------------------------------------------------------------------- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00314 for ; Thu, 17 Aug 2000 13:28:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:30 +0200 (MEST) Received: (qmail 16490 invoked by uid 0); 17 Aug 2000 03:31:28 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 17 Aug 2000 03:31:28 -0000 X-eGroups-Return: sentto-1101623-615-966483083-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 17 Aug 2000 03:31:26 -0000 Received: (qmail 5927 invoked from network); 17 Aug 2000 03:31:22 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 17 Aug 2000 03:31:22 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 17 Aug 2000 03:31:22 -0000 Received: from f-cpu.org (nas2-218.ras.club-internet.fr [195.36.192.218]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA20626 for ; Thu, 17 Aug 2000 05:31:19 +0200 (MET DST) Message-ID: <399B5C81.8E27EAA4@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 05:31:13 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] french brochure Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3b318ba3522275f2485144dc2da978d8 Status: R X-Status: N hello,
i added a "brochure" section to the f-cpu.de website.
the french version is ready and will soon be translated
(if we have enough time). This is the kind of document
that is to be used during presentations, in showcases
or conferences, simply because it is lighter than the
whole manual :-) (6 sheets, or 12 pages)
HTML source as well as PDF and PS are provided.
english and german versions should be done.

see http://www.f-cpu.de/brochure/ (ugly page, will be changed)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00320 for ; Thu, 17 Aug 2000 13:28:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:31 +0200 (MEST) Received: (qmail 21699 invoked by uid 0); 17 Aug 2000 05:14:01 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 17 Aug 2000 05:14:01 -0000 X-eGroups-Return: sentto-1101623-616-966489236-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 17 Aug 2000 05:13:58 -0000 Received: (qmail 29823 invoked from network); 17 Aug 2000 05:13:55 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Aug 2000 05:13:55 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 17 Aug 2000 05:13:55 -0000 Received: from f-cpu.org (nas1-145.ras.club-internet.fr [195.36.192.145]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA20107 for ; Thu, 17 Aug 2000 07:13:52 +0200 (MET DST) Message-ID: <399B7485.86DC7563@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 07:13:41 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fcf8b4db7b5da263e02cf25c779b61cb Status: R X-Status: N hello,

when i tried to use IDDASS (which Nate uses) it failed
because it requires a LISP machine behind. So i'm browsing
through the opencollector.org site and i ask people (here, you !)
to review some of the tools that would/could help us design
the f-cpu easily.

here are some posibilities.
requirements : MUST BE PURE GPL, should be functional and working,
VHDL recommended, easy to use, take almost no disk space and CPU time,
be nice with the user...

Camille
            &nb= sp;            Camil= le is an open-source clone
            &nb= sp;            of th= e Mentor Graphics=AE tool Renoir=99.
[yum !]

NGPaint
            &nb= sp;            NGPai= nt arose out of discussions on how
            &nb= sp;            to po= st schematics to newsgroups using
            &nb= sp;            minim= al bandwidth.
[could this be used here ?]

VHDL-GUI
            &nb= sp;            A gra= phical tool for capturing, drawing,
            &nb= sp;            editi= ng, and navigating hierarchical
            &nb= sp;            block= -diagrams, and for producing
            &nb= sp;            corre= sponding structural VHDL code.
[wow !]

FreeHDL
            &nb= sp;            The p= roject goals are to develop a VHDL
            &nb= sp;            simul= ator that:
            &nb= sp;            Has a= graphical waveform viewer;
            &nb= sp;            has a= source level debugger;
            &nb= sp;            is VH= DL-93 compliant;
            &nb= sp;            is of= commercial quality.
[does THAT exist ?]

PICA
            &nb= sp;            VHDL = compiler and simulator from the University of Pittsburg.

Savant
            &nb= sp;            Savan= t is an extensible VHDL 93 analyzer/simulator
            &nb= sp;            suppo= rting parallel simulation across a variety
            &nb= sp;            of ha= rdware platforms.

vhdl2c
            &nb= sp;            vhdl2= c is a vhdl to `C' converter by Michael
            &nb= sp;            Knies= er, based on Thomas Dettmer's
            &nb= sp;            yacc = grammar for VHDL.

Vaul
            &nb= sp;            VAUL,= a VHDL frontend that wants to be
            &nb= sp;            compl= ete, correct and flexible.


reviews and remarks about these as well as others are needed on this list.<= BR> let's not reinvent the wheel, right ? ;-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: ht= tp://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00350 for ; Thu, 17 Aug 2000 13:28:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:38 +0200 (MEST) Received: (qmail 8428 invoked by uid 0); 17 Aug 2000 07:57:42 -0000 Received: from c3.egroups.com (208.50.99.225) by mx12.rz2.gmx.net with SMTP; 17 Aug 2000 07:57:42 -0000 X-eGroups-Return: sentto-1101623-617-966499058-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 17 Aug 2000 07:57:38 -0000 Received: (qmail 24647 invoked from network); 17 Aug 2000 07:57:37 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Aug 2000 07:57:37 -0000 Received: from unknown (HELO web1103.mail.yahoo.com) (128.11.23.123) by mta1 with SMTP; 17 Aug 2000 07:57:37 -0000 Received: (qmail 15565 invoked by uid 60001); 17 Aug 2000 07:57:37 -0000 Message-ID: <20000817075737.15564.qmail@web1103.mail.yahoo.com> Received: from [199.203.98.250] by web1103.mail.yahoo.com; Thu, 17 Aug 2000 00:57:36 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 00:57:36 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 8ea94ed0d47ed37b965ce85b04eff0ad Status: R X-Status: N May be you can visit the OpenTech cdrom page that has lot of OpenSource tools and Openhw designs. you may look at the table of contents and/or order the cdrom. The new release is about to be ready (may be tomorrow) http://www.opencores.org/OIPC/projects/OpenTech Regards Jamil Khatib --- Yann Guidon wrote: > hello, > > when i tried to use IDDASS (which Nate uses) it > failed > because it requires a LISP machine behind. So i'm > browsing > through the opencollector.org site and i ask people > (here, you !) > to review some of the tools that would/could help us > design > the f-cpu easily. > > here are some posibilities. > requirements : MUST BE PURE GPL, should be > functional and working, > VHDL recommended, easy to use, take almost no disk > space and CPU time, > be nice with the user... > > Camille > Camille is an open-source > clone > of the Mentor Graphics® > tool Renoir™. > [yum !] > > NGPaint > NGPaint arose out of > discussions on how > to post schematics to > newsgroups using > minimal bandwidth. > [could this be used here ?] > > VHDL-GUI > A graphical tool for > capturing, drawing, > editing, and navigating > hierarchical > block-diagrams, and for > producing > corresponding structural > VHDL code. > [wow !] > > FreeHDL > The project goals are to > develop a VHDL > simulator that: > Has a graphical waveform > viewer; > has a source level > debugger; > is VHDL-93 compliant; > is of commercial quality. > [does THAT exist ?] > > PICA > VHDL compiler and simulator > from the University of Pittsburg. > > Savant > Savant is an extensible > VHDL 93 analyzer/simulator > supporting parallel > simulation across a variety > of hardware platforms. > > vhdl2c > vhdl2c is a vhdl to `C' > converter by Michael > Knieser, based on Thomas > Dettmer's > yacc grammar for VHDL. > > Vaul > VAUL, a VHDL frontend that > wants to be > complete, correct and > flexible. > > > reviews and remarks about these as well as others > are needed on this list. > let's not reinvent the wheel, right ? ;-) > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > the F-CPU: > http://www.mime.univ-paris8.fr/~whygee/f-cpu.html > SHARCPAGE: > http://www.mime.univ-paris8.fr/~whygee/sharcpage.html > > > > > __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ --------------------------------------------------------------------- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00353 for ; Thu, 17 Aug 2000 13:28:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:38 +0200 (MEST) Received: (qmail 362 invoked by uid 0); 17 Aug 2000 08:14:45 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 17 Aug 2000 08:14:45 -0000 X-eGroups-Return: sentto-1101623-618-966500083-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 17 Aug 2000 08:14:44 -0000 Received: (qmail 8532 invoked from network); 17 Aug 2000 08:14:42 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 17 Aug 2000 08:14:42 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 17 Aug 2000 08:14:42 -0000 Received: from f-cpu.org (nas4-173.aub.club-internet.fr [195.36.145.173]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA05773 for ; Thu, 17 Aug 2000 10:14:39 +0200 (MET DST) Message-ID: <399B9EE6.5B8940A8@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 10:14:30 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ef6ecf47cdf20f70821757d9e2ad9406 Status: R X-Status: N hi,
VGUI (Vhdl GUI) http://www.atl.lmco.com/rassp/vgui looks cool;
but it does only one simple thing : the architecture, not
the behaviour or the simulation. A good start and VHDL structure
editor anyway (300KB only under Windows).
Anyway, VGUI is not under GPL. it's not under development
apparently, and no source is available. It can only
be used for some prototype "hacking".

Electric and Savant should follow.
I can't d/l PICA, i don't know why.
Camille, gEDA and FreeHDL are not ready.

we need a VHDL behavioural simulator :
Electric and/or Savant would do the trick
if i can test them.

when the behaviour is OK, Electric and/or Alliance
could be used for the CMOS/SiO2 process part.

i'm expecting more, but that's a start.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00356 for ; Thu, 17 Aug 2000 13:28:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:39 +0200 (MEST) Received: (qmail 19636 invoked by uid 0); 17 Aug 2000 08:19:13 -0000 Received: from ck.egroups.com (208.50.144.69) by mx19.rz2.gmx.net with SMTP; 17 Aug 2000 08:19:13 -0000 X-eGroups-Return: sentto-1101623-619-966500350-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 17 Aug 2000 08:19:10 -0000 Received: (qmail 26435 invoked from network); 17 Aug 2000 08:19:09 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Aug 2000 08:19:09 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 17 Aug 2000 08:19:08 -0000 Received: from f-cpu.org (nas4-173.aub.club-internet.fr [195.36.145.173]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA06999 for ; Thu, 17 Aug 2000 10:19:06 +0200 (MET DST) Message-ID: <399B9FF1.30C8E428@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000817075737.15564.qmail@web1103.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 10:18:57 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 610c60598a4e81d774f10b54d30bc522 Status: R X-Status: N hello,

Jamil Khatib wrote:
> May be you can visit the OpenTech cdrom page that has
> lot of OpenSource tools and Openhw designs.
>
> you may look at the table of contents and/or order the
> cdrom.
>
> The new release is about to be ready (may be tomorrow)
>
> http://www.opencores.org/OIPC/projects/OpenTech

sorry, my ISP's DNS seems to be down.
the mail works anyway.

read you soon,

> Regards
> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00359 for ; Thu, 17 Aug 2000 13:28:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:40 +0200 (MEST) Received: (qmail 7713 invoked by uid 0); 17 Aug 2000 08:21:46 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 17 Aug 2000 08:21:46 -0000 X-eGroups-Return: sentto-1101623-620-966500503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 17 Aug 2000 08:21:44 -0000 Received: (qmail 8510 invoked from network); 17 Aug 2000 08:21:43 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 17 Aug 2000 08:21:43 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 17 Aug 2000 08:21:43 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA06307 for f-cpu@egroups.com; Thu, 17 Aug 2000 04:21:42 -0400 Message-Id: <200008170821.EAA06307@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <399B7485.86DC7563@f-cpu.org> from "Yann Guidon" at Aug 17, 2000 07:13:41 AM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 04:21:42 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 99bd76159592a568bbb3303a20b79ebb Status: R X-Status: N Hi

I haven't used more than a small proportion of these, but have a
little idea of the current state of some of them. If I get any
of these wrong I hope the authors will complain and correct it!
> here are some posibilities.
> requirements : MUST BE PURE GPL, should be functional and working,
> VHDL recommended, easy to use, take almost no disk space and CPU time,=
> be nice with the user...
>
> Camille
>            = ;            &n= bsp; Camille is an open-source clone
>            = ;            &n= bsp; of the Mentor Graphics=AE tool Renoir=99.
Camille does not yet have ANY code available, AFAIK - not even in cvs.
> [yum !]
>
> NGPaint
>            = ;            &n= bsp; NGPaint arose out of discussions on how
>            = ;            &n= bsp; to post schematics to newsgroups using
>            = ;            &n= bsp; minimal bandwidth.
It's meant for small diagrams, not large ones. Its not gpl.

>
> VHDL-GUI
>            = ;            &n= bsp; A graphical tool for capturing, drawing,
>            = ;            &n= bsp; editing, and navigating hierarchical
>            = ;            &n= bsp; block-diagrams, and for producing
>            = ;            &n= bsp; corresponding structural VHDL code.
I've been told this is good. But it is binary only (the one exception
to the rule on open collector..)

>
> FreeHDL
>            = ;            &n= bsp; The project goals are to develop a VHDL
>            = ;            &n= bsp; simulator that:
>            = ;            &n= bsp; Has a graphical waveform viewer;
>            = ;            &n= bsp; has a source level debugger;
>            = ;            &n= bsp; is VHDL-93 compliant;
>            = ;            &n= bsp; is of commercial quality.
Yes, but still in early stages. Savant does something similar to the goals<= BR> of FreeHDL, and is much further along.

>
> PICA
>            = ;            &n= bsp; VHDL compiler and simulator from the University of Pittsburg.
>
> Savant
>            = ;            &n= bsp; Savant is an extensible VHDL 93 analyzer/simulator
>            = ;            &n= bsp; supporting parallel simulation across a variety
>            = ;            &n= bsp; of hardware platforms.
If you want to do VHDL simulation (not synthesis) with full coverage of
the language, Savant is currently the only way to go with free
(lgpl) software. But you don't (yet) get all the 'nice' gui environment
you'd have with a commerical simulator.
>
> vhdl2c
>            = ;            &n= bsp; vhdl2c is a vhdl to `C' converter by Michael
>            = ;            &n= bsp; Knieser, based on Thomas Dettmer's
>            = ;            &n= bsp; yacc grammar for VHDL.
>
> Vaul
>            = ;            &n= bsp; VAUL, a VHDL frontend that wants to be
>            = ;            &n= bsp; complete, correct and flexible.
>
I believe this is now merged in with FreeHDL.

>
> reviews and remarks about these as well as others are needed on this l= ist.
> let's not reinvent the wheel, right ? ;-)
The most relevant ones aren't mentioned: gEDA for schematic entry,
and Icarus. Icarus is a Verilog based system. In general, free tools
using Verilog are further along than ones using VHDL. Icarus can do
synthesis (meaning net list generation, in this case). Both gEDA (gschem in particular) and Icarus are already being used for real designs, though <= BR> they are also still being developed very fast. I'm assuming you're
running Unix though - if you want Windows, you may have to do a lot
of porting work yourself.
Conclusion: for VHDL use Savant, for Verilog use Icarus. But don't
expect much more than bare text output. There are some nice waveform
viewers around for Verilog Change Dump files, though.

Graham
>

3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00371 for ; Thu, 17 Aug 2000 13:28:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:43 +0200 (MEST) Received: (qmail 24148 invoked by uid 0); 17 Aug 2000 08:30:54 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 17 Aug 2000 08:30:54 -0000 X-eGroups-Return: sentto-1101623-621-966501051-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 17 Aug 2000 08:30:53 -0000 Received: (qmail 19974 invoked from network); 17 Aug 2000 08:30:51 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 17 Aug 2000 08:30:51 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 17 Aug 2000 08:30:51 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA06379 for f-cpu@egroups.com; Thu, 17 Aug 2000 04:30:50 -0400 Message-Id: <200008170830.EAA06379@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <399B9EE6.5B8940A8@f-cpu.org> from "Yann Guidon" at Aug 17, 2000 10:14:30 AM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 04:30:50 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db7de237de99cdf0d4047b367a0828c3 Status: R X-Status: N >
> hi,
> VGUI (Vhdl GUI) http://www.atl.lmco.com/rassp/vgui looks cool;
> but it does only one simple thing : the architecture, not
> the behaviour or the simulation. A good start and VHDL structure
> editor anyway (300KB only under Windows).
> Anyway, VGUI is not under GPL. it's not under development
> apparently, and no source is available. It can only
> be used for some prototype "hacking".
>
> Electric and Savant should follow.
> I can't d/l PICA, i don't know why.
> Camille, gEDA and FreeHDL are not ready.
>
> we need a VHDL behavioural simulator :
> Electric and/or Savant would do the trick
> if i can test them.
I believe that Electric is more oriented to IC design,
where Savant is purely a simulation engine. For high-level
behavioural simulation (first pass at the design) Savant
might be better; for actual IC design, Electric.
Last time I looked, Alliance supported a very limited
subset of VHDL so wasn't so suitable for simulation.

>
> when the behaviour is OK, Electric and/or Alliance
> could be used for the CMOS/SiO2 process part.
Magic is alive and well, too.
>
Graham
Don't just travel. Travel right.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00389 for ; Thu, 17 Aug 2000 13:28:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 Aug 2000 13:28:47 +0200 (MEST) Received: (qmail 5639 invoked by uid 0); 17 Aug 2000 10:40:22 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 17 Aug 2000 10:40:22 -0000 X-eGroups-Return: sentto-1101623-622-966508816-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 17 Aug 2000 10:40:20 -0000 Received: (qmail 6308 invoked from network); 17 Aug 2000 10:40:15 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 17 Aug 2000 10:40:15 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 17 Aug 2000 10:40:14 -0000 Received: from f-cpu.org (nas4-97.ras.club-internet.fr [195.36.203.97]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA07407 for ; Thu, 17 Aug 2000 12:40:04 +0200 (MET DST) Message-ID: <399BC0F8.5C4D666D@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 12:39:52 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vgui Content-Type: multipart/mixed; boundary="------------397731E92267EA0F0D46E440" X-UIDL: bbf2d4a4257a7634258f7d2194fb0e5e Status: R X-Status: N --------------397731E92267EA0F0D46E440 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello again,
vgui seems to be a fun and simple stuff.

it didn't take that long to make a first top-level diagram of the FC0
and generate some VHDL output. i have enclosed some files like the
".dia" diagram file (that the SW reads and writes because VHDL or VERILOG
don't memorize the box coordinates) and a VHDL output. a screenshot is
also here. it's not perfect but worth the download, i spared some VHDL
headaches ;-P with this structure, we have to "fill the holes" of the
behaviour, then simulate and debug, but the debug deals with the behaviour,
almost never with the structure.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
--------------397731E92267EA0F0D46E440 Content-Type: text/plain; charset=us-ascii; name="ess-fc0-3.dia" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ess-fc0-3.dia" Version 1.000000 DEFINE_MODULE: EU_shuffler_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: EU_increment_findfirst_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: LSU_buffer_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: load_store_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: top_level DEFINE_DEVICE_INSTANCES: I_CACHE = r_cache_type | 2.100000 -0.800000 8.500000 3.200000 FETCHER = fetcher_type | 2.100000 5.600000 8.500000 8.100000 DECODER = decoder_type | 3.600000 10.100000 11.100000 13.100000 SCHEDULER = scheduler_type | 2.000000 16.200001 7.600000 18.000000 R7 = register_set_type | 2.500000 21.500000 11.100000 27.999998 XBAR = xbar_type | -2.900000 16.300001 1.000000 30.600000 IMU = EU_int_mul_type | -13.000000 19.200001 -7.100000 21.100000 ASU = EU_add_sub_type | -13.000000 16.200001 -7.100000 18.100002 ROP2_COMBINE = EU_rop2_type | -12.900001 27.799997 -7.000000 29.699999 D_CACHE = rw_cache_type | -13.000001 -1.100000 -6.100000 3.500000 LSU = load_store_type | -12.900001 5.500000 -6.000000 8.200000 new = LSU_buffer_type | -13.000000 9.100000 -6.000000 12.700000 TLB = TLB_type | -4.300000 10.700000 0.500000 14.600000 INC_FF = EU_increment_findfirst_type | -13.000000 22.000000 -7.100000 24.000000 SHL = EU_shuffler_type | -13.000001 25.000000 -7.000000 26.900000 SR = EU_special_registers_type | -4.100000 32.099998 1.900001 33.799999 MEM_INTERFACE = memory_interface_type | -20.500002 1.700000 -15.400000 7.100000 END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: LSU _ D_CACHE _ simplex 0 Bit 0 -10.400001 3.500000 -10.400001 5.500000 D_CACHE _ LSU _ simplex 0 Bit 0 -8.700000 5.500000 -8.700000 3.500000 LSU _ new _ simplex 0 Bit 0 -10.100000 9.100000 -10.100000 8.200000 MEM_INTERFACE _ LSU _ simplex 0 Bit 0 -9.200000 5.500000 -9.200000 4.600000 -15.400000 4.600000 FETCHER _ I_CACHE _ simplex 0 Bit 0 3.600000 3.200000 3.600000 5.600000 I_CACHE _ FETCHER _ simplex 0 Bit 0 6.200000 5.600000 6.200000 3.200000 LSU _ MEM_INTERFACE _ simplex 0 Bit 0 -15.400000 5.000000 -11.200000 5.000000 -11.200000 5.500000 new _ LSU _ simplex 0 Bit 0 -8.800000 8.200000 -8.800000 9.100000 FETCHER _ DECODER _ simplex 0 Bit 0 5.700000 10.100000 5.700000 8.100000 R7 _ XBAR _ simplex 0 Bit 0 1.000000 23.799999 2.500000 23.799999 R7 _ XBAR _ simplex 0 Bit 0 1.000000 24.400000 2.500000 24.400000 R7 _ XBAR _ simplex 0 Bit 0 1.000000 25.000000 2.500000 25.000000 XBAR _ R7 _ simplex 0 Bit 0 2.500000 26.200001 1.000000 26.200001 XBAR _ R7 _ simplex 0 Bit 0 2.500000 26.799999 1.000000 26.799999 XBAR _ SR _ simplex 0 Bit 0 -1.200000 32.099998 -1.200000 30.600000 SR _ XBAR _ simplex 0 Bit 0 -0.600000 30.600000 -0.600000 32.099998 XBAR _ SR _ simplex 0 Bit 0 -1.800000 32.099998 -1.800000 30.600000 ROP2_COMBINE _ XBAR _ simplex 0 Bit 0 -2.900000 29.400000 -7.000000 29.400000 XBAR _ ROP2_COMBINE _ simplex 0 Bit 0 -7.000000 28.899998 -2.900000 28.899998 XBAR _ ROP2_COMBINE _ simplex 0 Bit 0 -7.000000 28.400000 -2.900000 28.400000 XBAR _ ROP2_COMBINE _ simplex 0 Bit 0 -7.000000 27.999998 -2.900000 27.999998 ASU _ XBAR _ simplex 0 Bit 0 -2.900000 17.000000 -7.100000 17.000000 XBAR _ ASU _ simplex 0 Bit 0 -7.100000 16.600000 -2.900000 16.600000 XBAR _ ASU _ simplex 0 Bit 0 -7.100000 17.699999 -2.900000 17.699999 ASU _ XBAR _ simplex 0 Bit 0 -2.900000 17.299999 -7.100000 17.299999 IMU _ XBAR _ simplex 0 Bit 0 -2.900000 20.600000 -7.100000 20.600000 IMU _ XBAR _ simplex 0 Bit 0 -2.900000 20.200001 -7.100000 20.200001 XBAR _ IMU _ simplex 0 Bit 0 -7.100000 19.900000 -2.900000 19.900000 XBAR _ IMU _ simplex 0 Bit 0 -7.100000 19.500000 -2.900000 19.500000 IMU _ ASU _ simplex 0 Bit 0 -9.600000 18.100002 -9.600000 19.200001 XBAR _ INC_FF _ simplex 0 Bit 0 -7.100000 22.400000 -2.900000 22.400000 XBAR _ INC_FF _ simplex 0 Bit 0 -7.100000 23.000000 -2.900000 23.000000 INC_FF _ XBAR _ simplex 0 Bit 0 -2.900000 23.699999 -7.100000 23.699999 TLB _ FETCHER _ simplex 0 Bit 0 2.100000 6.600000 -2.200000 6.600000 -2.200000 10.700000 DEV_NULL _ LSU _ simplex 0 Bit 0 -6.000000 6.600000 -2.200000 6.600000 TLB _ DECODER _ simplex 0 Bit 0 4.500000 10.100000 4.500000 9.400001 -1.800000 9.400001 -1.800000 10.700000 XBAR _ SHL _ simplex 0 Bit 0 -7.000000 26.500002 -2.900000 26.500002 XBAR _ SHL _ simplex 0 Bit 0 -7.000000 25.299999 -2.900000 25.299999 SHL _ XBAR _ simplex 0 Bit 0 -2.900000 25.900002 -7.000000 25.900002 DECODER _ R7 _ simplex 0 Bit 0 8.400001 21.500000 8.400001 13.100000 DECODER _ R7 _ simplex 0 Bit 0 9.000000 21.500000 9.000000 13.100000 DECODER _ R7 _ simplex 0 Bit 0 9.600000 21.500000 9.600000 13.100000 SCHEDULER _ XBAR _ simplex 0 Bit 0 1.000000 17.200001 2.000000 17.200001 DECODER _ SCHEDULER _ simplex 0 Bit 0 4.600000 16.200001 4.600000 13.100000 SCHEDULER _ DECODER _ simplex 0 Bit 0 5.400000 13.100000 5.400000 16.200001 ASU _ TLB _ simplex 0 Bit 0 -3.200000 14.600000 -3.200000 14.800000 -9.800000 14.800000 -9.800000 16.200001 XBAR _ TLB _ simplex 0 Bit 0 -1.800000 14.600000 -1.800000 16.300001 MEM_INTERFACE _ FETCHER _ simplex 0 Bit 0 5.200000 5.600000 5.200000 4.200000 -15.400000 4.200000 END_DEFINE_TOPOLOGY. GENERIC: CACHE_BUS_WIDTH : integer := 256 GENERIC: MEMORY_ADDRESS_BUS_WIDTH : integer := 24 GENERIC: MEMORY_DATA_BUS_WIDTH : integer := 64 GENERIC: REGISTER_WIDTH : integer := 64 END_DEFINE_MODULE. DEFINE_MODULE: register_set_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: scheduler_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: decoder_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: fetcher_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: xbar_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: EU_add_sub_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: EU_rop2_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: EU_int_mul_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: rw_cache_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: r_cache_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. DEFINE_MODULE: memory_interface_type DEFINE_DEVICE_INSTANCES: END_DEFINE_DEVICE_INSTANCES. DEFINE_TOPOLOGY: END_DEFINE_TOPOLOGY. END_DEFINE_MODULE. --------------397731E92267EA0F0D46E440 Content-Type: text/plain; charset=us-ascii; name="ess-fc0-3.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ess-fc0-3.vhdl" ---------------------------------------------------------------------------- -- VHDL EXPORT File: F:\vgui\ess-fc0-3.vhdl - ---------------------------------------------------------------------------- ENTITY memory_interface_type IS END memory_interface_type; ARCHITECTURE structure OF memory_interface_type IS BEGIN END structure; ENTITY r_cache_type IS END r_cache_type; ARCHITECTURE structure OF r_cache_type IS BEGIN END structure; ENTITY rw_cache_type IS END rw_cache_type; ARCHITECTURE structure OF rw_cache_type IS BEGIN END structure; ENTITY EU_int_mul_type IS END EU_int_mul_type; ARCHITECTURE structure OF EU_int_mul_type IS BEGIN END structure; ENTITY EU_rop2_type IS END EU_rop2_type; ARCHITECTURE structure OF EU_rop2_type IS BEGIN END structure; ENTITY EU_add_sub_type IS END EU_add_sub_type; ARCHITECTURE structure OF EU_add_sub_type IS BEGIN END structure; ENTITY xbar_type IS END xbar_type; ARCHITECTURE structure OF xbar_type IS BEGIN END structure; ENTITY fetcher_type IS END fetcher_type; ARCHITECTURE structure OF fetcher_type IS BEGIN END structure; ENTITY decoder_type IS END decoder_type; ARCHITECTURE structure OF decoder_type IS BEGIN END structure; ENTITY scheduler_type IS END scheduler_type; ARCHITECTURE structure OF scheduler_type IS BEGIN END structure; ENTITY register_set_type IS END register_set_type; ARCHITECTURE structure OF register_set_type IS BEGIN END structure; ENTITY top_level IS GENERIC( CACHE_BUS_WIDTH : integer := 256 ); GENERIC( MEMORY_ADDRESS_BUS_WIDTH : integer := 24 ); GENERIC( MEMORY_DATA_BUS_WIDTH : integer := 64 ); GENERIC( REGISTER_WIDTH : integer := 64 ); END top_level; ARCHITECTURE structure OF top_level IS SIGNAL L9 : Bit; COMPONENT r_cache_type END COMPONENT; COMPONENT fetcher_type END COMPONENT; COMPONENT decoder_type END COMPONENT; COMPONENT scheduler_type END COMPONENT; COMPONENT register_set_type END COMPONENT; COMPONENT xbar_type END COMPONENT; COMPONENT EU_int_mul_type END COMPONENT; COMPONENT EU_add_sub_type END COMPONENT; COMPONENT EU_rop2_type END COMPONENT; COMPONENT rw_cache_type END COMPONENT; COMPONENT load_store_type END COMPONENT; COMPONENT LSU_buffer_type END COMPONENT; COMPONENT TLB_type PORT( _ : OUT Bit ); END COMPONENT; COMPONENT EU_increment_findfirst_type END COMPONENT; COMPONENT EU_shuffler_type END COMPONENT; COMPONENT EU_special_registers_type PORT( _ : IN Bit ); END COMPONENT; COMPONENT memory_interface_type END COMPONENT; BEGIN I_CACHE : r_cache_type FETCHER : fetcher_type DECODER : decoder_type SCHEDULER : scheduler_type R7 : register_set_type XBAR : xbar_type IMU : EU_int_mul_type ASU : EU_add_sub_type ROP2_COMBINE : EU_rop2_type D_CACHE : rw_cache_type LSU : load_store_type new : LSU_buffer_type TLB : TLB_type PORT MAP( L9 ); INC_FF : EU_increment_findfirst_type SHL : EU_shuffler_type SR : EU_special_registers_type PORT MAP( L9 ); MEM_INTERFACE : memory_interface_type END structure; ENTITY load_store_type IS END load_store_type; ARCHITECTURE structure OF load_store_type IS BEGIN END structure; ENTITY LSU_buffer_type IS END LSU_buffer_type; ARCHITECTURE structure OF LSU_buffer_type IS BEGIN END structure; ENTITY EU_increment_findfirst_type IS END EU_increment_findfirst_type; ARCHITECTURE structure OF EU_increment_findfirst_type IS BEGIN END structure; ENTITY EU_shuffler_type IS END EU_shuffler_type; ARCHITECTURE structure OF EU_shuffler_type IS BEGIN END structure; --------------397731E92267EA0F0D46E440 Content-Type: image/gif; name="fc0-vgui-1.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fc0-vgui-1.gif" R0lGODlhdAKSAvcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8P///wAAhACc/wD/ AJSUlP8A//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAdAKSAgAI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du1wdOBiot2HfhX+JBt44GK/hw4f3ClTst3FJxh0hE0ZMuXLdvoUVSka4GWTn jJ8vhrZMuvRYzIz1quarWvHfwpJbx67YmqDsxbcZxq4NYPXq3rz5mh5O/HTv48iFQ04t3Lbz 56ALzk5OnTP0xdizT89evLt3rHvD/nPHvrx59eWyR0fcrv26dda5mQPPPf67/ftN5c8uz529 eovsIcefZu45J997+CWooFH6SUedfv45qJFr9VFoXkID9pdchAt26GFPvr0WXHqsAYfbb/PB Jhp6KNLH2YjBVQgjih/WaON9/92o4448UkRjepn1KOSQRBZp5JFIJqnkkkw26eSTUEYp5ZRU VmnllVhmqeWWXHbp5ZdghinmmGSWaeaZaKap5ppstunmm3DGKeecdNZp55145qnnnnz26eef gAYq6KCEFmrooYgmquiijDbq6KOQRirppJRWaumlmGaq6aacdurpp6CGKuqopJZq6qmoUsTA qqy26uqr/rDGKuustNZq66241prqprn26uuvwAYb7K6aCmvsscgmqyuxmCrr7LPQ+spss6wS YO212Gar7bbcduvtt+CGK+642LY67aWtkqvuuuy262645uoY7bz0Kqtouu/mq+++/F4b7431 BiywtIni2+/BCCfM7b82Duzww7LeW63CFFfcL8M1QqzxxhKvavHHILOL8YcGh2xyyCMTWvLJ LLeccocrtyzzxax2zMDMOKNcs7wT5+zzuy8LGvPPROcbtIJDF610t0cDmvTSUMO7M8A9R211 tk3/+fTVXJc7dcNVd2111n5uLTbXZNtn9tk5p83n2mxD7bZ3cMft8teG1m03/tFzd6f33jqv ajPgbPdd3N+EW2w4nognfrfgPHvs+M+L39n45CZXbtrlmNMMOaKcd6443iSHLfrJmtcZ+ukK p07a6qy36/qcsMfuOQM71m47ubPLqfvuRpPu4e/Ag9t7nMSH28DyyyvPPLbNZ8t8A9Y+b/30 0d+eu+nFty78oMkrfy313pJfPfTSo0+A+eyrr33kN3+MPbjTQ2/++M+v3/z18+t7PJzho5/7 tHU/Ag7Qfe2r2P8OE0BuFdCBAyzg/ciXwPUdUHbfExr3LDbBbj1wfBY837YqSEHvfQ5skgPZ B9PnwQuKMIQwfB/oNlixDkIQghWUXv2qlz+ELdAw/g0coQBxCEIhvrCE/Pphm4LYwiIa0YAi XCEJX3gwJd6FiSwsXwtzaL8e7nBfVlwTFp8YwyzqMH9SdOIKk5hBpNEQYWt0YhaRCEUY0tF/ bXTaGxXGxTqGcIpFBCQVwZhH/IxRjjck4A7TeMSEhVFNh+xi9sqHxv1lb5GWpB72JknIE2Zs j/2KoxzpmENSjrKTuCsYKLunwELe55D9o2T0+Ie/WWZSf7EEmiv7FElZ5pJwj6RLL4EXTDQN k5VY2+V3jsnDTQJTmXtiJjKtVUy5SJN11TTTNZGZTbhsU3TdJNM3uxdOt4wTc+UU0zmJCU2/ rXKaGPRkoda5u3SyhZ6J/rMnmPAZO32qhZ+A86eXAHo6gaKFoHYzKJcQ2jmFmoWhhWtnniA6 OYeWhaJis2iWMJpPiRKHo2jzaFA2RtJbpQSkARXp5t4Jz3VpVCQljemsTsrSlqJyeym0qQyj ItOevoqmOdXp6OQ5vJoK1Xgq/YlPl0pUmBr1qCJL6uueCtWFSbUnKHXkVSOS1YRulTJdldtX dRLWnZakrGd7qVjQWjS1goSteGxqSOAaUrm6MajfEiXFOMm3VTWAKnTVpV0/EtixjZWBLNVr DfWl2HG16q9SKWw8U3kSyYp1sIZMbM4aq8XbQZanVC3oYRvSOM6q0LQgeyz8xCVBS+b1i1/E /uUl9SdJUcL2ls5sZvPM9dmnWNalo2UI4lCrQsZqr7dFxWsi7TfIAz7wjn9EogTzWsdSlrEB vI1saMEZ3IUMN2rE9WPwBIdcmL3zg4qV4iITScHcNhGBp9wkdmtWXqb8Vl3p/FtrNdle/sYx lrEFMG1rydczsg+3AJ5evOqboLqhV3x+hK4am0tdA9rwfA/MLmiV29L81hS90kWkGcv4RxbO cpC2rW58pbczBmeWw+KlsHg1qb7p2hHFFe7ghS0oQQ1D5b68665C9EtGDJPYhbKVcCOTXOAL CpLHm2wxCuMHYd3qNcH7s3Izcall+j3XwAd+nmq1C+NperjMMSYx/o3/S0Yl3/jInU3fjmns Nci5+JWaLZ6NvzXmDVP5qGf+8xBHbOQ4FzqKJg4koRMNwjlfV8qfRPOiCRzb07p3hPtFKgPu rBQgO1bICfkupeXsZS9ar8u0TLLzZnxb5vm4dJKuqtQwixRPiyvQ6grv5PbMNPpSLday5jOo Z2LrWVPWJKVdl3x13a5lU/KMwvbraoMt2GP/eLsNHfZBit02bVsT29R2K2HBXVFvF4TbOBP3 V9A9VGv7ltyOwzW1tUprtcG7quruCLt7Xe+N7Ptx7k6uoOcd5H4X5d/bkjfBzQrrgS/c2IC9 9zMNnhGEo87c3pQ4oDHuEosnk+IY8Xjg/gJu3mQ94OQPKCnKU86xqYjcXxwXyMs/lu+uOGvl Kkc5SSMObHaC/CIzbzdOj7Xyk5MU5y0ns8M7HHMABL2VPx+OsorOco0hXWM8X/ol/Vu/rfuy vVuWL5O5bssET216Tu35wzVNcilRfSUrnyqMn2zKQS85xDG8o96hB2mBcNoiPr06sgRfUi29 XSVxt8zTXEthxlcYfzh2oQ3XOF/c/d3fPSW8sTSf9CsdPiWJr8zi+atoyDd5xCd2LhUnj+JN k7eyMqX61HXe0y2FHvQol/vSeWzHHvI+vaTmtWxrS2AWzxcAl9dI5os+e6PX3vC5h3v0RU/D NZfeyMCvsfD3/p731RPAr5a3yucxcvtDlf8k5wdi9SesYrtHF/VG3DGlw1+V8V8k/YTCP0n0 b5fFsx/RMgZ/kXdKb3Zk1AN+fkcQyScU9mcR/BcoDxgSETgXSUNLYpdqDoRJerd181NJw1dL m7Y8A4F2UTGBD2GCfYKCHaGCbxF0NQcSLLgQMZgnKKcANniDNlgSNYiDN4gXDeRsS/OCHzGD CUGEd2KE9zd9YKVxeyOEHoGEBgGFdCKFFEGFD8WEXhV1RWGFAsGFcOKFEAGGa4WFcUN1ZniG aJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeoiHDiGGYRF0exiIgjiIhFiIhniI/oiYiIrI hw3hh2ABiIsYiZI4iZRYiZZ4iZjYh0qIGJB4cjx4g5gYiqI4iqRYiqaYh5p4crona064gpuY hKqoKFZogo64bmQYUVpIFF5Yi2oyi6+IELxoc7d4NqdYjGkYhb+Yf8koEbS4jP03jGJjjNLY gMGIJr4YiwxRjVvRidM4jciIjYhyjQ+QiuOoeNDYNSv3iTbYjaH4jeWYKOJIjquIb00HEzF4 ftpoJvHYiM5YFy5Yjy9xj6+Yj2Wyj9nYj8J0jnXFAATpEgIJjl2IkH9ikDIokd+mdrbDjnVY kRDJjx3ZkGNCkQoBklbBjRoJhxz5jic4kBaZgi2ZkvJo/o4YGTsnOYcwGRH4+JJ7IpJFqJPm pJBXk47qWJNmeJNhyJIdWSg8CYw+2RYm2ZQz8YAPqZIRmZTKaJXMaJEkWRX/mIs0IZU6WZQA IJbhCJXuGJPUN5PYBJBD2I8sKJZkaX5mWRDNiJXPqJai5ZVR6ZZheXhxaShS+JcH0YA+CJSG pZcyAZZ2OZh+SZiDEpiOSRCR6Y+GGTX2NC+c1yqZKStmuCqd6VNZAplFd5Bb6XKVeVltN1fR spmeSXu48pkMyXygOWVE55rBApucKZsQk3Xu1zWcdZmr6YnqqJnC+Ym0IpSf+ADqqAA7R5ub Z5vAgpuxIntYZ5poxmy+CZzQ/sKasel8uaKbremdzxdpgwed0Qme04meA8ObhhY7lZeab3Wa NtWKJdl8y+kryMmDsLKDxhkw7LlcXDZBGph3A1p2XOZBk+R4smVnJKiaeLl2CceWZ/F04wWf SbE1X0ZnNmZ91wV5JRaAzqV3r4Z8abd7EIpfEnqFDzpv9Al4b5Sh0dU/HLpnXwaiiFRKvLVJ JXqiNzVlPHprKYpsL2phH0qk0NVHvFdlS1Y9IzoSFEoxLfqfP+otUaoqQxp8kTejcyREjUWj fOd6JKqAOzql7lKlSkem0WahtbZHAgplqLZm/VV2fJVeBZqgx4d8DRqfKzqlZupnaEqlQXpW bPoz/tjJb2qqb/JZanZaSf7VVoE6Fk9apo/qpKBUqO6yqL/0aYjJVYmqpB1agJQzqX94jhfo TGKnW2GXSV2XqZMlpUKlnSa6WZOGpDPTp9e2p0q6d3jHektapHCGoptKVp3aV8H6EAwlfP8X qsV6RQr5YMvFSKBKgBXqqjoFq1fzXLAlYukmqo/YrN6nZkgGSI4WV4dqFF1ZrpiHq3yUY9pa q9xqi+r6WpgaYRloaphqqdT0ruMWrxOHrso3rI93Q7QqM8S5mKUheMXVfeDaruJaYwznFOeq EsfaaIz2qy1DlBibhwk7aQrbfgZoowXnr0MRsUAVqzJzqrnkez+TsSxb/ocbG0Gqd33WFa2S uqw3QbIoEakJ07I8G4fy43uneqDFF6CqmmqnF7LUOp/1qLMIk584SIrL2bPFyYMr96eGmrRM Z7PCBbCsdIY/UZoccYZWa1VaWxM4C3v8unZ9Crb7arJ8qq8ecbZCmrYPt7ZzaRNMC1xlSxNy K6h0u3B2a7BAkbfAKrJC0bckQbhstLciwbZxy7XoBLeIylTjibZuO7Z1Zrj2eLdmC7nlxrgy QbmzmbOe63OaG5Ccy7el21GgGxOiW7lze7mYm6+t25aCq1QfpkihhK+pJW3W+brNSbqS1lqM xbuWmUELiHipS2x5hmRF9l5wVEWskrx6YjbO/povuma8vcl2CkG96Le8odu87fq8ABpK0uu7 M3Sd5KtszXYyxHU03msSjju5l4ut9zq0Xeamo0a08hpmRNtqu+Vr6Wui0Jq/AVZpimSvAsqo A6ZqvlRL/+tqfpWnCWgT88sRDlZkXhqzqUejbiZidPdoAnwoGPqshMZ9AMpFHnxoNlqjBeh6 yBXDN3HB6Vq/GuxeyHp3ODwuLmxd8tWk4HOl9Kp9aOS8WyaAyTp2Abuk5gPDOiqmFgy+rnte Ggy9cJZAlMfDXAqzGTbCeSPEZjRdvAqyPBSzSYxaD3ZhMLwQ8bt/UgwTGTxjW+qrRXqk4wtF OsbFLObF8wTGMIs+/mNssRtsxwPYwt6nxtglw1BcEzT8rz23XwvMSff7v2+qsgjKagp8gNM7 OO2JZRyooay6vx5ayZP8Wpi8PNNLwW3sxrfrE3qjvUuTw9rSZyQ8qD+6Z/CLE41ccbnrm0GL adAWbatsJ2sDy2BmyRz0y7rbRbTbdsM8Ersccqvbr4uiuD0aFNEMdNOcUrWrTdu8lt3siq2M Vd+chadLzOXMXeEctm/8EtYMpOs8Ju88rQzYzh0HvLXCndWpSpSrz+kpnqMLFNnsovg8K/78 MNUsugf9Kgu9nvU8zjxR0MdpnjKV0P1M0bainjE1FANdERJt0BhdeDazVA3NKtS5VBxt/s9w 0dHngpZHydI9AdP1p9ItrYNNOZlsIdNUodM1zZQQXZU0PdM/XRk83dNnmZVFrctB3RZJbdQD QYRNPcNLndNT7dTiTJUrOdRkEdVOwdVGDdVVLRVezRRjXdNgrdVjUdZKodbMIpgeidVxwdZI wZ88aNVSPZpIDdcrHdZpIde7UnTL6ZGB/RZ+bRSFTScKfdLfGdLBK9B8jRaHTTsXrdH5zNid 97WPfRaR7TuJXdLhWXUo/dB6/R2bjTydrZzDWdmo3Z+NjdlofRilDUDprM7n3BKx7divjSrz TM/YnNlmcdtustvVltLYKLWkmNd2HWqznW3xrBGhZ9yjiNzJ/r1tyx25zZ0Rzw3d7YiTvk0p wl2ztc0S2a3dlyjd031u1f254S19xd3dRzGV520Q392qov3U7m3YPgncS5Te8Sa5RqnfMJjf 9x0p8x1V101+0wfgtjvaPZnbp1LgerveytveDo4Vbt3gA/4oEF64xP2OCs7OeE2OFU4qG460 9Q3Uex3ibz3io1LimirhuEfhDH4Vr6nYqm3ZHx0tG8XfrAvjKDHeM16fGW3jE+3ZOW4sO/63 gOvfI5ngGR6+t0LkIG3kRz4sWOLi8Ozj3yvjoxrldI2DRX6fVT4vSS677kt6+4uBPhO4Hv7k U6zkaGqra3GseCezSsPm9s3i5srj/rYj5/+UzlicWxxKrFouv06u5wfH5/3E5JQJ59h7fVjq qAcOi22O6ESB5bxtJRMLgBNmzODd4Xke5Fyp6OBc6ORpNUYbYBYLcKCO4t3q6G876VJH6ubM ESdTtdaC6yxzs7RO22U+uyauEd83MFdH5cLC67D+o36eFpjOvRsx7AJT7DgOLchu5sB+tVfe 67jo48MOMnT95TfYStV+7eT66+Tu7MKe7GI17jjjyQrMzAZsqqHsQ4yekOpOj8Xa7dVq6tJ8 7+81s2MsSIHs6R/H7wJ37uieEfqutOze7g67aBv68GHcu7K+Uv6+cfl+8X3V8DPDq0ga8aU3 rkKX7Rq//u8Zb+3ZxvEnS8QfX7ExGskEX/DmjvDYnu4oH7kq3zIer60gD4CBPPJX0uxpausl v+YGT9A3b76Q3ngur2QfTO8VXxpCD6gn/6pH79FcG8IKK/AEOLDne/V3lfR/ukALz3Q5f+aZ /Mnw7sBK7IE0V+8UqO1pdVhlD09RT91Fz6Jwf5FiH+d0n/fbevY0D3Ek3/dkSvaA766CP/hD X/iDlrJ1SnlojK2STnLxW/dmBvYTMfUGrvkvFqsunKV3vOoQv64RnhDei/nc5PmcmvisuPdx Yb1y/EQppsVpZlynjxCp7/p3s/iMX/Oa7seFDF9fV8YNfMCTfD39C8H8I8Eh/sg8BkG9qs9K dy/fcq/eM0++9jtbhmznPI/EqWfFBThBYDqCBSH9sF6qae89vv/7EVr9aUnA6+v90Ft3TF9b 3O+p48938nX+EQEQBBgwIFDQ4EGECRUmbFCwIYGHEBkejLjQ4sWBADRu5NjR40eQIUUOHHjR 5EmUKVWuZNkSI0mRMWXOpFnT5k2cOXWOJHmxosGfEyU6NFnxYUSjCn8GBaqSacOkQBk0YCCy wU2BBF2yDNqV4taXO8XKJKkV7Fm0adW6LDvW7Vu4ceWKLetTadOlRPVajHo0KsK8X/eePPr1 L8SpVTde5ci4Zta1RYUKHrw249y3dSNv5twZbFvM/qFFjyZNUzNfig1Ur3a42qjqoq5fQ/QL Gyjr27hlp7RNufVqkrI7On5c0jPgybl7b75cGufptE+Zol1+PHpC0M61b+c+Fvpd6+HFBy6Y 3SNxmpDFD/U9ePrZ5t3J9lT7/v3Z+y3zg/1pXv5/AAME4DvwopOtuvWUOvC+6nDLKr7GclJv vOTc6wxCATsicCv7PNtvpQ9d6g+mDEs0cbQNE1RxRYT8G2vC8LzS6zDLFDuRoxS5Ysg15ZDi 8bfedgOyNtpiCxI21g7sMTkXb3TySZtyZHHK9ZrcCcbjHFyQth85w/BEKZ1Crin2iMrrTMHI sy0/GdlLirzBrIRyTjo1/qSPSjxXlFNC4/Kc8ksTw+RtzBmVfAq5vpSszC5CkTJMUTLLI7FO SivVSFA/M0VrT5yw1FQ8QEvElDBChzq0QqjSRG3QiQ5LlVFJQ7V0VlHv/PTWGmXttE9cw9M1 wFEl860wwxA1lkw1xSzzVQvhLJNTWqOVL9heq10IWps8tZY5G5+kFtYhaztSyy4VFVJIwtoc csn2sJX23dK+3XZed9PjdV5u6ZR3oRDxXTVSVg2qF16C5yrrYIQTVnhhhht2+GGII5Z4YJm0 9XfTbp3cl9+LF2RwKQT/FXjSgkvWbmKUU1Z5ZZYnlsviiz/L+MaNY/aXYpNzzqllnnv2+eeF /l++12b4ZgbTVqKTtghnnZs2DWioo5Y6YqHNUlpmfZG+eutYjXb6a7DDFg1mrk/6FcCay/6U abHbdvttjshWe2mvax16bqLZhntvvnWWG2/s6s4wbcDx1LtvxBOn9e/CR85a4gcif6BhySef OuXKE85cc8mBVvxz0J1mvPGsHo9484Urt/xyyDtHGPWDYec5dNprf3f0xs/+D2XZY1ed9Yl7 Z0D44V332Xbkk6cT98J1nzZ44zn/HXiIhSeeeJWV1377DJkH3PlKKxdJ9chvFN+j89GXnHv2 24fXe7zBpzT9j8h/wPz11S+//vzd9///OeHOR7tBF6Sm1BD51Yl+/vpboIAaCIAHQrB/AKRg BQM0ur7sRV1sylIC6RTBjYAQQA+MoAgteEIUVi1g7SmThcC1GaoITlomNKF8SDhBjtQwhTvk IVbuViGALYpGgCEXVJBUwC5JxWk0xGGJbrg/BvZQilPUCeOmo651CYsyjsJLqRCzxCZ2RIfc eeL9+AdFKqZRjSCxIse8uCwtRoqLZjLgF5vGRDSaqIwgGeMa/YjCNhYoiHB8oZmG1UKGyDBa eDQj/vKokRKG8Y+T5GEggcjFIY7pTYd0FlXAGDkFhFKUoQyh5EY5ygCZ8pShrNwqWQlKV1JS lifE4I4GyKM68guLSHSQQzw4J0Y+aY9n/mzkLI1Jyx8C8YBvLMovoRRMJw0zisekZgUFuBaP +QRk/UKgImkFTUcWs5SPhKQkq3lO5cFvbs4UpjnLSU4HhjGS8ERnPWunTrWxM5rulCA9RyhP SfbRngOFGz7Lps9wxkSgzpGmGPlJUIgWNJmkOwhCTwTOiwIUnguNaEf9NlGKSuqT4pxmQkvq UH96VKVfMyjXLKpHfnKUNA3N4UNXetOStXRrL3ViTG1KRo2S9J1CxWlRTabTq/E0QxiFKTnn SVSjRvV2IE1I5c5iVT15c1ZM7alTA/pTqYY1gJiLHu/KSj2tWoqrSw0qH8EqVrie6EGtO+vp sDe1kSr0rQxt/isx4/pXt5FPJ4Ll4Vrj6dWN7hWwtLNfYx37WMhGVrKTpWxlJTtY1fXQsKns 60kX6z/Lhla0oyVtaSGLWZkmb7P/RCxRU/vZxJlWtrOlbW0VO9SUgtanue0OTccJVdgqz7bD JW5xH4va26p2t8D9j2+HGtz/vZaS0rXdapvbWZQyF7q1o+4fu8vY5baztW7l7XZB9901ove8 4d3neP1qXvapN43yVZx1bYjdmpYXvrFNrizpy9+U/lcszu2ndvdb3/5ON8HVZa9Js0teAx8Y cQKmnSsVUBNVrtKC9u0tfn8rYe1RuLAL5m6DM+pez4IYvPqtpoj3xmGgovjBKkae/otTaOO3 wXg7BMYxjcNHYj/2uG061g6Pgezjkgm5gkoOG5H5KuP8RhjJQz6yGpkMNieXxsgsnjKWqzzf LyM4wGEey5al3GUvc/mYV/5almfq4eei+XNs1q2aQ2zipgr1qXKeM5mlSGed2S8kgIbwe1PM Z7gROr5+5pugC91ePX/VzogumKK5Z+lKE9bQJ450YidNaY+glWV3FbVSM/3pwZVaetgjddT0 CuUPg9otqiZr5GgdtBozOl63Lov9UldX1r26067VNZJ5TdfVHZtkOlNZq1VdE2UPhHwMc7bn xgfnAst61tF2WIZPyWuwNRvYx4Y2t1vpSpKce5WXE/am/qOsbe9oLaQYM3WqzWprbteLcPPm lJnhTRd5z1tm9RaQuB9gYWWXm6oCf4mu/P1vneyb4V3DdLwXTq9l8+Tiuuzlj5J0RAKWC+Rc Ghcu0RU4h2O74oCVOIe2uaaRq8i4Mw9tPjMekpoFJoMaVBXPXXhIQqJchg+H+HMCriIaEQuR 4aF50ydrc+flXJBbHCQh54jIUy2qa+0+dLaLbvSNe4iFPpe5083uWKinVerKdBOygH51Gbnq Wjd/d9dX/teWi6jtBeqXWlRn4bOPFvCSS7vCraYfj3O85G8HWFc6nsQW0T3WM+761zV+eBYx i+Rz7HtaGsvso8dM36HX0RXl/vhzUzVeKDufe8phHWfLGz5PV+/50q1zOCjl/U+SDzXpQWR7 zgtS6UM81X36rfJi+1j3IIK827V+e95/M3qFf1rYvaj01JM9+3sPOvaHTzfXD/vRsa8+5pHu fPR3Hi2BZz9WXRp9HPlem4+HuRHtb/JecqlHIMd/a1o/dORDNXhbPt6IuZPLv/VoPwWkvpkg wPiJPqIjv/mwvolbCAVsv7QzIQdcJwgMwDOLvQ1snL9zpQukrMGLHLUxrQpkiw58Pa+TwAk0 vxVcCdzLM/fbGhWMI6dQv5AhouM4Phe8u7gKwcIpwcBLwdLSwd/TD5RQP1IBQvFzNxgECUG5 pY+z/j/+cDxs6hcjPDsk9DYLeyUULCRl0RFS4YxuCj8phL0pxDnSg5Pvw4+pk8OU6EKz+8LM urxC4qUgKRJ22Tz/88MgOpcjMpIYmgrVAIDVqDvKa8Q2/IgwcRbt0zu2o0SUGMFVskPIOsEH YMAYfCE0SRNiCUWyg8NGwb67aAvHQI8IfMTem6i4o7r5e40i6kF2gbk/VLzFSMRF3Cr78cSY kBLHy6S925K/oD1aLBcxUcXFcEQ2ZERXfEUZFKKOqzo3Yj3bq4w4DDqFSIxuWUWCIUJfgb+N EEa+QMXTW7pjHMSxe75UJJGrQI8XhEZ6jMZyDL1YTMdz1I3ay8bfaBTV/luaGKoccIQXcYS+ qMPH62uhOCTFYjRFWWxCgYghjYjHQ9sze5TGPeQ7cPE+1NMmfSTGgtDEpgNGPQRFkdMNA0xJ cvFDPhSXEFGNSZHHeZw8Z8xIcyyVbRQ+FxJJhiyUgLRAkpw5k3RDkHJCDmwOmmzFjByQN0wN XkoXJAkXqtzH5SjEXEKIoSTKgyLHS/E9pNyWbKoomEjENcTIprzHo5zBi8DEU9pK++HEoqRC +WPLkVFDu0s+GqtCxMtKrtgS6gDMxjLLgjnIH/RKp6TAFYTCNazJpjTMuSzMutyW0cs3y8S1 QfPAtIw/xbTLuQq3ybSWyrxM0mTMvBRAbStN/soZN7QCzc5cG8RUTdkEwCDUSxWbTYWpNrz6 Gsi8kNjETdLkupt0TJwEzl6bHnDjzdCslhpEIaYsTuOUNuS8NdecRtFDTCvTzM18F02jot70 EuwEs9pEze3sMCEsme/kFoKrsyisvPIEpjxMo/SMjOY8oed8TwWyzb6Zz1xJq+wczw/Ez8MK UP/hT7Wozw3TTgFVK/3kGwNNCwRdMgVd0Plp0L15UHrzT/Fsz+GkUEjzIwwtmvV0n/v0UAeT z+XslQiloBI10aaysB4K0YHTUCpqURdlK/JUHhndihUFIBu9Uc7K0eTZURYc0fb5USC9LiFF HiJtiR6NrglNUk4D/tEUxZUnZc/GPE+xis7jxDdyU87X1JQrJdEofUwulU4vTU6naVKWGNMj LVPo5FLdlJrqjEz/glN7PFM0RThRq9OuNNJFA9D3ZFPRTDcLDQ1CVQk3DVQOrcc49UyXgMvi slMFE9TyTNRekVTiotRJQlIYNFBCvA39Q0Dr0NTh4lTvwtNoxNBkmUTxcMtRMlUwFKUbTKrw rFFVdUVW9cE+dEfP+LycwVSUWNRLy9VH3NXUEETaA5VbpRRhNZtm/TNjbUNk7aLgyyo0JVBv qdJbIdbt8VQJrFZDutayk9XZQtUgm9YpFFfuW1amM9dz/VManSJwJT92JdewjFR4lS10/k0v df1UbjUQlcTCf2QRWKVVc5VLebWnegXBgGVLYIUX2OnX/2xUm0zLZ/2UfeXXha2nhrW8jNWU jc3B9wPUYrXU7eTLcMFCUmWmFbHFgxjZJOxYdPrYr4tEnXRVOuyMDzlYMTRVhS3ZeZVWlN1M nB07d+WPLBlWisyZxqLYDc3SQ4WvnOzHpM2NZL3KlsVaHwlEayQiwlzEXpSWkAW/odWsfw1X hQTbdTxDUeVGu2AWZGTa+ChIX0xTqMXVosXYtbXar20PuBsUuWXHk5BZ0spbek1be+3bqrta wA1KyRhcbbxEwxUtxCVai31GM4XF5NhJkeG+7eMYyW0Qyq1c/su6XLTd2821zmWBlK29xZjz Wl2SiCNxyebTSnV7y4QlQcKj2XOy2aI7WkglSwyhyQolH9QdMdV9VCWUypNzOb9kPkUxD8IM x4fNFG+9s+XN0+tdzGg1neTdIeCFuLL1k+w9me7Nk/NVru1dVT29TD8VWoZVXId933yL3536 XuXNXOLkXvvlNvy1VZP9VvoF2f8FYDBl3ZvRX/EtYCmFrvLtRgZ2zvjELTRytAdGswgWOo+t 4AKbIAzO4Cnb4MgbYOHy4BAOYRFWvvQ1nAk+YF6bti6FHV87nhXGKRIm3rNVSxguNRk21Oms 4Z65YRx+2CvcvNnYPxp84R5WtdxF/thZVYAnFqWVIeKbIhxyhVufLOEd/som9uG6ms5sTbbZ sWKV2jfNkzugG1YmDtPhFdMJNmPv7N40pjo1ZmOEyuE3vssuluM5dmNtTKI0vl2z3TZA3mMX NmE/bh805sZtREeTqEE9RuT1XeTtaWQ1LiBfleA8bmFEZpFKtqcvVtOmwWJ93L4shtZOPuRP BuU43tJRprUA/kuWJcRa9gtFbWMFbmXmfOWwimVZTuDwTcxd5mUr9WWpAuZnE2bfjThPNmZm VWSCmmQVCWUUeWZXXuVihmY4luaBouYEmWHQY2UqkWRs5mbPsGZ0AucENN3TbeadOWd0Bk9v FmV5hkpc/tQ/IJnFKyTklXDnd5Zfi9vmeU7kPoYrw2xVuM3ZhW4JgK6sYWZnSFXnc0poHwxd t21HsPBZKd7dTOxdgQY4ci5o36znerLoZMVoYcHGq1Jh6x3pbO5jifZMiq4mlLbWTWZbfO7P WU4ac4ZpkqZPZI6qmwZKf1y9fhTRg6aZe64SXQ5qjDPpdW7qx3XJJXTZGe3pvHlqqC5Uqa5o qiZc0GWQOcxQrbaZnyborg7noTYqcbRl93hdQX7dNgVibdWYsEZImc7rtV7ir7ZpvsbDh4as iA7svsbjpf5lw+7L533VwZaswgbqw+bRti6qmS7Vx46syFbryT7Mv6amyz4O/o6G16DNX23u bNj87GNSWSS+5Yz2l4hFz8VWz72WbNT268RO5qdkvJxWmqnoTsm0bac+7ds238ou4rVE2r/d qaZd09kWauIuboPms6pFP9BVkNnQ2oFVVo+bStgVRJI76+uMbunePdU2pure51P+3DWZ3EDU vNR7FZ1TOm8U74tJ6/KebjlL79B1XLGG5EA+F9pdWbKrb2YO6Z0I7RmsadBmXK3zb/dWabE2 FgCfIwN3buGO5trm7PyG0OO+Yge3uuWOcFScW1WRb02KFG803kWaPngGOw7vcKWm7t0m8ILl 538c2PrTblw0oiw6YgLIbM1+8ZtQcO8971kS3j0W/nLCltfUmmnX9Wef/vCVYu0djF7YZnK0 KxvjahzWy9dupfIzfm6lGW2P1t0x5JouLxzi+x4x9ygjp+fcZi3VEeza8vKqfkAklyVlLjX7 zvIo7mjyOUEvbz4wD/M9p6Q+79MDx0GXLj88x7rcefOOWvTWbHQB3vBIx6JhRmhLB54/xxf8 ZnPI1fM5t2QLouZRxxuVHPEpT3RU308yP1CulvFqpvRYv+RZ9/BsdeYMt3UuznV7/nXM3lRg Z2tYF/a3oeY1P3YNV/apJnbRnlRnf3ZoB2xp/9Up/tltF/Rqt/ZrX+1dX79Hb8Bxv20GD/cL PfesHuhvH8dkV3dM9+1a/n/3kj51edceVa93e6ftfE9ydqds8u536Mb3f2fSgC/S4pm0OJ+4 dEfvT6ceDI9xjaV2gvf3/Y54UC/lhHdoi794ns54jWc3js/2zmh2kKf1eF+jkQ+2kqd4ke32 xiL0lA95De54Ubdrk2H2cv/Emld5gwdxk7dzLe9EIo8SnF/rhwf4oefyoq/zo5e9n+f1oK/y XYfrfj50j396kDZtTZ96sxZ5mN/ZGSn1FTFzTS3tTDfksQf7pefzWTe9jzz7np+VfR94sHdS XIcoUHWjhkb2queOu//6vBf4wIfzq2fJLdbrid/swm/3m2/6VQlc/R7ntldffn/8XF55NSLS /p3UeoVv/KiHdM3Xe85HUcl3b8o/ajk3mYkdfXNP/fJ+e0VP/O3Oepg9ea7v+rV399Kv69P/ 48tfwd3nfXrH+9+P5L2f5qTfluJPc69n++THbRqX/TKXeaDlXejvfZEe/pqn/UlibWOM3QL8 yx25aMgnmKeF/cz00unf/MOv9BrvSVevxLKWe8hn8fzcHNSdtvcHCAICBxIkyOAgAwAKFzJs 6PAhxIgSJ1KsaPEixowaGSJkUPBjg4IhQQ4c+fEkQZMoRZ5UmXIlTIMIFzbYaPNmxI4xd/Ls 6XPgg6BChxItanToz6RKlzJt6vQpgY44p1KtavUqVp0rXRIYqdIk/leRDcaC7QrW69mxKcmS XMvWbEi1Mg8qJFsTK96cCKHyXXr0L2CiTcM+Jdz3MGKfUgHczev4MeTIErWi5Gr3pUDDXVma zVzyM2jObT1j7rx54GLGkiNTTuz6I1EFsmfLPkqbtlCmml+L5r1zd2mnqRuvLm78uMbWo0F/ DV1ZbuiypKcHD2737emPHYcix6vct+vA4v/qBv/b/PmewHkO7+7+PXwA36tnL73edHbp9cMS bl4Z5UFFxUfVfOjxlZpGRi3lElvQXVfSg3CJhd1lEL7V4G4RwuUgdltRqBaGFW7YAF00DXgi it7ttdVyXjm33Gn6oUVffdaJRth4Oeq4/iOPRRn4GoI2FRgTfy4yuF9vR1JX41lLVhfXjT5Z Ft1LJh1EIkPEpbgllxgNSd11HAIXYYgQmibihm6JKZeGQPX4JpxxBvWja0Fu9CWLMIYJ5YsM QtdnmC96+FWgTuZpn3NxhZmQiV06+uhkKx5KJ6U8yXkppuJVepidyUn6E3+9JSqqmX1OyhOb p8IUqn+eWTlTo5DKOiueNaK656ZO2RXbbbVl+utQvfo6Z65QdZpRrS0p+2RmaCKJaIxRpveZ ktESCeazrqLGAJaxzvptl8kWO25BR4Eb6UHkCgfrRkN9CqqahHYYnYht4jdis/O2VK+zf646 ZbwWjlWiauca/pyiuOqSe+zBCyWscLnAIrUgX/dB7Fq1J7XXMMfvdfQxyCGLPDLJJZt8Msop M9qxQw9fLJDEE1O8oL7o7WnxoPaKNeFKi2nJMtCsqTw00UUbfTS7QSvk8ssx5/Yy1FEzrDTV VyF9NdZZH1310u9GDROvvdom7NNfm71w0lyrbZXWbbv99sdqM33x1BMpeDbeuda9Nt99+73l 3BDvTVHgeRvO1OB/K744448Vrm7i6Hp0OOXmRd445plrbtHjaBN8U+eVi95z2pubfjrqEIVe 7OWqez067Ot+njrttW9ea4Y499X6Q6vHHjvvtgs/fMN4rqe7lKTPfufrvzuvWOnE/ks/PcvG o8qbYcE35PvzlWtPPfjhe9z8kmXim29a9+4rJlwrg05+9/FrHL349dt/4pcA50cfoYbyLxC3 luepdMmvgDH53v0SqEACwa9IrYoRmiwGsAC6T0jwM2ABEbjADXKQcw1cn40eKEFlkUiAyLog BuOnwQ6ysIUc+aC0kCTC5MmQfl5CYQqft0IXGgduPvzh1rhmPQtJqFBpUlTN9gWSFXIvh1Kz IQ/DBcQpUrFkcrsg8gxUQhPekIBOzOEOoyiZKpKxjAjhTtBwB56b/SsqUPSgF7+IwTCKETJm vKMPnaZHODmPiXj8IyDLWMdvNdGJezzkjvr4xooEspGO/oTbIGmFQzlaCpGWDIwiuXiRR3Ky k0GM5KMSZkQJoe9PSZyQvErVGSOSCS1IDNttLgknYSlAZrDzoydzqUuSgRJSD/OPjDCjn/8w h0rTmSG0NmOuNE7ya3TsJTRt98sqceaB/jOUkkA0TGumyjPPjE8h6fTNaJLTdNOkVjX/pyom NQs/yCxVWSiIRqCF80fjLCc+G/fLCmXTWbYiFTs3w6fzmWqgY5ElQn30u3vms6F+O+cwrbWs VU2UNFDaJrPcSYCEcpRYwFukQ0NaO4ia6p8mBWg2jYktYZaloxzNZAVFKtPhnXN/x6zotYp5 052uVKUhgSVuXDoeWtpydAyd/ilSOSZKNqUPfagcU4c+hMQRpYWpLoLLMunZzCdqMqle1edW Kam8mGo1jkYF6VfTyrd6SglXLzsqctiKHriqta6AC6tY5xcgoShNrpZDq10DWz285jViQr0k TAWr2L6psZTanOoa/cWbw8oysYu9bNWGOCqb+iaiOFUKZRG7UMBitrSO0iw2BdXZaTEFqLMJ LWCIWrZbkta0tkVR/trSKs1gSGCurFnu2BciCi3zZ+fyK3joetvlViW3qEymh7QlzIzmNJnN CUlHtGRccCHXN8plLngtaFZSXZWnp0rpZlnL0+uGqSHbJSRhBVfb8NJ3jDCkkWf1lE6Vqle6 2MJu/une6yh3xVdh360vgifiXBtx9rz7tSi8ZBhCN17JvQcryni9N98Ec5htWIwX+/4VVX5J VbJKFJWGGgBbRFq2wy7u4YeLlUX1AHSjK95ji1+sYzuiEHlsBJWJn3pK9dXsxjgebVd3rOT3 ZbiwPnHtsIwsFNl6lLZJXjKWuzg5Jy/lwI45So6zLGbx7rLMXhZakw935jEv18xu3nAoCww5 OLN5zG9+8xXTbLg119m0d3ZznrdsZbL2udCGPqGe88bnQzO6zXL2HKEbLelJy+fR41o0pTNt 1+7yBtOa/rRXOQ0kOoO61OEVdZ1IbepV2xbVifE0q2MdTVcjBtayvvUg/mnNKVXjutdf1fXu eO3rYcsU2AcSNrGTnU+jEfhjzXa2UN6m7GmXltnRBtmzz5htrFG724q1dlBCtm0GYLht3j53 XcH9AHFfezvl1hq6403feTKE3goxirzzLWl735uvDcG3vgNeaH4DgN8AFzjCxUxwghfc3wl/ +JIX7vB/TxziFu+wxIMCEYZfvOPMzfgDNl5xj5N8uSAXucZLrnKTj7zhKXcIx1cu87pOmWw1 F1tQaDnznaf15A+JOc+DLlKfw7zlQj96SIlO8ZcjvelJbznDge70qQ9S6fU2OtWzXkerL0Tq Wv86B7neb6aDvewuFLvLQ272tbNQQFcnStHJ/s72udvP7V23+93lTve9Uw/vaR+51/ku+AFt SqFuEoxhHzCuwTNeIhQu47v3ShRst/uPjb+8Qx5PxsiTe/KUD3cgMS96hbiRUjeP5emD+gBa zjXSo6d76bn8lCu/vuyxV1gr/Vkp2tf+67cnF3qvaSDe9z7rvx9Xf2gkTtcX3/aJ/lHyVbv8 5g/++MgncZCnT32+Wx9iV51xrZm/feM/P1ffN7D4xz/17m8q+OAPtvphX34t8pOpaIv/3Nkv e+jhn+363z97pF//Cd3/AeABCeAA8lwBHlOgmE/7qYfuEF8CytwCZkx5vR+dRCACTiAFPl/G 8BfeaCAH+l6iAcxu1hFJ/WFfVTWVwMAICA1MXdjFCB5dAVpGVElf+fwXS1igg91KVNSEds1g 0NWgbkEXCIVQA1JUwChfW9DFngihApagCzZYG+ngFKZXQKWHE0Jh0xFhkpiXfkkYNTFYTwkf ZmxhlnDhzFUgiLFgzqygb8VhKbXgb/GWXZTIdajhGnqgFu3ZBuohxC3gSb3hKQ1ZZI0SAP0h ICacIBrg/CwiAc6fIxaEBEKiwGnen3mSJUZhJu7SJn4iKIaiKI4iKZaiKZ4iKqaiKq4iK7ai K74iLMaiLE5gQAAAOw== --------------397731E92267EA0F0D46E440-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01830 for ; Fri, 18 Aug 2000 02:15:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 18 Aug 2000 02:15:49 +0200 (MEST) Received: (qmail 23670 invoked by uid 0); 17 Aug 2000 18:58:07 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 17 Aug 2000 18:58:07 -0000 X-eGroups-Return: sentto-1101623-623-966538665-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 17 Aug 2000 18:57:45 -0000 Received: (qmail 31493 invoked from network); 17 Aug 2000 18:57:44 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Aug 2000 18:57:44 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 17 Aug 2000 18:56:39 -0000 Received: from f-cpu.org (nas4-119.ras.club-internet.fr [195.36.203.119]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA18903 for ; Thu, 17 Aug 2000 20:56:24 +0200 (MET DST) Message-ID: <399C3551.AE6FBE65@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008170821.EAA06307@belegost.mit.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 20:56:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools, VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 544273878865bcea5f1ba0ad23f7745a Status: R X-Status: N hi !

graham@belegost.mit.edu wrote:
> Hi
>
> I haven't used more than a small proportion of these, but have a
> little idea of the current state of some of them. If I get any
> of these wrong I hope the authors will complain and correct it!

;-)

> Camille does not yet have ANY code available, AFAIK - not even in cvs.
sad.

> > NGPaint
> It's meant for small diagrams, not large ones. Its not gpl.
when a diagram exceeds a certain complexity, then the designer should either
split or hierarchize the diagram. As for the GLP thing, that's sad too.


> > VHDL-GUI
> I've been told this is good. But it is binary only (the one exception
> to the rule on open collector..)
the GPL thing, and the lack of sources, is very sad too.
hey, i wonder why you call your site "opencollector" ;-)

i'll try to stress on the VGUI developper(s) to get the source under GPL.
it's for the f-cpu and for me too, i believe that i could more or less
adapt some of the SW for the GNL project.

> > FreeHDL
> Yes, but still in early stages. Savant does something similar to the goals
> of FreeHDL, and is much further along.
that's crazy. But who am i to criticize when the f-cpu has still no
source available ? ;-P well at least we have an excuse : we have no suitable tool ;-)

> > PICA
> >                          VHDL compiler and simulator from the University of Pittsburg.
i'll try to see if i can d/l it now.

> > Savant
> If you want to do VHDL simulation (not synthesis) with full coverage of
> the language, Savant is currently the only way to go with free
> (lgpl) software. But you don't (yet) get all the 'nice' gui environment
> you'd have with a commerical simulator.
i have the distro on the HDD. I better make some room though, burn some CDs
and get one or two GB free.


> > Vaul
> I believe this is now merged in with FreeHDL.
"more or less".

> > reviews and remarks about these as well as others are needed on this list.
> > let's not reinvent the wheel, right ? ;-)
> The most relevant ones aren't mentioned: gEDA for schematic entry,
mmm... maybe i missed the point on their homepage.

> and Icarus. Icarus is a Verilog based system. In general, free tools
> using Verilog are further along than ones using VHDL.
well, in Europe there's almost no support of Verilog.

> Icarus can do
> synthesis (meaning net list generation, in this case).
we don't "need" it now. we still have to use more or less proprietary
things because the target processes are too diversified.

> Both gEDA (gschem
> in particular) and Icarus are already being used for real designs, though
> they are also still being developed very fast. I'm assuming you're
> running Unix though - if you want Windows, you may have to do a lot
> of porting work yourself.
i'm using Windows 95 and SuSE 6.3, depending on the tool's platform.
it takes two minutes to switch from one system to the other, though ;-)

> Conclusion: for VHDL use Savant, for Verilog use Icarus. But don't
> expect much more than bare text output. There are some nice waveform
> viewers around for Verilog Change Dump files, though.
what would be cool : a dynamic/automatic "back annotation" on the schematic entry.
but here i'm dreaming ;-)


> > Electric and Savant should follow.
> > I can't d/l PICA, i don't know why.
> > Camille, gEDA and FreeHDL are not ready.
> >
> > we need a VHDL behavioural simulator :
> > Electric and/or Savant would do the trick
> > if i can test them.
> I believe that Electric is more oriented to IC design,
> where Savant is purely a simulation engine. For high-level
> behavioural simulation (first pass at the design) Savant
> might be better; for actual IC design, Electric.
> Last time I looked, Alliance supported a very limited
> subset of VHDL so wasn't so suitable for simulation.
i have the distros for savant and electric, i'll check them
when i have some time. VGUI is fine at this moment because
i can do diagrams for the dependency graphs of my programs
(another biased use of schematic entry SW ;-D). it's very light
too.
Alliance : now, i don't know. i have CDroms full of docs etc
but haven't had time to read through. but to answer your comment :
better have half a langage than half a design ;-) i presume
that the limited support of VHDL is not severe enough to
impact on a normal design, with some "langage tricks".

Savant is meant to be GPL'd and simulation, it could be used
for the behavioural phase, but i gotta test it.


> > when the behaviour is OK, Electric and/or Alliance
> > could be used for the CMOS/SiO2 process part.
> Magic is alive and well, too.
let's have some VHDL first ;-)
the synthesis can be done with any tool, free or not, once the
behaviour is correct.



Any time i spoken to someone interested by the project, or when a
newbie comes, we're asked for VHDL. so let's make some :-)
OTOH i hope that we'll be able to see, test and enhance on the ground
of Nate's "soon to be released" design ;-)

> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01848 for ; Fri, 18 Aug 2000 02:15:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 18 Aug 2000 02:15:54 +0200 (MEST) Received: (qmail 9496 invoked by uid 0); 17 Aug 2000 21:38:25 -0000 Received: from hj.egroups.com (208.50.99.212) by mx19.rz2.gmx.net with SMTP; 17 Aug 2000 21:38:25 -0000 X-eGroups-Return: sentto-1101623-624-966548298-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 17 Aug 2000 21:38:24 -0000 Received: (qmail 28844 invoked from network); 17 Aug 2000 21:38:17 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 17 Aug 2000 21:38:17 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 17 Aug 2000 21:38:16 -0000 Received: from f-cpu.org (nas1-199.aub.club-internet.fr [195.36.150.199]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA19134 for ; Thu, 17 Aug 2000 23:38:09 +0200 (MET DST) Message-ID: <399C5B3A.364B7B8B@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000817075737.15564.qmail@web1103.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 23:38:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac3edb02bb6b7a2aa1b659a67d1d05d2 Status: R X-Status: N hi,

Jamil Khatib wrote:
>
> May be you can visit the OpenTech cdrom page that has
> lot of OpenSource tools and Openhw designs.
>
> you may look at the table of contents and/or order the
> cdrom.
>
> The new release is about to be ready (may be tomorrow)
>
> http://www.opencores.org/OIPC/projects/OpenTech
>
> Regards
> Jamil Khatib


ok the ISP is up. i'll see the links from
http://www.opencores.org/OIPC/projects/OpenTech/OpenTech-Bookmark.htm


have fun,

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01854 for ; Fri, 18 Aug 2000 02:15:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 18 Aug 2000 02:15:55 +0200 (MEST) Received: (qmail 20573 invoked by uid 0); 17 Aug 2000 21:50:16 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 17 Aug 2000 21:50:16 -0000 X-eGroups-Return: sentto-1101623-625-966548977-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mq.egroups.com with NNFMP; 17 Aug 2000 21:49:41 -0000 Received: (qmail 32455 invoked from network); 17 Aug 2000 21:49:37 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 17 Aug 2000 21:49:37 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta1 with SMTP; 17 Aug 2000 21:49:36 -0000 Received: from modem-6.indium.dialup.pol.co.uk ([62.136.40.6] helo=llandre.freeserve.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13PXXW-00007r-00 for f-cpu@egroups.com; Thu, 17 Aug 2000 22:49:31 +0100 Sender: root@pop.gmx.net Message-ID: <399C60FA.66E2AE35@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <200008170821.EAA06307@belegost.mit.edu> <399C3551.AE6FBE65@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 Aug 2000 23:02:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools, VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: df761ce265f6fd3dcc2f277dc3ede374 Status: R X-Status: N It seems that the Alliance team has created many real working CPUs using Alliance.
Therefore the limited VHDL support cannot be an obstacle to creating a CPU.
Therefore, I would like to suggest using VGUI to do top level node design,
and use Alliance tools to make the register block / arithmetic units etc.

There is limited FPGA support also. (xilinx only).

Alternatively, it cannot be difficult to take a node list from gEDA, and convert it to
VHDL.

So then there would be gEDA and Alliance to do schematic entry and the creation
of adders, rom, ram registers etc, also the synthesis and layout for Gate Array and FPGA.
And all GPL.

Simulation is however awkward in Alliance at present.


Jeff Davies
jeff@llandre.freeserve.co.uk
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00299 for ; Sun, 28 Mar 1999 09:13:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:07 +0200 (MEST) Received: (qmail 12400 invoked by uid 0); 18 Aug 2000 01:53:42 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 18 Aug 2000 01:53:42 -0000 X-eGroups-Return: sentto-1101623-626-966563619-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 18 Aug 2000 01:53:39 -0000 Received: (qmail 14962 invoked from network); 18 Aug 2000 01:53:38 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 18 Aug 2000 01:53:38 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 18 Aug 2000 01:53:37 -0000 Received: from f-cpu.org (nas1-250.aub.club-internet.fr [195.36.150.250]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA28859 for ; Fri, 18 Aug 2000 03:53:35 +0200 (MET DST) Message-ID: <399C9717.EC22A40E@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 Aug 2000 03:53:27 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] weird Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d46f2d478d228d37bfe812ecb09b8e39 Status: R X-Status: N hi,

i found a weird limitation in VGUI :
it is not possible to make a bifurcation/divergence
in a wire. That means that we have to tweak the VHDL
output or do other naughty stuffs.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00320 for ; Sun, 28 Mar 1999 09:13:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:12 +0200 (MEST) Received: (qmail 2533 invoked by uid 0); 18 Aug 2000 08:07:12 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 18 Aug 2000 08:07:12 -0000 X-eGroups-Return: sentto-1101623-627-966585963-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 18 Aug 2000 08:06:04 -0000 Received: (qmail 18476 invoked from network); 18 Aug 2000 08:06:02 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 18 Aug 2000 08:06:02 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 18 Aug 2000 08:06:01 -0000 Received: from morphin.marquardt-home.de (d90.nas21.sonic.net [209.204.136.90]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id KAA04161 for ; Fri, 18 Aug 2000 10:05:54 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13PcDI-0000Ou-00 for ; Thu, 17 Aug 2000 19:48:56 -0700 To: f-cpu@egroups.com References: <399B9EE6.5B8940A8@f-cpu.org> X-Now-Playing: Benediction's The Grand Leveller - Senile Dementia In-Reply-To: Yann Guidon's message of "Thu, 17 Aug 2000 10:14:30 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 17 Aug 2000 19:48:56 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6f88491611591e9c95e3159a4bb30807 Status: R X-Status: N * Yann Guidon <whygee@f-cpu.org> writes:

> but it does only one simple thing : the architecture, not
> the behaviour or the simulation. A good start and VHDL structure
> editor anyway (300KB only under Windows).

FWIW, the next version of Emacs' VHDL-Mode will have structural
composition too, albeit not in a graphical way.

Colin
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00338 for ; Sun, 28 Mar 1999 09:13:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:15 +0200 (MEST) Received: (qmail 11211 invoked by uid 0); 18 Aug 2000 09:43:55 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 18 Aug 2000 09:43:55 -0000 X-eGroups-Return: sentto-1101623-628-966591832-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 18 Aug 2000 09:43:54 -0000 Received: (qmail 2383 invoked from network); 18 Aug 2000 09:43:51 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 18 Aug 2000 09:43:51 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 18 Aug 2000 09:43:50 -0000 Received: from f-cpu.org (nas4-101.ras.club-internet.fr [195.36.203.101]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA08784 for ; Fri, 18 Aug 2000 11:43:45 +0200 (MET DST) Message-ID: <399D0542.9D477599@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <399B9EE6.5B8940A8@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 Aug 2000 11:43:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0cb508b15ca6492317910cf7fd12cc11 Status: R X-Status: N hi Colin !

Colin Marquardt wrote:
> * Yann Guidon <whygee@f-cpu.org> writes:
> > but it does only one simple thing : the architecture, not
> > the behaviour or the simulation. A good start and VHDL structure
> > editor anyway (300KB only under Windows).
> FWIW, the next version of Emacs' VHDL-Mode will have structural
> composition too, albeit not in a graphical way.

IMO, Emacs is not considered as an "industry standard EDA tool" ;-P
i've seen the electric mode at work, but it's useful to VHDL gurus,
not for me ;-)

tonight i downloaded some more files, rpms and tar/gz, some
DLX variants etc... but i'm seeking a GOOD GPL'd dataflow graph editor.

i've found some interesting sites about VHDL, probably the best is
http://tech-www.informatik.uni-hamburg.de/vhdl/
it points for example to a korean Alliance lookalike
(not complete, does sims, huge files). i've downloaded probably
all the files for gEDA, since i seek a better schematics entry tool
than vgui.


In the same time, a f-cpu reference behaviour simulator (not architectural)
would be useful. it would simulate the tasks, not the OS. that'd spare the
TLB management code, and exceptions would simply display a message and stop
the program. a simple, dumb, portable, pure C, simulator would help for the
instruction set sensus and analysis. this shouldn't be that difficult to do but ...
do we have the time ? :-) my master thesis is not seeing the beginning
of the end <sigh>...

i'd like to have something to play with in december, for the 17C3. the conference
would be called "the Freedom CPU project : one year of procrastination later" :-D

i'm compiling a "list of things to do before i could move forward".
some picky instruction set modifications/additions...

> Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00359 for ; Sun, 28 Mar 1999 09:13:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:20 +0200 (MEST) Received: (qmail 3587 invoked by uid 0); 18 Aug 2000 12:42:50 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 18 Aug 2000 12:42:50 -0000 X-eGroups-Return: sentto-1101623-629-966602549-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 18 Aug 2000 12:42:28 -0000 Received: (qmail 22784 invoked from network); 18 Aug 2000 12:42:28 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 18 Aug 2000 12:42:28 -0000 Received: from unknown (HELO mail0.lig) (205.152.0.90) by mta1 with SMTP; 18 Aug 2000 12:42:28 -0000 Received: from 0018728164 (host-209-215-11-182.bix.bellsouth.net [209.215.11.182]) by mail0.lig (3.3.5alt/0.75.2) with SMTP id IAA07365; Fri, 18 Aug 2000 08:42:26 -0400 (EDT) Message-ID: <000801c00911$bee2c300$b60bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 Aug 2000 07:42:16 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Free Downloads Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C008E7.D5002D00" X-UIDL: 6072a2dbf31378e028dd2219367ca90a Status: R X-Status: N ------=_NextPart_000_0005_01C008E7.D5002D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the third and FINAL time - check www.quicklogic.com for FREE downloads. ------=_NextPart_000_0005_01C008E7.D5002D00 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
For the third and FINAL time - check www.quicklogic.com for FREE downloads.
------=_NextPart_000_0005_01C008E7.D5002D00-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00389 for ; Sun, 28 Mar 1999 09:13:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:26 +0200 (MEST) Received: (qmail 639 invoked by uid 0); 18 Aug 2000 16:53:19 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 18 Aug 2000 16:53:19 -0000 X-eGroups-Return: sentto-1101623-630-966617582-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ei.egroups.com with NNFMP; 18 Aug 2000 16:53:13 -0000 Received: (qmail 22918 invoked from network); 18 Aug 2000 16:53:01 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Aug 2000 16:53:01 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 18 Aug 2000 16:53:01 -0000 Received: from [207.180.18.35] ([207.180.18.35]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id MAA18717 for ; Fri, 18 Aug 2000 12:52:59 -0400 (EDT) To: f-cpu@egroups.com Message-Id: Organization: Eddas, Inc. X-Mailer: Voyager Email for QNX (vmail v2.02) From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 Aug 2000 16:52:57 +0000 (GMT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ceb387f4bcebb4fa5f90197214d81d42 Status: R X-Status: N Previously, you (Colin Marquardt) wrote:
>
> [ attachment ]
>

This is good news, considering I use EMACS for all of my VHDL editing work.

I wonder how hard it would be to make a graphical interface for it.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00398 for ; Sun, 28 Mar 1999 09:13:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:28 +0200 (MEST) Received: (qmail 21889 invoked by uid 0); 18 Aug 2000 17:53:46 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 18 Aug 2000 17:53:46 -0000 X-eGroups-Return: sentto-1101623-631-966621218-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 18 Aug 2000 17:53:43 -0000 Received: (qmail 9716 invoked from network); 18 Aug 2000 17:53:37 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 18 Aug 2000 17:53:37 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 18 Aug 2000 17:50:20 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id MAA07609 for ; Fri, 18 Aug 2000 12:49:18 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 Aug 2000 12:49:18 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8b569b27dc9677e61146508cb3ccf184 Status: R X-Status: N

On Fri, 18 Aug 2000, Nathaniel Downes wrote:

> Previously, you (Colin Marquardt) wrote:
> >
> > [ attachment ]
> >
>
> This is good news, considering I use EMACS for all of my VHDL editing work.
>
> I wonder how hard it would be to make a graphical interface for it.
>

Not in emacs it self, neither xemacs.
They only manipulate text, but you can make tools to navigate more easily
throught your code.


But for graphics representations it will be an external tool.

The tool can then be linked to emacs. So you have your data piped from
emacs to it with comfort

--svdh
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00431 for ; Sun, 28 Mar 1999 09:13:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:34 +0200 (MEST) Received: (qmail 32116 invoked by uid 0); 19 Aug 2000 00:19:16 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 19 Aug 2000 00:19:16 -0000 X-eGroups-Return: sentto-1101623-632-966644352-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 19 Aug 2000 00:19:14 -0000 Received: (qmail 9998 invoked from network); 19 Aug 2000 00:18:58 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 19 Aug 2000 00:18:58 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 19 Aug 2000 00:18:53 -0000 Received: from f-cpu.org (nas3-117.aub.club-internet.fr [195.36.145.117]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA19415 for ; Sat, 19 Aug 2000 02:18:49 +0200 (MET DST) Message-ID: <399DD256.5503F239@f-cpu.org> Organization: Association F-CPU X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <000801c00911$bee2c300$b60bd7d1@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 02:18:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Free Downloads Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d5c16790261732e6e887aa7556fcb4f5 Status: R X-Status: N hi !

> "Richard E.Hartney" wrote:
>
> For the third and FINAL time - check www.quicklogic.com for FREE downloads.

it's "cost free" but not "GPL" and the source code is not provided.
i trust you and it might be an excellent tool but i don't want to base
a work/design on a SW suite that could be "discontinued"
(become not free, change the file formats, no port to other
platforms...), you know the rest. and if it's really that good,
someone should make a GPL counterpart :-)

i guess that there's a good solution, we simply have to find it :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00434 for ; Sun, 28 Mar 1999 09:13:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:35 +0200 (MEST) Received: (qmail 1963 invoked by uid 0); 19 Aug 2000 00:19:19 -0000 Received: from hn.egroups.com (208.50.99.199) by mx06.rz2.gmx.net with SMTP; 19 Aug 2000 00:19:19 -0000 X-eGroups-Return: sentto-1101623-633-966644353-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 19 Aug 2000 00:19:17 -0000 Received: (qmail 19647 invoked from network); 19 Aug 2000 00:18:59 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 19 Aug 2000 00:18:59 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 19 Aug 2000 00:18:55 -0000 Received: from f-cpu.org (nas3-117.aub.club-internet.fr [195.36.145.117]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA27884 for ; Sat, 19 Aug 2000 02:18:50 +0200 (MET DST) Message-ID: <399DD254.FDEAB58C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 02:18:28 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (i) f-cpu_map.h : new instruction set updates Content-Type: multipart/mixed; boundary="------------AE00EDF795E993E6EBF45F00" X-UIDL: 3c78f9164133c11596189130552e1b2f Status: R X-Status: N --------------AE00EDF795E993E6EBF45F00 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

this is not yet in the manual.

- "permute" : the opcode is reserved. This is a "shuffler" instruction,
the exact behaviour is not yet determined but it has been discussed
in this list.

- "VLIW" : this opcode is reserved. it takes 4 "slots" in the instruction
set, so we have some spare room for future ISA extensions. the behaviour is
not determined, it is equivalent to an unknown opcode trap.

- flushing the TLB : do we need an instruction, or do we do that
with the Special Registers ? the second option would be "cleaner"
and would spare one opcode that is not used much in practice.

- change "mod" to "rem" (semantics of modulo vs remainder).
Any comment on that matter ?

- scatter and gather instructions : opcode reserved.
the actual modus operandi is not determined.

- sdup : it is extended to a new form :
sdup and sdupi duplicate a byte, word, double word etc... at the location
indicated by the first parameter (reg 3, newly used in this instruction)
>from the source register 2, and puts the result in register 1.
an immediate version is planned, replacing the register 3 by an 8-bit data.

this extension uses the previously unused reg3 field and simplifies certain
constucts in wide superscala machines.

- Some old comments from md6nm@mdstud.chalmers.se
(who did a good analysis in december 99) :
---------------------------------------------------------------------------

6.1.3.1 inc: INCrement
6.1.3.2 dec: DECrement
6.1.3.3 neg: NEGation
6.1.3.9 abs: ABSolute value

  Could be packed together into one op-code
  (they all use the Increment Unit, and are all 1r1w)

  At least neg and abs can be packed together.

6.4 Floating Point Operations:

  Some aliases (assuming there is not separate floating point registers)

    fabs     - alias for bclr
    fneg     - alias for bchg

---------------------------------------------------------------------------

- loadaddri : change the semantics of the instruction prefetch version :
the 16-bit immediate data is shifted left by two positions, but not shifted
for loadaddrid. this extends the jump range "a bit or two". is it worth anyway ?
i'm requesting more inputs and comments.


- proposition to use the ASU instead of INC unit, and benefit from an
immediate field for the loops... (Nicolas Boulay).
OTOH, it's not such a good idea : there's a dependency on ONE register
(it gets read and written, it's therefore locked).
a form where the result doesn't get written back to the original register
would be good. let's think a bit about it...

ok i guess it's enough.

i have enclosed the new version of f-cpu_map.h here. we now have 116 reserved
opcode numbers and #define'd 110 opcodes. I'm pretty sure that 99% of the needs
are covered, no need of more "feature creeping". We have to make the manual more coherent.
i'll work on some SW pieces for an asm/sim, starting from this file.

Please, all mails dealing with the instruction set opcodes begin with a (i)
in the subject. This is easier to find them in the archives.


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
--------------AE00EDF795E993E6EBF45F00 Content-Type: application/x-unknown-content-type-H_auto_file; name="f-cpu_map.h" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f-cpu_map.h" I2lmbmRlZiBfX0ZDUFVfTUFQX18NCiNkZWZpbmUgX19GQ1BVX01BUF9fDQoNCi8qDQogICAg Ri1DUFUgT1BDT0RFIE1BUCwgUFJFTElNSU5BUlkgVkVSU0lPTg0KICAgIChDKSBZYW5uIEd1 aWRvbiB2ZW4gbWFyIDMxIDE3OjA2OjQyIENFU1QgMjAwMA0KDQpXYXJuaW5nIDogYSAuaCBm aWxlIGlzIG1lYW50IHRvIGNvbnRhaW4gY29uc3RhbnRzIHRoYXQgbWF5DQpjaGFuZ2UgaW4g dGhlIGZ1dHVyZSwgYW5kIHRoaXMgZmlsZSBpcyBubyBleGNlcHRpb24gIQ0KVGhlIGRlZmlu ZWQgdmFsdWVzIFdJTEwgY2hhbmdlIGFmdGVyIHRoZSBvcGNvZGVzIGFyZQ0KYWxsIGFuYWx5 c2VkLCBzbyBpdCdsbCB0YWtlIGxlc3MgbG9naWMgZ2F0ZXMgdG8gZGVjb2RlIHRoZQ0KaW5z dHJ1Y3Rpb25zLg0KDQoNClRoaXMgZG9jdW1lbnQgaXMgZGVyaXZlZCBmcm9tIHRoZSBidWdn eSBGLUNQVSBtYW51YWwgcmV2LiAwLjENCmFuZCB3aWxsIGNoYW5nZSBxdWlja2x5LiBCZSBz dXJlIHRvIGRvd25sb2FkIHRoZSBtb3N0IHJlY2VudA0KdmVyc2lvbiBhbmQgaW5jbHVkZSBp dCBhcyAiZi1jcHVfbWFwLmgiIGluIHlvdXIgZmlsZXMuDQoNClRoaXMgaXMgZnJlZSBzb2Z0 d2FyZSA7IHNlZSB0aGUgR1BMIGZvciBjb3B5aW5nIGNvbmRprQ0KdGlvbnMuIFRoZXJlIGlz IE5PIHdhcnJhbnR5IDsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWQ0Kb3IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCmNvbnRhY3RzIDogd2h5Z2VlQGYtY3B1 Lm9yZyBvciBmLWNwdUBlR3JvdXBzLmNvbQ0KDQogIE9yZ2FuaXphdGlvbiBvZiB0aGUgb3Bj b2RlcyA6DQpUaGUgZGVmaW5lZCBudW1iZXJzIHJlZmVyIHRvIGEgYnl0ZSBsb2NhdGVkIGlu IGJpdHMgMCB0byA3IGluIHRoZSBpbnN0cnVjdGlvbiB3b3JkLg0KVGhlICItSSIgc3VmZml4 IGlzIG9kZCwgbWVhbmluZyBpOHJyIGZvcm1hdCAodGhpcyBjb3VsZCBiZSBjaGFuZ2VkLCB0 byBhIE1TQiBmb3IgZXhhbXBsZSkuDQpUaGUgaW5zdHJ1Y3Rpb24gImJsb2NrcyIgYXJlIG5v dCBtdWNoIG1vcmUgdGhhbiAzMiBvcGNvZGVzIHNvIHRoZXkgY2FuIGJlIHBhY2tlZA0KIHdp dGggdGhpcyBncmFudWxhcml0eS4NCkFsbCB0aGVzZSBudW1iZXJzIHdpbGwgYmUgcmVvcmdh bml6ZWQgbGF0ZXIgZm9yIHRoZSBWTElXIGJvdW5kYXJ5IHRyaWNrLg0KDQogdG90YWwgY291 bnQgOiAxMDQsIHdpdGhvdXQgY291bnRpbmcgbXVsdGlwbGUgb2NjdXJlbmNlIG9mIEJJVE9Q KEkpLA0KQ09NQklORSh4eCkgYW5kIExPQURDT05TKFgpIA0KDQpJZiBpIGhhdmUgdGltZSBh bmQgZW5lcmd5LCBpJ2xsIG1ha2UgYSBuaWNlIGNvbG9yZWQgSFRNTCB0YWJsZSBvbmUgZGF5 Lg0KKi8NCg0KDQovKg0KdXBkYXRlIDogWUcsIDgvMTkvMjAwMA0KVGhpcyBpcyB0aGUgd29y a2luZyB2ZXJzaW9uIGZvciB0aGUgZmluYWwgbWFudWFsIHYwLjIuDQp2MC4yIHdpbGwgaGF2 ZSB0byBiZSB1cGRhdGVkIHdpdGggdGhlIGRhdGEgaW5jbHVkZWQgaW4gdGhpcyBmaWxlLg0K YWRkZWQgOiA4IG9wY29kZXMgOiBWTElXeCwgU0NBVFRFUiwgR0FUSEVSLCBQRVJNVVRFLg0K cmVkdWNlZCA6IElOQywgREVDLCBBQlMsIE5FRy4NCnRvdGFsIGNvdW50IDoNCiAoUlJSPTQ2 K1JSPTE1K0k4UlI9MjcrSTE2Uj0xMitJMjRSPTEwK05PUCtWTElXKT0xMTIgZGVmaW5lcywN CiBvcGNvZGVzIDogMTE2DQp0aGVyZSdzIGEgIndob2xlIiBhdCBuZWFyIHRoZSBJTkMgYW5k IHNvbWV3aGVyZSBlbHNlLg0Kd2UgYmVnaW4gdG8gYWRkIHNvbWUgYWxpYXNlcyAoX09QX05P UCAuLi4pIGFuZCBvdGhlciBzdHVmZnMuDQoqLw0KDQojZGVmaW5lIF9PUF9MQVNUX09QQ09E RSAgICBfT1BfR0FUSEVSDQovKiAxMjggKi8NCg0KLyoNCiBGb3JtYXQgemVybyA6IFJSUg0K IC0tLS0tLS0tLS0tLS0tLS0tDQogY291bnQ9NDYNCg0KdGhpcyB0YWtlcyBvbmUgaGFsZiBv ZiB0aGUgd2hvbGUgb3Bjb2RlIHRhYmxlICgyNTYgaW5zdHJ1Y3Rpb25zKQ0KDQoqLw0KDQov KiBub3QgYSByZWFsICJvcGVyYXRpb24iIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBkYXRhIGFy ZSBub3QgbW9kaWZpZWQgKi8NCiNkZWZpbmUgX09QX01PVkUgICAgICAgICAwDQovKiBzbyBO T1AgaXMgZGV0ZWN0ZWQgd2l0aCBhbiBpbnN0cnVjdGlvbiBlcXVhbCB0byB6ZXJvICovDQoN CiNkZWZpbmUgX09QX05PUCAwDQovKiBmb2xsb3dlZCBieSAzIGVtcHR5IGJ5dGVzLCBidXQg dGhlIDYgbGFzdCBiaXRzIChkZXN0IHJlZykgY2FuIGJlIHRlc3RlZCBub3cgdG8gc2ltcGxp ZnkgdGhpbmdzLiAqLw0KDQovKiBJbnRlZ2VyIGFyaXRobWV0aWNzICovDQojZGVmaW5lIF9P UF9BREQgICAgICAgICAgMg0KI2RlZmluZSBfT1BfU1VCICAgICAgICAgIDQNCiNkZWZpbmUg X09QX01VTCAgICAgICAgICA2DQojZGVmaW5lIF9PUF9ESVYgICAgICAgICAgOA0KI2RlZmlu ZSBfT1BfTU9EICAgICAgICAgIDEwDQojZGVmaW5lIF9PUF9BRERTVUIgICAgICAgMTINCiNk ZWZpbmUgX09QX01BQyAgICAgICAgICAxMw0KDQovKiBub3QgcmVhbGx5IGFyaXRobWV0aWMu Li4gKi8NCiNkZWZpbmUgX09QX1BPUENPVU5UICAgICAxNA0KDQovKiBJTkMtYmFzZWQgaW5z dHJ1Y3Rpb25zICovDQojZGVmaW5lIF9PUF9DTVBMICAgICAgICAgMjQNCiNkZWZpbmUgX09Q X0NNUExFICAgICAgICAyNg0KI2RlZmluZSBfT1BfTUFYICAgICAgICAgIDI4DQojZGVmaW5l IF9PUF9NSU4gICAgICAgICAgMzANCiNkZWZpbmUgX09QX1NPUlQgICAgICAgICAyMQ0KDQov KiBMTlMgb3BlcmF0aW9ucyAqLw0KI2RlZmluZSBfT1BfTEFERCAgICAgICAgIDMyDQojZGVm aW5lIF9PUF9MU1VCICAgICAgICAgMzMNCg0KLyogU0hMICgic2h1ZmZsZXIiKSBvcGVyYXRp b25zICovDQojZGVmaW5lIF9PUF9TSElGVEwgICAgICAgMzYNCiNkZWZpbmUgX09QX1NISUZU UiAgICAgICAzOA0KI2RlZmluZSBfT1BfU0hJRlRSQSAgICAgIDQwDQojZGVmaW5lIF9PUF9S T1RMICAgICAgICAgNDINCiNkZWZpbmUgX09QX1JPVFIgICAgICAgICA0NA0KI2RlZmluZSBf T1BfQklUT1AgICAgICAgIDQ2DQojZGVmaW5lIF9PUF9CSVRSRVYgICAgICAgNDgNCi8qIFNJ TUQgYW5kIGJ5dGUtc2h1ZmZsaW5nICovDQojZGVmaW5lIF9PUF9NSVggICAgICAgICAgNTIN CiNkZWZpbmUgX09QX0VYUEFORCAgICAgICA1Mw0KI2RlZmluZSBfT1BfU0RVUCAgICAgICAg IDU0DQojZGVmaW5lIF9PUF9QRVJNVVRFICAgICAgMTI2DQoNCi8qIFJPUDIgdW5pdCAobm90 IGNvbXBsZXRlIDogY29tYmluZSBpcyBuZXcpICovDQojZGVmaW5lIF9PUF9MT0dJQyAgICAg ICAgNTYNCiNkZWZpbmUgX09QX0NPTUJJTkVfT1IgICA1OA0KI2RlZmluZSBfT1BfQ09NQklO RV9BTkQgIDU5DQoNCi8qIEZQIChub3QgY29tcGxldGUpICovDQojZGVmaW5lIF9PUF9GQURE ICAgICAgICAgNjQNCiNkZWZpbmUgX09QX0ZTVUIgICAgICAgICA2NQ0KI2RlZmluZSBfT1Bf Rk1VTCAgICAgICAgIDY2DQojZGVmaW5lIF9PUF9GRElWICAgICAgICAgNzENCiNkZWZpbmUg X09QX0ZNQUMgICAgICAgICA3NQ0KI2RlZmluZSBfT1BfRkFERFNVQiAgICAgIDc2DQoNCi8q IExTVSwgZG9tZSBmb3JtcyBhciBhbHNvIGluIGludGVybWVkaWFyeSBmb3JtYXQgKi8NCiNk ZWZpbmUgX09QX0xPQUQgICAgICAgICA4MA0KI2RlZmluZSBfT1BfTE9BREYgICAgICAgIDgy DQojZGVmaW5lIF9PUF9TVE9SRSAgICAgICAgODQNCiNkZWZpbmUgX09QX1NUT1JFRiAgICAg ICA4Ng0KI2RlZmluZSBfT1BfQ0FDSEVNTSAgICAgIDg4DQoNCiNkZWZpbmUgX09QX1NDQVRU RVIgICAgICAxMjcNCiNkZWZpbmUgX09QX0dBVEhFUiAgICAgICAxMjgNCg0KLyogTUlTQyA6 ICovDQovKiBTUkIgOiAqLw0KI2RlZmluZSBfT1BfTE9BRE0gICAgICAgIDEwOA0KI2RlZmlu ZSBfT1BfU1RPUkVNICAgICAgIDExMA0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZp bmUgX09QX0pNUEEgICAgICAgICAxMTYNCg0KDQovKg0KIGludGVybWVkaWFyeSBmb3JtYXQg OiBSUg0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIGNhbiBiZWxvbmcgdG8gZWl0aGVy IFJSUiBvciBJOFJSIChSUlIgc2VlbXMgYmV0dGVyKQ0KIGNvdW50PTE1DQoqLw0KDQovKiBJ TkMtYmFzZWQgaW5zdHJ1Y3Rpb25zICovDQojZGVmaW5lIF9PUF9JTkMgICAgICAgICAgMTYN Ci8qDQogICB0aGUgZm9sbG93aW5nIGZ1bmN0aW9ucyBjYW4gYmUgZW5jb2RlZCBpbiB0aGUg Yml0cyAxMiBhbmQgMTMgIQ0KICAgI2RlZmluZSBfT1BfREVDDQogICAjZGVmaW5lIF9PUF9O RUcNCiAgICNkZWZpbmUgX09QX0FCUw0KKi8NCg0KDQovKiBob2xlIGhlcmUuICovDQoNCiNk ZWZpbmUgX09QX1NDQU4gICAgICAgICAyMA0KDQovKiBMTlMgb3BlcmF0aW9ucyAqLw0KI2Rl ZmluZSBfT1BfTDJJTlQgICAgICAgIDM0DQojZGVmaW5lIF9PUF9JTlQyTCAgICAgICAgMzUN Cg0KLyogU0lNRCBhbmQgYnl0ZS1zaHVmZmxpbmcgKi8NCiNkZWZpbmUgX09QX0JZVEVSRVYg ICAgICA1MA0KDQovKiBGUCwgbm90IGNvbXBsZXRlICovDQojZGVmaW5lIF9PUF9GMklOVCAg ICAgICAgNjcNCiNkZWZpbmUgX09QX0lOVDJGICAgICAgICA2OA0KI2RlZmluZSBfT1BfRklB UFJYICAgICAgIDY5DQojZGVmaW5lIF9PUF9GU1FSVElBUFJYICAgNzANCiNkZWZpbmUgX09Q X0ZTUVJUICAgICAgICA3Mg0KI2RlZmluZSBfT1BfRkxPRyAgICAgICAgIDczDQojZGVmaW5l IF9PUF9GRVhQICAgICAgICAgNzQNCg0KLyogTUlTQyA6ICovDQovKiBTUFIgOiAqLw0KI2Rl ZmluZSBfT1BfR0VUICAgICAgICAgIDEwNA0KI2RlZmluZSBfT1BfUFVUICAgICAgICAgIDEw Ng0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZpbmUgX09QX0xPT1AgICAgICAgICAx MTcgICAgLyogdGhpcyBpc24ndCBnb2luZyB0byBiZSBSUiBvbmx5IGluIHNvbWUgdGltZS4u LiAqLw0KDQovKg0KIEZvcm1hdCBvbmUgOiBJOFJSDQogLS0tLS0tLS0tLS0tLS0tLS0NCiAo cGx1cyBzaWduIGJpdCBpbiBhIDl0aCBiaXQpDQogY291bnQ9MjcNCg0KIGNoYWxsZW5nZSA6 IG1hcCBpdCBzbyBpdCBjb3JyZXNwb25kcyB0byB0aGUgUlJSIGZvcm1hdCB3aGVuZXZlciBw b3NzaWJsZSwNCnNvIHRoZSBkaWZmZXJlbmNlIGlzICJvbmx5IiBvbmUgYml0IGluIG1vc3Qg Y2FzZXMgLT4gZWFzaWVyIGRlY29kaW5nLg0KDQoqLw0KDQovKiBJbnRlZ2VyIGFyaXRobWV0 aWNzICovDQoNCiNkZWZpbmUgX09QX0FEREkgICAgICAgICAzDQojZGVmaW5lIF9PUF9TVUJJ ICAgICAgICAgNQ0KI2RlZmluZSBfT1BfTVVMSSAgICAgICAgIDcNCiNkZWZpbmUgX09QX0RJ VkkgICAgICAgICA5DQojZGVmaW5lIF9PUF9NT0RJICAgICAgICAgMTENCg0KLyogSU5DLWJh c2VkIGluc3RydWN0aW9ucyAqLw0KDQojZGVmaW5lIF9PUF9DTVBMSSAgICAgICAgMjUNCiNk ZWZpbmUgX09QX0NNUExFSSAgICAgICAyNw0KI2RlZmluZSBfT1BfTUFYSSAgICAgICAgIDI5 DQojZGVmaW5lIF9PUF9NSU5JICAgICAgICAgMzENCg0KLyogbm90IHJlYWxseSBhcml0aG1l dGljICovDQojZGVmaW5lIF9PUF9QT1BDT1VOVEkgICAgMTUNCg0KLyogU0hMICgic2h1ZmZs ZXIiKSBvcGVyYXRpb25zICovDQojZGVmaW5lIF9PUF9TSElGVExJICAgICAgMzcNCiNkZWZp bmUgX09QX1NISUZUUkkgICAgICAzOQ0KI2RlZmluZSBfT1BfU0hJRlRSQUkgICAgIDQxDQoj ZGVmaW5lIF9PUF9ST1RMSSAgICAgICAgNDMNCiNkZWZpbmUgX09QX1JPVFJJICAgICAgICA0 NQ0KI2RlZmluZSBfT1BfQklUT1BJICAgICAgIDQ3DQojZGVmaW5lIF9PUF9CSVRSRVZJICAg ICAgNDkNCi8qIFNJTUQgYW5kIGJ5dGUtc2h1ZmZsaW5nICovDQojZGVmaW5lIF9PUF9TRFVQ SSAgICAgICAgNTUNCg0KLyogUk9QMiB1bml0IChub3QgY29tcGxldGUgOiBjb21iaW5lIGlz IG5ldykgKi8NCiNkZWZpbmUgX09QX0xPR0lDSSAgICAgICA1Nw0KI2RlZmluZSBfT1BfQ09N QklORV9PUkkgIDYwDQojZGVmaW5lIF9PUF9DT01CSU5FX0FOREkgNjENCg0KLyogTFNVICov DQojZGVmaW5lIF9PUF9MT0FESSAgICAgICAgODENCiNkZWZpbmUgX09QX0xPQURJRiAgICAg ICA4Mw0KI2RlZmluZSBfT1BfU1RPUkVJICAgICAgIDg1DQojZGVmaW5lIF9PUF9TVE9SRUlG ICAgICAgODcNCiNkZWZpbmUgX09QX0NBQ0hFTU1JICAgICA4OA0KDQovKiBTUkIgOiAqLw0K I2RlZmluZSBfT1BfTE9BRE1JICAgICAgIDEwOQ0KI2RlZmluZSBfT1BfU1RPUkVNSSAgICAg IDExMQ0KDQovKg0KIEZvcm1hdCB0d28gOiBJMTZSDQogLS0tLS0tLS0tLS0tLS0tLS0NCiBj b3VudD0xMg0KICovDQoNCi8qIE1JU0MgOiAqLw0KLyogY2xvc2UgdG8gX09QX01PVkUgKi8N CiNkZWZpbmUgX09QX0xPQURDT05TICAgICA5NiAgIC8qIDQtb3Bjb2RlIHJhbmdlIHNvIHdl IGNhbiBjcmVhdGUgMjU2LWJpdCBpbW1lZGlhdGVzICovDQojZGVmaW5lIF9PUF9MT0FEQ09O U1ggICAgMTAwICAvKiBpZGVtICovDQovKiB0b3RhbCA6IDggb3Bjb2RlcyAqLw0KDQovKiBT UFIgOiAqLw0KI2RlZmluZSBfT1BfR0VUSSAgICAgICAgIDEwNQ0KI2RlZmluZSBfT1BfUFVU SSAgICAgICAgIDEwNw0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZpbmUgX09QX0xP QURBRERSICAgICAxMTQNCiNkZWZpbmUgX09QX0xPQURBRERSSSAgICAxMTUNCg0KLyoNCiBG b3JtYXQgdGhyZWUgOiBJMjQNCiAtLS0tLS0tLS0tLS0tLS0tLS0NCiBjb3VudD0xMA0KKi8N Cg0KLyogU1JCIDogKi8NCiNkZWZpbmUgX09QX1NSQl9TQVZFICAgICAxMTINCiNkZWZpbmUg X09QX1NSQl9SRVNUT1JFICAxMTMNCi8qIGNvbnRyb2wtcmVsYXRlZCAqLw0KI2RlZmluZSBf T1BfU1lTQ0FMTCAgICAgIDExOA0KI2RlZmluZSBfT1BfUkZFICAgICAgICAgIDExOQ0KI2Rl ZmluZSBfT1BfSEFMVCAgICAgICAgIDEyMA0KI2RlZmluZSBfT1BfU0VSSUFMSVpFICAgIDEy MQ0KDQojZGVmaW5lIF9PUF9WTElXICAgICAgICAgMTIyDQojZGVmaW5lIF9PUF9WTElXMCAg ICAgICAgMTIyICAgLyogc2hvdWxkIGJlIHJvdW5kZWQgb24gYSAyLWJpdCBib3VuZGFyeSAh ICovDQojZGVmaW5lIF9PUF9WTElXMSAgICAgICAgMTIzICAgLyogdWx0aW1hdGVseSwgd291 bGQgYmUgb3Bjb2RlICMyNTItMjU1ICovDQojZGVmaW5lIF9PUF9WTElXMiAgICAgICAgMTI0 DQojZGVmaW5lIF9PUF9WTElXMyAgICAgICAgMTI1DQoNCg0KLyogRkMwIEV4ZWN1dGlvbiBV bml0cyAgKi8NCg0KLyogQWRkL1N1YiBVbml0ICovDQojZGVmaW5lIEZDMF9FVV9BU1UgICAg ICAgICAgMQ0KLyogSW50ZWdlciBNdWx0aXBseSBVbml0ICovIA0KI2RlZmluZSBGQzBfRVVf SU1VICAgICAgICAgIDINCi8qIEludGVnZXIgRGl2aWRlIFVuaXQgKi8NCiNkZWZpbmUgRkMw X0VVX0lEVSAgICAgICAgICAzDQovKiBiaXQgIlNodWZmbGVyIiAqLw0KI2RlZmluZSBGQzBf RVVfU0hMICAgICAgICAgIDQNCi8qICJJbmNyZW1lbnRlciIgKi8NCiNkZWZpbmUgRkMwX0VV X0lOQyAgICAgICAgICA1DQovKiBib29sZWFuIG9wZXJhdGlvbnMgKi8NCiNkZWZpbmUgRkMw X0VVX1JPUDIgICAgICAgICA2DQovKiBMb2FkL1N0b3JlIFVuaXQgKi8NCiNkZWZpbmUgRkMw X0VVX0xTVSAgICAgICAgICA3DQovKiBTcGVjaWFsIFJlZ2lzdGVyIFVuaXQgKi8NCiNkZWZp bmUgRkMwX0VVX1NSVSAgICAgICAgICA4DQovKiBQT1B1bGF0aW9uIGNvdW50ICovDQojZGVm aW5lIEZDMF9FVV9QT1AgICAgICAgICAgOQ0KDQojZGVmaW5lIE1BWF9GQzBfRVUgICAgICAg ICAgMTANCi8qIHdpbGwgY2hhbmdlIGxhdGVyICovDQoNCg0KDQoNCiNlbmRpZg0K --------------AE00EDF795E993E6EBF45F00-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00473 for ; Sun, 28 Mar 1999 09:13:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:44 +0200 (MEST) Received: (qmail 21331 invoked by uid 0); 19 Aug 2000 09:06:33 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 19 Aug 2000 09:06:33 -0000 X-eGroups-Return: sentto-1101623-634-966675987-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 19 Aug 2000 09:06:32 -0000 Received: (qmail 30776 invoked from network); 19 Aug 2000 09:06:25 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 19 Aug 2000 09:06:25 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 19 Aug 2000 09:06:25 -0000 Received: from f-cpu.org (nas4-88.ras.club-internet.fr [195.36.203.88]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA19550; Sat, 19 Aug 2000 11:06:21 +0200 (MET DST) Message-ID: <399E4E01.57630B2C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 11:06:09 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6757f64bb3d6001994bbfbf084bd9e38 Status: R X-Status: N hi !

David Cary wrote:
> Dear Y.G.,
>
> Excellent idea.
i thought it was silly, but now we're two ;-)

> So where would the "master list" of everyone on the webring = be stored ? A
> HTML page at egroups.com ? A HTML page at f-cpu.tux.org ? Some sort of=
> ".cgi" active database somewhere ?
i "propose" the opencollector.org database's site.
it has a working archive engine and does a good job
at uniting the Free and Open HW projects.
Of course i would volunteer to help maintain the ring,
as long as the job is low-traffic/priority.

if nothing is possible with Graham, i could probably
arrange something at f-cpu.de or f-cpu.org BUT i have NO
experience with cgis. i can do some shell scripting
and use pipes, that's all :-) i know the necessary HTML
to setup a site, but never used or made a webring.
Using JAva or Javascript is not a thing to be considered,
at least on the remote page. so any help is welcome.

i do not think that we even need to use a public
("free ads for all") service. i have the ressources but not the knowledge. the last solution would be in my account in the
university but i don't know how long it will stay opened.
and i'd have to request the sysad's help because i presume that
the CGIs are not allowed.

If Graham shows me how to do some simple stuffs at seul.org,
i could maybe do the job, but i need one or two examples.

> Please add me
>   http://www.rdrop.com/~cary/html/computer_architecture.html=
> to the list.
i've seen it a while back, and it's still so amazing :-)

> Anything special I need to do ?
update the f-cpu entries ;-) (new sites, tux site is
soon closed, instruction set...)

let's find a definition/presentation of the ring :
name : Utopia Computing Webring (i can't find anyhing more general and desc= riptive)
definition : links together useful/resourceful pages dealing
with (but not only) : Computer Architecture (theory and practice),
Open Hardware initiatives, The F-CPU and similar projects.
We work towards a better platform, because a free computer is not
only free software.


A similar interesting thing would be to have a collection of
related, somewhat random, links. a bit like on David's page,
but that the f-cpuers contribute. there, we don't need CGIs,
informal manual additions do the trick.


Waiting for your submissions and help, (Jamil ?)
YG


PS: so, i read your page and a discussion remembered that there
was the question whether we'd include a "select" instruction
(similar to MUX in the DLX). it is not used often, but when it's needed, it is really helpful.


> >Organization: Association F-CPU
> >To: fm <f-cpu@egroups.com>
> >From: Yann Guidon <whygee@f-cpu.org>
> >Date: Sun, 16 Jul 2000 13:50:25 +0200
> ..
> >could we make a f-cpu webring ?
> >if you have a f-cpu-related webpage, we could
> >thus link them together...
> ..
> >the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> >SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
>
> --
> David Cary "mailto:d.cary@ieee.org" ><> <*> O= -
>   http://www.rdrop.c= om/~cary/
> "icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.8= 30' W97 03.443'")

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
=
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00485 for ; Sun, 28 Mar 1999 09:13:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:47 +0200 (MEST) Received: (qmail 14328 invoked by uid 0); 19 Aug 2000 10:28:55 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 19 Aug 2000 10:28:55 -0000 X-eGroups-Return: sentto-1101623-635-966680933-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 19 Aug 2000 10:28:54 -0000 Received: (qmail 2363 invoked from network); 19 Aug 2000 10:28:53 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 19 Aug 2000 10:28:53 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 19 Aug 2000 10:28:52 -0000 Received: from morphin.marquardt-home.de (d72.nas21.sonic.net [209.204.136.72]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id MAA26708; Sat, 19 Aug 2000 12:28:47 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13Q5rk-0000OT-00; Sat, 19 Aug 2000 03:28:40 -0700 To: f-cpu@egroups.com References: In-Reply-To: Steve Van der Hoeven's message of "Fri, 18 Aug 2000 12:49:18 -0500 (CDT)" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 40 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 19 Aug 2000 03:28:40 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VGUI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fbee43651d0413d979200961a90c8c5e Status: R X-Status: N * Steve Van der Hoeven <vanderho@essi.fr> writes:

> On Fri, 18 Aug 2000, Nathaniel Downes wrote:

>> Previously, you (Colin Marquardt) wrote:
>> >
>> > [ attachment ]

Huh? Not really an attachment, just normal text. :-)

[structural composition in next emacs' vhdl-mode]

>> This is good news, considering I use EMACS for all of my VHDL editing work.
>>
>> I wonder how hard it would be to make a graphical interface for it.
>>

> Not in emacs it self, neither xemacs.
> They only manipulate text, but you can make tools to navigate more easily
> throught your code.

If you have tried speedbar with a recent vhdl-mode, it is already
there.  It shows the hierarchy, and lets you jump to every design
unit. And of course, it can generate makefiles from its knowledge of
the hierarchy. Plus much more.

And, Yann: if you mean the old vhdl-electric package with "electric
mode": this is *oooold*. The current vhdl-mode is a merger of the
two old packages, plus a lot of improvements. I would go as far as
to say that it is the most mature of all emacs modes (but of course,
I have not tried every single mode...). Verilog-mode is nothing in
comparison.

Colin

PS: Yes, I *do* own the author a few beers.
    But that's all.
    Nothing more.
    Really.
    Promised.
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00488 for ; Sun, 28 Mar 1999 09:13:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Mar 1999 09:13:48 +0200 (MEST) Received: (qmail 21184 invoked by uid 0); 19 Aug 2000 10:45:34 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 19 Aug 2000 10:45:34 -0000 X-eGroups-Return: sentto-1101623-636-966681930-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c3.egroups.com with NNFMP; 19 Aug 2000 10:45:33 -0000 Received: (qmail 21756 invoked from network); 19 Aug 2000 10:45:30 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 19 Aug 2000 10:45:30 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 19 Aug 2000 10:45:24 -0000 Received: from f-cpu.org (nas2-208.ras.club-internet.fr [195.36.192.208]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA16322 for ; Sat, 19 Aug 2000 12:45:21 +0200 (MET DST) Message-ID: <399E6530.8B5EFEDA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 12:45:04 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] webring ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e8284b40c46602a239d33af984a87281 Status: R X-Status: N hello,

for the webring, i see a rather simple way to do this.

on the webpage, there are 3 links :
-previous
-list
-next
they point to the same thing (a CGI or PHP or whatever)
and they have 2 arguments : action and id.
if it works on f-cpu.de, it can be :
<a href=3D"http://www.f-cpu.de/webring?id=3Dmy_site&action=3Dprev&q= uot;>Previous site</a>
<a href=3D"http://www.f-cpu.de/webring?id=3Dmy_site&action=3Dlist&q= uot;>Site list</a>
<a href=3D"http://www.f-cpu.de/webring?id=3Dmy_site&action=3Dnext&q= uot;>Next site</a>

"my_site" would be an identifier ("i'm not a number !")= so there's no number
to manage. a linear file of id:URL fields would do the trick :
if action is "list" then display the file (with nice formatting)<= BR> else
  search the id in the file,
  if action is "prev" rewind one line
  else advance one line
    display the line as :

<HTML>
<HEAD>
   <META HTTP-EQUIV=3D"REFRESH" CONTENT=3D"0; U= RL=3D xxxx  ">
   <TITLE>FCPU WEBRING - JUMP</TITLE>
</HEAD>
<body text=3D"#FAFF20" bgcolor=3D"#6C536A" link=3D&q= uot;#FFE81A" vlink=3D"#00E0F9" alink=3D"#00CC00"&g= t;

<FONT SIZE=3D-1>
F-CPU Team's webring<BR></FONT>
<HR>
<CENTER>
<P>Please wait while you are redirected to the requested site.<p&g= t;
If the redirection does not work, click here : <a href=3Dxxxx> xxxx &= lt;/a>
</CENTER>

<P>&nbsp;<P><HR>
<FONT SIZE=3D-1>(C) 2000 www.f-cpu.de Webring</FONT>
</BODY>
</HTML>

xxxx is the URL. with the meta refresh, it's easy to redirect people.
there's maybe another way but i don't know.

In practice, webrings are not very much used. But it can act as a cement in the Utopic Computer Community and it's a good occasion to play with
new toys :-P

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01462 for ; Sat, 19 Aug 2000 22:11:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 19 Aug 2000 22:11:07 +0200 (MEST) Received: (qmail 664 invoked by uid 0); 19 Aug 2000 19:11:36 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 19 Aug 2000 19:11:36 -0000 X-eGroups-Return: sentto-1101623-637-966712291-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 19 Aug 2000 19:11:37 -0000 Received: (qmail 20640 invoked from network); 19 Aug 2000 19:11:30 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 19 Aug 2000 19:11:30 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 19 Aug 2000 19:11:30 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id OAA27143 for ; Sat, 19 Aug 2000 14:11:29 -0500 (CDT) To: fm In-Reply-To: <399E4E01.57630B2C@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 14:11:29 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d3384401b3d3482db72ac9d22560e73 Status: R X-Status: N

On Sat, 19 Aug 2000, Yann Guidon wrote:

> hi !
>
> David Cary wrote:
> > Dear Y.G.,
> >
> > Excellent idea.
> i thought it was silly, but now we're two ;-)
>
>
> if nothing is possible with Graham, i could probably
> arrange something at f-cpu.de or f-cpu.org BUT i have NO
> experience with cgis. i can do some shell scripting
> and use pipes, that's all :-) i know the necessary HTML
> to setup a site, but never used or made a webring.
> Using JAva or Javascript is not a thing to be considered,
> at least on the remote page. so any help is welcome.
>

No problem, ask me and I will advise you. I know a lot about web
servers and dynamic information...

> i do not think that we even need to use a public
> ("free ads for all") service. i have the ressources but not the
> knowledge. the last solution would be in my account in the
> university but i don't know how long it will stay opened.
> and i'd have to request the sysad's help because i presume that
> the CGIs are not allowed.
>

If you can open a socket server, usually the admins allow it above 1024,
then I have written a webserver in scheme with good performances. And it's
one you can run withour being root.

> If Graham shows me how to do some simple stuffs at seul.org,
> i could maybe do the job, but i need one or two examples.
>
> > Please add me
> >   http://www.rdrop.com/~cary/html/computer_architecture.html
> > to the list.
> i've seen it a while back, and it's still so amazing :-)
>
> > Anything special I need to do ?
> update the f-cpu entries ;-) (new sites, tux site is
> soon closed, instruction set...)
>

--steve
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01468 for ; Sat, 19 Aug 2000 22:11:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 19 Aug 2000 22:11:09 +0200 (MEST) Received: (qmail 29337 invoked by uid 0); 19 Aug 2000 19:16:38 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 19 Aug 2000 19:16:38 -0000 X-eGroups-Return: sentto-1101623-638-966712592-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ei.egroups.com with NNFMP; 19 Aug 2000 19:16:38 -0000 Received: (qmail 32762 invoked from network); 19 Aug 2000 19:16:32 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 19 Aug 2000 19:16:32 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 19 Aug 2000 19:16:32 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id OAA27194 for ; Sat, 19 Aug 2000 14:16:31 -0500 (CDT) To: fm In-Reply-To: <399E6530.8B5EFEDA@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 14:16:31 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 20a766cc96b88c85e961486f36668121 Status: R X-Status: N

On Sat, 19 Aug 2000, Yann Guidon wrote:

> hello,
>
> for the webring, i see a rather simple way to do this.
>
> on the webpage, there are 3 links :
> -previous
> -list
> -next
> they point to the same thing (a CGI or PHP or whatever)
> and they have 2 arguments : action and id.
> if it works on f-cpu.de, it can be :
> <a href="http://www.f-cpu.de/webring?id=my_site&action=prev">Previous site</a>
> <a href="http://www.f-cpu.de/webring?id=my_site&action=list">Site list</a>
> <a href="http://www.f-cpu.de/webring?id=my_site&action=next">Next site</a>
>
> "my_site" would be an identifier ("i'm not a number !") so there's no number
> to manage. a linear file of id:URL fields would do the trick :
> if action is "list" then display the file (with nice formatting)
> else
>   search the id in the file,
>   if action is "prev" rewind one line
>   else advance one line
>     display the line as :
>

No problem, now you should look to what technologies we have acess: cgi,
php, jsp, servlet, asp.... Or schemelets!(okay, I know I try to put in
front my own work)

Then you will be able to choose an implementation


--stev
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01731 for ; Sat, 19 Aug 2000 23:07:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 19 Aug 2000 23:07:46 +0200 (MEST) Received: (qmail 27196 invoked by uid 0); 19 Aug 2000 20:20:29 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 19 Aug 2000 20:20:29 -0000 X-eGroups-Return: sentto-1101623-639-966716424-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 19 Aug 2000 20:20:28 -0000 Received: (qmail 2296 invoked from network); 19 Aug 2000 20:20:24 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 19 Aug 2000 20:20:24 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 19 Aug 2000 20:20:24 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA07792 for f-cpu@egroups.com; Sat, 19 Aug 2000 16:20:23 -0400 Message-Id: <200008192020.QAA07792@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: from "Steve Van der Hoeven" at Aug 19, 2000 02:11:29 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 16:20:23 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 064a8073c6f34e0f382ce75de0367de8 Status: R X-Status: N > >
> > if nothing is possible with Graham, i could probably
> > arrange something at f-cpu.de or f-cpu.org BUT i have NO
> > experience with cgis. i can do some shell scripting
> > and use pipes, that's all :-) i know the necessary HTML
> > to setup a site, but never used or made a webring.
> > Using JAva or Javascript is not a thing to be considered,
> > at least on the remote page. so any help is welcome.
> >
>
> No problem, ask me and I will advise you. I know a lot about web
> servers and dynamic information...

I've never done a webring either, but I'm happy to help out if I can.
Be great if Steve could advise me what I need to do, though.
>
> > i do not think that we even need to use a public
> > ("free ads for all") service. i have the ressources but not the
> > knowledge. the last solution would be in my account in the
> > university but i don't know how long it will stay opened.
> > and i'd have to request the sysad's help because i presume that
> > the CGIs are not allowed.
> >
>
> If you can open a socket server, usually the admins allow it above 1024,
> then I have written a webserver in scheme with good performances. And it's
> one you can run withour being root.
>
The sysadmins on the machine open collector is on now are a little nervous
about system security (lots of problems with crackers using open ports).
But I'll ask. And I'd love to see a webserver in scheme...

> > If Graham shows me how to do some simple stuffs at seul.org,
> > i could maybe do the job, but i need one or two examples.
I'll see if I can get an account for YG.
> >
Graham
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01402 for ; Sun, 20 Aug 2000 04:57:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:52 +0200 (MEST) Received: (qmail 26661 invoked by uid 0); 20 Aug 2000 01:11:30 -0000 Received: from jk.egroups.com (208.50.144.83) by mx06.rz2.gmx.net with SMTP; 20 Aug 2000 01:11:30 -0000 X-eGroups-Return: sentto-1101623-640-966733883-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 20 Aug 2000 01:11:24 -0000 Received: (qmail 30250 invoked from network); 20 Aug 2000 01:11:22 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 20 Aug 2000 01:11:22 -0000 Received: from unknown (HELO mail5.primary.net) (216.87.38.199) by mta1 with SMTP; 20 Aug 2000 01:11:22 -0000 Received: from [192.168.1.40] (ip141-tc3.busprod.com [207.150.72.141]) by mail5.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id e7K148B05105; Sat, 19 Aug 2000 20:04:11 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <397628BF.2251C953@nventure.com> References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> To: f-cpu@egroups.com, MISC@pisa.rockefeller.edu Cc: l.geppert@ieee.org From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 20:12:36 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] small and simple processors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3d0a44c3045326c21d35597c51686964 Status: R X-Status: N
Dear cpu designers,

"Microprocessors: the off-beat generation" article by Linda Geppert in
_IEEE Spectrum_ 2000-07
has some fascinating information that is surprisingly reminiscent of some
things we've recently talked about.

Geppert talks about 3 specific designs, and points out that 2 of them use
multithreading (weren't we just talking about SMT ?).

  Blue Gene to solve "the protein-folding problem" for a single protein in
"only" 1 year. A 1 petaflops supercomputer built over a million individual
processors. Each 1 gigaflop processor contains 8 "thread units", a
floating-point unit, and some local memory. About 32 of these processors
are put on a chip, and the chips are placed in a 3 D array of 32 x 32 x 32
identical chips. Blue Gene architect Denneau trimmed the number of
instructions to 57 (practically MISC). (Originally designed for real-time
raytracing videos). Denneu expects "Every 4 days, on average, a processor
will fail".
  http://www.research.ibm.com/bluegene/
  http://www.research.ibm.com/resources/magazine/1999/number_4/bluegene499.html

  MAJC-5200 to process video signals "at wire speed" and "to be the fastest
JAVA processor in the world". A 2 gigaflops network processor built from 2
processors. A single CPU chip that has a shared data cache, 2 processing
units with their own local instruction cache. "In the past, the processor
executed roughly 1 memory operation for every 2 computations. Today it is 1
for every 10." Uses VLIW and space-time speculative execution a la Albert
Abramson.
  http://www.sun.com/microelectronics/MAJC

  Nios. A system-on-a-programmable-chip including a 50 MIPS processor.
Altera APEX FPGA chips, like most other FPGAs, are an array of LEs (a 4
input lookup table and a flip-flop) and RAM/CAM.
. The 16 bit version of Nios uses only 1 100 APEX LEs. "engineers ...
individually consider each logic gate" (weren't we just talking about how
manually tweaking a design could give surprisingly large 10x speedups ?).
Includes a timer and UART that can each interrupt the CPU. Some of the pins
of the FPGA are used up by the serial port and the FLASH memory / SRAM
interface.
Even the smallest APEX chip can hold a Nios with lots of room for Good
Stuff left over (perhaps even multiple Nios CPUs ?).
Altera APEX chips range from
  2 560 LEs (EP20K60E) ($ 76.00 )
  4 160 LEs (EP20K100E) ($ 90.00 )
  38 400 LEs (EP20K1000E) ($ 3 600.00 )
  51 840 LEs (EP20K1500E) ($ 5 150.00 )
(prices as of 2000-08-19 from
  http://Arrow.com/
).
  http://www.altera.com/html/mega/m-alt-nios.html
  http://www.altera.com/html/products/nios.html


>From: Albert Abramson <maxx@nventure.com>
>Date: Wed, 19 Jul 2000 15:16:31 -0700
>Subject: Re: [f-cpu] VHDL
...
>Point being that I like VLIW more for these very reasons.  It's not only
>proven technology that we can understand (knowing more about its
>shortcomings than its early implementors), but performance improvements
>can come by tweaking the wire and the design by hand.  It's still small
>enough and simple enough to hand optimize at the gate level.  It's like
>the difference between hand assembled code and compiler optimized code.  A
>smart software engineer can always outperform any computer generation
>program.  VLIW lets you make one mask and then tweak it forever to get
>better performance out of it.
...
>--Maxx

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01405 for ; Sun, 20 Aug 2000 04:57:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:53 +0200 (MEST) Received: (qmail 29102 invoked by uid 0); 20 Aug 2000 01:48:12 -0000 Received: from c9.egroups.com (208.50.99.230) by mx06.rz2.gmx.net with SMTP; 20 Aug 2000 01:48:12 -0000 X-eGroups-Return: sentto-1101623-641-966736085-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 20 Aug 2000 01:48:10 -0000 Received: (qmail 8027 invoked from network); 20 Aug 2000 01:48:04 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 20 Aug 2000 01:48:04 -0000 Received: from unknown (HELO femail3.sdc1.sfba.home.com) (24.0.95.83) by mta1 with SMTP; 20 Aug 2000 01:48:04 -0000 Received: from nventure.com ([24.10.43.202]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000820014737.KCXB28670.femail3.sdc1.sfba.home.com@nventure.com> for ; Sat, 19 Aug 2000 18:47:37 -0700 Message-ID: <399F38D2.72D69762@nventure.com> X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en To: f-cpu@egroups.com References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> From: Albert Abramson MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 18:48:09 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] small and simple processors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ea44648bc5b09a875e0d92464c07e42 Status: R X-Status: N I've been thinking about real time raytracing as an application for
supercomputing.  It is a very poorly served market, and we could address this
one.  As it turns out, raytracing uses a lot of look ups for its many
trigonometric operations, and would benefit tremendously from very high floating
point throughput.  Also, single precision doesn't quite do it.  Most raytracing
algorithms need more than 32 bits of mantissa (singles offer only 24), but don't
need all of the neat rounding modes and exception handling.  This creates a nice
opportunity for designing a highly specialized raytracing supercomputer that
economizes in all the right places.

The market is certainly there.  Both Hollywood and arcades are looking for
something to get ahead of the PC and video game console market that depend on
traditional vector graphics.  This is ablsolutely an area where VLIW would be
valuable.  This is definitely an area where pipelines could be straightened and
made deeper.  This is definitely an area where economical wiring is possible
because you can almost always get more work into the hardware at any given moment,
and you can balance the entire system for one set of closely related algorithms
and tasks.

This is absolutely an area where SMT could bring all sorts of advantages.

--Maxx

David Cary wrote:

> Dear cpu designers,
>
> "Microprocessors: the off-beat generation" article by Linda Geppert in
> _IEEE Spectrum_ 2000-07
> has some fascinating information that is surprisingly reminiscent of some
> things we've recently talked about.
>
> Geppert talks about 3 specific designs, and points out that 2 of them use
> multithreading (weren't we just talking about SMT ?).
>
>   Blue Gene to solve "the protein-folding problem" for a single protein in
> "only" 1 year. A 1 petaflops supercomputer built over a million individual
> processors. Each 1 gigaflop processor contains 8 "thread units", a
> floating-point unit, and some local memory. About 32 of these processors
> are put on a chip, and the chips are placed in a 3 D array of 32 x 32 x 32
> identical chips. Blue Gene architect Denneau trimmed the number of
> instructions to 57 (practically MISC). (Originally designed for real-time
> raytracing videos). Denneu expects "Every 4 days, on average, a processor
> will fail".
>   http://www.research.ibm.com/bluegene/
>   http://www.research.ibm.com/resources/magazine/1999/number_4/bluegene499.html
>
>   MAJC-5200 to process video signals "at wire speed" and "to be the fastest
> JAVA processor in the world". A 2 gigaflops network processor built from 2
> processors. A single CPU chip that has a shared data cache, 2 processing
> units with their own local instruction cache. "In the past, the processor
> executed roughly 1 memory operation for every 2 computations. Today it is 1
> for every 10." Uses VLIW and space-time speculative execution a la Albert
> Abramson.
>   http://www.sun.com/microelectronics/MAJC
>
>   Nios. A system-on-a-programmable-chip including a 50 MIPS processor.
> Altera APEX FPGA chips, like most other FPGAs, are an array of LEs (a 4
> input lookup table and a flip-flop) and RAM/CAM.
> . The 16 bit version of Nios uses only 1 100 APEX LEs. "engineers ...
> individually consider each logic gate" (weren't we just talking about how
> manually tweaking a design could give surprisingly large 10x speedups ?).
> Includes a timer and UART that can each interrupt the CPU. Some of the pins
> of the FPGA are used up by the serial port and the FLASH memory / SRAM
> interface.
> Even the smallest APEX chip can hold a Nios with lots of room for Good
> Stuff left over (perhaps even multiple Nios CPUs ?).
> Altera APEX chips range from
>   2 560 LEs (EP20K60E) ($ 76.00 )
>   4 160 LEs (EP20K100E) ($ 90.00 )
>   38 400 LEs (EP20K1000E) ($ 3 600.00 )
>   51 840 LEs (EP20K1500E) ($ 5 150.00 )
> (prices as of 2000-08-19 from
>   http://Arrow.com/
> ).
>   http://www.altera.com/html/mega/m-alt-nios.html
>   http://www.altera.com/html/products/nios.html
>
> >From: Albert Abramson <maxx@nventure.com>
> >Date: Wed, 19 Jul 2000 15:16:31 -0700
> >Subject: Re: [f-cpu] VHDL
> ...
> >Point being that I like VLIW more for these very reasons.  It's not only
> >proven technology that we can understand (knowing more about its
> >shortcomings than its early implementors), but performance improvements
> >can come by tweaking the wire and the design by hand.  It's still small
> >enough and simple enough to hand optimize at the gate level.  It's like
> >the difference between hand assembled code and compiler optimized code.  A
> >smart software engineer can always outperform any computer generation
> >program.  VLIW lets you make one mask and then tweak it forever to get
> >better performance out of it.
> ...
> >--Maxx
>
> --
> David Cary "mailto:d.cary@ieee.org" ><> <*> O-
>   http://www.rdrop.com/~cary/
> "icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
>
>

From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01408 for ; Sun, 20 Aug 2000 04:57:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:55 +0200 (MEST) Received: (qmail 30046 invoked by uid 0); 20 Aug 2000 02:01:47 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 20 Aug 2000 02:01:47 -0000 X-eGroups-Return: sentto-1101623-642-966736900-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by b05.egroups.com with NNFMP; 20 Aug 2000 02:01:42 -0000 Received: (qmail 11793 invoked from network); 20 Aug 2000 02:01:39 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 20 Aug 2000 02:01:39 -0000 Received: from unknown (HELO mail2.primary.net) (216.87.38.218) by mta1 with SMTP; 20 Aug 2000 02:01:39 -0000 Received: from [192.168.1.40] (ip36-htc1.busprod.com [207.150.74.36]) by mail2.primary.net (8.10.0+jb/8.10.0/8.10-0+tht) with ESMTP id e7K1sSZ01228 for ; Sat, 19 Aug 2000 20:54:29 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: <3959C1C7.28CF4AF6@hl.siemens.de> References: <001e01bfe066$19437300$3bf43cd0@0018728164> <3959AB0D.4DD00634@hl.siemens.de> To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 20:59:44 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 622133d862ddc9b8ce87f71a909714e6 Status: R X-Status: N
Dear Nicolas Boulay,

Thank you very much for sharing that paper with us. I found it fascinating.
I believe this originally came from
  http://www-cse.ucsd.com/~tullsen/smtcompilerabstract.html
  http://www.cs.washington.edu/research/smt/papers/smtcompilerabstract.html
.

Both of these sites have several other articles that might be relevant.
  Dean M. Tullsen
  http://www-cse.ucsd.com/~tullsen/
is one of the authors of that paper, and
  Simultaneous Multithreading Project
  http://www.cs.washington.edu/research/smt
includes 2 of the other authors of that paper.

>From: Nicolas Boulay <emstud2@hl.siemens.de>
>Date: Wed, 28 Jun 2000 11:13:43 +0200
>Subject: Re: [f-cpu] SMT
...
>I don't remember where i found this paper.
...
>Attachment converted: root:smtcompiler.ps (TEXT/mlpr) (00020D01)

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01414 for ; Sun, 20 Aug 2000 04:57:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:56 +0200 (MEST) Received: (qmail 13550 invoked by uid 0); 20 Aug 2000 02:23:14 -0000 Received: from mq.egroups.com (208.50.144.79) by mx06.rz2.gmx.net with SMTP; 20 Aug 2000 02:23:14 -0000 X-eGroups-Return: sentto-1101623-643-966738191-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 20 Aug 2000 02:23:12 -0000 Received: (qmail 28572 invoked from network); 20 Aug 2000 02:23:10 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Aug 2000 02:23:10 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 20 Aug 2000 02:23:10 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id VAA01600 for ; Sat, 19 Aug 2000 21:23:09 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <399F38D2.72D69762@nventure.com> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 21:23:09 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] small and simple processors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 101681d9727e0a7f40fdd01fc0795328 Status: R X-Status: N

On Sat, 19 Aug 2000, Albert Abramson wrote:

> I've been thinking about real time raytracing as an application for
> supercomputing.

It's a heavy job for the processor.

> It is a very poorly served market, and we could address this
> one.

add functions that would lighter ray tracing software, yes why not. You
have the same computing problems in motion planning for robots...
make a processor only for that market?

> As it turns out, raytracing uses a lot of look ups for its many
> trigonometric operations, and would benefit tremendously from very high floating
> point throughput.

the actual trigonmertic functions use a precalculated table of values and
then makes an approximation for the values inbetween two precalculated
values.

To make the process faster you need more silicon.

> Also, single precision doesn't quite do it.  Most raytracing
> algorithms need more than 32 bits of mantissa (singles offer only 24), but don't
> need all of the neat rounding modes and exception handling.  This creates a nice
> opportunity for designing a highly specialized raytracing supercomputer that
> economizes in all the right places.
>

> The market is certainly there.  Both Hollywood and arcades are looking for
> something to get ahead of the PC and video game console market that depend on
> traditional vector graphics.

This market is very special: hte software and the hardware are linked,
that is the succes of sgi

> This is ablsolutely an area where VLIW would be
> valuable.  This is definitely an area where pipelines could be straightened and
> made deeper.  This is definitely an area where economical wiring is possible
> because you can almost always get more work into the hardware at any given moment,
> and you can balance the entire system for one set of closely related algorithms
> and tasks.
>
> This is absolutely an area where SMT could bring all sorts of advantages.
>
> --Maxx
>

--Steve
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01417 for ; Sun, 20 Aug 2000 04:57:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:57 +0200 (MEST) Received: (qmail 15890 invoked by uid 0); 20 Aug 2000 02:32:18 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 20 Aug 2000 02:32:18 -0000 X-eGroups-Return: sentto-1101623-644-966738729-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 20 Aug 2000 02:32:07 -0000 Received: (qmail 14877 invoked from network); 20 Aug 2000 02:32:05 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Aug 2000 02:32:05 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 20 Aug 2000 02:32:05 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id VAA01678 for ; Sat, 19 Aug 2000 21:32:05 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 21:32:04 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b79b94b485adfb5eeed73529d7ff2735 Status: R X-Status: N
This page speaks about a single memory adress space and its runtime
protection.

http://www.cs.washington.edu/homes/levy/opal/opal.html

interessting.

--Steve
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01420 for ; Sun, 20 Aug 2000 04:57:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 04:57:58 +0200 (MEST) Received: (qmail 12270 invoked by uid 0); 20 Aug 2000 02:57:13 -0000 Received: from mu.egroups.com (208.50.99.218) by mx11.rz2.gmx.net with SMTP; 20 Aug 2000 02:57:13 -0000 X-eGroups-Return: sentto-1101623-645-966740231-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 20 Aug 2000 02:57:12 -0000 Received: (qmail 29347 invoked from network); 20 Aug 2000 02:57:11 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Aug 2000 02:57:11 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta1 with SMTP; 20 Aug 2000 02:57:10 -0000 Received: from modem-68.dextromethorphn.dialup.pol.co.uk ([62.136.90.196] helo=llandre.freeserve.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13QLIJ-0005dz-00 for f-cpu@egroups.com; Sun, 20 Aug 2000 03:57:08 +0100 Sender: root@pop.gmx.net Message-ID: <399F4C1D.9D6187B1@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <000801bff1c6$82b9da60$1c18d7d1@0018728164> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 Aug 2000 04:10:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] small and simple processors Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0f23e706607181287b053828acbd938 Status: R X-Status: N David Cary wrote:

> Dear cpu designers,
>
> "Microprocessors: the off-beat generation" article by Linda Geppert in
> _IEEE Spectrum_ 2000-07
> has some fascinating information that is surprisingly reminiscent of some
> things we've recently talked about.
>

> <snip>
>   Blue Gene to solve "the protein-folding problem" for a single protein in
> "only" 1 year. A 1 petaflops supercomputer built over a million individual
> processors. Each 1 gigaflop processor contains 8 "thread units", a
> floating-point unit, and some local memory. About 32 of these processors
> are put on a chip, and the chips are placed in a 3 D array of 32 x 32 x 32
> identical chips. Blue Gene architect Denneau trimmed the number of
> instructions to 57 (practically MISC). (Originally designed for real-time
> raytracing videos). Denneu expects "Every 4 days, on average, a processor
> will fail".

And they all laughed at my "piranha school" concept of a lot of low tech cpus.
Actually, I think the idea was around before me, as it appears all Soviet
supercomputers
were built along these lines (just like all other soviet things - why have a
$25000000 jet
when you can make 200 of them for the same price at a lower tech level). The west
laughed until
simulations showed that pretty soon we'd have to be using battlefield nukes to
keep the 10000s of
soviet WW2 tanks out of Europe.

Jeff Davies
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01674 for ; Sun, 20 Aug 2000 06:40:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 06:40:06 +0200 (MEST) Received: (qmail 3463 invoked by uid 0); 20 Aug 2000 03:01:04 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 20 Aug 2000 03:01:04 -0000 X-eGroups-Return: sentto-1101623-646-966740462-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 20 Aug 2000 03:01:00 -0000 Received: (qmail 4509 invoked from network); 20 Aug 2000 03:01:02 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Aug 2000 03:01:02 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 20 Aug 2000 03:01:01 -0000 Received: from f-cpu.org (nas3-97.aub.club-internet.fr [195.36.145.97]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA04657; Sun, 20 Aug 2000 05:00:44 +0200 (MET DST) Message-ID: <399F49D3.2B8EB1D1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 Aug 2000 05:00:35 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] webring ? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f936aead5467afe576dee1d6b7c4a600 Status: R X-Status: N hello !!!


thanks for the positive answers for this silly but
probably funny project. the funniest thing is
that now i'm sure it will work, but i still
don't know how :-D

Steve Van der Hoeven wrote:
> > so any help is welcome.
> No problem, ask me and I will advise you. I know a lot about web
> servers and dynamic information...

fantastic ! :-) while Sven is absent, there's someone else
to help us with the sites :-)

> > the last solution would be in my account in the
> > university but i don't know how long it will stay opened.
> > and i'd have to request the sysad's help because i presume that > > the CGIs are not allowed.
> If you can open a socket server, usually the admins allow it above 102= 4,
> then I have written a webserver in scheme with good performances. And = it's
> one you can run withour being root.

hmmm now that i think about it,
i don't know how the university's firewall will behave.
i don't think that i could do this there easily.


> > "my_site" would be an identifier ("i'm not a numbe= r !") so there's no number
> > to manage. a linear file of id:URL fields would do the trick : > > if action is "list" then display the file (with nice fo= rmatting)
> > else
> >   search the id in the file,
> >   if action is "prev" rewind one line
> >   else advance one line
> >     display the line as :
> >
>
> No problem, now you should look to what technologies we have acess: cg= i,
> php, jsp, servlet, asp.... Or schemelets!(okay, I know I try to put in=
> front my own work)
>
> Then you will be able to choose an implementation

i've looked a bit at the PHP3 source pages of f-cpu.de,
it's not straightforward but it's a procedural langage like others...
another problem is : at f-cpu.de, i have ftp access but no shell access. this keeps me from using the local database with private files.
If there is some simple file I/O capabilities from the PHP3 pages,
the database file could be located in the same directory as the PHP3 page.<= BR>
there's probably a better way to implement this, that's why i ask for help<= BR> and ask Graham if he could play a role in the story :-) The algorithm i des= cribed
shows to what extent i do understand how the web works : not bad but
rather "rudimentary" :-) i'm far from Graham's forms, comments, d= atabase,
submissions, bugs, etc... :-D




graham@belegost.mit.edu wrote:
> > No problem, ask me and I will advise you. I know a lot about web<= BR> > > servers and dynamic information...
> I've never done a webring either, but I'm happy to help out if I can.<= BR> > Be great if Steve could advise me what I need to do, though.

:-)

Anyway, when i look at your site, i believe that you have done
most of the hard work already. we only need to adapt the little
algorithm described before.

> The sysadmins on the machine open collector is on now are a little ner= vous
> about system security (lots of problems with crackers using open ports= ).
is THAT necessary ? (to play with ports ect)
the port 80 should do the trick... at least i think that nothing complex is=
necessary. if the cgi is reduced to a shell script, i think that i can
do most of it. but i don't think that we can play with the ports from
a script. why would we need anyway ?

ok, that's far from the FC0 control path discussions, but that's an
interesting question anyway ;-)

> But I'll ask. And I'd love to see a webserver in scheme...
well, as i said before, this doesn't bother me at all, as long as i can
write the few necessary lines. i have done a bit of java (on a NT server) some years ago, too (it had to play with UDP and ports and special protocol= s).
so, as long as you can setup some scripting/programming capabilities
with file I/O, string manipulation and http I/O, it's ok for me.

> > > If Graham shows me how to do some simple stuffs at seul.org,=
> > > i could maybe do the job, but i need one or two examples. > I'll see if I can get an account for YG.
wow :-) thanks ! we'd need a quota of a few megs, ftp and telnet access, and i wouldn't be the only webmaster of the thing (Graham and maybe Steve could help).

> Graham



Steve Van der Hoeven wrote:
> On Sat, 19 Aug 2000 graham@belegost.mit.edu wrote:
> > I've never done a webring either, but I'm happy to help out if I = can.
> > Be great if Steve could advise me what I need to do, though.
> So are we taking the idea of yann, a central server maintaining  = a list of
> adresses.
it would be too complex otherwise...

>  dynamic pagespage:
>         - to adding urls (publ= ic)
>         - a page to moderate t= he urls asked to be added? (secured)
>         - a page to remove url= s from the database (secured)
>         - a page to dump the u= rls in the server (public)
>
>          note: if you sto= re the urls in a database, you can tools to
> directly  access the database and avoid the pages. But you have t= o pay for
> the database.

i thought about something more "rudimentary", a simple text file<= BR> with the necessary fields, and a little CGI/PHP3/whateverlangage to read it= .
The update would be manually done by a simple ftp transfert of the URL file=
to the server, so we spare all the dynamic update stuff... people wanting t= o
subscribe would simply mail the webmaster(s) (we can setup a mailing list)<= BR> and they'd edit the file by hand (not really difficult).

OTOH if you really want to make everything dynamic, with a real database and online moderation, you better have the sources ready ;-) i don't
think that it's that necessary : we're like a little family, we won't
have one million sites in the ring :-D

>  dynamic redirection:
>         -the stuff of previous= , following and so more...
> And same remark as to yann, what thecnology do you wan to use?
i guess the reply will be "whatever works and does the job" :-D

> > But I'll ask. And I'd love to see a webserver in scheme...
>   My web server is in fact an multiprotocol application serv= er... And has
> some specific features wich are experimental: reconfiguring of the
> software components making the system at runtime. :-)
>   And it's still in devellopement, but you can already use i= t to serve
> files over http. I'm writting actually the interface for dynamic
> information (images, html, or whatever you know to code), it will be > usable at the end of the week. And also I try to tune is up, by rewrit= ting
> a part of the c code.
>   The server will be distributed under gpl. And runs over mz= scheme, a
> portable scheme runtime from the plt group at rice university. Which h= as
> an obdc library. :-)
>   We will set-up a server for our onw use this week. :-)

that sounds exciting :-D but i'm not a big "web technologies" fan= .
i have removed the term "d*t*b*se" from my vocabulary and i stay<= BR> as far as i can from anything ressembling to "e-commerce" or any = thing
"hype with a e-". the telnet protocol, embedding plain HTML file = transferts,
is well enough for me ;-) and i edit html by hand too...

OTOH if you come with something dead simple and working, i won't refuse it = :-D

> --steve


ok, thanks for your help everybody : this eases the work :-)
I don't want to make a big and hype site, i just want to make a nice,
simple and funny little thing that makes you feel good in our
little utopic community :-)

maybe Paul Mota can also help ? :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01677 for ; Sun, 20 Aug 2000 06:40:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 06:40:09 +0200 (MEST) Received: (qmail 15767 invoked by uid 0); 20 Aug 2000 03:47:39 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 20 Aug 2000 03:47:39 -0000 X-eGroups-Return: sentto-1101623-647-966743252-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 20 Aug 2000 03:47:34 -0000 Received: (qmail 16618 invoked from network); 20 Aug 2000 03:47:31 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 20 Aug 2000 03:47:31 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 20 Aug 2000 03:47:30 -0000 Received: from f-cpu.org (nas2-229.ras.club-internet.fr [195.36.192.229]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA07019 for ; Sun, 20 Aug 2000 05:47:26 +0200 (MET DST) Message-ID: <399F54C3.D9EE642B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 Aug 2000 05:47:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a81c9768aaa5e270d00a19baacdbc1b0 Status: R X-Status: N Steve Van der Hoeven wrote:
> This page speaks about a single memory adress space and its runtime > protection.
>
> htt= p://www.cs.washington.edu/homes/levy/opal/opal.html
>
> interessting.
indeed ! :-)
why  make complex when things can be so simple ?

> --Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01680 for ; Sun, 20 Aug 2000 06:40:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 06:40:09 +0200 (MEST) Received: (qmail 13396 invoked by uid 0); 20 Aug 2000 03:56:15 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 20 Aug 2000 03:56:15 -0000 X-eGroups-Return: sentto-1101623-648-966743773-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 20 Aug 2000 03:56:15 -0000 Received: (qmail 18402 invoked from network); 20 Aug 2000 03:56:12 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 20 Aug 2000 03:56:12 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 20 Aug 2000 03:56:12 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id WAA02235 for ; Sat, 19 Aug 2000 22:56:12 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <399F49D3.2B8EB1D1@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 22:56:12 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 77248eec637a69e186efb4d89909f9cb Status: R X-Status: N

On Sun, 20 Aug 2000, Yann Guidon wrote:

> hello !!!
>
>
> thanks for the positive answers for this silly but
> probably funny project. the funniest thing is
> that now i'm sure it will work, but i still
> don't know how :-D
>

It will work.

> Steve Van der Hoeven wrote:
> > > so any help is welcome.
> > No problem, ask me and I will advise you. I know a lot about web
> > servers and dynamic information...
>
> fantastic ! :-) while Sven is absent, there's someone else
> to help us with the sites :-)
>

:-), no prob. I share my knowledge with pleasure.

> > > the last solution would be in my account in the
> > > university but i don't know how long it will stay opened.
> > > and i'd have to request the sysad's help because i presume that
> > > the CGIs are not allowed.
> > If you can open a socket server, usually the admins allow it above 1024,
> > then I have written a webserver in scheme with good performances. And it's
> > one you can run withour being root.
>
> hmmm now that i think about it,
> i don't know how the university's firewall will behave.
> i don't think that i could do this there easily.
>

In my university they bloc only the 1024 first (from out side) where
usually the most sensitive serivces are located

the other are not blocked as we have to play with them for our lessons.
:-)

But I don't have enought space to run it, and the main server crash often,
a lot of my class mates still have not understand that a cluster is not to
run a netscape, but only critical applications.

question for one million who much netscape instance do you need to kill a
sparc enterprise quadri processor with 2 Go of ram...

>
> > > "my_site" would be an identifier ("i'm not a number !") so there's no number
> > > to manage. a linear file of id:URL fields would do the trick :
> > > if action is "list" then display the file (with nice formatting)
> > > else
> > >   search the id in the file,
> > >   if action is "prev" rewind one line
> > >   else advance one line
> > >     display the line as :
> > >
> >
> > No problem, now you should look to what technologies we have acess: cgi,
> > php, jsp, servlet, asp.... Or schemelets!(okay, I know I try to put in
> > front my own work)
> >
> > Then you will be able to choose an implementation
>
> i've looked a bit at the PHP3 source pages of f-cpu.de,
> it's not straightforward but it's a procedural langage like others...
> another problem is : at f-cpu.de, i have ftp access but no shell access.
> this keeps me from using the local database with private files.
> If there is some simple file I/O capabilities from the PHP3 pages,
> the database file could be located in the same directory as the PHP3 page.
>

php has file io. but crappy, concurrency problems for writting. But you
can have a database access separately from a unix account. And you can
always run the database some where else (it slow downs, because php cannot
cache any thing in memory between two requests)

> there's probably a better way to implement this, that's why i ask for help
> and ask Graham if he could play a role in the story :-) The algorithm i described
> shows to what extent i do understand how the web works : not bad but
> rather "rudimentary" :-) i'm far from Graham's forms, comments, database,
> submissions, bugs, etc... :-D
>
>

Graham seems okay to set it up... It's my impression, he can only tel.
Else I have already submitted him a design.

>
>
> graham@belegost.mit.edu wrote:
> > > No problem, ask me and I will advise you. I know a lot about web
> > > servers and dynamic information...
> > I've never done a webring either, but I'm happy to help out if I can.
> > Be great if Steve could advise me what I need to do, though.
>
> :-)
>
> Anyway, when i look at your site, i believe that you have done
> most of the hard work already. we only need to adapt the little
> algorithm described before.
>

The ward work is to code it, because it's boring. Getting the ideais more
exciting.

> > The sysadmins on the machine open collector is on now are a little nervous
> > about system security (lots of problems with crackers using open ports).
> is THAT necessary ? (to play with ports ect)
> the port 80 should do the trick... at least i think that nothing complex is
> necessary. if the cgi is reduced to a shell script, i think that i can
> do most of it. but i don't think that we can play with the ports from
> a script. why would we need anyway ?
>

You can always use tcl, perl, or Scheme scripts...

> ok, that's far from the FC0 control path discussions, but that's an
> interesting question anyway ;-)
>

When you design a processor you often think about speed, cycles.

But often it's usefull to do something else because it can bring new ideas

By the way can you tell me where exactly I can find some of the schemas of
the processor, I have only the the code definition for the moment.

> > But I'll ask. And I'd love to see a webserver in scheme...
> well, as i said before, this doesn't bother me at all, as long as i can
> write the few necessary lines. i have done a bit of java (on a NT server)
> some years ago, too (it had to play with UDP and ports and special protocols).
> so, as long as you can setup some scripting/programming capabilities
> with file I/O, string manipulation and http I/O, it's ok for me.
>

You can do much more with the webserver in scheme, but I think we will not
use it for this application as I'm the only one on world how to use it for
the moment.

> > > > If Graham shows me how to do some simple stuffs at seul.org,
> > > > i could maybe do the job, but i need one or two examples.
> > I'll see if I can get an account for YG.
> wow :-) thanks ! we'd need a quota of a few megs, ftp and telnet access,
> and i wouldn't be the only webmaster of the thing (Graham and maybe Steve
> could help).
>

I help, no prob. But I would like to do some hardware design also. Okay
I'm a web gurus, because nobody new enought about it and things had to
work. But I preffer much more compilation, and os design.

> > Graham
>
>
>
> Steve Van der Hoeven wrote:
> > On Sat, 19 Aug 2000 graham@belegost.mit.edu wrote:
> > > I've never done a webring either, but I'm happy to help out if I can.
> > > Be great if Steve could advise me what I need to do, though.
> > So are we taking the idea of yann, a central server maintaining  a list of
> > adresses.
> it would be too complex otherwise...
>

this depends only on how complex behaviour you want. but you can always
easily do on master server for adding new urls with a lot of mirror
servers. If it's just a file, you make it accessible throught the web
server on the main server. and on the mirror you put a small script in the
cron running wget from time to time. :-) done 1 hour of work to set up all
the rights and coding

> >  dynamic pagespage:
> >         - to adding urls (public)
> >         - a page to moderate the urls asked to be added? (secured)
> >         - a page to remove urls from the database (secured)
> >         - a page to dump the urls in the server (public)
> >
> >          note: if you store the urls in a database, you can tools to
> > directly  access the database and avoid the pages. But you have to pay for
> > the database.
>
> i thought about something more "rudimentary", a simple text file
> with the necessary fields, and a little CGI/PHP3/whateverlangage to read it.
> The update would be manually done by a simple ftp transfert of the URL file
> to the server, so we spare all the dynamic update stuff... people wanting to
> subscribe would simply mail the webmaster(s) (we can setup a mailing list)
> and they'd edit the file by hand (not really difficult).
>

If you want to use your skin instead of your head you're welcome. I prefer
to not use my skin and time to time only my brains...

> OTOH if you really want to make everything dynamic, with a real database
> and online moderation, you better have the sources ready ;-) i don't
> think that it's that necessary : we're like a little family, we won't
> have one million sites in the ring :-D
>

And when the processor will be ready... And we will be the winners, do you
think that our familly will remain in the "familly"

> >  dynamic redirection:
> >         -the stuff of previous, following and so more...
> > And same remark as to yann, what thecnology do you wan to use?
> i guess the reply will be "whatever works and does the job" :-D
>

ok+

>
> > > But I'll ask. And I'd love to see a webserver in scheme...
> >   My web server is in fact an multiprotocol application server... And has
> > some specific features wich are experimental: reconfiguring of the
> > software components making the system at runtime. :-)
> >   And it's still in devellopement, but you can already use it to serve
> > files over http. I'm writting actually the interface for dynamic
> > information (images, html, or whatever you know to code), it will be
> > usable at the end of the week. And also I try to tune is up, by rewritting
> > a part of the c code.
> >   The server will be distributed under gpl. And runs over mzscheme, a
> > portable scheme runtime from the plt group at rice university. Which has
> > an obdc library. :-)
> >   We will set-up a server for our onw use this week. :-)
>
> that sounds exciting :-D but i'm not a big "web technologies" fan.
> i have removed the term "d*t*b*se" from my vocabulary and i stay
> as far as i can from anything ressembling to "e-commerce" or any thing
> "hype with a e-".

try object databases instead of relational. It's the same difference as
between a steam train and a starship. And you will see that IA can be of
some interest to database technology other than make you buy more CDs on
.com

> the telnet protocol, embedding plain HTML file transferts,
> is well enough for me ;-) and

If it'snot your job it's okay

>i edit html by hand too...

I do also...

>
> OTOH if you come with something dead simple and working, i won't refuse it :-D
>
> > --steve
>
>
> ok, thanks for your help everybody : this eases the work :-)
> I don't want to make a big and hype site, i just want to make a nice,
> simple and funny little thing that makes you feel good in our
> little utopic community :-)
>

:-)

--steve
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01683 for ; Sun, 20 Aug 2000 06:40:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 06:40:11 +0200 (MEST) Received: (qmail 13750 invoked by uid 0); 20 Aug 2000 04:03:57 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 20 Aug 2000 04:03:57 -0000 X-eGroups-Return: sentto-1101623-649-966744230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 20 Aug 2000 04:03:52 -0000 Received: (qmail 25052 invoked from network); 20 Aug 2000 04:03:50 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 20 Aug 2000 04:03:50 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 20 Aug 2000 04:03:50 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id XAA02260 for ; Sat, 19 Aug 2000 23:03:49 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <399F54C3.D9EE642B@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 23:03:49 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SMT Content-Type: text/plain; charset=X-UNKNOWN X-UIDL: c947f122707ad368d71351a098ff6694 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by WintelPC.Potential id GAA01683 Status: R X-Status: N On Sun, 20 Aug 2000, Yann Guidon wrote: > Steve Van der Hoeven wrote: > > This page speaks about a single memory adress space and its runtime > > protection. > > > > http://www.cs.washington.edu/homes/levy/opal/opal.html > > > > interessting. > indeed ! :-) > why make complex when things can be so simple ? This can also reduce the problem of page management in os. You can have problems of vector aligned on two different pages and you acces precisely the memory of the two pages close to the separation. here you just align the the the index register to the first element and you have a better page alignement, because you can adapt it to you software a compile time throught semantic analysis. This is close to the 68000 memory registers,but they can cut the memory in physical seperated banks(one for the code and one for the data, they thought hardware could make runtime security). So the story of the separated memory banks seems crappy, because you cannot generate code on the fly... This can be usefull for routers or thing like that. > > > --Steve > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus." > F. Couchet, APRIL.org, 8/18/2000 (contre les portails à la con) > > > > > --------------------------------------------------------------------- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA03532 for ; Sun, 20 Aug 2000 20:30:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 20:30:47 +0200 (MEST) Received: (qmail 20060 invoked by uid 0); 20 Aug 2000 06:29:18 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 20 Aug 2000 06:29:18 -0000 X-eGroups-Return: sentto-1101623-650-966752955-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 20 Aug 2000 06:29:15 -0000 Received: (qmail 21431 invoked from network); 20 Aug 2000 06:29:14 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 20 Aug 2000 06:29:14 -0000 Received: from unknown (HELO web1104.mail.yahoo.com) (128.11.23.124) by mta1 with SMTP; 20 Aug 2000 06:29:13 -0000 Received: (qmail 17979 invoked by uid 60001); 20 Aug 2000 06:29:13 -0000 Message-ID: <20000820062913.17978.qmail@web1104.mail.yahoo.com> Received: from [199.203.98.250] by web1104.mail.yahoo.com; Sat, 19 Aug 2000 23:29:13 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Aug 2000 23:29:13 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools, VGUI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 7d8d3795c5e4c401892493799fd8b6b0 Status: R X-Status: N There is a gpl tool called vgi you can find a link to it in the opencollector you can also get it on the OpenTech cdrom in fact I have not uesed it so forgive me if I am wrong Jamil Khatib --- Yann Guidon wrote: > hi ! > > graham@belegost.mit.edu wrote: > > Hi > > > > I haven't used more than a small proportion of > these, but have a > > little idea of the current state of some of them. > If I get any > > of these wrong I hope the authors will complain > and correct it! > > ;-) > > > Camille does not yet have ANY code available, > AFAIK - not even in cvs. > sad. > > > > NGPaint > > It's meant for small diagrams, not large ones. Its > not gpl. > when a diagram exceeds a certain complexity, then > the designer should either > split or hierarchize the diagram. As for the GLP > thing, that's sad too. > > > > > VHDL-GUI > > I've been told this is good. But it is binary only > (the one exception > > to the rule on open collector..) > the GPL thing, and the lack of sources, is very sad > too. > hey, i wonder why you call your site "opencollector" > ;-) > > i'll try to stress on the VGUI developper(s) to get > the source under GPL. > it's for the f-cpu and for me too, i believe that i > could more or less > adapt some of the SW for the GNL project. > > > > FreeHDL > > Yes, but still in early stages. Savant does > something similar to the goals > > of FreeHDL, and is much further along. > that's crazy. But who am i to criticize when the > f-cpu has still no > source available ? ;-P well at least we have an > excuse : we have no suitable tool ;-) > > > > PICA > > > VHDL compiler and > simulator from the University of Pittsburg. > i'll try to see if i can d/l it now. > > > > Savant > > If you want to do VHDL simulation (not synthesis) > with full coverage of > > the language, Savant is currently the only way to > go with free > > (lgpl) software. But you don't (yet) get all the > 'nice' gui environment > > you'd have with a commerical simulator. > i have the distro on the HDD. I better make some > room though, burn some CDs > and get one or two GB free. > > > > > Vaul > > I believe this is now merged in with FreeHDL. > "more or less". > > > > reviews and remarks about these as well as > others are needed on this list. > > > let's not reinvent the wheel, right ? ;-) > > The most relevant ones aren't mentioned: gEDA for > schematic entry, > mmm... maybe i missed the point on their homepage. > > > and Icarus. Icarus is a Verilog based system. In > general, free tools > > using Verilog are further along than ones using > VHDL. > well, in Europe there's almost no support of > Verilog. > > > Icarus can do > > synthesis (meaning net list generation, in this > case). > we don't "need" it now. we still have to use more or > less proprietary > things because the target processes are too > diversified. > > > Both gEDA (gschem > > in particular) and Icarus are already being used > for real designs, though > > they are also still being developed very fast. I'm > assuming you're > > running Unix though - if you want Windows, you may > have to do a lot > > of porting work yourself. > i'm using Windows 95 and SuSE 6.3, depending on the > tool's platform. > it takes two minutes to switch from one system to > the other, though ;-) > > > Conclusion: for VHDL use Savant, for Verilog use > Icarus. But don't > > expect much more than bare text output. There are > some nice waveform > > viewers around for Verilog Change Dump files, > though. > what would be cool : a dynamic/automatic "back > annotation" on the schematic entry. > but here i'm dreaming ;-) > > > > > Electric and Savant should follow. > > > I can't d/l PICA, i don't know why. > > > Camille, gEDA and FreeHDL are not ready. > > > > > > we need a VHDL behavioural simulator : > > > Electric and/or Savant would do the trick > > > if i can test them. > > I believe that Electric is more oriented to IC > design, > > where Savant is purely a simulation engine. For > high-level > > behavioural simulation (first pass at the design) > Savant > > might be better; for actual IC design, Electric. > > Last time I looked, Alliance supported a very > limited > > subset of VHDL so wasn't so suitable for > simulation. > i have the distros for savant and electric, i'll > check them > when i have some time. VGUI is fine at this moment > because > i can do diagrams for the dependency graphs of my > programs > (another biased use of schematic entry SW ;-D). it's > very light > too. > Alliance : now, i don't know. i have CDroms full of > docs etc > but haven't had time to read through. but to answer > your comment : > better have half a langage than half a design ;-) i > presume > that the limited support of VHDL is not severe > enough to > impact on a normal design, with some "langage > tricks". > > Savant is meant to be GPL'd and simulation, it could > be used > for the behavioural phase, but i gotta test it. > > > > > when the behaviour is OK, Electric and/or > Alliance > > > could be used for the CMOS/SiO2 process part. > > Magic is alive and well, too. > let's have some VHDL first ;-) > the synthesis can be done with any tool, free or > not, once the > behaviour is correct. > > > > Any time i spoken to someone interested by the > project, or when a > newbie comes, we're asked for VHDL. so let's make > some :-) > OTOH i hope that we'll be able to see, test and > enhance on the ground > of Nate's "soon to be released" design ;-) > > > Graham > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > the F-CPU: > http://www.mime.univ-paris8.fr/~whygee/f-cpu.html > SHARCPAGE: > http://www.mime.univ-paris8.fr/~whygee/sharcpage.html > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ --------------------------------------------------------------------- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA03574 for ; Sun, 20 Aug 2000 20:30:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 20 Aug 2000 20:30:56 +0200 (MEST) Received: (qmail 11740 invoked by uid 0); 20 Aug 2000 16:57:30 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 20 Aug 2000 16:57:30 -0000 X-eGroups-Return: sentto-1101623-651-966790647-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 20 Aug 2000 16:57:29 -0000 Received: (qmail 9049 invoked from network); 20 Aug 2000 16:57:26 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Aug 2000 16:57:26 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 20 Aug 2000 16:57:25 -0000 Received: from f-cpu.org (nas1-220.aub.club-internet.fr [195.36.150.220]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA00879 for ; Sun, 20 Aug 2000 18:57:23 +0200 (MET DST) Message-ID: <39A00DEC.8024B3F4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000820062913.17978.qmail@web1104.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 Aug 2000 18:57:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tools, VGUI Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7f12ffde6c4eb2a9ae03f7e8023b2cee Status: R X-Status: N hi !

Jamil Khatib wrote:
> There is a gpl tool called vgi you can find a link to
> it in the opencollector you can also get it on the
> OpenTech cdrom
>
> in fact I have not uesed it so forgive me if I am
> wrong

>from Graham's database :
"
VGI : VHDL Graphical Interface is a set of awk
scripts which allow you to enter structural VHDL
and state machines with the graphic program tgif.
"

awk and tgif are necessary so it reduces
the portability (less chances to have all
those unders a given OS). i don't even know
if it's installed on my own computer.
i guess that it's why i didn't try to see
if it's any good.

regards,
> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00330 for ; Mon, 21 Aug 2000 17:38:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 21 Aug 2000 17:38:02 +0200 (MEST) Received: (qmail 30803 invoked by uid 0); 21 Aug 2000 02:00:19 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 21 Aug 2000 02:00:19 -0000 X-eGroups-Return: sentto-1101623-652-966823216-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 21 Aug 2000 02:00:18 -0000 Received: (qmail 26930 invoked from network); 21 Aug 2000 02:00:15 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 21 Aug 2000 02:00:15 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 21 Aug 2000 02:00:14 -0000 Received: from f-cpu.org (nas1-236.aub.club-internet.fr [195.36.150.236]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA08744 for ; Mon, 21 Aug 2000 04:00:10 +0200 (MET DST) Message-ID: <39A08D0F.BCEE516E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 Aug 2000 03:59:43 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e2149496a0e80ae55bbf6ed67fc6452f Status: R X-Status: N hi !

Steve Van der Hoeven wrote:
> On Sun, 20 Aug 2000, Yann Guidon wrote:
> > Steve Van der Hoeven wrote:
> But I don't have enought space to run it, and the main server crash of= ten,
> a lot of my class mates still have not understand that a cluster is no= t to
> run a netscape, but only critical applications.
:-D

> question for one million who much netscape instance do you need to kil= l a
> sparc enterprise quadri processor with 2 Go of ram...

i'd say that it depends on the disks' speed. a good RAID array can help
sustain the workload. otherwise... in practice, it slows down around at 10<= BR> and gets boring around 30. crash ? 100 would do the trick. but the OS
can sometimes be a bitch at allowing space it doesn't have.

> > i've looked a bit at the PHP3 source pages of f-cpu.de,
> > it's not straightforward but it's a procedural langage like other= s...
> > another problem is : at f-cpu.de, i have ftp access but no shell = access.
> > this keeps me from using the local database with private files. > > If there is some simple file I/O capabilities from the PHP3 pages= ,
> > the database file could be located in the same directory as the P= HP3 page.
> php has file io. but crappy, concurrency problems for writting.
no need of writing in the case i described :-P

> But you can have a database access separately from a unix account.
ideally, there's no need of any ! just a php3 script and a file located
in the same directory, that's all...

> And you can always run the database some where else (it slow downs, > because php cannot cache any thing in memory between two requests)
well, that's not something important because i don't expect that much hits/= day.
OTOH we could make a counter to see if it has any success at all ;-)

> > there's probably a better way to implement this, that's why i ask= for help
> > and ask Graham if he could play a role in the story :-) The algor= ithm i described
> > shows to what extent i do understand how the web works : not bad = but
> > rather "rudimentary" :-) i'm far from Graham's forms, c= omments, database,
> > submissions, bugs, etc... :-D
>  Graham seems okay to set it up... It's my impression, he can onl= y tel.
>  Else I have already submitted him a design.
cool ! thanks :-)))

> > Anyway, when i look at your site, i believe that you have done > > most of the hard work already. we only need to adapt the little > > algorithm described before.
>
> The ward work is to code it, because it's boring. Getting the ideais m= ore
> exciting.

yup, like everything ;-)
but the goal is not to sustain 1K hits/second with millions of URLs.
and the simpler, the less bugs ;-)

> You can always use tcl, perl, or Scheme scripts...
i've never used any. i stick to compiled code ;-)

> > ok, that's far from the FC0 control path discussions, but that's = an
> > interesting question anyway ;-)
> When you design a processor you often think about speed, cycles.

the goal being : doing things the fastest way, while preserving/forecasting=
scalability. we naturally tend to see "speed" as the execution ti= me
for one instruction, but in the end the whole program matters.
so i've stopped blindly counting cycles :-)

> But often it's usefull to do something else because it can bring new i= deas
well, i see no relation between the f-cpu core and the webring, but
it's relaxing to think about it ;-)

> By the way can you tell me where exactly I can find some of the schema= s of
> the processor, I have only the the code definition for the moment.

the http://www.f-cpu.org website point= s to the latest version : (v0.2)
online : http://www.f-c= pu.de/man/i7/summary.html
ZIP : http://ww= w.mime.up8.edu/~whygee/fcpu_manual.zip
TGZ : http://ww= w.mime.up8.edu/~whygee/fcpu_manual.tgz
and i have also revamped the http://www.f-c= pu.de german site :-)

v0.2.1 should appear in a month or two. theoretically...


> > so, as long as you can setup some scripting/programming capabilit= ies
> > with file I/O, string manipulation and http I/O, it's ok for me.<= BR> > You can do much more with the webserver in scheme, but I think we will= not
> use it for this application as I'm the only one on world how to use it= for
> the moment.

i wish you success so your server can be used by anyone ;-)

> > > > > If Graham shows me how to do some simple stuffs at= seul.org,
> > > > > i could maybe do the job, but i need one or two ex= amples.
> > > I'll see if I can get an account for YG.
> > wow :-) thanks ! we'd need a quota of a few megs, ftp and telnet = access,
> > and i wouldn't be the only webmaster of the thing (Graham and may= be Steve
> > could help).
> I help, no prob. But I would like to do some hardware design also. Oka= y
> I'm a web gurus, because nobody new enought about it and things had to=
> work. But I preffer much more compilation, and os design.

:-)

i'm still trying to find a "good" suite for the schematic/vhdl/si= m part
of the design. if there were anything suitable, it'd take few time
to design something structural and basic.

> this depends only on how complex behaviour you want.

something dead simple. is this clear enough ? :-)
i don't want to fight with technologies i don't understand
and don't want to be assimilated with :-)

> but you can always easily do on master server for adding
> new urls with a lot of mirror servers.
what would be the use of mirrors for a webring server ?
if the server is down there is no risk, just a little
broken link. plus i don't think that it will draw a lot of
bandwidth :-)

> If it's just a file, you make it accessible throught the web
> server on the main server. and on the mirror you put a small script in= the
> cron running wget from time to time. :-) done 1 hour of work to set up= all
> the rights and coding

well ok but... is this necessary ? :-)
we need one server, one script (anything that works), one list
of URLs with ID and description, and the pages at these URLs that
point to the ring's server. Simple enough ?

> If you want to use your skin instead of your head you're welcome. I pr= efer
> to not use my skin and time to time only my brains...

no pun intended, but you're doing here much more than needed :-)
it's fine, ok, but the idea was "only" a simple and funny webring= ,
nothing comparable with "professional" or "super-h@cker"= ; :-)

of course, if the ring takes big proportions (>15 URLs, i'm generous :-D= )
we'll need your big weapons. with automatic mail notification upon submissi= on :-P

> > OTOH if you really want to make everything dynamic, with a real d= atabase
> > and online moderation, you better have the sources ready ;-) i do= n't
> > think that it's that necessary : we're like a little family, we w= on't
> > have one million sites in the ring :-D
> And when the processor will be ready... And we will be the winners, do= you
> think that our familly will remain in the "familly"

i don't get the meaning/tone of what you said.
first, there's no garantee that the project succeeds ;-P
the more we are and think about it, the more chances it has to
exist and that's all.
The current status of the project is more : hacking around, thinking,
drafting and speaking a lot : that's where a webring ties us together.
when/if it becomes a success, then of course, we'll have to upgrade the
original idea. but as you showed us, it's not a big problem : you
seem to be very competent :-)

> > >  dynamic redirection:
> > >         -the stuff o= f previous, following and so more...
> > > And same remark as to yann, what thecnology do you wan to us= e?
> > i guess the reply will be "whatever works and does the job&q= uot; :-D
> ok+

you see, it's not very restrictive ;-)


> > that sounds exciting :-D but i'm not a big "web technologies= " fan.
> > i have removed the term "d*t*b*se" from my vocabulary a= nd i stay
> > as far as i can from anything ressembling to "e-commerce&quo= t; or any thing
> > "hype with a e-".
>
> try object databases instead of relational.
object what ? :-P

> It's the same difference as
> between a steam train and a starship. And you will see that IA can be = of
> some interest to database technology other than make you buy more CDs = on com
there are a lot of more skilled people than me to deal with this.
even EMACS is complex for me (that's why i like Borland's DOS IDEs so much = : they are simple).

> > the telnet protocol, embedding plain HTML file transferts,
> > is well enough for me ;-) and
> If it'snot your job it's okay
as long as i can update the f-cpu sites, it's ok. i don't need more.
but we need skilled people for more complex stuffs, starting with this
case study of a webring (a simple one is plain enough, i repeat ;-D)

> >i edit html by hand too...
> I do also...
wow ;-)

> > OTOH if you come with something dead simple and working, i won't = refuse it :-D
the offer is still valid ;-)

> > > --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00336 for ; Mon, 21 Aug 2000 17:38:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 21 Aug 2000 17:38:04 +0200 (MEST) Received: (qmail 5093 invoked by uid 0); 21 Aug 2000 05:38:34 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 21 Aug 2000 05:38:34 -0000 X-eGroups-Return: sentto-1101623-653-966836312-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 21 Aug 2000 05:38:30 -0000 Received: (qmail 27514 invoked from network); 21 Aug 2000 05:38:32 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 21 Aug 2000 05:38:32 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 21 Aug 2000 05:38:31 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id AAA16593 for ; Mon, 21 Aug 2000 00:38:31 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39A08D0F.BCEE516E@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 Aug 2000 00:38:31 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7d510696d4ac41e899ac32a5566924bc Status: R X-Status: N

Okay, So I started to get a deep look into the manuals.

I would just make some remarks on the media:

The current html document is not very handy to read (to big document for
the screen), and to print (you lose all the links and it's ugly).

Latex prints really nice, but is a hell when you want to do sophisticated
thing outside the standart stylsheets.


I would like to sugest you xml. No XML is not a data-interface-library,
it's a way to represent information in a standart way, quite easilly
readable by humans. It has the following advantages:
- completly portable from one system to another, no probs of char
  encoding, no probs of of tools as all share the same data format.
- can be converted to nearly whatever you want(latex,pdf,html,powerpoint...). And
  you have the complete control of it with very simple tools. For Gui gurus
  you have the object-model-component power over a textfile.
- the data can be splitted across many different files with no problem.
  This would allow to store it in a cvs server, so the information can be
  more accurated. You can make some experimenting without compromizing the
  work already done. And it would allow a real collective group solves the
  problem of double editing...And the cvs server would also enable us to
  share much more easilly code drawings... So that every body stays at the
  final discussion

This is a sugestion.
And I would do the data reformatting, as long as it is in latex or html.

--steve
From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00354 for ; Mon, 21 Aug 2000 17:38:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 21 Aug 2000 17:38:07 +0200 (MEST) Received: (qmail 15095 invoked by uid 0); 21 Aug 2000 08:47:18 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 21 Aug 2000 08:47:18 -0000 X-eGroups-Return: sentto-1101623-654-966847632-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 21 Aug 2000 08:47:13 -0000 Received: (qmail 5659 invoked from network); 21 Aug 2000 08:47:12 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 21 Aug 2000 08:47:12 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta1 with SMTP; 21 Aug 2000 08:47:12 -0000 Received: from 0018728164 (host-209-214-154-38.bix.bellsouth.net [209.214.154.38]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id EAA02773; Mon, 21 Aug 2000 04:47:10 -0400 (EDT) Message-ID: <000801c00b4c$62a56380$269ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 Aug 2000 03:47:04 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Erin32 Data Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C00B22.78B204A0" X-UIDL: 00f7e20b44eeab8540eeb170ab395ef5 Status: R X-Status: N ------=_NextPart_000_0005_01C00B22.78B204A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Due to a lack of response; I will no longer post any information on this Si= te. However, anyone that is interested may contact me personally at: rhartney@bellsouth.net Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C00B22.78B204A0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Due to a lack of response; I will no longer post any information on this Site.
However, anyone that is interested may contact me personally at:
 
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_0005_01C00B22.78B204A0-- From aaa@aaa Mon Jan 01 00:00:00 1997 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00372 for ; Mon, 21 Aug 2000 17:38:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 21 Aug 2000 17:38:12 +0200 (MEST) Received: (qmail 7484 invoked by uid 0); 21 Aug 2000 13:15:00 -0000 Received: from fh.egroups.com (208.50.144.71) by mx11.rz2.gmx.net with SMTP; 21 Aug 2000 13:15:00 -0000 X-eGroups-Return: sentto-1101623-655-966863638-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 21 Aug 2000 13:14:34 -0000 Received: (qmail 26164 invoked from network); 21 Aug 2000 13:13:58 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 21 Aug 2000 13:13:58 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 21 Aug 2000 13:13:57 -0000 Received: from f-cpu.org (nas2-244.ras.club-internet.fr [195.36.192.244]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA03891 for ; Mon, 21 Aug 2000 15:13:42 +0200 (MET DST) Message-ID: <39A12AF3.2DE09BF7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 Aug 2000 15:13:23 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring ? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-UIDL: b0721ddee613f80e85a5b4d60e942868 Status: R X-Status: N hi ! Steve Van der Hoeven wrote: > Okay, So I started to get a deep look into the manuals. at last ;-) > I would just make some remarks on the media: yeah :-) > The current html document is not very handy to read (to big document for > the screen), and to print (you lose all the links and it's ugly). well, at least i did some versions by hand, not bad after all... but it's becoming VERY HEAVY to manage this way. it could take weeks or months to updata perfectly. > Latex prints really nice, but is a hell when you want to do sophisticated > thing outside the standart stylsheets. i'm not an expert. > I would like to sugest you xml. No XML is not a data-interface-library, > it's a way to represent information in a standart way, quite easilly > readable by humans. It has the following advantages: > - completly portable from one system to another, no probs of char > encoding, no probs of of tools as all share the same data format. > - can be converted to nearly whatever you want(latex,pdf,html,powerpoint...). And > you have the complete control of it with very simple tools. For Gui gurus > you have the object-model-component power over a textfile. > - the data can be splitted across many different files with no problem. > This would allow to store it in a cvs server, so the information can be > more accurated. You can make some experimenting without compromizing the > work already done. And it would allow a real collective group solves the > problem of double editing...And the cvs server would also enable us to > share much more easilly code drawings... So that every body stays at the > final discussion > > This is a sugestion. > And I would do the data reformatting, as long as it is in latex or html. this can be done in some weeks : the french guy who translated to LATEX will release it in a week and i'll update some things. then we can translate again. OTOH, i have no XML experience. some people proposed SGML or similar stuffs, claiming the same advantages, but HTML is rock solid so i stuck to it. IF you so a XML version, you will be responsible of the manual's update (since not so many people know it). there's already somebody else for the LATEX, and we'll have to collaborate closely. ok ? are you sure you want to get involved ? :-) ok, let's go ! > --steve WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus." F. Couchet, APRIL.org, 8/18/2000 (contre les portails à la con) From snorepillow271@hotmail.com Wed Aug 23 17:09:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00622 for ; Fri, 25 Aug 2000 18:37:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 25 Aug 2000 18:37:29 +0200 (MEST) Received: (qmail 13552 invoked by uid 0); 24 Aug 2000 05:25:51 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 24 Aug 2000 05:25:51 -0000 X-eGroups-Return: sentto-1101623-656-967094748-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 24 Aug 2000 05:25:49 -0000 Received: (qmail 26599 invoked from network); 24 Aug 2000 05:25:47 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Aug 2000 05:25:47 -0000 Received: from unknown (HELO ns.ajis.co.jp) (210.155.45.2) by mta3 with SMTP; 24 Aug 2000 05:25:47 -0000 Received: from [209.179.244.20] by ns.ajis.co.jp (Netscape Mail Server v2.02) with SMTP id AAU12840; Thu, 24 Aug 2000 00:12:50 +0900 Message-ID: <000068171437$00007d06$0000189e@> To: X-Priority: 3 X-MSMail-Priority: Normal From: snorepillow271@hotmail.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 Aug 2000 08:09:37 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Snore No More 6302 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d1774a19fca1d707123aae3cb5625705 Status: R X-Status: N

Do you keep your partner, yourself or even
the whole house awake at night because you snore?

Have you tried a lot of products but still have trouble
sleeping quietly or soundly?

If so, we have something that could finally improve
your sleep quality for good.

Our Snore-No-More Pillow comes with a full 60 day
money back guarantee.  Check it out at:
http://www.angelfire.com/nv/snorenomore2









If you feel that this has reached you in error please DOUBLE
CLICK ON: mailto:remonow15@china.com?subject=remove
We will insure that your email address is removed from our
database immediately.





















Do you keep your partner, yourself or even
the whole house awake at night because you snore?

Have you tried a lot of products but still have trouble
From "VERONICA TREJO" Sun Aug 27 22:54:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02439 for ; Mon, 28 Aug 2000 01:28:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 01:28:35 +0200 (MEST) Received: (qmail 14351 invoked by uid 0); 27 Aug 2000 20:47:07 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 27 Aug 2000 20:47:07 -0000 X-eGroups-Return: sentto-1101623-657-967409222-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 27 Aug 2000 20:47:00 -0000 Received: (qmail 29979 invoked from network); 27 Aug 2000 20:47:01 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Aug 2000 20:47:01 -0000 Received: from unknown (HELO hotmail.com) (216.33.148.18) by mta2 with SMTP; 27 Aug 2000 20:47:01 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Aug 2000 13:47:01 -0700 X-Originating-IP: [148.246.161.55] To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 27 Aug 2000 20:47:01.0915 (UTC) FILETIME=[F37DAEB0:01C01067] From: "VERONICA TREJO" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 27 Aug 2000 15:54:37 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] informacion sobre el RETO DE HARDWARE Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0103F.1A252580" X-UIDL: b13bc7560ea5c0bc1b919a531c92f2e7 Status: R X-Status: N ------=_NextPart_000_0005_01C0103F.1A252580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable disculpa lo que pasa esqeu necesito informacion sobre el reto de hardware s= i me puedes ayudar favor de mandarme un mail a la sig. direccion ver_trejo= @hotmail.com agradesco tu atencion=20 ------=_NextPart_000_0005_01C0103F.1A252580 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
disculpa lo que pasa esqeu necesito informacion sobre el reto de hardware si me puedes ayudar favor de mandarme un mail a la sig.  direccion ver_trejo@hotmail.com
agradesco tu atencion
 
 
 
------=_NextPart_000_0005_01C0103F.1A252580-- From Yann Guidon Mon Aug 28 01:05:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02463 for ; Mon, 28 Aug 2000 01:28:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 01:28:43 +0200 (MEST) Received: (qmail 25506 invoked by uid 0); 27 Aug 2000 23:05:46 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 27 Aug 2000 23:05:46 -0000 X-eGroups-Return: sentto-1101623-658-967417529-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 27 Aug 2000 23:05:41 -0000 Received: (qmail 14354 invoked from network); 27 Aug 2000 23:05:28 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Aug 2000 23:05:28 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 27 Aug 2000 23:05:28 -0000 Received: from f-cpu.org (nas4-69.ras.club-internet.fr [195.36.203.69]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA24847 for ; Mon, 28 Aug 2000 01:05:26 +0200 (MET DST) Message-ID: <39A99EB5.985D1379@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 01:05:25 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] utopia computing webring Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 16192fef5c169fcf3ebd18f2b630e7a8 Status: R X-Status: N hello,

i'm pleased to say that the utopia webring is
being setup by Graham :-) this shouldn't take long
before people can submit their URL.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From Steve Van der Hoeven Mon Aug 28 01:08:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02466 for ; Mon, 28 Aug 2000 01:28:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 01:28:43 +0200 (MEST) Received: (qmail 28646 invoked by uid 0); 27 Aug 2000 23:09:15 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 27 Aug 2000 23:09:15 -0000 X-eGroups-Return: sentto-1101623-659-967417730-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ml.egroups.com with NNFMP; 27 Aug 2000 23:09:09 -0000 Received: (qmail 30350 invoked from network); 27 Aug 2000 23:08:50 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Aug 2000 23:08:50 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 27 Aug 2000 23:08:50 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id SAA25179 for ; Sun, 27 Aug 2000 18:08:49 -0500 (CDT) To: fm In-Reply-To: <39A99EB5.985D1379@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 27 Aug 2000 18:08:49 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] utopia computing webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d34ce708b52a16b0f02f05351be960bb Status: R X-Status: N
:-) utopia web ring...

--steve
From Yann Guidon Mon Aug 28 01:15:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02469 for ; Mon, 28 Aug 2000 01:28:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 01:28:44 +0200 (MEST) Received: (qmail 32518 invoked by uid 0); 27 Aug 2000 23:15:16 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 27 Aug 2000 23:15:16 -0000 X-eGroups-Return: sentto-1101623-660-967418110-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by b05.egroups.com with NNFMP; 27 Aug 2000 23:15:14 -0000 Received: (qmail 4729 invoked from network); 27 Aug 2000 23:15:09 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Aug 2000 23:15:09 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 27 Aug 2000 23:15:09 -0000 Received: from f-cpu.org (nas4-69.ras.club-internet.fr [195.36.203.69]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA23304 for ; Mon, 28 Aug 2000 01:15:06 +0200 (MET DST) Message-ID: <39A9A0FA.46551C60@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 01:15:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] utopia computing webring Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2779235b95b700338b842708f986bd22 Status: R X-Status: N hi !

Steve Van der Hoeven wrote:
> :-) utopia web ring...

yep, i think it's a cool name, no ? :-)

"
The Utopia WebRing links together useful/resourceful pages
dealing with (but not only) : Computer Architecture (theory
and practice), Open Hardware initiatives, The F-CPU and similar
projects. We work towards a better platform, because a free
computer is not only free software.
"

who has objections/enhancements ?

also, we need a little logo.
i have one or two ideas, but we can make a little contest,
or propose several artworks as well. run your GIMP !

> --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
=
From Mon Aug 28 03:02:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00335 for ; Mon, 28 Aug 2000 14:09:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:06 +0200 (MEST) Received: (qmail 21701 invoked by uid 0); 27 Aug 2000 23:59:53 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 27 Aug 2000 23:59:53 -0000 X-eGroups-Return: sentto-1101623-661-967420764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 27 Aug 2000 23:59:24 -0000 Received: (qmail 30244 invoked from network); 27 Aug 2000 23:59:23 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Aug 2000 23:59:23 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta1 with SMTP; 27 Aug 2000 23:59:22 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.10.2/8.10.2) with ESMTP id e7RNxEr28147 for ; Mon, 28 Aug 2000 01:59:15 +0200 (MET DST) Message-Id: <200008272359.e7RNxEr28147@essi.essi.fr> User-Agent: IMHO/0.98 (Webmail for Roxen) To: f-cpu@egroups.com From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 02:02:44 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] utopia Content-Type: multipart/mixed; boundary="'ThIs-RaNdOm-StRiNg-/=_.958911314:" X-UIDL: a6ecbf31303b3edcd4088b5a62f2e76f Status: R X-Status: N --'ThIs-RaNdOm-StRiNg-/=_.958911314: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit "
The Utopia WebRing links together useful/resourceful pages
dealing with (but not only) : Computer Architecture (theory
and practice), Open Hardware initiatives, The F-CPU and similar
projects. We work towards a better platform, because a free
computer is not only free software.
"

Not for in bots, but it's a god description...

Else for the logo... We can recylce one. Well I did it already. I
colorized one of the bear drawings. If it interstes you, we should ask
permission to the original autor.

--steve
--'ThIs-RaNdOm-StRiNg-/=_.958911314: Content-Length: 73028 MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg;name=logo.jpg Content-Disposition: attachment;filename=logo.jpg /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAF8AXADASIA AhEBAxEB/8QAHwABAAAGAwEBAAAAAAAAAAAAAAECAwcICQQGCgUL/8QARhAAAAYCAQMCAwUGBQIF AwMFAQIDBAUGAAcRCBIhEzEUQVEJFSJhcRYygZGx8CMkocHhF9ElMzRC8QoYUkNigkRTcnOS/8QA HQEBAAICAwEBAAAAAAAAAAAAAAYHBAUBAwgCCf/EADoRAAIBAwMDAwIDBQcFAQEAAAECAwAEEQUS IQYTMSJBUQcUMmFxFSNCgZEIJFKhscHwFjNi0eElcv/aAAwDAQACEQMRAD8A/P8A8YxilMYxilMY xilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYx ilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMrtWzh44RatUDu XC6hE0UEymMdVQxgApClLwIiYRAPAgPn3DK5nh1Gbdgmg1RKmZUVFUkCldO1FlCm7nTs5jrqEKUj dJJmQybBD4YjhFqV64fOnW1v7Pfpcj7ooGy7ZGneIoyTdnVGap1kUnkiiYi7mQUTTTILlizEW7VA oOTt3L77zaPmQlZoKK67VdTg0ixmvbjJSMAKi43SSMQqIueMknk/wqGbBANbXRdIudc1CDTrXaJJ SxaR8hIokUtJI+AThVBwAPUxVRywrBOr9Mm67Yz+8Y+hWFKOEgKkfOot23aqomKU5HLdwukk2eNz lEeFGKzoxTF7TplAe4J5Ppi3PHeodSmybopDnKc0ewkHZSnKIdxBFsxOmUQ5DwU3aHIAA/LPZrTu lUi7Vu6nHaaArJNjiikmU6olTR9NEVlhD1VlSE4KCiwiPACAG5ABy+de6KYu2rejCxchKGJwCyxC pptkee3ys5WAqCfPgQAygG4/dD5ZVt39T5bNJLq5t7C0s4hueS6uDDGijAJkuJGSNQSTjIX2xn3t E/TTSo4iJNYujKB6pVgjEQPGcIWzjn3kPI8/H5/c5UbNWjiSdgpaIMBwTAZFg6aFMc3dwUouEUgE RApvwh3CPHsACHPXylADFExTHJyXvKQxSnMXkAMUphKoBTD5Apuw4APBhIPAlz9Du0/ZbwspGqqS lbhpUBIYTt0nbF48AO0wiHpemHIgHdyBTj559xAM1ybL+x50NYzvvhIkK9LAqcDi1bmZnBwAiAfE ooGQBcocmAUnAK/hABQFJcAOGRoX1g6c1sP9tJBdGIgTNp15BeCPJwC6KVdAecE5BIIBJBxprn6c SnLadq9tcgfwTxvC2P8A+4zMpPxkKD5zivG3jN5nUB9ktK0QX37LuHQESSFdJVTldu5TIUglFNQC CJTdxhARBEiiXIkXIVJRus800X2hWDXk+7r9gYuGbpsocn+MmJAOBTGKAkN7HD8I8HDtA4gbtAO0 QCw9L13TdYUmynDOoBaFxslUfOw+RzyVJA96h2sdO6roZU31vtik4juI2EkDnGdoceG/8WCn8q6V jGM3FaOmMYxSmZ2/Zo9FyP2hvWvpPo5NerPrV5uuSsUTHXWq64h9qOq6tXahPXR/Ly9RmtoaiQWr ETB1uWlbJIsrarMRsQxdOoeu2WRK3h3WCWerb/6WOIi9KXr7R37S+1xsVI1noE6HL5OwqUyVwRsp svYDaWnK0g2XbIqOgXlavqe81FYjAwPzJ25JBEhzOiFMpWmTqD6AVa71s7e6MujG9XLrTkdKL3hn cNiNNVQ2oYMg6qZOne1bJ6Cu2tkw8JriiqR8i1k77cLZWY/1GJzuGbEjhiLrtzH7PSls/sipn7TK 6b3TrtxmurVLpj05oFvVUpE1+TiqtFWq4Wh/avvxB5DHiY51NuSNk668jW6deZt3sr8db4pux29d Cm5OoDob+wV67et6DfxTfcHW91OVTpe0LaXusqFarwvCQUZZdp9Ud7n5aYqknI3um3GoRV3q7tnd 3VmhKrL0KalmcNBpvXr+X0BdO+3LlObB6cqptCo3jqR6aem/arvqGvHTjEA6Xi5zWcJNwOxOpRd2 Vghyy/azXNGesbXdJlRUYeBYpKOZBrFxxE01Kw5xnqA/+oT1fROmiXiI/p8dam2Z0hfaLzNB69+l 7YEZT6tE37RFNbwewoK39NWvHkbFN5SvdOs8tsXW90rtGamhK1XnNGrkHH1prNQNokZTGro5qOtq N9kj1Q7OPqB3QuqfcfUjqTUOn+sjdlKi2+n6voFwisG2Uem7Z1or71hVtz1WUjp6N3DM1eTj7wej XKnRGv34z7Wdi3SlaFMZ7HK1ov7Mn7VH7Vmmal6emNRZdAHQn0XI9SfVls+haVrekrV1cWPR7apM tvzjeQUruvNkx9f2DL2qi16xntBoqUSkWe07dVlo/wDaOCtqFo9T6F151kfZy9Rm2Nl630jpq+fa T/aW9J3Sj9kfqyv02Jq59DrQm6WcTuOW09EREfW2yupnGvdoONcbKsakwoxvWyKAE5tV8bZa9Tsc mpWhr7OjpFh+vHrJ0l0jSuxbHqpfeFkUqUJeK3reK2opBzHwLmTK9mqrK7N1OQa4zjo+SfzUkxsz qVYtmnMfATK6oIFtP1Y6w1zpPqb33pvUd/d7W1tqjbN51xUNmPGTKOPf4qk2B9WwuDdlHOXrJvG2 FxGrykSRu8dEGLcszi4WMYxze4rpy1VXfs7dx/awbj1FqiGgunj7IfonlOmLpsvr7VdbY7N3d1/b YgoWt2DqLX2DJ1kbVNbRldgJ3TVIyca+m4bX2rdphrbXTNGnTcjATvhY6cqBsbavUDpHWuoIhpPb Uve2dfVTXUPIwMNaIx/dJy1xUfXEJeuWRhKVubhvvVdqeYjLHGvq88jCukZxovFHdpmUrYi0+ze1 hpDpn6ceovr63jeengnWlFbEs/TNR6DqVHatiHV1JpaktE7u2e3Ut9ZVharf7vL0Wpa7qMWivNWu CsslsB5O1ivQCZZnURnu/wCqWja9+1k+3mtHR/uOxpsugv7HfpmkbHsKDrUPWa1M7AqPTVFa8bbm r6UlE/c0hXGlo2hcmdAeR7OyGb1uh1iQfVQ1Rn5V3Ix+tmu60o/UN9ll1ddSt81Bo7XeyuvD7Qbp t0B9kFo2EpMRXS6ikdf7UBTbRdRQcTWUWrrUc3Q9hq6s2bPqpzzC+7Go331tVvJ7LcVOXmVK8s2M 9df27HVl089JNj239lfqHo06NZu31bpt6dNP7a6ja1pSkUmZpG0mUbSNw3uX05HUav12MiJm2TEo vIXabdgrMGsEm3iXoompqsW51q/YE69qu7OsbZ2iLxR9XXasbS6Ner5ib/qTrCkbBcVaxw2g71I1 O302Ws8HJT9IsEFMCk7CYpUrASjtAotXLtVMjf0FK0fYz069A3S7qr7TTcX2Zn2ee4qpqPVTXpK1 H1Eb56utm6sqZKPs+5acn7pXNi1rTe5rSRJmE7s6tQSCKrm5w7p8ehV7cytamIxhtCh7ARN2SGq2 muoj7N37VLrJt+idVa2pnUJ1D9PfS59kn041elRlXslb2rWr2zdWQ2oGMPHskU5VDVVnhEtpW6In 5c+15+L2A32RIS07HQRJlSvLNjP0cIv7OPWLb7Szph13t/Q2itedLv2L/wBnrB7Z6kL7T9F0+p0/ rP6pWGrdcWPdMusb9nKdTb5X4FhP68v9kcTsM3lICYfrktZk0NixiEL+elty1zd62rsq6WWETrNg td8tthmayiw+6kKzJS88/fO642ivhmQRTSBWXPEtYsrNmnHN2aTJNo2IgVBNSreYxjFKYxjFKYxj FKYxjFKYxjFKYxjFKYxjFKYxnKZsXkgsRuxauHa6hgKmi3SOsocxh4ApSJlMYwiPgAABER+WCQOS cD5NcgEnABJPgDkn+Vdgo1bkLjcazVYtqu8f2Cci4pBBskZZYfi3qCaipSlD8BG6IqLrrHEqSDdN VVU5EiHOHrU6VtVEqCdFoUeiQ6ldSZEljolDtF2RBBZQTj2/veidv3c8DyPkOBzUd9nN0F7Ts21K vt691+TqlEqIPJtq5k3clXgfPSMjt2ijldqqzdHjETuwVdxqixGMwQoR0ujIQjiSi329TU9x/Yjc UnGy8RLKN5A6DhnKxkLLzzMwLuiRT9JZeFh1ESqwj5ACSzsRcMopFZus8WYoFVbMqo6+1OK6e00+ 1lWYQmSW57RDqJHKJDHlSQzj94SoyRuXjPi4vptprWaahqV3H2JJokitBN+7cwqHknmCtgiM4QBy Ap2sAfGdosMxBw4YMexwqBzJJmTaIHcOlCkIUDFaIJgY6q5iAJUkiFMdRQQIUBEeB+Q2d7C6nZdt WNb22z601CAsH1GPruzkhpi519AVwDYM7ZolmDwIPYbBwDmrwbd6Z0lUzQdtlFa3cpw1I1tPCXRx AzlcnWFasE63aSse8V+704hn2N0Vk1lFTlsc3X1hAUymT4TBRXuHn0xABHORrO3zvSc7jApnT7ZL 9oZxCqo1mKpM5rNptTVEZGSux1P2Ue1qe3C6rk3VomCZang9VRlPsYuS1yUtaM02pr2lVam3DzT9 QbfVpRbfsyCK5vEgDaRFcT2aW7Xgedrttt3NHAt/HDFafZd8Zljlu4bZu/LHHNvdfaSSe2jYXTWO HN12ILll3sY+0WeKMiSIqzhtjMI2AZxgOVvIy6JbhUTP5qn7b22hYXbQW/xEzuPZt5ZNjD59RjXN j2i51Bq5AQAAXLXxN54544HOu3Wv32utoD/qcwYBZ3ySzQbHX035oG0FjG7P4x84ReJKGqs18Wso clVeS86J4g6K8NZrGeMsZYHJNv1c1eUaNXsdW7Wkm8KQ6bWWhnkPINgMPIpv2ciRmsyVT4EihFCg HsZIzshimNjztvcznabqLat4SXhWUQuocyT5NEoHWB4gAuBWZuXjRUjlAoeiDRVyYU1BBwViqV2R ODdB2H1D/wCpbK71/TpI7VFuFvL29CR3yRfbyJHbdzuGeSMz9vNtKkkKYZ1WKXZMnfp9isE0MtsH iieMsVXPYkjKqQSuNodtyshBWQ4z6kRlqzs9WoqxsVGUk2RcpHKPaKpCnAhxAQBQOQ4EQ5EQ5AQ8 j9c0nfaLdBNZv9BXudMatWc7GqrFAyZin71RMdJZgC5eDAVN/wD5P0V/TUBwgCPoAsQhTbsZiww1 eZoO5mSZRyLqQjoZkZ66QaA+mph+lFxEO0O8WTI6k5aUcoMIlgQwrO3i6LduQ6ihCZj/AL6tNXqO uJgs06Yt11WJ3DwTrkK2TN6rmQfvhWcA2/y4OXbh0d2YpeRETmDkDFz0hZXVzYXMN3as6TJIDGRn a5BXcrYHqGCoI8YbBxkVubi2t9RhlsLpUltpY2E6MeY84KyD/AVG5gxIIxkZAYjwMWetStSm30FM tztnzBdRFQhgEORIYS8+QAQHx5AQAQ8CHJRKY3X8yA6mrBH2Lb9sexwB6ISr4DCAAAgdRwZUyQiH IG9AxhR7u4QHs5AA+eP+ejbOWSe0tppU2SSwRSOn+FnQMR/U+PbxXmq+hjtr27t4n7kUNxNFHJwd 6I7KrZHByADkefNMYxmTWJTMxtWdfnVfpbQF96WdbbKioDp+2mud3s3WLjVmn7FBbDeCug5avrsv Z6DMy1pfQ7hoyWrj2bkXrqsKx8aeurRho5iLfEIGTwwEMVo5EqgFFMwIKiBwMHcUSCBODAYv4i9v PIeQ8Zzl6/PNWij9xCyqLBL0/VfKR7orNIVTJkTKo6FL0EzmOqmn2HUAwKnBIQBQe3FKyTadcHVr H9NLXo8jN97AiemhpK2GYJqSHkkYivLuba4F5Z2kg5jWzWblIOee9r6VrUlKu669fJovF4s7lBFU ltNJb82505W97fNLXN3RbbI1iepT+YZR0JJqPajam6bG01ty2noyVYrQ1oiirQNkYKNTN56tv5et SxHkDNS0c9tBjFKvHuHqB3Jv1eiK7cvkrcW+rtf1/VWtYddCNia1r7XNXIsEJTqVVYBjFVusQTZZ y8frs4WKZFkZd/IzUkLyWkHr1fe906fb+7G6GdLdFnTr0ZrWCu6Bp9KfD11aV3PrTX+2q3ufbVx2 NLPdo2bXlmtFtmbFG0K26wNBQsRreAS0pXoCxEs72YaXGUs7+3m832MUrZp1a9dlRk/tDt+dXX2c tDkuivVexFHUHRdVwEZUYppGUiw6xhtfbKgrHR4NCU1z+z+136FotFk1ym1nabGjalYJuaTbRbV8 piHN9T/UFYLJp+2SG2rknM9Pf3J/0F+6ZL9n4nSv7OT6dsh/+lFcgE4yu69+GtiQWtT9k4qJ+NtC jixPviZl05eq2HxilbDbl9rF9o3sJnvthderzblka9T0VRoLeScnJxqx7xDa2aqs6VFiuWLIvW2M Igu57W1QVgEn6zt46lCvnTx0sr277NHqg6Y+hLqb6eusu+RG2N13/STvb1wNoVtQqTV9fO9gNaFL wvT45a7pebVn7AtGjdZpG1Xl+ppGOkKD+y8X+zDLY7iVW+59YmMUrJSK6v8AqNr3ULsbqmrW0J2v bw21ObVntjXCOKzUJcVd3LTi21Iqywkk2fwVhrl1CyTCM7XJ2OkoZ+g77HLNUySJiSI9XvUk3v8A ozZiO2bAW19MbuvvenfltCnq+lHNXsCdtgzazoJ4s1Cp6bO3JhbjoQlaaN3trMrZX6TqcXWfqY3Y xSrh7a2xsXe2zb3uXblrkrzs7ZlnlrlerhLg2LJWKyzjpR7KSjtNk3aMkVHLhQxit2TVszbp9iDV uggmmkXPTpk6pNI9CUpTepLpfvm+LB1dt9K7T19LQGyNN0Grad19d9x0Gy6ynLjSbzXOoG4T2wmN Nq1slHVXhL9puHYTFpQjJ2VZRxGLdglrIxilXm1d1D7u0rt5rvvV2yrPT9vtZKblTXqPeEXlpB1Z 03qFnSnEpFF5H2GNszaRkGlkhp5lIxE+yfO2UuxeNXKyJ/pTPU9v2ddaZXf7QshGnTo+UlNCV2LM ygqVpqTc2pG9SUjrShQbOOpVMfT11QSt1ndwMAxcWmzF+/LGpKSZjOTWHxilbF3/ANrf9pJKbd2X viT6vtsyG29v6fV0DsC5vXkM6ey+mlXasiOvWDFeHPD1ivpSbl9KtUapHQi7OVlJiUaOEZCYlHLv Xe6dOXzlw9euF3bx2us6du3Syjhy6cuFDKruHC6pjqrrrqnOqssqcyiihjHOYxjCI0MYpTGMYpTG MYpTGMYpTGMYpTGMYpTGMYpTOyVitWKzyiEXWohzLyTr1WybZBmV2H+YSOgYTAqmokkcCKGMkuYC HbKgm4QVTXTTUJ2PV2tLZuS+QNDpsWu+lpt20bHFo3AyEXHis3aOZZ8Pckmm1aFWTE51ViKvXaqD JEziRfN0V/QT049Gso2vaWqtSoNa4erOGSe+tyz8C6cPac6fQMfY4rX2vGE3HFhLDtWw1+Xa2BUj gZyH1xBGI/u0IeadQ1YlNDrWuw6ShQBZbkxPNsZtsUMKEL3rhgCyRs5EcaorSTSlYokZ2AMi0Lp+ XV27ju0FosyQb1UPPcTvz9vaRsyJJIq4kld3SG3iPdnkSMFhrU1h9n5aphZiS4OXa8y+bKPGdFqr ZOSsLlMjV46QK7XXdMYaBI7VjXUezk7LJxcEvJinFnfpO10QU3A9M/2aitTdM5WRpcfXzN5Zi+aO H09IS007iyEQc+lNEim9fZRb/wCLM4bLxkZLT0WZFgib73mEJJ61bbcdQ9NurtLQzCBolVj4iNYA Y6RhEVHjh6qcDvJJ6sf1V5CSkuTLvZWRfLSjtwdRw7UWVOoobIBuVUiYFUFETdxwAUUvSJ6YKD6Q dvqrefSEP/d5HzwT2yodU6p1XUmdPuZIoCx2rHm3OAwK5SKVgOBgq8kxDEkSNhStyaT0to2lrG62 cU1wEIlafZdoWYAHDTwqx28gPHHbK3vAMkHr1VqsTUopCKhYyFh2qQqqfDxMM1jkAVcnFV0cEWZU 0wOsqY6ihwL3KnMJ1BMYwmzhz9dcCRebrsdAO7YySUXjk5c7mLjpJwYvJ42Rlo9tLSEWykkwSQUf oxM0aPdEazH3HNCwLEuO7ZMJhH5/wD2yO7mLb3O9t25i+W3nOTvJO5txzk5yc+c81IAiqhjQdpdp RRGAmwe2wKAF28FcDAIBA4qikCRh57QSUOH4kx49QPmAKcByHAq8+ef/ADQ8cjyPKAvHjuNx9OfH 8spgYQHzyIf37ZWz4IBGCBjjj9PFfVQEB8gBhKBv3gD2H+/n9ck7OAERHnwPj8/+P7+mVMe+AAPA A/3/AF+aV0eZqcDJz0JbnNTq8xbam2mm1RsMyyaGnK2SfRbNZ5KvzakS/lIBGeQaNG84ESdIJVFo xTdlcEQSKXC3dvRA32m9cTEZdZOoO1X0pJqVqupla6/kXz2wz1iQkZWqSpZ5meeWfzzqRss9EHh3 FospG9ueMmktHQAQmwQxe39PlkAAB9x4/wB/7/XO+O4ni27JCAuAAQrrtBdgu1wwChpHcAADexf8 YBHRJbQykl4wS3JwSh3EKpYshVizIiRsWY5jUR42FgfIDt77JPbNGnpyTcyLW8s3bo65EYxwtXpQ CrukzC6SkHEfMx6yhRE4vE1YtL0Y0XThg1kJBNixX1kKdPe1glFq8hVXq9oaIA5kaqIotrLHtvUF AXa0I7WRkVGQrgKSTxu3Wbrj5SOYM/QodxzF8USO2qDgo+4KplOA/l+IB8ZZjZHTxqnaUSSPsdTi hdtXDV/Ey7doihLRMnHO0ZCNfs3yAEcpOo+Qbt3KKyS4HSWSKomoRQCnCaaf17qdsdt5FFeRnYoI xDJGqgL6Qi7G45wQpJAJfmoVqX0/0q6AaxmmsZfWXD/3iKVmwQSWIlj9Wdx3SqFPpiBJr8/Gw1ax VSQXirJDSUJINhAFWkoycsHBREQDwi8SRVOHPIclIIDwJgESh3ZmN0vdJErv127lplqtW6csudZr IR7soC2BF4gczRFg6PISss3eFE8YxZLuI8xSJPp53bGS8E2gbvtg+0Q+z62dIpw9ihfuWwwbRzGR q9iFiolaIxFVZhFfEysk0TWVsMUiib70eFlWr64qL/ea7WZsjhxHV5r3LoopkFp+nQZ1V2Twqdga tFWlhssHC1y0tXFqUq7CRrlheyytVj5KRRRCar0etKR42n10YqUbt3sq0kIiT6h1gs2kQzaTJEuo XcyW6wuVd7Z3zy4k7aI3HoeVTBnJJeMM1RjS+izBrM8WtxTSaZZWr3skkRZBdQxmMHtmLuO6qZB3 UhkW4C8JtmKoexw/RXqGQOgjE6fQlniLhJY8pMA4fOma5UG4gZiAkTSYuVFEiuxI0I1I2UXM7KBS kbNsuyz6OImOZAk31WxAUeVUpNVJR1OkMUjgSJmlXAqybkjczt6tGkcOHRIz4pYkYVikRmUm7Gr0 oXZ0IuvQ4LrJpd3akiUwlTIUvcu5VEpSEEOPxHOYAEefceALj6becDER8LO3M1Wjqpe3MO81lc6b aHN7qNmq9yAp9bPZ2fSrVfjarZLwiQ52sMRWfrLd0+q8Alf31nuVXgZCpJeobh5/tptZf7kdtvtn vysv7zf2SIjIGO8RSmMbPUEfbwrGrQlj6a09o4n0zSrfuhgndto2yoZN2+RoyEBZk5kdQzYIJIIH nw3J9njrCSZi2jKaNHmSIEjId/GFdR7JqkiksZu2dtUjgSUdmVOqdaam28tNO3YpIOJRdj8JGQ+n jdfTjdtJTBiyzA0jCEOkok9MPKSxORMZJczRVMwpHAoFMogqip/iCVISiQFh957mBpmyoQ51GiDt s6TMX1SEKk5SHgwComYpe4i4G8gP6CA8CPOt3rH6FmWxNZSzGLUM6XbMjLoqgQE3Au0ku8VUyJ88 AqYoCKYc8cjxyACIzDQustRs7iKLUJ2urJmVJGmO+WJW2gSJJ+Jgvkhi2Rkjk5rQ690Xo+qWss+l W6WGoBGkhWAhbW4P4hGU4RN/hWQKF+MYFeMbGdxv9MlKBbJiqTCJ0X0U7VROU5TFE6YHMCagAbz2 nKXkBHkR88iOdOy543SVEkjYMkiq6MOQysAykfkQQaouWN4ZJIpVKSRO0ciMMMroSrKR8ggg0xjG fdfFMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilMYxilTFKY5gKQpjmH2KUBMYeA5H gAARHwAj4+WZZ9NHR3tnqXsbSMqcE+LEC7ZIv5cqaZUWTZ0sqReQeOFzEaxkaxQbPHK72QOmLkWp o6DaTU2u2i3FkNTVqRtuwqvBxjdZ04dSrMDpt2hny4N/iEirqJtCJrCoCRDidQ50jt2yIHdPABoi uIb/AJs3vqkTGdNemIUkDaLpWkZvYCb+PaTMBSqJKorRb+3bQM1jzwVxssqWOc1uC1ijKKVKUVTe s5p/I67YCirF+otcl0zs21ssQnuEZzPKw7dpChHcuJUBDMijOAvqd9sSjuSRhpd0x0/Fqwnu7ppf trV1jWCNSHvbmTaIbSGTBVJJGYEl8LHGHmbMUUxS7ug9Na71FZ5Tpn6Npau3HqfIkq33TvJ+1SnN fdM1aIo0bzUs4ZKu0Edn7Qbu1lIihURm4lTR1scTBLvKUipxk3Cn3PaV0vVtFUNhR6w9sU0k3XdP 5SwWubdTthnp6SFN5P2F+ssJGzSQs0wDixziMK0j2claZOXtLporYp+clXuNX2f2hGmjNSO/Qigj 3F/mVbm7eupCSlp6caO26beBm7LJTDVo/NZJqCQYT9ojRQJHxdumbGjFiqyMi5Wz6Ao9v588/wDG VDq+om5nlhiluJIg6m4nudn3N3cxqQ0suzKxxRs7pbWyMY4Uy/qmklke3tG00WsEM8qW6S9t1tob Rna1s7WYo6xQs2O9JKqRvcXbqJZmAT0QxxRrTxjJyB55/X+Py/3zS1vKiBPA8+R48B9B/n/xlPOR kBKA+4ecUqgAc+AzkZACgHsGRxSmMYxSqBh5Ef1/0yGTmKPPIeef9MlAoj8hxSoYyt2Bx/vkhuC+ ADjkPI/7f9/rilfNk45nLsHca/RTcNHiJ0F0VSEUIZM4CAiJTgYo8eBDkPA8D4H2wdU6XXesLOle dWQrebj2k4aflddpTRqyZ0Z9MnlrHL0yVO3VbN7O/B3ILhU5+QjajcXQt4mw2qqtXs1ZF88cqkHk OPpn2jlCDgMuQWRiwVseM7GVwRk4ZGVhk4YZr5dS6FQzISCA6bdyg43AB1ZCGAAZHVkccMpwMfL2 JD2aI6fIK16MqmwLjIWqHUkJXWtZcs6Q4mEDQ60pVIycr15LXpCqnTlEGUDMQhXNWKcJ5dHZcNLx cO8Rj+HQ/s1ELFp5vXdmybiwrlqbWuqx8sgV01mGTaJTi10ZVi59dFZKSQTMm7ZrEXSUTVUSMKqX 71x65aperv0X0a5MQUjlMZAwiZFUoD5Kcgjx5DkOfcMyQlbvUN416JqNkt2w9ZPWFggbAab1teJj X8o/RiXgffFZfy8KumZeuW2DWlKxPt1ClkGLWWNaKVJVPYlept1rFD9Z6d1lpM0lxpkrzafdapLq V/q9jbvdavboWY20VzbGdBLDYRO0EUtp2pTbBEdXEFtGkZvNEVp5roqLnfFtWAARRRnA7gUAOVWQ gMFO9VYFhgu5OI0RpyxarpdeSsZQB+m8k4FZblEppQ8O4dIISxytxFFEZFBuR78F+8wB0DZQRURM IcWSaJvGbhA5SmBRBUgAYAEBAxBAQEPp/p9fGX73hsWBsstG1yvOjrxMCZ0Ca7l6u7cP3q5hWdrF WfqrPnKaQKdoKHUUES9vAlIBShhHuvbsNq+qSL1Zw0POOGjskJHLuPSF9Ig2OdBM5kSKGTbFAO94 5AhwZtCGcmKIF4yyeiDq8vTWnSa1G0V/cd+YwMpjeGCa4kktYmjLMYmSBo8RliYhhCQV43unwvBa QRMWLRRgEnc7YUfpuYge2Mn4zxXi3+0ji20P1ZbAYtBIKBPSVKKYF7eXD6SXEoCQOBBMT+kUffsT KHI8ZgfmSvVtfUdibyt843cGeopOE44sgqAA4fizKJDu3AgAAZZwoY7hUQ8essqPAGE3ONWeudGj eLSdOjkBV0s7dWB8giNfPuD8g8jwa8765Kk2sanLGQySXtwykEEYMh8EZBwcjIOD5HFMYxmzrVUx jGKUxjGKUxjGKUxjGKUxjGKUxjGKUxjGKUxjGKUxjGKUxjPqwkUpNyjKMTWRbC7cJomcuB4RbkMP 41T8eTAQgGN2BwJu0fJSgYxeGYKpZjhVBJPwAMk1yqlmCqMliABwMknA5OAP1JwPeth/QPBSEG4t WzEKxJ2Vw1bKxkDHsI6UkCLvmjR5KPnz8ImPk36ENCxzN5ISh45i/m3wIowNWiLDcpmt1uX9I8Xp 5Lp96dZFoetJW/c/UXbYtXZjG5s5KclrS0mmZZPY9FcHp9glkmrildPlSudfrEbTJ0tTUs0KgWiR Cythi6xIY4dFeiNedN2t67N7QRj2MzC06K3BsAJ1nGKxdVgkJqYl9N1hyWdYvI1jKMpWBldo3mbq zws2x2fryrqvLUeoxNJilrtVnav/ANzvVdrBV6xK2hNHMbFc3cAkcjpyjYboVGK1xFWhJ1GuEkzx MfCTd/n4JJ1DysLcmOrnwKSyMM3fHprWdTS71WebLfaoTcSyrlt8dijHT7YlWRkt7i77TPtdRL91 aXAcf3ZlurRtKnt9It7cECd1NrBCSY9kt+U/al6rMskct1bWTSrFuTMItLy37b5ue5tEp7CwRVUr MZa5w1ns8fAw7OxWMzNjHDNzzePQRlZf7ui2jCOZpyD8i7wrVk2btm/q+igimRMhQ7aX2D9Azjh5 AB+oBnJyDFi7M5xliWwqqijJzhVUBVX4UAADgAAAVO0XYioCzBFVQzsWdtoAyzHJZjjLMTknJPJq Q48AHHz+f0/T+eUsqnDngfp75SzivqqhBH2+geP+2VMpEDjkw+3Hv/2/p/pk/eX6/wCg4pU2Mp+p +X+v9/75MUwG/IfpilREQD3HIAYo/PKRh5Ef1/0yGKVyMZKUeQDJsUplM4eefl8/+cmE4B49xyHe X6D/ACD/AL4pVLJim7fkGQEeRHjxkMUquAgIchlIw/iH+X+mTk9h/X/tgxefIe/zD6/3/f5qVb2/ SRY6FXWcwCMvHMyt5p+s9KRw0ZEg5GOkU3TaPbspWYkrAwOgExAM2EWAKPosofe8RIDHKn86H2h+ 3bDU6/PW2Mm4O5yV2VjK8eyxFVPXpVtHRSD8jqEmnJZmaRfV+Gm3kv8AsjFsyxx4Zi+WRsClosrq etcv6ZnTJJ6gq2cplURWIZNQhuBKYpg4EBD5+B/vyGYFdRnRRR9pV+WbtY9Mp3oKrqokInyssZIE xWFMeUV1ASSTBMV0VhIAdpBL2hxs9LvYrO6t3uIFntUlVp48BmkVWR1wXDbSrorMEKCUIiyBsAjA 1Cwe9tbpILp7a8eJks5uQsLsjxvu2bdwkR3VWkEjwl5GjZQ5UeGR85VePHTtc5lFnLhVdQ5hERMZ U5jiPI+ePPj5AHABwHGcXNivWB0M2fQzx5Pw6C7qugoYXCHoKlUYmMIiP4DCqZJL3KiCiyoKAUCg qK4ikOuoQEPAhwP0HL/07ULTU7VLqzlEkTen4dGHlJF8qy+48e4yMGvO+qaXe6RdyWd/EYpl9QOd ySI34ZI3HDo3yPfIIBBFMYxmdWupjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpmyv 7Prp7i7/AG1ttG2AVepUSRSf/ClKkZKSnm6gnYxiq7gwFbrRZm6Mw+J6ZSCWTrSyMgBBk2ZNbCQJ iqmCphKkJygoYOeSkEQ7h5AighwHPkE1BD3BM4h2jt61h1VaXW1lQdGRNXdNY5tDOWshBKpnbJ7C vckV3ILp3RwYJVrGUF9bJFWQcU6DRftZhEjeNlXQUo8lr2Qj/UpvzpcsenqwklO2aVQpaG2AJmZA xUNKwwkYJQDc0jSRBC4kvSn7NXWLeXVCphiIMMLbgs92zAQLIyglIUbMkjBZGO1Y0ilaQIdjknsq d2pWX1sZwT+ZgJq+IutcVaUcSLiL2JbTTcBT9MysQ3fqSyNRpQuoqpvomTaxrOICWO922Vsyjils c3s16dtD03pyq1mvFwkoVjZC11s+2lf5V2SHgDfc42K92SyuHc9JvzV+vNH9zsTkqMpOLM63BtW0 Wm4TiIlBQbFdMmq29o25DWJRGNGmaRqjc8VHIGh10Wm07tD/AAMMiCLFX7zrcxQ9PuJA6sJJt0Wk rXd2VyZQZmGPaLkvZ1M7kiqVUbBU0FW6FlvLGFMmi6boLkYp21szqMI8ct25fSk2h7KxYxb5qso/ I4TX+Hc/+EqpkLSchUtHAGkijnaOSdQzyFIZHiW3iYLuDtHCqTlkGGeVIe0rQxqLyYlV3IIppbNJ oYZH2QLNdQ28z3syysqlUlm3wMrZZVt5rruyd2dmzdKXnyPt/X+/+Mq5b3Xd0Jeq41nU0FG3rgJT JH55KYo8CAD47g+g5cApuQ8+4f65q62bKVYq3BBwR+dTZDtD6B/LI4xXzVI4+QD5AHtkmVTl58h7 h8sp8D9B/kOKVDJi/vB/fyyPYb8snKXjyPv/AExSpDFHnkPPP+mSgUR+Q5XxilQAOAAPpg3sP6Dk ce+KVx8ZOJBD28h/f9+Mh2G+n+oYpUuMsB1MbzadOmobHsxevObhKsXEDB1SntJWLg17Pb7ZYIyr 1qIWm5lVKMg4g0xLtFrFPOAXCFryUjKkZSCrRNk5xs6Kuojfu6pq9ttvx1CPEQDCF+7ZehV2eiIk 0yoib77btJSass4pPxZnAGNHKni4CRQjxZLvGSqr0QRzY7C4ks5r8dtbeFxGS7gPI+YwyxpgklBL GWLbQQ2FLMGC4Muo20V7Bp57jXM6l1CISiLiQq0jkgLuEUmAu5hsy4UMhbYmAiHsPt8vllYB5Dn2 y3NI2frrZZJBxru81W7tIlwkzkXVUm46eaNXThizk2qaj2McOGpTLxr5m8RADiCrZ2gsmYyZymG4 AGEA4+Xnx+uYjo8bFJEZHU4ZHUqwOAeVYAjgg+KzEdJFDxusiMMq6MGVh4yGUkEZ44NTicfl7fX/ AHwB+fBgDgf5fx5ynjPmvqsbOozQVa3LSpuJdx7ZV24YOEw7kimKuBkxACHHjyPzAfcBDnnkA58Q /VFoac6ftnzlUfNTkinLhwrDuFEiiBmpXAGOiU5iiJFW5yplOdMEx9JQqfcYh1QN+gWIAICA+QEO BD6gOaGftWOlGQ2BXLHcotjHuJKLE01W1kGTlkLZkSMbpyTCSeGdvwfvjP20m7Ms3bRrVJm5g2Sr JRwxWk3st6R1xtJ1ARTSAWV3tjlDZ2pIWCxyg8hSpPqJwNm7nIAMW6u0Ia3pjNDHu1CyDS2zDG54 gN0sB/icMATGoyRLtAAVmI8ouMmMHHHgA5ABDgeQEB8h55EOQ57RAOOBKJRADAbJcvOqApjGMUpj GMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUplxdRWGNqW0df2WYj/AL2ioO2wUlIRoiQAetWs igqqgIqAYn4il5DuAQAQAQ4EAELdZ9OFEpZeLMcwFIR+0UOY37pSJrkOYxuAHgpSlERHjwACPyz4 kUPG6MNyujKR4yGUgjI55BxX3ExSSN1O1kdGVjyFKsCCQeOCM817sena6w9d0XI7QlGEdETez7xe bkuhHuirklophMK6/wBZSAGKqdMqx9PUrXjdwREClBZqoc5RcGWOfWk4sVr3tv6m2hF0gtT77DVt hWhT/wAdm6pWqQkJv9pIxB06ZO26l0vGwocItw1hpaMVp9EZzCkmVe3QJInXXtvrvkKvrmnarqb9 rLR7CORSkHMbKuvilYZRV0uevIrtmjNOviogq0ZvJuOeP5lZuEgdipCza7aeY56dA+3Y7qIv9Rtz moMYWS1nVY+NZFbpkaxLCKt0u9jJaPYKAJSINY1tQYmRcJFIHpM27Non2lejzRt9ouo2VveancWh ht55JbdY3KboIC4FsO0SrKolW2SIqf3MUZBjbcqr6A0rW9Lu59P0u3vEnv7eCK6llRZSk9ysYa+R Ztjq4a3a9aYOrfcSyR7JV2sz+gCmV9rWK5FxDUgEI2apFPxxyZQSgJzCPACIiPPP5+fnnagEQ54+ f9+2UTKJolL6hexMEjHMoYQBJMCh+4YfHn6/pnT6Jfa/saDUsVdUcHj0rBca0b4tA7VcJGj22apc 1yioAH9IszX3oNlRACuG3pOUhMmoUwxUK20vj0qyoW9gzhioPwWCPgc/hNSRpFMgVmHcdXkC+7Kh QOw/JTIgPxuFd37zfX+n9/yyqA8hzlDKpPb+P9/3+WcVzU+MYxSrV7B2tXKE5iIJdy3lLlZgd/st R2c1WWVrsZI8EzSS8LF2CcgjSDaNRVIvIOG7hX4RIxDqBydMDUUNnNmCsY3ukU9pzmYcEZsBnARR aOHS4f4LEsggqrGncqgAgm3K7VVOYBAgG45DpOwYS2xuwafeKpDsZmRiEn0QupI8JqmippZqeUTI 8SamVS7js2L0W6aJWqyzBBsINgKm6aZG0iIs14nomBkXzCLCWUETNYlkR+/ZNm5R+JWReypPhHCh VjtzG7oX02nqi1MC4iV7mg1e/wBUsJPuYLS2fS7S1e4v5p7ntSnt72k7WEcokUKq/MMjOxdQx9Kj LiitRC7XFxJ35WPYSKEOkSBFwZdzxl3aTcuBKAAVOwetgIoRQoGIYDAIc/hEB/v+PGT51We1N+xD tzTq5c7FENK3LMEGK0fEa+j0Qi4ySB+vWzwzClN4NOHmh7mEodrFt5xuzXeGr03BP3Sz5WtWC2gk MzRuSkC4sKCSbaRf1tGQZQ8uukmQiswzh5Ry/f15KTVBdyjXFp2yHg01CsTWWfMiMgtt7KcXllDe KUCXCRyxoC25oZkEkUmGROGQgsv4kY4IIG44RfDhNkgBGQxAKggDcrFWbaQc4LYDAcHcdo7Jk6aq iJu9JQ6RgDjvTOYhuPp3FEB8/TnJMlP+6P8AD+uZFfVcxWWdrNztVPhjJHUTVMoLFj8WJ0wMBR+O BuDwCiBjAcgLgRTkPUAwlKIcIp+fA+B+WUsiHuH6h/XBJPkk/rXAAGcADJycDGT8n86sX1EaBqfU XQwotucPWrRtLx06ycsTIgqjJRiwuGplfXQcB6HcAgYSemoHICVVMxQEOoU3pgpdT0HbNAC+dSEH dKZa6XOv1nSyUg7Y22HfQskqLtudJZu4+FfrFTVQOmdEfT+DM2EheLlbzs8/RtWXS+VqNjJyRpNd n7SNel7ASqxs+hEwkko4jHVmcCMZAAcpviSy08keBbHbAM0tENO6civL31FdRnWlr6zvGDjbFxk5 9grIMjWKMh/2bifWO5ei3EKL8RIxjNwxj3TRgsxmFJZT1o9J+qIyB1HR5Noun6hqkS28GoRW8ENx 3oopSzf3lQpMioqNtVMxFyxAYuO1HM0cwjimuajp2k3BuJtOlubm5gME0sJVGNo4C7dzOpdmKyKq xjKCMtNJCskBk34dG+gr1pstpc3ZjAw6rmNqtXiI2DctnwLRdSjFGLeSfv2baNbunbwyrhUy6END Jn7jGJEMidiJc5TqlSHk4CVPtERP47CdvHPqDyHHICPHPt6Y+QEeB8pGnvtSeprX0AjGXaYj52QK 1EUrFba0WXUcuCrEOQFKtEzevWzkh0DKJJ+lcYAqShk1DqKFKsCuyii/aqNHjWHC0RtBkmjGJmZq 73Qzy4ayYx7ZJCSfQqcDVHMFtOOl1ilapRc+gntQ0k27TTzWHWavmsOTv1XpzXHuZZ5I4bl3cAG2 c7XWNFVWXugYHCqqs/eZyAEJzjo0nqbQIbWO3SS4tI4lJIuoyzB5XLsp7W9mO52ZnSMQqA3rAxnc x2iIAIfPIgQR9/Af3/fnLU692TEbCihmIWPnIsijFKeAssxA8LLwUpITjGJl67a4p2/psinLNoM8 +SPi59ey16Jl4ZW/V6sS081aG+nFX6If2SerC0lHDIMHyAx7Fv8AEJvEo5aMZCcJTvMKZn4y4Sxi kQEqZYo0M7OTl2g8eRV43jZ0cbHj/Erec5AwMZB/EGBzgrlgSMZl8cqSrE8R7iS/gdOVxtZsk8YG EIOeQ3BA5xcEeAEeB5DLK78hm8zq61IrNk3JgjXBUklCeqQyjgoNUxEogKQfjVR7xOHINhccAIiO Xp986TsMypKZYzokQVMWIfmArhYW6XhqoJOVQQccAKvpgI9g8c9w89vaPwPKng8gj4JyCP6mu0Zy MHBz5HtX55OxY08NebVEHaoMhi5yQjwatkEmyCJWjlRECpoIkTSSAezuEpEyFAwjwUM6Xl39/Kor 7o2WqgJTJGuE5wJBASiJXyxTdpi+DfiAQEfAiYB7gA3OWgz0xaMXtbZyMFreFiOeC0akjnn39+a8 wXqCO8ukB3BLmZQfkLIwHjjwPamMYzIrFpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUplZ uuo2VBVISAcCKp8nTTVL2rJHRU/AoQ5e4U1DAU4F70jcKJGIqQhy0cYpVceFD/jHjnnn94eA4EQA vI8B5LwHy4/lm9j7GKfTRvFuiRQIkUqdWcKqqiUTqIqubKiQioiUv+WA6a4pFERKBlnfsBhHNHsQ DFBw1Xfl9ZFQTh6ACJRAQ7ylUOJgL3EKcvcAlExD8mT7+5NQpM1enbqhZ9PFhh3bKDBQJKITj7LJ IHWTfKoNZB6+hVGfL34UE2Z5GTTeNFEinelkEnR3xFYdgieP9UWU+oaLd2ttF3p37TRpuCcxypIx ySAfSjBV53OVH5iS9I39tpuv2V5eTdi2jE6SSbGfHet5IF4QFgA8isx9kDHk4B9aHVXudnSNZzdT ipBcLM9Wq9caOkBbneNmd7m0KoymEjEOuAJMRePUVTGD7x/8MeqJRqoHjvvD5nQo2sTelWksy8We t1thbOlGiiy53HCU7si2zbYpTn5EOGckiUxeRAol7QEeM02QvVNqTdFwpUvNXt/Gylfdy8lA1R0L T1rRYJaNeV0ilkdopu0kIaOinjh9AxrN6d0rLqw0pKikrXkY1fbH9mfcoiY6caLCtytmL6IiQjFY 4jgiy7T7sUFim0fgWNiCNJxumgCNkg02wFrthTlYAjiUJF/eS1K3lhdWNp27mF4Gaa3eSORGB3lb pECscBgoieQtH3ExcKjOjR7WvOzv7O9nd7SdLtRBcxxzRFSvbWWwlkZ0G5oyTcx26LL2pD9pLMFk jnTtbIygAjwPPPy+g/llb2/LKBRDuDyHjyPkPpgypBN2FOUR+YAICPP5/wB/7Zqa2GD8fn/L5qt3 B9Q/nkc4+VCm8DyPgPr9MUqcSlH3AB/UAH+uXX0gsdDYceqApdice/EOQAVxcC4YAkCAD44+GM8A 4cgb90AHybMWZ7YsRGd3w7lNwUpRVFdM4lbFSAQSFU7k/LdNI4mEWhi/EA8IkuZqBikMYLa1bfkp F7A19ZGLBV4MBbGa0lCBYEIGNex09HOqzLSDldeDeSconWGFhfTLSNWNWBlH8SgJyInTZAeMdUtH d6Jq2nRyR/c3NhcRxRyOiCSQxsyRFnYBe8V7YdvShbc3AIqx+nvpR131TpV1rWiaDe3tjZxm4kki jcgxRFHldSFbISMl9o9TgbV5INZrbOIKd9tBRMJh+9FjCI+494FN5Dz58/XOh5ci/wAM5cuD29A6 jppLHBZ0oYoFUTcnDtMZQpA7BRUOTkqiAfDiAl+HAGw8BbfMrpm6hutB0poZVl7Nja20pHBSe3gj iljZf4WV1PGORhhwRVezwyQSvFKpSRGIZT5BB5B/MHg/mKYxjN7XVVMSfQeA/P5fx/v/AHyUBAo+ A5+g+3j9P7/rlQ/7o/w/rlHFKqgYDAICHuA8gPsIfP8A5zCXf3RpQ9tPGlugm6Vau8SBjkKRV+lT rY3FiMeaHudZauCxrovpEYKR1mbMC2WBdRMMUrmXrDacplizVxmRbXU9nKJreRo3AwdpOHQkEpIv h0bA3I2QcA+QCMa7s7a+iMN1EkqHkbh6kbGA8b/ijcezqQR4zgkV5Q+trWMPGumUVZ4WI1ZZawzZ oWKNkDM4WJkFSAikeyVRwpJPQlKTLrLtRgpkjt03TfyKVKlHbXYcNaKvCUemvSO2epWmDWOnzVrG MoQwMwzs29dmT0vQmM+9ckcxqUJrddtU7m9UbHUTct5afb1CdfN0W8vElcawspazal/UVe9bUPZs G5rOwKhW7nX3gEB1C2eFjp2JcAmcqhAXj5JBw2V7DkKcnekbtOUpg8lAQ7JFQsbCoA2jWiLREPZN IhSFD5eAKAfLx/8AI5Kx1cyWMcMdnm6jcsryzNJaoeMukICSOTltkc0zpEQrEzZwkQPRqyX0s0t7 /dXVVKwwJHdyKAP3ck53Rp4AkkghjeQE7OyQS+J/Rf0oNOkzXL+koW+bsriXlpJ+uwJJWRtr2uMx sFlfQ7DXtEnrLbCUlP7rmW5bGYk7OSdlmWoSc/YrC+SJKDjr1KxN01htaK2RTI+MNItmqBIZd48V QNY00XLqQl9fzRitG7eKjJaPZpJViyuZNylX7G4LNSkY8axSsLatqBR4Hn+A5YXqGqLO00KQRcIi Y6XBSrJKqt10Dqcimog5bGTdNnHrgiDVy0UI8aOhQdpnKYvqFi015Nc3cl5ckTzyvvlZ19Lklcgo hQEFV2EDHpJwQ2GExsrO3tLaGwt1MVvGgiiCtlo/JRxJIsrBlkIkDYJDAZDJuja5VHs7W51SEsrM FSIS0e1eFScJCi5RFyQDCi4QN+JM4CPBiD5Aee725y3/AFG2qOpWldiWGUcJs2kdWJddZZU5SFIQ jNRQ4iYw8B4H68c8+Q45yyPRjZW565OVA5vTkIiRWfrNirvDpFNMP5FeQes27t28+Fav59OdcpEb GBmmHMeiPYxApcIftlepZpQdVNtUQj4g2G6rAhIIEMQ520KkQVXwqJ+qQwkXTIWP4L3iRZ+ksJDp kVAvZp9k99f21nCGbvTIvI2kRbgWkPnAWPLcE/AzxXVqV2um2V1d3LIpt4Gdwp3qZgoAjQ4XdmYh BkLz+LbzjyfXGRNL2mxS5yempKzcrJKpgYTgmq/fLvFUwOKaRjgmouYgHMmQxwKBjFAxhzrWclwI nVUUN3D+IwqHAvIAqp3nApvYoCYQMHvz2lMIAbt7c42ekEUIiKPCqqjz4UADzz4HvzXmV2Lu7k5L szE8DJYkk8ADnPwKY9/bOcyjnkm8ax0Y3XkX7xVFBq0ZoKrLuF1wKBEEUik9RRb1DCkJCl4E4f4Z lCCBs2q9L32Uu4d8XyI168YSjq+u/gHs1rGqvYdnN67rcvAPJqJum/LnMEfwPT/SHpPuhVi8sMJa 9i2tCUattaal2A/cCg3+ZZY4EaSV1jRQWZmIAAHkknwB7k8D3oiPIwSNWdmICqoJJJ8AAeSa1OYz 1zdR32JsNqDQDFk2nde7rssbGffWx3OsNbvqNtenSPrCsk00q2RnbNV9xUSpRT98Sw1myUqj9RWz loNKcj9q250jrjQkR5wtz9Ktv1bAft3DSjO+65LMLV2QsUS2eMJWm2huUqjmnbJqkkkjPUG4M01E xdV+wNWrtITeAMAgI6qy6g0jUJmt7S+hmlVzHtUnBYDIUEgAOwBKoxDuAxQMFYjMudMvrNVa4tpY lZBIGZDjaSBnOMYBIDEEhSQGIJAOK2MmKQ5gOYpDGKmAGUMUoiBCiYpAMcQDgoCcxSAJuAExilDy IBkubmsGmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSgDwPPkP0Hgf55y1lQMoUSqnVIQoAmZQBK YCFABKXt5MBRAQEDAUxigPIAY4ABzcTKvBREpUyiJjFKAgIiYQUHwPZ2D+IDBwbgxeSmMKYgPaBj KVfTp/b/AH9uSnFdMnLtJGSTeLpRjR06dFRaFFUTosmCDp48WApAAjdo3XXXMIJpJHMYpR9AGq9j 3rVVlnoGhV16Dt6o9km57bOHhWdgo8jIuZNjKwUSwhpEgu6TZrC815MQxo6OnomtIU13dXaKb2sC bFX7MLpVu8w7Uu6kU2Zx0qkZoDl20MadWKYUhI6hlF1QjGbFkIqN1CSbdytLvVlvRLHt4hMLH6Gr H0x0qxUKOgWqMnDWSID4mLn2qikbYY+QbCn63Y5TD4aQZHWTL94RqpZGuSyZCpOmEnGqAmemestX trzVGtkUTQ2sPYeQOxXvF1kLBYyu7t/hZC7A5O4LKi7bz6J0ifTtHS5lcxXN7MblITDGJPtggi2l 50lVDJkSRsYVJ2qNxgkcvibEyPVzbhg3n7cuoaJD77kZSFrVZiSPnyTkhGcEwfTUy9uJYlswOu5k B+6SrupuSYNHMdMxEAR5XlslNTMNlRVhWk7o+l4+MXMcFfvySev2ipkvhm5FkHS7l00jQcCqmUjN b4Ez556hyNDqCc5vhaYLs6mWs9JnU20rGqGWRPI/CPmJmqBRHsM3TTcPCrKHAClEpXbMv7ypRLx8 MHX7Ldr7paHhtY3GWlrfU6/WI+vttoy33i7tUy0hmR2acnsB4sd+RxY1Ipi3kLHdheoR9hmTyz9z G1hVdiydwknehJKKUICxpGI2ZWZ3ZsxoA3bbau18tsZVTCR4WeFe3KIkjysqAm5llaZYyiRRoNkk p7TSxlwzQhY2kDNIS8i79gLGUjpJMqjJ43dEMUBA6KxVSmLwHIgJTCH6/wC/nMf+pm+SVQpUJXa8 /Ti7TtS2xuuoOUMR4YsMnKspWYtFiT+DAhgXrtKg7PPtCLSMOk4ex7dqEs3XXR7sQII9papJ2Oiz 5p2McqISxFIyQUQeLABknjdQ52qgJSLV2JEPUIqPwT5iAJPivUTmKepu6ft9vomstgzi4wzHWm3a /I2BKaiDGdO46wFd6+UboSEe1fsk4sS2lQ8kzcRjh0oVdN0jNsJCKTYu+I22OrcFl3MispbdKqFo UK8798oVSrAKQdrcE4kPTWjQ6pr+k2E8qizu72zhnk7gjKwyzxpcMScbFWBmYOjF/JTayqT9admF nS6SZQO2YR6Z28THeu4XIwbFMsRN24UeJkeuJt41OQZBd4ZZVoY67Fqqp6kk+lbVTm06zSxM8emW kXSAj6UcxIVd07UEBAiBAUOk2RBQ4AmK71w1ZI94HdOm6QGUDucn3qqvCmKZNUTKkEDFEpym8gJe Py5ASm57TlEDkESiURxxkNGsbLMqO7Ass7Yiv6wNRcuCIKiChFCg4QSWIk4ApiE7CLlUIUwAJSh5 E1WQzwXF29xqM0hCuWCEli3q3Y9iecnyNxySckmv3Suemb7p7ovTOmugtMtYYJrCO2lnhWFAsbwI jMp4Ub1JAfDKihVVMDA2MdGfXuW+3JTUOxmzMtPkGUhGQz5i1lpteKFPg8M9sdmEycNCP0Ue6OkY MVJhd06RbybGVBFwu3LntaKw+qzpIjgSO492mC8ZKtTAuyfNVAAyZ0HJB7O4xBKYxQN+YePxBper lZiKokzJBsUGIsSiRsLchUPSIJQKZIpUgIX0TdpRMkIGIJyJKh/iJJnJmZr7qouVUrp6lKIxtihj qpHRSnGovvhgBQnrAmYirdwU4oioRFVF0gcihkjufjEG6TbOldSk0vVZL/RIFazvjENS0uWRYYnk QlRf2L7WWC42MBPC4KXAUZdHVWPh/wCpf9irqS4tX1/pee0u9SkZpL3RVmKTMz4LTW887LA0iuT3 LcmKNl9UTK+UfLUB58hjJqA+re1oReVrL1nC2Ju3BQag8fFXF2qDcVFm8fIOkWCBhcOUVyMyHWIo DZNF29Ra952qfPdQkyyVkEncLNsgjnxo1ZeQg5qLbKuSNknImjnEoxZJSbUUFiAV9GmcMzKlWRBc VkF005zp/Uelag5gW4W3vE2iSyusQXClgCCqsdkyNn0ywPLG2Dtc4Nfn91DoOp9L6vdaJrNrLZaj ZyNFNbXEbwyqyE5BSQK2QOTjI2kMCVYE/OEOfA5SEg/Ljj/XKwgIe4CH6+Mhm9rTVREggHPv+mS5 yMYpXFKUA5EBEQMPd7+P4cfL/j6ZNnJbMnTpUjdogu6WOIAVNFMypzGEeAACkAR8+P4jl0q9qeVE 6EnawJAQifJ1fjlCJOXAFD1fSSRJysdUwJqdqKQGE4AIAQwhwGr1PWdN0iIy393DCdpMcJdTcTsB wkEAPcldjgKqqckjOBzT8/A+T4H6mutU2iS10crpNFE2DJqgou7lnZDfBtiJlE34jBwBzDxxwA+P n8gHB/ql2sw19UbBEMXKUnIJNXTUiCahVxkTh3NWTRIrpQCuHEkuKDRsQ5wF26cJkEeT8ZnjuvZs XT9fT7KGfMK1AsWDkXkqsPooKggkocCJibhVdVVIpxORLnuSFTj1OSglp609QZHd9qHbN1kjH140 KK9RizAUEJ9d4Vcq9ulHhzmUcx4x6wMqrFt/RZJEcyVjlTzishWQqWt6b1O91ifUby5ZLazTsx2e nFMzQgBmMl1OqnF1d54ttwFvFGrty5J7goQBsEuThB6Tg8ZlKsRuSLIYjGGZkQkbwR0/S9ontaWx 3Jy7xsWIY1AgzJ1kF2ypXLL414u8UXMv8IZooX0wSScMiPGJgdGNIPRfB6Hmm66t+u99b/t9nI/O 7hY12rFQZQV9RIUWqpyrO0gMkUQ9VwZUqYlVWIo1bNXSQlIudMnoR6+NspRbxtpnTNKZ2RW1Qr5x sa2wD92EtrWDbSEco8eqQMbHOX9vsdlrriyvqjW4KSStSrmuSU41g7C1aOgjPKzeaZMwmxJ2ipws ypOt7AEUyjlmK33zKuHzhIkT93RrcFDPkpxJ2zdQYMU3AybJ2xdsTqt3KfdeXQGnoJ5r+bZ3mt1+ 2jDRlliLhJJXRSXjZmQIgkVGdCZFDI6O1Y/UjVmlggsrZXWD7hlu5WEg3TxgyJAruNkiIH3uY2dY 3CwsY5IpIlt2I8+Ry7mvtOWjYLN5YgUZ1miwyxgtOwrMqszq1fSIkq4Mdy8Kgos+kHJSA0iICJRk Z+wyyjeHg45/KvGjFXdX0FfYvbK3zbpWvPaGjt2/194i0t0B+2jmgdPHTw+jkWSk3E9UG/oeCuRm u02k7IRsQ06c9QVXZmyncI1tctcUtesmrGWR9U2q+h3pM+zpi4K3kkk+pDqJqYWBeqbNuldZQNN1 S5s0kxkpBvovSaa8hWNVLFJCQ6IXeQe3jdRymexh9kI0p2WqJzfXOodN0C0lur6dFEalhGGXuMcZ AUH5+TnHnBxiqy0zSb3VbhILWJmLkAuQdijPJz74+B+mRWoX7OX7BmUfxcDtvd1qvHSlrRRq8et5 2Wia9CdZex1gjlUG6lFqVljrXX+l6kFfLqP2VwuLB7vaZUr/AMHH1TXMJY0LQ+37yI9O3Tnr5jpL pX11VtTa2jVlF0YKqgus4lJEUkW5p20WCWVdWW8WhZKPjiOrhc5Gx218miim8klipJnJr+2d1PbE vc46UUlnokVXPwQFlALwY3n8JT8DwUePHj34+fHT0rshXWLeavEq7apvlFUImPYxkxZLNYHiDZZ8 tGVGoVqOmrZbpr4Js4eowdahJmUXTQVMk0OVIxi+a+oPqxe9TytpmmWkkcDPtHbDNI4BxkheTwSf gc8DxVyaV0JbaGi317OjSKoYlyqohIH+L0jyP9OeKvpcHU1LLmc+uscBExgADG9hHzyPIgAiI+AH gA8ByPyx92xpLpy2tUpK43/XiV12PHWfSfTzIWSEfTcK7Y1TqG3JStXOa5bZSNbOYO5oVBS9p7Ma 0CxA5ka67ZQtxZhVVV4e0heqRrFnt0a6Qt7iS1pSF2SjNevREu2b7KmBctU0Hf3rdKrMSLKiMw9e UIgFBmlLmVdODsTLYdacpua6peK0NazKdHPUZUaY0ax89WNVzt81q0iGMd6bHY+p12+09YqsI84C iYWuwqbXJZInBQ9RuHBgMI8YPR0Ys+qNOmlvGjlllVZESYoNjum5GkVhv7i7gyqdgBQlyd6Du6gl a60O7SO1BhjRmR5YuWKqSrpGw3RlH2tvkAb0soj9SyV+axLMjRkrJxx0nKB4+QesjovW5mjxEzRy qgZJ21OY52zlMUxIu3Oc5kVQOmYxhKIj8/OyXKALVbbZq2R0k/Rgp2Vim0g3MsdtJNGT1ZBnJtFF 2rFZZlItSIvmbhRm1M4auElvh0QUBMvW89fjwKoKmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSm ZvdDXTDI9SG0mkWqzcnrsWqgvKOEwUImcBU/C3BwQxDpHV4EoKJGBVMfxJ8n4EuN2ptWWXbtwjal W2a7hZ2sn8Uskn3laNhOUqix+RAoAUDAHJzFTKYxRVUTIInD2f8A2f8A0pwHT7rGOTIzS+9npCOH bsSEFdZdQncc5luwonKIABSdhSGOQoKKkBZRXiG9X9QrpVo1pbyf/oXS7U2H1W8TcNM2OQSMrGOD nLZwvM56L6bbVbtb+7izplo4LBx6bmdcFYVBGGRThpTyoACHlqy107qiu6oqMPX4WPbNCsWLdvwi kRMCAgQCkTTKAcgAewBz47QD2AAG8PIGASnDuA3uA+w/l+Qf6B9MlxlI5JJJJYkkkkkkk+Sc58nm rwP5AAYAAHgADAA/IAAVwixjEjo7wrchVjgJTmL3EKIiPqd4pgPoisI+7gfI+A7uPw58Ww02Hs7B RjLIA9BQBKKq6aHrE+XIGRKgBePcOCiP887cX2D9AyOKAkHIJBHuDzWuO89MUzUHjyw60kpSAdul xcunFbURaC4OZy0cuXTuIetZGvSbt4RilHnfyUY/kkY1VVFs+QMp3F+Mba+xYuMmKzeq0nKRD5L4 NNzAJOK9ONkXKRGipk/iXy6IvWjoFJZKbbS8WqimdMiMcD+O+IkdmhilMHBgAwfQQAQ/1z4EpVoG YTFN/GNFwHnnvRII8jz55EPz/l4wSWXacEYIyQNwGVOA3kYKjHOByAPUxOZaXjWk8VzGGSaKRZEk jZk9aliGKKQhY7jubbuciMsW7UYGrhk+UkHKDKfUZRU6+IT7sIYyUdG2lNJko5CaqrV67NIpN3zJ m9cSdVWSePqXJw9gZOZWXrxK5ZZ/6qsPIIGEp2yoD3f/AIiPAAI+fHIch4H8vn7iGbFprXFJsdbc U+w1iDnqy8K2K8gJuLZSkO8Bm6RfM/iI50mq3V+HfNGr5H1Ejemu1RVJ2qpFMWzanTVWY1eITrDy YiYaKZCyLFBa7oDlMzBpFRtd+DeDYnUUdhEsGz5N5F2Kr2Y085cRrpSTj/gnaUzGb7pq1uZWmhlk tWbJZBEssTNjJYEOjRhvwhBG4B5LkE497/TP+3Bq3Tmj2mi9VaOmspZRrBBfJO0F2IUG1ElDJKk7 KuMyF4SecJwBWJwR70ANw3UEOPftH/T6+OfAcj49s452TruAgonAff8AdHn/AF4+vv8A9szDjNHg 4hBjbPI2gXj1sYZAYy0oGI3XXLys1iLHExFOmuxL11U2z0sZDuilAFSFRVasnKXIjenyjslnRlI6 WlU112p1krZY561MlF48xVGb1nGTkxLRzRcqpSqGcNmrByqqmmqqJzppmLrX6UkQsput+19uUj3I QCAWDM6HGPGAQcDnHNWva/28+lJFaR+m7uItFuRHuAsm8qAqsojcDnBIYqy5IK5GK+V0yNk5B6/b xki2k5Rs2fPF42PdIPFSoRayCL1s/SKY6Kafxa7Zo6YKd0g4KougRuikVw9aZUVHqrcUswU+1VY5 643TRjG7M6i5/gGLVIrZAjRB767dECJEKIimgHqn5UUA5xEw4q2aSmenazMdrwSnpUZIWaF4j28Y QUoQ4JpxrW6quI5uDlKFQZpxsbelZP4mFha9FRVqK7qcZVbG8mMsWG29Ab1ZoNLpDNYCdAEylkmh 27IyxlBBMgorH9Bu9IYwkMiJRTEEVEwWKVY4p5W/WOjXtldI17pd3qOi9pDHeWkjiexuIyGkKqoi JZCyN6GLIjKeRIK/Oj609d6h9V+utU6vtjFZPIRFFZBFRY7YDEJDZZiJAG3y8BpI3T8UTY7pLSmp LKP3xBWiOj20iogKbBVu6YuoxMyfaqZw4FxJoSofFqNw7PQgTIsU11ClkDJptVPoxOsVJtJM8ZOR rn1QP6aiTlkumqPACUqRGztV2HdyPHe3Jx6Yhz5KI447D1Xp+ogMmttqMgYEBT/zkuf4ZmiVcTFT IpIiPwBDiIAAlOuUSiJQMACJQNPCb50VQIVOIqtxUuE8DZ09TftvjWcMik1Oo3F2vJmarHXYmeEO yIpDtJlZV6RVqm1OZBx6fTB1P1FbadAuiX+qah6wii80s3OxQuQJbh0i27QBuZpSzecFmLGpobm8 WYQ3iwxEngd5GdySq4SPLzOCx4CfhOVBC4AyeitK2eSWXRIkqgZuIAY7xjLM0FBHjyk4dxySSwB5 5FNQ/A+B853FDUcZDgmaSSO/OQhTvFHJ37Jq25+JEQS747/McfDGKP4ycFVIYTCCrMHWv2J6tZhm E86r6VttkjLCgZeVl419CMfQjzPGkfH1yLekaJt4Ru4O/fJcun70/wB5KyDt0/TeMFFLN2vfe/LI 8XcMIkyLX1BIRJNaRWMoXvNyqZVZo2BMRLwPoA3MAiID8UHHGSixTrzXX2XmpR6VblV3i3sJY5Gb CBgZDdRSjByVGEGRlwwyo3cMEkiK+6EBiTwQwKhsLhhI6ZYDnBfBJUE4BO3/APamHqrIqERX25eT Jqi/bKQ8Y6RQXWInyoM49bKgKRRE6hU0k3XaUxE0ju+1M2Gu++pSUqka/lq1X2dllUjg2K3XnEJe YV+L7jNxRi0zgIoncpeh67n02bYU+5R0gQnJNfq7bfeyiFipaQlY9qY/Y4+7AXhUDoG4ESGWK5cP 0eB8Cs1dtDCKYGDt8gORWrNAQFJaGUdJEcvl1VXSxA7k0ReuR73LlQxBHl05UP3qO/8A1RjmE4iJ hzd2XQVvbXS3Ut2l3M0qtcSTRXTzTpuBljMrX5CBhxtVCoyWCZwK7SixYMjq+V/ApzgjGNoxxkkk lnONoAUgkjCPYMjZbtKQ966pJpKOhy2AjyoUBlKvCQyj9EyhIckomP3ahZZftL8RGwRI5WOZyJ0j tkp+XiIeeSnVv24NzyLaoasrzinUYrWMOjY5FFwjJLCss/B+1eVl43avIUGqKMWt6Mwc0pJGevYh WIrqiBJ5HYvY9b69ljEkJ6Bi11mqKyYSL5FNR0g3WEDLpA/d8uCtTCACZMFAIIhyAfSzVsuy1VVh 9Z6bodjnNsXaKdP9Y62rEREobDusBHLQbR5dothcFoyp0DUrN9Mr19zvvbL+I1lG2+t3GmMW9vvF Xe0lWydPsjIFtbC0RUhUcINttaQlgGkbA2oi+HkkY+kuzDcA41d9qlnp0Znu5RFvciNEI+4uZAmF UElSzfxLFCI1VlRA/bZoXsSOptL9OsGSQvslJ2C5yJn1qj41s6Se3iyWGGjiJA/K4kF2cRHKSjn7 rpTOYs7+vUqSsFmq2vFn5311hIWX53Tx0HL752ZKdQPVWpCa603Ku3UpD6d07rGkaZ2xdYNSWgGr Ko7c34MClvyf1TZKnUol9YajPS1T2MZGyLtm8RoJaPX1glkdF6goehHat82s+itq7+kJJ9YFyMpe ySerNXz8tFBBSQUBlY02MvdLM3gi/soG5djRx7qtVzO6pRYvUmrJE2qmvWbLv6aliHbJqg3aEAxU GyPCaBCCIiBSkJwUocG/Ln55qb/6gW3Sk01vptyLi/eIxXN0CJFX1BjbwowZEVSse+YM7lk2wtGm C2ofQpuqY4pL21EFlHIHt7bBjJwConlcFZJGIdykbLGoDbphI5xHsTt3VFVtX0KG1HpGsV7WmtKh HmhKpTKbHJQlbg4soj2NmUU0BNBMgD3CbnkxzGMY5+TCJtUctuhzf7JbGLp+MyMFLGibK5eP27hz FTirWJsMXAkakQcnXScQ9hStwEkHJCwLezRsdEpqIOXjCvdclbO+k1DidRQ3cYTcib6m59vy8eQ9 uAHyAZhdszYktq11I7wjnDie0Yowry2yFZGdISLSczsnVIaDu2pl1mcgtLJsq4qdWzV9o9YU+xOV YB1T1S3F3f3MhWU2ua11lfS23ce4uJ1EdlHJMYopLyWWNYbYM+EM1yO7Haxs0ZluTEm4ruU74abp vTdtBPtEUMMm+5McYkkW2WNu7OVALmG2YpLcOobt2/ccKXCY2GV9JiqsYE3x0fjPXT+LWSQdOokB ZC3bvI4XSajZyqg+BB4LaXSfEdeq5KcDpAVmN59aQ1V1ky7od7O2a0PiECw367zLiy26wLGMKzlI Xrz/AClZrp5JRzLs6HSGNZ1xWncrKlqNSr7ZyZuFnWFTdR8e3kFjgCK5UlEjkEDkVSUABKYBDwZM wKAYTAPgPPAhzx2CJeLLuCNkziPAgAfPngfAePn7ceOfIceM1dhqF1ZRNAEEX3BjMgACvJsOUDnG SoJ3BScZw2CVDVsbqzt7mRZiTIYt2wsxZU3H1FQSVUkErkDIXK52cVfnYtsO9heUTmBQSCBgIcfP geB44AOOeB+X19xHjpepNoSOu0bDYzMpGaVZxEn93QbA7EHk5JKs1iMIhsExJREQJ3iwlS5lZWNj QAwi6cJI95yXQp2nLFd2wfCt1V0wKA8gAmLxwPPbx3cj8xAQEefPsPA8h306WAxHkc3aOUZJiC0k xTBM/Y6XaJKHMzOTgB/zRO5JI/JfScikcRFP1CG3lvb6sb6z1OKCQiN0aPIbazJg4O0qTn35XOcA gmte0mnmCaxmlVQ/EpBG5UYgZ5zjA8Egge4OK8OW3emO6Wuqa53Jq3U9yiKLLae1uwnXM0vEoktG x63UWMNaJvWtfd/c98sNOszaMj7MnMGqrxujPzEyxLNy8UgxsMhg8+ZPYpVzGycasxfouBIsR6i6 bPWp2ijlq5bCgoZMhQFyU5HIKoHWTXZlTTUR7XJFvbp0Z9OqtY6TqFqLZLf4iw0ie3BCrvjpPxLK po7iv/wViTJKqrugaWliq1saJFVTFBCSICQ+j2FzB3rE+zqmrfLoyjCHqiVQGMRZJzUdU031mgJ2 NkXZW6sk0PsSvor6/s0NLPI4Gce8lrBT5tijM15rBFs0u6g/V9n13E1/dWt1HbizhnuI4b2KRx3I IZHWOUowfuGSNRJhGV2zsjR3Kq1Q3PQLnTNPurGW6k1C6gtXmsZIYyiTTpGXUTK0YhSN3ZSZVZFx ukkjjVnXyu4zJ3cfS7sXWBiSacG/la8LQ4SD1gxmzBCTUa4WjpyNet5iFhJdBod4zcTNcePIxNOX qLuNlm7l4QHiyeMYgJREpgEpgEQEBAQEBD3AQHyAh8wHJ/bXMF3Es9tKk0T+HQggEcFWHlWU8MrA MpBBANV9dWlxZTvb3ULwTRnDJIpBwRkMD4ZGBDK6kqykMpIINQxjGd9Y9MYxilMYxilMYxilMYxi lM+hExb2akmUVHoKOHj9wk2bopFE5zqKnAhQAoeR4EeeA8j7ByIgGfPzb99l/wBH0ptvYLG8T8Ws nAxSyLhoq5QUBI5QOAmWKoJQAhzCBUGwiYhxWOdy2MopGrIhrNX1OHSLCe9mI9CkRoTgyStwiD35 PkgcKCTW20TSZ9a1GCxhBAkbdNJgkQwKcySN7DA4XOMsQPetnX2bPQs2pddirXYY8AkZFJu8fOV0 SGOcTF7gbpnEBDtRATJGOQCgInWAOSqhxvhaNUI9sizakKmigQqZClAAAClDtAADjjgADPlVqAY1 yHYw8eimi2ZIJolKkmCRRAhQD2AA9+Pf5/P5jn3Te4/qOee7y8nv7qa7uXLzTOXYnnaDjCL8KoAA A4AAr0Za21vY2sFlaRiK3tkCRqPJ/wATsfd3PqYnkkmoYxjMau6q5R5AB9v74yOUOR+o5MUw88D5 5/0xSquMgI8AI5TOPI8fIMUqpyH1D+eRzj5WIPIefcP784pU2Ujl48/Uf9cq5IcOQ/Qf9MUrjqJk VIZNQpTkMAgYpgAQEB+oDyGY5o9MOtYRy8VoCLrWyMnOGsMjEVJrCJ193IKJMEnqCENLQ8o1rsbM /BJuJqPpylXCSk3cxYjKFs03LzbrI/JiB5D8vfOGAdHjcB45MB43AeN8Z2743DI+3cSpZSVJJXB5 r4aNWKsQQ6Z2OpZJE3FSwSRCrqH2qHCsA6ja4ZcisaUOnSNUcslZV7V1StGqLETQlGZQ7kWbEG33 WybOXUtOg1YMyFckM1+HULy6TGOGM9MQX7rE6Qpcadqqsk7k1myfp9zxUqaCxvw8uHMaxRZxS7kw l5+IBgXtETen2AOXnxmOtnap+G3hUjwRFGuPJ42qAByeBgYwBwABzGghXbHuVTyRvdsn0+ptzEs3 pGGOWByQcsxPxUoSIbABEY9qUCgBf/KJ4AA449uf18j+fI+3JKzaEDgrZAofQqZQ/wBv65yPxdxg EA4Afw8fT8w+WRzvCqBgKAPyAr7yfOTn5zVMiSSf7iZCf/4lAP6B+WTmMJSiICPgOfA5HA+QEPrn OOMDj4/KuKsm41tu/aLK0rQdrq1LXj5ZU8PYW1WLsKGp1TNKFQgJxWDsj2Bi7lsd+2aGsDZtPM1a FWnjs1ef1bZ8VAyymx7sa1gYbSVPs8RSFbHLWK4yYWTaG0rvML2ja23beRJRBS5bOuqyabuyTh0x 7GrcqbOr1tsUsdTK3WIdNCPb23hJm0N+tjpa1hXJJxFw+7WW542+rsyu3KzSC1xQP+oENIOIwfVi lYGTu8bTqFbVnDM8mnBXQ33XJV5+DCwR2TewXEFWXLtgmIqGUIcgHcIgg4NwAlD4lL8JiHDx3EAg CUfIlDxmFrQ1Kx0y3mS7FtZaiZ5XjjCJuaGV7RFZlHcZUEHpWV39TPKfXI7NGQbS51m7he3M11YG 3iSSQtLhZoIrpiu87UJ7/qEaKFULEuUjQLrS2fJSclNvDulFTqGVP++IiYfxDzyHI+frz4H55aRt Gzky4cxlShV7RYCAsiDFFczKKYvQTYHRQsc+DZ42gSCWWjXirZNtJWRWJXVk4StTYNlUBy6kel+Q 3fc4124tdtYVFH0wlKRErxUVAWZynIpPWbiemW8OW9/CkXbotV4eGt8PXrAzM5irPCz8BJycXIbD 9e6K19qOvRkVGRMTHIxLFBmwjI5mzZx8azapFSQj2LJmYkexRQImRFBInakRMO1NMhADKvsukpNR m+8uJe5EXMjqwkSMLuOFklJjkeQkEtHAoTtOhW7WXfGknute+1j+2hjMThVRXUxvKTwSyREPEqcg I8rM5cOrWwUI76z6N0j2qyJKJXoG04jIKSCKkOjE/BV1KLXeu/hWj2MfOZNSYdJxS7RlKvJRwtFS MgyNLRsLWk3XwKN3+o7peokj04bS1zKS7GImb1R56utpZdu5eEh3EvFrtAkPh2bhssoLcqwmKQF0 xOPHChREDFzNvm2oCkR64NQQK5AggmBQKHA/+3kA8BxyA8+4cBx4HzrA2Xs6bvUm4BRwqdFRYwET 7zCUAVW5AvACIeTcCACHHnjkc2NzLpXTJje1C3OpxyCW3OxO1bzAoyyJCq9oNuRDgKFJA3A1iQQX usiVZx2bSVTHcct3J0Kle28hPcdQrMF3OdqkhdoGKtLTtjqW3Tepztq5DU0q2sKJ6tQrbdCPgKm6 JV4pNzWYRkwQYtmcNAOEhiYlBk3bIINGSREUUiFKXOx1qVVK/bmA3IHOmYA47QAncXn8/qb8+PAD 5yxOnWcZGvtra+TcmNK0TYc5Nvmzj00Xa0fuB6+2/FyiDQQIp9x/HXCeqMdIE9Vk9fUqYRScfHMp Royv7VIwHUkX8RSJt1DHXVUH000UScKmOYw8ABSpcGEfYAAefw88RPVRcPrM74bbcXHftgQwLWl1 tubRwjs8i922lhkCuzSLuxJ6w1b/AE4wrpkC+lmhhEFwQQQtzb/uLlcj0nZPHIhKEoSuUYrgn0Kd ARKxJRKZp8EQTFMhDKqgAlATAADwJuePcPHIcccjx7Zj31wdaOmNd7Rd6m1C4aS1gj6lH27Z9njG Cy8ZUKxakyqU+LqM8j3xUttC6wPwVxpU9MNFtNo0hdeSKfcSjqvVRXC9TdE1qrTtm2eu2euKjXJ6 Oo2p6PHM7Gm72xs+XXCJVkrdJt4RSGbU+tqlmoRzWZhnaKbDVlSe2luOMt9TNV9U3LByi0y7bhl3 MvbLLNWoz+aeWK4XSfVMrO3y3SaoqTFomTgAE+IciBGcFCtSI1+k1VrB0WmsImnVuAiGXpvR7u30 rpSxhubSKTUpUD2/cUN2QVUiWTI5Zdw2ocbicHOGqrYdGm1zX7u6FzJDpFu+24ZGIa4YMQIYT4Cv tIMg8ICRyytXS2d03TZZF6jXS/CxBH7w0Q3hHsuRUyS7l2uX4918MnGJFbtAZlYNGkM2FAUTl+8V gEyjruKl03VEN1kJRGQeMjE7DtpBi3eNjE9P0TdxitmzgfwgA/8AqQ88+OB4DPat06CrDJJnFskE ATSBMTFTJ388eTCPHICI88h58iPy5z7y0cycFMRZuioUwcGA6ZB5AQ4H3L8w/wB/rkcAHGBgDwB4 HjjHj2Hzzz55qx1mijVY0hDIuAC5y5xj1FseSR48ADAAHA0yzUKzuZZ4ruHSbKvEFU3yKKLdYybb 90rlsR8zWIj8GuYjorV2i9TbO+Cj8UTybzwdZeiner7IznE4uMaklgWSnE68i+QroviqLpsJuPaP RF5GpTjUAfnjFXksjCyIvK+E9ZFIp1NSXt8NqmngtIukYlsmvIoqJLmKQPJTgPsHkAH5+A8D5D89 RXVPoanu361TuZGrSo2B1+zrmTfByhFo2ZUsbHSKaypiIIKMrMpBuVlFDFUKCTgiZ0xeuwdSnpXX H0jUI0kYmzunWOdc/h3elZQPfYSCwAyQMA+xi/WOiQdQabNLCgTULKIzQO2B3I0G6SFjkAEqGKsc jg7hjDL5FsZdjeOorLonalx1XbUQRmapJi1MPcny7j3KSb6Hk/RIc6jZOXiXLKVbIOATW+EeN1RI KSqRz2ny9wQwDKQQQCCOQQRkEH3BHIrzsQVJVgQykggjBBBwQR7EHgimMYzmuKYxjFKYxjFKYxl7 tVdO23dxTcXD0+mzSqMoKR0pl6wcsocGqhBVK5TfOU00XhDJgAplaGWEwqJGOKaJxWL8SSRxI0kr rHGilnd2CqqgZJLHAAAr7jjkmdYokaSR2CoiKWZmJwAqgEkk8ACvh6aoLrZWwq9VW6Czgjx6mZyR u3FyoDYhgMsb0CqoqLlTTKZUzdI5l1ypmQapKuVUkj+53pF0hF6Y1VX4dCPatH6jFqq9TQ/xCkOV MoFIRUyaQqlIACHrg1ai6XBd4Zm1cuXAZpo6CehqBo1/Yu5pNKam4Jyg4lnTpl3tUnjVT1Uwbrqq CimDF2kV2UPhiukVGsdKtHZWTlMXHo6j2otWqLcDGH0ykKHd2jwBQAoEKJUUA7Q44D8HPzHwPGUl 1hr0WsXkcNo7tZ2oIVsFVlkJG6QDyQQNq5AO0E8Zq+OkOnZ9BsZHvERL6+2PIgIZ4YVGUhZgOGyd zhWKknBGUBP1uAD2DjKR/f8Ah/3yrlE37w/38sh9S2pcmAvICPH04/3/ANMlyPIh7CIYpUMB4EMm EQEPbz8x/wCPqPz/AOfHx5uYZwMa6k3ypUkGqRlDGMIAA9pRHgBH5jwIB9RxXIGSAPc4/rXXrtf4 SkMSO5dwVMVDCCRCgAqGAoCPBSeTCIj2o+OOPWARH3ywFT6lkLbsNhTWEO+WI/Ovy4bNnThJgmm0 cPAXk126R0Y9FQiSZSqvTpJCq5ZNwP8AEv49N5jjLup7qMv7tnCvH7OEQdmizyzEySoxTBgp/wCK KMUHDYSBKOlirR4CgD0rRRGPeKJqfD/BDnPq3TtJ1PBMYerQpGYNGyLcXDly8kpZchTd5lpKZlHs jLzMksooZ3Ky0rJSMnKSB1Xbp0sqoQcDaRklt2RhRgYBB9TMfg4IXawYbwWQhc97qIQqlAzNHuLs 2Qrb1wiovklN5Z2ZQhMe1JQzhLuB5AB+oBlUgh7fPnnKeMVj1XEQD3HIAYo/PKOMUqt2F+n9f7/l kQAA8BkgH8eef1yIHAfqGKVPjGMUqmcPHPz+f/OUhAB45D29vyzk5J2B+f8Af9/nilSFDkQD5fPK nYX6f1/v+eRAAL/zkcUqyOyJm5UnZvSlsilNKu4VhOrDROv74exEaA5Lq7et/hdNzBK6uu1WMSdY 3u36ytiKBF2YLJVZVQyxzIJt1r47yqFgQvkmq7I59E79VcwLFEPTKZQTfiAwAIj4EfIciPPsAZaL eVYnLhqHY8HU2sa7urqozTqhozS7htDhsKKYqS+v3EssiYiycazubGEePBTHkEW5uAEwCGbi+qGt 0S86+qu6NZvmVkpOyapXr5SrPHgBo+w1C3Qzex1yaaHDz6D6ElW7hM5uwygHA3an3dhfvV9JfWOm WkViG0m8lZ1Xy0NwsckZPqzkSLOAcDIwBnBAi1xdLpvUaErldVtIgGOBia2ZopAOFH/aNv8AxM2c 5ABUHWRG7bjteIQMcggsq7fPVmRToEKIEWCJl5ADOzCQxSJcx4kKIgA/eh44A4ARKP1bHuF2oxXe KrG5EpjeTeQEQER45AAEPkI+BAQAe4PfMdLVAqyIPCJqARw3WbO2oHUUKkD2MdISDAHPYXuFsLxs 3B6UvAqMgOUwcG4zosnILTzBi2ifWM2XSL6RTi5KuBTAAFByR32vCugA3a9K9D4wHgHBYAU7gCp5 tXvIYDEGZUjBjiRff2zgc5I8g/GcfElisIJJ9zBWZ8OzE8hRtJGDxtzg7s49WCBtBbr1ytsrb5VR JNRVUh1hAhQERDgw8+OPmA8ccgPHuH1Dudb1mo0inMxJFKQUmqzhIFD+mImKiJgEBEPryAj7AIh7 chna4CiRFHhBt9wcJNEu0QbJKlFdd067RMVs0ZNu98+d/hEPh2ZFFBADdocFHjW1sTrI3tvyUcU3 py1o8qWp5xR7AF6lbhJQabWISZigWXstK1osmq8u0csyFWPpM4pIOoSas6wOJFp+ycTIHkcTT9En uO9f30lvCsYWSWa/uobS2t0fcVaSSd1MsjLHI8NnapcX10IpFtLaeRdld95qsNu0NnbLLIz5SOG1 hkuJ5mQorBFjVhHGHkjSS5uHhtYmkTvTxqwI7OWbgnnVL1KLVJcsitE680DU7Gim1kGgIW6Mcbms wRhn7lghEPFE6ncaiqB4947csEn6ZJlNuY7X1M3em/XE1Z5xk8uVRcSdcaQUndbWzby0QNcRJU28 U6fVH7zk0ir2V1ZnjpFCDZP6hDxZ4GJtctOTcPLlrjF5rv6fIO40Ta1P6dZuMbTFWtULZpTW+zEJ CWdWK7XCMmJG3X5LZwTz9x3bFn2lkJZDOIiQki213CX68AjXop2epUzcHNQVt1D017M2ZYIKcoDx 5r2FczMBIvJSSmIqEZRqko4rkmhre2T8SnLpyE/O1+wzFRcnE5SAdhYpxrCVqdTkelaYL3qSDUHg +60lINMFncBxJ93b29pFYRzKkbIYDLJaPJJaOkk+nzJ9hcSTMkkk2kvb37fRprRZjBfLNfm7t9hi FrPLK19JCzMjC42R3UaC4RhDdxsbyBIiyJFZvr5kDOr1q7WzdWKVYU+OkEgbR4vhUZ3B1LSURsid ct3SQfdVhmdok2vDzaDBU0K4q8TSCtDdqIFLdeg1xpWazGR7VMpe1skY5gKAGMcSgJhNwAeRERH9 PnmL3U84fk6gqjWZP01D0TX2qqM0dGeg9ev46ErqCyS0gf7qiAFcXki/EwlbFKoI+qJEjKHTJmFH GH4FmPP/APTpD+XkgfLLI1C6ju764kiG2IMEiUeFjREVVA9gOePGSfnAzdJgNtounRkYkaNpZj7v K7ElmPuce5zxjBwBX08pnMPPAePqP9/3/vOA8gA/XKRw8j+ftmJWXXz15Vk1WTQXdJJLKiAJpnUK BjiPgOCiYBH+Xn9Mxj6r6aysGtZqTKmQr5mxcHRXKUDH7kkhXTDu5A3HrJh7j7+3kPHRd4yb9ps6 vAkuuRNM7cU0yKHIQ/cqAGAQKPA8+3AgP5e+Xr3ib1dPywnHwpFnA4iPyFAAEfIDz7j8uRAf45wM nz78/GMY4/n78/lz5rLSMxvbuDkyEEgY4BxxknnOefb49q8rP2qVflJRbU2xEYMQj04NvCWm0i6Z /wDiNhm0XqFTZfDqOvvFyKdU147J8Qg1VZskGTZJ64brvmKbrT9m1L7SuSkE5umxCpPSZvKFq6TV OUolB5IR77dDQSHNwAH+7EJL/DKPBkglVB44WzVbnoTpl3fQdMMjFm+1jAY5yVA9IJJJO1cLnPt4 HivN/VyJH1JrCxqFX72U7VACgk5JAAA5PJ/Mk0xjGb2o5TGMYpV5tE6wV2zfm1dBuq6aMmJ5iQj2 jtqxfyqCL2PjGkNGupFw0jkJKdmJSMiGisjJRTBJd+Cq8g1ImAj6Y9EdO3TDqeKp6KvSjQtmXmJK U6tqk32z0HRJBeyuLiYkUtCXeKURaV+WWbR1Xss0tIXKFr0HXmStpWkSruZPV39l1BEeu5FA8Sog afukeDydEVjJqxUHWZ5y0bqpqGO3bt2b9zIGBwySSeu1Hp2rtVdkQhEPW3R6HBVqIZpEjm/xYoI+ quZIgqAXtAUkxOYO7xzyPI8fEisJfwjwNS9X9SalBqklhZXElpFbBNzRMA8zsiuS5wdqqWKqoIzj cedu25ui+mNHk0eLU9Rto7+e8aQRxTI3bt0jkK5QnG9nAUlhwp3IpPqNYcbKsF9r061slZrAQVOd RrRuagOpaw2iqNCAogs4eFlLW/mb4WRMii5YkM5t0hXwPMyMk5qkmaMr7GL+grtSpPdUWOei64wq N8XanZLxy7RmMig5fC4axT1ME3AoScbIuElfu162dGaPVEHUYY6cpHSLFjnJKw8ZLs1GL9oku1OU SmTOQogJePIeQ8ePH14+fyzXRtNszntmw9GrrAqEdDekmodApSgZy7OUQa8J/wCN2IIJC6et3HYT lePOQXRu74aBz313clzcTyys+CSX2hm3BiXUDD55GDg8rhsKVNhWdhYxmFba2htxD+IKhI7SrhQj Ft0TBgpLKSrDeGQuySR3V6T9fpQcO+njMitnsq6FZd2iVQqzhwH4ROu4WAHDpuUABq1+L+JMDRNs XntbFEM2SFHnkfH0D+/7/wB+s1KJRgYJhGpIlSBBBIvAgACJgKHIiHAeRH/5HOzep+X+v/GYg+fn B/yAH+QrslYPI7AYBY8fz8/qfJx7k/rVTJTFA35D9ciAgIchkBMUPnnNddcc4en+Pt7hN2l5KX8X 6D7+A9/f8smyvyBgH5h88pGAAHgA44xSpcwx6mb4sBWlNiRMd08URTUIkftE6jk4IoJDwPzMYB45 +Q8eQAQyttU4hXYGRlnBwIRq3UOURHjk4FHtAB+vdx/HwPgcwB1nHL7Z2e8npA7hZpEunZlgEFkU iGBuiuJiLHKUTlbt3rdARbGMHdJh2D8XGmBrwf64I+DycYP5ef8AP9Ky7ZVUmZ8bU8Z928jGfPHP 5Y/WspNF68jaBTY1NNsQq7pJAwODqisssB0yj66q5zCZddyt3ri4E7h07Mt6hzGOY3F+8+THNjpH XcrmP6q5U000TG/A0ZoAIN2yZSiVuVbkVnLw3ac5nS4piqdo0YlT+z2APkDeP6f3/DOf5k+/PnJ5 I/l4rFLs5LMMEk8fkCQMfAIwccYzj2qQA59sZVKTtHu5EfHt44/v+Pv55yAk5HxwH5f9sVxVPGT9 g/UA/v8Av647DflilSYwIceMYpUeR+o/zxyP1H+Y5DGKVHkfqP8AP6ZEDiHPz/X+/wDTJc46zlBA UwWVIkKqpESAcwcnVVH8KRefcTfLj5fpilcgR58jkxREBAPkI/2OS5EOOQ59ufOKVykznSORRMwl OmcpyGAeBKcggYpgH5CAgAgP1DMxOhnYkLun7Ohrrxs1XZSPRvsrafRgrGu0nBUWlT0dNINtLtWz o7hc8+CXTXZNMFeSKhCmXtp7GmskCyZjZhuAgPkM7x9nxqiR15urrvszE8IyrW469qLaciVvVnKU xYJf7hldWMIwbGSzLIKpa9eaytllXSLUUjmPvsCi7Ociiqsl0CRXt9csnGUuNNMwB/CZLaVFXI/x bbhyp48Ee4qG9XwsDot6gG631HsE/wAQS5jLHBz+HdbIGHJOQRwDmzVuZFY2CRbAXtD11ChyP1Pz 788AIF88cfLnwOYXb125WelilzVtZ1kJublJtQNd0SPaPkVdhbJtTh3LnptcQrMBYZZzarLJklrA odxBLFfSTyTkH8q2aEmJCJvxt+5LDu62UuQagwioeFYzzl3KC9bR0rGyrhVhGsa+UWxoaxKlmIqx ftm4WkEXtYYNqgwcV1Vvd200njvLXSHm126FVXZyLNJV+0aGg1SOodo4hnIQkgyKuyA0VHuY92ks yWjgMm6RXQkUkWh1W8gBKDu7iHTbwPdWkl3bx3UU0lqkpg70YLOiNKqSmEyRq+1u2ZBEXePbkPUu t45L23K29yltM0TxLcPGJDG/7tGZYmZO6A7rgb9hk7e4ODtOKNaoO8t6MUNj9cstGyMiuiseF6cI IOzV9OURfTDcsvbEm1ns0VcXj6DcNmEZV1Ha1UgIU66s00sVxnJ6WTySgIN3ZJlOLjkV3z4xSrFj 2KfrORKoYpW5DiPa3aA7OApNBkFWiCxwOHqplQVEvc2lKmZUqa7xRcUDFHhs3BRAg9yhDkUUX/8A OMqkBCdqiBm4AIm5AR4EM3dEViv0JNKel27cpm/CyCJikTKJg4EO4TFEePHI93HPuHcIhmFdTX3V uqRTagY7SzQkw2lshgsNPgdlZorWAsyopCqGZmeeYhZLiaaXc5yLeC16fspI7INNcOVE1zMRNeXk oBw80w273DOduVEUYJWOJEIFdI3t0sw2otB6A6obs/lIYOn/AK3+jbY0gmzVQbtZGtWXctX07dou U7uxc8J+x+1J2WTBNbk07HxwyQmrP3ikvtP6oqOx3hTN36RjHCEKjsOlXCgtZWKOQsgxjLlQf2SN KkECiKSyEqMqZEwgPIRqZhIJR8YKdat7X6n+jPqS0DEwy8svatR3MlViY11IRqi11hY9e1UXuUiR TVOCN8iIJ0q3J+CY9AG7giiZhKa7dJ6mnum+lrpl3lvaj3K0763HqmlmiOm2swAH3XsTdTjW8ZeZ at12oPCkdQ561KxkyjeFl4FJpQo2R/a68nqMZVZAyXoTp+2s7zSNN0zp0BhaXRSeYhe4pxFMjqeT saUXB5XYGHBJY4qnVpZ4NRvbzVzg3FujxoCQpG54ireMMEMYGDnBOcYGdL28dw1yy7D6f9iSUh8E 73JpzUFjh4d6Y61ulLA4hlFLbEhAswknklJ1B2CjeyqRrmYRhmrN7IyjlrDxwyZ9i8OqLiKjljJq ImOzbHFNTsBQnKYf4SgJiYA4+YAIh/IQzXT1OaV2hpZOo33ZMpV7tcKnLt6daV6tKtpxhqWhRz6R jIjT1cIo0qJq5UqXrEdJ73k7dbU5DYOzTWjZUndDWO3fcbw2a+pb7EXCuMAbrk+Oat00XCJjABwU IUCj4EfPIhwA8cj4+Yhzja5pP7I1CW3AYKzPJknKnuMXUICA2EQqpZmbcwYgrgos56d1P9q6LZzF kZoY0hKquHQooRjKQ23Mjq7KoRCqBQ3c4la7RQ4AMiIAPgcoAoQTmJ+Lkoj+8UQ9vS8p/lwqXzzy A+PYMoyUg2jGbh66VKkigkdQ5zDwAAUoj75qK3QBJwOSawS6jQIGxa0UhCmOd0zR7AEvPpqvCAsI e5vDf1V/Ah/5Y+Q4y5nUrMoRukHbFRf0Hc7HowrAxDkSWB3KE+CRMXuAwdzb1xcc8cB6IiPz5sYs +X2vu5umgcx4yKOd+4WIoACiigf0mvrpgYOG7swPDAJvBhZl7R8G7bB/aDdR9eqEAaOQk0yFr6a4 tD9iL1A0mxQcLLHUaguK6gxqLZ4uUCAdB4Zm/hgJ8eZkUO23gluZYoIELyysqIqjJLEgDgA8e5IB AAJrKupobSBJ7mRY4bWFpp3ZtuAApC7iRhnPpXkEsQAQSK0MfaJWlvNW+HYJunTgEZCVUj0HLZZk MZExTdlWhjkUHEXHuVGRpmJmJiPeLuZptJJTKkxAy60DKsGjLW5nftlXuQ2La31iemUI3MVFhDsj 8B93wrAooRrQAKJy9yaPJlODqAVU6hUz+kCZS9Bz0XpVn+z9Os7MnJt4ERjxy2Mt4wCdxOSANxyc DOK8vaxfftLVL6/xtF1cyzBckhVZiQATztAxtB8DA9qYxjNhWtpjGMUr0L9DEJGQmsdB2iLGNcos bE6sMu7aulHRwmSx72BJELfdbwWpHxE7g+fum8qdyLL7mUbqRKb5IHUT6c6zLNpqDjpBqqVRNdsk buIYDcD2ByH6gPy+WeIDou6rEtTLK6+t7k6NNlwcC3cnQK9bMHKKcvIJAZE6wrx7lV9ILkQeMGcm WSI7Xg30M4M9ZzUBvS6ZvtB6fLnRqMbaId9MIGMROHXkWKa8oRJs0UcPolqk7dOPQAzkxDt1U0nj RRs4ExDx4ov3dI9W6PqcWq3l20Ms9rIzTxzojMkcTuzGNyAQpiZjkeNpVjgZC330bq+lXWi2Nik8 FtfwlYJLaSRUaeRY4o1ljBILd1UXGRkyB0HlN28MQ5AQH5gID/TLaMtW1NlaHVtQj0iyzxQF11uw C+ov2+n6xiiHk4lTSDuD8Xj3H52jjuqOtLJk+8WDluoJOTdgAYojxzzyAeQ4Afb6eR9gzmH6nqWV 20bFKqmDpdNAqivYmAmOYCAP4hD5j5D5cfLnIZ/I/wBf0/P+v6e+amohuFztUgMMEjwRwcZ+Pf4/ nxWTeM4jJ2m+aN3aQ8puEyqEH6lMXuD9PGczjxznI5APzWORjigDwA8fPjz9MhjGKVEBEPIZD9cj wIe/j8vn/f8Af1z4Nlmm1fhX8q6OCaTVuopyI8cmKURKAfnz8vnwIYPFcgFiAPJOB/OsTeqDYSTS PTrDVYgqrmSByUVUkwOdwoRBs2FZT/BKZ05VRbk58AcwAIiHABcvp1pCtTo7dy/TOWSmR+KUFUVf VBsZVY7buTMQoofEFVPIGbfi+CM9MxKYzVm1EMTKNE/9cduOln6LeSrkS5PITQuG6D9sob1RSbRI lVM8aGUMQq6Ug1dseTMnQHYvWr1oPGzNBJMiKaSYCUpEy9oCQ5A7QAAAPIBwABwHHkf148cYAHyc 5PuPAxz/AF4xxgePFZMzFFEABAAVnJxlnPJ484QBQDwGyeDtBqpjAhx4HJSB45ATCA+eTe/n+AcB nNYtTgIgP9Q+uV8oAAiPAZVN4KPH6f3/AExSoCcA+o5EDAPPHv8AQf7HKORD3D9QxSoYyY3HI8ZL ilREOOPHHgB/X88hkwiAgH1Dx+XH9/T8/wAslxSmYQ7ku8+jt2mwUa9Wbs2Z3UgskkcyZFHBhbsE irlExe4hmsjIgDdcBKJ/xgAmbdwZwGLxx555/vkPy/v9NNPWDuK0a+uG29g1CmLWpvqN/A1GRMdR wZNvbm2vkdwPyTLNskm4YVA1RuFFi0LQ0fyTwtosDoJKuMK9Arz7vvt7aa6kEUKhnO0eplUAPLHC MlmGcvKi4GT6vBGa+Xu7aySSe6z2kilYARtIzNFE85CqAfX24ZGXdgZX8QOK3GMTnOxanU8qHRTM YePcTEAff6+fr/pnIEePI5bTTuyqhuPWNM2ZQ5VCZqlvhmsnFP0TlE4doqNn0e+SKInZS8PJIvYe diHJU3sJNMJGOfooPGiyKf0Nj36raupVn2FeJprW6jT4d7O2CYegsZFlHs0jqLHKg2QcO3ztTgqE dGxqDmTlZBVvGsGzh4uiip8CGXvC37cnf7nZ7RQ9zu7tnbKAZ7m/07AM7uAM1896Hs/ciWP7ft94 TbgI+yV3iXcTjZs9W4nAXkmudbLtWaNCyNlt9iharXYdsZ3LT1hlWMJDxTVMAFR1JSkishHs0CAP J1nKyaRPmb552/o36ntXbA6iaZXtWb21Js5C56t3frGza9qO2qnMWWIeMw1fuTXd7aVaKduzzNdS YRG24BxMFcprx83aIZJm2esHVlfV7TNB9TJtqTsFuKf0ZHbhXebdaUjpS1zY7fDNtSQ07Evo55I7 Rmbo3q9zjLHt1lDs7rbELtrOG2zr3WVU1vYqTQdkNLtM3cbzsIuG++nLT3V30ebvmLLQKq4idkwu vNrJKyRafMwVFndZ771tTbkxnFnjeFR1xWrBteYlN2wRGvrSNZplE2JLPm9Q6eXAZaWh9IG3tpLq eY/cy21zA0KEFFMiBdhODuZWGS6sF3DA3KN71F1D1gL6RbO3hUWsdzbzJM4cSN2pN3cXldqup9IZ GYoSTtZtqXo6otXRlhl5BpYa5FTzb1XpBbTEW2lGhSvG6rF4Q6T9odMSuI9ws2cFOn/mEVlkFu5I wlHpOnOnqSu9gbIC2MVsRQO4fSEqSaQCXkTD28ABQ59ueA5ERAOOdnG/qhGuJozpgkmq1cG7kQAO QMA8+OR5H8A9wD5DkPn4DMgek/WTVJFWRFgQpiJ9xR9MOQEO0eS8gIAAAUBH3HgeQ58cUO3RT33U n2tyJOwk8j7GDbcFgWKj8PrAGSMEkDPgVPF6jS10f7iDt914o1LjbvbChUDEDJ25O3OQMnBHNYEb N1jXNVxrduuil66SICPJQKHcAFHkee7kQNyAcG5Hjnx8sO5qzPp94EZGCYqInBMpEh5DgBAA444D jkQH35444H3DM9+tlm6XsrpqUxgIQxw4DkADyPHHAcAPA/IPIBzyIgHGAFdk04SdPWqjX1Nh7TWY tH8TTG7o0TEtCv5qHg2cpsC6KRkrCUCARWlVJpY0ki+t9irNduK2raPsmzVtaqLdrdH6jrGtyabp 1sbayikWOSULgbAQMlvb3yTx8/Fda9QWen6al5eTCW5dC6Rk5O5sEAAn88Yrv1sl7LofVbSRo9UU 2Bvnac5F680fQU448seQuM8p3SdtmmR1Y6CQqOrKwhNbGtT+12mj1h83rqNOWvFYmLXXl1bgayoJ de9992K5hrhtJ7QhoirxyJr3OwMfNGaO9lRtq3Nb2g3LcluuNjhYeHtNjMlRdYJUnXeqaTrvRuqq 3S1E7J9vpo0FbrDfbp1YXGxO7Y7k6HGaX1xNHjZCu1p9UYKWUmNobF15VHwS7ija02xfoiBLrqCL ZrsztNL1RTtsNdqXFDZyarXqOx5ZCGfOopiBG6JHj1cUkjfh+IfvVnz0Q4AAAVHjpQ4+3kR/QvpX pXpex6Y06K0tlDSkAzTMPU7YHHPgDBx4OSc+cCm9d1q51q8a4mOIwSIogfSq584/xHgE+OBj3J+H dJJrcpCRYWqS74GbZx8bISrtu2ct4tzHryCURNPPUULwUSSTuBtxzc/ecO7ZFFaKhmFh51Z3qv7P 6QtyR9DQZSU1FvBl7O5kJKTZtT0qgLfEmrqroyiSTu5V2asBjVbXFqSjmCEpDwczGXadJsimWRjM ZZ7ythq5qewA1lLOwttvkIGka8JRyRj66ONgWmaYx1XGuV+Zk2URaBgXIhaLLWJhctVlqhB2IbkX 9iyWQS5kuomqf9JrNBXprCS2wNiQjYj98RT9qkdOuG1NrlRg6HpC1z8A1fQWrtfKwCsuxgpCqIMb jc5m0Xqx1WAkrjZmzmb2P0n1z6pmaw6fs1m1G0haWOaRGES7kcJHLKg3qrOA6BSfWis0csYaNunS utU6NnS5upHNjM6LcQIy73RZI2cxpJmMsyBo2LLkI7mNo5dki456q3ZD31imR8U0VMpgVNy0V9Q5 AOIByYiqICgBRFT/ANR3AUf4fhs51Qbtg6/EL1tjLM15ASszSDNtJxRXTdORXMgyI5+JeJNWYP1D +ki5fu2TE5uSneNg7hLjjtzW0zqGypvImMhJuElykVUlyxzaHS+LMUCGMaPUCXFciJhWKR4qq0E4 B/l2JAMADbyJ17tHcCUhE1uJkpD70j3ka3WrsQT4qNBZv8KqDZ26I/YgdL4hUURNDpJFP29yaDge 0fPmr9E9S6Dr950xq2j39vrun3JtrzTUgee4R0KklFt+6Z43Q745IN8cqMjxuysM3jY9X6HqFlHq 1lf2kdnNFvt3uZQh7zI4SKRXKCEpLsLdxmJAZQgyrjttj3fVtD6olZwPX/aKXbPTO367GQi1UiIr LMypwiL6OaykiyRIiZaMspWZomYbqIy0K4lGiyaSHl16kt9WHclvfOpJ8d2xTWepsy+m2T+GZruU nSbFuKRDCRt6zVks5FU7h6+FkwM+kHqrVFwXKDqy2HYKlUJPS1xTk4q/02+WGtS8G5UA5ooGxmsq 4hG6xji9SrtXJLI1eFbPXDqVYMYtpBPBTUj11U9YoiJhExhExjCImMIiIiIjyIiI+RER8iI+RHJ1 0n00umtNfXMbfcGSSO2EqgPHArFVkxyVeVeSMjAO3HtVd9ZdWPq6W9lbSj7fsxTXpjLgSXTqrvA2 Qu6O1YbEyDkqX/iqGMYydVXtMYxilMYxilM5zOSeMVElEFEzlROY5G7xs2kGImMUSmFWPfouWK/I Dzwu3UADAU4ABylMHBxjz5p48VvX6Ft8a02NHIUG11acc3FlHybkWpbdfk6MgjHK10WTNhWwsp6i 1Slo5FySLrTKGI2j4yt2RBNuxbrnLZ/RHprVGtnNejrKwqsXHPHKaB1StUEU+FEA4S9QUgD1RIPa BRHkePA+fbwtaY2e905sms7Ei2DCQe15Vx2IuyODlOhItHMdJFR7XbZFJ65inr2MRdOCOWrEXPx5 WTh02RUD1n9JvWlX56kMnceqSRauEk1VooVkyycWqdMDrJOW3ILEOAG7gHgO4BKIfXKa640aSzvU voEc2Vwo3HcWWG43NvQAltiMuxkACqWLKANuTef0/wBZS/02XT5JYxqdvKWUYVJLizEcYjbdhe48 bCRXHqYLtYn18bdkEEWqKaCBCJIpEAiaZCgQhCh4ACgAAAB8gAPH6iOcgocjx+X9/r+n0zFEeqat iUBTjHZjCHIlEA8D48cgP5+fz/16fNdUr91/l6xBHWciAkKY4mMQqglEQAxylEQEP5mFQAEB5yBj 9CP6f+/+YqfC1nb+H+ZOP9azcEQAeBEP55KY4JlE4jwBQ5EQ+mYJUy87gttqbmTIcY1u+BOT7S/5 RmJEkDmZDwPJHPouG7kGwlE/pnKcwgBm4jmy7ekYs0VXCiZBFVkkfvEBDhZ0gisPkQAfChh/QOeP AiHP68e/Px/z9a6pI+2QNyuTkeg7gCDtIOPcMCCPYjFfW55/pmF/VVsRKGhiQbd0UonBRV4UyopF BIDAHCpvwkIgAfiUXMHa2bAdyY3YBhy99/2/WqkwclTfoOpMUjgg3RUKce8S/h7uB8Bz/T3zA6gw MxvrbibuVVSWh4NJlaZRqsRdwAwUk6lWdfMkYrpikgvZZWFkgj1gRmI5Ss1+ebP00VLK1Ua8qpbJ wdqAs5w3ABABOAcbmYIpYYLso8kV2RgQgSyenLBIQfLysMrhcgsqqGkfaQRGjt4UkZd9LWq09ca9 Bd2gglP2ySk7VNnRbOWZTuplyLpEizR3JyvwrxJl8ISUSZvCx7iWLIPEkEAcmTLk/lBs3TaoJN0i gVNFMqZQD2AClAof6B/xlfDMzEsxyxOScAf0A4AHgAcAYArGCqoCoAqqMKB7D/2TksfJYknkmqSh gAohz2ib8JTFL3j+vHnn5+/zyp+E30Hx/Hj+oZQMIiIeAH/TgPy/LADx5DOK5rkcAHsABkDccDz7 f37YAeQAfqGUz+/8MUqTGMYpTGMYpTGMYpTLI3LTkZLt5c9TeM6bNWvY1TvlynFYZGxL2BaHCnQM skKEw5OgzlpKj0qIqcRJFIoxiAaRr77nlRaKNHV7sZ9pI8bbkIHjIZVdHCsrhZI3DJIm9FYo6shK jKnFdckSSrtcH+LayO8ciFlKMY5Y2SSNirMu6N1baxGcE11CmVCHoldZ1yCbkQZN3EpJOFQaRzNa Rm7DKPrDZp+Qbw7NhFjMWKyycrPzizBjHtHUpKPHJUUxU7c+dsSg0bY0D9w7BptWvMG2fM5ZKHuE BFWOITk48THZSQR0y2dMSu2hllTIORS9VATGMmYDe1wMsbv+iWbZOvnNTrT+tkavJOKc22s21tOB X9k02OVUezOrZOerr5CUqcJsIUGtatthbw9yKnTHthhxp0spMkM277Ul7yBnnMG+dC9x6sx7nG+Q CPacgEnAKgngsq5Ix7tRHYzJFbicRwMsdsCoEgRcJHl8qF4AJIYgDhWbCnDaG16G7rmS5yCUU715 Y6upbKhWSoOUCH6eL7K/esJMyUfHy8Uum46udtVOxXuXeLL2GoW3QmqIGibDokVO7JtoqZixerNb 22huNU3XWlQtWsmjNgKFClqzHO6silDGKMOjEQpGxm7BePMmkkwLGIomalVTSQBIrkCGxgtXUh1J 2O4bDY3p9V9VylgvEyARFN6Yt6blPGUWFYIVKnv9f7cSsbbU1ddSNYqjS9REHO1LY7eFt1vfHs9W YS76X12j3LSewupmZ3tWNV6nZT+07GZha5i5Urf7zT+vaUlrOKQcR0FshpsfQdRv11p03ar27hYm hxV012ujbKbU9wpnqDez11Kxw3oWyntFgt7eGYOBEgjJLNvAVeRIQFkyCDuUkNnd/EM+c72G7ae4 nniKsZWMgAC7GZjwyAs0WPAV+Vxt52nGXGvdOS+izRlH1NsjaKelSNYaJret7VdxvyGrm8LFIwUT HU+17Pru1LW112SJj4qKYVU710yqhWyf3cRnXVJNCG2La5b7irMQo4iupLazZko3Efg5JTpk9MBA oCbmNY9H7x2oQweCcW4hw8ciIeRxbrMHt1h+y8FuXVNP1bKWqcsFUo4UHbhthQM0/qkPIS4xJz2j Xuk7Cyn52DhbNZK9H1qn2lqSpV9w+stmgH5iV4l2LHLrUaBWF8ssIooCY6ZSidwqbgfYrUQHkPHk pRKPj5cmz7/Z1m1x912IjMw5kMaFjxjO7GRkeT5bnJNdP3dwsXY7j9sE+je20HI/hBxwRwPAzxjn OIvUnrKxXmWkF711R9Q1vi3xlfi6vGSGqtVxRzCPcQ8fZ9Maqou22Tcoh3JentAwmKUUnB1UDHQz 4+gYSo0L4CowkMi0qybh6KkSdZ3IJvVJaSfS027lVZR1ILzMtYJiTk5myzE0s9fWWafyMhYXLx29 cLqW627t6Jh42VtVnlwjq8wKgdV2RF3IOFnMk7SYRMZFMI1J5LTs3PSsgwh63XoNo9nrBOyMZAwL GTkpJm0WtbV6ht7cpkpaWVsOuKC6LAptaDAXlelW+XjZIUVLHIXvbWuizVggbFWXJVSQlG0dbIFF dxDC2s25p6Nu0pWdd7fSNBn1C6W20yyaSaVslYY+Mnje2xfxEfxYLN4G4gCsW5vdkYa4mOxRgF2J OBj0jcfHjjgD8s87z989VGrtTac++L7e6RryvLKoRSdhu1lhapCHkF0hAjFaXnHLRv8AeJxZPBRJ 6/ecnghTKAJiazZKAm7vLhJMUzPWkgZN22ctxFwgu3eH5bOEHIAJFCKEEDEMURKPICUQDgR7B0+a R0LUdxQu1tg6OhaFu2S182oS+wKercr/AENetQ0s6Eq0hdzQUA3Y25GKdxn39d9p1qu2ieQlDVWq 2q1tGliIS5uyulaqHq0prPXG1drUPp6k38oSxa5aRLKhFh4GyppvpzXOu7e6g2+3WtTiXccA1Oow 7+lVKpxF+kYWOu9s1LQ4zpySmcX056plvoLGPTZpbiaRUEKhkkVnCsiyrKsbQBldXZpVUJGyyHKs pOsbV7FYmlMyhVBPJBBx52lSQ3OQMHlht4OcYFa4YstsXUm9WkxFTuqNbuLNUtESEDMxdgr9+s5y JVzZe5272LdyEeohXnbef03rpVAsdItWxdzy53E7Vdk1hSHyCimD+0y6SQif0jKFL7iYChzxz3j2 /wDtECh7CUocF7SiAB921HrkelC0+nREdWqdU4iLrFZr0S3SZRMDXIFkhEwkPGMkClbtI6LjWjZg zboplSRbNm6BAKmiQAxIr/Uxd21nctGNGqDSoMtlzWs5F6rdH5r2zcxYyJG005rAVZJi3byoNo2R ZMjzJlVIaTQkSODJmIVT9CuhdB6e+i/TGi2V8zjqDqNwjXMOnXd2puSLcTySG1gmMFnad+BA87Bk h27nlZZGqptWvLjXryeZSos7Tko0saegAlQA7L3Hfax2oCSxIABKitmNv6f9Z2qgJRttFFwukXvS AipQWTOUBMId3IiIiYP3R/EPIByIhyGEWvtyaJ1/eonXNGsBY94W0zFWRcPYOfi4l/Pw7p5HycJH WR6wjoKRlk5ZmZqVmzknDhU6Tn4chwKdRPrOv9vXcmzZvXFtsi0u0szqTuWtXbztI8GF9ZqNkqy6 hVDlcqVaTkUFY1QUmpjwMqxZpJuDxD11lkY3UW09u0zdWvTWyuUaH1/tLbjhGNhmCkjsuQuFlt8z f6LLvpOUakZ1OGQQmoiWiTwjSSkZftQcJTcaLRdjkN6hhfRdbg6j0vp3TtT661W717Q9Sh1DR4p9 bW50F7SaTQhfJqthFpsd/ppm1K01R31H7jSTZXVnp18t3DDJnW0xubX7OW6mh023Fvcx9q4ZbfZc Bl+57Yglad45QkTwgR7Je5G8kZRivnj+2roErQ+vbdJhZs2td2CerbergNTcuHAXyFSLa5B4Uhw4 dur6wtSBynBXvaJtDgJROJSaiM9IH2zFFkNjj0hdQsiSUiZXY2ib5qi3QsrFkYpwFp1aVW+w4rPX BGj48vZTW2wRxkVyC3SbVFIECEUlFSm834hwIh48Dx4EBDx9BDkBD8wEQH5Z4X66sobDq7XYrZGj tJ706lYowCsun6xFHq1gCqk7SLO9g9BO5fwuA4YCztLlabT7R2IZxEIpCDnMkBMEhz7/ALyNuRkE 8qSCDTGMZE62FMYxilMYxilMYxilMyD0b1AWPTkuCqAGk4Vx6abuJXFFVqciYnMip8O4AiQuGx1F RaK/EN00finRnJHhTJJpY+YzoubaC7he3uYkmhkGHjcZU+4/Qg8gjBB5BrItbq4sriO6tJnguIW3 RyxttZTjB59wQSCDkEEggg1u6pX2i+mXz6PZTkVcKiLtNUstNz7N1bIBIiLVZcEV2sXYX0woV4qk mzbdlflGxXThE7to3Zg5doXo/wDv41I7koVeo7eh26cRKKSFhb2esWFlFy1aTYPGYQ7Nk7YVlBZ+ eZfwy7VZNKQkW6SDmScMpSMi3rRPzu4yJydCaEzl4xdQkhgFSVJEG4EZ2TxTDgHjnggMMEA1NU+o /UYiEUzWdwAyNvkt3jlOxkYDuW00BwxTDcZZWZScHA9UuvvtJa9OOzV4svMwRmqZFUZQtSmn9RdR JiLvDT6Vjg4t2wi4FBiQr6TlLMStNmqJhcPEGKaT34O+stvNW6xdSXZ7b1+5Y3mWRjqY8Uv1YSj7 S6Yy7RjIp1wpZcX9qcx79UjFVrWm8rIJyx0GZkiqmAgeSfVmw5bV18q91iV3RFICaYSK7dq4M3Ud Nm7hM7lBM4GAhF1ECnKgooU6ZFewVU1UfUSP7tKBYqvuCK0tbo1t+0DSSrMTtGqXNu1VatI5zGsK 0wjn5UpFs2koiat9K25YWycc9ZNpFzAlkGD1NsoVREYb1L0zZ6M1tLAt1JbTCVXbvR/u5IYGfbho cgSbTISZGO1JERCxQCY9NdZalq8VzFKNPW8gMbR5tZQZI5plj3+icKxR2SLaI0GXR5JVG9qxkh9D bV2aYrqARNSoQ0a3dtLjuKqTCpJxV6WAk2pGumyWCj7HFkm2NYYKxIX+d1DMw023aKtK1doJyosl sB1fQG+uqu3iDOWElMuFTv7FMx0c6iGsrMOCkBy4ZRj6Xn38bGtkUkGENFup2aVjodmwYfeDoEPi FLkHHzx8vn/zlPIU8u5e2kaRx5DbQAzsVGA0krDexOASqlIQ+XSFCam+13dZp5XmlVWVSfRFGHwW WKBCI1GRhZHElxsPbed1rkcgPsIDjKACIDyGV86a+6oGKID/AE/P+/pkMrHEQKPHv8so4/5/z+lK rlEOPA88eMgYvPkPcP8AXKQDwPP9jkROYfnxilQEBAeByGRERH3/AJ/P9MhilMYxilTCIAHBf4j8 x/4/v9ZcYxSmMYxSmcV2mKiRih8yiHn+P9/wzlYEOfA5yDggjyCD/SuCAQQfBGKsfM1Vd07MYCjw I8gAgP5/zHz5+vyDgM+vp5O9dPO8v/uE1wzqtqeTlepFB2Prm9qvY1hZqZUpu7SESpRrdHAv+xNx Zvdkzkm5Tn63cIC/hEwNKP8A9OBfONjRV0hQII88FEefcQ8h+n5/yyuZIBIIABOf3i9xe4AOAh6Q gHPHgQD6j+fnN7F1Df24iMDhGiwMkbgwG04I/MjyCGXgqVYAjQTdOWFz3hOpcSg5IO1lJBAZTyMg E+khkPKurqWU3T2r191q73jpauF+6XurTUVJ1h1aDI2q6OIzSOx6EZztfpf6h9B1KkRkHpHb+yNx zf7W7SvFeslUZPNfLHbvVFEFXiDprUKYaym/OsfSEpZVa/DwXUPLW58gm4hKAr0w9Q1Rtk24etzm bMlP+oWuqfAV311PTavZy5T1VqlTVWbK3Kz1iFV+MLsnp9WpsP0ha3ukxBOJte0b5NVZUDoC9r8f E3P4rXL91cIgU1WjyFna3IWDWiRZtM7ZBzsDvImY5ymzXDeK7UKdNO65rmr1elwaDg5EIWmV+KrM OgUDiAFbxUMg2aIFDkQAiSYFKIjwHnkfeP8AZ3+ls/1TsI7zUrqwtI0ihnupWs7q4KwSksiW8S3c CiV4lwZ5ZnjhlBfsXAzCvmHr/VbfpvVLu0sEnkjhneCMSTRh2ePCyF2WHlRLu2qqBmjwC6kbjh/E dLUntu9tts9UxYBzVaqDkdTdNUWuE9S6i4mI14ykbxuGQD1IPae0n8BMLVRKFQbL621pEOJ1jVXF zeTL+8u812tvj0XRGTYiZUwOBQEgAI+DceePfn8/ceOPA5048JYDNnHek5ADIlOQe4yyQtg4H1TE /daio5WcJpgYCmeAzMYDcI9pelVE0fLvHbhnJtHqMfJvIt4o1XIuVtIxy4t3rJcUzj6TlquQyayR gA6ZgADF44z3l0L9Ifp/0fFcJaPBdX7NOI5bl4mvZ3gIMjKgWMsIlZGZYYhFCrLsVYypNRalr+q6 gydzckeFyqA7FDYxySQC2D5O5iCTubONidbkanWqNLbAt9nh6fVa60TfTVksEk3iIiMQFZNJI7yQ dqoopAs5VRQSKJwFw4USbkKodUhDYQzvVoO2djScBrBu2fapqsGg+st8sJJWJkrG/n0Xha43o0E9 RZvXUKJWSzh3aZFuSNkEkQaRXxZiqOE4ad20rqC+3jp/2+b/AKha32q7lNgaanbm3JY2oTK0g+td l1XJHkCuWvdU3LX9oaAguQot4FmZoxKVOASBHGbe9q9DfsZdSHBjEbDiC6/ljpIvjthnId2rKUIi xkO6Ni0DN3lqiU3TpNv8a/fQ8YVdRyozbngulLrOqdTRavNL+xOltC6t0zSOpbZ4Yl1W2uJ79LKC Oa9Z3t4NIe8vdDvLqVIN11oN290Lu0gLF865eCGzEKjv3dxaPNbOrHssqx9xjsxvabZHPGoyQtyg jKN+JbNz37QbOt27VW9zsdds1A2KxiNczMHJKsG8IxV1br6xfd8vDNRJFWuJdzs9NOXbayM5RTtf qEZrthbsjNejzEbOuH9T3wzrico+FBk32RW2RTSfamgk5jF7jVyCzBdax1gqz5qCrZs1fTlVXdR5 0jOUI9JO+7vT2yRtL27a1d11F3YI1qws9btaMghDSzyP7kYqwtpOKKu4jphmyVFk7OrHSKcqwZxb JQzQGKKpcpdT6kRo9CqlWlHJJidiodm1lZNMipEpCV9MDyT1NNYyipEnT4y6xCKHMZNM5SmEBLyE yuOlxP1BqGnXmnahpUtpN1FrP/UYFrf2E3U9r1dZat9N+pdLilllinvdP0C51rStftrmG1eey2aH dNcWEdhOurS4fsRSxzRSRPHBbtaYdJBbyWfa1O2mICERyXCRTwMDIBM33MRSbvrVllteGtaNbdIS sjXJmu2SEtMHPRiSRnjZePcEO7YLIPExItHTsWo8hZVscCmOzenMkdJwmidPM2u0NtYLZKWiGgU0 bPaYqvQ1glUfX9aUYVRWWWgk3SHqi1AY1Seke10ikV4sRZs3dOFGzVoRDqNrs+oNLxQ2Laltjaw2 Oo2bx0cqYXU1MyT1NwtGRETFthO9dzEwjGzCkDBopDM2MsNNfcDR2aKciTSp1z/bE1SrjYKBR5+Q cxKjVWJc6W13JxEVIS7WUbMm7gN5byra0+5YMIo6UqC+t+na6w9hkF149dXdzGGeuo5jGPqv9X+g elNTu9RS0t9U6uma2eSC2feY7yztLixt7uZXllhsJ1tbiayluo0+/msdltILmC3hjj2mhaBqV7Ek QkaKyUMoZgQCjssjIMAF1Miq4UnYJMv6SzMbpfbmM9cWbptqldo0wxv+3dE7lSud0RrsgVatavrs dr+wyNhjb/Z1zpU2Lt824eU09f1w7sbfZtij3n33WKrOxLCQVL4znipVnS6hClKUypxDtMc4CAmH jgyhjGEADgAERDkA5ACgIFDIHqG6qd09TtjRnNoWVI8RFKvBqGvayySrWsdfNXzj4lwxotGjxLDQ Ca5wID1+kktNS3pJqTUrJLlBXMdRHkRHgA5HngPYPyDnkeP45+e3WnVV31r1Hf8AUd9BBb3N+Yg8 dupVdsESQQ7yWZpJFhjjjaQkbgi4VFCotr6bYpptpHaRszrHuO5vJLHc36AsSQPbPknksYxkWrOp jGMUpjGMUpjGMUpjGMUpjGMUpns4+x/mVZnpRqguFO5aFRcxDYygGMLRoyPFsJFqIuBMZPuPFId6 YCUhTkDsIUhEwDxj57Mfso4AaZoPWkCYqrn9qq9tGxuniYTBmiRIy1URuwbHW9IWCbxwxsY8Ju10 3iqrJ2pCJrRqT86EI69w2jRxj8bXayKOPEMFxJIcnGMRhvfnO0AkgVN+gSU1p5CAUW0MbZ9jPdWs UfGDkiRlI44IySMZG3ARER5HIZAB5AB4EOfkPvkcparxqIAIj/UfplfKQHH6Bx/ftlQBAQ558f0/ XFKGDko/pz/LznH5Dz5Dx7/l4/0zkch9Q/nkok58gPH5f37YpVLGVQIAe48/388CQB9vH9P7/jil UsiAc8/kAj/LJuwfy/v+GTAXgB+YiH9h+n9fnilUsYwAc+AxSpykEffwH9clHwIh+eV8oG9x/UcU qGMYxSmTdg/Tnxz/AMcZMHYHA88jxzx7+f8Av+uTgYB9hxSqYEHnz7f1yVwsVFMxzDwBQER/T6fx /wBvzyvnwLB6gsVgS/eEo+3v7B7fw5/+c7YUEkscZOA7qpPwCeefb9fbzXVPIYoZZQNxRCwHyQK7 ltzqZXr32f26ohgoiaR0mo/3ezarJAuk8U1Y/i9yw6BiCBhAFZilqppgUhjEVIKoB+93fEq9alLh cG7vg6qTtwCpTiAiUxTnAQERHnkBEQDn3API8ccZjxTF0mtqkYq0ImXqNsZOICyoKEFZAY96Q7Y6 x0fxeomkVZQqhfcyR1A5/EI5mV0NHeOelXS9ls7sZe61msvtX3qZOuLw8rsrR1nmdPbMllJL0khX SdXygWBVJUCqILJGFVNaXTOmsb9X/wCzH1zoejdJxaFpjxya/LoDWV3bqzboG0jUbhrW72bTGEvr TX7WNZA4kkm024jKskQK+J/qBp97ea3c6jdRyRWsl+8yOwKq5njQyICf4o5Ld3K4/DMmCM1fi/0y uUiVgQcIoiraqI/j1VHK3YDeUpEkjIxRY+NMUCnM7irtZhcyhT8gEOgicnachj6kYgHVN6hdyUMj kpGN1JB7Yqbc5V0hWO4ahWLm1jzquVU10453Dwb90i1RQBFWbMsqUwuBOGXvUxtKUmZGLOiZQRrM 4hIpKfHHZkZIu415WJSRP5Fq8FhAzEq6IR+Q6fcgmYxSmTSMSxGwtbWPY8RV7pRixDPauvZdKx0e TmgdGiXabpMWlgq8uuw5cliLRDKuo9wt6TorF0ZlJptVVWhAz0BYaD1BoNnD1AY21DVtD1yDqmDT V3A6jo2r2V5pusafBI3ajkvZIptUu7a1LyLJqNnpYmaJZ1aKDS3NtdSvaKRFFNb/AGjTYH7uWKSK WJ2AywTfHEsjgBu08pVXK4a2O32cgvbOnQrgofGK7qFOPEwh63d/0t2WLr0O7/EEfgQdCv6XP+V9 UTh6YGNl27dqeFudbm63ZFHrZlNslWyjyNdqMpaPWH/EaycU/SH1WUmwckRfMHaQgq3dIJKl8l4z r8FUt17E2Brq67RpFL15WNbkn56LgYu0LXKxSN2mId3WG78zxKFiomNhWUDKzgogi4fP3ij9Dv8A hk0lCm7rtu9wuvKzNWmxujtImHZLPnApk71ViIcmUIgURKnwUgGM4cKHKzjGwGkZVZnHJKOAlel6 vp+oW3Xuta5bNpXS2tOi3Sa9ZzaYtzolt03p1nfXF5Y38cF3bwzyG9tGhvYIJ5Ett4i7UsRfDmgk ifToYT3ruBcJ2JFm23D3cskao8RZHYBo3BRmXLbckg4uFRTotGUPBOXppNWKjWbaRnXaSTU747Ju kk7lHgAJW7YXAkUdODGUTbo8mOJypEUOGFXXx9pdpHpEr8pXKvIpWrb4Al90wzRWIWAyCrQF0pVy dNxLLV+HO4FM7JewQTeWuDHl7S449XfttiR+mLqk+2jMq3lKn06wxyLqJvGZbpMlRXi45ZNbtYTM LBu2XdNTzRUCS8VJTwBD16RbsXEfASUqyRn0vP1Z7TYblNSFis8zKT01Ku3D+RlJiQeysk/eu1Tu Hb1/IyC7p8/fPHCijh6/fOXD165VVcu3C7hVRU3kj6t/2hI75/2F9N7q9t9LghNrLrsrXCXd4qp2 g1obo/eRLtAYXNwRdyEK7bGMiNO9B6VdR9zq8SByQyWw2ELyD+82ejHGNinAGQMDBq/28Orrdu+L JKWC53OVWNIrOxTatnj5NswaPDpmWjo0XLx6+bMlgQbi/UXfvJewukAm7dLWS0OZGffYw+/vjGeS pJHld5JHaSSRi7u7FndmOWZmJJJJ5JJyTU9VVRQqgKqjAUDAA+ABTGMZ8V9UxjGKUxjGKUxjGKUx jGKUxjGKUxjGKUz26/ZmrrL9MOsV24pLNfiVEAdEAhFVYqTqbOcbrmTXTSWTI4cfCHBMEivexNmZ QiaQvSh4is9fH2Oc3MOOm4tEeOpF5O1/9iNjkn5EriRij1i5TNhgo6rxD1yoi5NJQNQ1+vDuGIE+ DgkpWDRYncsQSSyEdew9zRkl4/cXUWcgkKJcxlzg5G0kcgN5xtJIImvQcpTW+2N3723lYhCAzmAd 4RjcCp37eQSvA4dea3SphwXjjjjxx3Cf2+oj/wDP1yfGMparzpjnxx8vfGMUplUBESj58h+nt49+ f45SycQEC8fUeR/l7YpU3eH5/wB/3+WTAID7ZxxHgOR5H9AER/kHOTAIh7YpVfJS9wB+MQEf/wBp R8f1H+PjJSnHngfn7D/f9/7VMUqUxeQEQDzkQKAewZHJDm48B7j88UqfKJx5H9PGQ5H6j/McCPI8 jilQxjIiHHjFKhjGMUqICIDyGQWTIsQSm4HuDyA8fP8AXxyHzAfljGcgkEEHBHIIrggEEEZB4INd ccV5mAKLFR5N5MBSlABMPH9ePzD5/LOodL29PgOpbqt6YpZozYyFnruvurTXgRpl3DT9lVKfSun3 Z8Y9RO0QLGSjW768rtsN6bycI9PshyqmRkVqDPPk7f27B64g3ijp62I/9ARSSOqXlPkogBjk5AQK HICHjyHHv7ZqRlWGzNgXSL3TF381E3pqm0OZ3Q0gSBYStXrEG+aSUVZK7sVJRsjOysNuOuyTmDuK LFX1a+zQhBrMWo5h7orebe+jX1BboXrfStavWll05Jkiv4EZe5LayZiftBwV3xq7yrvaKMlTukBK Bq8+ovSZ1rp2ZbOBRcwkzwsBgEqAX3HPh8KuAGcnBC7VZl3bW6CZ2GbfR7wvrt33rMnRRHyo3cJi 2cF/L8In5EPIe4ce+ZRdLMO2uGoDTLtqoacrs3aqXPEXTADjNUexSlZfvu35pzBYwku3HkQMhJJG /CHIBqq071PS1ok28H1AUpLSWwEZGChSyyssi41DsmXnXTaOhZDVN0cqIOVmtnkJGKQgoGyN2sia ySTqh16XvFqp1y+5NgdabvNTI742BbN6p1/Wd5sWt7lHa9Y0MWkvJyJddLa3t1Tf2hXZLiwTULaz 6/qFjLMVGp6jXiyIqlrVytayluLn6xfUb6maKnSmh9caBrEd9o0FtLZatHFJHaT20LRx31vJqVvc tDd28trLam3t7eWBpXj1h7m3jeGZXl8faJod1canLpb2ri9lkUWyhS4lkyI2SJkBRg+4Oz7gq9gq 5U7gvA2taWlbY26bdPGMTDVVsVaescry3rldKo8UZiWRcmUIm9lEe0xgrMet98AorFR8ypBpzcVL H8kXX39q/EbciLhp/SkC+GpTRF4if2HZjJhZbVHl4QOwbMytEi12tKFRTXLCRgRoSRzqOJ5qDt9O t5PbJ10XJbesKeuVWMdwERH1SYi6zXWtgstMp8I7WaLQkU6qlXoExARNOUjIBzYK6IsUnzKwVy4S jG/xF5NCU1aseQbZGsLNre4SdRsLMzCQbLCKAPTFblcNlTm+Hdt1zimiq1cAAlK77vhQU9Vssok9 aOkG3jXrX+0TP9SVbQtEuJNP0mCHZdWuDHLfk7lMoEg3xxCKQW8hUmWbdN3JEt7j7OK00+m1/wBM JDqGq2wkadgYJVIkigcYIVyuV7uVLoCSFxkAsqubZGN3GE3HHI+398/388lxjKorKpjGMUpjGMUp jGMUpjGMUpjGMUpjGMUpjGR9/AAHIciI+eePHv54AA48eAHyPIj44UqGV/REpQE5gKYwAJCAHcYQ 8+4APJfkIeBAQEfICAhkpCgHAicCcD+9wJh//iHzEPPkPb2EwD77FtCdK8DMwVft0+9YzM5a0Vlq RVXBXyjKQeM0na7gbE4jkVBhodAjUorSIneOjgLhKNhJiTboREhrtS1O10qDv3TMAzFY0UZaRgCx A8KoVQXd3KqiKzMQoJrZ6XpN3q9wbe1VcqFaR3YKqK7rGn/k7ySOsUUaBnlldIkBd1BxL1pp62bA ftFixrkkOsu3ZEfORKiR6uqdJs2jmCjkyaarhUDFSIcVEmzFIBePHLFk2WdI+kvpRev9P2nUFBmL PYNf1STqk5rsXUY9oaNUn3U2+rzapx9whbrT1Jt3YmcpKyi1ZLHsipxJGsg2fSh4exy8dJdf1xpd vANo1qyFd1MN2yiSkomkhElbkcqCqs1iIhkUYyAhUSmM3btVDScs8Zto/wC/JqTm03ko5u630pUI Jq3fErkDLroOIhOyknI6UsT201FFgesWqFlpcyzq2z0zN6/fzldZSrp3JSguHqfrlepOnCC9Tat1 RLrNwsRBgsI5GUIkayiVX/dmR+7s9SoS8W6JsOVzGpFXNpnRUOhWUszOk+pSRI+95HiNu0YMnbHY DFlkb91MqTw5QMI7mTIztf8AQ2AwXrR2llr8zGxZkIy5NrBGrtJuWcrpRbRV+0nK+m2hoZZt3PrA qwcUhwhYHK8eyaytRiHKjktzWxzKEAVEwKbyICmr66Zg49vVAoB7/XgfHkePA47xO4qGtHehKyEh FtPhit266wPnCijdZECppuRbkfxz5T0jKh96vvTUdgDcVEwemAR7rTNlVCWRfNW1si5FVpIS6qwO U1YSQRSFdxMGK5jpUGax/gI57HqrPGZQKr6hlfgY4gekWHOWYDKAFSQCsYUsGJbnYoQ4ZsKT68Mq AsioElKJ2fxGTDgsxeVpERkVRhWkYvhlG7gCMlGcqjud92zgUOOPn/H8+f78f7ygAiPAZxUlk1Td pBOIAUpiicQ5EPIByAj6weSDz6wBzx458AHJzq/4K7qrgHAcZA/7o5EB5AB/LAgAgID7YpVDGB/X nOh3zYEFQYpWSmHKSXYQxyJCYonMIFEQEC88h59xHjj6Dj/OuVUscKMk+3/P8/y5rvYnKQO45gKU PImEQAAAPceR+mWbvG8qnTFQaqOAevOe0yTYSn7R5APxCAiAfx4980ydSf2r1frU7JVaDcKLg3Om 2cOo0PWLFqKnOmmq/KoZoksZ0QpXDFuzXUVOxTNJuToMHsOd9pH3T1vbOu1odu6vYHkbGlOQCu+8 x5J0qRyLoTmeGKiqDb1y8ppNkGTYyAg3O0K3EEAk2l9Javqm1xD9rbum8T3IKKwOMbEGXYkHIIAB GGzggmO6n1boOj71muPvbmNtjWlmQ7K4GSHlJEahTlWwzENlduVYD14K9YNTEgmbtu7uImokY6yY JrEWKAlVRVNwVwiILJCBm4iUBUABH8XGW3m+tRErV3IRKCL1oyTVUckh0HtjekBHvMqVNhXkJF+s p+Ee1JBBRY5+CpkObwbx7OOqnfDtNZNxsKXUTUambAkY4AiRM34Q9JsQoNAUIAgYplEDcFJ2CIk4 TGWodUW+6pYAm47aFqOc5CFWjX8vIua+cEQRFFcYNI5mCCrRRuk8+KZNEHY+k4AVjg7dJuZCn05u 8EyajbggAhUjlwx84LnlAfG7Y+PO1hwY831O01WAi0e5I8FpZozt8YbYv48HJKb03YwHUncPWMy+ 02oMYu9VstY2IWKracW/vKyGt7iwkKfWpgJME7jMQE/FRFnCsRow0ipLSUdDSCjYW65jIAmxmFYv Y3XL2yt9Vi7dW4eyPY2Yj0ZGPavoZasTR0XCQKppvYG4nrctDO+0QBVlONop03U5TcJJHKJQ8nmh Or2M3m/j6ltQpIy2sXqUrW7MyWK0k4+aQIoiSSiXwkMCLhZu4cR0m1WItGzkK9lK5YI6UgZmSjpH bl0m76tOvGUhqCxIR0pLUz0F4lpFinFQStDm3kqFLlIBg1ZG+5q22Ri5asxNYcryEtBhVlYmTn7O VJG6WGL6to76Wxhkt5I54nV27k/ejmtn2oJEdYogwE+FZl7ZQTJGYyyNM8q0nU01iJbm3uYngmjd FWO3MEtvdpmQxMJJ7ja325Z0VxKkhgkkEgDi3XaxG2WcdjGEd0G1RBJBuqq4UfPaSoMGukBeG8qn FXCV/wAVwb8LI0GecbgJT/EOG4CQxu1pncj3gukimHj0hSXUW7g48ioBmzf0x/IBMH55imTqDnzq 8rwMKdmY3B0CnelX7BHyUHB3B0jGAPn8MACPyD5cqz76fPG5G9YYHijnTILh89FFw4TUEv402qJe 5AClP+6ut3mUKHlukIiAaV1LHIjSMcjCFyOWLc9x3b0hgowcFVBO5izNtY0ZAQ0rynP4pO2CMBRg CKOMEEgt+EnLNg7QFXKsA5Hj65KoYiQAZVRNMo+AMocpAEfpyYQ85gqz2xfWYriWfXcCumdP/NpI OPREwceqgB0+ElC+5RABIHzIICID0qQlZOWXM6k37t+4OIiZV04VXNyI8+O8wgUOfIFKAFD5AGFj ycFgPjjP/quwAE4zj/g/+4+ce2azstl9r1PaevIOiruj8fDRrQ6ar1wJg7gMCfdwiiBfJl1hIkHJ SgYxzkKbGe27qsk8U7aIAa8xEDAb4VYVZBcBAQD1HvYmKIcexGpEjAIj3KqB28WdOodQe5Q5zm4A O45hMPABwAcmER4APAB7AHgMlz6CBTyMkfPI/p8UIwcfHv8A8/rVm7RW520TiUgoZyj8G5WEjl2u o4UW7xKYy6DMXYsRcgqkgZnKybV47aFB4Rm0ag9O7GeHrtiaSqQ/HN1IP4f01EAQE7gr5FZVMwqv PvAfXWdAqUHP+UDsMxMUTiZ4AJ3cOmQwGKYpTlMXtMUwB+P68+PPID5/l+gpCplKQgFKQpO0hSl4 IXj9PHHy/wBR45HPsABg2SWBGOcj2OOATw2ePB5HPiu55d8ZiZUIYYPHklAmTjOSBgfyyOQMdAvE CW301Wj2FmNlrCj1q8CDdrAg3+JAV2a5gdImbLIMXsVIScFY2qCgt7FUpawVKXYTEDPysLJ3FlLL bbZFQ8LbJt5PRsHEN4GJZvypHbNYZo3O3aRhyCkcXjZAiroEhfi+On8Y+7TgL5f1IAUncAmKIl5A TAUe0whz5ADcGABEOeBEpgAeBEB44xwUBHtDgPkHPIh+o/Mf7AAzeS9RatNYfs59Sv3su3FEbRru 4NsYoXMsMRgMhiMcUrPJGhUrG7M6AMxJiVt0ppVrqJ1KO3hE5d3DdpN6s4CsVbGVLqNrlSNw4OR4 +C8g2LxuqgKfw/qnVWBZsVEhiuFgD1XJ0zIegq6WAf8AzF2zgwD+IPPHOszrc0MnsOkTRiRpErtT WxJuGkyNT/DysY4MsVRq2fHACESlCsXTV2wdOVXcS+SaPlkHbYsQ8f7UctBs+Kj5UrIiqaaj1FnL Mjn9MDLEj5crUqyAmHwVuq4aMnJyCPI/AJmEPwlHNZaXctldQ3sJKSwSo6kHAIDAOjeAyOmVZSfB PGM1I7mzTU7S406ZQ9vdRvG6sOFOwlJUbB2SxuEkV/8AEoHGd6ePd2BQXMBO0S9qQgYoCAG5RTHv 4EAHk4j3m5DkRMIj5zjZdretdSqe2r5XkCqEQjbHIlQTVAgGTReK/eaZSgmPaCRfjhI3AA/9OVIR MYREctLnoiCVZ4IZ0ztmijlXPnbIgcZ/PBFeYLiFra4nt3xvgmlhfHjdE7I2PPGVPuaYxjO2ummM YxSmMYxSmMYxSmMYxSmMYxSpilMcwFKAiI8+A+gAIiI/QAABEwjwAAAiIgACOV+5IiJSgQDLmMcD HE5x7S8p9gAn6YF4MX1AMInUMbu8lS7A9TjZHjyPPj38ef5fP+PPy+eKVkF026kd7e2PGwSbI75m iPxb5JMO5UW6aiKazgSjwkiyYAuR1Jyb5VCOYp/DMyDJWGYrdZsHo40TpqJo8YnGib46TM2RPPTK JRRKuomUCt4mGarGXPC11scogwhkllBAgOZOVkJWxyEzPSmDH2btSZRGopOyDHooyVlm1hXfAQPi nTZiZRFmmZU3J/SQS7zIIk4RSUVcLgAKOHJj7bac0BGPVc8eXa3JR+YpodxC8/8A8xVH9B8AHuNK 9X6tNf6tPZKxW0sn7OzORJJGfW5x4UuQAgOG2K7ZYIE9B9DaHb6ZoVvqTqGvtQXvrIQcRRygCNFB I9Yi3EyYDDuPGhCM5l7M1aNmSRUWqJEUyhwAFDyI/MTG/eOYfmJhEf5BxycYyKBR4PB+B8ccfH6Y /wBsVKcbidxO4nJ+T4/ln9P9q4CCfocJF8IiKpiF7uPSABD/AAw8D/gh548gDYPRblAShwHCRikk H7x2TkE3ItFColWdlblWbiPeczMVxjSqAJEjA8I1K9MJSlOcStGfb9zGGyM+ccfOMDH+eQPf/UV8 sCD8gHIzzj24PscEjIIOCfY1dKq7vkIU7ttK15KedC2jGTWUKIxz07ZqDoh1n8uizdovjM/W+HIm ZdvINgZHOoo4UftlA7lBb3Ok4OWajXqTJQfeOfFfKthAR7vTJKkMsuBx/fFWSTAgBykkj+6OPecJ wVyJDfDGTKryj2GWROon4V7leQScNhEBSAQ7gEOOeRK5ABbj8hFY8gZIGTu54wBgZ4wBj9P0ArhV UYwoHJOAQMljuY4z/ESSf/Ik+cAZzRO6qDKimT7ycsBVESk+9GKrMn04WU/xkEh5AURFZVP5+3jP vvdmUVkAi4tEP2FL3GM1eovyk4ERUAxmHxPb6HH4u4AABHgeRDkNeqqDhYggZT4c5klCdyKqp+xT /wDTVD/06PPPngzYeRAA7uPb5reDalUUVcfFu1VHab5RV46cLgZ23bJM0XbZudwdrGK/DNUREkQ2 YpioZRUE253r5E/HaQjIZvH5HwRnOcYGCT/T2ORyRyMYIJOecEKPcDHJzjIOABls8BTmbYeo6ksW 4DVU5K7PjqnbkSh2xmkegYgKAs5eS0v8CxFqm4KLPhgZ26M/SXagkBWr5Rn51/tWupq7vXldqpJ1 zU5yS9OadQ1akpF0yjY6KO3cN2yk+4axyrmTVmF2a0c+i4KtyKcdHrmkXZUnLdo72dXmTfxkWulA lRGVXQXMkioqZqisCaPCJTOUwOZsKinokB0Qhh9MipRKIgHoea3rxmSy+6jekuuZq2gmybVFdwVw chRlZsVHRzFExfUlVP8AxTu7gMRJ6i1Og0O1M3JJuj7KC61y3WSMSLbo9z68Nlowvb3Kcqdsjq+7 GQUABBJzFet7iaw6cnkid0ku5I7UMu9MRS/94h0K/iRHTYXcFZW3K2FK4ZuHDp6JxMdVZFuXuApE Soot0RVKmU/wzcPh2pDKKkIIEACAqqUgGMY4CbhZEpjEEDFMJTB5AxREBAfqAhwIfwyIm5AOQLyH IcgAF5D38gAAA8CPgRDn5ciAABbyAA4AwPgV5/qXGMYpX0oiWfwUkzlo1czd6xXTcIKFEwcHTMBg KbtMURIbjgwAYo8eSmKYAMG87RfUA2uzHVmxKs8fyWwqe9kaPb9eRzf7xn7zRX1elrfNosIxBk/k H0lXGdOe2qDPGFFyWQjTwirllAWGffJaH8yG6a5e/QW1IB1ryTXjZFR0wI9XSO6K2ViFZFkWUYPD ot1PTSdsRdRi7hRuZFIjlVb1mqQA/b6XW9Ptbu1aedU32kU7o7napR4mSWKRwrMscinBZAHRsPGy uAw3uhaleWV0tvbNKUu5rZXjiAaTuRzpJFLCpKqZo2X0hjsdS0cgZGYV63Wrlu+bN3jNdF00dIou GrpsoVZs4QXKC6DhBchhKs3UIYpyHKIlOQwGLyAhzzctjT7xBSDFduWRbi4YyL1q5SQdFkE41UTk epxZzIN2otRasXjQWjVZkidvHKMhMZ4ChXry5KSyK5QOiqmqQfIGTOU5f5lEQyhiFbw35/ng4wSM KeRz4Gc5r0gI22rvBB8HgY3jAccFhlWBUgO2CPxEg5q4xjPnaQQfPI8f78V87SCD55Hj/fipBKHP d28m/l7fPn9A4yfGM5bAB5yfz5x44Hx/6rlsAHnJ/PnHjgfH/qmMYz4x6Sc+DjHz4/8AtfOPSTnw cY+fH/2mMZSETAA9pe78Y/w/PAGc+36/qB/vXAGc+36/qB/vVX298shYJJFR9JPVD9rdMyo+p7gC DUoJgYP/ANolT7wD5gIgHkcuHYp5rGs3CAKCo9XT9JNBuVRRZAHJTFFZQEO4yZEw5MCw8CY4AUOA 7jkx8skuixiJdVxItYlqzauDyUs6UQMhEMiNfiXLhUXP+VB4RgC7oPWA7NogHxr0jpMqbR51tliq LliSMAAk7jwAAM5JJxgAk8Y81sLNNiSzPwoQlSSFBCjcxyxCgAAAkkKBkk4BI863WGKIdR+0E0RA QRmmqRhD5nLDRgnAfzKoY5fb5fXnMZ8uduSyoXDZdvsjYjhFCZm5GSRau0UUHbFF+8XeIRzsrdZy io8jkF0mDtwRdUHLluq4E5jKCOWxz0fp0TwafYwyDEkVpbROOfxxworeefxA8HkeK8qapMlxqWoX Ef8A25767mTByNks8jrz78MOffzTGMZmVg0xjGKUxjGKUxjGKUxjGKUxjGKUyIc8CPHj2H+Pt/Tx +mRKQ5gOYpDGKmUDqCUoiCZBORMDnEAEClFRQhAMbgBOchee4wAMuKV6EugCVbyfTzBlQACqMJOW YrphxyVRF4b8ZvHjuKYFAKIj3AYBD34DaFWw4hI//wD1qD/NdUc0BfZwbSRiZKzawfSSCASayM7D GcHMdBZT/KMXiTUh1ESgr5aGBucSqFXdCuCSvY4SJvPrtlIyTSjX5QKgXkEXRQ/CkBzCYSqh7imB jmEDB+IodwCAlAOKC6ltHs9e1BJMqs0zXETEHDRzkSDB9wpJUn5XnHOPTHS12up9LaUYvVJbRLbT qOSslupjb0jkFl2yAY5DAjIOauVjIFMUxQMUQMUwAYpiiAlMUQ5AQEPAgIeQEPAh5DI5p87W554A yP8AX8/9cY/ntM7W5+ACf9z/AMzjH82MYzl+QCOR+X+VH5AI5H5f5UxjGdfHv/L9a6+Pf+X60yi4 cJNUFXC5wIkiQxzmMPAAAB7B7iJjDwUpQATGMIFKAmEAHiv5RlGJgo7WKQTfuJhyZVT3/dIXk3Hg eTDwUB8CbnLaT1iUl+1BIhkGhDd3YY3J1j/+06nH4QAgeCEATBzycTCIlKT5ZgP19hWTb20kzDgi PPqcjAx7hfkn8vHvXxJeQUkHDp6obs7wU9Pu9kUi8gmQPPHBQ47hAQAT8m4HnPMz1UOHLzblheum 7liDwrY7KLeckcxUekgi3jWC7Yyi3wbpOOQajItSLKERlDvyl5KH4d/O3LpAVup2JxPnRGvxMau5 shHfHwsgmVMiiFYMdV03SOMuU5Ty6ZkZBl9xJvmUmk2LLM3Wea/Z14ebFu9gtrwR7pV+4XRJx2gk 3MqYUiFJ/wCwO0e7s89omEvI8Bli/TyylM95fspEQiFurlcBnZldgpzzgAF8Dj0YJ3ECtvqpqEPZ 07S43HcVzO8angKIwiuwA4wSUTLEsTLuQdtGboWMYy1apemMYxSmZG9Pu0qxr2WlEbYm9bx0tHKs izEXHRUk+jFQMLtF0RvMR8ywVVRcoI/DJuYWUaKqnIV23I3KdUMcsZj3VtFeQSW06lopV2uAcHGQ Rg/IIB5BHyCOKybS6msriK6gIEsLblLAMvIKkEHyCpIOCDzwQcGt4lF6yNGzFyRlHsmhR5aVYBCy zhBs8ZQ8irESC6kBJov2yKbRiDqPOqeSiLgaRjIx8uziYCUO3Vs83P5z1PbVSnkY1VhZmka9kFkW DZhJPWbSQeyiqbZwLOKet35oqfUKk4SIc1acSbD1jqJFVFRFVoTyqZ2WAuNrqyqa9dsUzCnSU9Up Y6RdNUjHEBAfVQRVIiuUwCYp01k1EzlMYpymKYQGDX/QFnMd9ndzwMFCrHNtljG3IQK4VZFUDAO7 uMcAhhgg2Lpn1M1C1HbvbK2uEaQu8kQeORi5UyOyM7I0jEFgVaJAzMWRiQR66m9unGhOD8POA7vT U9NYfbyQFTi0VEfoJz+/PPHtn2kb2YDlTcR4mUMQTdyRl00g49w9Q6KqPIB8hVAef5Z5hab1jbiq izJRaacSqEf6527cj6QhkjKuGTtgdZ0ziXDeDkjEI8OukWYhJNAjxNs7BD4po1WRyOpf2j1yiIx6 xsSjuckXD9FwwmpmtQEwWJjk0mKS0SEZXJPWYSRlhQfOSybqSI4Is8SKLdRJuDc8Xn6I163yY2gu FBUZSRiTuYglVZCdqLhmztbkrGjkczO1+ovTV1gTxXNo5DMd6IUG1FIVnR0AZ3LIgAZcAPI8YYhd /pbvFFKYzhF0gBPxHMJUhSIAB793qlN+Y/g/UAH3+ylZYNUAH7wTTEQ5EqqTkgh+Qj6Ik5D8jDzx 458c6co/7RSovSJ+gwrq6p00VTqTsraKWZIxwKKyCrVtTL0yEUDioJFG8+69Tkv+GQoGUG4Dnrq1 SxIZRRBKdROcgJOKtZassPpF+BBIj8bfL1FVs/QVcuuwwncsjtmJH6kixdPk4kmmk0DXYyok06cF 87chQDjaDuw42ZyMBtpbnAO1sbuPqLpW4DNHqsWVKBwO5kFgTgfu2EgABDGNmCnGSNy1tdRlIpfj 0pSOHn/+48Rb8e3v8UZH6/1+g5E0jHEHgZGPHj5lfNTh/wD9EVMX/XzmsuP6v6TJItXMZU7uozMI GTXJbtCqpOExBQODfEbqVcF57gMAmTKYPTAoB5AMllOtXXkQRAzyqWkAXbKOCqpWzRKySPAqAYi6 6e5zIJiApmERTcHKAAAd4DyAdY0zU87PtFLeNomgzkexXvE5z54rIOq6KFDffERlQwZre42lePVu 7AXBLLz4ya2XqzMSkAmPItOADn8C5FB+fsVMTmEfHsACI/TOsytvRBM6MWB1FjgJQcnKJE0+fAmT KYO45g+QmApSjwI93tmtyY66dUNIxy6aSEGWRI2SUZRc3aWqYOnS/b/lXDynsL38GmQ3g7xFk/bg XkwFSJ3HzGG+/aPvlWLxrSI6LYSAkXImsi0kJcEgURKiVzF2CaQiGxJFsuDh2RKSoD5g8bGasyHQ XcuFm/fbdPa3esFi0+WNS+wySgpGrEAgknJ2cgdxVMYJ5YAEjCu+p+ltPQSS6ik8hTurBBl5GXPu vpVX4J7LukhGMKcgHalJ22Kj1Zt1NSjOPZQxV3Em+k1wQIkk3ZsXbt0ZRUwFMzSJJNUjO+4QK5K5 aC37kxOGqDrS6ok3UcWlUuTcswlCFUes0klWLokUoQ6gJzKDghHTJd65OV45ZAizkO9sgwfqEbpS rKTwLsnURtGynkDSVmfOTyMiaWdKuFjulBkvvF4/TWQMqodJqVn8WLWLQbE+BiGjVqnBtIoPWA9k nbty+crO3i6rlyucTrLrKHWVVOPACdRRQxjnMPHImMYREcn2gdEJYXKXuoyx3MsLboIUBMIbA2yS B1BZlO4oOADtJBI4rjqX6jTarZPp+mwPZwzqVuJpG/vBiLH9yhRtsaugVZcbtwLKDtNU1Dgp+Mwq HWOY51VDmAQMJhDtAA47u4BAxjnMf8XeBQIX0xOpTxjLBqr6YxjFKYxjFKYxjFKYxjFKYxjFKYxj FKmIcyYiYg9oiRQgjwA/hVIZM4eQH94hzF59w55AQHgclxjFK+3XbBIVibip+MOmSQhnzaQYqKJk V9Fy0XK4ROTvAewxFSAcpiiAkNyYvAiPO1nSX2ixlXsfA7VjioNDAk2LPNVFFRTEAAgGeAcROoTt 57jrAsocw9x1inMZUNReM1OqaJp2sRhb2AO6qyxTKSssW7ByjD4IB2sCp9xW80XqLVdAl7mn3BRG dWlt3AeCbbxh0PvjI3KVYA8GvWZRtzVmzMm72o2+MlGahSmI3K7SWKAG/F2GQObvSEefxAmKY888 G55HL1NLw1OmUXbVYqnHkzYU1Uz+A4MAKHSMXn/8eTcf/kPPGeOuAttlq7gjqvzknErJnA4CzdrI k5AQEO4hDgQ3nnkDFH8vI5mpq3r52rTjtm1lULaotApEjA5Aia5U+RKJjKplSVUOCYmBMouCJ9/C glFQoGyutQ6BvoAz6dcx3aAkiGYdqUDjADZKMf5oOParU036l6VeFI9YsXspDw1xbEyRZPksoAkA /USY+fevSSa6x4/+W1eG44/eKiT+ix8kG6NPkycfxOmH+45qPhftGdfuGBXss1OwMQE/iEPSIKgG UMRMRSat376SX4Mbk3otlPTIUqpgKkmqOdolvtENHEhnC8NMu3M2ZLllGOK9OJJrLm5KVNZ6u3as kCgYPTOo7XbkKUAWE4JCBxjR6f6hRgn7Lu+WCgiEsgJIGS65ULnyxIXBJzjGJavUvShjLrrFkFC7 tr3AWQjG7ARtrFjnhQuc8YrZq5ujwe4GzRukX2KZUx1Th+fACmXkPpwYP1+Xwl7JNLgIGfKJgPyQ ImiIfoZMhT/zMOaTCfaaT5nxzq1NEjIBMCaaR0+RKCgnKdT1SKqCYS9pBAiqYAUvjzwOdHtX2jV+ lUHBYCAZQjsxx9Fwsu4lUylA3PqIpuFUSs1DdpBAUkTCXz4+WZ8fRXUUjBWgiiU4y73EYUA48hCz HHuAprXN9QekIELJLLM4yAiWkzM2MeGkAUZzkEsAcHFbxJKaj2KSzmUkkUfTT9RY7hcDLFKAc9xi gPrCPH05H3+XI5gTujrz1pRTOoSrrOrNN9p0zqxQJCg1MUq6YAq+WMDVsdJyiCLhFIryQaqCcqkY QpgdF043Xe20dggojZLdJuGSqblM8aRwq3izpuO4yqSsc1BNmsZXyQFFm5zgChgFQpDqDloDnOoc x1DmOcw8mOcRMYw/UTDyIj+Yjkp0v6fwRMJdUuPuSMEW8G6OLPw8h9bj8lCePJBqG6x9UbqZGh0W 1+zByDdXO2SbGB/24lzHGfzZpPY4BFX13F1A33cbxQJyRO1g011lWkAyUWRj0yquTOPVdEMqoeSf mUEijh+7Ooqq49VdFNuC65T2IxjLCt7eC1hSC3iSGGMbUjjUKoH6D3PuTyTyTVWXNzcXk8lzdTST zytukllYu7H8ySeB4AHAHAAFMYxndXRTGMYpTGMYpTGMYpUwlOUCGMUxQOXvIIgIAcoGMQTEEQ/E UDkOTuDkAMQxeeSiAQABHwACIgAjwAcjwACYR8fIAAREfkACI+AyGMUqID+vn34H5fPJhOYS9veY S+Pwj7eOfzH258ePmPt85MYpUeePp/IB/qGQ55/+AD+mMYpQBEPYRD9PGP8Ajz+ny/v6eMYxSmMY xSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmMYxSmTEOchu4hjEMACAGIYSm4MUSmDkBA eDFESiHzKIgPgRyXGKVEBEOfYeQ48gA8B+XIDwP0EOBD5D5wIiIAHjxz7AAD549xAAEfbxyI8eeO ORyGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMUpjGMU pjGMUpjGMUpjGMUr/9k= --'ThIs-RaNdOm-StRiNg-/=_.958911314:-- From Mon Aug 28 03:11:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00338 for ; Mon, 28 Aug 2000 14:09:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:17 +0200 (MEST) Received: (qmail 27938 invoked by uid 0); 28 Aug 2000 00:08:37 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 28 Aug 2000 00:08:37 -0000 X-eGroups-Return: sentto-1101623-662-967421309-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 28 Aug 2000 00:08:35 -0000 Received: (qmail 31570 invoked from network); 28 Aug 2000 00:08:29 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 28 Aug 2000 00:08:29 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta1 with SMTP; 28 Aug 2000 00:08:28 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.10.2/8.10.2) with ESMTP id e7S08Lr28210 for ; Mon, 28 Aug 2000 02:08:22 +0200 (MET DST) Message-Id: <200008280008.e7S08Lr28210@essi.essi.fr> User-Agent: IMHO/0.98 (Webmail for Roxen) To: f-cpu@egroups.com From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 02:11:51 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] the small version also Content-Type: multipart/mixed; boundary="'ThIs-RaNdOm-StRiNg-/=_.235245678:" X-UIDL: 383da4bed550edafc138ab0eca6b2a57 Status: R X-Status: N --'ThIs-RaNdOm-StRiNg-/=_.235245678: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit we need also a small version for in the web pages of the ring.

--steve
--'ThIs-RaNdOm-StRiNg-/=_.235245678: Content-Length: 2454 MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg;name=logo-small.jpg Content-Disposition: attachment;filename=logo-small.jpg /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABHAFoDASIA AhEBAxEB/8QAHAAAAQUBAQEAAAAAAAAAAAAAAAMEBQYHAgEI/8QANRAAAgEDAQUGBQMDBQAAAAAA AQIDAAQRBQYSEyExM0FRYXGRBxQiUoEyofAVI7FCQ1Niwf/EABoBAAIDAQEAAAAAAAAAAAAAAAIE AQMFBgD/xAAtEQABAwIDBgUFAQAAAAAAAAABAAIRAwQSITEFBhNBUZEUcbHB4RUiMqHRYf/aAAwD AQACEQMRAD8AweaaRZnAcgZpPjy/8je9e3Hbv60lT1zc1hXeA86nmeqFrRASnGk+9qUg49zPHDGz F3YKBmk4oJZ23Yo2dvBRmr1sjsbfcQ6lcIihVPCQnmWPf5Uq+7qtEl57lWMp4jopKw+HSz2ivLdy Biu8WL4A8/IUld/DG5Cb9lq0cg8N4N+4rQ7YEQQ5jXCbrbm9yJHceX8xUjdXkdxGAtpHG/LLA8x5 dKzztC8DxDzHmmjRZMYV876vpWpaJPwrsMAejDoajfmJfvPvWwbebs+gyRmzlkkzlCqb273ZyKxx kZGKsCCO40/Svbhwzee5S1Wk1pyXfzEv3n3o+Yl+8+9O7PRNQv4+Jb25ZM43s4FF7ouoWALT27BB /qHMUfjK0xxD3KDh5TCafMS/efepFHJRT5VE1KJ2a+groNhXFVzn4nE6c1TVAyTC47d/Wn+k6Hc6 rICuI4AwDSt0z4DxJ7gKZOjS3hRRlmbAFa7s3ocdobMSqTJGhdUJ/QOmT5k5/A9a52+fhrP8z6pm izEE+2f2WtNKtlZoRxTzw2Du+vif4KsIGBgV73UVlEyZT4ECEUUUVCleEBhgjINQmr7LadqtrLHw VhlcdoijOfOpyg1IJGiggHVQmhaS+n6W0Bti8sWEQKMk55A58KkLnR2miaPUbREJJAK94/hp6jtG wZCQw6EU11fULiOzaWOMMygkBV7zzJ5d9AcZfI0URCwfaLTk0rXruzjJKRv9OfA866Qf219BTbVr me81S4uLhSsruSQ3UU6Ts19BXcbtCXPnoPdZNxrkn+zVqjao927IWibEaFhzbx/HWtW0iAWrb87k 3VyN4gnoB0GPzWM6PdJZbQQzykcNXO/n7cc61LZrU4toNTuNQViQi7iqRjd5n/yuYvweO8/6fVPW 5GEBWyiuI5ElXfRgy5IyPI4rukE0vK9pBjO11uJkLujdIXOTnv8A2pbEiSFJEwy8iQcjNROcLy9r l3WNGd2CqoySTgAV3nFI3KRy2sscqb8bIQyjvGOlSoXltcw3cCzQOHjbOGHfSp58u6qRDtTpdnqS iWxu7bgpwFJwVxn/ADVqtNWs723eeGYFEIDk8t3PjROYQha8FU74gbMRz2X9StIwJov1qo/UKoKd mvoK3a6RZbKVWwVZD/isLIAJA6Cuu3UcS6oPL3SF80AgqKm7Z/WrJsztImiW9xB9Y4+PrAzu/iq3 N2z+tJ1jXTQ6q8HqfVepuLYIW76FqNmmkQB5kjfnlWODnNTUciSoHRgynoRWI7PbUNpMhW4TixMM dASPerxpm2NveOpW4EIPLcI5Y9O6s19NzSnmVGuVsl1WOGQcPDsp/GRUhI6zNxo2DJISwIP7VSmj WeARrNvKOW8h60/066k02EwxANCTkq2Tz8aULodK6B2yg+i11E5x3VjrzvrqIxzKCsiq5UMI3PM+ ldiCU4wjHPTAoxUaeawyIMFQuq6BZ6soE29G28GLR4BOPHIpxBpVna2cltBCERxhznLNy6k9Salh ZvjMjLGP+3WoLXdds7W2e2juOEv+9MeXIdw8T5Ci4mL7RmhgAyorUdbTS9k7pmcNLHmCPn1J5D+e VZYvNFPlTnabXU1W5ENqpjs4j9IJ5sfE01QjcXr0FdnuuMBqTzj3WbePDiITKW3kaViByJ8a4+Vl 8B70UU8/Y1u55cScz1+FSKhhHysvgPevRbzKcryPkaKKH6JbdT3+F7iFP4NQ1W2ULHO2B0BOamLL a/VrYjiwwXAH3jnRRQnYNodZ/X8Vrbqqz8SrBb/EeRLfhTaakqAfQGOSvoetct8Sr1IgsFoseDkB WxRRVR3ZsJmD3+FHi6ihL/bTW71WXeKhuuXzVdupr+9beuJWkPm3SiirRsC0bpP6/iE13u1TcWkp 7h71IKuFA8qKK0LaxpWedOc+qqc4u1X/2Q== --'ThIs-RaNdOm-StRiNg-/=_.235245678:-- From Yann Guidon Mon Aug 28 07:05:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00341 for ; Mon, 28 Aug 2000 14:09:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:17 +0200 (MEST) Received: (qmail 16118 invoked by uid 0); 28 Aug 2000 05:05:23 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 28 Aug 2000 05:05:23 -0000 X-eGroups-Return: sentto-1101623-663-967439117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 28 Aug 2000 05:05:21 -0000 Received: (qmail 8489 invoked from network); 28 Aug 2000 05:05:16 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 28 Aug 2000 05:05:16 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 28 Aug 2000 05:05:16 -0000 Received: from f-cpu.org (nas3-104.aub.club-internet.fr [195.36.145.104]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA27666 for ; Mon, 28 Aug 2000 07:05:11 +0200 (MET DST) Message-ID: <39A9F302.E9465D02@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 07:05:06 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] webring artwork Content-Type: multipart/mixed; boundary="------------84D3DE973AB7BF462B78CD52" X-UIDL: 5724f69cb550071382f01ec4dac6899a Status: R X-Status: N --------------84D3DE973AB7BF462B78CD52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello,

i played a bit with AMAPI and made those two pictures.
a third will follow soon (a chip).

the first picture (webring1.gif) will point to the precedent
site of the ring, the seconf (webring2.gif) will point to the main site
and the third will point to the next.
they are designed to be displayed on a white background,
i can change this if needed. transparency color is white too.

my first idea was to have a candle, a light bulb and a laser.
other similar ideas are welcome :-)
i'll try to make a nice HTML artwork as well.

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
--------------84D3DE973AB7BF462B78CD52 Content-Type: image/gif; name="webring2.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring2.gif" R0lGODlhagBoAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8AAAAAUFBQoKCg8P DxERERISEhUVFRcXFxgYGBoaGhsbGxwcHB0dHR4eHiAgICEhISIiIiMjIyQkJCUlJSYmJicn JygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDExMTIyMjMzMzQ0NDU1NTY2Njc3Nzg4ODk5 OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkNDQ0REREVFRUZGRkdHR0hISElJSUpKSktL S0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVVVVZWVldXV1hYWFlZWVpaWltbW1xcXF1d XV5eXl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdnZ2hoaGlpaWpqamtra2xsbG1tbW5ubm9v b3BwcHFxcXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5eXp6ent7e3x8fH19fX5+fn9/f4CAgIGB gYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouLi4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOT k5SUlJWVlZaWlpeXl5iYmJmZmZqampubm5ycnJ2dnZ6enp+fn6CgoKGhoaKioqOjo6SkpKWl paampqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+vr7CwsLGxsbKysrOzs7W1tba2tre3t7i4 uLm5ubq6uru7u729vb6+vr+/v8DAwMHBwcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvL y8zMzM3Nzc7Ozs/Pz9DQ0NHR0dLS0tPT09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d 3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v 7/Dw8PHx8fLy8vPz8/T09PX19fb29vf39/j4+Pn5+fr6+vv7+/z8/P39/f7+/v/////78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAEAAPUALAAAAABqAGgAAAj+AOsJHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIDnSq0cv3ruT7+DNC8ly40p3qshkYcKkyRIr a1qRbMkz4sh6u7KsGAIFSpSjUaRIMRJE2c6eUBXKO2ADyRMpSadoVUqFyhQrRzRFHXvQ2hYg RrFK0bp1ilcqVq744PSUbNRFLKAoPbqWrZS3bq1k8bLiQF27LLchWcJX7VauXd9WyQKGCotX iFmOLCakSVKlWLciedvVbZUqWsCA6SFi2s/MIuvxkqEW9OcpWCpocUu6ChUtYc4oySECHWyP koQg3Zu0yRQpVVxgKU3l9OktY9hI+WFDBLfjGUf+5sqRFnSWJVNGcLmCRUMWydarcDHzxoqR HjNiHAY/ERltvUpNscMLLhhhAg4ZrEDCbr6dVp0VXrAhx0xF+FADEPxZNA0QUZQnxRJQUPGC EhtogcUU7lGxhG8PXhEGHXFsEcUSRfQAgwuCTCKLNutk+BAPnjUWhRBT6PDDEyW8Z4UOWEBQ BQlRVGEFamXs8cYWVTyhBBEDunAFFE6AkYhAr/lI0Eh5gCjkX0UocaIHW1jhhBc0cMFFXlNW 4QUcf7DRxXtQbMmDCzNoRYUUSQCzn5n1gDNDY6FNEUURTvBAhA5IsGCDDkVcAYMWUk5Ghh99 pPHFn1VAkcQQPLAAwxL+f1WhhCqL+rhEE7VlNUUKNMighBRaKEFFETdY0QMVV1ihbBdvFILH GWKAwcV0TiQhRA4spMBEdb7dUit4sRyRa19TxNBEDjW4wEMRt16xxQ5XlPAEamQMEsgcZ5Qh xhfTUvGEtTqosIITVyR7QzGMDrSEE7aB9lwVTCDhhQlYOUEFGACUUAMXcY1hhyJ7uJEGGvry O92/Qeiwwg/suQuDcSX5CA0NkGqFBQtJMCFCFU0wUUVnVxzhQRNYnNYFG4gQUkcba6SR775b nOjEEUHYYIN8WFwRRBb1wNHFt2Pl4ZljUlzRAhQwBKEFFzJc8UMLOgSRBJZTbmFGIYrwAYf+ G2w0fQYZUF8xhRNIAIFDFNJigegRVgBhB9hQXfFEY26tQMSM/l7gBRI3tBCnslNqMcYfjQhS Bxx7M+004PwKPnUQUpThRRZTKntECuMcNxIMt7HlBBY7QFEFCFd08MIU1ilbBRYeO2KIHnPE EUfqfpMRxhdbXCFFE0dQgUYYWVxx2pcqmAOeNYeT+9wULUjBBRMOtD3dacpjEcYdjiCyBx1z yCHH9HyrXhi8oAXtMWELbBhDAbHABS98oQbkAE8ihKC+vyShCUm4wBG4UB1u5UkLYsBfIvpQ Bzrwr38AVF2+BhgnKYgBDmTQArK8YKc2xAM8lFBOX9ZiBRBswAr+yHMQ/U4jujo0IhF+sIMJ SzgHFFJvdQMsoBrkEEMqMGEKc/iGPCDHE06gZS19ocIQTsQtD0qJC2XoQyMOwQcl1uGNTHSi G1RnBut14QtymIMYspCqx/lIGjUAEGl4I8Q8ZSEMahjEIgahB/7BsYQmbKIcUDfH6oEhDXmQ wxewAES6ZGgkOpgcb+ATnypcgQthmEMhDvEHPDTRhHQooSxP+D/qoeFvcuhDG6alBSvwglFe MApbCBmZuGzhkn4whCAyCYc45HEOkLSDHWYpR6ahYQ188IMZtrAFjnXDTPSwhgigYJr4xEUL XghDGvAQiCTGoQ1teEMzn7lEaVKzlnP+VAMeBHEHMGThC14AQ8LqQYcfQCcuWMiCFrbQBTGs gQ56yEMd3tA0NbAhntKbgyPrIM1pvpF/+IRDIAbhhi1kIYaYYdRIcgADKDAwoGRAQxucSdE6 joEMZ0CDRePZzFfGsqPTjGQt96A/MWChDGQoQzzKlKGV/CAEmCqbnbrAhS1oQaFc+IIYypDT NbTBDW+QXh7r2VFI9i8PhyDELrtAMkww1Ucj0UAGeMUDIRhhMU4I0RXQCYatniENXnVDM+Og 0TcCNah0sAMhFoEHMFxBDWm4QjoGOpB5tGMCFRiBCmSQAx8MIWd63UI6x8BVwH51noXlaFmn KQhGDOIM2GH+gxr+YAkuwmYkIrCACFYgAxz4gAhIaEKIsMBQMNwUDYBlg2CdqdGf2tMOf2DE Ia7EhTf0DROViMQ73sooB2BgBC2YQQ6AQIQkOCFKxB2tGZCrXMH6L5aJtacfFLEIO4QBC294 QxmQUQ9RdEIs3PVRNhiwgRKwgAZGKq9nlreFL4SBDGY4g0XBCoexxvKNfFCEI/gwhsfmVxE7 YYQlRmHb40hgAyM4sA6AUATzRikLon3wencqT/8Vlg+LaMQfYliGSaZhJyN5xCZgUeLMhAMA BXYBDXYQhDYxTDBZFQOE0zDhsD6zD4hwBCDQkJpaVsMge/AEKopsF3jQoAEdMIH+C2rAgyAY QQlXgbJWcUrlr1qZD4lwxB/OAMLorUEUBqEHO/KgCUUFGDzuIMIRHNCBEqyZyW+O89rm3NWv zmG+IFPgi+LAhkKUYhj7oQchMiEMMkfFHUSxwQM4cIIX2KDNRljCE6aw1y4Yl6tqeCggEmGI OsgkDNKDQyigwYlMiOOt2NADJ5JB2XrgQApMyAAEPIACV/dACEdgAjlr3dcyrKEOgkCEIN7w hSuUIQ5vOAOJ66EMSmjiGgeJxiIoAQ7K0kEKT/BBBKZ9AhjcoK5HABGttdCFMbxhD4MYhB22 mQU1vMENZiAyPUZyi0lUIoJMFUYiKPHNhPlCKUzYwQb+KEDtGNigB0NAgrb1lIY59OEPemAD GKzKhou64ZcF0YUmFMGOiRfkAJSIxDl8/kl1WMErThhCDE5gAhZwNghHgMIWyPAGPOwBD20Y A8cQuQY2iMESTjlTPUjh7kW54hKLGCgwklAaKDBBCTmLAha+cAY35PENaQCDieyW0zEgAhuI eEQw6jISUGgiEfAo00hEMQlKTBau9biEaZRF3C48OKdoMIMYunDVuUu5DGVQVD3U4YhGeOMg jOgEXRRfD1RwAhMqrQchQMeeLEyVhlbNQtZsH1AqPKJHPo8GIDAB79eMBBCdIDHrG4GJS5ha M/WYgwp+kwXdV7/6vjnK8qz+EAVGmM/49aCGuLdB+HokghOrOMxKIpEJWh2aLCPBAwQ+UAMf JMEIRhgCi1V+FSo4wh0KAQyOUAnnUBAjoQefMGashwibkAqxZwxjsAAVAAIvUAM5wAPoggN9 QAyPlxAj8QuKoAjpsBIEMQ590Am5cBgj8QaYkILvlxkHkAl08HKNQAvk9xAj8QqXQAnvcBCC oAm1oH7wkAiScAzP12wHcQqVoAjwYIDiIAicMHhMpQ6ERgxIeBEjcQmb8An1QIIDIQ3zhg0G WA/eEAiX8B0veIULUQmc0AgHoQyLYAnNcBDHQAiNkDtqSBFZuAmlsEVnYgyPMAloWBDOoAiY IA7+eVgR8qAIhrcftUAJklCAYicLkAAJR5iII+EImcAK5TcLkBAJ7HAQqxAJknBDiSgR9NAO h9AJpuCFO9EKmXAIPSJ2qXAJnNCDpygR7RCHujCGWgh7BwEJmuAIl5iH9OAOf5AJhgF+nnAJ tcV67kYKxaiG84AOjsAIUjgQIzEJnOAJKigPkIAJ7peLEaEOgKAJ0DCGhtCNi/IHDUiOPpEN hGAI0VAXKxEImrCMBDEP70AIl4AwaQiPA+ENkNAIiMhUDKiA+/gOhRAJvzCNSDgSy5AIi1AO YkcOcZAJxrAf6TAInABvAtkQElkIkjBZZUIOhzAJVgh+05AHhPANEHn+hbUwCYXQDgYxDj/4 DAehDYhwCBYZkgwxEriQel2ojfUQDYRgCdXAer7QB5CgEkC5ECNRCpXQCO3AVMAQhx1nlLFA CHwQk1f4CZUQCgchDI9ACadnEKBgCIZgilHpgfWACJwgCkS3E6WACZOwDqxnCIRQCGBJWSMh CZUAaODHCpkgCQiBCINwCH85UCOxCJkACgZID5iACZKgDmNIB3sAewEZkuvQB5UwjgQRCp6Q CfvhDm2QB5Pwlg0hCJLggGKnCJmwegZxBnNAZKzpge1QB4vAieB3CZqgfPu4DnMwDbm5EOOA B4bQCwfhB57AhQZxQ50ZleeQBn/wkPs4D4iTYAlBOJ3HKRDz8A17wwyHoQ6FwAiz0JjwSA1f RQ1iFw96IAnk+Z0SwQxfMAdpSSb1UA1xIAgb6Z3HKZFfkAcHEQ56IAhiCKDfGQ2hOIbC0AaD 4J70iYNwqQuaOXQTqhGfMAdu0IQZioX1kApwgAdX+aEWMRKGEAdmYKIgighfEHYsWhH8GKM0 WqM2eqM4mqOUFRAAADs= --------------84D3DE973AB7BF462B78CD52 Content-Type: image/gif; name="webring1.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring1.gif" R0lGODlhLwBNAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8DEpKRAQCBgYECEh ECEhGCkhGCkpGCkpITEpGDEpITEpKTExGDExITExKTExMTkxGDkxITkxKTkxMTk5ITk5KTk5 MTk5OUI5IUI5KUI5MUJCKUJCMUJCOUJCQkpCIUpCMUpCOUpKKUpKMUpKOVJKKVJKMVJKOVJK QlJSOVJSQlpaQlpaSmNaSmNjQmNjSmNjUmNjY2NrUmtjSmtjUmtrSmtrUmtrWmtzWmtzY3Nr UnNrWnNzUnNzWnNzY3Nzc3N7Y3N7a3OEa3tzWntzY3t7Y3t7a3t7e3uEa3uEc4R7Y4R7a4SE a4SEc4SEhIyEa4yEc4yMc4yMe4yMjJSMc5SMe5SUe5SUhJSUjJSUlJyUe5yUhJychJycjJyc nKWcjKWljKWllKWlpa2llK2tlK2tnLWtnLW1nLW1pbW1rb21pb21rb29rb29tca9rca9tcbG tcbGvcbGxs7Gtc7Gvc7Ovc7OxtbOxtbWxtbWztbW1t7Wzt7e1t7e3ufn3ufn5+/n5+/v5+/v 7/f37/f39//39///9/////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAEAAJAALAAAAAAvAE0AAAj+ACEJHEiwoMGD CBMqXMiwocOHECNKnEixosRDFjMiUiMnY8U/VsbU6RPIkEeHieqgmeKkSpUuYNj4OakwD5oq RnLm7MHDiRc7NA/W8VLkx5EoUqIkAYKjx48sdYIS7OPlRw8gSZBKWZoDR9MteqRCapSGSA4e O44sWaKEKw8cNoiUMRnUTxavPXIEOdJWyI4eOHLYwNEkjtQ4TeCe3RFESBAgTLsOtuHlT1Ay P2x0zXEVyOMckuHiOOKGpiEvgQeD/rEDyN+uogeDEXRSkJXJinP8yLEDtOLJR6J6zEMl9mbe eVPDrdHUTCOPdhIzn3wctg3cNrbQzkjniPHUvjf+Tx58hI5HOkmwB17vG3cNG0DUnPd+HUcN wV0BwxY8IYJXMIhklEcT6h0H2AweMLDAAgC8lYVlFuXxBFwmeKWZCA4syOCCACwIlxN4ZPRH cThkqCGHGnbIIWBNlGZRIXfZMMKGKm6Y4oKD9VCGIxYh8sVkKNpIo4Ye8JDDGHRVhFlXQgpZ IwAPnKUFIBmpQcRbNwapJQ89TBGWRXQ40dSTN5LZgw9OGBYhFVxa4OSJNS7Aww9MsJGRIFqc CUOWTXYIAA09DIGGIhYdQoYPTr2JYo0XDOHDGIVkhAYRPgzBZ5w2DjGEFn1kBEcTlSpqY408 DFHFHRnVgUWgJpKpJQD+mjrxRkZ2OZqCoq7+oGkaGRVCxhA/8MDnqwuk4GgZiVi0SBqaWkqm qws4oGsX21XUBhOODusqrDxU0SmYUwAr6pvBTqFmRX1UUekExLrKpRF2WiTIF3PKAOeJTtLA pRmMWJRIGXMK+yyfG+DAwxdJUjQpooveiyIDgWHxZUVxMAEYvqJ2+KFwFdUxxVkZ+nmphuTN alEfVrw1o8Nv5mhGr6jBNSSxC5YgW4AVLWIGD4Ox7KoDNtTwYJVE9BwntAB4YB8VE1MUxxHX NUwsA9fVcMS5FEkYdAQ+M3CBBzQEHfQP8ln0x13v0WhBCzWIAIEH783QQtD3gfFcRYh48V7+ DTXIYAMLNcQQtAcQpCD23O9tkfBEZvTAHA0x1KBBDWCrIEMNJcBdgwU10FCDFVRa5AYQdMNQ wwY1sBA04iWIIALcQVMBlEVyNMG3DXNb8IENEXSgge8hRJCBBRCMUIMTs1ekhxVhB97C7x2g YIELL4TgAfEORBB0E3lkdMgWQc/QgQUPkCBCBxNYYEEEDrRfwgNwVZF8RY3bkP0D7LfP/gS8 sfCACg7wihUgBCbv1CACEGiAA3rQGghEIAlHAAIESuAAE/CADBjJyCC2ABcEPsABRkiCFBzw gLYUIXsO8EAV5kATNxyBB++7gLRy8sEiaOp+F2BDBj0CCDAAxgGg72uBpi7gH0c5QAEs+EC/ gnKHLzRhghEgAbBYMAEcTOELMfgAGE4gFkjk4Q0XEMEFLNCFLpDhAi24QyD2cIJ7gICAUlFB CUBwAUEI4hAnAMFAToCEE4ihi5DABwZOgIE96lEgJ0jkIcWyBxBwAQTbAQEXEZlIfAASEifg wgmuIBAoTBISOvgkIPl4gjMIRBAnWMQlESIGnK3ylbCM5UkCAgA7 --------------84D3DE973AB7BF462B78CD52-- From Yann Guidon Mon Aug 28 07:08:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00344 for ; Mon, 28 Aug 2000 14:09:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:19 +0200 (MEST) Received: (qmail 24363 invoked by uid 0); 28 Aug 2000 05:09:06 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 28 Aug 2000 05:09:06 -0000 X-eGroups-Return: sentto-1101623-664-967439327-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 28 Aug 2000 05:09:05 -0000 Received: (qmail 14587 invoked from network); 28 Aug 2000 05:08:47 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 28 Aug 2000 05:08:47 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 28 Aug 2000 05:08:46 -0000 Received: from f-cpu.org (nas3-104.aub.club-internet.fr [195.36.145.104]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA16051 for ; Mon, 28 Aug 2000 07:08:44 +0200 (MET DST) Message-ID: <39A9F3D7.84B979A6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008280008.e7S08Lr28210@essi.essi.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 07:08:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the small version also Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 22348837355cfb05375a58ce6bed0293 Status: R X-Status: N MDR :-D

well, i didn't think about this one ;-D

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From Jamil Khatib Mon Aug 28 07:57:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00347 for ; Mon, 28 Aug 2000 14:09:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:20 +0200 (MEST) Received: (qmail 22808 invoked by uid 0); 28 Aug 2000 05:47:07 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 28 Aug 2000 05:47:07 -0000 X-eGroups-Return: sentto-1101623-665-967441621-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 28 Aug 2000 05:47:02 -0000 Received: (qmail 21618 invoked from network); 28 Aug 2000 05:47:01 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 28 Aug 2000 05:47:01 -0000 Received: from unknown (HELO web1105.mail.yahoo.com) (128.11.23.125) by mta3 with SMTP; 28 Aug 2000 05:47:01 -0000 Message-ID: <20000828055715.9499.qmail@web1105.mail.yahoo.com> Received: from [199.203.98.250] by web1105.mail.yahoo.com; Sun, 27 Aug 2000 22:57:14 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 27 Aug 2000 22:57:14 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring artwork Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: b1e70f177924bad7548b1c110977e501 Status: R X-Status: N Hi How can we join the webring? --- Yann Guidon wrote: > hello, > > i played a bit with AMAPI and made those two > pictures. > a third will follow soon (a chip). > > the first picture (webring1.gif) will point to the > precedent > site of the ring, the seconf (webring2.gif) will > point to the main site > and the third will point to the next. > they are designed to be displayed on a white > background, > i can change this if needed. transparency color is > white too. > > my first idea was to have a candle, a light bulb and > a laser. > other similar ideas are welcome :-) > i'll try to make a nice HTML artwork as well. > > have fun, > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Moi qui pensait que dans le libre y avait pas trop > de cyber-neuneus." > F. Couchet, APRIL.org, 8/18/2000 (contre les > portails à la con) > -------------------------- eGroups Sponsor > > > > ATTACHMENT part 2 image/gif name=webring2.gif > ATTACHMENT part 3 image/gif name=webring1.gif __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! Apply NOW! http://click.egroups.com/1/7872/1/_/3462/_/967441621/ ---------------------------------------------------------------------_-> From EE Times Mon Aug 28 07:56:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00350 for ; Mon, 28 Aug 2000 14:09:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:20 +0200 (MEST) Received: (qmail 23391 invoked by uid 0); 28 Aug 2000 05:56:53 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 28 Aug 2000 05:56:53 -0000 X-eGroups-Return: sentto-1101623-666-967442207-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 28 Aug 2000 05:56:52 -0000 Received: (qmail 5032 invoked from network); 28 Aug 2000 05:56:46 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 28 Aug 2000 05:56:46 -0000 Received: from unknown (HELO cmpweb-dns0.web.cerf.net) (192.215.71.99) by mta3 with SMTP; 28 Aug 2000 05:56:46 -0000 Received: from cmpweb-prod9.web.cerf.net (cmpweb-prod9.web.cerf.net [192.215.71.79]) by cmpweb-dns0.web.cerf.net (8.9.3/8.9.3) with ESMTP id WAA23195 for ; Sun, 27 Aug 2000 22:56:45 -0700 (PDT) Received: (from webuser@localhost) by cmpweb-prod9.web.cerf.net (8.8.8+Sun/8.8.8) id WAA19399 for f-cpu@egroups.com; Sun, 27 Aug 2000 22:56:32 -0700 (PDT) Message-Id: <200008280556.WAA19399@cmpweb-prod9.web.cerf.net> To: f-cpu@egroups.com X-eGroups-From: EE Times From: EE Times MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 27 Aug 2000 22:56:32 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Fast processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd9dbe2daf5ee68b1b1e242ff62aecaf Status: R X-Status: N This article from http://www.eet.com was sent to you by khatib@ieee.org

khatib@ieee.org says:

Intel showcases Pentium 4
http://www.eet.com/story/OEG20000825S0030

SAN JOSE, Calif. &#151; Intel Corp. took the wraps off its upcoming
Pentium 4 microprocessor at the Intel Developer Forum this week. In a
"gas pedal" demonstration, senior vice president Albert Yu showcased
a Pentium 4 running at just over 2 GHz, though the speed at
introduction this fall will be 1.4 GHz. But analysts said the chip
could face a slow ramp, because it is initially tied to still-pricey
Rambus memories.

With a pipeline twice as long as its predecessor's and a 400-MHz
front-side bus, Pentium 4 promises to deliver performance aplenty. It
is based on a completely new architecture, called NetBurst, which
supports data transfers over networks.The chip set for the device
&#151; the 850, or Tehama &#151; supports a dual-channel Rambus
technology with bandwidth of up to 3.2 Gbytes/second. 

The Pentium 4 "is based on a good architecture, but it's too bad it
is bogged down by the whole Rambus issue," said Janet Ramkissoon, an
analyst at Quadra Capital. "It is an economic issue, because the
Rambus modules can cost as much as four times as much [as SDRAM
modules]."

The device is based on a 20-stage pipeline, twice the depth of the
10-stage pipeline in the Pentium III. To keep all these stages busy,
Intel has enhanced the branch prediction capability and created a
speculative execution engine that can juggle up to 126 instructions
simultaneously, three times as many as the Pentium III can work on at
once.

The design's 400-MHz front-side bus &#151; three times as fast as the
133-MHz bus on the Pentium III &#151; is said to be "very scalable,"
and Intel expects to ship Pentium 4s with even faster bus speeds.

The first iteration, code-named Willamette, is due for launch next
quarter. Built in an 0.18-micron process, it packs some 42 million
transistors. Though Intel did not disclose the die size, analysts
said the transistor count could make the Pentium 4 a full 50 percent
bigger than the most complex Pentium IIIs, with 28 million
transistors.

Pricing also has not been released, but the current flagship MPU, the
1.13-GHz Pentium III, is priced above $900, and Willamette will be
the same ballpark. In July, Intel posted on its Web site benchmarks
for identical Pentium III systems, one with the Rambus 820 chip set
and another with the 815 chip set, which supports PC133 DRAMs. The
two finished in a dead heat.

Those benchmarks "were not the kind of news we wanted to hear," said
Avo Kanadjian, marketing manager at Rambus Inc. (Mountain View,
Calif.). "But please remember that the 815 chip set has been
optimized over five generations, and the 820 has not gone through
that kind of tuning process. But with the Pentium 4, we have two
Rambus channels, and the 850 chip set draws upon the very successful
840 dual-channel chip set for the workstation space."

With demand low, memory vendors have not been producing RDRAM chips
in high volumes. "The Willamette can't be supported by the volume of
RDRAM chips that we are forecasting," said Tony Massimini, chief of
technology for Semico Research Corp. (Phoenix). "The only way that
processor will ramp is with a chip set that links it to SDRAM."

Intel said last month it would develop a chip set for Willamette that
supports PC133 SDRAM, for release in late 2001. The company is also
evaluating whether to create a second chip set to support the faster,
double-data-rate DRAM.

Additional reporting by David Lammers.

For more technology news, visit http://www.eet.com
From Yann Guidon Mon Aug 28 10:55:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00365 for ; Mon, 28 Aug 2000 14:09:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:23 +0200 (MEST) Received: (qmail 28480 invoked by uid 0); 28 Aug 2000 08:56:00 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 28 Aug 2000 08:56:00 -0000 X-eGroups-Return: sentto-1101623-667-967452957-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 28 Aug 2000 08:55:59 -0000 Received: (qmail 4009 invoked from network); 28 Aug 2000 08:55:56 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 28 Aug 2000 08:55:56 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 28 Aug 2000 08:55:56 -0000 Received: from f-cpu.org (nas3-96.aub.club-internet.fr [195.36.145.96]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA00411 for ; Mon, 28 Aug 2000 10:55:45 +0200 (MET DST) Message-ID: <39AA290A.14FA8648@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 10:55:38 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] utopia computing webring artwork Content-Type: multipart/mixed; boundary="------------9C0D06E261A53DE9D403BFD5" X-UIDL: 42c190e3a3faaf54896939db5d8f7d5e Status: R X-Status: N --------------9C0D06E261A53DE9D403BFD5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello again :-)

there i have the HTML and all the GIF/JPG
that are needed to make a nice jumpstation :-)

i have included them into a little ZIP.
It is free for download and editing
as necessary but the (C) remains.
Of course you'll have to edit the links
into the HTML source.
Enjoy :-D

i'll ask Bellamy about the bear's artwork
but the website would better be running a bit
so we can make our mind and see if it's worth it.

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
--------------9C0D06E261A53DE9D403BFD5 Content-Type: application/x-zip-compressed; name="webring_toolkit.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring_toolkit.zip" UEsDBBQAAgAIAEGYYSjjxI8hih0AANceAAASAAAAZi1jcHUvYmFja2duZDIuanBnnZd7WJLZ +vcXPAioCB6oIBEpmEA7jKaToJJgOxVKPNVMu3EaUmfUptwcLBXTQMuZ3IR4qMwhosRD7WlG Z6x0mxN2EK08pO4ytSKhCE3L1Eyz+jm/6z388/7xvu99rb+eta7nWp9rfe/7/t6fBj6ZgDM/ jBcGYDAYfAd8BwCfhsAmgICgv9Zi2Nkh7FCOKBQSicI6OKAdnbEuLs5YZ5wrfvlSVzeCG855 qecygru7h4eHy1LKSk/SyuUkD9JfP4HZ2dmhkCgnFMqJ5OrsSvp/jk8G4IKGOYJ3EGwlgLvA IBfYp5vAEwCYHey/A/yPgMEhhB0ShbZ3cFw8cMkZwGEQBEdAi3dHLO7mLO4DhIud6wpfLtIt ZjdqpRi/XlF8Fk0NrW9dEnvvNc0vQZJn77B0GYG4/LNVdIaXt/8XGwKYrMBNf9scFh7B48dt 2/7lVzv+vjMx6bvvk1NS90jT9x/IyMyS5R8+UvDjT0cLS0rLjp84WX6q4lylvqq6pvb8hd// aLh0+Upj07+v37h5q83Y3nG7t6//P/cfDDwcfDpitjx7bn1hG518MzU983b23dz8X1wwAMH+ Z/wfuVwWueAIBIRA/cUFg2f8dcAFYbfCF+nKjUHtFrutXK9A40OLz9a32lP9Yl8vSZDcc1hK 83/62eRfaP9N9n8Hlvf/Rfa/wP431yDAQLDFx4NcQAiYOufbTsdP5I6RigdP077b4NYwEX0D xdR3s4zMV/f/faKm+gsRQFXnMG4kN95CaPU92DCktHtXmUGSsQYrK4rj5Xd9feYiY6j10YPH SqUEdwnABLCF+kgW1Ed9UxksFGqv5wUkkcQcx5IBD9zW6SrYgRna+zhxvnLCesW/8oqnHA9M vI62ZZdRsg0LeusV8rSi8eUyUg+nixufqBvfCjEHw1nmYn7Q1IMSuxUGSjr9flHzsAOIrMlg rX5C6v0wsgOm6JipLmgfZRgfW4nmi4DSTlFKnJiQ0vR6PdvGhLQ1l4I0Bx8ar2zioDkvsloX GCjg0v1ripHVbpjREwQGVQN4uS9Hj9vFoG1AHUyuELz/nRf8JrWjlZ4m8QlYDn5goPIfPC5L I5g06XoqNV+jIc3g5QtN1kkdSogN8x2/n3dV9n1xbpxWrELP1CSz2OInl4C/KdvaWDUYzsbF R9doMLOVc6rAKY7TjDHeFFsUby4Nf0TwCN8Zqi++lxPFB7Gir9mReOdvWt5LNwMKRSuTuW1Z 2KwIORJ+rEYj7atQFyDyVRIfL7APkUzc2A+HMTtXudd204On8Wm38wKVPUBgzmN5+AlCMvOc fHcsCWpK5M8Nfg3c5nrgpCRY30wVrfR4O8rfpxsx+bAldZs6wDlkuXBVREyh5DL+EH9PXqhm ckjbIMSuR3/cBmqqc7+92YO7DRvN6kSf/f2mGa85wiLuneTA1p6+djxQwGx9pEnEn251b8ny vzrRtT5q43M50tCFxIkHKzJbCfiR7Y3jY+9ifR+ppcaaPSD2NhIuD2fN6p+V4fibGizzykLf 0tkC3zGOg1+DRsVqrdq6r3tRVgzHI8EzTH0HIKP2RsNdZXC/V4NlcPSdJNwmAXTm56ZW42/v YpPeXv/VV5kgd0EGkM/l2QcnVzmIhj9u00ubPY8D+uVwkpTPZVrSLdHL1mTPBr/Vj/qgaftR VQBozjxPYZKKriuOGEZxexzWZVJRZxY/l1LTacpeZbGqwRXdPmvjNWuv1r8IdABohOvGF+ax zaSaQ7Xnyn/qghEs6cG9GlV4rpe75+ceLFvY0671Am8k61v3JtPM84prvtTf+ip2CTJEnAVb DdBWoi76LFP0IRSPj3dNaKDBw3M7XB5UBxXGnLBSkkROwFvd1UQkvfbyLVn/RP6CAVRPzJz3 SrasB3ARICzHb0uevdnjmGd23+uqx+61FnGFcKWFpKrszZM87DB+W+WtuKKx9t1XCzHqASN5 GuDKhGc+XsLwJnC6KmO8a2rliowEOX53JiWJjNu5qyXcdl91YMlcFMtfOnu0DWfloKMgiP3v 2OL2OZEsQVWOKIk6q6evEUWZOUhJoCiLoJvqlxzi8pE9m6ASJl5eNyweWkxVEzlQFRiXSeh+ xnUv13JnqwjxGA05a5yDclJKjKXasqvwqIOwyK5h06TyQwpdU0s0FwLRPyKvBTzbOsoFr7Pj WoOuP43qj4a9r6pr6saDU4hf7R896S3DJKn52saxrVYNVMSNdebMFaB2gtDDxxOI+Df2BFQF 6HJH5KT+0vUUWhoUTqSZZNsOlzhDBS/CuQYd+vbxtQ2m/PzSzau1kqDZV+/ubUVSnZHZy6Na xjSm2Mt+aizLUNW+1jC7hLLCfDmqsfqyYD0WV7OzmGdAYA4YnlfwOtjdlGj4yRfijrExwe4p JUCFpjaO+r60r4H7Gcx/ynognsXj5kiZTDu9ewvGgs0kN1wILW2SGh/5g8PYzBe+HCitVzxW KHVenznW97jUI4ps6ltUjOiQQ7xWUYAM1Hqt/1qJDeo9SyotajF0X1qB/JpmEeaGFdehyS2p nYu1s5I6qH7NDcbtSXR2bbIpZduOPJCUAMf+32Q/NKbZm8TGnfBJLQjO56BvJmaaLBZZbO0a z3pIs/8scbt8qHFWp5Q+eSxfLsCujwSvfStgdLUPKj7akDfAIr5McTya32gNnrqv8bmWjSIM 2UI1eevDBKwxDkRkGqyjDBi6C/3+0buRIwaUevFVvXdchr01ytKF6KkrKulcNBTROlY8Pr/c 3kBRfMzxulMgJKgDsx32HI8PidP0QJyJQOz0WxaRfDX/cXHYrbTy8TD0DeAEvNy/CvqJ/qRi TwGLWutvvlQnI0nYtj8/sFsYMOkVZdKUMiYCiaayoJr4e1u3htYQu7ghxxm3GYg3qQEId/GW vOxsWb/yb8zdffldm9cFQNrG7t6KLdDsj1XBzi5lyahBBbTvibKeaMD/zNmbzBrT9h98R4B6 emDGqL1xhPJg59yCk3lmUXC2lH8hy/OWjWumkeosCWqY8pUD/hX97JggcuinNbo3uY3VEyt+ 9y0JnNXv9ai8dkWGYBZ97m0oIKJUBT83AwzAsXTqCYuV/GMLxk9lb4yqAk6KHnKTjRs/3WE8 xP9mIC3MbtWEb+nYjA4hbOXuKjNh/UqLZDjPDSNf9eaFI5S1I+WwhJsiP2VyFbt8w8tfsZmQ rvahhOXfSHNFsztmdAlJsDtu/cJo5FOltukstytKXMpntaKqkTwdCrN07ZnyaO4g6IZX4Igo 4ojah+C5TpI9o0P5eIcLGGtLFjRJ4k0sY1AWS19adBLhok0BTgsdb/1hD6i2CNC2Q5gdV66O QLjiYjj2eYewZQeb61W+KnbKmgN1hNa3lQeAIX6+h0KllKqcVq/iUUiSzOc/a4pLNmhFXtvr RIHRvnihEqs9Vxg3tVgnGbpN6BU/tbabi8OiSGcO9qY96j5oHe6tv/06cEYPd5aEcae/oDAp JowlOy6iwyRh57xIbPN90J/dA12Rajwv0s8P+uScR4q2qZ3WhaokXA8/zs2EQ0ePGvHQCfY7 M7nhWHcdvEwtAAup8hEBuj1uIrVF2qfK9Neno8gNp5fJ7WnR8KcRHykRXbCq4aEIgvEf/NS2 HskhnAzWzY4KjnUmh+UwCWNhYVkesortsWFPlbKYJ0xYqrwQnQCz447lC943PWpMUBdsJU0H j8h5CGHJYtWFvfDJSW21B2lWj8bqeoxYznzJrr3jyrxuLhQyv9tmPf1IGokAIoG4xOuWPOiP xuzeNHCsskgcsVspfZHln+w0M+oErAQrm4N3qixt1LxB7QEeWxJTjBfXwYyEjQVlvm1haCKy IuL6J5A5g7oEJx1tm2WGithR1/pUDW0O6znPCySc7qAwO4fceCU5+y0e/BgkLX5AIqcaiRN+ XeF7fnDpJweKZ6piRt01PQBNRWlbAmMaAV8Vzk+JHaBhmZUIzf6VChWxleIaeC+iSkEht9Tq kLha1CXGmOrh+IyO8f5q6WCJ/5zg62e7Dmv/nD4cYXyGgOPun2peqwrz49IwFul8LIBk4gog HkURO6G1xrixsPCYB09aiMC0XOgVG9Wfjn+k1Esf9GqaOtICE5F5SFOWxepRC/NZL0IbOr3i mnsVWiYt8coebEQop4Md1AtD0aGMnrj8g79kWheeH7vmdUOoanrF37g3CTZt24oYHgr9l1hj Do5eL7InjHXvSSFYV0dRLaZEOtHWCVbxTNJRMZd+VwQjLjAQU8oPfhXfGH7NQkxN6xDfGEhC l1adhpQ8kFCAOEE01o+FM72zOrr9gfDIWImxpop54WDNWco026bormGz3taQ3LTHxm+BVT4B uPhY3Egn6ydinAZme6yGY0U+QbIen2Asimx+Xa3UJIf8VFNvrsaTH9kugHiLmUXUhaolER71 W07/ak8EfVB+8yvnIHPhl4Y2bE4kYFAuh3jv+RHh0s627djnWBqqZt5IwvYD0ZKmz4pa0Pwr xEdDKgZECGnvLRHZk6J9CUJfWi4+WmDiGd7i4zg+G3aowoMT9A5fI3zWpEBUJiA3edh8e6zE D96crCG3RFg5mUeKi7o7rI3ihDG200zFBexIux3kOaMMAZ7+8aD0FoPlgIuKl/LyDr/2yZp+ FQlRzCHHfOpGquxJJGnYqzKV76jdqpf76eT+NxuKFeocO0APJwlH1HXtXWJtXtn5uIKFkA/p j+3BDP0ihVSJohd37yQITViebTzSyXhZ3Ktxp3zcZkjLehEC49ujw+nkuefFlz9C1/ZIf/2P B+4iIH5P9Sx/9VEateab0KfhhPa3M9VwI5Hmmdt/QdpMp5GDHMBm9w6SFrcT7c3t9jylZ75q pplMb3XKX5kjcji34+2HVELys3X2bcyqp7mTYPk3VSefxRhDFyWkt5Qqp3qihxVXHGeqj+8t kaDNRTszwozx2e/jCHoLxtme3Rz7x77BDXniGf0mze6sUT/+3XAAG1L1ozcT1s6Kn+B7QHAS uWFSjl1Gm2mv1iWwSNjD0fBjNUSS6sMxr5mhM7rq4idKrIhB9VCxIwFinIbt1++3nu32F56w tc6cveEaHotLK8OEsfYmetQx8dGVpaXK+XucHzFmDI40cnLPyUHDr4HPTzWXpN61qMOwE1l6 qOBrcMWDxbbJl+5dHv/dTwhxJwVByukN6vER+vz9j/EKzlBdYE5mJ+vnrDn5CxT+VNwLtCnR xkE6zhfiTa5o4swnsHG6dkiARQfHHfBobItg1zrr1aBzVe+uL0CJlfBqE+ZgDXH+e21J7uS3 Je3cGO3h9AWGsK39rEex4rYvwaPJOheHY1GLJmvqh2+W8Oi0is3/KH8NyA2f+2L31nfEKBML Nz91TKSybUYl6TXOFoF1/C6DJLZtFYobk6k0KRe2JUmjyrQsOsQJsaZvO+afBta3LRyHcJIl 4Bl/+PWy4rD7yYNGmjaSmvZIKZy9Bah1CTBLonK/nkVK33U1ptGCKxMPZCecJEKANKVtAJXu 4d8brWFMimK80MEVn19sNEfcuiIZ2P7SCTD3t7cSVypmVeauzOp/LTEAEjlFKCGMU2d0wO2q WiJVeW16C5xlk71l2A0q90b/Hr8TbX7dUCGIvZGbnayJO0qzKK311XJASva4RUS8uXllJxL4 UGnIMXnqWI9JifzgvV4SHidwAIuOEu0wkFjcP1IIf/3h3TmFi5zbBYv2eir7ro7ThYuq8stg tr7VYS5jt73tXkyHHdhoDG7nNwPflmOmRyraq7ZN3loHQxGvFwKCVBtO1EP91pDTK8jTIwEB dxonSzlOLJpIgvMfH+KQEmfw5XSGX3f8ZOfnK7Ict9pF3pyAQo5QEF6kohqZ4xJmdMh8//kH E2esEYC0wa/YNpgvz056XsoiUpIJz8t2H537tywabBgndGVVue57ybaV2z4MZsKOdsPL7Rtf tnZtLNMj3utVN60XfTzuyqZ6T0IYse0WIAYdnQiEhZkM2qjamarRMJlbf1yooj0oq4s3xsEx UQipyl5fdGCjja6b7qh0EA2Mtwffy7+jlWP9OsHq+jUCuLnam3044C5r9rwjnOuwQdEm68s4 aJZYpq2XAHNJm0ByaE1fDC8Bi8tNact98aqT4diagCKMKMAa5MQvh5bHPlmFS6xIHRZIos56 3i7LC683l3JaBRwzkfgJrNRE0eS+ryJpbv1KDKn3H6vbSbCeCrCdjcWhivlZwFK0M/X7Lh/f cX7W6iHo/IjcOY2w4t8x/BzAOqdQfibuQGl9+/vunBjkdtCV2uPLMdPj832vHWadSktS0amt EKScUk0XPgzZEEHy3Jm5K5+qfaiHEC6qllqYn/qWopMYwn2ZOpxY0+dvh5hdYIDEUtWP1zZO w96YilWa/ZXCVqu2Sed51UikVgGGg8GuK3t+v94y1U7u178WDCcrPafG+XK3qXQjsxruVvQz hKrTR/v+J+tD6m2BX5+2jIwW1pD16TqElWgnfpFi9OB67iq7wO3i0IcurbheSyDeAhQrgcmq WgNDYBzcQXobi6m3aEMCwfa9bs0oFdKLaL+6cZyEq1q57OO6/MaqBMMJq9ZYASBnGJN2yFu6 NFFpveRX3I8x19XIW3M+RFIIjsnBYm1DU+w2OWSGUEMV20Ezydl+RHPnWGXNNN7wA5BwjLvy lb1IhETEoMs3Ji6cFwWaVbrF4THZPUwQFKu4WlS+v5V4tlm0PiWnKSg3mgV5pHCIcbN/NBzK OF+puvEEL1EGwFkeqQ5HElpaOgEVoyx+XMagqNZn1pA+v4t9Oh45cPeXIfT2EF8dgpaoSYoJ tZIA75ycmF+CelOjkeUrlM9VTdSQnfEFUNHtEvBtS0dXYLEtAhnH6g45vi5rUaV9dRs0VuY4 x+lRG9pyAF6KwEZxBWaAxe29p+K2mt44gS+4Id+Gmf2bM9ahYjpGiuVrH2sjBsWtbDEHnRVc JIvlBQl8S5UZb6tNScrTfzYMu97Gi6SdgFnQMXLMeJntG8bD+KnDn/GanyE8p6ar4dbURXt2 +nyo+YcA2Q/OcU9YOjOkmU+Q0wxdG449HCsMBdCHX8iBFWmi1KU+v+BCjoCgY03Qq+SLdjtO oOTM6erJBmym2SZY246RcLoiwYrpjad0G4KyexwmjFSSlH+xncC0tc/ooKAymNxPo+hc4V2J +mwgfypaWUmdNNfqGMwQ30WnE+CS3xbiLUIo69shTWwbXv3LgYJgbfNmTOOB7axWUxEffO+z Jbeg7LK5mWmutUUMk1Re4ivM1um3OrviO5d5a4foFRwcwTM6J5XgUvzAFuF3zKDKQvljDrnX SRXhdzcBJNrq38uZa5bFNRLaxO06BN1KGNei+F73mKiJ83OHVIVfwQqz6EN1OlcsEhvCX0ax PjO+/8Yr4DuJ70SKswTVn7ttAsYaxfXm+TSBM7n9vQeunW/LslaAaBgT9RvpbU0yikAdjmkU ul7teRnvzDQQFnVOUUVB9a9CryCwPI/UJpJ4qIVVsG0+Ow4mybCbCFTY/lYuRIXWgF5XP820 TesX+ufGXYEz0zrkBd1LHrnGH6No7SAVikxJ6cGfQGAKJWOj+RIIItLF1t6yFfFkbI4sbgem nkBLKCu9QieOHuo2c5ARiaX83EnE5HCh0udLJ5VM2WtKDJ6f5GCf8mxFO78C6dPV9XOiXE1M 4zr3z/7gYD0gVyROFjrAYnm0ItXHbmiSe3pPjoqYL+1AkDcvetmv0sfHichNkJpp5C9O6sUd zwuMu67xAfN6kSCSmUh5n45UL0nUwPJVQZ+AJpa8Q5ioKgNVIl6rsQWlOkWTFsY/5ZE+gRW8 4vax0exo4HPGtwN1EfWZAG0yyXqwX9OSF1La12RgQHY03K69CxlF6vtnGlWp4umc8ZrJbqIe oZi99vlFsMpX23iuTGNGacvi6pw6hpQWcsstu98lYagr3EjKcbPCMKIJEw8kM6m/LaFQ7iit QJsdly+Slg4VpklypgRxb7RNYxxYgiDQMq0num8CLEvv+IqmvSRx52qtXmgxOYDU2CyKdT5W s47DMtfsDHDpirAGT0Zkrj3TW46lZH/EH8bdKYzOFXIpuQ3PaWneTTPtNg7aQaE6d6q0XzXc d/IIy3JmJ6C9OUQuAz+fRDiHUyu+ok1PL7zoWn+IGnFzKUqdUwvTWTIwLPxL+RahNjvW/Lw9 NlvMhYLVy9ionSC1XXqLAdRRW3PuDS2MKKYkqBD+lwToLKsrBfY7vEZbc5HRalcUndUtE32W SNlHUwtk833Stsf6mVcch04tX5VC2L63uDQ8GCNijfxoGERR1QIGsC9gEp9rZMm0D6nIbRMk q04vFEi1iyZ4hQczKHs+VjrljKo38sXPJIHk6yfT7lM1OD7YnRbGrDlCoFJZq9RP/9wrPDDf G0AkBpO95G7Hxztesqpsmgw2e/MXWRSVl+E3D1kvjPDaR+fKqFpbQDR/GGQ0uqic8yKoM3gR p2PsFZ9DD57kt3+1Ut3655dMS/Zye5IZPzPUkFeZEV+8ydtSrFHlMGAOJDmKLbEDTgboXUV0 xMfP92wdf5ETFumLFt2NsKqmnzlssxJI2X1hgWpfvq6+TeQ3qPhnA9SvIUk7EaIdWL/HeaF5 4u4D4xxEiWPuSvlypEiWeF+pdMZ5pA4sTvh+76L1QBCkankB9tNOtLPGK1yO0hRzWAaYgKh2 P/q7yLNmzVVwtxPdNMzbMX5MOJHVvatfeIROHu67nNeCFi7e8cytB5TeqQYLKRmuam6sLBgr ne+BL466ixl6xiZwbOO0sr0Mae3bqVonn/2ky4xG2GhYyE7OMhRdk1zhlq+GsRZsA4yncgLB pOoHPaEin8yaDMeSEP4PPsHve3+DtFx2VBUA493Q5LQO3MRozFoxf2wqjXyKyNJDjUZyAzji cyHL3NO7PyHqEbu9hlRP13kodI1e1/ON8cl4cKFx7+SoX2/5sjSsbKYmrRsx3SYdrHgv1WZZ emAN/yJN9e8/J+c8ypP2Fq7B4EWi7P2d3seuWumeO/2a2Uh2LbEdqASscQ4aGUGf9F8gH8BW 0pcQd/n4SAe0XgNU2pTqcLpOiAYlWBw/1vdNAGGUU7Wv8wo4+KRqRRdMZxd1Rs5B3VedIiyk fFuOjRJMVwKlqdTGOcxKYM5xFhjm55TExvnoLKoHenzLaZ3JSj2rS8CMD/LaJOIIAGRFt08f +0XCM9IvrhJ3tBF6oKjFpi9yV8/MHWqT84bFKmbIMYcIoATZsimOvEQSTpmfwa9+Oo/B7QEE gnlVHlzNaQ/+iAdVf0bLzuxaLPvv9sqXKSWMjrXFKp6/ftxWquIt9r5VE4D6gGjjvDfSkvuC ox92MwkfUqhKLdsGQNwFM1L9G/dMedHFIBJcqpSwU5itYJ0syQGkbTxIkj65iPL4Q/GKj45P x5fvNe0DU4t5H5jWHgwzXmSkiQLztQ3lbTz2H+8K46VNsvc9AD13dKwinPL6ahJGORlpSLMg bZ3Bbu7JSlWWDulNFmvSrS3B//ruR1Gmkc8RPdz44fydN/n5mveLvYBpme7WnTv+R7Pqz7I4 ch4cyelmR2IGDBC13+HvIf+xtjjN5jaGdOkD4wnzGWyDng5UDzugqnXrO8/s2ee7ilcSfkeN iuFaJoel2rzio9Emsg82ZPnWkiZ6aSeFdBXLMz/5rVcNshJVj1jz95TrgpIOeWdF85NkhbvF Os3vT5smsqNN4im4WMtm/FTamGTG3+vxvF7uYJ/WOF76WK3i7cp5Qa15MN+rDcAOBOfi5bsC Nab9+Jq8RhqDTvgEFpWtaPkElm+zOGeR+mAxqpHMNtyuPDlAwO3HO9eHcj2PRODu3vhwxhba D4UEbJrbtudmANNaq1/DE8ogxVyc/inXQ1rUqygcdo3a1C+LxbgoJ1X9p409/UrdCqaVeua6 Al0J0ZmtZvzhRKVi5uzRoQe/4etrv+8gMs+11hmQ9kaor4W1Kd2IUvad4q42WPr39XxIpSz5 87sYpXNK3KUDk11ZNTfPhbs3jS0cCwv5D/QkLQXG6XBsy07Ib3D+Oy9mvu8n+OZ4USrJVDde iFwVEayc4rdvFwRagz9uO52Q+MJwKBBya8vs9HHr04Z/u8c7Ggos7ZcfitsMij49/C9QSwME FAACAAgASVUcKdWvvr6aAQAAzQMAABIAAABmLWNwdS93ZWJyaW5nLmh0bWyVk8Fu2zAMhu8F +g6ch+0yuLaTOZkxyUAR1E+wYWfZYmStjmTITLrt6SfZjtEWTYueRJHUz4+UxFo6dOX1FWtR yJKRpg7Ln2R7LWBnD/2RtFHwC2sXVsJD3wlClkyJ/lxt5d8S2Ic49tE/xKOP1W1VrdIIatXY zjrv2ezy9eY2gk6b+5BQ3X3L/PY079P0Lq2KCMSy3+3SICCae+Xs0UgejbaRq5vfvYpKiONQ u0FD6LzlbRJ1h9Bg1/VCSg/LsxRq6yQ6nsGDltTyr3l6WfQF3lCDnJ+KDGzK8KXgZ1MP/XdW ++DeGoJB/0P+JYOzwjwDn/mj1YMPE4JfHSo9eAWUoA1Qi0Hh+urSvFkSxMsp6VGHQy+apx2m c4dF/mmChtNE7JVHx7MOmIDW4Z73Dk9zC2f0efplCGl7nODPJIkYaR61rw8KBtfw6GFizuLs Rul9NANtcmhRq5Z4sfbHSb5GEypdoJnV3wmzegqTF2eYbfEmjPGv+QJMCL2TZP1sLNuFZLuQ JOSmJVz0ZMnyBe/yClky/r5gjN/4P1BLAwQUAAIACAAsRRwpdUhJEY8MAACyDAAAFAAAAGYt Y3B1L3dlYnJpbmcxLTEuZ2lmHZZ7XNLnHse5iKKi4qXEu6iZFhKoKeBP5H4TCREVFQkvIRoS oqm1VoBYmVhobXN2OVqdnc5yRqap3UbihaY1q7Vs7oJm6VY7s9bOuh071uf1fj7fz/P9+/m8 Xg+byyIQi6igQtDfoPfSfTi6D0P3IVlX9KP1i2+W1oSviUZHY9asx8Xg4tfhk+OSkrFJBGwS CbuRsIFAWgG3AgnAk4B4EjkhBcADqfEAGQ+Q44G0BHJaYkpaIkCNJ1OSUigrYSOZmgTQEtNo K55EZiSn0QkAnUBmEFOYpBRWSgqDkMogkJkkgEkis1NSWSQyC0hhA2mc1BQOOYWTmsoByFwy wCOn8shkajyFlkhhbKQwEmmMJAojicZKorLeO4NFoLIIDDaRxSHSOAQWh8TmEVk8EoNHYnMA CjeVxgOo6StOpqSTVzKbn0blA0weicMDOOkAj0/iZqRyBQB/E1kgTBWkU1L51JQMGrCJAQiZ QCYLyGKniTnkXH5aniCNT6FkUGgCKm0TnSKg0TZRuEI6LZPGFDIoQgZNtAKLImLRREyGmM0Q UgQ5LH4Wh5LNpWZzGBIeMy+DmpfBlApYEg6/IINTuImTSRWKKEIxdQWRmCYU00Q5dFEOY4Vs CVMsYebksXLzWRIpOy+fI5byxAWcvEJOnpSTL+MWyHgFhVypjCOV8aSb02WyTIZMyJHzCosz ZPIsZnE2rTibsSWXXSTiFmdlFIu5CglbIeEq87kVUu5WaUZxurw4Q75FUKzYVKoQFpcJS8uE CqWwWCksVWYqykWl5SJFRWZZhai0QqTYKt6iyl5ZKisylRUi5VZxuSpLqcqqUImVKnGFOrtc La7YlluuzqlQi1XqHJUmt1yTU6nJUWtzt2kkZVV5FVWSyiqJWitRV+eragoqtxdW1Baq6jer tBJNTV5VTZ62Jl9Tk6+tza+uLaiplVbVSWvq31O7Q1a7s7Bup2z7zpUgq9+1eceuzTvVcm5V SXqtUrCzSL2rRL1HUbVLvmPlTb97s9TZeVqn0717fwG9+zDefUgrQr9yAoNAoyDM+ya87wQI vgxqdg3mWDqvN8B910ntmvBEpUck75hk8uhQ7SL24syiR8ToId+bX2XVeYZcqp61Hy8YOH+c bcZ57Sxhb9pCrL3d/UlKWY+UWBN086op4G4wafuvli22x93+5zbfufbvgoXDW1KqGc0nT12q PHGl8u7Y7W9gf90f2C7Wy0I6+rvsbffnKie+yAgYKBpQ/+/5I/e8wbOP8nsrjyLzL2+nnCu/ nFSZf056RT3asX19bk/BnttNF0jtluu1T6d6Tj1WPei/+vXuRx3BzauxpfYTXWvGH1TTtnU+ aKJ/OpE/cPWO+Vn/9q053ZKr9b4zvIM/jd26WHBi/Xhyb9+/rol/iXj8pB5TfEGxHFDCFhyT z8A8SgA2tv+381cwf55s5KN6JBZl48C9lius7kUPY0EKuX/tzQ0D0wZ3/CBDgcBfRpVIMRf5 Y2Eps2/9OymDX9EFxN//Gf2g9kYw3YS/BBBMdW8CLmQTRjV9s6xFc5asdmiKNhtnQ/zZjB9b MvDNvfb45taLLwztXpOAf3jLvDHSs7RvSjRbawv+0x0/8oKGwPX5BYRuuPBiweZPTW3KJMZ6 lwTEXR4RncaPg8r5G8ZUuad3XzDnmbzSEh8cTF68bY8m/YhTTmJ7R7QT2PHwhgWs9LfhxdIL 08XuEei3IFZ6o3pEQbxdf2NL++AUbRJXFw+f/Xh57IE2KoIMCjSZTvTXnCGc9aSbcKw5Wiz+ a3hCN9byDW0yrr/2N2al8deOIiKl59JEXO/pb9bgY69dbMb9/JOW/1X/suZJ9pBaLCOOMKrn zpkU6bH/HIsel2NOOoJoF8q+hIUwod/HCGKkob5deGZF89yXfYDSVLfvaXrPUPnFVRbCvLHN nrCWDJdhhkMfIvB9LwzuB0rHtPAh8tM33YfzPKYPtnRhurptUWUfNePb5u40bz0iGNNeQHNE VTmXDmQJfJuQ1ZO4ep+S+bhh1EME9pq01h07xI+vmUDXO7YVxN3jCFZn2CFRWBs88nOMt/bv iayhqDb7fcYmbc0yP35m/38jBHUBNVubl9tcI6WOm1q46VDGkZ1OCtPFXttTw8T3hxt7988d SNh942dc/3zRzU2Y553Ygak2ztyx6luDrhXePPEvG6ufGaMCB3pShtDtZtczhz7LuOXDQp1/ 84xxdKrtKbNyJCNZFr4hdfo4KMx3fvxIwtUXVMx54E4Q/m7L/Zk/Qo3e5yRed3WPok59/Oqy /7vUzDh8lserperdu18HjWIqcH9MhC3M7zvb3mcMuucwgv7yNwrPeEXFX74HIbo4RUx+q7v1 ZGww+mV/GBLs7fWW4zQBdvbc3QJnI/3+pC1cKXt7w4iBDnv7edN0/VGouRg0AvyoITIGHbAM MzaxBmeHYctyJTvK4KOc/tpRGYWafWkYMdeNrOudPMAT0hIM8DZ0NB11+ezJVV9JsKHLDhce xVj9Q+sqOywycLPyJ9RNuy0+/7xhUuOp67h/UA2ChoScfhh8iIAnvdbB6SD0pHyOpZYPH9x+ LHJhhGOMQOrhhh9OIZPnxqspWvOWKycDGjRcNBIM95RGuc94m958LDLXR84HNMl54aBZl8uS U9Hol2lV1jYTJ/F0nD7cWPAaVLL1bS7jt3EEjBf/KdD3KGAP0qn8NQjeUe55SbF2XVH7w/qS bkfct5Kb2lhqMOru/vigO21lGn4dFxj2xuyYqPK582nm8jQ9Ged8pPCAUDwCZ78Iv2GLiAE3 Mi3z3qKlhiLnoo5sa0PMpaLIhe7D6N/9XHAyVyMmVP9pDLCF/q9YfQJEj9xhjmG+eTDWYtwb LFs8EvCJrrHBjQoP++Rx4mHCJO0l2OujqcYd4gejLeGs1aXiOXbzDmNrh7xDEbwQtvsHZ95i BG7miiy95kKj9nhve5nTd4InhPNh9uteGxbBQTKza+GxfTGBnz/AgVY5+f74vLN15Cj/5ut9 eAfaLdxqxImnRTG/znbEAIuSfd//uzX0vGeZHRqkxBmoizTUnEZQgJ0L1uoetsVIn44w8pmx 31330tvpwV+a9b6DXT6XQcvORKlo+qz5oTdDM0x4dW+qCHLdJfAlfb241Y36ts8t3gLyU1qc MxyGoIbe9vTR2y1oSr/02v+oaKE3nNJ30u8fOGzINKgRMS93jlgE+2jQpu47G2LmBxmS0YoJ z7fXQ/6odwGczjeQzxR9WSVv8BBowAkOh8danBGru+2RxPOPnKe4oM/F7kszFSN6hLBYjn4v eRcNASzZgnrkUJ/2vz2rOodhSWgTrDmycGMFe61I4wS8nPVqJMBiRM+aRBYIUte+LqTHIvVT hUP3oJ67JZqd5CA6anxpUmcv8qy2gt20lmdhEP0+cvtJxK6X0NCxs9BAK8jJf4qyHPwf695g qRWy2m7EPQ4OmWmj+8WbIUFzSBcAPtxfst+2f+KKwbvUCiFaGtzOdDb4mEG3OJoWrKoh6Ccz NLBZR/NTUWAki85jzbTeQwWCrjI5IEFCfeAdJBQhpjj7L42citO5FvJ/SPI/750YiIb6deuc E+uvu5eaDb67wqEozl+o10v7iN+BIGtB+jXDRTA3iRxi399bibB5djkgnv52K5xi1rvrrNAz e6tRt8Ifo70Gfzy66IwR4cDumGIU+A6HWNPaJKd3wbZa9LDETr27PRy5q91m7gqHIiUOiL9Q k9xnVnip4NrPKkdWiUENxHY9os5OD12W4yD+T+VDkdPW1Ti8PnkmMPD4S7BTuwXdgrORNbp+ N7WmcaNU77bBYnWWCSFeKorPwuLeUEe3y0SIDYkQWvcWM8KLQFDfdSt91nmoAq44IGt09au/ K/IM8jj182prI/bgLBwWo3sMnkvCafTudMQxh9d9q/N/ZeDTn0FL5oU7YZhOucLP9rtX+yXi NLhl6EmxL/IQxedFpwsdBZnztbQ+hr5TuAfbGts4hqgvZKZ1YadGh+XDsHVCff5gtL+5PsE3 aVskV/rG/XTyfuLws9Ki+rmbvsKRJ9fxL/vunghBSnQQ1j8+MrQ3BFV/z/RxPqS/z4b6a27R 9Nj2Ys/o8GuvYPjxY+Vdro4gw9Z7SPZqDBIsxZy4OFqvm/nca1kfbCtr1lXDErualWbom9Vm 2O2NyLalj/9iI21WxA15jX8n7NIU4lark6cF9CIZ+dylzkWCtCGdPBygVhxiagkBOwNq+kzv gzesiUE+H9gVHeO9nrPnkFwXZ0dG7tc/W6hNQHnzLU4wtCtfqCcStoNXfmcp/wdQSwMEFAAC AAgAMUUcKS5iK/opCQAAQAkAABQAAABmLWNwdS93ZWJyaW5nMi0xLmdpZh2VfVQShhrG8VtE E8VKu1aATM3Qgd9fOSBERAQEVL4F5BsERERU5iCQyMzQebZ0xahc7bZq5m25e+ZtaLqlfflB LXfdVs52rLVltbvVaaeu9Zzfe57nj/fP9zlvWTkhv0BUBKAC/gK8lvXNWN+Y9U3yrWvJd2Jm bcuWLYmJidu3b4fD4QgEIjk5eUdS6rrS0tKQSGRGRgYq7W00Gp2ZmZmdnZ2bm1uUU1iSuSs/ P7+wsLC4uLikpARbiCEUlOJL8OXFRAwGg8PhCBgCHo8nEAhUHKWyrJJIJJJIJCqJQiVRyWQy hUKh7abSyqhVpTQ6oYqJYzDLGLWlNYxKBoPCqK5g1hJraitqqilMVmkNm8DilLFYlFoOkc2m sjiVbC6Zw6GwuRQOn8TlV/AEFfy6Cj6vkltHFgioPAGVT6PR6HQ6k8msqalh0WvZdBa3isNh sNlMFofJ5lRzeDQuv4rHZ/DqaII6ukDA5LNYLA6HI2ALeDyeQCAQMurEFKGYIhJThfVUUT1V XE8TiRkiUbVQXC0S14gkNLGEVi+tkkjpEtlrpHLGOjIhV1jPFks49XKOTMaXyvkyBXMdubJa rqpRqGqU6tp1VBqGSsGWKzhyBU+u5ChULKWarVJxlUqeQlm3jlLFU6h5Kg1L1cBRN7A1Wo5G w1dp6xqEQqFYLJYJpTKhTCKRyGQyRb1cJVSqRSq1SK2UKNRSlVqm0ojVGrFGJ2zQCbUauVoj 1WjkGp1Uq5NpFQqFSqVqUGi0ygatUqvRaLRarV6k08t0jWK9Xq5vkjTqVXqDsrFJaWjUNTZp DUZVU7PaaNQ1GXVGk6a5pcHUojWZtS2tula9Xm8wGJr1zaZGk8nQ3GIwGY3GFmOLyWQyN7WY jS3mJnObvq3VaG5rbmsztbab2tpN7RZDu6VlHYvZbG5ra3vX/G5H6zodHW0dFoulo6PD2v6e td1qs1jtHXar1bpnzx6Hw+F0Ovc7u1wuV1dXV3d3d09Pj9vt7uvr6+/vf/VizesdWt98tX7g rwCv3tirN2ldsOfBAQCAE4B83YTXnQCEvwREAROJw95xezgkjXcIfDkmS/vjGPqS/ejUfuDC oX3wE+QTB7dfcYzbgo+XO3ecdU8P/fOTisojhcqZOOf16Y9CFj61LD4JvHoIk9MrskNOAtHI nNJ9yyMBsyfRx5+lqkZIA6lvZQjT50beZ3yK3tUai715zL0ReU6goB0b74wVjDs7vwgksjtL WMP+U+cdP6VuhltCXpz6IC6qBSIr/z5TnfI15muPO9APQUrFKAdRQysd+NC9/dKB8sV0J+TI 5HzXpm/swdeDFxytrXd/4+ygjwjc8OeO27XTY5UFvaJgjY0Zr1bd8b0t3fE+1fu7cXz0gW5m aPgZ5igDfp00+fJLy4MLtj8os5eMfRm3nvyrefiEDzMeEHT1kfRry60h7kznoajT4AWthxj2 A9B37umBZDF+PBC4yQeApEh73eUprMe5nGYA6S5QFyXRT8RNn16gpOMqA0IitvJQIeQeWsju 5J7nZYsSgGd4U8St1r7uwsfmp6SUARdsCvSWUI9NQKfT/d2Y3y4IjPR8FLvdAxjtKb7nD9yf MuiKm4rYTgR0snbFVU90Np75zspNEu/YhLwxlnWwcMaPu7LTI8E5LZP/u2xP8hzG45PH7q/e Ahku1MYXPF163p05bS6QJESVuCZ2Wi5stpe/syK7ZzwgY+/PW/MHUQvmirOUmS/PWwaWu96e 7LoXkmKjhZ785CKuIvOnsd0Hi3+1QK6d+/xBgaS3zNl79cPPfYEgYMpNfUDC8Oyx9PQvEMe7 8371JUUXT21Tn/2sn7NFFl9lfhKJlBIDQDt4S8FYxxEE5FrevdOXKEUP++tPf/aL58WpM7h9 dx/sZPTTbgXGuQF285yWWzE6U8xY+/f938sRyBXE04hIQv8XtqB4y3BgJB16s/x8PCTxQN6P et79Dz3u3RvSBzHnpvgbyT4sEImPCU0YlEyfGd1yg5w1EnZpOaroxhjOGbdv8c6tsNThpSrV 8KQm41rO6KA2+1H/7ooUia83Hh5DRGWDaORz81cq5Bbky0UptSutCL53ejEZiRLawvijfw9I xUWVf55bmQyi3vQYJ8LkeDEYG4o4Tfvrh4u510fzHlyGULPnL+JgvwwOewEhWw+v7YkTIbfl LrQv/F1Z9MdhT3r6RUAgFz7oeAyYOfJeh2h1GkxuKnjsf3r9q80LYjJquAC+ANpABr8AEf6b kVswtnC8x/ND8u5p6Co5kEse8FmxMzupdw2rMw9Lonc98nawPUHs0hxhlt1vPBZJY43PTHy3 74qbuu2peW/eH/5i6cOJrb9nObZOwoC39ct58xGidA+2p3ksaNsj2rdZf+JBUsnVWCfmm9zQ vogG34lQyLNrn3vuHtC5jye+XFkjeHCr6aANePB961GM1wa6veQNQD6rnBKHgCidZ7lf0ZYx FNEBW+pEotl6LTrbGhA9S4mUrIVXjPSfqb69Bl0iTmFIc/t/jocDs6EBET75Owf18NhusCtn UOGu6K6HOjBlsIfmGPzhn6PDEggZocsREtQT+Ld3prDJth5s+MqGn2eX34JMXIzcFBz/bbxr 21k0ybkktoYGTBacD4/inqfDmsPLEBvEEarIoZi9Y1IcyhblmGyEjhwaQsUsR/ITV2KX44mw WaxLum0oajUcj9Ch3byh+cFQWCg6d7HcdgfWfwdJhF6v2mf3GqDeNWkh0NCVsCU4+peXs8s5 K/k3bMYgyFj/SRgi5lpHxErsHYwr95nSVadf8DrjCTs9CT02PR0MPjKZj1KBRcV+8H9SQ/HY NLqdx4QaMSexr7zzjA/84KP6b4jYuW47AP5x0FwoBhYR5YzFx83HX4adQM8T4vzQ7zFTGNnc 3t4PcAMhvXhcCNwl9Qccc+TvTSkqrLJhlmOSGkL+JLdt6JnBbhRlryYeEpH2OIzQmrVLxI0x oI9OnQfW6yeI7zS67JNGKNk3QfwY1ZWViPhHUY4D5EHN77LehfaZj8NmwY7eU7Bodf5lJAY9 v2fVCwqLCc56OLtoQ8LCivIvJ+GqvrddDYA1CpNCENzPwDu7bRdACfbN+o/ccIVtFKi0RVrb 3VmRti+BwPD1J/F/UEsDBBQAAgAIADtVHCl1LPROwgwAANEMAAAUAAAAZi1jcHUvd2Vicmlu ZzMtMS5naWYdk3tcEob6xkFEQQEB77cCUiNTQUXDS4X3GyiiyCVURFREJVBUylzcxRtpWjoz Q9Mya/20Oq1TbYXadKaLWpmVbVqnjXaqaevsPvttfT/v83me9//nSUlLJkcVJQBogF8A/6D8 IOUHU35IN/9m+eapubVwwmYSYVNEqC853Cc60js60id2h3cs2SuW7BOAw271w+Fx2G1+uEB/ v6AA/2B8QEggnhi4LXR7EDFoe1hwcERIKDk4LIpAIhEJkaGhkaQwcngYOSwiKiJiZ2TUblLs zqiouJ2e8Tt2UaJiKNE743buit9FSYqOS4tOStuVlJLonpbsRktzzaI6Z1Fd6DRnOs1lD9uJ x0UU8BBMBpqTh+SykTwuMpGyu6gALuDDhQJYpRi6VwKRSiAyqb28xr5WbqeoBysU4MQ4Snp8 SlpiUkZcKi05PT01JSM1NTM9PSuVmkWl0lOystNp2Zk0RlI2MyEnNzmHlZzHSKPnUOnMjFxm JoOZyeQk5+1JYbPTWewsFieVzaVxeOncggwej8YtoOUz6Yw8Rm5ebg4nm8lmMrnZnD25bF42 tyA7Pz+Pm8/k7eGweRxOAZdXyOPxMwr5mQV8ZkHRnkJ+fn5xZpEwS1BE5xcx+UKGoIQuFDIF pUyhgFtUzCsWcgQlHGFJfnFpfomIUSrKKxUzRZU54kqWWMQtExWUiTmi8nxRJVss4VRW5ldI 8qukeyTSAomAzy8RFJfwheV8kZhfXlEkFgvKKwRisVBUKaioElRWCiuqSqqqyisk5VXSor3S 0r1SkUTGl8qKpdV8aY1AViOolpXI5MU1tcK/Ty4rl9ZIquXlNbViubyypraqVlFWrxDXKyT1 +6oUNdXVcll1naxWIa3fJ9u3T644UNPQKDtwoLbho9pGZd1BZb1SvU+l3a/RNmi1BzT6Rp3h oybDQUOTUm9QNrWomtvUrW2atjZta5u2zahtN+qMRn27UW/s0B/qMBzqaOroNHQebjvc3dp1 tO1Ir7Gn91Dvxx29x7r7+g8fGzhy3NRzYrDHNNg7OHzs5PCx4ZH+kb87/f6PNZNpWKlUvv/n Abz/YO8/pL/B/mYLBAC6AEH/LOGfTQAgG4CtUJ/UcZNZA3EO5M2OD041aRwm9qVO4JLiz26w l2dlK4PJmoD8C+8Sk2e6XO5YW+5DYGBHNyqi2+8seu5YE+5/H2tbMrt7iMFXrA/mHwYIXxQ8 jX1k70QgFNKpCg7Wer76haXZsSz4IaO1AwY9MGJIsIwRz06eEeKPhmQdJjWOXEm+i0+VcXMB 3Nq9Oke3AMyz6TOMwLKj34WRbMvR2HxF/DA8PSoYU/HiUujXdYg+ge6jxIXyn07rwJ+7BAAu K92kE8VXx4o0eRXff682IGgt7xxghs9zt53UQXtBfmldXg2T8mMrPbnNX5HjzfXk/zrmago9 Bls8w/LnLm1kVwykYk4ya+LpJnrRZPmlT1gsCVPCi967egl8rbHUtS+5kLri3mDDlZoLiRNl mIrp/BW7LVVmBtSvutF/0e/QuUl1Q/l6rVfdj8cjH6jLRuKW/M5jfrrN0NyPc3A/Jgx1LcSU njYVns6uA/IlqQmZkbP0i5lReGzKLP4T7ThLlTNYMtWOzdO7Nbh7hLcTHlETaIStZ7JnNzex cTo17ZnIDIq1PcU3LkKbVJB2mmAWOzFsk1esZw+1wt4wb31TYF+wQ2v76rNLACbzS/tulbdB PR96DJLTTubRL+m2FFHetrjgECwzwmk4+QjqDPN/AFQZdpZPd++Pz4zZ+EGYgyDfXrqMrO7i rxtw4d1cawHxpWlqPxGIEjPhmE5+ybkh/5RtPXzBfEA3WajH65G4eeeDFyJdDeceEYOocFPL ImreZpE7pIJWN9MurN1r+wT612qGF47EGZUyaZjzShfSijsomURZHjo3V292XqjMaQ9bGK7J HHHwHzJAcWGQoAO6H/gg0ORbpK0tCmm+qVZ+Wf94KObCYTh5pW2qnTgQlPgF5MbvjwlOUXK2 yimNhH1noQzPszDQ/4rMEB01zOBXQWeEx5f8GclUNZ7hAOFJLjKrTRIs+LIFgWzNC4V0iUx2 /Wv3HAOuxyZsi3e+v/D4c1DeuPsGOGkFYEYXH3pas+iGrPnFaHeqEujy+HqXMfJJf047Rl7f 8GkhmaF8CqfahvyMRvIkKocTuacugFlWdbP/I21Y7Qvt93+dBSMVu+ToiHNis8v+UUr/vZhN Syl+H1MPQwlzlu1Iv8vWfNHT2pgTtaDjDcZrfXaMwRmo+WT/O/Cmm/Fw0jz+4kK0yOOdgWxh 6eK+cjsnDft2wB1lfsX8j2yyKXrsz3tgATIlal5llNC3eDwInA3ddHegH2q1p1LUqI41DUQR YvPjbxkbUr0bapRSMpXmCfUatIu/L3DTKI5TYBMORfzJrNcvexru13rhFAi9C1LtRj2dcGtk pGHDo5fiJViFsng2no/WJim4dceKIBuvu1/v6Qr5BW23ZIxbeln0rO4/Wt8+Sau7CEj6CosQ J4J8XyxNUxgTDjH4k142NuxXo2rQE1+rv4sV10za2rSdZ1/S/LjTu2/QoUQI8r48iozDYWGR gKDg1ygE4gfrvyM4Jlt/jAWs+PTG+9cQEOaHApjtUHOCEOdx+a3G37TukP/rl4cJ+yhO+5FA X9665Oo19cbvPUDYgb0ggdKDUAdslycKMMP4ucC59bnEf522Dyh2gr8ykG/STQ778apaxhc0 YpjE9zW+acc9YHsmTIt+Ua733wSdwi7/WJ2y5jN3GdSCxr+RN29cBOBz6tT0RLXzWfItfzQe udtv6Ei75YmZ2OMGMc3ZpfLVaIUSVPpyLTrw2tYdmhSgp8ekq0wGJv1JRMbCnnv1dmTXXdAf hbhg8Q5kz4v8e1MNlwNOTK/72032tFdSnnt8w7Yn2r1tYS2ZPQV0y4lSe1WPXQkkSnxUdVW0 8MD2/xqatyyCTR3wKtNznxWTfjtkzDvGBwT+Jh05LmJpG18CNLd/Pw4O6bvj+6+XY0+PTWHt UFBXBy1yyHIrcL8uYrd5GkK2eXJh+afdvXTXs3mvT6iIKzEfY2xdFyy6kGeWAPAILHjHeBwE PjzWh5Ocwk8p7UjjQBj7Z8yR1I1pt37zmc+g9jH2Yy3o1GtBXlwMsoDXXvZCA3wgWQEvAYEJ 6HVI/jCF/GiV9QbSkxWsmIi7cS3QLrIDCL+O9cRjQAkb0rZyA86x9PD2isiAzZe6+U5cQ6Xp 8qOnsKUc2wXyjL/X0KPQWA1iEuowdP9s5O6A8zTVOYK9zYS95yzFa80jOQFxtykZv8VuAE6V 1M6cn73QEhhzb7mQ2KEq4N6ELvL1FL3MWG8txWrHtYRcFFgnbqMRc3v33rn3maOLO4gg0jkI Ka17pxPgXRZb0k2Uo970zPPb1VfpSbGe6NXwa81bZHaAky1SiwB93PRFTAe2o7S7eNTRnLiB fQVoD5oPOZ+e4Hl77OXzN/GrLs4dqrDFVZhqTe19hz3lN9qJ4JGmkcNLzhdJD9nSF6Kd5i9f 7sqStkmHnVyfGWZCy7PbK3qL0O1W9VuE2r4ocQqdxz5y4lXgQ6RgpuvWa6X3KEBNYG/Z1C/t W14jNu/RnvSZOWAgaEPtRcsqzsBQdW6zYzo9WuU1iZwNf9wJV/066T0DqPHtoHYmwobQN6Sq 7o6FseCNX21PWAEQr2yj/JXWbdGavK+/0yiSTzu1WsFBQoCLceBWw+bf18EB9JYqUrzfY1OT 12crbdX3X6EqUzenUIFw9jkc4sX5sDoNi+e6NnhygT0TtmGrbpPFFqNF4/oY8UQ3M9cGZTGB TJL5540/v7XZugaO6J4V1OFPew14av2Rcf8eIWa5hrK3u3nHPIPTVQ4ufFDkchyDlgvyPdSb GDKtMj6ZB+4b8nA2bPnDfdqM8RqT9pG+GYSprJPext7pgMS7+juYSfcFdmK4ceFJ0B9LINbS zau378JVSzif55QL4ZZVR1Xb/m11Is1WOVD3bfmbMbcOTQQytJmjSNgk9tOGT058y2ILbiyg ZlP2Zzt4+lm7PMgqZzzApmRY416yK+XJzqJ2+RUB+hCrLfDEqmOGEnta6QkMOj+hS7tu42s1 9W8fzYbPQIpRV9L/ou7/VOVAFT5HmHNUDvg1G/ElzXDnuD6677uKaohW8JiQ6o0ociycX6F0 L+oUIyinsKxnHk/GIV10xxm+83o9Us23P6uEjRKhGCLw4ApctwM6RUF8R6//bcTRWK+EdEKu I+FzFpINyvEJ0SkyDrKARNwqht2QSn16kX1rkOhsZOvDsnIM3LpW0og8QLiCHEDCvyZCmwHw q1LsziuoSxb48tpHKQr0FST8pEWbATzIYOt8PJAAQMz/A1BLAQIUABQAAgAIAEGYYSjjxI8h ih0AANceAAASAAAAAAAAAAAAIAC2gQAAAABmLWNwdS9iYWNrZ25kMi5qcGdQSwECFAAUAAIA CABJVRwp1a++vpoBAADNAwAAEgAAAAAAAAABACAAtoG6HQAAZi1jcHUvd2VicmluZy5odG1s UEsBAhQAFAACAAgALEUcKXVISRGPDAAAsgwAABQAAAAAAAAAAAAgALaBhB8AAGYtY3B1L3dl YnJpbmcxLTEuZ2lmUEsBAhQAFAACAAgAMUUcKS5iK/opCQAAQAkAABQAAAAAAAAAAAAgALaB RSwAAGYtY3B1L3dlYnJpbmcyLTEuZ2lmUEsBAhQAFAACAAgAO1UcKXUs9E7CDAAA0QwAABQA AAAAAAAAAAAgALaBoDUAAGYtY3B1L3dlYnJpbmczLTEuZ2lmUEsFBgAAAAAFAAUARgEAAJRC AAAAAA== --------------9C0D06E261A53DE9D403BFD5-- From Yann Guidon Mon Aug 28 10:57:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00368 for ; Mon, 28 Aug 2000 14:09:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:27 +0200 (MEST) Received: (qmail 5354 invoked by uid 0); 28 Aug 2000 08:57:52 -0000 Received: from ml.egroups.com (208.50.144.77) by mx11.rz2.gmx.net with SMTP; 28 Aug 2000 08:57:52 -0000 X-eGroups-Return: sentto-1101623-668-967453068-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ml.egroups.com with NNFMP; 28 Aug 2000 08:57:51 -0000 Received: (qmail 29338 invoked from network); 28 Aug 2000 08:57:48 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 28 Aug 2000 08:57:48 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 28 Aug 2000 08:57:47 -0000 Received: from f-cpu.org (nas3-96.aub.club-internet.fr [195.36.145.96]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA28438 for ; Mon, 28 Aug 2000 10:57:44 +0200 (MET DST) Message-ID: <39AA2981.691CE456@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000828055715.9499.qmail@web1105.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 10:57:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring artwork Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fbdf7be1b5f72ff3a421befe0b1dc162 Status: R X-Status: N

Jamil Khatib wrote:
>
> Hi
> How can we join the webring?

hello,

the scripts are at the debugging stage now.
wait a few days and Graham will post the details
(URL etc). From what i've seen, it's nice :-)
fits very well with the opencollector's frame.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From Yann Guidon Mon Aug 28 13:18:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00389 for ; Mon, 28 Aug 2000 14:09:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 14:09:32 +0200 (MEST) Received: (qmail 21629 invoked by uid 0); 28 Aug 2000 11:18:51 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 28 Aug 2000 11:18:51 -0000 X-eGroups-Return: sentto-1101623-669-967461523-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 28 Aug 2000 11:18:46 -0000 Received: (qmail 8282 invoked from network); 28 Aug 2000 11:18:42 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 28 Aug 2000 11:18:42 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 28 Aug 2000 11:18:41 -0000 Received: from f-cpu.org (nas3-43.ras.club-internet.fr [195.36.203.43]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA17931 for ; Mon, 28 Aug 2000 13:18:37 +0200 (MET DST) Message-ID: <39AA4A85.83CB8FAA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 13:18:29 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] about the webring Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 001e037fbde7773f0550ddaa8f0feda8 Status: R X-Status: N hello,

Jamil and some others asked about the webring.
can these people, if they know interested people,
ask them if they want to join the ring ?
i think about the opencores, and potentially
almost all project in the opencollector database.

when the ring is ready, Graham should also announce
it on its site and on comp.arch.

Could Graham also add a "random" draw ? the sequencial
order can be boring sometimes.

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From graham@belegost.mit.edu Mon Aug 28 15:45:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01558 for ; Mon, 28 Aug 2000 21:37:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 21:37:40 +0200 (MEST) Received: (qmail 7079 invoked by uid 0); 28 Aug 2000 13:45:59 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 28 Aug 2000 13:45:59 -0000 X-eGroups-Return: sentto-1101623-670-967470344-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ef.egroups.com with NNFMP; 28 Aug 2000 13:45:57 -0000 Received: (qmail 8199 invoked from network); 28 Aug 2000 13:45:43 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 28 Aug 2000 13:45:43 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 28 Aug 2000 13:45:42 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA04193 for f-cpu@egroups.com; Mon, 28 Aug 2000 09:45:42 -0400 Message-Id: <200008281345.JAA04193@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <39AA4A85.83CB8FAA@f-cpu.org> from "Yann Guidon" at Aug 28, 2000 01:18:29 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 09:45:42 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] about the webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7687804c380718808bdb61c1f4102f9d Status: R X-Status: N >
> hello,
>
> Jamil and some others asked about the webring.
> can these people, if they know interested people,
> ask them if they want to join the ring ?
> i think about the opencores, and potentially
> almost all project in the opencollector database.
>
> when the ring is ready, Graham should also announce
> it on its site and on comp.arch.
When we started on this, I was really thinking that the
webring was for f-cpu related groups. I don't mind, whatever
people want - one big ring, several smaller rings...
now the machinery is there adding extra rings won't be
hard if someone wants one. But could we try it out just with
the f-cpu sites first?

>
> Could Graham also add a "random" draw ? the sequencial
> order can be boring sometimes.
Done.

When do you want to announce it? I'm logging off for a few
hours to save my phone bill/my wife's patience; then will have
a go at adding some of the images you sent to an example links page
tonight. Then tomorrow maybe could we test it first by adding
a few 'real' links instead of my test ones then maybe go
live after finding any remaining bugs that turn up then?

Graham
>

From Yann Guidon Mon Aug 28 17:10:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01567 for ; Mon, 28 Aug 2000 21:37:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 21:37:43 +0200 (MEST) Received: (qmail 16296 invoked by uid 0); 28 Aug 2000 15:13:59 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 28 Aug 2000 15:13:59 -0000 X-eGroups-Return: sentto-1101623-671-967475479-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 28 Aug 2000 15:11:26 -0000 Received: (qmail 11238 invoked from network); 28 Aug 2000 15:11:13 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 28 Aug 2000 15:11:13 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 28 Aug 2000 15:11:12 -0000 Received: from f-cpu.org (nas4-151.aub.club-internet.fr [195.36.145.151]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA17385 for ; Mon, 28 Aug 2000 17:11:07 +0200 (MET DST) Message-ID: <39AA8102.9B6E4352@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008281345.JAA04193@belegost.mit.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 17:10:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] about the webring Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3e2c15e8c51c059a7b4221c0fcf43a5f Status: R X-Status: N hi !

graham@belegost.mit.edu wrote:
> > hello,
> >
> > Jamil and some others asked about the webring.
> > can these people, if they know interested people,
> > ask them if they want to join the ring ?
> > i think about the opencores, and potentially
> > almost all project in the opencollector database.
> >
> > when the ring is ready, Graham should also announce
> > it on its site and on comp.arch.
> When we started on this, I was really thinking that the
> webring was for f-cpu related groups. I don't mind, whatever
> people want - one big ring, several smaller rings...
> now the machinery is there adding extra rings won't be
> hard if someone wants one. But could we try it out just with
> the f-cpu sites first?

when i read david cary's site (he posted an url) i thought
that the f-cpu was a bit isolated in its utopia, and each
one here has more than the f-cpu in his/her life.
the project couldn't exist alone, ex nihilo, and it rememebered
me that the f-cpu is like other projects, a wandering through
concepts, ideas and techniques from different horizons.
Plus, even though i try to keep the "utopia" very strictly
"orthodoxic", it's not limited to anything by nature :
the project has dealt with a lot of concepts like MISC,
TTA, memory mapped registers etc...

and it's a good occasion to have fun too :-P

> > Could Graham also add a "random" draw ? the sequencial<= BR> > > order can be boring sometimes.
> Done.

wow :-) you're an incredibly fast developper/debugger :-)

> When do you want to announce it?
don't know. You're so quick that i presume that it will be
running full steam in some days. otherwise, we can start to
"take pre-orders" and i'll manually add the urls when it's ready.=

when i write this, i hope that i won't have a mail flood ;-)

> I'm logging off for a few
> hours to save my phone bill/my wife's patience; then will have
> a go at adding some of the images you sent to an example links page > tonight. Then tomorrow maybe could we test it first by adding
> a few 'real' links instead of my test ones then maybe go
> live after finding any remaining bugs that turn up then?

this sounds too good to be true, but that ran so smoothly
until now that i'm confident :-) and there's nothing to lose anyway.

have fun !
maybe that when it's ready, i'll have enough neurons to
restart the old f-cpu licence debate ? :-)
> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
From Mon Aug 28 21:00:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01597 for ; Mon, 28 Aug 2000 21:37:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 28 Aug 2000 21:37:50 +0200 (MEST) Received: (qmail 13815 invoked by uid 0); 28 Aug 2000 19:01:03 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 28 Aug 2000 19:01:03 -0000 X-eGroups-Return: sentto-1101623-672-967489225-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 28 Aug 2000 19:00:32 -0000 Received: (qmail 15922 invoked from network); 28 Aug 2000 19:00:19 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Aug 2000 19:00:19 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 28 Aug 2000 19:00:19 -0000 Received: from localhost (graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA14959 for ; Mon, 28 Aug 2000 15:00:18 -0400 To: fm In-Reply-To: <39A9F302.E9465D02@f-cpu.org> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 28 Aug 2000 15:00:18 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring artwork Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb14ad007a65c5e00273f1a6ab24e1b6 Status: R X-Status: N Whygee,

I can't read your gif files using the gimp. Do you know
if there's a problem my end (eg I'm using an old version
(its 1.0)) or are you producing magic windows-only gifs?
Could you generate pngs instead?

Graham
From Yann Guidon Tue Aug 29 04:24:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03128 for ; Tue, 29 Aug 2000 04:42:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 29 Aug 2000 04:42:11 +0200 (MEST) Received: (qmail 20146 invoked by uid 0); 29 Aug 2000 02:24:30 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 29 Aug 2000 02:24:30 -0000 X-eGroups-Return: sentto-1101623-673-967515862-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 29 Aug 2000 02:24:28 -0000 Received: (qmail 14301 invoked from network); 29 Aug 2000 02:24:21 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 29 Aug 2000 02:24:21 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 29 Aug 2000 02:24:21 -0000 Received: from f-cpu.org (nas4-70.ras.club-internet.fr [195.36.203.70]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA27376 for ; Tue, 29 Aug 2000 04:24:15 +0200 (MET DST) Message-ID: <39AB1ECC.16854ECF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 29 Aug 2000 04:24:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] webring artwork Content-Type: multipart/mixed; boundary="------------5321D3DFDBAD114A84443B01" X-UIDL: 531ba3bf318e559d5ea8cc45403022f5 Status: R X-Status: N --------------5321D3DFDBAD114A84443B01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi !

graham@belegost.mit.edu wrote:
> Whygee,
>
> I can't read your gif files using the gimp. Do you know
> if there's a problem my end (eg I'm using an old version
> (its 1.0)) or are you producing magic windows-only gifs?
> Could you generate pngs instead?

i made the gifs using PSP6. transparency color was the
purple color. they display fine with Netscape 4.7.
i can also make PNGs or JPG but PNG support is rather
low today (even though it has most the advantages of
JPG and GIF) and JPG is a lossy compressor.
Netscape seems to display PNG is pages but it is associated
with an Apple program/plugin that is run each time
an individual picture is selected. weird.

anyway, it's not difficult to make a PNG version : here it is.
but i don't know how it will treat the transparency in real life.
i hope this helps.
> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
3D""
--------------5321D3DFDBAD114A84443B01 Content-Type: image/png; name="webring1-1.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring1-1.png" iVBORw0KGgoAAAANSUhEUgAAAEEAAABdCAMAAADNPfuXAAAAB3RJTUUH0AgdAg0nX8ltRAAA AAlwSFlzAAALEgAACxIB0t1+/AAAArVQTFRFbFNqSDpHSDhGWkZYJSAlNy02WEVUa1RpRDRC MCgwMioxWUZXcFZucFZtblRsblRqPzM+PTI8PDE6SjxIaVJmblZsfF95fF96RzlGJiEmbFRq aFFmalJmVEJSOjA6OjA4Xkpbcldvd1x0SjpIdFlyeFx2alJoZ1BkOC84UUFQaVJkcVhudlt0 OC42clhwPDI6eFx0dlpzaVJoX0teVEJQdFpyNy42Z1BmWEVWTz5OXUlcUEBOdFlxPDE8eV52 XEhaQzg8QDY7Rjo+RTo+RDg9QTY8el52VkRVT0BJSD07TD9BTEBASj5AalFnLCUrVkRSRDg+ UERAUUY8T0Q8UkZCVEdEQDQ8Rjs7ST48SDxASzxKXkpcQjRAXklbRTo7Rzw/WU1FU0hAUERC PzQ8PjM7S0A9U0c/WEpFUkVEQjY8Yk1gRDc/QjY+Qzg+PzQ7TUI8VUlBRjw7W0hZSjxHOi84 blVpST1CRDk7TUBCWU4/V0w/RTo8QTU+Yk1eSjxBUENCXE5GT0NATkJCSDw+SD09UkZARjhE UUJFVUhEZVdHUEU8el13RjhBXU9IYVJJXlBIYlRJXlFEYlVEaFpJWU1BQTJARDVAYFNFa1xN ZlhHYlVCVEg+TEE7Sj49XUhZPjI8bmBJcWNLdmhOSD47RDZCYlNNalxJRzs9Sj4+RjZBSjpE QTI+Sz5CUkRCXEpUSDlCWEhMQjQ/RDZAel54Zk9kTkFCWkhUTjxMTDxFVkZMOi41W01IbFNo RjZCXkhcalFoXEdZYEpdVEFQUD1ORjZEYktgTDpJSjpHVEFSbFRoaFBkSjlGZU5iZlBibFVm VkNSa1RlalJkcFdpUkBQaFBicFhnclhucVhtblZqc1psdl1scVlqemFueF9sdV1qb1dpf2Zx fGNudlxxdFpwel51dFttfGB5S8giCwAAAAF0Uk5TAEDm2GYAAAhFSURBVHjarZePfxNnGcBT WpY605bcbncsl17pkbu04VYuGUOhaVrSgliIg0krHYdltC7tGII/gp2OlQEb0Qs6Jhfd1Ol0 zp1hRrgoTl8G7ZD1jktMWJkyZP6Y8+/wvUspUux7Lfh++smPT/N83+/zvM/75o3D8X8fLted RPtYUmJJOHy3h2HVdRFJigSZiAoh82f4iH8zEYFofE+IsIIgkSQ7TwYrrfvXRx98dMlbKlz+ cJ0qCNCDnR9AFa79/R/Xrv7THyhcLnyoqvPUYNWIdOWv1z54/28tTl0vFIuJIMkK86iGi1Ql 8sr7V65e9QZKupHXAwE9SEq8OmcESaiq+udLf7lSKBYKASNv+KlEokZVmbkifCRB8InAe+FC 8XKiWJzU84bhTQSApDLE3BAw34hQLJb0yyUoEdBB0TAMkM9rBMPPqRYukpQiTAH6+wOlQKDk T3CU8bg/n58MEww7l0X1kaQgMHAN9UkKUCVdAzEN5jFpmIjgXBA+UmUE00E3dFDnARquASfM A0pokhqESfpsyyAxDA8L4DcmdaezoGmlhFbK5fK5/KRXleRa21KYhCAP8/dPQgmnpwCAF4T8 EJEv5cOEvMo2D0gQggwIBPwxI5fTPJqmeTUd5HJ+E+GQxVq7PCyC1AIoLZYz9Jgn4dViAODw DazE5HhGfBsuqV07CEGh0QsA8OcoP3BqXkCBGAV7czKfG5dl8ayNhEWQeOB0Ai6Xp+D8Bc6U gIgc0GU5I5626W6LwAoaXMOYbkrAaI1KxDi4orpHlssSLJrA8AJoBBrgYrkclIjBF94EoIz9 xv4MlJBXSUgJn7mc/BgAnpim5UwJDQdOvwY0KPFuZg4SJoFnxiZqAEwE5A0q5rkE/F5Kw0t5 410TkJHRlfCZaTBjC3IwDc1cDl1LeCmvH6Zj5GVrZDKVSAmzlLxwcQJ4nF4N5PI6p12iigFd pwLnrhMWIStBWjtj6cWcplFOTjdyMQ0UC6VCYGJClq8jzqEkymksvVgPPMAL1Q2/Fits/9MF +cbIZDIoCZeZBjMGJWBHUDrspLF6ecbIZF5GSUCCCkv5Tr0GcN0/cUG+dWQyJyVEb1tpjC24 8E7l2IQ8y8ic3I7YYC6rlgvOn5dnH1CCREjAw7AlfFpGjkxmm42ER0AT5OoFKAn4v9rwORvC +T8iJMwTv85O4vx5O4lldyxx9o4lWpa9ZSNRPYaWIM+SNhJpxU4i7EETRGXcTkJ4G41QUrU2 EjUOmzRSK+wkeKSEKKeydTa7YzYJcepRya6w2R1ng6syt0aLZYL5lM3eayNRx80IFqcJ1rOY HSdsJBpXzZz9JgLsiVpi9vMOSoRD0q3R4n8lo7w6jrjgWRIt7dOfno6+kZNyRlFqSRuJyAx9 8YZTtaKcUtJjqFumKWHu8hkZlNcTGsD4tBgjEBLWLuf/R7j1Op1On0qLMo+8LZtHTe1bMypg rUFaFMVq+CinJROBlODYWzsqrZQJ8G2W583bMkqipgbcBFBSqTMQYCLMTPa9GeYZCS0Bgqen 5oZ/Z7JK6swZJbVLhGWohpQTQ/vDDMwDKcGHplswm03BFUhNOfxeFNN/6DERCAnYVoTKnM5Y hOzvssqpUynFqiNMAr5IH00OvYkjf3nAKqlSrtzCpkA6Bac/KZb3GCTFk0O/+S0ukEgJkuAf MY9Fc/nNXi6HW3UVjyS7Xh/p2o7bSJCME/bwybSYVW40tnm/lcUj8T1D+wbaOdSJWb4NtMKN nMoq1vxT4WYO8huP9YxEe3+Nczwx+4WdJQmSeVBRlNR0vKhY+Tz9RnJHz+iJweFnfhULMeib FcvcpfzSjIIXUrMT0mm5Lf7ai88fSA6d6KT7ohuWUC2IK7/PrGX41bKAFS8e/fmO46+9cOxA cudI3+DhX6x5/TmKs7mlsszLorWl0+kfx3/yyis/PbB175Px5OhI/zD28M8ODjfjoTDil4t1 XZdMg/SR+Pf2fP/Fl176wd5jP/xR8mB3/1ODh7eMbsRWc3iId6AkJIbctis1lIwf/fZ3nj/2 wnePH48nd3b3RZ9wD8Z3du9uWxwKcR4HUoJh2fV9RyBix9Deb37r0fjQzpFD0U0DWNvolpHD GE1v5zjOgZRgGWZ/59Mjo6NDB4af2TN6sPtQdHfvIH342Y6Nh9Y+RdPP+SncgZQgeMZV37ev f+POr42s3drfv6mjF3N3PPn1byxv6MQegIh2HEmAbcUwroc6n9gdjXZ1de4a/uLgcnfHnr3x zV9aOTzw5eBXvko3JTxIgoskWBe1HhvsHRjEBhZhbpr+wmOwGN39w4PY6vDju5roeqfDRoIU 8O3Rrr7Pb+in29qwzh2PboaL0TlAY1gzHr4Ha1uEBli9jXMPdXds2vzwZ7f09Gzq/dzWvmiv +5H2JozGcdc2cWWFw1ailqPWd2Idn+7e0L2xi3Z3rV3kroyEW2m6NUZ5mj9TZUNwmCd/qL1j zZooHJ1d2FoMW7oOLrKziaYp3POpqio7CVjMEEU1wyK00Vib2+1uqIwIPMOEWxvoZrzWUVW1 0E6CJVwhCl+NYfcvbm1tbsawJsYaYdiSnhpH5eJKO4KDZT0czlVgDQ2f8FOBT2J0RRlRSTet sg2eQgRDHPcARjetgIQHG2D+FoFYeV+V/fxTiBaOwxc30MshoZGi6aWCAL812Yo51GAawXH+ JVCimQos45fS91Os9YW3sGrOEg6Hh/LW03TDEryRMSXKp2PlPCQcDmdt3SI3dg9+L0Euvvu+ qakX2jbDDEj1x+7+uNNVM7+pbxrXQ+eV/81jKvSuO5KomCLdJsFRsaBMqrjdLGYZ/wEcJPw7 KMpmHwAAAABJRU5ErkJggg== --------------5321D3DFDBAD114A84443B01 Content-Type: image/png; name="webring3-1.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring3-1.png" iVBORw0KGgoAAAANSUhEUgAAAEMAAABNCAMAAADKHikxAAAAB3RJTUUH0AgdAg0Znqhw7wAA AAlwSFlzAAALEgAACxIB0t1+/AAAAr5QTFRFbFNqVUNTdWRzhHqDamBpc2JxjISMjISLcF5u hHyDZlVkgnmBcWlwZFJibllsZl1laFZmYEtfgHZ/loyVWk1ZhHuEdGlzfHN7YVVgcWBwjIOM pJukaFpnYVBgfnV9joaObFhqdnF1dW11ZVlkY05hXlFdbWVteXF5bGJrOC0yJiIhYFVejoSN eW14kIeQkoySXk1dlIuTZVBkcWVxdGxzST5FKiUkKCIhOTU1eHB3WUZWoZihY1xjc2JyalVo dWp0aV1oioGJXVZaPTk5JyQiQT0+hn2FnJKbYE5eiH+ImI+YdGNzaF5ngHeAU0xQKSQiLCYl NjExcGhuh4CGUkVRcGZvcGFviH6HeG53amJpSTpFREFAmI6XSURFWFVVZFVicmBwpJujbF1r alloMi0tT0xMMCopkYiRkIiPXEpaWlFZaWBoTUZKQj5AbGRrZE9ioJefZV1jaFJmRTpBS0hI XE1aiICHnpWddWR0kIaPW1RYLSgmV0ZWm5Saa2JqWVFVX1xcmZCYfXF8WUhYjIKLpZylQDo9 YmBgMCwrcFtuXFFaXVVcT0hMVVBSUklQbl1ta2FqWEpXVEZTUUpNLiooamRoXktceGd3S0FI bmltjoWOjoaNfHV7VU5VMSssYF1dXlpcoZegODMyUU5NNDAvPzQ8SUYWVlJUeXR4PTY5dHMH T0wTTUkVREA/bGoJNC8eZGIMPDcbUE0UPDgaVU5SYV4NbFdqMy8fNTEdYmANcG4IeHcFXFoO T0wUb24IeHgFZWJjZWBkXlwOR0QXTkpKXFlZOjYcW1lYc25ySkhHeGp3bWJsQDk7WVYQNjQy QT0ZODMccXAHdXQGUE0Tc3JyW0dYOjYbdHFyVVISWlgQYlphODI1XFoQbWlrSkJHcWNwUEdP VUtUW1gPPDgcOS80Qjc+WE9XZFliYVtfVlRTTHa7JQAAAAF0Uk5TAEDm2GYAAAj+SURBVHja xZj7Q5PXGcePRRSTAIEIAQZBRQK8ohWM5yWKQOQYoQu+rygXA0gHSlQcaLy0qJujsLbWKXai rdNpB66bLVUu6sBLXZ3aVu1m221d3WZ3cXb7L/Y857xvINYLjB92hMSEnM/5PvcDhPy/VnPc tnEzkuyzxrU/O6WZ1HvuecfDeGAypyxjisIheV8ljlmDOYqk73gTCIrycr7NUZfmKxsjImpv 7K79pySmyMD4yOeztCQXvzgWgD+ckLK7x2G3zL//kxgebwrLixgD4vDdif7dt2WG22UmU0Wq 7ehIvBXtGS0g3E+STHvvCwliyf8u9rUfa88yjhJR1Lhh7qzbCmpgEuUkqnzhNFVsNy6KGg2g NpuYy5ZloAVCBn+gynF/HvGTsIJRIPbfMjzYfAolCABlAkaXNx1LM1nb3U8DGAj52r7hPmOy pDBZGEE1hxzxravOTG6/+RTEA3tbyn4JogAMOBmCgSQqUPu+Do8vTfQ/MbaQDpH2f0monweU gRVAYJBiXIo8taODlKfNeDyh+bUDE+oOSowJF6ATGE8MhSc6WLQvZo4rzd3qexwhjyRNPHIf AikrEvqhB/dzj2iBgSSbPsXhmuLOfwxhfdysbM9GxvfjycqNSwLFhnNMVk/6wd7s+FuPAPj9 JNxj8kr8XJlREEDP/RPcqpxhGF/0BZpDGxrTnHWVFS0TvoFYufnv/rKNCloBh/3jBrpQPo0v bwzhOzLVk+zQnKXPuXxHX3ooUfMI+Vvk3flMhBNO6+9Hp355Awy5c0GczxeoU1avqi+YXnf+ IQ2vN4YnVd4DCxRZwkgqck8/PN4ZwpPf13bz5ECTpJn1ieSrWFuwjlmOqSclTQHPbamnHyTd gXcGT9+BrZoOnqr0ni2hwmqrzgryh+Hun8EPil5cyOrvGezvv/SXvoGhQTiZiuRi3KX0r66j R9dNrgwbiViwnEtAXyjSpc855E+fXuHrS8pFyCd0FUBbHkea8w6fH8H4Qwb4QMJM4mnxm97e M+xM7xV9/ZFxbV8wzSnw3dkRm18QWzIitpIkcfX8AfKC9V7u+yyAuPI5hyu/hx+DDvxSato3 VbcnZFXMHGZgOHQAL7B3Lw4jPuvjpVL4SkCGoqw1FXhcH4x0h8QrQkDwn9I3TPj0bZ5WH18v 1PajEipHmaeRabFWPbb+eTL3JywuA1Lq4ggClvvW6zmU6rHB/6wpdRuPWRNa2zRGZAvuVlSR HL8bVJjuzt4BrurahzlgXyA5IGPp2Rbfs5ZJ7pt6pjojZUmL7CcXL5y+8MmAhhjAwqPXPlyO ZXuykOo9GXT8NmV90qLnmzWHhNsrC7BKsVtIPJvZkMbAt9l73cKV73ULS2Q0SpWmxoeV16e5 diHCPKM414iOkCXRqpgyqDsDGzjje2FVdes1g69uG7Na3CEWXx0ybtlTrRWSLMl6aBT5ss6g 8IrBXuzGdPVakIAEGSH7bE1W1/Z5ek82V26TeOOVJW7w5QCDt7+uLrCTfnw9B11JqUr5k7KF kIjsaTd5bIs8xjITGM4/z5QbV68O9Ads0afbWggMj8pOVYttw1mrLfYjY7UZGQdsDrtPMKgs XR0ahHIJ2MJTgl273iXrnhBflNa0ty71ZVYb9yDjvIHYPBI/j8nnBnjJvK/rwM8v/3VXoPC5 BhUxOR+YO+yH6kV6FBnKTClYLZRXC8jvG1J6Llx859JlsQtiK+sVH5BBmTe8PC+i3FiEjL2z VxQclPjxojoHeuHjvxoMXDUgtlo4BAKeVEVdU+pyGZ2ZrW8go6wsNfosE6OAVxsilHPaQAMn VUF+YKLz4/kzdBNa42q3ZB11l3Njskmq85SCYeWdtK8Xn/oH9DnCbREWyJpDBGtDdrNZL/2k RpN9Pu9hfJieRi1nepEgKXw+gw5xvl76wFMLlZG33HSbybRbHMFvBnjcuz1aZclU+CNw7eDv qp2dDepIRqJhZfRGnOvaPYeCnnc4iYlxcqKbC8ADkKSqnQ1LKMsImiuGSNPPFXHP0EfL2yJC uKm7W28bIqhqw87OX/zy1ILg0eSc0nhQZrLeKmVkUdEout7qFptlbcru7NzZRU/asuqDR6TJ 9NOSHXpz4bNd75pQJkogHGgJEI6feMvrjfnZ7GBGdlSKdQv3poSuEDdpOhwFVIVeoupOKLiq 4mOEzM7alB3ESPI4mt7kOY4VwyMsa41XU8ArT1XVJUcKvaE/WbieRBiPxgcx0kvSILZiOlHt AqkPkUCNgAaqNCWHkj3uTWmE2HxvBDEK4lKNB5mstQ99CokJy5sNEjprDklea2s0IbGTSw4T d/UzwQ4JP2Dyir1469A2Qw8UMxatoDTHmdxG0lsWmkloxYrXScqPg68deytDPD/inRQYoji1 3MDSAsKr+7Zm7C9e2EGaS1r2km8n+8zk4eWo3GBcHLg1KsIpTHgEJKi0yl1JSMlSF3w000n2 vLb+GwhiaE6c8XIAMTyEUIKa88qrGSm+6igSWjzJQKKrQ8gjV1FufqmXcfex4dxgSKDSqoQU Ut/+wzqyK9oXRiK3tT2a8X1jqX23nud6baOIwh8wr631JULS1pWQtuIXFpHHLntirXEHeEEr M0gpFUcAzXG4d0FGfg9+0akwkmZP7czHM+Dm0LRF1szg5Q61uXUr27b9hSISUWGJJC+2WMiT 14ZYa+NGxkTvpiKzvxvSRJpjNlmhIjM3k7rGuU9G1DpsubbF4u6Lg1Bds7YBQjGJkHnJ69aT aIsDfjl+igySOjfMVIMKmOi1q4tryfOZ36kjSdHJ9aTMU/80AME/JOSv8mIwIRQ5VSzDWh0L RZVlJWHF1eVPl8DTw1Pi8CzDsoB7a+mKlaTMYplJyt0VJKkyN280BPhlIT+9wLUYjCgsZEvc S4uIufi5OKiKOYRMGB0B1tzseY75VM5xmhaQmIXQHJwJuWSRcyx/2JiZak9LJxnSrEwIxew5 z84FX5hGEYqRyxAbYo2D5/iEbyWSJFvyNDJ9RspYALAiIs3izGhLNJkaYwklUWPSELTCQqYQ g9EU/j8DYIVOmjyWUDxyPRMycXwAXOPUMK71XzM80sV0nAjuAAAAAElFTkSuQmCC --------------5321D3DFDBAD114A84443B01 Content-Type: image/png; name="webring2-1.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="webring2-1.png" iVBORw0KGgoAAAANSUhEUgAAADsAAABPCAMAAABiSE1WAAAAB3RJTUUH0AgdAg0DY8qJlQAA AAlwSFlzAAALEgAACxIB0t1+/AAAAsRQTFRFbFNqYk5gWU9YT0pOUEdPW0xaWlVaXlleX1Be W1FaZVFkZFBibGdsaFRmX0tdU05TV0hWaV9oa2FqVUtUXVNcalZodnF2ZlJlY09hYFtgY09i bmluamBpZFpjXlRda1xqe3Z7Yk5hWE5XXk9daWRoe3Z6bl9tT0pPaGNnaFlnd3J2XE1bWVRY aVpobWhsaFRnfnp+blpsX0xeXk9cbFhqc2lyd212Z11mb2VudWt0gHuAZFBjbGdrZ1Nma1dp alZpdG9zaV9pa2ZqcGdwfXh9dXB1ZlJkaltpfnl+b2BtZl1ld3R3b2Bua2FreHN3eHR3dnJ1 gHt/dGpzgXyAZVJkcGZvdG90bF1qfnl9c25yfHd8bGJreHN4bGJsfHJ7enV6aVVnbVlseG53 dmx1YlNhc2Rxa1dqenZ5fHd7bmltalxoenB6cGFvY1licmlxZ1NlaFpnb2ZueW95XUtcUkZR QEBARkZGTExMUlJSVlZWWlpaXl5eYGBgZmBma1lqeXR4cWJwWUZYOzU6NDQ0PDw8VFRUWFhY XFxcYmJiZmZmaGhoampqbGxsbGVsV0VWIiIiSkpKbm5ucHBwcGpwVEJTLCwsdHR0eHh4enp6 fHx8fn5+cnJyg36DgoKCiIiIioqKgICAUUVQZGRkUFBQSEhITk5OhoaGjo6OkJCQi4aKPj4+ kpKSdnZ2aVxoJCQkOjo6REREbVpraFxnJiYmjIyMlJSUd252GhoaLi4ucW9xKCgoNjY2ZmBl Hx8fMTExZ1pmKioqODg4QkJChISEVEdTMjIyYlZhMCovPjI9XFBbHBwcWk5ZKSMoa2VqXVFc QTpAWk1ZUENPV0tWVU5UalhpX1JeXktdWFJXYk9gSTxITUdNWlRZRjlFWEVWWkhZWkdYWVJY RD5ERkBGWlNZY1BhT0JOYFNfU01TXUpbW05aYVVgYlVhVBmPlQAAAAF0Uk5TAEDm2GYAAAV1 SURBVHjarZb5dxNVFMcHNwRFBS2ooK2iKCi21aJYLUVQQMEFyqayCYqKG6JtJ0tFCJPMhpMZ YCbJmLS+Jm1tQxmxKFJFmDruK+4LoqK48E9438sk4ClJ+8D7wz3fcyaf+d653zdJGOZ/rAN/ H/rn8OFD+6jB7w6xXp8fly/451805B8HQ34+Uwjx/uDc/nseDGU4B0hcfOj3fqK/ecGTZYFV ULbY/f1Cf/GxtsPaNoybYwXh136QPyf9PLCKrTj2UayUPNAnuj/s5x0WaNtmnV05VlS59X2y P5L12g6ybUCAtThia3oDP/WB/uAjKHCE5ZDiBCx4Wjkd3LCnj3CCJBkHnpfjbMfhsLElCKJm eKzu7wuy35KJlU7b5hBncZaFkAOoIEdMLty+E23Pj37jJecIntNRgOOsIHEVJD0ueVJ1ewN8 fvprH16TwzlAJ8GSEyxsLmo9Ed7Lhmt3p3jUkIet9SPW5hQbTwo4J3CK0m15tHiLyoc8zXXb HA+Pth6bTfkhHM7hSDCK5Sh1eGKtqcsQkd/L1dsBx4fQV3lYhCdFeFKu0+IAhBXHW2OqJPC+ IJts39MsCF8ek7X9meOgKI7lEUhJeqKtyVRlUfCHPCmrGw+yb6vQm/3cz+FJnXrBLVGNtrU1 6aamSiLy4XXViSK+8EUvdh1nd+JMc6TRuKMxltYBlmFqvK56EFBOb+PPfJnbYlDWIomO1ngk nU5jYzmzrqAmCaIk1fZmNzshSYZSNdOIN7Y2EjJNjGFqvC5Bl3yc9Mmnx9jWx7tTSEtHYvGe lp5YBKB0DiZTe3Vd9Nh5jseHO2tTXl7E7iq4u2xuaimqiamP8rDvdwbakynO60eihFmADcOF YUvRqMw3f5DvTL+3Za8dZoMhHraVMTYwnJna6NHFEJcPZd5RnPY6MPbBl4U7dAYG43QiJqPQ u3nZ1bv2gHGzJwRTHzEmsNHYo8Gy86LMm+G3dm8gxnzW2MjA0a5GXRTQ2/lZ5A/s6q5N9jI2 mlq70pIkNjAFWD78+s5tVj0X/I9xpKUDUFl+o7QAu50PvtoZOMoYYjKMWNeOhC6pqvzajQXY rYiv79wCxuwR42hLR0eTCvfRXqmuqSg0NPKnAviAeLzE2Iy0tHUk4FFNU4XLGx8rwL6EBORr TiZTYIwkM9rS2pYwVFnTzU0vg+eIGcUF4AYBv2VQqh6NJxoTTbosyqaplzNrlsDlWSUF2M1b yNurG5FoLGqYKtxFM81NcKXoxXLoM58vAL+ghIHG7xLkKYr4hdpUTq4sXgtt/OyqAvC69YEN XNAbgv8q8EpI8sbcmI/MgjZlAlOonnm2tq6e9cA/nYZVzzHM2uyYC8qgTapZyfS/VlcOcdX8 qdCeXkPBMsufdEVFTTXDPFVWTsEeOU5zlkN7YimN8bzscSqtJDk9TsFOW7jKVfcvgja9jMZ4 zMNZRXJ6dCoNPO4hVyyYAW1lzSQK9sGaZa6aPw/a1OU0xitWuILkVEWV07LKB1xFchq1iMZ4 8RJXVM3Gnktn0cD3jXEFyal4Bg274NasKsGe986jgedPzN5lIdlZEQVbUZb99GTsOeF6GuPc p4nnXKqchuQ+PQffZdg4GuNR97iilORUMoYGnplN9c67oI29m4adnku15HZoI++ggadk375i nHbRbdMo2EmV1a6ajNO+ZSiN8cTsz2hFJeR0081VFOzg4dnvPZL2oBtojMdf44pSnPa1A6+j ga8c6wpyNq66moYdfdkAV12Oz8YVo2ngiy52RXEJtEsupWHPv+BCV40cRcOROvc8VxQNH0HL nnX2Oa4aOozaeHBWnHHmEGo4V4MGHj/LDDz9+NlTTzsB45NPOX52wEknYMww/wInrhB38KlK RQAAAABJRU5ErkJggg== --------------5321D3DFDBAD114A84443B01-- From "Vincent Penquerc'h" Wed Aug 30 20:36:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01468 for ; Wed, 30 Aug 2000 22:15:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 30 Aug 2000 22:15:34 +0200 (MEST) Received: (qmail 8796 invoked by uid 0); 30 Aug 2000 18:40:53 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 30 Aug 2000 18:40:53 -0000 X-eGroups-Return: sentto-1101623-674-967660793-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 30 Aug 2000 18:40:46 -0000 Received: (qmail 32439 invoked from network); 30 Aug 2000 18:39:51 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 30 Aug 2000 18:39:51 -0000 Received: from unknown (HELO calcaphon.demon.co.uk) (193.237.19.5) by mta3 with SMTP; 30 Aug 2000 18:39:49 -0000 Received: from vincent ([192.168.1.81]) by calcaphon.demon.co.uk (8.9.3/8.9.1) with SMTP id TAA11170 for ; Wed, 30 Aug 2000 19:38:34 +0100 (BST) (envelope-from vincent@calcaphon.com) To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 From: "Vincent Penquerc'h" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 30 Aug 2000 19:36:19 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] faq and archives Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f5b11a5e6259a0bd9b0245c4b6a4a36e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Hi,

I am new here, and did not found a reference to a FAQ or archives
(other than clicking on each message one by one :)) on the egroups site,
so would you be kind enough to point me to the right place to find a
FAQ and an archive of messages on this list, if these exist ?

Thanks in advance

--
Lyrian
From Yann Guidon Thu Aug 31 01:04:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02420 for ; Thu, 31 Aug 2000 02:31:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 02:31:22 +0200 (MEST) Received: (qmail 6406 invoked by uid 0); 30 Aug 2000 23:04:57 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 30 Aug 2000 23:04:57 -0000 X-eGroups-Return: sentto-1101623-675-967676692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 30 Aug 2000 23:04:56 -0000 Received: (qmail 16568 invoked from network); 30 Aug 2000 23:04:47 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 30 Aug 2000 23:04:47 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 30 Aug 2000 23:04:47 -0000 Received: from f-cpu.org (nas1-207.aub.club-internet.fr [195.36.150.207]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10265 for ; Thu, 31 Aug 2000 01:04:44 +0200 (MET DST) Message-ID: <39AD930C.DE41CC2E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 31 Aug 2000 01:04:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] faq and archives (LATEX manual anyone ?...) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0020731a9b5c3a0878b30522aeb01cfc Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello/kenavo ? :-)

Vincent Penquerc'h wrote:
> Hi,
>
> I am new here, and did not found a reference to a FAQ or archives
> (other than clicking on each message one by one :)) on the egroups sit= e,
> so would you be kind enough to point me to the right place to find a > FAQ and an archive of messages on this list, if these exist ?

first, welcome.

then, most of the f-cpu ressources are located at http://www.f-cpu.de
you'll find links to existing and past stuffs. There's even a link to
the FAQ in the online manual that you are meant to have read already ;-)
there is AFAIK no "archive" at egroups. They simply store all the= message,
that's all. i may generate a searchable archive for use with Netscape
but the file might be huge and wouldn't reflect what happened before i
joined.

Btw, my master thesis is finally coming to an end. give me two weeks
and i'll resurface an assembler and probably the emulator.
i hope that the manual in LATEX will be released soon too :-)

> Thanks in advance
regards,
> Lyrian
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Thu Aug 31 06:09:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00355 for ; Thu, 31 Aug 2000 10:09:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 10:09:12 +0200 (MEST) Received: (qmail 24561 invoked by uid 0); 31 Aug 2000 04:13:53 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 31 Aug 2000 04:13:53 -0000 X-eGroups-Return: sentto-1101623-676-967694968-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 31 Aug 2000 04:09:39 -0000 Received: (qmail 17131 invoked from network); 31 Aug 2000 04:09:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 31 Aug 2000 04:09:27 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 31 Aug 2000 04:09:27 -0000 Received: from f-cpu.org (nas2-240.ras.club-internet.fr [195.36.192.240]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA29060 for ; Thu, 31 Aug 2000 06:09:25 +0200 (MET DST) Message-ID: <39ADDA72.DECD5CC3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 31 Aug 2000 06:09:22 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] the ring is up ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9ee11e5393d0cc5fda8c87c29aba9891 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello,

the Utopia Computing Webring is working.
still there are a few details to manage but
you can go look at
http://opencollec= tor.org/cgi-bin/utopia/index

Graham did a really good work ;-)
let's have fun with VHDL now...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Steve Van der Hoeven Thu Aug 31 06:15:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00358 for ; Thu, 31 Aug 2000 10:09:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 10:09:13 +0200 (MEST) Received: (qmail 25835 invoked by uid 0); 31 Aug 2000 04:15:58 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 31 Aug 2000 04:15:58 -0000 X-eGroups-Return: sentto-1101623-677-967695308-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 31 Aug 2000 04:15:09 -0000 Received: (qmail 12122 invoked from network); 31 Aug 2000 04:15:07 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 31 Aug 2000 04:15:07 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta3 with SMTP; 31 Aug 2000 04:15:07 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id XAA27757 for ; Wed, 30 Aug 2000 23:15:06 -0500 (CDT) To: fm In-Reply-To: <39ADDA72.DECD5CC3@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 30 Aug 2000 23:15:06 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the ring is up ! Content-Type: text/plain; charset=X-UNKNOWN X-UIDL: 24d2ad22aa29f7d52d20bdc206ff7210 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by WintelPC.Potential id KAA00358 Status: R X-Status: N -------------------------- eGroups Sponsor -------------------------~-~> Get Your Free PC World Newsletter Today! http://click.egroups.com/1/8237/15/_/3462/_/967695308/ ---------------------------------------------------------------------_-> I have learn to not aplause before the pianist has finished playing, but it looks perfect. --Steve On Thu, 31 Aug 2000, Yann Guidon wrote: > > hello, > > the Utopia Computing Webring is working. > still there are a few details to manage but > you can go look at > http://opencollector.org/cgi-bin/utopia/index > > Graham did a really good work ;-) > let's have fun with VHDL now... > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus." > F. Couchet, APRIL.org, 8/18/2000 (contre les portails à la con) > > > From Steve Van der Hoeven Thu Aug 31 08:39:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00382 for ; Thu, 31 Aug 2000 10:09:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 10:09:21 +0200 (MEST) Received: (qmail 30825 invoked by uid 0); 31 Aug 2000 06:39:47 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 31 Aug 2000 06:39:47 -0000 X-eGroups-Return: sentto-1101623-678-967703979-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 31 Aug 2000 06:39:46 -0000 Received: (qmail 27967 invoked from network); 31 Aug 2000 06:39:38 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 31 Aug 2000 06:39:38 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta3 with SMTP; 31 Aug 2000 06:39:38 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id BAA29598 for ; Thu, 31 Aug 2000 01:39:37 -0500 (CDT) To: fm In-Reply-To: Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 31 Aug 2000 01:39:37 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Let's come back to an old sugestion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0a3622bacbda20ef7de170c27214703e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


So there was an idea about making each processing function write/read from
his own specific register.

And as far as I have seen in the docs the f-cpu is currently designed with
one independend circuit per processing function reading. and then two
register selection units that can can be linked on the fly to whatever
processing unit though to different pipes along which is not busy.

So I understand the following stages are currently necessary:

  -selection of the source registers
  -query a pipe to the correct processing unit
  -stransmit the registers

  -make the processing

  -open a pipe to the destination registers
  -write
 
With the othere design you have only:

  -move the data to the processing unit's registers
  -read the registers
  -process
  -write the registers


In both descrition I have omitted the interference of the micro code
execution scheduler, but I think it's influence is linear as it touchs
every stage.

advantages:
  -shorter the instruction pipe decoder
  -shorter operation latency
  -simplify the micro code execution unit
  -remove unnecessary silicon.

The disavantages:
  -less registers where you can put data data you will need very soon
(in some cycles).
     Can be solved by adding more registers (by wiring some more
register adress bus), this has made the compliers more performant on risc
architectures because they have a lot of directacces memory,and the
compiler has not to make a very fine analysis about how to distribute the
data between the registers...
  -more moves but you can do them in paralle with the other instructions
or doing them a half cycle later because a move (reg to reg) is not a
processing function. So moves would take less time. And I think if the
compiler would do a good analysis of the code there would be no more
moves.
  -make the compilers smarter. ;) my job...
  -a step further from the 86 architecture. :-)


Okay this is just my idea....

one other question... the cache memory. I have seen you have included a
prefetch memory to cache instruction so that a program can indicated e
better caching management for it's data. Do you want the cache management
to be integrated in the assembly code (great, but should see the influence
on the code length),done byt the cpu, or done by the chip set?

And some time ago I spoke also about the memory  being accessed at once
(no segmenents).
With a compiler generated caching management it could be greate, because
you could do some semantic analysis wich could have much better
performance thant the tactics as "the last loaded is the most important"
or " and cache the memory along the data and not the segements.

But this would change the memory architecture... yes if you want the burst
mode (align the memory pointer to a segment, and all the segement
bytes come one after the other with no other memory query).

Does somebody know the rambus philosophy?

We have also a

--steve


 From Yann Guidon Thu Aug 31 17:11:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01420 for ; Thu, 31 Aug 2000 18:06:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 18:06:11 +0200 (MEST) Received: (qmail 23086 invoked by uid 0); 31 Aug 2000 15:13:09 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 31 Aug 2000 15:13:09 -0000 X-eGroups-Return: sentto-1101623-680-967734721-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 31 Aug 2000 15:12:10 -0000 Received: (qmail 24404 invoked from network); 31 Aug 2000 15:12:00 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 31 Aug 2000 15:12:00 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 31 Aug 2000 15:12:00 -0000 Received: from f-cpu.org (nas4-74.ras.club-internet.fr [195.36.203.74]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA23350 for ; Thu, 31 Aug 2000 17:11:56 +0200 (MET DST) Message-ID: <39AE75BA.A6BAEAE1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 31 Aug 2000 17:11:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] the ring is up ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2394f64faef817edffeb04c58844d743 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

Steve Van der Hoeven wrote:
> I have learn to not aplause before the pianist has finished playing, b= ut
> it looks perfect.

this is thanks to Graham's work !
what a professional's job ;-)

> --Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Thu Aug 31 17:11:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01423 for ; Thu, 31 Aug 2000 18:06:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 31 Aug 2000 18:06:12 +0200 (MEST) Received: (qmail 19722 invoked by uid 0); 31 Aug 2000 15:13:47 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 31 Aug 2000 15:13:47 -0000 X-eGroups-Return: sentto-1101623-679-967734721-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 31 Aug 2000 15:12:06 -0000 Received: (qmail 16506 invoked from network); 31 Aug 2000 15:12:00 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 31 Aug 2000 15:12:00 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 31 Aug 2000 15:12:00 -0000 Received: from f-cpu.org (nas4-74.ras.club-internet.fr [195.36.203.74]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA15102 for ; Thu, 31 Aug 2000 17:11:56 +0200 (MET DST) Message-ID: <39AE75B4.E472B453@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 31 Aug 2000 17:11:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's come back to an old sugestion Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5559d686f54b8000965b7607ea71b95d Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello !

Steve Van der Hoeven wrote:
> So there was an idea about making each processing function write/read = from
> his own specific register.
long ago, i think...

> And as far as I have seen in the docs the f-cpu is currently designed = with
> one independend circuit per processing function reading. and then two<= BR> > register selection units that can can be linked on the fly to whatever=
> processing unit though to different pipes along which is not busy.

that is for the FC0. Other cores in the future might be completely
different.

> So I understand the following stages are currently necessary:
>   -selection of the source registers
>   -query a pipe to the correct processing unit
these two can be done at the same time.

>   -stransmit the registers
this is the "Xbar" cycle

>   -make the processing

>   -open a pipe to the destination registers
there is nothing to open : write back has priority
over the previous stages (in order to avoid deadlock).

>   -write
this last thing is absolutely painless... :-)

> With the othere design you have only:
>   -move the data to the processing unit's registers
>   -read the registers
>   -process
>   -write the registers
> In both descrition I have omitted the interference of the micro code > execution scheduler, but I think it's influence is linear as it touchs=
> every stage.
microcode ? everything is hardwired ...

> advantages:
>   -shorter the instruction pipe decoder
>   -shorter operation latency
>   -simplify the micro code execution unit
>   -remove unnecessary silicon.
i'm not really sure about these...

> The disavantages:
>   -less registers where you can put data data you will need = very soon
> (in some cycles).
>      Can be solved by adding more registers (= by wiring some more
> register adress bus), this has made the compliers more performant on r= isc
> architectures because they have a lot of directacces memory,and the > compiler has not to make a very fine analysis about how to distribute = the
> data between the registers...
the less registers, the harder to eficiently code. that's sure.
but the register allocation algorithms for compilers are known for maybe 20= years now.
that is : with a uniform register bank. Here, i believe that you refer
to a split register bank, where each bank is dedicated to a certain kind of=
instruction : this is not flexible at all and will suffer from the
problems that we had with TTA...

>   -more moves but you can do them in paralle with the other = instructions
> or doing them a half cycle later because a move (reg to reg) is not a<= BR> > processing function.
or at least that's what we're expecting. But the Xbar is here (in FC0) beca= use
moving is an operation in itself, even though it doesn't modify the data. the wires in the integrated circuits are taking over the overall latency and your half cycle will soon take a full cycle, then two...

> So moves would take less time. And I think if the
> compiler would do a good analysis of the code there would be no more > moves.
>   -make the compilers smarter. ;) my job...
you're such an optimistic guy :-) i like this anyway ;-)

>   -a step further from the 86 architecture. :-)
well, who will have the heart to contradict you here ? nobody i presume :-)=

> Okay this is just my idea....
...still worth discussing.

the FC0 executes 1 instruction per cycle, and it's rather smooth.
the next cores will have to decode and execute much more instructions
and the organisation will have to be much more radical : a lot of renamed registers, of shadow registers, of redundant units, etc... the fc0 is here<= BR> only to start the project, it will not stand a straightforward
scaleup to 8 instructions. OTOH FC0 suits low-power or embedded application= s.

> one other question... the cache memory. I have seen you have included = a
> prefetch memory to cache instruction so that a program can indicated e=
> better caching management for it's data. Do you want the cache managem= ent
> to be integrated in the assembly code (great, but should see the influ= ence
> on the code length),done byt the cpu, or done by the chip set?

look at the manual v0.2, there are caching hints in the load/store instruct= ions.
there are a few bits that indicate whether the data should be flushed to ce= ntral
memory or kept a while in internal cache. these "hints" influence= the cache mechanism
and allow to reduce cache spilling. imagine that you're doing some "lo= ng vector codes"
like addding 2 vectors of 100KB : 200KB doesn't fit in the cache, so you hi= nt
the memory accesses as "flush" and the data (300KB overall) won't= pollute the cache.

there are also "stream hints" that would be associated to SDRAM b= anks
for example. this way, you can boost the previously described accessses
because you won't have to send each address anew on the bus.

> And some time ago I spoke also about the memory  being accessed a= t once
> (no segmenents).
> With a compiler generated caching management it could be greate, becau= se
> you could do some semantic analysis wich could have much better
> performance thant the tactics as "the last loaded is the most imp= ortant"
> or " and cache the memory along the data and not the segements.
i'm not sure to remember exactly the idea behind segment (sorry)

> But this would change the memory architecture... yes if you want the b= urst
> mode (align the memory pointer to a segment, and all the segement
> bytes come one after the other with no other memory query).
>
> Does somebody know the rambus philosophy?

i never thought there would be a philosophy... :-)
SDRAM is already complex enough for me ;-)

> We have also a

a what ?

is there censorship here or what ?

> --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 3 11:57:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00506 for ; Sun, 3 Sep 2000 18:22:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 03 Sep 2000 18:22:36 +0200 (MEST) Received: (qmail 18568 invoked by uid 0); 3 Sep 2000 09:58:22 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 3 Sep 2000 09:58:22 -0000 X-eGroups-Return: sentto-1101623-682-967975099-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 03 Sep 2000 09:58:20 -0000 Received: (qmail 5788 invoked from network); 3 Sep 2000 09:58:18 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 3 Sep 2000 09:58:18 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 3 Sep 2000 09:58:06 -0000 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA07196 for ; Sun, 3 Sep 2000 11:57:46 +0200 (MET DST) Message-ID: <39B22091.8800E600@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000903085917.16127.qmail@web1102.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 03 Sep 2000 11:57:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] OpenHW Article Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2b7315e95806f5ff6389ebddcfd7a732 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi,

Jamil Khatib wrote:
> Check the feature article at IBM's developers work site
> htt= p://oss.software.ibm.com/developerworks/opensource/
> Article link
> http://www-4.ibm.com/software/developer/library/openh= w.html?dwzone=3Dopensource
> And please let me know your comments

not bad, not bad, i rated it 4 :-)

i mean, it's not a "killer" but it sums up almost everything.
and it's written in a way that IBM guyq can understand.
heck, if i made an article there, everybody would be afraid ;-)

> Regards
> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Jamil Khatib Sun Sep 3 12:28:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00509 for ; Sun, 3 Sep 2000 18:22:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 03 Sep 2000 18:22:37 +0200 (MEST) Received: (qmail 4631 invoked by uid 0); 3 Sep 2000 10:13:05 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 3 Sep 2000 10:13:05 -0000 X-eGroups-Return: sentto-1101623-683-967975983-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 03 Sep 2000 10:13:04 -0000 Received: (qmail 25102 invoked from network); 3 Sep 2000 10:13:03 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Sep 2000 10:13:03 -0000 Received: from unknown (HELO web1105.mail.yahoo.com) (128.11.23.125) by mta2 with SMTP; 3 Sep 2000 10:13:03 -0000 Message-ID: <20000903102805.3689.qmail@web1105.mail.yahoo.com> Received: from [199.203.98.250] by web1105.mail.yahoo.com; Sun, 03 Sep 2000 03:28:05 PDT To: cdrom@opencores.org, cores@opencores.org Cc: openip@opencores.org, f-cpu@egroups.com From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 3 Sep 2000 03:28:05 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] OpenTech cdrom prizes Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9a1e520b7fb9ab637a75b4e754dc5160 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Hi all,
3 Free OpenTech cdroms will be sent to the winners of
the OpenTech contests.
there are 3 contests
1. Logo.
2. CDROM covers
3. OpenHW design

For more information visit
http://www.opencores.org/OIPC/projects/OpenTech/prizes.shtml

Regards
Jamil Khatib

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
 From JEAN Olivier Mon Sep 4 09:47:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00428 for ; Mon, 4 Sep 2000 19:07:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 04 Sep 2000 19:07:00 +0200 (MEST) Received: (qmail 14476 invoked by uid 0); 4 Sep 2000 14:04:16 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 4 Sep 2000 14:04:16 -0000 X-eGroups-Return: sentto-1101623-684-968076144-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ml.egroups.com with NNFMP; 04 Sep 2000 14:02:31 -0000 Received: (qmail 26657 invoked from network); 4 Sep 2000 14:02:23 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 4 Sep 2000 14:02:23 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta2 with SMTP; 4 Sep 2000 14:02:23 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R8MW926P; Mon, 4 Sep 2000 09:47:14 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Mon, 4 Sep 2000 09:49:14 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE3F9@nts40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 4 Sep 2000 09:47:45 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] LATEX FILES Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: bbc675523b6d28d797b0c00d79477d62 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!


Hi Everybody !

  I have translated the html manual in Latex manual.

Now, the message is in french. I'm sorry for no frenchmen !

              =     Good bye.

Message for Yann:

J'ai d'=E9norme pb avec la mail list. Je ne re=E7ois plus de messages. J'a= i
envoy=E9 plein de messages sur la mail list fran=E7aise mais je n'ai aucune=
r=E9ponse.
A tout hasard, j'envoie ce pr=E9sent message sur la mail list principale. J'ai les fichiers traduits en Latex. O=F9 dois-je les envoyer ?

      A +.

            Olivier.
 From Yann Guidon Mon Sep 4 17:11:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00446 for ; Mon, 4 Sep 2000 19:07:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 04 Sep 2000 19:07:04 +0200 (MEST) Received: (qmail 13998 invoked by uid 0); 4 Sep 2000 15:11:23 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 4 Sep 2000 15:11:23 -0000 X-eGroups-Return: sentto-1101623-685-968080266-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 04 Sep 2000 15:11:18 -0000 Received: (qmail 14438 invoked from network); 4 Sep 2000 15:11:04 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 4 Sep 2000 15:11:04 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 4 Sep 2000 15:11:04 -0000 Received: from f-cpu.org (nas1-238.aub.club-internet.fr [195.36.150.238]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA01793; Mon, 4 Sep 2000 17:11:01 +0200 (MET DST) Message-ID: <39B3BB89.2AFCBF86@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com, JEAN Olivier References: <098A4E5B420CD3118F690008C75DD5DD029AE3F9@nts40.sbf.bourseparis.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 04 Sep 2000 17:11:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LATEX FILES Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ea8ff2fc2c0c60d26c86095442877799 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

yeah !!!!!!!!!

JEAN Olivier wrote:
>  Hi Everybody !
>
>   I have translated the html manual in Latex manual.
>
> Now, the message is in french. I'm sorry for no frenchmen !

no worries...

>            = ;             G= ood bye.
>
>  Message for Yann:
>
>  J'ai d'=E9norme pb avec la mail list. Je ne re=E7ois plus de mes= sages. J'ai
> envoy=E9 plein de messages sur la mail list fran=E7aise mais je n'ai a= ucune
> r=E9ponse.

je vais v=E9rifier ton adresse sur le site egroups.

> A tout hasard, j'envoie ce pr=E9sent message sur la mail list principa= le.
> J'ai les fichiers traduits en Latex. O=F9 dois-je les envoyer ?

mets-le en ftp ou http quelque part et envoie-nous l'url.
on recopiera .

>         A +.
>
>            = ;     Olivier.

welcome back :-)

things are going to heat up !!!!

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From jolpp@id.ru Wed Sep 6 00:21:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02670 for ; Wed, 6 Sep 2000 03:38:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 06 Sep 2000 03:38:52 +0200 (MEST) Received: (qmail 2959 invoked by uid 0); 5 Sep 2000 22:23:13 -0000 Received: from c3.egroups.com (208.50.99.225) by mx11.rz2.gmx.net with SMTP; 5 Sep 2000 22:23:13 -0000 X-eGroups-Return: sentto-1101623-686-968192587-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 05 Sep 2000 22:23:08 -0000 Received: (qmail 7085 invoked from network); 5 Sep 2000 22:23:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Sep 2000 22:23:07 -0000 Received: from unknown (HELO 51friend.net) (202.109.72.50) by mta1 with SMTP; 5 Sep 2000 22:23:06 -0000 Received: from 21cn.com [168.191.92.26] by 51friend.net (SMTPD32-4.06) id A5866E017A; Wed, 06 Sep 2000 06:24:22 PDT Message-ID: <00005f9f2bdf$00007a32$00005afc@orgio.net> To: X-Priority: 3 X-MSMail-Priority: Normal Errors-To: Worthnot_01@yahoo.com X-Mailer: Microsoft Outlook Express 5.00.2919.6600 From: jolpp@id.ru MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 05 Sep 2000 18:21:38 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Work at Home and Make Great Money! 23292 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-UIDL: 89baf255802d753adfe21134f7273b01 Status: R X-Status: N -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! Apply NOW! http://click.egroups.com/1/7872/15/_/3462/_/968192588/ ---------------------------------------------------------------------_-> Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! Is working for a "boss" too demeaning and unrewarding? Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future? If you're determined to retire in the next 2 - 5 years with enough income to have REAL Financial Independence and Freedom, and are not afraid to work for it, I can help you. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! 1-800-533-9350 (Free, 24 hour, 2 minute recorded message) DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" - Walt Disney To be removed from future mailings, send an email to: A_Nope1@yahoo.com and type "Remove" in the subject line. Tired of the 40 X 40 X 40 Plan? You know: From Peter Allen Thu Sep 7 00:19:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA04200 for ; Thu, 7 Sep 2000 09:01:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Sep 2000 09:01:32 +0200 (MEST) Received: (qmail 812 invoked by uid 0); 6 Sep 2000 22:19:57 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 6 Sep 2000 22:19:57 -0000 X-eGroups-Return: sentto-1101623-687-968278786-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 06 Sep 2000 22:19:54 -0000 Received: (qmail 10013 invoked from network); 6 Sep 2000 22:19:45 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 6 Sep 2000 22:19:45 -0000 Received: from unknown (HELO www.uklinux.net) (212.1.130.10) by mta2 with SMTP; 6 Sep 2000 22:19:44 -0000 Received: from pallen.uklinux.net (ppp-1-126.cvx6.telinco.net [212.1.156.126]) by www.uklinux.net (8.9.3/8.8.7) with ESMTP id XAA27756 for ; Wed, 6 Sep 2000 23:19:42 +0100 Message-ID: <39B6C2F0.D0E0676A@pallen.uklinux.net> X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200008280556.WAA19399@cmpweb-prod9.web.cerf.net> X-eGroups-From: Peter Allen From: Peter Allen MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 06 Sep 2000 23:19:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Fast processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 133753c300f9e417e80538957bdbd72e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

EE Times wrote:
>
> This article from http://www.eet.com was sent to you by khatib@ieee.org
>
> khatib@ieee.org says:
>
> Intel showcases Pentium 4
> http://www.eet.com/story/OEG20000825S0030
>
> SAN JOSE, Calif. &#151; Intel Corp. took the wraps off its upcoming
> Pentium 4 microprocessor at the Intel Developer Forum this week. In a
> "gas pedal" demonstration, senior vice president Albert Yu showcased
> a Pentium 4 running at just over 2 GHz, though the speed at
> introduction this fall will be 1.4 GHz. But analysts said the chip
> could face a slow ramp, because it is initially tied to still-pricey
> Rambus memories.
>
> With a pipeline twice as long as its predecessor's and a 400-MHz

Sorry about the delay in posting this.  I collect mail on two
different machines, and only read it on one :-)

Why are intel advertising huge piplines as a good thing.  I thought
the only thing they did was make cache misses more expensive.
Is there anything better about similarly clocked processors,
the first with a huge pipeline, and the second with a short one?
(Presuming everything else is the same ish)
Thanks....

                  Peter Allen
 From "Albert Abramson" Thu Sep 7 03:46:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA04221 for ; Thu, 7 Sep 2000 09:01:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Sep 2000 09:01:38 +0200 (MEST) Received: (qmail 10959 invoked by uid 0); 7 Sep 2000 01:48:10 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 7 Sep 2000 01:48:10 -0000 X-eGroups-Return: sentto-1101623-688-968291281-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ho.egroups.com with NNFMP; 07 Sep 2000 01:48:08 -0000 Received: (qmail 1054 invoked from network); 7 Sep 2000 01:48:01 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 7 Sep 2000 01:48:01 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta2 with SMTP; 7 Sep 2000 01:48:01 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000907014754.XEHA7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Wed, 6 Sep 2000 18:47:54 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000907014754.XEHA7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 06 Sep 2000 18:46:05 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Fast processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 42502474b80e9e284ad4e0610cc0a66f Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Granted, no one wants a 20 stage integer pipeline, and yes, it does lead to
long data dependencies and even longer control dependencies.  Worst is when
you have many of them together, as is common with most code.  The
correlating-noncorrelating branch prediction usually clues the processor in
more accurately about branch direction just one or two cycles ahead of time.

A cache miss time is just going to be whatever it's going to be.  The
question is whether or not your processor can do any cycle saving work
during that time frame.

The nice thing about VLIW is that you can get extraordinarily high clock
rates without extreme pipelining.  You also come in with much smaller
transistor budget, allowing the integration of much more cache and processor
cores on one die.  Statically scheduling work allows for much greater
simplicity in the overall design, and MT allows you to handle work from
alternate paths in the program during a miss, rather than having enormous
look-ahead hardware to find something to do in the existing stream.

--Maxx

----------
>From: Peter Allen <p.allen@bigfoot.com>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] Fast processor
>Date: Wed, 6 Sep, 2000, 3:19 PM
>

>
> EE Times wrote:
>>
>> This article from http://www.eet.com was sent to you by khatib@ieee.org
>>
>> khatib@ieee.org says:
>>
>> Intel showcases Pentium 4
>> http://www.eet.com/story/OEG20000825S0030
>>
>> SAN JOSE, Calif. &#151; Intel Corp. took the wraps off its upcoming
>> Pentium 4 microprocessor at the Intel Developer Forum this week. In a
>> "gas pedal" demonstration, senior vice president Albert Yu showcased
>> a Pentium 4 running at just over 2 GHz, though the speed at
>> introduction this fall will be 1.4 GHz. But analysts said the chip
>> could face a slow ramp, because it is initially tied to still-pricey
>> Rambus memories.
>>
>> With a pipeline twice as long as its predecessor's and a 400-MHz
>
> Sorry about the delay in posting this.  I collect mail on two
> different machines, and only read it on one :-)
>
> Why are intel advertising huge piplines as a good thing.  I thought
> the only thing they did was make cache misses more expensive.
> Is there anything better about similarly clocked processors,
> the first with a huge pipeline, and the second with a short one?
> (Presuming everything else is the same ish)
> Thanks....
>
>    Peter Allen
>
>
>
From Jeff Davies/CDPTEST Thu Sep 7 18:26:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01165 for ; Thu, 7 Sep 2000 23:52:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Sep 2000 23:52:23 +0200 (MEST) Received: (qmail 22834 invoked by uid 0); 7 Sep 2000 16:29:14 -0000 Received: from ej.egroups.com (208.50.144.75) by mx19.rz2.gmx.net with SMTP; 7 Sep 2000 16:29:14 -0000 X-eGroups-Return: sentto-1101623-689-968344146-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 07 Sep 2000 16:29:17 -0000 Received: (qmail 28000 invoked from network); 7 Sep 2000 16:29:06 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 7 Sep 2000 16:29:06 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta2 with SMTP; 7 Sep 2000 16:29:05 -0000 Received: from modem-132.indium.dialup.pol.co.uk ([62.136.40.132] helo=sargon.chrystal.gbr.xerox.com) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13X4X4-0002D5-00 for f-cpu@egroups.com; Thu, 07 Sep 2000 17:28:10 +0100 To: f-cpu@egroups.com Message-ID: <2CD62CBBE007FB1F80256953005A405B.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 7 Sep 2000 17:26:52 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] herein a jolly, nothing to do with fcpu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6551bb2130c64ba562cd1162a7cbcfa7 Status: R X-Status: N
where you set the price
eGroups My Groups | f-cpu Main Page | Start a new group!

(to be sung to tune of "oh lord won't you buy me a mercedes benz").

Oh lord won't you buy me a Linux PC,
My friends all use Windows,
it's screwed up their heads,
I'm tired of the paperclip,
and blue screen of death
So lord won't you buy me a Linux PC.

    //short transmission delay

<GOD + echo>
Thee should know this child:
Thou can downloadest Linux for free from the Internet.
Tell thine friends they shall perish (from stress) unless they flee the
Desktop of Doom
Look thee not back or I shall turn you into a pillar of salt (and thou
shalt be
ground up, put in a salt sellar, and placed on Michael Winner's dinner
table).

jeff@llandre.freeserve.co.uk
Jeff Davies
 From Yann Guidon Fri Sep 8 01:56:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01946 for ; Fri, 8 Sep 2000 02:07:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 08 Sep 2000 02:07:45 +0200 (MEST) Received: (qmail 9820 invoked by uid 0); 7 Sep 2000 23:56:32 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 7 Sep 2000 23:56:32 -0000 X-eGroups-Return: sentto-1101623-690-968370989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 07 Sep 2000 23:56:32 -0000 Received: (qmail 15335 invoked from network); 7 Sep 2000 23:56:27 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 7 Sep 2000 23:56:27 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 7 Sep 2000 23:56:27 -0000 Received: from april.org (nas2-199.ras.club-internet.fr [195.36.192.199]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA03766 for ; Fri, 8 Sep 2000 01:56:25 +0200 (MET DST) Message-ID: <39B82B20.B43147C@april.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <2CD62CBBE007FB1F80256953005A405B.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 08 Sep 2000 01:56:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] herein a jolly, nothing to do with fcpu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fc00921d4221c70da5b8103112487635 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jeff Davies/CDPTEST wrote:
> (to be sung to tune of "oh lord won't you buy me a mercedes benz&= quot;).
<snip>
scary ;-)

in the same kind : tune of "Spark" form Tori Amos :

"He's addicted to Linux patches"...

damn, i guess i made enough of F-CPhumor for tonight ;-)

> jeff@llandre.freeserve.co.uk
> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Nicolas Boulay Mon Sep 11 13:02:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00306 for ; Tue, 12 Sep 2000 01:19:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 12 Sep 2000 01:19:41 +0200 (MEST) Received: (qmail 9858 invoked by uid 0); 11 Sep 2000 10:06:02 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 11 Sep 2000 10:06:02 -0000 X-eGroups-Return: sentto-1101623-691-968666729-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 11 Sep 2000 10:05:47 -0000 Received: (qmail 31011 invoked from network); 11 Sep 2000 10:05:28 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 11 Sep 2000 10:05:28 -0000 Received: from unknown (HELO herabis.isep.fr) (194.2.232.252) by mta2 with SMTP; 11 Sep 2000 10:05:28 -0000 Received: from lune.isep.fr ([194.3.122.148]) by herabis.isep.fr (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0G0P00927YRM1U@herabis.isep.fr> for f-cpu@egroups.com; Mon, 11 Sep 2000 12:04:35 +0100 (WET DST) Received: from isep.fr (localhost [127.0.0.1]) by lune.isep.fr (8.9.1b+Sun/8.9.1) with ESMTP id MAA06828 for ; Mon, 11 Sep 2000 12:02:05 +0100 (WET DST) Sender: nboulay@lune.isep.fr To: f-cpu@egroups.com Message-id: <39BCBBAD.AE27DE33@isep.fr> Organization: ISEP X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4u) From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Sep 2000 12:02:05 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] about leon Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9e04863c3067abc20d447c641a349d39 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Just a link about a complete GPL and LGPL sparc like processor, the leon
>from the european space agency.
http://www.estec.esa.nl/wsmwww/leon/

nicO
 From "Albert Abramson" Mon Sep 11 21:31:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00359 for ; Tue, 12 Sep 2000 01:19:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 12 Sep 2000 01:19:54 +0200 (MEST) Received: (qmail 31694 invoked by uid 0); 11 Sep 2000 19:36:18 -0000 Received: from jj.egroups.com (208.50.144.82) by mx06.rz2.gmx.net with SMTP; 11 Sep 2000 19:36:18 -0000 X-eGroups-Return: sentto-1101623-692-968700943-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 11 Sep 2000 19:36:12 -0000 Received: (qmail 1800 invoked from network); 11 Sep 2000 19:35:42 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Sep 2000 19:35:42 -0000 Received: from unknown (HELO femail4.sdc1.sfba.home.com) (24.0.95.84) by mta2 with SMTP; 11 Sep 2000 19:35:42 -0000 Received: from [24.10.43.202] by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000911193452.DIZK8573.femail4.sdc1.sfba.home.com@[24.10.43.202]> for ; Mon, 11 Sep 2000 12:34:52 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000911193452.DIZK8573.femail4.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Sep 2000 12:31:59 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90ebb64a6db19d94fe5e074a747e741b Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

In the amount of time being taken for all of this, this group could have
produced a wire layout of every functional unit and be on its way to
generating a mask for fabrication.

I think that this whole discussion has gone off the deep end.  There's no
reason we can't wire this thing up by hand, just like the good ol' days.
Maybe none of you punk kids are old enough to remember, but years ago, all
uP's were designed by engineers, not computers.

If you're on the topic of SPARC, the MT VLIW design I was talking about
takes advantage of its register layout to allow register windowing if a
thread wants to pass messages that way.  Banks can be reserved for use by
alternate threads without having to know which bank they're in.  Nifty, eh?

--Maxx

I hope there's beer in heaven.

----------
>From: Nicolas Boulay <nicolas.boulay@isep.fr>
>To: f-cpu@egroups.com
>Subject: [f-cpu] about leon
>Date: Mon, 11 Sep, 2000, 4:02 AM
>

>
> Just a link about a complete GPL and LGPL sparc like processor, the leon
> from the european space agency.
> http://www.estec.esa.nl/wsmwww/leon/
>
> nicO
>
>
>
From Yann Guidon Tue Sep 12 00:42:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00368 for ; Tue, 12 Sep 2000 01:19:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 12 Sep 2000 01:19:57 +0200 (MEST) Received: (qmail 2790 invoked by uid 0); 11 Sep 2000 22:42:48 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 11 Sep 2000 22:42:48 -0000 X-eGroups-Return: sentto-1101623-693-968712144-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 11 Sep 2000 22:42:46 -0000 Received: (qmail 27527 invoked from network); 11 Sep 2000 22:42:23 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 11 Sep 2000 22:42:23 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 11 Sep 2000 22:42:22 -0000 Received: from f-cpu.org (nas3-28.ras.club-internet.fr [195.36.203.28]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA24577 for ; Tue, 12 Sep 2000 00:42:19 +0200 (MET DST) Message-ID: <39BD5FD1.112181B1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000911193452.DIZK8573.femail4.sdc1.sfba.home.com@[24.10.43.202]> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Sep 2000 00:42:25 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] fight against entropy (and time, too) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: dff142ae7e1426413a3b2a6253e129e6 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello, MAxx and Nico, welcome back from vacations,

just FYI, my personal status is : printing/editing of
master thesis. 900 pages printed already, the rest will follow soon.
if you don't believe me, go look the work at
http://www.m= ime.up8.edu/~whygee/memoire/corps.html
(beware : 350Ko of HTML and 2MB of pictures/illustrations.

one week or two and i'm all your's (and f-cpu's like always).

but maybe it'll then be time to rest some days and
go to the Oktoberfest ? :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Rares Marian Tue Sep 12 23:05:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA03282 for ; Wed, 13 Sep 2000 05:40:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Sep 2000 05:40:57 +0200 (MEST) Received: (qmail 13066 invoked by uid 0); 12 Sep 2000 21:05:45 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 12 Sep 2000 21:05:45 -0000 X-eGroups-Return: sentto-1101623-694-968792666-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 12 Sep 2000 21:04:46 -0000 Received: (qmail 29842 invoked from network); 12 Sep 2000 21:03:28 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Sep 2000 21:03:28 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta1 with SMTP; 12 Sep 2000 21:03:27 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e8CL5v602131; Tue, 12 Sep 2000 17:05:57 -0400 Message-Id: <200009122105.e8CL5v602131@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu@egroups.com From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Sep 2000 17:05:57 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's come back to an old sugestion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 082c05f0b0a90403f00862a7a4666f7a Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

>hi !
>
>Rares Marian wrote:
>>
>> Yann Guidon <whygee@f-cpu.org> wrote:
>> hi.
>>
>> (my net card is hosed yet I paid for 100Mbit access so I'm using my roommate's comp)
>>
>> >hello !
>> >that is : with a uniform register bank. Here, i believe that you refer
>> >to a split register bank, where each bank is dedicated to a certain kind of
>> >instruction : this is not flexible at all and will suffer from the
>> >problems that we had with TTA...
>>
>> What about the {in/con/re/per}verse?
>>
>> Can't we have several EU's per register group?
>>
>> I'll draw something up this weekend. (then I'll save it to floppy and send it through my roomate's box :/)
>
>as you wish, aslong as yyou don't reinvent the wheel ;-)

Heh.  Well here's the argument:

As chips go up in register size the EUs must all increase in size.
If we're to use multiple EUs sometime soon things could get ugly.
There's less room on the chips.

My current idea is a 3 bit adder (src1, src2, carry=initially zero)

If I can get this to a small managable size it could be easy to have many of these without utter madness ruling the architecture.

The logic is a bit(pun not intended) crazy and makes the unit run slower.
However, you can have many of them on chip running simultaneously.  Essentially the problem of hazards and stalls has been taken from the time dimension and put into the space dimension.  The way I organize registers holes appear in the register set not in the pipeline.

If you actually have a problem that requires all 63 regs at the same time then you are insane or an Amiga developer.

I think I can get a mult/div solution too.  A Logic unit solution is even easier.

You'll see :)

Rares



Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
 From "yulonda95353@nexus.hu" Wed Sep 13 02:45:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA03294 for ; Wed, 13 Sep 2000 05:41:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Sep 2000 05:41:00 +0200 (MEST) Received: (qmail 22758 invoked by uid 0); 13 Sep 2000 01:03:05 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 13 Sep 2000 01:03:05 -0000 X-eGroups-Return: sentto-1101623-695-968806978-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 13 Sep 2000 01:03:04 -0000 Received: (qmail 3947 invoked from network); 13 Sep 2000 01:02:13 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 13 Sep 2000 01:02:13 -0000 Received: from unknown (HELO booster.telnet.hu) (63.25.244.46) by mta2 with SMTP; 13 Sep 2000 01:02:12 -0000 Message-ID: <58837.30010@booster.telnet.hu> From: "yulonda95353@nexus.hu" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Sep 2000 20:45:36 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Info you requested. (3531) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: fa6d01254c7ba59db9a9f07ec4d288f8 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

We took a 100 year old product, added electronics and sound.
The result? We revolutionized an industry!!!
People like you are making $3,000-$5000 per week or more!
Not MLM!   No Selling!    Easy!  All Cash!!!

Call now for FREE INFO 1800-277-5212 24 Hours!

Only a limited number of people will be selected for each area!
Don't let this one pass you by! Call now to find out more!


If you would like your goods or services marketed via email, contact 
us at 954-567-8455.


remove at hida3956@mail.gr

********************************************************************************
66758
 From "Marco Al" Wed Sep 13 15:55:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00320 for ; Thu, 14 Sep 2000 07:28:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Sep 2000 07:28:16 +0200 (MEST) Received: (qmail 23227 invoked by uid 0); 13 Sep 2000 22:00:39 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 13 Sep 2000 22:00:39 -0000 X-eGroups-Return: sentto-1101623-696-968876351-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.143] by ci.egroups.com with NNFMP; 13 Sep 2000 20:19:58 -0000 Received: (qmail 4504 invoked from network); 13 Sep 2000 20:10:12 -0000 Received: from unknown (10.1.10.27) by m7.onelist.org with QMQP; 13 Sep 2000 20:10:12 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 13 Sep 2000 20:10:11 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id WAA14134 for ; Wed, 13 Sep 2000 22:10:10 +0200 (METDST) Message-ID: <000101c01dbf$ca270dd0$29e65982@student.utwente.nl> To: References: <200009122105.e8CL5v602131@tbird.iworld.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Sep 2000 15:55:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's come back to an old sugestion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4112c61f97e236763240e2a83d1a533 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Hello, did part of this discussion occur over email or something? Or did the
archive miss a beat? Im new to the list...

Im not quite sure who I am quoting here... I think its Rares Marian.

> >> Can't we have several EU's per register group?
<snip>
Rares Marian wrote:
> As chips go up in register size the EUs must all increase in size.
> If we're to use multiple EUs sometime soon things could get ugly.
> There's less room on the chips.

And the wires get longer limiting clock speed....

Isnt this the argument for why the Alpha 21264 uses two seperate integer
clusters with duplicate register files?

They said that with that design they were only getting a couple of % of per
clock performance degredation compared to a single register file for all 4.
But their unit's are pretty generic so instructions dependent on one in a
previous cycle can be scheduled to be issued to the same cluster.

> My current idea is a 3 bit adder (src1, src2, carry=initially zero)

Do you mean it add's those 3 together with 1 bit each, or it add's 2 3-bit
words with carry? (or in other words, do you mean a 1-bit full adder or a
3-bit full adder?)

> If I can get this to a small managable size it could be easy to have many
of these without utter madness ruling the architecture.
>
> The logic is a bit(pun not intended) crazy and makes the unit run slower.
> However, you can have many of them on chip running simultaneously.
Essentially the problem of hazards and stalls has been taken from the time
dimension and put into the space dimension.  The way I organize registers
holes appear in the register set not in the pipeline.
>
> If you actually have a problem that requires all 63 regs at the same time
then you are insane or an Amiga developer.
>
> I think I can get a mult/div solution too.  A Logic unit solution is even
easier.
>
> You'll see :)
>
> Rares

Im sorry I dont quite see the relation to the register-file/EU size
problem... are you trying to (re-)invent some form of FPGA? (with adders
instead of LUT's)

Marco

 From Yann Guidon Thu Sep 14 19:46:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00317 for ; Fri, 15 Sep 2000 07:53:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:20 +0200 (MEST) Received: (qmail 700 invoked by uid 0); 14 Sep 2000 17:42:37 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 14 Sep 2000 17:42:37 -0000 X-eGroups-Return: sentto-1101623-697-968953328-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 14 Sep 2000 17:42:33 -0000 Received: (qmail 9252 invoked from network); 14 Sep 2000 17:42:08 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 14 Sep 2000 17:42:08 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 14 Sep 2000 17:42:07 -0000 Received: from f-cpu.org (nas1-237.aub.club-internet.fr [195.36.150.237]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA15251 for ; Thu, 14 Sep 2000 19:42:04 +0200 (MET DST) Message-ID: <39C10EEE.6F98FF14@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000911193452.DIZK8573.femail4.sdc1.sfba.home.com@[24.10.43.202]> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Sep 2000 19:46:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8e191633204a08c13c2c1e8b241ce05b Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Albert Abramson wrote:
> If you're on the topic of SPARC, the MT VLIW design I was talking abou= t
> takes advantage of its register layout to allow register windowing if = a
> thread wants to pass messages that way.  Banks can be reserved fo= r use by
> alternate threads without having to know which bank they're in.  = Nifty, eh?

if you want to have fun, maybe you can try to make a SMT version of Bernd P= aysan's
4Stack CPU ? it's a 8-issue VLIW CPU with 4 stack instructions and 2 load/s= tores.
Bernd's site is linked on the Utopia Computing Webring (http://opencollector.org/cgi-bin/ut= opia/index)

> --Maxx
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From "Albert Abramson" Thu Sep 14 21:31:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00326 for ; Fri, 15 Sep 2000 07:53:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:22 +0200 (MEST) Received: (qmail 16309 invoked by uid 0); 14 Sep 2000 19:36:55 -0000 Received: from fj.egroups.com (208.50.99.207) by mx11.rz2.gmx.net with SMTP; 14 Sep 2000 19:36:55 -0000 X-eGroups-Return: sentto-1101623-698-968960155-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.39] by fj.egroups.com with NNFMP; 14 Sep 2000 19:36:21 -0000 Received: (qmail 13529 invoked from network); 14 Sep 2000 19:35:46 -0000 Received: from unknown (10.1.10.27) by m5.onelist.org with QMQP; 14 Sep 2000 19:35:46 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta2 with SMTP; 14 Sep 2000 19:35:46 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Thu, 14 Sep 2000 12:35:37 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Sep 2000 12:31:50 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e1a00a820eebbe971f954eb41c5d9f2e Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page

How bout we stick to V/LIW RISC.  There's nothing complicated or inter= esting
about it.  Multi-threading it and making those extra register banks available seems challenge enough for me.

--Maxx

----------
>From: Yann Guidon <whygee@f-cpu.org>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] GPL, VHDL, et al
>Date: Thu, Sep 14, 2000, 10:46 AM
>

>
> Albert Abramson wrote:
>> If you're on the topic of SPARC, the MT VLIW design I was talking = about
>> takes advantage of its register layout to allow register windowing= if a
>> thread wants to pass messages that way.  Banks can be reserve= d for use by
>> alternate threads without having to know which bank they're in.&nb= sp; Nifty, eh?
>
> if you want to have fun, maybe you can try to make a SMT version of Be= rnd
Paysan's
> 4Stack CPU ? it's a 8-issue VLIW CPU with 4 stack instructions and 2 load/stores.
> Bernd's site is linked on the Utopia Computing Webring
> (http://ope= ncollector.org/cgi-bin/utopia/index)
>
>> --Maxx
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Moi qui pensait que dans le libre y avait pas trop de cyber-neun= eus."
>  F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con= )
>
>
>
From Jeff Davies Fri Sep 15 01:36:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00353 for ; Fri, 15 Sep 2000 07:53:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:30 +0200 (MEST) Received: (qmail 23499 invoked by uid 0); 14 Sep 2000 23:21:42 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 14 Sep 2000 23:21:42 -0000 X-eGroups-Return: sentto-1101623-699-968973679-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 14 Sep 2000 23:21:38 -0000 Received: (qmail 23088 invoked from network); 14 Sep 2000 23:21:18 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 14 Sep 2000 23:21:18 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta1 with SMTP; 14 Sep 2000 23:21:17 -0000 Received: from modem-115.dexfenfluramine.dialup.pol.co.uk ([62.136.89.243] helo=llandre.freeserve.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13ZiJc-0004N3-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 00:21:13 +0100 Sender: root@pop.gmx.net Message-ID: <39C160E3.F4F5CB73@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) To: f-cpu@egroups.com References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 00:36:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: de0fa5b1b3f52c2e9b2dbb56885c1a8c Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Albert Abramson wrote:

>
> How bout we stick to V/LIW RISC.  There's nothing complicated or interesting
> about it.  Multi-threading it and making those extra register banks
> available seems challenge enough for me.
>
> --Maxx
>

We have an architecture, instruction set etc. that took a long time for anumber
of people to come up with. What we could do with now is
someone to implement it, and put it on FPGAs etc. I think a good idea
is to take a basic LART circuit, and extend it a bit with a few FPGAs on it
implementing a basic FCPU in place of the StrongArm.

Perhaps an interim step of suffient FPGAs for the CPU implementation
(plus necessary interconnect), some static ram and a boot ROM
containing a very simple monitor allowing download of code from
serial port.

A simulator, gas & gcc compiler and a port of linux shortly after on the
software side would be nice.

(but I guess other folks are busy - like me)

So here is the way forward:

Hardware:-

1. CODE EXISTING DESIGN INTO VHDL
2. COMPILE INTO FPGA(S) & PROGRAM SOME
3. DESIGN MOTHERBOARD1(static ram, rom, and uart + FPGAs for CPU).
4. BUILD MOTHERBOARD1
5. Write CPU tests, run them.
6. DESIGN MOTHERBOARD2 (hacked version of LART)
7. BUILD MOTHERBOARD2

Resources (Hardware/Software) required for above:
1. & 2.  -> something like Xilinx Foundation $300 or so for version which handles
VHDL including programming cable. Also a few FPGAs perhaps
$100 total?  (which fpga?)

3. RS Components catalogue/CD (rswww.com) to find some static RAM
etc. pinouts. Cheap low end Schematic/PCB design program like
Quickroute $140 or so. Can handle about 10 layers from memory.
Autoroute is not very good, but can save some time. produces gerber files.

4. Get gerber files made into PCBs. Setup fee will be about $200 (something like
$15 per gerber layer). PCBs might cost $150 each.
[lower in volume obviously].
Components likely to be about $150 including FPGAs.
Solder yourself - difficult to get anyone else to do this low volume.
So each very basic fully populated motherboard1 (primitive) will be
$300.

5. Cost nothing.

6. Cost nothing. (except maybe a beer or two for JDB)

7. Again, PCB setup cost about $200. PCBs cost about $150 each again.
Components now cost more like $600 per board. (this is a full PC like
system, and we don't have bulk buying capability yet).
Each fully populated motherboard2 will cost around $750.
Solder yourself again. With time, subcontract this.


Software:-

1. Port GAS?
2. Port GCC
3. Compile Linux, and a bootloader, perhaps also openbios?
4. If hardware not available, write and run simulator.

None of the above cost anything other than time.


I was holding out for a way to do the FPGA programming on a free bit of software.

but this isn't exactly possible right now since the FPGA manufacturers don't have
open
programming interfaces. I tried the software that Mr Erin recommended, and it
really
isn't as good as Xilinx Foundation. The really hard part is fitting a design into
a FPGA.
(The compiler tends to run out of CLBs, buses etc).
So the easiest way to start is put very very simple Execution Units in, a small
register file
etc. Simplify. You can always build up the design.

Also a problem is, you tend to put Xilinx Library components into your design,
naturally.
How free is the overall thing then?

Jeff Davies
jeff@llandre.freeserve.co.uk

 From "Marco Al" Fri Sep 15 03:39:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00356 for ; Fri, 15 Sep 2000 07:53:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:31 +0200 (MEST) Received: (qmail 30083 invoked by uid 0); 15 Sep 2000 01:31:37 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 15 Sep 2000 01:31:37 -0000 X-eGroups-Return: sentto-1101623-700-968981486-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 15 Sep 2000 01:31:36 -0000 Received: (qmail 21609 invoked from network); 15 Sep 2000 01:31:24 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Sep 2000 01:31:24 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 15 Sep 2000 01:31:24 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id DAA10214 for ; Fri, 15 Sep 2000 03:31:22 +0200 (METDST) Message-ID: <000e01c01eb5$d541b160$29e65982@student.utwente.nl> To: References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 03:39:46 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 22e2bb876b52a2cbf05158ac43677538 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

From: "Jeff Davies" <jeff@llandre.freeserve.co.uk>
> Albert Abramson wrote:
>
> >
> > How bout we stick to V/LIW RISC.  There's nothing complicated or
interesting
> > about it.

Apart from the compiler.

> > Multi-threading it and making those extra register banks
> > available seems challenge enough for me.

F0 is not far enough but you are only willing to go so far huh :) Personally
I think the compact code size for stack machines and the small size of the
register's would complement VLIW+SMT quite nicely. It seems a natural
extension of the 4stack design, if you split up the instruction decode in
the 4stack into 4 seperate streams you are there. The SMT part is obvious,
but if you provide a way for the instructions in the different pipe's to be
locked you also have a VLIW design (the V being Variable, some extra
synchronisation instructions which would kick in during stack2stack
transfers so VLIW instruction streams could be run on less pipes than what
they were initially constructed for would be nice too).

> Perhaps an interim step of suffient FPGAs for the CPU implementation
> (plus necessary interconnect), some static ram and a boot ROM
> containing a very simple monitor allowing download of code from
> serial port.
>
> A simulator, gas & gcc compiler and a port of linux shortly after on the
> software side would be nice.

Writing a simulator after design&implementation? Somehow that feels deeply
wrong to me.

> Resources (Hardware/Software) required for above:
> 1. & 2.  -> something like Xilinx Foundation $300 or so for version which
handles
> VHDL including programming cable. Also a few FPGAs perhaps
> $100 total?  (which fpga?)

Insight-Electronics has a nice board with the Spartan-II, which probably has
the best gates/$ ratio of the SRAM types. They are described at
http://www.insight-electronics.com/xcellence/scalable/kit/ I requested a
quote via their webform but got zip, and I am not going to place an
international call for it... if anyone is sufficiently interested could you
check the prices (with varying software options) and share it with the list
and me? :)

> I was holding out for a way to do the FPGA programming on a free bit of
software.
>
> but this isn't exactly possible right now since the FPGA manufacturers
don't have
> open
> programming interfaces.

Does anyone know if Xilinx is ever going to make jbits and jroute openly
available? It wouldnt quite make their architectures open, but it would be
more than sufficient to make say an Alliance backend.

Marco

 From "Albert Abramson" Fri Sep 15 03:46:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00359 for ; Fri, 15 Sep 2000 07:53:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:32 +0200 (MEST) Received: (qmail 24219 invoked by uid 0); 15 Sep 2000 01:57:34 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 15 Sep 2000 01:57:34 -0000 X-eGroups-Return: sentto-1101623-701-968983031-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 15 Sep 2000 01:57:33 -0000 Received: (qmail 12359 invoked from network); 15 Sep 2000 01:50:01 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 15 Sep 2000 01:50:01 -0000 Received: from unknown (HELO femail2.sdc1.sfba.home.com) (24.0.95.82) by mta2 with SMTP; 15 Sep 2000 01:50:01 -0000 Received: from [24.10.43.202] by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000915014954.EWVR27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> for ; Thu, 14 Sep 2000 18:49:54 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000915014954.EWVR27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Sep 2000 18:46:05 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fdad22e691fee6f5d10ee461f1085133 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Anyone who has ever implemented a processor, even a simple one, can tell you
what's wrong with the current approach.  The real bottleneck on modern uP's
is not logic, but wire, and the current f-cpu offers just too much.  That's
what's wrong with the architecture.  That's why I haven't spent too much
time in the discussion.

A good VLIW design would allow us to break from the VHDL and just go
straight to a hand designed, hand-tweaked mask.

I do not believe in the current approach, because it creates bottlenecks
even Intel does not have to deal with.  I have no plans to be part of
something I am relatively confident will never perform.  I'm interested in
Porsche, not Caravan.  It's upsetting to see that so many skilled
individuals would be getting behind something has no chance of flying high.

--Maxx

----------
>From: Jeff Davies <jeff@llandre.freeserve.co.uk>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] GPL, VHDL, et al
>Date: Thu, Sep 14, 2000, 4:36 PM
>

>
> Albert Abramson wrote:
>
>>
>> How bout we stick to V/LIW RISC.  There's nothing complicated or interesting
>> about it.  Multi-threading it and making those extra register banks
>> available seems challenge enough for me.
>>
>> --Maxx
>>
>
> We have an architecture, instruction set etc. that took a long time for
anumber
> of people to come up with. What we could do with now is
> someone to implement it, and put it on FPGAs etc. I think a good idea
> is to take a basic LART circuit, and extend it a bit with a few FPGAs on it
> implementing a basic FCPU in place of the StrongArm.
>
> Perhaps an interim step of suffient FPGAs for the CPU implementation
> (plus necessary interconnect), some static ram and a boot ROM
> containing a very simple monitor allowing download of code from
> serial port.
>
> A simulator, gas & gcc compiler and a port of linux shortly after on the
> software side would be nice.
>
> (but I guess other folks are busy - like me)
>
From "Albert Abramson" Fri Sep 15 04:37:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00362 for ; Fri, 15 Sep 2000 07:53:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 07:53:33 +0200 (MEST) Received: (qmail 19550 invoked by uid 0); 15 Sep 2000 02:41:27 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 15 Sep 2000 02:41:27 -0000 X-eGroups-Return: sentto-1101623-702-968985672-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hk.egroups.com with NNFMP; 15 Sep 2000 02:41:16 -0000 Received: (qmail 22837 invoked from network); 15 Sep 2000 02:41:11 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 15 Sep 2000 02:41:11 -0000 Received: from unknown (HELO femail2.sdc1.sfba.home.com) (24.0.95.82) by mta3 with SMTP; 15 Sep 2000 02:41:11 -0000 Received: from [24.10.43.202] by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000915024104.HJFX27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> for ; Thu, 14 Sep 2000 19:41:04 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000915024104.HJFX27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Sep 2000 19:37:15 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f798cfe10e970ac8b45d5c65097a4d3f Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!



----------
>From: "Marco Al" <marco@simplex.nl>
>To: <f-cpu@egroups.com>
>Subject: Re: [f-cpu] GPL, VHDL, et al
>Date: Thu, Sep 14, 2000, 6:39 PM
>

>
> From: "Jeff Davies" <jeff@llandre.freeserve.co.uk>
>> Albert Abramson wrote:
>>
>> >
>> > How bout we stick to V/LIW RISC.  There's nothing complicated or
> interesting
>> > about it.
>
> Apart from the compiler.
>
>> > Multi-threading it and making those extra register banks
>> > available seems challenge enough for me.
>
> F0 is not far enough but you are only willing to go so far huh :) Personally
> I think the compact code size for stack machines and the small size of the
> register's would complement VLIW+SMT quite nicely. It seems a natural
> extension of the 4stack design, if you split up the instruction decode in
> the 4stack into 4 seperate streams you are there. The SMT part is obvious,
> but if you provide a way for the instructions in the different pipe's to be
> locked you also have a VLIW design (the V being Variable, some extra
> synchronisation instructions which would kick in during stack2stack
> transfers so VLIW instruction streams could be run on less pipes than what
> they were initially constructed for would be nice too).
>

I'm not sure what you mean by all of this.  The MT Statically Scheduled
Superscalar design I offered banks seven sets of local registers with one
set of globals.  Any given thread can allocate more registers if need be at
any time during execution.  The compiler schedules instructions for each
cycle just like VLIW, but in the event of a miss, the processor is able to
execute alternate threads.  The approach depends very heavily on its high
clock rate and MT, but is able to take advantage of both because of its
extremely short message passing overhead (passing addresses and data through
registers, rather than memory).

It sounds very complicated in comparison to a flat register file accessible
with runtime translation.  The thread never sees complexity -- the hardware
never sees any bottlenecks.  In the event of a cache miss, there is no
context switching overhead.  Even the clock penalty of a large rf can be
avoided by holding only the current and next local bank in hardware at any
given time, allowing as little as two sets of 24 registers to be
implemented.

If you mean using four simultaneous streams for MT execution, static
integration into one stream leads to contagious stalls that leave all
pipelines stalled until all can proceed.  This is one of the shortcomings of
IA-64, which statically integrates many paths into one stream.

If you mean running four independent streams executing on the same hardware,
with decode hardware drawing from all four simultaneously, you still have to
determine whether or not hardware exists to perform the desired operation.
You also have to generate your own pipeline stalls at run time, something
MIPS once did at compile time.  Moving to superscalar, MIPS designers chose
to offload this work to the hardware, despite the hit in the clock rate.

I prefer to have the compiler schedule three or four instructions per clock,
and not to depend too heavily on ILP, which is getting harder to attain with
real application software.  I am currently thinking about a computer that is
focused on raytracing, which takes hours on my iMac.  Alpha is good for
that, but COMPAQ is handling the technology stupidly.  Raytracing is
floating point intensive, depends on double precision numbers, and involves
a lot of trigonometry.

> Marco

--Maxx
 From Colin Marquardt Fri Sep 15 07:06:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02602 for ; Fri, 15 Sep 2000 21:39:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:14 +0200 (MEST) Received: (qmail 16139 invoked by uid 0); 15 Sep 2000 07:20:42 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 15 Sep 2000 07:20:42 -0000 X-eGroups-Return: sentto-1101623-703-969002439-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 15 Sep 2000 07:20:38 -0000 Received: (qmail 6482 invoked from network); 15 Sep 2000 07:20:38 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 15 Sep 2000 07:20:38 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 15 Sep 2000 07:20:38 -0000 Received: from morphin.marquardt-home.de (d232.nas21.sonic.net [209.204.136.232]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id JAA17090 for ; Fri, 15 Sep 2000 09:20:21 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13Zni4-0000bT-00 for ; Thu, 14 Sep 2000 22:06:48 -0700 To: f-cpu@egroups.com References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> X-Now-Playing: Benediction's The Grand Leveller - Vision In The Shroud In-Reply-To: Jeff Davies's message of "Fri, 15 Sep 2000 00:36:04 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 9 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 14 Sep 2000 22:06:48 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fe178ce1d226088eb6388659de69e573 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

* Jeff Davies <jeff@llandre.freeserve.co.uk> writes:

> etc. pinouts. Cheap low end Schematic/PCB design program like
> Quickroute $140 or so. Can handle about 10 layers from memory.

Maybe EAGLE from www.cadsoft.de. The free version can handle half
euro size and 2 signal layers. Available for Linux.

Colin
 From "Marco Al" Fri Sep 15 09:46:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02605 for ; Fri, 15 Sep 2000 21:39:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:14 +0200 (MEST) Received: (qmail 17676 invoked by uid 0); 15 Sep 2000 07:37:53 -0000 Received: from fh.egroups.com (208.50.144.71) by mx11.rz2.gmx.net with SMTP; 15 Sep 2000 07:37:53 -0000 X-eGroups-Return: sentto-1101623-704-969003470-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 15 Sep 2000 07:37:52 -0000 Received: (qmail 3926 invoked from network); 15 Sep 2000 07:37:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Sep 2000 07:37:50 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 15 Sep 2000 07:37:49 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id JAA04297 for ; Fri, 15 Sep 2000 09:37:48 +0200 (METDST) Message-ID: <001901c01ee9$0610a020$29e65982@student.utwente.nl> To: References: <20000915024104.HJFX27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 09:46:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9a12e5b963fb71745837b670d5015aa8 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

From: "Albert Abramson" <maxx@nventure.com>

> If you mean using four simultaneous streams for MT execution, static
> integration into one stream leads to contagious stalls that leave all
> pipelines stalled until all can proceed.  This is one of the shortcomings
of
> IA-64, which statically integrates many paths into one stream.

Well they have to be integrated when you are using the 4stack as a VLIW
machine, I just meant giving the option to decouple them so you could use it
for SMT.

> If you mean running four independent streams executing on the same
hardware,
> with decode hardware drawing from all four simultaneously, you still have
to
> determine whether or not hardware exists to perform the desired operation.

Well each thread has its own stack+ALU with cheap operations, and if the
shared function unit's are busy just stall. If you are going to have shared
resources between different threads the potential of this happening is
always present... so my instinct was just to keep the hardware needed to
execute a single thread as small as possible to maximize the use of shared
resources and minimize the amount of transistors doing nothing if their
thread is stalled for only a couple of cycles, vertical multithreading is no
help there, and stack machines for various reasons seemed to me to be the
straightforward way.

> I prefer to have the compiler schedule three or four instructions per
clock,
> and not to depend too heavily on ILP, which is getting harder to attain
with
> real application software.

So basically you are suggesting a statically scheduled superscalar machine
with vertical multithreading, with multiple cores on a chip (with no shared
execution resources?) to provide further parallelism?

> I am currently thinking about a computer that is
> focused on raytracing, which takes hours on my iMac.  Alpha is good for
> that, but COMPAQ is handling the technology stupidly.  Raytracing is
> floating point intensive, depends on double precision numbers, and
involves
> a lot of trigonometry.

Generic portable code for raytracing works like that yes, but if you are
making a special purpose machine wouldnt special purpose software with
fixed-point/block-floating-point algorithms where appropriate make sense? I
think architecture's like Pixelfusion (http://www.pixelfusion.co.uk) are
better suited, or OpenRISC 2000 for that matter.

Marco

 From Nicolas Matringe Fri Sep 15 09:52:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02611 for ; Fri, 15 Sep 2000 21:39:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:16 +0200 (MEST) Received: (qmail 2531 invoked by uid 0); 15 Sep 2000 07:52:05 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 15 Sep 2000 07:52:05 -0000 X-eGroups-Return: sentto-1101623-705-969004321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 15 Sep 2000 07:52:04 -0000 Received: (qmail 1969 invoked from network); 15 Sep 2000 07:52:01 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Sep 2000 07:52:01 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 15 Sep 2000 07:52:00 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA20418 for ; Fri, 15 Sep 2000 07:51:59 GMT Message-ID: <39C1D555.84AAF7B7@ipricot.com> Organization: IPricot (DotCom S.A.) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> <000e01c01eb5$d541b160$29e65982@student.utwente.nl> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 09:52:53 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 1588a006592b8bc2e0821bed1391bac7 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Marco Al a =E9crit :
> Insight-Electronics has a nice board with the Spartan-II, which
> probably has the best gates/$ ratio of the SRAM types.

Hi
The problem we may encounter there is that the SpartanII family is
limited to 200k gates (FPGA gates, which you could call "marketing
gates"), which may be a bit small for a CPU design.

--
Nicolas MATRINGE          = ; DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.dotcom.fr/
 From JEAN Olivier Fri Sep 15 10:03:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02614 for ; Fri, 15 Sep 2000 21:39:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:17 +0200 (MEST) Received: (qmail 2569 invoked by uid 0); 15 Sep 2000 08:07:09 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 15 Sep 2000 08:07:09 -0000 X-eGroups-Return: sentto-1101623-706-969005203-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 15 Sep 2000 08:06:48 -0000 Received: (qmail 5733 invoked from network); 15 Sep 2000 08:06:43 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Sep 2000 08:06:43 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta1 with SMTP; 15 Sep 2000 08:06:43 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SM2QRJ7G; Fri, 15 Sep 2000 10:03:55 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Sep 2000 10:06:05 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE4AF@nts40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 10:03:58 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Latex Manual Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b49d75a0e0b328771019ea6a97169510 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page


Hi everebody.

Well, I think there is many problem about mail list because
I don't receive the message from it.

Question : Where do I send the latex manual ? His weight is
about 64Ko ( in ZIP ). I can use bzip2 to reduce the weight.

            Good bye.

                  OlivieR.

P.S. : The latex manual is a beta manual. There is many pb
about formatting.
From "Marco Al" Fri Sep 15 10:47:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02620 for ; Fri, 15 Sep 2000 21:39:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:18 +0200 (MEST) Received: (qmail 16800 invoked by uid 0); 15 Sep 2000 08:38:47 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 15 Sep 2000 08:38:47 -0000 X-eGroups-Return: sentto-1101623-707-969007121-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hk.egroups.com with NNFMP; 15 Sep 2000 08:38:42 -0000 Received: (qmail 5974 invoked from network); 15 Sep 2000 08:38:41 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 15 Sep 2000 08:38:41 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 15 Sep 2000 08:38:40 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id KAA25115 for ; Fri, 15 Sep 2000 10:38:39 +0200 (METDST) Message-ID: <002701c01ef1$86305540$29e65982@student.utwente.nl> To: References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> <000e01c01eb5$d541b160$29e65982@student.utwente.nl> <39C1D555.84AAF7B7@ipricot.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 10:47:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e5996da369e327d814c5f944c2bdd82a Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

From: "Nicolas Matringe" <nicolas@IPricot.com>

> Marco Al a =E9crit :
> > Insight-Electronics has a nice board with the Spartan-II, which > > probably has the best gates/$ ratio of the SRAM types.
>
> Hi
> The problem we may encounter there is that the SpartanII family is
> limited to 200k gates (FPGA gates, which you could call "marketin= g
> gates"), which may be a bit small for a CPU design.

Still, with about a buck per 1000 gates for the virtex compared to 20 cents=
for the SpartanII... The FPGA version is basically a toy anyway, at best a<= BR> quick way to check the logic. Giving up a bit more performance by going
multi-chip isnt that bad compared to the alternative IMO (which is to put using the FPGA version out of the reach of anybody not willing to pay
500$+).

Marco

 From Jecel Assumpcao Jr Fri Sep 15 14:25:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02629 for ; Fri, 15 Sep 2000 21:39:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:21 +0200 (MEST) Received: (qmail 27713 invoked by uid 0); 15 Sep 2000 12:31:27 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 15 Sep 2000 12:31:27 -0000 X-eGroups-Return: sentto-1101623-708-969021064-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 15 Sep 2000 12:31:26 -0000 Received: (qmail 19559 invoked from network); 15 Sep 2000 12:31:04 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 12:31:04 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 15 Sep 2000 12:31:01 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id JAA13422 for ; Fri, 15 Sep 2000 09:38:02 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> In-Reply-To: <39C160E3.F4F5CB73@llandre.freeserve.co.uk> Message-Id: <00091509594500.00386@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 09:25:34 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Xilinx prices (was: GPL, VHDL, et al) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1601e5249bc28d6d7ddcf0407142a6f9 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Thu, 14 Sep 2000, Jeff Davies wrote:
> Resources (Hardware/Software) required for above:
> 1. & 2.  -> something like Xilinx Foundation $300 or so for version which handles
> VHDL including programming cable. Also a few FPGAs perhaps
> $100 total?  (which fpga?)

Unfortunately, Xilinx's software prices have changed significantly
recently. There is a special promotion for the new Foundation ISE Base
Express: US$695.00 instead of the regular US$1600.00 PER YEAR. It can
only handle the XCV50 in the Virtex family, however. Foundation ISE
Express is US$2495.00.

The regular Foundation series is US$1090.00 (up from US$95.00
previously) for the Base model and US$1490.00 for the Base Express
version. Both of these have the XCV50 limitation. The Express version
doesn't, but it costs US$1995.00 (per year, as in all other cases). See

  http://www.xilinx.com/products/found.htm

But the chips themselves are being sold at very competitive prices.
The newer Virtex-E 1.8V family has more memory and is cheaper than the
older 2.5V chips. If the design is small or can be easily partitioned
into more than one FPGA, then it is probably worth using the Spartan II
family instead. It has the same architecture as the Virtex but all
members can be programmed by the cheaper versions of the programs
listed above. In single quantities, a Virtex-E 300 will cost roughly
US$160.00 while a Spartan II 150 is around US$20.00. You could buy 8 of
the smaller chips and have four times the gates for the same price.

I actually had changed my design like this (back when I was hoping that
this would allow me to use $95 software), but now I am putting back in
the big Virtex since it is so much easier to have the busses inside the
FPGA instead of the circuit board. And I am also going to make use of
the LVDS I/O which the Spartan II doesn't have (see Xilinx application
note 233).

-- Jecel
 From Jeff Davies/CDPTEST Fri Sep 15 17:02:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02638 for ; Fri, 15 Sep 2000 21:39:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:23 +0200 (MEST) Received: (qmail 18144 invoked by uid 0); 15 Sep 2000 15:08:06 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 15 Sep 2000 15:08:06 -0000 X-eGroups-Return: sentto-1101623-709-969030432-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 15 Sep 2000 15:08:05 -0000 Received: (qmail 24132 invoked from network); 15 Sep 2000 15:05:32 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 15:05:32 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 15:05:32 -0000 Received: from modem-70.indiana.dialup.pol.co.uk ([62.137.65.70] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13Zx3S-00006u-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 16:05:31 +0100 To: f-cpu@egroups.com Message-ID: <1F4F166F163A89E98025695B0052956D.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:02:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 47e06c09095e9a368f21ef34105746ad Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

* Jeff Davies <jeff@llandre.freeserve.co.uk> writes:

> etc. pinouts. Cheap low end Schematic/PCB design program like
> Quickroute $140 or so. Can handle about 10 layers from memory.

Maybe EAGLE from www.cadsoft.de. The free version can handle half
euro size and 2 signal layers. Available for Linux.

Colin


==== JD ============
Yes but 2 layers is not enough

Jeff davies

 From Jeff Davies/CDPTEST Fri Sep 15 17:06:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02641 for ; Fri, 15 Sep 2000 21:39:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:24 +0200 (MEST) Received: (qmail 4810 invoked by uid 0); 15 Sep 2000 15:09:25 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 15 Sep 2000 15:09:25 -0000 X-eGroups-Return: sentto-1101623-711-969030558-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 15 Sep 2000 15:09:23 -0000 Received: (qmail 3625 invoked from network); 15 Sep 2000 15:09:08 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 15:09:08 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 15:09:08 -0000 Received: from modem-70.indiana.dialup.pol.co.uk ([62.137.65.70] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13Zx6w-0000jz-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 16:09:06 +0100 To: f-cpu@egroups.com Message-ID: <231B6802E60448038025695B0052CF91.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:06:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: de95a7c23b1ccac7b033403bbeb0f449 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

rom: "Nicolas Matringe" <nicolas@IPricot.com>

> Marco Al a =E9crit :
> > Insight-Electronics has a nice board with the Spartan-II, which > > probably has the best gates/$ ratio of the SRAM types.
>
> Hi
> The problem we may encounter there is that the SpartanII family is
> limited to 200k gates (FPGA gates, which you could call "marketin= g
> gates"), which may be a bit small for a CPU design.

Still, with about a buck per 1000 gates for the virtex compared to 20 cents=
for the SpartanII... The FPGA version is basically a toy anyway, at best a<= BR> quick way to check the logic. Giving up a bit more performance by going
multi-chip isnt that bad compared to the alternative IMO (which is to put using the FPGA version out of the reach of anybody not willing to pay
500$+).

Marco


=3D=3Dreply by jeff davies =3D=3D=3D=3D=3D=3D=3D=3D=3D

We established previously that we would need a minimum of something like $160,000 to make ASIC version.
Perhaps market/consumer confidence will be inspired by having FPGA, and therefore people will be more
willing to stump up cash if we do FPGA first.

Jeff davies


 From Jeff Davies/CDPTEST Fri Sep 15 17:03:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02644 for ; Fri, 15 Sep 2000 21:39:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:25 +0200 (MEST) Received: (qmail 1270 invoked by uid 0); 15 Sep 2000 15:09:46 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 15 Sep 2000 15:09:46 -0000 X-eGroups-Return: sentto-1101623-710-969030508-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 15 Sep 2000 15:08:34 -0000 Received: (qmail 15078 invoked from network); 15 Sep 2000 15:06:48 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 15 Sep 2000 15:06:48 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 15:06:48 -0000 Received: from modem-70.indiana.dialup.pol.co.uk ([62.137.65.70] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13Zx4g-0000KA-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 16:06:47 +0100 To: f-cpu@egroups.com Message-ID: <5E06ABCCE0ED7ECB8025695B0052B082.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:03:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 39e299909ed87aec6c1b0435b06d1a80 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Marco Al a =E9crit :
> Insight-Electronics has a nice board with the Spartan-II, which
> probably has the best gates/$ ratio of the SRAM types.

Hi
The problem we may encounter there is that the SpartanII family is
limited to 200k gates (FPGA gates, which you could call "marketing
gates"), which may be a bit small for a CPU design.


=3D=3D=3D=3D reply by jeff davies =3D=3D=3D=3D=3D

Yes but keep it simple, and split the design into say 4 parts, and it will =
be ok.

Jeff Davies
 From Jeff Davies/CDPTEST Fri Sep 15 17:09:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02647 for ; Fri, 15 Sep 2000 21:39:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:26 +0200 (MEST) Received: (qmail 15784 invoked by uid 0); 15 Sep 2000 15:13:08 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 15 Sep 2000 15:13:08 -0000 X-eGroups-Return: sentto-1101623-712-969030744-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 15 Sep 2000 15:12:33 -0000 Received: (qmail 1684 invoked from network); 15 Sep 2000 15:12:24 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 15 Sep 2000 15:12:24 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta1 with SMTP; 15 Sep 2000 15:12:23 -0000 Received: from modem-70.indiana.dialup.pol.co.uk ([62.137.65.70] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ZxA6-0001Hz-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 16:12:22 +0100 To: f-cpu@egroups.com Message-ID: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:09:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Xilinx prices (was: GPL, VHDL, et al) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 38d0f444685ee5d77cd68cb2f2a9128e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!





Jecel Assumpcao Jr <jecel@merlintec.com> on 15/09/2000 13:25:34
Please respond to f-cpu@egroups.com




To:
f-cpu@egroups.com
cc:



Subject:
[f-cpu] Xilinx prices (was: GPL, VHDL, et al)




On Thu, 14 Sep 2000, Jeff Davies wrote:
> Resources (Hardware/Software) required for above:
> 1. & 2.  -> something like Xilinx Foundation $300 or so for version which
handles
> VHDL including programming cable. Also a few FPGAs perhaps
> $100 total?  (which fpga?)

Unfortunately, Xilinx's software prices have changed significantly
recently. There is a special promotion for the new Foundation ISE Base
Express: US$695.00 instead of the regular US$1600.00 PER YEAR. It can
only handle the XCV50 in the Virtex family, however. Foundation ISE
Express is US$2495.00.

The regular Foundation series is US$1090.00 (up from US$95.00
previously) for the Base model and US$1490.00 for the Base Express
version. Both of these have the XCV50 limitation. The Express version
doesn't, but it costs US$1995.00 (per year, as in all other cases). See

  http://www.xilinx.com/products/found.htm

But the chips themselves are being sold at very competitive prices.
The newer Virtex-E 1.8V family has more memory and is cheaper than the
older 2.5V chips. If the design is small or can be easily partitioned
into more than one FPGA, then it is probably worth using the Spartan II
family instead. It has the same architecture as the Virtex but all
members can be programmed by the cheaper versions of the programs
listed above. In single quantities, a Virtex-E 300 will cost roughly
US$160.00 while a Spartan II 150 is around US$20.00. You could buy 8 of
the smaller chips and have four times the gates for the same price.

I actually had changed my design like this (back when I was hoping that
this would allow me to use $95 software), but now I am putting back in
the big Virtex since it is so much easier to have the busses inside the
FPGA instead of the circuit board. And I am also going to make use of
the LVDS I/O which the Spartan II doesn't have (see Xilinx application
note 233).

-- Jecel


========= Jeff davies: ===

Gulp. Jecel, what tool do you recommend for FPGA design then, say for
example we want to split
an initial version into four parts of 200K gates each?

Has to handle VHDL I/O of netlist.

Jeff Davies






 From Nicolas Matringe Fri Sep 15 17:16:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02650 for ; Fri, 15 Sep 2000 21:39:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:27 +0200 (MEST) Received: (qmail 8391 invoked by uid 0); 15 Sep 2000 15:16:04 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 15 Sep 2000 15:16:04 -0000 X-eGroups-Return: sentto-1101623-713-969030939-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 15 Sep 2000 15:16:00 -0000 Received: (qmail 23109 invoked from network); 15 Sep 2000 15:15:38 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 15 Sep 2000 15:15:38 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 15 Sep 2000 15:15:38 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id PAA00018 for ; Fri, 15 Sep 2000 15:15:34 GMT Message-ID: <39C23D4B.F05C665F@ipricot.com> Organization: IPricot (DotCom S.A.) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <5E06ABCCE0ED7ECB8025695B0052B082.0000000000000000@chrystal.gbr.xerox.com> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 17:16:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 17345ccbc747b4497246e376e8f2c685 Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page

Jeff Davies/CDPTEST a =E9crit :
>
> Marco Al a =E9crit :
> > Insight-Electronics has a nice board with the Spartan-II, which > > probably has the best gates/$ ratio of the SRAM types.
>
> Hi
> The problem we may encounter there is that the SpartanII family is
> limited to 200k gates (FPGA gates, which you could call "marketin= g
> gates"), which may be a bit small for a CPU design.
>
> =3D=3D=3D=3D reply by jeff davies =3D=3D=3D=3D=3D
>
> Yes but keep it simple, and split the design into say 4 parts, and it<= BR> > will be ok.

I was talking about the Insight's board. If it has only one chip, it
will be short.

--
Nicolas MATRINGE          = ; IPricot / DotCom
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
 From Jeff Davies/CDPTEST Fri Sep 15 17:13:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02653 for ; Fri, 15 Sep 2000 21:39:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:28 +0200 (MEST) Received: (qmail 3840 invoked by uid 0); 15 Sep 2000 15:16:48 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 15 Sep 2000 15:16:48 -0000 X-eGroups-Return: sentto-1101623-714-969030997-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 15 Sep 2000 15:16:47 -0000 Received: (qmail 28055 invoked from network); 15 Sep 2000 15:16:37 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 15:16:37 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 15:16:37 -0000 Received: from modem-70.indiana.dialup.pol.co.uk ([62.137.65.70] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ZxEB-000244-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 16:16:36 +0100 To: f-cpu@egroups.com Message-ID: <6443D3F39F38DF498025695B00537863.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:13:48 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e50322dc663462432d8215c4588d48f2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> A simulator, gas & gcc compiler and a port of linux shortly after on the
> software side would be nice.

Writing a simulator after design&implementation? Somehow that feels deeply
wrong to me.

===reply by jeff davies =====

errmm the software list and the hardware list are two seperate concurrent
processes now that architecture is defined.

Jeff Davies

 From Nicolas Boulay Fri Sep 15 19:06:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02671 for ; Fri, 15 Sep 2000 21:39:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:32 +0200 (MEST) Received: (qmail 14233 invoked by uid 0); 15 Sep 2000 17:14:06 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 15 Sep 2000 17:14:06 -0000 X-eGroups-Return: sentto-1101623-715-969038040-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 15 Sep 2000 17:14:05 -0000 Received: (qmail 26997 invoked from network); 15 Sep 2000 17:03:34 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 17:03:34 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 15 Sep 2000 17:03:33 -0000 Received: from 195.36.172.238 [195.36.172.238] by lh00.opsion.fr; Fri, 15 Sep 2000 17:01:53 GMT Message-ID: <39C2570D.4B60A18C@ifrance.com> X-Mailer: Mozilla 4.05 [fr] (Win95; I) To: f-cpu@egroups.com References: <5E06ABCCE0ED7ECB8025695B0052B082.0000000000000000@chrystal.gbr.xerox.com> <39C23D4B.F05C665F@ipricot.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 19:06:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et leon Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7cad3dd5d1f0943dfd74fd12750f8c23 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Hello, every body !

Nobody receive may last post ? I believe that this could interrest lot
of people. It's about the leon processor, a sparc like, completly
fonctionnal. It's written in VHDL using the GPL and LGPL.

cf : http://www.estec.esa.= nl/wsmwww/leon/

I thinks, it's exactly what we have to do. Release the fcpu in HDL, in
the terme of the LGPL. A "binary" version is only a synthetised c= hip.
Usual compagny can used the core as they want and with there own code
without having to release it in the GPL licence. Nowdays, the compagny
looks for IP's, add some of their design and sell it. For example, a
compagny takes a licence to arm and to TI, and build a SoC for handy. So why not using f-cpu instead ?

The leon, it's a almost full sparc V8 compliant processor without fpu.
It take about 5000 CLB of a XV300 (almost 80-90% of the chip, at 25 Mhz
for the -4 series) (6900 cells). But the XCV1000 is about 27600 cells.

For the virtex E, the XCV3200E is about 73008 cells( cf.
http://www.x= ilinx.com/products/virtex/ss_vir.htm). And this familly
could support DDR-SDRAM... The futur Virtex II is quite amazing lot more cells and memory, and some multipliers capabilities (0.6 TeraMAc in
18bits, quite goob ;) ).

The price of this kind of chip could fall with a killer applicaton...

nicO

Nicolas Matringe a =E9crit:
>
>
> Jeff Davies/CDPTEST a =E9crit :
> >
> > Marco Al a =E9crit :
> > > Insight-Electronics has a nice board with the Spartan-II, wh= ich
> > > probably has the best gates/$ ratio of the SRAM types.
> >
> > Hi
> > The problem we may encounter there is that the SpartanII family i= s
> > limited to 200k gates (FPGA gates, which you could call "mar= keting
> > gates"), which may be a bit small for a CPU design.
> >
> > =3D=3D=3D=3D reply by jeff davies =3D=3D=3D=3D=3D
> >
> > Yes but keep it simple, and split the design into say 4 parts, an= d it
> > will be ok.
>
> I was talking about the Insight's board. If it has only one chip, it > will be short.
>
> --
> Nicolas MATRINGE         =   IPricot / DotCom
> Conception electronique    16 rue du Moulin des Bruyere= s
> Tel +33 1 46 67 51 11      F-92400 COURBEVOIE= - FRANCE
> Fax +33 1 46 67 51 01      http://www.IPricot.com/

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Yann Guidon Fri Sep 15 21:11:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02677 for ; Fri, 15 Sep 2000 21:39:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:34 +0200 (MEST) Received: (qmail 11739 invoked by uid 0); 15 Sep 2000 19:07:28 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 15 Sep 2000 19:07:28 -0000 X-eGroups-Return: sentto-1101623-716-969044840-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by cj.egroups.com with NNFMP; 15 Sep 2000 19:07:27 -0000 Received: (qmail 24765 invoked from network); 15 Sep 2000 19:07:19 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 15 Sep 2000 19:07:19 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 15 Sep 2000 19:07:19 -0000 Received: from f-cpu.org (nas3-67.aub.club-internet.fr [195.36.145.67]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA08445 for ; Fri, 15 Sep 2000 21:07:16 +0200 (MET DST) Message-ID: <39C27473.92D850B1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000914193537.QHIL7640.femail1.sdc1.sfba.home.com@[24.10.43.202]> <39C160E3.F4F5CB73@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 21:11:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b908f6081b51d5d9a1a35bc73909e6fb Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

Colin Marquardt wrote:
> * Jeff Davies <jeff@llandre.freeserve.co.uk> writes:
> > etc. pinouts. Cheap low end Schematic/PCB design program like
> > Quickroute $140 or so. Can handle about 10 layers from memory. > Maybe EAGLE from www.cadsoft.de. The free version can handle half
> euro size and 2 signal layers. Available for Linux.

gEDA may handle this. GNU PCB softs are more mature than VHDL softs.

remember, in last january-february, we studied this point
(PCB for the F1) and i have installed some tools on my computer.

Yet, i still have to find a good GNU VHDL suite. i have downloaded
Electric Editor and gEDA but haven't used them yet. that will happen soon anyway.

> Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 15 21:11:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02680 for ; Fri, 15 Sep 2000 21:39:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Sep 2000 21:39:35 +0200 (MEST) Received: (qmail 12799 invoked by uid 0); 15 Sep 2000 19:08:11 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 15 Sep 2000 19:08:11 -0000 X-eGroups-Return: sentto-1101623-717-969044844-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 15 Sep 2000 19:08:08 -0000 Received: (qmail 12376 invoked from network); 15 Sep 2000 19:07:24 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 15 Sep 2000 19:07:24 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 15 Sep 2000 19:07:23 -0000 Received: from f-cpu.org (nas3-67.aub.club-internet.fr [195.36.145.67]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA09296 for ; Fri, 15 Sep 2000 21:07:19 +0200 (MET DST) Message-ID: <39C27477.3623F17A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <098A4E5B420CD3118F690008C75DD5DD029AE4AF@nts40.sbf.bourseparis.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 21:11:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Latex Manual Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 198cd26b66ec7beb2556c685c8b94240 Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page

hello Olivier,

if you can read this, then 64Ko is ok for the
mailing list. it may annoy some people but we
have waited so long so go forward :-)

JEAN Olivier wrote:
>
>  Hi everebody.
>
>  Well, I think there is many problem about mail list because
> I don't receive the message from it.
>
>  Question : Where do I send the latex manual ? His weight is
> about 64Ko ( in ZIP ). I can use bzip2 to reduce the weight.
>
>            = ;     Good bye.
>
>            = ;             O= livieR.
>
>  P.S. : The latex manual is a beta manual. There is many pb
> about formatting.

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 15 21:51:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03552 for ; Sat, 16 Sep 2000 02:07:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:37 +0200 (MEST) Received: (qmail 6111 invoked by uid 0); 15 Sep 2000 19:47:43 -0000 Received: from mk.egroups.com (208.50.144.76) by mx12.rz2.gmx.net with SMTP; 15 Sep 2000 19:47:43 -0000 X-eGroups-Return: sentto-1101623-718-969047243-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 15 Sep 2000 19:47:42 -0000 Received: (qmail 18406 invoked from network); 15 Sep 2000 19:47:22 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 15 Sep 2000 19:47:22 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 15 Sep 2000 19:47:21 -0000 Received: from f-cpu.org (nas1-201.aub.club-internet.fr [195.36.150.201]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA04602; Fri, 15 Sep 2000 21:47:17 +0200 (MET DST) Message-ID: <39C27DD0.235A85C4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com, Nicolas Boulay References: <5E06ABCCE0ED7ECB8025695B0052B082.0000000000000000@chrystal.gbr.xerox.com> <39C23D4B.F05C665F@ipricot.com> <39C2570D.4B60A18C@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 21:51:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et leon Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2e8ef2f854888774d6c7643966988848 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Nicolas Boulay wrote:
> Hello, every body !

welcome back !

> Nobody receive may last post ? I believe that this could interrest lot=
> of people. It's about the leon processor, a sparc like, completly
> fonctionnal. It's written in VHDL using the GPL and LGPL.
>
> cf : http://www.estec= .esa.nl/wsmwww/leon/

yes we have seen and it triggered some passionate posts :-)

> I thinks, it's exactly what we have to do. Release the fcpu in HDL, in=
> the terme of the LGPL. A "binary" version is only a syntheti= sed chip.
> Usual compagny can used the core as they want and with there own code<= BR> > without having to release it in the GPL licence. Nowdays, the compagny=
> looks for IP's, add some of their design and sell it. For example, a > compagny takes a licence to arm and to TI, and build a SoC for handy. = So
> why not using f-cpu instead ?
that one of the things i had in mind...

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 15 21:51:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03555 for ; Sat, 16 Sep 2000 02:07:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:39 +0200 (MEST) Received: (qmail 30458 invoked by uid 0); 15 Sep 2000 19:47:53 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 15 Sep 2000 19:47:53 -0000 X-eGroups-Return: sentto-1101623-719-969047250-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 15 Sep 2000 19:47:49 -0000 Received: (qmail 29916 invoked from network); 15 Sep 2000 19:47:29 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 19:47:29 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 15 Sep 2000 19:47:28 -0000 Received: from f-cpu.org (nas1-201.aub.club-internet.fr [195.36.150.201]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA04449 for ; Fri, 15 Sep 2000 21:47:18 +0200 (MET DST) Message-ID: <39C27DD2.C3D0993B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 21:51:46 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] status Content-Type: multipart/mixed; boundary="------------C409805E8A358EF3B7AAB3BB" X-UIDL: 292ad8d69812677602e25cb6fa478d51 Status: R X-Status: N --------------C409805E8A358EF3B7AAB3BB Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello everybody, the vacations are almost over !

i say almost because i have to present master work on monday,
and i'll try to chill out (take vacations ???) during
one week.


Olivier Jean has some email troubles but is ready to publish
his manual update : i'm really loking forward to this.
we have half a dozen of instructions to discuss and we may share
some Latex edition among the people of the mailing list.
Some parts will be added : exception model, implementation, ...


assembler/simulator : i guess that it's the first thing i'll attack
now. i'll probably be working on GNL for the DEA (the grade under
doctorate in France) so i'll be doing at least two things at the
same time. there is a more-or-less standard C front-end for GNL,
so i'll have to make a F-CPU back-end and we'll have an
"interactive compiler" :-)


HDL is the key though. i'll have to stick to C before something
decent exists (particularly : graphic editor + simulator).
People working in this branch are encouraged to help and work
at this because it's what people expect to have.


Sven is back on the german mailing list : cool :-) i hope that we,
in France and Germany, we fund our respective associations at last !!!


Last but not least : i would like to put the eurolinux petition
banner on the f-cpu pages. please go to http://petition.eurolinux.org
and register yourself. The European Patent Office is going to
make almost everything patentable. Damn, there might be a patent
about silliness because they seem to use and abuse it.


thanks for your attention.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con) --------------C409805E8A358EF3B7AAB3BB Content-Type: image/gif; name="patent_banner.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patent_banner.gif" R0lGODlh1AE+AIQAAP///xsNgVRJYI2FQMbBIP/9AFRJZP/9Do2FRyQzbC1ZWG+7Jp/RHkCl LzZ/Q8bBKmaVO11vT40SQMYUIP8XAFQPYEBYG0B+JS0yTjZYOUCRKjZFNC1FU5/RF8/nC/// /yH/C05FVFNDQVBFMi4wAwEAAAAh/tFUaGlzIEdJRiBwaWN0dXJlIHdhcyBjcmVhdGVkIGlu IHRoZSBFdXJvcGVhbiBVbmlvbi4gV2UgZG8gbm90IGludGVuZCB0byBhc2sgYW55IGxpY2Vu c2UgdG8gVW5pc3lzLiBBY2NvcmRpbmcgdG8gRXVyb3BlYW4gTGF3cywgKDEpIGludGVyZmFj ZXMgYW5kIGZvcm1hdHMgY2FuIG5vdCBiZSBwcm90ZWN0ZWQgKDIpIFByb2dyYW1tZXMgY2Fu IG5vdCBiZSBwYXRlbnRlZAAh+QQEyAD/ACwAAAAA1AE+AEAF/mAgjmRpnmiqrmzrvnAsz3Rt 33iu73zv14LC4BQsGAlE4/DHbDqf0Kh0Sq0+g0uSotFQ8ILImXFMHodT5XJ2NUi730drDU6H C1jtuhCt77tNeX56KIF2KoVpJoKLRiYCBIxkTwlcDQsLlVxVkYpwayR1n4R1ci6kfHCOqYYw py+IajmwoSWzYzGuLJB0ZzxlLJSZwlwWxRaah2SiqG5LRW7PzSe0Lra3NxTZ2tkVJhXb2RLM kWR3KHC9Abt/pnQx1ozLIvAj62UE9K3uNfBk6TRt/mkZRjCTCjA06CyLRm0arxX22M2QAG7b jlwyyA1agRGPQln7TEQM2S5VNQLm/pKR1NFmYMFMCUYMEGjjoy5PMQT0U5bSR4UJFcFN6IZr ZTWj42KdQ6pSY5pl+VYw/KXPJIyZguRB4bKADINMXkqJHUu2rNmzaNPqgKS2rdu3cOPKnRtA mIxCWunq3cu3r18qVEtUSjBTAAQIDCLohGGvZ0k9jkfYRDHyaU+sD+N2FDG1TGQRjMQwTQEv 7ys/NKM+lngTHaF1APeseJnJguiib6xlmQyKN5vNNb6BIzqiIvESoQYoV97nnzXJb2gutXrU qTLSCq2qbgE8RWc30p3QzqRBA5ewPnxX9j2veyecNIKGG/ETnDjuo6uDX85/vWyO+Z1QGkjU BfBdgO+9/rHDgeXQYI8KW4yHDHZjfAZgbk3B55110OAgHwX3eQMUBcclFVhOdFg4AoMqBuCe gBwqVUuAfeCmoH5OmSYDQ+ZEyIURmICljj9/FWnkkUgmqeSSTDbp5JNQRinllFRWqQOGJQjQ opVcdumllQmMIUobzBVQwkjhfanmmmz+NdiO5ix2ZYossCfVTmJu6VaMA+hJgn9xmBhjIzMO SiggmWWYCHKGLjoKajpSeA8JlaDHz40v+KGCnWc2WoCfZHlqRIuCWCiqJIUa+mhDiBbo4qmH igBojXOgROYJlURAwDDKZWrrf5kKIhCnr7qmwqya5bcZntfZyFoLA+LA7Kit/mK6mqN1IhiF A7Q5AFgkPdnZT7Aa9iDBiB+G6JCr9bCH03NVWQstsVdF0st22bKbwqzU5lBZXtzSdoFtAWQw oSod5ivNemHYyepv2rJQn1DeVKRub41GptuK5V4or0eDakXPgXfg6/GzLjziR6TYDdHSCgEL XMwFXUCE0iNpYiwNdPGcACjLAYxbA7rDmUA0BROc/BR//L3gX2TGKowyxFjeoNq0qJL78Qz8 FpAzDhIOY6kvHQe9iDw/zxvxCUene/G1J4rWKH76Srqz1UiFFu/UNjAYK45mnBCMhGOT0NnX Oj+1bx95zYrPZXogjgJF8rEA1NsJ8q321onLOB3n/nYrLu1ofl+jtebVev3ZrEAjNwQWKoTd AEev45NR2Vk+vLh1krfQtjYTSCA80SVuujajVSsaN/KgrxoyjHW3e3yxzadKTu/VFPJ4XYRj dkSfbYYv/vhx5bELpR64EaQX5ntN/vvwx69WhAx4gEkbChQu//789+///wAMoJfkJMACGvCA QAgUAhfIwAZyJg0CYYsDJ0jBLokpdemoDKgqyMEOzkUBC2DAVxyRElHYA3seTKEKz+Ijb73D a5BAoaAUaLzkwUAns1DOBtuiER3OoB95gdXfzDY36L1BT/gSopnuBAt8gG8HAgmYD1CSkBdR T3QtUJm9dlgWQ0mOVp8T/lXqYuS8u5VxeUo8o6aAsAtRVGJBbZQbnWYIrN3FiIulENWWuiad NFqPjEaMWiCxBRoh5s46NYhIOnwECi0t0Wlp4CJq6GiarjECj5swiveiEzp60fGRgPPcpfpg IZPVsHok2IkTy7S8vZ0gQt4qQJC4skN7tK6Qa8ycKA1XB+mwLll1i9YhS3W76A1ylz/MyjGz BjdmKq2VM+rbij7jowIMAwI3NFwx/QA13BHRmLi0YVrcsxl0gFOX0Oxks/AmrDGmM4yEPCV4 yuIjgsRkCvZiHhZ5OUepRfIJw9uG8PyZTr+5Mw62uKUV/4jMu4ArldNb6AN7yQRQpiBs93yH /kLzyTMzyiRRrREnDigHPKIIB3ifJMKsHEOycHpmb/Gkmkdj89D2nLNz70SYHm7pnUA8EQX1 LMgFMDCCBOgvlbuwXTOV0NIrIlN36nSmDdpWPIvB847oVMJHUYlTqcrUOiJzB8NsytWumu4F pavQDRTJgvFowAIb4MAxZrehl9JtZzhxmCchOr0TnBQcbKvIJxdBRZEUSJDP9KryehhVQj3H lCl10CTnoFiX0MYYNKOr3YA2GYbp1ZvLrKwLfpc0o1FssKFo0cb4OtOrija0kQirVQ4EKGfF 9IZ8jELY3moB8xwVB7zBmlYPGjgXpI0Gf91GaeljHIK+9q4xjZhE/rcqUocelhMwzSlam/ME 2QnpB75J6zr1edt1HZEGJBVsBdKLNMxFNpGN+tp0ydpa637MkmeFbnklu9dNtShmsvutOjDp 1PFKj3FqfG6BDQyDDwVPAsWzrXYXC1bn5hdk1X0hu8Q7xMRe2DuhnDAgfPpTy4bNhSNuY4n1 y2D6EqsfvoSqC9hrkTndNAmn2tJ8v1lfDYNOEBJWsE0LS5kdu1g6skMxjoub3QuiIK2mgRWB i1M5FYwowuQVsXn3CVuLZvXDFP4e08bMtM9AdkgbOd1+Geo1/pCyimAWQVBfApEWe7iOht2r FrE60g8Vj6RY/nKHN4e6jnI5y0Km7vOIwztoju14usKFYBN6AmA6a5NsGVb0ob2DX39MOQW/ k89yl9rog/TT1KzY8poZTQ6oaOvRa9vzJZ0wXBGEDT39YgmZfcgCHJKZwDhsxoqdIDz7uBda u+7VXZINNGaLjNk5cba0y0wEaCN71xpNNhBYqYxh90CDAahn/cSGphWa+9xwIZIIKCHC9BXA AyJcH495iu5629sHyn4EpRrg7jHMkn3OkOG9B05wH3CBAWX4bsEXzvBSKMAB+Wu4xCdO8Ypb nC8hAAAh+QQFZAAfACwAAAAA1AE+AEAF/mAgjmRpnmiqrmzrvnAsz3Rt33iu73zv14LC4BQs GAlE4/DHbDqf0Kh0Sq0+g0uSotFQ8ILIlnFMLhutTnMW/SOYx2s2afCuGwVyUZEczvtdCVwN CwuCXE9vUAOLeDCLA40uAo+RaiuTjzeUKJszdGUtj5BUn2RxZn0/opE7mHGXmZKiLa6vKqAr gYa7XBa+FocqpUIpdokiw0JwyAUibmQlZWvPY9Gmc6gmliPHI8nE3Gas1Msk26FmJd+n6d7S 5XQu38YFqcy45tLuZKwo5yLd7kEbsUcJtoEA+bAoY89TPRVbeEkUpAKMi4Cc/pEoeIeWOBfk Olq7Fo5kPoUl/svtQ5jSoLx2K6up+yhQpYx12mAG+JbTZEaYGjXyHBGy4QsBIcERSWrLUbMR EScKSuDNKAyMJ4ZeSjqGQD+CXI98JfpmiEaCdqwGEKozoc8VWk+ELTB2Z9sY88qy4IrnH9K0 /YLqO8iSsN6Zdl7ldcmEywIyDAx5+UO5suXLmDNrzuNms+fPoEOLHk1l1823pFOrXs26NRN8 JKYO8AoBAoMIk2CQq3uysOsVZ11zpOsZJ9m7Vqip/e20aWypgizMOHOLHsJkQ4yvtT7WOvGe 3hkf5w7+CL3hg1ksZoz+TUPsdtMLC38k691/c1kKpv/dcB177aUXIGo2QGeIBhpw/jEZDliZ MM9Y63UToU4NnqNdS9S5ZVN8vgX3U2FYafcgDRdy2JV/T/Um3nZ2BCYfixvGxZ9SJmaD2H+6 +aaFgRTNNwZvGKaYQlwmoOdVVTQaGclsNNZ4BJOHjdfVIm+4+BaRMK7oo2/oLZKUPVg6NWND 7kH5Dx+P2Jhlk2zBFgBXWUySoYmPJNXIMHXSNANHjUTVgBGFSPYmSswVauihiCaq6KKMNuro o5BGKumklFJRxysCAFnpppx2amgCG9pFpZCDMuTpqaimqtpUMmSqh3ML0Zeoh8zBedmEP1aW TKrzpCLIgjXkBZysiNLKGpyx6Dpjf2wYO2k9ctoiSAQE/vCyyAvQ0gGrhjJB6mxqYVpWYoOq huYAdA6kgdyNLg23UVoVwZtCgMM1lV9dloQlJT8vRBjHgFbBF4C76uF3F5YaDfgQhuxcg2MK c9WVH7OltghxlCecC90F0gWQQTBJVHkCfzEJgV4jptZEapZ97FoCX85gvOZ3TI2UcsQDi/yS m06GgR67JusMF30B35feMO/Nud/NaqpciU9l9PNXFlGXMPV82a1sgsYb+3JBFysQ4BVSapGL 4pxouQkTwRiqiDa3StVb3sJwx4Hwi1t2GzPP3yxZB4nn/KWnk3Ov8R++L7bJUkhrCOykliqH ugOPvABrg9klN5m5KJxfG3nn/py7rbWFZwWkuN5199tWiKTjrTreAd1N4HpPv3W60gyB3slG czUkuHsFNz2CLjxa/q7wc2sNtPJwM28z6kNidKGdJFDP8PKFv17YcKlwj6INJdac+Tj4+YPP 0ivGVSInEA42ioOuazMEFipQ3gBw8xOw7czB6/h8YsmT2eOMganwfOV2K/tW5lAwsfpgL1gz GovCzmSdVKCvSVjClZBw5TfykAhpo6CcAsxUj/eV64QoTCEpzCOkBnjgDYHywifcsBwV2vCG ONxBRBjggULQQQHGy6EQh0jEIhrxiEjcTG6SyMQmOrFIDnyiFKcoRO+ZoDNUzKIWFxUqpL1M aFsM/qMYR6OABTAgMkVa0hUJNcY2ulEzUUkXXupBwxqQrFjxK5ScCCSHCekPMzPUVKWMojEf HEkMxDqUAlUTlv2tkD6CjMIiHyW4V/QoB5VEZHhmlUfWDMiRU9DgifIwj1QVpQRRMUemnCeX wY1sXYqapGiQJ65t/I6PUwhJJL2lo4ikqwCBcswu9wa5/7FSkZ1UTbiUJZ+f/YERJ4yEq0wQ lQLwAgIwYIUgMYdHXK5mmZQZFyzfmAM/8YIqTeBmjeIUqluKpCLWgydD+pLHXvFmG8k4pMr0 iQ4CFslWH2KP5OzTTARmb41qsNKGtnHKoaVsXmVCgZFAuZYWUA6deNmW/joF1g2FNcWjEp2R LbxjFDX0boBvi54/MwdGlS1BnU5agjs1JzubTFBIFyThQ79ojFbSYxrWgdUeTQYRHl0AA8ML 4hye8UfzbdKlM1sC43LGRmIahCNJE+nyemrMZY1zIzoVAjSbB0D/mEWBomxKTcWTOy/pJ3Fa PV5X8KBLs6ZJJdi5azGtSrcUGEgDFtgAB4BxP4hW7ZVPXWcp16mixsmnoIO70IUwArwg9Wd9 Ku2QTiQrjcX2j6RfWatS8MRAtzWMjZSFjcu4JVGq+W+JxfDfjgz0i68VNrOas+zfXAq51cHG tyxZHwXdNNkXiZaiRBKnat+R28+GB0xGM8k3/vh5UAxBd7k+cZwARUdRGlAOsBZIkFJlsNHt ijJD58UpclqHGtMZN7oDJSiIDsZeb+ZtRRg7bvUAU93UfU+3l0pbgK220h7YT1A5KO+60stS rjYPsXgtHYXey7NJEol1R4NpQLUUO/hq6V6m/Z/dJkyffxnDdyeOAcVKwDX7jfdNu1QwH8H5 X03qqL4cJnGMPNxc+aIOw9KV5fJe0eEK13PAazpt+nS8V3mSa6YpdVApxorKAzdAjlJ+BpWd Ktvxxda+1+tnex/bluJeicfILfMFN+hKMZ15p0SS2yWAAtc3B/ere0nmVB06yhPYD8sh6/OX uxy5+/aVII7dKaKN/slOv6jJimFeoIi1B714xpNwEBQQV5bXhy7lw8Tnq/OO1dbmN2GDunum A6qTydoUmFMqYQOzjKHH06DW+qcEjquAK9hfTId4ZzpqYK5q7JAZ+bTEohNaTh+4a3qcTU24 qqEkSNBiWG/kBrOOslwL3Gwk7/c/wZlQdyisWTBL+p/0MAqN+ewd3kRsuMZgxbKJva/dRq5p fkwwjUQYjmFmpXMsqIXnaAFCQQ61hAanxvs6ByQSmvDfq7AawNXBuWEKfFsHb2prQwcE3UVc Hgq/U8WzQo6He2Pkc0A5ojnOiZILFYQVgTkOYOYnHlbuS+TMuc7lQKhAnPGFBfDAGWNIMKed G/3oipCpr1xYhmDKUOlIj7rUo8AFBpQBwVPPutaZoAAHAHHrYA+72MdOdiqEAAAh+QQFZAAf ACwAAAAA1AE+AEAF/mAgjmRpnmiqrmzrvnAsz3Rt33iu73zv14LC4BQsGAlE4/DHbDqf0Kh0 Sq0+g0uSotFQ8ILIlnFMLhesPTO6VzQL16SBe35+yclZeJNQDutvCVwNCwuCXE9meT0DjDGM iiuPAiNqKo+QLwKPKJszlSqajJNQd2QzoVmlSk2oo6CXrid8pjqXQKIvZSyBhr1cFsAWh5Z4 KXSfZaWTAgSTqnUiz3G6I9LVfSafAdoBz9Dd2m1jitwq3M/kySTJY8vNLN50eWax4MWU1Ov5 9rTm9SLlyl27B3AfvzHTDArkVMDPiS2+IgoC1dBFohUXZZX5p5EMRxOz2mXLJ+5NCXoD/sed NLiNpTGDIY2YeOYwo6OFJUo6jKYOXz+fCEfENJki5jyWONGNKAkJJU+CBX/SkKNFYq8E1XbK sIkCJ4mhUEuAVZnEDJKFYyueUKpPaku3L+GKKOmxq8sW8eSBdKOpJwm6BSYtBLxKqNM+/8a+ e0p2rxutjAsDlfmDywIyDAx5+cO5s+fPoEOLFs1ntOnTqFOrXv2nlwxVmFjLnk27tm0oLgUl GNAMAgQGETTBiPmxbePbduXKHlp8jbdafmsHRRESsmc5sUlYNWTB07cTx/KpA2v4GKa0xyeH //42/Mw+xwiLZOE+pfmRKslHWp8+75yjbpWDnmTt3ReZXgc2/sXfe/wZ0ZwM2xmigQZcbIYD V+At1KBkGxIl0CdsGSdZiFFNp14uCrH0nHrs4eWVfUTBCKCJJVJWY4sp+GfjiQwRROKNqURX II6O7WgCRBE2sN985giJH41imTVKX9+BtRiVUfbB2xwrkUEAI26U8GNAd2XoljeMgJWOcks2 mAVgYLqRhzdfpiXmY3HWgeaW/5WHB58ydjnGl/HcGdaLK5Q0CpINGFGIZgHEZB1ylFZq6aWY Zqrpppx26umnoIYq6qi39ZnTg6SmquqqniaQHjhxZuklq7TWauuluskgwJTZ0ddgpYiyFk+v UugYbKCflslZPA4JYmENeWH0K6XH/p4GZyd6GKssg6/OVlqP3X7WUF+YCBIBAb40YlEz2Pka FqbVmhZvsfPm6ORq4qTqwHYOOIHhkyY944p8xRFc1Bx0lYXwWuPxJYJiKNJRpFnJFSZwm1BS hGd0ZMqFniLyOZjTekG+G0DIHKFDWHNj9brvdhd0F0AGwyi8kZnrTZYnWZL6GWOksz58qFNj /UW0UwcecTIdy1BsEUtDhUHXTsmgCc+GczoNp4jscWPlKLwB+KXPRg5pL1R0jQJWLMMujY29 Q1C1wsswA3NBFysQ0Awzk/4r6KAd0ejXUH9n8WE+Pw5ZcnodZ1yxkeWseKNaMEhOzLskNr4j c6fox/XZ/o0lbtOY28aQpC/P2uA317Elcsnrrrj+uiQ8/g2N6H6RHmDptd/IrYmrY1w2w5hz jNQ+weok2PHKhYi7j0IiyuwJvCSZutFOxxVu74ayCSORCUllOedkO6Q7lNVyoxP2dXFvx7EY coU00PvQlZ017quPrNDt8w/4/r4TwxCwoILTKckcAxybtEz2ORUMCEoPLFsE3RJBrZyvbOlz SciY5D4XaAttHVrTY8qxQWgco2VcQ5yTKvi7n9WrGqr40iROpwA+HWEAqLqVDnfIQyvcYRba 8YAbHuWFH1Kuh0hMohL1ABEGeKAQclDA9ZZIxSpa8YpYzKIWPSWcLXrxi2DU/pXSwkjGMpZx ahoxoxrXqKpXxVBW/WOjHOdYKQUsgAGZMcGuqjGxSdHxj4BEDZL6dRO9HTEGGwIW71hDpe1N 4YOOAxeBOMWMca0GMi/zwWLclTNqLTI1aSFWFCA5PNBNUlOJA00lfxaAiehglaIcksQ86b1L IihbHarcvWaTnTCZJmolQNI6dgW+wHEQZ6e81AtBQ5PQWM4GqWRkKd12zNC4BCL9KsCjLJND n4kyeLSMJGuW6YRnQmuXqglJonComoFxBEkF8AUEYBALVIETOeT0TD6ZYM6poBM1n7QUo3yB lSbcM3dHqMcq/wcKYArvHTixkilNQr4D+RFgAgFM/nEQaknhFVOPQ4mb8XbXPDlJclAc2eDi kuk/hrYwgV7q5jZacLqCOoJYBy1G2liknPq00KdLWc8/0JEWJPjnojyl0QMho46dXq6WKbyl 2WxnTK5MMBYRXCkrSzjUZBR1neNozkAjcgEMjCABU4zDLBSIzGPoTJZzuVlJ9ChXFXWoSg3a CSn5E8udKUFd1BRq4eDqUanK0kABbGBQwzMjn7oJgPRbj15D6MC3FXA7GrDABjggjAOiwKkY nWWB/GoSjo7xrZFxCGgPsqPMRYdO3wvM9yKGvn08s2r3ZC1iI3taICmWe9lbij4Uqjkikci1 ULFa0hY4zRGM1RfBuJtn/iXZy2mNVmTdg9xP8Fej8J1SG+fQxgW79snwDg0q7JCtLh/rPuTW drv/nMvjyFtS9BrEcuPlwekyawEKpXUr8TVpaG9J2cQq9nmhix7zxEnV3y6XRbHMbnMhy9rG 0hd4AU3aeyPpPCeNTsFQfYEBIZWDnN6lwIc11VQbXGGMalWEGCxvis4E3hf286U4zh/yPhm1 4k70xS6GbLzUiwK6GfC/keqmicMFv0Uerh8IHhGINzxhB0euxgz0qIuKZ1+SYjiOj4vdgqfZ 4Xd9+LwMjkYpcHGkETeAkDPhE5u1x9IOJmjLjqQwlmmE3ynHOMQrvjPrHPw+J9u1yzRKGIwu /jpjKht3pHwWr58/ytpJGRDONjtkW3GqrOAKxXaQoZpfAONdytmv1DC+cJV13D/PGXi9f5rd nMcnP8uSOoX11NPNWuogwNokCABsZlxfO+mnifO5EclbltXDaTaV0EjP/k60E81eIY+Z0q/m tWjtfDWsfQXFgV2Q7Xy5Vym7VdCLJZmEU52DWBjZKjm5wZKrvNSqejrcXhLIgCCTXxZzspQb 5Mgy96oI9IR0ZAjLqE/z0sg46ojCvL13iwkN4DzQEB8yXQvsIvE6FzQcsCn4uCjXDLaOfxY2 Bdt4HEy+clt4kOWcqE6vZkcDVMh6dild6xJszk6QolTNLo/5oDBBX/LFstXnSlCoyomA8pAv HejYksFYJsEoJ6JOooHMutblxdBA4FGIBfAAHol4kAhv/exoL+fOm9UAsI9hm0Vce9rnTvfO cIEBZSBx3ffO9zUowAFS7LvgB0/4wht+NiEAACH5BAVkAB8ALAAAAADUAT4AQAX+YCCOZGme aKqubOu+cCzPdG3feK7vfO/XgsLgFCwYCUTj8MdsOp/QqHRKrT6DS5Ki0VDwgsjWwEgum8nW 6ticTU/XZ6VbHEfBy/NUHXeXUxNcDQsLgVxPfUZTAgOMAjOMjDKLjSOIbSmQA458lHaQN5Yu mZtWiAV2eyyZkpmXJ6kkBGcroZWdL2YsgIW8XBa/FoYqd66VcceJI2dwBI4CBEuyZZdnpAFF eCR9Ycpn3MZsJNjZ2t4lcd8B0mbW6ssxtSPjaCWI6ZZkS2MvpsiwIvNOlSvzbUw7cNNM/BOx sF6cdg0xFUhXYkuvi4FUgBEVUeE7FAEFuliX70XIg/H+AtgzEfLcLIfhYCaEkVKluRItB+ay YQrVy1gfW/wUUTNAw45Eg3bbCUpkAIsYAyWoRBEeUhJXgforJs/fxIPySJJBUrQrsqpLySEs KZMtP6Us/aFNGrNGzxN3QXptZkKskU0rsQ7FedZa0aw1uCwow6CQlzyQI0ueTLmy5csoZGHe zLmz58+gIfOSQSy06dOoU6tOw5SE1AHNIEBgEGERDJJg29Jb3bQu7xU5QefVnawy0nW04NoV wiJqIQszivv0qvadqSx+43ANGZG7V1fe0b3ytrffTI5exVEniPflMfTr3ydZb8K8fJetsx9r Yx+ZD+eFaKABF4/xgZhRD03+F590C5433Fp+MKQcgr4tVFRZw8Cl3Xi+mTIXHYNBKJ2EDTLH kn7npbWbYK215xuJaq1AkgpQAZgcGbnpFKMeIXrkDSmMjGjThgDBZiKLZkBj3iXcMZIdRRYq h6FEL16zn5E36RghDQ+K6JSXRy4iSxZXohhhQ08GKd1hPcIwzyY1GkGIY+6M9dudeOap5558 9unnn4AGKuighBZqqGf7sZTjoYw26qifCbhljJol+PXho5hmqqlnUkmyiW1cljjolH72w5Vk XdLVomQH3pgiT+KNEEiBy13VX5t7kqpnmp9sluqQq0aWlZDEnRpdM2MUE0gEBPQSiQtfJatK q6X+TsinrpX9+mse3QWr5ZFSOOCcA05six9bAX0T3qV1HrNou95g+Mx3PObi3acovlsfdSfS q2BxfukL7I6qEjyCmTmGZyeHMSosqSXesZudseI6dwF0AWQgzHzVuLggkkpwp2IBQFa5Dchf WpmgynBdB1B2Pn6EIl/w4miVyUTOGyIiNW+ZYYnBnjxyW5p46cpRuBbMHstLSzTEPitUbPEv F3QhYzPPzGUuyjbH9aJSfhH3bcoDb+lXMSvDuKLS4LJtrMeS9ox2x2CyS6W3XYb9bQuLEMk1 w2vvWyW1LQB4Ea2wJs211vG24jjXjjteco8p+Q3538UK/uq0X09ouSn+At9tcJfaRT6Kekk6 wmawtiqHmIcn7GI44qgn6arBMQd+7sIgsvMCzLv7nLYIZwef8oXWiu4zhWW0U/y3b3OOd5R0 r9Cy6z0Ofw30uROLAnNYqGD4xt8P8Uz0W49Mdl8fe71eMWYmyn58YFG/ObaZnxB/83Avf/P0 bXKYW/qDIjK1iT4iOpriaHEHaDhifArA0hGKtqkKWvCCqDqCdBrggTjMyQtrkIXdMEjCEpqQ CRZhgAcIMQYF0O6EMIyhDGdIwxraEE+guqEOd8hDvh2hh0AMIg/Tpb/1CfGISOxT3AaWjuyE LolQjCJnFLAABjRGUZWY3w+lyMUumgYq5LL+CgFEWKv2BQp/1xJL9OagLcJFwY39a1sOqlIx H9BMevEZVfL6VEDOtHGBVoCj5pZoA525IiM6MGTv8igoNP5GYWt0wx+9xa0F5vBfcqyBWNIB FawIIAgxCNjtdGcoR/ImVp+ZJO7mcBVpjDKTNQiWRchVgDkp5onwQp8g82RK1fQyD6okZSUp OY5XRtIFpPjkCaBSgF5AwE3iwKMwCfVL1FRTkhFJXyDbJBZjVqFGvZhKE7TJvAjpDBpxhGW/ UudD6+xRgpsz3sGqR7ws0YRfeJnYK3VCQWl6b2s6I4i+4CnQeu3oVuAKRUAJqQIjusZw4oTH 28gpsyw57EP7y9H+/iYkwIl8rxpecYSZRgimhsUHLTxjWtdeub5tZbSI8Zlbazqa0GX4SyNw 6OcyDXcBDIwgAS/UhjTQicn0jGwI7mKbM+g5sjBsEqYlcsVG+Wc8oPnHJASdSK/q2SCUzAJ2 i7TqR5f21LFtpXsiQejDrPq2sorPORqwwAY4EIwGaISpJb1POYXQD7YFr3v8eRHoavcqVKpU eMM7RjosF1Y5GjYkl+CZ/PwpKsBqKbCZfB7m5Pkz23mJBZQcATgvAoyq2bWz6lTrisjjUcC1 TSkpFZHxXJGSLj3IfkvsZU1s+w97/CVUVg1cbP0qD9QuD2mhLVtrN6uD8cXVAgMKKmn+DqTY ou6Fa9SZXNCUwli1bQm3y9OthjwH26QCF4Crsuqi7KNA1iludaucwfh4Id3/xVd9RlRtdYCW hVRVjrwV2pmU9hhHagA4RS4r4+gWwlYtEgR77k0ufKf5ikVJbb71vSNLoZU8U1LLv9w9sKTA K0fxdq5Ke60pII37TwavGCDVmzCxWje4FauJr2AZ7bg8IY1bFJXDvjMohfMH5PuVV8CDITFt CTxIn/F2MIFRMCmfHM/+RRbCBKPx5g4ktBPMN4x6aZryvIdWluYGSvYUx5XtqU+tiPkknOUe keGzREsRdqVu6w16s5xmeRhwpuiYhPpcu1ybyJm51lulji/7IqMqj63IQ9YvoZGxZP42GZ9x TuClj5nnSxt1zo/IZkQahJ3gHqkhCD30oHNgjQtHBSd6vq93HermTxPmfRxTrLU2mhslb9q+ /uNqSDHJ6XT+OMzUacPMUvzbWSP7qp1GNA22BMFu4JIlkRPF47BKEgdqmw2RlCAFJ3E6nBIE fdtWcysOQm5IXLvdPgZJA6MHb53OoN7byTYDwY1aneYUJem2wzq8jRPJ1SfgMnDiUwqhwl4o wM5ejLjELdM0QFixgwXwgBU/OLBiT/zjIOfBs57xUIyTwZYgXALJQ87yls+BCwwwA51cTvOa W0EBDnChzXfO8577/OedCQEAIfkEAcgAHwAsAAAAANQBPgBABf5gII5kaZ5oqq5s675wLM90 bd94ru9879eCwuAULBgJROPwx2w6n9CodEqtPoNLkqLRUPCCSCtMQDCaz+g0eqVGZ2GDtnyu XMXpdTvehze38G8td32AKkVzLmV7gnRhOwlcDQsLkVxiT30EAjmFKopzjk2DhGaBAaNtfKRr Jp0on3KbLqhqoSO0aLIkuJknjTGsKpCVxFwWxxaWKqOmKhUU0NHREijP0tAVMLB9uiquJrxn zSLhcuOniwGHteVGqnNZ27nfJX0y7e4p5fLBI/xm//zgiGOrxJZiCCMZKlBQhYRr1yb0EPIC X4EU9Hzh6YaRzjl8KdYRemcuRcA25/5EnDTC8RWehvoItTyxUiCUOFoSEktwC6YNCRMgCp1A rcYAi2cIpGzl0YYApGiUzkQB0oVINSRRvli5dFnNqF1lyJvaYuylElwWnGFQycvZt3Djyp1L t67dGGXu6t3Lt6/fv3eJ3RMHuLDhw4gTy+03IlKCAZogQGAQ4am2M2TPXk2jSR8sNk3LElLK AjLhZasoUk23I/XFjvBYbFYzgKNpbklix1y1EBQc1Sp0VrIwI99PodlKIA+5qrOMjCTsRcFX LktVHoDoRA+tUXsMi6sRiZgt8KSjlVCEV9KggYtbHkGFYiMBFGJRHVC9ce8u3gV0cqyN55pN re2n0oDAgf7zH2y6oZaaJ67p8FkKB6nXgB5mZFZCfPKt8NB8LCAYi34NyiYiIR8FmJt02BlI E4pWnUiHhhCOeJmNV+QiQoUNGEFJWwHA4pNiRBZp5JFIJqnkkkw26eSTUEYp5ZRUAkObCQLQ WOWWXHY5ZQKlKHiUcQdG5eWZaKbZpGMyZDleWHzdRgppIboYw1NfpVHbLCxi2F+BdvKnFQ1P pUbnCuQRyMJKWpYpx5C31EJCJO8ZlYpdiUZIYkkVycjpbiM5+KcOqyy1YAmZnjhVppAGSUpp v8DAUKHNRBIBAcUc9cKsccBJxXWcBEpCqgl+txRUZ4Q3arCpjXOqq7GuUFND7f6Mg+wRDEr6 gwPCOUBXBR/KF80Eya34UqMonErddCeWACypIgay4LqyQteOu434RgJ6W12ZArfCXUBcABko Yy5mMFTA4TXlkmDNNfeZlBq6AcxrcbOgyiHCjOh412Js+2wsbJ98qhjpo+p4DK1W9w42BE4r ABzwMRd0Ia0mZLQqwsPLmRDuuA1/t4qGF5eIL8bKarxvuxPtR+ynJtQ0mMm7IOjSgFNYWEyl OSwsrjQSRMzE09n6WzZW/gn7rj9YN220gK6lVBO6+OjcsUzS8jaQtiUMYyHXw/Lt0NdipxCU BEEzBdA4ZPRxzrNwFw310cuWkCeZ8L4dOCldPb3nLv55UuwojotuhN0QWASnNRuoH9oCz0OF HfbC5O7qKUt1ao7o7WCJqnTpVNsAecrDV827rzWmIfroCN80ilQBaK2AnAx9rub12Ge/1x2K TOqBGj96wT1D2pdv/vl2HcSAB5TEoQDg6Mcv//z012///V1ahv/+/PfvFLb+C6AABziCqzQk LwRMoAK5FCbKkW9pylugBCeoJAUsgAFswZIuTCEkCnrwg4qpkLeERoAy2M0vT+HFUaz3B2G1 6Sj/WOHy8NGoteHgJbbTnbH4oRQWAg9lL0jUCYk3B4o1BGA+cI5frsUZ0OiwNJeDh4YsojMb 3gBvuZtcyeL1w0GZyIWbK/5iEBVhCoXooHHFqsvTSKY4LSIqijDyHcfkiLaP4dCJbpQY7zKk xzyGEYwiE2MizJQTg1UsS6/pl47skqcVwvBSZ3ODIjnnyEeaLWl3xGQdAYXFdAGSiHtcZNTm GEkvelKQOcTcjrjgrQL8KC1GPE1drAgOmJWygXk71xjucCzXTIWWNXCNTyDXC+awkXlp2FQc X4TKIBZwJhUqQDEgMIZh3aVunDTlKZv5AyY+0IGQzCYpZnKqVNmNWORU2XZ8eYJ2LM8FPCoG T+4iO4ghLpemu6ILicUuBNkmeMFEUEFOlckW8FNQTayHiP7JTf+0QGvzNJYOfgaN2omAohRI XP4BSxXQJx6zmycKBTBpIKNuSE6bWczjfjySKV1kCnnqGIQPDWKhC2BgBAmAH+iOANMRYBRE yrGPIaI4xED6kV432cNJZDHS4rBUXxUbGUA1uUmFcuokS8jUCD5pOUKqTicasMAGOJCMCxmz eS6AnTQ0GgCvQSNGzUklSk+mQyamyDtCvNvvxKknZCJsQR+lY1Wt2gY0mlKrXG1jIilkIWTU zKwZ85Vax1WNno0hijQ66SXB6biMhdM8U3Vqg4QI2NAqaKpcRFVq02OhsFqgPTq9wdckUgKF CfUGhs3nNue61eDZ1bNVXeNgb2ggOMrytE9E6GaV+x/h4pK1WqNUD/4mS1lwufWePvDcLfNA VUmmra4mM64qifs25z5XsYL7ojq3m1AUOLen3siMzKIb2yCJ7msUkF3h2oSXwD4Lmy0E73oj pzc78ta4KTEnXEmZUqietXilkelMAxBP9YywlmScsM8I5zYNQ9DBhOXtH4GozOXSda+jLDBf vXswYhYUS1+hGLHO2Vn8eNUE0b3wwexGXWjst7bx+fE69eTIy5W4rwYtVZGXiVwUY0nFmfOj X0U84lDirk3RSjKIyTveEVQ4IfhMYwp6TAGLlqA+QMWjp4iW2Cnf7q6VS7FprZRcUNa5gOJl MJbbUFQ7J6UK3ZivTlDFAzKLS8hUyfN52aoL31MoWhw0ampvB6zPO+uVysBFWg4202cCA6QK 3I3e33r7zhbMLiJh68EKUaKre1Ty1aWuZThkOIMUvtqRu7z1Cn2ga0dSrNdHiXUBLQkWD+NA JJ3e6J+lwI9N8Gh9W5NHskFI7WpHYdkBgAQGv1cAD2AwfHpttLXHTW4etJoMk2oAt83wSvFl ddrljre8ecAFBqABSPPOt77PogAHvG/fAA+4wAdO8MOEAAA7 --------------C409805E8A358EF3B7AAB3BB-- From Jecel Assumpcao Jr Fri Sep 15 21:49:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03567 for ; Sat, 16 Sep 2000 02:07:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:44 +0200 (MEST) Received: (qmail 27006 invoked by uid 0); 15 Sep 2000 20:35:20 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 15 Sep 2000 20:35:20 -0000 X-eGroups-Return: sentto-1101623-720-969050093-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 15 Sep 2000 20:35:16 -0000 Received: (qmail 23101 invoked from network); 15 Sep 2000 20:32:52 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 15 Sep 2000 20:32:52 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 15 Sep 2000 20:32:49 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id RAA14546 for ; Fri, 15 Sep 2000 17:40:03 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> In-Reply-To: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> Message-Id: <00091517312502.00386@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 16:49:14 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b2546e9a5ff178ef57864423d638e7b Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Jeff Davies wrote:
> Gulp. Jecel, what tool do you recommend for FPGA design then, say for
> example we want to split
> an initial version into four parts of 200K gates each?

I like to write my own tools, but since the FPGA bitstream format is
secret this isn't an option right now. Other vendors offer cheaper or
free tools, but either the chips are far too small or much more
expensive than the equivalent Xilinx chips.

There is the Student Version of the Foundation software, but I wasn't
able to get much information about it. It comes bundled with a book. I
don't know if it handles the Spartan II chips.

If it was just me, I would buy the tools no matter what the price and
be done with it. But my idea is that many people will buy my computer
or download its design and want to change it. It is not reasonable to
ask each one to pay $1000 or more per year and get a large PC running
Windows to do so.

It seems that JBits might be a solution. Previously I had thought that
it was simply a way to download a bitstream created with other tools to
an FPGA under your application's control. But this paper shows that it
can actually manipulate the bitstream as much as you want:

   http://www.io.com/~guccione/Papers/JBits/JBits.html

About partitioning the design: it was easy for me since my processor
has a TTA architecture and I restricted each functional unit to access
exactly two of the four busses. See the block diagram before I change
it back to one big FPGA:

   http://www.merlintec.com/merlin6/e_main.html

I don't think breaking FC0 up into smaller pieces will be as simple. In
fact, I think that one of the major problems with the iAPX 432 product
was that Intel was forced to split it into 2 chips.

> Has to handle VHDL I/O of netlist.

The "Express" versions of the Xilinx tools handle VHDL just fine, but
the others are limited to Abel and schematic design entry.

There is an interesting tool that I have read the manual but haven't
finished downloading yet:

   http://www.ics.ele.tue.nl/~ad/idass.html

This is meant for the higher level design phases of the project and can
output VHDL and Verilog so that other tools can be used for actually
programming the FPGAs (or doing the chip layout in the future). It is
free and runs on both Windows and Linux. It is now also open source.

Going towards the other extreme: there is an interesting design method
similar to Chuck Moore's tiling Okad system that was developed during
the 1980s at the University of Utah. It is called PPL (path
programmable logic) and it combines the behavioral and layout levels
into a single notation. I mentioned this when the fcpu-tools was first
created, but the reaction was surprisingly negative - their idea was
that anything not supported by commercial tools should be ignored since
no foundry would accept our designs otherwise.

I did buy some tools for PPL from a small outfit called "Bonniville
Electronics" (or something similar) but they weren't very nice - mostly
a patched version of Emacs. It would be simple to build better tools
and I intend to do just that. If there is any interest, I could post an
explanation of how this works.

-- Jecel
 From Yann Guidon Sat Sep 16 00:03:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03570 for ; Sat, 16 Sep 2000 02:07:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:45 +0200 (MEST) Received: (qmail 12213 invoked by uid 0); 15 Sep 2000 21:59:34 -0000 Received: from mr.egroups.com (208.50.144.80) by mx06.rz2.gmx.net with SMTP; 15 Sep 2000 21:59:34 -0000 X-eGroups-Return: sentto-1101623-721-969055151-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 15 Sep 2000 21:59:32 -0000 Received: (qmail 15409 invoked from network); 15 Sep 2000 21:59:09 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 15 Sep 2000 21:59:09 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 15 Sep 2000 21:59:08 -0000 Received: from f-cpu.org (nas2-200.ras.club-internet.fr [195.36.192.200]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA26321 for ; Fri, 15 Sep 2000 23:59:03 +0200 (MET DST) Message-ID: <39C29CA5.8DFE168E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> <00091517312502.00386@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 00:03:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6abd53e60be995b27b47e2eb0da3c1ab Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page

hello !

Jecel Assumpcao Jr wrote:
> I don't think breaking FC0 up into smaller pieces will be as simple. I= n
> fact, I think that one of the major problems with the iAPX 432 product=
> was that Intel was forced to split it into 2 chips.

the fc0 has been designed to be monolithic. otherwise you'd need 1000's of<= BR> pins and they'd draw half of the total power. But for the start, we can tes= t
small parts of the whole design, or make a scaled-down attempt if it doesn'= t
fit in one chip. "better scaled down than split" ;-)

> There is an interesting tool that I have read the manual but haven't > finished downloading yet:
>
>    http://www.ics.ele.tue.nl/~ad/idass.html

i've contacted the maintainers some time ago : they don't release it
under GPL for a certain number of reasons. plus they are bound to a certain=
flavour of smalltalk that is free only under Windows. that's why i haven't<= BR> tried it yet , even though i have all the files at home. like you said, i d= on't
want people to be charged if they want to develop under another OS.
this is an important side of the F in "f-cpu".

> This is meant for the higher level design phases of the project and ca= n
> output VHDL and Verilog so that other tools can be used for actually > programming the FPGAs (or doing the chip layout in the future). It is<= BR> > free and runs on both Windows and Linux. It is now also open source.
but not GPL.

"Open Source" is not a garanty of any kind concerning freedom of = use,
continuity or future development. we probably can trust the idass team
much more than the vgui team (at least, they still update idass and are
working on v5, while vgui people don't answer mails). but still, the major<= BR> compatibility layer must remain the HDL, documented with screenshots and dr= awings.

> Going towards the other extreme: there is an interesting design method=
> similar to Chuck Moore's tiling Okad system that was developed during<= BR> > the 1980s at the University of Utah. It is called PPL (path
> programmable logic) and it combines the behavioral and layout levels > into a single notation. I mentioned this when the fcpu-tools was first=
> created, but the reaction was surprisingly negative - their idea was > that anything not supported by commercial tools should be ignored sinc= e
> no foundry would accept our designs otherwise.

Chuck has had problems when they switched to a new silicon technology :
his design was stuck to a certain number of layers of metal.
Even though the F21 is an incredible stuff, it is not scalable
and this is the major problem that i can reproach. this is a very
important lesson and the f-cpu is the complete opposite : scalability
to a paranoiac extent, broad range of target technologies, long life span (not a throw-away instruction set, at least at the user level).

> I did buy some tools for PPL from a small outfit called "Bonnivil= le
> Electronics" (or something similar) but they weren't very nice - = mostly
> a patched version of Emacs. It would be simple to build better tools > and I intend to do just that. If there is any interest, I could post a= n
> explanation of how this works.

if you can help us have a good GPL HDL toolsuite, please go ahead !!!
this lack of suitable tool is killing the project. it is probably the
number 1 priority in the next week.

> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Jeff Davies/CDPTEST Sat Sep 16 00:34:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03573 for ; Sat, 16 Sep 2000 02:07:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:46 +0200 (MEST) Received: (qmail 15117 invoked by uid 0); 15 Sep 2000 22:37:08 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 15 Sep 2000 22:37:08 -0000 X-eGroups-Return: sentto-1101623-722-969057426-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 15 Sep 2000 22:37:07 -0000 Received: (qmail 19044 invoked from network); 15 Sep 2000 22:37:05 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Sep 2000 22:37:05 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta2 with SMTP; 15 Sep 2000 22:37:04 -0000 Received: from modem-26.androderm.dialup.pol.co.uk ([62.136.79.154] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13a46R-00010F-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 23:37:04 +0100 To: f-cpu@egroups.com Message-ID: From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 23:34:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et leon Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3899a21196c8f670c4e848f05d6dd780 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Nicolas Boulay wrote:
> Hello, every body !

welcome back !

> Nobody receive may last post ? I believe that this could interrest lot
> of people. It's about the leon processor, a sparc like, completly
> fonctionnal. It's written in VHDL using the GPL and LGPL.
>
> cf : http://www.estec.esa.nl/wsmwww/leon/

yes we have seen and it triggered some passionate posts :-)

** Jeff Davies:
Yep, we all talked about it a lot when it was announced about a year ago
The problem with LEON is that it uses SPARC architecture not a free
architecture.
Ok current prices are $99 to use the architecture in a commerical product.
But say some years down the line, Microsoft buys Sun, and suddenly you
can't use the
architecture no matter how much you want to pay. The architecture also has
to be free.



> I thinks, it's exactly what we have to do. Release the fcpu in HDL, in
> the terme of the LGPL. A "binary" version is only a synthetised chip.
> Usual compagny can used the core as they want and with there own code
> without having to release it in the GPL licence. Nowdays, the compagny
> looks for IP's, add some of their design and sell it. For example, a
> compagny takes a licence to arm and to TI, and build a SoC for handy. So
> why not using f-cpu instead ?
that one of the things i had in mind...

> nicO
WHYGEE


 From Jeff Davies/CDPTEST Sat Sep 16 00:53:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03576 for ; Sat, 16 Sep 2000 02:07:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:47 +0200 (MEST) Received: (qmail 8347 invoked by uid 0); 15 Sep 2000 22:56:21 -0000 Received: from mu.egroups.com (208.50.99.218) by mx19.rz2.gmx.net with SMTP; 15 Sep 2000 22:56:21 -0000 X-eGroups-Return: sentto-1101623-723-969058574-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 15 Sep 2000 22:56:17 -0000 Received: (qmail 1903 invoked from network); 15 Sep 2000 22:56:13 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 22:56:13 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 22:56:13 -0000 Received: from modem-26.androderm.dialup.pol.co.uk ([62.136.79.154] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13a4Ox-0003tv-00 for f-cpu@egroups.com; Fri, 15 Sep 2000 23:56:12 +0100 To: f-cpu@egroups.com Message-ID: <410971B06A9D587C8025695B007C2153.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 23:53:20 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2943abd8da569ea5283452cb339a856b Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

jecel wrote:
>secret this isn't an option right now. Other vendors offer cheaper or
>free tools, but either the chips are far too small or much more
>expensive than the equivalent Xilinx chips.

I found some of the others to be awkward to use, and non-intuitive, whereas
Foundation is pretty good. At this stage, all we need is to pick a tool,
decide which library components we are going to use, and then write VHDL
individually, send it to one person to import into Whichever-Tool-They-Use,
and that person program up some FPGAs for us.
Any volunteers?

>There is the Student Version of the Foundation software, but I wasn't
>able to get much information about it. It comes bundled with a book. I
>don't know if it handles the Spartan II chips.

I don't think there is any VHDL support - you'd have to use ABEL with the
Student version.

>If it was just me, I would buy the tools no matter what the price and
>be done with it. But my idea is that many people will buy my computer
>or download its design and want to change it. It is not reasonable to
>ask each one to pay $1000 or more per year and get a large PC running
>Windows to do so.

Agreed

>It seems that JBits might be a solution. Previously I had thought that

JBits is Java API for boundary scan, and you can program FPGA through
boundary scan
interface, am I right? This could open the way for Java programming tools.
(think layout optimisation should be through C++ though - best to be
non-gui as well).


** Re your design - don't fancy GPLing it do you?


>I don't think breaking FC0 up into smaller pieces will be as simple. In
>fact, I think that one of the major problems with the iAPX 432 product
>was that Intel was forced to split it into 2 chips.

I thought iAPX432 consisted of 3 chips.

you could obviously have registers and EUs and Instruction decoder in
different blobs with Databus
and control signals between them..

> Has to handle VHDL I/O of netlist.

>The "Express" versions of the Xilinx tools handle VHDL just fine, but
>the others are limited to Abel and schematic design entry.


>   http://www.ics.ele.tue.nl/~ad/idass.html
>
>
>This is meant for the higher level design phases of the project and can
>output VHDL and Verilog so that other tools can be used for actually
>programming the FPGAs (or doing the chip layout in the future). It is
>free and runs on both Windows and Linux. It is now also open source.

Will check this out. How does it know what library items are available on
the system
you import the VHDL to?


> -- Jecel



 From Jeff Davies/CDPTEST Sat Sep 16 01:00:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03579 for ; Sat, 16 Sep 2000 02:07:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:48 +0200 (MEST) Received: (qmail 9655 invoked by uid 0); 15 Sep 2000 23:03:47 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 15 Sep 2000 23:03:47 -0000 X-eGroups-Return: sentto-1101623-724-969059007-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 15 Sep 2000 23:03:45 -0000 Received: (qmail 22548 invoked from network); 15 Sep 2000 23:03:26 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 15 Sep 2000 23:03:26 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 15 Sep 2000 23:03:26 -0000 Received: from modem-26.androderm.dialup.pol.co.uk ([62.136.79.154] helo=sargon.chrystal.gbr.xerox.com) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13a4Vw-0004y2-00 for f-cpu@egroups.com; Sat, 16 Sep 2000 00:03:25 +0100 To: f-cpu@egroups.com Message-ID: <3E5B42DFC39D5DD68025695B007DCFC5.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 00:00:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6c55c5bfa3e8105118fe2cfb141490c4 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


Whygee wrote:

>the fc0 has been designed to be monolithic. otherwise you'd need 1000's of
>pins and they'd draw half of the total power. But for the start, we can
test
>small parts of the whole design, or make a scaled-down attempt if it
doesn't
>fit in one chip. "better scaled down than split" ;-)

Yes but very difficult to fit 64 bit cpu into 200Kgate FPGA.


>>    http://www.ics.ele.tue.nl/~ad/idass.html


>i've contacted the maintainers some time ago : they don't release it
>under GPL for a certain number of reasons. plus they are bound to a
certain
>flavour of smalltalk that is free only under Windows. that's why i haven't
>tried it yet , even though i have all the files at home. like you said, i
don't
>want people to be charged if they want to develop under another OS.
>this is an important side of the F in "f-cpu".

back to VHDL connection list, and someone on the list with an appropriate
tool joining it
all up and programming some FPGAs

>if you can help us have a good GPL HDL toolsuite, please go ahead !!!
>this lack of suitable tool is killing the project. it is probably the
>number 1 priority in the next week.

Perhaps I and others should sent you some $$$ and you get Xilinx
Foundation. Would you vounteer to
program the FPGAs for us?
Once we have an external bus design (really simple, no fancy stuff) we can
use gEDA or something
(the problem with gEDA the last time I looked was lack of autoroute).
The first board should be just static ram, rom and uart. Nothing fancy.
(perhaps with a bus connector so expansion is possible).



>WHYGEE

jeff Davies

 From "Marco Al" Sat Sep 16 01:38:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03588 for ; Sat, 16 Sep 2000 02:07:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 02:07:52 +0200 (MEST) Received: (qmail 2735 invoked by uid 0); 15 Sep 2000 23:30:37 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 15 Sep 2000 23:30:37 -0000 X-eGroups-Return: sentto-1101623-725-969060627-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 15 Sep 2000 23:30:33 -0000 Received: (qmail 13526 invoked from network); 15 Sep 2000 23:30:26 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 15 Sep 2000 23:30:26 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 15 Sep 2000 23:30:26 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA29758 for ; Sat, 16 Sep 2000 01:30:25 +0200 (METDST) Message-ID: <001601c01f6e$1ae7b3f0$29e65982@student.utwente.nl> To: References: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> <00091517312502.00386@gandalf> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 01:38:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 42b5df8bde659be988a21f22baba6fd3 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

From: "Jecel Assumpcao Jr" <jecel@merlintec.com>

> I like to write my own tools, but since the FPGA bitstream format is
> secret this isn't an option right now. Other vendors offer cheaper or
> free tools, but either the chips are far too small or much more
> expensive than the equivalent Xilinx chips.

Altera's Acex is not too much more expensive than the Spartan, and they have
free tools for it... the problem is that the embedded memory is only
supplied in relatively large blocks with relatively slow bus's. Apex (which
is not too expensive either) solves that mostly, but they arent supported by
the free tools :( Sigh... maybe the Acex 2k will solve it.

> It seems that JBits might be a solution. Previously I had thought that
> it was simply a way to download a bitstream created with other tools to
> an FPGA under your application's control. But this paper shows that it
> can actually manipulate the bitstream as much as you want:
>
>    http://www.io.com/~guccione/Papers/JBits/JBits.html

And jroute complements it nicely,
http://www.crosswinds.net/~ekeller/publications/index.html (also see
http://www.ens-lyon.fr/~fdedinec/recherche/jbits/).

How do you get these programs though?

Marco

 From Yann Guidon Sat Sep 16 02:13:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00327 for ; Sat, 16 Sep 2000 10:36:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:33 +0200 (MEST) Received: (qmail 2353 invoked by uid 0); 16 Sep 2000 00:09:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 16 Sep 2000 00:09:15 -0000 X-eGroups-Return: sentto-1101623-728-969062948-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 16 Sep 2000 00:09:12 -0000 Received: (qmail 12905 invoked from network); 16 Sep 2000 00:09:08 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 16 Sep 2000 00:09:08 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 16 Sep 2000 00:09:07 -0000 Received: from f-cpu.org (nas3-79.aub.club-internet.fr [195.36.145.79]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA14600 for ; Sat, 16 Sep 2000 02:09:03 +0200 (MET DST) Message-ID: <39C2BB1D.402FCFBB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3E5B42DFC39D5DD68025695B007DCFC5.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 02:13:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a61d7a7bad9bf54ffa4325022ecee14c Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jeff Davies/CDPTEST wrote:
> Whygee wrote:
>
> >the fc0 has been designed to be monolithic. otherwise you'd need 1= 000's of
> >pins and they'd draw half of the total power. But for the start, w= e can test
> >small parts of the whole design, or make a scaled-down attempt if = it doesn't
> >fit in one chip. "better scaled down than split" ;-)
> Yes but very difficult to fit 64 bit cpu into 200Kgate FPGA.
it's not our first problem today, because we have nothing to put in the fpg= a at all...

> >>    http://www.ics.ele.tue.nl/~ad/idass.html
> >i've contacted the maintainers some time ago : they don't release = it
> >under GPL for a certain number of reasons. plus they are bound to = a certain
> >flavour of smalltalk that is free only under Windows. that's why i= haven't
> >tried it yet , even though i have all the files at home. like you = said, i don't
> >want people to be charged if they want to develop under another OS= .
> >this is an important side of the F in "f-cpu".
>
> back to VHDL connection list, and someone on the list with an appropri= ate
> tool joining it all up and programming some FPGAs

i can make most structural and some behavioural stuff, but the problem
is to document the stuff enough to keep it maintainable.

in this case, the tool should not be a fundamental part of the design flow.=
i could use VGUI quickly to make a first draft but VGUI couldn't be used mu= ch after.
part of the reason is it's not GPL, another gooood reason is that we have t= o
manually tweak the output. but it's possible to do this if we take care.

> >if you can help us have a good GPL HDL toolsuite, please go ahead = !!!
> >this lack of suitable tool is killing the project. it is probably = the
> >number 1 priority in the next week.
> Perhaps I and others should sent you some $$$ and you get Xilinx
> Foundation. Would you vounteer to program the FPGAs for us?

i could volunteer but i don't think it's the best solution in the mid-long = term.
we need a stable toolsuite, GPL is our only chance for the future,
otherwise it gets too complex. i would prefer to get a deal between the f-c= pu group and
a major FPGA vendor, so we could have "free" (monetary) HW and SW= for prototyping.
it's both cheaper and looks more serious, affiliation with the industry hel= ps remove
the fear of the big bad free cpu. Of course, if there was no other solution= ,
this would be the way to go, but we have several other oportunities.
plus, i have just seen that Fabian has already one suite at home.

> Once we have an external bus design (really simple, no fancy stuff) we= can
> use gEDA or something
> (the problem with gEDA the last time I looked was lack of autoroute).<= BR> > The first board should be just static ram, rom and uart. Nothing fancy= .
> (perhaps with a bus connector so expansion is possible).

we've discussed the motherboard already, and it's not bery difficult
for the first proto : a 2 layers PCB would do the trick. i am not afraid at all here. things will be crazy later. i have some 17ns SRAM (32KB per ch= ip).
ROM ? no, we could boot throught the // printer port : easy and cheap.
we spare some problems (like burning the ROM) and we can access internal st= ates
of the CPU for debugging. what about that ? i first imagined this for the S= HARC :-)


first problem to solve : behavioural simulation of VHDL sources.
i could write some VHDL but i'm not very good, so we have to test it.
could some people volunteer to test some early snippets ?

a structural FC0 description could be written quickly (we've been preparing= it for
so long !) but testing will take most of the time. i still have to test ele= ctric editor
and i'll keep you informed.


have fun,
> >WHYGEE
> jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Jecel Assumpcao Jr Sat Sep 16 01:25:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00340 for ; Sat, 16 Sep 2000 10:36:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:39 +0200 (MEST) Received: (qmail 26863 invoked by uid 0); 16 Sep 2000 00:22:30 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 16 Sep 2000 00:22:30 -0000 X-eGroups-Return: sentto-1101623-729-969063747-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 16 Sep 2000 00:22:30 -0000 Received: (qmail 7352 invoked from network); 16 Sep 2000 00:22:26 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 16 Sep 2000 00:22:26 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 16 Sep 2000 00:22:22 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id VAA15044 for ; Fri, 15 Sep 2000 21:29:41 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <410971B06A9D587C8025695B007C2153.0000000000000000@chrystal.gbr.xerox.com> In-Reply-To: <410971B06A9D587C8025695B007C2153.0000000000000000@chrystal.gbr.xerox.com> Message-Id: <00091521205804.00386@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 20:25:29 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 84f6351a5f6568d9aa0ce24aa7e0ba04 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Jeff Davies wrote:
> JBits is Java API for boundary scan, and you can program FPGA through
> boundary scan
> interface, am I right? This could open the way for Java programming tools.
> (think layout optimisation should be through C++ though - best to be
> non-gui as well).

That paper I gave the link to says that JBits also lets you change
bistreams. You can reconfigure a CLB and reroute a net with it. Only
Xilinx doesn't give you any information about it and redirects your to
their partner's web sites (which have no mentioned of JBits).
  
> ** Re your design - don't fancy GPLing it do you?

I have thought about it quite a bit, and my current idea is to release
it under two licenses. The first requires you to publish any changes
you make and forbids you to change its name (but you can sell it and do
anything else you like with it). The second doesn't have these
restrictions, but requires you to pay royalties. This is sort of like
the Artistic license for Ghostscript, but I think it is better adapted
for hardware. And in my case it makes sense since I am doing the work
and other people will at most make small patches to it. Unlike the
F-CPU which is (supposed to be, at least) a collaborative effort.

In any case all information about it will be available as soon as I
write it.

> I thought iAPX432 consisted of 3 chips.

The "general purpose processor" was broken up into the 43201 and 43202
chips. The "i/o processor" fit into a single chip: the 43203. You could
have as many of each kind of *processor* in a system as you wished.
  
> >[IDASS]
> Will check this out. How does it know what library items are available on
> the system
> you import the VHDL to?

It has a kind of expert system configured from a text file to do the
conversion to VHDL. I haven't checked, but I would guess that it simply
supposes that the VHDL will use the exact same library names as the
idass design.

Yann Guidon wrote:
> i've contacted the maintainers some time ago : they don't release it
> under GPL for a certain number of reasons. plus they are bound to a
> certain flavour of smalltalk that is free only under Windows. that's
> why i haven't tried it yet , even though i have all the files at home.
> like you said, i don't want people to be charged if they want to
> develop under another OS. this is an important side of the F in
> "f-cpu".

Note that "free only under Windows" means "freedom". The non commercial
version of VisualWorks is available at zero cost for Linux and other
OSes. But if you run IDASS on top of that then you will be in violation
of the license if you use it to design a commercial chip.

Let me check the IDASS license...

- IDaSS is provided on an as-is basis. Eindhoven University
  of Technology does not accept any responsibility for damages
  occurring from the use of IDaSS (same goes for ObjectShare,
  but they use more words...).

- When distributing IDaSS, you may *not* charge any money for
  IDaSS, except to cover the cost of actual distribution.

- The Smalltalk virtual machine (file 'visual.exe') provided
  with this distribution may only be used to run IDaSS.

- You are not allowed to decompile, disassemble or reverse-
  engineer the non-textual parts of the IDaSS distribution.

This last part isn't such a restriction since they have started
redistributing the sources. The last two parts are probably due to
their need to comply with the commercial license for VisualWorks.

> but not GPL.
>
> "Open Source" is not a garanty of any kind concerning freedom of use,
> continuity or future development. we probably can trust the idass team
> much more than the vgui team (at least, they still update idass and
> are working on v5, while vgui people don't answer mails). but still,
> the major compatibility layer must remain the HDL, documented with
> screenshots and drawings.

Yes - a problem with IDASS is that their design files use their own
format. You can export to VHDL or Verilog when you want to move on to
another tool, but then it would have been better to start with one of
those languages to begin with.

> Chuck has had problems when they switched to a new silicon
> technology : his design was stuck to a certain number of layers of
> metal. Even though the F21 is an incredible stuff, it is not scalable
> and this is the major problem that i can reproach. this is a very
> important lesson and the f-cpu is the complete opposite : scalability
> to a paranoiac extent, broad range of target technologies, long life
> span (not a throw-away instruction set, at least at the user level).

He designed directly at the logical layout level. PPL is at a higher
level, but not by much. Still, it is abstract enough that you can move
a design from CMOS to GaAs with little, or no changes.

> if you can help us have a good GPL HDL toolsuite, please go ahead !!!
> this lack of suitable tool is killing the project. it is probably the
> number 1 priority in the next week.

My tools will be free, but they will run on Self (which though it is
free itself it currently only runs on Sparcs and PowerMacs). And they
use Self as the HDL since I don't like either Verilog or VHDL.

Jeff Davies wrote:
> Whygee wrote:
> > the fc0 has been designed to be monolithic. otherwise you'd need
> > 1000's of pins and they'd draw half of the total power. But for the
> > start, we can  test small parts of the whole design, or make a
> > scaled-down attempt if it  doesn't fit in one chip. "better scaled
> > down than split" ;-)
>
> Yes but very difficult to fit 64 bit cpu into 200Kgate FPGA.

That is 3125 gates per bit. Since the Xilinx chips have a generous
amount of RAM (beyond those gates) that we can use as registers, this
seems like enough for some designs.

> Perhaps I and others should sent you some $$$ and you get Xilinx
> Foundation. Would you vounteer to program the FPGAs for us?

One solution that was suggested to me was to set myself up as an
"application service provider". Since I won't really be using this
Sparc machine after I port Self to the PC, I could set it up to be
connected to the internet running Xilinx tools in a batch mode. Users
could send in their VHDL designs (perhaps as specially formated email
messages with attatchments) and they would get back their bitstreams to
program into their FPGAs. Since I would be running the tools in a
single machine and processing one design at a time, there would be no
violation of the software's license.

Since the input and output files would be rather small, even my pokey
33kbps link would be enough.

> Once we have an external bus design (really simple, no fancy stuff) we
> can use gEDA or something (the problem with gEDA the last time I
> looked was lack of autoroute). The first board should be just static
> ram, rom and uart. Nothing fancy. (perhaps with a bus connector so
> expansion is possible).

For such a simple board, there really is no need for an autorouter.

-- Jecel
 From Steve Van der Hoeven Sat Sep 16 02:31:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00345 for ; Sat, 16 Sep 2000 10:36:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:40 +0200 (MEST) Received: (qmail 19140 invoked by uid 0); 16 Sep 2000 00:31:27 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 16 Sep 2000 00:31:27 -0000 X-eGroups-Return: sentto-1101623-730-969064279-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 16 Sep 2000 00:31:25 -0000 Received: (qmail 11206 invoked from network); 16 Sep 2000 00:31:18 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 16 Sep 2000 00:31:18 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta3 with SMTP; 16 Sep 2000 00:31:18 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id TAA24993 for ; Fri, 15 Sep 2000 19:31:17 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <00091521205804.00386@gandalf> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 19:31:17 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 07b4ea7b7f74834835879e39142d7e48 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> One solution that was suggested to me was to set myself up as an
> "application service provider". Since I won't really be using this
> Sparc machine after I port Self to the PC, I could set it up to be
> connected to the internet running Xilinx tools in a batch mode. Users
> could send in their VHDL designs (perhaps as specially formated email
> messages with attatchments) and they would get back their bitstreams to
> program into their FPGAs. Since I would be running the tools in a
> single machine and processing one design at a time, there would be no
> violation of the software's license.
>
> Since the input and output files would be rather small, even my pokey
> 33kbps link would be enough.
>

Tell me if you need help to setup the service.

--Steve

 From Yann Guidon Sat Sep 16 02:48:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00349 for ; Sat, 16 Sep 2000 10:36:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:41 +0200 (MEST) Received: (qmail 32693 invoked by uid 0); 16 Sep 2000 00:44:04 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 16 Sep 2000 00:44:04 -0000 X-eGroups-Return: sentto-1101623-731-969065037-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 16 Sep 2000 00:44:02 -0000 Received: (qmail 16121 invoked from network); 16 Sep 2000 00:43:57 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 16 Sep 2000 00:43:57 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 16 Sep 2000 00:43:56 -0000 Received: from f-cpu.org (nas3-79.aub.club-internet.fr [195.36.145.79]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA29591 for ; Sat, 16 Sep 2000 02:43:46 +0200 (MET DST) Message-ID: <39C2C345.D4EF7F0B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <410971B06A9D587C8025695B007C2153.0000000000000000@chrystal.gbr.xerox.com> <00091521205804.00386@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 02:48:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6618cff1dcdf312255d5c5e81c91549f Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jecel Assumpcao Jr wrote:
> > >[IDASS]
> Yann Guidon wrote:
> > i've contacted the maintainers some time ago : they don't release= it
> > under GPL for a certain number of reasons. plus they are bound to= a
> > certain flavour of smalltalk that is free only under Windows. tha= t's
> > why i haven't tried it yet , even though i have all the files at = home.
> > like you said, i don't want people to be charged if they want to<= BR> > > develop under another OS. this is an important side of the F in > > "f-cpu".
>
> Note that "free only under Windows" means "freedom"= ;.
without the "windows" attached to it, it would be "optimisti= c".
now it sounds "weird" ;-)

> The non commercial
> version of VisualWorks is available at zero cost for Linux and other > OSes. But if you run IDASS on top of that then you will be in violatio= n
> of the license if you use it to design a commercial chip.
>
> Let me check the IDASS license...
>
> - IDaSS is provided on an as-is basis. Eindhoven University
>   of Technology does not accept any responsibility for damag= es
>   occurring from the use of IDaSS (same goes for ObjectShare= ,
>   but they use more words...).
>
> - When distributing IDaSS, you may *not* charge any money for
>   IDaSS, except to cover the cost of actual distribution. >
> - The Smalltalk virtual machine (file 'visual.exe') provided
>   with this distribution may only be used to run IDaSS.
>
> - You are not allowed to decompile, disassemble or reverse-
>   engineer the non-textual parts of the IDaSS distribution.<= BR> >
> This last part isn't such a restriction since they have started
> redistributing the sources. The last two parts are probably due to
> their need to comply with the commercial license for VisualWorks.

the problem is not Idass but the smalltalk machine and the platform.

anyway i'll have to give it a try before refusing.

> > but not GPL.
> >
> > "Open Source" is not a garanty of any kind concerning f= reedom of use,
> > continuity or future development. we probably can trust the idass= team
> > much more than the vgui team (at least, they still update idass a= nd
> > are working on v5, while vgui people don't answer mails). but sti= ll,
> > the major compatibility layer must remain the HDL, documented wit= h
> > screenshots and drawings.
>
> Yes - a problem with IDASS is that their design files use their own > format. You can export to VHDL or Verilog when you want to move on to<= BR> > another tool, but then it would have been better to start with one of<= BR> > those languages to begin with.

that's the huge problem. that's why the solution is to stick to the VHDL le= vel.

> > Chuck has had problems when they switched to a new silicon
> > technology : his design was stuck to a certain number of layers o= f
> > metal. Even though the F21 is an incredible stuff, it is not scal= able
> > and this is the major problem that i can reproach. this is a very=
> > important lesson and the f-cpu is the complete opposite : scalabi= lity
> > to a paranoiac extent, broad range of target technologies, long l= ife
> > span (not a throw-away instruction set, at least at the user leve= l).
>
> He designed directly at the logical layout level. PPL is at a higher > level, but not by much. Still, it is abstract enough that you can move=
> a design from CMOS to GaAs with little, or no changes.

like VHDL... or i missed a point :-)

> > if you can help us have a good GPL HDL toolsuite, please go ahead= !!!
> > this lack of suitable tool is killing the project. it is probably= the
> > number 1 priority in the next week.
>
> My tools will be free, but they will run on Self (which though it is > free itself it currently only runs on Sparcs and PowerMacs). And they<= BR> > use Self as the HDL since I don't like either Verilog or VHDL.

i don't like it either but that's the only thing there is here.
i don't like C either ;-P

> Jeff Davies wrote:
> > Perhaps I and others should sent you some $$$ and you get Xilinx<= BR> > > Foundation. Would you vounteer to program the FPGAs for us?
> One solution that was suggested to me was to set myself up as an
> "application service provider". Since I won't really be usin= g this
> Sparc machine after I port Self to the PC, I could set it up to be
> connected to the internet running Xilinx tools in a batch mode. Users<= BR> > could send in their VHDL designs (perhaps as specially formated email<= BR> > messages with attatchments) and they would get back their bitstreams t= o
> program into their FPGAs. Since I would be running the tools in a
> single machine and processing one design at a time, there would be no<= BR> > violation of the software's license.
>
> Since the input and output files would be rather small, even my pokey<= BR> > 33kbps link would be enough.

THAT is a solution :-) it won't be easy to setup but if it works,
it'll be really cool.

> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From "Marco Al" Sat Sep 16 02:58:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00352 for ; Sat, 16 Sep 2000 10:36:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:42 +0200 (MEST) Received: (qmail 18827 invoked by uid 0); 16 Sep 2000 00:50:16 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 16 Sep 2000 00:50:16 -0000 X-eGroups-Return: sentto-1101623-732-969065408-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 16 Sep 2000 00:50:14 -0000 Received: (qmail 28199 invoked from network); 16 Sep 2000 00:50:08 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Sep 2000 00:50:08 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 16 Sep 2000 00:50:08 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id CAA10383 for ; Sat, 16 Sep 2000 02:50:06 +0200 (METDST) Message-ID: <001501c01f79$3cdfd5e0$29e65982@student.utwente.nl> To: References: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> <00091517312502.00386@gandalf> <001601c01f6e$1ae7b3f0$29e65982@student.utwente.nl> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 02:58:32 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f1cf10619941f9ff1301ef2cb364592c Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

From: "Marco Al" <marco@simplex.nl>

> Altera's Acex is not too much more expensive than the Spartan, and they
have
> free tools for it... the problem is that the embedded memory is only
> supplied in relatively large blocks with relatively slow bus's.

Sorry, should know better than to parrot somoene and do it poorly too. I
thought Jan Gray's argument for the FLEX10K applied, but on closer look it
does seem to support true dual ported memory. Still the
Apex/Virtex/SpartanII's are probably much superiour.

Marco

 From Jeff Davies/CDPTEST Sat Sep 16 03:22:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00355 for ; Sat, 16 Sep 2000 10:36:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:43 +0200 (MEST) Received: (qmail 29520 invoked by uid 0); 16 Sep 2000 01:25:43 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 16 Sep 2000 01:25:43 -0000 X-eGroups-Return: sentto-1101623-733-969067537-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 16 Sep 2000 01:25:46 -0000 Received: (qmail 12322 invoked from network); 16 Sep 2000 01:25:36 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 16 Sep 2000 01:25:36 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta3 with SMTP; 16 Sep 2000 01:25:36 -0000 Received: from modem-96.anadrol.dialup.pol.co.uk ([62.136.79.96] helo=sargon.chrystal.gbr.xerox.com) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13a6jW-00089N-00 for f-cpu@egroups.com; Sat, 16 Sep 2000 02:25:34 +0100 To: f-cpu@egroups.com Message-ID: <8EA50D4C31B43D7D8025695C00074F14.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 02:22:41 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f75bb7a1511a46e69d7401205743b36d Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

modified lines start with **

We have an architecture, instruction set etc. that took a long time for
anumber
of people to come up with. What we could do with now is
someone to implement it, and put it on FPGAs etc. I think a good idea
is to take a basic LART circuit, and extend it a bit with a few FPGAs on it
implementing a basic FCPU in place of the StrongArm.

Perhaps an interim step of suffient FPGAs for the CPU implementation
(plus necessary interconnect), some static ram and a boot ROM
containing a very simple monitor allowing download of code from
serial port.

A simulator, gas & gcc compiler and a port of linux shortly after on the
software side would be nice.

(but I guess other folks are busy - like me)

So here is the way forward:

Hardware:-

1. CODE EXISTING DESIGN INTO VHDL
2. COMPILE INTO FPGA(S) & PROGRAM SOME
3. DESIGN MOTHERBOARD1(static ram, rom, and uart + FPGAs for CPU).
4. BUILD MOTHERBOARD1
5. Write CPU tests, run them.
6. DESIGN MOTHERBOARD2 (hacked version of LART)
7. BUILD MOTHERBOARD2

Resources (Hardware/Software) required for above:
1. & 2.  -> something like Xilinx Foundation $300 or so for version which
handles
VHDL including programming cable. Also a few FPGAs perhaps
$100 total?  (which fpga?).

** Alternatively, library building block details are given to
other people, who code VHDL (or draw using VGUI). VHDL is then sent to kind
person, and put onto FPGAs for distribution.


3. RS Components catalogue/CD (rswww.com) to find some static RAM
etc. pinouts. Cheap low end Schematic/PCB design program like
Quickroute $140 or so. Can handle about 10 layers from memory.
Autoroute is not very good, but can save some time. produces gerber files.

** gEDA doesn't have good Autoroute, so only for the brave.



4. Get gerber files made into PCBs. Setup fee will be about $200 (something
like
$15 per gerber layer). PCBs might cost $150 each.
[lower in volume obviously].
Components likely to be about $150 including FPGAs.
Solder yourself - difficult to get anyone else to do this low volume.
So each very basic fully populated motherboard1 (primitive) will be
$300.

5. Cost nothing.

6. Cost nothing. (except maybe a beer or two for JDB)

7. Again, PCB setup cost about $200. PCBs cost about $150 each again.
Components now cost more like $600 per board. (this is a full PC like
system, and we don't have bulk buying capability yet).
Each fully populated motherboard2 will cost around $750.
Solder yourself again. With time, subcontract this.

** 8. When we have built up a following and a name, the $150,000 to get
ASICs started
might not be a problem?

** 9. Free Product Designs:  Organiser (with hardware divx mpeg4 decoder &
perhaps encoder -ie dig cam?),
WebTV (ditto), Portable PC (with video editing) , Server Appliance
(multimedia) . (Desktops are
a bit passe).

Software:-
** (Not after, but in parallel with hardware).

1. Port GAS?
2. Port GCC
3. Compile Linux, and a bootloader, perhaps also openbios?
4. If hardware not available, write and run simulator.

None of the above cost anything other than time.


I was holding out for a way to do the FPGA programming on a free bit of
software.

but this isn't exactly possible right now since the FPGA manufacturers
don't have
open
programming interfaces. I tried the software that Mr Erin recommended, and
it
really
isn't as good as Xilinx Foundation. The really hard part is fitting a
design into
a FPGA.
(The compiler tends to run out of CLBs, buses etc).
So the easiest way to start is put very very simple Execution Units in, a
small
register file
etc. Simplify. You can always build up the design.

Also a problem is, you tend to put Xilinx Library components into your
design,
naturally.
How free is the overall thing then?

Jeff Davies
jeff@llandre.freeserve.co.uk

 From Jecel Assumpcao Jr Sat Sep 16 03:21:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00358 for ; Sat, 16 Sep 2000 10:36:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:45 +0200 (MEST) Received: (qmail 3343 invoked by uid 0); 16 Sep 2000 01:59:52 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 16 Sep 2000 01:59:52 -0000 X-eGroups-Return: sentto-1101623-734-969069582-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 16 Sep 2000 01:59:51 -0000 Received: (qmail 23767 invoked from network); 16 Sep 2000 01:59:41 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Sep 2000 01:59:41 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 16 Sep 2000 01:59:34 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id XAA15268; Fri, 15 Sep 2000 23:06:32 -0300 Organization: Merlintec Computers To: Steve Van der Hoeven X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Cc: f-cpu@egroups.com Message-Id: <00091522574705.00386@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 22:21:22 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ppl (was: cad tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 10b67730eb7f05263f2e59a72858d9da Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Fri, 15 Sep 2000, Steve Van der Hoeven wrote:
> > [PPL]
>
> Can you tell me more about it?

Sure, it is very simple. I'll just give a quick introduction here and
if there is interest I can go into more details next week. I am sending
a copy of this to the list.

In some ways the very opposite of Gate Arrays, the PPL design is done
in a fixed grid defined by the wiring. This is based on the
observation that the design rules for metal and vias are normally not
as fine pitched as those for polysilicon and diffusion, so wires tend
to take up more space on a chip than the transistors. Design in PPL
means positioning cells, that are a multiple of the grid size, next to
each other on that grid. Each grid position was represented by two
characters so students at the University of Utah could use an Emacs
derived editor to create their designs using simple ASCII terminals
(this was the late 80s, after all).

The left character indicates any "cuts" to the normal wiring and the
right character indicates the function of the cell (with a blank
indicating the default of no function at all; just wiring).

Here is an example of a very simple PPL design (you have to look at it
with a fixed width font for everything to line up):

                                           i i

                                          |0 0 + j

                                          |0 1 + j

                                          |1 0 + j

                                          |1 1 + j

This is a 4 to 1 multiplexor on a 4 by 5 section of the grid with the
input and output indications omitted to make the presentation simpler.
The selection addresses come in from either below or above using the
column wires of the first two columns in the design. There are four
column wires (plus power) and three row wires at each grid position,
but they have default functions so that when we say "the input comes
in the column wire" we know which one of the four we are talking
about. The "i" cell is a simple inverter which takes its input on the
default column wire and outputs to the secondary column wire. So this
means we now have both the original selection addresses and their
inverses available in the first two columns. This should be very
familiar to PLA designers and is standard practice in PPL.

The "|" character indicates that the row wires were cut to the left
of the cells in the first column. That is because the inputs to be
multiplexed come in from the right using the default row wires and we
want to isolate this design from any circuit that might be placed left
of it. The "0" cell is part of a distributed AND gate, along with the
"+" cell and the "1" cell. When the inverted column signal is true, it
sends an indication along the row. The "1" does the same thing for the
non inverted signal. A "+" cell combines all indications along its row
and outputs a true if all of the columns detected the signal they were
expecting. So in the design above, one of the four "+" cells will
output a true while all other three will output a false for any
combination of inputs. The "j" cell is a three state design that will
output its default row signal to its column only if its secondary row
has a true value. This means that one of the "j" cells will multiplex
its row input onto the fourth column as the circuit's output, as
selected by the two inputs on the first two columns.

Note that while this is a high level physical design (there is a direct
correspondence with the final layout), this also looks very much like a
truth table for the operation of this circuit. This is the main feature that
makes PPL such an efficient method for hand made designs - there are
no separate schematic/layout steps. But our interest here is in PPL as the
target for automatic synthesis tools. It fills that role nicely, due to:

     1) connection by abutment - there is little explicit routing, and
         combining placement and routing saves time and code
                                      
     2) trivial 2D - the fixed grid eliminates most degrees of freedom
         which would make compute times so impractical while retaining
         most advantages of two dimensions
   
      3) easy to mix with hand made designs - tool set doesn't have to
          be complete to be useful       

      4) output is easily inspected for verifying correctness while
          developing tools

-- Jecel
 From Yann Guidon Sat Sep 16 05:31:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00361 for ; Sat, 16 Sep 2000 10:36:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:46 +0200 (MEST) Received: (qmail 9501 invoked by uid 0); 16 Sep 2000 03:27:02 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 16 Sep 2000 03:27:02 -0000 X-eGroups-Return: sentto-1101623-735-969074813-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 16 Sep 2000 03:26:55 -0000 Received: (qmail 24868 invoked from network); 16 Sep 2000 03:26:52 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 16 Sep 2000 03:26:52 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 16 Sep 2000 03:26:52 -0000 Received: from f-cpu.org (nas4-184.aub.club-internet.fr [195.36.145.184]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA08738 for ; Sat, 16 Sep 2000 05:26:49 +0200 (MET DST) Message-ID: <39C2E989.B0765DC5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8EA50D4C31B43D7D8025695C00074F14.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 05:31:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7658e627fb9cb0a21fbb215c12d5adbf Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jeff Davies/CDPTEST wrote:
> modified lines start with **
>
> We have an architecture, instruction set etc. that took a long time fo= r anumber
> of people to come up with. What we could do with now is
> someone to implement it, and put it on FPGAs etc. I think a good idea<= BR> > is to take a basic LART circuit, and extend it a bit with a few FPGAs = on it
> implementing a basic FCPU in place of the StrongArm.
>
> Perhaps an interim step of suffient FPGAs for the CPU implementation > (plus necessary interconnect), some static ram and a boot ROM
> containing a very simple monitor allowing download of code from
> serial port.
>
> A simulator, gas & gcc compiler and a port of linux shortly after = on the
> software side would be nice.

linux is possible when we have enough diverse I/O devices,
otherwise it's not interesting. video is a minimum.

> (but I guess other folks are busy - like me)
>
> So here is the way forward:
>
> Hardware:-
>
> 1. CODE EXISTING DESIGN INTO VHDL
> 2. COMPILE INTO FPGA(S) & PROGRAM SOME
> 3. DESIGN MOTHERBOARD1(static ram, rom, and uart + FPGAs for CPU).
> 4. BUILD MOTHERBOARD1
> 5. Write CPU tests, run them.
> 6. DESIGN MOTHERBOARD2 (hacked version of LART)
> 7. BUILD MOTHERBOARD2
>
> Resources (Hardware/Software) required for above:
> 1. & 2.  -> something like Xilinx Foundation $300 or so fo= r version which
> handles
> VHDL including programming cable. Also a few FPGAs perhaps
> $100 total?  (which fpga?).
> ** Alternatively, library building block details are given to
> other people, who code VHDL (or draw using VGUI). VHDL is then sent to= kind
> person, and put onto FPGAs for distribution.

2nd solution is more reasonable : it's not worth putting $$$ in a stuff
that only one people can use. i can begin (in the next months) to make a template and we can work together on it.

> 3. RS Components catalogue/CD (rswww.com) to find some static RAM
> etc. pinouts. Cheap low end Schematic/PCB design program like
> Quickroute $140 or so. Can handle about 10 layers from memory.
> Autoroute is not very good, but can save some time. produces gerber fi= les.
>
> ** gEDA doesn't have good Autoroute, so only for the brave.

even wirewrapping would be enough : do you imagine we'd go at 200MHz ???

> 4. Get gerber files made into PCBs. Setup fee will be about $200 (some= thing
> like $15 per gerber layer). PCBs might cost $150 each.
> [lower in volume obviously].
> Components likely to be about $150 including FPGAs.
> Solder yourself - difficult to get anyone else to do this low volume.<= BR> > So each very basic fully populated motherboard1 (primitive) will be > $300.

prototype MB would be 2 layers, if using a FPGA. so no worries, it can be d= one at home.

> 5. Cost nothing.
>
> 6. Cost nothing. (except maybe a beer or two for JDB)
>
> 7. Again, PCB setup cost about $200. PCBs cost about $150 each again.<= BR> > Components now cost more like $600 per board. (this is a full PC like<= BR> > system, and we don't have bulk buying capability yet).
> Each fully populated motherboard2 will cost around $750.
> Solder yourself again. With time, subcontract this.
>
> ** 8. When we have built up a following and a name, the $150,000 to ge= t
> ASICs started might not be a problem?

money is not the problem if we have a good design.
companies will support us but not before we have something solid.

> ** 9. Free Product Designs:  Organiser (with hardware divx mpeg4 = decoder &
> perhaps encoder -ie dig cam?),
>  WebTV (ditto), Portable PC (with video editing) , Server Applian= ce
> (multimedia) . (Desktops are
> a bit passe).

desktop ? what else am i using ???
if you think that you can hack with a cell phone or
program a multi-cpu organizer, tell me now ;-)
or take an "openrisc1000" or an ARM instead. f-cpu is not
meant for the "low MOP/S" market but to compete with the ALPHA.
> Software:-
> ** (Not after, but in parallel with hardware).
>
> 1. Port GAS?
> 2. Port GCC
> 3. Compile Linux, and a bootloader, perhaps also openbios?
> 4. If hardware not available, write and run simulator.
>
> None of the above cost anything other than time.

gas ? nahh... ugly syntax.
all i need is an ANSI C front-end for GNL.
the GNL back-end generates asm that gets assembled in a cleaner
syntax, so it's eaiser to read and tweak.

> I was holding out for a way to do the FPGA programming on a free bit o= f
> software.

<snip interesting comments here>

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Steve Van der Hoeven Sat Sep 16 06:41:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00364 for ; Sat, 16 Sep 2000 10:36:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 10:36:48 +0200 (MEST) Received: (qmail 16473 invoked by uid 0); 16 Sep 2000 04:42:02 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 16 Sep 2000 04:42:02 -0000 X-eGroups-Return: sentto-1101623-736-969079311-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 16 Sep 2000 04:42:01 -0000 Received: (qmail 6594 invoked from network); 16 Sep 2000 04:41:50 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 16 Sep 2000 04:41:50 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 16 Sep 2000 04:41:50 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id XAA27927 for ; Fri, 15 Sep 2000 23:41:49 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39C2E989.B0765DC5@f-cpu.org> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Sep 2000 23:41:49 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b829426c1d50319fe1cb13d8aeb38060 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> > A simulator, gas & gcc compiler and a port of linux shortly after on the
> > software side would be nice.
>
> linux is possible when we have enough diverse I/O devices,
> otherwise it's not interesting. video is a minimum.
>

We could start with a simple alphanumerical lcd , and if you have an
uart...


> > perhaps encoder -ie dig cam?),
> >  WebTV (ditto), Portable PC (with video editing) , Server Appliance
> > (multimedia) . (Desktops are
> > a bit passe).
>
> desktop ? what else am i using ???
> if you think that you can hack with a cell phone or
> program a multi-cpu organizer, tell me now ;-)
> or take an "openrisc1000" or an ARM instead. f-cpu is not
> meant for the "low MOP/S" market but to compete with the ALPHA.
>

The power of an alpha in a palm size computer, yeah! I mean a disk with
memory, a video card and the eternet card + an extention connector.
Everything fiting in a small cube you can easily transport...

like a g4 cube (but better equiped)

--steve

 From graham@belegost.mit.edu Sat Sep 16 12:20:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00875 for ; Sat, 16 Sep 2000 15:56:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 15:56:53 +0200 (MEST) Received: (qmail 7384 invoked by uid 0); 16 Sep 2000 10:20:41 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 16 Sep 2000 10:20:41 -0000 X-eGroups-Return: sentto-1101623-737-969099636-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 16 Sep 2000 10:20:35 -0000 Received: (qmail 1794 invoked from network); 16 Sep 2000 10:20:34 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 16 Sep 2000 10:20:34 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 16 Sep 2000 10:20:34 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA20592 for f-cpu@egroups.com; Sat, 16 Sep 2000 06:20:34 -0400 Message-Id: <200009161020.GAA20592@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <00091521205804.00386@gandalf> from "Jecel Assumpcao Jr" at Sep 15, 2000 08:25:29 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 06:20:33 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f8c5e037665ff42c8b5cc0258697a4b2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Jecel wrote:
> That paper I gave the link to says that JBits also lets you change
> bistreams. You can reconfigure a CLB and reroute a net with it. Only
> Xilinx doesn't give you any information about it and redirects your to
> their partner's web sites (which have no mentioned of JBits).
>
>From looking at the Xilinx web-site, its fairly clear they do not
actually have a 'download jbits' available to the general public.
But looking round university sites, there are a LOT of people
developing tools with jbits. I guess you have to mail someone at
Xilinx, explain why you want it, and see if they'll give it to
you. It would be interesting if someone from a group like f-cpu
approached them 'officially' to see what their response was...
on the one hand they might be able to treat the f-cpu group as
if it was another university department, on the other they might
feel it was too open and they might lose control of jbits...

Graham

 From Jeff Davies/CDPTEST Sat Sep 16 18:12:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01561 for ; Sat, 16 Sep 2000 21:48:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 21:48:53 +0200 (MEST) Received: (qmail 12046 invoked by uid 0); 16 Sep 2000 16:16:01 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 16 Sep 2000 16:16:01 -0000 X-eGroups-Return: sentto-1101623-738-969120941-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 16 Sep 2000 16:15:50 -0000 Received: (qmail 23429 invoked from network); 16 Sep 2000 16:15:40 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Sep 2000 16:15:40 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 16 Sep 2000 16:15:40 -0000 Received: from modem-14.flonase.dialup.pol.co.uk ([62.136.95.14] helo=sargon.chrystal.gbr.xerox.com) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13aKcs-0003jy-00 for f-cpu@egroups.com; Sat, 16 Sep 2000 17:15:39 +0100 To: f-cpu@egroups.com Message-ID: <9FAE26841898B4E48025695C00586FB0.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 17:12:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6b0383237d9dd039a64c6823dbe7fab2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> > A simulator, gas & gcc compiler and a port of linux shortly after on
the
> > software side would be nice.
>
> linux is possible when we have enough diverse I/O devices,
> otherwise it's not interesting. video is a minimum.
>

We could start with a simple alphanumerical lcd , and if you have an
uart...

==jeff davies===

hmm - personally I think the first board should be uart only.
Just a very small monitor program with xmodem type sendin/reading of files.
This is to download test suite to board and run it.
With expansion slot, io card could be added later.


> > perhaps encoder -ie dig cam?),
> >  WebTV (ditto), Portable PC (with video editing) , Server Appliance
> > (multimedia) . (Desktops are
> > a bit passe).
>
> desktop ? what else am i using ???
> if you think that you can hack with a cell phone or
> program a multi-cpu organizer, tell me now ;-)
> or take an "openrisc1000" or an ARM instead. f-cpu is not
> meant for the "low MOP/S" market but to compete with the ALPHA.
>

The power of an alpha in a palm size computer, yeah! I mean a disk with
memory, a video card and the eternet card + an extention connector.
Everything fiting in a small cube you can easily transport...

like a g4 cube (but better equiped)

==jeff davies===
I think this should be motherboard 2, and based on the LART (Linux Advanced
radio Terminal)
which is a free design based on the strongarm. It has flash, SDRAM,
Ethernet, USB (I think) etc etc.
The strongarm they use has video built in to chip. So we can either make a
very simple frame buffer
by FPGA (for TV/SVGA) which is the hero way, or we can put an off the shelf
chip like S38?? in it.




--steve
 From Jeff Davies/CDPTEST Sat Sep 16 18:26:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01564 for ; Sat, 16 Sep 2000 21:48:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 21:48:54 +0200 (MEST) Received: (qmail 6597 invoked by uid 0); 16 Sep 2000 16:29:14 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 16 Sep 2000 16:29:14 -0000 X-eGroups-Return: sentto-1101623-739-969121751-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 16 Sep 2000 16:29:11 -0000 Received: (qmail 2085 invoked from network); 16 Sep 2000 16:29:10 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 16 Sep 2000 16:29:10 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta3 with SMTP; 16 Sep 2000 16:29:10 -0000 Received: from modem-38.angrod.dialup.pol.co.uk ([62.136.114.38] helo=sargon.chrystal.gbr.xerox.com) by cmailg5.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13aKpv-0003fV-00 for f-cpu@egroups.com; Sat, 16 Sep 2000 17:29:08 +0100 To: f-cpu@egroups.com Message-ID: <6F36EFF636F116178025695C00591264.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 17:26:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5675d0082d06b345e210255ac3d1e1b Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


Whygee wrote:

hi !

>
> A simulator, gas & gcc compiler and a port of linux shortly after on the
> software side would be nice.

linux is possible when we have enough diverse I/O devices,
otherwise it's not interesting. video is a minimum.

====Jeff Davies====
well for embedded appliances like servers, you don't need video, and what's
more,
it wouldn;t take much to get linux kernel talking over the serial port, and
therefore
bash also.


> ** Alternatively, library building block details are given to
> other people, who code VHDL (or draw using VGUI). VHDL is then sent to
kind
> person, and put onto FPGAs for distribution.

2nd solution is more reasonable : it's not worth putting $$$ in a stuff
that only one people can use. i can begin (in the next months) to make a
template and we can work together on it.

====I agree====


> 3. RS Components catalogue/CD (rswww.com) to find some static RAM
> etc. pinouts. Cheap low end Schematic/PCB design program like
> Quickroute $140 or so. Can handle about 10 layers from memory.
> Autoroute is not very good, but can save some time. produces gerber
files.
>
> ** gEDA doesn't have good Autoroute, so only for the brave.

even wirewrapping would be enough : do you imagine we'd go at 200MHz ???

=== much better to use a proper pcb - you never know if the bug is caused
by a loose wire with
wirewrap. Not 200MHz, but difficult routing say 24 address lines and 64
data lines on 2 layer.
Even 286s had 8 layer pcbs ===


> So each very basic fully populated motherboard1 (primitive) will be
> $300.

prototype MB would be 2 layers, if using a FPGA. so no worries, it can be
done at home.

==== well I'll wait and see if 2 layers will do, but why limit yourself,
when it is so easy and
not very expensive to get the job done by a pcb house. (and it will look
very nice).
If there is a bug in the board, it is still quite easy to add wire-adds to
it, break tracks where
required etc, and you still have a better quality unit.


> ** 8. When we have built up a following and a name, the $150,000 to get
> ASICs started might not be a problem?

money is not the problem if we have a good design.
companies will support us but not before we have something solid.

=== hope this is true, but in the meantime, I'd like something more solid
than virtual.


> ** 9. Free Product Designs:  Organiser (with hardware divx mpeg4 decoder
&
> perhaps encoder -ie dig cam?),
>  WebTV (ditto), Portable PC (with video editing) , Server Appliance
> (multimedia) . (Desktops are
> a bit passe).

desktop ? what else am i using ???
if you think that you can hack with a cell phone or
program a multi-cpu organizer, tell me now ;-)

== I was hoping for a Diamond Rio sized device with iGlasses or glasstrons.

or take an "openrisc1000" or an ARM instead. f-cpu is not
meant for the "low MOP/S" market but to compete with the ALPHA.

== Pretty soon 64 bits will be commonplace


gas ? nahh... ugly syntax.
all i need is an ANSI C front-end for GNL.
the GNL back-end generates asm that gets assembled in a cleaner
syntax, so it's eaiser to read and tweak.

== are you going to write everything from scratch including operating
system?
== or compile linux kernel with ANSI-C front end to GNL?

WHYGEE

==jeff davies
 From Nicolas Boulay Sat Sep 16 22:30:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01947 for ; Sat, 16 Sep 2000 23:46:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Sep 2000 23:46:47 +0200 (MEST) Received: (qmail 26689 invoked by uid 0); 16 Sep 2000 20:28:41 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 16 Sep 2000 20:28:41 -0000 X-eGroups-Return: sentto-1101623-740-969136117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 16 Sep 2000 20:28:40 -0000 Received: (qmail 2935 invoked from network); 16 Sep 2000 20:28:36 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 16 Sep 2000 20:28:36 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 16 Sep 2000 20:28:36 -0000 Received: from 195.36.162.133 [195.36.162.133] by lh00.opsion.fr; Sat, 16 Sep 2000 20:26:03 GMT Message-ID: <39C3D858.D7D3D434@ifrance.com> X-Mailer: Mozilla 4.05 [fr] (Win95; I) To: f-cpu@egroups.com References: <18D1EF5B0BC3FDF68025695B00531BC5.005345218025695B@chrystal.gbr.xerox.com> <00091517312502.00386@gandalf> <39C29CA5.8DFE168E@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 22:30:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 49ef9a7103490dd0998b87dccc3f8936 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Hello !



Yann Guidon a =E9crit:
>
> hello !
>
> Jecel Assumpcao Jr wrote:
> > I don't think breaking FC0 up into smaller pieces will be as simp= le. In
> > fact, I think that one of the major problems with the iAPX 432 pr= oduct
> > was that Intel was forced to split it into 2 chips.
>
> the fc0 has been designed to be monolithic. otherwise you'd need 1000'= s of
> pins and they'd draw half of the total power. But for the start, we ca= n test
> small parts of the whole design, or make a scaled-down attempt if it d= oesn't
> fit in one chip. "better scaled down than split" ;-)
>

In fact, we don't really need to put it in a fpga. Simulation of the rtl code is far enought. But fpag is a simple way to play with it and as "= a
proof of concept". 

> > There is an interesting tool that I have read the manual but have= n't
> > finished downloading yet:
> >
> >    http://www.ics.ele.tue.nl/~ad/idass.html
>
> i've contacted the maintainers some time ago : they don't release it > under GPL for a certain number of reasons. plus they are bound to a ce= rtain
> flavour of smalltalk that is free only under Windows. that's why i hav= en't
> tried it yet , even though i have all the files at home. like you said= , i don't
> want people to be charged if they want to develop under another OS. > this is an important side of the F in "f-cpu".
>
> > This is meant for the higher level design phases of the project a= nd can
> > output VHDL and Verilog so that other tools can be used for actua= lly
> > programming the FPGAs (or doing the chip layout in the future). I= t is
> > free and runs on both Windows and Linux. It is now also open sour= ce.
>
> but not GPL.
>
> "Open Source" is not a garanty of any kind concerning freedo= m of use,
> continuity or future development. we probably can trust the idass team=
> much more than the vgui team (at least, they still update idass and ar= e
> working on v5, while vgui people don't answer mails). but still, the m= ajor
> compatibility layer must remain the HDL, documented with screenshots a= nd drawings.
>
> > Going towards the other extreme: there is an interesting design m= ethod
> > similar to Chuck Moore's tiling Okad system that was developed du= ring
> > the 1980s at the University of Utah. It is called PPL (path
> > programmable logic) and it combines the behavioral and layout lev= els
> > into a single notation. I mentioned this when the fcpu-tools was = first
> > created, but the reaction was surprisingly negative - their idea = was
> > that anything not supported by commercial tools should be ignored= since
> > no foundry would accept our designs otherwise.
>
> Chuck has had problems when they switched to a new silicon technology = :
> his design was stuck to a certain number of layers of metal.
> Even though the F21 is an incredible stuff, it is not scalable
> and this is the major problem that i can reproach. this is a very
> important lesson and the f-cpu is the complete opposite : scalability<= BR> > to a paranoiac extent, broad range of target technologies, long life s= pan
> (not a throw-away instruction set, at least at the user level).
>
> > I did buy some tools for PPL from a small outfit called "Bon= niville
> > Electronics" (or something similar) but they weren't very ni= ce - mostly
> > a patched version of Emacs. It would be simple to build better to= ols
> > and I intend to do just that. If there is any interest, I could p= ost an
> > explanation of how this works.
>
> if you can help us have a good GPL HDL toolsuite, please go ahead !!!<= BR> > this lack of suitable tool is killing the project. it is probably the<= BR> > number 1 priority in the next week.
>
> > -- Jecel
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Moi qui pensait que dans le libre y avait pas trop de cyber-neun= eus."
>  F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con= )

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Yann Guidon Sun Sep 17 00:31:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00311 for ; Sun, 17 Sep 2000 09:39:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 09:39:51 +0200 (MEST) Received: (qmail 27213 invoked by uid 0); 16 Sep 2000 22:27:00 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 16 Sep 2000 22:27:00 -0000 X-eGroups-Return: sentto-1101623-741-969143216-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 16 Sep 2000 22:26:59 -0000 Received: (qmail 24159 invoked from network); 16 Sep 2000 22:26:56 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 16 Sep 2000 22:26:56 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 16 Sep 2000 22:26:55 -0000 Received: from f-cpu.org (nas2-199.ras.club-internet.fr [195.36.192.199]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA21345 for ; Sun, 17 Sep 2000 00:26:52 +0200 (MET DST) Message-ID: <39C3F4B9.B83B0A41@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <9FAE26841898B4E48025695C00586FB0.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 00:31:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 20a13b07811fb15fd2b35e9063a4e0dc Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jeff Davies/CDPTEST wrote:
> > linux is possible when we have enough diverse I/O devices,
> > otherwise it's not interesting. video is a minimum.
> We could start with a simple alphanumerical lcd , and if you have an u= art...
> =3D=3Djeff davies=3D=3D=3D
> hmm - personally I think the first board should be uart only.
> Just a very small monitor program with xmodem type sendin/reading of f= iles.
> This is to download test suite to board and run it.
> With expansion slot, io card could be added later.

how will you debug the UART or transfert software ?

the experimentation board consisting of only SRAM, CPU (FPGA ?) and
// printer port is enough to have fun, we'll plug stuff later.

but let's FIRST have the cpu, alright ? ;-)

> > desktop ? what else am i using ???
> > if you think that you can hack with a cell phone or
> > program a multi-cpu organizer, tell me now ;-)
> > or take an "openrisc1000" or an ARM instead. f-cpu is n= ot
> > meant for the "low MOP/S" market but to compete with th= e ALPHA.
> The power of an alpha in a palm size computer, yeah! I mean a disk wit= h
> memory, a video card and the eternet card + an extention connector. > Everything fiting in a small cube you can easily transport...
>
> like a g4 cube (but better equiped)

what i meant is that "embedded/wearable" applications are charact= erized
by a +-50MIPS requirement. it's often 8-bit, 16- or 32-bit software.
DECT (cell phone) uses around 20 to 30 MOPS and 16 bits.
the f-cpu is a 64-bit ++ stuff, it is meant to sustain around 1GOPS easily<= BR> (imagine a 128-bit version running SIMD code at around 500MHz,
it's in the range of the technologies used by Transmeta for example).
ok, remember that the power consumption is "a bit" higher too...<= BR> but you get the picture.

> =3D=3Djeff davies=3D=3D=3D
> I think this should be motherboard 2, and based on the LART (Linux Adv= anced
> radio Terminal) which is a free design based on the strongarm. It has = flash,
> SDRAM, Ethernet, USB (I think) etc etc. The strongarm they use has vid= eo built
> in to chip. So we can either make a very simple frame buffer by FPGA (= for TV/SVGA)
> which is the hero way, or we can put an off the shelf chip like S38?? = in it.

i let you prepare your own board as you wish, because it's not crucial for = the
CPU. we will maybe have several different boards, corresponding to differen= t
needs, and it's ok as long as we respect the freedom to let everybody make<= BR> his own stuff :-)


> > A simulator, gas & gcc compiler and a port of linux shortly a= fter on the
> > software side would be nice.
> linux is possible when we have enough diverse I/O devices,
> otherwise it's not interesting. video is a minimum.
> =3D=3D=3D=3DJeff Davies=3D=3D=3D=3D
> well for embedded appliances like servers, you don't need video, and w= hat's more,
> it wouldn;t take much to get linux kernel talking over the serial port= , and
> therefore bash also.

dunno. For me, linux is fine for a "linuxette", bash, X11 and 9wm= are a minimum ;-)
linux without interactive access is not worth, but it's depending on anyone= 's needs.
and we're not bound to linux, anyone can make his own kernel.


> > ** Alternatively, library building block details are given to
> > other people, who code VHDL (or draw using VGUI). VHDL is then se= nt to kind
> > person, and put onto FPGAs for distribution.
> 2nd solution is more reasonable : it's not worth putting $$$ in a stuf= f
> that only one people can use. i can begin (in the next months) to make= a
> template and we can work together on it.
>
> =3D=3D=3D=3DI agree=3D=3D=3D=3D

i've started the work on the Icache.
i have a problem with the LRU mechanism though :-D
the algo i use ("true LRU") leaves the weird possibility to
have several lines written with the same address ...
reading is straight-forward but the replacement mechanism is
too simplistic. I need help ! can anybody post a survey about LRU
implementations ?

btw, the Icache i do is 1 set, "1-way associative", so only the L= RU
side is interesting. sets and associativity will come later...

> > ** gEDA doesn't have good Autoroute, so only for the brave.
> even wirewrapping would be enough : do you imagine we'd go at 200MHz ?= ??
> =3D=3D=3D much better to use a proper pcb - you never know if the bug = is caused
> by a loose wire with wirewrap. Not 200MHz, but difficult routing say 2= 4
> address lines and 64 data lines on 2 layer. Even 286s had 8 layer pcbs= =3D=3D=3D

don't worry, i don't need autoroute for some parallel lines.
of course a PCB is better than wirewrapping, but we won't need
something expensive from the start.

> > So each very basic fully populated motherboard1 (primitive) will = be
> > $300.
> prototype MB would be 2 layers, if using a FPGA. so no worries, it can= be
> done at home.
>
> =3D=3D=3D=3D well I'll wait and see if 2 layers will do, but why limit= yourself,
> when it is so easy and not very expensive to get the job done by a pcb= house.
> (and it will look very nice). If there is a bug in the board, it is st= ill quite
> easy to add wire-adds to it, break tracks where required etc, and you = still have
> a better quality unit.

to be frank, if you want to pay a pcb house, go ahead, i stick to my pre-dr= illed
PCBs and i'll spend money only once it works :-) it's ok for 10-20MHz
stuffs but it's well enough for a start.

my own protos use pre-drilled epoxy (or bakelite, depending)
with copper pads around the hole. This way, we can solder IC sockets
and connect them together with normal soldered wires (not wire wrapping). it's more solid and as easy (if not more) than wirewrapping. plus,
it's cheaper because the sockets need not to be special ;-)

> > ** 8. When we have built up a following and a name, the $150,000 = to get
> > ASICs started might not be a problem?
> money is not the problem if we have a good design.
> companies will support us but not before we have something solid.
> =3D=3D=3D hope this is true, but in the meantime, I'd like something m= ore solid
> than virtual.

yup :-)

so i started with LRU in the icache and i need a survey.

i may have found an idea and need independent (candid) confirmation.

> > ** 9. Free Product Designs:  Organiser (with hardware divx m= peg4 decoder &
> > perhaps encoder -ie dig cam?),
> >  WebTV (ditto), Portable PC (with video editing) , Server Ap= pliance
> > (multimedia) . (Desktops are a bit passe).
> =3D=3D I was hoping for a Diamond Rio sized device with iGlasses or gl= asstrons.

you're really, reaaaally optimistic :-)
but what would be the use ?
i need a terminal (kbd+crt/lcd) with highres and highcolor
display, some gigabytes of magnetic storage, hundreds of megabytes of
hihg-speed memory and extension capabilities. I hope this will fit one
day inside a walkman case, but i doubt it'll come before ten or twenty year= s.
i don't need a toy ;-)

> or take an "openrisc1000" or an ARM instead. f-cpu is not > meant for the "low MOP/S" market but to compete with the ALP= HA.
>
> =3D=3D Pretty soon 64 bits will be commonplace

but not immediately for the embedded market. 64 bits consumes far too much<= BR> to be powered with tiny batteries.

> gas ? nahh... ugly syntax.
> all i need is an ANSI C front-end for GNL.
> the GNL back-end generates asm that gets assembled in a cleaner
> syntax, so it's eaiser to read and tweak.
>
> =3D=3D are you going to write everything from scratch including operat= ing system?
> =3D=3D or compile linux kernel with ANSI-C front end to GNL?

workflow : translate Linux kernel source in C to GNL graphs,
optimize the graphs, export to asm and finally assemble.
i'm not a kernel guru.

> --steve
> =3D=3Djeff davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 17 00:31:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00314 for ; Sun, 17 Sep 2000 09:39:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 09:39:53 +0200 (MEST) Received: (qmail 4349 invoked by uid 0); 16 Sep 2000 22:27:03 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 16 Sep 2000 22:27:03 -0000 X-eGroups-Return: sentto-1101623-742-969143217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 16 Sep 2000 22:26:58 -0000 Received: (qmail 20497 invoked from network); 16 Sep 2000 22:26:57 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 16 Sep 2000 22:26:57 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 16 Sep 2000 22:26:56 -0000 Received: from f-cpu.org (nas2-199.ras.club-internet.fr [195.36.192.199]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA18269 for ; Sun, 17 Sep 2000 00:26:52 +0200 (MET DST) Message-ID: <39C3F4BC.923677CE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200009161020.GAA20592@belegost.mit.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 00:31:24 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7a3afa071fdf941bd2e456ac7bac9476 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

graham@belegost.mit.edu wrote:
> Jecel wrote:
> > That paper I gave the link to says that JBits also lets you chang= e
> > bistreams. You can reconfigure a CLB and reroute a net with it. O= nly
> > Xilinx doesn't give you any information about it and redirects yo= ur to
> > their partner's web sites (which have no mentioned of JBits).
> From looking at the Xilinx web-site, its fairly clear they do not
> actually have a 'download jbits' available to the general public.
> But looking round university sites, there are a LOT of people
> developing tools with jbits. I guess you have to mail someone at
> Xilinx, explain why you want it, and see if they'll give it to
> you. It would be interesting if someone from a group like f-cpu
> approached them 'officially' to see what their response was...
> on the one hand they might be able to treat the f-cpu group as
> if it was another university department, on the other they might
> feel it was too open and they might lose control of jbits...

i don't know if and how we'll use this tool but approaching xilinx
is not a bad idea. but if you want to access jbits, why not ask the
people who use it outside of xilinx ? :-)
btw, one year ago IIRC there was someone from xilinx on the list.

As for the "official" side, it would be probably better if we
already had an official organization, like a club, the french
association or the german Verein. This way they wouldn't be too afraid.

> Graham
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Jeff Davies/CDPTEST Sun Sep 17 01:24:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00323 for ; Sun, 17 Sep 2000 09:39:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 09:39:56 +0200 (MEST) Received: (qmail 13719 invoked by uid 0); 16 Sep 2000 23:27:42 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 16 Sep 2000 23:27:42 -0000 X-eGroups-Return: sentto-1101623-743-969146858-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 16 Sep 2000 23:27:41 -0000 Received: (qmail 12190 invoked from network); 16 Sep 2000 23:27:37 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 16 Sep 2000 23:27:37 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 16 Sep 2000 23:27:37 -0000 Received: from modem-58.dextromethorphn.dialup.pol.co.uk ([62.136.90.186] helo=sargon.chrystal.gbr.xerox.com) by mail6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13aRMs-0003Mb-00 for f-cpu@egroups.com; Sun, 17 Sep 2000 00:27:35 +0100 To: f-cpu@egroups.com Message-ID: <4AC5B06B066E0C948025695C007DC570.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 00:24:29 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b1fd82585ad22b70fc3e4524ec583d77 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> hmm - personally I think the first board should be uart only.
> Just a very small monitor program with xmodem type sendin/reading of
files.
> This is to download test suite to board and run it.
> With expansion slot, io card could be added later.

how will you debug the UART or transfert software ?

==jeff davies====
Of course -> I'd use an EPROM programmer and eraser as usual (duly added to
plan).

what i meant is that "embedded/wearable" applications are characterized
by a +-50MIPS requirement. it's often 8-bit, 16- or 32-bit software.
DECT (cell phone) uses around 20 to 30 MOPS and 16 bits.
the f-cpu is a 64-bit ++ stuff, it is meant to sustain around 1GOPS easily
(imagine a 128-bit version running SIMD code at around 500MHz,
it's in the range of the technologies used by Transmeta for example).
ok, remember that the power consumption is "a bit" higher too...
but you get the picture.

===jeff davies====
The main thing it is characterised by is the battery size. Even the
excellent Sony NPF950
batteries wouldn't run a PIII for more than about a minute (perhaps a
slight exaggeration but
many of these cpus are 75 watt at 1.8 volt, which is beaucoup amps, around
40!!!).
However, typically risc type designs use a fraction of the power of intel
family.
Moving from 486 to PowerPC, for example would have given me more
performance for 20% of the power.
However, AMD are now doing fancy things. nokia 9110i communicator has an
AMD 486 in it, and the battery
still lasts for a week (and now it's the same size as a regular phone).

i let you prepare your own board as you wish, because it's not crucial for
the
CPU. we will maybe have several different boards, corresponding to
different
needs, and it's ok as long as we respect the freedom to let everybody make
his own stuff :-)

===== hmm I was trying to get consensus & suggest the easiest way,
so I could be lazy and say "ok whygee, here's my 150 euros, I'll
have a board too", like I suppose a few people on the list will say.


> it wouldn;t take much to get linux kernel talking over the serial port,
and
> therefore bash also.

dunno. For me, linux is fine for a "linuxette", bash, X11 and 9wm are a
minimum ;-)
linux without interactive access is not worth, but it's depending on
anyone's needs.
and we're not bound to linux, anyone can make his own kernel.

=== I wasn't suggesting using Linux on the very early pcb with only a uart,
this would just
have a monitor, but it could be expanded by a daughter board for a bank of
bigger ram, flash,
ide network etc etc. The monitor and uart would only be to run cpu tests.
(memory bits setting, math
ops, logical ops on blocks of ram). Run the thing for some tens of hours,
perhaps do speed tests, seeing what
the breaking point is, that sort of stuff.


btw, the Icache i do is 1 set, "1-way associative", so only the LRU
side is interesting. sets and associativity will come later...

=== functions of this level of complexity will be in the fc0??


my own protos use pre-drilled epoxy (or bakelite, depending)
with copper pads around the hole. This way, we can solder IC sockets
and connect them together with normal soldered wires (not wire wrapping).
it's more solid and as easy (if not more) than wirewrapping. plus,
it's cheaper because the sockets need not to be special ;-)

=== have you started implementing fc0 then?


> == I was hoping for a Diamond Rio sized device with iGlasses or
glasstrons.

you're really, reaaaally optimistic :-)
but what would be the use ?
i need a terminal (kbd+crt/lcd) with highres and highcolor
display,

=== Sony Glasstron appears as something like a virtual 17 metre screen. (so
I read)
=== I think overall resolution is around 360,000 pixels, which isnt too
great compared with 800x600.
=== but not bad for around 600 euros.

some gigabytes of magnetic storage, hundreds of megabytes of
=== I just bought a 12 gig drive for my laptop (cost about 200 euros) and
is lighter than a packet of
cigarettes. (I thought the box was empty).

hihg-speed memory and extension capabilities. I hope this will fit one
day inside a walkman case, but i doubt it'll come before ten or twenty
years.
i don't need a toy ;-)

> == Pretty soon 64 bits will be commonplace

but not immediately for the embedded market. 64 bits consumes far too much
to be powered with tiny batteries.

=== as most processes are cmos these days, you could have a "speed wheel"
like a volume control
that controls a PLL, and therefore processor clock speed, and power
consumption.


workflow : translate Linux kernel source in C to GNL graphs,
optimize the graphs, export to asm and finally assemble.
i'm not a kernel guru.
=== this sounds pretty interesting...


> --steve
> ==jeff davies
WHYGEE

=== Jeff Davies
 From Yann Guidon Sun Sep 17 02:47:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00329 for ; Sun, 17 Sep 2000 09:39:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 09:39:58 +0200 (MEST) Received: (qmail 18574 invoked by uid 0); 17 Sep 2000 00:44:17 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 17 Sep 2000 00:44:17 -0000 X-eGroups-Return: sentto-1101623-744-969151407-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 17 Sep 2000 00:43:33 -0000 Received: (qmail 18389 invoked from network); 17 Sep 2000 00:43:27 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 17 Sep 2000 00:43:27 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 17 Sep 2000 00:43:26 -0000 Received: from f-cpu.org (nas1-234.aub.club-internet.fr [195.36.150.234]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA11711 for ; Sun, 17 Sep 2000 02:43:23 +0200 (MET DST) Message-ID: <39C414B0.C454782A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <4AC5B06B066E0C948025695C007DC570.0000000000000000@chrystal.gbr.xerox.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 02:47:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Slightly modified implementation plan in light of comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6634aabc84ea3cb69631314f384037f1 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi again,

Jeff Davies/CDPTEST wrote:
> how will you debug the UART or transfert software ?
> =3D=3Djeff davies=3D=3D=3D=3D
> Of course -> I'd use an EPROM programmer and eraser as usual (duly = added to plan).
that will be difficult and slow, but if that's how you have fun...

my plan is :


PC <----//port-----> CPU <---> SRAM

the software gets uploaded and debugged through a special port of the CPU I= C.
something similar in function to the JTAG stuffs but in parallel, so it's f= aster
and simpler. we can have enough stuff to start developping some basic softw= are,
test the performance curve and extend the board when necessary. it requires=
a minimal number of ICs, it is therefore fast to build and the debugging is eased by the debug port.

> i let you prepare your own board as you wish, because it's not crucial= for the
> CPU. we will maybe have several different boards, corresponding to dif= ferent
> needs, and it's ok as long as we respect the freedom to let everybody = make
> his own stuff :-)
>
> =3D=3D=3D=3D=3D hmm I was trying to get consensus & suggest the ea= siest way,
> so I could be lazy and say "ok whygee, here's my 150 euros, I'll<= BR> > have a board too", like I suppose a few people on the list will s= ay.

;-) let's have the cpu fitted in a FPGA first, ok ? :-P

> btw, the Icache i do is 1 set, "1-way associative", so only = the LRU
> side is interesting. sets and associativity will come later...
> =3D=3D=3D functions of this level of complexity will be in the fc0??
well, only "mastering the complexity" matters. We'll extend the n= umber
of cache lines later. i suppose that we'll have only 8 cache lines
in the VHDL debugging version :-) that already makes 256 bytes, wow :-P
i think that i have an idea for a true LRU cache but i'll have to sleep. i'll say more next week. this first VHDL will show if we can develop
HDL in a virtual community.

> my own protos use pre-drilled epoxy (or bakelite, depending)
> with copper pads around the hole. This way, we can solder IC sockets > and connect them together with normal soldered wires (not wire wrappin= g).
> it's more solid and as easy (if not more) than wirewrapping. plus,
> it's cheaper because the sockets need not to be special ;-)
>
> =3D=3D=3D have you started implementing fc0 then?

no, but maybe i was unclear too :
this is the way i want to make my own first F-CPU board.
this is also how i make protos, usually. there is no routing needed :-)

>  some gigabytes of magnetic storage, hundreds of megabytes of
> =3D=3D=3D I just bought a 12 gig drive for my laptop (cost about 200 e= uros) and
> is lighter than a packet of cigarettes. (I thought the box was empty).=
what about the access time and the bandwidth ?

> > =3D=3D Pretty soon 64 bits will be commonplace
> but not immediately for the embedded market. 64 bits consumes far too = much
> to be powered with tiny batteries.
> =3D=3D=3D as most processes are cmos these days, you could have a &quo= t;speed wheel"
> like a volume control that controls a PLL, and therefore processor clo= ck
> speed, and power consumption.
yup it's common today. but no embedded application requires 64-bit CPUs. 64-bits are usually necessary when you want to access more than 4GB,
and no embedded toy needs that much.

OTOH, SIMD (64-bit or more) software can be used to reduce the power
consumption overhead caused by the control logic.

> workflow : translate Linux kernel source in C to GNL graphs,
> optimize the graphs, export to asm and finally assemble.
> i'm not a kernel guru.
> =3D=3D=3D this sounds pretty interesting...
that's why i want to spend the coming year on the GNL project :-D

later,
> > --steve
> > =3D=3Djeff davies
> WHYGEE
> =3D=3D=3D Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From "yulonda75358@freemail.c3.hu" Sun Sep 17 02:41:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00332 for ; Sun, 17 Sep 2000 09:39:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 09:39:59 +0200 (MEST) Received: (qmail 18744 invoked by uid 0); 17 Sep 2000 01:03:28 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 17 Sep 2000 01:03:28 -0000 X-eGroups-Return: sentto-1101623-745-969152604-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 17 Sep 2000 01:03:26 -0000 Received: (qmail 9466 invoked from network); 17 Sep 2000 01:01:42 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 17 Sep 2000 01:01:42 -0000 Received: from unknown (HELO mail.netguide.dk) (63.25.242.215) by mta2 with SMTP; 17 Sep 2000 01:01:41 -0000 Message-ID: <30537.44202@mail.netguide.dk> From: "yulonda75358@freemail.c3.hu" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Sep 2000 20:41:35 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] (3531) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: bd0e1847ee4a7fb0da5c57f75646fa03 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

A business where people are making $1,000-$5,000 per week, and very little work is involved!!!

Call 1-800-277-5212 24 Hours to find out more!

A business with no selling, all CASH, and not MLM!!!
You will be only 1 of a few people in each area with one of the
HOTTEST products!!!

Call 1-800-277-5212 24 Hours to find out more!!!

Imagine, being business for yourself, but NOT by yourself!!!
Unlimited company support FOREVER!!! Make the FREE call, what have you got to lose?


Remove   lynn2849@sowhatsamattau.uk

***********************************************************************************************
74600
 From Jamil Khatib Sun Sep 17 12:30:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01483 for ; Sun, 17 Sep 2000 19:48:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 19:48:58 +0200 (MEST) Received: (qmail 27037 invoked by uid 0); 17 Sep 2000 13:14:55 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 17 Sep 2000 13:14:55 -0000 X-eGroups-Return: sentto-1101623-746-969196214-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 17 Sep 2000 13:11:03 -0000 Received: (qmail 11407 invoked from network); 17 Sep 2000 10:30:09 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Sep 2000 10:30:09 -0000 Received: from unknown (HELO web1105.mail.yahoo.com) (128.11.23.125) by mta2 with SMTP; 17 Sep 2000 10:30:09 -0000 Message-ID: <20000917103009.28286.qmail@web1105.mail.yahoo.com> Received: from [199.203.98.250] by web1105.mail.yahoo.com; Sun, 17 Sep 2000 03:30:09 PDT To: f-cpu@egroups.com From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 03:30:09 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 53fab263b352913e3fc8383c9592795d Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


> >  
> http://www.io.com/~guccione/Papers/JBits/JBits.html
>
> And jroute complements it nicely,
>
http://www.crosswinds.net/~ekeller/publications/index.html
> (also see
> http://www.ens-lyon.fr/~fdedinec/recherche/jbits/).
>
visit also

http://www.geocities.com/SiliconValley/Pines/6639/fpga/jbits.html

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
 From Jamil Khatib Sun Sep 17 12:53:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01489 for ; Sun, 17 Sep 2000 19:48:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 19:48:59 +0200 (MEST) Received: (qmail 28929 invoked by uid 0); 17 Sep 2000 13:51:05 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 17 Sep 2000 13:51:05 -0000 X-eGroups-Return: sentto-1101623-747-969198600-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 17 Sep 2000 13:50:11 -0000 Received: (qmail 19016 invoked from network); 17 Sep 2000 10:53:11 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 17 Sep 2000 10:53:11 -0000 Received: from unknown (HELO web1102.mail.yahoo.com) (128.11.23.122) by mta1 with SMTP; 17 Sep 2000 10:53:11 -0000 Received: (qmail 19903 invoked by uid 60001); 17 Sep 2000 10:53:11 -0000 Message-ID: <20000917105311.19902.qmail@web1102.mail.yahoo.com> Received: from [199.203.98.250] by web1102.mail.yahoo.com; Sun, 17 Sep 2000 03:53:11 PDT To: f-cpu@egroups.com From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 03:53:11 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 537210789bdd5f07c3f0f351ea659c84 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> From looking at the Xilinx web-site, its fairly
> clear they do not
> actually have a 'download jbits' available to the
> general public.
> But looking round university sites, there are a LOT
> of people
> developing tools with jbits. I guess you have to
> mail someone at
> Xilinx, explain why you want it, and see if they'll
> give it to
> you. It would be interesting if someone from a group
> like f-cpu
> approached them 'officially' to see what their
> response was...
> on the one hand they might be able to treat the
> f-cpu group as
> if it was another university department, on the
> other they might
> feel it was too open and they might lose control of
> jbits...
>
> Graham


Yes the JBits is not free. If you want I can do some
work using JBits for the F-CPU project.

The main problem with this tool is that you have to
define the logic in each CLB and routing.

Small building blocks can be used to implement large
blocks but still it needs lot of work

I'l be happy if I can help you

Regards
Jamil Khatib
>
>
>
>


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
 From pelgrims p Sun Sep 17 16:42:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01495 for ; Sun, 17 Sep 2000 19:49:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 19:49:01 +0200 (MEST) Received: (qmail 20547 invoked by uid 0); 17 Sep 2000 14:43:42 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 17 Sep 2000 14:43:42 -0000 X-eGroups-Return: sentto-1101623-748-969201812-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 17 Sep 2000 14:43:41 -0000 Received: (qmail 20048 invoked from network); 17 Sep 2000 14:43:31 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 17 Sep 2000 14:43:31 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 17 Sep 2000 14:43:31 -0000 Received: (qmail 19211 invoked from network); 17 Sep 2000 14:43:28 -0000 Received: from unknown (HELO pandora.be) ([213.224.66.122]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 17 Sep 2000 14:43:28 -0000 Sender: root@pop.gmx.net Message-ID: <39C4D86E.9939A9B4@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20000917103009.28286.qmail@web1105.mail.yahoo.com> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 16:42:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ed5466044e8dce6320526ae1cd756c80 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Hello,

Is there already some VHDL code ?

Greatings,
                        P. Pelgrims

 From graham@belegost.mit.edu Sun Sep 17 17:48:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01498 for ; Sun, 17 Sep 2000 19:49:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Sep 2000 19:49:02 +0200 (MEST) Received: (qmail 6266 invoked by uid 0); 17 Sep 2000 15:48:53 -0000 Received: from hp.egroups.com (208.50.99.201) by mx11.rz2.gmx.net with SMTP; 17 Sep 2000 15:48:53 -0000 X-eGroups-Return: sentto-1101623-749-969205707-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 17 Sep 2000 15:48:33 -0000 Received: (qmail 19165 invoked from network); 17 Sep 2000 15:48:20 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 17 Sep 2000 15:48:20 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 17 Sep 2000 15:48:20 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA05652 for f-cpu@egroups.com; Sun, 17 Sep 2000 11:48:19 -0400 Message-Id: <200009171548.LAA05652@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <20000917105311.19902.qmail@web1102.mail.yahoo.com> from "Jamil Khatib" at Sep 17, 2000 03:53:11 AM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Sep 2000 11:48:19 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cd3ac57724dc314848c4fe9596000cd5 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

> Yes the JBits is not free. If you want I can do some
> work using JBits for the F-CPU project.
So how do you get hold of JBits? Is it from your work?
Or did you sign an NDA for Xilinx personally?
Or shouldn't I ask ;-)

Graham
>
From Yann Guidon Mon Sep 18 08:33:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA00344 for ; Mon, 18 Sep 2000 10:32:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Sep 2000 10:32:26 +0200 (MEST) Received: (qmail 20738 invoked by uid 0); 18 Sep 2000 06:29:52 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 18 Sep 2000 06:29:52 -0000 X-eGroups-Return: sentto-1101623-750-969258586-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 18 Sep 2000 06:29:50 -0000 Received: (qmail 17210 invoked from network); 18 Sep 2000 06:29:46 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Sep 2000 06:29:46 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 18 Sep 2000 06:29:45 -0000 Received: from f-cpu.org (nas2-232.ras.club-internet.fr [195.36.192.232]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA18563 for ; Mon, 18 Sep 2000 08:29:43 +0200 (MET DST) Message-ID: <39C5B756.4F4B4D1D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000917103009.28286.qmail@web1105.mail.yahoo.com> <39C4D86E.9939A9B4@pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 08:33:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cad tools (was: Xilinx prices) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 1aa7129f1f48404f2f02955d438d388d Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

pelgrims p wrote:
> Hello,
>
> Is there already some VHDL code ?

i'm working on the I cache now.
it's only structural code, done with VGUI,
filling the holes is rather easy.

then will come the fetcher then the decoder...

but first i need help for the LRU algorithm.

> Greatings,
>            = ;             P= . Pelgrims
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Mon Sep 18 17:16:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00823 for ; Tue, 19 Sep 2000 00:05:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 00:05:55 +0200 (MEST) Received: (qmail 26121 invoked by uid 0); 18 Sep 2000 16:04:55 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 18 Sep 2000 16:04:54 -0000 X-eGroups-Return: sentto-1101623-751-969293088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 18 Sep 2000 16:04:53 -0000 Received: (qmail 11295 invoked from network); 18 Sep 2000 16:04:46 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 18 Sep 2000 16:04:46 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.99) by mta1 with SMTP; 18 Sep 2000 16:04:45 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00959; Mon, 18 Sep 2000 17:16:12 +0200 Message-ID: <20000918171612.46073@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000917103009.28286.qmail@web1105.mail.yahoo.com> <39C4D86E.9939A9B4@pandora.be> <39C5B756.4F4B4D1D@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C5B756.4F4B4D1D@f-cpu.org>; from Yann Guidon on Mon, Sep 18, 2000 at 08:33:58AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 17:16:12 +0200 Reply-To: f-cpu@egroups.com Subject: pseudo LRU? (was: Re: [f-cpu] cad tools (was: Xilinx prices)) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 813ab6c8cc3799bc24bf3547d633f970 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Mon, Sep 18, 2000 at 08:33:58AM +0200, Yann Guidon wrote:

> but first i need help for the LRU algorithm.

Would a pseudo-LRU be sufficient?  There's a simple algorithm that needs
only (2^n)-1 FFs for 2^n cache lines, plus logic.  The FFs are the nodes
of a binary tree, the cache lines are the leaves.  A `0' in a FF means
`left successor', `1' means `right successor'.  To look up the (almost)
least recently used cache line, follow the path from the root FF and
toggle every FF after you passed it.  To update the tree (without looking
up the LRU first), start from the used cache line and walk towards the
root, setting each FF on your way to point to the sibling of the subtree
(or leaf) you came from.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Jecel Assumpcao Jr Mon Sep 18 20:11:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00829 for ; Tue, 19 Sep 2000 00:05:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 00:05:56 +0200 (MEST) Received: (qmail 21556 invoked by uid 0); 18 Sep 2000 18:45:45 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 18 Sep 2000 18:45:45 -0000 X-eGroups-Return: sentto-1101623-752-969302717-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 18 Sep 2000 18:45:41 -0000 Received: (qmail 31226 invoked from network); 18 Sep 2000 18:34:48 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 18 Sep 2000 18:34:48 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta2 with SMTP; 18 Sep 2000 18:34:45 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA23476 for ; Mon, 18 Sep 2000 15:43:37 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <410971B06A9D587C8025695B007C2153.0000000000000000@chrystal.gbr.xerox.com> <00091521205804.00386@gandalf> <39C2C345.D4EF7F0B@f-cpu.org> In-Reply-To: <39C2C345.D4EF7F0B@f-cpu.org> Message-Id: <00091815363600.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 15:11:25 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] jbits, asp (was: cad tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c70313d58a0bdab81f00747663db2f4f Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

Thanks Yann and Steve for your support for the "application service
provider" idea. My own preference is to call this "plan B", however. If
we can find a way where everyone can generate designs using their own
computers it would be a better option. If not, then this service would
be inconvenient, but necessary.

Thanks Marco, Graham and Jamil for the information in JBits. It would
solve my problems, except for the fact that it is not available (it is
no use to me if I can't give everyone on this list a copy). I will look
into this issue this week.

Yann Guidon wrote:
> the problem is not Idass but the smalltalk machine and the platform.

Very true, but if Idass itself is free (the license doesn't seem to
indicate that it is, but it was written before they started
distributing the sources) then somebody could port it to Squeak or
some other free Smalltalk. That could be a considerable effort and not
worth the trouble, but it is interesting to know if it is legally
possible at all.

> anyway i'll have to give it a try before refusing.

I haven't run it yet since I am missing a JuggleButtons "parcel". It
took me a while to find the "ForkedUI" one that is also required. I
could try the Windows version (it is standalone and should work "out
of the box"), but I am not too anxious to reboot this machine right
now...

> > He designed directly at the logical layout level. PPL is at a higher
> > level, but not by much. Still, it is abstract enough that you can move
> > a design from CMOS to GaAs with little, or no changes.
>
> like VHDL... or i missed a point :-)

I posted a small PPL example in another message. For a given
technology, you make a hand crafted design for each cell. You generate
the layout by placing these designs as show by the text version. So the
same text might be used to create a CMOS 0.35 micron layout or a GaAs
chip. You would have to have two versions for the "1" cell, two
versions for the "+" cell and so on.

> > My tools will be free, but they will run on Self (which though it is
> > free itself it currently only runs on Sparcs and PowerMacs). And they
> > use Self as the HDL since I don't like either Verilog or VHDL.
>
> i don't like it either but that's the only thing there is here.
> i don't like C either ;-P

I do like C and most other programming languages. I have used several
other HDLs besides Verilog and VHDL, so I don't think they are quite
the only thing here (though I am very much in favor of using standards
whenever possible!). In fact, in terms of free tools I am getting the
impression that Verilog and VHDL aren't quite here yet...

-- Jecel
 From Yann Guidon Mon Sep 18 23:54:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00844 for ; Tue, 19 Sep 2000 00:06:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 00:06:00 +0200 (MEST) Received: (qmail 2997 invoked by uid 0); 18 Sep 2000 21:50:40 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 18 Sep 2000 21:50:40 -0000 X-eGroups-Return: sentto-1101623-753-969313828-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mr.egroups.com with NNFMP; 18 Sep 2000 21:50:39 -0000 Received: (qmail 4952 invoked from network); 18 Sep 2000 21:50:28 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 18 Sep 2000 21:50:28 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 18 Sep 2000 21:50:27 -0000 Received: from f-cpu.org (nas1-145.ras.club-internet.fr [195.36.192.145]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA02971 for ; Mon, 18 Sep 2000 23:50:21 +0200 (MET DST) Message-ID: <39C68F26.C740D0C0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 23:54:46 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] I GOT IT !!! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e36dc1bd6f06cd4e2b2690bbf4419775 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

you local whygee has got his diplom : a master in
Micro-Informatique Micro-Electronique (MIME)
after two years of crazy work. So now, i have more time
for the project :-) Business is starting again !

I'm seeking people in Munich, i may go there some days
to rest a bit. My usual host is sick and I can't sleep there.
Hat jemand irgendwas um dort zum schlafen ? :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Mon Sep 18 23:54:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00847 for ; Tue, 19 Sep 2000 00:06:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 00:06:00 +0200 (MEST) Received: (qmail 10492 invoked by uid 0); 18 Sep 2000 21:50:43 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 18 Sep 2000 21:50:43 -0000 X-eGroups-Return: sentto-1101623-754-969313829-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 18 Sep 2000 21:50:40 -0000 Received: (qmail 4975 invoked from network); 18 Sep 2000 21:50:28 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 18 Sep 2000 21:50:28 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 18 Sep 2000 21:50:27 -0000 Received: from f-cpu.org (nas1-145.ras.club-internet.fr [195.36.192.145]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA24910 for ; Mon, 18 Sep 2000 23:50:21 +0200 (MET DST) Message-ID: <39C68F27.79855959@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000917103009.28286.qmail@web1105.mail.yahoo.com> <39C4D86E.9939A9B4@pandora.be> <39C5B756.4F4B4D1D@f-cpu.org> <20000918171612.46073@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 23:54:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: pseudo LRU? (was: Re: [f-cpu] cad tools (was: Xilinx prices)) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: aea7bf089431613feb29b18b9f4db3cb Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello !

Michael Riepe wrote:
> On Mon, Sep 18, 2000 at 08:33:58AM +0200, Yann Guidon wrote:
> > but first i need help for the LRU algorithm.
> Would a pseudo-LRU be sufficient?
in principle, i dislike pseudo-LRU. my experiences with the strip mining algorithm show that what we expect from a cache is never reached
by the poor reality. but what you explain sounds interesting anyway, it's maybe worth a look. If you had a VHDL code, it would even be better ;-)

>  There's a simple algorithm that needs
> only (2^n)-1 FFs for 2^n cache lines, plus logic.  The FFs are th= e nodes
> of a binary tree, the cache lines are the leaves.  A `0' in a FF = means
> `left successor', `1' means `right successor'.  To look up the (a= lmost)
> least recently used cache line, follow the path from the root FF and > toggle every FF after you passed it.  To update the tree (without= looking
> up the LRU first), start from the used cache line and walk towards the=
> root, setting each FF on your way to point to the sibling of the subtr= ee
> (or leaf) you came from.

that's pretty interesting :-)
but i don't understand why it's "pseudo-LRU". what's the differen= ce
with "true LRU" ? unless i missed something...

thanks for the help :-)))

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Tue Sep 19 01:30:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01448 for ; Tue, 19 Sep 2000 02:29:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 02:29:27 +0200 (MEST) Received: (qmail 3980 invoked by uid 0); 18 Sep 2000 23:31:07 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 18 Sep 2000 23:31:07 -0000 X-eGroups-Return: sentto-1101623-755-969319861-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 18 Sep 2000 23:31:05 -0000 Received: (qmail 26623 invoked from network); 18 Sep 2000 23:31:00 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Sep 2000 23:31:00 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.118) by mta3 with SMTP; 18 Sep 2000 23:30:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02725; Tue, 19 Sep 2000 01:30:55 +0200 Message-ID: <20000919013055.06244@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000917103009.28286.qmail@web1105.mail.yahoo.com> <39C4D86E.9939A9B4@pandora.be> <39C5B756.4F4B4D1D@f-cpu.org> <20000918171612.46073@thrai.stud.uni-hannover.de> <39C68F27.79855959@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C68F27.79855959@f-cpu.org>; from Yann Guidon on Mon, Sep 18, 2000 at 11:54:47PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Sep 2000 01:30:55 +0200 Reply-To: f-cpu@egroups.com Subject: Re: pseudo LRU? (was: Re: [f-cpu] cad tools (was: Xilinx prices)) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 71f1d1b242ed83e9f787d5c766c3053a Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Mon, Sep 18, 2000 at 11:54:47PM +0200, Yann Guidon wrote:

> in principle, i dislike pseudo-LRU. my experiences with the strip mining
> algorithm show that what we expect from a cache is never reached
> by the poor reality. but what you explain sounds interesting anyway, it's
> maybe worth a look. If you had a VHDL code, it would even be better ;-)

Sorry, my VHDL (or Verilog) experience is near zero.

[...]
> that's pretty interesting :-)
> but i don't understand why it's "pseudo-LRU". what's the difference
> with "true LRU" ? unless i missed something...

It's more like `NRU' (not recently used), unless there are only two
cache lines.  The lookup sequence stays the same as long as the tree
isn't updated, but each time a cache line is re-used (which is, of course,
the purpose of a cache :) the order changes.

To save the entire usage history (and always grab the REALLY MOST recently
used line), you would need log2(n!) bits of additional storage for n
cache lines.  For 2 lines, a single bit is enough, 16 bits are ok for
8 cache lines, and for 16 lines you already need at least 45 bits (in
contrast to 15 bits for the pseudo-LRU version).

Real LRU implementations will probably use 2^n cache lines and additional
n bits per line that form a kind of linked list.  The least recently
used line is at one end of the list, and when a line (any line) is used,
the cache controller removes it and puts it on the other end.  This can
become quite expensive (in terms of silicon real estate, at least),
which is the reason why I suggested the simple (but less perfect) version.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Steve Van der Hoeven Tue Sep 19 01:49:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01454 for ; Tue, 19 Sep 2000 02:29:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 02:29:29 +0200 (MEST) Received: (qmail 12082 invoked by uid 0); 18 Sep 2000 23:49:28 -0000 Received: from c9.egroups.com (208.50.99.230) by mx06.rz2.gmx.net with SMTP; 18 Sep 2000 23:49:28 -0000 X-eGroups-Return: sentto-1101623-756-969320961-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 18 Sep 2000 23:49:26 -0000 Received: (qmail 1311 invoked from network); 18 Sep 2000 23:49:20 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 18 Sep 2000 23:49:20 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta2 with SMTP; 18 Sep 2000 23:49:20 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id SAA07372 for ; Mon, 18 Sep 2000 18:49:19 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <20000919013055.06244@thrai.stud.uni-hannover.de> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Sep 2000 18:49:19 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] caching technics... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 65954682271ef6c51e2bef442ef92f26 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


The discussion is interesting... But have you already discussed that it
will be the LRU caching algorithm you really want or not?

If it has not been yet discussed, we could try to think about all the
solutions we have or might imagine.

  First how big do we want the caches to be. This has an enormous
influence if it can contain the data for several heavy memory-data-movers
threads or not. For example LRU on small caches for web servers can very
ineficient, because you need to refrech too much the cache with the thread
swapping.

So we should also try to see the relation between memory caching
algorithms and the software we would like to see on the f-cpu.

Then the idea of a one bloc of adress space without the x86 segements or
something like that, had some echo on you. In that case that may allow
some less conventional caching technics to be more efficient.
-> we can have information overlaping in the cach with two different
offsets in the main memory while using the standart algorithms.

--Steve


 From Yann Guidon Tue Sep 19 09:15:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00336 for ; Tue, 19 Sep 2000 16:09:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 16:09:51 +0200 (MEST) Received: (qmail 17606 invoked by uid 0); 19 Sep 2000 07:11:05 -0000 Received: from mw.egroups.com (208.50.144.94) by mx12.rz2.gmx.net with SMTP; 19 Sep 2000 07:11:05 -0000 X-eGroups-Return: sentto-1101623-757-969347460-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 19 Sep 2000 07:11:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 19 Sep 2000 07:10:59 -0000 Received: (qmail 2468 invoked from network); 19 Sep 2000 07:10:58 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 19 Sep 2000 07:10:58 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 19 Sep 2000 07:10:58 -0000 Received: from f-cpu.org (nas3-46.ras.club-internet.fr [195.36.203.46]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA03196 for ; Tue, 19 Sep 2000 09:10:54 +0200 (MET DST) Message-ID: <39C71283.C2FC31E3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Sep 2000 09:15:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 62db178b5bad4503ccb0d9ef38e72d2c Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Steve Van der Hoeven wrote:
> The discussion is interesting... But have you already discussed that i= t
> will be the LRU caching algorithm you really want or not?

in the future, the caching technique will be left to the implementor :
there are several techniques existing, some more complex or efficient
than others and i'm sure that it will evolve in teh future.

but what we need now is something simple that "works" and gets us=
started. in the ideal case, my philosophy condones "true LRU" but= for
a first attempt (before the chip gets implemented), the tree algo
seems ok.

> If it has not been yet discussed, we could try to think about all the<= BR> > solutions we have or might imagine.

probably, but it's often more a matter of taste : this does not directly influences the CPU core and there might be patent issues, so i don't think<= BR> it's a good idea to "choose" an algorithm over another.

At contrary, this should allow us to try and play with the algorithms :
we can make several versions using different algorithms. The "external= "
interface and the specifications don't change but if we have several
working VHDL files, we can make different versions and see which works best= .


>   First how big do we want the caches to be.
this is not my problem today : 16 cache lines (32 bytes per line) is much e= nough
to get us started. then it's only a matter of copy/paste in the VHDL code and a matter of CLB or macrocells in the FPGA. My problem today is to see h= ow the
different blocks work together : the Icache works with the TLB and the Fetc= her,
etc etc... so a simple working cache will be enough for today, it will be e= nhanced
later.

> This has an enormous influence if it can contain the data
> for several heavy memory-data-movers threads or not.
we're ONLY trying to setup the overall structure, we'll size the
units later ;-)

> For example LRU on small caches for web servers can very
> ineficient, because you need to refrech too much the cache
> with the thread swapping.
i'm only doing the Icache now, the Dcache will be a scale-up of the Icache<= BR> (same number of lines and more refined LRU). But for the "cache thrash= ing problem"
i have several solutions, particularly the "flush" bit in the L/S= instructions
(just in case you feel concerned by blkmov troubles).

>  So we should also try to see the relation between memory caching=
> algorithms and the software we would like to see on the f-cpu.

that's why i encourage everyone to join hands and make his/her version
of the instruction cache. we'll have several versions and we'll choose
the best version on a case by case basis.

> Then the idea of a one bloc of adress space without the x86 segements = or
> something like that, had some echo on you. In that case that may allow=
> some less conventional caching technics to be more efficient.
> -> we can have information overlaping in the cach with two differen= t
> offsets in the main memory while using the standart algorithms.

the simpler, the best !

experiences with strip mining algos taught me to avoid side effects wheneve= r possible.
but this is only a first-attempt design and the blocks could be interchange= d.

> --Steve


Michael Riepe wrote:
> On Mon, Sep 18, 2000 at 11:54:47PM +0200, Yann Guidon wrote:
> > in principle, i dislike pseudo-LRU. my experiences with the strip= mining
> > algorithm show that what we expect from a cache is never reached<= BR> > > by the poor reality. but what you explain sounds interesting anyw= ay, it's
> > maybe worth a look. If you had a VHDL code, it would even be bett= er ;-)
> Sorry, my VHDL (or Verilog) experience is near zero.
well, it's time to play and learn ;-)

now, i'm only playing with VGUI.

> [...]
> > that's pretty interesting :-)
> > but i don't understand why it's "pseudo-LRU". what's th= e difference
> > with "true LRU" ? unless i missed something...
> It's more like `NRU' (not recently used), unless there are only two > cache lines.  The lookup sequence stays the same as long as the t= ree
> isn't updated, but each time a cache line is re-used (which is, of cou= rse,
> the purpose of a cache :) the order changes.
>
> To save the entire usage history (and always grab the REALLY MOST rece= ntly
> used line), you would need log2(n!) bits of additional storage for n > cache lines.  For 2 lines, a single bit is enough, 16 bits are ok= for
> 8 cache lines, and for 16 lines you already need at least 45 bits (in<= BR> > contrast to 15 bits for the pseudo-LRU version).

maybe with a drawing ?... i'd understand better ? i'm rather tired these da= ys :-D

> Real LRU implementations will probably use 2^n cache lines and additio= nal
> n bits per line that form a kind of linked list.  The least recen= tly
> used line is at one end of the list, and when a line (any line) is use= d,
> the cache controller removes it and puts it on the other end.  Th= is can
> become quite expensive (in terms of silicon real estate, at least), > which is the reason why I suggested the simple (but less perfect) vers= ion.

mmm... the "linked list" rings a bell :-)

i don't care a lot about how much silicon it really takes
as long as it works very well, without troubles.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Tue Sep 19 11:32:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00348 for ; Tue, 19 Sep 2000 16:09:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Sep 2000 16:09:55 +0200 (MEST) Received: (qmail 7638 invoked by uid 0); 19 Sep 2000 09:28:12 -0000 Received: from mq.egroups.com (208.50.144.79) by mx06.rz2.gmx.net with SMTP; 19 Sep 2000 09:28:12 -0000 X-eGroups-Return: sentto-1101623-758-969355687-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 19 Sep 2000 09:28:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 19 Sep 2000 09:28:07 -0000 Received: (qmail 32506 invoked from network); 19 Sep 2000 09:28:07 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 19 Sep 2000 09:28:07 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 19 Sep 2000 09:28:06 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA11643 for ; Tue, 19 Sep 2000 11:28:03 +0200 (MET DST) Message-ID: <39C732B1.D1B3BDB7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Sep 2000 11:32:33 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) ICache Specs Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 54b117349603a881dd021d673adb1d85 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

so here are some requirements for the instruction cache :

- line width : 32 bytes (256 bits)
- number of lines : undetermined, could be as low as 4 for the
   tests or 256 for a final version. Size doesn't matter, behavio= ur
   is more important.
- strategy : "true LRU", 1 set/way, to avoid nasty thrashing.
   this could change in the future and it's up to everyone's tast= e
   and need.
- 1 read and 1 write data ports for simultaneous access
   of 2 different items -> 1 read and 1 write address buses - 1 "cache hit/miss" output bit.
- latency : 1, 2 or 3 cycles. 1 cycle is necessary for the simple
tests, 2 cycles might be necessary to speedup the clock in the future.
- It should be possible to invalidate/flush a certain cache line
if it corresponds to a specified address range.


VGUI outputs something like :


ENTITY ICache IS
  PORT( Flush : IN Bit;
        ICacheHit : OUT Bit;
        WriteIn, ReadIn : IN Bit_vector(= 24 downto 0);
        Din : IN Bit_vector(255 downto 0= );
        Dout  : OUT Bit_vector(255 = downto 0);
      );
END ICache;

ARCHITECTURE structure OF ICache IS
BEGIN

-- the hard work is here !

END structure;


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Tue Sep 19 20:15:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00322 for ; Wed, 20 Sep 2000 01:19:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 01:19:14 +0200 (MEST) Received: (qmail 27581 invoked by uid 0); 19 Sep 2000 22:03:37 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 19 Sep 2000 22:03:37 -0000 X-eGroups-Return: sentto-1101623-759-969401005-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 19 Sep 2000 22:03:36 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 19 Sep 2000 22:03:25 -0000 Received: (qmail 6666 invoked from network); 19 Sep 2000 22:03:25 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 19 Sep 2000 22:03:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta1 with SMTP; 19 Sep 2000 22:03:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01358; Tue, 19 Sep 2000 20:15:21 +0200 Message-ID: <20000919201521.64083@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C71283.C2FC31E3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C71283.C2FC31E3@f-cpu.org>; from Yann Guidon on Tue, Sep 19, 2000 at 09:15:15AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Sep 2000 20:15:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" X-UIDL: 659a46a5c8d4611e6d8c32b36872dd71 Status: R X-Status: N --8t9RHnE3ZwKMSgU+ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
eGroups My Groups | f-cpu Main Page | Start a new group!

On Tue, Sep 19, 2000 at 09:15:15AM +0200, Yann Guidon wrote:
[...]
> mmm... the "linked list" rings a bell :-)

Ringing bells always give me a headache :)

> i don't care a lot about how much silicon it really takes
> as long as it works very well, without troubles.

Hmm... in fact, I like a `real' LRU better, too.  Especially since I tried
to draw a picture of the tree algorithm with more than 4 cache lines :)
It doesn't scale very good, and the update logic is too complex.  But the
`linked list' approach has its drawbacks, too (it looks nice in software,
but is hard to implement in silicon).  So, here's another proposal.

The basic idea is to keep the cache line numbers in an 2^n-stage, n-bit
parallel shift register (assuming 2^n cache lines).  In the beginning,
the order is:

      7 6 5 4 3 2 1 0

The last stage is the LRU.  If we use cache line 0, we put the line
number at the front, and the register contents become

      7 6 5 4 3 2 1 0
      \ \ \ \ \ \ \
      0 7 6 5 4 3 2 1

(full shift).  When a line is re-used, we move it to the front by doing
a partial shift.  Let's say we use line #4 next:

      0 7 6 5 4 3 2 1
      \ \ \ \  | | |
      4 0 7 6 5 3 2 1

and so on.  The shift register consists of 2^n identical stages, which
include an n-bit register with a gated clock (or a register and a 2:1
multiplexer, which may be easier to implement), and an n-bit comparator
(see attached figure).  The comparators are used for partial shifting.
When one of them returns `1', it blocks the rest of the shift register
(second figure).  That way we don't have to search for the location of
cache line numbers.

This unit should scale pretty good (the blocking logic needs to be
parallelized, of course), it can be clocked synchronously (EN used as
a `shift enable' input) or asynchronously (EN permanently set to `1')
to save power, it has a simple interface, and it doesn't need too much
space.  And finally, it is self-initializing -- no matter what the initial
contents are, after clocking in all cache line numbers (while filling the
cache for the first time) the LRU output is ready to be used; additional
circuitry required: a binary counter, a single flipflop and a 2:1 mux.

Whadd'ya think?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 --8t9RHnE3ZwKMSgU+ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lru.gif" R0lGODdhHAP+AvAAAAAAAP///ywAAAAAHAP+AgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKhIAtAIYPDo+KggCem4iJmpuUnViHAZ4Mkg aslpeoqaukN6IMqaQPqqOktba+shG1o6Opl7+wscHOzbOrngSSysvMyMmRxqTAnaTF1tTfhM XHnN3e1dlx0NGyn+bX6ODhbe4Fqe/g4f/5Ssbfwsj5+vnyPbTrkLzd2+gQQLtpgWS5y/YgIN OnwIscM2S5IqTQwYMaPG/o0cO3r8CDKkyJEkS5o8iTKlypUsW7p8eaEhzJk0h9W8idNmzp08 UcnsCTRooJ9Cixq9Q/So0qVtkjJ9CnWM06hUq2aZajWr1nlbu3qtgvWr2LE8wpI9i1aG2bRs 26JY6zauXFxz69p9ezev3g9w9/rd2/ev4LqBBxtuW/iwYrKJFzvu2vix5KqRJ1tmWvmy5qKZ N3vm2fmz6JqhR5t2Wfq06pSpV7sm2fq17I+xZ9vWWPu2boe5d/ve1/u38HjBhxs/V/y4cm7J lztv1vy5dJ3Tq+O2HrWi9u3cu3v/Dj68+PHky5s/jz69+vXs27vHfiu6cvnw3dA3fr/+mvzC /vnrR+OfbwH+V8aAuhlIoBgI2rZggl80KBuEDnIhoWsVTngVhhJpyMmFqnnIYSchagDiiFGU OBqKJjqh4mctrrjEi5vJCCMSNF52Y41F5DgZjzoK4eNjQf74w5CLGUlkWUlGgOSS/MTkXpRS TklllVZeiSWVMTk5yFpNMlfkllwOJeZWHno5JpkWfHnNmWWm2QeakIW5Jpx/yGkmnRWwaScM eGrlZp198vFnVoHuOSihbxqqJwV8JspCoVYd6iikekhKWaMTPGppCphSRemmneLxaXaaSsDp qCaUClWoqKpqB6tPucokrOAsOumptdo6h6yY6QpBqryG4OtStAY7/qwcxSp17APCJkuXoJ5m SW13U1SLrXa47gqtfdsiu2e24t5jxLjjfutst28sO064UpC7Y2wNtQYvLOiqW+C97OiyKZv1 DvHvtvKy+wm+Tek7CiT9vutvbe4MjPAxBrNBcCsWM9kwwyc8vGrFCk+shsf8fuxsxic6LHEJ AZNcKchpiKxQsCZDsbK0LI9Qs8guWwHzPw7UXOTMKtvbccQ+72xGz0cfIzSLucVctM2iIp20 0UQv3e7JGm98NSNKU02Gl+jty/TWNPdmz1tfg62gDQ833QTQiN6M89psq3NDOf1ME6/Zq14c 9dyC34133lkXAxARcvew+NQjq2w34V0s/hjNK5Uf0fgqwUUyrdUFS144DvZUTnq5cDPyOOSe Aw765KskzkrmLsjOz+ape7063a1n+Hrspfettae315378LtfUSHfvpvuN9edS/3q8RT6sDzi wJ+9wuaRS88z9b8nDmSz7BSnffHkcz/DhdWDHwTtqjt6OriDb/zsmMlb/vn1SmLlft7bo14/ J0mIHFnrX/YCNRUD1iBnxcNAL9D3Agj1Qm98U9yhnKJAGjAQekPTHQT/9iT2MSGDILiczJoX vfmB0IMfxFkIRRijUBGFhGr5nwvz18IVLvBw83DVT2gYgw2qsIM4zOENd8hDp+lKJkD0kw1F wDEjog6JSYzb/rHmFb90cXCKWJMiLsRFNmkwzFzmCWMVR5geKGXLjF7cUcJ4gULFlS1402tj uVIGRzXyYoK+I4flVtZEvJyxX9piSCE/AYrABPJ18NtbHymyHTs6jnVz1OM4vge4CuYsSAop TEIwuT6MZGCRjDyh9U6ZyQnCUJJYm2FfKihK9pFudA4cEiahhMhc5m9vJAogHscnRlSSjJYs ZCUOkyK3iyhTbwV8pZGIOUpQYvGXa/IlNYOpS1lW0pjcwuAroVGwUNINGb3kCjjLiUpfZJCU jANmJfuxTW5qMYHfTMg5tXnJDbBTeI2zZzZHtk5rvhGbh4MnQeX5M+PlcUuJJKAw/ofXzy/B MlwXgSRCKJhMgQ70n9k06CAR+tGFCsoVsGPmJRWZRVSpkofQ5Ki78jVIfxZxlSClJMZGWYqF 4BNxi9unCiIqTHW+DZ0wfShAPOrSmoY0ni2LpThT19KXYo+o96xqFXuq0Y0+9KlDVeq++PdN iqQzlJ+s5ck8Kc2r8TKaRb3qLJPqU6Q9UKU4Zd0fVwq+iZqSRVatZkGlyUd9ZrVrBHUkDOO6 s7Td1JIA1eQy+2gWxE4Rq4+01kklMlibMq0eeq2oV+262KmO0KgxbNtn3UZYpqIxbkktbehO q8EuLhVznJwt8x4EW8PJlrRKkCxfDmpF3OYWtdfkbRJ8/rsh4K7WdfIkYxm1alwbObc8bIwu bcdWzTVCd7jtVK5ru7vbvi53iPITZHhdtg3H+su7yKVqKWfa2t4+kVjFBRtXRQTX9rKVeucV 73ebCmDnwZdtjxwwa7eqVyDoV4uata3+JglhHSrUvrM0IX79u2Bc8rfBDrag+bJnYAJfLnbI O+yNMhxGb8axvBEmYmZdZMJYYMGh3lUwAhdGxwCnUJAvhvHnEnkVoUo3TGBdMYN1PLQe+ziV nAuySD3sPan28MM/VfKSWUZOJ6u2feJ7cnC3eGQBQ5DEiAygkGlr5OPOl7si7WT9OnvilA4Z zAlls5QpOGPxepbLaZ4zecNs/ueStcOkYJFlRW4r2inTubqBXpd1Ea3oRLeYxY321qMf/GVJ 73jSlX5ZhwEmZzQverudBlCN1dxnUf+5zqXez5blm2pIc5rVrYbidMfDaP/COsdKHHV9a53n X6OYL6GW9aaPDWzepTa+qOZ1ppFM6WQHO8S6bramxwttQEu7xNSutp8jDe5Z53rbF57wpaF8 7f+Km9TkvhaHPx2+WGOaW9lu94mKCW8+Oxvb6/61vWlm7nzbWN7orve4/x1umd0aS2NcuJWo jPBCU9ThVWo4xacE8Yhvwsp+0JnG49QTj398DxwHua9HLoiSK+rkKAeEyknewJbn4eWXirnM kRJy/pvf/Fag0fnOe5Vzlv+85j0X+tBJFfRVH93kOxH50uFA85n7/OkHK7rSqS51qxsc60jX er+5zvOmTx3spvY6ssmedbEbHe2Wbsl31MgdttMh6o42r9zjQPe6E/HueKcJvfg+d9IcEfB9 F3wJCR/4m1Qm74j3N0saw/jG9/fx+pR84nMSVssrK+lb13zZza5tz1ed86EXPcWEgkzTXx4o P1T96ll/cNeH7ChRlP3mab9s24/eKIrV/e1HcvG3+757wA++d4ZPfJEM+9TIjxFs1Bd5rEff C8sXePPb9/woX/9d2Wfc9J/+fQpBf/vcL772yW9O5Y8f/ekPSfWZzX43/prf+/Hn6/zLEv6j 518L7z93/Tesfuf3f8fVffg3gM53f5pzgL1VgAq4gDbSgDrQfw8YbR0xgd5GgUqSgBK4fz/X gTO2fhkoRxtYOyIofwFIfyYIMBFYgioIJCwoOh94czLIMyHogsDCERd4gTf4brhhgzyogSho gEAIgO73g0T4QkYogEiYhCChgzTYclDYCd50SAoXFjsIhFJ4LfTEEHuFgf7HhJECg232Q3gW WmEoOmO4TevgYFjIg1pIcE/VWuTihjcIh/u2UGzIfDSFhn6ihtKwZzGFTHcYcYSYcO50UhYh EHRoiP/GJ8YHieSBY3T1avDXh7PjbjPHhYB4/mh9BS916IKPeCmbOImXBooqKIqaWIqUyIeW eIliWH6kQoViEzCnaIKpKItV5levSFz3poq6CD+82IsA94tVRorCqBaZmIuRkmCuiIxi1n6x coTPeBDKiBTTSI0gFovXuITZCIu+uIxD6I2YuI3S2I3jKDzlCA7YiI4SZn/h6IDtqI3gyI0p KI8/ZY3maI/3aHfRuI7nyI+D549zx44BeXjqSJAAaZAHSY/6KI4LyUXECI8cCJHueGAT2YIV KZDvWI8PqZEMKZEdGY8fCZID2SsFSZIOlI//uI8pmVwNyZIe6ZKVh5AnqZAzuXbYV4wjiZMk spIJ2ZI9qZI1qSwo/imU9GaSRXmTR4mUHOmQPMmUV4c5o7iUUUlrSYl3RmmV7MaAO0mRW5mT CkaVQQmWFYiAshiJVViWTXmR15iWnbiWZ3eWqtBkcUmOMGkKvWeX8xiSpwA1e4mPROkMjgeY vyWYijAvhdmPTqkJraeYe4eViJB6j7mRbZkJCUSZUPSTiXCFmVmSjMmZY+eZuLgImeeZPnmY KUeTp1lXeFkIkMeardmXhrB4sSmaaRian2mbpdeVh1Aajah/m+lykLmbsQeBtAmNxUmYU/ma 6aicXEmA2HB82RV3z7mcd9SYt0mZpFma2vmY3ImY3qmY4JmbUmmd3caclymehUmekrme/oDZ nr75nnsZn8gZlsVZn815n7uZn9gwn7nnkv3ZJf/pjAspoKq5n4gCnEp1oGpinsm1oCDVoMOZ oE0Voc0lnPb5oBxgYQGaofq5oauJbwE5oXdCoDZ1oZJUoh13orqTom20okzXedEyeUb0ljeK ozmqo8EHd9VinOeJFi+KE49VZo0VSSg3iAUmVqNzpM6BVDpVVbaIXmeIZXgVpUKKDh5FZnk1 g144TB2KP8+hpdMEfiVzNPVQH2O6iFiKHz9DaHCWpoQWEGY4oghHpscES1vqpHI6p4kopQTm ZW4mqM34G0jVhelUpsD1NqA0HYZ6qF8oc3TaYBcVp+ElU9LH/lR3+qdfoTx6eU9h6oF71FF/ BaD9AaWXKocjx0Sn2lKpih8V5UcVBpeRaoUx81hqCaSokauEsatzwaa9mnbAyha/6hY7aqzH iqzJqqzYdZ3eGKMEsYgp+awDUXsfOa3AUaPyeK368JfS+qHX0YMGua354KnempoZMVc9Oa74 UJfq+q3oSqx2tK7yEK/y+q7Cygzziq8+ca/7Kgz66q8d0q8B+wsAS7Dqea4HW7ADq7C0YLAN W56zCbHK8LATq6ESa7HAULEZO6AJy7H86rEfm5cMK7LZGbIla7KuibJ0SbIrG54n67Ivq7Ix O7IwS7PyabM3C6IYq7Mb17I927Ez/gu03ZmzQ0uhQmu07lm0SSujkcm0T2spl8CkhRSI6dOk Vgi1+khWURWDj4qIkJq1YQOmfzmBrmpoYQt1d7qHQXRLilqv/gqnXuY/zHZmaNsUeTq29qiH 1me3WwCrVVi2syq3YNu3YdCpeEqWcVe3hXu3XAuGzBiMlci4SeO4rci2m9WJazW5n3dUZMun lxu5Bbq5/Neq3/NHbhNZbTu6UtGnhpS5lmW1m7Spq9uYb0u733a7KEGouUsbu8u7vwu8wSu8 w0u8xWu8x4u8xmRZcXUP1WmmsfSoAJAY0otRjJW8gqVL0nsQ2rtX1Nu9XUW4X/u4lnu9Xkof 1DuIoqtn/qHBvdbXvuW7X6h7hu9LpeQbuuo7vvCbX7LqvaLkve2Lvm6aX7nUvwUMwLIqVv47 qGLUv1dKvwG8Cw2sv6zYWBGMVwd8TtxLv/+0wZ8KTRjcuSGcUwYsQv+rwcQEwiccrhPspyis WCDsVKr7hegLwTCcwh/MpBasWTdcUh4cwSx8Z9YDwCLswDQ8uCylvTbswqekxEf1Tiv1vkk8 VLYrjB2cwVCMw85oxUkkxUy8xETMw+srxFbaxZwIxFLWUQ3cxKaYvgScxToMxjhsxWEcxTTm xme8ikyMTTAMvWtKpWXsw3AcyINchmPcwx2swnjspV5swH4UVIB8WSX8Oyb8/sZX7MWMjMiA HMafSsSKjLlmPKeUjBEQbEh7RMIt/FaUHKuuu8o1fMJGHMmtK8uQlMDQ68mLssXClb+3XEOl Sn3dystcVq5SMcTBHC8SfAawbMzLzMzN7MzPDM3RLM3TTM3VbM3XjM3ZrM3bzM3d7M3fDM7h LM7jTM7lbM7njM7prM7rzM7t7M7vDM/xLM/zTM/1bM/3jM/5rM/7zM/97M//DNABLdADTdAF XUMaPMulnNAGjTxvpWt1zNB+a4ZbzMcR3dApQ9FW6nKkrLEcXbAerR+5/NB2vNHKHB80TMW1 KtLSIdIZvdJoidIfjdIpPT4znSAtjUUvLY0zrdOl/snTPY2YP03T5oDTwATURfnTtiDUQ43K yIwdRZ1HubzUU03VVW3VV43VWa3VW83VXe3VXw3WYS3WY03WZW3WZ43Waa3WYb0MUq2phrjU Si3Ucp3U1DEME21SB0yIcV0LfO2wc23Xd13JgmzLo2jTJ33YdB3T/0oNHD3Xjn3U9rHYMg3S f23SGjshl43YkX2ZlR0fGsLUcvnZ0AHajW3apI0hoc2WmI3amX3a+fraDqLaZjnasJ3asU2x uE0gs82bSq3b/8HbV8nYrS3bv83atu3axJ3byr3bxr2wzA3czl3bbV3a0H3c1D0ja63diX02 2+3dnG1j3+3dWyje2z0p/uU93meF3mttceuN1u3t3mZ93hZZp2aFhzSarRqWbvjty+71bJoJ nf6NGSiT3/p9iLoJMffN3/Vt3/u94AEn4MZC4P0d4btGnBAevwdumBSe4b124QkOKhOOnh3+ 3wDO4Q2u4Q8O4in+kiOO4q0i4itM4vxm4i5u4B4ekTL+4iVOXwW+iyHejw5TbCKK4TOubgIp 5AQnm0W+4wMe5PSj5EOp401+5DXO5DfO4z0+5Vju5NCY5ArO31/u4GEO5WDe4lf+49nxNCdO 5RYOmWLO4mcO5zie43MOE6nrnE/TZZJLo3qOg+LLRX5ehBTsYmrTovl6hWiz5Vzetfdb6GVO /pYCbF6CHumAfkSU7ugb0a6LfOmGzl9FNume3k6gLmCY3juZ3umQXinBHUEMDt6CY+oS6OqK zuBGrlvH+OiBo4G4Huii3jKsXo31/eoK+jzgpWL8VOxBeOx4gTYXROhJluyOA+x82cbMHu2y vsLDvurXnoTVzjXN3ije/jfgbjPT7pwjqu2iQu7ghe62s+5B2O74+O7vFXDp/irzvmnmnpyF jOy+Tu/mZu+1gu9NCPDuzu24SW0BjywDT2n6/uGSfu66/u8TpvC0XUK0sqp8KfHYXqoV39vE JjDoym4eL9y4M+gcRvI/ilnAorbJafLsbmApH+Bf9C3AGd9WnWsy/t+sgnXzVJ3z5zMtPT/V P6/xkCP0fr1bOu/j0bTVKm8Q4BvnJx+++nacfFvpOmn1MsmhYCHBXZ/ErOzUMKn0TjSX9gtq ZT/1A9ebu3z1S44xmTzZsxz2/j3JacVtbK/1J2j28Vb2Yx9BtYW/am/l9cvILsW+b5q3Nh6d e0/1a+/3s2NLgR80bfn423vhEF9YbXv4Z9ryfov3UFn1lQ+5Fyn6B/SOpQ+MOf68a6j5tsb5 flw4qH/wzCn7/t6VADDkOon7Uc5yu0+Ghu/6XYP7vs/BrkP8Ub+Cx0/nzqf8WQ6BzU/jg3/E xK/8zb/5hDX8gwr9DZ374dP9wsz7QfP9/lKO+X6qqMEPX8Nf/L8c/pNv5sYW/VUu/9L/Ub5v /Z/Lofgfw2Lb/lUJ//NPAPExdbn9DwCQVnuZxJt3pD1scsClLA00DbPxa06XnWlPrfHuznlr 74EkWZAIGxaRn2My+WMSnbxlwomyHqchiexEdamyT3EkOs6VzbRtuhlmz9ZvqFtuQ9d1dDXl NroqufQ24v5SApXwzCbuEkUEG/kCGCErJilJJB8vHyw3TTI94TR1KodAwAL9Ri+2wDKvWuNC e1RntVZta23zdkUMezk6d3WBWXFZS2PXWgEBhYuhM8iifY49v6xzsy+xqUu9YabBObc5x897 D9Fb1iMQ2xWe/q/f4enX1evFgcrz+228/P1qZ4rfJnncAAY8SIlgQFD7HEZkgqUgt4pvKDpc 2CijwotsOvrbKE1iySBLRl77qMjEykQp5aB0iQcmxpYaV840KURZT2XBfAaVFY+dR6FHkSZV Gu6mUaVPoS4lGU9nzKhXsfZkShVn1q070wUT+6moyKp7yDY1GzYtV49siZbt92zKWbA4cOVt 63btsL0J++b6ay9fzZOD9c3VG/cusMW+qJDDCdedkMl+I1t+i/mF5sDIMjd2PBZyZc+KKUuC YBgSa1qhjVwW3Pl04ccrRBe77YN27XqupfSOvXk2bsnEZ3HhYzcNXeG5i4MuLQg4/k3mWkwf /xzqyzfk3LP7hufcOPTUlcY+ql5nfQ0/1WQnL68dNWb118eQx2+exW70mtrDaD+xABxwIgN9 KTA+8BT87j/+oPFvOUcWVIlCBw0aJUCQEDTmwu28g3C0QUiDD0OEPqwvuhBVlC9F20oUkTPp kNiwuQ6LsFERHOeocDweTwJSxhxj7PHEe4SkJUkpljyjSbyedC/KIfEqMkgfB5pSFCyR5BId HalkicQDvTwHTDHOfCJNMo/8Ussw+7NynzdvKXOcNduwExw8a6QTTlLGzLNNM/3kZdA7CwVK zz+jkXDORanhM8dEB6H0xd8s9ZDRwuRUEtJGMzURxB8//o0w1E0xCbTPUnU7dcJD93R1NVnp Q/XLTplk1TFaxctS13R4Hc7We3B18tdhgpULRli9kdTIYW9VddJjtaE2uWTVanFZaM0sFkpr ucOWL20xBddCbruV9llySWU2UnEBY9dXdO/0VkpzM8TXIn0ZgpcweiO0Vw1/E9tW3i7dBZVf gNUUeMuETV2YI4IFGnVehht1uD+KH7IYYY/dlPgljsN01FOIWxXZOpXZ49hZjNWNJOZay52R RYPBu7TdFV8FGWaDNC54Vpbv1dTnkXW++NqkP/75PJkTNPrg1lQTdWqOqr65ZsEaPNpprGc2 J+uhURbzPqLROrvs/Obrtemv/l0sTTrqXC60u56vfik8YfOmaW9lt4Y7bhp5+3tcnOcxPF7E gVb8350H1+PlRwXnGWrC6Zj85BUzrzu1ztGGAzbAIa+8cbkLf27xwHNW/XGlW3e8477ZY4x0 2E1nKOi2xz6c9cRHX7104F2vmPaYEDOe8dz1DjtV24XH/fTghR5++uI1z9VmxbM3lvnrk7nq q9eRzMp8rMavPsvz2X8qfeUxbV/+o96fffnvkQc7+rebzfZ+3fz3u0gF0Hr4y5/+1Me//u0v ZMRiIKEG4rsCGhAkKEpgAx14QQhGkHwYjJYGEUVBqlnQfgLcUwc3yEH4TXCAIIyVCBE4whKy sIUz/pRevVZ4wxPmUIEwFFPjuvctTtmwhzgMYtF+w0MP+rCCDPLcXIi4xAgecWAiiWIKmdjE cD1RMVy0jRfjF7os1q81YDRhEaVIwxCubYyiqxYb3+i1ZplRjS9sY3OQJcYd6TE/dNRhGu9Y I2340U2EJJQhEYXIQL7GiXycyBXXyCkqPkySilzkGXI2yY1BEZJ2TGIn58hJTdbpkg073Sjt MERQvkuVqDTUeFwYylI+koSuVBQsY8lKXCoRix9cpcJm2QQS/jJiKuRlJH1JzJQZU5m7CqYw ZZhLYCazmcBiZjXzmEFpFvOZUIjmNpeZrgcic4fj9CQOzSnLbgZpfkmp/p8tK9VOecbinXWb 5z2zUBd74lOe9XTkOr2ZPHgy7Zvcs2TtBHrQA1LvmOcEqDiLV8JlkEErr7jPT8JHwGHyTmgT NURFmRG+kC5nB65EiW88alF6WrQaGCWpTJ4Whj5oABsgHQo5XDqrkpLsklio1Snw0bFOxAB0 BTMp9A4HVHvE4EM3zRYqzuMGqM6uEMQkKtmUd1SGGpUYVO2G0Zw6rqk+NJlFNV5QszZUtPqu qoPr3VOVY9RttjWAdCXeW8Ua16zOda2rs+v1zEpVwnzVamWYKQrJShnJ9ZWHakXhYcH5Q7zm lW/pTIxhQ4JNU3I0XlXIp4YY29HQRnOx5PNs/oowS9nEipNuzdCoVUf7A6ZyprUUvR1sOyhb wsatth+9rWMvqNvIso2znRXubeUSheNqdrUIVRtFMztataR2unYr7uJGelnEAoa6fNHqcz8a 3e3So7vcte5k/Zfds45XH+UlL08XuQiphdcLK22oM9Cw3KN2Dbr1za5a1avR2XJtvizF7195 EtboDVg+/KXvgaVLlQBLUKjwDSRwJbxU9q7QJzZkcLiSNhQrbHiGHdav3UDbgqBGWHgm1udw 0ZTilqyYxDv9yYmbi06r1TeBGMbbe59GM9s2VsZaq5hWCzxkIvoYq+YNsttkcdokV7a9Fs5x cHdrWQ7bVLUg+3CN/mWCUcjeV5dlkfKOwxvSMTMXxMI6s5E7LFEWX1lpDdkr/GRa5Mt60c72 yzJ6cWvc+PTZFXh2G+AQ3DRCm6Kjh67rnOnsQQZXdayv5VulDTZpfGBay2ftc4s0DeTcroKu A5VaqKvMQGGU2sp0HvF/4ywUI9AlrKYurIHTrOagzDovteYzrlWq6zjPuNc7HTSwdx3sCT/Y EcaOdEls/bpo/3ianQ6nOq3tTHLC+Nna3jabz/XtaTcZ29xeWi/J3O1yz/HT/9tVu8/YKnjX cZDZVre3D/lneg9S33+Ud7/R+G9z33uL/DS4VMxycIXTzykLd7h9u/hwiY+b4Ame+MO7/nJx jDdc4wrPeMc9XnEq4afVgtws3EhuupKL/JoBFVzKKwfzl7Nc3TJHOZpUjvOY07zbNv+az50G 9J+tnOc6NvnMT/5znSO96FcWOsyejrGoM4zoTa8hNJmO9ZsnPehWd/rSt07LrB897F5P7NQB hnZ6qR1dVTf7iMRedrIrnetDf/tq2c6tvENr78Ny+90td5id1x3qYKc74AHad1spHlWM39Tf EX9XIg0+7ofXuuUjH0zHM2rzf+o8nCCfed0RXuqG7zrpqS76bn6+ZKa3O+rTrvpnsn7kri88 7Ncue83bfk4S5z0jD+R73FdJTRP/ve59SHuROvz4mAy+8Cs//vk2GH/4yDeg8ql9peqjRVDd v7z0V8Wm6Fs/i9gn97rmDv5pif/7Lg+/99NPfiaaX8iUG7/g4Y9+9e9f+/l3v/zLr/mQ6P3a D/8IcP3uDyLYDwELEAApiP7wC9yyzwDjb2CW4TrABAKhaxEwUAMdsPEEUFoUbHMaEPicT8kO kP8o0D14bAFV8APxRwNhygX/7wX/gcJIsAIV8ARJLJW2DwYxzwY7pQNDkPtYcCpSsAaVEDuQ kAF1EAhzBwLzqfiK0I2IL3m0JwFN0Ai3KgtLEAopb/r6qQn1bwl7bwyx0Hu0kEnmiYy88AnB cOyurgvV8Au3R3aEaA3v8Lry0A7j/vD0jC6iMqxSqhB88NC1CCo4IIoOWzARefAPmSdYZvBV SM0DXW8SToEQf1DyVikTHfEKITESmWkE3aISC/GuSDEhTHETURET3+MTjzAURXF9aEptVrFP UhFYLtBEbnFSchFZdtE7ehEOZbH03IWmbskXl+3b2KHXxPAXuWlonJEVi3HxPgWoGCFAkm3f HmIZ7a2lcirgVBEaM7AaoxBSogy8lGQbxVHJXFEZK8rfEPEdqdEcOW9RavGX2oPh5PEX8hHN nIQdAYkr/tHIVtAeb89rsBG0QE5c7mAhmw3k4k0cvJHYNg4hg7COrmrKpEQg0a269Gwdh60d NxIgMTLH/iyJqByMDUdyIN/LEvZR1jSyplbyJFFST3YR4qiMJXXSJW2rFn9RG1vSJ30LKB8y 9GwyYJhlpMjRLuKR3pgyG50yHNsR15oyKV2tItet/+BRjiipK49nk7CyuZ6yH6uoHrPJ/w7S LL9yLIHCpggCKXmtJz/S/vxwK+2SGB2qDN3y1P5MLlVsKJkxB4VwMN+wMPeSK/tSE03jpgDT IqnSMOtQL/GSMM2QKAdwMZnmvyCzIT3zM5mPBtkJNO+JCouPNEtTNDXz/NxhxB5PJtlSLFGO CF+ONlcTtTqjC17TIyWzD4PONn8OOG9z+eKKEBZPMHszM4dOOJfTNIfz1hoT/hmPky7r0jKl jjmhDjufcyfLQzqnk+KQazKbUzXTTju387XiEgh1BDwnxjmD0z3PszbuBgUBcD0fk5TUkurM Mz6Xaj4HjufsM+b2c+0GlD+TzanuEzo0TkCpbzYblD/jc0Fr80F/k0Ih9EIxNEM1dEM5tEM9 9ENBNERFdERJtERN9ERRNEVVdEVZtEVd9EVhNEZldEZptEZt9EZxNEd1dEd5tEd99EeBNEiF dEiJtEiN9EiRNEmVdEmZtEmd9EmhNEqldEqptEqt9EqxNEu1dEu5tEu99EvBNEzFdEzJtEzN tPxibUC0sr8AbWM+YsJGEtYS9Ew3tBDOJDKNqypc/uPMRMyn6PRPk5EPKScV18w6BREH26oP AHVROZK4eKmknBAHf2vF/JRRLVU8+lTMsLHC8qurHjUdieGq0tEZ0oxNEZVSkepSVXW9BEKp KmwaXJW6CnUcYfUCRdVVu7GrcNW0skxRV/VXN3C2dHPARrXHpOqz3oEQcFVYdZUD9+xUA8xX gfVXXTNXK4NYU4E6r+jNlpWwmDXXCnIopWxW53Rab/O4YtVb56xTLy1U1ZUiPfXIAsvJ/qVc zVUzTwxbn5U1BUwd9FVeW3US2TW51spe77Uv9cu7dkvEvItmYA1gIdZaX+EFSvKtfDVRE+1g zTRfN7VYf5IiVkq3vqpbhVOtKNXVWSeWA1EWuzwVFtJNY700WpWVnmwV2GwWXJVIvaLSKA0s XEE1FUwVwmwVaDcQZo1WONiTX492aa+tTWOTaaF2YvwzIpI2ag9WW7/IYK12a7m2a732a8E2 bMV2bMm2bM32bNE2bdV2bdm2bd32beE2buV2bum2bu32bvE2byOiAAAAOw== --8t9RHnE3ZwKMSgU+-- From Steve Van der Hoeven Wed Sep 20 00:09:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00325 for ; Wed, 20 Sep 2000 01:19:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 01:19:17 +0200 (MEST) Received: (qmail 4282 invoked by uid 0); 19 Sep 2000 22:10:14 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 19 Sep 2000 22:10:14 -0000 X-eGroups-Return: sentto-1101623-760-969401396-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mo.egroups.com with NNFMP; 19 Sep 2000 22:10:07 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 19 Sep 2000 22:09:56 -0000 Received: (qmail 22797 invoked from network); 19 Sep 2000 22:09:56 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 19 Sep 2000 22:09:56 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 19 Sep 2000 22:09:56 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id RAA08926 for ; Tue, 19 Sep 2000 17:09:55 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <20000919201521.64083@thrai.stud.uni-hannover.de> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Sep 2000 17:09:55 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0299d2b30354ac8387807393ce4d3404 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!



> ... additional
> circuitry required: a binary counter, a single flipflop and a 2:1 mux.
>
> Whadd'ya think?

>from outside it looks okay for a basic caching technic...

Yann would be delighted with an vdhl source

--Steve


 From Yann Guidon Wed Sep 20 06:41:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00307 for ; Wed, 20 Sep 2000 16:57:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 16:57:38 +0200 (MEST) Received: (qmail 1172 invoked by uid 0); 20 Sep 2000 04:36:47 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 20 Sep 2000 04:36:47 -0000 X-eGroups-Return: sentto-1101623-761-969424599-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 20 Sep 2000 04:36:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 04:36:38 -0000 Received: (qmail 931 invoked from network); 20 Sep 2000 04:36:38 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 20 Sep 2000 04:36:38 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 20 Sep 2000 04:36:38 -0000 Received: from f-cpu.org (nas2-195.ras.club-internet.fr [195.36.192.195]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA19452 for ; Wed, 20 Sep 2000 06:36:35 +0200 (MET DST) Message-ID: <39C83FE6.8A147DE5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 06:41:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 19071a194e08ccd7d4a3e7acf3f19fb6 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Steve Van der Hoeven wrote:
> > ... additional
> > circuitry required: a binary counter, a single flipflop and a 2:1= mux.
> > Whadd'ya think?
> from outside it looks okay for a basic caching technic...
> Yann would be delighted with an vdhl source
vhdl would be really cool, but testing/simulating would be even better :-)<= BR>
i compiled "electric editor" but i don't understand anything.
shall i read the manual before ? ;-)

i had already downloaded some stuffs before and i have to test
some packages : gEDA, Espresso, Pica, FreeHDL, Savant, tyvis, warped...
If other people here could help and do the same, it would maybe
speedup the development :-)))

> --Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Wed Sep 20 06:41:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00310 for ; Wed, 20 Sep 2000 16:57:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 16:57:39 +0200 (MEST) Received: (qmail 1251 invoked by uid 0); 20 Sep 2000 04:36:49 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 20 Sep 2000 04:36:49 -0000 X-eGroups-Return: sentto-1101623-762-969424602-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by cj.egroups.com with NNFMP; 20 Sep 2000 04:36:47 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 04:36:42 -0000 Received: (qmail 28683 invoked from network); 20 Sep 2000 04:36:42 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 20 Sep 2000 04:36:42 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 20 Sep 2000 04:36:41 -0000 Received: from f-cpu.org (nas2-195.ras.club-internet.fr [195.36.192.195]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA20462 for ; Wed, 20 Sep 2000 06:36:38 +0200 (MET DST) Message-ID: <39C83FE6.CBADD819@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C71283.C2FC31E3@f-cpu.org> <20000919201521.64083@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 06:41:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 03477ae5167a6ac8130b537748d4f669 Status: R X-Status: N
3D""
=
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Michael Riepe wrote:
> > i don't care a lot about how much silicon it really takes
> > as long as it works very well, without troubles.
> Hmm... in fact, I like a `real' LRU better, too.  Especially sinc= e I tried
> to draw a picture of the tree algorithm with more than 4 cache lines := )
> It doesn't scale very good, and the update logic is too complex. = But the
> `linked list' approach has its drawbacks, too (it looks nice in softwa= re,
> but is hard to implement in silicon).  So, here's another proposa= l.

<snip>

> Whadd'ya think?

wwwwahhh....
if it really works (i'll give it a good try, just in case there's a flaw that we didn't remark), no need to search more.
I've had another idea but at least twice more complex.

i've looked a bit at P&H and they really seem to like the direct mapped=
caches. beuark.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
warning, he just woke up ! :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Wed Sep 20 12:23:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00322 for ; Wed, 20 Sep 2000 16:57:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 16:57:42 +0200 (MEST) Received: (qmail 29748 invoked by uid 0); 20 Sep 2000 10:19:12 -0000 Received: from ml.egroups.com (208.50.144.77) by mx11.rz2.gmx.net with SMTP; 20 Sep 2000 10:19:12 -0000 X-eGroups-Return: sentto-1101623-763-969445148-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ml.egroups.com with NNFMP; 20 Sep 2000 10:19:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 10:19:08 -0000 Received: (qmail 21491 invoked from network); 20 Sep 2000 10:19:08 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 20 Sep 2000 10:19:08 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 20 Sep 2000 10:19:07 -0000 Received: from f-cpu.org (nas3-88.aub.club-internet.fr [195.36.145.88]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA09784 for ; Wed, 20 Sep 2000 12:19:04 +0200 (MET DST) Message-ID: <39C8902D.6B5E5640@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 12:23:41 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 04d455fc56a43ec8a782fb2c1d9ebc03 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

so i thought about Micahel's algorithm and i found one problem :
the long "carry chain" that has to propagate in order to invalida= te
the deepest entries.

So the mechanism is realistic and i'll try to make some VHDL
but it will only be behavioural, someone will have to optimize
the chain later for a real chip, or we'll be VERY slow when
there will be around 256 cache lines ...

So, this warning apart and memorized, this is a good start for
the ICache. The DCache will be similar to the ICache but
with some more complex management to include the "write-back" : Riepe's algo provides a useful information to create the
write-back queue :-)

Michael, wo hast du dieser Algo gefunden ?

mmm, i think that i'll do some C before i do VHDL.
i'll also try to find another VHDL book, since
Nicolas' will be given back to its owner soon.
have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Wed Sep 20 15:25:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01208 for ; Wed, 20 Sep 2000 20:47:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 20:47:16 +0200 (MEST) Received: (qmail 5198 invoked by uid 0); 20 Sep 2000 17:04:27 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 20 Sep 2000 17:04:27 -0000 X-eGroups-Return: sentto-1101623-765-969469456-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 20 Sep 2000 17:04:23 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 17:04:15 -0000 Received: (qmail 11439 invoked from network); 20 Sep 2000 17:04:15 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 20 Sep 2000 17:04:15 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.150) by mta3 with SMTP; 20 Sep 2000 17:04:12 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00587; Wed, 20 Sep 2000 15:25:45 +0200 Message-ID: <20000920152545.17890@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C8902D.6B5E5640@f-cpu.org>; from Yann Guidon on Wed, Sep 20, 2000 at 12:23:41PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 15:25:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ca04509d8abb9e46325de13efbe489e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Wed, Sep 20, 2000 at 12:23:41PM +0200, Yann Guidon wrote:

> so i thought about Micahel's algorithm and i found one problem :
> the long "carry chain" that has to propagate in order to invalidate
> the deepest entries.

That's right; we need a kind of CLA for a larger cache (I already
mentioned that in my proposal).  I was just too lazy (that's my third
name, in case you wondered ;) to draw that, too -- and the serial carry
is easier to grok at the first glance, IMHO.

> So the mechanism is realistic and i'll try to make some VHDL
> but it will only be behavioural, someone will have to optimize
> the chain later for a real chip, or we'll be VERY slow when
> there will be around 256 cache lines ...

A CLA for 256 lines should not require more than 3 or 4 gate delays.
Still faster than the f-cpu pipelines :)

> So, this warning apart and memorized, this is a good start for
> the ICache. The DCache will be similar to the ICache but
> with some more complex management to include the "write-back" :
> Riepe's algo provides a useful information to create the
> write-back queue :-)
>
> Michael, wo hast du dieser Algo gefunden ?

Nirgendwo :)  It's more or less an array-based implementation of a linked
list (horribly inefficient in software because you can't shift data
through an array in a single cycle), combined with content addressing
for fast parallel search.  I started playing with a list, but that
required 3 read/write buses for moving an item to the front in a single
step, so I replaced it with a `gated' FIFO with feedbacks from each stage
to the first element (1 bus).  Later I realized that the feedbacks aren't
needed at all -- we *know* which number to shift in, we just don't know
where it's currently stored.  That's where content-addressable memory
came to my mind... *klick* fiat lux!

The `move-to-front encoder' in bzip2 uses a similar algorithm, but
without content-addressing.  It does a (slow) serial search instead.
Too bad that the main part of bzip2 doesn't fit into an FPGA, too...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Wed Sep 20 15:48:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01211 for ; Wed, 20 Sep 2000 20:47:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 20:47:17 +0200 (MEST) Received: (qmail 19083 invoked by uid 0); 20 Sep 2000 17:05:27 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 20 Sep 2000 17:05:27 -0000 X-eGroups-Return: sentto-1101623-764-969469452-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 20 Sep 2000 17:04:36 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 17:04:11 -0000 Received: (qmail 18543 invoked from network); 20 Sep 2000 17:04:08 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 20 Sep 2000 17:04:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.150) by mta3 with SMTP; 20 Sep 2000 17:04:06 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00639; Wed, 20 Sep 2000 15:48:36 +0200 Message-ID: <20000920154836.00133@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C71283.C2FC31E3@f-cpu.org> <20000919201521.64083@thrai.stud.uni-hannover.de> <39C83FE6.CBADD819@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C83FE6.CBADD819@f-cpu.org>; from Yann Guidon on Wed, Sep 20, 2000 at 06:41:10AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 15:48:36 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] caching technics... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af1034bf35dd2394933b8b13d240bf32 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Wed, Sep 20, 2000 at 06:41:10AM +0200, Yann Guidon wrote:

> i've looked a bit at P&H and they really seem to like the direct mapped
> caches. beuark.

Quick-and-dirty I-cache line prototype:

                 write bus (data, addr + valid bit)
                    |  |
                    |  |
      +-+-------+---------//---------+
      |V|ADDRESS|        DATA        |
      +-+-------+---------//---------+
      |   | |                  |  |
      \___| |____              |  |
           | |    \             |  |
         +-----+   \+---+       |  |
         | P=Q |----| & |-------|  |--- GOTCHA!
         +-----+    +---+       |  |
           | |                  |  |
           | |                  |  |
      read bus (addr)       read bus (data)

Did I mention that I love content-addressable memory? ;)
I don't know how well this works in the D-cache, however.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Wed Sep 20 19:53:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01217 for ; Wed, 20 Sep 2000 20:47:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Sep 2000 20:47:19 +0200 (MEST) Received: (qmail 28322 invoked by uid 0); 20 Sep 2000 17:49:41 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 20 Sep 2000 17:49:41 -0000 X-eGroups-Return: sentto-1101623-766-969472166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 20 Sep 2000 17:49:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 17:49:25 -0000 Received: (qmail 14900 invoked from network); 20 Sep 2000 17:49:23 -0000 Received: from unknown (10.1.10.26) by 10.1.10.35 with QMQP; 20 Sep 2000 17:49:23 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 20 Sep 2000 17:49:17 -0000 Received: from f-cpu.org (nas3-73.aub.club-internet.fr [195.36.145.73]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA02703 for ; Wed, 20 Sep 2000 19:49:14 +0200 (MET DST) Message-ID: <39C8F9AE.1B892761@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 19:53:50 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (c) stack LRU algo Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9fc078f262962800aaff2fefce4a8fcd Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

ok, now i remember that Riepe's LRU algo is used
for example in the TMS320C80 for example. they limited
it to a 4-lines depth, probably because of the "carry chain".

so here is some code for a C simulator.
warning : i haven't compiled it yet, it's just a first attempt.

#define DEGREE 5 /* 32 cache lines */
#define MAX_LINES  (1>>DEGREE)

long int Iaddress_read, Iaddress_write, Iaddress_tags[MAX_LINES]; /* bit 0 = of the address is used for the valid bit */
int i, Icache_hit, Icache_hit_line, Icache_write_line, ILRUtags[MAX_LINES],= temp1, temp2;
unsigned char Icache[MAX_LINES][32], IcacheIn[32], IcacheOut[32];

void reset_LRU() {
  int i=3D0;
  do {
    ILRUtags[i]=3Di;
    Iaddress_tags[i]=3D0;
  }
  while (i<MAX_LINES);
}

/* no input parameter, the variables are externally set before calling this= : */
void read_Icache_line () {
/* reset, just in case : */
  Icache_hit=3D0;
  Icache_hit_line=3D0;

/* 1 : seach in the address tags : */
  while ((Iaddress_read & -32)^(Iaddress_tags[Icache_hit_line] &am= p; -32)){ /* xor=3D1 -> different */
/* oops, */
     Icache_hit_line++;
     if (Icache_hit_line >=3D MAX_LINES)
       return;
  }
  Icache_hit=3D1; /* bingo. */
  memcpy(ICache[Icache_hit_line], IcacheOut, 32); /* OOOOPsss,
       check for the correct calling conventi= on !!! */

/* 2 : in the hardware, we'll have to encode the parallel comparison's resu= lt
            into a n= ormal integer : we get a bit vector instead of an integer.
            With the= sequential C algorithm, it's not necessary. */

/*
We could split the algorithm at this point.
*/

/* 3 : LRU update */
  i=3D0;
  temp2=3DIcache_hit_line;
  do {
    temp1=3DILRUtags[i];
    ILRUtags[i]=3Dtemp2;
    i++;
    temp2=3Dtemp1;
  } while (temp1 !=3D Icache_hit_line);
/* Stop condition is simplified because we're
   sure to meet the desired value at least once.
   This is a pretty good piece of C code
   but it's far from a HDL description. */
}

void write_Icache_line () {
/* 1: check the line that must be written */
  Icache_write_line =3D ILRUtags[MAX_LINES-1];

/* 2 : data move */
  Iaddress_tags[Icache_write_line]=3D(Iaddress_write & -32) | 1;   memcpy(Icache[Icache_write_line],IcacheOut,32); /* possibly wrong or= der */

/* 3 : LRU update (circular move) */
  i=3DMAX_LINES-1;
  j=3Di-1;
  do
    ILRUtags[i--]=3DILRUtags[j--];
  while (i);
  ILRUtags[0]=3DIcache_write_line;
}


In the HW, the LRU tags and the cache lines + address tags are
separated, the clock cycle can be split, and some side effects
should be taken care of.

The "carry chain" should be broken with a tree-like mechanism
but i still wonder how to do it.

I'll try to extend this stuff naturally to a modifiable DCache
but in the same time i'm expecting as much comments as possible.
I'll compile this crap and make some testbenches, i'll publish as
soon as possible.

I'll make some VHDL when the VHDL code will be ok and a simulator
will be ready/chosen/compiled/installed. i'll first try with PICA
(look at the opencollector database for the URL). I've bought two
little french books about VHDL and i hope that it will replace
nicolas' book.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Thu Sep 21 00:32:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00295 for ; Thu, 21 Sep 2000 17:14:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Sep 2000 17:14:09 +0200 (MEST) Received: (qmail 30977 invoked by uid 0); 20 Sep 2000 22:37:08 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 20 Sep 2000 22:37:08 -0000 X-eGroups-Return: sentto-1101623-768-969489130-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 20 Sep 2000 22:32:27 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 22:32:09 -0000 Received: (qmail 29545 invoked from network); 20 Sep 2000 22:32:09 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 20 Sep 2000 22:32:09 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta3 with SMTP; 20 Sep 2000 22:32:08 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02163; Thu, 21 Sep 2000 00:32:04 +0200 Message-ID: <20000921003204.26719@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C91D20.751BFD9B@f-cpu.org>; from Yann Guidon on Wed, Sep 20, 2000 at 10:25:04PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 00:32:04 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 81601fc5612a53917261a47562fea6f2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Wed, Sep 20, 2000 at 10:25:04PM +0200, Yann Guidon wrote:

> > A CLA for 256 lines should not require more than 3 or 4 gate delays.
> > Still faster than the f-cpu pipelines :)
> 3 or 4 gates delay leaves nothing for the remaining tasks.
> a 64-bit OR gate is half of the pipeline granularity.

Hmm... the comparator and the multiplexer need some time, too.  But
they don't need 64 bits.

> what really bothers me is how we can lookahead. what smart idea
> we can invent to predict the tree's behaviour. that's really tricky.
> now i understand why it's limited to 4 or 8 lines in practice.

Time to draw another picture.  Later...

> > > Michael, wo hast du dieser Algo gefunden ?
> > Nirgendwo :)  It's more or less an array-based implementation of a linked
> > list (horribly inefficient in software because you can't shift data
> > through an array in a single cycle), combined with content addressing
> > for fast parallel search.
>
> I've remarked that "content addressing" doesn't directly work for this case.
> i mean : when you have looked up what cache line contains the item you search,
> you have to lookup all the items in the queue which are more recent than the
> line. that's two lookups, two cycles. fortunately, one can easily split this up.

I guess doing both the cache line lookup and the LRU update in one cycle
would be *very* hard.

[...]
> > Too bad that the main part of bzip2 doesn't fit into an FPGA, too...
> that's just a matter of how smart one can be to "break up" the algorithm...
> it took me almost a year to breakup the FHP-3 collision operator :-)

Sorting 1 million strings with 1 million characters in them is beyond
the capabilities of today's FPGAs :(

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Rares Marian Thu Sep 21 04:47:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00301 for ; Thu, 21 Sep 2000 17:14:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Sep 2000 17:14:11 +0200 (MEST) Received: (qmail 15871 invoked by uid 0); 21 Sep 2000 02:52:23 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 21 Sep 2000 02:52:23 -0000 X-eGroups-Return: sentto-1101623-769-969504474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 21 Sep 2000 02:48:00 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@e-groups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 02:47:53 -0000 Received: (qmail 27153 invoked from network); 21 Sep 2000 02:47:53 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 21 Sep 2000 02:47:53 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 21 Sep 2000 02:47:51 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 16D1312A46A for ; Wed, 20 Sep 2000 22:47:27 -0400 (EDT) To: f-cpu@egroups.com Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 22:47:26 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] 1 bit loopback adder Content-Type: multipart/mixed; boundary="-679339033-1722169788-969504446=:3623" X-UIDL: 767c6658914fdbf5f8f6ad9305c2cf27 Status: R X-Status: N ---679339033-1722169788-969504446=:3623 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
eGroups My Groups | f-cpu Main Page | Start a new group!

Well here it is finally.  It needs a little hacking but it's done and at
least 3x as simple as I'd hoped.  I'd say it goes as fast as a traditional
1-bit full adder.

Possibilities:

1.  1 bit adder shared on the whole chip.  Scheduling down to the bit
level.  No execution unit related stall can last longer than the time it
takes to process a 1 bit add.  It would just require a carry bit that is
loaded from the right addends. Something about context switching at the
bit level seems a bit strange to me, however.  Anyway I got the craziest
possible idea out of the way.

2. 63 registers broken up into 21 register clusters (src1, src2,
destination).  One 1-bit loopback adder for each cluster.  It's so compact
I think multiple units are not a stretch of real possibilities.

I'm still working on the register layout but I hope this keeps you all
busy while I get that done.

I'm particularly proud that I managed to avoid costly XORs (aka (A nand
B) and (A or B)).

Okay take it apart now :)

Rares

 ---679339033-1722169788-969504446=:3623 Content-Type: IMAGE/png; name="1bitalu.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="1bitalu.png" iVBORw0KGgoAAAANSUhEUgAAAt8AAAHMCAIAAACCwlM7AAAAA3NCSVQICAjb 4U/gAAAgAElEQVR4nOzdd3wTdeMH8O8laZoUOihbRhdTyhDwQVAoygZ5WAJF QFlFKCCgLH1YQtllI5S9BNkqorJ8GILKkL2hA8oulDYd6Uru98c95hczrpfk cnfJfd5/8KLpN3ffXJO7T77rKJqmCQAAAIBkKMSuAAAAAMA/IJ0AAACAtCCd AAAAgLQgnQAAAIC0IJ0AAACAtCCdAAAAgLQgnQAAAIC0IJ0AAACAtCCdAAAA gLQgnQAAAIC0IJ0AAACAtKjErgAAAHgAiqLMf3ToHm0Wz3ViC9Jk/brMXxTz Wy4v063Hx3zjrmyTr+1w3Z0XvD8AAMB19q61Nq+dxIXrLseNOHHNFiwGsb8u 8+Nmb+/FHhnzTXHfgnU8Knabgm3HocJoOwEAALtMVxHryxVFFfP9luXbtulX xW5EgthbESiK4pg82DfiXN2sn27auBPHnK/tOMHz3hYAAOBuxfbjFNttYTPW OF3G0UuVc8/ivmX2jXPsBOEY7xxKEjRNs9SQS55wfTuOdmnZLIlRsQAAYBdN 0zYvHuydPlwu4cX+tlhOtFK4iN/XJXx44r5HvrbjNKQTAACwzcWLkBPXQo8g /T4Hvmro3HbYk6sJexML0gkAAPDJof6IYosVe6mz/pWbunUcilAiJhhxowlf MCoWAAA8j1jNLdyv2U6MPHWdRKIJM2yFZXhKsQkS6QRAUDRNJycni10LkAuF QhEaGirKrj2rs0YUOEQsMGcHQFB5eXlarVbsWoBcBAQEXLx40YmMwqVzxF4Z 5y66Du3L/EeWX/GL3y3zPl+Jr+rx+DLZ3yHsu0DbCYBAmFaTwsLC8PBwXjZo NBozMjLy8/MrVqzIywbB+2i12oiIiICAgMzMTIF3ja++LDjO/fEOFv07HNMP 2k4ABMK0mmg0Gr1e7+Km0tPTFy1atHz5cp1ORwi5fPlyvXr1+KgjeBudThcY GOhEOnG97YTfi0uxbSfETlOK++rg4na4bMrT205sbo3j9jFnB8CTpKenT548 OSwsbNasWTqdrn379n/88QeiCUiQOwZ7mtaoJWaXN+vrnFu/dfP1umTVNGC+ vCzh9trRswPgGSzaS9q3bz9t2rS33npL7HoBWDJfZlRgbt2vE6/LlbXevWPM rNNvBqQTAKlDLgEP5dD9XFxpSzDNX3V6Cw7hWFuOdyNiea53sPjrcDwaSCcA 0oVcAh7K9I2Z+50CHbrki9UtwvF1sd9nh+NaIDKHdAIgRcglwFFaWlrZsmV5 2ZS9RVeJrVGNNn80L2Z+ISe2LtLF3mjQAsc+AncHF/bXxfH+f+aFbR5b63E2 1tu0eTTsHSKOWcqV7bAwHTTuT0c6AZCWly9fTp06dcuWLdnZ2YSQFi1ajB49 ukGDBoSQpKQksWsHkjN79uxOnTp169ZN7IrYYJ4nWIKFoxc8e/elE6zJgcvr 4nKbQOvwweW5nsiJPw1mFAMIpNgZxXq9Pi4ubsmSJbm5uQLXDTwXRVGVK1e+ e/eur6+v9W+dnlHML5sXJy+4+rgeLBxtQPJQTvTHoe0EQCq0Wm1UVNTs2bOZ HxUKRVBQUEBAgEKBmf9gW2Zm5suXL1NTU5ctWzZ+/Hixq2OXt150XX9d3npk zDk3VAhtJwAC4bIam16v9/PzU6vVTZs2PXHiBCEkODh47Nixn376aUBAgICV BQ9A0/Trr79+69YtQoi/v/+9e/fKlStnUUYibScgZ86lE3wnA5AchUJx/Pjx Y8eORUVFpaenT5kyxbT8mthVAwk5dOjQrVu3mKa1rKysyZMni10jAEtOz7FC OgGQqJYtW5pnFPMlYsWuGkjCsmXLCCHBwcGEEJVKtWHDhsuXL4tdKZA1yor1 4xw3hXQCIGnIKGDT7du3Dx486OfnV6lSJUJIr169DAbD2LFjxa4XAD+QTgA8 ADIKWFixYgVN0/369StdujQhpFevXmXKlDl27Nh3330ndtVAvmgOOG4K6QTA Y9jLKFlZWWJXDQSVmZm5adMmiqJMw6WNRuNXX31FCBk/fnx+fr7YFQRwFdIJ gIexyCjTpk17+PCh2JUCQW3YsCE7O/u9996rU6cOk050Ot3QoUPr1KmTmJjI jEcB8GhIJwAeyZRRpk+fXrt2bbGrA8IxGo0rVqwghIwePZoQYkonKpVq0aJF hJC4uLjnz5+LW0ny90BIsWsBngrpBMCDtWzZEvNI5ebHH39MSkqKiIjo1KkT MUsnhJC2bdu+//77Op1OCu8KLKYFrkA6AQDwJEzHzciRI5mVTgIDA8nf6YQQ Eh8f7+Pjg9nF4OmQTgAAPMbVq1ePHTvm7+8/cOBA5hHzthNCSM2aNUeOHInZ xeDpkE4AADzG8uXLaZoeMGAA02RC/k4n5gvVT5kyxbnZxSxLZpkeZF9Wy4lF twBsQjoBAPAML1++/OabbxQKxciRI00PWrSdEEJKlSrlxOxiiqLMF6Wwee9c 9jLsvwVwCNIJAIBnWLt2rV6vb9++fY0aNUwPWqcTQohpdvG6des4bpzLIFaW Mkw0cXSDAPYgnQAAeACappcvX04I+fTTT80ft5lOVCrV4sWLR4wY8eGHH3Lc vs3bowCIRSV2BQAAoHgURZ0/fz4+Pr5t27bmj1vM2TFp06ZNmzZtTI8bjcaU lJSwsDB740UsmjoQUEBcSCcAAJ6hYsWKCxcutHgwMDCwcuXKISEhFo/r9fqf f/55y5YthJCsrCylUsk8HhQUFB4e3rBhw27durVu3VqtVgtQcwBHWeZlAHCT vLw8rVar0Wj0er29Mnq93s/Pj70MALusrKxRo0Zt3brVaDSaHqQoKiQk5P79 ++bnfKVSOXz48Pj4eI1GY/4403Bi3ZrC/oj1j9YbAeAI404AALzHgQMHwsLC Nm/eTAhp1qzZggULLl68+OrVK6PRmJycbDQaX7x4ce7cuRkzZjRs2NBgMKxY sSIiIuLkyZPmg05MM3RM/Tum6cSmHVk/wszTsd6IgK8evAfaTgAEgrYTcLfv v/++R48eRqPxnXfeWb169euvv85e/syZM0OHDr1y5Yqvr++xY8eaNm0qTD0B ioW2EwAAb3Dz5s1+/foZjcYvvvjit99+KzaaEEKaNGly6dKlIUOG5Ofnd+nS 5fHjxwLUE4ALjIoFAOABTdMpKSlKpVKhUFj/a/6jaYAqvxYtWpSTk9O1a9fZ s2dzfxZFUQkJCTdu3Pj999/Xrl07bdo0d9QNwFFIJwAAPMjJyQkPD+dY2Dyv 2Ewz9pINS4HTp08TQpy4O7FSqZwwYULXrl03btxI07QrdXDiuSqVKiwszNE6 g9fDuBMAgWDciRczGo03btzo2LEjRVFGo9FgMJj+tfjRYDAYDAb31SQvL8/X 19fRZ926dat27druqE+xAgMDMzIyRNk1SBnaTgAAXJWTk1O3bt2SJUtmZWVx KW+eWqzjS7H5xuavRowYcefOnZMnT7Zp08bR+v/xxx+EkNq1a/fu3du5vTtR ID8/32g0lipVyuHDDTKAdAIAIDSmv0Ol4vMM3K1bt3nz5k2YMOHUqVMlSpTg /sTnz58zdw2MjY01v7+gW2VnZ/v7+5csWTIpKUmYPYJnwZwdAABvMGnSpJo1 a166dKlLly7WC9vb8+LFi06dOt2/f79Zs2YxMTFuraE5JpkVFhYKtkfwLEgn AADeICgo6McffwwKCvr1118rVaq0bt26oqIilvIFBQXLli2rXLny+fPnK1eu /N133zkxYMVpPj4+BOkE7MOoWACBYFSsF8vKygoICOA+7sR9UlJSRo4c+dNP PxFClEpl69at27ZtW7Vq1YoVK5YrV+7p06dPnjx58ODBgQMHfvvtN6PRSFFU v3794uPjy5UrJ3BVlUolMwBFocD3ZLCEdAIgEKQTLyaddMJYsWLFvn37Tpw4 YX6rHQtKpbJdu3bjxo179913haybiUajyc/Pd26SEXg9pBMAgSCdeDGppRNG bm7uqlWrkpKSnjx58uTJk7S0tAoVKlSsWDE0NLRx48Zdu3YVNxb4+/tnZ2dn ZWWVLFlSxGqANGHODgCAe1ncKs/mr5hb6Nks4zQ/P7/PP/+cl025A4aeAAuk EwAANzLdrdfmj+Z3AzY9blHGW2HaDrDAWCQAAHexzhnmbSQWj9v8vxdj2k7Y JxaBbCGdAACACNCzAyyQTgAAQARIJ8AC6QQAAESAdAIskE4AANzFepSJTEa8 coFRscACc3YAAFySmprKEjgsAoq9GcUsZbwVRsUCC6QTAADHGI3GgwcP7tu3 78qVK5cuXTJ9+8/JyWnUqFGrVq1atWrVsmVL01pn7NlFiBpLEnp2gAXSCQAA V0VFRXPmzImPjze/CXBwcDAh5NWrVzRNX7hw4cKFCwsWLKhateqUKVMGDBjA 9F+ANaQTYIFxJwAAnJw7d65u3bpTp07V6XSvvfba8uXLT506lZaW9vLly5cv XxqNRp1Od+TIkUmTJtWuXfvBgwcxMTF16tR58OCB2BWXKKQTYIF0AgBQvJ07 dzZp0uTWrVtVq1bdv3//o0ePRo4c+fbbb5cpU8ZUxt/fv3Xr1nPmzLl27dqO HTtq1Khx586dBg0anDp1SsSaSxZGxQILpBMAgGKcO3du4MCBNE0PGjTo7t27 nTt3Zi+vUCh69+59+fLlHj16vHr1qmXLlleuXBGmqh4Eo2KBBdIJAACbwsLC bt266fX6YcOGrV+/Xq1Wc3yiRqPZtWtXt27dDAbDqFGj5DwA1ib07AALpBMA ADY7dux49OhR3bp1V6xY4ehzFQrFxo0by5Urd/Lkyb1797qjep4L6QRYIJ0A ALDZtGkTIWTUqFFKpdKJpwcGBk6YMIEQ8vPPP/NbMU+HdAIskE4AANj89ddf hJAuXbo4vYWmTZsSQi5dusRbnbwC0gmwQDoBAI9kNBqTkpJSUlKE2Z1paTUn VK5cmRDy8OFD/qrjDZg5OxgVCzZhmSAA8Eh6vT4iIsLPz+/q1atu3RGzxnxa WlpgYKBzW7h58yYhJCwsLCkpic+auUyhUISGhoq1d7SdAAukEwDwYLm5uRER EQLsaNu2bdOmTXPuuQcPHiSEnD17VpiqcleyZMlLly6JVSukE2CBdAIAHoyi qLCwMLfuQq/XP3nyZOXKlSNHjixdurSjT799+/bKlSsJIZUqVXKle4h3RqMx JSWlQYMGWVlZolQA6QRYIJ0AgAfz8/NLTEx0916ioqJOnjzZqVOn48ePazQa 7k988eLFBx98UFBQEBMTs2bNGvfV0Al6vd7Pz89oNIpVAaQTYIFRsQAAxdiz Z09oaOiZM2eaN2/ODCLh4vbt2w0aNLh27Vq5cuVmz57t1ho6gZkgbTAYxKoA RsUCC6QTAIBilC1b9scffyxVqtT58+fr1as3ceLE9PR0lvKpqakxMTGRkZGP Hj168803r127Zn47HolQKBRE1HSCthNggZ4dAIDiRUZGpqSkjB07dsOGDfPn z1+wYEF0dHStWrVq1qxZp06dgoKCrKysV69enTlz5tdff/3rr7+MRqNSqfzy yy+nT5/OXIalRvS2E6QTYOFYOmGmw4WHh7unMgAA0hUQELB+/frBgwevXLly z5493377rb2SFEX16NFj4cKFISEhQtbQIRRFKRQKo9FoNBqZdhSBIZ0AC8fS CTPxDPeyAgDZatasWbNmzTZs2LB79+7r16/funXr9u3bvr6+/v7+wcHBNWrU aNWqVVRUlKSm59ijVCqNRqPBYEA6AalBz46XYBaMIsiOAIJQq9V9+/YVuxau UiqVhYWFBoNBlL4npBNggXQiHFOAMEGSAAARiTv0BHN2gAXSCQCATDmRTsy/ ZVl8vzJvweXSmou2E2CBdCIc80+pdTuKiJjKoCEHQG4cTScURVmcx8x/ZP5P UZT54xZlzCGdAAusdwIAIFNMOuG4XKx1zjBvI7F43Ob/LSCdAAu0nXgJtHwA gKPEXZAN6QRYoO0EAECmMCoWJAvpBABApsRNJ2g7ARbC9exYdE861BNRbNcm AAA4yqF0wowyYRkV6yikE2DBZzqxt56HzWzB8W3NMrel2JkmTmQasWKQo/u1 d1hcyXzs04iQBQG8j6NtJxbDYO3NKGYpYw7pBFi4ve3E5qx35sFiAwrHj4Gn XzjtxQJM9JUh00dD7IqALDjRs8NyRnL0ZIVxJ8CCz3RiM39Y/4rYn4dmjn0x H/NWGXsBxbwMx4+N+Rx97s9yBcvLZHl19go7RPgXCwCSgnEnIFluHxVL03Sx 0cEax7vGuHhBZVYNcmULLjLFAnuHiP0oAQC4QgozirOzs0XZO0ice3t2XEwP 3J/uuf07xVabaWfy3BcIAJIlVtvJqlWr/vzzz7NnzxJCrl27plar33jjjbp1 6/bv3z8qKkrgyoA0SXFGsXN9MewFih1d63QFAAA8lPDp5ObNm23bto2Njd2y ZcutW7cIIVWqVCksLDx79uz69evffffdPn36PHz4ULD6gGRJMZ0IQwrdJQ4l MClUGAC8icDpZOvWrZGRkUeOHClRosSSJUt+//33goKCBw8e5OXlnThxYu7c uT4+Pjt27AgNDT18+LAwVQLJkm46oTgTu6YAAB7JofvsuOjSpUtDhw41Go0f ffTRw4cPR48e3bRpU2boia+vb4sWLSZOnJiSktKxY0eDwdC3b9/U1FQBagWS Jd10wiPrtgeL4ag2fyV0LQEAhCVY24lOp+vVq1deXt4nn3yyefPmoKAgm8Uq Vqz4448/duzY8cWLF9HR0ZjOI2fSvQsg8gGANNE0nZycLHYtiF6vJ4QYjcak pCSx6+KpmMt/ampq+fLl3bqjjRs33r17t169ekuXLmUvqVAotm7dWr9+/d9/ /339+vVt27Z1a8XM9xsaGirMvoALx2aCcG9X4FLSXhl3tF5YbNP8R4vZy8K0 nTi6F44L4zpXbTQXCSMvL0+r1Wo0GuayylJGq9Xm5uYKWTfuaJq+ceNGZGSk 2BUBz7N+/fpBgwZxKTlt2rQZM2a4uz7mAgMDr169WqVKFSF3Ciyk23bC7xxa 83m5Fhdj66XhBLtOO7ScP9IDSIFer4+MjKQoKiwsTNyaME04UqiJ53ry5Ile r69YsaJWq3Xrjh48eFBUVNS0aVOO5ZmSGo3mtddec2e9/sdgMNy/f/+NN954 8eKFALsDLqSYTrisJOsmGGMLwIVWq01MTBS3Djk5OSVLlvTz8xO9Jp6rbdu2 R44c2bx5c5s2bdy3l/z8fK1WS1FUtWrVOD4lIiKCEBIUFCTMH/f58+fly5dn RuGAREh6VCz3rOBiqhBxyi73Ff1FJ52aAAAvhFkr1tfX9/XXX6dp+q+//uL4 lAsXLhBCGjZs6M56/T/mCCCdSIpE04nFABEWpknFHK+dEuwl4bJSnFj3STb9 CtEEwPsINmenWbNmhJBTp05xLM+UZJ4lAOYIMHclBIngM51Yr0Fic0kSe2Xs Df6wd2m0eJzjorHFcmsOsHilLK/RZjGLjbAccHtH1SaWLIhcAuDFBEsn7777 LiFk7ty5XFYxuXjx4rp16wghgk3YQduJBEm07YRhcdNjexdde3fR47JZ9gcF YO812iwgQDX4OsgAIH2CpZPo6OhOnTq9fPmye/fuBQUFLCUzMzO7d++el5c3 fPjwN998090VYxQVFRE76SQ7O1uY1erAAp/phLbPiWLmhdl352gNnfstL2y+ XkdfO8sB5HhU7dWNZV+cXyIAeAzB1oqlKGrz5s1Vq1Y9f/58gwYNjhw5YrPY zp0769atm5KS0rBhw0WLFrm7ViYsbSdLlizZtGmTYDUBE8/oZpPD1VEKr1EK dQAAwQh5n53SpUv/8MMP7dq1Y24E2L179wYNGtStW7datWo3b968evXq0aNH //jjD0JI1apV9+zZo9FoBKgVw146efHixYIFC0qXLv3xxx+j30dgnpFOAACA dwLfBbBBgwapqalLliyJi4vbt2/fvn37LAqULVt29uzZgwYNYiYTCcbeqNhZ s2bpdDqdTrdr164+ffoIWSVAOgEAkCmB0wkhRK1WT5gwoX///keOHLl27drV q1cTExNr164dGRlZt27d9u3b27sFj1vZHHfy/PnztWvXMv+fM2dOdHQ0pggI CekEAECmhE8njIoVK3700UcC75SFzZ6duXPn5uTkMI9fvXp1//79Xbp0Ead+ siTpOTsAAOA+YqUTqbFOJw8fPly1ahXTwRQQEEAImTVrlljVkyekEwAAmRJm rVjpsx53EhcXl5eX16FDB0JIUFBQ+fLlz507d/jwYdGqKD9IJwAAMoW2E4ZF 20lSUtKGDRuUSuWoUaMIIT4+Pp999hlB84mwkE4AQIqwTrEAkE4YFqNiv/rq q8LCwv79+1epUoUQolKphg8fHhwcfPLkyd9++03MisoJ0gkASBFW3xGAYKux SZx528nNmze3bdumVqunTZtmetzf3//TTz8laD4RENIJAIBMoe2EYZ5Opk6d ajAYhgwZEhoayrSpMONRRo0a5e/vf+jQofPnz4tbW5lAOgEAkCmkE4ZpVOzF ixf37t2r1Wr/85//kL97fJh0EhwcPHz4cELI7NmzRa2sXCCdAAA/WO6MbXqQ /e7ZDt1bG1yHdMIwjTuZMmUKTdOxsbGvvfYa+Wc6IYR89tlnWq32hx9+uHbt moi1lQmkEwDgAUVR5veetIgXzCAS9jLsvwV3QDphMEcgMzPzp59+8vf3nzRp kvnjptGy5cuXHzJkiNFonDNnjlhVlQ+kEwDgAZdBrCxlmGji6AbBRUgnDOYI 3Lx5kxAyZsyYMmXKMI9btJ0QQsaPH69Wq3fu3Hnv3j0xaiojSCcAwAPqn8Su DnCCdMJgjkBaWlpwcDCztAnDOp1UqVKlf//+BoNh7ty5wtdTVpBOAMBVFp0y aPbwFFgrlsGkEELIuHHjzG9DaJ1OCCGTJk1SKpVbt25NTU0VspJyg3QCACBT aDth6PV6QohWq2UWNTGxeXfAatWq9e7d22AwXLlyRchKyg3SCQDwzImeHZuD ZPmrEdiGdMJgjkP37t1LlChh/rjNthNCyOzZszMzMzt16iRYDWXI8qADADjK IlswPzKPmGbrkH8OfbV+xN5G0E/kPlgrlsHkM41GY/G4vXQSEhIiTMXkDOkE AHjAPuPGOmHYzByYtiMwtJ0wrO9RzLCXTkAA6NkBAJAppBOGxV0ATWyOOwFh IJ0AAMgU0gnDXgpB24mIkE4AAGQK6YSBdCJBSCcAADKFdMLAuBMJ4u2gWwy2 t/kr8zH5GO8G4NGYJSIIIWq1Gh3zHgrphIFxJxLETzqxmPVn8aNpSqHFfEIE FADPcurUqcOHDxNCcnNz/fz8mAf9/PxatGgRFRXVoUOH+vXri1pBcAzWimWg Z0eCeOjZsXn7LpsrKVlHFgDwCDdu3Gjfvn3z5s1nzpxJCKEoSqvVarVajUaT m5t78ODBL774okGDBh988EFycrLYlQWu0HbCQDqRIIw7AYBiLFy4sG7duocO HfLx8YmJidm7d29GRkZubm5ubq5er09PT//2228HDhyoUqn27t1bvXr1devW iV1l4ATphIF0IkEOpxMsLw0gK+vXrx83bhxFUbGxsU+ePFmzZk337t0DAgJM BUqVKhUdHb1hw4b79+9/9NFHRqPxk08++e6770SsM3CEtWIZ9lIIxp2ICG0n AGDXxYsXhw0bRghZs2bN119/Xbp0aZbCr7322ubNm+fOnWs0Gvv06XPnzh2h qglOQtsJA20nEsTDQWdGmbCMigUAgdE0nZKSorCDoih7v7LYzpo1a4qKimJj YwcNGsRx1xMmTDh+/Pgvv/yydetWZpAKSBbSCQPpRIL4OejWt+8y/63pVyxl AIBH+fn54eHhTjzRIqzk5eURQj766COHNjJixIhffvllyZIlBw8etBeDis1J xRZmrigFBQUTJ07kd8v8FlapVGFhYU78LQSAdMJAOpEg3g46S9pAEAEQGE3T YWFhRlY0Tdv7lcXW6tWr59Dea9asSQjJzs4+f/48by/JjsLCwvnz57t7L67w 8/O7fv16aGio2BWxAemEYW81Now7EZHD6QRRA8DdXP+UabXapKQkJ55oEVNa tmx57ty548ePd+jQgftG/vjjD0JI8+bNFy1a5HRCKrZwXl7exIkT1Wr1zJkz +d0yj4UNBkNiYmK9evV0Op0Tfw53Qzph2FuNDW0nIsJBB/A2NE0/ePAgLy+P acNwCNMfYfqxTZs2586di4uLa926tY+PD5ct6PX6BQsWEEK6devWuHFjRyvA XU5OzsSJE318fCZMmOC+vbgoKyvLfH6T1CCdMNCzI0HOzNnJysrKzc3lvSoA wIuioqLQ0NC6deu6vqkRI0ZUrFjx999/Hzp0KJcWHaPR+OGHH169ejUiImLA gAGuVwDcCumEgXQiQcWnk9zc3JUrV/bu3ds0sCsgIKBEiRJhYWHR0dErV65E UgGQFB8fH4VCUVhYaHR5HYvXXntt//79fn5+mzZtioyMPHToEEthZim277// vlSpUj/99FOpUqVc3Du4G9NO5vr7xNOx9+xg3Iko2CLhnTt35s+fv3Xr1oKC AuYRjUbDtO4WFBSkpKSkpKTs3Llz7Nix/fv3nzBhQo0aNYSoMgAUx9fXV6/X 5+fna7VaFzfVuHHjgwcP9u7dm1nMPjw8vF27du3atStTpgxTIDk5+cSJE4cO HUpNTSWEhISE7N2714lOJRAe2k4Y7KNi0XYiCrsHfc2aNSNHjiwsLKQoaujQ oU2aNGnSpMnrr7/OzAqmafr69etnz579888/161bt379+i1btnz99dcxMTEC Vh4AbFOr1Xq9vqCgwPV0Qghp3rx5SkrKsmXLZs2alZSUtGrVqlWrVlkXK1u2 7IwZM2JiYvBd01MgnTDQsyNBNg660WgcN27c4sWLCSEDBw6cPXt2hQoVLMpQ FBUZGRkZGTlo0KAZM4Wbe24AACAASURBVGZ8+eWXGzduHDp06M2bN+Pj4xVW azoBgJB8fX0JIfn5+XxtUK1Wjxs3bsyYMcwUnuPHj+fk5DC/CgwMfO+996Ki oho2bIjPvmdBOmEgnUiQjYO+evXqxYsXq9Xq1atXcxnXVqFChQ0bNrRo0eKT Tz5ZvHhxjRo1mKWvAUAsvKcThkqlatq0adOmTb/44gt+twyiQDphsKcTtAWK wvKLzpMnT5jzztatWx0acj9gwIAtW7YQQr744osnT57wV0MAcJharSaEmEaM AdiEdMJgvwsg2k5EYZlOFi9enJmZ2blz5169ejm6rd69e7///vsZGRlLlixx vWZJSUnJycmubwdAhtzUdgJeBumEgZ4dCbJMJ2fPniWEDB8+3LnNMU88d+6c i9WiaToiIqJatWoubgdAnpBOgAukEwbSiQT976CbFr1m7ovxxhtvOLc55oln z551bhVtE6yXD/LE1zuf6dlBOgF2SCcMjDuRIBUhJDEx0aKVIisry3qeDhfZ 2dmEkJycnIiICFeqZX43YwBwFNN2gnEnwA7phIFxJxKkommaiSbM/dafPn2a m5t79uzZ6tWrO7E5pmPIz8/PuXBjQlFUYmKiK1sAkDP07AAXWCuWgZ4dCVIx LckKhYJJA4sXL/7ss89mzZrVs2dPpnGYu/z8/FmzZhFC4uLixo4d60q1aJrG wgkATkM6AS7QdsJAOpEgBZNOTD0psbGxtWrVunnz5siRIx3d1siRI2/evFm7 du3Y2FieqwkAjsCMYuAC6YSBcScSZJlOfH19ExISCCFr167t378/x+9eeXl5 /fv3X7duHSEkISGB+d4GAGJB2wlwgXTCsJdOMO5ERJbphBASFRW1f/9+f3// b775JjIyct26dSznuPz8/LVr19atW/ebb77x9/f/8ccfW7RoIUTFAcA+pBPg AumEYa8HBz07IlJZpxNCSOfOnS9evNi+fft79+7FxMRMnjz5vffea9KkSaNG jZh7FBcVFZ0/f/7MmTP//e9/nz17RgipVq3awYMHXZyqAwC8wIxi4ALphIFx JxJkO50QQiIiIm7durV79+558+ZdunTp22+//fbbb21uokGDBhMnTuzZsyc6 5wAkwjSjmKZpb11zWa/Xi10Fj5Sfn1/4t7S0NIJ0gnEnkmQ3nRBClEpldHR0 dHT0rVu3fvvtt7Nnz16/fp2Ze8bco/hf//pX8+bNa9WqJXStAYCVqWcnLy/P i1s0KYoKCwsTuxacGI3GpKSkQs4KCgq4F+bOOogoFIrQ0FAxDomEYNyJBP3/ jGKWQrVq1apVq1ZMTIxQtQIAl5jSCUVRzFJGXsnPz+/q1ati14KTrKws5xaR 4p2vr6+PmaCgoL/++kvsSokM404kiK3tBAA8lGlGsUajwcKGUqBWq6tVq+bj ILVa7ehT2KGTwiaMO5EglamnRuyaAABvMGdHarRa7d27d8WuBdiGcScSZGNG MQB4OqQTAO4w7kSCkE4AvBBmFANwZ6+NBD07IkI6AfBCuEcxAHf22kiQTkSE dALghdCzA8Adxp1IENIJgBdCzw4Adxh3IkFIJwBeCD07ANxhRrEEIZ0AeCH0 7ABwh9XYJEjBZa1YAPAsSCcA3NlsO6Fp2mAwUBSFcSeiUGA1NgDvg3EnANzZ TCf2untAGOjZAfBCGHcCwJ3NIIJuHXEhnQB4IfTsAHBkMBhomlYqlRbXQaQT ceEugABeCD07ABzZ68GhabpatWpM0AfhIZ0AeCH07ABwZC+d+Pv748aNIkLP DoAXQs8OAEcY/SpNaDsB8ELo2QHgiKbpiIgIrVYrdkXgH5BOALyQRqMJCQkp U6aM2BUBkDp/f/979+6JXQuwpMJqbADep0SJEikpKWLXAohCoQgPDy9RooTY FQHwMGg7AQBwlxIlSiQmJopdCwDPg7ViAQAAQFrQdgIAQmNOOMzJB9zBdErH QQYPJel0gs8VgJcx5RJpnnO8A0VRppOn+f89jvmbhOOrQPD1GpJOJ+JKSkoS uwpyQVFUWFiY2LUAIeCy4W4WcYQJgh562M0zFven4HLmHZBOLDGhJDQ0NCIi Quy6yIVarcbKHAAAYIJ08g9GozEiIkKhUBQWFoaHh4tdHbnw8fG5d++er69v lSpVxK6LmEwfw7y8PGKnTZ6lrdu6TdviEfOxCCzjEix2YV0NJ9rbpaDY12Vd xvpX0j+8HvQXAWCBdGKbQqHAPEDB6PV6Pz8/rVabm5srdl1Ew1ylmEOh0Whs fiQtrmQ22/DNy1s8Yvqws4xLsP7RoTpIVrGvy2YZLzi80v8DuR52ed+CQ5Gx 2FTqUAF7j8gQ0okNOBoCw53KrVlfC63PmE4PKbC46Ba7C3fUQVwyObzS/9O4 nsa45E4Xt1BsbCWsqZRLAYdGCxmNRs9da1GpVIaEhHApqWLWO5HaWrHITLKC dEL+eaGS1LwDli+RHsT6a6vXH16PiybE8TRWbODjZQsc62MvlXIvwFFGRobn DossVarUxYsXuQQUtJ2A+AoLC4ns0wkhhKbpvLw8rVar1+sle2mRZq24sGg2 l+YL4atWkn3/eAThE7lFLGP/8zG3R3B3ldzBYDDcv3+/cePGaWlpxRZGOvmf tLS0AwcO/PLLL4QQg8GgVCorV64cEhIyYMCAjz/+GDfXdium7cTHx0fsiojJ /HzEDMHBBYZHNlvavfXweujYIGliH4MiiqCgIA8dFvnixYuyZctyLKxAOiGE /PjjjzVq1Bg0aNDu3bsJIWXKlDEajQ8ePPjtt98GDx4cHh6+Y8cOserG9FaK tXdhoGeHwf6H5jJUwqENctyF9YBBlgJSJpPDiyzioUx/ffwFGXJPJ0ajcdq0 aV27ds3IyGjevPnXX3/95MmTtLQ0g8GQnJy8Z8+esLCwBw8e9OnTZ9q0aaLU UA5vU6QTBk3TWq2WEGKvZ4c5f5lwLGA+nMV0+jMpdgs2e+VZCrAz36+9OriJ c0ev2AJSO7wWFRDs8DrBiUTIZQuu14FlI1I+nuwePHgwdepUsWvhALmnk/nz 58+YMYOiqHnz5p04cSI2NrZChQqEEIVCERoa2qNHj8TExCVLligUipkzZ+7c uVPs+nonjDshf8dQvV5PCNFqtfbO0bQZLgXMS9K2uL4LR18mlzrwzvxouPLS PPHwCnOEnUOzJkIuWdbmFhy6ollvwbwa9rbPPZUWW8BiX7z/vc6dO9e9e/ew sLCZM2eePn2a3427j6zHneh0ugULFhBCdu3a1b17d5tlKIoaPXo0IWTMmDH9 +/d/8803PXQ4kpRh3AmAbLFcjDlep2mr9ice61Ds9ovdnYjp8L///e+cOXOO Hj1KCNFoNIMHDw4NDRWrMo7ygHTivvvdLF++PD09vWXLlvaiicno0aN/+umn I0eO/PDDD2PHjmUvbH4wrb8KEDuLOHHcgldCzw4AAF8NJzRN79+/f86cOWfO nCGEBAYGDh8+fMyYMeXLl3d944L533onUksnFEWFh4czfyp3T+z+4osvuBTr 27fvkSNHTp48yZ5OKNbR8qZGQpYy1j9yqZ5HQzrhHU3TycnJFG6vCCAnRUVF O3bsmDdv3rVr1wgh5cqVGz16dGxsbFBQkNhVc5hE204oimJmTNE07b6elIcP HxYUFFSuXJlL4ebNmxNCTpw4wV6MS/JlKWOdnWkHFxfyRBh3wru8vLyIiAiZ 3xwAwCOYn+Gdbj7Jy8vbuHHjggULkpOTCSFVq1YdN27c4MGD/fz8eKuosP6X TqS2VqyJKaa4Q506dW7cuMGxcGZmJiGkVKlS7MW8Pkm4A8adAIB0GI3GR48e ZWdn165dW4Ddudibk5WVlZCQsGjRoqdPnxJCatWqNXHixL59+3r6GVWibSfC 8Pf3J4ScPXv29ddfL7bwyZMnCSEtWrRgKWNzzLlrdZQF9OyA96Fp+uHDh4Jd 4cAVzJ1rmKmahBC9Xl+1alU/P7+cnByxq8bm+fPncXFxW7ZsYb48v/HGGxMn TuzZs6eIzQ0ZGRmBgYG8XPhknU5GjRp15syZmTNnFhsz8/Pz165dS4pLJ+Ac pBPwPgUFBVWrVlWr1fn5+WLXBYqRmZkZERFRqlSp9PR0QohWq6UoSq/XS7Zj vaCgYOLEiQkJCXl5eaYHL168GB0d3adPH59/UqvVgv24YsWKd955p0+fPq6/ Rlmnk+jo6FmzZt28eXPYsGFr1661lzdpmh44cOD169crV67crVs37tt34qha z3eXw58G407A+/j6+qpUqoKCgqKiIry3PYtCoWDGbOn1emmO21Cr1V27dj19 +vS5c+cIIQqFwtfXl6KowsLCwsLCgoKCgoICUSpGUdShQ4d69erl+u1fZJ1O lErlwoULO3XqtGHDhkePHm3fvj04ONiizOPHj0eMGPH9998HBAQcPHiQfeSz 9VRh08I75sfZPH9YP2JvI148tRjjTsAr+fn56XS63NzcgIAAsesCjvHz88vN zc3NzZVmOiGEREVFnT179sCBA5MnT758+bJer69Vq9aMGTN69OhRVFRU+LeC goJCM276kfn/o0ePXr58mZiYuH379v79+7v4AmWdTgghHTp0+PXXX6Ojow8d OhQSEtKmTZsOHTo0atTo8ePHT58+vX379qJFi4xGo4+Pz/fff1+nTp1iN+jo uj32VpMstow3Qc8OeCWkE8/FhJKcnJwyZcqIXRc277//fseOHXfu3Dl16tRb t2716tWrYcOGs2bNat++vcA1yczMDAkJYf4/c+bMPn36uHhKl/tK9oSQd999 9/Llyy1btszOzv7uu++GDh3aqFGjzp07x8TExMfHKxSKQYMG3b59+9133xW7 pl4L6QS8kukKJ3ZFwGHM384jJuQrFIo+ffrcuHFj9erVlSpVunDhQocOHVq2 bCnwovXLli1jBucqFIq7d+9u3brVxQ0inRBCSIUKFY4dO/b48eOEhARCCEVR HTt2HDhw4LRp0549e7Z+/XosaeVWGHcCXsmDrnBgoUSJEsSj/nY+Pj5Dhw69 e/dufHx8mTJlTpw48c4773Tu3Pny5csC7F2n0y1ZsoT5v6+vLyEkLi6OObE7 TSHNtWJFUbFixSFDhhBCFArFTz/9tGHDhunTp1uPRAHeYdwJeCWPu8KBiYcm S61W+/nnnycmJk6dOtXf3//AgQMNGzb88MMP796969b9fv311+np6e+88w4h RKVS1a5dOykpafPmza5sUyHx1dhADtCzA17JQ69wcmM0Gl+9emXxoL2/Xd++ fXfs2GEwGASqnFMCAgK++uqrxMTEsWPHqtXqb7/9tk6dOp988smjR4/csbvs 7OxFixYRQiZNmkQIMRqN06ZNI4TExcW5MnUIPTsgPqQT8EpIJ9J35syZChUq TJ8+3eJxm2OGTp8+vX379lGjRnnEGjZly5ZdtGjRnTt3hgwZQtP0mjVrwsPD 3fFuXLly5YsXL95++21mdCZN0z179oyMjLx///6GDRuc3izSCYgP4048kV6v z8jIePr06f3798Wui0RhVKz0BQcHZ2RkbN++3eJxm8ly4cKFhJDhw4dLdpqx tSpVqqxdu/b69eu9e/ceNGgQ7zXPzc1lDsvUqVOZThij0ahQKJjAN3v2bKeT nNxnFIMUYNwJ75jxZEaj8fz58/m25OXl2XycYxnz8W7+/v46nU681ypdzJUg NTX1yZMnzKqaarVao9GIXS/4f9WrVx82bNjy5cstHrceM3T37t0ffvhBo9GM GDFC0CryoUaNGjt27GBOC/xKSEh4/vz5W2+91bZtWyaIMKGie/fu9evXv3z5 8tq1a0eOHOnElpFOQHzo2eEdc1bNz89/88033bQLrVbr6+ur0WgCAwPdtAtP x1zhxo0bN27cOPPHVSqVKayYuO9HX1/fiIgIkY6BB5gyZcrmzZt1Oh1zImJY t50sWbLEaDT269evfPnyItSSD7wPMNXr9QsWLCCETJkyhfwdJExTbaZPn96t W7e5c+cOGTLEiVCOdALiQzrhHTOpT6FQNGzY0NeKRqOxftChMkxDF03TSUlJ aPSyh7nClSpVSqPRFPwtPz+/qKjI/ELobiVLlszKyhJsdx6nbNmyY8aMmTFj Rm5uLtMrQazSycuXLzdt2kRR1GeffSZmXSVm7dq1T58+bdy4cceOHcnf6ce0 fGiXLl0aNmx44cKF1atXjx492tGNI53Yxpxzlf+kUqlM/xG7gl4F4054xyQG X19f5jYcbpKTk1OtWrUSJUpkZ2e7by+ei7nCjRkzZurUqeaPFxUVmcKK6a4o 7vtRq9UmJSWZbsAL1oYNGzZjxgyDwbBt2zZmCXaLMUOrVq3Kzc3t1KkT7jht kpeXN3/+fPJ3wwn5O0iY36flq6++6ty589y5c2NiYhwd8oJ0YluxDaEKhcI8 r9gMMSyPSLCYiG2/GHfioZgmXKXLt/vyVvZGxapUKpVKJdjISp1OFxgYGBAQ wCzlCdZM/Q6TJ0/u2bOnRqMxbzvJy8tbsWIFIeTzzz8XsZJSw9yf7o033ujc uTPziGlUrKlMp06d/vWvf509e3bVqlWOHj2kk3+gKCo8PJyiKIOVoqIi8/8b jUaj0ejiWnjSoVKpRHwt6NnxUMxpCKsl2YMZxZ5FqVQ+ePBg6dKlEydONB8V u23btmfPnjVs2BD3MzEpKCiYO3cuIWTKlCmm/GDRdkL+Hn3SsWPH+fPnDxs2 zKFdqLBWrDmFQpGYmMilpNFotIgs1iHG0QfFKpaXlyfuBcY8naSkpJj3oJn/ i/giNQaDgSCd2Ie1Yj2LVqvNzs6eM2fO4MGDTcmSpmlmqTE0nJjbuHFjampq vXr1unbtav64QqFgvrqbTgsdOnRo2rTpH3/8sWLFisGDB3PfhQprxTpHoVAo FAov6IwwGAzM5V/EOpjSSWFhIfstjSw6pOz9K5FfWRRwx3Q+cbm1Z4em6UeP HlWqVMlzvzuh7cSz+Pj4tG/f/uDBgzNnzoyKiiKE5Obm/vLLLzdu3KhatWrP nj3FrqCEZGZmUhQ1efJki4+ndfMJIeSrr77q1KmTVqt1aBfo2ZE7pVLJ9GTR NC3W24DpVPLx8TEajaGhoaY2Hot/TQ0/olTSdcw8Gm/Ce88OTdObNm06e/bs +fPnL126xMRWf3//ChUqdOzYsU+fPk2aNOFrXwJAOvE48+fPP3LkSEJCQv36 9QkhOTk5zFJjn376qRd8F+XRhAkT/v3vf9esWdPicYVCYTAYjEaj+ZeWNm3a pKSkvPbaay9evOC+C6QTIEqlkrnwi9V1Ymo78fX1TU5OZilpNBptBhfzfisn Cjj3K0efq1Qqb9y4IdRBFQKPPTs0Tf/www9Tpky5du2a6cEKFSo8ffo0Kysr Kytr6dKlS5curVat2vbt2923iAu/sFasx6lbt+7HH3+8YcOGLVu2EEKeP39+ 8eLFgICAmJgYsasmObVq1bJ+0GbbCSHktddec3T7SCcgoXRSbEmFQqFWq91f I7fIy8tztG1T4vjq2SkoKOjUqdPRo0cJIUFBQePHj3/77bebNm3K/K11Ot3d u3e3b9++ffv2e/fuNWnS5PPPP589e7b0v8ui7cQTzZgxY8eOHSdPniSEMHdp iImJCQgIELtensF62o7zm0I6AebqImKPCebseChe2k4KCwt79ux59OjR0qVL L1++/Pnz519++WVUVJQphgYEBDRq1GjhwoWPHj2aO3euUqmMj49v06aN9fcz qcGoWE9UqVKlzz77jHl3paen+/j4fPrpp2JXymPYaztxAtIJiJ9OTONOxKoA OIeXcSeffPLJ/v37S5cufezYsZEjR7K8DRQKxcSJE2/cuFG2bNkTJ04wS1BI GdpOPNSECRPKlCnD/L9nz55Vq1YVtz4eBG0nwCfR0wnaTjyU6z07KSkpW7Zs USqVhw8frlu3LpenVK9efc2aNYSQiRMnso9Scgdm5BOzIL1er8/JycnKysrM zHz16tXLly/T0tKePXv25MmTR48epaampqenE6QTD+Tv7z9x4kTm/5hI7BAe 204w7gT+FwuEvPGHBaQTN6Fp+u7du8bi0DRdbBmbnjx5QgjJyspKSEhwbmvH jx83GAwfffRRw4YNub+url279urVa9euXe3btw8LC+O4L6dfpjlH/wQURYWE hDj6LBDdmDFj1q9fX7FiRYfemcBj2wlWYwO0nXghiqLCwsKSk5Nr1Kjh7n09 f/58+PDhrmwhNjbW0ad07dp1165dd+7cuXPnjiu7dhRFUQpH+Pv7nz59Wsga Ai9UKtXcuXNxUnIU2k6AT6KnE4w74Z1Go7l582adOnXsXTUdvcrapNPp9u3b V6pUqV69ejm3hRkzZmRlZTnRutC4cWNCSHBw8Pbt21m2z8vLNN8UTpXy0aVL F+mPvJYa/tOJAmvFypjo6QRtJ+7g6+t77949t+7i6tWr+/btq1SpUkJCgnNb WLhwYVZWlhNPZJ5VtmzZdu3aObdrgGIhjDpKgVGxwCOkE3CO0eVRsczMiD/+ +MPRJ547d44Q4inLsgHIBHp2gE8YFQvOMbo8ozgmJmb06NHLly/v1q0b92cV FRUxrTX8LmzP44kVPAvzTjYajUlJSe7bi0KhCA0Ndd/2pYDHthOkExC/7QTj TjyU66uxDRgwYPLkyceOHVu3bt2QIUM4PmvOnDmXLl0KCwv7+OOPnd61NRFv NQXi0ul0hJDMzMyIiAj37SUoKOjy5cvevXoK2k6AT6KnE7SdeCjXe3YCAgJW rlzZv3//Tz75xM/P78MPPyx2jwsWLJgxY4ZCodiwYYO/v7/TuwYwYd7Dbm3b MBgM9+/fb9iwoUN3wvM4aDsBPiGdgHNc79khhPTr1+/JkycTJkzo16/f7t27 Z86cGRkZabPk9evX+/bte/nyZYqili1b1rJlS1f2C2DCxNzAwMDExEQ37SIt La1cuXJePwEFbSfAJ6QTcA5f9ygeP358iRIlxowZ8/333//www+tWrVq2rRp o0aNIiIi0tLSMjIyHjx4sGHDhitXrhBCypUrt2nTpg4dOpB/nrgsToimsyRL GfYtAPCIlygvfWg7AT6Jnk4w7sRDud6zYxIbG9ujR4/Zs2evXr366NGjzP2K Lfj5+Y0aNWry5MklS5YkhFAUZZ4nLH5kcgl7GesfXX8hADbJJJ3w2XaCtWIB c3bAOfyecMuXL7906dIvv/zy1KlT58+fT0hIyMjIaNCgQWhoaLly5d5///2O HTuaJyEuZ0CWMhbRhGBULLiTTNIJ/20nXn/IgIXobSdIJx6Kr54dc+XLl+/R o0ePHj3++uuvI0eOzJ8/v02bNjZLIkmAB5FJOsG4E+AT0gk4h8eeHWu+vr6E kPz8fJu/tW75wEkMpEwm6QRrxQKfRE8nzLgTpBPiaQMz3XrC1Wg0hJC8vDx3 bBxAYDIZRMFj2wnSCYifTpi2E4yK9ThuTSfsbScWnDiDWY8ywWkQ3EcmbSfo 2QE+SSSdoO3E4zDvGTf17LC3nVhPFWZm6JC/z4zM/807gKwfsbcRz2rBAo8g k3SCGcXAJ6QTcI64bSfWM25YfrT5CJdnAfBCJukEPTvAJ9FnFGPciYfCuBMA jmSSTjAqFvgkkbYTjDvxOG7t2XFo3AmAxMlk8Q6MOwEbaJpOTk524onM19PH jx+79e7h9tA0XVRURFGUmy5y4D5oOwHgCG0njsJqbN6jqKjIldt/jxgxgsfK OISiqNDQUERkjyOdOTsAEieTdIK2E7CBGb1BUVRYWJhDT3z+/Hl2dna5cuWY 25cIz8fH59atW6LsGlwh4pwdAM8ik3TCZ9uJTJaIkQPmbeHr6+voTcA/+uij rVu3xsfH9+/f3z1VA++EthMAjmSSTjBnB2xw+t0v+qhY8FAYdwLAkUzSCebs gA1IJyAwzNkB4Egm6QTjTsAGp28Yi3QCzkHbCbDT6XR6vb6goKBKlSpi10Vk MkknzAtEOoF/cPqGsUgn4ByMOwELu3fvvnr16oULF06fPp2RkWF6XKFQhIWF RUREvPfee+3bt69Xr57cLjoySSfMnxUr2cM/OP3uF32tWPBQmLMDjMLCwpUr V86ZM+fZs2emBymKKlmypJ+fn4+Pz8OHDxMTExMTEw8fPjxp0qSQkJBJkyYN GjRIrVaLWG0hySSd8Nh2gnEn3gPjTkBgaDsBQsiuXbuqVKkyZsyYZ8+eBQQE jB8/fvfu3ffu3TMYDDqd7unTp6mpqQaD4fbt2/v37x88eHC5cuXu378/fPjw 4ODgn3/+WezqC0Qm6YT/thOvP2RygHQCAsO4E+jXr9+2bdsIIVFRUZMnT27V qpXN77oKhaJGjRo1atTo3Lmz0Wjct2/fzJkzr1y58u9//3vu3Lnjxo0TvOJC k1U6QdsJ/ANGxYLAMGdH5r788stt27b5+fmtWbPm2LFjrVu35nIpUSgUH3zw weXLlxcsWGA0GsePH79ixQoBaisumaQTPmcUYzU2r4FRsSAwtJ3I2R9//DFn zhwfH5/du3fHxMQ4cREZN27cnj17CCFffPGFc/cI8yAySSeYUQw2oGcHBIZx J3K2fPlyQsjnn3/esWNHpzfSvXv36OjoHTt2LF26dMmSJQ49l6Zpo9FI/838 /yy/slnMfHqRm8gknfB/F0CkEy+AOTsgMAHm7OTk5Ny7d8/1yw8vxUSvgHP1 ZBKeXq/v2bMnjxW4cOECIeSTTz5x8Q89ZMiQHTt2fP3111u3bnWoAq6/x8wp FIrQ0FB+t2lOJukEbSdgA9pOQGDu7tmpWrXqgwcPqlev7o7ty01hYSHTjcKv cuXKubgFJhMUFRWlp6c79ESKoiiKUigU1N/s/Z9LsaCgICZvuYlM0gnaTsAG jIoFgbn1hOvv73/r1q3IyEhXLjnci7lvy6LXMy8vb9CgQVqtdsuWLTxWoH37 9unp6deuXfvXv/7lyh/60qVLhJCWLVvu2bPHhEUYSgAAIABJREFUoVfN0xtN IDJJJxTaTsAaRsWCwNzas0MI0Wq1jt5wG6zpdLpBgwb5+Ph88MEHPG52yJAh 8+fPnz59uitrlhQWFs6aNYsQ0rp169KlS/NXO8mRSTrBXQDBBvTsgMBkcsIF m2JjY5VK5S+//DJlyhTntmAwGD766KOLFy+Gh4ePGTOG3+pJjUw+LDy2nSCd eA+MigWByeSECzaFhIR8//33KpUqLi4uOjrafA17LnJzc9u1a7djxw6lUrlx 48YSJUrwWz2mD4jfbbpCJh8W/ttOvP6QyQHaTkBg7u7ZAYl7//33v/32W7Va vXPnztq1a0+aNCk1NbXYZ/3+++/Dhg0LCgr69ddfK1SocOrUqRYtWvBeN94n 9bhIJukE407ABoyKBYHJ5IQLLD744IM333wzNjb2559/njdv3rx58xo3btyo UaOGDRtGREQwdwFUKpWJiYmpqakpKSlr165lFhdRKBR9+/adO3du5cqVxX4R QpDJh4XHuwCqsFas18CoWBCY04EYvElISMhPP/30559/rl+/fufOnefPnz9/ /jxLeY1G07dv35kzZ1asWFGwSopOJumE4v0ugEgnXgA9OyAwpwMxeJ+33nrr rbfeWrp06blz5y5cuHD69OmXL1/m5ubm5uYWFRVVrlz56NGjGo3mt99+a9So kc0rjvmDFl++Tf0FLGXYtyA6WaUT9OzAP2BULAhMJidc4M7Pzy8qKioqKmrs 2LHmj2dmZgYFBfn6+jZu3NjmEymKMr+kWfzI5BL2MtY/uv5yeCSTDwtmFIMN aDsBgWFULPCFy7dtljIW0YTjBoUkk3SCthOwAaNiQWAyOeGCALz+GiSTDwtW sgcbMCoWBCaTEy64m3XLh/ddkmTyYcFqbGADenZAYOjZAeBIJukEq7GBDUgn IDCZnHBBYE58W7aYzuPcRtxKJh8WjDsBGzBnBwQmkxMuuJv1VGHTOvTmVyjz DiDrR+xtRCLDY2XyYcG4E7ABo2JBYOjZAb6wz7ixThg2M4eUp+3IJJ3wOe4E a8V6DYyKBYHJ5IQL4DqZfFiw3gnYgHEnIDCZnHABXCeTDwvm7IANSCcgMPTs AHAkk3TC410AkU68B0bFgsBkcsIFcJ1MPiw83gUQ6cR7YFQsCEwmJ1wA18lk iCfaTsAGjIoFgaFnB4AjmUR5tJ2ADRh3AgKTyQkXwHUy+bDwPyrW6w+ZHCCd gMBkcsIFcJ1MPiyYUQw2uJhOMCoWHIWeHQCOZJJOsBob2OD0qFhmzg7aTsBR MjnhArhOJh8WtJ2ADRgVCwKTyQkXwHUy+bBgNTawAeNOQGDo2QHgSCZDPNF2 AjZgNTYvwOM3DwHI5OsggOucbtv2LGg7ARvQdgICQzoB4EgmQzzRdgI2IJ2A wNCzA8CRTKI82k7ABqcvFUgn4ByZnHABXCeTDwvaTsAGtJ2AwGRywgVwnUw+ LGg7ARtcHBWLdAKOQs8OAEcySSc8tp2oZDJURw6wViwITCYnXA/FfPOkadr0 xaOwsND0IMf/OFre3hN1Op3Qr19iZPJh4bHtRCWTSdhy4HrPDk3TycnJ7jg3 4Yk0TTP5r6ioKD4+3l6xwsJCpkxcXJz0X2NiYiIhZPr06aVLl5Z4VWX4RIuP uU6nU6vVRDwKhSI0NFTECohLVumEn7YTGj073sLpZnaVShUaGlqiRImioqKI iAg3VA3+X1FR0fjx44stM2XKFGHq47pffvlF7CqADcxZnaIoiqKYk4OPj4/p EdN/zP/v0H8cLR8QEHDp0iURDoQ0yCSdMC/QOhw7AenEezj97vfx8UlOTiaE FBUVhYeHi3LmEvGJgu26qKho+fLlKpVq9OjR9p5oMBjmz5+vUqkmTZokqaNk 88EpU6Y8ePBg1qxZVatWFXjXXvZEd+za9AHX6XSBgYEBAQGZmZl2zwLgZjJJ JxTaTsCa6+9+lUrFtNWDO+Tl5THphOnZsVeGSSczZ84Usm7OWbBgASGkc+fO devWFbsuAJImk3TCY9sJ5ux4D5m8+0E6ZLI4N4DrZHJ+pjCjGKzJ5N0P0oG3 HABHMvmwYDU2sAGLT4DAmLec159wAVwnk3SCthOwQSbvfpAO9OwAcCST8zOf bSdYjc1ryOTdD9KBtxwARzL5sKDtBGyQybsfpAM9OwAcyeT8zP+4E68/ZHIg k3c/SAd6dgA4ksn5GW0nYANGxYLAZHLCBXCdTD4smLMDNsjk3Q/SgZ4dAI5k cn5G2wnYIJN3P0gHenYAOJLJ+ZnHleyRTryHTN79IB14ywFwJJMPC1ayBxtk 8u4H6UDPDgBHMjk/o+0EbMCoWBAYenYAOJJJOkHbCdggk3c/SAfecgAcyeTD wmfbCdaK9RoyefeDdHhxzw5N04mJibx8BQQgsjk/89924vWHTA5k8u4H6fCy np2HDx/Gxsa+9dZbFStWVCgU1apVUyqVlStXbtOmzfTp058/fy52BcGDyeT8 jBnFYINM3v0gHV7zlvv111+bN29epUqVVatWnTlz5unTpxRFhYSE0DT96NGj o0ePfvXVVxUqVGjXrt2ZM2fErix4JK/5sLDDamxgA0bFgsC8oGfHYDBMmzat bdu2p06d8vPzi4mJOXr0aGpqqsFgSElJMRqNKSkpBw8e7Nu3r1qtPnz4cIsW LZYuXSp2rcHzyCSdoO3Eyzn355DJux+kw9N7doxGY/v27WfMmEEIWbx4sU6n W7NmTatWrSpXrsx8BpkWlHbt2n3zzTdZWVlxcXEFBQVjxozp2bOn2HUHDyOT 8zPaTsAG5g2RmZkpdkVAFrzgbDt//vyjR4+WKVPm1KlTY8aMYY9ZPj4+//nP fw4ePOjv779nz55NmzYJVU3wBl7weeECbSfw//Ly8pYtW9a0adN9+/YRQkaN GhUYGNijR49Vq1Y9evRI7NqB1/L0nsTr169Pnz6doqjt27c3bdqU47PatWv3 9ddfE0LGjh2LzxdwJ5N0wmPbiQrphEem2Gh+PK1TJMtvTb9i3wJDr9cvWLBg 0aJF5u0lZcuWTUtL27dv3759+8aPH7948eKYmBgnXw+AfabFCJKSksSuizPm zZuXn58/ZMiQNm3aOPTE/v37b9y48dixY4sXL46NjXVT9XiUnZ1NeLpggNNk kk54bDtBOuETk0soijL/2zj0o+nPUexfNz8/v1u3bocOHSKE1K9ff9asWfXr 169UqRJFUWlpaT/88MOhQ4f27NkzdOjQ/fv3b968OTg4mK+XCUAIoWk6LCws OTk5IiJC7Lo4r0+fPk48a8iQIceOHVu4cOHChQt5r5Kb5OTkiF0FWZNJOkHb iaSxBAvr2MEEGkeTZmFhYa9evQ4dOhQQEJCQkGBxhi1btuyQIUOGDBny7bff xsbGHjhwoHfv3ocPH8ZfGXik0WiuX78eGRkpdkWcQdN0SkoKTdNvvvmmE09v 3LgxIUSlUlWtWpXvqvGPmXnk9ddFiZNJOuGz7QRrxXqiiRMn7t+/v3Tp0seO Hatbt669Yn369GnWrFm9evWOHj26fv36IUOGCFlJ8HparTYxMVHsWjiDpunS pUu/evVKp9P5+/s7+vSsrCxCSLVq1W7evOmG2vEsOzu7fv36JUuWFLsisiar dMLnnB2vP2TeJCsra926dYSQgwcPskQTRkhIyJo1awghn3/++ZMnT4SoH4Dk URTFtH+cO3fOiaczz3Ku3UV4JUuWTExMvHz5stgVkTWZpBPcBVDWtm3blpWV FRUVxZxei9W7d+8WLVrodLpdu3a5u24AnoKZpxMfH+/o9zxmlpxpCwBcyCSd 8N92gnQiDIvpPITbAFiLp2zcuJEQMmzYMO77/fDDDwkhFy5c4P4UAO82ZsyY SpUqnT59evHixQ49ccqUKTdv3nz99dcHDhzoprqB95FJOkHbiUSZ1pdkecQ0 r8d6dg/HMi9fviQOtio3bNiQEPLXX3859noAvFepUqVWr15NCJkwYcKUKVOY 5VvY5efnjxgxIj4+XqVSbdy4UaPRuL+a4CVkMogCbScSRf+N5RHzB1kCJpcy 3DEzC+7du+f6pgC8RqdOnZiAEhcX16pVq//+97/2Pm5Go/HAgQNvv/32ypUr 1Wr1tm3b/vWvfwlbWfBsaDtxFGYUe6qioiLuha9fv04IeeONN9xWHQCPNHTo 0OrVq3/44YcnTpxo1apVqVKlRowYERERERISUqlSpQcPHty/fz8xMXHFihXM PJ3w8PDdu3czjZEA3MkknWA1NlmrVatWYmLigQMHatasyfEpTJ9Oo0aN3Fkv AI/07rvvXr58edWqVQkJCU+fPo2Li7NZLCQkZMSIEUOHDg0MDLRZgMsa0OYj z3g5g4OnkEk6wV0AZY0ZD7t69WqOZ7f8/PwNGzaQv5eQAgAL5cqVmzZt2uPH jzdt2vSf//ynX79+zZs3DwsLI4SoVKrZs2f/9ttvKSkp48ePZ4km5r2xFmdU UxeteTGcdWVFJukEq7HJWocOHUJCQu7evZuQkDB8+PBiy8+cOfPWrVu1atWK jo4WoHoAHoqiqI8//tj0Y3Z2tr+/v0aj+eKLL4p9Isc1oK1vWwEyIZN0grYT WVMqlczdPUaOHLl161b2wnv37p0zZ45CoVi/fj2mGAAAiEIm6YTHthOsFeuR evToMX/+fKPR+PHHH48ZM0an01mXyc7OHjJkyAcffGA0GseOHdusWTPh6wkA AMTsnt5iV8S9cBdAIOPHj9fr9dOmTVu6dOmqVavGjx9frVq18uXLly9f/uLF i0eOHDl8+PCrV6+0Wm18fDyXDiAAAHATtJ04CunEg02dOrV169Zz5849cODA rFmzrAvUr19/165dNWrUEL5uAPJhPcrEiRuPg3eTSTpB2wn8T7Nmzfbv3//s 2bNly5YlJCSkp6dHRETUq1evTZs2rVu3rl69utgVBJAFizk49mYUs5QB7yaT dIK2E/iH8uXLz5o166effkpPT9+7d2/9+vXFrhGA7LAv/SxkTUCCZJJOMGcH bJDJux8AwOPI5PyMOTtgg0ze/QAAHkcm52fcoxhsYN79SqVS7IoAAMA/yCSd 4B7FYANzC3ivf/cDAHgcmaQTPttOZLJEjBzI5N0PAOBxZHJ+RtsJ2CCTdz8A gMeRyfmZ/1GxSCdeQCbvfgAAjyOT8zNmFIMNGBULACBNMkknaDsBGzAqFgBA mmSSTtB2AjbI5N0PAOBxZHJ+xmpsYINM3v0AIHGpqanp6eli10JaZHJ+xl0A wQaZvPsBQIKOHz++e/fuS5cu/fXXX/n5+cyDQUFBNWvWbNeuXbt27Zo0aSLn UXEyOT/jLoBgA0bFAoDAaJpOSEiIi4t7/Pix6cFSpUrRNJ2RkZGRkXHmzJkz Z87MmDEjMjJy3rx5HTt2FLG2YqFpmrmLtddfajHuBGzAqFgAENLDhw9btmwZ Gxv7+PHj4ODg+Pj4Y8eOPX36ND09/dWrVzRNv3r16sCBA6NGjapSpcq1a9c6 derUunXr7OxssSsuNJk0nBB+x51grVivIZ8PAACI7syZMzVq1Dh58mRQUNDG jRvT0tI+//zzli1bli9f3lQmKCioU6dOy5Ytu3fv3qJFi4KDg3/99dc333zz 0aNHItZcePI5OaPtBGyQzwcAAMT17Nmz7t276/X6Nm3a3Lt3b8CAAexnHrVa PXbs2Fu3btWpU+fWrVsNGjR48eKFYLUVnXxOzljvBGyQzwcAAMQVHR39+PHj li1b/vzzz6VLl+b4rLJly/7+++/169d/8eLF9OnT3VlBaZHPyZnPuwAinXgN jIoFAAGcOHHi+PHjZcuW3bt3r0qlcui5AQEB27dvV6lUa9asuXXrlptqKDXy SSe4CyDYgFGxACCAbdu2EUKGDh0aHBzsxNNff/31gQMHFhYWbty4ke+qSZR8 0gmPbSeYUew95PMBABCM0WhMSkoSuxbSsm/fPkLIhx9+6PQWOnbsuHbt2j// /FMmxzYrK4v5j+n1KpXKkJAQ8WrkLjy2naiwVqzXQDrxLAaDYdGiRZ999hmX zrj8/PwVK1aMHTsWf1/BKBSK0NDQlJSUiIgIsesiRVWrVnX6uZGRkYSQkydP yurYZmVlmV5vcHDwy5cvxa2PO8h0NTaZpGznyGe1H6/x73//++effw4MDBw6 dGixhZcsWTJp0qSLFy9+8803AtQNCCF+fn7Xrl2rV6+e2BWRnJSUFKPR6MoV KCcnhxDi4+NTpUoV/urlSQIDA8WuglvIcSX7e/fuVa9eXexaAPBmwIABP//8 8+zZswcMGKBWq1lKZmdnx8fHM08RqHJACCGkRIkSiYmJYtdCcmrUqHH37t3z 58+/++67zm3h6tWrhJAuXbrs3r2b16qByGTXdmI0GploEh4eLnZdJM3R8fMg oh49ekRGRl67dm3Tpk3szSdff/31ixcv3n777datWwtWPQB7oqOjZ86c+c03 3zidTpjxsI0bN+a1XiA+HttOqDJlyrx48SItLa1MmTKub85NjEajUqmkKIqX 1wwgiry8PK1Wq9Fo9Ho988ju3bt79eoVEhJy584dpvnEukx2dnZYWNiLFy+O HDmCdAJScPfu3Ro1aqjV6hMnTrz11luOPv3AgQOdO3cuXbr0vXv3goKC3FFD EMudO3dq1qxZo0aN27dvW//2xYsXZcuWLVOmTFpaWrGbwoxiANEwzSf379/f tGmTvTJoOAGpqV69+pgxYwoKCrp27fr8+XOHnnv+/Hmmg3LKlCmIJt4HK9kD eAOFQjF16lRCyOzZswsKCqwLmEacyGphTZC++fPnv/POO8+ePXvjjTeOHTvG 8Vm//vprVFTUy5cvW7VqFRsb69Yagiiwkj2Al2BvPkHDCUiTj4/P3r1769at +/jx41atWsXExKSmprKUv3HjBnOD4tzc3Ojo6F9++cXHx0ew2oJg+Bx3EhQU lJGR8erVKyk3smHcCXgB6zElDPPRJ0aj0VQGI05A4gwGw8yZM+Pi4piFqrt3 7167du3atWvXq1evoKBAp9Olp6efOnXq0KFDN2/eJISUKFFi/vz5w4cPx/dh D1JYWPjee+/16dNn8ODBvr6+7IVTUlLCwsJCQ0OTk5Otf+vQuJP/zbrOyMig JYx561MUJXZFAJzHhBKNRmPxuMFgYBanWr16tXmZuXPnEkLefvttMSoLwNWN GzdGjBjh7+/PcqFRKpUDBw5MT08Xu7LgsB07djB/xMqVKy9fvlyv17MUvn// PiGkatWqNn/LhJIyZcpw2S8VEBCg0+l0Oh37e0tcaDsBL2Cv7YSYNZ9cuXIl MDBQo9GkpaWh4QQ8SFFR0ffff3/lypWbN29evXr19u3bKpWqS5cu/9fevcVG UT1wHD/Trm2hIVgSIhFopCWxkhCo3As0BghEBVGDpMHEJ9CYiJaL8ACE1WCi 0W23RE3UmKgPNFKI15gIhgABDaxCH8BE5RKK0UaFblnSstuy83+YP5tlbjuz tzmz/X6emJkzM+fsLju/PefMtKGhYcWKFU1NTcZnIqf3oKh3z1RIbVJVNf3f hWwBzKmq+uWXX77++uvd3d1CiIkTJ27fvn3Dhg1VVVXGwlevXq2trZ08eXJP T49xq7u+Ey2UxGIxt3mqmOg7QQmw6jtR07pP3nvvPa0MHSfwr2g0KoQYO3as TRlx5wnXpouplenrTcugOJLJ5BdffNHY2Ki9Kffff384HB4YGNAV+/PPP4UQ kyZNMj2Iq74T2WfFploLlLDUzTtvvfWWtoZbdVDCtJ+a6WvUtD4S3XrTf6PI FEV58sknf/nll6+++mrWrFl//fVXa2trfX19OBxO7wzO418BlDSddHV1bdmy ZdGiRVVVVZMnT9a6BFVV3bp1q+kzXgC/027e0bpDh4eHuVUHgGwURXniiSci kcjXX389e/bsv//+e9OmTXV1dW1tbQMDA+LOPTt5yZFlWsaRJ52cPXt26dKl a9eubWtrO3nyZCKRmDBhQmprKBRqaGhYvXr1H3/84WElgbxLdZ8IIYaHhwUd JwCkpCjKqlWrTp8+/e23386ZM6e3t3fLli11dXWhUEjrR8nPHcVVVVW3bt0a HBw0neFSZK2trXv37lVVddSoUZs3b168eHFzc/OoUaOEENFo9Pfff//000/3 7dsXjUYrKipCodBLL73kdZUBp2xmxWqSyeT06dN//fVXIcTChQtPnDhR3AoC +dHf33/vvfeOHTtWm4BiZBzZMV1pWgzizvwbcaeXIn0x4/qsd7Raf+TIkY6O Dm3ObE1NTV9f3/jx400fIuxqVqxSWVkZj8dv3bqV8T7mQtuzZ8+uXbsqKipe fvnlnTt3Wv2B6Xg8vmPHjlAoJIR48cUX33///WJWMo8PwsNIkzGdCCE6OzvX rVsnhPjss8+ampoK94XCAX10It8dMJFI/PDDD4FAYOnSpVY7HjlyRPsjgtri sWPHmpubdSVPnjyp/S/w70tRoANKLhAIvPHGG1u3btUGelLcpZOKiopEIhGP x+3/hnuhff755y0tLeXl5V1dXU899VTG8t9///3TTz89MDDwzTffrFy5sgg1 TCHOIztO0kkymZwxY8aYMWN++umnYtYNgI8oiqL9VE7/h9v1We9oXJ9MJm/c uBGLxbQxnVWrVgWDwYcfflhXbXfp5J577hkaGkokEh4+Vzgej0+aNOm///77 8MMPN2zY4HCvcDi8adOm2trac+fOFfNhLaQTZMdJOhFCdHV1VVdXb9y4sThf K17tKP8B5amJ75o2ODi4Zs2a6urqgwcPlljTPDxgegF5XLt2LRQKvfvuu7FY TFGUxx9/fPfu3bNnzzYt7C6dBAKB4eHh4eFh46Nyimbfvn3PPvvsrFmzfv75 Z+d73b59e8GCBZFIpL29vbW1tXDV01FIJ8iKw3SSTCZ13aGAv2Scd4IScP36 9ba2tr1798ZiMSHEY489FgwG58yZY7OLq3QS0C603saxjz76SAjxwgsvuNqr vLz8+eefj0QikUjEplh603SpQtuk3n2fvTF52G8F8otoAkBmfX19Wi65ceOG EOLRRx8NBoNz587N71n+n04uX77sYUC5cOGCEGLJkiVud9SGtc6cOWNVQNfP oVvUcol9GeOi20oCAFACotFoe3t7R0dHf3+/EGLFihXBYHD+/PmFOFdgypQp Fy9enDp1aiGO7koWPxlra2uFEJcuXbIq4KSrw6aMcRBHtXigIQAApSoajXZ0 dITDYW20bvny5cFgcMGCBYU7Y+DChQv19fWFO4ETV69eHRoa0p4058r58+eF EDNmzLAqQJIAACBr/f39HR0d7e3tWi5ZtmxZMBhcuHBhoc8bEEJcvHix0Kex t27dus7Ozv3797/22muudjx9+rS4M75jZOz5IKwAAEqSzdNTnCxalTl+/Pju 3buFEIsXL962bdu8efNUVf3nn3+yOF1fX5/z5khx+8mxY8ceeeSRCRMm9PT0 OL+xua+vb9q0ab29vZ2dnS0tLcYCpunE1RrT23O4ZwfZGRwcHD16dGVl5fnz 5/P79VGcRc7O2R0uDg0NHT58OBAILFu2rOQbK8/ZfaG8vHzmzJlO7s+V4kKr qupDDz3022+/Pffcc5988onDHo7169d//PHHzc3NR48eNd3FdEKrrr0Z84qT gwBORKPRmpoar2sBoDTZPDSl0IvOdxk3bpzDR4dIkU6EEJFIZMmSJTdv3mxt bW1vb7cvHI/HX3nllQ8++KCysrK7u7uhocGqpO5m4NSi1mrdoukaq4NI8rrB R+Lx+LRp0zz5RvD2+6j0zi5VZSQ8+8DAwDPPPFNdXX3gwIGR1nYPz15iZEkn QojDhw+vXLkykUg0Nja+8847VjcYHzhwYNu2bZcvX66oqNi/f//q1auLXE8A gA2exobcSZROhBCHDh1qaWnRJs40NTU1NTXNmzfvwQcf/Pfff69fv97T0/P2 22/39vYKIaZMmXLw4MHGxkavqwwAuAvpBLmTK50IIQYHB8Ph8Jtvvqk9hM6o pqbm1Vdf3bx5s+d/VBkAYEQ6Qe6kSyea/v7+H3/88dSpU6dOnbpy5cp9992n TX397rvvli9fzqO+AUBapBPkTtJ0oqOqallZWVlZ2e3bt72uCwDADukEuaMT AgAAyIV0AgAA5EI6AQAAciGdAAAAuZBOAACAXEgnAABALqQTAAAgF9IJAACQ C+kEAADIhXQCAADkQjoBAAByIZ0AAAC5BLyugDuXLl3yugoAADuxWMzrKsD3 fJNO6urqFEWpr6/3uiIAgAzKysoeeOABr2sBH1NUVfW6Dk6pqjp16lSvawEA yGDMmDHd3d1e1wI+5qd0AgAARgJmxQIAALmQTgAAgFxIJwAAQC6kEwAAIBfS CQAAkAvpBAAAyIV0AgAA5EI6AQAAciGdAAAAuZBOAACAXEgnAABALqQTAAAg F9IJAACQC+kEAADIhXQCAADkQjoBAAByIZ0AAAC5kE4AAIBcSCcAAEAupBMA ACAX0gkAAJAL6QQAAMiFdAIAAOQS8LoCAAATiqIIIVRV9boikIv2wRAWnw37 rXkpUBykEwB+lfoaFUKoqqooioTX8qxrpbWocMcXd7+A6efN7mhesbqaFuIq 6/lnLL0CxsrYb81LgaIhnQDwH2O/gpMLOXRMI53nF2C37GOcv9piT/fW6N4+ +615KVBMzDsB4Eu6L01pL0LSVsyKwz4b2eiqXaDLqu/eTf+i7wSAz1hdeKw6 9q026a5npj0x6T9M09ekL+YysmAcnHLekNR6m5bmRcZXUti+DhlrWJwRuhxb kcW7adxk85FzYkRlI9IJgBLkpMvapozxGqlbk8oo9l3rwnbIyVgBYXZVs6mk sUDu7F86qzbavA5uF7Oueeo9yjhclUUrsng3XX3ksuC7MThXGNkBUGqM39qm oxVOymRkvIDlUkn74xeIcrfshsysXgeH74Xb07mVYyvydYpSmp9baPSaIqK/ AAABKUlEQVSdAIAJ+ymHpSTjTRw5Ht/+CMbBlFxeZ6uBoSLMpCnmZJ0S/jSm kE4AAEI4uIlDZHUNzngd1U3uyft1Ny+t8PwUNucqSYzsAPAZq6GBvF8PUica IdcDT+hmieZ+x1Bpv1N5nKYjOdIJAF/SfS8b57RabXVyhCIwrWTuh8390m4/ 8TP3A2qzW3I8bC78O8pj/xFVM91TnXuBYuIHAQC/sr85M+NWh7d3Op/HkPFH raubaXWzMUzXmB7EtBWmrHZMH2Ex1jC9fHbN1G1y+Ea4aoVVtbNrhZNmOjxF xnfTilXisaqGzec5xwLFQToBMBI5/11YzF+QDCEBGkZ2AMAScQHwBOkEAKRA EgJS+M8AYMTJOMtBN8ZfoO/J4pwF8CPSCQAAkMv/AEbwLwdMRQhTAAAAAElF TkSuQmCC ---679339033-1722169788-969504446=:3623-- From Yann Guidon Thu Sep 21 06:19:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00304 for ; Thu, 21 Sep 2000 17:14:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Sep 2000 17:14:17 +0200 (MEST) Received: (qmail 24983 invoked by uid 0); 21 Sep 2000 04:15:38 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 21 Sep 2000 04:15:38 -0000 X-eGroups-Return: sentto-1101623-770-969509723-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 21 Sep 2000 04:15:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 04:15:22 -0000 Received: (qmail 21802 invoked from network); 21 Sep 2000 04:15:22 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 21 Sep 2000 04:15:22 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 21 Sep 2000 04:15:22 -0000 Received: from f-cpu.org (nas2-236.ras.club-internet.fr [195.36.192.236]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA14456 for ; Thu, 21 Sep 2000 06:15:20 +0200 (MET DST) Message-ID: <39C98C68.431F6CC4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 06:19:52 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 873c5bd58b87152d5aff2d22f00b360f Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Michael Riepe wrote:
> Time to draw another picture.  Later...

time to compile, too.
i found some bugs in the C source i sent.

the "weird case" is when one writes the same address
with two different values to the cache. In practice there
should be no problem because the first line should
be invalidated before the second write updates the data.
This is not yet very clear in the C code and i fear the
"semantic collision" when going to VHDL.

> [...]
> > > Too bad that the main part of bzip2 doesn't fit into an FPGA= , too...
> > that's just a matter of how smart one can be to "break up&qu= ot; the algorithm...
> > it took me almost a year to breakup the FHP-3 collision operator = :-)
>
> Sorting 1 million strings with 1 million characters in them is beyond<= BR> > the capabilities of today's FPGAs :(

i don't know how bz2 works.... sorry ;-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Rares Marian Thu Sep 21 15:06:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00322 for ; Thu, 21 Sep 2000 17:14:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Sep 2000 17:14:21 +0200 (MEST) Received: (qmail 13060 invoked by uid 0); 21 Sep 2000 13:03:24 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 21 Sep 2000 13:03:24 -0000 X-eGroups-Return: sentto-1101623-772-969541383-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 21 Sep 2000 13:03:09 -0000 X-Sender: rmarian@linuxstart.com X-Apparently-To: f-cpu@e-groups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 13:03:03 -0000 Received: (qmail 4394 invoked from network); 21 Sep 2000 13:03:03 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 21 Sep 2000 13:03:03 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta2 with SMTP; 21 Sep 2000 13:03:02 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e8LD6Nh31765; Thu, 21 Sep 2000 09:06:23 -0400 Message-Id: <200009211306.e8LD6Nh31765@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu@egroups.com From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 09:06:23 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 1 bit loopback adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac1b098ceea5b995049b640abdce9ae8 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Yann Guidon <whygee@f-cpu.org> wrote:


>hi !
>
>Rares Marian wrote:
><snip>
>
>for the record, some FPGAs use a 4:1 multiplexor as minimal
>block, instead of a 1-bit adder.

Ewww power hogs.

>> Rares
>WHYGEE

Rares


Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
 From Yann Guidon Wed Sep 20 22:25:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00309 for ; Fri, 22 Sep 2000 01:12:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 01:12:01 +0200 (MEST) Received: (qmail 7576 invoked by uid 0); 20 Sep 2000 20:22:31 -0000 Received: from ch.egroups.com (208.50.99.226) by mx12.rz2.gmx.net with SMTP; 20 Sep 2000 20:22:31 -0000 X-eGroups-Return: sentto-1101623-767-969481286-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 20 Sep 2000 20:22:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_1); 20 Sep 2000 20:21:25 -0000 Received: (qmail 18008 invoked from network); 20 Sep 2000 20:20:36 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 20 Sep 2000 20:20:36 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 20 Sep 2000 20:20:36 -0000 Received: from f-cpu.org (nas3-66.aub.club-internet.fr [195.36.145.66]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA11538 for ; Wed, 20 Sep 2000 22:20:32 +0200 (MET DST) Message-ID: <39C91D20.751BFD9B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Sep 2000 22:25:04 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0924e05423d2367f024dc9f912de9581 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello,

Michael Riepe wrote:
> A CLA for 256 lines should not require more than 3 or 4 gate delays. > Still faster than the f-cpu pipelines :)
3 or 4 gates delay leaves nothing for the remaining tasks.
a 64-bit OR gate is half of the pipeline granularity.

what really bothers me is how we can lookahead. what smart idea
we can invent to predict the tree's behaviour. that's really tricky.
now i understand why it's limited to 4 or 8 lines in practice.

> > Michael, wo hast du dieser Algo gefunden ?
> Nirgendwo :)  It's more or less an array-based implementation of = a linked
> list (horribly inefficient in software because you can't shift data > through an array in a single cycle), combined with content addressing<= BR> > for fast parallel search.

I've remarked that "content addressing" doesn't directly work for= this case.
i mean : when you have looked up what cache line contains the item you sear= ch,
you have to lookup all the items in the queue which are more recent than th= e
line. that's two lookups, two cycles. fortunately, one can easily split thi= s up.

>  I started playing with a list, but that
> required 3 read/write buses for moving an item to the front in a singl= e
> step, so I replaced it with a `gated' FIFO with feedbacks from each st= age
> to the first element (1 bus).  Later I realized that the feedback= s aren't
> needed at all -- we *know* which number to shift in, we just don't kno= w
> where it's currently stored.  That's where content-addressable me= mory
> came to my mind... *klick* fiat lux!
yup. but now it gives birth to a new problem...

> The `move-to-front encoder' in bzip2 uses a similar algorithm, but
> without content-addressing.  It does a (slow) serial search inste= ad.
like my C code, i presume.

> Too bad that the main part of bzip2 doesn't fit into an FPGA, too... that's just a matter of how smart one can be to "break up" the al= gorithm...
it took me almost a year to breakup the FHP-3 collision operator :-)

later,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From "Rares Marian" Thu Sep 21 20:32:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00318 for ; Fri, 22 Sep 2000 01:12:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 01:12:05 +0200 (MEST) Received: (qmail 8707 invoked by uid 0); 21 Sep 2000 19:19:15 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 21 Sep 2000 19:19:15 -0000 X-eGroups-Return: sentto-1101623-774-969561135-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 21 Sep 2000 18:32:26 -0000 X-Sender: rmarian@linuxstart.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 18:32:14 -0000 Received: (qmail 9813 invoked from network); 21 Sep 2000 18:32:14 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 21 Sep 2000 18:32:14 -0000 Received: from unknown (HELO mv.egroups.com) (10.1.1.41) by mta2 with SMTP; 21 Sep 2000 18:32:14 -0000 X-eGroups-Return: rmarian@linuxstart.com Received: from [10.1.2.225] by mv.egroups.com with NNFMP; 21 Sep 2000 18:32:14 -0000 To: f-cpu@egroups.com Message-ID: <8qdk7b+tub5@eGroups.com> In-Reply-To: <00092113582901.00413@gandalf> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 130.215.231.27 From: "Rares Marian" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 18:32:11 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: 1 bit loopback adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aa3bda5802700886f075a05b13cae168 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

--- In f-cpu@egroups.com, Jecel Assumpcao Jr <jecel@m...> wrote:
> Rares,
>
> > I'm particularly proud that I managed to avoid costly XORs (aka (A
nand
> > B) and (A or B)).
> >
> > Okay take it apart now :)
>
> I am afraid that I will have to be more harsh than I would like: are
> joking?!?
>
> 1) Notation.
>
> Why did you come up with your own instead of using standard logic
> symbols? Your notation is very ambiguous since it is hard to tell
which
> are the inputs and outputs of a gate. I once had to deal with a
large
> schematic in a manual written in Japanese and they drew everything
as
> labeled boxes. That makes it much harder to understand.

I'm looking for tools that have those symbols I'm not going to spend
hours drawing arcs and lines for gates when I could be designing.

> Since you wanted to share it via email, you might have considered a
> textual representation instead:
>
> new_bit = ((source1+source2)+old_carry)*!new_carry +
>          ((source1*source2)*old_carry)*new_carry
> new_carry = (source1+source2)*((source1*source2)+old_carry)
>
> This was easier to check against the truth table for the full adder
(it
> is correct).

Point taken.  I think seeing it wired together is useful, tho.

> 2) Latch for the carry.
>
> Your drawing shows the new_carry somehow flowing into the old_carry
> without explaining how this works. But this is the most important
> aspect of the whole design. Are you going to use a transparent
latch? A
> D Flip-Flop? How will this be synchronized with the incoming source1
> and source2 bits?

I haven't gotten that done yet.  I'd like to avoid sync signals from
the outside, except perhaps from local registers.  I certainly am not
going to sync all 1-bit adders to one signal.  The wiring would be
horrendous.

I figured at least the idea should be clear enough. 

> Some advice: with CMOS technology is it easier to generate inverted
> output gates: a NAND has two less transistors than an AND gate. If
you
> are looking for small and fast implementations it is important to
take
> this into consideration.

You're the second person to suggest this.  I'll see what nands would
do to the logic.  Hopefully I don't have to "!Nand" all over the
place.

> Note that I am trying to be helpful, not nasty.

No problem.  I have yet to take any formal course work in design.  I
know enough to propose ideas and get the logic right.  The nand < and
and other such details I'm a bit unfamiliar with.  I almost tried
using a LUT/multiplexer because I couldn't get the design simple
enough.  My first attempt was a traditional adder with just a looped
carry.  One signal leaving at the beginning of the circuit had to be
synced with a signal produced by 7 or 8 gates.  I knew it would
happen.  I prefer trying to sync two sets of 4 gates on either side to
8 to 0.
> -- Jecel
Rares

 From Jecel Assumpcao Jr Thu Sep 21 18:36:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00321 for ; Fri, 22 Sep 2000 01:12:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 01:12:06 +0200 (MEST) Received: (qmail 21057 invoked by uid 0); 21 Sep 2000 19:22:52 -0000 Received: from fj.egroups.com (208.50.99.207) by mx19.rz2.gmx.net with SMTP; 21 Sep 2000 19:22:52 -0000 X-eGroups-Return: sentto-1101623-773-969554457-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 21 Sep 2000 16:41:22 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 16:40:46 -0000 Received: (qmail 31464 invoked from network); 21 Sep 2000 16:40:45 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 21 Sep 2000 16:40:45 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 21 Sep 2000 16:40:39 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id NAA01446 for ; Thu, 21 Sep 2000 13:46:03 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00092113582901.00413@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 13:36:14 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 1 bit loopback adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 73919cc3b83a13fd15ff6bb55c172828 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

Rares,

> I'm particularly proud that I managed to avoid costly XORs (aka (A nand
> B) and (A or B)).
>
> Okay take it apart now :)

I am afraid that I will have to be more harsh than I would like: are
joking?!?

1) Notation.

Why did you come up with your own instead of using standard logic
symbols? Your notation is very ambiguous since it is hard to tell which
are the inputs and outputs of a gate. I once had to deal with a large
schematic in a manual written in Japanese and they drew everything as
labeled boxes. That makes it much harder to understand.

Since you wanted to share it via email, you might have considered a
textual representation instead:

new_bit = ((source1+source2)+old_carry)*!new_carry +
         ((source1*source2)*old_carry)*new_carry

new_carry = (source1+source2)*((source1*source2)+old_carry)

This was easier to check against the truth table for the full adder (it
is correct).

2) Latch for the carry.

Your drawing shows the new_carry somehow flowing into the old_carry
without explaining how this works. But this is the most important
aspect of the whole design. Are you going to use a transparent latch? A
D Flip-Flop? How will this be synchronized with the incoming source1
and source2 bits?

Some advice: with CMOS technology is it easier to generate inverted
output gates: a NAND has two less transistors than an AND gate. If you
are looking for small and fast implementations it is important to take
this into consideration.

Note that I am trying to be helpful, not nasty.

-- Jecel
 From Steve Van der Hoeven Thu Sep 21 23:08:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00324 for ; Fri, 22 Sep 2000 01:12:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 01:12:07 +0200 (MEST) Received: (qmail 10696 invoked by uid 0); 21 Sep 2000 21:09:02 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 21 Sep 2000 21:09:02 -0000 X-eGroups-Return: sentto-1101623-775-969570535-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 21 Sep 2000 21:09:00 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 21:08:54 -0000 Received: (qmail 8892 invoked from network); 21 Sep 2000 21:08:54 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 21 Sep 2000 21:08:54 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta3 with SMTP; 21 Sep 2000 21:08:54 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id QAA21711 for ; Thu, 21 Sep 2000 16:08:53 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <8qdk7b+tub5@eGroups.com> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 16:08:53 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] simulation software Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f57052e6f48b18e92704b5908fb0731 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!



browsing the gpl projects i discovered this one

don't know it we know this one already...

http://www.freehdl.seul.org/

--steve

 From Michael Riepe Thu Sep 21 19:18:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00309 for ; Fri, 22 Sep 2000 19:56:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:02 +0200 (MEST) Received: (qmail 24228 invoked by uid 0); 21 Sep 2000 23:39:24 -0000 Received: from hl.egroups.com (208.50.99.197) by mx11.rz2.gmx.net with SMTP; 21 Sep 2000 23:39:24 -0000 X-eGroups-Return: sentto-1101623-776-969579558-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 21 Sep 2000 23:39:22 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 23:39:18 -0000 Received: (qmail 27655 invoked from network); 21 Sep 2000 23:39:18 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 21 Sep 2000 23:39:18 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.37) by mta3 with SMTP; 21 Sep 2000 23:39:14 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00512; Thu, 21 Sep 2000 19:18:30 +0200 Message-ID: <20000921191830.23994@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39C98C68.431F6CC4@f-cpu.org>; from Yann Guidon on Thu, Sep 21, 2000 at 06:19:52AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 19:18:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c517ab6e93a708c28b7afed5426d7ee Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Thu, Sep 21, 2000 at 06:19:52AM +0200, Yann Guidon wrote:

> the "weird case" is when one writes the same address
> with two different values to the cache. In practice there
> should be no problem because the first line should
> be invalidated before the second write updates the data.
> This is not yet very clear in the C code and i fear the
> "semantic collision" when going to VHDL.

I'm afraid I do not grok fully what `same address' and `different values'
means in this context.  A memory location should be bound to a particular
cache line, as long as the line isn't replaced with data from another
memory location (in the I-cache, at least).  This is a 4-step operation:

      1. LRU lookup -> cache line to use
      2. invalidate line
      3. fill line (takes a while to complete)
      4. re-validate line

> > Sorting 1 million strings with 1 million characters in them is beyond
> > the capabilities of today's FPGAs :(
>
> i don't know how bz2 works.... sorry ;-)

A good description of the BWT algorithm is at
http://www.dogma.net/markn/articles/bwt/bwt.htm

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Jecel Assumpcao Jr Fri Sep 22 01:01:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00312 for ; Fri, 22 Sep 2000 19:56:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:03 +0200 (MEST) Received: (qmail 7708 invoked by uid 0); 21 Sep 2000 23:47:20 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 21 Sep 2000 23:47:20 -0000 X-eGroups-Return: sentto-1101623-777-969580024-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 21 Sep 2000 23:47:18 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 21 Sep 2000 23:47:01 -0000 Received: (qmail 4116 invoked from network); 21 Sep 2000 23:47:01 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 21 Sep 2000 23:47:01 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 21 Sep 2000 23:46:49 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id UAA02366 for ; Thu, 21 Sep 2000 20:52:09 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <8qdk7b+tub5@eGroups.com> In-Reply-To: <8qdk7b+tub5@eGroups.com> Message-Id: <00092120461900.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Sep 2000 20:01:43 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] schematics (was: 1 bit loopback adder) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e5627151609fada70f39cfd0dbe39c8b Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Thu, 21 Sep 2000, Rares wrote:
> I'm looking for tools that have those symbols I'm not going to spend
> hours drawing arcs and lines for gates when I could be designing.

You could use gEDA (http://www.geda.seul.org/) or one of the tools on
their links page (extracted from http://www.opencollector.org). I would
recomend Electric (read the manual at
http://www.staticfreesoft.com/manual/index.html) since it runs on
Linux, Windows and the Macintosh. And you get to simulate your circuit
to see if it works once you enter it into the tool.

IDaSS, which I now have running on both Linux and Windows, is for high
level designs and so represents everything as boxes that look all alike.

> > [textual representation]
> Point taken.  I think seeing it wired together is useful, tho.

It is indeed, but only if it is reasonably organized. It is a
convention to draw the schematics with inputs coming in from the left
and going out towards the right. Loops are avoided as much as possible.

> > 2) Latch for the carry.
>
> I haven't gotten that done yet.  I'd like to avoid sync signals from
> the outside, except perhaps from local registers.  I certainly am not
> going to sync all 1-bit adders to one signal.  The wiring would be
> horrendous.

So you don't have a global clock? You will find the wiring even worse
without it.
 
> I figured at least the idea should be clear enough. 

It is, but your circuit won't look so simple once you add the missing
latch, mux and control circuit. This kind of "hand waving" is the best
way to get into deep trouble later on in your design. This is
meant as just a friendly warning - don't let it kill off your
discussions and brainstorming!
     
> > [CMOS technology: inverted gates are faster]
>
> You're the second person to suggest this.  I'll see what nands would
> do to the logic.  Hopefully I don't have to "!Nand" all over the
> place.

new_bit = ((source1+source2)+old_carry)*!new_carry +
          ((source1*source2)*old_carry)*new_carry
new_carry = (source1+source2)*((source1*source2)+old_carry)

become, after applying De Morgan's rule to the top level:

new_bit = !(!(((source1+source2)+old_carry)*!new_carry) *
          !(((source1*source2)*old_carry)*new_carry))
new_carry = !(!(source1+source2)+!((source1*source2)+old_carry))

This might look more complex, but will actually save you 12 transistors
>from the original design. If you make a schematic, it doesn't look so
bad.

> No problem.  I have yet to take any formal course work in design.  I
> know enough to propose ideas and get the logic right.

I did get formal training, but only after I had already been building
logic circuits for 12 years.

If you are unfamiliar with Karnough Maps and De Morgan's rules, you
might want to take a quick look at:

    http://kom.auc.dk/logic/

> The nand < and
> and other such details I'm a bit unfamiliar with.

This varies from one technology to another. What is true for CMOS might
be wrong for superconducting circuits, for example.

> I almost tried
> using a LUT/multiplexer because I couldn't get the design simple
> enough.  My first attempt was a traditional adder with just a looped
> carry.  One signal leaving at the beginning of the circuit had to be
> synced with a signal produced by 7 or 8 gates.  I knew it would
> happen.  I prefer trying to sync two sets of 4 gates on either side to
> 8 to 0.

I would call what you are doing "equalizing delays" instead of
"syncing", but perhaps I simply didn't understand your intention.

-- Jecel
 From Kai Wetzel Fri Sep 22 12:22:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00360 for ; Fri, 22 Sep 2000 19:56:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:14 +0200 (MEST) Received: (qmail 14246 invoked by uid 0); 22 Sep 2000 08:24:58 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 22 Sep 2000 08:24:58 -0000 X-eGroups-Return: sentto-1101623-778-969611092-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 22 Sep 2000 08:24:53 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 08:24:52 -0000 Received: (qmail 13304 invoked from network); 22 Sep 2000 08:24:51 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 22 Sep 2000 08:24:51 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta2 with SMTP; 22 Sep 2000 08:24:51 -0000 Received: from welfen-netz.com [213.6.141.128] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 22 Sep 2000 10:22:55 +0200 Sender: kai@pop.gmx.net Message-ID: <39CB32CE.62D88178@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39C68F26.C740D0C0@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:22:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I GOT IT !!! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ef527aacde77ce95180d4d6f89bd334 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

Yann Guidon wrote:
[...]
> you local whygee has got his diplom : a master in
> Micro-Informatique Micro-Electronique (MIME)
> after two years of crazy work. So now, i have more time
> for the project :-) Business is starting again !

Cool - congratulations !  You wanted to scan some of your
schematics IIRC, did you find some time, yet ?

Regards,
kai

[...]

 From Yann Guidon Fri Sep 22 12:01:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00372 for ; Fri, 22 Sep 2000 19:56:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:18 +0200 (MEST) Received: (qmail 11582 invoked by uid 0); 22 Sep 2000 09:56:38 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 22 Sep 2000 09:56:38 -0000 X-eGroups-Return: sentto-1101623-782-969616596-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 22 Sep 2000 09:56:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 09:56:36 -0000 Received: (qmail 31212 invoked from network); 22 Sep 2000 09:56:36 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 22 Sep 2000 09:56:36 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 22 Sep 2000 09:56:36 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA10025 for ; Fri, 22 Sep 2000 11:47:52 +0200 (MET DST) Message-ID: <39CB2DE2.EBADCCCF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C68F26.C740D0C0@f-cpu.org> <39CB32CE.62D88178@welfen-netz.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:01:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] I GOT IT !!! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 45c453d17679a7b59387474d3e8b9ef2 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

Kai Wetzel wrote:
> Yann Guidon wrote:
> [...]
> > you local whygee has got his diplom : a master in
> > Micro-Informatique Micro-Electronique (MIME)
> > after two years of crazy work. So now, i have more time
> > for the project :-) Business is starting again !
>
> Cool - congratulations !
thanks,

>  You wanted to scan some of your
> schematics IIRC, did you find some time, yet ?
i'm going to use schematic entry software to redesign the
few gates i have already drawn. it's going to be ok, i think.

> Regards,
> kai
> [...]
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 22 12:01:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00375 for ; Fri, 22 Sep 2000 19:56:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:19 +0200 (MEST) Received: (qmail 9212 invoked by uid 0); 22 Sep 2000 09:56:44 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 22 Sep 2000 09:56:44 -0000 X-eGroups-Return: sentto-1101623-780-969616595-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 22 Sep 2000 09:56:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 09:56:35 -0000 Received: (qmail 27059 invoked from network); 22 Sep 2000 09:56:35 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 22 Sep 2000 09:56:35 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 22 Sep 2000 09:56:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA18059 for ; Fri, 22 Sep 2000 11:56:31 +0200 (MET DST) Message-ID: <39CB2DE0.369F9174@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:01:04 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] simulation software Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 84f604a01b354f89d9c458ed266852d6 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Steve Van der Hoeven wrote:
> browsing the gpl projects i discovered this one
>
> don't know it we know this one already...
>
> http://www.freehdl.seul.org/<= /a>

i've seen it and maybe downloaded it.
It's not very much achieved/advanced.
i'll try PICA first. if i have enough time.

> --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 22 12:01:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00378 for ; Fri, 22 Sep 2000 19:56:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:19 +0200 (MEST) Received: (qmail 8774 invoked by uid 0); 22 Sep 2000 09:56:45 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 22 Sep 2000 09:56:45 -0000 X-eGroups-Return: sentto-1101623-781-969616595-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 22 Sep 2000 09:56:44 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 09:56:35 -0000 Received: (qmail 27045 invoked from network); 22 Sep 2000 09:56:35 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 22 Sep 2000 09:56:35 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 22 Sep 2000 09:56:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA00509 for ; Fri, 22 Sep 2000 11:56:31 +0200 (MET DST) Message-ID: <39CB2DDD.3678CE45@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:01:01 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] tex manual Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3f89908209c173b9c3b630256eaf07c6 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello,

i received a zip from Olivier who has finished
the Tex sources for the manual. i'll upload it to the
f-cpu sites soon. many things are missing, like pictures,
but you can use the original ones from the HTML manual.

Now that it is available, we will work together on it
and enhance some parts.

it will be soon available at http://www.f-cpu.org/manual_tex.zip
there are only tex files in it yet.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 22 12:01:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00381 for ; Fri, 22 Sep 2000 19:56:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:20 +0200 (MEST) Received: (qmail 25438 invoked by uid 0); 22 Sep 2000 09:56:44 -0000 Received: from ci.egroups.com (208.50.99.231) by mx19.rz2.gmx.net with SMTP; 22 Sep 2000 09:56:44 -0000 X-eGroups-Return: sentto-1101623-779-969616595-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 22 Sep 2000 09:56:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 09:56:35 -0000 Received: (qmail 27043 invoked from network); 22 Sep 2000 09:56:35 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 22 Sep 2000 09:56:35 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 22 Sep 2000 09:56:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA21706 for ; Fri, 22 Sep 2000 11:56:31 +0200 (MET DST) Message-ID: <39CB2DDC.2D5AB0B5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:01:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5e01da2ae96886ed7b8d34a86ef6aebe Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Michael Riepe wrote:
> On Thu, Sep 21, 2000 at 06:19:52AM +0200, Yann Guidon wrote:
> > the "weird case" is when one writes the same address > > with two different values to the cache. In practice there
> > should be no problem because the first line should
> > be invalidated before the second write updates the data.
> > This is not yet very clear in the C code and i fear the
> > "semantic collision" when going to VHDL.
>
> I'm afraid I do not grok fully what `same address' and `different valu= es'
> means in this context.  A memory location should be bound to a pa= rticular
> cache line, as long as the line isn't replaced with data from another<= BR> > memory location (in the I-cache, at least).  This is a 4-step ope= ration:
>
>         1. LRU lookup -> ca= che line to use
>         2. invalidate line
>         3. fill line (takes a = while to complete)
>         4. re-validate line
i'll finish a testbench soon with a clear point of view.

> > > Sorting 1 million strings with 1 million characters in them = is beyond
> > > the capabilities of today's FPGAs :(
> >
> > i don't know how bz2 works.... sorry ;-)
>
> A good description of the BWT algorithm is at
> http://www= .dogma.net/markn/articles/bwt/bwt.htm

thanks, i'll have a look any day.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 22 12:01:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00384 for ; Fri, 22 Sep 2000 19:56:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:21 +0200 (MEST) Received: (qmail 9419 invoked by uid 0); 22 Sep 2000 09:56:52 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 22 Sep 2000 09:56:52 -0000 X-eGroups-Return: sentto-1101623-783-969616599-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 22 Sep 2000 09:56:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 09:56:39 -0000 Received: (qmail 31273 invoked from network); 22 Sep 2000 09:56:39 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 22 Sep 2000 09:56:39 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 22 Sep 2000 09:56:39 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA18105 for ; Fri, 22 Sep 2000 11:56:36 +0200 (MET DST) Message-ID: <39CB2DE1.D68DBC2D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8qdk7b+tub5@eGroups.com> <00092120461900.00384@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:01:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] schematics (was: 1 bit loopback adder) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 401b4149d075f5b992997bd4564e68a4 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Jecel Assumpcao Jr wrote:
> On Thu, 21 Sep 2000, Rares wrote:
> > I'm looking for tools that have those symbols I'm not going to sp= end
> > hours drawing arcs and lines for gates when I could be designing.=
> You could use gEDA (http://www.= geda.seul.org/) or one of the tools on
> their links page (extracted from http://www.opencollector.org). I would
> recomend Electric (read the manual at
> http://ww= w.staticfreesoft.com/manual/index.html) since it runs on
> Linux, Windows and the Macintosh. And you get to simulate your circuit=
> to see if it works once you enter it into the tool.

if only i took the time to read Electric's manuals... i compiled it
but i wonder how it works. can you explain us and give a short introduction= ?

> IDaSS, which I now have running on both Linux and Windows, is for high=
> level designs and so represents everything as boxes that look all alik= e.

can you describe your installation and use if idass ?

thanks,

> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Fri Sep 22 12:04:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00387 for ; Fri, 22 Sep 2000 19:56:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:22 +0200 (MEST) Received: (qmail 31393 invoked by uid 0); 22 Sep 2000 10:00:23 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 22 Sep 2000 10:00:23 -0000 X-eGroups-Return: sentto-1101623-784-969616818-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 22 Sep 2000 10:00:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 10:00:17 -0000 Received: (qmail 4007 invoked from network); 22 Sep 2000 10:00:17 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 22 Sep 2000 10:00:17 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 22 Sep 2000 10:00:17 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA23481 for ; Fri, 22 Sep 2000 12:00:13 +0200 (MET DST) Message-ID: <39CB2EBE.AAE64305@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39CB2DDD.3678CE45@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 12:04:46 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] tex manual Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fcf64f8d19bbaf79e9afe14ec324fbdf Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

Yann Guidon wrote:
> it will be soon available at http://www.f-cpu.org/manual_tex.zip
> there are only tex files in it yet.

ok, it works.
have fun.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Jeff Davies/CDPTEST Fri Sep 22 12:17:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00393 for ; Fri, 22 Sep 2000 19:56:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:24 +0200 (MEST) Received: (qmail 14638 invoked by uid 0); 22 Sep 2000 10:19:36 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 22 Sep 2000 10:19:36 -0000 X-eGroups-Return: sentto-1101623-785-969617970-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 22 Sep 2000 10:19:35 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 10:19:30 -0000 Received: (qmail 26995 invoked from network); 22 Sep 2000 10:19:30 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 22 Sep 2000 10:19:30 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta3 with SMTP; 22 Sep 2000 10:19:30 -0000 Received: from modem-62.endostatin.dialup.pol.co.uk ([62.136.92.190] helo=sargon.chrystal.gbr.xerox.com) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13cPvU-0004wX-00 for f-cpu@egroups.com; Fri, 22 Sep 2000 11:19:29 +0100 To: f-cpu@egroups.com Message-ID: From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 11:17:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] schematics (was: 1 bit loopback adder) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 23ca853015cc2b8de5ba87005e6525fa Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!


>new_bit = !(!(((source1+source2)+old_carry)*!new_carry) *
          !(((source1*source2)*old_carry)*new_carry))
>new_carry = !(!(source1+source2)+!((source1*source2)+old_carry))

>This might look more complex, but will actually save you 12 transistors
>from the original design. If you make a schematic, it doesn't look so
>bad.

Actually you don't need to do boolean reduction manually anymore. Xilinx
foundation and I think Alliance (the GPL one)
convert your circuit into basic logic (AND OR etc) and then do optimisation
which includes regular expression reuse and
lots and lots of boolean reduction. So you're best to draw it how you can
best understand it, then compile.

Jeff Davies


 From Yann Guidon Fri Sep 22 14:34:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00405 for ; Fri, 22 Sep 2000 19:56:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:28 +0200 (MEST) Received: (qmail 6351 invoked by uid 0); 22 Sep 2000 12:30:20 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 22 Sep 2000 12:30:20 -0000 X-eGroups-Return: sentto-1101623-786-969625812-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 22 Sep 2000 12:30:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 12:30:11 -0000 Received: (qmail 1179 invoked from network); 22 Sep 2000 12:30:11 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 22 Sep 2000 12:30:11 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 22 Sep 2000 12:30:11 -0000 Received: from f-cpu.org (nas1-248.aub.club-internet.fr [195.36.150.248]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA06666 for ; Fri, 22 Sep 2000 14:30:07 +0200 (MET DST) Message-ID: <39CB51E1.66E574B1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 14:34:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d50d3b9f2164287d1ab5f80a17cb57bf Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi !

Michael Riepe wrote:
> > > Sorting 1 million strings with 1 million characters in them = is beyond
> > > the capabilities of today's FPGAs :(
> >
> > i don't know how bz2 works.... sorry ;-)
>
> A good description of the BWT algorithm is at
> http://www= .dogma.net/markn/articles/bwt/bwt.htm

impressing :-)

but nothing forces you to take 1M characters in input.

OTOH, trying to optimize this algorithm with SIMD would give
us interesting instructions for the F-CPU :-)))

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Fri Sep 22 19:05:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00417 for ; Fri, 22 Sep 2000 19:56:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:31 +0200 (MEST) Received: (qmail 4852 invoked by uid 0); 22 Sep 2000 17:10:00 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 22 Sep 2000 17:10:00 -0000 X-eGroups-Return: sentto-1101623-787-969642569-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ei.egroups.com with NNFMP; 22 Sep 2000 17:09:58 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 17:09:29 -0000 Received: (qmail 9777 invoked from network); 22 Sep 2000 17:09:29 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 22 Sep 2000 17:09:29 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.217) by mta3 with SMTP; 22 Sep 2000 17:09:06 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA03341; Fri, 22 Sep 2000 19:05:25 +0200 Message-ID: <20000922190525.59439@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: <20000921003204.26719@thrai.stud.uni-hannover.de>; from Michael Riepe on Thu, Sep 21, 2000 at 12:32:04AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 19:05:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" X-UIDL: 35984f940b287697c1a937a4745a11c2 Status: R X-Status: N --Kj7319i9nmIyA2yE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
eGroups My Groups | f-cpu Main Page | Start a new group!

On Thu, Sep 21, 2000 at 12:32:04AM +0200, I wrote:

> > what really bothers me is how we can lookahead. what smart idea
> > we can invent to predict the tree's behaviour. that's really tricky.
> > now i understand why it's limited to 4 or 8 lines in practice.
>
> Time to draw another picture.  Later...

Here's the LRU-CLA picture.  For a CMOS implementation, we should consider
some modifications: a) invert the EN input and the EQ output, b) use
inverted logic in one of the stages.  That will shorten the critical
EQ<n> -> SEL<n> path to at most 3 (inverting) gates when we use two CLA
stages (5 gates for 3 stages).

I also wrote some VHDL code corresponding to figure 1 (the unmodified
version).  Feel free to correct any errors you may find, it's my first
VHDL coding attempt :)

------- chainsaw -------
library IEEE;
use IEEE.std_logic_1164.all;

entity lru_cla is
      port (
            eq : in std_logic_vector(7 downto 0);
            en : in std_logic;
            sel : out std_logic_vector(7 downto 0);
            eqo : out std_logic
      );
end lru_cla;

architecture lru_cla_1 of lru_cla is
begin
      sel(0) <= en;
      sel(1) <= not (not en or eq(0));
      sel(2) <= not (not en or eq(0) or eq(1));
      sel(3) <= not (not en or eq(0) or eq(1) or eq(2));
      sel(4) <= not (not en or eq(0) or eq(1) or eq(2) or eq(3));
      sel(5) <= not (not en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4));
      sel(6) <= not (not en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4) or eq(5));
      sel(7) <= not (not en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4) or eq(5) or eq(6));
      eqo <= eq(0) or eq(1) or eq(2) or eq(3) or eq(4) or eq(5) or eq(6) or eq(7);
end lru_cla_1;
------- chainsaw -------

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 --Kj7319i9nmIyA2yE Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lru-cla.gif" R0lGODdhNATCAvAAAAAAAP///ywAAAAANATCAgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZGQYAGhpq MIpQGiSaqiC6wFqT6mp6ugqgBDtLinsQq3ULSvsLHPzmW5vAS1tYLNyqerl8rCtrTAE9Tb0L azgcMMxNWsQtjj2ea1OeLQu8hG6efv2N1d5NXp+L3TY/n40fqG8PT9M/ddH6TRj47h4yf/io 4TLo45vDft5MnWuYMOPC/nAY3RGkd6+LxIweARLrCDLaOmUo43mDaGmkR40wJchM+ZHcoXj8 dBLhOdPdPhhAcZI0eqSoS4cfe8FcyqAoGqUUMUrlQzVZ0ExZVW610LXpUYYNaonjGBXir6Ev gLptWBOV2rnNRNKt6xXO27S7vv7Zi3djJcBar0YgnLfvTp/gcMbVcdbvWpMyIiMlafiHZcRj rWy+G1LOZ74pM+cZjVehQMZ7tWFArbUzoFsW6Rl7nIO2ZLOUY+i+HNR0j9+cgV8hDto27jLI SU/c5to4VK7RWz+/0Dy139mMu/Hz/pM1XbYuYCc2PsS8WPRV1B+Vpsa9ud5kFUuvunyRfJDk /h/svwldWerkdxFpyfTHQnHBEbiDgkgJB4WDPEH4SXID/iaIhAZRiIiGRnF4n4Hs/fVUQWiJ KBR9bT1VVWxIhIUZg0/AuFscNJaGYX3a1YjJjcEgWBaLLo7ox01wyTiDkS02xmSSLS253on2 TVeSXce8ZyEbSg65XR9bntclJF8SdAqIY2KmSDtQCoHQTD8iOUKblwnGJmX/OLOFnOiA+IWe WXLX1EDwSeLnNESKKOehWPkSWm115qhcM3yKYE1Pkg6qGaMF4UfnFJWqtimcXnwaaZAsQbpQ p5GQupGqQaIqzaSeZCqFrBGKyhyueNiqn66z8soBsLNKOaOvTggL/gaycygb4LAZMIudsc6m B62T0rJTrVPXipYtQ9tS9y1Y3U6bG6ZGuCqPufmoy924RbJL7jWVwRtvvfbei2+++toikqdn hNuvIwATMvAzr/wacBQFn7vHwvmQ6zAlER+GMBcTl/dvw49c7OW+EHDsAMh3iEwDySmYzAPK M24Mscf+HeyJykT5a4bMTdicbMsuC1hyxXnSzJzGAuu8cyswd4JzC0lTmrEeSyc87NMEH82J 1CcDTYbVDA89rdb+UL2J1yaIvQHZGDvNctdFRwW2QFCvXLPQjZidBt1Ytc3V28c2fVraztot d2U+94L1GIBH5HfUaxvdc8x638z3rokP/r54k75RLk/hYhw+3OSOV+6o4J//XGvkI3uONOih Xz464aXHjTbXf6tun+ipW6z5J4HrR7TqSXOeM+6vBx373L2D/jvmx+UefN+yK047eEkq7xnz fe6e5vGVJ996FsAfZLod3++tdvTc3066wuHXMT7k5dN+ftWPM9E+CfXfcD+/7/uOd4/zs7M+ OuQvCQMUHvz6ZzADRiiAy0Kd/MyHwJj8T3/Ec57x9oe8CA5mggRkoGgcGLboSc92D0zfAmFn QUYU0IQZbBz6XKc+FEruedQrWvxCqEC4VXCGF5wdBF1YjWIIcYhCNBwHX+RBG4HQbT+cXgWI CMUo0osKK6yG/vVGhb1EVNF7IrzhYS7mLiBs0SZXPCIxlpi3JpLQJmAcI3bMuLUdno6G3due BndUgjBqBo7hSKJe0Og/NbIuiCrQI+JySD45ig+QCTwgENlYSDeChY8/8eMZ6fjCFjqRkCeT 5BMpmR5LusGTYtTe4rz4sTYaEZHuUyT7GClBQc7siarcHCjZJMqHYbKE/HvkFyO5ShYmMmtZ 7JAp1/Y7KeLpBIbsHCvpl0stwXKDsqwTMG35TADKcI49hJ4jz1VL3WWTgsQsngqPacMXhbN5 MDyhKwU4TYl1UZ3XFKcwW1nOFPIOg3ZMyjqvN84ObnORu8ThN4k1NlKCL6BIHOgr/gvKxIOG p57s5OLw8snDc/LzlPTsZDDbqUOMclOjPpQotSgK0HtC06HwhGgaTWpNj2JTpdp8ZwNdGkiY ygWlWGRoUqK5BoUesqS9BCdPb1lTd4qUoN2s4c7qZ8hmpgyppWTpTZtaR47686g+VWpIPzrS fRL1lOgqF1dpSsUydlWXWM2kDaMTUxRItUFU3aNVP4jTRiJTU3FlplApttZK3lWJeY3lXkk1 nH/2FK0CtSle28rLpxaxrwkFa+YuatmHQtagb1WmZz8L2rIG668fq+tQl6pZknqzs3wVo2JN +1PMzjSjYl2tZBGbstcGFp9fnW1Ys7dRj+E2t2cF6WVj/uhYwm42omRd5k5lak/j8ta3TFWt U/fl3OfKlbQv2y0uB/vHwlJTp64trkUZ29Dkhne5Ly0qQvPI3ZDBdqrgvSR7c+reiUK3osf1 KnVTW9vrCrej281s9WQb3d9qEZ1PJbBfDdwetaLXvtbNKjIdXNn/Hhi5qG3pffWqyffaL748 m3AcO3zVCrtVq0bdb0qlu1L1UjjAFk7nVl28WBgnFcKPVfFqprgx0VrupDiebx8RzF8AAzdm cAWXkKGqWxP3droJri6NnZzdwbS2uy0usIYjjOQXK9iYSJvsM8zMZRHHicRs8y4qgBqfeAoM zVoe7pVu7OUqLy/MOR7zTpgc/tpAC3rQhC60oQ+N6ETbGQRzhYyRHV3fUcp5bnSWWKXb3OUH fzmtfH60nslctUsTStSrwDB8eSzhE6N6vT4+M6Tq3GT54lnTnwYzh1c94yWXOcsxibWsM53h WnP61ptWbqt7JOQgAxnK5u3vef0rbGNfObI1/rWaKcVmxklZsDKWtHjlGdw06zfPSd4wtMud 4mlzVsDavnYIGp0bT+Mg29b28zYY3N6FAvvUxe50elHcY3Uzl92lnnWw0T3sc4vZyrom+Hit aHB+R9vfse02W4+d72qX2N2Mpvedtx3KSF9c4BlfcWkjPmJcK5ycKh95wzWOX31z/APwnre8 8Qfn/rpRGshOS7bH57XsN6J8zS0f5pQRLu3F8NpbT1ahrzcu83HTGukUV3W/c32qp5Po1Zju 0JbrTcahY7voVI4xwJNOMFIvatG1gw7bhwzYfaf86itv7NlZ7favb13v7c471wv+SbG/++dt d7bR6e7ytCt68YxvvOMfD/nIS37ylE90s/cM8u9aXJpaVHvDPF94xfMd8BCXO9ERf/iyL1zJ ov/72kf/caXDfnVhN/2zNkR4uJv76Kv3sNdd76XZ0z7rSyd91InsgVjlfoTP5n2fGe73mtul +MaX/RSRxOzkK5/sZnf+zZ9v/V4F3enjD7ztX4N77u849VTHOqgx3nWS/se/9u+d1ISWn21P Ln/4vpf/ILA/acxHf1L3HeKCR99nV8Q2ce73Z98Weu93fHF3bcuWfqineixngXHmgEUidB9W fRJIgCuhHLxwf+qHgReIgG52NxsogAs2SS94frIBJiPoWd5XdUe2eUEVgCtofvDXdwOIfGkx EXBVgjDYfYaHgiqYczzogx8IgUAIgkFoIpw0gyeXhAp4hAvobR74NUbof04oblLYKAehC2Zi g1i4flqYeE/ogj34hbEXgdolg6/yEABIP8l2glnYflqCh7lSfuLjcx0IiH8Yh2FIWRJXegSk dWiYh72nF4sYVJAIh8siifxniDZSiQ94iZtI/itFZoXqBHzsl4Z7WDfC9y+mqHsnEYqaCHaY uIqp2IqfGIJz54Yc8XajiIvgp4qoaDigB4t8eIt2KEC+2IKyCIVyeHCFKBe32IjNmIKeQYy9 GIyDiIrCSInT6IXHWF6eyImuVXk8Fyep1nyu+I3laI7niI7pqI7ryI7t6I6Qd3lguIy8KIiD VHdKWCHMuDnEuH/igo21+Ij/mIjKGBFRFouPQo/Z2BbiiIS7+IrSWI3U+IrWyC0CSZDzd4i0 OJDg9JCvcUcVd3eR2JEQSX2WOEq8SJEVmYnF2I0YiYyIeJHe2IcAeTaM+IzHsZI1k5P9GC0l aZJQd41Np5DGmJGn/keTtqhHqKSHjhiQ0mcLgbgrUHmUTckgKRmFRTl2QwmSzPSRVqeGnKdP 2hhwYgmUrEeUZ9mSxMWNB+mV9tOVOBiSW0hbZIl3dPmDZpmW8liWL6mRMal5cvWW3BaXa5hu dimXfjmJeMmWe5mXkGGQjNmW4ehLV6hjY6mYkIl2aLmYdXmVmomZiRWPiflvXDmZS6mLhXmZ Lomanqmalsmad/maDfKYrQmXpLlJ95h5OmdOiAmWG9mZq9mYP0mboLmWnxlyV1OauXiT45ia sAmcm+mcrhmcrGicshmawnmcgJmczoiPOaiBU5mZ0/mLnBmboimeBVKcw5mdtrlGonia/tIJ n9VJmNCpl+R5nlbJl0bpm6M5NoG5nskyk8VCiAA6oL9pMVK5n+dZKwjKm9SpntaZntFZm/25 nXZHoAF6hz7poOmioeMpod6zk/VomNDYoSxJn+Z5omYVofX5n3nkn3/ZJwl5LChJkqKFn3lC o1qZop6So+D5oChakNe5oTBKobd5hu0RjTNqkdMXkTrKoU3qox9KolCaoDvqoRBKbg16WmQ4 ee/GkAuqjzfDj/u4pAb6pBMpomaKk2VantjJolg6dVrqTEFEeV56gzz6jnmqp3vKp33qp38K qIEqqPC4okAqmJBUqCN6qEw6khlKpaMypk66po+qqENKRZEa/qVvaqhqmaWVuqW/lKhqupWM mpNiyqbaQqmiiqSnaqUmeqaZeKOtmn2dqqpvRktC2qYteqCNaqoriX89WqUg+pCxKp+XOqxp mqtX6pi46qqLmkrM2qpVRaYYii0lun8dSazCKpSZuqmTen3Iep+m1peeOqdkCK3FqquMSpLc OqVVCa67SiHZKqVnyq6W6qbduqyhqqzSaq76qqAJOJgN+a93aq8Fu3vkKq+Via77arDNyqlx Sq70RYUQWzZferBf2bAJJ6c86bCaeq8fi3nB+qMgy7D4M5vzaqsTm4zBYrG2FrAZ27IJy5zJ 2rH4KrCy+q4Li560SrMS2688+ywt/quxGVizN6uzHCuzJFu0IbuxOTuy83ayHguwiAq0Hkmw F0uKSju0taq1Meu0KGu0T1uySzu2rxC1Nju1oFq1XxuZ74lUSMu2aIu14SqpuZm0DTurFNuz dHWrBqiyLHu1Lqt+cFu3Uju3OFu4M0u39Vq2JXO2XQtpf5tKVfkt+reEXitySku4jEu2nbu1 NHu3jeskzLpFMhKvFGinNtmduGm4gouwORe6nou5nBu7Zku6Rxolzyq5GuBGJZopBfqUwDuw sim8iCug8Rq3mqswDPq6iQu583K77okiVEu9HTBGvOqY1nor2uu8Mvmt3Su62butIgu2MEu8 49u04Cu7/qPrr6Xrt337s8l3vL4rvh1ausAqp7l1rOp7v/tLu8n7u74KwGNbu44bvZSZu/5B ualbrTJqsqwaHhAstvqbqqCrpBW8uOQ7j2jKvwO8vtDbvrg7h9OrwAwcvA58ERKMkBzMuefL whostxT8wunbwvULqx4cu3m7slybtroLv9ULuI46qENMxEVsxEeMxEmsxEvMxFB0wKZJwj4M xBXbq9hrtiq8wTesvi6sxf9bxV0Mw8r7xRqawzgsrvqZv3y7uyW8xlYrxKUKtVjsvWCcxuUi x2L8xmRsxltsw3rcwX8cgzRXwJEbv2wEIczSv3BsxwJ8wfbrwTJso3s8xsJR/sZ83MeULMlh bL4gvLYT7LNTHDL2W7nbS60pjL4N/L01zMUEUsmNfMiZXMd9rMkEDMtiOK48/KlSvMO8u7zg KMOq7MJePL/CPMsB7K6AXMwFWbxHW8tYOXiPrMaFDJNBzLoTisspW8yWi8yx/MnNS8wijLfN vLfs28nlm8tsXM7J3MNQ7MnrnMHgTMuWXK40nM2zW8/bbMtoHLHRDMpZSXNC687RGtDMHLit XM14fM+qa86da9CzqM/X3M26PM1UrNBtq7P8Ss/wzNDQfM7v7M0HHc74DNEGHMLSe4APzcuB i9H73NHGC9LxDMwRbcEizc4L3dAszcl6O7w298O7/hy0Kj3Q7dzSBF3RMTzI8/zRGW3SNi3O O00Uj7vJPN3GHWfCS23RQo3U16zN34zTMu3RWm3PSg3WgkfV8izV0nzLKV3UzjrOWT3Tax3S Mc3PSU3XCIzQYt3WvgHV4XvW/fzMjAbQQ43VXu3SGn3Tdh3XCf3SG03TTr0iT6ycJ+3Po+XL frXMQIe8Zg1fl83Uv6zYeH3Fmc3VYx3Mn13Xbz1z2sfR8dbTE92TpTx43CvLoG0tp0zai5zK pj3Slm3bqE3bmJ3bvz3BR63XkM2dXJLWtGTF2Oa/cczIcs3cz63bjtvcwr3Q21Xdp/3V1C3d 1t26xP3Uxm2haqvTXIrC/rGNwXp9x1Ed3TOs3eqd3kStzpsd38Pd1PDt3rft3TFsuyWN2DRI qLybpPSd37Vd4I7dcesN0w9c350N3Qne4N9930+t4Iw92nkd3v5d06ESeZTdxB8O4iEu4iNO 4iVu4ifep+LNn0zzvP543hB+4PhNx13d3jOu36Ed4/LNzTXuxxe+3cBt47793hdN0unM33Nd 1R+s3C8uyBXO2zk+2DxeVodt4EH+4wJN4FZe2EO+IhVO5VcepBoe2Wrdure33OjtyJecH+At 5Ws+4RTe3Vx+3U8eyY295The5z5+5xj+2GJ+3D895+hHv3TOypBc6Jq9ZrI93dwd3HJe5tjd /ttgbt+rvOh7LukP69NYztpuGeVL7jW+SzagvtoJxdkS7tn7fdfOfcx6ruOqzuqT/uqY7toI XqEU/ei2juR87qJ2/qIWPt/IGeum7taXLuy/rp3BbtRvLuvJrel9neR87caETeSFpOzteeO7 DeyV3uqbru2wbuzsieqJHe4mq+KjmuQqQzdsvuvIPkvszt5F2u0OLu3ePu5KDu6Onuy8TpxG 3uI4B+4yk+6jfu/X7uwET+uS6e4LnuvEnu8PzukJ7+v1jucB/u3n0EmVLb+CHejZLvEr8OXN PvBCbvAWr+/yvuPwXu8fP+1ATvEn3+vRbo8LD/Ioj+/tHu+3zvE1/i/uhJzy1R7zOq/wQP+c 1vzw1l7wul70HU/tJY/zx37zDT/vJi/0Ac/0UK/0DHjV/1zrRkrjND/yva7yW1/sV+/0PV/1 Nm/2EM+xLP7fgG70/u7wCP/0aD/1QS31Xy/2Vl/3Gj/2ex/3U6HRMC/gpV42zIvthizac2/m iZ/2pM74fl/xCkz4qY73G1/2kN/4Xdj2gi/okd7knr/yX6ToZD+5oE/vXR/Ko4/5qE+HjV75 fX/4Ic/wlC/yHGjV1mu9+NvmpJ/6cf76i5/mak/omHz2O4/mea74QR/7Xl/7s2/8tr/5oz5E rC8MUG75vW/9sP/52a/3yy+EEd79zZ/7/l7u87QP98kf8UIfn2wt953P/a/9/u/+/fGv/Nuv 5duO9NV//6f/+/C//3dPAPHRILljXXySVmvhPVnPrj4w5DQyPNFUXT3WZc23AejavvFc3/ne /4FB4ZBYNB6RSeWS2XQ+oVHplFq1Lk+xipbClXgjYId4JjOf0aX0estO9y7kFByTddPbIzsb 391/5BICs3ji/joGNw7R+r4WDfUiAd0EH+skES3zJik7PVESP0FFXRrD7govOddMxzT9+FI3 MzHVYncgV2l1bVllYXlzd4d7O0NbiIWLl5WbSZ+hj6Gdp0t0mM9wqYF9c7Bnv2W0VZPJw1/G wbcda9dLr91d/tvN48s+j/Ff2YPp+6v/+QDMJpDQjXLZcBzk1s2Gwn0O0SU8d2qeOkYS6zHI V3HhG4z+OoJ8OFGep438LKYMqXIkQZfiXpaKiaghxIg1UK5EiNOmvZxmDPbUqI8ipaAkfQqt xBFoTaRDmRZVikAa0ZJTFUW9+nTpTK8qqn4NK/CkMatJjZ6F+nOgVrQZu5p1uxarCLZA1cbl SjUv33t9s959K1Lq3q+H/SIWjLhs2rl67wC2W3eOZGSGJzteDJnwVrgwLDf+HJjyqMeJKYvu PFhxa9auPcMmjbny6dmRbWceDTZ077+5L+8Ovhqd782oaY9NbXw5cOWyqz1/KX2a/mpWzDU3 P77Cus6WxGU6xy7c9Hbd4JELp86ysPrx6G9Dl72erHy6tMtrl2t+OHu84gE06T3/XvvuugD1 S06U7gz0rj34ziPQvpnoA6jCBS3LT8Hf+GOwrQ4HfCPEBkl88EAQEdxQwBTdYxHCCS2E0cT5 MhxxRkZsjO3EBFtcEcUfS8uxwBuJ1NHB/4BUkccXZayuySFb8xDJJXdUEj8h7+txPyqPhNLL 4lyUkDMx0wsozC6zfFHKJwm6MLon1wQzSdzmZBLLMdHEE8czSzSyT5j4LPJLPQWVk8s/0yQz PkXZjKbRMqGLM7w6q9TyykD9LJTQKa20lLw7Ic0zVEQ3/gWUUlEXRTVCVR/FsNX+aAROQ0/N PJVU0DAddNQPD9V010w5pZVRWG9NdU9bfTU22VWLfZXDR930MchcExWR2lIN7VRNV5EFVldl g9322l+/5W1ccMsldll1nXXy1Wi3vLTbdGcVl796h5WU3GyFZVVf7kBFt9pm2TW1V28HXvff duNlE953rqChoIiNmJjiiC2+WOMgMt7YYyg6/lhkkUMe2eSTfWDY0Xej1HgElFMGBOYoXp4Z 5ZptzhkInHXu+QmefQ76Y5WfeZgUo8FC+oFQJFasaZpUftoaogl5mep7mFb66qpl3rpdqb2u FM6Wsbba6ayjRjtsDNRe2yOz/t2eru24mwSbbn7HPrvsrvXm++u57xYE8MC5G5zwog0/3DW7 FcdXRq25NiZxueF2lvEuICfb78bnmJxzVCr/XHPRHYcx881BR92ry784XfLQFWc9DNct95z0 i2C/fXXaLe+979dVp9D2x4d3W/YxeG/1+BmSP3x5jZrXHXPpZT0s+tb3hvr3qRl+XnDSvafq ejiLp77w3M1vc/y8lR/dqPKjg1++8DdYnyz5qadfAfuNxz99k/hnOt8xRmn6W5r74hBAGPiP agY0oO4cqECvRfB/u6ugncSCwFigj3LBaxQFRQfCC86OgyPsXAlNuCAJzm+A1isgA1WIQuLJ sH80/vyfCFP4DhvmcIM8TJh9VnjApjBvhwv0IPbUJw4YxhB42puhhZaowZjgcG0PTKIPsRUr AjYlBlS8xRFJeD/qeFF4SCPjfKyoxCJGKo1N5F7/ghhGLApMiy5UIuPOuJNE5BFrbfweGMVo xij+wynxWyNsCmlBQP7Nj4acIx0RKcWkEXGRanTiG6FoyUva0Y0JJN/9DonG7XmSbo2sThwj ybJRCjFy4itiGvXHx03O8oSVPB8oBBlKTepyl6QUS1VM6QteEhKYqKTkIwsWKSnyJHiyhB4+ 9jhI8UGzl2wDIDU7aU0oYpOYw3wfN3/pzfiBc37GjFILw4m8aB4Tk9ZY/ictp8dFW2oTnh55 5/vECbF5CnOfp7xnOuuJyFia84/IJOiwmDi7DMBjf+z0Zc3q95GB5vOZET0KK43YzwUu1Bv1 AyBF9bk/iTbPmS5hJkMxqsiAopGjI32iQdGpUiRuoYuD9N5ENdpOOWZ0pfyk6UdzmrqfZjKo p3yoTI9aNzkEE3HIZNaEgni8k3a0odDj5VRd2lOrXqSlF2VqSeUpUq/msqhctWghmYpLkKKi q2hdIVjP1lZmppSNTk1mHQFaUVrCdZr95Cvb/nlLrd6krDodqhgLy1PDljGxPRysCwNbV6ce lFUJ7avM7PbXuSaQfn9tXdaC6dmC4Cybhx0n/mm72dhuoDavSWUpa8tpV8oSzLJVxexm+frA j8TzsbylSSLVqtqZ/nazuBNuK91Z3NrSE6mcVe4Ve9vB26YVqDBV5Raru1jpaveTx3WYNBsn WtmC166u5eFs17Vcn3IXuux9qXtr6N27iXey5C2vaeeIXoQ5srS+bS1z32XfDwo4cPQ1KIHv izzZxlR42YNvaqMrSvkqda0FRvAIDZxg8+ZQv/RysFAfzN8Qx3bC792wCTOc3wtr2JWTZfAU X1hhhMi4vScu5YrjG+HyppjFw83vi7cLYhuDssRE1THReBw7HN9wySymboGBbNIYF1mHVBbx kHM84vw12XxJ7rFD/rHY4R8aGZ9WFqyWJXzktNE4bl7mMJcT/OT5RrnGjkXz0eDcVDNLVs0h zDME/zzeBV+Xk/31cXPxq7xAS/LQ5120n9n8ZTmXks5ENvRO/5toaD0au33+nJtTCOove9TF hM702/ZcS08X+s5I5nTtIs3kWDtZzCatNJmFDGBE+1fRsybxqsP76mD7Os61btOtiXkxoPls 2UIbQrOdXQVoRztn06b2tdPhXGxvm2albl9cKWbtmYmb2xfVdrm7TVx0j3u663Y3ud0d71/8 2NQfzOKx98W+pzrv3hckgbHtne9R1waSA6cQsvG6b1uPuW4ebqDDb9dFg1sE4JRm+MSn/ojw xaWXWxcHIsejBvIQivyRXKh4FUmO8Y4HHFopp5PHWbjfsJl80BAvuctVDquT17zl37Z5dvqt TJlPEOf8Hnqci45xmuc8lT5nOcxX9vMMHv1qS7eu1H1odaabC+tbF1vDnR70oiV9OmTXt9gh aHYMq33UWvf61MPusK7XSuBQnXvP0S49ib89PjtHOdT5vnK5o5Og/yZ63Y2X9/wp/r6GDzzA EP/4Zz1d0c8Ft9/VOenKa955wA28uSVvsdBbT+Mxf9yc1z5wzFN+9ARv/cHrHXfTJz71bX99 5G+P+9x//fQhB3ubUWzw1Q9+9zUqPq9YL3uhA7/2ki7+8FF//vz6xB7vArS4v4X/fOlXb/t4 +/3Xzj7z4Kte+92Xl/m5Xv3Sw5752Cf/7qF/ffSPnfrJXz7t3W97+M8fg/wvnd19r/far4Li b/pyrwDxz/8mj/jA7/v+Lv+cb/8UkO0mEPAYA8nC7/AgsMcQEAAr0AI/8F5ILwCtbwBvKPsk MAR1TwU/Be4aUAAT8ATf7wBZcAVrsLJGsHsycGs6EFf0jwZv8K6CcFpWBwMdUPyajwPL7wZ7 MOvWL+Fm7wEJEAWBkAmH8FjUr/6aLgbTpwmj7va8sOquEPkY8AnLTv5k8AfBcAjDMNTMcOOO UAOncAbXMAjbcPyUz/6gkAfxMAKr/rAG7zAJy1AL4dAEu5AK69AKx9Bg9HAQoxAJN9DJlhAQ F5ERHTELH1EO09APE5ESK3FSMDEU91AMBVHDAtFp2PATQbERd3AUH64UkS4FPVEV048V4/D+ pHATlVAWWfAU5zAPL9EVjTASTXESe5EWIQ8YW3ELc/EQ6fD1fPENkVEIC/EFS5ALuwwRoTEV p/H/Po4EPRAbF+8ZWy8aCbEbKRAd1XEd2bEd3VFwFkCueMLzlobzMCcez6om6NG2Vksem2Yf 9zHZWkAb6BH0lAofxSooApKubgwh61EiCtIgCVBi/BECFtLyaM0hCVK5qAoQUUqsOkhqRJKj FIwhgWck/lvMJEUqdVCS1FRyt4isJW3rcv7RHoFKJllJqmyyb3DyaVhHImUNo2RSdjCS1vhx KLWgIz0yJYWSpDjgKR3PJJ8yGqbSJe3iJ4tykkgDbEiSkrLSsqCyK2iSKd8rLBNDJwNRJMmy K7cqzKqSHwfS5MwRLNfSKlFjLgNMLE1gJzGNLP2yKfUMzOyyLY1LMOFyK9cHK/vSMH+NMAuq DPjy1F4yKfGSgxSTMdtOLhfzMZlQMzkTcShzMXHymkoSM1Vyo0rTMVMTsRhzeSLzi1pz6V6T sWIz89wyNFdzMCfuuS6TtraPJnFznPbyLRlyNK9pOO8SDDgPuNRSN1Vzm5AT/jE/K8AyiziB 8zDbrLiaEzstKuu00zpraiFN8TuTk9eWMjCuEzrh0a3YaTZBcprYs9G46N+ySj7VEz7niii/ kqXoc6xKwj3LqD/j0z6ZjCvrMyUBlHASqSN1chGpKj1Z8yj/0jhVyCwno0Elx0KRwTUlKD/B k6ZOzkPLky4SlDYl1Dkvyzs1VEOtskQtbEX/0gaPbzshNEJ7kylddKo2E0V3AkUxlIDY8jmF 9CB9NDyBMjuD9DNNs0CLtD0rkzS58zRdNDNzM0qpskkJc0p90jN3tDBvdEhhDEvN87vEFD/3 c4KSNEaVNNTSVDcpdDfb1EqnVNK4lEfjZUv1ciiI/nPy8PQs91JNfXAmozKzZjLjEHRQ/3RN o7BP0TNR7ZQUXZIrB5M+z6ugJPUwnWJONZFRr9JRnzQv/RRMm6gnk5QiLfJ0OBUpLfVM/YZU 7dJUjzQwXRUuTdVK+WxWU8pAO69FLVRXYdXRePVQvwcnNBVNgzVSKfU0VRBXldUs3KqjUkE8 ReRZIXIjpVUPqFUhcUEpYyRb9XFbr3XjvHUes61YHWVca/IawjXiHtJMyRUe1hWm0PVU4fVT N41b4/Ud9XVf+bVfS85e/TVgBXZgCbZKC/ZgETZhFTZtAHZhHfZhIbYC8zViKbZiLfZiMTZj NXZjObZjPfZjQTZkRXZk/km2ZE32ZFE2ZVV2ZVm2ZV32ZWE2ZmV2Zmm2Zm32ZnE2Z3V2Z3m2 Z332Z4E2aIV2aIm2aI32aJE2aZV2aZm2aZ32aaE2aqV2aqm2aq32arE2a7V2a7m2a732a8E2 bMV2bMm2bM32bNE2bdV2bdm2bd32beE2buV2bum2bu32bvE2b/V2b/m2b/32bwE3cAV3cAm3 cNdTW6/0HmO1qr4zTn9LrzDLcCU3altyNr9yS8WAU5G1yhR1TCf3c4v2Uqnyed5UNCsEj6TB XEF3dS1WdUmXRTXtyVA3uFi3docWdaGyWuk1JzGSQlHyXVfyKL91d3OVOeMxVXFLR+vRdpmX /mdp9FQZly1rVYhudHYFdXOvl3c96luxk1hrktT69HsVrnnJl2UfFHpFgFGVlztft1qxl3ql t6Wit++6UnwbKnwtsnz112aft1C1V3hh0lYB+H//V33j139XdX63t6aocX8dWGTTU3wNGFAp mFaP933td4IV2HrhV3iLk1UfOIQ/FkIz9YAfVYCLl4DxF4Pjl4TR93cZWHVFeIZpkYTbEnn3 9IR91YQ7OHtVmLckOCytV4ZpuIiv0IWBd31XEjg114OXd31X2IcxF3dVGH1z0oeNOIs51njT tSG893gNlInJ9ZnGCozbtYS9+IuJF1+xqqvWM3iXV4vlGGWTFXw6/neO8fhoRRfSZDSP/bhm T0rvfPKPCXlpF1dBJ7aQFXmRGbmRHfmRITmSJXmSKbmSLfmSMTmTNXmTObmTPfmTQTmURXmU SbmUTfmUUTmVVXmVWbmVXfmVYTmWZXmWabmWbfmWcZlfFwYHwwWh0rFfvFFazo/xvI+X7y5g fLmXjRkEldk3qQ5vd/kUoieaXWGajU9P8U0EITObibASrJn7sNkAu5kvvlmbw3lyqXktSOqa z1Kch/kq3bkFxTKe+6+dYwSc7ZmQ2Bk96TmZ5xmd9/kykiedkWOgAzoq3cWcZ8Og8TkzGFqh HfqeIVqgJXqcKVpyCfo8eCejh2Oj93nv/hJ6nEH6C4d5pOkPok36aD76mIEZGxp2hNnZ7QSv nmV6AWn6l6lOOWpamOVZ594En3e6YW76mQP1/IK6bwlaOUNaXpSapOW5qU+aCKFapcF5qmfa n63aprF6mZGZUF56i42PDFA1rOv5XEplrLlPrJ0ag9Q6qi+lralam+H6qnl5rgGXmgMhc/D6 nbUFLvS6RvLarT8lsOM6SAibrn3zsLUaBxX7b6N5jwobPyAbsdNrshebtiybp5kks4UaoTgb 6Mjjs19OsicabXeZo1s6pylbtRs6tdNFa047oO3lYCxxtvk6X7rabRcGmC57WXhbsxnltztb VYQbtCGkuEd7/jeQm+4wY7l5r1mcO2//ZSzMCDCoG7hR5bqHu1i027gVpbuTGz7Am7lHY7yf O1nMW7r74jmMRl/Ye7t95b29W1TkO7zJpL7JGz3w+7xlbr+t5Tj8G5rzYozmm1QI3L7z5MDz W0wUnL8HpcH/WykgHAu5YsLJEDws3G7jhD7gZcMvvLYlhMMRHFFEfMHRpMQdnOFQPMKfYsUp PCNc/G7X5EKiZcZZvJkFhcZN/E90PMXP+sZBvEt6HMgJZMhffDWMXMatosZ9/FeYnMiP5MmP 3D+k/MOjfMdrMR6qHMeBZcuDvE+8nG495GGS3B3IHMpL5Myn3EHU3MrTvMBdbyLa/pzLh2TO v5xI7FzM9aG63fxG+JzOB+bP79xPBL2YSaTQV3EdEL2oFR2747zR4XtsWwFEiaBkdGvezo1j rM3SoakIOP3T4Y1bAesjM31ijwDU2+2QyfjZNr3VU31nXF3dApjSWf3VQbhrF73gxteivQO1 +5glfF3X91y2hZ0pgn3XszzyTtfRj72Bh721vzbPxa7M+7zZnR0irF3alR3NE33auZ3RvX3N Dd3ZqR3HrX1rwzzcxT0ZFabJ7+Lc033bv/3RAc9N4l3Y7R3Lyd3dbeLc0X3e/b3c1X3dgzng AZ7YidlLDJ7g953fkRzhf/3HoT1sY5y1HZ7EIT7ix9ff/q+9UDi+4l97xNXi4/sc30V+Ljj+ 38dd3vW9wjM+4hu7p7l611M+w0P+5F1+4rEu5svambMo5VWe3XEbzj8D6AO83Ylev1++jwfB 6Lsd6XH+vpe+2O8N6IM+mFk+6tF76qke2Rs+6bmb670e5qw+vQkm1w2j7IV+6P02us++t6Fb 7Mde162+45lG7u3erLG+XOre7aEe7Pke76++r2fetl175W++tNmethG/3gU/tnX+7fV+77P+ ts1WtA1f6+f+6x2dXure61NX8Kkx9CM/7HOb8q/980cf9Tf/bXn+8Aed6lX/rvwep/Ot9ol6 73GfpTVl95l5wOndnx/D9xN+/m3tel5KvuM5H+6Vf/YLJiyc//gZn86hX/QVrvpLX8iTXfjb NquRv9rXvufZwuwLH9vDn/ujgvx9/v/U3/a9+vzLX87hf/11m+Scf1V02vpTJf+zXyX4X/EJ ID5mgB43hC9Kaq+dSuPG+9eJUWiU40mlI7uQ7QavMF3bN57rO9/7qCc3C/4woeEFmVD6jkJZ 0Ui8MR3R5NRWNV0z2drW1X3FcOGwzmmGjtvuNzwuny/rzxY6bV/j6VxE3h6QH0cgIBtdoV4f oaAW4pziHYshlSMYpJ/mJmen59VEpRVj49/kYKnYqYjooykf5Wbozpns6CqI7aslaeItLOqn 8DBx/nEbAHKy8jJzs/MzdLR0ssy09TV29nK1drf39xm4+Hg0N/k5ujn6Org6+3u2O/y8tLH9 PX4+ID2/NV4/QGj/AhLcRqkgQmQDExJcyBCgw4f8Ikqcp+8ixoyJWglTeFCjkS0eQaoQyfHT SFYnPaUEsbJTy5AkM5icWdImzpw6k5R4toHaQFU+FwD1UNNos58xQzII5cxE0Z//JDxdElVl UwdVlZE4qpTZV25Ct17dNxUpWKtLeWaFmpToWqJnvxrcF7dkW7hpuVKdqzat3XB5h/I16jdw Xa13uw4mG3fxzsiS9T3WkPIyE4+YzUK9+bGvVs6dVY4uLde01M+GQ7NG/k3T9GbXokmDhm05 84PYpe9CTr3a9myewFvz9ur79HCXyZEXPzxbN3KZ0XU3V30cem/W2J16nuz9O+UTLblbVf5r fOvftNWPPd5dVfT2XZ2nlx98/nlJ8ctb538rZnaXBUdebeu5R2B9+L2CnmwJClegfQ6qd9se 1aEgnn4AIiFgfQi6Jx17Hu5XIIWHNHgieCmqSAiGCkr44YsWGujfhwG2CCGN5rF3n40u5vjj gzsm2COOL474WpGuESkkitndF+MHS8LYpHFAKrnhjUyimOSR+0lpZZdhrjgmmV1UlmRvZZ0o o45TrpXmm1lq6eOTR8LZk5xTvmdlnExxySaI/m7i6aeWgAYpKJd2/ZmCk1CiOYSaXRqKJJN9 srXonmVquukPZ/43KFNRWlbnloWO2qCNGppIJX2wSZiqqKuG2eiap9qJpar5ZXoojSKW6las utLJ63Ov4hrsgoxWWSyqx15HqpimrmopW8jCNymn2WpbDWOFUVvtX1FhOyywRX1L03iAzbqs Yt6CGmq40OlJrl7mvgsuYvKCSe9bt2JViLrjLlrXuXgBnJjAphJ8L7oHF7Zuq/WOVHC38ZaY 6LYZa4zppxgrxSyr/YFMMV4gQyxyer5Gq5bJCevJob8XXnytshHDTDJjLdeMsqvNHjTzzPNy bArOVAENLa2S2lo0/lI677ox1FHX+mhQU9PLL8NGGu3o1UPzaZLKJ19ILtNNW+3xy1n/yvLZ c3pdZ9L2Xh13nsZWrfTTeZNMd9guS/23pp7umPRudUP7No9oTGy41tLiSDhzjK9NquCN11a5 0I4PrnjfO4+NOOSLz81u25P7h/m+iA/JOddoA/76ipiLGODpGUZpOZgMerlh7RXebnrps/Mu mu4A4k657ZnvIvq0v6+ce/Kp/xK572U8j3z10i/v4ezHt060tSr03rz1dPsofC7ER08+7O1r W/l268WPGvOfTwi0EvVPx33YWD8XdHfmFx/9talX+JPfAenXP68JMEgCTJf32tZASj0Q/mAR xFvKAKigCo7PftdJIIg4qD73kXBTcepXu2LxMMIM5XrGQiGwVCgux/TLfGhJTAyBsEIaAsaG dHlYDlmhl3wBRSDAuxUMh6jDGb7FiC5sVhKBiIUdNrGFPrSYhmjVFCbuxYqka2EKl4iZKlbl iSU8I0ggd7g4XJEGauwU6TzIiTZyCyVxnJEs7ljAPEYMj5qgYx/l8EY0EtIegzxiFAAZSDgo kmeR0OMeWbTIQPHRkXL8IyQpiclJEkuShfxkZA7pFphkklCVvKQbRWmGUl5qjqxEFyk52cpT +lEsrpQlLG8Jyl3iRJVK9CQqU+nLVOKyYbSMpDBfYknXwWuT/suUmTKDmbeFHFOTYIjUG4bJ y21mM5rOlKZNGhnOV15EnDMxJ0nQmUZyhoeb7sSINmP5zHUWs53z1Ig68cnOfOQzI/2Epzff KdA0BHQj9eTnPvHxz3Im9B4LtSc4z9lQQxZ0oBYlpnceitCDKnSixtBoRznqUI8WA6QjvShK 7fgdk1JUpC29pz9JSgyWflSmw6BpSSua0p1SSjI4nalNOxJUlcIUoC6t6VFzmlSg8rSpj1zp UFkSVXlGNJ1T1WVV6VlUhi71pjp1KlgRGdKtQrSWvbxqNTuZk596tatCdStRwyrXRH6VkWj9 plnHCVep7pWqeZVoX7H6V6vOtbBw/oRqYNPa01DeFZiD1WpW9ZlYvCLzrIa9LC3q2s3JOray eiXrRkE71sjGlLMGFe1JMataLWjWDWx9K2pfSlqjxhaptVXqbZma27autremfepuYTtbrgY3 ro+VbHH5mly/ehawvn1ucwm7XMFGF7LHLe10FTtN5w63rNVFLnTD2zXpdje05R3tdWl73tSu V7bpJW57bSve+WoPvO/1rjXX2tjTxhe3/dXtf3kbYOHSt8DxpG5+LZtdyib4swM27nex+2Dl Tpi5BRbvgbU7XutGWL33Ne+H0dth+IaYvSV274Ux3Npj7Be4FUawWhX8Yg0z08Mjxm+MHZxi FSN2wZ1t/jB3TyxfIfuXyAA2soCRTOAdQzfDDM5xkG8MYimLGMjkVTKErcxhLduXyc918o+h fGUqm5jMKOayhLFMYTVbWMxb9vJqwcxfNsN4sTt5bZbd3GU025jPJDbzkOHcWzm7mM40dtuY /YxjO+sEz2sGdJEhfWRBx3nFY3B0mxmt398KssWd5jQbPR1qUNuV0l+2tJlEXWofz1nSSXb1 khU9ZVlXWc9pNjVmCf1pVhca1nnWtIwN/WRg69jXj6Z1mXFtWF2Pmte7nvGwt5toW/eZ2n9G 9pmtvWhlh5XZq4Z2mIkdZWwHmtyRNvek0f1qdcea23L19mad3Wxwt5rdv5b2/pvFPW195xvf e3Z3t1ENClXHm969tvextT1rhdea3/92+K0BHvAeG/zZwg63vyPO8GRvPNsQr/bHry1xp8Lb tQQ3OakLfvF6d7zcLT/3y9Md83WPvKklZ3HKUS7vb6/84DNvd8i3veGHZxzkNU/pzS99cpzv XOXGznTRRR70hU+94VEX+tEtmvRU55zpFZ93zy3+9Dpfneplt/rQNZ51lG594F1X+tu53nSd f53nYz+08oiedqOvfaBtp2vc3T53r4cd7HeP9t6lfnaOV53xffe7wAE/eLhPXu51dzrCoZ54 rCO635s3++Pf+fciYJrsn0d7jRV/esev3uOLd33r/l0eeoGO/rCVF/zl6V54u2fe9KnnfN7V /nrZz96dtW/C0imfe8IfHuOxh3njYf970E8f9cXf5fF7UHq811f4z5d59In/fZqHH/rDN//1 eXnCLh6MIllcgSJZ2P6fqSuIv1+/Qa6CzW7h8Jf3xxMZsQ009Z8Udd8LsZ8A/gsB7p8Z4R9f 6B/f1J//dd7XBKCi0N8CLkb8OUYCukQUMWD2pd+mkUj31NFyoE6MUYfzWMcErVHajNAltEkL XhD8lKBfzOAR1eCQYNQJSo7/EMcKehAONqCcEBB8CCEIBd/3GCHrZBD2iCDknY9ixCAloQ8F PuGn6Ed/WKESBs8Uyooc/nGhAXrhKIHhjIihC0KP72hhGK7O/0lhGU7PGbrhFX7PWLDhHF7J G0KIU+BhAaHhBUEh7KCg/TXh5uyhwtiKI+VKF2IQWphhZTHiGDpiWMhhJIYPDUrOCvFgjagN sFUGzCwiJuagJooLJ/5I2byg0SiiNEliGgoiCRGiC4RiMFFMIz3GdJyi3TSiLG4RJOaXLcYR LtJiLQWjzYhHLprg19Rh6RwCMSKTMYriCzwjMKrNLSIjNapVNMIiN8GPiUwMJ6rMUlyjrOTG LCijOB6BMCqiOVpioKQjM1LiqYAjOu7iJHrjKNDjDdrjKy7hN57jPvoMLxbhP7rjocDjQLrI /jwCJAvyYyByo9SA4ibCxS4ooBHKxjUiTBlyzsIUSUZOZBElk9wIyUeaIkUeoUUi5D1iiEae JEe6i0euY0uGpDw4JCnyH4fQJEXYJBHi5ELmhkhe5IiEIEQKXyj2IUrKIE+S43lMoSFGyJMw 5YI4ZTgu5TqWI1XWo0CupEI2T1405Fb2owR5ZVK+o1UeI1aO0lOqpFjKI1mu5VkWpfppolk8 JdyoI1pWQGjYZVy2IjLupS6GZSbyS10GZsxw5Z8UpjLeZTz2omK2yjaaFS4C5mL2pWT+ZWfw pWCKlVxqjGNeYF4ypjTq5ReGJk9+ImbG4WiKpl+SQWmu5mnqTWqe/qRpbmYKziYD/iBrXqZr qmZrLiNsOkJugo4ndmYs5glD0uYW0mFC8uH0DGeIMCdiRuf22CUg3qRzVucpXmdPZucRQueB SGdbys5zhs76xKZuEk0H5uHuIGJ4audicidRGqfVUUcj9iAW8iZx3Of+/M/m6WBFmqd/2mGC 2eck4ieB3ibx8GcDyWJ66uNDNqgPMlBymhGCNqOC7ueB9qcTVh99vg8AIiAVNkwGwt8XceCI GkyJBp0DFpHxuJ+oaOCJWuAvkqgUFeB4hmj+vSgG3igIzqiI1qiK+qiMQiaKCqlPvh+L6ugD 8ugAEqmJfmghzae+bR/pzYCV2t7VUam0/mUp8mkbl46Xl2oflibfNf2clKpImHbNmJLpkupd d/JdnKrenGJdm/JAkd6eYT5kmppQ5AnTf/6pLTWmoN5Nc8bUhMajKyUqf2ISo26oowbqOj1q n2bMmhoMoVrVOJopFajJnZLppgYea4Wqnl4TqS6fEHgqp44qXlbqcVZEP8AorKZDj84qO8iq rY4DruZqO9Qqr5LDrv5qNwSrsMaDq7pPsd6qryarNxArs06Dsz5rOSyrtGJDtFZrGaUktlor tW5rPRwr0mWTQomrQ5GrIZnrR6FrSanrTLHrTbkruKpWXRWq+LjWuNprueLruepruvLruvpr uwJsvMorvKJE/sGyxMHCRMLO0cLqwjHc68Pma8QOrG/NK8Re2sWaScaCwsYmUseS3sd2Ssg2 AcV+WcP+0cmmAsZK7Mru68T268v+a8wG7MyW7LKlrC8IbEfgbCTwrCD5LBsBLSMJLdH2gs1e lsWyrMYqLccyrcc6LchCrchKLclSrfYdbZwVbc1Grcu2LMx6rcyCLc2K7bvqrMGaLdaSnNaS Ldd+7dJ27du6bdPC7dzK7dPS7d2mbWElLd62bdjG7d/WbeDm7eD67dgC7uEKrt5229oiLuEm 7uOW7dae7eQiLNoq7OUybOYu7kXxrd0aruSyLeWKruVWLuaaruairsOSLueyXeMq/m7k7uzm ouzsqqzjyq7q0m7u2i7stu5OeW7hTm3fCu/nEm/wVu3wIm/xKu/xXq3vMi5dgVHpwpH0ni71 Zuv0Il/1pu71JhH3ai/2Wi/4eu/qjq8EPq/ogdn25lFArW+kRu/5su/Ake/7Xin9skj7hu+i zm/81m/34ij6dqP66q/8wm//7a8BAzD+8u8BF7D99u8CJzB4dlP+3u9GVDAEBzAoNTBBcTD+ DrAHXzAIK7AIY/AEm9wJ1ypQpfCT0itiMDCVhnCnyrAGTykJz/ANdxoLp+QKj/AOMzAMu3C7 mHAM57CpGrFd/XCoKPEDE7EQ17CmIrE69DATkygV+/AV/ptwFgOxV9HwET+xxGhxF0uxQ0Ax 5HmxSG6xAatxE7Nx97rx+MIxqBYxGk/xGFexippx+lrwDGcxCPtxBQPy/Apy9BKy/Roy9SKy 9urxHmdwH98xGf+MIoPqJOMpHTvyqFZyZoGx+6YqJxNwBzOyAHcyMEgVKfOCUJ2yK6QyKOPC orZyKZOSKmMCJNex0coyLKOyKGOfExkvLvPxKtvRLLsRIKtvMbfvMfeuo+ZyMJsyM9PyLove 68auL4fu7Y7uNWevMmszNXMz6OIu60YzGgEv5H4zNm+z+KLz96pz+bKz7oZzO3ezOI/zNJsz 85ZzNYNzNqezPK9zP8ezPfNz/kDPcwmRszW7M+/+8zvvsz8PNEDn8zkrdEI7NEG3j0HrM0Ln 7O5qNDwvdEb3bO1yNEM/9D1XNCFddERT9ERDtDeztEC7dEPDNEk7b/LStEl/Ekq3dEljtESL 9Ef/bEiD9EYLdUev9E7fdCzWs0wvQk3j6cjadPM6tdVKdVPTwlNTNVKftFIfNVe/dFfH9FfP NFZHtVVPdVlXNVNnNT0HNVAPdVsXtU/3NFGPtEfL9VvTtVFDtVonNVsHbV8P7V9vdW+SdVoT tivztErHdWLvtaUK9lj/tF+7dWTD9VxDNmBL9mVT9l1bNmObkGOftWZPNl4r9lLn9WMftF2L NmcH/vYtd3aKeCtsx7ZszzZt17Zt3zZu5zazujai6rZv/zZwB7dwDzdxF7dx+wNv02lyLzdz j1tz8xY19CH7hegPlUUBRjIsSfeOAkr1ArA2RfcQN6lEYlGMUvcm3+F0r6LDrChdWHJjkFGU EpGSjp9ahreLOqB8l/cNcQR4l4t4m+htfGBx8LdCaPd/73eASyCUjuRzI5VmgJClSKKEcmZq iNDWfNCAgmaqXqhEQlCHKhB2r4aF8wcEZjiH4vFpjLjZmLi+KGencjhLSngS1ktmwXjJYPiH v+Yq2TiCGxCL9xAYN3gYJUv2WA9KFg+ysOKZCkvHrCJ1tueQ7ziTgw9o/pQ4+8AgHh/leZaj BV25hlJ4ygyI1lj3lu9OK2h5ke8LkvtGPKG5l6vhm3NojU85VDZljnAhOwa5kE9gfuY4JY5G i9fm4ZxqJzaqKlbKgNQNhIpSL0JKlx+ioh76vPginIu5KjV6oqCOULJWeiKNoi9QZSYoKn76 /ex5TkUKCsrL3lA6mPumqDvIqkPqx2jOnsS6oev4q4unTV46zkymK9pjO3qy6vC5baY4irs6 hooNcLZ5r2NppWTNo5u6Svkol5f6yAxKoFNTrwx6q1J5iJwEtdM5Hy6NNZ45mVd7zjxLWB47 n7t5hVsLQj74JsO7p0s4P4b4I247rB/wzWC7/i0bk75vCaGz5QDpuZA/eLogTLcXfEcaRrZr u31ze48L5ndDoMITSw1BO7hb/A5hqsXcO7sDEQq9yeo0fIXzab5HfOO8H4OPunuvd4szIZD3 xaabw8ePuTqa/J1Hu7T71Qyhu49fO81rUCaHOc5PiEMe2M+Le6E3edO7t9PkktEfJq4/cs9g ZOLEeWa25SwlY6lYubd34kosPZHj+NT3ycMPqteLyb0Q/Cj2fGe1PJCouicWONEX/Z/DiK2j /I3n/dzXPc+fd7LvPNXc+oqnOgzF+jPLTK53COBHet8jfqJTTdoPqoPufdBzPdxfKZsbDt3T ibzz/eVMKKG7vKxT/pAPNvuB5G/jKxDoFyenYyj2aro5YvJcOKjjv76HBpDnBw3tL8ec+31s uuKvb/4Fd1DYW4GSr/npIKkQwaDTMz3zZ31hE1AJQugASSf2EzP0J3+A8rx8isKjT395vieU n375088OUn/0Y+SZI3+dw6SY6yFtMjr82yByiufCG/8H57j1UzoBAMG0jNV7zDlW7UWUNpj7 5h4wjErPMkZsNTf36850rl4pfueY5TX8N8kgI1uwqOJhfDfmqRl0RknSZ7IHqy6ZixQKaAR2 rUmttCw8EL/mX3o3vpyLUyeSPqfnqXB+3/8HDBQcJCw0POTrohHRGWoUW7x59FKJJHTL/mn0 eHS05HyzZLRL5MjU2ZycFA0tBdW8bJV8/cRUU5WlHO2rlT1tfYX6zGXRheNdhRRm/WVtFjM8 RvWlRc31xR2GjkWeENaTdq58+0YsNz9HT1dfXy9mv3qPH3SXr/eyxzcez+ev6v+HAvAfPYHs CO4pmFDhQobpDvJ72PBQRImFKFactw+jQ40bz130+AdkyF0d75FEmVJlvpHynq0s9xLmxJYz 49S0WQNnThE8aZr0qQ8owqBFjdrcaVDm0URLmY5Z9pSMU6lXkuaMWnVFVq03i13tGlYsILBj zZ5Fm1btWrYFy7aFW/VtXLp17d7FmxfpUL19pc71G1jwYMKF/g37O5x4r2LGjR0/hswWcGTK l/hWxpxZ82bOMS93Bg3tc2jSpU2fVjwZNWjVq12/hh07ZWvZlGnXxp1b9+6Po3mfvv1b+HDi xYMXF3wc+XLmzUMrd34XenTq1a0Pnn5dsm/t3b1/P5wdvFnx482fRz+be/qN3mRSLalT1fvy 7O3f1+4N202LnLLhR2QOIkQ7KYoBAUQwQQX9wAOPgMha4471FgymJwkI1KkGCxWgsEMPPQQB iwxHtEzDPeprzg5PMESMkQs/hDFG+1R0pcCMtqpRRqg0cuPFEklE4Q4dhyQyv32QCHFCIFsk p0gzXtSARSOg/MBJK68kzoUH89hJ/kuiUFzulgY2yUBKcHAgc0ws12RTtluQ3KFLYOBsc0oO yVQSMS/LxLNOP/98Ds0v48zTTnLARE7FLbyixb8lfQyhUEAnpZQuOvnrpVFgtry0TkUlMbNJ QiWttFRTyeMxRyYZTNXGNkO8c8Mbl6wS1FNvxTUvWE9UddZY1QBUQFcDAbaFYXNFNtmzGoxw S1azaJZN9w78kZtOglQ2W2270s9FJSTttpptORq3XHNT60g5RIMl9Vx33/2rVXvW9ZNeeO/F FyJxWLJ3zX7zBThgdULJjiuBMT04YYXF+nfhYx2GOGKYGpa4yYovxnghiiXeOGOPOW7342pF JrnkejqG/hhlk1eGV+WFXWY55nFhTphmmW9G1maBdca551J5Bhhon4euN2SicTw6aaUtXtrX pp+OWWh8pYa66gWpbtloq7feFut3veY67PPAPpdssc/uzuxy1Ua77ejY7lprt+cumu5n7cb7 a7mfhjtvv2vrO9vA/yZ8tcGTPbxwxQNdHOnGH6808Vwlh7zyxyi/FXPLNw9v76Y15zz05Dxf GnTRT9eVdKVNR711S1VPmnXXZ19L9kltpz33sXD/U1Pffwc+eOGHJ754449HPnnll2e+eeef hz566aenvnrrr8c+++ZF1757778HP3zxxye/fPPPRz999dffVHf334c/fvnn/qe/fvvvxz9/ /ffnv3///wdgAAU4QAIW0IAHRGACFbhABjbQgQ+EYAQlOEEKVtCCF8RgBjW4QQ520IMfBGEI RThCEpbQhCdEYQpVuEIWttCFL4RhDGU4QxrW0IY3xGEOdbhDHvbQh5qZ1rzgk41oEGNH4CqW Z7jzDN790IlHgF2mpmIrdwxRBhkZhxWJtZ4zONGLatmVENPkuCZU8Sv9wdHeLtLEL3oRTNF6 lJqqqCYybnErTLOjSKLYRj5KRBxtmEY3eiQuYjjiYc6KAI2YuMhBMsmQjNoPIbshnyxeqxRU iAQX+rjJ9giKBJOcwhJAqQtQroooVCpkGbGQJE88/nJEoxTRJDPpyhascpFCwCMndYmPN7nS lzAQ0SlJaZJhjrFAUKyksXhVAlgys5nBCGYy2DCBXVYzIXsq5S/B0D5TMo2Uq5IDLaFFRz2M QprH7MQ1DBTNdIrJmu/U17fqoE027GiKqSykOkkERXkm0p10KuUTAoqwMgzUmPBEqEuOBEx2 gsEK9DBnutrQTwkNagv/TOYnM6pReKzTmd/aY0JF2ilVhdOTyqzjPLFFTovW81BdLGdGDRpK S/Kplje95EdFutN2LFQUeOqiIlwRSJDiVKe2AlI2U9XIFkWJGcosKBdK2lCgRiqkPLVmONop VUxsw1uUPCdIAamJVtInXBNf/U8cvcpRcS2CkUPlhVt9QE02YhWEhLJrXokWRr32NWpO9Wtg WaZPwRbWsIdFbGIVu1jGNtaxj4VsZCU7WcpW1rKXxWxmNbtZznbWs58FbWhFO1rSlta0AikA ADs= --Kj7319i9nmIyA2yE-- From Jecel Assumpcao Jr Fri Sep 22 19:53:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00426 for ; Fri, 22 Sep 2000 19:56:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 22 Sep 2000 19:56:36 +0200 (MEST) Received: (qmail 10862 invoked by uid 0); 22 Sep 2000 17:50:53 -0000 Received: from ej.egroups.com (208.50.144.75) by mx06.rz2.gmx.net with SMTP; 22 Sep 2000 17:50:53 -0000 X-eGroups-Return: sentto-1101623-788-969645054-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 22 Sep 2000 17:51:12 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 17:50:54 -0000 Received: (qmail 28843 invoked from network); 22 Sep 2000 17:50:54 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 22 Sep 2000 17:50:54 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta2 with SMTP; 22 Sep 2000 17:50:51 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id OAA02754 for ; Fri, 22 Sep 2000 14:56:48 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00092214555403.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 14:53:35 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] logic optimization (was: schematics) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ccbb8c7e0069889c462a242034cc30f2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Fri, 22 Sep 2000, Jeff Davies wrote:
> Actually you don't need to do boolean reduction manually anymore. Xilinx
> foundation and I think Alliance (the GPL one)
> convert your circuit into basic logic (AND OR etc) and then do optimisation
> which includes regular expression reuse and
> lots and lots of boolean reduction. So you're best to draw it how you can
> best understand it, then compile.

Very true, but in that case you might as well draw it as a simple box
marked as "full adder" and be done with it (both programs you mentioned
should have this in their library, I would expect).

-- Jecel
 From Yann Guidon Fri Sep 22 21:48:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00331 for ; Sat, 23 Sep 2000 12:31:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:31:53 +0200 (MEST) Received: (qmail 15414 invoked by uid 0); 22 Sep 2000 19:43:45 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 22 Sep 2000 19:43:45 -0000 X-eGroups-Return: sentto-1101623-789-969651820-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 22 Sep 2000 19:43:44 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 19:43:39 -0000 Received: (qmail 6124 invoked from network); 22 Sep 2000 19:43:39 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 22 Sep 2000 19:43:39 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 22 Sep 2000 19:43:39 -0000 Received: from f-cpu.org (nas3-102.aub.club-internet.fr [195.36.145.102]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA05919 for ; Fri, 22 Sep 2000 21:34:53 +0200 (MET DST) Message-ID: <39CBB776.2C04F137@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 21:48:06 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (c) LRU C code Content-Type: multipart/mixed; boundary="------------3AEED27E67A4AD23944135F3" X-UIDL: 35ddb108d605d841c56c1e3beb18b766 Status: R X-Status: N --------------3AEED27E67A4AD23944135F3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hello,

i more or less debugged and tested the LRU algorithm.
The result is included in the 2 C files.
It's under GPL and there might be some bugs still hiding,
i haven't completely tested all the side effects.

The LRU algorithm works well but it can be enhanced.
the invalidation is particularly interesting, and i have
not yet developped an idea where the LRU queue can be
tweaked to ease the hardwiring, but it's probably too
complex yet. LRU update after invalidation is not even
necessary, the performance impact is negligible in a
normal use. But the project is not normal so i keep
the idea somewhere in the back of my mind.

Because they share a function (finding a cache line
containing a certain address), the address bus used
for reading is also used for invalidating. The code should
be rewritten to contain a single function, acting
differently whether the flush signal is on or off.

there is a lot to do but it's a good beginning.
i'm reading some VHDL books to understand how the
"for" loops can be used.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con) --------------3AEED27E67A4AD23944135F3 Content-Type: application/x-unknown-content-type-C_auto_file; name="Test.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Test.c" I2luY2x1ZGUgPHN0ZGlvLmg+CgojaW5jbHVkZSAiY2FjaGUwMS5jIgoKdm9pZCBwcmludF9M UlUodm9pZCkgewogIGludCBpOwogIGZvciAoaT0wOyBpPE1BWF9MSU5FUzsgaSsrKSAKICAg IHByaW50ZigiJWQsICIsSUxSVXRhZ3NbaV0pOwogIHB1dGNoYXIoJ1xuJyk7Cn0KCi8qIHRo ZSBmb2xsb3dpbmcgdHdvIGZ1bmN0aW9ucyBhcmUgZm9yIHVzZSBmb3IgYSBzaW11bGF0b3Iu CiAgcmVhZGluZyBjYWNoZSBsaW5lcyBpcyB1c2VkIGJ5IHRoZSBmZXRjaGVyLCBpbnZhbGlk YXRpbmcgbGluZXMKICBpcyB1c2VkIGJ5IHRoZSBtZW1vcnkgY29udHJvbGxlci4gVGhleSB1 c2UgdGhlIHNhbWUgYWRkcmVzcyBsaW5lcwogIGFuZCB0aGV5IGFyZSBleGNsdXNpdmUgOiB0 aGV5IHNob3VsZCBiZSBjYWxsZWQgd2l0aCBhIG11dHVhbAogIGV4Y2x1c2lvbiBmbGFnIGZv ciB0aGUgc3luY2hyb25pc2F0aW9uLiBUaGVzZSBmdW5jdGlvbnMgYXJlCiAgTk9UIFlFVCBj eWNsZSBhY2N1cmF0ZS4gKi8KCnZvaWQgaGlnaF9sZXZlbF9yZWFkX0ljYWNoZV9saW5lKGxv bmcgaW50IGFkZHJlc3MpewogIElhZGRyZXNzX3JlYWQ9YWRkcmVzczsKICByZWFkX0ljYWNo ZV9saW5lICgpOwogIGlmIChJY2FjaGVfaGl0PT0wKSB7CiAgICAvKiBzb3JyeSwgaGVyZSB3 ZSBkb24ndCBzaW11bGF0ZSB0aGUgZmV0Y2hlcidzIGJ1ZmZlcnMgKHlldCkuICovCgogICAg LyogZmV0Y2ggZGF0YSBoZXJlLCBwdXQgaXQgaW4gSWNhY2hlSW4gKi8KICAgIHByaW50ZiAo ImZldGNoICVkXG4iLGFkZHJlc3MpOwoKCiAgICBtZW1jcHkgKEljYWNoZU91dCxJY2FjaGVJ biwzMik7CiAgICBJYWRkcmVzc193cml0ZT1hZGRyZXNzOwogICAgd3JpdGVfSWNhY2hlX2xp bmUoKTsKCiAgfSBlbHNlIHsKICAgIHByaW50ZigiaGl0ICVkICFcbiIsYWRkcmVzcyk7CiAg fQogIC8qIG5vdywgdGhlIGRhdGEgaXMgYXZhaWxhYmxlIGluIEljYWNoZU91dCAqLwp9Cgp2 b2lkIGhpZ2hfbGV2ZWxfaW52YWxpZGF0ZV9JY2FjaGVfbGluZShsb25nIGludCBhZGRyZXNz KXsKICBJYWRkcmVzc19yZWFkPWFkZHJlc3M7CiAgaW52YWxpZGF0ZV9JY2FjaGVfbGluZSgp Owp9CgppbnQgbWFpbiAodm9pZCkgewogIHJlc2V0X0xSVSgpOwogIHByaW50X0xSVSgpOwog IGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjUwMDApOwogIHByaW50X0xSVSgpOwog IGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjYwMDApOwogIHByaW50X0xSVSgpOwog IGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjcwMDApOwogIHByaW50X0xSVSgpOwog IGhpZ2hfbGV2ZWxfaW52YWxpZGF0ZV9JY2FjaGVfbGluZSgxMjYwMDApOwogIHByaW50X0xS VSgpOwogIGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjUwMDApOwogIHByaW50X0xS VSgpOwogIGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjYwMDApOwogIHByaW50X0xS VSgpOwogIGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVfbGluZSgxMjcwMDApOwogIHByaW50X0xS VSgpOwogIHJldHVybiAwOwp9CgovKgoKb3V0cHV0IHNob3VsZCBsb29rIGxpa2UgOgoKYmFz aC0yLjAzJCBnY2MgLWcgLVdhbGwgLWFuc2kgdGVzdC5jIApjYWNoZTAxLmM6IEluIGZ1bmN0 aW9uIGBpbnZhbGlkYXRlX0ljYWNoZV9saW5lJzoKSW4gZmlsZSBpbmNsdWRlZCBmcm9tIHRl c3QuYzozOgpjYWNoZTAxLmM6OTY6IHdhcm5pbmc6IGludCBmb3JtYXQsIGxvbmcgaW50IGFy ZyAoYXJnIDIpCnRlc3QuYzogSW4gZnVuY3Rpb24gYGhpZ2hfbGV2ZWxfcmVhZF9JY2FjaGVf bGluZSc6CnRlc3QuYzoyNjogd2FybmluZzogaW50IGZvcm1hdCwgbG9uZyBpbnQgYXJnIChh cmcgMikgICAgICAgICAgIDwtIGhhcm1sZXNzIHdhcm5pbmdzCnRlc3QuYzozNDogd2Fybmlu ZzogaW50IGZvcm1hdCwgbG9uZyBpbnQgYXJnIChhcmcgMikKYmFzaC0yLjAzJCAuL2Eub3V0 IAowLCAxLCAyLCAzLCA0LCA1LCA2LCA3LCA4LCA5LCAxMCwgMTEsIDEyLCAxMywgMTQsIDE1 LCAKZmV0Y2ggMTI1MDAwCjE1LCAwLCAxLCAyLCAzLCA0LCA1LCA2LCA3LCA4LCA5LCAxMCwg MTEsIDEyLCAxMywgMTQsIApmZXRjaCAxMjYwMDAKMTQsIDE1LCAwLCAxLCAyLCAzLCA0LCA1 LCA2LCA3LCA4LCA5LCAxMCwgMTEsIDEyLCAxMywgCmZldGNoIDEyNzAwMAoxMywgMTQsIDE1 LCAwLCAxLCAyLCAzLCA0LCA1LCA2LCA3LCA4LCA5LCAxMCwgMTEsIDEyLCAKTGluZSBAMTI2 MDAwIHJlbW92ZWQgZnJvbSBjYWNoZQoxMywgMTUsIDAsIDEsIDIsIDMsIDQsIDUsIDYsIDcs IDgsIDksIDEwLCAxMSwgMTIsIDE0LCAKaGl0IDEyNTAwMCAhCjE1LCAxMywgMCwgMSwgMiwg MywgNCwgNSwgNiwgNywgOCwgOSwgMTAsIDExLCAxMiwgMTQsIApmZXRjaCAxMjYwMDAKMTQs IDE1LCAxMywgMCwgMSwgMiwgMywgNCwgNSwgNiwgNywgOCwgOSwgMTAsIDExLCAxMiwgCmhp dCAxMjcwMDAgIQoxMywgMTQsIDE1LCAwLCAxLCAyLCAzLCA0LCA1LCA2LCA3LCA4LCA5LCAx MCwgMTEsIDEyLCAKYmFzaC0yLjAzJCAKCiAqLwo= --------------3AEED27E67A4AD23944135F3 Content-Type: application/x-unknown-content-type-C_auto_file; name="Cache01.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Cache01.c" I2luY2x1ZGUgPHN0cmluZy5oPg0KDQoNCiNkZWZpbmUgREVHUkVFIDQgLyogMTYgY2FjaGUg bGluZXMgKi8NCiNkZWZpbmUgTUFYX0xJTkVTICAoMTw8REVHUkVFKQ0KI2RlZmluZSBMQVNU X0xJTkUgKE1BWF9MSU5FUy0xKQ0KDQp1bnNpZ25lZCBjaGFyIEljYWNoZVtNQVhfTElORVNd WzMyXSwgSWNhY2hlSW5bMzJdLCBJY2FjaGVPdXRbMzJdOw0KbG9uZyBpbnQgSWFkZHJlc3Nf dGFnc1tNQVhfTElORVNdOw0KaW50IElMUlV0YWdzW01BWF9MSU5FU107DQpsb25nIGludCBJ YWRkcmVzc19yZWFkLCBJYWRkcmVzc193cml0ZSwNCiAgLyogYml0IDAgb2YgdGhlIGFkZHJl c3MgaXMgdXNlZCBmb3IgdGhlIHZhbGlkIGJpdCAqLw0KIEljYWNoZV9oaXQsIEljYWNoZV9o aXRfbGluZSwgSWNhY2hlX3dyaXRlX2xpbmU7DQoNCnZvaWQgcmVzZXRfTFJVKHZvaWQpIHsN CiAgaW50IGk9MDsNCiAgZG8gew0KICAgIElMUlV0YWdzW2ldPWk7DQogICAgSWFkZHJlc3Nf dGFnc1tpXT0wOw0KICAgIGkrKzsNCiAgfQ0KICB3aGlsZSAoaTxNQVhfTElORVMpOw0KfQ0K DQovKiBubyBpbnB1dCBwYXJhbWV0ZXIsIHRoZSB2YXJpYWJsZXMgYXJlIGV4dGVybmFsbHkg c2V0IGJlZm9yZSBjYWxsaW5nIHRoaXMgOiAqLw0Kdm9pZCByZWFkX0ljYWNoZV9saW5lICh2 b2lkKSB7DQogIGludCBpPTAsIHRlbXAxLCB0ZW1wMjsNCi8qIHJlc2V0LCBqdXN0IGluIGNh c2UgOiAqLw0KICBJY2FjaGVfaGl0PTA7DQogIEljYWNoZV9oaXRfbGluZT0wOw0KDQovKiAx IDogc2VhY2ggaW4gdGhlIGFkZHJlc3MgdGFncyA6ICovDQogIHRlbXAxPTEgfCAoSWFkZHJl c3NfcmVhZCAmIC0zMik7IC8qIGNoZWNrIGFsc28gdGhlIHZhbGlkIGJpdCAqLw0KICB3aGls ZSAodGVtcDFeKElhZGRyZXNzX3RhZ3NbSWNhY2hlX2hpdF9saW5lXSAmIC0zMSkpew0KICAg ICBJY2FjaGVfaGl0X2xpbmUrKzsNCiAgICAgaWYgKEljYWNoZV9oaXRfbGluZSA+IExBU1Rf TElORSkNCiAgICAgICByZXR1cm47DQogIH0gDQogIEljYWNoZV9oaXQ9MTsgLyogYmluZ28u ICovDQogIG1lbWNweShJY2FjaGVPdXQsIEljYWNoZVtJY2FjaGVfaGl0X2xpbmVdLCAzMik7 DQoNCi8qIDIgOiBpbiB0aGUgaGFyZHdhcmUsIHdlJ2xsIGhhdmUgdG8gZW5jb2RlIHRoZSBw YXJhbGxlbCBjb21wYXJpc29uJ3MgcmVzdWx0DQogICAgICAgICAgICBpbnRvIGEgbm9ybWFs IGludGVnZXIgOiB3ZSBnZXQgYSBiaXQgdmVjdG9yIGluc3RlYWQgb2YgYW4gaW50ZWdlci4N CiAgICAgICAgICAgIFdpdGggdGhlIHNlcXVlbnRpYWwgQyBhbGdvcml0aG0sIGl0J3Mgbm90 IG5lY2Vzc2FyeS4gKi8NCg0KLyoNCldlIGNvdWxkIHNwbGl0IHRoZSBhbGdvcml0aG0gYXQg dGhpcyBwb2ludC4NCiovDQoNCi8qIDMgOiBMUlUgdXBkYXRlICovDQogIHRlbXAyPUljYWNo ZV9oaXRfbGluZTsNCiAgZG8gew0KICAgIHRlbXAxPUlMUlV0YWdzW2ldOw0KICAgIElMUlV0 YWdzW2ldPXRlbXAyOw0KICAgIGkrKzsNCiAgICB0ZW1wMj10ZW1wMTsNCiAgfSB3aGlsZSAo dGVtcDEgIT0gSWNhY2hlX2hpdF9saW5lKTsNCi8qIFN0b3AgY29uZGl0aW9uIGlzIHNpbXBs aWZpZWQgYmVjYXVzZSB3ZSdyZQ0KICAgc3VyZSB0byBtZWV0IHRoZSBkZXNpcmVkIHZhbHVl IGF0IGxlYXN0IG9uY2UuDQogICBUaGlzIGlzIGEgcHJldHR5IGdvb2QgcGllY2Ugb2YgQyBj b2RlDQogICBidXQgaXQncyBmYXIgZnJvbSBhIEhETCBkZXNjcmlwdGlvbi4gKi8NCn0NCg0K dm9pZCB3cml0ZV9JY2FjaGVfbGluZSAodm9pZCkgew0KICBpbnQgaSxqOw0KLyogMTogY2hl Y2sgdGhlIGxpbmUgdGhhdCBtdXN0IGJlIHdyaXR0ZW4gKi8NCiAgSWNhY2hlX3dyaXRlX2xp bmUgPSBJTFJVdGFnc1tMQVNUX0xJTkVdOw0KDQovKiAyIDogZGF0YSBtb3ZlICovDQogIElh ZGRyZXNzX3RhZ3NbSWNhY2hlX3dyaXRlX2xpbmVdPShJYWRkcmVzc193cml0ZSAmIC0zMikg fCAxOw0KICBtZW1jcHkoSWNhY2hlW0ljYWNoZV93cml0ZV9saW5lXSxJY2FjaGVJbiwzMik7 DQoNCi8qIDMgOiBMUlUgdXBkYXRlIChjaXJjdWxhciBtb3ZlKSAqLw0KICBpPUxBU1RfTElO RTsNCiAgaj1pLTE7DQogIGRvDQogICAgSUxSVXRhZ3NbaS0tXT1JTFJVdGFnc1tqLS1dOw0K ICB3aGlsZSAoaSk7DQogIElMUlV0YWdzWzBdPUljYWNoZV93cml0ZV9saW5lOw0KfQ0KDQoN CnZvaWQgaW52YWxpZGF0ZV9JY2FjaGVfbGluZSAodm9pZCkgew0KICBpbnQgaT0wLGo9MSB8 IChJYWRkcmVzc19yZWFkICYgLTMyKTsNCg0KICAvKiAxIDogc2NhbiB0aGUgdGFnIGxpbmVz ICovDQogIHdoaWxlIChqXihJYWRkcmVzc190YWdzW2ldICYgLTMxKSl7DQogICAgIGkrKzsN CiAgICAgaWYgKGkgPiBMQVNUX0xJTkUpDQogICAgICAgcmV0dXJuOw0KICB9IA0KICAvKiBm b3VuZCA6ICovDQoNCiAgSWFkZHJlc3NfdGFnc1tpXSY9LTI7IC8qIHJlbW92ZSB0aGUgdmFs aWQgZmxhZyAqLw0KDQogIHByaW50ZiAoIkxpbmUgQCVkIHJlbW92ZWQgZnJvbSBjYWNoZVxu IixJYWRkcmVzc19yZWFkKTsNCiNpZm5kZWYgTFJVX0lOVkFMSUQNCiAgLyogMiA6IG9wdGlv bmFsLCBzZXQgdGhlIGludmFsaWRhdGVkIGxpbmUgYXMgbGVhc3QgcmVjZW50bHkgdXNlZCAq Lw0KICBqPTA7DQogIC8qIHNlYXJjaCB0aGUgbGluZSBudW1iZXIgaW4gdGhlIExSVSBxdWV1 ZSAqLw0KICB3aGlsZSAoSUxSVXRhZ3Nbal0hPWkpDQogICAgaisrOw0KDQogIC8qIG5hdWdo dHkgc2hpZnQgaGVyZSA6ICovDQogIHdoaWxlIChqPE1BWF9MSU5FUy0xKSB7DQogICAgSUxS VXRhZ3Nbal09SUxSVXRhZ3NbaisxXTsNCiAgICBqKys7DQogIH0NCiAgSUxSVXRhZ3Nbal09 aTsNCg0KI2Vsc2UNCiAgLyogb2ssIHVzdWFsbHksIHdlIGRvbid0IG5lZWQgdGhlIHByZXZp b3VzIGNvZGUgYmVjYXVzZSBpdCBpcyBhbHNvIGNvbXBsZXguICovDQojaWZuZGVmIExSVV9J TlZBTElEX1NNQVJUDQogIC8qIGJ1dCB3ZSBjYW4gZG8gc29tZXRoaW5nIGV2ZW4gc21hcnRl ciAhICovDQoNCiAgLyogdHJpY2sgOiBkaXNhYmxlIHRoZSBzaGlmdGluZyBvZiB0aGUgTFJV IHRhZ3MgZHVyaW5nIHRoZSBuZXh0DQogICAgIGNhY2hlIHJlYWQsIGluc3RlYWQgb2Ygc2hp ZnRpbmcgYmxpbmRseS4gVGhpcyBrZWVwcyB0aGUgbXVsdGlwbGV4ZXINCiAgICAgMi1pbnB1 dCBhbmQgbm90IDMtaW5wdXQsIGJ1dCBhZGRzIGFub3RoZXIgbGV2ZWwgKi8NCg0KICAvKiBj b2RlIHdpbGwgZ28gaGVyZS4gKi8NCg0KI2VuZGlmDQojZW5kaWYNCg0KfQ0K --------------3AEED27E67A4AD23944135F3-- From Yann Guidon Fri Sep 22 22:01:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00334 for ; Sat, 23 Sep 2000 12:31:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:31:55 +0200 (MEST) Received: (qmail 11757 invoked by uid 0); 22 Sep 2000 19:57:36 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 22 Sep 2000 19:57:36 -0000 X-eGroups-Return: sentto-1101623-790-969652644-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 22 Sep 2000 19:57:32 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 19:57:19 -0000 Received: (qmail 10832 invoked from network); 22 Sep 2000 19:57:19 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 22 Sep 2000 19:57:19 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 22 Sep 2000 19:57:18 -0000 Received: from f-cpu.org (nas4-70.ras.club-internet.fr [195.36.203.70]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA26921 for ; Fri, 22 Sep 2000 21:57:15 +0200 (MET DST) Message-ID: <39CBBAAA.F2F0810@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 22:01:46 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 248782be393ad8060fd692b2fb4f328e Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

hi,

Michael Riepe wrote:
> On Thu, Sep 21, 2000 at 12:32:04AM +0200, I wrote:
> > > what really bothers me is how we can lookahead. what smart i= dea
> > > we can invent to predict the tree's behaviour. that's really= tricky.
> > > now i understand why it's limited to 4 or 8 lines in practic= e.
> >
> > Time to draw another picture.  Later...
>
> Here's the LRU-CLA picture.  For a CMOS implementation, we should= consider
> some modifications: a) invert the EN input and the EQ output, b) use > inverted logic in one of the stages.  That will shorten the criti= cal
> EQ<n> -> SEL<n> path to at most 3 (inverting) gates whe= n we use two CLA
> stages (5 gates for 3 stages).

well, it's still "behavioural". i'd like to find a way to break t= he chain
anyway. that will be an interesting challenge...

> I also wrote some VHDL code corresponding to figure 1 (the unmodified<= BR> > version).  Feel free to correct any errors you may find, it's my = first
> VHDL coding attempt :)
>
> ------- chainsaw -------
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> entity lru_cla is
>         port (
>            = ;     eq : in std_logic_vector(7 downto 0);
>            = ;     en : in std_logic;
>            = ;     sel : out std_logic_vector(7 downto 0);
>            = ;     eqo : out std_logic
>         );
> end lru_cla;
>
> architecture lru_cla_1 of lru_cla is
> begin
>         sel(0) <=3D en;
>         sel(1) <=3D not (no= t en or eq(0));
>         sel(2) <=3D not (no= t en or eq(0) or eq(1));
>         sel(3) <=3D not (no= t en or eq(0) or eq(1) or eq(2));
>         sel(4) <=3D not (no= t en or eq(0) or eq(1) or eq(2) or eq(3));
>         sel(5) <=3D not (no= t en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4));
>         sel(6) <=3D not (no= t en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4) or eq(5));
>         sel(7) <=3D not (no= t en or eq(0) or eq(1) or eq(2) or eq(3) or eq(4) or eq(5) or eq(6));
>         eqo <=3D eq(0) or e= q(1) or eq(2) or eq(3) or eq(4) or eq(5) or eq(6) or eq(7);
> end lru_cla_1;
> ------- chainsaw -------

i see no "error" at the first read.
maybe someone should compile and simulate ? :-)

i'll try to find a solution to scale that scheme to 256 or 512 lines.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From David Sullins Fri Sep 22 22:28:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00339 for ; Sat, 23 Sep 2000 12:31:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:31:57 +0200 (MEST) Received: (qmail 12757 invoked by uid 0); 22 Sep 2000 20:30:31 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 22 Sep 2000 20:30:31 -0000 X-eGroups-Return: sentto-1101623-791-969654640-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 22 Sep 2000 20:30:49 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 20:30:40 -0000 Received: (qmail 30056 invoked from network); 22 Sep 2000 20:30:40 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 22 Sep 2000 20:30:40 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta3 with SMTP; 22 Sep 2000 20:30:38 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id PAA18229; Fri, 22 Sep 2000 15:30:28 -0500 Received: from eceultra3 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id PAA22735; Fri, 22 Sep 2000 15:30:27 -0500 (CDT) Received: from localhost by eceultra3 (8.8.8+Sun/ECESolaris-Client) id PAA00445; Fri, 22 Sep 2000 15:28:04 -0500 (CDT) To: fm In-Reply-To: <39CBB776.2C04F137@f-cpu.org> Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 15:28:04 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL for loop (was LRU C code) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e7c856ef2d85ffdd786da83d01e40ec2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Fri, 22 Sep 2000, Yann Guidon wrote:

> there is a lot to do but it's a good beginning.
> i'm reading some VHDL books to understand how the
> "for" loops can be used.

Be careful with for loops in synthesizable VHDL.  The whole loop will be
"unrolled" into separate concurrent logic, so if it loops 20 times you
will be looking at 20 copies of similar logic.  This can be bad if you
have (for example) an addition in the middle of that loop.  The synthesis
tool will generate multiple adders, which is sometimes not what you meant.

Here's how you would use a for loop to do something useful:

for i in 15 downto 0
loop
      b(i) <= a(i);
end loop;

This would be unrolled into the following set of concurrent statements:

b(15) <= a(15);
b(14) <= a(14);
b(13) <= a(13);
etc...
b(0) <= a(0);

I recommend just putting signal assignments inside of a for loop unless
you are sure you want to iteratively generate more complicated logic
units.

If you are interested in iteratively instantiating components in your
design, there is also a "for ... generate ... end generate;" statement. 
I consider this one of the coolest parts of VHDL.

Dave

 From Nicolas Boulay Fri Sep 22 22:54:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00345 for ; Sat, 23 Sep 2000 12:31:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:31:59 +0200 (MEST) Received: (qmail 7696 invoked by uid 0); 22 Sep 2000 20:50:35 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 22 Sep 2000 20:50:35 -0000 X-eGroups-Return: sentto-1101623-792-969655835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 22 Sep 2000 20:50:52 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 20:50:34 -0000 Received: (qmail 26313 invoked from network); 22 Sep 2000 20:50:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 22 Sep 2000 20:50:34 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta3 with SMTP; 22 Sep 2000 20:50:33 -0000 Received: from 194.158.111.66 [194.158.111.66] by lh04.opsion.fr; Fri, 22 Sep 2000 20:48:33 GMT Message-ID: <39CBC6FE.6CB4B002@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 22:54:22 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cache (LRU) Content-Type: multipart/mixed; boundary="------------5412722CB03E62939F35D2A7" X-UIDL: 48b1849943192d5671c274797f4ac89d Status: R X-Status: N --------------5412722CB03E62939F35D2A7 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
eGroups My Groups | f-cpu Main Page | Start a new group!


I'm sorry i aven't realy read all the mail about the cached system. I
send the usual mecanisme learned at scool. You can put the one way
system to make something more interresting. 4 ways is the best
compromise.

The question is how to choose in which cached page written. I propose to
make a LRU system for each page of cache. It's easy. You have 4 values
of 2 bits. During an access to the cache, you put the number of the
cached page in the first place. And if you want to write in it (after a
cache miss) you just pick up the last value of the list.

Any comment ?
nicO --------------5412722CB03E62939F35D2A7 Content-Type: image/gif; name="cache one-way.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cache one-way.gif" R0lGODlhcgH9AIAAAP///wAAACwAAAAAcgH9AAAC/4SPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDos7gbL5jE6r 1+y2+w2Py+f0uv2OL49dgT0f3OfnkLYRKKhi2JV4eKCH4IixyFgiqVXpB6lwGbE5CdJpBQoI KspQ6lkIiLpoZtB3qol6AhtFa5ng2Aqwmfkoa2L7FIyVmJnb0Nv4S6nKaFysbDH8iZY1jazb CJn95/zIGl1x/RleNR4bbvhaznIuVQzPLuFO5hv6IRkITkGPO6nOSl+kGtDu1Vuwzt6EfgoF Afwmbx5Bhdy47UrGo9+lav8Xt3nUZzGVN1fxXA2koS6dSZIrdwXRaMplQ4EyZTKMKOZhR5rY YqIMebElQKA6YCKs2RLpTp74PA0luc3UxokIE6ZM+tLD1H3a5N3EikmiNKr+hBorwjAf1kpM wXL46kTUNLgX2LJUKjRrU5UzV15NqFVWp2t0+Z3BpSfxYW2FRXxdvBMqSHg6967KN66x47JG NPvwzISQSL04gYDOuGzEaXyQOzdLTS2P7Nm0a9u+jds27BsYd/v+rXo18OG/ehM/jnyh8OTM cy5vbrz5lOjSQ1CvLuw58+vYm3DvXkg7+Bbfx0cSbx4R+uPl06NdT7y9+yHy53OCbz94fmr7 s/f/14rffwAK+FaABIZ3oAb1Jcibgb4tyCBBDu4GYYQzVJgghhbCoCGBHW5I3oSwfQjiCiT2 d2KJKKSYH4sqUgJfbjLOeB4ZM96oGxcu8vPFXPSIaKIiMfZY41tE6jikFz4epIiQMgCJSJGj 6ehkDFCmsKSRSlbJ4ZHS/OilJUk2WReYWyL5ZJiGSbWQmsSMSWWZmthy5YpcvlDnLFIGNdaZ W+zYpp/igJRBnsDc2Q2ZX2poKDNoWunmPGYqKmaagkr6YaMkaGodnH+Kc9eUnz7a5aXKMRnn n57eIqeWlFqzqjV7FhppKLESM+tJr75p6a6Sojqqqr2mOiiwrAoLqam//7pKLKzDBlsss9A6 m6yv9xkrK6l41gpBptxSAahY1nY7abO8VmvusqIeWym6054qLbvUljruA94qa+uz8sK7brbI 0pvutfH62y7AALbGW651fTvdra5CmWW/uGqbqHUNkRWtxFdwyp+7luF1ocJ91tuwvoGl80xA hUWsIMPvODzaVTZ1VRNdLNOKrzkwKwjUMWYRpbG95b678c44zzlzXoe2GvSigHEyctTzbqva UT9fvBnTLZ8cKrkZS32uwR9H4zNnNosMqrG0BEMYouQ5hnArilUE6M26bs0Z1GkvTPHb7q5m N99N051SyoiBLG7BVBsMONo8DszXXzTJTOjdU/9XjCfCS3+JLdhVgSW5LgUJrjjm+6qLd+qf t1Uz6FgH+u/iAXsNOdg8sf4XOm4lfrnfJPdUe9SSK5078RByzJrJE0vFllzR3dSa3JNB1RH1 ELXddztwG7qR5nwO4j3iG7utPTm7YyxZz85z9PrypfvO9WffqPG50PSXZlDspjdtA45vnJ+/ 95WvTbkooOFMYkBlHNB6g/Lf/3IGLqPNL3Jmq15eREc8/PlkKexz2v2QZz79wU9v6VvLYihT NtyFbxCIEU2Z7gdAc5AvSI9zHdZGR8G8ec6FHkwGCMcWNtmREC9cKYda/KI70rWQMOE7DZB+ WCDlIYMiayEbFVuHRZn/wY5N5xnMip44wygphzKSmaAFrSe96TFGiRazF5amuL98eYxgQtwU HEcYxDiOT4o2qpkB1cjA+PVugLMTY9X4VLwsxtBzchQbHfU4pYCAjnWCzCMeH3lJVD2EKYmh WQgFSMPf6emQSCwlFjXISJ3xUYar3Jrc7rKOylFSdZYkJNFs2SmbKAaRuwTa0UBpyEK+EYIl S+LmhGknYr7scMG8ZSiRWYvKNPN0uMRkvsLFQmWOUpRQ8OU2oXlMZzZMgu8ImTa98wpy1sKc 3FSCR1o5HXaCMwmSnKP76mhNVdpzj/sM4CCfKc5htjMu6uymPAO6zH6yUqHgCqNA52nHc/qH /6HxhGc5swdQamY0nxG06Do9alCMTpOjD0VoNEEqjINqtKMUvWhLPyrCat4TkgsFZklXelOS JtSRM80kP22azIGSEqLoRGlcVKrTk740pEtNqUhz2lOZ/vSfI43qRq3KUp5OlaYNfWpQiZo1 oYamoE5t6lG9+k2ThhOnO8UnVqG61aIZ1TtIfWtbuVpRs9IVrWtNal/tqlSt+hOvLgVqWtl6 WL9OlEMObKwdLuTYyMrBoV+UrGXbANnLapaHVIXrYH362Ua6Na5SDa0+BVvT0Zo2q6pNLWFh ati/kvaqs2Xta5mK2q7GlLar9axr5arX0NS1tsXMbV6NW9jOflWtjv8S6xKw2S2XJRaw3STr WYP7XMpOl7jLRWx1n7TZ8HqzsuLdrHZ1KyDoOgOKldyPeg/x3h2w97nzPUJ8i5Kh+nZGv7R0 L3+JcN8c/He/6R0wG/1b4Nck+D8BxoFd5tNg5yj4e+6JcBgsTBYMnxc7Gg5ZhzdcnQ9bycD0 IbFpTIyp/C64XSh+SYt7IGL1tM8+MY7tcRn84ozkOLoHqrFyf9uiHRdFyNn0EJEdfOQNrhjB 0h2Pj2up2O48GbiMDa+KcTziF8kYy4zVMpaS3L/1TDnISw6Rl4PjBgiLub7VaPN9hJxmNWfZ nTp04yLpiVk5d5nO7Xuw+NAJwwqvuVDjDef/VIo8Ts6aR8MV6uAIKUeUIwda0HOW0wqBIZqz 3FFnjk4Po5lYxkcbcdO2KrR0Pk1oMwJUi7wQ05ht2w5Qz084XMFhnTnN5cyleonNZPWffyzl NcuGeZppMwx7A+Y7czhGwyb2mY2MBOpc+tnBjvb6kk3tPRP4zdnW87bfjO1ub/nb4BY3eF4t MMOg29zvsfYLy7sGdrfbvj6C96Tl/YN1C+3d+E6OvsHXwHD3O5f0VrfAB94xctsP4dCZL3em zfAROXx9ET+1vfMAvn9XXAgXxwM2Dr7x9VYF5CEXeQtLjvIoQiTlLN/1GVsO8zVROOY0BzfJ a+6Qm+N85zzvuc9/Dw70oAt96EQvutGPHvICAAA7 --------------5412722CB03E62939F35D2A7 Content-Type: image/gif; name="cache 4ways.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cache 4ways.gif" R0lGODlhngERAYAAAP///wAAACwAAAAAngERAQAC/4SPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+20MyOf0uv2Oz+v3/L7/DxgoOEhYOAfHFIAYogjWuLhit/EIyUHZdVlJIpfAmZGpeQGq NRra4blQCqFqGsFq9dpqgcoQmyr7GWaLK3F5CKC428krqkt82tn4O0o7fEwhHBX9rEBJ68lc Ok287dRNDWxtfbD97SGJZZ76S47d7KJ+LO4MXEzzGA+UT46A384fYx+uef8MlKsxDtaHTMr6 VRBID9zDggW7QcwFsMo+Zv/1MvbaJNFeuH7+RMpIyC6cr3c9NtaioxIfqmUpz4WcRXGkQQwX eQIsKXOnUH02byUU2hApyJvQKi5zwHLoyZo6S8bsudRSrY5SVz4dgTWUTGXsQEXlenJdR6th Tbg06pCkR6kg2laydfBetYwp7WbV6uxoXIZ/mX58YBHh3qq36LasGxctyqENe/q9CxVjQJjt gnnue1bHRc4xS6skGVTE5bsMza1GFjmOMcM86wAmGrvI6x27aSMeYjtJ7xzDfb80hDy58uXM mztvblxJ6OiiilNPZJ3X9OtqtnPvlf37Ee/iEYcvT4Q8+pfr36hvnwx+m/fyDZ6v31Ld8/38 pwr/5w8gc6To98V59OFwHwwJqnBgRFsYuKBPXkSIQoO5keIfEhSysKFbBE6Y4XgFDjjJiJsJ Z2I6H2ISomwgZmHhXBieqGGKV8ToWIA6Ksdghzv+WMhhKpbo4IM9EueIkDeuKOOMFfqYpCsk akCYjR4iaWUDHZaAI1qOOXlCl6pFucqUmjUJ45EIkvkbjEx+mWYKYjLCZmZuEnkhmFeumeVW d1K5WDJADvqHaq8RiigfE+BlpoR5bsmgoZG+KGWlQwJapJdGMnJon36W+eeZX0Iqp6SlUgpq qkvi2SSpFZr6KqptqgrLm5reGmddncpqJ60a2WpWnafsyqKSva6K6aPr/yTK7B1UVulKs9KS NquvnyIr6q3BegqeXIsKe221x9bK6qiN8QoNWThxm2m4WjZqkrmBFlubha6Gaey474bqaKvn 0ltdsgDru6+1U3QJrbLsQkVVUwuj+S/BBwMbMZzpzKJutnoWbPC85Aosb7sXL0pQv1wwmq+7 VCDsccgDP+QauBVzLLEULGe6Lbokg7xpxy2rPHG52s6ca8AaF13zz0TbTPHP97r1LM8bA720 yNI0jbPM3R49ss9W5xk0zzmD3bXRJvcsbtJkXy302BDfGDXXcFvq9dtQ3Kzw1xrFffbUVett Mdtiz/w0l3zHi7baay/+BN7+Kl02xlIjTbPigf/fjXXeL6c7eeSVf/5345k/rvPWfVNONeSA N+G4y3bv/UnMD1/OOO3ejO564jB3Pnfdr9vOOu5Dz66l7KWvjqvqmLdNuNbR8q4Q3Wmnvvzg Tju/ivGbh/578oJn6zbwNh++7vG1A1/4OcKH77fpiLePPMqXgt888ezJHb3v6MNbPunnjx87 6MFOf9773xJaNzzkSYN8EyHeLuSHrbOxL31gmRYFxyQ9yxVQdMy7XoEsiL3ubVB8B1wf9w7G QIeZT4QQ/Bj9PLhChglwZSmjnghL2MGs2U8t+Bvg9GxIQumYUHk+lFwPaZhB0BHxdjnU3MlS +C0HRpGAOLSeDmNYvBn/ojCJQBxh8Jrov5OBUIo1XOIXrejEB40Riw8s4/ckWD8s3u909QrG FFX4vhN68YKTGKIC7wZFNzbQPu4r5CB/eEI+BjJfE4zSgejzlduwMI+CnCQXmQbG3A2oYeaB GbU01sb+iVKJZlRkANEYRjVyUobp+iQdT9MZfjSjJpzQngb3yL9DatKU6ltlFlvpyzvSIylr ISZbCHlEL+KSX4hr5AenBRtWQmss2DBgKYVJyuq98IqYWCPvapkjvszLltk8Hy/NBkcYdjOY PCSZK+EIlEBZxSPk7OIy55dOboqRKqGBZHCiuRZkxpMy4oQlJeNXSSaiUpNuAk0/VTHLfw5r /ya1JItFDUpLOyYzlFQUYiYTuE53vDMn1SjLIc4pyVu28FcfZV+c9MDK45x0nk+85DWZOUpn vgimv5QptVAqNHuudGV+tKbomBXExiV0fzjVJUhviDloktGmRtVQUaGq1KtIFGN4SKo3lnrP CDYzjgDrauzQ4VXWgXWoYdtmGjeG1uq4Eqha5Cgi3zhWdda0pDga6Wq2xNZE5hKPu3ReXyH6 JNGsFaxVdGsq4RcrfOkRgwQMLF7Fl7DHoi4SpzIjWBZLVQ56i5Fk3esL7AJOWJLGoZS96+ro ujNkEvapaU1EWpaS2oAWlJgLAW1H/6OTnJZWdxz6C0HMwls6hbZ7sP8FDzl1ur1JtVZdyc3t nG66XGUK8aq1PeBtp8sV3tLUMr51LXaCm8+3bla6GORMNZNSTe0u1a63jENqHMtQzxWXS3ac aXD9y86D/s+y2kyvZvXL2anqr7nPWyhtIStZNmLTno01cH57d9oQYpaxHnWwSxHMXtOqlMPA 9fBkARkQDSuTwKLF74PX29noIjS75zWxZxeYYgWbt7vp4a58s6ogFdO3nAp18YcxDA8hT/jE JTYyk7+aYwnPd7DYhK6IW8DgUQqVxFZt6ZPVGmUZD5jL4/Fxlp26Xyln98wxtfCLQRzjK2+Z xhXOqz6Jm2A1L5jKzt3qhfOXYR0zzA98jlb/XA+MZCwruc+KaupsrYznEEd6xr/tso3/CORA 63nHP7a0k2+M4iALmsidLrOXQZ3pJI+6i2zuqZuPDGhVb1qDrZ7jq79s2zDLWY8sLrIEzYpp KIuajYAgs33bBuyqgnnYYu4Moenc4U8He9mabvaGod3kW6Na2NXetWd7fUZpKzvXzPY2pTld Y3FjlduytvaKja0bM6u4MJMeM7Y9Xcd35mHen31mH9z5b0dLbd87bO0+A35vF/ZWr/WOsLuH PIbrvrXWCS/KrEmtRoP/uYiKXjWuiarxNyc6zQ9fsi7Iy3AIQ83j21a4xdUL58iWHN5tXUiy nW1BpG4m581idKPP/yDx6fFcWlMZeqJoLoagE4zilV74xReh9M8xHd39fjoioq6yqdc35DAe NxmwPlyVG47l7iGW16Xz3ZmbAuwp77rDzX32pB/q5g1f+YQK1Qq2Z4/fXI+5PMKjdx8YiO9r B7zWMV51dw/E8ISHTMELTyM5Jh7uf4+84idfd+0w/vGOl3zeDW/0o+889IMyTuDbLFuSvmP1 rYkPbbxDHtgf/h6bT/1oo3KNbJCUKbI3ZDsNc/pfPhS9JbV9fIJvht43uJO+Qf6yXsHOkaLm O8rfu/Vfn50AR1/2sydOLGL//e636EjTqagMy+8Z8VSf+ewHfm8o2lPc37f4xjd9+H1Pf//s 57n+XmLJSsLlfEB3f8uHejcRgK53fQVoa9SxfgqYf+5neQ6IgO3HgAOYgK7Ge7VHgQuIgdHR gB34exkYgSD4gBIIgRdIghMoggqCFxa4gfZHgCa4eyFxgKP1giWYgid4gzgYggYIelLFHR/I gT1Igz/Yc+rngjLIf+BQgzinc9SXhDk4gxLRhEuIH7CihFY4hUyogVeoK3vghGiFcAhHDVVI fF5oczylVXH1cz/HhSMIHDBhG9Bnhj1CcGGYUXdoH3pYhl3oIpZUanF4c2qIhxFFd89ghnUI UA9GU0zjLHzlZ2vof4dYeSx4VoMHczwWBIdIiZz4iD4Ih4yma0D/wUmz94mQeBanKCjSxw1+ uDOsyF/BMRNb9x/Sd2irmIqR2Ieh2GCwOHnHRGElFEywqIs4p3+WWBvTR3LhBTHiZxrFsx3E GGCLx4sX6ItOR1AW44zaF37d2HxGSAjLEmLH5IxSqIVbaIMreFrJIVMeMlPogHuXV17quI6G MGiLuAakxyOfh2/HoUURF2picU7cl0wAmWqs0Y9Z2HKe9wPlqCsJeY+zxQZn5pA2B5E7uJAM KXiyoIin5EmSqI8hSYk1wo+mlm8iiZJ86F0leWxyRXVfF5Ca0JHJaES0aJDshpAm6U4V13iP wZLxxjk82ZM8UJHqc5F8ZXLzEZM52ZLmvAFxcECRHJmSZCiOEgmVUykIi4eVKulsaNhHXtli ggKWXzmW6daVZemRaNmP06iWQ9iWQkBRM6mDbwmUz0iXNXmXgsiWecmDfJkfe+mX6RiYDTmY NFmYh1lziKmY4baYjRltjgmZTRmZkwmXRUmZ9SGXl6mZ5riZnbmOngmaN5CZodmZo0mammma p0mZqamakcmaremYrwmbs0mbtWmbt4mbuambu8mbvembvwmcwSmcw0mcxWmcx4mcIVAAADs= --------------5412722CB03E62939F35D2A7-- From Michael Riepe Fri Sep 22 19:39:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00354 for ; Sat, 23 Sep 2000 12:32:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:32:02 +0200 (MEST) Received: (qmail 14689 invoked by uid 0); 22 Sep 2000 23:30:38 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 22 Sep 2000 23:30:38 -0000 X-eGroups-Return: sentto-1101623-793-969665421-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 22 Sep 2000 23:30:30 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 23:30:20 -0000 Received: (qmail 3306 invoked from network); 22 Sep 2000 23:30:20 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 22 Sep 2000 23:30:20 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.86) by mta1 with SMTP; 22 Sep 2000 23:30:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA03491; Fri, 22 Sep 2000 19:39:16 +0200 Message-ID: <20000922193916.21054@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CB51E1.66E574B1@f-cpu.org>; from Yann Guidon on Fri, Sep 22, 2000 at 02:34:41PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Sep 2000 19:39:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d3c628ad7709e607de76258870f58f8e Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Fri, Sep 22, 2000 at 02:34:41PM +0200, Yann Guidon wrote:
[BWT algo]
> impressing :-)
>
> but nothing forces you to take 1M characters in input.

This is wrong, unfortunately.  With small block sizes (less than 500,000
bytes, approximately), bzip2 compresses worse than gzip -9.

> OTOH, trying to optimize this algorithm with SIMD would give
> us interesting instructions for the F-CPU :-)))

Are you suggesting SIMD move-to-front or RLE encoding instructions? :)

While we're at it, a SIMD equivalent of the ix86 `xlatb' instruction
would be nice for table-based translation operations, like character set
translation, pixel manipulation, colormap lookups and so on.  It could
also be used for the popcount instruction, but is much more general
(although probably not as fast as a hardwired population count FU).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sat Sep 23 01:55:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00357 for ; Sat, 23 Sep 2000 12:32:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:32:03 +0200 (MEST) Received: (qmail 13974 invoked by uid 0); 22 Sep 2000 23:56:08 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 22 Sep 2000 23:56:08 -0000 X-eGroups-Return: sentto-1101623-794-969666956-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ho.egroups.com with NNFMP; 22 Sep 2000 23:56:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 22 Sep 2000 23:55:55 -0000 Received: (qmail 32129 invoked from network); 22 Sep 2000 23:55:55 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 22 Sep 2000 23:55:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.86) by mta1 with SMTP; 22 Sep 2000 23:55:54 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05035; Sat, 23 Sep 2000 01:55:51 +0200 Message-ID: <20000923015551.33827@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39CBB776.2C04F137@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CBB776.2C04F137@f-cpu.org>; from Yann Guidon on Fri, Sep 22, 2000 at 09:48:06PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 01:55:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (c) LRU C code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db6b4c9394ea13d5eb6ea7f4fa71ba77 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page | Start a new group!

On Fri, Sep 22, 2000 at 09:48:06PM +0200, Yann Guidon wrote:
[...]
> The LRU algorithm works well but it can be enhanced.
> the invalidation is particularly interesting, and i have
> not yet developped an idea where the LRU queue can be
> tweaked to ease the hardwiring, but it's probably too
> complex yet. LRU update after invalidation is not even
> necessary, the performance impact is negligible in a
> normal use. But the project is not normal so i keep
> the idea somewhere in the back of my mind.

LRU update after invalidation would require a backwards shift (making
the invalidated line the new LRU, so that no valid line has to be
invalidated the next time).  This would make the LRU unit much more
complex (especially the stage blocking logic).  I don't think it's
worth the effort, unless the whole cache is invalidated at once.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Nicolas Boulay Sat Sep 23 12:17:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00399 for ; Sat, 23 Sep 2000 12:32:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 12:32:15 +0200 (MEST) Received: (qmail 4164 invoked by uid 0); 23 Sep 2000 10:14:23 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 23 Sep 2000 10:14:23 -0000 X-eGroups-Return: sentto-1101623-795-969704060-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 23 Sep 2000 10:14:19 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 10:14:19 -0000 Received: (qmail 22591 invoked from network); 23 Sep 2000 10:14:19 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Sep 2000 10:14:19 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta3 with SMTP; 23 Sep 2000 10:14:19 -0000 Received: from 195.36.163.49 [195.36.163.49] by lh04.opsion.fr; Sat, 23 Sep 2000 10:12:03 GMT Message-ID: <39CC8353.DBD40DB2@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> <39CBC6FE.6CB4B002@ifrance.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 12:17:55 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ee0bf73e2986678a376ee3b80634393c Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page | Start= a new group!

I m just thinking that my simple LRU system was much a little bit too
simple.

Nicolas Boulay a =E9crit :
> I'm sorry i aven't realy read all the mail about the cached system. I<= BR> > send the usual mecanisme learned at scool. You can put the one way
> system to make something more interresting. 4 ways is the best
> compromise.
>
> The question is how to choose in which cached page written. I propose = to
> make a LRU system for each page of cache. It's easy. You have 4 values=
> of 2 bits. During an access to the cache, you put the number of the > cached page in the first place. And if you want to write in it (after = a
> cache miss) you just pick up the last value of the list.
>
> Any comment ?
> nicO
>
>   ----------------------------------------------------------= --------------
>  [Image]  [Image]

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Yann Guidon Sat Sep 23 15:32:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01141 for ; Sat, 23 Sep 2000 20:13:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 20:13:15 +0200 (MEST) Received: (qmail 17266 invoked by uid 0); 23 Sep 2000 13:28:31 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 23 Sep 2000 13:28:31 -0000 X-eGroups-Return: sentto-1101623-798-969715703-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ef.egroups.com with NNFMP; 23 Sep 2000 13:28:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 13:28:23 -0000 Received: (qmail 12512 invoked from network); 23 Sep 2000 13:28:23 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 23 Sep 2000 13:28:23 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 23 Sep 2000 13:28:22 -0000 Received: from f-cpu.org (nas1-244.aub.club-internet.fr [195.36.150.244]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA27301 for ; Sat, 23 Sep 2000 15:28:19 +0200 (MET DST) Message-ID: <39CCB104.C9CF24A8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> <39CBC6FE.6CB4B002@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 15:32:52 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7da8245907dcb33e8d7a0786eeb72cca Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Nicolas Boulay wrote:
> I'm sorry i aven't realy read all the mail about the cached system. I<= BR> > send the usual mecanisme learned at scool. You can put the one way
> system to make something more interresting. 4 ways is the best
> compromise.
>
> The question is how to choose in which cached page written. I propose = to
> make a LRU system for each page of cache. It's easy. You have 4 values=
> of 2 bits. During an access to the cache, you put the number of the > cached page in the first place. And if you want to write in it (after = a
> cache miss) you just pick up the last value of the list.
>
> Any comment ?

In the final implementation, everybody will be free to implement
the cache design he wants. we're simply trying to promote the fully
associative strategy. 1-way (direct mapped) is not very efficient
and i presume that the first silicons/FPGAs won't have enough width
to contain 4*256bits=3D1024 bits. now multiply this by two for the data cac= he,
and you understand that it is difficult to fit this into a small chip.
It is also an interesting challenge.

My personal grief comes from the fact that the behaviour of direct mapped (or 2-way, or even 4-way) caches is less efficient than full-ass, when one = uses
strip-mining algorithms. direct-mapped performance drops quickly after the<= BR> strip-mining window is overflowed, but fully-associative caches thrash less= and
the performance decrease is almost linear up to twice the size of the windo= w.

Imagine a loop with N instructions and the cache can contain M instructions= .
If N<M, it's ok.
If M<N<2*M, direct mapped or 2-way is KO while fully associative thra= shes N-M lines.

My point is that it is more tolerant. Imagine that there are some interrupt= s
or system calls in the loop, it won't thrash everything.


Of course, remember that this is a modular design and this cache design can= be replaced
with something else, but if we're going to make something cool, let's do ev= erything
yully :-)

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sat Sep 23 15:32:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01144 for ; Sat, 23 Sep 2000 20:13:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 20:13:16 +0200 (MEST) Received: (qmail 449 invoked by uid 0); 23 Sep 2000 13:28:32 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 23 Sep 2000 13:28:32 -0000 X-eGroups-Return: sentto-1101623-799-969715704-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 23 Sep 2000 13:28:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 13:28:24 -0000 Received: (qmail 12523 invoked from network); 23 Sep 2000 13:28:23 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 23 Sep 2000 13:28:23 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 23 Sep 2000 13:28:23 -0000 Received: from f-cpu.org (nas1-244.aub.club-internet.fr [195.36.150.244]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA19301 for ; Sat, 23 Sep 2000 15:28:21 +0200 (MET DST) Message-ID: <39CCB106.2C34A994@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 15:32:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL for loop (was LRU C code) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cbe6f3cdd57dab116586103820adc79f Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

David Sullins wrote:
<snip>

thanks,

> Dave
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sat Sep 23 15:32:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01147 for ; Sat, 23 Sep 2000 20:13:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 20:13:17 +0200 (MEST) Received: (qmail 20856 invoked by uid 0); 23 Sep 2000 13:28:44 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 23 Sep 2000 13:28:44 -0000 X-eGroups-Return: sentto-1101623-796-969715701-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mq.egroups.com with NNFMP; 23 Sep 2000 13:28:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 13:28:20 -0000 Received: (qmail 4231 invoked from network); 23 Sep 2000 13:28:20 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 23 Sep 2000 13:28:20 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 23 Sep 2000 13:28:19 -0000 Received: from f-cpu.org (nas1-244.aub.club-internet.fr [195.36.150.244]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA19275 for ; Sat, 23 Sep 2000 15:28:16 +0200 (MET DST) Message-ID: <39CCB102.F19B6966@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> <20000922193916.21054@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 15:32:50 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e5e1a93405a4f20fc614b2486385c1fc Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> On Fri, Sep 22, 2000 at 02:34:41PM +0200, Yann Guidon wrote:
> [BWT algo]
> > impressing :-)
> >
> > but nothing forces you to take 1M characters in input.
>
> This is wrong, unfortunately.  With small block sizes (less than = 500,000
> bytes, approximately), bzip2 compresses worse than gzip -9.

hehe :-) then what matters is shich algo takes you there with less time
and ressources.

> > OTOH, trying to optimize this algorithm with SIMD would give
> > us interesting instructions for the F-CPU :-)))
> Are you suggesting SIMD move-to-front or RLE encoding instructions? :)=

no. a scatter-gather instruction pair would be helpful anyway.

i have not yet much analysed this transform but i'm not a compression
specialist either.

> While we're at it, a SIMD equivalent of the ix86 `xlatb' instruction > would be nice for table-based translation operations, like character s= et
> translation, pixel manipulation, colormap lookups and so on.  It = could
> also be used for the popcount instruction, but is much more general > (although probably not as fast as a hardwired population count FU).
popcount is easily done. it simply requires a special execution unit
but it's being considered (look at the instruction set).

as for your table lookup thing, the scatter-gather instructions
does that trick but it will be interesting only for 512-bit or wider
CPUs. the principle is similar to this on the vector computers, but
in a SIMD fashion : each subword of the regsiter holds a pointer
to memory and we fetch or store several items with one instructions.

Of course scatter-gather is a difficult instruction because it is
more or less sequential and might trigger multiple faults. there might be some solutions though.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sat Sep 23 15:32:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01150 for ; Sat, 23 Sep 2000 20:13:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 20:13:18 +0200 (MEST) Received: (qmail 20891 invoked by uid 0); 23 Sep 2000 13:28:45 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 23 Sep 2000 13:28:45 -0000 X-eGroups-Return: sentto-1101623-797-969715701-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 23 Sep 2000 13:28:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 13:28:21 -0000 Received: (qmail 6329 invoked from network); 23 Sep 2000 13:28:21 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 23 Sep 2000 13:28:21 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 23 Sep 2000 13:28:20 -0000 Received: from f-cpu.org (nas1-244.aub.club-internet.fr [195.36.150.244]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA16057 for ; Sat, 23 Sep 2000 15:28:17 +0200 (MET DST) Message-ID: <39CCB103.16258737@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39CBB776.2C04F137@f-cpu.org> <20000923015551.33827@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 15:32:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (c) LRU C code Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8dd73e1484e4566375ff9634e61e5aaf Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> On Fri, Sep 22, 2000 at 09:48:06PM +0200, Yann Guidon wrote:
> [...]
> > The LRU algorithm works well but it can be enhanced.
> > the invalidation is particularly interesting, and i have
> > not yet developped an idea where the LRU queue can be
> > tweaked to ease the hardwiring, but it's probably too
> > complex yet. LRU update after invalidation is not even
> > necessary, the performance impact is negligible in a
> > normal use. But the project is not normal so i keep
> > the idea somewhere in the back of my mind.
>
> LRU update after invalidation would require a backwards shift (making<= BR> > the invalidated line the new LRU, so that no valid line has to be
> invalidated the next time).  This would make the LRU unit much mo= re
> complex (especially the stage blocking logic).  I don't think it'= s
> worth the effort, unless the whole cache is invalidated at once.

If you look at the source code, you'll see that i implemented it in C
anyway. it's not such problem in SW.

As for the HW, if you still read the code, you'll see that i found an
interesting idea. instead of shifting back, that is in the reverse order, we simply have to disable the normal shifting for the next LRU read update = :-)

This is less simple in implementation bu let it be known that there is
a smart solution. i haven't thought a lot about it but it's possible.
the problem is to avoid a lot of side effect.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sat Sep 23 18:39:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01159 for ; Sat, 23 Sep 2000 20:13:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Sep 2000 20:13:21 +0200 (MEST) Received: (qmail 11577 invoked by uid 0); 23 Sep 2000 16:35:31 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 23 Sep 2000 16:35:31 -0000 X-eGroups-Return: sentto-1101623-800-969726926-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 23 Sep 2000 16:35:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 16:35:25 -0000 Received: (qmail 15165 invoked from network); 23 Sep 2000 16:35:25 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Sep 2000 16:35:25 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 23 Sep 2000 16:35:24 -0000 Received: from f-cpu.org (nas3-4.ras.club-internet.fr [195.36.203.4]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA14548 for ; Sat, 23 Sep 2000 18:35:15 +0200 (MET DST) Message-ID: <39CCDCD3.A7A3350B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 18:39:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: multipart/mixed; boundary="------------B1748F8B1526F5BB89B649BE" X-UIDL: b38d9081b48cd37e5e49191e7710beda Status: R X-Status: N --------------B1748F8B1526F5BB89B649BE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

i said i haven't found a flaw in the previous VHDL code but
it was still O(n) and some gates are pretty large (8 inputs).

i found a O(log(n)) organisation, using smaller gates (5 in max)
and that can scale easily to 4, 16, 64 or 256 cache lines. 16 will
serve as example. not only that, i also simplified the architecture
and i'm pretty satisfied :-))) of course it's still possible to do
better but it will depend on the targeted technology ; we did
the toughest.


First, remember what Michael said : it's a shifting register,
a sort of FIFO with 4-bit words (in our example) that are shifted
deeper in the queue. In fact, the shift is partial : one half
(the limit is determined by comparing each element with the
requested item) is shifted while another (it can be nothing)
stays identical. This way, the searched item is overwritten
and put back at the beginning of the queue ; the unused elements
are progressively pushed to the end of the queue.

This said, i think that Michael did a little "conceptual error",<= BR> or used a naive first approach : he has put a multiplexer in front
of the data input of each register in the queue. ok, this is only a
2:1 mux, but it's already annoying enough (transistorwise).
with my solution, it could become a simple pass transistor, a AND gate.
Rememeber that a shifting register connects the output to the input
of the next cell. The trick is to AND the clock signal, instead of
selecting the source. This way, only a part of the register is shifted
and the datapath is kept simple, since the comparison affects the
control path.

The fisrt entry of the queue is particular : it needs no comparison
at all because it is overwritten all the time by the newest value.
it is clocked directly and if it overwrites the same values, there is
no side effect because no other comparator will be triggered.
this is a cool simplification but it might make the VHDL code less
easy to write because it would be a simple "for" loop otherwise.<= BR>

The propagation tree is another subject but once the solution
is found, it looks really obvious. I have grouped the LRU registers
by four, so the logic gates are kept small and we have more choices.
To understand how it works, we have to start from the end.
The last element is shifted in if its value is equal to the line number
we seek. So the output of the last comparator is directly connected to its<= BR> pass transistor of the clock input. The precedent pass is enabled if
the value is equal, or if the last is enabled too. There is a OR between the comparator and the last comparator's outputs. The OR grows to 3 and
4 outputs when we go towards the beginning of the queue. So this is the
last "sector" : the output of the larges OR is sent to the other = sectors
in a tree-like fashion, instead of a carry-like fashion (like Michael
has drawn). In the other sectors (except the very first), the ORs have
2,3,4 and 5 inputs because they must OR another input : this new input
is a OR of the same kind, computed at a higher level of the tree.
This way, the wire lengths and counts are kept rather low.

Remark that the OR is re-computed to avoid nasty propagation delays,
for all sectors except the first. If we used the largest OR as result for the "carry" of the other sectors, it would take more time to set = and reset
the carry, it would slow down the thing and it would work in O(n).
In the same vein, the propagation of some signals should require a buffer t= ree :
the reset, the clock and the CMP inputs drive all the tag lines and the fan= out is
very high. Similarly, these signals should be driven not from the left,
but from the right of the circuit : this way the propagation of the input s= ignals
follows the propagation of the carry chain.

sorry no VHDL yet, it took me enough time like that to edit the schematics.=
more to follow, maybe.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con) --------------B1748F8B1526F5BB89B649BE Content-Type: image/gif; name="LRU.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="LRU.gif" R0lGODlheAMpAfcAAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0N DQ4ODg8PDxAQEBERERISEhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8f HyAgICEhISIiIiMjIyQkJCUlJSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDEx MTIyMjMzMzQ0NDU1NTY2Njc3Nzg4ODk5OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkND Q0REREVFRUZGRkdHR0hISElJSUpKSktLS0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVV VVZWVldXV1hYWFlZWVpaWltbW1xcXF1dXV5eXl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdn Z2hoaGlpaWpqamtra2xsbG1tbW5ubm9vb3BwcHFxcXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5 eXp6ent7e3x8fH19fX5+fn9/f4CAgIGBgYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouL i4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOTk5SUlJWVlZaWlpeXl5iYmJmZmZqampubm5ycnJ2d nZ6enp+fn6CgoKGhoaKioqOjo6SkpKWlpaampqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+v r7CwsLGxsbKysrOzs7S0tLW1tba2tre3t7i4uLm5ubq6uru7u7y8vL29vb6+vr+/v8DAwMHB wcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvLy8zMzM3Nzc7Ozs/Pz9DQ0NHR0dLS0tPT 09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl 5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v7/Dw8PHx8fLy8vPz8/T09PX19fb29vf3 9/j4+Pn5+fr6+vv7+/z8/P39/f7+/v///ywAAAAAeAMpAQAI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP nwQHCB1KtKhRokCTKl3KtKnTp1CjSp3accBFq1Szat3KtavXr2DD5sRakazYs2jTql3Ltq1b mWYnxn1Lt67du3jz6nU6N2LfvYADCx5MuLDhoFcPK17MuLHjx0n/PpQMmefRy0Ira97MubNN ygytgvY8c/RA06RTq17NeiHqg2Rft0b5Wvbs27hzL7Z9uiBv3R9rAx9OvHjh331/G8cofLnz 59DR8pasPLrfydaza9/edHrC6txd/mMPT768eZi2QYM/j9jhevbw48s3mF78fIrN7+vfzx82 RNPvsZdffwQWGJ9sABoYmnv/BKjggxB2hmBDDpqXoEAVRqjhhocNaB+HGC7YHogklijheBSa OFpcGZro4ovSoSgiier5B+ONOAbmoUItclcjfTkGKWRdqNVH44cjDqnkkmEVed2R30XJ5JRU ZuXkfyVSRl2VXHbZHYNYQonQll6WaeZOV8q4oZZSnunmmzFd+CSHZLYJ5514miRnmHTaaWOe gAbq0Z5qRljnmIImqmhiM/K5pp9ALirppCk22uBlvokZ6aVD9Ubpp6AmGSVSnmLYaY/ZUddp UKuG6uqk/gBixWKml2pK66wNvqrrokaWGqKLK9K667CC9vqrr7b+eSyxzN5pbK6ighhstM1W 6+WzuKpoKarWdmsgtsJmua235HIJLrWPIgltuewqee5pmMUr77z01mvvvfjmq+++/CIlWr8A ByzwwAQXbHBR7Sr6Lo7eTTlhwsXOaerBFFds8cUYy0vlwxAD+uyQDTPJccd4fixkyEuOTDKc JgeJsruOrvxmyzm+DHLMMp9JM8MScXufyjmbufONNp+Mc9DXSgyz0jcXinSXQ8NYtMtHP11l 1C9OXXPVVjvMtNFfU+10115zzXPYW49Ndspon2020W+vLbbabtMNt91yp413/tY9bxx33nfv DWzfZYMJeOGGs9124JUeLvLiUhP+uOCOi/v34JDzTXnlLvGrkecZgd544qHt+7npoaPOnOqW jl66vqfDnrrsq9PeOo//sW6R6Ffprq3kjGbuOum4X77s5sULf/vywFOutbLIQzo8fnJ9Xj3x yU/PvPLoNo99stp7Hz73yGY//qbGq/u9+NunX7706pu/PvnHl3U9c/e3H67+0NvP/v/ysxz9 EAVA99UPfgjs3/yit67gGZCAynse+h44wQUy0EHI2RzQzndB6xVQQxkMXf52N8IAjip6mckM CT9oQQWWkIPvw92OSlerFQ7QhfF7If8OmMAKwvCH/vvz3w35E0L8sRCI3fMhBNNEIRZVp4gO ZCAOTTjFTTGRhqwSIgWVmMMjBrGHXwRjFTsoQi8qyDsBgqINjXdFQn1HVTqUYRmHGMYucnGC bhwTHM0YojTGcYAzRFQg5WhEOiZRjBDq1XvUqEXnTW9adowhFZdYyC3WcZKXpBYkMclDTgpr kX984CA/2cIRgZKPiMwkCGO2HkZSz4ubzGQsPXnI/bUylGSE4aHGOMoxiuqWqIQgG12XRz8B 05CSpOWDZggeV+LSl52MZgPvOM0dSlOTa5QiNYUZyWpe8kcadFozn4nEZKoyOdZEZyNLac1a Gmp9TyRnO82ZxGJ6k57Q/rwnF+MZzHy6U5r2ZBMs4bnOcqbyn/rsJDi7yE9kXtOf3zqfctA4 x2GKcZcI3eZDF2pA0VTUkZ7EKD65edFuknRBfhxoDwUayYn2LaUOlc8sIfpQU1YSpPn8i0hL OVON+rRUp4ygMnV6UFVe057KPFZQLerLnbrTmW1aqjb301Oj/nSax2SqVd9H1Gye1KhQhV5W cXpVb3a1oNtE6kGz9UqhfrWOVc3oSI83Vnae0aQ1Rag626pVue51q289ZC9zSlO55tWpJz0r X1eKQnF6FYiKzSFHk3rYws7VsARiqV0T2r2G9jWv0forWutJvitiFrRzjSzxRLvYKWLtn4jF /utWWRs/zZbTtJcFbG4LZNt54ha1mGVmCWn7wd7KtqaxpWxlCzsX4kLOuJT9LWeVO12ufg26 RZWuZ6eqn+T6U60uValu6+fcuHn3quBtLWQDC6ny4u28gE2vPPVaVvIWFbTyDabPwgPfjOYX kIXabnM3MtndVhefBTbogc3ayAF7EIFh1WiC57nc4O5zvv8VZd3Gu+DpqpW9IC6fgOvL2BCj l38RNjGDF+vgj17YjHE1cIpFPNz7djjGwO2wgfujWrKGeMaZMu2IOczeHrMTxzoGrkcf2WAS F1nFP0UykBHTxiZbdsFSnm8fGXdaLKNYy7EZ3pC7TE0jr9ekU1Yq/pNZ7OQqmjmdX+ZjmMfF 5isP9sMQnTPm2tzLwZ64lmzNX6BvGsbtYtLP8T1nm5c16CgWerRlbqyaYjlmInt5qDC29Hze LNsJ11dllHZgox8bQ0OX2KCgbl1WRw1pTmP61eljNbIq3eU+S5p0+03VlZHbafEKVtMNlPUf 3btDT49XuPJbNbDvSGy8GtuwyLaTshd94GfvNtrgq+uTN3tpWQLbLMIGYLNpaW0lOzbZol72 N3dd7V671ds79tW4EVnuJGNbWuyWro5fu2JjpjveVJy3ibEL5W7/+ttJQpVIte3a0p5b2v9G +Pj4XWEyHyjf86N4uwML7jl2fFDSYziz/h0ePtvC9ONVCbmjOU5y5ml22hLfnsa1+7uY23Hm BIV4IVHOkYWvvOHuo7m/d27xtwocmgTPc86FCXOL6xvnJa85wBEcXeEhludCxPqDKwjTSULd 5eY7edFx2GJSrzvoS/+T2NWN1K8zVOo5lnDVL3f1ses5yVFn+8Rb/vahB0/rLqYxoYGOPKFT kuh6lznfAw53vMu94PiVqM7/PvYX2z3v3MvwLz1eebhSe6M23mCkD0/5xPc985JPVtchjOHU K0tVCCO9z1S7eqO3vn27hD2p1D51E5Yd0pJMs+aBynnTMz7TuBdg76vb38sOn9G+2f3EVEj8 uGvv9+q1fKxd/o/H6Ldq+tm6e8r7V3uy376lUS3+5cGOfPSr/o2xb2ro/zbhjkufrf6qfnBI qvvvg3X+e1N/QfZ9+Hcq+gdy5Ad/0vd/kHdj3EdKehR/VrRPRlFSDSh68IZvtrSAEsh8xoQp /tU48XcoKhRouEJ94tdz/Od91Ad+DChWIOh8Irh7uScrtnQrejZ7K8gq/teBAcWCPkh/8NIq deJEPciBgjeELcgpS/iDPFiBITgjI6h8fUSA4ZJ/YHd/T+iAr2OEO2WCX5SC9BGD8DNgWphw BpiFVqiEXOgaR7iEnXWD2HRUZPhVZriG8paGb3eG09eGPPKGRciEm8eGKfgvLViA/ikUdXwo iBi4hY6ogVmEVXIIh2Rng4NIiRZ4gmUoh9Z1QBIIbgvIQ81libOGgyVHinRlKkIoifqUe5xo U2OIh0xIXKOYipcYUKjIipj4Y7ZYhLkIhjVUTSX4itCyi531i6YYgL1IhcQYbi9oi+13VNwE jBAoiNCoVETIcoOYW4TijN+laNNIjGrWh9e4LjSojaXoV8REZKlWW81IeOWINdSIep1nIWEn jmiGj0gUbpE1j0Clh/E4gJhocvpogekYjR7md+WIjYm4jakYitHkj/JYkMfFj2KFjwTpkLpE kUnljbx1jxoZZwdJj/TUjxgpb++YcOgYkKs4ktsHaArJ/orVKJMsKYog6ZIiuZB2ZZHdF5IJ JZGZ44/hVI/lkZE4mY8+uY/g2JNHaZIa2XYpqYxJ2U48eZE+6ZQuCZVPGZQcuVZLuZVzGI5T yYtj2ZHqJiA3qZMh1ZVQVpVR6YlimZV7B5ZSeZRKCZNxqZNYWZNe95YbWZZeiZd+WV5A2ZJq SZVneR5GeZhkaZeIKZiD6UKFSXUx6ZGgB5ht+ZWRqUSTeZl5SZN/6ZgVqZl82W9WKZryh5nf SJTksZigmZOvuZOkWZq0uJk355ewaZlRWJKVGYafKZTwCJoTqZp/xptMqZdpGZtrSZyJxpr8 lZy62Y3syErL05mlZpt9SZct/gScd2mcp4mc3ymccymXhqmcj+md2mmax2mejcmYZumcPgKd uiWdp9WOvoeb92SdWkmedemegYme2Hmd6bmfpZmb0zlpt2OdEYmfy4ma/2l9myaf6khnO2af m5ieNjmg41mgSOmgmQmZAZqh/OmZ4Rmd61if1OmOGPqTDGqQ/vmhy4eWvTmh6qKbMgiiSuhR Brij+VeBhpgrPKqjEDlyK9qgL7qaAPqEQrqkQNqjCPOjUMopTep/Kyme5WmjkYejVtqJvzmf J1qhKdp4GnqlB4prxXaSJcqWrmmiFBp3FqpiwLmXW5qdIxqaR1qc0riejbamXtqmjvemkAgb Tsqk/j9qoCiKoM42qFOaiPMypY4apRpjiJEqpZBqjJTpoUiap00UpIu6pJjxqJQaqpNaL6DK qYYKpogaQE8qqow6qKPaqkx6qm4apswooR7op+Flpsd1lbrqoW8qho+HqXiakHVmVQqaqTKJ Z9x5nppqq7sJjcrKlsiaa9aBIIqqo7Poo9n6qp5qqVmapO7hqt1KL6UKq5giqfdSqp2qrfhS rkPanOAarkFqrqRaqeO6qqYDqeuKr+lqr1Q6rSh2rbO4r+Sqr+jKrv3Kqu/6rI73M9kErBw2 aHjmoBhkWctKZuGnYBLbnc26crn6ouMEi7u6kBPrn2p0dJxYsiGpslja/l2706MEO6+wI6kx S6/2ErMQqqQ2my/ueq7bOrNA+rMyy7M0e7D8SrRCm7M6e6/t6q9HUbMJy7RD27SMKLQ7W7BJ i3dHe7VIK7VcW69Vy61U+6nLpIIkuk4q+2L7VbFPZba36mhp63kNy22f2YDpR2EJiLfBp7Tq WXojm7d/u7dlS2Bf67X5arWGC7TeanZ+Ia4IWzBQC7WKGy+S27W5hkGOu7UDE7lGCzCci7iT OzuZ67mdO7Wki7iVO7YZQ7acwS1xu50gQa1za6RuS112Wrsi4boKdrsEtrt6a0m027u/26Hj 17qx67vEi7vHu3/DG7xbZ2PIC7wuqrzsNr3C/pu7yxu4sHm9ttu8eaG73tue1IuA5Nu9ycu9 0Bu+0Wu9z2u329u+5Tu+ifmM8gufsnsW4Ku95wu/8Yu+7ru/gfd5/yu94uu/1VvA/Fu/jBuj wVq85vvA35u9EIzAAezACsy3qdm/B7zB6tvAFzy77FvBBizCDEy/Izy/8MkW+TvBGWzBEvzB K5y+ADx4zKvBAtzCMPzCNezCHGzCCWy/GAEAQjzERFzE/yDE4Le6q5u6UUu5pes5T5y4lmsx THyzUVzFYCu2m3vFUTy5F4PFWKvFAvO5B0PGBgPGTQy5XAy6U+yzZbzGpAq8SCwQAHDEdXzH RGzHXaFvOJxdP6Rx/tlXVhM7nL71xzF1puXpx4jcn3OHvbdlyIlccINsSHM8EEiMx3OMxEq8 yYXrxW58xnAMymzcL2gsxpo7xqGsxqjbxW1cMaXsxKs8ymn8yapsyqf7xaysup+ay7P8tLxs xbGcrnRLEJVMx3dsx5lcx1zhJH7GzIx8QsNsdQZHb9M8cNWMdNe8w4TEu4L0zN0MuymCaAvc G83MIOUczt7sH+KMEJWMx0eMzJdcx5y8ya+8y8EsyrZMyr/syVt8z7UMy2/szwRTz1mMzwBt 0PYc0PkMxbLMz6gs0P280Icr0U/rvXk8xO980cq8zOb8tuQWtO+rzh4dEs4crehs0ig1/tLW vGT6S3cgPcNBptLYzNLOK9KvK800HcJAktMUvNMy7VPY2sEKUcwNPc/6XNRhfND/nNAI7cr7 nNRMvdS0PNCpTNVI3coPTdFYfcoBY8ZSrdBN7ctXLdEELdZaXdEy7BBG7BUlzVmTHNQ6HdM8 jcIr/dI9LddubchwfddUZtc9/NF73cfdPNdte9J5faaBfcOA7dcefEKEfanikdg+bNOHbbyG bW1tjdkd/dgY7GxBq9mXDdN9zdk/7dOkfb+ZLdrkzNiTbdqVvdinTRKpXdOuDdopHduIzdop vBazHdej/drULNm7PVLYatuRrduQLUe47dnCXcKwDdx1vdzP/m3cyg3dNlzbqr1l0h3cyH22 jm3dj9HbfL3a2x3d4M3DlE3d363eg33esPXZLS04xZ3d8M3e6U3f883C043f8E3beG3f2K3f RLLZ7k3c/e3b5F3gP/zbAP7f/N3c3t3e9fZzAY7g2q3g7Qbhpe3gAm7eDc7gD97dGw7iHf4W 4i3Y9+3fJJ7WPHXg433hH57gMQ7j8d3iGv7WIo7j5T3TOS7bBD7j9R3iOw7ULv7XJv7jQo7h J67Y+63iMp7kQJ7fLG7jPZ7bQ26sRd7YEl7jzF3lXX7l733jeu3lmzGKpKzSXY3mngvCYrbm bpTmb+7mbX7mqB2LoBPndD7nd67n/qhDrWa+56om54Ge54MO6JaNsd4dsm++QrKLfWGy6P4D 6a8k6ddT55qWizs46WLG6Jse6T5+6YnO6aom6uqj6J7h6ONB6YSj6k/S6IuG6YBb6Z2u6aPu 6SWB6mDC6o8+67Je67TuyIiO5qSObrZe6sOuGWWnh4XqKZSu7FLaHs3ekI4K7beOPs7eg6E+ hOb47MzO69fehNk+MduO7Wzu7dK+7L8S7SyN7sVo7uvO7enu7uMO7uVO7OIeZuSu7vOuib4e qlXI78au7fhO7/crFi0GirWCirDOdXmY8NAn7Iz2L+3e7Z8usgm/ZB8n6QjfkBk/6xuP8dTu 6x8/8fFe/u0zmUIgT/EBH2wSr/DhPvIuD/Es7/DB1tnt1fAcH/IrD/MPr/FZlPMqb+88X/P1 PuAn3/I97/E/n/Ilv/NLT/JQT9ITCC803/Ei//Qx7/NUD/RNL/RYn/Qmb/EoD/ULH0R3N/ZZ r/Rbz/RRn+lDb/XAfoBoD/ZOv/Zk//JfT/Rar4pc3/aQcfAM3oT/yvDQF6tsePUyLviLS2hn /9mKv/f1/fhqD+OSj/iU74V6MvWXz4KTH/mYb/mez/mgX9yVH/fjuPmP6PWJ//l1j/qH3/qh n/rIrvlBPqzb/uS23/iSXfDCiJK7jzO6z9pAE/xzPfy+L/wpAfi4D69yn+V+/nj6tc/80C/l wx1ax1/8wH/9fav6NJ772o+yx0H7+I6st69mAqf85m/k3D/u5N/4W+b9D4/8AYaS70/XsD/+ 8E/08r9a9L//nQ8QA/4NFChw4MF/BhEuZNjQYUOFBxVGnJgQ4sOLCytK5BiRI0aNDDcS7JgR 5EeEIy2S9Ejy5EuYMWXOpFnTZcqUAwqWFCmzJUWdKy22FPryZ86dLE3anHlUYtCKRIk+dEoQ Ks+QMasmvKq0p9avVpMOXcrUZ1iuY8fiBJtVrNC1KI2i1am2qNyTW+vCvXvTLEy9XcmizUtX cFy/hd2m5Sv17OK9Ucv+pVzZMuWtNKc6zNz0MVub/psvg8bruS1pzZ9Lq1aM2vRokJ1Zxyb8 eu7i1KdX64ZdW3Tr265nY5TNmzZu272VL+9dHPDs38efIx/O3Hlw7ImTS9893Xv37MxLRycO 3Sz58efNM0Vf+Tpw+H2rc649f3L7yeL174de1/9/AP/rL0ACAxywQASD4k+7BBvE7ycHETww QgAnpNC/Bce70EDjNuTwO7E83KtDETFcEMISFQQxrRQt9NDFDTOUccb8LtoJP6qeu9E9HQej kTobfVRvrh0x6xGxmtDbEUfrjpQvt8KK/EtJspissScpf9SOvizZc9LK+oJEEkrautTyTBqp NDPJL3kkUsgz1YQztDaN/nxzzO24nFNLOfG0D6c1ySwv0DzFfFLGPg/9syQ/jdOz0RUfVRRN Spu8c9JIDQUTSCz3TLPOKUEdMkpPC+0U0hNF9fLSTYXT1E1SUdUv0VbBA7TURZWSlbtBca30 V9hohbVMXzM9FVP+hLUzVmTjk7TWLV/9VdlQWR22113Ls5ZSakclNtsct62WWWiBNZfXHAnN tcpm0X12WlXpFNdbbNvVllxgu10V32W/tTdcftHUV96A6U232PDePXfh5uJlc959/S2333rL HfjhgiOuOF+HBT0YXPogJljiSi/2WOFxSab4438ZdvlelVPeeGWUBe7Y1JDUdVRamVmemGae /g2uWWOfry2a25vXXdLooUee+WWoiW4a45iFDjrOpHc+1uKsjc0Z4WS7Tvhqp4/ueeoZTcb5 VpCv/LrtMLdeEAC6AfinbrsHqjtqpsmm+mmr5S5ZbGf9PtnwtRlteTm1lWYXaMHPRjzDxrV+ e/G4L+daZOXo1vsgz0HPm+/ANe878tLZxjxYwt2d3HLVN88Ya84PR13q172OffDaE9d1dVdv Lxvt0UK/W3SEPDeedN/Zlb1q3IX/sXLdFX8e8OhNh7d3x3Wu/vfrzaZ99r/Fz353yLUXb3nk RQ89Rfjjb3CoBJ1nUUT6JVw6/vwLtF9+/hWkfvuDX/8I9L8CClB//s5L4P0MREAAtkiB/oNg iQz4QAZK0IEVqiD+JnjADkaQQhfkYAYt+EEMLqmB8wthjD5IvMuwT2+ju5sMGTc9IC2NYlPR ocx4+DikuaqH9Pqh97JTRLDxColwa5gQgUhEGPJmicDDyxR/pjErXiuLO4wiiLa4Phq2b4Y2 bGLacvhELHbxiGrcj0e+CMXcrTGO8HmjzZxoRDqyUYl6hNmThsinM+Jxj3McpPQEVcflhG50 y1NeGJVzRSnyEWDR+qPTEInDOyaxj5c8pCRDtptKAjKTTEQNJ5NjStagMlWjpGJiVOlFT5bl lZbZWw3xZssZzgqToESjJWNJmFm2MZCa/pykH3v5t2AWUn1B5KUgN/lL3CTzmYS0VDOJ+UlK HrOT1CymNJkHu9GM0HrsiRD6klTOcfIJneAjp4PMqZl12i808Qwl5eipTaPc05ka0ec1n+LO dKapn0wUJzvnCVCDnhOh8vxmOCmHnXqODTL4LNxE9+lQ4ES0oqTRqOss6s9ofZSU6ZNLR/uI TZMWE6UU9ShHWVpNmKUUm5OUqdtK+lKVLqWmDf2eZchDEZzOdKUXtZVfdsq6jAbVpkZVauZu StSQuhSqPoVoUzklVZAiC6hT/ek7EVVVroI1q10NqO2wOlKeXhWp3Dlq8M66OrIm9FNJDStd xypWguK1lalj/mpd2WpVtz71rnZF6/DoAtiiFqWtid3qYP861bQ6FaOPdWxMERtVwRbWsCKF q143FVeGmjWzez1fXytL08tq1au5aqxmRWvavBK2s7L9rGcjS9VVUja2up0tbyHJ2tWCU7Gp Be1iMQtb0m72rbWlbWmH61fLQpavzz3tUKurU+La9rYknWx0r3tY6KJWutNtbW+9u9vzmle8 WT3dcp1bXub69r3BDVtzlTva+KY3v+t1bVp/m1Pwfpez+7Vuf30H3/mW9cD0lah7x6ffBMt1 wQoGLoVzC+H7IpfA2A1vgZPr34fat3wcFrCDd4nhEQcYvfxVr4f/K1wEZ5i6K3Zx/oRD+1UR v3bGLSYxjXv8YZ6+WKjRTO2k3Fjk3xx5vKlTMnuTvEzRNpmUT2bwhWWJ5D1ClsoWhp2Ugfwn L7dqyxJeW5iZDOXtpviGz9Rylp3sZgOXGc1gnnOX66w7M9uxm1hm85v7PGU4f9nOVd7oXYyL 2TzfN9FplvFlxnxjORO6pYYuMkkXHeU7N5jSbf6zoOks6ZMSmdN7HvVMD23pTBf60pHmMp5T zehJl9E3ld7MUaRba0OG+D60VumpD2Vr9v4617qe9a17zWuh+hrXrxbPskEdagYhe9fGTnal 0yzkIUeb2tMOtrNbbWXXKPvY2y52t8cd7NMBe6TeJrOp/tRNRXZDGsfcXve5611tciPH19ee K3X27ZhhR8oxSz7bwNENcGa7y+BoRfizdVmff+cn4hC3dsO/XV9/V1ziGqf4eC3eblj3NFgT 8SZnSA7NnDwF5Y4+OTdNrnKXQ6TlAQfMzBPeRps7nDg5v3jNYU7zfP785tbhOcibUnR5w1Po OqcK0ve9XWzHRkUxN7lonv4W8wls6kCvudWt/U/snWfrQ8e51wnOmKy3M+xqT/v0xs70nZsd 3WBvu0LXHnJNP7zuajY635Muyr1j+uxG/rqtru5o6Emu53Qe/JMHr/i+C37uhi88oisP4gdT PduLt/PjIf93vx+e8I1PPDNX/q5W0Tt+8pb3/PlSX3rXX171cf5m1Cf9+rsr+vKoJn3uQy97 2Gee667ufeDl3HrdF//0gcW98TGCNzLKJPprPbHmbdr85SPe95Lv7+w/7H3bH3/1ox8/+Ltr feqjH/XA3774R6pIR85k+uefUfzh/vzg18T+nJ9b/mmy/8iTP/8TwParvwGUvgOMCQAEvf9L QP5YQNGDwMuTwMGjwGCDvzFapFuypbyBPmE6EwvsrxD8sBEMPwV0wJcoweJBwZNQwXNxQVpi QZCAwcqgQUqxwb/AQbPQQabgQQXsQLvBQCEEwlz6pwKBPiRMwr0RCCWEvgCpmydswlsKQiW0 HycE/hApnEIO9MCluUL8sRsKMiEEoRsHyUIpPJ4mtEK8iUIzRMMq7MI1xEIzDMItvCU4hEIL AkMQEsMjBIAImcMqpMIkVEM8/A9AdMNBvEMylMM2FEQkJMRF/MINugoVahBAvMRHdEQuZBcv 9I9D1EQ75MQ4NMQ5RMRHVEQ/xEKY8MFV3MBMrKU6LMIeXMXOocUCXEDQOUBc/JwCpIxdPJ5b tEXn+0VWzMUUlEGbIEZdFEY1UsZgPMZe3EFmjCNnHMZpBLpqXLlGksXk2RsZmr8WvMYaFEdQ y0ZqJEf+k0ZotMZ1bEZ0DEBgDMdozMF3ZEBelEd2xEd3bEf100f8e0Z//sTGekwpcxw+hxjC XERIXlSkZKzHhuRHgYRIZitIsnvIgJzIgcQpiizHjEQ+htjIxQNJeBRJe4zHGURGArxIjpTI lVTJkOxI9nJFR8xADWQkcHyImjzEcaTJNsRInszCiKxDoKxI/XMfnWxJTHQkgjTKUvRJoTxD oizKn4RKpMTEoEzKq7TKqETAqUxDp8TKr9TKqrxEg2SeRWqIMKLDnTRJY0zIq0TLhVBLpITL 5GHLkvTFtqzLulRKjcxLv5TLl7xHvXTLr6RLwrw/qbRLtgTMkfRLwUTDt/zIuLTLpXzMx2TM u1RHxUxLyuxLy1zMzjSis5TMvYzMySzNrXyZ/tE8zcOkx8/kTL4UTccEzdhEmNUczM+pTdoj zc2cTN1Eltv8y9C0zdmETdPETchMTa7sTdScS97MzeMUzt8kj+C8zOHczcGMP+MszOdMTudk TejkTvD0znQ0y9mMxw6Mwc9ET8usTMVkz+sEzvMczel8wPk0xvrER/ujz+hsy/QUT9b8T8Rs wPXkTwDNzvb0zPc00O8M0AT1SP88SPzsz3sU0MBc0Ak90AiNTxPMkOqs0PUkUAxdSAqFz/w8 yQLN0AFdzv1U0QttURLVUBDl0HWEUWA8Uf34UBMtUQZ9UQmN0QZFUBrN0fsEUh81TAttzBQ1 UiUd0RstS9LRUe/8/kX9xEn4DNLmxFErDVG51NJEOs8pLdEwldHwHFIUfc8xXVEWtdLqdM/9 61IxhVMyTdPyTMw3vdIjhcs2VdA73VPZ5FI8hUeeOktYLFMqPVNB9E3HdFNcytK3LFQ6FVTX RERFfVDizE32kdO5hFRN9VFODdTMnNREddTC/FQ/vVRKJdVNzVRQFb0fTdXD9FIkbdRYfVRW PVVUIdRbXdTdqxRCtU4wTUm15Exe/dPkJFZLzVXCRFYzXZ9lBU9Z5c1hhdZHBdZklc/wZNZo 7Y1fBc1iRdVpxc1tRdAkpaFxjdByRc5QtchwzctzBdF0/VZlzVZqLVVrbVa861YAPNR//jzW fvXUEMXXV21Xw6xTO33SLd3UgH1X9kzS8SxJff1XSRVVhH1VgEVTgZ1Vh1VXRt1YefU0cl3Y asVYho3YhL3YfYVSvvFASO3OHpzC+StZmF1AmfXGmFXZ/5vZMw1JnZVYiO3Zkx1JoLXYid3B oS1YobVZmsXGo3VZgmzah3VVtIRajtVIqv1Y6rzaa81apd3Zoh1U8kTaccTMqLUqOlxasjtb r11XvCTbqt0ntfXZo4rboF1XuiVatm1bjM1Y/HNbrBVAv91awN1bho2hsHVasz3csoVbxX1b YrpbsZVacyFYl9Vbki1Lyl3cx63YyO3Vk/RYwUVA0OVbNhXZ/rTlXMSFUAkd3cJ91rqdW9TV XHDJXMfFTj01Xaaj3b8VXdwtT90NXbyTTNbl1tit3X/5XdJd3d79Wnoc3tN13twt3t09Qeg1 2OZdXruVXuClxeotWuRt3bHFXtjt3uwl3/EVX88FFirlV5bsXMa9RtiF3/St29dNXPl9X4iM 3/ydX/rFW/0NyP9d2wCWW/6tXP+13/3FXwBG4AVWXTQBy+IRS9+VYO+l4Lw1WrJMWwue2w02 2w524I/84McV4dkl4eM14Q59Sq/MXRSWvxaWvhcO3oOkSuYYSqqzYZzFYeV82RXOYRqOSh1G zCC23hr8YSE2YusdYuZV4eiT3BZE/uIlVuILlmLjouIC/hUpjiEonuItruIuvuIZ7mEg/mKo suIyJuPxc2ExPuI1TmI0hhszTuNWbOMofmPMiWM4tuMU1pIspiU9TsY/1r9AphE8vuNBVuMq /KVC3uNupGMudmQvhuTLWuQfoWRBluQzxmSQsmQZbuSj1OIMZuFQnuBRXmIe/uQKLmW7jeE5 RuULxmBX5mBVluVY9uBZBmOm7ElRrmW4ZeUU9OVOXl/ivd/NJebZPcEdTskGLuYEZuZlPmZj Btn+dV9nFmAGtmYFxmY59tn6zWYC9uZuruZv3mb1ReYVjGYcEebTRWcDZOflfObjNWfflWdT nkV3pudx/obmZtZneE5hdY7ee3bI6RXo7e3kvVVXvAzo9k1dcQ5n2xVbh45nhXZJhuZnbX5o iD5gcNbohuZoi85naTZgav7oiE5nfB7gkjZohMbbhN5niXZpk55oIpVpbvbol+5nZb7okM7o kb5pnY5pmM5pkPbnk77moRbqlH7nn5YRD2zkFWzZWmLfcIRqhnzeb6zq6KVqh3ViNr3qrU5c rS7oqfZqsf5csk7eLw1rtBbeswZfWHWfsu7btsbZhlRrtx5Vp15r35xrq3akqDakF9vGXLpJ 7hXMbn1qw25N7+Xcw55nC23sei7Kx1bs8k3sMnVsyz7c8zVJyH7lWZzsy15s/tDWbLDObMzc bHOlbK6+Xc5W7dJu7dCubNgmbcYd7dPGp//CwBra7Ri07YNuQN++a8Z27do2bb1G7Nm+7eJO 7uN2XXjF3OGO7dVWXuYW7uCG7ut+XuN26+utbuze7u/2bu0W7yr7Ld0WbCYmy+AGRJ1QwvbW wupGwgHwQ/qebyl8b2/cbvmub/q+b/vO7/h2Qv7+76QscPhObUwV8Ple8CzEb+XRbwXnb/9m WQhfwwFvcAInWF2NcAY3cA8HcAQ3RSi88Ak/cHLdbwbPcPnO8OgWcTIk8SZ0cA1PSBSX8A8v 8BYHxQtX8Suk8AC38BTHcB8PcR0Pch6PwyE/cQ7v/u8tBuQiRG/LTW3IDd/WnvLf4d0qb9zl lnItJ+fSzXK33fLSDPPNnWwrf20uJ3OMFt7EPnMxd0s1j2cz7/JjnvM4J2o7f883h847H1ww 1/Myb3M6VxTzJsLdJuxjBO3RrWvL9tg9R1j7e/T/jHQvp24Ed/RAh21Mr/NGX09JZ1LFMUBF 9/RMv3RS53RNP3U573RAX3PnhnRJwXJTb/VVT3VaN+lRv3UAy0EqRB5EH2u/PnNppOpBx/Wr LnbAPfY+Z2pa9XVdF11lf3bqjXZKr3Nqj3VmJ/Zln/ZgR3Zo7/Zt595rNxQPbfbBlnZxB3d0 T/RxP5ZvD2Fvl6xLztRf/qfoh21pldzojNZ3Awbhld73jgZ4kmZpo+5ff//3fg/4hB94gffp mj7431Z1oM53hb/3gid4PNpA8yRopX74il9pfrd4iI/4dbd3kP/48wz5k3d1hBd5lJd4pMb4 ly95ZyVHlU/5ma92hzf4JKr3G8RnfF/bKwd6mWf4hd9pi2/4iRf6i1f6mHf6dmbJm4f5jud5 o3d5lid5nV96j7/6ld/5om8Xn39gotdMivd6nEd7qi93m895bOf4rX/6o2fkf76cqg97rrd6 sIf6/mt7taf5muZ7uH/7GZRqELRgX0R8W3bloW/lpnR3D1X8Xlblxv9lyl/8x7d7ppb8Eb78 /slnfMzXZc1/QM4vYc/vfND//MxXnVYEW44v+7mXe6zf+9hndr+n/dnPe7yX/a+ne6KfesCf 5tqH/dy3fal3e3In/t7n/bQXeymdXOUX0bPH/eW/e8G3z9vX/es3+ebX/uFn++P/+7i3/u9f 6OIH/+n3/vOP/rUf/OR/4mAt59d3f8in/9E3/+pHf6YH/vFn/+AHiH8CBwoEQPAgQoMI/w1g 6HAhxIgSFyqcWBBiw4wWD1a02JGgxoYbB36UWFJgyJEkVZ50qFElTIgtKWJ0GXNmwpovWfJc mBImTo46H3oEYPRozKRKc44MqtTpSp82gfZE+LOqx6Eilz7FCnKq/leTWm+GRQm2aVmbW7km hXpR6k60cq2e3ej2X8urc7PCJco2Lc2+a+2m1Ut479e4hxcfNPy3KFKOdwlHJhh5MtrKJI2+ pas4q+aCnPGOpRoa7+i8dR+DHm05dWmepy/Hzux6s0LVnycanA1bMGuyvnPXpnxbNHHgpo+j Tu7Zr/GStJUHby399/PB1hNib7yad3Puzr3vFju8M3noA7UH5+z6KGbw4yv2rr5y/v3ioNHT J009M3/5/WdfRPX515mB2QkX4EW6qScfg6Q5yJ55ESaYHoUECoVfg/pBeOCBFyb2YIUg9jfh giYKqKCGBfrX0YkelgjjihimSGOHA+6n/mKOLEqlYWowxjejZTW292KRPdpomoUgjpihTEhG JaGMLeaII5U6foiliOt9R+SUXZpVnoscZumjlTSZKaZaNyZ55pKyNYkikzzC+WSaas5ZZZRr OuklmX3uqSWYCP45JolmERjka6/B9yikkRrIZXOSPjqApZjCJ6WhmQKAqaaWfvoopyFWeumo oXq6qZ+egioqrLFaWuqJkr6qqq2ktprrq7DiSut9vI7qq65zCourrMnCCmyDx8b6666R3vps sXb25iyxrBorbarKeisqsxJiKyq020I6bbZIRXtut+m6Zy6qvYJrH6Ob0QtsfUNuWWS+EgWq p4r9RvRvTvgJ/jxUngUHeHBfddLI8HMO83tnehLnxyaiCSscMMUjWtwhxl+WuXDHgLp58aEm ayzgwyVnLCfHIRO8IckyJypozCm//CO9uQl5L4fjHRk0ehHDjKPQFR+dZNIer3wl00UrDSCP Tau8dFRW70wZg1qLnOakUev8NcBIS+001WaPPfPEVZ999cphZ/321juqjRPbLIuN981l7+1v olBy5d5HzLF17XUuDx6eZIrn3WziNgteMHPv8j35oow3KrlwlUM8dXTcOd435ZGvTTqQmtvL +XKmX96564Bjzq/no88+dO2sy5b76bdDLrrutsU+MIm+s7QpbqctdZe+YiEGOl+M/hn9vIvE G/8Y87KTRT3c0juPMGBMgf/02EJZv733aKcf5flUcV93ntm3H775468fmP3R6z+9SaSSv/j7 AHg/solvf9ADTwAfxxr55Q+BA1QgAxtGvzdJkHwR5J8Bq9fA72Wwex3EXwU1dsEDctCBIfxg ATFowhWSkCI++9/yJtiW8EGQhqijIAvVJ0IbGm+EOswh+zaoQRQqcIE8RB8RbzilJPbwiBZ0 ogzpRsD6MRGJQISfTF4IwxkGMIYJVKIUqajCEpLxh/GDYhdx2MIgVtF9DwTjkb7YRDlasYwe vGIK15g6OrqxjVHsXR2HOEYXimaLbfEWkBA5v6YoUohZ/lSW9v73rUgeD5KLtEsjT8ibTA4S bJzUo3iSRUlGWtKRLiylJj2Jyk6eUpSXhIwrTRlKWY1yk8ozJB7FaEQ+/vF1fcRjEf/iwzva EYSszKMgQanLZJrxjLxM4xKPuUw2SlONzCSmlYaJxWsaU5nWpKY3o1nMKRbScLgc5zQPh8YB ppOc4uSmO+P4xjnOM5DgbOY987lNsK0The2s4TPZ+c197rGevxwnQA3ay1r2r5DnhGYYuxJQ fw40nuWraDDVOdFcYhSO2rToRzOqUYVCFJAHhWdC/Ri3fnL0ndjUJzJf2k2U3hB55nxoO3Mq UZIK1KUEjelMZVpQlfZUiikF/qZHWZqwkCZ1o+jsKD2JulSlwvOfTeUpRX1qUWEiDzdA85zX Yngek+7uOl6r4Vh9+cS0MlQ+YDVqUtn6SreaFa7Xw57qkGNX2Ilnr63rK1mFB1i1rlSustzQ WwMbOsmcNa6JJexXWkS41TVvY5SqLM4u29ZCmQqydntT8Ao7qMO2TbNz5WyMTjsyaylWtKz1 7L7C1NrYdmqzqzUtaYc22lTeFrSzRa2Rwgk12cJWUYvS4mR1+9rUtcq2mfVtcXtLXOdKNlyh /ex0Vfvc7OZ2uLXVbjat+1vpfre7WcItb7db3vQyd7fV1Bt32WtZ6FJ3vvHt5F036VB7Iedb 1bqs/qwGIGBpDVhbr6VWpgqsLnjlKsHlOrC7/CthuXUKwbZS8LsgTC5yYZjCnbUwgR8M4AhP 2L/iDTCHRQxdEJ+rwydm8aVcvK5VldjEM27whVVMXBjDR8A6rjCJeyxjBnNrWT3bL2qAVrOL ztBgijNu2iYWMihzLWdOye/inDzluC75yicD2UWbqOUwb9HD/fLyx6i0ZTF32SJstrKbJYmv J3MZzhN5c8vW/GU1k5l4x93vTcXatYg2edB9xtpbwlrnu8VZzkQ7dJTnBukqM/rOe04Omh1t 6ExHOtERxfPfLJ1mTDf6aWb2tKgRLSVOUzrUgBs1ql/NsyO/B7Nq4p2t/ksHvElvp3F6/quv eT1V39BZzLgutWCDzepeb07Ywz52qpPd7GXTddfUNg+0ZV3YbPu5rNZG9mKnDW5mr87ZWO6f Zvy3y6KeFKZUzuqn7RnUyD4xjVHl6L2fmu+qwnHdFN23u6/6b3kD1Uv1FijA523whUab3dce bKBxSuiJt1vh725pvCte8Is7E+EE12nCNy5wfJd5giEH+ccrynF+a3Xl1bV3yls+cn3HPOOY RLLEAy5zLnpc4yj3ucr7LUyT19zZLLd5SR/OT5gDXeYnD/rTnS5npjNc2w4fN8aNLrok5/yp Oy+60i0OdbBjveMDbzrSr95weGs9vFRPetmP/t52kUv94Geverfhvvash71RXO/6I2NZnUnu Hd2CrwlQPkkXSSreO4lf5awxCfnFV/LwkY9b4+lNSstTfvO0LHyBMr9wzE/e8ZX/vNVhifq8 S57zpi8KzgEf9K+jfe46rTveEW93kte+77dPO9t9n7m3qz31fI+7zoFvdt7n/vLHB33ybe/Q iOf8o17sefM7X3zW75D4wUe+2HGvd+NP1fvPJ7/chU979fub+ePn/vnh73XlZzH2sqd4rn8v /fWDn+70Xzr2vZ/uCaDzzd/+DR7R9V7/6R/7Mdn/vVwAbt8ASmABpt8CJs/9RV/+zd4Dhl8H +t8Bth/NKSD0eWAI/lqf0A2d+RlgA6Jg1H3gvaygBZYgCLZgAppaV+kVAhrWDj7WBQZLXZ1g XjFOA+IVD04guemgDR5hBfaJD9Igcz0h+jlhEC6hFMpfmVwhEp4RE2pfEhLhD/4OY8Eg7VRh 2Z1bQ72H/QnacmVOc0FhadEXHMLXem0hF7pXE/rNfeWhfdUhH9JMG05heL2hIPZhZ4Xheclh IQIietnhIOKhF9LWIc6hd03iIsbhHkaiyw2OFvGXERHiDkLi67VaJo4idvmhJvITKDqielki FrZial0iHboiKz5iIL6iHqKiKUpiLOKiIfZiLbqhKGoeKeoiMZ4iLf4hJhrj6KUiJwLa/m3U 2IJpmK8gi1EMGTVOGDaOWI1t44pJIzhGyotJozfuGDn+2Ied4399Yzi24zRyY4mVI5B1IzrW ijoaGDy6ozSOIz2uozn2Iz6yYzzWIxDu45H93Rp2xZht4CyeWXvZmZJBJOCd2ucYYZsJo0Qq V545IAxRJJ0VWkZ+4kVG5EYypEiGpEWi5NAt5EOW5F+gISEhpEyq06OZZCJKmk2eWqlopKtN JLMoGkhWGkn2JE/iZAbeJKrl5E9SnKqRGkYKZdfpJFBeWqyFottwZFNWZVLAJCGp4UxmGbfh zvB81Vj2YFlG5RBaThSe5SeGZVuyZfWlZUWupFsaYV3SJVw+/hTifJsb3iVN+iVY5uVGcOUs jSECllT2qSC7JaZe/hFjChDbPeY5oSDPRSYB4hVirlRmUiBmLuZlHqXbeSZnKqZljmZjbub3 DZ9opub9USbZqWZpsiZaomb8yVNs1iZoAuBtsuBQZZ1kGpJrkmAMriZuxiVt8iZs+uZnTqZj LidkKqdp5uZw7uYMTid0yuZsEidyWqcB/iZwNmd0Xh91amBrgid2iqDcead0clXpHY7oLc97 PkV8ltl83kR9Pp7ruWd76uV9nl6sJNJ+wmeA0ueAHlKB2ueB4ufqrSeDNqiDPiiERqiETiiF VqiFXiiGZqiGbiiHdqiHfiiIhqiI/o4oiZaoiZ4oiqaoiq4oi7aoi74ojMaojM4ojdaojd7o QT6GDayAxO0ojv4okAapkOKUjxIpjw7pUYKApDTOAtnkISGpJyKEkp7ElBLElDopaxTpyvio loJDLQDCEgABlI7phF4pAIBAe2Bp4pFpaxaOJ0kc9ZmoktrAQdjAmfpd/cUknrapBV3LQFhA Dk7oTVWplN7GlYKmlmoMlx6pQCjDCgDACtSCh8bp8cCpmrKpfB6EBQzEoXLqUVQDoEaqQKjD IjwqAFjAkQLBo9DpRpCqqaLqQIBDHSgpCIBBNQxENYABoIJBLaTqqhKEOgACoFoAIKiDQFwp qEKqpGao/lEs6z/UAqVG6Z4mJE5F61+ow6li66YyaQbOaZ3eqbRyq7hSK3/26d9VAwAAQTVU AQBUQoea0xIoKbEa66iWqlHA6j+oKnywqkW46r0yqqzSqq3iqq4CAK/66r4Cq7CearEe66eG qrNiKlcJBL+OK2pYgCr8AyAcqZ0qwz9UggVsK7kiRMd+bMgKBKhagMcqQ8jeasqCgkA86rT+ AziAgAXALCiELDhsBsZqLKNeqFGAgLGqA6H+Q6cSBMhaALp2RNIu7dbF6qye6cD2q72eKsBG ba3eKsoW7MEKhL4eRcUG67A2rNE+rLJuBDCka9qKqcVOJAA4K7RihjnVzlFa/itbaKu2DsSj ai24bmjEKQMA8GvJJu3MTsTgnuw/pOzKtmzihizM/oPMhmvN3uw/5KwF7Kxo9OzGSmyT3pLn ZKymQmod1AK9hutEhOrolq6SPu4/AC6a2qmzCuvMLgEAAMJAQCvbogbocmjQ2i4gFC2SqQPt qoIqAKpCCC8AEK/xPm3jqmzrMq7hAoDHEm7zLq7SNu/jRm7sTS7O6izPZuzmTsTXgm3bRuWZ Dm3RHu1ANO1tsG/iEETASq3WToS/Wi3UCuz85uqu9qrX/upAiC3D0iuyQizaqm26/umROi3v OoVroC7plm9EOLDqAgDruu4/wO5AyG640q7tCgTu/m7G7nJukwqEyFqs4dSC8Z7p/H6lRKDw UYAA3y5poDEHoJbu39mtgxoF4KYt4BZORwAq6KrCaACxQAjx+zpsBfdtBIvuAyPxQFgwBguE BsceB9/uAYtGCG8EINTuFndw4ZovCPgu8CIk8irvaJRx8dItyoas9a4wRBzutiru817vy8bs zxwE91au92Yu+P4sRIyvUVTsP6jDo7rrAhMEv4KCqbqGCwftCtttI6twf+kKTtAwANhwrYlw jubpF9NsLdTBqXayRHgpKG+rkrqxaGCuQFTBzD6qx6Js3+Jwg3LGGgDAGshkNN5xLjPvrExE JMPwJLNKJZdEDeOp3drp/qPk7shOpvQCAA8fx20Q8T8YMQknbxGrcdkmMZqeLhNPsDZf8Ntm cAkzRxV78BXrbkx0cReTrPROKo5wsDpg60eQciibrkXQsykDACqjhir/AyuHqyvjaixf6phG HDbr7S0nrhIbxa2CgjJHxAokNLpuM+7eqjqAgo/WchVg7hr8LENXLttCKwjsLDg8qhfLMoNy hjoAgbFCs5BorQJ/tEIfcdnu80bgs8Pus1H08z/HXkDD8jazsESoKjAQNfPyaS3fskvvab3E Xi6Loy+nMDCfijA3VOhiMn1gBjLDhzLXchZraDRWs7FucUVENFC/RkM/NESYtUJTdLpaNEbz /qhGc7RH6zNIm/NI06xJ27MmJ8WVBrWnPgqamqkSpzAALMEKgwMYGMUSsK5EGDZiP/EigwAQ GHItXGlkx+piH3YFb7UNvDJhAzaGLvWeVsMKKG2yKoRpo/byimtFD3JcWwRbT7Q5qytsZzQA bLRAdDRa3/WznilJ7/UyH8Qpn/JRy55KszQuvzQs+wxMY7NxKwVO17QL8XQrt/NZDzdBELVR D4QQ9/SGEnZkXPapLkLQVvNRZLZAKDZjO/YSp/f8OuoLV7YHY3Zib3ZjP7Fng7Zg97V/t+hf l+15i/c2q0MtJ+95D/KBG/E2E3ijTjZ9czN8S/Z8W7Z9wy9+dzbYlvI3fIh2GnaEg/PptN7G aldDaqPsaZt4a+/pa190oq61RINri8f2XO92Xac1Xgd37fJ1RBS3XV8zeP+3kA85kRc5+VgA muLrgwY4k0NKgS94ghu4UTC4w/Z360K4IT82fKi3fAdthJM3Y993e+v3hlf5C1fqU5+5ka85 m7e5m7+5iyL5Pyg5nNe5nd85nue5nu+57AUEAAA7 --------------B1748F8B1526F5BB89B649BE-- From Michael Riepe Sun Sep 24 01:03:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00309 for ; Sun, 24 Sep 2000 18:03:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:33 +0200 (MEST) Received: (qmail 24872 invoked by uid 0); 23 Sep 2000 23:06:18 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 23 Sep 2000 23:06:18 -0000 X-eGroups-Return: sentto-1101623-801-969750358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 23 Sep 2000 23:06:13 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 23:05:52 -0000 Received: (qmail 8331 invoked from network); 23 Sep 2000 23:05:52 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Sep 2000 23:05:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.139) by mta1 with SMTP; 23 Sep 2000 23:05:48 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02106; Sun, 24 Sep 2000 01:03:51 +0200 Message-ID: <20000924010351.64499@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 01:03:51 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] LRU proposal #2 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" X-UIDL: ad3db0fd1ae3cb42a22355d7dbd33905 Status: R X-Status: N --UugvWAfsgieZRqgk Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
eGroups My Groups | f-cpu Main Page

OK, this is my second attempt.  There is no carry logic this time, and
no need to use look-ahead.  This unit is slightly more complex but
also more modular (2^n identical stages).

So, how does it work?  While my first version translated `relative time
of use' (or `queue position') to `cache line number', this one does the
reverse translation.  A right-shift operation in the queue becomes a
decrement, move-to-front becomes `set counter to all ones', and
`lru[line] == 0' means `least recently used'.

Hope you like it...
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"It's just a jump to the left // And then a step to the right"
  -- The Rocky Horror Picture Show, "Time Warp"
 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="lru2.c" /* LRU-2 Design Proposal for the F-CPU Copyright (C) 2000 Michael Riepe This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Description: This LRU uses 2^n independent stages (1 per cache line) and a common `reference bus'. Each stage consists of an n-bit register and an n-bit unsigned magnitude comparator that compares the number on the reference bus with the contents of the register. There are two control lines, `Enable' (global) and `Update' (per-stage), and one output line, `Zero', indicating the least recently used cache line. The register has three operating modes: - when Enable = 0 => do nothing. - when Enable = 1 and Update = 0 => when the number in the register is bigger than the number on the reference bus, decrement @ the next clock cycle, otherwise do nothing. - when Enable = 1 and Update = 1 => put register contents on the reference bus (immediately). set the register to (2^n)-1 @ the next clock cycle. To update the LRU unit, set the global Enable line and the Update line for the corresponding cache line to `1', all other Update lines to `0'. The reference bus can be either a real bus or a n:1 multiplexer. */ #define DEGREE 8 #define NLINES (1u << DEGREE) unsigned lru[NLINES]; void lru_init(void) { unsigned i; for (i = 0; i < NLINES; i++) { lru[i] = i; } } unsigned lru_lookup(void) { unsigned i; for (i = 0; i < NLINES; i++) { if (lru[i] == 0) { return i; } } } void lru_update(unsigned line) { unsigned i; for (i = 0; i < NLINES; i++) { if (lru[i] > lru[line]) { lru[i] -= 1; } } lru[line] = NLINES - 1; } --UugvWAfsgieZRqgk-- From Michael Riepe Sat Sep 23 19:02:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00312 for ; Sun, 24 Sep 2000 18:03:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:34 +0200 (MEST) Received: (qmail 23734 invoked by uid 0); 23 Sep 2000 23:06:34 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 23 Sep 2000 23:06:34 -0000 X-eGroups-Return: sentto-1101623-802-969750384-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 23 Sep 2000 23:06:29 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 23:06:24 -0000 Received: (qmail 16991 invoked from network); 23 Sep 2000 23:06:24 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 23 Sep 2000 23:06:24 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.139) by mta1 with SMTP; 23 Sep 2000 23:06:21 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01180; Sat, 23 Sep 2000 19:02:16 +0200 Message-ID: <20000923190216.40391@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> <20000922193916.21054@thrai.stud.uni-hannover.de> <39CCB102.F19B6966@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CCB102.F19B6966@f-cpu.org>; from Yann Guidon on Sat, Sep 23, 2000 at 03:32:50PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 19:02:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 090629c861dc43519bd4abaacab29fec Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sat, Sep 23, 2000 at 03:32:50PM +0200, Yann Guidon wrote:

> > While we're at it, a SIMD equivalent of the ix86 `xlatb' instruction
> > would be nice for table-based translation operations, like character set
> > translation, pixel manipulation, colormap lookups and so on.  It could
> > also be used for the popcount instruction, but is much more general
> > (although probably not as fast as a hardwired population count FU).
>
> popcount is easily done. it simply requires a special execution unit
> but it's being considered (look at the instruction set).

I did... and I think that a special execution unit for a single
instruction that is rarely used is a waste of time, space, and money,
unless you're building an application specific processor.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sat Sep 23 18:55:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00315 for ; Sun, 24 Sep 2000 18:03:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:35 +0200 (MEST) Received: (qmail 14328 invoked by uid 0); 23 Sep 2000 23:06:40 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 23 Sep 2000 23:06:40 -0000 X-eGroups-Return: sentto-1101623-803-969750394-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ho.egroups.com with NNFMP; 23 Sep 2000 23:06:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 23:06:34 -0000 Received: (qmail 1125 invoked from network); 23 Sep 2000 23:06:34 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 23 Sep 2000 23:06:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.139) by mta1 with SMTP; 23 Sep 2000 23:06:27 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01161; Sat, 23 Sep 2000 18:55:50 +0200 Message-ID: <20000923185550.21839@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39CBB776.2C04F137@f-cpu.org> <20000923015551.33827@thrai.stud.uni-hannover.de> <39CCB103.16258737@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CCB103.16258737@f-cpu.org>; from Yann Guidon on Sat, Sep 23, 2000 at 03:32:51PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Sep 2000 18:55:50 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (c) LRU C code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 16ac80d80cf50ffa1524a83f04bf3f97 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sat, Sep 23, 2000 at 03:32:51PM +0200, Yann Guidon wrote:

> As for the HW, if you still read the code, you'll see that i found an
> interesting idea. instead of shifting back, that is in the reverse order,
> we simply have to disable the normal shifting for the next LRU read update :-)

Yes, I've noticed that, but unfortunately the results differ:

Case 1: shift backwards on invalidation (correct but expensive)

      7 6 5 4 3 2 1 0
      | | |  / / / /
      7 6 5 3 2 1 0 4            invalidate 4
      \ \ \ \ \ \ \
      4 7 6 5 3 2 1 0            use LRU (4)
      \ \ \ \ \ \ \
      0 4 7 6 5 3 2 1            use next LRU (0)

Case 2: do nothing on invalidation (cheapest version)

      7 6 5 4 3 2 1 0
      | | | | | | | |
      7 6 5 4 3 2 1 0            invalidate 4 -- no update
      \ \ \ \ \ \ \
      0 7 6 5 4 3 2 1            use LRU (0)
      \ \ \ \ \ \ \
      1 0 7 6 5 4 3 2            use next LRU (1)

Case 3: do nothing on invalidation, and skip next update (clever version)

      7 6 5 4 3 2 1 0
      | | | | | | | |
      7 6 5 4 3 2 1 0            invalidate 4 -- no update
      | | | | | | | |
      7 6 5 4 3 2 1 0            use LRU (0) -- no update
      \ \ \ \ \ \ \
      0 7 6 5 4 3 2 1            use next LRU (0 *again* -- thrashing!)

As you can see, skipping the next update may be *too* clever under
some circumstances.  I vote for the cheapest implementation.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sun Sep 24 01:17:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00320 for ; Sun, 24 Sep 2000 18:03:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:37 +0200 (MEST) Received: (qmail 22498 invoked by uid 0); 23 Sep 2000 23:18:59 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 23 Sep 2000 23:18:59 -0000 X-eGroups-Return: sentto-1101623-804-969751135-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 23 Sep 2000 23:18:56 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 23 Sep 2000 23:18:55 -0000 Received: (qmail 1389 invoked from network); 23 Sep 2000 23:18:55 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Sep 2000 23:18:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.139) by mta1 with SMTP; 23 Sep 2000 23:18:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02275; Sun, 24 Sep 2000 01:17:16 +0200 Message-ID: <20000924011715.18393@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> <39CCDCD3.A7A3350B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CCDCD3.A7A3350B@f-cpu.org>; from Yann Guidon on Sat, Sep 23, 2000 at 06:39:47PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 01:17:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8fb8691400c55be1f3279caa4b9c443f Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sat, Sep 23, 2000 at 06:39:47PM +0200, Yann Guidon wrote:

> This said, i think that Michael did a little "conceptual error",
> or used a naive first approach : he has put a multiplexer in front
> of the data input of each register in the queue. ok, this is only a
> 2:1 mux, but it's already annoying enough (transistorwise).
> with my solution, it could become a simple pass transistor, a AND gate.
> Rememeber that a shifting register connects the output to the input
> of the next cell. The trick is to AND the clock signal, instead of
> selecting the source. This way, only a part of the register is shifted
> and the datapath is kept simple, since the comparison affects the
> control path.

Didn't I mention that in my mail?  Of course a gated clock works fine
(if the target technology supports it, which may not be the case for
FPGAs, for example).  The picture looks very good, btw -- but please
have a look at my second version, too.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Sun Sep 24 03:29:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00323 for ; Sun, 24 Sep 2000 18:03:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:38 +0200 (MEST) Received: (qmail 17513 invoked by uid 0); 24 Sep 2000 01:25:59 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 24 Sep 2000 01:25:59 -0000 X-eGroups-Return: sentto-1101623-805-969758751-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 24 Sep 2000 01:25:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 01:25:50 -0000 Received: (qmail 30998 invoked from network); 24 Sep 2000 01:25:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 Sep 2000 01:25:50 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 24 Sep 2000 01:25:50 -0000 Received: from f-cpu.org (nas2-223.ras.club-internet.fr [195.36.192.223]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA17690 for ; Sun, 24 Sep 2000 03:16:56 +0200 (MET DST) Message-ID: <39CD5916.ECC81C03@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39CBB776.2C04F137@f-cpu.org> <20000923015551.33827@thrai.stud.uni-hannover.de> <39CCB103.16258737@f-cpu.org> <20000923185550.21839@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 02:29:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (c) LRU C code Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c4ebf2d65ce5ffa565eba2daa3808fcc Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> On Sat, Sep 23, 2000 at 03:32:51PM +0200, Yann Guidon wrote:
> > As for the HW, if you still read the code, you'll see that i foun= d an
> > interesting idea. instead of shifting back, that is in the revers= e order,
> > we simply have to disable the normal shifting for the next LRU re= ad update :-)
>
> Yes, I've noticed that, but unfortunately the results differ:
>
> Case 1: shift backwards on invalidation (correct but expensive)
>
>         7 6 5 4 3 2 1 0
>         | | |  / / / / >         7 6 5 3 2 1 0 4 &= nbsp;       invalidate 4
>          \ \ \ \ \ \ \ >         4 7 6 5 3 2 1 0 &= nbsp;       use LRU (4)
>          \ \ \ \ \ \ \ >         0 4 7 6 5 3 2 1 &= nbsp;       use next LRU (0)
>
> Case 2: do nothing on invalidation (cheapest version)
>
>         7 6 5 4 3 2 1 0
>         | | | | | | | |
>         7 6 5 4 3 2 1 0 &= nbsp;       invalidate 4 -- no update
>          \ \ \ \ \ \ \ >         0 7 6 5 4 3 2 1 &= nbsp;       use LRU (0)
>          \ \ \ \ \ \ \ >         1 0 7 6 5 4 3 2 &= nbsp;       use next LRU (1)
>
> Case 3: do nothing on invalidation, and skip next update (clever versi= on)
>
>         7 6 5 4 3 2 1 0
>         | | | | | | | |
>         7 6 5 4 3 2 1 0 &= nbsp;       invalidate 4 -- no update
>         | | | | | | | |
>         7 6 5 4 3 2 1 0 &= nbsp;       use LRU (0) -- no update
>          \ \ \ \ \ \ \ >         0 7 6 5 4 3 2 1 &= nbsp;       use next LRU (0 *again* -- thrash= ing!)
>
> As you can see, skipping the next update may be *too* clever under
> some circumstances.  I vote for the cheapest implementation.

in fact i was imagining something even smarter. but the cheap way is still = ok.
unless i find something even better, i stick to the simplest which is
the lazy way.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 03:35:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00326 for ; Sun, 24 Sep 2000 18:03:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:39 +0200 (MEST) Received: (qmail 10271 invoked by uid 0); 24 Sep 2000 01:31:52 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 24 Sep 2000 01:31:52 -0000 X-eGroups-Return: sentto-1101623-806-969759108-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 24 Sep 2000 01:31:50 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 01:31:48 -0000 Received: (qmail 14167 invoked from network); 24 Sep 2000 01:31:48 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 24 Sep 2000 01:31:48 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 24 Sep 2000 01:31:47 -0000 Received: from f-cpu.org (nas2-223.ras.club-internet.fr [195.36.192.223]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA00647 for ; Sun, 24 Sep 2000 03:31:36 +0200 (MET DST) Message-ID: <39CD5A7B.870BFAB1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <39C98C68.431F6CC4@f-cpu.org> <20000921191830.23994@thrai.stud.uni-hannover.de> <39CB51E1.66E574B1@f-cpu.org> <20000922193916.21054@thrai.stud.uni-hannover.de> <39CCB102.F19B6966@f-cpu.org> <20000923190216.40391@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 02:35:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a1cff910345fef2f1e83dcbfb82c5344 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi again,

Michael Riepe wrote:
> On Sat, Sep 23, 2000 at 03:32:50PM +0200, Yann Guidon wrote:
> > > While we're at it, a SIMD equivalent of the ix86 `xlatb' ins= truction
> > > would be nice for table-based translation operations, like c= haracter set
> > > translation, pixel manipulation, colormap lookups and so on.=   It could
> > > also be used for the popcount instruction, but is much more = general
> > > (although probably not as fast as a hardwired population cou= nt FU).
> > popcount is easily done. it simply requires a special execution u= nit
> > but it's being considered (look at the instruction set).
> I did... and I think that a special execution unit for a single
> instruction that is rarely used is a waste of time, space, and money,<= BR> > unless you're building an application specific processor.

the popcount execution unit is optional.
however i have seen several cases where it is VERY useful.
For example, in the field that i studied, we usually count the
bits to break up some transformations that have some symmetries.
the transformation code can be greatly reduced by using
some particle-hole dualities.

we kept an entry for any instruction that might appear in the future,
that doesn't meant that we'll have to include them in the first silicons.
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 03:44:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00329 for ; Sun, 24 Sep 2000 18:03:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:40 +0200 (MEST) Received: (qmail 7249 invoked by uid 0); 24 Sep 2000 01:40:06 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 24 Sep 2000 01:40:06 -0000 X-eGroups-Return: sentto-1101623-807-969759602-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by b05.egroups.com with NNFMP; 24 Sep 2000 01:40:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 01:40:01 -0000 Received: (qmail 32298 invoked from network); 24 Sep 2000 01:40:01 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 24 Sep 2000 01:40:01 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 24 Sep 2000 01:40:01 -0000 Received: from f-cpu.org (nas2-223.ras.club-internet.fr [195.36.192.223]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA17004 for ; Sun, 24 Sep 2000 03:39:49 +0200 (MET DST) Message-ID: <39CD5C66.5CE450BF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 02:44:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 45e1565f821861aa06c8621430172ec1 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> OK, this is my second attempt.  There is no carry logic this time= , and
> no need to use look-ahead.  This unit is slightly more complex bu= t
> also more modular (2^n identical stages).

it also looks more structured for a cycle-accurate simulator.

> So, how does it work?  While my first version translated `relativ= e time
> of use' (or `queue position') to `cache line number', this one does th= e
> reverse translation.  A right-shift operation in the queue become= s a
> decrement, move-to-front becomes `set counter to all ones', and
> `lru[line] =3D=3D 0' means `least recently used'.

hmm, that's a pretty curious change of mind. could you write a little
testbench for this too ? can you also elaborate on the general algorithm and the modus operandi ? we'll keep the simplest and easiest of both
options, but i presume that in the end, representing the same data in diffe= rent
ways won't yield much win. the discussion about the entropy of LRU is open = :-)

> Hope you like it...
i'll take a serious look at it.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "It's just a jump to the left // And then a step to the rig= ht"
>   -- The Rocky Horror Picture Show, "Time Warp" WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 03:47:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00332 for ; Sun, 24 Sep 2000 18:03:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:41 +0200 (MEST) Received: (qmail 9695 invoked by uid 0); 24 Sep 2000 01:43:23 -0000 Received: from jk.egroups.com (208.50.144.83) by mx19.rz2.gmx.net with SMTP; 24 Sep 2000 01:43:23 -0000 X-eGroups-Return: sentto-1101623-808-969759801-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jk.egroups.com with NNFMP; 24 Sep 2000 01:43:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 01:43:21 -0000 Received: (qmail 5807 invoked from network); 24 Sep 2000 01:43:21 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 24 Sep 2000 01:43:21 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 24 Sep 2000 01:43:20 -0000 Received: from f-cpu.org (nas2-223.ras.club-internet.fr [195.36.192.223]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA23491 for ; Sun, 24 Sep 2000 03:43:09 +0200 (MET DST) Message-ID: <39CD5D30.E23FF7D9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> <39CCDCD3.A7A3350B@f-cpu.org> <20000924011715.18393@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 02:47:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : the Latest Riepe's Uptake (LRU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 83e2860c69cb49552a8d97e366080dc6 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

last hi for tonight...

Michael Riepe wrote:
> On Sat, Sep 23, 2000 at 06:39:47PM +0200, Yann Guidon wrote:
>
> > This said, i think that Michael did a little "conceptual err= or",
> > or used a naive first approach : he has put a multiplexer in fron= t
> > of the data input of each register in the queue. ok, this is only= a
> > 2:1 mux, but it's already annoying enough (transistorwise).
> > with my solution, it could become a simple pass transistor, a AND= gate.
> > Rememeber that a shifting register connects the output to the inp= ut
> > of the next cell. The trick is to AND the clock signal, instead o= f
> > selecting the source. This way, only a part of the register is sh= ifted
> > and the datapath is kept simple, since the comparison affects the=
> > control path.
>
> Didn't I mention that in my mail?  Of course a gated clock works = fine
> (if the target technology supports it, which may not be the case for > FPGAs, for example).  The picture looks very good, btw -- but ple= ase
> have a look at my second version, too.

i didn't see anything like that in your first descriptions but i may have not remarked it, not seeking it :-) and i'm not very picky on this currentl= y.

i'll try to see how your second version works. this reorganisation might je= opardize
some of the precedent efforts but i'll search what can be saved and what ca= n be won.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Nicolas Boulay Sun Sep 24 12:53:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00344 for ; Sun, 24 Sep 2000 18:03:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:44 +0200 (MEST) Received: (qmail 27176 invoked by uid 0); 24 Sep 2000 10:49:48 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 24 Sep 2000 10:49:48 -0000 X-eGroups-Return: sentto-1101623-809-969792585-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 24 Sep 2000 10:49:47 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 10:49:44 -0000 Received: (qmail 16776 invoked from network); 24 Sep 2000 10:49:44 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 24 Sep 2000 10:49:44 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 24 Sep 2000 10:49:44 -0000 Received: from 194.158.109.231 [194.158.109.231] by lh00.opsion.fr; Sun, 24 Sep 2000 10:47:49 GMT Message-ID: <39CDDD3A.1A3DB106@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> <39CCDCD3.A7A3350B@f-cpu.org> <20000924011715.18393@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 12:53:46 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : gated clock Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9e03922f5f1bbb230fed71a84a20d4c1 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

One year or 2 ago, in a synchronous design, it was definitely and
absolutely forbiden to make gated clock. Because of the skew, and that
the cad tools could't manage this, todays and because of danger of
spike. Nowdays, you could do that BUT for low power purpose only.

nicO

Michael Riepe a =E9crit :
>
>
> On Sat, Sep 23, 2000 at 06:39:47PM +0200, Yann Guidon wrote:
>
> > This said, i think that Michael did a little "conceptual err= or",
> > or used a naive first approach : he has put a multiplexer in fron= t
> > of the data input of each register in the queue. ok, this is only= a
> > 2:1 mux, but it's already annoying enough (transistorwise).
> > with my solution, it could become a simple pass transistor, a AND= gate.
> > Rememeber that a shifting register connects the output to the inp= ut
> > of the next cell. The trick is to AND the clock signal, instead o= f
> > selecting the source. This way, only a part of the register is sh= ifted
> > and the datapath is kept simple, since the comparison affects the=
> > control path.
>
> Didn't I mention that in my mail?  Of course a gated clock works = fine
> (if the target technology supports it, which may not be the case for > FPGAs, for example).  The picture looks very good, btw -- but ple= ase
> have a look at my second version, too.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Michael Riepe Sun Sep 24 15:39:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00359 for ; Sun, 24 Sep 2000 18:03:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:48 +0200 (MEST) Received: (qmail 17481 invoked by uid 0); 24 Sep 2000 15:13:45 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 24 Sep 2000 15:13:45 -0000 X-eGroups-Return: sentto-1101623-810-969807496-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 24 Sep 2000 14:58:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 14:58:15 -0000 Received: (qmail 15437 invoked from network); 24 Sep 2000 14:58:15 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Sep 2000 14:58:15 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.218) by mta3 with SMTP; 24 Sep 2000 14:58:13 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00706; Sun, 24 Sep 2000 15:39:52 +0200 Message-ID: <20000924153952.46294@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CD5C66.5CE450BF@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CD5C66.5CE450BF@f-cpu.org>; from Yann Guidon on Sun, Sep 24, 2000 at 02:44:06AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 15:39:52 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 07e451a740cfb311f0bf4facd83a05b2 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sun, Sep 24, 2000 at 02:44:06AM +0100, Yann Guidon wrote:

> > So, how does it work?  While my first version translated `relative time
> > of use' (or `queue position') to `cache line number', this one does the
> > reverse translation.  A right-shift operation in the queue becomes a
> > decrement, move-to-front becomes `set counter to all ones', and
> > `lru[line] == 0' means `least recently used'.
>
> hmm, that's a pretty curious change of mind. could you write a little
> testbench for this too ? can you also elaborate on the general algorithm
> and the modus operandi ? we'll keep the simplest and easiest of both
> options, but i presume that in the end, representing the same data in different
> ways won't yield much win. the discussion about the entropy of LRU is open :-)

It's not a change of mind -- just another viewpoint :)

The biggest win is that there is no stage-to-stage signal propagation
delay; the `carry chain' is broken.  On the other hand, we also lose:
the magnitude (P>Q) comparators are more complex than simple xor-nor
`P=Q' style ones, and we need synchronous binary counters.  There's also
a high load on the reference bus.  There ain't no such thing as a perfect
design. *sigh*

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From root Sun Sep 24 19:01:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00371 for ; Sun, 24 Sep 2000 18:03:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Sep 2000 18:03:53 +0200 (MEST) Received: (qmail 31053 invoked by uid 0); 24 Sep 2000 15:45:24 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 24 Sep 2000 15:45:24 -0000 X-eGroups-Return: sentto-1101623-811-969810317-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 24 Sep 2000 15:45:23 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 15:45:17 -0000 Received: (qmail 11259 invoked from network); 24 Sep 2000 15:45:17 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 Sep 2000 15:45:17 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta2 with SMTP; 24 Sep 2000 15:45:16 -0000 Received: from modem-75.azaghal.dialup.pol.co.uk ([62.136.131.203] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13dDxq-0001FE-00 for f-cpu@egroups.com; Sun, 24 Sep 2000 16:45:15 +0100 Sender: root@pop.gmx.net Message-ID: <39CE335A.81492E33@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <00092214555403.00382@gandalf> From: root MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 18:01:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] logic optimization (was: schematics) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 49958df8a680efa4495b83f67dedb69d Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

Jecel Assumpcao Jr wrote:

>
> On Fri, 22 Sep 2000, Jeff Davies wrote:
>
>
> Very true, but in that case you might as well draw it as a simple box
> marked as "full adder" and be done with it (both programs you mentioned
> should have this in their library, I would expect).
>
> -- Jecel

Yes, you are in the right. You can just put a core of a CPU in as well. I was
jstu saying that
(excuse me if I am wrong), different empirical gate designs are used in
different technologies.
EG: the CLB in an FPGA (which I think can be any of OR,AND,NAND,NOR), whereas as
ASIC
might be NAND based, or other (I am not up on this kind of thing). Therefore I
beleive it would be
best to draw your circuit how you can understand it & then optimise the boolean
expression to
whatever technology you are mapping to, rather than jumping straight in at the
optimised level.

Jeff Davies

 From Yann Guidon Sun Sep 24 20:04:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00305 for ; Mon, 25 Sep 2000 16:47:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:49 +0200 (MEST) Received: (qmail 2694 invoked by uid 0); 24 Sep 2000 18:00:32 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 24 Sep 2000 18:00:32 -0000 X-eGroups-Return: sentto-1101623-812-969818423-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 24 Sep 2000 18:00:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 18:00:22 -0000 Received: (qmail 2838 invoked from network); 24 Sep 2000 18:00:22 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 Sep 2000 18:00:22 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 24 Sep 2000 18:00:21 -0000 Received: from f-cpu.org (nas2-197.ras.club-internet.fr [195.36.192.197]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA04976 for ; Sun, 24 Sep 2000 20:00:18 +0200 (MET DST) Message-ID: <39CE423A.DFD02155@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 19:04:42 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] EDA tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e1ba11aec3f4f5ad7a84c9f2213fff19 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi,

so i tried to setup/compile PICA but it wouldn't extract
>from the archive. it's so sad. So i started reading Electric's
manual :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 22:06:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00314 for ; Mon, 25 Sep 2000 16:47:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:51 +0200 (MEST) Received: (qmail 26731 invoked by uid 0); 24 Sep 2000 20:02:48 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 24 Sep 2000 20:02:48 -0000 X-eGroups-Return: sentto-1101623-813-969825761-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ef.egroups.com with NNFMP; 24 Sep 2000 20:02:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 20:02:41 -0000 Received: (qmail 2769 invoked from network); 24 Sep 2000 20:02:41 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Sep 2000 20:02:41 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 24 Sep 2000 20:02:40 -0000 Received: from f-cpu.org (nas1-195.aub.club-internet.fr [195.36.150.195]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA26773 for ; Sun, 24 Sep 2000 22:02:37 +0200 (MET DST) Message-ID: <39CE5EE0.3DA4D08F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> <39CCDCD3.A7A3350B@f-cpu.org> <20000924011715.18393@thrai.stud.uni-hannover.de> <39CDDD3A.1A3DB106@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 21:06:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : gated clock Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 45514113ee6110ad8e891f413db77237 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Nicolas Boulay wrote:
> One year or 2 ago, in a synchronous design, it was definitely and
> absolutely forbiden to make gated clock. Because of the skew, and that=
> the cad tools could't manage this, todays and because of danger of
> spike. Nowdays, you could do that BUT for low power purpose only.

so what do you propose ? an "enable" input ? What ? the multiplex= or
is rather heavy...

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 22:07:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00317 for ; Mon, 25 Sep 2000 16:47:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:52 +0200 (MEST) Received: (qmail 4886 invoked by uid 0); 24 Sep 2000 20:02:25 -0000 Received: from jj.egroups.com (208.50.144.82) by mx06.rz2.gmx.net with SMTP; 24 Sep 2000 20:02:25 -0000 X-eGroups-Return: sentto-1101623-814-969825786-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 24 Sep 2000 20:03:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 20:03:05 -0000 Received: (qmail 17191 invoked from network); 24 Sep 2000 20:03:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 24 Sep 2000 20:03:05 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 24 Sep 2000 20:03:04 -0000 Received: from f-cpu.org (nas1-195.aub.club-internet.fr [195.36.150.195]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA20070 for ; Sun, 24 Sep 2000 22:03:01 +0200 (MET DST) Message-ID: <39CE5EFD.81686A55@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 21:07:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 32ae2ca66394ddecfc8262d329ed39a7 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> OK, this is my second attempt.  There is no carry logic this time= , and
> no need to use look-ahead.  This unit is slightly more complex bu= t
> also more modular (2^n identical stages).
>
> So, how does it work?  While my first version translated `relativ= e time
> of use' (or `queue position') to `cache line number', this one does th= e
> reverse translation.  A right-shift operation in the queue become= s a
> decrement, move-to-front becomes `set counter to all ones', and
> `lru[line] =3D=3D 0' means `least recently used'.
>
> Hope you like it...
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "It's just a jump to the left // And then a step to the rig= ht"
>   -- The Rocky Horror Picture Show, "Time Warp"
Now i remember what my first (ever) idea was : in order to avoid the
decrementation of ALL the elements, i made the contrary :
i compared the elements with a "cyclic trigger". but this never w= orked
and i had cases where two lines had the same value, so we could not disting= uish
which line was the LRU. I see that Michael solved the problem.

Now, what would it give if he adapted his algo with the cyclic trigger ? that means that we need 2 buses, and LRU is when trigger=3Dvalue.
When we use a line, it is set as trigger-1. no decrementation !!!
but we can't avoid the comparison... and this is still rather complex.


now i see that the first algo had the following advantages :
- it can easily be pipelined (we can separate the different stages)
- it can easily be adapted for the D-Cache where we directly have a list of= lines to flush.
- there is only one bus to compare with 4 xors and 1 AND.
- it can be folded as to reduce wire lengths :

instead of -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0= -0-0-0-0-0-
we can do
-0-0-0-0-0-0-0-0\
/0-0-0-0-0-0-0-0/
\0-0-0-0-0-0-0-0\
/0-0-0-0-0-0-0-0/
\0-0-0-0-0-0-0-0\
  0-0-0-0-0-0-0-0/
or fold in a "fractal" way (self-similar, easier to route).
instead of having length N, we have length sqrt(2N).
The clock tree is faster to propagate.

I hope you like and come up with a better algorithm :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 22:07:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00322 for ; Mon, 25 Sep 2000 16:47:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:53 +0200 (MEST) Received: (qmail 3656 invoked by uid 0); 24 Sep 2000 20:03:05 -0000 Received: from fl.egroups.com (208.50.144.74) by mx12.rz2.gmx.net with SMTP; 24 Sep 2000 20:03:05 -0000 X-eGroups-Return: sentto-1101623-816-969825810-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 24 Sep 2000 20:03:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 20:03:30 -0000 Received: (qmail 10070 invoked from network); 24 Sep 2000 20:03:30 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 24 Sep 2000 20:03:30 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 24 Sep 2000 20:03:30 -0000 Received: from f-cpu.org (nas1-195.aub.club-internet.fr [195.36.150.195]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA16157 for ; Sun, 24 Sep 2000 22:03:27 +0200 (MET DST) Message-ID: <39CE5F12.816B0EFB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39CE423A.DFD02155@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 21:07:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5d6090215af1e0552f15a6a74819b486 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi again,

Yann Guidon wrote:
> hi,
>
> so i tried to setup/compile PICA but it wouldn't extract
> from the archive. it's so sad. So i started reading Electric's
> manual :-)

finally i got it working, my dos box fucked up the file.
i had to d/l from telnet on another Unix server and retrieve
the file through bin ftp. file size must be 611286 bytes.

For those who have problems like that, i might mirror the file
on a more recent and better configured server ;-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Yann Guidon Sun Sep 24 22:06:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00328 for ; Mon, 25 Sep 2000 16:47:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:54 +0200 (MEST) Received: (qmail 6135 invoked by uid 0); 24 Sep 2000 20:04:36 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 24 Sep 2000 20:04:36 -0000 X-eGroups-Return: sentto-1101623-815-969825810-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 24 Sep 2000 20:03:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 20:03:30 -0000 Received: (qmail 10062 invoked from network); 24 Sep 2000 20:03:29 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 24 Sep 2000 20:03:29 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 24 Sep 2000 20:03:29 -0000 Received: from f-cpu.org (nas1-195.aub.club-internet.fr [195.36.150.195]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10531 for ; Sun, 24 Sep 2000 22:03:27 +0200 (MET DST) Message-ID: <39CE5EDE.17D8BFB3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CD5C66.5CE450BF@f-cpu.org> <20000924153952.46294@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 21:06:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 59758492fe98bff2c4d8fcd0cbf45b04 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> On Sun, Sep 24, 2000 at 02:44:06AM +0100, Yann Guidon wrote:
> > hmm, that's a pretty curious change of mind. could you write a li= ttle
> > testbench for this too ? can you also elaborate on the general al= gorithm
> > and the modus operandi ? we'll keep the simplest and easiest of b= oth
> > options, but i presume that in the end, representing the same dat= a in different
> > ways won't yield much win. the discussion about the entropy of LR= U is open :-)
>
> It's not a change of mind -- just another viewpoint :)

no i remember that i had a similar POV before we studied the first Riepe's = algo.
but it was a bit more sophisticated.

> The biggest win is that there is no stage-to-stage signal propagation<= BR> > delay; the `carry chain' is broken.
OTOH, the carry chain is broken on my design. And if you worry about the pr= opagation
time and the line length, i know other topologies that can highly reduce th= em.
they will even become necessary/mandatory for 256 cache lines.

>  On the other hand, we also lose:
> the magnitude (P>Q) comparators are more complex than simple xor-no= r
> `P=3DQ' style ones, and we need synchronous binary counters.  The= re's also
> a high load on the reference bus.  There ain't no such thing as a= perfect
> design. *sigh*

yep. But i prefer to stick with what i've already done, for several reasons= :
1) we know that it will be abandonned one day
2) less complex, finer granularity (you pointed the comparators etc)
3) less load and less surface.

Of course, because the design is modular, nothing forces you to follow me,<= BR> the initial goal being to have working and simulated VHDL of a reference pl= atform.
the actual implementation will probably differ a lot.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Nicolas Boulay Sun Sep 24 23:30:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00342 for ; Mon, 25 Sep 2000 16:47:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:47:57 +0200 (MEST) Received: (qmail 5936 invoked by uid 0); 24 Sep 2000 21:27:05 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 24 Sep 2000 21:27:05 -0000 X-eGroups-Return: sentto-1101623-817-969830820-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 24 Sep 2000 21:27:09 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 21:26:59 -0000 Received: (qmail 23258 invoked from network); 24 Sep 2000 21:26:59 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 24 Sep 2000 21:26:59 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta1 with SMTP; 24 Sep 2000 21:26:59 -0000 Received: from 194.158.111.50 [194.158.111.50] by lh04.opsion.fr; Sun, 24 Sep 2000 21:24:19 GMT Message-ID: <39CE726A.CB13209B@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <00092214555403.00382@gandalf> <39CE335A.81492E33@llandre.freeserve.co.uk> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 23:30:18 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] logic optimization (was: schematics) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4c6ea6124f532f95db02a3661679aaf8 Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

For an ASIC design, it's depend on the librairy but you can have more
than 600 differents cells. On a fpga (xilinx), a clb is composed by some PAL and a flip-flop, plus some more gate to speed up add operation or
multiply.

root a =E9crit :
>
>
> Jecel Assumpcao Jr wrote:
>
> >
> > On Fri, 22 Sep 2000, Jeff Davies wrote:
> >
> >
> > Very true, but in that case you might as well draw it as a simple= box
> > marked as "full adder" and be done with it (both progra= ms you mentioned
> > should have this in their library, I would expect).
> >
> > -- Jecel
>
> Yes, you are in the right. You can just put a core of a CPU in as well= . I was
> jstu saying that
> (excuse me if I am wrong), different empirical gate designs are used i= n
> different technologies.
> EG: the CLB in an FPGA (which I think can be any of OR,AND,NAND,NOR), = whereas as
> ASIC
> might be NAND based, or other (I am not up on this kind of thing). The= refore I
> beleive it would be
> best to draw your circuit how you can understand it & then optimis= e the boolean
> expression to
> whatever technology you are mapping to, rather than jumping straight i= n at the
> optimised level.
>
> Jeff Davies

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Michael Riepe Sun Sep 24 23:46:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00351 for ; Mon, 25 Sep 2000 16:48:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:48:00 +0200 (MEST) Received: (qmail 21182 invoked by uid 0); 24 Sep 2000 21:48:18 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 24 Sep 2000 21:48:18 -0000 X-eGroups-Return: sentto-1101623-818-969831972-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 24 Sep 2000 21:46:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 21:46:12 -0000 Received: (qmail 9117 invoked from network); 24 Sep 2000 21:46:12 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 24 Sep 2000 21:46:12 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.250) by mta2 with SMTP; 24 Sep 2000 21:46:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02213; Sun, 24 Sep 2000 23:46:18 +0200 Message-ID: <20000924234617.17698@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39C8902D.6B5E5640@f-cpu.org> <20000920152545.17890@thrai.stud.uni-hannover.de> <39C91D20.751BFD9B@f-cpu.org> <20000921003204.26719@thrai.stud.uni-hannover.de> <20000922190525.59439@thrai.stud.uni-hannover.de> <39CCDCD3.A7A3350B@f-cpu.org> <20000924011715.18393@thrai.stud.uni-hannover.de> <39CDDD3A.1A3DB106@ifrance.com> <39CE5EE0.3DA4D08F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CE5EE0.3DA4D08F@f-cpu.org>; from Yann Guidon on Sun, Sep 24, 2000 at 09:06:56PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 23:46:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache : gated clock Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ea94cb689aaaf884cfb7a94124e070cf Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sun, Sep 24, 2000 at 09:06:56PM +0100, Yann Guidon wrote:
>
> hi !
>
> Nicolas Boulay wrote:
> > One year or 2 ago, in a synchronous design, it was definitely and
> > absolutely forbiden to make gated clock. Because of the skew, and that
> > the cad tools could't manage this, todays and because of danger of
> > spike. Nowdays, you could do that BUT for low power purpose only.
>
> so what do you propose ? an "enable" input ? What ? the multiplexor
> is rather heavy...

Use JK-FFs instead of D-FFs :) One input of the mux is connected to
the output of the FF anyway, we only have to add 2 AND gates (or make
2 ANDed J and K inputs) per FF.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sun Sep 24 23:51:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00354 for ; Mon, 25 Sep 2000 16:48:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:48:01 +0200 (MEST) Received: (qmail 21251 invoked by uid 0); 24 Sep 2000 21:51:46 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 24 Sep 2000 21:51:46 -0000 X-eGroups-Return: sentto-1101623-819-969832299-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 24 Sep 2000 21:51:44 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 21:51:39 -0000 Received: (qmail 20983 invoked from network); 24 Sep 2000 21:51:39 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 24 Sep 2000 21:51:39 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.250) by mta1 with SMTP; 24 Sep 2000 21:51:37 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02231; Sun, 24 Sep 2000 23:51:45 +0200 Message-ID: <20000924235145.26634@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CE5EFD.81686A55@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CE5EFD.81686A55@f-cpu.org>; from Yann Guidon on Sun, Sep 24, 2000 at 09:07:25PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 23:51:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 08a65f4df249c4d9f016c6b76cba79d3 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sun, Sep 24, 2000 at 09:07:25PM +0100, Yann Guidon wrote:

> Now i remember what my first (ever) idea was : in order to avoid the
> decrementation of ALL the elements, i made the contrary :
> i compared the elements with a "cyclic trigger". but this never worked
> and i had cases where two lines had the same value, so we could not distinguish
> which line was the LRU. I see that Michael solved the problem.
>
> Now, what would it give if he adapted his algo with the cyclic trigger ?
> that means that we need 2 buses, and LRU is when trigger=value.
> When we use a line, it is set as trigger-1. no decrementation !!!
> but we can't avoid the comparison... and this is still rather complex.

We only need simple P=Q comparators in that case.  Sounds like another
good idea... gotta sleep on that.

> instead of -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-
> we can do
>  -0-0-0-0-0-0-0-0\
>  /0-0-0-0-0-0-0-0/
>  \0-0-0-0-0-0-0-0\
>  /0-0-0-0-0-0-0-0/
>  \0-0-0-0-0-0-0-0\
>   0-0-0-0-0-0-0-0/
> or fold in a "fractal" way (self-similar, easier to route).

Why not write our names into the design?  Just kidding, a hilbert
curve would do :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sun Sep 24 23:57:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00362 for ; Mon, 25 Sep 2000 16:48:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:48:02 +0200 (MEST) Received: (qmail 7683 invoked by uid 0); 24 Sep 2000 21:57:24 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 24 Sep 2000 21:57:24 -0000 X-eGroups-Return: sentto-1101623-820-969832635-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 24 Sep 2000 21:57:22 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 21:57:15 -0000 Received: (qmail 31752 invoked from network); 24 Sep 2000 21:57:14 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 24 Sep 2000 21:57:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.250) by mta3 with SMTP; 24 Sep 2000 21:57:13 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02251; Sun, 24 Sep 2000 23:57:10 +0200 Message-ID: <20000924235710.11118@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CD5C66.5CE450BF@f-cpu.org> <20000924153952.46294@thrai.stud.uni-hannover.de> <39CE5EDE.17D8BFB3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CE5EDE.17D8BFB3@f-cpu.org>; from Yann Guidon on Sun, Sep 24, 2000 at 09:06:54PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Sep 2000 23:57:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 908f09f99c58b9d1ba6f7c440966a686 Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Sun, Sep 24, 2000 at 09:06:54PM +0100, Yann Guidon wrote:

> yep. But i prefer to stick with what i've already done, for several reasons :
> 1) we know that it will be abandonned one day
> 2) less complex, finer granularity (you pointed the comparators etc)
> 3) less load and less surface.

Agreed. 3 times.

> Of course, because the design is modular, nothing forces you to follow me,
> the initial goal being to have working and simulated VHDL of a reference platform.
> the actual implementation will probably differ a lot.

Having alternatives to try if something goes wrong is still a
Good Thing (tm).  And I like playing with problems like this :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Mon Sep 25 02:18:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00368 for ; Mon, 25 Sep 2000 16:48:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Sep 2000 16:48:05 +0200 (MEST) Received: (qmail 3978 invoked by uid 0); 24 Sep 2000 23:14:22 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 24 Sep 2000 23:14:22 -0000 X-eGroups-Return: sentto-1101623-821-969837254-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 24 Sep 2000 23:14:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 24 Sep 2000 23:14:14 -0000 Received: (qmail 28107 invoked from network); 24 Sep 2000 23:14:14 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 24 Sep 2000 23:14:14 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 24 Sep 2000 23:14:13 -0000 Received: from f-cpu.org (nas1-182.ras.club-internet.fr [195.36.192.182]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA15191 for ; Mon, 25 Sep 2000 01:14:10 +0200 (MET DST) Message-ID: <39CE99D7.3F20A933@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CD5C66.5CE450BF@f-cpu.org> <20000924153952.46294@thrai.stud.uni-hannover.de> <39CE5EDE.17D8BFB3@f-cpu.org> <20000924235710.11118@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 25 Sep 2000 01:18:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 680e648c5c147fd60027ecf37e20b81b Status: R X-Status: N
3D""
=3D"eGroups" My Groups | f-cpu Main Page

hi !

Michael Riepe wrote:
> On Sun, Sep 24, 2000 at 09:06:54PM +0100, Yann Guidon wrote:
> > yep. But i prefer to stick with what i've already done, for sever= al reasons :
> > 1) we know that it will be abandonned one day
> > 2) less complex, finer granularity (you pointed the comparators e= tc)
> > 3) less load and less surface.
> Agreed. 3 times.

ok so let's go :-)

i got a working version of PICA.

> > Of course, because the design is modular, nothing forces you to f= ollow me,
> > the initial goal being to have working and simulated VHDL of a re= ference platform.
> > the actual implementation will probably differ a lot.
> Having alternatives to try if something goes wrong is still a
> Good Thing (tm).  And I like playing with problems like this :) i agree twice ;-)

> > Now i remember what my first (ever) idea was : in order to avoid = the
> > decrementation of ALL the elements, i made the contrary :
> > i compared the elements with a "cyclic trigger". but th= is never worked
> > and i had cases where two lines had the same value, so we could n= ot distinguish
> > which line was the LRU. I see that Michael solved the problem. > >
> > Now, what would it give if he adapted his algo with the cyclic tr= igger ?
> > that means that we need 2 buses, and LRU is when trigger=3Dvalue.=
> > When we use a line, it is set as trigger-1. no decrementation !!!=
> > but we can't avoid the comparison... and this is still rather com= plex.
> We only need simple P=3DQ comparators in that case.  Sounds like = another
> good idea... gotta sleep on that.

you won't sleep with that : it's heavy because you can update only one part=
of the lines. this means that you must compare against 2 values, between th= e
trigger and the current line's values, and handle the overflows...

> > instead of -0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0= -0-0-0-0-0-0-0-0-0-0-
> > we can do
> >  -0-0-0-0-0-0-0-0\
> >  /0-0-0-0-0-0-0-0/
> >  \0-0-0-0-0-0-0-0\
> >  /0-0-0-0-0-0-0-0/
> >  \0-0-0-0-0-0-0-0\
> >   0-0-0-0-0-0-0-0/
> > or fold in a "fractal" way (self-similar, easier to rou= te).
>
> Why not write our names into the design?  Just kidding, a hilbert=
> curve would do :)

i remember that i wrote a silly post on comp.dsp about the "Dhilbert t= ransform",
saying that if something is silly, it will get even worse. curiously this t= ransform
is not reversible ;-)

As for our names, well, our pride and active efforts do most of the work ;-= )

ok, now, the "fractal" cache line :

take a single "sector" of 4 tag lines : 0-0-0-0
with a '0' for each FF of the shift register.
it can be folded to
  0---0
  | X |
  0 | 0

with X as a clock and data buffer, as well
as the carry logic in the center.

This pattern can be applied on itself easily :

  0---0  0---0
  | X |  | X |
>-0 | 0--0 | 0
    |      | |
----X------+ |
    |      | |
<-0 | 0--0 | 0
  | X |  | X |
  0---0  0---0

(16 cache lines)

and so on :

   0---0---0---0   0---0---0---0
   | X=3D=3D=3D+=3D=3D=3DX |   | X=3D=3D=3D+=3D=3D=3DX = |
   0---0 | 0---0   0---0 | 0---0
       | X |=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D| = X |
   0---0 | 0---0 | 0---0 | 0---0
   | X=3D=3D=3D+=3D=3D=3DX | | | X=3D=3D=3D+=3D=3D=3DX |
   0---0---0<* 0---0   0---0---0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DX    = ; |
   0---0---0>* 0---0   0---0---0
   | X=3D=3D=3D+=3D=3D=3DX | | | X=3D=3D=3D+=3D=3D=3DX |
   0---0 | 0---0 | 0---0 | 0---0
       | X |=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D| = X |
   0---0 | 0---0   0---0 | 0---0
   | X=3D=3D=3D+=3D=3D=3DX |   | X=3D=3D=3D+=3D=3D=3DX = |
   0---0---0---0   0---0---0---0

(64 lines)

remark that i didn't invent anything, it's similar to what the CAM-8 implem= ents.
The recursive program that can generate such a drawing
is also the kind of things that is taught in schools to learn
how recursive langages work :-)
This is definitely an organisation to promote for a silicon/ASIC version.
> > Nicolas Boulay wrote:
> > > One year or 2 ago, in a synchronous design, it was definitel= y and
> > > absolutely forbiden to make gated clock. Because of the skew= , and that
> > > the cad tools could't manage this, todays and because of dan= ger of
> > > spike. Nowdays, you could do that BUT for low power purpose = only.
> > so what do you propose ? an "enable" input ? What ? the= multiplexor
> > is rather heavy...
> Use JK-FFs instead of D-FFs :) One input of the mux is connected to > the output of the FF anyway, we only have to add 2 AND gates (or make<= BR> > 2 ANDed J and K inputs) per FF.

hummm... something like that is pretty smart :-)
but as we dig deeper in the technology, we might end up
with something too much specialized.

good night :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
 From Michael Riepe Mon Sep 25 02:22:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00453 for ; Wed, 27 Sep 2000 16:45:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:45:30 +0200 (MEST) Received: (qmail 28910 invoked by uid 0); 25 Sep 2000 16:36:48 -0000 Received: from jj.egroups.com (208.50.144.82) by mx12.rz2.gmx.net with SMTP; 25 Sep 2000 16:36:48 -0000 X-eGroups-Return: sentto-1101623-823-969899822-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 25 Sep 2000 16:37:04 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 25 Sep 2000 16:37:01 -0000 Received: (qmail 19382 invoked from network); 25 Sep 2000 16:37:01 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 25 Sep 2000 16:37:01 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.226) by mta1 with SMTP; 25 Sep 2000 16:36:56 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02649; Mon, 25 Sep 2000 02:22:11 +0200 Message-ID: <20000925022211.31508@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20000924010351.64499@thrai.stud.uni-hannover.de> <39CD5C66.5CE450BF@f-cpu.org> <20000924153952.46294@thrai.stud.uni-hannover.de> <39CE5EDE.17D8BFB3@f-cpu.org> <20000924235710.11118@thrai.stud.uni-hannover.de> <39CE99D7.3F20A933@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39CE99D7.3F20A933@f-cpu.org>; from Yann Guidon on Mon, Sep 25, 2000 at 01:18:31AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 25 Sep 2000 02:22:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] LRU proposal #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a8fa033f0c92d283811134b11db0d8cf Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

On Mon, Sep 25, 2000 at 01:18:31AM +0100, Yann Guidon wrote:
[...]
> > > Now, what would it give if he adapted his algo with the cyclic trigger ?
> > > that means that we need 2 buses, and LRU is when trigger=value.
> > > When we use a line, it is set as trigger-1. no decrementation !!!
> > > but we can't avoid the comparison... and this is still rather complex.
> > We only need simple P=Q comparators in that case.  Sounds like another
> > good idea... gotta sleep on that.
>
> you won't sleep with that : it's heavy because you can update only one part
> of the lines. this means that you must compare against 2 values, between the
> trigger and the current line's values, and handle the overflows...

Let me think it over.  I also thought that something like my second
version would be impossible...

[fractals]
> This pattern can be applied on itself easily :
>
>   0---0  0---0
>   | X |  | X |
> >-0 | 0--0 | 0
>     |      | |
> ----X------+ |
>     |      | |
> <-0 | 0--0 | 0
>   | X |  | X |
>   0---0  0---0

This is similar to a hilbert curve:

  ->0   0---0---0
    | X |     X |
    0---0   0---0
            |
    0---0   0---0
    | X |     X |
  <-0   0---0---0

> remark that i didn't invent anything, it's similar to what the CAM-8 implements.
> The recursive program that can generate such a drawing
> is also the kind of things that is taught in schools to learn
> how recursive langages work :-)

I remember a Turbo Pascal program I wrote... more than 10 years ago.
But I like my PostScript version better :)

> This is definitely an organisation to promote for a silicon/ASIC version.

Isn't that boring?  I agree once more :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Nicolas Boulay Mon Sep 25 19:50:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00463 for ; Wed, 27 Sep 2000 16:45:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:45:34 +0200 (MEST) Received: (qmail 28373 invoked by uid 0); 25 Sep 2000 17:46:46 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 25 Sep 2000 17:46:46 -0000 X-eGroups-Return: sentto-1101623-824-969903994-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 25 Sep 2000 17:46:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 25 Sep 2000 17:46:33 -0000 Received: (qmail 3889 invoked from network); 25 Sep 2000 17:46:33 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 25 Sep 2000 17:46:33 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 25 Sep 2000 17:46:33 -0000 Received: from 195.36.163.229 [195.36.163.229] by lh00.opsion.fr; Mon, 25 Sep 2000 17:44:19 GMT Message-ID: <39CF9063.51E2877D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39CED4FE.67E4AA97@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 25 Sep 2000 19:50:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] clock validation Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f13471ad8e4c85bb8018da11593a12f8 Status: R X-Status: N
=3D"eGroups" My Groups | f-cpu Main Page



Yann Guidon a =E9crit :
>
>
> Hi !
>
> re: nico's remark,
>
> i read in his own book that some ASIC cells have a clock enable signal= .
> it even gives some VHDL on page 111 :
>
> entity REG_VAL_CLK is
>   port (
>     CLK, VAL : in bit;
>     D : in bit_vector(7 downto 0);
>     Q : out bit_vector(7 downto 0));
> end REG_VAL_CLK;
>
> architecture ArchCLK of REG_VAL_CLK is
> begin
>   process (CLK, VAL)
>   begin
>     if (CLK'event and CLK =3D '1') then
>       if VAL=3D'1' then
>         Q<=3DD;
>       end if;
>     end if;
>   end process;
> end ArchCLK;
>
> So, what was the trouble ? :-)
>

Maybe i haven't understood what you want to do. This case aren't about
clock gating. I had understood that you want to switch a clock signal.
And this signals is then reused as clock signal. This could make some
delay in the clock and make pb with the 2 domains.

i believed i must read more your mail ! Sorry.
nicO

> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Moi qui pensait que dans le libre y avait pas trop de cyber-neun= eus."
>  F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con= )

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Nicolas Boulay Mon Sep 25 19:51:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00467 for ; Wed, 27 Sep 2000 16:45:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:45:35 +0200 (MEST) Received: (qmail 10501 invoked by uid 0); 25 Sep 2000 17:50:09 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 25 Sep 2000 17:50:09 -0000 X-eGroups-Return: sentto-1101623-825-969904189-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 25 Sep 2000 17:49:56 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 25 Sep 2000 17:49:49 -0000 Received: (qmail 10553 invoked from network); 25 Sep 2000 17:48:08 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 25 Sep 2000 17:48:08 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 25 Sep 2000 17:48:08 -0000 Received: from 195.36.163.229 [195.36.163.229] by lh00.opsion.fr; Mon, 25 Sep 2000 17:45:48 GMT Message-ID: <39CF90BD.96327337@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39CED4FE.67E4AA97@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 25 Sep 2000 19:51:57 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] clock validation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 4b2275afc50955263d3b96e16a0c759c Status: R X-Status: N -------------------------- eGroups Sponsor -------------------------~-~> Thousands of Great Jobs, One Great Location! Austinatwork.com. Great Jobs, Great Life! http://click.egroups.com/1/7847/15/_/3462/_/969904189/ ---------------------------------------------------------------------_-> I send you the answer of the principal maintener of the leon about licence. Nicolas Boulay wrote: > But it didn't say if you should pay a fee to Sun or Sparc, if you want > to sell some Leons. And what exactly means the 99$ fees ? > nicO Back in 1997, Sparc International required a one-time license fee of $99 to allow you to design a processor according the SPARC manual. I did indeed purchase this license, so LEON was legally developed. The architecture license has now been abolished, and designing SPARC processors can be done without any licenses what so ever. This is indeed why I have selected SPARC, just see how many times Intel, MIPS and ARM has sued companies that developed processors using their architecture. Jiri. --------------------------------------------------------------------- Jiri Gaisler, ESA/ESTEC, Box 299, 2200 AG Noordwijk, the Netherlands email: jgais@ws.estec.esa.nl voice:+31-71-5654880 fax:+31-71-5654295 ERC32 home page at http://www.estec.esa.nl/wsmwww/erc32 ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif From Kai Wetzel Tue Sep 26 00:09:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00473 for ; Wed, 27 Sep 2000 16:45:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:45:36 +0200 (MEST) Received: (qmail 6887 invoked by uid 0); 25 Sep 2000 20:12:28 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 25 Sep 2000 20:12:28 -0000 X-eGroups-Return: sentto-1101623-826-969912717-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 25 Sep 2000 20:12:18 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_2); 25 Sep 2000 20:11:57 -0000 Received: (qmail 2914 invoked from network); 25 Sep 2000 20:11:57 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 25 Sep 2000 20:11:57 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta2 with SMTP; 25 Sep 2000 20:11:56 -0000 Received: from welfen-netz.com [193.194.149.164] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Mon, 25 Sep 2000 22:09:58 +0200 Sender: kai@pop.gmx.net Message-ID: <39CFCD0E.59331084@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39CE423A.DFD02155@f-cpu.org> <39CE5F12.816B0EFB@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 00:09:18 +0200 Reply-To: f-cpu@egroups.com Subject: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 36d91c01d256cabe6b39d691a029fb9a Status: R X-Status: N
eGroups My Groups | f-cpu Main Page

Hi,

as the topic of EDA tools comes up, what are your opinions
on the Mentor Graphics tools, in particular IC Station,
Design Architect - IC, and AccuSimII ?  Are they any good and
is IC Station more "user friendly" then Electric's layout module ?
Do you know of Free tools which try to match up with
the Mentor Graphics suite, especially IC Station ?

(I was skimming through a book about V8 a while ago and it seemed
pretty neat, but maybe it's just advertisement.  Since
I don't have access to this tool I can't tell, unfortunately)

kai

 From Rainer Dorsch Tue Sep 26 11:09:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00560 for ; Wed, 27 Sep 2000 16:46:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:14 +0200 (MEST) Received: (qmail 19557 invoked by uid 0); 26 Sep 2000 09:09:35 -0000 Received: from c3.egroups.com (208.50.99.225) by mx19.rz2.gmx.net with SMTP; 26 Sep 2000 09:09:35 -0000 X-eGroups-Return: sentto-1101623-827-969959356-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 26 Sep 2000 09:09:32 -0000 X-Sender: rainer@rai16.informatik.uni-stuttgart.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 09:09:15 -0000 Received: (qmail 31470 invoked from network); 26 Sep 2000 09:09:15 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 26 Sep 2000 09:09:15 -0000 Received: from unknown (HELO ifi.informatik.uni-stuttgart.de) (129.69.211.1) by mta2 with SMTP; 26 Sep 2000 09:09:14 -0000 Received: from rai16.informatik.uni-stuttgart.de (rai16 [129.69.183.16]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id LAA04626 for ; Tue, 26 Sep 2000 11:07:33 +0200 (MET DST) Received: from rai16.informatik.uni-stuttgart.de (localhost [127.0.0.1]) by rai16.informatik.uni-stuttgart.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA02896 for ; Tue, 26 Sep 2000 11:09:12 +0200 Message-Id: <200009260909.LAA02896@rai16.informatik.uni-stuttgart.de> X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: f-cpu@egroups.com In-Reply-To: Your message of "Tue, 26 Sep 2000 00:09:18 +0200." <39CFCD0E.59331084@welfen-netz.com> X-eGroups-From: Rainer Dorsch From: Rainer Dorsch MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 11:09:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e1301d78c582f35c6662133b050a9e8 Status: R X-Status: N
The good thing with IC station is that it is the only commercial tool so far
running on Linux. I am not sure, if Alliance was already discussed:

+ free (GPL)
+ stable
+ good documentation
- not FPGA backend supported
- no support for state of the art tool kits

That implies that work on the tool itself is needed.

Rainer.

> Hi,
>
> as the topic of EDA tools comes up, what are your opinions
> on the Mentor Graphics tools, in particular IC Station,
> Design Architect - IC, and AccuSimII ?  Are they any good and
> is IC Station more "user friendly" then Electric's layout module ?
> Do you know of Free tools which try to match up with
> the Mentor Graphics suite, especially IC Station ?
>
> (I was skimming through a book about V8 a while ago and it seemed
> pretty neat, but maybe it's just advertisement.  Since
> I don't have access to this tool I can't tell, unfortunately)
>
> kai
>
>
>
>



eGroups Sponsor
From "Toyoaki Sagawa" Tue Sep 26 17:24:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00623 for ; Wed, 27 Sep 2000 16:46:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:38 +0200 (MEST) Received: (qmail 7937 invoked by uid 0); 26 Sep 2000 15:26:15 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 26 Sep 2000 15:26:15 -0000 X-eGroups-Return: sentto-1101623-831-969981879-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 26 Sep 2000 15:25:04 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 15:24:38 -0000 Received: (qmail 22491 invoked from network); 26 Sep 2000 15:24:38 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 26 Sep 2000 15:24:38 -0000 Received: from unknown (HELO mail158.nifty.com) (202.248.37.150) by mta3 with SMTP; 26 Sep 2000 15:24:37 -0000 Received: from cfb5 by mail158.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id AAA03592 for ; Wed, 27 Sep 2000 00:24:36 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 00:24:51 +0900 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f26bc540f86763db85b5649c02894c28 Status: R X-Status: N
Hi, I'm new comer here.
This is my tempolary output "Sayuri" , It's very simple CPU.
I hope your response, about it has some value or not.

http://www.morphyplanning.co.jp/FreeCPU/freecpu-e.html

Toyoaki Sagawa

 From Kai Wetzel Tue Sep 26 18:57:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00626 for ; Wed, 27 Sep 2000 16:46:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:38 +0200 (MEST) Received: (qmail 5460 invoked by uid 0); 26 Sep 2000 16:03:56 -0000 Received: from fh.egroups.com (208.50.144.71) by mx06.rz2.gmx.net with SMTP; 26 Sep 2000 16:03:56 -0000 X-eGroups-Return: sentto-1101623-832-969984290-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 26 Sep 2000 16:05:07 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 16:04:48 -0000 Received: (qmail 19588 invoked from network); 26 Sep 2000 16:03:08 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 26 Sep 2000 16:03:08 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 26 Sep 2000 16:03:07 -0000 Received: from welfen-netz.com [213.6.144.106] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 26 Sep 2000 18:01:49 +0200 Sender: kai@pop.gmx.net Message-ID: <39D0D591.D76364A0@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200009261407.OAA09871@dichlore.mime.univ-paris8.fr> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 18:57:53 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e96f10e74535765f92bfbb8ea95ec60c Status: R X-Status: N Yann Guidon wrote:
>
> Hello
>
> I am really getting DESPERATED by the lack of real good GNU EDA tool.<= BR>
Yes, it's sad.

> I have tried everything i could download, from the links
> at the opencollector.org database but in the end i'm disapointed.

Would some people here be interested in opening a project
to create an application in the fashion of the Design
Architect-IC/IC-Station tools ?  Together with Camille
(if it makes progress) and various back-end Software around, this
could become a useful suite, no ?  Maybe this could put some lurkers <= BR> >from the software side (like me) to good use :=B0>

> I personally have a good feeling for some Mentor SW. i have a demo CD<= BR> > (not used) with some presentations and limited-time trial.

Can this CD be ordered from their website ?  I've only seen the
still images and descriptions in the book, so I'd love to see it in
action.

I was very impressed by Mentor's hierarchical approach, switching
between detailed layout and structural things pretty easily
(so it seems).  And I got the impresion that VHDL based design could intermix _comfortably_ with "direct layout", unlike in some other= tools.

> i think there is Renoir etc. and it's impressing.
>
> I have tried to use PICA. It could only compile on 1 of the 4 platform= s
> i tried : x86/FreeBSD works, but not on Sun, SGI and Linux.
> it doesn't seem to be much bugged but it's old and the VHDL is a bit s= trange.
> it's not "interactive" but would do the job, if it was more = portable.
> At least i tried.
>
> I also tried Electric. Compiles fine under SuSE Linux, rather well
> under SUN but SGI refuses (cpp is fucked up there) and FreeBSD's make<= BR> > utility does not compile the project. The problem is that the SUN is u= sed
> as a server and is accessed through the network, so the display is ...= slow...
> Anyway it's probably the last solution at our level. it's a "real= GNU" tool,
> available from gnu.org and its mirors, it's professionnal and seems no= t to
> be out of breath. if you can install it, read the manual and go forwar= d.

Though Electric looks fine in principle, I found it pretty tough to get a few gates (respectively transistors) in with the layout view (CMOS librar= y).
"Switching" between schematics and layout was even worse.  V= isual cues about
placement conflicts are provided but pretty simple.
The whole thing felt like cutting raw meat with a spoon (so to say).
The display is slow indeed (though it was in an acceptable range on
local display).  I can hardly image to layout a microprocessor with ultimately several millions of transistors with it.

> Alliance will be the only solution for the synthesis, i fear. If we ev= er need
> to synthetise anything at all (companies can do this tough task on a c= ase
> per case basis for their own use). It's far from being perfect but it'= s necessary
> at a certain point.
>
> What we need is something compact, portable, GNU and working good, for=
> compiling and simulating usual VHDL constructs. we don't need somethin= g
> sophisticated but that does his job easily and nicely. I want to write= VHDL,
> at last...

What do you have against Verilog ?  From a beginner's point of view it=
looked significantly easier to understand then VHDL, no ?  Or is Veril= og not
as flexible and powerful as VHDL ?

Regards,
kai



 From Nicolas Boulay Tue Sep 26 19:09:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00629 for ; Wed, 27 Sep 2000 16:46:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:40 +0200 (MEST) Received: (qmail 1587 invoked by uid 0); 26 Sep 2000 17:05:12 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 26 Sep 2000 17:05:12 -0000 X-eGroups-Return: sentto-1101623-833-969987907-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 26 Sep 2000 17:05:10 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 17:05:07 -0000 Received: (qmail 25219 invoked from network); 26 Sep 2000 17:05:07 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 26 Sep 2000 17:05:07 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 26 Sep 2000 17:05:06 -0000 Received: from 195.36.171.19 [195.36.171.19] by lh00.opsion.fr; Tue, 26 Sep 2000 17:02:44 GMT Message-ID: <39D0D82E.45E9AD03@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <200009261407.OAA09871@dichlore.mime.univ-paris8.fr> <39D0D591.D76364A0@welfen-netz.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 19:09:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 11e5d00a245e77a4728bfe5b963e6cdb Status: R X-Status: N

Kai Wetzel a =E9crit :
>
> Yann Guidon wrote:
> >
> > Hello
> >
> > I am really getting DESPERATED by the lack of real good GNU EDA t= ool.
>
> Yes, it's sad.
>

THE CAD synthetis tools is Synopsys. This is the only one for 80% of the compagny in the world.

Beside that do we really need a synthetis tools, nowadays ? Nowadays
there no line of vhdl for the fcpu. Leon team has just written [good ?]
vhdl code. If you want to synthetis it, you could used tools in
university or ask cad compagnies. Befor that you need the rtl CODE !
This should pass all the rtl simulation. Yes, the code should be
synthetisable but we are far from that !

Another question is what do we want to release ? Vhdl code is evident.
But if want to synthetise it you should target a specific technologie.
It's good to have a prototype. But you couldn't release the library
given by foundary.(because of the None Disclosure Agrement).

So now we need GPL VHDL simulator. Just, some thing wich compile and
draw lines. I was very surprise to see that it doesn't existe !! You
could find compilator for lot of very strange language but not for VHDL
! One of my ex-professor said that there is a gap between electrical and computer science engineers. I know that a lot of vhdl front-end has been written for formal proofing tools.

I sugest to push universities to develop a vhdl simulator, i'm sure that some of phd could do the work (because of the concurrencies, a vhdl
compiler should be a little bit more complicated compare to C one).
Maybe one days a gcc for vhdl will exist !

nicO

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Rainer Dorsch Tue Sep 26 19:13:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00632 for ; Wed, 27 Sep 2000 16:46:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:40 +0200 (MEST) Received: (qmail 29844 invoked by uid 0); 26 Sep 2000 17:13:24 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 26 Sep 2000 17:13:24 -0000 X-eGroups-Return: sentto-1101623-834-969988423-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 26 Sep 2000 17:14:12 -0000 X-Sender: rainer@rai16.informatik.uni-stuttgart.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 17:13:42 -0000 Received: (qmail 19488 invoked from network); 26 Sep 2000 17:13:41 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 26 Sep 2000 17:13:41 -0000 Received: from unknown (HELO ifi.informatik.uni-stuttgart.de) (129.69.211.1) by mta3 with SMTP; 26 Sep 2000 17:13:41 -0000 Received: from rai16.informatik.uni-stuttgart.de (rai16 [129.69.183.16]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id TAA13471 for ; Tue, 26 Sep 2000 19:12:01 +0200 (MET DST) Received: from rai16.informatik.uni-stuttgart.de (localhost [127.0.0.1]) by rai16.informatik.uni-stuttgart.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA05854 for ; Tue, 26 Sep 2000 19:13:38 +0200 Message-Id: <200009261713.TAA05854@rai16.informatik.uni-stuttgart.de> X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: f-cpu@egroups.com In-Reply-To: Your message of "Tue, 26 Sep 2000 19:09:02 +0200." <39D0D82E.45E9AD03@ifrance.com> X-eGroups-From: Rainer Dorsch From: Rainer Dorsch MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 19:13:38 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ef41751001fa351553e6d2ce5dec419e Status: R X-Status: N >
> So now we need GPL VHDL simulator. Just, some thing wich compile and
> draw lines. I was very surprise to see that it doesn't existe !! You

http://www.freehdl.seul.org/

Rainer

 From Nicolas Boulay Tue Sep 26 19:26:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00635 for ; Wed, 27 Sep 2000 16:46:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:41 +0200 (MEST) Received: (qmail 20676 invoked by uid 0); 26 Sep 2000 17:24:06 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 26 Sep 2000 17:24:06 -0000 X-eGroups-Return: sentto-1101623-835-969989078-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 26 Sep 2000 17:25:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 17:24:37 -0000 Received: (qmail 19692 invoked from network); 26 Sep 2000 17:22:55 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 26 Sep 2000 17:22:55 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 26 Sep 2000 17:22:55 -0000 Received: from 195.36.171.19 [195.36.171.19] by lh00.opsion.fr; Tue, 26 Sep 2000 17:20:37 GMT Message-ID: <39D0DC60.8E1C5A93@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <200009261713.TAA05854@rai16.informatik.uni-stuttgart.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 19:26:56 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a5f78fa2d5d116bf0b8e87a7f4e5b6f9 Status: R X-Status: N I forgot this one, it's work ?

Rainer Dorsch a =E9crit :
>
> >
> > So now we need GPL VHDL simulator. Just, some thing wich compile = and
> > draw lines. I was very surprise to see that it doesn't existe !! = You
>
> http://www.freehdl.seul.org/<= /a>
>
> Rainer
>

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Kai Wetzel Tue Sep 26 21:38:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00638 for ; Wed, 27 Sep 2000 16:46:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:43 +0200 (MEST) Received: (qmail 27313 invoked by uid 0); 26 Sep 2000 17:40:47 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 26 Sep 2000 17:40:47 -0000 X-eGroups-Return: sentto-1101623-836-969990014-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ml.egroups.com with NNFMP; 26 Sep 2000 17:40:46 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 17:40:14 -0000 Received: (qmail 16400 invoked from network); 26 Sep 2000 17:39:31 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 26 Sep 2000 17:39:31 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 26 Sep 2000 17:39:30 -0000 Received: from welfen-netz.com [213.6.75.10] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 26 Sep 2000 19:38:50 +0200 Sender: kai@pop.gmx.net Message-ID: <39D0FB21.29933B5B@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20000915014954.EWVR27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 21:38:09 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 814960fc2637d017fd94bbc637194fdf Status: R X-Status: N A late reply ...

Albert Abramson wrote:
[...]
> Anyone who has ever implemented a processor, even a simple one, can tell you
> what's wrong with the current approach.  The real bottleneck on modern uP's
> is not logic, but wire, and the current f-cpu offers just too much.

Do you mean the FUs as such are too complicated or that there should
be fewer or do you mean the other aspects of FC0 ?

[...]
> A good VLIW design would allow us to break from the VHDL and just go
> straight to a hand designed, hand-tweaked mask.

For the record, this approach (hand-tweaked and simple) convinces me.
But as a software person I can't offer much to make the point
stronger, unfortunately.

> I do not believe in the current approach, because it creates bottlenecks
> even Intel does not have to deal with.  I have no plans to be part of
> something I am relatively confident will never perform.  I'm interested in
> Porsche, not Caravan.  It's upsetting to see that so many skilled
> individuals would be getting behind something has no chance of flying high.
[...]

kai
eGroups Sponsor
From Rainer Dorsch Tue Sep 26 19:50:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00641 for ; Wed, 27 Sep 2000 16:46:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:44 +0200 (MEST) Received: (qmail 15047 invoked by uid 0); 26 Sep 2000 17:51:14 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 26 Sep 2000 17:51:14 -0000 X-eGroups-Return: sentto-1101623-837-969990660-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 26 Sep 2000 17:51:11 -0000 X-Sender: rainer@rai16.informatik.uni-stuttgart.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 17:51:00 -0000 Received: (qmail 5696 invoked from network); 26 Sep 2000 17:50:59 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 26 Sep 2000 17:50:59 -0000 Received: from unknown (HELO ifi.informatik.uni-stuttgart.de) (129.69.211.1) by mta2 with SMTP; 26 Sep 2000 17:50:59 -0000 Received: from rai16.informatik.uni-stuttgart.de (rai16 [129.69.183.16]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id TAA14051 for ; Tue, 26 Sep 2000 19:49:19 +0200 (MET DST) Received: from rai16.informatik.uni-stuttgart.de (localhost [127.0.0.1]) by rai16.informatik.uni-stuttgart.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA06284 for ; Tue, 26 Sep 2000 19:50:57 +0200 Message-Id: <200009261750.TAA06284@rai16.informatik.uni-stuttgart.de> X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: f-cpu@egroups.com In-Reply-To: Your message of "Tue, 26 Sep 2000 19:26:56 +0200." <39D0DC60.8E1C5A93@ifrance.com> X-eGroups-From: Rainer Dorsch From: Rainer Dorsch MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 19:50:57 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7c8607e5a7f98d1f684d514a2e16ce04 Status: R X-Status: N
I did not try it myself, but the mailing list is not too active any more (given that the archive is working).

I just checked the Debian distribution and found

verilog - Icarus verilog compiler

The Icarus verilog compiler for the verilog hardware description language.<= BR> The compiler can target either VVM (Verilog Virtual Machine) for simulation=
or XNF (Xilinx Netlist Format).

savant - The University of Cincinnati's free VHDL 93 Analyzer

This is the analyzer and intermediate representation for a free VHDL
simulation system from the University of Cincinnati's Experimental
Computation Laboratory.  "scram", SAVANT's analyzer, convert= s VHDL into the
AIRE intermediate standard form. AIRE is designed to be extensible by the user so that they can easily insert their own back ends. SAVANT includes a<= BR> VHDLpublishing back end and a C++ publishing back end. The generated C++ can be compiled and linked against the TyVis library to allow end to end sequential or parallel simulation of VHDL.  This version of the Debian=
package supports only sequential simulation - future releases should
support parallel simulation as well.


Savant is related to freehdl somehow.

I only wanted to suggest before starting a completely new EDA iniciative, <= BR> checking the existing ones.

Rainer.


> I forgot this one, it's work ?
>
> Rainer Dorsch a =E9crit :
> >
> > >
> > > So now we need GPL VHDL simulator. Just, some thing wich com= pile and
> > > draw lines. I was very surprise to see that it doesn't exist= e !! You
> >
> > http://www.freehdl.seul.= org/
> >
> > Rainer
> >
> 
> ______________________________________________________________________= ________
> Vous avez un site perso ?
> 2 millions de francs =E0 gagner sur i(france) !
> Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
>
>
>
>
>
>


From Nicolas Boulay Tue Sep 26 20:52:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00647 for ; Wed, 27 Sep 2000 16:46:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:46 +0200 (MEST) Received: (qmail 29606 invoked by uid 0); 26 Sep 2000 18:48:28 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 26 Sep 2000 18:48:28 -0000 X-eGroups-Return: sentto-1101623-838-969994098-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 26 Sep 2000 18:48:24 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 18:48:15 -0000 Received: (qmail 2765 invoked from network); 26 Sep 2000 18:48:15 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 26 Sep 2000 18:48:15 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 26 Sep 2000 18:48:15 -0000 Received: from 195.36.170.154 [195.36.170.154] by lh00.opsion.fr; Tue, 26 Sep 2000 18:46:10 GMT Message-ID: <39D0F06E.44D5E402@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20000915014954.EWVR27630.femail2.sdc1.sfba.home.com@[24.10.43.202]> <39D0FB21.29933B5B@welfen-netz.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 20:52:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GPL, VHDL, et al Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f4515365bd1df5e98d3d86aca17d8adb Status: R X-Status: N

Kai Wetzel a =E9crit :
>
> A late reply ...
>
> Albert Abramson wrote:
> [...]
> > Anyone who has ever implemented a processor, even a simple one, c= an tell you
> > what's wrong with the current approach.  The real bottleneck= on modern uP's
> > is not logic, but wire, and the current f-cpu offers just too muc= h.
>
> Do you mean the FUs as such are too complicated or that there should > be fewer or do you mean the other aspects of FC0 ?
>
Bottelneck is a wrong word, the principal delay is the best. that means
that you need to have some block near to each other without wire
crossing all the chip (imagine a bloc which send wires all over the
chip...).
> [...]
> > A good VLIW design would allow us to break from the VHDL and just= go
> > straight to a hand designed, hand-tweaked mask.
>
> For the record, this approach (hand-tweaked and simple) convinces me.<= BR> > But as a software person I can't offer much to make the point
> stronger, unfortunately.
>

hand-tweaked is the most powerfull but is much to close to the tools !
Like asm versus C. With a hdl, you can target very different
technologie, and tweak after !


> > I do not believe in the current approach, because it creates bott= lenecks
> > even Intel does not have to deal with.  I have no plans to b= e part of
> > something I am relatively confident will never perform.  I'm= interested in
> > Porsche, not Caravan.  It's upsetting to see that so many sk= illed
> > individuals would be getting behind something has no chance of fl= ying high.
> [...]
>
> kai
nicO

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif


 From Steve Van der Hoeven Wed Sep 27 00:56:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00681 for ; Wed, 27 Sep 2000 16:46:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:46:59 +0200 (MEST) Received: (qmail 23529 invoked by uid 0); 26 Sep 2000 23:05:19 -0000 Received: from mu.egroups.com (208.50.99.218) by mx19.rz2.gmx.net with SMTP; 26 Sep 2000 23:05:19 -0000 X-eGroups-Return: sentto-1101623-839-970008967-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 26 Sep 2000 22:56:11 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 22:56:06 -0000 Received: (qmail 14744 invoked from network); 26 Sep 2000 22:56:05 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 26 Sep 2000 22:56:05 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 26 Sep 2000 22:56:05 -0000 Received: from future.cs.rice.edu (future.cs.rice.edu [128.42.1.178]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id RAA17359 for ; Tue, 26 Sep 2000 17:56:05 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39D0D591.D76364A0@welfen-netz.com> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 17:56:13 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/plain; charset=X-UNKNOWN X-UIDL: 5dba79861d005c59598a37016f151a59 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by WintelPC.Potential id QAA00681 Status: R X-Status: N On Tue, 26 Sep 2000, Kai Wetzel wrote: > Yann Guidon wrote: > > > > Hello > > > > I am really getting DESPERATED by the lack of real good GNU EDA tool. > > Yes, it's sad. > > > I have tried everything i could download, from the links > > at the opencollector.org database but in the end i'm disapointed. > > Would some people here be interested in opening a project > to create an application in the fashion of the Design > Architect-IC/IC-Station tools ? Together with Camille > (if it makes progress) and various back-end Software around, this > could become a useful suite, no ? Maybe this could put some lurkers > from the software side (like me) to good use :°> > ... So our conclusion is the perfect tool does not exist ... But could there be an patchwork of gnu tools satify your desires? Take a piece here, another their and plug (trought scripts, patches, software glue and faith)them all to gether (and prey it to work)... I'm not against reinventing the stone while, it's often more fun to have it's own tool you maid for your own purpose... But it takes an enormous amount of time... Whatever you want, I can always do something on vhdl editors.... --steve -------------------------- eGroups Sponsor -------------------------~-~> Thousands of Great Jobs, One Great Location! Austinatwork.com. Great Jobs, Great Life! http://click.egroups.com/1/7847/15/_/3462/_/970008967/ ---------------------------------------------------------------------_-> From "Albert Abramson" Wed Sep 27 01:24:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00684 for ; Wed, 27 Sep 2000 16:47:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:00 +0200 (MEST) Received: (qmail 2579 invoked by uid 0); 26 Sep 2000 23:28:48 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 26 Sep 2000 23:28:48 -0000 X-eGroups-Return: sentto-1101623-840-970010920-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 26 Sep 2000 23:28:41 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 26 Sep 2000 23:28:38 -0000 Received: (qmail 13833 invoked from network); 26 Sep 2000 23:28:38 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 26 Sep 2000 23:28:38 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta1 with SMTP; 26 Sep 2000 23:28:38 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000926232826.GUVJ6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Tue, 26 Sep 2000 16:28:26 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000926232826.GUVJ6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Sep 2000 16:24:42 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a993cd0b23dc8b1d2b7fac6fafa3c353 Status: R X-Status: N looks simple enough

Why use three instructions to perform an add, though?  And you use separate
instructions where it might be just as effective to use ori to load an
immediate value.

We've been tinkering around with packing many instructions into one long
word (like 128 bits) which would make 32-bit immediates possible.  We've
even been toying with multithreading one processor and VLIW.

Unfortunately, some of the grandfather members of the group feel done with
architecture, probably the most fun thing about uP's.  That's why I haven't
contributed very much lately.

But you're design is detailed, and I like the move-based control.  It's
different from what I usually see.

--Maxx

----------
>From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>
>To: <f-cpu@egroups.com>
>Subject: [f-cpu] Sayuri from Japan
>Date: Tue, Sep 26, 2000, 8:24 AM
>

>
>  Hi, I'm new comer here.
>  This is my tempolary output "Sayuri" , It's very simple CPU.
>  I hope your response, about it has some value or not.
>
>  http://www.morphyplanning.co.jp/FreeCPU/freecpu-e.html
>
>  Toyoaki Sagawa
>
>
>
>
>

eGroups Sponsor
From Yann Guidon Wed Sep 27 08:31:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00690 for ; Wed, 27 Sep 2000 16:47:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:01 +0200 (MEST) Received: (qmail 10038 invoked by uid 0); 27 Sep 2000 05:26:35 -0000 Received: from mu.egroups.com (208.50.99.218) by mx06.rz2.gmx.net with SMTP; 27 Sep 2000 05:26:35 -0000 X-eGroups-Return: sentto-1101623-841-970032473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 27 Sep 2000 05:27:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 05:27:53 -0000 Received: (qmail 11215 invoked from network); 27 Sep 2000 05:27:52 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 27 Sep 2000 05:27:52 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 27 Sep 2000 05:27:52 -0000 Received: from f-cpu.org (nas4-95.ras.club-internet.fr [195.36.203.95]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA07659 for ; Wed, 27 Sep 2000 07:27:41 +0200 (MET DST) Message-ID: <39D19458.59525563@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 07:31:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a8f901461bcda1a4d90a10f98ac3e846 Status: R X-Status: N hi,

Toyoaki Sagawa wrote:
>
>  Hi, I'm new comer here.
>  This is my tempolary output "Sayuri" , It's very simpl= e CPU.
>  I hope your response, about it has some value or not.
>
>  http://www.morphyplanning.co.jp/FreeCPU/freecpu-e.html

i'm downloading the files, but what does the diagram (gif) means ? :-)
sorry if i can't read japanese...
happy continuation,

>  Toyoaki Sagawa
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Nicolas Matringe Wed Sep 27 09:12:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00699 for ; Wed, 27 Sep 2000 16:47:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:05 +0200 (MEST) Received: (qmail 16959 invoked by uid 0); 27 Sep 2000 07:12:45 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 27 Sep 2000 07:12:45 -0000 X-eGroups-Return: sentto-1101623-842-970038756-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 27 Sep 2000 07:12:42 -0000 X-Sender: nicolas@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 07:12:35 -0000 Received: (qmail 27463 invoked from network); 27 Sep 2000 07:12:35 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 27 Sep 2000 07:12:35 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 27 Sep 2000 07:12:35 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA23582 for ; Wed, 27 Sep 2000 07:12:33 GMT X-To: Message-ID: <39D19DF7.654CD0ED@ipricot.com> Organization: IPricot (DotCom S.A.) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 09:12:55 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5df1c1f2c66a9d1bbb322e2d2d69c7ee Status: R X-Status: N Steve Van der Hoeven a =E9crit :
[...]
>   Whatever you want, I can always do something on vhdl edito= rs...

As far as editors are concerned, I don't think anyone should bother.
Emacs (running on every Unix and even on NT) has got very nice VHDL and
Verilog modes. I use them every day.

--
Nicolas MATRINGE          = ; IPricot / DotCom
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor=
3D""
From Yann Guidon Wed Sep 27 11:15:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00711 for ; Wed, 27 Sep 2000 16:47:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:08 +0200 (MEST) Received: (qmail 26165 invoked by uid 0); 27 Sep 2000 08:12:04 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 27 Sep 2000 08:12:04 -0000 X-eGroups-Return: sentto-1101623-843-970042321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mv.egroups.com with NNFMP; 27 Sep 2000 08:12:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 08:11:59 -0000 Received: (qmail 32709 invoked from network); 27 Sep 2000 08:11:59 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 08:11:59 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 27 Sep 2000 08:11:59 -0000 Received: from f-cpu.org (nas1-206.aub.club-internet.fr [195.36.150.206]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA28637 for ; Wed, 27 Sep 2000 10:11:50 +0200 (MET DST) Message-ID: <39D1BAC8.55193159@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200009261407.OAA09871@dichlore.mime.univ-paris8.fr> <39D0932F.7AD12D5B@ipricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 10:15:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2aef7576bc415f7137f2022373703d7e Status: R X-Status: N hi !

Nicolas Matringe wrote:
> Yann Guidon a =E9crit :
>
> > Alliance will be the only solution for the synthesis, i fear. If = we
> > ever need to synthetise anything at all (companies can do this to= ugh
> > task on a case per case basis for their own use). It's far from b= eing
> > perfect but it's necessary at a certain point.
>
> We are planning to buy some tools (Renoir/ModelSim/Leonardo) and I thi= nk
> I could do some F-CPU work after office hours. I'll let you know.

how coool !
that's the good news of the day :-)

> Nicolas MATRINGE         =   IPricot / DotCom

then :

Rainer Dorsch wrote:
> > Alliance will be the only solution for the synthesis, i fear. If = we ever need
> > to synthetise anything at all (companies can do this tough task o= n a case
> > per case basis for their own use). It's far from being perfect bu= t it's necessary
> > at a certain point.
> I thinks without synthesis, the whole project is useless. At least it = has to
> be proven, that there is a tool that synthesises the code. The others = will
> port it to other synthesis tools (see the LEON CPU project from ESA).<= BR> Of course, the synthesis is important but not at the current development st= age.
If we keep the source files in VHDL (or Verilog for those who prefer),
synthesis will be no "particular" problem.

now the problem is to get this fucking VHDL written and simulated, proofed<= BR> and nice-looking. in the absence of suitable tools, i'll stick to gcc/gdb .= ..

> > What we need is something compact, portable, GNU and working good= , for
> > compiling and simulating usual VHDL constructs. we don't need som= ething
> > sophisticated but that does his job easily and nicely. I want to = write VHDL,
> > at last...
>
> For a simulator, freehdl is the only way I see,
hummm... i 'll try it (if i find it on my HDD).

> synthesis Alliance (even if it does not synthesize it
> for a 0.13 mue library people can adapt it to DC or Leonardo).
of course. but Alliance is rather heavy.
it takes probably one year to master it :-)

> Rainer.

then :

Kai Wetzel wrote:
> Yann Guidon wrote:
> > I have tried everything i could download, from the links
> > at the opencollector.org database but in the end i'm disapointed.=
> Would some people here be interested in opening a project
> to create an application in the fashion of the Design
> Architect-IC/IC-Station tools ?  Together with Camille
> (if it makes progress) and various back-end Software around, this
> could become a useful suite, no ?  Maybe this could put some lurk= ers
> from the software side (like me) to good use :=B0>

remember that the goal of the f-cpu project is to design a CPU,
not a HDL SW. But nothing keep anybody from participating to such useful projects. Camille and other projects need a good kick in the butt :-)
we really need something working like renoir or similar stuffs and
i can hardly simulate any HDL with GNU tools. If some GNU EDA projects
could merge and have some fresh blood, it could probably make something
tha works as expected. The efforts in this direction are so various that they ahrdly succeed, a merge would probably be useful.

> > I personally have a good feeling for some Mentor SW. i have a dem= o CD
> > (not used) with some presentations and limited-time trial.
> Can this CD be ordered from their website ?  I've only seen the > still images and descriptions in the book, so I'd love to see it in > action.
i don't know if it's possible to copy this CD. it's the 1999 demo for win95= /NT.
the coming 2000 version will rock the house :-)

> I was very impressed by Mentor's hierarchical approach, switching
> between detailed layout and structural things pretty easily
> (so it seems).  And I got the impresion that VHDL based design co= uld
> intermix _comfortably_ with "direct layout", unlike in some = other tools.

Electric can do that too (more or less) but it doesn't allow me
to simulate raw VHDL.

> > I also tried Electric. Compiles fine under SuSE Linux, rather wel= l
> > under SUN but SGI refuses (cpp is fucked up there) and FreeBSD's = make
> > utility does not compile the project. The problem is that the SUN= is used
> > as a server and is accessed through the network, so the display i= s ... slow...
> > Anyway it's probably the last solution at our level. it's a "= ;real GNU" tool,
> > available from gnu.org and its mirors, it's professionnal and see= ms not to
> > be out of breath. if you can install it, read the manual and go f= orward.
>
> Though Electric looks fine in principle, I found it pretty tough to ge= t
> a few gates (respectively transistors) in with the layout view (CMOS l= ibrary).
> "Switching" between schematics and layout was even worse.&nb= sp; Visual cues about
> placement conflicts are provided but pretty simple.
> The whole thing felt like cutting raw meat with a spoon (so to say). > The display is slow indeed (though it was in an acceptable range on > local display).  I can hardly image to layout a microprocessor wi= th
> ultimately several millions of transistors with it.

hey, we're beginning to prototype some execution units, that's all.
no need to display ALL the transistors now :-)
if i could get the LRU VHDL simulated, i'd be more happy.

> > What we need is something compact, portable, GNU and working good= , for
> > compiling and simulating usual VHDL constructs. we don't need som= ething
> > sophisticated but that does his job easily and nicely. I want to = write VHDL,
> > at last...
> What do you have against Verilog ?  From a beginner's point of vi= ew it
> looked significantly easier to understand then VHDL, no ?  Or is = Verilog not
> as flexible and powerful as VHDL ?

don't get me wrong :-) VHDL and Verilog are on the same ground and you can<= BR> interchange the terms at will. In Europe (or so i think) it's a cultural habit to use VHDL, while americans use more Verilog.
I have chosen VHDL because that's what i have learnt at school.
it would be different if i was american. but as long as you get the sources=
and the SW under the GNU licence, i don't think it really makes a differenc= e :-)
unless you want to develop, the first thing that matters is to get the HDL = file
to work. but since i decided to stick to C+schematics for a while, it's not=
important at all : the design is "free" (GNU), the tools should b= e "free",
so the langage doesn't matter as long as it's widely known (not obfuscated)= .

> Regards,
> kai

then :

Nicolas Boulay wrote:
> Kai Wetzel a =E9crit :
> > Yann Guidon wrote:
> > > Hello
> > > I am really getting DESPERATED by the lack of real good GNU = EDA tool.
> > Yes, it's sad.
> THE CAD synthetis tools is Synopsys. This is the only one for 80% of t= he
> compagny in the world.
we don't need that at this point.

> Beside that do we really need a synthetis tools, nowadays ? Nowadays > there no line of vhdl for the fcpu. Leon team has just written [good ?= ]
> vhdl code. If you want to synthetis it, you could used tools in
> university or ask cad compagnies. Befor that you need the rtl CODE ! > This should pass all the rtl simulation. Yes, the code should be
> synthetisable but we are far from that !
right, and why ? There is no tool for this.
we have already played with gcc and other stuffs, they work
pretty well almost everywhere, but nothing like that for the HDL.

> Another question is what do we want to release ? Vhdl code is evident.=
that's what we could call the "reference platform".

> But if want to synthetise it you should target a specific technologie.=
> It's good to have a prototype. But you couldn't release the library > given by foundary.(because of the None Disclosure Agrement).
that's a problem. but we target no particular technology either.

> So now we need GPL VHDL simulator. Just, some thing wich compile and > draw lines. I was very surprise to see that it doesn't existe !! You > could find compilator for lot of very strange language but not for VHD= L
> ! One of my ex-professor said that there is a gap between electrical a= nd
> computer science engineers. I know that a lot of vhdl front-end has be= en
> written for formal proofing tools.

look at the opencollector database and you'll see a lot of VHDL parsers. but no "working" simulator :-( PICA was a pretty failure. It woul= d need to
be cleaned anyway, it was written in 1989 and probably on a VAX.
it only compiled on FreeBSD. If someone wants to reactualize it ... :-)

As for Alliance's simulator, i have not tried it yet.

> I sugest to push universities to develop a vhdl simulator, i'm sure th= at
> some of phd could do the work (because of the concurrencies, a vhdl > compiler should be a little bit more complicated compare to C one). > Maybe one days a gcc for vhdl will exist !

Linux was born because GCC existed. we need that kind of tool too.
> nicO


heeeeeelp !

list of things to try :
- freeHDL
- Alliance (again).
- Savant/waped/tyvis

nice but not doing the job :
- tEDA (tiny EDA, port of gEDA on Win95 in Pascal)
- Electric (a bit strange but can be useful)
- VGUI (structural VHDL generation only, result must be tweaked)

unsuccessful :
- PICA (hard to setup on most platforms, needs rewrite/cleaning)
- QCAD (PCB, strange)

and others, too.


then :

Steve Van der Hoeven wrote:
> .. So our conclusion is the perfect tool does not exist ...
> But could there be an patchwork of gnu tools satify your desires?
probably. but this will make the development more complex than needed.

> Take a piece here, another their and plug (trought scripts, patches, > software glue and faith)them all to gether (and prey it to work)... that's more or less what we do anyway...

>   I'm not against reinventing the stone while, it's often mo= re fun to have
> it's own tool you maid for your own purpose... But it takes an enormou= s
> amount of time...
yep, and we're rather late with the F-CPU already.

>   Whatever you want, I can always do something on vhdl edito= rs....
editing is not the problem, emacs does the trick ;-)

simulating and correcting bugs is another problem. without
simulator, we can't develop.


ok, let's work, not chat, now ;-)

> --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Rainer Dorsch Wed Sep 27 10:44:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00720 for ; Wed, 27 Sep 2000 16:47:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:11 +0200 (MEST) Received: (qmail 16480 invoked by uid 0); 27 Sep 2000 08:44:50 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 27 Sep 2000 08:44:50 -0000 X-eGroups-Return: sentto-1101623-844-970044284-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 27 Sep 2000 08:44:53 -0000 X-Sender: rainer@rai16.informatik.uni-stuttgart.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 08:44:44 -0000 Received: (qmail 18644 invoked from network); 27 Sep 2000 08:44:43 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 27 Sep 2000 08:44:43 -0000 Received: from unknown (HELO ifi.informatik.uni-stuttgart.de) (129.69.211.1) by mta2 with SMTP; 27 Sep 2000 08:44:42 -0000 Received: from rai16.informatik.uni-stuttgart.de (rai16 [129.69.183.16]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id KAA23327 for ; Wed, 27 Sep 2000 10:43:00 +0200 (MET DST) Received: from rai16.informatik.uni-stuttgart.de (localhost [127.0.0.1]) by rai16.informatik.uni-stuttgart.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA08719 for ; Wed, 27 Sep 2000 10:44:37 +0200 Message-Id: <200009270844.KAA08719@rai16.informatik.uni-stuttgart.de> X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: f-cpu@egroups.com In-Reply-To: Your message of "Wed, 27 Sep 2000 10:15:52 BST." <39D1BAC8.55193159@f-cpu.org> X-eGroups-From: Rainer Dorsch From: Rainer Dorsch MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 10:44:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d906d5b1b747dd77e69dc3fa51d18cf Status: R X-Status: N
> > synthesis Alliance (even if it does not synthesize it
> > for a 0.13 mue library people can adapt it to DC or Leonardo).
> of course. but Alliance is rather heavy.
> it takes probably one year to master it :-)
>

I think compared to commercial tools like IC station or the Synopsys tool suite it is rather simple. We had two master students synthesising a DLX CPU with it within 3 months (and having many other lectures beside that, so it was not a full time job!). AFAIK Alliance is also used in Stanford to teach students EDA design, because it is easier to understand what is going on than when the vendor tries to hide things from the competitioner. And you have the source! It is a lot easier to track down a problem than when you just get a message "Error 537 occured".

And since you have a team actively developing it, you might get features urgently needed.


Rainer.
eGroups Sponsor
From Yann Guidon Wed Sep 27 13:08:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00732 for ; Wed, 27 Sep 2000 16:47:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:15 +0200 (MEST) Received: (qmail 19627 invoked by uid 0); 27 Sep 2000 10:04:08 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 27 Sep 2000 10:04:08 -0000 X-eGroups-Return: sentto-1101623-845-970049042-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mu.egroups.com with NNFMP; 27 Sep 2000 10:04:05 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 10:04:01 -0000 Received: (qmail 4359 invoked from network); 27 Sep 2000 10:04:01 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 10:04:01 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 27 Sep 2000 10:04:00 -0000 Received: from f-cpu.org (nas3-51.ras.club-internet.fr [195.36.203.51]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA17308 for ; Wed, 27 Sep 2000 12:03:58 +0200 (MET DST) Message-ID: <39D1D528.E94819D4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 12:08:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL sim Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cd7e9f1e6a3e7c0a8ea4bbbe20234933 Status: R X-Status: N i'm trying to use Symphony's EDA tool called Simili.
it's not GPL. Available under Windows, no other build seems
made. It requires tcl/tk for one of the tools, this
makes 2.4+2.5=3D5MB to download. I'll try to see if it's
possible to simulate simple VHDL stuffs.

see http://www.s= ymphonyeda.com/download_simili.htm
and give us your opinion. It seems linked to synopsys
but not "bound" so the design files can be kept rather
independent. The lack of Unix port is sad anyway.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Nicolas Matringe Wed Sep 27 12:07:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00735 for ; Wed, 27 Sep 2000 16:47:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:16 +0200 (MEST) Received: (qmail 14399 invoked by uid 0); 27 Sep 2000 10:07:44 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 27 Sep 2000 10:07:44 -0000 X-eGroups-Return: sentto-1101623-846-970049245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 27 Sep 2000 10:07:43 -0000 X-Sender: nicolas@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 10:07:23 -0000 Received: (qmail 27878 invoked from network); 27 Sep 2000 10:07:23 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Sep 2000 10:07:23 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 27 Sep 2000 10:07:23 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id KAA27482 for ; Wed, 27 Sep 2000 10:07:21 GMT X-To: Message-ID: <39D1C6ED.5B61DB53@ipricot.com> Organization: IPricot (DotCom S.A.) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D1D528.E94819D4@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 12:07:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL sim Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e032ab71a5bcdd1b0b95ef43c7b88719 Status: R X-Status: N Yann Guidon a =E9crit :
>
> i'm trying to use Symphony's EDA tool called Simili.
> it's not GPL. Available under Windows, no other build seems
> made. It requires tcl/tk for one of the tools, this
> makes 2.4+2.5=3D5MB to download. I'll try to see if it's
> possible to simulate simple VHDL stuffs.

I think this one is quite good. I remember seeing its author requiring
comments on comp.lang.vhdl
I'm not sure it's got a graphic waveform viewer though
--
Nicolas MATRINGE          = ; IPricot / DotCom
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor=
3D""
=
From "Toyoaki Sagawa" Wed Sep 27 13:09:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00741 for ; Wed, 27 Sep 2000 16:47:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:18 +0200 (MEST) Received: (qmail 1832 invoked by uid 0); 27 Sep 2000 11:09:13 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 27 Sep 2000 11:09:13 -0000 X-eGroups-Return: sentto-1101623-847-970052950-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 27 Sep 2000 11:09:12 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 11:09:09 -0000 Received: (qmail 26628 invoked from network); 27 Sep 2000 11:09:09 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 27 Sep 2000 11:09:09 -0000 Received: from unknown (HELO mail158.nifty.com) (202.248.37.150) by mta3 with SMTP; 27 Sep 2000 11:09:09 -0000 Received: from cfb5 by mail158.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA21933 for ; Wed, 27 Sep 2000 20:09:07 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39D19458.59525563@f-cpu.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 20:09:23 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 68ca07eb79c0b7d7a1f13359a33f3f8e Status: R X-Status: N
Hi, sorry this is just a simple diagram, maybe you (guru of VHDL) don't
need it :-)

Toyoaki Sagawa

i'm downloading the files, but what does the diagram (gif) means ? :-)
sorry if i can't read japanese...
happy continuation,

>  Toyoaki Sagawa
WHYGEE
eGroups Sponsor
From JEAN Olivier Wed Sep 27 13:12:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00744 for ; Wed, 27 Sep 2000 16:47:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:20 +0200 (MEST) Received: (qmail 29171 invoked by uid 0); 27 Sep 2000 11:16:01 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 27 Sep 2000 11:16:01 -0000 X-eGroups-Return: sentto-1101623-848-970053335-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 27 Sep 2000 11:15:47 -0000 X-Sender: O.JEAN@euronext.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 11:15:35 -0000 Received: (qmail 14171 invoked from network); 27 Sep 2000 11:15:35 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 11:15:35 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta3 with SMTP; 27 Sep 2000 11:15:34 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TFCHW18R; Wed, 27 Sep 2000 13:13:03 +0200 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Sep 2000 13:15:34 +0200 Message-ID: <098A4E5B420CD3118F690008C75DD5DD029AE570@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 13:12:59 +0200 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 69965f830a7aa2fc8f7d9ed0d736c280 Status: R X-Status: N Hi !

I have looked about the diagram. I don't understand the Kanji's alphabet
(?).
Can you translate in english, please ?
I'm not a specialist about making processor, just a manual's maintener !
And I would like understand schema and another diagram ...

           bye.
                  Olivier.
eGroups Sponsor
From "Toyoaki Sagawa" Wed Sep 27 13:23:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00747 for ; Wed, 27 Sep 2000 16:47:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:20 +0200 (MEST) Received: (qmail 13316 invoked by uid 0); 27 Sep 2000 11:21:27 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 27 Sep 2000 11:21:27 -0000 X-eGroups-Return: sentto-1101623-849-970053776-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 27 Sep 2000 11:22:59 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 11:22:55 -0000 Received: (qmail 27014 invoked from network); 27 Sep 2000 11:22:55 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 27 Sep 2000 11:22:55 -0000 Received: from unknown (HELO mail158.nifty.com) (202.248.37.150) by mta1 with SMTP; 27 Sep 2000 11:22:55 -0000 Received: from cfb5 by mail158.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA00095 for ; Wed, 27 Sep 2000 20:22:53 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000926232826.GUVJ6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 20:23:09 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e89450e796e07703ca773d969070bd95 Status: R X-Status: N
Hi,

>Why use three instructions to perform an add, though?

this is just a normal instruction (ADD R1, R2, R3) vs. Sayuri's add(R3 <-
R1+R2).
I wonder about GCC can make suitable assembler code for sayuri..

>long word

Sayuri can be easily expanded to 64bit/word or 128bit/word. but it will
need severe tuning for compiler, so I'm thinking about multi Sayuri core and
single cash (to avoid cash coherency problem, and to keep VHDL simple) in
One chip.


Toyoaki Sagawa

-----Original Message-----
From: Albert Abramson [mailto:maxx@nventure.com]
Sent: Wednesday, September 27, 2000 8:25 AM
To: f-cpu@egroups.com
Subject: Re: [f-cpu] Sayuri from Japan


looks simple enough
eGroups Sponsor
From "Toyoaki Sagawa" Wed Sep 27 13:56:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00762 for ; Wed, 27 Sep 2000 16:47:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:25 +0200 (MEST) Received: (qmail 9221 invoked by uid 0); 27 Sep 2000 11:56:04 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 27 Sep 2000 11:56:04 -0000 X-eGroups-Return: sentto-1101623-850-970055762-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 27 Sep 2000 11:56:04 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 11:56:01 -0000 Received: (qmail 27024 invoked from network); 27 Sep 2000 11:56:01 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 27 Sep 2000 11:56:01 -0000 Received: from unknown (HELO mail153.nifty.com) (202.248.37.146) by mta3 with SMTP; 27 Sep 2000 11:56:01 -0000 Received: from cfb5 by mail153.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA22827 for ; Wed, 27 Sep 2000 20:56:00 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <098A4E5B420CD3118F690008C75DD5DD029AE570@NTS40.sbf.bourseparis.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 20:56:15 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b0ff044b1e8792ff307674b978cbef7f Status: R X-Status: N
Hi,  update it to english.

Toyoaki Sagawa

-----Original Message-----
From: JEAN Olivier [mailto:O.JEAN@euronext.fr]
Sent: Wednesday, September 27, 2000 8:13 PM
To: 'f-cpu@egroups.com'
Subject: RE: [f-cpu] Sayuri from Japan


Hi !

I have looked about the diagram. I don't understand the Kanji's alphabet
(?).
Can you translate in english, please ?


eGroups Sponsor
From Yann Guidon Wed Sep 27 17:05:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00807 for ; Wed, 27 Sep 2000 16:47:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:39 +0200 (MEST) Received: (qmail 31643 invoked by uid 0); 27 Sep 2000 14:01:29 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 27 Sep 2000 14:01:29 -0000 X-eGroups-Return: sentto-1101623-851-970063260-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 27 Sep 2000 14:01:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 14:00:59 -0000 Received: (qmail 18542 invoked from network); 27 Sep 2000 14:00:59 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 27 Sep 2000 14:00:59 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 27 Sep 2000 14:00:58 -0000 Received: from f-cpu.org (nas4-186.aub.club-internet.fr [195.36.145.186]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA16430 for ; Wed, 27 Sep 2000 16:00:53 +0200 (MET DST) Message-ID: <39D20CA6.650C8EF3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 16:05:10 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VLIW ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fc87f98f7bfb474bafc2c6e9ac957b5e Status: R X-Status: N hello,

i'm reading sayuri's code (i hope that
the final F-CPU code will be as good as
what Toyoaki Sagawa has written).

and i was thinking about Albert's answer.
He probably believes that we don't care about him,
which is false. Particularly, the problems
of VLIW (like the consistency of the code,
the violation of the coding rules, the enlargement
of the decoding units etc) make its implementation
as a UNIX CPU very difficult : look at Intel's crap.
"pure" VLIW is not suitable for such a project
as the F-CPU.

So it struck me recently that superscalar CPUs have the
same problem as usual RISC machines, at the decoding
level only though. Well it was obvious, but it also
struck me that the usual ways to solve this limitations
are rather inefficient and don't match the F-CPU
requirements of scalability and longevity.

IA-64 uses a special information in the instruction word
to know how the instructions should be decoded. I don't know
how well it scales and i doubt that a very large version
is possible because one can't access more than 32 int registers
at once. 12 instructions seems a practical maximum for a int-only
code (the usual case when you don't forecast the weather).
For the F-CPU, there are 2x more registers so 24, or at least
16 instructions per cycle "could" be feasible and codable
in a real program. IA's instruction format can't be used too.
Some opcodes in the F-CPU map are reserved for hinting the
CPU's decoder about the instruction packing.

Of course, this could be done "on the fly", with some special bit= s
per instruction in the cache : it is decoded once with all the
necessary checks, the bits are filled (how many instructions do
compete or stall etc) and then on the next executions, the bits
are used to skip the check stage. They could also be reorganised
on the fly, but the HW is a bit complex and unnecessary at our point.
All of that is done #before# decoding and executing : the field
that is on the chip, between the cache and the decoder, is very
interesting when you want to speedup things. Remember that the
first Pentium did have a bit per byte in the Icache to say where a
previously decoded instruction started and wether it is pairable.

Now, if this can be done harmlessly by HW on the fly, why would
we give hints ? they shift to a higher level, because the amount
of bandwidth they take is revelant. The F-CPU also gives hints about
the memory usage (what bank and what cache strategy). Instruction
packets will have a very wide variety of forms and sizes, we can't spend a lot of opcodes for this matter.

today's food for thoughts : hierarchical hints.
Level 1 : hints about registers/EU contentions for the next 1 to 4 instruct= ions
Level 2 : hints about a group of Level 1 packets. for example : loops,
branches, small subroutines...
Level 3 : hints about a still higher level... what registers are saved etc.=

Each level would need 1 opcode. I think that there are 4 reserved opcodes,<= BR> this can change but it is ok.

hints, advices, ideas, constructive criticisms wanted :-)


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Yann Guidon Wed Sep 27 17:34:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00825 for ; Wed, 27 Sep 2000 16:47:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:46 +0200 (MEST) Received: (qmail 28643 invoked by uid 0); 27 Sep 2000 14:30:23 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 27 Sep 2000 14:30:23 -0000 X-eGroups-Return: sentto-1101623-852-970065013-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 27 Sep 2000 14:30:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 14:30:12 -0000 Received: (qmail 15212 invoked from network); 27 Sep 2000 14:30:12 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 27 Sep 2000 14:30:12 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 27 Sep 2000 14:30:11 -0000 Received: from f-cpu.org (nas3-118.aub.club-internet.fr [195.36.145.118]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA04286 for ; Wed, 27 Sep 2000 16:30:08 +0200 (MET DST) Message-ID: <39D21380.E8A9C0C4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200009270844.KAA08719@rai16.informatik.uni-stuttgart.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 16:34:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 52c423b0007bf50bf1d373703d54026d Status: R X-Status: N hi,

i still haven't really tested Symphony's EDA tool but will do it within a f= ew days.
anyway, there's a tool in it that displays waveforms using TCL/TK, or at le= ast
they say so, i haven't tested it yet.

Rainer Dorsch wrote:
> > > synthesis Alliance (even if it does not synthesize it
> > > for a 0.13 mue library people can adapt it to DC or Leonardo= ).
> > of course. but Alliance is rather heavy.
> > it takes probably one year to master it :-)
> I think compared to commercial tools like IC station or the Synopsys > tool suite it is rather simple. We had two master students synthesisin= g
> a DLX CPU with it within 3 months (and having many other lectures besi= de
> that, so it was not a full time job!). AFAIK Alliance is also used in<= BR> > Stanford to teach students EDA design, because it is easier to
> understand what is going on than when the vendor tries to hide
> things from the competitioner. And you have the source! It is
> a lot easier to track down a problem than when you just get
> a message "Error 537 occured".

You are right for those point. But what i seek is a nice tool
that takes a few minutes to start playing with, so people are not
discouraged by the first approach.

The analogy could be that you can swim to cross a river, but you
need a big boat to cross the ocean. and it's harder to learn how to
pilot a big boat.

We don't need to synthetize now, we need a simple and working
illustration of the F-CPU behaviour. we'll need much more efforts
later, but we need the behaviour first.

> And since you have a team actively developing it,
> you might get features urgently needed.
wrong :-) the few Alliance developpers are overflowed with work-to-do.
they'll answer : "do it yourself, we might include it in the next rele= ase."
but nothing keeps us from modifying this huge stuff, if we have
as much time as some presume ;-)

Veil Spass am keyboard,
> Rainer.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Yann Guidon Wed Sep 27 17:34:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00828 for ; Wed, 27 Sep 2000 16:47:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Sep 2000 16:47:47 +0200 (MEST) Received: (qmail 16543 invoked by uid 0); 27 Sep 2000 14:30:40 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 27 Sep 2000 14:30:40 -0000 X-eGroups-Return: sentto-1101623-853-970065035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 27 Sep 2000 14:30:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 14:30:35 -0000 Received: (qmail 6956 invoked from network); 27 Sep 2000 14:30:35 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Sep 2000 14:30:35 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 27 Sep 2000 14:30:34 -0000 Received: from f-cpu.org (nas3-118.aub.club-internet.fr [195.36.145.118]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA08301 for ; Wed, 27 Sep 2000 16:30:21 +0200 (MET DST) Message-ID: <39D2138C.E6989CB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 16:34:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f480079c1929d6de24224f12553ed45b Status: R X-Status: N Toyoaki Sagawa wrote:
>  I wonder about GCC can make suitable assembler code for sayuri..=
GCC will need a big change in its core. Anyway, i don't count on GCC anymor= e,
except for making really portable things. That's why i want to work on GNL.=
With GNL, making a back-end for almost any CPU will be really easy :-)

> >long word
>  Sayuri can be easily expanded to 64bit/word or 128bit/word. but = it will
> need severe tuning for compiler, so I'm thinking about multi Sayuri co= re and
> single cash (to avoid cash coherency problem, and to keep VHDL simple)= in
> One chip.

you mean "cache" instead of "cash", i suppose :-)
i knew that memory was expensive, but i wouldn't put
a coin on a chip ;-) </bad tired humor>

> Hi,  update it to english.
ok, i'll look !

respect,
> Toyoaki Sagawa

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Moi qui pensait que dans le libre y avait pas trop de cyber-neuneus.&= quot;
F. Couchet, APRIL.org, 8/18/2000 (contre les portails =E0 la con)
eGroups Sponsor=
3D""
From Steve Van der Hoeven Wed Sep 27 18:30:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00316 for ; Thu, 28 Sep 2000 21:19:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:43 +0200 (MEST) Received: (qmail 8461 invoked by uid 0); 27 Sep 2000 16:35:21 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 27 Sep 2000 16:35:21 -0000 X-eGroups-Return: sentto-1101623-854-970072507-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 27 Sep 2000 16:35:11 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 16:35:06 -0000 Received: (qmail 6756 invoked from network); 27 Sep 2000 16:30:40 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Sep 2000 16:30:40 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 27 Sep 2000 16:30:40 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id LAA07582 for ; Wed, 27 Sep 2000 11:30:39 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39D19DF7.654CD0ED@ipricot.com> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 11:30:39 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: Mentor Graphics ? (was: Re: [f-cpu] EDA tools) Content-Type: text/plain; charset=X-UNKNOWN X-UIDL: e7de05a925ec47a2b740a3846abdb724 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by WintelPC.Potential id VAA00316 Status: R X-Status: N On Wed, 27 Sep 2000, Nicolas Matringe wrote: > Steve Van der Hoeven a écrit : > [...] > > Whatever you want, I can always do something on vhdl editors... > > As far as editors are concerned, I don't think anyone should bother. > Emacs (running on every Unix and even on NT) has got very nice VHDL and > Verilog modes. I use them every day. > -------------------------- eGroups Sponsor -------------------------~-~> Your family still won't know what you do. At least they'll know where. The resources, brainpower & breadth of opportunities at Microsoft are unmatched. The only question is are you ready for that kind of impact? http://click.egroups.com/1/9223/15/_/3462/_/970072507/ ---------------------------------------------------------------------_-> From jeff davies Wed Sep 27 18:54:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00331 for ; Thu, 28 Sep 2000 21:19:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:48 +0200 (MEST) Received: (qmail 30736 invoked by uid 0); 27 Sep 2000 16:55:52 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 27 Sep 2000 16:55:52 -0000 X-eGroups-Return: sentto-1101623-855-970073650-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 27 Sep 2000 16:54:55 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 16:54:09 -0000 Received: (qmail 18311 invoked from network); 27 Sep 2000 16:54:09 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 27 Sep 2000 16:54:09 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta3 with SMTP; 27 Sep 2000 16:54:08 -0000 Received: from modem-14.meitnerium.dialup.pol.co.uk ([62.136.74.142] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13eKT7-0004v2-00 for f-cpu@egroups.com; Wed, 27 Sep 2000 17:54:06 +0100 Sender: root@pop.gmx.net Message-ID: <39D22634.59DF71BD@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 17:54:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c0930b72c583b81e03420584f690876 Status: R X-Status: N Toyoaki Sagawa wrote:

>
>  Sayuri can be easily expanded to 64bit/word or 128bit/word. but it will
> need severe tuning for compiler, so I'm thinking about multi Sayuri core and
> single cash (to avoid cash coherency problem, and to keep VHDL simple) in
> One chip.
>

Aha, someone with the same idea as me, but someone who has made more progress
than me.
(scalable cpu, and keeping simple).

I think that a BIG problem with current CPUs is the sheer amount of heat they
generate.
At the same time I light enlightenment a great deal, and my old P90 (180
bogomips) can't do much without
interfering with MP3 player, whereas my laptop P166MMX (360 bogomips) doesn't
have a problem.

So I'd like a 360 bogomips cpu as a target . (or should that be CPUs - perhaps
8 off Sayuris will do this??).

I think that making a 256 bit simple cpu might give equivalent performance to a
complex 64 bit CPU, with
lower clock rate (and hence power consumption) and for the same chip area (no
out of order stuff, just keep
it simple).
Personally I think that power usage will become a much bigger issue very soon
now.

One idea, what about a CPU that can be 32/64/128/256 bit. (according to mode
bits) - in 32 bit mode,
the rest of the cpu is non-clocked and therefore uses little power.
Alternatively,. 8 off 32 bit cpus
in a package, and the unused CPUs are turned off when not in use!!

I just took delivery of my Nokia 9110i which has a 486 in it, and yet runs for
4 days on standby battery..
..vey nice.

Apple with the G4 powerpc are following the lower clock rate, non-fan cooled
route, with a floating
point engine that can execute 8 simultaneous floating point operations.
I'd love one, and might get one before long, especially with OS X (Apple
Desktop on BSD).
Just wondering aloud if JDK available for mac - probably.

One very important thing, Toyoaki, are you going to publish your processor
under the GPL
(GNU Public licence?). I rather hope so.

Have you put one on an FPGA yet?

Jeff Davies
jeff@llandre.freeserve.co.uk

>
> Toyoaki Sagawa
>
> -----Original Message-----
> From: Albert Abramson [mailto:maxx@nventure.com]
> Sent: Wednesday, September 27, 2000 8:25 AM
> To: f-cpu@egroups.com
> Subject: Re: [f-cpu] Sayuri from Japan
>
> looks simple enough
>

 From Nicolas Boulay Wed Sep 27 19:52:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00340 for ; Thu, 28 Sep 2000 21:19:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:54 +0200 (MEST) Received: (qmail 21977 invoked by uid 0); 27 Sep 2000 17:47:18 -0000 Received: from jk.egroups.com (208.50.144.83) by mx06.rz2.gmx.net with SMTP; 27 Sep 2000 17:47:18 -0000 X-eGroups-Return: sentto-1101623-856-970076923-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 27 Sep 2000 17:48:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 17:48:34 -0000 Received: (qmail 16684 invoked from network); 27 Sep 2000 17:48:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 27 Sep 2000 17:48:34 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 27 Sep 2000 17:48:34 -0000 Received: from 195.36.164.94 [195.36.164.94] by lh00.opsion.fr; Wed, 27 Sep 2000 17:46:24 GMT Message-ID: <39D233F8.B1D155A1@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: "f-cpu@egroups.com" From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 19:52:56 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vliw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9779919166957e484f3ef8ea7178f7f4 Status: R X-Status: N
A special difficulties is the number of port needed by register. In the
TI C64X DSP, there are 2 times 4 pipelines which access to different
bank register. So 4 pipelines should be a maximum for simple things. To
have an easy programming processor, we need that all the 4 pipelines are strictly equivalent (no special slot for memory access for exemple)
because gcc could became crazy.

After that we could manage more packet of 4 instruction word (later).
This packet can be encapsulate with few bit to define what there are in
it, to speed up decode.

An other trick from TI DSP (C55) is its multisize instruction world
(8,16,24,32,48) to reduice the size of the code (they said 20% smaller
than ARM thumb code). Inside the core they use a 32 bit data bus. So
most of the time you need one click to run an instruction.

So to resume, we could used a standart packet of 4 instructions with an
head to describe the packet. Or this head could be like an opcode and
describe a much larger packet, and just a bit discribe that this opcode
is a "packet description" ?

Does i dream ?
nicO

Yann Guidon a =E9crit :
>
> hello,
>
> i'm reading sayuri's code (i hope that
> the final F-CPU code will be as good as
> what Toyoaki Sagawa has written).
>
> and i was thinking about Albert's answer.
> He probably believes that we don't care about him,
> which is false. Particularly, the problems
> of VLIW (like the consistency of the code,
> the violation of the coding rules, the enlargement
> of the decoding units etc) make its implementation
> as a UNIX CPU very difficult : look at Intel's crap.
> "pure" VLIW is not suitable for such a project
> as the F-CPU.
>
> So it struck me recently that superscalar CPUs have the
> same problem as usual RISC machines, at the decoding
> level only though. Well it was obvious, but it also
> struck me that the usual ways to solve this limitations
> are rather inefficient and don't match the F-CPU
> requirements of scalability and longevity.
>
> IA-64 uses a special information in the instruction word
> to know how the instructions should be decoded. I don't know
> how well it scales and i doubt that a very large version
> is possible because one can't access more than 32 int registers
> at once. 12 instructions seems a practical maximum for a int-only
> code (the usual case when you don't forecast the weather).
> For the F-CPU, there are 2x more registers so 24, or at least
> 16 instructions per cycle "could" be feasible and codable > in a real program. IA's instruction format can't be used too.
> Some opcodes in the F-CPU map are reserved for hinting the
> CPU's decoder about the instruction packing.
>
> Of course, this could be done "on the fly", with some specia= l bits
> per instruction in the cache : it is decoded once with all the
> necessary checks, the bits are filled (how many instructions do
> compete or stall etc) and then on the next executions, the bits
> are used to skip the check stage. They could also be reorganised
> on the fly, but the HW is a bit complex and unnecessary at our point.<= BR> > All of that is done #before# decoding and executing : the field
> that is on the chip, between the cache and the decoder, is very
> interesting when you want to speedup things. Remember that the
> first Pentium did have a bit per byte in the Icache to say where a
> previously decoded instruction started and wether it is pairable.
>
> Now, if this can be done harmlessly by HW on the fly, why would
> we give hints ? they shift to a higher level, because the amount
> of bandwidth they take is revelant. The F-CPU also gives hints about > the memory usage (what bank and what cache strategy). Instruction
> packets will have a very wide variety of forms and sizes, we can't spe= nd
> a lot of opcodes for this matter.
>
> today's food for thoughts : hierarchical hints.
> Level 1 : hints about registers/EU contentions for the next 1 to 4 ins= tructions
> Level 2 : hints about a group of Level 1 packets. for example : loops,=
> branches, small subroutines...
> Level 3 : hints about a still higher level... what registers are saved= etc.
>
> Each level would need 1 opcode. I think that there are 4 reserved opco= des,
> this can change but it is ok.
>
> hints, advices, ideas, constructive criticisms wanted :-)
>
> WHYGEE

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
eGroups Sponsor=
3D""
From jeff davies Wed Sep 27 21:05:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00352 for ; Thu, 28 Sep 2000 21:19:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:57 +0200 (MEST) Received: (qmail 10673 invoked by uid 0); 27 Sep 2000 19:04:11 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 27 Sep 2000 19:04:11 -0000 X-eGroups-Return: sentto-1101623-857-970081521-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 27 Sep 2000 19:05:26 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 19:05:20 -0000 Received: (qmail 26320 invoked from network); 27 Sep 2000 19:05:20 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Sep 2000 19:05:20 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta1 with SMTP; 27 Sep 2000 19:05:20 -0000 Received: from modem-244.texas.dialup.pol.co.uk ([62.137.94.244] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13eMW5-0006kZ-00 for f-cpu@egroups.com; Wed, 27 Sep 2000 20:05:18 +0100 Sender: root@pop.gmx.net Message-ID: <39D244F3.9AC629C0@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D233F8.B1D155A1@ifrance.com> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 20:05:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 89afec677ebb5c40f0eb81b0689299cf Status: R X-Status: N Nicolas Boulay wrote:

> An other trick from TI DSP (C55) is its multisize instruction world
> (8,16,24,32,48) to reduice the size of the code (they said 20% smaller
> than ARM thumb code). Inside the core they use a 32 bit data bus. So
> most of the time you need one click to run an instruction.
>

Is this "idea" the intellectual property of TI? We ought to stay away from other
people's IP
and develop our own ideas.
Jeff Davies
eGroups Sponsor
From Steve Van der Hoeven Wed Sep 27 21:21:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00355 for ; Thu, 28 Sep 2000 21:19:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:58 +0200 (MEST) Received: (qmail 17084 invoked by uid 0); 27 Sep 2000 19:21:36 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 27 Sep 2000 19:21:36 -0000 X-eGroups-Return: sentto-1101623-858-970082482-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 27 Sep 2000 19:21:27 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 19:21:21 -0000 Received: (qmail 1887 invoked from network); 27 Sep 2000 19:21:21 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 27 Sep 2000 19:21:21 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta3 with SMTP; 27 Sep 2000 19:21:21 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id OAA13839 for ; Wed, 27 Sep 2000 14:21:20 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39D244F3.9AC629C0@llandre.freeserve.co.uk> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 14:21:20 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aff7cbd12240a8bf6a854eea044cf548 Status: R X-Status: N

On Wed, 27 Sep 2000, jeff davies wrote:

> Nicolas Boulay wrote:
>
> > An other trick from TI DSP (C55) is its multisize instruction world
> > (8,16,24,32,48) to reduice the size of the code (they said 20% smaller
> > than ARM thumb code). Inside the core they use a 32 bit data bus. So
> > most of the time you need one click to run an instruction.
> >
>
> Is this "idea" the intellectual property of TI? We ought to stay away from other
> people's IP
> and develop our own ideas.
> Jeff Davies
>
  we could imagin the instructions to be a stream of bits... no more bites
boundaries. This could lead to even more compact code.


Once again we are talking about code compression...

take a look to this, it's good start to other documents about it:

http://www.iro.umontreal.ca/~latendre/publications/index.html


--Steve
eGroups Sponsor
From Nicolas Boulay Wed Sep 27 22:10:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00358 for ; Thu, 28 Sep 2000 21:19:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:59 +0200 (MEST) Received: (qmail 6084 invoked by uid 0); 27 Sep 2000 20:06:20 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 27 Sep 2000 20:06:20 -0000 X-eGroups-Return: sentto-1101623-859-970085173-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hk.egroups.com with NNFMP; 27 Sep 2000 20:06:14 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 20:06:12 -0000 Received: (qmail 26574 invoked from network); 27 Sep 2000 20:06:10 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 27 Sep 2000 20:06:10 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta1 with SMTP; 27 Sep 2000 20:06:10 -0000 Received: from 195.36.162.241 [195.36.162.241] by lh04.opsion.fr; Wed, 27 Sep 2000 20:02:35 GMT Message-ID: <39D2542D.941A8F6E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: "f-cpu@egroups.com" From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 22:10:21 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Ultrasparc iii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 0c400134cd1b6bb0c15a920c9164a8d1 Status: R X-Status: N http://www.aceshardware.com/Spades/read.php?article_id=116 About the Uiii and a little bit more, which suggest to have 3 slots for the VLIW and have 1 clock latency of the memory cache. ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif -------------------------- eGroups Sponsor -------------------------~-~> No blistered feet. No crowd. No travel. Intraware invites you to attend a virtual tradeshow: Ensuring Scalable and Secure E-Business Systems. http://click.egroups.com/1/9219/15/_/3462/_/970085173/ ---------------------------------------------------------------------_-> From Kai Wetzel Thu Sep 28 00:12:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00361 for ; Thu, 28 Sep 2000 21:19:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:19:59 +0200 (MEST) Received: (qmail 25451 invoked by uid 0); 27 Sep 2000 20:13:00 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 27 Sep 2000 20:13:00 -0000 X-eGroups-Return: sentto-1101623-860-970085572-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 27 Sep 2000 20:12:58 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 20:12:51 -0000 Received: (qmail 13636 invoked from network); 27 Sep 2000 20:12:51 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 20:12:51 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta3 with SMTP; 27 Sep 2000 20:12:51 -0000 Received: from welfen-netz.com [213.6.74.153] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Wed, 27 Sep 2000 22:12:45 +0200 Sender: kai@pop.gmx.net Message-ID: <39D270B3.F418B5F4@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D20CA6.650C8EF3@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 00:12:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e7d457da14e4539a9208437b300afe39 Status: R X-Status: N Hi,

Yann Guidon wrote:
[...]
> Particularly, the problems of VLIW (like the consistency of the
> code, the violation of the coding rules, the enlargement
> of the decoding units etc)

Well, you have a point with the consistency/violation stuff, but
using a software instruction rescedular it's not that bad as long
as the supported instructions and overall arch. dont change.

Regarding the decoding unit: IIRC it's supposed to be
pretty tiny with VLIW - why do you say it's enlarged ?

> make its implementation as a UNIX CPU very difficult :

What's a UNIX CPU, what's a Tetris CPU, ... ?  UNIX is
not likely to be a very CPU bound itself, what matters
is the speed of CPU-bound tasks, and they only make up
an extremely tiny fraction of all the code running most
UNIX systems, no ?

> look at Intel's crap.

Well, it's crap - so what ? =3DO)

> "pure" VLIW is not suitable for such a project
> as the F-CPU.

Hmm, I don't know what you mean by "pure" - we could take 80%
of the FC0 ISA, add some and a little and get a "VLIW"
instruction set (for FC1, 2, 3, whatever).  It's not pure, but
it's certainly a different approach :=B0>

[...]
> IA-64 uses a special information in the instruction word
> to know how the instructions should be decoded. I don't know
> how well it scales and i doubt that a very large version
> is possible because one can't access more than 32 int registers
> at once. 12 instructions seems a practical maximum for a int-only
> code (the usual case when you don't forecast the weather).
> For the F-CPU, there are 2x more registers so 24, or at least
> 16 instructions per cycle "could" be feasible and codable > in a real program.

Very optimistic...

[...]
kai
eGroups Sponsor=
3D""
From Yann Guidon Thu Sep 28 01:10:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00367 for ; Thu, 28 Sep 2000 21:20:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:01 +0200 (MEST) Received: (qmail 30231 invoked by uid 0); 27 Sep 2000 22:06:20 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 27 Sep 2000 22:06:20 -0000 X-eGroups-Return: sentto-1101623-861-970092374-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 27 Sep 2000 22:06:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 22:06:13 -0000 Received: (qmail 2421 invoked from network); 27 Sep 2000 22:06:13 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 27 Sep 2000 22:06:13 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 27 Sep 2000 22:06:12 -0000 Received: from f-cpu.org (nas2-222.ras.club-internet.fr [195.36.192.222]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA28334 for ; Thu, 28 Sep 2000 00:06:05 +0200 (MET DST) Message-ID: <39D27E5B.7C7EAAB7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D233F8.B1D155A1@ifrance.com> <39D244F3.9AC629C0@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 00:10:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fd5c2743c3b7491deecac7ec35dd84ca Status: R X-Status: N hi !

jeff davies wrote:
> Nicolas Boulay wrote:
> > An other trick from TI DSP (C55) is its multisize instruction wor= ld
> > (8,16,24,32,48) to reduice the size of the code (they said 20% sm= aller
> > than ARM thumb code). Inside the core they use a 32 bit data bus.= So
> > most of the time you need one click to run an instruction.
> Is this "idea" the intellectual property of TI? We ought to = stay away from other
> people's IP and develop our own ideas.
> Jeff Davies

true and false : ok for staying away from TI.
false because CISC was not invented by TI ;-)

then :

Steve Van der Hoeven wrote:
> On Wed, 27 Sep 2000, jeff davies wrote:
> > Nicolas Boulay wrote:
<snip>
> we could imagine the instructions to be a stream of bits... no more bi= tes
> boundaries. This could lead to even more compact code.
yup, and how will that react when you cross a cache line AND cross a page b= oundary
AND trigger a TLB miss AND trigger a page refill from hdd ? :-)
how will you jump, you'll need 5 more bits in the jump address...
cool, back to the old'good CISC ages :-)

> Once again we are talking about code compression...
it was not about code compression, it was about "not wasting memory ba= ndwidth
in a silly way". it was about the good sense of not encoding informati= on
that could have been known at run time, even if it's only at the second
execution. it's about the #really# useful hints that the user/compiler
can give to the system so it works faster.

> take a look to this, it's good start to other documents about it:
> http://www.iro.umontreal.ca/~latendre/publications/index.html
mmm i should have read it more, but i was there already...
it's not utterly useful in our case.

> --Steve

then :

Kai Wetzel wrote:
> Hi,
>
> Yann Guidon wrote:
> [...]
> > Particularly, the problems of VLIW (like the consistency of the > > code, the violation of the coding rules, the enlargement
> > of the decoding units etc)
>
> Well, you have a point with the consistency/violation stuff, but
> using a software instruction rescedular it's not that bad as long
> as the supported instructions and overall arch. dont change.

what can be done for a "wide" F-CPU :
- P-4 way : a decoder/rulechecker located at the bus interface that
generates and possibly reschedules the instructions on the fly,
so they're nicely packed in the Icache and ready for straight execution.
or :

- RISC front-end, still located near the memory bus interface
(so it works when there's a Icache line fill). It generates =B5codes
for a wide "move-machine" (like the one that was previously inten= ded
for the F-CPU, after the first arch failed).

I lean towards 2 because the OOO nature is implicit and requires
almost no special hardware, it's close to Tomasulo's algo.
way #1 is good for a first attempt, it's simple to implement
but it gets hairy when we want more on-the-fly optimisations.
both could maybe get mixed, it would become really funny ;-)

> Regarding the decoding unit: IIRC it's supposed to be
> pretty tiny with VLIW - why do you say it's enlarged ?
i meant : when the chip decoded more instructions per cycle
(the instruction bus would be enlarged).

> > make its implementation as a UNIX CPU very difficult :
> What's a UNIX CPU, what's a Tetris CPU, ... ?  UNIX is
> not likely to be a very CPU bound itself, what matters
> is the speed of CPU-bound tasks, and they only make up
> an extremely tiny fraction of all the code running most
> UNIX systems, no ?

sorry again.
let's take for example a DSP and a i386 : the i386 can run a
Un*x-like because it provides a precise view of the system to
the user's task. When a protection error occurs, it can be located,
and at least it's detected. The task can be ended or the function
(ie screen or another i/o) can be emulated.

A DSP has no mean to protect the system from an hostile binary
file : you simply need to know a few things about it (ie :
interrupt table or system BIOS) and you can install a virus
or hang the system. Furthermore, since almost all DSP SW is
written for a very precise platform, the instruction set
is perfectly matched to the technology and it's called a
"throw-away ISA" CPU. SW compatibility is sometimes possible
at the source code level, not the binary level.
For the F-CPU and any line of server/workstation, this is not
possible to recompile absolutely everything all the time,
EVEN in a GNU/OpenSource world.

The are two differences that i think make a CPU eligible to
work in a Un*x server/workstation or any other
protected/multitask/multiuser OS.
i hope this is clear enough,
i don't want to elaborate more tonight :-)

> > look at Intel's crap.
> Well, it's crap - so what ? =3DO)
let's not do like that ;-)

> > "pure" VLIW is not suitable for such a project
> > as the F-CPU.
> Hmm, I don't know what you mean by "pure" - we could take 80= %
> of the FC0 ISA, add some and a little and get a "VLIW"
> instruction set (for FC1, 2, 3, whatever).  It's not pure, but > it's certainly a different approach :=B0>

you got the point.

"pure" VLIW is like what some research institutes did in the earl= y 80s :
put N instructions in fixed slots (1 slot/EU), send all the 256 bits
to the EU every cycle. like what you'd do with a microcoded machine,
but without the microcode ROM : you program directly the microcode
with the compiler.

The obvious problem, as i try to point, is the risk of offensive codes
that generate illegal opcode combinations that trash the machine (or
worse). Another problem that Nicolas pointed (and that IBM met)
is the high number of ports. there are workarounds, like split/duplicated reg sets, but we need to need it to do it. it either hard to code for,
or hard to hardwire.

> [...]
> > IA-64 uses a special information in the instruction word
> > to know how the instructions should be decoded. I don't know
> > how well it scales and i doubt that a very large version
> > is possible because one can't access more than 32 int registers > > at once. 12 instructions seems a practical maximum for a int-only=
> > code (the usual case when you don't forecast the weather).
> > For the F-CPU, there are 2x more registers so 24, or at least
> > 16 instructions per cycle "could" be feasible and codab= le
> > in a real program.
> Very optimistic...
so is the arithmetic ;-)

just take 32 registers, and 3-operands (2r1w) instructions.
this makes 32/3=3D11 instructions before you need more registers.
16 instructions is probably "optimistic" but could be coded
in a real application. Let's see : 64/3=3D21, some source
operands can be used twice (say, 4 or 5), so 24 instructions
would be "possible". of course it depends on the application,
we need pointers to memory, and 16 is more reasonable.
But before we need that, we'll have already 512-bit wide registers :-)
if this runs at 100MHz, this makes around 8GMOPS...
it could work for operations like signal processing (it's rather
easy to find ILP in these code kernels).

> [...]
> kai

well, now, let's sleep then see how Simili works.
it looks quite good, i want to be sure that it IS any good :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Thu Sep 28 01:10:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00370 for ; Thu, 28 Sep 2000 21:20:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:03 +0200 (MEST) Received: (qmail 1878 invoked by uid 0); 27 Sep 2000 22:06:21 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 27 Sep 2000 22:06:21 -0000 X-eGroups-Return: sentto-1101623-862-970092375-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 27 Sep 2000 22:06:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 22:06:15 -0000 Received: (qmail 10114 invoked from network); 27 Sep 2000 22:06:13 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Sep 2000 22:06:13 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 27 Sep 2000 22:06:12 -0000 Received: from f-cpu.org (nas2-222.ras.club-internet.fr [195.36.192.222]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29184 for ; Thu, 28 Sep 2000 00:06:05 +0200 (MET DST) Message-ID: <39D27E5E.480CF3E1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D233F8.B1D155A1@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 00:10:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 30ec5bba1f882f34ac7726d590b5cd82 Status: R X-Status: N hi again,

Nicolas Boulay wrote:
> A special difficulties is the number of port needed by register.
very, very true. but in my taste, more "silicon budget" should be= spent
on this "area".

duplicated sets are one way to solve this problem.
example : a F-CPU with 3*3 instructions per cycle,
there are 3 register sets per cluster with around
4 write ports and 7 write ports each. The dynamical
validity bits will indicate (after a first-run check)
what instructions can be put in which slot. this
ensures that the local sets need not much communication.
some added/hidden ports have to synchronize the values
of the different registers.

7r4w corresponds to 1 "special" instruction with 2 writes
and 3 reads, and 2 "normal" instructions with 1 write and
2 reads. i'm lazy enough not to reorganize the slots on
the fly :-)

> In the TI C64X DSP, there are 2 times 4 pipelines which access to diff= erent
> bank register. So 4 pipelines should be a maximum for simple things. T= o
> have an easy programming processor, we need that all the 4 pipelines a= re
> strictly equivalent (no special slot for memory access for exemple) > because gcc could became crazy.
sure. TI's experience is very interesting, compared to IA-64's attempts. But remember that the C6x and DSPs in general work in a "trusted"=
environment and their constraints differ a bit from our requirements
(stability even against hostile binaries in user mode).

> After that we could manage more packet of 4 instruction word (later).<= BR> > This packet can be encapsulate with few bit to define what there are i= n
> it, to speed up decode.

i suggest that this can be computed when the instructions are loaded
on the chip : decoded on the fly. The memory bandwidth is far lower than the decoding bandwidth, so we can decode once for all at that point.
that's what the Willamette does anyway, but not for decoding RISC instructi= ons
into VLIW packets.

> An other trick from TI DSP (C55) is its multisize instruction world > (8,16,24,32,48) to reduice the size of the code (they said 20% smaller=
> than ARM thumb code). Inside the core they use a 32 bit data bus. So > most of the time you need one click to run an instruction.

hey, that's a waste of decoding bandwidth. The C5x (or was it the C3x ?) have a 4-cycle clock with different decoding stages. pre-C6x TI DSPs
were a real pain in the ass, uneven architecture and crappy real performanc= e.
they're only good at coding/decoding low bitrate streams of compressed voic= e ;-)
they're used in DECT, or adapted DECT (even lower quality) for phone answer= ing
machines.

> So to resume, we could used a standart packet of 4 instructions with a= n
> head to describe the packet. Or this head could be like an opcode and<= BR> > describe a much larger packet, and just a bit discribe that this opcod= e
> is a "packet description" ?

there are reserved opcodes for this purpose. They can be considered as
"NOP" for architectures that don't support this feature.

> Does i dream ?
no.
only trying to anticipate.
and it's always better to anticipate -before- it happens ;-)

> nicO

> Yann Guidon a =E9crit :
> >

<big snip : you could have spared some bandwidth, thanks ;-)>

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS: j'attends ton RV pour rendre ton bouquin.
t'as raison, il est vraiment bien.
eGroups Sponsor=
3D""
From Yann Guidon Thu Sep 28 01:10:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00373 for ; Thu, 28 Sep 2000 21:20:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:04 +0200 (MEST) Received: (qmail 13882 invoked by uid 0); 27 Sep 2000 22:04:54 -0000 Received: from mu.egroups.com (208.50.99.218) by mx06.rz2.gmx.net with SMTP; 27 Sep 2000 22:04:54 -0000 X-eGroups-Return: sentto-1101623-863-970092376-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 27 Sep 2000 22:06:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 22:06:16 -0000 Received: (qmail 5437 invoked from network); 27 Sep 2000 22:06:16 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 27 Sep 2000 22:06:16 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 27 Sep 2000 22:06:16 -0000 Received: from f-cpu.org (nas2-222.ras.club-internet.fr [195.36.192.222]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29250 for ; Thu, 28 Sep 2000 00:06:11 +0200 (MET DST) Message-ID: <39D27E60.F83855A3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D22634.59DF71BD@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 00:10:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d519ef5acf88c89996b1a43cc026b371 Status: R X-Status: N hi !

jeff davies wrote:
> Toyoaki Sagawa wrote:
> Aha, someone with the same idea as me, but someone who has made more p= rogress
> than me. (scalable cpu, and keeping simple).

ain't it great ? ;-)
but i have the strange feeling, by reading the VHDL, that his core is a bit=
strange for the scheduling. hmmm... i should read it more closely.

> So I'd like a 360 bogomips cpu as a target . (or should that be CPUs -= perhaps
> 8 off Sayuris will do this??).
maybe you're making a mistake : MIPS and MOPS. DSPs usualy count in Million= Operations
per Second, and the x86 is well known to have a low MOPS/MIPS ratio, especi= ally
for DSP code. MMX enhanced the thing a bit, but it's still memory bound. OTOH, a 50MHz DSP can do a great job at decoding AC3 streams that consume a= lot
of time in inverse FFT and stream decoding : their structure is much more a= dapted
to this task. So the conclusion is : BogoMIPS has the name it holds because= it
doesn't mean anything.

ah, i feel better after this rant is out :-)


> I think that making a 256 bit simple cpu might give equivalent perform= ance
> to a complex 64 bit CPU, with lower clock rate (and hence power consum= ption)
> and for the same chip area (no out of order stuff, just keep it simple= ).
hey, why limit yourself to 256 bits ? the F-CPU has no upper limit :-PPP
> Personally I think that power usage will become a much bigger issue > very soon now.
I don't know. The latest chips have hit the wall, i think : they dissipate<= BR> REALLY too much power. Their clock frequency reach the frequency used for t= he
transmission of GSM phones (>900MHz) and they consume maybe 50 amperes t= hat
are concentrated on a few cm=B2. that is a physical limit. Another is the t= hermal
capacitance : i've heard that some overclocked CPUs generate so much heat that if they're shut down too quickly (the fan, too), the heat can't dissip= ate
anymore and it breaks/burns the chip or the package. Some people therefore = add
rechargeable batteries to the fan units so they still run even during a mai= n
power failure.

As long as we stay in the Pentium range of dissipation, still using
a rather simple cooling AND power regulation system, it's still bearable. Otherwise, it's a tweaking that may be necessary to rarely. I try to stay in the desktop range of CPUs, the investments for higher performance is
only needed/funded by Sony/PS-3 or the NSA ;-)

> I just took delivery of my Nokia 9110i which has a 486 in it, and yet = runs for
> 4 days on standby battery..
> .vey nice.
remember the first i486s (16 or 20 MHz ?) and they needed at least 10 Watts= ...
Silicon technology helps, too, in reducing the power.

> Apple with the G4 powerpc are following the lower clock rate, non-fan = cooled
> route, with a floating point engine that can execute 8 simultaneous fl= oating
> point operations.
A Cray-1 today, if put on silicon, would be even more powerful.
a single instruction will compute 64 operations.
The F-CPU is a SIMD machine, too, but not (yet) vectored.
there are thousands of ways to Rome but they lead to the same city.

> I'd love one, and might get one before long, especially with OS X (App= le
> Desktop on BSD). Just wondering aloud if JDK available for mac - proba= bly.
dunno. What would be the point of going from a rather proprietary architect= ure
(PC for my case) to another not-very-free architecture ?
i prefer to concentrate of this Fucking-CPU.

just for the chat,

> Jeff Davies
> jeff@llandre.freeserve.co.uk
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Kai Wetzel Thu Sep 28 02:19:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00376 for ; Thu, 28 Sep 2000 21:20:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:05 +0200 (MEST) Received: (qmail 14744 invoked by uid 0); 27 Sep 2000 22:25:28 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 27 Sep 2000 22:25:28 -0000 X-eGroups-Return: sentto-1101623-864-970093498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 27 Sep 2000 22:24:59 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 22:24:57 -0000 Received: (qmail 9404 invoked from network); 27 Sep 2000 22:24:57 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 22:24:57 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta3 with SMTP; 27 Sep 2000 22:24:57 -0000 Received: from welfen-netz.com [193.194.149.139] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Thu, 28 Sep 2000 00:23:40 +0200 Sender: kai@pop.gmx.net Message-ID: <39D28EA5.37BF41C@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D22634.59DF71BD@llandre.freeserve.co.uk> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 02:19:49 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (off topic) G4 Mac (was: Re: Sayuri from Japan) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3341ac826e4b5bea968210f83517f52e Status: R X-Status: N jeff davies wrote:
[...]
> Apple with the G4 powerpc are following the lower clock rate, non-fan = cooled
> route, with a floating
> point engine that can execute 8 simultaneous floating point operations= .
> I'd love one, and might get one before long, especially with OS X (App= le
> Desktop on BSD).
> Just wondering aloud if JDK available for mac - probably.

The G4 cube is nice, especially with the 22" Studio Display :=B0)
I'd love to get one when my current PC wears off two years
>from now or so - 15" will have to do, though, I guess <sigh>

kai
eGroups Sponsor=
3D""
From Yann Guidon Thu Sep 28 02:17:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00379 for ; Thu, 28 Sep 2000 21:20:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:06 +0200 (MEST) Received: (qmail 22157 invoked by uid 0); 27 Sep 2000 23:13:24 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 27 Sep 2000 23:13:24 -0000 X-eGroups-Return: sentto-1101623-865-970096384-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 27 Sep 2000 23:13:20 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 23:13:03 -0000 Received: (qmail 961 invoked from network); 27 Sep 2000 23:13:03 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Sep 2000 23:13:03 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 27 Sep 2000 23:13:03 -0000 Received: from f-cpu.org (nas3-77.aub.club-internet.fr [195.36.145.77]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA26295 for ; Thu, 28 Sep 2000 01:13:00 +0200 (MET DST) Message-ID: <39D28E11.DDAADB27@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D2542D.941A8F6E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 01:17:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Ultrasparc iii Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 248b449b36d4006bb87d8fff12b2abf1 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> http://www.aceshardware.com/Spades/read.php?article_id=116

ok, i read it : interesting !

"
Increasing cache sizes is not as effective as it used to be,
ILP is not as effective as it used to be, increasing clock frequency by
lengthening the pipeline is not as effective as it used to be,
and designs are becoming more complex.
"

fortunately, the F-CPU project has other ways to develop itself.

> About the Uiii and a little bit more, which suggest to have 3 slots for
> the VLIW and have 1 clock latency of the memory cache.
I have not found the real justification for 3 inst/clock.
i've read a similar study but it was academic and not based
on real measurements, but on simulations.

OTOH, i liked the part where the pipe depth estimation was decreased
by the conditional move instruction :-D (of course, it is an
/average/ cost, not immediate cost).

thanks again,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From "Albert Abramson" Thu Sep 28 01:14:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00382 for ; Thu, 28 Sep 2000 21:20:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:06 +0200 (MEST) Received: (qmail 21621 invoked by uid 0); 27 Sep 2000 23:19:14 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 27 Sep 2000 23:19:14 -0000 X-eGroups-Return: sentto-1101623-866-970096748-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ml.egroups.com with NNFMP; 27 Sep 2000 23:19:13 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 23:19:07 -0000 Received: (qmail 28842 invoked from network); 27 Sep 2000 23:19:07 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 27 Sep 2000 23:19:07 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta3 with SMTP; 27 Sep 2000 23:19:07 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000927231855.EYOL6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Wed, 27 Sep 2000 16:18:55 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000927231855.EYOL6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 16:14:45 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ab754e09d4445cf61e956dff0eef1a98 Status: R X-Status: N The reason I don't like proposing ideas to this list is because WHYGEE
always comes back and brings up some problem with "my idea." Exam= ple:

The problem with VLIW is the decode is too hard.
The problem with RISC is that it's hard to pipeline.
Why not just build a processor that issues 12 or 16 instruction per
processor?  The problem is that your design would suffer from a high c= lock
rate.

I'm not even sure how to articulate what's wrong with WHYGEE's remarks.
It's like saying don't increase the speed limit because people might stop t= o
read the sign.

The highest clock rate can only be attained on a processor that uses the compiler to statically schedule a small number of instructions to issue in<= BR> parallel, without putting any serious demands on the decode hardware,
without creating any obvious bottlenecks to performance.  I am perplex= ed
when I get a lengthy and inaccurate response from WHYGEE claiming that woul= d
create problems that another processor had.

SPARC and Alpha are both technically RISC.  One is fast, one is not.&n= bsp; SPARC
creates problems because of a large register file and complex decode. = Alpha
avoids that.

f-cpu creates needless bottlenecks, also.  The architecture itself is = more
complicated than it needs to be.  It makes assumptions that are just n= ot
true.

I don't like contributing even modest ideas to the group because it is
frustrating to communicate with WHYGEE.  The criticisms he makes are j= ust
not applicable.

----------
>From: Yann Guidon <whygee@f-cpu.org>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] vliw
>Date: Wed, Sep 27, 2000, 4:10 PM
>

> hi !
>
> jeff davies wrote:
>> Nicolas Boulay wrote:
>> > An other trick from TI DSP (C55) is its multisize instruction= world
>> > (8,16,24,32,48) to reduice the size of the code (they said 20= % smaller
>> > than ARM thumb code). Inside the core they use a 32 bit data = bus. So
>> > most of the time you need one click to run an instruction. >> Is this "idea" the intellectual property of TI? We ought= to stay away from
other
>> people's IP and develop our own ideas.
>> Jeff Davies
>
> true and false : ok for staying away from TI.
> false because CISC was not invented by TI ;-)
>
> then :
>
> Steve Van der Hoeven wrote:
>> On Wed, 27 Sep 2000, jeff davies wrote:
>> > Nicolas Boulay wrote:
> <snip>
>> we could imagine the instructions to be a stream of bits... no mor= e bites
>> boundaries. This could lead to even more compact code.
> yup, and how will that react when you cross a cache line AND cross a p= age
boundary
> AND trigger a TLB miss AND trigger a page refill from hdd ? :-)
> how will you jump, you'll need 5 more bits in the jump address...
> cool, back to the old'good CISC ages :-)
>
>> Once again we are talking about code compression...
> it was not about code compression, it was about "not wasting memo= ry bandwidth
> in a silly way". it was about the good sense of not encoding info= rmation
> that could have been known at run time, even if it's only at the secon= d
> execution. it's about the #really# useful hints that the user/compiler=
> can give to the system so it works faster.
>
>> take a look to this, it's good start to other documents about it:<= BR> >> http://www.iro.umontreal.ca/~latendre/publications/index.html > mmm i should have read it more, but i was there already...
> it's not utterly useful in our case.
>
>> --Steve
>
> then :
>
> Kai Wetzel wrote:
>> Hi,
>>
>> Yann Guidon wrote:
>> [...]
>> > Particularly, the problems of VLIW (like the consistency of t= he
>> > code, the violation of the coding rules, the enlargement
>> > of the decoding units etc)
>>
>> Well, you have a point with the consistency/violation stuff, but >> using a software instruction rescedular it's not that bad as long<= BR> >> as the supported instructions and overall arch. dont change.
>
> what can be done for a "wide" F-CPU :
> - P-4 way : a decoder/rulechecker located at the bus interface that > generates and possibly reschedules the instructions on the fly,
> so they're nicely packed in the Icache and ready for straight executio= n.
>
> or :
>
> - RISC front-end, still located near the memory bus interface
> (so it works when there's a Icache line fill). It generates =B5codes > for a wide "move-machine" (like the one that was previously = intended
> for the F-CPU, after the first arch failed).
>
> I lean towards 2 because the OOO nature is implicit and requires
> almost no special hardware, it's close to Tomasulo's algo.
> way #1 is good for a first attempt, it's simple to implement
> but it gets hairy when we want more on-the-fly optimisations.
> both could maybe get mixed, it would become really funny ;-)
>
>> Regarding the decoding unit: IIRC it's supposed to be
>> pretty tiny with VLIW - why do you say it's enlarged ?
> i meant : when the chip decoded more instructions per cycle
> (the instruction bus would be enlarged).
>
>> > make its implementation as a UNIX CPU very difficult :
>> What's a UNIX CPU, what's a Tetris CPU, ... ?  UNIX is
>> not likely to be a very CPU bound itself, what matters
>> is the speed of CPU-bound tasks, and they only make up
>> an extremely tiny fraction of all the code running most
>> UNIX systems, no ?
>
> sorry again.
> let's take for example a DSP and a i386 : the i386 can run a
> Un*x-like because it provides a precise view of the system to
> the user's task. When a protection error occurs, it can be located, > and at least it's detected. The task can be ended or the function
> (ie screen or another i/o) can be emulated.
>
> A DSP has no mean to protect the system from an hostile binary
> file : you simply need to know a few things about it (ie :
> interrupt table or system BIOS) and you can install a virus
> or hang the system. Furthermore, since almost all DSP SW is
> written for a very precise platform, the instruction set
> is perfectly matched to the technology and it's called a
> "throw-away ISA" CPU. SW compatibility is sometimes possible=
> at the source code level, not the binary level.
> For the F-CPU and any line of server/workstation, this is not
> possible to recompile absolutely everything all the time,
> EVEN in a GNU/OpenSource world.
>
> The are two differences that i think make a CPU eligible to
> work in a Un*x server/workstation or any other
> protected/multitask/multiuser OS.
> i hope this is clear enough,
> i don't want to elaborate more tonight :-)
>
>> > look at Intel's crap.
>> Well, it's crap - so what ? =3DO)
> let's not do like that ;-)
>
>> > "pure" VLIW is not suitable for such a project
>> > as the F-CPU.
>> Hmm, I don't know what you mean by "pure" - we could tak= e 80%
>> of the FC0 ISA, add some and a little and get a "VLIW" >> instruction set (for FC1, 2, 3, whatever).  It's not pure, bu= t
>> it's certainly a different approach :=B0>
>
> you got the point.
>
> "pure" VLIW is like what some research institutes did in the= early 80s :
> put N instructions in fixed slots (1 slot/EU), send all the 256 bits > to the EU every cycle. like what you'd do with a microcoded machine, > but without the microcode ROM : you program directly the microcode
> with the compiler.
>
> The obvious problem, as i try to point, is the risk of offensive codes=
> that generate illegal opcode combinations that trash the machine (or > worse). Another problem that Nicolas pointed (and that IBM met)
> is the high number of ports. there are workarounds, like split/duplica= ted
> reg sets, but we need to need it to do it. it either hard to code for,=
> or hard to hardwire.
>
>> [...]
>> > IA-64 uses a special information in the instruction word
>> > to know how the instructions should be decoded. I don't know<= BR> >> > how well it scales and i doubt that a very large version
>> > is possible because one can't access more than 32 int registe= rs
>> > at once. 12 instructions seems a practical maximum for a int-= only
>> > code (the usual case when you don't forecast the weather). >> > For the F-CPU, there are 2x more registers so 24, or at least=
>> > 16 instructions per cycle "could" be feasible and c= odable
>> > in a real program.
>> Very optimistic...
> so is the arithmetic ;-)
>
> just take 32 registers, and 3-operands (2r1w) instructions.
> this makes 32/3=3D11 instructions before you need more registers.
> 16 instructions is probably "optimistic" but could be coded<= BR> > in a real application. Let's see : 64/3=3D21, some source
> operands can be used twice (say, 4 or 5), so 24 instructions
> would be "possible". of course it depends on the application= ,
> we need pointers to memory, and 16 is more reasonable.
> But before we need that, we'll have already 512-bit wide registers :-)=
> if this runs at 100MHz, this makes around 8GMOPS...
> it could work for operations like signal processing (it's rather
> easy to find ILP in these code kernels).
>
>> [...]
>> kai
>
> well, now, let's sleep then see how Simili works.
> it looks quite good, i want to be sure that it IS any good :-)
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
From "Albert Abramson" Thu Sep 28 01:16:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00385 for ; Thu, 28 Sep 2000 21:20:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:08 +0200 (MEST) Received: (qmail 9424 invoked by uid 0); 27 Sep 2000 23:20:55 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 27 Sep 2000 23:20:55 -0000 X-eGroups-Return: sentto-1101623-867-970096834-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 27 Sep 2000 23:20:54 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 23:20:33 -0000 Received: (qmail 11607 invoked from network); 27 Sep 2000 23:20:33 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 27 Sep 2000 23:20:33 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta3 with SMTP; 27 Sep 2000 23:20:33 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000927232022.FBIE6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Wed, 27 Sep 2000 16:20:22 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000927232022.FBIE6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Sep 2000 16:16:12 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (off topic) G4 Mac (was: Re: Sayuri from Japan) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e62063e23c541a976eb04a1607c419ed Status: R X-Status: N I am about to install MacOS X Public Beta on this iMac.  If you don't = here
>from me again, you all know what to do.

--Maxx

----------
>From: Kai Wetzel <k.wetzel@welfen-netz.com>
>To: f-cpu@egroups.com
>Subject: [f-cpu] (off topic) G4 Mac (was: Re: Sayuri from Japan)
>Date: Wed, Sep 27, 2000, 5:19 PM
>

> jeff davies wrote:
> [...]
>> Apple with the G4 powerpc are following the lower clock rate, non-= fan cooled
>> route, with a floating
>> point engine that can execute 8 simultaneous floating point operat= ions.
>> I'd love one, and might get one before long, especially with OS X = (Apple
>> Desktop on BSD).
>> Just wondering aloud if JDK available for mac - probably.
>
> The G4 cube is nice, especially with the 22" Studio Display :=B0)=
> I'd love to get one when my current PC wears off two years
> from now or so - 15" will have to do, though, I guess <sigh>= ;
>
> kai
>
>
>
>
>
>
From "Toyoaki Sagawa" Thu Sep 28 01:37:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00388 for ; Thu, 28 Sep 2000 21:20:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:09 +0200 (MEST) Received: (qmail 22742 invoked by uid 0); 27 Sep 2000 23:37:58 -0000 Received: from fh.egroups.com (208.50.144.71) by mx19.rz2.gmx.net with SMTP; 27 Sep 2000 23:37:58 -0000 X-eGroups-Return: sentto-1101623-868-970097833-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 27 Sep 2000 23:37:56 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 23:37:12 -0000 Received: (qmail 28974 invoked from network); 27 Sep 2000 23:37:12 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 27 Sep 2000 23:37:12 -0000 Received: from unknown (HELO mail153.nifty.com) (202.248.37.146) by mta3 with SMTP; 27 Sep 2000 23:37:11 -0000 Received: from cfb5 by mail153.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id IAA00938 for ; Thu, 28 Sep 2000 08:37:10 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39D22634.59DF71BD@llandre.freeserve.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 08:37:26 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 31cfe1dd28ae1b98f362b57b5c2f8b32 Status: R X-Status: N
Hi,
jeff davies wrote:
> I think that a BIG problem with current CPUs is the sheer amount
> of heat they
> generate.

  On the other hand, I'm designing SH4 Linux machine.
SH4-mini : smallest. have 2 CF slot, costs under $200 (you need + SDRAM+CF
to run)
SH4-PCI : seems like RISC-Workstation. using V320USC as PCI bridge.
using Millenium2 VGA, PCI/USB for KB/MOUSE/etc, SCSI, Ethernet.
Clustered SH4 : 2 SH4 on single board, have IEEE1394, clustered with TCP/IP
on IEEE1394
if many people buy it and leave it on Internet, people will have
FreeSuperComputer on the net.
it's dream? no, MorphyOne now have 1600 order and it is under
manufacturing.(will out 2001/1)
the most important point is, heat/performance(FLOPS) of SH4. 1024 node will
have TFLOPS performance, but it doesn't need special cooling system.

> So I'd like a 360 bogomips cpu as a target . (or should that be
> CPUs - perhaps
> 8 off Sayuris will do this??).

meagering performance of Sayuri is very difficult. Now it runs at 75MHz, it
has no pipeline architecture, it can have small DSP inside. maybe 4
Sayuri(ver.1.0) will have better performance than Pentium2-450.(just a
simulation with simple code, if it is on cache)

> One very important thing, Toyoaki, are you going to publish your processor
> under the GPL
> (GNU Public licence?). I rather hope so.

Of cource, Sayuri is published under GPL. no patent, no license, no
foundation :-).

> Have you put one on an FPGA yet?

  Now doing it. post-rayout, it runs at 75MHz with XCV400-6. it requires
some modification for Xilinx specialized.

Toyoaki Sagawa

 From "Toyoaki Sagawa" Thu Sep 28 01:54:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00391 for ; Thu, 28 Sep 2000 21:20:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:10 +0200 (MEST) Received: (qmail 32511 invoked by uid 0); 27 Sep 2000 23:53:06 -0000 Received: from jk.egroups.com (208.50.144.83) by mx12.rz2.gmx.net with SMTP; 27 Sep 2000 23:53:06 -0000 X-eGroups-Return: sentto-1101623-869-970098827-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 27 Sep 2000 23:53:51 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 27 Sep 2000 23:53:46 -0000 Received: (qmail 10558 invoked from network); 27 Sep 2000 23:53:46 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Sep 2000 23:53:46 -0000 Received: from unknown (HELO mail156.nifty.com) (202.248.37.168) by mta2 with SMTP; 27 Sep 2000 23:53:46 -0000 Received: from cfb5 by mail156.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id IAA21249 for ; Thu, 28 Sep 2000 08:53:45 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39D27E60.F83855A3@f-cpu.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 08:54:01 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6980763dc1deed569c1c4eb545e0addb Status: R X-Status: N
Hi,

Yann Guidon wrote:
> but i have the strange feeling, by reading the VHDL, that his
> core is a bit
> strange for the scheduling. hmmm... i should read it more closely.

Sayuri has no scheduler for pipeline.
it just works as...

Instruction -> little logic and Decoder -> OE and WE to each register
in one clock.
"Move" is done by OE(output enable) and WE(write enable)
if you want to ADD R1 and R2 to R3,
Output enable R1 : Write enable ALU_BASE
Output enable R2 : Write enable ALU_ADD_IN
Output enable ALU_OUT : Write enable R3
it requires 3 clock. but it has no Pipeline , so there are no
control/branch hazard, no branch buffer, no pipeline register.
and many % of software is, normally, load and store and simple
caluculation.

what I thought before was, " what's the different between 20stage
pipeline/2GHz and 20 100MHz CPUs?"

anyway, good point of Sayuri is, these two.
gates / perfornance
easy to understand for many person :-)

Toyoaki Sagawa

 From Yann Guidon Thu Sep 28 03:44:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00394 for ; Thu, 28 Sep 2000 21:20:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:11 +0200 (MEST) Received: (qmail 30178 invoked by uid 0); 28 Sep 2000 00:40:08 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 28 Sep 2000 00:40:08 -0000 X-eGroups-Return: sentto-1101623-870-970101593-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 28 Sep 2000 00:40:06 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 00:39:52 -0000 Received: (qmail 27970 invoked from network); 28 Sep 2000 00:39:52 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 28 Sep 2000 00:39:52 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 28 Sep 2000 00:39:52 -0000 Received: from f-cpu.org (nas4-172.aub.club-internet.fr [195.36.145.172]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA16017 for ; Thu, 28 Sep 2000 02:39:48 +0200 (MET DST) Message-ID: <39D2A26D.1A029B9C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 02:44:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vhdl EDA again Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee43f6d8e72d8ca32d5eb2863904b202 Status: R X-Status: N hello,

so i've read apparently all the doc for Symphony EDA's Simili
and i find it pretty easy to use. it can complete Electric
when it comes to simulate a circuit.

pros :
- two commands to know : compile and simulate
- works almost "out of the box",
- pretty well VHDL-93 compliant
- comes with some useful libraries from a few vendors
   (but don't expect much)
- could be used to simulate some Execution Units together
- useful documentation (some english and typing errors
   but not heavy to read)

cons :
- not GPL
- i still don't know how to use the Tcl/tk waveform viewer
- Windows only

overall : not bad for a new "commercial" software.
i haven't tested it in depths but it would be a nice
engine competing with "true GNU" efforts. it seems ready
for the Linux port, i'll check if there's an opportunity
for more, here.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From jeff davies Thu Sep 28 02:40:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00397 for ; Thu, 28 Sep 2000 21:20:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:11 +0200 (MEST) Received: (qmail 23221 invoked by uid 0); 28 Sep 2000 00:38:44 -0000 Received: from hj.egroups.com (208.50.99.212) by mx06.rz2.gmx.net with SMTP; 28 Sep 2000 00:38:44 -0000 X-eGroups-Return: sentto-1101623-871-970101609-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hj.egroups.com with NNFMP; 28 Sep 2000 00:40:17 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 00:40:09 -0000 Received: (qmail 15417 invoked from network); 28 Sep 2000 00:40:08 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 28 Sep 2000 00:40:08 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 28 Sep 2000 00:40:08 -0000 Received: from modem-41.ununnilium.dialup.pol.co.uk ([62.136.75.41] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13eRk6-0004oV-00 for f-cpu@egroups.com; Thu, 28 Sep 2000 01:40:07 +0100 Sender: root@pop.gmx.net Message-ID: <39D29365.7F0BAA45@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D22634.59DF71BD@llandre.freeserve.co.uk> <39D27E60.F83855A3@f-cpu.org> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 01:40:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: feb60927cc57e2bf620142106e4e87cb Status: R X-Status: N Yann Guidon wrote:

>
> i prefer to concentrate of this Fucking-CPU.
>

The unofficial version of what FCPU stands for.

Jeff davies


 From Yann Guidon Thu Sep 28 03:47:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00400 for ; Thu, 28 Sep 2000 21:20:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:12 +0200 (MEST) Received: (qmail 13515 invoked by uid 0); 28 Sep 2000 00:43:03 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 28 Sep 2000 00:43:03 -0000 X-eGroups-Return: sentto-1101623-872-970101775-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 28 Sep 2000 00:43:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 00:42:55 -0000 Received: (qmail 7906 invoked from network); 28 Sep 2000 00:42:55 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 28 Sep 2000 00:42:55 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 28 Sep 2000 00:42:54 -0000 Received: from f-cpu.org (nas4-172.aub.club-internet.fr [195.36.145.172]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA27705 for ; Thu, 28 Sep 2000 02:42:52 +0200 (MET DST) Message-ID: <39D2A324.D50E1C87@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D22634.59DF71BD@llandre.freeserve.co.uk> <39D27E60.F83855A3@f-cpu.org> <39D29365.7F0BAA45@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 02:47:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 51b4f9ec99de116e3ff9f9d6c2fab0f4 Status: R X-Status: N jeff davies wrote:
> Yann Guidon wrote:
> > i prefer to concentrate of this Fucking-CPU.
> The unofficial version of what FCPU stands for.

:-)

you found the secret already...

> Jeff davies
>

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From jeff davies Thu Sep 28 02:48:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00403 for ; Thu, 28 Sep 2000 21:20:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:12 +0200 (MEST) Received: (qmail 6023 invoked by uid 0); 28 Sep 2000 00:48:20 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 28 Sep 2000 00:48:20 -0000 X-eGroups-Return: sentto-1101623-873-970102096-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 28 Sep 2000 00:48:17 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 00:48:16 -0000 Received: (qmail 16365 invoked from network); 28 Sep 2000 00:48:15 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 28 Sep 2000 00:48:15 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta2 with SMTP; 28 Sep 2000 00:48:15 -0000 Received: from modem-41.ununnilium.dialup.pol.co.uk ([62.136.75.41] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13eRrw-0005FY-00 for f-cpu@egroups.com; Thu, 28 Sep 2000 01:48:13 +0100 Sender: root@pop.gmx.net Message-ID: <39D29550.38C992C@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 01:48:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bccaa1c3183815655b73daa45b10acb3 Status: R X-Status: N Toyoaki Sagawa wrote:

> Hi,
> jeff davies wrote:
> > I think that a BIG problem with current CPUs is the sheer amount
> > of heat they
> > generate.
>
>   On the other hand, I'm designing SH4 Linux machine.
> SH4-mini : smallest. have 2 CF slot, costs under $200 (you need + SDRAM+CF
> to run)
> SH4-PCI : seems like RISC-Workstation. using V320USC as PCI bridge.
>  using Millenium2 VGA, PCI/USB for KB/MOUSE/etc, SCSI, Ethernet.
> Clustered SH4 : 2 SH4 on single board, have IEEE1394, clustered with TCP/IP
> on IEEE1394
>  if many people buy it and leave it on Internet, people will have
> FreeSuperComputer on the net.
>  it's dream? no, MorphyOne now have 1600 order and it is under
> manufacturing.(will out 2001/1)
>  the most important point is, heat/performance(FLOPS) of SH4. 1024 node will
> have TFLOPS performance, but it doesn't need special cooling system.
>

Wow

>
> > So I'd like a 360 bogomips cpu as a target . (or should that be
> > CPUs - perhaps
> > 8 off Sayuris will do this??).
>
>  meagering performance of Sayuri is very difficult. Now it runs at 75MHz, it
> has no pipeline architecture, it can have small DSP inside. maybe 4
> Sayuri(ver.1.0) will have better performance than Pentium2-450.(just a
> simulation with simple code, if it is on cache)
>

Sounds like Sayuri is currently (per core) about 100 bogoMIPS? (so 4 of current
level meets
target easily). Hold on a minute... the XCV4000 isn't a huge FPGA is it?? So
you could fit
a lot on an ASIC.

>
> > One very important thing, Toyoaki, are you going to publish your processor
> > under the GPL
> > (GNU Public licence?). I rather hope so.
>
>  Of cource, Sayuri is published under GPL. no patent, no license, no
> foundation :-).
>

Hoorah

>
> > Have you put one on an FPGA yet?
>
>   Now doing it. post-rayout, it runs at 75MHz with XCV400-6. it requires
> some modification for Xilinx specialized.
>
> Toyoaki Sagawa
>

Jeff Davies

 From "Marco Al" Thu Sep 28 04:44:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00406 for ; Thu, 28 Sep 2000 21:20:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:13 +0200 (MEST) Received: (qmail 26303 invoked by uid 0); 28 Sep 2000 02:36:04 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 28 Sep 2000 02:36:04 -0000 X-eGroups-Return: sentto-1101623-874-970108560-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 28 Sep 2000 02:36:03 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 02:36:00 -0000 Received: (qmail 15711 invoked from network); 28 Sep 2000 02:35:59 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 28 Sep 2000 02:35:59 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 28 Sep 2000 02:35:59 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id EAA02434 for ; Thu, 28 Sep 2000 04:35:58 +0200 (METDST) Message-ID: <007401c028f6$11883960$29e65982@student.utwente.nl> To: References: <39D20CA6.650C8EF3@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 04:44:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fdbd7a8f9b36dffe4f9c32ce5d6633cc Status: R X-Status: N Subject: [f-cpu] VLIW ...

> and i was thinking about Albert's answer.
> He probably believes that we don't care about him,
> which is false. Particularly, the problems
> of VLIW (like the consistency of the code,

Consistency??

> the violation of the coding rules

How is that a problem? Building scheduling rules into a compiler is easier
than building it into hardware whichever way you look at it. Or do you mean
>from a security point of view?

>, the enlargement
> of the decoding units

Why would a X instruction VLIW decoder be larger than the decoders in a X
way superscalar machine?

> etc) make its implementation
> as a UNIX CPU very difficult : look at Intel's crap.

Oh come now, they may have dropped the ball on the first implementation...
but both HP and Intel put a lot of money and faith into EPIC, after HP had
already been doing a lot of research into it for a long time, I wouldnt
count it out just yet on the evidence of the first generation.

> are rather inefficient and don't match the F-CPU
> requirements of scalability and longevity.

Scalability and longevity are overrated. I dont mind recompiling Linux, and
theres always binary translation (which does not have to be slow with the
right design according to IBM, http://www.research.ibm.com/vliw/). I think
HP has also said future EPIC processors would be backwards compatible via
binary translation.

> IA-64 uses a special information in the instruction word
> to know how the instructions should be decoded. I don't know
> how well it scales and i doubt that a very large version
> is possible because one can't access more than 32 int registers
> at once. 12 instructions seems a practical maximum for a int-only
> code (the usual case when you don't forecast the weather).
> For the F-CPU, there are 2x more registers so 24, or at least
> 16 instructions per cycle "could" be feasible and codable
> in a real program.

How do you intend to extract those 16 IPC? Wouldnt you need a huge
instruction window with standard RISC? And the majority of those
instructions would be speculative of course, a book keeping nightmare.

> Now, if this can be done harmlessly by HW on the fly, why would
> we give hints ? they shift to a higher level, because the amount
> of bandwidth they take is revelant.

With a disposable ISA you dont need hints like that at all of course :) (it
would all be implicit in the instruction stream)

Marco

 From "Toyoaki Sagawa" Thu Sep 28 13:54:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00439 for ; Thu, 28 Sep 2000 21:20:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:22 +0200 (MEST) Received: (qmail 19454 invoked by uid 0); 28 Sep 2000 11:54:19 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 28 Sep 2000 11:54:19 -0000 X-eGroups-Return: sentto-1101623-875-970142048-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 28 Sep 2000 11:54:18 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 11:54:08 -0000 Received: (qmail 13509 invoked from network); 28 Sep 2000 11:54:08 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 28 Sep 2000 11:54:08 -0000 Received: from unknown (HELO mail152.nifty.com) (202.248.37.145) by mta3 with SMTP; 28 Sep 2000 11:54:07 -0000 Received: from cfb5 by mail152.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA25463 for ; Thu, 28 Sep 2000 20:54:06 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <39D29550.38C992C@llandre.freeserve.co.uk> Importance: Normal From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 20:54:22 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3cdcf27348790f54591e3f275d9c0b6c Status: R X-Status: N
Hi,

jeff davis wrote:
> Sounds like Sayuri is currently (per core) about 100 bogoMIPS?

Sorry this is my loadmap, now Sayuri is version 0.2 .
Sayuri 1.0 will have multi mac unit for double(64bit float), etc
but even now, currently , compare with Pentium instruction and Sayuri
Instruction,
ex: 1+2+3+4+5+...
PentiumII assembler
00401038   mov         eax,dword ptr [ebp-4]
0040103B   add         eax,1        //(eax stall)
0040103E   mov         dword ptr [ebp-4],eax   //(eax stall)
00401041   cmp         dword ptr [ebp-4],0Bh  //memory stall
00401045   jge         main+42h (00401052)
00401047   mov         ecx,dword ptr [ebp-8]
0040104A   add         ecx,dword ptr [ebp-4]  //ecx stall
0040104D   mov         dword ptr [ebp-8],ecx // add control stall
00401050   jmp         main+28h (00401038)
this is not so faster than Sayuri(has no stall condition)

> target easily). Hold on a minute... the XCV4000 isn't a huge FPGA
> is it?? So you could fit a lot on an ASIC.

  Now Sayuri needs 853 Slices of Virtex(71% of XCV100). Single Sayuri
core(ver 0.2, now) can be mapped into XCV100-pq240.(even XCV50 with some
effort)
  maybe with Xilinx's distributed RAM etc, XCV400 can contain 4
Sayuri(ver1.0?) and enough volume of cache.
How many core can be fit in ASIC :-)

Toyoaki Sagawa

 From "Marco Al" Thu Sep 28 17:01:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00469 for ; Thu, 28 Sep 2000 21:20:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:30 +0200 (MEST) Received: (qmail 32630 invoked by uid 0); 28 Sep 2000 15:54:23 -0000 Received: from hp.egroups.com (208.50.99.201) by mx12.rz2.gmx.net with SMTP; 28 Sep 2000 15:54:23 -0000 X-eGroups-Return: sentto-1101623-876-970156420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 28 Sep 2000 15:54:09 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 15:53:39 -0000 Received: (qmail 21413 invoked from network); 28 Sep 2000 15:53:39 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Sep 2000 15:53:39 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 28 Sep 2000 15:53:39 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id RAA02621 for ; Thu, 28 Sep 2000 17:53:34 +0200 (METDST) Message-ID: <000901c02965$7ee81ab0$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 17:01:00 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b1158e9d02ac2944356cf90bbe9cca82 Status: R X-Status: N From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>

> ex: 1+2+3+4+5+...
> PentiumII assembler
> 00401038   mov         eax,dword ptr [ebp-4]
> 0040103B   add         eax,1        //(eax stall)
> 0040103E   mov         dword ptr [ebp-4],eax   //(eax stall)
> 00401041   cmp         dword ptr [ebp-4],0Bh  //memory stall
> 00401045   jge         main+42h (00401052)
> 00401047   mov         ecx,dword ptr [ebp-8]
> 0040104A   add         ecx,dword ptr [ebp-4]  //ecx stall
> 0040104D   mov         dword ptr [ebp-8],ecx // add control stall
> 00401050   jmp         main+28h (00401038)

Why would you go through memory at each iteration?

Marco

 From Yann Guidon Thu Sep 28 19:50:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00475 for ; Thu, 28 Sep 2000 21:20:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:32 +0200 (MEST) Received: (qmail 16782 invoked by uid 0); 28 Sep 2000 16:48:03 -0000 Received: from f19.egroups.com (208.50.99.238) by mx19.rz2.gmx.net with SMTP; 28 Sep 2000 16:48:03 -0000 X-eGroups-Return: sentto-1101623-878-970159678-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 28 Sep 2000 16:48:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 16:47:54 -0000 Received: (qmail 12298 invoked from network); 28 Sep 2000 16:46:14 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 28 Sep 2000 16:46:14 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 28 Sep 2000 16:46:13 -0000 Received: from f-cpu.org (nas1-129.ras.club-internet.fr [195.36.192.129]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA02028 for ; Thu, 28 Sep 2000 18:46:07 +0200 (MET DST) Message-ID: <39D384E9.A0762301@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 18:50:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c2c5c9b7f36e0f851054ad64870fbd28 Status: R X-Status: N hi !

Toyoaki Sagawa wrote:
> Hi,
>
> jeff davis wrote:
> > Sounds like Sayuri is currently (per core) about 100 bogoMIPS?
>
>  Sorry this is my loadmap, now Sayuri is version 0.2 .
>  Sayuri 1.0 will have multi mac unit for double(64bit float), etc
>  but even now, currently , compare with Pentium instruction and Sayuri
> Instruction,
> ex: 1+2+3+4+5+...
> PentiumII assembler
> 00401038   mov         eax,dword ptr [ebp-4]
> 0040103B   add         eax,1        //(eax stall)
> 0040103E   mov         dword ptr [ebp-4],eax   //(eax stall)
> 00401041   cmp         dword ptr [ebp-4],0Bh  //memory stall
> 00401045   jge         main+42h (00401052)
> 00401047   mov         ecx,dword ptr [ebp-8]
> 0040104A   add         ecx,dword ptr [ebp-4]  //ecx stall
> 0040104D   mov         dword ptr [ebp-8],ecx // add control stall
> 00401050   jmp         main+28h (00401038)
>  this is not so faster than Sayuri(has no stall condition)

sorry but you're completely wrong, even though it doesn't matter that much.

some technical details : the Pentium II is not similar to a normal Pentium
that packed instructions by 2. The PII has no stall condition at the decoding
stage because the registers are renamed on the fly. the grouping rule
is "4-1-1" and a memory write can only be placed at the first slot (it generates
2 u-ops).

something else : this code above is far from optimised. You obviously compiled
it with something like GCC, but OTOH you made your Sayuri code example by hand.
this is not what i call fair ;-)

I hope that you understand that i do simply remark flaws in the arguments, not
in the architecture itself. one has to be very sure and prove what he says,
otherwise the argumentation has no value. You would be flamed if you posted
that on comp.arch ;-)

ok i'll try (not garantied) to optimize the algo for the PII.
remember that it has more than 4 registers, but not much more in fact.
you can win a lot with a good register allocation. This is particularly
important for the x86. I hope that it will destroy your faith in compilers :-)

what your algo does is, for each iteration, add a value to another, and increment the
added value. This obviously has a lot of dependencies, so i'll unroll the loop
once or twice.

eax : inc1
ebx : sum1
ecx : inc2
edx : sum2
esi : inc3
edi : sum3
ebp : loop counter

entry :
pusha ; we have to save ebp and everything
mov eax,1
xor ebx,ebx
mov ecx,2
xor edx,edx
mov esi,3
xor edi,edi
mov ebp,100 ; number of iterations
; we won't use ebp for the frame pointer
; so it can serve other purposes

loop:
; slot 1 :
   add ebx,eax
   add edx,ecx
   add edi,esi
; slot 2 :
   add eax,3
   add ecx,3
   add esi,3
; last slot :
   sub ebp,3
   jns loop

; finish up, combine the results :
add ebx,edx
add ebx,esi

; last bits :
test ebp,ebp
jz exit
inc ebp
add ebx,eax

test ebp,ebp
jz exit
add ebx,ecx

; ebx contains the result.

exit:
popa ; restore

look, my inner loop has almost the same number of instructions
as yours and i do 3 times more :-) never trust compilers.
i'm used to the NASM syntax, not to as's fuzzy syntax.
the idea is that we have 3 independent threads of execution.
we increment 3 separate threads because they can be proved
to be independent.

The above code is not garantied perfect but gives you a hint
of the kind of optimisation that is used today. There are people
out who that can do even better, see comp.arch and comp.lang.asm.x86.
Of course, you can speed this up incredibly by using this formula :
y=(x*(x-1))/2 but that's not the point, right ? ;-)


> > target easily). Hold on a minute... the XCV4000 isn't a huge FPGA
> > is it?? So you could fit a lot on an ASIC.
>
>   Now Sayuri needs 853 Slices of Virtex(71% of XCV100). Single Sayuri
> core(ver 0.2, now) can be mapped into XCV100-pq240.(even XCV50 with some effort)
>   maybe with Xilinx's distributed RAM etc, XCV400 can contain 4
>   Sayuri(ver1.0?) and enough volume of cache. How many core can be fit in ASIC :-)

"it depends on the size" ;-)

Anyway, i hope that you'll have fun and success with Sayuri.
Pipelining it will certainly make it run faster.

Last question, i hope you won't make fun of me for my ignorance,
what does "Sayuri" means ?

regards,
> Toyoaki Sagawa
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Thu Sep 28 19:50:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00478 for ; Thu, 28 Sep 2000 21:20:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:34 +0200 (MEST) Received: (qmail 30281 invoked by uid 0); 28 Sep 2000 16:48:13 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 28 Sep 2000 16:48:13 -0000 X-eGroups-Return: sentto-1101623-877-970159678-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ch.egroups.com with NNFMP; 28 Sep 2000 16:48:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 16:47:52 -0000 Received: (qmail 12179 invoked from network); 28 Sep 2000 16:46:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 28 Sep 2000 16:46:12 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 28 Sep 2000 16:46:12 -0000 Received: from f-cpu.org (nas1-129.ras.club-internet.fr [195.36.192.129]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA18892 for ; Thu, 28 Sep 2000 18:46:08 +0200 (MET DST) Message-ID: <39D384E7.93CEB725@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D20CA6.650C8EF3@f-cpu.org> <007401c028f6$11883960$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 18:50:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 99c1b6e6fc3e169c1fb48f8788e756f4 Status: R X-Status: N hello,

Marco Al wrote:
> Subject: [f-cpu] VLIW ...
> > Particularly, the problems of VLIW (like the consistency of the code,
> Consistency??
i'm concerned by the immunity to "hostile software"
and the integrity of the protection mechanisms.
The respect of the coding conventions is one part of this :
how will the HW manage if two parallel instructions
write to the same register ? Does it fry the chip ?
if the last is true, then you shouldn't run Linux on it.

> > the violation of the coding rules
> How is that a problem? Building scheduling rules into a compiler is easier
> than building it into hardware whichever way you look at it. Or do you mean
> from a security point of view?

both. and making a "good" compiler is not as easy as you seem to think.
of course it's easy to make a toy compiler. But a solid one, that can optimize
correctly a great variety of codes, is a tough task.

> >, the enlargement of the decoding units
> Why would a X instruction VLIW decoder be larger than the decoders in a X
> way superscalar machine?

read the other post : i meant "it decodes more instructions during every cycle".

> > etc) make its implementation
> > as a UNIX CPU very difficult : look at Intel's crap.
> Oh come now, they may have dropped the ball on the first implementation...
> but both HP and Intel put a lot of money and faith into EPIC, after HP had
> already been doing a lot of research into it for a long time, I wouldnt
> count it out just yet on the evidence of the first generation.
alright, alright. HP already ships native IA-64 chips in their servers.
does that mean that Intel's promises are kept ? :-)

> > are rather inefficient and don't match the F-CPU
> > requirements of scalability and longevity.
> Scalability and longevity are overrated.
of course, you write a new compiler every day.

> I dont mind recompiling Linux, and
> theres always binary translation (which does not have to be slow with the
> right design according to IBM, http://www.research.ibm.com/vliw/). I think
> HP has also said future EPIC processors would be backwards compatible via
> binary translation.
OK for binary translation, but does that spare the effort of designing a new
instruction set all the time ?...

> > IA-64 uses a special information in the instruction word
> > to know how the instructions should be decoded. I don't know
> > how well it scales and i doubt that a very large version
> > is possible because one can't access more than 32 int registers
> > at once. 12 instructions seems a practical maximum for a int-only
> > code (the usual case when you don't forecast the weather).
> > For the F-CPU, there are 2x more registers so 24, or at least
> > 16 instructions per cycle "could" be feasible and codable
> > in a real program.
>
> How do you intend to extract those 16 IPC?
with my head, some experience, a lot of good sense and GNL.
with GNL and those 64 registers, i'd have done it for a while :
i have a computation kernel that requires a lot of computations
and i have broken down it into 6 parallel calculations. each calculation
can use 3 instructions per cycle, so it would give 18 instructions (peak)
per cycle if such a large CPU was possible.

> Wouldnt you need a huge
> instruction window with standard RISC? And the majority of those
> instructions would be speculative of course, a book keeping nightmare.
i don't use speculative instructions in the computation kernels :
it would waste a lot of ressources. What's the point of computing
something if it gets discarded ??? i programmed the above kernel
(look at http://www.mime.up8.edu/~whygee/memoire/index.html)
on Pentium 200 MMX and PII. they are bound by the decoding unit,
so each instruction that gets decoded must be the right one.
If you decode useless instructions, your performance drops.

> > Now, if this can be done harmlessly by HW on the fly, why would
> > we give hints ? they shift to a higher level, because the amount
> > of bandwidth they take is revelant.
> With a disposable ISA you dont need hints like that at all of course :) (it
> would all be implicit in the instruction stream)

and who would design the "disposable" ISA everyday ?
how would you teach each version to each newcomer ?
What would you say to people who want to use old versions ?
"sorry, i have thrown this one away, have a fun reverse-engineering"

remember that for industrial products, longevity is a critical
matter. have you heard about those companies that store
spare electronic components in liquid nitrogen for the next 30 years
because if one of their devices has a failure, they won't find a replacement ?
How can you convince an industrial company to give money for building a CPU
project and say, in a ice-cold voice : "i'll throw it away in two years" ?

Of course ISAs need to evolve but we have to respect the continuity of
the efforts, or else it does not look credible. Damn, the MIPS
(as well as ALPHA, SPARC, Power etc...) ISA has grown up and is still working
after years of development. it was designed with this goal in mind.
So what's wrong with longevity, when it's designed with this goal in mind ?

of course, x86 is the best counter-example and it was not designed for
longevity.

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jecel Assumpcao Jr Thu Sep 28 21:28:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00481 for ; Thu, 28 Sep 2000 21:20:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Sep 2000 21:20:36 +0200 (MEST) Received: (qmail 327 invoked by uid 0); 28 Sep 2000 18:56:51 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 28 Sep 2000 18:56:51 -0000 X-eGroups-Return: sentto-1101623-879-970167404-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 28 Sep 2000 18:56:51 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 18:56:42 -0000 Received: (qmail 10482 invoked from network); 28 Sep 2000 18:56:42 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 28 Sep 2000 18:56:42 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 28 Sep 2000 18:56:40 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id QAA13558 for ; Thu, 28 Sep 2000 16:04:37 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39D20CA6.650C8EF3@f-cpu.org> <007401c028f6$11883960$29e65982@student.utwente.nl> <39D384E7.93CEB725@f-cpu.org> In-Reply-To: <39D384E7.93CEB725@f-cpu.org> Message-Id: <00092816405802.00406@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 16:28:51 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] fixed ISA (was: VLIW ...) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 94c0487354c6c1e0a580ac67ace22939 Status: R X-Status: N Yann,

I don't understand your arguments against a changing ISA for VLIWs
given the possibility of binary translation. Consider the two Transmeta
chips: each has a different internal ISA, but both run exactly the same
user binaries (x86). It seems to be working great, so what is your
problem with this?

For my own project, I chose a simple external ISA (just four
instructions: push literal, send message to top of stack, send message
to self and non local return) but can vary the internal ISA
considerably.

User code can never be "hostile software" and force the generation of
invalid code. Only a buggy compiler can do that. But I consider the
compiler as an integral part of the chip and see this as no different
than a buggy decoder circuit that would allow certain instructions to
have multiple writes to the same register.

-- Jecel
eGroups Sponsor
From "Marco Al" Thu Sep 28 22:29:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01658 for ; Fri, 29 Sep 2000 02:22:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:40 +0200 (MEST) Received: (qmail 32404 invoked by uid 0); 28 Sep 2000 20:21:06 -0000 Received: from mw.egroups.com (208.50.144.94) by mx12.rz2.gmx.net with SMTP; 28 Sep 2000 20:21:06 -0000 X-eGroups-Return: sentto-1101623-880-970172442-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 28 Sep 2000 20:20:52 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 20:20:42 -0000 Received: (qmail 22272 invoked from network); 28 Sep 2000 20:20:42 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 28 Sep 2000 20:20:42 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 28 Sep 2000 20:20:41 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id WAA10958 for ; Thu, 28 Sep 2000 22:20:40 +0200 (METDST) Message-ID: <000f01c0298a$cf712ba0$29e65982@student.utwente.nl> To: References: <39D20CA6.650C8EF3@f-cpu.org> <007401c028f6$11883960$29e65982@student.utwente.nl> <39D384E7.93CEB725@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 22:29:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 63f520dc6631f3ad3747492b6621976d Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> both. and making a "good" compiler is not as easy as you seem to think.
> of course it's easy to make a toy compiler. But a solid one, that can
optimize
> correctly a great variety of codes, is a tough task.

I dont think its easy, I dont think designing superscalar machines with a
hardware scheduler optimal for a great variety of codes is easy either.

> > > are rather inefficient and don't match the F-CPU
> > > requirements of scalability and longevity.
> > Scalability and longevity are overrated.
> of course, you write a new compiler every day.

No more than I design a new superscalar processor every day.

You spend less time on hardware and more time on software.

> OK for binary translation, but does that spare the effort of designing a
new
> instruction set all the time ?...

No but it saves you the effort from trying to build hardware to extract ever
more parallelism on the fly from code written for an existing instruction
set... compare that to writing software to do the same off-line.

> > How do you intend to extract those 16 IPC?
> with my head, some experience, a lot of good sense and GNL.
> with GNL and those 64 registers, i'd have done it for a while :
> i have a computation kernel that requires a lot of computations
> and i have broken down it into 6 parallel calculations. each calculation
> can use 3 instructions per cycle, so it would give 18 instructions (peak)
> per cycle if such a large CPU was possible.

Extracting parallelism from a high level description, numerical code at
that, isnt really what I meant. Extracting it on the fly from existing FCPU
code for superscalar execution is what I meant.

> > Wouldnt you need a huge
> > instruction window with standard RISC? And the majority of those
> > instructions would be speculative of course, a book keeping nightmare.
> i don't use speculative instructions in the computation kernels :
> it would waste a lot of ressources. What's the point of computing
> something if it gets discarded ?

I dont see the relevance, didnt you call it a UNIX CPU? You will be hard
pressed to find 16 consecutive instructions without one branch, the average
is probably closer to 2, in the tasks a "UNIX CPU" would be commonly
performing. Let alone instructions which could be executed in parallel.

> > With a disposable ISA you dont need hints like that at all of course :)
(it
> > would all be implicit in the instruction stream)
>
> and who would design the "disposable" ISA everyday ?

You dont design a processor every day.

> how would you teach each version to each newcomer ?

Simple, since the fraction of them who care about assembly is so far below 0
to not be commercially interesting... you dont. (ohhh Im gonna get flamed
for that :)

> What would you say to people who want to use old versions ?

Well for one, binary translation goes 2 ways.... but as you say

"We have to run the application, which will recognize the computer
configuration with special instructions, and then calibrate the loop counts
or modify the pointer updates. This is almost the same process as loading a
dynamic library..."

If you wanted to you could design a common ISA from which all the versions
of the processors could efficiently translate, ala Transmeta although x86 is
not really ideal. Then have fat binaries for applications which want to have
specific architecture optimisations, which could always fall back to the
relatively efficient RISC code for translation on other processors.

Would give the assembly hackers an option too.

> remember that for industrial products, longevity is a critical
> matter. have you heard about those companies that store
> spare electronic components in liquid nitrogen for the next 30 years
> because if one of their devices has a failure, they won't find a
replacement ?

And no matter what you do you cant design an ISA to satisfy people like
that, source-code compatibility is not enough... not on high level and not
on the machine code level. All they want is a single processor which remains
exactly the same till the end of days.

> How can you convince an industrial company to give money for building a
CPU
> project and say, in a ice-cold voice : "i'll throw it away in two years" ?

If I was that poor at marketing I probably should not be talking to them :)
How about "I will emulate it in 2 years at near native speed"?

> Of course ISAs need to evolve but we have to respect the continuity of
> the efforts, or else it does not look credible. Damn, the MIPS
> (as well as ALPHA, SPARC, Power etc...) ISA has grown up and is still
working
> after years of development. it was designed with this goal in mind.
> So what's wrong with longevity, when it's designed with this goal in mind
?

Nothing, but people are starting to go to ridiculous lengths to get wider
and wider superscalar issue machines for smaller and smaller increments in
effective CPI... people are researching value predictors for instance, if
you dont like speculative execution you should see why I think this is a bad
sign.

I think trace's are going in the right direction, but since translation is a
pretty small task you might as well save yourself the headache of putting it
in hardware AFAICS.

Marco

 From Steve Van der Hoeven Thu Sep 28 22:46:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01664 for ; Fri, 29 Sep 2000 02:22:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:42 +0200 (MEST) Received: (qmail 27891 invoked by uid 0); 28 Sep 2000 20:47:06 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 28 Sep 2000 20:47:06 -0000 X-eGroups-Return: sentto-1101623-881-970174018-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 28 Sep 2000 20:47:05 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 20:46:58 -0000 Received: (qmail 23526 invoked from network); 28 Sep 2000 20:46:57 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Sep 2000 20:46:57 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta2 with SMTP; 28 Sep 2000 20:46:57 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id PAA19580 for ; Thu, 28 Sep 2000 15:46:57 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <00092816405802.00406@gandalf> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 15:46:56 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fixed ISA (was: VLIW ...) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 943fd4a20635c982c7861d8deddcfc93 Status: R X-Status: N

On Thu, 28 Sep 2000, Jecel Assumpcao Jr wrote:

> User code can never be "hostile software" and force the generation of
> invalid code.

Viruses... they use the code morphing technics to generate their
reproduction code on the fly and to hide them... I think they can be
hostile...

I don't really know all the issue about virus and so on... It's just an
idea.


> Only a buggy compiler can do that. But I consider the
> compiler as an integral part of the chip and see this as no different
> than a buggy decoder circuit that would allow certain instructions to
> have multiple writes to the same register.
 
buggy compiler... All the compilers are more or less buggy...
 
How do you develop an compiler else?... Personaly I'm never proud about my
first shots...

The philosophy: buggy code -> buggy execution; Good code -> Good execution

This is okay If I can have also a safe mode: if a program crash I can
still clean the system of it and do something else.      
 
In our world of network computer we are also exchanging more and more code   
on the fly and we need some kind of security: memory access and execution
Read from remote host sun: Aucun chemin d'accs pour atteindre l'hte cible
Connection to sun closed.

--steve

 From Steve Van der Hoeven Thu Sep 28 23:04:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01670 for ; Fri, 29 Sep 2000 02:22:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:43 +0200 (MEST) Received: (qmail 4037 invoked by uid 0); 28 Sep 2000 21:04:33 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 28 Sep 2000 21:04:33 -0000 X-eGroups-Return: sentto-1101623-882-970175068-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 28 Sep 2000 21:04:32 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 21:04:27 -0000 Received: (qmail 8203 invoked from network); 28 Sep 2000 21:04:27 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 28 Sep 2000 21:04:27 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 28 Sep 2000 21:04:27 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id QAA20019 for ; Thu, 28 Sep 2000 16:04:26 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <000f01c0298a$cf712ba0$29e65982@student.utwente.nl> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 16:04:26 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6a9ff3f1b02ee53066a6a016f3455d86 Status: R X-Status: N
Something about code translation...

So some people are very found about the transmetta chips...


  Okay they are nice with their code emulation on the cpu level... But
those processors were no maid with the same goals as ours: we wanted IA-64
killer, they wanted chip very easy to integrate in embended systems.

  Their code translation has been proved to be too expensive since more
than 20 years... We are not talking about $, their they are wright: having
one chip to maintain instead of a complet fleed for the industry is
interesting.

  Now remembre, some years ago... When you used an alpha and you were
using the 86 binaries on it.
  They did not software translation at the cpu level. But at the first
loading of a binary, they translated it on the fly and the it was stored
as an permanent alpha binary.

  I think the second aproach is the good one, for binairy translation: do
it once and forever with software.

  Now the problem of recompiling... It's not a big deal when you have a
good coded software. And with an IA-64 killer it will not be too long...
I think this is more a problem on the operating side: the software
interfaces of an operating are much more volatile than and processor
microcode.
  I prefer to recompile than to translate, because the translation can
only do optimization for a micro fragment, else it's called a cross
compiler.


--steve
eGroups Sponsor
From "Marco Al" Thu Sep 28 23:20:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01673 for ; Fri, 29 Sep 2000 02:22:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:44 +0200 (MEST) Received: (qmail 28414 invoked by uid 0); 28 Sep 2000 21:11:53 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net with SMTP; 28 Sep 2000 21:11:53 -0000 X-eGroups-Return: sentto-1101623-883-970175508-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 28 Sep 2000 21:11:51 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 21:11:47 -0000 Received: (qmail 29980 invoked from network); 28 Sep 2000 21:11:47 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 28 Sep 2000 21:11:47 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 28 Sep 2000 21:11:47 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id XAA28063 for ; Thu, 28 Sep 2000 23:11:45 +0200 (METDST) Message-ID: <002f01c02991$f289ae80$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 23:20:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fixed ISA (was: VLIW ...) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c8e45bddf9932de1d94a3d4c8dcd65eb Status: R X-Status: N From: "Steve Van der Hoeven" <vanderho@essi.fr>

> buggy compiler... All the compilers are more or less buggy...
>
> How do you develop an compiler else?... Personaly I'm never proud about my
> first shots...
>
> The philosophy: buggy code -> buggy execution; Good code -> Good execution

The same goes for processors of course, you can fix software... you can only
trash hardware :) (or make keychains out of them like Intel)

Marco
eGroups Sponsor
From "Marco Al" Thu Sep 28 23:34:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01676 for ; Fri, 29 Sep 2000 02:22:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:45 +0200 (MEST) Received: (qmail 25632 invoked by uid 0); 28 Sep 2000 21:26:07 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 28 Sep 2000 21:26:07 -0000 X-eGroups-Return: sentto-1101623-884-970176359-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 28 Sep 2000 21:26:04 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 21:25:58 -0000 Received: (qmail 7774 invoked from network); 28 Sep 2000 21:25:58 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 28 Sep 2000 21:25:58 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 28 Sep 2000 21:25:57 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id XAA02785 for ; Thu, 28 Sep 2000 23:25:56 +0200 (METDST) Message-ID: <003e01c02993$ed9721d0$29e65982@student.utwente.nl> To: References: <39D20CA6.650C8EF3@f-cpu.org> <007401c028f6$11883960$29e65982@student.utwente.nl> <39D384E7.93CEB725@f-cpu.org> <000f01c0298a$cf712ba0$29e65982@student.utwente.nl> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 23:34:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bbd6d797acb8097cd53d570c2bcefd07 Status: R X-Status: N Ugh... so many mistakes, Ill just correct some of them before anyone else
does :)

> Simple, since the fraction of them who care about assembly is so far below
0

1%.

> Nothing, but people are starting to go to ridiculous lengths to get wider
> and wider superscalar issue machines for smaller and smaller increments in
> effective CPI

IPC.

Marcp

 From Nicolas Boulay Thu Sep 28 23:51:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01679 for ; Fri, 29 Sep 2000 02:22:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:45 +0200 (MEST) Received: (qmail 12500 invoked by uid 0); 28 Sep 2000 21:47:18 -0000 Received: from ei.egroups.com (208.50.99.235) by mx19.rz2.gmx.net with SMTP; 28 Sep 2000 21:47:18 -0000 X-eGroups-Return: sentto-1101623-885-970177629-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ei.egroups.com with NNFMP; 28 Sep 2000 21:47:14 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 21:47:08 -0000 Received: (qmail 11437 invoked from network); 28 Sep 2000 21:47:08 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 28 Sep 2000 21:47:08 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 28 Sep 2000 21:47:07 -0000 Received: from 195.36.163.177 [195.36.163.177] by lh00.opsion.fr; Thu, 28 Sep 2000 21:44:29 GMT Message-ID: <39D3BD52.3D5B8458@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D233F8.B1D155A1@ifrance.com> <39D27E5E.480CF3E1@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 23:51:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw and TI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: c1fe6602c03d54a77c64980920aae031 Status: R X-Status: N The TI technic using changing lenth instructions word aren't CISC. Because there isn't microcode at all. Maybe 48 bits is to long for a 32 bits bus what could you say if you use 4 8bits wide instructions. It's the amdhal law. Speed up the common used things. The more compacted thing to go quick and a wider world for more complicated task. That a very good to decrease the need for memory bandwith (it's close to the arm thumb code concept). ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif -------------------------- eGroups Sponsor -------------------------~-~> No blistered feet. No crowd. No travel. Intraware invites you to attend a virtual tradeshow: Ensuring Scalable and Secure E-Business Systems. http://click.egroups.com/1/9219/15/_/3462/_/970177629/ ---------------------------------------------------------------------_-> From Steve Van der Hoeven Thu Sep 28 23:58:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01682 for ; Fri, 29 Sep 2000 02:22:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 02:22:46 +0200 (MEST) Received: (qmail 19431 invoked by uid 0); 28 Sep 2000 21:58:29 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 28 Sep 2000 21:58:29 -0000 X-eGroups-Return: sentto-1101623-886-970178294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 28 Sep 2000 21:58:27 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 28 Sep 2000 21:58:13 -0000 Received: (qmail 31525 invoked from network); 28 Sep 2000 21:58:13 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Sep 2000 21:58:13 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta2 with SMTP; 28 Sep 2000 21:58:13 -0000 Received: from sun.cs.rice.edu (sun.cs.rice.edu [128.42.1.42]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id QAA21725 for ; Thu, 28 Sep 2000 16:58:12 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <39D3BD52.3D5B8458@ifrance.com> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 16:58:12 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw and TI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 78b737abbef9d0c60fc0262300380d4d Status: R X-Status: N

> The TI technic using changing lenth instructions word aren't CISC.
> Because there isn't microcode at all. Maybe 48 bits is to long for a 32
> bits bus what could you say if you use 4 8bits wide instructions. It's
> the amdhal law. Speed up the common used things. The more compacted
> thing to go quick and a wider world for more complicated task. That a
> very good to decrease the need for memory bandwith (it's close to the
> arm thumb code concept).
> 
... if I remembre, we spill about 20 to 30% of our bandiwith with bits the
86 processors just ignore...

--Steve
eGroups Sponsor
From Yann Guidon Fri Sep 29 03:55:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01883 for ; Fri, 29 Sep 2000 03:38:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 03:38:06 +0200 (MEST) Received: (qmail 25147 invoked by uid 0); 29 Sep 2000 00:51:47 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 29 Sep 2000 00:51:47 -0000 X-eGroups-Return: sentto-1101623-887-970188662-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 29 Sep 2000 00:51:08 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 00:51:01 -0000 Received: (qmail 27637 invoked from network); 29 Sep 2000 00:51:01 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 29 Sep 2000 00:51:01 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 29 Sep 2000 00:51:01 -0000 Received: from f-cpu.org (nas4-96.ras.club-internet.fr [195.36.203.96]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA00234 for ; Fri, 29 Sep 2000 02:50:58 +0200 (MET DST) Message-ID: <39D3F68C.5896123D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 02:55:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cache design Content-Type: multipart/mixed; boundary="------------ABE3224CFC8D27373AE62206" X-UIDL: 8195e1da1fbab950fec613d04a43c277 Status: R X-Status: N --------------ABE3224CFC8D27373AE62206 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

i do not dislike to chat with you but it's time for
me to make some VHDL, at last :-)

So i'm using Simili now. I contacted the guy who makes
it and he's open, even though Simili is proprietary :
it seems that the use of this tool will remain free (of charge).
It is a rather convenient way to learn VHDL, too, because
it seems solid and simple. A Un*x port is going on, too,
and linux/x86 will be the next target, so we'll be closer
to the F-CPU philosophy.

i'm working on the Icache and learning the practical use of
VHDL, so i hope that you will forgive the first incomplete
version of the included file. At least it compiles with Simili,
and i guess that other IEEE-compliant compilers will accept
it too :-)

I've found SDRAM VHDL models so we'll be able to simulate a
"real" system when enough units will be ready. in particular,
the way to interact with the SDRAM banks from the asm code
is interesting, i guess that it can have a positive impact
on the efficiency of the architecture.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------ABE3224CFC8D27373AE62206 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="cache002.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cache002.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIA0KLS0gRi1DUFUgcHJvamVjdA0KLS0gKGMpIFlhbm4gR3Vp ZG9uIDI5IHNlcHQuIDIwMDAgd2h5Z2VlQGYtY3B1Lm9yZw0KLS0gR1BMIGFwcGxpZXMuDQot LSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQotLSANCi0tIFdhcm5pbmcsIGknbSBub3QgYSBnb29kIFZI REwgY29kZXIuDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLQ0KLS0gSGVyZSBhcmUgc29tZSBy ZXF1aXJlbWVudHMvc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGluc3RydWN0aW9uIGNhY2hlIDoN Ci0tIC0gbGluZSB3aWR0aCA6IDMyIGJ5dGVzICgyNTYgYml0cykNCi0tIC0gbnVtYmVyIG9m IGxpbmVzIDogdW5kZXRlcm1pbmVkLCBjb3VsZCBiZSBhcyBsb3cgYXMgNCBmb3IgdGhlDQot LSAgICB0ZXN0cyBvciAyNTYgZm9yIGEgZmluYWwgdmVyc2lvbi4gU2l6ZSBkb2Vzbid0IG1h dHRlciwgYmVoYXZpb3VyDQotLSAgICBpcyBtb3JlIGltcG9ydGFudC4NCi0tIC0gc3RyYXRl Z3kgOiAidHJ1ZSBMUlUiLCAxIHNldC93YXksIHRvIGF2b2lkIG5hc3R5IHRocmFzaGluZy4N Ci0tICAgIHRoaXMgY291bGQgY2hhbmdlIGluIHRoZSBmdXR1cmUgYW5kIGl0J3MgdXAgdG8g ZXZlcnlvbmUncyB0YXN0ZQ0KLS0gICAgYW5kIG5lZWQuIDItIG9yIDQtd2F5IGFzc29jaWF0 aXZlIG1heSBiZSBpbXBsZW1lbnRlZCBpbnN0ZWFkDQotLSAgICBvZiBmdWxseSBhc3NvY2lh dGl2ZS4NCi0tIC0gMSByZWFkIGFuZCAxIHdyaXRlIGRhdGEgcG9ydHMgZm9yIHNpbXVsdGFu ZW91cyBhY2Nlc3MNCi0tICAgIG9mIDIgZGlmZmVyZW50IGl0ZW1zIC0+IDEgcmVhZCBhbmQg MSB3cml0ZSBhZGRyZXNzIGJ1c2VzDQotLSAtIDEgImNhY2hlIGhpdC9taXNzIiBvdXRwdXQg Yml0Lg0KLS0gLSBsYXRlbmN5IDogMSwgMiBvciAzIGN5Y2xlcy4gMSBjeWNsZSBpcyBuZWNl c3NhcnkgZm9yIHRoZSBzaW1wbGUNCi0tICAgICB0ZXN0cywgMiBjeWNsZXMgbWlnaHQgYmUg bmVjZXNzYXJ5IHRvIHNwZWVkdXAgdGhlIGNsb2NrIGluIHRoZSBmdXR1cmUuDQotLSAtIEl0 IHNob3VsZCBiZSBwb3NzaWJsZSB0byBpbnZhbGlkYXRlL2ZsdXNoIGEgY2VydGFpbiBjYWNo ZSBsaW5lDQotLSAgICBpZiBpdCBjb3JyZXNwb25kcyB0byBhIHNwZWNpZmllZCBhZGRyZXNz IHJhbmdlLiBUaGUgYWRkcmVzcyBtYXNrcw0KLS0gICAgZm9yIHRoaXMgY2FzZSBhcmUgbm90 IHlldCBpbXBsZW1lbnRlZC4NCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIA0KLS0gVGhpcyB2 ZXJ5IGltcGxlbWVudGF0aW9uIG9mIHRoZSBJY2FjaGUgaXMgY29tcG9zZWQgb2YgdGhyZWUg ZWxlbWVudHMgOg0KLS0gICogVGhlIExSVSBzdGFjaw0KLS0gICogVGhlIGFkZHJlc3MgdGFn cyAmIGNvbXBhcmF0b3JzDQotLSAgKiBUaGUgY2FjaGUgbGluZXMgdGhlbXNlbHZlcy4NCi0t IEVhY2ggb2YgdGhlbSB0YWtlIG9uZSBjeWNsZSB0byBnbyB0aHJvdWdoLg0KLS0NCi0tIEFs Z29yaXRobSBmb3IgdGhlIHRocmVlIG1vZGVzIDoNCi0tIA0KLS0gUmVhZCA6DQotLSBDeWNs ZSAxKSBTZW5kIHRoZSBhZGRyZXNzIG9uIHRoZSByZWFkIGJ1cy4gVGhlIGFkZHJlc3MgaXMN Ci0tIGNvbXBhcmVkIHdpdGggZXZlcnkgdmFsaWQgYWRkcmVzcyB0YWcgYW5kIHRoZSByZXN1 bHQgaXMNCi0tIGEgYml0IHZlY3Rvci4gVGhpcyB2ZWN0b3IgaXMgc2VudCB0byB0aGUgcmVh ZCBsaW5lcyBvZiB0aGUgY2FjaGUsDQotLSBhbmQgZW5jb2RlZCBmb3IgdGhlIExSVSBzdGFj ay4gVGhlICJoaXQiIHNpZ25hbCBpcyBzZW50Lg0KLS0gQ3ljbGUgMikgVXBkYXRlIHRoZSBM UlUgYW5kIHJlYWQgdGhlIHNlbGVjdGVkIGNhY2hlIGxpbmUuDQotLSANCi0tIFdyaXRlIDog KGZpdHMgaW4gMSBjeWNsZSkNCi0tICAqIFRoZSBMUlUgc3RhY2sgYWx3YXlzIG91dHB1dHMg dGhlIG51bWJlciBvZiB0aGUgTFJVIGxpbmUsDQotLSAgc28gaXQncyAicHJlZGVjb2RlZCIu IGl0IGlzIHNlbnQgYXMgYSBiaXQgdmVjdG9yIHRvIHRoZQ0KLS0gIHdyaXRlIHNpZ25hbCBv ZiBlYWNoIGNhY2hlIGxpbmUsIGFuZCBhbGxvd2VkIGJ5IHRoZSBnZW5lcmFsIFdSSVRFIHNp Z25hbC4NCi0tICAqIEluIHRoZSBzYW1lIHRpbWUsIHRoZSBMUlUgaGFzIGEgc3BlY2lhbCB1 cGRhdGUgY3ljbGUuDQotLSAgKiBUaGUgZGF0YSBpcyBzZW50IHRvIHRoZSBkYXRhX2luIGJ1 cyBvZiB0aGUgY2FjaGUgYmxvY2suDQotLSAgKiBUaGUgYWRkcmVzcyBpcyBzZW50IHRvIHRo ZSB3cml0ZSBhZGRyZXNzIGJ1cyBvZiB0aGUgYWRkcmVzcyB0YWcgYmxvY2suDQotLSAgDQot LSBJbnZhbGlkYXRpb24gOg0KLS0gICogdGhlIGludmFsaWQgc2lnbmFsIGlzIHNlbnQNCi0t ICAqIHRoZSBpbnZhbGlkYXRlZCBhZGRyZXNzIGlzIHNlbnQgdG8gdGhlIHJlYWQgYWRkcmVz cyBidXMgb2YgdGhlIHRhZyBibG9jay4NCi0tIA0KLS0gDQotLSBCZWNhdXNlIHRoZSByZWFk IHRha2VzIDIgY3ljbGVzLCB0aGVyZSBtaWdodCBiZSBjb25mbGljdHVhbCBzaXR1YXRpb25z Lg0KLS0gQWxsIHRoZSBjb25mbGljdHMgbXVzdCBiZSB0ZXN0ZWQgYW5kIGRlbGF5ZWQgYmVm b3JlIHRoZSByZXF1ZXN0ZWQgY3ljbGUNCi0tIGlzIGFjY2VwdGVkIGludG8gdGhlICJwaXBl bGluZSIuIFRoZSBjb25mbGljdHMgYXJlIE5PVCB0ZXN0ZWQgeWV0Lg0KLS0gUmVhZCBhbmQg aW52YWxpZGF0aW9uIGN5Y2xlcyBzaG91bGQgbm90IGNvbGxpZGUgZWl0aGVyIDogdGhleSB1 c2Ugc29tZQ0KLS0gY29tbW9uIHJlc3NvdXJjZXMuDQotLSANCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CmxpYnJhcnkgaWVlZTsNCnVzZSBpZWVlLnN0ZF9sb2dpY18xMTY0LmFsbDsNCnVzZSBJRUVF LnN0ZF9sb2dpY191bnNpZ25lZC5hbGw7DQoNCkVOVElUWSBJQ2FjaGUgSVMNCiAgZ2VuZXJp YygNCiAgICBBQldJRFRIIDogSU5URUdFUiA6PSAxNiAgIDsgLS0gYWRkcmVzcyBidXMgd2lk dGggKHRoaXMgbWFrZXMgYSAyMS1iaXQgcGh5c2ljYWwgYWRkcmVzcyBzcGFjZSkNCiAgICBE QldJRFRIIDogSU5URUdFUiA6PSAyNTYgIDsgLS0gZGF0YSBidXMgd2lkdGgNCiAgICBOQkxJ TkVTIDogSU5URUdFUiA6PSA2NCAgOyAtLSBudW1iZXIgb2YgY2FjaGUgbGluZXMNCiAgICBM T0dMSU5FUyA6IElOVEVHRVIgOj0gNiAgLS0gbG9nMihOQkxJTkVTKQ0KICApOw0KICBQT1JU KA0KICAgIENMSywgRmx1c2hFbiwgUmVhZEVuLCBXcml0ZUVuIDogSU4gc3RkX2xvZ2ljOw0K ICAgIElDYWNoZUhpdCA6IE9VVCBzdGRfbG9naWM7DQogICAgV3JpdGVBZGRyLCBSZWFkQWRk ciA6IElOIHN0ZF9sb2dpY192ZWN0b3IoQUJXSURUSC0xIGRvd250byAwKTsgDQogICAgRGlu IDogSU4gc3RkX2xvZ2ljX3ZlY3RvcihEQldJRFRILTEgZG93bnRvIDApOw0KICAgIERvdXQg IDogT1VUIHN0ZF9sb2dpY192ZWN0b3IoREJXSURUSC0xIGRvd250byAwKQ0KICApOw0KRU5E IElDYWNoZTsNCg0KLS0gaSdtIHN0aWxsIHdvcmtpbmcgYmVsb3cgdGhpcyBsaW5lIDoNCg0K QVJDSElURUNUVVJFIGVzczEgT0YgSUNhY2hlIElTDQogIHR5cGUgY2FjaGVfYmxvY2tfdHlw ZSBpcyBhcnJheSgwIHRvIE5CTElORVMtMSkgb2Ygc3RkX2xvZ2ljX3ZlY3RvcihEQldJRFRI LTEgZG93bnRvIDApOw0KICBzaWduYWwgSWNhY2hlX2Jsb2NrIDogY2FjaGVfYmxvY2tfdHlw ZTsNCkJFR0lODQoNCmNhY2hlX2xvb2t1cCA6IHByb2Nlc3MoY2xrKSBiZWdpbg0KICBpZiAo UmVhZEVuPScxJykgYW5kIChSZWFkQWRkcjxOQkxJTkVTKSB0aGVuDQogICAgRG91dCA8PSBJ Y2FjaGVfYmxvY2sgKENPTlZfSU5URUdFUihSZWFkQWRkcikpOw0KICBlbmQgaWY7DQplbmQg cHJvY2VzcyBjYWNoZV9sb29rdXA7DQoNCkVORCBlc3MxOw0K --------------ABE3224CFC8D27373AE62206-- From Jecel Assumpcao Jr Fri Sep 29 03:35:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01886 for ; Fri, 29 Sep 2000 03:38:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 03:38:07 +0200 (MEST) Received: (qmail 31537 invoked by uid 0); 29 Sep 2000 01:07:04 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 29 Sep 2000 01:07:04 -0000 X-eGroups-Return: sentto-1101623-888-970189610-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 29 Sep 2000 01:06:57 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 01:06:50 -0000 Received: (qmail 7838 invoked from network); 29 Sep 2000 01:06:50 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 Sep 2000 01:06:50 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 29 Sep 2000 01:06:47 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id WAA14394 for ; Thu, 28 Sep 2000 22:14:56 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00092822521903.00386@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Sep 2000 22:35:29 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fixed ISA Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5cbee2992266b3181f6f79838a04041 Status: R X-Status: N Steve Van der Hoeven expressed several problems that he has with binary
translation for replacing hardware.

First I should say that I am very biased, since I have been working on
this a few years before Transmeta was even founded.

In theory, viruses are not a problem. We have three levels of code
execution: user level, kernel level and native code/compilation. In a
good OS design, nothing at the user level should be able to affect the
kernel level (I haven't yet heard of any viruses for Linux, for
example). And even the kernel level has no access at all to the native
level. In the case of the Crusoe, for example, no sequence of x86
instructions can change the compiler (which is loaded into a RAM that
can't be addressed by x86 code before the normal boot starts).

Of course, if you want to be able to distribute "hardware updates"
over the internet then there much be a way to change the compiler from
the normal operation. Just like updating the BIOS stored in your
computer's Flash memory. It isn't hard to protect these special update
operations against tampering by viruses, however.

About performance: Linus claimed that he recompiled Linux for the
native VLIW code on the Crusoe chip and that it was not any faster than
"code morphing" the x86 version. This agrees with my own experience.
While it is true that a binary translation system is limited to just
the basic blocks of code (unlike a static compiler), it has access to
much more information than a hardware superscalar scheduler. The
hardware can only see the past, while a compiler can "see the future".

-- Jecel
eGroups Sponsor
From "Albert Abramson" Fri Sep 29 09:34:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00329 for ; Fri, 29 Sep 2000 13:53:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 13:53:04 +0200 (MEST) Received: (qmail 15341 invoked by uid 0); 29 Sep 2000 07:35:29 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 29 Sep 2000 07:35:29 -0000 X-eGroups-Return: sentto-1101623-889-970212874-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 29 Sep 2000 07:35:25 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 07:34:33 -0000 Received: (qmail 3411 invoked from network); 29 Sep 2000 07:34:33 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 29 Sep 2000 07:34:33 -0000 Received: from unknown (HELO femail4.sdc1.sfba.home.com) (24.0.95.84) by mta3 with SMTP; 29 Sep 2000 07:34:33 -0000 Received: from [24.10.43.202] by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000929073332.VTXB4031.femail4.sdc1.sfba.home.com@[24.10.43.202]> for ; Fri, 29 Sep 2000 00:33:32 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000929073332.VTXB4031.femail4.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 00:34:27 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2166c0c43df8e172e793404185939f8c Status: R X-Status: N Just so that we're all on the same starting point, if we're discussing VLIW,
there can be only one realistic approach to compilation, and that is to use
a virtual ISA to compile to that is easier to optimize than x86.  Either at
installation time or after interpreting code the first time, you build up a
branch history table and cache miss history in memory for more accurate
compilation, straight line execution, and memory management.  In theory,
IA-64 is actually a pretty good candidate for this.

Point being that dynamic optimization software stands between the compiler
and the hardware, rather than more decode hardware.  So you really do have
trusted software running that actually performs the necessary checks ahead
of time.

Ideally, the ISA would hold a large virtual register file that accessed
those memory locations with constants, but permitted an imprecise view of
that vrf.  This gives the dynomizer software the greatest flexibility (as
well as hints for cache management) and allows for greater simplicity in the
operation of the software.

Nearly anything that can be done in hardware can be performed in software
without complicating the hardware.  Branching code (especially compiling,
optimization, etc.) depends on short latency in both the pipeline and the
memory system, since it doesn't lend itself too well to better parallelism.
Raytracing, video, de/compression, vector graphics, and computer simulations
depend on high throughput for their data types and high bandwidth throughout
the memory system.

Finally, there are only two outstanding bottlenecks on modern computers:
latency and bandwidth.  VLIW helps both by leaving more space on the chip
for caching.  While statically scheduled code inevitably leads to larger
code size, this cycle by cycle approach actually allows for some improvement
in ICACHE management (the ICACHE being the only place left where code size
matters, since it impacts the L1's hit rate).  After identifying the most
likely upcoming branch mispredicts, you load only as many instruction words
as you would need to reach L2.  Since each instruction word is one cycle,
you need only keep n words in the ICACHE along the mispredicted path, where
n is the number of cycles needed to reach L2.  We can simplify things a lot
by implementing cache(L2) that is accessed in four cycles, while packing
four instruction words (four cycles worth) onto one cache block and leaving
enough bandwidth to get another instruction word each cycle onto L1.

Main memory latency is the biggest one, and even the largest OOO windows are
not keeping up with that one.  Only MT holds out a possibility of solving
that one.

----------
>From: Yann Guidon <whygee@f-cpu.org>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] VLIW ...
>Date: Thu, Sep 28, 2000, 10:50 AM
>

> hello,
>
> Marco Al wrote:
>> Subject: [f-cpu] VLIW ...
>> > Particularly, the problems of VLIW (like the consistency of the code,
>> Consistency??
> i'm concerned by the immunity to "hostile software"
> and the integrity of the protection mechanisms.
> The respect of the coding conventions is one part of this :
> how will the HW manage if two parallel instructions
> write to the same register ? Does it fry the chip ?
> if the last is true, then you shouldn't run Linux on it.
>
The software layer provides this level of protection.  Remember, almost
anything that can be handled in hardware can be handled in software.

>> > the violation of the coding rules
>> How is that a problem? Building scheduling rules into a compiler is easier
>> than building it into hardware whichever way you look at it. Or do you mean
>> from a security point of view?
>
> both. and making a "good" compiler is not as easy as you seem to think.
> of course it's easy to make a toy compiler. But a solid one, that can optimize
> correctly a great variety of codes, is a tough task.
>
Since the hardware guys would have the illustrious task of developing that
low level software, the compiler is kept from this arduous task.  Security
is still built in, but software, not hardware, saves you.

>> >, the enlargement of the decoding units
>> Why would a X instruction VLIW decoder be larger than the decoders in a X
>> way superscalar machine?
>
> read the other post : i meant "it decodes more instructions during every
cycle".

Admittedly, a dynamically scheduled processor will always get a better CPI
than a statically scheduled one.  But would you rather issue a maximum of
three IPC at 1.4 GHz or six at 700 MHz?  You would always prefer the former
because it is never slower.

>
>> > etc) make its implementation
>> > as a UNIX CPU very difficult : look at Intel's crap.
>> Oh come now, they may have dropped the ball on the first implementation...
>> but both HP and Intel put a lot of money and faith into EPIC, after HP had
>> already been doing a lot of research into it for a long time, I wouldnt
>> count it out just yet on the evidence of the first generation.
> alright, alright. HP already ships native IA-64 chips in their servers.
> does that mean that Intel's promises are kept ? :-)
>
>> > are rather inefficient and don't match the F-CPU
>> > requirements of scalability and longevity.
>> Scalability and longevity are overrated.
> of course, you write a new compiler every day.
>

No, only the code morphing/dynamic optimization software would have to be
rewritten.  Transmeta's problem is that they started with x86 code, which is
notoriously hard to recompile into anything efficient, even in hardware.

>> I dont mind recompiling Linux, and
>> theres always binary translation (which does not have to be slow with the
>> right design according to IBM, http://www.research.ibm.com/vliw/). I think
>> HP has also said future EPIC processors would be backwards compatible via
>> binary translation.
> OK for binary translation, but does that spare the effort of designing a new
> instruction set all the time ?...
>

Then keep the old one that worked well enough.  A little wire worked and
improved caching and integration always helps performance a little bit.

>> > IA-64 uses a special information in the instruction word
>> > to know how the instructions should be decoded. I don't know
>> > how well it scales and i doubt that a very large version
>> > is possible because one can't access more than 32 int registers
>> > at once. 12 instructions seems a practical maximum for a int-only
>> > code (the usual case when you don't forecast the weather).
>> > For the F-CPU, there are 2x more registers so 24, or at least
>> > 16 instructions per cycle "could" be feasible and codable
>> > in a real program.
>>
>> How do you intend to extract those 16 IPC?
> with my head, some experience, a lot of good sense and GNL.
> with GNL and those 64 registers, i'd have done it for a while :
> i have a computation kernel that requires a lot of computations
> and i have broken down it into 6 parallel calculations. each calculation
> can use 3 instructions per cycle, so it would give 18 instructions (peak)
> per cycle if such a large CPU was possible.
>

Compilers generate 99% of all code that executes on computers, and your
processor spends at least 95% of its time handling compiled binaries.  Even
with dynamic hardware and/or software optimization, it is hard to average
even four IPC with most code.  A higher clock rate is a better way to get
more throughput.

>> Wouldnt you need a huge
>> instruction window with standard RISC? And the majority of those
>> instructions would be speculative of course, a book keeping nightmare.
> i don't use speculative instructions in the computation kernels :
> it would waste a lot of ressources. What's the point of computing
> something if it gets discarded ??? i programmed the above kernel
> (look at http://www.mime.up8.edu/~whygee/memoire/index.html)
> on Pentium 200 MMX and PII. they are bound by the decoding unit,
> so each instruction that gets decoded must be the right one.
> If you decode useless instructions, your performance drops.
>
Speculation usually targets instructions that have a high probabilty of
execution or that would lead to a many-cycle stall (like cbt's).
Speculation can also be inlined in static code with cmov's, not exacerbating
wire lengths too much, which is why they've been the prefered method with
Alpha since the beginning.  IA-64 uses predication, but in reality, it not
much more effective and does exacerbate wire lengths.

>> > Now, if this can be done harmlessly by HW on the fly, why would
>> > we give hints ? they shift to a higher level, because the amount
>> > of bandwidth they take is revelant.
>> With a disposable ISA you dont need hints like that at all of course :) (it
>> would all be implicit in the instruction stream)
>
> and who would design the "disposable" ISA everyday ?
> how would you teach each version to each newcomer ?
> What would you say to people who want to use old versions ?
> "sorry, i have thrown this one away, have a fun reverse-engineering"
>
> remember that for industrial products, longevity is a critical
> matter. have you heard about those companies that store
> spare electronic components in liquid nitrogen for the next 30 years
> because if one of their devices has a failure, they won't find a replacement ?
> How can you convince an industrial company to give money for building a CPU
> project and say, in a ice-cold voice : "i'll throw it away in two years" ?
>
> Of course ISAs need to evolve but we have to respect the continuity of
> the efforts, or else it does not look credible. Damn, the MIPS
> (as well as ALPHA, SPARC, Power etc...) ISA has grown up and is still working
> after years of development. it was designed with this goal in mind.
> So what's wrong with longevity, when it's designed with this goal in mind ?
>
MIPS, ironically, suffers from and is now failing because Silicon Graphics'
management insisted on retrofiting everything into the CPU, leaving them
with a 250MHz clock when even Intel was breaking 400.

> of course, x86 is the best counter-example and it was not designed for
> longevity.
>
>> Marco
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
--Maxx
 From Kai Wetzel Fri Sep 29 12:52:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00338 for ; Fri, 29 Sep 2000 13:53:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 13:53:07 +0200 (MEST) Received: (qmail 25823 invoked by uid 0); 29 Sep 2000 09:12:19 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 29 Sep 2000 09:12:19 -0000 X-eGroups-Return: sentto-1101623-890-970218732-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 29 Sep 2000 09:12:17 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 09:12:11 -0000 Received: (qmail 2775 invoked from network); 29 Sep 2000 09:12:11 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 Sep 2000 09:12:11 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta3 with SMTP; 29 Sep 2000 09:12:11 -0000 Received: from welfen-netz.com [213.6.66.94] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 29 Sep 2000 11:10:15 +0200 Sender: kai@pop.gmx.net Message-ID: <39D4745B.E8B51046@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D20CA6.650C8EF3@f-cpu.org> <007401c028f6$11883960$29e65982@student.utwente.nl> <39D384E7.93CEB725@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 12:52:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6704f4908781251067a949c7afca31ec Status: R X-Status: N Yann Guidon wrote:
>
> hello,
>
> Marco Al wrote:
> > Subject: [f-cpu] VLIW ...
> > > Particularly, the problems of VLIW (like the consistency of = the code,
> > Consistency??
> i'm concerned by the immunity to "hostile software"
> and the integrity of the protection mechanisms.

There is (at least) user mode and supervisor mode ...

> The respect of the coding conventions is one part of this :
> how will the HW manage if two parallel instructions
> write to the same register ?

It depends.  For the example of a 6-issue VLIW you'd
have no trouble if a single register can be written
on a sub-cycle basis 6 times - problem solved.  If this
can not be achieved technically you could implement a
first-wins policy, where subsequent writes would be ignored and
possibly an (optional) exception issued - problem solved as well.
(And in any case, it is "well-defined")

> Does it fry the chip ?

No frying involved, no.

> if the last is true, then you shouldn't run Linux on it.

No problem running Linux at all.

[...]
> > > Now, if this can be done harmlessly by HW on the fly, why wo= uld
> > > we give hints ? they shift to a higher level, because the am= ount
> > > of bandwidth they take is revelant.
> > With a disposable ISA you dont need hints like that at all of cou= rse :) (it
> > would all be implicit in the instruction stream)
>
> and who would design the "disposable" ISA everyday ?

Remember that the instruction set is (almost) identical to
the custom-layout microprocessor, so as often as you design
a new chip, you'll get a new IS.  The overall ISA doesn't
have to change that often, though :=B0)

> how would you teach each version to each newcomer ?

Those individuals who could and wanted to program a static
multi-issue VLIW pipeline (possibly even with predecates if one
likes that idea) manually on a regular basis are rare
(disclaimer: only taking planet earth into account).
_They_'ll adapt to a slightly modified instruction set easily ;^)
For the rest of us, we won't bother, or use special tools
which make things easier.

[...]
kai


 From Kai Wetzel Fri Sep 29 12:33:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00341 for ; Fri, 29 Sep 2000 13:53:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 13:53:08 +0200 (MEST) Received: (qmail 1658 invoked by uid 0); 29 Sep 2000 09:12:21 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 29 Sep 2000 09:12:21 -0000 X-eGroups-Return: sentto-1101623-891-970218732-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 29 Sep 2000 09:12:20 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 09:12:11 -0000 Received: (qmail 4705 invoked from network); 29 Sep 2000 09:12:11 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 29 Sep 2000 09:12:11 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta1 with SMTP; 29 Sep 2000 09:12:11 -0000 Received: from welfen-netz.com [213.6.66.94] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 29 Sep 2000 11:10:11 +0200 Sender: kai@pop.gmx.net Message-ID: <39D46FFA.EE056A93@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D233F8.B1D155A1@ifrance.com> <39D244F3.9AC629C0@llandre.freeserve.co.uk> <39D27E5B.7C7EAAB7@f-cpu.org> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 12:33:30 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vliw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3b70e9913dca0f68f69a4941e6fe0dbd Status: R X-Status: N Yann Guidon wrote:
[...]
> Kai Wetzel wrote:
> > Hi,
> >
> > Yann Guidon wrote:
> > [...]
> > > Particularly, the problems of VLIW (like the consistency of = the
> > > code, the violation of the coding rules, the enlargement
> > > of the decoding units etc)
> >
> > Well, you have a point with the consistency/violation stuff, but<= BR> > > using a software instruction rescedular it's not that bad as long=
> > as the supported instructions and overall arch. dont change.
>
> what can be done for a "wide" F-CPU :
> - P-4 way : a decoder/rulechecker located at the bus interface that > generates and possibly reschedules the instructions on the fly,
> so they're nicely packed in the Icache and ready for straight executio= n.
>
> or :
>
> - RISC front-end, still located near the memory bus interface
> (so it works when there's a Icache line fill). It generates =B5codes > for a wide "move-machine" (like the one that was previously = intended
> for the F-CPU, after the first arch failed).

How about a 5- or 6-issue VLIW with a code translator in software ? :=B0) (Please note that this makes for a cycle longer then the 6-gates
cycle you projected for FC0)

[...]
> > > make its implementation as a UNIX CPU very difficult :
> > What's a UNIX CPU, what's a Tetris CPU, ... ?  UNIX is
> > not likely to be a very CPU bound itself, what matters
> > is the speed of CPU-bound tasks, and they only make up
> > an extremely tiny fraction of all the code running most
> > UNIX systems, no ?
>
> sorry again.
> let's take for example a DSP and a i386 : the i386 can run a
> Un*x-like because it provides a precise view of the system to
> the user's task. When a protection error occurs, it can be located, > and at least it's detected. The task can be ended or the function
> (ie screen or another i/o) can be emulated.

Hmm, but we're talking about a VLIW processor, not a DSP.

[...]
> The obvious problem, as i try to point, is the risk of offensive codes=
> that generate illegal opcode combinations that trash the machine (or > worse).

Many of the obstacles you mention can be met more or less
easily:

- some super/user mode distinction is maintained
- no instruction entering the device can "trash the
  machine"
- How finely-grained exceptions can be located depends
  on how much space we want to throw at it.  (Ok, it's
  strictly not possible to interrupt the pipeline and re-issue,
  but that's something we could live with I think =3D^)

> Another problem that Nicolas pointed (and that IBM met)
> is the high number of ports. there are workarounds, like split/duplica= ted
> reg sets, but we need to need it to do it. it either hard to code for,=
> or hard to hardwire.

How many ports are needed depends on the maximum throughput
of a single port, if it can be used on a sub-cycle basis we
need correspondingly less ports for the reg-file even with
"n-issue" ...

> > [...]
> > > IA-64 uses a special information in the instruction word
> > > to know how the instructions should be decoded. I don't know=
> > > how well it scales and i doubt that a very large version
> > > is possible because one can't access more than 32 int regist= ers
> > > at once. 12 instructions seems a practical maximum for a int= -only
> > > code (the usual case when you don't forecast the weather). > > > For the F-CPU, there are 2x more registers so 24, or at leas= t
> > > 16 instructions per cycle "could" be feasible and = codable
> > > in a real program.
> > Very optimistic...
> so is the arithmetic ;-)
>
> just take 32 registers, and 3-operands (2r1w) instructions.
> this makes 32/3=3D11 instructions before you need more registers.
> 16 instructions is probably "optimistic" but could be coded<= BR> > in a real application. Let's see : 64/3=3D21, some source
> operands can be used twice (say, 4 or 5), so 24 instructions
> would be "possible". of course it depends on the application= ,
> we need pointers to memory, and 16 is more reasonable.
> But before we need that, we'll have already 512-bit wide registers :-)=
> if this runs at 100MHz, this makes around 8GMOPS...

Reducing clock-frequency to get more MOPS by widening
registers is interesting, but I'm not quite convinced.
I think using a vector/queue kind of thing between registers
and the cache is a more general solution and may help
the static pipeline not to drain too often ;=B0>

Regarding arithmetics, just imagine the possibility of
a 1GHz 4-cores VLIW FC1 processor reaching a theoretical
maximum of roughly 48GFLOPS =3D*p  (and thats using "doubles"= ; !)

> it could work for operations like signal processing (it's rather
> easy to find ILP in these code kernels).
>
> > [...]
> > kai
>
> well, now, let's sleep then see how Simili works.
> it looks quite good, i want to be sure that it IS any good :-)

Of the tools you tried for UNIX, which would you recommend for
drawing schematics ?

Best regards,
kai


 From "Toyoaki Sagawa" Fri Sep 29 13:45:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00362 for ; Fri, 29 Sep 2000 13:53:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 13:53:13 +0200 (MEST) Received: (qmail 28069 invoked by uid 0); 29 Sep 2000 11:45:07 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 29 Sep 2000 11:45:07 -0000 X-eGroups-Return: sentto-1101623-892-970227898-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 29 Sep 2000 11:45:02 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 11:44:58 -0000 Received: (qmail 15937 invoked from network); 29 Sep 2000 11:44:58 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 29 Sep 2000 11:44:58 -0000 Received: from unknown (HELO mail160.nifty.com) (202.248.37.176) by mta3 with SMTP; 29 Sep 2000 11:44:57 -0000 Received: from cfb5 by mail160.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA11201 for ; Fri, 29 Sep 2000 20:44:55 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39D384E9.A0762301@f-cpu.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 20:45:12 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7c9e6bc2c7100a3a8302b83f70023ebc Status: R X-Status: N
Hi, Thanks to Yann and Morco,

> sorry but you're completely wrong, even though it doesn't matter
> that much.

I tried VisualC++ today, and I got...
Speed fastest: the loop was completely unroled.
Speed/Size : the code was similer to Yann's.

> it with something like GCC, but OTOH you made your Sayuri code
> example by hand.
> this is not what i call fair ;-)

Yes it is not fair (^^;

> loop:
> ; slot 1 :
>    add ebx,eax
>    add edx,ecx
>    add edi,esi
> ; slot 2 :
>    add eax,3
>    add ecx,3
>    add esi,3
> ; last slot :
>    sub ebp,3
>    jns loop

  It is VERY, truly instructive for me.
  I keep it in my mind.

> >   Sayuri(ver1.0?) and enough volume of cache. How many core can
> be fit in ASIC :-)
>
> "it depends on the size" ;-)

  Now Sayuri's equivalent gate count for design is 12,267.
I want to keep it in this range, at least under 50000.

> Anyway, i hope that you'll have fun and success with Sayuri.
> Pipelining it will certainly make it run faster.
>
> Last question, i hope you won't make fun of me for my ignorance,
> what does "Sayuri" means ?

  Sayuri is written by Japanese Kanji like...
http://www.morphyplanning.co.jp/FreeCPU/sayuri.gif
Left side character means "small" or "pretty" ..."Sa"
middle and right side, two character is "lily"... "yuri"
normally this is a name of girls, in Japan  :-)

Toyoaki Sagawa
 From rhoover@india.com Fri Sep 29 13:38:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01395 for ; Fri, 29 Sep 2000 23:26:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Sep 2000 23:26:29 +0200 (MEST) Received: (qmail 18334 invoked by uid 0); 29 Sep 2000 18:30:05 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 29 Sep 2000 18:30:05 -0000 X-eGroups-Return: sentto-1101623-893-970252194-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 29 Sep 2000 18:30:02 -0000 X-Sender: rhoover@india.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 18:29:53 -0000 Received: (qmail 2658 invoked from network); 29 Sep 2000 18:29:53 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 29 Sep 2000 18:29:53 -0000 Received: from unknown (HELO wb.warr.ac.uk) (194.82.91.15) by mta2 with SMTP; 29 Sep 2000 18:29:52 -0000 Received: from _[185.167.58.129]_by by wb.warr.ac.uk (8.9.3+Sun/SMI-SVR4) id TAA14380; Fri, 29 Sep 2000 19:31:00 +0100 (BST) Message-Id: <200009291831.TAA14380@wb.warr.ac.uk> Received: from [139.16.68.217] by _[185.167.58.129]_by with SMTP id A84C41E10 Fri, 29 Sep 2000 11:21:14 PDT From: rhoover@india.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 11:38:31 Reply-To: f-cpu@egroups.com Subject: [f-cpu] # 1 Website Promotion Techiques Plus Free Report of Your Website's Placement Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 5bf2202fb7630647d7a8730827bfea21 Status: R X-Status: N Your business will make money 24-hours a day!




GET YOUR FREE REPORT OF YOUR WEBSITE'S POSITION ON MAJOR SEARCH ENGINES
By simply filling out the form below. This report will be the most important information you could have on driving traffic to your site.

INCREASE THE TRAFFIC TO YOUR WEBSITE BY 10 TO 20 TIMES
Until recently, only larger companies were able to afford the luxury of having their sites positioned. WE GUARANTEE, in writing, that you will be among those select few positioned or your MONEY BACK.

95% OF ALL PEOPLE USE SEARCH ENGINES TO FIND WHAT THEY WANT ON THE INTERNET.
Contrary to popular belief simply submitting your web site to the search engine does not guarantee that your site will even be indexed (or listed) at all!!!
WE GUARANTEE, in writing, that your traffic will increase or your MONEY BACK.

95% OF ALL PEOPLE WHO USE A MAJOR SEARCH ENGINE NEVER GO PAST THE TOP 20 LISTINGS
If you're not ranked within the top 10, or the top 20 positions in the major search engines using keywords and phrases directly related to your company, you lose. WE GUARANTEE in writing, your site will be in the top 10 or top 20 or your MONEY BACK.

SEARCH ENGINE PLACEMENT IS THE MOST EFFECTIVE METHOD TO INCREASE TRAFFIC TO YOUR SITE
Web positioning is the MOST IMPORTANT thing you can do for your website to increase traffic and sales. With over 800 million websites on the Internet, no one will find your site by simply "surfing the Net". WE GUARANTEE, in writing, your site will be in the top 10 or top 20 or your MONEY BACK

DON'T WAIT!!! GET YOUR FREE REPORT OF YOUR WEBSITE'S POSITION ON MAJOR SEARCH ENGINES
A Website Promoter will contact you within 24 hours, just fill out the form below.

 
Your Name:
Your Web Address:
Company Name:
State:
Business Phone:
Home Phone:
Email:
Type of Business:

 

If you received this in error or would like to
be removed from our list, PLEASE CLICK HERE


eGroups Sponsor
From Michael Riepe Fri Sep 29 15:57:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00351 for ; Sat, 30 Sep 2000 20:18:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:18 +0200 (MEST) Received: (qmail 9203 invoked by uid 0); 29 Sep 2000 21:55:43 -0000 Received: from hj.egroups.com (208.50.99.212) by mx12.rz2.gmx.net with SMTP; 29 Sep 2000 21:55:43 -0000 X-eGroups-Return: sentto-1101623-894-970264532-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 29 Sep 2000 21:55:41 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 21:55:31 -0000 Received: (qmail 4490 invoked from network); 29 Sep 2000 21:55:31 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 29 Sep 2000 21:55:31 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta3 with SMTP; 29 Sep 2000 21:55:30 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00729; Fri, 29 Sep 2000 15:57:02 +0200 Message-ID: <20000929155702.35703@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D3F68C.5896123D@f-cpu.org>; from Yann Guidon on Fri, Sep 29, 2000 at 02:55:24AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 15:57:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 138df96db0d4bd737bcfde606b3dda48 Status: R X-Status: N On Fri, Sep 29, 2000 at 02:55:24AM +0100, Yann Guidon wrote:

> i do not dislike to chat with you but it's time for
> me to make some VHDL, at last :-)

`Der Worte sind genug gewechselt...' ;)

I have a semi-finished version of the LRU unit (my first version).
But I still have no VHDL tools for Linux, so it's completely untested.

While browsing through the manual one more time, I noticed that some
of the execution units are still undefined, most notably the integer
multiply and divide units -- or did I miss something?  I recently had
some ideas for the IMUL unit I would like to play with... is anybody
working on it already?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From "Bill80601@netian.com" Sat Sep 30 00:02:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00360 for ; Sat, 30 Sep 2000 20:18:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:20 +0200 (MEST) Received: (qmail 7981 invoked by uid 0); 29 Sep 2000 22:35:09 -0000 Received: from c9.egroups.com (208.50.99.230) by mx11.rz2.gmx.net with SMTP; 29 Sep 2000 22:35:09 -0000 X-eGroups-Return: sentto-1101623-895-970266906-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c9.egroups.com with NNFMP; 29 Sep 2000 22:35:08 -0000 X-Sender: Bill80601@netian.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 22:35:05 -0000 Received: (qmail 4500 invoked from network); 29 Sep 2000 22:34:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 29 Sep 2000 22:34:07 -0000 Received: from unknown (HELO mailgw1.worldonline.dk) (63.25.244.190) by mta1 with SMTP; 29 Sep 2000 22:34:06 -0000 Message-ID: <67911.84669@mailgw1.worldonline.dk> X-eGroups-From: Bill80601@netian.com From: "Bill80601@netian.com" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 18:02:54 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Try for FREE!!! (3531) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 6d01b0802d63c8b47d98cbb5b512fd1b Status: R X-Status: N Come in, its FREE!!!   Click   http://1061731905

Have a FREE taste, on us!!!  Click   http://1061731905

If link does not work, just cut and paste in your browsers window.

What have you got to lose? It's FREE!!  Click  http://1061731905




remove   debbie02859@kmail.com

****************************************************************
25227
eGroups Sponsor
From Yann Guidon Sat Sep 30 01:52:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00372 for ; Sat, 30 Sep 2000 20:18:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:24 +0200 (MEST) Received: (qmail 8307 invoked by uid 0); 29 Sep 2000 22:48:31 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 29 Sep 2000 22:48:31 -0000 X-eGroups-Return: sentto-1101623-896-970267707-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 29 Sep 2000 22:48:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 22:48:26 -0000 Received: (qmail 7491 invoked from network); 29 Sep 2000 22:48:26 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 29 Sep 2000 22:48:26 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 29 Sep 2000 22:48:26 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA19587 for ; Sat, 30 Sep 2000 00:48:22 +0200 (MET DST) Message-ID: <39D52B40.24592395@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000929155702.35703@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 00:52:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 99d60424a8cd5cd1e366c010f310429c Status: R X-Status: N hi !

Michael Riepe wrote:
> On Fri, Sep 29, 2000 at 02:55:24AM +0100, Yann Guidon wrote:
> > i do not dislike to chat with you but it's time for
> > me to make some VHDL, at last :-)
> `Der Worte sind genug gewechselt...' ;)
i'm not sure to understand correctly...
but i'm too exhausted to try anyway.

> I have a semi-finished version of the LRU unit (my first version).
> But I still have no VHDL tools for Linux, so it's completely untested.

i hope that Simili will work soon. Otherwise, i have FreeHDL on HDD but
i have not tested it. Anyway, if you have a windows box or win/dosemu,
you might try the first one.

Even though it is not finished, can you post your sources ?
i would like to test some parts and this could also homogenize
our coding styles. thanks for your help :-)

> While browsing through the manual one more time, I noticed that some
> of the execution units are still undefined, most notably the integer
> multiply and divide units -- or did I miss something?  I recently had
> some ideas for the IMUL unit I would like to play with... is anybody
> working on it already?

IMul and Idiv are often very dependent on the available libraries,
so the only constraint is that it could support SIMD data.
If you can't, then just issue a trap for unsupported instruction.
If you have ideas, don't hesitate to try them :-) but i'd recommend
you to read the necessary litterature of the field, maybe the techniques
already exist.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Sep 30 01:52:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00375 for ; Sat, 30 Sep 2000 20:18:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:25 +0200 (MEST) Received: (qmail 18765 invoked by uid 0); 29 Sep 2000 22:48:40 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 29 Sep 2000 22:48:40 -0000 X-eGroups-Return: sentto-1101623-897-970267707-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 29 Sep 2000 22:48:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 22:48:26 -0000 Received: (qmail 8431 invoked from network); 29 Sep 2000 22:48:26 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 29 Sep 2000 22:48:26 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 29 Sep 2000 22:48:26 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA12508 for ; Sat, 30 Sep 2000 00:48:22 +0200 (MET DST) Message-ID: <39D52B3E.132216B8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 00:52:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dc25e4d899931faf043020f1b4107988 Status: R X-Status: N hello !

Toyoaki Sagawa wrote:
> Hi, Thanks to Yann and Morco,
> > sorry but you're completely wrong, even though it doesn't matter
> > that much.
> I tried VisualC++ today, and I got...
> Speed fastest: the loop was completely unroled.
> Speed/Size : the code was similer to Yann's.
even with the duplication/interleaving trick ? ... :-)

> > it with something like GCC, but OTOH you made your Sayuri code
> > example by hand. this is not what i call fair ;-)
>  Yes it is not fair (^^;
so now, the discussion is much more interesting :-)

<snip code>
>   It is VERY, truly instructive for me.
>   I keep it in my mind.
i'm sure that you'll learn a lot of tricks, because computers
are going to be very complex in the future. They require very complex
coding techniques, when you want to reach the "paper performance".

> > >   Sayuri(ver1.0?) and enough volume of cache. How many core can
> > be fit in ASIC :-)
> > "it depends on the size" ;-)
>   Now Sayuri's equivalent gate count for design is 12,267.
>  I want to keep it in this range, at least under 50000.
try first to fit two cores on one chip, so you see and understand the
problems it creates. the technology to do that is available, but
the system design in itself is less easy.

>   Sayuri is written by Japanese Kanji like...
> http://www.morphyplanning.co.jp/FreeCPU/sayuri.gif
>  Left side character means "small" or "pretty" ..."Sa"
>  middle and right side, two character is "lily"... "yuri"
>  normally this is a name of girls, in Japan  :-)

Thank you for this explanation. I'm not sure to fully understand
all the nuances but it certainly gives a human face to this project :-)

> Toyoaki Sagawa
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Sep 30 01:48:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00381 for ; Sat, 30 Sep 2000 20:18:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:27 +0200 (MEST) Received: (qmail 28173 invoked by uid 0); 29 Sep 2000 23:48:50 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 29 Sep 2000 23:48:50 -0000 X-eGroups-Return: sentto-1101623-898-970271325-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 29 Sep 2000 23:48:49 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 29 Sep 2000 23:48:44 -0000 Received: (qmail 18088 invoked from network); 29 Sep 2000 23:48:44 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 29 Sep 2000 23:48:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta1 with SMTP; 29 Sep 2000 23:48:43 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02713; Sat, 30 Sep 2000 01:48:25 +0200 Message-ID: <20000930014825.05136@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000929155702.35703@thrai.stud.uni-hannover.de> <39D52B40.24592395@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D52B40.24592395@f-cpu.org>; from Yann Guidon on Sat, Sep 30, 2000 at 12:52:32AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 01:48:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cache design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a440cdacb6058f7c248d679fef6bcda8 Status: R X-Status: N On Sat, Sep 30, 2000 at 12:52:32AM +0100, Yann Guidon wrote:

> IMul and Idiv are often very dependent on the available libraries,
> so the only constraint is that it could support SIMD data.
> If you can't, then just issue a trap for unsupported instruction.
> If you have ideas, don't hesitate to try them :-) but i'd recommend
> you to read the necessary litterature of the field, maybe the techniques
> already exist.

I'm sure they do exist.  I thought about a number of fast 8x8-bit
multipliers in the first pipeline stage(s), followed by wallace trees
for the 16-, 32- and 64-bit results, but I still have to figure out some
details (signed/unsigned multiplication, for example).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Jeff Davies/CDPTEST Sat Sep 30 02:02:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00384 for ; Sat, 30 Sep 2000 20:18:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:28 +0200 (MEST) Received: (qmail 14513 invoked by uid 0); 30 Sep 2000 00:04:47 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 30 Sep 2000 00:04:47 -0000 X-eGroups-Return: sentto-1101623-899-970272283-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 30 Sep 2000 00:04:44 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 00:04:43 -0000 Received: (qmail 15532 invoked from network); 30 Sep 2000 00:04:42 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 30 Sep 2000 00:04:42 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta1 with SMTP; 30 Sep 2000 00:04:42 -0000 Received: from modem-35.elmiron.dialup.pol.co.uk ([62.136.92.35] helo=sargon.chrystal.gbr.xerox.com) by mail2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13fA8u-0005lc-00 for f-cpu@egroups.com; Sat, 30 Sep 2000 01:04:41 +0100 To: f-cpu@egroups.com Message-ID: <7FAD6DD85CD9224E80256969008325A4.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 01:02:01 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0572e87ca7aea6d7771f5ad14fadd7d2 Status: R X-Status: N Hmmm seems like the FPGA manufacturers don't like the idea of Free Cores -
Xilinx and Others now require very expensive annual
licences for their tools ($1K + per year). I can only presume this is to
reduce the prevalence of Free Cores (and maintain their
revenue stream?). Atmel seem to do a VHDL synthesis tool for free, but you
have to apply for it.

Perhaps we are going about this wrong - we are a bit stuck by bitstreams
being proprietary, and for Alliance (GPL one), even if you
make the XNF file, you can't program the device without Xilinx code. [I
might be wrong here - I think Nate suggested previously that
he had written code to do this].

So,,, what about a GPL FPGA design? Is this a crazy idea. If not, it could
be done in Electric, and then used to bootstrap the free cores
industry?  I think FPGA structure is simple internally (in the main)....
any thoughts?

Tell me to shut up if I'm being dumb.

Jeff Davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
From Yann Guidon Sat Sep 30 05:13:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00387 for ; Sat, 30 Sep 2000 20:18:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:29 +0200 (MEST) Received: (qmail 18977 invoked by uid 0); 30 Sep 2000 02:09:15 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 30 Sep 2000 02:09:15 -0000 X-eGroups-Return: sentto-1101623-900-970279748-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 30 Sep 2000 02:09:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 02:09:08 -0000 Received: (qmail 9181 invoked from network); 30 Sep 2000 02:09:07 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 30 Sep 2000 02:09:07 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 30 Sep 2000 02:09:07 -0000 Received: from f-cpu.org (nas4-111.ras.club-internet.fr [195.36.203.111]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA26031 for ; Sat, 30 Sep 2000 04:09:04 +0200 (MET DST) Message-ID: <39D55A59.82C7594F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 04:13:29 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4dcc993688100aed8a3eb2579ae4b616 Status: R X-Status: N hi,

so i'm discovering more and more hidden details of VHDL.
the three books on my desk are helpful, tanks to Nicolas Boulay
who lent me his book :-) all 3 are complementary.

little problem, though : i have a std_logic_vector()
that i want to initialize with an integer, more exactly,
a loop counter :

  type LRU_tag_type is array(0 to NBLINES-1) of std_logic_vector(LOGLINES-1 downto 0);

  function init_cst(N : natural) return LRU_tag_type is
    variable t : LRU_tag_type;
  begin
    for i in t'range loop
      t(i):=i; -- this is not accepted.
    end loop;
    return t;
  end init_cst;

i have tried some format castings but none works.
it's not covered by the 3 books. help ...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Albert Abramson" Sat Sep 30 04:58:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00390 for ; Sat, 30 Sep 2000 20:18:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:30 +0200 (MEST) Received: (qmail 31736 invoked by uid 0); 30 Sep 2000 02:58:36 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 30 Sep 2000 02:58:36 -0000 X-eGroups-Return: sentto-1101623-901-970282713-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 30 Sep 2000 02:58:35 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 02:58:32 -0000 Received: (qmail 21086 invoked from network); 30 Sep 2000 02:58:32 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 30 Sep 2000 02:58:32 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta3 with SMTP; 30 Sep 2000 02:58:32 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000930025820.NSMS6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Fri, 29 Sep 2000 19:58:20 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20000930025820.NSMS6495.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Sep 2000 19:58:00 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VLIW ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b8be1a0239e98b3888033932a539234c Status: R X-Status: N Discussion about LRU has come up again as though no reads any emails but the
ones they write.  Granted, DCACHE requires replacement, but ICACHE is
different.  Whereas DCACHE accesses involve a good deal of uncertainty,
instructions are accessed sequentially.  A statically scheduled processor
executes instructions in even stride, greatly improving predictability.  All
of the hints and lookaheads are inserted into one cycle's instruction word.

Harvard architecture might even be taken to an extreme.  MIPS conventions
stipulate that some areas of memory are to be viewed as constants.  We might
specify that the upper part of the address range is strictly read-only for
any thread.  You then have a read DCACHE and a read-write DCACHE.  One is
coupled to a load-store unit, the other to a load unit.  Since die area has
become less of a problem than cache access times and bandwidth, and since
most alogorithms benefit from this kind of access, it doesn't strike me as
at all unusual.

On the issue of the ICACHE, however, this predictable stride allows us to
build a Level 2 cache that stays in constant stride with branch mispredicts.
Provided a branch points to the start of a cache block, the next block will
begin coming in as soon as L2 reports back.  There's only a need to keep
that first block, so everything after that block becomes a candidate for
replacement.  You just don't need to keep it all on L1.

----------
>From: Kai Wetzel <k.wetzel@welfen-netz.com>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] VLIW ...
>Date: Fri, Sep 29, 2000, 3:52 AM
>

> Yann Guidon wrote:
>>
>> hello,
>>
>> Marco Al wrote:
>> > Subject: [f-cpu] VLIW ...
>> > > Particularly, the problems of VLIW (like the consistency of the code,
>> > Consistency??
>> i'm concerned by the immunity to "hostile software"
>> and the integrity of the protection mechanisms.
>
> There is (at least) user mode and supervisor mode ...

There's no reason you can't check the opcode in the execution unit for
validity, then nullify the results before writeback and call an exception.

This ignores the bigger issue, though.  It's becoming increasingly clear to
me that optimization and even compiling of code will be done, if not at
runtime, then at least at installation time.  If done at run time, you have
the benefit of branch history tables and memory stalls that allow for better
straightening of code, better speculation and ILP without putting it all in
decode hardware, which already amounts to more than 3/4 of the logic on
modern uP's.  It would be nice to use that for caching or execution hardware
to get some actual work done.  All of that bookkeeping hardware just takes
up space and lengthens the clock period.  It's just excess hardware to be
movved off to software.

So the issue of "hostile software" is irrelevant becuase hostile binaries
are not created.

--Maxx
 From Nicolas Boulay Sat Sep 30 12:45:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00417 for ; Sat, 30 Sep 2000 20:18:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:41 +0200 (MEST) Received: (qmail 12182 invoked by uid 0); 30 Sep 2000 10:40:53 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 30 Sep 2000 10:40:53 -0000 X-eGroups-Return: sentto-1101623-902-970310450-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 30 Sep 2000 10:40:50 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 10:40:49 -0000 Received: (qmail 10212 invoked from network); 30 Sep 2000 10:40:49 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 30 Sep 2000 10:40:49 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta1 with SMTP; 30 Sep 2000 10:40:48 -0000 Received: from 194.158.108.27 [194.158.108.27] by lh04.opsion.fr; Sat, 30 Sep 2000 10:38:09 GMT Message-ID: <39D5C42F.5DD05C6@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 12:45:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: multipart/mixed; boundary="------------570D9748A5361D3B92E3DCF2" X-UIDL: 7ada1a060a613eec61800b7452155c0a Status: R X-Status: N --------------570D9748A5361D3B92E3DCF2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You have found the heavier stupid think in VHDL. There is absolutely no
automatic cast for safty reason. I send you a diagram with all the cast
and the use of fonction from iee.std_logic_arth.all to convert type.

You need to use an intermediate value and then converted it in the good
type. That's why just make "+1" take 3 lines !

Sometimes you can see some limitation inside the compilator. Leapfrog
didn't like function inside function like "toto(titi(toto_val))".= Crazy,
no ?

nicO

Ps: "ne t'inquiete pas Yann, je vais bientot te repiquer mon bouquin ;= )"

Yann Guidon a =E9crit :
>
> hi,
>
> so i'm discovering more and more hidden details of VHDL.
> the three books on my desk are helpful, tanks to Nicolas Boulay
> who lent me his book :-) all 3 are complementary.
>
> little problem, though : i have a std_logic_vector()
> that i want to initialize with an integer, more exactly,
> a loop counter :
>
>   type LRU_tag_type is array(0 to NBLINES-1) of std_logic_ve= ctor(LOGLINES-1 downto 0);
>
>   function init_cst(N : natural) return LRU_tag_type is
>     variable t : LRU_tag_type;
>   begin
>     for i in t'range loop
>       t(i):=3Di; -- this is not accepted= .
>     end loop;
>     return t;
>   end init_cst;
>
> i have tried some format castings but none works.
> it's not covered by the 3 books. help ...
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -------------------------- eGroups Sponsor -------------------------~-= ~>
> No blistered feet. No crowd. No travel. Intraware invites you to atten= d
> a virtual tradeshow: Ensuring Scalable and Secure E-Business Systems.<= BR> > htt= p://click.egroups.com/1/9219/15/_/3462/_/970279748/
> ---------------------------------------------------------------------_= -> --------------570D9748A5361D3B92E3DCF2 Content-Type: image/gif; name="cast_vhdl.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cast_vhdl.gif" R0lGODlh6AOoAqIAAIuLi83Nza2trXFxcRYWFv///wAAAAAAACH5BAAAAAAALAAAAADoA6gC QAP/WLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6 K4GoNCCoWq+ArHY7AHS9W7D4q/12zd7BOT0IPN/wuHxOr9vv+LJ6z+/7/4CBgnxsamN9bGVZ f4uNYIaPXHqQeoqEl4OQBJubAwJ4oKGio6SlpqdKAouZrIGdhXwEe1mds1xnZGJpYbu8ZbK8 X6oAw5O+q363yIFenJsAqNHS09TV1tegAYaYgIWPjIacWuIA5GrPq7rbi6/jwGHtY8DbZLJm 6Me+a9/LzOeysrAJHEiwoMGDCClQaSDAE6xWECPSMwNp1sQ1udbtU9bL/1K+j+oGPUQ0oJMs NwWqJFzJsqXLlzB1qJSgrZ/EZBG9geRVhdiVn0CvUPk5VEBRLD2LHbtZ8t+5pk+jfnqwMKbV q1izal1p9MPIZL6s+LQydIqUp5u6oiyw1kgAe8B2VKXaZavdu3jz6kURAEDbCF2V9HXj5S+c vgv8+ghMs/Dex5AjS3b5ty80B5cFK8a2mcfcDH0ZTx5NurTpJH09QficRHRCxD5Yr657urbt 27hfdGw7c4lrltrUTFXQ2/PwBllyK1/OvHljQwwNH+n8wDHCNNIZ/M5RvAGVLtIbZndOvrx5 gsMcbDdC3UFR3pnxxuexffD5+/jzg+pewDrg8f9ErBfccWypAuBBAAYHHlsLyCYTgXQtqN+E FFbIAxhtaUPgekW0p96Be0mhinDuqaYAMUDUZ+GKLLaoQkMSsgUdcfMl4aF30ETBAIiQsabg AKvVuMONKWHn4pFIJhmBjjtCiASKOwpXGZJGQqAKELDp2NBx4RGp5JdgakUiZlK65+R0QioQ HI9hSuDlDbBBkMaZbdZpp0tqZLhhmkbwx1Zlu7DZIoeNBeHgAzDeqeii2Ci4IZ1F+LkAjDHK KCiYTJKZRXiQ3vAmo6CGSo2kffIpagow+gWifUC09+mpsMY6BEqkRmqqmgzMueOlsi65x4FX YjlfpgwZwmuvyCZrmK7/VnY66600jpmssMe+EGx1xlY77ba9EtuftjrEyW020NpQa38zjqvu uIQSIe66qEDZKrjw1gvmq0KwugSG3nkrgbHYerKWKkYlmhhtuzIgrXvJyTiVhmoibJ02KMnm xcMN5CkjkAWoAYHHEXO8MUr+yVRuDe/aq3KY+ArRchE1DawYxBPQrOZxDcm7ZRTEANqzdFLs eIFlxIAhWRs9pLZHLSs3fV85bbw8b0wiakFwFf42Wky7TVz7QxpOh42bAJwgzYTUTlCRBdcs qt1zg7+66Qg3FzFld0T2DAJQVHAtDUjed4tkEUm1ICz24RtoqNM+gTfu+OOQR66xBUexjfif /1ZUhIsglaxjyUYkSf444KJD5I3nzoB8+eqUb84K6VFB5QfpsJdu++2u6+0MAc6y3kHOsxQe iz3sDE9R6CUBXng7ZXfR/PK1QE88RGUTn7rswi/NfC3lvJJ8N6kTQK/vKpPxNwFpPNP8P3Ct 78rzygMjvPTan1H7H8s7/wr8+M/zff1OoV7ZTka+DGzJfBLRyUi+MTi7TS+AsosdWqAyP9x1 4yGR+N5JCshBzDTifXnrXvzud5Pa7c59EsmeBSW3O5GZJ2je6V2KNgU3m5gOJ65j4ApxR8Id PqJvMuxg2IYxka/s8IilM+LtWqim9BlrGEYZX7Hiwyp5TYBSJpqU2f8cpsW2lKxYa2nYxCQm Mi9M4GIRMsvG6JIZg41MAYaLoRUTF8WGnPCOJmnK9fimx+Th8Y+ADKQgB0nIQlYPICbZGyIR ScGSBFGITStKMwxJyUpa8pKYPKEfGalHPG5Sk+Hz2xZXEIWeECNuDYIh5aQYAirw5pEvcNvb UKGNRKJPLuxjJSR3OYdm9BGWJ1DQ3oDJAbdZjpdL0BcTlInMZt4hZZHSZQvUhjVnosyFoTiX NbfpGQLaSJpYGkbWuNkgb44CmuRMpwfQuCRz9hJBUARnndC5Emaq855w21AM5SkHdB5TIKXE Gj9PQ8+7aBOflzOMgXaEtoHUSmnDGWg1qPn/z6wU1DSuRKjYDpRRyXAtZxLVCs+qCVB3Kueg Gr1Xyyr6GC9ZJqTKoSZMX0TMCR0qpYpi6W0aqi6ZroCnbeLPTXGqF9eERiE6PU9HIzBHsrDu PQObKaaclBouSZWodqiJd6pz1eZcNFpjaVBNT/XVJRFsoDaby1KbY9QoARWr2RwlsezJLXom NVZDjUFRNOCGlyYmPg070Vutkle4xutTd51WYZtUKUYtVjBWUEGc5rLQq5TVsE8yaUq6Kqta BbZBE4JRp1AqDbWN84pb3FKuVjrKUXEWsySYo5VeWy8OubIzj50MREWknbG+JKC6FE/ENnPZ P+3Ht7Al5WqQq07c/35GtLbREZNEM9joEowDWVRPZypLWxnkNrmkZC5m0fndq+QsrLnqLltn ObQMyEu9JtAsXFN12iaBV7LDOk1163pWD3gtYjg7mHhRBV94fVZGRCrufU9AqvqyJLHN7O8G GFNZdFWsYQ25AWl9560MS2DAC0bBeqhTYGqF2APALTFfQBwr2X5YxSfuwI3GSV9ybWUqvclo cdZGnNRmcVVCEi4X2RJYm1mnsmL0MYyLed1kQnhb+y0Ik7ZbsePwuD/b/XEFhIzlGpLMbELN YmBpSOQ2mo1VwbIZl5MJLTAEZskgKC9w2KumvvYrYSy4milFKuGvRSFd3NqwRUkqNAbtav8t Dl4lX9a254QcNDVkxpKUWHwNEW1NoHBOmlieDFk6x5IQpxI0aapmNaKo8plHWVui4+DiDs2i 0pYh9Jdi/RcYJeiUhAjGUswXEiViEImOU+IOhSJl+QJUKJn+rVOXxCazmKVglQuKUoLBlF/v Ihc8Oca0d8JtRXwOHNXOrkKg2sGApuNiwE43Dlthw+PV7XFfmeQ5YOkJsfik2zvBdhgycm5c JGLd6r6hsCPCK7etuq4DHw7wAg5uW2DEHw4/nhF7cZExdDvc1AM0ZnHN8Nn9DYAQ3JsfQR69 EXZccLsz5713ve9cb0Qf2NYc3Q6Bw2vD2x82ScS153aT9DmD0gX/rEnAf40IYbf74w18SvF8 joZvR1x0vmyKsZt5dLxlPHB/zEQPWSjKCPbBhF/XXtnc+zluv/zcC3Rfya03P/nNA3r1k7dT aAH1nAz8k9iEq9AxHvav04/k93N73vLo9/jFwuuItwhHdFi69en9yuOQIPYO37fE89Hjfa/8 BDuZSL9FT4MRHHwjMd/Hw5N+6xJkIgbOe0GaY+QWD7+ECsORiahvw5OcO/ndVD9eBoq+61jv ++gYTvHGS76FPGPEsimD57VKd7pcquMsVZ0aL36CVS/9TmuR6umh9S+T4A+/+MdPfkFeakuw WMa/dZ473TvQ/QIsWylH75NkvyFmW6WK/6G3WpmKddWnFjAJkNNvTRdx+JYO7fdx16NInJdH DihyD6hItlQ9I+d1hCdy/5cUUeRfcTRkFnYiW6Q6CyBuE7AgwZEZk7MmBZIYX/YwlDBLTZYS jPEeyJEOnDYHdjRy9kBbR5U2pSRC5ReEQjiERNhCeyNVPyhrHFgjqgWCXxZGrXVgNIEwTZgS IehCVZgYZ4J/yJF3QyNOr+VKzuZs+xdjyGJwctF9y/EWqRNlONJqGOVsdbRp2xYGdZhtVjMW 0oZpY3hqZviHHQCAwgJ0uaE6/xVLfQaIilgvgogESmgvcIgyibiIlMgcAUWIkoiJ8LJWMLN8 lfiJ0XCJB3cYN/+oTpx4GGUBiqqYAqI4iqdwiqsIGpp4BK0YizRBHLQSfUnYgjzzXopxLTSj gqVhacjmh8NYirbIZPYXB5dYjK7oHOyUK2emOmM0LJGIZ5vVYy64BTM4g8QSg00EHlH0bFjA aEFBhsvIX+mYjHyFjOz4jvX0jPCYDfI4j/aIB8Z4j3YBi/rYjz/Aj/5YHqUUkASJYhtYkIrl jghpTaW0jgs5T4/4kD1FgxJZkX+iRhZpUeQ4jg6ZkR6JYs3IkStiGHO1ZREFHm4jjQzVV8Q1 jRUDZiKzZswWktKmRh35kTj5h1lIIySjcGTUfxhQkiHAkT2Yk0Z5lEiZlEq5lEzZlE7/+ZRQ GZUTUjRgUREMpA77Bns590G8BnC5l0CMUHZbGXNch0pSeZZ/KIA9xwq+dnfFJzhfaQuSoG8H +G9Jl0ImMXVouZfbtHA8hA7fQwvbgz4U523yRnGA+XbCIAbxIHX2I3Ef5Ai7hgk2F5a8x5eY iVVVcUCSc3cy53BVB5nsx3gEmEFX2XL54G5rSQgUSIKZ+ZrNdCiKA38NB5oL5DlogDzFJ5aM Q5cvKDp5RCByBpvEGWiCMgUwMn46mHWdx4DOWXqbJ3Kld4GNBIF9pHn/M3iLhHfPOXqA0CnP OCDFOZ5BdZPawTcBIQdOZDVLlldaRZ7w+TQCEx1sZp4p4IYk/1CP8bmfdnGQWjSfDLVM+EkH ChZLU8JUcmWf/Lmg/ziLP6WgseGgTHYBzMKgFnoKMqSfOTCgceWa6iGhiTMeO0lkHXihJjor KGlAEPohz+GhBzGi2pGObFOhJ1qjQnCIXNUEiEViHJpVfNVEKTJWomajRFpM0fgfOnqcc6KQ oRgok9ITCzOkLbAdIFqkVtoxTkJmBdoD55IphVClDmWWOfoD67GTK3qlC3lg3YGj0wEpJMkv zAGjIbNFW6ob2eEGonGmaPqJSjMePOoEgkZEehqKe1Bnp8WkrXQZpnWeJbqn5DkiLiqDgAoh 71kswoGotTEn/tdO68gf1yiMjrqUGv93kQwBpgxGqYgmMCDVKwszVFI6pXSyMKGKk6HhDUYh hZLaNe6kIHqpJCeopA5JJJRSMbO6lNc4BGwKGoMaGXoigu1kKDeyqqBVrPAIXYhiqiaQrJUB MLjCQSTINT06AtCUKtT6idYKGNhaAnWaSma4ri7wX4hma+VaieEaS70ai8m6oRnSWho6r8hU ry5AV6XwZhVWMyIINnc2gpHKAkYjrpOTSiSZiyVGMS6zrP7aJgA7TRn7rmLWsd4EUSGjRZkB qm7ErgKmf/7hH2rRhS1osEFGgqCqsKlKK1e4jsdqA1myfRfLSxvLsBYrAlNQhqhxkWTRh0Z7 tEJbUinSSen/urNKAoSdMKg9CzPGhKnKFmn7Qif+d7TE+BNF03KvozeNM3GGmZWy6rSjprN6 ZVxcO4ZbUjB7GBRfi2+XcK9idVY/exdK03UEopY39Le0CXzwV5k5BEFo+4qqmYCSZ3nKE7iR M3ChCZafp2obp7gel36HaXH8oEAgl2uLU3SRizym9z+Ly0eTFEIU9A5OMUDuABV5e7gZYLnv VrpiR7sVGDh2WW06l34udzze424YBLk6aLdC5Je3xz3xwD2BSbiN0A7/I0LsE3fd035th3qE QzufZz+tebuThwuFEwy787qwS6GhuYBtNzzWyz+1u3noqz/WiwgD5L4UkbmaMA/T/6u9+NsK J0S85RZ7YFl0LziWjqt7RudzANG04zsDxrt7A5xunSOXs1uVgnBHyueJ6hpnwokzIjpKD6vA cdR/3iKGm0GjKqEvMROzHwagU+i3ZFs3S2GYlDC/B3hpdHg1jJaHZie6YXtIm9RJDahBB5zA o0AwjfO+SVR7XRmWeJgPUDQWReO1ekYwTqxrvHCZpQoFGthsCFOpKFwBR+ZjPmll39pjYdRG CPqSn6Kz2edFXSAa0logQTunahhftadt9WdqbesGm5QjNfBJ6CO+Qpw2fgxKEzhBjat1LYQU cSuGeTyGbOs3H5AasnB9IzK1M2BujNavqChJ3DiOLUExUP/TKhHFv4FMIT4xyfQBCQhsVnP8 kBRbBzdbyqG1yrElvvG0iAI7xKQsywiRy7lCy/ZKDQYHyLnhrqXgy7zsEm8stK9KoLcintNa WsSGV7ssDc2czFm1zM2ibCksnFjRiOSBzCFSzdgsacACzHTwUHBqXHE4iTBhzJNhteVsLSZo JrbxMnJ6H+QWCsMpkOg8z4H4z+hBzHgxFKqyA9e8IuC6sABNE80m0DGBL68cNim2AZZsIbIp axBdnDJJFRutF898pEKkTLtI0bblhbC7MwzVjfy1XAxxZZFEzqnUymcknBLiV0Xy0RjqRQTN p3OEqzF0OP2ckK1B093chcWs00v/OdSMuIUwHWpKPU3unDhFNkcdZTOvIc8WicxMzTq2VcnE qlS19gW5uBUUaQEClTPk+6I9/a8SHdXIglvDBRjRrFvyejMDA9ev+NTu4acnqahnpqUYqtfJ pdVUdyDrrBfjQSwXfYxqOFcNU5QdTQrwnIyNfU+VnReXjdEGwlEggrXBuNmtZNgcVlGkvWDd kR1f9M6ijVdTjdY1gtXslNkkcNo95R2N1VtQ2S5g3a0EQdv4VBastNrhQtgUIi4Nu83F+SbL bNzBJNPFDAMFG6FG7RbQ3S3ObYmcNdE2ksIMfRjXLQrTjWVQ+IQA1oWwVFURkyFAk0VCttpc NtlPgNPR/4Q4wP3bMGs4ZFZkcYS1BguFNdRFuI2C0UcXJ0kyHhLf3x0gW8hQCy4ssGJnNtnI RhsT4oSzsbODZxjej3omtv0BjFBPt7yGYEjZbWwCR3sxbhtt2wZsbU1go9GMmkwZ+/wGrT1h attKF7niceuOBu2fgfadA97AgeuZYWk7xRPEnDGLfbXiIuJKPW5vHxFMJa5YPFYI2bHA6taW RRQSEawR/suWMAd7iTt8hjDiWMVxR2TEJzd7eGPEbB4+KjdtBcg4ksmVYFuZ6nfkECe7cPm4 OOERJcQ9aI5TWk7kZNtvmHs6/ua5UZeVMHeXZj6qcBW6o2t1cGm+1mmBcBe97f+7vu936Wz+ fU3hXnfIjWYbwAHcEVCBDHpuu7n55xoBtk9X5hJMN0yROtntWLYeOchLO6bHdPWgOW/nP9Nz 7HVDPOv5mTvn58GXN/flt6QH68InuPorfMBuPN0rnWILQL8HQaY36ndkQIWLdmPe5RYXDr+u ndoOvTjBSdyr7XwnEozOboXXCeClIcZXQgx86Uhk5I7TmnpokzuV43QsTbF2RbDQuKj37f4O fNnueanrCtZu75Tpb5IAw6mZQROcOucXc7z7cOxn6wCPcaP+787+OinnjC/Oighx4TVY8tMO 8UQebhyveDuUR0BzrJUz463zMDi2RdYxRi40MVDQscP/kYKGyK0fWGZ42rHl/UZRIvRq/Nri angQmL2MdMjU7ug0p0nQRuGOHJS5bSieALg1v+XvtkB1mQ/IhygL24sJrQFCNl1Ub95whIUP jmBaNBzVCDdtQE2CdTB9JSVDMYLkDEXxJYHMOYHh44CkO/HS2TeUT3nViXjdCZ2Xx5ZKkdYV Lr6YXH88WLSezAKh0eQ/w8ncmI/wFGlv0cF5duMtMMiEtLrT6cNwHg9PrId76Lbf48hN3q2I xrZJawo/KPpwArdnfQIkRkzmJlANndTVrcCyH9EpF7CdHf3a79ER+Y+xrChArVdWv/3kCc6a 0fIxPveSZcHkb48VnVUAqVHx/9+J09/+G1W0E/Xh6dTVtIgAIRvlD6OctNqLs968+w+G4ogJ QENqwICm7gvHcqAsAt3K+h4qOQ8MCofEIs9nTLpoC8CNpoxKpx4By6FwrFCBweDhfXQBkC3H Org9rFwAucBeX7XfwlgybpmpuwYOZ2PjFMiAw3eIOKOWyNjo+AiZBTlJiff3RGgiyJCJ+eTz Fyo6SlpqWtqZ2unG2urkZjKo+vlnh0cCVam7y9uL1AscLDw8Ykh8jJysvMzcnGzsHC09LfxL fY2drb3NHfPUDR4u/mg9bn6Onq6uwbDu/g7PVxNPX29//wKKv8/ff1jzw5/AgQSpMFlUMKHC hbpCMf98CBEbE1ERK1q8uA7QN4zi3GDUSMghx5EkS5pEBoUiBD+FFDgBlRLlnJVp5AhwYOUE DTM4BuhEFSjAClleGAzFseLTHnY1JcQ5CTWq1KlUq1q9ijWr1q1cu3r9Cjas2LFky5o9izat 2rVs27p9Czeu3Ll069pdYuuu3r18y/qxdUqUKletvBheYdgLYsSJFbtxTJhwrMiUK1v2+ZjV 4cacO3v2ErCv6NGkS776jDq16tWPfTpevRk149efh1qmrNg17M8ECAzwfbO08OHECWpu7Ht3 beWcj+vOvfj17MNDG2uunjg6ddyQp2Nmnri3+DfFy5s/r845b/C5fz8P37v/s/fs02cvtg39 vnbd129Hdt3afLuJpxh6Bh6IIDaasLfcZuNZt4JvjxH4HmFe9DYhZgAQEGCGG0p4oYYbaiih EwSOeBl21QmImnjxJQhjjDIKYwUaDK42nhsnnhghh4V9F+BvybESn20ZiuihCdu558SS/WU2 n3OMtQYhgb7NiGWWWvJxgno3yufTiUIqxqOQICIJoHXQGZachiG62V17/uFW35qw6Rifb6Ft yWeffoKAUI3gsdjel7F9txmVhd7X3Ip25hdnZZA9pyh4eV5B3p+absrpAyfgkYahDBLq2X/Y ydkcf4VuByWjFv6opqE9uhecHZ92imuuMN46QRdK/4oK7JSypaZdh0aiOml3cy4Li2SvvBLL hcnVWsaeul6LrV0IVeDrZLMQIossmmzy33vmWsqme2/6xq577b6r7rttJncpZ/TGG1+684YI 77QWZJptwAKvVU4H0pqZp4sJK5wwwvRa6a7C/LqbLsX3DiqZJuIW8kSEhvnxlxSSXKBAUwOf jHJJI/PSBb8AI8PYkNYasXIEP7g0c8o67xyOCRnUDMzBOQ/z2w0vI0LtLRFsy3PTTivokwUL HDO1GNwIBUnSNg/9dNdeByMUaBVUPQzZ6GD9iNZfr802Mb7avDTXWcvds9qH2C31TG3vzbcO LR/tFN2OmH0P04kADsfSUf9b3XfjjncgFMA55cBrNXjjUzkjl9ux+Bq5PA566NVikDkwQCdU OtIXTC5666I/NTZKiBeumOEFzE7F5nT4tK3trv/OaUAt412w6bjX44QlFKDtyOl2/HAU8NKv 7TzLm39+T/JLL3+8FHafHnbq04+fYMn0fd/9JMxjED728fyqOxzxK7G+BEORj7/A1e9SP7do zL8QwiUCfPkr4Izktr+GHC0g0SuI+7hVIC0Izgjpk4NPJmjADKrFRheEgACNR7LFWCQgvzKZ BD2FQSIAzkYp1KALz9Ky0CSwEv3DQ+ZmWJBtdQFkvapgEmr4wiDWBXZOASA5upeHlUAlcpXT 3s3/fEgztVFOMS0UohVLYgNPXWEnVfyH+LCAkzpkJWxiE8MnlmZEI3zwZia8ohurgoYI6ERv 1XgZ0IbHki5WpGVt9NTosqa7v+nxjYTEXBntN8gpCGVoiTzJA7FQlAl8kQ9kY4IJSzbJQmry HURUGiJlR8ISbsct91MeCicxtZT0sWRp3KQrwSHIC2SShrM8EBARUbpSKvGVvDRH+5zSxlqq L5OMaWVazJcGa/lsEqlbChzECMZeSnMameKj1oQZCWIeEifGHAvsclKCbgphkRyI4TTP6TYG 1o5p2DzizZApvI+Vxka+O2U2c6bLXaJzn5rLHGJm1s5H5JKKOLFkJIez/8O4hbCRMzhaO/gJ UV80kAIBdUQtyZjM55XPNpdbZjbZFwuGRnSkVZBbRRtxUiyI0y79gwYFPpgIj4rBZGETKUlv ugF9zFQZKYWbjEzwA5h6aqVBEGAO0NBTnCoVBLfsxSxj4TuijqaELXjkHwFpszb2calctcAv l2crmyahlm2UafBYCMmZdaES2uRdV98KzKw+kaczQ0NQ3SBWTpnVotDTmlXhus+W4eGhO01G QK0Jxad5hBIDzUFTAXvOvxFurYbNq+i0x8ygGoZaloWsCx+7i6S6ULRAoOxKkOqpxHr2jaDV BWZH2lpFqna1vYwtY6X6lcWubps4GQFulbDXRv/gkLa8tC0qfxuF4ULwnWuYXRi0uEAIHNSr DxyFSrcGB+ht9ZTru9VzBSsHFMAuKb09xGvThlziks+4WE1GjaRLHt3uNjFVfS7n5mDOMEKT cXTA21J4srg70AEFvLVfB2my3/uGxr5JvK8WO9sD0gLhvOolZHCDIVQamey9YbzeBALM4ENu k7faBRjaBPw2LdCiDDSFhbX+qombERYLEKbZbIvQpCtVOIgZZtmNaehLE9dYHT1O7ojc9eMd Py2hcEjy3Zy8D5A0yzIhociQNXCJJrRiI9ygIyO6EJ8rK5lTH6KQhH8I5WvUgBVc/shkxDxO Lws3wQYxxZhFIwAXbZf/f2kehkvwCmeI/FmZ8ZvMuYAFJkQretGMls+d9xIA4Li3z+SAaqC7 8mfrhIZUi+b0otsUnhY1GtFBUlfnHr3HGgzG0LAa0L0uNupS0adVRqrPddzEHVcACUqp6eKf 62lLLSNHXSg4VaJjIyBF4efQsV5Ps5XDaft8SF2oHiGz0VWxN3UmX8/uNmuCdbBtrhnYKTP2 t6mjrjqdaz7cvlG7Qe1tVBXJVbXOzGSIxO1q7zENXorVsPWlbXvFe+DnJjXD0nutnBDLTIcu UqxiVqIxhalNHhtTa/JFoXc/DN7bzteRLf4gbmPc4RI/2KykVGb3XFrf0xiDp0UNn3Z7Rs9f /6IQwWFeKVEpjNIJT1O4AURybk875wJHzLwdbmabb5xNI+c4jpQu858jB0RJj7jTc/OulbNc GnCSk9EdZHOHRd1eQo8XgGaV8bA/TDU0Z9K03R6ioTPcNRiquLTYNXasnyh0Obk41pk+pJKX CdfV0XPaQV0vMjEM8VO/+s0blB36QEzrW3dG16nTdoTdfV55b3yZOb/2lN+9R44vVdgZPpsH TV3vMZc6213Ec131/fGKhjXtRWXrY7kp65VnSL+zjS/DN730gGd6thff+s13fttqSnzxSUT8 UK9q5pdyHEal9KVKqfv23B8VfYw/3d4X5Pefllj0mQ+f7qvm5dNvkf+em5ELl66OV2FD+O2Q aF/+Air2XoXF8hBFamrCfurXbfXmH1AVLe9if+LHDfdGgPEmLA/IIMgHL/LUB/IFKKe2EhMl PzdARAV2Wg1gNtrDYQWQf7diBYpDHtDzBim2Ap4DSZkSYuShgdyCV5DDb2wGLoEALbpmbs4W MWK3eENIhEVohEeIhEUohCOneXjHLwvIgNoQLY3meOcngYMSbxBjYPlnRuNSRQLGOStYg151 GOH1YGaoRf41E+TVZDuRKS/oACDIYnTGhXHoZWBogvjVOacWOeQWAvwyhA4jiP1iMUmIhBHD MBRjKYmogzYAE4ERMlGIFePyLLCAgJXoCvf/pmXMwh1o4m6vNiaGaIhLKIpEGIR9YGnCI197 wGT/clczxSs8kU/5RE4qxRIzpWk0FlR/FUUu1jM7h0uIGGaSWBeRVorHiIzJmIhOWIHyYoSh WIiKuHQi92+rQXlmtGXYo2ohEQkiUWf3xovdIBRK8n6O8BtkkILEqD8Oc4122CaD5ExiwArh 6AwHsYmW6Ih2FhOGYF2BkQpzkgneyBEeJWfD1I7qyBZrxi8HaUElB4UkY2lwVWTBcGYIiWfx 9ZAhsFjs9UNBMU0UJg0TaZHDUZH0w39DsI0MiSsgKYUZOZLe5JJJcGHP0IcqmSAliQwz+ZJ0 gZODE5PCVZNO05Pw/zeUOwkROulBJ0kJIrkNTPASNpkWRXkNUmmUClGCHgSV3jM/gzYOLjFj 6EGV3MCSVckRbLRASpmT1oKBY3kOXpmVF8GUAxGXZLkPN8hizfSWkDBLZKQTArFm9PgVcxlA P0mX2xCP8pgQt2SWIxSRWiGYjJmXhdk8G+CH/gBA4RMVgxaZhkWYAlGZknk1gYIZScOR/uA8 4+hYGGgVKWmZmwkPnwmaIemHsPkQ1cOGVxUW9giY1ECbgdmZsUlDvxkPOKSabqFqrgkCYTkV ygWcErVdvWkSzDkaurkL0Ekw1tmc/COcBPGY5rET3VkMaEkWvpNiWCCe2fkB2IkV0imdpP9h j/mwnTDJDsi5k+0ZFkKlB8Gxm+UDVDljnwh1TbVSf+gpAtijJF+ZXXuBn0eFGfRpFu3joFxR MzXDlgTqUzaxPPEJR+gToWhRmW6JYy3YoeFQPHHIWXIYm461OiNqEfXUYGZ0YFlSkiBKAkAF KuShngMZT+d5Z1Y1WRp6ny8GVX6So0x1nOVEEy3AYZHTXFlRpL0nPIFDUSw6FU96HlaKigiq AjNho6l1Ff/JgBgIU6UJli1UU8KhnEFAoxlIpdEApuLXSdd1LU8Vo/PUph+wpi4Qj6zzUmmK EkBKSIOEpbsyNP9zp+OgpZJ0qH7TpWC1EkpaK/JVguDEnYtqfXX/CpGKtQGHORZfJUcOFGNI GkZKWpCgAqhzM2ZMc5VYyTaxNTmW6qYhaEMjgTOCs5t2aQeDygy66kbxmKdm9Dg10wQ0Zain tZw/46f0EKrcsifliatPoQl5oVAtqVTa1VGwqhcj0wYvgxinKo5VpSSVQ6ZS0YeQk6uVowaR owc86pMQFS3QYoP5M6b0F1IkcZVDwVnsqjLLCpGZ4VhNgYe82l5cJbBdI1REhJTGQW7jep0I ykPck0bjCH/e2jYM2zrkSa4yFiNHGgMgWQhuU7Cvg60yejNWAZ7eya/M6kleaou2gqNJiUoj Sxqr+qn7dEN5o6+8SbEslbKU+Tlxyjl+/5U2MisXlLo6O7s32lRVRDsEJ6srv/oBcNhhM1Ur TusCVosrNPtSTIstn8lEXOsNSCsj31mgfoCrxSkPYqugfMg9xKWYxFqq54C1fKOuPaC2RXQy zqRMYMszitkGtcO3PputIStJces9L+Gmd+sXHmCxS3WaZRW4UqO4CqGij/o88ZcSiGtGLoWa Z+oLPWs5moJU9TS3UwVnQKsLEwmhkZugDFGLeTFe8cUrJoS6LyVuMwFiArphW4SpdTuqzOC7 xsO6JFGi5YFAtxCJGiV/gCFjlrSoMPWjiUo1w0sEEitX5im762o/W6mk4gWwT2mgG8YrIZWa 6Uq4iAC1zRMok/+rFW+KOdWkBW8ou7DIYoITu/CFoS67LSajW6y4u8WGuLnwrHsGDKQrrsm6 AwhcltaFZeJKvUWQviLDR8kRI+e7DnGajirGsmG4vTn1vdDUOUvqQTG4Bt8TwuKrNTbqlc4g PuFDLQn7ZDC4nvY4CJRRZbTgEFrHBVmmidIbmriKZtr2wMPJvq5LCkTANENcoC3crfhLDhCC tviwZk9Jq40pjr5oY3XYFwocnboICrOAiZxow5mYiQF5Ru/wusTAGUqcU154TPXqVVgWCh64 CvcmKVdoLvixInosxk/ybGyMCzkLD1MMvpTrlRYsMoKcAk3cllZcGpqZHRCLx5NMyWD/5y/2 ULqDPI6IDKqaSzU5CzKksAoRGHns4Sh9rGuGC1JYPCMcVCpcECqVLMuKNoCrgnFFbJKAnAJO mclgAbXhNwE1gspzkiyE8oO1nGyHUsqzJh3GVixEx2h+Bbo80yTA5221PHDLR4CGF7E7WC7Q 3H3gvG5IYoBsBpBTtmUa0wRQxYkoKsesjCVRolni/GzeQcqlomyHYh+IssdxQs7H4czkdyOp N4ZJi83PdnUc54QBJ3NrV3yZZyilZ4WANx4dEMaQos8RGB3S1n6zjHu0/B3c9k7TfC1OWUxJ 4dGUotGnkhmTwmvKfM9w4oP2vBscLWqKLKMHHWunJ3JN93xm/yJ6yed6o1aBrJGIFm1o/5wi ytZqrXZs38dsjLJ+dqIiVELPi1IhtMEapHeOoOMrNX3NFXLM6BZ5nXh2pUZ3BXdt2WdqBd02 As1o7dJx4Cd8Gbd5dy12FN2EqSHX1tzWfQ0boPciHNAfhJfKnQgrugZqGw0kyULVzKFuU6If y0wppQzQqYws8iExuPzIa41oHqd0phZ4Cf13unEmQ3JkOlLaplZx+pHP9axtOB3POUfafA1z M+dsUAfYAUd2Ei19ft1siFeOm2rHT2IqtIbc6uHHrFJyaV3KEPPbMXN37UfTd7Jw3waMwRrL CC3cpj1sp8J46wd13v0e88bM/IzPnf82d3TWqj/IHOGNLpwnfcNndgsN32b327zNHr4t3H2d iIJTLs18LLfGH8kmJuNtfFxNcz09cQ1Dd06n06Ry1cshMV691hPN10yIhejn0M1m054NhK9H wV7DlYrzbxPtdLB23wIHitDIjP69LnOnzcCt3wpt29VI0XpyBvzGKnRSGPuhzA3+04dH3z79 11YiIRCNbB/92cPtOCCO4/m94ikN2VCucw/d1s1BHEDMuCQdzIqC4Y9t1bymfWenHP6Nd8qo 5mt+jPYLgOcN0LWh0zWncbhNcHNOfflCt/43BlF+4nZ+5lQugKuC5+9NIP9qGIMFz1PgCZs7 D6mlE7dptPT/WIK3WUbg1Ypn+Ez6aV9LUUYA9gaXzqk24+U9QIpsjuqpruqHyIT2jc+N2BLS KSiy0dJxDtXoJ+gpjXz6Ldt1ZKvZEMEqJt3dluKjBuTHHRmCUMZaVty/59BpjuSGRzFiNW77 uePXtIZN4en7lRRyM6n8i7sJRqlLYVX/NQe3qem3UxO/psuP6hLKN+I2xsU16nO08SNjHuS5 ru+NN4xaFEFd2Jfoqwb0KoIC6mKe62A0xj4n/CngxcFNaiupBcDNZbaw3PAZGbwWjevOuOrC N4jMKI2A+OItrogHI9fQHeNBaDFSB4onn/LuPE5T3Gb9l0xHdRBJqZ8+jDS0kMFY/7aJnPwM NtIugmy9yuAryT4uO7jOGwMu+FrDPXjHP07gA8h4r7YwHb/qqlxO7D5hXrYUHLbtU+S1J1y1 eiiGgAMT9CtJfRbselrfxufyhChxLl/lytKDnSCQX2GPzV5lkOj3p4AJ21gZdtz37a6mcNzB RdCo2XDqWO/4jw/5FLjg+K1yIsPs1m6eaZA06XpUCFG8ObXLNqN7DMXLQG+hrov4A1Sh6ykh 9lfixDtu+FgLbsqPgqEKmH/6mFbqlGT6FZFngWh/+Zj7wy/wnkwJj24XKafAbU/8zZ9TXF6d 894VMFxa/uf8zq9qssPZWbH6EIwz12+RxzmyOt8nyF9p3f8P/rAl/NLw+QPT/o2w/umvScwP vL2cK+9//B8r/17tlggQtdz+MMpJaw1C2M27/2AojmRpMphyrmImqGwsz3Rt33iu73zvm4Eg IAP7GSfEo3LJbLJeThqGWIxar9is9lLder9BV/IbxZDP6LQs2FWH2K+ge06vc9rrxWCAt/sd cGJUfX9GbISFiYpkbItAU4OOkk6HUAtmUygAQ0J8DAADACgXog8CngWnGgUBoZ+oBaCXoWwD Gq2lrKCIk2+HkIIpv72FwsTHyGCWyTOBLnLM0REBsoB7KHsqu7O5era81qWnMNCmsNWxtuar reo7Cr+CYkNDwb+H0vkrKfr9/k7/y/41uQdM3j2BPqjZWiYsoBkU4CDEE1Rvk8U9e0DVi0Ow HMKPH/mBHEmyh8iSKFOqXMmyTMCWMGOeeCizps2bOEeezMmzZ4edPoMKHUr03cuiSJMCOqq0 qdOnNoFCnTq1EdWrWLMqsqq1q1dWTL+KHUuWhLGyaMdyTcu2bdazbuO2xSe3rt2UdO/q3Rsm 4t6/gK9M8Ru4sN2+hhMrbjZmsePHFxpDnnw3TBzKmDObvay5M0/LHD2LHn3DskfSqN0445y6 tesskE6/nj0N9DPZtHPrRuYs724aAgBEJFdERZHgClTxICjv9trf0KOjrSSGICuc1BigogZv CDbhrK4x/xjnYdP3VzBONdiTARQfhRtDvXBvcR6t59Lz699f7HrH/wCaFk8lwjDHXjzytXff KeClAssC22xg3iyrOJjeg5tUQQ1HHlHRgFT8hSjiiEXhl0cjhIGAIokstujiizDGKOOMNNZo 44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp5JNQRinllFRWaeWVWGap5ZZcbmAcPABS ZNEmGJVZZopdpqkmVfD4F2BBzQUX3Jh00hmKe3dipFGdfM45J59jZoRnmYOa+eCaiCYaTaGG Nuroo4BGKukmf05qqaB5Ckpmphdtquee9D0q6qjuoKnoqah+QQ+prA5AQKuwNv/KaKyyeopn p6HkSqann/aaK62GgvLqsKamauyxS6wK7LKsFjprRpCGCimnGul6p6V2Qqsts9AS8KqrFSIr 7rhYDGHot9ymW62uoGZ6ba/rEvqrmdLuCqqd9PFqq57ceusqAeGSK/DARlyUbquMDrqpwbfK G6ys8/I7b7sSdxqqvrxKzKy3/nZD8Mcg3zDnwaNmTKrBhM56q8mOKpzttZPCjC/D6XLsrcch 56yzCSiT/DDHs3Kscb3a7qqpy/R+atGr9lLap9OVNm2twrEKazPOO2etNQd/ckv1uUwry26e N88c852nyMwr0/92LOy8I5fpdp1FB0qr1UJvrffeFTD/iHDJjgr977VAbyL0urga7m3chpOd a9iuOn5R2G+be3Sk7OL6q7OyCj4A36CHPh7LB4facSiH/7v0zdvOfHq3BLiHLut5Vk5m2KdA TrnUgDr8cMsA2Cye6MRv3bPXLRce/OmsW+2upIffHrudZVP/LuWR3y7z9vEWrXHJ/vpbbPHk q9lOxM0O/azyhav+eOzU7slv9bKjK6i/veLvrtIpXxoo6aJSXOQOVb4CIisDDnpW6Uqmvek5 C3PvWtj/MJUve6HvXZfDVsIUCCn9xc6AIDxWdhYgJw4Cy4Swkl3k7Dc1aWWOYWZrYdNgOEEA Muttw3JBCHeIKIdc0GfqOh60/6olv83F64guhNfE7oWtWp0wfK6CR8B4SMUqjfBDtgCiFn2H qaRNy2JElJ8E1TZEu42RZA0bFrjGM74qutFHTMEFClOYwoZt63f7CmDtijg0TcFMbU28oyD1 qEaAfWiKb0ykkWjyADluUY+Aa90QB0mvlcmwjBl8oQTPxjnABWp2UwyLIkfZI1GGJ22P9JrJ xEjEitGNiXX6UwnjRMta1pIekuoWRgzZSESS8pc3YuQ0bNHJSlrKBfWh1DzksRFb2hKXY4pa Klm4BzW2bYUrFFohCzlAUErAlMAMZ4saVIF+VZOb30pnNm2GTnRis53hE97gumkmdc6umo26 p9ywOf84KA7rn20DKDfxiTUU+JICvhGnQkkjzA50M57s/Cc7HzpPiV5ToNl85zvbqVGNcnSb A6SnNUNKzf7Vh5YFOkjf/IILcC70pY9x6QSCh098bhOeNt1oPyn6N5nVchhtnClBXYLQDMH0 qKJBYAnwEVQK8LOpTaipKwCChysi9aqYKagW2qE/qA6EpOwZyEEbkLaxYvWsbCInEsxqBVSG lK1qOB8BmWBK7wACrXjFSkRkioUNZWQS5GkoEwQbAfLk9bBNYdBK69Cg4CzKq0/oA3wgi9jK lqQdbSAsI7SaDKVaQbOWDS1RBlOECJGQsjywq0BAewS+iva1OElbZuEKG9r/MsO1RjELbHf7 D2FaFUKo3YFadcLZ1qKJGsXlrXInoZGq2lYwyRUIbnXgWwqYdrnYXQQuevmS6Gphuv34LVW/ WVp3nDa76PWDbNdaB9aiZLhi9dJU00tfOngEFJKJhR1UG5Xn7sClyqmvgAEbXOp6VyXije80 XlLWATuYqKSwg2d9wt8ouLQd/n2whm2gij6AlxIHRkkX3PsDzSp2wyg+QiZIqJFwkfi7GQaJ Qsz7iQKXII4a0mGKd1wa69o4B/CFyYwJ8WKTmLW5jaQxj5c8gS4gB6ExBkiUBXJdH2chLBMi a1iZzGUVZSQMDviwgr+5kg5lhCkThnCTt3zXLrvZ/0thnjJdzSpmaQS4AkGmKx7+2kj3yPnN osWNBUIMXesqGcFO1mqaKWHbBgOax25diAWKjIVFS+TLNQnOfKdB6P8iAsmPfnMY8NSGOjMh z99kM6IFDQFUK0Gzm4aAqUONXkujwdYQ8fNVEtyEIP+Z1rzFdZjtwJ0mF2d4MRmfq1X8a2Av WdjKuAAtPnQTwlwR2sb9wJCdrdxlg4XYQYZLOuTz417wAgN6Mo63S0zbGTeb2290rDXew4oq zFoJwsZIufWBG3SzuRzYNoIp07ZueGN1Q4fkxCH9sO52FLzaM/4GwGHB68EikkH7NngVQS3r jNcA2oYlIZ+R0oqAMewBD//vQac1jlffjvwS7y6xqz3eEoVkdjwxjwGlWY7XE5NXwmyVt1fk +jlzdGPlOsBayYnDap4rkpEH3flnC07w9tAcL+75Zs6fMFaOO32hZYUBfleR8itAe7Iwv/dn 6IOIii+B1xWW+teJN2J0V+jQapj5l9ji9XHDt+yepsB65z5Kf1doxcWug9BhjnIay90p/haO hnC+VUQi1xKDITwPPXbnVOCX4VVtfJm23hOHV5XGSM8BOFtxdc0nyueXcEDqB1Lc1vvE7Y6m PGywlqHjFN31BmR7nEEPiJtDRiOc3kKD6jE8h5vD9sA/UrEST4fFQ4hemHcMhq18ZVFAo8ps jH7/yPQtAfEGXPlt1zShFDP4SyBGE+j3T6zRLv6QEVwixZk9XWcPfQpzwi+ApwOWtm31NzCy QYAdR3ytxhrScX4J8XcXMm0FaCzwIWvkB3/gtmbZ4BrvJxH6x2G+1H7XMYHGcoHURlakl1oa kmUwh2me4W5tIgEBmAMJFmtpVmEkmCXQcH8e6Ae8Rg7zFmuQgQttQn2yloIn8BKslXs5iCWs h0VKpnZH4G2ohIRs0Qof4m1GOHUOhXdNaCVMCAgf+Gq/pwkvJ3IHwlBLkV/DpwVaqGpfKCVE GGZ6IntWCGRR93kL+BoEB4TJV3kaKBFSGIcv4nsb2GRjqGI4U3JaZib9/6cWSsaCrfaIg1Zq cEiIVnSJ57VfF4cn3eWFDKVVCcViW+CAmHglRoWB7ZVccnUcvzFieDJTlIhns3iK+7EMkTZX sVCLJICDSKAng/gY7rYBptgDwlaFvGiLSUUorrgUPhiAmKUfHeYBbvd2BRVWUpSMyvgbM+gE vogjDCF8shh/DkBxoLiNi5SIhqCOIoJhxMFeW+UxB9h06JgjDKaNIfCN1IiPbMFg56gL/Ch7 faBr9Sh97PiAMwEjCCh4d0gC1ucNx9GQBUkb2hCQHoBto3aJ9KgfO6EQReUFw6WLIziROlKN YECFdNgNFskX+cILIjlnbRaEK0mSZMGDbdaNvf9GWxhHVvb4ctuFBAfJAluIDYdIk7d4bGU4 Os84kKxxPgpXkiIwlBY2RUVplPwRjaMgkAxnVuczk/lRjMshj4b4DVb5Gqk4HhgxRSbpBWuJ ltPmlbvRlgVzcaoGl2U5FAspg3bJkCoShlWij4OFM2r1k3fZGiIohkupMw9pBfDVCchWmK7h HlWAkzCZNVIJYo1kb/8ImUkVlD3wkh8DmNZ4el+2l5xJFJS5BItpmZ65AjeoaupxmqjxeFGQ msdim1LwIKYpm6OFmwInkWqymlLGm7oBllcAmooBDgl1mcfAnIG5m8QZFL75A8bpCKMIZYcn J5N5eGfIM294KBuJiIz/BZwiIJrRCRnVWZvQOQMVppsTUJTIV3zrsZk2gJWxV3ynAQcqEHY4 ZxlEOR/0WZ+tORMDep5jMZ0IaQcBWn5C+B0aAg9FmTaZOZ9jxQ8TVmxYCZ+rEJtEmZVoqQJT ZVjyRpjpYBzDU5WBqSrraaArkZ7euKJZKIEAOaN9A4zzpmXsEKGPWW8NEJ8WWCHbwIjhgQoR gg6FtaNDyiFDGgHNN19YCX6nRp4hIJws+hfOuVmFcGd3poekcCaz8HvtMJ8ROKGvoFWmpYfk 8WQipw2geZgFgKJvOlfIdoiECaUpCpLpUaWA4aK9BqM/+goVAnvEOF9OOqfmmJQjeX04s6Hm /xUhghZg9hkB34iNWvZ/aElO3LETbAhicIlAgqqnbiGX8bgIPlenoNlQsACf21GVQuqh3mCO 4QIFjMQoxqGE4bkS5lliYZBOfgqqxJCrXsCn5UJjkTBpKvUhDzppjJF/bIKog5VTr9Krvqpd BUqD1QoGHeGDoaEVyEmdTzWtQ0dW0kpCUipkqyFLGiQnyOQnz2AQt9Ec0BRLtyFd1/oGIQWu WiEAhiSquzeug3WuylQdHHKrcwAHuMSAk3ClSiAs9YqvCBEANlOu7Cmx7VUpHhIUQkAp/opy FNsBn+qwJBdQ39KxZtGwaWAZ9UCwJYIB9VAMJqusvyBxHfECNHtLl/+SLiQLsiAQUS/LdTLG rhvbC34CfWAys7QkRKmUtD3VMoI0R46SszrrUEIDtSOgsNbZHpuaGCx7FDv5nlz0LIgzQ/zC R5SktKPCQtQ0Uvm0T2xbUssyDFF7nP6iXlRLg0PLgXMComkpgwtktrvkM/rktyf0tdbCTXHL mAvqhkEbZxrLkY7SBU5bNUwruJS7LJGbMJkjss56uNQlf+/xHzVrs3xSuUnbMEbTRd0aGY0r ImnjTt/So9ZSOpjbSqS7MbWrL15kL/jzKpx7ab5jQ8jjt5F7u49kKiwrecE0BQoDH2XLRb+b LxhUu9LrM6fbtDSlRov7aCUHuKIyUm47vWv/W7pmm1mXl7138TWRNLbfg7ocpLYboz/1BL4h 9TAVdLqrg729Gw62K1U7Nb/xK78A/ENVE0/qcLwq+yPdczKBgz2+AjieE8Dp68Dwq0IXpEJj QsDmK2rEpMD+27bdC8EgTL0TlbpHQrsRUy2QIzPfckSYFL0ZMcEltTazgy7OA7+Pkjq7G7ge ND2CYzXSQzZswzaKgz8Z/GYC/EgPTEchTLlzhDevUre3iD735Dx6AlEpHEG7tMLzCzTnVD/v 88XnxDSCk8T55EHnlMWxQ8bXhDq0Mzg+/EDyVMRudsSkgrYd/L11DCt4DL5Eg0YBlbhG4jer c0f44zw/DLZZDDvv/wM/8MvFO4zGeLMswmNR9WTDYQzJiUzFwaJNJAyuxDS851JT8nS2lkwr pUy8bOswnZTA9MLJUCyNGjPCbkzF2oNHYKzJhczFy6PFd5zDe7zAaGs/6WTDu1zFQaw7MbzL 3yLHXebCJ3PKlxw4aNzAv7O+WxTMSeO9noMn+kPFaozGHQOGmwM2hixAt1xJxszIOzzDiXzJ nvPOsswqJTXK01woe8xHSCM8zMxltfMzAKW5YUzP3cs86gzEP3zGYAzN6fy3XVw5qvM2CP04 QHzOpBw+PdsiDLIu+hTJ05wygMS+1kxJyizQeexPv2y2HNRAUZS/5cgyhlzJw0w7YzzQ6v88 w2lcNvPUNkMMLEBj0/L0OooMxtH8zWUczlXiN3czLRnlvupiwwq9xCejMhP9xCzdo6TjxOwc 0FqdynLDOji8zvC8yJLcyJbMxfOjxW6T00991itsJY4Eykrs0kkN1cJLQT8crVX9CSZUPzEt PTZdx2O8zi8N036d1N28xn9NUtHDPF2dtsD8ulTicHDtRS5MtnTNx3YULWOjTfvMZEiL0IEN 1iSdzWTt1BFlT+nMQsAbwcDTRZNN2vgTJXmbQEurwEaT2Zc9vU3cOpP8yk3IOEosz6dN1GXs RycNzlCU24CdNzUnA5IoqQ0aVBRbvuHw2ujTM5+9xMctvS4zOWr/5Ns5iNSkyyjH7U9cDcGz i7ohfcPCs63VRw5USodFAKdLxQFc+gZYNFzLKUX+9QxrlkR0HOB9zMeelDQoE01+AjWztK7N hEzRFK+VQk/gTYJxUzP/y9DKfUNlZCvWvdyc/ChWSJtKGZNPOEzzjZwxiKx08RxQ8BKaeAng IXSJN1UkalglHqdgoroFV3L4TDFO8+P08EzLNOR0EjUQ9MF/PdxKvuRM3uQSNdz9S9V57XlS rdwdTuDTpM+5w7bBWKkuBgfyRW6Nh4ufe133bQ05yqhq/gofynhQuGeSx4gkeh5fSpQgWnva 6WU0HVHrNMk79eQi6+SnHeiCXuiGXuiE/z7Jfi5Q3z3lVD7XGY7lk4vEwtOI/4a1BzxM4ZJl Ny54zNjmIheoqAeKZ+oJAbalRRemGpifQqjqD1CoYHqIDeonMtDn/QRPBGzFmnvovN7rvj7o 5n1CsaTgXc6ZuGBON3zhka7UkgQvowvgzxNAcZxkIjlqT/kT5lWqSOrpqBByptWq6XBQqvqO 5gCoCIV34Oej84lF+5mqn2PAN7BRH3VR7uxRNnVToz3szvEmAHId+spOE+7omnDldFRBgHRS yXSwP27k6rpMQP408apBq03TW+w5kKW8186kuUCYcy5rSdbu3JkLnXfmV2RXJb50p/Ht91F+ QDliR7GR9PcOmf/OM9f0rHwe8FNOdPuE67/e8z7/80v+57ne84qNLvt2vNe+C2JHdnClpt8G uxFZtMgak3imTOq+eyvPb2fsLdpI7xkv8GUA9GI/9uYN6Lre5NC6839sUZzc9mpv9OymaQjL 8olqYWLpEnvS2TVKyfxIU3cC9lvQCmQ/+PwUyh38vt/74HEC0WyTlvxuFX74WUiftWUGCdE0 83aGTwEvpFgI+JX2+HArB0VYDogwUa9m0dKddQalTPvsDAHr3idrtPBqECZiE+DR8ZQQZgjq +QW7TpvLA/o6T03VdAas9+VnG1irrhHPrhtB7Fgb5A1vD8YfVyqpGrvP+2CQ9r+vcv7/+7Kj NvcgdP0/IP7Y7wX3WpteanGrSz78ulnTX/4I5OpRsIHkX7V5zjf1nyw4X/4EigClFesPo5x0 haYEqLx7GgiagH3miabqyrbuC6fBFte2aOf6zvf+DwwKh8QiCFAyspDKVQggSjan1KpVxbwC odqu9wsOi8fkSbY8waEloZF0DY+L1fKXpo7P6/f8/onON+NnoQH1NoiYyDFwqFgh6BgpOUlZ yQGZSCLZZtho+TlHA/ooOmp6ipqqNOMZKAB6AWCoSkvEWst2hrvL20t526ErKfx5IULS6quc 9rrsEJLsLD1NTRYyeo37FFU9Ddz93S0+Tl4DMNAMkm5KrH2s/1mOCjgOHW9/j19xvv7QDsvv rBC8fIr8jTNIMKHCWvUcCBhQqgDCURMLPIQY7deIgQvh3FlYsaPIkZECDGAkYR4ulQ72PQOY ytgskl9ClmNJM6dOOdksRGQAcxcmCMIyqtrGcWeQnjRxKn0KdRWEh0EV2FSV1MLUmdW2XYia 42o+p2DLmr1xUsqMpGJpDZVwrq0vmVnPXqqa863dvXydyGrFdFzdDPz02mvDrW8/oyTDKX4M mVCSh19f5gucCx3NJ1zNGvb8M7Lo0UQZT/PnlRDehMYS75SrsyHp2U8HPyAbD7cCkxg9uzFN DXNk2LSLi3PJZjU+1HEnK4/t5h5xsP+2jVsXR9lCZUJKcao9B3ynzO0Bnw8Pfz09KsbVRRqc 0fs6XfSKPl/XrT7/eoiPzHf0DhB89JWFGHmW4GeccPotGFNzDyj4lH23ccGgdq7VF1qFQGnI YUl/DLhQe1Q90+FuBfbRXoUQlsjiGiFARNZ0I0kIon6tpaiFhCzK1mKPdRhI2Gw4+tjBjUBa MSSLQ7ZBZJM5+nfWik6q8MSRQ0g5ZXXgkThll0JgCVmSXppgpBBiNlnXW1aOyaYdNRIIZZso pJYDgmxmFZSdchJp2prWJanBm10i5UKGe0YA5qGKzhknaYEdYlI6grJJZwd6KircSZKes2iP b/h5m48pytL/aQ2xpNlop49iAF+qpaqXHQVnymeoRbrAJ+OrDCBGoa5ksoXSAh/5WmGsJh4y a34p4jopsdlUSqw6rQwbLYORqtMmhCblWq2wjZRZBKiK8VjCtQ5d2q14/D2j2VTN3tdIYbL0 mi4pJ1T5bgSxOiYaj7tFJIur9eo0EbfWrvZQr6ySOrBDb54YQ6D6zpIvQYPNUGvDYLVjILpE MifFRQYPKnB/nc0ZbEtnMLzrY2yNrDFr21G7YbTeLfxXzAvAfNfJliaxlk+ijOhvWRxVrLM4 ArIbUaKHGppwyXt6bOqFJsCDMQbGSrzbWVQnPZKxD/IsqtTEZmzEqcCRZy4D7VpV/wrSyzgN djz0MvATsmazibbGX195DHCAsJxB33ntXfcy9C6dXOIW1ZisioZ/ofa9wozQF92OH4dj5K9q /u/dXnpOeeApiGmb3JWAvjk1Yt+m+p1GtXqojoFkrUPbFsSHKDhkt37Up4jrumKrsZP2948Q u8B4BilHQLg3pAPvDOsx+wMItNb1OfkkVU7gSRKcOj9ZwA28Htz01PvB9enHq4ow7/khV4H6 jizf+4Plvr1tCSMW+T40FG19p4iepYbXMINcDoGxoR8EbNeL6JDpbf9z2+Ry1ovfERAO37vL Bj9gO1zJZzIY2Y4GPyHBCS5sAB9ony/s90EB3uZtD2Qg2P9Q45p52fBwC5sRBq9GQxAEURkw jKEYMJOnAA4MTC6MDDIuIj+JKDEmKYQBy8wlLlAkz4haSAruwLfDzXFMM/t7XubY5pMoVTF/ ZshCBY1lpaBRoohcXMUPPVhHFtABGhgjBDFo1sA7Qm+K0tCe/h40kCtuCYs+K0YY8xgEQeqL kGATDvrc9khqnGOIFskkPvDngWdtCW9aS1kTK7FFSDahEHpTpRXLBbdnOAgsurvIOk44ozVe 4hmsco1JgEbJVXjSlcw7Rn+IGQMIzTIqBmJCyIaZl7UAR1OfYtm+cHkF6yGTB75s3DbN8S2f wCiYsCChLrBpFl2eazes3FmwKmj/Cm1+swh0nCfeZCU/aGoxI6k0jjpnBrTdrY2cudOnPd13 UB1gr2kELYn8gNa9HrXTcsAxoB4gmNClRDSjIMxQQ0ehgZPoop8dmqhCDbqUenL0aivtATrj gdFFqZONFBAk11BaA5W21AwfJSZJEyI6jXUQBFa6XLu29opP9XSSO23h2nCa0XAsNZ4b7Zbp ChWafb2Tk1YYYFMfuMmMxfSrLphHMuSZwam2aBtUMmojLOoFnarSEy8lq2VCKclyoDVpiGkB vyTyvEBlcQhy3ZwtWwhVu0rxEuvKR1271Qb6mDVl/fuXWr21U6BFEZGKbcKKEnZZnlQ1j5HV Y8pGaZG3/+3jAh/9ad3geU+4hLapjy3gbIl1Vb8Iq7Fbq4JrK8nVltz2qxAU2WAb1NkjeK60 uwnuFPYaM4yt45feTK4W3tMbrQ2XCrXloiHJBNdsJnZqzo2tdeMalG/IcS7jJe1M+wDdal2O rts9718xw8dddHdKxwXCd/cw1nr1JC0c+O1567QaZgmlvTq55A4cXAW2DiK+zgofgw8M3po+ L7yU2G+TWAvY+p6rsF+6sLJQ4GEM6/GtnkCGiF9AYXr0EpjlikZlKrM1Z/I2u40FxsrSgVqP NNJFo8XUZgep4h95tIYifbFfU4wICkFCjusdpe44DNYABYuRQ1NtsMDTGquY0v+MPMktB0m8 VvNVl69BfTCZ0TAR4x7IxHw45Q9HaeXGYvIEsugxZZngmjeiBD7QG7OTQYg5DkJ5R0W2p+7i YJ+8RmLRiEBf+0ZpLD1bMAVS5t+3KLhlTeONBrQrScAEeKvXHhobbNtORmSzx04kumsZ+Nem GvBF3PVRWM04A9ccWAfUiHOclabzINAn5ZWF+idLSoek6LDJk/AOVKv2r6SzmYUg18vA2hAF w4aysizoTtT1O60odp1arRGjsdbccq9ihWcabK28ZSBLZbUSCEqPS17/uTZ3pf1mX8V4LqJD d4hj2dy40ZtdJSDcjsu1zB5zQb2g7jWZUUvdfMcLoiz/3AO3F8RaXENnyF+K9gAIIO1G80nl 3bAo4VimyIgkrIXmbvi5hwiMHn/riqEO0LsXjobUwYfc1khjekJ+o3ccY15Mb7oON6J0KCh9 6u+AgtOfHrhq/+C//gX4SQjAciVpHQ9fFO6/WuJuZptGYrlWmLhZ5T//QUSHNdYOIpXKqkTY p2MEHsP4Pt4L1lL9HUgX+SaSHoWxw3gt4x06yjteKsDr6mj6rnf8sovmFZhc8aUTiIsJwpnM e0G6aZM25z8Z9uga/vTh8mgTRY8CKAK88mVIen9llvV/kHwHj4YBrgtfeBIMfgRqHkuS01pn rxNdKEhh/Sbey0EG7Ar40Rb+/+Cvrvzsa3/73O/+7FMu0rmbfF7fj4um8AF7mQkeMYOPLPAL L33Vgfj90Gg/iE8BSA563fk2YP/t+zVTWOY23keABTh+KddnEBF+BTh3Cnh1JmeA3zd7EMiA Feh15mdsZxYZrYF1/2cJHGg1jkB795Jy2sB1a5VCvBFweCN7FuiCLwiDMbiAMkiD3AcABPB4 J8d/PvBXscEJnbAZJ4gH+TcGfXcKnOGBPjJ0+5dlNeiETwiFUeiCFPh9j4dyGVgTOxgGMrF7 zAR9RLZqz/N79Ed1TCeF57d4xZcuVCht0wUFZwiHceh9bAh+UUiH0YaDJwd0+IeFrvCFANiF W9guY/8YctZXhg/YfXSogA4ofk43dVJndVX3gHGRgC8IbIgWiNUieGzYDOggh58IijOYfYpY gxAYVnmoh30YYal3FBuhhUKhhuyiHC0og2FVh9F2dYUQMFa3i5OIfYjYZ+ZHfnWofWFFiYvY gKL4hHFBeGwgXa/oKK0SitMIhTkYgaFociinjao4BSPoIqwEjV2RQtHWYlanjBdIjaMoiqZI hcIYfglYibg4gb+4iMYohRRIagIRjunhien4gqhIjdZYgQIph3mIcqzoBPE3ffTHkMJXf8MX dTfoi05HjP5ogZNiJPv4SbRIblRhkf4Yjw7Yjspnfg1IfhR5khJYicgogej/KJDpFzP9+JEz +XXZl4MASZPdZ5DLJwEViY9m2HS6qENMt3RSJwIBs3S6eJRQt5SPiJRBOZHwGJXBiI71KJUk SYDySB/zwWbcZ045eY7DWJEIiJX1yIhmOJb2KFJN14jCaItZOYc1KVKdtZJgqYdfZ4XWiIo4 qJd5CXAAeZA1uUk4WZYzeQ58eZAngA7DeIwpSZLyWJLTSIp2eY4wuEnNiCgFopE+yIWjiGss SZlkmYg+KY9WOYGi2Ygi6YviB5qjOZrWiJAb9IY0KZCEKW1+iZc3CZh5qY18eXI4aZu3SYAE KZcxeIOIeRJ8JpSpWX6PCZSmaJeTWYxxWZmPKYNW/8g/f+hdL9KP0gmKbumOkTmW6/iOp7mW anmewZiSVImP1KmO2jiXiiWWxJmOiKmbf9mbu6mbuOl1wEmfNEif/6l99gl5HsCLlDiVv4iW 4BeSzCmS1emOFlia8KiOdliYo7iX1ERW2xKa6LiSJfl44pmMrPmWzfmOB/ig5PmJ8FmgXyWW cSigwnmbvCmjyoecv7mXgJmbuRmjAwmFh4mcfMaYE5mM6omgRsqaVcmeJ2mkpamSNhiZ7Tmd LVl+JcmkrgkRN8qNixIprZmOS4qgolmiYUqRZPmTXmqSR8qI5Smd3smiLUpb2RiFAkqQ+cmj PEqgBIqj/Vmn1wmHAbqTQv/6nCi5oINapFW5lreIqNWJpsXIhuo5nhe6gMdoniOKlb5JAFtq ZN55nTdpozVKgfz5dX2Wg4fZnyOKog2Ig1KJfY1ainqYg3SZgD3qfXR6qtxXp55KmHr5l3d5 qzXqo7/6hASqnE0alSfalr7om/G4oFNKpZY6nc36oY7KgE5qgfYJdorVpb0qhb5ZnN/qq3dZ iSEqruEqrqY6mFh6mncIh6Z6l7JakLh6q7U5o9iqo7Dqq7TKgG96qjGqr30Jn6YBicZKj0B5 gbgIqcn6okA6rcjImGVphrpImidal+lpgwdrgMiZrXa1rSval/XKraaah+lqk9uXrid7jLV5 kGr/SqKm2a3CKat4GKzhCp99eq14+Zs7iq/cepc7uX2eerP7OpBBagJlSrCFaoxsyayo6K43 KgtO27P7CaRAO7JTm7OMKqHsaKagSYXIGZvrw6GgCJz4CbR1OLLBmaRXC6ThB6gzOopMeoCc WoCeSlwBk4zYKa+fOqD9aq57m69XW7Z6W5yB27fg6rd9+590ipwCa46DuprnKaaQq4dxwbQ4 SqpSi7PeuqfeyrnBKbfq6qWcKpDa6qrDapA3qrmcW6Nvaq/l+aOVWpifa7J/y1Evck4Vq6/c mrvmyqvCSa/4errYibc6GYOaC6y1CqwEyrgfCpm3yKyRmqX6CbI4S70s/4mpOUqcxruMbwu9 rwmQpFux7Qqju+uECGuW3dupALeZ8FVyX/tfw4i2e0u+hfuz9au7f7uzhvurNvujb7m09sm4 hWCawCiWiAi5y2q5Vnuc5MqXK7mqotjA8hi/xhm7z+qsmwunLRW2fFuNPXu8Fnyp9xqH1lqi wdq7/aqv3qhFtaVtbRUSAiyX/Ku/w3mG1uqcVAqeIlq6wGuvPezDrYtyAVypKJmkZfq2qdvA iEm5SIzAPTx39omHE4y1FnmjpBtSPDu0fNuj89uhi1q8+guYiri+JQEpQJJ4LYxXyPAHXJum biqj+fnDcSzHc0zHdWzHd4zHK6gvi6mOJdzHOf+5qwHaxS5IrE3FGdBKv8LKpzV5wqs7yEra kn6ct/56vKzidc0QetVWxuxEY3ZXbkAWaujwBKrlyX23a9viTpicnGKGaxSCWmicHG2GBXhM y7Vsy7eMy7lcx3o8FYuptVDqxV+KozeqyNcYmspbu6e2AK7KxcQ7w4/soVUakNb4Bpv0LZms BAwDb6oMyqp8c5DHTzuWDqa8LvfmTqWkypCXaYNGTfNnhLBcOJl4OjuqsXR8tXiKrYxcr7cM vB6clUHZlKlIf9NH0EqQMCKaqo+qw8MKzcbshHrKr7M3xr63h7o3GNC6xY78uzHc0ImYoMf6 sEUcvuEaPr8Cjj6AbKf/1S6opWeoDELivMyhLEt9JzaGwBHr/JlkZspBFnpLgZVAqZS72H5Z h3TSF0rwAcXBBGFhQBUNW8ToK7sfjLwlG53cC4N6ir+rnBdfewUmRQEYXb0za4c5PIlLeaCt usMDWrPBq8vDa3o98INFBFvplspiNs4tyhsv3WV3bcmDpjLOA2RvNYjkLMo39hfcOXcwuYUi m88VDQOntAZNHc1SGtXH3NFxicx4A3BJ5RX1FU68dCy8FFD94T+aUHYXMRnnIz6t/G64Jikl ZIS8F4vBAMMI+LhT7Ld+qbE8XM/DLMewupM+y9EejLe/u9Z3KrzAPdxvbQucAYR8NkTf5mXp /xwy3GPTWONLWGN4KXGLTsCdsswLD+GzXK0PKiwDfEyalEqxwfynNHzZ/wjAY6PV+qOP3ahu trYz3rZsaNcnME0+CecA5UxG7PZlpMYyPAlj2gk+IYfPbW3PNdvPrAvhxU3P4Lqrhcuibo24 UwjQxpQjca3GCz5FvxcENFM8P3jYEx0xpyYAOUhI0jRhacusYXqwQzq7aWvbxPjRRBmVQjmR ArHjk7imF+zbBHDNR014ATQ+/WBorLzMCtc9Lr1n/71pCVdNrezNPem+Co5ivrunmzvhwJ3c Ee7PgNvIrGuAZU11DLndhZR0RuliikeIgncM6YmUSa7iPKA9M1dymv/qBBUK39fr4INO6IVu x7zsBEuZhBpWzU1+cGL2ILEtRDfnbPsd05ACF2+G4AA02ztQ2dIMlRsB50T9FXnu5ogH5J5H fGYNdUI96hD5RPC3b/K8deCtCEVu6Lmu67teyzuLUrYHIi38bb3C0mZ0XOjWNu2Tgs8NWEQJ cSEeJPeCmceXXIreBSFoCbjO69tO6ICbt9EKt0Pp6kmJ7c2tj2sTCdzwmTUCgopN7ZXU6b5l 3lfC5iFX0POnkKXuBEGcA6XWGChe7vdj2rPDgeZj6u9uLfG+ivM+N1dbMc9IS+zX4Wxu1Jju V8dS77xy1mt+8AiPgrTeen5eSK1LNkKoIh7/j/I5osxj0IML0uL5fEImn/IzL1RePQYBzyEL vLHt2/E07/PgwOVIIvJAhXJAQU7T/vNJTylmJkCSRxpxY+twHfRKT/WzIfNg0PKlkvX+xfRV 7/UAiPPWEPbOMoK59/VnH/GQXWZDPxpqL0xjj/ZxDw7uN2HujiYMf5SLLvd7vzpdX2d2PyZw vwowzveFbwpmXx9ObzOA/ysgb/iPv4V+r3eMTzyUL+2CD/mZbwuIj0ps3yaY/ySOr/mjn+iS 7z2WH12oX/qqT/oIr5m0oPjexfosYAz31/q3vytJvmA9TySxn1KJh/txT+ez/yS87yVedTvA H/zHB+zGTyZ6/+7I/1/3yr/82MbwuOeK9yD9cr/9iW/6o7/UNgDPCcJ+1M8axK/B6P8lr1/9 AKQWtm9r3On8XYB0TWn+0DH/qZ//9P39CFC63P4wykmrvTjrzUNwnyIIYRGMwkJSq5kWwBAG w0u/cL0MwAL0JpkiVhoIOcikcknxeFAjwMj5KTGv2Ky2cbJuv+CweEwuL7vmdPaEcqrf8Pg3 AAjFFDe8zkTU42hAJk08XgJHhjM8PkcwQIBVC4+LXnKVJlQkUAJSUFSWn6BKU6GkpaanoB6o q5FPnZSssbIQilyEeH0FRpF7eoEWdEYhiAx1qsWMd0G/O0fBsKhUrpqcU9Jus9naEGjb3v/f 4KvH4afSUyTY5OphuQy3fEe7vg2GzBY/Is51EDE47T/pCmxCJwUaiEvXprVB9yqhm4frIkrk EnCixYsYNXTLyOqaJmvjOK575mAPjUTOajEw+KCElxIxjMQ01uljlB9SqjlMKEikz59JRgEd SjRjxaLfdrrq0uaJUkhIz/xIUcVDQYRPM2HKBCVnU6UCjUmLSrYsmaNm06qN1mKt2wpPnbyq abOu3bt0Pzrlee2t379F2QAeTFgO2sKIEytezHjL4caQI2M4Ibmy5cuY127MzLlzpLaeQ4se TfrN5tKoK4dMzbq169anX8teHHu27du4Na/Ozbvw7t7AgwvXVnv/uHG3xY8rX84cC7rm0P8+ jk69+nJP1rNrBq29u3fX07+LHxp+vPnz0sujXy9SKPv38Mlzj0+/6Pz6+POLc6+/P9Hk/gUo oBYADmggRuodqOCCTi3oYFTYPSihfw1OaCGEBV6oIXRdsLThhyJFCOKIwO1F4olpVYjiiqKx 4SGLMP6XYIw0kiXXizXmGBh/OvYYoos4+igkhjMOaWQlNwZ55JJqdcjkk2bIxSOUVDJmYpVY wsWGNVl26dlSXh4pJZdhlgmei2ZaqBA6SqbpJnggvSmeOa/Iaed4Uv4GpZ6wbalJkXcGyh5Y Q/L5AA5jtBklVk5xNZaigkZ64ZhsQjqp/xXBINohplQRI8ILUqiwx30aMernQF9ZKumqZnqU JKCWhaSKrAWd0Asd++BRAT6+2MHIJgxsYscLnuYhUA1WIWvrOTVt6ZAgqrIq7bRrbLXQpjy9 FeoQIahkCC+BtEMHorsGAkgm/TjRTyYyTVXNJlO50c+hjFBr771vYTKrUsza9Wpcj3pSVVXQ 7osJD1/F4O5Mm7RrCA+c2IrwTj014g4Onh4bbL2RRACQA4aQi+/IJOMnTwPepuQPx8BeoAwf gYQcyccq8DeTTNGWrPPO5sVLzwcjrNQWrGVQFmzOPCet9IYiLu3001BHLfXUVFdt9dVYZ631 1lx37fXXYIct9gbYZJddQAIAOw== --------------570D9748A5361D3B92E3DCF2-- From Steve Van der Hoeven Sat Sep 30 17:14:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00432 for ; Sat, 30 Sep 2000 20:18:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:49 +0200 (MEST) Received: (qmail 23108 invoked by uid 0); 30 Sep 2000 15:13:58 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 30 Sep 2000 15:13:58 -0000 X-eGroups-Return: sentto-1101623-907-970326830-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 30 Sep 2000 15:13:54 -0000 X-Sender: svdh@cs.rice.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 15:13:50 -0000 Received: (qmail 18036 invoked from network); 30 Sep 2000 15:13:50 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 30 Sep 2000 15:13:50 -0000 Received: from unknown (HELO cs.rice.edu) (128.42.1.30) by mta1 with SMTP; 30 Sep 2000 15:13:50 -0000 Received: from future.cs.rice.edu (future.cs.rice.edu [128.42.1.178]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id KAA05417 for ; Sat, 30 Sep 2000 10:13:49 -0500 (CDT) To: f-cpu@egroups.com In-Reply-To: <001c01c02aea$fbe3d460$4496fea9@deskpro-5100.pandora.be> Message-ID: X-eGroups-From: Steve Van der Hoeven From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 10:14:22 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Already done VHDL code ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ce524ee68e977cb906543d0259f2354f Status: R X-Status: N

On Sat, 30 Sep 2000, patrick Pelgrims wrote:

>
> Hello F-CPU memebers :-)
>
> Is it possible to put all the already available code (C-programs, vhdl etc)
> that is circulating in the egroup on a ftp-site. In that way it would be
> easyer to follow the evoluation :-).
> F-CPU greatings,
>
>     P. Pelgrims
>

I would be much more hapier with an cvs server... Don't we have one at
sourceforge.net?

It would also be interesting to put the documentation on it.

--steve
eGroups Sponsor
From Nicolas Boulay Sat Sep 30 18:12:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00435 for ; Sat, 30 Sep 2000 20:18:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:50 +0200 (MEST) Received: (qmail 13893 invoked by uid 0); 30 Sep 2000 16:10:52 -0000 Received: from fh.egroups.com (208.50.144.71) by mx06.rz2.gmx.net with SMTP; 30 Sep 2000 16:10:52 -0000 X-eGroups-Return: sentto-1101623-908-970330245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 30 Sep 2000 16:10:49 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 16:10:45 -0000 Received: (qmail 20897 invoked from network); 30 Sep 2000 16:10:45 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 30 Sep 2000 16:10:45 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 30 Sep 2000 16:10:44 -0000 Received: from 194.158.107.85 [194.158.107.85] by lh00.opsion.fr; Sat, 30 Sep 2000 16:05:14 GMT Message-ID: <39D610E2.8FC33FDB@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 18:12:18 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 1fe85235045c6c0862525da2969df5d1 Status: R X-Status: N Declare "i" as natural then convert it to include i in t(i).
But your code is strange. This for loop aren't synthetisable at all. You want to affect some value inside an array but i don't see what kind of
hardwar could you use it. I think it's better to use signal instead of
variable. You use variable for arithmetique or constant.

nicO

Yann Guidon a =E9crit :
>
> hi,
>
> so i'm discovering more and more hidden details of VHDL.
> the three books on my desk are helpful, tanks to Nicolas Boulay
> who lent me his book :-) all 3 are complementary.
>
> little problem, though : i have a std_logic_vector()
> that i want to initialize with an integer, more exactly,
> a loop counter :
>
>   type LRU_tag_type is array(0 to NBLINES-1) of std_logic_ve= ctor(LOGLINES-1 downto 0);
>
>   function init_cst(N : natural) return LRU_tag_type is
>     variable t : LRU_tag_type;
>   begin
>     for i in t'range loop
>       t(i):=3Di; -- this is not accepted= .
>     end loop;
>     return t;
>   end init_cst;
>
> i have tried some format castings but none works.
> it's not covered by the 3 books. help ...
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
eGroups Sponsor=
3D""
From Yann Guidon Sat Sep 30 19:38:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00438 for ; Sat, 30 Sep 2000 20:18:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:51 +0200 (MEST) Received: (qmail 1852 invoked by uid 0); 30 Sep 2000 16:34:33 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 30 Sep 2000 16:34:33 -0000 X-eGroups-Return: sentto-1101623-909-970331645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 30 Sep 2000 16:34:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 16:34:04 -0000 Received: (qmail 9358 invoked from network); 30 Sep 2000 16:34:04 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 30 Sep 2000 16:34:04 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 30 Sep 2000 16:34:03 -0000 Received: from f-cpu.org (nas3-7.ras.club-internet.fr [195.36.203.7]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA18208 for ; Sat, 30 Sep 2000 18:33:59 +0200 (MET DST) Message-ID: <39D62513.306B636A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 18:38:27 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) cache... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0d293174469a71221ffb7ac927262d1 Status: R X-Status: N hello again,

i've solved some problems and the writing goes faster now.
here is the current version : it is almost finished.
i still have to manage the case where a read occurs and
we have to partially update the LRU.
A testbench and some simulation vectors will follow as soon
as it is ready. I am using Simili, now that i have found
something that works. This doesn't mean that it is perfect
but it does the job well. could people here try to compile
this file with other tools ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the current file follows :

--------------------------------------------------------------------
--
-- F-CPU project : behavioural description of the instruction cache
-- (c) Yann Guidon 30 sept. 2000 whygee@f-cpu.org
-- GPL applies.
--
--------------------------------------------------------------------
--
-- Disclaimers :
--
-- This behavioural description lets us debug the LRU algorithms.
-- This is a "quick-and-dirty" first attempt and my first VHDL
-- file ever since.... A more acurate and synthetisable version
-- will be done later. This file should compile without too much
-- trouble, but it has not yet been tested : a testbench will come
-- soon. Warning, i'm not a good VHDL coder.
--
--------------------------------------------------------------------
--
-- Here are some requirements/specification for the instruction cache :
-- - line width : 32 bytes (256 bits)
-- - number of lines : undetermined, could be as low as 4 for the
--    tests or 256 for a final version. Size doesn't matter, behaviour
--    is more important.
-- - strategy : "true LRU", 1 set/way, to avoid nasty thrashing.
--    this could change in the future and it's up to everyone's taste
--    and need. 2- or 4-way associative may be implemented instead
--    of fully associative.
-- - 1 read and 1 write data ports for simultaneous access
--    of 2 different items -> 1 read and 1 write address buses
-- - 1 "cache hit/miss" output bit.
-- - latency : 1, 2 or 3 cycles. 1 cycle is necessary for the simple
--     tests, 2 cycles might be necessary to speedup the clock in the future.
-- - It should be possible to invalidate/flush a certain cache line
--    if it corresponds to a specified address range. The address masks
--    for this case are not yet implemented.
--
--------------------------------------------------------------------
--
-- This very implementation of the Icache is composed of three elements :
--  * The LRU stack
--  * The address tags & comparators
--  * The cache lines themselves.
-- Each of them take one cycle to go through.
--
-- Algorithm for the three modes :
--
-- Read :
-- Cycle 1) Send the address on the read bus. The address is
-- compared with every valid address tag and the result is
-- a bit vector. This vector is sent to the read lines of the cache,
-- and encoded for the LRU stack. The "hit" signal is sent.
-- Cycle 2) Update the LRU and read the selected cache line.
--
-- Write : (fits in 1 cycle)
--  * The LRU stack always outputs the number of the LRU line,
--  so it's "predecoded". it is sent as a bit vector to the
--  write signal of each cache line, and allowed by the general WRITE signal.
--  * In the same time, the LRU has a special update cycle.
--  * The data is sent to the data_in bus of the cache block.
--  * The address is sent to the write address bus of the address tag block.
-- 
-- Invalidation :
--  * the invalid signal is sent
--  * the invalidated address is sent to the read address bus of the tag block.
--
--
-- Because the read takes 2 cycles, there might be conflictual situations.
-- All the conflicts must be tested and delayed before the requested cycle
-- is accepted into the "pipeline". The conflicts are NOT tested yet.
-- Read and invalidation cycles should not collide either : they use some
-- common ressources.
--
--------------------------------------------------------------------

-- oh, and i also forgot the "line freeze" (or "lock") feature.


library ieee;
use ieee.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
use std.textio.all;
use ieee.std_logic_textio.all;


ENTITY ICache IS
  generic(
    ABWIDTH : INTEGER := 16   ; -- address bus width (this makes a 21-bit physical address space)
    DBWIDTH : INTEGER := 256  ; -- data bus width
    NBLINES : INTEGER := 64  ; -- number of cache lines
    LOGLINES : INTEGER := 6  -- log2(NBLINES)
  );
  PORT(
    Reset, CLK, FlushEn, ReadEn, WriteEn : IN std_logic;
    ICacheHit : INOUT std_logic;
    WriteAddr, ReadAddr : IN std_logic_vector(ABWIDTH-1 downto 0);
    Din : IN std_logic_vector(DBWIDTH-1 downto 0);
    Dout  : OUT std_logic_vector(DBWIDTH-1 downto 0)
  );
END ICache;

ARCHITECTURE ess1 OF ICache IS
-- the cache block :
  type cache_block_type is array(0 to NBLINES-1) of std_logic_vector(DBWIDTH-1 downto 0);
  signal Icache_block : cache_block_type;

-- the line command signals :
  signal write_signal, read_signal : std_logic_vector (NBLINES-1 downto 0);

-- the address tags :
  type address_tag_type is array(0 to NBLINES-1) of std_logic_vector(ABWIDTH-1 downto 0);
  signal adddress_tag : address_tag_type;
  signal address_valid_tag : std_logic_vector(NBLINES-1 downto 0);

-- the LRU tags :
  type LRU_tag_type is array(0 to NBLINES-1) of std_logic_vector(LOGLINES-1 downto 0);
  signal LRU_tag : LRU_tag_type;
  signal FIFO_input : std_logic_vector(LOGLINES-1 downto 0);

  function init_cst(N:integer) return LRU_tag_type is
    variable t : LRU_tag_type;
  begin
    for i in t'range loop
      t(i):=CONV_STD_LOGIC_VECTOR(i,LOGLINES);
    end loop;
    return t;
  end init_cst;

  constant Cst_LRU_init : LRU_tag_type := init_cst(1);

BEGIN

------------------------------------------------------------------
-- quick and asynchronous reset of the Icache state
------------------------------------------------------------------

Icache_reset : process (Reset)
begin
  if (Reset = '1') then
    write_signal <= (others=>'0');
    read_signal <= (others=>'0');
    address_valid_tag <= (others=>'0');
    LRU_tag <= Cst_LRU_init;
  end if;
end process Icache_reset;


Icache_memory_block : process(clk)
  variable i : integer;
  variable modified : boolean:=false;
  variable t : std_logic_vector(LOGLINES-1 downto 0);
begin
  if (clk = '1') then       -- only on the rising edge

------------------------------------------------------------------
-- Read one Icache line
------------------------------------------------------------------
    for i in 0 to NBLINES-1 loop
      if (read_signal(i)='1') then
        modified:=true;
        exit;
      end if;
    end loop;
       
    if modified=true then
      Dout <= Icache_block (i);
    else
      Dout <= (others=>'Z');
    end if;

------------------------------------------------------------------
-- Write one Icache line
------------------------------------------------------------------
    for i in 0 to NBLINES-1 loop
      if (WriteEn and write_signal(i))='1' then
        Icache_block (i) <= Din;
        exit;
      end if;
    end loop;

  end if;
end process Icache_memory_block;


------------------------------------------------------------------
-- The address lookup table
------------------------------------------------------------------

Icache_address_table : process (clk)
  variable t_read : std_logic_vector (NBLINES-1 downto 0):=(others=>'0');
  variable i : integer;
  variable hit: boolean:=false;
begin
  if (clk = '1') then       -- only on the rising edge

------------------------------------------------------------------
-- search for the same address tag.
------------------------------------------------------------------
    for i in 0 to NBLINES-1 loop
      if ((address_valid_tag(i)='1') and (adddress_tag(i)=ReadAddr))
      then  -- line : found
        if (FlushEn='1') then
          address_valid_tag(i) <= '0';
        else
          if ReadEn='1' then
            hit:=true;
            t_read(i):='1';
          end if;
        end if;
      end if;

-- manage a write enable :
      if (WriteEn and write_signal(i))='1' then
        adddress_tag(i) <= WriteAddr;
      end if;

    end loop;

    write_signal <= t_read;
    if (hit=true) then
      ICacheHit<='1';
    else
      ICacheHit<='0';
    end if;

    FIFO_input<=CONV_STD_LOGIC_VECTOR(i,LOGLINES);
  -- in real life, this is a binary encoder of 64->6 bits.

  end if;
end process Icache_address_table;



Icache_LRU_update : process (clk)
  variable t : std_logic_vector (NBLINES-1 downto 0) := (others=>'0');
  variable u : LRU_tag_type;
  variable i : integer;
begin
  if (clk = '1') then       -- only on the rising edge

------------------------------------------------------------------
-- Update LRU during write (beware of the priority, it might change)
------------------------------------------------------------------
    if WriteEn='1' then
      -- full rotate :
      u(0):=LRU_tag(NBLINES-1);
      for i in 1 to NBLINES-1 loop
        u(i):=LRU_tag(i-1);
      end loop;
    else
------------------------------------------------------------------
-- Update LRU after read (beware of the collisions, too)
------------------------------------------------------------------
      if ICacheHit='1' then
        XXXXXXXXXXX
      end if;
    end if;

    LRU_tag<= u;

    -- generate the write signals from the LRU queue :
    for i in t'range loop
      if LRU_tag(NBLINES-1)=CONV_STD_LOGIC_VECTOR(i,LOGLINES) then
        t(i):='1';
      end if;
    end loop;
    write_signal<=t;

  end if;
end process Icache_LRU_update;


END ess1;

------------------------------------------------------------------
--                                            that's all, folks...
------------------------------------------------------------------
eGroups Sponsor
From Yann Guidon Sat Sep 30 20:12:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00447 for ; Sat, 30 Sep 2000 20:18:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:56 +0200 (MEST) Received: (qmail 8629 invoked by uid 0); 30 Sep 2000 17:08:29 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 30 Sep 2000 17:08:29 -0000 X-eGroups-Return: sentto-1101623-910-970333705-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 30 Sep 2000 17:08:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 17:08:24 -0000 Received: (qmail 4069 invoked from network); 30 Sep 2000 17:08:24 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 30 Sep 2000 17:08:24 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 30 Sep 2000 17:08:23 -0000 Received: from f-cpu.org (nas4-66.ras.club-internet.fr [195.36.203.66]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA21331 for ; Sat, 30 Sep 2000 19:08:21 +0200 (MET DST) Message-ID: <39D62D1B.1AD5B205@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D610E2.8FC33FDB@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 19:12:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6f5022d5914d51e270b4a84029eb1558 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Declare "i" as natural then convert it to include i in t(i).
> But your code is strange. This for loop aren't synthetisable at all. You
> want to affect some value inside an array but i don't see what kind of
> hardwar could you use it. I think it's better to use signal instead of
> variable. You use variable for arithmetique or constant.

the code wasn't complete, of course, and you see the result in the latest
update that i just posted.

The problem is that i want to make a constant that is not 0, not arbitrary,
but a regular pattern : 0,1,2,3,4,5,6,7,8,9,...
This is used to initialize the LRU FIFO. i prefer this complex VHDL rather
than a file read or a constant that will waste room.

This is not meant to be synthesized : the synthesisable VHDL will probably
have the constant as is, instead of a function. i'll probably make a
for ... generate or something like that. before i do that, i want to simulate
the source without spending a whole day for a single cycle ;-)

OK, i have to finish the LRU then write a testbench, unless someone wants
to start the testbench writing now ? if you volunteer, please be quick :-)
the whole behavioural icache code could be ready on monday, we'll probably
need the next week to simulate and debug it. Comments are needed,
as well as the use of other simulators to test against punctual flaws.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Sep 30 20:12:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00453 for ; Sat, 30 Sep 2000 20:18:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Sep 2000 20:18:58 +0200 (MEST) Received: (qmail 28681 invoked by uid 0); 30 Sep 2000 17:12:36 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 30 Sep 2000 17:12:36 -0000 X-eGroups-Return: sentto-1101623-911-970333705-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 30 Sep 2000 17:08:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 17:08:24 -0000 Received: (qmail 4093 invoked from network); 30 Sep 2000 17:08:24 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 30 Sep 2000 17:08:24 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 30 Sep 2000 17:08:24 -0000 Received: from f-cpu.org (nas4-66.ras.club-internet.fr [195.36.203.66]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA13360; Sat, 30 Sep 2000 18:59:17 +0200 (MET DST) Message-ID: <39D62D1C.BAE44FB5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001c01c02aea$fbe3d460$4496fea9@deskpro-5100.pandora.be> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 19:12:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Already done VHDL code ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f5652854f78c45162e5950a6df485b46 Status: R X-Status: N hi !

patrick Pelgrims wrote:
> Hello F-CPU memebers :-)
> Is it possible to put all the already available code (C-programs, vhdl etc)
> that is circulating in the egroup on a ftp-site. In that way it would be
> easyer to follow the evoluation :-).

i'll update the f-cpu.de site as soon as we have something either stable, reliable
or working. We're still doing the reference platform.
We have not much C sources. VHDL is going on. I try to post any update to the codes
on the mailing list, so if you're subscribed, just take the most recent files.

The first FC0 reference definition will take some months to create. then we'll have to
tune the parameters like bus width and other "characteristic lengths", so we see how
each parameter affects the performance. Synthesis will be another tougher problem,
but "fortunately" we're far from this :-D
The Icache is only a "warm-up" for the rest of the units. if we can have a consistent
design that is spread among the participant, we'll be ready for the other units.

Anyway, i swear to update f-cpu.de when we have something stable or useful.
Give me time to learn the complexities of VHDL, though ;-) now i begin to
understand why VHDL is so controversial...

> F-CPU greatings,
>
>     P. Pelgrims

Steve Van der Hoeven wrote:
> I would be much more hapier with an cvs server... Don't we have one at
> sourceforge.net?
sourceforge was used for the gcc port but now it's inactive.
Someone will have to open an account there for this other side of the project.
I don't volunteer for at least 2 reasons :
- 1) i don't use CVS. not that it is bad or anything, but it doesn't correspond
   to my coding habits. Plus, CVS under Windows is possible but unpractical for
   my case because i'm on a modem in France and all i can do is send/receive emails.
   browsing the web is expensive because the phone bills are not free, here.
   emails already do the trick : they are archived and are rather up-to-date.
   i've had this idea already, that i could upload my f-cpu mail archive, so people
   could search keywords (egroups doesn't do this yet).
- 2) i am already responsible of enough things like that, i don't want to manage
   anything more. it's time for other people to be more involved ;-)

maybe Paul Mota can open a CVS account at the university of Paris 8, at last :-)

anyway, if CVS is used, i'll have to find a way to convert mails into CVS requests.


> It would also be interesting to put the documentation on it.

documentation is already at f-cpu.de.
If you have any update or suggestion, don't hesitate.

> --steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From jeff davies Sun Oct 1 01:25:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01674 for ; Sun, 1 Oct 2000 01:30:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 01:30:25 +0200 (MEST) Received: (qmail 12324 invoked by uid 0); 30 Sep 2000 23:25:28 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 30 Sep 2000 23:25:28 -0000 X-eGroups-Return: sentto-1101623-912-970356323-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 30 Sep 2000 23:25:27 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 23:25:22 -0000 Received: (qmail 31255 invoked from network); 30 Sep 2000 23:25:21 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 30 Sep 2000 23:25:21 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta1 with SMTP; 30 Sep 2000 23:25:21 -0000 Received: from modem-57.scandium.dialup.pol.co.uk ([62.136.20.57] helo=llandre.freeserve.co.uk) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13fVzu-0006MC-00 for f-cpu@egroups.com; Sun, 01 Oct 2000 00:24:51 +0100 Sender: root@pop.gmx.net Message-ID: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 00:25:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] SDRAM Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1aab6a37e1c037bf9f4229a139607adc Status: R X-Status: N Can I suggest that F-CPU ought NOT to use SDRAM interface, since Rambus
in addition to
suing SDRAM makers for royalties, are suing AMD, transmeta, hitachi (SH
series) for licence fees
for using SDRAM interfaces in their processors.

Plainly, if SDRAM support is an integral part of FCPU, then Rambus can
decide to not licence the technology, and the US courts will insist FCPU
is wiped from any website, subsequently most west european
governments (especially UK) will bend over accomodatingly, and we won't
even be able to link to
our "freedom of speech" FCPU website in china.

Why not start with static ram? Perhaps whygees MFM style compression can
be used to make GPL ram
chip designs ultimately??

I think oodles of fast static ram on the same silicon as a CPU is a very
very good idea as an alternative.

Jeff Davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
From Alan Grimes Sun Oct 1 01:41:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01820 for ; Sun, 1 Oct 2000 02:23:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 02:23:22 +0200 (MEST) Received: (qmail 12666 invoked by uid 0); 30 Sep 2000 23:39:26 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 30 Sep 2000 23:39:26 -0000 X-eGroups-Return: sentto-1101623-913-970357163-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 30 Sep 2000 23:39:23 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 23:39:22 -0000 Received: (qmail 23081 invoked from network); 30 Sep 2000 23:39:22 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 30 Sep 2000 23:39:22 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta2 with SMTP; 30 Sep 2000 23:39:22 -0000 Received: from 216-164-128-4.s4.tnt1.lnhva.md.dialup.rcn.com ([216.164.128.4] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13fWDw-0000Rw-00 for f-cpu@egroups.com; Sat, 30 Sep 2000 19:39:21 -0400 Message-ID: <39D67A1D.B3084643@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Sep 2000 19:41:17 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Checking up on the project. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b33c595e993dda7ef64e7543fc70163b Status: R X-Status: N om

Hey, I havn't really been paying attention to the project much reciently...
What, concicely is the status?
      Further I know that some of you have been studying GCC in an efort to
write a back end to that compiler for the F-CPU... Naturally the best
possible F-CPU is one designed for that compiler so what enhancements can
be made to the F-CPU to make it a better target for GCC?

Finally: I have come to the conclusion that a "protection free" processor
is best because it imposes no hardware overhead on well-behaved code which
is the only thing a "safe" compiler can generate anyway. =)

--
In this year's presidential race you *do* have a choice!
VOTE Browne/Olivier The ticket to freedom!
http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle randy weaver sog sof oliver north vince
foster m-16 hillary clinton bill clinton marx crack m-60 c5 c7 mlk black
panthers fbi chemical weapons twa 800 roswell white slavery history of us
foreign policy terrorist freedom
####### End   Eschelon Block #######
eGroups Sponsor
From Yann Guidon Sun Oct 1 02:57:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01823 for ; Sun, 1 Oct 2000 02:23:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 02:23:23 +0200 (MEST) Received: (qmail 30955 invoked by uid 0); 30 Sep 2000 23:53:15 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 30 Sep 2000 23:53:15 -0000 X-eGroups-Return: sentto-1101623-915-970357992-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 30 Sep 2000 23:53:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 23:53:12 -0000 Received: (qmail 14533 invoked from network); 30 Sep 2000 23:53:12 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 30 Sep 2000 23:53:12 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 30 Sep 2000 23:53:11 -0000 Received: from f-cpu.org (nas4-152.aub.club-internet.fr [195.36.145.152]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10241 for ; Sun, 1 Oct 2000 01:53:08 +0200 (MET DST) Message-ID: <39D68BFB.FCEBA74@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D67A1D.B3084643@starpower.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 01:57:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Checking up on the project. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d164e54e7b29caff566dd07a28ea521 Status: R X-Status: N hi Alan !

Alan Grimes wrote:
> om
idem,

> Hey, I havn't really been paying attention to the project much reciently...
> What, concicely is the status?

I have finished my master thesis so i'm back to active status :-P
i have finally found a not-too-proprietary VHDL compiler and simulator
so i started to learn and write HTML code. I'm warming up on the Icache
behavioural design. it's almost finished and i'm thinking about a testbench.
I post the files on the group when they are in development or finished,
so we can react in real time :-)

>         Further I know that some of you have been studying GCC in an efort to
> write a back end to that compiler for the F-CPU... Naturally the best
> possible F-CPU is one designed for that compiler so what enhancements can
> be made to the F-CPU to make it a better target for GCC?

this is a bad idea : GCC is designed for the CPUs of the 80's and a langage
of the 70's. we're entering the 3rd millenium, did you know ? unless you got
a y2k bug and got back to 1970 ;-P </silly joke>

so GCC is necessary for all the backwards compatibility but i don't expect
much more. i don't program in C for performance anyway. the recent post about
Sayuri proved that point : i can write a better code than GCC when it's about
speed.

I will be working on GNL actively during the next year so we'll have a portable,
target-independent graphical programming tool that can generate very good code.
If someone wants to join the effort, he's welcome : there's a lot of things to
do !

> Finally: I have come to the conclusion that a "protection free" processor
> is best because it imposes no hardware overhead on well-behaved code which
> is the only thing a "safe" compiler can generate anyway. =)

well, not all code is generated by compilers. what if a Linux user
does :
$ cat > a.out
azerzertzqmljkhqsdjkhqlkjhf
^D
$ chmod 700 a.out
$ ./a.out

huh ?

protection is necessary for certain cases, Linux being the most important.
you can remove this "feature" easily because there is not much overhead
anyway.

at the current stage, that is : the Icache, protection is not a problem at all.

welcome back, sit comfortably and enjoy the fun :-D

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 1 02:46:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01826 for ; Sun, 1 Oct 2000 02:23:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 02:23:24 +0200 (MEST) Received: (qmail 2594 invoked by uid 0); 30 Sep 2000 23:59:25 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 30 Sep 2000 23:59:25 -0000 X-eGroups-Return: sentto-1101623-914-970357308-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 30 Sep 2000 23:41:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 30 Sep 2000 23:41:48 -0000 Received: (qmail 28655 invoked from network); 30 Sep 2000 23:41:48 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 30 Sep 2000 23:41:48 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 30 Sep 2000 23:41:48 -0000 Received: from f-cpu.org (nas4-152.aub.club-internet.fr [195.36.145.152]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA24879 for ; Sun, 1 Oct 2000 01:41:44 +0200 (MET DST) Message-ID: <39D6894F.5FAD9C39@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 01:46:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SDRAM Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8fc06078fab9ec27e1f948c073c36a86 Status: R X-Status: N hi !

jeff davies wrote:
> Can I suggest that F-CPU ought NOT to use SDRAM interface, since Rambus
> in addition to
> suing SDRAM makers for royalties, are suing AMD, transmeta, hitachi (SH
> series) for licence fees
> for using SDRAM interfaces in their processors.
>
> Plainly, if SDRAM support is an integral part of FCPU, then Rambus can
> decide to not licence the technology, and the US courts will insist FCPU
> is wiped from any website, subsequently most west european
> governments (especially UK) will bend over accomodatingly, and we won't
> even be able to link to
> our "freedom of speech" FCPU website in china.

that is a problem, of course, but it depends at which level you're considering
it : if it's at the core level, for example for the FC0 specification, there
is no direct dependency. The FC0 and the F-CPU instruction set can support
up to 8 memory banks, that makes 2 SDRAM chips at least. But that is not
really depending on SDRAM and there are other banked memories out there.

I guess that at some point, all the sued companies will collaborate and
blow Rambus' patent up. that would be fun.

> Why not start with static ram? Perhaps whygees MFM style compression can
> be used to make GPL ram chip designs ultimately??

The MFM trick is not dependent on the core, so it could be possible.
Anyway, this "trick" requires a huge industrial investment and and don't
want to make it public domain : i sniff a lot of money :-) but money needs
money and i'm broke. if a companies backs me up, alright and i'll reinvest
all the bucks into the f-cpu.

the MFM trick (i oughta find a better name soon) is a hard stuff.
it's going to eat up a lot of money into patents, consulting, prototyping
and horrible things that i don't want to hear about. The challenge is
interesting and stimulating though but i have no mean to do this.
i prefer to make a first working FC0 VHDL source and learn VHDL ;-)

> I think oodles of fast static ram on the same silicon as a CPU is a very
> very good idea as an alternative.

maybe, but that won't solve the swapping problem ;-)

> Jeff Davies
> jeff@llandre.freeserve.co.uk
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 1 03:47:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA02540 for ; Sun, 1 Oct 2000 06:33:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 06:33:49 +0200 (MEST) Received: (qmail 3088 invoked by uid 0); 1 Oct 2000 00:43:26 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 1 Oct 2000 00:43:26 -0000 X-eGroups-Return: sentto-1101623-916-970360993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 01 Oct 2000 00:43:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 00:43:12 -0000 Received: (qmail 11087 invoked from network); 1 Oct 2000 00:43:12 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 1 Oct 2000 00:43:12 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 1 Oct 2000 00:43:12 -0000 Received: from f-cpu.org (nas4-165.aub.club-internet.fr [195.36.145.165]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA12672 for ; Sun, 1 Oct 2000 02:43:08 +0200 (MET DST) Message-ID: <39D697B2.4C8C1EEE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 02:47:30 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) first icache behaviour file Content-Type: multipart/mixed; boundary="------------768D77773B32B79B6CC28B61" X-UIDL: c5f6ab9eba7a4d9e67ff2e28f1770e52 Status: R X-Status: N --------------768D77773B32B79B6CC28B61 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,
so i completed the missing lines in the LRU update code.
this is coded as if i was using C, so don't care about the
capability of synthesis.

now, i learn to use text i/o to make a testbench.
during the sims, i'll setup an algorithm to dispatch
the read, write and invalidate cycles and avoid the
lethal collisions.

read you soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------768D77773B32B79B6CC28B61 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="cache008.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cache008.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIA0KLS0gRi1DUFUgcHJvamVjdCA6IGJlaGF2aW91cmFsIGRl c2NyaXB0aW9uIG9mIHRoZSBpbnN0cnVjdGlvbiBjYWNoZQ0KLS0gKGMpIFlhbm4gR3VpZG9u IDMwIHNlcHQuIDIwMDAgd2h5Z2VlQGYtY3B1Lm9yZw0KLS0gR1BMIGFwcGxpZXMuDQotLSAN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQotLQ0KLS0gRGlzY2xhaW1lcnMgOg0KLS0NCi0tIFRoaXMgYmVo YXZpb3VyYWwgZGVzY3JpcHRpb24gbGV0cyB1cyBkZWJ1ZyB0aGUgTFJVIGFsZ29yaXRobXMu DQotLSBUaGlzIGlzIGEgInF1aWNrLWFuZC1kaXJ0eSIgZmlyc3QgYXR0ZW1wdCBhbmQgbXkg Zmlyc3QgVkhETA0KLS0gZmlsZSBldmVyIHNpbmNlLi4uLiBBIG1vcmUgYWN1cmF0ZSBhbmQg c3ludGhldGlzYWJsZSB2ZXJzaW9uDQotLSB3aWxsIGJlIGRvbmUgbGF0ZXIuIFRoaXMgZmls ZSBzaG91bGQgY29tcGlsZSB3aXRob3V0IHRvbyBtdWNoDQotLSB0cm91YmxlLCBidXQgaXQg aGFzIG5vdCB5ZXQgYmVlbiB0ZXN0ZWQgOiBhIHRlc3RiZW5jaCB3aWxsIGNvbWUNCi0tIHNv b24uIFdhcm5pbmcsIGknbSBub3QgYSBnb29kIFZIREwgY29kZXIuDQotLSANCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLQ0KLS0gSGVyZSBhcmUgc29tZSByZXF1aXJlbWVudHMvc3BlY2lmaWNhdGlv biBmb3IgdGhlIGluc3RydWN0aW9uIGNhY2hlIDoNCi0tIC0gbGluZSB3aWR0aCA6IDMyIGJ5 dGVzICgyNTYgYml0cykNCi0tIC0gbnVtYmVyIG9mIGxpbmVzIDogdW5kZXRlcm1pbmVkLCBj b3VsZCBiZSBhcyBsb3cgYXMgNCBmb3IgdGhlDQotLSAgICB0ZXN0cyBvciAyNTYgZm9yIGEg ZmluYWwgdmVyc2lvbi4gU2l6ZSBkb2Vzbid0IG1hdHRlciwgYmVoYXZpb3VyDQotLSAgICBp cyBtb3JlIGltcG9ydGFudC4NCi0tIC0gc3RyYXRlZ3kgOiAidHJ1ZSBMUlUiLCAxIHNldC93 YXksIHRvIGF2b2lkIG5hc3R5IHRocmFzaGluZy4NCi0tICAgIHRoaXMgY291bGQgY2hhbmdl IGluIHRoZSBmdXR1cmUgYW5kIGl0J3MgdXAgdG8gZXZlcnlvbmUncyB0YXN0ZQ0KLS0gICAg YW5kIG5lZWQuIDItIG9yIDQtd2F5IGFzc29jaWF0aXZlIG1heSBiZSBpbXBsZW1lbnRlZCBp bnN0ZWFkDQotLSAgICBvZiBmdWxseSBhc3NvY2lhdGl2ZS4NCi0tIC0gMSByZWFkIGFuZCAx IHdyaXRlIGRhdGEgcG9ydHMgZm9yIHNpbXVsdGFuZW91cyBhY2Nlc3MNCi0tICAgIG9mIDIg ZGlmZmVyZW50IGl0ZW1zIC0+IDEgcmVhZCBhbmQgMSB3cml0ZSBhZGRyZXNzIGJ1c2VzDQot LSAtIDEgImNhY2hlIGhpdC9taXNzIiBvdXRwdXQgYml0Lg0KLS0gLSBsYXRlbmN5IDogMSwg MiBvciAzIGN5Y2xlcy4gMSBjeWNsZSBpcyBuZWNlc3NhcnkgZm9yIHRoZSBzaW1wbGUNCi0t ICAgICB0ZXN0cywgMiBjeWNsZXMgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHNwZWVkdXAgdGhl IGNsb2NrIGluIHRoZSBmdXR1cmUuDQotLSAtIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBp bnZhbGlkYXRlL2ZsdXNoIGEgY2VydGFpbiBjYWNoZSBsaW5lDQotLSAgICBpZiBpdCBjb3Jy ZXNwb25kcyB0byBhIHNwZWNpZmllZCBhZGRyZXNzIHJhbmdlLiBUaGUgYWRkcmVzcyBtYXNr cw0KLS0gICAgZm9yIHRoaXMgY2FzZSBhcmUgbm90IHlldCBpbXBsZW1lbnRlZC4NCi0tIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIA0KLS0gVGhpcyB2ZXJ5IGltcGxlbWVudGF0aW9uIG9mIHRo ZSBJY2FjaGUgaXMgY29tcG9zZWQgb2YgdGhyZWUgZWxlbWVudHMgOg0KLS0gICogVGhlIExS VSBzdGFjaw0KLS0gICogVGhlIGFkZHJlc3MgdGFncyAmIGNvbXBhcmF0b3JzDQotLSAgKiBU aGUgY2FjaGUgbGluZXMgdGhlbXNlbHZlcy4NCi0tIEVhY2ggb2YgdGhlbSB0YWtlIG9uZSBj eWNsZSB0byBnbyB0aHJvdWdoLg0KLS0NCi0tIEFsZ29yaXRobSBmb3IgdGhlIHRocmVlIG1v ZGVzIDoNCi0tIA0KLS0gUmVhZCA6DQotLSBDeWNsZSAxKSBTZW5kIHRoZSBhZGRyZXNzIG9u IHRoZSByZWFkIGJ1cy4gVGhlIGFkZHJlc3MgaXMNCi0tIGNvbXBhcmVkIHdpdGggZXZlcnkg dmFsaWQgYWRkcmVzcyB0YWcgYW5kIHRoZSByZXN1bHQgaXMNCi0tIGEgYml0IHZlY3Rvci4g VGhpcyB2ZWN0b3IgaXMgc2VudCB0byB0aGUgcmVhZCBsaW5lcyBvZiB0aGUgY2FjaGUsDQot LSBhbmQgZW5jb2RlZCBmb3IgdGhlIExSVSBzdGFjay4gVGhlICJoaXQiIHNpZ25hbCBpcyBz ZW50Lg0KLS0gQ3ljbGUgMikgVXBkYXRlIHRoZSBMUlUgYW5kIHJlYWQgdGhlIHNlbGVjdGVk IGNhY2hlIGxpbmUuDQotLSANCi0tIFdyaXRlIDogKGZpdHMgaW4gMSBjeWNsZSkNCi0tICAq IFRoZSBMUlUgc3RhY2sgYWx3YXlzIG91dHB1dHMgdGhlIG51bWJlciBvZiB0aGUgTFJVIGxp bmUsDQotLSAgc28gaXQncyAicHJlZGVjb2RlZCIuIGl0IGlzIHNlbnQgYXMgYSBiaXQgdmVj dG9yIHRvIHRoZQ0KLS0gIHdyaXRlIHNpZ25hbCBvZiBlYWNoIGNhY2hlIGxpbmUsIGFuZCBh bGxvd2VkIGJ5IHRoZSBnZW5lcmFsIFdSSVRFIHNpZ25hbC4NCi0tICAqIEluIHRoZSBzYW1l IHRpbWUsIHRoZSBMUlUgaGFzIGEgc3BlY2lhbCB1cGRhdGUgY3ljbGUuDQotLSAgKiBUaGUg ZGF0YSBpcyBzZW50IHRvIHRoZSBkYXRhX2luIGJ1cyBvZiB0aGUgY2FjaGUgYmxvY2suDQot LSAgKiBUaGUgYWRkcmVzcyBpcyBzZW50IHRvIHRoZSB3cml0ZSBhZGRyZXNzIGJ1cyBvZiB0 aGUgYWRkcmVzcyB0YWcgYmxvY2suDQotLSAgDQotLSBJbnZhbGlkYXRpb24gOg0KLS0gICog dGhlIGludmFsaWQgc2lnbmFsIGlzIHNlbnQNCi0tICAqIHRoZSBpbnZhbGlkYXRlZCBhZGRy ZXNzIGlzIHNlbnQgdG8gdGhlIHJlYWQgYWRkcmVzcyBidXMgb2YgdGhlIHRhZyBibG9jay4N Ci0tIA0KLS0gDQotLSBCZWNhdXNlIHRoZSByZWFkIHRha2VzIDIgY3ljbGVzLCB0aGVyZSBt aWdodCBiZSBjb25mbGljdHVhbCBzaXR1YXRpb25zLg0KLS0gQWxsIHRoZSBjb25mbGljdHMg bXVzdCBiZSB0ZXN0ZWQgYW5kIGRlbGF5ZWQgYmVmb3JlIHRoZSByZXF1ZXN0ZWQgY3ljbGUN Ci0tIGlzIGFjY2VwdGVkIGludG8gdGhlICJwaXBlbGluZSIuIFRoZSBjb25mbGljdHMgYXJl IE5PVCB0ZXN0ZWQgeWV0Lg0KLS0gUmVhZCBhbmQgaW52YWxpZGF0aW9uIGN5Y2xlcyBzaG91 bGQgbm90IGNvbGxpZGUgZWl0aGVyIDogdGhleSB1c2Ugc29tZQ0KLS0gY29tbW9uIHJlc3Nv dXJjZXMuDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tIG9oLCBhbmQgaSBhbHNvIGZvcmdv dCB0aGUgImxpbmUgZnJlZXplIiAob3IgImxvY2siKSBmZWF0dXJlLg0KDQoNCmxpYnJhcnkg aWVlZTsNCnVzZSBpZWVlLnN0ZF9sb2dpY18xMTY0LmFsbDsNCnVzZSBJRUVFLnN0ZF9sb2dp Y191bnNpZ25lZC5hbGw7DQp1c2UgaWVlZS5zdGRfbG9naWNfYXJpdGguYWxsOw0KdXNlIHN0 ZC50ZXh0aW8uYWxsOw0KdXNlIGllZWUuc3RkX2xvZ2ljX3RleHRpby5hbGw7DQoNCg0KRU5U SVRZIElDYWNoZSBJUw0KICBnZW5lcmljKA0KICAgIEFCV0lEVEggOiBJTlRFR0VSIDo9IDE2 ICAgOyAtLSBhZGRyZXNzIGJ1cyB3aWR0aCAodGhpcyBtYWtlcyBhIDIxLWJpdCBwaHlzaWNh bCBhZGRyZXNzIHNwYWNlKQ0KICAgIERCV0lEVEggOiBJTlRFR0VSIDo9IDI1NiAgOyAtLSBk YXRhIGJ1cyB3aWR0aA0KICAgIE5CTElORVMgOiBJTlRFR0VSIDo9IDY0ICA7IC0tIG51bWJl ciBvZiBjYWNoZSBsaW5lcw0KICAgIExPR0xJTkVTIDogSU5URUdFUiA6PSA2ICAtLSBsb2cy KE5CTElORVMpDQogICk7DQogIFBPUlQoDQogICAgUmVzZXQsIENMSywgRmx1c2hFbiwgUmVh ZEVuLCBXcml0ZUVuIDogSU4gc3RkX2xvZ2ljOw0KICAgIElDYWNoZUhpdCA6IElOT1VUIHN0 ZF9sb2dpYzsNCiAgICBXcml0ZUFkZHIsIFJlYWRBZGRyIDogSU4gc3RkX2xvZ2ljX3ZlY3Rv cihBQldJRFRILTEgZG93bnRvIDApOyANCiAgICBEaW4gOiBJTiBzdGRfbG9naWNfdmVjdG9y KERCV0lEVEgtMSBkb3dudG8gMCk7DQogICAgRG91dCAgOiBPVVQgc3RkX2xvZ2ljX3ZlY3Rv cihEQldJRFRILTEgZG93bnRvIDApDQogICk7DQpFTkQgSUNhY2hlOw0KDQpBUkNISVRFQ1RV UkUgZXNzMSBPRiBJQ2FjaGUgSVMNCi0tIHRoZSBjYWNoZSBibG9jayA6DQogIHR5cGUgY2Fj aGVfYmxvY2tfdHlwZSBpcyBhcnJheSgwIHRvIE5CTElORVMtMSkgb2Ygc3RkX2xvZ2ljX3Zl Y3RvcihEQldJRFRILTEgZG93bnRvIDApOw0KICBzaWduYWwgSWNhY2hlX2Jsb2NrIDogY2Fj aGVfYmxvY2tfdHlwZTsNCg0KLS0gdGhlIGxpbmUgY29tbWFuZCBzaWduYWxzIDoNCiAgc2ln bmFsIHdyaXRlX3NpZ25hbCwgcmVhZF9zaWduYWwgOiBzdGRfbG9naWNfdmVjdG9yIChOQkxJ TkVTLTEgZG93bnRvIDApOw0KDQotLSB0aGUgYWRkcmVzcyB0YWdzIDoNCiAgdHlwZSBhZGRy ZXNzX3RhZ190eXBlIGlzIGFycmF5KDAgdG8gTkJMSU5FUy0xKSBvZiBzdGRfbG9naWNfdmVj dG9yKEFCV0lEVEgtMSBkb3dudG8gMCk7DQogIHNpZ25hbCBhZGRkcmVzc190YWcgOiBhZGRy ZXNzX3RhZ190eXBlOw0KICBzaWduYWwgYWRkcmVzc192YWxpZF90YWcgOiBzdGRfbG9naWNf dmVjdG9yKE5CTElORVMtMSBkb3dudG8gMCk7DQoNCi0tIHRoZSBMUlUgdGFncyA6DQogIHR5 cGUgTFJVX3RhZ190eXBlIGlzIGFycmF5KDAgdG8gTkJMSU5FUy0xKSBvZiBzdGRfbG9naWNf dmVjdG9yKExPR0xJTkVTLTEgZG93bnRvIDApOw0KICBzaWduYWwgTFJVX3RhZyA6IExSVV90 YWdfdHlwZTsNCiAgc2lnbmFsIEZJRk9faW5wdXQgOiBzdGRfbG9naWNfdmVjdG9yKExPR0xJ TkVTLTEgZG93bnRvIDApOw0KDQogIGZ1bmN0aW9uIGluaXRfY3N0KE46aW50ZWdlcikgcmV0 dXJuIExSVV90YWdfdHlwZSBpcw0KICAgIHZhcmlhYmxlIHQgOiBMUlVfdGFnX3R5cGU7DQog IGJlZ2luDQogICAgZm9yIGkgaW4gdCdyYW5nZSBsb29wDQogICAgICB0KGkpOj1DT05WX1NU RF9MT0dJQ19WRUNUT1IoaSxMT0dMSU5FUyk7DQogICAgZW5kIGxvb3A7DQogICAgcmV0dXJu IHQ7DQogIGVuZCBpbml0X2NzdDsNCg0KICBjb25zdGFudCBDc3RfTFJVX2luaXQgOiBMUlVf dGFnX3R5cGUgOj0gaW5pdF9jc3QoMSk7DQoNCkJFR0lODQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0g cXVpY2sgYW5kIGFzeW5jaHJvbm91cyByZXNldCBvZiB0aGUgSWNhY2hlIHN0YXRlDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSWNhY2hlX3Jlc2V0IDogcHJvY2VzcyAoUmVzZXQpDQpiZWdpbg0KICBp ZiAoUmVzZXQgPSAnMScpIHRoZW4NCiAgICB3cml0ZV9zaWduYWwgPD0gKG90aGVycz0+JzAn KTsNCiAgICByZWFkX3NpZ25hbCA8PSAob3RoZXJzPT4nMCcpOw0KICAgIGFkZHJlc3NfdmFs aWRfdGFnIDw9IChvdGhlcnM9PicwJyk7DQogICAgTFJVX3RhZyA8PSBDc3RfTFJVX2luaXQ7 DQogIGVuZCBpZjsNCmVuZCBwcm9jZXNzIEljYWNoZV9yZXNldDsNCg0KDQpJY2FjaGVfbWVt b3J5X2Jsb2NrIDogcHJvY2VzcyhjbGspDQogIHZhcmlhYmxlIGkgOiBpbnRlZ2VyOw0KICB2 YXJpYWJsZSBtb2RpZmllZCA6IGJvb2xlYW46PWZhbHNlOw0KICB2YXJpYWJsZSB0IDogc3Rk X2xvZ2ljX3ZlY3RvcihMT0dMSU5FUy0xIGRvd250byAwKTsNCmJlZ2luDQogIGlmIChjbGsg PSAnMScpIHRoZW4gICAgICAgLS0gb25seSBvbiB0aGUgcmlzaW5nIGVkZ2UNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLSBSZWFkIG9uZSBJY2FjaGUgbGluZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgZm9y IGkgaW4gMCB0byBOQkxJTkVTLTEgbG9vcA0KICAgICAgaWYgKHJlYWRfc2lnbmFsKGkpPScx JykgdGhlbg0KICAgICAgICBtb2RpZmllZDo9dHJ1ZTsNCiAgICAgICAgZXhpdDsNCiAgICAg IGVuZCBpZjsNCiAgICBlbmQgbG9vcDsNCiAgICAgICAgDQogICAgaWYgbW9kaWZpZWQ9dHJ1 ZSB0aGVuDQogICAgICBEb3V0IDw9IEljYWNoZV9ibG9jayAoaSk7DQogICAgZWxzZQ0KICAg ICAgRG91dCA8PSAob3RoZXJzPT4nWicpOw0KICAgIGVuZCBpZjsNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQotLSBXcml0ZSBvbmUgSWNhY2hlIGxpbmUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIGZvciBpIGlu IDAgdG8gTkJMSU5FUy0xIGxvb3ANCiAgICAgIGlmIChXcml0ZUVuIGFuZCB3cml0ZV9zaWdu YWwoaSkpPScxJyB0aGVuDQogICAgICAgIEljYWNoZV9ibG9jayAoaSkgPD0gRGluOw0KICAg ICAgICBleGl0Ow0KICAgICAgZW5kIGlmOw0KICAgIGVuZCBsb29wOw0KDQogIGVuZCBpZjsN CmVuZCBwcm9jZXNzIEljYWNoZV9tZW1vcnlfYmxvY2s7DQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQot LSBUaGUgYWRkcmVzcyBsb29rdXAgdGFibGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJY2FjaGVfYWRk cmVzc190YWJsZSA6IHByb2Nlc3MgKGNsaykNCiAgdmFyaWFibGUgdF9yZWFkIDogc3RkX2xv Z2ljX3ZlY3RvciAoTkJMSU5FUy0xIGRvd250byAwKTo9KG90aGVycz0+JzAnKTsNCiAgdmFy aWFibGUgaSA6IGludGVnZXI7DQogIHZhcmlhYmxlIGhpdDogYm9vbGVhbjo9ZmFsc2U7DQpi ZWdpbg0KICBpZiAoY2xrID0gJzEnKSB0aGVuICAgICAgIC0tIG9ubHkgb24gdGhlIHJpc2lu ZyBlZGdlDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gc2VhcmNoIGZvciB0aGUgc2FtZSBhZGRyZXNz IHRhZy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIGZvciBpIGluIDAgdG8gTkJMSU5FUy0xIGxvb3AN CiAgICAgIGlmICgoYWRkcmVzc192YWxpZF90YWcoaSk9JzEnKSBhbmQgKGFkZGRyZXNzX3Rh ZyhpKT1SZWFkQWRkcikpDQogICAgICB0aGVuICAtLSBsaW5lIDogZm91bmQNCiAgICAgICAg aWYgKEZsdXNoRW49JzEnKSB0aGVuDQogICAgICAgICAgYWRkcmVzc192YWxpZF90YWcoaSkg PD0gJzAnOw0KICAgICAgICBlbHNlDQogICAgICAgICAgaWYgUmVhZEVuPScxJyB0aGVuDQog ICAgICAgICAgICBoaXQ6PXRydWU7DQogICAgICAgICAgICB0X3JlYWQoaSk6PScxJzsNCiAg ICAgICAgICBlbmQgaWY7DQogICAgICAgIGVuZCBpZjsNCiAgICAgIGVuZCBpZjsNCg0KLS0g bWFuYWdlIGEgd3JpdGUgZW5hYmxlIDoNCiAgICAgIGlmIChXcml0ZUVuIGFuZCB3cml0ZV9z aWduYWwoaSkpPScxJyB0aGVuDQogICAgICAgIGFkZGRyZXNzX3RhZyhpKSA8PSBXcml0ZUFk ZHI7DQogICAgICBlbmQgaWY7DQoNCiAgICBlbmQgbG9vcDsNCg0KICAgIHdyaXRlX3NpZ25h bCA8PSB0X3JlYWQ7DQogICAgaWYgKGhpdD10cnVlKSB0aGVuDQogICAgICBJQ2FjaGVIaXQ8 PScxJzsNCiAgICBlbHNlDQogICAgICBJQ2FjaGVIaXQ8PScwJzsNCiAgICBlbmQgaWY7DQoN CiAgICBGSUZPX2lucHV0PD1DT05WX1NURF9MT0dJQ19WRUNUT1IoaSxMT0dMSU5FUyk7DQog IC0tIGluIHJlYWwgbGlmZSwgdGhpcyBpcyBhIGJpbmFyeSBlbmNvZGVyIG9mIDY0LT42IGJp dHMuDQoNCiAgZW5kIGlmOw0KZW5kIHByb2Nlc3MgSWNhY2hlX2FkZHJlc3NfdGFibGU7DQoN Cg0KDQpJY2FjaGVfTFJVX3VwZGF0ZSA6IHByb2Nlc3MgKGNsaykNCiAgdmFyaWFibGUgdCA6 IHN0ZF9sb2dpY192ZWN0b3IgKE5CTElORVMtMSBkb3dudG8gMCkgOj0gKG90aGVycz0+JzAn KTsNCiAgdmFyaWFibGUgdSA6IExSVV90YWdfdHlwZTsNCiAgdmFyaWFibGUgaSA6IGludGVn ZXI7DQogIHZhcmlhYmxlIGogOiBib29sZWFuOj1mYWxzZTsNCmJlZ2luDQogIGlmIChjbGsg PSAnMScpIHRoZW4gICAgICAgLS0gb25seSBvbiB0aGUgcmlzaW5nIGVkZ2UNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLSBVcGRhdGUgTFJVIGR1cmluZyB3cml0ZSAoYmV3YXJlIG9mIHRoZSBwcmlv cml0eSwgaXQgbWlnaHQgY2hhbmdlKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgaWYgV3JpdGVFbj0n MScgdGhlbg0KICAgICAgLS0gZnVsbCByb3RhdGUgOg0KICAgICAgdSgwKTo9TFJVX3RhZyhO QkxJTkVTLTEpOw0KICAgICAgZm9yIGkgaW4gMSB0byBOQkxJTkVTLTEgbG9vcA0KICAgICAg ICB1KGkpOj1MUlVfdGFnKGktMSk7DQogICAgICBlbmQgbG9vcDsNCiAgICBlbHNlDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCi0tIFVwZGF0ZSBMUlUgYWZ0ZXIgcmVhZCAoYmV3YXJlIG9mIHRoZSBjb2xs aXNpb25zLCB0b28pDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgIGlmIElDYWNoZUhpdD0nMScgdGhl bg0KICAgICAgICBmb3IgaSBpbiBOQkxJTkVTLTEgZG93bnRvIDEgbG9vcA0KICAgICAgICAg IGlmIExSVV90YWcoaSk9RklGT19pbnB1dCB0aGVuDQogICAgICAgICAgICBqOj10cnVlOw0K ICAgICAgICAgIGVuZCBpZjsNCiAgICAgICAgICBpZiBqPXRydWUgdGhlbg0KICAgICAgICAg ICAgdShpKTo9TFJVX3RhZyhpLTEpOw0KICAgICAgICAgIGVuZCBpZjsNCi0tIHRoaXMgaXMg bm90IGEgZ3JlYXQgYWxnb3JpdGhtIGJ1dCBpdCBzaG91bGQgd29yayBmb3IgdGhlIHNpbXMu Li4NCiAgICAgICAgZW5kIGxvb3A7DQogICAgICAgIHUoMCk6PUZJRk9faW5wdXQ7DQogICAg ICBlbmQgaWY7DQogICAgZW5kIGlmOw0KDQogICAgTFJVX3RhZzw9IHU7DQoNCiAgICAtLSBn ZW5lcmF0ZSB0aGUgd3JpdGUgc2lnbmFscyBmcm9tIHRoZSBMUlUgcXVldWUgOg0KICAgIGZv ciBpIGluIHQncmFuZ2UgbG9vcA0KICAgICAgaWYgTFJVX3RhZyhOQkxJTkVTLTEpPUNPTlZf U1REX0xPR0lDX1ZFQ1RPUihpLExPR0xJTkVTKSB0aGVuDQogICAgICAgIHQoaSk6PScxJzsN CiAgICAgIGVuZCBpZjsNCiAgICBlbmQgbG9vcDsNCiAgICB3cml0ZV9zaWduYWw8PXQ7DQoN CiAgZW5kIGlmOw0KZW5kIHByb2Nlc3MgSWNhY2hlX0xSVV91cGRhdGU7DQoNCg0KRU5EIGVz czE7DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoYXQncyBhbGwsIGZvbGtzLi4uDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --------------768D77773B32B79B6CC28B61-- From Colin Marquardt Sun Oct 1 04:10:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA02549 for ; Sun, 1 Oct 2000 06:33:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 06:33:53 +0200 (MEST) Received: (qmail 20467 invoked by uid 0); 1 Oct 2000 03:55:08 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 1 Oct 2000 03:55:08 -0000 X-eGroups-Return: sentto-1101623-917-970371264-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 01 Oct 2000 03:35:35 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 03:34:23 -0000 Received: (qmail 29737 invoked from network); 1 Oct 2000 02:11:39 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 1 Oct 2000 02:11:39 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 1 Oct 2000 02:11:39 -0000 Received: from morphin.marquardt-home.de (d200.nas21.sonic.net [209.204.136.200]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id EAA23050 for ; Sun, 1 Oct 2000 04:11:36 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13fYaK-0000tG-00 for ; Sat, 30 Sep 2000 19:10:36 -0700 To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D5C42F.5DD05C6@ifrance.com> X-Now-Playing: Umbra Et Imago's MYSTIC SOUND SAMPLER - Last Dream In-Reply-To: Nicolas Boulay's message of "Sat, 30 Sep 2000 12:45:03 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 36 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 30 Sep 2000 19:10:36 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a8b05d5f73c0c75585d40a2e4a43e71b Status: R X-Status: N Hi,

* Nicolas Boulay <nicolas.boulay@ifrance.com> writes:

> You have found the heavier stupid think in VHDL. There is absolutely no
> automatic cast for safty reason. I send you a diagram with all the cast
> and the use of fonction from iee.std_logic_arth.all to convert type.

No! Please do *not* use ieee.std_logic_arith (or ieee.std_logic_signed
ieee.std_logic_unsigned)! Despite its name, it is not a real IEEE package
but a proprietary Synopsys thing. Please read up on numeric_std in the
excellent VHDL FAQ.

If our simulator doesn't support numeric_std: scratch it.

> You need to use an intermediate value and then converted it in the good
> type. That's why just make "+1" take 3 lines !

With numeric_std it would look something like that (untested):

constant c_Address_MSB : natural := 7;
signal Address : std_logic_vector(c_Address_MSB downto 0);

Address <= to_std_logic_vector(to_integer(unsigned(Address)) + 1,
           Address'lenght)

The "unsigned" tells the conversion function how to interpret the
std_logic_vector.

I think it makes sense to show your code as early as possible to
discover newbie/style issues like that.

Cheers,
  Colin

--
From Jecel Assumpcao Jr Sun Oct 1 06:23:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA02552 for ; Sun, 1 Oct 2000 06:33:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 01 Oct 2000 06:33:54 +0200 (MEST) Received: (qmail 31350 invoked by uid 0); 1 Oct 2000 04:30:30 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 1 Oct 2000 04:30:30 -0000 X-eGroups-Return: sentto-1101623-918-970371602-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.143] by fg.egroups.com with NNFMP; 01 Oct 2000 03:41:14 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 03:40:01 -0000 Received: (qmail 24482 invoked from network); 1 Oct 2000 03:31:31 -0000 Received: from unknown (10.1.10.142) by m7.onelist.org with QMQP; 1 Oct 2000 03:31:31 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 1 Oct 2000 03:31:29 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id AAA20711 for ; Sun, 1 Oct 2000 00:40:39 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> In-Reply-To: <39D5FBA0.676BA52D@f-cpu.org> Message-Id: <00100101312101.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 01:23:42 -0300 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40d5957757612d4f390e47916b438456 Status: R X-Status: N This is an interesting web page:

   http://www.andraka.com/multipli.htm

-- Jecel
 From Yann Guidon Sun Oct 1 07:20:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04814 for ; Mon, 2 Oct 2000 02:10:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:02 +0200 (MEST) Received: (qmail 21832 invoked by uid 0); 1 Oct 2000 05:07:49 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 1 Oct 2000 05:07:49 -0000 X-eGroups-Return: sentto-1101623-919-970373747-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 01 Oct 2000 04:15:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 04:15:46 -0000 Received: (qmail 17564 invoked from network); 1 Oct 2000 04:15:46 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 1 Oct 2000 04:15:46 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 1 Oct 2000 04:15:45 -0000 Received: from f-cpu.org (nas1-160.ras.club-internet.fr [195.36.192.160]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA17949 for ; Sun, 1 Oct 2000 06:15:43 +0200 (MET DST) Message-ID: <39D6C982.27667C6D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 06:20:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] sim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bac78ca0a473636364af8e2fadc54f5f Status: R X-Status: N hello,

i've written a first testbench and the
result is a catastrophe. i still don't know
why the signals are not even initialized
when the reset signal is sent.

help !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 1 07:24:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04817 for ; Mon, 2 Oct 2000 02:10:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:03 +0200 (MEST) Received: (qmail 5572 invoked by uid 0); 1 Oct 2000 05:23:08 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 1 Oct 2000 05:23:08 -0000 X-eGroups-Return: sentto-1101623-920-970374028-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 01 Oct 2000 04:21:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 04:20:28 -0000 Received: (qmail 7185 invoked from network); 1 Oct 2000 04:20:28 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 1 Oct 2000 04:20:28 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 1 Oct 2000 04:20:27 -0000 Received: from f-cpu.org (nas1-160.ras.club-internet.fr [195.36.192.160]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA19244 for ; Sun, 1 Oct 2000 06:20:25 +0200 (MET DST) Message-ID: <39D6CA9E.94E89DB4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 06:24:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5cf3498e910c586b7bc62b4dae200909 Status: R X-Status: N Jecel Assumpcao Jr wrote:
> This is an interesting web page:
>    http://www.andraka.com/multipli.htm

yes, but targeted only for FPGAs.
Ray is an usual poster of comp.dsp and others.

btw, i found an online VHDL generator for
various functions. i can't find the url anymore
but i've saved some files. The 64*64 multiplier,
3-stage pipelines, is >1MB :-)

> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 1 07:54:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04820 for ; Mon, 2 Oct 2000 02:10:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:04 +0200 (MEST) Received: (qmail 17199 invoked by uid 0); 1 Oct 2000 05:32:34 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 1 Oct 2000 05:32:34 -0000 X-eGroups-Return: sentto-1101623-921-970375832-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 01 Oct 2000 04:50:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 04:50:32 -0000 Received: (qmail 16867 invoked from network); 1 Oct 2000 04:50:32 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 1 Oct 2000 04:50:32 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 1 Oct 2000 04:50:31 -0000 Received: from f-cpu.org (nas1-248.aub.club-internet.fr [195.36.150.248]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA00157 for ; Sun, 1 Oct 2000 06:50:29 +0200 (MET DST) Message-ID: <39D6D1AA.1ED16EAB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D5C42F.5DD05C6@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 06:54:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0af2062114264819cd9cac93e1aaac65 Status: R X-Status: N hi !

Colin Marquardt wrote:
> Hi,
>
> * Nicolas Boulay <nicolas.boulay@ifrance.com> writes:
>
> > You have found the heavier stupid think in VHDL. There is absolutely no
> > automatic cast for safty reason. I send you a diagram with all the cast
> > and the use of fonction from iee.std_logic_arth.all to convert type.
>
> No! Please do *not* use ieee.std_logic_arith (or ieee.std_logic_signed
> ieee.std_logic_unsigned)! Despite its name, it is not a real IEEE package
> but a proprietary Synopsys thing. Please read up on numeric_std in the
> excellent VHDL FAQ.

i wasn't aware of this. anyway, i don't think that it solves anything.

> If our simulator doesn't support numeric_std: scratch it.
that's an idea. but we can't do this all the time either.

> > You need to use an intermediate value and then converted it in the good
> > type. That's why just make "+1" take 3 lines !
>
> With numeric_std it would look something like that (untested):
>
> constant c_Address_MSB : natural := 7;
> signal Address : std_logic_vector(c_Address_MSB downto 0);
>
> Address <= to_std_logic_vector(to_integer(unsigned(Address)) + 1,
>            Address'lenght)
>
> The "unsigned" tells the conversion function how to interpret the
> std_logic_vector.

wow. But Nicolas also mentioned that some compilers don't support
nested function calls. That's would why it would sometimes take 3 lines...

> I think it makes sense to show your code as early as possible to
> discover newbie/style issues like that.

i posted the behavioural description recently, i'm trying to make it work now.
i am still a "beginner" and some problems are really weird.
i would have less problems with GCC ;-)

> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Sun Oct 1 10:24:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04838 for ; Mon, 2 Oct 2000 02:10:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:08 +0200 (MEST) Received: (qmail 5331 invoked by uid 0); 1 Oct 2000 10:37:05 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 1 Oct 2000 10:37:05 -0000 X-eGroups-Return: sentto-1101623-922-970396605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 01 Oct 2000 10:37:02 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 10:36:44 -0000 Received: (qmail 24150 invoked from network); 1 Oct 2000 10:36:44 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 1 Oct 2000 10:36:44 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 1 Oct 2000 10:36:43 -0000 Received: from morphin.marquardt-home.de (d97.nas21.sonic.net [209.204.136.97]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id MAA00504 for ; Sun, 1 Oct 2000 12:36:40 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13feQC-0001Bl-00 for ; Sun, 01 Oct 2000 01:24:32 -0700 To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D5C42F.5DD05C6@ifrance.com> <39D6D1AA.1ED16EAB@f-cpu.org> X-Now-Playing: Die Apokalyptischen Reiter's Soft & Stronger - Downfall In-Reply-To: Yann Guidon's message of "Sun, 01 Oct 2000 06:54:50 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 46 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 01:24:31 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d53f6cc76949630378da7ada94012448 Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

>> No! Please do *not* use ieee.std_logic_arith (or ieee.std_logic_signed
>> ieee.std_logic_unsigned)! Despite its name, it is not a real IEEE package
>> but a proprietary Synopsys thing. Please read up on numeric_std in the
>> excellent VHDL FAQ.

> i wasn't aware of this. anyway, i don't think that it solves anything.

It doesn't solve anything at the moment, but it makes sure that you
will not get my recommendation for numeric_std as answer when you
ask something else on comp.lang.vhdl :-)

>> If our simulator doesn't support numeric_std: scratch it.
> that's an idea. but we can't do this all the time either.

I think most of them do now, only Synopsys doesn't like it, for
obvious reasons.

>> Address <= to_std_logic_vector(to_integer(unsigned(Address)) + 1,
>> Address'lenght)

> wow. But Nicolas also mentioned that some compilers don't support
> nested function calls. That's would why it would sometimes take 3 lines...

Hmmm... the Leapfrog version I used had no problems with such things.

>> I think it makes sense to show your code as early as possible to
>> discover newbie/style issues like that.

> i posted the behavioural description recently, i'm trying to make it work now.

I saw it minutes after I posted this.

> i am still a "beginner" and some problems are really weird.

Absolutely, but in the end VHDL pays off over Verilog IMO. Unfortunately,
my knowledge about VHDL is slowly fading away as I am working on some old
Verilog code since a few months... :-P

Cheers,
  Colin

--

eGroups Sponsor
From polz@writeme.com Sun Oct 1 11:23:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04853 for ; Mon, 2 Oct 2000 02:10:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:13 +0200 (MEST) Received: (qmail 31210 invoked by uid 0); 1 Oct 2000 11:35:45 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 1 Oct 2000 11:35:45 -0000 X-eGroups-Return: sentto-1101623-923-970400141-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 01 Oct 2000 11:35:49 -0000 X-Sender: polz@writeme.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 11:35:41 -0000 Received: (qmail 19622 invoked from network); 1 Oct 2000 11:35:40 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 1 Oct 2000 11:35:40 -0000 Received: from unknown (HELO mojastwar.burek.net) (194.249.3.143) by mta1 with SMTP; 1 Oct 2000 11:35:40 -0000 Received: from localhost (mojastwar.burek.net) [127.0.0.1] (polz) by mojastwar.burek.net with esmtp (Exim 3.11 #1 (Debian)) id 13ffKx-00053c-00; Sun, 01 Oct 2000 11:23:11 +0200 X-Mailer: exmh version 2.1.1 10/15/1999 (debian) To: f-cpu@egroups.com In-reply-to: Your message of "Sun, 01 Oct 2000 01:46:07 BST." <39D6894F.5FAD9C39@f-cpu.org> References: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> <39D6894F.5FAD9C39@f-cpu.org> Message-Id: From: polz@writeme.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 11:23:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SDRAM Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ea49408a5eb00ab85c64142d5f9c3072 Status: R X-Status: N Why should people in Europe, Japan and the rest of the world care ?
eGroups Sponsor
From Yann Guidon Sun Oct 1 17:20:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04862 for ; Mon, 2 Oct 2000 02:10:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:15 +0200 (MEST) Received: (qmail 2033 invoked by uid 0); 1 Oct 2000 14:16:32 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 1 Oct 2000 14:16:32 -0000 X-eGroups-Return: sentto-1101623-924-970409785-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 01 Oct 2000 14:16:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 14:16:24 -0000 Received: (qmail 32462 invoked from network); 1 Oct 2000 14:16:24 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 1 Oct 2000 14:16:24 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 1 Oct 2000 14:16:24 -0000 Received: from f-cpu.org (nas3-2.ras.club-internet.fr [195.36.203.2]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA16921 for ; Sun, 1 Oct 2000 16:16:21 +0200 (MET DST) Message-ID: <39D7564A.9AB59250@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> <39D6894F.5FAD9C39@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 16:20:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SDRAM Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1740380f49516fcae930f976d8edb2ac Status: R X-Status: N hi,

polz@writeme.com wrote:
> Why should people in Europe, Japan and the rest of the world care ?

the sdram interface is cool. unfortunately, following the american
way of fucking things up, at least the europeans are loosening/weakening
the patent protection : they don't check everything and accept almost
any patent. the patent offices only care about the annual fees that
they get for "protecting" the claims of the people who have money.

I don't remember when the rambus patent is meant to become public domain,
but i guess that the f-cpu will be released before. if the core is bound
to the SDRAM interface, and if the rambus story doesn't end, industrial
companies won't help us to fab the chip.

but as i said before, there's no such problem yet and there are several
"turnarounds", the "MFM trick" being one but it's a whole new project.

ok, let's debug the VHDL codes now ;-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sun Oct 1 17:20:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04865 for ; Mon, 2 Oct 2000 02:10:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:16 +0200 (MEST) Received: (qmail 8034 invoked by uid 0); 1 Oct 2000 14:16:52 -0000 Received: from mk.egroups.com (208.50.144.76) by mx06.rz2.gmx.net with SMTP; 1 Oct 2000 14:16:52 -0000 X-eGroups-Return: sentto-1101623-925-970409805-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 01 Oct 2000 14:16:50 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 14:16:45 -0000 Received: (qmail 10841 invoked from network); 1 Oct 2000 14:16:45 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 1 Oct 2000 14:16:45 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 1 Oct 2000 14:16:45 -0000 Received: from f-cpu.org (nas3-2.ras.club-internet.fr [195.36.203.2]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA29399 for ; Sun, 1 Oct 2000 16:16:37 +0200 (MET DST) Message-ID: <39D75648.A5FAB7D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D5C42F.5DD05C6@ifrance.com> <39D6D1AA.1ED16EAB@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 16:20:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 81bd9ad627f7e00994466102355fa73e Status: R X-Status: N Colin Marquardt wrote:
> Hi,
> * Yann Guidon <whygee@f-cpu.org> writes:
> >> No! Please do *not* use ieee.std_logic_arith (or ieee.std_logic_signed
> >> ieee.std_logic_unsigned)! Despite its name, it is not a real IEEE package
> >> but a proprietary Synopsys thing. Please read up on numeric_std in the
> >> excellent VHDL FAQ.
> > i wasn't aware of this. anyway, i don't think that it solves anything.
> It doesn't solve anything at the moment, but it makes sure that you
> will not get my recommendation for numeric_std as answer when you
> ask something else on comp.lang.vhdl :-)
so what should i do now ? rename the package ? :-)
i'm seeking a solution but i'm still new to this.

i don't know all the story of the synopsys thing, can you
send me the FAQ ? thanks.

> >> If our simulator doesn't support numeric_std: scratch it.
> > that's an idea. but we can't do this all the time either.
> I think most of them do now, only Synopsys doesn't like it, for
> obvious reasons.
yep, but what could they do ? it's part of the ieee thing, so they accept.

> >> Address <= to_std_logic_vector(to_integer(unsigned(Address)) + 1,
> >> Address'lenght)
> > wow. But Nicolas also mentioned that some compilers don't support
> > nested function calls. That's would why it would sometimes take 3 lines...
> Hmmm... the Leapfrog version I used had no problems with such things.
If you contradict Nicolas, you won't be friend with him ;-)

> >> I think it makes sense to show your code as early as possible to
> >> discover newbie/style issues like that.
> > i posted the behavioural description recently, i'm trying to make it work now.
> I saw it minutes after I posted this.
... and you were in awe to see how dumb it is ;-)
i mostly did it like a parallel C or Pascal program, and now i see the side effects...

> > i am still a "beginner" and some problems are really weird.
> Absolutely, but in the end VHDL pays off over Verilog IMO. Unfortunately,
> my knowledge about VHDL is slowly fading away as I am working on some old
> Verilog code since a few months... :-P
poor, poor Colin...
poor, poor me too :-) i never cease to jump into unbelievable situations.

> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sun Oct 1 20:25:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04886 for ; Mon, 2 Oct 2000 02:10:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:22 +0200 (MEST) Received: (qmail 20576 invoked by uid 0); 1 Oct 2000 17:20:59 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 1 Oct 2000 17:20:59 -0000 X-eGroups-Return: sentto-1101623-926-970420852-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 01 Oct 2000 17:20:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 17:20:52 -0000 Received: (qmail 23192 invoked from network); 1 Oct 2000 17:20:51 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 1 Oct 2000 17:20:51 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 1 Oct 2000 17:20:51 -0000 Received: from f-cpu.org (nas3-10.ras.club-internet.fr [195.36.203.10]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA12431 for ; Sun, 1 Oct 2000 19:20:48 +0200 (MET DST) Message-ID: <39D78185.6190890E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 19:25:09 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) happy :-) Content-Type: multipart/mixed; boundary="------------682E0D673DA2E6B35CFFE0C4" X-UIDL: 731ea1abcde41223e473ddfbde3e23c3 Status: R X-Status: N --------------682E0D673DA2E6B35CFFE0C4 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

i finally succeeded in making a component work.
so now, i have a compiler/simulator that works rather smoothly,
and i made a little FIFO that can be reset to a fixed pattern.
I think that the rest will follow in the behavioural domain.

Colin will remark that i use only bit's and bit_vector's
and the text i/o should not be bound by synopsys, i guess.
OTOH, std_logic and the necessary libraries were useful to
detect the uninitialised variables.

As pointed before, work should be started on the execution units.
if someone wants to make the pipelined adder and multiplier
or the shifter, the inc/findfirst, the ROP2 etc... please start now.
remember that it should be capable of SIMD but it is not mandatory
for the first attempts, as long as it works smoothly :-)

later,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------682E0D673DA2E6B35CFFE0C4 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="simple5.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="simple5.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCi0tIHRlc3RiZW5jaGluZyB0ZXN0YmVuY2hlcy4uLiBZRw0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLS0g QSBzaW1wbGUgOCo4IGJpdCBGSUZPDQplbnRpdHkgbXlfZmlmbyBpcyANCiAgcG9ydCAoY2xr LCByZXNldCA6IGluIGJpdDsNCiAgICAgICAgRGluIDogaW4gYml0X3ZlY3RvcigwIHRvIDcp Ow0KICAgICAgICBEb3V0IDogb3V0IGJpdF92ZWN0b3IoMCB0byA3KSk7DQplbmQgbXlfZmlm bzsNCg0KYXJjaGl0ZWN0dXJlIGFyY2ggb2YgbXlfZmlmbyBpcw0KICB0eXBlIGZpZm9fYXJy YXkgaXMgYXJyYXkgICgwIHRvIDcpIG9mIGJpdF92ZWN0b3IoMCB0byA3KTsNCiAgc2lnbmFs IGFyIDogIGZpZm9fYXJyYXk7DQogIHNoYXJlZCB2YXJpYWJsZSBjeWNsZSA6IGludGVnZXI6 PTA7DQoNCiAgLS0gbXkgb3duIGNvbnZlcnNpb24gdXRpbGl0eSA6DQogIGZ1bmN0aW9uIGNv bnZfYml0X3ZlY3RvcihpLGo6aW50ZWdlcikgcmV0dXJuIGJpdF92ZWN0b3IgaXMNCiAgICB2 YXJpYWJsZSB2OiBiaXRfdmVjdG9yKGotMSBkb3dudG8gMCk6PShvdGhlcnM9PicwJyk7DQog ICAgdmFyaWFibGUgdDppbnRlZ2VyOj1pOw0KICBiZWdpbg0KICAgIGZvciBrIGluIDAgdG8g ai0xIGxvb3ANCiAgICAgIGlmICh0IG1vZCAyKSA9IDEgdGhlbg0KICAgICAgICB2KGspIDo9 ICcxJzsNCiAgICAgICAgdDo9dC0xOw0KICAgICAgZW5kIGlmOw0KICAgICAgdDo9IHQvMjsN CiAgICBlbmQgbG9vcDsNCiAgICByZXR1cm4gdjsNCiAgZW5kOw0KDQpiZWdpbg0KDQogcHJv Y2VzcyAoQ0xLLCByZXNldCkNCiBiZWdpbg0KICAgaWYgcmVzZXQ9JzEnIHRoZW4NCiAgICAg Zm9yIGkgaW4gNyBkb3dudG8gMCBsb29wDQogICAgICAgYXIoaSk8PWNvbnZfYml0X3ZlY3Rv cihpLDgpOw0KICAgICBlbmQgbG9vcDsNCiAgIGVsc2UNCiAgICAgaWYgKENMSydldmVudCBh bmQgQ0xLID0gJzEnKSB0aGVuDQogICAgICAgZm9yIGkgaW4gNyBkb3dudG8gMSBsb29wDQog ICAgICAgICBhcihpKTw9YXIoaS0xKTsNCiAgICAgICBlbmQgbG9vcDsNCiAgICAgICBhcigw KTw9RGluOw0KICAgICBlbmQgaWY7DQogICBlbmQgaWY7DQogZW5kIHByb2Nlc3M7DQoNCiBE b3V0PD1hcig3KTsNCg0KZW5kIGFyY2g7DQoNCmxpYnJhcnkgaWVlZTsNCnVzZSBzdGQudGV4 dGlvLmFsbDsNCnVzZSBpZWVlLnN0ZF9sb2dpY190ZXh0aW8uYWxsOw0KDQotLSB0ZXN0YmVu Y2hpbmcgdGhlIGZpZm8NCmVudGl0eSB0ZXN0YmVuY2ggaXMgDQplbmQgdGVzdGJlbmNoOw0K DQp1c2UgV09SSy5teV9maWZvOw0KDQphcmNoaXRlY3R1cmUgdGVzdDEgb2YgdGVzdGJlbmNo IGlzDQogIHNpZ25hbCBkaW4sZG91dCA6IGJpdF92ZWN0b3IoMCB0byA3KTo9KG90aGVycz0+ JzAnKTsNCiAgc2lnbmFsIHJlc2V0LGNsayA6IGJpdDo9JzAnOw0KICBzaGFyZWQgdmFyaWFi bGUgY3ljbGUgOiBuYXR1cmFsIDo9MTsNCg0KICBwcm9jZWR1cmUgcHJpbnQgaXMNCiAgICB2 YXJpYWJsZSBsb3V0IDogbGluZSA7DQogIGJlZ2luDQogICAgV1JJVEUobG91dCxkaW4pOw0K ICAgIFdSSVRFKGxvdXQsIiAiKTsNCiAgICBXUklURShsb3V0LGRvdXQpOw0KICAgIFdSSVRF KGxvdXQsIiAiKTsNCiAgICBXUklURShsb3V0LGNsayk7DQogICAgV1JJVEUobG91dCwiICIp Ow0KICAgIFdSSVRFKGxvdXQscmVzZXQpOw0KICAgIFdSSVRFKGxvdXQsIiAiKTsNCiAgICBX UklURShsb3V0LGN5Y2xlKTsNCiAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgZW5k Ow0KDQpiZWdpbg0KDQogLS0gSW5zdGFudGlhdGUgdGhlIHRlc3RlZCBjaXJjdWl0DQogc3R1 ZmY6IGVudGl0eSBteV9maWZvDQogICBwb3J0IG1hcCgNCiAgICAgRGluID0+IGRpbiwNCiAg ICAgRG91dCA9PiBkb3V0LA0KICAgICBjbGsgPT4gY2xrLA0KICAgICByZXNldCA9PiByZXNl dA0KICAgKTsNCg0KIHByb2Nlc3MNCiBiZWdpbg0KICAgcHJpbnQ7DQogICByZXNldDw9JzEn Ow0KICAgd2FpdCBmb3IgMTAgbnM7DQogICBwcmludDsNCiAgIHJlc2V0PD0nMCc7DQogICB3 YWl0IGZvciAxMCBuczsNCiAgIHByaW50Ow0KDQogICBmb3IgYXplcnR5IGluIDAgdG8gMTAg bG9vcA0KICAgICBjbGs8PScxJzsNCiAgICAgd2FpdCBmb3IgMTAgbnM7DQogICAgIGNsazw9 JzAnOw0KICAgICB3YWl0IGZvciAxMCBuczsNCiAgICAgY3ljbGU6PWN5Y2xlKzE7DQogICAg IHByaW50Ow0KICAgZW5kIGxvb3A7DQoNCiAgIHdhaXQ7IC0tIHN0b3AgdGhlIHNpbXVsYXRp b24NCiBlbmQgcHJvY2VzczsNCg0KZW5kIHRlc3QxOw0K --------------682E0D673DA2E6B35CFFE0C4-- From "Richard E.Hartney" Sun Oct 1 21:39:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04898 for ; Mon, 2 Oct 2000 02:10:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:25 +0200 (MEST) Received: (qmail 8230 invoked by uid 0); 1 Oct 2000 19:39:02 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 1 Oct 2000 19:39:02 -0000 X-eGroups-Return: sentto-1101623-927-970429135-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 01 Oct 2000 19:38:56 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 19:38:54 -0000 Received: (qmail 26073 invoked from network); 1 Oct 2000 19:38:54 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 1 Oct 2000 19:38:54 -0000 Received: from unknown (HELO mail2.lig.bellsouth.net) (205.152.0.56) by mta1 with SMTP; 1 Oct 2000 19:38:54 -0000 Received: from 0018728164 (host-209-215-11-170.bix.bellsouth.net [209.215.11.170]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id PAA16910; Sun, 1 Oct 2000 15:38:52 -0400 (EDT) Message-ID: <001201c02bdf$5c9a6ea0$aa0bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 14:39:47 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] American Fuck-ups Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C02BB5.72AEB0E0" X-UIDL: e14b6e7361923214bf398c320c515000 Status: R X-Status: N ------=_NextPart_000_000F_01C02BB5.72AEB0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We may screw up a few things - but we don't spend 5 to ten years catching u= p with anyone Mr Guidon. You are LEARNING from our mistakes. And your BSM= S don't make you GOD's gift to the world......... ERIN GREENE ------=_NextPart_000_000F_01C02BB5.72AEB0E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
We may screw up a few things - but we don't spend 5 to ten years catching up with anyone Mr Guidon.  You are LEARNING from our mistakes.  And your BSMS
don't make you GOD's gift to the world.........
 
ERIN GREENE
------=_NextPart_000_000F_01C02BB5.72AEB0E0-- From Yann Guidon Sun Oct 1 23:36:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04913 for ; Mon, 2 Oct 2000 02:10:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:28 +0200 (MEST) Received: (qmail 15142 invoked by uid 0); 1 Oct 2000 20:32:08 -0000 Received: from ck.egroups.com (208.50.144.69) by mx19.rz2.gmx.net with SMTP; 1 Oct 2000 20:32:08 -0000 X-eGroups-Return: sentto-1101623-928-970432320-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 01 Oct 2000 20:32:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 20:32:00 -0000 Received: (qmail 16077 invoked from network); 1 Oct 2000 20:31:59 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 1 Oct 2000 20:31:59 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 1 Oct 2000 20:31:59 -0000 Received: from f-cpu.org (nas4-140.aub.club-internet.fr [195.36.145.140]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10475 for ; Sun, 1 Oct 2000 22:31:56 +0200 (MET DST) Message-ID: <39D7AE52.93F11B5C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <001201c02bdf$5c9a6ea0$aa0bd7d1@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 01 Oct 2000 22:36:18 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] American Fuck-ups Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d5b4cfa4392b3011837057be65bca00 Status: R X-Status: N hi,

<turning his tongue 7 times in his mouth>
<turning 7 times more>

> "Richard E.Hartney" wrote:
>
> We may screw up a few things - but we don't spend 5 to ten years
> catching up with anyone Mr Guidon.  You are LEARNING from our
> mistakes.  And your BSMS don't make you GOD's gift to the world.........

i'm sorry for you.

but why don't you help instead of using some swear words ?
i am asking for HELP, not less, and you don't help much.
if you are so good, why don't you come back (i thought you were
gone) and help design the other execution units ?

regards,
> ERIN GREENE
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From graham@belegost.mit.edu Sun Oct 1 22:36:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04916 for ; Mon, 2 Oct 2000 02:10:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:29 +0200 (MEST) Received: (qmail 13118 invoked by uid 0); 1 Oct 2000 20:36:22 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 1 Oct 2000 20:36:22 -0000 X-eGroups-Return: sentto-1101623-929-970432578-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 01 Oct 2000 20:36:19 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 20:36:17 -0000 Received: (qmail 25093 invoked from network); 1 Oct 2000 20:36:17 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 1 Oct 2000 20:36:17 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 1 Oct 2000 20:36:17 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA06573 for f-cpu@egroups.com; Sun, 1 Oct 2000 16:36:16 -0400 Message-Id: <200010012036.QAA06573@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <7FAD6DD85CD9224E80256969008325A4.0000000000000000@chrystal.gbr.xerox.com> from "Jeff Davies/CDPTEST" at Sep 30, 2000 01:02:01 AM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 16:36:15 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d05ee9ba88ba5c009335dd9bc2bf21cf Status: R X-Status: N >
Jeff Davies wrote:
> So,,, what about a GPL FPGA design? Is this a crazy idea. If not, it could
> be done in Electric, and then used to bootstrap the free cores
> industry?  I think FPGA structure is simple internally (in the main)....
> any thoughts?
>
Its one of my pet ideas too, but nobody much seems to think its realistic
(compared, say, with an Intel-beating cpu ;-). The main objections
seem to be:
how are you going to get the volume you'd need made?
what about the patents?
Manufacture is the same problem whether its a cpu or an fpga; I don't
have any answers, apart from try it and see...
Patents are more of a problem. Just because they are relatively simple
means you can't make a Xilinx-like fpga without treading on their patents.
It would have to be an FPGA with some original approach; I think its
more of a research type problem than most open-source projects are
(which usually re-implement the wheel :-) But there are some nice things
an open-source fpga could do that current fpgas don't (eg transparent
access to configuration bits and external read/write to internal locations).

I think a project to do this would be excellent, but unless there are
some people around with experience in this and some definite ideas its
likely to turn into another of those 'lets argue about basic principles
for a couple of years and not design anything' style projects :-(

Graham

 From Colin Marquardt Sun Oct 1 22:39:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04919 for ; Mon, 2 Oct 2000 02:10:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:30 +0200 (MEST) Received: (qmail 31743 invoked by uid 0); 1 Oct 2000 20:36:39 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 1 Oct 2000 20:36:39 -0000 X-eGroups-Return: sentto-1101623-930-970432579-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 01 Oct 2000 20:36:27 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 20:36:19 -0000 Received: (qmail 21422 invoked from network); 1 Oct 2000 20:36:18 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 1 Oct 2000 20:36:18 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 1 Oct 2000 20:36:18 -0000 Received: from morphin.marquardt-home.de (e155.nas22.sonic.net [209.204.142.155]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id WAA24170 for ; Sun, 1 Oct 2000 22:36:14 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13fptg-0003nm-00 for ; Sun, 01 Oct 2000 13:39:44 -0700 To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D5C42F.5DD05C6@ifrance.com> <39D6D1AA.1ED16EAB@f-cpu.org> <39D75648.A5FAB7D@f-cpu.org> X-Now-Playing: Hollenthon's Domus Mundi - Reprisal - Malis Avibus In-Reply-To: Yann Guidon's message of "Sun, 01 Oct 2000 16:20:40 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 167 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 13:39:43 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 72d5f47de52cbc2eb3e56c6f55d59946 Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

> Colin Marquardt wrote:
>> Hi,
>> * Yann Guidon <whygee@f-cpu.org> writes:
>> >> No! Please do *not* use ieee.std_logic_arith (or ieee.std_logic_signed
>> >> ieee.std_logic_unsigned)! Despite its name, it is not a real IEEE package
>> >> but a proprietary Synopsys thing. Please read up on numeric_std in the
>> >> excellent VHDL FAQ.

> so what should i do now ? rename the package ? :-)

Uhm, ... what do you mean with "rename"? Just get rid of
ieee.std_logic_arith and use ieee.numeric_std instead, then make the
conv_<xxx> functions to be to_<yyy> functions.

> i'm seeking a solution but i'm still new to this.

What was the problem again? :-) numeric_std can do the same thing
for you, and it is the proper solution.

> i don't know all the story of the synopsys thing, can you
> send me the FAQ ? thanks.

It is posted regularly on comp.lang.vhdl, and can be found at (looks
up URL):
  http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html

The relevant part for this topic is this:

| 4.2.21 How to Convert Between Integer and Bit/Std_Logic-Vectors
|
| There are two IEEE-standard packages that provide functionality to
| convert between integers and either bit_vectors or std_logic_vectors:
|
|       "IEEE.numeric_bit" includes functions to convert bit-based vectors
|       "IEEE.numeric_std" includes functionality to convert std_logic_vectors
|
| Both packages (see Section Section 4.7 on how to get these packages)
| define two new vector types: SIGNED and UNSIGNED. SIGNED vectors
| represent two's-complement integers, while UNSIGNED vectors
| represent unsigned-magnitude integers. Each package includes four
| conversion functions:
|
|         function TO_INTEGER (ARG: UNSIGNED) return NATURAL;
|         -- Result subtype: NATURAL.  Value cannot be negative since
|         --         parameter is an UNSIGNED vector.
|         -- Result: Converts the UNSIGNED vector to an INTEGER.
|
|         function TO_INTEGER (ARG: SIGNED) return INTEGER;
|         -- Result subtype: INTEGER
|         -- Result: Converts a SIGNED vector to an INTEGER.
|
|         function TO_UNSIGNED (ARG, SIZE: NATURAL) return UNSIGNED;
|         -- Result subtype: UNSIGNED(SIZE-1 downto 0)
|         -- Result: Converts a non-negative INTEGER to an UNSIGNED
|         --         vector with the specified size.
|
|         function TO_SIGNED (ARG: INTEGER; SIZE: NATURAL) return SIGNED;
|         -- Result subtype: SIGNED(SIZE-1 downto 0)
|         -- Result: Converts an INTEGER to a SIGNED vector of the
|         --         specified size.
|
| The first two functions may be used to convert a UNSIGNED or SIGNED
| vector to an integer. For example,
|
|         libaray IEEE;
|         use IEEE.std_logic_1164.all;
|         use ieee.numeric_std.all;
|         ...
|         variable int : integer;
|         variable unsigned_vec : UNSIGNED(0 to 7);
|         variable signed_vec : SIGNED(0 to 7);
|         ...
|         int := TO_INTEGER(unsigned_vec);
|         int := TO_INTEGER(signed_vec);
|
| Note that a value of type bit_vector or std_logic_vector must be
| converted to SIGNED or UNSIGNED before calling TO_INTEGER. This
| conversion (see also Section 4.2.17) is necessary in order to
| determine the interpretation of the most-significant bit of the
| vector:
|
|         variable int : integer;
|         variable bvec : bit_vector(0 to 7);
|         ...
|         int := TO_INTEGER(UNSIGNED(bvec)); -- bvec is treated as a
|                                            -- unsigned magnitude
|                                            -- representation of an
|                                            -- integer value
|         int := TO_INTEGER(SIGNED(bvec)); -- bvec is treated as a
|                                          -- two's-complement
|                                          -- representation of an
|                                          -- integer value
|
| TO_UNSIGNED and TO_SIGNED may be used to convert a integer value into a
| corresponding bit_vector or std_logic vector, as shown in the following
| example. The second parameter to each function determines the size of
| the resulting vector:
|
|         variable int : integer := 1;
|         variable unsigned_vec : UNSIGNED(0 to 7);
|         variable signed_vec : SIGNED(0 to 7);
|         ...
|         unsigned_vec := TO_UNSIGNED(int, unsigned_vec'Length);
|         signed_vec := TO_SIGNED(int, signed_vec'Length);
|
| A SIGNED or UNSIGNED value can be transformed into a plain bit_vector or
| std_logic_vector using explicit conversion (see also Section 4.2.17). The
| following example shows how to convert a signed integer into a bit_vector
| and a non- negative integer into a std_logic_vector:
|
|         variable bvec : bit_vector(0 to 7);
|         variable slvec : std_logic_vector(0 to 7);
|         ...
|         bvec := bit_vector(TO_SIGNED(int, bvec'Length));
|         slvec := std_logic_vector(TO_UNSIGNED(int, slvec'Length));
|
| Note: Synopsys has produced three packages: std_logic_arith,
| std_logic_signed, and std_logic_unsigned that are intended to
| provide functionality similar to numeric_bit and numeric_std. In
| particular, the same two types, SIGNED and UNSIGNED are
| defined. Moreover, the packages include functions to convert between
| vectors and integers. These packages are typically even installed in
| the library IEEE. However, these packages are NOT standard, and
| different vendors have different and mutually incompatible
| versions. Also, there are naming clashes when some of these packages
| are used together. So, it is recommended that numeric_bit or
| numeric_std be used in preference to these non-standard packages.
|
| See Section Section Section 4.10 for a more detailed discussion on
| arithmetic packages for bit_vectors and std_logic_vectors.


>> >> If our simulator doesn't support numeric_std: scratch it.
>> > that's an idea. but we can't do this all the time either.
>> I think most of them do now, only Synopsys doesn't like it, for
>> obvious reasons.
> yep, but what could they do ? it's part of the ieee thing, so they accept.

I am not sure if e.g. Design Compiler supports it now, it definitely
did not a year ago (Rainer, do you know more?). Synopsys does it as
they do it with VHDL'93: they just don't support it (not fully at
least). And since they are the "Microsoft of the EDA tool industry",
it is hard to find alternatives (and of course, nobody ever got
fired for choosing Synopsys :-).

>> > wow. But Nicolas also mentioned that some compilers don't support
>> > nested function calls. That's would why it would sometimes take 3 lines...
>> Hmmm... the Leapfrog version I used had no problems with such things.
> If you contradict Nicolas, you won't be friend with him ;-)

I am just interested in the version which had this. I know there is
an "issue" (depending on how you read the LRM not a real bug I guess:
it could not decide if the ' is the tick for specifying a type or the
beginning of a bit specification like in '1'), but it happens in such
a rare occasion only...

>> I saw it minutes after I posted this.
> ... and you were in awe to see how dumb it is ;-)

I didn't look too close. :-)

Cheers,
  Colin
 From Colin Marquardt Sun Oct 1 22:53:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04937 for ; Mon, 2 Oct 2000 02:10:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:37 +0200 (MEST) Received: (qmail 6089 invoked by uid 0); 1 Oct 2000 21:39:09 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 1 Oct 2000 21:39:09 -0000 X-eGroups-Return: sentto-1101623-931-970436343-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 01 Oct 2000 21:39:08 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 21:39:03 -0000 Received: (qmail 10037 invoked from network); 1 Oct 2000 21:39:03 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 1 Oct 2000 21:39:03 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 1 Oct 2000 21:39:02 -0000 Received: from morphin.marquardt-home.de (d124.nas22.sonic.net [209.204.137.124]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id XAA12822 for ; Sun, 1 Oct 2000 23:38:58 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13fq72-0003oQ-00 for ; Sun, 01 Oct 2000 13:53:32 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> X-Now-Playing: Incubator's MCMETALXCVIII - Fear 2 Fear In-Reply-To: Yann Guidon's message of "Sun, 01 Oct 2000 19:25:09 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 33 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 13:53:32 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3a457f846b2de84cddf5226e527c728b Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

> Colin will remark that i use only bit's and bit_vector's

Hey, how did you know that? :-) Really... what is making you stay away
>from std_logic_vector, or, better in my opinion, std_ulogic_vector?

(std_ulogic_vector for the real design, since it doesn't resolve
clashes between multiple drivers automatically, you have to find the
X'es in simulation and track them down, which is almost always some
unwanted behaviour which otherwise would be hidden until
later. Unfortunately, the Reuse Methdology Manual suggests
otherwise...)

> and the text i/o should not be bound by synopsys, i guess.

textio is okay. it is really just the three _arith, _unsigned and
_signed.

> OTOH, std_logic and the necessary libraries were useful to
> detect the uninitialised variables.

See? :-)

> As pointed before, work should be started on the execution units.
> if someone wants to make the pipelined adder and multiplier
> or the shifter, the inc/findfirst, the ROP2 etc... please start now.

So much code, so little time... :-(

Colin
 From Michael Riepe Sun Oct 1 23:30:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04940 for ; Mon, 2 Oct 2000 02:10:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:37 +0200 (MEST) Received: (qmail 13943 invoked by uid 0); 1 Oct 2000 21:47:15 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 1 Oct 2000 21:47:15 -0000 X-eGroups-Return: sentto-1101623-932-970436832-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 01 Oct 2000 21:47:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 21:47:11 -0000 Received: (qmail 21500 invoked from network); 1 Oct 2000 21:47:11 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 1 Oct 2000 21:47:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.119) by mta3 with SMTP; 1 Oct 2000 21:47:03 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00567; Sun, 1 Oct 2000 23:30:14 +0200 Message-ID: <20001001233014.63696@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D697B2.4C8C1EEE@f-cpu.org>; from Yann Guidon on Sun, Oct 01, 2000 at 02:47:30AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 23:30:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" X-UIDL: b89b763bc74e68dafef9f32d11fac03b Status: R X-Status: N --J/dobhs11T7y2rNN Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, Oct 01, 2000 at 02:47:30AM +0100, Yann Guidon wrote:

> so i completed the missing lines in the LRU update code.
> this is coded as if i was using C, so don't care about the
> capability of synthesis.

While you were busy, I finished my version.  It's a little different.
First of all, it does not update the LRU when a cache line is filled;
doing so would be Not A Good Thing (tm), IMHO.  Instead, the LRU is always
updated immediately following a read operation (at the next clock cycle),
cache hit or not.

One of the other goodies is that you can invalidate an address range :)
It's limited to power-of-two size and alignment values, but that made
the change pretty simple, and flushing arbitrary ranges of memory is
a rarely needed operation anyway.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="icache.vhdl" -- icache.vhdl - instruction cache for the F-CPU -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: icache.vhdl,v 1.4 2000/10/01 20:52:02 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; -- gotta get rid of that later use IEEE.numeric_std.all; entity ICache is generic ( NBITS : integer := 256; -- cache line size (32 bytes) NADDRS : integer := 27; -- number of address bits (32 - 5) => 4 GByte NLINES : integer := 64; -- number of cache lines NLOG : integer := 6 -- log2(NLINES) ); port ( -- read port Addr : in std_logic_vector(NADDRS-1 downto 0); -- read address Read : in std_logic; -- read line(addr) -- invalidate (mutually exclusive with read, uses Addr) Mask : in std_logic_vector(NADDRS-1 downto 0); -- mask for invalidate Inv : in std_logic; -- invalidate lines(addr, mask) -- fill port Fill : in std_logic_vector(NLINES-1 downto 0); -- fill cache line Ain : in std_logic_vector(NADDRS-1 downto 0); -- new tag Din : in std_logic_vector(NBITS-1 downto 0); -- new data -- clock & reset Clk : in std_logic; -- global clock Rst : in std_logic; -- asynchronous reset -- outputs Dout : out std_logic_vector(NBITS-1 downto 0); Hit : out std_logic ); end ICache; architecture ICache_arch1 of ICache is -- Data types type Line_Array is array(NLINES-1 downto 0) of std_logic_vector(NBITS-1 downto 0); type Tag_Array is array(NLINES-1 downto 0) of std_logic_vector(NADDRS-1 downto 0); type LRU_Array is array(NLINES-1 downto 0) of std_logic_vector(NLOG-1 downto 0); -- Cache subunit signal data : Line_Array; signal tags : Tag_Array; signal valid : std_logic_vector(NLINES-1 downto 0); signal addr_cmp : Tag_Array; -- tags(<>) xor Addr -- LRU subunit signal lru : LRU_Array; signal match : std_logic_vector(NLINES-1 downto 0); signal enable : std_logic_vector(NLINES-2 downto 0); -- LRU control interface signal lru_mru : std_logic_vector(NLOG-1 downto 0); signal lru_update : std_logic; begin -- -- Part 1: the LRU subunit -- -- 1a: find the matching register process (lru, lru_mru) variable i : natural; begin match <= (others => '0'); for i in NLINES-1 downto 0 loop if (lru(i) = lru_mru) then match(i) <= '1'; end if; end loop; end process; -- 1b: block the rest of the queue process (match) variable zero : std_logic_vector(NLINES-1 downto 0) := (others => '0'); variable i : natural; begin enable <= (others => '0'); for i in NLINES-2 downto 0 loop if (match(NLINES-1 downto i+1) = zero(NLINES-1 downto i+1)) then enable(i) <= '1'; end if; end loop; end process; -- 1c: shift (and reset) circuitry process (Clk, Rst) variable i : natural; begin if (Rst = '1') then -- asynchronous reset for i in NLINES-1 downto 0 loop lru(i) <= conv_std_logic_vector(i, NLOG); end loop; elsif Clk'event and (Clk = '1') then -- LRU update if (lru_update = '1') then for i in 0 to NLINES-2 loop if (enable(i) = '1') then lru(i) <= lru(i + 1); end if; end loop; lru(NLINES-1) <= lru_mru; end if; end if; end process; -- -- Part 2: the cache itself -- -- 2a: compare tags and address process (Addr, tags) variable i : natural; begin -- don't combine the bits yet... we need them later for i in NLINES-1 downto 0 loop addr_cmp(i) <= Addr xor tags(i); end loop; end process; -- 2b: do all the work process (Clk, Rst) variable zero : std_logic_vector(NADDRS-1 downto 0) := (others => '0'); variable o : std_logic_vector(NBITS-1 downto 0); variable h : std_logic; variable line : std_logic_vector(NLOG-1 downto 0); variable update : std_logic; variable i : natural; begin -- default values o := (others => '0'); -- why use 'Z' here? h := '0'; line := (others => '0'); update := '0'; -- let the show begin if (Rst = '1') then -- asynchronous reset valid <= (others => '0'); elsif Clk'event and (Clk = '1') then -- Inv has higher priority than Read/Fill if (Inv = '1') then -- invalidate lines(addr, mask) -- to invalidate ALL lines, set Mask to (others => '0') for i in NLINES-1 downto 0 loop if ((addr_cmp(i) and Mask) = zero) then valid(i) <= '0'; end if; end loop; -- TODO: stall/abort colliding writes? else -- read if (Read = '1') then -- find cache line -- default is least recently used line (cache miss) line := lru(0); for i in NLINES-1 downto 0 loop if (valid(i) = '1') and (addr_cmp(i) = zero) then -- cache hit, output data o := data(i); h := '1'; -- remember cache line number line := conv_std_logic_vector(i, NLOG); exit; end if; end loop; if (h /= '1') then -- handle cache miss: -- invalidate least recently used line -- (re-validated by fill operation) valid(to_integer(unsigned(line))) <= '0'; -- TODO: tell memory controller to fetch this line -- TODO: stall IF/ID unit end if; -- update LRU at the next clock cycle update := '1'; -- -- Note: the LRU is updated after EVERY read, even -- when a cache miss occurs (and NOT updated when the -- line is finally filled). If we did otherwise, the -- next cache miss might use the same cache line again. -- end if; -- line fill for i in NLINES-1 downto 0 loop if (Fill(i) = '1') then -- fill line and re-validate it tags(i) <= Ain; data(i) <= Din; valid(i) <= '1'; exit; end if; end loop; end if; end if; -- LRU control lru_mru <= line; lru_update <= update; -- outputs Dout <= o; Hit <= h; end process; end ICache_arch1; -- vi: set ts=4 sw=4 : please --J/dobhs11T7y2rNN-- From Michael Riepe Sun Oct 1 14:17:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04943 for ; Mon, 2 Oct 2000 02:10:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:39 +0200 (MEST) Received: (qmail 11211 invoked by uid 0); 1 Oct 2000 21:47:21 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 1 Oct 2000 21:47:21 -0000 X-eGroups-Return: sentto-1101623-933-970436838-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 01 Oct 2000 21:47:20 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 21:47:18 -0000 Received: (qmail 21106 invoked from network); 1 Oct 2000 21:47:18 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 1 Oct 2000 21:47:18 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.119) by mta3 with SMTP; 1 Oct 2000 21:47:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00488; Sun, 1 Oct 2000 14:17:25 +0200 Message-ID: <20001001141725.17822@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D67A1D.B3084643@starpower.net> <39D68BFB.FCEBA74@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D68BFB.FCEBA74@f-cpu.org>; from Yann Guidon on Sun, Oct 01, 2000 at 01:57:31AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 14:17:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Checking up on the project. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 16457c7864f7412a806779f9ced5a407 Status: R X-Status: N On Sun, Oct 01, 2000 at 01:57:31AM +0100, Yann Guidon wrote:

> I have finished my master thesis so i'm back to active status :-P
> i have finally found a not-too-proprietary VHDL compiler and simulator
> so i started to learn and write HTML code. [...]
                                  ^^^^

I hope not!

[...]
> well, not all code is generated by compilers. what if a Linux user
> does :
> $ cat > a.out
> azerzertzqmljkhqsdjkhqlkjhf
> ^D
> $ chmod 700 a.out
> $ ./a.out
>
> huh ?

You missed the point.  In this case, `a.out' is a shell script,
not a binary.  But there is at least one program that executes random
binary code (and tries to crash the OS that way, that's why it's called
`crashme'; of course crashme must not -- never!!! -- be able to crash
(or fry, or whatever) the CPU).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Jecel Assumpcao Jr Mon Oct 2 00:55:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04946 for ; Mon, 2 Oct 2000 02:10:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:39 +0200 (MEST) Received: (qmail 10204 invoked by uid 0); 1 Oct 2000 21:58:46 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 1 Oct 2000 21:58:46 -0000 X-eGroups-Return: sentto-1101623-934-970437521-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 01 Oct 2000 21:58:42 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 21:58:41 -0000 Received: (qmail 15921 invoked from network); 1 Oct 2000 21:58:40 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 1 Oct 2000 21:58:40 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 1 Oct 2000 21:58:33 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA23214 for ; Sun, 1 Oct 2000 19:07:59 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <200010012036.QAA06573@belegost.mit.edu> In-Reply-To: <200010012036.QAA06573@belegost.mit.edu> Message-Id: <00100120033304.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 19:55:50 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d79bebf8ecaac9166e1a8c03f1d47bf3 Status: R X-Status: N On Sun, 01 Oct 2000, Graham wrote:
> Jeff Davies wrote:
> > So,,, what about a GPL FPGA design? Is this a crazy idea. If not, it could
> > be done in Electric, and then used to bootstrap the free cores
> > industry?  I think FPGA structure is simple internally (in the main)....
> > any thoughts?
> >
> Its one of my pet ideas too, but nobody much seems to think its realistic
> (compared, say, with an Intel-beating cpu ;-).

You have to actually build the chip and software tools - you can't show
a prototype in FPGA, right?

> The main objections
> seem to be:
> how are you going to get the volume you'd need made?
> what about the patents?
> Manufacture is the same problem whether its a cpu or an fpga; I don't
> have any answers, apart from try it and see...

Actually, it is much easier to get a working fpga design than a cpu is
it is so regular. Much like a memory chip.

> Patents are more of a problem. Just because they are relatively simple
> means you can't make a Xilinx-like fpga without treading on their patents.

And they have bought several smaller companies to have their patents as
well.

> It would have to be an FPGA with some original approach; I think its
> more of a research type problem than most open-source projects are
> (which usually re-implement the wheel :-) But there are some nice things
> an open-source fpga could do that current fpgas don't (eg transparent
> access to configuration bits and external read/write to internal locations).

Exactly. Look at how many people were interested in the XC6200 series
and it was killed just the same since Xilinx's largest customers didn't
want anything like that. Such a design would have to come from a
separate company.

> I think a project to do this would be excellent, but unless there are
> some people around with experience in this and some definite ideas its
> likely to turn into another of those 'lets argue about basic principles
> for a couple of years and not design anything' style projects :-(

After reading Jeff's post I thought a few minutes about it and came up
with a very workable design. I made a drawing to see if there were any
problems (there weren't) but didn't save it. If anyone is interested, I
could write a description. But the f-cpu list isn't the best place for
this.

-- Jecel
 From graham@belegost.mit.edu Mon Oct 2 00:13:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04952 for ; Mon, 2 Oct 2000 02:10:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:41 +0200 (MEST) Received: (qmail 9044 invoked by uid 0); 1 Oct 2000 22:13:14 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 1 Oct 2000 22:13:14 -0000 X-eGroups-Return: sentto-1101623-935-970438391-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 01 Oct 2000 22:13:12 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 22:13:11 -0000 Received: (qmail 13453 invoked from network); 1 Oct 2000 22:13:10 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 1 Oct 2000 22:13:10 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 1 Oct 2000 22:13:10 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA07096 for f-cpu@egroups.com; Sun, 1 Oct 2000 18:13:10 -0400 Message-Id: <200010012213.SAA07096@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <00100120033304.00384@gandalf> from "Jecel Assumpcao Jr" at Oct 01, 2000 07:55:50 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 1 Oct 2000 18:13:10 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af40d7d49f8f4158a25bc5f9b5ae475d Status: R X-Status: N Jecel wrote:
> You have to actually build the chip and software tools - you can't show
> a prototype in FPGA, right?
Not necessarily. Although there have been virtual FPGAs designed before now (and
I believe some are still being worked on) they suffer from the boot-strap
problem (ie what tools are used to implement the virtual FPGA itself) - but
no more so than a CPU. So why not prototypes in FPGA? FPGAs are well
suited for implementing on FPGAs because of their regularity.
But in the long run, yes, it's pointless having existing FPGAs as the
final target.
>
> > Patents are more of a problem. Just because they are relatively simple
> > means you can't make a Xilinx-like fpga without treading on their patents.
>
> And they have bought several smaller companies to have their patents as
> well.
Do you think that's the only reason they bought Algotronix? And I thought I
was cynical..
>
> Exactly. Look at how many people were interested in the XC6200 series
> and it was killed just the same since Xilinx's largest customers didn't
> want anything like that. Such a design would have to come from a
> separate company.
>
> After reading Jeff's post I thought a few minutes about it and came up
> with a very workable design. I made a drawing to see if there were any
> problems (there weren't) but didn't save it. If anyone is interested, I
> could write a description. But the f-cpu list isn't the best place for
> this.
Agreed, its a distraction for this list.
If you think there would be interest, I'll happily get a mailing list
organised. But it needs at least one person to be pushing it, and I
don't have the knowledge/skills...
If there isn't enough interest for a list, I'd like to see the description
anyway (and maybe give it a web-page as a suggestion for the future?)
It will be interesting to see how you bypassed the patent problems ;-)

Graham
eGroups Sponsor
From Yann Guidon Mon Oct 2 01:40:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04955 for ; Mon, 2 Oct 2000 02:10:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:42 +0200 (MEST) Received: (qmail 26748 invoked by uid 0); 1 Oct 2000 22:37:06 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 1 Oct 2000 22:37:06 -0000 X-eGroups-Return: sentto-1101623-936-970439804-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mv.egroups.com with NNFMP; 01 Oct 2000 22:36:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 22:36:43 -0000 Received: (qmail 32585 invoked from network); 1 Oct 2000 22:36:43 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 1 Oct 2000 22:36:43 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 1 Oct 2000 22:36:43 -0000 Received: from f-cpu.org (nas3-31.ras.club-internet.fr [195.36.203.31]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08583 for ; Mon, 2 Oct 2000 00:36:40 +0200 (MET DST) Message-ID: <39D7CB86.4A0B5926@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 00:40:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aa3b865f0724d5d5e05806304e039141 Status: R X-Status: N hi,

Colin Marquardt wrote:
> Hi,
>
> * Yann Guidon <whygee@f-cpu.org> writes:
> > Colin will remark that i use only bit's and bit_vector's
> Hey, how did you know that? :-)
'instinct ? :-)
> Really... what is making you stay away
> from std_logic_vector, or, better in my opinion, std_ulogic_vector?
faster, simpler and less libraries. similation time for the whole system
might become a limiting factor when all the units will be put together,
and it's only a behavioural code.

> (std_ulogic_vector for the real design, since it doesn't resolve
> clashes between multiple drivers automatically, you have to find the
> X'es in simulation and track them down, which is almost always some
> unwanted behaviour which otherwise would be hidden until
> later. Unfortunately, the Reuse Methdology Manual suggests
> otherwise...)
damn...

> > and the text i/o should not be bound by synopsys, i guess.
> textio is okay. it is really just the three _arith, _unsigned and _signed.
ok, and thank you for the extract in the other mail : it's not very clear,
but i can see where the problem is.

> > OTOH, std_logic and the necessary libraries were useful to
> > detect the uninitialised variables.
> See? :-)
at least, next time, i'll remember this story ;-)

> > As pointed before, work should be started on the execution units.
> > if someone wants to make the pipelined adder and multiplier
> > or the shifter, the inc/findfirst, the ROP2 etc... please start now.
> So much code, so little time... :-(
yup. and now, Michael contributed with his own code.

what if we made a unique testbench for all the versions ?
this would spare some time to the group :-)

ok, let's code now.
damn, i'm happy that this coding moment has finally come :-))))

> Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Oct 2 01:40:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04958 for ; Mon, 2 Oct 2000 02:10:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:43 +0200 (MEST) Received: (qmail 18841 invoked by uid 0); 1 Oct 2000 22:37:24 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 1 Oct 2000 22:37:24 -0000 X-eGroups-Return: sentto-1101623-937-970439806-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 01 Oct 2000 22:37:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 22:36:46 -0000 Received: (qmail 19650 invoked from network); 1 Oct 2000 22:36:46 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 1 Oct 2000 22:36:46 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 1 Oct 2000 22:36:46 -0000 Received: from f-cpu.org (nas3-31.ras.club-internet.fr [195.36.203.31]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08593 for ; Mon, 2 Oct 2000 00:36:43 +0200 (MET DST) Message-ID: <39D7CB87.7A4E5619@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 00:40:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b9d9f703e146caf0d47e4d002c2d5ecd Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Oct 01, 2000 at 02:47:30AM +0100, Yann Guidon wrote:
> > so i completed the missing lines in the LRU update code.
> > this is coded as if i was using C, so don't care about the
> > capability of synthesis.
>
> While you were busy, I finished my version.
yeah !

>  It's a little different.
i see, i'll have to analyse it carefully.

> First of all, it does not update the LRU when a cache line is filled;
although it's very easy to do : just rotate all the LRU (if you use the
queue/FIFO approach).

> doing so would be Not A Good Thing (tm), IMHO.
why ? am i missing something ?

>  Instead, the LRU is always
> updated immediately following a read operation (at the next clock cycle),
> cache hit or not.
that's curious. is it speculative or something like that ? ...

> One of the other goodies is that you can invalidate an address range :)
> It's limited to power-of-two size and alignment values, but that made
> the change pretty simple, and flushing arbitrary ranges of memory is
> a rarely needed operation anyway.

i have thought about something like that, but it's only an accessorily feature,
we need a testbench to see if it works.

I also remark that you have separated all 3 functions (read, write, invalidate)
and it takes 3 buses (or so i have seen), while i reuse the read address bus
for the invalidation, because it uses more or less the same functions (compare the
addresses). i guess that invalidation occurs not very often so the overhead
for the multiplexing is not critical.

btw, have you tested this code (and how) ?
do i start to write a testbench ?

thanks again,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Mon Oct 2 01:52:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04964 for ; Mon, 2 Oct 2000 02:10:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 02:10:45 +0200 (MEST) Received: (qmail 5370 invoked by uid 0); 1 Oct 2000 23:52:40 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 1 Oct 2000 23:52:40 -0000 X-eGroups-Return: sentto-1101623-938-970444356-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ef.egroups.com with NNFMP; 01 Oct 2000 23:52:39 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 1 Oct 2000 23:52:35 -0000 Received: (qmail 21538 invoked from network); 1 Oct 2000 23:52:35 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 1 Oct 2000 23:52:35 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.119) by mta1 with SMTP; 1 Oct 2000 23:52:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01156; Mon, 2 Oct 2000 01:52:30 +0200 Message-ID: <20001002015229.31639@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D7CB87.7A4E5619@f-cpu.org>; from Yann Guidon on Mon, Oct 02, 2000 at 12:40:55AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 01:52:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9766d36b1dd0c3c5b01b1debf99cc62a Status: R X-Status: N On Mon, Oct 02, 2000 at 12:40:55AM +0100, Yann Guidon wrote:

> > First of all, it does not update the LRU when a cache line is filled;
> although it's very easy to do : just rotate all the LRU (if you use the
> queue/FIFO approach).

Yes, I do.

> > doing so would be Not A Good Thing (tm), IMHO.
> why ? am i missing something ?
>
> >  Instead, the LRU is always
> > updated immediately following a read operation (at the next clock cycle),
> > cache hit or not.
> that's curious. is it speculative or something like that ? ...

Not at all.  You can change the LRU unit immediately or later, when
the line is valid and the read completes.  You just have to save the
line number for the fill operation.  In my `global plan', the cache
sends it to the memory controller, and the m.c. sends it back when it
fills the cache line.  This way, the cache and memory controller are
less tightly coupled, and the read and write ports are independent of
each other because the write port doesn't need the LRU unit any longer.
Another feature is that there is only one interface to the LRU unit,
and all LRU updates work the same way, no matter whether the data is in
the cache or not.

> I also remark that you have separated all 3 functions (read, write, invalidate)
> and it takes 3 buses (or so i have seen), while i reuse the read address bus
> for the invalidation, because it uses more or less the same functions (compare the
> addresses). i guess that invalidation occurs not very often so the overhead
> for the multiplexing is not critical.

The Read and Inv operations share the `Addr' input lines and parts of
the address comparators.  If we drop the `range invalidation' feature,
Inv is the only additional input line (it may be wise to add another
line that invalidates the whole cache in that case -- I had that in an
earlier version which is still in my CVS, fortunately).

> btw, have you tested this code (and how) ?

It's syntacitically correct (at least Simili doesn't object).
I didn't have enough time to write a testbench.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Jeff Davies/CDPTEST Mon Oct 2 02:51:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05951 for ; Mon, 2 Oct 2000 12:33:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:22 +0200 (MEST) Received: (qmail 13558 invoked by uid 0); 2 Oct 2000 00:55:21 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 2 Oct 2000 00:55:21 -0000 X-eGroups-Return: sentto-1101623-939-970448084-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 02 Oct 2000 00:55:04 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 00:54:44 -0000 Received: (qmail 20578 invoked from network); 2 Oct 2000 00:54:44 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 2 Oct 2000 00:54:44 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta2 with SMTP; 2 Oct 2000 00:54:43 -0000 Received: from modem-6.alabama.dialup.pol.co.uk ([62.137.52.6] helo=sargon.chrystal.gbr.xerox.com) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ftsP-00040l-00 for f-cpu@egroups.com; Mon, 02 Oct 2000 01:54:42 +0100 To: f-cpu@egroups.com Message-ID: <57E8F7A67715B2538025696C00045EDE.0000000000000000@chrystal.gbr.xerox.com> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 01:51:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 59aabbd8a03ff79e47d3d84f914b1e49 Status: R X-Status: N

On Sun, 01 Oct 2000, Graham wrote:
> Jeff Davies wrote:
> > So,,, what about a GPL FPGA design? Is this a crazy idea. If not, it
could
> > be done in Electric, and then used to bootstrap the free cores
> > industry?  I think FPGA structure is simple internally (in the
main)....
> > any thoughts?
> >
> Its one of my pet ideas too, but nobody much seems to think its realistic
> (compared, say, with an Intel-beating cpu ;-).

You have to actually build the chip and software tools - you can't show
a prototype in FPGA, right?

** What about maybe using Alliance (it's GPL isn't it??), perhaps modifying
it to compile
** VHDL for this FPGA?

> I think a project to do this would be excellent, but unless there are
> some people around with experience in this and some definite ideas its
> likely to turn into another of those 'lets argue about basic principles
> for a couple of years and not design anything' style projects :-(

After reading Jeff's post I thought a few minutes about it and came up
with a very workable design. I made a drawing to see if there were any
problems (there weren't) but didn't save it. If anyone is interested, I
could write a description. But the f-cpu list isn't the best place for
this.

-- Jecel

** Can you post the design on this list a a graphic and text.
This is because (I beleive) this list is archived, and could be used for
prior art authentication.
Thereafter, yes, I think another list could be started, perhaps a project
on opencores??
The more I think about it, the more a free design FPGA sounds like a good
idea.
(Probably easier to sell and more reusable than say, getting a bunch of
CPUs made into ASIC).
Could also really kick off the free hardware design market in a big way.

Jeff Davies


 From Jeff Davies/CDPTEST Mon Oct 2 02:55:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05954 for ; Mon, 2 Oct 2000 12:33:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:23 +0200 (MEST) Received: (qmail 26335 invoked by uid 0); 2 Oct 2000 00:58:42 -0000 Received: from mq.egroups.com (208.50.144.79) by mx19.rz2.gmx.net with SMTP; 2 Oct 2000 00:58:42 -0000 X-eGroups-Return: sentto-1101623-940-970448314-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mq.egroups.com with NNFMP; 02 Oct 2000 00:58:40 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 00:58:33 -0000 Received: (qmail 15213 invoked from network); 2 Oct 2000 00:58:33 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 2 Oct 2000 00:58:33 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta2 with SMTP; 2 Oct 2000 00:58:33 -0000 Received: from modem-6.alabama.dialup.pol.co.uk ([62.137.52.6] helo=sargon.chrystal.gbr.xerox.com) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ftw7-0004A2-00 for f-cpu@egroups.com; Mon, 02 Oct 2000 01:58:31 +0100 To: f-cpu@egroups.com Message-ID: From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 01:55:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1f33d4ffed1e04fa1fb9de4eb3598514 Status: R X-Status: N Jecel, almost forgot, please don't forget to put something in like:

#FreeFPGA GNU Public Licence FreeFPGA design/implementation
#Copyright (C) 2000 Jecel Assumpcao Jr.
#This design/implementation is a free hardware design
#(and all intellectual property therein); you can redistribute it and/or
#modify it under the terms of the GNU General Public License
#as published by the Free Software Foundation; either version 2
#of the License, or (at your option) any later version.
#This design is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA&nbsp;
02111-1307,
#USA.
#Jecel Assumpcao, *** Your address in here ***
#** your phone number in here **   **email here**
#** homepage here **

OK the mods i have made to the GPL standard text might not be perfect, but
methinks better than nothing.

Jeff Davies
 From Colin Marquardt Mon Oct 2 00:15:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05963 for ; Mon, 2 Oct 2000 12:33:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:26 +0200 (MEST) Received: (qmail 30430 invoked by uid 0); 2 Oct 2000 01:14:37 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 2 Oct 2000 01:14:37 -0000 X-eGroups-Return: sentto-1101623-941-970449273-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jk.egroups.com with NNFMP; 02 Oct 2000 01:14:31 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 01:14:33 -0000 Received: (qmail 15817 invoked from network); 2 Oct 2000 01:14:32 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 2 Oct 2000 01:14:32 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 2 Oct 2000 01:14:32 -0000 Received: from morphin.marquardt-home.de (e229.nas22.sonic.net [209.204.142.229]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id DAA00390 for ; Mon, 2 Oct 2000 03:14:29 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13frOD-0003wz-00 for ; Sun, 01 Oct 2000 15:15:21 -0700 To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> X-Now-Playing: M.O.D.'s Gross Misconduct - P.B.M. In-Reply-To: Michael Riepe's message of "Sun, 1 Oct 2000 23:30:14 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 41 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 15:15:21 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c40d5f69b7484b5f55ec458c2836b5a5 Status: R X-Status: N Hi,

* Michael Riepe <michael@stud.uni-hannover.de> writes:

| -- $Id: icache.vhdl,v 1.4 2000/10/01 20:52:02 michael Exp $
[...]
| use IEEE.std_logic_arith.all;      -- gotta get rid of that later

Hehe! :-)

Hmmm... let's see... may I suggest that we use abstract data types?
That means for instance making the reset a boolean type. No need to
care if it is an active-low or -high pin later on, internally it is
simply "true" or "not true".

Same for things like:
| if (Read = '1') then

If Read was a boolean, there is no need for comparing with a
fixed value. And of course, any signal should be positive logic
(internally).

| NADDRS : integer := 27; -- number of address bits (32 - 5) => 4 GByte

I would rather use natural instead of integer here. natural is
restricted to positive values by default, which an address is
too. This will also help in situations where conversion is required
(no need for the "unsigned" specifier).

|      elsif Clk'event and (Clk = '1') then

I think "rising_edge(Clk)" is now supported everywhere, even
Synopsys knows it.


Feel free to disregard all or some of my comments, as I did not (yet?)
provide any code myself. It is just that the above recommendations come
>from years of "real-life" experience (not mine, fortunately :-).

Cheers,
  Colin
 From Yann Guidon Mon Oct 2 05:00:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05966 for ; Mon, 2 Oct 2000 12:33:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:27 +0200 (MEST) Received: (qmail 7794 invoked by uid 0); 2 Oct 2000 01:56:18 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 2 Oct 2000 01:56:18 -0000 X-eGroups-Return: sentto-1101623-942-970451767-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 02 Oct 2000 01:56:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 01:56:06 -0000 Received: (qmail 31521 invoked from network); 2 Oct 2000 01:56:06 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 2 Oct 2000 01:56:06 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 2 Oct 2000 01:56:06 -0000 Received: from f-cpu.org (nas2-232.ras.club-internet.fr [195.36.192.232]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22727 for ; Mon, 2 Oct 2000 03:56:02 +0200 (MET DST) Message-ID: <39D7FA46.90188C09@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 04:00:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 008373ae040bb1410027d5eb3a886d12 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Mon, Oct 02, 2000 at 12:40:55AM +0100, Yann Guidon wrote:
> > > doing so would be Not A Good Thing (tm), IMHO.
> > why ? am i missing something ?
> >
> > >  Instead, the LRU is always
> > > updated immediately following a read operation (at the next clock cycle),
> > > cache hit or not.
> > that's curious. is it speculative or something like that ? ...
>
> Not at all.  You can change the LRU unit immediately or later, when
> the line is valid and the read completes.  You just have to save the
> line number for the fill operation.  In my `global plan', the cache
> sends it to the memory controller, and the m.c. sends it back when it
> fills the cache line.  This way, the cache and memory controller are
> less tightly coupled, and the read and write ports are independent of
> each other because the write port doesn't need the LRU unit any longer.
> Another feature is that there is only one interface to the LRU unit,
> and all LRU updates work the same way, no matter whether the data is in
> the cache or not.

it is not yet clear in my head (i gotta sleep, it's 4am)
but the organisation is slightly different from what i had
in mind : the cache miss/fill sequence would be done by another
separate unit, we would only need the Din/Dou/AddrRead/AddrWrite/
WriteEn/ReadEn/Inv/Reset interface. The exact line where the data
are stored is completely internal, whereas i have seen that you have
made them available to the outside.
I better rereread your code.

> > I also remark that you have separated all 3 functions (read, write, invalidate)
> > and it takes 3 buses (or so i have seen), while i reuse the read address bus
> > for the invalidation, because it uses more or less the same functions (compare the
> > addresses). i guess that invalidation occurs not very often so the overhead
> > for the multiplexing is not critical.
>
> The Read and Inv operations share the `Addr' input lines and parts of
> the address comparators.  If we drop the `range invalidation' feature,
> Inv is the only additional input line
yup

> (it may be wise to add another
> line that invalidates the whole cache in that case -- I had that in an
> earlier version which is still in my CVS, fortunately).
total invalidate should be done by the reset line, no ? :-)

> > btw, have you tested this code (and how) ?
> It's syntacitically correct (at least Simili doesn't object).
> I didn't have enough time to write a testbench.

ok so i'll start to write the testbench and then fill it with the
behavioural code.

well, i'll start after a nap. Or two.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Oct 2 05:08:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05969 for ; Mon, 2 Oct 2000 12:33:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:28 +0200 (MEST) Received: (qmail 2293 invoked by uid 0); 2 Oct 2000 02:04:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 2 Oct 2000 02:04:11 -0000 X-eGroups-Return: sentto-1101623-943-970452248-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 02 Oct 2000 02:04:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 02:04:07 -0000 Received: (qmail 24116 invoked from network); 2 Oct 2000 02:04:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 2 Oct 2000 02:04:07 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 2 Oct 2000 02:04:06 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA18877 for ; Mon, 2 Oct 2000 04:04:04 +0200 (MET DST) Message-ID: <39D7FC28.D43BAA45@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 04:08:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d7cf712533af7cd939301dc48b22593 Status: R X-Status: N hi again,

Colin Marquardt wrote:
> Hi,
<snip>
>
> Feel free to disregard all or some of my comments, as I did not (yet?)
> provide any code myself. It is just that the above recommendations come
> from years of "real-life" experience (not mine, fortunately :-).

that's what i call useful recommendation :-) i'll take these remarks
into account for the coming rerepost of the external definition of the Icache.

what do you recommend for the data buses ? an array(0 to 7) of natural ? :-)
or will bit_vector do the trick ?

Anyway, now that i think about it, the range allowed by natural might
not be enough for later f-cpu chips, because the addressable range might
reach or exceed 64 bits. Any advice on this ?

read you soon, tomorrow
> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Mon Oct 2 04:26:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05972 for ; Mon, 2 Oct 2000 12:33:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:29 +0200 (MEST) Received: (qmail 4469 invoked by uid 0); 2 Oct 2000 02:23:15 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 2 Oct 2000 02:23:15 -0000 X-eGroups-Return: sentto-1101623-944-970453388-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 02 Oct 2000 02:23:10 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 02:23:07 -0000 Received: (qmail 591 invoked from network); 2 Oct 2000 02:23:07 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 2 Oct 2000 02:23:07 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 2 Oct 2000 02:23:07 -0000 Received: from morphin.marquardt-home.de (e229.nas22.sonic.net [209.204.142.229]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id EAA26458 for ; Mon, 2 Oct 2000 04:23:04 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13fvJJ-0004CQ-00 for ; Sun, 01 Oct 2000 19:26:33 -0700 To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7FC28.D43BAA45@f-cpu.org> X-Now-Playing: nothing, sorry. In-Reply-To: Yann Guidon's message of "Mon, 02 Oct 2000 04:08:24 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 37 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 19:26:32 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: faa22bb83d09372de39c4d3b5adb1759 Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

> what do you recommend for the data buses ? an array(0 to 7) of natural ? :-)
> or will bit_vector do the trick ?

No, no no! :-)

It was just that the "to 7" part was defined via a generic, and the
generic accepted an integer. An integer in VHDL can be negative
though, so it makes sense to define it as natural which is ranging
>from "0 to <whatever>".

And of course, all such things should be described by a "downto"
range, except string which go from "1 to <something>"

If I had written the code, I would have used something like

MyAddress : in std_ulogic_vector(c_MyAddressMSB-1 downto 0);

If c_MyAddressMSB was a constant or a generic, this would be of the
type natural, not integer.

naturals are "closely related" to integers, so while many
simulators/synthesis tools allow integer generics only, it should
work with natural (please anybody correct me if this is wrong).

> Anyway, now that i think about it, the range allowed by natural might
> not be enough for later f-cpu chips, because the addressable range might
> reach or exceed 64 bits. Any advice on this ?

I think with natural the LRM says that your address MSB can be 2**32-1
(without looking at any docs), so that should be enough. :-)

Cheers,
  Colin
 From Colin Marquardt Mon Oct 2 04:39:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05975 for ; Mon, 2 Oct 2000 12:33:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:30 +0200 (MEST) Received: (qmail 23902 invoked by uid 0); 2 Oct 2000 02:36:00 -0000 Received: from c9.egroups.com (208.50.99.230) by mx12.rz2.gmx.net with SMTP; 2 Oct 2000 02:36:00 -0000 X-eGroups-Return: sentto-1101623-945-970454152-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 02 Oct 2000 02:35:57 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 02:35:52 -0000 Received: (qmail 31536 invoked from network); 2 Oct 2000 02:35:52 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 2 Oct 2000 02:35:52 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 2 Oct 2000 02:35:51 -0000 Received: from morphin.marquardt-home.de (e229.nas22.sonic.net [209.204.142.229]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id EAA29889 for ; Mon, 2 Oct 2000 04:35:48 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13fvVh-0004Cu-00 for ; Sun, 01 Oct 2000 19:39:21 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> X-Now-Playing: nothing, sorry. In-Reply-To: Yann Guidon's message of "Mon, 02 Oct 2000 00:40:54 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 51 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 2000 19:39:20 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c568cd21d44b2f75c2d72fcffae94b2e Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

>> Really... what is making you stay away
>> from std_logic_vector, or, better in my opinion, std_ulogic_vector?
> faster, simpler and less libraries. similation time for the whole system
> might become a limiting factor when all the units will be put together,
> and it's only a behavioural code.

I would say to never trade in readability, maintainability and
"see-logical-errors-quickly"-ability for simulation time. It just
doesn't pay off. In terms of simulation time, Verilog would have
been a better choice, but I hate that it is so easy to shoot
yourself in the foot.

A colleague has written his diploma thesis about the speed of
different coding styles in some tools. I will ask him if this is
publicly accessible. (It will be in German though... :-( )

>> (std_ulogic_vector for the real design, since it doesn't resolve
>> clashes between multiple drivers automatically, you have to find the
>> X'es in simulation and track them down, which is almost always some
>> unwanted behaviour which otherwise would be hidden until
>> later. Unfortunately, the Reuse Methdology Manual suggests
>> otherwise...)
> damn...

Oh, but with that I mean that it suggests std_logic in favor of
std_*u*logic. They don't even consider bit as a useful type :-)
Can you find a copy of it in your library? Would be a good read
(it is by Keating/Bricaud, published by Kluwer IIRC).

>> > and the text i/o should not be bound by synopsys, i guess.
>> textio is okay. it is really just the three _arith, _unsigned and _signed.
> ok, and thank you for the extract in the other mail : it's not very clear,
> but i can see where the problem is.

Just for the fact that they dared to call them "ieee" these
libraries should be killed! :-)

> what if we made a unique testbench for all the versions ?
> this would spare some time to the group :-)

I guess it really makes sense to have a world-accessible CVS
repository. sourceforge.net was already mentioned. (And btw, I hate
this eGroups banners. Can we please move the list to sourceforge
too?)

Cheers,
  Colin
eGroups Sponsor
From Nicolas Matringe Mon Oct 2 10:09:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA05993 for ; Mon, 2 Oct 2000 12:33:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 12:33:34 +0200 (MEST) Received: (qmail 15524 invoked by uid 0); 2 Oct 2000 08:08:18 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 2 Oct 2000 08:08:18 -0000 X-eGroups-Return: sentto-1101623-946-970474092-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 02 Oct 2000 08:08:15 -0000 X-Sender: nicolas.matringe@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 08:08:11 -0000 Received: (qmail 20721 invoked from network); 2 Oct 2000 08:08:11 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 2 Oct 2000 08:08:11 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 2 Oct 2000 08:08:11 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA02213 for ; Mon, 2 Oct 2000 08:08:09 GMT X-To: Message-ID: <39D842A1.A74D581@ipricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D610E2.8FC33FDB@ifrance.com> <39D62D1B.1AD5B205@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 10:09:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1796e27573c5a807a64d132346f6fe60 Status: R X-Status: N Although I'm not a regular poster, I'm still here reading.
Don't forget I've been a VHDL user for about 3 years so I know a few
things about the language. Don't hesitate to ask... :o)

As Colin said, DON'T use the ieee.std_arith packages, use only
ieee.numeric_std.

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FRANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor
From Yann Guidon Mon Oct 2 16:58:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07047 for ; Mon, 2 Oct 2000 23:34:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:13 +0200 (MEST) Received: (qmail 20267 invoked by uid 0); 2 Oct 2000 13:54:24 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 2 Oct 2000 13:54:24 -0000 X-eGroups-Return: sentto-1101623-947-970494849-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 02 Oct 2000 13:54:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 13:54:08 -0000 Received: (qmail 4618 invoked from network); 2 Oct 2000 13:54:08 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 2 Oct 2000 13:54:08 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 2 Oct 2000 13:54:08 -0000 Received: from f-cpu.org (nas4-83.ras.club-internet.fr [195.36.203.83]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA19367 for ; Mon, 2 Oct 2000 15:54:05 +0200 (MET DST) Message-ID: <39D8A294.F8AC7B8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D610E2.8FC33FDB@ifrance.com> <39D62D1B.1AD5B205@f-cpu.org> <39D842A1.A74D581@ipricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 15:58:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d95ca9b10892397638ac6a22fa05c2cc Status: R X-Status: N hi !

Nicolas Matringe wrote:
> Although I'm not a regular poster, I'm still here reading.
you're the one who designed the logo, so you're at home here ;-)

> Don't forget I've been a VHDL user for about 3 years so I know a few > things about the language. Don't hesitate to ask... :o)
as you can read, i've asked but you didn't reply. And i know that you
have to work. but of course, if you can help with VHDL, your comments
are welcome.

> As Colin said, DON'T use the ieee.std_arith packages, use only
> ieee.numeric_std.
now, i think that it's clear :-)
i'll cleanup all the files (well, there is not many of them so it will
be quick :-D)

> Nicolas MATRINGE         =   IPricot European Headquarters
tiens, ils ont chang=E9 de nom ?
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Nicolas Matringe Mon Oct 2 16:06:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07050 for ; Mon, 2 Oct 2000 23:34:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:14 +0200 (MEST) Received: (qmail 22783 invoked by uid 0); 2 Oct 2000 14:05:38 -0000 Received: from hp.egroups.com (208.50.99.201) by mx19.rz2.gmx.net with SMTP; 2 Oct 2000 14:05:38 -0000 X-eGroups-Return: sentto-1101623-948-970495531-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 02 Oct 2000 14:05:34 -0000 X-Sender: nicolas.matringe@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 14:05:30 -0000 Received: (qmail 6976 invoked from network); 2 Oct 2000 14:05:29 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 2 Oct 2000 14:05:29 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 2 Oct 2000 14:05:28 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id OAA10470 for ; Mon, 2 Oct 2000 14:05:26 GMT X-To: Message-ID: <39D8965D.C3775FDA@ipricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D610E2.8FC33FDB@ifrance.com> <39D62D1B.1AD5B205@f-cpu.org> <39D842A1.A74D581@ipricot.com> <39D8A294.F8AC7B8@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 16:06:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 927f23ec6596b8553c5149026ed29555 Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas Matringe wrote:
> > Although I'm not a regular poster, I'm still here reading.
> you're the one who designed the logo, so you're at home here ;-)

Thanks :oD


> > Don't forget I've been a VHDL user for about 3 years so I know a = few
> > things about the language. Don't hesitate to ask... :o)
> as you can read, i've asked but you didn't reply. And i know that you<= BR> > have to work. but of course, if you can help with VHDL, your comments<= BR> > are welcome.

The problem is that I read my mail only at work. I read your question
today in the morning, when everyone had already replied :o)


> > Nicolas MATRINGE        &= nbsp;  IPricot European Headquarters
> tiens, ils ont chang=E9 de nom ?

"DotCom" can not be registered in North America.
A part =E7a, rien n'a chang=E9, personne ne nous a rachet=E9 :o)

--
Nicolas MATRINGE          = ; IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
 From Yann Guidon Mon Oct 2 18:07:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07059 for ; Mon, 2 Oct 2000 23:34:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:16 +0200 (MEST) Received: (qmail 1304 invoked by uid 0); 2 Oct 2000 15:03:27 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 2 Oct 2000 15:03:27 -0000 X-eGroups-Return: sentto-1101623-949-970498999-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mq.egroups.com with NNFMP; 02 Oct 2000 15:03:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 15:03:11 -0000 Received: (qmail 11632 invoked from network); 2 Oct 2000 15:03:11 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 2 Oct 2000 15:03:11 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 2 Oct 2000 15:03:11 -0000 Received: from f-cpu.org (nas3-100.aub.club-internet.fr [195.36.145.100]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA19660 for ; Mon, 2 Oct 2000 17:03:07 +0200 (MET DST) Message-ID: <39D8B2BC.1222D68F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 17:07:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b809edd457ada81f074f53e3c4b1eb96 Status: R X-Status: N hi again,

Colin Marquardt wrote:
> Hi,
> * Yann Guidon <whygee@f-cpu.org> writes:
> > what do you recommend for the data buses ? an array(0 to 7) of natural ? :-)
> > or will bit_vector do the trick ?
> No, no no! :-)
;-)

> It was just that the "to 7" part was defined via a generic, and the
> generic accepted an integer. An integer in VHDL can be negative
> though, so it makes sense to define it as natural which is ranging
> from "0 to <whatever>".
i have maybe missed a point but i guess that
array(0 to DBwidth-1) will work, if DBwidth is not defined as generic.
or ?
sorry, i just woke up :-)

> And of course, all such things should be described by a "downto"
> range, except string which go from "1 to <something>"
yup...

> If I had written the code, I would have used something like
>
> MyAddress : in std_ulogic_vector(c_MyAddressMSB-1 downto 0);
>
> If c_MyAddressMSB was a constant or a generic, this would be of the
> type natural, not integer.

so i'll just cut-n-paste, it will spare some bandwidth :-)

> naturals are "closely related" to integers, so while many
> simulators/synthesis tools allow integer generics only, it should
> work with natural (please anybody correct me if this is wrong).
>
> > Anyway, now that i think about it, the range allowed by natural might
> > not be enough for later f-cpu chips, because the addressable range might
> > reach or exceed 64 bits. Any advice on this ?
>
> I think with natural the LRM says that your address MSB can be 2**32-1
> (without looking at any docs), so that should be enough. :-)

hmmmm.... 32+5 is 37, that makes 128BG which is enough before a total rewrite.
let's go.

> Cheers,
>   Colin


then :

Colin Marquardt wrote:
> Hi,
<snip>
> I would say to never trade in readability, maintainability and
> "see-logical-errors-quickly"-ability for simulation time. It just
> doesn't pay off. In terms of simulation time, Verilog would have
> been a better choice, but I hate that it is so easy to shoot
> yourself in the foot.
ok, you made your point.

> A colleague has written his diploma thesis about the speed of
> different coding styles in some tools. I will ask him if this is
> publicly accessible. (It will be in German though... :-( )
well, german is a start. I'm not sure that i'll understand
correctly but can you post the URL when you find it ?
thanks :-)

> Oh, but with that I mean that it suggests std_logic in favor of
> std_*u*logic. They don't even consider bit as a useful type :-)
huh ? so when they have a huge memory array, like 256Mbits, what
time does it take to simulate this ? :-)

> Can you find a copy of it in your library? Would be a good read
> (it is by Keating/Bricaud, published by Kluwer IIRC).
i think that i'll have to wait a bit, i'm mostly broke. I still have
to finish the books i've already bought. Anywa, a good reference manual
might be useful in the near future. I'm seeking a job and i might
have enough money to buy good books in a month or two.

> >> > and the text i/o should not be bound by synopsys, i guess.
> >> textio is okay. it is really just the three _arith, _unsigned and _signed.
> > ok, and thank you for the extract in the other mail : it's not very clear,
> > but i can see where the problem is.
> Just for the fact that they dared to call them "ieee" these
> libraries should be killed! :-)
:-)

oh, just a proposal for the future developments :
can someone write a summary of all the design rules at the VHDL level ?
the libraries that can and cannot be used etc...
it's a matter of 1 KB of text and it will be used and updated
on the f-cpu site.

> > what if we made a unique testbench for all the versions ?
> > this would spare some time to the group :-)
> I guess it really makes sense to have a world-accessible CVS
> repository. sourceforge.net was already mentioned. (And btw, I hate
> this eGroups banners. Can we please move the list to sourceforge
> too?)

there is no list maintainer anymore, the list is going on its way
for a very long time, and it has become the central point for the project.
we might lose a lot of people if we move somewhere else.
OTOH, even though the banners don't disturb me, this is an abvious waste
of bandwidth.

We could make a f-cpu_vhdl list on sourceforge that will deal only with
the VHDL aspects of the project. But Sourceforge doesn't garantee that
they won't add banners in the future. I know some other places that
can help provide a banner-free mailing list : the April.org server,
seul.org, and maybe at the Paris 8 university.

Ok, now i have to write the testbench.


> Cheers,
>   Colin

thanks a lot,

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Mon Oct 2 14:43:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07068 for ; Mon, 2 Oct 2000 23:34:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:19 +0200 (MEST) Received: (qmail 6346 invoked by uid 0); 2 Oct 2000 16:01:35 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 2 Oct 2000 16:01:35 -0000 X-eGroups-Return: sentto-1101623-951-970502474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ei.egroups.com with NNFMP; 02 Oct 2000 16:01:27 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:01:14 -0000 Received: (qmail 8430 invoked from network); 2 Oct 2000 16:01:14 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 2 Oct 2000 16:01:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta2 with SMTP; 2 Oct 2000 16:01:12 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00574; Mon, 2 Oct 2000 14:43:54 +0200 Message-ID: <20001002144354.05034@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D55A59.82C7594F@f-cpu.org> <39D610E2.8FC33FDB@ifrance.com> <39D62D1B.1AD5B205@f-cpu.org> <39D842A1.A74D581@ipricot.com> X-Mailer: Mutt 0.84e In-Reply-To: <39D842A1.A74D581@ipricot.com>; from Nicolas Matringe on Mon, Oct 02, 2000 at 10:09:05AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:43:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 187b430ebe9691e6cadc9a51996c06fd Status: R X-Status: N On Mon, Oct 02, 2000 at 10:09:05AM +0200, Nicolas Matringe wrote:

> As Colin said, DON'T use the ieee.std_arith packages, use only
> ieee.numeric_std.

Read and memorized.

Maybe we should define some general VHDL coding rules for the F-CPU
project.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Mon Oct 2 14:53:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07071 for ; Mon, 2 Oct 2000 23:34:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:19 +0200 (MEST) Received: (qmail 30306 invoked by uid 0); 2 Oct 2000 16:01:57 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 2 Oct 2000 16:01:57 -0000 X-eGroups-Return: sentto-1101623-952-970502489-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 02 Oct 2000 16:01:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:01:29 -0000 Received: (qmail 5422 invoked from network); 2 Oct 2000 16:01:29 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 2 Oct 2000 16:01:29 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta2 with SMTP; 2 Oct 2000 16:01:19 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00599; Mon, 2 Oct 2000 14:53:10 +0200 Message-ID: <20001002145309.62114@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Sun, Oct 01, 2000 at 07:39:20PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:53:09 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2d82b1ad2c5136c834fe452544f3f168 Status: R X-Status: N On Sun, Oct 01, 2000 at 07:39:20PM -0700, Colin Marquardt wrote:

> A colleague has written his diploma thesis about the speed of
> different coding styles in some tools. I will ask him if this is
> publicly accessible. (It will be in German though... :-( )

Her damit ;)  URL?

[...]
> I guess it really makes sense to have a world-accessible CVS
> repository. sourceforge.net was already mentioned. (And btw, I hate
> this eGroups banners. Can we please move the list to sourceforge
> too?)

Agreed, eGroups sucks.  I don't like remote CVS, though -- multiple
repositories confuse me, and I already have two or three of them.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Mon Oct 2 14:36:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07074 for ; Mon, 2 Oct 2000 23:34:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:20 +0200 (MEST) Received: (qmail 16957 invoked by uid 0); 2 Oct 2000 16:02:16 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 2 Oct 2000 16:02:16 -0000 X-eGroups-Return: sentto-1101623-953-970502512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 02 Oct 2000 16:02:06 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:01:52 -0000 Received: (qmail 10539 invoked from network); 2 Oct 2000 16:01:52 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 2 Oct 2000 16:01:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta2 with SMTP; 2 Oct 2000 16:01:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00551; Mon, 2 Oct 2000 14:36:49 +0200 Message-ID: <20001002143649.04675@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D7FA46.90188C09@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D7FA46.90188C09@f-cpu.org>; from Yann Guidon on Mon, Oct 02, 2000 at 04:00:22AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:36:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0f245d492325cc6af067112a728fb427 Status: R X-Status: N On Mon, Oct 02, 2000 at 04:00:22AM +0100, Yann Guidon wrote:

> it is not yet clear in my head (i gotta sleep, it's 4am)
> but the organisation is slightly different from what i had
> in mind : the cache miss/fill sequence would be done by another
> separate unit, we would only need the Din/Dou/AddrRead/AddrWrite/
> WriteEn/ReadEn/Inv/Reset interface. The exact line where the data
> are stored is completely internal, whereas i have seen that you have
> made them available to the outside.

For the memory controller, the cache line number is just a meaningless
token.  No, wait -- let's call it a transaction id :)  Having a unique
identifier means that there can be multiple outstanding requests, from
different sources, at the same time.  This may not be useful for the
FC0, but perhaps later.

[...]
> > (it may be wise to add another
> > line that invalidates the whole cache in that case -- I had that in an
> > earlier version which is still in my CVS, fortunately).
> total invalidate should be done by the reset line, no ? :-)

An asynchronous reset should only happen during initialization (or when
the user hits the Big Red Switch).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Mon Oct 2 15:30:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07077 for ; Mon, 2 Oct 2000 23:34:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:21 +0200 (MEST) Received: (qmail 31473 invoked by uid 0); 2 Oct 2000 16:02:52 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 2 Oct 2000 16:02:52 -0000 X-eGroups-Return: sentto-1101623-950-970502472-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 02 Oct 2000 16:01:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:01:10 -0000 Received: (qmail 4529 invoked from network); 2 Oct 2000 16:01:10 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 2 Oct 2000 16:01:10 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta2 with SMTP; 2 Oct 2000 16:01:08 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00695; Mon, 2 Oct 2000 15:30:50 +0200 Message-ID: <20001002153050.57678@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> X-Mailer: Mutt 0.84e In-Reply-To: <00100101312101.00382@gandalf>; from Jecel Assumpcao Jr on Sun, Oct 01, 2000 at 01:23:42AM -0300 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 15:30:50 +0200 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bbd72350467b4ff3cee58c4fe0d62cd2 Status: R X-Status: N On Sun, Oct 01, 2000 at 01:23:42AM -0300, Jecel Assumpcao Jr wrote:
> This is an interesting web page:
>
>    http://www.andraka.com/multipli.htm

Pretty good overview.  What I had in mind is a combination of several
items from this list: a carry-save multiplier using a modification of
booth's algorithm and precomputed partial products as the basic (8x8)
unit -- this is the hard part --, and wallace trees for larger products.
By adding partial products the right way, we automatically get 16-bit,
32-bit and 64-bit products in later pipeline stages -- SIMD made easy :)
In other words, it's a pretty big `full adder farm'.  Expected throughput:
1 operation/cycle, latency: less than 12 cycles for a full 64-bit product
(SIMD operations would be even faster).

A simplified version using serial shift-and-add 8x8 multipliers might
save some space, but has lower throughput -- something like one operation
every 3 or 4 cycles, which is still pretty good IMHO -- and slightly
higher latencies.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Nicolas Matringe Mon Oct 2 18:03:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07080 for ; Mon, 2 Oct 2000 23:34:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:22 +0200 (MEST) Received: (qmail 5582 invoked by uid 0); 2 Oct 2000 16:03:00 -0000 Received: from jk.egroups.com (208.50.144.83) by mx12.rz2.gmx.net with SMTP; 2 Oct 2000 16:03:00 -0000 X-eGroups-Return: sentto-1101623-955-970502570-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 02 Oct 2000 16:02:50 -0000 X-Sender: nicolas.matringe@ipricot.com X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:02:50 -0000 Received: (qmail 17063 invoked from network); 2 Oct 2000 16:02:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 2 Oct 2000 16:02:50 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 2 Oct 2000 16:02:50 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id QAA13864 for ; Mon, 2 Oct 2000 16:02:48 GMT X-To: Message-ID: <39D8B1DF.D9D533F7@ipricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: fcpu From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Oct 2000 18:03:43 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: "Xilinx Adds FPGA Support to Free Web Design Tools"] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e9bcc21abd67613e8730f2d9babb0a8f Status: R X-Status: N

-------- Original Message --------
Objet: "Xilinx Adds FPGA Support to Free Web Design Tools"
Date: Mon, 02 Oct 2000 15:10:13 GMT
De: "Jan Gray" <jsgray@acm.org>
Soci=E9t=E9: Gray Research LLC
Forums: comp.arch.fpga

"Xilinx, Inc. today announced full support of the entire Spartan-II FP= GA
family as well as the 300,000 system gate Virtex XCV300E FPGA in the
WebPACK
ISE tool suite. The free downloadable software, previously available
only
for Xilinx CPLDs, now offers a zero-cost-of-entry point for designing
with
Xilinx FPGAs."

See http://www.xili= nx.com/prs_rls/webfpga.html.

(Yippee!)

Jan Gray
Gray Research LLC
www.fpgacpu.org
 From Michael Riepe Mon Oct 2 14:09:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07083 for ; Mon, 2 Oct 2000 23:34:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:22 +0200 (MEST) Received: (qmail 16116 invoked by uid 0); 2 Oct 2000 16:03:28 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 2 Oct 2000 16:03:28 -0000 X-eGroups-Return: sentto-1101623-954-970502516-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ei.egroups.com with NNFMP; 02 Oct 2000 16:02:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 16:01:56 -0000 Received: (qmail 10679 invoked from network); 2 Oct 2000 16:01:55 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 2 Oct 2000 16:01:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta2 with SMTP; 2 Oct 2000 16:01:54 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00487; Mon, 2 Oct 2000 14:09:03 +0200 Message-ID: <20001002140903.43869@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Sun, Oct 01, 2000 at 03:15:21PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:09:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dfd1ededa5015685367df3550f1cad59 Status: R X-Status: N On Sun, Oct 01, 2000 at 03:15:21PM -0700, Colin Marquardt wrote:
> Hi,
>
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> | -- $Id: icache.vhdl,v 1.4 2000/10/01 20:52:02 michael Exp $
> [...]
> | use IEEE.std_logic_arith.all;      -- gotta get rid of that later
>
> Hehe! :-)

Don't laugh - I *got* rid of it already :) I just had to get the
conversions working first.  Now I remember why I didn't use (*yuck*)
Ada for the last 10 years...

I also changed std_logic to std_ulogic in the next version; the
arguments in the FAQ convinced me.

> Hmmm... let's see... may I suggest that we use abstract data types?
> That means for instance making the reset a boolean type. No need to
> care if it is an active-low or -high pin later on, internally it is
> simply "true" or "not true".

Does that mean that I can use something like this?

      entity blah is
            port (Rst : boolean);
      end blah;

And what about vectors?

> Same for things like:
> | if (Read = '1') then
>
> If Read was a boolean, there is no need for comparing with a
> fixed value. And of course, any signal should be positive logic
> (internally).

As long as the synthesis tool groks it and does the right thing...

> | NADDRS : integer := 27; -- number of address bits (32 - 5) => 4 GByte
>
> I would rather use natural instead of integer here. natural is
> restricted to positive values by default, which an address is
> too. This will also help in situations where conversion is required
> (no need for the "unsigned" specifier).

You still need conversions for the address itself -- this is only the
*length* of the address.  You're right, though -- no array can have a
negative number of elements...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Jecel Assumpcao Jr Mon Oct 2 19:38:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07107 for ; Mon, 2 Oct 2000 23:34:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:31 +0200 (MEST) Received: (qmail 5534 invoked by uid 0); 2 Oct 2000 17:48:40 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 2 Oct 2000 17:48:40 -0000 X-eGroups-Return: sentto-1101623-956-970508893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 02 Oct 2000 17:48:36 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 17:48:13 -0000 Received: (qmail 12769 invoked from network); 2 Oct 2000 17:48:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 2 Oct 2000 17:48:12 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 2 Oct 2000 17:47:52 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id OAA25845 for ; Mon, 2 Oct 2000 14:57:18 -0300 Organization: Merlintec Computers To: f-cpu@eGroups.com X-Mailer: KMail [version 1.0.28] References: <39D8B1DF.D9D533F7@ipricot.com> In-Reply-To: <39D8B1DF.D9D533F7@ipricot.com> Message-Id: <00100214471201.00401@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:38:15 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] [Fwd: "Xilinx Adds FPGA Support to Free Web Design Tools"] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2072045e599ef85a3b693ccbf4cafa7e Status: R X-Status: N
> "Xilinx, Inc. today announced full support of the entire Spartan-II FPGA
> family as well as the 300,000 system gate Virtex XCV300E FPGA in the
> WebPACK ISE tool suite. The free downloadable software, previously available
> only for Xilinx CPLDs, now offers a zero-cost-of-entry point for designing
> with Xilinx FPGAs."

Great timing! I have registered and am downloading the CPLD-only
version now. Interesting that only the XCV300E, exactly the chip I am
using, will be supported. I found no mention of the OS required to run
this, but from the .exe names it is easy to guess it is Win98 or
something :-(

Of course, while free-as-in-free-beer software is a great help (BTW:
people who don't understand this "free beer" thing have been going to
the wrong parties ;-) and will solve many of my problems, other
problems would need free-as-in-free-speech software instead.

-- Jecel
 From Jecel Assumpcao Jr Mon Oct 2 19:47:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07116 for ; Mon, 2 Oct 2000 23:34:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:33 +0200 (MEST) Received: (qmail 19450 invoked by uid 0); 2 Oct 2000 17:55:10 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 2 Oct 2000 17:55:10 -0000 X-eGroups-Return: sentto-1101623-957-970509294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 02 Oct 2000 17:55:08 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 17:54:54 -0000 Received: (qmail 4625 invoked from network); 2 Oct 2000 17:54:54 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 2 Oct 2000 17:54:54 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 2 Oct 2000 17:54:24 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA25866 for ; Mon, 2 Oct 2000 15:03:18 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00100214531202.00401@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:47:56 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb3bea37bc063b38ccdc2eb3c6c0034a Status: R X-Status: N I will try to set up a web page decribing my FPGA architecture
tomorrow. While I have a general idea of what patents have been granted
in this area, I really haven't looked into this to see if my idea
doesn't violate a number of them (though I hope not - I tried to be
original as was requested here).

You can't GPL an idea. GPL is a distribution license for copyrighted
material. You can copyright VHDL code and IC mask designs. You can
patent certain "mechanisms" in a FPGA. I think making the information
freely available on the web should be enough.

-- Jecel
eGroups Sponsor
Click Here!
From graham@belegost.mit.edu Mon Oct 2 20:02:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA07122 for ; Mon, 2 Oct 2000 23:34:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 02 Oct 2000 23:34:35 +0200 (MEST) Received: (qmail 26753 invoked by uid 0); 2 Oct 2000 18:03:24 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 2 Oct 2000 18:03:24 -0000 X-eGroups-Return: sentto-1101623-958-970509777-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mv.egroups.com with NNFMP; 02 Oct 2000 18:03:23 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 18:02:56 -0000 Received: (qmail 27756 invoked from network); 2 Oct 2000 18:02:56 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 2 Oct 2000 18:02:56 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 2 Oct 2000 18:02:56 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA15272 for f-cpu@egroups.com; Mon, 2 Oct 2000 14:02:55 -0400 Message-Id: <200010021802.OAA15272@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <00100214531202.00401@gandalf> from "Jecel Assumpcao Jr" at Oct 02, 2000 02:47:56 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 14:02:55 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e66340a67cee2bd5ed7d5ac76abe524a Status: R X-Status: N >
> You can't GPL an idea. GPL is a distribution license for copyrighted
> material. You can copyright VHDL code and IC mask designs. You can
> patent certain "mechanisms" in a FPGA. I think making the information
> freely available on the web should be enough.
If you want to make doubly sure,
http://swpat.ffii.org/purci/indexen.html
will archive it with a time stamp recognised under European law
(tho' not yet US law?) as valid proof of prior art...

And you can always copyright a drawing, if its artistic enough ;-)

Graham

 From Michael Riepe Mon Oct 2 18:17:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11385 for ; Wed, 4 Oct 2000 05:17:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:47 +0200 (MEST) Received: (qmail 28506 invoked by uid 0); 2 Oct 2000 22:15:15 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 2 Oct 2000 22:15:15 -0000 X-eGroups-Return: sentto-1101623-959-970524911-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 02 Oct 2000 22:15:12 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 22:15:11 -0000 Received: (qmail 23323 invoked from network); 2 Oct 2000 22:15:09 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 2 Oct 2000 22:15:09 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.159) by mta2 with SMTP; 2 Oct 2000 22:15:07 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01451; Mon, 2 Oct 2000 18:17:41 +0200 Message-ID: <20001002181741.35548@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <39D8B2BC.1222D68F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D8B2BC.1222D68F@f-cpu.org>; from Yann Guidon on Mon, Oct 02, 2000 at 05:07:24PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 2 Oct 2000 18:17:41 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8dfa3c42cf3b9626b1d0cdcc5dc9fb0b Status: R X-Status: N On Mon, Oct 02, 2000 at 05:07:24PM +0100, Yann Guidon wrote:

> > I think with natural the LRM says that your address MSB can be 2**32-1
> > (without looking at any docs), so that should be enough. :-)
>
> hmmmm.... 32+5 is 37, that makes 128BG which is enough before a total rewrite.
> let's go.

I guess he's talking about 2**32-1 _address_bits_.  That means
Quadrillions of Multi-Giga-Ultra-Super-Special-Hyperbytes, or something
like that.  Let me suggest to use `Plenty-' as the unit prefix ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Tue Oct 3 02:11:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11395 for ; Wed, 4 Oct 2000 05:17:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:49 +0200 (MEST) Received: (qmail 12632 invoked by uid 0); 2 Oct 2000 23:06:54 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 2 Oct 2000 23:06:54 -0000 X-eGroups-Return: sentto-1101623-960-970528002-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 02 Oct 2000 23:06:52 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 2 Oct 2000 23:06:41 -0000 Received: (qmail 2775 invoked from network); 2 Oct 2000 23:06:40 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 2 Oct 2000 23:06:40 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 2 Oct 2000 23:06:40 -0000 Received: from f-cpu.org (nas3-26.ras.club-internet.fr [195.36.203.26]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA23076 for ; Tue, 3 Oct 2000 01:06:36 +0200 (MET DST) Message-ID: <39D92415.95BBCA58@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D7FA46.90188C09@f-cpu.org> <20001002143649.04675@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 01:11:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ec02465a5a11951b47535ef29155c7d0 Status: R X-Status: N hi,

i received several job offers and have not yet done much code.
i'll correct that tonight ;-)

Michael Riepe wrote:
> On Sun, Oct 01, 2000 at 01:23:42AM -0300, Jecel Assumpcao Jr wrote:
> > This is an interesting web page:
> >    http://www.andraka.com/multipli.htm
> Pretty good overview.  What I had in mind is a combination of several
> items from this list: a carry-save multiplier using a modification of
> booth's algorithm and precomputed partial products as the basic (8x8)
> unit -- this is the hard part --, and wallace trees for larger products.
> By adding partial products the right way, we automatically get 16-bit,
> 32-bit and 64-bit products in later pipeline stages -- SIMD made easy :)
> In other words, it's a pretty big `full adder farm'.  Expected throughput:
> 1 operation/cycle, latency: less than 12 cycles for a full 64-bit product
> (SIMD operations would be even faster).
that's interesting.

> A simplified version using serial shift-and-add 8x8 multipliers might
> save some space, but has lower throughput -- something like one operation
> every 3 or 4 cycles, which is still pretty good IMHO -- and slightly
> higher latencies.
well, this is something interesting for the division, instead.


> On Mon, Oct 02, 2000 at 04:00:22AM +0100, Yann Guidon wrote:
> > it is not yet clear in my head (i gotta sleep, it's 4am)
> > but the organisation is slightly different from what i had
> > in mind : the cache miss/fill sequence would be done by another
> > separate unit, we would only need the Din/Dou/AddrRead/AddrWrite/
> > WriteEn/ReadEn/Inv/Reset interface. The exact line where the data
> > are stored is completely internal, whereas i have seen that you have
> > made them available to the outside.
> For the memory controller, the cache line number is just a meaningless
> token.  No, wait -- let's call it a transaction id :)  Having a unique
> identifier means that there can be multiple outstanding requests, from
> different sources, at the same time.  This may not be useful for the
> FC0, but perhaps later.

now i understand better.

the idea that i had is that the "transaction ID" is not even necessary.

the time necessary for the transaction can be so long that the line that you
reserved for writing may be reused. This increases the cache thrashing.
Remember that a full transaction can take tens of cycles and if you have
64 cache lines, only one half will be really used, the others will remain
reserved. ok, 64 lines is not much but it serves as example.

keeping the line number inside the cache allows any write to really use the
Least Recently Used line, with less thrashing. It also keeps the cache size
independent from the other parameters of the chip, so it can be interchanged
at will.

I guess that we need an independent "transaction ID" to reduce the cache
thrashing and keep the cache independent from the rest.

> [...]
> > > (it may be wise to add another
> > > line that invalidates the whole cache in that case -- I had that in an
> > > earlier version which is still in my CVS, fortunately).
> > total invalidate should be done by the reset line, no ? :-)
> An asynchronous reset should only happen during initialization (or when
> the user hits the Big Red Switch).

or maybe this could be the reverse ?
cache init would be triggered during power-up (using some hardwired
firmware in ROM or a Finite State Machine that would trigger the
necessary reset signals in the right order)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
"more life, more fun"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Tue Oct 3 03:18:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11401 for ; Wed, 4 Oct 2000 05:17:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:52 +0200 (MEST) Received: (qmail 28068 invoked by uid 0); 3 Oct 2000 00:15:08 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 3 Oct 2000 00:15:08 -0000 X-eGroups-Return: sentto-1101623-961-970532066-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 03 Oct 2000 00:14:33 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 00:14:25 -0000 Received: (qmail 32272 invoked from network); 3 Oct 2000 00:14:25 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 3 Oct 2000 00:14:25 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 3 Oct 2000 00:14:24 -0000 Received: from f-cpu.org (nas1-250.aub.club-internet.fr [195.36.150.250]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA27162 for ; Tue, 3 Oct 2000 02:14:16 +0200 (MET DST) Message-ID: <39D933ED.FE44813B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 02:18:37 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) icache spec : the declaration file Content-Type: multipart/mixed; boundary="------------54464B5189907C38B003E094" X-UIDL: 6e7b7b58f85e902c9e859d15f408c356 Status: R X-Status: N --------------54464B5189907C38B003E094 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

no testbench yet, but an attempt to sum up the most recent
discussions.

I have enclosed a file that contains the declaration of the
Icache. Some will remark, if they read it (;-D) that i have
added yet another input signal : "Freeze_En". For convenience,
i have merged it more or less with the functionality of
"Inv_En" because they are used for the same purposes
(only the effects differ). They also share the "Address_mask"
input.

Can somebody correct the declaration of the addresses ?
Colin, what was exactly the trouble with the vectors ?
When done, please post the updated file.

I have also included a VGUI screenshot for my version of the
cache memory. some signals are missing though (clk and freeze).
My trick is that the LRU FIFO's last entry (LRU) is always
decoded to 64 bits and addresses the cache line write signals.
this signal vector is enabled/valid on Write_En and we don't
lose any time at all, and there is less line thrashing :-)

Michael :
> > > (it may be wise to add another
> > > line that invalidates the whole cache in that case -- I had that in an
> > > earlier version which is still in my CVS, fortunately).
> > total invalidate should be done by the reset line, no ? :-)
> An asynchronous reset should only happen during initialization (or when
> the user hits the Big Red Switch).

an Inv_En<=true with the Address_mask<=(others=>'1') should do the trick, no ?


ok, some more meat to come tonight.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------54464B5189907C38B003E094 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="Icache-decl.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Icache-decl.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIEYtQ1BVIHByb2plY3QgOiBJbnN0cnVjdGlvbiBjYWNoZSBz cGVjaWZpY2F0aW9uDQotLSBZYW5uIEd1aWRvbiwgb2N0LiAzLCAyMDAwICgyYW0pIHdpdGgg YSBsb3Qgb2YgbWF0ZXJpYWwNCi0tIGZyb20gdGhlIGYtY3B1QGVncm91cHMuY29tIG1haWxp bmcgbGlzdCAobW9zdGx5IE1pY2hhZWwgJiBDb2xpbikNCi0tIFRoaXMgZmlsZSBwcm92aWRl cyBvbmx5IHRoZSBkZWNsYXJhdGlvbiBhbmQgdGhlIGdlbmVyaWNzIGZvcg0KLS0gdGhlIElj YWNoZSBvZiB0aGUgRkMwLiBJdCBhbHNvIHN1bXMgdXAgdGhlIGNvZGluZyBjb252ZW50aW9u cw0KLS0gYWRvcHRlZCBmb3IgdGhlIFZIREwgc291cmNlcyBvZiB0aGUgcHJvamVjdC4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCmxpYnJhcnkgSUVFRTsNCnVzZSBJRUVFLnN0ZF9sb2dpY18xMTY0 LmFsbDsNCnVzZSBJRUVFLm51bWVyaWNfc3RkLmFsbDsNCg0KRU5USVRZICBJY2FjaGVfdHlw ZSAgSVMNCiAgR0VORVJJQygNCiAgICBEQndpZHRoICA6IG5hdHVyYWwgOj0gMjU2IDsgLS0g RGF0YSBCdXMgd2lkdGgsIG9yIHdpZHRoIG9mIGVhY2ggY2FjaGUgbGluZSAoMzIgYnl0ZXMp DQogICAgQUJ3aWR0aCAgOiBuYXR1cmFsIDo9IDMyICA7IC0tIEFkZHJlc3MgQnVzcyB3aWR0 aCwgaW4gMzItYnl0ZSBjaHVuY2tzICgzMis1PTEyOEdCKQ0KICAgIExvZ0xpbmVzIDogbmF0 dXJhbCA6PSA2ICAgOyAtLSBMb2cyIG9mIHRoZSBOdW1CZXIgb2YgY2FjaGUgTGluZXMgKE1V U1QgYmUgRVZFTikNCiAgICBOQmxpbmVzICA6IG5hdHVyYWwgOj0gNjQgICAgLS0gTnVtQmVy IG9mIGNhY2hlIExpbmVzICgyKipMb2dMaW5lcykgKHNtYWxsIG51bWJlciBmb3IgdGhlIGZp cnN0IGF0dGVtcHRzKQ0KICApOw0KICBQT1JUKA0KICAgQ2xrLCBJbnZfRW4sIFJlc2V0LCBS ZWFkX0VuLCBXcml0ZV9FbiwgRnJlZXplX0VuIDogSU4gQm9vbGVhbjsNCiAgIEFkZHJlc3Nf cmVhZCwgQWRkcmVzc193cml0ZSwgQWRkcmVzc19NYXNrIDogSU4gU3RkX3Vsb2dpY192ZWN0 b3IoQUJ3aWR0aC0xIGRvd250byAwKTsNCi0tICJuYXR1cmFsIiBzaG91bGQgYmUgdXNlZCBm b3IgdGhlIGFkZHJlc3NlcywgcmlnaHQgPyBCdXQgaG93IGRvIHdlIGhhbmRsZQ0KLS0gdGhl IEFORCB3aXRoIHRoZSBtYXNrcyA/DQogICBJY2FjaGVfaGl0IDogT1VUIEJvb2xlYW47DQog ICBEaW4gIDogIElOIFN0ZF91bG9naWNfdmVjdG9yKERCd2lkdGgtMSBkb3dudG8gMCk7DQog ICBEb3V0IDogT1VUIFN0ZF91bG9naWNfdmVjdG9yKERCd2lkdGgtMSBkb3dudG8gMCkNCiAg KTsNCkVORCBJY2FjaGVfdHlwZTsNCg0KLS0gdGhpcyBmaWxlIHdhcyBjb21waWxlZCBhbmQg c2ltdWxhdGVkIChlbXB0eSBhcmNoKSB3aXRoIHNpbWlsaS4= --------------54464B5189907C38B003E094 Content-Type: image/gif; name="icache1.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="icache1.gif" R0lGODlhRQJ5ArMAAAAAAAAAgAD/AACc//8A//+lAJaWlv///wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACwAAAAARQJ5AgAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//A oHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uVwyGCbwz39Rn8Lzq7u77 /2txEoJ0hTaEeyiIgIyNjkFzfHaGNYuKl4+Zmps0kYR5d6CCdZKLom8npqByeqytAHF8pxqr g56xs7C1nLy9jrGwg6iIn3KoxhSWJsTHycLOus+mk83FxtO+2dpswKPD0MHPyLa5KcwXs8rh 4aKSFpbW68Ht6tv291zW0+fr2OIv/MCxw6AvhDJg4+bhW8gwTEFn/Eb5k0cxlUCFyLA9TIju H0KP/hTrNRxJEomeVrnasYqm61W5ih9S7lolEeUtcu7QwXszc1fJn0CDVpkotKjRozzoiSyV E6nTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3L t69fCwMCCx5MuLDhw4gTK17MuLHjx5AjS55MubLlwn9JXt7MubPnz6BDiwadeeTo06hTq17N mnRphq1jy55Nu3bn17AFB9jNu7fv38CDCx9OvLjx48iTK1/OvLnz584H4144GLr169iza9/O vXt36dPvVfdOvrz58+jTawcfftt49fDjy59PHzr79tne19/Pv7//8/fh/teLfv8VaOCBCA4X oICcEJjggxBGON+CDGrioIQYZqghdhRW+MiFG4Yo4ojCdehhIyCSqOKKGpp4IiApsijjjAa6 +KIfMdKo447y2XijGznyKOSQ3vn4IxtBEqnkks8ZecCTT1pwABJQRlnBlEdmkCSTXHZZnJEA YBnmE2KKmSUHW3qp5pq7gWmmmUq8eWYHabJpJ5NuUoAllHpOaaUPcob5p6CEHlnnnYgKmecE gTK65w+NjtmnBHB6eGiimM64KKV6XskopJ1+GqqkN16a6akkbkrqqqRWmkOkcJZpqG6o1qrk prF6yimgova6K6uW0mrrsDs6WWWffArq56Cv/h7raLJ8JvuiqcRWiyCYjRSg7bbcbosXtdaG 6x+2jBSwgbl3gSvuuvSRCwi6GcBbl7rs1qtegAQQwIu8F/A7F732BlyedPnmC4C+nPhbgcJx ASzww9sFVvDEFFds8cUYZ6zxxhx37DHFFjAMl8MQl2zdYBNLgPAmIkvQslskmywzc/cVvO+5 3wo7887pufvHyy+3FTPPRCso2D1A5xxYwAIIUF7TwUHNnNSY+uxHt1hrq/QAAjtNnNfNgf2b 2MqRfafVc4YxNJNmj/1c27vBbZzcaqKd9hdrC9n03rztLbbfvQH+teB9++Y32IcXHgDVbNp9 dxd57/g3cJMLR/fi/oFnrnjhZHvteaKOP75F5DpWvjjhmBuOOuWax92663A7fTmeR4veB+k0 Vm566pvzHvXru2MeO+N2hm47FrjPqDvwrvt++e7By25487PfWvvxSOps7eGe8/3391DLzX3f hCcet+BUE++l8dhXkXzRRbPf/hTvV8u9+vDzJv/8UdSf/8z7498T/Pc/kwVQgE0gYAEhdkAE LkGBCxRYAx2YBAhG0F4TpOARLHhBdmVQg0XgYAfF9UEQDkGEI7RWCU0YBBSmkFgrZOEPXPhC W8VQhj2gYQ1RdUMc7kCHO8xUD32YAyAGEXTXI+LotHfEIA5RiTYwYhOLl0QoIo+JU3zh/hOt OAMpZrFuVeSi+7D4xQ5uUYww8GIZuWQsaRmhSq5yoBrXuCRckSCOLJDVCPAooDnSkUiq4mMG BJmCSH2AkOHx4x8VFUYMBAqOlNpTmdzogkc6y0p/cta0yLjI/AWSVY/6FbAq2alctWpUpeJk J+PXyAvIyZR6FCUMXqmrWI6yQopcJY0+CUtfIfIEtAyVLX+Jm1zqUkZ2BOWuBhXKF+ixl4Va ZiqXdswFtpGZmiQUNmMAyWdtc5vT5Fo1C3hGLGQNa1sbJzlbmTCcpUuV6ixZOa+QtHdSM56s DMw28lVPuxgTnyGaJxX0lbJ+pdNLbcNfdhSq0OI0VD3V649g/j5G0Ypa9KIY1djCDsol8Tn0 bZZzTkSbx52R1kegU9CXuWwWMo6yLaRfA+nvwpYck9YUQyiVAkFXZlB7ivOlquPb+RiHutVR bnWdK1/5zje49IXvqUoV6usSlNMo8NOd/oRn7qbXu97R7XnM66r0NPe5j3KVd5Pr3FkfVFUp 9HNeWlXeWhFX1LEZda5h5dzvImo2xHn1dObr6rXYybJzcsulSlKr4qCH1+EwVqy+C9xDpwo7 5oE1Qm1F4wn+iR3FUi+sZSXpTEUbvciWtXqhFZ5l1xrZwepTs1bgbGeDKlTAfU+y4bNcYHcb Vak51aF9pS1dpSpathIWtkyQ7XVs/qomzx6HuT06LnKVoNzlPu1+8LnfV5M6UuhG97XTlUJ1 AYpZ6YZ3g3ElrwfNe94Qple9JGRve0/4XviqUL7zbWF97QtD/OZ3hvvlrw39+98cBljAPCRw gX94YAQLUcELLmKDHYxE8EYYCeOlsEQhfOEoTljDVLRwh917TxCvV8Qjpm+JTRxfFKdYvytm 8X1d/GIAx1jG/aVxjQ18YxwPWMc7ZrBthkzkIhu5NUFW8ZGXzOQmO7kxSRbCk21DgClbuTVV rkyUYXxlLHf5y6fJMmW2HBaWjsXMZJ4LmstssDTTxWA8/cpO3fxmgp75YHGmc1vsfLAyq6zP en5Lxdhc/tBAC/oseTY0WxIdLWa58gbEPGSkcZBnOE76Spf2lQocregqJPqUe4RCpmvAaFSK YNTc7LQWPm1LEKB6B6+WQak1HYJYk1LVWGC1qBr9LExjk5JS0iQlLa3NNwHb1jCY9TKF7cZu DpLZsYJklH5dKWTj+ge69tOkVlVtXdFa07AaFSYfbeohMPqS3t51uU0d7l6NW0rpvnZKHTkm Q9I62s52JafbDWplMcvaLpj1JLtJ8HUji9yijOXA/y1vK2Sb2/SOd6YZ7kt3Jzze5iZ3qy8O 8Q5QnOOgNiTAG66DT9cb47KUVDNTDm52C1vdLT+Csld+cpizPOaydPYz2U3y/oEOslXZzHc0 /S1InWdz19PGZLQiCWwgVFrpTM/k0onOR6M3XZLLwrq2id5zq3Jh5EIweZy6jgax08DSnN7A 0VddA7Rfeu1kF4PZuTL3uGul7ne3e1nwnkdXgZ3ter8zCogZx7T3ge+Bpwrif+7xZ2di8YmP CqsvKUlvcqDwtzx85P0Mb2FW3OPDzrwbIL95pyhbmiBXu8VF3wbSl/4op1f55y/vbrhr/vVd iX0omXnz1Rv89rjfyuSbvaxtq93RTQd+8LPi+qk0f/k/eb4j0c4Q6UN/JNZ/Svavv5DtI8X7 3LcH+I0y/vBno/xCQb/5eaF+oLR//TUAM2HELP8B/pQd/mOsv/4za4P3418GPfY/QOYF/vd/ afRTZmR/Z1CABugCAShSdwUdk7VQCZUcA9gFDNiALPCAIiVYMjU3Ehg1JnWBXJCBGqgCHEhT Hjg1N9WBImiBCmgGJniCKJCCLLhYvXVZc0NcgTVa0zOCMVgGM0iDJmCDy5FWP8hatAWCU7Vd xDNWx0GCWzCEREgCRlg2mYNdJuVXMdWEjrU5qfUlQUgGVFiFInCFLVhZboMcXPiFXghTaBWB wCGFgGeGFYSAC7VYSUhZrTM7p6WEfbiGUTiGY1CGdvgBaPhcRZWDwMVX4DOBxDVUyEGHWWCI h0gneBhBlJhrl4hhmcgf/tolguPDhtgVMYQod52IXlp0imFgiamoJZ8oiD3YWd51hBW4Hqxo AQJQia/oXmYFhtrRXSF4VExoHHS4i1fgir0IGLH4hsXlgs/1gXZVjGL4AcjocMtIX10IWozo hjtIVHL4jGroWFLlPVC1NxNwOLqYjNkoZc34jEiYhYBIPhNoWvM4VGqFWrLYN6+1i9coAf8I AAGpU+2oX9v4V1qYhn7IWl8FjK3FOmeFOP0okNxTAQPpdQUJYAdJWg+5hSvojOLokIAFiazz NxN5kRSAkk+gjBnJgcH1WfLIhyIJU2HYkPDIhPEYNydpkTyJjRnpAyn4iEJJj5BYj6eDW0XZ /lf1qD7c1TTp6Dc96ZM/yQNB+TCdc4ycOJVU+Y4fWTalaFejqIhh+Y2zqDpBlYtRKZVaKWGr eH9rqQOJaEBoSYBvCZf7d5dziYF1KWH6R3/y55Z7uQksyX6BKZhtRhaDWZgyd5iCp5iOAGd7 55iPAJmIKZmNwGeJOZmWyQiD1pib+QfDZ3iX93dpkJmf6XQa8GqkqQameZo+IHaotpqs6Zqg mZqTIpq9J3606QewiWm56W/Yt5vK13m+F3GsR5jC2Xq2KW6q95vImZxr0JvMuZzHyQmtCZ03 EJpYpyzHJ5syiJ3RiWjgOZsl4HbpN56lKZ7ouYDquZ5C2J7uWYib/gZplUR43lkB1xmfL9B+ 99kCv9Sf+KmfZJhqZNJ4OZCfAsoC55Z13Cl1+GZsyedNA+drvEZtxEmd2ZmgqIhwxpZ6OYdy Hzp7QMdyptSdAPpnGgoGD2dvKfegEcqdF9ooCnd0iLRxyZaiKkpvW3dz3fZ7qVmiHRdyPEd7 zqkCCIqjJ2ByO8qjnUdzeASkLrp6Imeg1ZkCR4qkJaCkQEd8wwahuGl1+8Z0MHosWkdIL9oC V4qlI5CmtUaXajqFgEJ9tXamkkZsPMCmb/oBeDp6eVqHldmnWRmZgMqOZrGnnYaXYYaoYwYF hqpoiioafvmoUMaokimplkpkGKmYl7qp/rSRqYWZYfDDfx7QqIYGqvmUl0VAqoFmqkQjqh2g qnrGqjzjJkJHaZX6YRSGLSx6RyAAq3Qmqzujqz7apnp6q3HJYsKKdNICpgs3qsbKlT7WG7qK bqXkKSUaab7qZsAKQPLVTHLKpS9XrI65rTKTrDa6bU/aq88arYNIhztXrfAqpa+6ruwqhlII LWUqofpqfBuQrWlGrnK5iag5rrjqYK7KAf5KZgArTxx2p/Rar0YjYoxpBAm7ZQvLQEeTMlda sVF2sQ8jMRkVsiI7siRbsiZ7siibMV3hsRI0USy1sXzBsVd0rCZWMxObqjG7sgWLYAfbrznL FSwbMD2rATKr/plAu7MCRqu25wGiKacoqhdFG1tIy1/JWqSMd7WrErWXqbM0C2JVW6XGGbYB uhdaSwVBi0HdKkzQ5qVF9ytJR7ZcC631Oq3QgnErV3TEpy8nqnhxC7HEYa4SqnR1+22e9yl6 C7V9uyK8hT5QVWGoinqj9EjD6nd9trfOl7gs8pIw+ZD3iExpC7mcIrmE+3lTcrh5Ubb0M7X1 obmp04ZwyEj3CnVcF3UqV6uBm3UEQKd7hrmKK4it25UjiZRIaZT7MbQZgLq1ebRdWyBKWY7A y7mbC7010rDA5LTH+7NbAbAvaToLKVwciVPUW3LYqxXau4bc+4vfGzzGJbEwC7fK/iu3EsKF bei6M5Vaw0W8xZuxNtO+iPu+mTs+tTVciii8rAshIJuyCJzACrzADIwxN+q/+VOL8IEyh8m/ WKF+yNs/qisioeiV+Ju/4EWZSJDBToDBvOu3v4EvFnwVJgzBKDyH4XugwvfA2bvB6mW8GEDC TdDCNby8ucpejWamfWe7kkfD5GvD5FW1o6aagGa5W7ufJ/zC+vO5YAuiTAtozGfEWXG29aLE YuqgFIosX3owkzR0pqfFWMHFJ/a4J9ehQYpzuRl0NAd7aHwVarwuwrqkmCdxdkpvuTud2lfH VnHHLcbG2rarPTq6jxZn53qeUOzCUiyt+LWkt9SjTmqb/gjjrUX8yD0Mv9FKLjuab0JHbVVH bEEMFTx8xD5ssDFsq3nHyarsyT7mquY5ATrMBKm8xUgMUDh8Abe8BLmcxruMTyqsBL9szIJc FYQcLgSzv8j8ygEXxZF8wA1czdZ8zdi8ZmMbzZAcyW3ism22wuRHtMlMFcs8Y0GozURwzK9J zrCsy6vMs62coYF8ve8szPGctPPcf6jsztzcyd7sGz2Em8eHxcOqm/b8z7Ec0JIssOUJTAaN oQidw+U8FedcLUMUa6V7xd3nz2gqzVJMtw7Ktp9Cyqr3a2F8D2IXzHY8zPGkKsByyYUi09Nn uvdWfR6toCD9wjC9r3tcu0TM/ik23aI4ndAf3c2gSJT361uNWzrc0dMd99NzjMnKZMW9sNIV LRVeVMDOQ1Ldux0S7I0cAsTWWrg2R9OLXNVmrQ1Yfc8tnc/WpYTLE5IyOYwlZYruurZALbhj urTKkruC+29O7KcWwNKD7NJpSFlzLb3BS5TD64QCbI7dWNc0s8+k1s9GrdNITR+3OLwz6YPm S9k36dUxCVnZQcvWy8490NYKDc+y/DQQSVaBuJEjab/oS9oc+ZV0XdkO3c71TNFufdhwbdeK /b2MbY96+LwVyFg6eB3FnASq7bCZvQLR7YnDLY0OOb/KHb1LbVY52dXOddwwqE8a+8xnPN1G utPy/iGUTe1UjkjAvqtb8b24T2iK2Xzf+J3fH5PT23zUAP0fYQ3bKvi8ncvbA1BQ4owPrO3L WR0VahTg+BiOotg9YzmNuMWGT51E6pxxJLHghd3gUHHROcbGYVcSHt7fmv3fDB0AvfzhHc7f FGDYyozY49TiKN7R6G3LIP4UIj4sNh7jJg7jOh7cM37dN2zZNFDdRB7RN57emx3SSD4DSt7a TT7kVP7Wry1jP27lDXHiQL7kFk3j1bTlT9vlQl7mKb7QK87iUS5rQZ7jaE7d6u23ZM7kCn7m dm6lcw6xdT7l/s3gcJ6kez63bR4Dfp7mLg7cVy7cWY6shb7j1onnMm7O/mJ+TH3+5ooO6Ite 5I1es48O5ucn6ZCOFJxa6khGqS8e6JMe5qbe6qfhqUWd6Yn+567t6pERqbb+6Zu+T6IO6g6e 65KRL8COGagenKo+6rC14V5x6HJ+7L5+XiIsFszu5LJe5Sgw7dLOZ54Z65re7YgeYZj5p8Ze 7V++6/PVmdKO6d5u7YJeY9hu3mbu7OaeX/5H0Fi7afaJbeo+6/ze7C9WgIPdnESq76lO7lz+ 7RcG8EVQoyVe8Ote7rTeYQsaTWAqxni7rIJNpsVneVatyK487g9/8P6eYkr6KEAKulWXbvz2 bhIHevbu5g7f7xCP8OB+799Krb95daikcPvq/vFu69sgL/MiT+0kb/MIJ3s+H0kqD8h32/E/ v9r7zu6rTu9GH69IH8dLb/HyCsdXG/BDr9K9Pu/nrm/g2qxlWsoYr/MNGth7baYvb+hRP/Ps bgLvznlS4PXiG/NSj+zJbgO17Gq66/JBLd1Bv/fPDu3wye1CH+dEP2J1P8Jx//WMr+furgNv z5uRP/ma3+7/XkiHNNHxbvCbT/c7ln3/CfZ6L/eqT/mdT/ayO9IDz9aZn+ejn6Wlf/RXv6vB dvnDieOiT/ucX/QXmvsH/fRXPftezvrC3/L9VqWN/JjIj+ekX/nDv3ui2/WhnvqSD/zT3/q7 /01u3J2yr/2bP/Vj/l+o0R/o3b/8K/D3qF/4q1/7JPD4cpb4vh/y8r+mt4/+5A/85g8BQE5a 7cVZb979B0NxJMuJMFN1ZVsMdWN5luBXs+Oc5nv/B/52QWKRNzQmacgTbqmERqVTE5N6xVqx 243W++SGxaRB2XxGp9Vrdts9ILzlc7p8fLznb5nvTKsHDKsbJCw0PEQsC3T5W7zq25NpdKRU KgvAzNTc5Oz0/AQNFR0lLQ1VrEyZTFWCvFgVgWWdpbk0vcXN1d3NRaWN/eVytZAFKQ5GNrHl 5RRwfhZg3nTujJYepS71Te445pZ04gP7Jo9Zvs60xlSXZtfMDnXHlRfdLo+8Nxqu8O7O/v9P cQ5dAHrtPsEDVZCUQlD2ADZ5SGQfhX4cKka8JxCdNXXUEEJjSNBTtJAEn72DFq/XAIz8WgKZ CBHcS5oYNF5LmY7jumkJT74TKcrdUJ8I67GsebGmxXD4GC2FOuGmwaA8rZYEajUoVqJZR6bT hpSm0qhOXYrzUxbqVGb0OmrFBnZdzoQ9vVaTO8phRLJqz5qlOM5vS7a82O28avcrXMaLEefF 2/jT3od9B9do+krw5YeFdYH0GJoj3YNGTXI9THqk6YZiX1q+HBNzWs4YPQ/EnVs3J8oAYQ+W DeB34NoRb+8uCtIUaNalQfPq/W+42uDTZxcHeBz5du4rl1qP/lp9M/Zyxzs+H8gaK871YT0I 4AYeqnja5PPd7ir58+q4hku1j64C+JCR77vMiBnPPm7wUww3hZprcJ7l3HsvmQKTOvAvHRS8 bwCV7DrPJJR+OuirkkhTrq6FSDypRZAmeFFAAjkEBi3AVriQRiM8kwdFxPKrhkSeuIqQIdUW 86ojVOAbEEYZg8nxtQyJm0nHBT1UMavD5GqvqreqypIxIyFDMi8lkWIStCd/ibIl+qq0Ehke m4lsqwm1SjFMMPdU7ES8DlsSgCYxGHSWNjF6c8M4k5mzwcce0w9POoVK7K5J+Zx0S0DRFHRN CQpl5VC+ppRJ0UWDYVAn5VwcTcjV/nqEEKURY51rPdOGggbGXCkANdRTmbJRs/p+nSXV7o5F dk8BAuTVQmJJvU5YOJ+txLyNmFsO2/+0bYbbIKdxxjUNevWVWmnPRXBYcx3RLll332W2HFEr g1a4BNfVo9139+0uXnLm9a1e8ADGV5lEDkY4YYXZMLDgUtO9UQWCHR5hYYvbiONijdFomOJE n6I4ZHRFNtXhj1uYmGTfCEj51Jb/Ffhelddl+eU4bY4vZnVnLphle3lGWeSTWcAZaAJRKJrD pKHUeVqjqUU62qdJWJrNpkue+tmaa866CqGvBrlrc6tWkGxDwQ5a7LExOKDttkt424IDiDW7 3Ih/dlrt/kW1mBtutvt2+etgIcZa7701AFyExCuIO/CQh8bRcK0Rp+DtxjNYfIK5M9ex7lQg l1hyuimvvG/OS78cgM1HfxxtokX/lW/GNd8AcNslOF1pwe8eGHbH2Z4d99ppx93t3DkwPvUQ lP/geBJS97wS0FXx/XDMg1d9eOGxf75yE5xPYvHoKZne6+qtZCL54jdnHnW52/cgcfBJ30L8 3UemsvDzyRsfeOLVX5/8jFe7Aa6PceqznACVZ7/WDU5DYdtf2b6XPPi5AICLy5zpvHe9DW7P g9kr3geJN0Kp4at8JehfBKGQQrl5kIKmK6D8CMg5GY7wdgHE4ANN6LrIqVCC/qzQoAg/GEQh /o17NQQhCJEoQhYC4oRU8+EPU3HDHNZwiS3sYBJxaMMhcg9vJuNh6KLIPyDGzYwFVJ3blAjA v6lxi1hUoxsHCEM3frFnYaTeGLHTxErMzwN8zMMTRwBIPfaAkDN4oR9Rp0h/NJB3MivkfCKp Q5rh0XyTBA4mH7ZDB+YPgpoMDyjtyMlH7kyUY9laKlW5Sla20pWvhGUsZTlLWtaylfcjXC7T dkpedgyMndzk63o5TCk5En/B7CExlRmwA6JxBBXUngUZ+QFB1miZ15TXBa64vDBM84+WRCE2 xfkNJGwTBN70ATqBVcq8jdOd5NPmBtnoTDa2sXF1/sQh+9K4SCzqD5klFOY7BSo9bcbQi0rM Yj+7SELbETGh6uwCOKE4UIouopwupOAbzek+hSLxhmnEpxZ3eUyAJrOiJx3DRZNIQ3kmFHM5 ZCgXtQhTf5bUpnlEaU6FEc/tVbGlJFToTJt5z/891JT/HGVAdbrUKQxBjnS8ZxzziTg01vN/ CYTqGkMqRnbWlKlfhcksIArJ4FwSrGeVCBASqbitUqGaITgkWkEZ1zC81RhyxasQcElJpJo1 r3/9JClJmlSTAtawXP1lVwPru4011rGPhWxkJSuHjG0MQ8C8qV+rN1nOdtaznwUtGyqrscsq dqTnC21qVbta1rZ2DaUd/mzvVOha2tbWtrddGGx16cnTbtYM/AJucIU7XOLi4gy65Wtmw/k+ Zz7tDMWFbnSlO91+mQG5vMVuYWPKgrF25rfUBW94xTveyVh3LBIdpP+K2D0FPZe874VvfId7 XORZFZ6YJSxiswjVhtZxnm19pn0p4V75FtjAB84NfZHnUr8Fwa7UtKdDs+fTDna3oy2wMAgI jGAOd9jDR/HXRp+ZVvzKFo6ayyhIF+nfGIhYcUXY8IdlPOMOKziaWo2qf6sKYK+WdbknXi+K g5zh/b4RpDlGchBiTGMmN5m8NqaqHGdHYZmGtcT3ouKUtVzhIC/PoN6jsgth/F0nl9nM04Uy /gf7G8PLvRCohkSvNTl6Rh3XOXXQPCdGL9jmFIvUB0s+c6AF7a40+++jRvTzm/Fw5aNSgojO MyMHlUzmQVfa0tspNE8RCuYty5TIeDQxLbLMaVJ7GgiAvnSqVa2LTDczhEdec6wPaGXTKrWM MDTyf0OKZxagetW/BnZr/JUzRrczTgVAdrKVnewQ+DrYz4Z2q/Px4G+aqwAbuLaGKQ1tbnNb 2vegdiOple0MkNsDzu52ui0NZZ9JJ85wXZe5LyBvDqBb3fc+83G3lt8ZFdurOqJ3BQKuAXvj 2+BMLoMtFb5whjfc4Q+HeMQlPvFYWmDgGSj4wTXu4TPsm99M87cK/i8ugZFfIOMbR7mBbcw1 d4d8qnA7npv9UvKSW+DkKcf5e7+dTZcvlL2STnRNaN7sbefc6AfeOcx6LtQGA/0yQ9e2vo4+ 9egmvc8BjnJzNZvdklpxx3zmcU+FzGsva/2cMb/6vJe99ppX4OZUh/t8zbtgRTfvxp+G3AUP 6lBI4zPSLWaw3ekXdB68Pe6H31fSmf5z9faYVI9Osd7rXtQqYzjw8btxEgyPeM4fS/Fet/OK tdfQfU601ptOtBUvX8RDc1eeX1cgNCFf+sIXvfO3D+7nv/xmvs9QgF0GtXolvDrKA1/1wA+w lF3a+6yXDvkGkzrupZ/guY8exXtWvvF9/q7OoT0111KFde7cHEeyCz7WdP679hf/aZPbfvrv r26IxXzhxTe+8nddOkYerWnUE571k1+BzYO/AVwJ+RO7Uus/SPsp/ws+tZI5JRg12jk+9TtA BgwI9yPADEQHqzuj77OclysoBMKq9Mq/h/A+WLs+4ku7FRvBsLvA6NPAGAQxcRmVEoQdtls7 ooNBGeTBTlA8GVgrOLPBXwnCEIC6DxDAHlRCTPhBZxlCyTnCc8PAJaTC8rKHdpu2dxObKOyA JKxCGdQ3rqGriHpCw+HCepvCL1RDJoQDinPDN4TDOJTDOaTDVLI4HcSSNdRD3jADlvs4q8Gv QjrDDfDCPYQ//gXzmTHUwv0ZRIJLQ0NcQnZTxJ4jP/BhvwccjEbEuEeExB5swn67kdYTPMZj v1/QRJvgxE4Ew+pDlMcDwMF7MfvAwWXDQ1U0RA5kH0uUJgFbp2OiogS6vqESPdIhvfKrr1yk O+5awdrbQVuUvs97RafjpmiMLeAhvlfbJprqMnqSsO+hRv6LxefrtVR0RgKERnEMqmncOmRa nY3KoKEKO+azwFFUp7EqRSQkx3I8RFaUNDqivV3zO7NbQGDsxd2asPpbvoOCxflbgV/UJwPi pxRUwJV6yBkoRH08PGi8xtLLRi9COz5DPtnYyKB7x/7zvwn8tHZ0PoQUKW1krt+b/seKyUeM fEZ+tEaWFCIMWsbiW6mCTK5rrCerArsKGr8RbMiDrLuSlEii3L5amEmavD2NxEk/c8nMY8gy jAiVTMqgYiSWQsdahMpItMmbDLySHL7B2z8yvJsfKMIiGMnTMUsRirmBdMpmDEu4+0Gg5EaA HMYIa0Fo8rGX0MuA5EuJzLpKVDEZuMi7NLpPBLm11KNZVDawZMxVHDYH3EkShEySacsOOMX2 s8vKbExWxEJwqxdBxDbKFM0MpC8xZKbNjKLPtLmnPLhb6ZI97LgcmMTTmyTZdDvarM062Zfb 9LY2rMPjRM7kVM7llLg7jLo87Dy3CC7ijLY+ZLndHCxi/vJNCljMSvMRFskJF1EVeMiTPHmV 1PgI81S1lStNnpOmCZLG4thOqQDOZ4OU+5QVkSCK/YyQS4mMLQk2xwREwPPGUczE1HxOo0sR AAVQMUEPV3GVEgGXn2jQXxNQWrCO7urK2phPCehOQWNQLbkLIPkWcKGUEYUL6qSxC/Uy+LS/ TtK12LudoVRAsBPG5DNGqnJRcJwAyWS2BMW5EOUSFLUUkugJEs2UFB1PFZ0xFlVHxktG3qrK s+RIudTRlkzHcHS9AsU8xaxPVUuJVqHQVflO8qQL9eSP8eQTJpUxJ80zLu0AznGqCFsvhxTI q6RKFShFDX1Tc/jS1ewPYNO9/tAzTOGh0eGx0YjcJK+sQOzpRvqZUj2FxxTsy4pEQcpJVEp1 gQ+tQuYgziNZz7H0SCC7qkY9SSplsDlFQCqNwG0Eqrgkxb2z0irF0pea1dUrAU4FVHyzOjol yaviRTxVSuyKURzzx6eKR6MUSnssy91z1Hyay1v9RtXc1ffrVfqDS55Mxkg1SKgwpwl81pgU 1ixVAV2t1nS7VglcwApEVU3j1sRJmc4kgivaSFbV1mit1XUt1z8914Mb1CTjLwNCVqJU1uaC nsuI0TUzVoFFv49MzGX109DsV4NzU4ISKB9FNmqd2M6r2F0MVjkTHXn9gA4FAHPd2AAV1Sy8 WATF/keJPVl0TVnTdCeWIVmTfdlV61hHwM5M8jjnbFnovNmMTDjmJNqiNdqjTU6B09igpbqc PSx9AIAC6FkKaDvu5FemfTanfVqJaE+flUKXxVpBjdmtvYOavdqwtdCxJVsxMFuwRdtQHbb2 WaB7RCRRg8sMolsgxDaMXdq3TbkmFD8edYS81dsXFddu6gGb9dt8U9vJY9QpGtz4JNx0Styz Xdx1a1yk9EA6+0fYk7WXQkbyC0ZFvVQqqFfPZdhCLd2PRUzRhUhNNTIysNzLHbS87EmehMm3 xNKq5DIhY0mXnFy7OzR5rNIw01xXHSLildbDnU23pV1BO8cE9LmWjLw7/uM1raxTrszMecXd 6dVJ7HO1BavXF/3eO+3C2X1exg0xZyVe3l3J971Jd+RKMZC8RqVXAnofRJ3KYWVeQkTf9C2z 6GW+JQLe3VVIBPzV4GlXKGjV9h1V463RA4ZV9/1aoAVgilVbxAy/qQpK1I1dsizdEKY9EYbA gmWzOdpLJPtcTFVdET5U6LPgC743rV1bIMDYqqVP55XhJqPhecVE2BHZFWjbGN7hbuvhGu6B IS5ifyXNndUpJV5iXrWufXPinILiKFa3oUXaLebiLvZiWfLa89VhLOY467SBKkapKybj4vSF RETismXZCl5jmL1CND4pNZ5jlL3MN5YCPM7j/rTdYz6Gghvu2z++tLy82/z9hRydArnF22Bg ZNAkYkPG3MsMXHJ1NMg13OBlywD8X0qOL8CVXGTgZAIV3FLugQxTXFAeL9uV0UJ13dX14Dbq XEL9YEA4XTs71hVO2Cir5SRr4Vz9ZFZ+sswFynXNXQNG4L4zVFmdyjs45u71Xd2FYPw93jx9 ZiAl5lQT4IUiYHjkXI6K0vAL2GxGXPv1XnD2R3HOPJmr3/6V5G2GWxr0VXC93yuFX/t7XOXV g3d2YFyd23He5+kV5jGWZ/HqZqb7ZqOqZlgMM37OgwZOZ4buNAq0Unv2ZIM+aPDCxYfFvkp8 YVlOVsIEWBDsZxMe/lisCuleBt2VBr/tleONrrQjFuQYIGRtlulAo2m2/OEICmIR8OOcdjJJ rGkuCGqhRjjzcs2ixoKjRuomtU6uY2ojcOqn/jAt/uKs1uqtLtowRkONtmq5w2rlmmobjmMx nuSwrrHq88OyjoKqVmsE22m3LgG4jmuVy1y6DgK7vmv5+lci6+lI+tizG+yo5Vuc7usytmRT hmff2VNctchhHq/2sE0FDeW8fuxlyuwoWGXwuk3pBC42lVDdEG1kEeWx66/ENDTUxqTfyzHV 5qli5OTOpq7PFs53Ke3bTg/4Ou1pvr+XXElUphadZMi+A8nG/lkw7Zb0BM8xJYnzaG4z/o3Q CUXP6o6VMxWN04juHtE5zA7X21Wz3i0kmvqoifSoP5Nsz1YRIU3RneBPoEDS/hRRMtHtLwET Iy3S7l5s8b7mU55WySFvBPbvr5RJsFZv6sbP+y7SBzWK6a7v8LSU+jYT+EYP+qau3r7KkeS/ tBzv7+5vbP3vAk/rMgOSBK/Q+M7PFB9tJVXwDzlSFA2J3OaOv2ZYF4NWFXPBkD1h2LbEjNLg uhxxJytxFj/xIlGWI19vFtduP1HwIidRGce0vNbrH7jp5FbuWdmKBSVTISlP7HZwE1VT7hYK MV/SMo9wjpZyHDVfnfrps/Zq/zXwA7/yXEDxFUfoNJ9yHuBr/iEnL0+dB+dGUxU/jf+47DrO cyXY88QuZkWg4kNPgkRX9Dvn6kmn9EqHwzd3xDiP9PgzThiw44qC9E2/cLbuWkf3gVAXdema a1P3TDeH8yBP9fBadVZ3daot5Fhv5cYt7PghvbObmV2P015vnsyp8pjG9QLD8KMk8GVflM1G p9lO72PXjWTXU0s1UM5sMWvv0srVdGkfCAwnSBwn2F+u1FcLGddO7WQld9XFtcjudm+/hmRP P1HUMq+EqUfFF+IG7wi2dwVmdmOH90WnZ6cr71fEXl2r6HP/bnrnNF6+M+RG64Dnbe/mbw3v J35+bZUJcHWNJoxPbWaEdYkX64HX/ueY0kV0rlV8X5eNb+aO92Z/h/hXF3mB53Vk5fFj9OgP vNSoohjw9TucH9iF7Vx3D/mZB65Zp/VyO2wrN3o0D2S2gmnNDmwWQPWmN208T3ohrvVNfHer NwWizvpT33pU7HqvJ4UwdOOwT+Kxj2ezV/VOt/S4l/u5hyVM5/qid3vPM+O+UvsUqPq83w1E jJq+p4G/B3zqM3TCnwHDP/xvx3rFB2q2b168b/zAf3zIB4Fij/jKFy6kx/yIpXzOxw3P//wW wK3TR/3UV/3LL33NW/3Xh/3Y96zWHzDZt/3bx/2EoX12yf3e9/3fb4PdF/7hJ/7iN/7jR/7k V/7lZ/7mD3f+54f+6Jf+6af+N44AAAA7 --------------54464B5189907C38B003E094-- From Yann Guidon Tue Oct 3 05:24:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11404 for ; Wed, 4 Oct 2000 05:17:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:55 +0200 (MEST) Received: (qmail 15890 invoked by uid 0); 3 Oct 2000 02:20:38 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 3 Oct 2000 02:20:38 -0000 X-eGroups-Return: sentto-1101623-962-970539612-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 03 Oct 2000 02:20:32 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 02:20:12 -0000 Received: (qmail 23066 invoked from network); 3 Oct 2000 02:20:12 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Oct 2000 02:20:12 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 3 Oct 2000 02:20:11 -0000 Received: from f-cpu.org (nas3-47.ras.club-internet.fr [195.36.203.47]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA29141 for ; Tue, 3 Oct 2000 04:20:07 +0200 (MET DST) Message-ID: <39D9516E.DA1D0A0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 04:24:30 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) testbench attempt (+re) Content-Type: multipart/mixed; boundary="------------51B191A8188F551FD854BE27" X-UIDL: 81ca869f77eeecf18c5c2ec0980987ee Status: R X-Status: N --------------51B191A8188F551FD854BE27 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Michael Riepe wrote:
> On Mon, Oct 02, 2000 at 12:40:55AM +0100, Yann Guidon wrote:
> > >  Instead, the LRU is always
> > > updated immediately following a read operation (at the next clock cycle),
> > > cache hit or not.
> > that's curious. is it speculative or something like that ? ...
> Not at all.  You can change the LRU unit immediately or later, when
> the line is valid and the read completes.  You just have to save the
> line number for the fill operation.  In my `global plan', the cache
> sends it to the memory controller, and the m.c. sends it back when it
> fills the cache line.  This way, the cache and memory controller are
> less tightly coupled, and the read and write ports are independent of
> each other because the write port doesn't need the LRU unit any longer.
> Another feature is that there is only one interface to the LRU unit,
> and all LRU updates work the same way, no matter whether the data is in
> the cache or not.

re-re-reading it later helps me understand better what you meant.
unfortunately, the precedent cache thrashing remark still applies
(unless there's a point i still missed).

> > btw, have you tested this code (and how) ?
> It's syntacitically correct (at least Simili doesn't object).
so, someone else is using it, cool :-)
if someone has another VHDL suite, please test our files.
Simili is not the most solid SW ever, even if it 'works'.

> I didn't have enough time to write a testbench.
so here is something to start with. just replace the "dumb" arch with yours.
you can also write messages from inside your code, so you can test
the temporary values.

i'm going to include text file reading, so we can make long test
vectors that can be generated from a C file.

dman, i'm learning rather quicly, maybe under the stimulation of the excitment :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------51B191A8188F551FD854BE27 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="tb01.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="tb01.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIEYtQ1BVIHByb2plY3QgOiBJbnN0cnVjdGlvbiBjYWNoZSBz cGVjaWZpY2F0aW9uICYgdGVzdGJlbmNoDQotLSBZYW5uIEd1aWRvbiwgb2N0LiAzLCAyMDAw ICgyYW0pIHdpdGggYSBsb3Qgb2YgbWF0ZXJpYWwNCi0tIGZyb20gdGhlIGYtY3B1QGVncm91 cHMuY29tIG1haWxpbmcgbGlzdCAobW9zdGx5IE1pY2hhZWwgJiBDb2xpbikNCi0tIFRoaXMg ZmlsZSBpcyBub3QgZmluaXNoZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpsaWJyYXJ5IElFRUU7 DQp1c2UgSUVFRS5zdGRfbG9naWNfMTE2NC5hbGw7DQp1c2UgSUVFRS5udW1lcmljX3N0ZC5h bGw7DQp1c2Ugc3RkLnRleHRpby5hbGw7DQp1c2UgaWVlZS5zdGRfbG9naWNfdGV4dGlvLmFs bDsNCg0KRU5USVRZICBJY2FjaGVfdHlwZSAgSVMNCiAgR0VORVJJQygNCiAgICBEQndpZHRo ICA6IG5hdHVyYWwgOj0gMjU2IDsgLS0gRGF0YSBCdXMgd2lkdGgsIG9yIHdpZHRoIG9mIGVh Y2ggY2FjaGUgbGluZSAoMzIgYnl0ZXMpDQogICAgQUJ3aWR0aCAgOiBuYXR1cmFsIDo9IDMy ICA7IC0tIEFkZHJlc3MgQnVzcyB3aWR0aCwgaW4gMzItYnl0ZSBjaHVuY2tzICgzMis1PTEy OEdCKQ0KICAgIExvZ0xpbmVzIDogbmF0dXJhbCA6PSA2ICAgOyAtLSBMb2cyIG9mIHRoZSBO dW1CZXIgb2YgY2FjaGUgTGluZXMgKE1VU1QgYmUgRVZFTikNCiAgICBOQmxpbmVzICA6IG5h dHVyYWwgOj0gNjQgICAgLS0gTnVtQmVyIG9mIGNhY2hlIExpbmVzICgyKipMb2dMaW5lcykg KHNtYWxsIG51bWJlciBmb3IgdGhlIGZpcnN0IGF0dGVtcHRzKQ0KICApOw0KICBQT1JUKA0K ICAgQ2xrLCBJbnZfRW4sIFJlc2V0LCBSZWFkX0VuLCBXcml0ZV9FbiwgRnJlZXplX0VuIDog SU4gQm9vbGVhbjsNCiAgIEFkZHJlc3NfcmVhZCwgQWRkcmVzc193cml0ZSwgQWRkcmVzc19N YXNrIDogSU4gU3RkX3Vsb2dpY192ZWN0b3IoQUJ3aWR0aC0xIGRvd250byAwKTsNCi0tICJu YXR1cmFsIiBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIGFkZHJlc3NlcywgcmlnaHQgPyBCdXQg aG93IGRvIHdlIGhhbmRsZQ0KLS0gdGhlIEFORCB3aXRoIHRoZSBtYXNrcyA/DQogICBJY2Fj aGVfaGl0IDogT1VUIEJvb2xlYW47DQogICBEaW4gIDogIElOIFN0ZF91bG9naWNfdmVjdG9y KERCd2lkdGgtMSBkb3dudG8gMCk7DQogICBEb3V0IDogT1VUIFN0ZF91bG9naWNfdmVjdG9y KERCd2lkdGgtMSBkb3dudG8gMCkNCiAgKTsNCkVORCBJY2FjaGVfdHlwZTsNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCi0tIER1bWIgbGF0Y2ggd2l0aCByZXNldC4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpB cmNoaXRlY3R1cmUgZHVtYiBvZiBJY2FjaGVfdHlwZSBJUw0KYmVnaW4NCiBwcm9jZXNzIChD TEssIHJlc2V0KQ0KICAgICB2YXJpYWJsZSBsb3V0IDogbGluZSA7DQogYmVnaW4NCiAgIGlm IHJlc2V0PXRydWUgdGhlbg0KICAgICBEb3V0PD0ob3RoZXJzPT4nMCcpOw0KICAgICBXUklU RShsb3V0LCJSZXNldCIpOw0KICAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgICAg V1JJVEUobG91dCwiICIpOw0KICAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgIGVs c2UNCiAgICAgaWYgKENMSydldmVudCBhbmQgQ0xLPXRydWUpIHRoZW4NCiAgICAgICBEb3V0 PD1EaW47DQogICAgIGVuZCBpZjsNCiAgIGVuZCBpZjsNCiBlbmQgcHJvY2VzczsNCg0KZW5k IGR1bWI7DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFRlc3RiZW5jaGluZyA6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KbGlicmFyeSBJRUVFOw0KdXNlIElFRUUuc3RkX2xvZ2ljXzExNjQuYWxsOw0K dXNlIElFRUUubnVtZXJpY19zdGQuYWxsOw0KdXNlIHN0ZC50ZXh0aW8uYWxsOw0KdXNlIGll ZWUuc3RkX2xvZ2ljX3RleHRpby5hbGw7DQp1c2UgV29yay5JY2FjaGVfdHlwZTsNCg0KZW50 aXR5IHRlc3RiZW5jaCBpcw0KLS0gY29weSBvZiB0aGUgYWJvdmUgZGVjbGFyYXRpb24NCiAg R0VORVJJQygNCiAgICBEQndpZHRoICA6IG5hdHVyYWwgOj0gMjU2IDsgLS0gRGF0YSBCdXMg d2lkdGgsIG9yIHdpZHRoIG9mIGVhY2ggY2FjaGUgbGluZSAoMzIgYnl0ZXMpDQogICAgQUJ3 aWR0aCAgOiBuYXR1cmFsIDo9IDMyICA7IC0tIEFkZHJlc3MgQnVzcyB3aWR0aCwgaW4gMzIt Ynl0ZSBjaHVuY2tzICgzMis1PTEyOEdCKQ0KICAgIExvZ0xpbmVzIDogbmF0dXJhbCA6PSA2 ICAgOyAtLSBMb2cyIG9mIHRoZSBOdW1CZXIgb2YgY2FjaGUgTGluZXMgKE1VU1QgYmUgRVZF TikNCiAgICBOQmxpbmVzICA6IG5hdHVyYWwgOj0gNjQgICAgLS0gTnVtQmVyIG9mIGNhY2hl IExpbmVzICgyKipMb2dMaW5lcykgKHNtYWxsIG51bWJlciBmb3IgdGhlIGZpcnN0IGF0dGVt cHRzKQ0KICApOw0KZW5kIHRlc3RiZW5jaDsNCg0KYXJjaGl0ZWN0dXJlIHRlc3QxIG9mIHRl c3RiZW5jaCBpcw0KLS0gdGhpcyBpcyBhbm90aGVyIGNvcHksIGJ1dCBoZXJlIGFyZSB0aGUg c2lnbmFscy9wb3J0cyA6DQogIHNpZ25hbCBkaW4sZG91dCA6IFN0ZF91bG9naWNfdmVjdG9y KERCd2lkdGgtMSBkb3dudG8gMCk7IC0tIHVuaW5pdGlhbGl6ZWQgb24gcHVycG9zZS4NCiAg c2lnbmFsIHJlc2V0LGNsayxJbnZfRW4sUmVhZF9FbixXcml0ZV9FbixGcmVlemVfRW4gOiBC b29sZWFuOj1mYWxzZTsgLS0gaW5wdXRzIG9mIHRoZSBjYWNoZQ0KICBzaWduYWwgQWRkcmVz c19yZWFkLCBBZGRyZXNzX3dyaXRlLCBBZGRyZXNzX01hc2sgOiBTdGRfdWxvZ2ljX3ZlY3Rv cihBQndpZHRoLTEgZG93bnRvIDApOj0ob3RoZXJzPT4nMCcpOw0KICBzaWduYWwgSWNhY2hl X2hpdCA6IEJvb2xlYW47IC0tIHVuaW5pdGlhbGl6ZWQgOiBvdXRwdXQgc2lnbmFsOw0KDQot LSBpbnRlcm5hbCBjb3VudGVyIDoNCiAgc2hhcmVkIHZhcmlhYmxlIGN5Y2xlIDogbmF0dXJh bCA6PTE7DQoNCiAgcHJvY2VkdXJlIHByaW50IGlzDQogICAgdmFyaWFibGUgbG91dCA6IGxp bmUgOw0KICBiZWdpbg0KICAgIFdSSVRFKGxvdXQsIiogY3ljbGU6Iik7DQogICAgV1JJVEUo bG91dCxjeWNsZSk7DQogICAgV1JJVEVMSU5FKE9VVFBVVCwgbG91dCk7DQotLSAgICBXUklU RShsb3V0LCJEaW4gOiIpOw0KLS0gICAgV1JJVEUobG91dCxkaW4pOw0KLS0gICAgV1JJVEVM SU5FKE9VVFBVVCwgbG91dCk7DQotLSAgICBXUklURShsb3V0LCJEb3V0OiIpOw0KLS0gICAg V1JJVEUobG91dCxkb3V0KTsNCi0tICAgIFdSSVRFTElORShPVVRQVVQsIGxvdXQpOw0KICAg IGlmIGNsaz10cnVlIHRoZW4NCiAgICAgIFdSSVRFKGxvdXQsIiAgIGNsayIpOw0KICAgIGVu ZCBpZjsNCiAgICBpZiByZXNldD10cnVlIHRoZW4NCiAgICAgIFdSSVRFKGxvdXQsIiAgIHJl c2V0Iik7DQogICAgZW5kIGlmOw0KICAgIGlmIEljYWNoZV9oaXQ9dHJ1ZSB0aGVuDQogICAg ICBXUklURShsb3V0LCIgICBJY2FjaGVfaGl0ICEgRG91dD0iKTsNCiAgICAgIFdSSVRFKGxv dXQsRG91dCk7DQogICAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgICBlbmQgaWY7 DQogICAgaWYgUmVhZF9Fbj10cnVlIHRoZW4NCiAgICAgIFdSSVRFKGxvdXQsIiAgIFJlYWRf RW46Iik7DQogICAgICBXUklURShsb3V0LEFkZHJlc3NfcmVhZCk7DQogICAgZW5kIGlmOw0K ICAgIGlmIFdyaXRlX0VuPXRydWUgdGhlbg0KICAgICAgV1JJVEUobG91dCwiICAgV3JpdGVf RW46Iik7DQogICAgICBXUklURShsb3V0LEFkZHJlc3Nfd3JpdGUpOw0KICAgICAgV1JJVEUo bG91dCwiIERpbj0iKTsNCiAgICAgIFdSSVRFKGxvdXQsRGluKTsNCiAgICAgIFdSSVRFTElO RShPVVRQVVQsIGxvdXQpOw0KICAgIGVuZCBpZjsNCiAgICBpZiBJbnZfRW49dHJ1ZSB0aGVu DQogICAgICBXUklURShsb3V0LCIgICBJbnZfRW46Iik7DQogICAgICBXUklURShsb3V0LEFk ZHJlc3NfcmVhZCk7DQogICAgICBXUklURShsb3V0LCIsIGFkZHJlc3NfbWFzazoiKTsNCiAg ICAgIFdSSVRFKGxvdXQsQWRkcmVzc19NYXNrKTsNCiAgICBlbmQgaWY7DQogICAgaWYgRnJl ZXplX0VuPXRydWUgdGhlbg0KICAgICAgV1JJVEUobG91dCwiICAgRnJlZXplX0VuOiIpOw0K ICAgICAgV1JJVEUobG91dCxBZGRyZXNzX3JlYWQpOw0KICAgICAgV1JJVEUobG91dCwiLCBh ZGRyZXNzX21hc2s6Iik7DQogICAgICBXUklURShsb3V0LEFkZHJlc3NfTWFzayk7DQogICAg ZW5kIGlmOw0KICAgIFdSSVRFTElORShPVVRQVVQsIGxvdXQpOw0KICAgIFdSSVRFKGxvdXQs IiAiKTsNCiAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgZW5kOw0KDQpiZWdpbg0K DQogLS0gSW5zdGFudGlhdGUgdGhlIHRlc3RlZCBjaXJjdWl0DQogSWNhY2hlIDogZW50aXR5 IEljYWNoZV90eXBlDQogICBwb3J0IG1hcCgNCiAgICAgRGluID0+IGRpbiwNCiAgICAgRG91 dCA9PiBkb3V0LA0KICAgICBjbGsgPT4gY2xrLA0KICAgICByZXNldCA9PiByZXNldCwNCiAg ICAgSW52X0VuID0+IEludl9FbiwNCiAgICAgUmVhZF9FbiA9PiBSZWFkX0VuLA0KICAgICBX cml0ZV9FbiA9PiBXcml0ZV9FbiwNCiAgICAgRnJlZXplX0VuID0+IEZyZWV6ZV9FbiwNCiAg ICAgQWRkcmVzc19yZWFkID0+IEFkZHJlc3NfcmVhZCwNCiAgICAgQWRkcmVzc193cml0ZSA9 PiBBZGRyZXNzX3dyaXRlLA0KICAgICBBZGRyZXNzX01hc2sgPT4gQWRkcmVzc19NYXNrLA0K ICAgICBJY2FjaGVfaGl0ID0+IEljYWNoZV9oaXQNCiAgICk7DQoNCiBwcm9jZXNzDQogYmVn aW4NCiAgIERpbjw9KG90aGVycz0+JzAnKTsNCi0tIGluaXQvcmVzZXQgOg0KICAgcHJpbnQ7 DQogICByZXNldDw9dHJ1ZTsNCiAgIHdhaXQgZm9yIDEwIG5zOw0KICAgcHJpbnQ7DQogICBy ZXNldDw9ZmFsc2U7DQogICB3YWl0IGZvciAxMCBuczsNCiAgIHByaW50Ow0KDQotLSBiZWdp biB0aGUgc2ltdWxhdGlvbiBib2R5IDoNCg0KICAgY2xrPD10cnVlOyAgICAgICAgLS0gcmlz aW5nIGVkZ2UNCiAgIGN5Y2xlOj1jeWNsZSsxOw0KICAgd2FpdCBmb3IgMTAgbnM7ICAgLS0g bGV0IHRoZSBjaXJjdWl0IGRvIHRoZSB3b3JrDQogICBjbGs8PWZhbHNlOyAgICAgICAtLSBm YWxsaW5nIGVkZ2UNCiAgIHdhaXQgZm9yIDEwIG5zOyAgIC0tIGxlYXZlIHNvbWUgdGltZSB0 byByZWFjdA0KICAgcHJpbnQ7ICAgICAgICAgICAgLS0gYmUgaGFwcHkNCiAgIC0tIG5vdyBj aGFuZ2UgdGhlIHBhcmFtZXRlcnMNCiAgIA0KDQotLSAgICBmb3IgYXplcnR5IGluIDAgdG8g MTAgbG9vcA0KLS0gICAgICBjbGs8PScxJzsNCi0tICAgICAgd2FpdCBmb3IgMTAgbnM7DQot LSAgICAgIGNsazw9JzAnOw0KLS0gICAgICB3YWl0IGZvciAxMCBuczsNCi0tICAgICAgY3lj bGU6PWN5Y2xlKzE7DQotLSAgICAgIHByaW50Ow0KLS0gICAgZW5kIGxvb3A7DQoNCiAgIHdh aXQ7IC0tIHN0b3AgdGhlIHNpbXVsYXRpb24NCiBlbmQgcHJvY2VzczsNCg0KZW5kIHRlc3Qx Ow0K --------------51B191A8188F551FD854BE27-- From Colin Marquardt Tue Oct 3 05:22:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11415 for ; Wed, 4 Oct 2000 05:17:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:58 +0200 (MEST) Received: (qmail 27320 invoked by uid 0); 3 Oct 2000 03:36:17 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 3 Oct 2000 03:36:17 -0000 X-eGroups-Return: sentto-1101623-963-970544169-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 03 Oct 2000 03:36:14 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 03:36:08 -0000 Received: (qmail 2939 invoked from network); 3 Oct 2000 03:36:08 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 3 Oct 2000 03:36:08 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 3 Oct 2000 03:36:08 -0000 Received: from morphin.marquardt-home.de (e176.nas23.sonic.net [208.201.225.176]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA29632 for ; Tue, 3 Oct 2000 05:35:57 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gIeo-0000T5-00 for ; Mon, 02 Oct 2000 20:22:18 -0700 To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <20001002140903.43869@thrai.stud.uni-hannover.de> X-Now-Playing: Pakeni's Detergent Bubble Bath - Reanimate The Way In-Reply-To: Michael Riepe's message of "Mon, 2 Oct 2000 14:09:03 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 51 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 02 Oct 2000 20:22:17 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e72609839e38696c558535edd5ba90f3 Status: R X-Status: N Hi,

* Michael Riepe <michael@stud.uni-hannover.de> writes:

> I also changed std_logic to std_ulogic in the next version; the
> arguments in the FAQ convinced me.

Makes us non-compliant to the RMM though, but that doesn't really
matter I guess.

>       entity blah is
>             port (Rst : boolean);
>       end blah;

Exactly. Only at the top level this will be converted to a
std_ulogic, where it will probably have negative logic.

> And what about vectors?

Normally vectors are things which one usually expresses as
std_(u)logic_vector. Signals like CS, WE, DIR, ENA should be boolean
(and thus positive logic!) until they go out of the chip, and are
usually grouped with records.

At work, we have convenience packages which allow handling of
boolean vectors and much more, but they are proprietary. :-(

I cannot really think of a case where I used a boolean vector...

>> fixed value. And of course, any signal should be positive logic
>> (internally).

> As long as the synthesis tool groks it and does the right thing...

They normally do. At least, we *have* had tapeouts! :-)

>> | NADDRS : integer := 27; -- number of address bits (32 - 5) => 4 GByte
>>
>> I would rather use natural instead of integer here. natural is
>> restricted to positive values by default, which an address is
>> too. This will also help in situations where conversion is required
>> (no need for the "unsigned" specifier).

> You still need conversions for the address itself -- this is only the
> *length* of the address.  You're right, though -- no array can have a
> negative number of elements...

Oh yes, sure, I was only talking about the NADDRS type itself.

Cheers,
  Colin
 From Colin Marquardt Tue Oct 3 05:41:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11422 for ; Wed, 4 Oct 2000 05:17:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:59 +0200 (MEST) Received: (qmail 27549 invoked by uid 0); 3 Oct 2000 03:39:52 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 3 Oct 2000 03:39:52 -0000 X-eGroups-Return: sentto-1101623-964-970544284-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 03 Oct 2000 03:39:51 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 03:38:04 -0000 Received: (qmail 7675 invoked from network); 3 Oct 2000 03:38:04 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 3 Oct 2000 03:38:04 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 3 Oct 2000 03:38:03 -0000 Received: from morphin.marquardt-home.de (e176.nas23.sonic.net [208.201.225.176]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA00102 for ; Tue, 3 Oct 2000 05:37:51 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gIx7-0000Tc-00 for ; Mon, 02 Oct 2000 20:41:13 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> X-Now-Playing: Sentenced's North From Here - Awaiting The Winter Frost In-Reply-To: Michael Riepe's message of "Mon, 2 Oct 2000 14:53:09 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 25 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 02 Oct 2000 20:41:13 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a5065aa40e30e3a01e023979158cd6ee Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> On Sun, Oct 01, 2000 at 07:39:20PM -0700, Colin Marquardt wrote:
>> A colleague has written his diploma thesis about the speed of
>> different coding styles in some tools. I will ask him if this is
>> publicly accessible. (It will be in German though... :-( )

> Her damit ;)  URL?

Forgot to ask him today... :-(

> [...]
>> I guess it really makes sense to have a world-accessible CVS
>> repository. sourceforge.net was already mentioned. (And btw, I hate
>> this eGroups banners. Can we please move the list to sourceforge
>> too?)

> Agreed, eGroups sucks.  I don't like remote CVS, though -- multiple
> repositories confuse me, and I already have two or three of them.

What other suggestion do you have for code then? Sending it by mail
is not really feasible...

Cheers,
  Colin
 From Colin Marquardt Tue Oct 3 05:45:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11425 for ; Wed, 4 Oct 2000 05:17:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:17:59 +0200 (MEST) Received: (qmail 21597 invoked by uid 0); 3 Oct 2000 03:42:02 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 3 Oct 2000 03:42:02 -0000 X-eGroups-Return: sentto-1101623-965-970544516-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 03 Oct 2000 03:42:00 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 03:41:54 -0000 Received: (qmail 17440 invoked from network); 3 Oct 2000 03:41:54 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Oct 2000 03:41:54 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 3 Oct 2000 03:41:53 -0000 Received: from morphin.marquardt-home.de (e176.nas23.sonic.net [208.201.225.176]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA00986 for ; Tue, 3 Oct 2000 05:41:43 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gJ0r-0000To-00 for ; Mon, 02 Oct 2000 20:45:05 -0700 To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> X-Now-Playing: Keimzeit's Primeln und Elefanten - Lisa In-Reply-To: Yann Guidon's message of "Tue, 03 Oct 2000 02:18:37 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 7 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 02 Oct 2000 20:45:05 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8535ca27c23ad5f08552b41f0e0de6d9 Status: R X-Status: N * Yann Guidon <whygee@f-cpu.org> writes:

> Can somebody correct the declaration of the addresses ?
> Colin, what was exactly the trouble with the vectors ?
> When done, please post the updated file.

No, it is okay like that. Just I wanted it. :-)
 From Colin Marquardt Tue Oct 3 05:51:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11429 for ; Wed, 4 Oct 2000 05:18:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:00 +0200 (MEST) Received: (qmail 32707 invoked by uid 0); 3 Oct 2000 03:47:45 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 3 Oct 2000 03:47:45 -0000 X-eGroups-Return: sentto-1101623-966-970544860-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 03 Oct 2000 03:47:43 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 03:47:40 -0000 Received: (qmail 7555 invoked from network); 3 Oct 2000 03:47:39 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 3 Oct 2000 03:47:39 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 3 Oct 2000 03:47:39 -0000 Received: from morphin.marquardt-home.de (e176.nas23.sonic.net [208.201.225.176]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA02336 for ; Tue, 3 Oct 2000 05:47:36 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gJ6k-0000Tv-00 for ; Mon, 02 Oct 2000 20:51:10 -0700 To: f-cpu@egroups.com X-Now-Playing: Die Apokalyptischen Reiter's Allegro Barbaro - Heavy Metal X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. In-Reply-To: Yann Guidon's message of "Tue, 03 Oct 2000 04:24:30 +0100" Message-ID: Lines: 77 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 02 Oct 2000 20:51:10 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [comp.lang.verilog] c compiler for embedded CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ba7d3915080e5c3d2736b3e4d16adc80 Status: R X-Status: N Hi,

just a forward, I didn't look at the docs...

From: Dave Tweed <dtweed@acm.org>
Subject: Re: c compiler for embedded CPU
Newsgroups: comp.lang.verilog
Date: Mon, 02 Oct 2000 08:13:08 -0400
Organization: almost none
Message-ID: <39D87BD4.907F32CF@acm.org>
Reply-To: dtweed@acm.org
X-Trace: 8kFfzdcaG18Sq/4qs7wbgDNMH92sigdF2mFLPP/yie8=
X-Complaints-To: abuse@rcn.com
NNTP-Posting-Date: 2 Oct 2000 12:13:04 GMT
X-Accept-Language:  en
X-Mailer:  Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)

stefaan vanheesbeke wrote:
> For my own hown build CPU (implemented in an FPGA), I'm looking to write or
> modify a simple C compiler. I have already build an assembler, but it is too
> much work to write programs with it.
>
> Can somebody point me to some C compiler stuff (written in C or C++ if
> possible)?

In a recent 3-part Circuit Cellar series, Jan Gray did exactly what you're
doing. And you're in luck, the series was posted on the web in both HTML
and PDF.

Issue: 116 March 2000
Page: 26
Author: Jan Gray
Title: Building a RISC System in an FPGA
Subtitle: Part 1: Tools, Instruction Set, and Datapath
Abstract: To kick off this three-part article, Jan's going to port a C
      compiler, design an instruction set, write an assembler and simulator,
      and design the CPU datapath. Get reading, you've only got a month
      before your connecting article arrives!
Download: gray.zip
HTML: http://www.circuitcellar.com/pastissues/articles/gray116/article.htm
PDF: http://www.circuitcellar.com/pastissues/articles/gray116/gray116.pdf

Issue: 117 April 2000
Page: 20
Author: Jan Gray
Title: Building a RISC System in an FPGA
Subtitle: Part 2: Pipeline and Control Unit Design
Abstract: In Part 1, Jan introduced his plan to build a pipelined 16-bit RISC
      processor and System-on-a-Chip in an FPGA. This month, he explores the
      CPU pipeline and designs the control unit. Listen up, because next
      month, he'll tie it all together.
Download: gray.zip
HTML: http://www.circuitcellar.com/pastissues/articles/gray117/article.htm
PDF: http://www.circuitcellar.com/pastissues/articles/gray117/gray117.pdf

Issue: 118 May 2000
Page: 36
Author: Jan Gray
Biography: Jan Gray is a software developer whose products include a leading
      C++ compiler. He has been building FPGA processors and systems since
      1994, and now he designs for Gray Research LLC.
Email: jan@fpgacpu.org
Title: Building a RISC System in an FPGA
Subtitle: Part 3: System-on-a-Chip Design
Abstract: Now that the xr16 RISC processor is complete, it's time to tie
      everything together and wrap up this series. In this final part, Jan
      designs a demo system that includes an on-chip bus, memory controller,
      video controller, and peripherals.
HTML: http://www.circuitcellar.com/pastissues/articles/gray118/article.htm
PDF: http://www.circuitcellar.com/pastissues/articles/gray118/gray118.pdf

To learn more about Circuit Cellar, visit <http://www.circuitcellar.com>,
or browse my online index to the magazine at
   <http://www.dtweed.com/cajindex/index.htm>

-- Dave Tweed
   Circuit Cellar archivist
 From Yann Guidon Tue Oct 3 07:03:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11432 for ; Wed, 4 Oct 2000 05:18:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:01 +0200 (MEST) Received: (qmail 22913 invoked by uid 0); 3 Oct 2000 03:59:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx19.rz2.gmx.net with SMTP; 3 Oct 2000 03:59:32 -0000 X-eGroups-Return: sentto-1101623-967-970545567-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 03 Oct 2000 03:59:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 03:59:26 -0000 Received: (qmail 32339 invoked from network); 3 Oct 2000 03:59:26 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Oct 2000 03:59:26 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 3 Oct 2000 03:59:25 -0000 Received: from f-cpu.org (nas4-111.ras.club-internet.fr [195.36.203.111]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA00303 for ; Tue, 3 Oct 2000 05:59:22 +0200 (MET DST) Message-ID: <39D968B2.748393CE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 06:03:46 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] file i/o Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fe3d32bd92ab9877b3e90353fd3fe3f7 Status: R X-Status: N hi,

i can't find the correct VHDL93 syntax for reading files,
neither in my books or in example files. i can make something
anyway but it compiles with the -87 option with Simili.
If you have a quick hint, please post (before i find it myself).

read you soon (tomorrow)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Colin Marquardt Tue Oct 3 05:38:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11435 for ; Wed, 4 Oct 2000 05:18:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:02 +0200 (MEST) Received: (qmail 16760 invoked by uid 0); 3 Oct 2000 04:04:52 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 3 Oct 2000 04:04:52 -0000 X-eGroups-Return: sentto-1101623-968-970545871-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hm.egroups.com with NNFMP; 03 Oct 2000 04:04:49 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 04:04:31 -0000 Received: (qmail 2661 invoked from network); 3 Oct 2000 04:04:31 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 04:04:31 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 3 Oct 2000 04:04:30 -0000 Received: from morphin.marquardt-home.de (e176.nas23.sonic.net [208.201.225.176]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA06823 for ; Tue, 3 Oct 2000 06:04:28 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gIuG-0000TM-00 for ; Mon, 02 Oct 2000 20:38:16 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <39D8B2BC.1222D68F@f-cpu.org> X-Now-Playing: Arch Enemy's Burning Bridges - The Immortal In-Reply-To: Yann Guidon's message of "Mon, 02 Oct 2000 17:07:24 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 71 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 02 Oct 2000 20:38:15 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d8ad8ef55663553654b5c0df491925b Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

> i have maybe missed a point but i guess that
> array(0 to DBwidth-1) will work, if DBwidth is not defined as generic.
> or ?

If it is generic or not does not matter, but DBwidth has a type, and
that matters. integer will work, but you could have a DBwidth of -42
(b/c of e.g. a typo somewhere) which does not make sense. natural
does only have a positive range, so here the *assignment to DBwidth*
will already fail!  If you have DBwidth as integer, you will only
get an error if you create the array (since the number left of the
"to" is bigger than the right one), not before. There are situations
where this helps a lot.

>> Oh, but with that I mean that it suggests std_logic in favor of
>> std_*u*logic. They don't even consider bit as a useful type :-)
> huh ? so when they have a huge memory array, like 256Mbits, what
> time does it take to simulate this ? :-)

I don't think it takes so much time. It makes a difference in RAM usage
though if you are not careful with signal vs. variable (regardless of
the type). See a recent post from Ben Cohen on comp.lang.vhdl.

>> Can you find a copy of it in your library? Would be a good read
>> (it is by Keating/Bricaud, published by Kluwer IIRC).
> i think that i'll have to wait a bit, i'm mostly broke. I still have
> to finish the books i've already bought. Anywa, a good reference manual

That's why I mention "library". Can't you have guest access to your
universities'?

> might be useful in the near future. I'm seeking a job and i might
> have enough money to buy good books in a month or two.

Declare books as work related! :-)

> oh, just a proposal for the future developments :
> can someone write a summary of all the design rules at the VHDL level ?
> the libraries that can and cannot be used etc...
> it's a matter of 1 KB of text and it will be used and updated
> on the f-cpu site.

Haha, 1k! :-) I can try to start it.

>> repository. sourceforge.net was already mentioned. (And btw, I hate
>> this eGroups banners. Can we please move the list to sourceforge
>> too?)

> there is no list maintainer anymore, the list is going on its way
> for a very long time, and it has become the central point for the project.
> we might lose a lot of people if we move somewhere else.

Hmm, true... But we might auto-subscribe all the current members there...

> OTOH, even though the banners don't disturb me, this is an abvious waste
> of bandwidth.

Full-quoters are much worse, but I lost all hope about quoting when
I came to the US. In Europe they care some, but not over here.

> We could make a f-cpu_vhdl list on sourceforge that will deal only with
> the VHDL aspects of the project. But Sourceforge doesn't garantee that

Hmm, doesn't make much sense I think. Topics are too close to the
real design work.

Cheers,
  Colin
 From Yann Guidon Tue Oct 3 07:16:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11438 for ; Wed, 4 Oct 2000 05:18:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:03 +0200 (MEST) Received: (qmail 11868 invoked by uid 0); 3 Oct 2000 04:12:41 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 3 Oct 2000 04:12:41 -0000 X-eGroups-Return: sentto-1101623-969-970546356-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ch.egroups.com with NNFMP; 03 Oct 2000 04:12:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 04:12:35 -0000 Received: (qmail 23702 invoked from network); 3 Oct 2000 04:12:35 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 04:12:35 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 3 Oct 2000 04:12:34 -0000 Received: from f-cpu.org (nas1-148.ras.club-internet.fr [195.36.192.148]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA21241 for ; Tue, 3 Oct 2000 06:12:31 +0200 (MET DST) Message-ID: <39D96BC7.4456E982@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 06:16:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] [comp.lang.verilog] c compiler for embedded CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b0507bfb52ca8ad5acb48ebf39292d6d Status: R X-Status: N g'night,

Colin Marquardt wrote:
> Hi,
>
> just a forward, I didn't look at the docs...
<snip>

funnily, i had downloaded all the files a few days ago,
after a post on comp.lang.vhdl ...
but all the files are in Verilog.
i gotta read the PDF anyway.

Mr Gray has been on the list for a while,
as he wrote me. Now that the things are heating,
we need more people like him on the list :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Tue Oct 3 08:07:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11453 for ; Wed, 4 Oct 2000 05:18:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:07 +0200 (MEST) Received: (qmail 8718 invoked by uid 0); 3 Oct 2000 05:03:34 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 3 Oct 2000 05:03:34 -0000 X-eGroups-Return: sentto-1101623-970-970549402-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 03 Oct 2000 05:03:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 05:03:21 -0000 Received: (qmail 20334 invoked from network); 3 Oct 2000 05:03:21 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 3 Oct 2000 05:03:21 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 3 Oct 2000 05:03:21 -0000 Received: from f-cpu.org (nas2-204.ras.club-internet.fr [195.36.192.204]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA07786 for ; Tue, 3 Oct 2000 06:54:06 +0200 (MET DST) Message-ID: <39D977AD.326737C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <39D8B2BC.1222D68F@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 07:07:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 733eeef44f5b7e19680e3dbe9ce99328 Status: R X-Status: N hi again,

Colin Marquardt wrote:
> Hi,
> * Yann Guidon <whygee@f-cpu.org> writes:
>
> > i have maybe missed a point but i guess that
> > array(0 to DBwidth-1) will work, if DBwidth is not defined as generic.
> > or ?
>
> If it is generic or not does not matter, but DBwidth has a type, and
> that matters. integer will work, but you could have a DBwidth of -42
> (b/c of e.g. a typo somewhere) which does not make sense. natural
> does only have a positive range, so here the *assignment to DBwidth*
> will already fail!  If you have DBwidth as integer, you will only
> get an error if you create the array (since the number left of the
> "to" is bigger than the right one), not before. There are situations
> where this helps a lot.
this makes sense, right.

> >> Oh, but with that I mean that it suggests std_logic in favor of
> >> std_*u*logic. They don't even consider bit as a useful type :-)
> > huh ? so when they have a huge memory array, like 256Mbits, what
> > time does it take to simulate this ? :-)
> I don't think it takes so much time. It makes a difference in RAM usage
> though if you are not careful with signal vs. variable (regardless of
> the type). See a recent post from Ben Cohen on comp.lang.vhdl.
mmm i wasn't aware of this one...

> >> Can you find a copy of it in your library? Would be a good read
> >> (it is by Keating/Bricaud, published by Kluwer IIRC).
> > i think that i'll have to wait a bit, i'm mostly broke. I still have
> > to finish the books i've already bought. Anywa, a good reference manual
> That's why I mention "library". Can't you have guest access to your
> universities'?
well, my university is a litterary one, the "CS" part of the library
is not fantastic. I better go to Jussieu but i prefer to "own" books.
having three different books (including Nicolas') was useful to get
started in the hard stuff because they explain almost the same things
in different ways.

> > might be useful in the near future. I'm seeking a job and i might
> > have enough money to buy good books in a month or two.
> Declare books as work related! :-)
well, if i get a job as game programmer, it will be hard to do it ;-)

> > oh, just a proposal for the future developments :
> > can someone write a summary of all the design rules at the VHDL level ?
> > the libraries that can and cannot be used etc...
> > it's a matter of 1 KB of text and it will be used and updated
> > on the f-cpu site.
> Haha, 1k! :-) I can try to start it.
or maybe you can overcomment the description file i recently posted.
like "this line because this or that" etc...

> >> repository. sourceforge.net was already mentioned. (And btw, I hate
> >> this eGroups banners. Can we please move the list to sourceforge
> >> too?)
> > there is no list maintainer anymore, the list is going on its way
> > for a very long time, and it has become the central point for the project.
> > we might lose a lot of people if we move somewhere else.
> Hmm, true... But we might auto-subscribe all the current members there...
not against their will.

> > OTOH, even though the banners don't disturb me, this is an abvious waste
> > of bandwidth.
> Full-quoters are much worse, but I lost all hope about quoting when
> I came to the US. In Europe they care some, but not over here.
heh.

> > We could make a f-cpu_vhdl list on sourceforge that will deal only with
> > the VHDL aspects of the project. But Sourceforge doesn't garantee that
> Hmm, doesn't make much sense I think. Topics are too close to the
> real design work.
so what do you propose ? what do you wish ?
what was the question, btw ? banners ? (iirc)
IIRC egroups will shut them up if we pay a fee.
but that's useless, i think (full quoters are worse ;-D)

read you soon,
> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Tue Oct 3 08:26:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11457 for ; Wed, 4 Oct 2000 05:18:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:09 +0200 (MEST) Received: (qmail 32132 invoked by uid 0); 3 Oct 2000 05:22:11 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 3 Oct 2000 05:22:11 -0000 X-eGroups-Return: sentto-1101623-971-970550524-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 03 Oct 2000 05:22:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 05:22:04 -0000 Received: (qmail 17319 invoked from network); 3 Oct 2000 05:22:04 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 3 Oct 2000 05:22:04 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 3 Oct 2000 05:22:03 -0000 Received: from f-cpu.org (nas2-204.ras.club-internet.fr [195.36.192.204]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA07414 for ; Tue, 3 Oct 2000 07:22:00 +0200 (MET DST) Message-ID: <39D97C10.3755A21F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 07:26:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Advanced Concepts in VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ae054985579e6ccec0767b9c42821ad Status: R X-Status: N http://www.cedcc.psu.edu/ee497f/rassp_13/index.htm

has some interesting samples :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Colin Marquardt Tue Oct 3 09:18:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11465 for ; Wed, 4 Oct 2000 05:18:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:10 +0200 (MEST) Received: (qmail 19092 invoked by uid 0); 3 Oct 2000 07:21:36 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 3 Oct 2000 07:21:36 -0000 X-eGroups-Return: sentto-1101623-972-970557692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 03 Oct 2000 07:21:34 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 07:21:31 -0000 Received: (qmail 10277 invoked from network); 3 Oct 2000 07:21:31 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Oct 2000 07:21:31 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 3 Oct 2000 07:21:30 -0000 Received: from morphin.marquardt-home.de (d190.nas21.sonic.net [209.204.136.190]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id JAA10418 for ; Tue, 3 Oct 2000 09:21:26 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gMLA-0001Ui-00 for ; Tue, 03 Oct 2000 00:18:16 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <39D8B2BC.1222D68F@f-cpu.org> <39D977AD.326737C@f-cpu.org> X-Now-Playing: Pungent Stench's Been Caught Buttering - And Only Hunger Remains In-Reply-To: Yann Guidon's message of "Tue, 03 Oct 2000 07:07:41 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 21 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Oct 2000 00:18:15 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 333d78cb20b9187d112f65e6ef6924a7 Status: R X-Status: N Hi,

* Yann Guidon <whygee@f-cpu.org> writes:

>> Hmm, true... But we might auto-subscribe all the current members there...
> not against their will.

You are probably right. But I have seen such a thing once, with the
proper announcements before and the deletion of the other list
shortly after... But still, it is probably too much of a hassle.

> so what do you propose ? what do you wish ?
> what was the question, btw ? banners ? (iirc)

The real question was about a CVS repository for code (and docs IMO)
on e.g. sourceforge. Which I still think makes sense.

Cheers,
  Colin

--
From Kai Wetzel Tue Oct 3 17:01:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11507 for ; Wed, 4 Oct 2000 05:18:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:21 +0200 (MEST) Received: (qmail 15491 invoked by uid 0); 3 Oct 2000 13:03:55 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 3 Oct 2000 13:03:55 -0000 X-eGroups-Return: sentto-1101623-973-970578223-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 03 Oct 2000 13:03:49 -0000 X-Sender: k.wetzel@welfen-netz.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 13:03:43 -0000 Received: (qmail 16480 invoked from network); 3 Oct 2000 13:03:42 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 3 Oct 2000 13:03:42 -0000 Received: from unknown (HELO welfen-netz.com) (193.194.148.20) by mta2 with SMTP; 3 Oct 2000 13:03:42 -0000 Received: from welfen-netz.com [193.194.149.183] by welfen-netz.com [193.194.148.21] with SMTP (MDaemon.v2.8.5.0.R) for ; Tue, 03 Oct 2000 15:02:28 +0200 Sender: kai@pop.gmx.net Message-ID: <39D9F4E0.D6437165@welfen-netz.com> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> <20001002153050.57678@thrai.stud.uni-hannover.de> X-MDaemon-Deliver-To: f-cpu@egroups.com X-Return-Path: k.wetzel@welfen-netz.com From: Kai Wetzel MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 17:01:52 +0200 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 97d140c4d53303a6daf5165bb08ccad7 Status: R X-Status: N Michael Riepe wrote:
>
> On Sun, Oct 01, 2000 at 01:23:42AM -0300, Jecel Assumpcao Jr wrote:
> > This is an interesting web page:
> >
> >    http://www.andraka.com/multipli.htm
>
> Pretty good overview.  What I had in mind is a combination of several
> items from this list: a carry-save multiplier using a modification of
> booth's algorithm and precomputed partial products as the basic (8x8)
> unit -- this is the hard part --, and wallace trees for larger products.
> By adding partial products the right way, we automatically get 16-bit,
> 32-bit and 64-bit products in later pipeline stages -- SIMD made easy :)
> In other words, it's a pretty big `full adder farm'.  Expected throughput:
> 1 operation/cycle, latency: less than 12 cycles for a full 64-bit product
> (SIMD operations would be even faster).

How many gates to you consider per cycle ?

> A simplified version using serial shift-and-add 8x8 multipliers might
> save some space, but has lower throughput -- something like one operation
> every 3 or 4 cycles, which is still pretty good IMHO -- and slightly
> higher latencies.
[...]
kai

 From Michael Riepe Tue Oct 3 04:10:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11510 for ; Wed, 4 Oct 2000 05:18:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:21 +0200 (MEST) Received: (qmail 32746 invoked by uid 0); 3 Oct 2000 13:28:13 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 3 Oct 2000 13:28:13 -0000 X-eGroups-Return: sentto-1101623-974-970579683-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 03 Oct 2000 13:28:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 13:28:03 -0000 Received: (qmail 25470 invoked from network); 3 Oct 2000 13:28:02 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 3 Oct 2000 13:28:02 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.74) by mta3 with SMTP; 3 Oct 2000 13:28:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01478; Tue, 3 Oct 2000 04:10:10 +0200 Message-ID: <20001003041009.03040@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D933ED.FE44813B@f-cpu.org>; from Yann Guidon on Tue, Oct 03, 2000 at 02:18:37AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 04:10:09 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f87f8b450243116a3c85e2225c005f9b Status: R X-Status: N On Tue, Oct 03, 2000 at 02:18:37AM +0100, Yann Guidon wrote:

> Michael :
> > > > (it may be wise to add another
> > > > line that invalidates the whole cache in that case -- I had that in an
> > > > earlier version which is still in my CVS, fortunately).
> > > total invalidate should be done by the reset line, no ? :-)
> > An asynchronous reset should only happen during initialization (or when
> > the user hits the Big Red Switch).
>
> an Inv_En<=true with the Address_mask<=(others=>'1') should do the trick, no ?

In my version, that would be (others => '0').  Didn't read yours yet,
sorry.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Oct 3 04:07:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11513 for ; Wed, 4 Oct 2000 05:18:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:22 +0200 (MEST) Received: (qmail 10692 invoked by uid 0); 3 Oct 2000 13:28:20 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 3 Oct 2000 13:28:20 -0000 X-eGroups-Return: sentto-1101623-975-970579687-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mq.egroups.com with NNFMP; 03 Oct 2000 13:28:19 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 13:28:07 -0000 Received: (qmail 21404 invoked from network); 3 Oct 2000 13:28:07 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 3 Oct 2000 13:28:07 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.74) by mta3 with SMTP; 3 Oct 2000 13:28:04 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01467; Tue, 3 Oct 2000 04:07:07 +0200 Message-ID: <20001003040707.25415@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D7FA46.90188C09@f-cpu.org> <20001002143649.04675@thrai.stud.uni-hannover.de> <39D92415.95BBCA58@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D92415.95BBCA58@f-cpu.org>; from Yann Guidon on Tue, Oct 03, 2000 at 01:11:01AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 04:07:07 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bedffcc07bbae2f5fa2772faed50502d Status: R X-Status: N On Tue, Oct 03, 2000 at 01:11:01AM +0100, Yann Guidon wrote:

> > A simplified version using serial shift-and-add 8x8 multipliers might
> > save some space, but has lower throughput -- something like one operation
> > every 3 or 4 cycles, which is still pretty good IMHO -- and slightly
> > higher latencies.
> well, this is something interesting for the division, instead.

Later... I do not support multitasking very well ;)

SIMD division is particularly hard to implement...

[...]
> the time necessary for the transaction can be so long that the line that you
> reserved for writing may be reused. This increases the cache thrashing.
> Remember that a full transaction can take tens of cycles and if you have
> 64 cache lines, only one half will be really used, the others will remain
> reserved. ok, 64 lines is not much but it serves as example.

A line that is going to be re-filled *is* reserved -- unless you delay
the LRU lookup (and final selection of the cache line) until the line
is finally written.  This is the other alternative, and I will have to
think it over.  But the sequence

      LRU lookup => line is selected (and reserved)
      memory access (slow)
      fill line, LRU update

definitely doesn't make sense, unless the cache is blocked during the
whole process.

> keeping the line number inside the cache allows any write to really use the
> Least Recently Used line, with less thrashing. It also keeps the cache size
> independent from the other parameters of the chip, so it can be interchanged
> at will.

Hmm.  Instead of

      select line to flush (LRU lookup + update)
      invalidate line
      fetch new data @addr (slow)
      revalidate line

we could do

      fetch new data @addr into temporary buffer (slow)
      select line to flush (LRU lookup + update)
      fill line from temporary buffer (atomically)

which is (slightly) better in terms of cache line reusal.  But there is
one drawback:  it is possible that concurrent read and write requests
collide at the LRU unit, because they both attempt to update it.  And we
can't delay the LRU update until the read happens because a second
write would overwrite the results of the first one if there's no read
(and LRU update) between them.

[...]
> > An asynchronous reset should only happen during initialization (or when
> > the user hits the Big Red Switch).
>
> or maybe this could be the reverse ?
> cache init would be triggered during power-up (using some hardwired
> firmware in ROM or a Finite State Machine that would trigger the
> necessary reset signals in the right order)

Of course we can reset the LRU unit to `all 0'1' and use a FSM to
initialize it.  This will be much cheaper than 2^n registers with 2^n
different initialization states (the wiring would be a mess!).

The other open question is whether we use a synchronous or asynchronous
reset internally.  Of course we can put both of them into the VHDL
sources until we make the final decision...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Oct 3 16:29:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11561 for ; Wed, 4 Oct 2000 05:18:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:36 +0200 (MEST) Received: (qmail 22826 invoked by uid 0); 3 Oct 2000 19:27:27 -0000 Received: from fj.egroups.com (208.50.99.207) by mx06.rz2.gmx.net with SMTP; 3 Oct 2000 19:27:27 -0000 X-eGroups-Return: sentto-1101623-977-970601237-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 03 Oct 2000 19:27:23 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 19:27:17 -0000 Received: (qmail 27815 invoked from network); 3 Oct 2000 19:27:17 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Oct 2000 19:27:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.223) by mta1 with SMTP; 3 Oct 2000 19:27:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00616; Tue, 3 Oct 2000 16:29:50 +0200 Message-ID: <20001003162949.10349@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Mon, Oct 02, 2000 at 08:41:13PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 16:29:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1a992b71c056c56d83512f9277cd27be Status: R X-Status: N On Mon, Oct 02, 2000 at 08:41:13PM -0700, Colin Marquardt wrote:
[...]
> > Agreed, eGroups sucks.  I don't like remote CVS, though -- multiple
> > repositories confuse me, and I already have two or three of them.
>
> What other suggestion do you have for code then? Sending it by mail
> is not really feasible...

I really do recommend CVS for every project that consist of 3 or more
files.  I've used it for more than five years now and I'm quite satisfied.
You may have noticed that I checked in my icache.vhdl, too :)
I just don't like _remote_ repositories, because

      1) I have a dial-up connection.
      2) I don't have direct access to them (can't move/rename files internally).
      3) It's hard to keep two repositories in sync.
      4) I always forget to change CVSROOT ;)

But I guess I can live with it somehow.  I have to, after all.

NB: I have a local repository that contains >800 MByte of sources for
my own Linux system.  I never installed any binary distributions after
the initial SLS in '92 :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Tue Oct 3 19:38:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11564 for ; Wed, 4 Oct 2000 05:18:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:36 +0200 (MEST) Received: (qmail 28919 invoked by uid 0); 3 Oct 2000 19:27:27 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 3 Oct 2000 19:27:27 -0000 X-eGroups-Return: sentto-1101623-976-970601126-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mo.egroups.com with NNFMP; 03 Oct 2000 19:25:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 19:25:25 -0000 Received: (qmail 10459 invoked from network); 3 Oct 2000 19:25:25 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 19:25:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.223) by mta1 with SMTP; 3 Oct 2000 19:25:22 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01190; Tue, 3 Oct 2000 19:38:40 +0200 Message-ID: <20001003193839.21479@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> <20001002153050.57678@thrai.stud.uni-hannover.de> <39D9F4E0.D6437165@welfen-netz.com> X-Mailer: Mutt 0.84e In-Reply-To: <39D9F4E0.D6437165@welfen-netz.com>; from Kai Wetzel on Tue, Oct 03, 2000 at 05:01:52PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 19:38:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4717bd35d75dbcec14896146a545195 Status: R X-Status: N On Tue, Oct 03, 2000 at 05:01:52PM +0200, Kai Wetzel wrote:

> > Pretty good overview.  What I had in mind is a combination of several
> > items from this list: a carry-save multiplier using a modification of
> > booth's algorithm and precomputed partial products as the basic (8x8)
> > unit -- this is the hard part --, and wallace trees for larger products.
> > By adding partial products the right way, we automatically get 16-bit,
> > 32-bit and 64-bit products in later pipeline stages -- SIMD made easy :)
> > In other words, it's a pretty big `full adder farm'.  Expected throughput:
> > 1 operation/cycle, latency: less than 12 cycles for a full 64-bit product
> > (SIMD operations would be even faster).
>
> How many gates to you consider per cycle ?

As few as possible :)  I estimated 4 cycles for the 8x8 multiplier,
plus 2 cycles for each wallace tree, probably 3 for the last one.
Plus an additional cycle sacrificed to Mr. Murphy :)

The 8x8 multiplier consists of 1-bit full adders (2 gates) with input
muxes (3 gates) and an xor (1 gate) and calculates 3 bits at once.
That's 6 gates per stage, 3 stages total, plus one stage for precomputing
a single partial product (just an ordinary 8-bit adder).

Do you think I'm too optimistic?  Even if the 8x8 multiplication took
6 cycles, and each of the wallace trees took 3 cycles, the whole unit
would have a latency of 6 + 3 + 3 + 3 = 15 cycles for a 64-bit product,
which is still pretty good IMHO.

In case you wonder how it works... consider booth's algorithm
(y=a*b, a shown as `current bit : previous bit'):

     a      operations
    0:0     shift
    0:1     +b, shift
    1:0     -b, shift
    1:1     shift

Now let's consume 2 bits at once:

     a      operations              ; resulting operation
    00:0    shift twice             ; y=4*y
    00:1    +b, shift twice         ; y=4*y+1*b
    01:0    -b, shift, +b, shift    ; y=4*y+1*b
    01:1    shift, +b, shift        ; y=4*y+2*b
    10:0    shift, -b, shift        ; y=4*y-2*b
    10:1    +b, shift, -b, shift    ; y=4*y-1*b
    11:0    -b, shift twice         ; y=4*y-1*b
    11:1    shift twice             ; y=4*y

Note that `2*b' doesn't need any calculation at all, it's a hardwired
left shift.  Now, the 3-bit version:

      a     operations                      ; resulting operation
    000:0   shift(3)                        ; y=8*y
    000:1   +b, shift(3)                    ; y=8*y+1*b
    001:0   -b, shift, +b, shift(2)         ; y=8*y+1*b
    001:1   shift, +b, shift(2)             ; y=8*y+2*b
    010:0   shift, -b, shift, +b, shift     ; y=8*y+2*b
    010:1   +b, shift, -b, shift, +b, shift ; y=8*y+3*b
    011:0   -b, shift(2), +b, shift         ; y=8*y+3*b
    011:1   shift(2), +b, shift             ; y=8*y+4*b
    100:0   shift(2), -b, shift             ; y=8*y-4*b
    100:1   +b, shift(2), -b, shift         ; y=8*y-3*b
    101:0   -b, shift, +b, shift, -b, shift ; y=8*y-3*b
    101:1   shift, +b, shift, -b, shift     ; y=8*y-2*b
    110:0   shift, -b, shift(2)             ; y=8*y-2*b
    110:1   +b, shift, -b, shift(2)         ; y=8*y-1*b
    111:0   -b, shift(3)                    ; y=8*y-1*b
    111:1   shift(3)                        ; y=8*y

Here we need the additional adder to pre-calculate `3*b'.  Note that the
`resulting operations' column has a nice regular structure that is easy
to decode.  Also note that the whole unit will have 3 stages, which
results in a 9x9-bit multiplier.  The additional bits can be used to
select signed/unsigned multiplication modes (set it to '0' for unsigned
mode, copy the operand's MSBits for signed mode -- this costs only two
and gates).  And there's one more advantage: if we preload `y' with a
value != 0, we get the `mac' and `smac' instructions for free.

There are some variants that have the same capabilities.  I already
mentioned the serialized version which takes 1/3 of the space (considering
only the basic 8x8 multipliers) but has reduced throughput (well, I could
live with that).  With `regular' 1xn-bit `booth-style' multipliers forming
a carry-save multiplier the input muxes are less heavy and we don't have
to precalculate anything, and we may probably get 2 product bits per stage
(which means we need 5 stages for 9x9).  I think 2xn-bit multipliers
(the second example above) will need 1 stage each, which also results
in 5 stages for 9x9.  This is still better than the 6 cycles from the
`pessimistic' calculation above.

<masochism>
Now flame me, please ;)
</masochism>
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Tue Oct 3 16:08:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11567 for ; Wed, 4 Oct 2000 05:18:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:38 +0200 (MEST) Received: (qmail 22890 invoked by uid 0); 3 Oct 2000 19:27:29 -0000 Received: from fj.egroups.com (208.50.99.207) by mx06.rz2.gmx.net with SMTP; 3 Oct 2000 19:27:29 -0000 X-eGroups-Return: sentto-1101623-978-970601241-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 03 Oct 2000 19:27:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 19:27:21 -0000 Received: (qmail 16299 invoked from network); 3 Oct 2000 19:27:20 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 19:27:20 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.223) by mta1 with SMTP; 3 Oct 2000 19:27:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00563; Tue, 3 Oct 2000 16:08:12 +0200 Message-ID: <20001003160811.18217@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <20001002140903.43869@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Mon, Oct 02, 2000 at 08:22:17PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 16:08:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 33e0737ccf3a9ccd3ae9347d42cde835 Status: R X-Status: N On Mon, Oct 02, 2000 at 08:22:17PM -0700, Colin Marquardt wrote:
> Hi,
>
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> > I also changed std_logic to std_ulogic in the next version; the
> > arguments in the FAQ convinced me.
>
> Makes us non-compliant to the RMM though, but that doesn't really
> matter I guess.

We can revert that later when we worked out all errors, don't we?
`for f in *.vhdl; do some-sed-magic <$f >$f.new; done'.
Or we use a package to define symbolic names and use them all over the
place.

> >       entity blah is
> >             port (Rst : boolean);
> >       end blah;
>
> Exactly. Only at the top level this will be converted to a
> std_ulogic, where it will probably have negative logic.

Automagically?

> > And what about vectors?
>
> Normally vectors are things which one usually expresses as
> std_(u)logic_vector. Signals like CS, WE, DIR, ENA should be boolean
> (and thus positive logic!) until they go out of the chip, and are
> usually grouped with records.

I.c.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Wed Oct 4 00:40:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11585 for ; Wed, 4 Oct 2000 05:18:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:42 +0200 (MEST) Received: (qmail 25730 invoked by uid 0); 3 Oct 2000 21:35:49 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 3 Oct 2000 21:35:49 -0000 X-eGroups-Return: sentto-1101623-979-970608946-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 03 Oct 2000 21:35:48 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 21:35:46 -0000 Received: (qmail 28659 invoked from network); 3 Oct 2000 21:35:45 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Oct 2000 21:35:45 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 3 Oct 2000 21:35:45 -0000 Received: from f-cpu.org (nas1-235.aub.club-internet.fr [195.36.150.235]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA09404 for ; Tue, 3 Oct 2000 23:35:42 +0200 (MET DST) Message-ID: <39DA6045.FEE3A485@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <39D8B2BC.1222D68F@f-cpu.org> <39D977AD.326737C@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 23:40:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cb1c1c74752674a7116adc4a9b688238 Status: R X-Status: N hi,

Colin Marquardt wrote:
> Hi,
>
> * Yann Guidon <whygee@f-cpu.org> writes:
> >> Hmm, true... But we might auto-subscribe all the current members there...
> > not against their will.
> You are probably right. But I have seen such a thing once, with the
> proper announcements before and the deletion of the other list
> shortly after... But still, it is probably too much of a hassle.
this looks a bit like Noah's arch, shall we sacrifice the lurkers
or isolate the developers from the crowd ? anyway, we can't remove
the list for the good reason that there is no maintainer anymore ;-)
it will die with egroups.

> > so what do you propose ? what do you wish ?
> > what was the question, btw ? banners ? (iirc)
> The real question was about a CVS repository for code (and docs IMO)
> on e.g. sourceforge. Which I still think makes sense.

for some files, it's possible to put them on a little archive at egroups.
i've already put the F-CPU manual online there. the mailing list itself
is also a good CVS system, without the name, because everything is
archived by egroups so it's possible to keep the current version
up to date from the mails, even though it's not automatic ;-)

I gotta rest, too...
have fun,
> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Michael Riepe Tue Oct 3 16:01:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11588 for ; Wed, 4 Oct 2000 05:18:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:42 +0200 (MEST) Received: (qmail 5560 invoked by uid 0); 3 Oct 2000 21:44:43 -0000 Received: from ef.egroups.com (208.50.144.95) by mx06.rz2.gmx.net with SMTP; 3 Oct 2000 21:44:43 -0000 X-eGroups-Return: sentto-1101623-980-970609473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 03 Oct 2000 21:44:42 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 21:44:30 -0000 Received: (qmail 31798 invoked from network); 3 Oct 2000 21:44:30 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Oct 2000 21:44:30 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.167) by mta1 with SMTP; 3 Oct 2000 21:44:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00542; Tue, 3 Oct 2000 16:01:19 +0200 Message-ID: <20001003160119.51532@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39D9516E.DA1D0A0@f-cpu.org>; from Yann Guidon on Tue, Oct 03, 2000 at 04:24:30AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 16:01:19 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) testbench attempt (+re) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d367603a56d253c970921fad1ddf211 Status: R X-Status: N On Tue, Oct 03, 2000 at 04:24:30AM +0100, Yann Guidon wrote:
[...]
> re-re-reading it later helps me understand better what you meant.
> unfortunately, the precedent cache thrashing remark still applies
> (unless there's a point i still missed).

I don't think that it will thrash much more.  If we have SMT some day,
we need to enlarge the cache anyway.

[...]
> > > btw, have you tested this code (and how) ?
> > It's syntacitically correct (at least Simili doesn't object).
> so, someone else is using it, cool :-)

Yep, but it's hard to boot NT again and again...

> if someone has another VHDL suite, please test our files.
> Simili is not the most solid SW ever, even if it 'works'.

It runs on Losedows, what do you expect? ;)

I downloaded Alliance 4.0.6 yesterday and will try that on Linux
(if I can compile it with XFree86 3.3.5 and OpenMotif 2.1.30).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Nicolas Boulay Tue Oct 3 23:11:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11594 for ; Wed, 4 Oct 2000 05:18:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:44 +0200 (MEST) Received: (qmail 25952 invoked by uid 0); 3 Oct 2000 22:13:31 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 3 Oct 2000 22:13:31 -0000 X-eGroups-Return: sentto-1101623-981-970611208-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 03 Oct 2000 22:13:28 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:13:27 -0000 Received: (qmail 10113 invoked from network); 3 Oct 2000 22:13:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 3 Oct 2000 22:13:27 -0000 Received: from unknown (HELO lh04.opsion.fr) (212.73.208.230) by mta3 with SMTP; 3 Oct 2000 22:13:27 -0000 Received: from 195.36.173.90 [195.36.173.90] by lh04.opsion.fr; Tue, 3 Oct 2000 21:11:27 GMT Message-ID: <39DA4B88.DDDE415E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> <39D6894F.5FAD9C39@f-cpu.org> <39D7564A.9AB59250@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 23:11:36 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] MFM trick Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 8c9b842bb9a7a27984ad7de2c7f3d7cf Status: R X-Status: N could you repeat what is MFM exactly i don't remember any thing about ? nicO ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970611208/ ---------------------------------------------------------------------_-> From Yann Guidon Wed Oct 4 01:34:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11597 for ; Wed, 4 Oct 2000 05:18:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:44 +0200 (MEST) Received: (qmail 12729 invoked by uid 0); 3 Oct 2000 22:29:59 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 3 Oct 2000 22:29:59 -0000 X-eGroups-Return: sentto-1101623-982-970612197-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 03 Oct 2000 22:29:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:29:56 -0000 Received: (qmail 26027 invoked from network); 3 Oct 2000 22:29:55 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 3 Oct 2000 22:29:55 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 3 Oct 2000 22:29:54 -0000 Received: from f-cpu.org (nas1-153.ras.club-internet.fr [195.36.192.153]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA14795 for ; Wed, 4 Oct 2000 00:29:50 +0200 (MET DST) Message-ID: <39DA6CF5.43305B3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 00:34:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9ce0e049c768a5a2aaadc2afcce0381f Status: R X-Status: N hi again again,

Michael Riepe wrote:
> On Tue, Oct 03, 2000 at 02:18:37AM +0100, Yann Guidon wrote:
> > Michael :
> > > > > (it may be wise to add another
> > > > > line that invalidates the whole cache in that case -- I had that in an
> > > > > earlier version which is still in my CVS, fortunately).
> > > > total invalidate should be done by the reset line, no ? :-)
> > > An asynchronous reset should only happen during initialization (or when
> > > the user hits the Big Red Switch).
> > an Inv_En<=true with the Address_mask<=(others=>'1') should do the trick, no ?
> In my version, that would be (others => '0').  Didn't read yours yet, sorry.
well, these bits can be reversed at one point or another of the circuit.
of course i see that it makes sense, at the circuit level, to use 1 as "mask valid"
since it can act as a OR with the address comparator.
Anyway at the system level, the data can be represented as a normal bitvector.

what do we decide ?

i'm also investigating the cache freeze capabilities.
In order to keep the FIFO simple, we have to move the freezed
items in front of the queue. We'll need a multiplexer to select
where the loaded data will come from (neighbour or new value
>from a bus). We can limit the freezable entries to 1/4 of the queue
so the write bus is shorter. we need an additional bit vector
to indicate that the entry is freezed, too.

This is secondary but worth the brainstorm : if we decide to add
another feature to the cache, another organisation might become
more compact or faster.

Anyway, the freeze instructions have a so-called side effect :
we can't freeze everything and only a subset of the cache can be frozen.
if we send freeze commands all the time, it will spill somewhere.
I still like the FIFO/queue approache because it translates the
'freeze overflow' into a normal LRU ;-)

ok this is not completely clear but i have a good track to investigate.

BUUUUUT now that i have it in mind, i see that the "range" argument can't
be used for our design : the LRU FIFO can only manage 1 request at a time.
i guess that the range/mask will be ignored before we find a suitable solution.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Wed Oct 4 01:34:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11600 for ; Wed, 4 Oct 2000 05:18:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:46 +0200 (MEST) Received: (qmail 12743 invoked by uid 0); 3 Oct 2000 22:30:00 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 3 Oct 2000 22:30:00 -0000 X-eGroups-Return: sentto-1101623-983-970612197-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 03 Oct 2000 22:29:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:29:57 -0000 Received: (qmail 4637 invoked from network); 3 Oct 2000 22:29:56 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 3 Oct 2000 22:29:56 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 3 Oct 2000 22:29:55 -0000 Received: from f-cpu.org (nas1-153.ras.club-internet.fr [195.36.192.153]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA26991 for ; Wed, 4 Oct 2000 00:29:47 +0200 (MET DST) Message-ID: <39DA6CF2.C7A8C65F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D7FA46.90188C09@f-cpu.org> <20001002143649.04675@thrai.stud.uni-hannover.de> <39D92415.95BBCA58@f-cpu.org> <20001003040707.25415@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 00:34:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dea812e59ce223d29c377314a9c15527 Status: R X-Status: N Michael Riepe wrote:
> On Tue, Oct 03, 2000 at 01:11:01AM +0100, Yann Guidon wrote:
> > > A simplified version using serial shift-and-add 8x8 multipliers might
> > > save some space, but has lower throughput -- something like one operation
> > > every 3 or 4 cycles, which is still pretty good IMHO -- and slightly
> > > higher latencies.
> > well, this is something interesting for the division, instead.
> Later... I do not support multitasking very well ;)
"it's only a matter of priorities" ;-)

> SIMD division is particularly hard to implement...
i don't think so. a simple shift-sub algo, with the carry that can
be broken at different sizes... or a shift-sub that can be broken up
if you prefer.

> [...]
> > the time necessary for the transaction can be so long that the line that you
> > reserved for writing may be reused. This increases the cache thrashing.
> > Remember that a full transaction can take tens of cycles and if you have
> > 64 cache lines, only one half will be really used, the others will remain
> > reserved. ok, 64 lines is not much but it serves as example.
> A line that is going to be re-filled *is* reserved -- unless you delay
> the LRU lookup (and final selection of the cache line) until the line
> is finally written.  This is the other alternative, and I will have to
> think it over.
i think that i use more what you described.
we don't need much, only to write to the line that was used the least recently,
and this is given by the FIFO's end value. et voila :-)

>  But the sequence
>         LRU lookup => line is selected (and reserved)
>         memory access (slow)
>         fill line, LRU update
> definitely doesn't make sense, unless the cache is blocked during the
> whole process.
i don't use anything close to "reserved line", except with the freeze/invalidate
stuffs but it's completely off topic here.
if you look closely, you'll see that a write could be done in 1 cycle only
(assuming a rather classical propagation time). All the necessary data are already
available at the necessary places, we just have to move them around a bit
when we receive the write_en signal.

BUT the scheme that you described might be valid in another
context, where there is no RU queue.

> > keeping the line number inside the cache allows any write to really use the
> > Least Recently Used line, with less thrashing. It also keeps the cache size
> > independent from the other parameters of the chip, so it can be interchanged
> > at will.
>
> Hmm.  Instead of
>
>         select line to flush (LRU lookup + update)
there is no need to "lookup" the LRU in a FIFO : the LRU is given by
the end of the queue so it can be speculatively decoded "for free" :-)

>         invalidate line
>         fetch new data @addr (slow)
>         revalidate line
this is a bit unclear anyway...

> we could do
>         fetch new data @addr into temporary buffer (slow)
the said temporary buffer, in the current case, is the "fetcher"
(8 * 256-bit lines that can be addressed with a finer granularity).
>         select line to flush (LRU lookup + update)
>         fill line from temporary buffer (atomically)
this can be done (almost) in parallel.

> which is (slightly) better in terms of cache line reusal.  But there is
> one drawback:  it is possible that concurrent read and write requests
> collide at the LRU unit, because they both attempt to update it.
the priority encoder/collision check is not yet designed.
it shouldn't be difficult, but it's not done anyway.

>  And we can't delay the LRU update until the read happens because a second
> write would overwrite the results of the first one if there's no read
> (and LRU update) between them.
so we have to hold some cache transactions before it is performed.
i hope that the testbench will help analyse all the issues.

> [...]
> > > An asynchronous reset should only happen during initialization (or when
> > > the user hits the Big Red Switch).
> > or maybe this could be the reverse ?
> > cache init would be triggered during power-up (using some hardwired
> > firmware in ROM or a Finite State Machine that would trigger the
> > necessary reset signals in the right order)
> Of course we can reset the LRU unit to `all 0'1' and use a FSM to
> initialize it.  This will be much cheaper than 2^n registers with 2^n
> different initialization states (the wiring would be a mess!).
nope :-) it's just hardwired to + instead of gnd, that's all...
i'll try to re-write the LRU init soon.

but IIRC there are ASIC FF cells that can be configured to be 1 or 0
on power-up, without needing an explicit hard reset. if such a feature
exists, there is no need to reset the FIFO when the cache is completely
invalidated or during a soft reboot. this can be selected with a "generic"
in the VHDL file...

> The other open question is whether we use a synchronous or asynchronous
> reset internally.  Of course we can put both of them into the VHDL
> sources until we make the final decision...
i guess so...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Wed Oct 4 01:34:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11603 for ; Wed, 4 Oct 2000 05:18:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:47 +0200 (MEST) Received: (qmail 20960 invoked by uid 0); 3 Oct 2000 22:30:06 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 3 Oct 2000 22:30:06 -0000 X-eGroups-Return: sentto-1101623-984-970612205-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 03 Oct 2000 22:30:06 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:30:04 -0000 Received: (qmail 26075 invoked from network); 3 Oct 2000 22:30:04 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Oct 2000 22:30:04 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 3 Oct 2000 22:29:59 -0000 Received: from f-cpu.org (nas1-153.ras.club-internet.fr [195.36.192.153]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA04762 for ; Wed, 4 Oct 2000 00:29:51 +0200 (MET DST) Message-ID: <39DA6CF7.2FF43696@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 00:34:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0f250f4e0090fcae81e5be7a8994e7d5 Status: R X-Status: N hi again,

Michael Riepe wrote:
> On Mon, Oct 02, 2000 at 08:41:13PM -0700, Colin Marquardt wrote:
> > > Agreed, eGroups sucks.  I don't like remote CVS, though -- multiple
> > > repositories confuse me, and I already have two or three of them.
> > What other suggestion do you have for code then? Sending it by mail
> > is not really feasible...
> I really do recommend CVS for every project that consist of 3 or more
> files.  I've used it for more than five years now and I'm quite satisfied.
> You may have noticed that I checked in my icache.vhdl, too :)

i don't understand *where*/how you did that. do you have your own
private tree ? :-)

> I just don't like _remote_ repositories, because
>         1) I have a dial-up connection.
me too, and no suitable CVS, and i haven't configured the modem for linux, lazy me...
>         2) I don't have direct access to them (can't move/rename files internally).
>         3) It's hard to keep two repositories in sync.
probably :-)
>         4) I always forget to change CVSROOT ;)
heh. if at least i knew what this meant ;-P

> But I guess I can live with it somehow.  I have to, after all.
as long as we work on small and few files, it can work. we need to
be sure that we use the same external declarations, the architecture
can be personal.

> NB: I have a local repository that contains >800 MByte of sources for
> my own Linux system.  I never installed any binary distributions after
> the initial SLS in '92 :)
huh... impressing :-) i hope that you'll remain as involved in the F-CPU
as you're with your system :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Wed Oct 4 01:34:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11606 for ; Wed, 4 Oct 2000 05:18:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:48 +0200 (MEST) Received: (qmail 21321 invoked by uid 0); 3 Oct 2000 22:30:18 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 3 Oct 2000 22:30:18 -0000 X-eGroups-Return: sentto-1101623-985-970612207-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 03 Oct 2000 22:30:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:30:07 -0000 Received: (qmail 26148 invoked from network); 3 Oct 2000 22:30:07 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 3 Oct 2000 22:30:07 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 3 Oct 2000 22:30:00 -0000 Received: from f-cpu.org (nas1-153.ras.club-internet.fr [195.36.192.153]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA27014 for ; Wed, 4 Oct 2000 00:29:53 +0200 (MET DST) Message-ID: <39DA6CF8.2108DAC2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> <20001002153050.57678@thrai.stud.uni-hannover.de> <39D9F4E0.D6437165@welfen-netz.com> <20001003193839.21479@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 00:34:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 09cf959056bc593e547b715ac4669911 Status: R X-Status: N hi,

Michael Riepe wrote:
> <masochism>
> Now flame me, please ;)
> </masochism>

well, since i haven't gone down this road yet,
i only admire and respect this work. With you working
on such a hard piece of code, i can do the other "simple"
pieces (rop2, inc) in peace :-P

anyway there is a constraint that you are asked to
comply with : for each allowed operation (ie :
SIMD 8*8, int 32*32 etc) you must indicate the
latency and throughput. This is important for the
scheduler so it can determine the instruction slots
at decode time and allocate the write slots of the
Xbar. Of course i leave you some time to complete (or not)
the multiplier. just don't forget the specific scheduling
constraints of the FC0.

If your work doesn't succeed, i remember that i have seen
an online form that generates all sorts of VHDL sources
for pipelined/straight/whatever arithmetic functions,
filters. I asked a pipeline 64*64 mul and it has spit a 1MB
file :-) so you're warned : a multiplier can be huge.
That, and the adders, are two critical units, though.

later,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Wed Oct 4 01:34:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11609 for ; Wed, 4 Oct 2000 05:18:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:49 +0200 (MEST) Received: (qmail 2301 invoked by uid 0); 3 Oct 2000 22:30:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 3 Oct 2000 22:30:32 -0000 X-eGroups-Return: sentto-1101623-986-970612230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 03 Oct 2000 22:30:32 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:30:29 -0000 Received: (qmail 27381 invoked from network); 3 Oct 2000 22:30:29 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 3 Oct 2000 22:30:29 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 3 Oct 2000 22:30:24 -0000 Received: from f-cpu.org (nas1-153.ras.club-internet.fr [195.36.192.153]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA27610 for ; Wed, 4 Oct 2000 00:29:54 +0200 (MET DST) Message-ID: <39DA6CFA.D28115A7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 00:34:18 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] testbench Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3077ebde64cf321b0b4a816c534d7a8a Status: R X-Status: N hello,

i'm thinking about the testbench vector files.
i will have to write the VHDL parser and before it
start this coding work, we better agree on the
the vector format.

I have identified 5 actions :
- reset
- write
- read
- invalid
- freeze (ignored but will become available in
the future)

1 vector = 1 line = 1 cycle
each line is composed of the following optional elements :
T (reset), Write:@, R:@/I:@:mask/F:@:mask

R/I/F use the same address bus so they are exclusive.
they accept the @ (address) parameter and the mask.

i have not yet thought about the comments.

example :

T (reset)
W:456789 (adrress in hexa... variable size, too : no trailing 0 is allowed)
W:98765,R:12345
W:12345,I:78945:127
F:456789:511 (not yet supported but accepted for the testbench).

This way, we can write testbench files in C or by hand.
Now the problem is to get REAL access patterns to see if the
cache is efficient, but it's yet another story ;-)

i gotta put some counters in the testbench : # of reads, writes, hits, etc
so we don't need to use grep to parse the output :-D

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Jecel Assumpcao Jr Wed Oct 4 00:57:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11612 for ; Wed, 4 Oct 2000 05:18:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:50 +0200 (MEST) Received: (qmail 27018 invoked by uid 0); 3 Oct 2000 22:58:21 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 3 Oct 2000 22:58:21 -0000 X-eGroups-Return: sentto-1101623-987-970613894-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 03 Oct 2000 22:58:20 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 22:58:14 -0000 Received: (qmail 1494 invoked from network); 3 Oct 2000 22:58:14 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 3 Oct 2000 22:58:14 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 3 Oct 2000 22:58:12 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id UAA29775 for ; Tue, 3 Oct 2000 20:09:06 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <200010021802.OAA15272@belegost.mit.edu> In-Reply-To: <200010021802.OAA15272@belegost.mit.edu> Message-Id: <00100319582302.05678@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 3 Oct 2000 19:57:42 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 873826ffd74598cb56e44d43ce88960e Status: R X-Status: N As promised:

  http://www.merlintec.com/fpga/

Enjoy,
-- Jecel
 From Yann Guidon Wed Oct 4 02:14:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11618 for ; Wed, 4 Oct 2000 05:18:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:51 +0200 (MEST) Received: (qmail 32516 invoked by uid 0); 3 Oct 2000 23:10:10 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 3 Oct 2000 23:10:10 -0000 X-eGroups-Return: sentto-1101623-989-970614607-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 03 Oct 2000 23:10:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 23:10:06 -0000 Received: (qmail 3365 invoked from network); 3 Oct 2000 23:10:06 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 23:10:06 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 3 Oct 2000 23:10:06 -0000 Received: from f-cpu.org (nas2-207.ras.club-internet.fr [195.36.192.207]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA21648 for ; Wed, 4 Oct 2000 01:10:03 +0200 (MET DST) Message-ID: <39DA7663.B5C7A284@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D6766D.4D2F6E3A@llandre.freeserve.co.uk> <39D6894F.5FAD9C39@f-cpu.org> <39D7564A.9AB59250@f-cpu.org> <39DA4B88.DDDE415E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 01:14:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MFM trick Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e3c307111e4eb0b2e6fb1ab5655e1e61 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> could you repeat what is MFM exactly i don't remember any thing about ?
you'll have to sign a NDA first :-)
<more in private mail>

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 4 02:14:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11621 for ; Wed, 4 Oct 2000 05:18:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:52 +0200 (MEST) Received: (qmail 19749 invoked by uid 0); 3 Oct 2000 23:10:10 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 3 Oct 2000 23:10:10 -0000 X-eGroups-Return: sentto-1101623-988-970614604-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 03 Oct 2000 23:10:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 23:10:03 -0000 Received: (qmail 3195 invoked from network); 3 Oct 2000 23:10:02 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 3 Oct 2000 23:10:02 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 3 Oct 2000 23:10:02 -0000 Received: from f-cpu.org (nas2-207.ras.club-internet.fr [195.36.192.207]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA24573 for ; Wed, 4 Oct 2000 01:09:59 +0200 (MET DST) Message-ID: <39DA765F.2907E7AF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 01:14:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) testbench attempt (+re) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4b4aaf8e2bb3fa6a7715069894ca28f Status: R X-Status: N hi again again again,

Michael Riepe wrote:
> On Tue, Oct 03, 2000 at 04:24:30AM +0100, Yann Guidon wrote:
> > re-re-reading it later helps me understand better what you meant.
> > unfortunately, the precedent cache thrashing remark still applies
> > (unless there's a point i still missed).
> I don't think that it will thrash much more.  If we have SMT some day,
> we need to enlarge the cache anyway.

my thrash argument is valid when there is a high ratio of "locked"
lines, waiting for update, vs actual cache lines.
This issue is avoided simply and cleanly with the LRU queue organisation
that i propose.

Anyway, here we don't see the "big picture". The actual transfers
will be determined by a mechanism that will communicate with the I/O bus,
the private external memory bus, the Icache, the Dcache, the Fetcher,
the L/SU, and we need something simple, we don't need the complication
of dealing with the cache line number...

Think of it like this, if you use the line number as "token" or "transaction ID" :
there will probably be less ongoing transactions than cache lines, so the ID
will need more bits than necessary.


> [...]
> > > > btw, have you tested this code (and how) ?
> > > It's syntacitically correct (at least Simili doesn't object).
> > so, someone else is using it, cool :-)
> Yep, but it's hard to boot NT again and again...
do you mean that Simili crashes NT ? :-)

i too am waiting for the release of the Linux version.
and it will be in binary form ;-)

> > if someone has another VHDL suite, please test our files.
> > Simili is not the most solid SW ever, even if it 'works'.
> It runs on Losedows, what do you expect? ;)
it's not perfect because there is no big team behind it.
it will be ported soon, so what the heck :-)

> I downloaded Alliance 4.0.6 yesterday and will try that on Linux
> (if I can compile it with XFree86 3.3.5 and OpenMotif 2.1.30).
good luck !

isn't XF4 released ? or ...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 4 03:03:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11627 for ; Wed, 4 Oct 2000 05:18:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:53 +0200 (MEST) Received: (qmail 30305 invoked by uid 0); 3 Oct 2000 23:59:13 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 3 Oct 2000 23:59:13 -0000 X-eGroups-Return: sentto-1101623-990-970617548-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 03 Oct 2000 23:59:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 3 Oct 2000 23:59:07 -0000 Received: (qmail 7624 invoked from network); 3 Oct 2000 23:59:07 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Oct 2000 23:59:07 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 3 Oct 2000 23:59:06 -0000 Received: from f-cpu.org (nas3-89.aub.club-internet.fr [195.36.145.89]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA24881 for ; Wed, 4 Oct 2000 01:49:50 +0200 (MET DST) Message-ID: <39DA81DE.7513337E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200010021802.OAA15272@belegost.mit.edu> <00100319582302.05678@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 02:03:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d1f39e1e77e90c5eb78bf9ff81dcff4 Status: R X-Status: N hi,

Jecel Assumpcao Jr wrote:
> As promised:
>   http://www.merlintec.com/fpga/
i'm not convinced 100% but it's promising :-)
maybe you need to communicate about this on
the related newsgroups ?

> Enjoy,
nice xfig :-)
> -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From o5x0BCy93@public.sta.net.cn Thu Nov 6 08:33:36 2036 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11630 for ; Wed, 4 Oct 2000 05:18:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:54 +0200 (MEST) Received: (qmail 9616 invoked by uid 0); 4 Oct 2000 01:25:58 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 4 Oct 2000 01:25:58 -0000 X-eGroups-Return: sentto-1101623-991-970622748-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 04 Oct 2000 01:25:55 -0000 X-Sender: o5x0BCy93@public.sta.net.cn X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 01:25:47 -0000 Received: (qmail 30377 invoked from network); 4 Oct 2000 01:25:47 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 4 Oct 2000 01:25:47 -0000 Received: from unknown (HELO mail.gsdas.com) (194.133.168.6) by mta2 with SMTP; 4 Oct 2000 01:25:45 -0000 Received: from firewall.gsdas.com (localhost [194.133.168.1] (may be forged)) by mail.gsdas.com (8.8.7/8.8.7) with SMTP id XAA03754; Sun, 1 Oct 2000 23:38:04 +0300 Message-ID: <5qk3gJ705xJu> From: o5x0BCy93@public.sta.net.cn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 01 Oct 00 4:05:20 PM Reply-To: f-cpu@egroups.com Subject: [f-cpu] you decide Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 9664c5bc2cd9925b5fda0ca5d4d05f2a Status: R X-Status: N Look, we don't want to waste your time...or ours

You must be determined to earn a bare minimum of $10,000 in the next
30 - 45 days and to develop a net worth of over 1 Million Dollars Cash
in the next  24-36 months. My mission is to help other people develop their
life long dreams. Part of what I'm looking for are those people who are
committed to that BIG of a picture and are not afraid to work for it.
We can help you:

                   REGARDLESS OF YOUR CURRENT AGE
                                OR YOUR DEBT LOAD!

                             NOT MLM or FRANCHISE

                   Don't bother to call unless you are serious.

                Learn the Facts  CALL 1-800-631-5047 (24 hrs)

                          $10,000 IN 30 - 45 DAYS
                      RETIREMENT IN 3-5 YEARS

***************************************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.
mailto:listmgr@cybermax.com?subject=REMOVE
PLEASE understand that any effort to disrupt, close or block this REMOVE
account can only result in difficulties for others wanting to be removed from
our mailing list as it will be impossible to take anyone off the list if the
remove instruction can not be received.
****************************************************************************************
eGroups Sponsor
From Alan Grimes Wed Oct 4 03:34:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11633 for ; Wed, 4 Oct 2000 05:18:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:55 +0200 (MEST) Received: (qmail 13941 invoked by uid 0); 4 Oct 2000 01:32:30 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 4 Oct 2000 01:32:30 -0000 X-eGroups-Return: sentto-1101623-992-970623145-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 04 Oct 2000 01:32:26 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 01:32:24 -0000 Received: (qmail 7725 invoked from network); 4 Oct 2000 01:32:24 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 01:32:24 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta3 with SMTP; 4 Oct 2000 01:32:24 -0000 Received: from 216-164-139-82.s336.tnt5.lnhva.md.dialup.rcn.com ([216.164.139.82] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13gdPz-0005ca-00 for f-cpu@egroups.com; Tue, 03 Oct 2000 21:32:23 -0400 Message-ID: <39DA8915.B9DC273@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <5qk3gJ705xJu> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 21:34:13 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] you decide Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70b09ce253b99444f1ec2c2d09cb8bcd Status: R X-Status: N Somebody's gotta do somethings about the ammount of spam traffick on this
list. =\

--
In this year's presidential race you *do* have a choice!
VOTE Browne/Olivier The ticket to freedom!
http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle randy weaver sog sof oliver north vince
foster m-16 hillary clinton bill clinton marx crack m-60 c5 c7 mlk black
panthers fbi chemical weapons twa 800 roswell white slavery history of us
foreign policy terrorist freedom
####### End   Eschelon Block #######
 From busy1@kidzmail.com.au Wed Oct 4 02:59:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA11636 for ; Wed, 4 Oct 2000 05:18:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 05:18:56 +0200 (MEST) Received: (qmail 31346 invoked by uid 0); 4 Oct 2000 01:33:22 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 4 Oct 2000 01:33:22 -0000 X-eGroups-Return: sentto-1101623-993-970623195-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ci.egroups.com with NNFMP; 04 Oct 2000 01:33:18 -0000 X-Sender: busy1@kidzmail.com.au X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 01:33:15 -0000 Received: (qmail 10075 invoked from network); 4 Oct 2000 01:33:15 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 4 Oct 2000 01:33:15 -0000 Received: from unknown (HELO mail.lucky-star.com.tw) (210.63.240.1) by mta1 with SMTP; 4 Oct 2000 01:33:13 -0000 Received: from finally ([158.252.248.189]) by mail.lucky-star.com.tw (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id tw; Wed, 4 Oct 2000 09:07:12 +0800 X-Priority: 3 X-MSMail-Priority: Normal From: busy1@kidzmail.com.au MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Oct 2000 17:59:39 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Open Your Mind To Exciting Opportunities 76 Content-Type: multipart/mixed; boundary="----=_NextPart_000_322D_00001550.00005FCA" To: sloyment@gmx.net Message-ID: <20001004013322.31359gmx1@mx07.gmx.net> X-UIDL: fba9db0c83fa737e28e40b1fd54e8c60 Status: R X-Status: N ------=_NextPart_000_322D_00001550.00005FCA Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit LOOKING FOR GEMS!

It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!

Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme?

If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need.

Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-742-6549 ext. 6500

We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you.

You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now!

The call is FREE, and there is absolutely no obligation, So what have you got to lose?

Call Toll Free 1-800-742-6549 ext. 6500

P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life!

Please, serious inquiries only.







To be removed from future mailings send a blank email with remove in the subject line and
the email address or addresses to be removed in the body to
busy1@kidzmail.com.au

LOOKING FOR GEMS!


It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...

We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!


Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme?


------=_NextPart_000_322D_00001550.00005FCA-- From Colin Marquardt Wed Oct 4 06:12:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12510 for ; Wed, 4 Oct 2000 14:23:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:32 +0200 (MEST) Received: (qmail 27710 invoked by uid 0); 4 Oct 2000 04:34:38 -0000 Received: from mo.egroups.com (208.50.144.78) by mx12.rz2.gmx.net with SMTP; 4 Oct 2000 04:34:38 -0000 X-eGroups-Return: sentto-1101623-994-970634074-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 04 Oct 2000 04:34:36 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 04:34:34 -0000 Received: (qmail 13067 invoked from network); 4 Oct 2000 04:34:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 4 Oct 2000 04:34:34 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 4 Oct 2000 04:34:33 -0000 Received: from morphin.marquardt-home.de (d88.nas22.sonic.net [209.204.137.88]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA14927 for ; Wed, 4 Oct 2000 06:34:30 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gfv9-0000Qc-00 for ; Tue, 03 Oct 2000 21:12:43 -0700 To: f-cpu@egroups.com X-Now-Playing: Todd Dillingham's tryst - Underneath Stars Without A Sky X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 54 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Oct 2000 21:12:43 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [comp.lang.vhdl] memory usage of large bhv array Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d77a8f7e33cce509528a25f45518d094 Status: R X-Status: N
Just another article to have in mind when we need it... The paper is
here:
  http://www.ednmag.com/ednmag/reg/1999/112499/pdfs/24ms579.pdf

From: "Kate Atkins" <kate.atkins@siraeo.noldckspam.co.uk>
Subject: Re: memory usage of large bhv array
Newsgroups: comp.lang.vhdl
Date: Tue, 3 Oct 2000 09:58:00 +0100
Message-ID: <970563515.4309.0.nnrp-09.9e98b847@news.demon.co.uk>
X-NNTP-Posting-Host: siraeo.demon.co.uk:158.152.184.71
X-Trace: news.demon.co.uk 970563515 nnrp-09:4309 NO-IDENT siraeo.demon.co.uk:158.152.184.71
X-Complaints-To: abuse@demon.net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300

Hi

EDN magazine www.ednmag.com did an interesting article called "VHDL
constructs and methodologies for advanced design verification" in November
1999. It describes how to use records and access types to create dynamically
allocated memory models, ie simulation memory is only allocated to locations
which have been written to. If you need a big array but the simulation will
only access small parts of it then this could be a useful technique. The
article is still available on the web site and VHDL was available as well. I
tried it for a 128kx8 memory and it seemed to work OK.

Kate

Diarmuid Collins <diarmuid.collins@s3group.com> wrote in message
news:39D376CC.F9180F93@s3group.com...
> Hi,
> I currently investigating the use of a large array of records
> in vhdl. I'm interested in a 64x3k (and larger) array of records,each
> record containing an integer (1to64) and a 3 bit number.
> I know that using signals is a big no-no but can anyone give me any
> figures so I can work out what sort of memory usage I can expect.
> This is for a testbench so it doesnt have to be synthesisable.
>
> I'm using Modeltech (MTI) 5.4c.
>
> Thanks
>
> Diarmuid
>
>
> --
>  Diarmuid Collins                |   +353-1-2185544
>  Silicon & Software Systems Ltd  |   diarmuid.collins@s3group.com


--
14. Madcatmachopsychoromantik . . . . . . . . . . . . . . . . . . 09.15
 From Colin Marquardt Wed Oct 4 05:59:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12513 for ; Wed, 4 Oct 2000 14:23:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:33 +0200 (MEST) Received: (qmail 14496 invoked by uid 0); 4 Oct 2000 04:34:48 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 4 Oct 2000 04:34:48 -0000 X-eGroups-Return: sentto-1101623-996-970634081-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 04 Oct 2000 04:34:47 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 04:34:41 -0000 Received: (qmail 28900 invoked from network); 4 Oct 2000 04:34:41 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 4 Oct 2000 04:34:41 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 4 Oct 2000 04:34:40 -0000 Received: from morphin.marquardt-home.de (d88.nas22.sonic.net [209.204.137.88]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA14978 for ; Wed, 4 Oct 2000 06:34:37 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gfiN-0000QH-00 for ; Tue, 03 Oct 2000 20:59:31 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> X-Now-Playing: Manic Movement's Thousand Sufferings - Juglar Of Bones In-Reply-To: Michael Riepe's message of "Tue, 3 Oct 2000 16:29:49 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 23 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Oct 2000 20:59:31 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cd22bdc3decb49b5a088b645387d6dfb Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> I just don't like _remote_ repositories, because

>       1) I have a dial-up connection.
>       2) I don't have direct access to them (can't move/rename files internally).
>       3) It's hard to keep two repositories in sync.
>       4) I always forget to change CVSROOT ;)

> But I guess I can live with it somehow.  I have to, after all.

I also only have a modem, albeit with a flat rate. But many
developers are using CVS and are in the same situation...

> NB: I have a local repository that contains >800 MByte of sources for
> my own Linux system.  I never installed any binary distributions after
> the initial SLS in '92 :)

That is really cool :-) I also wonder why I even have a distribution
since my /usr/local is filled up too...

Cheers,
  Colin
 From Colin Marquardt Wed Oct 4 06:07:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12516 for ; Wed, 4 Oct 2000 14:23:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:33 +0200 (MEST) Received: (qmail 24508 invoked by uid 0); 4 Oct 2000 04:34:49 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 4 Oct 2000 04:34:49 -0000 X-eGroups-Return: sentto-1101623-995-970634077-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 04 Oct 2000 04:34:47 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 04:34:37 -0000 Received: (qmail 7332 invoked from network); 4 Oct 2000 04:34:37 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 4 Oct 2000 04:34:37 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 4 Oct 2000 04:34:37 -0000 Received: from morphin.marquardt-home.de (d88.nas22.sonic.net [209.204.137.88]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA14964 for ; Wed, 4 Oct 2000 06:34:34 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gfqY-0000QN-00 for ; Tue, 03 Oct 2000 21:07:58 -0700 To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> X-Now-Playing: Impaler's Deaf Metal Sampler - Repel Your Faith In-Reply-To: Yann Guidon's message of "Wed, 04 Oct 2000 00:34:13 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Oct 2000 21:07:58 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 80934eb42029029ed4f5a97e8ae8b491 Status: R X-Status: N * Yann Guidon <whygee@f-cpu.org> writes:

>> > an Inv_En<=true with the Address_mask<=(others=>'1') should do the trick, no ?

>> In my version, that would be (others => '0').  Didn't read yours yet, sorry.

> well, these bits can be reversed at one point or another of the circuit.
> of course i see that it makes sense, at the circuit level, to use 1 as "mask valid"
> since it can act as a OR with the address comparator.

I have always seen "mask" as "mask something out", so if a mask bit is
a one, the thing to mask (think of an interrupt) is not visible. But I
have seen it the other 'round too (confuses me though).

Colin
 From Colin Marquardt Wed Oct 4 06:03:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12519 for ; Wed, 4 Oct 2000 14:23:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:34 +0200 (MEST) Received: (qmail 9193 invoked by uid 0); 4 Oct 2000 04:34:56 -0000 Received: from ci.egroups.com (208.50.99.231) by mx11.rz2.gmx.net with SMTP; 4 Oct 2000 04:34:56 -0000 X-eGroups-Return: sentto-1101623-997-970634084-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 04 Oct 2000 04:34:53 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 04:34:44 -0000 Received: (qmail 13383 invoked from network); 4 Oct 2000 04:34:44 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 4 Oct 2000 04:34:44 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 4 Oct 2000 04:34:44 -0000 Received: from morphin.marquardt-home.de (d88.nas22.sonic.net [209.204.137.88]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA14985 for ; Wed, 4 Oct 2000 06:34:41 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13gfmF-0000QL-00 for ; Tue, 03 Oct 2000 21:03:31 -0700 To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <20001002140903.43869@thrai.stud.uni-hannover.de> <20001003160811.18217@thrai.stud.uni-hannover.de> X-Now-Playing: Sadus's Elements Of Anger - In The End In-Reply-To: Michael Riepe's message of "Tue, 3 Oct 2000 16:08:11 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 27 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Oct 2000 21:03:31 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90893e2a129d5cff8e459083fa991401 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> We can revert that later when we worked out all errors, don't we?
> `for f in *.vhdl; do some-sed-magic <$f >$f.new; done'.

That would work.

> Or we use a package to define symbolic names and use them all over the
> place.

Like making f_cpu_vector of either std_ulogic_vector or
std_logic_vector? Would also work, but it is probably not worth the
hassle. RMM compliancy in that regard is not critical.

>> >       entity blah is
>> >             port (Rst : boolean);
>> >       end blah;
>>
>> Exactly. Only at the top level this will be converted to a
>> std_ulogic, where it will probably have negative logic.

> Automagically?

No, we have to do it.

Cheers,
  Colin
 From graham@belegost.mit.edu Wed Oct 4 11:23:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12567 for ; Wed, 4 Oct 2000 14:23:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:47 +0200 (MEST) Received: (qmail 5721 invoked by uid 0); 4 Oct 2000 09:24:00 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 4 Oct 2000 09:24:00 -0000 X-eGroups-Return: sentto-1101623-998-970651396-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ei.egroups.com with NNFMP; 04 Oct 2000 09:23:23 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 09:23:16 -0000 Received: (qmail 8692 invoked from network); 4 Oct 2000 09:23:15 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 4 Oct 2000 09:23:15 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 4 Oct 2000 09:23:15 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA03095 for f-cpu@egroups.com; Wed, 4 Oct 2000 05:23:15 -0400 Message-Id: <200010040923.FAA03095@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <00100319582302.05678@gandalf> from "Jecel Assumpcao Jr" at Oct 03, 2000 07:57:42 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 05:23:14 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 00a4619ef824d1b29e153e02f9cfbdea Status: R X-Status: N >
> As promised:
>
>   http://www.merlintec.com/fpga/
>
> Enjoy,
> -- Jecel
>

Some assorted comments:

>from FPGA99:

"Herman Schmit of Carnegie Mellon University demonstrated that a
partially populated four-dimensional interconnect scheme -
essentially, a hypercube - behaved much better under intensive
routing demands than existing two-dimensional arrays."

but isn't scaling a problem? log n connections per cell for n cells still
grows for large devices...

Built in RAM?

How about the loading circuitry? Bit-serial load? Or direct addressing
for each cell? (is that practical? I have no idea of the number of
layers available or required to do this...)

'Cells very similar to Xilinx CLBs' sounds like it might be a problem
>from the patent side...

Nice to see it though... :-)

Graham


 From Michael Riepe Wed Oct 4 06:02:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12600 for ; Wed, 4 Oct 2000 14:23:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:56 +0200 (MEST) Received: (qmail 21428 invoked by uid 0); 4 Oct 2000 12:06:02 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 4 Oct 2000 12:06:02 -0000 X-eGroups-Return: sentto-1101623-999-970661159-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hj.egroups.com with NNFMP; 04 Oct 2000 12:06:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:05:58 -0000 Received: (qmail 30415 invoked from network); 4 Oct 2000 12:05:58 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 12:05:58 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta3 with SMTP; 4 Oct 2000 12:05:55 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA01471; Wed, 4 Oct 2000 06:02:12 +0200 Message-ID: <20001004060211.44006@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D7FA46.90188C09@f-cpu.org> <20001002143649.04675@thrai.stud.uni-hannover.de> <39D92415.95BBCA58@f-cpu.org> <20001003040707.25415@thrai.stud.uni-hannover.de> <39DA6CF2.C7A8C65F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DA6CF2.C7A8C65F@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 12:34:10AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 06:02:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) first icache behaviour file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 509092a93e993650461bea99ef7797e7 Status: R X-Status: N On Wed, Oct 04, 2000 at 12:34:10AM +0100, Yann Guidon wrote:

> > Later... I do not support multitasking very well ;)
> "it's only a matter of priorities" ;-)

It's more like SIMD: I could do many things at once, but the results
would be much smaller ;)

> > SIMD division is particularly hard to implement...
> i don't think so. a simple shift-sub algo, with the carry that can
> be broken at different sizes... or a shift-sub that can be broken up
> if you prefer.

Yes.  But that's soooo sloooooooow...

> we don't need much, only to write to the line that was used the least recently,
> and this is given by the FIFO's end value. et voila :-)

I understood that.  Amazing ;)

What happens to the read that triggered the fetch?

> >  But the sequence
> >         LRU lookup => line is selected (and reserved)
> >         memory access (slow)
> >         fill line, LRU update
> > definitely doesn't make sense, unless the cache is blocked during the
> > whole process.
> i don't use anything close to "reserved line", except with the freeze/invalidate
> stuffs but it's completely off topic here.
> if you look closely, you'll see that a write could be done in 1 cycle only
> (assuming a rather classical propagation time). All the necessary data are already
> available at the necessary places, we just have to move them around a bit
> when we receive the write_en signal.

I was talking about the memory fetch cycle, not the final write.

> BUT the scheme that you described might be valid in another
> context, where there is no RU queue.
>
> > Hmm.  Instead of
> >
> >         select line to flush (LRU lookup + update)
> there is no need to "lookup" the LRU in a FIFO : the LRU is given by
> the end of the queue so it can be speculatively decoded "for free" :-)

That's what I meant :)

> >         invalidate line
> >         fetch new data @addr (slow)
> >         revalidate line
> this is a bit unclear anyway...

Safety measure.  Maybe we can get away without it, but I'm not sure.

> > we could do
> >         fetch new data @addr into temporary buffer (slow)
> the said temporary buffer, in the current case, is the "fetcher"
> (8 * 256-bit lines that can be addressed with a finer granularity).
> >         select line to flush (LRU lookup + update)
> >         fill line from temporary buffer (atomically)
> this can be done (almost) in parallel.

Right.

> > which is (slightly) better in terms of cache line reusal.  But there is
> > one drawback:  it is possible that concurrent read and write requests
> > collide at the LRU unit, because they both attempt to update it.
> the priority encoder/collision check is not yet designed.
> it shouldn't be difficult, but it's not done anyway.

I'd rather avoid collisions at all than handle them.

> >  And we can't delay the LRU update until the read happens because a second
> > write would overwrite the results of the first one if there's no read
> > (and LRU update) between them.
> so we have to hold some cache transactions before it is performed.
> i hope that the testbench will help analyse all the issues.

Amen; so do I.

> > Of course we can reset the LRU unit to `all 0'1' and use a FSM to
> > initialize it.  This will be much cheaper than 2^n registers with 2^n
> > different initialization states (the wiring would be a mess!).
> nope :-) it's just hardwired to + instead of gnd, that's all...
> i'll try to re-write the LRU init soon.

But each register in the LRU would have different wiring.  I prefer
clean, modular structures, in case you didn't notice :)  This will
save our butt when we start structural modeling.

> but IIRC there are ASIC FF cells that can be configured to be 1 or 0
> on power-up, without needing an explicit hard reset. if such a feature
> exists, there is no need to reset the FIFO when the cache is completely
> invalidated or during a soft reboot. this can be selected with a "generic"
> in the VHDL file...

Target technology dependencies are a Bad Thing for a project like this.
There are FPGAs out there that have nice (and unique) features (I like
the Atmel AT40K series very much, from an aesthetic point of view),
but we should avoid these kinds of traps if possible.  Once trapped,
it's hard to escape.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Wed Oct 4 05:32:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12603 for ; Wed, 4 Oct 2000 14:23:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:57 +0200 (MEST) Received: (qmail 29013 invoked by uid 0); 4 Oct 2000 12:06:05 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 4 Oct 2000 12:06:05 -0000 X-eGroups-Return: sentto-1101623-1000-970661161-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 04 Oct 2000 12:06:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:06:00 -0000 Received: (qmail 5267 invoked from network); 4 Oct 2000 12:06:00 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 4 Oct 2000 12:06:00 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta3 with SMTP; 4 Oct 2000 12:05:59 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA01399; Wed, 4 Oct 2000 05:32:39 +0200 Message-ID: <20001004053239.48460@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DA6CF5.43305B3@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 12:34:13AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 05:32:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9ee7031b2022acc362317605f073eeed Status: R X-Status: N On Wed, Oct 04, 2000 at 12:34:13AM +0100, Yann Guidon wrote:

> BUUUUUT now that i have it in mind, i see that the "range" argument can't
> be used for our design : the LRU FIFO can only manage 1 request at a time.
> i guess that the range/mask will be ignored before we find a suitable solution.

Another good reason why only reads should trigger an LRU update ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Wed Oct 4 05:15:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12606 for ; Wed, 4 Oct 2000 14:23:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:57 +0200 (MEST) Received: (qmail 27203 invoked by uid 0); 4 Oct 2000 12:06:21 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 4 Oct 2000 12:06:21 -0000 X-eGroups-Return: sentto-1101623-1002-970661174-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 04 Oct 2000 12:06:19 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:06:14 -0000 Received: (qmail 31043 invoked from network); 4 Oct 2000 12:06:14 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 12:06:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta3 with SMTP; 4 Oct 2000 12:06:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA01347; Wed, 4 Oct 2000 05:15:38 +0200 Message-ID: <20001004051537.26563@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> <20001002153050.57678@thrai.stud.uni-hannover.de> <39D9F4E0.D6437165@welfen-netz.com> <20001003193839.21479@thrai.stud.uni-hannover.de> <39DA6CF8.2108DAC2@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DA6CF8.2108DAC2@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 12:34:16AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 05:15:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b05f13412165c079addb2051651a9bd0 Status: R X-Status: N On Wed, Oct 04, 2000 at 12:34:16AM +0100, Yann Guidon wrote:

> well, since i haven't gone down this road yet,
> i only admire and respect this work. With you working
> on such a hard piece of code, i can do the other "simple"
> pieces (rop2, inc) in peace :-P

I thought ROP2 was already finished?  The drawing in the manual looked
pretty complete to me, and it even supports SIMD ;)

> anyway there is a constraint that you are asked to
> comply with : for each allowed operation (ie :
> SIMD 8*8, int 32*32 etc) you must indicate the
> latency and throughput. This is important for the
> scheduler so it can determine the instruction slots
> at decode time and allocate the write slots of the
> Xbar. Of course i leave you some time to complete (or not)
> the multiplier. just don't forget the specific scheduling
> constraints of the FC0.

I'm aware of that.

> If your work doesn't succeed, i remember that i have seen
> an online form that generates all sorts of VHDL sources
> for pipelined/straight/whatever arithmetic functions,
> filters. I asked a pipeline 64*64 mul and it has spit a 1MB
> file :-) so you're warned : a multiplier can be huge.

Yes, and I'm afraid this one will be pretty big.  But I had another
idea today, just in case we have space problems:  we can save almost 75%
of space if we build a 32-bit multiplier instead.  No wait, please let
me explain...

Since the slices of SIMD operands are mutually independent, we don't
have to calculate all SIMD results at the same time.  With a pipelined
32-bit multiplier that has a throughput of 1 op/cycle, we can split
64-bit quantities for all SIMD operations and calculate upper and
lower half one after another.  This reduces SIMD throughput to 50%
and adds 1 cycle of latency.  For full-size operations, we calculate
4 partial results in sequence (latency: +3 cycles, throughput: 25%),
collect the results and feed them into the final, fully-sized stage.
This saves even more space than the `serial 8x8 multiplier' approach
(which had <66% saving) and runs SIMD multiplications faster.

> That, and the adders, are two critical units, though.

Yep.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Wed Oct 4 05:27:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12609 for ; Wed, 4 Oct 2000 14:23:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:59 +0200 (MEST) Received: (qmail 30282 invoked by uid 0); 4 Oct 2000 12:06:43 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 4 Oct 2000 12:06:43 -0000 X-eGroups-Return: sentto-1101623-1001-970661170-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 04 Oct 2000 12:06:16 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:06:09 -0000 Received: (qmail 30889 invoked from network); 4 Oct 2000 12:06:09 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 12:06:09 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta3 with SMTP; 4 Oct 2000 12:06:07 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA01383; Wed, 4 Oct 2000 05:27:14 +0200 Message-ID: <20001004052714.61783@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DA765F.2907E7AF@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 01:14:23AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 05:27:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) testbench attempt (+re) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9d156269cfef5dc0462a8dc3380e998d Status: R X-Status: N On Wed, Oct 04, 2000 at 01:14:23AM +0100, Yann Guidon wrote:
> hi again again again,

for i in 1 to 100 loop
      write("I shall not write too many e-mails to f-cpu@egroups.com");
end loop; -- ;)

> > Yep, but it's hard to boot NT again and again...
> do you mean that Simili crashes NT ? :-)

No... but I have to switch between NT and Linux.

> i too am waiting for the release of the Linux version.
> and it will be in binary form ;-)

I'd rather try alliance and savant first.  I *hate* binaries.
But I'd really love a CPU with source code :)

> > I downloaded Alliance 4.0.6 yesterday and will try that on Linux
> > (if I can compile it with XFree86 3.3.5 and OpenMotif 2.1.30).
> good luck !

Hmm... I will need that.  BTW: I also tried electric; it compiled
fine with Motif, but the display had lots of ugly glitches that made
it unusable.

> isn't XF4 released ? or ...

Yes it is, but it doesn't run on all cards.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From jeff davies Wed Oct 4 14:10:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12612 for ; Wed, 4 Oct 2000 14:23:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 14:23:59 +0200 (MEST) Received: (qmail 9914 invoked by uid 0); 4 Oct 2000 12:11:12 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 4 Oct 2000 12:11:12 -0000 X-eGroups-Return: sentto-1101623-1003-970661448-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 04 Oct 2000 12:11:11 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:10:47 -0000 Received: (qmail 8215 invoked from network); 4 Oct 2000 12:10:47 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 12:10:47 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta3 with SMTP; 4 Oct 2000 12:10:47 -0000 Received: from modem-5.lawrencium.dialup.pol.co.uk ([62.136.71.5] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13gnNl-000543-00 for f-cpu@egroups.com; Wed, 04 Oct 2000 13:10:46 +0100 Sender: root@pop.gmx.net Message-ID: <39DB1E51.47344466@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 13:10:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) testbench attempt (+re) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 362b43fb11c9482505d6bfa36639c24c Status: R X-Status: N Michael Riepe wrote:

> > > Yep, but it's hard to boot NT again and again...
> > do you mean that Simili crashes NT ? :-)
>
> No... but I have to switch between NT and Linux.
>

try vmware ($99) www.vmware.com
very very good. All OS's should have a virtual machine like this
built in.

Jeff Davies
eGroups Sponsor
From Michael Riepe Wed Oct 4 04:47:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA13027 for ; Wed, 4 Oct 2000 18:47:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Oct 2000 18:47:07 +0200 (MEST) Received: (qmail 3648 invoked by uid 0); 4 Oct 2000 12:24:49 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 4 Oct 2000 12:24:49 -0000 X-eGroups-Return: sentto-1101623-1004-970662281-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 04 Oct 2000 12:24:47 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 12:24:41 -0000 Received: (qmail 3918 invoked from network); 4 Oct 2000 12:24:41 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 4 Oct 2000 12:24:41 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.248) by mta1 with SMTP; 4 Oct 2000 12:24:39 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01280; Wed, 4 Oct 2000 04:47:47 +0200 Message-ID: <20001004044747.48281@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> <39DA6CF7.2FF43696@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DA6CF7.2FF43696@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 12:34:15AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 04:47:47 +0200 Reply-To: f-cpu@egroups.com Subject: CVS (was: Re: [f-cpu] (v) happy :-)) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f3791ce5f9a16df4570c388037d2db29 Status: R X-Status: N On Wed, Oct 04, 2000 at 12:34:15AM +0100, Yann Guidon wrote:

> > I really do recommend CVS for every project that consist of 3 or more
> > files.  I've used it for more than five years now and I'm quite satisfied.
> > You may have noticed that I checked in my icache.vhdl, too :)
>
> i don't understand *where*/how you did that. do you have your own
> private tree ? :-)

I have three repositories of my own, two locally and one remote.
And I use several others (public, read-only repositories from some
projects I'm interested in).

> > I just don't like _remote_ repositories, because
[...]
> >         4) I always forget to change CVSROOT ;)
> heh. if at least i knew what this meant ;-P

CVSROOT is a shell variable that points to the root directory of the
repository you use.

CVS isn't hard to use at all, and you can set it up with only a few steps.
Those of you who are interested in CVS should read the CVS documentation
(cvs.info, normally).  It contains a short introduction, too.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Wed Oct 4 20:29:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00298 for ; Thu, 5 Oct 2000 07:44:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:06 +0200 (MEST) Received: (qmail 19030 invoked by uid 0); 4 Oct 2000 17:26:23 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 4 Oct 2000 17:26:23 -0000 X-eGroups-Return: sentto-1101623-1005-970680376-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 04 Oct 2000 17:26:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 17:26:14 -0000 Received: (qmail 4400 invoked from network); 4 Oct 2000 17:26:08 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 4 Oct 2000 17:26:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 4 Oct 2000 17:26:07 -0000 Received: from f-cpu.org (nas1-140.ras.club-internet.fr [195.36.192.140]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA02392 for ; Wed, 4 Oct 2000 19:25:48 +0200 (MET DST) Message-ID: <39DB7717.3C778121@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 19:29:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] [comp.lang.vhdl] memory usage of large bhv array Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 14ecfe449a8f81e68f163121660eb302 Status: R X-Status: N hi !

Colin Marquardt wrote:
>
> Just another article to have in mind when we need it... The paper is
> here:
>   http://www.ednmag.com/ednmag/reg/1999/112499/pdfs/24ms579.pdf

i've also found some VHDL models of memories that are either
"plain" or "dynamic". Internet is a powerful tool when it comes
to seeking a VHDL library :-) For example, the MICRON models are
very complete.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 4 20:29:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00301 for ; Thu, 5 Oct 2000 07:44:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:07 +0200 (MEST) Received: (qmail 16040 invoked by uid 0); 4 Oct 2000 17:28:29 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 4 Oct 2000 17:28:29 -0000 X-eGroups-Return: sentto-1101623-1006-970680497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 04 Oct 2000 17:28:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 17:28:16 -0000 Received: (qmail 20418 invoked from network); 4 Oct 2000 17:25:51 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 4 Oct 2000 17:25:51 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 4 Oct 2000 17:25:50 -0000 Received: from f-cpu.org (nas1-140.ras.club-internet.fr [195.36.192.140]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA23314 for ; Wed, 4 Oct 2000 19:25:29 +0200 (MET DST) Message-ID: <39DB7716.D2992B7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 19:29:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 327aa0760473aa29381086e4be4bfcc9 Status: R X-Status: N hi,

Colin Marquardt wrote:
> * Yann Guidon <whygee@f-cpu.org> writes:
> >> > an Inv_En<=true with the Address_mask<=(others=>'1') should do the trick, no ?
> >> In my version, that would be (others => '0').  Didn't read yours yet, sorry.
> > well, these bits can be reversed at one point or another of the circuit.
> > of course i see that it makes sense, at the circuit level, to use 1 as "mask valid"
> > since it can act as a OR with the address comparator.
> I have always seen "mask" as "mask something out", so if a mask bit is
> a one, the thing to mask (think of an interrupt) is not visible. But I
> have seen it the other 'round too (confuses me though).

so what we have to do is the difference between the "declaration/interface" level
and the "implementation". we better choose what makes most sense.
Here the mask is a physical implementation of a "range", and a range is a positive
number (usually). From the outside it could make sense to have a string of 1 that
indicates which part of the address to ignore. Of course, these can be "booleans" that
will be implemented acitve low or high at the last moment.
I need your feedback before writing the benchmark vectors.

Another crucial functionality that i have forgotten : BIST port,
or at least a way for the BIOS/firmware to test the integrity of the
cache's components. this is not for today, and it also depends on the
target technology, but it will be necessary for the ASICs and full-custom
chips. This came to my mind because at one point, it will be necessary
to know whether an address is cached, if it's frozen, etc...

> Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 4 21:20:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00316 for ; Thu, 5 Oct 2000 07:44:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:10 +0200 (MEST) Received: (qmail 22811 invoked by uid 0); 4 Oct 2000 18:16:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 4 Oct 2000 18:16:32 -0000 X-eGroups-Return: sentto-1101623-1007-970683374-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 04 Oct 2000 18:16:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 18:16:12 -0000 Received: (qmail 20320 invoked from network); 4 Oct 2000 18:16:10 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 4 Oct 2000 18:16:10 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 4 Oct 2000 18:16:10 -0000 Received: from f-cpu.org (nas1-238.aub.club-internet.fr [195.36.150.238]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA05566 for ; Wed, 4 Oct 2000 20:15:57 +0200 (MET DST) Message-ID: <39DB82E2.9D19FF8E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Oct 2000 20:20:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] several merged replies (cache+msic) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8386ab8c09609954b03f4a19141a3360 Status: R X-Status: N Michael Riepe wrote:
> On Wed, Oct 04, 2000 at 01:14:23AM +0100, Yann Guidon wrote:
> > hi again again again,
> for i in 1 to 100 loop
>         write("I shall not write too many e-mails to f-cpu@egroups.com");
> end loop; -- ;)
nice but this doesn't count, you have forgotten the "writeline" ;-)
yes, i know, i should code more than i speak...

> > i too am waiting for the release of the Linux version.
> > and it will be in binary form ;-)
> I'd rather try alliance and savant first.  I *hate* binaries.
> But I'd really love a CPU with source code :)
so let's go :-)
please, can you do the Alliance learning first,
so i concentrate on the meat ? ;-) i have a paper doc and 2 distro CDs
but no time to read that all :-/

> > > I downloaded Alliance 4.0.6 yesterday and will try that on Linux
> > > (if I can compile it with XFree86 3.3.5 and OpenMotif 2.1.30).
> > good luck !
> Hmm... I will need that.  BTW: I also tried electric; it compiled
> fine with Motif, but the display had lots of ugly glitches that made
> it unusable.
RIP...

> > isn't XF4 released ? or ...
> Yes it is, but it doesn't run on all cards.
heck.



Michael Riepe wrote:
> On Wed, Oct 04, 2000 at 12:34:13AM +0100, Yann Guidon wrote:
> > BUUUUUT now that i have it in mind, i see that the "range" argument can't
> > be used for our design : the LRU FIFO can only manage 1 request at a time.
> > i guess that the range/mask will be ignored before we find a suitable solution.
> Another good reason why only reads should trigger an LRU update ;)
grrrr ! :-) i hate when you are right like that ;-)

so let's just allow non-simultaneous reads and writes. there will be priority queues
etc, outside of the cache's structure.

> > > Later... I do not support multitasking very well ;)
> > "it's only a matter of priorities" ;-)
> It's more like SIMD: I could do many things at once, but the results
> would be much smaller ;)
:-D

> > > SIMD division is particularly hard to implement...
> > i don't think so. a simple shift-sub algo, with the carry that can
> > be broken at different sizes... or a shift-sub that can be broken up
> > if you prefer.
> Yes.  But that's soooo sloooooooow...
of course, it's slow, all int divides are slow.
but when you need to divide a vector (SIMD or whatever) by a number,
just compute the reciprocal, and multiply each element with this reciprocal.
this way, the "vector" divide is pipelinable. that's what all high-speed
computers do. So maybe all we need is an integer "recip" ?

> > we don't need much, only to write to the line that was used the least recently,
> > and this is given by the FIFO's end value. et voila :-)
> I understood that.  Amazing ;)
> What happens to the read that triggered the fetch?
it's managed outside the Icache element.
we have to manage several buses at the same time and Tomasulo's algo would
not work all the time... we have to design the memory interface first.

> > >  But the sequence
> > >         LRU lookup => line is selected (and reserved)
> > >         memory access (slow)
> > >         fill line, LRU update
> > > definitely doesn't make sense, unless the cache is blocked during the
> > > whole process.
> > i don't use anything close to "reserved line", except with the freeze/invalidate
> > stuffs but it's completely off topic here.
> > if you look closely, you'll see that a write could be done in 1 cycle only
> > (assuming a rather classical propagation time). All the necessary data are already
> > available at the necessary places, we just have to move them around a bit
> > when we receive the write_en signal.
> I was talking about the memory fetch cycle, not the final write.
the external memory fetch is managed by the memory interface that communicates
with the fetcher. Only when the fetcher's buffer is filled, we trigger the
Icache write cycle.

          fetcher = Icache
       /
ext. mem
       \\
          LSU = Dcache



> > > Hmm.  Instead of
> > >         select line to flush (LRU lookup + update)
> > there is no need to "lookup" the LRU in a FIFO : the LRU is given by
> > the end of the queue so it can be speculatively decoded "for free" :-)
> That's what I meant :)
cool :-)
so now , the problem is that i'm sure that there are people here who still
don't understand what we say :-D

> > >         invalidate line
> > >         fetch new data @addr (slow)
> > >         revalidate line
> > this is a bit unclear anyway...
> Safety measure.  Maybe we can get away without it, but I'm not sure.
let's keep it simple and working :-)

> > > we could do
> > >         fetch new data @addr into temporary buffer (slow)
> > the said temporary buffer, in the current case, is the "fetcher"
> > (8 * 256-bit lines that can be addressed with a finer granularity).
> > >         select line to flush (LRU lookup + update)
> > >         fill line from temporary buffer (atomically)
> > this can be done (almost) in parallel.
> Right.
this was already described in the VHDL comments of the
icache spec i sent some time ago.

> > > which is (slightly) better in terms of cache line reusal.  But there is
> > > one drawback:  it is possible that concurrent read and write requests
> > > collide at the LRU unit, because they both attempt to update it.
> > the priority encoder/collision check is not yet designed.
> > it shouldn't be difficult, but it's not done anyway.
> I'd rather avoid collisions at all than handle them.
yep, but here we can't avoid the need that causes the collisions.
so the efforts are made somewhere else in the chip.
let's not think about it now.

> > > Of course we can reset the LRU unit to `all 0'1' and use a FSM to
> > > initialize it.  This will be much cheaper than 2^n registers with 2^n
> > > different initialization states (the wiring would be a mess!).
> > nope :-) it's just hardwired to + instead of gnd, that's all...
> > i'll try to re-write the LRU init soon.
> But each register in the LRU would have different wiring.  I prefer
> clean, modular structures, in case you didn't notice :)  This will
> save our butt when we start structural modeling.
i'm not convinced of this ...
in HW or in cell libraries, you can find flip-flops that can be hardwired
latched at 1 or 0 at power-up. Some FF can have a reset and others have a preset,
they can be all tied to the same general reset bus.

> > but IIRC there are ASIC FF cells that can be configured to be 1 or 0
> > on power-up, without needing an explicit hard reset. if such a feature
> > exists, there is no need to reset the FIFO when the cache is completely
> > invalidated or during a soft reboot. this can be selected with a "generic"
> > in the VHDL file...
> Target technology dependencies are a Bad Thing for a project like this.
> There are FPGAs out there that have nice (and unique) features (I like
> the Atmel AT40K series very much, from an aesthetic point of view),
> but we should avoid these kinds of traps if possible.  Once trapped,
> it's hard to escape.
i agree about the trap.
but you can agree that there are FFs that have a preset, others have a reset,
so instead of wasting space with a FSM that will init the LRU queue,
let's use simple features that are easily hardwired. We're only beginning the
design, we're still far from the synthesis and we still use behavioural code,
so i think that it is not a huge problem now :-)


Michael Riepe wrote:
> On Wed, Oct 04, 2000 at 12:34:16AM +0100, Yann Guidon wrote:
> > well, since i haven't gone down this road yet,
> > i only admire and respect this work. With you working
> > on such a hard piece of code, i can do the other "simple"
> > pieces (rop2, inc) in peace :-P
> I thought ROP2 was already finished?  The drawing in the manual looked
> pretty complete to me, and it even supports SIMD ;)
you're right for the SIMD ;-) but no VHDL exists yet.

> > If your work doesn't succeed, i remember that i have seen
> > an online form that generates all sorts of VHDL sources
> > for pipelined/straight/whatever arithmetic functions,
> > filters. I asked a pipeline 64*64 mul and it has spit a 1MB
> > file :-) so you're warned : a multiplier can be huge.
> Yes, and I'm afraid this one will be pretty big.  But I had another
> idea today, just in case we have space problems:  we can save almost 75%
> of space if we build a 32-bit multiplier instead.  No wait, please let
> me explain...
ok ok ok :-)

> Since the slices of SIMD operands are mutually independent, we don't
> have to calculate all SIMD results at the same time.  With a pipelined
> 32-bit multiplier that has a throughput of 1 op/cycle, we can split
> 64-bit quantities for all SIMD operations and calculate upper and
> lower half one after another.  This reduces SIMD throughput to 50%
> and adds 1 cycle of latency.  For full-size operations, we calculate
> 4 partial results in sequence (latency: +3 cycles, throughput: 25%),
> collect the results and feed them into the final, fully-sized stage.
> This saves even more space than the `serial 8x8 multiplier' approach
> (which had <66% saving) and runs SIMD multiplications faster.

hmmm if you're going to "vector" the SIMD chunks, you have to keep
buffers for each input and output value, and this can take some room.
schematics would be practical, too. But don't worry too much about
the multiplier : it's well-known for being silicon-hungry. if you keep the
latency and the pipeline stages short, this will work for the FC0.

have fun,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Jecel Assumpcao Jr Wed Oct 4 20:08:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00319 for ; Thu, 5 Oct 2000 07:44:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:12 +0200 (MEST) Received: (qmail 16768 invoked by uid 0); 4 Oct 2000 18:19:06 -0000 Received: from hk.egroups.com (208.50.99.220) by mx12.rz2.gmx.net with SMTP; 4 Oct 2000 18:19:06 -0000 X-eGroups-Return: sentto-1101623-1008-970683539-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 04 Oct 2000 18:19:03 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 18:18:59 -0000 Received: (qmail 26326 invoked from network); 4 Oct 2000 18:18:59 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 4 Oct 2000 18:18:59 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta2 with SMTP; 4 Oct 2000 18:18:55 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA32369 for ; Wed, 4 Oct 2000 15:30:16 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <200010040923.FAA03095@belegost.mit.edu> In-Reply-To: <200010040923.FAA03095@belegost.mit.edu> Message-Id: <00100415245800.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 15:08:44 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: de4cc3219b0d6726e3080f5d41013e28 Status: R X-Status: N Graham,
> from FPGA99:
>
> "Herman Schmit of Carnegie Mellon University demonstrated that a
> partially populated four-dimensional interconnect scheme -
> essentially, a hypercube - behaved much better under intensive
> routing demands than existing two-dimensional arrays."

Thanks - I hadn't seen this. I did some detailed comparison of
different connection architectures about 10 years ago. But it was for
packet switching networks, while in a FPGA you have circuit switching.
  
> but isn't scaling a problem? log n connections per cell for n cells still
> grows for large devices...

A 64 by 64 (4096 cells) device would be very large, yet it would only
need to connect to six neighbors in the same row and six others in the
same column. That isn't much.

> Built in RAM?

There are lots of things that should be added to the basic cell,
including RAM.

> How about the loading circuitry? Bit-serial load? Or direct addressing
> for each cell? (is that practical? I have no idea of the number of
> layers available or required to do this...)

Xilinx has direct addressing for each chip column. At least this much
flexibility should be available. It would be better to be able to load
each "basic cell" separately. If I remember correctly, the X6000 series
allowed you to address each programming bit individually, so that
should be possible too.

Yann,
> i'm not convinced 100% but it's promising :-)

I am not convinced either :-) Though it took me much longer to write it
down, I did mention that this is what I was able to come up with after
thinking about it for five minutes.

I have updated the page with a discussion of some problems. So that you
don't have to look at it again, I will mention the main one here: if
you do a 32 bit adder by fitting a 4 bit adder in 8 cells, you will
need 8 clocks to complete the operation since each cell only outputs
its carry out one clock after getting its carry in. Using two more
cells for look ahead would only reduce that to 3 clocks. There are a
few solutions, but it isn't trivial.

> maybe you need to communicate about this on the related newsgroups ?

Now that Xilinx is releasing free FPGA software, I should really
concentrate on gettting my cpu finished first.

-- Jecel
 From Jecel Assumpcao Jr Wed Oct 4 20:34:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00328 for ; Thu, 5 Oct 2000 07:44:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:15 +0200 (MEST) Received: (qmail 959 invoked by uid 0); 4 Oct 2000 18:48:34 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 4 Oct 2000 18:48:34 -0000 X-eGroups-Return: sentto-1101623-1009-970685300-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 04 Oct 2000 18:48:29 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 18:48:19 -0000 Received: (qmail 23597 invoked from network); 4 Oct 2000 18:46:39 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 4 Oct 2000 18:46:39 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 4 Oct 2000 18:46:37 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA32433 for ; Wed, 4 Oct 2000 15:57:59 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39D933ED.FE44813B@f-cpu.org> <39DB7716.D2992B7@f-cpu.org> In-Reply-To: <39DB7716.D2992B7@f-cpu.org> Message-Id: <00100415524001.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 15:34:32 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] icache Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 30ebcc22fc3274b33973bf538cf8ce3c Status: R X-Status: N Just one small question: what is the performance difference between a
true LRU cache replacement policy and a random replacement policy as a
function of the cache size?

If nobody knows this, then I hope that the current design effort is just
an exercise to learn VHDL and not typical of how the F-CPU will be
built...

-- Jecel
http://www.google.com/search?q=cache+LRU+random+replacement
 From Michael Riepe Wed Oct 4 14:36:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00382 for ; Thu, 5 Oct 2000 07:44:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:28 +0200 (MEST) Received: (qmail 21271 invoked by uid 0); 4 Oct 2000 23:05:19 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 4 Oct 2000 23:05:19 -0000 X-eGroups-Return: sentto-1101623-1010-970700702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 04 Oct 2000 23:05:08 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 23:04:53 -0000 Received: (qmail 26994 invoked from network); 4 Oct 2000 23:04:52 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 4 Oct 2000 23:04:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta1 with SMTP; 4 Oct 2000 23:04:45 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00542; Wed, 4 Oct 2000 14:36:45 +0200 Message-ID: <20001004143645.55085@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Tue, Oct 03, 2000 at 09:07:58PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 14:36:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4e608e66db1705f14870527af7125142 Status: R X-Status: N On Tue, Oct 03, 2000 at 09:07:58PM -0700, Colin Marquardt wrote:

> I have always seen "mask" as "mask something out", so if a mask bit is
> a one, the thing to mask (think of an interrupt) is not visible. But I
> have seen it the other 'round too (confuses me though).

In Software, you usually want to keep some bits and set the rest to 0.
This means you AND the bits you need with 1, others with 0.  This
differs from the meaning of `mask' in most other situations (unless
you define that the 0-bits form the mask, of course ;).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 4 14:54:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00385 for ; Thu, 5 Oct 2000 07:44:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:29 +0200 (MEST) Received: (qmail 29539 invoked by uid 0); 4 Oct 2000 23:05:20 -0000 Received: from jj.egroups.com (208.50.144.82) by mx12.rz2.gmx.net with SMTP; 4 Oct 2000 23:05:20 -0000 X-eGroups-Return: sentto-1101623-1011-970700705-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 04 Oct 2000 23:05:15 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 23:05:05 -0000 Received: (qmail 7265 invoked from network); 4 Oct 2000 23:05:05 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 4 Oct 2000 23:05:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta1 with SMTP; 4 Oct 2000 23:04:59 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00596; Wed, 4 Oct 2000 14:54:17 +0200 Message-ID: <20001004145417.57174@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <5qk3gJ705xJu> <39DA8915.B9DC273@starpower.net> X-Mailer: Mutt 0.84e In-Reply-To: <39DA8915.B9DC273@starpower.net>; from Alan Grimes on Tue, Oct 03, 2000 at 09:34:13PM -0400 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 4 Oct 2000 14:54:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] you decide Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 905696bd583776063407503c1abd7db6 Status: R X-Status: N On Tue, Oct 03, 2000 at 09:34:13PM -0400, Alan Grimes wrote:
> Somebody's gotta do somethings about the ammount of spam traffick on this
> list. =\
>
> --
> In this year's presidential race you *do* have a choice!
> VOTE Browne/Olivier The ticket to freedom!
> http://users.erols.com/alangrimes/  <my website.

You mean, this one?  I really don't care who's elected for president
in your country.

> ####### Begin Eschelon Block #######
> unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
> oklahoma city assault rifle randy weaver sog sof oliver north vince
> foster m-16 hillary clinton bill clinton marx crack m-60 c5 c7 mlk black
> panthers fbi chemical weapons twa 800 roswell white slavery history of us
> foreign policy terrorist freedom
> ####### End   Eschelon Block #######

Or this?

Keep your signature short, please.  And try to read RFC 1855 some day.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From jeff davies Thu Oct 5 01:47:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00391 for ; Thu, 5 Oct 2000 07:44:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:31 +0200 (MEST) Received: (qmail 13751 invoked by uid 0); 4 Oct 2000 23:47:17 -0000 Received: from fk.egroups.com (208.50.99.208) by mx19.rz2.gmx.net with SMTP; 4 Oct 2000 23:47:17 -0000 X-eGroups-Return: sentto-1101623-1012-970703220-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 04 Oct 2000 23:47:08 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 4 Oct 2000 23:47:00 -0000 Received: (qmail 23674 invoked from network); 4 Oct 2000 23:46:59 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 4 Oct 2000 23:46:59 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta3 with SMTP; 4 Oct 2000 23:46:59 -0000 Received: from modem-1.barium.dialup.pol.co.uk ([62.136.47.1] helo=llandre.freeserve.co.uk) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13gyFV-0002dz-00 for f-cpu@egroups.com; Thu, 05 Oct 2000 00:46:58 +0100 Sender: root@pop.gmx.net Message-ID: <39DBC193.E12BDEB1@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200010040923.FAA03095@belegost.mit.edu> <00100415245800.00384@gandalf> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 00:47:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ae7507f20386852e6b010eb68699478c Status: R X-Status: N > Yann,
> > i'm not convinced 100% but it's promising :-)
>
> I am not convinced either :-) Though it took me much longer to write it
> down, I did mention that this is what I was able to come up with after
> thinking about it for five minutes.
>

I think it is a very good start. I will keep the idea of a GPL design FPGA
on a slow burn.

>
> I have updated the page with a discussion of some problems. So that you
> don't have to look at it again, I will mention the main one here: if
> you do a 32 bit adder by fitting a 4 bit adder in 8 cells, you will
> need 8 clocks to complete the operation since each cell only outputs
> its carry out one clock after getting its carry in. Using two more
> cells for look ahead would only reduce that to 3 clocks. There are a
> few solutions, but it isn't trivial.
>

I found when I tried to make a 16 bit CPU in foundation that I kept hitting
architectural limits that were described (eg: run out of tristate lines),
but not much info on the ACTUAL architecture and how to tailor
your circuit. I used a big MUX instead made from AND/OR which then
maxed out the CLBs. Can manual placing be better than autoroute in
many cases. (Again this appeared difficult with Foundation).

>
> Now that Xilinx is releasing free FPGA software, I should really
> concentrate on gettting my cpu finished first.
>

I must have missed something.. what free FPGA software - i was
on their site just a couple of days ago...

Jeff Davies
eGroups Sponsor
From Michael Riepe Thu Oct 5 02:34:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00397 for ; Thu, 5 Oct 2000 07:44:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:32 +0200 (MEST) Received: (qmail 20401 invoked by uid 0); 5 Oct 2000 00:35:32 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 5 Oct 2000 00:35:32 -0000 X-eGroups-Return: sentto-1101623-1013-970706095-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 05 Oct 2000 00:34:57 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 00:34:55 -0000 Received: (qmail 22456 invoked from network); 5 Oct 2000 00:34:55 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 00:34:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta1 with SMTP; 5 Oct 2000 00:34:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00791; Thu, 5 Oct 2000 02:34:48 +0200 Message-ID: <20001005023448.33011@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DB82E2.9D19FF8E@f-cpu.org>; from Yann Guidon on Wed, Oct 04, 2000 at 08:20:02PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 02:34:48 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] several merged replies (cache+msic) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 20b3375cd0797e5c7f41c2c188b8fd73 Status: R X-Status: N On Wed, Oct 04, 2000 at 08:20:02PM +0100, Yann Guidon wrote:

> > for i in 1 to 100 loop
> >         write("I shall not write too many e-mails to f-cpu@egroups.com");
> > end loop; -- ;)
> nice but this doesn't count, you have forgotten the "writeline" ;-)

No, `write' is overloaded ;)  I just didn't show you that part ;)

> > I'd rather try alliance and savant first.  I *hate* binaries.
> > But I'd really love a CPU with source code :)
> so let's go :-)
> please, can you do the Alliance learning first,
> so i concentrate on the meat ? ;-) i have a paper doc and 2 distro CDs
> but no time to read that all :-/

First, I have to make some binaries... the Alliance build environment
is really ugly :(  You should see what they did to GNU autoconf...

> > > > SIMD division is particularly hard to implement...
> > > i don't think so. a simple shift-sub algo, with the carry that can
> > > be broken at different sizes... or a shift-sub that can be broken up
> > > if you prefer.
> > Yes.  But that's soooo sloooooooow...
> of course, it's slow, all int divides are slow.
> but when you need to divide a vector (SIMD or whatever) by a number,
> just compute the reciprocal, and multiply each element with this reciprocal.

That's what I usually do in flouting-point programs.

> this way, the "vector" divide is pipelinable. that's what all high-speed
> computers do. So maybe all we need is an integer "recip" ?

1/x (or 2^n/x) is still a division; it won't be much faster than y/x.

> > > we don't need much, only to write to the line that was used the least recently,
> > > and this is given by the FIFO's end value. et voila :-)
> > I understood that.  Amazing ;)
> > What happens to the read that triggered the fetch?
> it's managed outside the Icache element.

Yes... but will it be suspended, or aborted and retried?

[...]
> > > >         invalidate line
> > > >         fetch new data @addr (slow)
> > > >         revalidate line
> > > this is a bit unclear anyway...
> > Safety measure.  Maybe we can get away without it, but I'm not sure.
> let's keep it simple and working :-)

That's the point, exactly.

Invalidating a cache line has a side effect: the address/tag comparator
for that line will return `false'.  That has another side effect:
nobody can read from this line.  If nobody can read it, there will be
no collision with the writer (at least not in the Icache).  And if a
collision can't happen, we don't have to handle it.  Same principle as
in the IDIV unit: we *know* beforehand that the divisor won't be 0,
and there will be no overflow either, so we don't have to check for
(and handle) any exceptions.

[...and later...]
> > I'd rather avoid collisions at all than handle them.
> yep, but here we can't avoid the need that causes the collisions.

Really?

[...]
> but you can agree that there are FFs that have a preset, others have a reset,
> so instead of wasting space with a FSM that will init the LRU queue,
> let's use simple features that are easily hardwired. We're only beginning the
> design, we're still far from the synthesis and we still use behavioural code,
> so i think that it is not a huge problem now :-)

Ok, let's think it over some more times and defer the final decision.

[32-bit multiplier idea]
> hmmm if you're going to "vector" the SIMD chunks, you have to keep
> buffers for each input and output value, and this can take some room.

In case of a half-width pipeline, we need 3 additional 64-bit registers.
The pipeline is already full of them, so what?  48 9x9 booth multipliers
would take much more space (~1300 FFs).

> schematics would be practical, too. But don't worry too much about
> the multiplier : it's well-known for being silicon-hungry. if you keep the
> latency and the pipeline stages short, this will work for the FC0.

I just don't want that unit to become bigger than the Icache ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Thu Oct 5 05:08:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00400 for ; Thu, 5 Oct 2000 07:44:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:33 +0200 (MEST) Received: (qmail 15608 invoked by uid 0); 5 Oct 2000 02:04:41 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 5 Oct 2000 02:04:41 -0000 X-eGroups-Return: sentto-1101623-1014-970711475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 05 Oct 2000 02:04:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 02:04:34 -0000 Received: (qmail 26066 invoked from network); 5 Oct 2000 02:04:34 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 02:04:34 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 5 Oct 2000 02:04:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA13052 for ; Thu, 5 Oct 2000 04:04:30 +0200 (MET DST) Message-ID: <39DBF0BF.74592E65@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 04:08:47 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: baf1927964baeadf1bd885f3262bb1fa Status: R X-Status: N hi !

Jecel Assumpcao Jr wrote:
> Just one small question: what is the performance difference between a
> true LRU cache replacement policy and a random replacement policy as a
> function of the cache size?
the difference lies in the postulat.
a cache memory is based on the principle that at some place,
the memory access pattern will have some low "entropy", a locality/coherency
in space (address) and time. we've already discussed about it recently
(some weeks ago). the difference that i see between "true LRU" and
1-,2- or 4-way is that the restrictions are different. LRU is a bit more
resource-consuming but a direct mapped cache restricts the kind of entropy
to certain cases. For example, if you walk the memory with long strides
(for example when scanning a 2D array with y in the inner loop)
the thrashing is catastrophic. today no compiler is able or allowed
to change a loop nesting.

remember that i'm a performance freak and i like to win every percent
of speed where i see it ;-)

> If nobody knows this, then I hope that the current design effort is just
> an exercise to learn VHDL and not typical of how the F-CPU will be
> built...
the cache system is a special case in the FC0 architecture, but like the other
units, you can change the replacement strategy without jeopardizing the whole
design. This is also a way to see how we can work together and solve problems
in a mailing list environment. I still have to learn the use of "access" types
but i think that i have recently learnt the necesary background for a dumb design
(without synthesis constraints yet) so it's also a "food for thoughts"
that keeps the creativity going on :-)

> -- Jecel
> http://www.google.com/search?q=cache+LRU+random+replacement
did you search "fully associative" ? :-)

i looked at P&H/HW-SW interface, but they don't consider fully associative.
They expect some kind of random access pattern, which is contrary to the
first postulat of low entropy in space and time.
I hope that the testbench will give us some numbers to crunch.

Michael Riepe wrote:
> > > for i in 1 to 100 loop
> > >         write("I shall not write too many e-mails to f-cpu@egroups.com");
> > > end loop; -- ;)
> > nice but this doesn't count, you have forgotten the "writeline" ;-)
> No, `write' is overloaded ;)  I just didn't show you that part ;)
grrrrr ! :-)

> > please, can you do the Alliance learning first,
> > so i concentrate on the meat ? ;-) i have a paper doc and 2 distro CDs
> > but no time to read that all :-/
> First, I have to make some binaries... the Alliance build environment
> is really ugly :(  You should see what they did to GNU autoconf...
maybe you can try savant then ?

> > > > > SIMD division is particularly hard to implement...
> > > > i don't think so. a simple shift-sub algo, with the carry that can
> > > > be broken at different sizes... or a shift-sub that can be broken up
> > > > if you prefer.
> > > Yes.  But that's soooo sloooooooow...
> > of course, it's slow, all int divides are slow.
> > but when you need to divide a vector (SIMD or whatever) by a number,
> > just compute the reciprocal, and multiply each element with this reciprocal.
> That's what I usually do in flouting-point programs.
flouting what ? :-)

you know, the recip trick works in the integer domain too.

> > this way, the "vector" divide is pipelinable. that's what all high-speed
> > computers do. So maybe all we need is an integer "recip" ?
> 1/x (or 2^n/x) is still a division; it won't be much faster than y/x.
it removes a multiply at the end, we don't have to fetch 2 operands but one...
but i prefer to keep the usual integer div/mod instructions to avoid dumb
problems in the future.

what i wanted to say is that i knew that idiv is slow but it's not much used
and usually people don't expect much speed from this. i expect that it will be
mostly used for bin to/from dec base conversions or something like that.
Evans & Eckhouse (in a book about programming the Alpha that i use as a mousepad)
show that it is possible (with some precautions) to use the "recip" recipe
for this case too. You just have compute the recip with the usual div instruction
and (since the conversion base doesn't change), you can reuse the reciprocal
for all the stages of the conversion. This will "burn" one big divide and several
multiplies that you said are trying to optimize :-)

> > > > we don't need much, only to write to the line that was used the least recently,
> > > > and this is given by the FIFO's end value. et voila :-)
> > > I understood that.  Amazing ;)
> > > What happens to the read that triggered the fetch?
> > it's managed outside the Icache element.
> Yes... but will it be suspended, or aborted and retried?
it's delayed. or whatever makes most sense and keeps the complexity low.

> [...]
> > > > >         invalidate line
> > > > >         fetch new data @addr (slow)
> > > > >         revalidate line
> > > > this is a bit unclear anyway...
> > > Safety measure.  Maybe we can get away without it, but I'm not sure.
> > let's keep it simple and working :-)
> That's the point, exactly.
>
> Invalidating a cache line has a side effect: the address/tag comparator
> for that line will return `false'.  That has another side effect:
> nobody can read from this line.
true, until it goes at the end of the FIFO. but it was already at the
end of the FIFO so we have NBLINES cycles max to fill the line,
because the LRU gets updated/rotated (the last becomes the recent).
is it what you mean ?

>  If nobody can read it, there will be
> no collision with the writer (at least not in the Icache).  And if a
> collision can't happen, we don't have to handle it.  Same principle as
> in the IDIV unit: we *know* beforehand that the divisor won't be 0,
> and there will be no overflow either, so we don't have to check for
> (and handle) any exceptions.
i'm beginning to see what you mean. but do you fear that something like
that will be hard to debug ? how will you see where a problem is
if the symptoms depend on a lot of different units ?

Anyway, here is the scheduling of the operation on a read :
- read address bus and Read_En are setup, clock cycle is started
- the tag address block compares all the addresses
- end of the cycle : cache_hit is refreshed
* remark : we can't decide yet what line to invalidate
- start of the next cycle : line select signal is sent and the data is brought
    on the output data bus.
- in the same time, we invalidate the LRU line and keep this number as
    a "transaction ID" for the future write.
* remark : what if we hit a non-cachable memory region ? we'll finally flush
    all the cache and no data will be written back after it is consumed once.
* remark 2 : if we can have N lines and M ongoing transactions, we still
    can benefit from only N-M lines.
unless there's still some things i haven't understood.

> [...and later...]
> > > I'd rather avoid collisions at all than handle them.
> > yep, but here we can't avoid the need that causes the collisions.
> Really?
we have several independent units that can emit orders.
We naturally must put a prioritizing element to sort the access
(round-robin or Ifetch priority)

> [...]
> > but you can agree that there are FFs that have a preset, others have a reset,
> > so instead of wasting space with a FSM that will init the LRU queue,
> > let's use simple features that are easily hardwired. We're only beginning the
> > design, we're still far from the synthesis and we still use behavioural code,
> > so i think that it is not a huge problem now :-)
> Ok, let's think it over some more times and defer the final decision.
yup. i'll try to make a nice configurable generic'ed VHDL rewrite.

> [32-bit multiplier idea]
> > hmmm if you're going to "vector" the SIMD chunks, you have to keep
> > buffers for each input and output value, and this can take some room.
> In case of a half-width pipeline, we need 3 additional 64-bit registers.
> The pipeline is already full of them, so what?  48 9x9 booth multipliers
> would take much more space (~1300 FFs).
what i had in mind is : there's no need to hold the data when they can
be needed urgently somewhere else. we can't do partial register forwarding
and i would prefer a big fat multiplier to a complex small one.
go for speed and simplicity : they go well along each other :-)
remember that if we want to beat the Alpha and the IA-64, we need
similar weapons ;-)

> > schematics would be practical, too. But don't worry too much about
> > the multiplier : it's well-known for being silicon-hungry. if you keep the
> > latency and the pipeline stages short, this will work for the FC0.
> I just don't want that unit to become bigger than the Icache ;)
i don't think that it's an issue, and certainly not for the prototypes
which will be certainly unbalanced. The multiplier often becomes crucial
for codes where the memory bandwidth is the limiting factor, cache management
is more important than the size. in other words, it's not what you have
but how you use it that matters, in this case :-)
if your multiplier is more compact and more complex to use, it's not
worth the effort.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"



Michael Riepe wrote:
>
> On Tue, Oct 03, 2000 at 09:07:58PM -0700, Colin Marquardt wrote:
>
> > I have always seen "mask" as "mask something out", so if a mask bit is
> > a one, the thing to mask (think of an interrupt) is not visible. But I
> > have seen it the other 'round too (confuses me though).
>
> In Software, you usually want to keep some bits and set the rest to 0.
> This means you AND the bits you need with 1, others with 0.  This
> differs from the meaning of `mask' in most other situations (unless
> you define that the 0-bits form the mask, of course ;).

so, what do we do ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From berkane Thu Oct 5 07:06:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00403 for ; Thu, 5 Oct 2000 07:44:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:36 +0200 (MEST) Received: (qmail 12598 invoked by uid 0); 5 Oct 2000 05:04:35 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 5 Oct 2000 05:04:35 -0000 X-eGroups-Return: sentto-1101623-1015-970722269-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 05 Oct 2000 05:04:31 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:29 -0000 Received: (qmail 22285 invoked from network); 5 Oct 2000 05:04:29 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 05:04:29 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:04:27 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556WM00865 for ; Thu, 5 Oct 2000 07:06:33 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C58.FE781FF8@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:32 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Open Your Mind To Exciting Opportunities 76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 833fdb4c7460f239980ef361d9d61b06 Status: R X-Status: N busy1@kidzmail.com.au a =E9crit :
>
> LOOKING FOR GEMS!
>
> It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
> We're searching for only 10 elite individuals with the work ethic
> necessary to generate a cash-flow for themselves of $2,000 - $5,000per=
> week, and to increase that to over $20,000 per month, in as little as<= BR> > four to six months. And you know what? If you really have a burning > desire and commitment, we guarantee you that you'll reach this
> explosive income!
>
> Can you read a short script to our qualified leads, and then turn the<= BR> > interested prospects over to our electronic sales medium? (you will > not be required to do any selling.)Do you have the self-discipline to<= BR> > ignore the TV for a couple of hours per day? Are you looking for a
> legitimate home-based business opportunity, that is not multi-level > marketing, or a chain-letter scheme?
>
> If you would like to build an amazing income that will grow
> lightning-fast and have you profit $1,000.00 every time only one
> prospect makes a purchase, then this is for you! You can build the
> business under our guidance and support without having to attend
> meetings or sell people things they don't need.
>
> Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-742-6549 ext. 6500=
>
> We market a real product, that pays real commissions to you,$1,000.00<= BR> > per sale, just for making the initial contacts. With our turn-key lead=
> generation systems you'll always talk to people who actually WANT to > talk to you.
>
> You have nothing to lose, there's no risk involved, nor is there any > obligation whatsoever, and you may be qualified to earn thousands of > extra dollars per month! So call now!
>
> The call is FREE, and there is absolutely no obligation, So what have<= BR> > you got to lose?
>
> Call Toll Free 1-800-742-6549 ext. 6500
>
> P.S. You literally have a once-in-a-lifetime opportunity to GET
> INVOLVED NOW! Don't let this one go by. You have absolutely nothing to=
> lose! This could be the most fascinating and profitable business of > your life!
>
> Please, serious inquiries only.
>
> To be removed from future mailings send a blank email with remove in > the subject line and
> the email address or addresses to be removed in the body to
> busy1@kidzmail.com.au
>
> LOOKING FOR GEMS!
>
> It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
>
> We're searching for only 10 elite individuals with the work ethic
> necessary to generate a cash-flow for themselves of $2,000 - $5,000per=
> week, and to increase that to over $20,000 per month, in as little as<= BR> > four to six months. And you know what? If you really have a burning > desire and commitment, we guarantee you that you'll reach this
> explosive income!
>
> Can you read a short script to our qualified leads, and then turn the<= BR> > interested prospects over to our electronic sales medium? (you will > not be required to do any selling.)Do you have the self-discipline to<= BR> > ignore the TV for a couple of hours per day? Are you looking for a
> legitimate home-based business opportunity, that is not multi-level > marketing, or a chain-letter scheme?

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:06:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00406 for ; Thu, 5 Oct 2000 07:44:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:37 +0200 (MEST) Received: (qmail 28722 invoked by uid 0); 5 Oct 2000 05:04:37 -0000 Received: from jj.egroups.com (208.50.144.82) by mx06.rz2.gmx.net with SMTP; 5 Oct 2000 05:04:37 -0000 X-eGroups-Return: sentto-1101623-1016-970722275-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 05 Oct 2000 05:04:32 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:35 -0000 Received: (qmail 23387 invoked from network); 5 Oct 2000 05:04:35 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:04:35 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:04:33 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556dM00870 for ; Thu, 5 Oct 2000 07:06:39 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C5F.9D65EEA8@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200010021802.OAA15272@belegost.mit.edu> <00100319582302.05678@gandalf> <39DA81DE.7513337E@f-cpu.org> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6c8c7669a051f2306db93fb83661749c Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi,
>
> Jecel Assumpcao Jr wrote:
> > As promised:
> >   http://www= .merlintec.com/fpga/
> i'm not convinced 100% but it's promising :-)
> maybe you need to communicate about this on
> the related newsgroups ?
>
> > Enjoy,
> nice xfig :-)
> > -- Jecel
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:06:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00409 for ; Thu, 5 Oct 2000 07:44:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:37 +0200 (MEST) Received: (qmail 5960 invoked by uid 0); 5 Oct 2000 05:04:44 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 5 Oct 2000 05:04:44 -0000 X-eGroups-Return: sentto-1101623-1017-970722279-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 05 Oct 2000 05:04:40 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:39 -0000 Received: (qmail 23567 invoked from network); 5 Oct 2000 05:04:39 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:04:39 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:04:37 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556hM00875 for ; Thu, 5 Oct 2000 07:06:43 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C63.CE2E9BBD@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200010021802.OAA15272@belegost.mit.edu> <00100319582302.05678@gandalf> <39DA81DE.7513337E@f-cpu.org> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:43 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 44e2823aa347d382e023a583d60696e4 Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi,
>
> Jecel Assumpcao Jr wrote:
> > As promised:
> >   http://www= .merlintec.com/fpga/
> i'm not convinced 100% but it's promising :-)
> maybe you need to communicate about this on
> the related newsgroups ?
>
> > Enjoy,
> nice xfig :-)
> > -- Jecel
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:06:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00412 for ; Thu, 5 Oct 2000 07:44:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:38 +0200 (MEST) Received: (qmail 20756 invoked by uid 0); 5 Oct 2000 05:04:47 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 5 Oct 2000 05:04:47 -0000 X-eGroups-Return: sentto-1101623-1018-970722285-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 05 Oct 2000 05:04:43 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:45 -0000 Received: (qmail 22795 invoked from network); 5 Oct 2000 05:04:45 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 5 Oct 2000 05:04:45 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:04:43 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556nM00880 for ; Thu, 5 Oct 2000 07:06:49 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C69.6569E026@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <5qk3gJ705xJu> <39DA8915.B9DC273@starpower.net> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] you decide Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 19e1cb34c8323b2e9808e4bb56c873be Status: R X-Status: N Alan Grimes a =E9crit :
>
> Somebody's gotta do somethings about the ammount of spam traffick on t= his
> list. =3D\
>
> --
> In this year's presidential race you *do* have a choice!
> VOTE Browne/Olivier The ticket to freedom!
> http://users.erols.com/= alangrimes/  <my website.
>
> ####### Begin Eschelon Block #######
> unibomber anthrax plutonium militia delta force ruby ridge atf batf wa= co
> oklahoma city assault rifle randy weaver sog sof oliver north vince > foster m-16 hillary clinton bill clinton marx crack m-60 c5 c7 mlk bla= ck
> panthers fbi chemical weapons twa 800 roswell white slavery history of= us
> foreign policy terrorist freedom
> ####### End   Eschelon Block #######
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:06:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00415 for ; Thu, 5 Oct 2000 07:44:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:38 +0200 (MEST) Received: (qmail 12945 invoked by uid 0); 5 Oct 2000 05:04:53 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 5 Oct 2000 05:04:53 -0000 X-eGroups-Return: sentto-1101623-1019-970722289-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 05 Oct 2000 05:04:51 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:49 -0000 Received: (qmail 25375 invoked from network); 5 Oct 2000 05:04:48 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 5 Oct 2000 05:04:48 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:04:47 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556rM00885 for ; Thu, 5 Oct 2000 07:06:53 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C6D.8CB58CE7@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> <39DA6CF7.2FF43696@f-cpu.org> <20001004044747.48281@thrai.stud.uni-hannover.de> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:53 +0200 Reply-To: f-cpu@egroups.com Subject: Re: CVS (was: Re: [f-cpu] (v) happy :-)) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d1567f3d1a66978c82d51680025552b9 Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Wed, Oct 04, 2000 at 12:34:15AM +0100, Yann Guidon wrote:
>
> > > I really do recommend CVS for every project that consist of = 3 or more
> > > files.  I've used it for more than five years now and I= 'm quite satisfied.
> > > You may have noticed that I checked in my icache.vhdl, too := )
> >
> > i don't understand *where*/how you did that. do you have your own=
> > private tree ? :-)
>
> I have three repositories of my own, two locally and one remote.
> And I use several others (public, read-only repositories from some
> projects I'm interested in).
>
> > > I just don't like _remote_ repositories, because
> [...]
> > >         4) I always = forget to change CVSROOT ;)
> > heh. if at least i knew what this meant ;-P
>
> CVSROOT is a shell variable that points to the root directory of the > repository you use.
>
> CVS isn't hard to use at all, and you can set it up with only a few st= eps.
> Those of you who are interested in CVS should read the CVS documentati= on
> (cvs.info, normally).  It contains a short introduction, too.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:07:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00418 for ; Thu, 5 Oct 2000 07:44:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:39 +0200 (MEST) Received: (qmail 4705 invoked by uid 0); 5 Oct 2000 05:05:06 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net with SMTP; 5 Oct 2000 05:05:06 -0000 X-eGroups-Return: sentto-1101623-1022-970722303-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 05 Oct 2000 05:05:05 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:05:03 -0000 Received: (qmail 23383 invoked from network); 5 Oct 2000 05:05:03 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 5 Oct 2000 05:05:03 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:05:01 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e95577M00900 for ; Thu, 5 Oct 2000 07:07:07 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C7B.4773E0C3@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> <20001004053239.48460@thrai.stud.uni-hannover.de> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:07:07 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 38df14c235a2b031f33b218fe27d74f7 Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Wed, Oct 04, 2000 at 12:34:13AM +0100, Yann Guidon wrote:
>
> > BUUUUUT now that i have it in mind, i see that the "range&qu= ot; argument can't
> > be used for our design : the LRU FIFO can only manage 1 request a= t a time.
> > i guess that the range/mask will be ignored before we find a suit= able solution.
>
> Another good reason why only reads should trigger an LRU update ;)
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:07:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00421 for ; Thu, 5 Oct 2000 07:44:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:40 +0200 (MEST) Received: (qmail 13226 invoked by uid 0); 5 Oct 2000 05:05:11 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 5 Oct 2000 05:05:11 -0000 X-eGroups-Return: sentto-1101623-1023-970722307-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 05 Oct 2000 05:05:10 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:05:07 -0000 Received: (qmail 11246 invoked from network); 5 Oct 2000 05:05:07 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 05:05:07 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:05:05 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9557BM00905 for ; Thu, 5 Oct 2000 07:07:11 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C7F.23C6CD4A@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:07:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) happy :-) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fecfc5bf8add53b7ba3808e256ab43a8 Status: R X-Status: N Colin Marquardt a =E9crit :
>
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> > I just don't like _remote_ repositories, because
>
> >       1) I have a dial-up connectio= n.
> >       2) I don't have direct access= to them (can't move/rename files internally).
> >       3) It's hard to keep two repo= sitories in sync.
> >       4) I always forget to change = CVSROOT ;)
>
> > But I guess I can live with it somehow.  I have to, after al= l.
>
> I also only have a modem, albeit with a flat rate. But many
> developers are using CVS and are in the same situation...
>
> > NB: I have a local repository that contains >800 MByte of sour= ces for
> > my own Linux system.  I never installed any binary distribut= ions after
> > the initial SLS in '92 :)
>
> That is really cool :-) I also wonder why I even have a distribution > since my /usr/local is filled up too...
>
> Cheers,
>   Colin
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:07:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00424 for ; Thu, 5 Oct 2000 07:44:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:40 +0200 (MEST) Received: (qmail 32092 invoked by uid 0); 5 Oct 2000 05:05:29 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 5 Oct 2000 05:05:29 -0000 X-eGroups-Return: sentto-1101623-1021-970722299-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 05 Oct 2000 05:05:28 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:59 -0000 Received: (qmail 23204 invoked from network); 5 Oct 2000 05:04:58 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 05:04:58 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:04:57 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e95573M00895 for ; Thu, 5 Oct 2000 07:07:03 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C76.24463433@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:07:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) testbench attempt (+re) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: aaba43cd3b8d62d19c4270649695c95a Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Wed, Oct 04, 2000 at 01:14:23AM +0100, Yann Guidon wrote:
> > hi again again again,
>
> for i in 1 to 100 loop
>         write("I shall no= t write too many e-mails to f-cpu@egroups.com");
> end loop; -- ;)
>
> > > Yep, but it's hard to boot NT again and again...
> > do you mean that Simili crashes NT ? :-)
>
> No... but I have to switch between NT and Linux.
>
> > i too am waiting for the release of the Linux version.
> > and it will be in binary form ;-)
>
> I'd rather try alliance and savant first.  I *hate* binaries.
> But I'd really love a CPU with source code :)
>
> > > I downloaded Alliance 4.0.6 yesterday and will try that on L= inux
> > > (if I can compile it with XFree86 3.3.5 and OpenMotif 2.1.30= ).
> > good luck !
>
> Hmm... I will need that.  BTW: I also tried electric; it compiled=
> fine with Motif, but the display had lots of ugly glitches that made > it unusable.
>
> > isn't XF4 released ? or ...
>
> Yes it is, but it doesn't run on all cards.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Thu Oct 5 07:06:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00427 for ; Thu, 5 Oct 2000 07:44:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:41 +0200 (MEST) Received: (qmail 17206 invoked by uid 0); 5 Oct 2000 05:05:32 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 5 Oct 2000 05:05:32 -0000 X-eGroups-Return: sentto-1101623-1020-970722295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 05 Oct 2000 05:05:26 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:04:55 -0000 Received: (qmail 10826 invoked from network); 5 Oct 2000 05:04:54 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:04:54 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:04:53 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9556wM00890 for ; Thu, 5 Oct 2000 07:06:59 +0200 Sender: root@localhost.localdomain Message-ID: <39DC0C72.9DECA629@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D3F68C.5896123D@f-cpu.org> <20000930014825.05136@thrai.stud.uni-hannover.de> <39D5FBA0.676BA52D@f-cpu.org> <00100101312101.00382@gandalf> <20001002153050.57678@thrai.stud.uni-hannover.de> <39D9F4E0.D6437165@welfen-netz.com> <20001003193839.21479@thrai.stud.uni-hannover.de> <39DA6CF8.2108DAC2@f-cpu.org> <20001004051537.26563@thrai.stud.uni-hannover.de> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 07:06:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: multiplies (was : Re: [f-cpu] cache design) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 333ccec8223d9262a14d681b98c8f64e Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Wed, Oct 04, 2000 at 12:34:16AM +0100, Yann Guidon wrote:
>
> > well, since i haven't gone down this road yet,
> > i only admire and respect this work. With you working
> > on such a hard piece of code, i can do the other "simple&quo= t;
> > pieces (rop2, inc) in peace :-P
>
> I thought ROP2 was already finished?  The drawing in the manual l= ooked
> pretty complete to me, and it even supports SIMD ;)
>
> > anyway there is a constraint that you are asked to
> > comply with : for each allowed operation (ie :
> > SIMD 8*8, int 32*32 etc) you must indicate the
> > latency and throughput. This is important for the
> > scheduler so it can determine the instruction slots
> > at decode time and allocate the write slots of the
> > Xbar. Of course i leave you some time to complete (or not)
> > the multiplier. just don't forget the specific scheduling
> > constraints of the FC0.
>
> I'm aware of that.
>
> > If your work doesn't succeed, i remember that i have seen
> > an online form that generates all sorts of VHDL sources
> > for pipelined/straight/whatever arithmetic functions,
> > filters. I asked a pipeline 64*64 mul and it has spit a 1MB
> > file :-) so you're warned : a multiplier can be huge.
>
> Yes, and I'm afraid this one will be pretty big.  But I had anoth= er
> idea today, just in case we have space problems:  we can save alm= ost 75%
> of space if we build a 32-bit multiplier instead.  No wait, pleas= e let
> me explain...
>
> Since the slices of SIMD operands are mutually independent, we don't > have to calculate all SIMD results at the same time.  With a pipe= lined
> 32-bit multiplier that has a throughput of 1 op/cycle, we can split > 64-bit quantities for all SIMD operations and calculate upper and
> lower half one after another.  This reduces SIMD throughput to 50= %
> and adds 1 cycle of latency.  For full-size operations, we calcul= ate
> 4 partial results in sequence (latency: +3 cycles, throughput: 25%), > collect the results and feed them into the final, fully-sized stage. > This saves even more space than the `serial 8x8 multiplier' approach > (which had <66% saving) and runs SIMD multiplications faster.
>
> > That, and the adders, are two critical units, though.
>
> Yep.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From billou@microthief.com Thu Oct 5 07:09:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00430 for ; Thu, 5 Oct 2000 07:44:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:42 +0200 (MEST) Received: (qmail 15238 invoked by uid 0); 5 Oct 2000 05:07:52 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:52 -0000 X-eGroups-Return: sentto-1101623-1024-970722466-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 05 Oct 2000 05:07:47 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:46 -0000 Received: (qmail 31036 invoked from network); 5 Oct 2000 05:07:46 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:07:46 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:43 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559n400927; Thu, 5 Oct 2000 07:09:49 +0200 Message-Id: <200010050509.e9559n400927@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:49 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 639128fa9fca7fede68a54119d361ca2 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Click here and you can even personalize these quotes. http://click.egroups.com/1/9536/15/_/3462/_/970722466/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00433 for ; Thu, 5 Oct 2000 07:44:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:43 +0200 (MEST) Received: (qmail 8186 invoked by uid 0); 5 Oct 2000 05:07:52 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:52 -0000 X-eGroups-Return: sentto-1101623-1026-970722467-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 05 Oct 2000 05:07:48 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:47 -0000 Received: (qmail 28205 invoked from network); 5 Oct 2000 05:07:47 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 5 Oct 2000 05:07:47 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:44 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559oj00933; Thu, 5 Oct 2000 07:09:50 +0200 Message-Id: <200010050509.e9559oj00933@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:50 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: dac3cf92c7bdb1873e0b94ed2b51518f Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Call 1-800-555-TELL. http://click.egroups.com/1/9535/15/_/3462/_/970722467/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00436 for ; Thu, 5 Oct 2000 07:44:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:43 +0200 (MEST) Received: (qmail 11040 invoked by uid 0); 5 Oct 2000 05:07:53 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:53 -0000 X-eGroups-Return: sentto-1101623-1029-970722469-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 05 Oct 2000 05:07:50 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:49 -0000 Received: (qmail 28244 invoked from network); 5 Oct 2000 05:07:49 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 5 Oct 2000 05:07:49 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:46 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559pR00942; Thu, 5 Oct 2000 07:09:51 +0200 Message-Id: <200010050509.e9559pR00942@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:51 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: a703dd3c17f74baa897afbf48b62cc9a Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970722469/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00439 for ; Thu, 5 Oct 2000 07:44:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:44 +0200 (MEST) Received: (qmail 15275 invoked by uid 0); 5 Oct 2000 05:07:54 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:54 -0000 X-eGroups-Return: sentto-1101623-1025-970722466-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 05 Oct 2000 05:07:48 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:46 -0000 Received: (qmail 30106 invoked from network); 5 Oct 2000 05:07:46 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:46 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:44 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559nK00930; Thu, 5 Oct 2000 07:09:49 +0200 Message-Id: <200010050509.e9559nK00930@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:49 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: a2a9942e72cb8a34cc7f6448d3341b8e Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722466/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00442 for ; Thu, 5 Oct 2000 07:44:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:45 +0200 (MEST) Received: (qmail 7781 invoked by uid 0); 5 Oct 2000 05:07:56 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:56 -0000 X-eGroups-Return: sentto-1101623-1033-970722472-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 05 Oct 2000 05:07:53 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:52 -0000 Received: (qmail 28344 invoked from network); 5 Oct 2000 05:07:52 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 05:07:52 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:50 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559rp00954; Thu, 5 Oct 2000 07:09:53 +0200 Message-Id: <200010050509.e9559rp00954@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:53 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 0a674255b1f5ab2a617b86bfd951b501 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970722473/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00445 for ; Thu, 5 Oct 2000 07:44:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:45 +0200 (MEST) Received: (qmail 19388 invoked by uid 0); 5 Oct 2000 05:07:56 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:56 -0000 X-eGroups-Return: sentto-1101623-1032-970722472-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 05 Oct 2000 05:07:52 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:52 -0000 Received: (qmail 16167 invoked from network); 5 Oct 2000 05:07:51 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Oct 2000 05:07:51 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:49 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559rE00951; Thu, 5 Oct 2000 07:09:53 +0200 Message-Id: <200010050509.e9559rE00951@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:53 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 77b2b3d0ada1348e86fc0a5ce6c296ad Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Click here and you can even personalize these quotes. http://click.egroups.com/1/9536/15/_/3462/_/970722472/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00448 for ; Thu, 5 Oct 2000 07:44:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:46 +0200 (MEST) Received: (qmail 11099 invoked by uid 0); 5 Oct 2000 05:07:57 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:57 -0000 X-eGroups-Return: sentto-1101623-1027-970722468-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ei.egroups.com with NNFMP; 05 Oct 2000 05:07:50 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:48 -0000 Received: (qmail 28227 invoked from network); 5 Oct 2000 05:07:48 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 5 Oct 2000 05:07:48 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:45 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559oY00936; Thu, 5 Oct 2000 07:09:50 +0200 Message-Id: <200010050509.e9559oY00936@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:50 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 49c5e582cc22c6ab1db969bb58446249 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Call 1-800-555-TELL. For more info visit: http://click.egroups.com/1/9533/15/_/3462/_/970722468/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00451 for ; Thu, 5 Oct 2000 07:44:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:46 +0200 (MEST) Received: (qmail 19424 invoked by uid 0); 5 Oct 2000 05:07:59 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 5 Oct 2000 05:07:59 -0000 X-eGroups-Return: sentto-1101623-1031-970722471-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 05 Oct 2000 05:07:49 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:51 -0000 Received: (qmail 16145 invoked from network); 5 Oct 2000 05:07:51 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 05:07:51 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:48 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559q100948; Thu, 5 Oct 2000 07:09:52 +0200 Message-Id: <200010050509.e9559q100948@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:52 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 1e49a10d0bbe34b68956e2ab61bc1cbc Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970722471/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00454 for ; Thu, 5 Oct 2000 07:44:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:47 +0200 (MEST) Received: (qmail 30764 invoked by uid 0); 5 Oct 2000 05:08:00 -0000 Received: from mo.egroups.com (208.50.144.78) by mx12.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:00 -0000 X-eGroups-Return: sentto-1101623-1036-970722475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mo.egroups.com with NNFMP; 05 Oct 2000 05:07:57 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:55 -0000 Received: (qmail 30375 invoked from network); 5 Oct 2000 05:07:55 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:55 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:52 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559uj00963; Thu, 5 Oct 2000 07:09:56 +0200 Message-Id: <200010050509.e9559uj00963@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:56 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 6cde50e996806b02490174acca77d8a9 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Call 1-800-555-TELL. For more info visit: http://click.egroups.com/1/9533/15/_/3462/_/970722475/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00457 for ; Thu, 5 Oct 2000 07:44:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:48 +0200 (MEST) Received: (qmail 4633 invoked by uid 0); 5 Oct 2000 05:08:00 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:00 -0000 X-eGroups-Return: sentto-1101623-1039-970722477-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 05 Oct 2000 05:07:58 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:57 -0000 Received: (qmail 30430 invoked from network); 5 Oct 2000 05:07:57 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:57 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:07:54 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559wA00972; Thu, 5 Oct 2000 07:09:58 +0200 Message-Id: <200010050509.e9559wA00972@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:58 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 9533b05be2bf456d57d3efa1d9fac298 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970722477/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00460 for ; Thu, 5 Oct 2000 07:44:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:49 +0200 (MEST) Received: (qmail 11175 invoked by uid 0); 5 Oct 2000 05:08:00 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:00 -0000 X-eGroups-Return: sentto-1101623-1035-970722474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mu.egroups.com with NNFMP; 05 Oct 2000 05:07:57 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:54 -0000 Received: (qmail 30351 invoked from network); 5 Oct 2000 05:07:54 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:54 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:51 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559uR00960; Thu, 5 Oct 2000 07:09:56 +0200 Message-Id: <200010050509.e9559uR00960@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:56 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 8b507b208d389c7b399784c9e8d4d58f Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Access Tellme from any phone. For more info visit: http://click.egroups.com/1/9534/15/_/3462/_/970722474/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00463 for ; Thu, 5 Oct 2000 07:44:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:49 +0200 (MEST) Received: (qmail 11179 invoked by uid 0); 5 Oct 2000 05:08:00 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:00 -0000 X-eGroups-Return: sentto-1101623-1028-970722468-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ei.egroups.com with NNFMP; 05 Oct 2000 05:07:56 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:48 -0000 Received: (qmail 30180 invoked from network); 5 Oct 2000 05:07:48 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:48 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:46 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559pr00939; Thu, 5 Oct 2000 07:09:51 +0200 Message-Id: <200010050509.e9559pr00939@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:51 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 5a6434601792360f3a655316a499950e Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9335/15/_/3462/_/970722468/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00466 for ; Thu, 5 Oct 2000 07:44:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:50 +0200 (MEST) Received: (qmail 30241 invoked by uid 0); 5 Oct 2000 05:08:01 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:01 -0000 X-eGroups-Return: sentto-1101623-1030-970722470-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 05 Oct 2000 05:07:57 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:50 -0000 Received: (qmail 30223 invoked from network); 5 Oct 2000 05:07:50 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:50 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:48 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559pn00945; Thu, 5 Oct 2000 07:09:51 +0200 Message-Id: <200010050509.e9559pn00945@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:51 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: d778c5bdcc5a92bfe01731240bff56c2 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722470/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00469 for ; Thu, 5 Oct 2000 07:44:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:51 +0200 (MEST) Received: (qmail 30842 invoked by uid 0); 5 Oct 2000 05:08:02 -0000 Received: from mo.egroups.com (208.50.144.78) by mx12.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:02 -0000 X-eGroups-Return: sentto-1101623-1037-970722475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 05 Oct 2000 05:07:58 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:55 -0000 Received: (qmail 28469 invoked from network); 5 Oct 2000 05:07:55 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 05:07:55 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:53 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559vD00966; Thu, 5 Oct 2000 07:09:57 +0200 Message-Id: <200010050509.e9559vD00966@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:57 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 4b9b35d41c7f6694ac5e943fe04c5d86 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722475/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00472 for ; Thu, 5 Oct 2000 07:44:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:51 +0200 (MEST) Received: (qmail 8373 invoked by uid 0); 5 Oct 2000 05:08:03 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:03 -0000 X-eGroups-Return: sentto-1101623-1038-970722476-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 05 Oct 2000 05:07:57 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:56 -0000 Received: (qmail 30400 invoked from network); 5 Oct 2000 05:07:56 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:56 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:53 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559wk00969; Thu, 5 Oct 2000 07:09:58 +0200 Message-Id: <200010050509.e9559wk00969@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:58 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 6c672f232bc0eea8bce0a11ad6cb3acc Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Call 1-800-555-TELL. http://click.egroups.com/1/9535/15/_/3462/_/970722476/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00475 for ; Thu, 5 Oct 2000 07:44:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:52 +0200 (MEST) Received: (qmail 29994 invoked by uid 0); 5 Oct 2000 05:08:04 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:04 -0000 X-eGroups-Return: sentto-1101623-1042-970722480-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 05 Oct 2000 05:08:00 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:00 -0000 Received: (qmail 16401 invoked from network); 5 Oct 2000 05:07:59 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:07:59 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:07:57 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A1f00983; Thu, 5 Oct 2000 07:10:01 +0200 Message-Id: <200010050510.e955A1f00983@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:01 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 8e93d65fd5f149b22af8e77a1edf6e1a Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. http://click.egroups.com/1/9530/15/_/3462/_/970722480/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00478 for ; Thu, 5 Oct 2000 07:44:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:53 +0200 (MEST) Received: (qmail 1769 invoked by uid 0); 5 Oct 2000 05:08:04 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:04 -0000 X-eGroups-Return: sentto-1101623-1043-970722481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 05 Oct 2000 05:08:00 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:00 -0000 Received: (qmail 16426 invoked from network); 5 Oct 2000 05:08:00 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:00 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:07:58 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A2r00986; Thu, 5 Oct 2000 07:10:02 +0200 Message-Id: <200010050510.e955A2r00986@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:02 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 043488aff2c72aca79bfcdfe4401a633 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9335/15/_/3462/_/970722481/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00481 for ; Thu, 5 Oct 2000 07:44:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:54 +0200 (MEST) Received: (qmail 4683 invoked by uid 0); 5 Oct 2000 05:08:03 -0000 Received: from b05.egroups.com (208.50.144.96) by mx11.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:03 -0000 X-eGroups-Return: sentto-1101623-1041-970722479-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by b05.egroups.com with NNFMP; 05 Oct 2000 05:07:58 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:59 -0000 Received: (qmail 30516 invoked from network); 5 Oct 2000 05:07:59 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:59 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:56 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A0B00980; Thu, 5 Oct 2000 07:10:00 +0200 Message-Id: <200010050510.e955A0B00980@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:00 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: ddad0baf91d4fc54762334ca7e72937f Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0% Intro APR and no annual fee! Apply NOW! http://click.egroups.com/1/9332/15/_/3462/_/970722479/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00484 for ; Thu, 5 Oct 2000 07:44:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:54 +0200 (MEST) Received: (qmail 30893 invoked by uid 0); 5 Oct 2000 05:08:04 -0000 Received: from ef.egroups.com (208.50.144.95) by mx12.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:04 -0000 X-eGroups-Return: sentto-1101623-1034-970722473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ef.egroups.com with NNFMP; 05 Oct 2000 05:07:58 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:53 -0000 Received: (qmail 16215 invoked from network); 5 Oct 2000 05:07:53 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 05:07:53 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:51 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559tA00957; Thu, 5 Oct 2000 07:09:55 +0200 Message-Id: <200010050509.e9559tA00957@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:55 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: e87062158fbe54ae71ccfaa653dc4d1b Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Click here and you can even personalize these quotes. http://click.egroups.com/1/9536/15/_/3462/_/970722473/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00487 for ; Thu, 5 Oct 2000 07:44:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:55 +0200 (MEST) Received: (qmail 11260 invoked by uid 0); 5 Oct 2000 05:08:04 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:04 -0000 X-eGroups-Return: sentto-1101623-1044-970722481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 05 Oct 2000 05:08:02 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:01 -0000 Received: (qmail 16477 invoked from network); 5 Oct 2000 05:08:01 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:01 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:07:59 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A3A00989; Thu, 5 Oct 2000 07:10:03 +0200 Message-Id: <200010050510.e955A3A00989@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:03 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 2ec6cff3efd3d5e71fc8b9bd360de546 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9333/15/_/3462/_/970722481/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:09:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00490 for ; Thu, 5 Oct 2000 07:44:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:56 +0200 (MEST) Received: (qmail 30953 invoked by uid 0); 5 Oct 2000 05:08:06 -0000 Received: from ef.egroups.com (208.50.144.95) by mx12.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:06 -0000 X-eGroups-Return: sentto-1101623-1040-970722478-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ef.egroups.com with NNFMP; 05 Oct 2000 05:08:01 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:07:57 -0000 Received: (qmail 30453 invoked from network); 5 Oct 2000 05:07:57 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:07:57 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:55 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e9559xl00975; Thu, 5 Oct 2000 07:09:59 +0200 Message-Id: <200010050509.e9559xl00975@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:09:59 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 574bbe69bbe028447e02b333a85ed602 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970722478/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00493 for ; Thu, 5 Oct 2000 07:44:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:57 +0200 (MEST) Received: (qmail 11313 invoked by uid 0); 5 Oct 2000 05:08:07 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:07 -0000 X-eGroups-Return: sentto-1101623-1045-970722482-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 05 Oct 2000 05:08:04 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:02 -0000 Received: (qmail 28699 invoked from network); 5 Oct 2000 05:08:02 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 5 Oct 2000 05:08:02 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:07:59 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A3x00992; Thu, 5 Oct 2000 07:10:03 +0200 Message-Id: <200010050510.e955A3x00992@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:03 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: af776b47dd3364c5fefd92b2605ecdd5 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9336/15/_/3462/_/970722482/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00496 for ; Thu, 5 Oct 2000 07:44:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:57 +0200 (MEST) Received: (qmail 8490 invoked by uid 0); 5 Oct 2000 05:08:09 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:09 -0000 X-eGroups-Return: sentto-1101623-1049-970722485-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 05 Oct 2000 05:08:03 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:05 -0000 Received: (qmail 16678 invoked from network); 5 Oct 2000 05:08:05 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:05 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:02 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A7H01004; Thu, 5 Oct 2000 07:10:07 +0200 Message-Id: <200010050510.e955A7H01004@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:07 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 44a4e03b210ecfe64d4665830b6513f4 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970722485/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00499 for ; Thu, 5 Oct 2000 07:44:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:58 +0200 (MEST) Received: (qmail 11360 invoked by uid 0); 5 Oct 2000 05:08:10 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:10 -0000 X-eGroups-Return: sentto-1101623-1050-970722486-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 05 Oct 2000 05:08:03 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:06 -0000 Received: (qmail 30776 invoked from network); 5 Oct 2000 05:08:06 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:08:06 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:03 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A8e01007; Thu, 5 Oct 2000 07:10:08 +0200 Message-Id: <200010050510.e955A8e01007@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:08 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 1d3abb21f036929ed65fd497b3e0ab45 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9336/15/_/3462/_/970722486/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00502 for ; Thu, 5 Oct 2000 07:44:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:59 +0200 (MEST) Received: (qmail 4762 invoked by uid 0); 5 Oct 2000 05:08:10 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:10 -0000 X-eGroups-Return: sentto-1101623-1053-970722488-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 05 Oct 2000 05:08:08 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:08 -0000 Received: (qmail 16747 invoked from network); 5 Oct 2000 05:08:08 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:08 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:06 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AAS01016; Thu, 5 Oct 2000 07:10:10 +0200 Message-Id: <200010050510.e955AAS01016@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:10 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 542e294b1f29196012d12381e0817517 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9335/15/_/3462/_/970722488/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00505 for ; Thu, 5 Oct 2000 07:44:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:44:59 +0200 (MEST) Received: (qmail 8482 invoked by uid 0); 5 Oct 2000 05:08:10 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:10 -0000 X-eGroups-Return: sentto-1101623-1051-970722487-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 05 Oct 2000 05:08:07 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:06 -0000 Received: (qmail 31534 invoked from network); 5 Oct 2000 05:08:06 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:06 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:04 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A8I01010; Thu, 5 Oct 2000 07:10:08 +0200 Message-Id: <200010050510.e955A8I01010@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:08 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: fc84c6b6768feba7bf37df0bc19bad8b Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9333/15/_/3462/_/970722487/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00510 for ; Thu, 5 Oct 2000 07:45:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:00 +0200 (MEST) Received: (qmail 4788 invoked by uid 0); 5 Oct 2000 05:08:12 -0000 Received: from hj.egroups.com (208.50.99.212) by mx11.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:12 -0000 X-eGroups-Return: sentto-1101623-1047-970722484-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 05 Oct 2000 05:08:04 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:04 -0000 Received: (qmail 16621 invoked from network); 5 Oct 2000 05:08:04 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:04 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:01 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A5i00998; Thu, 5 Oct 2000 07:10:05 +0200 Message-Id: <200010050510.e955A5i00998@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:05 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: a8c3931822a48ae84356023ed571d683 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Call 1-800-555-TELL. http://click.egroups.com/1/9535/15/_/3462/_/970722484/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00556 for ; Thu, 5 Oct 2000 07:45:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:01 +0200 (MEST) Received: (qmail 8505 invoked by uid 0); 5 Oct 2000 05:08:13 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:13 -0000 X-eGroups-Return: sentto-1101623-1052-970722487-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 05 Oct 2000 05:08:10 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:07 -0000 Received: (qmail 31563 invoked from network); 5 Oct 2000 05:08:07 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:07 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:05 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A9g01013; Thu, 5 Oct 2000 07:10:09 +0200 Message-Id: <200010050510.e955A9g01013@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:09 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 02a56785f95e0cc65229f43a15287a1e Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722487/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00610 for ; Thu, 5 Oct 2000 07:45:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:01 +0200 (MEST) Received: (qmail 1824 invoked by uid 0); 5 Oct 2000 05:08:13 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:13 -0000 X-eGroups-Return: sentto-1101623-1055-970722489-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hm.egroups.com with NNFMP; 05 Oct 2000 05:08:07 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:09 -0000 Received: (qmail 16791 invoked from network); 5 Oct 2000 05:08:09 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:09 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:07 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ACa01022; Thu, 5 Oct 2000 07:10:12 +0200 Message-Id: <200010050510.e955ACa01022@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:12 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 4085a085f49c2b7503beeb4498cbd29c Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. Call 1-800-555-TELL and hear everything. For info visit: http://click.egroups.com/1/9529/15/_/3462/_/970722490/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00613 for ; Thu, 5 Oct 2000 07:45:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:02 +0200 (MEST) Received: (qmail 24209 invoked by uid 0); 5 Oct 2000 05:08:13 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:13 -0000 X-eGroups-Return: sentto-1101623-1046-970722483-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 05 Oct 2000 05:08:03 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:03 -0000 Received: (qmail 16542 invoked from network); 5 Oct 2000 05:08:03 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:03 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:00 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A4A00995; Thu, 5 Oct 2000 07:10:04 +0200 Message-Id: <200010050510.e955A4A00995@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:04 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: e99ed265c23d69ad47e527f758c194f6 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970722483/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00616 for ; Thu, 5 Oct 2000 07:45:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:03 +0200 (MEST) Received: (qmail 4881 invoked by uid 0); 5 Oct 2000 05:08:14 -0000 Received: from hj.egroups.com (208.50.99.212) by mx11.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:14 -0000 X-eGroups-Return: sentto-1101623-1048-970722484-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hj.egroups.com with NNFMP; 05 Oct 2000 05:08:09 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:04 -0000 Received: (qmail 31460 invoked from network); 5 Oct 2000 05:08:04 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:04 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:02 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955A6C01001; Thu, 5 Oct 2000 07:10:06 +0200 Message-Id: <200010050510.e955A6C01001@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:06 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: c1e7e56470a3aa2822bd9db3ca3c2e76 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Call 1-800-555-TELL. http://click.egroups.com/1/9535/15/_/3462/_/970722484/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00619 for ; Thu, 5 Oct 2000 07:45:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:04 +0200 (MEST) Received: (qmail 7993 invoked by uid 0); 5 Oct 2000 05:08:16 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:16 -0000 X-eGroups-Return: sentto-1101623-1054-970722489-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 05 Oct 2000 05:08:11 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:09 -0000 Received: (qmail 31623 invoked from network); 5 Oct 2000 05:08:09 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:09 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:07 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ABA01019; Thu, 5 Oct 2000 07:10:11 +0200 Message-Id: <200010050510.e955ABA01019@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:11 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 4be3f8d0130003cc47e46ab009727057 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970722489/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00622 for ; Thu, 5 Oct 2000 07:45:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:04 +0200 (MEST) Received: (qmail 1881 invoked by uid 0); 5 Oct 2000 05:08:16 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:16 -0000 X-eGroups-Return: sentto-1101623-1056-970722490-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 05 Oct 2000 05:08:10 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:10 -0000 Received: (qmail 31638 invoked from network); 5 Oct 2000 05:08:10 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:10 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:08 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ACs01025; Thu, 5 Oct 2000 07:10:12 +0200 Message-Id: <200010050510.e955ACs01025@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:12 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: b5e129ba4301c6875c9d9ef9ecce01c1 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970722490/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00625 for ; Thu, 5 Oct 2000 07:45:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:05 +0200 (MEST) Received: (qmail 23440 invoked by uid 0); 5 Oct 2000 05:08:17 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:17 -0000 X-eGroups-Return: sentto-1101623-1059-970722494-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 05 Oct 2000 05:08:14 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:14 -0000 Received: (qmail 29114 invoked from network); 5 Oct 2000 05:08:13 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 5 Oct 2000 05:08:13 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:10 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AFb01034; Thu, 5 Oct 2000 07:10:15 +0200 Message-Id: <200010050510.e955AFb01034@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:15 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 5ad9df7279d42fd0e410206ea34f5615 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Dial 1-800-555-TELL, say "Phone Booth" http://click.egroups.com/1/9532/15/_/3462/_/970722494/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00628 for ; Thu, 5 Oct 2000 07:45:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:07 +0200 (MEST) Received: (qmail 24263 invoked by uid 0); 5 Oct 2000 05:08:17 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:17 -0000 X-eGroups-Return: sentto-1101623-1060-970722495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 05 Oct 2000 05:08:15 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:14 -0000 Received: (qmail 31025 invoked from network); 5 Oct 2000 05:08:14 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Oct 2000 05:08:14 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:12 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AGk01037; Thu, 5 Oct 2000 07:10:16 +0200 Message-Id: <200010050510.e955AGk01037@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:16 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 30638427c53aacc499c9c794ecb31b21 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. http://click.egroups.com/1/9530/15/_/3462/_/970722495/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00631 for ; Thu, 5 Oct 2000 07:45:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:07 +0200 (MEST) Received: (qmail 15204 invoked by uid 0); 5 Oct 2000 05:08:18 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:18 -0000 X-eGroups-Return: sentto-1101623-1057-970722492-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 05 Oct 2000 05:08:08 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:12 -0000 Received: (qmail 29035 invoked from network); 5 Oct 2000 05:08:11 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 5 Oct 2000 05:08:11 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:09 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ADI01028; Thu, 5 Oct 2000 07:10:13 +0200 Message-Id: <200010050510.e955ADI01028@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:13 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 0cde16f16690701375e1ab8c167664ee Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722492/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00634 for ; Thu, 5 Oct 2000 07:45:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:08 +0200 (MEST) Received: (qmail 24299 invoked by uid 0); 5 Oct 2000 05:08:20 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:20 -0000 X-eGroups-Return: sentto-1101623-1061-970722495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 05 Oct 2000 05:08:15 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:14 -0000 Received: (qmail 31762 invoked from network); 5 Oct 2000 05:08:14 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:14 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:12 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AHW01040; Thu, 5 Oct 2000 07:10:17 +0200 Message-Id: <200010050510.e955AHW01040@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:17 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 6dfca8c4bfa3fc8ae9d678d355e1d9e2 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa, in 30 seconds! 1. Fill in the brief application 2. Get rates as low as 2.99% Intro APR with NO annual fee! http://click.egroups.com/1/9333/15/_/3462/_/970722495/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00667 for ; Thu, 5 Oct 2000 07:45:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:10 +0200 (MEST) Received: (qmail 24312 invoked by uid 0); 5 Oct 2000 05:08:20 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:20 -0000 X-eGroups-Return: sentto-1101623-1064-970722497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 05 Oct 2000 05:08:17 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:17 -0000 Received: (qmail 17068 invoked from network); 5 Oct 2000 05:08:17 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:17 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:15 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AJ301049; Thu, 5 Oct 2000 07:10:19 +0200 Message-Id: <200010050510.e955AJ301049@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:19 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: a6f7465abff19a496f1e8b1bcd3a2009 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. http://click.egroups.com/1/9530/15/_/3462/_/970722497/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00670 for ; Thu, 5 Oct 2000 07:45:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:10 +0200 (MEST) Received: (qmail 15250 invoked by uid 0); 5 Oct 2000 05:08:20 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:20 -0000 X-eGroups-Return: sentto-1101623-1058-970722492-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 05 Oct 2000 05:08:11 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:12 -0000 Received: (qmail 31710 invoked from network); 5 Oct 2000 05:08:12 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:12 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:10 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AEI01031; Thu, 5 Oct 2000 07:10:14 +0200 Message-Id: <200010050510.e955AEI01031@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:14 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: dd5bdb12e86c71f0d5cfc140d1c62d9c Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722492/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00673 for ; Thu, 5 Oct 2000 07:45:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:11 +0200 (MEST) Received: (qmail 31846 invoked by uid 0); 5 Oct 2000 05:08:21 -0000 Received: from ck.egroups.com (208.50.144.69) by mx06.rz2.gmx.net with SMTP; 5 Oct 2000 05:08:21 -0000 X-eGroups-Return: sentto-1101623-1063-970722496-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 05 Oct 2000 05:08:16 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:16 -0000 Received: (qmail 31087 invoked from network); 5 Oct 2000 05:08:16 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 5 Oct 2000 05:08:16 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:14 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AIV01046; Thu, 5 Oct 2000 07:10:18 +0200 Message-Id: <200010050510.e955AIV01046@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:18 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: d69eaa72c9ab643f322215cf2744d271 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get FREE long-distance phone calls on Tellme! Click here for the scoop: http://click.egroups.com/1/9531/15/_/3462/_/970722496/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00676 for ; Thu, 5 Oct 2000 07:45:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:11 +0200 (MEST) Received: (qmail 24363 invoked by uid 0); 5 Oct 2000 05:08:22 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:22 -0000 X-eGroups-Return: sentto-1101623-1062-970722495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mq.egroups.com with NNFMP; 05 Oct 2000 05:08:19 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:15 -0000 Received: (qmail 29162 invoked from network); 5 Oct 2000 05:08:15 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 5 Oct 2000 05:08:15 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta3 with SMTP; 5 Oct 2000 05:08:13 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AH001043; Thu, 5 Oct 2000 07:10:17 +0200 Message-Id: <200010050510.e955AH001043@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:17 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 85c32e21146b461ffa9f9a34fe0efd40 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Call 1-800-555-TELL. For more info visit: http://click.egroups.com/1/9533/15/_/3462/_/970722495/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00679 for ; Thu, 5 Oct 2000 07:45:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:12 +0200 (MEST) Received: (qmail 24364 invoked by uid 0); 5 Oct 2000 05:08:22 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:22 -0000 X-eGroups-Return: sentto-1101623-1065-970722498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 05 Oct 2000 05:08:18 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:18 -0000 Received: (qmail 31835 invoked from network); 5 Oct 2000 05:08:18 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:18 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:15 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AKa01053; Thu, 5 Oct 2000 07:10:20 +0200 Message-Id: <200010050510.e955AKa01053@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:20 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 8e1a8a1cf46be2815e6c1d14347a448d Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. Call 1-800-555-TELL and hear everything. For info visit: http://click.egroups.com/1/9529/15/_/3462/_/970722498/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00682 for ; Thu, 5 Oct 2000 07:45:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:13 +0200 (MEST) Received: (qmail 24379 invoked by uid 0); 5 Oct 2000 05:08:23 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:23 -0000 X-eGroups-Return: sentto-1101623-1066-970722499-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 05 Oct 2000 05:08:24 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:19 -0000 Received: (qmail 31876 invoked from network); 5 Oct 2000 05:08:18 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:18 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:16 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AKk01056; Thu, 5 Oct 2000 07:10:20 +0200 Message-Id: <200010050510.e955AKk01056@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:20 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: ffc98bdfc67a61a179290814f9650bd7 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Tellme Sports. Tellme Stocks. Tellme News. Just Tellme. Call 1-800-555-TELL and hear everything. For info visit: http://click.egroups.com/1/9529/15/_/3462/_/970722499/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00685 for ; Thu, 5 Oct 2000 07:45:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:13 +0200 (MEST) Received: (qmail 24529 invoked by uid 0); 5 Oct 2000 05:08:24 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:24 -0000 X-eGroups-Return: sentto-1101623-1070-970722502-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 05 Oct 2000 05:08:22 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:22 -0000 Received: (qmail 31213 invoked from network); 5 Oct 2000 05:08:22 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:08:22 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:19 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ANA01068; Thu, 5 Oct 2000 07:10:23 +0200 Message-Id: <200010050510.e955ANA01068@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:23 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 25a8f297e39bc450884b3146a008604c Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0% Intro or 9.99% Ongoing APR and no annual fee! Apply NOW! http://click.egroups.com/1/9331/15/_/3462/_/970722502/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00688 for ; Thu, 5 Oct 2000 07:45:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:14 +0200 (MEST) Received: (qmail 800 invoked by uid 0); 5 Oct 2000 05:08:24 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:24 -0000 X-eGroups-Return: sentto-1101623-1069-970722501-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 05 Oct 2000 05:08:21 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:21 -0000 Received: (qmail 17196 invoked from network); 5 Oct 2000 05:08:21 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:21 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:18 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AMi01065; Thu, 5 Oct 2000 07:10:22 +0200 Message-Id: <200010050510.e955AMi01065@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:22 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 41305811b54d6c8853fb96cf8951bcce Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9336/15/_/3462/_/970722501/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00691 for ; Thu, 5 Oct 2000 07:45:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:15 +0200 (MEST) Received: (qmail 22693 invoked by uid 0); 5 Oct 2000 05:08:26 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:26 -0000 X-eGroups-Return: sentto-1101623-1071-970722503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 05 Oct 2000 05:08:23 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:23 -0000 Received: (qmail 17231 invoked from network); 5 Oct 2000 05:08:22 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 5 Oct 2000 05:08:22 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:20 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AO301071; Thu, 5 Oct 2000 07:10:24 +0200 Message-Id: <200010050510.e955AO301071@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:24 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: aa006b4735eb295e95ac877a0d7269aa Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Call 1-800-555-TELL. http://click.egroups.com/1/9535/15/_/3462/_/970722503/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00694 for ; Thu, 5 Oct 2000 07:45:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:16 +0200 (MEST) Received: (qmail 23698 invoked by uid 0); 5 Oct 2000 05:08:28 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:28 -0000 X-eGroups-Return: sentto-1101623-1068-970722500-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hp.egroups.com with NNFMP; 05 Oct 2000 05:08:20 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:20 -0000 Received: (qmail 31178 invoked from network); 5 Oct 2000 05:08:20 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 05:08:20 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:18 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AMU01062; Thu, 5 Oct 2000 07:10:22 +0200 Message-Id: <200010050510.e955AMU01062@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:22 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: e71ace9882bfc78f4a07bddf1fbf6fad Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Access Tellme from any phone. For more info visit: http://click.egroups.com/1/9534/15/_/3462/_/970722500/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00697 for ; Thu, 5 Oct 2000 07:45:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:17 +0200 (MEST) Received: (qmail 15441 invoked by uid 0); 5 Oct 2000 05:08:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:29 -0000 X-eGroups-Return: sentto-1101623-1073-970722504-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 05 Oct 2000 05:08:23 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:24 -0000 Received: (qmail 32094 invoked from network); 5 Oct 2000 05:08:24 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:24 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:22 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955AQm01077; Thu, 5 Oct 2000 07:10:26 +0200 Message-Id: <200010050510.e955AQm01077@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:26 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: afd0f1c342c79908d28e1f0402b69542 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0% Intro or 9.99% Ongoing APR and no annual fee! Apply NOW! http://click.egroups.com/1/9331/15/_/3462/_/970722504/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00700 for ; Thu, 5 Oct 2000 07:45:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:17 +0200 (MEST) Received: (qmail 24656 invoked by uid 0); 5 Oct 2000 05:08:31 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:31 -0000 X-eGroups-Return: sentto-1101623-1067-970722499-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 05 Oct 2000 05:08:29 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:19 -0000 Received: (qmail 31912 invoked from network); 5 Oct 2000 05:08:19 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:19 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta1 with SMTP; 5 Oct 2000 05:08:17 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955ALl01059; Thu, 5 Oct 2000 07:10:21 +0200 Message-Id: <200010050510.e955ALl01059@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:21 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: db8547a8d1f7b0ea64a55f832a0c3cff Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Get a NextCard Visa with rates as low as 2.99% Intro APR! 1. Fill in the brief application 2. Get approval decisions in 30 seconds! http://click.egroups.com/1/9334/15/_/3462/_/970722499/ ---------------------------------------------------------------------_-> From billou@microthief.com Thu Oct 5 07:10:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00703 for ; Thu, 5 Oct 2000 07:45:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 07:45:18 +0200 (MEST) Received: (qmail 22828 invoked by uid 0); 5 Oct 2000 05:08:34 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 5 Oct 2000 05:08:34 -0000 X-eGroups-Return: sentto-1101623-1072-970722503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 05 Oct 2000 05:08:26 -0000 X-Sender: http@localhost.localdomain X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 05:08:23 -0000 Received: (qmail 32050 invoked from network); 5 Oct 2000 05:08:23 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 5 Oct 2000 05:08:23 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.53.206) by mta2 with SMTP; 5 Oct 2000 05:08:21 -0000 Received: (from http@localhost) by localhost.localdomain (8.10.1/8.8.7) id e955APa01074; Thu, 5 Oct 2000 07:10:25 +0200 Message-Id: <200010050510.e955APa01074@localhost.localdomain> To: f-cpu@egroups.com From: billou@microthief.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 07:10:25 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] spam Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: bd29bfeca097e1fa23f19394d89b73c1 Status: R X-Status: N salut casse couillles lrnu !!!!!!!!! WRNA Byvivre jebgr: > Uv Rirelobql ! > > V unir genafyngrq gur ugzy znahny va Yngrk znahny. > > Abj, gur zrffntr vf va serapu. V\'z fbeel sbe ab serapuzra ! ab jbeevrf... > Tbbq olr. > > Zrffntr sbe Lnaa: > > W\'nv q\'éabezr co nirp yn znvy yvfg. Wr ar erçbvf cyhf qr zrffntrf. W\'nv > raiblé cyrva qr zrffntrf fhe yn znvy yvfg senaçnvfr znvf wr a\'nv nhphar > eécbafr. wr invf iéevsvre gba nqerffr fhe yr fvgr rtebhcf. > N gbhg unfneq, w\'raibvr pr ceéfrag zrffntr fhe yn znvy yvfg cevapvcnyr. > W\'nv yrf svpuvref genqhvgf ra Yngrk. Bù qbvf-wr yrf raiblre ? zrgf-yr ra sgc bh uggc dhrydhr cneg rg raibvr-abhf y\'hey. ba erpbcvren . > N +. > > Byvivre. jrypbzr onpx :-) guvatf ner tbvat gb urng hc !!!! JULTRR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \"Zbv dhv crafnvg dhr qnaf yr yvoer l ninvg cnf gebc qr plore-arharhf.\" S. Pbhpurg, NCEVY.bet, 8/18/2000 (pbager yrf cbegnvyf à yn pba) genere par Spammer In Progress -------------------------- eGroups Sponsor -------------------------~-~> Restaurants, Movies, Weather, Traffic & More! Call 1-800-555-TELL. For more info visit: http://click.egroups.com/1/9533/15/_/3462/_/970722503/ ---------------------------------------------------------------------_-> From "Toyoaki Sagawa" Thu Oct 5 13:16:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00331 for ; Thu, 5 Oct 2000 14:49:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 14:49:26 +0200 (MEST) Received: (qmail 12649 invoked by uid 0); 5 Oct 2000 11:16:45 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 5 Oct 2000 11:16:45 -0000 X-eGroups-Return: sentto-1101623-1074-970744599-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 05 Oct 2000 11:16:44 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 11:16:39 -0000 Received: (qmail 1280 invoked from network); 5 Oct 2000 11:16:38 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 5 Oct 2000 11:16:38 -0000 Received: from unknown (HELO mail152.nifty.com) (202.248.37.145) by mta3 with SMTP; 5 Oct 2000 11:16:38 -0000 Received: from cfb5 by mail152.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA28862 for ; Thu, 5 Oct 2000 20:16:36 +0900 To: Message-ID: <000101c02ebd$c4e7dc00$0200a8c0@cfb5> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39D52B3E.132216B8@f-cpu.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 20:16:55 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Sayuri from Japan Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 51c9cf3d65a5b0382a10146c78ddf360 Status: R X-Status: N
Hi,

Yann Guidon wrote:
> try first to fit two cores on one chip, so you see and understand the
> problems it creates. the technology to do that is available, but
> the system design in itself is less easy.

I'm thinking about efficient design about multi core in one chip, this is
difficult..
reading many books about architectures, but everything is for multi-CPU.
Please wait a while :-)

Toyoaki Sagawa
eGroups Sponsor
From Alan Grimes Thu Oct 5 17:58:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01056 for ; Thu, 5 Oct 2000 21:31:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 21:31:58 +0200 (MEST) Received: (qmail 24452 invoked by uid 0); 5 Oct 2000 15:56:35 -0000 Received: from fg.egroups.com (208.50.144.70) by mx06.rz2.gmx.net with SMTP; 5 Oct 2000 15:56:35 -0000 X-eGroups-Return: sentto-1101623-1075-970761374-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 05 Oct 2000 15:56:34 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 15:56:13 -0000 Received: (qmail 28716 invoked from network); 5 Oct 2000 15:56:11 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 15:56:11 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta1 with SMTP; 5 Oct 2000 15:56:11 -0000 Received: from 207-172-184-82.s82.tnt6.lnhva.md.dialup.rcn.com ([207.172.184.82] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13hDNR-00046U-00 for f-cpu@egroups.com; Thu, 05 Oct 2000 11:56:10 -0400 Message-ID: <39DCA50B.A8F53FEB@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 11:58:03 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: spam [descrambled] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 12180708d8241cc3b69951f5d5aaaabc Status: R X-Status: N Does anybody on this list know how to tie a noose?

      |
      |
      |
      =3D
      =3D
      =3D
      =3D
      ^
      /   \
     |     |
      \   /
       ---

>salut casse couillles
yeah !!!!!!!!!

JEAN Olivier wrote:
>  Hi Everybody !
>
>   I have translated the html manual in Latex manual.
>
> Now, the message is in french. I\'m sorry for no frenchmen !

no worries...

>            = ;             G= ood bye.
>
>  Message for Yann:
>
>  J\'ai d\'=E9norme pb avec la mail list. Je ne re=E7ois plus de m= essages. >J\'ai envoy=E9 plein de messages sur la mail list fran=E7aise = mais je n\'ai
>aucune r=E9ponse.

>je vais v=E9rifier ton adresse sur le site egroups.

> A tout hasard, j\'envoie ce pr=E9sent message sur la mail list
>principale. J\'ai les fichiers traduits en Latex. O=F9 dois-je les envo= yer
>?

>mets-le en ftp ou http quelque part et envoie-nous l\'url.
>on recopiera .

>         A +.
>
>            = ;     Olivier.

>welcome back :-)

>things are going to heat up !!!!

WHYGEE

--
In this year's presidential race you *do* have a choice!
VOTE Browne/Olivier The ticket to freedom!
http://users.erols.com/alang= rimes/  <my website.

####### Begin Eschelon Block #######
unibomber anthrax plutonium militia delta force ruby ridge atf batf waco oklahoma city assault rifle randy weaver sog sof oliver north vince
foster m-16 hillary clinton bill clinton marx crack m-60 c5 c7 mlk black panthers fbi chemical weapons twa 800 roswell white slavery history of us foreign policy terrorist freedom
####### End   Eschelon Block #######
 From Nicolas Matringe Thu Oct 5 18:01:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01059 for ; Thu, 5 Oct 2000 21:31:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 21:31:59 +0200 (MEST) Received: (qmail 7471 invoked by uid 0); 5 Oct 2000 16:00:23 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 5 Oct 2000 16:00:23 -0000 X-eGroups-Return: sentto-1101623-1076-970761616-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by f19.egroups.com with NNFMP; 05 Oct 2000 16:00:21 -0000 X-Sender: nicolas.matringe@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 16:00:16 -0000 Received: (qmail 24060 invoked from network); 5 Oct 2000 16:00:15 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 5 Oct 2000 16:00:15 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 5 Oct 2000 16:00:15 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id QAA06307 for ; Thu, 5 Oct 2000 16:00:04 GMT X-To: Message-ID: <39DCA5C2.91F2AC1F@ipricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39DCA50B.A8F53FEB@starpower.net> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 18:01:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: spam [descrambled] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b6a46d73d1ef66c78cab4d4aa26a0150 Status: R X-Status: N Alan Grimes a =E9crit :
>
> Does anybody on this list know how to tie a noose?
>
>         |
>         |
>         |
>         =3D
>         =3D
>         =3D
>         =3D
>         ^
>       /   \
>      |     |
>       \   /
>        ---

Well I happen to know but I don't see what use it will be. Anyway, if
anyone needs... :o)

--
Nicolas MATRINGE          = ; IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor=
3D""
From Jecel Assumpcao Jr Thu Oct 5 20:24:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01062 for ; Thu, 5 Oct 2000 21:31:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 21:31:59 +0200 (MEST) Received: (qmail 1276 invoked by uid 0); 5 Oct 2000 18:38:36 -0000 Received: from mu.egroups.com (208.50.99.218) by mx12.rz2.gmx.net with SMTP; 5 Oct 2000 18:38:36 -0000 X-eGroups-Return: sentto-1101623-1078-970771100-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mu.egroups.com with NNFMP; 05 Oct 2000 18:38:34 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 18:38:20 -0000 Received: (qmail 17179 invoked from network); 5 Oct 2000 18:30:59 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 5 Oct 2000 18:30:59 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta2 with SMTP; 5 Oct 2000 18:30:57 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA00787 for ; Thu, 5 Oct 2000 15:37:31 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> In-Reply-To: <39DBF0BF.74592E65@f-cpu.org> Message-Id: <00100515444401.00396@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 15:24:30 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9b0b82f4a746aa29ce8119dc8d09c3dd Status: R X-Status: N Yann,

thanks for the explanation on the theory, but I was asking about
concrete numbers. For real applications where the working set is
slightly larger than the cache it is possible for random replacement to
actually out perform LRU. You are right that this is less of a problem
for fully associative caches (the link I gave included this
information).

I wanted to know something like "yes, this design will take up 40% more
gates, but it will perform 13% better and so is worth it".

-- Jecel
 From Jecel Assumpcao Jr Thu Oct 5 20:15:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01065 for ; Thu, 5 Oct 2000 21:32:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Oct 2000 21:32:00 +0200 (MEST) Received: (qmail 2916 invoked by uid 0); 5 Oct 2000 18:15:50 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 5 Oct 2000 18:15:50 -0000 X-eGroups-Return: sentto-1101623-1077-970769432-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 05 Oct 2000 18:10:32 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 18:10:31 -0000 Received: (qmail 9166 invoked from network); 5 Oct 2000 18:10:31 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 18:10:31 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 5 Oct 2000 18:10:28 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id PAA00734 for ; Thu, 5 Oct 2000 15:17:00 -0300 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <200010040923.FAA03095@belegost.mit.edu> <00100415245800.00384@gandalf> <39DBC193.E12BDEB1@llandre.freeserve.co.uk> In-Reply-To: <39DBC193.E12BDEB1@llandre.freeserve.co.uk> Message-Id: <00100515241300.00396@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 15:15:01 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FPGA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1bf8bb0d6a2fb53cb4251a0a34bbf27b Status: R X-Status: N Jeff,

> I found when I tried to make a 16 bit CPU in foundation that I kept hitting
> architectural limits that were described (eg: run out of tristate lines),

Really? I would think it could handle at least three such busses which
is the most I have seen on simple processor designs. What device were
you using?

> but not much info on the ACTUAL architecture and how to tailor
> your circuit.

That is what I liked about the old XACT software - you could see the
whole chip and what resources your design was using. I think the new
tools have a "floor plan" view, but I doubt it is as informative.

I don't think there is any other way to know this other than read the
chip datasheets very carefully.

> I used a big MUX instead made from AND/OR which then
> maxed out the CLBs. Can manual placing be better than autoroute in
> many cases. (Again this appeared difficult with Foundation).

You might get better results if you can very carefully place the cells
to explore regularities in your design, but I think this will be less
and less the case as the software gets better and PCs get faster.

> I must have missed something.. what free FPGA software - i was
> on their site just a couple of days ago...

The free WebPACK tools will soon include FPGA support:

    http://www.xilinx.com/products/software/wp_fpga.htm

-- Jecel
 From berkane Thu Oct 5 23:38:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00639 for ; Fri, 6 Oct 2000 14:43:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:43:51 +0200 (MEST) Received: (qmail 24902 invoked by uid 0); 5 Oct 2000 21:36:21 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 5 Oct 2000 21:36:21 -0000 X-eGroups-Return: sentto-1101623-1079-970781766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 05 Oct 2000 21:36:12 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 21:36:06 -0000 Received: (qmail 9726 invoked from network); 5 Oct 2000 21:36:06 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Oct 2000 21:36:06 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.46.81) by mta1 with SMTP; 5 Oct 2000 21:36:04 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e95LcA501197 for ; Thu, 5 Oct 2000 23:38:10 +0200 Sender: root@localhost.localdomain Message-ID: <39DCF4C2.4F9F3899@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <399A2809.3C3EB25F@f-cpu.org> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Oct 2000 23:38:10 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] l updated Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 834df43978ea9731960b4950f26bf086 Status: R X-Status: N Yann Guidon a =E9crit :
>
> hello,
Azdine Berkane :
en revoir , forget me tu peut comprendre ca ?
 From berkane Fri Oct 6 00:32:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00645 for ; Fri, 6 Oct 2000 14:43:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:43:53 +0200 (MEST) Received: (qmail 8891 invoked by uid 0); 5 Oct 2000 22:30:32 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 5 Oct 2000 22:30:32 -0000 X-eGroups-Return: sentto-1101623-1080-970785025-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 05 Oct 2000 22:30:27 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 5 Oct 2000 22:30:24 -0000 Received: (qmail 28895 invoked from network); 5 Oct 2000 22:30:23 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 5 Oct 2000 22:30:23 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.44.236) by mta3 with SMTP; 5 Oct 2000 22:30:22 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e95MWS501420 for ; Fri, 6 Oct 2000 00:32:29 +0200 Sender: root@localhost.localdomain Message-ID: <39DD017C.7B597CCE@infolibre.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <399A2809.3C3EB25F@f-cpu.org> <39DCF4C2.4F9F3899@infolibre.org> X-eGroups-From: berkane From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Oct 2000 00:32:28 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] l updated Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cf18c3723bbdbd7100dbd3e620d936f4 Status: R X-Status: N berkane a =E9crit :
>
> Yann Guidon a =E9crit :
> >
> > hello,
> Azdine Berkane :
> en revoir , forget me tu peut comprendre ca ?
>
pove tipe
--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From Yann Guidon Fri Oct 6 04:08:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00660 for ; Fri, 6 Oct 2000 14:43:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:43:58 +0200 (MEST) Received: (qmail 29444 invoked by uid 0); 6 Oct 2000 01:04:39 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 6 Oct 2000 01:04:39 -0000 X-eGroups-Return: sentto-1101623-1081-970794274-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 06 Oct 2000 01:04:34 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 01:04:33 -0000 Received: (qmail 24852 invoked from network); 6 Oct 2000 01:04:33 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 6 Oct 2000 01:04:33 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 6 Oct 2000 01:04:33 -0000 Received: from f-cpu.org (nas4-95.ras.club-internet.fr [195.36.203.95]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA26344 for ; Fri, 6 Oct 2000 03:04:29 +0200 (MET DST) Message-ID: <39DD3435.925F47D3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Oct 2000 03:08:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a12323f0310112e2c1ae2c958a6538c1 Status: R X-Status: N hi !

Jecel Assumpcao Jr wrote:
> Yann,
>
> thanks for the explanation on the theory, but I was asking about
> concrete numbers. For real applications where the working set is
> slightly larger than the cache it is possible for random replacement to
> actually out perform LRU. You are right that this is less of a problem
> for fully associative caches (the link I gave included this
> information).
>
> I wanted to know something like "yes, this design will take up 40% more
> gates, but it will perform 13% better and so is worth it".

i haven't found any numbers, mostly because full associativity
is not much used. maybe someone's gotta ask on comp.arch BUT
if you want numbers, they can mislead you : it always depends on
a lot of factors and the real impact is much too varied, as the
systems change.

When selecting FA, i had a small design with not much cache in mind.
Memory management (at the packet level) is more important because
the cache must react smoothly. This can change as the size increases.

Unfortunately, i haven't updated the testbench for a few days.
this testbench will give us the number we all expect (or at least
i hope so). i'm doing job interviews now and i'm running a lot
in and around Paris. But an EDA vendor proposed me a job (no
interview yet), and i wish i'll be hired : i'll have all the tools
i want to play with the F-CPU :-)))

It's still only speculation, but it's so sweet to think about it :-)
>  -- Jecel
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 6 04:08:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00663 for ; Fri, 6 Oct 2000 14:43:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:43:59 +0200 (MEST) Received: (qmail 17256 invoked by uid 0); 6 Oct 2000 01:04:43 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 6 Oct 2000 01:04:43 -0000 X-eGroups-Return: sentto-1101623-1082-970794276-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 06 Oct 2000 01:04:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 01:04:36 -0000 Received: (qmail 8636 invoked from network); 6 Oct 2000 01:04:36 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 6 Oct 2000 01:04:36 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 6 Oct 2000 01:04:35 -0000 Received: from f-cpu.org (nas4-95.ras.club-internet.fr [195.36.203.95]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA07752 for ; Fri, 6 Oct 2000 03:04:32 +0200 (MET DST) Message-ID: <39DD3436.EC52978E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39DCA50B.A8F53FEB@starpower.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Oct 2000 03:08:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: spam [descrambled] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40814c815f235e93bdbade08beb90c2e Status: R X-Status: N Alan Grimes wrote:
> Does anybody on this list know how to tie a noose?
please keep your calm, or the situation could get worse.
let's find a solution instead.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Fri Oct 6 06:44:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00666 for ; Fri, 6 Oct 2000 14:44:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:00 +0200 (MEST) Received: (qmail 31245 invoked by uid 0); 6 Oct 2000 04:40:52 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 6 Oct 2000 04:40:52 -0000 X-eGroups-Return: sentto-1101623-1083-970807243-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 06 Oct 2000 04:40:46 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 04:40:42 -0000 Received: (qmail 1029 invoked from network); 6 Oct 2000 04:40:42 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 6 Oct 2000 04:40:42 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 6 Oct 2000 04:40:41 -0000 Received: from morphin.marquardt-home.de (d117.nas22.sonic.net [209.204.137.117]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA03275 for ; Fri, 6 Oct 2000 06:40:38 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13hPMb-0000SK-00 for ; Thu, 05 Oct 2000 21:44:05 -0700 To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> <39DA6CF7.2FF43696@f-cpu.org> <20001004044747.48281@thrai.stud.uni-hannover.de> X-Now-Playing: Mindrot's Soul - Nothing In-Reply-To: Michael Riepe's message of "Wed, 4 Oct 2000 04:47:47 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 17 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 05 Oct 2000 21:44:04 -0700 Reply-To: f-cpu@egroups.com Subject: Re: CVS (was: Re: [f-cpu] (v) happy :-)) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d53bb3c02581f63eadd448004e27c632 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> CVS isn't hard to use at all, and you can set it up with only a few steps.
> Those of you who are interested in CVS should read the CVS documentation
> (cvs.info, normally).  It contains a short introduction, too.

I find that book (a large part of it free) pretty cool:
  http://www.red-bean.com/cvsbook/

BTW, the diploma thesis about comparing VHDL coding techniques is at
http://mikro.e-technik.uni-ulm.de/education/upload_data/jriexing_diplomarbeit.pdf
[in german]

Cheers,
  Colin

--
From Colin Marquardt Fri Oct 6 06:48:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00669 for ; Fri, 6 Oct 2000 14:44:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:01 +0200 (MEST) Received: (qmail 3642 invoked by uid 0); 6 Oct 2000 04:45:29 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 6 Oct 2000 04:45:29 -0000 X-eGroups-Return: sentto-1101623-1084-970807527-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mo.egroups.com with NNFMP; 06 Oct 2000 04:45:29 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 04:45:27 -0000 Received: (qmail 10398 invoked from network); 6 Oct 2000 04:45:27 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 6 Oct 2000 04:45:27 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 6 Oct 2000 04:45:26 -0000 Received: from morphin.marquardt-home.de (d117.nas22.sonic.net [209.204.137.117]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id GAA04585 for ; Fri, 6 Oct 2000 06:45:13 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13hPQz-0000SV-00 for ; Thu, 05 Oct 2000 21:48:37 -0700 To: f-cpu@egroups.com References: <39D933ED.FE44813B@f-cpu.org> <20001003041009.03040@thrai.stud.uni-hannover.de> <39DA6CF5.43305B3@f-cpu.org> <20001004143645.55085@thrai.stud.uni-hannover.de> X-Now-Playing: Regurgitate's Regurgitate / Split - Expelling Pyorrhea In-Reply-To: Michael Riepe's message of "Wed, 4 Oct 2000 14:36:45 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 22 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 05 Oct 2000 21:48:37 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) icache spec : the declaration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7da8ba5d4ca5c7d9112902e278eedf54 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> On Tue, Oct 03, 2000 at 09:07:58PM -0700, Colin Marquardt wrote:
>> I have always seen "mask" as "mask something out", so if a mask bit is
>> a one, the thing to mask (think of an interrupt) is not visible. But I
>> have seen it the other 'round too (confuses me though).

> In Software, you usually want to keep some bits and set the rest to 0.
> This means you AND the bits you need with 1, others with 0.  This
> differs from the meaning of `mask' in most other situations (unless
> you define that the 0-bits form the mask, of course ;).

I would define the latter for interrupts, for example. An interrupt mask
register has the 1's there where you don't want to get an interrupt. (I
might be wrong, but it seems logical to me -- positive logic. The
"mask" action is enabled with a 1).

Anyway, it is not a serious issue...

Colin

--
From Nicolas Matringe Fri Oct 6 09:37:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00687 for ; Fri, 6 Oct 2000 14:44:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:06 +0200 (MEST) Received: (qmail 23154 invoked by uid 0); 6 Oct 2000 07:36:48 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 6 Oct 2000 07:36:48 -0000 X-eGroups-Return: sentto-1101623-1085-970817803-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hj.egroups.com with NNFMP; 06 Oct 2000 07:36:47 -0000 X-Sender: nicolas.matringe@ipricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 07:36:42 -0000 Received: (qmail 21507 invoked from network); 6 Oct 2000 07:36:41 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 6 Oct 2000 07:36:41 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 6 Oct 2000 07:36:41 -0000 Received: from ipricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA14103; Fri, 6 Oct 2000 07:36:38 GMT Message-ID: <39DD8143.C54CA31@ipricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com Cc: asdean@infolibre.net References: <399A2809.3C3EB25F@f-cpu.org> <39DCF4C2.4F9F3899@infolibre.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Oct 2000 09:37:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] l updated Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 87ec600104e05b849b1065294b8ab395 Status: R X-Status: N berkane a =E9crit :
>
> Yann Guidon a =E9crit :
> >
> > hello,
> Azdine Berkane :
> en revoir , forget me tu peut comprendre ca ?

T'es gentil mais on n'est pas responsable de ton inscription =E0 cette
liste. En principe, personne ne t'a inscrit sans ton consentement (c'est pas la politique du truc) alors tu te calmes et on voit ce qu'on peut
faire.

Nico
 From Michael Riepe Thu Oct 5 14:35:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00720 for ; Fri, 6 Oct 2000 14:44:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:14 +0200 (MEST) Received: (qmail 8817 invoked by uid 0); 6 Oct 2000 11:39:27 -0000 Received: from fl.egroups.com (208.50.144.74) by mx11.rz2.gmx.net with SMTP; 6 Oct 2000 11:39:27 -0000 X-eGroups-Return: sentto-1101623-1086-970832350-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 06 Oct 2000 11:39:15 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 11:39:09 -0000 Received: (qmail 16193 invoked from network); 6 Oct 2000 11:39:09 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 6 Oct 2000 11:39:09 -0000 Received: from unknown (HELO studserv.stud.uni-hannover.de) (130.75.176.2) by mta2 with SMTP; 6 Oct 2000 11:39:09 -0000 Received: from tribble.stud.uni-hannover.de (a252.home.uni-hannover.de [130.75.232.252]) by studserv.stud.uni-hannover.de (8.11.0/8.11.0/MTA/check_local4.1) with ESMTP id e95MQsB28984 for ; Fri, 6 Oct 2000 00:29:35 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00543; Thu, 5 Oct 2000 14:35:28 +0200 Message-ID: <20001005143527.15452@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DBF0BF.74592E65@f-cpu.org>; from Yann Guidon on Thu, Oct 05, 2000 at 04:08:47AM +0100 X-eGroups-From: Michael Riepe From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 14:35:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a1f62fed82cba03aac991c6d9b339dba Status: R X-Status: N On Thu, Oct 05, 2000 at 04:08:47AM +0100, Yann Guidon wrote:

> i looked at P&H/HW-SW interface, but they don't consider fully associative.
> They expect some kind of random access pattern, which is contrary to the
> first postulat of low entropy in space and time.

Sounds like `Knuth's Mistake'.

[...]
> > First, I have to make some binaries... the Alliance build environment
> > is really ugly :(  You should see what they did to GNU autoconf...
> maybe you can try savant then ?

I don't have the complete build env yet (one of the downloads failed).

[...]
> > Invalidating a cache line has a side effect: the address/tag comparator
> > for that line will return `false'.  That has another side effect:
> > nobody can read from this line.
> true, until it goes at the end of the FIFO. but it was already at the
> end of the FIFO so we have NBLINES cycles max to fill the line,
> because the LRU gets updated/rotated (the last becomes the recent).
> is it what you mean ?

That's correct.  But I really do not expect that we will have NBLINES
fetch operations running at the same time.  Where should they come from?

> >  If nobody can read it, there will be
> > no collision with the writer (at least not in the Icache).  And if a
> > collision can't happen, we don't have to handle it.  Same principle as
> > in the IDIV unit: we *know* beforehand that the divisor won't be 0,
> > and there will be no overflow either, so we don't have to check for
> > (and handle) any exceptions.
> i'm beginning to see what you mean. but do you fear that something like
> that will be hard to debug ? how will you see where a problem is
> if the symptoms depend on a lot of different units ?
>
> Anyway, here is the scheduling of the operation on a read :
> - read address bus and Read_En are setup, clock cycle is started
> - the tag address block compares all the addresses
> - end of the cycle : cache_hit is refreshed
> * remark : we can't decide yet what line to invalidate
> - start of the next cycle : line select signal is sent and the data is brought
>     on the output data bus.
> - in the same time, we invalidate the LRU line and keep this number as
>     a "transaction ID" for the future write.
> * remark : what if we hit a non-cachable memory region ? we'll finally flush
>     all the cache and no data will be written back after it is consumed once.

Non-cacheable regions are, by definition, not handled by the cache.
I think we will have to detect them in the MMU (or a separate
`cache/memory configuration unit') and bypass the cache.

> * remark 2 : if we can have N lines and M ongoing transactions, we still
>     can benefit from only N-M lines.
> unless there's still some things i haven't understood.

Again, where should these M ongoing transactions come from?

> > [...and later...]
> > > > I'd rather avoid collisions at all than handle them.
> > > yep, but here we can't avoid the need that causes the collisions.
> > Really?
> we have several independent units that can emit orders.

Not for the Icache.  And for the Dcache, they're probably serialized
in the L/S unit.

> We naturally must put a prioritizing element to sort the access
> (round-robin or Ifetch priority)

Yep.  First come first served.

> what i had in mind is : there's no need to hold the data when they can
> be needed urgently somewhere else. we can't do partial register forwarding
> and i would prefer a big fat multiplier to a complex small one.
> go for speed and simplicity : they go well along each other :-)
> remember that if we want to beat the Alpha and the IA-64, we need
> similar weapons ;-)

Ok, let's see how big it becomes.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From "Richard E.Hartney" Fri Oct 6 14:03:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00723 for ; Fri, 6 Oct 2000 14:44:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:16 +0200 (MEST) Received: (qmail 4388 invoked by uid 0); 6 Oct 2000 12:03:31 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 6 Oct 2000 12:03:31 -0000 X-eGroups-Return: sentto-1101623-1087-970833805-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 06 Oct 2000 12:03:30 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 12:03:24 -0000 Received: (qmail 21389 invoked from network); 6 Oct 2000 12:03:24 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 6 Oct 2000 12:03:24 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta1 with SMTP; 6 Oct 2000 12:03:24 -0000 Received: from 0018728164 (host-209-215-11-181.bix.bellsouth.net [209.215.11.181]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id IAA26002; Fri, 6 Oct 2000 08:03:17 -0400 (EDT) Message-ID: <000d01c02f8d$907d5140$b50bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 6 Oct 2000 07:03:44 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C02F63.90CD1100" X-UIDL: aafd29ecded1eb477786be87b31258ab Status: R X-Status: N ------=_NextPart_000_000A_01C02F63.90CD1100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Decided to put out a FOR WHAT ITS WORTH statement. Sent Patrick Pelgrims a document severl months ago with no pro or con respo= nse The design was for a Single Level Pipeline. This document essentialy negat= ed most of the data sent to Mr. Guidon -who to this date - also provided NO= feedback. Attempted to implement some of the F-CPU Architecture and very quickly did = an about face. Requires to much logic particularly in the Arithmetic and L= ogic Instructions. Reverted back to the 74181 concept which has worked in very = nicely. Deleted the Harvard Architecture but have retained an 18 Bit Data Soucre Ad= dress and an 18 Bit Data Destination Address in the Micro Instruction which= is now 72 BITS. Some Instruction decoding is required but is DISTRIBUTED = within the functions requiring it. In terms of decoding - there two choices= . Register the Decoded Instruction or Decode the Registered Instruction. = You will find the later to be the BEST choice.=20 Due to I/O Pin limitations - the FBC function requires an external chip. T= he design of the FBC is identical to a DMA. Mr. Guidon has this basic desig= n - logic diagrams. The only difference is where it is inserted in the SYS= TEM architecture. There also two choices of DMA implementation. Do the Data transfer in burs= t mode or interlace with Instruction execution - I wont make a recommendati= on here. I ruled out the use of XILINX devices very early in their introduction - I = required speed that they were and are still incapable of providing. The ma= jor and only asset in the device is Re-Programmablility.=20=20 This why I have chosen the Quicklogic Eclipse QL6600. The software is stil= l in Beta Testing but is now due out late this month. Normally they introd= uce the smaller devices first BUT have chosen to make available the LARGEST= devices first. Engineering samples are NOW available - but so what - need= the Software first. I require the QL6600 because of the available I/O pins =3D 512. CELLS =3D 4032 (require 2530) Max FF's =3D 9600 (require 1336) RAM =3D 36 Modules (not used) PKG =3D BGA =3D 672 total pins PLL =3D 4 DLL =3D 4 Clock Networks =3D 9 What you people call EU's, I prefer the term PE (Processing Elements). The= composite of the PE's is an EU. I currently use 9 PE's which are: CSTB (Clear Bit, Set Bit, Test Bit) SHFT (Left and Right Shift) AL32 (All required Arithmetic and Logic Functions) LOAD (Load Accumulator, Load Byte) STORE (Store Accumulator, Store Incremented Operand, Store PC) MOVE (Initiate FBC transfers, Input Terminal Data) BRAN (Condition Branch Instructions) UDRS (Other Control Instructions) VECTOR (Enable/Disable Interrupts, 8 Vectored Interrupts, Lookahead= Logic) The most important of the above PE's is VECTOR. It is designed such that t= he processor is always in the EXECUTE phase. The JMP, JST, BRAN, STORE, Op= erand Fetch, and Interrupts are fully transparent other than occupying prog= ram space. Rather than concentrating on reducing Instruction count (9967) - decided to= go for performance. Of the 9967 instructions 3082 are JMP, JST, and BRAN = executing in ZERO time. Mission accomplished - the remaining instructions = will execute in the 200 - 400 MHZ effective rate range. Can't be more spec= ific until each PE is run thru Place, Route, Back Annotate, and SILOS Simul= ation. This will tell me how to best use the CLOCK resources of the device. Since this design is M2M, which the group discarded some time ago, I can be= of little or no use to your effort - also my design is SCHEMATIC input ONL= Y and I have no desire to stop at this point and learn VHDL. VHDL is a par= t of my current Quicklogic software - never used. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_000A_01C02F63.90CD1100 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit

Decided to put out a FOR WHAT ITS WORTH statement.
 
Sent Patrick Pelgrims a document severl months ago with no pro or con response
The design was for a Single Level Pipeline.  This document essentialy negated most of the data sent to Mr. Guidon -who to this date - also provided NO feedback.
 
Attempted to implement some of the F-CPU Architecture and very quickly did an about face.  Requires to much logic particularly in the Arithmetic and Logic
Instructions.  Reverted back to the 74181 concept which has worked in very nicely.
Deleted the Harvard Architecture but have retained an 18 Bit Data Soucre Address and an 18 Bit Data Destination Address in the Micro Instruction which is now 72 BITS.  Some Instruction decoding is required but is DISTRIBUTED within the functions requiring it. In terms of decoding - there two choices.  Register the Decoded Instruction or Decode the Registered Instruction.  You will find the later to be the BEST choice.
 
Due to I/O Pin limitations - the FBC function requires an external chip.  The design of the FBC is identical to a DMA. Mr. Guidon has this basic design - logic diagrams.  The only difference is where it is inserted in the SYSTEM architecture.
There also two choices of DMA implementation.  Do the Data transfer in burst mode or interlace with Instruction execution - I wont make a recommendation here.
 
I ruled out the use of XILINX devices very early in their introduction - I required speed that they were and are still incapable of providing.  The major and only asset in the device is Re-Programmablility. 
 
This why I have chosen the Quicklogic Eclipse QL6600.  The software is still in Beta Testing but is now due out late this month.  Normally they introduce the smaller devices first BUT have chosen to make available the LARGEST devices first.  Engineering samples are NOW available - but so what - need the Software
first. I require the QL6600 because of the available I/O pins = 512.
 
        CELLS = 4032 (require 2530)
        Max FF's = 9600 (require 1336)
        RAM = 36 Modules (not used)
        PKG = BGA = 672 total pins
        PLL = 4
        DLL = 4
        Clock Networks = 9
 
What you people call EU's, I prefer the term PE (Processing Elements).  The composite of the PE's is an EU.  I currently use 9 PE's which are:
 
        CSTB (Clear Bit, Set Bit, Test Bit)
        SHFT (Left and Right Shift)
        AL32 (All required Arithmetic and Logic Functions)
        LOAD (Load Accumulator, Load Byte)
        STORE (Store Accumulator, Store Incremented Operand, Store PC)
        MOVE (Initiate FBC transfers, Input Terminal Data)
        BRAN (Condition Branch Instructions)
        UDRS (Other Control Instructions)
        VECTOR (Enable/Disable Interrupts, 8 Vectored Interrupts, Lookahead Logic)
 
The most important of the above PE's is VECTOR.  It is designed such that the processor is always in the EXECUTE phase.  The JMP, JST, BRAN, STORE, Operand Fetch, and Interrupts are fully transparent other than occupying program
space.
 
Rather than concentrating on reducing Instruction count (9967) - decided to go for performance.  Of the 9967 instructions 3082 are JMP, JST, and BRAN executing in ZERO time.  Mission accomplished - the remaining instructions will execute in the 200 - 400 MHZ effective rate range.  Can't be more specific until each PE is run thru Place, Route, Back Annotate, and SILOS Simulation. This will tell me how to best use the CLOCK resources of the device.
 
Since this design is M2M, which the group discarded some time ago, I can be of little or no use to your effort - also my design is SCHEMATIC input ONLY and I have no desire to stop at this point and learn VHDL.  VHDL is a part of my current Quicklogic software - never used.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_000A_01C02F63.90CD1100-- From Michael Riepe Thu Oct 5 20:11:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00726 for ; Fri, 6 Oct 2000 14:44:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Oct 2000 14:44:18 +0200 (MEST) Received: (qmail 17476 invoked by uid 0); 6 Oct 2000 12:04:52 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 6 Oct 2000 12:04:52 -0000 X-eGroups-Return: sentto-1101623-1088-970833886-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 06 Oct 2000 12:04:56 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 12:04:45 -0000 Received: (qmail 23632 invoked from network); 6 Oct 2000 12:04:45 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 6 Oct 2000 12:04:45 -0000 Received: from unknown (HELO studserv.stud.uni-hannover.de) (130.75.176.2) by mta2 with SMTP; 6 Oct 2000 12:04:45 -0000 Received: from tribble.stud.uni-hannover.de (a252.home.uni-hannover.de [130.75.232.252]) by studserv.stud.uni-hannover.de (8.11.0/8.11.0/MTA/check_local4.1) with ESMTP id e95MOCB28254 for ; Fri, 6 Oct 2000 00:26:53 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA07444; Thu, 5 Oct 2000 20:11:27 +0200 Message-ID: <20001005201127.11930@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e X-eGroups-From: Michael Riepe From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Oct 2000 20:11:27 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Alliance Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6a44c6eab2f576364435116e2f4502ca Status: R X-Status: N Alliance finally works, but...

The VHDL subset (called VBE) it supports is rather limited.  It doesn't
grok processes and sequential statements, and even `library IEEE;'
results in a parse error.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From pelgrims p Fri Oct 6 14:42:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00319 for ; Sat, 7 Oct 2000 14:16:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:17 +0200 (MEST) Received: (qmail 22524 invoked by uid 0); 6 Oct 2000 12:43:35 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 6 Oct 2000 12:43:35 -0000 X-eGroups-Return: sentto-1101623-1089-970836212-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 06 Oct 2000 12:43:31 -0000 X-Sender: patrick.pelgrims@pandora.be X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 12:43:31 -0000 Received: (qmail 732 invoked from network); 6 Oct 2000 12:43:31 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 6 Oct 2000 12:43:31 -0000 Received: from unknown (HELO smtp.pandora.be) (195.130.132.33) by mta1 with SMTP; 6 Oct 2000 12:43:31 -0000 Received: (qmail 14124 invoked from network); 6 Oct 2000 12:43:30 -0000 Received: from unknown (HELO pandora.be) ([213.224.165.171]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 6 Oct 2000 12:43:30 -0000 Sender: root@pop.gmx.net Message-ID: <39DDC8CE.D9CD33B8@pandora.be> Organization: A X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000d01c02f8d$907d5140$b50bd7d1@0018728164> From: pelgrims p MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Oct 2000 14:42:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN32 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f01ae6235e8c827fd737901e9d58f3e6 Status: R X-Status: N "Richard E.Hartney" wrote:

> Decided to put out a FOR WHAT ITS WORTH statement. Sent Patrick
> Pelgrims a document severl months ago with no pro or con responseThe
> design was for a Single Level Pipeline.  This document essentialy
> negated most of the data sent to Mr. Guidon -who to this date - also
> provided NO feedback.
>
> -> It is a fine desing !!!! Simple but useful. Attempted to implement
> some of the F-CPU Architecture and very quickly did an about face.
> Requires to much logic particularly in the Arithmetic and
> LogicInstructions.  Reverted back to the 74181 concept which has
> worked in very nicely.
> -> Have seen that ! Very nice done !
>
> Deleted the Harvard Architecture but have retained an 18 Bit Data
> Soucre Address and an 18 Bit Data Destination Address in the Micro
> Instruction which is now 72 BITS.  Some Instruction decoding is
> required but is DISTRIBUTED within the functions requiring it. In
> terms of decoding - there two choices.  Register the Decoded
> Instruction or Decode the Registered Instruction.  You will find the
> later to be the BEST choice. Due to I/O Pin limitations - the FBC
> function requires an external chip.  The design of the FBC is
> identical to a DMA. Mr. Guidon has this basic design - logic
> diagrams.  The only difference is where it is inserted in the SYSTEM
> architecture.There also two choices of DMA implementation.  Do the
> Data transfer in burst mode or interlace with Instruction execution -
> I wont make a recommendation here. I ruled out the use of XILINX
> devices very early in their introduction - I required speed that they
> were and are still incapable of providing.  The major and only asset
> in the device is Re-Programmablility. This why I have chosen the
> Quicklogic Eclipse QL6600.  The software is still in Beta Testing but
> is now due out late this month.  Normally they introduce the smaller
> devices first BUT have chosen to make available the LARGEST devices
> first.  Engineering samples are NOW available - but so what - need the
> Softwarefirst. I require the QL6600 because of the available I/O pins
> = 512.         CELLS = 4032 (require 2530)        Max FF's = 9600
> (require 1336)        RAM = 36 Modules (not used)        PKG = BGA =
> 672 total pins        PLL = 4        DLL = 4        Clock Networks =
> 9 What you people call EU's, I prefer the term PE (Processing
> Elements).  The composite of the PE's is an EU.  I currently use 9
> PE's which are:         CSTB (Clear Bit, Set Bit, Test Bit)
> SHFT (Left and Right Shift)        AL32 (All required Arithmetic and
> Logic Functions)        LOAD (Load Accumulator, Load Byte)
> STORE (Store Accumulator, Store Incremented Operand, Store PC)
> MOVE (Initiate FBC transfers, Input Terminal Data)        BRAN
> (Condition Branch Instructions)        UDRS (Other Control
> Instructions)        VECTOR (Enable/Disable Interrupts, 8 Vectored
> Interrupts, Lookahead Logic) The most important of the above PE's is
> VECTOR.  It is designed such that the processor is always in the
> EXECUTE phase.  The JMP, JST, BRAN, STORE, Operand Fetch, and
> Interrupts are fully transparent other than occupying
> programspace. Rather than concentrating on reducing Instruction count
> (9967) - decided to go for performance.  Of the 9967 instructions 3082
> are JMP, JST, and BRAN executing in ZERO time.  Mission accomplished -
> the remaining instructions will execute in the 200 - 400 MHZ effective
> rate range.  Can't be more specific until each PE is run thru Place,
> Route, Back Annotate, and SILOS Simulation. This will tell me how to
> best use the CLOCK resources of the device.
> -> Yes, I'm thinking the same :-)
>  Since this design is M2M, which the group discarded some time ago, I
> can be of little or no use to your effort - also my design is
> SCHEMATIC input ONLY and I have no desire to stop at this point and
> learn VHDL.  VHDL is a part of my current Quicklogic software - never
> used. SincerelyRichard E. HartneyResearch DirectorErin Greene &
> Associates

Sorry for the delay Mr Erin, but it have taken a time to look in you
design schematics !!!
Still well done !!!
Hopfully we may find also other similar examples on the web or in our
"mailbox" :-).

Thanks again,

    P. Pelgrims
eGroups Sponsor
From "Richard E.Hartney" Fri Oct 6 19:33:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00338 for ; Sat, 7 Oct 2000 14:16:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:21 +0200 (MEST) Received: (qmail 28893 invoked by uid 0); 6 Oct 2000 17:34:27 -0000 Received: from ck.egroups.com (208.50.144.69) by mx06.rz2.gmx.net with SMTP; 6 Oct 2000 17:34:27 -0000 X-eGroups-Return: sentto-1101623-1090-970853606-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 06 Oct 2000 17:33:27 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 17:33:25 -0000 Received: (qmail 29722 invoked from network); 6 Oct 2000 17:33:25 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 6 Oct 2000 17:33:25 -0000 Received: from unknown (HELO mail0.lig.bellsouth.net) (205.152.0.90) by mta2 with SMTP; 6 Oct 2000 17:33:25 -0000 Received: from 0018728164 (host-209-214-154-116.bix.bellsouth.net [209.214.154.116]) by mail0.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id NAA21774; Fri, 6 Oct 2000 13:33:20 -0400 (EDT) Message-ID: <000801c02fbb$ac9660a0$749ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 6 Oct 2000 12:33:49 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C02F91.ADAF8AE0" X-UIDL: 0cae93f071569cb7ae84795b1b5cdd04 Status: R X-Status: N ------=_NextPart_000_0005_01C02F91.ADAF8AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my previous mailing of today --- I neglected to say the design requires = four (4) EU's based on the instruction mix percentages I provided some time ago to a= chieve the 200 - 400 MHZ rate. This is included in the CELL count of 2530 e= tc. ALL PE's include all logic required to carry it thru the Execution Pha= se, including look-ahead arbitration. You people may use a different term = here.=20=20 For Multiplication - try the Time-sequenced/pipelined approach much less lo= gic in the array. May be either fixed time or variable by skipping stings = of zero's.(AMD) For Division - try the skip strings of one's and zero's approach. Will be = variable in terms of actual execution time however.(FLORES) Both of the above Mul/Div can be used in Floating Point. I see absolutely no need for the SIMD requirement as you are not trying to = capture code from 8,16,32 bit processor families as are AMD/INTEL. MOTOROLA did th= e same thing when they introduced the 68020. To capture 6800, 68000, and 6= 8010 data forms Think on this for a while. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C02F91.ADAF8AE0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
In my previous mailing of today --- I neglected to say the design requires four (4)
EU's based on the instruction mix percentages I provided some time ago to achieve the 200 - 400 MHZ rate. This is included in the CELL count of 2530 etc.  ALL PE's include all logic required to carry it thru the Execution Phase, including look-ahead arbitration.  You people may use a different term here. 
 
For Multiplication - try the Time-sequenced/pipelined approach much less logic in the array.  May be either fixed time or variable by skipping stings of zero's.(AMD)
 
For Division - try the skip strings of one's and zero's approach.  Will be variable in
terms of actual execution time however.(FLORES)
 
Both of the above Mul/Div can be used in Floating Point.
 
I see absolutely no need for the SIMD requirement as you are not trying to capture
code from 8,16,32 bit processor families as are AMD/INTEL.  MOTOROLA did the same thing when they introduced the 68020.  To capture 6800, 68000, and 68010
data forms
 
Think on this for a while.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
------=_NextPart_000_0005_01C02F91.ADAF8AE0-- From Michael Riepe Fri Oct 6 14:38:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00398 for ; Sat, 7 Oct 2000 14:16:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:34 +0200 (MEST) Received: (qmail 3823 invoked by uid 0); 6 Oct 2000 21:56:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net with SMTP; 6 Oct 2000 21:56:40 -0000 X-eGroups-Return: sentto-1101623-1091-970869395-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 06 Oct 2000 21:56:40 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 21:56:34 -0000 Received: (qmail 5983 invoked from network); 6 Oct 2000 21:56:34 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 6 Oct 2000 21:56:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.89) by mta3 with SMTP; 6 Oct 2000 21:56:26 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00472; Fri, 6 Oct 2000 14:38:55 +0200 Message-ID: <20001006143854.01095@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DD3435.925F47D3@f-cpu.org>; from Yann Guidon on Fri, Oct 06, 2000 at 03:08:53AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 6 Oct 2000 14:38:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 33c268ca6e50f041b35f873fb0790de5 Status: R X-Status: N On Fri, Oct 06, 2000 at 03:08:53AM +0100, Yann Guidon wrote:
> Jecel Assumpcao Jr wrote:
> > I wanted to know something like "yes, this design will take up 40% more
> > gates, but it will perform 13% better and so is worth it".
>
> i haven't found any numbers, mostly because full associativity
> is not much used. maybe someone's gotta ask on comp.arch BUT
> if you want numbers, they can mislead you : it always depends on
> a lot of factors and the real impact is much too varied, as the
> systems change.

To get `exact' numbers for the F-CPU (especially the I-cache), we will
have to emulate it.  Is there an emulator for the current ISA?  I didn't
find any links in the mailing list archive.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sat Oct 7 00:28:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00413 for ; Sat, 7 Oct 2000 14:16:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:37 +0200 (MEST) Received: (qmail 30093 invoked by uid 0); 6 Oct 2000 22:28:18 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 6 Oct 2000 22:28:18 -0000 X-eGroups-Return: sentto-1101623-1092-970871292-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 06 Oct 2000 22:28:15 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 22:28:12 -0000 Received: (qmail 21398 invoked from network); 6 Oct 2000 22:28:12 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 6 Oct 2000 22:28:12 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.89) by mta2 with SMTP; 6 Oct 2000 22:28:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00659; Sat, 7 Oct 2000 00:28:04 +0200 Message-ID: <20001007002803.29225@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <000801c02fbb$ac9660a0$749ad6d1@0018728164> X-Mailer: Mutt 0.84e In-Reply-To: <000801c02fbb$ac9660a0$749ad6d1@0018728164>; from Richard E.Hartney on Fri, Oct 06, 2000 at 12:33:49PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 7 Oct 2000 00:28:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN32 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 54cdac94f891c537182e29ccfd6dcae9 Status: R X-Status: N On Fri, Oct 06, 2000 at 12:33:49PM -0500, Richard E.Hartney wrote:

> I see absolutely no need for the SIMD requirement as you are not trying to capture
> code from 8,16,32 bit processor families as are AMD/INTEL.  MOTOROLA did the same thing when they introduced the 68020.  To capture 6800, 68000, and 68010
> data forms

Au contraire.  SIMD is useful for a lot of things.  Audio/video/image
processing, for example, or fast encryption/decryption.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Sat Oct 7 01:37:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00416 for ; Sat, 7 Oct 2000 14:16:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:38 +0200 (MEST) Received: (qmail 23078 invoked by uid 0); 6 Oct 2000 22:33:43 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 6 Oct 2000 22:33:43 -0000 X-eGroups-Return: sentto-1101623-1094-970871613-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 06 Oct 2000 22:33:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 22:33:33 -0000 Received: (qmail 13210 invoked from network); 6 Oct 2000 22:33:33 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 6 Oct 2000 22:33:33 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 6 Oct 2000 22:33:32 -0000 Received: from f-cpu.org (nas4-134.aub.club-internet.fr [195.36.145.134]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA01081 for ; Sat, 7 Oct 2000 00:33:28 +0200 (MET DST) Message-ID: <39DE6221.C2A9050F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 00:37:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1756d7f2677b8ffc63a78f707878a7ac Status: R X-Status: N Michael Riepe wrote:
> On Thu, Oct 05, 2000 at 04:08:47AM +0100, Yann Guidon wrote:
> > i looked at P&H/HW-SW interface, but they don't consider fully associative.
> > They expect some kind of random access pattern, which is contrary to the
> > first postulat of low entropy in space and time.
> Sounds like `Knuth's Mistake'.
what was it, btw ?

> [...]
> > > First, I have to make some binaries... the Alliance build environment
> > > is really ugly :(  You should see what they did to GNU autoconf...
> > maybe you can try savant then ?
> I don't have the complete build env yet (one of the downloads failed).
good luck !

> [...]
> > > Invalidating a cache line has a side effect: the address/tag comparator
> > > for that line will return `false'.  That has another side effect:
> > > nobody can read from this line.
> > true, until it goes at the end of the FIFO. but it was already at the
> > end of the FIFO so we have NBLINES cycles max to fill the line,
> > because the LRU gets updated/rotated (the last becomes the recent).
> > is it what you mean ?
> That's correct.  But I really do not expect that we will have NBLINES
> fetch operations running at the same time.  Where should they come from?
no, we won't and shouldn't have that much access but, in average with a simple
FC0 with 2 SDRAM banks (8 lines) we can have probably 10 read requests at the same
time. if we have a 2KB Icache, we'll have up to 4 fetch requests and that uses
4 of the 64 lines, we waste 6% of the available space.

> > * remark : what if we hit a non-cachable memory region ? we'll finally flush
> >     all the cache and no data will be written back after it is consumed once.
> Non-cacheable regions are, by definition, not handled by the cache.
yup, but at the Icache level, where no cycle should be wasted,
it's not the best place to do it.

> I think we will have to detect them in the MMU (or a separate
> `cache/memory configuration unit') and bypass the cache.
i don't see exactly where you want to go, but my problem here is to not waste
cycles : the cachability can be determined by the memory interface,
but it would waste silicon and time to duplicate it to the L/SU and the fetcher.

my idea is :
- fetch request : address is calculated
- the address is compared with the 8 fetcher's lines
- on miss, the address is sent to the Icache address tags
- next cycle : the "cache hit" signal is sampled. if 'true', the data bus
    is latched on a free fetcher's line. end of the game.
- if false, the address is sent to the memory interface :
    address ranges, bank merging etc are computed. the request
    is put in a FIFO and the latency is undetermined.
- when the first data is finally available, it is sent on the internal data bus
    to the fetcher or the L/SU so the different chunks are merged and used
    immediately, in the needed order.
-- As soon as the line is complete AND if the data is cachable,
    the data is sent to the cache block. The address and the data are known
    from the fetcher line or its attributes.

The "cachability" attribute
can also be controlled by the software : for the Load/Store operations,
the cachability hint bit is available from the opcode. For the instructions,
there could be an instruction that says : "don't bother to cache the following
instructions because we know that it won't be used anytime soon". The bit
can be discarded as soon as we enter in a loop (instruction "loopentry")
or jump to somewhere else.

> > * remark 2 : if we can have N lines and M ongoing transactions, we still
> >     can benefit from only N-M lines.
> > unless there's still some things i haven't understood.
> Again, where should these M ongoing transactions come from?
"transactional memories" : several banks with pipelined access. This makes
M=P*B (banks*pipeline stages) possible ongoing transactions, PLUS the waiting
transaction requests that can wait in the FIFO.

> > > [...and later...]
> > > > > I'd rather avoid collisions at all than handle them.
> > > > yep, but here we can't avoid the need that causes the collisions.
> > > Really?
> > we have several independent units that can emit orders.
> Not for the Icache.
why ? We have 8 fetcher lines, we can emit 1 read request per cycle
(as much as the instructions/cycle rate), plus the write requests from the
memory controller, so we have to prioritize the access.

>  And for the Dcache, they're probably serialized in the L/S unit.
if it's serialized, this means that several accesses can be emitted.

> > We naturally must put a prioritizing element to sort the access
> > (round-robin or Ifetch priority)
> Yep.  First come first served.
FIFO, then.

> > what i had in mind is : there's no need to hold the data when they can
> > be needed urgently somewhere else. we can't do partial register forwarding
> > and i would prefer a big fat multiplier to a complex small one.
> > go for speed and simplicity : they go well along each other :-)
> > remember that if we want to beat the Alpha and the IA-64, we need
> > similar weapons ;-)
> Ok, let's see how big it becomes.
yep, "how big and how good" :-)
have fun and look around on the Net to find other references :
i've seen some already.


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS: is is my mail server, or Michael's mail always arrive late ?
it seems to me that there is almost 1 day of lag.
 From Yann Guidon Sat Oct 7 01:36:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00419 for ; Sat, 7 Oct 2000 14:16:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:40 +0200 (MEST) Received: (qmail 14196 invoked by uid 0); 6 Oct 2000 22:33:43 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 6 Oct 2000 22:33:43 -0000 X-eGroups-Return: sentto-1101623-1095-970871613-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ci.egroups.com with NNFMP; 06 Oct 2000 22:33:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 22:33:33 -0000 Received: (qmail 13209 invoked from network); 6 Oct 2000 22:33:33 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 6 Oct 2000 22:33:33 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 6 Oct 2000 22:33:32 -0000 Received: from f-cpu.org (nas4-134.aub.club-internet.fr [195.36.145.134]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA10066 for ; Sat, 7 Oct 2000 00:33:28 +0200 (MET DST) Message-ID: <39DE621A.CFCDA93F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D78185.6190890E@f-cpu.org> <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> <39DA6CF7.2FF43696@f-cpu.org> <20001004044747.48281@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 00:36:58 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: CVS + others Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5630946d17ac85ec58a28b1b6e85ca7d Status: R X-Status: N hi,
Colin Marquardt wrote:
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
> > CVS isn't hard to use at all, and you can set it up with only a few steps.
> > Those of you who are interested in CVS should read the CVS documentation
> > (cvs.info, normally).  It contains a short introduction, too.
> I find that book (a large part of it free) pretty cool:
>   http://www.red-bean.com/cvsbook/
i've d/l it.

> BTW, the diploma thesis about comparing VHDL coding techniques is at
> http://mikro.e-technik.uni-ulm.de/education/upload_data/jriexing_diplomarbeit.pdf
> [in german]
d/l too. i still have to read it.

Colin Marquardt wrote:
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
> > In Software, you usually want to keep some bits and set the rest to 0.
> > This means you AND the bits you need with 1, others with 0.  This
> > differs from the meaning of `mask' in most other situations (unless
> > you define that the 0-bits form the mask, of course ;).
>
> I would define the latter for interrupts, for example. An interrupt mask
> register has the 1's there where you don't want to get an interrupt. (I
> might be wrong, but it seems logical to me -- positive logic. The
> "mask" action is enabled with a 1).
>
> Anyway, it is not a serious issue...

right, but as you can remark, it's rather annoying :-)
so let's find a good compromise. it's not very critical in fact because it's
about HW implementation, not about SW interface.

> Cheers,
>   Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sat Oct 7 01:37:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00422 for ; Sat, 7 Oct 2000 14:16:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:41 +0200 (MEST) Received: (qmail 23242 invoked by uid 0); 6 Oct 2000 22:33:52 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 6 Oct 2000 22:33:52 -0000 X-eGroups-Return: sentto-1101623-1093-970871613-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 06 Oct 2000 22:33:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 22:33:32 -0000 Received: (qmail 19762 invoked from network); 6 Oct 2000 22:33:32 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 6 Oct 2000 22:33:32 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 6 Oct 2000 22:33:32 -0000 Received: from f-cpu.org (nas4-134.aub.club-internet.fr [195.36.145.134]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA26325 for ; Sat, 7 Oct 2000 00:33:28 +0200 (MET DST) Message-ID: <39DE621E.2B7A8A4A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001001233014.63696@thrai.stud.uni-hannover.de> <39D7CB87.7A4E5619@f-cpu.org> <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <20001005201127.11930@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 00:37:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Alliance Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 47383bcbaef0572dbe24150c63da8286 Status: R X-Status: N Michael Riepe wrote:
> Alliance finally works, but...
>
> The VHDL subset (called VBE) it supports is rather limited.  It doesn't
> grok processes and sequential statements, and even `library IEEE;'
> results in a parse error.

THAT hurts.
so i'll stick to Simili until there's something better.
BUT if i'm hired where i WISH to be,
i'll be using extra-fresh tools that we couldn't pay otherwise :-)


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Oct 7 01:36:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00455 for ; Sat, 7 Oct 2000 14:16:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:55 +0200 (MEST) Received: (qmail 13066 invoked by uid 0); 6 Oct 2000 23:36:18 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 6 Oct 2000 23:36:18 -0000 X-eGroups-Return: sentto-1101623-1096-970875374-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 06 Oct 2000 23:36:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 23:36:14 -0000 Received: (qmail 7297 invoked from network); 6 Oct 2000 23:36:13 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 6 Oct 2000 23:36:13 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.89) by mta1 with SMTP; 6 Oct 2000 23:36:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00874; Sat, 7 Oct 2000 01:36:07 +0200 Message-ID: <20001007013607.33815@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DE6221.C2A9050F@f-cpu.org>; from Yann Guidon on Sat, Oct 07, 2000 at 12:37:05AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 7 Oct 2000 01:36:07 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a6aeb3527116ff425645b6fd0242a082 Status: R X-Status: N On Sat, Oct 07, 2000 at 12:37:05AM +0100, Yann Guidon wrote:

> > Sounds like `Knuth's Mistake'.
> what was it, btw ?

He made some caching experiments and relied on the results.
Which he should not have done ;)

> > > maybe you can try savant then ?
> > I don't have the complete build env yet (one of the downloads failed).
> good luck !

Too late.  I got it running.  But I don't like it either.  It requires a
C++ compiler for simulation -- it compiles VHDL to C++ -- and it creates
HUGE binaries (and when I say huge, I really do mean huge).  Back to
Simili...

[...]
> > That's correct.  But I really do not expect that we will have NBLINES
> > fetch operations running at the same time.  Where should they come from?
> no, we won't and shouldn't have that much access but, in average with a simple
> FC0 with 2 SDRAM banks (8 lines) we can have probably 10 read requests at the same
> time. if we have a 2KB Icache, we'll have up to 4 fetch requests and that uses
> 4 of the 64 lines, we waste 6% of the available space.

I could live with that.

> > > * remark : what if we hit a non-cachable memory region ? we'll finally flush
> > >     all the cache and no data will be written back after it is consumed once.
> > Non-cacheable regions are, by definition, not handled by the cache.
> yup, but at the Icache level, where no cycle should be wasted,
> it's not the best place to do it.

If a page of code (as opposed to data) is uncacheable, there's something
wrong.

> > I think we will have to detect them in the MMU (or a separate
> > `cache/memory configuration unit') and bypass the cache.
> i don't see exactly where you want to go, but my problem here is to not waste
> cycles : the cachability can be determined by the memory interface,
> but it would waste silicon and time to duplicate it to the L/SU and the fetcher.

Maybe I'm in the wrong state of mind ;)  No piece of memory is uncacheable
*per se*.  It's the operating system that decides not to cache certain
areas (for reasons that shall not interest us further).  This information
can be put into a separate unit (like intel's MTRRs), or somewhere else.
IMHO the MMU is a good place.

[...]
> The "cachability" attribute
> can also be controlled by the software : for the Load/Store operations,
> the cachability hint bit is available from the opcode. For the instructions,
> there could be an instruction that says : "don't bother to cache the following
> instructions because we know that it won't be used anytime soon". The bit
> can be discarded as soon as we enter in a loop (instruction "loopentry")
> or jump to somewhere else.

This is indeed a different kind of `uncacheable' than I had in mind.

> > > * remark 2 : if we can have N lines and M ongoing transactions, we still
> > >     can benefit from only N-M lines.
> > > unless there's still some things i haven't understood.
> > Again, where should these M ongoing transactions come from?
> "transactional memories" : several banks with pipelined access. This makes
> M=P*B (banks*pipeline stages) possible ongoing transactions, PLUS the waiting
> transaction requests that can wait in the FIFO.

We're slowly drifting over to the Dcache, do we?

> > > > [...and later...]
> > > > > > I'd rather avoid collisions at all than handle them.
> > > > > yep, but here we can't avoid the need that causes the collisions.
> > > > Really?
> > > we have several independent units that can emit orders.
> > Not for the Icache.
> why ? We have 8 fetcher lines, we can emit 1 read request per cycle
> (as much as the instructions/cycle rate), plus the write requests from the
> memory controller, so we have to prioritize the access.

I can't see the picture, sorry.  How many instructions can we throw at
the IF/ID unit per cycle?  A single cache line holds 8 instructions.

> >  And for the Dcache, they're probably serialized in the L/S unit.
> if it's serialized, this means that several accesses can be emitted.

Yes, one after another.  That means they won't collide with each
other any more.

[...]
> PS: is is my mail server, or Michael's mail always arrive late ?
> it seems to me that there is almost 1 day of lag.

The DFN had some problems with one of its overseas connections...
Maybe a cleaningwoman in NYC pulled the wrong plug ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"Whenever I hear the word `cleaningwoman' I go berzerk" -- Steve Martin
 From Michael Riepe Sat Oct 7 01:41:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00458 for ; Sat, 7 Oct 2000 14:16:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:56 +0200 (MEST) Received: (qmail 19676 invoked by uid 0); 6 Oct 2000 23:41:37 -0000 Received: from mu.egroups.com (208.50.99.218) by mx19.rz2.gmx.net with SMTP; 6 Oct 2000 23:41:37 -0000 X-eGroups-Return: sentto-1101623-1097-970875683-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mu.egroups.com with NNFMP; 06 Oct 2000 23:41:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 23:41:22 -0000 Received: (qmail 19220 invoked from network); 6 Oct 2000 23:41:22 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 6 Oct 2000 23:41:22 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.89) by mta1 with SMTP; 6 Oct 2000 23:41:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00892; Sat, 7 Oct 2000 01:41:17 +0200 Message-ID: <20001007014117.22959@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D7CB86.4A0B5926@f-cpu.org> <20001002145309.62114@thrai.stud.uni-hannover.de> <20001003162949.10349@thrai.stud.uni-hannover.de> <39DA6CF7.2FF43696@f-cpu.org> <20001004044747.48281@thrai.stud.uni-hannover.de> <39DE621A.CFCDA93F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DE621A.CFCDA93F@f-cpu.org>; from Yann Guidon on Sat, Oct 07, 2000 at 12:36:58AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 7 Oct 2000 01:41:17 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: CVS + others Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e1e2772a5ac475bfb2f82ca3824134cf Status: R X-Status: N On Sat, Oct 07, 2000 at 12:36:58AM +0100, Yann Guidon wrote:

[mask stuff]
> right, but as you can remark, it's rather annoying :-)
> so let's find a good compromise. it's not very critical in fact because it's
> about HW implementation, not about SW interface.

Since we compare addresses and tags, the interesting operation is

      (addr xor tag) = zero

To skip some bits, and them with `0':

      (addr xor tag) and mask = zero

The bits we still look at will have their mask bits set to `1' (or
"transparent", if you prefer).  The other bits are set to `0' ("opaque").

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Sat Oct 7 02:51:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00461 for ; Sat, 7 Oct 2000 14:16:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:56 +0200 (MEST) Received: (qmail 4408 invoked by uid 0); 6 Oct 2000 23:47:35 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 6 Oct 2000 23:47:35 -0000 X-eGroups-Return: sentto-1101623-1098-970876031-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 06 Oct 2000 23:47:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 23:47:10 -0000 Received: (qmail 23724 invoked from network); 6 Oct 2000 23:47:10 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 6 Oct 2000 23:47:10 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 6 Oct 2000 23:47:10 -0000 Received: from f-cpu.org (nas2-213.ras.club-internet.fr [195.36.192.213]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA14230 for ; Sat, 7 Oct 2000 01:47:07 +0200 (MET DST) Message-ID: <39DE7396.57A951D6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 01:51:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] yet some other merged replies (cache+misc.+erin) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 482290c6ecb49a35cf60e331d14ff61c Status: R X-Status: N hi,

Michael Riepe wrote:
> On Fri, Oct 06, 2000 at 03:08:53AM +0100, Yann Guidon wrote:
> > Jecel Assumpcao Jr wrote:
> > > I wanted to know something like "yes, this design will take up 40% more
> > > gates, but it will perform 13% better and so is worth it".
> > i haven't found any numbers, mostly because full associativity
> > is not much used. maybe someone's gotta ask on comp.arch BUT
> > if you want numbers, they can mislead you : it always depends on
> > a lot of factors and the real impact is much too varied, as the
> > systems change.
>
> To get `exact' numbers for the F-CPU (especially the I-cache), we will
> have to emulate it.  Is there an emulator for the current ISA?  I didn't
> find any links in the mailing list archive.

unfortunately there is no emulator. yet. if Simili is solid enough,
it will become this emulator, when running the simulations.
some time ago, i was about to write one again, but i finally founs Simili.
I think that we can probably do both C and VHDL emulators at the same time.
then, VHDL will be aimed at accuracy and C for speed of simulation
(skipping some temporary variables etc...).


then :

Michael Riepe wrote:
> On Fri, Oct 06, 2000 at 12:33:49PM -0500, Richard E.Hartney wrote:
> > I see absolutely no need for the SIMD requirement as you are not trying
> > to capture code from 8,16,32 bit processor families as are AMD/INTEL.
> >  MOTOROLA did the same thing when they introduced the 68020.  To capture
> > 6800, 68000, and 68010 data forms
6800 ???

> Au contraire.  SIMD is useful for a lot of things.  Audio/video/image
> processing, for example, or fast encryption/decryption.
SIMD is also one secure way to extend the computing performance at almost no
software cost. the F-CPU as it is now is defined to be as extensible as possible
and wide SIMD registers is an easy way to boost algebaic or repetitive parallel
algoritms, such as noted before. this is not an "extension" as in other CPUs,
the SIMD factor is part of the F-CPU development and ISA. we don't try to capture
anything, except speed :-)


then :


"Richard E.Hartney" wrote:
> For Multiplication - try the Time-sequenced/pipelined
> approach much less logic in the array.  May be either
> fixed time or variable by skipping stings of zero's.(AMD)
>
> For Division - try the skip strings of one's and zero's
> approach.  Will be variable in terms of actual execution
> time however.(FLORES)
i agree with you about these points. Unfortunately, as you remarked,
these solutions have a variable, "data-dependent" latency.
these latency also depends on the magnitude of the numbers
because most 1 or 0 strings are situated in the MSBs of the
numbers. I don't have any flexible and reliable solution for
this problem yet.

> Both of the above Mul/Div can be used in Floating Point.
yes, they require some additional HW but that can work this way
for a single-instruction issue pipeline.

> Think on this for a while.
we'll do this on this list, thank you for the contributions.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sat Oct 7 02:53:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00464 for ; Sat, 7 Oct 2000 14:16:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:16:58 +0200 (MEST) Received: (qmail 13078 invoked by uid 0); 6 Oct 2000 23:49:20 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 6 Oct 2000 23:49:20 -0000 X-eGroups-Return: sentto-1101623-1099-970876156-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 06 Oct 2000 23:49:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 6 Oct 2000 23:49:16 -0000 Received: (qmail 5962 invoked from network); 6 Oct 2000 23:49:16 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 6 Oct 2000 23:49:16 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 6 Oct 2000 23:49:15 -0000 Received: from f-cpu.org (nas2-213.ras.club-internet.fr [195.36.192.213]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA03432 for ; Sat, 7 Oct 2000 01:49:13 +0200 (MET DST) Message-ID: <39DE7414.A7A19BF5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 01:53:40 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] http://www.senga.org/Catalog/html/ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 016aa9e2775e9bcf4555fd77712aea37 Status: R X-Status: N at http://www.senga.org/Catalog/html/ there are
nice stuffs to add to the group's server.

anyway, it's as useful as the webring : not much
but funny anyway :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Oct 7 04:05:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00479 for ; Sat, 7 Oct 2000 14:17:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Oct 2000 14:17:03 +0200 (MEST) Received: (qmail 17632 invoked by uid 0); 7 Oct 2000 01:01:15 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 7 Oct 2000 01:01:15 -0000 X-eGroups-Return: sentto-1101623-1100-970880471-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hp.egroups.com with NNFMP; 07 Oct 2000 01:01:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 01:01:10 -0000 Received: (qmail 13850 invoked from network); 7 Oct 2000 01:01:10 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 7 Oct 2000 01:01:10 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 7 Oct 2000 01:01:10 -0000 Received: from f-cpu.org (nas1-154.ras.club-internet.fr [195.36.192.154]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA09954 for ; Sat, 7 Oct 2000 03:01:06 +0200 (MET DST) Message-ID: <39DE84ED.7039B3D8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001002015229.31639@thrai.stud.uni-hannover.de> <39D9516E.DA1D0A0@f-cpu.org> <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 03:05:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc21aa12a8d11c95a51a25a06c062f98 Status: R X-Status: N Michael Riepe wrote:
> On Sat, Oct 07, 2000 at 12:37:05AM +0100, Yann Guidon wrote:
> > > Sounds like `Knuth's Mistake'.
> > what was it, btw ?
> He made some caching experiments and relied on the results.
> Which he should not have done ;)
hehe.

So, in order to have a good idea of the behaviour, the least
we can do is run SpecInt or something like that ;-)

> > > > maybe you can try savant then ?
> > > I don't have the complete build env yet (one of the downloads failed).
> > good luck !
> Too late.  I got it running.  But I don't like it either.  It requires a
> C++ compiler for simulation -- it compiles VHDL to C++ -- and it creates
> HUGE binaries (and when I say huge, I really do mean huge).  Back to Simili...
heck. i hope to find a decent solution soon.

> [...]
> > > That's correct.  But I really do not expect that we will have NBLINES
> > > fetch operations running at the same time.  Where should they come from?
> > no, we won't and shouldn't have that much access but, in average with a simple
> > FC0 with 2 SDRAM banks (8 lines) we can have probably 10 read requests at the same
> > time. if we have a 2KB Icache, we'll have up to 4 fetch requests and that uses
> > 4 of the 64 lines, we waste 6% of the available space.
> I could live with that.
not me :-) i want ALL the lines to contain useful informations.

> > > > * remark : what if we hit a non-cachable memory region ? we'll finally flush
> > > >     all the cache and no data will be written back after it is consumed once.
> > > Non-cacheable regions are, by definition, not handled by the cache.
> > yup, but at the Icache level, where no cycle should be wasted,
> > it's not the best place to do it.
> If a page of code (as opposed to data) is uncacheable, there's something
> wrong.
have you looked at your BIOS settings ?
have you checked : "Video ROM cachable" ? "BIOS ROM cachable" ?
i would consider it as too optimistic to consider all instructions as cachable.

> > > I think we will have to detect them in the MMU (or a separate
> > > `cache/memory configuration unit') and bypass the cache.
> > i don't see exactly where you want to go, but my problem here is to not waste
> > cycles : the cachability can be determined by the memory interface,
> > but it would waste silicon and time to duplicate it to the L/SU and the fetcher.
> Maybe I'm in the wrong state of mind ;)
i don't know...

>  No piece of memory is uncacheable
> *per se*.  It's the operating system that decides not to cache certain
> areas (for reasons that shall not interest us further).  This information
> can be put into a separate unit (like intel's MTRRs), or somewhere else.
> IMHO the MMU is a good place.
in the current platforms, it's the HW that decides what is cachable or not.
ie, if you execute code that is located on a PCI board, chances are that
it's not cachable because it's an I/O.

As for the first FC0, as soon as you go out of private space, it's uncachable
because it avoids any MESI problem :-)

> [...]
> > The "cachability" attribute
> > can also be controlled by the software : for the Load/Store operations,
> > the cachability hint bit is available from the opcode. For the instructions,
> > there could be an instruction that says : "don't bother to cache the following
> > instructions because we know that it won't be used anytime soon". The bit
> > can be discarded as soon as we enter in a loop (instruction "loopentry")
> > or jump to somewhere else.
> This is indeed a different kind of `uncacheable' than I had in mind.
yes but it can probably be merged.

> > > Again, where should these M ongoing transactions come from?
> > "transactional memories" : several banks with pipelined access. This makes
> > M=P*B (banks*pipeline stages) possible ongoing transactions, PLUS the waiting
> > transaction requests that can wait in the FIFO.
> We're slowly drifting over to the Dcache, do we?
very slowly, then, because the Icache is not finished :-)
and since the Icache is less complex than the Dcache, we better
make it work before we discover too many problems with the Dcache.

> > > > we have several independent units that can emit orders.
> > > Not for the Icache.
> > why ? We have 8 fetcher lines, we can emit 1 read request per cycle
> > (as much as the instructions/cycle rate), plus the write requests from the
> > memory controller, so we have to prioritize the access.
> I can't see the picture, sorry.  How many instructions can we throw at
> the IF/ID unit per cycle?  A single cache line holds 8 instructions.
yes. so we could (in the best case : alignment is ok etc) emit 1 prefetch
instruction per cycle.

Plus, i haven't designed the fetcher's management completely, but lines
go by pairs, so we're fetching one while we're executing the other.
So, on a jump, we'll request two fetches : the target and the next line.
As soon as the target line is "consumed" (completely read) we'll fetch the
line after the next line : that's often called "double buffering".

> [...]
> > PS: is is my mail server, or Michael's mail always arrive late ?
> > it seems to me that there is almost 1 day of lag.
> The DFN had some problems with one of its overseas connections...
> Maybe a cleaningwoman in NYC pulled the wrong plug ;)
heck, sabotage ! :-)


As for the masks, i see your point. it wasn't clear though
about what was on each bit. i'll try to restate it differently :
('j' is the line number, T is the tag, A is the address, M is the mask)

V(i) <= (M(0) AND (A(0) XNOR T(i,0)))
    and (M(1) AND (A(1) XNOR T(i,1)))
    and (M(2) AND (A(2) XNOR T(i,2)))
    and (M(3) AND (A(3) XNOR T(i,3)))
    and (M(4) AND (A(4) XNOR T(i,4)))
    ..... -- "loop-generate" or a vector operation would be better here

but i prefer to work on it later, because (as noted before)
the LRU queue can only be updated once in a cycle :-)
the mask will not yet be used for the cache freeze, for example.

ok, now, let's code (at last) :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "Whenever I hear the word `cleaningwoman' I go berzerk" -- Steve Martin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Oct 7 18:43:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00375 for ; Sun, 8 Oct 2000 18:47:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:03 +0200 (MEST) Received: (qmail 31841 invoked by uid 0); 7 Oct 2000 19:16:44 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 7 Oct 2000 19:16:44 -0000 X-eGroups-Return: sentto-1101623-1101-970946197-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 07 Oct 2000 19:16:43 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 19:16:37 -0000 Received: (qmail 27183 invoked from network); 7 Oct 2000 19:16:36 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 7 Oct 2000 19:16:36 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.77) by mta2 with SMTP; 7 Oct 2000 19:16:24 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00803; Sat, 7 Oct 2000 18:43:12 +0200 Message-ID: <20001007184312.31473@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DE84ED.7039B3D8@f-cpu.org>; from Yann Guidon on Sat, Oct 07, 2000 at 03:05:33AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 7 Oct 2000 18:43:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd9d078a6acf07c17bff7f5cd92bfb2f Status: R X-Status: N On Sat, Oct 07, 2000 at 03:05:33AM +0100, Yann Guidon wrote:

> So, in order to have a good idea of the behaviour, the least
> we can do is run SpecInt or something like that ;-)

Since I'm quite familiar with benchmarks and have already worked with
this one, let me give you some numbers...

On state-of-the-art hardware, the integer part of SPEC CPU2000 takes
several hours.  The reference machine, a 300 MHz SPARC iirc, needs almost
2 days for a full run (including SPECfp). Running SPECint2000 on an
emulator would probably take some days; on a cycle-accurate simulator,
be prepared to wait weeks or even months.  Not to mention the hardware
requirements: you won't get away with less than 256 MBytes of RAM (for
SPECint alone; the emulator will need additional storage, of course).

[...]
> > > > That's correct.  But I really do not expect that we will have NBLINES
> > > > fetch operations running at the same time.  Where should they come from?
> > > no, we won't and shouldn't have that much access but, in average with a simple
> > > FC0 with 2 SDRAM banks (8 lines) we can have probably 10 read requests at the same
> > > time. if we have a 2KB Icache, we'll have up to 4 fetch requests and that uses
> > > 4 of the 64 lines, we waste 6% of the available space.
> > I could live with that.
> not me :-) i want ALL the lines to contain useful informations.

I always thought *I* were a perfectionist ;)

[...]
> > If a page of code (as opposed to data) is uncacheable, there's something
> > wrong.
> have you looked at your BIOS settings ?
> have you checked : "Video ROM cachable" ? "BIOS ROM cachable" ?
> i would consider it as too optimistic to consider all instructions as cachable.

That's an administrative decision.  You can still cache the BIOS ROM
(unless the chipset is buggy), it just doesn't make sense.

> in the current platforms, it's the HW that decides what is cachable or not.
> ie, if you execute code that is located on a PCI board, chances are that
> it's not cachable because it's an I/O.

Why do intel processors (and also some clones) have MTR registers, then?

[...]
> > This is indeed a different kind of `uncacheable' than I had in mind.
> yes but it can probably be merged.

I hope so.

[...]
> > I can't see the picture, sorry.  How many instructions can we throw at
> > the IF/ID unit per cycle?  A single cache line holds 8 instructions.
> yes. so we could (in the best case : alignment is ok etc) emit 1 prefetch
> instruction per cycle.
>
> Plus, i haven't designed the fetcher's management completely, but lines
> go by pairs, so we're fetching one while we're executing the other.
> So, on a jump, we'll request two fetches : the target and the next line.
> As soon as the target line is "consumed" (completely read) we'll fetch the
> line after the next line : that's often called "double buffering".

Hmm.  We really need an emulator for some experiments.  We have to find
out how much we can prefetch without doing any harm, how long an average
basic block is (or, how frequently we have to branch), whether it's good
to prefetch branches speculatively or not (and when), and so on.

> > [...]
> > > PS: is is my mail server, or Michael's mail always arrive late ?
> > > it seems to me that there is almost 1 day of lag.
> > The DFN had some problems with one of its overseas connections...
> > Maybe a cleaningwoman in NYC pulled the wrong plug ;)
> heck, sabotage ! :-)

Shit happens. ;)

> As for the masks, i see your point. it wasn't clear though
> about what was on each bit. i'll try to restate it differently :
> ('j' is the line number, T is the tag, A is the address, M is the mask)
>
> V(i) <= (M(0) AND (A(0) XNOR T(i,0)))
>     and (M(1) AND (A(1) XNOR T(i,1)))
>     and (M(2) AND (A(2) XNOR T(i,2)))
>     and (M(3) AND (A(3) XNOR T(i,3)))
>     and (M(4) AND (A(4) XNOR T(i,4)))
>     ..... -- "loop-generate" or a vector operation would be better here

Of course you can go both ways:

      (addr xor tag(i)) and mask = (others => '0')

is equivalent to

      (addr xnor tag(i)) or (not mask) = (others => '1')

This shouldn't worry us much; I suppose that synthesis tools will
perform DeMorgan transforms when necessary.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Sat Oct 7 17:04:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00378 for ; Sun, 8 Oct 2000 18:47:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:04 +0200 (MEST) Received: (qmail 23699 invoked by uid 0); 7 Oct 2000 19:16:49 -0000 Received: from mk.egroups.com (208.50.144.76) by mx11.rz2.gmx.net with SMTP; 7 Oct 2000 19:16:49 -0000 X-eGroups-Return: sentto-1101623-1102-970946201-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 07 Oct 2000 19:16:47 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 19:16:41 -0000 Received: (qmail 8132 invoked from network); 7 Oct 2000 19:16:40 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 7 Oct 2000 19:16:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.77) by mta2 with SMTP; 7 Oct 2000 19:16:38 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00434; Sat, 7 Oct 2000 17:04:27 +0200 Message-ID: <20001007170427.27252@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DE7396.57A951D6@f-cpu.org>; from Yann Guidon on Sat, Oct 07, 2000 at 01:51:34AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 7 Oct 2000 17:04:27 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] yet some other merged replies (cache+misc.+erin) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a21790c3fd454a40874d9af9efc092b0 Status: R X-Status: N On Sat, Oct 07, 2000 at 01:51:34AM +0100, Yann Guidon wrote:

> > To get `exact' numbers for the F-CPU (especially the I-cache), we will
> > have to emulate it.  Is there an emulator for the current ISA?  I didn't
> > find any links in the mailing list archive.
>
> unfortunately there is no emulator. yet. if Simili is solid enough,
> it will become this emulator, when running the simulations.

I really meant an emulator, not a cycle-accurate simulator.
An emulator could obtain memory usage patterns much faster.

[...]
> Michael Riepe wrote:
> > On Fri, Oct 06, 2000 at 12:33:49PM -0500, Richard E.Hartney wrote:
> > > I see absolutely no need for the SIMD requirement as you are not trying
> > > to capture code from 8,16,32 bit processor families as are AMD/INTEL.
> > >  MOTOROLA did the same thing when they introduced the 68020.  To capture
> > > 6800, 68000, and 68010 data forms
> 6800 ???

I didn't write that, but I remember that little beast, too.

> > Au contraire.  SIMD is useful for a lot of things.  Audio/video/image
> > processing, for example, or fast encryption/decryption.
> SIMD is also one secure way to extend the computing performance at almost no
> software cost. the F-CPU as it is now is defined to be as extensible as possible
> and wide SIMD registers is an easy way to boost algebaic or repetitive parallel
> algoritms, such as noted before. this is not an "extension" as in other CPUs,
> the SIMD factor is part of the F-CPU development and ISA. we don't try to capture
> anything, except speed :-)

Apropos speed.  I looked at the Rijndael docs some days ago (you
know, the new AES algorithm that is going to replace DES).  They use
some instructions that we could implement easily, e.g. the `xtimes'
instruction that shifts a byte left by one bit and inverts some of the
result bits if the msb was 1 before the shift.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From fckja@centrum.cz Sun Oct 8 01:08:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00405 for ; Sun, 8 Oct 2000 18:47:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:10 +0200 (MEST) Received: (qmail 13756 invoked by uid 0); 7 Oct 2000 23:09:01 -0000 Received: from jj.egroups.com (208.50.144.82) by mx19.rz2.gmx.net with SMTP; 7 Oct 2000 23:09:01 -0000 X-eGroups-Return: sentto-1101623-1103-970960130-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 07 Oct 2000 23:08:47 -0000 X-Sender: fckja@centrum.cz X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 23:08:50 -0000 Received: (qmail 5073 invoked from network); 7 Oct 2000 23:08:49 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 7 Oct 2000 23:08:49 -0000 Received: from unknown (HELO WIZWEB.wiz-net.co.kr) (211.44.228.171) by mta3 with SMTP; 7 Oct 2000 23:08:49 -0000 Received: from inet.com.ua ([63.25.69.126]) by WIZWEB.wiz-net.co.kr with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Sun, 8 Oct 2000 08:09:01 +0900 Message-ID: <00003c5e7532$00007f5e$0000436b@maktoob.com> To: X-Priority: 3 X-MSMail-Priority: Normal Errors-To: Adde_Bad1@yahoo.com X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-OriginalArrivalTime: 07 Oct 2000 23:09:03.0937 (UTC) FILETIME=[95F2CB10:01C030B3] From: fckja@centrum.cz MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Oct 2000 19:08:51 -0400 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Start Making What Your Worth! 17259 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-UIDL: c25967cf2661604aa4f969ccc276514f Status: R X-Status: N Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future? If you're determined to retire in the next 2 - 5 years with enough income to have REAL Financial Independence and Freedom, and are not afraid to work for it, I can help you. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! 1-800-533-9350 (Free, 24 hour, 2 minute recorded message) DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" - Walt Disney To be removed from future mailings, send an email to: Thanks_No5@yahoo.com and type "Remove" in the subject line. Tired of the 40 X 40 X 40 Plan? You know: Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! Is working for a "boss" too demeaning and unrewarding? -------------------------- eGroups Sponsor -------------------------~-~> Dial 1-800-555-TELL -- You Won't Believe Your Ears! For more details, click here: http://click.egroups.com/1/9537/15/_/3462/_/970960130/ ---------------------------------------------------------------------_-> From jeff@llandre.freeserve.co.uk Sun Oct 8 02:16:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00408 for ; Sun, 8 Oct 2000 18:47:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:10 +0200 (MEST) Received: (qmail 4636 invoked by uid 0); 7 Oct 2000 23:16:49 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net with SMTP; 7 Oct 2000 23:16:49 -0000 X-eGroups-Return: sentto-1101623-1104-970960607-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 07 Oct 2000 23:16:48 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 23:16:47 -0000 Received: (qmail 9095 invoked from network); 7 Oct 2000 23:16:47 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 7 Oct 2000 23:16:47 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta3 with SMTP; 7 Oct 2000 23:16:47 -0000 Received: from modem-37.neodymium.dialup.pol.co.uk ([62.136.49.165] helo=62.136.49.165) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13i3Ct-0002gA-00 for f-cpu@egroups.com; Sun, 08 Oct 2000 00:16:45 +0100 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 0:16 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] fpga idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ca4ede14b29bf680c8a3451a5dccd7d9 Status: R X-Status: N Jecel - how about an FPGA design where cells not in use
can be powered down (enabled by a bit). I know CMOS
doesnt use much
power when not switching, but still, a good idea.

This idea is freely given by me to the world BTW.
Jeff Davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
From Michael Riepe Sun Oct 8 01:50:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00414 for ; Sun, 8 Oct 2000 18:47:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:12 +0200 (MEST) Received: (qmail 12339 invoked by uid 0); 7 Oct 2000 23:52:52 -0000 Received: from ch.egroups.com (208.50.99.226) by mx19.rz2.gmx.net with SMTP; 7 Oct 2000 23:52:52 -0000 X-eGroups-Return: sentto-1101623-1105-970962761-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 07 Oct 2000 23:52:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 7 Oct 2000 23:52:40 -0000 Received: (qmail 23312 invoked from network); 7 Oct 2000 23:52:40 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 7 Oct 2000 23:52:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.88) by mta1 with SMTP; 7 Oct 2000 23:52:09 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00362; Sun, 8 Oct 2000 01:50:58 +0200 Message-ID: <20001008015058.08497@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 01:50:58 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" X-UIDL: f9170e29a14cd53b86a7c1ad18b09759 Status: R X-Status: N --ZPt4rx8FFjLCG7dd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Ok, here's something to play with.  I got the 8x8 multiplier running.
It's only partially tested yet; an exhaustive test (with 2^32 possible
input patterns) would take 3 months on my Pentium/MMX.  I verified that
the basic function (multiplication only, i.e. X = 0) works in both signed
and unsigned mode; I'm currently trying small values of X (-128 to 127 for
signed mode, 0 to 255 for unsigned mode).

The circuit is still combinatorial because that is easier to check.
I did indicate the separate stages, though.  If we manage to add 13 bits
in a single cycle, we should have a 4-stage 8-bit multiplier; otherwise,
it will use 5 stages.  I have an alternative version under development
that should be even faster (3 cycles, maybe).

Have fun,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Description: 8-bit multiplier Content-Disposition: attachment; filename="imul3.vhdl" -- imul3.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: imul3.vhdl,v 1.1 2000/10/07 23:40:07 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- -- the 9x9(8x8)-bit multiplier -- entity Mul9x9 is port ( -- inputs (will be changed to 8-bit later) A, B : in std_ulogic_vector(8 downto 0); -- optional double-width `add' input X : in std_ulogic_vector(15 downto 0) := (others => '0'); -- double-width output Y : out std_ulogic_vector(15 downto 0) ); end Mul9x9; architecture Arch_1 of Mul9x9 is -- -- multiplexer function (called in stage 2) -- function bmux ( A : in std_ulogic_vector(3 downto 0); B : in std_ulogic_vector(8 downto 0); B3 : in std_ulogic_vector(10 downto 0)) return std_ulogic_vector is variable res : std_ulogic_vector(10 downto 0); variable sel : std_ulogic_vector(2 downto 0); begin -- NOTE: calculation of `sel' can be put in first stage if necessary sel := A(2 downto 0) xor (2 downto 0 => A(3)); case sel is when "000" => res := (others => '0'); when "001" | "010" => res := (others => B(B'left)); res(B'range) := B; when "011" | "100" => res := (0 => '0', others => B(B'left)); res(B'left+1 downto B'right+1) := B; when "101" | "110" => res := (others => B3(B3'left)); res(B3'range) := B3; when "111" => res := (0 | 1 => '0', others => B(B'left)); res(B'left+2 downto B'right+2) := B; when others => res := (others => 'X'); end case; if (A(3) = '1') then -- subtract res := not res; end if; return res; end bmux; -- -- stage 1 : setup -- signal a1 : std_ulogic_vector(8 downto 0); signal b1 : std_ulogic_vector(8 downto 0); signal b1_3 : std_ulogic_vector(10 downto 0); signal y1, z1 : std_ulogic_vector(16 downto 0); -- -- stage 2 : muxes -- signal b2a, b2b, b2c : std_ulogic_vector(10 downto 0); signal y2, z2 : std_ulogic_vector(16 downto 0); -- -- stage 3 : carry-save adders -- signal y3, z3 : std_ulogic_vector(16 downto 0); -- -- stage 4 : final adder (drives Y) -- begin -- -- setup stage -- stage1 : process (A, B, X) begin -- pass `A' and `B' through -- will handle signed/unsigned mode switching here (later) a1 <= A; b1 <= B; -- precalculate `3*B' b1_3 <= std_ulogic_vector( to_signed(3 * to_integer(signed(B)), b1_3'length)); -- optional input for multiply-and-add y1 <= "0" & X; -- `magic' correction value for subtractions z1 <= (6 => A(8), 3 => A(5), 0 => A(2), others => '0'); end process; -- -- input mux stage -- stage2 : process (a1, b1, b1_3, y1, z1) begin -- input multiplexers b2a <= bmux(a1(2 downto 0) & '0', b1, b1_3); b2b <= bmux(a1(5 downto 2), b1, b1_3); b2c <= bmux(a1(8 downto 5), b1, b1_3); -- pass `y1' and `z1' through y2 <= y1; z2 <= z1; end process; -- -- adder farm stage -- stage3 : process (b2a, b2b, b2c, y2, z2) -- sum outputs variable s1, s2, s3 : std_ulogic_vector(16 downto 0); -- carry outputs variable c1, c2, c3 : std_ulogic_vector(16 downto 0); -- temporary summand variable t : std_ulogic_vector(16 downto 0); begin -- adder row #1 t := (others => b2a(b2a'left)); t(b2a'range) := b2a; s1 := y2 xor z2 xor t; c1 := (y2 and z2) or (y2 and t) or (z2 and t); c1 := c1(c1'left-1 downto 0) & "0"; -- wired 1-bit left shift -- adder row #2 t := (others => b2b(b2b'left)); t(b2b'range) := b2b; t := t(t'left-3 downto 0) & "000"; -- wired 3-bit left shift s2 := s1 xor c1 xor t; c2 := (s1 and c1) or (s1 and t) or (c1 and t); c2 := c2(c2'left-1 downto 0) & "0"; -- wired 1-bit left shift -- adder row #3 t := (others => b2c(b2c'left)); t(b2c'range) := b2c; t := t(t'left-6 downto 0) & "000000"; -- wired 6-bit left shift s3 := s2 xor c2 xor t; c3 := (s2 and c2) or (s2 and t) or (c2 and t); c3 := c3(c3'left-1 downto 0) & "0"; -- wired 1-bit left shift -- output drivers y3 <= s3; z3 <= c3; end process; -- -- output adder stage -- stage4 : process (y3, z3) -- temporary result variable t : unsigned(16 downto 0); begin -- high-bit adder t := unsigned(y3) + unsigned(z3); -- output driver Y <= std_ulogic_vector(t(Y'range)); end process; end Arch_1; -- vi: set ts=4 sw=4 : please --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Description: 8-bit multiplier testbench Content-Disposition: attachment; filename="t-imul.vhdl" -- t-imul.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: t-imul.vhdl,v 1.1 2000/10/07 23:40:07 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use std.textio.all; use IEEE.std_logic_textio.all; entity mul9x9_test is end mul9x9_test; architecture Arch_1 of mul9x9_test is signal A, B : std_ulogic_vector(8 downto 0); signal X, Y : std_ulogic_vector(15 downto 0); begin mut: entity work.Mul9x9 port map (A => A, B => B, X => X, Y => Y); process variable i, j, k, prod, res : integer; variable lout : line; begin write(lout, "*******************************************"); writeline(output, lout); write(lout, "Multiplier Testbench (C) 2000 Michael Riepe"); writeline(output, lout); write(lout, "*******************************************"); writeline(output, lout); write(lout, "Expect this to run for quite some time..."); writeline(output, lout); write(lout, "Get some coffee now, or go dating your SO."); writeline(output, lout); writeline(output, lout); write(lout, "*** Testing 8-bit signed multiplication"); writeline(output, lout); for i in -128 to 127 loop A <= std_ulogic_vector(to_signed(i, A'length)); for j in -128 to 127 loop B <= std_ulogic_vector(to_signed(j, B'length)); for k in -128 to 127 loop X <= std_ulogic_vector(to_signed(k, X'length)); wait for 1 ns; res := to_integer(signed(Y)); prod := i * j + k; if (res /= prod) then write(lout, "WHOA THERE!!! "); write(lout, i); write(lout, " * "); write(lout, j); write(lout, " + "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, prod); write(lout, " d = "); write(lout, res - prod); writeline(output, lout); end if; end loop; end loop; end loop; write(lout, "*** Testing 8-bit unsigned multiplication"); writeline(output, lout); for i in 0 to 255 loop A <= std_ulogic_vector(to_unsigned(i, A'length)); for j in 0 to 255 loop B <= std_ulogic_vector(to_unsigned(j, B'length)); for k in 0 to 255 loop X <= std_ulogic_vector(to_unsigned(k, X'length)); wait for 1 ns; res := to_integer(unsigned(Y)); prod := i * j + k; if (res /= prod) then write(lout, "WHOA THERE!!! "); write(lout, i); write(lout, " * "); write(lout, j); write(lout, " + "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, prod); write(lout, " d = "); write(lout, res - prod); writeline(output, lout); end if; end loop; end loop; end loop; wait; end process; end Arch_1; --ZPt4rx8FFjLCG7dd-- From berkane Sun Oct 8 02:07:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00417 for ; Sun, 8 Oct 2000 18:47:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:14 +0200 (MEST) Received: (qmail 9940 invoked by uid 0); 8 Oct 2000 00:05:17 -0000 Received: from c9.egroups.com (208.50.99.230) by mx06.rz2.gmx.net with SMTP; 8 Oct 2000 00:05:17 -0000 X-eGroups-Return: sentto-1101623-1106-970963512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by c9.egroups.com with NNFMP; 08 Oct 2000 00:05:15 -0000 X-Sender: aberkane@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 00:05:12 -0000 Received: (qmail 662 invoked from network); 8 Oct 2000 00:05:12 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 8 Oct 2000 00:05:12 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.40.39) by mta3 with SMTP; 8 Oct 2000 00:05:10 -0000 Received: from april.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e9807JU13952 for ; Sun, 8 Oct 2000 02:07:20 +0200 Sender: root@localhost.localdomain Message-ID: <39DFBAB7.1ECB805E@april.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 02:07:19 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b864ed6d4595bede9b70f3f04e188e59 Status: R X-Status: N Michael Riepe a =E9crit :
>
> Ok, here's something to play with.  I got the 8x8 multiplier runn= ing.
> It's only partially tested yet; an exhaustive test (with 2^32 possible=
> input patterns) would take 3 months on my Pentium/MMX.  I verifie= d that
> the basic function (multiplication only, i.e. X =3D 0) works in both s= igned
> and unsigned mode; I'm currently trying small values of X (-128 to 127= for
> signed mode, 0 to 255 for unsigned mode).
>
> The circuit is still combinatorial because that is easier to check. > I did indicate the separate stages, though.  If we manage to add = 13 bits
> in a single cycle, we should have a 4-stage 8-bit multiplier; otherwis= e,
> it will use 5 stages.  I have an alternative version under develo= pment
> that should be even faster (3 cycles, maybe).
>
> Have fun,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>   ----------------------------------------------------------= --------------
>            = ;         Name: imul3.vhdl
>    imul3.vhdl       Type:= Plain Text (text/plain)
>            = ;  Description: 8-bit multiplier
>
>            = ;          Name: t-imul.vhdl >    t-imul.vhdl       Type= : Plain Text (text/plain)
>            = ;   Description: 8-bit multiplier testbench

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
eGroups Sponsor=
3D""
From Michael Riepe Sun Oct 8 02:13:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00420 for ; Sun, 8 Oct 2000 18:47:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:15 +0200 (MEST) Received: (qmail 9984 invoked by uid 0); 8 Oct 2000 00:13:47 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 8 Oct 2000 00:13:47 -0000 X-eGroups-Return: sentto-1101623-1107-970964021-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 08 Oct 2000 00:13:44 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 00:13:41 -0000 Received: (qmail 25814 invoked from network); 8 Oct 2000 00:13:40 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 8 Oct 2000 00:13:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.88) by mta1 with SMTP; 8 Oct 2000 00:13:34 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00502; Sun, 8 Oct 2000 02:13:10 +0200 Message-ID: <20001008021310.44182@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from jeff@llandre.freeserve.co.uk on Sun, Oct 08, 2000 at 12:16:00AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 02:13:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fpga idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8a7a4acebde43527b0f25d8997311067 Status: R X-Status: N On Sun, Oct 08, 2000 at 12:16:00AM +0000, jeff@llandre.freeserve.co.uk wrote:
> Jecel - how about an FPGA design where cells not in use
> can be powered down (enabled by a bit). I know CMOS
> doesnt use much
> power when not switching, but still, a good idea.

Turning off the clock for those cells should be enough, IMHO.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From berkane Sun Oct 8 04:34:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00426 for ; Sun, 8 Oct 2000 18:47:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:17 +0200 (MEST) Received: (qmail 14128 invoked by uid 0); 8 Oct 2000 02:32:24 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 8 Oct 2000 02:32:24 -0000 X-eGroups-Return: sentto-1101623-1108-970972342-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 08 Oct 2000 02:32:22 -0000 X-Sender: aberkane@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 02:32:22 -0000 Received: (qmail 29097 invoked from network); 8 Oct 2000 02:32:22 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 8 Oct 2000 02:32:22 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.50.131) by mta2 with SMTP; 8 Oct 2000 02:32:20 -0000 Received: from april.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e982YSf06016 for ; Sun, 8 Oct 2000 04:34:29 +0200 Sender: root@localhost.localdomain Message-ID: <39DFDD34.37137864@april.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> <39DFBAB7.1ECB805E@april.org> From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 04:34:28 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5edb0f7ffff4a0d322437bb9e4bb6ca7 Status: R X-Status: N berkane a =E9crit :
>
> Michael Riepe a =E9crit :
> >
> > Ok, here's something to play with.  I got the 8x8 multiplier= running.
> > It's only partially tested yet; an exhaustive test (with 2^32 pos= sible
> > input patterns) would take 3 months on my Pentium/MMX.  I ve= rified that
> > the basic function (multiplication only, i.e. X =3D 0) works in b= oth signed
> > and unsigned mode; I'm currently trying small values of X (-128 t= o 127 for
> > signed mode, 0 to 255 for unsigned mode).
> >
> > The circuit is still combinatorial because that is easier to chec= k.
> > I did indicate the separate stages, though.  If we manage to= add 13 bits
> > in a single cycle, we should have a 4-stage 8-bit multiplier; oth= erwise,
> > it will use 5 stages.  I have an alternative version under d= evelopment
> > that should be even faster (3 cycles, maybe).
> >
> > Have fun,
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> >
> >
> >   -----------------------------------------------------= -------------------
> >           =           Name: imul3.vhdl
> >    imul3.vhdl       = Type: Plain Text (text/plain)
> >           =    Description: 8-bit multiplier
> >
> >           =            Name: t-imul.v= hdl
> >    t-imul.vhdl      = Type: Plain Text (text/plain)
> >           =     Description: 8-bit multiplier testbench
>
> --
> ---asdean@infolibre.org---
> Member of infolibre.org
> ---http://www.infolibre.org >
bye
--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From berkane Sun Oct 8 04:34:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00429 for ; Sun, 8 Oct 2000 18:47:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:18 +0200 (MEST) Received: (qmail 11126 invoked by uid 0); 8 Oct 2000 02:32:53 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 8 Oct 2000 02:32:53 -0000 X-eGroups-Return: sentto-1101623-1109-970972369-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ei.egroups.com with NNFMP; 08 Oct 2000 02:32:54 -0000 X-Sender: aberkane@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 02:32:49 -0000 Received: (qmail 24134 invoked from network); 8 Oct 2000 02:32:49 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 8 Oct 2000 02:32:49 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.50.131) by mta2 with SMTP; 8 Oct 2000 02:32:47 -0000 Received: from april.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.10.1/8.8.7) with ESMTP id e982Yuf06022 for ; Sun, 8 Oct 2000 04:34:56 +0200 Sender: root@localhost.localdomain Message-ID: <39DFDD50.30FD444D@april.org> Organization: scoop-infolibre X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20001008021310.44182@thrai.stud.uni-hannover.de> From: berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 04:34:56 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fpga idea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2e4b3efb9eca3a13cae7c0380663eb01 Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Sun, Oct 08, 2000 at 12:16:00AM +0000, jeff@llandre.freeserve.co.uk= wrote:
> > Jecel - how about an FPGA design where cells not in use
> > can be powered down (enabled by a bit). I know CMOS
> > doesnt use much
> > power when not switching, but still, a good idea.
>
> Turning off the clock for those cells should be enough, IMHO.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
i don't need your mail
--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
 From Rares Marian Sun Oct 8 09:30:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00435 for ; Sun, 8 Oct 2000 18:47:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 18:47:19 +0200 (MEST) Received: (qmail 13757 invoked by uid 0); 8 Oct 2000 07:28:16 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 8 Oct 2000 07:28:16 -0000 X-eGroups-Return: sentto-1101623-1110-970990093-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ml.egroups.com with NNFMP; 08 Oct 2000 07:28:15 -0000 X-Sender: rmarian@linuxstart.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 07:28:13 -0000 Received: (qmail 23462 invoked from network); 8 Oct 2000 07:28:12 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 8 Oct 2000 07:28:12 -0000 Received: from unknown (HELO tbird.iworld.com) (63.236.72.237) by mta2 with SMTP; 8 Oct 2000 07:28:12 -0000 Received: (from nobody@localhost) by tbird.iworld.com (8.10.2/8.10.2) id e987Uf710917; Sun, 8 Oct 2000 03:30:41 -0400 Message-Id: <200010080730.e987Uf710917@tbird.iworld.com> X-Authentication-Warning: tbird.iworld.com: nobody set sender to rmarian@linuxstart.com using -f X-Mailer: MIME-tools 4.103 (Entity 4.115) To: f-cpu@egroups.com From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 03:30:41 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d9202130946611f4594b90e4c828d748 Status: R X-Status: N Um 3 cycles is possible with Booth/Modified Booth algorithm.

Essentially it says 10x100 is easier to do than 40x25 or 48x59 = 50x60 - 50 - 2*59.

It's a trick that always got me through grade school tests faster than anybody else.

YG knows it better than I do.

>> > The circuit is still combinatorial because that is easier to check.
>> > I did indicate the separate stages, though.  If we manage to add 13 bits
>> > in a single cycle, we should have a 4-stage 8-bit multiplier; otherwise,
>> > it will use 5 stages.  I have an alternative version under development
>> > that should be even faster (3 cycles, maybe).
>> >
>> > Have fun,
>> > --
>> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>> >  "All I wanna do is have a little fun before I die"

Rares


Thanks to Free Unices, we've crawled back UP to 70's.
----------------------
Do you do Linux? :)
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com
eGroups Sponsor
From Yann Guidon Sun Oct 8 20:39:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00813 for ; Sun, 8 Oct 2000 22:16:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 22:16:59 +0200 (MEST) Received: (qmail 29431 invoked by uid 0); 8 Oct 2000 17:34:50 -0000 Received: from mk.egroups.com (208.50.144.76) by mx11.rz2.gmx.net with SMTP; 8 Oct 2000 17:34:50 -0000 X-eGroups-Return: sentto-1101623-1111-971026486-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 08 Oct 2000 17:34:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 17:34:45 -0000 Received: (qmail 29451 invoked from network); 8 Oct 2000 17:34:45 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 8 Oct 2000 17:34:45 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 8 Oct 2000 17:34:44 -0000 Received: from f-cpu.org (nas4-71.ras.club-internet.fr [195.36.203.71]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA21771 for ; Sun, 8 Oct 2000 19:34:40 +0200 (MET DST) Message-ID: <39E0BF4B.EEE26402@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 19:39:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 82cd9f0c805b16a54a343675322ddbb9 Status: R X-Status: N hi again,

Michael Riepe wrote:
> On Sat, Oct 07, 2000 at 03:05:33AM +0100, Yann Guidon wrote:
> > So, in order to have a good idea of the behaviour, the least
> > we can do is run SpecInt or something like that ;-)
> Since I'm quite familiar with benchmarks and have already worked with
> this one, let me give you some numbers...
>
> On state-of-the-art hardware, the integer part of SPEC CPU2000 takes
> several hours.  The reference machine, a 300 MHz SPARC iirc, needs almost
> 2 days for a full run (including SPECfp). Running SPECint2000 on an
> emulator would probably take some days; on a cycle-accurate simulator,
> be prepared to wait weeks or even months.  Not to mention the hardware
> requirements: you won't get away with less than 256 MBytes of RAM (for
> SPECint alone; the emulator will need additional storage, of course).

so, ok to say that it is slow. now, i believe that a "normal" workload
with various software will do the trick. P&H use Spice and GCC,
let's add MP3 decompression and JPEG encoding, some heavy linear algebra
and Lyx/Latex-like stuffs. Other heavily used things are DECT/GSM algos
(with all the synchros and match searches) and IP routing algos.

> [...]
> > > > > we waste 6% of the available space.
> > > I could live with that.
> > not me :-) i want ALL the lines to contain useful informations.
> I always thought *I* were a perfectionist ;)
we simply have different criteria.

> [...]
> > > If a page of code (as opposed to data) is uncacheable, there's something
> > > wrong.
> > have you looked at your BIOS settings ?
> > have you checked : "Video ROM cachable" ? "BIOS ROM cachable" ?
> > i would consider it as too optimistic to consider all instructions as cachable.
> That's an administrative decision.  You can still cache the BIOS ROM
> (unless the chipset is buggy), it just doesn't make sense.
it can make a difference if we go down to obscure decisions. my postulat here
is that data can be cachable or not, and instructions are data.

> > in the current platforms, it's the HW that decides what is cachable or not.
> > ie, if you execute code that is located on a PCI board, chances are that
> > it's not cachable because it's an I/O.
> Why do intel processors (and also some clones) have MTR registers, then?
MTRRs essentially give you the possibility to selectively change the cache
policy of memory regions. Some algorithms behave better when using
write-through, others not. write combining can be better for some software,
when non-cachable is necessary for semaphores (for example).
But a careful read at the Intel docs will give you the priority strategy :
Hardware often matters most.

> [...]
> > > This is indeed a different kind of `uncacheable' than I had in mind.
> > yes but it can probably be merged.
> I hope so.
so let's not bother ;-)

> [...]
> > Plus, i haven't designed the fetcher's management completely, but lines
> > go by pairs, so we're fetching one while we're executing the other.
> > So, on a jump, we'll request two fetches : the target and the next line.
> > As soon as the target line is "consumed" (completely read) we'll fetch the
> > line after the next line : that's often called "double buffering".
>
> Hmm.  We really need an emulator for some experiments.  We have to find
> out how much we can prefetch without doing any harm, how long an average
> basic block is (or, how frequently we have to branch), whether it's good
> to prefetch branches speculatively or not (and when), and so on.
we will :-)

Michael Abrash says : "always measure your code" ;-)

> > > [...]
> > As for the masks, i see your point. it wasn't clear though
> > about what was on each bit. i'll try to restate it differently :
> > ('j' is the line number, T is the tag, A is the address, M is the mask)
> >
> > V(i) <= (M(0) AND (A(0) XNOR T(i,0)))
> >     and (M(1) AND (A(1) XNOR T(i,1)))
> >     and (M(2) AND (A(2) XNOR T(i,2)))
> >     and (M(3) AND (A(3) XNOR T(i,3)))
> >     and (M(4) AND (A(4) XNOR T(i,4)))
> >     ..... -- "loop-generate" or a vector operation would be better here
>
> Of course you can go both ways:
>
>         (addr xor tag(i)) and mask = (others => '0')
>
> is equivalent to
>
>         (addr xnor tag(i)) or (not mask) = (others => '1')
mmm the declaration as bits or bit_vectors was missing, before.

> This shouldn't worry us much; I suppose that synthesis tools will
> perform DeMorgan transforms when necessary.
let's hope so, and that's the least they can do,
since they're usually so fucking expensive ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sun Oct 8 20:39:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00816 for ; Sun, 8 Oct 2000 22:17:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 22:17:00 +0200 (MEST) Received: (qmail 18425 invoked by uid 0); 8 Oct 2000 17:34:57 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 8 Oct 2000 17:34:57 -0000 X-eGroups-Return: sentto-1101623-1112-971026490-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fj.egroups.com with NNFMP; 08 Oct 2000 17:34:55 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 17:34:50 -0000 Received: (qmail 5404 invoked from network); 8 Oct 2000 17:34:50 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 8 Oct 2000 17:34:50 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 8 Oct 2000 17:34:49 -0000 Received: from f-cpu.org (nas4-71.ras.club-internet.fr [195.36.203.71]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA13747 for ; Sun, 8 Oct 2000 19:34:45 +0200 (MET DST) Message-ID: <39E0BF4C.F5B3E6E0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 19:39:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: da9475b900c67377ac66e9aeb6e86b33 Status: R X-Status: N hi,

i'm back from a nice trip out of Paris :-)
and i find this nice piece of codein my inbox when i return !

Michael Riepe wrote:
> I have an alternative version under development
> that should be even faster (3 cycles, maybe).
cool :-) so we'll have something to play with :-)

i'll try to look closely at your code but
i still have to finish the Icache...

> Have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sun Oct 8 20:39:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00819 for ; Sun, 8 Oct 2000 22:17:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 22:17:01 +0200 (MEST) Received: (qmail 26935 invoked by uid 0); 8 Oct 2000 17:35:01 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 8 Oct 2000 17:35:01 -0000 X-eGroups-Return: sentto-1101623-1113-971026491-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mw.egroups.com with NNFMP; 08 Oct 2000 17:34:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 17:34:51 -0000 Received: (qmail 20862 invoked from network); 8 Oct 2000 17:34:51 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 8 Oct 2000 17:34:51 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 8 Oct 2000 17:34:50 -0000 Received: from f-cpu.org (nas4-71.ras.club-internet.fr [195.36.203.71]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA14422 for ; Sun, 8 Oct 2000 19:25:20 +0200 (MET DST) Message-ID: <39E0BF4F.CC57349B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001008021310.44182@thrai.stud.uni-hannover.de> <39DFDD50.30FD444D@april.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 19:39:11 +0100 Reply-To: f-cpu@egroups.com Subject: for berkane (was: Re: [f-cpu] fpga idea) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0a58e7a90dfaa111bed45ffda6f1bce2 Status: R X-Status: N berkane wrote:
> Michael Riepe a =E9crit :
<snip>
> i don't need your mail

Just in case you didn't read the email that i sent to you privately :

read the message header and you'll find
List-Unsubscribe: <mailto:f-cpu-unsubscribe@egroups.com>

this means that you can send a message to this address
to be unsubscribed. i thought you were more adult than that.
NOBODY CAN REMOVE YOU FROM THE LIST, so don't bother us,
but instead ask yourself what you can do. Spamming the list,
for example, is not a solution that works. It makes people
unhappy but it does nothing to the computers. Reading your
mails' headers, at contrary, can be very informative.
What is the point in knowing how to anonymously spam a list
if you don't even know how to read headers ??? or at least,
keep an archive of the subscription confirmation mail.

now, you have no excuse to be here, so :
bye (like you said, but for good))
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Sun Oct 8 21:21:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00822 for ; Sun, 8 Oct 2000 22:17:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 22:17:02 +0200 (MEST) Received: (qmail 7057 invoked by uid 0); 8 Oct 2000 18:17:33 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 8 Oct 2000 18:17:33 -0000 X-eGroups-Return: sentto-1101623-1114-971029041-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ho.egroups.com with NNFMP; 08 Oct 2000 18:17:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 18:17:20 -0000 Received: (qmail 31637 invoked from network); 8 Oct 2000 18:17:19 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 8 Oct 2000 18:17:19 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 8 Oct 2000 18:17:19 -0000 Received: from f-cpu.org (nas4-68.ras.club-internet.fr [195.36.203.68]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA11819 for ; Sun, 8 Oct 2000 20:17:10 +0200 (MET DST) Message-ID: <39E0C93F.9DA942F1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 20:21:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a56b814b3dca2cc41e2fa0a475b5058b Status: R X-Status: N Michael Riepe wrote:
> Ok, here's something to play with.  I got the 8x8 multiplier running.
> It's only partially tested yet; an exhaustive test (with 2^32 possible
> input patterns) would take 3 months on my Pentium/MMX.  I verified that
> the basic function (multiplication only, i.e. X = 0) works in both signed
> and unsigned mode; I'm currently trying small values of X (-128 to 127 for
> signed mode, 0 to 255 for unsigned mode).

i'm running the testbench at the moment, and it works correctly
(at least until 2000.000 us). i'm reading the source at the same time.
What i miss is a good schematic drawing :-)

> The circuit is still combinatorial because that is easier to check.
> I did indicate the separate stages, though.  If we manage to add 13 bits
> in a single cycle, we should have a 4-stage 8-bit multiplier; otherwise,
> it will use 5 stages.  I have an alternative version under development
> that should be even faster (3 cycles, maybe).
if you could document it, it would be interesting.

As for testing larger multipliers, one idea is to use the pipeline stages
to reduce the combinatorial explosion. If we split the unit, there are
less things to test, no ? Can you apply this to the stages of the
9*9 multipliers, so it is tested faster ?

> Have fun,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Nicolas Boulay Mon Oct 8 21:33:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00831 for ; Sun, 8 Oct 2000 22:17:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Oct 2000 22:17:03 +0200 (MEST) Received: (qmail 30644 invoked by uid 0); 8 Oct 2000 19:28:28 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 8 Oct 2000 19:28:28 -0000 X-eGroups-Return: sentto-1101623-1115-971033301-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 08 Oct 2000 19:28:22 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 19:28:21 -0000 Received: (qmail 2312 invoked from network); 8 Oct 2000 19:28:21 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 8 Oct 2000 19:28:21 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 8 Oct 2000 19:28:20 -0000 Received: from 195.36.162.158 [195.36.162.158] by lh00.opsion.fr; Sun, 8 Oct 2000 19:29:57 GMT Message-ID: <3BC1FF75.BE5AAA01@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Oct 2001 21:33:09 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] bench Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-UIDL: 1cb59d696b478b5110cbe7604a694486 Status: R X-Status: N Somebody knows about a useful test to run it on a simulator. I just see about Spec but some month to have the number is a little bit too much... nicO ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif -------------------------- eGroups Sponsor -------------------------~-~> Your family still won't know what you do. At least they'll know where. The resources, brainpower & breadth of opportunities at Microsoft are unmatched. The only question is are you ready for that kind of impact? http://click.egroups.com/1/9223/15/_/3462/_/971033302/ ---------------------------------------------------------------------_-> From jeff davies Sun Oct 8 22:22:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01434 for ; Mon, 9 Oct 2000 01:29:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:29:59 +0200 (MEST) Received: (qmail 8723 invoked by uid 0); 8 Oct 2000 20:22:51 -0000 Received: from hi.egroups.com (208.50.99.211) by mx12.rz2.gmx.net with SMTP; 8 Oct 2000 20:22:51 -0000 X-eGroups-Return: sentto-1101623-1116-971036543-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 08 Oct 2000 20:22:48 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 20:22:22 -0000 Received: (qmail 24958 invoked from network); 8 Oct 2000 20:22:22 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 8 Oct 2000 20:22:22 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta1 with SMTP; 8 Oct 2000 20:22:22 -0000 Received: from modem-177.barium.dialup.pol.co.uk ([62.136.47.177] helo=llandre.freeserve.co.uk) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13iMxf-0005IH-00 for f-cpu@egroups.com; Sun, 08 Oct 2000 21:22:20 +0100 Sender: root@pop.gmx.net Message-ID: <39E0D7A2.54162CC9@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 21:22:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40cce008278f3f9815290d3be8878d22 Status: R X-Status: N Yann Guidon wrote:

> hi again,
>
>
> > [...]
> > > > If a page of code (as opposed to data) is uncacheable, there's something
> > > > wrong.
> > > have you looked at your BIOS settings ?
> > > have you checked : "Video ROM cachable" ? "BIOS ROM cachable" ?
>

If you look at OpenBios, and other things like LART, it appears that BIOS
is unnecessary, instead OpenBios (find from www.gnu.org link) boots straight into
Linux.
None of the old awkward timing problems associated with the BIOS are inherited, and
therefore
the above is a non-issue.

> MTRRs essentially give you the possibility to selectively change the cache
> policy of memory regions. Some algorithms behave better when using
> write-through, others not. write combining can be better for some software,
> when non-cachable is necessary for semaphores (for example).
>

It is obvious that the ability to turn off cacheing for certain address
ranges is required (as stated - for I/O or semaphores) , althought the above bit about
algorithms is a new one
to me, but a very good point.

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jeff Davies
jeff@llandre.freeserve.co.uk

 From jeff davies Sun Oct 8 22:25:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01437 for ; Mon, 9 Oct 2000 01:30:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:00 +0200 (MEST) Received: (qmail 7992 invoked by uid 0); 8 Oct 2000 20:25:14 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 8 Oct 2000 20:25:14 -0000 X-eGroups-Return: sentto-1101623-1117-971036709-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 08 Oct 2000 20:25:10 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 20:25:08 -0000 Received: (qmail 31188 invoked from network); 8 Oct 2000 20:25:08 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 8 Oct 2000 20:25:08 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta2 with SMTP; 8 Oct 2000 20:25:08 -0000 Received: from modem-177.barium.dialup.pol.co.uk ([62.136.47.177] helo=llandre.freeserve.co.uk) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13iN0L-0005qe-00 for f-cpu@egroups.com; Sun, 08 Oct 2000 21:25:06 +0100 Sender: root@pop.gmx.net Message-ID: <39E0D849.79DCF15F@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> <39E0C93F.9DA942F1@f-cpu.org> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 21:25:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c4189fcee13671aed95b15a767df5aae Status: R X-Status: N Yann Guidon wrote:

> Michael Riepe wrote:
> > Ok, here's something to play with.  I got the 8x8 multiplier running.
> > It's only partially tested yet; an exhaustive test (with 2^32 possible
> > input patterns) would take 3 months on my Pentium/MMX.

A very good reason to put it into a fpga and test it??

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jeff Davies

 From Michael Riepe Sun Oct 8 23:42:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01475 for ; Mon, 9 Oct 2000 01:30:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:04 +0200 (MEST) Received: (qmail 13021 invoked by uid 0); 8 Oct 2000 21:43:37 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 8 Oct 2000 21:43:37 -0000 X-eGroups-Return: sentto-1101623-1118-971041407-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mk.egroups.com with NNFMP; 08 Oct 2000 21:43:36 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_0_3); 8 Oct 2000 21:43:27 -0000 Received: (qmail 19288 invoked from network); 8 Oct 2000 21:43:27 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 8 Oct 2000 21:43:27 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta1 with SMTP; 8 Oct 2000 21:43:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00335; Sun, 8 Oct 2000 23:42:06 +0200 Message-ID: <20001008234206.19116@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 23:42:06 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] multiplier take #2 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" X-UIDL: 1c7e1323a7a29b4af19debdee4fc5c87 Status: R X-Status: N --PEIAKu/WMn1b1Hv9 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi!

Here's my second implementation of the 8x8 multiplier.  It uses nine
1x9-bit booth multipliers and a five-level wallace tree in the first
two stages, the final (third) stage is a carry look-ahead adder as in
version #1.  It looks pretty good to me.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="imul5.vhdl" -- imul5.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: imul5.vhdl,v 1.1 2000/10/08 21:08:13 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- -- the 9x9(8x8)-bit multiplier -- entity Mul9x9 is port ( -- inputs (will be changed to 8-bit later) A : in std_ulogic_vector(8 downto 0); B : in std_ulogic_vector(8 downto 0); -- XXX: make width generic? -- optional double-width `add' input X : in std_ulogic_vector(15 downto 0) := (others => '0'); -- double-width output Y : out std_ulogic_vector(15 downto 0) ); end Mul9x9; architecture Arch_1 of Mul9x9 is type std_ulogic_matrix is array(natural range <>, natural range <>) of std_ulogic; signal s3 : std_ulogic_matrix(5 downto 0, 15 downto 0); signal s6 : std_ulogic_matrix(1 downto 0, 15 downto 0); begin stage1 : process (A, B, X) variable s1 : std_ulogic_matrix(10 downto 0, 15 downto 0); variable s2 : std_ulogic_matrix(7 downto 0, 15 downto 0); variable t : std_ulogic; begin -- -- prepare bit matrix -- Note: Booth's algorithm is hidden here :) -- XXX: reorder lines to save adders? -- s1 := (others => (others => '0')); t := '0'; for j in 0 to 8 loop for i in s1'high(2) downto j loop if i - j > B'left then s1(j, i) := (A(j) xor t) and (A(j) xor B(B'left)); else s1(j, i) := (A(j) xor t) and (A(j) xor B(i-j)); end if; end loop; s1(9, j) := A(j) and not t; t := A(j); end loop; for i in X'range loop s1(10, i) := X(i); end loop; -- -- first level of wallace tree -- s2 := (others => (others => '0')); for i in s2'range(2) loop s2(0, i) := s1(0, i) xor s1(1, i) xor s1(2, i); s2(1, i) := s1(3, i) xor s1(4, i) xor s1(5, i); s2(2, i) := s1(6, i) xor s1(7, i) xor s1(8, i); if i < s2'high(2) then s2(3, i+1) := (s1(0, i) and s1(1, i)) or (s1(0, i) and s1(2, i)) or (s1(1, i) and s1(2, i)); s2(4, i+1) := (s1(3, i) and s1(4, i)) or (s1(3, i) and s1(5, i)) or (s1(4, i) and s1(5, i)); s2(5, i+1) := (s1(6, i) and s1(7, i)) or (s1(6, i) and s1(8, i)) or (s1(7, i) and s1(8, i)); end if; s2(6, i) := s1(9, i); s2(7, i) := s1(10, i); end loop; -- -- second level of wallace tree -- s3 <= (others => (others => '0')); for i in s3'range(2) loop s3(0, i) <= s2(0, i) xor s2(1, i) xor s2(2, i); s3(1, i) <= s2(3, i) xor s2(4, i) xor s2(5, i); if i < s3'high(2) then s3(2, i+1) <= (s2(0, i) and s2(1, i)) or (s2(0, i) and s2(2, i)) or (s2(1, i) and s2(2, i)); s3(3, i+1) <= (s2(3, i) and s2(4, i)) or (s2(3, i) and s2(5, i)) or (s2(4, i) and s2(5, i)); end if; s3(4, i) <= s2(6, i); s3(5, i) <= s2(7, i); end loop; end process; stage2 : process (s3) variable s4 : std_ulogic_matrix(3 downto 0, 15 downto 0); variable s5 : std_ulogic_matrix(2 downto 0, 15 downto 0); begin -- -- third level of wallace tree -- s4 := (others => (others => '0')); for i in s4'range(2) loop s4(0, i) := s3(0, i) xor s3(1, i) xor s3(2, i); s4(1, i) := s3(3, i) xor s3(4, i) xor s3(5, i); if i < s4'high(2) then s4(2, i+1) := (s3(0, i) and s3(1, i)) or (s3(0, i) and s3(2, i)) or (s3(1, i) and s3(2, i)); s4(3, i+1) := (s3(3, i) and s3(4, i)) or (s3(3, i) and s3(5, i)) or (s3(4, i) and s3(5, i)); end if; end loop; -- -- fourth level of wallace tree -- s5 := (others => (others => '0')); for i in s5'range(2) loop s5(0, i) := s4(0, i) xor s4(1, i) xor s4(2, i); if i < s5'high(2) then s5(1, i+1) := (s4(0, i) and s4(1, i)) or (s4(0, i) and s4(2, i)) or (s4(1, i) and s4(2, i)); end if; s5(2, i) := s4(3, i); end loop; -- -- fifth level of wallace tree -- s6 <= (others => (others => '0')); for i in s6'range(2) loop s6(0, i) <= s5(0, i) xor s5(1, i) xor s5(2, i); if i < s6'high(2) then s6(1, i+1) <= (s5(0, i) and s5(1, i)) or (s5(0, i) and s5(2, i)) or (s5(1, i) and s5(2, i)); end if; end loop; end process; stage3 : process (s6) variable s7, s8 : std_ulogic_vector(15 downto 0); begin -- -- carry look-ahead adder -- s8(s8'low) := '0'; for i in s7'low to s7'high loop s7(i) := s6(0, i) xor s6(1, i); if i < s7'high then s8(i+1) := (s6(0, i) and s6(1, i)) or (s7(i) and s8(i)); end if; end loop; Y <= s7 xor s8; end process; end Arch_1; -- vi: set ts=4 sw=4 : please --PEIAKu/WMn1b1Hv9-- From Michael Riepe Sun Oct 8 23:49:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01481 for ; Mon, 9 Oct 2000 01:30:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:06 +0200 (MEST) Received: (qmail 5067 invoked by uid 0); 8 Oct 2000 21:49:56 -0000 Received: from hn.egroups.com (208.50.99.199) by mx12.rz2.gmx.net with SMTP; 8 Oct 2000 21:49:56 -0000 X-eGroups-Return: sentto-1101623-1119-971041792-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 08 Oct 2000 21:49:55 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 21:49:52 -0000 Received: (qmail 29564 invoked from network); 8 Oct 2000 21:49:52 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 8 Oct 2000 21:49:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta2 with SMTP; 8 Oct 2000 21:49:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00511; Sun, 8 Oct 2000 23:49:49 +0200 Message-ID: <20001008234949.23112@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001008021310.44182@thrai.stud.uni-hannover.de> <39DFDD50.30FD444D@april.org> X-Mailer: Mutt 0.84e In-Reply-To: <39DFDD50.30FD444D@april.org>; from berkane on Sun, Oct 08, 2000 at 04:34:56AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 23:49:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] fpga idea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3db27e1f13d59b6cd9577e3dbbefb1d3 Status: R X-Status: N On Sun, Oct 08, 2000 at 04:34:56AM +0200, berkane wrote:
> Michael Riepe a =E9crit :
[full quote deleted]
> i don't need your mail

Why don't you unsubscribe from this list, then?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D""
From Yann Guidon Mon Oct 9 00:54:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01484 for ; Mon, 9 Oct 2000 01:30:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:07 +0200 (MEST) Received: (qmail 12232 invoked by uid 0); 8 Oct 2000 21:50:32 -0000 Received: from hm.egroups.com (208.50.99.198) by mx11.rz2.gmx.net with SMTP; 8 Oct 2000 21:50:32 -0000 X-eGroups-Return: sentto-1101623-1120-971041827-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 08 Oct 2000 21:50:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 21:50:27 -0000 Received: (qmail 7480 invoked from network); 8 Oct 2000 21:50:27 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 8 Oct 2000 21:50:27 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 8 Oct 2000 21:50:26 -0000 Received: from f-cpu.org (nas3-75.aub.club-internet.fr [195.36.145.75]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA22864 for ; Sun, 8 Oct 2000 23:50:14 +0200 (MET DST) Message-ID: <39E0FB24.6BB249A2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001008234206.19116@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 23:54:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier take #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 57e444ecffbeb7aeb5d1f92f033e66cf Status: R X-Status: N Michael Riepe wrote:
> Hi!
>
> Here's my second implementation of the 8x8 multiplier.  It uses nine
> 1x9-bit booth multipliers and a five-level wallace tree in the first
> two stages, the final (third) stage is a carry look-ahead adder as in
> version #1.  It looks pretty good to me.

cool :-) i'll try to look at it closely.
the first bench is still running on my computer, but the first
half is ok. it's at time 18000us :-)

What is your plan for the next stages ?

> Ciao,
bene, bene :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Mon Oct 9 00:59:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01487 for ; Mon, 9 Oct 2000 01:30:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:07 +0200 (MEST) Received: (qmail 24034 invoked by uid 0); 8 Oct 2000 21:55:45 -0000 Received: from mu.egroups.com (208.50.99.218) by mx06.rz2.gmx.net with SMTP; 8 Oct 2000 21:55:45 -0000 X-eGroups-Return: sentto-1101623-1121-971042139-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 08 Oct 2000 21:55:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 21:55:39 -0000 Received: (qmail 16987 invoked from network); 8 Oct 2000 21:55:39 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 8 Oct 2000 21:55:39 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 8 Oct 2000 21:55:39 -0000 Received: from f-cpu.org (nas3-75.aub.club-internet.fr [195.36.145.75]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA06400 for ; Sun, 8 Oct 2000 23:55:26 +0200 (MET DST) Message-ID: <39E0FC60.41011E79@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> <39E0C93F.9DA942F1@f-cpu.org> <39E0D849.79DCF15F@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Oct 2000 23:59:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d7434d0c9054d566682aa5cc6cc3cabf Status: R X-Status: N hi,



jeff davies wrote:
> Yann Guidon wrote:
> > Michael Riepe wrote:
> > > Ok, here's something to play with.  I got the 8x8 multiplier running.
> > > It's only partially tested yet; an exhaustive test (with 2^32 possible
> > > input patterns) would take 3 months on my Pentium/MMX.
> A very good reason to put it into a fpga and test it??
sure, but don't forget that SPEC tests a WHOLE system, the results
are accepted for machines that are shipped (sold) or going to be sold within
6 months, that it requires a lot of memory and HDD... so we'll also test
the HDD, the memory subsystem as well as all the controllers and device managers.
there might be something lighter, no ? :-)

but if you have the big FPGA, there is obviously no objection.


> MTRRs essentially give you the possibility to selectively change the cache
> policy of memory regions. Some algorithms behave better when using
> write-through, others not. write combining can be better for some software,
> when non-cachable is necessary for semaphores (for example).
It is obvious that the ability to turn off cacheing for certain address
ranges is required (as stated - for I/O or semaphores) , althought the above bit about
algorithms is a new one to me, but a very good point.

The Intel Optimisation Guide (I don't remember the exact number) gives a good hint
about why it's desirable. it shows an "example algorithm", a proof of concept with
the sieve of Erathostenes. For example, it mentions that the code runs better on
PII than PMMX because the caching strategy is different. When you write to an address
that is not in cache, the memory access bypasses the cache and you have full
penalty. The PII has write buffer that can rebuild whole cache lines and it creates
a burst. On PMMX, you have to "touch" a cache line to speedup the algo.

Unfortunately, this detail is often forgotten. MTRRs allow you, when you know that
you write to a location that will not be needed in the future, to bypass the cache
when needed, so you have less cache thrashing. the single-word external accesses
counter-balance the cache thrashing. If you know, in a multi-CPU system for example,
that an access can cause performance drop through MESI cycles, you can tune
the strategy.

> > >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> > WHYGEE
> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Yann Guidon Mon Oct 9 01:03:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01490 for ; Mon, 9 Oct 2000 01:30:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:08 +0200 (MEST) Received: (qmail 1628 invoked by uid 0); 8 Oct 2000 21:58:51 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 8 Oct 2000 21:58:51 -0000 X-eGroups-Return: sentto-1101623-1122-971042328-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 08 Oct 2000 21:58:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 21:58:48 -0000 Received: (qmail 22232 invoked from network); 8 Oct 2000 21:58:48 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 8 Oct 2000 21:58:48 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 8 Oct 2000 21:58:47 -0000 Received: from f-cpu.org (nas3-75.aub.club-internet.fr [195.36.145.75]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA24797 for ; Sun, 8 Oct 2000 23:58:45 +0200 (MET DST) Message-ID: <39E0FD2E.CB9AED3F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001003160119.51532@thrai.stud.uni-hannover.de> <39DA765F.2907E7AF@f-cpu.org> <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> <3BC1FF75.BE5AAA01@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Oct 2000 00:03:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] bench Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0c56490029924b085b10d6c5218dd956 Status: R X-Status: N Nicolas Boulay wrote:
> Somebody knows about a useful test to run it on a simulator. I just see
> about Spec but some month to have the number is a little bit too much...

F-CPU being a multi-purpose CPU, the test should be multi-purpose... right ? :-)

P&H limit the benchmarks to gcc&spice. that's an error, but interesting anyway.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS: j'ai encore ton bouquin :-)
 From Michael Riepe Mon Oct 9 00:00:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01493 for ; Mon, 9 Oct 2000 01:30:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:09 +0200 (MEST) Received: (qmail 27141 invoked by uid 0); 8 Oct 2000 22:00:35 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 8 Oct 2000 22:00:35 -0000 X-eGroups-Return: sentto-1101623-1123-971042431-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hh.egroups.com with NNFMP; 08 Oct 2000 22:00:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 22:00:31 -0000 Received: (qmail 26298 invoked from network); 8 Oct 2000 22:00:31 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 8 Oct 2000 22:00:31 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta3 with SMTP; 8 Oct 2000 22:00:30 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00552; Mon, 9 Oct 2000 00:00:30 +0200 Message-ID: <20001009000029.00759@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> <39E0C93F.9DA942F1@f-cpu.org> <39E0D849.79DCF15F@llandre.freeserve.co.uk> X-Mailer: Mutt 0.84e In-Reply-To: <39E0D849.79DCF15F@llandre.freeserve.co.uk>; from jeff davies on Sun, Oct 08, 2000 at 09:25:45PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 00:00:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 592929ff02d8e2418f50e5c18c1fbbba Status: R X-Status: N On Sun, Oct 08, 2000 at 09:25:45PM +0100, jeff davies wrote:
> Yann Guidon wrote:
>
> > Michael Riepe wrote:
> > > Ok, here's something to play with.  I got the 8x8 multiplier running.
> > > It's only partially tested yet; an exhaustive test (with 2^32 possible
> > > input patterns) would take 3 months on my Pentium/MMX.
>
> A very good reason to put it into a fpga and test it??

Do you have one that is fast (and big) enough?  Then please go ahead.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Mon Oct 9 00:07:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01496 for ; Mon, 9 Oct 2000 01:30:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:10 +0200 (MEST) Received: (qmail 2191 invoked by uid 0); 8 Oct 2000 22:08:06 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 8 Oct 2000 22:08:06 -0000 X-eGroups-Return: sentto-1101623-1124-971042873-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 08 Oct 2000 22:08:07 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 22:07:52 -0000 Received: (qmail 17005 invoked from network); 8 Oct 2000 22:07:52 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 8 Oct 2000 22:07:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta1 with SMTP; 8 Oct 2000 22:07:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00575; Mon, 9 Oct 2000 00:07:48 +0200 Message-ID: <20001009000747.07632@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39D697B2.4C8C1EEE@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <00100515444401.00396@gandalf> <39DD3435.925F47D3@f-cpu.org> <20001006143854.01095@thrai.stud.uni-hannover.de> <39DE7396.57A951D6@f-cpu.org> <20001007170427.27252@thrai.stud.uni-hannover.de> <20001008015058.08497@thrai.stud.uni-hannover.de> <39E0C93F.9DA942F1@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E0C93F.9DA942F1@f-cpu.org>; from Yann Guidon on Sun, Oct 08, 2000 at 08:21:35PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 00:07:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6caf403b388647980a03bd8afbae7af5 Status: R X-Status: N On Sun, Oct 08, 2000 at 08:21:35PM +0100, Yann Guidon wrote:

> i'm running the testbench at the moment, and it works correctly
> (at least until 2000.000 us). i'm reading the source at the same time.

When the simulation finally reaches 33,554.432 us you're probably also
done with the source ;)

> What i miss is a good schematic drawing :-)

Any artists in here? ;)

> > The circuit is still combinatorial because that is easier to check.
> > I did indicate the separate stages, though.  If we manage to add 13 bits
> > in a single cycle, we should have a 4-stage 8-bit multiplier; otherwise,
> > it will use 5 stages.  I have an alternative version under development
> > that should be even faster (3 cycles, maybe).
> if you could document it, it would be interesting.

Which one?

> As for testing larger multipliers, one idea is to use the pipeline stages
> to reduce the combinatorial explosion. If we split the unit, there are
> less things to test, no ? Can you apply this to the stages of the
> 9*9 multipliers, so it is tested faster ?

There are still lots of combinations in each stage if we want to test
the full functionality (including multiply-and-add), but I'll try.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Mon Oct 9 00:13:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01499 for ; Mon, 9 Oct 2000 01:30:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:11 +0200 (MEST) Received: (qmail 7657 invoked by uid 0); 8 Oct 2000 22:13:24 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 8 Oct 2000 22:13:24 -0000 X-eGroups-Return: sentto-1101623-1125-971043192-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 08 Oct 2000 22:13:20 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 22:13:12 -0000 Received: (qmail 24102 invoked from network); 8 Oct 2000 22:13:11 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 8 Oct 2000 22:13:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta3 with SMTP; 8 Oct 2000 22:13:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00594; Mon, 9 Oct 2000 00:13:07 +0200 Message-ID: <20001009001306.25879@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E0BF4B.EEE26402@f-cpu.org>; from Yann Guidon on Sun, Oct 08, 2000 at 07:39:07PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 00:13:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2f5e5e6ad39c5992fd4962c81f627e3a Status: R X-Status: N On Sun, Oct 08, 2000 at 07:39:07PM +0100, Yann Guidon wrote:

[benchmarks]
> so, ok to say that it is slow. now, i believe that a "normal" workload
> with various software will do the trick. P&H use Spice and GCC,
> let's add MP3 decompression and JPEG encoding, some heavy linear algebra
> and Lyx/Latex-like stuffs. Other heavily used things are DECT/GSM algos
> (with all the synchros and match searches) and IP routing algos.

Don't forget to compile the linux kernel ;)

[...]
> > This shouldn't worry us much; I suppose that synthesis tools will
> > perform DeMorgan transforms when necessary.
> let's hope so, and that's the least they can do,
> since they're usually so fucking expensive ;-)

You don't always get what you pay for, unfortunately :(

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Mon Oct 9 00:36:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01502 for ; Mon, 9 Oct 2000 01:30:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:12 +0200 (MEST) Received: (qmail 20196 invoked by uid 0); 8 Oct 2000 22:36:47 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 8 Oct 2000 22:36:47 -0000 X-eGroups-Return: sentto-1101623-1126-971044604-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 08 Oct 2000 22:36:46 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 22:36:43 -0000 Received: (qmail 14260 invoked from network); 8 Oct 2000 22:36:43 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 8 Oct 2000 22:36:43 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta2 with SMTP; 8 Oct 2000 22:36:42 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00691; Mon, 9 Oct 2000 00:36:39 +0200 Message-ID: <20001009003639.24866@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001008234206.19116@thrai.stud.uni-hannover.de> <39E0FB24.6BB249A2@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E0FB24.6BB249A2@f-cpu.org>; from Yann Guidon on Sun, Oct 08, 2000 at 11:54:28PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 00:36:39 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier take #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 653f280e250a5c864f96b0aa0d10fc85 Status: R X-Status: N On Sun, Oct 08, 2000 at 11:54:28PM +0100, Yann Guidon wrote:

> the first bench is still running on my computer, but the first
> half is ok. it's at time 18000us :-)

You've been warned :)

> What is your plan for the next stages ?

Combine 4 8x8 units to a 16x16 one, then 4 16x16 to one 32x32, and
finally 4 32x32 to one 64x64.  That means we need 64 of these tiny
(*cough*) little beauties, plus some 1-level wallace trees and adders.

Alternatively, I could convert the 8x8 into 8xn or 16x16 units, but
that would be unwise when we want SIMD.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Yann Guidon Mon Oct 9 02:05:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01508 for ; Mon, 9 Oct 2000 01:30:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 01:30:14 +0200 (MEST) Received: (qmail 18854 invoked by uid 0); 8 Oct 2000 23:01:48 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 8 Oct 2000 23:01:48 -0000 X-eGroups-Return: sentto-1101623-1127-971046104-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 08 Oct 2000 23:01:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 8 Oct 2000 23:01:43 -0000 Received: (qmail 3220 invoked from network); 8 Oct 2000 23:01:43 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 8 Oct 2000 23:01:43 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 8 Oct 2000 23:01:43 -0000 Received: from f-cpu.org (nas1-205.aub.club-internet.fr [195.36.150.205]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA04631 for ; Mon, 9 Oct 2000 01:01:39 +0200 (MET DST) Message-ID: <39E10BE1.9E466046@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001004052714.61783@thrai.stud.uni-hannover.de> <39DB82E2.9D19FF8E@f-cpu.org> <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> <20001009001306.25879@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Oct 2000 01:05:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ab58699d26f15b4654c3b2f9741062c Status: R X-Status: N hi !

the night is starting well, it seems :-)

Michael Riepe wrote:
> On Sun, Oct 08, 2000 at 07:39:07PM +0100, Yann Guidon wrote:
>
> [benchmarks]
> Don't forget to compile the linux kernel ;)
that's what we'll feed in gcc :-)

but then, you'll remark the very high demand on memory
and HDD, thus kernel and devices. SPEC contestants
never compete with half-loaded weapons, they always aim at
the high-quality and expensive systems, not a FPGA ;-)
In the GCC case, compiling the linux kernel will certainly
benchmark the HDD, not the CPU.

> [...]
> > > This shouldn't worry us much; I suppose that synthesis tools will
> > > perform DeMorgan transforms when necessary.
> > let's hope so, and that's the least they can do,
> > since they're usually so fucking expensive ;-)
> You don't always get what you pay for, unfortunately :(
fortunately, you're here to make the dirty work instead ;-)
and, fortunately for us, it's at no cost ;-P


> > the first bench is still running on my computer, but the first
> > half is ok. it's at time 18000us :-)
> You've been warned :)
now it's 22000 but yes, i've been warned and i give it a run/try :-)
just for the fun of using my CPU the way it should run...

> > What is your plan for the next stages ?
>
> Combine 4 8x8 units to a 16x16 one, then 4 16x16 to one 32x32, and
> finally 4 32x32 to one 64x64.  That means we need 64 of these tiny
> (*cough*) little beauties, plus some 1-level wallace trees and adders.
what would be the total latencies for each size ?
8*(8*8+16) : 3 cycles (we'll tune the adder later, don't worry)
4*(16*16) : ?
2*(32*32) : ?
64*64 : ?

This means that the Xbar will need 4 inputs from the IMUL unit if
we want to feed one operation of any size at each cycle. This could
be reduced to 2 ports anyway (the 2W limitation) but i don't want
to think about it now, i gotta finish the Icache.

> Alternatively, I could convert the 8x8 into 8xn or 16x16 units, but
> that would be unwise when we want SIMD.
i agree. SIMD 8*8 multiplies are worth the worries : see JPEG and MPEG...
16*16 and 32*32 are for sound processing/FFT/filtering...

Btw, is there any room left to include the fractional number support ?
(like the 1Q15 or something like that : 1 sign bit and 15 useful bits)
it's "only" a matter of a shifter at the end stage of the multiplier.

remember : 1Q7 * 1Q7 (the Q meaning the fixed point) gives 2Q14,
we need a single shift to get back to 1Q15. This could be something
that can influence the booth coding.

> On Sun, Oct 08, 2000 at 08:21:35PM +0100, Yann Guidon wrote:
> > i'm running the testbench at the moment, and it works correctly
> > (at least until 2000.000 us). i'm reading the source at the same time.
> When the simulation finally reaches 33,554.432 us you're probably also
> done with the source ;)
mmm i've started writing something else, instead.

> > What i miss is a good schematic drawing :-)
> Any artists in here? ;)
not me : i'm a bit busy :-)

> > > I have an alternative version under development
> > > that should be even faster (3 cycles, maybe).
> > if you could document it, it would be interesting.
> Which one?
the one that works ;-)

> > As for testing larger multipliers, one idea is to use the pipeline stages
> > to reduce the combinatorial explosion. If we split the unit, there are
> > less things to test, no ? Can you apply this to the stages of the
> > 9*9 multipliers, so it is tested faster ?
> There are still lots of combinations in each stage if we want to test
> the full functionality (including multiply-and-add), but I'll try.
better soon than late :-)
remember that usually, the motto is "design for testability"...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
are multipliers part of the fun ? :-) [or the dying part ?]
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Michael Riepe Mon Oct 9 02:24:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00324 for ; Mon, 9 Oct 2000 09:03:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:23 +0200 (MEST) Received: (qmail 17385 invoked by uid 0); 9 Oct 2000 00:24:52 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 9 Oct 2000 00:24:52 -0000 X-eGroups-Return: sentto-1101623-1128-971051081-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 09 Oct 2000 00:24:49 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 00:24:40 -0000 Received: (qmail 13149 invoked from network); 9 Oct 2000 00:24:40 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 9 Oct 2000 00:24:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.199) by mta2 with SMTP; 9 Oct 2000 00:24:37 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01026; Mon, 9 Oct 2000 02:24:34 +0200 Message-ID: <20001009022434.44922@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> <20001009001306.25879@thrai.stud.uni-hannover.de> <39E10BE1.9E466046@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E10BE1.9E466046@f-cpu.org>; from Yann Guidon on Mon, Oct 09, 2000 at 01:05:53AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 02:24:34 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 61447d816e4fe55c5f6c54dd9bdb348f Status: R X-Status: N On Mon, Oct 09, 2000 at 01:05:53AM +0100, Yann Guidon wrote:

> > Don't forget to compile the linux kernel ;)
> that's what we'll feed in gcc :-)

*grin*

> but then, you'll remark the very high demand on memory
> and HDD, thus kernel and devices. SPEC contestants
> never compete with half-loaded weapons, they always aim at
> the high-quality and expensive systems, not a FPGA ;-)

What did Shakespeare write?  `There are things between heaven and earth,
Horatio, that an FPGA will do even better than Some Random CPU (tm)...'

> In the GCC case, compiling the linux kernel will certainly
> benchmark the HDD, not the CPU.

That's right.

> > > > This shouldn't worry us much; I suppose that synthesis tools will
> > > > perform DeMorgan transforms when necessary.
> > > let's hope so, and that's the least they can do,
> > > since they're usually so fucking expensive ;-)
> > You don't always get what you pay for, unfortunately :(
> fortunately, you're here to make the dirty work instead ;-)
> and, fortunately for us, it's at no cost ;-P

No cost?  I expected at least a working F-CPU for free ;)

> > > What is your plan for the next stages ?
> >
> > Combine 4 8x8 units to a 16x16 one, then 4 16x16 to one 32x32, and
> > finally 4 32x32 to one 64x64.  That means we need 64 of these tiny
> > (*cough*) little beauties, plus some 1-level wallace trees and adders.
> what would be the total latencies for each size ?
> 8*(8*8+16) : 3 cycles (we'll tune the adder later, don't worry)
> 4*(16*16) : ?
> 2*(32*32) : ?
> 64*64 : ?

8x8+16 -> 3 cycles
16x16+32 -> 5 cycles
32x32+64 -> 7 cycles
64x64+64 -> 9 or 10 cycles

> This means that the Xbar will need 4 inputs from the IMUL unit if
> we want to feed one operation of any size at each cycle. This could
> be reduced to 2 ports anyway (the 2W limitation) but i don't want
> to think about it now, i gotta finish the Icache.

Don't forget that it also does `widening' multiplications -- that
means 3 input + 8 output ports.

> Btw, is there any room left to include the fractional number support ?
> (like the 1Q15 or something like that : 1 sign bit and 15 useful bits)
> it's "only" a matter of a shifter at the end stage of the multiplier.
>
> remember : 1Q7 * 1Q7 (the Q meaning the fixed point) gives 2Q14,
> we need a single shift to get back to 1Q15. This could be something
> that can influence the booth coding.

This is actually 7x7->14 unsigned multiplication plus a shift, and an
xor for the sign bit.  If we route the sign bits separately, this should
not be a problem.

> > > > I have an alternative version under development
> > > > that should be even faster (3 cycles, maybe).
> > > if you could document it, it would be interesting.
> > Which one?
> the one that works ;-)

They both work, AFAIK ;)

> > > As for testing larger multipliers, one idea is to use the pipeline stages
> > > to reduce the combinatorial explosion. If we split the unit, there are
> > > less things to test, no ? Can you apply this to the stages of the
> > > 9*9 multipliers, so it is tested faster ?
> > There are still lots of combinations in each stage if we want to test
> > the full functionality (including multiply-and-add), but I'll try.
> better soon than late :-)
> remember that usually, the motto is "design for testability"...

That's a totally different thing and depends very much on the error model
you use.  For a `stuck-at' error model, you hardly need exhaustive bit
patterns, but we need them to prove that the circuit actually does what
it was designed for.  Otherwise 3*4 might become 11.9 (did anybody say
`Pentium' out there?  Jokers! ;).

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> >  "All I wanna do is have a little fun before I die"
> are multipliers part of the fun ? :-) [or the dying part ?]

It's (much) fun when things work, dying otherwise ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From jeff@llandre.freeserve.co.uk Mon Oct 9 04:15:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00327 for ; Mon, 9 Oct 2000 09:03:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:25 +0200 (MEST) Received: (qmail 9981 invoked by uid 0); 9 Oct 2000 01:15:56 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 9 Oct 2000 01:15:56 -0000 X-eGroups-Return: sentto-1101623-1129-971054147-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ej.egroups.com with NNFMP; 09 Oct 2000 01:16:00 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 01:15:46 -0000 Received: (qmail 18621 invoked from network); 9 Oct 2000 01:15:46 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 9 Oct 2000 01:15:46 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta2 with SMTP; 9 Oct 2000 01:15:46 -0000 Received: from modem-123.praseodymium.dialup.pol.co.uk ([62.136.49.123] helo=62.136.49.123) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13iRXY-0005Ni-00 for f-cpu@egroups.com; Mon, 09 Oct 2000 02:15:42 +0100 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 2:15 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 909fdf9a46ce5f4b36bf7eb8bdfdac7c Status: R X-Status: N How about this idea for a fast CPU to RAM interface:
Async Block Transfer mode;

data line x n + one line as a "start block" signal.
Both the cpu and the ram know the clock speed, but
they do not have a common clock. When the block
start positive edge is given, 1024 bits or whatever are
read 5 nS apart.

Or perhaps bit number one of the packet is always 1 on each
line allowing for skew between lines..

Jeff Davies
eGroups Sponsor
From Yann Guidon Mon Oct 9 04:25:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00330 for ; Mon, 9 Oct 2000 09:03:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:25 +0200 (MEST) Received: (qmail 2104 invoked by uid 0); 9 Oct 2000 01:21:04 -0000 Received: from ci.egroups.com (208.50.99.231) by mx19.rz2.gmx.net with SMTP; 9 Oct 2000 01:21:04 -0000 X-eGroups-Return: sentto-1101623-1130-971054447-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 09 Oct 2000 01:21:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 01:20:47 -0000 Received: (qmail 26252 invoked from network); 9 Oct 2000 01:20:47 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 9 Oct 2000 01:20:47 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 9 Oct 2000 01:20:46 -0000 Received: from f-cpu.org (nas2-218.ras.club-internet.fr [195.36.192.218]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA10249 for ; Mon, 9 Oct 2000 03:20:44 +0200 (MET DST) Message-ID: <39E12C81.66FC9976@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Oct 2000 03:25:05 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] simulation finished :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 19fd8212fb15671b76f5200d6c3f624e Status: R X-Status: N just for the record :

vhdle mul9x9_test
Symphony EDA (R) VHDL Compiler/Simulator Module VhdlE, Version 1.4, Build#32.
Copyright(C) Symphony EDA 1997-2000. All rights reserved.
Reading d:\vhdl\simili\bin\symphony.ini ...
Library 'ieee'          ==> $SYMPHONY/Lib/Ieee/Ieee.sym
Library 'work'          ==> work.sym
Reading  work.sym\mul9x9_test\mul9x9_test.var
Reading  $SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_textio\std_logic_textio(body).var
Reading  $SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_1164\std_logic_1164(body).var
Reading  $SYMPHONY\Lib\Ieee\Ieee.sym\numeric_std\numeric_std(body).var
Reading  work.sym\mul9x9_test\mul9x9_test(arch_1).var
Reading  work.sym\mul9x9\mul9x9.var
Reading  work.sym\mul9x9\mul9x9(arch_1).var
        # of Signals       = 284
        # of Components    = 1
        # of Processes     = 6
        # of Drivers       = 214
Design Load/Elaboration Elapsed Time: 00h:00m:01s:785ms
*******************************************
Multiplier Testbench (C) 2000 Michael Riepe
*******************************************
Expect this to run for quite some time...
Get some coffee now, or go dating your SO.

*** Testing 8-bit signed multiplication
ASSERT: WARNING at 0 ps+0: NUMERIC_STD.TO_INTEGER: metavalue detected, returning
0
    At imul3.vhdl: (line 106)
        Instance = :mul9x9_test(arch_1):mut@
*** Testing 8-bit unsigned multiplication
Simulation stopped at: 33554.432 us
Simulation Elapsed Time: 07h:28m:53s:079ms


so, i did it :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Rares Marian Mon Oct 9 05:06:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00333 for ; Mon, 9 Oct 2000 09:03:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:27 +0200 (MEST) Received: (qmail 27553 invoked by uid 0); 9 Oct 2000 03:06:59 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 9 Oct 2000 03:06:59 -0000 X-eGroups-Return: sentto-1101623-1131-971060816-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 09 Oct 2000 03:06:57 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 03:06:55 -0000 Received: (qmail 25004 invoked from network); 9 Oct 2000 03:06:55 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Oct 2000 03:06:55 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 9 Oct 2000 03:06:55 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 45B87538FA for ; Sun, 8 Oct 2000 23:06:00 -0400 (EDT) To: f-cpu@egroups.com Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 23:06:00 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Testing procmail Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 16af2d58c621d242914cd8a58b6cc534 Status: R X-Status: N Ignore this

I just set up procmail.  Weee!

Rares



 From Rares Marian Mon Oct 9 05:11:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00336 for ; Mon, 9 Oct 2000 09:03:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:27 +0200 (MEST) Received: (qmail 9456 invoked by uid 0); 9 Oct 2000 03:12:29 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 9 Oct 2000 03:12:29 -0000 X-eGroups-Return: sentto-1101623-1132-971061127-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 09 Oct 2000 03:12:13 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 03:12:07 -0000 Received: (qmail 5491 invoked from network); 9 Oct 2000 03:12:07 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 9 Oct 2000 03:12:07 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 9 Oct 2000 03:12:07 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id CF279538FA for ; Sun, 8 Oct 2000 23:11:11 -0400 (EDT) To: f-cpu@egroups.com Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Oct 2000 23:11:11 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Trial 2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac5ad2a04ea3fcfb6337b87bd21ec070 Status: R X-Status: N Procmail test 2

Rares
eGroups Sponsor
From Colin Marquardt Mon Oct 9 08:02:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00345 for ; Mon, 9 Oct 2000 09:03:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:29 +0200 (MEST) Received: (qmail 20204 invoked by uid 0); 9 Oct 2000 06:00:40 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 9 Oct 2000 06:00:40 -0000 X-eGroups-Return: sentto-1101623-1133-971071231-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 09 Oct 2000 06:00:31 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 06:00:31 -0000 Received: (qmail 15124 invoked from network); 9 Oct 2000 06:00:31 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 9 Oct 2000 06:00:31 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 9 Oct 2000 06:00:30 -0000 Received: from morphin.marquardt-home.de (d75.nas21.sonic.net [209.204.136.75]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id IAA23984 for ; Mon, 9 Oct 2000 08:00:28 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13iW1H-0004Z7-00 for ; Sun, 08 Oct 2000 23:02:39 -0700 To: f-cpu@egroups.com References: <20001008234206.19116@thrai.stud.uni-hannover.de> X-Now-Playing: Grave's You'll Never See - Brutally Deceased In-Reply-To: Michael Riepe's message of "Sun, 8 Oct 2000 23:42:06 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 08 Oct 2000 23:02:39 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier take #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bced730cdacfcce7edbd388e4fed2172 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> Hi!
> Here's my second implementation of the 8x8 multiplier.  It uses nine

| -- inputs (will be changed to 8-bit later)
| A : in std_ulogic_vector(8 downto 0);
| B : in std_ulogic_vector(8 downto 0);      -- XXX: make width generic?

I would make the width a constant at least, yes. Then base as many
of the other "magic numbers" as you can on these. If that doesn't
seem feasible, mention in the header that this is 8x8 only, and
other widths have to be constructed from that.

Colin
 From Rares Marian Mon Oct 9 08:16:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00348 for ; Mon, 9 Oct 2000 09:03:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 09:03:30 +0200 (MEST) Received: (qmail 24395 invoked by uid 0); 9 Oct 2000 06:17:43 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 9 Oct 2000 06:17:43 -0000 X-eGroups-Return: sentto-1101623-1134-971072245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 09 Oct 2000 06:17:26 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 06:17:25 -0000 Received: (qmail 1832 invoked from network); 9 Oct 2000 06:17:25 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 9 Oct 2000 06:17:25 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 9 Oct 2000 06:17:25 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 83D00538FA for ; Mon, 9 Oct 2000 02:16:11 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 02:16:11 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier take #2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c68aa7a8908ddf1f50fa3427585244b Status: R X-Status: N On 8 Oct 2000, Colin Marquardt wrote:

Could someone repost the vhdl?

Rares

> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> > Hi!
> > Here's my second implementation of the 8x8 multiplier.  It uses nine
>
> | -- inputs (will be changed to 8-bit later)
> | A : in std_ulogic_vector(8 downto 0);
> | B : in std_ulogic_vector(8 downto 0);      -- XXX: make width generic?
>
> I would make the width a constant at least, yes. Then base as many
> of the other "magic numbers" as you can on these. If that doesn't
> seem feasible, mention in the header that this is 8x8 only, and
> other widths have to be constructed from that.
>
> Colin

 From Jeff Davies/CDPTEST Mon Oct 9 12:03:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00301 for ; Mon, 9 Oct 2000 16:38:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 16:38:08 +0200 (MEST) Received: (qmail 3691 invoked by uid 0); 9 Oct 2000 10:06:22 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 9 Oct 2000 10:06:22 -0000 X-eGroups-Return: sentto-1101623-1135-971085979-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 09 Oct 2000 10:06:19 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 10:06:18 -0000 Received: (qmail 14628 invoked from network); 9 Oct 2000 10:06:18 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Oct 2000 10:06:18 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta3 with SMTP; 9 Oct 2000 10:06:18 -0000 Received: from modem-153.calcium.dialup.pol.co.uk ([62.136.19.153] helo=sargon.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13iZp1-00069W-00 for f-cpu@egroups.com; Mon, 09 Oct 2000 11:06:16 +0100 To: f-cpu@egroups.com Message-ID: <45D59175013587A68025697300370B1B.0000000000000000@pileser.sumeria> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 11:03:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] 8-bit signed/unsigned multiplier/adder Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e1ab5213c8776dca90c5a6f81830c09 Status: R X-Status: N > > Michael Riepe wrote:
> > > Ok, here's something to play with.  I got the 8x8 multiplier running.
> > > It's only partially tested yet; an exhaustive test (with 2^32
possible
> > > input patterns) would take 3 months on my Pentium/MMX.
>
>> A very good reason to put it into a fpga and test it??

> Do you have one that is fast (and big) enough?  Then please go ahead.

Big enough to test an 8x8 multiplier?? I'd have though it would be
difficult to find
a FPGA that is too small to fit one in?

Jeff Davies

 From Yann Guidon Mon Oct 9 16:19:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00307 for ; Mon, 9 Oct 2000 16:38:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Oct 2000 16:38:09 +0200 (MEST) Received: (qmail 23929 invoked by uid 0); 9 Oct 2000 13:15:24 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 9 Oct 2000 13:15:24 -0000 X-eGroups-Return: sentto-1101623-1136-971097318-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 09 Oct 2000 13:15:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 13:15:17 -0000 Received: (qmail 26567 invoked from network); 9 Oct 2000 13:15:17 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 9 Oct 2000 13:15:17 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 9 Oct 2000 13:15:17 -0000 Received: from f-cpu.org (nas4-103.ras.club-internet.fr [195.36.203.103]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA18679 for ; Mon, 9 Oct 2000 15:15:14 +0200 (MET DST) Message-ID: <39E1D3FF.F322374A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Oct 2000 15:19:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4dfbbc4de648bec912650c2962e27141 Status: R X-Status: N hi !

jeff@llandre.freeserve.co.uk wrote:
> How about this idea for a fast CPU to RAM interface:
> Async Block Transfer mode;
how do you handle the asynch part ?...

> data line x n + one line as a "start block" signal.
> Both the cpu and the ram know the clock speed, but
> they do not have a common clock. When the block
> start positive edge is given, 1024 bits or whatever are
> read 5 nS apart.

now, how can you do the magic of keeping the 2 clocks
synchronous ???

> Or perhaps bit number one of the packet is always 1 on each
> line allowing for skew between lines..
well, if you don't solve the clock problem, this won't help :-)

what's wrong with a clock line ? :-)

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From Jeff Davies/CDPTEST Mon Oct 9 17:42:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01841 for ; Tue, 10 Oct 2000 01:08:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 01:08:17 +0200 (MEST) Received: (qmail 5667 invoked by uid 0); 9 Oct 2000 15:46:35 -0000 Received: from mu.egroups.com (208.50.99.218) by mx19.rz2.gmx.net with SMTP; 9 Oct 2000 15:46:35 -0000 X-eGroups-Return: sentto-1101623-1137-971106369-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mu.egroups.com with NNFMP; 09 Oct 2000 15:46:32 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 15:46:07 -0000 Received: (qmail 26075 invoked from network); 9 Oct 2000 15:46:07 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 9 Oct 2000 15:46:07 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta1 with SMTP; 9 Oct 2000 15:46:05 -0000 Received: from modem-59.doxycycline.dialup.pol.co.uk ([62.136.91.59] helo=sargon.pileser.sumeria) by mail3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13if7o-0003cp-00 for f-cpu@egroups.com; Mon, 09 Oct 2000 16:46:00 +0100 To: f-cpu@egroups.com Message-ID: From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 16:42:48 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d07d00d35ae658f04c691748e45b44a5 Status: R X-Status: N hi !

jeff@llandre.freeserve.co.uk wrote:
> How about this idea for a fast CPU to RAM interface:
> Async Block Transfer mode;
how do you handle the asynch part ?...

** say you transfer 256 words of data in a block. Per line this is 256
bits.
The rising edge is the leading edge start bit. All timings *on this line*
are then
synchronised to this start time. All lines are independant, allowing for
minute time
differences due to longer track lengths on the motherboard.
So, a circuit generates 256 clock pulses in the RAM each 5ns apart starting
5ns after the
rising edge of the start bit.


> data line x n + one line as a "start block" signal.
> Both the cpu and the ram know the clock speed, but
> they do not have a common clock. When the block
> start positive edge is given, 1024 bits or whatever are
> read 5 nS apart.

now, how can you do the magic of keeping the 2 clocks
synchronous ???

** they don't have to be synchronous! They just have to be sufficiently
accurate
not to have over 0.5 bit time error during the packet.

> Or perhaps bit number one of the packet is always 1 on each
> line allowing for skew between lines..
well, if you don't solve the clock problem, this won't help :-)
**no clock problem

what's wrong with a clock line ? :-)
** just think above will be able to be driven faster. What's wrong with a
Z80?

> Jeff Davies
WHYGEE

**Jeff
eGroups Sponsor
From "Marco Al" Mon Oct 9 19:43:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01856 for ; Tue, 10 Oct 2000 01:08:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 01:08:20 +0200 (MEST) Received: (qmail 20306 invoked by uid 0); 9 Oct 2000 17:38:56 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 9 Oct 2000 17:38:56 -0000 X-eGroups-Return: sentto-1101623-1138-971113128-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 09 Oct 2000 17:38:54 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_0_3); 9 Oct 2000 17:38:47 -0000 Received: (qmail 16204 invoked from network); 9 Oct 2000 17:38:46 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 9 Oct 2000 17:38:46 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 9 Oct 2000 17:38:46 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id TAA20745 for ; Mon, 9 Oct 2000 19:38:44 +0200 (METDST) Message-ID: <004d01c03218$7302c860$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 19:43:34 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4e78ff7944ae92ce60814117cafd0cdf Status: R X-Status: N From: "Jeff Davies/CDPTEST" <jeff@llandre.freeserve.co.uk>

> > what's wrong with a clock line ? :-)
> ** just think above will be able to be driven faster. What's wrong with a
> Z80?

I dont see it. AFAICS you can sync even more easily if you include a
forwarded clock with the data, one extra line wont kill you.

Marco

 From Michael Riepe Mon Oct 9 14:38:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01868 for ; Tue, 10 Oct 2000 01:08:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 01:08:24 +0200 (MEST) Received: (qmail 18712 invoked by uid 0); 9 Oct 2000 21:42:03 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 9 Oct 2000 21:42:03 -0000 X-eGroups-Return: sentto-1101623-1139-971127710-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 09 Oct 2000 21:42:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 9 Oct 2000 21:41:48 -0000 Received: (qmail 11362 invoked from network); 9 Oct 2000 21:41:48 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 9 Oct 2000 21:41:48 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.189) by mta3 with SMTP; 9 Oct 2000 21:41:41 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00537; Mon, 9 Oct 2000 14:38:03 +0200 Message-ID: <20001009143803.26795@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from jeff@llandre.freeserve.co.uk on Mon, Oct 09, 2000 at 02:15:00AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 14:38:03 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ec8828dd9d09b5c62b8778e27821dde5 Status: R X-Status: N On Mon, Oct 09, 2000 at 02:15:00AM +0000, jeff@llandre.freeserve.co.uk wrote:
> How about this idea for a fast CPU to RAM interface:
> Async Block Transfer mode;
>
> data line x n + one line as a "start block" signal.
> Both the cpu and the ram know the clock speed, but
> they do not have a common clock. When the block
> start positive edge is given, 1024 bits or whatever are
> read 5 nS apart.

That would run out of sync quickly.

I'd rather use asynchronous logic (phased logic, to be more precise).
There is no clock at all, just a pair of data lines (per bit).
To transfer a single bit, toggle one of these lines; which one depends
on the bit value.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Mon Oct 9 14:05:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01871 for ; Tue, 10 Oct 2000 01:08:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 01:08:24 +0200 (MEST) Received: (qmail 4063 invoked by uid 0); 9 Oct 2000 21:42:15 -0000 Received: from jk.egroups.com (208.50.144.83) by mx11.rz2.gmx.net with SMTP; 9 Oct 2000 21:42:15 -0000 X-eGroups-Return: sentto-1101623-1140-971127727-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 09 Oct 2000 21:42:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 9 Oct 2000 21:42:06 -0000 Received: (qmail 10996 invoked from network); 9 Oct 2000 21:42:06 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Oct 2000 21:42:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.189) by mta3 with SMTP; 9 Oct 2000 21:41:59 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00435; Mon, 9 Oct 2000 14:05:01 +0200 Message-ID: <20001009140501.52274@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39E12C81.66FC9976@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E12C81.66FC9976@f-cpu.org>; from Yann Guidon on Mon, Oct 09, 2000 at 03:25:05AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Oct 2000 14:05:01 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] simulation finished :-) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e58409d4c9bf99183ec85bbfafb1eb81 Status: R X-Status: N On Mon, Oct 09, 2000 at 03:25:05AM +0100, Yann Guidon wrote:
> just for the record :
>
> vhdle mul9x9_test
[...]
> Simulation stopped at: 33554.432 us
> Simulation Elapsed Time: 07h:28m:53s:079ms
>
>
> so, i did it :-)

Yeah!
Of course I knew that 8x8+8 would work ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Tue Oct 10 03:16:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00311 for ; Tue, 10 Oct 2000 17:08:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:54 +0200 (MEST) Received: (qmail 9611 invoked by uid 0); 10 Oct 2000 00:12:14 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 10 Oct 2000 00:12:14 -0000 X-eGroups-Return: sentto-1101623-1141-971136727-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 10 Oct 2000 00:12:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 00:12:06 -0000 Received: (qmail 30205 invoked from network); 10 Oct 2000 00:12:06 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 10 Oct 2000 00:12:06 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 10 Oct 2000 00:12:06 -0000 Received: from f-cpu.org (nas1-201.aub.club-internet.fr [195.36.150.201]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA12253 for ; Tue, 10 Oct 2000 02:12:02 +0200 (MET DST) Message-ID: <39E26DF1.D4052C16@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001005023448.33011@thrai.stud.uni-hannover.de> <39DBF0BF.74592E65@f-cpu.org> <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> <20001009001306.25879@thrai.stud.uni-hannover.de> <39E10BE1.9E466046@f-cpu.org> <20001009022434.44922@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 02:16:33 +0100 Reply-To: f-cpu@egroups.com Subject: (i) Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 626511c59ef2a6c53b162c1b242fb445 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Mon, Oct 09, 2000 at 01:05:53AM +0100, Yann Guidon wrote:
> What did Shakespeare write?  `There are things between heaven and= earth,
> Horatio, that an FPGA will do even better than Some Random CPU (tm)...= '
hum, what book was it ?...

> > In the GCC case, compiling the linux kernel will certainly
> > benchmark the HDD, not the CPU.
> That's right.
so this makes the point that the computer is not the CPU only.
we know that the efficiency of the cache (for example)
greatly depends both on the software that we run and the HW that
is used. i see no obvious way to "measure" the cache efficiency idenpendently of the rest, except with the size in KB and
the latency and throughput in clock cycles.

is this enough ?

> > > You don't always get what you pay for, unfortunately :(
> > fortunately, you're here to make the dirty work instead ;-)
> > and, fortunately for us, it's at no cost ;-P
> No cost?  I expected at least a working F-CPU for free ;)
we'll make a nice pin or medail from one chip,
with "knight of the F-CPU order" in bold letters,
and we'll send it to you ;-P

I have some epoxy resin and we'll use faulty/failed chips for
this purpose of course ;-)

no kidding, now : i have no idea of the way the first ASICs will
be fabbed. I only know that we'll have prototypes easily if
we come up with a good synthetisable HDL source.

> > > > What is your plan for the next stages ?
> 8x8+16 -> 3 cycles
> 16x16+32 -> 5 cycles
> 32x32+64 -> 7 cycles
> 64x64+64 -> 9 or 10 cycles
yummy yummy :-)))
i hope that you'll succeed because it looks too good to
be true ;-)

> > This means that the Xbar will need 4 inputs from the IMUL unit if=
> > we want to feed one operation of any size at each cycle. This cou= ld
> > be reduced to 2 ports anyway (the 2W limitation) but i don't want=
> > to think about it now, i gotta finish the Icache.
> Don't forget that it also does `widening' multiplications -- that
> means 3 input + 8 output ports.
i don't get it. i'm probably too worried or tired. can you explain
more clearly ?

> > Btw, is there any room left to include the fractional number supp= ort ?
> > (like the 1Q15 or something like that : 1 sign bit and 15 useful = bits)
> > it's "only" a matter of a shifter at the end stage of t= he multiplier.
> >
> > remember : 1Q7 * 1Q7 (the Q meaning the fixed point) gives 2Q14,<= BR> > > we need a single shift to get back to 1Q15. This could be somethi= ng
> > that can influence the booth coding.
>
> This is actually 7x7->14 unsigned multiplication plus a shift, and = an
> xor for the sign bit.  If we route the sign bits separately, this= should
> not be a problem.
cool :-) i gotta check if we have a provision for this operation in the
instruction set census.

<clic><clic><clic><clic>...

COOL ! we have the bit 11 that is still reserved ;-)
so we can use it for this purpose.

> > > > > I have an alternative version under development > > > > > that should be even faster (3 cycles, maybe).
> > > > if you could document it, it would be interesting.
> > > Which one?
> > the one that works ;-)
> They both work, AFAIK ;)
;-)

> > remember that usually, the motto is "design for testability&= quot;...
> That's a totally different thing and depends very much on the error mo= del
> you use.  For a `stuck-at' error model, you hardly need exhaustiv= e bit
> patterns, but we need them to prove that the circuit actually does wha= t
> it was designed for.  Otherwise 3*4 might become 11.9 (did anybod= y say
> `Pentium' out there?  Jokers! ;).
well, let's simply do as good as we can, and let's use any opportunity
to ease the debug phase, independently from the error model.
If the test runs in O(N) instead of O(N=B2), that's a win.
If we can break units up, we reduce the testbench's runtime.
hey, that's another win of the superpipeline methodology :-)

For the multiplier, for example, we can define SRs (Special Registers)
that can spy the partial results. To run a test, we can send a multiply
instruction and read all the partial results with the different SRs.
If 64*64 takes 10 cycles, we need 10 SRs. Then the problem is to determine<= BR> what data should be used to test all the combinations, exhaustively but
without redundancy. heck.

> > >  Michael "Tired" Riepe <Michael.Riepe@stud= .uni-hannover.de>
> > >  "All I wanna do is have a little fun before I die= "
> > are multipliers part of the fun ? :-) [or the dying part ?]
> It's (much) fun when things work, dying otherwise ;)
amen...

ok, let's sleep.
zzzz man,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Tue Oct 10 03:16:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00314 for ; Tue, 10 Oct 2000 17:08:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:55 +0200 (MEST) Received: (qmail 9625 invoked by uid 0); 10 Oct 2000 00:12:15 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 10 Oct 2000 00:12:15 -0000 X-eGroups-Return: sentto-1101623-1142-971136729-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 10 Oct 2000 00:12:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 00:12:09 -0000 Received: (qmail 32034 invoked from network); 10 Oct 2000 00:12:09 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Oct 2000 00:12:09 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 10 Oct 2000 00:12:09 -0000 Received: from f-cpu.org (nas1-201.aub.club-internet.fr [195.36.150.201]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA16414 for ; Tue, 10 Oct 2000 02:12:05 +0200 (MET DST) Message-ID: <39E26DF3.6E8E1EBA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001009143803.26795@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 02:16:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6ddad36ed129d14ffc9c48e4bda54de Status: R X-Status: N hi,

Michael Riepe wrote:
> On Mon, Oct 09, 2000 at 02:15:00AM +0000, jeff@llandre.freeserve.co.uk wrote:
> > How about this idea for a fast CPU to RAM interface:
> > Async Block Transfer mode;
> >
> > data line x n + one line as a "start block" signal.
> > Both the cpu and the ram know the clock speed, but
> > they do not have a common clock. When the block
> > start positive edge is given, 1024 bits or whatever are
> > read 5 nS apart.
>
> That would run out of sync quickly.
>
> I'd rather use asynchronous logic (phased logic, to be more precise).
> There is no clock at all, just a pair of data lines (per bit).
> To transfer a single bit, toggle one of these lines; which one depends
> on the bit value.

I still am puzzled about his device.
Can Jeff make a little diagram or schematic ?

i can understand that we can resynch on a front
but this means that there is a front all the time,
while data can't be all fronts all the time
(we can move a block of zeroes, for example).
The clock wire is the solution but as he pointed,
it can be out of phase because of the PCB's different
wire lengths. What Jeff proposes is more like what is
used on magnetic recordings or wire/radio links :
we get the clock mixed with the data. there is
nothing really new here, but the latency (the time
it takes to get your bits) augments by tens of ns,
which counter-balances the win.

can Jeff be more explicit about his very idea ?

One idea that i add to Jeff's :
i'm ok to say that there can be some "lag" between signals
of the same bus. This is usually corrected with a zig-zag
to lengthen the line (have you seen a recent SDRAM module ?)
but adds some nanoHenrys. What Jeff will get with his
idea is a "dynamic lag", a "jitter", while the PCB only
generates a static one (+ parasites). so he'll gets probably
the worse of both worlds.

If the "PCB lag" is static, let's treat it this way.
As you may know, it is possible to make configurable
delay lines, that can be configured at reset time.
a delay line cell can be a simple RLC element and the
output can go to a multiplexer and the next cell.
is it simple enough ?

> what's wrong with a clock line ? :-)
> ** just think above will be able to be driven faster. What's wrong with a Z80?
what's the point ? i don't understand...


have a good relaxing night,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Tue Oct 10 03:16:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00317 for ; Tue, 10 Oct 2000 17:08:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:56 +0200 (MEST) Received: (qmail 9636 invoked by uid 0); 10 Oct 2000 00:12:16 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 10 Oct 2000 00:12:16 -0000 X-eGroups-Return: sentto-1101623-1143-971136729-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 10 Oct 2000 00:12:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 00:12:09 -0000 Received: (qmail 32054 invoked from network); 10 Oct 2000 00:12:09 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 10 Oct 2000 00:12:09 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 10 Oct 2000 00:12:09 -0000 Received: from f-cpu.org (nas1-201.aub.club-internet.fr [195.36.150.201]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA23450 for ; Tue, 10 Oct 2000 02:12:06 +0200 (MET DST) Message-ID: <39E26DF4.15CD04B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39E12C81.66FC9976@f-cpu.org> <20001009140501.52274@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 02:16:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] simulation finished :-) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ec13af6f8d4b90220e78e1fd2a778544 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Mon, Oct 09, 2000 at 03:25:05AM +0100, Yann Guidon wrote:
> > just for the record :
> > Simulation stopped at: 33554.432 us
> > Simulation Elapsed Time: 07h:28m:53s:079ms
> >
> > so, i did it :-)
> Yeah!
> Of course I knew that 8x8+8 would work ;)
that's not the point :
jetzt weiss ich wie verr=FCkt ich bin ;-P

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Jeff Davies/CDPTEST Tue Oct 10 02:24:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00320 for ; Tue, 10 Oct 2000 17:08:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:56 +0200 (MEST) Received: (qmail 13895 invoked by uid 0); 10 Oct 2000 00:27:33 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 10 Oct 2000 00:27:33 -0000 X-eGroups-Return: sentto-1101623-1144-971137642-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 10 Oct 2000 00:27:31 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 00:27:22 -0000 Received: (qmail 30860 invoked from network); 10 Oct 2000 00:27:22 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 10 Oct 2000 00:27:22 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 10 Oct 2000 00:27:22 -0000 Received: from modem-20.adderall.dialup.pol.co.uk ([62.136.76.20] helo=sargon.pileser.sumeria) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13inGK-00051h-00 for f-cpu@egroups.com; Tue, 10 Oct 2000 01:27:21 +0100 To: f-cpu@egroups.com Message-ID: <2B63ACFD491BBB1F802569740000BB63.0000000000000000@pileser.sumeria> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 01:24:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ede335fbb16b5c2a672004966184a76a Status: R X-Status: N From: "Jeff Davies/CDPTEST" <jeff@llandre.freeserve.co.uk>

>> > what's wrong with a clock line ? :-)
>> ** just think above will be able to be driven faster. What's wrong with
a
>> Z80?

>I dont see it. AFAICS you can sync even more easily if you include a
>forwarded clock with the data, one extra line wont kill you.

>Marco

The point is that at higher frequency, the clock may be skewed with respect
to the data lines
(and the data lines skewed with respect to each other). However, relative
to itself, a given
data line would be unlikely to be skewed. Therefore if you have a mechanism
that removes
all forms of skew from the equation, you have a potentially faster was of
bursting to ram, which
is what this is.

Think of it like a hyper fast uart on each line, clocking in not 10 bits,
but 256.
One could even build in stuff like CRC, stop bit checking (framing error),
for hyper reliable
superfast bursting.

Given say 128 lines to a bank of RAM, The CPU might burst 256 words. It
would also simplify
memory interface if address was sent as a word before the bursted block
along the same lines.

The clock being forwarded is not the issue. A long time ago as a student, I
repaired Sun3
workstation motherboards. The video circuitry was ECL and running at
300MHZ+. At those speeds
there is no semblance of a square wave. I think clock skew is a big
problem. By going
asynchronous you avoid this area.

Anyway my main point in submitting this idea is for it to be a public idea
(and archived publically) , and so in 3 years time, if Rambus decide it is
a good idea, they
can't rape the world again.


Jeff Davies
eGroups Sponsor
From Jeff Davies/CDPTEST Tue Oct 10 02:29:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00323 for ; Tue, 10 Oct 2000 17:08:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:58 +0200 (MEST) Received: (qmail 8031 invoked by uid 0); 10 Oct 2000 00:32:46 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 10 Oct 2000 00:32:46 -0000 X-eGroups-Return: sentto-1101623-1145-971137959-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ch.egroups.com with NNFMP; 10 Oct 2000 00:32:41 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 00:32:39 -0000 Received: (qmail 20878 invoked from network); 10 Oct 2000 00:32:38 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 10 Oct 2000 00:32:38 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 10 Oct 2000 00:32:38 -0000 Received: from modem-20.adderall.dialup.pol.co.uk ([62.136.76.20] helo=sargon.pileser.sumeria) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13inLQ-0005NQ-00 for f-cpu@egroups.com; Tue, 10 Oct 2000 01:32:37 +0100 To: f-cpu@egroups.com Message-ID: <777CE7F65CD653AD802569740002428B.0000000000000000@pileser.sumeria> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 01:29:20 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb8289349a69509281e930a4114c0e35 Status: R X-Status: N On Mon, Oct 09, 2000 at 02:15:00AM +0000, jeff@llandre.freeserve.co.uk
wrote:
>> How about this idea for a fast CPU to RAM interface:
>> Async Block Transfer mode;
>>
>> data line x n + one line as a "start block" signal.
>> Both the cpu and the ram know the clock speed, but
>> they do not have a common clock. When the block
>> start positive edge is given, 1024 bits or whatever are
>> read 5 nS apart.

>That would run out of sync quickly.

How so? The RAM chip times the bits from the starting edge of the start bit
on each line individually - like 128 off UART, one for every line coming to
the ram chip.
Each line is self -syncing to the start of it's packet. How can it run out
of sync ever?

>I'd rather use asynchronous logic (phased logic, to be more precise).
>There is no clock at all, just a pair of data lines (per bit).
>To transfer a single bit, toggle one of these lines; which one depends
>on the bit value.

Yes but your will need a f**k **f size package. For 128 bit wide ram you'd
need 256 wires.
Good luck routing it.

On the other hand, if RAMBUS try to patent it in 3 years time, now the idea
is in the public
domain! So well done Michael.


--
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> "All I wanna do is have a little fun before I die"

Jeff Davies
eGroups Sponsor
From Nicolas Boulay Tue Oct 9 23:14:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00329 for ; Tue, 10 Oct 2000 17:08:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:08:59 +0200 (MEST) Received: (qmail 17496 invoked by uid 0); 10 Oct 2000 03:43:28 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 10 Oct 2000 03:43:28 -0000 X-eGroups-Return: sentto-1101623-1146-971149392-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 10 Oct 2000 03:43:27 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 03:43:11 -0000 Received: (qmail 1889 invoked from network); 10 Oct 2000 03:43:11 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Oct 2000 03:43:11 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 10 Oct 2000 03:43:10 -0000 Received: from 195.36.164.117 [195.36.164.117] by lh00.opsion.fr; Mon, 9 Oct 2000 21:11:32 GMT Message-ID: <3BC368AE.EC288A57@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win95; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 09 Oct 2001 23:14:22 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5e26a22ae64b0de4e476d8dd1c387f96 Status: R X-Status: N

Jeff Davies/CDPTEST a =E9crit :
>
> hi !
>
> jeff@llandre.freeserve.co.uk wrote:
> > How about this idea for a fast CPU to RAM interface:
> > Async Block Transfer mode;
> how do you handle the asynch part ?...
>
> ** say you transfer 256 words of data in a block. Per line this is 256=
> bits.
> The rising edge is the leading edge start bit. All timings *on this li= ne*
> are then
> synchronised to this start time. All lines are independant, allowing f= or
> minute time
> differences due to longer track lengths on the motherboard.
> So, a circuit generates 256 clock pulses in the RAM each 5ns apart sta= rting
> 5ns after the
> rising edge of the start bit.

If the line aren't of the same length, the time propagation change. Do
you know the big difference between EDO and SDRAM. I think the S for
synchronous. Why some teams who want to reuse old core must rewrite them all ? to your mind ?

>
> > data line x n + one line as a "start block" signal.
> > Both the cpu and the ram know the clock speed, but
> > they do not have a common clock. When the block
> > start positive edge is given, 1024 bits or whatever are
> > read 5 nS apart.
>
> now, how can you do the magic of keeping the 2 clocks
> synchronous ???
>
> ** they don't have to be synchronous! They just have to be sufficientl= y
> accurate
> not to have over 0.5 bit time error during the packet.

So you need a regenerator clock system, like for serial transmission
with a 4 times sample rate and voting mechanisme...

>
> > Or perhaps bit number one of the packet is always 1 on each
> > line allowing for skew between lines..
> well, if you don't solve the clock problem, this won't help :-)
> **no clock problem
>

So very BIG problem to solve.

> what's wrong with a clock line ? :-)
> ** just think above will be able to be driven faster. What's wrong wit= h a
> Z80?

It's slow ?

>
> > Jeff Davies
> WHYGEE
>
> **Jeff
>

___________________________________________________________________________= ___
Vous avez un site perso ?
2 millions de francs =E0 gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
eGroups Sponsor=
3D""
From "Marco Al" Tue Oct 10 07:01:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00332 for ; Tue, 10 Oct 2000 17:09:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:09:00 +0200 (MEST) Received: (qmail 24094 invoked by uid 0); 10 Oct 2000 04:56:34 -0000 Received: from cj.egroups.com (208.50.144.68) by mx06.rz2.gmx.net with SMTP; 10 Oct 2000 04:56:34 -0000 X-eGroups-Return: sentto-1101623-1147-971153786-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 10 Oct 2000 04:56:33 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 04:56:25 -0000 Received: (qmail 26340 invoked from network); 10 Oct 2000 04:56:25 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 10 Oct 2000 04:56:25 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 10 Oct 2000 04:56:25 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id GAA02495 for ; Tue, 10 Oct 2000 06:56:23 +0200 (METDST) Message-ID: <001d01c03277$1f0f0930$29e65982@student.utwente.nl> To: References: <2B63ACFD491BBB1F802569740000BB63.0000000000000000@pileser.sumeria> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 07:01:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0ab5e14836d72fdd30bb490e9248da7 Status: R X-Status: N From: "Jeff Davies/CDPTEST" <jeff@llandre.freeserve.co.uk>


> From: "Jeff Davies/CDPTEST" <jeff@llandre.freeserve.co.uk>
>
> >> > what's wrong with a clock line ? :-)
> >> ** just think above will be able to be driven faster. What's wrong with
> a
> >> Z80?
>
> >I dont see it. AFAICS you can sync even more easily if you include a
> >forwarded clock with the data, one extra line wont kill you.
>
> >Marco
>
> The point is that at higher frequency, the clock may be skewed with
respect
> to the data lines

If you go you're way, you would presumably have to put a DLL on each input
(to delay a common clock, synchronicity is still assumed in your method).
But a DLL doesnt lock in that fast I think, plus there is really no need to
lock into the initial edge AFAICS... the skew has to be pretty much static,
your method doesnt do much for jitter/dynamic-skew, so you could just use a
digital DLL and lock it in during reset. Just matching path lengths is a lot
easier and cheaper though.

I think if you get to really high frequences (and/or relatively long paths)
dynamic effects will be important and need a different approach, but yours
doesnt help there. The easiest solution would be multi level signalling (if
the signal is guarantueed to change every clock you can truly clock the data
to itself).

Marco
eGroups Sponsor
From Jeff Davies/CDPTEST Tue Oct 10 10:50:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00362 for ; Tue, 10 Oct 2000 17:09:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:09:07 +0200 (MEST) Received: (qmail 9686 invoked by uid 0); 10 Oct 2000 08:54:24 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 10 Oct 2000 08:54:24 -0000 X-eGroups-Return: sentto-1101623-1148-971168049-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 10 Oct 2000 08:54:13 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 08:54:08 -0000 Received: (qmail 24727 invoked from network); 10 Oct 2000 08:54:08 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 10 Oct 2000 08:54:08 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta2 with SMTP; 10 Oct 2000 08:54:08 -0000 Received: from modem-98.depacon.dialup.pol.co.uk ([62.136.88.98] helo=sargon.pileser.sumeria) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ivAk-0000x9-00 for f-cpu@egroups.com; Tue, 10 Oct 2000 09:54:06 +0100 To: f-cpu@egroups.com Message-ID: <645C06812BAA371180256974002FF896.0000000000000000@pileser.sumeria> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 09:50:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c4b61b51f1e6dd6297e0a82026415cf5 Status: R X-Status: N DPTEST a =E9crit :
>
> hi !
>
> jeff@llandre.freeserve.co.uk wrote:
> > How about this idea for a fast CPU to RAM interface:
> > Async Block Transfer mode;
> how do you handle the asynch part ?...
>
> ** say you transfer 256 words of data in a block. Per line this is 256=
> bits.
> The rising edge is the leading edge start bit. All timings *on this li= ne*
> are then
> synchronised to this start time. All lines are independant, allowing f= or
> minute time
> differences due to longer track lengths on the motherboard.
> So, a circuit generates 256 clock pulses in the RAM each 5ns apart starting
> 5ns after the
> rising edge of the start bit.

If the line aren't of the same length, the time propagation change. Do
you know the big difference between EDO and SDRAM. I think the S for
synchronous. Why some teams who want to reuse old core must rewrite them all ? to your mind ?

** I think async will be faster, just a bit more complex.

>
> > data line x n + one line as a "start block" signal.
> > Both the cpu and the ram know the clock speed, but
> > they do not have a common clock. When the block
> > start positive edge is given, 1024 bits or whatever are
> > read 5 nS apart.
>
> now, how can you do the magic of keeping the 2 clocks
> synchronous ???
>
> ** they don't have to be synchronous! They just have to be sufficientl= y
> accurate
> not to have over 0.5 bit time error during the packet.

So you need a regenerator clock system, like for serial transmission
with a 4 times sample rate and voting mechanisme...

** PIC uart uses clock *3 for sampling and voting, I think. However, in classic uarts, they
have to maintain synchronisation from start bits over a long long sequence =
of bytes.
in my proposal, it only has to maintain synch from start bit (of the
packet) to end of packet
(256 bits for example). So no need for regenerator with 4 times sample rate=
etc, just either
data rate (phase shifted by 0.5 cycle). This "clock" will be prim= ed prior
to the packet being
sent, and start running at the first leading edge. It will count 257, then =
stop.

>
> > Or perhaps bit number one of the packet is always 1 on each
> > line allowing for skew between lines..
> well, if you don't solve the clock problem, this won't help :-)
> **no clock problem
>

So very BIG problem to solve.
** There are millions of uarts out there with no clock line, and no clock <= BR> encoded in the signal.
** what is the problem?

> what's wrong with a clock line ? :-)
> ** just think above will be able to be driven faster. What's wrong wit= h a
> Z80?

It's slow ?
** exactly. Perhaps having a clock line LIMITs your speed.

>
> > Jeff Davies
> WHYGEE
>
> **Jeff
>
jeff

eGroups Sponsor=
3D""
<= /a>
From Jeff Davies/CDPTEST Tue Oct 10 10:57:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00365 for ; Tue, 10 Oct 2000 17:09:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:09:08 +0200 (MEST) Received: (qmail 25307 invoked by uid 0); 10 Oct 2000 09:03:21 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net with SMTP; 10 Oct 2000 09:03:21 -0000 X-eGroups-Return: sentto-1101623-1149-971168456-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 10 Oct 2000 09:00:59 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 09:00:56 -0000 Received: (qmail 2833 invoked from network); 10 Oct 2000 09:00:56 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 10 Oct 2000 09:00:56 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 10 Oct 2000 09:00:55 -0000 Received: from modem-98.depacon.dialup.pol.co.uk ([62.136.88.98] helo=sargon.pileser.sumeria) by mail12.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ivHJ-00026K-00 for f-cpu@egroups.com; Tue, 10 Oct 2000 10:00:54 +0100 To: f-cpu@egroups.com Message-ID: <5D666B41991D2D03802569740030B5E4.0000000000000000@pileser.sumeria> From: Jeff Davies/CDPTEST MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 09:57:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e46d0cec4135ccb6afed810b26121c37 Status: R X-Status: N
> From: "Jeff Davies/CDPTEST" <jeff@llandre.freeserve.co.uk>
>
> >> > what's wrong with a clock line ? :-)
> >> ** just think above will be able to be driven faster. What's wrong
with
> a
> >> Z80?
>
> >I dont see it. AFAICS you can sync even more easily if you include a
> >forwarded clock with the data, one extra line wont kill you.
>
> >Marco
>
> The point is that at higher frequency, the clock may be skewed with
respect
> to the data lines

If you go you're way, you would presumably have to put a DLL on each input
(to delay a common clock, synchronicity is still assumed in your method).

** yes it assumes the data rate is unaffected, but the data across the word
might be
** skewed in time.

But a DLL doesnt lock in that fast I think, plus there is really no need to
lock into the initial edge AFAICS... the skew has to be pretty much static,
your method doesnt do much for jitter/dynamic-skew, so you could just use a
digital DLL and lock it in during reset. Just matching path lengths is a
lot
easier and cheaper though.

** depends if the dynamic skew is big enough to make a difference of 0.5
bit times
** over 256 bit packet. With CRC or simple framing error detection, this
could cause
** retransmission of the packet for example.

I think if you get to really high frequences (and/or relatively long paths)
dynamic effects will be important and need a different approach, but yours
doesnt help there. The easiest solution would be multi level signalling (if
the signal is guarantueed to change every clock you can truly clock the
data
to itself).

** you mean encode the clock on every data line. This is also a good idea.
more complex
** - probably wouldn't work on FPGA (unless analog devices analog fpga)
** - but might be doable on a ASIC. (multi level is used on ISDN)



Marco

** anyhow, I'm not suggesting this for FC0. I'm trying to put ideas into
the public domain for
** much faster than SDRAM type technology before RAMBUS patent everything.

jeff Davies
eGroups Sponsor
From "Amaury Jacquot" Tue Oct 10 12:06:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00380 for ; Tue, 10 Oct 2000 17:09:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:09:12 +0200 (MEST) Received: (qmail 28750 invoked by uid 0); 10 Oct 2000 10:03:21 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 10 Oct 2000 10:03:21 -0000 X-eGroups-Return: sentto-1101623-1150-971172199-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 10 Oct 2000 10:03:19 -0000 X-Sender: sxpert@www.esitcom.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 10:03:18 -0000 Received: (qmail 5063 invoked from network); 10 Oct 2000 10:03:18 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 10 Oct 2000 10:03:18 -0000 Received: from unknown (HELO snipe.prod.itd.earthlink.net) (207.217.121.233) by mta1 with SMTP; 10 Oct 2000 10:03:18 -0000 Received: from electron (1Cust132.tnt1.hershey.pa.da.uu.net [63.23.225.132]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA04553 for ; Tue, 10 Oct 2000 03:03:17 -0700 (PDT) To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001d01c03277$1f0f0930$29e65982@student.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal From: "Amaury Jacquot" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 06:06:36 -0400 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6284819bb12e0c9d1002d18418aa3f86 Status: R X-Status: N

> -----Original Message-----
> From: Marco Al [mailto:marco@simplex.nl]
> Sent: Tuesday, October 10, 2000 1:01 AM
> To: f-cpu@egroups.com
> Subject: Re: [f-cpu] cpu ram interface

[snip]

> I think if you get to really high frequences (and/or relatively
> long paths)
> dynamic effects will be important and need a different approach, but yours
> doesnt help there. The easiest solution would be multi level
> signalling (if
> the signal is guarantueed to change every clock you can truly
> clock the data
> to itself).

If you go to higher frequencies, then you have Radio frequencies issues, and
you then need to be careful at the _impedence_ of the lines...

it seems that pc motherboard manufacturers (i'm looking at my giga-byte
right
now) make elongated s shaped things to make the lines the same lengths,
however,
I would think this adds some weird things like selfs and caps along the
lines...

> Marco

Amaury

>
>
>
>
>
eGroups Sponsor
From Michael Riepe Tue Oct 10 05:04:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00389 for ; Tue, 10 Oct 2000 17:09:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Oct 2000 17:09:15 +0200 (MEST) Received: (qmail 3322 invoked by uid 0); 10 Oct 2000 12:33:40 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 10 Oct 2000 12:33:40 -0000 X-eGroups-Return: sentto-1101623-1151-971181177-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ei.egroups.com with NNFMP; 10 Oct 2000 12:33:06 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 12:32:56 -0000 Received: (qmail 23435 invoked from network); 10 Oct 2000 12:32:56 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Oct 2000 12:32:56 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.175) by mta3 with SMTP; 10 Oct 2000 12:32:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA00383; Tue, 10 Oct 2000 05:04:53 +0200 Message-ID: <20001010050452.51221@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 05:04:52 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] multiplier, take #3 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" X-UIDL: f55fbaab25022bb59b840c7a7bd9c1d9 Status: R X-Status: N --PEIAKu/WMn1b1Hv9 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi!

I realized that the first stage will be simpler when I drop booth's
algorithm and use explicit corrections for signed multiplication.  I also
made B'length generic (but didn't test values other than 8 yet), changed
A and B to their _real_ width and added an input for signed/unsigned
mode switching.  There's also a modified testbench for the new module
interface.

The algorithm is pretty simple now.  In the first stage, it places all
1-bit partial products (A'length * B'length of them) in a bit matrix,
at the correct positions.  Then, it puts the `multiply-and-add' input
X and the correction numbers for signed multiplication (one for A < 0,
one for B < 0) into three additional matrix rows.  Unused bits in the
matrix are set to '0'.

The rest of stage 1 (and stage 2) consists of full adders forming a
wallace tree.  They reduce the matrix to 2 rows, which are added
in stage 3.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Description: 8xN multiplier Content-Disposition: attachment; filename="imul7.vhdl" -- imul7.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: imul7.vhdl,v 1.1 2000/10/10 02:38:45 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; -- -- 8xN-bit signed/unsigned multiplier/adder -- entity Mul8xN is generic ( BWIDTH : natural := 8 -- width of multiplicator (affects output width) ); port ( -- inputs A : in std_ulogic_vector(7 downto 0); B : in std_ulogic_vector(BWIDTH-1 downto 0); -- optional full-width `add' input X : in std_ulogic_vector(BWIDTH+7 downto 0) := (others => '0'); -- signed/unsigned mode switch Smul : in std_ulogic; -- full-width output Y : out std_ulogic_vector(BWIDTH+7 downto 0) ); end Mul8xN; architecture Arch_1 of Mul8xN is type std_ulogic_matrix is array(natural range <>, natural range <>) of std_ulogic; signal s3 : std_ulogic_matrix(5 downto 0, Y'length-1 downto 0); signal s6 : std_ulogic_matrix(1 downto 0, Y'length-1 downto 0); begin stage1 : process (A, B, X, Smul) variable s1 : std_ulogic_matrix(10 downto 0, Y'length-1 downto 0); variable s2 : std_ulogic_matrix(7 downto 0, Y'length-1 downto 0); variable Aneg, Bneg : std_ulogic; begin -- -- unsigned multiplier bit matrix -- s1 := (others => (others => '0')); for j in A'length-1 downto 0 loop for i in B'length-1 downto 0 loop s1(j, j + i) := A(A'low + j) and B(B'low + i); end loop; end loop; -- -- additional summand -- for i in X'length-1 downto 0 loop s1(8, i) := X(X'low + i); end loop; -- -- subtract B << A'length if A < 0 -- Aneg := Smul and A(A'high); for i in B'length-1 downto 0 loop s1(9, A'length + i) := Aneg and not B(B'low + i); end loop; -- place carry in unused bit(s) for i in A'length-1 downto 0 loop s1(9, i) := Aneg; end loop; s1(1, 0) := Aneg; -- -- subtract A << B'length if B < 0 -- Bneg := Smul and B(B'high); for i in A'length-1 downto 0 loop s1(10, B'length + i) := Bneg and not A(A'low + i); end loop; -- place carry in unused bit s1(0, B'length) := Bneg; -- -- first level of wallace tree -- s2 := (others => (others => '0')); for i in s2'range(2) loop s2(0, i) := s1(0, i) xor s1(1, i) xor s1(2, i); s2(1, i) := s1(3, i) xor s1(4, i) xor s1(5, i); s2(2, i) := s1(6, i) xor s1(7, i) xor s1(8, i); if i < s2'high(2) then s2(3, i+1) := (s1(0, i) and s1(1, i)) or (s1(0, i) and s1(2, i)) or (s1(1, i) and s1(2, i)); s2(4, i+1) := (s1(3, i) and s1(4, i)) or (s1(3, i) and s1(5, i)) or (s1(4, i) and s1(5, i)); s2(5, i+1) := (s1(6, i) and s1(7, i)) or (s1(6, i) and s1(8, i)) or (s1(7, i) and s1(8, i)); end if; s2(6, i) := s1(9, i); s2(7, i) := s1(10, i); end loop; -- -- second level of wallace tree -- s3 <= (others => (others => '0')); for i in s3'range(2) loop s3(0, i) <= s2(0, i) xor s2(1, i) xor s2(2, i); s3(1, i) <= s2(3, i) xor s2(4, i) xor s2(5, i); if i < s3'high(2) then s3(2, i+1) <= (s2(0, i) and s2(1, i)) or (s2(0, i) and s2(2, i)) or (s2(1, i) and s2(2, i)); s3(3, i+1) <= (s2(3, i) and s2(4, i)) or (s2(3, i) and s2(5, i)) or (s2(4, i) and s2(5, i)); end if; s3(4, i) <= s2(6, i); s3(5, i) <= s2(7, i); end loop; end process; stage2 : process (s3) variable s4 : std_ulogic_matrix(3 downto 0, Y'length-1 downto 0); variable s5 : std_ulogic_matrix(2 downto 0, Y'length-1 downto 0); begin -- -- third level of wallace tree -- s4 := (others => (others => '0')); for i in s4'range(2) loop s4(0, i) := s3(0, i) xor s3(1, i) xor s3(2, i); s4(1, i) := s3(3, i) xor s3(4, i) xor s3(5, i); if i < s4'high(2) then s4(2, i+1) := (s3(0, i) and s3(1, i)) or (s3(0, i) and s3(2, i)) or (s3(1, i) and s3(2, i)); s4(3, i+1) := (s3(3, i) and s3(4, i)) or (s3(3, i) and s3(5, i)) or (s3(4, i) and s3(5, i)); end if; end loop; -- -- fourth level of wallace tree -- s5 := (others => (others => '0')); for i in s5'range(2) loop s5(0, i) := s4(0, i) xor s4(1, i) xor s4(2, i); if i < s5'high(2) then s5(1, i+1) := (s4(0, i) and s4(1, i)) or (s4(0, i) and s4(2, i)) or (s4(1, i) and s4(2, i)); end if; s5(2, i) := s4(3, i); end loop; -- -- fifth level of wallace tree -- s6 <= (others => (others => '0')); for i in s6'range(2) loop s6(0, i) <= s5(0, i) xor s5(1, i) xor s5(2, i); if i < s6'high(2) then s6(1, i+1) <= (s5(0, i) and s5(1, i)) or (s5(0, i) and s5(2, i)) or (s5(1, i) and s5(2, i)); end if; end loop; end process; stage3 : process (s6) variable s7, s8 : std_ulogic_vector(Y'length-1 downto 0); begin -- -- carry look-ahead adder -- s8(S8'low) := '0'; for i in s7'low to s7'high loop s7(i) := s6(0, i) xor s6(1, i); if i < s7'high then s8(i+1) := (s6(0, i) and s6(1, i)) or (s7(i) and s8(i)); end if; end loop; Y <= s7 xor s8; end process; end Arch_1; -- vi: set ts=4 sw=4 : please --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Description: testbench Content-Disposition: attachment; filename="t-imul7.vhdl" -- t-imul7.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: t-imul7.vhdl,v 1.2 2000/10/10 02:44:12 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use std.textio.all; use IEEE.std_logic_textio.all; entity mul8xn_test is end mul8xn_test; architecture Arch_1 of mul8xn_test is signal A, B : std_ulogic_vector(7 downto 0); signal X, Y : std_ulogic_vector(15 downto 0); signal Smul : std_ulogic; begin mut: entity work.Mul8xN generic map (BWIDTH => 8) port map (A => A, B => B, X => X, Smul => Smul, Y => Y); process variable i, j, k, prod, res : integer; variable lout : line; begin write(lout, "*******************************************"); writeline(output, lout); write(lout, "Multiplier Testbench (C) 2000 Michael Riepe"); writeline(output, lout); write(lout, "*******************************************"); writeline(output, lout); write(lout, "Expect this to run for quite some time..."); writeline(output, lout); write(lout, "Get some coffee now, or go dating your SO."); writeline(output, lout); writeline(output, lout); write(lout, "*** Testing 8-bit signed multiplication"); writeline(output, lout); Smul <= '1'; for i in -128 to 127 loop A <= std_ulogic_vector(to_signed(i, A'length)); for j in -128 to 127 loop B <= std_ulogic_vector(to_signed(j, B'length)); for k in -128 to 127 loop X <= std_ulogic_vector(to_signed(k, X'length)); wait for 1 ns; res := to_integer(signed(Y)); prod := i * j + k; if (res /= prod) then write(lout, "WHOA THERE!!! "); write(lout, i); write(lout, " * "); write(lout, j); write(lout, " + "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, prod); write(lout, " d = "); write(lout, res - prod); writeline(output, lout); end if; end loop; end loop; end loop; write(lout, "*** Testing 8-bit unsigned multiplication"); writeline(output, lout); Smul <= '0'; for i in 0 to 255 loop A <= std_ulogic_vector(to_unsigned(i, A'length)); for j in 0 to 255 loop B <= std_ulogic_vector(to_unsigned(j, B'length)); for k in 0 to 255 loop X <= std_ulogic_vector(to_unsigned(k, X'length)); wait for 1 ns; res := to_integer(unsigned(Y)); prod := i * j + k; if (res /= prod) then write(lout, "WHOA THERE!!! "); write(lout, i); write(lout, " * "); write(lout, j); write(lout, " + "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, prod); write(lout, " d = "); write(lout, res - prod); writeline(output, lout); end if; end loop; end loop; end loop; write(lout, "*** Testing 16-bit pass-through (unsigned)"); writeline(output, lout); A <= (others => '0'); B <= (others => '0'); for k in 0 to 65535 loop X <= std_ulogic_vector(to_unsigned(k, X'length)); wait for 1 ns; res := to_integer(unsigned(Y)); if (res /= k) then write(lout, "WHOA THERE!!! "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, k); write(lout, " d = "); write(lout, res - k); writeline(output, lout); end if; end loop; write(lout, "*** Testing 16-bit pass-through (signed)"); writeline(output, lout); Smul <= '1'; for k in 0 to 65535 loop X <= std_ulogic_vector(to_unsigned(k, X'length)); wait for 1 ns; res := to_integer(unsigned(Y)); if (res /= k) then write(lout, "WHOA THERE!!! "); write(lout, k); write(lout, " => "); write(lout, Y); write(lout, " /= "); write(lout, k); write(lout, " d = "); write(lout, res - k); writeline(output, lout); end if; end loop; wait; end process; end Arch_1; --PEIAKu/WMn1b1Hv9-- From Michael Riepe Tue Oct 10 15:12:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00353 for ; Wed, 11 Oct 2000 15:58:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:44 +0200 (MEST) Received: (qmail 7605 invoked by uid 0); 10 Oct 2000 21:32:51 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 10 Oct 2000 21:32:51 -0000 X-eGroups-Return: sentto-1101623-1152-971213548-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 10 Oct 2000 21:32:41 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 21:32:27 -0000 Received: (qmail 2406 invoked from network); 10 Oct 2000 21:32:27 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Oct 2000 21:32:27 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.147) by mta2 with SMTP; 10 Oct 2000 21:32:24 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00557; Tue, 10 Oct 2000 15:12:29 +0200 Message-ID: <20001010151229.06879@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <777CE7F65CD653AD802569740002428B.0000000000000000@pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <777CE7F65CD653AD802569740002428B.0000000000000000@pileser.sumeria>; from Jeff Davies/CDPTEST on Tue, Oct 10, 2000 at 01:29:20AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 15:12:29 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c238bd59954ce13504aba6e091a896e2 Status: R X-Status: N On Tue, Oct 10, 2000 at 01:29:20AM +0100, Jeff Davies/CDPTEST wrote:

> >That would run out of sync quickly.
>
> How so? The RAM chip times the bits from the starting edge of the start bit
> on each line individually - like 128 off UART, one for every line coming to
> the ram chip.
> Each line is self -syncing to the start of it's packet. How can it run out
> of sync ever?

Asynchronous transfer may be fine with small packets at 19200 Baud.
At 100 MHz, a bit is only 10ns long, and timing isn't accurate any longer.

> >I'd rather use asynchronous logic (phased logic, to be more precise).
> >There is no clock at all, just a pair of data lines (per bit).
> >To transfer a single bit, toggle one of these lines; which one depends
> >on the bit value.
>
> Yes but your will need a f**k **f size package. For 128 bit wide ram you'd
> need 256 wires.
> Good luck routing it.

I have seen synchronous memory busses that were 512 bits wide (plus
ECC bits).  UltraSPARC II chipset, IIRC.

> On the other hand, if RAMBUS try to patent it in 3 years time, now the idea
> is in the public
> domain! So well done Michael.

Dual-rail encoding and phased logic aren't new ideas, they're just
little used, although they have interesting properties.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Oct 10 14:57:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00356 for ; Wed, 11 Oct 2000 15:58:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:45 +0200 (MEST) Received: (qmail 7106 invoked by uid 0); 10 Oct 2000 21:32:57 -0000 Received: from ej.egroups.com (208.50.144.75) by mx19.rz2.gmx.net with SMTP; 10 Oct 2000 21:32:57 -0000 X-eGroups-Return: sentto-1101623-1153-971213562-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ej.egroups.com with NNFMP; 10 Oct 2000 21:33:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 21:32:42 -0000 Received: (qmail 12054 invoked from network); 10 Oct 2000 21:32:40 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 10 Oct 2000 21:32:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.147) by mta2 with SMTP; 10 Oct 2000 21:32:35 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00517; Tue, 10 Oct 2000 14:57:11 +0200 Message-ID: <20001010145711.58321@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001005143527.15452@thrai.stud.uni-hannover.de> <39DE6221.C2A9050F@f-cpu.org> <20001007013607.33815@thrai.stud.uni-hannover.de> <39DE84ED.7039B3D8@f-cpu.org> <20001007184312.31473@thrai.stud.uni-hannover.de> <39E0BF4B.EEE26402@f-cpu.org> <20001009001306.25879@thrai.stud.uni-hannover.de> <39E10BE1.9E466046@f-cpu.org> <20001009022434.44922@thrai.stud.uni-hannover.de> <39E26DF1.D4052C16@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E26DF1.D4052C16@f-cpu.org>; from Yann Guidon on Tue, Oct 10, 2000 at 02:16:33AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 14:57:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: (i) Re: [f-cpu] some other merged replies (cache+misc.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 54d0a10200548cfe42f01fb0d87e75d6 Status: R X-Status: N On Tue, Oct 10, 2000 at 02:16:33AM +0100, Yann Guidon wrote:

> so this makes the point that the computer is not the CPU only.
> we know that the efficiency of the cache (for example)
> greatly depends both on the software that we run and the HW that
> is used. i see no obvious way to "measure" the cache efficiency
> idenpendently of the rest, except with the size in KB and
> the latency and throughput in clock cycles.
>
> is this enough ?

I don't know.

[...]
> > > > > What is your plan for the next stages ?
> > 8x8+16 -> 3 cycles
> > 16x16+32 -> 5 cycles
> > 32x32+64 -> 7 cycles
> > 64x64+64 -> 9 or 10 cycles
> yummy yummy :-)))
> i hope that you'll succeed because it looks too good to
> be true ;-)

There's still a murphy factor of one or two cycles.

> > > This means that the Xbar will need 4 inputs from the IMUL unit if
> > > we want to feed one operation of any size at each cycle. This could
> > > be reduced to 2 ports anyway (the 2W limitation) but i don't want
> > > to think about it now, i gotta finish the Icache.
> > Don't forget that it also does `widening' multiplications -- that
> > means 3 input + 8 output ports.
> i don't get it. i'm probably too worried or tired. can you explain
> more clearly ?

I referred to the `mulh' instruction which needs two register writes
(2r2w), and two output ports per stage.

[signed-magnitude fractional numbers]
> > This is actually 7x7->14 unsigned multiplication plus a shift, and an
> > xor for the sign bit.  If we route the sign bits separately, this should
> > not be a problem.
> cool :-) i gotta check if we have a provision for this operation in the
> instruction set census.

Shouldn't that be a separate instruction?
BTW: does this have to be SIMD?

> For the multiplier, for example, we can define SRs (Special Registers)
> that can spy the partial results. To run a test, we can send a multiply
> instruction and read all the partial results with the different SRs.
> If 64*64 takes 10 cycles, we need 10 SRs. Then the problem is to determine
> what data should be used to test all the combinations, exhaustively but
> without redundancy. heck.

You mean, registers that are accessible in software?
What about boundary scan?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Jecel Assumpcao Jr Wed Oct 11 00:26:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00362 for ; Wed, 11 Oct 2000 15:58:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:47 +0200 (MEST) Received: (qmail 16483 invoked by uid 0); 10 Oct 2000 21:43:24 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 10 Oct 2000 21:43:24 -0000 X-eGroups-Return: sentto-1101623-1154-971214191-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 10 Oct 2000 21:43:13 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 21:43:10 -0000 Received: (qmail 9145 invoked from network); 10 Oct 2000 21:43:10 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 10 Oct 2000 21:43:10 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 10 Oct 2000 21:43:08 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA17037 for ; Tue, 10 Oct 2000 19:52:38 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <777CE7F65CD653AD802569740002428B.0000000000000000@pileser.sumeria> <20001010151229.06879@thrai.stud.uni-hannover.de> In-Reply-To: <20001010151229.06879@thrai.stud.uni-hannover.de> Message-Id: <00101019302706.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 19:26:57 -0300 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 12dcd64ba3f95f7c113e0938cc5f28dc Status: R X-Status: N People interested in high speed interfaces should check out:

   http://pasta.stanford.edu:80/hssp/

You can now add hundreds of transistors around a single pad and not
make the slightest difference in the chip size. So the simple
interfaces of the past no longer make sense (though when you use a FPGA
you are stuck with what they deliver).

I haven't kept up with the Rambus patent deals, but I think they are
related to the DDR SDRAMs only, and not to SDRAMs in general. Don't
trust me on this...

-- Jecel
eGroups Sponsor
From Jecel Assumpcao Jr Wed Oct 11 01:32:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00374 for ; Wed, 11 Oct 2000 15:58:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:50 +0200 (MEST) Received: (qmail 3884 invoked by uid 0); 10 Oct 2000 22:50:36 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 10 Oct 2000 22:50:36 -0000 X-eGroups-Return: sentto-1101623-1155-971218227-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 10 Oct 2000 22:50:41 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 22:50:27 -0000 Received: (qmail 23056 invoked from network); 10 Oct 2000 22:50:27 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 10 Oct 2000 22:50:27 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta2 with SMTP; 10 Oct 2000 22:50:24 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id UAA17179 for ; Tue, 10 Oct 2000 20:59:54 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] Message-Id: <00101020374107.00384@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 20:32:39 -0300 Reply-To: f-cpu@egroups.com Subject: [f-cpu] fpga Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ece50c43fe4ba99bf278dff8191828dd Status: R X-Status: N For those interested in FPGAs, I found this paper describing a better
architecture than the one I had proposed:

   ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Ian.Page/cam95.ps

  "The Design of a New FPGA Architecture",
  Anthony Stansfield and Ian Page.

  A description of the new CAM-based FPGA architecture. (14 pages,
  written Jul95)

I found a reference to this in:

   http://www.dcs.ed.ac.uk/home/gordon/fan/rep/web/Publications/thesis.html

   "Self-Timed Field Programmable Gate Array Architectures"
   Rob Payne: PhD Thesis

This one would also be interesting for people wanting to design
asynchronous circuits.

-- Jecel
P.S.: actually, my idea was very close to this CAM thing and combining
the two (hypercube connections) would give the best results of all
eGroups Sponsor
From Yann Guidon Wed Oct 11 02:38:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00377 for ; Wed, 11 Oct 2000 15:58:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:51 +0200 (MEST) Received: (qmail 7190 invoked by uid 0); 10 Oct 2000 23:34:43 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 10 Oct 2000 23:34:43 -0000 X-eGroups-Return: sentto-1101623-1156-971220868-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 10 Oct 2000 23:34:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:34:28 -0000 Received: (qmail 10552 invoked from network); 10 Oct 2000 23:34:28 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Oct 2000 23:34:28 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 10 Oct 2000 23:34:27 -0000 Received: from f-cpu.org (nas4-174.aub.club-internet.fr [195.36.145.174]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA09480 for ; Wed, 11 Oct 2000 01:34:24 +0200 (MET DST) Message-ID: <39E3B69C.4E1B53CA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001010050452.51221@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 01:38:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier, take #3 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ba67411bb0ff09298e088fde23d3fd74 Status: R X-Status: N hi !

Michael Riepe wrote:
> Hi!
>
> I realized that the first stage will be simpler when I drop booth's
> algorithm and use explicit corrections for signed multiplication.  I also
> made B'length generic (but didn't test values other than 8 yet), changed
> A and B to their _real_ width and added an input for signed/unsigned
> mode switching.  There's also a modified testbench for the new module
> interface.
>
> The algorithm is pretty simple now.  In the first stage, it places all
> 1-bit partial products (A'length * B'length of them) in a bit matrix,
> at the correct positions.  Then, it puts the `multiply-and-add' input
> X and the correction numbers for signed multiplication (one for A < 0,
> one for B < 0) into three additional matrix rows.  Unused bits in the
> matrix are set to '0'.
>
> The rest of stage 1 (and stage 2) consists of full adders forming a
> wallace tree.  They reduce the matrix to 2 rows, which are added
> in stage 3.
>
> Ciao,

Damn, this is getting really crazy :-)

A good documentation (some pages of HTML for example) would
probably kill the magic, but that would certainly help people
use your design. The documentation would be included in the
F-CPU/FC0 manual.

One cool thing, anyway : the MAC instruction can be used with
Michael's design. let's see now if there is a problem with
fractional/fixed point flags.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From jeff davies Wed Oct 11 01:35:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00380 for ; Wed, 11 Oct 2000 15:58:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:52 +0200 (MEST) Received: (qmail 4289 invoked by uid 0); 10 Oct 2000 23:34:58 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 10 Oct 2000 23:34:58 -0000 X-eGroups-Return: sentto-1101623-1159-971220878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 10 Oct 2000 23:34:55 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:34:38 -0000 Received: (qmail 11130 invoked from network); 10 Oct 2000 23:34:38 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 10 Oct 2000 23:34:38 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta2 with SMTP; 10 Oct 2000 23:34:38 -0000 Received: from modem-24.connecticut.dialup.pol.co.uk ([62.137.58.24] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13j8uq-0007fn-00 for f-cpu@egroups.com; Wed, 11 Oct 2000 00:34:36 +0100 Sender: root@pop.gmx.net Message-ID: <39E3A7A5.61E54EAA@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 00:35:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] can't be true can it? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fa09e93d87574d6442b370d2f5394e99 Status: R X-Status: N 2 off 64 bit MIPS plus 512k cache on a chip running at 1ghz yet only
consuming 10 watts??
can this be true?  runs Linux of course.

http://www.sibyte.com/

and worse still - http://www.pactcorp.com/ are supposed to have huge
32bit_processor arrays (128) somehow based
on FPGAs
"The core of the XPU128 is an array of 128 parallel Processing Array
     Elements (PAEs) implemented in advanced, reprogrammable
technology."

can it be that wintel might no longer be at the forefront of computing?
Surely not.

Jeff Davies
eGroups Sponsor
From Yann Guidon Wed Oct 11 02:38:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00383 for ; Wed, 11 Oct 2000 15:58:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:52 +0200 (MEST) Received: (qmail 22117 invoked by uid 0); 10 Oct 2000 23:35:03 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 10 Oct 2000 23:35:03 -0000 X-eGroups-Return: sentto-1101623-1158-971220872-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 10 Oct 2000 23:34:54 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:34:32 -0000 Received: (qmail 32480 invoked from network); 10 Oct 2000 23:34:32 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 10 Oct 2000 23:34:32 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 10 Oct 2000 23:34:31 -0000 Received: from f-cpu.org (nas4-174.aub.club-internet.fr [195.36.145.174]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA25939 for ; Wed, 11 Oct 2000 01:34:28 +0200 (MET DST) Message-ID: <39E3B6A2.2520797F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 01:38:58 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] My next toy Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2e4d45b7a9cf79f01b72e7f42ab8d0bd Status: R X-Status: N As some of you may know, my current peecee runs at 200MHz.

Today, i have _seen_ the monster with which i want to work :
several cubic meters, hundreds of ASICs and it can simulate
up to 10M gates at the rate of 1MHz. the ICE probe is in option.

the interview with the EDA vendor was very interesting,
let's hope that we will _all_ benefit from this.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 11 02:38:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00386 for ; Wed, 11 Oct 2000 15:58:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:53 +0200 (MEST) Received: (qmail 22552 invoked by uid 0); 10 Oct 2000 23:35:32 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 10 Oct 2000 23:35:32 -0000 X-eGroups-Return: sentto-1101623-1157-971220870-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mo.egroups.com with NNFMP; 10 Oct 2000 23:34:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:34:30 -0000 Received: (qmail 10762 invoked from network); 10 Oct 2000 23:34:30 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 10 Oct 2000 23:34:30 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 10 Oct 2000 23:34:30 -0000 Received: from f-cpu.org (nas4-174.aub.club-internet.fr [195.36.145.174]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA16681 for ; Wed, 11 Oct 2000 01:34:28 +0200 (MET DST) Message-ID: <39E3B6A1.B5FBF4D5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <5D666B41991D2D03802569740030B5E4.0000000000000000@pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 01:38:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d1d9e728096f523c41d82e28b478d3cf Status: R X-Status: N hi,

Jeff Davies/CDPTEST wrote:
> ** anyhow, I'm not suggesting this for FC0. I'm trying to put ideas into the public domain for
> ** much faster than SDRAM type technology before RAMBUS patent everything.
> jeff Davies
it was clear from the start. Anyway, i'm more or less that the abuse of patents
will probably kill the patents. Let's see how much load and shit the patent offices
can stand. they accept anything, and they'll pay this one day. When the justice
departments of all governments will be overflowed with complaints, the governments
will react. They will have a taste of it when they'll have to pay the fees for
the public education system : http://www.freepatents.org:80/examples/education.html
Do you think that any government can accept that ?

keep the good creative vibes flowing,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 11 02:45:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00389 for ; Wed, 11 Oct 2000 15:58:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:54 +0200 (MEST) Received: (qmail 12463 invoked by uid 0); 10 Oct 2000 23:41:18 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 10 Oct 2000 23:41:18 -0000 X-eGroups-Return: sentto-1101623-1160-971221260-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ho.egroups.com with NNFMP; 10 Oct 2000 23:41:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:41:00 -0000 Received: (qmail 28262 invoked from network); 10 Oct 2000 23:41:00 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 10 Oct 2000 23:41:00 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 10 Oct 2000 23:41:00 -0000 Received: from f-cpu.org (nas4-174.aub.club-internet.fr [195.36.145.174]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA27721 for ; Wed, 11 Oct 2000 01:40:57 +0200 (MET DST) Message-ID: <39E3B827.4CA5810@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39E3A7A5.61E54EAA@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 01:45:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] can't be true can it? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 22048d9ff49610eea3e497b0fd3a28b3 Status: R X-Status: N jeff davies wrote:
>
> 2 off 64 bit MIPS plus 512k cache on a chip running at 1ghz yet only
> consuming 10 watts??
> can this be true?  runs Linux of course.
>
> http://www.sibyte.com/

still browsing ... crunch crunch...

> and worse still - http://www.pactcorp.com/ are supposed to have huge
> 32bit_processor arrays (128) somehow based
> on FPGAs
> "The core of the XPU128 is an array of 128 parallel Processing Array
>      Elements (PAEs) implemented in advanced, reprogrammable technology."

i hate Javascripts. what do they wanna hide ?

> can it be that wintel might no longer be at the forefront of computing?
> Surely not.

forefront ? no. leader of a captive mass market ? sure :-)
but Linux is unfortunately not the only cure, we'll need more than that.

> Jeff Davies
>

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From jeff davies Wed Oct 11 01:41:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00392 for ; Wed, 11 Oct 2000 15:58:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:55 +0200 (MEST) Received: (qmail 10142 invoked by uid 0); 10 Oct 2000 23:41:28 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 10 Oct 2000 23:41:28 -0000 X-eGroups-Return: sentto-1101623-1161-971221282-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 10 Oct 2000 23:41:27 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 10 Oct 2000 23:41:21 -0000 Received: (qmail 18515 invoked from network); 10 Oct 2000 23:41:21 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 10 Oct 2000 23:41:21 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta2 with SMTP; 10 Oct 2000 23:41:21 -0000 Received: from modem-24.connecticut.dialup.pol.co.uk ([62.137.58.24] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13j91L-0008KD-00 for f-cpu@egroups.com; Wed, 11 Oct 2000 00:41:20 +0100 Sender: root@pop.gmx.net Message-ID: <39E3A946.52F9EAAC@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> From: jeff davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 00:41:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5977ac5029be525f62344bf412f87496 Status: R X-Status: N Yann Guidon wrote:

> As some of you may know, my current peecee runs at 200MHz.
>
> Today, i have _seen_ the monster with which i want to work :
> several cubic meters, hundreds of ASICs and it can simulate
> up to 10M gates at the rate of 1MHz. the ICE probe is in option.
>
> the interview with the EDA vendor was very interesting,
> let's hope that we will _all_ benefit from this.
>
> WHYGEE
>

You bloody tart. Are they going to pay you to work there as well??
Can you smuggle me in in your briefcase (probably not as I weight 100Kg+ ).

Jeff Davies

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
eGroups Sponsor
From Yann Guidon Wed Oct 11 04:09:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00401 for ; Wed, 11 Oct 2000 15:58:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:57 +0200 (MEST) Received: (qmail 2958 invoked by uid 0); 11 Oct 2000 01:05:13 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 11 Oct 2000 01:05:13 -0000 X-eGroups-Return: sentto-1101623-1162-971226300-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 11 Oct 2000 01:05:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 01:04:59 -0000 Received: (qmail 5057 invoked from network); 11 Oct 2000 01:04:59 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 11 Oct 2000 01:04:59 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 11 Oct 2000 01:04:59 -0000 Received: from f-cpu.org (nas3-100.aub.club-internet.fr [195.36.145.100]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA11021 for ; Wed, 11 Oct 2000 03:04:57 +0200 (MET DST) Message-ID: <39E3CBD5.E765860C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> <39E3A946.52F9EAAC@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 03:09:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 887b68f71f43bc965a8956d84b89bdc5 Status: R X-Status: N hi !

jeff davies wrote:
> You bloody tart. Are they going to pay you to work there as well??
they better do it ;-) since i'll probably help them create the next
generation chips...

> Can you smuggle me in in your briefcase (probably not as I weight 100Kg+ ).
soory, but what does that mean ? "smuggle" ?

g'night,
> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 11 04:14:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00404 for ; Wed, 11 Oct 2000 15:58:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:58 +0200 (MEST) Received: (qmail 8675 invoked by uid 0); 11 Oct 2000 01:10:58 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 11 Oct 2000 01:10:58 -0000 X-eGroups-Return: sentto-1101623-1163-971226646-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 11 Oct 2000 01:10:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 01:10:45 -0000 Received: (qmail 1703 invoked from network); 11 Oct 2000 01:10:45 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 11 Oct 2000 01:10:45 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 11 Oct 2000 01:10:45 -0000 Received: from f-cpu.org (nas3-100.aub.club-internet.fr [195.36.145.100]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22765 for ; Wed, 11 Oct 2000 03:10:08 +0200 (MET DST) Message-ID: <39E3CCF0.EDAF8C3C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <777CE7F65CD653AD802569740002428B.0000000000000000@pileser.sumeria> <20001010151229.06879@thrai.stud.uni-hannover.de> <00101019302706.00384@gandalf> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 03:14:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1dbcc3cfdcfb0e37179c930390f114a5 Status: R X-Status: N Jecel :
> People interested in high speed interfaces should check out:
>    http://pasta.stanford.edu:80/hssp/

reading...
thanks for the link !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Marco Al" Wed Oct 11 03:41:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00410 for ; Wed, 11 Oct 2000 15:58:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:58:59 +0200 (MEST) Received: (qmail 19010 invoked by uid 0); 11 Oct 2000 01:36:59 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 11 Oct 2000 01:36:59 -0000 X-eGroups-Return: sentto-1101623-1164-971228216-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 11 Oct 2000 01:36:58 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 01:36:55 -0000 Received: (qmail 11974 invoked from network); 11 Oct 2000 01:36:55 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 01:36:55 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 11 Oct 2000 01:36:54 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id DAA26731 for ; Wed, 11 Oct 2000 03:36:53 +0200 (METDST) Message-ID: <004201c03324$6b397220$29e65982@student.utwente.nl> To: References: <39E3A7A5.61E54EAA@llandre.freeserve.co.uk> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 03:41:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] can't be true can it? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f7a325a3e0aafc7eb0f5d9d0f5d4c16f Status: R X-Status: N From: "jeff davies" <jeff@llandre.freeserve.co.uk>


> 2 off 64 bit MIPS plus 512k cache on a chip running at 1ghz yet only
> consuming 10 watts??
> can this be true?  runs Linux of course.
>
> http://www.sibyte.com/

Wow,

"Enhanced skew-pipelining allows zero load to use penalty -- in other words,
a load instruction can be issued in the same cycle as the ALU instruction
that uses the results of the load, enabling very high integer and floating
point computation rates."

Or in other words, essentially a 32 KB 0 latency dual ported 4 way
associative L1 D-cache... working at up to a GHz. Not only that, the SB-1
core can do 4 floating point MAC's per cycle for a total of 8 GFLOP's and
has a die size of 25mm2 (at 15u I think). All around one of the most
impressive RISC designs out there.

Pity, I remember them having their embedded processor forum presentation on
the site but it seems to be gone.

> and worse still - http://www.pactcorp.com/ are supposed to have huge
> 32bit_processor arrays (128) somehow based
> on FPGAs
> "The core of the XPU128 is an array of 128 parallel Processing Array
>      Elements (PAEs) implemented in advanced, reprogrammable
> technology."

Its a trend. These kind of structures map very well to heavily parallel
tasks, PixelFusion (http://www.pixelfusion.co.uk/) tried to do it for 3D...
but they were a little too far ahead of their time, they are now trying to
retarget it to communications (a common theme...) but I think their ALU's
are too narrow (8 bits, compared to PACT's 32, reasonable for 3D but not so
efficient for other tasks). The OpenRISC 2000 is a little like it too.

Theres a lot of academic interest too, most of you know the TTA approach by
now... a couple more some of you hopefully find interesting and dont know
yet:
http://www.eng.uci.edu/morphosys/morphosys-new/index.html
http://www.cag.lcs.mit.edu/raw/
http://wwwhome.cs.utwente.nl/~havinga/mdpapdir.html#publications (close to
home for me, the FPFA papers are the relevant one's)
http://iacoma.cs.uiuc.edu/flexram/index.html
http://cva.stanford.edu/imagine/project/im_arch.html

Marco
eGroups Sponsor
From Yann Guidon Wed Oct 11 04:41:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00413 for ; Wed, 11 Oct 2000 15:59:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:00 +0200 (MEST) Received: (qmail 31162 invoked by uid 0); 11 Oct 2000 01:37:22 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 11 Oct 2000 01:37:22 -0000 X-eGroups-Return: sentto-1101623-1165-971228233-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 11 Oct 2000 01:37:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 01:37:12 -0000 Received: (qmail 17027 invoked from network); 11 Oct 2000 01:37:12 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 11 Oct 2000 01:37:12 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 11 Oct 2000 01:37:12 -0000 Received: from f-cpu.org (nas2-202.ras.club-internet.fr [195.36.192.202]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA21028 for ; Wed, 11 Oct 2000 03:37:10 +0200 (MET DST) Message-ID: <39E3D356.A0FBC138@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 03:41:26 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] another link Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af0b6ad70e7d1414bd4b90719c5cd779 Status: R X-Status: N damn, i wish i had enough time to read all these papers !!!

http://velox.stanford.edu/cgi-bin/papers.cgi?paper#High-speed links

Michael will certainly like :
M. Santoro and M. Horowitz. SPIM: A pipelined 64x64b iterative multiplier.
IEEE Journal of Solid-State Circuits, April 1989, pages 487-493.
(link : http://mos.stanford.edu/papers/ms_jssc_89.pdf )

g'night,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Rares Marian Wed Oct 11 03:48:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00416 for ; Wed, 11 Oct 2000 15:59:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:00 +0200 (MEST) Received: (qmail 11319 invoked by uid 0); 11 Oct 2000 01:49:46 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 11 Oct 2000 01:49:46 -0000 X-eGroups-Return: sentto-1101623-1166-971228974-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hi.egroups.com with NNFMP; 11 Oct 2000 01:49:38 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 01:49:33 -0000 Received: (qmail 21858 invoked from network); 11 Oct 2000 01:49:33 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 11 Oct 2000 01:49:33 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 11 Oct 2000 01:49:33 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id BD756538FA for ; Tue, 10 Oct 2000 21:48:30 -0400 (EDT) To: f-cpu@egroups.com Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 21:48:30 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] speeding up the Mult/Add Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 33052b7b9fef0fdb5ce8870d4e423a5f Status: R X-Status: N I'm under the impression this is quite like playing dice.

Say you had an 8x8 multiplier with a 16bit result.

Only 1 pair of signals ever modify the LSB in the result.
Similarly 1 pair for the MSB.

Now if you were to wire the thing so that only those pairs that could add
up to target bits are ever considered, then you could have a
much smaller multiplier.

The idea is:

bit in result      bit1 sources       bit2 sources  carry sources (to do)
0            0            0

1            1            0
            0            1

2            2            0
            1            1
            0            2

3            3            0
            2            1
            1            2
            0            3

4            4            0
            3            1
            2            2
            1            3
            0            4

5            5            0
            4            1
            3            2
            2            3
            1            4
            0            5

6            6            0
            5            1
            4            2
            3            3
            2            4
            1            5
            0            6
                       
7            7            0
            6            1
            5            2
            4            3
            3            4
            2            5
            1            6
            0            7

8            7            1
            6            2
            5            3
            4            4
            3            5
            2            6
            1            7

9            7            2
            6            3
            5            4
            4            5
            3            6
            2            7

10            7            3
            6            4
            5            5
            4            6
            3            7
                                   
11            7            4
            6            5
            5            6
            4            7

12            7            5
            6            6
            5            7

13            7            6
            6            7

14            7            7

15            this only gets affected by carries

Taking this model you will have to consider the carry between the groups.

Strategy:

Couple the groups and their carry together into adders.  Tricky but it
should work. 

Have a latch that opens whenever all the 1 have been taken care of.  Try
to skip zeros.

Cache previous results?  No repeating pairs, can't cache. :/

Wire the adders together in some way.

This could cut time and size considerably.

Rares - your friendly mad scientist

Copyright 2000 Rares Marian
eGroups Sponsor
From "Richard E.Hartney" Wed Oct 11 06:02:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00419 for ; Wed, 11 Oct 2000 15:59:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:03 +0200 (MEST) Received: (qmail 4480 invoked by uid 0); 11 Oct 2000 04:01:26 -0000 Received: from ej.egroups.com (208.50.144.75) by mx0.gmx.net with SMTP; 11 Oct 2000 04:01:26 -0000 X-eGroups-Return: sentto-1101623-1167-971236878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 11 Oct 2000 04:01:25 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 04:01:18 -0000 Received: (qmail 29817 invoked from network); 11 Oct 2000 04:01:17 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Oct 2000 04:01:17 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta2 with SMTP; 11 Oct 2000 04:01:17 -0000 Received: from 0018728164 (host-209-215-24-211.bix.bellsouth.net [209.215.24.211]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id AAA09415; Wed, 11 Oct 2000 00:01:15 -0400 (EDT) Message-ID: <002a01c03338$12149da0$d318d7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Oct 2000 23:02:25 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] MUL/DIV Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C0330E.27EEE420" X-UIDL: ff607b4f947fa624355a2ded15ec2dfa Status: R X-Status: N ------=_NextPart_000_0027_01C0330E.27EEE420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Someone finally took my cue. Skip strings of one's and zero's in Multiply = and Divide. Variable length execution - but so what????? Hartney ------=_NextPart_000_0027_01C0330E.27EEE420 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Someone finally took my cue.  Skip strings of one's and zero's in Multiply and
Divide.  Variable length execution - but so what?????
 
Hartney

eGroups Sponsor
------=_NextPart_000_0027_01C0330E.27EEE420-- From Nicolas Matringe Wed Oct 11 09:40:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00425 for ; Wed, 11 Oct 2000 15:59:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:04 +0200 (MEST) Received: (qmail 14889 invoked by uid 0); 11 Oct 2000 07:39:50 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 11 Oct 2000 07:39:50 -0000 X-eGroups-Return: sentto-1101623-1168-971249984-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 11 Oct 2000 07:39:45 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 07:39:43 -0000 Received: (qmail 16480 invoked from network); 11 Oct 2000 07:39:43 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 07:39:43 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 11 Oct 2000 07:39:43 -0000 Received: from IPricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA01969 for ; Wed, 11 Oct 2000 07:39:41 GMT X-To: Message-ID: <39E4196C.52106BAB@IPricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 09:40:28 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: deeb476ab13fbce8d50f534f50d9e365 Status: R X-Status: N Yann Guidon a =E9crit :
>
> As some of you may know, my current peecee runs at 200MHz.
>
> Today, i have _seen_ the monster with which i want to work :
> several cubic meters, hundreds of ASICs and it can simulate
> up to 10M gates at the rate of 1MHz. the ICE probe is in option.
>
> the interview with the EDA vendor was very interesting,
> let's hope that we will _all_ benefit from this.

Hey! Where did you see that thing?
I really have to have a look at that! ;o)

--
Nicolas MATRINGE          = ; IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor=
3D""
From Vanderhoeven Steve Wed Oct 11 10:47:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00443 for ; Wed, 11 Oct 2000 15:59:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:07 +0200 (MEST) Received: (qmail 20401 invoked by uid 0); 11 Oct 2000 08:47:53 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 11 Oct 2000 08:47:53 -0000 X-eGroups-Return: sentto-1101623-1169-971254068-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 11 Oct 2000 08:47:49 -0000 X-Sender: vanderho@ariel.essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 08:47:48 -0000 Received: (qmail 24986 invoked from network); 11 Oct 2000 08:47:48 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 08:47:48 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta3 with SMTP; 11 Oct 2000 08:47:47 -0000 Received: from ariel.essi.fr (ariel.essi.fr [157.169.5.31]) by essi.essi.fr (8.11.0/8.11.0) with ESMTP id e9B8lIo23793; Wed, 11 Oct 2000 10:47:19 +0200 (MET DST) Message-Id: <200010110847.e9B8lIo23793@essi.essi.fr> X-Mailer: exmh version 2.0.2 2/24/98 To: f-cpu@egroups.com Cc: vanderho@essi.essi.fr In-reply-to: Your message of "Tue, 10 Oct 2000 15:12:29 +0200." <20001010151229.06879@thrai.stud.uni-hannover.de> From: Vanderhoeven Steve MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 10:47:11 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1f00444d9c83be4e8beb76564ad06a60 Status: R X-Status: N >> >That would run out of sync quickly.
>>
>> How so? The RAM chip times the bits from the starting edge of the start bit
>> on each line individually - like 128 off UART, one for every line coming to
>> the ram chip.
>> Each line is self -syncing to the start of it's packet. How can it run out
>> of sync ever?
>
>Asynchronous transfer may be fine with small packets at 19200 Baud.
>At 100 MHz, a bit is only 10ns long, and timing isn't accurate any longer.

... why not dubling the number of wires... instead of one wire you have a
pair, and each time you send data on one wire you set a +1 and on the other a
-1.
So the equivalent of on a simple wire  0 or 1 is on wich wire the +1 is.

So here you don't need any more a ground. if the pairs are close the
association of +1 and -1 limits the electrical influence on the other wires.
And the signal it self can be it's clock.

This is the solution used by scsi.
eGroups Sponsor
From Michael Riepe Wed Oct 11 05:00:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00449 for ; Wed, 11 Oct 2000 15:59:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:09 +0200 (MEST) Received: (qmail 15828 invoked by uid 0); 11 Oct 2000 11:20:01 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 11 Oct 2000 11:20:01 -0000 X-eGroups-Return: sentto-1101623-1170-971263197-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 11 Oct 2000 11:20:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 11:19:56 -0000 Received: (qmail 25521 invoked from network); 11 Oct 2000 11:19:56 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Oct 2000 11:19:56 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta1 with SMTP; 11 Oct 2000 11:19:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA01695; Wed, 11 Oct 2000 05:00:14 +0200 Message-ID: <20001011050014.22162@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39E3D356.A0FBC138@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E3D356.A0FBC138@f-cpu.org>; from Yann Guidon on Wed, Oct 11, 2000 at 03:41:26AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 05:00:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] another link Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ccaef72828d2d7343f3c92b38e2af3d Status: R X-Status: N On Wed, Oct 11, 2000 at 03:41:26AM +0100, Yann Guidon wrote:
> damn, i wish i had enough time to read all these papers !!!

*sigh*

> Michael will certainly like :
> M. Santoro and M. Horowitz. SPIM: A pipelined 64x64b iterative multiplier.
> IEEE Journal of Solid-State Circuits, April 1989, pages 487-493.
> (link : http://mos.stanford.edu/papers/ms_jssc_89.pdf )

Should I read it before or after I have finished the IMUL unit? ;)

There are too many papers in the world...  Instead of writing a paper
about my multiplier, I should draw the schematics and print them on
the back side of a t-shirt.  And if anybody asks for documentation,
I can simply turn around...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 11 04:26:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00452 for ; Wed, 11 Oct 2000 15:59:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:10 +0200 (MEST) Received: (qmail 1433 invoked by uid 0); 11 Oct 2000 11:20:09 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 11 Oct 2000 11:20:09 -0000 X-eGroups-Return: sentto-1101623-1172-971263203-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mr.egroups.com with NNFMP; 11 Oct 2000 11:20:08 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 11:20:03 -0000 Received: (qmail 849 invoked from network); 11 Oct 2000 11:20:03 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Oct 2000 11:20:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta1 with SMTP; 11 Oct 2000 11:20:02 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01596; Wed, 11 Oct 2000 04:26:28 +0200 Message-ID: <20001011042628.46357@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E3B6A2.2520797F@f-cpu.org>; from Yann Guidon on Wed, Oct 11, 2000 at 01:38:58AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 04:26:28 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dbe4e9ab4bc73aab6b35efa2eded840d Status: R X-Status: N On Wed, Oct 11, 2000 at 01:38:58AM +0100, Yann Guidon wrote:
> As some of you may know, my current peecee runs at 200MHz.
>
> Today, i have _seen_ the monster with which i want to work :
> several cubic meters, hundreds of ASICs and it can simulate
> up to 10M gates at the rate of 1MHz. the ICE probe is in option.

Fine.  That beast will run an exhaustive test of the 64-bit multiplier
in slightly more than 584554 years.  Only 584 and a half year if 1000
of them fit into the box.  Assuming the cleaningwoman doesn't pull the
wrong plug, of course ;)

Maybe we should start the `f-cpu@home' project...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 11 04:18:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00455 for ; Wed, 11 Oct 2000 15:59:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:10 +0200 (MEST) Received: (qmail 7190 invoked by uid 0); 11 Oct 2000 11:20:11 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 11 Oct 2000 11:20:11 -0000 X-eGroups-Return: sentto-1101623-1173-971263206-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 11 Oct 2000 11:20:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 11:20:06 -0000 Received: (qmail 26560 invoked from network); 11 Oct 2000 11:20:06 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 11 Oct 2000 11:20:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta1 with SMTP; 11 Oct 2000 11:20:04 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01568; Wed, 11 Oct 2000 04:18:09 +0200 Message-ID: <20001011041808.48195@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Rares Marian on Tue, Oct 10, 2000 at 09:48:30PM -0400 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 04:18:08 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] speeding up the Mult/Add Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 966f84cfa70c7ad65ece74569153ce92 Status: R X-Status: N On Tue, Oct 10, 2000 at 09:48:30PM -0400, Rares Marian wrote:
> I'm under the impression this is quite like playing dice.

Didn't Einstein say something about playing dice...? ;)

> Say you had an 8x8 multiplier with a 16bit result.
>
> Only 1 pair of signals ever modify the LSB in the result.
> Similarly 1 pair for the MSB.
>
> Now if you were to wire the thing so that only those pairs that could add
> up to target bits are ever considered, then you could have a
> much smaller multiplier.
>
> The idea is:
[long ascii art deleted]

Looks very much like a carry-save multiplier.
Have you read http://www.andraka.com/multipli.htm?

I considered a similar version, but it's slow.  We could put at most
two rows into one pipeline stage, and we still need an adder for the
high part of the result (mulh instruction); that means we need 6 stages
for 8x8 signed/unsigned multiplication.  My multiplier (which can be
optimized in a similar way, if you like to) takes only 3 cycles.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 11 04:46:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00458 for ; Wed, 11 Oct 2000 15:59:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 15:59:11 +0200 (MEST) Received: (qmail 26843 invoked by uid 0); 11 Oct 2000 11:21:18 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 11 Oct 2000 11:21:18 -0000 X-eGroups-Return: sentto-1101623-1171-971263200-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 11 Oct 2000 11:21:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 11:20:00 -0000 Received: (qmail 722 invoked from network); 11 Oct 2000 11:20:00 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 11 Oct 2000 11:20:00 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta1 with SMTP; 11 Oct 2000 11:19:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01655; Wed, 11 Oct 2000 04:46:15 +0200 Message-ID: <20001011044615.62058@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001010050452.51221@thrai.stud.uni-hannover.de> <39E3B69C.4E1B53CA@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E3B69C.4E1B53CA@f-cpu.org>; from Yann Guidon on Wed, Oct 11, 2000 at 01:38:52AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 04:46:15 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] multiplier, take #3 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 072d5f5e26c9e421b1ae6f87f18226da Status: R X-Status: N On Wed, Oct 11, 2000 at 01:38:52AM +0100, Yann Guidon wrote:

> Damn, this is getting really crazy :-)

Do you think?  You wanted a free CPU, you get it ;)

> A good documentation (some pages of HTML for example) would
> probably kill the magic, but that would certainly help people
> use your design. The documentation would be included in the
> F-CPU/FC0 manual.

Please wait until the 64-bit unit is ready.  I had to change the
interface of the 8x8 unit again to work out some signedness issues (I
really want to make the final stages as simple, clean and modular as
I can).

> One cool thing, anyway : the MAC instruction can be used with
> Michael's design. let's see now if there is a problem with
> fractional/fixed point flags.

Fractional numbers and SIMD together might be a problem.  I will think
about it when I have the 64-bit multiplier running (maybe tomorrow).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Wed Oct 11 18:05:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02469 for ; Wed, 11 Oct 2000 23:02:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:40 +0200 (MEST) Received: (qmail 637 invoked by uid 0); 11 Oct 2000 15:03:42 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 11 Oct 2000 15:03:42 -0000 X-eGroups-Return: sentto-1101623-1174-971276604-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 11 Oct 2000 15:03:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 15:03:23 -0000 Received: (qmail 24490 invoked from network); 11 Oct 2000 15:00:46 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 15:00:46 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 11 Oct 2000 15:00:46 -0000 Received: from f-cpu.org (nas4-136.aub.club-internet.fr [195.36.145.136]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA24923 for ; Wed, 11 Oct 2000 17:00:42 +0200 (MET DST) Message-ID: <39E48FB5.C0BB09B8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <002a01c03338$12149da0$d318d7d1@0018728164> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 17:05:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MUL/DIV Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4fe3f33f839fac8bd6cf1fa103745a89 Status: R X-Status: N hi !

> "Richard E.Hartney" wrote:
>
> Someone finally took my cue.  Skip strings of one's and zero's in Multiply and
> Divide.  Variable length execution - but so what?????

there are not thousands of ways to speedup such operations, except
the recent SRT algorithm used for the Pentium for example. Booth
and similar techniques are to be used at one point or another.

Anyway, i have nothing personal against "Variable length execution"
but in our case, there are two issues :
- 1) scheduling (you were aware of this) : we allocate the
write ports of the Xbar/register set with a FIFO, and the position
in the FIFO must be known at decode time. otherwise the decoder
gets really annoying to design.
- 2) another argument i had forgotten : predictability.
it is highly desirable to know how many cycles a piece of code
will use, simply by looking at the code. Of course, the external
memory is highly unpredictable but the instructions that refer
to memory are completely different.

To use a "Variable length execution" IMUL/IDIV unit "safely",
we would have to use a TTA approach : one instruction brings
the operands and another instruction moves the results around.
You see, i don't burry TTA, i still think that a F-CPU ISA front-end
for a very large TTA engine could do wonders ;-)

regards,
> Hartney
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 11 18:05:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02472 for ; Wed, 11 Oct 2000 23:02:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:41 +0200 (MEST) Received: (qmail 18277 invoked by uid 0); 11 Oct 2000 15:08:03 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 11 Oct 2000 15:08:03 -0000 X-eGroups-Return: sentto-1101623-1175-971276860-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fk.egroups.com with NNFMP; 11 Oct 2000 15:07:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 15:07:40 -0000 Received: (qmail 30980 invoked from network); 11 Oct 2000 15:00:56 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Oct 2000 15:00:56 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 11 Oct 2000 15:00:55 -0000 Received: from f-cpu.org (nas4-136.aub.club-internet.fr [195.36.145.136]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA08903 for ; Wed, 11 Oct 2000 17:00:51 +0200 (MET DST) Message-ID: <39E48FBD.95C45E02@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> <20001011042628.46357@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 17:05:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy + misc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: abfaaac606ec26110a44ff3fe727e266 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Wed, Oct 11, 2000 at 01:38:58AM +0100, Yann Guidon wrote:
> > As some of you may know, my current peecee runs at 200MHz.
> >
> > Today, i have _seen_ the monster with which i want to work :
> > several cubic meters, hundreds of ASICs and it can simulate
> > up to 10M gates at the rate of 1MHz. the ICE probe is in option.
>
> Fine.  That beast will run an exhaustive test of the 64-bit multiplier
> in slightly more than 584554 years.  Only 584 and a half year if 1000
> of them fit into the box.  Assuming the cleaningwoman doesn't pull the
> wrong plug, of course ;)

hhmmm i don't think that your multiplier takes 10M gates, so we can run
multiple instances of it in parallel.

> Maybe we should start the `f-cpu@home' project...
is it really so useful ? :-D


Michael Riepe wrote:
> On Wed, Oct 11, 2000 at 03:41:26AM +0100, Yann Guidon wrote:
> > damn, i wish i had enough time to read all these papers !!!
> *sigh*
*amen*

> > Michael will certainly like :
> > M. Santoro and M. Horowitz. SPIM: A pipelined 64x64b iterative multiplier.
> > IEEE Journal of Solid-State Circuits, April 1989, pages 487-493.
> > (link : http://mos.stanford.edu/papers/ms_jssc_89.pdf )
> Should I read it before or after I have finished the IMUL unit? ;)
it's as you like :-)

> There are too many papers in the world...  Instead of writing a paper
> about my multiplier, I should draw the schematics and print them on
> the back side of a t-shirt.  And if anybody asks for documentation,
> I can simply turn around...
wow, you're "fit" today, did you eat a clown for your breakfeast ? :-DD

(about the multiplier :)
Michael Riepe wrote:
> On Wed, Oct 11, 2000 at 01:38:52AM +0100, Yann Guidon wrote:
> > Damn, this is getting really crazy :-)
> Do you think?  You wanted a free CPU, you get it ;)
hey, i'm not the only one to want it ;-)

> > A good documentation (some pages of HTML for example) would
> > probably kill the magic, but that would certainly help people
> > use your design. The documentation would be included in the
> > F-CPU/FC0 manual.
> Please wait until the 64-bit unit is ready.
ok, i'm patient.

>  I had to change the interface of the 8x8 unit again to work out
> some signedness issues (I really want to make the final stages as
> simple, clean and modular as I can).
ok, i trust you :-)

> > One cool thing, anyway : the MAC instruction can be used with
> > Michael's design. let's see now if there is a problem with
> > fractional/fixed point flags.
> Fractional numbers and SIMD together might be a problem.
ah ? what problem ? what are the possible solutions ?

>  I will think about it when I have the 64-bit multiplier
> running (maybe tomorrow).
THAT is FAST :-)

> > > > > > What is your plan for the next stages ?
> > > 8x8+16 -> 3 cycles
> > > 16x16+32 -> 5 cycles
> > > 32x32+64 -> 7 cycles
> > > 64x64+64 -> 9 or 10 cycles
> > yummy yummy :-)))
> > i hope that you'll succeed because it looks too good to
> > be true ;-)
> There's still a murphy factor of one or two cycles.
if you can make tighter stages, it won't hurt a lot
to have more latency : because it will run faster, so don't
be afraid.

> > > > This means that the Xbar will need 4 inputs from the IMUL unit if
> > > > we want to feed one operation of any size at each cycle. This could
> > > > be reduced to 2 ports anyway (the 2W limitation) but i don't want
> > > > to think about it now, i gotta finish the Icache.
> > > Don't forget that it also does `widening' multiplications -- that
> > > means 3 input + 8 output ports.
> > i don't get it. i'm probably too worried or tired. can you explain
> > more clearly ?
> I referred to the `mulh' instruction which needs two register writes
> (2r2w), and two output ports per stage.
oh yeah, 4 results (pipe stages with output) and 2 words each.
this makes 8 results, right :-)

> [signed-magnitude fractional numbers]
> > > This is actually 7x7->14 unsigned multiplication plus a shift, and an
> > > xor for the sign bit.  If we route the sign bits separately, this should
> > > not be a problem.
> > cool :-) i gotta check if we have a provision for this operation in the
> > instruction set census.
> Shouldn't that be a separate instruction?
> BTW: does this have to be SIMD?
for SIMD, the answer is "Of course" :-)
as for a separate instruction, this is more difficult to answer.
we gotta all brainstorm ...

> > For the multiplier, for example, we can define SRs (Special Registers)
> > that can spy the partial results. To run a test, we can send a multiply
> > instruction and read all the partial results with the different SRs.
> > If 64*64 takes 10 cycles, we need 10 SRs. Then the problem is to determine
> > what data should be used to test all the combinations, exhaustively but
> > without redundancy. heck.
> You mean, registers that are accessible in software?
> What about boundary scan?
boundary scan is slow, but it can be used during the burning tests
to upload a SW in the caches. The SW will contain other test vectors that
will run like a BIST (Built-In Self Test). This SW will test the all the
operations and instructions, compare the results with the vectors and
will report the errors. it will run faster than boundary scan because
SW executes in parallel, while JTAG uses a serial link. Well, we can of course
use JTAG/etc for the first preliminary tests but units like the multiplier
will need more vectors and speed than that.

>  Michael "witty" Riepe
WHYGEE (who just woke up and enjoy a laugh or two when reading his mails)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "STARGATE COMPONENTS" Wed Oct 11 17:19:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02481 for ; Wed, 11 Oct 2000 23:02:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:43 +0200 (MEST) Received: (qmail 20741 invoked by uid 0); 11 Oct 2000 15:18:08 -0000 Received: from hm.egroups.com (208.50.99.198) by mx06.rz2.gmx.net with SMTP; 11 Oct 2000 15:18:08 -0000 X-eGroups-Return: sentto-1101623-1176-971277449-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 11 Oct 2000 15:18:03 -0000 X-Sender: amritag1@earthlink.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 15:17:29 -0000 Received: (qmail 27222 invoked from network); 11 Oct 2000 15:17:28 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 15:17:28 -0000 Received: from unknown (HELO harrier.prod.itd.earthlink.net) (207.217.121.12) by mta3 with SMTP; 11 Oct 2000 15:17:28 -0000 Received: from oemcomputer (user-33qtheu.dialup.mindspring.com [199.174.197.222]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id IAA19578 for ; Wed, 11 Oct 2000 08:17:25 -0700 (PDT) Message-ID: <005101c03396$985fcca0$39cdaec7@oemcomputer> To: References: <39E3B6A2.2520797F@f-cpu.org> <20001011042628.46357@thrai.stud.uni-hannover.de> <39E48FBD.95C45E02@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "STARGATE COMPONENTS" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 08:19:04 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 92e0963a966b7c95e2dfcaf22701eef4 Status: R X-Status: N
----- Original Message -----
From: "Yann Guidon" <whygee@f-cpu.org>
To: <f-cpu@egroups.com>
Sent: Wednesday, October 11, 2000 9:05 AM
Subject: Re: [f-cpu] My next toy + misc.


> hi !
>
> Michael Riepe wrote:
> > On Wed, Oct 11, 2000 at 01:38:58AM +0100, Yann Guidon wrote:
> > > As some of you may know, my current peecee runs at 200MHz.
> > >
> > > Today, i have _seen_ the monster with which i want to work :
> > > several cubic meters, hundreds of ASICs and it can simulate
> > > up to 10M gates at the rate of 1MHz. the ICE probe is in option.
> >
> > Fine.  That beast will run an exhaustive test of the 64-bit multiplier
> > in slightly more than 584554 years.  Only 584 and a half year if 1000
> > of them fit into the box.  Assuming the cleaningwoman doesn't pull the
> > wrong plug, of course ;)
>
> hhmmm i don't think that your multiplier takes 10M gates, so we can run
> multiple instances of it in parallel.
>
> > Maybe we should start the `f-cpu@home' project...
> is it really so useful ? :-D
>
>
> Michael Riepe wrote:
> > On Wed, Oct 11, 2000 at 03:41:26AM +0100, Yann Guidon wrote:
> > > damn, i wish i had enough time to read all these papers !!!
> > *sigh*
> *amen*
>
> > > Michael will certainly like :
> > > M. Santoro and M. Horowitz. SPIM: A pipelined 64x64b iterative
multiplier.
> > > IEEE Journal of Solid-State Circuits, April 1989, pages 487-493.
> > > (link : http://mos.stanford.edu/papers/ms_jssc_89.pdf )
> > Should I read it before or after I have finished the IMUL unit? ;)
> it's as you like :-)
>
> > There are too many papers in the world...  Instead of writing a paper
> > about my multiplier, I should draw the schematics and print them on
> > the back side of a t-shirt.  And if anybody asks for documentation,
> > I can simply turn around...
> wow, you're "fit" today, did you eat a clown for your breakfeast ? :-DD
>
> (about the multiplier :)
> Michael Riepe wrote:
> > On Wed, Oct 11, 2000 at 01:38:52AM +0100, Yann Guidon wrote:
> > > Damn, this is getting really crazy :-)
> > Do you think?  You wanted a free CPU, you get it ;)
> hey, i'm not the only one to want it ;-)
>
> > > A good documentation (some pages of HTML for example) would
> > > probably kill the magic, but that would certainly help people
> > > use your design. The documentation would be included in the
> > > F-CPU/FC0 manual.
> > Please wait until the 64-bit unit is ready.
> ok, i'm patient.
>
> >  I had to change the interface of the 8x8 unit again to work out
> > some signedness issues (I really want to make the final stages as
> > simple, clean and modular as I can).
> ok, i trust you :-)
>
> > > One cool thing, anyway : the MAC instruction can be used with
> > > Michael's design. let's see now if there is a problem with
> > > fractional/fixed point flags.
> > Fractional numbers and SIMD together might be a problem.
> ah ? what problem ? what are the possible solutions ?
>
> >  I will think about it when I have the 64-bit multiplier
> > running (maybe tomorrow).
> THAT is FAST :-)
>
> > > > > > > What is your plan for the next stages ?
> > > > 8x8+16 -> 3 cycles
> > > > 16x16+32 -> 5 cycles
> > > > 32x32+64 -> 7 cycles
> > > > 64x64+64 -> 9 or 10 cycles
> > > yummy yummy :-)))
> > > i hope that you'll succeed because it looks too good to
> > > be true ;-)
> > There's still a murphy factor of one or two cycles.
> if you can make tighter stages, it won't hurt a lot
> to have more latency : because it will run faster, so don't
> be afraid.
>
> > > > > This means that the Xbar will need 4 inputs from the IMUL unit if
> > > > > we want to feed one operation of any size at each cycle. This
could
> > > > > be reduced to 2 ports anyway (the 2W limitation) but i don't want
> > > > > to think about it now, i gotta finish the Icache.
> > > > Don't forget that it also does `widening' multiplications -- that
> > > > means 3 input + 8 output ports.
> > > i don't get it. i'm probably too worried or tired. can you explain
> > > more clearly ?
> > I referred to the `mulh' instruction which needs two register writes
> > (2r2w), and two output ports per stage.
> oh yeah, 4 results (pipe stages with output) and 2 words each.
> this makes 8 results, right :-)
>
> > [signed-magnitude fractional numbers]
> > > > This is actually 7x7->14 unsigned multiplication plus a shift, and
an
> > > > xor for the sign bit.  If we route the sign bits separately, this
should
> > > > not be a problem.
> > > cool :-) i gotta check if we have a provision for this operation in
the
> > > instruction set census.
> > Shouldn't that be a separate instruction?
> > BTW: does this have to be SIMD?
> for SIMD, the answer is "Of course" :-)
> as for a separate instruction, this is more difficult to answer.
> we gotta all brainstorm ...
>
> > > For the multiplier, for example, we can define SRs (Special Registers)
> > > that can spy the partial results. To run a test, we can send a
multiply
> > > instruction and read all the partial results with the different SRs.
> > > If 64*64 takes 10 cycles, we need 10 SRs. Then the problem is to
determine
> > > what data should be used to test all the combinations, exhaustively
but
> > > without redundancy. heck.
> > You mean, registers that are accessible in software?
> > What about boundary scan?
> boundary scan is slow, but it can be used during the burning tests
> to upload a SW in the caches. The SW will contain other test vectors that
> will run like a BIST (Built-In Self Test). This SW will test the all the
> operations and instructions, compare the results with the vectors and
> will report the errors. it will run faster than boundary scan because
> SW executes in parallel, while JTAG uses a serial link. Well, we can of
course
> use JTAG/etc for the first preliminary tests but units like the multiplier
> will need more vectors and speed than that.
>
> >  Michael "witty" Riepe
> WHYGEE (who just woke up and enjoy a laugh or two when reading his mails)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>

 From Yann Guidon Wed Oct 11 18:46:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02487 for ; Wed, 11 Oct 2000 23:02:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:45 +0200 (MEST) Received: (qmail 7484 invoked by uid 0); 11 Oct 2000 15:53:25 -0000 Received: from ef.egroups.com (208.50.144.95) by mx0.gmx.net with SMTP; 11 Oct 2000 15:53:25 -0000 X-eGroups-Return: sentto-1101623-1177-971279600-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ef.egroups.com with NNFMP; 11 Oct 2000 15:53:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 15:53:18 -0000 Received: (qmail 8063 invoked from network); 11 Oct 2000 15:41:43 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 11 Oct 2000 15:41:43 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 11 Oct 2000 15:41:38 -0000 Received: from f-cpu.org (nas4-99.ras.club-internet.fr [195.36.203.99]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA27850; Wed, 11 Oct 2000 17:41:34 +0200 (MET DST) Message-ID: <39E4994C.2BB12850@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com, STARGATE COMPONENTS References: <39E3B6A2.2520797F@f-cpu.org> <20001011042628.46357@thrai.stud.uni-hannover.de> <39E48FBD.95C45E02@f-cpu.org> <005101c03396$985fcca0$39cdaec7@oemcomputer> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 17:46:04 +0100 Reply-To: f-cpu@egroups.com Subject: UNSUBSCRIPTIONs (aws : Re: [f-cpu] REMOVE ME) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a7e027c071c4a61096648948425889c6 Status: R X-Status: N oh no !!!
here we go again...

NOBODY CAN REMOVE ANYBODY.
IF YOU WANT TO UNSUBSCRIBE, READ THE SUBSCRIPTION
CONFIRMATION MAIL THAT WAS SENT TO YOU BY THE eGROUPS
MAIL SERVER.

IF YOU HAVE REMOVED IT, SEND A MESSAGE
TO f-cpu-unsubscribe@egroups.com (THIS IS AUTOMATED,
NOBODY WILL ANSWER QUESTIONS EITHER).

PLEASE BE MORE RESPONSIBLE... THE LIST MANAGERS HAVE
GONE FOR A VERY LONG TIME.

STARGATE COMPONENTS wrote:
<snip>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Marco Al" Wed Oct 11 20:58:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02511 for ; Wed, 11 Oct 2000 23:02:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:51 +0200 (MEST) Received: (qmail 27467 invoked by uid 0); 11 Oct 2000 18:53:47 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 11 Oct 2000 18:53:47 -0000 X-eGroups-Return: sentto-1101623-1178-971290395-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 11 Oct 2000 18:53:40 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 18:53:15 -0000 Received: (qmail 24303 invoked from network); 11 Oct 2000 18:53:14 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Oct 2000 18:53:14 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 11 Oct 2000 18:53:14 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id UAA03296 for ; Wed, 11 Oct 2000 20:53:12 +0200 (METDST) Message-ID: <003001c033b5$31e93c80$29e65982@student.utwente.nl> To: References: <200010110847.e9B8lIo23793@essi.essi.fr> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 20:58:07 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 65597fe072c0d42083820799469dc400 Status: R X-Status: N From: "Vanderhoeven Steve" <vanderho@essi.fr>


> ... why not dubling the number of wires... instead of one wire you have a
> pair, and each time you send data on one wire you set a +1 and on the
other a
> -1.
> So the equivalent of on a simple wire  0 or 1 is on wich wire the +1 is.

Its still a binary signal though, you still need a clock. Differential
signalling is nice though, the Elbrus people even want to use it on chip.

Marco
eGroups Sponsor
From Rares Marian Wed Oct 11 21:42:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02514 for ; Wed, 11 Oct 2000 23:02:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:51 +0200 (MEST) Received: (qmail 19660 invoked by uid 0); 11 Oct 2000 19:43:08 -0000 Received: from jj.egroups.com (208.50.144.82) by mx11.rz2.gmx.net with SMTP; 11 Oct 2000 19:43:08 -0000 X-eGroups-Return: sentto-1101623-1179-971293382-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 11 Oct 2000 19:43:03 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 19:43:02 -0000 Received: (qmail 12947 invoked from network); 11 Oct 2000 19:43:02 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 11 Oct 2000 19:43:02 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 11 Oct 2000 19:43:01 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 4C6CB538FA for ; Wed, 11 Oct 2000 15:42:03 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <39E48FB5.C0BB09B8@f-cpu.org> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 15:42:01 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MUL/DIV Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4d402826ee0b623ed1d7fd11acd48b5f Status: R X-Status: N On Wed, 11 Oct 2000, Yann Guidon wrote:

> hi !
>
> > "Richard E.Hartney" wrote:
> >
> > Someone finally took my cue.  Skip strings of one's and zero's in Multiply and
> > Divide.  Variable length execution - but so what?????

I claim originality :)

> - 1) scheduling (you were aware of this) : we allocate the
> write ports of the Xbar/register set with a FIFO, and the position
> in the FIFO must be known at decode time. otherwise the decoder
> gets really annoying to design.

I can see a problem there, but...

> - 2) another argument i had forgotten : predictability.
> it is highly desirable to know how many cycles a piece of code
> will use, simply by looking at the code. Of course, the external
> memory is highly unpredictable but the instructions that refer
> to memory are completely different.

You can tell how long it takes by the number of 1s there are in the bit
strings.  It is that precise.

> To use a "Variable length execution" IMUL/IDIV unit "safely",
> we would have to use a TTA approach : one instruction brings
> the operands and another instruction moves the results around.
> You see, i don't burry TTA, i still think that a F-CPU ISA front-end
> for a very large TTA engine could do wonders ;-)

I don't think you would need an extra instruction.  The way I see it you
could break up the process into two parts.

0.  Find the exec times depending on how many ones there are in the bit
strings.  Calculate the trade off of multiplying with a number that has
fewer ones and adjusting the result to the real value later. 

I think you'll find many (theoretically 2^n/n*k.avg) situations where
it's cheaper to pretend you're calculating something you're not and then
fix it later.

1. One system does the "denormalization".

2. The other does the "renormalization".

3. If the rules of "denormalization" are consistent, then these systems
can be independent since all you need is the original operands.  You
design the renormalization system according to the rules of the other.

4. Further optimization is possible even in the denormalization steps of
both systems.  Some numbers just denormalize faster :)  Finally, this
means the skip 0s trick needs to be as simple as possible.  Like some sort
of micro clocking thing that literally skips micro cycles on 0.

Granted this a little crazy.  You'll have a mult that does its own things
behind the scenes.  I know the original rule was don't do implicit
things.  It's the center of our universe it should all be explicit
since that encourages genericity provided the programmer is clever
enough.  I argue that something that is generic to begin with can be
implicit, that is behind the scenes.

I'll name this shade/unshade after one of the most useful window
management features I have seen.

The only caveat is: This seems cool only because these sorts of tricks are
how human beings do things by eyeballing.  Computers aren't even close to
being able to eyeball so these tricks may cause the system to become
slower. 

As we all know evrything gets easy when we get fiber optic
technology worked out but we're not doing that.

Anyway it looks like this:

#include multaddspeedupbybittargets.h ; it's in my last post

Stage 0 - get operands

Stage 1 - split into two identical streams

Stage 2a - according to "The Rules" adjust mult stream to operands that
multiply faster. 

Stage 2b - according to "the rules" based on "The Rules" adjust the
renorm operands to correct the "error".

Stage 3 - Calculate both sides

Stage 4 - Fix the error

Stage oo - output

Just balance the speed of both streams and you're fine.

> regards,
> > Hartney
> WHYGEE

Rares
eGroups Sponsor
From Rares Marian Wed Oct 11 21:55:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02520 for ; Wed, 11 Oct 2000 23:02:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Oct 2000 23:02:53 +0200 (MEST) Received: (qmail 15943 invoked by uid 0); 11 Oct 2000 19:58:06 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 11 Oct 2000 19:58:06 -0000 X-eGroups-Return: sentto-1101623-1180-971294279-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fl.egroups.com with NNFMP; 11 Oct 2000 19:58:05 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 19:57:59 -0000 Received: (qmail 10603 invoked from network); 11 Oct 2000 19:56:18 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 11 Oct 2000 19:56:18 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 11 Oct 2000 19:56:18 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id ED157538FA for ; Wed, 11 Oct 2000 15:55:19 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <20001011041808.48195@thrai.stud.uni-hannover.de> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 15:55:18 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] speeding up the Mult/Add Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0e63349787d45983e3b7e3ab9bc0a35e Status: R X-Status: N On Wed, 11 Oct 2000, Michael Riepe wrote:

> On Tue, Oct 10, 2000 at 09:48:30PM -0400, Rares Marian wrote:
> > I'm under the impression this is quite like playing dice.
>
> Didn't Einstein say something about playing dice...? ;)
>
> > Say you had an 8x8 multiplier with a 16bit result.
> >
> > Only 1 pair of signals ever modify the LSB in the result.
> > Similarly 1 pair for the MSB.
> >
> > Now if you were to wire the thing so that only those pairs that could add
> > up to target bits are ever considered, then you could have a
> > much smaller multiplier.
> >
> > The idea is:
> [long ascii art deleted]

Heh.

> Looks very much like a carry-save multiplier.
> Have you read http://www.andraka.com/multipli.htm?
>
> I considered a similar version, but it's slow.  We could put at most
> two rows into one pipeline stage, and we still need an adder for the
> high part of the result (mulh instruction); that means we need 6 stages
> for 8x8 signed/unsigned multiplication.  My multiplier (which can be
> optimized in a similar way, if you like to) takes only 3 cycles.
>

Thing is it's not just carry save.

It's also bit multiply save.

Man all this complex it over two possible results.

Rares
eGroups Sponsor
From Michael Riepe Wed Oct 11 13:44:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00342 for ; Thu, 12 Oct 2000 18:15:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:15:50 +0200 (MEST) Received: (qmail 24290 invoked by uid 0); 11 Oct 2000 22:42:56 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 11 Oct 2000 22:42:56 -0000 X-eGroups-Return: sentto-1101623-1181-971304166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hl.egroups.com with NNFMP; 11 Oct 2000 22:42:53 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 11 Oct 2000 22:42:45 -0000 Received: (qmail 28260 invoked from network); 11 Oct 2000 22:42:45 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 11 Oct 2000 22:42:45 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.43) by mta2 with SMTP; 11 Oct 2000 22:42:41 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00474; Wed, 11 Oct 2000 13:44:49 +0200 Message-ID: <20001011134449.50229@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001010151229.06879@thrai.stud.uni-hannover.de> <200010110847.e9B8lIo23793@essi.essi.fr> X-Mailer: Mutt 0.84e In-Reply-To: <200010110847.e9B8lIo23793@essi.essi.fr>; from Vanderhoeven Steve on Wed, Oct 11, 2000 at 10:47:11AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 13:44:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] cpu ram interface Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0005ad9abf70bc94c9c90565c81b96a2 Status: R X-Status: N On Wed, Oct 11, 2000 at 10:47:11AM +0200, Vanderhoeven Steve wrote:

> ... why not dubling the number of wires... instead of one wire you have a
> pair, and each time you send data on one wire you set a +1 and on the other a
> -1.
> So the equivalent of on a simple wire  0 or 1 is on wich wire the +1 is.

Differential?

> So here you don't need any more a ground. if the pairs are close the
> association of +1 and -1 limits the electrical influence on the other wires.
> And the signal it self can be it's clock.

No it can't, unless you use an encoding that allows clock recovery at
the receiver.  That's why I mentioned phased logic -- it uses the same
two wires but a slightly different encoding, and it doesn't need an
extra clock at all.  There are four possible states: 00, 01, 10 and 11.
The left bit is called `value' bit; it always has the value of the bit
that is transferred.  The right bit is an auxiliary bit that is used
for clocking.  When a bit is transferred, exactly one of the bits
toggles:

      00 - 10 - 11 - 01 - 00 - 01 - 11 - 10 - 11

transfers the sequence `11000111'.

> This is the solution used by scsi.

SCSI uses differential signaling because it reduces noise, IIRC.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Thu Oct 12 02:05:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00348 for ; Thu, 12 Oct 2000 18:15:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:15:52 +0200 (MEST) Received: (qmail 3431 invoked by uid 0); 12 Oct 2000 00:37:00 -0000 Received: from hn.egroups.com (208.50.99.199) by mx12.rz2.gmx.net with SMTP; 12 Oct 2000 00:37:00 -0000 X-eGroups-Return: sentto-1101623-1182-971311015-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 12 Oct 2000 00:36:57 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 00:36:54 -0000 Received: (qmail 8563 invoked from network); 12 Oct 2000 00:36:54 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 12 Oct 2000 00:36:54 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.238) by mta2 with SMTP; 12 Oct 2000 00:36:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00736; Thu, 12 Oct 2000 02:05:37 +0200 Message-ID: <20001012020537.00430@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39E3B6A2.2520797F@f-cpu.org> <20001011042628.46357@thrai.stud.uni-hannover.de> <39E48FBD.95C45E02@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E48FBD.95C45E02@f-cpu.org>; from Yann Guidon on Wed, Oct 11, 2000 at 05:05:17PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 02:05:37 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy + misc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c27788b25acee083d3ad538ce6344032 Status: R X-Status: N On Wed, Oct 11, 2000 at 05:05:17PM +0100, Yann Guidon wrote:

[Yann's `FPGA oven']
> > Fine.  That beast will run an exhaustive test of the 64-bit multiplier
> > in slightly more than 584554 years.  Only 584 and a half year if 1000
> > of them fit into the box.  Assuming the cleaningwoman doesn't pull the
> > wrong plug, of course ;)
>
> hhmmm i don't think that your multiplier takes 10M gates, so we can run
> multiple instances of it in parallel.

Let's see...

The 8x8 unit needs 64 AND gates for the one-bit products,  18 AND
gates and 16 inverters for the `smul correction', 144 full adders,
plus the gates for the adder in stage 3.  We need 64 of these units,
that's 5348 ANDs, 1024 inverters, 9216 full adders, and 64 fast 16-bit
adders; wallace trees for later pipeline stages not counted.  Not to
mention an awful high number of flip-flops.  That means we could run
some hundred instances in parallel (and would have to wait for the
*next* millenium to come, at least).

[...]
> wow, you're "fit" today, did you eat a clown for your breakfeast ? :-DD

I'm afraid I was born that way ;)

[...]
> > Fractional numbers and SIMD together might be a problem.
> ah ? what problem ? what are the possible solutions ?

We can mask off the sign bits at the input, route them separately,
and combine them with the left-shifted result in the output stage(s).
So far, everything is ok.  The problem is the (non-)symmetry of the
instruction itself (this also applies to the MAC instruction, BTW): in
SIMD mode, we get a double-width result, while in full-width operations,
the result is truncated.  In SIMD mode, we can use only one half of
the operand registers (upper or lower), in full-width mode we use the
whole register.  Additionally, fractional results and MAC results are
truncated differently (fractional uses the most-significant half, while
MAC uses the least-significant half).  And, of course, I have to handle
all of these special cases in the multiplier :(

> >  I will think about it when I have the 64-bit multiplier
> > running (maybe tomorrow).
> THAT is FAST :-)

It will take a little longer.  16x16 works fine but at 32x32, signed
multiplications start to fail.  I didn't figure out why exactly, but
there seems to be a problem with wallace trees and signed multipliers
that I overlooked (I guess it's a forgotten carry/borrow somewhere).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Rares Marian Thu Oct 12 03:14:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00363 for ; Thu, 12 Oct 2000 18:15:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:15:55 +0200 (MEST) Received: (qmail 18545 invoked by uid 0); 12 Oct 2000 01:15:30 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 12 Oct 2000 01:15:30 -0000 X-eGroups-Return: sentto-1101623-1183-971313322-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 12 Oct 2000 01:15:28 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 01:15:21 -0000 Received: (qmail 27089 invoked from network); 12 Oct 2000 01:15:21 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 12 Oct 2000 01:15:21 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 12 Oct 2000 01:15:21 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 3ED5A538FA for ; Wed, 11 Oct 2000 21:14:24 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <20001012020537.00430@thrai.stud.uni-hannover.de> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 21:14:23 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] My next toy + misc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 32f858e0370d204fc8d522f4517efcea Status: R X-Status: N On Thu, 12 Oct 2000, Michael Riepe wrote:

> The 8x8 unit needs 64 AND gates for the one-bit products,  18 AND
> gates and 16 inverters for the `smul correction', 144 full adders,
> plus the gates for the adder in stage 3.  We need 64 of these units,
> that's 5348 ANDs, 1024 inverters, 9216 full adders, and 64 fast 16-bit
> adders; wallace trees for later pipeline stages not counted.  Not to
> mention an awful high number of flip-flops.  That means we could run
> some hundred instances in parallel (and would have to wait for the
> *next* millenium to come, at least).

Time for me to do my 1-bit multiplier thingie

Jecel can do the latches :)

Sounds like a job for dia (gnome proggie).

Rares
eGroups Sponsor
From Erik Fischer Thu Oct 12 06:53:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00390 for ; Thu, 12 Oct 2000 18:16:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:02 +0200 (MEST) Received: (qmail 12136 invoked by uid 0); 12 Oct 2000 04:54:06 -0000 Received: from hm.egroups.com (208.50.99.198) by mx06.rz2.gmx.net with SMTP; 12 Oct 2000 04:54:06 -0000 X-eGroups-Return: sentto-1101623-1184-971326420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 12 Oct 2000 04:53:40 -0000 X-Sender: Erik.Fischer@hungary.sun.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 04:53:40 -0000 Received: (qmail 32544 invoked from network); 12 Oct 2000 04:53:39 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Oct 2000 04:53:39 -0000 Received: from unknown (HELO mercury.Sun.COM) (192.9.25.1) by mta1 with SMTP; 12 Oct 2000 04:53:39 -0000 Received: from dunaserv.Hungary.Sun.COM ([129.159.190.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07966 for ; Wed, 11 Oct 2000 21:53:37 -0700 (PDT) Received: from srsun02c (srsun02c.Eng.Sun.COM [129.144.135.63]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id GAA11684 for ; Thu, 12 Oct 2000 06:53:30 +0200 (MET DST) Message-Id: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> To: f-cpu@egroups.com Content-MD5: SUww8SGDTJMUE4U6FgYBtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc From: Erik Fischer MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Oct 2000 21:53:29 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f37766ce42bf35fbde28fcf05efc90c9 Status: R X-Status: N Please me too, I just can't take myself off this list!!!
Rgds,
Eric
>
>----- Original Message -----
>From: "Yann Guidon" <whygee@f-cpu.org>
>To: <f-cpu@egroups.com>
>Sent: Wednesday, October 11, 2000 9:05 AM
>Subject: Re: [f-cpu] My next toy + misc.
>
>
>> hi !
>>
>> Michael Riepe wrote:
>> > On Wed, Oct 11, 2000 at 01:38:58AM +0100, Yann Guidon wrote:
>> > > As some of you may know, my current peecee runs at 200MHz.
>> > >
>> > > Today, i have _seen_ the monster with which i want to work :
>> > > several cubic meters, hundreds of ASICs and it can simulate
>> > > up to 10M gates at the rate of 1MHz. the ICE probe is in option.
>> >
>> > Fine.  That beast will run an exhaustive test of the 64-bit multiplier
>> > in slightly more than 584554 years.  Only 584 and a half year if 1000
>> > of them fit into the box.  Assuming the cleaningwoman doesn't pull the
>> > wrong plug, of course ;)
>>
>> hhmmm i don't think that your multiplier takes 10M gates, so we can run
>> multiple instances of it in parallel.
>>
>> > Maybe we should start the `f-cpu@home' project...
>> is it really so useful ? :-D
>>
>>
>> Michael Riepe wrote:
>> > On Wed, Oct 11, 2000 at 03:41:26AM +0100, Yann Guidon wrote:
>> > > damn, i wish i had enough time to read all these papers !!!
>> > *sigh*
>> *amen*
>>
>> > > Michael will certainly like :
>> > > M. Santoro and M. Horowitz. SPIM: A pipelined 64x64b iterative
>multiplier.
>> > > IEEE Journal of Solid-State Circuits, April 1989, pages 487-493.
>> > > (link : http://mos.stanford.edu/papers/ms_jssc_89.pdf )
>> > Should I read it before or after I have finished the IMUL unit? ;)
>> it's as you like :-)
>>
>> > There are too many papers in the world...  Instead of writing a paper
>> > about my multiplier, I should draw the schematics and print them on
>> > the back side of a t-shirt.  And if anybody asks for documentation,
>> > I can simply turn around...
>> wow, you're "fit" today, did you eat a clown for your breakfeast ? :-DD
>>
>> (about the multiplier :)
>> Michael Riepe wrote:
>> > On Wed, Oct 11, 2000 at 01:38:52AM +0100, Yann Guidon wrote:
>> > > Damn, this is getting really crazy :-)
>> > Do you think?  You wanted a free CPU, you get it ;)
>> hey, i'm not the only one to want it ;-)
>>
>> > > A good documentation (some pages of HTML for example) would
>> > > probably kill the magic, but that would certainly help people
>> > > use your design. The documentation would be included in the
>> > > F-CPU/FC0 manual.
>> > Please wait until the 64-bit unit is ready.
>> ok, i'm patient.
>>
>> >  I had to change the interface of the 8x8 unit again to work out
>> > some signedness issues (I really want to make the final stages as
>> > simple, clean and modular as I can).
>> ok, i trust you :-)
>>
>> > > One cool thing, anyway : the MAC instruction can be used with
>> > > Michael's design. let's see now if there is a problem with
>> > > fractional/fixed point flags.
>> > Fractional numbers and SIMD together might be a problem.
>> ah ? what problem ? what are the possible solutions ?
>>
>> >  I will think about it when I have the 64-bit multiplier
>> > running (maybe tomorrow).
>> THAT is FAST :-)
>>
>> > > > > > > What is your plan for the next stages ?
>> > > > 8x8+16 -> 3 cycles
>> > > > 16x16+32 -> 5 cycles
>> > > > 32x32+64 -> 7 cycles
>> > > > 64x64+64 -> 9 or 10 cycles
>> > > yummy yummy :-)))
>> > > i hope that you'll succeed because it looks too good to
>> > > be true ;-)
>> > There's still a murphy factor of one or two cycles.
>> if you can make tighter stages, it won't hurt a lot
>> to have more latency : because it will run faster, so don't
>> be afraid.
>>
>> > > > > This means that the Xbar will need 4 inputs from the IMUL unit if
>> > > > > we want to feed one operation of any size at each cycle. This
>could
>> > > > > be reduced to 2 ports anyway (the 2W limitation) but i don't want
>> > > > > to think about it now, i gotta finish the Icache.
>> > > > Don't forget that it also does `widening' multiplications -- that
>> > > > means 3 input + 8 output ports.
>> > > i don't get it. i'm probably too worried or tired. can you explain
>> > > more clearly ?
>> > I referred to the `mulh' instruction which needs two register writes
>> > (2r2w), and two output ports per stage.
>> oh yeah, 4 results (pipe stages with output) and 2 words each.
>> this makes 8 results, right :-)
>>
>> > [signed-magnitude fractional numbers]
>> > > > This is actually 7x7->14 unsigned multiplication plus a shift, and
>an
>> > > > xor for the sign bit.  If we route the sign bits separately, this
>should
>> > > > not be a problem.
>> > > cool :-) i gotta check if we have a provision for this operation in
>the
>> > > instruction set census.
>> > Shouldn't that be a separate instruction?
>> > BTW: does this have to be SIMD?
>> for SIMD, the answer is "Of course" :-)
>> as for a separate instruction, this is more difficult to answer.
>> we gotta all brainstorm ...
>>
>> > > For the multiplier, for example, we can define SRs (Special Registers)
>> > > that can spy the partial results. To run a test, we can send a
>multiply
>> > > instruction and read all the partial results with the different SRs.
>> > > If 64*64 takes 10 cycles, we need 10 SRs. Then the problem is to
>determine
>> > > what data should be used to test all the combinations, exhaustively
>but
>> > > without redundancy. heck.
>> > You mean, registers that are accessible in software?
>> > What about boundary scan?
>> boundary scan is slow, but it can be used during the burning tests
>> to upload a SW in the caches. The SW will contain other test vectors that
>> will run like a BIST (Built-In Self Test). This SW will test the all the
>> operations and instructions, compare the results with the vectors and
>> will report the errors. it will run faster than boundary scan because
>> SW executes in parallel, while JTAG uses a serial link. Well, we can of
>course
>> use JTAG/etc for the first preliminary tests but units like the multiplier
>> will need more vectors and speed than that.
>>
>> >  Michael "witty" Riepe
>> WHYGEE (who just woke up and enjoy a laugh or two when reading his mails)
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>>
>
>
>
>
>
eGroups Sponsor
From Yann Guidon Thu Oct 12 09:01:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00393 for ; Thu, 12 Oct 2000 18:16:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:04 +0200 (MEST) Received: (qmail 18264 invoked by uid 0); 12 Oct 2000 05:57:21 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 12 Oct 2000 05:57:21 -0000 X-eGroups-Return: sentto-1101623-1185-971330234-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 12 Oct 2000 05:57:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 05:57:14 -0000 Received: (qmail 19422 invoked from network); 12 Oct 2000 05:57:13 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Oct 2000 05:57:13 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 12 Oct 2000 05:57:13 -0000 Received: from f-cpu.org (nas1-139.ras.club-internet.fr [195.36.192.139]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA23630 for ; Thu, 12 Oct 2000 07:57:08 +0200 (MET DST) Message-ID: <39E561D0.EA787A5E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 08:01:36 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) Icache testbench : first working version Content-Type: multipart/mixed; boundary="------------BA9A586829A0573B7A2C50A7" X-UIDL: b1c47560657092b35ffc545d427f8bb9 Status: R X-Status: N --------------BA9A586829A0573B7A2C50A7 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

after some "inactivity" time, i've finally finished
this testbench for the Icache. It reads text files
with vectors, and decodes them to all the buses.

It's not perfect, and far from it, but it's a good start.
to whoever wants/has time : clean it as necessary,
send the updates to the list and use/abuse of it :-)
I've not succeeded in making a micro-flex/bison in VHDL,
but it's a start, no ? :-)

and NOW, i can make the Icache :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PS: read the files carefully. some stuffs,
particularly the parsing, are not trivial...
eGroups Sponsor
--------------BA9A586829A0573B7A2C50A7 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="tb07.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="tb07.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tIEYtQ1BVIHByb2plY3QgOiBJbnN0cnVjdGlvbiBjYWNoZSBz cGVjaWZpY2F0aW9uICYgdGVzdGJlbmNoDQotLSBjcmVhdGVkIGJ5IFlhbm4gR3VpZG9uLCBv Y3QuIDMsIDIwMDAgKDJhbSkgd2l0aCBhIGxvdCBvZiBtYXRlcmlhbA0KLS0gZnJvbSB0aGUg Zi1jcHVAZWdyb3Vwcy5jb20gbWFpbGluZyBsaXN0IChtb3N0bHkgTWljaGFlbCAmIENvbGlu KQ0KLS0gVGhpcyBmaWxlIGlzIG5vdCBmaW5pc2hlZC4gR1BMIGFwcGxpZXMuIE5vdyB5b3Un cmUgd2FybmVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KbGlicmFyeSBJRUVFOw0KICAgIHVzZSBJ RUVFLnN0ZF9sb2dpY18xMTY0LmFsbDsNCiAgICB1c2UgSUVFRS5udW1lcmljX3N0ZC5hbGw7 DQogICAgdXNlIHN0ZC50ZXh0aW8uYWxsOw0KICAgIHVzZSBpZWVlLnN0ZF9sb2dpY190ZXh0 aW8uYWxsOw0KDQpFTlRJVFkgIEljYWNoZV90eXBlICBJUw0KICBHRU5FUklDKA0KICAgIERC d2lkdGggIDogbmF0dXJhbCA6PSAyNTYgOyAtLSBEYXRhIEJ1cyB3aWR0aCwgb3Igd2lkdGgg b2YgZWFjaCBjYWNoZSBsaW5lICgzMiBieXRlcykNCiAgICBBQndpZHRoICA6IG5hdHVyYWwg Oj0gMzIgIDsgLS0gQWRkcmVzcyBCdXNzIHdpZHRoLCBpbiAzMi1ieXRlIGNodW5ja3MgKDMy KzU9MTI4R0IpDQogICAgTG9nTGluZXMgOiBuYXR1cmFsIDo9IDYgICA7IC0tIExvZzIgb2Yg dGhlIE51bUJlciBvZiBjYWNoZSBMaW5lcyAoTVVTVCBiZSBFVkVOKQ0KICAgIE5CbGluZXMg IDogbmF0dXJhbCA6PSA2NCAgICAtLSBOdW1CZXIgb2YgY2FjaGUgTGluZXMgKDIqKkxvZ0xp bmVzKSAoc21hbGwgbnVtYmVyIGZvciB0aGUgZmlyc3QgYXR0ZW1wdHMpDQogICk7DQogIFBP UlQoDQogICBDbGssIEludl9FbiwgUmVzZXQsIFJlYWRfRW4sIFdyaXRlX0VuLCBGcmVlemVf RW4gOiBJTiBCb29sZWFuOw0KICAgQWRkcmVzc19yZWFkLCBBZGRyZXNzX3dyaXRlLCBBZGRy ZXNzX01hc2sgOiBJTiBTdGRfdWxvZ2ljX3ZlY3RvcihBQndpZHRoLTEgZG93bnRvIDApOw0K LS0gIm5hdHVyYWwiIHNob3VsZCBiZSB1c2VkIGZvciB0aGUgYWRkcmVzc2VzLCByaWdodCA/ IEJ1dCBob3cgZG8gd2UgaGFuZGxlDQotLSB0aGUgQU5EIHdpdGggdGhlIG1hc2tzID8NCiAg IEljYWNoZV9oaXQgOiBPVVQgQm9vbGVhbjsNCiAgIERpbiAgOiAgSU4gU3RkX3Vsb2dpY192 ZWN0b3IoREJ3aWR0aC0xIGRvd250byAwKTsNCiAgIERvdXQgOiBPVVQgU3RkX3Vsb2dpY192 ZWN0b3IoREJ3aWR0aC0xIGRvd250byAwKQ0KICApOw0KRU5EIEljYWNoZV90eXBlOw0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KLS0gRHVtYiBsYXRjaCB3aXRoIHJlc2V0Lg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkFyY2hpdGVjdHVyZSBkdW1iIG9mIEljYWNoZV90eXBlIElTDQpiZWdpbg0KIHByb2Nl c3MgKENMSywgcmVzZXQpDQogICAgIHZhcmlhYmxlIGxvdXQgOiBsaW5lIDsNCiBiZWdpbg0K ICAgaWYgcmVzZXQ9dHJ1ZSB0aGVuDQogICAgIERvdXQ8PShvdGhlcnM9PicwJyk7DQotLSAg ICAgV1JJVEUobG91dCwiTEFUQ0ggOiBSZXNldCIpOw0KICAgZWxzZQ0KICAgICBpZiAoQ0xL J2V2ZW50IGFuZCBDTEs9dHJ1ZSkgdGhlbg0KLS0gICAgICAgV1JJVEUobG91dCwiTEFUQ0gg OiBsYXRjaGluZyIpOw0KICAgICAgIERvdXQ8PURpbjsNCiAgICAgZW5kIGlmOw0KICAgZW5k IGlmOw0KLS0gICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiBlbmQgcHJvY2VzczsNCg0K ZW5kIGR1bWI7DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFRlc3RiZW5jaGluZyA6DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KTElCUkFSWSBpZWVlOw0KICAgIFVTRSBpZWVlLnN0ZF9sb2dpY18xMTY0 LkFMTDsNCiAgICBVU0UgaWVlZS5zdGRfbG9naWNfdGV4dGlvLmFsbDsNCiAgICBVU0UgaWVl ZS5udW1lcmljX3N0ZC5hbGw7DQpMSUJSQVJZIHN0ZDsNCiAgICBVU0Ugc3RkLnRleHRpby5B TEw7DQogICAgVVNFIHdvcmsuSWNhY2hlX3R5cGU7DQoNCmVudGl0eSB0ZXN0YmVuY2ggaXMN Ci0tIGNvcHkgb2YgdGhlIGFib3ZlIGRlY2xhcmF0aW9uDQogIEdFTkVSSUMoDQogICAgREJ3 aWR0aCAgOiBuYXR1cmFsIDo9IDI1NiA7IC0tIERhdGEgQnVzIHdpZHRoLCBvciB3aWR0aCBv ZiBlYWNoIGNhY2hlIGxpbmUgKDMyIGJ5dGVzKQ0KICAgIEFCd2lkdGggIDogbmF0dXJhbCA6 PSAzMiAgOyAtLSBBZGRyZXNzIEJ1c3Mgd2lkdGgsIGluIDMyLWJ5dGUgY2h1bmNrcyAoMzIr NT0xMjhHQikNCiAgICBMb2dMaW5lcyA6IG5hdHVyYWwgOj0gNiAgIDsgLS0gTG9nMiBvZiB0 aGUgTnVtQmVyIG9mIGNhY2hlIExpbmVzIChNVVNUIGJlIEVWRU4pDQogICAgTkJsaW5lcyAg OiBuYXR1cmFsIDo9IDY0ICA7IC0tIE51bUJlciBvZiBjYWNoZSBMaW5lcyAoMioqTG9nTGlu ZXMpIChzbWFsbCBudW1iZXIgZm9yIHRoZSBmaXJzdCBhdHRlbXB0cykNCg0KLS0gdGhlIGxp bmUgYmVsb3cgaXMgbm90IGNvcGllZCA6DQogICAgZmlsZW5hbWUgOiBzdHJpbmcgOj0gInRl c3QzLnR4dCINCg0KICApOw0KZW5kIHRlc3RiZW5jaDsNCg0KYXJjaGl0ZWN0dXJlIHRlc3Qx IG9mIHRlc3RiZW5jaCBpcw0KLS0gdGhpcyBpcyBhbm90aGVyIGNvcHksIGJ1dCBoZXJlIGFy ZSB0aGUgc2lnbmFscy9wb3J0cyA6DQogIHNpZ25hbCBkaW4sZG91dCA6IFN0ZF91bG9naWNf dmVjdG9yKERCd2lkdGgtMSBkb3dudG8gMCk7IC0tIHVuaW5pdGlhbGl6ZWQgb24gcHVycG9z ZS4NCiAgc2lnbmFsIHJlc2V0LGNsayxJbnZfRW4sUmVhZF9FbixXcml0ZV9FbixGcmVlemVf RW4gOiBCb29sZWFuOj1mYWxzZTsgLS0gaW5wdXRzIG9mIHRoZSBjYWNoZQ0KICBzaWduYWwg QWRkcmVzc19yZWFkLCBBZGRyZXNzX3dyaXRlLCBBZGRyZXNzX01hc2sgOiBTdGRfdWxvZ2lj X3ZlY3RvcihBQndpZHRoLTEgZG93bnRvIDApOj0ob3RoZXJzPT4nMCcpOw0KICBzaWduYWwg SWNhY2hlX2hpdCA6IEJvb2xlYW47IC0tIHVuaW5pdGlhbGl6ZWQgOiBvdXRwdXQgc2lnbmFs Ow0KDQotLSBpbnRlcm5hbCBjb3VudGVyIDoNCiAgc2hhcmVkIHZhcmlhYmxlIGN5Y2xlIDog bmF0dXJhbCA6PTA7DQogIHNoYXJlZCB2YXJpYWJsZSBsb3V0IDogbGluZSA7DQoNCiAgcHJv Y2VkdXJlIHByaW50IGlzDQogIGJlZ2luDQogICAgV1JJVEUobG91dCwiKiBjeWNsZSAjIDog Iik7DQogICAgV1JJVEUobG91dCxjeWNsZSk7DQogICAgV1JJVEUobG91dCwiICAgc2lnbmFs cyA6ICIpOw0KICAgIGlmIGNsaz10cnVlIHRoZW4NCiAgICAgIFdSSVRFKGxvdXQsIiAgIGNs ayIpOw0KICAgIGVuZCBpZjsNCiAgICBpZiByZXNldD10cnVlIHRoZW4NCiAgICAgIFdSSVRF KGxvdXQsIiAgIHJlc2V0Iik7DQogICAgZW5kIGlmOw0KICAgIGlmIEljYWNoZV9oaXQ9dHJ1 ZSB0aGVuDQogICAgICBXUklURShsb3V0LCIgICBJY2FjaGVfaGl0ICEgRG91dD0iKTsNCiAg ICAgIEhXUklURShsb3V0LERvdXQpOw0KICAgICAgV1JJVEVMSU5FKE9VVFBVVCwgbG91dCk7 DQogICAgZW5kIGlmOw0KICAgIGlmIFJlYWRfRW49dHJ1ZSB0aGVuDQogICAgICBXUklURShs b3V0LCIgICBSZWFkX0VuOiIpOw0KICAgICAgSFdSSVRFKGxvdXQsQWRkcmVzc19yZWFkKTsN CiAgICBlbmQgaWY7DQogICAgaWYgV3JpdGVfRW49dHJ1ZSB0aGVuDQogICAgICBXUklURShs b3V0LCIgICBXcml0ZV9FbjoiKTsNCiAgICAgIEhXUklURShsb3V0LEFkZHJlc3Nfd3JpdGUp Ow0KICAgICAgV1JJVEUobG91dCwiIERpbj0iKTsNCiAgICAgIEhXUklURShsb3V0LERpbik7 DQogICAgICBXUklURUxJTkUoT1VUUFVULCBsb3V0KTsNCiAgICBlbmQgaWY7DQogICAgaWYg SW52X0VuPXRydWUgdGhlbg0KICAgICAgV1JJVEUobG91dCwiICAgSW52X0VuOiIpOw0KICAg ICAgSFdSSVRFKGxvdXQsQWRkcmVzc19yZWFkKTsNCiAgICAgIFdSSVRFKGxvdXQsIiwgYWRk cmVzc19tYXNrOiIpOw0KICAgICAgSFdSSVRFKGxvdXQsQWRkcmVzc19NYXNrKTsNCiAgICBl bmQgaWY7DQogICAgaWYgRnJlZXplX0VuPXRydWUgdGhlbg0KICAgICAgV1JJVEUobG91dCwi ICAgRnJlZXplX0VuOiIpOw0KICAgICAgSFdSSVRFKGxvdXQsQWRkcmVzc19yZWFkKTsNCiAg ICAgIFdSSVRFKGxvdXQsIiwgYWRkcmVzc19tYXNrOiIpOw0KICAgICAgSFdSSVRFKGxvdXQs QWRkcmVzc19NYXNrKTsNCiAgICBlbmQgaWY7DQogICAgV1JJVEVMSU5FKE9VVFBVVCwgbG91 dCk7DQotLSAgICBXUklURShsb3V0LCIgIik7DQotLSAgICBXUklURUxJTkUoT1VUUFVULCBs b3V0KTsNCiAgZW5kOw0KDQotLSBGb3IgYSBkdW1iIHBhcnNlciBpbiBWSERMIDoNCiAgc2hh cmVkIHZhcmlhYmxlIHRlbXBfY2hhciA6IENoYXJhY3RlciA6PSBOVUw7ICAtLSBwYXJzZWQg Y2hhcmFjdGVyDQogIHNoYXJlZCB2YXJpYWJsZSBidWZmIDogbGluZTsgICAgICAgLS0gbGlu ZSBmcm9tIHdoaWNoIHdlIHBhcnNlDQogIHNoYXJlZCB2YXJpYWJsZSBsaW5lX251bWJlciA6 IG5hdHVyYWw6PTA7DQogIHNoYXJlZCB2YXJpYWJsZSBpIDogbmF0dXJhbDsNCg0KICBwcm9j ZWR1cmUgZ2V0Y2ggaXMNCiAgYmVnaW4NCiAgICB0ZW1wX2NoYXI6PWJ1ZmYoaSk7DQogICAg aTo9aSsxOw0KICBlbmQ7DQoNCiAgLS0gd2FybmluZyAhISEgbm8gb3ZlcmZsb3cgY2hlY2tz ICEhIQ0KICBmdW5jdGlvbiBnZXRfaGV4YShzOlN0ZF91bG9naWNfdmVjdG9yKSByZXR1cm4g U3RkX3Vsb2dpY192ZWN0b3IgaXMNCiAgICB2YXJpYWJsZSB0OlN0ZF91bG9naWNfdmVjdG9y KDMgZG93bnRvIDApOj0ob3RoZXJzPT4nMCcpOw0KICAgIHZhcmlhYmxlIHU6U3RkX3Vsb2dp Y192ZWN0b3IocydoaWdoIGRvd250byAwKTo9KG90aGVycz0+JzAnKTsNCiAgYmVnaW4NCiAg ICBoZXhhX2xvb3AgOiB3aGlsZSBpPD1idWZmJ2hpZ2ggbG9vcA0KICAgICAgZ2V0Y2g7DQog ICAgICBjYXNlIHRlbXBfY2hhciBpcw0KICAgICAgICB3aGVuICcwJyA9PiB0Oj1YIjAiOw0K ICAgICAgICB3aGVuICcxJyA9PiB0Oj1YIjEiOw0KICAgICAgICB3aGVuICcyJyA9PiB0Oj1Y IjIiOw0KICAgICAgICB3aGVuICczJyA9PiB0Oj1YIjMiOw0KICAgICAgICB3aGVuICc0JyA9 PiB0Oj1YIjQiOw0KICAgICAgICB3aGVuICc1JyA9PiB0Oj1YIjUiOw0KICAgICAgICB3aGVu ICc2JyA9PiB0Oj1YIjYiOw0KICAgICAgICB3aGVuICc3JyA9PiB0Oj1YIjciOw0KICAgICAg ICB3aGVuICc4JyA9PiB0Oj1YIjgiOw0KICAgICAgICB3aGVuICc5JyA9PiB0Oj1YIjkiOw0K ICAgICAgICB3aGVuICdBJyA9PiB0Oj1YIkEiOw0KICAgICAgICB3aGVuICdCJyA9PiB0Oj1Y IkIiOw0KICAgICAgICB3aGVuICdDJyA9PiB0Oj1YIkMiOw0KICAgICAgICB3aGVuICdEJyA9 PiB0Oj1YIkQiOw0KICAgICAgICB3aGVuICdFJyA9PiB0Oj1YIkUiOw0KICAgICAgICB3aGVu ICdGJyA9PiB0Oj1YIkYiOw0KICAgICAgICB3aGVuICdhJyA9PiB0Oj1YIkEiOw0KICAgICAg ICB3aGVuICdiJyA9PiB0Oj1YIkIiOw0KICAgICAgICB3aGVuICdjJyA9PiB0Oj1YIkMiOw0K ICAgICAgICB3aGVuICdkJyA9PiB0Oj1YIkQiOw0KICAgICAgICB3aGVuICdlJyA9PiB0Oj1Y IkUiOw0KICAgICAgICB3aGVuICdmJyA9PiB0Oj1YIkYiOw0KICAgICAgICB3aGVuIG90aGVy cyA9PiBpOj1pLTE7IHJldHVybiB1Ow0KICAgICAgZW5kIGNhc2U7DQogICAgICB1KHUnaGln aCBkb3dudG8gNCk6PXUoKHUnaGlnaCktNCBkb3dudG8gMCk7DQogICAgICB1KDMgZG93bnRv IDApOj10Ow0KICAgIGVuZCBsb29wOw0KLS0gdGhpcyBleGl0IG9ubHkgaWYgRU9MIDoNCiAg ICByZXR1cm4gdTsNCiAgZW5kOw0KDQpiZWdpbg0KDQogLS0gSW5zdGFudGlhdGUgdGhlIHRl c3RlZCBjaXJjdWl0DQogSWNhY2hlIDogZW50aXR5IEljYWNoZV90eXBlDQogICBwb3J0IG1h cCgNCiAgICAgRGluID0+IGRpbiwNCiAgICAgRG91dCA9PiBkb3V0LA0KICAgICBjbGsgPT4g Y2xrLA0KICAgICByZXNldCA9PiByZXNldCwNCiAgICAgSW52X0VuID0+IEludl9FbiwNCiAg ICAgUmVhZF9FbiA9PiBSZWFkX0VuLA0KICAgICBXcml0ZV9FbiA9PiBXcml0ZV9FbiwNCiAg ICAgRnJlZXplX0VuID0+IEZyZWV6ZV9FbiwNCiAgICAgQWRkcmVzc19yZWFkID0+IEFkZHJl c3NfcmVhZCwNCiAgICAgQWRkcmVzc193cml0ZSA9PiBBZGRyZXNzX3dyaXRlLA0KICAgICBB ZGRyZXNzX01hc2sgPT4gQWRkcmVzc19NYXNrLA0KICAgICBJY2FjaGVfaGl0ID0+IEljYWNo ZV9oaXQNCiAgICk7DQoNCiBwcm9jZXNzDQogICBmaWxlIHRlc3RfdmVjdG9yIDogVEVYVCBP UEVOIFJFQURfTU9ERSBJUyBmaWxlbmFtZTsNCiAgIHZhcmlhYmxlIHRlbXBfcmVzZXQsIHRl bXBfSW52X0VuLCB0ZW1wX1JlYWRfRW4sIHRlbXBfV3JpdGVfRW4sIHRlbXBfRnJlZXplX0Vu IDogYm9vbGVhbjsNCiBiZWdpbg0KLS0gaW5pdC9yZXNldCA6DQogICBEaW48PShvdGhlcnM9 PicwJyk7DQotLSAgIHByaW50Ow0KICAgcmVzZXQ8PXRydWU7DQogICB3YWl0IGZvciAxMCBu czsNCi0tICAgcHJpbnQ7DQogICByZXNldDw9ZmFsc2U7DQogICB3YWl0IGZvciAxMCBuczsN Ci0tICAgcHJpbnQ7DQoNCi0tIGJlZ2luIHRoZSBzaW11bGF0aW9uIGJvZHkgOg0KICAgd2hp bGUgKG5vdCBlbmRmaWxlKHRlc3RfdmVjdG9yKSkgbG9vcA0KICAgICAtLSBpbml0IHRlbXAg aW5wdXRzIDoNCiAgICAgdGVtcF9yZXNldDo9ZmFsc2U7DQogICAgIHRlbXBfSW52X0VuOj1m YWxzZTsNCiAgICAgdGVtcF9SZWFkX0VuOj1mYWxzZTsNCiAgICAgdGVtcF9Xcml0ZV9Fbjo9 ZmFsc2U7DQogICAgIHRlbXBfRnJlZXplX0VuOj1mYWxzZTsNCg0KICAgICAtLSByZWFkIHRo ZSBwYXJhbWV0ZXJzIGZyb20gdGhlIHRlc3QgdmVjdG9yIGZpbGUgOg0KICAgICByZWFkbGlu ZSh0ZXN0X3ZlY3RvcixidWZmKTsNCiAgICAgbGluZV9udW1iZXI6PWxpbmVfbnVtYmVyKzE7 DQogICAgIHdyaXRlKGxvdXQsIioqKiBkZWNvZGluZyBsaW5lICMiKTsNCiAgICAgd3JpdGUo bG91dCxsaW5lX251bWJlcik7DQogICAgIHdyaXRlbGluZShvdXRwdXQsbG91dCk7DQoNCiAg ICAgSWYgYnVmZidsZW5ndGgvPTAgdGhlbg0KDQogICAgIC0tIHBhcnNpbmcgImJ1ZmYiIGhl cmUgLi4uDQogICAgICAgaTo9MTsNCnBhcnNlX2xvb3A6DQogICAgICAgd2hpbGUgaTw9YnVm ZidoaWdoIGxvb3ANCiAgICAgICAgIGdldGNoOw0KICAgICAgICAgY2FzZSB0ZW1wX2NoYXIg aXMNCg0KICAgICAgICAgICB3aGVuICc7JyA9Pg0KICAgICAgICAgICAgIGV4aXQgcGFyc2Vf bG9vcDsNCg0KICAgICAgICAgICB3aGVuICdRJyA9Pg0KICAgICAgICAgICAgIHdyaXRlKGxv dXQsTEYmIiAgICMjIyBFbmQgb2YgdmVjdG9yIGZpbGUgIyMjLiImTEYpOw0KICAgICAgICAg ICAgIHdyaXRlbGluZShvdXRwdXQsbG91dCk7DQogICAgICAgICAgICAgd2FpdDsNCg0KICAg ICAgICAgICB3aGVuICdUJyA9Pg0KICAgICAgICAgICAgIGlmIHRlbXBfcmVzZXQ9dHJ1ZSB0 aGVuDQogICAgICAgICAgICAgICB3cml0ZShsb3V0LCJXYXJuaW5nIDogbXVsdGlwbGUgUmVz ZXQgaW4gdmVjdG9yICEiJkJFTCk7DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAg ICAgdGVtcF9yZXNldDo9dHJ1ZTsNCiAgICAgICAgICAgICBlbmQgaWY7DQoNCiAgICAgICAg ICAgd2hlbiAnVycgPT4NCiAgICAgICAgICAgICBpZiB0ZW1wX1dyaXRlX0VuPXRydWUgdGhl bg0KICAgICAgICAgICAgICAgd3JpdGUobG91dCwiV2FybmluZyA6IG11bHRpcGxlIFdyaXRl cyBpbiB2ZWN0b3IgISImQkVMKTsNCiAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAg ICBBZGRyZXNzX3dyaXRlPD1nZXRfaGV4YShBZGRyZXNzX3dyaXRlKTsNCiAgICAgICAgICAg ICAgIGk6PWkrMTsgLS0gY29ycmVjdCB0aGUgaW5kZXgsIHJlc3RvcmUgdGhlIGNoYXJhY3Rl ciB0aGF0IGhhcyBiZWVuIGFscmVhZHkgImVhdGVuIg0KICAgICAgICAgICAgICAgaWYgdGVt cF9jaGFyLz0nOicgdGhlbg0KICAgICAgICAgICAgICAgICByZXBvcnQgImV4cGVjdGVkICc6 JyBiZXR3ZWVuIGFkZHJlc3MgJiBkYXRhLCBub3QgZm91bmQiOw0KICAgICAgICAgICAgICAg ZW5kIGlmOw0KICAgICAgICAgICAgICAgRGluPD1nZXRfaGV4YShEaW4pOw0KICAgICAgICAg ICAgICAgdGVtcF9Xcml0ZV9Fbjo9dHJ1ZTsNCiAgICAgICAgICAgICBlbmQgaWY7DQoNCiAg ICAgICAgICAgd2hlbiAnUicgPT4NCiAgICAgICAgICAgICBpZiAodGVtcF9GcmVlemVfRW49 dHJ1ZSkgb3IgKHRlbXBfUmVhZF9Fbj10cnVlKSBvciAodGVtcF9JbnZfRW49dHJ1ZSkgdGhl bg0KICAgICAgICAgICAgICAgd3JpdGUobG91dCwiV2FybmluZyA6IG11bHRpcGxlIFJlYWRz L0ludmFsaWRhdGlvbnMvRnJlZXplIGluIHZlY3RvciAhIiZCRUwpOw0KICAgICAgICAgICAg IGVsc2UNCiAgICAgICAgICAgICAgIEFkZHJlc3NfcmVhZDw9Z2V0X2hleGEoQWRkcmVzc19y ZWFkKTsNCiAgICAgICAgICAgICAgIHRlbXBfUmVhZF9Fbjo9dHJ1ZTsNCiAgICAgICAgICAg ICBlbmQgaWY7DQoNCiAgICAgICAgICAgd2hlbiAnSScgPT4NCiAgICAgICAgICAgICBpZiAo dGVtcF9GcmVlemVfRW49dHJ1ZSkgb3IgKHRlbXBfSW52X0VuPXRydWUpIG9yICh0ZW1wX1Jl YWRfRW49dHJ1ZSkgIHRoZW4NCiAgICAgICAgICAgICAgIHdyaXRlKGxvdXQsIldhcm5pbmcg OiBtdWx0aXBsZSBSZWFkcy9JbnZhbGlkYXRpb25zL0ZyZWV6ZSBpbiB2ZWN0b3IgISImQkVM KTsNCiAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAgICBBZGRyZXNzX3JlYWQ8PWdl dF9oZXhhKEFkZHJlc3NfcmVhZCk7DQogICAgICAgICAgICAgICBpOj1pKzE7IC0tIGNvcnJl Y3QgdGhlIGluZGV4LCByZXN0b3JlIHRoZSBjaGFyYWN0ZXIgdGhhdCBoYXMgYmVlbiBhbHJl YWR5ICJlYXRlbiINCiAgICAgICAgICAgICAgIGlmIHRlbXBfY2hhci89JzonIHRoZW4NCiAg ICAgICAgICAgICAgICAgcmVwb3J0ICJleHBlY3RlZCAnOicgYmV0d2VlbiBhZGRyZXNzICYg bWFzaywgbm90IGZvdW5kIjsNCiAgICAgICAgICAgICAgIGVuZCBpZjsNCiAgICAgICAgICAg ICAgIEFkZHJlc3NfTWFzayA8PWdldF9oZXhhKEFkZHJlc3NfTWFzayApOw0KICAgICAgICAg ICAgICAgdGVtcF9JbnZfRW46PXRydWU7DQogICAgICAgICAgICAgZW5kIGlmOw0KDQogICAg ICAgICAgIHdoZW4gJ0YnID0+DQogICAgICAgICAgICAgaWYgKHRlbXBfRnJlZXplX0VuPXRy dWUpIG9yICh0ZW1wX0ludl9Fbj10cnVlKSBvciAodGVtcF9SZWFkX0VuPXRydWUpICB0aGVu DQogICAgICAgICAgICAgICB3cml0ZShsb3V0LCJXYXJuaW5nIDogbXVsdGlwbGUgUmVhZHMv SW52YWxpZGF0aW9ucy9GcmVlemUgaW4gdmVjdG9yICEiJkJFTCk7DQogICAgICAgICAgICAg ZWxzZQ0KICAgICAgICAgICAgICAgQWRkcmVzc19yZWFkPD1nZXRfaGV4YShBZGRyZXNzX3Jl YWQpOw0KICAgICAgICAgICAgICAgaTo9aSsxOyAtLSBjb3JyZWN0IHRoZSBpbmRleCwgcmVz dG9yZSB0aGUgY2hhcmFjdGVyIHRoYXQgaGFzIGJlZW4gYWxyZWFkeSAiZWF0ZW4iDQogICAg ICAgICAgICAgICBpZiB0ZW1wX2NoYXIvPSc6JyB0aGVuDQogICAgICAgICAgICAgICAgIHJl cG9ydCAiZXhwZWN0ZWQgJzonIGJldHdlZW4gYWRkcmVzcyAmIG1hc2ssIG5vdCBmb3VuZCI7 DQogICAgICAgICAgICAgICBlbmQgaWY7DQogICAgICAgICAgICAgICBBZGRyZXNzX01hc2sg PD1nZXRfaGV4YShBZGRyZXNzX01hc2sgKTsNCiAgICAgICAgICAgICAgIHRlbXBfRnJlZXpl X0VuOj10cnVlOw0KICAgICAgICAgICAgIGVuZCBpZjsNCg0KICAgICAgICAgICB3aGVuIG90 aGVycyA9Pg0KICAgICAgICAgICAgIHdyaXRlKGxvdXQsTEYmIiAgIyB1bmtub3duIGNvbW1h bmQgOiAiKTsNCiAgICAgICAgICAgICB3cml0ZShsb3V0LHRlbXBfY2hhciZMRik7DQoNCiAg ICAgICAgIGVuZCBjYXNlOw0KICAgICAgICAgd3JpdGVsaW5lKG91dHB1dCxsb3V0KTsNCiAg DQotLSBleHBlY3QgYSBjb21hL3NlcGFyYXRvci9FT0wgOg0KICAgICAgICAgaWYgKGktMT49 YnVmZidIaWdoKSB0aGVuICAgLS0gZG8gbm90IGV4cGVjdCBjb21hIGlmIGFscmVhZHkgYXQg ZW5kIG9mIGxpbmUNCiAgICAgICAgICAgZXhpdCBwYXJzZV9sb29wOw0KICAgICAgICAgZW5k IGlmOw0KICAgICAgICAgZ2V0Y2g7DQogICAgICAgICBpZiAodGVtcF9jaGFyID0gJzsnKSB0 aGVuDQogICAgICAgICAgIGV4aXQgcGFyc2VfbG9vcDsNCiAgICAgICAgIGVuZCBpZjsNCiAg ICAgICAgIGlmICh0ZW1wX2NoYXIgLz0gJywnKSB0aGVuDQogICAgICAgICAgIHdyaXRlKGxv dXQsIicsJyBleHBlY3RlZCwgZ290ICIpOw0KICAgICAgICAgICB3cml0ZShsb3V0LHRlbXBf Y2hhcik7DQogICAgICAgICAgIHdyaXRlKGxvdXQsIiBpbnN0ZWFkIik7DQogICAgICAgICAg IHdyaXRlbGluZShvdXRwdXQsbG91dCk7DQogICAgICAgICBlbmQgaWY7DQoNCiAgICAgICBl bmQgbG9vcCBwYXJzZV9sb29wOw0KLS0gICAgIGVsc2UNCi0tICAgICAgIHJlcG9ydCAic2tp cHBpbmcgZW1wdHkgbGluZSI7DQogICAgIGVuZCBpZjsgLS0gdm9pZCBzdHJpbmcNCg0KICAg ICByZXNldDw9dGVtcF9yZXNldDsNCiAgICAgSW52X0VuPD10ZW1wX0ludl9FbjsNCiAgICAg UmVhZF9Fbjw9dGVtcF9SZWFkX0VuOw0KICAgICBXcml0ZV9Fbjw9dGVtcF9Xcml0ZV9FbjsN CiAgICAgRnJlZXplX0VuPD10ZW1wX0ZyZWV6ZV9FbjsNCg0KICAgICAtLSBjeWNsZSA6DQog ICAgIGNsazw9dHJ1ZTsgICAgICAgIC0tIHJpc2luZyBlZGdlDQogICAgIGN5Y2xlOj1jeWNs ZSsxOyAgIC0tIGFkdmFuY2UgdGhlIGNvdW50ZXINCiAgICAgd2FpdCBmb3IgMTAgbnM7ICAg LS0gbGV0IHRoZSBjaXJjdWl0IGRvIHRoZSB3b3JrDQogICAgIGNsazw9ZmFsc2U7ICAgICAg IC0tIGZhbGxpbmcgZWRnZQ0KICAgICB3YWl0IGZvciAxMCBuczsgICAtLSBsZWF2ZSBzb21l IHRpbWUgdG8gcmVhY3QNCiAgICAgcHJpbnQ7ICAgICAgICAgICAgLS0gYmUgaGFwcHkNCiAg IGVuZCBsb29wOw0KDQogICBmaWxlX2Nsb3NlKHRlc3RfdmVjdG9yKTsNCg0KICAgd2FpdDsg LS0gc3RvcCB0aGUgc2ltdWxhdGlvbg0KIGVuZCBwcm9jZXNzOw0KDQplbmQgdGVzdDE7DQo= --------------BA9A586829A0573B7A2C50A7 Content-Type: text/plain; charset=us-ascii; name="test3.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test3.txt" WA:B WA:BE;write 0xBE at address 0xA WFEDC:BA98,T;write and reset at the same time W2:2 R1 R2; read @ 2 I111:3; invalidate F225:8; freeze Q; Stop analysing the vector file. One line is one cycle and one vector. A void cycle is a void line (or beginning with ';') A vector is, for each cycle, a coma-separated list of upcase letters with parameters when needed. One can put comments after the end of the vector file (like here) or after a ';' placed just after the last command (spaces are not filtered). This is a really dumb parser, you've been warned. created : 10/12/2000, 4am by whygee@f-cpu.org --------------BA9A586829A0573B7A2C50A7-- From Nicolas Matringe Thu Oct 12 09:35:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00414 for ; Thu, 12 Oct 2000 18:16:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:11 +0200 (MEST) Received: (qmail 17439 invoked by uid 0); 12 Oct 2000 07:34:30 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 12 Oct 2000 07:34:30 -0000 X-eGroups-Return: sentto-1101623-1186-971336067-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 12 Oct 2000 07:34:29 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 07:34:27 -0000 Received: (qmail 16794 invoked from network); 12 Oct 2000 07:34:27 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 12 Oct 2000 07:34:27 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 12 Oct 2000 07:34:26 -0000 Received: from IPricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA22276 for ; Thu, 12 Oct 2000 07:34:25 GMT X-To: Message-ID: <39E569AC.9E17DA1E@IPricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39E561D0.EA787A5E@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 09:35:08 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache testbench: naming conventions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c73e67acd121ef6cbb397f700df1abbe Status: R X-Status: N Yann Guidon a =E9crit :
>
> hello,
>
> after some "inactivity" time, i've finally finished
> this testbench for the Icache. It reads text files
> with vectors, and decodes them to all the buses.
[...]
> ---------------------------------------------------------------------<= BR> >            = ;     Name: tb07.vhdl

Hi
I suggest the use of some conventions for clarity.
Naming your testbenches as you do (tbxx.vhd) is not very helpfull.
You'll end up with an awful lot of tb01.vhd (in different directories, I reckon).
I've always used this convention: name your testbenches after the entity they're supposed to test. For example, your ICachetop level is called
ICache.vhd, then name the testbenche ICache_tb.vhd

We also should use VHDL writing conventions for the whole project.
Anyone wants to discuss them?

--
Nicolas MATRINGE          = ; IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FR= ANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/
eGroups Sponsor=
3D""
<= /a>
From Yann Guidon Thu Oct 12 12:06:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00432 for ; Thu, 12 Oct 2000 18:16:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:17 +0200 (MEST) Received: (qmail 15998 invoked by uid 0); 12 Oct 2000 09:02:27 -0000 Received: from fl.egroups.com (208.50.144.74) by mx19.rz2.gmx.net with SMTP; 12 Oct 2000 09:02:27 -0000 X-eGroups-Return: sentto-1101623-1187-971341336-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 12 Oct 2000 09:02:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 09:02:15 -0000 Received: (qmail 3756 invoked from network); 12 Oct 2000 09:02:15 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 12 Oct 2000 09:02:15 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 12 Oct 2000 09:02:15 -0000 Received: from f-cpu.org (nas4-71.ras.club-internet.fr [195.36.203.71]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA08286 for ; Thu, 12 Oct 2000 11:02:11 +0200 (MET DST) Message-ID: <39E58D2A.4EABAE93@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39E561D0.EA787A5E@f-cpu.org> <39E569AC.9E17DA1E@IPricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 11:06:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache testbench: naming conventions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7098ddd307327c2715c3c3a11713c6e2 Status: R X-Status: N hi !

Nicolas Matringe wrote:
> Hi
> I suggest the use of some conventions for clarity.
that can be useful, true :-)

> Naming your testbenches as you do (tbxx.vhd) is not very helpfull.
> You'll end up with an awful lot of tb01.vhd (in different directories, I
> reckon).
i'm sorry if the internal name was kept. but you can change the name at will.
it's an old habit that takes time to vanish.

> I've always used this convention: name your testbenches after the entity
> they're supposed to test. For example, your ICachetop level is called
> ICache.vhd, then name the testbenche ICache_tb.vhd
like in Java ;-)
of course this is wiser for publication, but it was an internal name.
What i expect is that it will be renamed (the file name doesn't affect
the contents) and enhanced (because the contents matters).

> We also should use VHDL writing conventions for the whole project.
> Anyone wants to discuss them?
we've started to discuss about it and i tried to take everything into
account. all enhancements, advices and corrections are welcome anyway :-)
as you remember, i'm still fresh in the VHDL world, so it's the best time
to get good habits.

BTW, did anybody compile/run the test ?
The parser and the surroundings can/will be reused for the
other execution units so we better fix the unstabilities and
incompatibilities ASAP.

> Nicolas MATRINGE           IPricot European Headquarters
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Richard E.Hartney" Thu Oct 12 12:12:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00465 for ; Thu, 12 Oct 2000 18:16:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:26 +0200 (MEST) Received: (qmail 12157 invoked by uid 0); 12 Oct 2000 10:12:55 -0000 Received: from ch.egroups.com (208.50.99.226) by mx12.rz2.gmx.net with SMTP; 12 Oct 2000 10:12:55 -0000 X-eGroups-Return: sentto-1101623-1188-971345567-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 12 Oct 2000 10:12:47 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 10:12:46 -0000 Received: (qmail 22960 invoked from network); 12 Oct 2000 10:12:46 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 12 Oct 2000 10:12:46 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta2 with SMTP; 12 Oct 2000 10:12:46 -0000 Received: from 0018728164 (host-209-214-154-159.bix.bellsouth.net [209.214.154.159]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id GAA07404; Thu, 12 Oct 2000 06:12:43 -0400 (EDT) Message-ID: <004f01c03435$230adf40$9f9ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 05:12:03 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] MUL/DIV Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C0340A.F58DC480" X-UIDL: dfdb7b12a9031b04736311c1628328a4 Status: R X-Status: N ------=_NextPart_000_004C_01C0340A.F58DC480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry Mr. Rares Marion; neither of us can claim originality for the concept= of skipping strings of One's and Zero's. I refer you to the same book I u= se as a reference: The Logic of COMPUTER ARITHMETIC IVAN FLORES Consultant Norwalk, Connectut and Adjunct Professor of Electrical Engineering New York University Published by Prentice-Hall,inc. Library of Congress Catalog Card Number: 63-14727 First Printing 1963 My current designs use these techniques; as I have stated before. I have N= O Register problems as my design is M2M which the group has discarded some ti= me ago - I haven't. I currently have 256K Registers available for software= assignment in Local Memory. The variable execution time does not create a= ny problems whatsoever and is initiated with two MOV instructions for estab= lishing arguments. I was going to offer these instructions as being OPTIONAL but have since de= cided to make them STANDARD as I have more than adequate logic space availa= ble in the Eclipse FPGA I have selected - the QL6600 from Quicklogic. It i= sn't re-programmable but will yield excellent performance compared to XILIN= X.=20=20 Better luck next time. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_004C_01C0340A.F58DC480 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Sorry Mr. Rares Marion; neither of us can claim originality for the concept of skipping strings of One's and Zero's.  I refer you to the same book I use as a reference:
 
        The Logic of COMPUTER ARITHMETIC
        IVAN FLORES
        Consultant Norwalk, Connectut
        and
        Adjunct Professor of Electrical Engineering
        New York University
        Published by Prentice-Hall,inc.
        Library of Congress Catalog Card Number: 63-14727
        First Printing 1963
 
My current designs use these techniques; as I have stated before.  I have NO
Register problems as my design is M2M which the group has discarded some time ago - I haven't.  I currently have 256K Registers available for software assignment in Local Memory.  The variable execution time does not create any problems whatsoever and is initiated with two MOV instructions for establishing arguments.
I was going to offer these instructions as being OPTIONAL but have since decided to make them STANDARD as I have more than adequate logic space available in the Eclipse FPGA I have selected - the QL6600 >from Quicklogic.  It isn't re-programmable but will yield excellent performance compared to XILINX. 
 
Better luck next time.
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
 
 

eGroups Sponsor
------=_NextPart_000_004C_01C0340A.F58DC480-- From Rares Marian Thu Oct 12 12:35:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00477 for ; Thu, 12 Oct 2000 18:16:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:29 +0200 (MEST) Received: (qmail 318 invoked by uid 0); 12 Oct 2000 10:36:59 -0000 Received: from hi.egroups.com (208.50.99.211) by mx11.rz2.gmx.net with SMTP; 12 Oct 2000 10:36:59 -0000 X-eGroups-Return: sentto-1101623-1189-971347017-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 12 Oct 2000 10:36:57 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 10:36:57 -0000 Received: (qmail 14990 invoked from network); 12 Oct 2000 10:36:57 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 12 Oct 2000 10:36:57 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 12 Oct 2000 10:36:57 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id F2D24538FC for ; Thu, 12 Oct 2000 06:35:44 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <004f01c03435$230adf40$9f9ad6d1@0018728164> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 06:35:44 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MUL/DIV Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fd580d07ed142f37c344aac2824e2175 Status: R X-Status: N On Thu, 12 Oct 2000, Richard E.Hartney wrote:

> Sorry Mr. Rares Marion; neither of us can claim originality for the concept of skipping strings of One's and Zero's.  I refer you to the same book I use as a reference:
>
>         The Logic of COMPUTER ARITHMETIC
>         IVAN FLORES
>         Consultant Norwalk, Connectut
>         and
>         Adjunct Professor of Electrical Engineering
>         New York University
>         Published by Prentice-Hall,inc.
>         Library of Congress Catalog Card Number: 63-14727
>         First Printing 1963
>
> My current designs use these techniques; as I have stated before.  I have NO
> Register problems as my design is M2M which the group has discarded some time ago - I haven't.  I currently have 256K Registers available for software assignment in Local Memory.  The variable execution time does not create any problems whatsoever and is initiated with two MOV instructions for establishing arguments.
> I was going to offer these instructions as being OPTIONAL but have since decided to make them STANDARD as I have more than adequate logic space available in the Eclipse FPGA I have selected - the QL6600 from Quicklogic.  It isn't re-programmable but will yield excellent performance compared to XILINX. 

Hmm.  I've been pondering script based CPUs on all fronts: graphics,
i/o, sound, networking, webcams.  The DMCA drives me toward this for
obvious reasons.  M2M could be the missing piece.  Scan string.  Create
hash as operation.  Do work.  Registers would suck at this. 

M2M seems limited, though I may just be biased.

> Better luck next time.

Oddly enough, I just wrote a letter to a person who is consulting with me
on a book on the DMCA.  I used the word originality in that letter to mean
you put in effort to get work done, not uniqueness.

I love the date, 1963.  High tech indeed.  I'm scared to see so many
people amazed with current technology.  It does not bode well for real
innovators.

> Sincerely
> Richard E. Hartney
> Research Director
> Erin Greene & Associates

Rares

 From "Richard E.Hartney" Thu Oct 12 13:31:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00486 for ; Thu, 12 Oct 2000 18:16:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:32 +0200 (MEST) Received: (qmail 2962 invoked by uid 0); 12 Oct 2000 11:30:52 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 12 Oct 2000 11:30:52 -0000 X-eGroups-Return: sentto-1101623-1190-971350239-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 12 Oct 2000 11:30:39 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 11:30:39 -0000 Received: (qmail 4507 invoked from network); 12 Oct 2000 11:30:39 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 12 Oct 2000 11:30:39 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta1 with SMTP; 12 Oct 2000 11:30:38 -0000 Received: from 0018728164 (host-209-215-24-30.bix.bellsouth.net [209.215.24.30]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id HAA21123; Thu, 12 Oct 2000 07:30:36 -0400 (EDT) Message-ID: <000b01c03440$041c78e0$1e18d7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 06:31:49 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DMCA? Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C03416.1A30BB20" X-UIDL: e089dbf8f86980d231edbadb3a6ae183 Status: R X-Status: N ------=_NextPart_000_0008_01C03416.1A30BB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is DMCA? All of you people use abbreviation language and assume that = everyone knows what it means. For clarity I always make statements as foll= ows: My design uses an FBC (Fully Buffered Channel) instead of a DMA (Direct Mem= ory Access) channel. They are logically identical; the difference is their= application. Hartney ------=_NextPart_000_0008_01C03416.1A30BB20 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
What is DMCA?  All of you people use abbreviation language and assume that everyone knows what it means.  For clarity I always make statements as follows:
 
My design uses an FBC (Fully Buffered Channel) instead of a DMA (Direct Memory Access) channel.  They are logically identical; the difference is their application.
 
Hartney

eGroups Sponsor
------=_NextPart_000_0008_01C03416.1A30BB20-- From "Richard E.Hartney" Thu Oct 12 14:35:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00498 for ; Thu, 12 Oct 2000 18:16:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:35 +0200 (MEST) Received: (qmail 14168 invoked by uid 0); 12 Oct 2000 12:33:56 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 12 Oct 2000 12:33:56 -0000 X-eGroups-Return: sentto-1101623-1191-971354031-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 12 Oct 2000 12:33:52 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 12:33:51 -0000 Received: (qmail 30552 invoked from network); 12 Oct 2000 12:33:51 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 12 Oct 2000 12:33:51 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta2 with SMTP; 12 Oct 2000 12:33:50 -0000 Received: from 0018728164 (host-209-215-11-181.bix.bellsouth.net [209.215.11.181]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id IAA24075; Thu, 12 Oct 2000 08:33:48 -0400 (EDT) Message-ID: <000801c03448$d8be1740$b50bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 07:35:02 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] General Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0341E.EEE4A900" X-UIDL: 2c15d1f272faab39a4083930bd88fc33 Status: R X-Status: N ------=_NextPart_000_0005_01C0341E.EEE4A900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am suggesting that LEAPING to 64 Bit using FPGA's is the wrong way to go. Go 32 Bit first untill you see the FULL picture and use FPGA's. Better cha= nce of fitting all of your functionality into a single device. Then you will see = that you can only go for 64 Bit in ASIC. Hartney ------=_NextPart_000_0005_01C0341E.EEE4A900 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
I am suggesting that LEAPING to 64 Bit using FPGA's is the wrong way to go.
Go 32 Bit first untill you see the FULL picture and use FPGA's.  Better chance of
fitting all of your functionality into a single device.  Then you will see that you can only go for 64 Bit in ASIC.
 
Hartney

eGroups Sponsor
------=_NextPart_000_0005_01C0341E.EEE4A900-- From Amaury JACQUOT Thu Oct 12 14:18:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00501 for ; Thu, 12 Oct 2000 18:16:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:36 +0200 (MEST) Received: (qmail 17518 invoked by uid 0); 12 Oct 2000 12:39:22 -0000 Received: from b05.egroups.com (208.50.144.96) by mx11.rz2.gmx.net with SMTP; 12 Oct 2000 12:39:22 -0000 X-eGroups-Return: sentto-1101623-1192-971354337-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by b05.egroups.com with NNFMP; 12 Oct 2000 12:39:06 -0000 X-Sender: sxpert@sxpert.dyndns.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 12:38:57 -0000 Received: (qmail 6076 invoked from network); 12 Oct 2000 12:38:56 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 12 Oct 2000 12:38:56 -0000 Received: from unknown (HELO sxpert.dyndns.org) (212.43.199.14) by mta3 with SMTP; 12 Oct 2000 12:38:56 -0000 Received: (from sxpert@localhost) by sxpert.dyndns.org (8.9.3/8.9.3) id OAA32626 for f-cpu@egroups.com; Thu, 12 Oct 2000 14:18:47 +0200 To: f-cpu@egroups.com Message-ID: <20001012141847.A32615@sxpert.localhost> References: <000b01c03440$041c78e0$1e18d7d1@0018728164> X-Mailer: Mutt 1.0pre3us In-Reply-To: <000b01c03440$041c78e0$1e18d7d1@0018728164> From: Amaury JACQUOT MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 14:18:47 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DMCA? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b18620d4062880df72f713b58effa63e Status: R X-Status: N On Thu, Oct 12, 2000 at 06:31:49AM -0500, Richard E.Hartney wrote:
> What is DMCA?  All of you people use abbreviation language and assume that everyone knows what it means.  For clarity I always make statements as follows:

you should find another acronym, this one is confusing... ;-)

Amaury

>
> My design uses an FBC (Fully Buffered Channel) instead of a DMA (Direct Memory Access) channel.  They are logically identical; the difference is their application.
>
> Hartney
eGroups Sponsor
From Alan Grimes Thu Oct 12 14:43:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00504 for ; Thu, 12 Oct 2000 18:16:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:36 +0200 (MEST) Received: (qmail 3098 invoked by uid 0); 12 Oct 2000 12:42:16 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 12 Oct 2000 12:42:16 -0000 X-eGroups-Return: sentto-1101623-1193-971354508-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 12 Oct 2000 12:41:49 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 12:41:47 -0000 Received: (qmail 30682 invoked from network); 12 Oct 2000 12:41:47 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Oct 2000 12:41:47 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta1 with SMTP; 12 Oct 2000 12:41:47 -0000 Received: from 216-164-137-180.s434.tnt4.lnhva.md.dialup.rcn.com ([216.164.137.180] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13jhgA-0007Je-00 for f-cpu@egroups.com; Thu, 12 Oct 2000 08:41:46 -0400 Message-ID: <39E5B20A.E1B71E5D@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <000b01c03440$041c78e0$1e18d7d1@0018728164> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 08:43:54 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DMCA? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd017d09af8d7d33d3cc43c40bb27480 Status: R X-Status: N > Richard E.Hartney wrote:
>
> What is DMCA?  All of you people use abbreviation language and assume
> that everyone knows what it means. 

I'll echo this notion. =P Often when I come accross a message that uses a
lot of abreviations I have no choice to but to treat it as if it were in a
foreign language that I don't understand.

DMCA == ,I think, Digital Millinium Copyright Act.

It is a bad law that sorely infringes on people's "Fair Use" rights. It
gives content providers far too much power.

Slashdot, particularly in their /yro section, has much to say on this.
You can also find DMCA material at www.openDVD.org and www.eff.org

--
In this year's presidential race you *do* have a choice!
VOTE Browne/Olivier The ticket to freedom!
http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers fbi chemical weapons twa 800 roswell terrorist freedom
eGroups Sponsor
From Rares Marian Thu Oct 12 14:43:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00507 for ; Thu, 12 Oct 2000 18:16:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:37 +0200 (MEST) Received: (qmail 7502 invoked by uid 0); 12 Oct 2000 12:44:33 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 12 Oct 2000 12:44:33 -0000 X-eGroups-Return: sentto-1101623-1194-971354666-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 12 Oct 2000 12:44:32 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 12:44:26 -0000 Received: (qmail 20085 invoked from network); 12 Oct 2000 12:44:25 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Oct 2000 12:44:25 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 12 Oct 2000 12:44:25 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 530FB538FC for ; Thu, 12 Oct 2000 08:43:12 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <000b01c03440$041c78e0$1e18d7d1@0018728164> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 08:43:12 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] DMCA? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c4a61ba9638766b0338efdafcccb8276 Status: R X-Status: N Digital Millenium Copyright Act

A little vague piece of paper that is causing every looter in the business
to claim ownership even of products they didn't make.  The DMCA doesn't
actually allow what they say it allows, but they get away with it in the
name of anitpiracy.

If someone wrote a Linux driver for the Digital Convergence CueCat (that
free barcode reader Radio Shack is giving away), whose property is it
DCs? or the driver author's?

Digital Convergence claims it's theirs.  They cite the DMCA like some
fundamentalist might claim the Bible ordains holy wars.

Sorry if I seem irate.  The DMCA doesn't scare me that much.  Several
senators fixed the original draft which was much more poisonous to the
industry.  What scares me is the far fetched claims corporations are
getting awy with and the fact that people buy every word.

I have a 3 MB file to attach if you're interested.

Rares

PS: Wow!  I've seen 3 responses WHILE writing this response (pine lets me
know these things.)
eGroups Sponsor
From "Richard E.Hartney" Thu Oct 12 16:59:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00534 for ; Thu, 12 Oct 2000 18:16:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 12 Oct 2000 18:16:43 +0200 (MEST) Received: (qmail 25804 invoked by uid 0); 12 Oct 2000 14:58:15 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 12 Oct 2000 14:58:15 -0000 X-eGroups-Return: sentto-1101623-1197-971362690-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by b05.egroups.com with NNFMP; 12 Oct 2000 14:58:09 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 14:58:09 -0000 Received: (qmail 1356 invoked from network); 12 Oct 2000 14:58:09 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 12 Oct 2000 14:58:09 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta1 with SMTP; 12 Oct 2000 14:58:09 -0000 Received: from 0018728164 (host-208-60-244-211.bix.bellsouth.net [208.60.244.211]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id KAA13217; Thu, 12 Oct 2000 10:57:48 -0400 (EDT) Message-ID: <001801c0345c$f7774bc0$d3f43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 09:59:00 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DMCA Response Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C03433.0B757F40" X-UIDL: 1e5f2bc483b71cca31ef681aa03881a9 Status: R X-Status: N ------=_NextPart_000_0015_01C03433.0B757F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mr. Amaury JACQUOT - I am not at all certain if you are confused about my D= MCA query or FBC and DMA. If you don't know what an FBC or DMA is; you ar= e in the wrong business or should go back to school. I was using the terms = as an example and have been used for over 40 years. Hartney ------=_NextPart_000_0015_01C03433.0B757F40 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Mr. Amaury JACQUOT - I am not at all certain if you are confused about my DMCA query or FBC and DMA.   If you don't know what an FBC or DMA is; you are in the wrong business or should go back to school. I was using the terms as an example
and have been used for over 40 years.
 
Hartney

eGroups Sponsor
------=_NextPart_000_0015_01C03433.0B757F40-- From Michael Riepe Thu Oct 12 14:26:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00567 for ; Fri, 13 Oct 2000 18:40:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:40:42 +0200 (MEST) Received: (qmail 13808 invoked by uid 0); 12 Oct 2000 22:16:08 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 12 Oct 2000 22:16:08 -0000 X-eGroups-Return: sentto-1101623-1198-971388931-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 12 Oct 2000 22:16:07 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 22:15:30 -0000 Received: (qmail 1093 invoked from network); 12 Oct 2000 22:15:29 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 12 Oct 2000 22:15:29 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta3 with SMTP; 12 Oct 2000 22:15:26 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00458; Thu, 12 Oct 2000 14:26:16 +0200 Message-ID: <20001012142616.51573@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> X-Mailer: Mutt 0.84e In-Reply-To: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM>; from Erik Fischer on Wed, Oct 11, 2000 at 09:53:29PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 14:26:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af81e7ed0b393d18976492fae40e38da Status: R X-Status: N On Wed, Oct 11, 2000 at 09:53:29PM -0700, Erik Fischer wrote:
> Please me too, I just can't take myself off this list!!!

That's absolutely no excuse for a full quote.

Shouldn't we try to find somebody at egroups who enters a new list
administrator into their database?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Alan Grimes Fri Oct 13 00:43:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00570 for ; Fri, 13 Oct 2000 18:40:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:40:43 +0200 (MEST) Received: (qmail 18011 invoked by uid 0); 12 Oct 2000 22:43:04 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 12 Oct 2000 22:43:04 -0000 X-eGroups-Return: sentto-1101623-1199-971390457-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ci.egroups.com with NNFMP; 12 Oct 2000 22:41:27 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 22:40:57 -0000 Received: (qmail 16184 invoked from network); 12 Oct 2000 22:40:56 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 12 Oct 2000 22:40:56 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 12 Oct 2000 22:40:56 -0000 Received: from 209-122-203-105.s359.tnt6.lnhva.md.dialup.rcn.com ([209.122.203.105] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13jr1z-0007AG-00 for f-cpu@egroups.com; Thu, 12 Oct 2000 18:40:55 -0400 Message-ID: <39E63E76.CBEF80A3@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> <20001012142616.51573@thrai.stud.uni-hannover.de> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 18:43:02 -0400 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3fff7462dea9b32fe5c3e52960b12ae7 Status: R X-Status: N List unsubscribe info:

""
            Unsubscribe:
                         f-cpu-unsubscribe@egroups.com
""

--
In this year's presidential race you *do* have a choice!
VOTE Browne/Olivier The ticket to freedom!
http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers fbi chemical weapons twa 800 roswell terrorist freedom
eGroups Sponsor
From Erik Fischer Fri Oct 13 01:09:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00579 for ; Fri, 13 Oct 2000 18:40:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:40:46 +0200 (MEST) Received: (qmail 10235 invoked by uid 0); 12 Oct 2000 23:09:16 -0000 Received: from f19.egroups.com (208.50.99.238) by mx0.gmx.net with SMTP; 12 Oct 2000 23:09:16 -0000 X-eGroups-Return: sentto-1101623-1200-971392149-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 12 Oct 2000 23:09:14 -0000 X-Sender: Erik.Fischer@hungary.sun.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 12 Oct 2000 23:09:08 -0000 Received: (qmail 32367 invoked from network); 12 Oct 2000 23:09:08 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Oct 2000 23:09:08 -0000 Received: from unknown (HELO mercury.Sun.COM) (192.9.25.1) by mta2 with SMTP; 12 Oct 2000 23:09:08 -0000 Received: from dunaserv.Hungary.Sun.COM ([129.159.190.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16619 for ; Thu, 12 Oct 2000 16:09:05 -0700 (PDT) Received: from srsun02c (srsun02c.Eng.Sun.COM [129.144.135.63]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id BAA12574 for ; Fri, 13 Oct 2000 01:09:01 +0200 (MET DST) Message-Id: <200010122309.BAA12574@dunaserv.Hungary.Sun.COM> To: f-cpu@egroups.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc From: Erik Fischer MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Oct 2000 16:09:01 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: multipart/mixed; boundary="Brood_of_Chickens_719_000" X-UIDL: 1adc9416ce6196a56c52e02c2e5f09b3 Status: R X-Status: N --Brood_of_Chickens_719_000 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit I have tried that a million times, I am not member of this group
according to my profile and the list admin software... But I am
getting every single mail. I got off from this list several months ago,
but automagically I am recieving everything again... This is just ridiculous.
Eric

>
>List unsubscribe info:
>
>""
>            Unsubscribe:
>                         f-cpu-unsubscribe@egroups.com
>""
>
>--
>In this year's presidential race you *do* have a choice!
>VOTE Browne/Olivier The ticket to freedom!
>http://users.erols.com/alangrimes/  <my website.
>
>####### Begin Eschelon Block #######
>unibomber anthrax plutonium militia delta force ruby ridge atf batf waco
>oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
>mlk panthers fbi chemical weapons twa 800 roswell terrorist freedom
>
>
>
>
eGroups Sponsor
--Brood_of_Chickens_719_000 Content-Type: MESSAGE/rfc822; name=Mailbox Content-Description: Mailbox MIME-Version: 1.0 Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id AAA09939 for ; Fri, 13 Oct 2000 00:45:20 +0200 (MET DST) Received: from ho.egroups.com (ho.egroups.com [208.50.99.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA21629 for ; Thu, 12 Oct 2000 16:45:17 -0600 (MDT) Received: from [10.1.10.38] by ho.egroups.com with NNFMP; 12 Oct 2000 22:45:16 -0000 Received: (qmail 4569 invoked by alias); 12 Oct 2000 22:45:14 -0000 Date: 12 Oct 2000 22:45:14 -0000 Message-ID: <971390714.4555@egroups.com> MIME-Version: 1.0 To: Erik.Fischer@hungary.sun.com From: eGroups Subject: Unable to process your message Content-Type: multipart/mixed; boundary="PCDQWujdIPklGbVUpnhq9EfhpxoebjSzugNRY62" Content-Length: 2475 --PCDQWujdIPklGbVUpnhq9EfhpxoebjSzugNRY62 Content-Type: text/plain Content-Transfer-Encoding: 7bit The email address used to send your message is not subscribed to this group. If you are a member of this group, please be aware that you may only send messages and manage your subscription to this group using the email address(es) you have registered with eGroups. eGroups allows you to use the email address you originally used to register, or an alternate email address you specify in your personal settings. If you would like to subscribe to this group: 1. visit http://www.egroups.com/subscribe/f-cpu -OR- 2. send email to f-cpu-subscribe@egroups.com If you would like to specify an alternate email address: 1. visit http://www.egroups.com/myprofile 2. click the "Edit Profile" button 3. type your alternate email address in the area labeled "Alternate email addresses". 4. click the "Save Changes" button 5. wait approximately 10 minutes for the change to take effect After you follow these steps, you will be able to send messages to all your groups using this alternate email address. For further assistance, please email support@egroups.com or visit http://www.egroups.com/help --PCDQWujdIPklGbVUpnhq9EfhpxoebjSzugNRY62 Content-Type: message/rfc822 Received: (qmail 4545 invoked from network); 12 Oct 2000 22:45:14 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Oct 2000 22:45:14 -0000 Received: from unknown (HELO mercury.Sun.COM) (192.9.25.1) by mta2 with SMTP; 12 Oct 2000 22:45:14 -0000 Received: from dunaserv.Hungary.Sun.COM ([129.159.190.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07687 for ; Thu, 12 Oct 2000 15:45:10 -0700 (PDT) Received: from srsun02c (srsun02c.Eng.Sun.COM [129.144.135.63]) by dunaserv.Hungary.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id AAA09913 for ; Fri, 13 Oct 2000 00:45:06 +0200 (MET DST) Message-Id: <200010122245.AAA09913@dunaserv.Hungary.Sun.COM> Date: Thu, 12 Oct 2000 15:45:05 -0700 (PDT) From: Erik Fischer Reply-To: Erik Fischer Subject: unsubscribe To: f-cpu-unsubscribe@egroups.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hdeBTR4qbJ4p96fDbDRqhQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc unsubscribe --PCDQWujdIPklGbVUpnhq9EfhpxoebjSzugNRY62-- --Brood_of_Chickens_719_000-- From Yann Guidon Fri Oct 13 04:32:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00591 for ; Fri, 13 Oct 2000 18:40:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:40:52 +0200 (MEST) Received: (qmail 12030 invoked by uid 0); 13 Oct 2000 01:28:13 -0000 Received: from ml.egroups.com (208.50.144.77) by mx19.rz2.gmx.net with SMTP; 13 Oct 2000 01:28:13 -0000 X-eGroups-Return: sentto-1101623-1202-971400488-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 13 Oct 2000 01:28:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 01:28:08 -0000 Received: (qmail 32130 invoked from network); 13 Oct 2000 01:28:08 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 13 Oct 2000 01:28:08 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 13 Oct 2000 01:28:08 -0000 Received: from f-cpu.org (nas1-174.ras.club-internet.fr [195.36.192.174]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA23685 for ; Fri, 13 Oct 2000 03:28:05 +0200 (MET DST) Message-ID: <39E67445.FFF8FD35@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> <20001012142616.51573@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 03:32:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a83c2deadd044325c13186459f95cf61 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Wed, Oct 11, 2000 at 09:53:29PM -0700, Erik Fischer wrote:
> > Please me too, I just can't take myself off this list!!!
> That's absolutely no excuse for a full quote.
true.

> Shouldn't we try to find somebody at egroups who enters a new list
> administrator into their database?
maybe, but still, this is NO excuse. there are two rules :
- keep in archive the direction to unsubscribe. they are sent
   when one subscribes to the list.
- look at the mail header that ALSO contains hints.
If somebody volunteers to manage the list,
he/she will be flooded with requests that could have been
done otherwise.
  
a bit of nettiquette helps, too. we're not in the jungle, here.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 13 04:32:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00594 for ; Fri, 13 Oct 2000 18:40:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:40:52 +0200 (MEST) Received: (qmail 6924 invoked by uid 0); 13 Oct 2000 01:28:14 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 13 Oct 2000 01:28:14 -0000 X-eGroups-Return: sentto-1101623-1201-971400487-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by b05.egroups.com with NNFMP; 13 Oct 2000 01:28:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 01:28:06 -0000 Received: (qmail 32172 invoked from network); 13 Oct 2000 01:28:06 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 13 Oct 2000 01:28:06 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 13 Oct 2000 01:28:05 -0000 Received: from f-cpu.org (nas1-174.ras.club-internet.fr [195.36.192.174]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA25389 for ; Fri, 13 Oct 2000 03:28:03 +0200 (MET DST) Message-ID: <39E67442.FC3CEFB6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200010122309.BAA12574@dunaserv.Hungary.Sun.COM> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 03:32:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8085a330c4ea9f6a55a700c66aa59050 Status: R X-Status: N Erik Fischer wrote:

<snip>

this list is not going well...

but how can we contact the eGroups management ?

tired WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 13 14:17:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00637 for ; Fri, 13 Oct 2000 18:41:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 13 Oct 2000 18:41:10 +0200 (MEST) Received: (qmail 24592 invoked by uid 0); 13 Oct 2000 11:12:39 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 13 Oct 2000 11:12:39 -0000 X-eGroups-Return: sentto-1101623-1203-971435554-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ch.egroups.com with NNFMP; 13 Oct 2000 11:12:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 11:12:33 -0000 Received: (qmail 20975 invoked from network); 13 Oct 2000 11:12:33 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Oct 2000 11:12:33 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 13 Oct 2000 11:12:33 -0000 Received: from f-cpu.org (nas2-230.ras.club-internet.fr [195.36.192.230]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA01653 for ; Fri, 13 Oct 2000 13:12:30 +0200 (MET DST) Message-ID: <39E6FD40.A03E31AA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 13:17:04 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL guidelines Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 54086f20a25a7e064d65aae6c06438a4 Status: R X-Status: N hello,

Mr Matringe and Colin have proposed to make a document
that contains the VHDL guidelines. Jeff also volunteered
to write a glossary. Before we can setup a public ftp
account, we can use the eGroups facilities of the mailing
list : the website can host around 10MB. so go check it
and tell us about your efforts.

one restriction, though, is that you must be logged in
(cookies on+pwd+email address) to upload and download the
files on the site at http://www.egroups.com/files/f-cpu/.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Oct 14 00:06:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00357 for ; Sat, 14 Oct 2000 17:48:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:29 +0200 (MEST) Received: (qmail 3010 invoked by uid 0); 13 Oct 2000 21:02:18 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 13 Oct 2000 21:02:17 -0000 X-eGroups-Return: sentto-1101623-1204-971470918-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hn.egroups.com with NNFMP; 13 Oct 2000 21:02:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 21:01:57 -0000 Received: (qmail 4060 invoked from network); 13 Oct 2000 21:01:57 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 13 Oct 2000 21:01:57 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 13 Oct 2000 21:01:57 -0000 Received: from f-cpu.org (nas2-206.ras.club-internet.fr [195.36.192.206]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA19359 for ; Fri, 13 Oct 2000 23:01:53 +0200 (MET DST) Message-ID: <39E78760.9D539839@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 23:06:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) VHDL guidelines : 2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 83c9333969aaa3012b5d0d8a5c844d4c Status: R X-Status: N hello,

As written before, some people have proposed to write
a draft of the coding style of the VHDL sources.

Here, i propose some F-CPU specific guidelines
and recommendations that will ensure the compatibility
of the sources inside the project.

These guidelines are less specific to the langage
because they can apply to schematics, C simulators or
VHDL. Some of them are more specific to the FC0, currently
under definition.

- Always define the data widths from the only "characteristic
size" that applies. For example :
  * The width of the register is also the width of the
     execution units and the Xbar.
  * Internal buses that are not linked to the core itself
     (for example : the external memory bus situated
     outside of the memory controler) should have its
     own name, so it can be changed independently of
     the other sizes.

- Some "characteristic widths" :
  * register width (it defines almost all the rest
      in the execution core)
  * external data bus width, for the private memory
  * external I/O bus width
  * cache and memory sizes (in cache lines, line width
      and address bus widths)

- It is necessary that all "characteristic widths"
are defined with the same name (or similar, when
otherwise impossible) on the different coding langages :
C, VHDL, Verilog, whatever...

- In the end, it should be possible to recompile
or resynthetize the files with one changed parameter,
without having to change another single character.
Of course, there are restrictions on the possible values
taken by certain parameters.

- The "parameters" names are not yet all standardized.
The files "f-cpu_map.h" and "SR.h" contain some of them
but it is not exhaustive. we need additional work in
this domain.

- Of course, like the rest, all these elements can change
during the discussions on the mailing list f-cpu@egroups.com.
feedback, advices and constructive criticisms are expected
and welcome.

- After the document has reached a satisfying and coherent shape,
this draft will be published as part of the F-CPU manual,
under the Gnu Free Documentation Licence.

ok, now, back to VHDL.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jamil Khatib Fri Oct 13 23:31:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00363 for ; Sat, 14 Oct 2000 17:48:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:31 +0200 (MEST) Received: (qmail 10523 invoked by uid 0); 13 Oct 2000 21:31:10 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 13 Oct 2000 21:31:10 -0000 X-eGroups-Return: sentto-1101623-1205-971472667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 13 Oct 2000 21:31:09 -0000 X-Sender: jamilkhatib75@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 21:31:06 -0000 Received: (qmail 15815 invoked from network); 13 Oct 2000 21:31:06 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 13 Oct 2000 21:31:06 -0000 Received: from unknown (HELO web1102.mail.yahoo.com) (128.11.23.122) by mta3 with SMTP; 13 Oct 2000 21:31:06 -0000 Received: (qmail 15827 invoked by uid 60001); 13 Oct 2000 21:31:05 -0000 Message-ID: <20001013213105.15826.qmail@web1102.mail.yahoo.com> Received: from [212.179.38.151] by web1102.mail.yahoo.com; Fri, 13 Oct 2000 14:31:05 PDT To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 14:31:05 -0700 (PDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) VHDL guidelines : 2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 455a761b8bf72370fad9fb83673fc7bd Status: R X-Status: N my be the OpenIPCore vhdl guidelines will help you.
try to look at www.opencores.org/OIPC

Regards
Jamil Khatib

--- Yann Guidon <whygee@f-cpu.org> wrote:
> hello,
>
> As written before, some people have proposed to
> write
> a draft of the coding style of the VHDL sources.
>
> Here, i propose some F-CPU specific guidelines
> and recommendations that will ensure the
> compatibility
> of the sources inside the project.
>
> These guidelines are less specific to the langage
> because they can apply to schematics, C simulators
> or
> VHDL. Some of them are more specific to the FC0,
> currently
> under definition.
>
> - Always define the data widths from the only
> "characteristic
> size" that applies. For example :
>   * The width of the register is also the width of
> the
>      execution units and the Xbar.
>   * Internal buses that are not linked to the core
> itself
>      (for example : the external memory bus situated
>      outside of the memory controler) should have
> its
>      own name, so it can be changed independently of
>      the other sizes.
>
> - Some "characteristic widths" :
>   * register width (it defines almost all the rest
>       in the execution core)
>   * external data bus width, for the private memory
>   * external I/O bus width
>   * cache and memory sizes (in cache lines, line
> width
>       and address bus widths)
>
> - It is necessary that all "characteristic widths"
> are defined with the same name (or similar, when
> otherwise impossible) on the different coding
> langages :
> C, VHDL, Verilog, whatever...
>
> - In the end, it should be possible to recompile
> or resynthetize the files with one changed
> parameter,
> without having to change another single character.
> Of course, there are restrictions on the possible
> values
> taken by certain parameters.
>
> - The "parameters" names are not yet all
> standardized.
> The files "f-cpu_map.h" and "SR.h" contain some of
> them
> but it is not exhaustive. we need additional work in
> this domain.
>
> - Of course, like the rest, all these elements can
> change
> during the discussions on the mailing list
> f-cpu@egroups.com.
> feedback, advices and constructive criticisms are
> expected
> and welcome.
>
> - After the document has reached a satisfying and
> coherent shape,
> this draft will be published as part of the F-CPU
> manual,
> under the Gnu Free Documentation Licence.
>
> ok, now, back to VHDL.
> WHYGEE
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -------------------------- eGroups Sponsor
>
>
>


__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
eGroups Sponsor
From Michael Riepe Sat Oct 14 00:20:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00375 for ; Sat, 14 Oct 2000 17:48:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:34 +0200 (MEST) Received: (qmail 11762 invoked by uid 0); 13 Oct 2000 22:22:57 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net with SMTP; 13 Oct 2000 22:22:57 -0000 X-eGroups-Return: sentto-1101623-1206-971475749-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ho.egroups.com with NNFMP; 13 Oct 2000 22:22:42 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 22:22:29 -0000 Received: (qmail 13393 invoked from network); 13 Oct 2000 22:22:29 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 13 Oct 2000 22:22:29 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.58) by mta3 with SMTP; 13 Oct 2000 22:22:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00504; Sat, 14 Oct 2000 00:20:55 +0200 Message-ID: <20001014002055.45060@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Oct 2000 00:20:55 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] latest multiplier news Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" X-UIDL: d6c229c377b454146cac337bebd20dd5 Status: R X-Status: N --ZPt4rx8FFjLCG7dd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Buon giorno!

Friday 13th is over, and here's the first release of the 64-bit multiplier
(codename: Full Moon ;).  It doesn't support fractional numbers yet
and is mostly untested (2^16 test patterns take 30 minutes, so...).

I'm looking for a program that can compare boolean expressions quickly
(and tell me whether they're equivalent) -- with that, I could confirm
that the implementation works correctly in all modes.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Description: 8x8 multiplier Content-Disposition: attachment; filename="imul8.vhdl" -- imul8.vhdl - F-CPU 8x8-Bit Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: imul8.vhdl,v 1.2 2000/10/11 12:16:16 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; -- -- 8xN-bit signed/unsigned multiplier/adder -- entity Mul8xN is generic ( BWIDTH : natural := 8 -- width of multiplicator (affects output width) ); port ( -- inputs A : in std_ulogic_vector(7 downto 0); B : in std_ulogic_vector(BWIDTH-1 downto 0); -- optional full-width `add' input X : in std_ulogic_vector(BWIDTH+7 downto 0) := (others => '0'); -- signed/unsigned mode switches SignedA, SignedB : in std_ulogic; -- full-width output Y : out std_ulogic_vector(BWIDTH+7 downto 0) ); end Mul8xN; architecture Arch_1 of Mul8xN is type std_ulogic_matrix is array(natural range <>, natural range <>) of std_ulogic; signal s3 : std_ulogic_matrix(5 downto 0, Y'length-1 downto 0); signal s6 : std_ulogic_matrix(1 downto 0, Y'length-1 downto 0); begin stage1 : process (A, B, X, SignedA, SignedB) variable s1 : std_ulogic_matrix(10 downto 0, Y'length-1 downto 0); variable s2 : std_ulogic_matrix(7 downto 0, Y'length-1 downto 0); variable Aneg, Bneg : std_ulogic; begin -- -- unsigned multiplier bit matrix -- s1 := (others => (others => '0')); for j in A'length-1 downto 0 loop for i in B'length-1 downto 0 loop s1(j, j + i) := A(A'low + j) and B(B'low + i); end loop; end loop; -- -- additional summand -- for i in X'length-1 downto 0 loop s1(8, i) := X(X'low + i); end loop; -- -- subtract B << A'length if A < 0 -- Aneg := SignedA and A(A'high); for i in B'length-1 downto 0 loop s1(9, A'length + i) := Aneg and not B(B'low + i); end loop; -- place carry in unused bit(s) for i in A'length-1 downto 0 loop s1(9, i) := Aneg; end loop; s1(1, 0) := Aneg; -- -- subtract A << B'length if B < 0 -- Bneg := SignedB and B(B'high); for i in A'length-1 downto 0 loop s1(10, B'length + i) := Bneg and not A(A'low + i); end loop; -- place carry in unused bit s1(0, B'length) := Bneg; -- -- first level of wallace tree -- s2 := (others => (others => '0')); for i in s2'range(2) loop -- -- Note that the tree is slightly irregular. -- This reduces the delay for the last three rows -- and makes room for more sophisticated handling -- of the `X' operand. -- s2(0, i) := s1(0, i); s2(1, i) := s1(1, i); s2(2, i) := s1(2, i) xor s1(3, i) xor s1(4, i); s2(4, i) := s1(5, i) xor s1(6, i) xor s1(7, i); s2(6, i) := s1(8, i) xor s1(9, i) xor s1(10, i); if i < s2'high(2) then s2(3, i+1) := (s1(2, i) and s1(3, i)) or (s1(2, i) and s1(4, i)) or (s1(3, i) and s1(4, i)); s2(5, i+1) := (s1(5, i) and s1(6, i)) or (s1(5, i) and s1(7, i)) or (s1(6, i) and s1(7, i)); s2(7, i+1) := (s1(8, i) and s1(9, i)) or (s1(8, i) and s1(10, i)) or (s1(9, i) and s1(10, i)); end if; end loop; -- -- second level of wallace tree -- s3 <= (others => (others => '0')); for i in s3'range(2) loop s3(0, i) <= s2(0, i) xor s2(1, i) xor s2(2, i); s3(1, i) <= s2(3, i) xor s2(4, i) xor s2(5, i); if i < s3'high(2) then s3(2, i+1) <= (s2(0, i) and s2(1, i)) or (s2(0, i) and s2(2, i)) or (s2(1, i) and s2(2, i)); s3(3, i+1) <= (s2(3, i) and s2(4, i)) or (s2(3, i) and s2(5, i)) or (s2(4, i) and s2(5, i)); end if; s3(4, i) <= s2(6, i); s3(5, i) <= s2(7, i); end loop; end process; stage2 : process (s3) variable s4 : std_ulogic_matrix(3 downto 0, Y'length-1 downto 0); variable s5 : std_ulogic_matrix(2 downto 0, Y'length-1 downto 0); begin -- -- third level of wallace tree -- s4 := (others => (others => '0')); for i in s4'range(2) loop s4(0, i) := s3(0, i) xor s3(1, i) xor s3(2, i); s4(1, i) := s3(3, i) xor s3(4, i) xor s3(5, i); if i < s4'high(2) then s4(2, i+1) := (s3(0, i) and s3(1, i)) or (s3(0, i) and s3(2, i)) or (s3(1, i) and s3(2, i)); s4(3, i+1) := (s3(3, i) and s3(4, i)) or (s3(3, i) and s3(5, i)) or (s3(4, i) and s3(5, i)); end if; end loop; -- -- fourth level of wallace tree -- s5 := (others => (others => '0')); for i in s5'range(2) loop s5(0, i) := s4(0, i) xor s4(1, i) xor s4(2, i); if i < s5'high(2) then s5(1, i+1) := (s4(0, i) and s4(1, i)) or (s4(0, i) and s4(2, i)) or (s4(1, i) and s4(2, i)); end if; s5(2, i) := s4(3, i); end loop; -- -- fifth level of wallace tree -- s6 <= (others => (others => '0')); for i in s6'range(2) loop s6(0, i) <= s5(0, i) xor s5(1, i) xor s5(2, i); if i < s6'high(2) then s6(1, i+1) <= (s5(0, i) and s5(1, i)) or (s5(0, i) and s5(2, i)) or (s5(1, i) and s5(2, i)); end if; end loop; end process; stage3 : process (s6) variable s7, s8 : std_ulogic_vector(Y'length-1 downto 0); begin -- -- carry look-ahead adder -- s8(S8'low) := '0'; for i in s7'low to s7'high loop s7(i) := s6(0, i) xor s6(1, i); if i < s7'high then s8(i+1) := (s6(0, i) and s6(1, i)) or (s7(i) and s8(i)); end if; end loop; Y <= s7 xor s8; end process; end Arch_1; -- vi: set ts=4 sw=4 : please --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Description: wallace tree + adder Content-Disposition: attachment; filename="wallace.vhdl" -- wallace.vhdl - Not So Simple Wallace Tree Adder -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: wallace.vhdl,v 1.3 2000/10/13 22:10:43 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity Wallace is generic ( WIDTH : natural := 4 ); port ( -- inputs A0B0, A0B1, A1B0, A1B1 : in std_ulogic_vector(WIDTH-1 downto 0); -- mode switches Signed01, Signed10 : in std_ulogic; -- output Y : out std_ulogic_vector(2*WIDTH-1 downto 0) ); end Wallace; architecture Arch_1 of Wallace is begin process (A0B0, A0B1, A1B0, A1B1) variable a, b, c, d, e, f : std_ulogic_vector(2*WIDTH-1 downto 0); begin -- tree a := A1B1 & A0B0; b := (others => '0'); b(3*WIDTH/2-1 downto WIDTH/2) := A0B1; b(2*WIDTH-1 downto 3*WIDTH/2) := (others => Signed01 and A0B1(A0B1'left)); c := (others => '0'); c(3*WIDTH/2-1 downto WIDTH/2) := A1B0; c(2*WIDTH-1 downto 3*WIDTH/2) := (others => Signed10 and A1B0(A1B0'left)); d := a xor b xor c; e := (a and b) or (a and c) or (b and c); f := e(e'left-1 downto e'right) & '0'; -- adder a := d xor f; b := d and f; c(0) := '0'; for i in 0 to b'left-1 loop c(i+1) := b(i) or (a(i) and c(i)); end loop; Y <= a xor c; end process; end Arch_1; --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Description: the big picture... Content-Disposition: attachment; filename="imul.vhdl" -- imul.vhdl - F-CPU Integer Multiplication Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: imul.vhdl,v 1.3 2000/10/13 22:10:43 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity IMul is generic ( WIDTH : natural := 64 -- do not change! ); port ( -- normal inputs A, B : in std_ulogic_vector(WIDTH-1 downto 0); -- optional adder input X : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); -- mode switch SignedMode : in std_ulogic; -- SIMD switches U8, U16, U32 : in std_ulogic; -- 8-bit SIMD result Y8l, Y8h : out std_ulogic_vector(WIDTH-1 downto 0); -- 16-bit SIMD result Y16l, Y16h : out std_ulogic_vector(WIDTH-1 downto 0); -- 32-bit SIMD result Y32l, Y32h : out std_ulogic_vector(WIDTH-1 downto 0); -- 64-bit result Y : out std_ulogic_vector(2*WIDTH-1 downto 0) ); end IMul; architecture Arch_1 of IMul is constant ROWS : natural := WIDTH / 8; type Matrix16 is array (natural range <>, natural range <>) of std_ulogic_vector(15 downto 0); type Matrix32 is array (natural range <>, natural range <>) of std_ulogic_vector(31 downto 0); type Matrix64 is array (natural range <>, natural range <>) of std_ulogic_vector(63 downto 0); signal Xtmp : Matrix16(ROWS-1 downto 0, ROWS-1 downto 0); signal Y16tmp : Matrix16(ROWS-1 downto 0, ROWS-1 downto 0); signal Y32tmp : Matrix32(ROWS/2-1 downto 0, ROWS/2-1 downto 0); signal Y64tmp : Matrix64(ROWS/4-1 downto 0, ROWS/4-1 downto 0); signal S : std_ulogic_vector(ROWS-1 downto 0); begin -- -- mode switching -- S <= ( 7 => SignedMode, 3 => SignedMode and not U32, 5 | 1 => SignedMode and not U16, 6 | 4 | 2 | 0 => SignedMode and not U8 ); -- -- multiply-and-add inputs -- process (X, U8, U16, U32) begin -- -- This is tricky. Only the most significant partial -- product may be added with a full-size summand in -- order to avoid overflows in the partial products. -- Half-size summands (high part set to zero) are ok -- because the result of an `8*8+8' operation will not -- overflow when at least one of the multiplicands -- is treated as an unsigned quantity (which is the -- case for all partial products except the most -- significant one): -- -- s * u: y <= 127 * 255 + 255 = 128 * 255 < 32768 -- u * u: y <= 255 * 255 + 255 = 256 * 255 < 65536 -- Xtmp <= (others => (others => (others => '0'))); if U8 /= '1' then -- 8-bit mode: use A0B0, A1B1 ... A7B7 -- macl Xtmp(0, 0)(15 downto 0) <= X(15 downto 0); Xtmp(1, 1)(15 downto 0) <= X(31 downto 16); Xtmp(2, 2)(15 downto 0) <= X(47 downto 32); Xtmp(3, 3)(15 downto 0) <= X(63 downto 48); -- mach Xtmp(4, 4)(15 downto 0) <= X(15 downto 0); Xtmp(5, 5)(15 downto 0) <= X(31 downto 16); Xtmp(6, 6)(15 downto 0) <= X(47 downto 32); Xtmp(7, 7)(15 downto 0) <= X(63 downto 48); elsif U16 /= '1' then -- 16-bit mode: use A0B0-A0B1-A1B1, A2B2-A2B3-A3B3, ... -- macl Xtmp(0, 0)( 7 downto 0) <= X( 7 downto 0); Xtmp(0, 1)( 7 downto 0) <= X(15 downto 8); Xtmp(1, 1)(15 downto 0) <= X(31 downto 16); Xtmp(2, 2)( 7 downto 0) <= X(39 downto 32); Xtmp(2, 3)( 7 downto 0) <= X(47 downto 40); Xtmp(3, 3)(15 downto 0) <= X(63 downto 48); -- mach Xtmp(4, 4)( 7 downto 0) <= X( 7 downto 0); Xtmp(4, 5)( 7 downto 0) <= X(15 downto 8); Xtmp(5, 5)(15 downto 0) <= X(31 downto 16); Xtmp(6, 6)( 7 downto 0) <= X(39 downto 32); Xtmp(6, 7)( 7 downto 0) <= X(47 downto 40); Xtmp(7, 7)(15 downto 0) <= X(63 downto 48); elsif U32 /= '1' then -- 32-bit mode: use A0B0-A0B3-A3B3 and A4B4-A4B7-A7B7 -- macl Xtmp(0, 0)( 7 downto 0) <= X( 7 downto 0); Xtmp(0, 1)( 7 downto 0) <= X(15 downto 8); Xtmp(0, 2)( 7 downto 0) <= X(23 downto 16); Xtmp(0, 3)( 7 downto 0) <= X(31 downto 24); Xtmp(1, 3)( 7 downto 0) <= X(39 downto 32); Xtmp(2, 3)( 7 downto 0) <= X(47 downto 40); Xtmp(3, 3)(15 downto 0) <= X(63 downto 48); -- mach Xtmp(4, 4)( 7 downto 0) <= X( 7 downto 0); Xtmp(4, 5)( 7 downto 0) <= X(15 downto 8); Xtmp(4, 6)( 7 downto 0) <= X(23 downto 16); Xtmp(4, 7)( 7 downto 0) <= X(31 downto 24); Xtmp(5, 7)( 7 downto 0) <= X(39 downto 32); Xtmp(6, 7)( 7 downto 0) <= X(47 downto 40); Xtmp(7, 7)(15 downto 0) <= X(63 downto 48); else -- 64-bit mode: use A0B0-A0B7 -- macl only Xtmp(0, 0)( 7 downto 0) <= X( 7 downto 0); Xtmp(0, 1)( 7 downto 0) <= X(15 downto 8); Xtmp(0, 2)( 7 downto 0) <= X(23 downto 16); Xtmp(0, 3)( 7 downto 0) <= X(31 downto 24); Xtmp(0, 4)( 7 downto 0) <= X(39 downto 32); Xtmp(0, 5)( 7 downto 0) <= X(47 downto 40); Xtmp(0, 6)( 7 downto 0) <= X(55 downto 48); Xtmp(0, 7)( 7 downto 0) <= X(63 downto 56); end if; end process; -- -- 8x8 multipliers en masse -- rows8 : for j in ROWS-1 downto 0 generate cols8 : for i in ROWS-1 downto 0 generate mul8 : entity work.Mul8xN generic map (BWIDTH => 8) port map ( A => A(8*j+7 downto 8*j), B => B(8*i+7 downto 8*i), X => Xtmp(j, i), SignedA => S(j), SignedB => S(i), Y => Y16tmp(j, i) ); end generate; end generate; -- -- calculate 16x16-bit products -- rows16 : for j in ROWS/2-1 downto 0 generate cols16 : for i in ROWS/2-1 downto 0 generate add16 : entity work.Wallace generic map (WIDTH => 16) port map ( A0B0 => Y16tmp(2*j+0, 2*i+0), A0B1 => Y16tmp(2*j+0, 2*i+1), A1B0 => Y16tmp(2*j+1, 2*i+0), A1B1 => Y16tmp(2*j+1, 2*i+1), Signed01 => S(2*i+1), Signed10 => S(2*j+1), Y => Y32tmp(j, i) ); end generate; end generate; -- -- calculate 32x32-bit products -- rows32 : for j in ROWS/4-1 downto 0 generate cols32 : for i in ROWS/4-1 downto 0 generate add32 : entity work.Wallace generic map (WIDTH => 32) port map ( A0B0 => Y32tmp(2*j+0, 2*i+0), A0B1 => Y32tmp(2*j+0, 2*i+1), A1B0 => Y32tmp(2*j+1, 2*i+0), A1B1 => Y32tmp(2*j+1, 2*i+1), Signed01 => S(4*i+3), Signed10 => S(4*j+3), Y => Y64tmp(j, i) ); end generate; end generate; -- -- calculate 64x64-bit products -- add64 : entity work.Wallace generic map (WIDTH => 64) port map ( A0B0 => Y64tmp(0, 0), A0B1 => Y64tmp(0, 1), A1B0 => Y64tmp(1, 0), A1B1 => Y64tmp(1, 1), Signed01 => SignedMode, Signed10 => SignedMode, Y => Y ); -- -- 8-bit SIMD result -- TODO: need reordering for macl/mach -- Y8l <= Y16tmp(7, 7)(7 downto 0) & Y16tmp(6, 6)(7 downto 0) & Y16tmp(5, 5)(7 downto 0) & Y16tmp(4, 4)(7 downto 0) & Y16tmp(3, 3)(7 downto 0) & Y16tmp(2, 2)(7 downto 0) & Y16tmp(1, 1)(7 downto 0) & Y16tmp(0, 0)(7 downto 0); Y8h <= Y16tmp(7, 7)(15 downto 8) & Y16tmp(6, 6)(15 downto 8) & Y16tmp(5, 5)(15 downto 8) & Y16tmp(4, 4)(15 downto 8) & Y16tmp(3, 3)(15 downto 8) & Y16tmp(2, 2)(15 downto 8) & Y16tmp(1, 1)(15 downto 8) & Y16tmp(0, 0)(15 downto 8); -- -- 16-bit SIMD result -- TODO: need reordering for macl/mach -- Y16l <= Y32tmp(3, 3)(15 downto 0) & Y32tmp(2, 2)(15 downto 0) & Y32tmp(1, 1)(15 downto 0) & Y32tmp(0, 0)(15 downto 0); Y16h <= Y32tmp(3, 3)(31 downto 16) & Y32tmp(2, 2)(31 downto 16) & Y32tmp(1, 1)(31 downto 16) & Y32tmp(0, 0)(31 downto 16); -- -- 32-bit SIMD result -- TODO: need reordering for macl/mach -- Y32l <= Y64tmp(1, 1)(31 downto 0) & Y64tmp(0, 0)(31 downto 0); Y32h <= Y64tmp(1, 1)(63 downto 32) & Y64tmp(0, 0)(63 downto 32); end Arch_1; --ZPt4rx8FFjLCG7dd-- From Michael Riepe Fri Oct 13 15:14:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00378 for ; Sat, 14 Oct 2000 17:48:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:37 +0200 (MEST) Received: (qmail 12781 invoked by uid 0); 13 Oct 2000 22:22:59 -0000 Received: from mu.egroups.com (208.50.99.218) by mx12.rz2.gmx.net with SMTP; 13 Oct 2000 22:22:59 -0000 X-eGroups-Return: sentto-1101623-1207-971475761-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mu.egroups.com with NNFMP; 13 Oct 2000 22:22:58 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 22:22:40 -0000 Received: (qmail 15852 invoked from network); 13 Oct 2000 22:22:40 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 13 Oct 2000 22:22:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.58) by mta3 with SMTP; 13 Oct 2000 22:22:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA06599; Fri, 13 Oct 2000 15:14:58 +0200 Message-ID: <20001013151458.55912@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> <20001012142616.51573@thrai.stud.uni-hannover.de> <39E67445.FFF8FD35@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39E67445.FFF8FD35@f-cpu.org>; from Yann Guidon on Fri, Oct 13, 2000 at 03:32:37AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 15:14:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e91983129b3bafaa3cc10fedd13c29e6 Status: R X-Status: N On Fri, Oct 13, 2000 at 03:32:37AM +0100, Yann Guidon wrote:

> > Shouldn't we try to find somebody at egroups who enters a new list
> > administrator into their database?
> maybe, but still, this is NO excuse. there are two rules :
> - keep in archive the direction to unsubscribe. they are sent
>    when one subscribes to the list.
> - look at the mail header that ALSO contains hints.

Since I've been a mailing list administrator myself for years, I know
that you can put the unsubscribe command right in front of user's noses
IN BIG F*CKING CAPITAL LETTERS but some of them still won't manage to
get off the list.

> If somebody volunteers to manage the list,
> he/she will be flooded with requests that could have been
> done otherwise.

Still better than flooding the *list* with repeated requests.

> a bit of nettiquette helps, too. we're not in the jungle, here.

Oh, really? ;)

"The world is a jungle in general, and the networking game contributes
many animals." -- RFC 826, "An Ethernet Address Resolution Protocol"

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Sat Oct 14 02:38:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00390 for ; Sat, 14 Oct 2000 17:48:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:40 +0200 (MEST) Received: (qmail 16609 invoked by uid 0); 13 Oct 2000 23:34:04 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 13 Oct 2000 23:34:04 -0000 X-eGroups-Return: sentto-1101623-1208-971480038-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 13 Oct 2000 23:34:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 23:33:57 -0000 Received: (qmail 3886 invoked from network); 13 Oct 2000 23:33:57 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 13 Oct 2000 23:33:57 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 13 Oct 2000 23:33:57 -0000 Received: from f-cpu.org (nas3-29.ras.club-internet.fr [195.36.203.29]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA00540 for ; Sat, 14 Oct 2000 01:33:54 +0200 (MET DST) Message-ID: <39E7AB00.88BAF335@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001013213105.15826.qmail@web1102.mail.yahoo.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Oct 2000 01:38:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) VHDL guidelines : 2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9963b723593287665942567c885e2d8e Status: R X-Status: N hi,

Jamil Khatib wrote:
> my be the OpenIPCore vhdl guidelines will help you.
> try to look at www.opencores.org/OIPC

i'll check it, thanks !

> Regards
> Jamil Khatib
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Oct 14 02:38:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00393 for ; Sat, 14 Oct 2000 17:48:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:41 +0200 (MEST) Received: (qmail 16638 invoked by uid 0); 13 Oct 2000 23:34:05 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 13 Oct 2000 23:34:05 -0000 X-eGroups-Return: sentto-1101623-1209-971480038-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by c3.egroups.com with NNFMP; 13 Oct 2000 23:34:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 23:33:57 -0000 Received: (qmail 3883 invoked from network); 13 Oct 2000 23:33:57 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 13 Oct 2000 23:33:57 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 13 Oct 2000 23:33:57 -0000 Received: from f-cpu.org (nas3-29.ras.club-internet.fr [195.36.203.29]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA15382 for ; Sat, 14 Oct 2000 01:33:53 +0200 (MET DST) Message-ID: <39E7AB00.5F80C598@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200010120453.GAA11684@dunaserv.Hungary.Sun.COM> <20001012142616.51573@thrai.stud.uni-hannover.de> <39E67445.FFF8FD35@f-cpu.org> <20001013151458.55912@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Oct 2000 01:38:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE ME Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 95074d3298a01476d15d97c22848acae Status: R X-Status: N hi,

Michael Riepe wrote:
> On Fri, Oct 13, 2000 at 03:32:37AM +0100, Yann Guidon wrote:
> > If somebody volunteers to manage the list,
> > he/she will be flooded with requests that could have been
> > done otherwise.
> Still better than flooding the *list* with repeated requests.

yes, but ... what can we do ?

> > a bit of nettiquette helps, too. we're not in the jungle, here.
> Oh, really? ;)
>
> "The world is a jungle in general, and the networking game contributes
> many animals." -- RFC 826, "An Ethernet Address Resolution Protocol"

nice, but this doesn't solve our problem.
i see no solution yet.

have a nice full moon,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Oct 14 02:38:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00396 for ; Sat, 14 Oct 2000 17:48:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:41 +0200 (MEST) Received: (qmail 27201 invoked by uid 0); 13 Oct 2000 23:34:08 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 13 Oct 2000 23:34:08 -0000 X-eGroups-Return: sentto-1101623-1210-971480042-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 13 Oct 2000 23:34:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 23:34:02 -0000 Received: (qmail 4072 invoked from network); 13 Oct 2000 23:34:02 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 13 Oct 2000 23:34:02 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 13 Oct 2000 23:34:01 -0000 Received: from f-cpu.org (nas3-29.ras.club-internet.fr [195.36.203.29]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA17152 for ; Sat, 14 Oct 2000 01:33:55 +0200 (MET DST) Message-ID: <39E7AB01.64146BDA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001014002055.45060@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Oct 2000 01:38:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] latest multiplier news Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ffb2ad448b47a47b4b06658d54f3f353 Status: R X-Status: N Michael Riepe wrote:
> Buon giorno!
G'mojn' !

> Friday 13th is over, and here's the first release of the 64-bit multiplier
> (codename: Full Moon ;).
yeah ! good name, well chosen :-)

>  It doesn't support fractional numbers yet
> and is mostly untested (2^16 test patterns take 30 minutes, so...).
the fractional format is not mandatory but if you can do it,
don't hesitate. As for the test, i understand that it's not easy for you.
i'll help with it whenever possible, i hope to sign the contract and
start using my "new toy" in two weeks maybe.

> I'm looking for a program that can compare boolean expressions quickly
> (and tell me whether they're equivalent) -- with that, I could confirm
> that the implementation works correctly in all modes.
i think that some people here are aware of the formal verification
methods. i can't help, here, but correctly chosen test vectors should help.

i'm now working on the Icache implementation, i have no ASIC/FPGA synthesis tool
and i'll need help here.

> Ciao,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Allen Goldstein" Sat Oct 14 01:59:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00399 for ; Sat, 14 Oct 2000 17:48:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:42 +0200 (MEST) Received: (qmail 19397 invoked by uid 0); 13 Oct 2000 23:56:50 -0000 Received: from fk.egroups.com (208.50.99.208) by mx0.gmx.net with SMTP; 13 Oct 2000 23:56:50 -0000 X-eGroups-Return: sentto-1101623-1211-971481403-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 13 Oct 2000 23:56:46 -0000 X-Sender: allen@digitalharmony.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 13 Oct 2000 23:56:42 -0000 Received: (qmail 13124 invoked from network); 13 Oct 2000 23:56:41 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Oct 2000 23:56:41 -0000 Received: from unknown (HELO pulse.digitalharmony.com) (216.39.145.40) by mta3 with SMTP; 13 Oct 2000 23:56:41 -0000 Received: (qmail 19613 invoked from network); 13 Oct 2000 23:56:41 -0000 Received: from unknown (HELO allen) (216.39.145.40) by 192.168.0.139 with SMTP; 13 Oct 2000 23:56:41 -0000 To: "F-Cpu" Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: "Allen Goldstein" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 13 Oct 2000 16:59:06 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ec7059011576194e1dc8da34c9d5fc7 Status: R X-Status: N Hi:

I'm new to the list.  I have read the manual, now I'd like
to have a look at the source code so far.

Where can I find the source?

Cordially,
Allen
eGroups Sponsor
From Yann Guidon Sat Oct 14 07:37:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00402 for ; Sat, 14 Oct 2000 17:48:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 14 Oct 2000 17:48:43 +0200 (MEST) Received: (qmail 13606 invoked by uid 0); 14 Oct 2000 04:33:31 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 14 Oct 2000 04:33:31 -0000 X-eGroups-Return: sentto-1101623-1212-971498007-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 14 Oct 2000 04:33:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 14 Oct 2000 04:33:27 -0000 Received: (qmail 5086 invoked from network); 14 Oct 2000 04:33:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 14 Oct 2000 04:33:27 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 14 Oct 2000 04:33:26 -0000 Received: from f-cpu.org (nas4-131.aub.club-internet.fr [195.36.145.131]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA01078 for ; Sat, 14 Oct 2000 06:33:24 +0200 (MET DST) Message-ID: <39E7F135.75EC9CC4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Oct 2000 06:37:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c93cf9a18d6dbacf56ba1b43f13a7c07 Status: R X-Status: N hello,

Allen Goldstein wrote:
> Hi:
>
> I'm new to the list.
welcome !

if you have read the recent mails,
you are asked to preciously keep your unsubscription
directions, because nobody is responsible of the list
anymore, and nobody can unsub you from here.
This quick note is only meant to spare you future
stress, nothing more. anyway.

>  I have read the manual, now I'd like
> to have a look at the source code so far.

So far, the most advanced design that exists currently
is Michael Riepe's SIMD multiplier. He has posted the
sources (3 vhdl files) less than a day ago. It should work
correctly, but we have no formal proof of correctness.

> Where can I find the source?

usually, the latest files are posted on the list.
there is no coherent infrastrucure today, the writing
of the VHDL files is very recent because of the lack of
suitable tools. We are still working on standardizing the
file formats and no file is "ready" yet, in the sense
that we have nothing yet that has been exhaustively
verified and that will satisfy any synthetizer/router.

I am currently working on issuing an 'almost' synthetisable
file for the instruction cache. Michael refines his multiplier.
The ROP2 unit will be only a formality, yet the fetcher, the
instruction decoder/scheduler and the L/SU will be really tricky
so don't expect a lot more than behavioural code.

your help is welcome,

> Cordially,
> Allen
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Allen Goldstein" Mon Oct 16 16:56:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00417 for ; Tue, 17 Oct 2000 15:47:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:27 +0200 (MEST) Received: (qmail 11735 invoked by uid 0); 16 Oct 2000 14:54:15 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 16 Oct 2000 14:54:15 -0000 X-eGroups-Return: sentto-1101623-1213-971708046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fg.egroups.com with NNFMP; 16 Oct 2000 14:54:10 -0000 X-Sender: allen@digitalharmony.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 16 Oct 2000 14:54:05 -0000 Received: (qmail 6332 invoked from network); 16 Oct 2000 14:54:05 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 16 Oct 2000 14:54:05 -0000 Received: from unknown (HELO pulse.digitalharmony.com) (216.39.145.40) by mta2 with SMTP; 16 Oct 2000 14:54:04 -0000 Received: (qmail 26651 invoked from network); 16 Oct 2000 14:54:04 -0000 Received: from unknown (HELO allen) (216.39.145.40) by 192.168.0.139 with SMTP; 16 Oct 2000 14:54:04 -0000 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <39E7F135.75EC9CC4@f-cpu.org> From: "Allen Goldstein" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Oct 2000 07:56:34 -0700 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ae765a0a1051c4a8a276a4e0cc92d937 Status: R X-Status: N Has anyone considered setting up a CVS repository?

Cordially,
Allen

> -----Original Message-----
> From: Yann Guidon [mailto:whygee@f-cpu.org]
> Sent: Friday, October 13, 2000 10:38 PM
> To: f-cpu@egroups.com
> Subject: Re: [f-cpu] Where's the source?
>
>
> hello,
>
> Allen Goldstein wrote:
> > Hi:
> >
> > I'm new to the list.
> welcome !
>
> if you have read the recent mails,
> you are asked to preciously keep your unsubscription
> directions, because nobody is responsible of the list
> anymore, and nobody can unsub you from here.
> This quick note is only meant to spare you future
> stress, nothing more. anyway.
>
> >  I have read the manual, now I'd like
> > to have a look at the source code so far.
>
> So far, the most advanced design that exists currently
> is Michael Riepe's SIMD multiplier. He has posted the
> sources (3 vhdl files) less than a day ago. It should work
> correctly, but we have no formal proof of correctness.
>
> > Where can I find the source?
>
> usually, the latest files are posted on the list.
> there is no coherent infrastrucure today, the writing
> of the VHDL files is very recent because of the lack of
> suitable tools. We are still working on standardizing the
> file formats and no file is "ready" yet, in the sense
> that we have nothing yet that has been exhaustively
> verified and that will satisfy any synthetizer/router.
>
> I am currently working on issuing an 'almost'
> synthetisable
> file for the instruction cache. Michael refines
> his multiplier.
> The ROP2 unit will be only a formality, yet the
> fetcher, the
> instruction decoder/scheduler and the L/SU will
> be really tricky
> so don't expect a lot more than behavioural code.
>
> your help is welcome,
>
> > Cordially,
> > Allen
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -------------------------- eGroups Sponsor
>
>
>
>
eGroups Sponsor
From Yann Guidon Mon Oct 16 22:47:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00435 for ; Tue, 17 Oct 2000 15:47:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:34 +0200 (MEST) Received: (qmail 27958 invoked by uid 0); 16 Oct 2000 19:44:53 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net with SMTP; 16 Oct 2000 19:44:53 -0000 X-eGroups-Return: sentto-1101623-1214-971725406-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 16 Oct 2000 19:44:52 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 16 Oct 2000 19:43:25 -0000 Received: (qmail 18625 invoked from network); 16 Oct 2000 19:43:17 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Oct 2000 19:43:17 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 16 Oct 2000 19:43:16 -0000 Received: from f-cpu.org (nas3-95.aub.club-internet.fr [195.36.145.95]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA10629 for ; Mon, 16 Oct 2000 21:43:01 +0200 (MET DST) Message-ID: <39EB6968.DCFE405D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Oct 2000 21:47:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 381766e9f0378c56ed6db40229fa51a4 Status: R X-Status: N hello,

Allen Goldstein wrote:
> Has anyone considered setting up a CVS repository?
yes, we've discussed about it recently.
one year ago, there was even a CVS server at the university
of Paris but the HDD crashed.

But today, what's the use of a CVS with 3 files only ? :-)

We don't have enough meat to use a CVS but it will come soon.
If you have a solution to this problem, don't hesitate to
speak about it.

thanks,
> Cordially,
> Allen
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Mon Oct 16 22:30:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00438 for ; Tue, 17 Oct 2000 15:47:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:34 +0200 (MEST) Received: (qmail 1720 invoked by uid 0); 16 Oct 2000 20:32:25 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 16 Oct 2000 20:32:25 -0000 X-eGroups-Return: sentto-1101623-1215-971728334-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by ck.egroups.com with NNFMP; 16 Oct 2000 20:32:20 -0000 X-Sender: colin.marquardt@usa.alcatel.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 16 Oct 2000 20:32:14 -0000 Received: (qmail 31558 invoked from network); 16 Oct 2000 20:30:33 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 16 Oct 2000 20:30:33 -0000 Received: from unknown (HELO netmail.alcatel.com) (128.251.168.50) by mta1 with SMTP; 16 Oct 2000 20:30:33 -0000 Received: from relay1.usa.alcatel.com (hostree6.alcatel.com [143.209.238.6] (may be forged)) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA10960 for ; Mon, 16 Oct 2000 15:29:40 -0500 (CDT) Received: from lwmail01.pet.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id PAA12108 for ; Mon, 16 Oct 2000 15:30:28 -0500 (CDT) Received: from optilink.pet.usa.alcatel.com ([10.11.2.49]) by lwmail01.pet.usa.alcatel.com (Netscape Messaging Server 4.15 lwmail01 Aug 8 2000 13:22:32) with ESMTP id G2JIBX00.EZJ for ; Mon, 16 Oct 2000 13:31:09 -0700 Received: from sol-cmarquar.pet.usa.alcatel.com (sol-cmarquar [143.209.122.168]) by optilink.pet.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28487 for ; Mon, 16 Oct 2000 13:30:28 -0700 (PDT) Received: (from cmarquar@localhost) by sol-cmarquar.pet.usa.alcatel.com (8.9.3+Sun/8.9.1) id NAA00848; Mon, 16 Oct 2000 13:30:29 -0700 (PDT) X-Authentication-Warning: sol-cmarquar.pet.usa.alcatel.com: cmarquar set sender to colin.marquardt@usa.alcatel.com using -f To: f-cpu@egroups.com Keywords: edu,ececs,oct,mon,received,alcatel,babbage,stgl X-Disclaimer: Opinions expressed are not those of Alcatel USA. Message-ID: Lines: 67 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Canyonlands) From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 16 Oct 2000 13:30:28 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cf623a6cb43ce43d835f2d7db36da81c Status: R X-Status: N Hi all,

I guess that we should tell them that we are potentially interested
in using Savant, but are scared away by the huge memory usage...

(Michael, can you provide some numbers?)

Colin

-------------------- Start of forwarded message --------------------
Received: from mailrelay1.alcatel.de (sls26e.stgl.netd.alcatel.de [149.204.45.34])
      by sls4a1.stgl.sel.alcatel.de (8.8.8+Sun/8.8.8) with SMTP id WAA23937
      for <CMARQU@sls4a1.stgl.sel.alcatel.de>; Mon, 16 Oct 2000 22:09:41 +0200 (MET DST)
Received: from slsdm2.stgl.netd.alcatel.de by mailrelay1.alcatel.de with SMTP (XT-PP) with ESMTP; Mon, 16 Oct 2000 22:09:30 +0200
Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by slsdm2.stgl.netd.alcatel.de (8.9.3/8.9.3) with ESMTP id WAA04232 for <c.marquardt@alcatel.de>; Mon, 16 Oct 2000 22:09:29 +0200 (MET DST)
Received: from localhost (sendmail@localhost) by babbage.ececs.uc.edu (8.10.2/8.10.2) with SMTP id e9GK88r10317; Mon, 16 Oct 2000 16:08:12 -0400 (EDT)
X-Authentication-Warning: babbage.ececs.uc.edu: sendmail owned process doing -bs
Received: by babbage.ececs.uc.edu (bulk_mailer v1.9); Mon, 16 Oct 2000 16:08:08 -0400
Received: (from majdomo@localhost) by babbage.ececs.uc.edu (8.10.2/8.10.2) id e9GK87g10311 for savant-users-list; Mon, 16 Oct 2000 16:08:07 -0400 (EDT)
X-Authentication-Warning: babbage.ececs.uc.edu: majdomo set sender to owner-savant-users@mail.ececs.uc.edu using -f
Received: from mail2.one.net (IDENT:0@mail2.one.net [206.112.192.100]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e9GK84j10307 for <savant-users@ececs.uc.edu>; Mon, 16 Oct 2000 16:08:04 -0400 (EDT)
Received: from ip-216-23-53-186.adsl.one.net ([216.23.53.186] EHLO chinchilla.toadis.porkis ident: IDENT-NOT-QUERIED [port 35588]) by mail2.one.net with ESMTP id <231483-356>; Mon, 16 Oct 2000 16:08:06 -0400
Received: from dmartin by chinchilla.toadis.porkis with local (Exim 3.16 #1 (Debian)) id 13lGY5-0002IY-00; Mon, 16 Oct 2000 16:07:53 -0400
To: savant-users@ececs.uc.edu
Subject: SAVANT's direction
Message-ID: <20001016160752.A8830@clifton-labs.com>
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: "Dale E. Martin" <dmartin@clifton-labs.com>
Date:       Mon, 16 Oct 2000 16:08:03 -0400
Sender: owner-savant-users@ececs.uc.edu
Content-Length: 1235

With the forthcoming major release of SAVANT, we are also beginning the
planning for our next major development activities.  In particular, we are
considering work on the following tasks:

1. completion of the vhdl_writer visitor.
2. replacing the publish_cc methods in IIR with a cc_writer visitor.
3. adding support for VHDL-AMS and VHDL 2000.
4. using XML for our library modules.
5. adding support to dynamically locate and invoke IIR visitors stored in
   binary libraries.
6. Increased simultation compatibility with the various standard IEEE
   libraries, such as std_logic_1164, numeric_std, VITAL and friends.

With this message, we are soliciting your input and possible support for
these activities.  Are you or your companies interested in these tasks?  If
so, to what extent.

We'd be interested to hear how things are going on your projects, and
please let us know how we can be of assistance.

Sincerely,
      Dale Martin for the SAVANT project team.
--
+---------------------- pgp key available -----------------------+
| Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com   |
+----------------------------------------------------------------+

-------------------- End of forwarded message --------------------

--
Colin Marquardt <colin.marquardt@usa.alcatel.com>
Alcatel USA, 1420 McDowell Blvd. North, Petaluma, CA 94954
Phone: (+1 707) 665-8221 * Fax: (+1 707) 792-7055
eGroups Sponsor
From Michael Riepe Tue Oct 17 02:58:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00495 for ; Tue, 17 Oct 2000 15:47:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:51 +0200 (MEST) Received: (qmail 30536 invoked by uid 0); 17 Oct 2000 00:58:54 -0000 Received: from fl.egroups.com (208.50.144.74) by mx0.gmx.net with SMTP; 17 Oct 2000 00:58:54 -0000 X-eGroups-Return: sentto-1101623-1216-971744326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fl.egroups.com with NNFMP; 17 Oct 2000 00:58:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 17 Oct 2000 00:58:46 -0000 Received: (qmail 30535 invoked from network); 17 Oct 2000 00:58:45 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 17 Oct 2000 00:58:45 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.50) by mta2 with SMTP; 17 Oct 2000 00:58:44 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01664; Tue, 17 Oct 2000 02:58:41 +0200 Message-ID: <20001017025840.34224@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Mon, Oct 16, 2000 at 01:30:28PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Oct 2000 02:58:40 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e1cebed6d4cc25fa2e42cf03cb2bfadc Status: R X-Status: N On Mon, Oct 16, 2000 at 01:30:28PM -0700, Colin Marquardt wrote:

> I guess that we should tell them that we are potentially interested
> in using Savant, but are scared away by the huge memory usage...
>
> (Michael, can you provide some numbers?)

You mean, like this?  This is savant's main executable:

-rwxr-xr-x michael/staff 14460672 2000-10-06 03:41 opt/savant/bin/scram

A very simple VHDL file (my Icache implementation) turned into a 12 MByte
file.  I didn't try the 64-bit multiplier.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Tue Oct 17 06:19:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00501 for ; Tue, 17 Oct 2000 15:47:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:52 +0200 (MEST) Received: (qmail 744 invoked by uid 0); 17 Oct 2000 03:14:56 -0000 Received: from fj.egroups.com (208.50.99.207) by mx0.gmx.net with SMTP; 17 Oct 2000 03:14:56 -0000 X-eGroups-Return: sentto-1101623-1217-971752488-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fj.egroups.com with NNFMP; 17 Oct 2000 03:14:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 17 Oct 2000 03:14:47 -0000 Received: (qmail 14716 invoked from network); 17 Oct 2000 03:14:47 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 17 Oct 2000 03:14:47 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 17 Oct 2000 03:14:47 -0000 Received: from f-cpu.org (nas4-120.ras.club-internet.fr [195.36.203.120]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA16595 for ; Tue, 17 Oct 2000 05:14:40 +0200 (MET DST) Message-ID: <39EBD343.BFDFD487@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001017025840.34224@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Oct 2000 05:19:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64c7844666a0a67d7bca281d230e9016 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Mon, Oct 16, 2000 at 01:30:28PM -0700, Colin Marquardt wrote:
> > I guess that we should tell them that we are potentially interested
> > in using Savant, but are scared away by the huge memory usage...
right. Simili is nice for small designs but won't scale well.

> > (Michael, can you provide some numbers?)
> You mean, like this?  This is savant's main executable:
> -rwxr-xr-x michael/staff 14460672 2000-10-06 03:41 opt/savant/bin/scram
> A very simple VHDL file (my Icache implementation) turned into a 12 MByte
> file.  I didn't try the 64-bit multiplier.
AAArghh ! Simili is so much more compact :-)

IIRC, FreeHDL is more or less as efficient.
But some of the most desirable features are VHDL'93 and
IEEE1164 optimized libraries.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Tue Oct 17 08:56:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00504 for ; Tue, 17 Oct 2000 15:47:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Oct 2000 15:47:53 +0200 (MEST) Received: (qmail 29846 invoked by uid 0); 17 Oct 2000 06:52:20 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 17 Oct 2000 06:52:20 -0000 X-eGroups-Return: sentto-1101623-1218-971765536-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 17 Oct 2000 06:52:19 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 17 Oct 2000 06:52:15 -0000 Received: (qmail 4599 invoked from network); 17 Oct 2000 06:52:15 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 17 Oct 2000 06:52:15 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 17 Oct 2000 06:52:14 -0000 Received: from morphin.marquardt-home.de (d36.nas21.sonic.net [209.204.136.36]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id IAA16745 for ; Tue, 17 Oct 2000 08:52:00 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13lQfI-0001JH-00 for ; Mon, 16 Oct 2000 23:56:00 -0700 To: f-cpu@egroups.com References: <20001017025840.34224@thrai.stud.uni-hannover.de> X-Now-Playing: Umbra et Imago's Infantile Spiele - Gothic Erotic In-Reply-To: Michael Riepe's message of "Tue, 17 Oct 2000 02:58:40 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 28 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 16 Oct 2000 23:56:00 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1732e886575be5647c3982ab06736e3f Status: R X-Status: N Hi,

* Michael Riepe <michael@stud.uni-hannover.de> writes:

> On Mon, Oct 16, 2000 at 01:30:28PM -0700, Colin Marquardt wrote:
>> I guess that we should tell them that we are potentially interested
>> in using Savant, but are scared away by the huge memory usage...
>>
>> (Michael, can you provide some numbers?)

> You mean, like this?  This is savant's main executable:

> -rwxr-xr-x michael/staff 14460672 2000-10-06 03:41 opt/savant/bin/scram

That would be okay I guess, but that...

> A very simple VHDL file (my Icache implementation) turned into a 12 MByte
> file.  I didn't try the 64-bit multiplier.

... is quite a bit. Is it as slow as it is big?

I would be surprised if they could make substantial improvements to
that. The size is probably due to the tool architecture.

Colin

PS: I started working on the coding rules, using the opencores TeX
    files as basis. It is going slow though :-)
eGroups Sponsor
From Michael Riepe Tue Oct 17 14:35:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00334 for ; Thu, 19 Oct 2000 17:29:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:29:14 +0200 (MEST) Received: (qmail 24206 invoked by uid 0); 17 Oct 2000 22:31:54 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net with SMTP; 17 Oct 2000 22:31:54 -0000 X-eGroups-Return: sentto-1101623-1219-971821906-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by jj.egroups.com with NNFMP; 17 Oct 2000 22:31:49 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 17 Oct 2000 22:31:44 -0000 Received: (qmail 27822 invoked from network); 17 Oct 2000 22:31:44 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 17 Oct 2000 22:31:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.223) by mta3 with SMTP; 17 Oct 2000 22:31:41 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00567; Tue, 17 Oct 2000 14:35:05 +0200 Message-ID: <20001017143505.08589@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001017025840.34224@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Mon, Oct 16, 2000 at 11:56:00PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Oct 2000 14:35:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4150821f0820fb8006d1ddc71f2ca989 Status: R X-Status: N On Mon, Oct 16, 2000 at 11:56:00PM -0700, Colin Marquardt wrote:

> > A very simple VHDL file (my Icache implementation) turned into a 12 MByte
> > file.  I didn't try the 64-bit multiplier.
>
> ... is quite a bit. Is it as slow as it is big?
>
> I would be surprised if they could make substantial improvements to
> that. The size is probably due to the tool architecture.

There are more problems :(  I installed and ran savant again (input was
the 8x8-bit multiplier this time) and scram threw an assertion failure.
And worse, it core dumps on the testbench.  You can calculate the
performance yourself (hint: it's damn close to 0.0).

I don't think savant is useful at the moment.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From David Sullins Wed Oct 18 03:56:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00346 for ; Thu, 19 Oct 2000 17:29:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:29:30 +0200 (MEST) Received: (qmail 16373 invoked by uid 0); 18 Oct 2000 02:09:43 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 18 Oct 2000 02:09:43 -0000 X-eGroups-Return: sentto-1101623-1220-971834230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 18 Oct 2000 01:57:13 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 01:57:09 -0000 Received: (qmail 23490 invoked from network); 18 Oct 2000 01:57:09 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 18 Oct 2000 01:57:09 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta3 with SMTP; 18 Oct 2000 01:57:09 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id UAA20072; Tue, 17 Oct 2000 20:56:47 -0500 Received: from eceultra14 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id UAA14505; Tue, 17 Oct 2000 20:56:45 -0500 (CDT) Received: from localhost by eceultra14 (8.8.8+Sun/ECESolaris-Client) id UAA06774; Tue, 17 Oct 2000 20:56:40 -0500 (CDT) To: f-cpu@egroups.com Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Oct 2000 20:56:40 -0500 (CDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] analysis/simulation/synthesis tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a538ece3c8f2f4e09238ee794848ac64 Status: R X-Status: N Hi there.  I have been following the mailing list for a couple months now,
and I would really like to contribute something.  Unfortunately I don't
have a lot of time to spend writing any VHDL.

But what I could contribute is the use of some commercial software that my
university has licenses for.  If anyone out there is itching to test out
some design in VHDL, but doesn't have the software to do it, I can
help.  We have Modelsim for analysis/simulation, and Leonardo/Spectrum for
synthesis.

So people could send me their VHDL source along with testbenches, and I
could run them through Modelsim when I get the chance.  Think of it as a
human operated batch processing unit.  Might take a day or two to get your
job processed, but it's better than nothing.

We also have a full (level 3) license for Leonardo/Spectrum.  When this
project gets further along, I could target designs to different
technologies to see how they fare.  It looks like we can target 9
different FPGA/CPLD vendors' devices with the software we have now.

I hope this contribution helps the project.  Maybe some day I'll find time
to code an execution unit or two.

Dave
eGroups Sponsor
From "Richard E.Hartney" Wed Oct 18 10:10:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00361 for ; Thu, 19 Oct 2000 17:29:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:29:45 +0200 (MEST) Received: (qmail 4792 invoked by uid 0); 18 Oct 2000 08:10:45 -0000 Received: from jj.egroups.com (208.50.144.82) by mx12.rz2.gmx.net with SMTP; 18 Oct 2000 08:10:45 -0000 X-eGroups-Return: sentto-1101623-1222-971856638-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 18 Oct 2000 08:10:34 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 08:10:38 -0000 Received: (qmail 1040 invoked from network); 18 Oct 2000 08:10:38 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 18 Oct 2000 08:10:38 -0000 Received: from unknown (HELO mail3.lig.bellsouth.net) (205.152.0.51) by mta3 with SMTP; 18 Oct 2000 08:10:38 -0000 Received: from 0018728164 (host-209-215-11-181.bix.bellsouth.net [209.215.11.181]) by mail3.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id EAA24983; Wed, 18 Oct 2000 04:10:35 -0400 (EDT) Message-ID: <000801c038db$19740100$b50bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 03:10:40 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] ERIN32 Progress Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C038B0.FE880320" X-UIDL: 2db22a950bbf6f20852e8ee876781e12 Status: R X-Status: N ------=_NextPart_000_0005_01C038B0.FE880320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Language Processor is complete, waiting for Eclipse Software to be rele= ased. This design has a 4 deep pipeline structure. Curently doing its companion, the MMP (Memory Management Processor) which i= s synchronous with the Language Processor (LP). Its functions are: 1. Operand prefetch for LP 2. Transparent JUMP 3. Transparent Indirect JUMP 4. Transparent Jump & Store Return (JST} 5 Enable Interrupts (May be executed with any LP Instruction) 6. Disable Interrupts (May be executed with any LP Instruction) 7. Conditional Jump (Not transparent) 8. Interrupt Processing (This effectively an Indirect Jump & Store Re= turn) Timing diagram indicates a performance in the 200 - 300 MHZ range. A preli= minary PC Board layout indicates adequate space for adding an additional 4 levels = of pipeline. This requires two LP's and two MMP's with additional program = memory. which should yield a performance of 400 - 600 MHZ. Simulation results will= tell me the basic Clock Oscillator to use. I will use the SILOS Simulator= which is included with the Eclipse Software. The PC Board also includes a= n FBC (Fully Buffered Channel) chip & 1 MegByte Local Memory. All memory i= s SSRAM (Synchronous Static RAM) either two or four port. PC Board size is= approx 8 1/2 inches by 11 inches. I will require two of these identical b= oards - one for the LP and one for the Peripheral Processor. I DO NOT requ= ire the added performance but gut feel says DO IT for un-anticipated applic= ations. It will create another new set of logic problems that I won't go i= n to. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C038B0.FE880320 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
The Language Processor is complete, waiting for Eclipse Software to be released.
This design has a 4 deep pipeline structure.
 
Curently doing its companion, the MMP (Memory Management Processor) which is synchronous with the Language Processor (LP).  Its functions are:
 
    1.  Operand prefetch for LP
    2.  Transparent JUMP
    3.  Transparent Indirect JUMP
    4.  Transparent Jump & Store Return (JST}
    5    Enable Interrupts (May be executed with any LP Instruction)
    6.   Disable Interrupts (May be executed with any LP Instruction)
    7.   Conditional Jump (Not transparent)
    8.   Interrupt Processing (This effectively an Indirect Jump & Store Return)
 
Timing diagram indicates a performance in the 200 - 300 MHZ range.  A preliminary
PC Board layout indicates adequate space for adding an additional 4 levels of pipeline.  This requires two LP's and two MMP's with additional program memory.
which should yield a performance of 400 - 600 MHZ.  Simulation results will tell me the basic Clock Oscillator to use.  I will use the SILOS Simulator which is included with the Eclipse Software.  The PC Board also includes an FBC (Fully Buffered Channel) chip & 1 MegByte Local Memory.  All memory is SSRAM (Synchronous Static RAM) either two or four port.  PC Board size is approx 8 1/2 inches by 11 inches.  I will require two of these identical boards - one for the LP and one for the Peripheral Processor.  I DO NOT require the added performance but gut feel says DO IT for un-anticipated applications.  It will create another new set of logic problems that I won't go in to.
 
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates

eGroups Sponsor
------=_NextPart_000_0005_01C038B0.FE880320-- From Yann Guidon Wed Oct 18 11:56:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00367 for ; Thu, 19 Oct 2000 17:29:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:29:53 +0200 (MEST) Received: (qmail 26643 invoked by uid 0); 18 Oct 2000 08:52:22 -0000 Received: from hh.egroups.com (208.50.99.210) by mx11.rz2.gmx.net with SMTP; 18 Oct 2000 08:52:22 -0000 X-eGroups-Return: sentto-1101623-1223-971859134-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 18 Oct 2000 08:52:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 08:52:13 -0000 Received: (qmail 23207 invoked from network); 18 Oct 2000 08:52:13 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 18 Oct 2000 08:52:13 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 18 Oct 2000 08:52:13 -0000 Received: from f-cpu.org (nas2-244.ras.club-internet.fr [195.36.192.244]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA21858 for ; Wed, 18 Oct 2000 10:52:10 +0200 (MET DST) Message-ID: <39ED73DF.7C250BAB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 10:56:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] analysis/simulation/synthesis tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5b693f3dcb49a10bb921a724a61ecb10 Status: R X-Status: N hi !

David Sullins wrote:
> Hi there.  I have been following the mailing list for a couple months now,
> and I would really like to contribute something.  Unfortunately I don't
> have a lot of time to spend writing any VHDL.
thank you for saying hi anyway :-)

> But what I could contribute is the use of some commercial software that my
> university has licenses for.  If anyone out there is itching to test out
> some design in VHDL, but doesn't have the software to do it, I can
> help.  We have Modelsim for analysis/simulation, and Leonardo/Spectrum for
> synthesis.
cool :-)

> So people could send me their VHDL source along with testbenches, and I
> could run them through Modelsim when I get the chance.  Think of it as a
> human operated batch processing unit.  Might take a day or two to get your
> job processed, but it's better than nothing.
of course. And when the batch fails, there's an intelligent error correction :-)

> We also have a full (level 3) license for Leonardo/Spectrum.  When this
> project gets further along, I could target designs to different
> technologies to see how they fare.  It looks like we can target 9
> different FPGA/CPLD vendors' devices with the software we have now.
you can start with the files that were recently posted on the list,
particularly Michael's multiplier. Nicolas Boulay criticized him
because Michael used a Wallace tree, it might be inefficient with
few metal layers. Maybe a synthesis would help determine if it was
a good choice, and what technologies are best used.

> I hope this contribution helps the project.  Maybe some day I'll find time
> to code an execution unit or two.
let's hope, too !

thanks,
> Dave
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Junker, Gregory G" Wed Oct 18 14:33:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00523 for ; Thu, 19 Oct 2000 17:30:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:30:32 +0200 (MEST) Received: (qmail 8305 invoked by uid 0); 18 Oct 2000 12:32:41 -0000 Received: from mq.egroups.com (208.50.144.79) by mx19.rz2.gmx.net with SMTP; 18 Oct 2000 12:32:41 -0000 X-eGroups-Return: sentto-1101623-1224-971872352-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by mq.egroups.com with NNFMP; 18 Oct 2000 12:32:39 -0000 X-Sender: gregory_junker@reyrey.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 12:32:31 -0000 Received: (qmail 1609 invoked from network); 18 Oct 2000 12:32:31 -0000 Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 18 Oct 2000 12:32:31 -0000 Received: from unknown (HELO gw.reyrey.com) (206.175.68.198) by mta3 with SMTP; 18 Oct 2000 12:32:31 -0000 Received: from mailsrv1.reyrey.com (oh15ux01.reyrey.com [168.207.1.211]) by gw.reyrey.com (8.9.3/8.9.3) with ESMTP id IAA13360; Wed, 18 Oct 2000 08:32:30 -0400 (EDT) Received: (from mailgate@localhost) by mailsrv1.reyrey.com (8.9.3/8.9.3) id IAA13353; Wed, 18 Oct 2000 08:32:30 -0400 (EDT) Received: by oh15ex06.reyrey.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 08:33:23 -0400 Message-ID: <3F7F50D4CAF1D211BF070090273CBD3202FD5F82@oh15ex06.reyrey.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2650.21) From: "Junker, Gregory G" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 08:33:15 -0400 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64dd91d60540c0a407588aff8bc9fbfd Status: R X-Status: N There's every reason to use a CVS at any stage in a project. Whether one
file or one hundred thousand, having version control, and in a centralized
and (as seems to be the issue here) well-known place, is extremely valuable.
If no one else wants to do it, I would be happy to do so, but you'll have to
give me a few weeks to get everything up. I have to get a CVS server set up
for something else I am working on, and have to get some dedicated access
(static IP, and all that), but in a couple/few weeks I will be in a position
to host such services (if anybody wants it).

let me know
greg


-----Original Message-----
From: Yann Guidon [mailto:whygee@f-cpu.org]
Sent: Monday, October 16, 2000 3:45 PM
To: f-cpu@egroups.com
Subject: Re: [f-cpu] Where's the source?


hello,

Allen Goldstein wrote:
> Has anyone considered setting up a CVS repository?
yes, we've discussed about it recently.
one year ago, there was even a CVS server at the university
of Paris but the HDD crashed.

But today, what's the use of a CVS with 3 files only ? :-)

We don't have enough meat to use a CVS but it will come soon.
If you have a solution to this problem, don't hesitate to
speak about it.

thanks,
> Cordially,
> Allen
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


eGroups Sponsor     
<http://click.egroups.com/1/9657/15/_/3462/_/971725408/>


<http://adimg.egroups.com/img/9657/15/_/3462/_/971725408/WarningFreeStuff468
x602E.gif>


eGroups Sponsor
From "Junker, Gregory G" Wed Oct 18 16:39:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00541 for ; Thu, 19 Oct 2000 17:30:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:30:53 +0200 (MEST) Received: (qmail 10187 invoked by uid 0); 18 Oct 2000 14:38:29 -0000 Received: from mv.egroups.com (208.50.144.81) by mx19.rz2.gmx.net with SMTP; 18 Oct 2000 14:38:29 -0000 X-eGroups-Return: sentto-1101623-1226-971879901-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 18 Oct 2000 14:38:28 -0000 X-Sender: gregory_junker@reyrey.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 14:38:21 -0000 Received: (qmail 16388 invoked from network); 18 Oct 2000 14:38:21 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 18 Oct 2000 14:38:21 -0000 Received: from unknown (HELO gw.reyrey.com) (206.175.68.198) by mta3 with SMTP; 18 Oct 2000 14:38:20 -0000 Received: from mailsrv1.reyrey.com (oh15ux01.reyrey.com [168.207.1.211]) by gw.reyrey.com (8.9.3/8.9.3) with ESMTP id KAA27657; Wed, 18 Oct 2000 10:38:19 -0400 (EDT) Received: (from mailgate@localhost) by mailsrv1.reyrey.com (8.9.3/8.9.3) id KAA10733; Wed, 18 Oct 2000 10:38:19 -0400 (EDT) Received: by oh15ex06.reyrey.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 10:39:11 -0400 Message-ID: <3F7F50D4CAF1D211BF070090273CBD3202FD5F85@oh15ex06.reyrey.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2650.21) From: "Junker, Gregory G" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 10:39:02 -0400 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb665e07483a3e56086214f1cb74e96e Status: R X-Status: N Grabbing a Linux dist is the best bet because it's all there for you already
(CVS, inetd, etc.); fix a couple of config files, run "cvs init" on a
directory and off you go (plus maintaining a password file if necessary)

It's also a matter of having a dedicated connection to the internet so that
anyone can access the box at any time. A university is sometimes considered
ideal for this, because they already have that. However, you are somewhat at
the whim of the university computing resources owners. Same problem with a
corporation or other business. For something like this, it may be best for
an independent individual to host the CVS. You would likely also have a hard
time convincing an ISP to open up port 2401 (pserver) on one of their
servers to general access for an ISP user, as this is a serious (IMO )
security hole. Again, if I were to dedicate a single Linux server to CVS and
nothing else, I would have no problem hosting it; like I said, I have to
anyway for other reasons, so if FCPU wanted to piggyback on that, the
offer's open...

greg


Is it a matter of getting a Linux Box (or Solaris or whatever), and running
pserver on it?
Jeff Davies
eGroups Sponsor
From Jeff Davies Wed Oct 18 16:24:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00544 for ; Thu, 19 Oct 2000 17:30:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:30:56 +0200 (MEST) Received: (qmail 4587 invoked by uid 0); 18 Oct 2000 14:43:55 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 18 Oct 2000 14:43:55 -0000 X-eGroups-Return: sentto-1101623-1225-971879256-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 18 Oct 2000 14:27:46 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 14:27:36 -0000 Received: (qmail 32307 invoked from network); 18 Oct 2000 14:27:35 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 18 Oct 2000 14:27:35 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta3 with SMTP; 18 Oct 2000 14:27:35 -0000 Received: from modem-204.north-dakota.dialup.pol.co.uk ([62.137.85.204] helo=llandre.freeserve.co.uk) by mail3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13luBp-0000Gd-00 for f-cpu@egroups.com; Wed, 18 Oct 2000 15:27:34 +0100 Message-ID: <39EDB28C.671E3E1C@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3F7F50D4CAF1D211BF070090273CBD3202FD5F82@oh15ex06.reyrey.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 15:24:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aab8b8b30efeb374a9259b93d6dc575a Status: R X-Status: N "Junker, Gregory G" wrote:

> There's every reason to use a CVS at any stage in a project. Whether one
> file or one hundred thousand, having version control, and in a centralized
> and (as seems to be the issue here) well-known place, is extremely valuable.
> If no one else wants to do it, I would be happy to do so, but you'll have to
> give me a few weeks to get everything up. I have to get a CVS server set up
> for something else I am working on, and have to get some dedicated access
> (static IP, and all that), but in a couple/few weeks I will be in a position
> to host such services (if anybody wants it).
>
> let me know
> greg
>
>

Is it a matter of getting a Linux Box (or Solaris or whatever), and running
pserver on it?
Jeff Davies
eGroups Sponsor
From Michael Riepe Wed Oct 18 15:36:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00586 for ; Thu, 19 Oct 2000 17:32:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:32:10 +0200 (MEST) Received: (qmail 15222 invoked by uid 0); 18 Oct 2000 19:29:12 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 18 Oct 2000 19:29:12 -0000 X-eGroups-Return: sentto-1101623-1227-971897327-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by fh.egroups.com with NNFMP; 18 Oct 2000 19:29:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 19:28:46 -0000 Received: (qmail 21540 invoked from network); 18 Oct 2000 19:28:46 -0000 Received: from unknown (10.1.10.26) by m1.onelist.org with QMQP; 18 Oct 2000 19:28:46 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.109) by mta1 with SMTP; 18 Oct 2000 19:28:44 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00634; Wed, 18 Oct 2000 15:36:40 +0200 Message-ID: <20001018153640.46080@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39ED73DF.7C250BAB@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39ED73DF.7C250BAB@f-cpu.org>; from Yann Guidon on Wed, Oct 18, 2000 at 10:56:47AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 15:36:40 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] analysis/simulation/synthesis tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 85dc4c1841741d658cee98c58b81c9b3 Status: R X-Status: N On Wed, Oct 18, 2000 at 10:56:47AM +0100, Yann Guidon wrote:
[...]
> you can start with the files that were recently posted on the list,
> particularly Michael's multiplier. Nicolas Boulay criticized him
> because Michael used a Wallace tree, it might be inefficient with
> few metal layers. Maybe a synthesis would help determine if it was
> a good choice, and what technologies are best used.

I didn't see anything from Nicolas on that topic.  Why not?

I can re-arrange the adders in stage 1 to make the 8x8 multiplier
more SPIM-like (http://mos.stanford.edu/papers/ms_jssc_89.pdf) if that
helps.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 18 14:45:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00589 for ; Thu, 19 Oct 2000 17:32:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:32:11 +0200 (MEST) Received: (qmail 27500 invoked by uid 0); 18 Oct 2000 19:30:41 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 18 Oct 2000 19:30:41 -0000 X-eGroups-Return: sentto-1101623-1228-971897430-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 18 Oct 2000 19:30:40 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 18 Oct 2000 19:30:29 -0000 Received: (qmail 9035 invoked from network); 18 Oct 2000 19:28:49 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 18 Oct 2000 19:28:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.109) by mta1 with SMTP; 18 Oct 2000 19:28:47 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00450; Wed, 18 Oct 2000 14:45:06 +0200 Message-ID: <20001018144506.36663@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001017025840.34224@thrai.stud.uni-hannover.de> <20001017143505.08589@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Wed, Oct 18, 2000 at 12:13:45AM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Oct 2000 14:45:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ["Dale E. Martin" ] SAVANT's direction Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b157b85fa36662dcefb055051e432eb7 Status: R X-Status: N On Wed, Oct 18, 2000 at 12:13:45AM -0700, Colin Marquardt wrote:
[savant]
> But still: have you filed a bug report? In a time where many users
> might away from submitting testcases because of (potentially) legal
> problems, yours is even more needed.

No, I was too busy.  I usually cross-check that it's not my fault before
I report a bug (or my compiler's fault, for example) but I didn't have
the time to do that.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Jeff Davies Thu Oct 19 12:15:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00679 for ; Thu, 19 Oct 2000 17:33:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Oct 2000 17:33:26 +0200 (MEST) Received: (qmail 7508 invoked by uid 0); 19 Oct 2000 10:15:39 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 19 Oct 2000 10:15:39 -0000 X-eGroups-Return: sentto-1101623-1229-971950498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 19 Oct 2000 10:15:01 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 19 Oct 2000 10:14:57 -0000 Received: (qmail 28604 invoked from network); 19 Oct 2000 10:14:57 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 19 Oct 2000 10:14:57 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta3 with SMTP; 19 Oct 2000 10:14:57 -0000 Received: from modem-114.titanium.dialup.pol.co.uk ([62.136.21.114] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13mCit-0005Yi-00 for f-cpu@egroups.com; Thu, 19 Oct 2000 11:14:56 +0100 Sender: jeff@pop.gmx.net Message-ID: <39EEC9CA.4CBBB037@llandre.freeserve.co.uk> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <200010122309.BAA12574@dunaserv.Hungary.Sun.COM> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Oct 2000 11:15:38 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FOA ERIC FISCHER Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b988cd122a31f8b09140dafc8ad6c431 Status: R X-Status: N Sorry, the email I sent earlier was wrong, it is not
f-cpu-unsubscribe@egroups.com

If you open the web page www.egroups.com/group/f-cpu
you see the unsubscribe is in fact  @makelist.com.
This is probably the fault of some corporate takeover or other...

"This is the main mailing list for the Freedom CPU Project.
                It will be broken down into various topic-specific lists
                as needed.

                To subscribe, send an empty message to
f-cpu-subscribe@makelist.com

                To unsubscribe, send a message to f-cpu-unsubscribe@makelist.com

                List Owner: f-cpu-owner@makelist.com "
eGroups Sponsor
From Yann Guidon Fri Oct 20 03:52:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00617 for ; Sun, 22 Oct 2000 02:01:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:33 +0200 (MEST) Received: (qmail 706 invoked by uid 0); 20 Oct 2000 00:47:55 -0000 Received: from ck.egroups.com (208.50.144.69) by mx11.rz2.gmx.net with SMTP; 20 Oct 2000 00:47:55 -0000 X-eGroups-Return: sentto-1101623-1230-972002868-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 20 Oct 2000 00:47:50 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 00:47:47 -0000 Received: (qmail 31011 invoked from network); 20 Oct 2000 00:47:47 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 20 Oct 2000 00:47:47 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 20 Oct 2000 00:47:46 -0000 Received: from f-cpu.org (nas1-237.aub.club-internet.fr [195.36.150.237]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA16637 for ; Fri, 20 Oct 2000 02:47:44 +0200 (MET DST) Message-ID: <39EFA557.732E55B2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3F7F50D4CAF1D211BF070090273CBD3202FD5F85@oh15ex06.reyrey.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 02:52:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Where's the source? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e5b17c460ebbf6e2c40376fa30ea06cc Status: R X-Status: N hi !
(late answer)

"Junker, Gregory G" wrote:
<snip>
> Again, if I were to dedicate a single Linux server to CVS and
> nothing else, I would have no problem hosting it; like I said, I have to
> anyway for other reasons, so if FCPU wanted to piggyback on that, the
> offer's open...
i see no reason to refuse :-)
anyway, i'm more used to ftp or web forms.
i'm lazy to install WinCVS :-)
As people will start to add or modify files,
it will certainly become important anyway.

> greg
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 20 03:52:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00620 for ; Sun, 22 Oct 2000 02:01:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:33 +0200 (MEST) Received: (qmail 8261 invoked by uid 0); 20 Oct 2000 00:47:59 -0000 Received: from hm.egroups.com (208.50.99.198) by mx06.rz2.gmx.net with SMTP; 20 Oct 2000 00:47:59 -0000 X-eGroups-Return: sentto-1101623-1231-972002871-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hm.egroups.com with NNFMP; 20 Oct 2000 00:47:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 00:47:50 -0000 Received: (qmail 29369 invoked from network); 20 Oct 2000 00:47:49 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 20 Oct 2000 00:47:49 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 20 Oct 2000 00:47:49 -0000 Received: from f-cpu.org (nas1-237.aub.club-internet.fr [195.36.150.237]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA24264 for ; Fri, 20 Oct 2000 02:47:46 +0200 (MET DST) Message-ID: <39EFA559.74241878@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 02:52:25 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] toy update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70b48e1c6697bf78d0ca01dfa694cfa9 Status: R X-Status: N hi,

i still haven't signed yet so i can't say much.
All i can say is that the R&D team in which i hope
to work is rather receptive to the f-cpu idea.
They already got the LEON working on their machine,
so it's just another step forward :-)

in the meanwhile, i'm trying to earn some pocket money
writing an article, so i haven't touched Simili for
some time. this will change once i'm signed :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 20 03:52:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00623 for ; Sun, 22 Oct 2000 02:01:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:34 +0200 (MEST) Received: (qmail 32293 invoked by uid 0); 20 Oct 2000 00:48:00 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net with SMTP; 20 Oct 2000 00:48:00 -0000 X-eGroups-Return: sentto-1101623-1232-972002871-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 20 Oct 2000 00:47:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 00:47:50 -0000 Received: (qmail 31107 invoked from network); 20 Oct 2000 00:47:50 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 20 Oct 2000 00:47:50 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 20 Oct 2000 00:47:50 -0000 Received: from f-cpu.org (nas1-237.aub.club-internet.fr [195.36.150.237]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA21168 for ; Fri, 20 Oct 2000 02:47:47 +0200 (MET DST) Message-ID: <39EFA55B.374E0E0F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200010122309.BAA12574@dunaserv.Hungary.Sun.COM> <39EEC9CA.4CBBB037@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 02:52:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FOA ERIC FISCHER Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 67744ce110458972f1d49ddd8e6328e4 Status: R X-Status: N hi !

Jeff Davies wrote:
> Sorry, the email I sent earlier was wrong, it is not
> f-cpu-unsubscribe@egroups.com
>
> If you open the web page www.egroups.com/group/f-cpu
> you see the unsubscribe is in fact  @makelist.com.
> This is probably the fault of some corporate takeover or other...
>
> "This is the main mailing list for the Freedom CPU Project.
>                 It will be broken down into various topic-specific lists
>                 as needed.
>
>                 To subscribe, send an empty message to
> f-cpu-subscribe@makelist.com
>
>                 To unsubscribe, send a message to f-cpu-unsubscribe@makelist.com
>
>                 List Owner: f-cpu-owner@makelist.com "

thank you Jeff... i'm rather upset that they changed the subscription
details without sending us a notice.

read you soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Fri Oct 20 03:02:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00626 for ; Sun, 22 Oct 2000 02:01:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:35 +0200 (MEST) Received: (qmail 8735 invoked by uid 0); 20 Oct 2000 01:02:37 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 20 Oct 2000 01:02:37 -0000 X-eGroups-Return: sentto-1101623-1233-972003751-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 20 Oct 2000 01:02:32 -0000 X-Sender: gjunker@one.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 01:02:31 -0000 Received: (qmail 72518 invoked from network); 20 Oct 2000 01:02:17 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 20 Oct 2000 01:02:17 -0000 Received: from unknown (HELO mail1.one.net) (206.112.192.107) by mta1 with SMTP; 20 Oct 2000 01:02:17 -0000 Received: from port-37-11.access.one.net ([209.50.100.25] HELO tsunami ident: IDENT-NOT-QUERIED [port 52775]) by mail.one.net with SMTP id <836608-19798>; Thu, 19 Oct 2000 21:02:17 -0400 Sender: "Gregory Junker" To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: X-eGroups-From: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Oct 2000 21:02:03 -0400 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Where's the source? Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C03A10.2EFAF3E0" X-UIDL: 38ce2b791b94cb355f16cc7821e87a25 Status: R X-Status: N ------=_NextPart_000_0008_01C03A10.2EFAF3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ah ha, see that's the nice thing about CVS, it has a command-line executable ;-P...as well as a web-based GUI (I forget the home location of the web GUI source, it's around somewhere)   When it's available I'll post that fact here (unless someone gets one going in the meantime :)   greg   PGP Key available at ldap://certserver.pgp.com or http://pgpkeys.mit.edu:11371   -----Original Message----- From: Yann Guidon [mailto:whygee@f-cpu.org] Sent: Thursday, October 19, 2000 8:48 PM To: f-cpu@egroups.com Subject: Re: [f-cpu] Where's the source? hi ! (late answer) "Junker, Gregory G" wrote: > Again, if I were to dedicate a single Linux server to CVS and > nothing else, I would have no problem hosting it; like I said, I have to > anyway for other reasons, so if FCPU wanted to piggyback on that, the > offer's open... i see no reason to refuse :-) anyway, i'm more used to ftp or web forms. i'm lazy to install WinCVS :-) As people will start to add or modify files, it will certainly become important anyway. > greg WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ eGroups Sponsor ------=_NextPart_000_0008_01C03A10.2EFAF3E0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
ah ha, see that's the nice thing about CVS, it has a command-line executable ;-P...as well as a web-based GUI (I forget the home location of the web GUI source, it's around somewhere)
 
When it's available I'll post that fact here (unless someone gets one going in the meantime :)
 
greg
 

PGP Key available at ldap://certserver.pgp.com or http://pgpkeys.mit.edu:11371

 
-----Original Message-----
From: Yann Guidon [mailto:whygee@f-cpu.org]
Sent: Thursday, October 19, 2000 8:48 PM
To: f-cpu@egroups.com
Subject: Re: [f-cpu] Where's the source?

hi !
(late answer)

"Junker, Gregory G" wrote:
<snip>
> Again, if I were to dedicate a single Linux server to CVS and
> nothing else, I would have no problem hosting it; like I said, I have to
> anyway for other reasons, so if FCPU wanted to piggyback on that, the
> offer's open...
i see no reason to refuse :-)
anyway, i'm more used to ftp or web forms.
i'm lazy to install WinCVS :-)
As people will start to add or modify files,
it will certainly become important anyway.

> greg
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


eGroups Sponsor
------=_NextPart_000_0008_01C03A10.2EFAF3E0-- From DuaneMHunt170976@aol.com Fri Oct 20 16:30:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00683 for ; Sun, 22 Oct 2000 02:01:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:56 +0200 (MEST) Received: (qmail 13840 invoked by uid 0); 20 Oct 2000 14:30:52 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 20 Oct 2000 14:30:52 -0000 X-eGroups-Return: sentto-1101623-1234-972052215-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.35] by hj.egroups.com with NNFMP; 20 Oct 2000 14:30:20 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 14:30:14 -0000 Received: (qmail 28882 invoked from network); 20 Oct 2000 14:30:14 -0000 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 20 Oct 2000 14:30:14 -0000 Received: from unknown (HELO ho.egroups.com) (10.1.2.219) by mta2 with SMTP; 20 Oct 2000 14:30:14 -0000 X-eGroups-Return: DuaneMHunt170976@aol.com Received: from [10.1.2.52] by ho.egroups.com with NNFMP; 20 Oct 2000 14:30:13 -0000 To: f-cpu@egroups.com Message-ID: <8spktf+ga32@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 62.254.0.5 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 14:30:07 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Let me get this then Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c74e0955a3f38da0cdeaa10f1f8f3d4a Status: R X-Status: N Right then

You lot want to make a NEW CPU
I guess to be BETTER than any that AMD, INTEL or VIA(Cryix) can make
WHY these boys pay millions on this but there is on thing you could
do with all you information about CPUs that is

A Graphics Card or a Sound Card or even a USB/Parrel Port Card with
have a BILLION DEAD CPUs like the Cryix M2 and the AMD K5 and with
the K6 soon to go the same with the intro of the Athlon and P4
We have all this GOOD CPUs on the TIP and take years to break down
and there WORTHLESS well 1p maybe. We also have EDO memory and the
only 72Pin Simms we got a processor we got memory they both no how to
talk to a computer because there were a computer at one point in time
so what not use this WORTHLESS stuff and make it NEW and CHEAP in to
are Graphics Cards and Sound Cards
We already have a Processor on a Graphics Card but this costs about
=A3150-=A3250
Could EASY make a AGP card with a CPU and FAN on top to cool it just
make sure that the CPU is facing away from the rest of the cards then
we have space for the fan and this should make the computer run
cheaper and fast for us POOR people who cant pay =A3150-=A3250 for
a good
card.


Yours LOVINGLY
Duane M Hunt (Newark Nottinghamshire England)

Lets not MAKE NEW JUNK Lets RE-Vamp the OLD Stuff

Old Hard Drives (150Mb) and a 4xCD-Rom with a old Case(Power Unit)
with a bit or LINUX HELP you could have a good MP3 Music Player there
>from stuff no one wants..

Its a DREAM any way..if any one wants to take this dream i would be
keen to help and would love to know more..
eGroups Sponsor=
3D""
From Nathaniel Downes Fri Oct 20 21:45:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00686 for ; Sun, 22 Oct 2000 02:01:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:57 +0200 (MEST) Received: (qmail 4923 invoked by uid 0); 20 Oct 2000 14:44:40 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 20 Oct 2000 14:44:40 -0000 X-eGroups-Return: sentto-1101623-1235-972053035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 20 Oct 2000 14:43:57 -0000 X-Sender: down@ici.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 14:43:55 -0000 Received: (qmail 7485 invoked from network); 20 Oct 2000 14:43:54 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 20 Oct 2000 14:43:54 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 20 Oct 2000 14:43:54 -0000 Received: from dc-57-27.ici.net (dc-57-27.ici.net [207.180.57.27]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id KAA18336 for ; Fri, 20 Oct 2000 10:43:58 -0400 (EDT) To: f-cpu@egroups.com Message-Id: Organization: Eddas, Inc. X-Mailer: Voyager Email for QNX (vmail v2.02) From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 15:45:37 -0400 (edt) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ERIN32 Progress Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fabab63b1394df47e1855f639514c350 Status: R X-Status: N Previously, you (Richard E.Hartney) wrote:
> The Language Processor is complete, waiting for Eclipse Software to be released.
> This design has a 4 deep pipeline structure.
>
> Curently doing its companion, the MMP (Memory Management Processor) which is synchronous with the Language Processor (LP).  Its functions are:
>
>     1.  Operand prefetch for LP
>     2.  Transparent JUMP
>     3.  Transparent Indirect JUMP
>     4.  Transparent Jump & Store Return (JST}
>     5    Enable Interrupts (May be executed with any LP Instruction)
>     6.   Disable Interrupts (May be executed with any LP Instruction)
>     7.   Conditional Jump (Not transparent)
>     8.   Interrupt Processing (This effectively an Indirect Jump & Store Return)
>
> Timing diagram indicates a performance in the 200 - 300 MHZ range.  A preliminary
> PC Board layout indicates adequate space for adding an additional 4 levels of pipeline.  This requires two LP's and two MMP's with additional program memory.
> which should yield a performance of 400 - 600 MHZ.  Simulation results will tell me the basic Clock Oscillator to use.  I will use the SILOS Simulator which is included with the Eclipse Software.  The PC Board also includes an FBC (Fully Buffered Channel) chip & 1 MegByte Local Memory.  All memory is SSRAM (Synchronous Static RAM) either two or four port.  PC Board size is approx 8 1/2 inches by 11 inches.  I will require two of these identical boards - one for the LP and one for the Peripheral Processor.  I DO NOT require the added performance but gut feel says DO IT for un-anticipated applications.  It will create another new set of logic problems that I won't go in to.
>
>
> Sincerely
> Richard E. Hartney
> Research Director
> Erin Greene & Associates

Not to sound like a negative voice, I'm going "dammit".  I was working on such a MMP already.  Well, now it's time to compare/contrast the two, eh?
eGroups Sponsor
From Yann Guidon Fri Oct 20 22:52:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00695 for ; Sun, 22 Oct 2000 02:01:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:01:59 +0200 (MEST) Received: (qmail 23379 invoked by uid 0); 20 Oct 2000 19:53:13 -0000 Received: from ei.egroups.com (208.50.99.235) by mx06.rz2.gmx.net with SMTP; 20 Oct 2000 19:53:13 -0000 X-eGroups-Return: sentto-1101623-1236-972071590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 20 Oct 2000 19:53:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 19:53:09 -0000 Received: (qmail 58677 invoked from network); 20 Oct 2000 19:48:16 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Oct 2000 19:48:16 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 20 Oct 2000 19:48:16 -0000 Received: from f-cpu.org (nas4-105.ras.club-internet.fr [195.36.203.105]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA04937 for ; Fri, 20 Oct 2000 21:48:12 +0200 (MET DST) Message-ID: <39F0B0A4.3C872A48@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8spktf+ga32@eGroups.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 21:52:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let me get this then Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4ea24929c6ac3691634c22e1e778150d Status: R X-Status: N hello Duane,

DuaneMHunt170976@aol.com wrote:
<snip>

i have a personnal comment about what you wrote.
I'm ok to say that used CPUs could be useful.
Unfortunately, they are not really efficient
for video cards : they're completely inadapted.
the CPUs' internal frequency is not even adapted
to the performance required by a usual video card.
The instruction decoding rate and the memory
bandwidths, not forgetting of course the incredible
power consumption, are not comparable to the
chips that populate =A330 video cards. Plus,
if you spend 1p for a used Socket-7 CPU,
you'll spend much more money for designing, building
and soldering the PCB (4 to 6 layers minimum).

In comparison, designing a CPU looks so easy :-)
that's why i prefer to work on this "simple" subject.
Of course, what you propose is "technically"
possible, but out of reach of a single person.
You'll certainly learn a lot anyway.

yours,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Fri Oct 20 15:05:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00698 for ; Sun, 22 Oct 2000 02:02:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:00 +0200 (MEST) Received: (qmail 21243 invoked by uid 0); 20 Oct 2000 19:57:44 -0000 Received: from f19.egroups.com (64.209.169.107) by mx19.rz2.gmx.net with SMTP; 20 Oct 2000 19:57:44 -0000 X-eGroups-Return: sentto-1101623-1237-972071779-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by f19.egroups.com with NNFMP; 20 Oct 2000 19:56:45 -0000 X-Sender: cancun76@amele.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 20 Oct 2000 19:56:19 -0000 Received: (qmail 31919 invoked from network); 20 Oct 2000 19:56:19 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 20 Oct 2000 19:56:19 -0000 Received: from unknown (HELO gbdgi.gbdgi.ru) (194.87.169.36) by mta3 with SMTP; 20 Oct 2000 19:56:15 -0000 Received: from _[221.34.241.230]_by (wall.gbdgi.ru [194.87.169.47]) by gbdgi.gbdgi.ru (8.11.1/8.11.1) with SMTP id e9KJwnV05185; Fri, 20 Oct 2000 23:58:50 +0400 Message-Id: <200010201958.e9KJwnV05185@gbdgi.gbdgi.ru> Received: from [60.114.242.241] by _[221.34.241.230]_by with SMTP id A51C21E10 Fri, 20 Oct 2000 12:47:50 PDT From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 13:05:07 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Want More Clients? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 658db9ca3388a7591593e19d49c93bc5 Status: R X-Status: N
More Leads = More Sales!!! More Sales = Greater Income!!!

 




IF YOU'RE SERIOUS ABOUT
YOUR BUSINESS, PLEASE
FILL OUT THE FORM BELOW
AND ONE OF OUR STAFF
MEMBERS WILL CONTACT YOU.

 

 


WE DELIVER THE MOST UNIQUE DIRECT EMAIL MARKETING CAMPAIGN IN THE WORLD
With a database of over 350 million potential customers/clients, we can reach your clients anywhere in the world. With graphics, pictures and bullet descriptions, your potential client will not miss your message.

PUT OUR PROFESSIONAL MARKETERS ON YOUR TEAM
Our staff members are graduates from major MBA Universities, with years of experience in the marketing field. We can craft an advertising campaign, specifically targeted to your client base, which will generate serious leads in huge numbers.

OUR OPT-IN LISTS ARE THE CLEANEST IN THE INDUSTRY
Directing E-mail marketing is a proven method to reach global and local markets with a small expense compared to that of conventional marketing. Quality work and a dedicated professional staff will ensure your ad campaign to be successful.

GREATEST RETURN ON YOUR MARKETING DOLLAR
To reach millions of potential clients in newspapers, radio and television would cost several tens of thousands. We can produce and deliver your message/advertisement to the greatest number of clients, resulting with the greatest number of sales. Hence, we give you the greatest return on your marketing dollar.
Your Name:
Your Web Address:
Company Name:
State:
Business Phone:
Home Phone:
Email:
Type of Business:

If you received this in error or would like to
be removed from our list, PLEASE CLICK HERE


eGroups Sponsor
From David Cary Sat Oct 21 06:12:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00716 for ; Sun, 22 Oct 2000 02:02:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:04 +0200 (MEST) Received: (qmail 23041 invoked by uid 0); 21 Oct 2000 04:17:22 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 21 Oct 2000 04:17:22 -0000 X-eGroups-Return: sentto-1101623-1238-972101838-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 21 Oct 2000 04:17:19 -0000 X-Sender: d.cary@ieee.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 21 Oct 2000 04:17:17 -0000 Received: (qmail 478 invoked from network); 21 Oct 2000 04:17:17 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 21 Oct 2000 04:17:17 -0000 Received: from unknown (HELO mail1.primary.net) (216.87.38.221) by mta2 with SMTP; 21 Oct 2000 04:17:17 -0000 Received: from [192.168.1.40] (ip14-tc1.busprod.com [207.150.72.14]) by mail1.primary.net (8.10.0+jb/8.10.0/8.10-0+tht) with ESMTP id e9L4GiH04008 for ; Fri, 20 Oct 2000 23:16:45 -0500 X-Sender: cary@www.rdrop.com Message-Id: In-Reply-To: References: To: f-cpu@egroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Oct 2000 23:12:06 -0500 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5359ffb79cc39d02ea306a8342608bf Status: R X-Status: N
>From: <gjunker@one.net>
>Date: Sun, 6 Aug 2000 22:10:40 -0400
>Subject: RE: [f-cpu] test, comments and question
...
>I am a Computer  Engineer, architecture my minor

Architecture as in bricks and masonry, or "computer architecture" ?

...
>I am  also involved somewhat in the ReactOS (www.reactos.com) development
...

Have you seen
  http://www.rdrop.com/~cary/html/computer_architecture.html#os
?

>From: Yann Guidon <whygee@f-cpu.org>
>Date: Mon, 07 Aug 2000 04:38:12 +0200
>Subject: Re: [f-cpu] test, comments and question
...
>I'd like a US F-CPU club, or something like that, to appear,

I'm here in Tulsa, Oklahoma, USA.

> because
>the americans are not organised

You've got that right :-).

...
>WHYGEE

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://www.rdrop.com/~cary/
"icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
eGroups Sponsor
From Yann Guidon Sat Oct 21 20:36:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00752 for ; Sun, 22 Oct 2000 02:02:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:14 +0200 (MEST) Received: (qmail 5639 invoked by uid 0); 21 Oct 2000 20:28:26 -0000 Received: from hj.egroups.com (208.50.99.212) by mx12.rz2.gmx.net with SMTP; 21 Oct 2000 20:28:26 -0000 X-eGroups-Return: sentto-1101623-1239-972160097-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 21 Oct 2000 20:28:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 21 Oct 2000 20:28:16 -0000 Received: (qmail 37073 invoked from network); 21 Oct 2000 20:28:16 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 21 Oct 2000 20:28:16 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 21 Oct 2000 20:28:16 -0000 Received: from f-cpu.org (nas4-107.ras.club-internet.fr [195.36.203.107]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA25568 for ; Sat, 21 Oct 2000 19:32:19 +0200 (MET DST) Message-ID: <39F1E243.75B4F49C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Oct 2000 19:36:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 399877d7c8acd6edd2aadbfe5f42e54d Status: R X-Status: N hi !

David Cary wrote:
> >From: <gjunker@one.net>
> >Date: Sun, 6 Aug 2000 22:10:40 -0400
> >Subject: RE: [f-cpu] test, comments and question
> ..
> >I am a Computer  Engineer, architecture my minor
> Architecture as in bricks and masonry, or "computer architecture" ?
i guess that the answer was obvious ;-)
btw, David, welcome back :-)
i was waiting for you to put the HTML links
on your page for the Utopia Computing Webring.
Please do something, please ;-) contact me ASAP.

> >From: Yann Guidon <whygee@f-cpu.org>
> >Date: Mon, 07 Aug 2000 04:38:12 +0200
> >Subject: Re: [f-cpu] test, comments and question
> ..
> >I'd like a US F-CPU club, or something like that, to appear,
> I'm here in Tulsa, Oklahoma, USA.
> > because the americans are not organised
> You've got that right :-).
you've gotta see what the germans can do, sometimes :-P
Unfortunately, most of them are as scattered on the german
territories as the american f-cpuers. We're lucky in France
because a noticeable fraction of us are in or around Paris.

Ok, I've spent most of the night programming a GNU
utility called GDUPS. it's like a super-locate for hunting
duplicate files down and it works beyond my expectations :-)

> David Cary "mailto:d.cary@ieee.org" ><> <*> O-
>   http://www.rdrop.com/~cary/
> "icbmto:N36 09.055' W95 58.730'" (was: "icbmto:N36 08.830' W97 03.443'")
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From DuaneMHunt170976@aol.com Sun Oct 22 00:52:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00770 for ; Sun, 22 Oct 2000 02:02:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:18 +0200 (MEST) Received: (qmail 4997 invoked by uid 0); 21 Oct 2000 22:52:44 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 21 Oct 2000 22:52:44 -0000 X-eGroups-Return: sentto-1101623-1240-972168761-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 21 Oct 2000 22:52:43 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 21 Oct 2000 22:52:40 -0000 Received: (qmail 14930 invoked from network); 21 Oct 2000 22:52:40 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 21 Oct 2000 22:52:40 -0000 Received: from unknown (HELO imo-r10.mail.aol.com) (152.163.225.10) by mta1 with SMTP; 21 Oct 2000 22:52:39 -0000 Received: from DuaneMHunt170976@aol.com by imo-r10.mx.aol.com (mail_out_v28.31.) id a.3e.27105ac (16787) for ; Sat, 21 Oct 2000 18:52:30 -0400 (EDT) Message-ID: <3e.27105ac.2723782d@aol.com> To: f-cpu@egroups.com X-Mailer: Windows AOL sub 111 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Oct 2000 18:52:29 EDT Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let me get this then Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4a0cc28c8083ca6ae83bd8efd82ca4b5 Status: R X-Status: N I think you would get an EEC Grant to help with the WASTE
CHIPS dont DEGRADE or that slowly it seems like it
IM always getting told that the AMD K5 and K6 and all
the rest have MMX and 3D-Now WHAT COOL buzz words
But didn't that MMX mean better SOUND and didn't that
3D-Now mean better GRAPHICS...

And dont the G-Force have its on Processor
the thing that makes it BRILL

a CPU talking to another CPU with a little help
would work but Brothers in a way x86 but a CPU
talking to a NEW Graphics Procesor needs more
and more TRANSLASHION

Granted that it will cost but better than WASTE and
it may give Computer to more people


GIVE A CPU A HOME
REMEMBER A CPU ISNT just for CHRISTMAS
its FOR LIFE
eGroups Sponsor
From DuaneMHunt170976@aol.com Sun Oct 22 00:55:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00773 for ; Sun, 22 Oct 2000 02:02:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:19 +0200 (MEST) Received: (qmail 30086 invoked by uid 0); 21 Oct 2000 22:55:24 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 21 Oct 2000 22:55:24 -0000 X-eGroups-Return: sentto-1101623-1241-972168923-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jk.egroups.com with NNFMP; 21 Oct 2000 22:55:20 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 21 Oct 2000 22:55:23 -0000 Received: (qmail 28507 invoked from network); 21 Oct 2000 22:55:23 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 21 Oct 2000 22:55:23 -0000 Received: from unknown (HELO imo-d02.mx.aol.com) (205.188.157.34) by mta3 with SMTP; 21 Oct 2000 22:55:22 -0000 Received: from DuaneMHunt170976@aol.com by imo-d02.mx.aol.com (mail_out_v28.31.) id a.ca.bb3ebbd (16787) for ; Sat, 21 Oct 2000 18:55:18 -0400 (EDT) Message-ID: To: f-cpu@egroups.com X-Mailer: Windows AOL sub 111 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Oct 2000 18:55:18 EDT Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 547ef393b638d37fbd6cac9529b0d50c Status: R X-Status: N RACE AREA DONT MATTER ALL A GROUP WANTING TO LEARN AND THINK
We dont need to BREAK up in to other RACE/AREA Groups we should work as one
and fight out NEW and IMPROVED IDEAS

The Dreams of TODAY may COME the FACTS of TOMORROW

BROTHERS AND SISTERS IN HUMAN UNION
eGroups Sponsor
From Michael Riepe Sun Oct 22 01:52:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00776 for ; Sun, 22 Oct 2000 02:02:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Oct 2000 02:02:19 +0200 (MEST) Received: (qmail 15816 invoked by uid 0); 21 Oct 2000 23:53:08 -0000 Received: from fj.egroups.com (64.209.169.104) by mx19.rz2.gmx.net with SMTP; 21 Oct 2000 23:53:08 -0000 X-eGroups-Return: sentto-1101623-1242-972172380-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fj.egroups.com with NNFMP; 21 Oct 2000 23:53:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 21 Oct 2000 23:53:00 -0000 Received: (qmail 9427 invoked from network); 21 Oct 2000 23:53:00 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 21 Oct 2000 23:53:00 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.155) by mta3 with SMTP; 21 Oct 2000 23:52:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02214; Sun, 22 Oct 2000 01:52:54 +0200 Message-ID: <20001022015254.18810@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F1E243.75B4F49C@f-cpu.org>; from Yann Guidon on Sat, Oct 21, 2000 at 07:36:51PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 01:52:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d00e880ddce1c277e87868476e273720 Status: R X-Status: N Moin, moin...

On Sat, Oct 21, 2000 at 07:36:51PM +0100, Yann Guidon wrote:
[...]
> you've gotta see what the germans can do, sometimes :-P

`sometimes' is correct.  In practice, it means: `after the initial
paperwork is done, and before the final paperwork starts' ;)

> Unfortunately, most of them are as scattered on the german
> territories as the american f-cpuers. We're lucky in France
> because a noticeable fraction of us are in or around Paris.

German Linux users are scattered, too.  That didn't stop them ;)
There are Linux User Groups all over the country; some of them were
founded as early as 1993/4, when almost nobody knew what Linux was.
We also had lots of ready-to-use Linux distributions made in Germany
those days -- SuSE, DLD (bought by RedHat recently), LST (which became
part of Caldera later) and Unifix (defunct AFAIK), for example.

I guess geographical distance doesn't matter if you *really* want
something.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From DuaneMHunt170976@aol.com Sun Oct 22 02:33:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00309 for ; Mon, 23 Oct 2000 22:49:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:36 +0200 (MEST) Received: (qmail 2166 invoked by uid 0); 22 Oct 2000 00:33:57 -0000 Received: from fl.egroups.com (64.209.169.106) by mx0.gmx.net with SMTP; 22 Oct 2000 00:33:57 -0000 X-eGroups-Return: sentto-1101623-1243-972174834-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fl.egroups.com with NNFMP; 22 Oct 2000 00:33:55 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 00:33:53 -0000 Received: (qmail 26212 invoked from network); 22 Oct 2000 00:33:53 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 22 Oct 2000 00:33:53 -0000 Received: from unknown (HELO imo-r16.mail.aol.com) (152.163.225.70) by mta3 with SMTP; 22 Oct 2000 00:33:53 -0000 Received: from DuaneMHunt170976@aol.com by imo-r16.mx.aol.com (mail_out_v28.31.) id a.38.cf0f93a (16787) for ; Sat, 21 Oct 2000 20:33:46 -0400 (EDT) Message-ID: <38.cf0f93a.27238fea@aol.com> To: f-cpu@egroups.com X-Mailer: Windows AOL sub 111 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Oct 2000 20:33:46 EDT Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 97a123db1b6507390f89a367def0468a Status: R X-Status: N LIINUX is bloody powerful i am trying to place it on my computer but having= a
few problems.

1. i cant read that well there for eht questsions it asks i guess a bit
2. i gave it 7gb of my hard drive but its wiped it and cant get it back
3. its SuSE v6.4 i got it then 4 days letter there was v7 GITS
4. I sent them a EMAIL telling them of this they said i was at UNI set from=
newark.ac.uk (Ps this is just a COLLEGE its a small TOWN) but because i was=
at UNI i could have the v7 Pro for only =A340 the same price i payed out fo= r
the standard v6.4 one sob sob sob


So once i got all that JUNK off my Hard Drive i will RESET the DAM thing an= d
put windows back on and give it all that 23Gb it wants again and give the 7= gb
to Linux i think i got to break it down to 4Gb and a 3Gb tho well any way..=

LINUX is POWER and POWER is MONEY (dam thats a big electricity bill)
i think with a ONE OFF LINUX OS CD Player what YOU DONT SEE a CD-ROM QUAD <= BR> DAUL etc speeds a cheap sound card a small HHD what will hold the LINUX OS = CD
PLAY to play CD's MP CD's and DVD sound tracks and even CD-RW sounds.

Updataing said player well could have ti so when it reads the CD if the Cd =
has a CODE on it , it will update or REINSTALL the newest version..
Another way would be to have a cheap Modem a ISA one that no one wants any =
more downloading the NEWEST on from the NET

Because this LINUX OS CD Player is LIMITED to what you want it to do it don= t
need all the JUNK toys like SCANDISK and DEFRAG etc etc

but will need maybe some talking between a modem updating and the HHD maybe= a
CHEAP MOTHERBOARD an old 586 would do its only for music

eGroups Sponsor=
3D""
From Yann Guidon Sun Oct 22 04:01:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00312 for ; Mon, 23 Oct 2000 22:49:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:37 +0200 (MEST) Received: (qmail 23345 invoked by uid 0); 22 Oct 2000 00:57:06 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 22 Oct 2000 00:57:06 -0000 X-eGroups-Return: sentto-1101623-1245-972176220-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 22 Oct 2000 00:57:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 00:57:00 -0000 Received: (qmail 5951 invoked from network); 22 Oct 2000 00:57:00 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 22 Oct 2000 00:57:00 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 22 Oct 2000 00:56:59 -0000 Received: from f-cpu.org (nas3-27.ras.club-internet.fr [195.36.203.27]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA08941 for ; Sun, 22 Oct 2000 02:56:55 +0200 (MET DST) Message-ID: <39F24A79.5DC16928@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3e.27105ac.2723782d@aol.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 03:01:29 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let me get this then Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f5c61fefc638d50c1db6324eb4da38be Status: R X-Status: N hello,

DuaneMHunt170976@aol.com wrote:
> I think you would get an EEC Grant to help with the WASTE
> CHIPS dont DEGRADE or that slowly it seems like it
> IM always getting told that the AMD K5 and K6 and all
> the rest have MMX and 3D-Now WHAT COOL buzz words
> But didn't that MMX mean better SOUND and didn't that
> 3D-Now mean better GRAPHICS...

all i know is that it's slow like hell.
i get an average of 2x of speedup when using
MMX because the usual x86 is so fucked up that
it requires you to move data around the registers
all the time, wasting all the

> And dont the G-Force have its on Processor
> the thing that makes it BRILL
>
> a CPU talking to another CPU with a little help
> would work but Brothers in a way x86 but a CPU
> talking to a NEW Graphics Procesor needs more
> and more TRANSLASHION

i guess that there's a huge point that you miss.
the reality is really, really, really really
more complex than you could ever imagine.
Not only the x86 chips are incredibly complex
and unbalanced, but a whole book on VGA
graphics (not speaking about VESA or super vga)
takes thousands of pages. All the layers
of compatibility since the IBM PC of the 80s
have added so much complexity that it's a
real nightmare.

if you want cool graphics, buy a
Silicon Graphics workstation or a PS2.
HW is known to outperform SW.
PC is not for graphics ; still pictures, maybe.
otherwise, buy adapted professional HW.

> Granted that it will cost but better than WASTE and
> it may give Computer to more people
>
> GIVE A CPU A HOME
> REMEMBER A CPU ISNT just for CHRISTMAS
> its FOR LIFE

well said :-)
i collect some old server motherboards
(MIPS, SUN, SONY NEWS, NCR...)

yours,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 22 04:01:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00315 for ; Mon, 23 Oct 2000 22:49:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:38 +0200 (MEST) Received: (qmail 23359 invoked by uid 0); 22 Oct 2000 00:57:08 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 22 Oct 2000 00:57:08 -0000 X-eGroups-Return: sentto-1101623-1244-972176220-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 22 Oct 2000 00:57:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 00:56:59 -0000 Received: (qmail 5942 invoked from network); 22 Oct 2000 00:56:59 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 22 Oct 2000 00:56:59 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 22 Oct 2000 00:56:59 -0000 Received: from f-cpu.org (nas3-27.ras.club-internet.fr [195.36.203.27]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA08940 for ; Sun, 22 Oct 2000 02:56:55 +0200 (MET DST) Message-ID: <39F24A7C.10435967@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 03:01:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 442901c0d13a78cdabe619227bff8c0f Status: R X-Status: N hi !

Michael Riepe wrote:
> Moin, moin...
n'abend, auch,

> On Sat, Oct 21, 2000 at 07:36:51PM +0100, Yann Guidon wrote:
> [...]
> > you've gotta see what the germans can do, sometimes :-P
> `sometimes' is correct.  In practice, it means: `after the initial
> paperwork is done, and before the final paperwork starts' ;)
In france, it's quite different, you have to fight a lot to make
an idea work. Once it's ok, it's ok, but it's too late too ;-)
French people need others to show them the way, before they
even intend to act a bit.

> > Unfortunately, most of them are as scattered on the german
> > territories as the american f-cpuers. We're lucky in France
> > because a noticeable fraction of us are in or around Paris.
> German Linux users are scattered, too.  That didn't stop them ;)
i know, of course :-)
but that was a problem on the german mailing list, when they wanted
to constitute a Verein. The rules are more strict than in France
and they couldn't easily find 7 people located next to each others
to fill in the administrative papers. They also have had the same
problem as the french association for the legal stuffs because
there are no lawyers/specialists.

<snip LUGs>
i have a Suse 6.3

> I guess geographical distance doesn't matter if you *really* want
> something.
yep. but it doesn't help either ;-)

> Ciao,
Gute Nacht,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"


hi again,

DuaneMHunt170976@aol.com wrote:
> RACE AREA DONT MATTER ALL A GROUP WANTING TO LEARN AND THINK
> We dont need to BREAK up in to other RACE/AREA Groups we should work as one
> and fight out NEW and IMPROVED IDEAS
>
> The Dreams of TODAY may COME the FACTS of TOMORROW
>
> BROTHERS AND SISTERS IN HUMAN UNION

soory to contradict you, it was not about race at all. I spoke about
what i have seen during the last year in the f-cpu group.
when i speak about "americans" or "germans" or "french", it's more
about a local culture and how people have behaved. it's not criticism,
but a call for all the good wills here to be more involved and active
in the project. Of course, the F-CPU project is made by and for everybody
but let's see the facts :
- a group of 10 french people has bought the trademark during an operation.
- there are plans for a german Verein and a french association
- articles were published in american, spanish, german and french magazines,
    some of them were written or co-written by Mathias Brossard,
    Manuel Benet Navarro and me.
- The F-CPU manual is co-written by a lot of european people, a french guy
    is currently making the TEX formatting.
i forget the rest...

It's not an attempt to prove anything : i have met some americans and
the egroups server is certainly located in the US. What i want to say is :
"help ! we can't do everything ! it's time to participate a bit more !"
I have no doubt that the f-cpu project won't fail, but it won't succeed
if we do it alone in Europe. We need more people to take REAL responsibilities,
not just chat. remember that the dream of yesterday is coming to life
before our eyes, don't leave it die because "it's almost done, so why bother ?"

yours in f-cpuism,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Oct 22 04:46:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00318 for ; Mon, 23 Oct 2000 22:49:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:39 +0200 (MEST) Received: (qmail 2633 invoked by uid 0); 22 Oct 2000 01:42:35 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 22 Oct 2000 01:42:35 -0000 X-eGroups-Return: sentto-1101623-1246-972178901-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 22 Oct 2000 01:42:33 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 01:41:40 -0000 Received: (qmail 29488 invoked from network); 22 Oct 2000 01:41:40 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 22 Oct 2000 01:41:40 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 22 Oct 2000 01:41:40 -0000 Received: from f-cpu.org (nas3-30.ras.club-internet.fr [195.36.203.30]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA05743 for ; Sun, 22 Oct 2000 03:41:36 +0200 (MET DST) Message-ID: <39F254F6.26A6E4D7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 03:46:14 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) F-CPU configuration file Content-Type: multipart/mixed; boundary="------------D2BDD7155EEEC9325159577E" X-UIDL: 012b31e60b3de2fe013c2778811e2238 Status: R X-Status: N --------------D2BDD7155EEEC9325159577E Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

no i haven't finished the Icache. i'm guilty and i repent.
anyway, i have started to think about the ROP2 unit.
They have some parts in common so i also started to
write a VHDL "package", a file that contains all
the "generic" definitions of the CPU.
This is of course PRELIMINARY : i'll accept any
advice and enhancements. The opcode map will be added
in the future. please read and comment.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------D2BDD7155EEEC9325159577E Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="F-CPU_config.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="F-CPU_config.vhdl" LS0gRmlsZSBGLUNQVV9jb25maWcudmhkbA0KLS0gKGMpIFlhbm4gR1VJRE9OLCBvY3QuIDIx LCAyMDAwDQotLSB3aHlnZWVAZi1jcHUub3JnIC8gZi1jcHVAZWdyb3Vwcy5jb20NCi0tDQot LSBUaGlzIHBhY2thZ2UgZGVmaW5lcyB0aGUgImNoYXJhY3RlcmlzdGljIHdpZHRocyIgb2YN Ci0tIHRoZSBpbnRlcm5hbCB1bml0cy4gUGxlYXNlIHJlc3BlY3QgdGhlIHJlc3RyaWN0aW9u cy4NCg0KDQpwYWNrYWdlIEZDUFVfY29uZmlnIGlzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gTW9zdCBpbXBvcnRhbnQg Ri1DUFUgY29uc3RhbnRzIDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBjb25zdGFudCBNQVhTSVpFIDogbmF0dXJhbCA6PSA4 OyAgICAgICAgLS0gU2l6ZSBvZiB0aGUgcmVnaXN0ZXJzIGluIGJ5dGVzLCBhbnkgcG93ZXIg b2YgdHdvID49IDQuDQogIGNvbnN0YW50IFVNQVggOiBuYXR1cmFsIDo9IE1BWFNJWkUgKiA4 OyAtLSBTaXplIG9mIHRoZSByZWdpc3RlcnMgaW4gYml0cy4NCiAgY29uc3RhbnQgRl9SQU5H RSA6IG5hdHVyYWwgOj0gVU1BWC0xOyAgIC0tIFJhbmdlIG9mIGEgcmVnaXN0ZXIgd2lkdGgg ZGVjbGFyYXRpb24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLS0gU29tZSBhcmNoaXRlY3R1cmFsIGNvbnN0YW50cywgYm91 bmQgdG8gRkMwIG9ubHkgOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tIEwxIENhY2hlcyAoc3BsaXQgaW5zdHJ1Y3Rpb25z IGFuZCBkYXRhKQ0KICBMMURCd2lkdGggIDogbmF0dXJhbCA6PSAyNTYgOyAtLSBEYXRhIEJ1 cyB3aWR0aCwgb3Igd2lkdGggb2YgZWFjaCBjYWNoZSBsaW5lICgzMiBieXRlcykNCiAgTDFB QndpZHRoICA6IG5hdHVyYWwgOj0gMzIgIDsgLS0gQWRkcmVzcyBCdXMgd2lkdGgsIGluIDMy LWJ5dGUgY2h1bmNrcyAoMzIrNT0xMjhHQikNCiAgTDFMb2dMaW5lcyA6IG5hdHVyYWwgOj0g NiAgIDsgLS0gTG9nMiBvZiB0aGUgTnVtQmVyIG9mIGNhY2hlIExpbmVzIChNVVNUIGJlIEVW RU4pDQogIEwxTkJsaW5lcyAgOiBuYXR1cmFsIDo9IDY0ICA7IC0tIE51bUJlciBvZiBjYWNo ZSBMaW5lcyAoMioqTG9nTGluZXMpIChzbWFsbCBudW1iZXIgZm9yIHRoZSBmaXJzdCBhdHRl bXB0cykNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCi0tIFRoZSBTcGVjaWFsIFJlZ2lzdGVycyA6DQotLSAoY29waWVkIGZy b20gU1IuaCkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogIGNvbnN0YW50IFNSX05VTUJFUlMgICAgICA6IG5hdHVyYWwgOj0g MDsNCiAgY29uc3RhbnQgU1JfTlVNQkVSU192YWwgIDogbmF0dXJhbCA6PSAxMDsgICAgICAt LSAxMCBTUnMgYXJlIGltcGxlbWVudGVkIGluIHRoaXMgbW9kZWwNCg0KICBjb25zdGFudCBT Ul9GQU1JTFkgICAgICAgOiBuYXR1cmFsIDo9IDE7DQogIGNvbnN0YW50IFNSX0ZBTUlMWV92 YWwgICA6IG5hdHVyYWwgOj0gWCJGQzAiOyAgLS0gRi1DUFUgY29yZSBudW1iZXIsIG9yIHdo YXRldmVyICovDQoNCiAgY29uc3RhbnQgU1JfU1RFUFBJTkcgICAgIDogbmF0dXJhbCA6PSAy Ow0KICBjb25zdGFudCBTUl9TVEVQUElOR192YWwgOiBuYXR1cmFsIDo9IFgiMSI7ICAgIC0t IHJldmlzaW9uL2ltcGxlbWVudGF0aW9uICovDQoNCiAgY29uc3RhbnQgU1JfTUFYX1NJWkUg ICAgIDogbmF0dXJhbCA6PSAzOw0KICBjb25zdGFudCBTUl9NQVhfU0laRV92YWwgOiBuYXR1 cmFsIDo9IE1BWFNJWkU7IC0tIGluIGJ5dGVzLCBhIHBvd2VyIG9mIHR3byA+PSA0ICovDQoN CiAgY29uc3RhbnQgU1JfU0laRV8xICAgICAgIDogbmF0dXJhbCA6PSA0Ow0KICBjb25zdGFu dCBTUl9TSVpFXzFfdmFsICAgOiBuYXR1cmFsIDo9IDE7ICAgICAgIC0tIFNpemUgYXR0cmli dXRlIDEsIGhhcmR3aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4ICovDQoNCiAgY29uc3RhbnQg U1JfU0laRV8yICAgICAgIDogbmF0dXJhbCA6PSA1Ow0KICBjb25zdGFudCBTUl9TSVpFXzJf dmFsICAgOiBuYXR1cmFsIDo9IDI7ICAgICAgIC0tIFNpemUgYXR0cmlidXRlIDIsIGhhcmR3 aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4ICovDQoNCiAgY29uc3RhbnQgU1JfU0laRV8zICAg ICAgIDogbmF0dXJhbCA6PSA2Ow0KICBjb25zdGFudCBTUl9TSVpFXzNfdmFsICAgOiBuYXR1 cmFsIDo9IDQ7ICAgICAgIC0tIFNpemUgYXR0cmlidXRlIDMsIGhhcmR3aXJlZCBpZiBTUl9N QVhfU0laRSA8PSA4ICovDQoNCiAgY29uc3RhbnQgU1JfU0laRV80ICAgICAgIDogbmF0dXJh bCA6PSA3Ow0KICBjb25zdGFudCBTUl9TSVpFXzRfdmFsICAgOiBuYXR1cmFsIDo9IDg7ICAg ICAgIC0tIFNpemUgYXR0cmlidXRlIDQsIGhhcmR3aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4 ICovDQoNCiAgY29uc3RhbnQgU1JfQ1lDTEUgICAgICAgIDogbmF0dXJhbCA6PSA4OyAgICAg ICAtLSBSL1csIFZhbHVlIGlzIGR5bmFtaWMsIGluY3JlbWVudGVkIGV2ZXJ5IGN5Y2xlLg0K DQogIGNvbnN0YW50IFNSX1BBR0lORyAgICAgICA6IG5hdHVyYWwgOj0gOTsgICAgICAgLS0g UHJvdGVjdGVkLCBSL1csIENvbnRyb2xzIHRoZSBwYWdlZCBtZW1vcnkuDQoNCmVuZCBGQ1BV X2NvbmZpZzsNCg0KDQpwYWNrYWdlIEZDUFVfY29uZmlnIGlzDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gRW1wdHkuIE9u bHkgdGhlIGNvbnN0YW50cyBtYXR0ZXIgdW50aWwgdG9kYXkuDQotLSBTb21lIHVzZWZ1bCB3 cmFwcGVycyBvciBmdW5jdGlvbnMgY291bGQgYmUgaW5jbHVkZWQNCi0tIGhlcmUgaWYgdGhl eSBhcmUgbmVjZXNzYXJ5IGZvciB0aGUgcHJvamVjdC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQplbmQgRkNQVV9jb25maWc7 DQoNCg== --------------D2BDD7155EEEC9325159577E-- From Yann Guidon Sun Oct 22 05:29:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00321 for ; Mon, 23 Oct 2000 22:49:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:41 +0200 (MEST) Received: (qmail 32295 invoked by uid 0); 22 Oct 2000 02:25:09 -0000 Received: from f19.egroups.com (64.209.169.107) by mx0.gmx.net with SMTP; 22 Oct 2000 02:25:09 -0000 X-eGroups-Return: sentto-1101623-1247-972181505-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by f19.egroups.com with NNFMP; 22 Oct 2000 02:25:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 02:25:04 -0000 Received: (qmail 19605 invoked from network); 22 Oct 2000 02:25:04 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 22 Oct 2000 02:25:04 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 22 Oct 2000 02:25:04 -0000 Received: from f-cpu.org (nas2-252.ras.club-internet.fr [195.36.192.252]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA17938 for ; Sun, 22 Oct 2000 04:25:01 +0200 (MET DST) Message-ID: <39F25F1E.20ACD003@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 04:29:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) ooops ! corrections... Content-Type: multipart/mixed; boundary="------------58688DC61B7C880ADEA16540" X-UIDL: 030c70eb00acc4695be64a1fab86f4ab Status: R X-Status: N --------------58688DC61B7C880ADEA16540 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit sorry, i sent the last file too early.
i corrected some syntax errors.
This one MUST work, now.
I have also just added some lines to
the f-cpu.org index.html.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------58688DC61B7C880ADEA16540 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="F-CPU_config.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="F-CPU_config.vhdl" LS0gRmlsZSBGLUNQVV9jb25maWcudmhkbA0KLS0gKGMpIFlhbm4gR1VJRE9OLCBvY3QuIDIx LCAyMDAwDQotLSB3aHlnZWVAZi1jcHUub3JnIC8gZi1jcHVAZWdyb3Vwcy5jb20NCi0tDQot LSBUaGlzIHBhY2thZ2UgZGVmaW5lcyB0aGUgImNoYXJhY3RlcmlzdGljIHdpZHRocyIgb2YN Ci0tIHRoZSBpbnRlcm5hbCB1bml0cy4gUGxlYXNlIHJlc3BlY3QgdGhlIHJlc3RyaWN0aW9u cy4NCg0KDQpwYWNrYWdlIEZDUFVfY29uZmlnIGlzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gTW9zdCBpbXBvcnRhbnQg Ri1DUFUgY29uc3RhbnRzIDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBjb25zdGFudCBNQVhTSVpFIDogbmF0dXJhbCA6PSA4 OyAgICAgICAgLS0gU2l6ZSBvZiB0aGUgcmVnaXN0ZXJzIGluIGJ5dGVzLCBhbnkgcG93ZXIg b2YgdHdvID49IDQuDQogIGNvbnN0YW50IFVNQVggOiBuYXR1cmFsIDo9IE1BWFNJWkUgKiA4 OyAtLSBTaXplIG9mIHRoZSByZWdpc3RlcnMgaW4gYml0cy4NCiAgY29uc3RhbnQgRl9SQU5H RSA6IG5hdHVyYWwgOj0gVU1BWC0xICA7IC0tIFJhbmdlIG9mIGEgcmVnaXN0ZXIgd2lkdGgg ZGVjbGFyYXRpb24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLS0gU29tZSBhcmNoaXRlY3R1cmFsIGNvbnN0YW50cywgYm91 bmQgdG8gRkMwIG9ubHkgOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tIEwxIENhY2hlcyAoc3BsaXQgaW5zdHJ1Y3Rpb25z IGFuZCBkYXRhKQ0KICBjb25zdGFudCBMMURCd2lkdGggIDogbmF0dXJhbCA6PSAyNTYgOyAt LSBEYXRhIEJ1cyB3aWR0aCwgb3Igd2lkdGggb2YgZWFjaCBjYWNoZSBsaW5lICgzMiBieXRl cykNCiAgY29uc3RhbnQgTDFBQndpZHRoICA6IG5hdHVyYWwgOj0gMzIgIDsgLS0gQWRkcmVz cyBCdXMgd2lkdGgsIGluIDMyLWJ5dGUgY2h1bmNrcyAoMzIrNT0xMjhHQikNCiAgY29uc3Rh bnQgTDFMb2dMaW5lcyA6IG5hdHVyYWwgOj0gNiAgIDsgLS0gTG9nMiBvZiB0aGUgTnVtQmVy IG9mIGNhY2hlIExpbmVzIChNVVNUIGJlIEVWRU4pDQogIGNvbnN0YW50IEwxTkJsaW5lcyAg OiBuYXR1cmFsIDo9IDY0ICA7IC0tIE51bUJlciBvZiBjYWNoZSBMaW5lcyAoMioqTG9nTGlu ZXMpIChzbWFsbCBudW1iZXIgZm9yIHRoZSBmaXJzdCBhdHRlbXB0cykNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFRo ZSBTcGVjaWFsIFJlZ2lzdGVycyA6DQotLSAoY29waWVkIGZyb20gU1IuaCkNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogIGNv bnN0YW50IFNSX05VTUJFUlMgICAgICA6IG5hdHVyYWwgOj0gMDsNCiAgY29uc3RhbnQgU1Jf TlVNQkVSU192YWwgIDogbmF0dXJhbCA6PSAxMDsgICAgICAtLSAxMCBTUnMgYXJlIGltcGxl bWVudGVkIGluIHRoaXMgbW9kZWwNCg0KICBjb25zdGFudCBTUl9GQU1JTFkgICAgICAgOiBu YXR1cmFsIDo9IDE7DQogIGNvbnN0YW50IFNSX0ZBTUlMWV92YWwgICA6IG5hdHVyYWwgOj0g NDAzMjsgICAgIC0tIEYtQ1BVIGNvcmUgbnVtYmVyLiByZW1hcmsgOiAweEZDMCA9IDQwMzIg Oi0pDQoNCiAgY29uc3RhbnQgU1JfU1RFUFBJTkcgICAgIDogbmF0dXJhbCA6PSAyOw0KICBj b25zdGFudCBTUl9TVEVQUElOR192YWwgOiBuYXR1cmFsIDo9IDE7ICAgICAgIC0tIHJldmlz aW9uL2ltcGxlbWVudGF0aW9uDQoNCiAgY29uc3RhbnQgU1JfTUFYX1NJWkUgICAgIDogbmF0 dXJhbCA6PSAzOw0KICBjb25zdGFudCBTUl9NQVhfU0laRV92YWwgOiBuYXR1cmFsIDo9IE1B WFNJWkU7IC0tIGluIGJ5dGVzLCBhIHBvd2VyIG9mIHR3byA+PSA0DQoNCiAgY29uc3RhbnQg U1JfU0laRV8xICAgICAgIDogbmF0dXJhbCA6PSA0Ow0KICBjb25zdGFudCBTUl9TSVpFXzFf dmFsICAgOiBuYXR1cmFsIDo9IDE7ICAgICAgIC0tIFNpemUgYXR0cmlidXRlIDEsIGhhcmR3 aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4DQoNCiAgY29uc3RhbnQgU1JfU0laRV8yICAgICAg IDogbmF0dXJhbCA6PSA1Ow0KICBjb25zdGFudCBTUl9TSVpFXzJfdmFsICAgOiBuYXR1cmFs IDo9IDI7ICAgICAgIC0tIFNpemUgYXR0cmlidXRlIDIsIGhhcmR3aXJlZCBpZiBTUl9NQVhf U0laRSA8PSA4DQoNCiAgY29uc3RhbnQgU1JfU0laRV8zICAgICAgIDogbmF0dXJhbCA6PSA2 Ow0KICBjb25zdGFudCBTUl9TSVpFXzNfdmFsICAgOiBuYXR1cmFsIDo9IDQ7ICAgICAgIC0t IFNpemUgYXR0cmlidXRlIDMsIGhhcmR3aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4DQoNCiAg Y29uc3RhbnQgU1JfU0laRV80ICAgICAgIDogbmF0dXJhbCA6PSA3Ow0KICBjb25zdGFudCBT Ul9TSVpFXzRfdmFsICAgOiBuYXR1cmFsIDo9IDg7ICAgICAgIC0tIFNpemUgYXR0cmlidXRl IDQsIGhhcmR3aXJlZCBpZiBTUl9NQVhfU0laRSA8PSA4DQoNCiAgY29uc3RhbnQgU1JfQ1lD TEUgICAgICAgIDogbmF0dXJhbCA6PSA4OyAgICAgICAtLSBSL1csIFZhbHVlIGlzIGR5bmFt aWMsIGluY3JlbWVudGVkIGV2ZXJ5IGN5Y2xlLg0KDQogIGNvbnN0YW50IFNSX1BBR0lORyAg ICAgICA6IG5hdHVyYWwgOj0gOTsgICAgICAgLS0gUHJvdGVjdGVkLCBSL1csIENvbnRyb2xz IHRoZSBwYWdlZCBtZW1vcnkuDQoNCmVuZCBGQ1BVX2NvbmZpZzsNCg0KDQpwYWNrYWdlIEZD UFVfY29uZmlnIGlzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLS0gRW1wdHkuIE9ubHkgdGhlIGNvbnN0YW50cyBtYXR0ZXIg dW50aWwgdG9kYXkuDQotLSBTb21lIHVzZWZ1bCB3cmFwcGVycyBvciBmdW5jdGlvbnMgY291 bGQgYmUgaW5jbHVkZWQNCi0tIGhlcmUgaWYgdGhleSBhcmUgbmVjZXNzYXJ5IGZvciB0aGUg cHJvamVjdC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQplbmQgRkNQVV9jb25maWc7DQoNCg== --------------58688DC61B7C880ADEA16540-- From Yann Guidon Sun Oct 22 09:04:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00324 for ; Mon, 23 Oct 2000 22:49:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:42 +0200 (MEST) Received: (qmail 27885 invoked by uid 0); 22 Oct 2000 06:00:15 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net with SMTP; 22 Oct 2000 06:00:15 -0000 X-eGroups-Return: sentto-1101623-1248-972194412-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 22 Oct 2000 06:00:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 06:00:12 -0000 Received: (qmail 9047 invoked from network); 22 Oct 2000 06:00:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 22 Oct 2000 06:00:12 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 22 Oct 2000 06:00:11 -0000 Received: from f-cpu.org (nas3-92.aub.club-internet.fr [195.36.145.92]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA22451 for ; Sun, 22 Oct 2000 08:00:07 +0200 (MET DST) Message-ID: <39F2918A.765AF87E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 08:04:42 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) ROP2 and apologies Content-Type: multipart/mixed; boundary="------------FC7BE5A9181F5725D522EAD2" X-UIDL: 57741792ce260a4d7e0e9832090cc5ca Status: R X-Status: N --------------FC7BE5A9181F5725D522EAD2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

i detected a more subtle and severe error in the
FCPU_config.vhdl file (missing "body" keyword).
This is corrected and enhanced with some useful
syntax shortcuts (F_VECTOR).

I also made a first version of the ROP2 Execution
Unit. It compiles with Simili, it elaborates well
but i have not finished the testbench. It also only
supports byte chunks, not 16 and 32-bit COMBINE
operations. Corrections and comments are welcome.

enjoy,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------FC7BE5A9181F5725D522EAD2 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="F-CPU_config.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="F-CPU_config.vhdl" LS0gRmlsZSBGLUNQVV9jb25maWcudmhkbA0KLS0gKGMpIFlhbm4gR1VJRE9OLCBvY3QuIDIx LCAyMDAwDQotLSB3aHlnZWVAZi1jcHUub3JnIC8gZi1jcHVAZWdyb3Vwcy5jb20NCi0tDQot LSBUaGlzIHBhY2thZ2UgZGVmaW5lcyB0aGUgImNoYXJhY3RlcmlzdGljIHdpZHRocyIgb2YN Ci0tIHRoZSBpbnRlcm5hbCB1bml0cy4gUGxlYXNlIHJlc3BlY3QgdGhlIHJlc3RyaWN0aW9u cy4NCg0KTElCUkFSWSBpZWVlOw0KICAgIFVTRSBpZWVlLnN0ZF9sb2dpY18xMTY0LkFMTDsN Cg0KcGFja2FnZSBGQ1BVX2NvbmZpZyBpcw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIE1vc3QgaW1wb3J0YW50IEYtQ1BV IGNvbnN0YW50cyA6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KICBjb25zdGFudCBNQVhTSVpFIDogbmF0dXJhbCA6PSA4OyAg ICAgICAgLS0gU2l6ZSBvZiB0aGUgcmVnaXN0ZXJzIGluIGJ5dGVzLCBhbnkgcG93ZXIgb2Yg dHdvID49IDQuDQogIGNvbnN0YW50IFVNQVggOiBuYXR1cmFsIDo9IE1BWFNJWkUgKiA4OyAt LSBTaXplIG9mIHRoZSByZWdpc3RlcnMgaW4gYml0cy4NCiAgdHlwZSBGX1JBTkdFIGlzIHJh bmdlIFVNQVgtMSBkb3dudG8gMCA7IC0tIFJhbmdlIG9mIGEgcmVnaXN0ZXIgd2lkdGggZGVj bGFyYXRpb24uDQogIHN1YnR5cGUgRl9WRUNUT1IgaXMgc3RkX3Vsb2dpY192ZWN0b3IoRl9S QU5HRSkgOyAtLSBzaG9ydGN1dCBmb3IgYSB2ZXJ5IGNvbW1vbiBkZWNsYXJhdGlvbi4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQotLSBTb21lIGFyY2hpdGVjdHVyYWwgY29uc3RhbnRzLCBib3VuZCB0byBGQzAgb25seSA6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KLS0gTDEgQ2FjaGVzIChzcGxpdCBpbnN0cnVjdGlvbnMgYW5kIGRhdGEpDQogIGNv bnN0YW50IEwxREJ3aWR0aCAgOiBuYXR1cmFsIDo9IDI1NiA7IC0tIERhdGEgQnVzIHdpZHRo LCBvciB3aWR0aCBvZiBlYWNoIGNhY2hlIGxpbmUgKDMyIGJ5dGVzKQ0KICBjb25zdGFudCBM MUFCd2lkdGggIDogbmF0dXJhbCA6PSAzMiAgOyAtLSBBZGRyZXNzIEJ1cyB3aWR0aCwgaW4g MzItYnl0ZSBjaHVuY2tzICgzMis1PTEyOEdCKQ0KICBjb25zdGFudCBMMUxvZ0xpbmVzIDog bmF0dXJhbCA6PSA2ICAgOyAtLSBMb2cyIG9mIHRoZSBOdW1CZXIgb2YgY2FjaGUgTGluZXMg KE1VU1QgYmUgRVZFTikNCiAgY29uc3RhbnQgTDFOQmxpbmVzICA6IG5hdHVyYWwgOj0gNjQg IDsgLS0gTnVtQmVyIG9mIGNhY2hlIExpbmVzICgyKipMb2dMaW5lcykgKHNtYWxsIG51bWJl ciBmb3IgdGhlIGZpcnN0IGF0dGVtcHRzKQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gVGhlIFNwZWNpYWwgUmVnaXN0 ZXJzIDoNCi0tIChjb3BpZWQgZnJvbSBTUi5oKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgY29uc3RhbnQgU1JfTlVNQkVS UyAgICAgIDogbmF0dXJhbCA6PSAwOw0KICBjb25zdGFudCBTUl9OVU1CRVJTX3ZhbCAgOiBu YXR1cmFsIDo9IDEwOyAgICAgIC0tIDEwIFNScyBhcmUgaW1wbGVtZW50ZWQgaW4gdGhpcyBt b2RlbA0KDQogIGNvbnN0YW50IFNSX0ZBTUlMWSAgICAgICA6IG5hdHVyYWwgOj0gMTsNCiAg Y29uc3RhbnQgU1JfRkFNSUxZX3ZhbCAgIDogbmF0dXJhbCA6PSA0MDMyOyAgICAgLS0gRi1D UFUgY29yZSBudW1iZXIuIHJlbWFyayA6IDB4RkMwID0gNDAzMiA6LSkNCg0KICBjb25zdGFu dCBTUl9TVEVQUElORyAgICAgOiBuYXR1cmFsIDo9IDI7DQogIGNvbnN0YW50IFNSX1NURVBQ SU5HX3ZhbCA6IG5hdHVyYWwgOj0gMTsgICAgICAgLS0gcmV2aXNpb24vaW1wbGVtZW50YXRp b24NCg0KICBjb25zdGFudCBTUl9NQVhfU0laRSAgICAgOiBuYXR1cmFsIDo9IDM7DQogIGNv bnN0YW50IFNSX01BWF9TSVpFX3ZhbCA6IG5hdHVyYWwgOj0gTUFYU0laRTsgLS0gaW4gYnl0 ZXMsIGEgcG93ZXIgb2YgdHdvID49IDQNCg0KICBjb25zdGFudCBTUl9TSVpFXzEgICAgICAg OiBuYXR1cmFsIDo9IDQ7DQogIGNvbnN0YW50IFNSX1NJWkVfMV92YWwgICA6IG5hdHVyYWwg Oj0gMTsgICAgICAgLS0gU2l6ZSBhdHRyaWJ1dGUgMSwgaGFyZHdpcmVkIGlmIFNSX01BWF9T SVpFIDw9IDgNCg0KICBjb25zdGFudCBTUl9TSVpFXzIgICAgICAgOiBuYXR1cmFsIDo9IDU7 DQogIGNvbnN0YW50IFNSX1NJWkVfMl92YWwgICA6IG5hdHVyYWwgOj0gMjsgICAgICAgLS0g U2l6ZSBhdHRyaWJ1dGUgMiwgaGFyZHdpcmVkIGlmIFNSX01BWF9TSVpFIDw9IDgNCg0KICBj b25zdGFudCBTUl9TSVpFXzMgICAgICAgOiBuYXR1cmFsIDo9IDY7DQogIGNvbnN0YW50IFNS X1NJWkVfM192YWwgICA6IG5hdHVyYWwgOj0gNDsgICAgICAgLS0gU2l6ZSBhdHRyaWJ1dGUg MywgaGFyZHdpcmVkIGlmIFNSX01BWF9TSVpFIDw9IDgNCg0KICBjb25zdGFudCBTUl9TSVpF XzQgICAgICAgOiBuYXR1cmFsIDo9IDc7DQogIGNvbnN0YW50IFNSX1NJWkVfNF92YWwgICA6 IG5hdHVyYWwgOj0gODsgICAgICAgLS0gU2l6ZSBhdHRyaWJ1dGUgNCwgaGFyZHdpcmVkIGlm IFNSX01BWF9TSVpFIDw9IDgNCg0KICBjb25zdGFudCBTUl9DWUNMRSAgICAgICAgOiBuYXR1 cmFsIDo9IDg7ICAgICAgIC0tIFIvVywgVmFsdWUgaXMgZHluYW1pYywgaW5jcmVtZW50ZWQg ZXZlcnkgY3ljbGUuDQoNCiAgY29uc3RhbnQgU1JfUEFHSU5HICAgICAgIDogbmF0dXJhbCA6 PSA5OyAgICAgICAtLSBQcm90ZWN0ZWQsIFIvVywgQ29udHJvbHMgdGhlIHBhZ2VkIG1lbW9y eS4NCg0KZW5kIEZDUFVfY29uZmlnOw0KDQoNCnBhY2thZ2UgYm9keSBGQ1BVX2NvbmZpZyBp cw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCi0tIEVtcHR5LiBPbmx5IHRoZSBjb25zdGFudHMgbWF0dGVyIHVudGlsIHRvZGF5 Lg0KLS0gU29tZSB1c2VmdWwgd3JhcHBlcnMgb3IgZnVuY3Rpb25zIGNvdWxkIGJlIGluY2x1 ZGVkDQotLSBoZXJlIGlmIHRoZXkgYXJlIG5lY2Vzc2FyeSBmb3IgdGhlIHByb2plY3QuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KZW5kIEZDUFVfY29uZmlnOw0KDQo= --------------FC7BE5A9181F5725D522EAD2 Content-Type: application/x-unknown-content-type-vhdl_auto_file; name="ROP2.vhdl" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ROP2.vhdl" LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFJPUDIudmhkbCAtIFJPUDIgRXhlY3V0aW9uIFVu aXQgZm9yIHRoZSBGLUNQVQ0KLS0gQ29weXJpZ2h0IChDKSAyMDAwIFlhbm4gR1VJRE9OICh3 aHlnZWVAZi1jcHUub3JnKQ0KLS0NCi0tIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQotLSBpdCB1bmRlciB0 aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZCBieQ0KLS0gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24g MiBvZiB0aGUgTGljZW5zZSwgb3INCi0tIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl cnNpb24uDQotLQ0KLS0gVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQotLSBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7 IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KLS0gTUVSQ0hBTlRBQklM SVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KLS0g R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCi0tDQotLSBZ b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZQ0KLS0gYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUg dG8gdGhlIEZyZWUgU29mdHdhcmUNCi0tIEZvdW5kYXRpb24sIEluYy4sIDY3NSBNYXNzIEF2 ZSwgQ2FtYnJpZGdlLCBNQSAwMjEzOSwgVVNBLg0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQotLSBUaGlzIGlzIHRoZSBmaXJzdCB2ZXJzaW9uIGV2ZXIgZm9yIHRoaXMgdW5pdC4NCi0t IEl0IHNob3VsZCBiZSBlYXNpbHkgc3ludGhldGl6YWJsZSBidXQgdGhlcmUgaXMgbm8gcHJv b2YgeWV0Lg0KLS0gV2hhdCBtYXR0ZXJzIG1vc3QgdG9kYXkgaXMgdGhhdCBpdCBjb21waWxl cyBhbmQgYmVoYXZlcyBjb3JyZWN0bHkuDQotLSBXYXJuaW5nIDogdGhpcyBjb2RlIGlzIGFu ZCBzaG91bGQgcmVtYWluIHB1cmVseSBjb21iaW5hdG9yaWFsLA0KLS0gdGhlcmUgaXMgbm8g bGF0Y2hpbmcgaGVyZSwgaXQgbXVzdCBiZSBkb25lIGF0IGFub3RoZXIgbGV2ZWwuDQotLSBG dXJ0aGVybW9yZSwgdGhlIGZ1bmN0aW9uIGxvb2t1cCB0YWJsZSBzaG91bGQgYmUgbW92ZWQg ZWFybGllcg0KLS0gaW4gdGhlIHBpcGVsaW5lLCBpbiBwYXJhbGxlbCB3aXRoIHRoZSBYYmFy IGN5Y2xlLg0KLS0gRmluYWxseSwgb25seSBieXRlIGNvbWJpbmVzIGFyZSBwb3NzaWJsZSB5 ZXQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpMSUJSQVJZIGllZWU7DQogICAgVVNFIGll ZWUuc3RkX2xvZ2ljXzExNjQuQUxMOw0KICAgIFVTRSBpZWVlLm51bWVyaWNfc3RkLmFsbDsN CkxJQlJBUlkgd29yazsNCiAgICBVU0Ugd29yay5GQ1BVX2NvbmZpZy5BTEw7DQoNCkVudGl0 eSBFVV9ST1AyIGlzDQogIHBvcnQoDQogICAgRGluX0EsIERpbl9CICA6IGluIEZfVkVDVE9S OyAgICAgLS0gdGhlIDIgb3BlcmFuZHMNCiAgICBST1BfZnVuY3Rpb24gIDogaW4gU3RkX3Vs b2dpY192ZWN0b3IoMiBkb3dudG8gMCk7ICAtLSAzIGZ1bmN0aW9uIGJpdHMNCiAgICBDb21i aW5lX0FORCwgQ29tYmluZV9PUiA6IGluIFN0ZF91bG9naWM7ICAgICAgICAgICAtLSBhZGRp dGlvbmFsIGZ1bnRpb24NCiAgICBDb21iaW5lX3NpemUgOiBpbiBTdGRfdWxvZ2ljX3ZlY3Rv cigxIGRvd250byAwKTsgICAtLSB1bnVzZWQgQVRNLiBCeXRlIGNodW5ja3Mgb25seS4NCiAg ICBEb3V0ICAgICAgICAgOiBvdXQgRl9WRUNUT1IgICAgIC0tIHRoZSByZXN1bHQNCiAgKTsN CmVuZCBFVV9ST1AyOw0KDQpBcmNoaXRlY3R1cmUgYXJjaDEgb2YgRVVfUk9QMiBpcw0KICBz aWduYWwgcGFydGlhbF9yZXN1bHQsIHBhcnRpYWxfT1IsIHBhcnRpYWxfQU5EIDogRl9WRUNU T1I7ICAtLSB0aGUgcGFydGlhbCByZXN1bHRzLg0KICBzaWduYWwgbG9jYWxfZnVuY3Rpb24g OiBTdGRfdWxvZ2ljX3ZlY3RvcigzIGRvd250byAwKTsgIC0tIHRoZSBsb2NhbCwgZGVjb2Rl ZCwgZnVuY3Rpb24gYml0cy4NCmJlZ2luDQoNCi0tIDEgOiBsb29rdXAgdGFibGUgdGhhdCBk ZWNvZGVzIHRoZSBmdW5jdGlvbiBiaXRzDQotLSAgICAgICAgKHNob3VsZCBiZSBkb25lIGlu IGFuIGVhcmxpZXIgc3RhZ2UpDQogIHdpdGggUk9QX2Z1bmN0aW9uIHNlbGVjdA0KICAgIGxv Y2FsX2Z1bmN0aW9uIDw9DQogICAgICAiMDAwMSIgd2hlbiAiMDAwIiwgIC0tIEFORA0KICAg ICAgIjAwMTAiIHdoZW4gIjAwMSIsICAtLSBBTkRODQogICAgICAiMDExMCIgd2hlbiAiMDEw IiwgIC0tIFhPUg0KICAgICAgIjAxMTEiIHdoZW4gIjAxMSIsICAtLSBPUg0KICAgICAgIjEw MDAiIHdoZW4gIjEwMCIsICAtLSBOT1INCiAgICAgICIxMDAxIiB3aGVuICIxMDEiLCAgLS0g WE5PUg0KICAgICAgIjExMDEiIHdoZW4gIjExMCIsICAtLSBPUk4NCiAgICAgICIxMTEwIiB3 aGVuIG90aGVyczsgLS0gTkFORA0KDQogIExhYmVsX3JvcDJfMSA6IGZvciBpIGluIERpbl9B J3JhbmdlIGdlbmVyYXRlDQotLSAyIDogdGhlIFJPUDIgb3BlcmF0b3IgaXRzZWxmLg0KICAg IHBhcnRpYWxfcmVzdWx0KGkpIDw9DQogICAgICAgICAobG9jYWxfZnVuY3Rpb24oMCkgYW5k IChub3QgRGluX0EoaSkpIGFuZCAobm90IERpbl9CKGkpKSkNCiAgICAgIG9yIChsb2NhbF9m dW5jdGlvbigxKSBhbmQgKCAgICBEaW5fQShpKSkgYW5kIChub3QgRGluX0IoaSkpKQ0KICAg ICAgb3IgKGxvY2FsX2Z1bmN0aW9uKDIpIGFuZCAobm90IERpbl9BKGkpKSBhbmQgKCAgICBE aW5fQihpKSkpDQogICAgICBvciAobG9jYWxfZnVuY3Rpb24oMykgYW5kICggICAgRGluX0Eo aSkpIGFuZCAoICAgIERpbl9CKGkpKSk7DQoNCi0tIDMgOiBwYXJ0aWFsIE9ScyBhbmQgQU5E cyBvbiB0aGUgYnl0ZSBjaHVuY2tzIDoNCiAgICBCWVRFX0NPTUJJTkUgOiBpZiAoKGkgbW9k IDgpPTApIGdlbmVyYXRlDQogICAgICBwYXJ0aWFsX09SKGkrNyBkb3dudG8gaSkgPD0gIjEx MTExMTExIiB3aGVuDQogICAgICAgICgocGFydGlhbF9yZXN1bHQoaSAgKSBvciBwYXJ0aWFs X3Jlc3VsdChpKzEpIG9yDQogICAgICAgICAgcGFydGlhbF9yZXN1bHQoaSsyKSBvciBwYXJ0 aWFsX3Jlc3VsdChpKzMpIG9yDQogICAgICAgICAgcGFydGlhbF9yZXN1bHQoaSs0KSBvciBw YXJ0aWFsX3Jlc3VsdChpKzUpIG9yDQogICAgICAgICAgcGFydGlhbF9yZXN1bHQoaSs2KSBv ciBwYXJ0aWFsX3Jlc3VsdChpKzcpKT0nMScpDQogICAgICAgIGVsc2UgIjAwMDAwMDAwIjsN CiAgICAgIHBhcnRpYWxfQU5EKGkrNyBkb3dudG8gaSkgPD0gIjExMTExMTExIiB3aGVuDQog ICAgICAgICgocGFydGlhbF9yZXN1bHQoaSAgKSBhbmQgcGFydGlhbF9yZXN1bHQoaSsxKSBh bmQNCiAgICAgICAgICBwYXJ0aWFsX3Jlc3VsdChpKzIpIGFuZCBwYXJ0aWFsX3Jlc3VsdChp KzMpIGFuZA0KICAgICAgICAgIHBhcnRpYWxfcmVzdWx0KGkrNCkgYW5kIHBhcnRpYWxfcmVz dWx0KGkrNSkgYW5kDQogICAgICAgICAgcGFydGlhbF9yZXN1bHQoaSs2KSBhbmQgcGFydGlh bF9yZXN1bHQoaSs3KSk9JzEnKQ0KICAgICAgICBlbHNlICIwMDAwMDAwMCI7DQotLSBpJ20g c3RpbGwgdW5jZXJ0YWluIGFib3V0IHRoZSBiZXN0IHdheSB0byB3cml0ZSBhIG11bHRpLXNp emUgdmVyc2lvbi4NCiAgICBlbmQgZ2VuZXJhdGUgQllURV9DT01CSU5FOw0KICBlbmQgZ2Vu ZXJhdGUgTGFiZWxfcm9wMl8xOw0KDQotLSA0IDogZmluYWwgc2VsZWN0aW9uIHN0YWdlIDoN CiAgRG91dCA8PSBwYXJ0aWFsX09SICB3aGVuIChDb21iaW5lX09SICA9ICcxJykNCiAgICAg ZWxzZSBwYXJ0aWFsX0FORCB3aGVuIChDb21iaW5lX0FORCA9ICcxJykNCiAgICAgZWxzZSBw YXJ0aWFsX3Jlc3VsdDsNCg0KZW5kOw0K --------------FC7BE5A9181F5725D522EAD2-- From Michael Riepe Sun Oct 22 19:11:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00339 for ; Mon, 23 Oct 2000 22:49:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:50 +0200 (MEST) Received: (qmail 11393 invoked by uid 0); 22 Oct 2000 17:16:06 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net with SMTP; 22 Oct 2000 17:16:06 -0000 X-eGroups-Return: sentto-1101623-1249-972234963-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 22 Oct 2000 17:16:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 17:16:02 -0000 Received: (qmail 21689 invoked from network); 22 Oct 2000 17:16:02 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 22 Oct 2000 17:16:02 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.75) by mta3 with SMTP; 22 Oct 2000 17:15:54 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01485; Sun, 22 Oct 2000 19:11:51 +0200 Message-ID: <20001022191151.07140@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F254F6.26A6E4D7@f-cpu.org>; from Yann Guidon on Sun, Oct 22, 2000 at 03:46:14AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 19:11:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" X-UIDL: a791ea6df6e8132b96a4fc272db3d08b Status: R X-Status: N --0OAP2g/MAC+5xKAE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, Oct 22, 2000 at 03:46:14AM +0100, Yann Guidon wrote:

> no i haven't finished the Icache. i'm guilty and i repent.
> anyway, i have started to think about the ROP2 unit.

[NB: could you tell your mail software that VHDL is text/plain with
charset ISO-8859-1 or ASCII and not some random binary format it has to
encode for transmission?  Plain text is much easier to read (and comment)
than Base64 or Quoted-Unreadable...]

I think you got the opcode decoder wrong; see my corrected version.
I also simplified the coding (use vectors and slices as much as possible;
that speeds up simulation -- gotta do that in the IMUL unit, too).  And I
had to change F_RANGE to a subtype of natural to make Vanilla VHDL shut up
(I use that for quick syntax checking on Linux now -- it's not good enough
for simulation, but I don't have to edit my code under NT any longer ;).

I'm afraid the COMBINE mode is not a good idea.  It's true that the
datapath of ROP2 is short (3 gates deep, AFAICS), but 64-bit AND/OR gates
plus output mux are quite expensive (5 additional levels, or something
like that).  That might be too much for a single pipeline stage.

There's also some good news, however.  I'll attach some fallout from
my work on the IMUL unit: an 8-bit adder with a 5-gate datapath (which
leaves room for inverting one of the operands) and carry input/output
that uses only 2-input XORs and AND and OR gates with up to 4 inputs.
I think it's fast enough to be used in both the first stage of the
adder and the final stages of the multiplier (and maybe the divide
unit, too).

While playing with the adder I noticed that it could process two
additional instructions: (a+b)/2 -- `average' -- and the complementary
(a-b)/2, each of them with different rounding modes (floor/ceiling).
Both instructions are quite useful, but I didn't find them in the
current version of the manual.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Description: Whygee's ROP2 EU, slightly modified Content-Disposition: attachment; filename="ROP2.vhdl" -------------------------------------------------------------------------- -- ROP2.vhdl - ROP2 Execution Unit for the F-CPU -- Copyright (C) 2000 Yann GUIDON (whygee@f-cpu.org) -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- -------------------------------------------------------------------------- -- This is the first version ever for this unit. -- It should be easily synthetizable but there is no proof yet. -- What matters most today is that it compiles and behaves correctly. -- Warning : this code is and should remain purely combinatorial, -- there is no latching here, it must be done at another level. -- Furthermore, the function lookup table should be moved earlier -- in the pipeline, in parallel with the Xbar cycle. -- Finally, only byte combines are possible yet. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; LIBRARY work; USE work.FCPU_config.ALL; Entity EU_ROP2 is port( Din_A, Din_B : in F_VECTOR; -- the 2 operands ROP_function : in Std_ulogic_vector(2 downto 0); -- 3 function bits Combine_AND, Combine_OR : in Std_ulogic; -- additional funtion Combine_size : in Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. Dout : out F_VECTOR -- the result ); end EU_ROP2; Architecture arch1 of EU_ROP2 is signal partial_result, partial_OR, partial_AND : F_VECTOR; -- the partial results. signal local_function : Std_ulogic_vector(3 downto 0); -- the local, decoded, function bits. begin -- 1 : lookup table that decodes the function bits -- (should be done in an earlier stage) with ROP_function select local_function <= "0001" when "000", -- AND "0010" when "001", -- ANDN "0110" when "010", -- XOR "0111" when "011", -- OR "1000" when "100", -- NOR "1001" when "101", -- XNOR "1011" when "110", -- ORN "1110" when others; -- NAND -- 2 : the ROP2 operator itself. partial_result <= ((not Din_A) and (not Din_B) and (F_RANGE => local_function(3))) or ((not Din_A) and ( Din_B) and (F_RANGE => local_function(2))) or (( Din_A) and (not Din_B) and (F_RANGE => local_function(1))) or (( Din_A) and ( Din_B) and (F_RANGE => local_function(0))); -- 3 : partial ORs and ANDs on the byte chuncks : BYTE_COMBINE : for i in UMAX/8-1 downto 0 generate partial_OR(8*i+7 downto 8*i) <= "11111111" when partial_result(8*i+7 downto 8*i) /= "00000000" else "00000000"; partial_AND(8*i+7 downto 8*i) <= "11111111" when partial_result(8*i+7 downto 8*i) = "11111111" else "00000000"; -- i'm still uncertain about the best way to write a multi-size version. end generate BYTE_COMBINE; -- 4 : final selection stage : Dout <= partial_OR when (Combine_OR = '1') else partial_AND when (Combine_AND = '1') else partial_result; end; --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Description: slightly changed config package Content-Disposition: attachment; filename="F-CPU_config.vhdl" -- File F-CPU_config.vhdl -- (c) Yann GUIDON, oct. 21, 2000 -- whygee@f-cpu.org / f-cpu@egroups.com -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ constant MAXSIZE : natural := 8; -- Size of the registers in bytes, any power of two >= 4. constant UMAX : natural := MAXSIZE * 8; -- Size of the registers in bits. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- Range of a register width declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; -- shortcut for a very common declaration. ------------------------------------------------------ -- Some architectural constants, bound to FC0 only : ------------------------------------------------------ -- L1 Caches (split instructions and data) constant L1DBwidth : natural := 256 ; -- Data Bus width, or width of each cache line (32 bytes) constant L1ABwidth : natural := 32 ; -- Address Bus width, in 32-byte chuncks (32+5=128GB) constant L1LogLines : natural := 6 ; -- Log2 of the NumBer of cache Lines (MUST be EVEN) constant L1NBlines : natural := 64 ; -- NumBer of cache Lines (2**LogLines) (small number for the first attempts) ------------------------------------------------------ -- The Special Registers : -- (copied from SR.h) ------------------------------------------------------ constant SR_NUMBERS : natural := 0; constant SR_NUMBERS_val : natural := 10; -- 10 SRs are implemented in this model constant SR_FAMILY : natural := 1; constant SR_FAMILY_val : natural := 4032; -- F-CPU core number. remark : 0xFC0 = 4032 :-) constant SR_STEPPING : natural := 2; constant SR_STEPPING_val : natural := 1; -- revision/implementation constant SR_MAX_SIZE : natural := 3; constant SR_MAX_SIZE_val : natural := MAXSIZE; -- in bytes, a power of two >= 4 constant SR_SIZE_1 : natural := 4; constant SR_SIZE_1_val : natural := 1; -- Size attribute 1, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_2 : natural := 5; constant SR_SIZE_2_val : natural := 2; -- Size attribute 2, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_3 : natural := 6; constant SR_SIZE_3_val : natural := 4; -- Size attribute 3, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_4 : natural := 7; constant SR_SIZE_4_val : natural := 8; -- Size attribute 4, hardwired if SR_MAX_SIZE <= 8 constant SR_CYCLE : natural := 8; -- R/W, Value is dynamic, incremented every cycle. constant SR_PAGING : natural := 9; -- Protected, R/W, Controls the paged memory. end FCPU_config; package body FCPU_config is ------------------------------------------------------ -- Empty. Only the constants matter until today. -- Some useful wrappers or functions could be included -- here if they are necessary for the project. ------------------------------------------------------ end FCPU_config; --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Description: 8-bit adder Content-Disposition: attachment; filename="iadd8.vhdl" -- iadd8.vhdl -- F-CPU 8-Bit Adder -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: iadd8.vhdl,v 1.3 2000/10/22 12:15:34 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity IAdd8 is generic ( WIDTH : natural := 8 -- do not change! ); port ( -- summands A : in std_ulogic_vector(WIDTH-1 downto 0); B : in std_ulogic_vector(WIDTH-1 downto 0); -- carry input Cin : in std_ulogic; -- sum output Y : out std_ulogic_vector(WIDTH-1 downto 0); -- carry output Cout : out std_ulogic ); end IAdd8; architecture Arch_1 of IAdd8 is signal P, W, X, C1, C2 : std_ulogic_vector(WIDTH-1 downto 0); signal X_6_3 : std_ulogic; begin -- d=1 P <= A and B; X <= A xor B; -- d=2 X_6_3 <= '1' when X(6 downto 3) = "1111" else '0'; -- d=3 C1 <= ( 7 => P(6) or (X(6) and P(5)) or (X(6) and X(5) and P(4)) or (X(6) and X(5) and X(4) and P(3)), 6 => P(5) or (X(5) and P(4)) or (X(5) and X(4) and P(3)), 5 => P(4) or (X(4) and P(3)), 4 => P(3), 3 => P(2) or (X(2) and P(1)) or (X(2) and X(1) and P(0)) or (X(2) and X(1) and X(0) and Cin), 2 => P(1) or (X(1) and P(0)) or (X(1) and X(0) and Cin), 1 => P(0) or (X(0) and Cin), 0 => Cin ); -- d=4 W <= X xor C1; C2 <= ( 7 => X_6_3 and C1(3), 6 => X(5) and X(4) and X(3) and C1(3), 5 => X(4) and X(3) and C1(3), 4 => X(3) and C1(3), 3 downto 0 => '0' ); -- d=5 Y <= W xor C2; Cout <= P(7) or (X(7) and C1(7)) or (X(7) and X_6_3 and C1(3)); end Arch_1; --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Description: 8-bit adder testbench Content-Disposition: attachment; filename="ia8test.vhdl" -- ia8test.vhdl -- F-CPU 8-Bit Adder Testbench -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: ia8test.vhdl,v 1.2 2000/10/22 12:15:34 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use std.textio.all; use IEEE.std_logic_textio.all; entity IAdd8_test is end IAdd8_test; architecture Arch_1 of IAdd8_test is constant WIDTH : natural := 8; signal A, B, Y : std_ulogic_vector(WIDTH-1 downto 0); signal Cin, Cout : std_ulogic; begin mut : entity work.IAdd8 generic map (WIDTH => WIDTH) port map (A => A, B => B, Cin => Cin, Y => Y, Cout => Cout); process variable res, prod : natural; variable lout : line; begin for i in 0 to 2**WIDTH-1 loop A <= std_ulogic_vector(to_unsigned(i, A'length)); for j in 0 to 2**WIDTH-1 loop B <= std_ulogic_vector(to_unsigned(j, B'length)); for k in 0 to 1 loop if k = 1 then Cin <= '1'; else Cin <= '0'; end if; wait for 1 ns; res := to_integer(unsigned(Cout & Y)); prod := i + j + k; if (res /= prod) then write(lout, "WHOA THERE!!! "); write(lout, i); write(lout, " + "); write(lout, j); write(lout, " + "); write(lout, k); write(lout, " => "); write(lout, Cout & Y); write(lout, " /= "); write(lout, prod); writeline(output, lout); end if; end loop; end loop; end loop; wait; end process; end Arch_1; --0OAP2g/MAC+5xKAE-- From Michael Riepe Sun Oct 22 15:01:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00342 for ; Mon, 23 Oct 2000 22:49:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:49:53 +0200 (MEST) Received: (qmail 29087 invoked by uid 0); 22 Oct 2000 17:16:40 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 22 Oct 2000 17:16:40 -0000 X-eGroups-Return: sentto-1101623-1250-972234991-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 22 Oct 2000 17:16:36 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 17:16:30 -0000 Received: (qmail 89153 invoked from network); 22 Oct 2000 17:16:06 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 22 Oct 2000 17:16:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.75) by mta3 with SMTP; 22 Oct 2000 17:16:04 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00719; Sun, 22 Oct 2000 15:01:10 +0200 Message-ID: <20001022150110.44698@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F24A7C.10435967@f-cpu.org>; from Yann Guidon on Sun, Oct 22, 2000 at 03:01:32AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 15:01:10 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] test, comments and question Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6356a8e175ed0f8150225cba55399fce Status: R X-Status: N On Sun, Oct 22, 2000 at 03:01:32AM +0100, Yann Guidon wrote:
[...]
> French people need others to show them the way, before they
> even intend to act a bit.

Just like most people all over the world, I guess.

[...]
> but that was a problem on the german mailing list, when they wanted
> to constitute a Verein. The rules are more strict than in France
> and they couldn't easily find 7 people located next to each others
> to fill in the administrative papers. They also have had the same
> problem as the french association for the legal stuffs because
> there are no lawyers/specialists.

I still wonder what the `FreeCPU-Verein' (or its french counterpart)
will be good for.  Collect money for the prototype and tools that are
not freely available?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Sun Oct 22 23:51:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00360 for ; Mon, 23 Oct 2000 22:50:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:03 +0200 (MEST) Received: (qmail 10484 invoked by uid 0); 22 Oct 2000 20:46:34 -0000 Received: from ej.egroups.com (64.209.169.103) by mx0.gmx.net with SMTP; 22 Oct 2000 20:46:34 -0000 X-eGroups-Return: sentto-1101623-1251-972247591-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 22 Oct 2000 20:46:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 20:46:30 -0000 Received: (qmail 23420 invoked from network); 22 Oct 2000 20:46:29 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 22 Oct 2000 20:46:29 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 22 Oct 2000 20:46:29 -0000 Received: from f-cpu.org (nas2-237.ras.club-internet.fr [195.36.192.237]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA01592 for ; Sun, 22 Oct 2000 22:46:21 +0200 (MET DST) Message-ID: <39F36146.D2217317@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Oct 2000 22:51:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) ROP2 : distribution Content-Type: multipart/mixed; boundary="------------9116C171D9C97690A59F2F0D" X-UIDL: c8f35568a0540d278b204ee4cd35e37e Status: R X-Status: N --------------9116C171D9C97690A59F2F0D Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

here is a first package for you to test.
i have used Simili under DOS (see the batch file)
to check the functionality of the basic unit.
It complies with the definition found in the f-cpu manual.
The COMBINE functions have not been tested yet.

The ZIP file contains interesting stuffs, you better
read all the files before you compile. </usual warning>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------9116C171D9C97690A59F2F0D Content-Type: application/x-zip-compressed; name="rop2.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="rop2.zip" UEsDBBQAAgAIAOSqVimOQOCm5woAADkgAAAhAAAAdmhkbC9ST1AyL3Rlc3RiZW5jaF90ZW1w bGF0ZS52aGRsrVnrcxo5Ev+eqvwPHVIVwx7Bjzx2F8LWEhsnVBHbh+G8+USJGQE6DzPcSGPM /fXX3dK8PGN7s7f+kHjUrVa/+yf57BLmF5fTOZxefrsajYcwuIbRdefli5cv3v5tPyQLjNRm IUNvPTdysw2EkZ27tR9AF9JvWEYxmLWE87enVzPYxtG/pWd482m03cdqtTbQPG3BydHREXwX YQhfZqOzywto7tb7lZS/L99626QTxasWHB8dnpwcEufvJ0drFsL/nEUQRga8aLNVgcTjlIYl /taBkQH8PQqDPYhMpw5vulnLWN7JGEIpfem3IZZI9SRrG0hjZKxhOIOdMmteG95LLzEqCmEW KnOgIRQbJ2uankinCV9sjfRhGUcb3siEkSe8tZxnHmNH8e5cAnpnFYsNCVnGUoKOlmYnYtmD fZSAJ0LU0VfaxGqRoGuVARH6h+jgTeSr5Z4F4WIS+tI6HW3YoPlL/vhyMYMvMpSxCOAqWQTK g7HyZKglCDybVvQa9V5YQRw00uLaaQHnEUoW5IEeSPQKHoL+0+SRk/QQJ7ENUcxSmsKQ8jFE W9rYQo33QEHI9j7ug9xUH1TI4tfRlgKEQtHOnQoCWEhItFwmQZtlIDfcjKZfL2dTGFx8h5vB ZDK4mH7vcRwjpGLMrSyF2aBQNNoWi9Ds0QQW8W04Of2KewafR+PR9DtaAuej6cXw+hrOLycw gKvBZDo6nY0HE7iaTa4ur4cdgGvJmcMSnvD0kqOFzvSlESrQufXfMcQaNQx8WIs7iaH2pLpD /QQm9nb/fBRZigiicJXmbO7OHqgl1UgbdrHC1DFRNb68P49xG0ah12nDx58/wDehNQzuMKyn YrOIlb/CX78N4Ojk+N2vbZhdDzI7/tb+whlBJRWCMFS+hjTfiFtMWYgFp+CKnIFeKHccLDMV rlhIuW41N4VYCp/FqnCLOUEV2oatiLXEVdCUGlh++9CIe1cMmHK+1B7mI7LY2tIGc9gzUazb VIiA2YXCLDWWOgkMdh7+wn1S2kyn06mSMW+9RJtoozTF2GZzm7mtUGwwVoGMfS3CFfJKoVWw 7/y9zn75Yjz6PBlMvoOSUvZevgD8mV0P+bOjjT8PopXy5sfHH993BuPx4xxG3qOzOyIIHvKE yYYiNUdeR07PxJUCM9GdlPJJuyi+7ZzjHJl7UbhUK0e2fS/0gsTHDoFdnebPmkrMC0TMyZxW DwUNXYiRVKsQG6UynQfihzNLzGS/fCFDo7A9DGd598akpH1fhhfDyei0aWVQFtFMwOOpcWEd dvvQoD0uTTrm3jQAlWUup5Kl8WYS0+rRgX7pNNZDxN4aS9czSeySDwVUdHJzNRVubcFU2kax KTqkzWUi7wVnepdOJk5sKr5Coo+53IaB72Me67ntGV24xiAnNspW62arV9iJvBJ3ecFtGyZY YPMhSrqhvfgbbv8cRYEUYbe/FIGWeeBwGNB2D1sPzQWrzBo7kg93IlZigRp6e4/0RM+h/cjc 7R/16vgCavFdCFQogU8AaoGe9MlrWwyKcaFbyJUKbdxuJqPpsEk7242f3EmvUUij1aswMJXW UXMrDjPZ1jg7QbsEtEcDtV30R9/ECY8Hd2L5TPxEnuw0ir5a9rL97NZnJTDXozJcOJ6V4vi6 mSCArwWWNCGofT52VBrwZ89KGZ87jLMvZylJOVNh/5HtSHqwaTy6GDYRGFzNpm1OlMdMGIV3 f8YAy/YjviqLwKnheDZC3z4nB2fwba3CT9mGjGmdnWO9C/CTzcIOupgw1b++no3rC47G6RxH DtYjnOJ/wuPa7MPFbNwDamIsxaexZIl1UhbJcunKsWdNo51cnQyPd2uFjWsnrbDagkbeOU6O BZ2elv9j1a9ylkrxr6ThHkkKNCgozVYD+xxOc7o7MORqJKEjdDqdB00i80e3T0Y1VRoL1e2r fxyXvM1GIqQKaQa8evUKT4AI4e4yiHboL+ndalomxmUSejygUL35GvtxU3crbbaF1Y1GhdUG 7JoZFOJW3d58h3buQkROR61uvxkRbNL93w6ODlIbst1JzW59sMZb2tMiCo4iIxAKRFuMBYaX ovKJXWbFECVNcw5JlvSe0MW0Sy2jnx0WIeBh0P8NDez/0Thq9B5Sj3PqcZV6klNPqtR3OfVd lfo+p76vUj/k1A9V6sec+rFK/Tmn/lyl/pJTf6lSf82pv1apg5w6qFI/59TPVeppTj2tUs9y 6lmVOsypwyr1PKeeV6niSZ0XT+rsPamz/6TO8kmdl0/pbAuBGKgNvD3upZWaZJzUqym1LWbQ a7U0EEj8p5tyJM2kVGLvscSSpltsvX2fl14v31KqaVOYC1Rg9ix5j9cdi0f4BQQn2/BynJ5b UjTtXK6OcYluKqE2eDFWdKkqgGdPxV6iDPIg+lTM4xE0K8Dk/ZZ7uUWdG7F1AJnGNfmKIGa6 QniNlmjUuTUEQ7REONKtMLihNQsx3WoZniK1tJByOUhD9BSUOkoGTZGU/s6kVi91QWq2Bdgx KkmjizzIg0XbHsUPPMSWduUuTId/TOHyangBk+HgbP7t8mwIo+vsimDjVR621jb+NUPP/FWA 0AsLoWm7CxUjaGUOrYuahOq1/E9CwSBMbWOlW3weuv9TXf/nvZ8Y79iFnVCGLwjHRxDqElOK 3eu47AsM6eUQ8SYJ7PVrEfl7l3h2JjRp6GLWkUOaBde1WsUJ4YxjN9irus7KJvdZ8UKRbqM5 jlmfXa9yyJG9yHWz5BI+kYtqtGlgZeVWwCDdfuHDjX0yikKUXiF++oluWpFP05/PfZ1DuwJj QVCZzMrYx4R2CuUcfbRkSHWAWbQy68P+kcOnueEEpOjgBvE1bPU7NAMOrpDWjLd4TGdt6Llp XRnY9TO7QE1baI9bKD9OHmh+z9psMEFLnMDtCnK9erWi/kmiHmws+HR8/oaQ+evXr2FILzLL 4vWaljuNN+PzVq9OQp3by1yY7/VaTWu0wm6bp2j1LlGnfePGYcYuYOUYRVfzCdc1VpQz5FXj zefhuKKbDCx8Lv0USyQv7sKm9BpRY9LNEyY9fsX7s1axBP0XzSq1+U/9DDk/cmHM1bdInRLR i+IYD7bvwKEv7+n5Xxt6mKWl7E5jH/7WQmNbQ6+IgJrFHhoSZ2LYqJ6wzIvhsH/QPah3DvUc Ho0Neb9FNXCoEu9Cmh2fYu2AN+ALI9p8P1nSu2yjalPpJlj44VafeaZ0Fy6nR3YL/+EMmdRn SJPF0svyf7Mcaf3F1KdH2v8vRyheNSlSvpSXPZK+gfyoQzIs+Fx7eg1JeBsieuNGSC/Hhbem um1ZTrneVeAsoMs/080cLqSks31YHGq5pTfBKD4sgMMsmIhpf7Pz4CuBUY6jHTS+/aObE0ai aENaIYKnOzVgUqRkWrXPP5HNlYmTZRgPnD4Nl5rs+qEzyiIPUWa7TmYxW5ED0tptwwr98DCA deF7nKUBBKTRc7VinpxM1YxMbwE1DnDMFL+7SPnunbqEH2SMkM7CJKH5UZMRXLcIxRErZqOl V8bZjuS+eg+gtqOmnyXI5p5480uAQ6SQPxzFirGN9FdpSvGmbp//o97ObMK/4zsJt3L7qpzi qzJkdc9R0g4CB5Yps+mT/hxQVMaCzFwZ/A4eaPOIeHpb0tEGFVIb/tsb1oiXwh9+Re4VK59B NA6d7XbPPIVbXXbdmHtBpMvIOSUzTCEhOM+2D4A4MpA0d3np2b9u+Hx3wY//AVBLAwQUAAIA CACjs1YpEVtPSb8AAACEAQAAGQAAAHZoZGwvUk9QMi9ST1AydmVjdG9ycy50eHRVj8sKgzAQ RfeC/zAfYOncPqG72OIyfVFwa61QQU0RXfTvOxpHaOCSk3CY3BhmIIoZjCjhMEggWUnWko1k K9lJ9mFwDQOB1tXUvQtKFsfLg+qs6bOKDmFA7pO7V0FtIeeRkr7Ju9I1dP/WT1eVOTVZXYhJ zEzjEoBshow9UTzcCHgDaoBnYxl7w44KdAgmJT3f/BCBwQAwG/4ZFWgStAd8I0NWDasGZsOP SFVJVdEeAM+vjE0F7F8PaFOr/x3gB1BLAwQUAAIACAAss1YpnPCk628CAAAeCAAAHQAAAHZo ZGwvUk9QMi9ST1AydmVjdG9ycy5vdXQudHh0rZXva+IwGMdfK/g/PNCDqexq0nb+KHjgZmUH 7jbmIQwKUtuo4dqkJK07//tLNh3WVtgx86JN+32+Tz5P2zyd7ZJ0w9kOvPEIms8tmN+Pp3DH k5TGRHRmNMnjIOMCHniUxwTmmyj2rmFOhKScATada7jNaRwZtmU26nc83Qm63mTNuxbMjnPj waD33UIImTCKY3gLkiCIJGJLImV9JkFE2Roi19+qRXxJExpTf0mZL/eJTMoomKYKntKlCMQO righ5KpWGw5/wLfZy8PT/eOvl45SOz+V8HYwlfvI8MrFn71BT9/Vw9oft3zBU2uREZktCQs3 J5fmNhBVJpIvdODhfC5sFab5IuRsRdfH8+aSR7vWiemjKF9V4Ot6/ENRvsyiRczXNFxg3HVO Lv87G8sTIpRZpTmef4EqI38zyks3KjN+7sE39az1ycffDES4wfvomgF8BTO6ZkEs4X0MoYsG B0l/8pwRlsl3CR+EJ8FDIiWRe0/fOShjQbdqH3xkswdWoz4mUi0CUx5EHS8OllwEmd4pap5K EsFvmhAXENq4CCUusqWLunYiG/V2uw0RCflbUTFlBAzF0IZwF6p9Z4ALWK3y/PhkwSpnoU7q okYdxpQtRkNUGBjvhduigJEWYMzz7MShhQoCq0hglQjwxQgwqiSwiwR2icC6FAE+Q+AUCZwS gX05guq3cFMkuCkROF8gmBwPz/MqCbpFgm6J4OZyBJNKgl6RoFci6F6KYHKGoF8k6JcIehcj mFS/BdWstAEMwwCPRboHbUmo/84rqqkMw9QR+5+27joy42mquk6QKWAETBbUMz0JqZ7kWLon /QNQSwMEFAACAAgACrNWKVm4wOYsBgAAIBAAABMAAAB2aGRsL1JPUDIvUk9QMi52aGRsrVfv b9s2EP0eIP/DIV9io44XOWm6xQswxXVaA4kd+MfafDJoibaJyqJAUvHcv36PpGzJbrIMW40C lai7x3f37o7M2dnP+h0fnZ3RcPDYaj4v44T8M3X/4lFuhExpkgpDc6nILDndnXUeJ86jI7ON EouloVqnTq3z83N6YmlKnya9j4M+1dbLzYLzP+ZnUZY3pVrUrZfzHC+FpkzJhWIrwuNccU5a zs2aKd6mjcwpYikpHgttlJjlhhMosDT+BSxWMhbzjQPCYp7G3DMzXK00ybl7+dSf0CeecsUS esxniYjoXkQ81ZwY9rYresljmnkgF5llMSpY0J0EMrPxt4kLfFf0zJW2+WhtNykQGySVQ6kx Y8krkpl1rIPxhhJmSt/mqzkoQ41JpA5+KTNEtQQo4lyLJKEZp1zzeZ40HAas6Utv/HkwGVPY f6Iv4XAY9sdPbVibpcRX/sw9llhliQA0YlMsNRuE4CAeusPOZ/iEt7373vgJkdBdb9zvjkZ0 NxhSSI/hcNzrTO7DIT1Oho+DUbdJNOKWGHcI/5DpuVMLyYy5YSLRZfRPkFiDYRLTkj1zSB1x 8Qx+jCKU1dsqOhSWyHThYoV1mc42iTml0jRorQRKx8gf9XX+pcYN6qVRs0FXH97TA9OawmfI 2mGrmRLxAo8PIZ23govfGjQZhbs4fmoHuorAP8t1LpQ2u4KDiqpoQHzP0Y6OAfXMNokoDM60 SDakNykAjPjOZgl3FWJrl1vgVNoMIbUbXgB8scW1YgYVqqEUtjQyZhvPwtddJFeZSLi23Ydt rFoaiwqKmWRTwDCVCihx7QlGMnb7WY+Cn+IrhqrOcsXBEZgzkTIjlWBFKVdJomOipcWzaw1L YpWDGmKMZYr+tZNAuo5MkJnEc7jLlV2y5dbwKczTyI2vRMpveUbGJaTM10raeuNMoS98+xZt l4mMJyK1O4MxQ+0lPNlWGaevM6Yo2kQJLzZGJEmywRBIEdpsg4Lz8dmcIaZMai3s1tus/7yi OT66790Ow+ETCc55+/iI8JuMuu61qU08TeRCRNMguLpshvf3hxZpvuIK32HZRAztEm8t1beK tX1t3mHwTyOZzsWiADs+6qZGYJh0J1N3ZghtfTKpTM07fxTpNGy4/24J9YGM3k3/7HbGg2Hb fqdi9mKkZujyNNbeD2jTnYDeb4Rwch/PM2pPqloL9bBO0d3n9bZDuihFnwlTQHW8GNOw/7Gx e8FoOwD1dGhLisWxsEAYPMC0T/toWnznr/EK9nhZtDzF2I4pHD806dZVyBJEv2lXM80iVXZe b3/XZN+2qapmSnGdJ8a61KEAR4sVyXd6hAqdY0ADjYbqi5aBHaX78mixsGGhsg3ab+oBG7v3 wbB8Rs5ApaJYQaL4XpDRzQpsIiM47nS4fiE/F4e6WUjn18BJYadH3NhXEhvM+EKkNkTYB4Dd 62o3rLyr3m9+XwfwKX61cgC4YQIBcdMopgBpwxa8bqNx7b5XhZonoO+1Ogjy9xu/THSCW1Bw Qusljl37fNJwASKPFYvgvLQISot+aRJUTIItyNfBsGpRbhNsQSoGgd28MAh2PPr7FkFpsYX4 umcSVEx2PAbDfsVix9RNZN1227h4rdE9m3GUmMxaUyuaPcOEzbmbC6do+AWnhTvgjT+SW+4Q 4f4K6maCsT4G2Z8XjbJfuDVRr+TfKrwvTu287g6i2m4cweNg6dYu1bcY2O8QI3gdAyfRv8No HTj8Fx4Xr2Ps82gXnXKBdG6bdTD0RzLEsYPHpXlWHUbXfufbp3F32hk83Pb6XTvi5lSrCXvr pl/rN8hmqZfnWQ6Omnj3YdvbThZXIO7ni6SUqVY7lBEDzYZ8uPwuqLvrdTmdf7Bovex48abj 5cuO7990vHrZ8UO9fnManNZLX57gGmwHgfudtA9zBi3+d9Kspi9lDetvpe1F14u3XS9fcX3/ tuvVK67/Jnf2jna6wpS2fwuhZrky9lbJZtJfczHVcU9c4wKLXPq7P8PdMTHizJ3X5R9hDh80 trW8V/ROpb2v1TG2ba1LO8/s3a84GdwZYc8P30fuOIeYZXeQn5O1yh2EbqgSswu4evTu29uV 1+19Ih05UEcIfwNQSwMEFAACAAgAMrJWKeFvVIXCCQAAYBwAAB0AAAB2aGRsL1JPUDIvUk9Q Ml90ZXN0YmVuY2gudmhkbK1Z7XPaOBP/3pn+D1syc4U+hBDSlys+OmcItMzQkIfA9fKJEbaM dTU245dQ7q+/XUl+w04y0ykfStCuftqVdn+7Us/Pf9Xn5Yvzc1jMb3vrmEfxhvuW23lwbQ/6 cvR1BDguh8EJQohdDpPz0e0K9mHwD7diOX8U7I+h2LoxNEct6HW7Xbhnvg+fV9Pr+Q00D+5x y/mfzrm1TzpBuG3BZfei17sgzT97XVeCyH+WrojAER4H/GY228fcBicMdnJlKcjsRIt3e4/F XBrcofk5Bpq3DdmOYJyQc4gCJz6wkBtwDBKwmA8ht0UUh2KTxLhaDMy3L9DDXWAL5yiBcDDx ba68jnm4iyBw5I/PNyv4zH0eMg9uk40nLJgJi/sRB4Zr00jkouUbBSR3jay401bAJEBkFovA N4ALlIfwwMMIf0MvXUQjtiEIJUqTxWR8CMGeJrbQ4iOQ/9ncx/cgd9UG4Ut4N9ijVy6Cop8H 4Xmw4ZBE3Em8tsRAbfg2XX6Zr5Zg3tzDN3OxMG+W9wZqx26AUv7AFZbAgxAIjb6FzI+P6IKE +DpejL7gHHM4nU2X9+gJTKbLm/HdHUzmCzDh1lwsp6PVzFzA7WpxO78bdwDuOBnGJcITO+3I 08LNtHnMhBfl3t/jEUdooWeDyx44HrXFxQPax8DCUH3+FCUK8wJ/K31F7Xw7DRAO+EHchkMo MHTioHq+cn5+xm2Y+lanDe8/vIOvLIrAfMBjHbHdJhT2Fv/8akK3d3n1sQ2rOzPz45fm+Nz3 jnCF/u92GOmYXLhxMrqjOAhsOPIYU97sQ4R/kD9oOVtjqJgYB5EKiGFVOpRSmOQSZA1wEt+K 03jEWOS07Eb4PJNElG5SP8R0lsbglkorKL+53fm1G/DyxWw6XJiLexCcc+PlC8DP6m4sf3ai 2F57wVZY68vL92875mz2uEbMf6ADHeZ5pzp+suMhaqCuFqdr4khBmeQapbzSIQi/dyZIrmsr 8B2x1eKMQmxueSyUEZWGsM0jsfXxIHOuwu3rnGCOV2sic4nF/VhggpYpHymCpnwe34wX01FT TSe29dmOY1wQeWAu9AfQoIkPSPxBGHXiH3ED0DippS1SMjmZYFoGLWmfrCctYaHlYgJZcRIq VieIGrt0gSm7jIVpH4RxaU/6tCAJMZ+vhb822/JrCOjBZP3XeLScLwyo/+gtRvLdIx9gghSw 0KZ1GriEdYfBkKhoUN42r8AODj4yQbdlSKyrLNJhI+Ii2Ehlwtq8uW5nP5ALi7BG2TBm24Kg cDai0l81eJH4l9fadlmyjfASH2neBnP5tQPDI1KY5aKx37G6IUd0iptIJJ9+nt/DdBMxpRMv 1oErfCxQBGYhHVKtUqfkYsrb8MBCwTZY1K2j5ZH5PsNoQOX+oGvU6XlkUR884hIZREC0bHGb YmiPQRrrUN7wrfBVHH9bTJfjJs1sN97olc4QpNEyKgpSSuNouYLDTJZOqS2JAEs1Vz6UkfEn xW527v0M/ktBrRhKepkqTiFEFIrSKuIUVJ6FmS+eQ5kvSlsxm96Mm1j1b1fLttzxmo1qqAwb 1HopRT8JOXwccvgTkDKGH4E8nfMIItJXysITZDYGdrLbwJ6FEUYz1sC/vlzP6qOaGtS1hYMY bSP8YpZMgAHcrGaKJySKDVYqrEPZJI6jY97IE02mgOyMD65ApjxwBVabNXTIWJ42tHqaY4+l mMhVlI0C68oPcpQMOc25LY8lTZNiI+TMbrYaSDg8kvVcdl+NxNeCTqdzkpvZDvUHhN4U6YGI /kD877K0/9IY7K58KkWvXr3CFSDAztfxggPuICcGw2FSzMgXzVu7/AdrRv0KM7aQqNBNv8qZ mkOgcJL9J0m/P2gG1MRHg0+vu69TH7LZSc3s6LWLN6anIQobRU5gBxLs8XTwwOmc/pBbpmBI ohRBHYmR/rJYVAzE1DP6HFxs33ExGHxCBwd/N7oN41R6mUsvq9JeLu1VpVe59KoqfZtL31al 73Lpu6r0fS59X5V+yKUfqtLfc+nvVenHXPqxKjVzqVmVDnPpsCod5dJRVXqdS6+r0nEuHVel k1w6qUrZkzZvnrTZetJm+0mb+ZM2O0/ZrBKBFIgGzi+NNFOTTJN6SgptVdciVzgxeBz/6aca STMppdhbTLGkqQdb528LbVE+pZTTsRbQWpRgai3+Axs61QZQv0S3wfF8lq5bMjRlLp3HOITz p34U4x1ZsJjrhwW674AlQisR2DWpFlhILYt6It2x6yZeLiNb3x3b605d1WLaL9X2FkaH6egw HS11sygs/m72cv9T/UKrQerF/vVEA7vYgsJ8cSqXLWpBg35ntlJjR6bitxxqGemGpZukbgQh KlDpo/2WZShSjJa9DaUc3ofl+O8lzG/HN7AYm9frr/PrMUzvsntN2hKVy7XZll/DQr9bpeaa eZPa5rtXjKdGt6sYVscDBa7YJZ66vWwC+6ijSBF8kyoohhDZ2yx41moV6R5BqLpiLGZ3r7w1 yB7N0qwgVRIX8dpURrIkKPQK/UHhhy7GZB09e6T99Js3dAULbKrJct2zrNcqKhaAymJpDGrs SUm3XFo+deTlYcvDpix0eGrb2G1dDLrklw8qOlzueW1sWuzAfx2nLxr0uHBwj3AndsIT9Pqw 9ximlKIXoWaGfIftg3q/0uu0iFMwvLZ4McJ4ZMQpOCBfyPAiTU3NoZMZqPs3cr1BFjYUK+gu B3QbQ/smOzNZvjN6eq6KVwp5fS0vSFNqNSS1yvdLvCUz+eSDHFLSBEljkNtl1EL9n6BOJhZO dTb5jS4aZ2dnMMYdxwt64fZPw53Gb7NJy6hDqDv4shYT8alVhQawT+0fNq70xuZbR90Admqc MNP9oCcqSZAnK8mxPwZZr5hdX2rAhqdgwxqw4QnY8BGwSRFM5qrm4RPMIkUXoE8vk9UVskL6 3BmeYeZ8x+D20wfC4v24bloWhT93wIXyDaDL6h5jR4Uru4j4nl51gvCiUFtVRjnQxJbgk0qb L1TLFR3I6LADee/QYARFE5hHvHekfOYqTsm4ktHVdCjZKhzjqcQko/K8HFAOKqt+fo0y5AVi tuswi2SMGtpzbrdhi/tweoR1B/i4SgOoC8Gdq4V59nylP9lY2kTVbIBWpvN7CIStXxtLNIu3 vCBU9YxF8ikmffFTrxonKaIqcvbmkSalquzlYVMPm0ZxQf0epQfkr/5AfmEdTF/lHmSDFsvn bfm2lRY2ZC75vxOXXfAjre7pFNd9HkUq/aSyoqfJ9ybj5D1tw/ESvd8fpU6hEc16nrXlBVG5 P0jFkkElvcS47+oRK203UIHQdAelX4Zt2UDhsfwHUEsDBBQAAgAIAJe0Vilyrg+U4wAAAFAB AAAWAAAAdmhkbC9ST1AyL3Rlc3RST1AyLmJhdF2PzWrDMBCE74G8w5BTAonj+gFKoVAwNCT0 5xxkaS2JKpKR1nbz9pUdSEtvs7Oz7DeRLmBK/HY8VUUjGGu5wWiumuip3cmuL0LUWzyU+6ra V2VZLhcxn3wYm5Dj0qC1jtAnShAe1icWzpHCe32oX2somzjapmcbfLFcDEa5Di+759PnWQbf Wl1MFub3d3WeiBry0sze7YwQQ/dn9XjHDj0X/M03sroFDRSvbKzXyJThC2vrpevVZLAhrJTw 2uVphVFEn8Vmi86RSAQZLp2INOd4DHO7hP+vclU1kw4kOcT0i/ADUEsDBBQAAgAIAC8yVimD PbdVZAQAAL8MAAAbAAAAdmhkbC9ST1AyL0YtQ1BVX2NvbmZpZy52aGRsrVZdb+pGEH2PlP8w uk8hBQcbkqZxU10gJIpECIKQNn1By3rB29hea3cd6v76zq5xwoep1OT6CeTZc45nZs9MowG3 PGJw2+iNpjMqkgVfOm9hEB0fNRpwQmvwQpIE7qb3N4/DOgiqHfDcOnjNZtOGrMJ8ydj3RYOm mSPkEs7A/v7OllJkqXKoiE2gDX4KuYKU0FeyZBCwBU+YAh0y+EZDIgnVTHKlOYUVD3SovoFY 2HMmhCf4NiERZAnXyoFRxIhiIJlKGdU2BH9ryanmIlHO8dHx0eC+O+6MX4AzxvzjI8BnOunb v47SwSwSS05nrnvRdjqDgW+OlOpuP/IBXJk3jU89Vv+DUBp4nAqpSaKLZAOCK/NXwdXnwc1H lUDw0Pljcv9nH64gITqTmKura7j0Yf2gkAn/h2FS19laYrKZVJhamOeaqTqQJIdUrJi0QSsB v11D29kimSLLNkNJe2q4/pPEFM6A6TzFDM/GneEdVkOBJAmm3CA3XAjEKtECmmDBxvYVopF3 rKI7sH9ohE1jqm1BVTZf4z73e0+PYwNsipwVVX7DLhHyZM1aK9BViCWhmYaFkMjwxmSOXxrH ItmB/1L5JyJmQCQNuUYRNm3vxa/DXGRJAPjFt70miCTKv9YPyDdwoUdoiHfrRKURx9ZDMpkV FwNrHEBANKltlXXg3nSLvG4X1zu/KFJ1g0egm6ki+2gFZR2wNgzZgBpKiPBOw0nLKzpql6NT yYHRBUcnCPAOq00abJuW1zBgQMMsoa/KoP90fu16l3fdXfyBWA6sqWzhX8AaH197ZWcOs7hb 9HkhvDh38jCdPMGcQf+5P9xFH3YjG7SD3l6jH0D0Tk9LWTUsSEyiCJIsnmOo6TqjZcElGgTR msWpNkn7YsM9IeYEbZGjwvH7Dbxae7pIOQtgIUUMk7ET1n6Q+0zGs+H0odsfTwq72UpS0z8Q O3vDgO1Yt+m/G5bbxFjsWcmMf0YsZjgGAtMV2sySWAQs2tdx23m4H7xAhQ7Xr44tZGzHtpst zy+FlJ6NQoriOehHMZGveKb5t7m6xQG4atT2BU2e+qPR/fBuX5DnH4q1knbEfzi5ZG9c4X0+ e0+Ltap9ajTVmbXnPeqWfyh2n3rt8bbPN8bF/rCo+HYD6FYVo+1Xx1YVY/Pb7YDB2yL5PENf wHUEt4dgxaXpjMXWR/+KA/CAJK9K0nm1JK9KkndYkvc5Sa0qSRfVklqVLXtYUutzktpVkn6u ltSuknR5WFL7f0vqvfQGfaiStEkzPvu9Ds8kypjZAYI8ITGnZpRQWRoIK0Z9TiPm7NOMOnfl Zd2h+WWDZiSFmecsqBeMPZFoKaJio01xiQwgZrGQuWVgOHY3lkq/MPly3ZyLIP+xO2cfR0nu wKNZKIygj3UzNoNG4h6teYR7R0CMwHJNyRRbZBGsJElTMzRwQi1w7BarAxVZFJjpiKmMsoAF 9lzIjDvbqZpbp04YxSlOMMHlgEul+AtT5Xxl1FQl8F9QSwECFAAUAAIACADkqlYpjkDgpucK AAA5IAAAIQAAAAAAAAABACAAtoEAAAAAdmhkbC9ST1AyL3Rlc3RiZW5jaF90ZW1wbGF0ZS52 aGRsUEsBAhQAFAACAAgAo7NWKRFbT0m/AAAAhAEAABkAAAAAAAAAAQAgALaBJgsAAHZoZGwv Uk9QMi9ST1AydmVjdG9ycy50eHRQSwECFAAUAAIACAAss1YpnPCk628CAAAeCAAAHQAAAAAA AAABACAAtoEcDAAAdmhkbC9ST1AyL1JPUDJ2ZWN0b3JzLm91dC50eHRQSwECFAAUAAIACAAK s1YpWbjA5iwGAAAgEAAAEwAAAAAAAAABACAAtoHGDgAAdmhkbC9ST1AyL1JPUDIudmhkbFBL AQIUABQAAgAIADKyVinhb1SFwgkAAGAcAAAdAAAAAAAAAAEAIAC2gSMVAAB2aGRsL1JPUDIv Uk9QMl90ZXN0YmVuY2gudmhkbFBLAQIUABQAAgAIAJe0Vilyrg+U4wAAAFABAAAWAAAAAAAA AAEAIAD/gSAfAAB2aGRsL1JPUDIvdGVzdFJPUDIuYmF0UEsBAhQAFAACAAgALzJWKYM9t1Vk BAAAvwwAABsAAAAAAAAAAQAgALaBNyAAAHZoZGwvUk9QMi9GLUNQVV9jb25maWcudmhkbFBL BQYAAAAABwAHAPoBAADUJAAAAAA= --------------9116C171D9C97690A59F2F0D-- From Yann Guidon Mon Oct 23 01:02:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00369 for ; Mon, 23 Oct 2000 22:50:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:08 +0200 (MEST) Received: (qmail 2800 invoked by uid 0); 22 Oct 2000 21:58:24 -0000 Received: from fh.egroups.com (208.50.144.71) by mx12.rz2.gmx.net with SMTP; 22 Oct 2000 21:58:24 -0000 X-eGroups-Return: sentto-1101623-1252-972251901-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 22 Oct 2000 21:58:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 21:58:19 -0000 Received: (qmail 22395 invoked from network); 22 Oct 2000 21:58:19 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 22 Oct 2000 21:58:19 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 22 Oct 2000 21:58:19 -0000 Received: from f-cpu.org (nas3-19.ras.club-internet.fr [195.36.203.19]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA24716 for ; Sun, 22 Oct 2000 23:58:15 +0200 (MET DST) Message-ID: <39F37220.F6D39EFC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 00:02:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db97b48e7fa7f2a7bd0a4f67870ff0b2 Status: R X-Status: N hi again !

Michael Riepe wrote:
> On Sun, Oct 22, 2000 at 03:46:14AM +0100, Yann Guidon wrote:
> > no i haven't finished the Icache. i'm guilty and i repent.
> > anyway, i have started to think about the ROP2 unit.
> [NB: could you tell your mail software that VHDL is text/plain with
> charset ISO-8859-1 or ASCII and not some random binary format it has to
> encode for transmission?  Plain text is much easier to read (and comment)
> than Base64 or Quoted-Unreadable...]

glups ...
VHDL and VHD are associated to the wordpad.
i don't know how to configure that part of Netscape
(it's running under W95). If i compress the file
(zip or tgz) it should take less room, though.

> I think you got the opcode decoder wrong; see my corrected version.
"opcode decoder" ? i don't see where. Is it the lookup table in front
of the ROP2 unit ?

> I also simplified the coding (use vectors and slices as much as possible;
> that speeds up simulation -- gotta do that in the IMUL unit, too).  And I
> had to change F_RANGE to a subtype of natural to make Vanilla VHDL shut up
> (I use that for quick syntax checking on Linux now -- it's not good enough
> for simulation, but I don't have to edit my code under NT any longer ;).
well done :-) thank you for the hint ! Simili worked ok.

> I'm afraid the COMBINE mode is not a good idea.  It's true that the
> datapath of ROP2 is short (3 gates deep, AFAICS), but 64-bit AND/OR gates
> plus output mux are quite expensive (5 additional levels, or something
> like that).  That might be too much for a single pipeline stage.
i also feared something like this. The big OR/AND is not the only
problem, the result must be sent and selected on the output stages.
i'll stick to 8-bit COMBINE until we need more width. then, we'll
probably switch it to the Shuffler unit and pipeline it more.

> There's also some good news, however.  I'll attach some fallout from
> my work on the IMUL unit: an 8-bit adder with a 5-gate datapath (which
> leaves room for inverting one of the operands) and carry input/output
> that uses only 2-input XORs and AND and OR gates with up to 4 inputs.
> I think it's fast enough to be used in both the first stage of the
> adder and the final stages of the multiplier (and maybe the divide
> unit, too).
i gotta check it carefully, but thanks for the code,
it will certainly be reused all over the design.
Are wider adders possible ? thanks.

> While playing with the adder I noticed that it could process two
> additional instructions: (a+b)/2 -- `average' -- and the complementary
> (a-b)/2, each of them with different rounding modes (floor/ceiling).
> Both instructions are quite useful, but I didn't find them in the
> current version of the manual.
i've thought about it. This instruction is not much used in practice.
saturated arithmetics has more priority because the overhead in SW
is bigger than a single unconditional shift.
i'm still reserved about the average : it is used from time to time
in graphics (finding the center of a shape, for example) or sound
processing but i wonder if it's worth the added multiplexer.

The manual is in constant development, so all comments are welcome.
practical examples are a must :-)

Ok, i'll go back to the combine instructions, i'll test your last
code. BTW, i replaced UMAX/8 with MAXSIZE in the for-generate loop :-)
except that little detail, Michael's job is good and it works :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Oct 23 01:02:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00372 for ; Mon, 23 Oct 2000 22:50:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:09 +0200 (MEST) Received: (qmail 31701 invoked by uid 0); 22 Oct 2000 21:58:39 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 22 Oct 2000 21:58:39 -0000 X-eGroups-Return: sentto-1101623-1253-972251907-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 22 Oct 2000 21:58:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 21:58:26 -0000 Received: (qmail 11047 invoked from network); 22 Oct 2000 21:58:25 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 22 Oct 2000 21:58:25 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 22 Oct 2000 21:58:25 -0000 Received: from f-cpu.org (nas3-19.ras.club-internet.fr [195.36.203.19]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA01126 for ; Sun, 22 Oct 2000 23:48:08 +0200 (MET DST) Message-ID: <39F37221.A83E9E76@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 00:02:57 +0100 Reply-To: f-cpu@egroups.com Subject: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ff384159e7bba35cba08b0e9b0a5299f Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Oct 22, 2000 at 03:01:32AM +0100, Yann Guidon wrote:
> [...]
> > French people need others to show them the way, before they
> > even intend to act a bit.
> Just like most people all over the world, I guess.
Probably, but here in France, there are other cultural and
sociological factors that make us one of the least dynamic
countries... factor 1) : we're too used to comfort, we don't
do a lot to seek risky things, whatever the possible outcome.
2) : our economic system leaves no room for innovation :
there are heavy taxes everywhere and the laws are very complex.
tiny companies (a few people) have no chance to survive a year.

OTOH the associative movements are active and well. they have
all the freedom they want to perform useful actions.

> [...]
> > but that was a problem on the german mailing list, when they wanted
> > to constitute a Verein. The rules are more strict than in France
> > and they couldn't easily find 7 people located next to each others
> > to fill in the administrative papers. They also have had the same
> > problem as the french association for the legal stuffs because
> > there are no lawyers/specialists.
>
> I still wonder what the `FreeCPU-Verein' (or its french counterpart)
> will be good for.  Collect money for the prototype and tools that are
> not freely available?

that's the first part.
The Verein/association (depends where one is located) can also
organize meetings, rent the necessary stuffs, they an sell things
to earn some pocket money.
But the most important part is that we can't make a fundation like the FSF,
so the Verein/association is the best cheap way to replace it.
the Verein/association will own the copyrights and will be able to
go to court with more impact than a single developper. plus, the association
can go to court in France to defend a german case and vice versa.
Finally (for today), we will have more credibility when we speak to
companies, newspapers etc.

So it's more than a "F-CPU User's Group", it's like a multinational FSF.

comments are welcome.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Oct 23 02:34:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00378 for ; Mon, 23 Oct 2000 22:50:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:11 +0200 (MEST) Received: (qmail 32525 invoked by uid 0); 22 Oct 2000 23:29:40 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net with SMTP; 22 Oct 2000 23:29:39 -0000 X-eGroups-Return: sentto-1101623-1254-972257373-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ci.egroups.com with NNFMP; 22 Oct 2000 23:29:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 22 Oct 2000 23:29:32 -0000 Received: (qmail 30654 invoked from network); 22 Oct 2000 23:29:32 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 22 Oct 2000 23:29:32 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 22 Oct 2000 23:29:32 -0000 Received: from f-cpu.org (nas3-49.ras.club-internet.fr [195.36.203.49]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA09988 for ; Mon, 23 Oct 2000 01:29:24 +0200 (MET DST) Message-ID: <39F38779.EB27A73D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 01:34:01 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) ROP2 : COMBINE update Content-Type: multipart/mixed; boundary="------------885267EBC3A6D766C79C0519" X-UIDL: a4d87816bd9d2af241cee0176adf1aaa Status: R X-Status: N --------------885267EBC3A6D766C79C0519 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Ok, i have updated my files with Michael's input.
i hope that everybody can read the .zip file :-)

I have tested the COMBINE modes and it "seems"
to work, maybe i should have chosen other test vectors ?

Ok, now, let's finish the Icache :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------885267EBC3A6D766C79C0519 Content-Type: application/x-zip-compressed; name="ROP2.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ROP2.zip" UEsDBBQAAgAIAOSqVimOQOCm5woAADkgAAAhAAAAdmhkbC9ST1AyL3Rlc3RiZW5jaF90ZW1w bGF0ZS52aGRsrVnrcxo5Ev+eqvwPHVIVwx7Bjzx2F8LWEhsnVBHbh+G8+USJGQE6DzPcSGPM /fXX3dK8PGN7s7f+kHjUrVa/+yf57BLmF5fTOZxefrsajYcwuIbRdefli5cv3v5tPyQLjNRm IUNvPTdysw2EkZ27tR9AF9JvWEYxmLWE87enVzPYxtG/pWd482m03cdqtTbQPG3BydHREXwX YQhfZqOzywto7tb7lZS/L99626QTxasWHB8dnpwcEufvJ0drFsL/nEUQRga8aLNVgcTjlIYl /taBkQH8PQqDPYhMpw5vulnLWN7JGEIpfem3IZZI9SRrG0hjZKxhOIOdMmteG95LLzEqCmEW KnOgIRQbJ2uankinCV9sjfRhGUcb3siEkSe8tZxnHmNH8e5cAnpnFYsNCVnGUoKOlmYnYtmD fZSAJ0LU0VfaxGqRoGuVARH6h+jgTeSr5Z4F4WIS+tI6HW3YoPlL/vhyMYMvMpSxCOAqWQTK g7HyZKglCDybVvQa9V5YQRw00uLaaQHnEUoW5IEeSPQKHoL+0+SRk/QQJ7ENUcxSmsKQ8jFE W9rYQo33QEHI9j7ug9xUH1TI4tfRlgKEQtHOnQoCWEhItFwmQZtlIDfcjKZfL2dTGFx8h5vB ZDK4mH7vcRwjpGLMrSyF2aBQNNoWi9Ds0QQW8W04Of2KewafR+PR9DtaAuej6cXw+hrOLycw gKvBZDo6nY0HE7iaTa4ur4cdgGvJmcMSnvD0kqOFzvSlESrQufXfMcQaNQx8WIs7iaH2pLpD /QQm9nb/fBRZigiicJXmbO7OHqgl1UgbdrHC1DFRNb68P49xG0ah12nDx58/wDehNQzuMKyn YrOIlb/CX78N4Ojk+N2vbZhdDzI7/tb+whlBJRWCMFS+hjTfiFtMWYgFp+CKnIFeKHccLDMV rlhIuW41N4VYCp/FqnCLOUEV2oatiLXEVdCUGlh++9CIe1cMmHK+1B7mI7LY2tIGc9gzUazb VIiA2YXCLDWWOgkMdh7+wn1S2kyn06mSMW+9RJtoozTF2GZzm7mtUGwwVoGMfS3CFfJKoVWw 7/y9zn75Yjz6PBlMvoOSUvZevgD8mV0P+bOjjT8PopXy5sfHH993BuPx4xxG3qOzOyIIHvKE yYYiNUdeR07PxJUCM9GdlPJJuyi+7ZzjHJl7UbhUK0e2fS/0gsTHDoFdnebPmkrMC0TMyZxW DwUNXYiRVKsQG6UynQfihzNLzGS/fCFDo7A9DGd598akpH1fhhfDyei0aWVQFtFMwOOpcWEd dvvQoD0uTTrm3jQAlWUup5Kl8WYS0+rRgX7pNNZDxN4aS9czSeySDwVUdHJzNRVubcFU2kax KTqkzWUi7wVnepdOJk5sKr5Coo+53IaB72Me67ntGV24xiAnNspW62arV9iJvBJ3ecFtGyZY YPMhSrqhvfgbbv8cRYEUYbe/FIGWeeBwGNB2D1sPzQWrzBo7kg93IlZigRp6e4/0RM+h/cjc 7R/16vgCavFdCFQogU8AaoGe9MlrWwyKcaFbyJUKbdxuJqPpsEk7242f3EmvUUij1aswMJXW UXMrDjPZ1jg7QbsEtEcDtV30R9/ECY8Hd2L5TPxEnuw0ir5a9rL97NZnJTDXozJcOJ6V4vi6 mSCArwWWNCGofT52VBrwZ89KGZ87jLMvZylJOVNh/5HtSHqwaTy6GDYRGFzNpm1OlMdMGIV3 f8YAy/YjviqLwKnheDZC3z4nB2fwba3CT9mGjGmdnWO9C/CTzcIOupgw1b++no3rC47G6RxH DtYjnOJ/wuPa7MPFbNwDamIsxaexZIl1UhbJcunKsWdNo51cnQyPd2uFjWsnrbDagkbeOU6O BZ2elv9j1a9ylkrxr6ThHkkKNCgozVYD+xxOc7o7MORqJKEjdDqdB00i80e3T0Y1VRoL1e2r fxyXvM1GIqQKaQa8evUKT4AI4e4yiHboL+ndalomxmUSejygUL35GvtxU3crbbaF1Y1GhdUG 7JoZFOJW3d58h3buQkROR61uvxkRbNL93w6ODlIbst1JzW59sMZb2tMiCo4iIxAKRFuMBYaX ovKJXWbFECVNcw5JlvSe0MW0Sy2jnx0WIeBh0P8NDez/0Thq9B5Sj3PqcZV6klNPqtR3OfVd lfo+p76vUj/k1A9V6sec+rFK/Tmn/lyl/pJTf6lSf82pv1apg5w6qFI/59TPVeppTj2tUs9y 6lmVOsypwyr1PKeeV6niSZ0XT+rsPamz/6TO8kmdl0/pbAuBGKgNvD3upZWaZJzUqym1LWbQ a7U0EEj8p5tyJM2kVGLvscSSpltsvX2fl14v31KqaVOYC1Rg9ix5j9cdi0f4BQQn2/BynJ5b UjTtXK6OcYluKqE2eDFWdKkqgGdPxV6iDPIg+lTM4xE0K8Dk/ZZ7uUWdG7F1AJnGNfmKIGa6 QniNlmjUuTUEQ7REONKtMLihNQsx3WoZniK1tJByOUhD9BSUOkoGTZGU/s6kVi91QWq2Bdgx KkmjizzIg0XbHsUPPMSWduUuTId/TOHyangBk+HgbP7t8mwIo+vsimDjVR621jb+NUPP/FWA 0AsLoWm7CxUjaGUOrYuahOq1/E9CwSBMbWOlW3weuv9TXf/nvZ8Y79iFnVCGLwjHRxDqElOK 3eu47AsM6eUQ8SYJ7PVrEfl7l3h2JjRp6GLWkUOaBde1WsUJ4YxjN9irus7KJvdZ8UKRbqM5 jlmfXa9yyJG9yHWz5BI+kYtqtGlgZeVWwCDdfuHDjX0yikKUXiF++oluWpFP05/PfZ1DuwJj QVCZzMrYx4R2CuUcfbRkSHWAWbQy68P+kcOnueEEpOjgBvE1bPU7NAMOrpDWjLd4TGdt6Llp XRnY9TO7QE1baI9bKD9OHmh+z9psMEFLnMDtCnK9erWi/kmiHmws+HR8/oaQ+evXr2FILzLL 4vWaljuNN+PzVq9OQp3by1yY7/VaTWu0wm6bp2j1LlGnfePGYcYuYOUYRVfzCdc1VpQz5FXj zefhuKKbDCx8Lv0USyQv7sKm9BpRY9LNEyY9fsX7s1axBP0XzSq1+U/9DDk/cmHM1bdInRLR i+IYD7bvwKEv7+n5Xxt6mKWl7E5jH/7WQmNbQ6+IgJrFHhoSZ2LYqJ6wzIvhsH/QPah3DvUc Ho0Neb9FNXCoEu9Cmh2fYu2AN+ALI9p8P1nSu2yjalPpJlj44VafeaZ0Fy6nR3YL/+EMmdRn SJPF0svyf7Mcaf3F1KdH2v8vRyheNSlSvpSXPZK+gfyoQzIs+Fx7eg1JeBsieuNGSC/Hhbem um1ZTrneVeAsoMs/080cLqSks31YHGq5pTfBKD4sgMMsmIhpf7Pz4CuBUY6jHTS+/aObE0ai aENaIYKnOzVgUqRkWrXPP5HNlYmTZRgPnD4Nl5rs+qEzyiIPUWa7TmYxW5ED0tptwwr98DCA deF7nKUBBKTRc7VinpxM1YxMbwE1DnDMFL+7SPnunbqEH2SMkM7CJKH5UZMRXLcIxRErZqOl V8bZjuS+eg+gtqOmnyXI5p5480uAQ6SQPxzFirGN9FdpSvGmbp//o97ObMK/4zsJt3L7qpzi qzJkdc9R0g4CB5Yps+mT/hxQVMaCzFwZ/A4eaPOIeHpb0tEGFVIb/tsb1oiXwh9+Re4VK59B NA6d7XbPPIVbXXbdmHtBpMvIOSUzTCEhOM+2D4A4MpA0d3np2b9u+Hx3wY//AVBLAwQUAAIA CAB7uFYp/zGtan0EAAD6DAAAGwAAAHZoZGwvUk9QMi9GLUNQVV9jb25maWcudmhkbK1WXW/q RhB9j5T/MLpPIQUHG5KmoakuEIgiAUEQ0qYvaFkvsI3ttXbXUPfXd3aNCR+mUpPrB2Tk2Tln 5+PMVCrQ5QGDbqU9nEypiOZ84ayWfnB+VqnABS3BG4kieJw8PTwPyiCodsBzy+BVq1Vrsl6m C8a+zys0ThwhF3AF9v07W0iRxMqhIrSG9mdVdTy4gz6nS8ICGHEWM8D3aMF86E5HzcFjxxha 45clVxAT+k4WDHw25xFToJcMvuEJSahmkivNKay5r5fqG4i5PWdMeIRfIxJAEnGtHBgGjCgG kqmYUW1N8F1LTjUXkXLOz87Pek+tUXP0Bpwx1jg/A3wm44796yjtTwOx4HTqujd1p9nrNcyR nF33I3rAlflS+dRj+feF0sDDWEhNIp2lBtC5Mn8V3H3eublU7gj6zT/GT392MB0R0YnEWN3d w20DNg8SGfN/GAZ1E60FBptJhaGFWaqZKgOJUojFmklrtBbw2z3UnT2QCaLsI+SwlwbrP0FM 4owzlcx0inWyqQ8M8NafNJVjQSou+GIdaQFVsH5H9hM6Jlu3WaFgKdEA68ck/sD/a6f98jwy ACbfSZbwFRaMkBcb9FLmXS0xOzTRMBcSEVZMpnjpMBTRgfsvVcJYhAyIpEuukYS98bYOyjAT SeQD3rjbroKIgvRrpYF4PRfahC6xzS5UHHCsQgSTSdYjmG4ffKJJaS/DPfehlcV1P8/e9U0W qgc8Aq1EZdFHDcnzgLlhiAbUQEKA7Q0XNS8rrkOMZiEGWmcYTd/Hdla7MFhBNa9inKHAJBF9 V8b7T9f3rnf72Dr03xOLntWXPf83sPGPn728SAdJ2MpKPiOenbvoT8YvMGPQee0MDr0PWoE1 OvBe33g/4dG7vMxplTAhIQkCiJJwhqam6gyXOZeoFURrFsbaBO2LBfeCPseokBwZjrbNeLcZ BiLmKNNzKUIYj5xl6QcJ0Xg0HUz6rc5onCnPXpCqjRO20xUa7Nu61cZWu9wq2mLNSmakNGAh w4ngm6rQZqyEwmfBMY9us//Ue4MCHm6j2DajsW9br9a8Rk4kl28kkiXPQT0KiXzHM9W/Tetm B+CuUjomNH7pDIdPg8djQl7jlK2ldED+Q9QlW3GF/Xy1DYuVqmNoFNWpVeoj6FrjlO0x9Ebu bZ3vTI7juVFwd+PQLUpGvVFsW5SM3bvbWYPdIvksQV3APQYXCX/NpamM+d6lf8VZeIKSV0Tp upiSV0TJO03J+xylWhGlm2JKtcKSPU2p9jlK9SJKPxdTqhdRuj1Nqf6/KbXf2r0OFFHahRld /V6GVxIkzOwAfhqRkFMzSqjMBYRloz6lAXOOYYbNx7xZD2B+2YEZSmHmOfPLGWJbRFqKIFtu Y2J24ZCFQqYWgeHY3dkvG5nI55vnTPjpj10/OzhKUgeezUJhCH1snqEZNBJXas0D3Dt8Ygjm a0qi2DwJYC1JHJuhgRNqjmM3Wx2oSALfTEcMZZD4zLfnlsyos52qqVXqiFGc4gQDnA+4WIq/ MFTOV0ZNcQD/BVBLAwQUAAIACAAAB1cpeJZYrfsAAAAjAgAAGQAAAHZoZGwvUk9QMi9ST1Ay dmVjdG9ycy50eHRlj01rhEAMhu+C/yHHFrY02a9Ce9KKx0k/KHh17UCFnZkiu4f++8bMRrpU eWPUh8fXCpHob1Y10vW5arEsWpKsJRvJVrKT7CUPZdEI8QR9bOBmSOEwRg8hffpbfUM61zo3 Orc6dzr3OsXB6uDpn4JVwapgVbAqWBWsClbFa1lInykFOH15aO+eXz4g9PHcH+GxLCB9D2KE ycu9bu05DqcxRXj/CYd0HAeIffBCAiKCHrKQXCqoXAP1/ESWTJARhAtxX2fCKUImoQvS8VuW yDITRLQQ+TMGwAWwHpQbVeCMcEbQQmRFZ0hniPUgwuUr2lQWd9WDrKmz/52XX1BLAwQUAAIA CABYB1cpD2wl7ZMGAADRDwAAEwAAAHZoZGwvUk9QMi9ST1AyLnZoZGytV1tv2zYUfi/Q/3DQ l9qbrUbJLl28DlNcJzOQ2IEva7MXg5ZomygtCiQVz/v1+0jKlpzeNqBC0UjyOd/5zpVH3e63 up4/63ZpMr4/jx43maRwT4O/eVpaoXKa58LSSmmyG07X3f793Gv0VbHXYr2x1Oq36fzs7Iwe WJ7TzXz4djyi1m6zX3P++6qbFmWk9LrttLzm41l0fkl3It0wLmkieMFJc4iwXPzDM29ny0Tu jHbXPOeaWU5SqeKgfnFJDzfQKSRLoTC/S96/ek07YTeE2+nwrwFddmuDs40wVGi11mxLuF1p zsmold0xzXu0VyWlLAdeJozVYlnCHHxmefYKbm9VJlZ7D4SXZZ7xEArL9daQWvmHm9GcbjxV SfflUoqUbkXKc8OJwbZ7YzagugxAPpSOxbRiQdcKyMwFvEccjsDII9fGJeD8YKRC7JDSHqXF rCOvSRVOsQ3Ge5II1lE3+mwMalczQqgd/EYhEXYDUPi5E1LSklNp+KqUHY8BaXo3nP0xns8o GT3Qu2QySUazh54PvcKv/JEHLLEtpAA0fNMst3u44CHuBpP+H9BJroa3w9kDPKHr4Ww0mE7p ejyhhO6TyWzYn98mE7qfT+7H00FENOWOGPcIX4j0ymcLwcy4ZUKa2vsHpNiAocxowx5duaVc PIIfoxR1/PUsehQmVb4OZWYb4eyRWFGubId2WqB0rPo4v16/znGHhnkadeinn3+kO2YMJY9I a59tl1pka9zeJXR2Hl/80qH5NDn68U1b3lcE/jmuK6GNPRYcsqirjsfvJfrfM6ChPQQRhcGZ EXJPZp8DwIp/2FJyXyGudrkDzpWLEEK75xXAO1dcW2ZRoQaZgkmrMrYPLELdpWpbCMmN6z6Y cdkyeKmRMSv3FQzTuUAmLgPBVGXentOo+GnuB0hRag6OwFyKnFmlBatKuUkSHZNuHJ5713Ek tiWowcdM5ehfNwmU70iJyMjA4brU7pUrt04IYZmnfl5iUH0oC7I+IHW8tsrVG2cafRHat2q7 QhRcitxZBmOG2pMYi1WVcXq/ZJrSfSp5ZRieSLnHEMjh2nKPggv+uZjBp0IZI2A6QoI59cd3 V8PRoLKHli8DSXhurGtxeOZjLrl1odK8m/EVwLLo2xbc82e3w6tJMnkgwTnvPX9GuObTgX+M jM0WUq1Fuojjn36IktvbpxJ5ueUav0Mygv+9Gm+n9IeGtHuMrnFKLVKVr8S6Anv+bJBbgUE0 mC/8ASeM0ymUtq2g/Fbki6Tj/1wRagvZuF78OejPxpOe+52quY1xXGBC5JkJekBbHJMf9KZw pwz+PKJulW6do5Z2OSbDWbvnkS7qglkKW0H1QyIXyeht5/iAsfgENNChAymWZcIBYWgB092d ohmcqp/jFZ/wcmhljpGfUTK7i+jKV9cGRD8YX29RFSo36w/XJbmnQ6iakdLclNI6lTYywNGe VfB9PhKNrrOggSZF5aab2I3h0/QYsXZuoSssWncRADvH5/GkvkfMQKWRsYpE9XtFxkQNWKlS KB7zcPmJ+Fw8zZuD9HodnDJu8mSd00zCwJKvRe5chHwM2JOJ4AddUDWngyPUAXSqq1UPDz+I kEBsKdUEQfuyNW87b/yoOKlCwyXoh1w9cfLXN+E10QusbPEL2m1wZLv7Fx3vIOLYkIjPaom4 lhjVInFDJD6AvB9PmhK1mfgA0hCInfFKID7yGJ1KxLXEAeL9qUhtJT7yGE9qpnHN1E9z0/Nm vL8+7Of+QOFh//U9jgrAcYBornzZnJZhI5TUark56idI259Dx+er6vl6gVXpZkBvfnuSkdZF u90OQLD2MdBhNH0d6PwU6DjT/jej+MtA/53RGYB6VXQvEN1DL44n4bRG7N1c8VFfNmfNpTN/ 9TAbLKoDDMpuIRGuCaoVv1vPLjp8JQTW9Xhovf5OfP/zQQ4PbWTNl4K/Qjkcsnia3k+ovnrj G8VfLw5aXGLzrF/3TinAw2/Loan5eQpuWXu5rY54hJRr6/YhtlRhQcNMwYazw+oF3LC1Mmw9 0oquPy2anw90L0sTdhz3bZGne9r67z7+dyHd6nXsGbcpvsRazDVytWUwGwCmYSH+GN9/iGhV FDhw3Mkl3fK1xGzcYjbm2NGNYbpa+m65w4ZH6QdHGp9+cMgVjYki353ufDl+LTZr51CBP7gi cttTNR/9pHRTNJSbP9SQmbp6KEyLVuMkRvxfxi+r7giBbx5Ap/LuzeflQ4rDwYj//wVQSwME FAACAAgA0AlXKZZXgEMoAwAAVhEAAB0AAAB2aGRsL1JPUDIvUk9QMnZlY3RvcnMub3V0LnR4 dL2Yf2viMBiA/57gd3ihB6eyq0lbdRY8cNOyg/1Cj8GgILWNGq420lTv/PaXbipt0uGO7lqJ pn3zJk+CfWg63a83KxbtYTwaQmPShOfb0R3csPWGhiRuT+l6G3oJi+GeBduQwPMqCMeX8Exi TlkEWLcu4XpLw0AzDb1eu2GbfUyXq6Rx04Rptm/c7/e+GQghHYZhCK+NOMSEk3hHApE6IV5A oyUEtrsTg7icrmlI3TmNXH7oSKcRBV0Xje/oPPbiPXylhJCvFxeDwXf4Mn25f7p9fHhpi2j7 hwi8fukiO5Pwm8W/Dglp9S16HPt0yY3ZxpglhCdzEvkr6VTfeXFREtnO0obH3/eaLfzNduaz aEGX2XpjzoJ9U0o6TcoVM3DT+bjHSbk8CWYhW1J/hnHXkk7/ubdouyaxSBbdZOslqBLyJ6FM uVDY48cWvpHWmh9c/oYX+yt8aH2hAVvAlC4jL+Twdgygi/rHUPqXZxGJEv4WwsfAU8x8wjnh hxzjFBnFdCfug1NvZt+q10aEi0HgjnlBexx6cxZ7SXqniPqGkwB+0jWxAaGVjdDaRpjbZqez 5vVaq9WCgPjsdVIhjQhoYqQW+Htf3Hca2IDFKJPHJwMW28hPO7VRvQYjGs2GA4QwzpZD4HqA cP4jAjBi20RkiNNMKSQw8gSGQoBLEeQAUCGBmScwFQKjDEE+oZjAyhNYCoFZjgBnSyFBJ0/Q UQisEgTOeDzOlkKCbp6gqxB0yhE42VJI0MsT9BSCbikCx8mWQoKrPMGVQtArQ+DkGQoJ+nmC vuoDcUWIbJ62tmH4MCrnh9xRbCgkKQqphqicSdam6k2jciZJpFg1qVk5k6RWrLrVqpxJki1W bdupnEnSL1b92/1UJsfJlmImSchYNXLvE5nyRO+tk6Ro3Dvjp8fJf18mydn46oyeKkCSJI77 Z+xUCsmRjuKHPEniBjojpwqQJIcb+IybKkCSn4WNM2qqAEkyuGGeMVMFSJLADeuMmCpAEv5O M0DTNBhHQbp12xE/famxoCmmpulpi8O7jnSzxhO22YjNmpekM0AQ8Vz4nb0c4jbqd9O93F9Q SwMEFAACAAgAmQtXKQfwAcYdCgAALR4AAB0AAAB2aGRsL1JPUDIvUk9QMl90ZXN0YmVuY2gu dmhkbNVZW3PaShJ+T1X+QwdXxZDFGHAuJxBSBzAkVGHwYnxy/EQJaYDZCImSRjjsr9/u1kga kOzUSeVleQhmuuebnp6+fDO5uPhdn5cvLi5gNr1tLpQI1VJ49qa23zgutHj0PAQc52FY+QGo jYDhRf/2HnaB/x9hK57f93eHQK43Csr9CjTr9To8WJ4HX+5H19MJlB83h7UQf64u7F1U84N1 BRr1y2bzkjT/bNY3DML/zDcyhJV0BeC35Vg7JRxYBf6WV2ZBaidavN25lhJscI3mM8a+Xmui +Q9fwHaF5SEAzZWeEmsRlCtgW6GiIQ8XcFAaRrudH6h4fwguvTXj0Kz+9KY3mgxwdqiCyFbS 98JsJbYWHbEOrC0ZvAqEgNBfqUcrEG04+BEu5kEgHInT5TJSaIcCy3Muca2t78jVgYFwMPIc EftXiWAbgr/iH18m9/BFeCKwXLiNlq60YSxt4YUCLFybRsINbmJ5SG0ekhV32goY+ohskeFt EBLlAexFEOJvaCaLaMQq+AGjlC1Fxgfg72hiBS0+AHk6nfu0D7KtOug1ht/4O9zVBkFxn4/S dWEpIArFKnKrjIHa8G00/zq9n0N38gDfurNZdzJ/aKO22vgoFXsRY0k8conQuLfA8tQBt8AQ N4NZ/yvO6fZG49H8AXcCw9F8Mri7g+F0Bl247c7mo/79uDuD2/vZ7fRuUAO4E2SYYIRnPL3i 00JnOkJZ0jUi4AGPOEQLXQc21l7gUdtC7tE+C2xMip+fIqNYru+tea+onbmzDXIFnq+q8BhI DB3l58+X52dnXIWRZ9eq8P7DO7ixwhC6ezzWvrVdBtJZ4583Xag3G1cfq3B/10338VurydRz D3CF+99uMdIxjdFxHN2h8n0HDkJhdnZbEApOQ0DLrQWGShfjIIwDopeX9lgKw0yC9QlWkcdJ WdOxKGjZpfREKgkp3Vg/wNxmY9ClbAUlu3Bqv9cBL1+MR71Zd/YAUgjRfvkC8HN/N+CftVA5 C9dfS3vRaLx/W+uOx09rKPEDN1CzXPdUx4u2IkAN1NXiZE0cMZRJrlGOV3r0g++1IZbxhe17 K7nW4rSEOMJ2rYAjKglhR4Ry7eFBZrUK3Vc7wRzcL6htMJbwlMQEPW4uWCJoypfBZDAb9cvx dKrrnrUVGBdUPDAXWh0o0cQ9thg/CGvqhyoBGsda2qJYxpMJptKmJZ2T9dgSK7A3mEC2ioK4 fxBEgV26lR1vGVsgtwfTJy1akISYz9fSW3Sr/NUD3MFw8degP5/O2lD80S7G4rvDeoAJYmCh TYskcAnrDoMhiqMh3m35Chz/0cNKUK+0GesqjXRYSmWC9eNMWHQn19X0B9ZCE7Z9bBg2RElQ OBtR6a8CvFD+VxTa1jiyjfAiD8u8A935TQ16Byxh9gaN/Y7dDWtEzXQiFfnk83MfJk7ElI5c pQOXOnxAYDaWQ+pV8SltMOUd2FuBtJZIH+wDsgJcwrMwGlC51am3i/RcsqgFLtUSDiKgsmwL h2Joh0GqdCgvxVp6cRx/m43mgzLNrJbe6JXOEKRUaecUWErjaHkMh5nMm4pdEgK2ahHv4RgZ f1LspufeSuG/GmpmKCVybCdlIyo6543zCjOhWJxbRutSuZ5cp6sINxTJBBNxOssDPgM5naWI iImJK1fJAuYPnj9GDlZGdnB7P6/yyRQ4tBRnYqfQGyyq/Bpk72nI3i9Acqw/AXk65wlEdFBS rYdYAS1wou0SdlYQYtRjr/zr6/W4OPqJMi9sHMQD6OOXZXOidGByP47rCaM4YCfCIpRltFrp 3GhnCcmpwlz9cSOxoj6KGKwwuyhgsI0tafUkF59KRZmpxDZK7D8/aKNkyGluroXick6KpUBY TrlSwsIkQu77zNJKkacFtVrtJIdTD7U6hF6WafK0OvJfjSP/szHIwjxqWa9evcIVwEeGvHL9 R/SgoEqHw6SYFmk0b7ERP6xy2MpV0AoWNNyml6+tutaAcZKtZ5tDq1P2ieyHnc/n9fNkD+ns qGB2eL7BO9zzEIajaBPIVPwdng4eOJ3TJ3ZZDEOSJLv5SNJcx/uXGYjJzujzSLcyXAw6n3GD nb9L9VL7VNrIpI28tJlJm3npVSa9ykvfZtK3eem7TPouL32fSd/npR8y6Ye89I9M+kde+jGT fsxLu5m0m5f2MmkvL+1n0n5eep1Jr/PSQSYd5KXDTDrMS61nbV4+a7P9rM3OszaLZ21ePWdz nAikQGXgotFOMjU6amEU2nFLDzdypcAV+E8r0YjK0VGKvcUUi8p6sHLx1qBP2ZSjnFZGh6QE i9cSP5D4xXSBeBU15cF0nKx7ZGhSuXQe4xDOH3mhwru0tJTQDxB0LwJbBnYkkV3FVFmylk2t WzN7TfZ5GabIW2unGX3ci8lfMT02RnvJaC8ZPWK9KDR/l5vZ/hN9g8KQuslzTzSQ7RoK09mp nKmsoUG/U1uJAJKp+M1DlXbisMRJ8c0hQAWmNCjkNhTGFS19rUpqeAvmg7/nML0dTGA26F4v bqbXAxjdpfef+HSPmzUazd+0WZN0tzpYJ2mCPkqKObmN3PiCsvSdgw6AuDaXqfnh6dNSZcOo SsWs1NxbpeKVwzRwk/XTJdPB6SwZywCos2IcpvezjBakT3gJMKmS2DSoSi0kTQCDJ7Q6xg/d iGl79DSScO43b+ia5jvUj3nds4xjGooG0LGYjUGNHSlpuqXloxWzjXM8qbXaXHbq8RNitm/i OrRuidRKcTpqegGaP5DRTIm4b6Z14WftM9dBi5uoIU1qWptrGj8w4jXW4jcZTN4jTeD6AZld 7UKofxPUyUTDpePha6L3Z2dnMMDihDdo43pOw7XS6/Gw0i5CKPL6sZYl1alVBvNqEe9CxkiP YJ590MyrVrCJbuIPekPiynSyEo996qQkLb03FID1TsF6BWC9E7DeE2BDE4wTRRfAE0yzNhrQ p7e9ghWmyQrJC9l0doJNl7m01vBjOKd45ZJy/ORal4+A0rf0OLAMKblzzefzJBxelV73BuPc CZt3yvSTlZjGeW5Cckcs2On16U5xP/8PW41L7D/aa8pLfpaZZxB53z3spMm7rPksUTQtrS2/ lrYGGwLQLGWHfomLkHUZih09pvnBpUFV0qNBhvU5LoZfiRrFpZZz3vH5GqfBCIomWC61kgNY 3OOo+pBxR0bni1zev0+X2zReuNp2qLJW8mHyj9Y4hrxEzGoRphl2qKF3LpwqrNEPp0dYdIBP q5T4/7XQc4UwPz3f45hMOGmBA7Qynd/el45+5DVJww4vzX4QUwQr5Bew7KH1iNB96uhcbefZ oJbhX0eMRD/56QH+1erwF9KI5OFzz9xW8f8g8PNhwguw9/B/ADXq4IVa3dVFWlNkikr6SU/g eho/6bVPniyXAjbWbndgHYPDp3RxYbt+eMzPEjH3QG4QCn0cvxMmdA8VCE2TT/347jD3xB// A1BLAwQUAAIACACyC1cpW4VGnukAAABXAQAAFgAAAHZoZGwvUk9QMi90ZXN0Uk9QMi5iYXRd j8FqwzAQRO+B/MOQUwKJ47r3kmJaMLQ01O05yNLaElUkI63t5u9rO5CW3nZmZ9k3gc5givz+ dsySSjDWcoNBXxqiQ72TbZf40Gxxl+6z+32WpulyEcaTD20ixrjUqI0ldJEihINxkYW1pFAW r8VLAWUiB1N1bLxLloteK9vieZcfP0/Su9o0yWRhfn+bThNRRU7q2bueEYJv/6webti+44S/ +UpW1KCewoW1cQ1GSv+FtXHSdmoyWBNWSrjGTuoxz5/KcoVBBDfqzRatJREJ0p9bEWiO8+Dn khH/P46N1Qzck2Qf4i/JD1BLAwQUAAIACAC1C1cpor05nSYDAABWEQAAGgAAAHZoZGwvUk9Q Mi90ZXN0Uk9QMi5vdXQudHh0vZh/a+IwGID/nuB3eKEHp7KrSVt1Ch64adnBfqHHYFCQ2kYN 1zbStN757S/dVNq0ozu6ayWa9s2bPAn2oeni4O+2LDjAbDqB1rwNz7fTO7hh/o56JOwuqB97 dsRCuGdu7BF43rre7BKeScgpCwCrxiVcx9RzFV1Tm40btjuEdLONWjdtWKT7xsPh4JuGEFJh 4nnw2ohDSDgJ98QVqXNiuzTYgDuy9mIQi1OfetRa0cDix45UGlBQVdH4jq5COzzAV0oI+Xpx MR5/hy+Ll/un28eHl66Idn+IwOuXKrJTCb9Z+OuYkFTfoqexz5eskO20ZUR4tCKBs5VO1b0d FiWReJk0PP2+12zt7OKlw4I13aTrrRVzD20p6TwpS8zASuZjnSZl8chdemxDnSXGfUM6/efe gtgnoUgW3aTrFagi8ieiLHehsMePLXwrqbU/uPwtO3S2+Nj6QgG2hgXdBLbH4e0YQx8NT6Hk L88CEkT8LYRPgaeQOYRzwo852jkyDele3Afn3vSh0WxMCReDwB2z3e7Ms1cstKPkThH1HScu /KQ+GQFC2xFCvih8NBz0fd5sdDodcInDXifl0YCAIkbqgHNwxH2nwAiwGGX++KTBOg6cpNMR ajZgSoPlZIwQxulyDFyPEc5+RACmLI5EhjhNlUICLUug5QhwJYIMACok0LMEeo5Aq0KQTSgm MLIERo5Ar0aA06WQoJcl6OUIjAoE5mw2S5dCgn6WoJ8j6FUjMNOlkGCQJRjkCPqVCEwzXQoJ rrIEVzmCQRUCM8tQSDDMEgzzPhBXhMhWSesRTB6m1fyQOYoNhSRFobwhameStZn3plY7kyRS nDepXjuTpFacd6tRO5MkW5y3ba92Jkm/OO/f/qcymWa6FDNJQsZ5Iw8+kSlL9N46SYrGgxI/ Pc7/+zJJzsZXJXqqAUmSOB6W2KkSkikdxQ95ksQ1VCKnGpAkh2u4xE01IMnPwlqJmmpAkgyu 6SVmqgFJErhmlIipBiTh7yQDFEWBWeAmW7c9cZKXGmuaYCqKmrQ4vutINms8Yrud2KzZUTID BAHPhN/fy6GBnuzl/gJQSwECFAAUAAIACADkqlYpjkDgpucKAAA5IAAAIQAAAAAAAAABACAA toEAAAAAdmhkbC9ST1AyL3Rlc3RiZW5jaF90ZW1wbGF0ZS52aGRsUEsBAhQAFAACAAgAe7hW Kf8xrWp9BAAA+gwAABsAAAAAAAAAAQAgALaBJgsAAHZoZGwvUk9QMi9GLUNQVV9jb25maWcu dmhkbFBLAQIUABQAAgAIAAAHVyl4llit+wAAACMCAAAZAAAAAAAAAAEAIAC2gdwPAAB2aGRs L1JPUDIvUk9QMnZlY3RvcnMudHh0UEsBAhQAFAACAAgAWAdXKQ9sJe2TBgAA0Q8AABMAAAAA AAAAAQAgALaBDhEAAHZoZGwvUk9QMi9ST1AyLnZoZGxQSwECFAAUAAIACADQCVcplleAQygD AABWEQAAHQAAAAAAAAABACAAtoHSFwAAdmhkbC9ST1AyL1JPUDJ2ZWN0b3JzLm91dC50eHRQ SwECFAAUAAIACACZC1cpB/ABxh0KAAAtHgAAHQAAAAAAAAABACAAtoE1GwAAdmhkbC9ST1Ay L1JPUDJfdGVzdGJlbmNoLnZoZGxQSwECFAAUAAIACACyC1cpW4VGnukAAABXAQAAFgAAAAAA AAABACAA/4GNJQAAdmhkbC9ST1AyL3Rlc3RST1AyLmJhdFBLAQIUABQAAgAIALULVymivTmd JgMAAFYRAAAaAAAAAAAAAAEAIAC2gaomAAB2aGRsL1JPUDIvdGVzdFJPUDIub3V0LnR4dFBL BQYAAAAACAAIAEICAAAIKgAAAAA= --------------885267EBC3A6D766C79C0519-- From Michael Riepe Mon Oct 23 03:56:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00381 for ; Mon, 23 Oct 2000 22:50:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:13 +0200 (MEST) Received: (qmail 9632 invoked by uid 0); 23 Oct 2000 01:56:23 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 23 Oct 2000 01:56:23 -0000 X-eGroups-Return: sentto-1101623-1255-972266179-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 23 Oct 2000 01:56:20 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 01:56:18 -0000 Received: (qmail 90273 invoked from network); 23 Oct 2000 01:56:17 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 23 Oct 2000 01:56:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.173) by mta3 with SMTP; 23 Oct 2000 01:56:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA03033; Mon, 23 Oct 2000 03:56:18 +0200 Message-ID: <20001023035618.11817@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F37220.F6D39EFC@f-cpu.org>; from Yann Guidon on Mon, Oct 23, 2000 at 12:02:56AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 03:56:18 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70dafe81d2c1288287ae1c1cae41a4cf Status: R X-Status: N On Mon, Oct 23, 2000 at 12:02:56AM +0100, Yann Guidon wrote:
[attachment content-type]
> glups ...
> VHDL and VHD are associated to the wordpad.
> i don't know how to configure that part of Netscape

Edit -> Preferences -> Navigator -> Applications -> New, I guess.

> (it's running under W95). If i compress the file
> (zip or tgz) it should take less room, though.

I can't read it inside my mail reader either :(

> > I think you got the opcode decoder wrong; see my corrected version.
> "opcode decoder" ? i don't see where. Is it the lookup table in front
> of the ROP2 unit ?

Yep, that's it.  BTW: we only have 4 bits left for function selection
in the opcode according to the manual.  Where can we put the Combine_AND
and Combine_OR bits?  And where the NOT function (it's missing)?

[...8-bit adder...]
> i gotta check it carefully, but thanks for the code,
> it will certainly be reused all over the design.
> Are wider adders possible ? thanks.

Wider adders will need a second pipeline stage.  I hope to get away with
1/2 stage in the multiplier (I can split the 8-bit adder somewhere in
the middle and combine the front part with the wallace tree).  The back
end will probably be a 2:1 mux (carry-select adder).

[average instruction]
> i've thought about it. This instruction is not much used in practice.
> saturated arithmetics has more priority because the overhead in SW
> is bigger than a single unconditional shift.

It's more than a simple shift because the carry bit is preserved.

> i'm still reserved about the average : it is used from time to time
> in graphics (finding the center of a shape, for example) or sound
> processing but i wonder if it's worth the added multiplexer.

The `(a-b)/2' also has its uses.  I remember some numerical
algorithms...

> The manual is in constant development, so all comments are welcome.
> practical examples are a must :-)
>
> Ok, i'll go back to the combine instructions, i'll test your last
> code. BTW, i replaced UMAX/8 with MAXSIZE in the for-generate loop :-)
> except that little detail, Michael's job is good and it works :-)

*bow*

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Mon Oct 23 04:02:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00384 for ; Mon, 23 Oct 2000 22:50:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:14 +0200 (MEST) Received: (qmail 11958 invoked by uid 0); 23 Oct 2000 02:02:58 -0000 Received: from hh.egroups.com (208.50.99.210) by mx19.rz2.gmx.net with SMTP; 23 Oct 2000 02:02:58 -0000 X-eGroups-Return: sentto-1101623-1256-972266573-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 23 Oct 2000 02:02:53 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 02:02:52 -0000 Received: (qmail 795 invoked from network); 23 Oct 2000 02:02:52 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 23 Oct 2000 02:02:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.173) by mta3 with SMTP; 23 Oct 2000 02:02:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA03056; Mon, 23 Oct 2000 04:02:55 +0200 Message-ID: <20001023040254.42136@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F37221.A83E9E76@f-cpu.org>; from Yann Guidon on Mon, Oct 23, 2000 at 12:02:57AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 04:02:54 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5a6a611b92ccdf851abe29836a79a9b0 Status: R X-Status: N On Mon, Oct 23, 2000 at 12:02:57AM +0100, Yann Guidon wrote:
[...]
> the Verein/association will own the copyrights [...]

It can't, as far as I know.  At least not in Germany, because the
so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
give it away.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Colin Marquardt Mon Oct 23 04:29:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00387 for ; Mon, 23 Oct 2000 22:50:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:15 +0200 (MEST) Received: (qmail 17387 invoked by uid 0); 23 Oct 2000 02:25:59 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 23 Oct 2000 02:25:59 -0000 X-eGroups-Return: sentto-1101623-1257-972267955-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mr.egroups.com with NNFMP; 23 Oct 2000 02:25:57 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 02:25:54 -0000 Received: (qmail 31009 invoked from network); 23 Oct 2000 02:25:54 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 23 Oct 2000 02:25:54 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 23 Oct 2000 02:25:54 -0000 Received: from morphin.marquardt-home.de (e133.nas22.sonic.net [209.204.142.133]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id EAA03257 for ; Mon, 23 Oct 2000 04:25:42 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13nXN7-0004BE-00 for ; Sun, 22 Oct 2000 19:29:57 -0700 To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> X-Now-Playing: Silent Cry's Goddes Of Tears - Last Visions In-Reply-To: Michael Riepe's message of "Mon, 23 Oct 2000 04:02:54 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 22 Oct 2000 19:29:57 -0700 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bea2ff63c33e01882e067741bad72146 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> It can't, as far as I know.  At least not in Germany, because the
> so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
> give it away.

Except if you do contract work for a company. Then they will own
the copyright IIRC. But that is really nitpicking in that case. But
maybe the Verein could hire you? :-)

Colin
eGroups Sponsor
From Yann Guidon Mon Oct 23 06:51:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00390 for ; Mon, 23 Oct 2000 22:50:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:15 +0200 (MEST) Received: (qmail 16530 invoked by uid 0); 23 Oct 2000 03:49:26 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 23 Oct 2000 03:49:26 -0000 X-eGroups-Return: sentto-1101623-1259-972272963-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 23 Oct 2000 03:49:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 03:49:22 -0000 Received: (qmail 27588 invoked from network); 23 Oct 2000 03:47:06 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 Oct 2000 03:47:06 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 23 Oct 2000 03:47:05 -0000 Received: from f-cpu.org (nas1-243.aub.club-internet.fr [195.36.150.243]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA10455 for ; Mon, 23 Oct 2000 05:46:57 +0200 (MET DST) Message-ID: <39F3C3D2.BB13A05C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 05:51:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: multipart/mixed; boundary="------------5E0FCD9120D47D2C21E7069A" X-UIDL: df6765f3c63700f9859552cd905a832a Status: R X-Status: N --------------5E0FCD9120D47D2C21E7069A Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hi again ! :-)

Michael Riepe wrote:
> On Mon, Oct 23, 2000 at 12:02:56AM +0100, Yann Guidon wrote:
> [attachment content-type]
> > glups ...
> > VHDL and VHD are associated to the wordpad.
> > i don't know how to configure that part of Netscape
> Edit -> Preferences -> Navigator -> Applications -> New, I guess.
i've finally found a way. i hope that this one will work.
Please tell me what you think.

> > (it's running under W95). If i compress the file
> > (zip or tgz) it should take less room, though.
> I can't read it inside my mail reader either :(
geeeez, what a fucked up world... ok, i'll try something else
in this mail. It will be larger but it's an attempt.
tell me if you get it right. i have also completed some
comments in the F-CPU_config file.

> > > I think you got the opcode decoder wrong; see my corrected version.
> > "opcode decoder" ? i don't see where. Is it the lookup table in front
> > of the ROP2 unit ?
> Yep, that's it.
So what do you propose ?

>  BTW: we only have 4 bits left for function selection
> in the opcode according to the manual.  Where can we put the Combine_AND
> and Combine_OR bits?  And where the NOT function (it's missing)?

well, i thought that i'll think about it later.
Yet, it's an annoying configuration.
i'll drop the size flags anyway.

First proposition :
the ROP2 "opcode" (the 8-bit field in the MSB) has 2 variations:
1 is "normal", the other (bit 0 set in the main opcode) is "combine".

the subcode is situated on the flag position : the 3-bit ROP function
code and the 1-bit (AND/OR) code.

to sum up :
bits 0-7 : opcode (bit 7 enables COMBINE)
bits 8-9 : size flags (ignored)
bit  10  : combine mode (AND/OR)
bits 14-19 : A source register
bits 20-25 : B source register
bits 26-31 : C dest register

the size may be used later for the combine opcode,
but it's optional and will trap if /="00"

> [...8-bit adder...]
> > i gotta check it carefully, but thanks for the code,
> > it will certainly be reused all over the design.
> > Are wider adders possible ? thanks.
> Wider adders will need a second pipeline stage.
well, we can't do without...

> I hope to get away with
> 1/2 stage in the multiplier (I can split the 8-bit adder somewhere in
> the middle and combine the front part with the wallace tree).  The back
> end will probably be a 2:1 mux (carry-select adder).
good luck :-)

but i know that, in the fetcher for example, we need a rather large
adder. 32 bits will do the trick, 16 bits if otherwise impossible.

> [average instruction]
> > i've thought about it. This instruction is not much used in practice.
> > saturated arithmetics has more priority because the overhead in SW
> > is bigger than a single unconditional shift.
> It's more than a simple shift because the carry bit is preserved.
hmmmm..... let's see...

> > i'm still reserved about the average : it is used from time to time
> > in graphics (finding the center of a shape, for example) or sound
> > processing but i wonder if it's worth the added multiplexer.
> The `(a-b)/2' also has its uses.  I remember some numerical algorithms...
so, let's make it an optional opcode. you're now responsible of it ;-)

> > The manual is in constant development, so all comments are welcome.
> > practical examples are a must :-)
> >
> > Ok, i'll go back to the combine instructions, i'll test your last
> > code. BTW, i replaced UMAX/8 with MAXSIZE in the for-generate loop :-)
> > except that little detail, Michael's job is good and it works :-)
>
> *bow*

hey, you help the project, no ? :-)

ok, now let's see how the files get transferred...

btw, this is the latest version (superseedes the last files)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="ROP2vectors.out.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ROP2vectors.out.txt" Symphony EDA (R) VHDL Compiler/Simulator Module VhdlE, Version 1.4, Build#32. Copyright(C) Symphony EDA 1997-2000. All rights reserved. Reading d:\vhdl\simili\bin\symphony.ini ... Library 'ieee' ==> $SYMPHONY/Lib/Ieee/Ieee.sym Library 'work' ==> work.sym Reading work.sym\rop2_testbench\rop2_testbench.var Reading work.sym\eu_rop2\eu_rop2.var Reading work.sym\fcpu_config\fcpu_config(body).var Reading $SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_1164\std_logic_1164(body).var Reading $SYMPHONY\Lib\Ieee\Ieee.sym\numeric_std\numeric_std(body).var Reading $SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_textio\std_logic_textio(body).var Reading work.sym\rop2_testbench\rop2_testbench(test).var Reading work.sym\eu_rop2\eu_rop2(arch1).var # of Signals = 609 # of Components = 1 # of Processes = 21 # of Drivers = 394 Design Load/Elaboration Elapsed Time: 00h:00m:01s:355ms *** decoding line #1 * cycle # : 1 ROP2 function:0 Din_A=0011001100110011 Din_B=0101010101010101 Dout=0001000100010001 *** decoding line #2 * cycle # : 2 ROP2 function:1 Din_A=0011001100110011 Din_B=0101010101010101 Dout=0010001000100010 *** decoding line #3 * cycle # : 3 ROP2 function:2 Din_A=0011001100110011 Din_B=0101010101010101 Dout=0110011001100110 *** decoding line #4 * cycle # : 4 ROP2 function:3 Din_A=0011001100110011 Din_B=0101010101010101 Dout=0111011101110111 *** decoding line #5 * cycle # : 5 ROP2 function:4 Din_A=0011001100110011 Din_B=0101010101010101 Dout=FEEEFEEEFEEEFEEE *** decoding line #6 * cycle # : 6 ROP2 function:5 Din_A=0011001100110011 Din_B=0101010101010101 Dout=FEEFFEEFFEEFFEEF *** decoding line #7 * cycle # : 7 ROP2 function:6 Din_A=0011001100110011 Din_B=0101010101010101 Dout=FEFFFEFFFEFFFEFF *** decoding line #8 * cycle # : 8 ROP2 function:7 Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFEFFFEFFFEFFFE *** decoding line #9 * cycle # : 9 ROP2 function:0 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #10 * cycle # : 10 ROP2 function:1 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #11 * cycle # : 11 ROP2 function:2 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #12 * cycle # : 12 ROP2 function:3 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #13 * cycle # : 13 ROP2 function:4 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #14 * cycle # : 14 ROP2 function:5 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=0000000000000000 *** decoding line #15 * cycle # : 15 ROP2 function:6 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=00FF00FF00FF00FF *** decoding line #16 * cycle # : 16 ROP2 function:7 Combine : AND Din_A=0011001100110011 Din_B=0101010101010101 Dout=FF00FF00FF00FF00 *** decoding line #17 * cycle # : 17 ROP2 function:0 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=00FF00FF00FF00FF *** decoding line #18 * cycle # : 18 ROP2 function:1 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=00FF00FF00FF00FF *** decoding line #19 * cycle # : 19 ROP2 function:2 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #20 * cycle # : 20 ROP2 function:3 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #21 * cycle # : 21 ROP2 function:4 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #22 * cycle # : 22 ROP2 function:5 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #23 * cycle # : 23 ROP2 function:6 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #24 * cycle # : 24 ROP2 function:7 Combine : OR Din_A=0011001100110011 Din_B=0101010101010101 Dout=FFFFFFFFFFFFFFFF *** decoding line #25 ### End of vector file ###. Simulation stopped at: 240 ns Simulation Elapsed Time: 00h:00m:00s:096ms --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="ROP2vectors.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ROP2vectors.txt" A0011001100110011,B0101010101010101,F0 F1 F2 F3 F4 F5 F6 F7 D,F0; anD (combine mode) D,F1 D,F2 D,F3 D,F4 D,F5 D,F6 D,F7 O,F0; Or (combine mode) O,F1 O,F2 O,F3 O,F4 O,F5 O,F6 O,F7 Q >From the F-CPU manual : opcode real code Function Symbolic name 000 0001 A AND B AND 001 0010 A AND /B ANDN 010 0110 A XOR B XOR 111 0111 A OR B OR 100 1000 A NOR B NOR 101 1001 A XNOR B XNOR 110 1101 A OR /B ORN 111 1110 A NAND B NAND --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="ROP2.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ROP2.vhdl" -------------------------------------------------------------------------- -- ROP2.vhdl - ROP2 Execution Unit for the F-CPU -- Copyright (C) 2000 Yann GUIDON (whygee@f-cpu.org) -- -- v0.2: Michael Riepe reorganized the main for-generate loop -- v0.3: YG replaced UMAX/8 with MAXSIZE :-) -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- -------------------------------------------------------------------------- -- This is the first version ever for this unit. -- It should be easily synthetizable but there is no proof yet. -- What matters most today is that it compiles and behaves correctly. -- Warning : this code is and should remain purely combinatorial, -- there is no latching here, it must be done at another level. -- Furthermore, the function lookup table should be moved earlier -- in the pipeline, in parallel with the Xbar cycle. -- Finally, only byte combines are possible. The COMBINE -- instruction is still not completely re-defined. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; LIBRARY work; USE work.FCPU_config.ALL; Entity EU_ROP2 is port( Din_A, Din_B : in F_VECTOR; -- the 2 operands ROP_function : in Std_ulogic_vector(2 downto 0); -- 3 function bits Combine_AND, Combine_OR : in Std_ulogic; -- additional funtion Combine_size : in Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. Dout : out F_VECTOR -- the result ); end EU_ROP2; Architecture arch1 of EU_ROP2 is signal partial_result, partial_OR, partial_AND : F_VECTOR; -- the partial results. signal local_function : Std_ulogic_vector(3 downto 0); -- the local, decoded, function bits. begin -- 1 : lookup table that decodes the function bits -- (should be done in an earlier stage) with ROP_function select local_function <= "0001" when "000", -- AND "0010" when "001", -- ANDN "0110" when "010", -- XOR "0111" when "011", -- OR "1000" when "100", -- NOR "1001" when "101", -- XNOR "1011" when "110", -- ORN "1110" when others; -- NAND -- 2 : the ROP2 operator itself. partial_result <= ((not Din_A) and (not Din_B) and (F_RANGE => local_function(3))) or ((not Din_A) and ( Din_B) and (F_RANGE => local_function(2))) or (( Din_A) and (not Din_B) and (F_RANGE => local_function(1))) or (( Din_A) and ( Din_B) and (F_RANGE => local_function(0))); -- 3 : partial ORs and ANDs on the byte chuncks : BYTE_COMBINE : for i in MAXSIZE-1 downto 0 generate partial_OR(8*i+7 downto 8*i) <= "11111111" when partial_result(8*i+7 downto 8*i) /= "00000000" else "00000000"; partial_AND(8*i+7 downto 8*i) <= "11111111" when partial_result(8*i+7 downto 8*i) = "11111111" else "00000000"; -- I'm still uncertain about the best way to write a multi-size version. -- Plus, the latency might explode the ROP2 unit's performance. -- So the multi-size version is dropped until it becomes necessary. -- Let's stick to plain bytes... end generate BYTE_COMBINE; -- 4 : final selection stage : Dout <= partial_OR when (Combine_OR = '1') else partial_AND when (Combine_AND = '1') else partial_result; end; --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="ROP2_testbench.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ROP2_testbench.vhdl" -------------------------------------------------------------------------- -- ROP2_testbench.vhdl : ROP2's tesbench for the F-CPU project -- Copyright (C) 2000 Yann GUIDON (whygee@f-cpu.org) 10/22/2000@20h -- -- This file is adapted from the file testbench_template.vhdl. -- -- v0.2 : YG cleaned the integer() cast then added support for testing -- the COMBINE instructions. -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- -------------------------------------------------------------------------- -- Only 3 commands are understood yet : A: set the data_in A bus, -- B: set the data_in B bus, F: set the ROP function. -- The combine functions and the rest are not yet tested. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_textio.all; USE ieee.numeric_std.all; LIBRARY std; USE std.textio.ALL; USE work.FCPU_config.ALL; -- the declaration of the design unit under test. USE work.EU_ROP2; entity ROP2_testbench is GENERIC( filename : string := "ROP2vectors.txt" -- name of the vector file ); end ROP2_testbench; architecture test of ROP2_testbench is -- Copy of the design's port declaration : signal Din_A, Din_B : F_VECTOR; -- the 2 operands signal ROP_function : Std_ulogic_vector(3 downto 0); -- 3 function bits signal Combine_AND, Combine_OR : Std_ulogic; -- additional funtion signal Combine_size : Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. signal Dout : F_VECTOR; -- the result -- internal counter : shared variable cycle : natural :=0; shared variable lout : line ; procedure print is begin WRITE(lout,"* cycle # : "); WRITE(lout,cycle); -- print all the signals here : WRITE(lout," ROP2 function:"); HWRITE(lout,ROP_function); if (Combine_AND='1') then WRITE(lout," Combine : AND"); else if (Combine_OR='1') then WRITE(lout," Combine : OR"); end if; end if; WRITELINE(OUTPUT, lout); WRITE(lout," Din_A="); HWRITE(lout,Din_A); WRITELINE(OUTPUT, lout); WRITE(lout," Din_B="); HWRITE(lout,Din_B); WRITELINE(OUTPUT, lout); WRITE(lout," Dout="); HWRITE(lout,Dout); WRITELINE(OUTPUT, lout); end; -- For a dumb parser in VHDL : shared variable temp_char : Character := NUL; -- parsed character shared variable buff : line; -- line from which we parse shared variable line_number : natural:=0; shared variable i : natural; -- index in buff procedure getch is -- "read()" does not have "unread()"... begin temp_char:=buff(i); i:=i+1; end; -- warning !!! no overflow checks !!! function get_hexa(s:Std_ulogic_vector) return Std_ulogic_vector is variable t:Std_ulogic_vector(3 downto 0):=(others=>'0'); variable u:Std_ulogic_vector(s'high downto 0):=(others=>'0'); begin hexa_loop : while i<=buff'high loop getch; case temp_char is when '0' => t:=X"0"; when '1' => t:=X"1"; when '2' => t:=X"2"; when '3' => t:=X"3"; when '4' => t:=X"4"; when '5' => t:=X"5"; when '6' => t:=X"6"; when '7' => t:=X"7"; when '8' => t:=X"8"; when '9' => t:=X"9"; when 'A' => t:=X"A"; when 'B' => t:=X"B"; when 'C' => t:=X"C"; when 'D' => t:=X"D"; when 'E' => t:=X"E"; when 'F' => t:=X"F"; when 'a' => t:=X"A"; when 'b' => t:=X"B"; when 'c' => t:=X"C"; when 'd' => t:=X"D"; when 'e' => t:=X"E"; when 'f' => t:=X"F"; when others => i:=i-1; return u; end case; -- shift left : u(u'high downto 4):=u((u'high)-4 downto 0); u(3 downto 0):=t; end loop; -- exits here only if EOL : return u; end; begin -- Instantiate the tested circuit ROP2_instance : entity EU_ROP2 port map( Din_A => Din_A, Din_B => Din_B, ROP_function => ROP_function(2 downto 0), Combine_AND => Combine_AND, Combine_OR => Combine_OR, Combine_size => Combine_size, Dout => Dout ); -- the testbench routine : process file test_vector : TEXT OPEN READ_MODE IS filename; variable temp_OR,temp_AND : Std_ulogic:='0'; begin -- simulation body : while (not endfile(test_vector)) loop -- init temps : temp_AND:='0'; temp_OR:='0'; -- read one vector line from the file : readline(test_vector,buff); line_number:=line_number+1; write(lout,"*** decoding line #"); write(lout,line_number); writeline(output,lout); If buff'length/=0 then -- parsing "buff" here ... i:=1; parse_loop: while i<=buff'high loop getch; case temp_char is when ';' => -- it's a comment exit parse_loop; when 'Q' => write(lout,LF&" ### End of vector file ###."&LF); writeline(output,lout); wait; -- warning : no redundancy checks. when 'A' => -- set Din_A Din_A<=get_hexa(Din_A); when 'B' => -- set Din_B Din_B<=get_hexa(Din_B); when 'F' => -- set the function ROP_function<=get_hexa(ROP_function); when 'O' => -- combine OR if (temp_AND or temp_OR)/='0' then write(lout,"Warning : multiple COMBINE in vector !"&BEL); else temp_OR:='1'; end if; when 'D' => -- combine AND if (temp_AND or temp_OR)/='0' then write(lout,"Warning : multiple COMBINE in vector !"&BEL); else temp_AND:='1'; end if; when others => write(lout,LF&" # unknown command : "); write(lout,temp_char&LF); writeline(output,lout); end case; -- expect a coma/separator/EOL : if (i-1>=buff'High) then -- do not expect coma if already at end of line exit parse_loop; end if; getch; if (temp_char = ';') then exit parse_loop; end if; if (temp_char /= ',') then write(lout,"',' expected, got "); write(lout,temp_char); write(lout," instead"); writeline(output,lout); end if; end loop parse_loop; end if; -- void string -- perform the assignation : Combine_OR<=temp_OR; Combine_AND<=temp_AND; -- cycle : cycle:=cycle+1; -- advance the counter wait for 10 ns; -- let the circuit do the work print; -- be happy end loop; file_close(test_vector); wait; -- stop the simulation end process; end test; --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="testbench_template.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testbench_template.vhdl" DO _NOT_ COMPILE AS IS. -------------------------------------------------------------------------- -- testbench_template.vhdl : template for the F-CPU project -- Copyright (C) 2000 Yann GUIDON (whygee@f-cpu.org) 10/22/2000@20h -- -- Do not compile this file. It is only a template. -- Wherever needed, replace the letters EU with the Execution Unit's name. -- This file is adapted from the file Icache_testbench.vhdl. -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- -------------------------------------------------------------------------- -- This is an attempt to make a rather generic template for testing -- Execution Units. It reads an input file, parses a simple syntax -- that describes the test vectors, and outputs the result on the screen. -- It can be customised at will, the vector's syntax can be changed easily. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_textio.all; USE ieee.numeric_std.all; LIBRARY std; USE std.textio.ALL; USE work.FCPU_config.ALL; -- include here : the declaration of the tested design unit. USE work.EUdesign.ALL; entity EU_testbench is GENERIC( filename : string := "testvectors.txt" -- name of the vector file ); end EU_testbench; architecture test of EU_testbench is -- Copy of the design's port declaration, for example : signal din, dout, Address_write : Std_ulogic_vector(); signal reset, clk, Read_En, Write_En : Boolean:=false; -- internal counter : shared variable cycle : natural :=0; shared variable lout : line ; procedure print is begin WRITE(lout,"* cycle # : "); WRITE(lout,cycle); -- print all the signals here : if clk=true then WRITE(lout," clk"); end if; if reset=true then WRITE(lout," reset"); end if; if Read_En=true then WRITE(lout," Read_En:"); HWRITE(lout,Address_read); end if; if Write_En=true then WRITE(lout," Write_En:"); HWRITE(lout,Address_write); WRITE(lout," Din="); HWRITE(lout,Din); WRITELINE(OUTPUT, lout); end if; if Inv_En=true then WRITE(lout," Inv_En:"); HWRITE(lout,Address_read); WRITE(lout,", address_mask:"); HWRITE(lout,Address_Mask); end if; WRITELINE(OUTPUT, lout); end; -- For a dumb parser in VHDL : shared variable temp_char : Character := NUL; -- parsed character shared variable buff : line; -- line from which we parse shared variable line_number : natural:=0; shared variable i : natural; procedure getch is -- "read()" does not have "unread()"... begin temp_char:=buff(i); i:=i+1; end; -- warning !!! no overflow checks !!! function get_hexa(s:Std_ulogic_vector) return Std_ulogic_vector is variable t:Std_ulogic_vector(3 downto 0):=(others=>'0'); variable u:Std_ulogic_vector(s'high downto 0):=(others=>'0'); begin hexa_loop : while i<=buff'high loop getch; case temp_char is when '0' => t:=X"0"; when '1' => t:=X"1"; when '2' => t:=X"2"; when '3' => t:=X"3"; when '4' => t:=X"4"; when '5' => t:=X"5"; when '6' => t:=X"6"; when '7' => t:=X"7"; when '8' => t:=X"8"; when '9' => t:=X"9"; when 'A' => t:=X"A"; when 'B' => t:=X"B"; when 'C' => t:=X"C"; when 'D' => t:=X"D"; when 'E' => t:=X"E"; when 'F' => t:=X"F"; when 'a' => t:=X"A"; when 'b' => t:=X"B"; when 'c' => t:=X"C"; when 'd' => t:=X"D"; when 'e' => t:=X"E"; when 'f' => t:=X"F"; when others => i:=i-1; return u; end case; -- shift left : u(u'high downto 4):=u((u'high)-4 downto 0); u(3 downto 0):=t; end loop; -- exits here only if EOL : return u; end; begin -- Instantiate the tested circuit EU_instance : entity EU_type port map( Din => din, Dout => dout, clk => clk, reset => reset, Address_write => Address_write, Read_En => Read_En, Write_En => Write_En ); -- the testbench routine : process file test_vector : TEXT OPEN READ_MODE IS filename; variable temp_reset,temp_Read_En, temp_Write_En : boolean; begin -- init/reset (for sequential circuits) Din<=(others=>'0'); reset<=true; wait for 10 ns; reset<=false; wait for 10 ns; -- begin the simulation body : while (not endfile(test_vector)) loop -- init temp inputs : temp_reset:=false; -- read one vector line from the file : readline(test_vector,buff); line_number:=line_number+1; write(lout,"*** decoding line #"); write(lout,line_number); writeline(output,lout); If buff'length/=0 then -- parsing "buff" here ... i:=1; parse_loop: while i<=buff'high loop getch; case temp_char is when ';' => -- it's a comment exit parse_loop; when 'Q' => write(lout,LF&" ### End of vector file ###."&LF); writeline(output,lout); wait; when 'T' => if temp_reset=true then write(lout,"Warning : multiple Reset in vector !"&BEL); else temp_reset:=true; end if; when 'W' => if temp_Write_En=true then write(lout,"Warning : multiple Writes in vector !"&BEL); else Address_write<=get_hexa(Address_write); i:=i+1; -- correct the index, restore the character that has been already "eaten" if temp_char/=':' then report "expected ':' between address & data, not found"; end if; Din<=get_hexa(Din); temp_Write_En:=true; end if; when 'R' => if (temp_Freeze_En=true) then write(lout,"Warning : multiple Reads in vector !"&BEL); else Address_read<=get_hexa(Address_read); temp_Read_En:=true; end if; when others => write(lout,LF&" # unknown command : "); write(lout,temp_char&LF); end case; writeline(output,lout); -- expect a coma/separator/EOL : if (i-1>=buff'High) then -- do not expect coma if already at end of line exit parse_loop; end if; getch; if (temp_char = ';') then exit parse_loop; end if; if (temp_char /= ',') then write(lout,"',' expected, got "); write(lout,temp_char); write(lout," instead"); writeline(output,lout); end if; end loop parse_loop; end if; -- void string -- perform the assignation : reset<=temp_reset; Read_En<=temp_Read_En; Write_En<=temp_Write_En; -- cycle : clk<=true; -- rising edge cycle:=cycle+1; -- advance the counter wait for 10 ns; -- let the circuit do the work clk<=false; -- falling edge wait for 10 ns; -- leave some time to react print; -- be happy end loop; file_close(test_vector); wait; -- stop the simulation end process; end test; --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii; name="F-CPU_config.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="F-CPU_config.vhdl" -- File F-CPU_config.vhdl -- (c) Yann GUIDON, oct. 21, 2000 -- whygee@f-cpu.org / f-cpu@egroups.com -- -- v0.2 : Michael Riepe changed F_RANGE -- v0.3 : YG specified the user-modifiable constants + GPL -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. -- -- * MAXSIZE : Size of the registers in bytes. Can be -- any power of two >= 4. For example : 4, 8, 16, 32... -- This is the most important parameter, the first with -- which one can play. Be careful anyway. -- -- * L1LogLines : Log2 of the NumBer of cache Lines (MUST be EVEN) -- This parameter determines how many L1 cache lines are implemented. -- It must be >=4 and even because of the particular LRU mechanism -- used for this prototype. Allowed values are 4, 6 or 8 (that is : -- 16, 64 or 256 lines, or 512 bytes, 2KB or 8KB). More would correspond -- to a L2 cache... but are possible if you have enough ressources. -- -- * L1ABwidth :Address Bus width, in 32-byte chuncks (32+5=128GB) -- This determines the width of the address comparator of every L1 -- cache line. Be careful, too many bits might require a LOT of ressources. -- A reasonable value for a small design would be 16 (2MB of adressable -- physical memory), adapt as required. Warning : this parameter -- also determines how many address bits are physically implemented. -- -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ constant MAXSIZE : natural := 8; -- Size of the registers in bytes, any power of two >= 4. constant UMAX : natural := MAXSIZE * 8; -- Size of the registers in bits. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- Range of a register width declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; -- shortcut for a very common declaration. ------------------------------------------------------ -- Some architectural constants, bound to FC0 only : ------------------------------------------------------ -- L1 Caches (split instructions and data) constant L1DBwidth : natural := 256 ; -- Data Bus width, or width of each cache line (32 bytes) constant L1ABwidth : natural := 32 ; -- Address Bus width, in 32-byte chuncks (32+5=128GB) constant L1LogLines : natural := 6 ; -- Log2 of the NumBer of cache Lines (MUST be EVEN) constant L1NBlines : natural := 2**L1LogLines ; -- NumBer of cache Lines (2**L1LogLines) (small number for the first attempts) ------------------------------------------------------ -- The Special Registers : (copied from SR.h) -- -- What the user should modify when implementing the core : -- * SR_NUMBERS_val should be updated when the -- number of implemented SR changes. -- * SR_FAMILY_val specifies the type of core (FC0, FC1 etc). -- This is meant to be used for selecting particular code -- sections that are optimized for certain cores. -- * SR_STEPPING_val specifies the mask revision, for example. -- -- DO NOT MODIFY the other constants unless the specifications change. -- A set of "signature" SRs will appear soon. Stay tuned. ------------------------------------------------------ constant SR_NUMBERS : natural := 0; constant SR_NUMBERS_val : natural := 10; -- 10 SRs are implemented in this model constant SR_FAMILY : natural := 1; constant SR_FAMILY_val : natural := 4032; -- F-CPU core number. remark : 0xFC0 = 4032 :-) constant SR_STEPPING : natural := 2; constant SR_STEPPING_val : natural := 1; -- revision/implementation constant SR_MAX_SIZE : natural := 3; constant SR_MAX_SIZE_val : natural := MAXSIZE; -- in bytes, a power of two >= 4 constant SR_SIZE_1 : natural := 4; constant SR_SIZE_1_val : natural := 1; -- Size attribute 1, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_2 : natural := 5; constant SR_SIZE_2_val : natural := 2; -- Size attribute 2, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_3 : natural := 6; constant SR_SIZE_3_val : natural := 4; -- Size attribute 3, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_4 : natural := 7; constant SR_SIZE_4_val : natural := 8; -- Size attribute 4, hardwired if SR_MAX_SIZE <= 8 constant SR_CYCLE : natural := 8; -- R/W, Value is dynamic, incremented every cycle. constant SR_PAGING : natural := 9; -- Protected, R/W, Controls the paged memory. end FCPU_config; package body FCPU_config is ------------------------------------------------------ -- Empty. Only the constants matter until today. -- Some useful wrappers or functions could be included -- here if they are necessary for rest of the project. ------------------------------------------------------ end FCPU_config; --------------5E0FCD9120D47D2C21E7069A Content-Type: text/plain; charset=us-ascii;; charset=us-ascii; name="testROP2.bat" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testROP2.bat" rem testROP2.bat (c) whygee@f-cpu.org, 10/23/2000 rem This batch file uses an installed SIMILI distribution. vhdlp F-CPU_config.vhdl ROP2.vhdl ROP2_testbench.vhdl vhdle rop2_testbench>testROP2.out.txt rem If everything is ok (including the "dangling ACCESS" warning), please compare the two files testROP2.out.txt and ROP2vectors.out.txt --------------5E0FCD9120D47D2C21E7069A-- From Yann Guidon Mon Oct 23 06:51:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00393 for ; Mon, 23 Oct 2000 22:50:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:21 +0200 (MEST) Received: (qmail 4916 invoked by uid 0); 23 Oct 2000 03:49:34 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 23 Oct 2000 03:49:34 -0000 X-eGroups-Return: sentto-1101623-1258-972272940-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 23 Oct 2000 03:49:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 03:49:00 -0000 Received: (qmail 27528 invoked from network); 23 Oct 2000 03:47:02 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 Oct 2000 03:47:02 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 23 Oct 2000 03:47:01 -0000 Received: from f-cpu.org (nas1-243.aub.club-internet.fr [195.36.150.243]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA14740 for ; Mon, 23 Oct 2000 05:46:57 +0200 (MET DST) Message-ID: <39F3C3D4.B0259AA3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 05:51:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1fd999a97c397b954ddb2884aa72e4d9 Status: R X-Status: N hi :-)

Colin Marquardt wrote:
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
> > It can't, as far as I know.  At least not in Germany, because the
> > so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
> > give it away.
> Except if you do contract work for a company. Then they will own
> the copyright IIRC. But that is really nitpicking in that case. But
> maybe the Verein could hire you? :-)

i don't know. i don't remember how the FSF dealt with this case.
but hiring is probably not the good solution.

> Colin
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Oct 23 07:18:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00396 for ; Mon, 23 Oct 2000 22:50:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:22 +0200 (MEST) Received: (qmail 20983 invoked by uid 0); 23 Oct 2000 04:14:33 -0000 Received: from hk.egroups.com (208.50.99.220) by mx12.rz2.gmx.net with SMTP; 23 Oct 2000 04:14:33 -0000 X-eGroups-Return: sentto-1101623-1260-972274469-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 23 Oct 2000 04:14:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 04:14:25 -0000 Received: (qmail 8055 invoked from network); 23 Oct 2000 04:14:25 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 23 Oct 2000 04:14:25 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 23 Oct 2000 04:14:24 -0000 Received: from f-cpu.org (nas1-130.ras.club-internet.fr [195.36.192.130]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA29506 for ; Mon, 23 Oct 2000 06:14:22 +0200 (MET DST) Message-ID: <39F3CA3A.FC5999EF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 06:18:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d330c86864d26878253180380830a345 Status: R X-Status: N post-scriptum (a posteriori)

Michael Riepe wrote:
> > > I think you got the opcode decoder wrong; see my corrected version.
> > "opcode decoder" ? i don't see where. Is it the lookup table in front
> > of the ROP2 unit ?
> Yep, that's it.
i didn't remark any change in the syntax of this lookup table, curiously.
Can you give a better syntax ?

>  BTW: we only have 4 bits left for function selection
> in the opcode according to the manual.  Where can we put the Combine_AND
> and Combine_OR bits?  And where the NOT function (it's missing)?

the NOT instruction is "NOT" needed :-P
you can either use XNOR r1,r0,r2
or ANDN r1,r0,r2 to put not(r1) into r2.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE, tired too. but happy of the good working job he has done tonight ;-P
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PS: finally, better broke, unemployed and f-pcuing around, rather
than rich, employed and not having any time for myself :-PPP
eGroups Sponsor
From Nicolas Matringe Mon Oct 23 09:10:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00402 for ; Mon, 23 Oct 2000 22:50:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:23 +0200 (MEST) Received: (qmail 23747 invoked by uid 0); 23 Oct 2000 07:09:42 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 23 Oct 2000 07:09:42 -0000 X-eGroups-Return: sentto-1101623-1261-972284979-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 23 Oct 2000 07:09:40 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 07:09:39 -0000 Received: (qmail 16859 invoked from network); 23 Oct 2000 07:09:38 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Oct 2000 07:09:38 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 23 Oct 2000 07:09:38 -0000 Received: from IPricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA26243 for ; Mon, 23 Oct 2000 07:09:37 GMT X-To: Message-ID: <39F3E453.56C0F8E1@IPricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: fcpu From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 09:10:11 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: CPU Design HOWTO v2.0 - To design, test and manufacture CPUs] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 24efdb66e16ef03dba93dd7fae02c10e Status: R X-Status: N

-------- Original Message --------
Objet: CPU Design HOWTO v2.0 - To design, test and manufacture CPUs
Date: Sat, 21 Oct 2000 19:42:49 GMT
De: Al Dev <alavoor@yahoo.com>
R=E9pondre-A: alavoor@yahoo.com
Soci=E9t=E9: Road Runner - Texas
Forums: comp.arch.fpga,comp.lang.vhdl

Hello:

The CPU Design HOWTO version 2.0 is released.  This document  giv= es a
bird's eyeview on
design, test and manufacturing of CPUs.
It is located at http://www.aldev.8m.co= m or at http://aldev.webjump.com


Bookmark this url and circulate to your friends..

Let me know suggestions and I will add those..

al dev
eGroups Sponsor=
3D""
From Yann Guidon Mon Oct 23 10:44:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00412 for ; Mon, 23 Oct 2000 22:50:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:25 +0200 (MEST) Received: (qmail 25723 invoked by uid 0); 23 Oct 2000 09:31:29 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 23 Oct 2000 09:31:29 -0000 X-eGroups-Return: sentto-1101623-1262-972293479-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 23 Oct 2000 09:31:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 09:31:18 -0000 Received: (qmail 25769 invoked from network); 23 Oct 2000 09:31:18 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 23 Oct 2000 09:31:18 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 23 Oct 2000 09:31:18 -0000 Received: from f-cpu.org (nas2-217.ras.club-internet.fr [195.36.192.217]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA23993 for ; Mon, 23 Oct 2000 09:39:37 +0200 (MET DST) Message-ID: <39F3FA61.24B0FB29@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F3E453.56C0F8E1@IPricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 09:44:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] [Fwd: CPU Design HOWTO v2.0 - To design, test and manufacture CPUs] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dba5a57492020a642d9a09f670caec6a Status: R X-Status: N hi !

i've seen it some hours ago...

funny, not big, but i hope that it will grow.
it's redundant with the reading of the opencollector database, too :-)

Nicolas Matringe wrote:
> Forums: comp.arch.fpga,comp.lang.vhdl
>
> Hello:
>
> The CPU Design HOWTO version 2.0 is released.  This document  gives a
> bird's eyeview on
> design, test and manufacturing of CPUs.
> It is located at http://www.aldev.8m.com or at http://aldev.webjump.com
>
> Bookmark this url and circulate to your friends..
>
> Let me know suggestions and I will add those..
>
> al dev
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Mon Oct 23 06:08:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00446 for ; Mon, 23 Oct 2000 22:50:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:32 +0200 (MEST) Received: (qmail 26765 invoked by uid 0); 23 Oct 2000 13:32:14 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx01) with SMTP; 23 Oct 2000 13:32:14 -0000 X-eGroups-Return: sentto-1101623-1263-972307665-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 23 Oct 2000 13:28:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 13:27:43 -0000 Received: (qmail 2451 invoked from network); 23 Oct 2000 13:27:43 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 23 Oct 2000 13:27:43 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.167) by mta1 with SMTP; 23 Oct 2000 13:27:40 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA03456; Mon, 23 Oct 2000 06:08:24 +0200 Message-ID: <20001023060824.04639@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Sun, Oct 22, 2000 at 07:29:57PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 06:08:24 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 094946ec82e10d3e7d9a38647b32bd42 Status: R X-Status: N On Sun, Oct 22, 2000 at 07:29:57PM -0700, Colin Marquardt wrote:
> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> > It can't, as far as I know.  At least not in Germany, because the
> > so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
> > give it away.
>
> Except if you do contract work for a company. Then they will own
> the copyright IIRC. But that is really nitpicking in that case. But
> maybe the Verein could hire you? :-)

You're not officially speaking for `the Verein', are you? ;)

That might be an option.  But the question is: do I really want that?
And what if I don't?  The GPL already permits the Verein/association
to use, modify and redistribute my code; they don't need the copyright.

Another question is: will they use my code anyway?  The FSF says no.
You can't even send a 20-liner to them without signing a paper first,
and changing all copyright notices in your code to read `Copyright (C)
20xx Free Software Foundation'.  I don't like that attitude at all,
and even if there weren't the `legal incompatibility' with german law,
I wouldn't do that voluntarily.  Why should I?

I really like Free Software and the GPL.  I don't even mind not getting
paid for most software I write (well, sometimes I do, near the end
of the month ;).  But I want people to know who wrote the software
they use, just like they know who wrote the book they currently read
(Terry Pratchett, in case you wonder ;).  And yes, I also want the
F-CPU users-to-be to know that it wasn't made by some anonymous crowd,
but by certain well-known individuals who spent a lot of time and effort
on that project (and also had a lot of fun, but that's another story).

Note that I don't talk about fame or admiration here.  I don't want to
become another Linus Torvalds, Richard Stallman, Dennis Ritchie or Bill
(*yuck*) Gates -- too much publicity is bad for your health; ask a movie
star if you happen to meet one (you almost never meet them -- guess why?).
I want people to respect me and my work just like I respect them.
Nothing more, nothing less.

</rant useless="yes, absolutely, but I had to say this">

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Mon Oct 23 16:19:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00470 for ; Mon, 23 Oct 2000 22:50:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:39 +0200 (MEST) Received: (qmail 4537 invoked by uid 0); 23 Oct 2000 18:29:12 -0000 Received: from ck.egroups.com (208.50.144.69) by mx19.rz2.gmx.net with SMTP; 23 Oct 2000 18:29:12 -0000 X-eGroups-Return: sentto-1101623-1264-972325738-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 23 Oct 2000 18:29:08 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 18:28:57 -0000 Received: (qmail 8470 invoked from network); 23 Oct 2000 18:28:57 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 23 Oct 2000 18:28:57 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.95) by mta2 with SMTP; 23 Oct 2000 18:28:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00548; Mon, 23 Oct 2000 16:19:44 +0200 Message-ID: <20001023161944.18919@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3C3D2.BB13A05C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F3C3D2.BB13A05C@f-cpu.org>; from Yann Guidon on Mon, Oct 23, 2000 at 05:51:30AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 16:19:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e7281f1b42c1a1acbbee36f8b822a66 Status: R X-Status: N On Mon, Oct 23, 2000 at 05:51:30AM +0100, Yann Guidon wrote:

[attachment content-type]
> i've finally found a way. i hope that this one will work.
> Please tell me what you think.

Yep, it's perfect.  For the record: what did you do?

[...]
> but i know that, in the fetcher for example, we need a rather large
> adder. 32 bits will do the trick, 16 bits if otherwise impossible.

Wouldn't an incrementer be sufficient?

[...]

> >From the F-CPU manual :
>  opcode real code Function Symbolic name
>   000      0001   A AND B    AND
>   001      0010   A AND /B   ANDN
>   010      0110   A XOR B    XOR
>   111      0111   A OR B     OR
>   100      1000   A NOR B    NOR
>   101      1001   A XNOR B   XNOR
>   110      1101   A OR /B    ORN

Here's a bug: should be 1011.
It's already corrected in ROP2.vhdl.

>   111      1110   A NAND B   NAND

[...]
> -- File F-CPU_config.vhdl
[...]
> --  * MAXSIZE : Size of the registers in bytes. Can be
> --  any power of two >= 4. For example : 4, 8, 16, 32...
> --  This is the most important parameter, the first with
> --  which one can play. Be careful anyway.

Since this is a power of to, maybe we should write it that way:

      constant MAXSIZE : natural := 2 ** 3;

It may even be useful to define

      constant LOGMAXSIZE : natural := 3;
      constant MAXSIZE : natural := 2 ** LOGMAXSIZE;

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Mon Oct 23 15:55:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00473 for ; Mon, 23 Oct 2000 22:50:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:40 +0200 (MEST) Received: (qmail 12354 invoked by uid 0); 23 Oct 2000 18:40:25 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 23 Oct 2000 18:40:25 -0000 X-eGroups-Return: sentto-1101623-1265-972326422-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 23 Oct 2000 18:40:25 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 18:40:21 -0000 Received: (qmail 5123 invoked from network); 23 Oct 2000 18:29:04 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 Oct 2000 18:29:04 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.95) by mta2 with SMTP; 23 Oct 2000 18:29:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00493; Mon, 23 Oct 2000 15:55:52 +0200 Message-ID: <20001023155551.33470@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F3CA3A.FC5999EF@f-cpu.org>; from Yann Guidon on Mon, Oct 23, 2000 at 06:18:50AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 15:55:51 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e7ebc2434338dfc072ac691e5d6576a2 Status: R X-Status: N On Mon, Oct 23, 2000 at 06:18:50AM +0100, Yann Guidon wrote:
> post-scriptum (a posteriori)
>
> Michael Riepe wrote:
> > > > I think you got the opcode decoder wrong; see my corrected version.
> > > "opcode decoder" ? i don't see where. Is it the lookup table in front
> > > of the ROP2 unit ?
> > Yep, that's it.
> i didn't remark any change in the syntax of this lookup table, curiously.
> Can you give a better syntax ?

It's not the syntax -- the decoded bits were wrong.  It looked like
this:

      signal local_function : std_ulogic_vector(3 downto 0);
      ...
      local_function <= "0001";      -- AND
      ...
      partial_result <=
               (local_function(0) and not A and not B)
            or (local_function(1) and     A and not B)
            or (local_function(2) and not A and     B)
            or (local_function(3) and     A and     B);

Since local_function has a descending index range, local_function(0) is
'1' in this case, and partial_result becomes `not A and not B', but not
`A and B' as it should.

There also was a small bug in the decoder itself; the bit patterns for
ANDN and ORN were complementary ("0010" and "1101"), while the
operations themselves aren't -- `A and not B' equals `not(not A or B)',
not `not(A or not B)'.

> >  BTW: we only have 4 bits left for function selection
> > in the opcode according to the manual.  Where can we put the Combine_AND
> > and Combine_OR bits?  And where the NOT function (it's missing)?
>
> the NOT instruction is "NOT" needed :-P
> you can either use XNOR r1,r0,r2
> or ANDN r1,r0,r2 to put not(r1) into r2.

It's ugly, but it works :)

> PS: finally, better broke, unemployed and f-pcuing around, rather
> than rich, employed and not having any time for myself :-PPP

Good choice :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From "Richard E.Hartney" Mon Oct 23 21:58:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00476 for ; Mon, 23 Oct 2000 22:50:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Oct 2000 22:50:41 +0200 (MEST) Received: (qmail 6695 invoked by uid 0); 23 Oct 2000 19:57:00 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 23 Oct 2000 19:57:00 -0000 X-eGroups-Return: sentto-1101623-1266-972331016-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jk.egroups.com with NNFMP; 23 Oct 2000 19:56:52 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 19:56:54 -0000 Received: (qmail 22903 invoked from network); 23 Oct 2000 19:56:51 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Oct 2000 19:56:51 -0000 Received: from unknown (HELO mail0.lig.bellsouth.net) (205.152.0.90) by mta3 with SMTP; 23 Oct 2000 19:56:50 -0000 Received: from 0018728164 (host-209-214-154-102.bix.bellsouth.net [209.214.154.102]) by mail0.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id PAA20802; Mon, 23 Oct 2000 15:56:48 -0400 (EDT) Message-ID: <000c01c03d2b$9c6f45c0$669ad6d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 14:58:26 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Unsubscribe Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C03D01.B252B400" X-UIDL: cf155426f96e03a98867235a36757006 Status: R X-Status: N ------=_NextPart_000_0009_01C03D01.B252B400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shortly after I send this, I will unsubscribe from the F-CPU mail list. I = am reading nothing but pure jibberish.=20 Anyone interested in the ERIN32 progress may contact me at: rhartney@bellsouth.net ------=_NextPart_000_0009_01C03D01.B252B400 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Shortly after I send this, I will unsubscribe from the F-CPU mail list.  I am reading nothing but pure jibberish.
 
Anyone interested in the ERIN32 progress may contact me at:
                    rhartney@bellsouth.net

eGroups Sponsor
------=_NextPart_000_0009_01C03D01.B252B400-- From Berkane Tue Oct 24 00:46:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00333 for ; Tue, 24 Oct 2000 16:35:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:35:57 +0200 (MEST) Received: (qmail 28474 invoked by uid 0); 23 Oct 2000 22:44:02 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx01) with SMTP; 23 Oct 2000 22:44:02 -0000 X-eGroups-Return: sentto-1101623-1267-972341040-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 23 Oct 2000 22:44:01 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 22:43:58 -0000 Received: (qmail 21273 invoked from network); 23 Oct 2000 22:43:58 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 23 Oct 2000 22:43:58 -0000 Received: from unknown (HELO semeur.localdomain) (212.27.38.176) by mta3 with SMTP; 23 Oct 2000 22:43:56 -0000 Received: from infolibre.org (semeur.localdomain [127.0.0.1]) by semeur.localdomain (8.10.1/8.8.7) with ESMTP id e9NMkGY01535 for ; Tue, 24 Oct 2000 00:46:21 +0200 Sender: root@semeur.localdomain Message-ID: <39F4BFB8.A2787EBD@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <000c01c03d2b$9c6f45c0$669ad6d1@0018728164> X-eGroups-From: Berkane From: Berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 00:46:16 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a68a5ae92167d3ec0b05650d22fa1411 Status: R X-Status: N > "Richard E.Hartney" a =E9crit :
>
> Shortly after I send this, I will unsubscribe from the F-CPU mail
> list.  I am reading nothing but pure jibberish.
>
> Anyone interested in the ERIN32 progress may contact me at:
>            = ;         rhartney@bellsouth.net >
>            = ;           eGroups Spons= or
>


i'am interresting to unsubcribe
bye

--
---asdean@infolibre.org---
Member of infolibre.org
---http://www.infolibre.org
eGroups Sponsor=
3D""
From Yann Guidon Tue Oct 24 02:02:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00342 for ; Tue, 24 Oct 2000 16:36:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:36:09 +0200 (MEST) Received: (qmail 5562 invoked by uid 0); 23 Oct 2000 23:04:24 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 23 Oct 2000 23:04:24 -0000 X-eGroups-Return: sentto-1101623-1268-972341890-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 23 Oct 2000 22:58:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 22:58:09 -0000 Received: (qmail 32219 invoked from network); 23 Oct 2000 22:58:08 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Oct 2000 22:58:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 23 Oct 2000 22:58:08 -0000 Received: from f-cpu.org (nas1-202.aub.club-internet.fr [195.36.150.202]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA18254 for ; Tue, 24 Oct 2000 00:58:04 +0200 (MET DST) Message-ID: <39F4D19C.F727F494@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> <20001023155551.33470@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 01:02:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5ea79300ad4aa3e7661bfe3775fb12d0 Status: R X-Status: N hello :-)

Michael Riepe wrote:
> On Mon, Oct 23, 2000 at 06:18:50AM +0100, Yann Guidon wrote:
> > post-scriptum (a posteriori)
> > Michael Riepe wrote:
> > > > > I think you got the opcode decoder wrong; see my corrected version.
> > > > "opcode decoder" ? i don't see where. Is it the lookup table in front
> > > > of the ROP2 unit ?
> > > Yep, that's it.
> > i didn't remark any change in the syntax of this lookup table, curiously.
> > Can you give a better syntax ?
> It's not the syntax -- the decoded bits were wrong.  It looked like
> this:
>
>         signal local_function : std_ulogic_vector(3 downto 0);
>         ...
>         local_function <= "0001";       -- AND
>         ...
>         partial_result <=
>                    (local_function(0) and not A and not B)
>                 or (local_function(1) and     A and not B)
>                 or (local_function(2) and not A and     B)
>                 or (local_function(3) and     A and     B);
>
> Since local_function has a descending index range, local_function(0) is
> '1' in this case, and partial_result becomes `not A and not B', but not
> `A and B' as it should.

i corrected that bit at the second release, that was in a ZIP file.
but when i sent it, i received your corrected version too :-)

> There also was a small bug in the decoder itself; the bit patterns for
> ANDN and ORN were complementary ("0010" and "1101"), while the
> operations themselves aren't -- `A and not B' equals `not(not A or B)',
> not `not(A or not B)'.

i'm not sure to understand. i'll have to draw some schematics and tables
on paper to convince myself.

Anyway, here are two points :
- the ROP2 unit "seems" to work without trouble, which is already a Good Thing :-)
- there is this question : should we invert the B operand only, so the coding
is more consistent ? Or due to logic simplifications, we do
invert A and B in different places ? that is :
ANDN inverts the A operand
ORN inverts B
What will the programmer/compiler-writer think ?
I guess that a sane solution is to invert only one operand,
so we don't have to remember the conversion table.
OTOH the internal conversion table is less straight-forward
but it's not really complex either... a 3->4 decoder is
really easy to synthetise ;-)

Any remark ?

> > >  BTW: we only have 4 bits left for function selection
> > > in the opcode according to the manual.  Where can we put the Combine_AND
> > > and Combine_OR bits?  And where the NOT function (it's missing)?
> >
> > the NOT instruction is "NOT" needed :-P
> > you can either use XNOR r1,r0,r2
> > or ANDN r1,r0,r2 to put not(r1) into r2.
> It's ugly, but it works :)

Do you remember that MIPS does even more ugly ?
They code something like ADD r0,r0,rN to set rN to zero.


then :
Michael Riepe wrote:
> On Mon, Oct 23, 2000 at 05:51:30AM +0100, Yann Guidon wrote:
>
> [attachment content-type]
> > i've finally found a way. i hope that this one will work.
> > Please tell me what you think.
> Yep, it's perfect.  For the record: what did you do?
i just thrashed my register base in W95...

no, frankly, Netscape is not perfect, i know. It uses and
modifies the global attributes of the files. I had to remove
the attributes for VHD and VHDL, create a new one and copy/paste
>from other attributes (those found in plain texts for example).
I preferred the old way anyway, because i could manage the attachments
more easily. Now, it's less straight-forward to save a received file
to the HDD.


> [...]
> > but i know that, in the fetcher for example, we need a rather large
> > adder. 32 bits will do the trick, 16 bits if otherwise impossible.
> Wouldn't an incrementer be sufficient?
i guess. the fetcher, and some other parts, need incrementers, too.
i'll have to make an incrementer design soon.


> [...]
>
> > >From the F-CPU manual :
> >  opcode real code Function Symbolic name
> >   000      0001   A AND B    AND
> >   001      0010   A AND /B   ANDN
> >   010      0110   A XOR B    XOR
> >   111      0111   A OR B     OR
> >   100      1000   A NOR B    NOR
> >   101      1001   A XNOR B   XNOR
> >   110      1101   A OR /B    ORN
>
> Here's a bug: should be 1011.
> It's already corrected in ROP2.vhdl.
i'll check. but i'm still unsure.
thanks for pointing this out :-)

> >   111      1110   A NAND B   NAND
>
> [...]
> > -- File F-CPU_config.vhdl
> [...]
> > --  * MAXSIZE : Size of the registers in bytes. Can be
> > --  any power of two >= 4. For example : 4, 8, 16, 32...
> > --  This is the most important parameter, the first with
> > --  which one can play. Be careful anyway.
>
> Since this is a power of to, maybe we should write it that way:
>
>         constant MAXSIZE : natural := 2 ** 3;
>
> It may even be useful to define
>
>         constant LOGMAXSIZE : natural := 3;
>         constant MAXSIZE : natural := 2 ** LOGMAXSIZE;

useful for what ? as long as you respect this obvious rule,
there's no risk to expect :-)

We've thought about this case a long time ago, but this is only
useful in certain limited cases. If we go on this way, we have:

         constant LOGSIZE : natural := 1 ; -- any positive integer
         constant MAXSIZE : natural := 2 ** (LOGSIZE+2);

This LOGSIZE is used for example in 128+ bits architectures,
where we have to store and restore the attribute flags.

For the newcomers : the size attributes in the instructions
are hardwired for 32- and 64-bits arechitectures. They are specified
in the manual : the 2 bits corresponds to 8, 16, 32 and 64-bit operands.

When we have a 128-bit CPU, or any larger implementation, we can
reconfigure these bits so they can be any power of two, for example :
00  128-bits
01  256-bits
10  16-bits
11  8-bits

but when there is a task switch, it must be remembered for each task.
there is a "status register" ( name ?) that holds 3 or 4 bits for each,
so we can have very large implementations :
0000 8
0001 16
0010 32
0011 64
0100 128
0101 256
0110 512
0111 1024
1000 2048
1001 4096
1010 8192
1011 16384
1100 32768
1101 65536
1110 131072
1111 262144 (ok , it's enough ?)

now, this LOGSIZE would be a number from 0 to 15.
This is not useful yet, since we're only playing
in 64-bit land. it will be necessary in the future
but today we have more practical problems to solve,
isn't it ? :-)

> > PS: finally, better broke, unemployed and f-pcuing around, rather
> > than rich, employed and not having any time for myself :-PPP
> Good choice :)
yes, but who will give me money ? :-/

i'm a bit worried. There are several companies that want me to work
for them, but the job that interests me (with the "Big Toy")
is probably fading away. I would have signed one week ago, but nothing yet.
On top of that, i'm broke and i have muscular and nervous pains in the
back, the arms, the hand, the neck... Freedom is expensive, right ?

ok, let's go back to the VHDL files... the cache, certainly.
good night,

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Tue Oct 24 01:24:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00361 for ; Tue, 24 Oct 2000 16:36:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:36:25 +0200 (MEST) Received: (qmail 3211 invoked by uid 0); 23 Oct 2000 23:26:53 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 23 Oct 2000 23:26:53 -0000 X-eGroups-Return: sentto-1101623-1269-972343608-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 23 Oct 2000 23:26:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 23 Oct 2000 23:26:46 -0000 Received: (qmail 32183 invoked from network); 23 Oct 2000 23:25:06 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 23 Oct 2000 23:25:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.94) by mta1 with SMTP; 23 Oct 2000 23:25:04 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02157; Tue, 24 Oct 2000 01:24:59 +0200 Message-ID: <20001024012458.57039@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> <20001023155551.33470@thrai.stud.uni-hannover.de> <39F4D19C.F727F494@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F4D19C.F727F494@f-cpu.org>; from Yann Guidon on Tue, Oct 24, 2000 at 01:02:36AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 01:24:58 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c3b85f05442d4776c64235cbd0c6749e Status: R X-Status: N 'lo again!

On Tue, Oct 24, 2000 at 01:02:36AM +0100, Yann Guidon wrote:

[...]
> - there is this question : should we invert the B operand only, so the coding
> is more consistent ? Or due to logic simplifications, we do
> invert A and B in different places ? that is :
> ANDN inverts the A operand
> ORN inverts B
> What will the programmer/compiler-writer think ?

That the second operand is inverted in both cases, IMHO.
The naming suggests that it's `or not' and `and not'.

[...]
> > Wouldn't an incrementer be sufficient?
> i guess. the fetcher, and some other parts, need incrementers, too.
> i'll have to make an incrementer design soon.

I have one lying around somewhere, but it doesn't support SIMD and the
other fancy features of the INC EU (but the fetcher won't need them
anyway, right?).

[...]
> > It may even be useful to define
> >
> >         constant LOGMAXSIZE : natural := 3;
> >         constant MAXSIZE : natural := 2 ** LOGMAXSIZE;
>
> useful for what ? as long as you respect this obvious rule,
> there's no risk to expect :-)

Simply because I may want to do something like

      for i in 0 to LOGMAXSIZE generate
            ...
      end generate;

in the future, and I can't derive LOGMAXSIZE from MAXSIZE easily.
This may be useful for all tree-like structures -- you only have to
change the constant (and re-calculate the delays, of course) but the
code for a `wider' F-CPU implementation is already there.

Good night,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Tue Oct 24 04:18:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00364 for ; Tue, 24 Oct 2000 16:36:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:36:30 +0200 (MEST) Received: (qmail 13625 invoked by uid 0); 24 Oct 2000 01:15:51 -0000 Received: from mk.egroups.com (208.50.144.76) by mx19.rz2.gmx.net with SMTP; 24 Oct 2000 01:15:51 -0000 X-eGroups-Return: sentto-1101623-1270-972350131-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 24 Oct 2000 01:15:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 01:15:31 -0000 Received: (qmail 15572 invoked from network); 24 Oct 2000 01:13:50 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 Oct 2000 01:13:50 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 24 Oct 2000 01:13:50 -0000 Received: from f-cpu.org (nas4-156.aub.club-internet.fr [195.36.145.156]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA26782; Tue, 24 Oct 2000 03:13:46 +0200 (MET DST) Message-ID: <39F4F172.1D510127@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com Cc: hardlicense-discuss@seul.org References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> <20001023060824.04639@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 03:18:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 48e61dab083b2e99ac418eac86e49401 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Oct 22, 2000 at 07:29:57PM -0700, Colin Marquardt wrote:
> > * Michael Riepe <michael@stud.uni-hannover.de> writes:
> > > It can't, as far as I know.  At least not in Germany, because the
> > > so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
> > > give it away.
> > Except if you do contract work for a company. Then they will own
> > the copyright IIRC. But that is really nitpicking in that case. But
> > maybe the Verein could hire you? :-)
> You're not officially speaking for `the Verein', are you? ;)
hehe ;-)

> That might be an option.  But the question is: do I really want that?
> And what if I don't?  The GPL already permits the Verein/association
> to use, modify and redistribute my code; they don't need the copyright.
what we want to solve is : how can we enforce our rights ?
Of course, everyone's free will must be respected.

> Another question is: will they use my code anyway?  The FSF says no.
> You can't even send a 20-liner to them without signing a paper first,
> and changing all copyright notices in your code to read `Copyright (C)
> 20xx Free Software Foundation'.  I don't like that attitude at all,
> and even if there weren't the `legal incompatibility' with german law,
> I wouldn't do that voluntarily.  Why should I?
that's your choice and i guess that everybody can respect it :-)
OTOH copyright law is pretty bizarre. Remember the DeCSS trial ?
Now the problem is : how do we protect 1) ourselves 2) the F-CPU project.
What the FSF/GNU project do is to scatter the copyrights :
"divide to reign". it gives more inertia.

Idea : Every file contains the usual copyright notice, date and name,
plus the mention : "for use only in the F-CPU project". is it a good idea ?
Copyright law allows it, is it compatible with the GPL ?

> I really like Free Software and the GPL.  I don't even mind not getting
> paid for most software I write (well, sometimes I do, near the end
> of the month ;).  But I want people to know who wrote the software
> they use, just like they know who wrote the book they currently read
> (Terry Pratchett, in case you wonder ;).  And yes, I also want the
> F-CPU users-to-be to know that it wasn't made by some anonymous crowd,
> but by certain well-known individuals who spent a lot of time and effort
> on that project (and also had a lot of fun, but that's another story).
I understand. it makes the project look more human, too.

> Note that I don't talk about fame or admiration here.  I don't want to
> become another Linus Torvalds, Richard Stallman, Dennis Ritchie or Bill
> (*yuck*) Gates -- too much publicity is bad for your health; ask a movie
> star if you happen to meet one (you almost never meet them -- guess why?).
> I want people to respect me and my work just like I respect them.
> Nothing more, nothing less.
yo :-) If it was for the money, you wouldn't be here anyway ;-)

> </rant useless="yes, absolutely, but I had to say this">
of course. can this discussion go to the hardlicense-discuss@seul.org
mailing list ? there are more people there who can answer our questions.


Now i've finished the Icache SRAM array, i'm moving
to the infrastructure. The LRU unit will be made at the last time.
stay tuned.


have fun,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Rares Marian Tue Oct 24 05:47:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00388 for ; Tue, 24 Oct 2000 16:36:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:36:47 +0200 (MEST) Received: (qmail 28220 invoked by uid 0); 24 Oct 2000 03:48:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx19.rz2.gmx.net with SMTP; 24 Oct 2000 03:48:32 -0000 X-eGroups-Return: sentto-1101623-1271-972359304-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hl.egroups.com with NNFMP; 24 Oct 2000 03:48:25 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 03:48:23 -0000 Received: (qmail 8853 invoked from network); 24 Oct 2000 03:48:22 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 24 Oct 2000 03:48:22 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 24 Oct 2000 03:48:22 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id CAD892F5815 for ; Mon, 23 Oct 2000 23:47:40 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <39F4BFB8.A2787EBD@infolibre.org> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Oct 2000 23:47:40 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Unsubscribe Content-Type: text/plain; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-UIDL: e6a8c6306a57666f5e5b9c1c05847569 Status: R X-Status: N On Tue, 24 Oct 2000, Berkane wrote: > > "Richard E.Hartney" a écrit : > > > > Shortly after I send this, I will unsubscribe from the F-CPU mail > > list. I am reading nothing but pure jibberish. > > > > Anyone interested in the ERIN32 progress may contact me at: > > rhartney@bellsouth.net > > > > eGroups Sponsor > > > > > i'am interresting to unsubcribe > bye > > Should we just add a subject that says "Hot Chicks" or "IRS Audit Please Respond" to get people to read? Rares (from his newly setup debian system) -- Pine Is Not Elm. Thank God Almighty. -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/15/_/3462/_/972359304/ ---------------------------------------------------------------------_-> From Colin Marquardt Tue Oct 24 05:54:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00391 for ; Tue, 24 Oct 2000 16:36:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:36:53 +0200 (MEST) Received: (qmail 16085 invoked by uid 0); 24 Oct 2000 03:49:41 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 24 Oct 2000 03:49:41 -0000 X-eGroups-Return: sentto-1101623-1272-972359377-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 24 Oct 2000 03:49:40 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 03:49:36 -0000 Received: (qmail 25360 invoked from network); 24 Oct 2000 03:49:36 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 24 Oct 2000 03:49:36 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 24 Oct 2000 03:49:35 -0000 Received: from morphin.marquardt-home.de (d28.nas22.sonic.net [209.204.137.28]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA20956 for ; Tue, 24 Oct 2000 05:49:32 +0200 (MET DST) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13nvA3-0000OR-00 for ; Mon, 23 Oct 2000 20:54:03 -0700 To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> <20001023060824.04639@thrai.stud.uni-hannover.de> X-Now-Playing: Silent Cry's Goddes Of Tears - Desire Of Dreams In-Reply-To: Michael Riepe's message of "Mon, 23 Oct 2000 06:08:24 +0200" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 53 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 23 Oct 2000 20:54:02 -0700 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 06167d0ed133a91b0efd1799d5f4d250 Status: R X-Status: N * Michael Riepe <michael@stud.uni-hannover.de> writes:

> On Sun, Oct 22, 2000 at 07:29:57PM -0700, Colin Marquardt wrote:
>> * Michael Riepe <michael@stud.uni-hannover.de> writes:
>>
>> > It can't, as far as I know.  At least not in Germany, because the
>> > so-called `Urheberrecht' is not transferable.  Whatever I do, I can not
>> > give it away.
>>
>> Except if you do contract work for a company. Then they will own
>> the copyright IIRC. But that is really nitpicking in that case. But
>> maybe the Verein could hire you? :-)

> You're not officially speaking for `the Verein', are you? ;)

No, of course not.

> Another question is: will they use my code anyway?  The FSF says no.
> You can't even send a 20-liner to them without signing a paper first,

And that paper has to have a signature from your employer also. They
must disclaim any rights in your code.

This is also something for Yann to consider when choosing the
employer. Bring the assignment paper to the first interview :-)
(you don't have to assign any copyrights after that, just make sure
you can if you want).

I might have to do this myself should I want to see a bit of my Lisp
code in emacs...

> and changing all copyright notices in your code to read `Copyright (C)
> 20xx Free Software Foundation'.  I don't like that attitude at all,
> and even if there weren't the `legal incompatibility' with german law,
> I wouldn't do that voluntarily.  Why should I?

You can still be recognized as the author while having assigned the
copyright to the FSF. I see it more like "please, FSF, be my defender
in a possible lawsuit". But let's not make a discussion out of that.

> F-CPU users-to-be to know that it wasn't made by some anonymous crowd,
> but by certain well-known individuals who spent a lot of time and effort
> on that project (and also had a lot of fun, but that's another story).

Things like that could polish up your resume tremendously.

> (*yuck*) Gates -- too much publicity is bad for your health; ask a movie
> star if you happen to meet one (you almost never meet them -- guess why?).

*I* was in a "movie" already! ;-)

Cheers,
  Colin
eGroups Sponsor
From Yann Guidon Tue Oct 24 07:14:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00394 for ; Tue, 24 Oct 2000 16:37:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:37:03 +0200 (MEST) Received: (qmail 24627 invoked by uid 0); 24 Oct 2000 04:10:04 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 24 Oct 2000 04:10:04 -0000 X-eGroups-Return: sentto-1101623-1273-972360600-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 24 Oct 2000 04:10:01 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 04:09:59 -0000 Received: (qmail 52723 invoked from network); 24 Oct 2000 04:09:59 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 24 Oct 2000 04:09:58 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 24 Oct 2000 04:09:58 -0000 Received: from f-cpu.org (nas3-92.aub.club-internet.fr [195.36.145.92]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA14888 for ; Tue, 24 Oct 2000 06:09:55 +0200 (MET DST) Message-ID: <39F51ABD.CDFD1EF3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> <20001023155551.33470@thrai.stud.uni-hannover.de> <39F4D19C.F727F494@f-cpu.org> <20001024012458.57039@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 06:14:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 437e09dae5c763d925d770d659fb080e Status: R X-Status: N Michael Riepe wrote:
> 'lo again!
'mojn,

> On Tue, Oct 24, 2000 at 01:02:36AM +0100, Yann Guidon wrote:
> [...]
> > - there is this question : should we invert the B operand only, so the coding
> > is more consistent ? Or due to logic simplifications, we do
> > invert A and B in different places ? that is :
> > ANDN inverts the A operand
> > ORN inverts B
> > What will the programmer/compiler-writer think ?
>
> That the second operand is inverted in both cases, IMHO.
> The naming suggests that it's `or not' and `and not'.

"2B ORN 2B ?" :-)

well, if the naming suggests that the second operand is negated, so be it.

> [...]
> > > Wouldn't an incrementer be sufficient?
> > i guess. the fetcher, and some other parts, need incrementers, too.
> > i'll have to make an incrementer design soon.
> I have one lying around somewhere, but it doesn't support SIMD and the
> other fancy features of the INC EU (but the fetcher won't need them
> anyway, right?).
The INC EU is rather particular, i have some particular ideas about it.
but a normal incrementer (32-bits for example) would be interesting.

> [...]
> > > It may even be useful to define
> > >
> > >         constant LOGMAXSIZE : natural := 3;
> > >         constant MAXSIZE : natural := 2 ** LOGMAXSIZE;
> >
> > useful for what ? as long as you respect this obvious rule,
> > there's no risk to expect :-)
>
> Simply because I may want to do something like
>
>         for i in 0 to LOGMAXSIZE generate
>                 ...
>         end generate;
>
> in the future, and I can't derive LOGMAXSIZE from MAXSIZE easily.
> This may be useful for all tree-like structures -- you only have to
> change the constant (and re-calculate the delays, of course) but the
> code for a `wider' F-CPU implementation is already there.

right.


my work for a rather synthesisable Icache is rather messy.
i'm doing the address tag comparator and i find awful stuffs.
i'll clean it up tomorrow.


ok, i'm waiting for your update of the F-CPU_config.vhdl file.

> Good night,
sleep well,

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Rares Marian Tue Oct 24 06:30:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00397 for ; Tue, 24 Oct 2000 16:37:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:37:10 +0200 (MEST) Received: (qmail 32536 invoked by uid 0); 24 Oct 2000 04:30:53 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 24 Oct 2000 04:30:53 -0000 X-eGroups-Return: sentto-1101623-1274-972361848-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 24 Oct 2000 04:30:51 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 04:30:47 -0000 Received: (qmail 20181 invoked from network); 24 Oct 2000 04:30:46 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 24 Oct 2000 04:30:46 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 24 Oct 2000 04:30:46 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 427CF2F5815 for ; Tue, 24 Oct 2000 00:30:05 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <39F51ABD.CDFD1EF3@f-cpu.org> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 00:30:05 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ae9710a7cbfc5efd2e1810f4643dcb82 Status: R X-Status: N On Tue, 24 Oct 2000, Yann Guidon wrote:

> Michael Riepe wrote:
> > 'lo again!
> 'mojn,
>
> > On Tue, Oct 24, 2000 at 01:02:36AM +0100, Yann Guidon wrote:
> > [...]
> > > - there is this question : should we invert the B operand only, so the coding
> > > is more consistent ? Or due to logic simplifications, we do
> > > invert A and B in different places ? that is :
> > > ANDN inverts the A operand
> > > ORN inverts B
> > > What will the programmer/compiler-writer think ?
> >
> > That the second operand is inverted in both cases, IMHO.
> > The naming suggests that it's `or not' and `and not'.
>
> "2B ORN 2B ?" :-)
>
> well, if the naming suggests that the second operand is negated, so be it.

I want the opposite of the OR op.  I want to be able to think terms of
construction at the CPU.  Don't you damn tell me what YOU think it does.

If I wanted A or not B I would do it in two operations.  There's going to
be designs where the splitting of logic into millions of little bits
requires that I be able to express what I mean not what the CPU does.

Rares
--
Pine Is Not Elm.  Thank God Almighty.
eGroups Sponsor
From Yann Guidon Tue Oct 24 09:53:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00403 for ; Tue, 24 Oct 2000 16:37:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:37:21 +0200 (MEST) Received: (qmail 32388 invoked by uid 0); 24 Oct 2000 06:48:40 -0000 Received: from fl.egroups.com (64.209.169.106) by mx0.gmx.net with SMTP; 24 Oct 2000 06:48:40 -0000 X-eGroups-Return: sentto-1101623-1275-972370116-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 24 Oct 2000 06:48:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 06:48:35 -0000 Received: (qmail 18412 invoked from network); 24 Oct 2000 06:48:35 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 24 Oct 2000 06:48:35 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 24 Oct 2000 06:48:34 -0000 Received: from f-cpu.org (nas4-110.ras.club-internet.fr [195.36.203.110]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA27101 for ; Tue, 24 Oct 2000 08:48:31 +0200 (MET DST) Message-ID: <39F53FEA.14CF1E4F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 08:53:14 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (v) Icache address tag comparator Content-Type: multipart/mixed; boundary="------------D7FE7A90A83463C9AB00B890" X-UIDL: b4b3dad537fb87e2503a388dd04345a1 Status: R X-Status: N --------------D7FE7A90A83463C9AB00B890 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

here is the ugly code i have made tonight.
Simili swallows it but it's awful anyway.
If anyone can enhance it, making it suitable
for most common synthesizers, it will be helpful.

When it will be ready, i'll be able to work on the
LRU stack. I've found an incredible way to make
recursive port maps in a book that i've bought.
It gives an interesting alternative to the usual
for-generate loop, without requiring to compute
a logarithm explicitly :-P

ok, have fun and comment.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------D7FE7A90A83463C9AB00B890 Content-Type: text/plain; charset=us-ascii; name="Icache_addrtags.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Icache_addrtags.vhdl" -------------------------------------------------------------------- -- Icache_addr_tags.vhdl : the address tags of the FC0's Icache. -- created by Yann Guidon, oct. 24, 2000 (4am) for the F-CPU project -- First attempt at a +/- synthesisable version. Compiled/simulated -- with Simili. NOT YET synthetized. GPL applies. Now you're warned. -------------------------------------------------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -------------------------------------------------------------------- -- warning : this is still an unclocked version. it will be pipelined -- soon. library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use work.FCPU_config.all; ENTITY Addr_tags_type IS PORT( Clk, Inv_En, Reset, Read_En, Write_En, Freeze_En : IN Boolean; Address_read, Address_write, Address_Mask : IN Std_ulogic_vector(L1ABwidth-1 downto 0); Write_signal : IN Std_ulogic_vector(L1NBlines-1 downto 0); Icache_hit : OUT Boolean; Read_signal : OUT Std_ulogic_vector(L1NBlines-1 downto 0) ); END Addr_tags_type; Architecture Addr_tags1 of Addr_tags_type IS -- The "valid" bit for every tag line : signal tag_valid : Std_ulogic_vector(L1NBlines-1 downto 0) := (others=>'0'); -- the address tags themselves : type tag_array_type is array (L1NBlines-1 downto 0) of Std_ulogic_vector(L1ABwidth-1 downto 0); signal tag_array : tag_array_type; -- uninitialized : the valid tag does the job instead. -- Internal signal that says that the address matches : signal addr_match : Std_ulogic_vector(L1NBlines-1 downto 0) := (others=>'0'); constant zero : Std_ulogic_vector(L1NBlines-1 downto 0) := (others=>'0'); -- ugly, ugly ! begin -- cache hit : Icache_hit <= true when (addr_match /= zero) else false; -- open collector or hiZ trick here ? -- FOR each comparator : tag_generate : for index_tag in L1NBlines-1 downto 0 generate -- compare the addresses : addr_match(index_tag)<='1' when (Address_read=tag_array(index_tag)) and (tag_valid(index_tag)='1') else '0'; -- read operation : Read_signal(index_tag)<='1' when (addr_match(index_tag)='1') and (Read_En=true) else '0'; -- invalidation (without mask...) and reset tag_valid(index_tag)<='0' when ((reset=true) or ((addr_match(index_tag)='1') and (Inv_En=true))) -- reset the flag / normally, it should be a R/S cell (??timing??) -- Write an address tag : (set the R/S) else '1' when ((Write_signal(index_tag)='1') and (Write_En=true)) -- beware of the clocking ... else tag_valid(index_tag); tag_array(index_tag)<=Address_write when ((Write_signal(index_tag)='1') and (Write_En=true)); -- beware of the clocking ... -- help, the conditions are similar, should i make a process ? end generate tag_generate; end Addr_tags1; --------------D7FE7A90A83463C9AB00B890-- From Yann Guidon Tue Oct 24 12:39:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00436 for ; Tue, 24 Oct 2000 16:37:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 16:37:58 +0200 (MEST) Received: (qmail 16953 invoked by uid 0); 24 Oct 2000 09:35:05 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 24 Oct 2000 09:35:05 -0000 X-eGroups-Return: sentto-1101623-1276-972380100-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hj.egroups.com with NNFMP; 24 Oct 2000 09:35:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 09:34:59 -0000 Received: (qmail 3387 invoked from network); 24 Oct 2000 09:34:59 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 24 Oct 2000 09:34:59 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 24 Oct 2000 09:34:58 -0000 Received: from f-cpu.org (nas1-133.ras.club-internet.fr [195.36.192.133]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA13496 for ; Tue, 24 Oct 2000 11:34:55 +0200 (MET DST) Message-ID: <39F566EA.F810570E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 11:39:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cce6fef798bee718bbf9adf87a8821eb Status: R X-Status: N hi !

Rares Marian wrote:
> > "2B ORN 2B ?" :-)
> >
> > well, if the naming suggests that the second operand is negated, so be it.
>
> I want the opposite of the OR op.  I want to be able to think terms of
> construction at the CPU.  Don't you damn tell me what YOU think it does.
>
> If I wanted A or not B I would do it in two operations.  There's going to
> be designs where the splitting of logic into millions of little bits
> requires that I be able to express what I mean not what the CPU does.

isn't it the work of the compiler ? There are some good logic minimization
algorithms out there today... i know it for sure, i've made researches
in this field :-) and believe me or not, ROP2 helps. If you are happy
with only AND, OR, ANDN and XOR, buy/use a PC. if you want to do serious
logic operations, it's not enough. If you don't care at all, use a
high-level langage. If you don't like these instructions, you're not
forced to use them. If you have a better idea, just speak about it :-)

have fun,
> Rares
> --
> Pine Is Not Elm.  Thank God Almighty.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jeff Davies Tue Oct 24 12:00:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00647 for ; Tue, 24 Oct 2000 17:24:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 24 Oct 2000 17:24:43 +0200 (MEST) Received: (qmail 9675 invoked by uid 0); 24 Oct 2000 10:04:09 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net with SMTP; 24 Oct 2000 10:04:09 -0000 X-eGroups-Return: sentto-1101623-1277-972381846-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 24 Oct 2000 10:04:07 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 10:04:05 -0000 Received: (qmail 77424 invoked from network); 24 Oct 2000 10:04:05 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 24 Oct 2000 10:04:05 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta2 with SMTP; 24 Oct 2000 10:04:05 -0000 Received: from modem-31.titanium.dialup.pol.co.uk ([62.136.21.31] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13o0w7-00039E-00 for f-cpu@egroups.com; Tue, 24 Oct 2000 11:04:03 +0100 Message-ID: <39F55DC1.A81A7FA7@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <000c01c03d2b$9c6f45c0$669ad6d1@0018728164> <39F4BFB8.A2787EBD@infolibre.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 11:00:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d88e038b7756f673e9629224db66e343 Status: R X-Status: N Go to www.egroups.com/group/f-cpu
There you will find how to unsubscribe

Berkane wrote:

> > "Richard E.Hartney" a =E9crit :
> >
> > Shortly after I send this, I will unsubscribe from the F-CPU mail=
> > list.  I am reading nothing but pure jibberish.
> >
> > Anyone interested in the ERIN32 progress may contact me at:
> >           =           rhartney@bellsouth.n= et
> >
> >           =             eGroups = Sponsor
> >
>
> i'am interresting to unsubcribe
> bye
>
> --
> ---asdean@infolibre.org---
> Member of infolibre.org
> ---http://www.infolibre.org >
eGroups Sponsor=
3D""
From Michael Riepe Tue Oct 24 15:47:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00620 for ; Fri, 28 Jul 2000 00:56:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:23 +0200 (MEST) Received: (qmail 24516 invoked by uid 0); 24 Oct 2000 17:16:03 -0000 Received: from fg.egroups.com (208.50.144.70) by mx19.rz2.gmx.net with SMTP; 24 Oct 2000 17:16:03 -0000 X-eGroups-Return: sentto-1101623-1278-972407745-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 24 Oct 2000 17:15:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 17:15:43 -0000 Received: (qmail 36709 invoked from network); 24 Oct 2000 17:15:26 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 24 Oct 2000 17:15:26 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta3 with SMTP; 24 Oct 2000 17:15:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00678; Tue, 24 Oct 2000 15:47:12 +0200 Message-ID: <20001024154712.50867@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F53FEA.14CF1E4F@f-cpu.org>; from Yann Guidon on Tue, Oct 24, 2000 at 08:53:14AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 15:47:12 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e8fdc66b56752e02743cfdffa5c37e15 Status: R X-Status: N On Tue, Oct 24, 2000 at 08:53:14AM +0100, Yann Guidon wrote:

> When it will be ready, i'll be able to work on the
> LRU stack. I've found an incredible way to make
> recursive port maps in a book that i've bought.
> It gives an interesting alternative to the usual
> for-generate loop, without requiring to compute
> a logarithm explicitly :-P

I tried something similar (an entity that instantiated smaller versions
of itself), but that didn't work with Simili :(  Maybe I have to use
VHDL'87 `component' syntax instead of '93 syntax.

[...]
> -- cache hit :
>   Icache_hit <= true
>     when (addr_match /= zero)
>     else false;   -- open collector or hiZ trick here ?

Since Icache_hit is a boolean:

      Icache_hit <= addr_match /= zero;

I see no reason for OC/OD or HiZ here (and boolean doesn't support them
anyway).

[...]
> -- invalidation (without mask...) and reset
>     tag_valid(index_tag)<='0' when ((reset=true) or ((addr_match(index_tag)='1') and (Inv_En=true))) -- reset the flag / normally, it should be a R/S cell (??timing??)
> -- Write an address tag : (set the R/S)
>       else '1' when ((Write_signal(index_tag)='1') and (Write_En=true)) -- beware of the clocking ...
>       else tag_valid(index_tag);

tag_valid(index_tag) driving itself (sometimes)?

>     tag_array(index_tag)<=Address_write
>       when ((Write_signal(index_tag)='1') and (Write_En=true)); -- beware of the clocking ...
> -- help, the conditions are similar, should i make a process ?

You already did ;)  Each signal assignment:

      signal <= value;

is equivalent to a process:

      process (signals used in `value')
      begin
            signal <= value;
      end process;

I would do it like this:

      process (reset, Inv_En, Write_En)
      -- becomes `process (reset, clock)' later...
      begin
            if reset then
                  tag_valid <= (others => '0');
            else      -- becomes `elsif rising_edge(clock)' later...
                  if Inv_En then
                        for i in tag_valid'range loop
                              if addr_match(i) = '1' then
                                    tag_valid(i) <= '0';
                              end if;
                        end loop;
                  end if;
                  -- Possible conflict if both operations select the same line.
                  -- In that case, the write takes precedence (for that line)
                  -- because its signal assignment to tag_valid(i) comes last.
                  -- Swap the if blocks if you want things to work vice versa.
                  if Write_En then
                        for i in tag_valid'range loop
                              if Write_signal(i) = '1' then
                                    tag_valid(i) <= '1';
                                    tag_array(i) <= Address_write;
                              end if;
                        end loop;
                  end if;
            end if;
      end process;

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Oct 24 14:59:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00623 for ; Fri, 28 Jul 2000 00:56:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:25 +0200 (MEST) Received: (qmail 3646 invoked by uid 0); 24 Oct 2000 17:18:51 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 24 Oct 2000 17:18:51 -0000 X-eGroups-Return: sentto-1101623-1279-972407862-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 24 Oct 2000 17:18:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 17:17:40 -0000 Received: (qmail 41052 invoked from network); 24 Oct 2000 17:16:23 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 24 Oct 2000 17:16:23 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta3 with SMTP; 24 Oct 2000 17:16:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00574; Tue, 24 Oct 2000 14:59:24 +0200 Message-ID: <20001024145924.48831@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F51ABD.CDFD1EF3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: ; from Rares Marian on Tue, Oct 24, 2000 at 12:30:05AM -0400 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 14:59:24 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 971b267414ff46631e783b85dafaeaee Status: R X-Status: N On Tue, Oct 24, 2000 at 12:30:05AM -0400, Rares Marian wrote:

> I want the opposite of the OR op.  I want to be able to think terms of
> construction at the CPU.  Don't you damn tell me what YOU think it does.

Please tell me: what exactly is `the opposite of the OR op'?  We already
have a complete set of logical binary operators (there are only 10
of them).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Tue Oct 24 14:38:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00626 for ; Fri, 28 Jul 2000 00:56:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:25 +0200 (MEST) Received: (qmail 21337 invoked by uid 0); 24 Oct 2000 17:19:19 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net with SMTP; 24 Oct 2000 17:19:19 -0000 X-eGroups-Return: sentto-1101623-1280-972407942-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 24 Oct 2000 17:19:12 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 17:19:01 -0000 Received: (qmail 11364 invoked from network); 24 Oct 2000 17:16:37 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Oct 2000 17:16:37 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta3 with SMTP; 24 Oct 2000 17:16:35 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00513; Tue, 24 Oct 2000 14:38:44 +0200 Message-ID: <20001024143844.12441@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F1E243.75B4F49C@f-cpu.org> <20001022015254.18810@thrai.stud.uni-hannover.de> <39F24A7C.10435967@f-cpu.org> <20001022150110.44698@thrai.stud.uni-hannover.de> <39F37221.A83E9E76@f-cpu.org> <20001023040254.42136@thrai.stud.uni-hannover.de> <20001023060824.04639@thrai.stud.uni-hannover.de> <39F4F172.1D510127@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F4F172.1D510127@f-cpu.org>; from Yann Guidon on Tue, Oct 24, 2000 at 03:18:26AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 14:38:44 +0200 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2443d2d04985fe3c93e6273c9f7b9ca8 Status: R X-Status: N On Tue, Oct 24, 2000 at 03:18:26AM +0100, Yann Guidon wrote:
[...]
> Idea : Every file contains the usual copyright notice, date and name,
> plus the mention : "for use only in the F-CPU project". is it a good idea ?
> Copyright law allows it, is it compatible with the GPL ?

IMHO it's incompatible with the spirit of the GPL.  Free ****ware means
that *everybody* can use it.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Oct 24 14:53:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00629 for ; Fri, 28 Jul 2000 00:56:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:26 +0200 (MEST) Received: (qmail 28281 invoked by uid 0); 24 Oct 2000 17:21:25 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx01) with SMTP; 24 Oct 2000 17:21:25 -0000 X-eGroups-Return: sentto-1101623-1281-972407981-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 24 Oct 2000 17:21:19 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 17:19:40 -0000 Received: (qmail 11017 invoked from network); 24 Oct 2000 17:16:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Oct 2000 17:16:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.232) by mta3 with SMTP; 24 Oct 2000 17:16:31 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00556; Tue, 24 Oct 2000 14:53:25 +0200 Message-ID: <20001024145325.57558@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> <20001023155551.33470@thrai.stud.uni-hannover.de> <39F4D19C.F727F494@f-cpu.org> <20001024012458.57039@thrai.stud.uni-hannover.de> <39F51ABD.CDFD1EF3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F51ABD.CDFD1EF3@f-cpu.org>; from Yann Guidon on Tue, Oct 24, 2000 at 06:14:37AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 14:53:25 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: multipart/mixed; boundary="B8fVQJ5HfG6fxhi0" X-UIDL: 3b7ca303512ec55abdbbacb06327e93a Status: R X-Status: N --B8fVQJ5HfG6fxhi0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, Oct 24, 2000 at 06:14:37AM +0100, Yann Guidon wrote:

> "2B ORN 2B ?" :-)

That is, of course, the question.  The answer was 42, IIRC ;)

[...]
> The INC EU is rather particular, i have some particular ideas about it.

Would you mind sharing them with us?

> but a normal incrementer (32-bits for example) would be interesting.

See the attachment below.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--B8fVQJ5HfG6fxhi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="inc.vhdl" -- inc.vhdl -- F-CPU Simple Increment Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: inc.vhdl,v 1.2 2000/10/24 00:39:25 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity Inc is generic ( WIDTH : natural := 64 -- do not change! ); port ( -- input A : in std_ulogic_vector(WIDTH-1 downto 0); -- output Y : out std_ulogic_vector(WIDTH-1 downto 0) ); end Inc; architecture Arch_1 of Inc is signal B, G : std_ulogic_vector(WIDTH-1 downto 0); signal C, D : std_ulogic_vector(WIDTH/4-1 downto 0); signal E, F : std_ulogic_vector(WIDTH/16-1 downto 0); begin -- d=1 level1 : for i in 0 to WIDTH/4-1 generate B(4*i+0) <= '1'; B(4*i+1) <= A(4*i+0); B(4*i+2) <= A(4*i+0) and A(4*i+1); B(4*i+3) <= A(4*i+0) and A(4*i+1) and A(4*i+2); C(i) <= A(4*i+0) and A(4*i+1) and A(4*i+2) and A(4*i+3); end generate; -- d=2 level2 : for i in 0 to WIDTH/16-1 generate D(4*i+0) <= '1'; D(4*i+1) <= C(4*i+0); D(4*i+2) <= C(4*i+0) and C(4*i+1); D(4*i+3) <= C(4*i+0) and C(4*i+1) and C(4*i+2); E(i) <= C(4*i+0) and C(4*i+1) and C(4*i+2) and C(4*i+3); end generate; -- d=3 level3 : for i in 0 to WIDTH/64-1 generate F(4*i+0) <= '1'; F(4*i+1) <= E(4*i+0); F(4*i+2) <= E(4*i+0) and E(4*i+1); F(4*i+3) <= E(4*i+0) and E(4*i+1) and E(4*i+2); end generate; -- d=4 level4 : for i in 0 to WIDTH-1 generate G(i) <= B(i) and D(i/4) and F(i/16); end generate; -- d=5 Y <= A xor G; end Arch_1; -- vi: set ts=4 sw=4 : please --B8fVQJ5HfG6fxhi0-- From Rares Marian Tue Oct 24 19:33:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00632 for ; Fri, 28 Jul 2000 00:56:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:27 +0200 (MEST) Received: (qmail 24631 invoked by uid 0); 24 Oct 2000 17:35:08 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx01) with SMTP; 24 Oct 2000 17:35:08 -0000 X-eGroups-Return: sentto-1101623-1282-972408878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 24 Oct 2000 17:34:55 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 17:34:37 -0000 Received: (qmail 21939 invoked from network); 24 Oct 2000 17:34:14 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 24 Oct 2000 17:34:14 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 24 Oct 2000 17:34:13 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 3F64E2F5801 for ; Tue, 24 Oct 2000 13:33:36 -0400 (EDT) To: f-cpu@egroups.com In-Reply-To: <20001024143844.12441@thrai.stud.uni-hannover.de> Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 13:33:36 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 606bfc1d5c85386bc2be697a801e59b1 Status: R X-Status: N On Tue, 24 Oct 2000, Michael Riepe wrote:

> On Tue, Oct 24, 2000 at 03:18:26AM +0100, Yann Guidon wrote:
> [...]
> > Idea : Every file contains the usual copyright notice, date and name,
> > plus the mention : "for use only in the F-CPU project". is it a good idea ?
> > Copyright law allows it, is it compatible with the GPL ?
>
> IMHO it's incompatible with the spirit of the GPL.  Free ****ware means
> that *everybody* can use it.

I agree.  There's no reason to exclude.  Let people take advantage of the
GPL and they'll be coming back for more and they will pay for good
designs.  It's going to end up costing them more if they want to only copy
and not innovate.

Rares

>
>

--
Pine Is Not Elm.  Thank God Almighty.
eGroups Sponsor
From Yann Guidon Wed Oct 25 00:49:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00653 for ; Fri, 28 Jul 2000 00:56:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:32 +0200 (MEST) Received: (qmail 6043 invoked by uid 0); 24 Oct 2000 21:45:16 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net with SMTP; 24 Oct 2000 21:45:16 -0000 X-eGroups-Return: sentto-1101623-1283-972423912-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c9.egroups.com with NNFMP; 24 Oct 2000 21:45:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 21:45:10 -0000 Received: (qmail 2924 invoked from network); 24 Oct 2000 21:45:10 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 24 Oct 2000 21:45:10 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 24 Oct 2000 21:45:09 -0000 Received: from f-cpu.org (nas4-137.aub.club-internet.fr [195.36.145.137]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA24325 for ; Tue, 24 Oct 2000 23:45:01 +0200 (MET DST) Message-ID: <39F61208.6E3670DC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 23:49:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Verein/association (was : Re: [f-cpu] test, comments and question) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 65a4e9820481e7da612069841eacf822 Status: R X-Status: N hi !

Rares Marian wrote:
> On Tue, 24 Oct 2000, Michael Riepe wrote:
> > On Tue, Oct 24, 2000 at 03:18:26AM +0100, Yann Guidon wrote:
> > [...]
> > > Idea : Every file contains the usual copyright notice, date and name,
> > > plus the mention : "for use only in the F-CPU project". is it a good idea ?
> > > Copyright law allows it, is it compatible with the GPL ?
> >
> > IMHO it's incompatible with the spirit of the GPL.  Free ****ware means
> > that *everybody* can use it.
>
> I agree.  There's no reason to exclude.  Let people take advantage of the
> GPL and they'll be coming back for more and they will pay for good
> designs.  It's going to end up costing them more if they want to only copy
> and not innovate.

so, how can we "protect" the project ? what are our legal rights
and what to do when they are infringed ?

> Rares
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 25 00:49:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00656 for ; Fri, 28 Jul 2000 00:56:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:33 +0200 (MEST) Received: (qmail 20861 invoked by uid 0); 24 Oct 2000 21:46:45 -0000 Received: from fl.egroups.com (64.209.169.106) by mx12.rz2.gmx.net with SMTP; 24 Oct 2000 21:46:45 -0000 X-eGroups-Return: sentto-1101623-1284-972423993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 24 Oct 2000 21:46:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 21:46:32 -0000 Received: (qmail 77849 invoked from network); 24 Oct 2000 21:45:00 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 24 Oct 2000 21:45:00 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 24 Oct 2000 21:44:59 -0000 Received: from f-cpu.org (nas4-137.aub.club-internet.fr [195.36.145.137]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA18111 for ; Tue, 24 Oct 2000 23:34:40 +0200 (MET DST) Message-ID: <39F61203.5F17A1CD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F254F6.26A6E4D7@f-cpu.org> <20001022191151.07140@thrai.stud.uni-hannover.de> <39F37220.F6D39EFC@f-cpu.org> <20001023035618.11817@thrai.stud.uni-hannover.de> <39F3CA3A.FC5999EF@f-cpu.org> <20001023155551.33470@thrai.stud.uni-hannover.de> <39F4D19C.F727F494@f-cpu.org> <20001024012458.57039@thrai.stud.uni-hannover.de> <39F51ABD.CDFD1EF3@f-cpu.org> <20001024145325.57558@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 24 Oct 2000 23:49:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) F-CPU configuration file Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 22d091aa1eb94323db2be0e70b066ae7 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Tue, Oct 24, 2000 at 06:14:37AM +0100, Yann Guidon wrote:
> > "2B ORN 2B ?" :-)
> That is, of course, the question.  The answer was 42, IIRC ;)
:-)

> [...]
> > The INC EU is rather particular, i have some particular ideas about it.
> Would you mind sharing them with us?
huh, finally, it's something similar to what you just sent :-/
we can't invent everything all the time...

> > but a normal incrementer (32-bits for example) would be interesting.
> See the attachment below.
yup. that's +/- what i imagined.

thanks !
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 25 02:10:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00668 for ; Fri, 28 Jul 2000 00:56:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:36 +0200 (MEST) Received: (qmail 7690 invoked by uid 0); 24 Oct 2000 23:06:18 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 24 Oct 2000 23:06:18 -0000 X-eGroups-Return: sentto-1101623-1285-972428765-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ei.egroups.com with NNFMP; 24 Oct 2000 23:06:20 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 23:06:05 -0000 Received: (qmail 10476 invoked from network); 24 Oct 2000 23:06:05 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 24 Oct 2000 23:06:05 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 24 Oct 2000 23:06:04 -0000 Received: from f-cpu.org (nas3-31.ras.club-internet.fr [195.36.203.31]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA21393 for ; Wed, 25 Oct 2000 01:06:01 +0200 (MET DST) Message-ID: <39F62504.84BAD2A6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 01:10:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3bc76d9450bbe9e691c9f241c8720c2c Status: R X-Status: N hi again,

Michael Riepe wrote:
> On Tue, Oct 24, 2000 at 08:53:14AM +0100, Yann Guidon wrote:
> > When it will be ready, i'll be able to work on the
> > LRU stack. I've found an incredible way to make
> > recursive port maps in a book that i've bought.
> > It gives an interesting alternative to the usual
> > for-generate loop, without requiring to compute
> > a logarithm explicitly :-P
>
> I tried something similar (an entity that instantiated smaller versions
> of itself), but that didn't work with Simili :(  Maybe I have to use
> VHDL'87 `component' syntax instead of '93 syntax.

i sent a mail to Haneef (Simili's designer) about this.
he usually answers within 24 hours.

> [...]
> > -- cache hit :
> >   Icache_hit <= true
> >     when (addr_match /= zero)
> >     else false;   -- open collector or hiZ trick here ?
> Since Icache_hit is a boolean:
>         Icache_hit <= addr_match /= zero;

damnit, am i dumb... or tired ?

> I see no reason for OC/OD or HiZ here (and boolean doesn't support them
> anyway).
right. OC is slower than a CMOS AND anyway.


> [...]
> tag_valid(index_tag) driving itself (sometimes)?
i "just" wanted to make a R/S latch...

maybe i should make an entity for the R/S latch ? dunno.

> >     tag_array(index_tag)<=Address_write
> >       when ((Write_signal(index_tag)='1') and (Write_En=true)); -- beware of the clocking ...
> > -- help, the conditions are similar, should i make a process ?
>
> You already did ;)  Each signal assignment:
>
>         signal <= value;
>
> is equivalent to a process:
>
>         process (signals used in `value')
>         begin
>                 signal <= value;
>         end process;

IIRC Alliance (ASIME's) doesn't support processes so i tried not to use them...
[even though Alliance doesn't support a LOT of things...)

> I would do it like this:
>
>         process (reset, Inv_En, Write_En)
>         -- becomes `process (reset, clock)' later...
>         begin
>                 if reset then
>                         tag_valid <= (others => '0');
>                 else    -- becomes `elsif rising_edge(clock)' later...
>                         if Inv_En then
>                                 for i in tag_valid'range loop
>                                         if addr_match(i) = '1' then
>                                                 tag_valid(i) <= '0';
>                                         end if;
>                                 end loop;
>                         end if;
>                         -- Possible conflict if both operations select the same line.
>                         -- In that case, the write takes precedence (for that line)
>                         -- because its signal assignment to tag_valid(i) comes last.
>                         -- Swap the if blocks if you want things to work vice versa.
>                         if Write_En then
>                                 for i in tag_valid'range loop
>                                         if Write_signal(i) = '1' then
>                                                 tag_valid(i) <= '1';
>                                                 tag_array(i) <= Address_write;
>                                         end if;
>                                 end loop;
>                         end if;
>                 end if;
>         end process;
>

thanks,
have you compiled it ?

i'll cleanup my files ASAP and check your code carefully.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Wed Oct 25 01:42:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00671 for ; Fri, 28 Jul 2000 00:56:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:37 +0200 (MEST) Received: (qmail 27386 invoked by uid 0); 24 Oct 2000 23:43:36 -0000 Received: from fg.egroups.com (208.50.144.70) by mx12.rz2.gmx.net with SMTP; 24 Oct 2000 23:43:36 -0000 X-eGroups-Return: sentto-1101623-1286-972430947-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fg.egroups.com with NNFMP; 24 Oct 2000 23:42:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 24 Oct 2000 23:42:26 -0000 Received: (qmail 4393 invoked from network); 24 Oct 2000 23:42:26 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 24 Oct 2000 23:42:26 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.220) by mta1 with SMTP; 24 Oct 2000 23:42:25 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02647; Wed, 25 Oct 2000 01:42:21 +0200 Message-ID: <20001025014221.26941@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> <39F62504.84BAD2A6@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F62504.84BAD2A6@f-cpu.org>; from Yann Guidon on Wed, Oct 25, 2000 at 01:10:44AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 01:42:21 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 691d1585addd1f722b4bbf854113e0fb Status: R X-Status: N On Wed, Oct 25, 2000 at 01:10:44AM +0100, Yann Guidon wrote:

[...]
> > tag_valid(index_tag) driving itself (sometimes)?
> i "just" wanted to make a R/S latch...
>
> maybe i should make an entity for the R/S latch ? dunno.

That would be an option, if you don't want to use a process.

> > I would do it like this:
[code removed]
> thanks,
> have you compiled it ?

No, that was a quick hack while I was writing the reply.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Wed Oct 25 03:35:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00674 for ; Fri, 28 Jul 2000 00:56:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:38 +0200 (MEST) Received: (qmail 21443 invoked by uid 0); 25 Oct 2000 00:31:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 25 Oct 2000 00:31:29 -0000 X-eGroups-Return: sentto-1101623-1287-972433878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ck.egroups.com with NNFMP; 25 Oct 2000 00:31:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_1_0); 25 Oct 2000 00:31:18 -0000 Received: (qmail 3160 invoked from network); 25 Oct 2000 00:31:17 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 25 Oct 2000 00:31:17 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 25 Oct 2000 00:31:17 -0000 Received: from f-cpu.org (nas1-133.ras.club-internet.fr [195.36.192.133]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA24280 for ; Wed, 25 Oct 2000 02:31:14 +0200 (MET DST) Message-ID: <39F638FC.B551881C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 02:35:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 03568aecdec04e3c900391674a1c01f0 Status: R X-Status: N other comments :

Michael Riepe wrote:
> [...]
> tag_valid(index_tag) driving itself (sometimes)?
since i want it to act like a R/S cell, we could simply write our R/S cell ?

-- internal state :
signal RS_Q  : std_ulogic_vector (anyrange)  :=(others=>'0');
signal RS_Qb : std_ulogic_vector (samerange) :=(others=>'1'); -- we can initialize the R/S this way
-- inputs :
signal RS_set, RS_reset  : std_ulogic_vector (anyrange)  :=(others=>'0');

RS_Q  <= not (RS_set or RS_Qb);
RS_Qb <= not (RS_reset or RS_Q);

so we can control the set and reset easily.
the case when both inputs are 1 should be avoided "at a higher level", by providing
that the clocking is correct etc.

ok, i know, i digress :-) but i like R/S cells.

> I would do it like this:

i don't see where you set address_match...

>         process (reset, Inv_En, Write_En)
>         -- becomes `process (reset, clock)' later...
>         begin
>                 if reset then
>                         tag_valid <= (others => '0');
>                 else    -- becomes `elsif rising_edge(clock)' later...
>                         if Inv_En then

how do you decide what "loop" or "if" is nested in what ?
for example, what is your criterium for putting Inv_en outside if the i loop ?

>                                 for i in tag_valid'range loop
>                                         if addr_match(i) = '1' then
>                                                 tag_valid(i) <= '0';

couldn't this be "vectored" ? i mean, using the general (index-less)
notation of std_ulogic_vector ? how do synthesizers react with this code ?

>                                         end if;
>                                 end loop;
>                         end if;
>                         -- Possible conflict if both operations select the same line.
>                         -- In that case, the write takes precedence (for that line)
>                         -- because its signal assignment to tag_valid(i) comes last.
>                         -- Swap the if blocks if you want things to work vice versa.

before a "definitive" solution is found, we can issue a warning or a note with "assert".

>                         if Write_En then
>                                 for i in tag_valid'range loop
>                                         if Write_signal(i) = '1' then
>                                                 tag_valid(i) <= '1';
>                                                 tag_array(i) <= Address_write;
>                                         end if;
>                                 end loop;
>                         end if;
>                 end if;
>         end process;

i am still unsure about how i'll rewrite the code.
it's very interesting anyway :-)


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 25 04:19:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00677 for ; Fri, 28 Jul 2000 00:56:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:40 +0200 (MEST) Received: (qmail 15240 invoked by uid 0); 25 Oct 2000 01:14:51 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 25 Oct 2000 01:14:51 -0000 X-eGroups-Return: sentto-1101623-1289-972436478-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 25 Oct 2000 01:14:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 01:14:38 -0000 Received: (qmail 29444 invoked from network); 25 Oct 2000 01:14:38 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 25 Oct 2000 01:14:38 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 25 Oct 2000 01:14:35 -0000 Received: from f-cpu.org (nas3-119.aub.club-internet.fr [195.36.145.119]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA01631 for ; Wed, 25 Oct 2000 03:14:31 +0200 (MET DST) Message-ID: <39F64321.A2E9DA40@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm References: <39F62505.C81BD6C7@f-cpu.org> <002801c03e19$bb0bef80$9c6c323f@cypress> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 03:19:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: recursivity Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f454ce5bfdab2deaff282ed1975fcdc1 Status: R X-Status: N hi, Haneef has answered quickly :-) here are some hints.

for-generate is cleaner anyway, no ? :-)

"Haneef D. Mohammed" wrote:
> > > I tried something similar (an entity that instantiated
> > > smaller versions of itself), but that didn't work with
> > > Simili :(  Maybe I have to use VHDL'87 `component' syntax
> > > instead of '93 syntax.
> >
> > Are recursive maps possible with Simili ? is it out of
> > question, or is there a possibility to admit it ?
> > If recursivity works, can you provide us with a "template"
> > so we can use it ?
>
> There is nothing in Simili to prevent recursion. However
> in a simulator or in synthesis, the recursion has to terminate
> before simulation begins. This can be typically done using generics.
>
> You say you tried something and that it did not work. Do
> you have an example of what you tried. Remember that unlike
> functions/procedures, entity/component recursion has to
> stop during elaboration. Maybe you ran into some small glitch
> that is preventing this....if so, I can try and fix it.
>
> Regards,
> Haneef

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Wed Oct 25 04:19:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00680 for ; Fri, 28 Jul 2000 00:56:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:40 +0200 (MEST) Received: (qmail 15267 invoked by uid 0); 25 Oct 2000 01:14:52 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net with SMTP; 25 Oct 2000 01:14:52 -0000 X-eGroups-Return: sentto-1101623-1288-972436478-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 25 Oct 2000 01:14:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 01:14:38 -0000 Received: (qmail 29409 invoked from network); 25 Oct 2000 01:14:37 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 25 Oct 2000 01:14:37 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 25 Oct 2000 01:14:37 -0000 Received: from f-cpu.org (nas3-119.aub.club-internet.fr [195.36.145.119]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA24374 for ; Wed, 25 Oct 2000 03:14:30 +0200 (MET DST) Message-ID: <39F64320.3AD080B6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> <39F62504.84BAD2A6@f-cpu.org> <20001025014221.26941@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 03:19:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1a012a9efe054b790d754199ba436758 Status: R X-Status: N hi again,

Michael Riepe wrote:
> On Wed, Oct 25, 2000 at 01:10:44AM +0100, Yann Guidon wrote:
> [...]
> > > tag_valid(index_tag) driving itself (sometimes)?
> > i "just" wanted to make a R/S latch...
> > maybe i should make an entity for the R/S latch ? dunno.
> That would be an option, if you don't want to use a process.
well, so what do you think about the option of the
hand-made R/S of the last post ? :-)

> > > I would do it like this:
> [code removed]
> > thanks,
> > have you compiled it ?
> No, that was a quick hack while I was writing the reply.
i'm still searching a "clean" way to implement it.
help welcome.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Rares Marian Wed Oct 25 09:46:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00686 for ; Fri, 28 Jul 2000 00:56:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:56:42 +0200 (MEST) Received: (qmail 6659 invoked by uid 0); 25 Oct 2000 07:47:35 -0000 Received: from hn.egroups.com (208.50.99.199) by mx12.rz2.gmx.net with SMTP; 25 Oct 2000 07:47:35 -0000 X-eGroups-Return: sentto-1101623-1290-972460050-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 25 Oct 2000 07:47:33 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 07:47:29 -0000 Received: (qmail 9600 invoked from network); 25 Oct 2000 07:47:29 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 25 Oct 2000 07:47:29 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 25 Oct 2000 07:47:29 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id CC3C42F5804 for ; Wed, 25 Oct 2000 03:46:56 -0400 (EDT) To: f-cpu@egroups.com Message-ID: From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 03:46:56 -0400 (EDT) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Speed by mutiple units Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4f2f7a06f176a94c504b8afb036d7ce5 Status: R X-Status: N
Do we really have to build full units?
Does each step have to include all the possible pieces CISC-like?

Or could we do this:

You have a unit A1.  A1 is made up of an atomic repeating process
so it implies subunit a1.  a1 will take up consdirably less space on the
chip than A1.  a1 cycles are cosiderably shorter than A1 cycles.  In fact
the time taken by repeated a1 cycles required to complete the work of A1
is not much longer than the time taken by A1.  But you can now fit
(Areaof(A1)/Areaof(a1)) a1 units on the chip.

It brings down your maximum cycle speed somewhat but now there's more room
on the chip to work in.

I think a partial multipilier recursed (or recoursed as seems more
appropriate) to itself will do fine.

No need to take up room if parts are waiting.

Heck we could even make use of other units as needed to get the effects of
Booth and other ideas.

See the question here is:

Does everything have to be explicitly coded?  Can we have situations where
one unit subordinates another unit temporarily?  Does it have to be hard
wired?

Perhaps expand the concept of register addressing and include EUs as well.

I know TTA, yada yada, but I can't shake it.  It can be implemented
without breaking the compiler.

In any case: 
The above is copyright Rares Marian 2000 and copyright F-CPU if applicable
once all licensing has been worked out.

Rares

PS Have a look at .c files in the Linux kernel each one is copyrighted by
a different person with all final decisions going to Linus.

I think that's the licensing model we should look toward.

--
Pine Is Not Elm.  Thank God Almighty.
eGroups Sponsor
From Michael Riepe Wed Oct 25 15:57:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00776 for ; Fri, 28 Jul 2000 00:57:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:09 +0200 (MEST) Received: (qmail 2474 invoked by uid 0); 25 Oct 2000 21:39:25 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 25 Oct 2000 21:39:25 -0000 X-eGroups-Return: sentto-1101623-1291-972509891-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mw.egroups.com with NNFMP; 25 Oct 2000 21:39:15 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 21:38:10 -0000 Received: (qmail 8532 invoked from network); 25 Oct 2000 21:38:04 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 25 Oct 2000 21:38:04 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.80) by mta2 with SMTP; 25 Oct 2000 21:38:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00685; Wed, 25 Oct 2000 15:57:08 +0200 Message-ID: <20001025155708.32981@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F62505.C81BD6C7@f-cpu.org> <002801c03e19$bb0bef80$9c6c323f@cypress> <39F64321.A2E9DA40@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F64321.A2E9DA40@f-cpu.org>; from Yann Guidon on Wed, Oct 25, 2000 at 03:19:13AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 15:57:08 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: recursivity Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3a57790e60fc35c84e79bde841b6b52e Status: R X-Status: N On Wed, Oct 25, 2000 at 03:19:13AM +0100, Yann Guidon wrote:
> hi, Haneef has answered quickly :-) here are some hints.
>
> for-generate is cleaner anyway, no ? :-)

`To iterate is human, to recurse, devine' ;)

> "Haneef D. Mohammed" wrote:
[...]
> > You say you tried something and that it did not work. Do
> > you have an example of what you tried. Remember that unlike
> > functions/procedures, entity/component recursion has to
> > stop during elaboration. Maybe you ran into some small glitch
> > that is preventing this....if so, I can try and fix it.

The problem seems to be that in '93 syntax:

      label : entity work.blah port map (...);

the instantiated entity has to be elaborated *first*.  That means
no recursion is possible; I have to use `component' syntax where the
instantiated component will be elaborated later.  This became very clear
to me when I re-read the VHDL FAQ, section 4.2.2 ;)

Thanks to Haneef, anyway...
(is his first name Haneef or Mohammed?)
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 25 16:16:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00779 for ; Fri, 28 Jul 2000 00:57:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:09 +0200 (MEST) Received: (qmail 21005 invoked by uid 0); 25 Oct 2000 21:55:52 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 25 Oct 2000 21:55:52 -0000 X-eGroups-Return: sentto-1101623-1292-972510949-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 25 Oct 2000 21:55:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 21:55:49 -0000 Received: (qmail 93068 invoked from network); 25 Oct 2000 21:38:08 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Oct 2000 21:38:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.80) by mta2 with SMTP; 25 Oct 2000 21:38:05 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00736; Wed, 25 Oct 2000 16:16:02 +0200 Message-ID: <20001025161602.38027@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Rares Marian on Wed, Oct 25, 2000 at 03:46:56AM -0400 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 16:16:02 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Speed by mutiple units Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 483a130c56ff5d557a61b18c315a3a54 Status: R X-Status: N 'lo again,

On Wed, Oct 25, 2000 at 03:46:56AM -0400, Rares Marian wrote:
>
> Do we really have to build full units?
> Does each step have to include all the possible pieces CISC-like?
>
> Or could we do this:
>
> You have a unit A1.  A1 is made up of an atomic repeating process
> so it implies subunit a1.  a1 will take up consdirably less space on the
> chip than A1.  a1 cycles are cosiderably shorter than A1 cycles.  In fact
> the time taken by repeated a1 cycles required to complete the work of A1
> is not much longer than the time taken by A1.  But you can now fit
> (Areaof(A1)/Areaof(a1)) a1 units on the chip.

That would effectively disable pipelining (=> reduce throughput).
It's an option for the divider unit, though.

> It brings down your maximum cycle speed somewhat but now there's more room
> on the chip to work in.
>
> I think a partial multipilier recursed (or recoursed as seems more
> appropriate) to itself will do fine.

I already suggested several ways to reduce the size of the multiplier.

> No need to take up room if parts are waiting.
>
> Heck we could even make use of other units as needed to get the effects of
> Booth and other ideas.
>
> See the question here is:
>
> Does everything have to be explicitly coded?  Can we have situations where
> one unit subordinates another unit temporarily?  Does it have to be hard
> wired?

Like, use the IMUL, IADD and SHIFT units to compute the level-1
floating-point stuff?  I considered that myself some time ago but didn't
want to come up with it before the integer units are ready.  On the
other hand, this will probably not be much faster than a well-optimized
FP library written in F-CPU assembler (thanks to the register bypass
capability of the crossbar!), and it would make instruction scheduling
MUCH more complex.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Wed Oct 25 15:45:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00785 for ; Fri, 28 Jul 2000 00:57:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:11 +0200 (MEST) Received: (qmail 22781 invoked by uid 0); 25 Oct 2000 21:56:34 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 25 Oct 2000 21:56:34 -0000 X-eGroups-Return: sentto-1101623-1293-972510971-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 25 Oct 2000 21:56:12 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 21:56:11 -0000 Received: (qmail 93411 invoked from network); 25 Oct 2000 21:38:14 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Oct 2000 21:38:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.80) by mta2 with SMTP; 25 Oct 2000 21:38:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00641; Wed, 25 Oct 2000 15:45:45 +0200 Message-ID: <20001025154545.55890@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> <39F638FC.B551881C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F638FC.B551881C@f-cpu.org>; from Yann Guidon on Wed, Oct 25, 2000 at 02:35:56AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Oct 2000 15:45:45 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a5c7809a2a3aa71d58db16354eca9a3b Status: R X-Status: N On Wed, Oct 25, 2000 at 02:35:56AM +0100, Yann Guidon wrote:

> RS_Q  <= not (RS_set or RS_Qb);
> RS_Qb <= not (RS_reset or RS_Q);
>
> so we can control the set and reset easily.

If the simulator groks that -- no problem so far.
In the final (clocked) version, we will have something different
anyway (a D-FF or JK-FF, probably, but that depends on the target).

> > I would do it like this:
>
> i don't see where you set address_match...

That was handled above, iirc.

> >         process (reset, Inv_En, Write_En)
> >         -- becomes `process (reset, clock)' later...
> >         begin
> >                 if reset then
> >                         tag_valid <= (others => '0');
> >                 else    -- becomes `elsif rising_edge(clock)' later...
> >                         if Inv_En then
>
> how do you decide what "loop" or "if" is nested in what ?
> for example, what is your criterium for putting Inv_en outside if the i loop ?

Style ;)  I could have made a single for loop with two ifs inside, but
I wanted the Inv and Write operations to be separated as much as
possible to make the code cleaner, and easier to understand.

>
> >                                 for i in tag_valid'range loop
> >                                         if addr_match(i) = '1' then
> >                                                 tag_valid(i) <= '0';
>
> couldn't this be "vectored" ? i mean, using the general (index-less)
> notation of std_ulogic_vector ? how do synthesizers react with this code ?

Since this is a standard VHDL idiom, the synthesizer should create a
row of 1-bit latches for tag_valid (and also for tag_array below) --
for a clocked circuit, replace `latches' with `flip-flops'.

You could write something like this (assuming all signals have type
std_ulogic[_vector], and all vectors have identical index ranges):

    -- signal ffSet, ffRes : std_ulogic_vector(tag_valid'range);

    -- auxiliary write vector
    ffSet <= Write_signal and (tag_valid'range => Write_En);
    -- auxiliary invalidate vector
    ffRes <= addr_match and (tag_valid'range => Inv_En);
    -- row of RS-FFs
    -- precedence rule: reset > ffSet > ffRes.
    tag_valid <= ((tag_valid and not ffRes) or ffSet)
                 and not (tag_valid'range => reset);

I don't know what a synthesizer does in this case, however.  The code
can certainly be synthesized (some FPGAs even support an `internal'
feedback inside a cell, e.g. Atmel AT40K).  A simulator should stop
scheduling events once the circuit is stable, i.e. when the signal values
(tag_valid in particular) stop changing.  Buggy simulators may enter an
endless loop, though.

[possible Inv/Write conflict]
> before a "definitive" solution is found, we can issue a warning or a note with "assert".

Yep.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Thu Oct 26 02:34:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00788 for ; Fri, 28 Jul 2000 00:57:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:12 +0200 (MEST) Received: (qmail 21146 invoked by uid 0); 25 Oct 2000 23:30:28 -0000 Received: from fl.egroups.com (64.209.169.106) by mx0.gmx.net with SMTP; 25 Oct 2000 23:30:28 -0000 X-eGroups-Return: sentto-1101623-1294-972516624-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 25 Oct 2000 23:30:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 23:30:23 -0000 Received: (qmail 9036 invoked from network); 25 Oct 2000 23:30:23 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 25 Oct 2000 23:30:23 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 25 Oct 2000 23:30:22 -0000 Received: from f-cpu.org (nas2-224.ras.club-internet.fr [195.36.192.224]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA03228 for ; Thu, 26 Oct 2000 01:30:18 +0200 (MET DST) Message-ID: <39F77C2F.69510BAA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F62505.C81BD6C7@f-cpu.org> <002801c03e19$bb0bef80$9c6c323f@cypress> <39F64321.A2E9DA40@f-cpu.org> <20001025155708.32981@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 01:34:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: recursivity Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4fac7d5e397c04b605b42547dfa8f765 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Wed, Oct 25, 2000 at 03:19:13AM +0100, Yann Guidon wrote:
> > for-generate is cleaner anyway, no ? :-)
> `To iterate is human, to recurse, devine' ;)
hmmm, IMHo that why gods are so slow ;-P

> > "Haneef D. Mohammed" wrote:
> [...]
> The problem seems to be that in '93 syntax:
>         label : entity work.blah port map (...);
> the instantiated entity has to be elaborated *first*.  That means
> no recursion is possible; I have to use `component' syntax where the
> instantiated component will be elaborated later.  This became very clear
> to me when I re-read the VHDL FAQ, section 4.2.2 ;)
hehe :-)

> Thanks to Haneef, anyway...
> (is his first name Haneef or Mohammed?)
i don't know, but you can ask him [i think] :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Thu Oct 26 02:34:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00791 for ; Fri, 28 Jul 2000 00:57:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:13 +0200 (MEST) Received: (qmail 11200 invoked by uid 0); 25 Oct 2000 23:30:40 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx01) with SMTP; 25 Oct 2000 23:30:40 -0000 X-eGroups-Return: sentto-1101623-1295-972516627-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 25 Oct 2000 23:30:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 25 Oct 2000 23:30:27 -0000 Received: (qmail 18477 invoked from network); 25 Oct 2000 23:30:27 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 25 Oct 2000 23:30:27 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 25 Oct 2000 23:30:22 -0000 Received: from f-cpu.org (nas2-224.ras.club-internet.fr [195.36.192.224]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA11122 for ; Thu, 26 Oct 2000 01:30:18 +0200 (MET DST) Message-ID: <39F77C2E.DE6208BB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F53FEA.14CF1E4F@f-cpu.org> <20001024154712.50867@thrai.stud.uni-hannover.de> <39F638FC.B551881C@f-cpu.org> <20001025154545.55890@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 01:34:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (v) Icache address tag comparator Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 548661af0f3daa4262697dc0e5b3870a Status: R X-Status: N hi again,

Michael Riepe wrote:
> On Wed, Oct 25, 2000 at 02:35:56AM +0100, Yann Guidon wrote:
> > RS_Q  <= not (RS_set or RS_Qb);
> > RS_Qb <= not (RS_reset or RS_Q);
> > so we can control the set and reset easily.
> If the simulator groks that -- no problem so far.
it #should#.

> In the final (clocked) version, we will have something different
> anyway (a D-FF or JK-FF, probably, but that depends on the target).
now that you mention this... i'll try to see what it makes when
we use a simple D-FF with asynch. reset.

> > > I would do it like this:
> > i don't see where you set address_match...
> That was handled above, iirc.
ok, so the process is outside the generate loop, right ?

> You could write something like this (assuming all signals have type
> std_ulogic[_vector], and all vectors have identical index ranges):
>
>     -- signal ffSet, ffRes : std_ulogic_vector(tag_valid'range);
>
>     -- auxiliary write vector
>     ffSet <= Write_signal and (tag_valid'range => Write_En);
>     -- auxiliary invalidate vector
>     ffRes <= addr_match and (tag_valid'range => Inv_En);
>     -- row of RS-FFs
>     -- precedence rule: reset > ffSet > ffRes.
>     tag_valid <= ((tag_valid and not ffRes) or ffSet)
>                  and not (tag_valid'range => reset);
>
> I don't know what a synthesizer does in this case, however.  The code
> can certainly be synthesized (some FPGAs even support an `internal'
> feedback inside a cell, e.g. Atmel AT40K).  A simulator should stop
> scheduling events once the circuit is stable, i.e. when the signal values
> (tag_valid in particular) stop changing.  Buggy simulators may enter an
> endless loop, though.
i think that if they are not cycle-based, they should simulate it correctly.

but now, i realize that the "custom" R/S latch could take more space
and be slower than a standard cell. I'll try to convert the design to a D-FF.

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Thu Oct 26 09:37:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00800 for ; Fri, 28 Jul 2000 00:57:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:17 +0200 (MEST) Received: (qmail 10945 invoked by uid 0); 26 Oct 2000 06:32:38 -0000 Received: from hm.egroups.com (208.50.99.198) by mx19.rz2.gmx.net with SMTP; 26 Oct 2000 06:32:38 -0000 X-eGroups-Return: sentto-1101623-1296-972541954-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 26 Oct 2000 06:32:33 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 26 Oct 2000 06:32:33 -0000 Received: (qmail 17518 invoked from network); 26 Oct 2000 06:32:33 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 26 Oct 2000 06:32:33 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 26 Oct 2000 06:32:32 -0000 Received: from f-cpu.org (nas2-226.ras.club-internet.fr [195.36.192.226]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA10142 for ; Thu, 26 Oct 2000 08:32:29 +0200 (MET DST) Message-ID: <39F7DF29.316AC6EF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 08:37:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] just for the form Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6e895e3d63750ca2e670477166467792 Status: R X-Status: N hi,

i bundled and released a first ZIP package of VHDL files.
it concerns the ROP2 unit only, but it works and it's
a major milestone :-)

see http://www.f-cpu.de/design/

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jeff Davies Thu Oct 26 22:33:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00884 for ; Fri, 28 Jul 2000 00:57:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:33 +0200 (MEST) Received: (qmail 1783 invoked by uid 0); 26 Oct 2000 20:57:03 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net with SMTP; 26 Oct 2000 20:57:03 -0000 X-eGroups-Return: sentto-1101623-1297-972593814-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hk.egroups.com with NNFMP; 26 Oct 2000 20:56:55 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 26 Oct 2000 20:56:54 -0000 Received: (qmail 5906 invoked from network); 26 Oct 2000 20:56:53 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 26 Oct 2000 20:56:53 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 26 Oct 2000 20:56:51 -0000 Received: from modem-123.iowa.dialup.pol.co.uk ([62.137.66.123] helo=tiglath.pileser.sumeria) by mail6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ou4v-0005Sw-00 for f-cpu@egroups.com; Thu, 26 Oct 2000 21:56:49 +0100 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] Message-Id: <00102621561404.21313@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 21:33:57 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] sony ps2 128 bit risc, and the gnu hurd Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 8e6d107f135878a7b142b6a0f7a350ce Status: R X-Status: N I know this is slightly off topic in the middle of the current VHDL cloud,...but Apparently the sony ps2 has a 300Mhz 128 bit risc which outperforms the dreamcast by a factor of between 50 and 9. The PS2 can, it is said, process 6 billion floating point ops per second. (can this be true?). Microsoft is claiming that the Xbox will "be 15 times faster than the PS2". With a 775 MHz Pentium III (this is a 32 bit CPU isn't it?), how can it? Are there SIMD instructions that somehow allow 128 bit transfers? Certainly it seems to me that on the CPU side, the Xbox will be much slower than the PS2 (the PS2 is RISC, the Pentium III Risc, and although I haven't been watching Specmarks recently, Risc type CPUs always did more than CISC type per cycle, with the king of the class being HP PA-Risc when I did my last survey of Specmarks per MHz about 12 months ago). The Xbox is going to have some special graphics CPU however from Nvidia, all details of which are secret apart from the "15 times blah blah blah". At peak, the PS2 can apparently render 75 million polygons per second, dropping to 20 million with light shading and stuff. The PS2 graphics chip runs at about 150MHz, and apparently the bus to the 4meg VRAM runs at 6Gigabytes per second. Does anyone know of any reason the xbox will be anything other than another "Exchange - the Lotus Notes Killer ... yeah right", or bloody Windows CE , the pile of crap I shelled out £500 for when it first came out. On an aside, linked together only by the thought that perhaps von Neuman architecture is reaching its limit,.. GNU/hurd is now available from debian with it's own mini distribution!! For those that know not of the hurd, it is a Linux type kernel which sits on the mach microkernel. Both are the fruit of a much longer running project than Linux, the main difference being it's object orientated nature. In the hurd, the unix environment is just another object receiving messages, which in a nutshell allows you to split your task over SMP, beouwulf style networks, beowulf style networks of SMP machines etc, without changing the code at all. [that's what debian say, anyway]. Jeff Davies -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/15/_/3462/_/972593814/ ---------------------------------------------------------------------_-> From Michael Riepe Thu Oct 26 23:29:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00887 for ; Fri, 28 Jul 2000 00:57:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:34 +0200 (MEST) Received: (qmail 3788 invoked by uid 0); 26 Oct 2000 21:39:10 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 26 Oct 2000 21:39:10 -0000 X-eGroups-Return: sentto-1101623-1298-972596345-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 26 Oct 2000 21:39:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 26 Oct 2000 21:39:04 -0000 Received: (qmail 7304 invoked from network); 26 Oct 2000 21:31:42 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 26 Oct 2000 21:31:42 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.228) by mta2 with SMTP; 26 Oct 2000 21:31:36 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01871; Thu, 26 Oct 2000 23:29:14 +0200 Message-ID: <20001026232914.17861@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F7DF29.316AC6EF@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F7DF29.316AC6EF@f-cpu.org>; from Yann Guidon on Thu, Oct 26, 2000 at 08:37:13AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 23:29:14 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] just for the form Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 30238e318ab86c78ffaefc758db620a1 Status: R X-Status: N On Thu, Oct 26, 2000 at 08:37:13AM +0100, Yann Guidon wrote:

> i bundled and released a first ZIP package of VHDL files.
> it concerns the ROP2 unit only, but it works and it's
> a major milestone :-)

Yeah!!  Where's the bottle of champagne? ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Fri Oct 27 00:01:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00890 for ; Fri, 28 Jul 2000 00:57:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:35 +0200 (MEST) Received: (qmail 14704 invoked by uid 0); 26 Oct 2000 22:03:39 -0000 Received: from ej.egroups.com (64.209.169.103) by mx0.gmx.net with SMTP; 26 Oct 2000 22:03:39 -0000 X-eGroups-Return: sentto-1101623-1299-972597809-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 26 Oct 2000 22:03:42 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_0); 26 Oct 2000 22:03:29 -0000 Received: (qmail 9420 invoked from network); 26 Oct 2000 22:01:48 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 26 Oct 2000 22:01:48 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.228) by mta3 with SMTP; 26 Oct 2000 22:01:47 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02170; Fri, 27 Oct 2000 00:01:44 +0200 Message-ID: <20001027000144.22026@thrai.stud.uni-hannover.de> To: F-CPU Mailing List X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 00:01:44 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Heise reports ROP2 release... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7b3c2f344db68170adea881be6b8a4f7 Status: R X-Status: N See http://www.heise.de/newsticker/data/hes-26.10.00-000/
(in german).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Berkane Fri Oct 27 02:54:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00905 for ; Fri, 28 Jul 2000 00:57:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:39 +0200 (MEST) Received: (qmail 8921 invoked by uid 0); 27 Oct 2000 00:52:13 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 27 Oct 2000 00:52:13 -0000 X-eGroups-Return: sentto-1101623-1300-972607925-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 27 Oct 2000 00:52:07 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 00:52:05 -0000 Received: (qmail 7404 invoked from network); 27 Oct 2000 00:52:04 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Oct 2000 00:52:04 -0000 Received: from unknown (HELO semeur.localdomain) (212.27.43.35) by mta1 with SMTP; 27 Oct 2000 00:52:03 -0000 Received: from infolibre.org (semeur.localdomain [127.0.0.1]) by semeur.localdomain (Postfix) with ESMTP id D97158667 for ; Fri, 27 Oct 2000 02:54:28 +0200 (CEST) Sender: root@semeur.localdomain Message-ID: <39F8D244.D0178AC2@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com X-eGroups-From: Berkane From: Berkane MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 02:54:28 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3156642e1fc4a9b49fba5a35952781b7 Status: R X-Status: N
s33 U s00n  RuNaWaY 0n 0p3nBsD.

|   |
|-|-|
   |      @]-,--< ViVe JsK >--'-[@
|-|-|
|   |

                UnDer MiSsIoN aLwAys fR33.

    is there somebody here, who have information about ERIM32.
    thanks It's a real good things for us.
    power to ERIM32 progress
    I like it .

    Mr guidon I can kick U . Or break your neck.
    remember where I live .I learned life in sad streets.
    U are a piece of cake for me. So easy
    I got good friends where u live, don't U know ?
    and I like MUAY THAI.
    I'M GONE MAKE U KNOCK OUT
    SO FOR ALL PEOPLE  THERE IS ERIM32
    THAT NICE NOW ;)))))))))))))))))))))))
    ;)))))))))))))))))))))))))))))))))
    ;)))))))))))))) LET THE ERIM32 SHINE.
    en francais t'est qu'un cave qui demande qu'a ce faire plumer .
    tu voie ou tes conneries me poussent jusqu'en enfer si tu continu
comme
    ca tu risque d'aller faire un tour a la cave. Comme cela, se fait
chez nous
    dans le neuf-trois. Faudra pas pleurer pauv type.
    regarde a deux fois avant de vouloir mepriser les autres . T'as fais
une
    tres mauvaise pioche . Va te coucher, va dormir . Oublie moi,
    sinon, je vais venir te chercher a rosny. C'est pas tres loin de
chez moi.
    Histoire de me calmer les nerf sur ta carcasse . Tu vas voir comment
    je vais te degonfler ta baudruche.
    si t'est un homme rendez-vous quand tu veux
    association sportive emmaus a la cite de l'etoile BOBIGNY
    face a la tour sur le parking ."cours de boxe thailandaise".
    je suis pret a t'affronter a la loyal sur le ring . Ton jour sera le
mien
    fiote, lolote. Malgre mon age 37 toi 20 mais c'est sans compter la
rage
    qui m'habite; je vais boire ton sang . Manger ton foie. Sans oublier
de
    pisser dans ton cou. creuse ton tombeau avant d'affrontrer mon
couroux.
    Achete une armoire en sapin, apres tu pourra venir prendre ta lecon.
    A base de coup de genoux saute menton voila comment je vais te
soigne.
    Sans compter les coup de coudes affutes de chez wilkinson. tu
pourras
    verifier l'affirmation qui dit que les secs ont les os pointus.
    si tu est ok pour le rencard il te suffit d'y aller quand tu veux .
    Demande aux jeunes apres moi il m'appelleront chez moi et je
viendrais te
    foutre une putain de raclee que tu t'en souviendra jusqu'a la fin
des temps.
    La c'est ma partie
    la boxe thai a l'etoile
    ont la connait dans tous ces details
    KHALED nous l'apprend sans failles.
    ca vas etre dur pour toi ca sent la defaite. Cela pourra t'apprendre
le respect
    due au ancien. Petit jeune merdeux viens histoire que je te punisse
comme tu
    l'as merite. Ne n'oblige pas a aller te chercher chez toi. Car la je
serais
    sans pitie comme tu le fais maintenant avec ma boite a lettre.
    continue a me chauffer avec tes mails tu vas voir cela va etre
triste
    pour toi.Alors surtout oublie moi

    forget me or it will be sad for U.
    mail from hell

s33 U s00n  RuNaWaY 0n 0p3nBsD.

|   |
|-|-|
   |      @]-,--< ViVe JsK >--'-[@
|-|-|
|   |

                UnDer MiSsIoN aLwAys fR33.


----asdean@webmails.com----
eGroups Sponsor
From "Albert Abramson" Fri Oct 27 04:56:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00908 for ; Fri, 28 Jul 2000 00:57:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:40 +0200 (MEST) Received: (qmail 21231 invoked by uid 0); 27 Oct 2000 02:58:30 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net with SMTP; 27 Oct 2000 02:58:30 -0000 X-eGroups-Return: sentto-1101623-1301-972615506-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 27 Oct 2000 02:58:28 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 02:58:25 -0000 Received: (qmail 29479 invoked from network); 27 Oct 2000 02:58:24 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 27 Oct 2000 02:58:24 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta2 with SMTP; 27 Oct 2000 02:58:24 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001027025810.XVQP2380.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Thu, 26 Oct 2000 19:58:10 -0700 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20001027025810.XVQP2380.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Oct 2000 19:56:24 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] sony ps2 128 bit risc, and the gnu hurd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 1f7372e8d647f301164cfb7da7bac875 Status: R X-Status: N Yes, it is possible for a 32 bit processor based system to outperform a 128=
bit system.  The reason is that 32 bits is just the address size of th= e
processor.  PS2 uses a MIPS-based VLIW architecture with one MIPS
instruction bundled with each SIMD instruction.  The P3 also uses SIMD=
hardware, though less effectively.  Xbox is different because of its u= se of
GeForce hardware.  I've seen screenshots from both and they both suck.= .. for
the price and the wait.

I would rather see raytracing done in realtime.  This is much more dif= ficult
that traditional vector graphics, requiring complex double-precision
algorithms, rather than simple single-precision multiply-adds.  This i= s the
primary motivator for implementing double-precision hardware in my previous=
proposals.

Technically, Xbox may be much more powerful than PS2, but it is unlikely that the games on Xbox will do anything but suck eggs like most of the game= s
on the PC.

Even with all of the SIMD stuff being added to CPUs, nothing compares to dedicated graphics hardware for raw graphics processing power.  Nothin= g
comes close, not even Alpha -- not even G4.

----------
>From: Jeff Davies <jeff@llandre.freeserve.co.uk>
>To: f-cpu@egroups.com
>Subject: [f-cpu] sony ps2 128 bit risc, and the gnu hurd
>Date: Thu, Oct 26, 2000, 1:33 PM
>

> I know this is slightly off topic in the middle of the current VHDL cloud,...but
>
> Apparently the sony ps2 has a 300Mhz 128 bit risc which outperforms th= e
> dreamcast by a factor of between 50 and 9. The PS2 can, it is said, pr= ocess
> 6 billion floating point ops per second. (can this be true?).
>
> Microsoft is claiming that the Xbox will "be 15 times faster than= the PS2".
> With a 775 MHz Pentium III  (this is a 32 bit CPU isn't it?), how= can it?
> Are there SIMD instructions that somehow allow 128 bit transfers?
>
> Certainly it seems to me that on the CPU side, the Xbox will be much s= lower
than
> the PS2 (the PS2 is RISC, the Pentium III Risc, and although I haven't= been
> watching Specmarks recently, Risc type CPUs always did more than CISC = type
> per cycle, with the king of the class being HP PA-Risc when I did my l= ast
survey
> of Specmarks per MHz about 12 months ago).
>
Graphics performance is more a function of raw throughput and specific
operations.  SPECmarks have more to do with balancing instruction and = memory
latency with issues like pipelining, dynamic scheduling, and caching.
Graphics just focuses on raw throughput and bandwidth.  Unfortunately,= f-cpu
seems to address neither issue.

> The Xbox is going to have some special graphics CPU however from Nvidi= a, all
> details of which are secret apart from the "15 times blah blah bl= ah".
> At peak, the PS2 can apparently render 75 million polygons per second,=
dropping
> to 20 million with light shading and stuff. The PS2 graphics chip runs= at
about
> 150MHz, and apparently the bus to the 4meg VRAM runs at 6Gigabytes per= second.
>
> Does anyone know of any reason the xbox will be anything other than an= other
> "Exchange - the Lotus Notes Killer ... yeah right", or blood= y Windows CE , the
> pile of crap I shelled out =A3500 for when it first came out.
>
> On an aside,  linked together only by the thought that perhaps vo= n
> Neuman architecture is reaching its limit,..
> GNU/hurd is now available from
> debian with it's own mini distribution!! For those that know not of th= e hurd,
> it is a Linux type kernel which sits on the mach microkernel. Both are= the
> fruit of a much longer running project than Linux, the main difference= being
> it's object orientated nature. In the hurd, the unix environment is ju= st
> another object receiving messages, which in a nutshell allows you to s= plit
your
> task over SMP, beouwulf style networks, beowulf style networks of SMP = machines
> etc, without changing the code at all. [that's what debian say, anyway= ].
>
> Jeff Davies
>
>
>
>
>
--Maxx
eGroups Sponsor=
3D""
From "Marco Al" Fri Oct 27 05:58:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00911 for ; Fri, 28 Jul 2000 00:57:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:41 +0200 (MEST) Received: (qmail 24018 invoked by uid 0); 27 Oct 2000 03:52:46 -0000 Received: from mv.egroups.com (208.50.144.81) by mx12.rz2.gmx.net with SMTP; 27 Oct 2000 03:52:46 -0000 X-eGroups-Return: sentto-1101623-1302-972618764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 27 Oct 2000 03:52:46 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 03:52:44 -0000 Received: (qmail 38895 invoked from network); 27 Oct 2000 03:52:41 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 27 Oct 2000 03:52:41 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 27 Oct 2000 03:52:41 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id FAA25911 for ; Fri, 27 Oct 2000 05:52:40 +0200 (METDST) Message-ID: <00ad01c03fca$1ce9ec50$29e65982@student.utwente.nl> To: References: <20001027025810.XVQP2380.femail1.sdc1.sfba.home.com@[24.10.43.202]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 05:58:05 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] OT raytracing and dedicated hardware Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 75f8065ff75076bc7def053d14f1c618 Status: R X-Status: N From: "Albert Abramson" <maxx@nventure.com>


> Yes, it is possible for a 32 bit processor based system to outperform a
128
> bit system.  The reason is that 32 bits is just the address size of the
> processor.  PS2 uses a MIPS-based VLIW architecture with one MIPS
> instruction bundled with each SIMD instruction.  The P3 also uses SIMD
> hardware, though less effectively.  Xbox is different because of its use
of
> GeForce hardware.  I've seen screenshots from both and they both suck...
for
> the price and the wait.

Oh I dont know, I rather liked the original robot animation (not the dumbed
down one which could run in realtime on the NV15).

> I would rather see raytracing done in realtime.

Everything in graphics is a hack, whats important is what you can get on the
screen with a fixed amount of resources. Id rather have the robot than a
couple of colored balls on a reflective plane ;) Pixar still believes in
scan conversion...

>  This is much more difficult
> that traditional vector graphics, requiring complex double-precision
> algorithms, rather than simple single-precision multiply-adds.

If you have specific algorithms Im sure there are more efficient methods to
implement them in dedicated hardware than just wasting double-precision
floating point hardware on everything.

> Even with all of the SIMD stuff being added to CPUs, nothing compares to
> dedicated graphics hardware for raw graphics processing power.  Nothing
> comes close, not even Alpha -- not even G4.

Which is X-Box's edge over the PS2, at least in the graphics department,
dedicated hardware for T&L and pixel shading.

But if you believe that and you want to make a raytracing processor, why are
you trying to shoehorn it into a general purpose processor? :)

Marco
eGroups Sponsor
From Yann Guidon Fri Oct 27 08:11:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00920 for ; Fri, 28 Jul 2000 00:57:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:43 +0200 (MEST) Received: (qmail 20649 invoked by uid 0); 27 Oct 2000 05:07:00 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 27 Oct 2000 05:07:00 -0000 X-eGroups-Return: sentto-1101623-1303-972623217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 27 Oct 2000 05:06:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 05:06:57 -0000 Received: (qmail 53262 invoked from network); 27 Oct 2000 05:06:56 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Oct 2000 05:06:56 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 27 Oct 2000 05:06:56 -0000 Received: from f-cpu.org (nas2-231.ras.club-internet.fr [195.36.192.231]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA13337; Fri, 27 Oct 2000 07:06:50 +0200 (MET DST) Message-ID: <39F91C96.9183E243@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com, Berkane References: <39F8D244.D0178AC2@infolibre.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 07:11:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cbfe3d28b27967b3a92ced7eff802400 Status: R X-Status: N tu sais lire ?

@ http://www.egroups.com/gro= up/f-cpu :

            &nb= sp; To unsubscribe, send a message to f-cpu-unsubscribe@makelist.com

c'est facile de boxer. les menaces, c'est m=EAme marrant. penser, c'est du = sport.
JE NE PEUX PAS TE DESINSCRIRE, HEUREUSEMENT POUR TA VIE PRIVEE, C'EST COMME= CA
LE NET. en esp=E9rant que tu trouves la bonne touche et que =E7a marche,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
<= /a>
From Yann Guidon Fri Oct 27 09:37:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00923 for ; Fri, 28 Jul 2000 00:57:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:44 +0200 (MEST) Received: (qmail 5028 invoked by uid 0); 27 Oct 2000 06:33:25 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 27 Oct 2000 06:33:25 -0000 X-eGroups-Return: sentto-1101623-1304-972628401-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 27 Oct 2000 06:33:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 06:33:20 -0000 Received: (qmail 58974 invoked from network); 27 Oct 2000 06:33:20 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 27 Oct 2000 06:33:20 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 27 Oct 2000 06:33:19 -0000 Received: from f-cpu.org (nas1-203.aub.club-internet.fr [195.36.150.203]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA21737 for ; Fri, 27 Oct 2000 08:33:14 +0200 (MET DST) Message-ID: <39F930D0.DC6B66DA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F7DF29.316AC6EF@f-cpu.org> <20001026232914.17861@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 08:37:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] just for the form Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 37599151f1ed02484f9183eabadcd426 Status: R X-Status: N Michael Riepe wrote:
> On Thu, Oct 26, 2000 at 08:37:13AM +0100, Yann Guidon wrote:
> > i bundled and released a first ZIP package of VHDL files.
> > it concerns the ROP2 unit only, but it works and it's
> > a major milestone :-)
>
> Yeah!!  Where's the bottle of champagne? ;)

then :

Michael Riepe wrote:
> See http://www.heise.de/newsticker/data/hes-26.10.00-000/
> (in german).

you answered your own question ;-P


OTOH, this doesn't keep anybody from foolproofing the archive
that i uploaded to http://www.f-cpu.de/design/ , thanks ;-)



>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Asdean Fri Oct 27 13:36:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00953 for ; Fri, 28 Jul 2000 00:57:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:57:51 +0200 (MEST) Received: (qmail 13632 invoked by uid 0); 27 Oct 2000 11:33:50 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net with SMTP; 27 Oct 2000 11:33:50 -0000 X-eGroups-Return: sentto-1101623-1305-972646428-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 27 Oct 2000 11:33:47 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 11:33:47 -0000 Received: (qmail 84680 invoked from network); 27 Oct 2000 11:33:47 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Oct 2000 11:33:47 -0000 Received: from unknown (HELO semeur.localdomain) (213.228.21.24) by mta1 with SMTP; 27 Oct 2000 11:33:46 -0000 Received: from infolibre.org (semeur.localdomain [127.0.0.1]) by semeur.localdomain (Postfix) with ESMTP id 0442C8682 for ; Fri, 27 Oct 2000 13:36:05 +0200 (CEST) Sender: root@semeur.localdomain Message-ID: <39F968A5.7083E509@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <39F8D244.D0178AC2@infolibre.org> <39F91C96.9183E243@f-cpu.org> X-eGroups-From: Asdean From: Asdean MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 13:36:05 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ddc94fbab1881caa95a2762819d47a38 Status: R X-Status: N Yann Guidon a =E9crit :
>
> tu sais lire ?
>
> @ http://www.egroups.co= m/group/f-cpu :
>
>            = ;   To unsubscribe, send a message to f-cpu-unsubscribe@makelist.= com
>
> c'est facile de boxer. les menaces, c'est m=EAme marrant. penser, c'es= t du sport.
> JE NE PEUX PAS TE DESINSCRIRE, HEUREUSEMENT POUR TA VIE PRIVEE, C'EST = COMME CA
> LE NET. en esp=E9rant que tu trouves la bonne touche et que =E7a march= e,
>
Quand je vais t'ouvrir le crane cela sera marrant sans aucun doute
eGroups Sponsor=
3D""
=
From Nicolas Matringe Fri Oct 27 14:49:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00992 for ; Fri, 28 Jul 2000 00:58:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:00 +0200 (MEST) Received: (qmail 7371 invoked by uid 0); 27 Oct 2000 12:48:25 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net with SMTP; 27 Oct 2000 12:48:25 -0000 X-eGroups-Return: sentto-1101623-1306-972650902-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 27 Oct 2000 12:48:24 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 12:48:22 -0000 Received: (qmail 674 invoked from network); 27 Oct 2000 12:48:21 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 27 Oct 2000 12:48:21 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 27 Oct 2000 12:48:21 -0000 Received: from IPricot.com (dish.dotcom.fr [192.168.1.64]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id MAA21787 for ; Fri, 27 Oct 2000 12:48:20 GMT X-To: Message-ID: <39F979BD.E091533B@IPricot.com> Organization: IPricot European Headquarters (Formerly DotCom SA) X-Mailer: Mozilla 4.6 [fr] (WinNT; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39F8D244.D0178AC2@infolibre.org> <39F91C96.9183E243@f-cpu.org> <39F968A5.7083E509@infolibre.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 14:49:01 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c4a77c95c5fa47b6626a04df2f42fffa Status: R X-Status: N Asdean a =E9crit :

> Quand je vais t'ouvrir le crane cela sera marrant sans aucun doute

La question que je me pose, c'est "comment =E7a va faire avancer le schmilblick?"

Nico
eGroups Sponsor=
3D""
From Yann Guidon Fri Oct 27 16:54:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01039 for ; Fri, 28 Jul 2000 00:58:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:08 +0200 (MEST) Received: (qmail 3897 invoked by uid 0); 27 Oct 2000 13:50:50 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 27 Oct 2000 13:50:50 -0000 X-eGroups-Return: sentto-1101623-1307-972654638-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 27 Oct 2000 13:50:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 13:50:37 -0000 Received: (qmail 8983 invoked from network); 27 Oct 2000 13:50:17 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Oct 2000 13:50:17 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 27 Oct 2000 13:50:07 -0000 Received: from f-cpu.org (nas3-123.aub.club-internet.fr [195.36.145.123]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA12224 for ; Fri, 27 Oct 2000 15:49:59 +0200 (MET DST) Message-ID: <39F99734.856D7DE3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 15:54:44 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6bc6d5dc888f48cf9d60a486a398d05 Status: R X-Status: N hello,

when putting the package together, i included
the file containing the text of the GPL.
I would like to modify this text, precisely,
adding the "do's-don't" that are linked with the
F-CPU project. i have discussed some of these
with Graham and Jamil on another mailing list.
See the OpenCollector site for the outcome.

Can we discuss here about what we'll add in this
file, in front of the GPL ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 27 17:50:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01052 for ; Fri, 28 Jul 2000 00:58:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:12 +0200 (MEST) Received: (qmail 22703 invoked by uid 0); 27 Oct 2000 14:46:14 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 27 Oct 2000 14:46:14 -0000 X-eGroups-Return: sentto-1101623-1308-972657968-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 27 Oct 2000 14:46:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 14:46:08 -0000 Received: (qmail 10410 invoked from network); 27 Oct 2000 14:46:08 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Oct 2000 14:46:08 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 27 Oct 2000 14:46:07 -0000 Received: from f-cpu.org (nas1-197.aub.club-internet.fr [195.36.150.197]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA21779 for ; Fri, 27 Oct 2000 16:45:59 +0200 (MET DST) Message-ID: <39F9A44C.D85B458F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F8D244.D0178AC2@infolibre.org> <39F91C96.9183E243@f-cpu.org> <39F968A5.7083E509@infolibre.org> <39F979BD.E091533B@IPricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 16:50:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] unsubscribe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2ddf54560fb33fc09b3cfbb727ceb902 Status: R X-Status: N salut,

Nicolas Matringe wrote:
> Asdean a =E9crit :
> > Quand je vais t'ouvrir le crane cela sera marrant sans aucun dout= e
> La question que je me pose, c'est "comment =E7a va faire avancer = le
> schmilblick?"
rien.
pour ma d=E9charge, j'ai bien v=E9rifi=E9 qu'il =E9tait d=E9sinscrit de la = liste
fran=E7aise mais je ne peux absolument RIEN sur cette liste. RIEN.
et j'aime pas jouer aux boucs =E9missaires.

Si azdine peut envoyer des po=E8mes sur la liste, il peut tr=E8s bien
envoyer un mail =E0 un serveur pour se d=E9sinscrire. s'il n'y arrive
pas, il ne peut s'en prendre qu'=E0 lui-m=EAme. J'ai fait mon possible
pour tol=E9rer ses manquements graves =E0 la nettiquette, j'ai tent=E9
de voir ce qui n'allait pas, mais il n'arrive pas =E0 comprendre
que je ne suis pas magicien, que =E7a ne sert =E0 rien de s'en prendre
aux autres quand on s'est pi=E9g=E9 soi-m=EAme. Il prendrait un char
d'assaut que =E7a n'aiderait pas plus alors qu'un simple mail
r=E9soudrait la situation.

est-ce que je perds mon calme, moi ?

> Nico
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Fri Oct 27 17:50:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01056 for ; Fri, 28 Jul 2000 00:58:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:13 +0200 (MEST) Received: (qmail 1196 invoked by uid 0); 27 Oct 2000 14:46:21 -0000 Received: from ej.egroups.com (64.209.169.103) by mx0.gmx.net with SMTP; 27 Oct 2000 14:46:21 -0000 X-eGroups-Return: sentto-1101623-1309-972657969-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ej.egroups.com with NNFMP; 27 Oct 2000 14:46:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 14:46:09 -0000 Received: (qmail 22304 invoked from network); 27 Oct 2000 14:46:09 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 27 Oct 2000 14:46:09 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 27 Oct 2000 14:46:09 -0000 Received: from f-cpu.org (nas1-197.aub.club-internet.fr [195.36.150.197]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA04912 for ; Fri, 27 Oct 2000 16:35:35 +0200 (MET DST) Message-ID: <39F9A446.13A1C5F6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 16:50:30 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: ROP2 & Modelsim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 357ff5858d942a3cb4a1c7a3748ac8fc Status: R X-Status: N hello, i received this today :

Erik Hansen wrote:
> Hi,
>
> I just downloaded ROP2 source and found out that I had
> to apply some patches to make it work with Modelsim 5.3XE starter
> and Modelsim 5.4c.
>
> There where some changes to be made to the ROP2_testbench.vhdl file.
>
> 1. The write Commands needed a little change:
>
>    old: write (lout, "* cycle # : ");
>    new: write (lout, string'("* cylcle # : "));
>
>    It seems as if Modelsim made a Typecast do std_logic_vector, so
>    I made the explicit typecast to string.
>
> 2. function get_hexa uses variables which are normally out of
>    scope for pure functions ( although they are declared as
>    being shared ). So I made get_hexa an impure function.
>
>    old: function get_hexa(...
>    new: impure function get_hexa(...
>
> I've attached the changed file, together with compile script for
> Windows/Modelsim5.3XE Starter (testrop2.bat)
> and Solaris/Modelsim5.4c (testrop2.unix). Should work with outer
> Version of Modelsim as well;-)
>
> Erik
> -------------------------------------------------------------
>                      Name: rop2.tar.gz
>    rop2.tar.gz       Type: WinZip File (application/x-unknown-content-type-WinZip)
>                  Encoding: BASE64
>               Description: Tared and gzipped directory

i'll check the modifications. i will also put the new files on the german site.
it seems like the article on the net has had a good impact :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Fri Oct 27 21:26:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01122 for ; Fri, 28 Jul 2000 00:58:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:32 +0200 (MEST) Received: (qmail 4079 invoked by uid 0); 27 Oct 2000 19:31:09 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net with SMTP; 27 Oct 2000 19:31:09 -0000 X-eGroups-Return: sentto-1101623-1310-972675042-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ck.egroups.com with NNFMP; 27 Oct 2000 19:31:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 19:30:42 -0000 Received: (qmail 546 invoked from network); 27 Oct 2000 19:30:41 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 27 Oct 2000 19:30:41 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.108) by mta1 with SMTP; 27 Oct 2000 19:30:39 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01749; Fri, 27 Oct 2000 21:26:36 +0200 Message-ID: <20001027212636.32705@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F9A446.13A1C5F6@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F9A446.13A1C5F6@f-cpu.org>; from Yann Guidon on Fri, Oct 27, 2000 at 04:50:30PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 21:26:36 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: ROP2 & Modelsim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1753eaa341017774d2f0b5f0acd1dd87 Status: R X-Status: N On Fri, Oct 27, 2000 at 04:50:30PM +0100, Yann Guidon wrote:
[...]
> > 1. The write Commands needed a little change:
> >
> >    old: write (lout, "* cycle # : ");
> >    new: write (lout, string'("* cylcle # : "));
> >
> >    It seems as if Modelsim made a Typecast do std_logic_vector, so
> >    I made the explicit typecast to string.

I had to do the same for Vanilla VHDL -- it's unable to tell whether
the constant is a string or a bit vector, and write() is overloaded
to handle both of them.

[...]
> it seems like the article on the net has had a good impact :-)

Did you read the comments on www.heise.de?  IMHO, this wasn't good
publicity at all (except for c't, maybe).

People say that there ain't no such thing as bad publicity.  Being in
that business myself for some time now, I know that people are wrong.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 From Michael Riepe Fri Oct 27 20:52:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01125 for ; Fri, 28 Jul 2000 00:58:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:33 +0200 (MEST) Received: (qmail 11244 invoked by uid 0); 27 Oct 2000 19:31:09 -0000 Received: from c9.egroups.com (208.50.99.230) by mx12.rz2.gmx.net with SMTP; 27 Oct 2000 19:31:09 -0000 X-eGroups-Return: sentto-1101623-1311-972675051-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c9.egroups.com with NNFMP; 27 Oct 2000 19:30:54 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 19:30:51 -0000 Received: (qmail 21014 invoked from network); 27 Oct 2000 19:30:50 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 27 Oct 2000 19:30:50 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.108) by mta1 with SMTP; 27 Oct 2000 19:30:45 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01651; Fri, 27 Oct 2000 20:52:46 +0200 Message-ID: <20001027205246.51116@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F99734.856D7DE3@f-cpu.org>; from Yann Guidon on Fri, Oct 27, 2000 at 03:54:44PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 20:52:46 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 67a4bb8b5f80ac63ae55ed8cc7fa269a Status: R X-Status: N On Fri, Oct 27, 2000 at 03:54:44PM +0100, Yann Guidon wrote:

> Can we discuss here about what we'll add in this
> file, in front of the GPL ?

Why not?  As long as I understand the language we use ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Fri Oct 27 23:57:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01140 for ; Fri, 28 Jul 2000 00:58:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:36 +0200 (MEST) Received: (qmail 17490 invoked by uid 0); 27 Oct 2000 20:52:37 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 27 Oct 2000 20:52:37 -0000 X-eGroups-Return: sentto-1101623-1313-972679953-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mr.egroups.com with NNFMP; 27 Oct 2000 20:52:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 20:52:33 -0000 Received: (qmail 30727 invoked from network); 27 Oct 2000 20:52:33 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 27 Oct 2000 20:52:33 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 27 Oct 2000 20:52:33 -0000 Received: from f-cpu.org (nas4-157.aub.club-internet.fr [195.36.145.157]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA24716 for ; Fri, 27 Oct 2000 22:52:30 +0200 (MET DST) Message-ID: <39F9FA3A.A539BE80@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F9A446.13A1C5F6@f-cpu.org> <20001027212636.32705@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 22:57:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: ROP2 & Modelsim Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c467078c83fdc094ffd3f883e28e5b18 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Fri, Oct 27, 2000 at 04:50:30PM +0100, Yann Guidon wrote:
> [...]
> > > 1. The write Commands needed a little change:
> > >
> > >    old: write (lout, "* cycle # : ");
> > >    new: write (lout, string'("* cylcle # : "));
> > >
> > >    It seems as if Modelsim made a Typecast do std_logic_vector, so
> > >    I made the explicit typecast to string.
>
> I had to do the same for Vanilla VHDL -- it's unable to tell whether
> the constant is a string or a bit vector, and write() is overloaded
> to handle both of them.
so, let's overload...

> [...]
> > it seems like the article on the net has had a good impact :-)
> Did you read the comments on www.heise.de?  IMHO, this wasn't good
> publicity at all (except for c't, maybe).
i didn't feel it as bad publicity. anyway, he didn't understand my
comment about the patents and the compiler, i was refering in fact to
another article he wrote. we can't have everything right at once, so
why bother... it's too late anyway.

> People say that there ain't no such thing as bad publicity.  Being in
> that business myself for some time now, I know that people are wrong.
"time will tell" and there will be other articles.
this doesn't keep us from receiving helpful comments and carry on the work.

> Ciao,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Oct 27 23:57:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01143 for ; Fri, 28 Jul 2000 00:58:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 00:58:37 +0200 (MEST) Received: (qmail 10712 invoked by uid 0); 27 Oct 2000 20:52:54 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net with SMTP; 27 Oct 2000 20:52:54 -0000 X-eGroups-Return: sentto-1101623-1312-972679951-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 27 Oct 2000 20:52:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 20:52:31 -0000 Received: (qmail 31428 invoked from network); 27 Oct 2000 20:52:31 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 27 Oct 2000 20:52:31 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 27 Oct 2000 20:52:30 -0000 Received: from f-cpu.org (nas4-157.aub.club-internet.fr [195.36.145.157]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA19755 for ; Fri, 27 Oct 2000 22:52:28 +0200 (MET DST) Message-ID: <39F9FA38.ABE8123C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 22:57:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b2e4542056f9081bb4f405a8be94a877 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Fri, Oct 27, 2000 at 03:54:44PM +0100, Yann Guidon wrote:
> > Can we discuss here about what we'll add in this
> > file, in front of the GPL ?
> Why not?  As long as I understand the language we use ;)
so let's go :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Oct 28 01:58:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00313 for ; Fri, 28 Jul 2000 07:54:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 07:54:15 +0200 (MEST) Received: (qmail 15582 invoked by uid 0); 27 Oct 2000 23:58:57 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 27 Oct 2000 23:58:57 -0000 X-eGroups-Return: sentto-1101623-1314-972691128-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 27 Oct 2000 23:58:56 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 27 Oct 2000 23:58:47 -0000 Received: (qmail 25660 invoked from network); 27 Oct 2000 23:58:47 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 27 Oct 2000 23:58:47 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.224) by mta3 with SMTP; 27 Oct 2000 23:58:46 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02666; Sat, 28 Oct 2000 01:58:43 +0200 Message-ID: <20001028015843.00731@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39F9FA38.ABE8123C@f-cpu.org>; from Yann Guidon on Fri, Oct 27, 2000 at 10:57:12PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 28 Oct 2000 01:58:43 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b0d1ae18227df427b4ddf6f9382fbc2d Status: R X-Status: N On Fri, Oct 27, 2000 at 10:57:12PM +0100, Yann Guidon wrote:

> > > Can we discuss here about what we'll add in this
> > > file, in front of the GPL ?
> > Why not?  As long as I understand the language we use ;)
> so let's go :-)

Ok, what to add...

We need to clarify what the GPL is going to mean in the context of the
F-CPU project.  What is a `binary', what is `source code', and so on.
We should not add any restrictions, though (and we must not change the
GPL itself).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Adam Haberlach Sat Oct 28 06:45:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00319 for ; Fri, 28 Jul 2000 07:54:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 28 Jul 2000 07:54:17 +0200 (MEST) Received: (qmail 9554 invoked by uid 0); 28 Oct 2000 03:20:17 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net with SMTP; 28 Oct 2000 03:20:17 -0000 X-eGroups-Return: sentto-1101623-1315-972703214-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 28 Oct 2000 03:20:18 -0000 X-Sender: adam@newsnipple.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 28 Oct 2000 03:20:14 -0000 Received: (qmail 54653 invoked from network); 28 Oct 2000 03:20:13 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 28 Oct 2000 03:20:13 -0000 Received: from unknown (HELO socket.newsnipple.com) (208.243.144.102) by mta1 with SMTP; 28 Oct 2000 03:20:13 -0000 Received: by socket.newsnipple.com (Postfix, from userid 1000) id E876C35837; Fri, 27 Oct 2000 21:45:25 -0700 (PDT) To: f-cpu@egroups.com Message-ID: <20001027214525.A20928@ricochet.net> References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.0.1i In-Reply-To: <20001028015843.00731@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Sat, Oct 28, 2000 at 01:58:43AM +0200 From: Adam Haberlach MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 27 Oct 2000 21:45:25 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: adeecd85c658673281f10a6ec358f68a Status: R X-Status: N On Sat, Oct 28, 2000 at 01:58:43AM +0200, Michael Riepe wrote:
> On Fri, Oct 27, 2000 at 10:57:12PM +0100, Yann Guidon wrote:
>
> > > > Can we discuss here about what we'll add in this
> > > > file, in front of the GPL ?
> > > Why not?  As long as I understand the language we use ;)
> > so let's go :-)
>
> Ok, what to add...
>
> We need to clarify what the GPL is going to mean in the context of the
> F-CPU project.  What is a `binary', what is `source code', and so on.
> We should not add any restrictions, though (and we must not change the
> GPL itself).

      And above all, we must spend more time on the license then the actual
design of the system.

--
Adam Haberlach            |    ASCII   /~\
adam@newsnipple.com       |   Ribbon   \ /  Against
http://www.newsnipple.com | Campaign    X   HTML
'88 EX500                 |            / \  E-mail
eGroups Sponsor
From Yann Guidon Sat Oct 28 15:58:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00324 for ; Sat, 28 Oct 2000 22:28:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 28 Oct 2000 22:28:07 +0200 (MEST) Received: (qmail 10898 invoked by uid 0); 28 Oct 2000 12:53:41 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net with SMTP; 28 Oct 2000 12:53:41 -0000 X-eGroups-Return: sentto-1101623-1316-972737620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 28 Oct 2000 12:53:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 28 Oct 2000 12:53:39 -0000 Received: (qmail 57964 invoked from network); 28 Oct 2000 12:53:38 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 28 Oct 2000 12:53:38 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 28 Oct 2000 12:53:37 -0000 Received: from f-cpu.org (nas3-45.ras.club-internet.fr [195.36.203.45]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA11615 for ; Sat, 28 Oct 2000 14:53:33 +0200 (MET DST) Message-ID: <39FADB70.A9E4311D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <20001027214525.A20928@ricochet.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 28 Oct 2000 14:58:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 929dacb1ed27acc490b348f69fad4714 Status: R X-Status: N hi,

Adam Haberlach wrote:
>  And above all, we must spend more time on the license then the actual
> design of the system.

if we want the project to ever have a chance to succeed, i think we have
to do the contrary ;-)

> Adam Haberlach
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Nicolas Boulay Sat Oct 28 21:43:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02837 for ; Sun, 29 Oct 2000 03:02:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 29 Oct 2000 03:02:24 +0100 (MET) Received: (qmail 3261 invoked by uid 0); 28 Oct 2000 21:08:00 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net with SMTP; 28 Oct 2000 21:08:00 -0000 X-eGroups-Return: sentto-1101623-1317-972762169-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 28 Oct 2000 19:42:50 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 28 Oct 2000 19:42:49 -0000 Received: (qmail 29323 invoked from network); 28 Oct 2000 19:42:48 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Oct 2000 19:42:48 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 28 Oct 2000 19:42:48 -0000 Received: from ifrance.com (nas13-57.vlt.club-internet.fr [195.36.163.57]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA07764 for ; Sat, 28 Oct 2000 21:42:46 +0200 (MET DST) Message-ID: <39FB2C75.2540C1D7@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 28 Oct 2000 21:43:49 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 69fd647c8bbabd5eba1e3b4863895370 Status: R X-Status: N

Michael Riepe a =E9crit :
>
> On Fri, Oct 27, 2000 at 10:57:12PM +0100, Yann Guidon wrote:
>
> > > > Can we discuss here about what we'll add in this
> > > > file, in front of the GPL ?
> > > Why not?  As long as I understand the language we use ;= )
> > so let's go :-)
>
> Ok, what to add...
>
> We need to clarify what the GPL is going to mean in the context of the=
> F-CPU project.  What is a `binary', what is `source code', and so= on.
> We should not add any restrictions, though (and we must not change the=
> GPL itself).
>

Cf the leon web page, they simply use the LGPL. The source code is the
VHDL. The binaries is what you can produice with. (netlist, hard macro,
what ever you want !). And we can use the LGPL to allow adding
proprietary core.

Not enough ?

nicO

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

eGroups Sponsor=
3D""
=
From Yann Guidon Sun Oct 29 02:46:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02846 for ; Sun, 29 Oct 2000 03:02:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 29 Oct 2000 03:02:27 +0100 (MET) Received: (qmail 22880 invoked by uid 0); 28 Oct 2000 23:42:31 -0000 Received: from f19.egroups.com (64.209.169.107) by mx0.gmx.net with SMTP; 28 Oct 2000 23:42:31 -0000 X-eGroups-Return: sentto-1101623-1318-972776545-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 28 Oct 2000 23:42:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 28 Oct 2000 23:42:24 -0000 Received: (qmail 17450 invoked from network); 28 Oct 2000 23:42:24 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 28 Oct 2000 23:42:24 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 28 Oct 2000 23:42:24 -0000 Received: from f-cpu.org (nas2-203.ras.club-internet.fr [195.36.192.203]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA05611 for ; Sun, 29 Oct 2000 01:42:19 +0200 (MET DST) Message-ID: <39FB737C.FFA9B9A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Oct 2000 01:46:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: multipart/mixed; boundary="------------3B71F7F3BF84D3308AEB5C9A" X-UIDL: c04339e541b497f373e6d0d8a7755278 Status: R X-Status: N --------------3B71F7F3BF84D3308AEB5C9A Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hi !

Nicolas Boulay wrote:
> Cf the leon web page, they simply use the LGPL. The source code is the
> VHDL. The binaries is what you can produice with. (netlist, hard macro,
> what ever you want !). And we can use the LGPL to allow adding
> proprietary core.
>
> Not enough ?

no, otherwise we wouldn't ask the question :-)

I have included a document that was first posted
on this list and is stored by graham seaman at the
opencollector database.

i propose to split one of the parts into other parts,
so we can distinguish between : users (reader),
distributors, implementors and people who modify a file.
this way it will be clearer for everybody what he can do
and what he must do. it will be a sort of re-reading
of the GPL with the F-CPU eyes.

comments welcome. i'll have to update the ROP2 package
soon and i'll need the updated version.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------3B71F7F3BF84D3308AEB5C9A Content-Type: text/html; charset=us-ascii; name="fcpu_0_012.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fcpu_0_012.html" The License Zone

Whygee's FCPU License Proposal

To: f-cpu@egroups.com
From: Yann Guidon [whygee@f-cpu.org]
Date: Sat, 10 Jun 2000 02:03:09 +0200
Subject: [f-cpu] F-CPU licence
This is a proposition and some "meat" for the F-CPU licence rev. 0.01, as everything it is a subject and basis for constructive discussions and should not be considered as definitive : it's just a few things that popped in my brain. Everybody is asked to contribute to this decisive, non-technical side of the project.

What i've done was simply to list the desirable differences and similarities between the GPL and the F-CPU licence. maybe we'll "patch" the GPL later since most of the important things and principles are already written there, with this "patch" as an adaptation of the original text.

(add your name + revision date at the bottom of the list)
(indicate where and what you have modified) 

june 10th 2000, YG v0.010
Original version to F-CPU mailing list
june 24th 2000, David Cary v0.011
Dropped requirement for copyright notice on chip
august 11th 2000, GS
Formatting changes for html version (no content changes).
In particular, paras numbered to allow easier reference.
august 14th 2000, GS v0.012
Removed references to 'intellectual property' and replaced
with references to 'the design'

Prologue

Licences are usually intended to restrict the rights of the end user. This F-CPU licence defines the terms under which the user is given rights as well as responsibilities : the licence also defines duties and the rules of the game for transfers of the design happening when developing the F-CPU.

We stress the point that each user and developer is part of a community and what is good for the community is good for the individual, and vice versa. This is why there is no notion of "customer" and "reseller" in this document, but everybody is considered as an individual who can be a "user" as well as a "developer" according to the direction of the transfer (a "user" uses the design developed by the "developer").

Goal(s)

The goal of this licence is to protect the design created by the F-CPU project.

The idea behind the F-CPU project is mainly to transpose the spirit of the GNU project (including the GPL licence and the sofware developed for the GNU project) to the microelectronics world (EDA, CPU architecture, core blocks, instruction sets, software development kits...). The goal of this document is NOT to specify the project goals because it is documented elsewhere and may evolve.

The F-CPU project is NOT the GNU project. There are certain radical differences : this is not a software-only project, the electronics industry has a different nature and the GPL can't be used as it is. The goal of this document is to adapt the GPL and its spirit to this different context. While the main ideas of freedom remain (in the sense of the GPL), some details change.

This licence is also a "game rule" of the F-CPU community which is composed of users and developers. It defines the way people interact at a general level.

What is in common with the GPL ?

  1. The F-CPU licence differs from the GPL on certain aspects but one can see a parallel between them. The GPL can be applied to a source code, that is : a textual representation of a program and all the derived works (compiled files, non-textual representations etc).
  2. The F-CPU licence specifies the terms and conditions of distribution and development of the design, which is more general than a textual source feeding an EDA software suite. The F-CPU design consists of texts, source codes in various langages, manuals, drawings, all the data that describe the CPU, its structure, its behaviour and its interactions with other components. The design spans from high-level schematics and descriptions up to the mask files (like GDSII) or equivalent files for Programmable Logic Devices. This generalisation includes the principles and ideas behind the architectures, all the necessary files in their respective formats (including but not limited to : VHDL, Verilog, RTL, scripts, pictures, texts, test vectors...).
  3. The scope of this licence stops when it comes to physical process-dependent parameters that do not directly influence the performance or the price of the final product. The thickness of the metal layers, their chemical composition or the deposition details do not directly influence the overall architecture in the general case. Otherwise, the implementor must specify the critical parameters that were used to fabricate the chip and modify the architecture, so the implementation can be reproduced.
  4. The general principle is that one can read the GPL and replace "software" with "F-CPU design". A chip, a final product derived >from the design or any material implementation is considered as a "distribution" when compared to the software world. Hardware has a price, has fabrication, transportation and marketing constraints but all the information that constitute the design can be easily spread through electronic media. A "distribution" also has the obvious constraint to be complete and working, otherwise it is still considered as a "source" and is freely shared.
  5. Like GPL'ed software, the design files can be sold on a physical media (that is : CD-ROM, diskette, magnetic tape or similar persistent medium) under the condition that the same data are also available for free download on the Internet (with ftp or http). This is consistent with the fact that the whole design is freely available without restriction (cf : the following chapter).

Rights and duties :

  1. The distribution, modification and knowledge of the sources (non physical forms of the design, as opposed to the "implementation" of this design) must not be bound or restricted in ANY way.
  2. In particular, you need not be a customer of a F-CPU vendor in order to access the sources of any F-CPU version or derived work. Similarly, in-progress works must be available upon a single request.
  3. The reason for this break from the GPL principle is simple : the F-CPU is not the property of an individual or a company, but belongs to everybody. Anybody must be able to examine, use or modify any version of any document because it is not the exclusive property of a person. If you have your kid in a kindergarten, you think it is normal to visit the location and see if your kid is safe or if nothing wrong happened. Same goes with software. Secrecy has no advantage in the F-CPU community and corresponds to a self-exclusion from the group.
  4. Any implementation of the F-CPU IP must hold a written mention of the version and an Internet address (URL) where the original files are stored. This is meant to ensure that any user can easily use any F-CPU version or variation, simply looking at the chip's package.
  5. For example, this is a recommended format :
    • on the chip : 
        Zoobidah 125089
  see http://www.zoobidah.com/125089/
    • on the web : 
      www.zoobidah.com
 |-- index.html indicates where the design files are located in the site.
 |-- /125085
 |-- /125086  \
 |-- /125087   different implementation versions
 |-- /125088  /
 |-- /125089
 |   |-- index.html
 |   |-- README.TXT
 |   |-- /manuals           \
 |   |-- /datasheets         for every design and version
 |   |-- /sdk               /
 |   |-- /errata (nobody's perfect !)
 |   |-- /sources
 |  ...
...
  6. If the Zoobidah corp. copied and implemented a design of the Artchoon corp. without modifying it, the index.html at http://www.zoobidah.com/125089/ must specify it and point to the original location of the files. Zoobidah may miror the files as well (just in case Artchoon corp. went out of business without warning).
  7. If there was not enough surface on the package, the hardcopy manual provided with the chip as well as the website must ensure that one can find the location of the design files easily in the server, for example with a general index directly reachable from the main page of the site. It is not required that the files are located on the same server, but all the files used to fabricate the chip MUST be available directly through a simple URL.
  8. Specifying an URL on the chip is important when one has to use/acquire a new or old hardware : if several vendors offer several versions of a chip, one can not interpret all the numbers on a package. A direct URL indirectly helps evaluate the characteristics of a certain chip without browsing through a hundred books or web sites, in search of the exact reference. This web hosting is also one part of the user support that a company owes to a customer. It is not considered a "fair sale" to sell something without letting the user know what's inside it. Respecting the practice described in this chapter is one simple way to be more transparent with the users.
  9. All software created for simulating, developing and managing the F-CPU design must be distributed under the terms of the GPL in order to promote and keep the openness and freedom of the project.
  10. Existing software that are not distributed under the terms of the GPL can be ported to a F-CPU platform if these applications are not platform-specific. For example, it is possible to port Mozilla (distributed under the terms of the MPL), LaTeX (under LPPL) or Apache to the F-CPU.
  11. It is not possible to port non-GPL software that interact directly with the machine : device drivers, OS kernels, compilers, debuggers or cpu simulators/emulators. This measure is necessary to keep the platform "free" from industrial pressure, arbitrary biases or the damages of the discontinuing of a product line. It also ensures that the new software matches the specific characteristics of the new hardware with less performance lag (thanks to rewriting rather than recompiling only).
  12. All documentations written about the F-CPU and the associated software must be distributed under the terms of the GFDL (GNU Free Documentation Licence).
  13. The use and distribution of the F-CPU design is allowed under the sole condition that you agree to and respect this F-CPU licence. You do not have to register yourself in a database, you do not need any authorization of any kind and you can do whatever you want with the F-CPU design, except : changing the copyright notices, altering this licence or use it against its spirit.
  14. Unlike some "Open" standards and initiatives, you do not need to fill in a form, pay a fee or a licence to use the F-CPU design. In return, you may not restrict the direct access to the design that you have modified, even for the sake of collecting statistics or polling (or, in general, collecting individual/personal data or going through advertising pages).
When this document will be ready, the big work will be to merge it with the GPL text. we need help for this, because the F-CPU licence must not become incompatible, even though some details differ. see http://www.gnu.org/philosophy/license-list.html 
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
G.Seaman,    14th August 2000. --------------3B71F7F3BF84D3308AEB5C9A-- From Michael Riepe Sun Oct 29 01:53:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02849 for ; Sun, 29 Oct 2000 03:02:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 29 Oct 2000 03:02:29 +0100 (MET) Received: (qmail 22988 invoked by uid 0); 28 Oct 2000 23:53:16 -0000 Received: from c3.egroups.com (208.50.99.225) by mx12.rz2.gmx.net with SMTP; 28 Oct 2000 23:53:16 -0000 X-eGroups-Return: sentto-1101623-1319-972777193-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 28 Oct 2000 23:53:15 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 28 Oct 2000 23:53:12 -0000 Received: (qmail 4741 invoked from network); 28 Oct 2000 23:53:11 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 28 Oct 2000 23:53:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.59) by mta2 with SMTP; 28 Oct 2000 23:53:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00456; Sun, 29 Oct 2000 01:53:07 +0200 Message-ID: <20001029015306.17681@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <39FB2C75.2540C1D7@ifrance.com>; from Nicolas Boulay on Sat, Oct 28, 2000 at 09:43:49PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Oct 2000 01:53:06 +0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 78fe3d0e7d6a114df89347704e1feeb7 Status: R X-Status: N On Sat, Oct 28, 2000 at 09:43:49PM +0200, Nicolas Boulay wrote:

> Cf the leon web page, they simply use the LGPL. The source code is the
> VHDL. The binaries is what you can produice with. (netlist, hard macro,
> what ever you want !). And we can use the LGPL to allow adding
> proprietary core.

I prefer GPL for projects like this.  LGPL is for libraries that must
be linked with proprietary stuff (e.g. lesstif).  It depends on how we
interpret `linked with', though -- is an FPGA with an integrated F-CPU
core `linked with' the F-CPU, is it a `derived work', or is it simply a
`use' of the F-CPU?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sun Oct 29 02:18:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02852 for ; Sun, 29 Oct 2000 03:02:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 29 Oct 2000 03:02:30 +0100 (MET) Received: (qmail 9489 invoked by uid 0); 29 Oct 2000 01:20:01 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 29 Oct 2000 01:20:01 -0000 X-eGroups-Return: sentto-1101623-1320-972782397-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 29 Oct 2000 01:19:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 29 Oct 2000 01:19:57 -0000 Received: (qmail 39365 invoked from network); 29 Oct 2000 01:19:55 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Oct 2000 01:19:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.176) by mta1 with SMTP; 29 Oct 2000 01:19:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00666; Sun, 29 Oct 2000 02:18:39 +0100 Message-ID: <20001029021839.31271@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <39FB737C.FFA9B9A@f-cpu.org>; from Yann Guidon on Sun, Oct 29, 2000 at 01:46:52AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Oct 2000 02:18:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8acd1ac4733d504252d7d9031d8fda0b Status: R X-Status: N On Sun, Oct 29, 2000 at 01:46:52AM +0100, Yann Guidon wrote:

[oh shit, this is HTML...]

> <h2>What is in common with the GPL ?</h2>
> <ol>
> <li>The F-CPU licence differs from the GPL on certain aspects but one
> can see a parallel between them. The GPL can be applied to a source
> code, that is : a textual representation of a program and all the
> derived works (compiled files, non-textual representations etc).

A `derived work' in GPL-speak is a modified version of the *source* code.
Everything else ist a `binary'.

[...]
> <li>
> The general principle is that one can read the GPL and replace "software"
> with "F-CPU design". A chip, a final product derived
> from the design or any material implementation is considered as a "distribution"
> when compared to the software world. Hardware has a price, has fabrication,
> transportation and marketing constraints but all the information that
> constitute the design can be easily spread through electronic media. A
> "distribution" also has the obvious constraint to be complete and
> working, otherwise it is still considered as a "source" and is freely shared.

This is a *binary* distribution, as opposed to a *source* distribution
which will contain the VHDL code, documentation, drawings and so on.

[...]
> <h2>Rights and duties :</h2>
> <ol>
> <li> The distribution, modification and knowledge of the sources
> (non physical forms of the design, as opposed to the "implementation"
> of this design) must not be bound or restricted in ANY way.

The rules of the GPL should apply here.

> <li>
> In particular, you need not be a customer of a F-CPU vendor in order
> to access the sources of any F-CPU version or derived work.
> Similarly, in-progress works must be available upon a single request.
> <li>
> The reason for this break from the GPL principle is simple : the F-CPU
> is not the property of an individual or a company, but belongs to
> everybody. Anybody must be able to examine, use or modify any version
> of any document because it is not the exclusive property of a person.
> If you have your kid in a kindergarten, you think it is normal to
> visit the location and see if your kid is safe or if nothing wrong
> happened. Same goes with software. Secrecy has no advantage in the
> F-CPU community and corresponds to a self-exclusion from the group.

Does this mean you have to send your source tree every time somebody
says so?

[...]
> <li>
>  Any implementation of the F-CPU IP must hold a written
> mention of the version and an Internet address (URL) where the original
> files are stored. This is meant to ensure that any user can easily use
> any F-CPU version or variation, simply looking at the chip's package.

We should set a time limit here, like 5 or 10 years.  Additionally,
the source code must remain *unmodified* all the time -- if somebody
is going to release a second version, the source code to the first one
must still be accessible until it `times out'.

> <li>
> Specifying an URL on the chip is important when one has to use/acquire
> a new or old hardware : if several vendors offer several versions
> of a chip, one can not interpret all the numbers on a package.

Should the URL be `on the chip' or `on the package'?

[...]
> <li>
>  All software created for simulating, developing and managing
> the F-CPU design must be distributed under the terms of the GPL in order
> to promote and keep the openness and freedom of the project.

That will make it *very* hard to produce chips.

> <li>
> Existing software that are not distributed under the terms of the GPL
> can be ported to a F-CPU platform if these applications are not
> platform-specific. For example, it is possible to port Mozilla
> (distributed under the terms of the MPL), LaTeX (under LPPL) or
> Apache to the F-CPU.

This can be considered a `use' of the F-CPU.  I'm not going to tell
people which software they may run on it and which not.  The name of
the game is still `Freedom', isn't it?

> <li>
> It is not possible to port non-GPL software
> that interact directly with the machine : device drivers, OS kernels,
> compilers, debuggers or cpu simulators/emulators. This measure is necessary
> to keep the platform "free" from industrial pressure, arbitrary biases or
> the damages of the discontinuing of a product line. It also ensures that
> the new software matches the specific characteristics of the new hardware
> with less performance lag (thanks to rewriting rather than recompiling only).

I don't like this either.  It stinks.

> <li>
>  All documentations written about the F-CPU and the associated software
> must be distributed under the terms of the GFDL (GNU Free Documentation
> Licence).

If I decide to write an article or a book about the F-CPU, I must put
it under GFDL?  Free documentation is nice, but this is too much.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Nicolas Boulay Sun Oct 29 12:36:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00338 for ; Sun, 29 Oct 2000 20:27:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 29 Oct 2000 20:27:30 +0100 (MET) Received: (qmail 20123 invoked by uid 0); 29 Oct 2000 11:35:48 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 29 Oct 2000 11:35:48 -0000 X-eGroups-Return: sentto-1101623-1321-972819345-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 29 Oct 2000 11:35:47 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 29 Oct 2000 11:35:43 -0000 Received: (qmail 17703 invoked from network); 29 Oct 2000 11:35:43 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Oct 2000 11:35:43 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 29 Oct 2000 11:35:43 -0000 Received: from ifrance.com (nas14-150.vlt.club-internet.fr [195.36.164.150]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA24669 for ; Sun, 29 Oct 2000 12:35:40 +0100 (MET) Message-ID: <39FC0BB5.E88D2C26@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> <20001029021839.31271@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Oct 2000 12:36:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: bdd03760301d87d49ec056f7429909dd Status: R X-Status: N

Michael Riepe a =E9crit :
>
> On Sun, Oct 29, 2000 at 01:46:52AM +0100, Yann Guidon wrote:
>
> [oh shit, this is HTML...]
>
> > <h2>What is in common with the GPL ?</h2>
> > <ol>
> > <li>The F-CPU licence differs from the GPL on certain aspec= ts but one
> > can see a parallel between them. The GPL can be applied to a sour= ce
> > code, that is : a textual representation of a program and all the=
> > derived works (compiled files, non-textual representations etc).<= BR> >
> A `derived work' in GPL-speak is a modified version of the *source* co= de.
> Everything else ist a `binary'.
>
> [...]
> > <li>
> > The general principle is that one can read the GPL and replace &q= uot;software"
> > with "F-CPU design". A chip, a final product derived > > from the design or any material implementation is considered as a= "distribution"
> > when compared to the software world. Hardware has a price, has fa= brication,
> > transportation and marketing constraints but all the information = that
> > constitute the design can be easily spread through electronic med= ia. A
> > "distribution" also has the obvious constraint to be co= mplete and
> > working, otherwise it is still considered as a "source"= and is freely shared.
>
> This is a *binary* distribution, as opposed to a *source* distribution=
> which will contain the VHDL code, documentation, drawings and so on. >
> [...]
> > <h2>Rights and duties :</h2>
> > <ol>
> > <li> The distribution, modification and knowledge of the so= urces
> > (non physical forms of the design, as opposed to the "implem= entation"
> > of this design) must not be bound or restricted in ANY way.
>
> The rules of the GPL should apply here.

I agree !

>
> > <li>
> > In particular, you need not be a customer of a F-CPU vendor in or= der
> > to access the sources of any F-CPU version or derived work.
> > Similarly, in-progress works must be available upon a single requ= est.
> > <li>
> > The reason for this break from the GPL principle is simple : the = F-CPU
> > is not the property of an individual or a company, but belongs to=
> > everybody. Anybody must be able to examine, use or modify any ver= sion
> > of any document because it is not the exclusive property of a per= son.
> > If you have your kid in a kindergarten, you think it is normal to=
> > visit the location and see if your kid is safe or if nothing wron= g
> > happened. Same goes with software. Secrecy has no advantage in th= e
> > F-CPU community and corresponds to a self-exclusion from the grou= p.
>
> Does this mean you have to send your source tree every time somebody > says so?
>
> [...]
> > <li>
> >  Any implementation of the F-CPU IP must hold a written
> > mention of the version and an Internet address (URL) where the or= iginal
> > files are stored. This is meant to ensure that any user can easil= y use
> > any F-CPU version or variation, simply looking at the chip's pack= age.
>
> We should set a time limit here, like 5 or 10 years.  Additionall= y,
> the source code must remain *unmodified* all the time -- if somebody > is going to release a second version, the source code to the first one=
> must still be accessible until it `times out'.
>

If there is many version you should give url for each version ?

> > <li>
> > Specifying an URL on the chip is important when one has to use/ac= quire
> > a new or old hardware : if several vendors offer several versions=
> > of a chip, one can not interpret all the numbers on a package. >
> Should the URL be `on the chip' or `on the package'?
>
> [...]
> > <li>
> >  All software created for simulating, developing and managin= g
> > the F-CPU design must be distributed under the terms of the GPL i= n order
> > to promote and keep the openness and freedom of the project.
>
> That will make it *very* hard to produce chips.
>

Does it mean created "especialy for the design of the fcpu" ? I d= on't
see the usefulness of this rules. If you want to create a GPL CAD tools, it's your probl=E8me. If you want to use synopsys it's your pb, too. We
just need to put a rules about the openness of the format of the file
used (no pb with .doc, any more ! ).

> > <li>
> > Existing software that are not distributed under the terms of the= GPL
> > can be ported to a F-CPU platform if these applications are not > > platform-specific. For example, it is possible to port Mozilla > > (distributed under the terms of the MPL), LaTeX (under LPPL) or > > Apache to the F-CPU.
>
> This can be considered a `use' of the F-CPU.  I'm not going to te= ll
> people which software they may run on it and which not.  The name= of
> the game is still `Freedom', isn't it?
>

Yes, it look a little bit strange.

> > <li>
> > It is not possible to port non-GPL software
> > that interact directly with the machine : device drivers, OS kern= els,
> > compilers, debuggers or cpu simulators/emulators. This measure is= necessary
> > to keep the platform "free" from industrial pressure, a= rbitrary biases or
> > the damages of the discontinuing of a product line. It also ensur= es that
> > the new software matches the specific characteristics of the new = hardware
> > with less performance lag (thanks to rewriting rather than recomp= iling only).
>
> I don't like this either.  It stinks.
>

I agree, too !!! That's signifie that we should write a base BIOS to
allow people to write program for the fcpu ! And what about the used of
the fcpu in a system on chip with no OS, or things like that ? With that rules, you couldn't have any drivers for prephericals.

> > <li>
> >  All documentations written about the F-CPU and the associat= ed software
> > must be distributed under the terms of the GFDL (GNU Free Documen= tation
> > Licence).
>
> If I decide to write an article or a book about the F-CPU, I must put<= BR> > it under GFDL?  Free documentation is nice, but this is too much.=
>

Maybe you could had differences between articles and documentation (like it's size). But books are very usefull to begin with some things. So if
it's written under the GFDL licence, few people would like to take the
time to write such kind of book.

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
nicO
eGroups Sponsor=
3D""
From Michael Riepe Sun Oct 29 15:56:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01967 for ; Mon, 30 Oct 2000 02:45:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 30 Oct 2000 02:45:26 +0100 (MET) Received: (qmail 3712 invoked by uid 0); 29 Oct 2000 19:42:49 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net with SMTP; 29 Oct 2000 19:42:49 -0000 X-eGroups-Return: sentto-1101623-1322-972848560-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 29 Oct 2000 19:42:47 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 29 Oct 2000 19:42:40 -0000 Received: (qmail 14370 invoked from network); 29 Oct 2000 19:42:40 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 29 Oct 2000 19:42:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.124) by mta2 with SMTP; 29 Oct 2000 19:42:34 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00779; Sun, 29 Oct 2000 15:56:47 +0100 Message-ID: <20001029155647.43948@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> <20001029021839.31271@thrai.stud.uni-hannover.de> <39FC0BB5.E88D2C26@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <39FC0BB5.E88D2C26@ifrance.com>; from Nicolas Boulay on Sun, Oct 29, 2000 at 12:36:21PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Oct 2000 15:56:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 51a59c00b32642cfa2a114961cd4b90e Status: R X-Status: N On Sun, Oct 29, 2000 at 12:36:21PM +0100, Nicolas Boulay wrote:

[...]
> > >  Any implementation of the F-CPU IP must hold a written=
> > > mention of the version and an Internet address (URL) where t= he original
> > > files are stored. This is meant to ensure that any user can = easily use
> > > any F-CPU version or variation, simply looking at the chip's= package.
> >
> > We should set a time limit here, like 5 or 10 years.  Additi= onally,
> > the source code must remain *unmodified* all the time -- if someb= ody
> > is going to release a second version, the source code to the firs= t one
> > must still be accessible until it `times out'.
> >
>
> If there is many version you should give url for each version ?

Yes, and the URLs must be different, unless you can build several
variants from the same code base.

BTW: We should reserve some special registers for the URL, in addition
to the family/stepping registers we already have.  That way, people can query it even if the CPU itself is inaccessible for them.  8 or 10=
registers (each of them holding 8 characters) should be enough.

[...]
> > >  All software created for simulating, developing and ma= naging
> > > the F-CPU design must be distributed under the terms of the = GPL in order
> > > to promote and keep the openness and freedom of the project.=
> >
> > That will make it *very* hard to produce chips.
> >
>
> Does it mean created "especialy for the design of the fcpu" = ? I don't
> see the usefulness of this rules. If you want to create a GPL CAD tool= s,
> it's your probl=E8me. If you want to use synopsys it's your pb, too. W= e
> just need to put a rules about the openness of the format of the file<= BR> > used (no pb with .doc, any more ! ).

If people want to write additional documentation in M$.DOC format,
why stop them?  It's still better than no documentation at all.

What tools and file formats people use is *their* choice, not ours.
If they need proprietary tools for manufacturing F-CPU chips -- let
them do it.  Of course they will have to document what they did and which software and libraries they used.

NB: only linking with `system libraries' is allowed.  A library that is not delivered with the synthesis tools *by default* is not a system
library and must be available in source code, and under a license
that is either identical to the F-CPU license, or less restrictive.
The result of the `linkage' shall be covered by the F-CPU license.

[...]
> I agree, too !!! That's signifie that we should write a base BIOS to > allow people to write program for the fcpu ! And what about the used o= f
> the fcpu in a system on chip with no OS, or things like that ? With th= at
> rules, you couldn't have any drivers for prephericals.

Well, a 64-bit CPU may be a little too heavy for embedded systems ;)
But times may change...

[...]
> Maybe you could had differences between articles and documentation (li= ke
> it's size). But books are very usefull to begin with some things. So i= f
> it's written under the GFDL licence, few people would like to take the=
> time to write such kind of book.

What about this?  When someone writes documentation and bundles it wit= h
his version of the F-CPU, the documentation must be freely available under<= BR> the terms of the GFDL -- to make sure that anybody can use, modify and
redistribute the package as a whole -- and it must be in source format
(i.e. no .DOC, .PS, .DVI or .PDF without the corresponding source code).
Independent works covering the F-CPU (e.g. books, newspaper or online
articles) may be published under any license the authors/publishers want. Of course they can't re-print the sources (in whole or in part) without
asking the copyright holder(s) for permission first -- and in that case, we can ask them to release a free version, too.  If they refuse to do<= BR> so -- fine, then we refuse to permit the use of any F-CPU material also. IMHO this is the best deal we can make.

And now for something totally different...

I'd like to restrict changes to the instruction set to ensure binary
compatibility, e.g. like this:

      A derived work MUST implement all mandatory = (non-optional)
      instructions for that core generation *in ha= rdware*.  It MUST
      NOT change the contents of the family/steppi= ng special registers,
      they're reserved for use by the F-CPU projec= t.      (It MUST, however,
      change the URL special registers to indicate= which variant of
      that core generation they implemented.)

      It MUST implement all optional instructions = the original version
      (as released by the F-CPU project) supports.=   If it doesn't
      implement them in silicon, it MUST provide a= software emulation,
      and the emulator MUST be GPLed and distribut= ed in source code
      with the CPU.

      It MAY implement all optional instructions d= efined in the F-CPU
      manual for that core generation, even if the= original F-CPU
      doesn't implement them.

      If an implementation supports a particular i= nstruction, mandatory
      or optional, in hardware or software, it MUS= T work the same
      way the original one does (if it wasn't impl= emented before,
      it MUST work the way the manual says).

      An implementation MUST NOT use unallocated (= i.e. reserved)
      bits in the opcode to enable new operation m= odes.  It MAY use
      unassigned opcodes that are not reserved (we= have to leave
      such a `hole' somewhere) for implementing ne= w instructions.
      To avoid variable-length instructions, it MU= ST NOT use an
      opcode as a `prefix' that effectively switch= es the F-CPU
      to another instruction set, loads additional= data from the
      instruction stream, or something like that.&= nbsp; It MUST document
      any new instructions, and this documentation= is subject to the
      restrictions above (GFDLed, with source), an= d MUST be distributed
      with the CPU in source form.

      The F-CPU project may, at its discretion, re= move a mandatory
      instruction from the instruction set of futu= re F-CPU core
      generations.  This instruction will aut= omatically become optional
      for all later core generations, and a softwa= re emulation will be
      provided to maintain binary compatibility wi= th older software.
      The project may also add new instructions or= make optional
      instructions mandatory, or use reserved bits= in existing
      opcodes to add new operation modes.  It= will not remove optional
      instructions entirely.   &nbs= p;  The project will assign new opcodes from
      the range that is unassigned and reserved, b= ut it will not touch
      the opcodes implementors may use for their o= wn extensions.

Similar rules should apply to the addition and removal of special
registers, IMHO.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D""
From Yann Guidon Mon Oct 30 00:48:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01997 for ; Mon, 30 Oct 2000 02:45:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 30 Oct 2000 02:45:35 +0100 (MET) Received: (qmail 22050 invoked by uid 0); 29 Oct 2000 23:44:18 -0000 Received: from mk.egroups.com (208.50.144.76) by mx19.rz2.gmx.net with SMTP; 29 Oct 2000 23:44:18 -0000 X-eGroups-Return: sentto-1101623-1323-972863053-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 29 Oct 2000 23:44:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 29 Oct 2000 23:44:13 -0000 Received: (qmail 11577 invoked from network); 29 Oct 2000 23:44:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 29 Oct 2000 23:44:12 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 29 Oct 2000 23:44:12 -0000 Received: from f-cpu.org (nas2-212.ras.club-internet.fr [195.36.192.212]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA22674 for ; Mon, 30 Oct 2000 00:44:09 +0100 (MET) Message-ID: <39FCB766.AFEB31BF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> <20001029021839.31271@thrai.stud.uni-hannover.de> <39FC0BB5.E88D2C26@ifrance.com> <20001029155647.43948@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 30 Oct 2000 00:48:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3879993d151816aeb913ca9b52301cc1 Status: R X-Status: N hi !

Michael Riepe wrote:
> BTW: We should reserve some special registers for the URL, in addition
> to the family/stepping registers we already have.  That way, people
> can query it even if the CPU itself is inaccessible for them.  8 or 10
> registers (each of them holding 8 characters) should be enough.

i name this as the "good idea of the week" :-)))
it's far better than writing it on the package ...
yo :-)

i've been playing bass lately, i'll have to catch up on this thread,
but i'm happy that some good ideas appear on the list :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Nicolas Boulay Mon Oct 30 22:02:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA00343 for ; Wed, 1 Nov 2000 03:27:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 01 Nov 2000 03:27:56 +0100 (MET) Received: (qmail 26440 invoked by uid 0); 30 Oct 2000 21:01:57 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net with SMTP; 30 Oct 2000 21:01:57 -0000 X-eGroups-Return: sentto-1101623-1324-972939700-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mk.egroups.com with NNFMP; 30 Oct 2000 21:01:55 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 30 Oct 2000 21:01:40 -0000 Received: (qmail 23017 invoked from network); 30 Oct 2000 21:01:28 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 30 Oct 2000 21:01:28 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 30 Oct 2000 21:01:28 -0000 Received: from ifrance.com (nas13-88.vlt.club-internet.fr [195.36.163.88]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA20804 for ; Mon, 30 Oct 2000 22:01:24 +0100 (MET) Message-ID: <39FDE1D0.CC525E8@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> <20001029021839.31271@thrai.stud.uni-hannover.de> <39FC0BB5.E88D2C26@ifrance.com> <20001029155647.43948@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 30 Oct 2000 22:02:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: aa02208e6f62f1bc5c41ac3f5f2e3093 Status: R X-Status: N

Michael Riepe a =E9crit :
>
> On Sun, Oct 29, 2000 at 12:36:21PM +0100, Nicolas Boulay wrote:
>
> [...]
> > > >  Any implementation of the F-CPU IP must hold a wr= itten
> > > > mention of the version and an Internet address (URL) wh= ere the original
> > > > files are stored. This is meant to ensure that any user= can easily use
> > > > any F-CPU version or variation, simply looking at the c= hip's package.
> > >
> > > We should set a time limit here, like 5 or 10 years.  A= dditionally,
> > > the source code must remain *unmodified* all the time -- if = somebody
> > > is going to release a second version, the source code to the= first one
> > > must still be accessible until it `times out'.
> > >
> >
> > If there is many version you should give url for each version ? >
> Yes, and the URLs must be different, unless you can build several
> variants from the same code base.
>
> BTW: We should reserve some special registers for the URL, in addition=
> to the family/stepping registers we already have.  That way, peop= le
> can query it even if the CPU itself is inaccessible for them.  8 = or 10
> registers (each of them holding 8 characters) should be enough.
>

Maybe a simple little internal rom should be enough.

> [...]
> > > >  All software created for simulating, developing a= nd managing
> > > > the F-CPU design must be distributed under the terms of= the GPL in order
> > > > to promote and keep the openness and freedom of the pro= ject.
> > >
> > > That will make it *very* hard to produce chips.
> > >
> >
> > Does it mean created "especialy for the design of the fcpu&q= uot; ? I don't
> > see the usefulness of this rules. If you want to create a GPL CAD= tools,
> > it's your probl=E8me. If you want to use synopsys it's your pb, t= oo. We
> > just need to put a rules about the openness of the format of the = file
> > used (no pb with .doc, any more ! ).
>
> If people want to write additional documentation in M$.DOC format,
> why stop them?  It's still better than no documentation at all. >

Yes, i speak about source code, not writing it with a specific tools,
with proprietary file format (so, in VHDL ;) ).

> [...]
> > I agree, too !!! That's signifie that we should write a base BIOS= to
> > allow people to write program for the fcpu ! And what about the u= sed of
> > the fcpu in a system on chip with no OS, or things like that ? Wi= th that
> > rules, you couldn't have any drivers for prephericals.
>
> Well, a 64-bit CPU may be a little too heavy for embedded systems ;) > But times may change...
>

ST Microelectronics develop it's own 64 bits microcontroleurs with some
other compagnies (the ST50).

> [...]
> > Maybe you could had differences between articles and documentatio= n (like
> > it's size). But books are very usefull to begin with some things.= So if
> > it's written under the GFDL licence, few people would like to tak= e the
> > time to write such kind of book.
>
> What about this?  When someone writes documentation and bundles i= t with
> his version of the F-CPU, the documentation must be freely available u= nder
> the terms of the GFDL -- to make sure that anybody can use, modify and=
> redistribute the package as a whole -- and it must be in source format=
> (i.e. no .DOC, .PS, .DVI or .PDF without the corresponding source code= ).
>
> Independent works covering the F-CPU (e.g. books, newspaper or online<= BR> > articles) may be published under any license the authors/publishers wa= nt.

Ok, it's what i say : no obligation.

> Of course they can't re-print the sources (in whole or in part) withou= t
> asking the copyright holder(s) for permission first -- and in that cas= e,
> we can ask them to release a free version, too.  If they refuse t= o do
> so -- fine, then we refuse to permit the use of any F-CPU material als= o.
> IMHO this is the best deal we can make.
>

Asking to print some things in GFDL ??

> And now for something totally different...
>
> I'd like to restrict changes to the instruction set to ensure binary > compatibility, e.g. like this:
>
>         A derived work MUST im= plement all mandatory (non-optional)
>         instructions for that = core generation *in hardware*.  It MUST
>         NOT change the content= s of the family/stepping special registers,
>         they're reserved for u= se by the F-CPU project.  (It MUST, however,
>         change the URL special= registers to indicate which variant of
>         that core generation t= hey implemented.)
>

Boaf, it's far away the idea of the GPL. Maybe, we can say that they
can't use the name "fcpu", if they don't respect some rules. Like= a
basic ISA and specials registers are mandatory.

>         It MUST implement all = optional instructions the original version
>         (as released by the F-= CPU project) supports.  If it doesn't
>         implement them in sili= con, it MUST provide a software emulation,
>         and the emulator MUST = be GPLed and distributed in source code
>         with the CPU.
>

If they use it for them (in embedded system for example) and don't call
this processor "fcpu", where is the problem ?

>         It MAY implement all o= ptional instructions defined in the F-CPU
>         manual for that core g= eneration, even if the original F-CPU
>         doesn't implement them= .
>
>         If an implementation s= upports a particular instruction, mandatory
>         or optional, in hardwa= re or software, it MUST work the same
>         way the original one d= oes (if it wasn't implemented before,
>         it MUST work the way t= he manual says).
>

IF they call it FCPU.

>         An implementation MUST= NOT use unallocated (i.e. reserved)
>         bits in the opcode to = enable new operation modes.  It MAY use
>         unassigned opcodes tha= t are not reserved (we have to leave
>         such a `hole' somewher= e) for implementing new instructions.
>         To avoid variable-leng= th instructions, it MUST NOT use an
>         opcode as a `prefix' t= hat effectively switches the F-CPU
>         to another instruction= set, loads additional data from the
>         instruction stream, or= something like that.  It MUST document
>         any new instructions, = and this documentation is subject to the
>         restrictions above (GF= DLed, with source), and MUST be distributed
>         with the CPU in source= form.
>
>         The F-CPU project may,= at its discretion, remove a mandatory
>         instruction from the i= nstruction set of future F-CPU core
>         generations.  Thi= s instruction will automatically become optional
>         for all later core gen= erations, and a software emulation will be
>         provided to maintain b= inary compatibility with older software.
>         The project may also a= dd new instructions or make optional
>         instructions mandatory= , or use reserved bits in existing
>         opcodes to add new ope= ration modes.  It will not remove optional
>         instructions entirely.=   The project will assign new opcodes from
>         the range that is unas= signed and reserved, but it will not touch
>         the opcodes implemento= rs may use for their own extensions.
>

Maybe we can add some things like "But the fcpu team will try to avoid=
such kind of change".

> Similar rules should apply to the addition and removal of special
> registers, IMHO.
>

I'm embarrassed by your proposal because with such licence we are far
away from the GPL. The "soul" of the GPL is that a GPLed object i= s own
by every one and you can't modify the licence because you can't ask
everyone ;) In your case, the design is own by the group. But imagine
some problems inside the group, who will decide. The groupe has no legal existance. So in a trial, how can we defend this rules.

BUT we can protect the name "fcpu". A processor called like that = MUST
have  a specific basic ISA and special register according to the numbe= r
of the core (fc0). 
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

nicO
eGroups Sponsor=
3D""
From Michael Riepe Tue Oct 31 00:10:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA00382 for ; Wed, 1 Nov 2000 03:28:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 01 Nov 2000 03:28:05 +0100 (MET) Received: (qmail 17967 invoked by uid 0); 30 Oct 2000 23:12:24 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net with SMTP; 30 Oct 2000 23:12:24 -0000 X-eGroups-Return: sentto-1101623-1325-972947530-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by fh.egroups.com with NNFMP; 30 Oct 2000 23:12:23 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 30 Oct 2000 23:12:09 -0000 Received: (qmail 32709 invoked from network); 30 Oct 2000 23:12:09 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 30 Oct 2000 23:12:09 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.122) by mta3 with SMTP; 30 Oct 2000 23:11:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02232; Tue, 31 Oct 2000 00:10:44 +0100 Message-ID: <20001031001044.15636@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <39F99734.856D7DE3@f-cpu.org> <20001027205246.51116@thrai.stud.uni-hannover.de> <39F9FA38.ABE8123C@f-cpu.org> <20001028015843.00731@thrai.stud.uni-hannover.de> <39FB2C75.2540C1D7@ifrance.com> <39FB737C.FFA9B9A@f-cpu.org> <20001029021839.31271@thrai.stud.uni-hannover.de> <39FC0BB5.E88D2C26@ifrance.com> <20001029155647.43948@thrai.stud.uni-hannover.de> <39FDE1D0.CC525E8@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <39FDE1D0.CC525E8@ifrance.com>; from Nicolas Boulay on Mon, Oct 30, 2000 at 10:02:08PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 31 Oct 2000 00:10:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1543581d911eec05b049b5a283764dd9 Status: R X-Status: N On Mon, Oct 30, 2000 at 10:02:08PM +0100, Nicolas Boulay wrote:

> > I'd like to restrict changes to the instruction set to ensure binary
> > compatibility, e.g. like this:
[...]
> Boaf, it's far away the idea of the GPL. Maybe, we can say that they
> can't use the name "fcpu", if they don't respect some rules. Like a
> basic ISA and specials registers are mandatory.

That's what I meant.  Users must be able to buy an F-CPU from *any*
vendor and run *any* F-CPU code on it.  If people take the sources and
build a CPU that has a different ISA, then it's no longer an F-CPU.
Of course this is permitted by the license, but that chip must not be
called F-CPU to avoid confusion.

Sorry if *I* confused anybody now ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Tue Oct 31 00:21:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA00385 for ; Wed, 1 Nov 2000 03:28:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 01 Nov 2000 03:28:06 +0100 (MET) Received: (qmail 15205 invoked by uid 0); 30 Oct 2000 23:27:31 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net with SMTP; 30 Oct 2000 23:27:31 -0000 X-eGroups-Return: sentto-1101623-1326-972948448-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 30 Oct 2000 23:27:30 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 30 Oct 2000 23:27:28 -0000 Received: (qmail 47426 invoked from network); 30 Oct 2000 23:21:46 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 30 Oct 2000 23:21:46 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 30 Oct 2000 23:21:46 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 1E3FE32802; Mon, 30 Oct 2000 18:21:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by moonbase.res.wpi.net (Postfix) with ESMTP id 196523B808 for ; Mon, 30 Oct 2000 18:21:27 -0500 (EST) To: f-cpu@egroups.com In-Reply-To: <20001031001044.15636@thrai.stud.uni-hannover.de> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 30 Oct 2000 18:21:27 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] COPYING Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 30a0d4e978232534d1109ca8200876f9 Status: R X-Status: N
What if someone writes code translation code to run F-CPU software on
the Transmeta CPU.

Give the F-CPU version numbers.  That's all you need to do.
It's like the somewhat fragmented Linux market.  People who run Debian use
.deb files.  People who run Mandrake use .rpm files.

No one claims that all software installs everywhere only that all
Linux software runs on Linux.

Rares


On Tue, 31 Oct 2000, Michael Riepe wrote:

> On Mon, Oct 30, 2000 at 10:02:08PM +0100, Nicolas Boulay wrote:
>
> > > I'd like to restrict changes to the instruction set to ensure binary
> > > compatibility, e.g. like this:
> [...]
> > Boaf, it's far away the idea of the GPL. Maybe, we can say that they
> > can't use the name "fcpu", if they don't respect some rules. Like a
> > basic ISA and specials registers are mandatory.
>
> That's what I meant.  Users must be able to buy an F-CPU from *any*
> vendor and run *any* F-CPU code on it.  If people take the sources and
> build a CPU that has a different ISA, then it's no longer an F-CPU.
> Of course this is permitted by the license, but that chip must not be
> called F-CPU to avoid confusion.
>
> Sorry if *I* confused anybody now ;)
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>
>


eGroups Sponsor
From Yann Guidon Fri Nov 3 07:32:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00309 for ; Fri, 3 Nov 2000 18:46:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 03 Nov 2000 18:46:59 +0100 (MET) Received: (qmail 22963 invoked by uid 0); 3 Nov 2000 06:27:29 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net with SMTP; 3 Nov 2000 06:27:29 -0000 X-eGroups-Return: sentto-1101623-1327-973232845-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 03 Nov 2000 06:27:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 3 Nov 2000 06:27:25 -0000 Received: (qmail 12313 invoked from network); 3 Nov 2000 06:27:25 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Nov 2000 06:27:25 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 3 Nov 2000 06:27:24 -0000 Received: from f-cpu.org (nas4-134.aub.club-internet.fr [195.36.145.134]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA18629 for ; Fri, 3 Nov 2000 07:27:22 +0100 (MET) Message-ID: <3A025BE7.B5B64AE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 03 Nov 2000 07:32:07 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-cpu.de accounts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 60ddf0253fe51104369b9347a3ce2a39 Status: R X-Status: N hello,

until now, only me and Sven have access to the f-cpu servers.
Now that more people are seriously involved (they write documents
and take responsibilities), we try to give them more
possibilities to work in good conditions. This includes opening
personal accounts at f-cpu.de for the people who contribute most,
like Michael Riepe or Jean Olivier. If you want to contribute "actively"
to the project, if you want to have an account on the f-cpu server,
please tell us.

have a nice day,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Fri Nov 3 21:53:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02124 for ; Sat, 4 Nov 2000 03:54:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 03:54:21 +0100 (MET) Received: (qmail 4107 invoked by uid 0); 3 Nov 2000 23:45:26 -0000 Received: from fh.egroups.com (208.50.144.71) by mx19.rz2.gmx.net with SMTP; 3 Nov 2000 23:45:26 -0000 X-eGroups-Return: sentto-1101623-1328-973295122-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 03 Nov 2000 23:45:25 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 3 Nov 2000 23:45:22 -0000 Received: (qmail 8190 invoked from network); 3 Nov 2000 23:45:21 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 3 Nov 2000 23:45:21 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.155) by mta3 with SMTP; 3 Nov 2000 23:45:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01150; Fri, 3 Nov 2000 21:53:49 +0100 Message-ID: <20001103215349.12151@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 3 Nov 2000 21:53:49 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] More Code, More Problems... Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" X-UIDL: 4105b3c1f0b813914fa5b53f4df4d2bb Status: R X-Status: N --+HP7ph2BbKc20aGI Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Moin kinnas,

Here's some more `fallout' -- an almost complete 64-bit SIMD add/sub unit
(`almost' because the 8-bit SIMD mode doesn't work yet -- feedback welcome!).

While playing with it, I noticed some restrictions of Simili -- it doesn't
support some valid VHDL constructs, like ports in block statements,
and it is limited to signed 32-bit arithmetics (i.e. `natural' has a
range of 0 to 2**31-1), which makes it hard to test 64-bit and even
32-bit arithmetic units :(

I hope you will like the add/sub unit anyway.  It's fully structural this
time (using a small library of simple elements -- gates, inverters, muxes
and so on -- that can be mapped to vendor-specific components later).
There's also a more detailed description of how to use it and how it
works; please read the comments in iadd.vhdl.

One more thing: we should change the manual entry for the `subb'
instruction.  It's MUCH easier to generate a `positive' borrow because
that mirrors the `addc' instruction (no additional circuitry required,
and no additional delay, of course).  And after all, we borrow 1 from
the next operation, not -1 :)

Now have fun,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
PS: can't we rename the project to `Fun-CPU'? ;)
 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Description: Preliminary F-CPU IAdd EU Content-Disposition: attachment; filename="iadd.vhdl" -- iadd.vhdl -- F-CPU 64-bit Add/Subtract Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: iadd.vhdl,v 1.8 2000/11/03 20:28:20 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity IAdd is generic ( WIDTH : natural := 64 -- do not change! ); port ( A, B : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); -- subtract mode enable Sub : in std_ulogic := '0'; -- saturate/floor mode enable Sat : in std_ulogic := '0'; -- SIMD mode switches U08, U16, U32 : in std_ulogic := '0'; -- outputs Yl, Yh : out std_ulogic_vector(WIDTH-1 downto 0) ); end IAdd; -- Known limitations: -- 1: Not fully tested. -- 2: 8-bit SIMD mode doesn't work yet. -- 3: There was no space (or rather, delay time) to include the avg -- and diff instructions. They will probably need an additional -- output port, unless the MUX components are fast enough. Different -- avg/diff rounding modes won't work either, but `truncate' should -- be sufficient anyway. -- 4: subb mode differs from F-CPU manual. IMHO the manual should -- be changed :) See the rationale in the code below. -- Operating Modes: -- Sub = '0', Sat = '0': add operation -- Sub = '0', Sat = '1': add operation with unsigned saturation (ceiling) -- Sub = '1', Sat = '0': sub operation -- Sub = '1', Sat = '1': sub operation with unsigned saturation (floor) -- carry/borrow is always available on the second output port (Yh); -- that means all operating modes from the manual are supported: -- add, addc, adds, sub, subb and subf. -- SIMD Modes: -- U08 = '0', U16 = '0', U32 = '0': 8-bit mode (does not work yet) -- U08 = '1', U16 = '0', U32 = '0': 16-bit mode -- U08 = '1', U16 = '1', U32 = '0': 32-bit mode -- U08 = '1', U16 = '1', U32 = '1': 64-bit mode -- (others combinations are invalid) -- Note: I intend to use this encoding scheme everywhere; it seems -- to be the most appropriate one. -- Modus Operandi: -- The IAdd unit is a carry-select adder with some special features. -- The first part calculates 4-bit results both with and without carry. -- These 4-bit results are put together to form 16-bit results (again, -- both with and without carry) in the first carry-select stage. The -- second (final) carry-select stage creates larger results, and also -- does the SIMD selection for results >= 16 bits. 8-bit SIMD is not -- supported yet due to timing problems -- I guess I have to tap -- the 4-bit results and handle 8-bit mode separately. Ideas welcome. -- -- Subtraction is implemented as `not ((not A) + B)' rather than the -- usual `A + (not B) + 1' because that makes the saturation modes -- easier -- and we don't need a carry input either, which simplifies -- the SIMD stuff in the final carry-select stage. Expressed as a -- simple equation, this unit calculates: -- -- Yl := (((A xor Sub) + B) or (Sat and Carry)) xor Sub -- Yh := 1 when Carry is set, 0 otherwise -- -- where `Carry' is the appropriate carry output from the adder; -- any other signals can be found in the entity declaration. -- Implementation: -- The whole unit consist of ordinary and/or gates with up to 4 inputs, -- 2-input xor gates, inverters and 2:1 muxes. This also applies to the -- HA (half adder), MULTI_CLA and SIMD_CLA (carry look-ahead) subunits. -- In timing calculations, all gates are assumed to have a delay of 1, -- muxes count as 2 delays (in FPGAs, they will probably occupy a -- single cell; in standard CMOS, they can be made faster, too). -- Some basic elements may be optimized further if the target supports -- arbitrary functions of 3 or 4 inputs, e.g. the half adders can -- be combined with the input inverters. With the conservative -- assumptions above, the unit has a delay of 12, and it can be split -- in the middle (at d=6) to form two pipeline stages. *schwitz* :) architecture Struct_1 of IAdd is component AND2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component AND3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component AND4 is -- assume d=1 port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component XOR2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component OR4 is -- assume d=1 port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component NOT1 is -- assume d=1 port (A : in std_ulogic; Y : out std_ulogic); end component; component MUX2 is -- assume d=2 port (A0, A1, Sel : in std_ulogic; Y : out std_ulogic); end component; component HA is -- assume d=1 port (A, B : in std_ulogic; Sum, Carry : out std_ulogic); end component; component MULTI_CLA is -- assume d=2 port ( Gi, Pi : in std_ulogic_vector(3 downto 0) := (others => '0'); CoNC : out std_ulogic_vector(3 downto 0); CoCY : out std_ulogic_vector(3 downto 0); Go, Po : out std_ulogic ); end component; component SIMD_CLA is -- assume d=2 port ( Gi, Pi : in std_ulogic_vector(3 downto 0) := (others => '0'); U1, U2 : in std_ulogic := '0'; Co : out std_ulogic_vector(3 downto 0) ); end component; signal G0, P0, C1_nc, C1_cy : std_ulogic_vector(WIDTH-1 downto 0); signal G1, P1, C2_nc, C2_cy : std_ulogic_vector(WIDTH/4-1 downto 0); signal G2, P2, C3 : std_ulogic_vector(WIDTH/16-1 downto 0); signal Y4_nc, Y4_cy : std_ulogic_vector(WIDTH-1 downto 0); signal Y16_nc, Y16_cy : std_ulogic_vector(WIDTH-1 downto 0); signal S : std_ulogic_vector(WIDTH/8-1 downto 0) := (others => '0'); signal un08, un16, un32 : std_ulogic; begin -- input stage -- d=2 input : for i in 0 to WIDTH-1 generate -- Behaviour: -- Sum(i) <= (A(i) xor Sub) xor B(i); -- Carry(i) <= (A(i) xor Sub) and B(i); bl : block -- local signals signal An : std_ulogic; begin -- invert operand for subtraction inv_a : XOR2 port map (A => A(i), B => Sub, Y => An); -- a row of half adders add : HA port map (A => An, B => B(i), Sum => P0(i), Carry => G0(i)); end block; end generate; -- first-level CLA, w/ and w/o carry-in -- d=4 cla1 : for i in 0 to WIDTH/4-1 generate -- Behaviour: see multicla.vhdl multi : MULTI_CLA port map ( Gi => G0(4*i+3 downto 4*i), Pi => P0(4*i+3 downto 4*i), CoNC => C1_nc(4*i+3 downto 4*i), CoCY => C1_cy(4*i+3 downto 4*i), Go => G1(i), Po => P1(i) ); end generate; -- precomputed 4-bit partial results -- d=5 res4 : for i in 0 to WIDTH-1 generate -- Behaviour: -- Y4_nc(i) <= P0(i) xor C1_nc(i); -- Y4_cy(i) <= P0(i) xor C1_cy(i); nc : XOR2 port map (A => P0(i), B => C1_nc(i), Y => Y4_nc(i)); cy : XOR2 port map (A => P0(i), B => C1_cy(i), Y => Y4_cy(i)); end generate; -- second-level CLA, w/ and w/o carry -- d=6 cla2 : for i in 0 to WIDTH/16-1 generate -- Behaviour: see multicla.vhdl multi : MULTI_CLA port map ( Gi => G1(4*i+3 downto 4*i), Pi => P1(4*i+3 downto 4*i), CoNC => C2_nc(4*i+3 downto 4*i), CoCY => C2_cy(4*i+3 downto 4*i), Go => G2(i), Po => P2(i) ); end generate; -- TODO: ADD PIPELINE REGISTER HERE !!! -- 16-bit partial result muxes -- d=8 res16 : for i in 0 to WIDTH-1 generate -- Behaviour: -- Y16_nc(i) <= Y4_cy(i) when C2_nc(i/4) = '1' else Y4_nc(i); -- Y16_cy(i) <= Y4_cy(i) when C2_cy(i/4) = '1' else Y4_nc(i); nc : MUX2 port map ( A0 => Y4_nc(i), A1 => Y4_cy(i), Sel => C2_nc(i/4), Y => Y16_nc(i) ); cy : MUX2 port map ( A0 => Y4_nc(i), A1 => Y4_cy(i), Sel => C2_cy(i/4), Y => Y16_cy(i) ); end generate; -- third-level CLA, w/ variable carry -- d=8 cla3 : for i in 0 to WIDTH/64-1 generate -- Similar to the `normal' CLA entity, but this -- one is influenced by the SIMD mode lines. -- Behavior: -- Co <= ( -- 0 => '0', -- 1 => (U1 and Gi(0)), -- 2 => (U2 and Gi(1)) -- or (U2 and Pi(1) and Gi(0)), -- 3 => (U1 and Gi(2)) -- or (U2 and Pi(2) and Gi(1)) -- or (U2 and Pi(2) and Pi(1) and Gi(0)) -- ); -- This used to be a block statement, but Symphony EDA -- doesn't support blocks with ports in them, yet :( -- Therefore it's now a separate entity. nc : SIMD_CLA port map ( Gi => G2(4*i+3 downto 4*i), Pi => P2(4*i+3 downto 4*i), Co => C3(4*i+3 downto 4*i), U1 => U16, U2 => U32 ); end generate; -- saturate/carry logic -- d=10 sat_and_carry : block -- Note!!! some signals are not driven explicitly! signal C08, C16, C32, C64 : std_ulogic_vector(WIDTH/8-1 downto 0) := (others => '0'); begin -- mode switches inverted -- (only used here, but can be moved anywhere) modeinv : block begin u08_n : NOT1 port map (U08, un08); u16_n : NOT1 port map (U16, un16); u32_n : NOT1 port map (U32, un32); end block; -- carry output vectors for each width -- d=8 carry08 : for i in WIDTH/8-1 downto 0 generate -- 8-bit carry out -- C08(i) <= G1(2*i+1) or (P1(2*i+1) and G1(2*i)); bl : block signal t : std_ulogic; begin tmp : AND2 port map (P1(2*i+1), G1(2*i), t); co : OR2 port map (G1(2*i+1), t, C08(i)); end block; end generate; carry16 : for i in WIDTH/16-1 downto 0 generate -- 16-bit carry out C16(2*i) <= G2(i); end generate; carry32 : for i in WIDTH/32-1 downto 0 generate -- 32-bit carry out -- C32(4*i) <= G2(2*i+1) or (P2(2*i+1) and G2(2*i)); bl : block signal t : std_ulogic; begin tmp : AND2 port map (P2(2*i+1), G2(2*i), t); co : OR2 port map (G2(2*i+1), t, C32(4*i)); end block; end generate; carry64 : for i in WIDTH/64-1 downto 0 generate -- 64-bit carry out -- C64(8*i) <= (G2(4*i+3)) -- or (P2(4*i+3) and G2(4*i+2)) -- or (P2(4*i+3) and P2(4*i+2) and G2(4*i+1)) -- or (P2(4*i+3) and P2(4*i+2) and P2(4*i+1) and G2(4*i+0)); bl : block signal t1, t2, t3 : std_ulogic; begin tmp1 : AND2 port map (P2(4*i+3), G2(4*i+2), t1); tmp2 : AND3 port map (P2(4*i+3), P2(4*i+2), G2(4*i+1), t2); tmp3 : AND4 port map (P2(4*i+3), P2(4*i+2), P2(4*i+1), G2(4*i+0), t3); co : OR4 port map (G2(4*i+3), t1, t2, t3, C64(8*i)); end block; end generate; -- saturate vector (taken from carry outputs) -- d=10 saturate : for i in WIDTH/8-1 downto 0 generate bl : block alias S08 : std_ulogic is C08(i); alias S16 : std_ulogic is C16(2*(i/2)); alias S32 : std_ulogic is C32(4*(i/4)); alias S64 : std_ulogic is C64(8*(i/8)); signal t1, t2, t3, t4 : std_ulogic; begin -- Behaviour: -- S(i) <= (Sat and S08 and not U08) -- or (Sat and S16 and U08 and not U16) -- or (Sat and S32 and U16 and not U32) -- or (Sat and S64 and U32); tmp1 : AND3 port map (Sat, S08, un08, t1); tmp2 : AND4 port map (Sat, S16, U08, un16, t2); tmp3 : AND4 port map (Sat, S32, U16, un32, t3); tmp4 : AND3 port map (Sat, S64, U32, t4); sat : OR4 port map (t1, t2, t3, t4, S(i)); end block; end generate; -- high output vector -- d=10 high_out : for i in WIDTH/8-1 downto 0 generate bl : block signal t1, t2, t3, t4, t5 : std_ulogic; begin -- Behaviour: -- Yh(8*i) <= (C08(i) and not U08) -- or (C16(i) and U08 and not U16) -- or (C32(i) and U16 and not U32) -- or (C64(i) and U32); tmp1 : AND2 port map (C08(i), un08, t1); tmp2 : AND3 port map (C16(i), U08, un16, t2); tmp3 : AND3 port map (C32(i), U16, un32, t3); tmp4 : AND2 port map (C64(i), U32, t4); tmp5 : OR4 port map (t1, t2, t3, t4, t5); -- -- Note that this differs from the F-CPU -- manual, Rev.0.2. In the manual, the -- `subb' borrow output is set to all 1's -- (numeric value -1) while this unit -- sets it to the numeric value 1. -- This is much easier to do in the -- presence of SIMD, and it's also -- more logical: `borrow -1' actually -- means `add 1', which is wrong. -- Yh(8*i) <= t5; Yh(8*i+7 downto 8*i+1) <= (others => '0'); end block; end generate; end block; -- output stage -- d=12 output : for i in 0 to WIDTH-1 generate bl : block -- local signals signal Y64, Y64_sat : std_ulogic; begin -- 64-bit result mux -- d=10 mux : MUX2 port map ( A0 => Y16_nc(i), A1 => Y16_cy(i), Sel => C3(i/16), Y => Y64 ); -- handle saturate/floor mode -- d=11 sat_or : OR2 port map (A => Y64, B => S(i/8), Y => Y64_sat); -- invert output for subtraction -- d=12 inv_y : XOR2 port map (A => Y64_sat, B => Sub, Y => Yl(i)); end block; end generate; end Struct_1; -- vi: set ts=4 sw=4 : please --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Description: Modified Carry Look-Ahead Unit for Carry-Select Adders Content-Disposition: attachment; filename="multicla.vhdl" -- multicla.vhdl -- Multi-Output 4-Bit Carry Look-Ahead Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: multicla.vhdl,v 1.2 2000/11/03 15:58:36 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity MULTI_CLA is port ( -- inputs Gi, Pi : in std_ulogic_vector(3 downto 0) := (others => '0'); -- outputs CoNC : out std_ulogic_vector(3 downto 0); CoCY : out std_ulogic_vector(3 downto 0); Go, Po : out std_ulogic ); end MULTI_CLA; architecture Behave_1 of MULTI_CLA is begin CoNC <= ( 3 => Gi(2) or (Pi(2) and Gi(1)) or (Pi(2) and Pi(1) and Gi(0)), 2 => Gi(1) or (Pi(1) and Gi(0)), 1 => Gi(0), 0 => '0' ); CoCY <= ( 3 => Gi(2) or (Pi(2) and Gi(1)) or (Pi(2) and Pi(1) and Gi(0)) or (Pi(2) and Pi(1) and Pi(0)), 2 => Gi(1) or (Pi(1) and Gi(0)) or (Pi(1) and Pi(0)), 1 => Gi(0) or Pi(0), 0 => '1' ); Go <= Gi(3) or (Pi(3) and Gi(2)) or (Pi(3) and Pi(2) and Gi(1)) or (Pi(3) and Pi(2) and Pi(1) and Gi(0)); Po <= Pi(3) and Pi(2) and Pi(1) and Pi(0); end Behave_1; architecture Struct_1 of MULTI_CLA is component AND2 is port (A, B : in std_ulogic; Y : out std_ulogic); end component; component AND3 is port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component AND4 is port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component OR2 is port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR3 is port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component OR4 is port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; signal t : std_ulogic_vector(7 downto 0); begin -- common terms tmp0 : AND2 port map (Pi(1), Gi(0), t(0)); tmp1 : AND2 port map (Pi(2), Gi(1), t(1)); tmp2 : AND3 port map (Pi(2), Pi(1), Gi(0), t(2)); tmp3 : AND2 port map (Pi(1), Pi(0), t(3)); tmp4 : AND3 port map (Pi(2), Pi(1), Pi(0), t(4)); tmp5 : AND2 port map (Pi(3), Gi(2), t(5)); tmp6 : AND3 port map (Pi(3), Pi(2), Gi(1), t(6)); tmp7 : AND4 port map (Pi(3), Pi(2), Pi(1), Gi(0), t(7)); -- outputs for Ci = '0' con0 : CoNC(0) <= '0'; con1 : CoNC(1) <= Gi(0); con2 : OR2 port map (Gi(1), t(0), CoNC(2)); con3 : OR3 port map (Gi(2), t(1), t(2), CoNC(3)); -- outputs for Ci = '1' coc0 : CoCY(0) <= '1'; coc1 : OR2 port map (Gi(0), Pi(0), CoCY(1)); coc2 : OR3 port map (Gi(1), t(0), t(3), CoCY(2)); coc3 : OR4 port map (Gi(2), t(1), t(2), t(4), CoCY(3)); -- generate output gen : OR4 port map (Gi(3), t(5), t(6), t(7), Go); -- propagate output prop : AND4 port map (Pi(3), Pi(2), Pi(1), Pi(0), Po); end Struct_1; -- vi: set ts=4 sw=4 : please --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Description: Modified Carry Look-Ahead Unit with SIMD Capabilities Content-Disposition: attachment; filename="simd_cla.vhdl" -- simd_cla.vhdl -- SIMD-enabled Carry Look-Ahead Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: simd_cla.vhdl,v 1.2 2000/11/03 15:58:36 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity SIMD_CLA is port ( -- propagate/generate inputs Gi, Pi : in std_ulogic_vector(3 downto 0) := (others => '0'); -- SIMD mode U1, U2 : in std_ulogic := '0'; -- carry out Co : out std_ulogic_vector(3 downto 0) ); end SIMD_CLA; architecture Struct_1 of SIMD_CLA is component AND2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component AND3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component AND4 is -- assume d=1 port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component OR2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; signal t1, t2, t3, t4, t5 : std_ulogic; begin -- Behavior: -- Co <= ( -- 0 => '0', -- 1 => (U1 and Gi(0)), -- 2 => (U2 and Gi(1)) -- or (U2 and Pi(1) and Gi(0)), -- 3 => (U1 and Gi(2)) -- or (U2 and Pi(2) and Gi(1)) -- or (U2 and Pi(2) and Pi(1) and Gi(0)) -- ); co_0 : Co(0) <= '0'; co_1 : AND2 port map (U1, Gi(0), Co(1)); tmp1 : AND2 port map (U2, Gi(1), t1); tmp2 : AND3 port map (U2, Pi(1), Gi(0), t2); co_2 : OR2 port map (t1, t2, Co(2)); tmp3 : AND2 port map (U1, Gi(2), t3); tmp4 : AND3 port map (U2, Pi(2), Gi(1), t4); tmp5 : AND4 port map (U2, Pi(2), Pi(1), Gi(0), t5); co_3 : OR3 port map (t3, t4, t5, Co(3)); end Struct_1; -- vi: set ts=4 sw=4 : please --+HP7ph2BbKc20aGI Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Description: Component Library Content-Disposition: attachment; filename="lib.tar.gz" H4sIAGjhAjoCA+2da3OiSBfH8zZ+ivNiqyapUgfoVmd0Z2uJSSY+NbmsMc8k+yaF2Co7CBZg Lt/+OY2AF7wkO4rzJKervCHn9OXY/v7Q3WBb7Y+G09GKD/2OvbedpCpKmXPYAwA1egUtepVv FVYBqKiVCi+xSonjXppWUfdA2csgjfzA8AD2BpbZN8TyJsDdut29N5cKBUjCD/hBK1jOcBSA fnEMPSMQOdxWd4fPntXrB3BQP8RwKQqcj1sLmpYYCvg9arw//WDUKY4cq9A3HMd9EF6xI/5A F9JLq2/5MPTcnmcMAN92PSHAd7vBo+GJGjy7IzANBzzRsfzAs9qjQIAVyNJ9dD0YuB2r+yz9 4LaR0xEeBH0BgfAGPrjd8MPXixv4KhzhGTZcjdq2ZcI3yxSOL8DArOUWvy860A79SItTWYbr qAxw6qJjI7BcpwbCwu89wCr4+Bm0OI/IYR5cTzo5MAJZcg/cobQ7xOI+g43tlpgWl1R/UssO WE7ou+9iWwZ9dIl1fLRsG9oCRr7ojuy8dIE7w/dG6+zypoXxuYPverOpX7Tuarhz0HfxW/Eg xq6swdC20DPWyzOc4BmLLz2cnzTrZ2iiHzW+NVp3WAk4bbQuTq6v4fSyCTpc6c1Wo37zTW/C 1U3z6vL6pAhwLWSxwp/CiibuhlHCZuyIwLBsP674HQbWx9LZHegbDwIDbArrActmgIk/rPXB k04M23V6YTVx50lD1sDqguMGeXj0LPy9BG46rNJ8Etk8NByzmIdypQTnhu+D/oDBrBuDtmd1 evj2XAdFU9nnPNxc68WctP6t0alOekn+AdQiC7vBR1X5yFRQSlWtXFU4RN0ATp6G8FsuZ1tt z/CeoXFyclLLYSDDd0U/6Nzbbs8y71W1zIuGbddyOeEEFoYJu52Gv47c/tD1sLvl9vf1PBxB Vf5EpN0oNKzh9jvcKEM+2ZrbP6yhn07oBF0antnHRjGDEQblSMjGv1dlc8eZtEXPcnLo6fcv GHqsIByNHcQ713J7lN52ssf8Zzvlf0lJ8b9cIv5nx3+W8J8R/4n/xP+F/GeZ8J+l+Y8FfL0E YGskAFsiAcLnOgmBd8V/vlP+l9X08b9C/M+O/zzhPyf+E/+J/wv5zzPhP1/I/zwcv14C8DUS gK+UAOHzMQmBN8//rrFN+q/nfxm7Tsz/coVJ/iuMEf8z4n8Ufkl/tdBG9CBvbDA6yFiiP9Gf 6I/0j/pIyH5thv28Wvpc5Z83wP5T/cVH/tejgSy2hxks5f+pPk//68AbmcGY/lFmpjsYug4W AG4vm+ORh6gAC8cdIK03MLd9mV3iCXOdcnuu/0dj834X1eqlrn2r5+CPJFBx9+lGiWRMIAbD e/ldWJ8wy4ExxGzhyx8Q1glfsQB38jVQZRZd494fDZaYBGpkU49ssOkjIzNs/XEFl2dUnzYO QxbFJ47GbiWV5H9/x/znvJziP6fx/6z435/nf9+wu8R/4j/xP+F/f4r/6hz/NaXKSxvg/5n+ spH/l8D/bCX8z+bhn0w72Cz8N6gpIrz3V7F6Hu8RqvsxqsNarrH59Qi9ff4PjH+0bU4AWMf/ iqLN85+V6fx/VvyfhH88AdDtFpjc6HryX4kGAUgGkAyIZMCkqyxUAqVKlW3iTMDkoPknpwGE jlYpgUlOWxcDl83tnAfIQ6Dhg605H/AS+I/PB4Qm2hKTo7nTAYGWmLAlJvXIRI9NmDTBn9K9 Jk1kuyw76SBrVh/bRMZ3G9YmMf/57vjPeEWd4j8f879M/M+Q/3yW/5z4T/wn/i/kP8+G/5ua BhD6WicBeFYS4P9RWOCD46OEjzI+Kvj4lI3Y0F8vNmKT4xmxEZrwl0oanpiU1pgkuZQSk/Ia FZSYlBOTyqtVUFBJjD8tMeaxcSk2LsfGnxL9xUPj9KBPJTb+tCXZ9aud/2G71H+KqqT0X4mT /stO/zE+tQCE9B/pP9J/y/Qfy0b/sQ3qP7ZO/7HM9B9foNQW1emnxNovfyboFeLseP7kEY/F CxuLF/4y2XQci6K3LWco/Rv9Z2718h9rx/80nlr/q2oa6b+s9J+ZvvzH+ci2hVeok/wj+Ufy L5F/ZgaXADmv//wVQNDHqqU/URaRMMJ2NAW2QqjHDnP70eZ9bFapKOCD+uEwXAt0cBR/wgaW e4wXDeEWWRxh+4mFMmOhpCyUsQXuYXUjWReVgpYb7YL/bKf8Z1Pzf4j/O+B/+vIfxH/iP/E/ zX+WBf83M/WnzlZLALZMAmBeL1MB4af6v9cEE3tSCDvl/+hpt9f/LLN5/jNWIf5nxf84/DMn AG5uCfuEfcK+xH7cQULu821x/+Z2/sBfyYOu5jEI9mvhj75W0j/Ka+baHyo8IoLD3EKAA9Jb gK4QcN84/7EXqTvlv5Y6/mcarf/Jiv9J+CX/Ly5bdMxP8Cf4x/BPesdWD/qx26lz8H8l8qWH VciPc5hGPtYNdML7e+e/6+12/F9h6fF/TvzPiv9x+KcP/xEKpAJIBZAKiFRA3Ee2KgLi5TE/ M/KPPlapgCiL2Wt+Yujoxh/vmv+7Hf9XFsz/4zT+nx3/0+P/xH/iP/F/mv8sC/5vZOQf3ayW AGyxBJBPdN+Pd8l/vlv+lxbwn9Z/Zsf/9O0/iP/Ef+L/NP95Fvzf1KJP9LRaAvAVEkA+0W0/ 3hH/h9gTfrH7f3KFrv+VFf+T8EsBcKUjDQj9hH5Cf4T+pHtslf1hv5uH/9dXYl86WcX9OJNZ 8Iez/r5Oz/n78PcH4v/74b8nejs9/udaKXX/T43u/5UV/+PwS/zXbdf8gX/R/zU8y2jbovDd 6uBfbxP/MPyA7gdCooBEQSgK4j6zVU2AvS6UBD3ZENgCUhV8bxy3zlABOAbSHRun+gXKPBQA E+VQt3/koekHi9RD6kzC/QMKBdc7CB0XVOi4jw42nCI97v+V0hpLd09ECJZ6lQaJKjW/8DAu 8+zKQ1mJsS6JVwf+JTXLgSu7oy+vZCSXDk5WGnqWbzm9e4Gxkx4PZ82OaUnhQv4/bXkC4Pr5 fxVa/7c7/j8tmgB4SyMARHwi/oT4T5lMAbzdxBzA2zWTAG8XzgJ8ommAlChRokSJEiVKlChR ovSG0/8A9TLmNACgAAA= --+HP7ph2BbKc20aGI-- From Colin Marquardt Sat Nov 4 05:41:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA02715 for ; Sat, 4 Nov 2000 08:03:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 08:03:51 +0100 (MET) Received: (qmail 22427 invoked by uid 0); 4 Nov 2000 04:41:44 -0000 Received: from fj.egroups.com (64.209.169.104) by mx0.gmx.net with SMTP; 4 Nov 2000 04:41:44 -0000 X-eGroups-Return: sentto-1101623-1329-973312895-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 04 Nov 2000 04:41:37 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 4 Nov 2000 04:41:34 -0000 Received: (qmail 3560 invoked from network); 4 Nov 2000 04:41:34 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 4 Nov 2000 04:41:34 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 4 Nov 2000 04:41:34 -0000 Received: from morphin.marquardt-home.de (e245.nas22.sonic.net [209.204.142.245]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA07897 for ; Sat, 4 Nov 2000 05:41:30 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13rv94-0000GG-00 for ; Fri, 03 Nov 2000 20:41:34 -0800 To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> <20001103215349.12151@thrai.stud.uni-hannover.de> X-Now-Playing: Arch Enemy's Burning Bridges - Diva Satanica (Bonus track) In-Reply-To: Michael Riepe's message of "Fri, 3 Nov 2000 21:53:49 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Nov 2000 20:41:32 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] More Code, More Problems... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ef15a4ccb289d5893cab26f3c53da7c Status: R X-Status: N Michael Riepe <michael@stud.uni-hannover.de> writes:

> Moin kinnas,

Nahmd Purche,

> While playing with it, I noticed some restrictions of Simili -- it doesn't
> support some valid VHDL constructs, like ports in block statements,
> and it is limited to signed 32-bit arithmetics (i.e. `natural' has a
> range of 0 to 2**31-1), which makes it hard to test 64-bit and even
> 32-bit arithmetic units :(

The LRM states that each tool has to support at least 32bit integers,
and that's what most of them do AFAIK. Relying on a possibly larger
implementation in another tool is just not portable.


Cheers,
  Colin
eGroups Sponsor
From Yann Guidon Sat Nov 4 07:32:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA02721 for ; Sat, 4 Nov 2000 08:03:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 08:03:52 +0100 (MET) Received: (qmail 10180 invoked by uid 0); 4 Nov 2000 06:28:12 -0000 Received: from ef.egroups.com (64.209.169.102) by mx0.gmx.net with SMTP; 4 Nov 2000 06:28:12 -0000 X-eGroups-Return: sentto-1101623-1330-973319289-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 04 Nov 2000 06:28:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 4 Nov 2000 06:28:09 -0000 Received: (qmail 22897 invoked from network); 4 Nov 2000 06:28:08 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 4 Nov 2000 06:28:08 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 4 Nov 2000 06:28:08 -0000 Received: from f-cpu.org (nas4-78.ras.club-internet.fr [195.36.203.78]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA01882 for ; Sat, 4 Nov 2000 07:28:04 +0100 (MET) Message-ID: <3A03AD91.9F6593BC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> <20001103215349.12151@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 04 Nov 2000 07:32:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] More Code, More Problems... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8cafcb6d6e1f1e350abce05968672012 Status: R X-Status: N Michael Riepe wrote:
> Moin kinnas,
halli hallo, liebe Freunde,

> Here's some more `fallout' -- an almost complete 64-bit SIMD add/sub unit
> (`almost' because the 8-bit SIMD mode doesn't work yet -- feedback welcome!).
i didn't read it yet. i have a lot to catch up. i'll be ready in several days.

> I hope you will like the add/sub unit anyway.  It's fully structural this
> time (using a small library of simple elements -- gates, inverters, muxes
> and so on -- that can be mapped to vendor-specific components later).
> There's also a more detailed description of how to use it and how it
> works; please read the comments in iadd.vhdl.
jo :-) i'll check it carefully. whenever i have time, of course.
but it's priority #1.

> One more thing: we should change the manual entry for the `subb'
> instruction.  It's MUCH easier to generate a `positive' borrow because
> that mirrors the `addc' instruction (no additional circuitry required,
> and no additional delay, of course).  And after all, we borrow 1 from
> the next operation, not -1 :)
heck, i was thinking about "adding -1" which is exactly "subbing 1".
we'll discuss about it more deeply soon. but it's a pertinent remark :-)

> Now have fun,
Don't worry,

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>  PS: can't we rename the project to `Fun-CPU'? ;)
"yet another acronym" ? there were also : "This french CPU" or "This f*ck*ng CPU"
or "The First Chocolate Powered Utopia" or "The First Cheese Powered Utopia" :-)
i don't know if "fun-cpu" is as witty as you'd think, because before we get to the
current point, it was a real pain in what you referred to in another mail...
but if you like it, why not ? :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Nicolas Boulay Sat Nov 4 17:46:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA04777 for ; Sat, 4 Nov 2000 23:44:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 23:44:28 +0100 (MET) Received: (qmail 7186 invoked by uid 0); 4 Nov 2000 16:45:33 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net with SMTP; 4 Nov 2000 16:45:33 -0000 X-eGroups-Return: sentto-1101623-1331-973356327-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 04 Nov 2000 16:45:31 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 4 Nov 2000 16:45:27 -0000 Received: (qmail 11106 invoked from network); 4 Nov 2000 16:45:26 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 4 Nov 2000 16:45:26 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 4 Nov 2000 16:45:26 -0000 Received: from ifrance.com (nas20-184.vlt.club-internet.fr [195.36.170.184]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA07377 for ; Sat, 4 Nov 2000 17:45:24 +0100 (MET) Message-ID: <3A043D82.3D377951@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> <20001103215349.12151@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 04 Nov 2000 17:46:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] More Code, More Problems... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 85c9eb77b8499362bec2e3c3fdadef76 Status: R X-Status: N

Michael Riepe a =E9crit :

> While playing with it, I noticed some restrictions of Simili -- it doe= sn't
> support some valid VHDL constructs, like ports in block statements, > and it is limited to signed 32-bit arithmetics (i.e. `natural' has a > range of 0 to 2**31-1), which makes it hard to test 64-bit and even > 32-bit arithmetic units :(
>
I have seen exactly the same probleme with Leapfrog on a ultrasparc
station (a 64 bits processor !). It seems it's a usual problem.

nicO
eGroups Sponsor=
3D""
From Michael Riepe Sat Nov 4 14:23:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA04786 for ; Sat, 4 Nov 2000 23:44:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 23:44:32 +0100 (MET) Received: (qmail 26607 invoked by uid 0); 4 Nov 2000 17:24:27 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net with SMTP; 4 Nov 2000 17:24:27 -0000 X-eGroups-Return: sentto-1101623-1333-973358662-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 04 Nov 2000 17:24:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 4 Nov 2000 17:24:22 -0000 Received: (qmail 12268 invoked from network); 4 Nov 2000 17:24:22 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 4 Nov 2000 17:24:22 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.140) by mta2 with SMTP; 4 Nov 2000 17:24:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00462; Sat, 4 Nov 2000 14:23:56 +0100 Message-ID: <20001104142356.55230@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> <20001103215349.12151@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Fri, Nov 03, 2000 at 08:41:32PM -0800 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 4 Nov 2000 14:23:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] More Code, More Problems... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc7f42cb648d59d45b044cf714594b8e Status: R X-Status: N Moin,

On Fri, Nov 03, 2000 at 08:41:32PM -0800, Colin Marquardt wrote:

[VHDL integer size]
> The LRM states that each tool has to support at least 32bit integers,
> and that's what most of them do AFAIK. Relying on a possibly larger
> implementation in another tool is just not portable.

Yep.  The language (syntax) itself supports numbers of arbitrary size,
but implementations aren't supposed to grok them.  Damn toy software.
I wish VHDL were a subset of LISP, instead of Ada...

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sat Nov 4 14:33:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA04789 for ; Sat, 4 Nov 2000 23:44:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 04 Nov 2000 23:44:32 +0100 (MET) Received: (qmail 31530 invoked by uid 0); 4 Nov 2000 17:24:28 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx01) with SMTP; 4 Nov 2000 17:24:28 -0000 X-eGroups-Return: sentto-1101623-1332-973358658-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mv.egroups.com with NNFMP; 04 Nov 2000 17:24:27 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 4 Nov 2000 17:24:17 -0000 Received: (qmail 9481 invoked from network); 4 Nov 2000 17:24:17 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 4 Nov 2000 17:24:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.140) by mta2 with SMTP; 4 Nov 2000 17:24:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00491; Sat, 4 Nov 2000 14:33:08 +0100 Message-ID: <20001104143308.31655@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A025BE7.B5B64AE@f-cpu.org> <20001103215349.12151@thrai.stud.uni-hannover.de> <3A03AD91.9F6593BC@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A03AD91.9F6593BC@f-cpu.org>; from Yann Guidon on Sat, Nov 04, 2000 at 07:32:49AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 4 Nov 2000 14:33:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] More Code, More Problems... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5826375b70865e2609bf69f31eac0d52 Status: R X-Status: N On Sat, Nov 04, 2000 at 07:32:49AM +0100, Yann Guidon wrote:

[...]
> >  PS: can't we rename the project to `Fun-CPU'? ;)
> "yet another acronym" ? there were also : "This french CPU" or "This f*ck*ng CPU"
> or "The First Chocolate Powered Utopia" or "The First Cheese Powered Utopia" :-)

Fabulous CPU
Famous CPU
Fantastic CPU
Fast CPU
Fine CPU
...

> i don't know if "fun-cpu" is as witty as you'd think, because before we get to the
> current point, it was a real pain in what you referred to in another mail...
> but if you like it, why not ? :-)

As long as nobody calls it `Funny CPU' or `Faulty CPU'... ;)

Ok, back to work...
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Sun Nov 5 08:23:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA07304 for ; Sun, 5 Nov 2000 08:53:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 05 Nov 2000 08:53:26 +0100 (MET) Received: (qmail 29559 invoked by uid 0); 5 Nov 2000 07:18:45 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net with SMTP; 5 Nov 2000 07:18:45 -0000 X-eGroups-Return: sentto-1101623-1334-973408720-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hh.egroups.com with NNFMP; 05 Nov 2000 07:18:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 5 Nov 2000 07:18:39 -0000 Received: (qmail 10602 invoked from network); 5 Nov 2000 07:18:39 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 5 Nov 2000 07:18:39 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 5 Nov 2000 07:18:39 -0000 Received: from f-cpu.org (nas3-30.ras.club-internet.fr [195.36.203.30]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA22426 for ; Sun, 5 Nov 2000 08:18:36 +0100 (MET) Message-ID: <3A050AEA.3BF9B8AE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 05 Nov 2000 08:23:22 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] CCC Meeting in Berlin Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fd21cf9b9f7a06f9bf8a01bb22773033 Status: R X-Status: N hello,

With the help of Sven and others, i'll try to come in Berlin
for the next CCC meeting. We'll present the achievements of the
past year and we'll have a lot of fun (i hope as much as last year !).

i try to organise a trip with some other french F-CPU team members :
whoever is willing to help or come is welcome ! it's discussed on the
local mailing lists. Someone has even proposed to arrange the
trip in a little tourism plane :-)

I wish that a lot of us could meet there so we can discuss
a bit about the f-cpu's architecture, have fun, play music
and know each other :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Nicolas Boulay Mon Nov 6 21:26:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01921 for ; Mon, 6 Nov 2000 22:06:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 06 Nov 2000 22:06:19 +0100 (MET) Received: (qmail 8230 invoked by uid 0); 6 Nov 2000 20:25:32 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx14) with SMTP; 6 Nov 2000 20:25:32 -0000 X-eGroups-Return: sentto-1101623-1335-973542327-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hk.egroups.com with NNFMP; 06 Nov 2000 20:25:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 6 Nov 2000 20:25:27 -0000 Received: (qmail 13358 invoked from network); 6 Nov 2000 20:25:17 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 6 Nov 2000 20:25:17 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 6 Nov 2000 20:25:16 -0000 Received: from ifrance.com (nas5-118.vlt.club-internet.fr [194.158.107.118]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA06000 for ; Mon, 6 Nov 2000 21:25:13 +0100 (MET) Message-ID: <3A071413.ACD3E490@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A050AEA.3BF9B8AE@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 06 Nov 2000 21:26:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] arithmetics Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 13d48aa1ecc33bc4b0a5ce0a311290ee Status: R X-Status: N
http://modgen.fysel.ntnu.no/
http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html

2 URL for those who didn't want to rewrite the wheel (but i didn't
exactly watch there licence).

nicO
eGroups Sponsor
From Yann Guidon Tue Nov 7 00:07:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00312 for ; Tue, 7 Nov 2000 18:26:48 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:26:48 +0100 (MET) Received: (qmail 27021 invoked by uid 0); 6 Nov 2000 23:13:01 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net (mx11) with SMTP; 6 Nov 2000 23:13:01 -0000 X-eGroups-Return: sentto-1101623-1336-973552295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hn.egroups.com with NNFMP; 06 Nov 2000 23:11:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 6 Nov 2000 23:11:34 -0000 Received: (qmail 18476 invoked from network); 6 Nov 2000 23:02:43 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 6 Nov 2000 23:02:43 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 6 Nov 2000 23:02:42 -0000 Received: from f-cpu.org (nas3-16.ras.club-internet.fr [195.36.203.16]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA01051 for ; Tue, 7 Nov 2000 00:02:39 +0100 (MET) Message-ID: <3A0739AE.498A8FB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A050AEA.3BF9B8AE@f-cpu.org> <3A071413.ACD3E490@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 00:07:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] arithmetics Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bbfd51f55bde9e034a2512e429d4c4b1 Status: R X-Status: N Nicolas Boulay wrote:
> http://modgen.fysel.ntnu.no/
> http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html
>
> 2 URL for those who didn't want to rewrite the wheel (but i didn't
> exactly watch there licence).

thanks :-)

my browser highlights one of them, meaning that i have already
visited it. I presume that it's the one that generates functions
with a web interface. pipelining and SIMD are not well developped.

i gotta check carefully though.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Tue Nov 7 01:09:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00321 for ; Tue, 7 Nov 2000 18:26:51 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:26:51 +0100 (MET) Received: (qmail 8367 invoked by uid 0); 7 Nov 2000 00:09:31 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx04) with SMTP; 7 Nov 2000 00:09:31 -0000 X-eGroups-Return: sentto-1101623-1337-973555759-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 07 Nov 2000 00:09:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 00:09:18 -0000 Received: (qmail 11948 invoked from network); 7 Nov 2000 00:09:18 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 7 Nov 2000 00:09:18 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.70) by mta2 with SMTP; 7 Nov 2000 00:09:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01720; Tue, 7 Nov 2000 01:09:11 +0100 Message-ID: <20001107010910.01960@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A050AEA.3BF9B8AE@f-cpu.org> <3A071413.ACD3E490@ifrance.com> <3A0739AE.498A8FB@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A0739AE.498A8FB@f-cpu.org>; from Yann Guidon on Tue, Nov 07, 2000 at 12:07:26AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 7 Nov 2000 01:09:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] arithmetics Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c88f5c983d5da08e96f15e226d0e50c Status: R X-Status: N Hi y'all,

On Tue, Nov 07, 2000 at 12:07:26AM +0100, Yann Guidon wrote:
> Nicolas Boulay wrote:
> > http://modgen.fysel.ntnu.no/
> > http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html
[...]
> my browser highlights one of them, meaning that i have already
> visited it. I presume that it's the one that generates functions
> with a web interface. pipelining and SIMD are not well developped.

The first one is the VHDL generator... but the second one seems to be
interesting (some PS documents, and source code for an arithmetic
library -- download already finished ;).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Tue Nov 7 07:35:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00332 for ; Tue, 7 Nov 2000 18:26:54 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:26:54 +0100 (MET) Received: (qmail 2847 invoked by uid 0); 7 Nov 2000 06:30:43 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx04) with SMTP; 7 Nov 2000 06:30:43 -0000 X-eGroups-Return: sentto-1101623-1338-973578639-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 07 Nov 2000 06:30:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 06:30:38 -0000 Received: (qmail 22097 invoked from network); 7 Nov 2000 06:30:37 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 7 Nov 2000 06:30:37 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 7 Nov 2000 07:31:43 -0000 Received: from f-cpu.org (nas1-169.ras.club-internet.fr [195.36.192.169]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA22525 for ; Tue, 7 Nov 2000 07:30:34 +0100 (MET) Message-ID: <3A07A29D.1D271AE6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 07:35:09 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] CCC meeting : who wants some room ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee8c35ed48f774879da9db16ef819780 Status: R X-Status: N hello,
recently i have received mails from the CCC.
they propose to reserve some room in the "hackcenter"
(the computer zone) for our project.

If someone wants to come with his whole HW (that means :
screen, keyboard, PC, network devices, chair, wires,
audio amplifier, webcam etc) please answer quickly !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Colin Marquardt Tue Nov 7 07:05:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00338 for ; Tue, 7 Nov 2000 18:26:55 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:26:55 +0100 (MET) Received: (qmail 30586 invoked by uid 0); 7 Nov 2000 08:45:48 -0000 Received: from hh.egroups.com (208.50.99.210) by mx12.rz2.gmx.net (mx12) with SMTP; 7 Nov 2000 08:45:48 -0000 X-eGroups-Return: sentto-1101623-1339-973586745-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 07 Nov 2000 08:45:46 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 08:45:44 -0000 Received: (qmail 56676 invoked from network); 7 Nov 2000 08:45:44 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 7 Nov 2000 08:45:44 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 7 Nov 2000 08:45:43 -0000 Received: from morphin.marquardt-home.de (d167.nas21.sonic.net [209.204.136.167]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id JAA02296 for ; Tue, 7 Nov 2000 09:45:37 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13t1tK-0000NQ-00 for ; Mon, 06 Nov 2000 22:05:54 -0800 To: f-cpu@egroups.com References: <3A050AEA.3BF9B8AE@f-cpu.org> <3A071413.ACD3E490@ifrance.com> <3A0739AE.498A8FB@f-cpu.org> <20001107010910.01960@thrai.stud.uni-hannover.de> X-Now-Playing: Manos's Living Burial - nervenlied In-Reply-To: Michael Riepe's message of "Tue, 7 Nov 2000 01:09:10 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 06 Nov 2000 22:05:54 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] arithmetics Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 06365d92e225a438e3bbdbf09855c54d Status: R X-Status: N Michael Riepe <michael@stud.uni-hannover.de> writes:

> > > http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html

> The first one is the VHDL generator... but the second one seems to be
> interesting (some PS documents, and source code for an arithmetic
> library -- download already finished ;).

>From emacs' vhdl-mode author, now working for Synopsys :-)

Colin
eGroups Sponsor
From Erik Hansen Tue Nov 7 13:15:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00353 for ; Tue, 7 Nov 2000 18:26:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:26:59 +0100 (MET) Received: (qmail 26534 invoked by uid 0); 7 Nov 2000 12:18:35 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx17) with SMTP; 7 Nov 2000 12:18:35 -0000 X-eGroups-Return: sentto-1101623-1340-973599513-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 07 Nov 2000 12:18:34 -0000 X-Sender: erikh@cs.tu-berlin.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 12:18:32 -0000 Received: (qmail 37855 invoked from network); 7 Nov 2000 12:18:32 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 7 Nov 2000 12:18:32 -0000 Received: from unknown (HELO mail.cs.tu-berlin.de) (130.149.17.13) by mta1 with SMTP; 7 Nov 2000 12:18:31 -0000 Received: from havarti.cs.tu-berlin.de (erikh@havarti.cs.tu-berlin.de [130.149.22.38]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id NAA23396 for ; Tue, 7 Nov 2000 13:15:50 +0100 (MET) Received: (from erikh@localhost) by havarti.cs.tu-berlin.de (8.9.3/8.9.3) id NAA05584; Tue, 7 Nov 2000 13:15:50 +0100 (MET) X-Sender: erikh@havarti To: f-cpu@egroups.com Message-ID: From: Erik Hansen MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 7 Nov 2000 13:15:50 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6448d68f8ad07aa9b9484bf81192b045 Status: R X-Status: N Hi all!

I have been following the progress of the F-CPU Project for quite a while
and finally I have decided to contribute in some way.

Unfortunately I was not able to find out which parts of the porjekt are
being worked on. OK, I know that you are working on the ROP2 unit and
the adder unit, but what about the other components? Is there any order
by which you like to implement the units? Do you have coding guidelines?
Is there a printable version (PS or PDF) of your manual (I Don't like the
Idea of reading through all of it on my screen)?

So, if you have any answers or other useful information just drop me a
mail. 

Thanx

Erik
eGroups Sponsor
From Jeff Davies Tue Nov 7 17:58:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00392 for ; Tue, 7 Nov 2000 18:27:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 07 Nov 2000 18:27:13 +0100 (MET) Received: (qmail 2833 invoked by uid 0); 7 Nov 2000 17:09:49 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net (mx01) with SMTP; 7 Nov 2000 17:09:49 -0000 X-eGroups-Return: sentto-1101623-1341-973616981-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 07 Nov 2000 17:09:47 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 17:09:41 -0000 Received: (qmail 99851 invoked from network); 7 Nov 2000 17:08:02 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 7 Nov 2000 17:08:02 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta3 with SMTP; 7 Nov 2000 18:09:07 -0000 Received: from modem-141.idaho.dialup.pol.co.uk ([62.137.63.141] helo=tiglath.pileser.sumeria) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13tCDt-0007iq-00 for f-cpu@egroups.com; Tue, 07 Nov 2000 17:07:50 +0000 X-Mailer: KMail [version 1.0.28] Message-Id: <00110717081801.18244@tiglath.pileser.sumeria> To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 7 Nov 2000 16:58:57 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FCPU Glossary DTD 0.01 Content-Type: multipart/mixed; boundary="Boundary-=_XrJmOWFrxsjyBldbEFSArCBynEcd" X-UIDL: b3184dab985db1273189295ea7704e2f Status: R X-Status: N --Boundary-=_XrJmOWFrxsjyBldbEFSArCBynEcd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit I have been designing a DTD for use in glossary, and became kind of carriedaway, and made it into a multimedia encyclopaedia DTD.

Here is version 0.01.

There are 3 things to note here:

1. I have attempted to optimise it for simple transformation. My target is to
faciliate the use of "sed" as a means of transforming the data to Latex or to
HTML (or WML). You will see it is not possible to omit any tags in the DTD.
[there is no DCL yet].
Encyclopeadia entries are of DOCTYPE ENCYCLOPAEDIA-ENTRY.

2. Attributes are not used at all. This is also to facilitate use of "sed" for
transformation. (sed is avaliable everywhere, more awkward to insist on XSLT).
Local entities also should not be used.

3. No empty elements are used, this is so that documents are compatible across
SGML and XML.

NOTE:
a. Graphic files (inline or referenced) should be in an free licence format.
Ideally JPG or PNG.
b. Audio files should be in VORBIS OGG format. This is a GPL format, and you can
get plug ins from the web site for all sorts of media players/recorders (use
www.google.com to find it).
c. video files should be in .mpg format (I think this is a free format? - or is
it?)
d. 3d world files should be in VRML  (later that XML thing that is similar).
e. You will notice only java applets are supported. ActiveX applets have total
access to your system when signed by the correct certifying authority (like
Microsoft). Who knows if the recent intruders into Microsoft stole the root
certifier for Microsoft. If so I don't fancy someone suing me for my house
due to their contact list being sucked by an evil ActiveX, so sorry, no support
at all ever ;)
..
I will make some sed scripts soon, and a java tool to create entries. I could
do with a CVS repository to put the SGML files and code on-line. Does FCPU have
one?

Please also note: I have built the DTD whilst thinking about Topic Maps et al.
This is why you find date inside published-date and task-sequences etc.

(Docbook is a more publishing orientated thingy, whereas if the above
encyclopaedia entries are stored in an object database like coldstore, you can
search for a "procedure for programming FPGA" more intelligently that you
could with a text-only index).

I also want to add some way of expressing a class relationship like "Z80 is a
an instance of a CPU", but all I have at the moment is related term list, which
doesn't really express the relationship in a searchable-at-sufficient-resolution
form. Perhaps a "parent-term" element which is defined as term-id* (can have
multiple parents?).
So Z80 could be child of CPU and child of 8bit CPU (Which itself is a child of
CPU).


As an authoring tool, Xmetal handles the DTD ok, you need to insert a
ENCYCLOPAEDIA-ENTRY as a first step.

I haven't tried it on IBMs Xeena XML editor yet (entirely written in Java).




Jeff Davies
eGroups Sponsor
--Boundary-=_XrJmOWFrxsjyBldbEFSArCBynEcd Content-Type: text/html; name="fcpudoc.dtd" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpudoc.dtd" PCEtLSBUaW1lIFByaW1pdGl2ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgSE9VUiBDREFUQT4NCjwhRUxFTUVOVCBN SU5VVEUgQ0RBVEE+DQo8IUVMRU1FTlQgU0VDT05EIENEQVRBPg0KPCFFTEVNRU5UIERBWSBD REFUQT4NCjwhRUxFTUVOVCBNT05USCBDREFUQT4NCjwhRUxFTUVOVCBZRUFSIENEQVRBPg0K DQo8IS0tIFRpbWUgSW50ZXJtZWRpYXRlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVOVCBEQVRFIChIT1VSLE1JTlVURSxTRUNP TkQpPg0KPCFFTEVNRU5UIFRJTUUgKFlFQVIsTU9OVEgsREFZKT4NCjwhRUxFTUVOVCBEQVRF LVRJTUUgKERBVEUsVElNRSk+DQo8IUVMRU1FTlQgVElNRS1SQU5HRSAoREFURS1USU1FLERB VEUtVElNRSk+DQoNCjwhLS0gVGltZXN0YW1wcyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIElORk8tVElNRVNU QU1QIChEQVRFLVRJTUUpPg0KDQo8IS0tIFBlcnNvbiBOYW1lIHByaW1pdGl2ZXMgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVOVCBQRVJT T04tVElUTEUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEZJUlNULU5BTUUgLSAtIENEQVRBPg0K PCFFTEVNRU5UIExBU1QtTkFNRSAtIC0gQ0RBVEE+DQoNCjwhLS0gUGVyc29uIE5hbWUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0K PCFFTEVNRU5UIFBFUlNPTi1OQU1FIC0gLSAoUEVSU09OLVRJVExFPyxGSVJTVC1OQU1FKixM QVNULU5BTUUqKT4NCg0KPCEtLSBBZGRyZXNzIFByaW1pdGl2ZXMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgU1RSRUVULUFE RFJFU1MgLSAtIENEQVRBPg0KPCFFTEVNRU5UIENJVFkgLSAtIENEQVRBPg0KPCFFTEVNRU5U IENPVU5UWSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgUkVHSU9OIC0gLSBDREFUQT4NCjwhRUxF TUVOVCBDT1VOVFJZIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBGRURFUkFUSU9OIC0gLSBDREFU QT4NCjwhRUxFTUVOVCBQT1NUQUwtQ09ERSAtIC0gQ0RBVEE+DQoNCjwhLS0gQWRkcmVzcyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tPg0KPCFFTEVNRU5UIEFERFJFU1MgLSAtIChTVFJFRVQtQUREUkVTUyosQ0lUWT8sQ09V TlRZPyxSRUdJT04/LENPVU5UUlk/LEZFREVSQVRJT04/LFBPU1RBTC1DT0RFPyk+DQoNCjwh LS0gQ29udGFjdCBQcmltaXRpdmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIENPTVBBTlktTkFNRSAtIC0gQ0RBVEE+DQo8 IUVMRU1FTlQgRU1BSUwtQUREUkVTUyAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgVVJJIC0gLSBD REFUQT4NCjwhRUxFTUVOVCBURUxFUEhPTkUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEdTTS1U RUxFUEhPTkUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEpPQi1USVRMRSAtIC0gQ0RBVEE+DQoN CjwhLS0gQ29udGFjdCB0eXBlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIENPTVBBTlktQ09OVEFDVC1ERVRBSUxT IChDT01QQU5ZLU5BTUUsQUREUkVTUyosRU1BSUwtQUREUkVTUyosVVJJKixURUxFUEhPTkUq LEdTTS1URUxFUEhPTkUqLElORk8tVElNRVNUQU1QKT4NCjwhRUxFTUVOVCBJTkRJVklEVUFM LUNPTlRBQ1QtREVUQUlMUyAoUEVSU09OLU5BTUUsSk9CLVRJVExFPyxDT01QQU5ZLU5BTUU/ LEFERFJFU1MqLEVNQUlMLUFERFJFU1MqLFVSSSosVEVMRVBIT05FKixHU00tVEVMRVBIT05F KixJTkZPLVRJTUVTVEFNUCk+DQoNCjwhLS0gR3JvdXBzIG9mIENvbnRhY3RzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIEFV VEhPUlMgKChJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3xDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUykqKSA+DQo8IUVMRU1FTlQgRURJVE9SUyAoKElORElWSURVQUwtQ09OVEFDVC1ERVRB SUxTfENPTVBBTlktQ09OVEFDVC1ERVRBSUxTKSopID4NCjwhRUxFTUVOVCBQUklDRS1QUk9W SURFUlMgKChJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3xDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUykqKT4NCjwhRUxFTUVOVCBQVUJMSVNIRVJTICgoSU5ESVZJRFVBTC1DT05UQUNULURF VEFJTFN8Q09NUEFOWS1DT05UQUNULURFVEFJTFMpKik+DQoNCg0KPCEtLSBGQ1BVLVJJQ0gt VEVYVC1GT1ItREVTQ1JJUFRJT04tRklFTEQtUFJJTUlUSVZFUyBTVEFSVCBIRVJFICAgICAg IC0tPg0KDQo8IS0tIHRleHQgc3R5bGUgaW5mb3JtYXRpb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgRU1QSCAtIC0gQ0RBVEE+ DQo8IUVMRU1FTlQgVkVSQkFUSU0gLSAtIENEQVRBPg0KDQo8IUVMRU1FTlQgU0VDVElPTi1U SVRMRSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgU0VDVElPTiAtIC0gKFNFQ1RJT04tVElUTEUs REVTQ1JJUFRJT04pPg0KDQo8IUVMRU1FTlQgVEVYVCAtIC0gQ0RBVEE+DQoNCjwhRUxFTUVO VCBJTkxJTkUtR1JBUEhJQyAtIC0gKFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tR1JBUEhJ QyAtIC0gKElOTElORS1HUkFQSElDPyxURVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8t TU9WSUUgLSAtIChJTkxJTkUtR1JBUEhJQz8sVEVYVCxVUkkpID4NCjwhRUxFTUVOVCBMSU5L LVRPLVNPVU5EIC0gLSAoSU5MSU5FLUdSQVBISUM/LFRFWFQsVVJJKSA+DQo8IUVMRU1FTlQg TElOSy1UTy1USFJFRS1ELVdPUkxEIC0gLSAoSU5MSU5FLUdSQVBISUM/LFRFWFQsVVJJKSA+ DQo8IUVMRU1FTlQgTElOSy1UTy1KQVZBLUFQUExFVCAtIC0gKElOTElORS1HUkFQSElDPyxU RVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tT1RIRVItTUVESUEgLSAtIChJTkxJTkUt R1JBUEhJQz8sVEVYVCxVUkkpID4NCjwhRUxFTUVOVCBMSU5LLVRPLUhUTUwtUEFHRSAtIC0g KElOTElORS1HUkFQSElDPyxURVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tUkVGRVJF TkNFLVRFUk0gLSAtIChURVJNLUlEKSAtLXRoaXMgcmVmZXJzIHRvIGFub3RoZXIgdGVybSBk ZXNjcmlwdGlvbiBkb2N1bWVudCAtLT4NCg0KDQo8IUVMRU1FTlQgKFRBU0stQ09ORElUSU9O fFRBU0stU1RBVFVTKSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgVEFTSy1EVUUtREFURSAtIC0g KERBVEUpPg0KPCFFTEVNRU5UIFRBU0stQ09NUExFVEUtREFURSAtIC0gKERBVEUpPg0KPCFF TEVNRU5UIFRBU0sgLSAtIChUQVNLLURVRS1EQVRFPyxUQVNLLUNPTVBMRVRFLURBVEU/LFRB U0stU1RBVFVTPyxURVhUKT4NCjwhRUxFTUVOVCBUQVNLLVNFUVVFTkNFIC0gLSAoVEFTSy1D T05ESVRJT04/LCBUQVNLLURVRS1EQVRFPywgVEFTSy1DT01QTEVURS1EQVRFPywgVEFTSy1T VEFUVVM/LCAoVEFTSy1TRVFVRU5DRXxUQVNLKSopPg0KDQo8IUVMRU1FTlQgKFBST0NFU1Mt Q09ORElUSU9OfFBST0NFU1MtTkFNRXxQUk9DRVNTLVRFWFQpIC0gLSBDREFUQT4NCjwhRUxF TUVOVCBQUk9DRVNTIC0gLSAoUFJPQ0VTUy1OQU1FLFBST0NFU1MtVEVYVCkgPg0KPCFFTEVN RU5UIFBST0NFU1MtU0VRVUVOQ0UgKFBST0NFU1MtQ09ORElUSU9OLCAoUFJPQ0VTUy1TRVFV RU5DRXxQUk9DRVNTKSopPg0KDQo8IUVMRU1FTlQgKFBVQkxJQ0FUSU9OLVRJVExFfEVESVRJ T058UEFHRXxDSEFQVEVSfFZFUlNJT058TElDRU5DRS1UWVBFfFBBQ0tBR0UtTkFNRSkgLSAt IENEQVRBPg0KPCFFTEVNRU5UIERBVEUtUFVCTElTSEVEIC0gLSAoREFURSk+DQo8IUVMRU1F TlQgKERPV05MT0FELVVSSXxJTkZPUk1BVElPTi1VUkl8TElOSy1VUkkpIC0gLSAoVVJJKSA+ DQoNCjwhRUxFTUVOVCBSRUZFUkVOQ0UtVE8tQk9PSyAtIC0gKFBVQkxJQ0FUSU9OLVRJVExF LEVESVRJT04/LFBBR0U/LENIQVBURVI/LERBVEUtUFVCTElTSEVELFBVQkxJU0hFUlMsIEFV VEhPUlM/LCBFRElUT1JTPyk+DQo8IUVMRU1FTlQgUkVGRVJFTkNFLVRPLU9OTElORS1CT09L IC0gLSAoUFVCTElDQVRJT04tVElUTEUsVkVSU0lPTixET1dOTE9BRC1VUkk/LElORk9STUFU SU9OLVVSST8sTElOSy1VUkk/LERBVEUtUFVCTElTSEVELFBVQkxJU0hFUlMsIEFVVEhPUlM/ LCBFRElUT1JTPyxMSUNFTkNFLVRZUEUpPg0KPCFFTEVNRU5UIFJFRkVSRU5DRS1UTy1TT0ZU V0FSRSAtIC0gKFBBQ0tBR0UtTkFNRSxWRVJTSU9OLERPV05MT0FELVVSST8sSU5GT1JNQVRJ T04tVVJJPyxMSU5LLVVSST8sREFURS1QVUJMSVNIRUQsUFVCTElTSEVSUywgQVVUSE9SUz8s IEVESVRPUlM/LExJQ0VOQ0UtVFlQRSk+DQoNCjwhLS0gSW5mb3JtYXRpb24gU3RydWN0dXJl cyAtLT4NCjwhRUxFTUVOVCBMSVNULUVOVFJZIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBMSVNU IC0gLSAoTElTVC1FTlRSWSopPg0KDQo8IUVMRU1FTlQgSEVBRElORy1ST1cgLSAtICgoSEVB RElORy1DRUxMLENFTEwqKXwoQ0VMTCopKT4NCjwhRUxFTUVOVCBST1cgLSAtICgoSEVBRElO Ry1DRUxMLENFTEwqKXwoQ0VMTCopKT4NCjwhRUxFTUVOVCBIRUFESU5HLUNFTEwgLSAtIENE QVRBPg0KPCFFTEVNRU5UIENFTEwgLSAtIENEQVRBPg0KPCFFTEVNRU5UIFRBQkxFIC0gLSAo KEhFQURJTkctUk9XLFJPVyopfChST1cqKSk+IA0KDQoNCjwhLS0gUHJpY2UgSXRlbSBwYWly IC0tPg0KDQo8IUVMRU1FTlQgUVVBTlRJVFkgLSAtIENEQVRBIC0tbnVtYmVyIG9mIHVuaXRz IHB1cmNoYXNlZCBmb3IgdGhpcyBwcmljZS0tPg0KPCFFTEVNRU5UIEFNT1VOVCAtIC0gQ0RB VEEgLS1hbW91bnQgb2YgY3VycmVuY3ktLT4NCjwhRUxFTUVOVCBDVVJSRU5DWSAtIC0gQ0RB VEE+DQo8IUVMRU1FTlQgU09VUkNFIC0gLSBDREFUQSAtLWVnIG5ld3NwYXBlciBuYW1lLS0+ DQo8IUVMRU1FTlQgU09VUkNFLVRZUEUgLSAtIENEQVRBIC0tZWcgJ25ld3NwYXBlcictLT4N Cg0KPCFFTEVNRU5UIChJVEVNLU5BTUUsSVRFTS1NT0RFTCxJVEVNLVZFUlNJT04pIC0gLSBD REFUQT4NCjwhRUxFTUVOVCBNQU5VRkFDVFVSRVIgLSAtIChDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUyk+DQo8IUVMRU1FTlQgSVRFTSAtIC0gKElURU0tTkFNRSwgSVRFTS1CUkFORD8sIElU RU0tTU9ERUw/LCBJVEVNLVZFUlNJT04/LCBNQU5VRkFDVFVSRVIpPg0KPCFFTEVNRU5UIFBS SUNFIC0gLSAoUVVBTlRJVFksQU1PVU5ULENVUlJFTkNZLFNPVVJDRSxTT1VSQ0UtVFlQRSxU SU1FU1RBTVAsIFBSSUNFLVBST1ZJREVSUyk+DQo8IUVMRU1FTlQgUFJJQ0UtSVRFTS1QQUlS IC0gLSAoSVRFTSwgUFJJQ0UpPg0KDQoNCjwhLS0gZW5jeWNsb3BhZWRpYSBlbnRyeSBwcmlt aXRpdmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVO VCAoVEVSTS1OQU1FfEVESVQtTk9URVMpIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBURVJNLUlE IC0gLSBDREFUQSAgLS10aGlzIGlzIGhvdyB0aGUgdGVybXMgYXJlIGluZGV4ZWQsIGl0J3Mg YmFzaWNhbGx5IGEgaGFzaGVkIGluZGV4IHBvaW50ZXIgb3Igc29tZSBzb3J0IC0tPg0KPCFF TEVNRU5UIFRFUk0tUVVBTElGSUVSIC0gLSBDREFUQSAgLS1mb3IgZXhhbXBsZSBQQVJJUywg ZnJhbmNlIC0gaGVyZSBmcmFuY2UgaXMgdGhlIHF1YWxpZmllciAtLT4NCjwhRUxFTUVOVCBM QU5HVUFHRS1QQVJUIC0gLSBDREFUQSAgLS1lZyBub3VuLCB2ZXJiIGV0YyAtLT4NCjwhRUxF TUVOVCBTT1VSQ0UtTEFOR1VBR0UgLSAtIENEQVRBID4NCjwhRUxFTUVOVCBDQVRFR09SWSAt IC0gQ0RBVEEgPg0KPCFFTEVNRU5UIENBVEVHT1JZLUxJU1QgLSAtIChDQVRFR09SWSopPg0K DQo8IUVMRU1FTlQgQVNTT0NJQVRFRC1URVJNUyAtIC0gKFRFUk0tSUQqKT4NCjwhRUxFTUVO VCBQVUJMSVNIRUQtREFURSAtIC0gKERBVEUpPg0KPCFFTEVNRU5UIEVESVQgLSAtIChEQVRF LEVESVRPUlMsRURJVC1OT1RFUyk+DQo8IUVMRU1FTlQgRURJVC1ISVNUT1JZIC0gLSAoRURJ VCopPg0KDQoNCjwhRUxFTUVOVCBERVNDUklQVElPTiAtIC0gKChEQVRFfFRJTUUtUkFOR0V8 VEFTSy1TRVFVRU5DRXxQUk9DRVNTLVNFUVVFTkNFfFJFRkVSRU5DRS1UTy1TT0ZUV0FSRXwN ClJFRkVSRU5DRS1UTy1PTkxJTkUtQk9PS3xSRUZFUkVOQ0UtVE8tQk9PS3xJTkxJTkUtR1JB UEhJQ3xMSU5LLVRPLUdSQVBISUN8DQpMSU5LLVRPLU1PVklFfExJTkstVE8tU09VTkR8TElO Sy1UTy1USFJFRS1ELVdPUkxEfExJTkstVE8tSkFWQS1BUFBMRVR8DQpMSU5LLVRPLU9USEVS LU1FRElBfExJTkstVE8tSFRNTC1QQUdFfExJTkstVE8tUkVGRVJFTkNFLVRFUk18U0VDVElP TnxDT01QQU5ZLUNPTlRBQ1QtREVUQUlMU3xJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3wN CkxJU1R8VEFCTEV8UFJJQ0UtSVRFTS1QQUlSfCNQQ0RBVEEpKik+DQoNCjwhRUxFTUVOVCBF TkNZQ0xPUEFFRElBLUVOVFJZIC0gLSAoVEVSTS1OQU1FLCBURVJNLUlEICwgVEVSTS1RVUFM SUZJRVIqICwgTEFOR1VBR0UtUEFSVD8sIFNPVVJDRS1MQU5HVUFHRSwgQ0FURUdPUlktTElT VCwgREVTQ1JJUFRJT04sIEFTU09DSUFURUQtVEVSTVMsIFBVQkxJU0hFRC1EQVRFLCBBVVRI T1JTLCBFRElULUhJU1RPUlkpPg0K --Boundary-=_XrJmOWFrxsjyBldbEFSArCBynEcd-- From Michael Riepe Tue Nov 7 17:03:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00318 for ; Wed, 8 Nov 2000 01:38:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:07 +0100 (MET) Received: (qmail 17855 invoked by uid 0); 7 Nov 2000 18:12:09 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx01) with SMTP; 7 Nov 2000 18:12:09 -0000 X-eGroups-Return: sentto-1101623-1343-973620566-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by b05.egroups.com with NNFMP; 07 Nov 2000 18:09:39 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 18:09:25 -0000 Received: (qmail 6300 invoked from network); 7 Nov 2000 18:09:25 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 7 Nov 2000 18:09:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.87) by mta1 with SMTP; 7 Nov 2000 18:09:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00924; Tue, 7 Nov 2000 17:03:59 +0100 Message-ID: <20001107170359.33916@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Erik Hansen on Tue, Nov 07, 2000 at 01:15:50PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 7 Nov 2000 17:03:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 21fa62520256d04e085d0792e114ab15 Status: R X-Status: N On Tue, Nov 07, 2000 at 01:15:50PM +0100, Erik Hansen wrote:

> I have been following the progress of the F-CPU Project for quite a while
> and finally I have decided to contribute in some way.

Welcome.

> Unfortunately I was not able to find out which parts of the porjekt are
> being worked on. OK, I know that you are working on the ROP2 unit and
> the adder unit, but what about the other components? Is there any order
> by which you like to implement the units? Do you have coding guidelines?

Did you really say "order"? ;) No, there isn't.

Whygee currently works on the I-Cache (and probably also has the D-Cache
in mind).  ROP2 is done (for now), and I'm working on the adder-based
EUs (integer add & multiply).  Comments are always welcome, however.

Coding guidelines...

      Write VHDL that can be simulated and (if possible) synthesized
      (VHDL'93 preferred).  Use any tools you like; we currently use
      Symphony EDA (Windows) and Vanilla VHDL (Linux).  I also tried
      alliance and savant but wasn't happy with them -- your mileage
      may vary (alliance isn't really an option because it doesn't
      support full-featured VHDL).  But please don't include stuff
      from proprietary libraries.

      Be aware of the restrictions: no variable-latency EUs, short
      pipeline stages (rule of thumb: <= 6 gates long/deep/whatever).

      We're using std_ulogic(_vector) signals to catch `multiple driver'
      errors early.  Please do not use bit or bit_vector.

      If you are going to write structural VHDL: I made a small
      component library that you can use (currently only available via
      e-mail -- or the egroups archive --, until I have an account on
      the web site).

> Is there a printable version (PS or PDF) of your manual (I Don't like the
> Idea of reading through all of it on my screen)?

You could print the HTML version (or convert it to PS and print that).
There is also a TeX version that may be printable, IIRC.  Whygee?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Tue Nov 7 21:31:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00335 for ; Wed, 8 Nov 2000 01:38:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:11 +0100 (MET) Received: (qmail 16392 invoked by uid 0); 7 Nov 2000 20:26:33 -0000 Received: from jj.egroups.com (208.50.144.82) by mx19.rz2.gmx.net (mx19) with SMTP; 7 Nov 2000 20:26:33 -0000 X-eGroups-Return: sentto-1101623-1344-973628784-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by jj.egroups.com with NNFMP; 07 Nov 2000 20:26:32 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 20:26:24 -0000 Received: (qmail 23987 invoked from network); 7 Nov 2000 20:26:23 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 7 Nov 2000 20:26:23 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 7 Nov 2000 20:26:23 -0000 Received: from f-cpu.org (nas1-219.aub.club-internet.fr [195.36.150.219]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA20205 for ; Tue, 7 Nov 2000 21:26:20 +0100 (MET) Message-ID: <3A08668A.64BF2B1E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 21:31:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c4492489aa13d6869439b39ff85acc6 Status: R X-Status: N hi !

Erik Hansen wrote:
<snip>
> So, if you have any answers or other useful information just drop me a mail.

well, most of it is said in the other mail.
last remark : i hope you'll be there at the 17C3 :-)))

> Thanx
> Erik
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Tue Nov 7 21:31:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00338 for ; Wed, 8 Nov 2000 01:38:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:12 +0100 (MET) Received: (qmail 27637 invoked by uid 0); 7 Nov 2000 20:26:55 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx03) with SMTP; 7 Nov 2000 20:26:55 -0000 X-eGroups-Return: sentto-1101623-1345-973628784-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by cj.egroups.com with NNFMP; 07 Nov 2000 20:26:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 20:26:24 -0000 Received: (qmail 30188 invoked from network); 7 Nov 2000 20:26:24 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 7 Nov 2000 20:26:24 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 7 Nov 2000 21:27:29 -0000 Received: from f-cpu.org (nas1-219.aub.club-internet.fr [195.36.150.219]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA15945 for ; Tue, 7 Nov 2000 21:26:21 +0100 (MET) Message-ID: <3A08668D.CACD29B4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001107170359.33916@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 21:31:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a447b1ac85b2189b24342eee585cd1a8 Status: R X-Status: N hi !

sorry, i'm now busy all day long, i try to catch up a bit
when i get home late in the night... but i have a new
flashy address : yann_guidon(at)mentor.com :-)

Michael Riepe wrote:
> > Unfortunately I was not able to find out which parts of the porjekt are
> > being worked on. OK, I know that you are working on the ROP2 unit and
> > the adder unit, but what about the other components? Is there any order
> > by which you like to implement the units? Do you have coding guidelines?
> Did you really say "order"? ;) No, there isn't.
there's an overall structure. We have started with the easiest parts :-)
(the contrary would be suicidal anyway). We have to get our coding
style smoothed before we get to the tough parts, that is (for me):
the scheduler/Xbar/scoreboard/all-that-stuff. So we do the easy things
first, and we "plug" them througth the scheduling HW later. we can already play
with some units and test the tools and testbenches.

> Whygee currently works on the I-Cache (and probably also has the D-Cache
> in mind).
before i restart on it, i have to include the remarks that were done on ROP2.
it will be done (i hope) this week-end (when i have more than a few minutes to
spend on the kbd).

>  ROP2 is done (for now), and I'm working on the adder-based
> EUs (integer add & multiply).  Comments are always welcome, however.
as said earlier, i have to update the ROP2 package : add the comments
about typechecking, plus add the URL SRs we discussed in another thread.

> Coding guidelines...
<snip>
nicely said, thanks :-)

>         If you are going to write structural VHDL: I made a small
>         component library that you can use (currently only available via
>         e-mail -- or the egroups archive --, until I have an account on
>         the web site).
i don't know what Sven does, i hope you'll have access to this soon.
i also hope that we'll have f-cpu.org soon on another server, with full access
to whatever might come to mind, located at the university Paris 8 (Paul ?).
help/comments welcome...

> > Is there a printable version (PS or PDF) of your manual (I Don't like the
> > Idea of reading through all of it on my screen)?
> You could print the HTML version (or convert it to PS and print that).
> There is also a TeX version that may be printable, IIRC.  Whygee?
I just asked Olivier Jean to release a first snapshot of the manual.
i have no idea of the number of pages it'll take :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
damn, i feel like i couldn't have more fun...
well, i hope that the CCC meeting will contradict this ;-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Tue Nov 7 21:31:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00341 for ; Wed, 8 Nov 2000 01:38:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:13 +0100 (MET) Received: (qmail 18673 invoked by uid 0); 7 Nov 2000 20:28:16 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx10) with SMTP; 7 Nov 2000 20:28:16 -0000 X-eGroups-Return: sentto-1101623-1346-973628880-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 07 Nov 2000 20:28:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 20:28:00 -0000 Received: (qmail 29799 invoked from network); 7 Nov 2000 20:26:20 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 7 Nov 2000 20:26:20 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 7 Nov 2000 20:26:19 -0000 Received: from f-cpu.org (nas1-219.aub.club-internet.fr [195.36.150.219]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA20161 for ; Tue, 7 Nov 2000 21:26:16 +0100 (MET) Message-ID: <3A086687.47F53B87@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00110717081801.18244@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 21:31:03 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FCPU Glossary DTD 0.01 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d8781af8b9a6fae9b926a786057cf805 Status: R X-Status: N hi,
i haven't be able to read much in fact. i can't read DTDs either.
if you could arrange the inclusion of this DTD in the manual
(that is now mostly maintained by Olivier), this will be cool.
thanks for the efforts,
> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From return61@uole.com Sun Jul 9 21:27:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00347 for ; Wed, 8 Nov 2000 01:38:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:14 +0100 (MET) Received: (qmail 15124 invoked by uid 0); 7 Nov 2000 23:07:42 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx05) with SMTP; 7 Nov 2000 23:07:42 -0000 X-eGroups-Return: sentto-1101623-1347-973638326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hl.egroups.com with NNFMP; 07 Nov 2000 23:05:29 -0000 X-Sender: return61@uole.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 23:05:20 -0000 Received: (qmail 27273 invoked from network); 7 Nov 2000 23:02:31 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 7 Nov 2000 23:02:31 -0000 Received: from unknown (HELO nickel.cix.co.uk) (194.153.0.18) by mta3 with SMTP; 8 Nov 2000 00:03:36 -0000 Received: from delcobdc.delco.co.uk (ns0.delco.co.uk [212.35.237.3]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id XAA15782 for ; Tue, 7 Nov 2000 23:02:17 GMT X-Envelope-From: return61@uole.com Message-Id: <200011072302.XAA15782@nickel.cix.co.uk> Received: From FROM POUIFESI.CC.ORG.AR ([256.45.36.4]) BY RIS5S2.DAIDACENOTTERE1.CHUEA.CEAIMTV.NET.IE (8.9.1A/8.9.1/1.0) WITH SMTP ID NAE11975 ([256.45.256.4]) (63.20.23.204[63.20.23.204 port:1251]) by delcobdc.delco.co.uk (Mail essentials server 2.421) with SMTP id: <1414@delcobdc.delco.co.uk> for 07/11/00 22:53:21 +0100 To: X-Priority: 3 X-MSMail-Priority: Normal From: return61@uole.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 09 Jul 2000 12:27:52 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Fast Cash.....Consolidate your dept and save $$$ 8755 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c7a7a2e755cf260ffb780f5f57831521 Status: R X-Status: N The Lender

The Lender's Network Mortgage Specialists

For U.S.A. Homeowners Only
Save Now!

We Shop The Best Loan For You!

The Lenders Network is a 100% free service which lets you shop for a mortgage conveniently and securely from the comfort of your home. Using our vast network of lenders across the U.S., we will search our database of loan programs for the best loans that fit your needs.  Even if you're currently working with another lender or have been turned down before, we can still help.

Our loan programs can get you the cash you need for:

  • Debt Consolidation
  • 2nd Mortgage
  • Refinance
  • Credit Repair
  • Home Improvement
  • New Car
  • Dream Vacation
  • College Tuition ..and much, much more.

Funding borrowers with less than perfect credit is our specialty!

Incredibly low monthly payments

We can get you the loan you need.
Regardless of whether you have good or bad credit, we can help you.

Ready to get started?
Simply fill out the form below, and we'll begin shopping for your loan.  It's that easy!

Free Mortgage Quote
Contact Information (* required info)

   
Name: *
Address: *
City: *
State(US Only): *
Zip/Postal Code: *
Home Phone:  *
Work Phone: *
Email Address:
Best Time to Call:
Do You Own Your Home? Mobile Homes DO NOT Qualify
Current Property Value: * See Below For Qualifications
1st Mortgage Owed: * 
2nd Mortgage Owed: *
Amount You Wish To Borrow: *
Interest Rate on Current Mortgage: *
Monthly Gross Household Income *
Monthly Debt (excluding current mortgage(s)) *
Credit Rating: *
Loan Interested In: *

Email List Removal
Click Here


eGroups Sponsor
CONFIDENTIALITY: The information in this e-mail and any attachment is confidential. It is intended only for the named recipients(s). If you are not a named recipient, please notify the sender immediately and do not read, use, copy, or disseminate this information. CONDITIONS: Any offer contained within this communication is subject to contract and formal approval by the legal entity giving the offer. From Michael Riepe Wed Nov 8 00:11:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00350 for ; Wed, 8 Nov 2000 01:38:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 01:38:17 +0100 (MET) Received: (qmail 19978 invoked by uid 0); 7 Nov 2000 23:17:39 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx16) with SMTP; 7 Nov 2000 23:17:39 -0000 X-eGroups-Return: sentto-1101623-1348-973639054-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ml.egroups.com with NNFMP; 07 Nov 2000 23:17:37 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 7 Nov 2000 23:17:34 -0000 Received: (qmail 27409 invoked from network); 7 Nov 2000 23:17:34 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 7 Nov 2000 23:17:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.122) by mta3 with SMTP; 8 Nov 2000 00:18:38 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00555; Wed, 8 Nov 2000 00:11:36 +0100 Message-ID: <20001108001136.07896@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001107170359.33916@thrai.stud.uni-hannover.de> <3A08668D.CACD29B4@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A08668D.CACD29B4@f-cpu.org>; from Yann Guidon on Tue, Nov 07, 2000 at 09:31:09PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 8 Nov 2000 00:11:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5fecdcf169b8f47edb2b420cb343da9b Status: R X-Status: N On Tue, Nov 07, 2000 at 09:31:09PM +0100, Yann Guidon wrote:

> sorry, i'm now busy all day long, i try to catch up a bit
> when i get home late in the night... but i have a new
> flashy address : yann_guidon(at)mentor.com :-)

I guess that means that you got the job you wanted?
Congratulations!

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Wed Nov 8 07:56:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01461 for ; Wed, 8 Nov 2000 13:22:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 13:22:10 +0100 (MET) Received: (qmail 27324 invoked by uid 0); 8 Nov 2000 06:52:12 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx02) with SMTP; 8 Nov 2000 06:52:12 -0000 X-eGroups-Return: sentto-1101623-1349-973666325-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 08 Nov 2000 06:52:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 8 Nov 2000 06:52:04 -0000 Received: (qmail 27058 invoked from network); 8 Nov 2000 06:52:04 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 8 Nov 2000 06:52:04 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 8 Nov 2000 07:53:09 -0000 Received: from f-cpu.org (nas3-27.ras.club-internet.fr [195.36.203.27]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA08676 for ; Wed, 8 Nov 2000 07:52:00 +0100 (MET) Message-ID: <3A08F931.6CF9BAF2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001107170359.33916@thrai.stud.uni-hannover.de> <3A08668D.CACD29B4@f-cpu.org> <20001108001136.07896@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 07:56:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 393ad4b39f4b476beeb1cc13546c6d24 Status: R X-Status: N Michael Riepe wrote:
> > flashy address : yann_guidon(at)mentor.com :-)
> I guess that means that you got the job you wanted?
> Congratulations!
yeah, i definitely signed :-) i work on a crazy machine,
see http://www.celaro.com but i need to find a flat next to
the workplace, it took 2 hours yesterday to come home...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From yanng@relay1.mentorg.com Wed Nov 8 11:24:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01479 for ; Wed, 8 Nov 2000 13:22:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 08 Nov 2000 13:22:13 +0100 (MET) Received: (qmail 28881 invoked by uid 0); 8 Nov 2000 10:30:18 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx23) with SMTP; 8 Nov 2000 10:30:18 -0000 X-eGroups-Return: sentto-1101623-1350-973679415-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hh.egroups.com with NNFMP; 08 Nov 2000 10:30:17 -0000 X-Sender: yanng@relay1.mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 8 Nov 2000 10:30:14 -0000 Received: (qmail 32057 invoked from network); 8 Nov 2000 10:30:14 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 8 Nov 2000 10:30:14 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 8 Nov 2000 10:30:14 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA06994; Wed, 8 Nov 2000 02:30:12 -0800 (PST) Received: from zeus (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W3VCKCFB; Wed, 8 Nov 2000 11:30:10 +0100 Received: by zeus (SMI-8.6/CF5.38L) id LAA23851; Wed, 8 Nov 2000 11:24:46 +0100 Message-Id: <200011081024.LAA23851@zeus> Apparently-To: f-cpu@egroups.com From: yanng@relay1.mentorg.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 8 Nov 2000 11:24:46 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 92a9d655fa6883b872fd8e61aaff8171 Status: R X-Status: N hi,

Colin wrote something about the legal stuff,
i made sure it was clear from the start what
is and what is not my work, so there is not problem.
it's in my contract and i have no worry, except\
that i can spend really less time on the f-cpu.
eGroups Sponsor
From Yann Guidon Thu Nov 9 07:54:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00368 for ; Thu, 9 Nov 2000 12:04:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 12:04:28 +0100 (MET) Received: (qmail 17412 invoked by uid 0); 9 Nov 2000 06:50:27 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx03) with SMTP; 9 Nov 2000 06:50:27 -0000 X-eGroups-Return: sentto-1101623-1351-973752622-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hp.egroups.com with NNFMP; 09 Nov 2000 06:50:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 06:50:22 -0000 Received: (qmail 22447 invoked from network); 9 Nov 2000 06:50:21 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 9 Nov 2000 06:50:21 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 9 Nov 2000 06:50:21 -0000 Received: from f-cpu.org (nas3-53.ras.club-internet.fr [195.36.203.53]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA03054 for ; Thu, 9 Nov 2000 07:49:30 +0100 (MET) Message-ID: <3A0A4A17.CDB840F4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 07:54:15 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Cray has blown a fuse... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2be785ce54af9ee10e6148ddb2614c9d Status: R X-Status: N http://www.srccomp.com/products_map.htm
gives some hints about what he would have done
if he had survived his accident in 96...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jeff Davies Thu Nov 9 17:29:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01246 for ; Thu, 9 Nov 2000 19:53:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 19:53:06 +0100 (MET) Received: (qmail 13189 invoked by uid 0); 9 Nov 2000 16:34:43 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx07) with SMTP; 9 Nov 2000 16:34:43 -0000 X-eGroups-Return: sentto-1101623-1352-973787673-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 09 Nov 2000 16:34:37 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 16:34:33 -0000 Received: (qmail 10721 invoked from network); 9 Nov 2000 16:34:24 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 9 Nov 2000 16:34:24 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta2 with SMTP; 9 Nov 2000 16:34:24 -0000 Received: from modem-71.bicolor-pseudochromis.dialup.pol.co.uk ([62.136.231.71] helo=llandre.freeserve.co.uk) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13tueb-0004N7-00 for f-cpu@egroups.com; Thu, 09 Nov 2000 16:34:21 +0000 Message-ID: <3A0AD101.1BB273DA@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 16:29:53 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Glossary DTD again Content-Type: multipart/mixed; boundary="------------CBCFBC704DEB554016C701E7" X-UIDL: 61ff93e17ae3594f644a065f881fb675 Status: R X-Status: N --------------CBCFBC704DEB554016C701E7 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit This time from netscape (last time I sent it from KDE kmail).

Jeff Davies
eGroups Sponsor
--------------CBCFBC704DEB554016C701E7 Content-Type: application/x-unknown-content-type-dtd_auto_file; name="fcpudoc.dtd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fcpudoc.dtd" PCEtLSBUaW1lIFByaW1pdGl2ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgSE9VUiBDREFUQT4NCjwhRUxFTUVOVCBN SU5VVEUgQ0RBVEE+DQo8IUVMRU1FTlQgU0VDT05EIENEQVRBPg0KPCFFTEVNRU5UIERBWSBD REFUQT4NCjwhRUxFTUVOVCBNT05USCBDREFUQT4NCjwhRUxFTUVOVCBZRUFSIENEQVRBPg0K DQo8IS0tIFRpbWUgSW50ZXJtZWRpYXRlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVOVCBEQVRFIChIT1VSLE1JTlVURSxTRUNP TkQpPg0KPCFFTEVNRU5UIFRJTUUgKFlFQVIsTU9OVEgsREFZKT4NCjwhRUxFTUVOVCBEQVRF LVRJTUUgKERBVEUsVElNRSk+DQo8IUVMRU1FTlQgVElNRS1SQU5HRSAoREFURS1USU1FLERB VEUtVElNRSk+DQoNCjwhLS0gVGltZXN0YW1wcyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIElORk8tVElNRVNU QU1QIChEQVRFLVRJTUUpPg0KDQo8IS0tIFBlcnNvbiBOYW1lIHByaW1pdGl2ZXMgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVOVCBQRVJT T04tVElUTEUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEZJUlNULU5BTUUgLSAtIENEQVRBPg0K PCFFTEVNRU5UIExBU1QtTkFNRSAtIC0gQ0RBVEE+DQoNCjwhLS0gUGVyc29uIE5hbWUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0K PCFFTEVNRU5UIFBFUlNPTi1OQU1FIC0gLSAoUEVSU09OLVRJVExFPyxGSVJTVC1OQU1FKixM QVNULU5BTUUqKT4NCg0KPCEtLSBBZGRyZXNzIFByaW1pdGl2ZXMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgU1RSRUVULUFE RFJFU1MgLSAtIENEQVRBPg0KPCFFTEVNRU5UIENJVFkgLSAtIENEQVRBPg0KPCFFTEVNRU5U IENPVU5UWSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgUkVHSU9OIC0gLSBDREFUQT4NCjwhRUxF TUVOVCBDT1VOVFJZIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBGRURFUkFUSU9OIC0gLSBDREFU QT4NCjwhRUxFTUVOVCBQT1NUQUwtQ09ERSAtIC0gQ0RBVEE+DQoNCjwhLS0gQWRkcmVzcyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tPg0KPCFFTEVNRU5UIEFERFJFU1MgLSAtIChTVFJFRVQtQUREUkVTUyosQ0lUWT8sQ09V TlRZPyxSRUdJT04/LENPVU5UUlk/LEZFREVSQVRJT04/LFBPU1RBTC1DT0RFPyk+DQoNCjwh LS0gQ29udGFjdCBQcmltaXRpdmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIENPTVBBTlktTkFNRSAtIC0gQ0RBVEE+DQo8 IUVMRU1FTlQgRU1BSUwtQUREUkVTUyAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgVVJJIC0gLSBD REFUQT4NCjwhRUxFTUVOVCBURUxFUEhPTkUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEdTTS1U RUxFUEhPTkUgLSAtIENEQVRBPg0KPCFFTEVNRU5UIEpPQi1USVRMRSAtIC0gQ0RBVEE+DQoN CjwhLS0gQ29udGFjdCB0eXBlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIENPTVBBTlktQ09OVEFDVC1ERVRBSUxT IChDT01QQU5ZLU5BTUUsQUREUkVTUyosRU1BSUwtQUREUkVTUyosVVJJKixURUxFUEhPTkUq LEdTTS1URUxFUEhPTkUqLElORk8tVElNRVNUQU1QKT4NCjwhRUxFTUVOVCBJTkRJVklEVUFM LUNPTlRBQ1QtREVUQUlMUyAoUEVSU09OLU5BTUUsSk9CLVRJVExFPyxDT01QQU5ZLU5BTUU/ LEFERFJFU1MqLEVNQUlMLUFERFJFU1MqLFVSSSosVEVMRVBIT05FKixHU00tVEVMRVBIT05F KixJTkZPLVRJTUVTVEFNUCk+DQoNCjwhLS0gR3JvdXBzIG9mIENvbnRhY3RzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPg0KPCFFTEVNRU5UIEFV VEhPUlMgKChJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3xDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUykqKSA+DQo8IUVMRU1FTlQgRURJVE9SUyAoKElORElWSURVQUwtQ09OVEFDVC1ERVRB SUxTfENPTVBBTlktQ09OVEFDVC1ERVRBSUxTKSopID4NCjwhRUxFTUVOVCBQUklDRS1QUk9W SURFUlMgKChJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3xDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUykqKT4NCjwhRUxFTUVOVCBQVUJMSVNIRVJTICgoSU5ESVZJRFVBTC1DT05UQUNULURF VEFJTFN8Q09NUEFOWS1DT05UQUNULURFVEFJTFMpKik+DQoNCg0KPCEtLSBGQ1BVLVJJQ0gt VEVYVC1GT1ItREVTQ1JJUFRJT04tRklFTEQtUFJJTUlUSVZFUyBTVEFSVCBIRVJFICAgICAg IC0tPg0KDQo8IS0tIHRleHQgc3R5bGUgaW5mb3JtYXRpb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0+DQo8IUVMRU1FTlQgRU1QSCAtIC0gQ0RBVEE+ DQo8IUVMRU1FTlQgVkVSQkFUSU0gLSAtIENEQVRBPg0KDQo8IUVMRU1FTlQgU0VDVElPTi1U SVRMRSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgU0VDVElPTiAtIC0gKFNFQ1RJT04tVElUTEUs REVTQ1JJUFRJT04pPg0KDQo8IUVMRU1FTlQgVEVYVCAtIC0gQ0RBVEE+DQoNCjwhRUxFTUVO VCBJTkxJTkUtR1JBUEhJQyAtIC0gKFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tR1JBUEhJ QyAtIC0gKElOTElORS1HUkFQSElDPyxURVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8t TU9WSUUgLSAtIChJTkxJTkUtR1JBUEhJQz8sVEVYVCxVUkkpID4NCjwhRUxFTUVOVCBMSU5L LVRPLVNPVU5EIC0gLSAoSU5MSU5FLUdSQVBISUM/LFRFWFQsVVJJKSA+DQo8IUVMRU1FTlQg TElOSy1UTy1USFJFRS1ELVdPUkxEIC0gLSAoSU5MSU5FLUdSQVBISUM/LFRFWFQsVVJJKSA+ DQo8IUVMRU1FTlQgTElOSy1UTy1KQVZBLUFQUExFVCAtIC0gKElOTElORS1HUkFQSElDPyxU RVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tT1RIRVItTUVESUEgLSAtIChJTkxJTkUt R1JBUEhJQz8sVEVYVCxVUkkpID4NCjwhRUxFTUVOVCBMSU5LLVRPLUhUTUwtUEFHRSAtIC0g KElOTElORS1HUkFQSElDPyxURVhULFVSSSkgPg0KPCFFTEVNRU5UIExJTkstVE8tUkVGRVJF TkNFLVRFUk0gLSAtIChURVJNLUlEKSAtLXRoaXMgcmVmZXJzIHRvIGFub3RoZXIgdGVybSBk ZXNjcmlwdGlvbiBkb2N1bWVudCAtLT4NCg0KDQo8IUVMRU1FTlQgKFRBU0stQ09ORElUSU9O fFRBU0stU1RBVFVTKSAtIC0gQ0RBVEE+DQo8IUVMRU1FTlQgVEFTSy1EVUUtREFURSAtIC0g KERBVEUpPg0KPCFFTEVNRU5UIFRBU0stQ09NUExFVEUtREFURSAtIC0gKERBVEUpPg0KPCFF TEVNRU5UIFRBU0sgLSAtIChUQVNLLURVRS1EQVRFPyxUQVNLLUNPTVBMRVRFLURBVEU/LFRB U0stU1RBVFVTPyxURVhUKT4NCjwhRUxFTUVOVCBUQVNLLVNFUVVFTkNFIC0gLSAoVEFTSy1D T05ESVRJT04/LCBUQVNLLURVRS1EQVRFPywgVEFTSy1DT01QTEVURS1EQVRFPywgVEFTSy1T VEFUVVM/LCAoVEFTSy1TRVFVRU5DRXxUQVNLKSopPg0KDQo8IUVMRU1FTlQgKFBST0NFU1Mt Q09ORElUSU9OfFBST0NFU1MtTkFNRXxQUk9DRVNTLVRFWFQpIC0gLSBDREFUQT4NCjwhRUxF TUVOVCBQUk9DRVNTIC0gLSAoUFJPQ0VTUy1OQU1FLFBST0NFU1MtVEVYVCkgPg0KPCFFTEVN RU5UIFBST0NFU1MtU0VRVUVOQ0UgKFBST0NFU1MtQ09ORElUSU9OLCAoUFJPQ0VTUy1TRVFV RU5DRXxQUk9DRVNTKSopPg0KDQo8IUVMRU1FTlQgKFBVQkxJQ0FUSU9OLVRJVExFfEVESVRJ T058UEFHRXxDSEFQVEVSfFZFUlNJT058TElDRU5DRS1UWVBFfFBBQ0tBR0UtTkFNRSkgLSAt IENEQVRBPg0KPCFFTEVNRU5UIERBVEUtUFVCTElTSEVEIC0gLSAoREFURSk+DQo8IUVMRU1F TlQgKERPV05MT0FELVVSSXxJTkZPUk1BVElPTi1VUkl8TElOSy1VUkkpIC0gLSAoVVJJKSA+ DQoNCjwhRUxFTUVOVCBSRUZFUkVOQ0UtVE8tQk9PSyAtIC0gKFBVQkxJQ0FUSU9OLVRJVExF LEVESVRJT04/LFBBR0U/LENIQVBURVI/LERBVEUtUFVCTElTSEVELFBVQkxJU0hFUlMsIEFV VEhPUlM/LCBFRElUT1JTPyk+DQo8IUVMRU1FTlQgUkVGRVJFTkNFLVRPLU9OTElORS1CT09L IC0gLSAoUFVCTElDQVRJT04tVElUTEUsVkVSU0lPTixET1dOTE9BRC1VUkk/LElORk9STUFU SU9OLVVSST8sTElOSy1VUkk/LERBVEUtUFVCTElTSEVELFBVQkxJU0hFUlMsIEFVVEhPUlM/ LCBFRElUT1JTPyxMSUNFTkNFLVRZUEUpPg0KPCFFTEVNRU5UIFJFRkVSRU5DRS1UTy1TT0ZU V0FSRSAtIC0gKFBBQ0tBR0UtTkFNRSxWRVJTSU9OLERPV05MT0FELVVSST8sSU5GT1JNQVRJ T04tVVJJPyxMSU5LLVVSST8sREFURS1QVUJMSVNIRUQsUFVCTElTSEVSUywgQVVUSE9SUz8s IEVESVRPUlM/LExJQ0VOQ0UtVFlQRSk+DQoNCjwhLS0gSW5mb3JtYXRpb24gU3RydWN0dXJl cyAtLT4NCjwhRUxFTUVOVCBMSVNULUVOVFJZIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBMSVNU IC0gLSAoTElTVC1FTlRSWSopPg0KDQo8IUVMRU1FTlQgSEVBRElORy1ST1cgLSAtICgoSEVB RElORy1DRUxMLENFTEwqKXwoQ0VMTCopKT4NCjwhRUxFTUVOVCBST1cgLSAtICgoSEVBRElO Ry1DRUxMLENFTEwqKXwoQ0VMTCopKT4NCjwhRUxFTUVOVCBIRUFESU5HLUNFTEwgLSAtIENE QVRBPg0KPCFFTEVNRU5UIENFTEwgLSAtIENEQVRBPg0KPCFFTEVNRU5UIFRBQkxFIC0gLSAo KEhFQURJTkctUk9XLFJPVyopfChST1cqKSk+IA0KDQoNCjwhLS0gUHJpY2UgSXRlbSBwYWly IC0tPg0KDQo8IUVMRU1FTlQgUVVBTlRJVFkgLSAtIENEQVRBIC0tbnVtYmVyIG9mIHVuaXRz IHB1cmNoYXNlZCBmb3IgdGhpcyBwcmljZS0tPg0KPCFFTEVNRU5UIEFNT1VOVCAtIC0gQ0RB VEEgLS1hbW91bnQgb2YgY3VycmVuY3ktLT4NCjwhRUxFTUVOVCBDVVJSRU5DWSAtIC0gQ0RB VEE+DQo8IUVMRU1FTlQgU09VUkNFIC0gLSBDREFUQSAtLWVnIG5ld3NwYXBlciBuYW1lLS0+ DQo8IUVMRU1FTlQgU09VUkNFLVRZUEUgLSAtIENEQVRBIC0tZWcgJ25ld3NwYXBlcictLT4N Cg0KPCFFTEVNRU5UIChJVEVNLU5BTUUsSVRFTS1NT0RFTCxJVEVNLVZFUlNJT04pIC0gLSBD REFUQT4NCjwhRUxFTUVOVCBNQU5VRkFDVFVSRVIgLSAtIChDT01QQU5ZLUNPTlRBQ1QtREVU QUlMUyk+DQo8IUVMRU1FTlQgSVRFTSAtIC0gKElURU0tTkFNRSwgSVRFTS1CUkFORD8sIElU RU0tTU9ERUw/LCBJVEVNLVZFUlNJT04/LCBNQU5VRkFDVFVSRVIpPg0KPCFFTEVNRU5UIFBS SUNFIC0gLSAoUVVBTlRJVFksQU1PVU5ULENVUlJFTkNZLFNPVVJDRSxTT1VSQ0UtVFlQRSxU SU1FU1RBTVAsIFBSSUNFLVBST1ZJREVSUyk+DQo8IUVMRU1FTlQgUFJJQ0UtSVRFTS1QQUlS IC0gLSAoSVRFTSwgUFJJQ0UpPg0KDQoNCjwhLS0gZW5jeWNsb3BhZWRpYSBlbnRyeSBwcmlt aXRpdmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLT4NCjwhRUxFTUVO VCAoVEVSTS1OQU1FfEVESVQtTk9URVMpIC0gLSBDREFUQT4NCjwhRUxFTUVOVCBURVJNLUlE IC0gLSBDREFUQSAgLS10aGlzIGlzIGhvdyB0aGUgdGVybXMgYXJlIGluZGV4ZWQsIGl0J3Mg YmFzaWNhbGx5IGEgaGFzaGVkIGluZGV4IHBvaW50ZXIgb3Igc29tZSBzb3J0IC0tPg0KPCFF TEVNRU5UIFRFUk0tUVVBTElGSUVSIC0gLSBDREFUQSAgLS1mb3IgZXhhbXBsZSBQQVJJUywg ZnJhbmNlIC0gaGVyZSBmcmFuY2UgaXMgdGhlIHF1YWxpZmllciAtLT4NCjwhRUxFTUVOVCBM QU5HVUFHRS1QQVJUIC0gLSBDREFUQSAgLS1lZyBub3VuLCB2ZXJiIGV0YyAtLT4NCjwhRUxF TUVOVCBTT1VSQ0UtTEFOR1VBR0UgLSAtIENEQVRBID4NCjwhRUxFTUVOVCBDQVRFR09SWSAt IC0gQ0RBVEEgPg0KPCFFTEVNRU5UIENBVEVHT1JZLUxJU1QgLSAtIChDQVRFR09SWSopPg0K DQo8IUVMRU1FTlQgQVNTT0NJQVRFRC1URVJNUyAtIC0gKFRFUk0tSUQqKT4NCjwhRUxFTUVO VCBQVUJMSVNIRUQtREFURSAtIC0gKERBVEUpPg0KPCFFTEVNRU5UIEVESVQgLSAtIChEQVRF LEVESVRPUlMsRURJVC1OT1RFUyk+DQo8IUVMRU1FTlQgRURJVC1ISVNUT1JZIC0gLSAoRURJ VCopPg0KDQoNCjwhRUxFTUVOVCBERVNDUklQVElPTiAtIC0gKChEQVRFfFRJTUUtUkFOR0V8 VEFTSy1TRVFVRU5DRXxQUk9DRVNTLVNFUVVFTkNFfFJFRkVSRU5DRS1UTy1TT0ZUV0FSRXwN ClJFRkVSRU5DRS1UTy1PTkxJTkUtQk9PS3xSRUZFUkVOQ0UtVE8tQk9PS3xJTkxJTkUtR1JB UEhJQ3xMSU5LLVRPLUdSQVBISUN8DQpMSU5LLVRPLU1PVklFfExJTkstVE8tU09VTkR8TElO Sy1UTy1USFJFRS1ELVdPUkxEfExJTkstVE8tSkFWQS1BUFBMRVR8DQpMSU5LLVRPLU9USEVS LU1FRElBfExJTkstVE8tSFRNTC1QQUdFfExJTkstVE8tUkVGRVJFTkNFLVRFUk18U0VDVElP TnxDT01QQU5ZLUNPTlRBQ1QtREVUQUlMU3xJTkRJVklEVUFMLUNPTlRBQ1QtREVUQUlMU3wN CkxJU1R8VEFCTEV8UFJJQ0UtSVRFTS1QQUlSfCNQQ0RBVEEpKik+DQoNCjwhRUxFTUVOVCBF TkNZQ0xPUEFFRElBLUVOVFJZIC0gLSAoVEVSTS1OQU1FLCBURVJNLUlEICwgVEVSTS1RVUFM SUZJRVIqICwgTEFOR1VBR0UtUEFSVD8sIFNPVVJDRS1MQU5HVUFHRSwgQ0FURUdPUlktTElT VCwgREVTQ1JJUFRJT04sIEFTU09DSUFURUQtVEVSTVMsIFBVQkxJU0hFRC1EQVRFLCBBVVRI T1JTLCBFRElULUhJU1RPUlkpPg0K --------------CBCFBC704DEB554016C701E7-- From bfranchuk@jetnet.ab.ca Thu Nov 9 18:35:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01255 for ; Thu, 9 Nov 2000 19:53:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 19:53:10 +0100 (MET) Received: (qmail 30311 invoked by uid 0); 9 Nov 2000 17:35:34 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx01) with SMTP; 9 Nov 2000 17:35:34 -0000 X-eGroups-Return: sentto-1101623-1353-973791314-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by mk.egroups.com with NNFMP; 09 Nov 2000 17:35:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 17:35:13 -0000 Received: (qmail 18703 invoked from network); 9 Nov 2000 17:35:12 -0000 Received: from unknown (10.1.10.26) by m2.onelist.org with QMQP; 9 Nov 2000 17:35:12 -0000 Received: from unknown (HELO fk.egroups.com) (10.1.10.47) by mta1 with SMTP; 9 Nov 2000 17:35:12 -0000 X-eGroups-Return: bfranchuk@jetnet.ab.ca Received: from [10.1.2.240] by fk.egroups.com with NNFMP; 09 Nov 2000 17:35:12 -0000 To: f-cpu@egroups.com Message-ID: <8uen8f+p78f@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 207.153.6.49 From: bfranchuk@jetnet.ab.ca MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 17:35:11 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 95b4253f2cba9ed92781d2539f1c7d70 Status: R X-Status: N Taking a look at some old? Fcpu documentation you have a
classic Load/Store design. Ho hum another Foobar design
compared to the great Marketing giants like Intel. It has to
be marketing cause to me a 300MHZ vs 600 MHZ CPU is not that much
faster for general use, yet several times the price.:(

The early advantage the RISC machines had over CISC processers
is that complex addressing modes could be computed better
and reused more often. Both styles of machines have +-7 bit
or +- 31 bit immedate values for address calculation. Mind you that
is Gasp +- 32 words or 16 long longs before you have use long
addressing. This may be fine for benchmarks but I know a C-stack frame
is more often in the range of +-2Kb wide. I think if you have a risc
machine more thought needs to go into address calculation modes
as that is what you do more of. I would say 1/3 of the risc operations
are involved in address calculations and this some room where some
fine tuning might be made in the design.
I was thinking since a Frame register is used so often
in high level lanuages it may be useful to define one register
a hardware frame register and some specific instructions for it.
I was thinking of adding LoadFrame,StoreFrame,FrameEfa.In all
3 instructions, a 12bit constant formed by two of the register
fields would be added to the frame register giving a efective
address for a load,store or Efa instuction.

Ben.
eGroups Sponsor
From Jeff Davies Thu Nov 9 20:05:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01673 for ; Thu, 9 Nov 2000 23:35:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 23:35:18 +0100 (MET) Received: (qmail 18691 invoked by uid 0); 9 Nov 2000 19:12:30 -0000 Received: from hk.egroups.com (208.50.99.220) by mx11.rz2.gmx.net (mx11) with SMTP; 9 Nov 2000 19:12:30 -0000 X-eGroups-Return: sentto-1101623-1354-973797132-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 09 Nov 2000 19:12:28 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 19:12:11 -0000 Received: (qmail 12793 invoked from network); 9 Nov 2000 19:10:31 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 9 Nov 2000 19:10:31 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta1 with SMTP; 9 Nov 2000 19:10:30 -0000 Received: from modem-139.blue-head-tilefish.dialup.pol.co.uk ([62.136.235.139] helo=llandre.freeserve.co.uk) by mail3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13tx5d-0005yL-00 for f-cpu@egroups.com; Thu, 09 Nov 2000 19:10:26 +0000 Message-ID: <3A0AF594.7BF394FC@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 19:05:56 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DTD again + a Programming DTD ie XML programming language. Content-Type: multipart/mixed; boundary="------------BF04EBE0748A1DA755828FBE" X-UIDL: ad10cb65450e2e9d0c9eb577d31138a9 Status: R X-Status: N --------------BF04EBE0748A1DA755828FBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit 1. Here is the glossary/encyclopaedia dtd and a high level programming
dtd (both pretty early).
Both work with XMetal.

2. Here are the concepts behind the programming DTD.

IBM xeena is a tree based (java) XML editor, the gui of which (tree
control) is the best way to edit
structured documents.

It occurred to me (an YG and myself have talked about this a long time
ago on this list) that you could
enter a program in a structured document editor  (XML/SGML).

3. Recently I have been doing boring documentation in audited code, and
it occurred to me that the auditing
information and the code should be edited together.

Why not do this in XML/SGML editor?

So, you will see in the DTD (fcpuhlc.dtd) link to Data Flow Diagram URIs
and stuff, and each step in the
code has a id number assigned (this should match the Data Flow Diagram).

I think that diagrams should be edited in XFIG (or whatever) and stored
as PNG/JPG files?

As you can see, things to add might be <EQUALS> for inside expressions,
and <CARRIAGE-RETURN><LINE-FEED> etc.

note: the description element inside each code step, and code-section
will be made richer in the vein
of the description field in the glossary dtd (fcpudoc.dtd). This means
inline graphics, links to movies
links to sound etc.

4. There is no class structure yet. Perhaps this could be
<CLASS>
    <CLASS-NAME>thingy</CLASS-NAME>
    <INHERIT-FROM>oldclass</INHERIT-FROM>
    <PUBLIC-MEMBER-VARIABLES><MEMBER-VARIABLE>
        <NAME>xpos</NAME><TYPE>INTEGER</TYPE>
    </MEMBER-VARIABLE></PUBLIC-MEMBER-VARIABLES>
    <PRIVATE-MEMBER-VARIABLES><MEMBER-VARIABLE>
        <NAME>xpostemp</NAME><TYPE>INTEGER</TYPE>
    </MEMBER-VARIABLE></PRIVATE-MEMBER-VARIABLES>
    <PUBLIC-MEMBER-FUNCTIONS><MEMBER-FUNCTION>
        <NAME>goDoIt</NAME><TYPE>VOID</TYPE>
        <PARAMETERS-IN>
           <PARAMETER>
           <NAME>texttoputondisplay</NAME><TYPE>STRING</TYPE>
           </PARAMETER>
         <PARAMETERS-IN>
    </MEMBER-FUNCTION></PUBLIC-MEMBER-FUNCTION>
   </CLASS>

Note: you wouldn't edit the above as text, you would drag and drop
things in an XML editor.
(think tree control for the above structure and context sensitive button
bar for inserting elements).

5. It should be pretty obvious that the above kind of structure is
easily transformable to C++ or JAVA (or basic
or pascal etc etc) using simple string replace functions (using sed -
the unix/linux string editor) from the unix/linux command line.
The same document could also be transformed into a functional spec!!
Either direct to latex, or into
a publishing DTD like Docbook, and from there to latex. (or XHTML, WML
etc)

6. Before you ask, omittable tags are not used to ensure total
consistency between SGML and XML.
7. before you ask, attributes are not used

It could also be transformed by XSLT.

8. I was wondering if the same should be done for low level programming:

eg: <COPY><SRCREG>R1</SRCREG><DESTREG>R2</DESTREG></COPY>

9. What about expressing a circuit in an XML format, you could transform
to VHDL or Verilog!
<CIRCUIT>
   <EXTERNAL-NODES>
       <NODE>a11</NODE>
......
</CIRCUIT>

10. Perhaps if functionality can be expressed in a XML format, then the
same XML program might be
transformed into C++ or Java etc, or behavioural VHDL (a subset that
compiles into a netlist)!!!

Anyone have any comments, I could do with some feedback.

Jeff davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
--------------BF04EBE0748A1DA755828FBE Content-Type: application/x-zip-compressed; name="fcpu-dtds.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fcpu-dtds.zip" UEsDBBQAAAAIADGDZylQEqz0wAYAAD0aAAALAAAAZmNwdWRvYy5kdGS9GMlu2zj0PkD/gcUc ahvkHxQ1GIm21WorRaWTo2orEwHxMrLcNoA+fh6pjdTiTtxi1CYRyce3r3r/lhAksn2Kwjzb Z0X2LT2j1z6EfHjzx/u3zGUe8wXaBDFHlk0FNbY9x48FGzmImBX49siBTR/G8AS+2IzsPzDa kZUHjWTOoUjzfbrLkuK1wvUkA+QMzaR8uJIGV7zPDSjheAAl2cGKVwxyzAd4SAUmX7F8HeIg nPrrGkRB4/Ztbop4LpL96fV2U09PRMdfBYpEJKgXasQ1kmGan48H5Ceg3NMNbtMjGTIeBT4Q ES5DBP4NbbtyeCSIT70pAJeOnY/we8szzm9LbaYLsMQdrwvcsrXQ1Ed3uzw9n2+OuB47keCM CUJtm7MomtCP5YiHqaMg9icPOVs7gX/tJp+6umI241RMXw8D8DGXWIE9arVGTbc+PTXp+pmZ OltgqZ4lrjSxxJXQ9ZrDRifKEmtcLzWjWsdDkWyL32VUK/BC6j9cc3nmUcf9idlj7kycCHgJ N4E/hX0deeRnMB+Du5Go7SmkeDndUFImFQLpVlBLEJsJED9CM11TuDWooZwFBj0scCvOAhvS LbCZ9MxM7Pi2c+/YsbJ5j7aWCXCrDOk3HUvL38dTrdh1frxAsj8+Nir+NU+jsdgEHISZTUta Tmh/vpgj0ydtR/w2ZCF3LEZCHgAedjtSE2d85zrR5tfQtaZYWWFMgMsNGO4vQVYBB8DI4k4o cwVZOcy1QQDHc4RzzyJI1ZRDf8Q4021RIyvSHwU6Fy/PKcoOj8d8nxQZVK3//vQMy7xwMxG4 94zfQTrzBnHb1hRmKQmu1eQapk6o+gWsKWHewywVNUnW8V3HZ2TNabhxrAozhEnPLwDmExGB CWZeXWJJB0/f9cCp2E03IygK9k03xQaKDrHJl4C7t2H4SO8poWHoMnHT/UCA7xEPopTedH8j PJeEdH2b5jhbgef7ENOC8cr3ZvKNOPYcnLd4ys4oTx+hWUPFESWHY/GU5kj27miXnrd5dlIB sTtuL/v0UDTBo5OaCRp9kkELeQicr1RLiDoRR/MJN1YgdgyGkc29Ykq+zYdAMieA5n8OWYum IwblDFDUexV7lfZGqEbscyyVpiFt5Vti1KMywmmz2dCpkTR4lY7mi36cziDvWlCnNGU2O7Ks tQvF9YRqa5iKc/02Nm+PXerkHnKCu71WinpjTBCZ8i3apaeSNQKBJ5fWhobghSXkxEhuAmzl ow8hYKXWJwBSTE9JqSakpq7YU34xs4MvvhtQm0CAlLK4c6/iSa5ViKjIMXKejkCLnoDcBUHt ZQPpMGt8Q4oHzUgl3xKbfOKuEuKmBwDfqAv40mTeoB1UUX+NhVqXWJd5iXtCL3Ej9St5w7qJ rjAaBSvxhfJmSNNM+X8zWFd4RyvrUZFftsUFJpx+3QbEgrArg5UEqGTqQAduv2HUdvw14cGX CnbW7FjMdbH8tZiXs+pvT4mvv6IDTnB95UjQu7rL6EgCExh+JEH1Z/4BaY0XTFnbFDlFuken JMu7PqpB+TmmvjBmXoA5XPZfoaJA53w5ZNA2ny759ik5pzsEdkGq/pwk4n6H7Mk50MCU7I8X qECAaXvJ8/SwfemPKzGXfjhlQmgiuMUMlOnf6JB+P5+SE7B4SPZ9LqoryqX69961F98NFDFz BPMqp1dvHsytbvVaB8FUXvOoH6+g940545Vxpppi45pEXYF3lNUmuePUt5f1QvHRLGpOYKkT 7XXuchqoEDfGxZVlcKNsXOkIa6rC7QSF+/PECHqiuAmpwzsJ6ntG3y8Nvn0+nhL5URFWRf7y ug9hPdtWbZCqqzKHED8QbLphqVomzQma5gn+Px2/gyOnqms6oySXs8Qu/ZHuMMqKd2f0NTln 2+T5+QUlCFz/CXxfAaDTMZOfSREEwvm4T+FXXvTZVJRB+a4Dkw03GZARlP5I9icYX0LKHUiM j3lygCglCNq4tFkBj5K/fy7Jc/aYpfkg+1F/Hcs8HcpRySAhIwTCDqNvaf4VpcV28CWssnuD Qrttxibk8nWgp9fxc9Il2mZrkGZpFAWWA6e2amrrXqc20cTsaV9tIKUDdGe4rilY84sBONkA o41AM7mjjakNoDaTVXAKf9l9aC7NtnDQYY3W1vLNH1PNQTnoWEpzYCh7gxzgMsaz9lyNXO3K GKPaXW000vBoA08L2Q4x7Y45mJT1LDv1DaC88tlAUo5EqQpa2Usp5Z+hcrZhiypzl+UGIZV8 aqW/Swu4jXrci8IF7BgxA0m0FwfY9GisuwIeeDDu+Wnb4GDD16QM/wJQSwMEFAAAAAgA0ZNp KajrI7RWAgAAmAgAAAsAAABmY3B1aGxjLmR0ZKVV227jIBB9X2n/gWpfkhbUH6haTWAcs8KA ACfNv/jjO74bx05WWvkFmTNnzlyY+XgRghXS16zU55IZvKBhPrhzgIp9V4appJgQn79/fbTI 0nksamNuLJU6sqs2hqUANhYuVEzb5Jh0CukWEpNg2QmZhxhRMboCJt/l29v7X7jQ0VVeGwwL drCKgYmOeQwl+MgqkMEJH5AUSYzRhY6G+KoTmX599cbt9/GCBiu0iRnn/AWIl74DHSxUePxc IuhnunnsESS6KYyD1ChXE2sjSwhNTEHb851Zy9WZSQUJslujTwHCTWi1A4gok3ZWPOAYIbsc dUTRO9IYe/2z3+Nrhi1q27NFj1IELDCglSjqoHfY2x+CcnEVSkPbAf9k5YGQmDAIbZ9CXJ2e YeLIc1gyvx730CPlIfOywiv0aBVFcnuU/wVKYZRB+zaBz8EPUjqDdos6Y/o4Vlr5tiqe++eZ p53gp6aZwV2eNtvmQZ5GTE+WWfCsjjyv01rWdoqXGPym1x/j5OuP71DN6HPV8+ZCTnWiD4y4 gKmHRz7TrMNVKA0EJHDQQM+fLccGHybFWnduMuU0/72SJsEY8T+JW5LRCNRn2x0zvXmcM15b GXCCY+XTbR3Sw/vZn6DZLNoRu05sM/loJrbj3XCmPbGwHkY1vy8b3/DIh+LnoV1L2iKbirbx MaEX3ZLq4LOfZtTWzJRNVrVVRTum/XHf3j6fIi2sV7I24AM/nxRvBGJ0TLN5JzBrOrISw1Zh +ZDc6DK+HBT8wf7gTzYFX+46Pm81nu0vfhdsG03fMz9QSwMEFAAAAAgAU4NnKWmRK8/iAQAA FQQAAAsAAABmY3B1ZG9jLnNnbX1TW2/bIBR+r9T/wPpOadKHSRVCYobEbDa2AG+zlBcv921K qtjZmn/fA3YTJ6kq+fKd+znfAfpJZJErc4mkjsooyXIuheJYamdKZEvrZIruRk+Tfb2b/J4N Jovp8362nd7Pmtkdu72h74Qx6qRJseapZFr+QF6i5KRrzUqwqp61T2cFFbVZYSKJE67HBR9L 9mu3btb1Cs03y7/wp+TSgUbcyXFmSpwo604im1bNgJKjeIKdo5A2Mip3KtPs5VAj6MO/1Moo 6N4AdsolksXb/6jZorqpdg1qVuvafzZLaOjM7Syt2+824DZHf+YHSvqWYxjr6qK2eKL0N+wy PDY8j1XkufrpWNVxBJAWRrFV0zw/ERIaOJCX++V6QYk3UHKV4LwstzaLFBAhsKfcXi6jtwly 7ZsXX4C7GBQC1DBr+MawETYErgOgqdIFqB8p6ZAnMtOCDcLQHkFTIZJcJuSFizMDlZQW6rsS BU8wRDgeOSyk4yrxXUhjge/2LI2Usa7FX+cLoKGnoAl/g6L6t57XQM9RA8X7eZQeZbDCVFrH 07wdLcgfTzm8mvLxaso2Sym5YQ8PlARAU5gqDiQFAEVKNvzsQ/xRbUNIrwly2SD5iCJyJBKu pcMxHPj2DlyK79ze25tXUEsDBBQAAAAIADKUaSksv0WC3QIAACEIAAAOAAAAZmNwdWhscC1l Zy5zZ22lVdFumzAUfa/Uf/Ai7dF4NK00VTQSBadFIsBsp02mvqRgGioKGSZK9vezSTIMy1JV TaTIl3vu9fG5B8f64oYOm0cYOKGLIcUO88IA0DlleAIG4+untaieXhPzKY1X62UeG0mdDEbn Z5aOH1mRTewJZphQ6OmhipyyKHhcZ2XhJbyoszTjlYU6kG7BVPCqWLzxk6BoIcSmrJKTILZ4 zvmxVm3YI0xhOGV6FxU+03UccyH0Lg0M9etcHOHAxYHjYapFc30NA1kysgPqAfrDB6bxzUL9 rA53MXWIFzVCsyUH4lcOxIrHUsh4oWTtlOtovcuUeKNlXa+uEdpsNsaiEJkRl29IdkOSAlId jWX9lne6qSq9i+c2xKEkDvvEZU6P9aBRYzwNGrdAGmEHEjzGRKZws4ei9MrTtKGUrotY0RGK HEyeYVoIeHW1gIfElWlsFdFTHS3XZjYc++EjdD37To7ps1uuihd5pHe6WvtXYjdGPItCwpox E+yExKWYAZuC2cS3UAf5t06qyO5npjn83iKUslOKoe/dEps0Yu6WjeiUuV5oGpdD42JoIS2h g2bzn8NLY3hlXJhdDOo17rotE2BSJuucg6TkAtTSfmmZ5+UmK16AIT+Ab1dlVYvmjBWP5Rsp eA0WQp0RpFnOlQ00S8qLJZL7UbZb7h/okFCapmnnhEGwU0BK0Uft6lq1DHMPUodqFuqGkq4L CfTDUG6kfh9sMrLkT6N5ZqHDUmpyyPoP8kbwmPzaPnyw/anMyjkSTKnaV3pei2TdEbgtk3fB BAcMRviwvRc4BKtnsugoALVUHdv34cHd2pvTcF1VWVGnmvt3Jzh1BX/u+ht8FahA1eD96w/1 iD/eez7en0lTbXtzU1dr3lNSByNtgqj1yRG3EGy7YOxh3wXKVWBMwglg9q2PP2Gadj6tW7aa W3Te/xuTyIoPzej3R4f0r/otla6y+nGOKIu0dxJ1/tfPz/4AUEsBAhQAFAAAAAgAMYNnKVAS rPTABgAAPRoAAAsAAAAAAAAAAQAgALaBAAAAAGZjcHVkb2MuZHRkUEsBAhQAFAAAAAgA0ZNp KajrI7RWAgAAmAgAAAsAAAAAAAAAAQAgALaB6QYAAGZjcHVobGMuZHRkUEsBAhQAFAAAAAgA U4NnKWmRK8/iAQAAFQQAAAsAAAAAAAAAAQAgALaBaAkAAGZjcHVkb2Muc2dtUEsBAhQAFAAA AAgAMpRpKSy/RYLdAgAAIQgAAA4AAAAAAAAAAQAgALaBcwsAAGZjcHVobHAtZWcuc2dtUEsF BgAAAAAEAAQA5wAAAHwOAAAAAA== --------------BF04EBE0748A1DA755828FBE-- From Jeff Davies Thu Nov 9 20:39:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01679 for ; Thu, 9 Nov 2000 23:35:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 23:35:21 +0100 (MET) Received: (qmail 13011 invoked by uid 0); 9 Nov 2000 19:44:04 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx01) with SMTP; 9 Nov 2000 19:44:04 -0000 X-eGroups-Return: sentto-1101623-1355-973799030-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 09 Nov 2000 19:44:03 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 19:43:49 -0000 Received: (qmail 7649 invoked from network); 9 Nov 2000 19:43:49 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 9 Nov 2000 19:43:49 -0000 Received: from unknown (HELO mail4.svr.pol.co.uk) (195.92.193.211) by mta1 with SMTP; 9 Nov 2000 19:43:49 -0000 Received: from modem-114.montana.dialup.pol.co.uk ([62.137.77.114] helo=llandre.freeserve.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13txbu-0002tp-00 for f-cpu@egroups.com; Thu, 09 Nov 2000 19:43:47 +0000 Message-ID: <3A0AFD65.A6993537@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 19:39:17 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] making fcpu project more compelling ;) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 59b65ba5ae3f8f33088dfb8a8fb65ef8 Status: R X-Status: N Wonder if anyone on the list can edit quake worlds. We could put up a
quake world
on a server that you walk around that has fcpu art gallery (the logo
competition entries)
in it (and more besides, perhaps alphaghost wandering around eh YG?).

Is there anyway to add HTML links into a quake world like you can with
VRML??

I know this is a bit off-topic (off the serious business of VHDL
coding), but it would be
neat, and might generate some headlines on news sites.

Jeff Davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
From Thu Nov 9 22:32:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01685 for ; Thu, 9 Nov 2000 23:35:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 09 Nov 2000 23:35:23 +0100 (MET) Received: (qmail 18017 invoked by uid 0); 9 Nov 2000 22:05:07 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx03) with SMTP; 9 Nov 2000 22:05:07 -0000 X-eGroups-Return: sentto-1101623-1356-973807503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 09 Nov 2000 22:05:06 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:05:03 -0000 Received: (qmail 61532 invoked from network); 9 Nov 2000 22:05:02 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Nov 2000 22:05:02 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 9 Nov 2000 22:05:02 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 85E1432807 for ; Thu, 9 Nov 2000 16:32:42 -0500 (EST) To: f-cpu@egroups.com In-Reply-To: <3A0AFD65.A6993537@llandre.freeserve.co.uk> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 9 Nov 2000 16:32:42 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] making fcpu project more compelling ;) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4e01af744b22e142ddbc3e5d546122a8 Status: R X-Status: N
Why not do the F-CPU itself as a map?

rares

On Thu, 9 Nov 2000, Jeff Davies wrote:

> Wonder if anyone on the list can edit quake worlds. We could put up a
> quake world
> on a server that you walk around that has fcpu art gallery (the logo
> competition entries)
> in it (and more besides, perhaps alphaghost wandering around eh YG?).
>
> Is there anyway to add HTML links into a quake world like you can with
> VRML??
>
> I know this is a bit off-topic (off the serious business of VHDL
> coding), but it would be
> neat, and might generate some headlines on news sites.
>
> Jeff Davies
> jeff@llandre.freeserve.co.uk
>
>
>
>
>


eGroups Sponsor
Click Here!
From Yann Guidon Thu Nov 9 23:40:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00323 for ; Fri, 10 Nov 2000 17:44:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:25 +0100 (MET) Received: (qmail 30732 invoked by uid 0); 9 Nov 2000 22:35:23 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx07) with SMTP; 9 Nov 2000 22:35:23 -0000 X-eGroups-Return: sentto-1101623-1357-973809320-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 09 Nov 2000 22:35:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:35:20 -0000 Received: (qmail 81776 invoked from network); 9 Nov 2000 22:35:18 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Nov 2000 22:35:18 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 9 Nov 2000 22:35:18 -0000 Received: from f-cpu.org (nas4-131.aub.club-internet.fr [195.36.145.131]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA07081 for ; Thu, 9 Nov 2000 23:35:14 +0100 (MET) Message-ID: <3A0B27C4.99A5B510@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 23:40:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? (who cares ? :*D) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c535af7a54b507fdb85f2e503147d63 Status: R X-Status: N hi !

quick and dirty superficial answer while i'm still awake,
it will be completed as the discussion will unroll...

bfranchuk@jetnet.ab.ca wrote:
> Taking a look at some old? Fcpu documentation you have a
> classic Load/Store design.
the particular f-cpu instruction form eases a lot of things beyond
the usual RISC stuff. but it doesn't appear immediately.
you'll certainly understand if you look at a recent version,
see part 7 IIRC.

> Ho hum another Foobar design
> compared to the great Marketing giants like Intel. It has to
> be marketing cause to me a 300MHZ vs 600 MHZ CPU is not that much
> faster for general use, yet several times the price.:(
not even taking into account that the memory bandwidth is not
even better... low bandwidth kills a lot of SW.

> The early advantage the RISC machines had over CISC processers
> is that complex addressing modes could be computed better
> and reused more often. Both styles of machines have +-7 bit
> or +- 31 bit immedate values for address calculation.
hm... +-31 if using a register offset, i presume ;-)

> Mind you that
> is Gasp +- 32 words or 16 long longs before you have use long
> addressing. This may be fine for benchmarks but I know a C-stack frame
> is more often in the range of +-2Kb wide.
this depends on the kind of code, the algos, the coding style, the compiler...
the most critical parts of a code don't use any stack... the rest is just here
to "move data around" so the "core" can run as fast as possible.

> I think if you have a risc machine more thought needs
> to go into address calculation modes as that is what you do more of.
IBM, SPARC et al. have the same POV. The accelerate old access patterns.

linked lists are fine for me, but most can be recoded to linear arrays.
since most of the f-cpu code will be rewritten from scratch, we count
on the intelligence of the coder that is meant not to access sparse data.
regular strides are well suited for today's CPUs. the f-cpu seems to penalize
irregular access patterns, but in fact it only reflects what the memory does.
use registers instead :-)

> I would say 1/3 of the risc operations are involved in address calculations
> and this some room where some fine tuning might be made in the design.
The F-CPU has more directly accessible registers than most today.
it was fine tuned to have as much "raw power" as possible (look at the
stream hint bits etc) without taking 5 sq meters of silicon and 150 pipeline
stages. you remember how complex CISC addressing modes were awful. To me, the usual
RISC L/S are as fucked up because the instruction can be interrupted in the
middle of the pipeline, between the TLB and the cache stages.
here, for the F-CPU, the process is split and "dephased" so you perform
the cache access AND the address computation/TLB lookup at the same time.
double advantage : latency split in two, no fucked up pipeline. For Ever.
the inconvenient is that it's a matter of mentality, culture and habits,
you have to forecast and prepare your effective address long before
you use it. This may sound weird at the first glance but if you look
at what a normal CPU has to do, you'll see that it maps perfectly
to a simple CPU. More interesting, it doesn't penalize
"advanced" CPUs :-)))

> I was thinking since a Frame register is used so often
> in high level lanuages it may be useful to define one register
> a hardware frame register and some specific instructions for it.
No. Never. Read RISC books. Read the books that describe the ending of
the CISC era. the manual is clear : no "asymmetric" instruction, no
special register (except register zero), no limitation factor.
a "special register" with its own instruction is an ILP killer.
if you want a frame pointer, reserve a register with your compiler.
look at a GCC config files, GCC does the job rather well, Mathias
did some work already about that. We can configure the compiler to
use certain registers for address computations or pointer manipulations,
they are in the normal registers, just like the ALPHA, MIPS and
other RISC CPUs do.

> I was thinking of adding LoadFrame,StoreFrame,FrameEfa.In all
> 3 instructions, a 12bit constant formed by two of the register
> fields would be added to the frame register giving a efective
> address for a load,store or Efa instuction.
there #might# be a "store multiple" and "read multiple" instruction
#if# the SRB or a similar mechanism is implemented in a particular chip,
but otherwise, no special instruction to support a particular langage is
desired. it should remain as universal and flexible as possible.
Read Patterson and Hennessy's books and read the analysis of the
R2000 or R3000 chips. after all, the limiting factor is the memory
latency etc, not the frame-enabling instructions.
Plus, remember that for really fast function/procedure calls/returns,
it is highly recommended to use the registers : you have 63 of them,
why use the (slow) memory instructions ??? also remember that
the number of parameters that you pass is in general rather low,
something like 3 to 5 in average, so you can analyse your program
and allocate the right registers at the right place with a global
analysis. depending on the complexity, you can nest around 5 or 7
function calls with 64 registers. happy ? :-)

ok, it was really on top of my tired and cranky head.
i hope i didn't sound negative, it was discussed 1,5 year
ago on this list :-) i'm sure you'll learn the rest easily.
i hope to rest this week-end, and answer quietly to some more questions.
i also have some VHDL packages to check and bundle, so be patient.

last but not least : the Berlin meeting @17C3 will be certainly
extremely interesting. a lot of people have said that they are interested
to come. I'm now trying to arrange the confirmations etc.
This is a rather heavy organisation, please help AND come :-)

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Thu Nov 9 23:40:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00326 for ; Fri, 10 Nov 2000 17:44:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:27 +0100 (MET) Received: (qmail 16818 invoked by uid 0); 9 Nov 2000 22:35:25 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx16) with SMTP; 9 Nov 2000 22:35:25 -0000 X-eGroups-Return: sentto-1101623-1358-973809321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mo.egroups.com with NNFMP; 09 Nov 2000 22:35:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:35:20 -0000 Received: (qmail 9137 invoked from network); 9 Nov 2000 22:35:20 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Nov 2000 22:35:20 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 9 Nov 2000 23:36:25 -0000 Received: from f-cpu.org (nas4-131.aub.club-internet.fr [195.36.145.131]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA26336 for ; Thu, 9 Nov 2000 23:35:16 +0100 (MET) Message-ID: <3A0B27C6.72BEF6CA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0AFD65.A6993537@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 23:40:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] making fcpu project more compelling ;) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 02c9d99bffba5d147a93819433de4663 Status: R X-Status: N hi, and g'night,

Jeff Davies wrote:
> Wonder if anyone on the list can edit quake worlds. We could put up a quake world
> on a server that you walk around that has fcpu art gallery (the logo competition entries)
> in it (and more besides, perhaps alphaghost wandering around eh YG?).
> Is there anyway to add HTML links into a quake world like you can with VRML??
> I know this is a bit off-topic (off the serious business of VHDL
> coding), but it would be neat, and might generate some headlines on news sites.

i don't know, it would maybe be similar to the webring idea (using the net's tools
in a non-productive way). if something is done, there will be no problem to put it
on f-cpu.de/org (at least there shouldn't be ethical problems, technics is subject
to Murphy's law).
i wonder how the alpha ghost would be made. an alpha letter viewed in grey transparency,
floating around the coridors ? :-) [jeff, it was your idea first...]
maybe VRML will be easier to make than Quake levels (VRML is a standard).
i don't have Quake at home, anywhere else either, while it's easy to find VRML viewers.

thanks for the humor :-) "C'est de l'humour typiquement terrien"
(it's a typical human humor) but "so" F-CPU :-D

I don't have time to write about the other mail you sent about the DTD.
sorry, the work at mentor/meta is far from being quiet and resting...

> Jeff Davies
> jeff@llandre.freeserve.co.uk
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Marco Al" Thu Nov 9 23:43:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00329 for ; Fri, 10 Nov 2000 17:44:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:28 +0100 (MET) Received: (qmail 2064 invoked by uid 0); 9 Nov 2000 22:37:31 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx05) with SMTP; 9 Nov 2000 22:37:31 -0000 X-eGroups-Return: sentto-1101623-1359-973809444-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by ml.egroups.com with NNFMP; 09 Nov 2000 22:37:29 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:37:24 -0000 Received: (qmail 7090 invoked from network); 9 Nov 2000 22:37:24 -0000 Received: from unknown (10.1.10.142) by m2.onelist.org with QMQP; 9 Nov 2000 22:37:24 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 9 Nov 2000 23:38:29 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id XAA27270 for ; Thu, 9 Nov 2000 23:37:23 +0100 (MET) Message-ID: <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> To: References: <8uen8f+p78f@eGroups.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 9 Nov 2000 23:43:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 632279cb1e67a40ffd6fd3c6284d2d28 Status: R X-Status: N From: <bfranchuk@jetnet.ab.ca>


> Taking a look at some old? Fcpu documentation you have a
> classic Load/Store design. Ho hum another Foobar design
> compared to the great Marketing giants like Intel. It has to
> be marketing cause to me a 300MHZ vs 600 MHZ CPU is not that much
> faster for general use, yet several times the price.:(

Sure but how fast does it run the lates iD game? :) And why the negative
emoticon? All those people buying the 600 MHz one are providing extra volume
and buying at a greater margin such that you can buy your 300 MHz one at a
bargain price.

> The early advantage the RISC machines had over CISC processers
> is that complex addressing modes could be computed better
> and reused more often. Both styles of machines have +-7 bit
> or +- 31 bit immedate values for address calculation. Mind you that
> is Gasp +- 32 words or 16 long longs before you have use long
> addressing. This may be fine for benchmarks but I know a C-stack frame
> is more often in the range of +-2Kb wide. I think if you have a risc
> machine more thought needs to go into address calculation modes
> as that is what you do more of. I would say 1/3 of the risc operations
> are involved in address calculations and this some room where some
> fine tuning might be made in the design.
> I was thinking since a Frame register is used so often
> in high level lanuages it may be useful to define one register
> a hardware frame register and some specific instructions for it.
> I was thinking of adding LoadFrame,StoreFrame,FrameEfa.In all
> 3 instructions, a 12bit constant formed by two of the register
> fields would be added to the frame register giving a efective
> address for a load,store or Efa instuction.
>
> Ben.

I have little insight to offer myself... but this reminds me of a page from
one of the principle P6 architects
(http://www.cs.wisc.edu/~glew/HOME_DIRECTORY/work/research/public/instructio
n-set-issues.html)

"No Addressing Modes
Not providing any addressing modes is a classic RISC excess: e.g. providing
only register indirect addressing,
    dest := load( memory[register] )
    store( memory[register1] := register2)

Not having addressing modes hurts codes that access complex data structures
and records with different fields at various offsets. Post-increment
addressing, as was proposed for a Gould machine and implemented in IA64, is
only slightly better since it creates unnecessary dependencies and consumes
registers." (he backs it up a little and has some more points, but that was
the most relevant bit)

Marco
eGroups Sponsor
From Yann Guidon Thu Nov 9 23:42:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00332 for ; Fri, 10 Nov 2000 17:44:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:29 +0100 (MET) Received: (qmail 682 invoked by uid 0); 9 Nov 2000 22:38:09 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx15) with SMTP; 9 Nov 2000 22:38:09 -0000 X-eGroups-Return: sentto-1101623-1360-973809485-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.36] by hi.egroups.com with NNFMP; 09 Nov 2000 22:38:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:38:05 -0000 Received: (qmail 9323 invoked from network); 9 Nov 2000 22:38:05 -0000 Received: from unknown (10.1.10.27) by m2.onelist.org with QMQP; 9 Nov 2000 22:38:05 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 9 Nov 2000 22:38:04 -0000 Received: from f-cpu.org (nas4-131.aub.club-internet.fr [195.36.145.131]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA20687 for ; Thu, 9 Nov 2000 23:38:02 +0100 (MET) Message-ID: <3A0B286D.A9D58C1E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 09 Nov 2000 23:42:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] making fcpu project more compelling ;) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b7bc6fc0c3a56626837006ce2ae76d20 Status: R X-Status: N rares@moonbase.res.wpi.net wrote:
> Why not do the F-CPU itself as a map?

woah, where did you find this idea ? :*)

> rares
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Thu Nov 9 21:20:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00335 for ; Fri, 10 Nov 2000 17:44:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:29 +0100 (MET) Received: (qmail 15052 invoked by uid 0); 9 Nov 2000 22:39:07 -0000 Received: from mu.egroups.com (208.50.99.218) by mx12.rz2.gmx.net (mx12) with SMTP; 9 Nov 2000 22:39:07 -0000 X-eGroups-Return: sentto-1101623-1361-973809537-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mu.egroups.com with NNFMP; 09 Nov 2000 22:39:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_2_1); 9 Nov 2000 22:38:57 -0000 Received: (qmail 20104 invoked from network); 9 Nov 2000 22:38:57 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 9 Nov 2000 22:38:57 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.180) by mta3 with SMTP; 9 Nov 2000 23:39:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01774; Thu, 9 Nov 2000 21:20:43 +0100 Message-ID: <20001109212042.28917@thrai.stud.uni-hannover.de> To: f-cpu@eGroups.com References: <8uen8f+p78f@eGroups.com> X-Mailer: Mutt 0.84e In-Reply-To: <8uen8f+p78f@eGroups.com>; from bfranchuk@jetnet.ab.ca on Thu, Nov 09, 2000 at 05:35:11PM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 9 Nov 2000 21:20:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 32abbcd9701d79882adc053bb24e40e6 Status: R X-Status: N Hi there!

`F' means `Fun' :)

On Thu, Nov 09, 2000 at 05:35:11PM -0000, bfranchuk@jetnet.ab.ca wrote:
> Taking a look at some old? Fcpu documentation you have a
> classic Load/Store design. Ho hum another Foobar design
> compared to the great Marketing giants like Intel. It has to
> be marketing cause to me a 300MHZ vs 600 MHZ CPU is not that much
> faster for general use, yet several times the price.:(

The F-CPU design has been discussed for more than two years, it's now
stable (unless we encounter unsolvable problems), and we're going to
implement it as is.

If you want something unique, like a dataflow or TTA processor, or are
interested in things like reconfigurable logic, look for other projects
(or start your own).

> The early advantage the RISC machines had over CISC processers
> is that complex addressing modes could be computed better
> and reused more often. Both styles of machines have +-7 bit
> or +- 31 bit immedate values for address calculation. Mind you that
> is Gasp +- 32 words or 16 long longs before you have use long
> addressing. This may be fine for benchmarks but I know a C-stack frame
> is more often in the range of +-2Kb wide. I think if you have a risc
> machine more thought needs to go into address calculation modes
> as that is what you do more of. I would say 1/3 of the risc operations
> are involved in address calculations and this some room where some
> fine tuning might be made in the design.
> I was thinking since a Frame register is used so often
> in high level lanuages it may be useful to define one register
> a hardware frame register and some specific instructions for it.

We don't have a dedicated stack pointer, so why should we have a dedicated
frame pointer?

The F-CPU ABI isn't defined yet, but I guess that it will pass function
parameters in registers (if possible, depending on the number and size
of parameters), and that the callee will save registers to the stack
before it uses them (using post-{inc,dec}rement addressing, and a general
register as the stack pointer).

> I was thinking of adding LoadFrame,StoreFrame,FrameEfa.In all
> 3 instructions, a 12bit constant formed by two of the register
> fields would be added to the frame register giving a efective
> address for a load,store or Efa instuction.

An instruction that performs `r1 := (r2 + d)' (using *general* registers,
and with a reasonable range for `d') would be nice for array and structure
members, too, but the current load/store instructions have only 3 bits
left for `d'.  On the other hand, a separate instruction would be only
one or two cycles shorter than a sequence like

      loadconsx.0 d, r1
      add r1, r2, r3
      load (r3), r4

unless the load/store unit had its own adder (and a third input port),
and the range for `d' would be smaller, too (10 vs. 16 bits, or more
if we add another `loadcons').  Another argument is that an address
that is explicitly calculated can be reused (e.g. in the corresponding
`store' instruction) while an implicit add has to be repeated every
time the instruction is executed.  If the load/store is part of a loop,
the wasted cycles sum up quickly...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Ben Franchuk Tue Nov 7 18:26:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00359 for ; Fri, 10 Nov 2000 17:44:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:37 +0100 (MET) Received: (qmail 1541 invoked by uid 0); 10 Nov 2000 01:49:39 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx04) with SMTP; 10 Nov 2000 01:49:39 -0000 X-eGroups-Return: sentto-1101623-1362-973820976-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mv.egroups.com with NNFMP; 10 Nov 2000 01:49:38 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 01:49:36 -0000 Received: (qmail 9189 invoked from network); 10 Nov 2000 01:49:35 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Nov 2000 01:49:35 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 10 Nov 2000 01:49:34 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA04267 for ; Thu, 9 Nov 2000 18:42:00 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A083B55.A01A3B66@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@eGroups.com References: <8uen8f+p78f@eGroups.com> <20001109212042.28917@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 17:26:45 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aeb3a5b682b7f3eb01deddc11fdd016f Status: R X-Status: N Michael Riepe wrote:

> The F-CPU design has been discussed for more than two years, it's now
> stable (unless we encounter unsolvable problems), and we're going to
> implement it as is.

I am not saying to change the instruction set, but if you discover
FREE resources a single word midsize offset for C frames might be useful.

>look for other projects
> (or start your own).
I have - see bottom of email. :)

> We don't have a dedicated stack pointer, so why should we have a dedicated
> frame pointer?
>

A frame pointer is used a lot in many languages and if you can save
by using a short form over a long address that is one less word of bandwidth
taken
up and one word of core memory shorter.Opps ... ram memory shorter.
 

This brings up a good point. I can see 4 stack and frame pointers off hand.
User stack and frame pointer,system software stack and frame pointer,
interrupt software stack and frame pointer and virtual memory handler
stack and frame pointer. The question is how do you tell a C compiler
or other HTL what you registers you want to compile with?

> The F-CPU ABI isn't defined yet, but I guess that it will pass function
> parameters in registers (if possible, depending on the number and size
> of parameters), and that the callee will save registers to the stack
> before it uses them (using post-{inc,dec}rement addressing, and a general
> register as the stack pointer).

If this is the case then a frame pointer would not be of much use.


> An instruction that performs `r1 := (r2 + d)' (using *general* registers,
> and with a reasonable range for `d') would be nice for array and structure
> members, too, but the current load/store instructions have only 3 bits
> left for `d'.  On the other hand, a separate instruction would be only
> one or two cycles shorter than a sequence like

True, but other than the instruction set doc's are a long read
the F-cpu looks to be a fairly nice and complete machine.
Ben.
PS. With a language like Forth that bounces around a lot,
is there a way to tell the cache and pipe line logic, "**danger**
slow down the program curves ahead"?
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Tue Nov 7 19:56:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00362 for ; Fri, 10 Nov 2000 17:44:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:38 +0100 (MET) Received: (qmail 18024 invoked by uid 0); 10 Nov 2000 03:19:47 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx03) with SMTP; 10 Nov 2000 03:19:47 -0000 X-eGroups-Return: sentto-1101623-1363-973826373-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 10 Nov 2000 03:19:40 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 03:19:33 -0000 Received: (qmail 5772 invoked from network); 10 Nov 2000 03:19:32 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 10 Nov 2000 03:19:32 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 10 Nov 2000 04:20:37 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA08707 for ; Thu, 9 Nov 2000 20:11:56 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A08506B.8BD2097C@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <3A0B27C4.99A5B510@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 18:56:43 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? (who cares ? :*D) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: efd299e773899e60b3e651b32fd2fd84 Status: R X-Status: N Yann Guidon wrote:

> linked lists are fine for me, but most can be recoded to linear arrays.
> since most of the f-cpu code will be rewritten from scratch, we count
> on the intelligence of the coder that is meant not to access sparse data.
> regular strides are well suited for today's CPUs. the f-cpu seems to penalize
> irregular access patterns, but in fact it only reflects what the memory does.
> use registers instead :-)

I have started programing on a PDP8 and never got in the the habit of using
registers.

> The F-CPU has more directly accessible registers than most today.
> it was fine tuned to have as much "raw power" as possible (look at the
> stream hint bits etc) without taking 5 sq meters of silicon and 150 pipeline
> stages. you remember how complex CISC addressing modes were awful. To me, the
> usual
> RISC L/S are as fucked up because the instruction can be interrupted in the
> middle of the pipeline, between the TLB and the cache stages.
> here, for the F-CPU, the process is split and "dephased" so you perform
> the cache access AND the address computation/TLB lookup at the same time.
> double advantage : latency split in two, no fucked up pipeline. For Ever.
> the inconvenient is that it's a matter of mentality, culture and habits,
> you have to forecast and prepare your effective address long before
> you use it. This may sound weird at the first glance but if you look
> at what a normal CPU has to do, you'll see that it maps perfectly
> to a simple CPU. More interesting, it doesn't penalize
> "advanced" CPUs :-)))

That is  a good feature.Is there a way ( I need to read more doc's)
to state the time the effective address block is valid? this block is
valid for the next n# cycles before virtual memory messis things up.

> > I was thinking since a Frame register is used so often
> > in high level lanuages it may be useful to define one register
> > a hardware frame register and some specific instructions for it.
> No. Never. Read RISC books.
I don't have any, and the books here are "Basic programing Concepts
and the IBM 1620 Computer","Programing the the IBM 1130", "Programing the PDP8",
"386 Assembly Programing".
 
> Read the books that describe the ending of
> the CISC era. the manual is clear : no "asymmetric" instruction, no
> special register (except register zero), no limitation factor.
> a "special register" with its own instruction is an ILP killer.
> if you want a frame pointer, reserve a register with your compiler.
> look at a GCC config files, GCC does the job rather well, Mathias
> did some work already about that. We can configure the compiler to
> use certain registers for address computations or pointer manipulations,
> they are in the normal registers, just like the ALPHA, MIPS and
> other RISC CPUs do.

I think the ending is for both RISC and CISC instruction sets in the near
future.
Most cpu's emulate a Harvard style cpu by using a lot of internal
registers.Unfortanaly this requires large amount of opcode fetches.
With a .5 ns internal cycle and say a 20ns external memory cycle in the future
bandwidth to external memory will be the limiting factor regardless of the
internal
cpu design. This is a lot like the old vacuum tube computers with a fast but
heat limited cpu core and slow external magnetic core memory.
I think a streamlined CPU will result that has a simple CISC instruction set but
have a well defined local memory like risc stack register windows for on chip
use.

> there #might# be a "store multiple" and "read multiple" instruction
> #if# the SRB or a similar mechanism is implemented in a particular chip,
> but otherwise, no special instruction to support a particular langage is
> desired. it should remain as universal and flexible as possible
> Read Patterson and Hennessy's books and read the analysis of the
> R2000 or R3000 chips. after all, the limiting factor is the memory
> latency etc, not the frame-enabling instructions.

I programed intel chips,I KNOW what inflexable is.While memory latency is a
a limiting factor on cpu design, wasted resources are a close second
like software doing the hardware's job. Mice and too fast I/O
come to mind.


> Plus, remember that for really fast function/procedure calls/returns> it is highly recommended to use the registers : you have 63 of them,

I think 8 registers are more than ample in many cases for a CISC
well designed processor like the PDP11.

> why use the (slow) memory instructions ??? also remember that
> the number of parameters that you pass is in general rather low,
> something like 3 to 5 in average, so you can analyse your program
> and allocate the right registers at the right place with a global
> analysis. depending on the complexity, you can nest around 5 or 7
> function calls with 64 registers. happy ? :-)

Nope - I use recursive functions in small C.:)

> ok, it was really on top of my tired and cranky head.
> i hope i didn't sound negative, it was discussed 1,5 year
> ago on this list :-) i'm sure you'll learn the rest easily.
> i hope to rest this week-end, and answer quietly to some more questions.
> i also have some VHDL packages to check and bundle, so be patient.

Ok so I am 2 years late.

> last but not least : the Berlin meeting @17C3 will be certainly
> extremely interesting. a lot of people have said that they are interested
> to come. I'm now trying to arrange the confirmations etc.
> This is a rather heavy organisation, please help AND come :-)

I would love to come but I am financially challenged at the moment.
You don't have a video camera you could tie to the net for all us
home bodies?
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Tue Nov 7 20:34:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00368 for ; Fri, 10 Nov 2000 17:44:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:40 +0100 (MET) Received: (qmail 27785 invoked by uid 0); 10 Nov 2000 03:57:03 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx08) with SMTP; 10 Nov 2000 03:57:03 -0000 X-eGroups-Return: sentto-1101623-1364-973828619-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by jj.egroups.com with NNFMP; 10 Nov 2000 03:57:01 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 03:56:58 -0000 Received: (qmail 14410 invoked from network); 10 Nov 2000 03:56:58 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Nov 2000 03:56:58 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 10 Nov 2000 03:56:57 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA10692 for ; Thu, 9 Nov 2000 20:49:23 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A085932.166DDAF9@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 19:34:10 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0f9dde98d6d1fed34afe5ed2cd58a08a Status: R X-Status: N Marco Al wrote:
>
> From: <bfranchuk@jetnet.ab.ca>
>
> > Taking a look at some old? Fcpu documentation you have a
> > classic Load/Store design. Ho hum another Foobar design
> > compared to the great Marketing giants like Intel. It has to
> > be marketing cause to me a 300MHZ vs 600 MHZ CPU is not that much
> > faster for general use, yet several times the price.:(
>
> Sure but how fast does it run the lates iD game? :) And why the negative
> emoticon?
I got a 120MHZ machine.

> All those people buying the 600 MHz one are providing extra volume
> and buying at a greater margin such that you can buy your 300 MHz one at a
> bargain price.

@$##! you got a 600Mhz machine and I don't.:( I have 120 Mhz machine with
48 Meg and a .5G HD for windows and a 1G HD for linux and a 90Meg zip drive for
backups. Standard 640x480 16bit color screen and modem mouse and CD.
To me this is just the right size as I can save restore linux with
two boot floppies to my zip drive. The only reason I have windows is to
run a few DOS programs and some FPGA software.

All for open source FPGA chips raise their HANDS!!!

> (http://www.cs.wisc.edu/~glew/HOME_DIRECTORY/work/research/public/instructio
> n-set-issues.html)

Arg!! 404 File not found.

> "No Addressing Modes
> Not providing any addressing modes is a classic RISC excess: e.g. providing
> only register indirect addressing,
>     dest := load( memory[register] )
>     store( memory[register1] := register2)

Back tracking because of virtual memory is a pain regardless of what cpu you
use.
The best solution would be sort the program into data and stack,heap and arrays
and code and constants, having only the heap and arrays as virtual memory.
Programs are too big for virtual memory.

> Not having addressing modes hurts codes that access complex data structures
> and records with different fields at various offsets. Post-increment
> addressing, as was proposed for a Gould machine and implemented in IA64, is
> only slightly better since it creates unnecessary dependencies and consumes
> registers." (he backs it up a little and has some more points, but that was
> the most relevant bit.

I think the greatest problem is stack faults and virtual memory.I wonder
if 90% of windows 95 crashing is due to that?
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Keyshaun Fri Nov 10 06:05:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00371 for ; Fri, 10 Nov 2000 17:44:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:41 +0100 (MET) Received: (qmail 2612 invoked by uid 0); 10 Nov 2000 05:05:26 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx15) with SMTP; 10 Nov 2000 05:05:26 -0000 X-eGroups-Return: sentto-1101623-1365-973832719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 10 Nov 2000 05:05:23 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 05:05:18 -0000 Received: (qmail 36312 invoked from network); 10 Nov 2000 05:05:17 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 10 Nov 2000 05:05:17 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 10 Nov 2000 06:06:23 -0000 Received: (qmail 4520 invoked from network); 10 Nov 2000 05:05:17 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 10 Nov 2000 05:05:17 -0000 X-Sender: kruger@ultra1.inconnect.com To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 9 Nov 2000 22:05:17 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e1f1eeb89fb2ec3dd9cc69ed89a8bd70 Status: R X-Status: N Hi, I'm in the process of getting a website setup for the furtherment of
Open source and other Open movements in general.  The website is
Openall.org, don't try going there yet I don't have it setup with my
providor yet.  The purpose of openall.org is to raise money for open
source projects.  All projects must have a goal and focus.  The goal and
focus for the money raised by openall.org is to create a fully open source
platform.  I come to you because I believe the F-CPU to be the most mature
project that has an "open source" CPU.  I would like to use most of the
resources of openall.org to help get F-CPU produced and on ATX form factor
boards AND get Linux as the main OS for the platform. 

Now to break it down.

Things needed for an open source PC:
* CPU (F-CPU)
* System chipsets
* Linux port
-- options that would be nice
* Open source RAM designs
* 64bit open standards bus interface (less probable)
* System designed with tasking processor that handles memory management
      and task management (can be used to make system non-lockable)

Resources needed to obtain these:
* Foundary services (F-CPU, system chipsets, opensource RAM?)
* Money for prototypes
* People to work on the Linux port, distribution, and hardware


I would now like to discuss the subject of the open source RAM I have
suggested.  I don't know who is going to design it.  I'm sure that people
can be found.  I personally called to get prices on Micron memory chips
directly from a top level distributor.  I discovered that the high price
of memory comes directly from the manufacturer.  It distrubs me that two
chips that are only distinguishable by a number can have prices so
different.  The proper term for this is price fixing and anywere else
would be seriously considered as unethical.  Granted (in theory) there
more value added from one to the other, but I still think that if there is
an open source PC memory should be cheaper.

On the 64bit bus interface based on open standards (none have been drafted
that I have found).  I don't know about you, but I have never been able to
find docs on PCI.  It is a fine bus, but it is too closed.  I didn't have
money to join the organization that handles the standardization of
PCI.  Though, a special 64bit bus may never be implemented I feel that it
would be worthwhile to draft a standard for one and make it open source
for anyone who decides to start supporting/marketing it.

As stated above I believe that it would be benificial to have a small
tasking processor on systems.  Designing small systems with a tasking
processor would help to create an arcitecture that would scale very
well.  Some things that usually require locking all processors could be
taken care of by the tasking processor as well as the virtual memory
management.  Most importantly though is the fact that if a tasking
processor is alive in the unlikely event of a CPU lock (infinite loop with
interrupts disabled) the reset option could be linked to the individual
processor. Upon reset the processor could be directed to SMP init code and
be ready to be given more work by the tasking processor.  All that is lost
is the failed opperation.

The last thing I believe would leave questions is why foundary services
are needed.  This would be so that the F-CPU could be prduced at a good
price such that people would consider it worth while for them to buy it
instead of x86 or other.  The other reason is if memory were designed to
be used with the F-CPU on the open PC then it could be produced at a good
price.  I'm sure you see what I'm getting at now. 

I am here to further the cause of Open Source.  I can't do it myself so I
desire to focus efforts of many groups to a singe point where the
purpose is to make a fully open computer.

Shaun Kruger
thekernel@subdimension.com
eGroups Sponsor
From Jeff Davies Fri Nov 10 14:25:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00434 for ; Fri, 10 Nov 2000 17:44:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:44:58 +0100 (MET) Received: (qmail 8159 invoked by uid 0); 10 Nov 2000 13:30:03 -0000 Received: from hl.egroups.com (208.50.99.197) by mx12.rz2.gmx.net (mx12) with SMTP; 10 Nov 2000 13:30:03 -0000 X-eGroups-Return: sentto-1101623-1366-973862994-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hl.egroups.com with NNFMP; 10 Nov 2000 13:29:55 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 13:29:53 -0000 Received: (qmail 2081 invoked from network); 10 Nov 2000 13:29:53 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 10 Nov 2000 13:29:53 -0000 Received: from unknown (HELO mail4.svr.pol.co.uk) (195.92.193.211) by mta3 with SMTP; 10 Nov 2000 14:30:58 -0000 Received: from modem-82.south-dakota.dialup.pol.co.uk ([62.137.92.82] helo=llandre.freeserve.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13uEFb-0003ob-00 for f-cpu@egroups.com; Fri, 10 Nov 2000 13:29:51 +0000 Message-ID: <3A0BF738.F151DEC9@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 13:25:12 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GUI idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 53ec827555e4e239c003f2ab84c77023 Status: R X-Status: N Again, off topic, but taking the concept of a XML editor which has a
tree control in a left hand pane,
you could have plug ins for a right hand pane. Additionally, more plug
ins operate for double click etc.
In essence make the whole explorer thing an event-to-routine system like
emacs/word/gimp etc.
(ie you can map a keypress, mouse click etc to a script function)
perhaps using GUILE (gnu lisp like
library).

So you have XML Explorer.
Note the left hand pane should also be plug-in-enabled so that you can
view the same objects with
different parent child relationships.

eg: File browser.
The parser gets information from a XML interface to the file system.
It is given metadata about files (file sizes etc).
It expresses the parent-child relationship of files within a folder in
your regular tree control.

The right hand pane can be a customisable view which displays columns
of  whichever field passed from the
file metadata you want (creator etc). Or, as it is customisable, you
might have a set of contact files, and
display the LASTNAME element in the first column etc. (this would
involve also parsing the targets).

As everything is customisable, you could have a single file (contacts)
that drills down into the element structure
beneath it. (perhaps only to a certain level, and then double click
opens a plug-in editor for an individual
contact.

The left hand pane could be changed to show the contacts as children of
a company etc etc.

This might be well off topic, but obviously the same tool would be very
good at editing FCPU documentation
and perhaps code (see my previous DTDs).

Jeff Davies
eGroups Sponsor
From Michael Riepe Fri Nov 10 05:22:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00477 for ; Fri, 10 Nov 2000 17:45:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:45:02 +0100 (MET) Received: (qmail 28325 invoked by uid 0); 10 Nov 2000 15:23:45 -0000 Received: from mr.egroups.com (208.50.144.80) by mx11.rz2.gmx.net (mx11) with SMTP; 10 Nov 2000 15:23:45 -0000 X-eGroups-Return: sentto-1101623-1367-973869802-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mr.egroups.com with NNFMP; 10 Nov 2000 15:23:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 15:23:21 -0000 Received: (qmail 2646 invoked from network); 10 Nov 2000 15:21:41 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Nov 2000 15:21:41 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.105) by mta2 with SMTP; 10 Nov 2000 15:21:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA00500; Fri, 10 Nov 2000 05:22:51 +0100 Message-ID: <20001110052251.49009@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 05:22:51 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] IAdd EU Update Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" X-UIDL: 043cc78a3b00249215a783d53f47118d Status: R X-Status: N --Dxnq1zWXvFF0Q93v Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Second turn...

I changed the adder from carry-select to carry-increment after I figured
out how to do the SIMD thing without increasing the delay... took me
a while.  I also added limited 8-bit support -- add/addc/sub/subb now
takes 1 cycle (6 gates), but saturated mode (adds/subf) needs the whole
pipeline (2 cycles).  There is also a reasonably complex test suite now;
it doesn't check everything, but IMHO it's sufficient.  Of course, the
unit passes the test.  (BTW: Vanilla VHDL finally reached its limits --
it dies with an `opcode botch' error, whatever that means -- but Simili
still works fine).

I threw out the MUXes (not needed) and the more complex components
(there were to many special cases); according to vhdle.exe, there are
now 1268 components, and all of them are standard gates (I'll insert
the pipeline register later).

I think I'll let you play with this unit for a while and concentrate on
the multiplier again.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Description: 64-bit SIMD IAdd EU Content-Disposition: attachment; filename="iadd.vhdl" -- iadd.vhdl -- F-CPU 64-bit Add/Subtract Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: iadd.vhdl,v 1.15 2000/11/10 03:20:20 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity IAdd is generic ( WIDTH : natural := 64 -- do not change! ); port ( -- operand inputs A : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); B : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); -- subtract mode enable Sub : in std_ulogic := '0'; -- saturate/floor mode enable Sat : in std_ulogic := '0'; -- SIMD mode switches U08, U16, U32 : in std_ulogic := '0'; -- 8-bit tap outputs Y8l : out std_ulogic_vector(WIDTH-1 downto 0); Y8h : out std_ulogic_vector(WIDTH-1 downto 0); -- regular outputs Yl : out std_ulogic_vector(WIDTH-1 downto 0); Yh : out std_ulogic_vector(WIDTH-1 downto 0) ); end IAdd; -- Known limitations: -- -- 1: Not fully tested. -- -- 2: 8-bit SIMD mode works but adds/subf is slower (2 cycles) -- than add/addc/sub/subb (1 cycle). 8-bit adds/subf seems to -- be impossible with 6 gates, unless we use lookup tables. -- -- 3: There was no space (or rather, delay time) to include -- the avg and diff instructions. They will probably need an -- additional output port. Different avg/diff rounding modes -- won't work either, but `truncate' should be sufficient anyway. -- -- 4: subb mode differs from F-CPU manual. IMHO the manual -- should be changed :) See the rationale in the code below. -- -- 5: The pipeline register is missing. I planned to tear off -- the second stage after testing, make it a separate unit and -- then glue the stages and the register together. -- Operating Modes: -- -- Sub = '0', Sat = '0': add operation -- Sub = '0', Sat = '1': add operation with unsigned saturation (ceiling) -- Sub = '1', Sat = '0': sub operation -- Sub = '1', Sat = '1': sub operation with unsigned saturation (floor) -- -- carry/borrow is always available on the second output port (Yh); -- that means all operating modes from the manual are supported: -- add, addc, adds, sub, subb and subf. 8-bit add/addc/sub/subb -- has its own output ports in the first pipeline stage; 8-bit -- adds/subf uses the output port of the second stage. -- SIMD Modes: -- -- U08 = '0', U16 = '0', U32 = '0': 8-bit mode -- U08 = '1', U16 = '0', U32 = '0': 16-bit mode -- U08 = '1', U16 = '1', U32 = '0': 32-bit mode -- U08 = '1', U16 = '1', U32 = '1': 64-bit mode -- (others combinations are invalid) -- -- Note: I intend to use this encoding scheme everywhere; it seems -- to be the most appropriate one. -- Modus Operandi: -- -- The IAdd unit is a multi-level carry look-ahead/increment adder -- with SIMD capabilities. Its first level calculates 4-bit -- slices using carry look-ahead; the second and third level -- are SIMD-enabled incrementers that provide wider results. -- There is also a `tap' output that provides faster 8-bit -- results for some operations. -- -- Subtraction is implemented as `not ((not A) + B)' rather -- than the usual `A + (not B) + 1' because that makes the -- saturation modes easier -- and we don't need a carry input -- either, which simplifies the SIMD stuff in the final stages. -- Expressed as a simple equation, this unit calculates: -- -- Yl := (((A xor Sub) + B) or (Sat and Carry)) xor Sub -- Yh := 1 when Carry is set, 0 otherwise -- -- where `Carry' is the appropriate carry output from the adder; -- any other signals can be found in the entity declaration. -- Implementation: -- -- The whole unit consist of ordinary and/or gates with up -- to 4 inputs, 2-input xor gates and inverters. In timing -- calculations, all gates are assumed to have a delay of 1. -- Some basic elements may be optimized further if the target -- supports arbitrary functions of 3 or 4 inputs, e.g. the half -- adders can be combined with the input inverters. With the -- conservative assumptions above, the unit has a delay of -- 12, and it can be split in the middle (at d=6) to form two -- pipeline stages. *schwitz* :) architecture Struct_1 of IAdd is component AND2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component AND3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component AND4 is -- assume d=1 port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component XOR2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR2 is -- assume d=1 port (A, B : in std_ulogic; Y : out std_ulogic); end component; component OR3 is -- assume d=1 port (A, B, C : in std_ulogic; Y : out std_ulogic); end component; component OR4 is -- assume d=1 port (A, B, C, D : in std_ulogic; Y : out std_ulogic); end component; component NOT1 is -- assume d=1 port (A : in std_ulogic; Y : out std_ulogic); end component; -- signals used by both stages signal C2 : std_ulogic_vector(WIDTH/4-1 downto 0); signal G2 : std_ulogic_vector(WIDTH/16-1 downto 0); signal P2 : std_ulogic_vector(WIDTH/16-1 downto 0); signal Y04 : std_ulogic_vector(WIDTH-1 downto 0); signal C08 : std_ulogic_vector(WIDTH/8-1 downto 0); signal Inc04 : std_ulogic_vector(WIDTH-1 downto 0); signal Inc16 : std_ulogic_vector(WIDTH/4-1 downto 0); begin stage_1 : block -- signals used by stage 1 exclusively signal G0 : std_ulogic_vector(WIDTH-1 downto 0); signal P0 : std_ulogic_vector(WIDTH-1 downto 0); signal C1 : std_ulogic_vector(WIDTH-1 downto 0); signal G1 : std_ulogic_vector(WIDTH/4-1 downto 0); signal P1 : std_ulogic_vector(WIDTH/4-1 downto 0); signal un08 : std_ulogic; begin -- mode switch inverted -- d=1 u08n : NOT1 port map (U08, un08); -- input stage -- (half adders with A input inverted by Sub) -- d=2 input : for i in 0 to WIDTH-1 generate -- Behaviour: -- P0(i) <= (A(i) xor Sub) xor B(i); -- G0(i) <= (A(i) xor Sub) and B(i); bl : block signal t : std_ulogic; begin inv_a : XOR2 port map (A(i), Sub, t); sum : XOR2 port map (t, B(i), P0(i)); carry : AND2 port map (t, B(i), G0(i)); end block; end generate; -- 4-bit increment vector -- d=3 inc_04 : for i in 0 to WIDTH/4-1 generate -- Behaviour: -- Inc04(4*i+3) <= P0(4*i) and P0(4*i+1) and P0(4*i+2); -- Inc04(4*i+2) <= P0(4*i) and P0(4*i+1); -- Inc04(4*i+1) <= P0(4*i); -- Inc04(4*i+0) <= '1'; i_3 : AND3 port map (P0(4*i), P0(4*i+1), P0(4*i+2), Inc04(4*i+3)); i_2 : AND2 port map (P0(4*i), P0(4*i+1), Inc04(4*i+2)); i_1 : Inc04(4*i+1) <= P0(4*i); i_0 : Inc04(4*i) <= '1'; end generate; -- first-level carry look-ahead -- (like regular CLA but without carry input) -- d=4 cla1 : for i in 0 to WIDTH/4-1 generate bl : block alias Gi : std_ulogic_vector(3 downto 0) is G0(4*i+3 downto 4*i); alias Pi : std_ulogic_vector(3 downto 0) is P0(4*i+3 downto 4*i); alias Co : std_ulogic_vector(3 downto 0) is C1(4*i+3 downto 4*i); alias Go : std_ulogic is G1(i); alias Po : std_ulogic is P1(i); signal t : std_ulogic_vector(5 downto 0); begin -- Behaviour: -- Po <= Pi(0) and Pi(1) and Pi(2) and Pi(3); -- Go <= Gi(3) -- or (Pi(3) and Gi(2)) -- or (Pi(3) and Pi(2) and Gi(1)) -- or (Pi(3) and Pi(2) and Pi(1) and Gi(0)); -- Co <= ( -- 3 => Gi(2) -- or (Pi(2) and Gi(1)) -- or (Pi(2) and Pi(1) and Gi(0)), -- 2 => Gi(1) -- or (Pi(1) and Gi(0)), -- 1 => Gi(0), -- 0 => '0' -- ); prop : AND4 port map (Pi(3), Pi(2), Pi(1), Pi(0), Po); tmp0 : AND2 port map (Pi(3), Gi(2), t(0)); tmp1 : AND3 port map (Pi(3), Pi(2), Gi(1), t(1)); tmp2 : AND4 port map (Pi(3), Pi(2), Pi(1), Gi(0), t(2)); gen : OR4 port map (Gi(3), t(0), t(1), t(2), Go); co0 : Co(0) <= '0'; co1 : Co(1) <= Gi(0); tmp3 : AND2 port map (Pi(1), Gi(0), t(3)); co2 : OR2 port map (Gi(1), t(3), Co(2)); tmp4 : AND2 port map (Pi(2), Gi(1), t(4)); tmp5 : AND3 port map (Pi(2), Pi(1), Gi(0), t(5)); co3 : OR3 port map (Gi(2), t(4), t(5), Co(3)); end block; end generate; -- 4-bit partial results -- d=5 res_04 : for i in 0 to WIDTH-1 generate -- Behaviour: -- Y04(i) <= P0(i) xor C1(i); y_4 : XOR2 port map (P0(i), C1(i), Y04(i)); end generate; -- 16-bit increment vector -- d=5 inc_16 : for i in 0 to WIDTH/16-1 generate -- Behaviour: -- Inc16(4*i+3) <= (not U08 and P1(4*i+2)) -- or (P1(4*i) and P1(4*i+1) and P1(4*i+2)); -- Inc16(4*i+2) <= (not U08) -- or (P1(4*i) and P1(4*i+1)); -- Inc16(4*i+1) <= P1(4*i); -- Inc16(4*i+0) <= '1'; bl : block signal t1, t2, t3 : std_ulogic; begin tmp1 : AND3 port map (P1(4*i), P1(4*i+1), P1(4*i+2), t1); tmp2 : AND2 port map (un08, P1(4*i+2), t2); i_3 : OR2 port map (t1, t2, Inc16(4*i+3)); tmp3 : AND2 port map (P1(4*i), P1(4*i+1), t3); i_2 : OR2 port map (un08, t3, Inc16(4*i+2)); i_1 : Inc16(4*i+1) <= P1(4*i); i_0 : Inc16(4*i) <= '1'; end block; end generate; -- second-level carry look-ahead -- (regular CLA - carry input + SIMD split after 2 bits) -- d=6 cla2 : for i in 0 to WIDTH/16-1 generate bl : block alias Gi : std_ulogic_vector(3 downto 0) is G1(4*i+3 downto 4*i); alias Pi : std_ulogic_vector(3 downto 0) is P1(4*i+3 downto 4*i); alias Co : std_ulogic_vector(3 downto 0) is C2(4*i+3 downto 4*i); alias Go : std_ulogic is G2(i); alias Po : std_ulogic is P2(i); signal t : std_ulogic_vector(6 downto 0); begin -- Behaviour: -- Note: for Po and Go, U08 = '1' is assumed (16-bit mode) -- Po <= Pi(0) and Pi(1) and Pi(2) and Pi(3); -- Go <= Gi(3) -- or (Pi(3) and Gi(2)) -- or (Pi(3) and Pi(2) and Gi(1)) -- or (Pi(3) and Pi(2) and Pi(1) and Gi(0)); -- Co <= ( -- 3 => Gi(2) -- or (U08 and Pi(2) and Gi(1)) -- or (U08 and Pi(2) and Pi(1) and Gi(0)), -- 2 => (U08 and Gi(1)) -- or (U08 and Pi(1) and Gi(0)), -- 1 => Gi(0), -- 0 => '0' -- ); prop : AND4 port map (Pi(3), Pi(2), Pi(1), Pi(0), Po); tmp0 : AND2 port map (Pi(3), Gi(2), t(0)); tmp1 : AND3 port map (Pi(3), Pi(2), Gi(1), t(1)); tmp2 : AND4 port map (Pi(3), Pi(2), Pi(1), Gi(0), t(2)); gen : OR4 port map (Gi(3), t(0), t(1), t(2), Go); co0 : Co(0) <= '0'; co1 : Co(1) <= Gi(0); tmp3 : AND3 port map (U08, Pi(1), Gi(0), t(3)); tmp4 : AND2 port map (U08, Gi(1), t(4)); co2 : OR2 port map (t(3), t(4), Co(2)); tmp5 : AND3 port map (U08, Pi(2), Gi(1), t(5)); tmp6 : AND4 port map (U08, Pi(2), Pi(1), Gi(0), t(6)); co3 : OR3 port map (Gi(2), t(5), t(6), Co(3)); end block; end generate; -- 8-bit carry out (used in tap and second stage) -- d=6 carry8 : for i in 0 to WIDTH/8-1 generate bl : block signal t : std_ulogic; begin -- Behaviour: -- C08(8*i) <= G1(2*i+1) or (P1(2*i+1) and G1(2*i)); tmp : AND2 port map (P1(2*i+1), G1(2*i), t); c_08 : OR2 port map (G1(2*i+1), t, C08(i)); end block; end generate; -- 8-bit SIMD add/sub tap -- d=6 simd8 : for i in 0 to WIDTH/8-1 generate bl : block constant ii : natural := 8 * i; signal t1, t2, t3 : std_ulogic_vector(7 downto 0); signal Inc : std_ulogic_vector(7 downto 0); begin -- Behaviour: -- Inc <= (7 downto 4 => G1(2*i), others => '0'); -- Y8l(8*i+j) <= Sub -- xor P0(8*i+j) -- xor C1(8*i+j) -- xor (Inc04(8*i+j) and Inc(j)); -- Y8h(8*i) <= G1(2*i+1) or (P1(2*i+1) and G1(2*i)); -- Y8h(8*i+7 downto 8*i+1) <= (others => '0'); -- local increment vector -- d=4 Inc <= ( 7 downto 4 => G1(2*i), others => '0' ); -- sum output -- d=6 out8 : for j in 0 to 7 generate -- Note the increasing delay! tmp1 : XOR2 port map (Sub, P0(ii+j), t1(j)); tmp2 : XOR2 port map (t1(j), C1(ii+j), t2(j)); tmp3 : AND2 port map (Inc(j), Inc04(ii+j), t3(j)); y_8 : XOR2 port map (t2(j), t3(j), Y8l(ii+j)); end generate; -- carry output -- d=6 cy8_n : Y8h(ii+7 downto ii+1) <= (others => '0'); cy8_0 : Y8h(ii) <= C08(i); end block; end generate; end block stage_1; -- TODO: ADD PIPELINE REGISTER HERE !!! stage_2 : block -- signals used by stage 2 exclusively signal C3 : std_ulogic_vector(WIDTH/16-1 downto 0); signal Y16 : std_ulogic_vector(WIDTH-1 downto 0); signal Y64 : std_ulogic_vector(WIDTH-1 downto 0); signal S : std_ulogic_vector(WIDTH/8-1 downto 0) := (others => '0'); begin -- 16-bit partial results -- d=8 res_16 : for i in 0 to WIDTH-1 generate -- Behaviour: -- Y16(i) <= Y04(i) xor (Inc04(i) and C2(i/4)); bl : block signal t : std_ulogic; begin tmp : AND2 port map (Inc04(i), C2(i/4), t); y_16 : XOR2 port map (Y04(i), t, Y16(i)); end block; end generate; -- third-level carry look-ahead -- (regular CLA - gen/prop outputs - carry input + SIMD splits after every bit) -- d=8 cla3 : for i in 0 to WIDTH/64-1 generate bl : block alias Gi : std_ulogic_vector(3 downto 0) is G2(4*i+3 downto 4*i); alias Pi : std_ulogic_vector(3 downto 0) is P2(4*i+3 downto 4*i); alias Co : std_ulogic_vector(3 downto 0) is C3(4*i+3 downto 4*i); signal t : std_ulogic_vector(4 downto 0); begin -- Behaviour: -- Co <= ( -- 3 => (U16 and Gi(2)) -- or (U32 and Pi(2) and Gi(1)) -- or (U32 and Pi(2) and Pi(1) and Gi(0)), -- 2 => (U32 and Gi(1)) -- or (U32 and Pi(1) and Gi(0)), -- 1 => (U16 and Gi(0)), -- 0 => '0' -- ); co0 : Co(0) <= '0'; co1 : AND2 port map (U16, Gi(0), Co(1)); tmp0 : AND3 port map (U32, Pi(1), Gi(0), t(0)); tmp1 : AND2 port map (U32, Gi(1), t(1)); co2 : OR2 port map (t(0), t(1), Co(2)); tmp2 : AND2 port map (U16, Gi(2), t(2)); tmp3 : AND3 port map (U32, Pi(2), Gi(1), t(3)); tmp4 : AND4 port map (U32, Pi(2), Pi(1), Gi(0), t(4)); co3 : OR3 port map (t(2), t(3), t(4), Co(3)); end block; end generate; -- 64-bit result -- d=10 res_64 : for i in 0 to WIDTH-1 generate -- Behaviour: -- Y64(i) <= Y16(i) xor (Inc04(i) and Inc16(i/4) and C3(i/16)); bl : block signal t : std_ulogic; begin tmp : AND3 port map (Inc04(i), Inc16(i/4), C3(i/16), t); y_64 : XOR2 port map (Y16(i), t, Y64(i)); end block; end generate; -- saturate/carry logic -- d=10 sat_and_carry : block -- Note!!! some signals are not driven explicitly! signal C16, C32, C64 : std_ulogic_vector(WIDTH/8-1 downto 0) := (others => '0'); signal un08, un16, un32 : std_ulogic; begin -- mode switches inverted -- d=7 (due to pipelining) u08n : NOT1 port map (U08, un08); u16n : NOT1 port map (U16, un16); u32n : NOT1 port map (U32, un32); -- carry output vectors for each width -- d=8 carry16 : for i in WIDTH/16-1 downto 0 generate -- 16-bit carry out C16(2*i) <= G2(i); end generate; carry32 : for i in WIDTH/32-1 downto 0 generate -- 32-bit carry out -- C32(4*i) <= G2(2*i+1) or (P2(2*i+1) and G2(2*i)); bl : block signal t : std_ulogic; begin tmp : AND2 port map (P2(2*i+1), G2(2*i), t); co : OR2 port map (G2(2*i+1), t, C32(4*i)); end block; end generate; carry64 : for i in WIDTH/64-1 downto 0 generate -- 64-bit carry out -- C64(8*i) <= (G2(4*i+3)) -- or (P2(4*i+3) and G2(4*i+2)) -- or (P2(4*i+3) and P2(4*i+2) and G2(4*i+1)) -- or (P2(4*i+3) and P2(4*i+2) and P2(4*i+1) and G2(4*i+0)); bl : block signal t1, t2, t3 : std_ulogic; begin tmp1 : AND2 port map (P2(4*i+3), G2(4*i+2), t1); tmp2 : AND3 port map (P2(4*i+3), P2(4*i+2), G2(4*i+1), t2); tmp3 : AND4 port map (P2(4*i+3), P2(4*i+2), P2(4*i+1), G2(4*i+0), t3); co : OR4 port map (G2(4*i+3), t1, t2, t3, C64(8*i)); end block; end generate; -- saturate vector (taken from carry outputs) -- d=10 saturate : for i in WIDTH/8-1 downto 0 generate bl : block alias S08 : std_ulogic is C08(i); alias S16 : std_ulogic is C16(2*(i/2)); alias S32 : std_ulogic is C32(4*(i/4)); alias S64 : std_ulogic is C64(8*(i/8)); signal t1, t2, t3, t4 : std_ulogic; begin -- Behaviour: -- S(i) <= (Sat and S08 and not U08) -- or (Sat and S16 and U08 and not U16) -- or (Sat and S32 and U16 and not U32) -- or (Sat and S64 and U32); tmp1 : AND3 port map (Sat, S08, un08, t1); tmp2 : AND4 port map (Sat, S16, U08, un16, t2); tmp3 : AND4 port map (Sat, S32, U16, un32, t3); tmp4 : AND3 port map (Sat, S64, U32, t4); sat : OR4 port map (t1, t2, t3, t4, S(i)); end block; end generate; -- high output vector -- d=10 high_out : for i in WIDTH/8-1 downto 0 generate bl : block signal t1, t2, t3, t4, t5 : std_ulogic; begin -- Behaviour: -- Yh(8*i) <= (C08(i) and not U08) -- or (C16(i) and U08 and not U16) -- or (C32(i) and U16 and not U32) -- or (C64(i) and U32); tmp1 : AND2 port map (C08(i), un08, t1); tmp2 : AND3 port map (C16(i), U08, un16, t2); tmp3 : AND3 port map (C32(i), U16, un32, t3); tmp4 : AND2 port map (C64(i), U32, t4); tmp5 : OR4 port map (t1, t2, t3, t4, t5); -- -- Note that this differs from the F-CPU -- manual, Rev.0.2. In the manual, the -- `subb' borrow output is set to all 1's -- (numeric value -1) while this unit -- sets it to the numeric value 1. -- This is much easier to do in the -- presence of SIMD, and it's also -- more logical: `borrow -1' actually -- means `add 1', which is wrong. -- Yh(8*i+7 downto 8*i+1) <= (others => '0'); Yh(8*i) <= t5; end block; end generate; end block; -- output stage -- (saturate and invert) -- d=12 output : for i in 0 to WIDTH-1 generate -- Behaviour: -- Yl(i) <= (Y64(i) or S(i/8)) xor Sub; bl : block signal t : std_ulogic; begin tmp : OR2 port map (Y64(i), S(i/8), t); y_l : XOR2 port map (t, Sub, Yl(i)); end block; end generate; end block stage_2; end Struct_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Description: IAdd testbench Content-Disposition: attachment; filename="iatest5.vhdl" -- iatest5.vhdl - Testbench for F-CPU IAdd Unit -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: iatest5.vhdl,v 1.3 2000/11/10 03:20:20 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_textio.all; use IEEE.numeric_std.all; use std.textio.all; entity IAdd_test is end IAdd_test; architecture Arch_1 of IAdd_test is constant WIDTH : natural := 64; signal M : std_ulogic_vector(4 downto 0) := (others => '0'); signal A, B, H, L : std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); signal Yl, Y8l, Yh, Y8h : std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); procedure writestr (s : string) is variable lout : line; begin write(lout, s); writeline(output, lout); end writestr; procedure do_report (lbl : string; x, y : std_ulogic_vector) is variable lout : line; begin write(lout, string'("WHOA THERE!!!")); writeline(output, lout); write(lout, string'("A := ")); write(lout, A); writeline(output, lout); write(lout, string'("B := ")); write(lout, B); writeline(output, lout); write(lout, string'("M := ")); write(lout, M); writeline(output, lout); write(lout, string'("H := ")); write(lout, H); writeline(output, lout); write(lout, string'("L := ")); write(lout, L); writeline(output, lout); write(lout, lbl); write(lout, string'(" := ")); write(lout, x); writeline(output, lout); write(lout, lbl); write(lout, string'(" /= ")); write(lout, y); writeline(output, lout); end do_report; procedure check_numeric (lbl : string; x : std_ulogic_vector; y : natural) is variable tmp : std_ulogic_vector(x'range); variable lout : line; begin tmp := std_ulogic_vector(to_unsigned(y mod 2**x'length, x'length)); if x /= tmp then do_report(lbl, x, tmp); end if; end check_numeric; procedure check_logic (lbl : string; a, b : std_ulogic_vector) is alias x : std_ulogic_vector(a'length downto 1) is a; alias y : std_ulogic_vector(b'length downto 1) is b; variable lout : line; begin assert a'length = b'length; for i in x'range loop next when y(i) = '-'; next when x(i) = y(i); do_report(lbl, x, y); return; end loop; end check_logic; begin -- module under test mut : entity work.IAdd generic map (WIDTH => WIDTH) port map ( A => A, B => B, Sub => M(0), Sat => M(1), U08 => M(2), U16 => M(3), U32 => M(4), Y8l => Y8l, Y8h => Y8h, Yl => Yl, Yh => Yh ); -- choose correct output L <= Yl when M(2) = '1' else Y8l; H <= Yh when M(2) = '1' else Y8h; -- driver process process variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable left, right, bits, carry, simd, res : natural; variable lout : line; begin M <= "UUU00"; -- add mode writestr("*** testing add instruction ***"); for gran in 3 downto 0 loop simd := 8 * 2**gran; write(lout, string'("*** testing ")); write(lout, simd); write(lout, string'("-bit mode ***")); writeline(output, lout); -- set simd mode bits for n in 0 to 2 loop if gran > n then M(n + 2) <= '1'; else M(n + 2) <= '0'; end if; end loop; -- main test loop av := (others => 'X'); bv := (others => 'X'); for slice in 0 to WIDTH/4-1 loop -- calculate slice range and width right := 4 * slice; left := right + 4; if left mod simd = 0 then -- leftmost 4-bit slice, strip MSBit left := left - 1; end if; bits := left - right + 1; -- location of carry-out bit carry := right - right mod simd; -- carry-in on/off loop for k in 0 to 1 loop -- turn carry-in on/off if right /= 0 then if k = 0 then av(right-1) := '0'; bv(right-1) := '0'; else av(right-1) := '1'; bv(right-1) := '1'; end if; end if; -- input values loops for i in 0 to 2**bits-1 loop av(left downto right) := std_ulogic_vector(to_unsigned(i, bits)); A <= av; for j in 0 to 2**bits-1 loop bv(left downto right) := std_ulogic_vector(to_unsigned(j, bits)); B <= bv; wait for 1 ns; -- test normal output res := i + j; if right mod simd /= 0 then res := res + k; end if; check_numeric("L", L(left downto right), res); if gran = 0 then check_numeric("Y", Yl(left downto right), res); end if; -- test carry output tmp := (others => '0'); for n in 0 to WIDTH/simd-1 loop tmp(simd * n) := '-'; end loop; if left mod simd = simd - 1 then -- this is the leftmost slice if res >= 2**bits then tmp(carry) := '1'; else tmp(carry) := '0'; end if; end if; check_logic("H", H, tmp); if gran = 0 then check_logic("Y", Yh, tmp); end if; end loop; end loop; end loop; -- clear slice av(left downto right) := (others => 'X'); bv(left downto right) := (others => 'X'); if right /= 0 then av(right-1) := 'X'; bv(right-1) := 'X'; end if; end loop; -- test saturation write(lout, string'("*** testing ")); write(lout, simd); write(lout, string'("-bit saturation ***")); writeline(output, lout); M(1) <= '1'; for i in WIDTH/simd-1 downto 0 loop right := simd * i; left := right + simd - 1; av := (others => 'X'); bv := (others => 'X'); for j in left downto right loop av(j) := '0'; bv(j) := '0'; A <= av; B <= bv; wait for 1 ns; tmp := (others => 'X'); tmp(left downto j + 1) := (others => '1'); if j = right then tmp(j) := '0'; end if; check_logic("L", Yl, tmp); av(j) := '1'; bv(j) := '1'; A <= av; B <= bv; wait for 1 ns; tmp(left downto right) := (others => '1'); check_logic("L", Yl, tmp); bv(j) := '0'; end loop; end loop; M(1) <= '0'; end loop; M <= "UUU01"; -- sub mode writestr("*** testing sub instruction ***"); for gran in 3 downto 0 loop simd := 8 * 2**gran; write(lout, string'("*** testing ")); write(lout, simd); write(lout, string'("-bit mode ***")); writeline(output, lout); -- set simd mode bits for n in 0 to 2 loop if gran > n then M(n + 2) <= '1'; else M(n + 2) <= '0'; end if; end loop; -- main test loop av := (others => 'X'); bv := (others => 'X'); for slice in 0 to WIDTH/4-1 loop -- calculate slice range and width right := 4 * slice; left := right + 4; if left mod simd = 0 then -- leftmost 4-bit slice, strip MSBit left := left - 1; end if; bits := left - right + 1; -- location of carry-out bit carry := right - right mod simd; -- carry-in on/off loop for k in 0 to 1 loop -- turn carry-in on/off if right /= 0 then if k = 0 then av(right-1) := '1'; bv(right-1) := '0'; else av(right-1) := '0'; bv(right-1) := '1'; end if; end if; -- input values loops for i in 0 to 2**bits-1 loop av(left downto right) := std_ulogic_vector(to_unsigned(i, bits)); A <= av; for j in 0 to 2**bits-1 loop bv(left downto right) := std_ulogic_vector(to_unsigned(j, bits)); B <= bv; wait for 1 ns; -- test normal output res := i - j + 2**bits; if right mod simd /= 0 then res := res - k; end if; check_numeric("L", L(left downto right), res); if gran = 0 then check_numeric("Y", Yl(left downto right), res); end if; -- test carry output tmp := (others => '0'); for n in 0 to WIDTH/simd-1 loop tmp(simd * n) := '-'; end loop; if left mod simd = simd - 1 then -- this is the leftmost slice if res < 2**bits then tmp(carry) := '1'; else tmp(carry) := '0'; end if; end if; check_logic("H", H, tmp); if gran = 0 then check_logic("Y", Yh, tmp); end if; end loop; end loop; end loop; -- clear slice av(left downto right) := (others => 'X'); bv(left downto right) := (others => 'X'); if right /= 0 then av(right-1) := 'X'; bv(right-1) := 'X'; end if; end loop; -- test saturation write(lout, string'("*** testing ")); write(lout, simd); write(lout, string'("-bit saturation ***")); writeline(output, lout); M(1) <= '1'; for i in WIDTH/simd-1 downto 0 loop right := simd * i; left := right + simd - 1; av := (others => 'X'); bv := (others => 'X'); for j in left downto right loop av(j) := '1'; bv(j) := '0'; A <= av; B <= bv; wait for 1 ns; tmp := (others => 'X'); tmp(left downto j + 1) := (others => '0'); if j = right then tmp(j) := '1'; end if; check_logic("L", Yl, tmp); av(j) := '0'; bv(j) := '1'; A <= av; B <= bv; wait for 1 ns; tmp(left downto right) := (others => '0'); check_logic("L", Yl, tmp); bv(j) := '0'; end loop; end loop; M(1) <= '0'; end loop; -- stop simulation writestr("*** simulation complete ***"); wait; end process; end Arch_1; --Dxnq1zWXvFF0Q93v Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Description: updated component library Content-Disposition: attachment; filename="lib.tar.gz" H4sIADDKBToCA+2da3OiSBfH8zZ+ivNiq5JUqQG61Rmzs/UQk0zcmlzWmJ3keZNCbYVdBAsw l2+/pxHwgpdkR3E2OV3lDTmnL4f294fuRttqHRpORys+mh17ZzNJVZQy57ADAGr0Clr0Kt8q rAJQUSsVXmKVEse9NK2i7oCyk0Ea+oHhAez0rbZpiMVNgLt1uzvvLhUKkIQf8INWsJzBMAD9 8gR6RiByuK3mDl48q2cGsF87wHApClyMWgsalhgI+DVqvP/5wbBTHDpWwTQcx30UXrEjfkMX 0kvTtHwYeG7PM/qAb7ueEOC73eDJ8MQRvLhDaBsOeKJj+YFntYaBACuQpTt0Pei7Hav7Iv3g tqHTER4EpoBAeH0f3G744evlLXwVjvAMG66HLdtqwzerLRxfgIFZyy2+KTrQCv1IizNZhpuo DHDmomMjsFznCISF33uAVfDxM2hxHpHDPLiedLJvBLLkHrgDaXeAxX0BG9stMS0uqP64lh2w nNC36WJbBia6xDo+WbYNLQFDX3SHdl66wJ3he715fnXbxPjcw3e90dAvm/dHuHNguviteBQj V1Z/YFvoGevlGU7wgsWXHi5OG7VzNNGP69/qzXusBJzVm5enNzdwdtUAHa71RrNeu/2mN+D6 tnF9dXNaBLgRsljhobCkibthlLAZOyIwLNuPK36PgfWxdHYHTONRYIDbwnrEshnQxgNrdfCk E8N2nV5YTdx53JBHYHXBcYM8PHkWHi+Bmw6rNB9HNg91p13MQ7lSggvD90F/xGDWjH7Lszo9 fHuhg6Kp7HMebm/0Yk5a/1LvVMe9JP8IapGF3eBQVQ6ZCkqpqpWrCoeoG8Dp8wB+yeVsq+UZ 3gvUT09Pj3IYyPBd0Q86D7bbs9oPqlrmRcO2j3I54QQWhgm7nYZHR2534HrY3XK7u3oejqEq DxFpNwwNj3D7PW6UIR9vze0eHKGfTugEXRpe28RGaQdDDMqxkI3/oMrmjjNpiZ7l5NDTr18w 9FhBOB45iHc+yu1Qet/JHvGfbZX/JSXF/3KJ+J8d/1nCf0b8J/4T/+fyn2XCf5bmPxbw7RKA rZAAbIEECJ9rJAQ+FP/5VvlfVtPn/wrxPzv+84T/nPhP/Cf+z+U/z4T/fC7/83DydgnAV0gA vlQChM8nJATePf+7xibpv5r/Zew6Mf/LFSb5rzBG/M+I/1H4Jf3VQgvRg7yxweggY4n+RH+i P9I/6iMh+7Up9vNq6XOVf14D+8/0V5/53wz7stgeZrCQ/2f6LP1vAm/YDkb0jzJru/2B62AB 4O6qMRp5iAowd9wB0noDc9uV2SWeMNcJtxf67xqb9TuvVq917Vs9Bw+SQMXdJxslkjGB6A8e 5HdhfcIs+8YAs4Uvv0FYJ3zFAtzL10CVWXSNB3/YX2ASqJFNLbLBpo+M2mHrjyq4OKPapHEY sig+cTS2K6kk/80t85/zcor/nMb/s+K/Oct/07C7xH/iP/E/4b85wX91hv+aUuWlNfD/XH/d yP9r4H++FP7ns/BPph2sF/5r1BQR3s1lrJ7Fe4RqM0Z1WMsVNj8foTfP/77xl7bJCQCr+F9R tFn+szJd/8+K/+PwjyYAut0CkxtdT/4q0SAAyQCSAZEMGHeVuUqgVKmydVwJGJ80/+A0gNDR MiUwzmnjYuCqsZnrAHkINHywFdcDXgP/0fWA0ERbYHI8czkg0BITtsCkFpnosQmTJngoPWjS RLbLoosOsma1kU1kfL9mbRLzn2+P/4xX1An+8xH/y8T/DPnPp/nPif/Ef+L/XP7zbPi/rmkA oa9VEoBnJQH+i8ICHxwfJXyU8VHBx6dsxIb+drERm5xMiY3QhL9W0vDEpLTCJMmllJiUV6ig xKScmFTerIKCSmL8aYExj41LsXE5Nv6U6C8eGqcHfSqx8acNya6f7foP26b+U1Qlpf9KnPRf dvqP8YkFIKT/SP+R/luk/1g2+o+tUf+xVfqPZab/+BylNq9OPyTWfvorQW8QZyezF494LF7Y SLzw18mmk1gUvW85Q+nf6L/2Rm//sXL8T+Op9b+qppH+y0r/tdO3/7gY2rbwCjWSfyT/SP4l 8q+dwS1ALmo/fgcQ9LFs6U+URSSMsB3bAlsh1GMHud1o8y42q1QUsKfuHYRrgfaP40/YwHKP 0aIh3CKLI2w/sVCmLJSUhTKywD2sbiTrolLQcqNt8J9tlf9sYv4P8X8L/E/f/oP4T/wn/qf5 z7Lg/3qm/tTYcgnAFkkAzOt1KiD8VPv3mmBsTwphq/wfPm/1/p8qY8h/TVEVFbmvju7/QeM/ mfE/Dv/UBYDbO8I+YZ+wL7Efd5CQ+6WI++oh4l5lVc7Ws/wHe9zsib+SB13NYxDst8IffS2l f5TX1L0/VHgy5THkPtwp6j5mejBCOyDFBejK3K+V6Ou9uz0C83+U/9iL1K3e/0tLnf8zjdb/ ZMX/JPyS/5dXTTrnJ/gT/GP4J71joyf92O3UGfi/EfnSwzLkxzlMIh/rBjph+6Pz3/W2O/6v sPT4Pyf+Z8X/OPyTp/8IBVIBpAJIBUQqIO4jGxUB8fKYHxn5Rx/LVECUxfQ9PzF09McfH5r/ 2x3/V+bM/+M0/p8d/9Pj/8R/4j/xf5L/LAv+r2XkH90slwBsvgSQT/S/Hx+S/3y7/C/N4T+N /2fH//TffxD/if/E/0n+8yz4v65Fn+hpuQTgSySAfKK//fhA/B9gT9jq/D+1PDv/j5Xo+n9W /E/CLwXAtY40IPQT+gn9EfqT7hGyn29o9l/Y72bh//WN2JdOlnE/zmQa/JPT+r5Ozfnb+//e nG9pyt87478nels9/+esNMt/tUz//5UV/+PwS/zXbLf9N/5E/2l4ltGyReG71cGf3gb+YPgB /R8IiQISBaEoiPvMRjUB9rpQEvRkQ2ALSFXwvX7SPEcF4BhId2yc6hco81AAjJVDzf47Dw0/ mKceUlcSHh5RKLjefui4oELHfXKw4RTpcfePlNZYuHsiQrDUyzRIVKnZhYdxmadXHka6Q26P dEm8SvAPqV32XdktfXlHI7mEcLzi0LN8y+k9CIyh9HwwbXZCSwun+P+84QmAq+f/VVLz/1mF +J8R/5/nTQC8oxEAIj4Rf0z850ymAN6tYw7g3YpJgHdzZwE+0zRASpQoUaJEiRIlSpQoUXrH 6R8HfJsnAKAAAA== --Dxnq1zWXvFF0Q93v-- From whygee@club-internet.fr Fri Nov 10 16:58:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00486 for ; Fri, 10 Nov 2000 17:45:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:45:25 +0100 (MET) Received: (qmail 16733 invoked by uid 0); 10 Nov 2000 16:03:09 -0000 Received: from temp-egroups-fj.yahoo.com (HELO fj.egroups.com) (64.211.240.231) by mx0.gmx.net (mx08) with SMTP; 10 Nov 2000 16:03:09 -0000 X-eGroups-Return: sentto-1101623-1368-973872088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 10 Nov 2000 16:02:53 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 16:01:27 -0000 Received: (qmail 40878 invoked from network); 10 Nov 2000 15:59:04 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 10 Nov 2000 15:59:04 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 10 Nov 2000 17:00:09 -0000 Received: (from mnet@localhost) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA14691 for f-cpu@egroups.com; Fri, 10 Nov 2000 16:58:29 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 16:58:29 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IAdd EU Update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5c46010b4e7c044ecbce145552035055 Status: R X-Status: N Michael:
>Second turn...
>
>I changed the adder from carry-select to carry-increment after I figured
>out how to do the SIMD thing without increasing the delay... took me
>a while.
it was worth anyway :-)
>  I also added limited 8-bit support -- add/addc/sub/subb now
>takes 1 cycle (6 gates), but saturated mode (adds/subf) needs the whole
>pipeline (2 cycles).  There is also a reasonably complex test suite now;
>it doesn't check everything, but IMHO it's sufficient.  Of course, the
>unit passes the test.  (BTW: Vanilla VHDL finally reached its limits --
>it dies with an `opcode botch' error, whatever that means -- but Simili
>still works fine).
nice :-)

>I threw out the MUXes (not needed) and the more complex components
>(there were to many special cases); according to vhdle.exe, there are
>now 1268 components, and all of them are standard gates (I'll insert
>the pipeline register later).
>
>I think I'll let you play with this unit for a while and concentrate on
>the multiplier again.
>
>Ciao,
>--
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

Damnit, i #knew# it was somehow possible.
you found out #how# :-))) no worries for the saturated
version, it's a big win already.


I'll try to update the f-cpu site and the current package
this week-end. maybe even i'll work on the cache.

don't speak about it, but i have a rather incredible
working environment at Meta. it's not useful yet.
but, later...

YG
eGroups Sponsor
From whygee@club-internet.fr Fri Nov 10 16:58:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00489 for ; Fri, 10 Nov 2000 17:45:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 10 Nov 2000 17:45:26 +0100 (MET) Received: (qmail 17077 invoked by uid 0); 10 Nov 2000 16:05:23 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx02) with SMTP; 10 Nov 2000 16:05:23 -0000 X-eGroups-Return: sentto-1101623-1368-973872088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 10 Nov 2000 16:05:21 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 16:01:27 -0000 Received: (qmail 40878 invoked from network); 10 Nov 2000 15:59:04 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 10 Nov 2000 15:59:04 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 10 Nov 2000 17:00:09 -0000 Received: (from mnet@localhost) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA14691 for f-cpu@egroups.com; Fri, 10 Nov 2000 16:58:29 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 16:58:29 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IAdd EU Update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3159f3c43429fa46888c4a14b6a4e818 Status: R X-Status: N Michael:
>Second turn...
>
>I changed the adder from carry-select to carry-increment after I figured
>out how to do the SIMD thing without increasing the delay... took me
>a while.
it was worth anyway :-)
>  I also added limited 8-bit support -- add/addc/sub/subb now
>takes 1 cycle (6 gates), but saturated mode (adds/subf) needs the whole
>pipeline (2 cycles).  There is also a reasonably complex test suite now;
>it doesn't check everything, but IMHO it's sufficient.  Of course, the
>unit passes the test.  (BTW: Vanilla VHDL finally reached its limits --
>it dies with an `opcode botch' error, whatever that means -- but Simili
>still works fine).
nice :-)

>I threw out the MUXes (not needed) and the more complex components
>(there were to many special cases); according to vhdle.exe, there are
>now 1268 components, and all of them are standard gates (I'll insert
>the pipeline register later).
>
>I think I'll let you play with this unit for a while and concentrate on
>the multiplier again.
>
>Ciao,
>--
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

Damnit, i #knew# it was somehow possible.
you found out #how# :-))) no worries for the saturated
version, it's a big win already.


I'll try to update the f-cpu site and the current package
this week-end. maybe even i'll work on the cache.

don't speak about it, but i have a rather incredible
working environment at Meta. it's not useful yet.
but, later...

YG
eGroups Sponsor
From Jeff Davies Fri Nov 10 17:16:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03179 for ; Sat, 11 Nov 2000 13:41:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:41:52 +0100 (MET) Received: (qmail 15308 invoked by uid 0); 10 Nov 2000 16:42:09 -0000 Received: from temp-egroups-ef.yahoo.com (HELO ef.egroups.com) (64.211.240.229) by mx0.gmx.net (mx21) with SMTP; 10 Nov 2000 16:42:09 -0000 X-eGroups-Return: sentto-1101623-1369-973874522-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 10 Nov 2000 16:42:06 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 16:42:01 -0000 Received: (qmail 32766 invoked from network); 10 Nov 2000 16:21:35 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 10 Nov 2000 16:21:35 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 10 Nov 2000 16:21:35 -0000 Received: from modem-143.picasso-trigger.dialup.pol.co.uk ([62.136.219.143] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13uGvl-0002If-00 for f-cpu@egroups.com; Fri, 10 Nov 2000 16:21:33 +0000 Message-ID: <3A0C1F74.25903BCA@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 16:16:52 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Contact details Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d73f1a8ff8b666ee6c5b84bf2cb23859 Status: R X-Status: N Whygee, can you send me your email address, and Olivier, can you send me
your email address?

Jeff Davies
jeff@llandre.freeserve.co.uk
eGroups Sponsor
From Fri Nov 10 17:58:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03182 for ; Sat, 11 Nov 2000 13:41:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:41:53 +0100 (MET) Received: (qmail 29389 invoked by uid 0); 10 Nov 2000 17:01:28 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 10 Nov 2000 17:01:28 -0000 X-eGroups-Return: sentto-1101623-1370-973875671-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 10 Nov 2000 17:01:26 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 17:01:11 -0000 Received: (qmail 4316 invoked from network); 10 Nov 2000 16:58:17 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 10 Nov 2000 16:58:17 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 10 Nov 2000 16:58:16 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id E419032807 for ; Fri, 10 Nov 2000 11:58:26 -0500 (EST) To: f-cpu@egroups.com In-Reply-To: <3A085932.166DDAF9@jetnet.ab.ca> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 11:58:26 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d9cddaf12a6830484f237d6603d265f3 Status: R X-Status: N
Regarding the virtual memory sillyness:

Many would rant that amigaOS had no memory management.  It didn't need it.
If you have a program you generally have a purpose, so you then should
have resource managed for you.  While it allocated 64k blocks at a time,
no program ever needed finer blocks.  Almost everything you could want
would fit.  At user mode, it was stricter than Java.  Pointer arithmetic
was possible, but the hardware dealt with overlaps.  Closing an app just
flagged every 64k block.  Fastest thing around.

And when you loaded a library or program the chip put it where it was
available.  There was no screwing with virtual memory because using
supervisor mode with userspace tools was as frowned upon as IRCing as root
user is these days.

With a system that required only 5 lines of ASM code to produce a sound
there's no excuse not to be able to fix bugs provided you had source.

I'm going to workon Eddas with Downix.  I think the concept of a
microkernel style CPU especially a dumb calculator at the center of it all
is flawed.  I want something else entirely.  However, for competition's
sake I'll still be working on some ideas for F-CPU.

Rares
eGroups Sponsor
From Ben Franchuk Wed Nov 8 00:02:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03188 for ; Sat, 11 Nov 2000 13:41:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:41:55 +0100 (MET) Received: (qmail 4751 invoked by uid 0); 10 Nov 2000 18:54:29 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 10 Nov 2000 18:54:29 -0000 X-eGroups-Return: sentto-1101623-1371-973882236-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 10 Nov 2000 18:50:38 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 18:50:36 -0000 Received: (qmail 12754 invoked from network); 10 Nov 2000 18:43:55 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Nov 2000 18:43:55 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 10 Nov 2000 18:43:53 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA06499 for ; Fri, 10 Nov 2000 11:36:15 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0889EA.B9AE12DE@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 23:02:02 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 408fbae87eeb3b166981a0decf08f970 Status: R X-Status: N rares@moonbase.res.wpi.net wrote:
>
> Regarding the virtual memory sillyness:
>
> Many would rant that amigaOS had no memory management.  It didn't need it.
> If you have a program you generally have a purpose, so you then should
> have resource managed for you.  While it allocated 64k blocks at a time,
> no program ever needed finer blocks.  Almost everything you could want
> would fit.  At user mode, it was stricter than Java.  Pointer arithmetic
> was possible, but the hardware dealt with overlaps.  Closing an app just
> flagged every 64k block.  Fastest thing around.

The Amiga had a few flaws as well as some good features. As its market
was a game machine rather than business machine it never caught on. The
IBM pc was the only open machine at the time and thus it is still around
today !@%#. Since memory arrays I think were limited to 32k?64k? 64k blocks
where more than ample.It had a few flaws like no way test if a key was pressed
for "printf("hit any key to abort\n");while(!kbhit())do_big_loop();" style
programs. The low level I/O was nice.

I feel you need memory management not virtual memory.Since memory management
keeps 'holes'  out of main memory it is a good thing.

While on the topic of old machines, it comes to my mind that
nobody (In my limited knowledge of computers) has really designed a good
multi-tasking system with good memory management and I/O hardware.
Multi-tasking OS's like Unix's were designed in the era (and it still
is with linux) for slow user I/O devices and with only a few differnt
programs running in memory at once.With 50 people online 90% of the people
would be doing a low cpu intensive process like using a simple text editor.
With a 110 baud TTY having your 8k basic program swapped out now and then
would not be noticed. Personal computers developed nice interactive
i/o devices but at the cost of cpu time.Mouse presses come to mind or
speaker beeps.The flood of low quality computers pushed by marketing
people have left us with designs that never worked and closed hardware.
I AM STILL WAITING for DOS to come out with a serial com driver that uses
interupts.
This is the mess that the current computer hardware/software is in, 3 era's
of computer design all merged togther with very few good features and at lot of
the problems.

Perhaps now is a good time to consider if hardware and software ideas need
to be re-evaluated for use in the gobal computer network.

>
> And when you loaded a library or program the chip put it where it was
> available.  There was no screwing with virtual memory because using
> supervisor mode with userspace tools was as frowned upon as IRCing as root
> user is these days.
>
> With a system that required only 5 lines of ASM code to produce a sound
> there's no excuse not to be able to fix bugs provided you had source.
>
> I'm going to workon Eddas with Downix.  I think the concept of a
> microkernel style CPU especially a dumb calculator at the center of it all
> is flawed.  I want something else entirely.  However, for competition's
> sake I'll still be working on some ideas for F-CPU.
>
> Rares
>
Arg! my mouse died... Back later.Ben.
PS. why not a two cpu set? A system processer and a user processer.
A page fault in the just advances to the next task.The system processer
just cleans up the mess.
--

"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Jeff Davies Fri Nov 10 20:06:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03200 for ; Sat, 11 Nov 2000 13:41:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:41:59 +0100 (MET) Received: (qmail 25088 invoked by uid 0); 10 Nov 2000 19:17:06 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net (mx21) with SMTP; 10 Nov 2000 19:17:06 -0000 X-eGroups-Return: sentto-1101623-1372-973883570-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 10 Nov 2000 19:12:55 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 19:12:49 -0000 Received: (qmail 1436 invoked from network); 10 Nov 2000 19:11:01 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 10 Nov 2000 19:11:01 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta1 with SMTP; 10 Nov 2000 19:11:00 -0000 Received: from modem-179.banded-shark.dialup.pol.co.uk ([62.136.226.179] helo=llandre.freeserve.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13uJZT-00028D-00 for f-cpu@egroups.com; Fri, 10 Nov 2000 19:10:43 +0000 Message-ID: <3A0C4720.1AED46F9@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 19:06:09 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] A picture of xeena editing a program in fcpu program dtd for xml Content-Type: multipart/mixed; boundary="------------8A978E447725B98B0B66238D" X-UIDL: 36b7bc7aaf5ed3e8fe4d2b6dbf820679 Status: R X-Status: N --------------8A978E447725B98B0B66238D Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Apparently Csharp "is the first programming language with markup for
documentation right there in the code"

I must have been imagining the code I have often seen with HTML in it.

Anyway, why use legacy Csharp when you can program in XML!!!

(take a look).

IBM Xeena isn't perfect ... why oh why have the text box at bottom
left??

I have updated the program dtd to work with xeena (1.2?).
The multimedia doc dtd works with xmetal but not xeena (yet).

The attachment example-program-bmp.zip is the most interesting.

Jeff Davies
eGroups Sponsor
--------------8A978E447725B98B0B66238D Content-Type: application/x-zip-compressed; name="fcpu-dtds.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fcpu-dtds.zip" UEsDBBQAAAAIAPqWainlTmV0GAMAAPYLAAAQAAAAZmNwdS1wcm9ncmFtLmR0ZJ1WTY/TMBC9 I/EfzHLp7traKwfYyHWmrcGxje10t2dACAmWKwf/eCZp0sb5BuUSxW/efOaN32d/fv0k316+ /P764+X7h5sy7Ni7m+zx1Wt83r9hjOyELclB7g9EwREUsc7sHS/Ic6FIHnLC2GODPBgLu1Kp EwkH6cmTVIoEx7XfGVcQqYMhwuSApzwQwTXZArHce8gJHnEiHsT9/cNHfsRXU1ipwHXYuc4J V94QC+7ArScFF84w6wAjEuC9cTUN8hVbNM2ys3FlDgoK0IEcudO8ALJ5a0XOA78lj91jZYxF CNk0uN4xfg0ni9aYStwpw0PMTYm+ojhwF31wUu9rm64VfC4x7AsnHefWJrB1SIWpYgX1Em7v gAdwa6AtJTPuHMQ/cK+2wQynCsvzfMnal9slSC6PEqdrAVWYRV9FqYK0OMYLOMH9OaVqKig8 4yh6L43uwbaOi08QfDp1Sf0lYtyJyXxqMj2IgMxsbnpbzDRL6YGdfUnAcK5ub+9S4K7UZy5v QTAHO3CgBbDSySnu6hPDn+KJ5ZJXArHOLIAPTGpTBnbE+I3zk3Yjhlhw7NVaE8sxLMC5RYcr QBjTMsrXXF3muxlsTZl4GKBzsKBzzOXUb/YkLgcvnLRVw9bA50rUgSVjNIUim168dDwumvqn iZ9J+npKr9CmVqODOlurFkU2CZ4mXaRpn4ZBTRW5i7qKwEU8YusznvU9XqU+tsIbO4IaB2oc x+S2oomVAkVUz4jyGFHZYitd55NWeS4v+J+nWakjZi4DPlyxI1clFrErZP38chCKO0Cokxw3 XyKRlQwOy5Ya1A1NPw2CElwp9v8961LhbUDudf16ibSf3xUttXBNHwsbTsNUZk6vnhheUFh1 lRgrZTKWpsU1Fw86bAfdjBDHS6DxEtQtHZ/9pwPeowbhTIB9AMvqO1rHbWzjjFeumPRo0MGa Z0ZA6vM1slUByaYPpw0/vcQ76kDJaj9Xr02AafkrO9YszY4qV3OV9QYro11NyujMfkTo/CbM 6NLOaxCjyy2j3asAve58miz3KuBeuapqtFP4F1BLAwQUAAAACAAxg2cpUBKs9MAGAAA9GgAA FgAAAGZjcHUtbXVsdGltZWRpYWRvYy5kdGS9GMlu2zj0PkD/gcUcahvkHxQ1GIm21WorRaWT o2orEwHxMrLcNoA+fh6pjdTiTtxi1CYRyce3r3r/lhAksn2KwjzbZ0X2LT2j1z6EfHjzx/u3 zGUe8wXaBDFHlk0FNbY9x48FGzmImBX49siBTR/G8AS+2IzsPzDakZUHjWTOoUjzfbrLkuK1 wvUkA+QMzaR8uJIGV7zPDSjheAAl2cGKVwxyzAd4SAUmX7F8HeIgnPrrGkRB4/Ztbop4LpL9 6fV2U09PRMdfBYpEJKgXasQ1kmGan48H5Ceg3NMNbtMjGTIeBT4QES5DBP4NbbtyeCSIT70p AJeOnY/we8szzm9LbaYLsMQdrwvcsrXQ1Ed3uzw9n2+OuB47keCMCUJtm7MomtCP5YiHqaMg 9icPOVs7gX/tJp+6umI241RMXw8D8DGXWIE9arVGTbc+PTXp+pmZOltgqZ4lrjSxxJXQ9ZrD RifKEmtcLzWjWsdDkWyL32VUK/BC6j9cc3nmUcf9idlj7kycCHgJN4E/hX0deeRnMB+Du5Go 7SmkeDndUFImFQLpVlBLEJsJED9CM11TuDWooZwFBj0scCvOAhvSLbCZ9MxM7Pi2c+/YsbJ5 j7aWCXCrDOk3HUvL38dTrdh1frxAsj8+Nir+NU+jsdgEHISZTUtaTmh/vpgj0ydtR/w2ZCF3 LEZCHgAedjtSE2d85zrR5tfQtaZYWWFMgMsNGO4vQVYBB8DI4k4ocwVZOcy1QQDHc4RzzyJI 1ZRDf8Q4021RIyvSHwU6Fy/PKcoOj8d8nxQZVK3//vQMy7xwMxG494zfQTrzBnHb1hRmKQmu 1eQapk6o+gWsKWHewywVNUnW8V3HZ2TNabhxrAozhEnPLwDmExGBCWZeXWJJB0/f9cCp2E03 IygK9k03xQaKDrHJl4C7t2H4SO8poWHoMnHT/UCA7xEPopTedH8jPJeEdH2b5jhbgef7ENOC 8cr3ZvKNOPYcnLd4ys4oTx+hWUPFESWHY/GU5kj27miXnrd5dlIBsTtuL/v0UDTBo5OaCRp9 kkELeQicr1RLiDoRR/MJN1YgdgyGkc29Ykq+zYdAMieA5n8OWYumIwblDFDUexV7lfZGqEbs cyyVpiFt5Vti1KMywmmz2dCpkTR4lY7mi36cziDvWlCnNGU2O7KstQvF9YRqa5iKc/02Nm+P XerkHnKCu71WinpjTBCZ8i3apaeSNQKBJ5fWhobghSXkxEhuAmzlow8hYKXWJwBSTE9JqSak pq7YU34xs4MvvhtQm0CAlLK4c6/iSa5ViKjIMXKejkCLnoDcBUHtZQPpMGt8Q4oHzUgl3xKb fOKuEuKmBwDfqAv40mTeoB1UUX+NhVqXWJd5iXtCL3Ej9St5w7qJrjAaBSvxhfJmSNNM+X8z WFd4RyvrUZFftsUFJpx+3QbEgrArg5UEqGTqQAduv2HUdvw14cGXCnbW7FjMdbH8tZiXs+pv T4mvv6IDTnB95UjQu7rL6EgCExh+JEH1Z/4BaY0XTFnbFDlFukenJMu7PqpB+TmmvjBmXoA5 XPZfoaJA53w5ZNA2ny759ik5pzsEdkGq/pwk4n6H7Mk50MCU7I8XqECAaXvJ8/SwfemPKzGX fjhlQmgiuMUMlOnf6JB+P5+SE7B4SPZ9LqoryqX69961F98NFDFzBPMqp1dvHsytbvVaB8FU XvOoH6+g940545Vxpppi45pEXYF3lNUmuePUt5f1QvHRLGpOYKkT7XXuchqoEDfGxZVlcKNs XOkIa6rC7QSF+/PECHqiuAmpwzsJ6ntG3y8Nvn0+nhL5URFWRf7yug9hPdtWbZCqqzKHED8Q bLphqVomzQma5gn+Px2/gyOnqms6oySXs8Qu/ZHuMMqKd2f0NTln2+T5+QUlCFz/CXxfAaDT MZOfSREEwvm4T+FXXvTZVJRB+a4Dkw03GZARlP5I9icYX0LKHUiMj3lygCglCNq4tFkBj5K/ fy7Jc/aYpfkg+1F/Hcs8HcpRySAhIwTCDqNvaf4VpcV28CWssnuDQrttxibk8nWgp9fxc9Il 2mZrkGZpFAWWA6e2amrrXqc20cTsaV9tIKUDdGe4rilY84sBONkAo41AM7mjjakNoDaTVXAK f9l9aC7NtnDQYY3W1vLNH1PNQTnoWEpzYCh7gxzgMsaz9lyNXO3KGKPaXW000vBoA08L2Q4x 7Y45mJT1LDv1DaC88tlAUo5EqQpa2Usp5Z+hcrZhiypzl+UGIZV8aqW/Swu4jXrci8IF7Bgx A0m0FwfY9GisuwIeeDDu+Wnb4GDD16QM/wJQSwMEFAAAAAgAU4NnKWmRK8/iAQAAFQQAABkA AABleGFtcGxlLW11bHRpbWVkaWFkb2Muc2dtfVNbb9sgFH6v1P/A+k5p0odJFUJihsRsNrYA b7OUFy/3bUqq2Nmaf98DdhMnqSr58p37Od8B+klkkStziaSOyijJci6F4lhqZ0pkS+tkiu5G T5N9vZv8ng0mi+nzfrad3s+a2R27vaHvhDHqpEmx5qlkWv5AXqLkpGvNSrCqnrVPZwUVtVlh IokTrscFH0v2a7du1vUKzTfLv/Cn5NKBRtzJcWZKnCjrTiKbVs2AkqN4gp2jkDYyKncq0+zl UCPow7/Uyijo3gB2yiWSxdv/qNmiuql2DWpW69p/Nkto6MztLK3b7zbgNkd/5gdK+pZjGOvq orZ4ovQ37DI8NjyPVeS5+ulY1XEEkBZGsVXTPD8REho4kJf75XpBiTdQcpXgvCy3NosUECGw p9xeLqO3CXLtmxdfgLsYFALUMGv4xrARNgSuA6Cp0gWoHynpkCcy04INwtAeQVMhklwm5IWL MwOVlBbquxIFTzBEOB45LKTjKvFdSGOB7/YsjZSxrsVf5wugoaegCX+Dovq3ntdAz1EDxft5 lB5lsMJUWsfTvB0tyB9PObya8vFqyjZLKblhDw+UBEBTmCoOJAUARUo2/OxD/FFtQ0ivCXLZ IPmIInIkEq6lwzEc+PYOXIrv3N7bm1dQSwMEFAAAAAgAxZVqKVJT2SooAQAArwIAABMAAABl eGFtcGxlLXByb2dyYW0ueG1sfVJNb4MwDL33V2TcU6+3qUqpMjBVpPKhJGzrcQK6MjGYSjvt 5w8KLR9Fu9nv+Tn2c9j69ysjP8mxTIt8ZSzmjwZJ8qiI0/xjZYTaoU/G2pyxB9u39C5AYvk2 UoWWFr5H1E5pdImxT7NkCZAV0Xt2KMoTOEs4l0f4jBewj77Phyyax6fYqBr19eaMEGZzzamz 9V+pLfhGcpdKdFCiZyENpYBLUSugHndxiAi7yUOFdCueJZcCVQPZqCwpgrqs1WgMqiKl66zN m/BKjiUd077TAfUiV6TCuFJi47no6Q6s4Bcu65lNBteoz+JbILESNlb0CCf0bg5NEp0TAzrg lYGoUSoq7sR9vqYZDNJxL/inGYOpCRlMLcTg3hsGIw8b4HIl6J2JwfC//AFQSwECFAAUAAAA CAD6lmop5U5ldBgDAAD2CwAAEAAAAAAAAAABACAAtoEAAAAAZmNwdS1wcm9ncmFtLmR0ZFBL AQIUABQAAAAIADGDZylQEqz0wAYAAD0aAAAWAAAAAAAAAAEAIAC2gUYDAABmY3B1LW11bHRp bWVkaWFkb2MuZHRkUEsBAhQAFAAAAAgAU4NnKWmRK8/iAQAAFQQAABkAAAAAAAAAAQAgALaB OgoAAGV4YW1wbGUtbXVsdGltZWRpYWRvYy5zZ21QSwECFAAUAAAACADFlWopUlPZKigBAACv AgAAEwAAAAAAAAABACAAtoFTDAAAZXhhbXBsZS1wcm9ncmFtLnhtbFBLBQYAAAAABAAEAAoB AACsDQAAAAA= --------------8A978E447725B98B0B66238D Content-Type: application/x-zip-compressed; name="example-program-bmp.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="example-program-bmp.zip" UEsDBBQAAAAIAN2WaikafBqYrDYAAHYABgAZAAAAZXhhbXBsZS14ZWVuYS1wcm9ncmFtLmJt cO2dz4sky53Yw0js5PJExQpffFvzTgurg+Dtxehi7IKdi+n/ZOiD2e5bJ+ZB5cOCEfiwGnSw zz49fFoxBwmhgw4P9C/0QQid3gubhm7Yx4Qzvj8iIn9nZWV1VWR8PzNTlZkRmdXTn/xGREZG Rv2n//JP6q+U45/qf3/nFn5Y//uBUv8GFhx/pX6/U/CvSQl/VVnim/vjNtUvv/3tb+stFv4q a/HN/XGb3LogCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIg CIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCILQS/ubZIVsAP+HOyFP bsH/+0rIE/GfN+I/b8R/3oj/vBH/eSP+8yb4L+0r8/qfKDR4Ef9Z0/JfjJUT62OjT5z4QYWz cA3+XRd0UU33UwqrcxX+8VMf3o+dp8I5eL6O8r+sw796kBrg1bkS//DBD/cTP6ywOlcV/+L/ 1bkO/1T/i/9X5zr8Y/tf/L8+V1P/VxL/l0D8583VtP+U+L8EV+K/KCup/y+B+M8b8Z83V1P/ l1L/XwJp/+eN+M+bayn/Cyn/L4K0//JG/OeN+M+ba6n/K+n/vQjS/s8b8Z831379p7ubENOT h+Yx8bRWhzCDH7J9rr39F2keTNC9i521YcQ/LF+Bf2dVa2uUtvVfbeoNbtm91xvcmzK1Lpdk 3Jty6rTC5DqQtVugHHWCUUprOKL161BKKL+LO5M0ngIa98WPVPBRRuFn+500/FW4r8IfzyR8 Al2hf/JrDb1Y9A/L9RZF6ZrSXTGvKdngKRL8W4sJcFTMbXC75mNCdmspBxwLPj4sGd4JPjFs 1X45Xa7s+g9+leg8+gWzM/DP8Y82HFxQNBZm+McchsPX8EkUHb7j39JfrIDE/6m02v+Rf6Vb /qnM5vgHQUoZ1fLvc5B/V/qjf23JFKz2+Yd96eMb8W8b/hVWT1D+i/+TaPtXIfBty7/bzqk+ QH224D+Of4VVPFb7ta5G/Y/+NfuHXTjqwxJ+hlI2jn/68cT/qQyW/+63jSFoYv+42SVo75/W IKsJORrxb/x6+AdbuHrwpxF+ZFT+a8M7GH++aH+6if+T6Gv/YwC68h98aycJNoBa7dr7dTQ2 2/+G2/8hh/dt2v61CeV/I6r5okPDp1H73+hQ/7fb/+7yQvyfQF/7n+LRgQHsZPb9kkO+fib8 s1DL7Tn6tMYLYgY+zPiXRLka/yXV/xC3/sczUCB4Ny2m/Cu+/u+v//n63zT940fyEh9qoC/R bRb/ywnPf8j930sg93/yRvznzRU9/1eI/9fnWtp/9V/xfwGuy//7iZ9WWJur6f8r6/L/biq3 sDYd/1PX1GuD/t0EMNXD9GyFwsoc2v7fTO+zIg+N9v/4mSKcgU78vzEDXxF2Fhr+p08XYXW6 /qvXo3T+J08S4Zxc3P90NuGMiP+8Ef95c3H/7Sap8Kpc3H8x3UYRzoa+vP/nyYsU4Wxcgf+X 6YzCmThcg3+573cxrsK/3Pe5FOI/b95fh3+5738ZXq7E/2G6nSqcgavxP3aSTvNM/2p+/s03 39zAEjwZZOgdnyGg50D8Iz/wYFGG8C3eNxv0X1U/D/6NbvqPHuTDBzzz9P9C4b8Z//UJ/VxT L/78Lft3j/o4zfV5zs/+4AnBj3xl7B97XA5bjP/9Sxz/WP5r/+yfpn/kP+lHN5ezaf9vY/9W N/1Hz36C/8lHCDfJpv3vyT+399g5hjwvw6sR/9vw7xozuBja/0bRHBBc90fP/lpcMtOPEG8S 57/ckH9rH3jBHfVmJKNg0b8qtuRfOIbaf6nUJuNfmEHtv74iLiT+M2Vr7T+J/+PYnn/hGCT+ 80biP29e8O15y/Fv6EHmmd8BkRU84HbT8X9HN7mnc2YH+z9suf6//cvu23fv3on/Ltvz38Pu U/mpJs87vONkEf/6u0cp//vJJP4h/E3a8/OehUzi3/FoxX+HTOLfqB1U/+K/RS7xryT+e9ly /D8/00jguv5XnyT++9hy/Pslif9Bcmn/S/z3k1n8Cy0k/vMmg/jXWj/W8a8l/nvIIP7V4849 5bqT2O8hg/jf7UL/n9Aig/jf7aj/fzprfmQQ/+rxPZDl811T5FD/M9NZ8yOL639hkCyu/4VB srj/Jwwi8Z83Ev95I/GfNxL/ebM1/9H8PwGDU78ZS3N+4jxg9bp0CmzOv/Xzf+1raP43zdN9 OfcKVup3k+eUTw027D+a/1e7ab80zf2q3Txg2tTIcIBN+w/z/xqc9I/9W5zvOdc5P2M2579v /l9f8rv5/7A2IP9S/9Ovf4vxH83/q/38r4aagBL/wKb9v4380wy/Gmt9De/if9v+996/8RcB ofmf7Zy/MRu+/o+//wMaADj3L6+46X/xmwFyZsP9f+6oMv/vBNL/nzfS/583Ev95I/GfNxL/ eSPxnzcS/3kj/vNG/OeN+M8b8Z834j9vtuG/b9Sv5q/2hEE/1ig/CgTH/dLt4MzZiH/bHfVr LH/BM3/FL9z89+N+3Yr435x/f9cfBvn6sZ9wzx+GfPG4XxoImDnb8x9G/VKYs3/3osO4P/Hv 2Ij/vlG/UMy78b0K1BsV+Q8DgTNne/HvR/1ifY+nAI70NPG4XxoInDkb9M+jfnHELz/xx2N/ /bhfGgg8dMhM2KD/fY9/g419BQs07leJ/w1e/4dRv3zVD/+gGwBOBT/ut14xMv6Xfv2p9/89 8II7loz6nY30/+bN5uJfOAqJ/7yR+M8bif+8kfjPG4n/vBH/eSP+80b85434zxvxnzcp+++d 6xdv89EIX7/F3QNUiqYBFQJJ+7f9o35hrIfle/u0BcYByIRvbTbiP4z6DRN80eAuDUN9rPGn hhCxFf9+1G/Tf13ua1zyk8AKMUn77xv168b3GJzqDyv7pn+p/5tsJf79qF832jeK/7Z/sd9k M/7DXL/cBCD/rF3897EZ/825fvkCwDnnMcAWBwILMRu5/g+jft1jPu7iX9EVfxgDzB0AwwfM kLT7/x54wR1BRv0uQPp/82bc/93rcXtS/AsLGfd/P+2ty+3LdJ4ui/wLpzLhv1rA7Ut1PAeJ /4uQtn/hVCT+80biP2+O9V/Wf8tClfVCoapKqar+UzSy9Pl3uxVFvVedt5UdWSv+zRtsTkov zzwW+a+cyVo8vMFLzID/oqxzFt3syGrxf6eQ6ZyCXVD+g0EU7/036fNfFLRjNzuyWv1/+5fd t+/evRP/8zjav1Id/3UlEDPgv1Tkv5UdWS3+d5/KTzVyn2ceq8T/ZPmPWdYv/x+6m/R3j1L+ z+do/yU6L46q//3pcv76f/cJwj++8Y/DP3hUiBCzxH8dXWUJ7f/aZTmn/e+clwpPgvO2/+v4 dzxaGvvjtcPAD/HfZmH8u6UCNxTtHD3+C8zW3/QDVox/o3ZQ/Xf9y+C/Dkf7r0WC//Ia/D90 N9Xxrzj+6Qzw/mX4f4fj/U9ykf6/52caCVzX/wqb/waHAKng34j/Nmn7f+guxfHfbP+J/x62 Ev+eKP5j//AYiJWrwja5xL8R/72cwX+5xH91hvjn+l/hbL9Wrv+6jPsfH7K1KuvEv9b6sY5/ /dibXegw7l+9IqvEv3rcuR96J4E+k1H/E/uuyyrxv9uF/j9hBqP+p0vtFVkl/nc76v+fzio4 xvwX1auyRvyrx/eA9PPOJG3/HXxrYjqr4NhY/AtHsrH4F45kK/EvLEPiP28k/vNG4j9vJP7z JmX/z67bsL2xM/+vlmF/I8z1r+p1eNiv3uoe4OAF91rhUyEFZMHkCp4NVKre6LaFNQXPgbhs dLzKPw5yvH87Z/5fGAMqJ8AAE/7d7/Ut+Xey3WDvskCPBf1RkFWBf/jnXjGz29BYK+F5UTyz cCMknOx/ZP5f+ZrvMSb8u99r278K8pzKUpUQ8OwfVopB/z5bsar/4fl/Da8KPUz5r/82/Jcd /1h+14U71QGoE+I88k9ryvv351O13P+s+X/F/xhT/t+yf4rXsmz7L0L9r6iuhw0KnhPC84LX 6sy+mYCHUKf4t3Pm/xX/Y0z537fiX7X9g3A3rQO3ATj++8p/VXTif6Xyf2z+X/E/zKT/t03/ Rcc/FuyhDTjqvzqb/8H5fy09BCb0wUP83gz533f8N9v/7F+x/7H2P1b3q7X/w/X/2Py/0gEw wsszjr4a8u/b/1T/g2qqzFvX//SPrv/7638nna//T67/Zf7f03nBCuAw4N/xtnodpP//Aszw /1pI//8FSNu/cCoS/3kj8Z83Ev95M+ZfvS5a4v/1GfM/FKhn4v0a8S/z/x5H2v57kPl/j2Jr 8S/z/x7HmP+JXVdnlfiX+X+PYsz/a980WSX+Zf7foxjzn+Dz//H8v3gjWFscBOTGASgYHgKT AbkvBIWvA8Xvh3VJllZpH2Mtf3Go3u73Bo/6v/r5Xx66m6L5P9A/j//QuALrmhO0/1poHXJg Ev7RGx86OurfTkftaqw//6/37xf9eCDNa7zJsn9/TliNr1n7r16P9ef/Zf84A6yB6Z8b/nGE iK8aLK3SPhpfs/b/fmLv9XhZf/7fRvmPUwA2/FN4U/lv2+W/1lL+H6bL7ZVY5v+hu9SMfxXq fxIL625zt/5XuIr74F+Xr/OpW2LC/1otwKJb4AMlpb85Nf49rfjH9r71hTy1/7Vr5mP7X4X2 v4ZVDUlwmmi4HNgyE/75q5yL57HgnWbIf0XpC/0/dJfa9T9CjbyYKCmmnS3v8p+Ti5chgbM4 FEMp/uPXj/+6WPHBa7pDgAdODWNbysX/9fp/aC/J/L9HMsd/cVb/7jbTavEv8/8eyQz/5Zn9 FyvGv8z/eyQz/Ksz+1crxr/M/3sk0/7Ls/sv1ot/mf/3SDYW/77DYTqr4NhY/S8cycba/8KR bOX6X1jG5vr/hKOQ+M+bKf+Y67kYOcQMngf9U7rE/4WY8k+aigF9cykm0iX+L8S8+D87z0v8 P7s7x+2Nnfl/Fdzmh7FeFobz4oBe6CHUlDe+VZwXU/5faQTYMv923vy/BoZ6UYrp+De4Lv57 /D8n4n90/l/LQ39xyJ/xmzCjxmGAed4y2Ir/sfl/LT++wWPBO/6N+E/R/8z5f+u/sKSwRKCx wAqrffG/ifgfm/+X4l9RjUAbsBng/Wvxn7T/kfl/yX9o+3n/sA3Xtz7Qf4DN+B+b/9f4dxWk cyNA4/ki/tPzH67/x+b/pQ4AfJTXdQIoGvKvDPYS4ANi4j81/zL/7+mk7V84lY3Ev7AQif+8 kfjPG4n/vJH4zxuJ/7wR/3kj/vNG/OeN+M8b8Z836fmfN+pXmEeC/q2/6z8y6leYR9L+R0b9 CvNI2//AqF9hNgn6nzXqV5hH2vE/MOpXmE3i/vtH/QqzSdx//6hfYTZJX/+PjfoVZpFi/98D L7ifnNv/wiKk/zdvko5/4WQk/vNG4j9vJP7zRuI/byT+80b85434zxvxnzfiP2/Ef96k4n/u XL/K+M3CDJLxb/1d/9G5fqOJvYQZJOh/fK5fns+t/zBCixT9j871S6WB+J9HMv7nzvULDQIZ BTiXFON/dK5fN5+jFf9zSdL/2Fy/VvvBoMI0Sfofm+vXGvF/BAle/4+N+sULQNgsJ8Ac0un/ e+AF9/Ny+184Een/zZsE419YEYn/vJH4zxuJ/7yR+M8bif+8STn+zZs7QHUzCzNJOv7vFDKd Uxgg6fr/9i+7b9+9eyf+l5N0/O8+lZ9qeu/1Sqkwi6TjX3/3OFL+yw2gGSQe/xD+Bm/6aqON +0rvetV9wafWVrkvfIUbgQaGBLtvAIXv/jYwRERxjnpv97WgBrYruoeIwwpoPzio4gNYPkp8 uDRJPP4dj5b94wv+cWdD7Vbzd//SH4NZcdQA51D8Rhn4cK39TJRuOodLk8Tj36gdVP/ev/X+ SQ40DlgpS7Xev/EO6USh/MG/iQ6rfXr3cGmSevyrRvwrFeLfwhc7u5EgDf/wrAgU2JwDXzSW 75byN/z7w2p/vO7h0iTF+H9+ppHAdf2vPjXjv+Gfo7sR/5RkfQ4b5Ua13fifKv+TJcX490tx /Cv2DxW/sf7N+1e8DcO9kUM1qwE6EvjHv9SaiPy3D5cmqbf/Q/y7lr4rv40rsKn97zbQcwF1 Do3b3AK0/6McGhv+3P6nI1m3AUp5t6KoUuH2f+twabKZ+OeXFprfdLwaJ4aXQN+R+rYmXPAT m4l/O+qfI3Smf9sb0OL/bCyJf631Yx3/+rE3uzCLhONfPe7c6P9df2EtzCLh+N/tQv+fsJCE 43+3o/7/6azCEAnHv3p8D6TfCLsgKdf/zHRWYYikr/+Fk5Hxv3kj4//zRuI/byT+80biP28k /vMmFf998//CUCxFw3Jh+JYfysODPnB4bt8BBSAZ//TPNuf/xYmfNQzIgRFbTf8a1qWDaJgE /Yf5v8g7aSb3uMmt4/ngBv70H1NI07+f/5ccW1RvbY9/GBUo/gdJxn/f/L/gGMZj0/guaAzg XMDifxYpxr+f/5cd40hdv4GaAezfbGCY1tlI0v/btv/Q9osGaFsqBIxcAAyTpH+e/5cdg38d pNOigQWrxP8wCV7/x/P/QgcAPLoF1/oGv/qn3qTwmS2l8epAGCDB/j/3894M5RKOQ/r/80b6 //NG4j9vJP7zRuI/byT+80biP28k/vNG4j9vJP7zRuI/byT+8ybp+OfbfvgMcP2KY3/crd94 OADfIRS6JBj/8fhfzWM/rcWBAJH7aDgIZhW6JBj//v6/94z3990rnw+ahwJGI0TGjpktCca/ H/9rLMW2gWqg6d/QH9s/9Z+ApOPfz/rrx/+if0PDfij+FbcHuOanrwaX+r+XFOOfx/+Cf4Ol u22W/zbM1IvxL/r7SbH+b4//1b3+TcO/DALsJ8n437f8hxo+qvUNvtrwiJjQJeX2P8Y5jwFm /zwM2K267dAMwJHAQgcZ/5s30v+fN0v969CtanAdHsXkRzH4UUwqdznVZVXwlTl+3cCXKUj/ /4U4yv+T63rFRWxPGd+w4m44ao75SRi0b31Rqm+N0zr20kn8X4ij/L/ULa/f4+KYf4OXXbP8 49O5WuL/Qhzn/w9V1fBPC/gtOX5L7L9+iVKDf16np7Ml/i/EHP/P3PX68vvYf6P+x2mYcEvs H+t/TuWbtX4dpmewcv//YhwX/7+/qdrlf9z+o5Vm+d9O1fG6sRL/F2VW/PvMv993/Pv6vzsV Q0ie8r+s/jdv7gDp21/OkfG/f7uuf+6gXRb/d/IFAKdyXPxz+9997xLX9gpvr/bU/4pq/Lj+ V63632VefP1/+5fdt+/evRP/yzku/uutX/Ye5lSWxf/uUylfAHQaR8X/+VgW//q7Ryn/TyPp /n/6/i9oSdAdP6OwdQFfzGvk1Jgi8fj33/+Hc73he3zXXxgn8fg3asff/2uiET/sX1oGU6Qe /+H7v01jxJfxl6XCGCnGvx8J3Pj+b/AO737ov/ifJMX490ut+Neh64ke+5EKYIrU2/998S/+ 57OR+I/c6+DfiP8pNhL/7rofhdPQM4v9zlL/T5Bw/GutH+v414+92YVZJBz/6nHn7kPtpIw/ gaXx3xn/a/hWnu+KxQ1cFrtc8DSGNT2Dgt8siP/dLur/E5ax2vhfw0N5fVcsJVMzjJpjlG7o EHSQOf477HbU/z+dVRhi2f3/Xv+Gr7zYu/viJQ502saP6y3w/9BeUo/vAWnjncBq4387/t0N OO/fBv+wX3tQ8JL4V8x0VmGItcb/+qG8Ufw71/S0T/APj2R2BgUviX9hBVYb/+uHcjb9d+Of NvrVxfEvrMBq43/H/cf1v/H1/1H+H4YShBNYbfyvH8ob/DvBfB7gX3+DdoF/4RysNf43XP8b aN0pGofF1/+QS1GroTsoWOL/QiQ9/lc4maTH/wgnk0r/f/T9nwF+5sRwxzIscdNERv/OIJX4 j77/tzH/LzY+o2ana10qS41OOQGmSCb+rfcfz/8LHYx4MeEboQavOqIZCYRBEox/P/+vjfyH y0nXDamVsuE2lDBMMvFf1+bt+X+hfKcbyC3/1or/WaQY/zz/r+VnvmAl+OdeR/E/TYr1fzT/ b7uDWVvqiRb/80gy/veRf6dakX/qWVZ8ASj+J0nw+j/M/+vn+qVuaBpZJh0A80mw/8/9vNz+ F04k6fH/wsksjH//rWs0tFeHiRegIsZ/Gsf/zED6/y/EwvG/3PIO/a408QL6V97/zAaYxP+F WDj+t3PlRa1vDf4NPotpzJr+H4YShBNYOv43+LdN/wpHArvW+Lr+hXOwcPwv1/8t/wbrfx3i X+r/62bh+F8d/Yv84+0Yg1WAxH8CLBz/O1D/N/27G/HnrP9l/t/TWTj+t7/9j5eAOBJ4df89 yPy/J7Ow/R9f/7ue1/b1v++QP2v9L/P/nkzS438vNP/vlgqcpMf/Xmz+35m1WgIk3f/fmv/X VT90O1BxXYT3A/k5VUjAlgvdKIQ5CyAVn0/hI9Gqpm4Now3NbuBuOdbVnTLuL29Ml8TjvzH/ Lw0H4IfODb/GL9Z3UnCrtbVkuSsbVr1/3gAbjbuxEW1MmMTjvzH/rx8GPu5fa01lRTgTSGU4 Eq3G/q33T+dGLv6vOf5b83/G/rGSJusD/nHQCEumWoL9Yy1Clikn+bdK4n9Njor/ofl/4YFS XsBmYV/934z/2D8uhfgfKv9ps8T/aiyZ/68n/q2O4p/+0rTgviQI/jX8NbxP5F/hZrdgo6qe Nvo3y7unS+rt/+b8vz3+uWb35b+CQQrk3zXgjQ95GsxSr2ho48MJUq/VpQnlNL79X28w0P43 euKnvGo2Ev9YYlsyPcN/XGxTAh+UVniT8S8tkvbObCT+rf/Keb7+9/U/Fug4QDh0DMRTAzfH CRtamfafdMFPJBz/Mv/vCiQc/zL/7wosjH9qKIV/mm71aeu/1xNn+WlNCTzAkviX+X9XYPH4 X/avvX+NCS4cqRWGi9wkO9F/B5n/dwUWj/+1vl3t3v1Qr45/apSbk/0/tJdk/t8VWDj+F1rQ 1HfaGOobBb2lWX5X8t9BMdNZhSEWjv9VCuOe3/1QX81T+mkbzfJ/lvgXVmDx+F/jv26xMdTX l/+0fsb4F1bghPG/sX8/1LPh/0z1v7AeJ4z/necfb5lJ/F8pC9v/iodP+fkWoP7neYGj+r85 JfAQEv8XIunxv8LJJD3+RziZVPr/F8z/y12Thq5ThR5Sif9o/q/Z8//CqeDeN3Gn9jwkE//W +587/y91ScF4L4n+ARKM/7nz/+JzyG4slxH/QyQT/8fP/0t3JzWN8+4/bu6kGP8z5//VkX+x P0CK9f/M+X+p+aePmIYgP5KM/3nz//rmP20Qekjw+n/2/L9ULri/MhXwAAn2/7mfl9v/wokk Pf5fOJmzj/+lm/8TSP//hTj7+F9t7IyvYZP4vxDnH/8LA0SmkPi/EOcf/7uWf+EcnH/8r7Ez br9J/F+I84//pe64cST+L8T5x/+u5f+hs0Xm/z2ds4//1UafLf5l/t+TOfv433Ne/8v8vyeT 9Pjf8fl/df9mISbp8b/j8/+K/xkk3f8fzf+L3U2G+6Pg7i/eGNQ4TBhqK7pDiB3UcLVqWzMG 00SBxmdxmzmrtjxFGD/VAjOApTy6KPH4b8z/6/1bvB9hNbdQ3VY6MTT3SOnWPmEFX3i7Dlkp Bx3TH2NG++ZqSTz+/fy/0AGhNfZEgSoyzf6t8f7p/IiF9vinLMbnMP6weF4E/zbdqib1+Of5 Pyf8Q1+196+0969j/6CRLle7/nXHvy860i0AUoz/vvl/J+Nfxy+W5KrOjMGh/g+nSJSVvVPD geN/2/6vLf79Uoh/iGqLzT5LhXeo/xWpN/wSyv+wwCuW4rvlH1Mb/rlYsAlXAKm3/yn+W/6V xvY/+A9f1AHfTqob5X/XP/kNp0j2/hOI/xat8hhXOb41bqKyG5T3+o/dY9bYfdQs4JMgRTYS /22aXULBP31FITQKVN+MwdQPgE8UG2odcFbL3wkE79TJ7Q6Wbg90wvEv8/+uQMLxL/P/rsDy 8b++V5S7SU3oFaULKEvFJnSPGr6K0jaMEeZ+1yXxL/P/rsDy8b/UKjK+cWToj+XTgRpVuNHG 7azWupnjv4PM/7sCy8f/cvMXA5mFa2Ppfkzwrzn/kH+9KP5l/t8VWD7+N/Zvm/6xURz7tzRW uOHfr8/y30Ex01mFIRaP/yX/xnb8a67/ldJcwVus8+k6K4wRhmSzrP4XVmDx+F/yrzv+sbbX YRP7j4oE01jXs/wL5+AF356PHv/b8G96/JvYvz7d/8NQgnACGP5VdfT4X/SnsBGnUTj80R3/ vv3f798dQ+L/QrD/w9Hjf9kfXP/DwN/29T9X8Py96r7+1836f57/h6EE4QTm+G9klvl/N8VR 8X8+JP4vxFHxfz4m/ffN/2v4KtREbUy6p6dpI97eozYq5cd/JjRiejulDVdieIdPhwbLlkgl /qP5v+L5fxW1O8k2tjypMcrzAOPwHzpNSCI8szZ6UcKTiqFw/yk5+n8FjvEf5v/StvHUuQ3X JcE/qfMD/N0fWNE4SyhGenTm8Dp2bPreDdrV2G2RYPyH+X+1tb5buZZDxTjJhAGhPJzD+vKe iwI3VFRxyTDs32I1kLX/V2Daf9/8v2iFi36nj6twcM4RzsO64OkeRe0BmBY2jAAyeGEa1r1/ pfiTlNreRJIpxr+f/7frP45/LsEj/9E+5J9So/indWN9/Pu9LFcH2yHF+j+a/9dqbM67leCf TJnYf3iOA/fRmqePHvJvIuF+V4n/s3Ccf57/13T8s3BLXdGaMlGL3xq/T7g86B+VAM918gr6 92kbIsHr/3j+XwxhpRS1zAxfymtvCzsArN9M+8C0wJSKFb/mdoDFB3sMPg0EFxbon460JRLs /3M/7s1QLuE4Uol/4TwsjH9Fzz9AlRn6TXVYwXuB3Bk7hfT/X4ij4j8e/+tv6vM/FW/ER+/4 mmy60SzxfyGOiv/G+F/d9G9MtNGvrOj/YShBOIGj4r8x/nfav+XbJRL/V8us+O+O/wXV4ZJJ Gwp2Ha9I/X/9HBf/8fhfjv9udxmv+Pp/Gon/C3Fc/R+P/532f+76X+b/PZ0j478x/6+N/GtQ Thup+/Xs7X+Z//dkFrb//aW+r//tBa7/Zf7fkzku/qvNzP87p1GSAwn2/wdOmP9X/CNJ9/8f Of+vtjTgS1Ei3gWEO4Y8vrdRh9G3ieJu7al/3T8aQeBnwnAHNkm1RxKP/+Pm/6Ul90aJmpJM 2Dk0bC3dRHYvtJ0OR81eHBJE5xwn2KSKlsTj/7j5f8m/5dOAXHHXFQvt889H1FFWPDZ9RvBv xn7kayP1+D9q/l/2r7CS4LEilv0bG/kHjaZ5ijSn/m3556LDplQApBj/i+f/9Us+Ectv8o/D fmx4OjWq/8MpErKyd3jHwcGb9H9t8e+Xjp7/1/qtjfrfl/9+gWPaUny3/VN1Evn3xUJaFUDq 7f8j5v81CvRhw7/R/h/2z351EJyf/wTiv0XLAK7q4XJZU9sNlff5j903axV8D/7N5vy/AqfG f5vmJTj5N4MnQJjPN+rYhvrfYN1OWXScFUsVi+82THQxo7v7ekg4/mX+3xVIOP5l/t8VWBj/ fKlEFR/8xfLTr2JR6stHjRWwxpaU4Usm2m9J/Mv8vytwVPw3x/92/Ftq/JB/qCGj9hHu4f1r ygT7LYl/mf93BY6K//b4X0OSrfcI2w1PAewvry03rA3Nu7DA/0N7Seb/XYGj4r81/hebxcZ9 5XPHv+GJF/hemsas4L87GfCi+p+ZzioMMSv+B8b/xvFPUyMMxL9Rvn+U4h+vtfxkwMuu/4WT OS7+G+N/sT1nex68jydeoP5Tv4cv/82p8S+sgKEy9M3M8Z8z/Ose/8bvofCx6+P9P8ArNEFf lZuhH2gTvOAQ6ru5/qPxv33+qVeUrgqgxUdNvZP9I+J/XY6b/70x/tfJ9VMi0bPA2EmKbTvs IwXD3D9qqOSI6399VP0v/tflOP/Vxcf/iv91Sef73x7gVfyvSyr+ef6f2P8N2Hly70+uXxLe cAk3Qap7ty4RZo69cX/d6hOYfYrWbzC/xXx43Jv90+b919Vwcf3+6V/bv7NU/6GT4Ak31NLc JlzB9z2dEuh0z8vxug35+bhZ+C+VSiD+rffv5v/akyT8+3Rzgz7ZJm7yFulMobeneFO0/vQE 227CoSFt++W/KtLyX1U/7/UfotmF7Y0rwpv+91DOj/vfYzWQk/8yhfrf4Py/zv9b9m/ZU69/ 2PCEtTxW+LiPdZvgn6XqHta9f6j/4biQlnf7r5rYfyWOiv/923b8P3X9g8wbLPRvONhpn2b8 0/rN3sc/HxrS8vZ/X70Kh6X+0fjTHhvy+9Bse6LUJ/Z/450P+b/xK+FMyt3/3StxlP89+b+h vzfOP18HPuFp4P3vqVF/4+v9JxbfWHdVgOUVOi5VAhtmwv/E3qtxzPV/aP/XoRk83UA1b8EY acVrfqzlIQPu4zdxOwDW4fTgFfKPq1tm4vs/J6J2PY7o/3Pn6/712Hj5TxVwv/9qhEMxlno0 cv//ojwf719PHPI4DPufLiuEM3Dp+K/I/ytdcAhtrsS/cCHuxX/eXIX/6fa4cCau3P/N02CS 7cl00x4qctNYGz5Ytlzcv1K1//+I45F7fr5geTgl+H9q52+uDh9s2/AzMz0LV+Iffsg9GLKu a9fdpqPOWev6cN3YDvt04/5YC29P+Abddi47jgB6snjzD7O4fuEnzua2Tf2iNsoz1vW3PQsD /kulykoVZVXgW1kWparO6V999vWe/dsbEAj+6zf0D2cCqCb/zjWIv4EFPCecf59lT/ZxJ/s0 UptsGurvu+1ZGPJf/3XWa/8lL9V/zuG/pPhn/3XQYjg/uRszljy6jXssFGzsFO17//sR/zcZ +3fD/Zz20r3P9l+h/6qklXP4L8pW+U/+QXXDP5Tvey74yT/c9mn591nEPxL5r1wUO/91aa4m /Ls6oMA3VwTUO56r/R/8u/ocdNl92z+eFHvb8L/v8e+ziH8kFPvBf12hFyP+a+lQ65+9/Gf/ of7fsy7yX9fb5N9tfILWgR2r/30Wtw3zSv1fsX8sCOp3NVH+u4ZfWeeu31ShztX+q9r1vw3l vz8V3J163/5/AvcU0b79b7n9b0MWaP+7hczb/5H/uh4g/648H/cfQ2tnL//djxtpgsE6tbun fZ+76XiOr/ihQMmSXv/j8e8q/Zhz+6fOHx6Gw9xYHMO11H+8l6s78iS67IMGwHT9P8TZ/EPp L5yH2D9dCEy0/4cQ/ynS55+2XEv/b2/nv7AOx/f/DXGG+B+//yOsgEVMz0LXPw0O76fZKDwd uf9/YXr8jz39N3ZuLEH8X5ge/1PO1gT9T+cTzkRP/f+agP/pbMLZ6PjvGSR4PsD/6AkqnJf3 Lf/qdbGv/olCg3b8T+6wMuL/wjT9v9LUH8LV0PQvT+LlRsu/XIzlxaHjf6yyKCaOJqRGx//7 scLidupwQmJ0/I9WAGvf/xEujfjPG/GfN+I/b8R/3gz4V6qq/7gnPyr3JKh7/suNCBb/W6Pf vxsmXID6kk4AdyKI/+0xWP4XBT/5RX8rif8NMuRfVUXFT37igvjfIkP1f1X5+Fc4/4OU/1tk sP4vFT75CdV/gaeB+N8cI+0/zlKGd/G/NYav/wrOIv43jPT/5I34zxvxnzfiP2/Ef96I/7xp +zfj/scGhwoJ8qblf/zLHw+v+3igcHba/ken/xC2xqHjX54Ay4muf3kCLCMeevw3zo/pBkSL scJGuDb6/Jso/f1zdLLoaPl2IEEeEEqKXv/RFcD76GrwoKMdbwcSxH9SDPjnWWCU868ost/o MD2Mum0lMOI/KYbi/45qc+f/cIvLoJkTbtsJhPhPiiH/t3/Zffvu3Tv0vyu//fOf//wImjnh tp3gLhsq8Z8YQ/53n8pPNcb5L7/7i/6uBjRzwm07oT4B3Kv4T4oh//q7R1/+18JDMc8Jt+0E 8Z8iw/EPUV5i/AMFxT8m3DYSDu6bpF1bUPynxXD8Ox4rin9HccD4x4TbZsJddXe4O9wf7sV/ UgzHv1H1vyqO/wPHv9kZ9P9Ynw2PGv3X4X+4r6T/Jy1G4l8Nxb9+1BT/ZudOBvGfLiP1v/rk 4//mT3/67objX7kSQOJ/Gxwf/26zj3+ldhz/Uv+nyKz4r4P/5k9c/6tm/a8g/qX9nygL6n/1 XVz/K4z/Sq7/k2RB/f9p143/6oD+D+I/Lfr9F4V+rONcu/gvyyj+64TvuP6vE0L8i/806fev Hnd1065u2zn/OxWu/+sEf/1fJzwqpSn+78G/1P+J0e9/t+Nuvtr/42OI/5Bw20wQ/2ky5J+6 +dF/iP+QcNtM4EGj4j8thsr/90AB5X/x4jAVlP+ccNtM8Ij/pBjwzzj/vAz1v0+4bSZ4xH9S 9Pq/C8j4z23T618FtI2IV8xAQjx4XLh6Jp//EDZNn/87IRt6/I8VF8LW6PoXskL8581zy/90 nSFsiqZ/IUfEf96I/7wR/3kj/vOG/VshR7z/6asFYXs8eP8Pai6FKzbKyWwEFDInpK/OWh94 1K/hqA/tHnnWL3EJkf/n+LyI5/tqTvh1d1e4Hd8PZ2juCx9zQvrqSWt9YOfXsNqHdo8865e4 hMh/NKqjOd6jMeCjonnAGw3G25F94fWE9NWT4HWFoxbuNf41rPahhXttHBlepw6/BPEv/mf4 L6Na5pr93w8nVVX8lGIK/r/44otff/jwq+oa/P+g/mG+KDAN3qb9f7nf79++rv9D5B/vZt1H ex3gX+MDS9fYmjwqHoaS3DkERyrcpjX9Q4wVDf8fP3z88C/X4N84/z8tIA1e2/5//OMf/ztQ Hvzb9/aV/YNySqKmEScd7u/v3DwF4QPd77r88GGGfy5XvH84auE2regfvmqxLKuW/49X4f83 UAD86LfFkP+/tbb2b+0T7/vlvj7sefxTnPTH/4H26vHv3sIH1kcY8O8DHpLcMe6jpDs8j9bw zxEPu+KVXFFE/j92/Zcq7O45v/9/xQLgmz9E/kt/7en8v7x3/l+C/yej9GL/v3RLX1X0S+Xr W9rVjTkuen/fw/7d+6E21/LfW/43/d/H8X+Yjn/cd/B/ScZduo942LXe+t8/VmrC/2dfF9Hh VXz4JbT8+ypIs16XycX/b2Dtm2/Cj1f94KfKfUt0hf5//Ld/o374tEf/Sv1w/9SMf7d7CcWb dioOB6ydOR2O438zX/3CbWX/ZVWU8KHsX6nIP1bzlIRtvN74pweVG/6r6Kig9r7Pf1T/H3rq //eUGX+eWzXqv/4taEXpPuLZf/3jxfH/M/D/8RX9w2j+gvz7Np+L/xrzu8+/+ebv2v5/WlVU /v+N4vK//KI+Fer4P6L8/+xjXRt//JrSv/rgPuSXlfdflLxr3caI4p/ckH/yPRT/eGrQB9a/ 7zKEott5yH/FgH8m+MfZL9j/gxnzr7T535p/wwVHfFz+l8H/x4//5/PPW/4xEOjw9UrdxD6X fyzyK4r/3/zma+f/3w/5d/H/JcU/+ncnQ9O/l1j5XySllx9r9599/Mif/aF2/1W/f2uj+HfK 6r/o/8B1c3/8Nz4Qft/wf+Uf6O5uof8P/+yLh2rCf6ms+V/aPSlD/jHiOf5dbdD0//dt/5+F +r88s//fcAEA9X/96/rdT77/Q8u/UsPx74r/Vvy7XfE309JRfq2+Vp+pz+izq7+uK4APVUW/ VBX7NyqK/7s4/g898e9Ka01XBtEsNRj/sf8o/gMHjScD1gF4VKoRIv8fsACAPe8eDPxIeFD+ 1Fb8k38f8XiWY2WgYv8fP475L7hddB7//8oFQP3TqcJ+b6vvrf1vRfD/RSggav//t670nXLv v74WbPt3FjEc+Qfw8f9ZHf9fc/zXBUCBbQDUUeA9kYH4v7+L4/8Q1f/wSQf/jPp9/AO1y//D sP9Dw/+h4x8LACzEdR0p7B8myX8Tf2ip3Olb+PjHiMcPdb9804z/j5//fbv9F/l3rbN9+D8t YTT+sc0HP93Pvyf+X9GM/x+Q/x//+N9+8cU/OOXg/4t/wPCPi1u3QMeG8D/E7b9m/e8KgL+G z0EdP4TlKP5NFcf/fRz/B45/twhXakP+CfJPkH+Y04z9087kH9fi8v8DdzpUD+4XaNg/rDX8 V/QrZYEY8fihbk49E7f/Xfk/0v5zuxdn9A9tPpcJ/H9DJ0Dk3y1w/V+HfM0XReXjf7936cE/ 7FZE/qvh9r8rAKD4Jx1fwrKPfyy3g/+7KvZ/T/7v77DHb078Y1kRPvDQ8D8R/7/86p8fqth/ Ffsv4g9FaZzOEU/lP9VrUfvf1f//0jh9yo8QR+y/+vKtP/wSxuO/bvO5TOwf/g75d++wyfn/ qdP0n136XP9UGFbs/6sPUPyTDmjlRPHPp2Vo5bF/tHwLjbgKa4MB/ypu/7X902EPc+r/up36 wQ2lx5/H1f/8v+h8KLXeOZ0j3u2q1Me6XtNF5P8LaP/H/suvCywAyH+BFcCZ4t8ovv6vfv7H Wv5Pvv/+j7P97/eQHvw6t436/1DF/vFXU7D/D7+AS0DS8fYtZKP4pxES4/5htXK1wXD8D/sP 8R9BVQPS6P+BAgCTJ67/YKFg/758eKl/PxD/Jvb/M9cCjMv/8mtdxv4P++q//uO6/g33/2DE llg7lX/8Hv3/tprnn1biqqtotf/h9xSVjBW8FJD+odH++/LtHrKR/ydYmfQPZ9nhfsT/cPlf Rf4Pd3Q5CEmcs9n/98F/6Lj/Mq7/oSfLRTz4p8SO/3+Jd/+o4vgvvvzHOtBW9u/K1uinp9bJ j373+eeff/O7z/+w3H+pfNVFwdlMhxICp5SB0h8KAPRPDQDy/7bCXV+wc74K/u/pBeOfGwQ6 SvEfqPyoqV7/Ial1/+eerl2a/l1fBfsPe3rC/5L0s3/rm7J1/BeYOfj/ou3fdZFE9X91Dv9F FX76suLWifP/k9P8E0O/mfjWxle/KKgTuOt/v+ddwT/c1mP/d4f7EP/O6H1F/jnFf+Du20c6 TusHWuS/+p+8JxcPQ/9LAtMp4t2udf1fUBK8g/+ftf1TkYX+66WVy//m2VlRHeD+Y+U33/zu J677L/zHlVLhx1/Bf5SOp4K//xP7j3Z9qbCV5/tb7mAq6pCExjG+KeVc/nv3DEnwOpI+EP// A6r/oV9SBdFwv6J/pudX8iPw/4e+/zj4x5OhQP9+ZaH/KH0qCUt1TuJaxSVxiY5JXMD3l/+B Hv8z6v/+PUMSvI77D0mwWPv/Dx9+9esR/4HX8M933Qf8B478n0+lL0869CfB6wofWLjX9fxH SYV7Bf8ff/2rqxj/Ea8l438gCV5T8B8lw6v4F/8+z/r+bUxj8j/TSIIOi+r9cIbmvvAxJ6Sv nrTWB3Z+Dat9aPfIs36JSxjyL+RB8H8nZIjEf95I/OdN8C/kifjPG/GfN5F/6uD1lO0NzbWh XC3URHoZeuIjpvYSVuLq47+YzCGcgPjPm8i/u6FclDwOo4JC2I0yKvk5s7KWUbhaoM5S+sGM pd+g3HChsoAshRfnNhduc+nyVJikyiC2qKr4EPRRuFZn66kdhNXo+g/mCvhXeFUlrvk3zlVy LvdS+iw+Hf6UsX93SnE6HCAcgj+KN0UZhfXp888UVY9/fKva/vmlavtnk1XTfyP+vf+qtVd8 IOEcdP2HhndR9fmvk+GpNfbvtsMGfJZtwH+pYv/ucSD+lNh/s/yHA4r/sxL7V80yGOr/jn8M 0sh/qQrO1e+/RNcN/1V//PttZfTZfqOwPpP1fxn7V6H+L0L570uJovT1vwo7VVWlaJfCJSjO 4Q8g9f/FGGv/F25jUZS8pYTGOLXV/XhV0KfwxdktsP3fKMnrg7hd3DwehTsBIEcRPkba/5ei 5b8KtXpFgVfwQiMtrBXNHZuZIL1ob2pnIKJdy54fRzgDjfpfYfXOYM9sUY77p4Ig+C8a2aLy pJeo/1f8vz5y/ydvxH/eiP+8Ef95I/7zRvznjfjPG/a/F3JE/OdN8F+5U+BtJSfCBlEt/IbY /5cu55dvJw51MnZyg7A2z/i0D3/N3K3f0PFfif8NQlMH8DQDt35D7B+zvnU+7N7a/Y19unF/ 6sX9zZPb4kzVr24bJO3hb72C2esEy7vu3fIe9qwz1dvqbHvLx653wH3hqLD/Uzgw5MbPFVaB pjuiL3Ib8E+AI2fN+je0CEbRP23DvzbKzsuUBQxiprANzgjyH3Z8ig9MJ9LE/0qYS/BfuVuq zj+M1ej1j1b2sYmu/z0s7i37DycG6QXBnK+xjVZ48755/uzF//r48j/4h7E4Hf8vrv2Phbn7 /p6o/G/6t7gY++fyn06fjn+/Tfy/Oj3+YUL+lv8X1w2455LZCbFRQdAu/+N8KJKKeSr/Xda6 avc78zb2j5v9/qGGEP9r0+ffPb7T8g+9wBD/3P7DNxfc0FJzksEwNNO4Buf2n9PGy3uLBX6o 5sM2bP/tcZOl1t4TNfrcCeMKH2n/rcjM+IcpxqhUbhK22GjF7rHoD7mCMhutRiJvsECATY19 GwfmokZYh5n1/3so/23Pb35t/1b8vybBv7/+62v/Q7Ze/2ELVORh46B/XMUyvOHfhvhvfE7T f2s34SR6/OOGhv/3L9j+F7bGrP4/x3vxv0UsYvjdb+jr/xEyQu7/542M/8oc8Z835N8KeYL+ p88TYZvAd1Da/w9QSwECFAAUAAAACADdlmopGnwamKw2AAB2AAYAGQAAAAAAAAAAACAAtoEA AAAAZXhhbXBsZS14ZWVuYS1wcm9ncmFtLmJtcFBLBQYAAAAAAQABAEcAAADjNgAAAAA= --------------8A978E447725B98B0B66238D-- From Jecel Assumpcao Jr Fri Nov 10 22:04:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03203 for ; Sat, 11 Nov 2000 13:42:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:03 +0100 (MET) Received: (qmail 630 invoked by uid 0); 10 Nov 2000 19:30:05 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 10 Nov 2000 19:30:05 -0000 X-eGroups-Return: sentto-1101623-1373-973884599-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 10 Nov 2000 19:30:05 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 19:29:58 -0000 Received: (qmail 72133 invoked from network); 10 Nov 2000 19:28:27 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 10 Nov 2000 19:28:27 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta1 with SMTP; 10 Nov 2000 19:28:23 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id RAA15202 for ; Fri, 10 Nov 2000 17:55:16 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A0889EA.B9AE12DE@jetnet.ab.ca> In-Reply-To: <3A0889EA.B9AE12DE@jetnet.ab.ca> Message-Id: <00111019195702.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 19:04:31 -0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] old computers and i/o (was: Is F for Foobar, R is for Risky?) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3cc36a1bb760a949dae86772c56cf37d Status: R X-Status: N On Tue, 07 Nov 2000,  Ben Franchuk wrote:
> While on the topic of old machines, it comes to my mind that
> nobody (In my limited knowledge of computers) has really designed a good
> multi-tasking system with good memory management and I/O hardware.

Please check out the Xerox Alto (1973):

   http://www.spies.com/~aek/alto/index.html

The scanned-in manuals are rather large, but you might find at least
the two hardware ones well worth reading. The CPU switched between 16
"micro tasks" on each clock cycle. One was dedicated to executing the
external instruction set while all the others were for I/O (video,
Ethernet, laser printer, disk, etc).

Though there is very little information about it, you might find this
1983 design of mine interesting:

   http://www.lsi.usp.br/~jecel/sinde.html

And note that Intel's I2O effort has greatly improved servers, though I
don't see why desktop computers shouldn't have something like this as
well:

   http://developer.intel.com/design/iio/

-- Jecel
eGroups Sponsor
From "Marco Al" Fri Nov 10 20:48:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03209 for ; Sat, 11 Nov 2000 13:42:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:04 +0100 (MET) Received: (qmail 21119 invoked by uid 0); 10 Nov 2000 19:43:48 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx01) with SMTP; 10 Nov 2000 19:43:48 -0000 X-eGroups-Return: sentto-1101623-1374-973885420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 10 Nov 2000 19:43:45 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 19:43:39 -0000 Received: (qmail 30774 invoked from network); 10 Nov 2000 19:42:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 10 Nov 2000 19:42:47 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 10 Nov 2000 19:42:45 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id UAA26979 for ; Fri, 10 Nov 2000 20:42:41 +0100 (MET) Message-ID: <002501c04b4f$301bc600$29e65982@student.utwente.nl> To: References: <3A0889EA.B9AE12DE@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 20:48:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ca9479c49dd5b7ac4cfb45aa19d42ac1 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> I feel you need memory management not virtual memory.Since memory
management
> keeps 'holes'  out of main memory it is a good thing.

How do you do memory management without address translation? Do you pick
some basic block size and have user land programs never access data in any
block except through an OS supplied base address?

> While on the topic of old machines, it comes to my mind that
> nobody (In my limited knowledge of computers) has really designed a good
> multi-tasking system with good memory management and I/O hardware.

What would be a good system then in your opinion? Mainframes/*nix seem to
work pretty well, what bothers you about them apart from the fact that you
dont like virtual memory? (how would you isolate tasks, pretty much
essential for a good multitasking system IMO, as well without it BTW?)

> Arg! my mouse died... Back later.Ben.
> PS. why not a two cpu set? A system processer and a user processer.
> A page fault in the just advances to the next task.The system processer
> just cleans up the mess.

I think its overkill, if you have a processor which can switch tasks easily
why not let it switch to the software memory management which can setup
DMA'd IO to get the page and relinquish conrol to a non stalled task quite
quickly (possibly even before its ready if it itself stalls)?

Hmm I just noticed something, maybe I should stop writing up every statement
I make as a question? :)

Marco
eGroups Sponsor
From Ben Franchuk Wed Nov 8 00:57:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03212 for ; Sat, 11 Nov 2000 13:42:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:05 +0100 (MET) Received: (qmail 18535 invoked by uid 0); 10 Nov 2000 19:46:05 -0000 Received: from mw.egroups.com (208.50.144.94) by mx19.rz2.gmx.net (mx19) with SMTP; 10 Nov 2000 19:46:05 -0000 X-eGroups-Return: sentto-1101623-1375-973885561-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mw.egroups.com with NNFMP; 10 Nov 2000 19:46:03 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 19:46:00 -0000 Received: (qmail 24478 invoked from network); 10 Nov 2000 19:44:18 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 10 Nov 2000 19:44:18 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 10 Nov 2000 20:45:23 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA09761 for ; Fri, 10 Nov 2000 12:36:42 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0896CC.B16433CF@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0889EA.B9AE12DE@jetnet.ab.ca> <00111019195702.00382@gandalf> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 07 Nov 2000 23:57:00 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] old computers and i/o (was: Is F for Foobar, R is for Risky?) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b667ecdd00aa58660f45435984b557b9 Status: R X-Status: N Jecel Assumpcao Jr wrote:
>
> On Tue, 07 Nov 2000,  Ben Franchuk wrote:
> > While on the topic of old machines, it comes to my mind that
> > nobody (In my limited knowledge of computers) has really designed a good
> > multi-tasking system with good memory management and I/O hardware.
>
> Please check out the Xerox Alto (1973):

In 1973 the closest I came to a computer was Star trek re-runs.
In 1983 I got to to program a PDP-8 and a IBM1130.
Around 1993 I got a 386. I will check it out as I like old
computer designs better than new hardware.The new ones have too
many I/O registers to tweek.

>    http://www.spies.com/~aek/alto/index.html
>
> The scanned-in manuals are rather large, but you might find at least
> the two hardware ones well worth reading. The CPU switched between 16
> "micro tasks" on each clock cycle. One was dedicated to executing the
> external instruction set while all the others were for I/O (video,
> Ethernet, laser printer, disk, etc).
>
> Though there is very little information about it, you might find this
> 1983 design of mine interesting:
>
>    http://www.lsi.usp.br/~jecel/sinde.html
>
> And note that Intel's I2O effort has greatly improved servers, though I
> don't see why desktop computers shouldn't have something like this as
> well:
>
>    http://developer.intel.com/design/iio/
>
Thanks Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Wed Nov 8 01:57:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03218 for ; Sat, 11 Nov 2000 13:42:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:07 +0100 (MET) Received: (qmail 4422 invoked by uid 0); 10 Nov 2000 20:46:24 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx16) with SMTP; 10 Nov 2000 20:46:24 -0000 X-eGroups-Return: sentto-1101623-1376-973889180-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 10 Nov 2000 20:46:23 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 20:46:20 -0000 Received: (qmail 25892 invoked from network); 10 Nov 2000 20:44:59 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 10 Nov 2000 20:44:59 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 10 Nov 2000 21:46:02 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA12793 for ; Fri, 10 Nov 2000 13:37:18 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A08A501.51581049@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0889EA.B9AE12DE@jetnet.ab.ca> <002501c04b4f$301bc600$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 00:57:37 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e1bf5a7940274577ca49d9d7d9104f3d Status: R X-Status: N Marco Al wrote:

> How do you do memory management without address translation? Do you pick
> some basic block size and have user land programs never access data in any
> block except through an OS supplied base address?

Address translation is needed for sure.It is the Excess of virtual memory
the is the problem.I say use what memory you have and if you run out tough
beans.No swapping ever.Take general file buffering, a few buffers are nice,
several MEG, no way.Lets see we have a 4gig address space... lets put the
heap at one end and the stack at the other and general data scattered hither
and yon. Wow we need 64 bit addressing next as we have all these 4k page faults
For a person who's first computer usage had 8k of core memory I really question
VERY large address spaces.


> What would be a good system then in your opinion? Mainframes/*nix seem to
> work pretty well, what bothers you about them apart from the fact that you
> dont like virtual memory? (how would you isolate tasks, pretty much
> essential for a good multitasking system IMO, as well without it BTW?)

Maybie I just dream of using a Real Time OS rather than unix clone.Virtual
memory is useful but just as we all know it is not a cure for bad programing.
I still think 1 thread 1 cpu and memory. The average PC user only has one
active interactive program and a lot of background tasks.48 Meg (ignoring
the size of the large video display buffers) to me seems to me wasteful
I have web browser and few other programs that I  have to swap memory. PS
any number crunching like ray tracing I would do at night anyhow, if I could
find
a good modeling program for Radiance.


> I think its overkill, if you have a processor which can switch tasks easily
> why not let it switch to the software memory management which can setup
> DMA'd IO to get the page and relinquish conrol to a non stalled task quite
> quickly (possibly even before its ready if it itself stalls)?
>

If you treat the main processors as just another DMA device,
you can have a small dedicated processor with its own memory to keep
things flowing smoothly. Just my 2 Cents on the subject.

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Alan Grimes Fri Nov 10 23:13:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03230 for ; Sat, 11 Nov 2000 13:42:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:10 +0100 (MET) Received: (qmail 3723 invoked by uid 0); 10 Nov 2000 22:14:06 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx01) with SMTP; 10 Nov 2000 22:14:06 -0000 X-eGroups-Return: sentto-1101623-1377-973894392-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hi.egroups.com with NNFMP; 10 Nov 2000 22:13:37 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 22:13:12 -0000 Received: (qmail 12843 invoked from network); 10 Nov 2000 22:13:10 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 10 Nov 2000 22:13:10 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta2 with SMTP; 10 Nov 2000 22:13:10 -0000 Received: from 208-58-197-29.s537.tnt10.lnhva.md.dialup.rcn.com ([208.58.197.29] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #2) id 13uMQ1-0003iF-00 for f-cpu@egroups.com; Fri, 10 Nov 2000 17:13:09 -0500 Message-ID: <3A0C72F0.77BF7513@starpower.net> Organization: Nanosoft: Software That Thinks X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 17:13:04 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bc44f74dc13866017695bc533cbb8b05 Status: R X-Status: N > And when you loaded a library or program the chip put it where it was
> available.  There was no screwing with virtual memory because using
> supervisor mode with userspace tools was as frowned upon as IRCing as >root user is these days.

I never figured out how to IRC in X windows when not logged in as root.
Since I could only get networking and X running at the same time while I
was w00t, I had to switch to the second virtual console, log in as user and
then IRC. This, ofcourse, profoundly sucked... Which is why I am using win
3.11 to type this. =\

> I'm going to workon Eddas with Downix.  I think the concept of a
> microkernel style CPU especially a dumb calculator at the center of it >all is flawed.  I want something else entirely.  However, for
>competition's sake I'll still be working on some ideas for F-CPU.

That's probably the best projeckt for mee tooo. =)


--
Meept: The ultimate Phlisophy.

http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unabomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers fbi chemical weapons twa 800 roswell terrorist freedom
 From Michael Riepe Sat Nov 11 00:20:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03233 for ; Sat, 11 Nov 2000 13:42:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:11 +0100 (MET) Received: (qmail 5823 invoked by uid 0); 10 Nov 2000 23:24:31 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx04) with SMTP; 10 Nov 2000 23:24:31 -0000 X-eGroups-Return: sentto-1101623-1378-973898667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 10 Nov 2000 23:24:30 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 10 Nov 2000 23:24:27 -0000 Received: (qmail 46892 invoked from network); 10 Nov 2000 23:24:26 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 10 Nov 2000 23:24:26 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.125) by mta1 with SMTP; 10 Nov 2000 23:24:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02418; Sat, 11 Nov 2000 00:20:28 +0100 Message-ID: <20001111002028.18473@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A0889EA.B9AE12DE@jetnet.ab.ca> <002501c04b4f$301bc600$29e65982@student.utwente.nl> <3A08A501.51581049@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A08A501.51581049@jetnet.ab.ca>; from Ben Franchuk on Wed, Nov 08, 2000 at 12:57:37AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 00:20:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, R is for Risky? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 83163ded96eb7c263bbf3745523cd0f3 Status: R X-Status: N On Wed, Nov 08, 2000 at 12:57:37AM +0000, Ben Franchuk wrote:
[...]
> Maybie I just dream of using a Real Time OS rather than unix clone.Vir= tual
> memory is useful but just as we all know it is not a cure for bad prog= raming.
[...]

If you don't like virtual memory, log in to your Linux system as root
and type the command `swapoff -a' -- voil=E0, no more swapping.  I hav= e no
swap space on my PC at home for almost a year now, and that never was a
problem (ok, I had to kill netscape now and then -- that piece of shit
is an extraordinary example for Bad Programming (tm)...).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D""
<= /a>
From Yann Guidon Sat Nov 11 01:20:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03239 for ; Sat, 11 Nov 2000 13:42:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:14 +0100 (MET) Received: (qmail 16163 invoked by uid 0); 11 Nov 2000 00:43:09 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx17) with SMTP; 11 Nov 2000 00:43:09 -0000 X-eGroups-Return: sentto-1101623-1379-973901766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 11 Nov 2000 00:16:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 00:16:05 -0000 Received: (qmail 20523 invoked from network); 11 Nov 2000 00:16:05 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 11 Nov 2000 00:16:05 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 11 Nov 2000 00:16:05 -0000 Received: from f-cpu.org (nas2-216.ras.club-internet.fr [195.36.192.216]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA08733 for ; Sat, 11 Nov 2000 01:16:00 +0100 (MET) Message-ID: <3A0C90E5.6D1BCAE6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 01:20:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, W is for Whisky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 533c17bcf76688bd55e9dcb13042bf8e Status: R X-Status: N hi,

Marco Al wrote:
> From: <bfranchuk@jetnet.ab.ca>
> I have little insight to offer myself... but this reminds me of a page from
> one of the principle P6 architects
> (http://www.cs.wisc.edu/~glew/HOME_DIRECTORY/work/research/public/instructio n-set-issues.html)

ah, this old smart Andy. Sometimes he's not easy to understand but some other times,
his ideas are really strikingly elegant and useful (who remembers the discussion about
POC [pipeline-ordered clocking] ?)

> "No Addressing Modes
> Not providing any addressing modes is a classic RISC excess: e.g. providing
> only register indirect addressing,
>     dest := load( memory[register] )
>     store( memory[register1] := register2)

it's an excess but in our case, this keep the core absolutely clean and
therefore easier to develop, less things to debug. VM is usually a real
pain to design...

> Not having addressing modes hurts codes that access complex data structures
> and records with different fields at various offsets.

this, in turn, comes from obscure programming with langages that shall remain unnamed.

> Post-increment addressing, as was proposed for a Gould machine and implemented in IA64, is
> only slightly better since it creates unnecessary dependencies and consumes
> registers." (he backs it up a little and has some more points, but that was
> the most relevant bit)

f-cpu does post-incremented, or, to be precise, parallel implementing.
the addition is performed at the same time of the fetch/store.

it's probably more strange when viewed from a HLL, but gives a lot of opportinity
to make fast and clean code. we're not here to execute COBOL...

> Marco

then, Michael Riepe wrote:
> Hi there!
> `F' means `Fun' :)
well, yesterday, on this list, we changed it to "fluffy-cpu". Tomorrow,
it will be "floppy-cpu". then...

> On Thu, Nov 09, 2000 at 05:35:11PM -0000, bfranchuk@jetnet.ab.ca wrote:
> The F-CPU design has been discussed for more than two years,
1,5 to be precise ;-)
> it's now stable (unless we encounter unsolvable problems),
> and we're going to implement it as is.
not only it's (apparently) stable but it leaves a lot of opportunity
for future architectures.

> If you want something unique, like a dataflow or TTA processor, or are
> interested in things like reconfigurable logic, look for other projects
> (or start your own).
before he starts something from scratch, he may look at the
http://www.opencollector.org site, there are some "ol'good" octal desings...
but he also wrote in another mail that he liked RISC too, so let's not
bother :-)

> > I was thinking since a Frame register is used so often
> > in high level lanuages it may be useful to define one register
> > a hardware frame register and some specific instructions for it.
> We don't have a dedicated stack pointer, so why should we have a dedicated
> frame pointer?
looks like an old habit. but that's not important...
hey, since the 386, enter/leave was slower than push bp/add bp,N :-)

> The F-CPU ABI isn't defined yet, but I guess that it will pass function
> parameters in registers (if possible, depending on the number and size
> of parameters), and that the callee will save registers to the stack
> before it uses them (using post-{inc,dec}rement addressing, and a general
> register as the stack pointer).
right. That prevents a lot of (slow) memory accesses.

as for the later remark about recursivity, remember that there are
two kinds of recursivity : program recursivity, and data recursivity.
except for certain rare cases, all recursive algos can be transformed
to data recursivity (loop-based). a good example is a tree scan.

> > I was thinking of adding LoadFrame,StoreFrame,FrameEfa.In all
> > 3 instructions, a 12bit constant formed by two of the register
> > fields would be added to the frame register giving a efective
> > address for a load,store or Efa instuction.
> An instruction that performs `r1 := (r2 + d)' (using *general* registers,
> and with a reasonable range for `d') would be nice for array and structure
> members, too, but the current load/store instructions have only 3 bits
> left for `d'.  On the other hand, a separate instruction would be only
> one or two cycles shorter than a sequence like
>         loadconsx.0 d, r1
>         add r1, r2, r3
>         load (r3), r4

OTOH, what we do is the same as
load r1,(r2)
add r2,r3,r2

and the last half can be the "d" (offset) of the next memory access.
who got the trick ? :-)

> unless the load/store unit had its own adder (and a third input port),
> and the range for `d' would be smaller, too (10 vs. 16 bits, or more
> if we add another `loadcons').  Another argument is that an address
> that is explicitly calculated can be reused (e.g. in the corresponding
> `store' instruction) while an implicit add has to be repeated every
> time the instruction is executed.  If the load/store is part of a loop,
> the wasted cycles sum up quickly...

right. if you compute all the time the same address, there's no point
using complex addressing. with clean RISC coding habits, it's easy to break
the complexity of a code into a minimal number of instructions.
furthermore, the code density decrease as the performance increases.
we have found a rather good compromise for the f-cpu.

Ben Franchuk wrote:
> I am not saying to change the instruction set, but if you discover
> FREE resources a single word midsize offset for C frames might be useful.
addressing should only be post (paralle, in fact) incremented.
otherwise it's a real pain to schedule inside the chip when an interrupt
or a fault appears. you know what i mean.

> >look for other projects
> > (or start your own).
> I have - see bottom of email. :)
is it Ulna or Luna ?...

> > We don't have a dedicated stack pointer, so why should we have a dedicated
> > frame pointer?
> A frame pointer is used a lot in many languages and if you can save
> by using a short form over a long address that is one less word of bandwidth
> taken up and one word of core memory shorter.Opps ... ram memory shorter.
old habits, huh ? ;-) like you have remarked, today, code density is not a criterium.
plus, it slows down the CPU when it needs to decode several instructions at a time.

> This brings up a good point. I can see 4 stack and frame pointers off hand.
> User stack and frame pointer,system software stack and frame pointer,
> interrupt software stack and frame pointer and virtual memory handler
> stack and frame pointer. The question is how do you tell a C compiler
> or other HTL what you registers you want to compile with?
no need. The each correspond to a different "state" of the CPU, associated
to a particular "context", that is, a VM environment and a private (logical,
not physical) register set. The register set is flushed to memory when there
is a task switch.

> > An instruction that performs `r1 := (r2 + d)' (using *general* registers,
> > and with a reasonable range for `d') would be nice for array and structure
> > members, too, but the current load/store instructions have only 3 bits
> > left for `d'.  On the other hand, a separate instruction would be only
> > one or two cycles shorter than a sequence like
> True, but other than the instruction set doc's are a long read
> the F-cpu looks to be a fairly nice and complete machine.
it tries to be. Well, people try to make it like they think it should.
it can't satisfy everybody, like every CPU, and it's like a "least common
denominator" of the features we want and of what we can do.

> Ben.
> PS. With a language like Forth that bounces around a lot,
> is there a way to tell the cache and pipe line logic, "**danger**
> slow down the program curves ahead"?
i guess that we will be able to play with program prefetch logic.
the protocol is not writen into stone, but the f-cpu is highly based
on prefetching habits. a jump without prefetch (or a load/store without
preparation) is slow but necessary because the internal hidden property
flags are flushed upon task switches, they have to be regenerated upon use.
we have to let "clumsy" software work as well.


> > regular strides are well suited for today's CPUs. the f-cpu seems to penalize
> > irregular access patterns, but in fact it only reflects what the memory does.
> > use registers instead :-)
> I have started programing on a PDP8 and never got in the the habit of using
> registers.
it's ok if you only program PDPs. nostaligia is fine and history is funny.
but today is today and we have new challenges...

> > This may sound weird at the first glance but if you look
> > at what a normal CPU has to do, you'll see that it maps perfectly
> > to a simple CPU. More interesting, it doesn't penalize
> > "advanced" CPUs :-)))
> That is  a good feature.Is there a way ( I need to read more doc's)
> to state the time the effective address block is valid? this block is
> valid for the next n# cycles before virtual memory messis things up.
as of today, there is no worry about VM validity because in common cases,
it should work well. VM flushes "unused" pages so your access patterns should
match the LRU system.

here's how it all works for the FC0 (the F-cpu Core #0)

usually, we have consecutive instructions like

load r1,r2,r3
.......
load r4,r2,r5
..........

the first instruction does load the worf at location r2 to the register r3,
and in parallel adds r1 to r2. then, it loads the word (r2) [after the result
of the computation is available and tested] to the register r5 then it adds
r4 to r2. So R2 is our data pointer, it gets modified by r4 and r1, so we jump
>from one location to another by adding values. we can access up to 8 different
locations with different registers. i remember that we have an 8-bit (signed ?)
version of this instruction to avoid the loadcons instruction for short offsets.

in fact, behind the scene, it works like that :
with a lookup table (associated with a LRU algorithm), we "associate"
(tag) the register R2 as a "pointer". a buffer line in the L/SU is "associated"
to r2. When the decoder sees R2, it looks up in the table and reads
the L/SU line, the offset in the line, the "valid" tag, the "VM valid" tag
and the access right tags (R, RW, W, (X)).

* if the "valid" tag and "VM valid" tag are set, AND if we do a correct
operation (load on a "R" or "RW" sector, store on "W" or "RW" sector), we can "issue"
the instruction in the "execution pipeline" that can't be stopped.

* the execution pipeline will do 2 things : 1) read or write to/from memory
through the L/SU 2) add the offset (reg/imm8) then submit the result
to the TLB. the TLB will fill the tags (VMok and access rights).

this way, next time we see a load/store instruction with R2 as pointer, we lookup
the flags and that's only what's necessary at the decode stage. If VMok is
not valid, we have to trap, but the pipeline remains clean because the instruction
has not been "issued" to the pipeline.


Now, if there is a task switch, the little lookup table (8 entries of 6-bits inputs)
is flushed by the precedent task and we have to restore the "hidden flags" that were stored
in the LUT. this is detected when the "valid" tag is cleared. So we have a special
cycle that submits the register value to the TLB, before the rest of the usual
operations are done (test if VMok, issue if ok). it stalls the pipeline during 3 or 4
cycles, just like when you use more than 8 registers to access memory, but it still
works (in functionality) even if slower.

notice that the same principle applies for jumps and routine calls.

> > > I was thinking since a Frame register is used so often
> > > in high level lanuages it may be useful to define one register
> > > a hardware frame register and some specific instructions for it.
> > No. Never. Read RISC books.
> I don't have any, and the books here are "Basic programing Concepts
> and the IBM 1620 Computer","Programing the the IBM 1130", "Programing the PDP8",
> "386 Assembly Programing".
ok, i see :-) it will be a huge cultural shock for you to use RISC machines,
but remember that it's finally rather close to what Seymour Cray did with the
CDC machines, and later the CRAYs :-) back to the 60's-70's...

> I think the ending is for both RISC and CISC instruction sets in the near future.
> Most cpu's emulate a Harvard style cpu by using a lot of internal
> registers.Unfortanaly this requires large amount of opcode fetches.
this is not a real problem. The real problems are bad compilers that churn
bad codes and inefficient algorithms...

> With a .5 ns internal cycle and say a 20ns external memory cycle in the future
> bandwidth to external memory will be the limiting factor regardless of the internal
> cpu design.
yup. the real problem here is the number of pads to the outside memory.

Comp.sys.super Official (as it gets) Motto:

        If you fit in L1 cache, you ain't supercomputing :-)
        --Krste Asanovic <krste@ICSI.Berkeley.EDU>

[l/m 5/7/97] Intro/TOC/Justification comp.parallel (2/28) FAQ
(Eugene N. Miya)

> This is a lot like the old vacuum tube computers with a fast but
> heat limited cpu core and slow external magnetic core memory.
yup. that's why in the manual i compare the FC0 to a crossover
between a CDC6600 and a MIPS R2000 :-)

> I think a streamlined CPU will result that has a simple CISC instruction set but
> have a well defined local memory like risc stack register windows for on chip
> use.
stack register windows ? argh...
what you describe is close to the NS32K, i believe (i gotta check my books).

> > it should remain as universal and flexible as possible
> > Read Patterson and Hennessy's books and read the analysis of the
> > R2000 or R3000 chips. after all, the limiting factor is the memory
> > latency etc, not the frame-enabling instructions.
> I programed intel chips,I KNOW what inflexable is.
hey. so you know things i don't want.
in asm, i NEVER used frame pointers. i used BP for storing useful data
and i used PUSH/POP to spill some others. i pass all parameters by
registers. x86 is the worst thing mankind can do (after war and taxes).

> While memory latency is a
> a limiting factor on cpu design, wasted resources are a close second
> like software doing the hardware's job. Mice and too fast I/O
> come to mind.
i don't see how the mouse influences the instruction set ... :-)

> > Plus, remember that for really fast function/procedure calls/returns
> it is highly recommended to use the registers : you have 63 of them,
> I think 8 registers are more than ample in many cases for a CISC
> well designed processor like the PDP11.
yup, but now memory is even slower compared to the core.
more registers means less need to access memory for trivial spills.
now, you got the point ? :-)


> > depending on the complexity, you can nest around 5 or 7
> > function calls with 64 registers. happy ? :-)
> Nope - I use recursive functions in small C.:)
read above (transform recursivity into loops and manual data
addressing for the data stack). if you wanted real performance,
you woudn't use trivial algorithms ;-)

> > i also have some VHDL packages to check and bundle, so be patient.
> Ok so I am 2 years late.
no, i wouldn't say. maybe 15 years (the golden era of the RISC architectures),
but you don't miss much. you have to catch up, though, but you can learn
only the interesting things :-)

> I would love to come but I am financially challenged at the moment.
> You don't have a video camera you could tie to the net for all us
> home bodies?
there should be some netcasts, it's in the CCC's usual gear.
(almost) all conferences are recorded. unfortunately, last year's
videos were lost in a silly server overflow... i hope they learnt the lesson ;-)
anyway, you're welcome as soon as you can hop above the ocean,
there might be meetings in France as well.

> Ben.

ok i have to leave, i have tons of mails + a draft to write tonight.
tomorrow, i'll catch up and maybe update f-cpu.de.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Keyshaun Sat Nov 11 02:04:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03245 for ; Sat, 11 Nov 2000 13:42:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:18 +0100 (MET) Received: (qmail 669 invoked by uid 0); 11 Nov 2000 01:04:38 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx04) with SMTP; 11 Nov 2000 01:04:38 -0000 X-eGroups-Return: sentto-1101623-1381-973904667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 11 Nov 2000 01:04:35 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 01:04:27 -0000 Received: (qmail 7496 invoked from network); 11 Nov 2000 01:04:26 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Nov 2000 01:04:26 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta1 with SMTP; 11 Nov 2000 01:04:26 -0000 Received: (qmail 26134 invoked from network); 11 Nov 2000 01:04:26 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 11 Nov 2000 01:04:26 -0000 X-Sender: kruger@ultra1.inconnect.com To: f-cpu@egroups.com In-Reply-To: <3A0C90E8.B8DED9EF@f-cpu.org> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 18:04:26 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2375d504aa696384bf9bf78bc7eccd0c Status: R X-Status: N I would like to share my thoughts on your concernes...

F-CPU on ATX.  I know that ATX is not the best there is.  Though, it is
supported by people commonly.  That is the important part.  Other than
that I could care less what it makes it on.  Right now I'm thinking how
nice it is that my Alpha AXPpci 33 just happened to be an AT form factor
and not some funky proprietary. 

Linux port of F-CPU.  People are the important thing.  What I feel is
needed is a group of people who are devoted to the FSF philosophy, and
yes, that is what I mean when I say open source (poor choice of
words).  The "pink FSF utopia" as you called it is what I try to share
with people.  To the point though.  Get enough people interested in making
a linux port to the F-CPU and it will happen.  If the F-CPU is a good
processor and there is linux support for it then it may be all the more
marketable to businesses running linux in house.

RAM patents.  What part is patented?  If it is patented to the level of
using the principal of capacitance and if you make any device that holds a
charge to store information I feel that they wouldn't have a case in
court.  That is patenting a principal of electronics and as such should
place it in the public domain.  As long as your external interface is
different than that of SDRAM and you call it something else they shouldn't
be able to touch you or whoever may design it.  they need to face the fact
that physics can't be patented.

The tasking processor.  Though in a small application it would probably be
a moot point to have a tasking processor I feel it would be a good part of
an F-CPU system design.  Tasking processors in systems can help take care
of memory management and other OS functions as I described before.  Most
of my interest in supporting a design with a tasking processor has come
>from what I have learned of the IBM AS/400, it makes masterfull use of a
tasking processor.  But I do agree with you that it may just be extra
design effort.

F-CPU isn't ready.  Though my message before didn't relay it I do
understand that F-CPU isn't ready.  I want to support getting it ready.  I
would like to support the advancement of the F-CPU and other projects.  If
you think it would be better for me to try and organize support for
another project I can.  All that I have seen at opencores.org is only VHDL
burnable to PGAs.  From what I have observed you have already determined
what is and isn't going into the F-CPU and the real design decisions have
been made and now it is a question of implementing it on a mask so you can
etch chips.  (yes, I am oversimplifying)

F-CPU first for hackers.  I can appreciate that the F-CPU would be mainly
used by hackers and other such groups in the beginning.  I also believe
that if people can actively work on in and believe that it is an up and
comming project that will work then it will be supported sooner.  I feel
that organizing efforts to support something while it is still partially
under development can help to accelerate the readiness of people to
recieve it.

Last of all...  I share the views of the FSF and I do  believe that
computers and their users should be free.  I consider the relationship
between MS and consumers to be downright abusive.  At this time most
people don't realize that there is a problem.  They pay too much and they
get the blue screen of death.  I started writing to you with the ideal of
having a truely free platform.  I do use free software as much as
possible.  When you said there aren't many(if any) good free EDA tools for
linux I just wanted to make sure you have been following gEDA.  I know it
isn't ready yet.  I am fully aware of that.  When it is done will it be a
good suite of tools for you to use?

Shaun Kruger
thekernel@subdimension.com

If it wasn't for the bondage of windows I would never have gone to linux.
eGroups Sponsor
From Jeff Davies Sat Nov 11 01:57:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03248 for ; Sat, 11 Nov 2000 13:42:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:19 +0100 (MET) Received: (qmail 3680 invoked by uid 0); 11 Nov 2000 01:15:18 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net (mx19) with SMTP; 11 Nov 2000 01:15:18 -0000 X-eGroups-Return: sentto-1101623-1382-973905215-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 11 Nov 2000 01:13:36 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 01:13:35 -0000 Received: (qmail 16711 invoked from network); 11 Nov 2000 01:13:35 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 11 Nov 2000 01:13:35 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta1 with SMTP; 11 Nov 2000 01:13:34 -0000 Received: from modem-91.doxycycline.dialup.pol.co.uk ([62.136.91.91] helo=tiglath.pileser.sumeria) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13uPEX-0001O0-00 for f-cpu@egroups.com; Sat, 11 Nov 2000 01:13:30 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> In-Reply-To: <3A0C90E5.6D1BCAE6@f-cpu.org> Message-Id: <00111101133600.24769@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 00:57:52 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] No more architecture wars until FC0 finished please Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d6944f18355f9477dac281732812f8e Status: R X-Status: N
> > With a .5 ns internal cycle and say a 20ns external memory cycle in the future
> > bandwidth to external memory will be the limiting factor regardless of the internal
> > cpu design.
> yup. the real problem here is the number of pads to the outside memory.
>
This is why the idea of a smaller amount of RAM (say 16meg) on chip with the
CPU, and many of them is a good idea. Like I've said previously, GNU Hurd is
now available in it's own distro from Debian. The hurd is supposed to run more
like an object-messaging system than functions and calling.
Imagine 20 cpus each with 16meg of RAM (running at 800MHz?) in your laptop......

I think there's probably a way to do away with a stack by using a pure message
based architecture, but I'll have to stroke my chin for a few days thinking
about it.

>         If you fit in L1 cache, you ain't supercomputing :-)
>         --Krste Asanovic <krste@ICSI.Berkeley.EDU>
Call MS Word supercomputing?

>
> WHYGEE

I think the architecture wars have to be called to a halt for a while.

Yes there are good reasons not to use Virtual Memory, but it's not particularly
hard to support, and people will laugh if we don't include it. I think at the
moment, the target OS is still Linux also, but hey, you can write/port anything
you want to it. Don't forget there are real time versions of Linux out there
that you can compile up for FCPU when there's a C compiler for the FCPU.

Similarily, if you don;t like FCPU architecture, fine, rip it apart and reuse
components in your chosen architecture, publish it under GPL, and everyone is
happy. There are already many free cpu designs, just like there are many
free kernels:

Linux, FreeBSD, Hurd and probably many many others.

I missed the agreement on  a VHDL toolset: are you using Simili and where do I
get it from. Is it Free, is it GPL?

Jeff Davies
eGroups Sponsor
From Jeff Davies Sat Nov 11 02:43:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03251 for ; Sat, 11 Nov 2000 13:42:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:20 +0100 (MET) Received: (qmail 2657 invoked by uid 0); 11 Nov 2000 01:46:20 -0000 Received: from fh.egroups.com (208.50.144.71) by mx19.rz2.gmx.net (mx19) with SMTP; 11 Nov 2000 01:46:20 -0000 X-eGroups-Return: sentto-1101623-1384-973907176-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 11 Nov 2000 01:46:18 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 01:46:16 -0000 Received: (qmail 40520 invoked from network); 11 Nov 2000 01:46:15 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Nov 2000 01:46:15 -0000 Received: from unknown (HELO mail4.svr.pol.co.uk) (195.92.193.211) by mta2 with SMTP; 11 Nov 2000 01:46:15 -0000 Received: from modem-215.indium.dialup.pol.co.uk ([62.136.40.215] helo=tiglath.pileser.sumeria) by mail4.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13uPkD-0005aS-00 for f-cpu@egroups.com; Sat, 11 Nov 2000 01:46:14 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00111101462102.24769@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 01:43:35 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9b73cd5de5ccdf03db859009cf0cbb16 Status: R X-Status: N On Sat, 11 Nov 2000, you wrote:
> I would like to share my thoughts on your concernes...
>
> court.  That is patenting a principal of electronics and as such should
basmati rice was, by an american company,(for 3 years) until it was overturned
a couple of days ago, unfortunately there are 3500 other native plants of
india also patented by the ridiculous american patent office.

> between MS and consumers to be downright abusive. 
I think it's a bit like AMWAY

Jeff Davies
eGroups Sponsor
From Jeff Davies Sat Nov 11 02:14:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03254 for ; Sat, 11 Nov 2000 13:42:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:21 +0100 (MET) Received: (qmail 3336 invoked by uid 0); 11 Nov 2000 01:55:38 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx23) with SMTP; 11 Nov 2000 01:55:38 -0000 X-eGroups-Return: sentto-1101623-1383-973906722-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 11 Nov 2000 01:38:46 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 01:38:41 -0000 Received: (qmail 9723 invoked from network); 11 Nov 2000 01:38:41 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 11 Nov 2000 01:38:41 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta1 with SMTP; 11 Nov 2000 01:38:41 -0000 Received: from modem-159.lithium.dialup.pol.co.uk ([62.136.2.159] helo=tiglath.pileser.sumeria) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13uPcr-00089J-00 for f-cpu@egroups.com; Sat, 11 Nov 2000 01:38:38 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A0C90E8.B8DED9EF@f-cpu.org> In-Reply-To: <3A0C90E8.B8DED9EF@f-cpu.org> Message-Id: <00111101384401.24769@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 01:14:41 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 86388b56ced03b9e54eb62aae00b5b9d Status: R X-Status: N On Sat, 11 Nov 2000, you wrote:
> hi,
>
> > resources of openall.org to help get F-CPU produced and on ATX form factor
> > boards AND get Linux as the main OS for the platform.
YG, I think he means so you can fit it in an ATX case.

> > Things needed for an open source PC:
> forget the word "PC". use "computer" instead :-)
> it might mislead people, because 999/1000 is means x86.
I think Game Console, walkman, and Laptop are better form factors.


> > * CPU (F-CPU)
I had a thought, perhaps F is for foutre (is that how you spell it, as in va
faire t'foutre) 

> > * Linux port0
> glups... anyone ??? nobody ??? ok, later then.
gcc or similar c compiler will make this pretty easy. More difficult without ;)

> > * Open source RAM designs
> kidding ? the big players are fighting with patent infringements trials,
> and you imagine that you can come and change the situation ? it's too
> much technology dependent and the market is not able to see the difference
> anyway...
Hey, my async block transfer idea is better than SDRAM

> a system freeze is a sign that it is bad designed.
True, never seen my Linux box freeze, so this is total overkill.

> > * Foundary services (F-CPU, system chipsets, opensource RAM?)
> production won't be a problem.
I think india/china and such places are stuffed with reasonable quality very
cheap wafer fabs. I have no substantiation for that beleif, perhaps someone
has.

> THAT will be more important.
Selling a few on ebay will probably bring in a big wedge of cash

>
> but you forget a little point : the f-cpu is not ready, and far from
> being synthesisable to silicon. we know some ressources for that,
> but it can't happen before the whole design is stable and running
> common software. don't hurry up, because it's a very slow process.
>
Is anyone working on a C compiler and simulator. Linux could be ported and run
on a simulator with sh or bash. This can be concurrent with Development of FCPU
circuit design [as long a architecture is fixed].

> the problem is less simple than you'd think. it's a whole industry with
> its "mafia", its systems, distributors, funders, financial balances,
> patent mafia etc. At the moment, i believe that we can customize
> SDRAM interfaces for the F-CPU.
Watch out for RAMBUS everyone is paying them royalties for this public domain
idea. I hate the f***g company. The sooner they go out of business the better.


> well, usually, a CPU hangs either because the SW is bad [this happens...]
> or because of a HW reason, which can be either a faulty CPU (altered HW)
> or a board that has been unplugged (or vibrations, or hotswapped).
Perhaps a CRC on blocks of data between CPU and RAM could stop some of this
locking. [and CRC on most interfaces].

> don't dream too much : price is a matter of quantity. Only established
> industrial companies (like IBM, Alcatel, Thomson, whatever, you see the point)
> can produce enough with good margins. that's why it's called an "industry"...

Yes, but I can see umpteen small foundaries in the far east being happy to make
better margins without middlemen selling FCPUs to the Linux community than
selling capacity to cut-throat companies. And the cost of the FCPU will still
probably be low, as there won't be a bunch of sales/marketing/managers driving
around in flash cars to support. (perhaps we should start a collection for them
now).


> remember that Open Source is quite different from Free Software philosophy.
> the F-CPU project is rooted in a "pink FSF utopia" that is slowly coming true.
> releasing sources is not enough, you gotta find the right #free# tools
> that go along. ie for the f-cpu, some files become available because
> we have found a free tool that lets anyone participate. the EDA world is
> still too closed, don't expect miracles. good luck, maybe, but not miracles.

Linux Mandrake 7.1 is a miracle. 7.2 is supposed to be VERY cool.
If you're still using something old like Slackware 3.3 (like I was until
recently), do yourself a favour, Mandrake is BRILLIANT. (despite it being
based on redhat).

>
> >  I can't do it myself so I desire to focus efforts of many groups
> > to a singe point where the purpose is to make a fully open computer.
> the OpenCores groups is more advances at the moment. they have quite a different
> POV but their MIPS-like CPU is already available.

Have you seen the Public design of a car project on www.opencollector.org?
Neat. I'd like an electric one tho.

>
> good luck and regards,
> > Shaun Kruger
> > thekernel@subdimension.com
> WHYGEE

Jeff Davies
eGroups Sponsor
From Ben Franchuk Wed Nov 8 06:12:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03257 for ; Sat, 11 Nov 2000 13:42:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:22 +0100 (MET) Received: (qmail 25561 invoked by uid 0); 11 Nov 2000 02:22:11 -0000 Received: from hi.egroups.com (208.50.99.211) by mx12.rz2.gmx.net (mx12) with SMTP; 11 Nov 2000 02:22:11 -0000 X-eGroups-Return: sentto-1101623-1385-973909326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 11 Nov 2000 02:22:09 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 02:22:05 -0000 Received: (qmail 45278 invoked from network); 11 Nov 2000 02:22:04 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 11 Nov 2000 02:22:04 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 11 Nov 2000 03:23:09 -0000 Received: from jetnet.ab.ca (dialin44.jetnet.ab.ca [207.153.6.44]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA29685 for ; Fri, 10 Nov 2000 19:14:26 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A08E0AC.82BE884A@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 05:12:12 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, W is for Whisky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aacfa799db75b1b63240968788fbb3d5 Status: R X-Status: N Yann Guidon wrote:

> his ideas are really strikingly elegant and useful (who remembers the discussion about POC [pipeline-ordered clocking] ?)

We don't need no stinking PIPLINES here. :)
The truth be known in all the "toy" cpu designs I have done
on paper I have never got a pipeline design to work.

The question I have is how narrow a pipeline can you have before the
delay thru the pipeline registers is more than the logic you want to
compute? The 6 gate limit seems to be a well matched size to the number
of gates in a FF, 4 gates.

> > "No Addressing Modes
> > Not providing any addressing modes is a classic RISC excess: e.g. providing
> > only register indirect addressing,
> >     dest := load( memory[register] )
> >     store( memory[register1] := register2)

what about the ZISC computer - Zero instruction set computer ... no memory
reads or writes, thus super fast.

> before he starts something from scratch, he may look at the
> http://www.opencollector.org site, there are some "ol'good" octal desings...
> but he also wrote in another mail that he liked RISC too, so let's not
> bother :-)

Yep this guy keeps cranking them out. I think he must be waiting for
CORE memory and Low voltage NIXIE TUBES to hit the OPEN SOURCE
design shelves and he will flood the PC market. The 'Lunix' os will be standard
with source in octal on 7 track paper tape.


> > The F-CPU ABI isn't defined yet, but I guess that it will pass function
> > parameters in registers (if possible, depending on the number and size
> > of parameters), and that the callee will save registers to the stack
> > before it uses them (using post-{inc,dec}rement addressing, and a general
> > register as the stack pointer).
> right. That prevents a lot of (slow) memory accesses.


> right. if you compute all the time the same address, there's no point
> using complex addressing. with clean RISC coding habits, it's easy to break
> the complexity of a code into a minimal number of instructions.
> furthermore, the code density decrease as the performance increases.
> we have found a rather good compromise for the f-cpu.

As I am looking at pile doc's here the F-Cpu  does indeed
look to be well thought out.

> is it Ulna or Luna ?...

That is LUNA as in moon, not as in lunatic.

> i guess that we will be able to play with program prefetch logic.
> the protocol is not writen into stone, but the f-cpu is highly based
> on prefetching habits. a jump without prefetch (or a load/store without
> preparation) is slow but necessary because the internal hidden property
> flags are flushed upon task switches, they have to be regenerated upon use.
> we have to let "clumsy" software work as well.

It is not that forth is clumsy it just uses a lot of really short subroutines.
A typical routine is 3 to 8 instructions.

> ok, i see :-) it will be a huge cultural shock for you to use RISC machines,
> but remember that it's finally rather close to what Seymour Cray did with the
> CDC machines, and later the CRAYs :-) back to the 60's-70's...

Regardless of what computer science people teach, I view RISC as a
microcoded machine with all memory as the microcode.

> this is not a real problem. The real problems are bad compilers that churn
> bad codes and inefficient algorithms...

I think bad hardware is the problem behind bad compilers.
As long as we have programs like tiny C and Pascal like teaching compilers
mildly inefficient algorithms will still be around.

>
> > I think a streamlined CPU will result that has a simple CISC instruction set but
> > have a well defined local memory like risc stack register windows for on chip
> > use.
> stack register windows ? argh...
> what you describe is close to the NS32K, i believe (i gotta check my books).
>

> i don't see how the mouse influences the instruction set ... :-)
 
  i=delay; while(i-- && mouse()==down); if(i) do_mouse_drag(); else
   do_mouse_press();

> yup, but now memory is even slower compared to the core.
> more registers means less need to access memory for trivial spills.
> now, you got the point ? :-)

But 77[Octal] registers, my pea-sized brain can't keep track of that
many numbers.-).

> no, i wouldn't say. maybe 15 years (the golden era of the RISC architectures),
> but you don't miss much. you have to catch up, though, but you can learn
> only the interesting things :-)

But I am still catching up from the golden era of TTL designs.

> WHYGEE
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Wed Nov 8 06:21:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03260 for ; Sat, 11 Nov 2000 13:42:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:24 +0100 (MET) Received: (qmail 24464 invoked by uid 0); 11 Nov 2000 02:31:57 -0000 Received: from jj.egroups.com (208.50.144.82) by mx19.rz2.gmx.net (mx19) with SMTP; 11 Nov 2000 02:31:57 -0000 X-eGroups-Return: sentto-1101623-1386-973909909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jj.egroups.com with NNFMP; 11 Nov 2000 02:31:53 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 02:31:49 -0000 Received: (qmail 20466 invoked from network); 11 Nov 2000 02:31:48 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 11 Nov 2000 02:31:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 11 Nov 2000 02:31:48 -0000 Received: from jetnet.ab.ca (dialin44.jetnet.ab.ca [207.153.6.44]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA00278 for ; Fri, 10 Nov 2000 19:24:11 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A08E2F5.85DFFBEA@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0C90E8.B8DED9EF@f-cpu.org> <00111101384401.24769@tiglath.pileser.sumeria> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 05:21:57 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 73759e49e2fda475dc65864ef3400fa1 Status: R X-Status: N Jeff Davies wrote:

> Linux Mandrake 7.1 is a miracle. 7.2 is supposed to be VERY cool.
> If you're still using something old like Slackware 3.3 (like I was until
> recently), do yourself a favour, Mandrake is BRILLIANT. (despite it being
> based on redhat).
>

I want to put a plug in for Debain Lunix,It has one feature
RED-HAT based linux's don't have. You can upgrade over a standard
modem ISP link, most the other linux's require a network card.
***Pats trusty 28.k modem here ***

> Have you seen the Public design of a car project on www.opencollector.org?
> Neat. I'd like an electric one tho.

Steam here!

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Keyshaun Sat Nov 11 06:37:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03269 for ; Sat, 11 Nov 2000 13:42:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:26 +0100 (MET) Received: (qmail 22757 invoked by uid 0); 11 Nov 2000 05:37:33 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx01) with SMTP; 11 Nov 2000 05:37:33 -0000 X-eGroups-Return: sentto-1101623-1387-973921050-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 11 Nov 2000 05:37:31 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 05:37:29 -0000 Received: (qmail 21446 invoked from network); 11 Nov 2000 05:37:29 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Nov 2000 05:37:29 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 11 Nov 2000 06:38:34 -0000 Received: (qmail 28718 invoked from network); 11 Nov 2000 05:37:28 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 11 Nov 2000 05:37:28 -0000 X-Sender: kruger@ultra1.inconnect.com To: f-cpu@egroups.com In-Reply-To: <00111101384401.24769@tiglath.pileser.sumeria> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Nov 2000 22:37:28 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cff2005fd7ed2770ec52bccb1f31fcb5 Status: R X-Status: N

On Sat, 11 Nov 2000, Jeff Davies wrote:

> On Sat, 11 Nov 2000, you wrote:
> > hi,
> >
> > > resources of openall.org to help get F-CPU produced and on ATX form factor
> > > boards AND get Linux as the main OS for the platform.
> YG, I think he means so you can fit it in an ATX case.

This is a correct assumption

> > > * Linux port0
> > glups... anyone ??? nobody ??? ok, later then.
> gcc or similar c compiler will make this pretty easy. More difficult without ;)

Create interest and people will start.  If an F-CPU based system is found
to be a inexpensive yet robust solution people will want it and people
will be interested in developing for it.

>
> > > * Open source RAM designs
> > kidding ? the big players are fighting with patent infringements trials,
> > and you imagine that you can come and change the situation ? it's too
> > much technology dependent and the market is not able to see the difference
> > anyway...
> Hey, my async block transfer idea is better than SDRAM
Can you write me and let me know a little bit about your async block
transfer idea?  It would be nice if you could patent it if only for the
prupose of keeping it from being stolen by the memory "mafia".


> > a system freeze is a sign that it is bad designed.
> True, never seen my Linux box freeze, so this is total overkill.
I have had my Blade3D driver kill my system when switching between X and
the console.  Granted this is a poorly designed driver problem I still
think there is value in having a failsafe that allows the processor to be
reset without killing the system.  Though that specific feature would only
require redirecting the boot init code to something more like SMP init.

>
> > > * Foundary services (F-CPU, system chipsets, opensource RAM?)
> > production won't be a problem.
> I think india/china and such places are stuffed with reasonable quality very
> cheap wafer fabs. I have no substantiation for that beleif, perhaps someone
> has.
>
> > THAT will be more important.
> Selling a few on ebay will probably bring in a big wedge of cash
I like ebay, that is where I got my DEC Alpha.


> >
> > but you forget a little point : the f-cpu is not ready, and far from
> > being synthesisable to silicon. we know some ressources for that,
> > but it can't happen before the whole design is stable and running
> > common software. don't hurry up, because it's a very slow process.
> >
> Is anyone working on a C compiler and simulator. Linux could be ported and run
> on a simulator with sh or bash. This can be concurrent with Development of FCPU
> circuit design [as long a architecture is fixed].
I agree, I don't know how to write it.  I am a programmer, though limited
in skill.  Thus I will work more to find funding and organizing support.

> Yes, but I can see umpteen small foundaries in the far east being happy to make
> better margins without middlemen selling FCPUs to the Linux community than
> selling capacity to cut-throat companies. And the cost of the FCPU will still
> probably be low, as there won't be a bunch of sales/marketing/managers driving
> around in flash cars to support. (perhaps we should start a collection for them
> now).

If you market it, they will come.  This projects doesn't look much like
vapour ware.  that is why it interests me so much as being a possibility
for an open platform.

>
>
> > remember that Open Source is quite different from Free Software philosophy.
> > the F-CPU project is rooted in a "pink FSF utopia" that is slowly coming true.
> > releasing sources is not enough, you gotta find the right #free# tools
> > that go along. ie for the f-cpu, some files become available because
> > we have found a free tool that lets anyone participate. the EDA world is
> > still too closed, don't expect miracles. good luck, maybe, but not miracles.
>
> Linux Mandrake 7.1 is a miracle. 7.2 is supposed to be VERY cool.
> If you're still using something old like Slackware 3.3 (like I was until
> recently), do yourself a favour, Mandrake is BRILLIANT. (despite it being
> based on redhat).
I installed RH 7.  Config files like /etc/bashrc and many others of the
type were all misconfigured.  I spent 2 days trying to get my server setup
then gave up.  I took 2 hours and got Caldera 2.3 doing everything I
wanted it to do.

On a slightly different not.  In thinking about vapour ware where is
IA-64 with it's ugh...  real mode backward compatability.  It has a linux
port and it has only allegedly run.

Shaun Kruger
eGroups Sponsor
From "Toyoaki Sagawa" Sat Nov 11 08:32:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA03272 for ; Sat, 11 Nov 2000 13:42:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 13:42:28 +0100 (MET) Received: (qmail 32294 invoked by uid 0); 11 Nov 2000 07:32:47 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx05) with SMTP; 11 Nov 2000 07:32:47 -0000 X-eGroups-Return: sentto-1101623-1388-973927938-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fj.egroups.com with NNFMP; 11 Nov 2000 07:32:19 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 07:32:17 -0000 Received: (qmail 21711 invoked from network); 11 Nov 2000 07:32:17 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 11 Nov 2000 07:32:17 -0000 Received: from unknown (HELO mail154.nifty.com) (202.248.37.147) by mta3 with SMTP; 11 Nov 2000 08:33:22 -0000 Received: from cfb5 by mail154.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id QAA17396 for ; Sat, 11 Nov 2000 16:32:15 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 16:32:40 +0900 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Prototiping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 89ff25f95538d72ab096b4c9c4391619 Status: R X-Status: N How about it?
http://www.xess.com/prod014.html
if anyone already use it, please let me know.

I plan to buy it(XCV300), and implement Sayuri core.

Toyoaki Sagawa
eGroups Sponsor
From Ben Franchuk Wed Nov 8 09:46:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA03721 for ; Sat, 11 Nov 2000 16:42:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 16:42:09 +0100 (MET) Received: (qmail 27209 invoked by uid 0); 11 Nov 2000 15:22:02 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx05) with SMTP; 11 Nov 2000 15:22:02 -0000 X-eGroups-Return: sentto-1101623-1389-973956117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 11 Nov 2000 15:21:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 15:21:56 -0000 Received: (qmail 40386 invoked from network); 11 Nov 2000 15:21:56 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 11 Nov 2000 15:21:56 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 11 Nov 2000 15:21:55 -0000 Received: from jetnet.ab.ca (dialin39.jetnet.ab.ca [207.153.6.39]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA18652 for ; Sat, 11 Nov 2000 08:14:14 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0912D4.75068F20@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 08:46:12 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f564122043df6a7e423546c7e3dd00f4 Status: R X-Status: N Keyshaun wrote:

> > Hey, my async block transfer idea is better than SDRAM
> Can you write me and let me know a little bit about your async block
> transfer idea?  It would be nice if you could patent it if only for the
> prupose of keeping it from being stolen by the memory "mafia".

I keep all my 0's and 1's locked up at night safe. I can't be of much help
with bus interface ideas as I still favor OPEN COLLECTOR busing.If
I could design memory I would put the Address translation part of the
MMU right on the memory chip. The CPU's MMU would only have a true/false
flag for what is mapped.

> True, never seen my Linux box freeze, so this is total overkill.
> I have had my Blade3D driver kill my system when switching between X and
> the console.

I have had that happen a lot, mostly when I switch the console
for shutdown with CTRL-ALT-DEL. I have had a few X freezes and a
couple thrashing loops with X. But I can backup/restore linux easily
and this happens once or twice a month, compared to daily? with the
OTHER OS.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Sat Nov 11 16:37:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA03727 for ; Sat, 11 Nov 2000 16:42:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 16:42:12 +0100 (MET) Received: (qmail 13449 invoked by uid 0); 11 Nov 2000 15:32:53 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx02) with SMTP; 11 Nov 2000 15:32:53 -0000 X-eGroups-Return: sentto-1101623-1391-973956771-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 11 Nov 2000 15:32:52 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 15:32:51 -0000 Received: (qmail 3043 invoked from network); 11 Nov 2000 15:32:51 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 11 Nov 2000 15:32:51 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 11 Nov 2000 15:32:51 -0000 Received: from f-cpu.org (nas4-175.aub.club-internet.fr [195.36.145.175]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA20278 for ; Sat, 11 Nov 2000 16:32:47 +0100 (MET) Message-ID: <3A0D67C5.EB2480F8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 16:37:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototiping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8c3cc2a7c9a95f2fc53c3ffe240096f3 Status: R X-Status: N hello,

Toyoaki Sagawa wrote:
> How about it?
> http://www.xess.com/prod014.html
> if anyone already use it, please let me know.
AFAIK, there is no proto board available yet.
the problem is the same as the development software :
anybody should be able to use it freely and at the
least cost. but i'm still hopeful, though.

> I plan to buy it(XCV300), and implement Sayuri core.
if you can, don't hesitate. then, you'll speak about it
to the others so we benefit from your experience and errors.


Now that i work for Meta, i can access a large HW
reconfigurable simulation machine. i don't know how to use
it yet and my work is far from developping cores. Anyway,
there is maybe (i'm very careful, i can't raise high hopes)
a possibility to use it for remote design. this is a rather
complex and proprietary machine but it can do some
remarkable things that don't fit in a FPGA. i'll keep the group
informed about my efforts.


i wish you good luck,

> Toyoaki Sagawa
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Nov 11 16:37:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA03733 for ; Sat, 11 Nov 2000 16:42:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 16:42:15 +0100 (MET) Received: (qmail 8085 invoked by uid 0); 11 Nov 2000 15:32:56 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx01) with SMTP; 11 Nov 2000 15:32:56 -0000 X-eGroups-Return: sentto-1101623-1392-973956775-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 11 Nov 2000 15:32:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 15:32:54 -0000 Received: (qmail 3132 invoked from network); 11 Nov 2000 15:32:54 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 11 Nov 2000 15:32:54 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 11 Nov 2000 16:34:00 -0000 Received: from f-cpu.org (nas4-175.aub.club-internet.fr [195.36.145.175]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA18422 for ; Sat, 11 Nov 2000 16:32:50 +0100 (MET) Message-ID: <3A0D67C4.CAF72C91@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> <00111101133600.24769@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 16:37:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] No more architecture wars until FC0 finished please Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5611649570d91fa3da357d5f219a43d9 Status: R X-Status: N hi !

Jeff Davies wrote:
> > > With a .5 ns internal cycle and say a 20ns external memory cycle in the future
> > > bandwidth to external memory will be the limiting factor regardless of the internal
> > > cpu design.
> > yup. the real problem here is the number of pads to the outside memory.
> This is why the idea of a smaller amount of RAM (say 16meg) on chip with the
> CPU, and many of them is a good idea.
As said earlier, it's not a philosophical problem, rather an industrial problem.
eDRAM (embedded DRAM) is fine etc. but there's no standard at the moment.
the capacity, access time, everything will vary from one chip to another.
it's not bad, but it's not practical either.

> Like I've said previously, GNU Hurd is
> now available in it's own distro from Debian. The hurd is supposed to run more
> like an object-messaging system than functions and calling.
> Imagine 20 cpus each with 16meg of RAM (running at 800MHz?) in your laptop......
i'm still thinking about the Convec SPP-1000 that i've seen for sale on comp.sys.super.
dated around 1994, it has 16 100-MHz CPUs with each 256MB. Overall, 4GB of RAM and
4*4GB of SCSI HDD. I would have bought it (if i had money) but it consumes a lot
of current and space. its charm is the high bandwidth memory crossbar.

So your 20*CPUs are nice but don't forget that :
the more you add CPUs, the more mem bw you need. a simple 32-bit or 64-bit interface won't
be enough on each CPU. You get my point ?

in a mail (that i still have to write, sorry), i propose the overall description
of the "G-chip" or "glue chip", or G for short (F being the CPU, ha ha ha :-P)
stay tuned.

> I think there's probably a way to do away with a stack by using a pure message
> based architecture, but I'll have to stroke my chin for a few days thinking
> about it.
i don't catch anything... What do you have in mind ?

> >         If you fit in L1 cache, you ain't supercomputing :-)
> >         --Krste Asanovic <krste@ICSI.Berkeley.EDU>
> Call MS Word supercomputing?
LMAO

> I think the architecture wars have to be called to a halt for a while.
i have seen no "archwar" for a long time. And there was no blood so
i wouldn't call them wars.

> Yes there are good reasons not to use Virtual Memory, but it's not particularly
> hard to support, and people will laugh if we don't include it.
this is exactly the reason why i forced myself to use it.
OTOH, we don't have anything overly complex so we're safe :
everything is done in SW. The HW has been smoothed and simplified to
avoid any scheduling problem. The SW does all the work, just like in
the Alpha :-)

> I think at the
> moment, the target OS is still Linux also, but hey, you can write/port anything
> you want to it. Don't forget there are real time versions of Linux out there
> that you can compile up for FCPU when there's a C compiler for the FCPU.
yup. freedom is also freedom of SW.

> Similarily, if you don;t like FCPU architecture, fine, rip it apart and reuse
> components in your chosen architecture, publish it under GPL, and everyone is
> happy.
yup. Why waste time in discussion when all we want here is a CPU ? :-)

OTOH if we make GOOD compromises, we can make most people happy.

> I missed the agreement on  a VHDL toolset: are you using Simili and where do I
> get it from. Is it Free, is it GPL?
look at the f-cpu websites, there's a link.

short description :
it works under Win32 in a DOS box (command line), a linux port is being done.
it is "free as in free beer", meaning not GPL but the maintainer is ok with
the fact that Simili is used for the F-CPU (it makes some advertising, more
bugs are reported etc). It is very simple to use : straight-forward to install
and no funky command lines. it's compact, the archive uses 3MB (20min at 2.8 kB/s)
and it doesn't create huge binaries. Most of all : it's almost completely VHDL'93 compliant.

there are other things to notice but that's what i remember without checking my archives.
it's available from http://www.symphonyeda.com

Michael Riepe also uses Vanilla HDL under Linux but i don't have tried it. I believe it
can be found at the opencollector.org database.

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Toyoaki Sagawa" Sat Nov 11 16:55:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04393 for ; Sat, 11 Nov 2000 20:39:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:24 +0100 (MET) Received: (qmail 21477 invoked by uid 0); 11 Nov 2000 15:55:45 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx21) with SMTP; 11 Nov 2000 15:55:44 -0000 X-eGroups-Return: sentto-1101623-1393-973958139-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 11 Nov 2000 15:55:41 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 15:55:38 -0000 Received: (qmail 38430 invoked from network); 11 Nov 2000 15:55:36 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Nov 2000 15:55:36 -0000 Received: from unknown (HELO mail154.nifty.com) (202.248.37.147) by mta3 with SMTP; 11 Nov 2000 16:56:41 -0000 Received: from cfb5 by mail154.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id AAA00733 for ; Sun, 12 Nov 2000 00:55:34 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A0D67C5.EB2480F8@f-cpu.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 00:55:59 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7ee3dce5a81903da768b9a5edb18ab95 Status: R X-Status: N Hi,

> > I plan to buy it(XCV300), and implement Sayuri core.
> if you can, don't hesitate. then, you'll speak about it
> to the others so we benefit from your experience and errors.

I will make speech at Linux conference at Kyoto city, 11/30, and hope if
some persons interested in Sayuri.
I think I have to make "Team" who have same board, same source, same
development tool(Xilinx).
Then (we) will buy the board, and starts porting Sayuri core/ implement
peripherals/porting GCC and Linux.
there are many things to enjoy  :-)
(1) run linux with console(RS-232C) only
(2) Keyboard and VGA
(3) USB host driver
(4) Ethernet, Audio in/out, video input
(5) make RAM extention board for XESS

Toyoaki Sagawa
eGroups Sponsor
From Ben Franchuk Wed Nov 8 11:12:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04405 for ; Sat, 11 Nov 2000 20:39:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:27 +0100 (MET) Received: (qmail 712 invoked by uid 0); 11 Nov 2000 16:48:14 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx18) with SMTP; 11 Nov 2000 16:48:14 -0000 X-eGroups-Return: sentto-1101623-1394-973961287-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 11 Nov 2000 16:48:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 16:48:06 -0000 Received: (qmail 1269 invoked from network); 11 Nov 2000 16:48:05 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 11 Nov 2000 16:48:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 11 Nov 2000 16:48:05 -0000 Received: from jetnet.ab.ca (dialin39.jetnet.ab.ca [207.153.6.39]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA22283 for ; Sat, 11 Nov 2000 09:40:24 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A092707.5E5DD03@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> <3A08E0AC.82BE884A@jetnet.ab.ca> <3A0D67C0.5E9FEF5@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 08 Nov 2000 10:12:23 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, W is for Whisky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1107913890ed0411ae0b93f3cf36b4f8 Status: R X-Status: N Yann Guidon wrote:
> > The truth be known in all the "toy" cpu designs I have done
> > on paper I have never got a pipeline design to work.
> "on paper", right ? :-) and what speed could they reach ?

They where SLOW. I am guessing with LS TTL about 250 ns for the
instruction decoding and output of the ram D latch, with about
250 ns for the alu. But since I could never get the memory bus (Open Collector?)
faster than 450ns it was well matched with the cpu.(300ns Dram for 150ns
buffers and delays).I hope to have the schematics done (Isn't CAD great)
over the weekend.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Keyshaun Sat Nov 11 18:06:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04420 for ; Sat, 11 Nov 2000 20:39:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:32 +0100 (MET) Received: (qmail 686 invoked by uid 0); 11 Nov 2000 17:06:24 -0000 Received: from jj.egroups.com (208.50.144.82) by mx11.rz2.gmx.net (mx11) with SMTP; 11 Nov 2000 17:06:24 -0000 X-eGroups-Return: sentto-1101623-1395-973962378-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 11 Nov 2000 17:06:23 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 17:06:18 -0000 Received: (qmail 85904 invoked from network); 11 Nov 2000 17:06:13 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Nov 2000 17:06:13 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta2 with SMTP; 11 Nov 2000 17:06:13 -0000 Received: (qmail 1059 invoked from network); 11 Nov 2000 17:06:12 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 11 Nov 2000 17:06:12 -0000 X-Sender: kruger@ultra1.inconnect.com To: f-cpu@egroups.com In-Reply-To: <3A0D67C4.CAF72C91@f-cpu.org> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 10:06:12 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL docs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 60aaeec9a806d90f6e41c4c82e61c437 Status: R X-Status: N Forgive my inexperience, but where can I get docs on VHDL?  I am rather
interested in how the HW design process goes.  I have studied it much, but
I can only find so much on my own.  I would like to be able to make sense
out of the F-CPU source if I ever try to read it. 

Shaun
eGroups Sponsor
From Yann Guidon Sat Nov 11 18:11:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04423 for ; Sat, 11 Nov 2000 20:39:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:32 +0100 (MET) Received: (qmail 26036 invoked by uid 0); 11 Nov 2000 17:06:40 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx18) with SMTP; 11 Nov 2000 17:06:40 -0000 X-eGroups-Return: sentto-1101623-1397-973962391-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 11 Nov 2000 17:06:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 17:06:31 -0000 Received: (qmail 86477 invoked from network); 11 Nov 2000 17:06:25 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Nov 2000 17:06:25 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 11 Nov 2000 17:06:24 -0000 Received: from f-cpu.org (nas2-231.ras.club-internet.fr [195.36.192.231]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA04123 for ; Sat, 11 Nov 2000 18:06:22 +0100 (MET) Message-ID: <3A0D7DAB.BD3D8306@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 18:11:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 754b37e73119a2d2aa3e0b4407e0826d Status: R X-Status: N hi,
(late answer)

Keyshaun wrote:
> I would like to share my thoughts on your concernes...
>
> F-CPU on ATX.
<snip>
> Linux port of F-CPU.
<snip>
> RAM patents.
<snip>
> The tasking processor.
<snip>
> F-CPU isn't ready.
<snip>
> F-CPU first for hackers.
<snip>
> Last of all...
<snip>
> I started writing to you with the ideal of
> having a truely free platform.  I do use free software as much as
> possible.  When you said there aren't many(if any) good free EDA tools for
> linux I just wanted to make sure you have been following gEDA.  I know it
> isn't ready yet.  I am fully aware of that.  When it is done will it be a
> good suite of tools for you to use?

Ok, this shows that we are on a similar (?) wavelength. Utopia is fine
only because reality is crappy. i wanted to make sure that you were conscious
of some critical points.

Speaking of gEDA, it's maybe "rather advanced" for a "free EDA project".
unfortunately, its use and compilation is still rather heavy, tEDA (Tiny EDA,
the windows port) is much nicer. There is also Electric Editor, but it doesn't
allow a lot of things. It's fine for more advanced stages, mainly synthesis,
but not for early design. Finally, Simili was (IMHO) a good compromise,
and it lets other developpers use their own tools if they have Synopsis,
Cadence etc. Of course, the day when GOOD GNU EDA will be ready, the revolution
will become a reality. before that, we have to cross our fingers and use
strings and crap to make something decent AND free.


> Shaun Kruger
> thekernel@subdimension.com
>
> If it wasn't for the bondage of windows I would never have gone to linux.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Nov 11 18:11:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04426 for ; Sat, 11 Nov 2000 20:39:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:34 +0100 (MET) Received: (qmail 26319 invoked by uid 0); 11 Nov 2000 17:07:09 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx23) with SMTP; 11 Nov 2000 17:07:09 -0000 X-eGroups-Return: sentto-1101623-1396-973962382-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mq.egroups.com with NNFMP; 11 Nov 2000 17:06:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 17:06:22 -0000 Received: (qmail 21757 invoked from network); 11 Nov 2000 17:06:22 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 11 Nov 2000 17:06:22 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 11 Nov 2000 18:07:27 -0000 Received: from f-cpu.org (nas2-231.ras.club-internet.fr [195.36.192.231]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA00808 for ; Sat, 11 Nov 2000 18:06:18 +0100 (MET) Message-ID: <3A0D7DAA.7B79A342@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0C90E8.B8DED9EF@f-cpu.org> <00111101384401.24769@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 18:11:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d05c64e757667d781ef6d56d588e2e9 Status: R X-Status: N hi,

Jeff Davies wrote:
> On Sat, 11 Nov 2000, you wrote:
> > hi,
> >
> > > resources of openall.org to help get F-CPU produced and on ATX form factor
> > > boards AND get Linux as the main OS for the platform.
> YG, I think he means so you can fit it in an ATX case.
ATX is rather nice for PCs (ie, x86 + clones).
using it for the fcpu would be a "bad compromise".
The power unit could be reused, but the overall design
is crappy. really. I have never seen ANY good AT/X box.
the air stream is completly fucked up, the placement of the
different units is "merdique" and the original design in itself
doesn't aspire confidence.

i am conscious that the ATX is the "low cost route towards
acceptance of the product". anyway, it should not be reused as is, if it happens.
that means that the components must not be placed the same way.


> > > Things needed for an open source PC:
> > forget the word "PC". use "computer" instead :-)
> > it might mislead people, because 999/1000 is means x86.
> I think Game Console, walkman, and Laptop are better form factors.
yup, but the power is a critical ressource.

> > > * CPU (F-CPU)
> I had a thought, perhaps F is for foutre (is that how you spell it, as in va
> faire t'foutre)
it's the first time is see this one. it completes nicely the list that was
published recently. but it's only a name... it is cool because it doesn't
need 150 letters to spell it, and it is getting slowly recognized.

> > > * Linux port0
> > glups... anyone ??? nobody ??? ok, later then.
> gcc or similar c compiler will make this pretty easy. More difficult without ;)
see the sourceforge site where Mathias had deposited some sources.
if you want to make a GCC port, it's a good base (even though it's incomplete).

> > > * Foundary services (F-CPU, system chipsets, opensource RAM?)
> > production won't be a problem.
> I think india/china and such places are stuffed with reasonable quality very
> cheap wafer fabs. I have no substantiation for that beleif, perhaps someone has.
i don't know much about india/china. you're certainly right, but they're not
represented in Europe. this might change in the next years though.

> > THAT will be more important.
> Selling a few on ebay will probably bring in a big wedge of cash
probably. imagine : "hey, i own the f-cpu chip #5 and i use it to type this mail",
that will make anyone jealous in some decades ;-)

> Is anyone working on a C compiler and simulator. Linux could be ported and run
> on a simulator with sh or bash. This can be concurrent with Development of FCPU
> circuit design [as long a architecture is fixed].

it can be concurrent with the synthesis, but as long as the VHDL is not ready,
we don't have any working "reference platform".

When the VHDL will be ok, we'll be able to simulate with HW accelerators
if we want speed. META (where i work) is a solution. An array of FPGA
(a big one of big ones) will also do the trick.

To make a C simulator will require some weeks of work when the VHDL of FC0 is done,
but we can't do it before...

> > well, usually, a CPU hangs either because the SW is bad [this happens...]
> > or because of a HW reason, which can be either a faulty CPU (altered HW)
> > or a board that has been unplugged (or vibrations, or hotswapped).
> Perhaps a CRC on blocks of data between CPU and RAM could stop some of this
> locking. [and CRC on most interfaces].
you mean, SEC/DED (single error correction, double error detection) ?
we have had a Verilog source w/ explaining comments on this list. that's useful.

> > don't dream too much : price is a matter of quantity. Only established
> > industrial companies (like IBM, Alcatel, Thomson, whatever, you see the point)
> > can produce enough with good margins. that's why it's called an "industry"...
> Yes, but I can see umpteen small foundaries in the far east being happy to make
> better margins without middlemen selling FCPUs to the Linux community than
> selling capacity to cut-throat companies. And the cost of the FCPU will still
> probably be low, as there won't be a bunch of sales/marketing/managers driving
> around in flash cars to support. (perhaps we should start a collection for them
> now).
that's ok, but can only happen before the design is successful.
if we start an expensive one, it will be tagged as expensive
and it will not attract people.

the OpenCores team has had a proposition form TSMC (IIRC, look at opencollector.org)
to fund one waffer for free. i guess that since it has been done once, other
similar opportunities will appear. that's a really good compromise :-)

> > > Shaun Kruger
> > WHYGEE
> Jeff Davies
WHYGEE again :-)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Nov 11 14:47:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04435 for ; Sat, 11 Nov 2000 20:39:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 11 Nov 2000 20:39:36 +0100 (MET) Received: (qmail 31299 invoked by uid 0); 11 Nov 2000 18:19:46 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx22) with SMTP; 11 Nov 2000 18:19:46 -0000 X-eGroups-Return: sentto-1101623-1398-973964120-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 11 Nov 2000 17:35:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 17:35:20 -0000 Received: (qmail 30597 invoked from network); 11 Nov 2000 17:35:20 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 11 Nov 2000 17:35:20 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.195) by mta2 with SMTP; 11 Nov 2000 17:35:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00608; Sat, 11 Nov 2000 14:47:13 +0100 Message-ID: <20001111144712.02045@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A0C90E8.B8DED9EF@f-cpu.org> <00111101384401.24769@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00111101384401.24769@tiglath.pileser.sumeria>; from Jeff Davies on Sat, Nov 11, 2000 at 01:14:41AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 14:47:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 607a3f52e9406af1d6bf5ea336dabda4 Status: R X-Status: N On Sat, Nov 11, 2000 at 01:14:41AM +0000, Jeff Davies wrote:

[...]
> Is anyone working on a C compiler and simulator. Linux could be ported= and run
> on a simulator with sh or bash. This can be concurrent with Developmen= t of FCPU
> circuit design [as long a architecture is fixed].
[...]

Stop talking, start coding...

People on this list seems to have great ideas, but nobody wants to do
the real work.  There are lots of things to do, and there's no excuse<= BR> for not *trying* to do something useful, at least.  If you don't know<= BR> any programming languages -- time to learn.  You need not grok VHDL (although that's rather easy if you understand the basic concepts of
digital electronics -- took me a week or something like that), but C
would be fine.  Or start reading the GCC Manual, find out how to port<= BR> the compiler to a new platform and start writing a machine description
for the F-CPU.  Someone can do the compiler, someone else the GAS port= ,
an emulator and so on.  The F-CPU ISA is stable enough to be used as a=
base for it, so there's no need to wait.

You can't gain experience by talking about something, or by watching
somebody else doing something.  And you won't have fun that way, eithe= r.

I joined this project less than two months ago, after reading the
mailing list archive, because I felt that most of you needed a kick in
the <you-know-what>.  And I will kick you, again and again, soft= ly, until
you start *doing* something (or I become too tired ;), no matter what
(except those of you who don't need a kick, of course -- you know who).

Note to german readers:  Von Euch h=E4tte ich auch mehr erwartet als n= ur
einen Verein zu gr=FCnden und sich dann zur=FCckzulehnen und zuzugucken. Was macht Ihr eigentlich, warten da=DF die H=F6lle zufriert?

C U on the bazaar,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D""
From Yann Guidon Sat Nov 11 22:32:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00339 for ; Sun, 12 Nov 2000 14:55:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:55:57 +0100 (MET) Received: (qmail 18307 invoked by uid 0); 11 Nov 2000 21:27:35 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 11 Nov 2000 21:27:35 -0000 X-eGroups-Return: sentto-1101623-1399-973978046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 11 Nov 2000 21:27:32 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 21:27:26 -0000 Received: (qmail 51643 invoked from network); 11 Nov 2000 21:27:25 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 11 Nov 2000 21:27:25 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 11 Nov 2000 21:27:25 -0000 Received: from f-cpu.org (nas3-117.aub.club-internet.fr [195.36.145.117]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA21422 for ; Sat, 11 Nov 2000 22:27:21 +0100 (MET) Message-ID: <3A0DBADB.46CC4D6F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> <3A08E0AC.82BE884A@jetnet.ab.ca> <3A0D67C0.5E9FEF5@f-cpu.org> <3A092707.5E5DD03@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 22:32:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Is F for Foobar, W is for Whisky? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 93510630d3d7641961e3294a91be795e Status: R X-Status: N hi,

Ben Franchuk wrote:
> Yann Guidon wrote:
> > > The truth be known in all the "toy" cpu designs I have done
> > > on paper I have never got a pipeline design to work.
> > "on paper", right ? :-) and what speed could they reach ?
>
> They where SLOW. I am guessing with LS TTL about 250 ns for the
> instruction decoding and output of the ram D latch, with about
> 250 ns for the alu. But since I could never get the memory bus (Open Collector?)
> faster than 450ns it was well matched with the cpu.(300ns Dram for 150ns
> buffers and delays).I hope to have the schematics done (Isn't CAD great)
> over the weekend.

that will be a nice addition to the Utopia Computing Webring :-)

have fun,
> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Nov 11 22:32:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00342 for ; Sun, 12 Nov 2000 14:55:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:55:58 +0100 (MET) Received: (qmail 18334 invoked by uid 0); 11 Nov 2000 21:27:36 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 11 Nov 2000 21:27:36 -0000 X-eGroups-Return: sentto-1101623-1400-973978051-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 11 Nov 2000 21:27:34 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 21:27:30 -0000 Received: (qmail 83982 invoked from network); 11 Nov 2000 21:27:30 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Nov 2000 21:27:30 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 11 Nov 2000 21:27:30 -0000 Received: from f-cpu.org (nas3-117.aub.club-internet.fr [195.36.145.117]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA25788 for ; Sat, 11 Nov 2000 22:27:28 +0100 (MET) Message-ID: <3A0DBADD.C4E3B8EA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 22:32:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 510a6f81ea53f618668762101b8baa79 Status: R X-Status: N hello,

Toyoaki Sagawa wrote:
> Hi,
>
> > > I plan to buy it(XCV300), and implement Sayuri core.
> > if you can, don't hesitate. then, you'll speak about it
> > to the others so we benefit from your experience and errors.
>
>  I will make speech at Linux conference at Kyoto city, 11/30, and hope if
> some persons interested in Sayuri.
i'm sure it will be fruitful. Don't hesitate to send a notice on the
opencollector database and send us a transcript or a report of your
presentation.

>  I think I have to make "Team" who have same board, same source, same
> development tool(Xilinx).
that's wise, indeed :-)

Xilinx, who uses them here ? Wasn't Robert (Erin Greene) using them ?
i think that someone at Xilinks was subscribed here. Don't hesitate to
search in the mailing list archive.

>  Then (we) will buy the board, and starts porting Sayuri core/ implement
> peripherals/porting GCC and Linux.  there are many things to enjoy  :-)
> (1) run linux with console(RS-232C) only
> (2) Keyboard and VGA
> (3) USB host driver
> (4) Ethernet, Audio in/out, video input
> (5) make RAM extention board for XESS

good luck and have fun,

> Toyoaki Sagawa
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Michael Riepe Sat Nov 11 18:46:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00345 for ; Sun, 12 Nov 2000 14:55:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:55:58 +0100 (MET) Received: (qmail 8730 invoked by uid 0); 11 Nov 2000 23:31:00 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx22) with SMTP; 11 Nov 2000 23:31:00 -0000 X-eGroups-Return: sentto-1101623-1401-973985456-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 11 Nov 2000 23:30:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 11 Nov 2000 23:30:55 -0000 Received: (qmail 30836 invoked from network); 11 Nov 2000 23:30:55 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 11 Nov 2000 23:30:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.78) by mta1 with SMTP; 11 Nov 2000 23:30:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01412; Sat, 11 Nov 2000 18:46:52 +0100 Message-ID: <20001111184652.03200@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <8uen8f+p78f@eGroups.com> <001901c04a9e$6a84cc30$29e65982@student.utwente.nl> <3A0C90E5.6D1BCAE6@f-cpu.org> <00111101133600.24769@tiglath.pileser.sumeria> <3A0D67C4.CAF72C91@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A0D67C4.CAF72C91@f-cpu.org>; from Yann Guidon on Sat, Nov 11, 2000 at 04:37:40PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 18:46:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] No more architecture wars until FC0 finished please Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 74ca92aaebaff719438f80bb4388eeeb Status: R X-Status: N On Sat, Nov 11, 2000 at 04:37:40PM +0100, Yann Guidon wrote:

[...]
> in a mail (that i still have to write, sorry), i propose the overall description
> of the "G-chip" or "glue chip", or G for short (F being the CPU, ha ha ha :-P)
> stay tuned.

After all these lower-case `e's (as in e-Mail, e-Commerce, e-Business,
e-Whatever) it was certainly time to e-Xplore the rest of the alphabet ;)

[...]
> Michael Riepe also uses Vanilla HDL under Linux but i don't have tried it. I believe it
> can be found at the opencollector.org database.

Vanilla VHDL is located at http://www.freehdl.seul.org/

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Colin Marquardt Sun Nov 12 01:45:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00360 for ; Sun, 12 Nov 2000 14:56:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:03 +0100 (MET) Received: (qmail 12070 invoked by uid 0); 12 Nov 2000 01:14:54 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx07) with SMTP; 12 Nov 2000 01:14:54 -0000 X-eGroups-Return: sentto-1101623-1402-973991688-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 12 Nov 2000 01:14:49 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 01:14:48 -0000 Received: (qmail 53624 invoked from network); 12 Nov 2000 01:14:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Nov 2000 01:14:47 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta2 with SMTP; 12 Nov 2000 01:14:47 -0000 Received: from morphin.marquardt-home.de (d95.nas21.sonic.net [209.204.136.95]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id CAA00806 for ; Sun, 12 Nov 2000 02:14:45 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 13ulH9-0000vG-00 for ; Sat, 11 Nov 2000 16:45:39 -0800 To: f-cpu@egroups.com References: <3A0C4720.1AED46F9@llandre.freeserve.co.uk> X-Now-Playing: track_03 In-Reply-To: Jeff Davies's message of "Fri, 10 Nov 2000 19:06:09 +0000" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 11 Nov 2000 16:45:39 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] A picture of xeena editing a program in fcpu program dtd for xml Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 53471a7ca77f27fce73148a4e9233c1b Status: R X-Status: N Jeff Davies <jeff@llandre.freeserve.co.uk> writes:

> Apparently Csharp "is the first programming language with markup for
> documentation right there in the code"
>
> I must have been imagining the code I have often seen with HTML in it.

And perl. And all of Knuth's Literate Programming stuff, like cweb.

Colin
eGroups Sponsor
From Jeff Davies Sun Nov 12 02:06:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00363 for ; Sun, 12 Nov 2000 14:56:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:04 +0100 (MET) Received: (qmail 12209 invoked by uid 0); 12 Nov 2000 01:17:10 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx21) with SMTP; 12 Nov 2000 01:17:10 -0000 X-eGroups-Return: sentto-1101623-1403-973991828-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by c3.egroups.com with NNFMP; 12 Nov 2000 01:17:09 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 01:17:08 -0000 Received: (qmail 22756 invoked from network); 12 Nov 2000 01:17:08 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Nov 2000 01:17:08 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta2 with SMTP; 12 Nov 2000 01:17:07 -0000 Received: from modem-20.seaborgium.dialup.pol.co.uk ([62.136.73.20] helo=tiglath.pileser.sumeria) by mail3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ullZ-0003EW-00 for f-cpu@egroups.com; Sun, 12 Nov 2000 01:17:05 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <8uen8f+p78f@eGroups.com> <00111101133600.24769@tiglath.pileser.sumeria> <3A0D67C4.CAF72C91@f-cpu.org> In-Reply-To: <3A0D67C4.CAF72C91@f-cpu.org> Message-Id: <00111201170200.05129@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 01:06:38 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] No more architecture wars until FC0 finished please Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee08f89f99aa3f8fb20245f38ebd3f47 Status: R X-Status: N On Sat, 11 Nov 2000, you wrote:
> hi !
>

> > Like I've said previously, GNU Hurd is
> > now available in it's own distro from Debian. The hurd is supposed to run more
> > like an object-messaging system than functions and calling.
> > Imagine 20 cpus each with 16meg of RAM (running at 800MHz?) in your laptop......
> i'm still thinking about the Convec SPP-1000 that i've seen for sale on comp.sys.super.
> dated around 1994, it has 16 100-MHz CPUs with each 256MB. Overall, 4GB of RAM and
> 4*4GB of SCSI HDD. I would have bought it (if i had money) but it consumes a lot
> of current and space. its charm is the high bandwidth memory crossbar.
>
I guess the 256Meg of ram wasn't on-chip with the cpu?

> So your 20*CPUs are nice but don't forget that :
> the more you add CPUs, the more mem bw you need. a simple 32-bit or 64-bit interface won't
> be enough on each CPU. You get my point ?

In terms of an application utilising it to it's max, the memory bandwidth
will be 20 times the memory bandwidth of one cpu.
At worst, like all machines, you'll run out of VM, and run at hard disk speed.

What if you make the CPU very simple and very very wide also (how easy is it to
have 2000 bit databus on an ASIC?)

Current isn't a problem - low load, sleep or turn off cpus!!

> > I think there's probably a way to do away with a stack by using a pure message
> > based architecture, but I'll have to stroke my chin for a few days thinking
> > about it.
> i don't catch anything... What do you have in mind ?

Sort of like a message passing to a subroutine object, and somehow being
associated by the thread executing the subroutine, then a message passing back
un-freezing the thread in the calling object. (or so)


> look at the f-cpu websites, there's a link.
doh!

> and it doesn't create huge binaries. Most of all : it's almost completely VHDL'93 compliant.
I will get it very very soon.

Jeff Davies
eGroups Sponsor
From Jeff Davies Sun Nov 12 02:24:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00366 for ; Sun, 12 Nov 2000 14:56:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:04 +0100 (MET) Received: (qmail 14394 invoked by uid 0); 12 Nov 2000 01:27:59 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx22) with SMTP; 12 Nov 2000 01:27:59 -0000 X-eGroups-Return: sentto-1101623-1404-973992472-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c9.egroups.com with NNFMP; 12 Nov 2000 01:27:58 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 01:27:52 -0000 Received: (qmail 89626 invoked from network); 12 Nov 2000 01:27:49 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Nov 2000 01:27:49 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta3 with SMTP; 12 Nov 2000 02:28:55 -0000 Received: from modem-20.seaborgium.dialup.pol.co.uk ([62.136.73.20] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13ulvu-00002w-00 for f-cpu@egroups.com; Sun, 12 Nov 2000 01:27:46 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <00111101384401.24769@tiglath.pileser.sumeria> <3A0D7DAA.7B79A342@f-cpu.org> In-Reply-To: <3A0D7DAA.7B79A342@f-cpu.org> Message-Id: <00111201274301.05129@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 01:24:15 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 43befd1bdf46b626b101988ae8d7d02f Status: R X-Status: N > > Perhaps a CRC on blocks of data between CPU and RAM could stop some of this
> > locking. [and CRC on most interfaces].
> you mean, SEC/DED (single error correction, double error detection) ?
> we have had a Verilog source w/ explaining comments on this list. that's useful.
Nope, I mean error checking on a block of words transferred from RAM to Cache,
not per word. Error condition will cause retransmit. Too many, cause exception.

Jeff Davies
eGroups Sponsor
From Jeff Davies Sun Nov 12 02:29:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00369 for ; Sun, 12 Nov 2000 14:56:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:05 +0100 (MET) Received: (qmail 16147 invoked by uid 0); 12 Nov 2000 01:32:50 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx23) with SMTP; 12 Nov 2000 01:32:50 -0000 X-eGroups-Return: sentto-1101623-1405-973992769-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 12 Nov 2000 01:32:50 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 01:32:48 -0000 Received: (qmail 6970 invoked from network); 12 Nov 2000 01:32:48 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Nov 2000 01:32:48 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta1 with SMTP; 12 Nov 2000 01:32:48 -0000 Received: from modem-20.seaborgium.dialup.pol.co.uk ([62.136.73.20] helo=tiglath.pileser.sumeria) by mail3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13um0k-0004Hd-00 for f-cpu@egroups.com; Sun, 12 Nov 2000 01:32:46 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <00111101384401.24769@tiglath.pileser.sumeria> <20001111144712.02045@thrai.stud.uni-hannover.de> In-Reply-To: <20001111144712.02045@thrai.stud.uni-hannover.de> Message-Id: <00111201324302.05129@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 01:29:30 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a5375ae244a1f8cd8013d91b05d1795e Status: R X-Status: N On Sat, 11 Nov 2000, you wrote:
> On Sat, Nov 11, 2000 at 01:14:41AM +0000, Jeff Davies wrote:
>
> [...]
> > Is anyone working on a C compiler and simulator. Linux could be ported and run
> > on a simulator with sh or bash. This can be concurrent with Development of FCPU
> > circuit design [as long a architecture is fixed].
> [...]
>
> Stop talking, start coding...
>
You misunderstand. I was asking if anyone was working on these since I seem to
remember Downie or someone on the french list saying something like, "I am
working on one... it will be ready soon".
BTW I did send in some VHDL 1.5 years ago.

What I really need is access to a CVS server, before any cries of RTFM, I'm off
to the web site to look for links to CVS server. Was this set up?

Jeff Davies.
eGroups Sponsor
From Alan Grimes Sun Nov 12 04:29:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00372 for ; Sun, 12 Nov 2000 14:56:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:06 +0100 (MET) Received: (qmail 21610 invoked by uid 0); 12 Nov 2000 03:30:16 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx22) with SMTP; 12 Nov 2000 03:30:16 -0000 X-eGroups-Return: sentto-1101623-1406-973999807-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hh.egroups.com with NNFMP; 12 Nov 2000 03:30:11 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 03:30:05 -0000 Received: (qmail 6348 invoked from network); 12 Nov 2000 03:30:05 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 12 Nov 2000 03:30:05 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta3 with SMTP; 12 Nov 2000 04:31:11 -0000 Received: from 216-164-136-129.s129.tnt4.lnhva.md.dialup.rcn.com ([216.164.136.129] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 13unqG-000518-00 for f-cpu@egroups.com; Sat, 11 Nov 2000 22:30:04 -0500 Message-ID: <3A0E0E91.75444287@starpower.net> Organization: Nanosoft: Software That Thinks X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Nov 2000 22:29:21 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b2d9249a84c6d0619cc9e3fecca78fb6 Status: R X-Status: N 2000 bits? Yer out of yer mind! =P

But it does point to a potentially usefull concept. That of a vairable
wordlength... I mean there needs to be something better than using a full
word for a boolean! =P

--
Meept: The ultimate Phlisophy.

http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unabomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers fbi chemical weapons twa 800 roswell terrorist freedom
eGroups Sponsor
From Ben Franchuk Sun Nov 12 05:34:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00375 for ; Sun, 12 Nov 2000 14:56:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:07 +0100 (MET) Received: (qmail 20796 invoked by uid 0); 12 Nov 2000 04:10:39 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net (mx19) with SMTP; 12 Nov 2000 04:10:39 -0000 X-eGroups-Return: sentto-1101623-1407-974002207-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 12 Nov 2000 04:10:09 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 04:10:06 -0000 Received: (qmail 92192 invoked from network); 12 Nov 2000 04:10:05 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Nov 2000 04:10:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 12 Nov 2000 04:10:03 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA25599 for ; Sat, 11 Nov 2000 21:02:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0E1DCF.961EF47@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E0E91.75444287@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 04:34:23 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: decfe3bd6147f1a4eae49c501f9147ca Status: R X-Status: N Alan Grimes wrote:
>
> 2000 bits? Yer out of yer mind! =P
Better make it 2048 bits ... a nice even power of 2.
84 pins is the limit of cheap sockets.
Somewhere around 200 pins things like sockets get to be real pricy.
40 pin dip  $1.50 cheap
84 pin PLCC $1.75 cheap
273 pin Pin Grid array $20.00 12 cents a pin
196 pin PQFP $50.00 ... 25 cents a pin
6144 pin ****  $6,114  ... 100 cents a pin

> But it does point to a potentially usefull concept. That of a vairable
> wordlength... I mean there needs to be something better than using a full
> word for a boolean! =P

Some people like -1 as true rather than 1, thus a full word is needed.

> --
> Meept: The ultimate Phlisophy.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Sun Nov 12 05:15:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00378 for ; Sun, 12 Nov 2000 14:56:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:07 +0100 (MET) Received: (qmail 13107 invoked by uid 0); 12 Nov 2000 04:10:56 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx23) with SMTP; 12 Nov 2000 04:10:56 -0000 X-eGroups-Return: sentto-1101623-1408-974002251-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 12 Nov 2000 04:10:55 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 04:10:51 -0000 Received: (qmail 21253 invoked from network); 12 Nov 2000 04:10:50 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 12 Nov 2000 04:10:50 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 12 Nov 2000 04:10:49 -0000 Received: from f-cpu.org (nas3-37.ras.club-internet.fr [195.36.203.37]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA05262 for ; Sun, 12 Nov 2000 05:10:47 +0100 (MET) Message-ID: <3A0E1967.8C1E3A67@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 05:15:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL docs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e945cde12345ca780325b343f09e7df2 Status: R X-Status: N hello,

Keyshaun wrote:
> Forgive my inexperience, but where can I get docs on VHDL?  I am rather
> interested in how the HW design process goes.  I have studied it much, but
> I can only find so much on my own.  I would like to be able to make sense
> out of the F-CPU source if I ever try to read it.

trying to understand the f-cpu sources isn't very difficult if you know
how to program in a usual langage, VHDL comes from ADA which is inherited
>from Pascal. that is to say that it's easier to learn than C :-)

I have found several ressources online. You can also see the examples
provided with the free VHDL SW around (Simili as well as others like FreeHDL)
look at the opencollector database.

A good starting point is to read the comp.lang.vhdl FAQ. it will give you
a good overview on the langage and the tools.

there were some URLs posted to the mailing list.
a good Net search will do wonders, too. from my bookmarks :

http://www.atl.external.lmco.com/rassp/vgui/ generates VHDL from block diagrams
(the output must be cleaned, though)
http://www.symphonyeda.com/_vti_bin/shtml.exe/proddownloads.htm to d/l Simili
http://tech-www.informatik.uni-hamburg.de/vhdl/ : Hamburg VHDL archive
ftp://poppy.snu.ac.kr/pub/vhdl/ (a rather huge VHDL suite, but very heavy)
http://www.micron.com/mti/msp/models/index.html : VHDL models of memories
http://www.tu-chemnitz.de/~rsie/vhdlpp_project/index.html (?)
http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html
http://www.estec.esa.nl/wsmwww/leon/
http://mikro.e-technik.uni-ulm.de/vhdl/vhdl_infos.html
http://mikro.e-technik.uni-ulm.de/vhdl/vhdl_simulators.html
http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/
http://mikro.e-technik.uni-ulm.de/vhdl/vhdl_utilities.html
http://tech-www.informatik.uni-hamburg.de/vhdl/tools/grammar/vhdl93-bnf.html#selected_name
http://www.cedcc.psu.edu/ee497f/rassp_13/index.htm
http://www.eej.ulst.ac.uk/tutor/link.html
http://www.eej.ulst.ac.uk/tutor/tutor.html
http://www.fujitsu.co.jp/hypertext/Products/Device/CATALOG/AD05/VHDL/index_e.html
http://www.it.dtu.dk/~c958307/49280_lab/examples/index.html
http://www.sigda.acm.org/Archives/NewsGroupArchives/comp.lang.vhdl/Jan2000/
http://www.symphonyeda.com/Doc/vhdl93_readme.htm

there's no miracle though : buy some good books and meet people that can help you.
i thank Nicolas Boulay for "holding my hand", lending a book and giving advices.

hope this helps,
> Shaun
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Nov 12 05:19:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00381 for ; Sun, 12 Nov 2000 14:56:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:09 +0100 (MET) Received: (qmail 1059 invoked by uid 0); 12 Nov 2000 04:14:24 -0000 Received: from fh.egroups.com (208.50.144.71) by mx12.rz2.gmx.net (mx12) with SMTP; 12 Nov 2000 04:14:24 -0000 X-eGroups-Return: sentto-1101623-1409-974002460-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fh.egroups.com with NNFMP; 12 Nov 2000 04:14:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 04:14:20 -0000 Received: (qmail 2234 invoked from network); 12 Nov 2000 04:14:20 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 12 Nov 2000 04:14:20 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 12 Nov 2000 05:15:25 -0000 Received: from f-cpu.org (nas3-37.ras.club-internet.fr [195.36.203.37]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA16204 for ; Sun, 12 Nov 2000 05:14:17 +0100 (MET) Message-ID: <3A0E1A35.141B55BC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 05:19:01 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4dd412b262fd4b413de2681a46cedcd Status: R X-Status: N hello,
i have uploaded a draft for the G-chip (sort of 'chipset' but better)
at http://www.f-cpu.de/g-chip/

i hope that you'll have helpful remarks. it also explains why i don't
seem to like the usual PC standards. there is also a redesign proposal
for the F-bus.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Ben Franchuk Sun Nov 12 05:49:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00384 for ; Sun, 12 Nov 2000 14:56:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:09 +0100 (MET) Received: (qmail 22207 invoked by uid 0); 12 Nov 2000 04:25:24 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx05) with SMTP; 12 Nov 2000 04:25:24 -0000 X-eGroups-Return: sentto-1101623-1410-974003121-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by f19.egroups.com with NNFMP; 12 Nov 2000 04:25:22 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 04:25:21 -0000 Received: (qmail 26885 invoked from network); 12 Nov 2000 04:25:21 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Nov 2000 04:25:21 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 12 Nov 2000 04:25:20 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA26409 for ; Sat, 11 Nov 2000 21:17:34 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0E2165.484C53F@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 04:49:41 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2d514b24d6e930576b1bc61da35e44fd Status: R X-Status: N Yann Guidon wrote:
>
> hello,
> i have uploaded a draft for the G-chip (sort of 'chipset' but better)
> at http://www.f-cpu.de/g-chip/

Is the HTML working right , all I get is 1 image?
Ben.
PS.Now if F is the fun chip is this the Gay (as in happy) chip.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Sun Nov 12 06:03:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00387 for ; Sun, 12 Nov 2000 14:56:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:10 +0100 (MET) Received: (qmail 20218 invoked by uid 0); 12 Nov 2000 04:38:52 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx18) with SMTP; 12 Nov 2000 04:38:52 -0000 X-eGroups-Return: sentto-1101623-1411-974003929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 12 Nov 2000 04:38:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 04:38:48 -0000 Received: (qmail 70581 invoked from network); 12 Nov 2000 04:38:48 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Nov 2000 04:38:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 12 Nov 2000 04:38:47 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA26920 for ; Sat, 11 Nov 2000 21:30:56 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0E2488.C8134F5@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 05:03:04 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8c299c489eb96e776219c7a9213edebe Status: R X-Status: N Yann Guidon wrote:
>
> hello,
> i have uploaded a draft for the G-chip (sort of 'chipset' but better)
> at http://www.f-cpu.de/g-chip/
Arg... Something got lost the the first few tries, the web page is finaly
loading now.Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Sun Nov 12 06:43:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00397 for ; Sun, 12 Nov 2000 14:56:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:12 +0100 (MET) Received: (qmail 18625 invoked by uid 0); 12 Nov 2000 05:38:24 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx10) with SMTP; 12 Nov 2000 05:38:24 -0000 X-eGroups-Return: sentto-1101623-1412-974007502-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 12 Nov 2000 05:38:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 05:38:20 -0000 Received: (qmail 16546 invoked from network); 12 Nov 2000 05:38:20 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 12 Nov 2000 05:38:20 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 12 Nov 2000 06:39:25 -0000 Received: from f-cpu.org (nas3-44.ras.club-internet.fr [195.36.203.44]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA13315 for ; Sun, 12 Nov 2000 06:38:17 +0100 (MET) Message-ID: <3A0E2DE9.F90AC9C7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2488.C8134F5@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 06:43:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5b4340f13fb55a345ed143ab6a248d4a Status: R X-Status: N hi,

ok, i'm too tired to play the funny names games... i gotta sleep....

Ben Franchuk wrote:
> Yann Guidon wrote:
> > hello,
> > i have uploaded a draft for the G-chip (sort of 'chipset' but better)
> > at http://www.f-cpu.de/g-chip/
> Arg... Something got lost the the first few tries, the web page is finaly
> loading now.Ben.
ok, hope you like. please comment and help.

the propositions i have made are using technologies that are possible,
they have a similar technology where i work, but with a completely
different architecture. packaging, algos and routing are easily possible,
the rest can be done in VDL. Synthesis will be the tough part, as always.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Ben Franchuk Sun Nov 12 08:05:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00402 for ; Sun, 12 Nov 2000 14:56:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:12 +0100 (MET) Received: (qmail 26611 invoked by uid 0); 12 Nov 2000 06:41:38 -0000 Received: from jk.egroups.com (208.50.144.83) by mx12.rz2.gmx.net (mx12) with SMTP; 12 Nov 2000 06:41:38 -0000 X-eGroups-Return: sentto-1101623-1413-974011291-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 12 Nov 2000 06:41:32 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 06:41:30 -0000 Received: (qmail 76167 invoked from network); 12 Nov 2000 06:41:30 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Nov 2000 06:41:30 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 12 Nov 2000 07:42:35 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id XAA02007 for ; Sat, 11 Nov 2000 23:33:43 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0E414F.6F0B4C33@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2488.C8134F5@jetnet.ab.ca> <3A0E2DE9.F90AC9C7@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 07:05:52 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] G-chip draft - cache and bus considerations Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 510a1a36a70de201df2df37e4115de29 Status: R X-Status: N Quickly looking at the G-chip specs, I notice you have a burst up to 32
words? for the cache.All the programs I can think of is too random of
program data for this large a cache. Hopeing to find more information
on this I did a search on the for "memory cache". While I did not find
any more information on how to estimate typical cache sizes, I did find this
link on a fast risc (1GHZ+)
http://inp.cie.rpi.edu/~cmaier/phdthesis/PhD_Dissertation.html
I hope it may be of some use. Ben.
PS.Anybody got a program to estimate static sizes needed for a cache?
I can run thru linux source?
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Keyshaun Sun Nov 12 08:40:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00405 for ; Sun, 12 Nov 2000 14:56:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:13 +0100 (MET) Received: (qmail 4110 invoked by uid 0); 12 Nov 2000 07:41:19 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx22) with SMTP; 12 Nov 2000 07:41:19 -0000 X-eGroups-Return: sentto-1101623-1414-974014866-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fk.egroups.com with NNFMP; 12 Nov 2000 07:41:08 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 07:41:06 -0000 Received: (qmail 13344 invoked from network); 12 Nov 2000 07:41:05 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 12 Nov 2000 07:41:05 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 12 Nov 2000 08:42:11 -0000 Received: (qmail 3261 invoked from network); 12 Nov 2000 07:40:48 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 12 Nov 2000 07:40:48 -0000 X-Sender: kruger@ultra1.inconnect.com To: f-cpu@egroups.com In-Reply-To: <3A0E1DCF.961EF47@jetnet.ab.ca> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 00:40:48 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b78ac39480cbc33b4d7211e98958c393 Status: R X-Status: N

On Sun, 12 Nov 2000, Ben Franchuk wrote:

> Alan Grimes wrote:
> >
> > 2000 bits? Yer out of yer mind! =P
> Better make it 2048 bits ... a nice even power of 2.
> 84 pins is the limit of cheap sockets.
> Somewhere around 200 pins things like sockets get to be real pricy.
> 40 pin dip  $1.50 cheap
> 84 pin PLCC $1.75 cheap
> 273 pin Pin Grid array $20.00 12 cents a pin
> 196 pin PQFP $50.00 ... 25 cents a pin
> 6144 pin ****  $6,114  ... 100 cents a pin

Not to point out proprietary systems, but the AS/400 processor (Power PC
based) has 1500 pins.  (2)256 databusses (4)128 bit addressbusses and 512
signal or power pins.  I like that setup, the system has much memory
bandwidth.  It uses more signals instead of higher Mhz (< 60)

Shaun
eGroups Sponsor
From Nicolas Boulay Sun Nov 12 12:44:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00430 for ; Sun, 12 Nov 2000 14:56:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 14:56:20 +0100 (MET) Received: (qmail 25653 invoked by uid 0); 12 Nov 2000 11:42:43 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx04) with SMTP; 12 Nov 2000 11:42:43 -0000 X-eGroups-Return: sentto-1101623-1415-974029358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ck.egroups.com with NNFMP; 12 Nov 2000 11:42:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 11:42:38 -0000 Received: (qmail 28417 invoked from network); 12 Nov 2000 11:42:37 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 12 Nov 2000 11:42:37 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 12 Nov 2000 11:42:37 -0000 Received: from ifrance.com (nas24-218.vlt.club-internet.fr [195.36.223.218]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA10947 for ; Sun, 12 Nov 2000 12:42:32 +0100 (MET) Message-ID: <3A0E82B1.9E09254F@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 12:44:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c8d457ffa7ed7efffcb268a884b1114a Status: R X-Status: N The most advanced GPL cpu is the Leon from the ESA. It's a sparc like.
It is provided with its gcc port, a simulator and all what you need in
VHDL. The internal buses is the Amba one. A port of =B5linux is in a good way (work only in kernel mode). You can compile the chip with many
differents tools. And it is running in a xv300 board.

Sincerly,
nicO

Keyshaun a =E9crit :
>
> Hi, I'm in the process of getting a website setup for the furtherment = of
> Open source and other Open movements in general.  The website is<= BR> > Openall.org, don't try going there yet I don't have it setup with my > providor yet.  The purpose of openall.org is to raise money for o= pen
> source projects.  All projects must have a goal and focus.  = The goal and
> focus for the money raised by openall.org is to create a fully open so= urce
> platform.  I come to you because I believe the F-CPU to be the mo= st mature
> project that has an "open source" CPU.  I would like to= use most of the
> resources of openall.org to help get F-CPU produced and on ATX form fa= ctor
> boards AND get Linux as the main OS for the platform.
>
> Now to break it down.
>
> Things needed for an open source PC:
> * CPU (F-CPU)
> * System chipsets
> * Linux port
> -- options that would be nice
> * Open source RAM designs
> * 64bit open standards bus interface (less probable)
> * System designed with tasking processor that handles memory managemen= t
>         and task management (c= an be used to make system non-lockable)
>
> Resources needed to obtain these:
> * Foundary services (F-CPU, system chipsets, opensource RAM?)
> * Money for prototypes
> * People to work on the Linux port, distribution, and hardware
>
> I would now like to discuss the subject of the open source RAM I have<= BR> > suggested.  I don't know who is going to design it.  I'm sur= e that people
> can be found.  I personally called to get prices on Micron memory= chips
> directly from a top level distributor.  I discovered that the hig= h price
> of memory comes directly from the manufacturer.  It distrubs me t= hat two
> chips that are only distinguishable by a number can have prices so
> different.  The proper term for this is price fixing and anywere = else
> would be seriously considered as unethical.  Granted (in theory) = there
> more value added from one to the other, but I still think that if ther= e is
> an open source PC memory should be cheaper.
>
> On the 64bit bus interface based on open standards (none have been dra= fted
> that I have found).  I don't know about you, but I have never bee= n able to
> find docs on PCI.  It is a fine bus, but it is too closed.  = I didn't have
> money to join the organization that handles the standardization of
> PCI.  Though, a special 64bit bus may never be implemented I feel= that it
> would be worthwhile to draft a standard for one and make it open sourc= e
> for anyone who decides to start supporting/marketing it.
>
> As stated above I believe that it would be benificial to have a small<= BR> > tasking processor on systems.  Designing small systems with a tas= king
> processor would help to create an arcitecture that would scale very > well.  Some things that usually require locking all processors co= uld be
> taken care of by the tasking processor as well as the virtual memory > management.  Most importantly though is the fact that if a taskin= g
> processor is alive in the unlikely event of a CPU lock (infinite loop = with
> interrupts disabled) the reset option could be linked to the individua= l
> processor. Upon reset the processor could be directed to SMP init code= and
> be ready to be given more work by the tasking processor.  All tha= t is lost
> is the failed opperation.
>
> The last thing I believe would leave questions is why foundary service= s
> are needed.  This would be so that the F-CPU could be prduced at = a good
> price such that people would consider it worth while for them to buy i= t
> instead of x86 or other.  The other reason is if memory were desi= gned to
> be used with the F-CPU on the open PC then it could be produced at a g= ood
> price.  I'm sure you see what I'm getting at now.
>
> I am here to further the cause of Open Source.  I can't do it mys= elf so I
> desire to focus efforts of many groups to a singe point where the
> purpose is to make a fully open computer.
>
> Shaun Kruger
> thekernel@subdimension.com
>

eGroups Sponsor=
3D""
From Jeff Davies Sun Nov 12 15:14:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01658 for ; Sun, 12 Nov 2000 21:28:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:45 +0100 (MET) Received: (qmail 27042 invoked by uid 0); 12 Nov 2000 14:17:51 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx02) with SMTP; 12 Nov 2000 14:17:51 -0000 X-eGroups-Return: sentto-1101623-1416-974038668-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ej.egroups.com with NNFMP; 12 Nov 2000 14:17:50 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 14:17:47 -0000 Received: (qmail 14950 invoked from network); 12 Nov 2000 14:17:28 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 12 Nov 2000 14:17:28 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta3 with SMTP; 12 Nov 2000 15:18:33 -0000 Received: from modem-97.rutherfordium.dialup.pol.co.uk ([62.136.71.225] helo=tiglath.pileser.sumeria) by cmailg5.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13uxwe-00052I-00 for f-cpu@egroups.com; Sun, 12 Nov 2000 14:17:21 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A0E0E91.75444287@starpower.net> <3A0E1DCF.961EF47@jetnet.ab.ca> In-Reply-To: <3A0E1DCF.961EF47@jetnet.ab.ca> Message-Id: <00111214171100.25808@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 14:14:53 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1bb3996145e31d478690b931f41a2e4b Status: R X-Status: N On Sun, 12 Nov 2000, you wrote:
> Alan Grimes wrote:
> >
> > 2000 bits? Yer out of yer mind! =P
> Better make it 2048 bits ... a nice even power of 2.
> 84 pins is the limit of cheap sockets.

I was talking about ON CHIP RAM of about 16 meg , in my scenario, there is no
off chip memory.
my question was, is there any reason why you couldn't use a huge word length
given asic layout

Jeff davies
eGroups Sponsor
From Jeff Davies Sun Nov 12 15:19:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01661 for ; Sun, 12 Nov 2000 21:28:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:45 +0100 (MET) Received: (qmail 24321 invoked by uid 0); 12 Nov 2000 14:21:21 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net (mx19) with SMTP; 12 Nov 2000 14:21:21 -0000 X-eGroups-Return: sentto-1101623-1417-974038879-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hn.egroups.com with NNFMP; 12 Nov 2000 14:21:20 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 14:21:19 -0000 Received: (qmail 25226 invoked from network); 12 Nov 2000 14:20:37 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 12 Nov 2000 14:20:37 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 12 Nov 2000 15:21:43 -0000 Received: from modem-97.rutherfordium.dialup.pol.co.uk ([62.136.71.225] helo=tiglath.pileser.sumeria) by mail6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13uxzm-0002gc-00 for f-cpu@egroups.com; Sun, 12 Nov 2000 14:20:35 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2DE9.F90AC9C7@f-cpu.org> <3A0E414F.6F0B4C33@jetnet.ab.ca> In-Reply-To: <3A0E414F.6F0B4C33@jetnet.ab.ca> Message-Id: <00111214202601.25808@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 14:19:26 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft - cache and bus considerations Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b3adc56b0d4671e510652c10e9da912b Status: R X-Status: N On Sun, 12 Nov 2000, you wrote:
> Quickly looking at the G-chip specs, I notice you have a burst up to 32
> words? for the cache.All the programs I can think of is too random of
> program data for this large a cache.
Perhaps they are tailored for a machine with smaller cache granularity??

Jeff davies
eGroups Sponsor
From Ben Franchuk Sun Nov 12 10:09:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01685 for ; Sun, 12 Nov 2000 21:28:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:50 +0100 (MET) Received: (qmail 9472 invoked by uid 0); 12 Nov 2000 16:11:32 -0000 Received: from hj.egroups.com (208.50.99.212) by mx11.rz2.gmx.net (mx11) with SMTP; 12 Nov 2000 16:11:32 -0000 X-eGroups-Return: sentto-1101623-1418-974045488-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 12 Nov 2000 16:11:30 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 16:11:26 -0000 Received: (qmail 1202 invoked from network); 12 Nov 2000 16:11:26 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 12 Nov 2000 16:11:26 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 12 Nov 2000 16:11:25 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA10920 for ; Sun, 12 Nov 2000 09:03:39 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0E5E32.467C483D@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2DE9.F90AC9C7@f-cpu.org> <3A0E414F.6F0B4C33@jetnet.ab.ca> <00111214202601.25808@tiglath.pileser.sumeria> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 09:09:06 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft - cache and bus considerations Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e60c7c6e2f75aca7d51d81d69a9797e Status: R X-Status: N Jeff Davies wrote:
>
> On Sun, 12 Nov 2000, you wrote:
> > Quickly looking at the G-chip specs, I notice you have a burst up to 32
> > words? for the cache.All the programs I can think of is too random of
> > program data for this large a cache.
> Perhaps they are tailored for a machine with smaller cache granularity??

Thats the word I am looking for "cache granularity"

Here is some cache urls I have found.
http://www.ece.cmu.edu/~ee742/proj_s98/fung/#ref4
http://www.ece.cmu.edu/~ee742/proj_f97/myers/
http://www.sics.se/~ans/simple-coma/hpca-95/paper.html
http://www.cs.cmu.edu/~steffan/items/isca00/

Some interesting ideas here, but they all imply the BIGGER is better
idea is not working out well.
Ben.
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Michael Riepe Sun Nov 12 16:21:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01697 for ; Sun, 12 Nov 2000 21:28:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:53 +0100 (MET) Received: (qmail 19294 invoked by uid 0); 12 Nov 2000 17:07:18 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx05) with SMTP; 12 Nov 2000 17:07:18 -0000 X-eGroups-Return: sentto-1101623-1420-974048835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ml.egroups.com with NNFMP; 12 Nov 2000 17:07:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 17:07:14 -0000 Received: (qmail 17526 invoked from network); 12 Nov 2000 17:07:14 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 12 Nov 2000 17:07:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.196) by mta2 with SMTP; 12 Nov 2000 17:07:12 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00549; Sun, 12 Nov 2000 16:21:23 +0100 Message-ID: <20001112162122.18723@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <00111101384401.24769@tiglath.pileser.sumeria> <20001111144712.02045@thrai.stud.uni-hannover.de> <00111201324302.05129@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00111201324302.05129@tiglath.pileser.sumeria>; from Jeff Davies on Sun, Nov 12, 2000 at 01:29:30AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 16:21:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: abb0385eaf5417d9d87b28c5ab47410d Status: R X-Status: N On Sun, Nov 12, 2000 at 01:29:30AM +0000, Jeff Davies wrote:
[C Compiler]
> > Stop talking, start coding...
> >
> You misunderstand. I was asking if anyone was working on these since I seem to
> remember Downie or someone on the french list saying something like, "I am
> working on one... it will be ready soon".

Uh... these separate mailing lists suck, somehow.  There are too many
independent communication channels, and you have to poll them all (maybe
several times) to query the status of the project :(

> BTW I did send in some VHDL 1.5 years ago.

That wasn't directed to you in particular, but to the lurking general
public.  As I said -- `you know who'.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sun Nov 12 16:25:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01700 for ; Sun, 12 Nov 2000 21:28:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:54 +0100 (MET) Received: (qmail 8091 invoked by uid 0); 12 Nov 2000 17:07:23 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx17) with SMTP; 12 Nov 2000 17:07:23 -0000 X-eGroups-Return: sentto-1101623-1419-974048835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 12 Nov 2000 17:07:20 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 17:07:14 -0000 Received: (qmail 24841 invoked from network); 12 Nov 2000 17:07:10 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Nov 2000 17:07:10 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.196) by mta2 with SMTP; 12 Nov 2000 17:07:08 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00563; Sun, 12 Nov 2000 16:25:51 +0100 Message-ID: <20001112162551.58292@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A0E0E91.75444287@starpower.net> <3A0E1DCF.961EF47@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A0E1DCF.961EF47@jetnet.ab.ca>; from Ben Franchuk on Sun, Nov 12, 2000 at 04:34:23AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 16:25:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9a51322b4651dc93711fa75970309293 Status: R X-Status: N On Sun, Nov 12, 2000 at 04:34:23AM +0000, Ben Franchuk wrote:
[...]
> > But it does point to a potentially usefull concept. That of a vairable
> > wordlength... I mean there needs to be something better than using a full
> > word for a boolean! =P
>
> Some people like -1 as true rather than 1, thus a full word is needed.

No, a single bit is sufficient -- if the bit is set, its numeric value
*is* -1 (unless you treat it as unsigned).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From "Marco Al" Sun Nov 12 18:45:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01709 for ; Sun, 12 Nov 2000 21:28:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:56 +0100 (MET) Received: (qmail 24098 invoked by uid 0); 12 Nov 2000 17:39:32 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx17) with SMTP; 12 Nov 2000 17:39:32 -0000 X-eGroups-Return: sentto-1101623-1421-974050766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 12 Nov 2000 17:39:30 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 17:39:25 -0000 Received: (qmail 81973 invoked from network); 12 Nov 2000 17:39:25 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Nov 2000 17:39:25 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 12 Nov 2000 17:39:21 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id SAA20682 for ; Sun, 12 Nov 2000 18:39:12 +0100 (MET) Message-ID: <002501c04cd0$479c2d60$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 18:45:00 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototiping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1277d0e3c45742f46399202fa2bb7d8f Status: R X-Status: N From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>


> How about it?
> http://www.xess.com/prod014.html
> if anyone already use it, please let me know.
>
> I plan to buy it(XCV300), and implement Sayuri core.
>
> Toyoaki Sagawa

Hmm its a bit of an expensive platform... I was considering buying one of
the SpartanII boards, probably one from Insight. Any reason you dont like
it?

Marco
eGroups Sponsor
From Yann Guidon Sun Nov 12 18:49:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01712 for ; Sun, 12 Nov 2000 21:28:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:57 +0100 (MET) Received: (qmail 21830 invoked by uid 0); 12 Nov 2000 17:44:47 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx16) with SMTP; 12 Nov 2000 17:44:47 -0000 X-eGroups-Return: sentto-1101623-1422-974051080-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 12 Nov 2000 17:44:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 17:44:40 -0000 Received: (qmail 97566 invoked from network); 12 Nov 2000 17:44:39 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Nov 2000 17:44:39 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 12 Nov 2000 17:44:38 -0000 Received: from f-cpu.org (nas1-152.ras.club-internet.fr [195.36.192.152]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA05817 for ; Sun, 12 Nov 2000 18:44:35 +0100 (MET) Message-ID: <3A0ED825.CCB17999@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2488.C8134F5@jetnet.ab.ca> <3A0E2DE9.F90AC9C7@f-cpu.org> <3A0E414F.6F0B4C33@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 18:49:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft - cache and bus considerations Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8031288d611f2b47e1a9a52d4fe29afe Status: R X-Status: N hi,

Ben Franchuk wrote:
> Quickly looking at the G-chip specs, I notice you have a burst up to 32
> words?
i meant that the master could only control the bus during 16 cycles,
leaving enough time to transmit a burts of 8 x 32-bit words and send prefetch
addresses.
> for the cache.All the programs I can think of is too random of
> program data for this large a cache.
As of today, a cache line is 256 bits, that means that we can execute 8 instructions
per line, so the latency of the memory can be of 8 cycles (with a single issue
pipeline). It also takes 8 cycles to fill a cache line from the F-bus,
so if the F-bus can sustain a transfer rate at the same speed as the CPU core,
the CPU can work with few stalls (theoretically). That is a case
when nothing is cached (each instruction generates a cache miss) and when the
data are ready (cached), so the bandwidth looks balanced. In practice it is
never the case.

> Hopeing to find more information
> on this I did a search on the for "memory cache". While I did not find
> any more information on how to estimate typical cache sizes, I did find this
> link on a fast risc (1GHZ+)
> http://inp.cie.rpi.edu/~cmaier/phdthesis/PhD_Dissertation.html
i have to check it (give me some time)

> I hope it may be of some use. Ben.
> PS.Anybody got a program to estimate static sizes needed for a cache?
> I can run thru linux source?

"static size" ? what is this ? you mean an estimation of the needed cache size ?
i don't think that the Linux sources contain anything about this.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Marco Al" Sun Nov 12 18:58:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01715 for ; Sun, 12 Nov 2000 21:28:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:58 +0100 (MET) Received: (qmail 15330 invoked by uid 0); 12 Nov 2000 17:52:45 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx02) with SMTP; 12 Nov 2000 17:52:45 -0000 X-eGroups-Return: sentto-1101623-1423-974051556-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 12 Nov 2000 17:52:43 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 17:52:36 -0000 Received: (qmail 65838 invoked from network); 12 Nov 2000 17:52:36 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Nov 2000 17:52:36 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 12 Nov 2000 17:52:33 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id SAA23908 for ; Sun, 12 Nov 2000 18:52:22 +0100 (MET) Message-ID: <003601c04cd2$1f7e2de0$29e65982@student.utwente.nl> To: References: <3A0D67C5.EB2480F8@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 18:58:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototiping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cd911732a41f019db16219d66e5c9b44 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> AFAIK, there is no proto board available yet.
> the problem is the same as the development software :
> anybody should be able to use it freely and at the
> least cost. but i'm still hopeful, though.

Well the SpartanII is pretty close to that goal, cheap boards (Insight) and
free (beer) development software.

> Now that i work for Meta, i can access a large HW
> reconfigurable simulation machine. i don't know how to use
> it yet and my work is far from developping cores. Anyway,
> there is maybe (i'm very careful, i can't raise high hopes)
> a possibility to use it for remote design. this is a rather
> complex and proprietary machine but it can do some
> remarkable things that don't fit in a FPGA. i'll keep the group
> informed about my efforts.

Is it "just" for logic verification?

Marco
eGroups Sponsor
From Yann Guidon Sun Nov 12 19:05:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01718 for ; Sun, 12 Nov 2000 21:28:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:28:59 +0100 (MET) Received: (qmail 7389 invoked by uid 0); 12 Nov 2000 18:00:47 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx04) with SMTP; 12 Nov 2000 18:00:47 -0000 X-eGroups-Return: sentto-1101623-1424-974052041-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 12 Nov 2000 18:00:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 18:00:41 -0000 Received: (qmail 49641 invoked from network); 12 Nov 2000 18:00:40 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Nov 2000 18:00:40 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 12 Nov 2000 18:00:40 -0000 Received: from f-cpu.org (nas4-164.aub.club-internet.fr [195.36.145.164]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA28176 for ; Sun, 12 Nov 2000 19:00:37 +0100 (MET) Message-ID: <3A0EDBEA.805C8A6C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E0E91.75444287@starpower.net> <3A0E1DCF.961EF47@jetnet.ab.ca> <00111214171100.25808@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 19:05:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Variable word length? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4235f54a10bfdd23bbb7b9ccd44fc9d6 Status: R X-Status: N hi,

Jeff Davies wrote:
> On Sun, 12 Nov 2000, you wrote:
> > Alan Grimes wrote:
> > > 2000 bits? Yer out of yer mind! =P
> > Better make it 2048 bits ... a nice even power of 2.
> > 84 pins is the limit of cheap sockets.
> I was talking about ON CHIP RAM of about 16 meg , in my scenario,
> there is no off chip memory.
> my question was, is there any reason why you couldn't use a huge word length
> given asic layout

there is nothing keeping you from doing it, at the f-cpu level.
it depends greatly on the technology, though, and can't be defined
precisely in the f-cpu architecture. If you implement eDRAM, though,
you'll have to publish the specifications of the interface, this
includes the SR configuration and setup. remember a discussion we
had previously.

> Jeff davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Nov 12 19:10:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01742 for ; Sun, 12 Nov 2000 21:29:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 12 Nov 2000 21:29:08 +0100 (MET) Received: (qmail 10731 invoked by uid 0); 12 Nov 2000 18:07:10 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx03) with SMTP; 12 Nov 2000 18:07:10 -0000 X-eGroups-Return: sentto-1101623-1425-974052427-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hn.egroups.com with NNFMP; 12 Nov 2000 18:07:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 18:07:07 -0000 Received: (qmail 23267 invoked from network); 12 Nov 2000 18:07:07 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Nov 2000 18:07:07 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 12 Nov 2000 18:07:07 -0000 Received: from f-cpu.org (nas4-164.aub.club-internet.fr [195.36.145.164]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA02219 for ; Sun, 12 Nov 2000 19:06:04 +0100 (MET) Message-ID: <3A0EDCFE.F412B1D9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0E2DE9.F90AC9C7@f-cpu.org> <3A0E414F.6F0B4C33@jetnet.ab.ca> <00111214202601.25808@tiglath.pileser.sumeria> <3A0E5E32.467C483D@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 19:10:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft - cache and bus considerations Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b28892aa40269508a80cec300c40a81 Status: R X-Status: N hi,

Ben Franchuk wrote:
> Jeff Davies wrote:
> > On Sun, 12 Nov 2000, you wrote:
> > > Quickly looking at the G-chip specs, I notice you have a burst up to 32
> > > words? for the cache.All the programs I can think of is too random of
> > > program data for this large a cache.
> > Perhaps they are tailored for a machine with smaller cache granularity??
> Thats the word I am looking for "cache granularity"

it's 256 bits as of today... it can change with wider CPUs but it's large enough
for the FC0.

> Here is some cache urls I have found.
> http://www.ece.cmu.edu/~ee742/proj_s98/fung/#ref4
> http://www.ece.cmu.edu/~ee742/proj_f97/myers/
> http://www.sics.se/~ans/simple-coma/hpca-95/paper.html
> http://www.cs.cmu.edu/~steffan/items/isca00/
>
> Some interesting ideas here, but they all imply the BIGGER is better
> idea is not working out well.

nice URLs, thanks :-)

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Nicolas Boulay Sun Nov 12 23:54:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00329 for ; Mon, 13 Nov 2000 15:57:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:50 +0100 (MET) Received: (qmail 21056 invoked by uid 0); 12 Nov 2000 22:52:42 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx01) with SMTP; 12 Nov 2000 22:52:42 -0000 X-eGroups-Return: sentto-1101623-1426-974069554-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 12 Nov 2000 22:52:41 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 22:52:33 -0000 Received: (qmail 1534 invoked from network); 12 Nov 2000 22:52:33 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Nov 2000 22:52:33 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 12 Nov 2000 23:53:33 -0000 Received: from ifrance.com (nas25-251.vlt.club-internet.fr [195.36.224.251]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA16897 for ; Sun, 12 Nov 2000 23:51:46 +0100 (MET) Message-ID: <3A0F1FB5.3D801F67@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 23:54:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 75661a14fe2022de688bf2f5acf64ae5 Status: R X-Status: N I just read your page. But you make very big "prospective" mistak= e. The
2 or 4 chip will be on the SAME die. So each cpus could only shared L2
or L3 cache (eDRAM about few Mbyte). But your system could be
implemented inside a chip.

I'm sorry i have wrote a big message about memory sharing system but in
the french mailing list... any body, to translate ? ;) Aller !

nicO

Yann Guidon a =E9crit :
>
> hello,
> i have uploaded a draft for the G-chip (sort of 'chipset' but better)<= BR> > at http://www.f-cpu.de/g-chip/=
>
> i hope that you'll have helpful remarks. it also explains why i don't<= BR> > seem to like the usual PC standards. there is also a redesign proposal=
> for the F-bus.
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

eGroups Sponsor=
3D""
From Yann Guidon Sun Nov 12 23:59:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00332 for ; Mon, 13 Nov 2000 15:57:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:51 +0100 (MET) Received: (qmail 28459 invoked by uid 0); 12 Nov 2000 23:15:29 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx03) with SMTP; 12 Nov 2000 23:15:29 -0000 X-eGroups-Return: sentto-1101623-1427-974069701-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 12 Nov 2000 22:55:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 22:55:01 -0000 Received: (qmail 53371 invoked from network); 12 Nov 2000 22:54:53 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Nov 2000 22:54:53 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 12 Nov 2000 22:54:53 -0000 Received: from f-cpu.org (nas1-219.aub.club-internet.fr [195.36.150.219]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA28159 for ; Sun, 12 Nov 2000 23:54:51 +0100 (MET) Message-ID: <3A0F20D8.30C90DD2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0D67C5.EB2480F8@f-cpu.org> <003601c04cd2$1f7e2de0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 23:59:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototiping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab4f6a2ee5e48aab574bde18fbb671d0 Status: R X-Status: N hi,

Marco Al wrote:
> > there is maybe (i'm very careful, i can't raise high hopes)
> > a possibility to use it for remote design. this is a rather
> > complex and proprietary machine but it can do some
> > remarkable things that don't fit in a FPGA. i'll keep the group
> > informed about my efforts.
> Is it "just" for logic verification?

at first glance, this machine's best point is that it can work
with multiple clock domains. you understand that i can't say more,
but since the FC0 is a fully synchronous superpipeline, the first
logic verification can be done in SW. The day we'll want
a more complex design, like a multi-bus bridge with several
clock domains and complex signals, it will be very useful.
It can also be used to connect the "emulated core" with external HW.
Simili seems to do the trick for the high-level development.
Then, we'll have to synthesise the design for a specific technology,
then check the synthesised result with the original design
(verification against timing violations etc). i know that there
are some wizzards around here, but let's have a complete design
first ;-) While i'm at work, Michael's work on the design is more
than helpful... i've tried to catch up this week-end but i had
to rest too.

> Marco
WHYGEE (speakin' for himself, heh.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Toyoaki Sagawa" Mon Nov 13 00:06:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00342 for ; Mon, 13 Nov 2000 15:57:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:52 +0100 (MET) Received: (qmail 5644 invoked by uid 0); 12 Nov 2000 23:21:43 -0000 Received: from hm.egroups.com (208.50.99.198) by mx12.rz2.gmx.net (mx12) with SMTP; 12 Nov 2000 23:21:43 -0000 X-eGroups-Return: sentto-1101623-1428-974070343-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hm.egroups.com with NNFMP; 12 Nov 2000 23:05:46 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 12 Nov 2000 23:05:43 -0000 Received: (qmail 14548 invoked from network); 12 Nov 2000 23:05:42 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 12 Nov 2000 23:05:42 -0000 Received: from unknown (HELO mail154.nifty.com) (202.248.37.147) by mta1 with SMTP; 12 Nov 2000 23:05:42 -0000 Received: from cfb5 by mail154.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id IAA21133 for ; Mon, 13 Nov 2000 08:05:41 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002501c04cd0$479c2d60$29e65982@student.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 08:06:05 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6a861ca5f96ddde3413956c852dbaba6 Status: R X-Status: N
Hi,

> > How about it?
> > http://www.xess.com/prod014.html
> Hmm its a bit of an expensive platform... I was considering
> buying one of
> the SpartanII boards, probably one from Insight. Any reason you
> dont like
> it?

(1) Memory size.Virtex board have 4MB memory (and expandable).
(2) interface.
Virtex board: PS/2, VGA, Ethernet, USB, Serial.
it is enough to build complete personal computer.
(3) gate size.
Sayuri needs about 1000 logic slice for it's core(at now. it can be
reduced).
I want 2 sayuri core + peripheral IP's in one chip, so XCV300 is
suitable.

So I think XESS XCV300 is (maybe) best selection , but if you know more
cheap board(4MB+ memory, enough interface & gates), please tell me.

Toyoaki Sagawa
eGroups Sponsor
From Yann Guidon Mon Nov 13 01:39:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00345 for ; Mon, 13 Nov 2000 15:57:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:53 +0100 (MET) Received: (qmail 16398 invoked by uid 0); 13 Nov 2000 00:34:32 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx08) with SMTP; 13 Nov 2000 00:34:32 -0000 X-eGroups-Return: sentto-1101623-1429-974075669-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 13 Nov 2000 00:34:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 00:34:29 -0000 Received: (qmail 26119 invoked from network); 13 Nov 2000 00:34:28 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Nov 2000 00:34:28 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 13 Nov 2000 01:35:34 -0000 Received: from f-cpu.org (nas3-86.aub.club-internet.fr [195.36.145.86]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA05183 for ; Mon, 13 Nov 2000 01:34:26 +0100 (MET) Message-ID: <3A0F3833.BD5B6486@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 01:39:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 62286e433e69da1f803c7305aec86afe Status: R X-Status: N hi,

Nicolas Boulay wrote:
> I just read your page. But you make very big "prospective" m= istake. The
> 2 or 4 chip will be on the SAME die. So each cpus could only shared L2=
> or L3 cache (eDRAM about few Mbyte). But your system could be
> implemented inside a chip.

we don't know yet. i have nothing against eDRAM but without a big
external SDRAM bank, we won't go far. it's your business if you don't
need it, at least the solution exists in a certain form. you can remove
a part without much trouble. My problem was the scalability of the memory bandwidth with a multi-CPU system. Scalability means that the user can add = or remove
parts without unbalancing the architecture. The case that you are refering<= BR> to uses a multi-core chip with embedded DRAM. Nice, but you can't add new CPUs on the chip like LEGO bricks, once the chip is funded. you know what i mean ? my remarks will still apply to this kind of system : only the bus<= BR> interface matters. This means that the G-chip will be a very important
ressource if we want a real scalable system. I was investigating something<= BR> like the good formula for bricks (F-chips) and cement (G-chips), so they can make a good wall.

just a remark about putting ie 4 cores on a die : the agregate mem bw
will not scale as well. if 4 pairs of F+G chips can do 4*2*128=3D1024
bits of bandwidth (one 128-bit SDRAM interface per chip) with a package of<= BR> around 400 pins (x8), you'll need around 1500 pins and a wicked PCB to reac= h
this external bandwidth with a single chip. Furthermore, it won't be as sca= lable :
once you have put the 4 cores, the eDRAM, the external SDRAM interface,
you won't have any ressource or pin left for communication with other simil= ar
chips. To keep the system balanced, you'll need a 256-bit wide I/O bus ! i don't want to route that PCB ;-) i hope that you understand my point of v= iew :
i don't want to sacrifice the overall system performance and scalability be= cause
of a single, probable and uncontrollable advantage. We can master our sourc= e
codes but not the technology of the funders. eDRAM is nice for L2, sure, bu= t that's all.
we need an external module or a slot for a much larger storage.

If you have other interesting orientations, topology propositions etc.,
please speak out :-)

oh btw, i tried to investigate the T3D (3D Torus) architecture but the G-ch= ip
wouldn't have enough pins because it requires at least twice as much F-bus = interfaces
(6 for the neighbours and 1 for the local chip). i'm seeking a good comprom= ise
that lets any hobbyist "play" with inexpensive modules (F-cpu + S= DRAM) like
LEGO bricks. The "brick" in question can have the same package an= d silicon process
for the F-CPU chip and the crossbar chip, this helps keep the design inexpe= nsive.


> I'm sorry i have wrote a big message about memory sharing system but i= n
> the french mailing list... any body, to translate ? ;) Aller !

sorry, i gotta sleep (and go to the office morgen fr=FCh)

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From "Marco Al" Mon Nov 13 02:29:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00349 for ; Mon, 13 Nov 2000 15:57:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:54 +0100 (MET) Received: (qmail 1062 invoked by uid 0); 13 Nov 2000 01:23:29 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx15) with SMTP; 13 Nov 2000 01:23:29 -0000 X-eGroups-Return: sentto-1101623-1430-974078603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by c3.egroups.com with NNFMP; 13 Nov 2000 01:23:24 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 01:23:21 -0000 Received: (qmail 1032 invoked from network); 13 Nov 2000 01:23:21 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 13 Nov 2000 01:23:21 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 13 Nov 2000 01:23:21 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id CAA20778 for ; Mon, 13 Nov 2000 02:23:19 +0100 (MET) Message-ID: <00ad01c04d11$1e7809e0$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 02:29:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d978fd5ba7efd45aa52771922ab0b777 Status: R X-Status: N From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>

>  So I think XESS XCV300 is (maybe) best selection , but if you know more
> cheap board(4MB+ memory, enough interface & gates), please tell me.
>
> Toyoaki Sagawa

How about the Insight SpartanII PCI board? (a bit tight though with only
~1700 slices)  With a free PCI core (http://tapec.uv.es/research/PCI/ for
instance, fits into a 8K gates Altera FLEX) you could use a normal
motherboard+CPU to provide other services.

Marco
eGroups Sponsor
From Yann Guidon Mon Nov 13 07:53:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00367 for ; Mon, 13 Nov 2000 15:57:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:57:59 +0100 (MET) Received: (qmail 6734 invoked by uid 0); 13 Nov 2000 06:48:50 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx05) with SMTP; 13 Nov 2000 06:48:50 -0000 X-eGroups-Return: sentto-1101623-1431-974098125-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fg.egroups.com with NNFMP; 13 Nov 2000 06:48:47 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 06:48:44 -0000 Received: (qmail 29847 invoked from network); 13 Nov 2000 06:48:44 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 13 Nov 2000 06:48:44 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 13 Nov 2000 07:49:49 -0000 Received: from f-cpu.org (nas3-2.ras.club-internet.fr [195.36.203.2]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA25807 for ; Mon, 13 Nov 2000 07:48:41 +0100 (MET) Message-ID: <3A0F8FF1.4E8D3FD5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00ad01c04d11$1e7809e0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 07:53:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1797897dbda9497c43e1f11352af6f43 Status: R X-Status: N hi,

Marco Al wrote:
> From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>
> >  So I think XESS XCV300 is (maybe) best selection , but if you know more
> > cheap board(4MB+ memory, enough interface & gates), please tell me.
> >
> > Toyoaki Sagawa
>
> How about the Insight SpartanII PCI board? (a bit tight though with only
> ~1700 slices)  With a free PCI core (http://tapec.uv.es/research/PCI/ for
> instance, fits into a 8K gates Altera FLEX) you could use a normal
> motherboard+CPU to provide other services.

i've seen (a bit) the Xilinx page, and it looks almost too good.
add to that a DRAM controller and an IDE interface, and you have a
complete portable solution. i don't know about the real power
consumption, though. At least it can help as a demonstration board
for a minimal 32- or 64-bit POC system ("Proof of concept").

The other link (PCI VHDL generator) is cool, too. I don't know
whether it can be easily retargeted to another technology.
The argument of using the host platform to do the I/O is buggy
(in my humble personal opinion) because we have to find a board
with the chip already mounted on a PCI compliant PCB. I won't speak
about the configuration SW : we have to setup both the platform
and the PCI board, and that's twice as much as i can personally afford.

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Nov 13 07:55:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00371 for ; Mon, 13 Nov 2000 15:58:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:58:01 +0100 (MET) Received: (qmail 10740 invoked by uid 0); 13 Nov 2000 06:50:14 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx04) with SMTP; 13 Nov 2000 06:50:14 -0000 X-eGroups-Return: sentto-1101623-1432-974098210-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by jk.egroups.com with NNFMP; 13 Nov 2000 06:50:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 06:50:10 -0000 Received: (qmail 17955 invoked from network); 13 Nov 2000 06:50:10 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Nov 2000 06:50:10 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 13 Nov 2000 07:51:15 -0000 Received: from f-cpu.org (nas3-2.ras.club-internet.fr [195.36.203.2]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA26463 for ; Mon, 13 Nov 2000 07:50:07 +0100 (MET) Message-ID: <3A0F9047.F17C6E50@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00ad01c04d11$1e7809e0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 07:55:03 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ff6ce0bf1ff75aeaa268876152b55f94 Status: R X-Status: N ooooops !

"Not Found

"The requested URL /cgi-bin/pcigen.cgi was not found on this server.


looks like i can't try your toy...

Marco Al wrote:
> How about the Insight SpartanII PCI board? (a bit tight though with only
> ~1700 slices)  With a free PCI core (http://tapec.uv.es/research/PCI/ for
> instance, fits into a 8K gates Altera FLEX) you could use a normal
> motherboard+CPU to provide other services.
>
> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Toyoaki Sagawa" Mon Nov 13 12:01:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00378 for ; Mon, 13 Nov 2000 15:58:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:58:03 +0100 (MET) Received: (qmail 30302 invoked by uid 0); 13 Nov 2000 11:01:04 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx23) with SMTP; 13 Nov 2000 11:01:04 -0000 X-eGroups-Return: sentto-1101623-1433-974113260-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by b05.egroups.com with NNFMP; 13 Nov 2000 11:01:01 -0000 X-Sender: PXW07530@nifty.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 11:01:00 -0000 Received: (qmail 16107 invoked from network); 13 Nov 2000 11:01:00 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 13 Nov 2000 11:01:00 -0000 Received: from unknown (HELO mail154.nifty.com) (202.248.37.147) by mta1 with SMTP; 13 Nov 2000 11:00:59 -0000 Received: from cfb5 by mail154.nifty.com (8.9.3+3.2W/3.7W-10/13/99) with SMTP id UAA17432 for ; Mon, 13 Nov 2000 20:00:58 +0900 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <00ad01c04d11$1e7809e0$29e65982@student.utwente.nl> From: "Toyoaki Sagawa" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 20:01:23 +0900 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f30b9668ce5d2bf35b432a38397b286f Status: R X-Status: N
Hi,
> From: Marco Al [mailto:marco@simplex.nl]
> How about the Insight SpartanII PCI board? (a bit tight though with only

You mean
http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.htm
l
This board?
I read but, they say
"Available now, the Spartan-II PCI Development Kit (DS-PCI32S-KIT1) is
priced at $3,995, "
...
or you mean
"Insight also sells the development board with the reference designs,
source code examples and Reference Design Center access (DS-PCI32-BRD) for
$145. "
it is considerable. I send quote request.

Now I have 2 way to think...
(1) with XESS XCV300. double Sayuri core. needs many IP. small memory.
I can make Compact Flash extension board as storage+Memory Extension.
(2) with DS-PCI32-BRD. single Sayuri core+ Free PCI host IP.
it requires PCI mother board+many PCI board(Ethernet, VGA, SuperIO,SCSI)
or, I already have my PCI-target VHDL, so it can be tested in my PC.

the total cost will be almost same :-).

Toyoaki Sagawa
eGroups Sponsor
From Erik Hansen Mon Nov 13 14:57:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00387 for ; Mon, 13 Nov 2000 15:58:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 15:58:05 +0100 (MET) Received: (qmail 10410 invoked by uid 0); 13 Nov 2000 14:02:37 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx22) with SMTP; 13 Nov 2000 14:02:37 -0000 X-eGroups-Return: sentto-1101623-1434-974124151-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 13 Nov 2000 14:02:35 -0000 X-Sender: erikh@cs.tu-berlin.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 14:02:30 -0000 Received: (qmail 83115 invoked from network); 13 Nov 2000 14:02:26 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 13 Nov 2000 14:02:25 -0000 Received: from unknown (HELO mail.cs.tu-berlin.de) (130.149.17.13) by mta1 with SMTP; 13 Nov 2000 14:02:24 -0000 Received: from lira.cs.tu-berlin.de (erikh@lira.cs.tu-berlin.de [130.149.17.201]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id OAA01488 for ; Mon, 13 Nov 2000 14:57:18 +0100 (MET) Received: (from erikh@localhost) by lira.cs.tu-berlin.de (8.9.3/8.9.3) id OAA25951; Mon, 13 Nov 2000 14:57:18 +0100 (MET) X-Sender: erikh@lira To: f-cpu@egroups.com Message-ID: From: Erik Hansen MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 14:57:18 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 52ae4d6b98a2b5d85198207ffa541127 Status: R X-Status: N Hi all,

i had a close look on the inc unit this weekend. While doing
so some questions arose concerning the exact definition of
the units behavior.

1. Compare:

  According to chapter 2.10 of the manual the execution of conditional
  operations is dependend on the register being either all zeros or
  having at last one bit set.
  The example of the cmplxx commands shows the the result is either
  all zeros or all ones.
  Though the two ways of handling conditions are almost the same,
  there is this slight difference which ends up in additional gates
  when using the second definition.
  Therefore i would prefer the first method.
  Any comments?

2. SIMD / Data SIZE

  Is there a command like neg.b ( in contrary to sneg.b )?
  If so, how are the upper bit handled?
    Keep there values in the target register
    Set them all zero
    Or take them from one of the source operands

3. Overflow

  As I understood there will be no exceptions in the
  execution units.
  So in which way neg of -128 (byte mode) schould handled?
  There is no +128. Using the normal algoritm ( invert
  every bit, add 1) results again in -128.


Thanx

Erik

 


eGroups Sponsor
From Ben Franchuk Sun Nov 12 20:38:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01283 for ; Mon, 13 Nov 2000 22:48:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:19 +0100 (MET) Received: (qmail 27447 invoked by uid 0); 13 Nov 2000 15:43:25 -0000 Received: from mv.egroups.com (208.50.144.81) by mx19.rz2.gmx.net (mx19) with SMTP; 13 Nov 2000 15:43:25 -0000 X-eGroups-Return: sentto-1101623-1435-974130201-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mv.egroups.com with NNFMP; 13 Nov 2000 15:43:24 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 15:43:20 -0000 Received: (qmail 18593 invoked from network); 13 Nov 2000 15:43:20 -0000 Received: from unknown (10.1.10.27) by m3.onelist.org with QMQP; 13 Nov 2000 15:43:20 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 13 Nov 2000 15:43:19 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA26715 for ; Mon, 13 Nov 2000 08:35:22 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0EF1B1.73B32C0D@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 12 Nov 2000 19:38:25 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c0620440016c61fd5b4ee26d89e49f63 Status: R X-Status: N Erik Hansen wrote:
>
> Hi all,
>
> i had a close look on the inc unit this weekend. While doing
> so some questions arose concerning the exact definition of
> the units behavior.
>
> 1. Compare:
>
>   According to chapter 2.10 of the manual the execution of conditional
>   operations is dependend on the register being either all zeros or
>   having at last one bit set.
>   The example of the cmplxx commands shows the the result is either
>   all zeros or all ones.
>   Though the two ways of handling conditions are almost the same,
>   there is this slight difference which ends up in additional gates
>   when using the second definition.
>   Therefore i would prefer the first method.
>   Any comments?

One option may be to use some of the reserved flag bits as logical mask.
Flag #1 & true_condition -> Bit [1]
Flag #2 & true_condition -> Bit [63..2]
Flag #3 & true_condition -> Bit [64]
This gives you 1,-1,and sign bit as useful values for a logic true result.
This makes the C,Pascal and Basic people happy.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Jeff Davies Mon Nov 13 17:36:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01295 for ; Mon, 13 Nov 2000 22:48:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:22 +0100 (MET) Received: (qmail 16617 invoked by uid 0); 13 Nov 2000 16:38:44 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx18) with SMTP; 13 Nov 2000 16:38:44 -0000 X-eGroups-Return: sentto-1101623-1436-974133516-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ho.egroups.com with NNFMP; 13 Nov 2000 16:38:43 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_2_1); 13 Nov 2000 16:38:36 -0000 Received: (qmail 21546 invoked from network); 13 Nov 2000 16:38:36 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 13 Nov 2000 16:38:36 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta2 with SMTP; 13 Nov 2000 16:38:33 -0000 Received: from modem-247.magnesium.dialup.pol.co.uk ([62.136.11.247] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13vMcj-00022r-00 for f-cpu@egroups.org; Mon, 13 Nov 2000 16:38:26 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] Message-Id: <00111316365903.05917@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 16:36:32 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] xml program dtd now with xsl stylesheet - and example program written in XML with output java Content-Type: multipart/mixed; boundary="Boundary-=_yGgxxpkLoRellNMPapqfWkHOPkMC" X-UIDL: b9c004a03a861af61856e455a088c0d1 Status: R X-Status: N --Boundary-=_yGgxxpkLoRellNMPapqfWkHOPkMC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit I actually have a working basic system whereby I can write programs in XML,
using the nice (free but not GPL) xeena tree-control based editor !!you can fold
up sections of the code), and you can translate this into  Java using the basic
stylesheet I have developed.

Xeena from IBM Alphaworks is pretty good for editing, and has built in XSLT
engine to do translation (eg XML to HTML or WML for Wap phones).

Here are the most recent zipped files:

fcpu-program.dtd is the dtd (this is the set of rules that you use to build
your document - in this case our program).

fcpu-class-program.xsl is my first xsl stylesheet to convert the above program
(in XML form) into Java.

example-class.xml is a sample class which is translated into
fcpu-prog.txt  which is the output Java program.

The program structure has spaces for dependency information, function spec
references, id numbers, exactly what you need for auditable code.
BY writing a different XSL stylesheet, you could output perhaps ASSEMBLER or
BASIC or C++ from the same code!
(or perhaps VHDL?).

The auditable capability might be useful also if you want to write programs
for routers, banking or, really just about anything (all code should be
reliable).

Jeff Davies
eGroups Sponsor
--Boundary-=_yGgxxpkLoRellNMPapqfWkHOPkMC Content-Type: application/x-zip; name="demo131100.zip" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="demo131100.zip" PK --Boundary-=_yGgxxpkLoRellNMPapqfWkHOPkMC-- From whygee@club-internet.fr Mon Nov 13 18:11:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01304 for ; Mon, 13 Nov 2000 22:48:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:25 +0100 (MET) Received: (qmail 5442 invoked by uid 0); 13 Nov 2000 17:11:34 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx08) with SMTP; 13 Nov 2000 17:11:34 -0000 X-eGroups-Return: sentto-1101623-1437-974135482-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 13 Nov 2000 17:11:27 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 17:11:22 -0000 Received: (qmail 62466 invoked from network); 13 Nov 2000 17:11:18 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Nov 2000 17:11:18 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 13 Nov 2000 17:11:18 -0000 Received: (from mnet@localhost) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id SAA20154 for f-cpu@egroups.com; Mon, 13 Nov 2000 18:11:15 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 18:11:15 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] xml program dtd now with xsl stylesheet - and example program written in Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 09548fb4c3bf4cfade3b73d220823eb5 Status: R X-Status: N hello !

>De: Jeff Davies <jeff@llandre.freeserve.co.uk>
>I actually have a working basic system whereby I can write programs in XML,
>using the nice (free but not GPL) xeena tree-control based editor !!you can fold
>up sections of the code), and you can translate this into  Java using the basic
>stylesheet I have developed.

<snip>

hey, could there be a GPL version or equivalent under the
GNU licence ? if yes, that would become a good alternative
to GCC coding. now, we would have to make a C front-end
to translate the Linux sources...

i have no way to use your work yet, but the idea behind GNL can
be reused somehow. if you could make a demo of this workflow
at the 17C3, the guyz would want to ... well, hum, marry you ?
:o)

YG
eGroups Sponsor
From Michael Riepe Mon Nov 13 15:32:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01307 for ; Mon, 13 Nov 2000 22:48:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:26 +0100 (MET) Received: (qmail 12297 invoked by uid 0); 13 Nov 2000 17:29:14 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 13 Nov 2000 17:29:14 -0000 X-eGroups-Return: sentto-1101623-1438-974136549-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hj.egroups.com with NNFMP; 13 Nov 2000 17:29:11 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 17:29:08 -0000 Received: (qmail 25208 invoked from network); 13 Nov 2000 17:29:08 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 13 Nov 2000 17:29:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.38) by mta3 with SMTP; 13 Nov 2000 18:30:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00561; Mon, 13 Nov 2000 15:32:10 +0100 Message-ID: <20001113153210.43399@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A0F3833.BD5B6486@f-cpu.org>; from Yann Guidon on Mon, Nov 13, 2000 at 01:39:15AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 15:32:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 396750a48e7bcc654edae93889147d8f Status: R X-Status: N On Mon, Nov 13, 2000 at 01:39:15AM +0100, Yann Guidon wrote:
[...]
> oh btw, i tried to investigate the T3D (3D Torus) architecture but the G-chip
> wouldn't have enough pins because it requires at least twice as much F-bus interfaces
> (6 for the neighbours and 1 for the local chip). i'm seeking a good compromise
> that lets any hobbyist "play" with inexpensive modules (F-cpu + SDRAM) like
> LEGO bricks. The "brick" in question can have the same package and silicon process
> for the F-CPU chip and the crossbar chip, this helps keep the design inexpensive.

Did you consider a serial link instead of a bus?  A full-duplex serial
link requires only few lines -- that also means simpler wiring, less pins,
and lower cost.  Since connections between [FG]-chips are point-to-point
anyway, a full-blown bus with tri-state buffers, bidirectional control
signals and so on would be overkill, IMHO.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Jecel Assumpcao Jr Mon Nov 13 18:58:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01325 for ; Mon, 13 Nov 2000 22:48:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:32 +0100 (MET) Received: (qmail 18759 invoked by uid 0); 13 Nov 2000 18:01:35 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 13 Nov 2000 18:01:35 -0000 X-eGroups-Return: sentto-1101623-1440-974138483-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fl.egroups.com with NNFMP; 13 Nov 2000 18:01:25 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 18:01:22 -0000 Received: (qmail 23615 invoked from network); 13 Nov 2000 18:01:22 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Nov 2000 18:01:22 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.210.69.43) by mta3 with SMTP; 13 Nov 2000 19:02:12 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id QAA24271 for ; Mon, 13 Nov 2000 16:29:34 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F3833.BD5B6486@f-cpu.org> <20001113153210.43399@thrai.stud.uni-hannover.de> In-Reply-To: <20001113153210.43399@thrai.stud.uni-hannover.de> Message-Id: <00111316132103.00382@gandalf> X-eGroups-From: Jecel Assumpcao Jr From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 15:58:00 -0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] serial link (was: G-chip draft) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 662fa71d890a943afbb637a04e6166cd Status: R X-Status: N On Mon, 13 Nov 2000, Michael Riepe wrote:
> On Mon, Nov 13, 2000 at 01:39:15AM +0100, Yann Guidon wrote:
> [...]
> > oh btw, i tried to investigate the T3D (3D Torus) architecture but the G-chip
> > wouldn't have enough pins because it requires at least twice as much F-bus interfaces
> > (6 for the neighbours and 1 for the local chip). i'm seeking a good compromise
> > that lets any hobbyist "play" with inexpensive modules (F-cpu + SDRAM) like
> > LEGO bricks. The "brick" in question can have the same package and silicon process
> > for the F-CPU chip and the crossbar chip, this helps keep the design inexpensive.
>
> Did you consider a serial link instead of a bus?  A full-duplex serial
> link requires only few lines -- that also means simpler wiring, less pins,
> and lower cost.  Since connections between [FG]-chips are point-to-point
> anyway, a full-blown bus with tri-state buffers, bidirectional control
> signals and so on would be overkill, IMHO.

I was going to write the exact same thing myself. Specially since that
is the direction more experienced people are going:

   http://developer.intel.com/design/servers/future_server_io/

   http://www.infinibandta.org/

I, of course, prefer more open efforts like the IEEE P2100:

    http://www.SCIzzL.com/P2100/index.html

or its "big brother", the Scalable Coherent Interface.

-- Jecel
eGroups Sponsor
From "Marco Al" Mon Nov 13 19:05:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01328 for ; Mon, 13 Nov 2000 22:48:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:33 +0100 (MET) Received: (qmail 27876 invoked by uid 0); 13 Nov 2000 18:00:55 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 13 Nov 2000 18:00:55 -0000 X-eGroups-Return: sentto-1101623-1439-974138413-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by fg.egroups.com with NNFMP; 13 Nov 2000 18:00:22 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 18:00:13 -0000 Received: (qmail 19694 invoked from network); 13 Nov 2000 18:00:12 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 13 Nov 2000 18:00:12 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 13 Nov 2000 19:01:14 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id SAA07404 for ; Mon, 13 Nov 2000 18:59:56 +0100 (MET) Message-ID: <005401c04d9c$59121c90$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 19:05:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Prototyping board for FreeCPUs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2dd4bde435d5527f357d45e465ecec4 Status: R X-Status: N From: "Toyoaki Sagawa" <PXW07530@nifty.ne.jp>

> Hi,
> > From: Marco Al [mailto:marco@simplex.nl]
> > How about the Insight SpartanII PCI board? (a bit tight though with only
>
> You mean
> http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.htm
> l
> This board?
>  I read but, they say
> "Available now, the Spartan-II PCI Development Kit (DS-PCI32S-KIT1) is
> priced at $3,995, "

Thats including a core license and foundation I think.

> or you mean
> "Insight also sells the development board with the reference designs,
> source code examples and Reference Design Center access (DS-PCI32-BRD) for
> $145. "
> it is considerable. I send quote request.

Thats the one, I was basing my thoughts on a statement from John Campbell on
the FPGACPU list which quoted a price of just 135$ for just the board but
close enough.

> Now I have 2 way to think...
> (1) with XESS XCV300. double Sayuri core. needs many IP. small memory.
>  I can make Compact Flash extension board as storage+Memory Extension.
> (2) with DS-PCI32-BRD. single Sayuri core+ Free PCI host IP.
>  it requires PCI mother board+many PCI board(Ethernet, VGA, SuperIO,SCSI)
>  or, I already have my PCI-target VHDL, so it can be tested in my PC.
>
>  the total cost will be almost same :-).
>
> Toyoaki Sagawa

Total system cost is the same, getting a development prototype will be much
cheaper for most people though... since they have a PC with all the
necessary peripherals on hand already.

Marco

PS. Oops didnt really try out the PCI VHDL generator website, I just read a
paper on it which mentioned the website... Ill send a mail asking whats up.
eGroups Sponsor
From whygee@club-internet.fr Mon Nov 13 19:16:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01331 for ; Mon, 13 Nov 2000 22:48:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:34 +0100 (MET) Received: (qmail 2705 invoked by uid 0); 13 Nov 2000 18:17:01 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx15) with SMTP; 13 Nov 2000 18:17:01 -0000 X-eGroups-Return: sentto-1101623-1441-974139404-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by cj.egroups.com with NNFMP; 13 Nov 2000 18:16:47 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 18:16:43 -0000 Received: (qmail 30234 invoked from network); 13 Nov 2000 18:16:43 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 13 Nov 2000 18:16:43 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 13 Nov 2000 18:16:38 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id TAA23346 for f-cpu@egroups.com; Mon, 13 Nov 2000 19:16:37 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 19:16:37 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c916389070e58388a9535d49346e1a5f Status: R X-Status: N hi,

>De: Michael Riepe <michael@stud.uni-hannover.de>
>Did you consider a serial link instead of a bus?  A full-duplex serial
>link requires only few lines -- that also means simpler wiring, less pins,
>and lower cost.  Since connections between [FG]-chips are point-to-point
>anyway, a full-blown bus with tri-state buffers, bidirectional control
>signals and so on would be overkill, IMHO.

in this case, i was seeking the highest bandwidth possible.
i don't believe that serial links are worth with the kind
of technologies that we can access. What do you prefer,
Mbits/s or MBytes/s ? :-)

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
Y"lazy"G
eGroups Sponsor
From "Marco Al" Mon Nov 13 21:08:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01343 for ; Mon, 13 Nov 2000 22:48:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:38 +0100 (MET) Received: (qmail 4270 invoked by uid 0); 13 Nov 2000 20:03:21 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx03) with SMTP; 13 Nov 2000 20:03:21 -0000 X-eGroups-Return: sentto-1101623-1442-974145748-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by b05.egroups.com with NNFMP; 13 Nov 2000 20:02:32 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 20:02:27 -0000 Received: (qmail 20457 invoked from network); 13 Nov 2000 20:02:27 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 13 Nov 2000 20:02:27 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 13 Nov 2000 21:03:32 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id VAA02841 for ; Mon, 13 Nov 2000 21:02:25 +0100 (MET) Message-ID: <00a801c04dad$75b067b0$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 21:08:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 46fc14341aef7456bafad941dfb7f01b Status: R X-Status: N From: <whygee@club-internet.fr>

> in this case, i was seeking the highest bandwidth possible.
> i don't believe that serial links are worth with the kind
> of technologies that we can access. What do you prefer,
> Mbits/s or MBytes/s ? :-)

Well unless you use fiber a purely serial bus isnt an option obviously...
its more a question of a narrow bus with a fast clock or a wide one with a
slow clock. ACK's are slow, so if you want to stick to that approach you
will have to go wide to get good throughput. If seperate clock's are an
absolute requirement, couldnt then the receiver forward his own clock and
then get the data (and the clock...) back at that rate?

I fail to see the logic in having async TTL compatible bus, you could always
include a simple serial connection for debugging.

Marco
eGroups Sponsor
From Nicolas Boulay Mon Nov 13 22:01:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01352 for ; Mon, 13 Nov 2000 22:48:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 13 Nov 2000 22:48:40 +0100 (MET) Received: (qmail 29751 invoked by uid 0); 13 Nov 2000 20:59:30 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx01) with SMTP; 13 Nov 2000 20:59:30 -0000 X-eGroups-Return: sentto-1101623-1443-974149164-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 13 Nov 2000 20:59:28 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 20:59:23 -0000 Received: (qmail 86696 invoked from network); 13 Nov 2000 20:59:22 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 13 Nov 2000 20:59:22 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 13 Nov 2000 20:59:21 -0000 Received: from ifrance.com (nas5-133.vlt.club-internet.fr [194.158.107.133]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA13758 for ; Mon, 13 Nov 2000 21:59:18 +0100 (MET) Message-ID: <3A1056B4.6DC5A45A@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 22:01:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a19567364fc5abf57a799958bd427071 Status: R X-Status: N

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > I just read your page. But you make very big "prospective&qu= ot; mistake. The
> > 2 or 4 chip will be on the SAME die. So each cpus could only shar= ed L2
> > or L3 cache (eDRAM about few Mbyte). But your system could be
> > implemented inside a chip.
>
> we don't know yet. i have nothing against eDRAM but without a big
> external SDRAM bank, we won't go far. it's your business if you don't<= BR>
That's not the point ! Very (very close) to us we will have cpu with 2
or more core in the same die. The next AMD chip will be provide with 2
cpu on it. IBM want put 2 PowerPC on the same die with 2 Mo of eDRAM as
L2 cache. This is always the same goal having the maximum bandwiths
between the cpus.

> need it, at least the solution exists in a certain form. you can remov= e
> a part without much trouble. My problem was the scalability of the mem= ory
> bandwidth with a multi-CPU system. Scalability means that the user can= add or remove
> parts without unbalancing the architecture. The case that you are refe= ring
> to uses a multi-core chip with embedded DRAM. Nice, but you can't add = new
> CPUs on the chip like LEGO bricks, once the chip is funded. you know w= hat

I don't broke this ! You just need to have 2 level of cpu networks. One
level on chip with shared memory and the second a NUMA memory system
(like mine ?). So you can play with your fcpu lego bricks if you are a
student or a microelectronic designer.

> i mean ? my remarks will still apply to this kind of system : only the= bus
> interface matters. This means that the G-chip will be a very important=
> ressource if we want a real scalable system. I was investigating somet= hing
> like the good formula for bricks (F-chips) and cement (G-chips), so th= ey
> can make a good wall.
>
> just a remark about putting ie 4 cores on a die : the agregate mem bw<= BR> > will not scale as well. if 4 pairs of F+G chips can do 4*2*128=3D1024<= BR>
Never mind !!! It could dratiscally change with 8 Mo of cache even one
way and a good memory management !

> bits of bandwidth (one 128-bit SDRAM interface per chip) with a packag= e of
> around 400 pins (x8), you'll need around 1500 pins and a wicked PCB to= reach
> this external bandwidth with a single chip. Furthermore, it won't be a= s scalable :
> once you have put the 4 cores, the eDRAM, the external SDRAM interface= ,
> you won't have any ressource or pin left for communication with other = similar
> chips. To keep the system balanced, you'll need a 256-bit wide I/O bus= !
> i don't want to route that PCB ;-) i hope that you understand my point= of view :
> i don't want to sacrifice the overall system performance and scalabili= ty because
> of a single, probable and uncontrollable advantage. We can master our = source
> codes but not the technology of the funders. eDRAM is nice for L2, sur= e, but that's all.

That's true but you can say in your code : hier you need a memory for
the cache system !

> we need an external module or a slot for a much larger storage.
>
> If you have other interesting orientations, topology propositions etc.= ,
> please speak out :-)
>
> oh btw, i tried to investigate the T3D (3D Torus) architecture but the= G-chip
> wouldn't have enough pins because it requires at least twice as much F= -bus interfaces
> (6 for the neighbours and 1 for the local chip). i'm seeking a good co= mpromise
> that lets any hobbyist "play" with inexpensive modules (F-cp= u + SDRAM) like
> LEGO bricks. The "brick" in question can have the same packa= ge and silicon process
> for the F-CPU chip and the crossbar chip, this helps keep the design i= nexpensive.
>

SUN use a crossbar and a 512bit with bus, and it's very expensive... So
a quick link could be funny. Serial link are very impressive BUT wiring
is horrible (see the problem of RDRAM) and the connector are very
expensive and the latence much horrible (that could kill your multi-cpu
device).

> > I'm sorry i have wrote a big message about memory sharing system = but in
> > the french mailing list... any body, to translate ? ;) Aller ! >
> sorry, i gotta sleep (and go to the office morgen fr=FCh)
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

eGroups Sponsor=
3D""
From "Marco Al" Tue Nov 14 00:21:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01875 for ; Tue, 14 Nov 2000 00:46:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 00:46:36 +0100 (MET) Received: (qmail 13152 invoked by uid 0); 13 Nov 2000 23:19:10 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx15) with SMTP; 13 Nov 2000 23:19:10 -0000 X-eGroups-Return: sentto-1101623-1444-974157537-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 13 Nov 2000 23:19:06 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 23:18:57 -0000 Received: (qmail 13847 invoked from network); 13 Nov 2000 23:15:21 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 13 Nov 2000 23:15:21 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 13 Nov 2000 23:15:21 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id AAA21286 for ; Tue, 14 Nov 2000 00:15:19 +0100 (MET) Message-ID: <001301c04dc8$681aaaf0$29e65982@student.utwente.nl> To: References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> <3A1056B4.6DC5A45A@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 00:21:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9bb4c087922cd71d761c5d279f778561 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> SUN use a crossbar and a 512bit with bus, and it's very expensive... So
> a quick link could be funny. Serial link are very impressive BUT wiring
> is horrible (see the problem of RDRAM) and the connector are very
> expensive and the latence much horrible (that could kill your multi-cpu
> device).

The latency issue with RDRAM is not so much caused by it being serial IMO
but by it being packetized just like the given design, and wiring isnt so
much horrible as very strict IMO. Personally I like a fully differential bus
like BLVDS.

Marco
eGroups Sponsor
From Jeff Davies Tue Nov 14 00:40:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02041 for ; Tue, 14 Nov 2000 02:00:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 02:00:46 +0100 (MET) Received: (qmail 4542 invoked by uid 0); 13 Nov 2000 23:50:19 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx15) with SMTP; 13 Nov 2000 23:50:19 -0000 X-eGroups-Return: sentto-1101623-1445-974159408-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mw.egroups.com with NNFMP; 13 Nov 2000 23:50:18 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 23:50:08 -0000 Received: (qmail 94434 invoked from network); 13 Nov 2000 23:44:28 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 13 Nov 2000 23:44:28 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta2 with SMTP; 13 Nov 2000 23:44:28 -0000 Received: from modem-52.indiana.dialup.pol.co.uk ([62.137.65.52] helo=tiglath.pileser.sumeria) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13vTGz-0000cz-00 for f-cpu@egroups.com; Mon, 13 Nov 2000 23:44:26 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: In-Reply-To: Message-Id: <00111323440202.06297@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 23:40:00 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] xml program dtd now with xsl stylesheet - and example program written in Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 08f257bafc5549431d1811ab5b384854 Status: R X-Status: N I have two things to do regarding the editor:
1. petition IBM to make Xeena GPL. (50% chance of success).
2. Build a similar but much better version which can become a full
explorer-type product. I think I would do this in Java.
I think IBM 's parser (Xerxes is GPL but I have to check, otherwise we need
that too, and an XSLT tool).
Jeff Davies.

ps: I think it is difficult for me to make 17C3, what with 4 kids, dog and
wife-type-unit. We probably need to go to scotland to see olds at this time. (if
it wasn't so close to christmas.....).


On Mon, 13 Nov 2000, you wrote:
> hello !
>
> >De: Jeff Davies <jeff@llandre.freeserve.co.uk>
> >I actually have a working basic system whereby I can write programs in XML,
> >using the nice (free but not GPL) xeena tree-control based editor !!you can fold
> >up sections of the code), and you can translate this into  Java using the basic
> >stylesheet I have developed.
>
> <snip>
>
> hey, could there be a GPL version or equivalent under the
> GNU licence ? if yes, that would become a good alternative
> to GCC coding. now, we would have to make a C front-end
> to translate the Linux sources...
>
> i have no way to use your work yet, but the idea behind GNL can
> be reused somehow. if you could make a demo of this workflow
> at the 17C3, the guyz would want to ... well, hum, marry you ?
> :o)
>
> YG
>

eGroups Sponsor
From Michael Riepe Mon Nov 13 19:01:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02047 for ; Tue, 14 Nov 2000 02:00:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 02:00:49 +0100 (MET) Received: (qmail 21021 invoked by uid 0); 13 Nov 2000 23:57:34 -0000 Received: from hj.egroups.com (208.50.99.212) by mx19.rz2.gmx.net (mx19) with SMTP; 13 Nov 2000 23:57:34 -0000 X-eGroups-Return: sentto-1101623-1446-974159697-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 13 Nov 2000 23:55:11 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 13 Nov 2000 23:54:56 -0000 Received: (qmail 14055 invoked from network); 13 Nov 2000 23:49:37 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 13 Nov 2000 23:49:37 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.66) by mta2 with SMTP; 13 Nov 2000 23:49:24 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01276; Mon, 13 Nov 2000 19:01:00 +0100 Message-ID: <20001113190100.49320@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Erik Hansen on Mon, Nov 13, 2000 at 02:57:18PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 19:01:00 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e7293046cade6dc6fba4816f6b9533b Status: R X-Status: N On Mon, Nov 13, 2000 at 02:57:18PM +0100, Erik Hansen wrote:

>   According to chapter 2.10 of the manual the execution of conditional
>   operations is dependend on the register being either all zeros or
>   having at last one bit set.
>   The example of the cmplxx commands shows the the result is either
>   all zeros or all ones.
>   Though the two ways of handling conditions are almost the same,
>   there is this slight difference which ends up in additional gates
>   when using the second definition.
>   Therefore i would prefer the first method.

IIRC the information `register is zero' is taken from the scoreboard
(pre-calculated when the register is written to).

This points me to another problem: we can't do register bypassing in this
case; the value has to be stored first in order to update the scoreboard.

> 2. SIMD / Data SIZE
>
>   Is there a command like neg.b ( in contrary to sneg.b )?
>   If so, how are the upper bit handled?
>     Keep there values in the target register
>     Set them all zero
>     Or take them from one of the source operands

That isn't clear to me either, and it's a general problem, i.e. not
limited to the neg instruction.  Take mul.b, for example -- will the
target register hold a 16-bit result or only the lower 8 bits, and what
will the other bits look like?  For symmetry's sake, it should hold
the lower 8 bits only (you can get the rest with mulh.b, or use a 16-bit
operation); the rest of the target register will probably be unchanged.
On the other hand, partial register writes will be a real horror because
we have to update the zero property in the scoreboard (which means we
have to re-read the register, or have individual property bits for every
8-bit slice).  I guess `set to zero' is the better solution.

> 3. Overflow
>
>   As I understood there will be no exceptions in the
>   execution units.
>   So in which way neg of -128 (byte mode) schould handled?

As usual: sign_extend(neg(-128)) => -128.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Nov 14 02:11:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00313 for ; Tue, 14 Nov 2000 16:46:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:39 +0100 (MET) Received: (qmail 14078 invoked by uid 0); 14 Nov 2000 01:24:28 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx22) with SMTP; 14 Nov 2000 01:24:28 -0000 X-eGroups-Return: sentto-1101623-1447-974165053-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by b05.egroups.com with NNFMP; 14 Nov 2000 01:24:23 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 01:24:13 -0000 Received: (qmail 53582 invoked from network); 14 Nov 2000 01:11:55 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 14 Nov 2000 01:11:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.66) by mta2 with SMTP; 14 Nov 2000 01:11:54 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01271; Tue, 14 Nov 2000 02:11:50 +0100 Message-ID: <20001114021150.47353@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Nov 13, 2000 at 07:16:37PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 02:11:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9b344f33a77a6758e546d21531ae8566 Status: R X-Status: N On Mon, Nov 13, 2000 at 07:16:37PM +0100, whygee@club-internet.fr wrote:

> in this case, i was seeking the highest bandwidth possible.
> i don't believe that serial links are worth with the kind
> of technologies that we can access. What do you prefer,
> Mbits/s or MBytes/s ? :-)

Depends on the numbers in front of them ;) And on the number of problems
I'm going to have -- which is proportional to the number of bus lines,
multiplied by bus length, number of units on the bus, clock frequency,
and by another factor of 3 if there are bi-directional signals and/or
buffers with tri-state or open-collector/open-drain outputs.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Nov 14 02:49:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00316 for ; Tue, 14 Nov 2000 16:46:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:41 +0100 (MET) Received: (qmail 32073 invoked by uid 0); 14 Nov 2000 01:49:42 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx16) with SMTP; 14 Nov 2000 01:49:42 -0000 X-eGroups-Return: sentto-1101623-1448-974166565-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 14 Nov 2000 01:49:39 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 01:49:22 -0000 Received: (qmail 31139 invoked from network); 14 Nov 2000 01:49:11 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 14 Nov 2000 01:49:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.66) by mta3 with SMTP; 14 Nov 2000 02:50:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01377; Tue, 14 Nov 2000 02:49:07 +0100 Message-ID: <20001114024907.29453@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> <3A1056B4.6DC5A45A@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A1056B4.6DC5A45A@ifrance.com>; from Nicolas Boulay on Mon, Nov 13, 2000 at 10:01:40PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 02:49:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d575dd88d851a994bb1e67e71ed253eb Status: R X-Status: N On Mon, Nov 13, 2000 at 10:01:40PM +0100, Nicolas Boulay wrote:

> SUN use a crossbar and a 512bit with bus, and it's very expensive... So
> a quick link could be funny. Serial link are very impressive BUT wiring
> is horrible (see the problem of RDRAM) and the connector are very
> expensive and the latence much horrible (that could kill your multi-cpu
> device).

I remember that SUN device... only the memory bus is 512 bits wide
(plus ECC), the other ports (2x CPU, 2xI/O) are narrower.  And 2 CPUs
share a port in a quad configuration (maybe they have a new version for
the UltraSPARC III).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Ben Franchuk Mon Nov 13 05:16:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00319 for ; Tue, 14 Nov 2000 16:46:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:41 +0100 (MET) Received: (qmail 22232 invoked by uid 0); 14 Nov 2000 04:22:47 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx16) with SMTP; 14 Nov 2000 04:22:47 -0000 X-eGroups-Return: sentto-1101623-1449-974174475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 14 Nov 2000 04:01:52 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 04:01:14 -0000 Received: (qmail 5479 invoked from network); 14 Nov 2000 03:30:45 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 14 Nov 2000 03:30:45 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 14 Nov 2000 03:30:44 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA03466 for ; Mon, 13 Nov 2000 20:22:45 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A0F6B0D.DEDE4414@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Nov 2000 04:16:13 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 44d0bc23e238bae08623dc90c7c89df9 Status: R X-Status: N Michael Riepe wrote:
>> Depends on the numbers in front of them ;) And on the number of problems
> I'm going to have -- which is proportional to the number of bus lines,
> multiplied by bus length, number of units on the bus, clock frequency,
> and by another factor of 3 if there are bi-directional signals and/or
> buffers with tri-state or open-collector/open-drain outputs.

Does Asynchronous bus lines have any advantages here.That is two lines per
data bit have any advantages here? I think they have better noise immunity.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Tue Nov 14 08:14:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00327 for ; Tue, 14 Nov 2000 16:46:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:43 +0100 (MET) Received: (qmail 22860 invoked by uid 0); 14 Nov 2000 07:09:39 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx05) with SMTP; 14 Nov 2000 07:09:39 -0000 X-eGroups-Return: sentto-1101623-1451-974185772-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 14 Nov 2000 07:09:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 07:09:31 -0000 Received: (qmail 28278 invoked from network); 14 Nov 2000 07:09:30 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 14 Nov 2000 07:09:30 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 14 Nov 2000 07:09:30 -0000 Received: from f-cpu.org (nas1-162.ras.club-internet.fr [195.36.192.162]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA11558 for ; Tue, 14 Nov 2000 08:09:25 +0100 (MET) Message-ID: <3A10E644.59686B68@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 08:14:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6faa008baf07e9c3b859d85875db6f5f Status: R X-Status: N hi,

Michael Riepe wrote:
> On Mon, Nov 13, 2000 at 07:16:37PM +0100, whygee@club-internet.fr wrote:
> > in this case, i was seeking the highest bandwidth possible.
> > i don't believe that serial links are worth with the kind
> > of technologies that we can access. What do you prefer,
> > Mbits/s or MBytes/s ? :-)
>
> Depends on the numbers in front of them ;)
sure, but with the same number ?

> And on the number of problems
> I'm going to have -- which is proportional to the number of bus lines,
> multiplied by bus length, number of units on the bus, clock frequency,
> and by another factor of 3 if there are bi-directional signals and/or
> buffers with tri-state or open-collector/open-drain outputs.

Anyway, do you agree that badwidth is a matter of technology ?
when we don't have technology, we can try to make some compromises.
i don't want too many of them because when they are done, it's
already too late to rewind the error.

i'm still trying to find a decent protocol for the F-bus. A preliminary
spec might appear soon. i've found the latest discussion very positive,
in the sense that many people have voiced out (in french as well as english)
and we see the worries of everyone, without starting a single flame war :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Tue Nov 14 08:14:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00330 for ; Tue, 14 Nov 2000 16:46:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:44 +0100 (MET) Received: (qmail 21753 invoked by uid 0); 14 Nov 2000 07:09:38 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx17) with SMTP; 14 Nov 2000 07:09:38 -0000 X-eGroups-Return: sentto-1101623-1450-974185772-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 14 Nov 2000 07:09:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 07:09:31 -0000 Received: (qmail 7514 invoked from network); 14 Nov 2000 07:09:31 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 Nov 2000 07:09:31 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 14 Nov 2000 08:10:36 -0000 Received: from f-cpu.org (nas1-162.ras.club-internet.fr [195.36.192.162]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA11049 for ; Tue, 14 Nov 2000 08:09:24 +0100 (MET) Message-ID: <3A10E644.D75CE049@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00111323440202.06297@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 08:14:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] xml program dtd now with xsl stylesheet - and example program written in Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 593053e311e57bbbd838458c935c7852 Status: R X-Status: N hi,

Jeff Davies wrote:
>
> I have two things to do regarding the editor:
> 1. petition IBM to make Xeena GPL. (50% chance of success).
> 2. Build a similar but much better version which can become a full
> explorer-type product. I think I would do this in Java.
> I think IBM 's parser (Xerxes is GPL but I have to check, otherwise we need
> that too, and an XSLT tool).
> Jeff Davies.

i guess that it is your holy crusade, now :-)

> ps: I think it is difficult for me to make 17C3, what with 4 kids, dog and
> wife-type-unit. We probably need to go to scotland to see olds at this time. (if
> it wasn't so close to christmas.....).
sad, but not lethal. I think we'll have time to setup some demo SW
on a laptop before 17C3. I don't want you to divorce :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Tue Nov 14 08:14:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00333 for ; Tue, 14 Nov 2000 16:46:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 14 Nov 2000 16:46:44 +0100 (MET) Received: (qmail 22912 invoked by uid 0); 14 Nov 2000 07:09:43 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx05) with SMTP; 14 Nov 2000 07:09:43 -0000 X-eGroups-Return: sentto-1101623-1452-974185773-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 14 Nov 2000 07:09:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 07:09:33 -0000 Received: (qmail 13536 invoked from network); 14 Nov 2000 07:09:33 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 Nov 2000 07:09:33 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 14 Nov 2000 08:10:37 -0000 Received: from f-cpu.org (nas1-162.ras.club-internet.fr [195.36.192.162]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA25012 for ; Tue, 14 Nov 2000 08:09:25 +0100 (MET) Message-ID: <3A10E641.83BFC026@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001113190100.49320@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 08:14:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bc593c8e839cf6517ec4ff2b06a87b3c Status: R X-Status: N hi !

Michael Riepe wrote:
> On Mon, Nov 13, 2000 at 02:57:18PM +0100, Erik Hansen wrote:
> >   According to chapter 2.10 of the manual the execution of conditional
> >   operations is dependend on the register being either all zeros or
> >   having at last one bit set.
> >   The example of the cmplxx commands shows the the result is either
> >   all zeros or all ones.

explanation :

this instruction's result is also for binary manipulation purposes,
using masks to perform operations in SIMD mode.
That is : if you have XXXX comparisons to do, you would do them all
in a usual CPU. F-CPU lets you do less iterations with SIMD packets.
But if you set only one bit, you can't mask out bits. that's why it's
apparently overkilling the pipeline. If you use good algorithms, this
should not become a problem.

> >   Though the two ways of handling conditions are almost the same,
> >   there is this slight difference which ends up in additional gates
> >   when using the second definition.
the "light" difference is more than that, the critical datapath is even longer
and the fanout can lead to some complication. i am conscious of this, but
in the end, it boils down to the same things : if you output only one bit, you'll
require a complex operation in the shifter to select the words. this complex
operation will do the OR/AND mask, plus the fanout stuff, so we better
keep it in the incrementer, even if it takes one addition pipestage in this case...

> >   Therefore i would prefer the first method.
you'll prefer the second when the CPU increases in width :-)

> IIRC the information `register is zero' is taken from the scoreboard
> (pre-calculated when the register is written to).
that's still right :-) so you see that this redundancy has a special reason.

> This points me to another problem: we can't do register bypassing in this
> case; the value has to be stored first in order to update the scoreboard.
well, it's both a drawback and an advantage. it simplifies the chip's scheduling
during task switches. but we can do "smart bypass", right ? read below...

> > 2. SIMD / Data SIZE
> >
> >   Is there a command like neg.b ( in contrary to sneg.b )?
> >   If so, how are the upper bit handled?
> >     Keep there values in the target register
> >     Set them all zero
> >     Or take them from one of the source operands
>
> That isn't clear to me either, and it's a general problem, i.e. not
> limited to the neg instruction.  Take mul.b, for example -- will the
> target register hold a 16-bit result or only the lower 8 bits, and what
> will the other bits look like?  For symmetry's sake, it should hold
> the lower 8 bits only (you can get the rest with mulh.b, or use a 16-bit
> operation); the rest of the target register will probably be unchanged.
> On the other hand, partial register writes will be a real horror because
> we have to update the zero property in the scoreboard (which means we
> have to re-read the register, or have individual property bits for every
> 8-bit slice).  I guess `set to zero' is the better solution.

2 points here : "set to zero" is not recommended, but it's not specified either.
long ago, i have found a way to do the partial writes on the registers.
this means that for the execution unit, all operations are SIMD, and the SIMD
flag only operates when the write back occurs. this keeps your job simple.
so you can remember : the partial reads are not a problems because everything
is read at the same time, only write back is partial. do you prefer that ? :-)

2nd point : the zero flag. It's a big 64-bit OR. As you noted, it must be split
into 8 byte-ors, that are ored together. So when write back occurs, we select
only the good latch. that's where the above "smart forward" appears : selecting
the byte-or or the output of the incrementer (before it is extended to  a byte).
so we gain around 1 or 2 gates of critical datapath... (we have to add a
mux in the CDP).

> > 3. Overflow
> >   As I understood there will be no exceptions in the
> >   execution units.
> >   So in which way neg of -128 (byte mode) schould handled?
> As usual: sign_extend(neg(-128)) => -128.
well, euh... maybe, i should wake up too.

read you,

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Tue Nov 14 18:11:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00308 for ; Wed, 15 Nov 2000 16:04:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:21 +0100 (MET) Received: (qmail 15677 invoked by uid 0); 14 Nov 2000 17:19:28 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx14) with SMTP; 14 Nov 2000 17:19:28 -0000 X-eGroups-Return: sentto-1101623-1454-974222353-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 14 Nov 2000 17:19:23 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 17:19:13 -0000 Received: (qmail 14855 invoked from network); 14 Nov 2000 17:19:12 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 Nov 2000 17:19:12 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.203) by mta3 with SMTP; 14 Nov 2000 18:19:54 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01256; Tue, 14 Nov 2000 18:11:16 +0100 Message-ID: <20001114181115.01122@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A10E644.59686B68@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A10E644.59686B68@f-cpu.org>; from Yann Guidon on Tue, Nov 14, 2000 at 08:14:12AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 18:11:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: caf24bee676383746d2e51eece709619 Status: R X-Status: N On Tue, Nov 14, 2000 at 08:14:12AM +0100, Yann Guidon wrote:

> > > in this case, i was seeking the highest bandwidth possible.
> > > i don't believe that serial links are worth with the kind
> > > of technologies that we can access. What do you prefer,
> > > Mbits/s or MBytes/s ? :-)
> >
> > Depends on the numbers in front of them ;)
> sure, but with the same number ?

See the other mail I just wrote...

> > And on the number of problems
> > I'm going to have -- which is proportional to the number of bus lines,
> > multiplied by bus length, number of units on the bus, clock frequency,
> > and by another factor of 3 if there are bi-directional signals and/or
> > buffers with tri-state or open-collector/open-drain outputs.
>
> Anyway, do you agree that badwidth is a matter of technology ?

Yes and no.  Technology matters, but there are other factors, too.

> when we don't have technology, we can try to make some compromises.
> i don't want too many of them because when they are done, it's
> already too late to rewind the error.
>
> i'm still trying to find a decent protocol for the F-bus. A preliminary
> spec might appear soon. i've found the latest discussion very positive,
> in the sense that many people have voiced out (in french as well as english)
> and we see the worries of everyone, without starting a single flame war :-)

Too bad that I don't understand french, and know next to nothing about
the things you discuss on the mailing list next door (and no, I don't
read the german list either -- my credo is: one project, one language,
one mailing list ;).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Nov 14 18:04:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00311 for ; Wed, 15 Nov 2000 16:04:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:22 +0100 (MET) Received: (qmail 25242 invoked by uid 0); 14 Nov 2000 17:20:17 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx18) with SMTP; 14 Nov 2000 17:20:17 -0000 X-eGroups-Return: sentto-1101623-1455-974222358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 14 Nov 2000 17:19:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 17:19:18 -0000 Received: (qmail 4519 invoked from network); 14 Nov 2000 17:19:17 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 Nov 2000 17:19:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.203) by mta3 with SMTP; 14 Nov 2000 18:20:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01235; Tue, 14 Nov 2000 18:04:22 +0100 Message-ID: <20001114180422.41938@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A0F6B0D.DEDE4414@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A0F6B0D.DEDE4414@jetnet.ab.ca>; from Ben Franchuk on Mon, Nov 13, 2000 at 04:16:13AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 18:04:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 453cd90a385be0be1752b80f16881c70 Status: R X-Status: N On Mon, Nov 13, 2000 at 04:16:13AM +0000, Ben Franchuk wrote:
> Michael Riepe wrote:
> >> Depends on the numbers in front of them ;) And on the number of problems
> > I'm going to have -- which is proportional to the number of bus lines,
> > multiplied by bus length, number of units on the bus, clock frequency,
> > and by another factor of 3 if there are bi-directional signals and/or
> > buffers with tri-state or open-collector/open-drain outputs.
>
> Does Asynchronous bus lines have any advantages here.That is two lines per
> data bit have any advantages here? I think they have better noise immunity.

Differential signalling does (see Ultra2/LVD SCSI), but asynchronous
logic (aka Dual-Rail Encoding) doesn't.  The advantage of DRE is that it
eliminates the bus clock -- a bit is transferred whenever one of the two
lines changes its state -- and adapts to the maximum speed of receiver
and transmitter automagically; but it needs a feedback line that ACKs
every single bit, to avoid overruns.  The time to transfer a bit can
become quite long this way -- it depends on the delays of receiver and
transmitter (signal-to-feedback and vice versa), and the delay of the
link itself.

The main point isn't noise immunity anyway.  The bus protocol for a
bi-directional parallel bus is quite complicated; a serial link (or two
independent one-way links for full-duplex) is much easier.  You need
no bus arbitration, no complicated handshaking, no change of transfer
direction, and no tri-state phases.  If bursts can be used, an n-bit bus
will have a (theoretical) maximum throughput of n bits/cycle, but worst
case throughput is much lower -- both master and slave have to acquire
bus ownership, send a word and release the bus, which probably takes 2
or 3 cycles per single-word transfer.  A serial link, on the other hand,
always runs at its full speed (which will probably be much higher than
that of a bus), and full-duplex links allow simultaneous transfers in both
directions.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Tue Nov 14 18:16:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00314 for ; Wed, 15 Nov 2000 16:04:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:23 +0100 (MET) Received: (qmail 13849 invoked by uid 0); 14 Nov 2000 17:21:15 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx03) with SMTP; 14 Nov 2000 17:21:15 -0000 X-eGroups-Return: sentto-1101623-1453-974222294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 14 Nov 2000 17:18:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 17:18:14 -0000 Received: (qmail 11846 invoked from network); 14 Nov 2000 17:18:11 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 Nov 2000 17:18:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.203) by mta3 with SMTP; 14 Nov 2000 18:19:14 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01271; Tue, 14 Nov 2000 18:16:38 +0100 Message-ID: <20001114181638.16023@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001113190100.49320@thrai.stud.uni-hannover.de> <3A10E641.83BFC026@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A10E641.83BFC026@f-cpu.org>; from Yann Guidon on Tue, Nov 14, 2000 at 08:14:09AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 18:16:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d55dc547ae7d766fdda422c45d20cbbb Status: R X-Status: N On Tue, Nov 14, 2000 at 08:14:09AM +0100, Yann Guidon wrote:

[upper bits in non-SIMD byte operations]
> 2 points here : "set to zero" is not recommended, but it's not specified either.
> long ago, i have found a way to do the partial writes on the registers.
> this means that for the execution unit, all operations are SIMD, and the SIMD
> flag only operates when the write back occurs. this keeps your job simple.

Fine :)  But it makes the crossbar and/or instruction decoder more
complex, right?

> so you can remember : the partial reads are not a problems because everything
> is read at the same time, only write back is partial. do you prefer that ? :-)

What about `div.b r1, r2, r3', for example?  Will it read r3, too?
And how will it handle divide-by-zero exceptions?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From DuaneMHunt170976@aol.com Tue Nov 14 19:10:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00326 for ; Wed, 15 Nov 2000 16:04:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:26 +0100 (MET) Received: (qmail 29506 invoked by uid 0); 14 Nov 2000 18:10:52 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx10) with SMTP; 14 Nov 2000 18:10:52 -0000 X-eGroups-Return: sentto-1101623-1456-974225446-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 14 Nov 2000 18:10:48 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 18:10:45 -0000 Received: (qmail 61594 invoked from network); 14 Nov 2000 18:10:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 14 Nov 2000 18:10:45 -0000 Received: from unknown (HELO imo-r05.mail.aol.com) (152.163.225.5) by mta1 with SMTP; 14 Nov 2000 18:10:45 -0000 Received: from DuaneMHunt170976@aol.com by imo-r05.mx.aol.com (mail_out_v28.32.) id a.5b.df2e00b (16781) for ; Tue, 14 Nov 2000 13:10:35 -0500 (EST) Message-ID: <5b.df2e00b.2742da1b@aol.com> To: f-cpu@egroups.com X-Mailer: Windows AOL sub 103 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 13:10:35 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Some Questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d3184c9370e5da83eaae8ec10a81b725 Status: R X-Status: N hay did any one else computer go FUNNY YESTERDAY ie 13th Nov
eGroups Sponsor
From Nicolas Boulay Tue Nov 14 22:26:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00397 for ; Wed, 15 Nov 2000 16:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:44 +0100 (MET) Received: (qmail 11572 invoked by uid 0); 14 Nov 2000 21:24:36 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx10) with SMTP; 14 Nov 2000 21:24:36 -0000 X-eGroups-Return: sentto-1101623-1457-974237051-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by hi.egroups.com with NNFMP; 14 Nov 2000 21:24:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 21:24:09 -0000 Received: (qmail 3931 invoked from network); 14 Nov 2000 21:24:07 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 14 Nov 2000 21:24:07 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 14 Nov 2000 22:25:12 -0000 Received: from ifrance.com (nas8-139.vlt.club-internet.fr [194.158.111.139]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA22215 for ; Tue, 14 Nov 2000 22:24:04 +0100 (MET) Message-ID: <3A11AE0A.2B2D4484@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A10E644.59686B68@f-cpu.org> <20001114181115.01122@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 22:26:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 956fe2a80f61ba1794385a3a61901e07 Status: R X-Status: N
>
> Too bad that I don't understand french, and know next to nothing about
> the things you discuss on the mailing list next door (and no, I don't
> read the german list either -- my credo is: one project, one language,
> one mailing list ;).

I admire you ;) I don't like to lose time to find my word to explain
things in english. But i will try :)

The main idea try to solve the folowing problem : How to manage cache
and local memory coherency. We have 4 algorithmes.

Central server (uncachable memory), Migration (one copy of the data that
move thought the network with a central data location center),
read-replication (many copy of the data in case of write, we INVALIDATE
the other copy, there're also a central data location center),
Full-replication (idem but the data are propagate).

One this, you use Mutex variable. The idae behind that that you don't
need to update an object written inside a critical section cover by a
mutex. When you go out of the cs you could send your messages thought
the network.

The granularity is low, we need to manage cache page.

Some question ?

nicO

>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
eGroups Sponsor
From Nicolas Boulay Tue Nov 14 22:45:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00406 for ; Wed, 15 Nov 2000 16:04:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:47 +0100 (MET) Received: (qmail 27421 invoked by uid 0); 14 Nov 2000 21:54:45 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx21) with SMTP; 14 Nov 2000 21:54:44 -0000 X-eGroups-Return: sentto-1101623-1458-974238200-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 14 Nov 2000 21:43:28 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 21:43:20 -0000 Received: (qmail 66090 invoked from network); 14 Nov 2000 21:43:19 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 14 Nov 2000 21:43:19 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 14 Nov 2000 21:43:19 -0000 Received: from ifrance.com (nas15-93.vlt.club-internet.fr [195.36.165.93]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA11628 for ; Tue, 14 Nov 2000 22:43:17 +0100 (MET) Message-ID: <3A11B26D.F3214A40@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> <3A1056B4.6DC5A45A@ifrance.com> <001301c04dc8$681aaaf0$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 22:45:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fb7a7ea7c7acfe597d3fe756ba29116d Status: R X-Status: N

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > SUN use a crossbar and a 512bit with bus, and it's very expensive= ... So
> > a quick link could be funny. Serial link are very impressive BUT = wiring
> > is horrible (see the problem of RDRAM) and the connector are very=
> > expensive and the latence much horrible (that could kill your mul= ti-cpu
> > device).
>
> The latency issue with RDRAM is not so much caused by it being serial = IMO
> but by it being packetized just like the given design, and wiring isnt= so
> much horrible as very strict IMO.

*~<;-)) it's the opposite ! Like every memory, you have a complete
random acces cycle time of around 50 ns. So with a big pipeline (~40
stages) you could send many acces request interlaced (there are 32 banks inside a RDRAM vs 4 in SDRAM) during this latency. But it's hard to
manage this interlacing. But the worst thing is when you put a second
RIMM in this soket. You increase the overall latency ! Because the load
is bigger (at ~400 Mhz for the PC800). And the controlor should manage
this automagically ! (that's why there are only 2 RIMM socket instead of 3)

And at 400 Mhz, you can't make want you want with wires.

nicO
> Personally I like a fully differential bus
> like BLVDS.
>
> Marco
>

eGroups Sponsor=
3D""
From Yann Guidon Tue Nov 14 23:31:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00420 for ; Wed, 15 Nov 2000 16:04:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:51 +0100 (MET) Received: (qmail 32049 invoked by uid 0); 14 Nov 2000 22:26:27 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx05) with SMTP; 14 Nov 2000 22:26:27 -0000 X-eGroups-Return: sentto-1101623-1459-974240778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 14 Nov 2000 22:26:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 22:26:17 -0000 Received: (qmail 3575 invoked from network); 14 Nov 2000 22:26:16 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 Nov 2000 22:26:16 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 14 Nov 2000 23:27:22 -0000 Received: from f-cpu.org (nas1-252.aub.club-internet.fr [195.36.150.252]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA14122 for ; Tue, 14 Nov 2000 23:26:13 +0100 (MET) Message-ID: <3A11BD2D.5481B964@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 23:31:09 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] yet another bus proposal. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 89a2ff9bf4da5320697973f5b15017f3 Status: R X-Status: N hello,

after all the discussions about the f-bus, here's my new
contribution. it is derived from the previous ideas but
it is "adapted" to fit the constraints.

it is in fact a dual-bus, with two fixed-directions
multiplexed 16-bit datapaths. Theoretically, it "does"
look like a 32-bit bus when used symmetrically
(ie : linear scan of an array with cache thrashing).
OTOH, when other algos are used, it may look underused
(are there studies about the use of the directions
on a data bus ???).

So this solved the bus turnaround problem. the pins
are fixed as input or output once for all. OTOH, management
is a complete new problem, most of all the addresses are
split into 16-bit chunks. This gives the possibility
(for example) to send only the modified parts of an address,
or extend to large addressing spaces (>32 bits). 48-bit
or 64-bit addressing is possible, messages can be sent
(IRQ, prefetch, error notices...), but the state machine
that describe the protocol gets complex here.
i try a configuration where the ACK is only checked when a
"block" (series of similar packets, ie contiguous data packets
or address packets) is ended. for example, we send an address
block, and we wait for an ACK before we send/receive the data.
it's getting really complex... it looks like TCP :-)
Now it's completely synchronous : same clock for both ends
of the bus (both ways too). it's clocked at the max speed of
the slowest device with an external signal (hardwired/PCB).
is it simple enough ?

Since the bus is symmetrical, each "way" can send addresses
and querry data at will. transactional accesses are required
when the latency and the packet complexity increase.
i'm still trying to find an efficient and simplistic protocol.
stay tuned. i do that in the train, on the way from/to work,
that leaves me around 2 hours/day of pseudo-solitude that
i use to study the f-cpu specs. i have almost no time, though,
to write the results to the list.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From asdean Wed Nov 15 00:33:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00435 for ; Wed, 15 Nov 2000 16:04:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:54 +0100 (MET) Received: (qmail 6364 invoked by uid 0); 14 Nov 2000 23:31:15 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 14 Nov 2000 23:31:15 -0000 X-eGroups-Return: sentto-1101623-1460-974244670-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 14 Nov 2000 23:31:13 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 14 Nov 2000 23:31:09 -0000 Received: (qmail 3698 invoked from network); 14 Nov 2000 23:31:09 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 14 Nov 2000 23:31:09 -0000 Received: from unknown (HELO localhost.localdomain) (212.27.46.30) by mta3 with SMTP; 15 Nov 2000 00:32:14 -0000 Received: from infolibre.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 44E67E for ; Wed, 15 Nov 2000 00:33:10 +0100 (CET) Sender: root@localhost.localdomain Message-ID: <3A11CBB5.AA94EA9B@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A11BD2D.5481B964@f-cpu.org> From: asdean MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 00:33:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] yet another proposal. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b8abb7121762e5cb806aa1ccc95c397b Status: R X-Status: N Yann Guidon a =E9crit :

hello,

after all the discussions about the f-cpu, here's my new
contribution. it is derived from erim32
eGroups Sponsor=
3D""
From "Marco Al" Wed Nov 15 01:14:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00438 for ; Wed, 15 Nov 2000 16:04:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:55 +0100 (MET) Received: (qmail 7198 invoked by uid 0); 15 Nov 2000 00:09:54 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx02) with SMTP; 15 Nov 2000 00:09:54 -0000 X-eGroups-Return: sentto-1101623-1461-974246929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hk.egroups.com with NNFMP; 15 Nov 2000 00:09:53 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 00:08:48 -0000 Received: (qmail 25164 invoked from network); 15 Nov 2000 00:08:47 -0000 Received: from unknown (10.1.10.142) by m4.onelist.org with QMQP; 15 Nov 2000 00:08:47 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 15 Nov 2000 01:09:53 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA20344 for ; Wed, 15 Nov 2000 01:08:46 +0100 (MET) Message-ID: <002a01c04e99$0b450790$29e65982@student.utwente.nl> To: References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A10E644.59686B68@f-cpu.org> <20001114181115.01122@thrai.stud.uni-hannover.de> <3A11AE0A.2B2D4484@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 01:14:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 120224baaf723570be317880d45b41ba Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>


> Migration (one copy of the data that move thought the network with a
> central data location center),

COMA always sounds nice, but why isnt it performing in the market? (see the
latest SUN supercomputer debacle)

> One this, you use Mutex variable. The idae behind that that you don't
> need to update an object written inside a critical section cover by a
> mutex. When you go out of the cs you could send your messages thought
> the network.

How would the hardware know wich memory was covered by the mutex?

Marco
eGroups Sponsor
From "Marco Al" Wed Nov 15 01:33:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00441 for ; Wed, 15 Nov 2000 16:04:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:56 +0100 (MET) Received: (qmail 11725 invoked by uid 0); 15 Nov 2000 00:27:53 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx22) with SMTP; 15 Nov 2000 00:27:53 -0000 X-eGroups-Return: sentto-1101623-1462-974248070-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by mw.egroups.com with NNFMP; 15 Nov 2000 00:27:52 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 00:27:49 -0000 Received: (qmail 3334 invoked from network); 15 Nov 2000 00:27:49 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 15 Nov 2000 00:27:49 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 15 Nov 2000 00:27:49 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA24445 for ; Wed, 15 Nov 2000 01:27:48 +0100 (MET) Message-ID: <002e01c04e9b$b3e3ebd0$29e65982@student.utwente.nl> To: References: <3A11BD2D.5481B964@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 01:33:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] yet another bus proposal. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b680e2d5dfe6b4beba854219a685d8eb Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> So this solved the bus turnaround problem. the pins
> are fixed as input or output once for all. OTOH, management
> is a complete new problem, most of all the addresses are
> split into 16-bit chunks. This gives the possibility
> (for example) to send only the modified parts of an address,
> or extend to large addressing spaces (>32 bits). 48-bit
> or 64-bit addressing is possible, messages can be sent
> (IRQ, prefetch, error notices...), but the state machine
> that describe the protocol gets complex here.
> i try a configuration where the ACK is only checked when a
> "block" (series of similar packets, ie contiguous data packets
> or address packets) is ended. for example, we send an address
> block, and we wait for an ACK before we send/receive the data.
> it's getting really complex... it looks like TCP :-)

Why do you need the ACK, wouldnt a signal to indicate a nearly full FIFO
suffice?

> Now it's completely synchronous : same clock for both ends
> of the bus (both ways too).

Completely synchronous... why not take the last step and make it source
synchronous?

Marco
eGroups Sponsor
From Keyshaun Wed Nov 15 01:50:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00444 for ; Wed, 15 Nov 2000 16:04:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:57 +0100 (MET) Received: (qmail 30839 invoked by uid 0); 15 Nov 2000 00:50:17 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 15 Nov 2000 00:50:17 -0000 X-eGroups-Return: sentto-1101623-1463-974249408-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 15 Nov 2000 00:50:15 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 00:50:07 -0000 Received: (qmail 9752 invoked from network); 15 Nov 2000 00:50:06 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Nov 2000 00:50:06 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 15 Nov 2000 01:51:12 -0000 Received: (qmail 27399 invoked from network); 15 Nov 2000 00:50:05 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 15 Nov 2000 00:50:05 -0000 X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 17:50:05 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Designing a CMOS mask Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b8162c232b972f47f4cea67322038460 Status: R X-Status: N Hi, I know this is quite off topic and as far as this project goes way
early.  None the less I am interested in the process of designing a CMOS
mask.  If I can find out about the design of gates and how they are
implemented in the mask I may be considering something right out of Asimov
that could acellerate the process of designing any kind of chip,
processors included but more complex.  Would the CE department at my local
university (Univ. of Utah) be a good place to start?  If not what would be
a good place.  You know, I must explore more projects in the goal of
designing a Free Computer.  And yes, I am now considering the LEON more,
but I like F-CPU more than LEON.  The website will be a few days yet, but
it's on its way.

Shaun
eGroups Sponsor
From Jonathan Vaughn Wed Nov 15 04:27:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00450 for ; Wed, 15 Nov 2000 16:04:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:58 +0100 (MET) Received: (qmail 7097 invoked by uid 0); 15 Nov 2000 03:28:43 -0000 Received: from hk.egroups.com (208.50.99.220) by mx11.rz2.gmx.net (mx11) with SMTP; 15 Nov 2000 03:28:43 -0000 X-eGroups-Return: sentto-1101623-1464-974258882-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 15 Nov 2000 03:28:11 -0000 X-Sender: silverh@mindspring.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 03:28:01 -0000 Received: (qmail 32423 invoked from network); 15 Nov 2000 03:28:01 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 15 Nov 2000 03:28:01 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by mta2 with SMTP; 15 Nov 2000 03:28:01 -0000 Received: from sehnsucht (user-33qsdgd.dialup.mindspring.com [199.174.54.13]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id WAA03564; Tue, 14 Nov 2000 22:27:59 -0500 (EST) Message-Id: <3.0.6.32.20001114212758.008f7770@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, fm In-Reply-To: <3A11BD2D.5481B964@f-cpu.org> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 21:27:58 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] yet another bus proposal. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64505381f4419d1f44572e601a94da17 Status: R X-Status: N At 11:31 PM 11/14/00 +0100, Yann Guidon wrote:
>hello,
>
>after all the discussions about the f-bus, here's my new
>contribution. it is derived from the previous ideas but
>it is "adapted" to fit the constraints.
>
*snip*
>of the bus (both ways too). it's clocked at the max speed of
>the slowest device with an external signal (hardwired/PCB).
>is it simple enough ?

Hi, haven't been reading lately much, just letting it pile and ignoring it.
Hopefully I'll get back into things soon, at least to a discussion
participation
degree... Here's my 2 cents on the slowest device idea: Bad for the same
reason
that Rambus's use of it is bad. You have to find the slowest device, do some
timing calculations, etc, to find out how slow to go. someone mentioned going
source syncronous - this is really the way to do it. in fact, make it so the
source is clocking the data, and the clock can vary. great for power saving,
and just put some sort of speed cap (or have some way of signaling that a
device
can accept no more than xMHz or xGHz of speed, as there will be limitations
inherit in the manufacturing of the devices - but a straight top end cap is
simpler)

-JV
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
From Jonathan Vaughn Wed Nov 15 04:30:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00453 for ; Wed, 15 Nov 2000 16:04:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:04:59 +0100 (MET) Received: (qmail 5181 invoked by uid 0); 15 Nov 2000 03:30:33 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx03) with SMTP; 15 Nov 2000 03:30:33 -0000 X-eGroups-Return: sentto-1101623-1465-974259019-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 15 Nov 2000 03:30:30 -0000 X-Sender: silverh@mindspring.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 03:30:19 -0000 Received: (qmail 38496 invoked from network); 15 Nov 2000 03:30:18 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 Nov 2000 03:30:18 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by mta1 with SMTP; 15 Nov 2000 03:30:18 -0000 Received: from sehnsucht (user-33qsdgd.dialup.mindspring.com [199.174.54.13]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id WAA29393; Tue, 14 Nov 2000 22:30:15 -0500 (EST) Message-Id: <3.0.6.32.20001114213014.008f8490@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: <3A11B26D.F3214A40@ifrance.com> References: <3A0E1A35.141B55BC@f-cpu.org> <3A0F1FB5.3D801F67@ifrance.com> <3A0F3833.BD5B6486@f-cpu.org> <3A1056B4.6DC5A45A@ifrance.com> <001301c04dc8$681aaaf0$29e65982@student.utwente.nl> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 21:30:14 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7a50e244bf9b7b5439750b948591893f Status: R X-Status: N At 10:45 PM 11/14/00 +0100, Nicolas Boulay wrote:
>
>
>Marco Al a =E9crit :
>>
>> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>= ;
>>
>> > SUN use a crossbar and a 512bit with bus, and it's very expen= sive... So
>> > a quick link could be funny. Serial link are very impressive = BUT wiring
>> > is horrible (see the problem of RDRAM) and the connector are = very
>> > expensive and the latence much horrible (that could kill your= multi-cpu
>> > device).
>>
>> The latency issue with RDRAM is not so much caused by it being ser= ial IMO
>> but by it being packetized just like the given design, and wiring = isnt so
>> much horrible as very strict IMO.
>
>*~<;-)) it's the opposite ! Like every memory, you have a complete >random acces cycle time of around 50 ns. So with a big pipeline (~40 >stages) you could send many acces request interlaced (there are 32 bank= s
>inside a RDRAM vs 4 in SDRAM) during this latency. But it's hard to
>manage this interlacing. But the worst thing is when you put a second >RIMM in this soket. You increase the overall latency ! Because the load=
>is bigger (at ~400 Mhz for the PC800). And the controlor should manage<= BR> >this automagically ! (that's why there are only 2 RIMM socket instead o= f
>3)
>
>And at 400 Mhz, you can't make want you want with wires.
>

The reason it's got horrid latency is the packet nature, the serialization,=
and to a very large degree, ever device slows itself down so that they all<= BR> take as long to respond as the one furthest out. Also, each chip is hooked<= BR> up in a chain, so in fact, if there are say 4 chips on a RIMM, the first 3<= BR> slow down to be as slow as the delay for the 4th, and if you drop in anothe= r
RIMM, they will probably end up more than doubling the delay for the first<= BR> RIMM.

Lots of complex boot time stuff calculates these delays..

-JV
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_vide= o/
eGroups Sponsor=
3D""
From Jonathan Vaughn Wed Nov 15 05:38:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00456 for ; Wed, 15 Nov 2000 16:05:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:00 +0100 (MET) Received: (qmail 31735 invoked by uid 0); 15 Nov 2000 04:38:47 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx16) with SMTP; 15 Nov 2000 04:38:47 -0000 X-eGroups-Return: sentto-1101623-1466-974263125-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 15 Nov 2000 04:38:46 -0000 X-Sender: silverh@mindspring.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 04:38:43 -0000 Received: (qmail 22108 invoked from network); 15 Nov 2000 04:38:42 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 15 Nov 2000 04:38:42 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by mta2 with SMTP; 15 Nov 2000 04:38:42 -0000 Received: from sehnsucht (user-33qsdgd.dialup.mindspring.com [199.174.54.13]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id XAA30352 for ; Tue, 14 Nov 2000 23:38:36 -0500 (EST) Message-Id: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> X-Sender: silverh@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Nov 2000 22:38:29 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4752880a3c1bf8b864fbf6c3cb0663ba Status: R X-Status: N I'm thinking about this.. several ideas, which I will try to make more
specific
in a bit...

not all of the ideas necessarilly to be used at once or together at all..

- use source clocking, preferably with several clocks (say one for each 8 bits
of signals, so that having the pins spread around on the chips won't be an
issue - and also allow much higher speeds even when they are grouped together.
they could be set up with blocks of 9 pins, with the center being the clock)

- allow the f-bus pins to be shared with a generic bus that could interface to
older/slower/dumber peripherals, but you can't do both - just one or the
other.
would eliminate need of G-Chip for embedded uses for example. example of a
flexible bus for peripherals is the Motorola ColdFire 5307 and similar...

- if using the above on a G-Chip as well, you could interface to multiple type
chips at a time, say one F-Bus/Dumb-bus port set for IDE, another for
opreating
an ISA bus with say ethernet on it, and the other two to talk to the CPUs.

- you could use two of the G-Chip busses for CPUs, another to talk to another
G-chip, and another to talk to a hypothetical F-Bus to PCI bridge, and other
various combinations. you could put three CPUs on one GChip and use the
fourth
bus to talk to another GChip, or ... etc

-----

some issues: this gets really damn complex. Another idea, would be to have the
F-Bus, and then have the F-CPU be able to switch its pins on boot from
F-Bus to
generic dumb async bus, and then either have a dedicated dumb bus on the GChip
or have only one switchable.

I've been trying to figure out how to get gobs of bandwidth moving around,
while
not having too many pins. I.e., at least 2 or 3GB/s, with latency that isn't
extreme, and so forth.

How many pins can we get away with on the G Chip? How fast can we send a
signal
when using source clocking over a 4" to 6" distance (distance between opposite
sides of adjacent F/G-chips)... ?

-----

I think the F-Bus, should provide for both blocking (wait and tie up bus until
we get our data) and non-blocking (i.e., say get me memory at address Z, and
here's the transaction ID X; the chip saying this then can keep going w/
other
things until it is told by the other chip 'here is the data for transaction
ID
X'), 8 or even 4 should be enough IDs (3 or 2 bits). Perhaps we can flag
transaction ID 0 as being blocking, and use it that way... transaction
requests
should specify a length and start offset (or just full address), if the later
sent back data can't be sent in so long a burst, it just gets terminated when
the sending chip has reached it's limit (say sending from slower chip, and
ran
out of buffer), and the requester has to request the rest again...

thoughts?

also, how about for the blocking requests, being able to specify a length
also,
in multiples of the granularity? for blocking requests the returned data is
only
terminated when it reaches the end or there is an error, otherwise, the sender
just inserts waitstates - after all we WERE willing to wait for our data.

...

ok enough rambling.. I think.. that is, ifI can, through this caffeine low
haze..

-JV
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
From Yann Guidon Wed Nov 15 06:47:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00465 for ; Wed, 15 Nov 2000 16:05:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:06 +0100 (MET) Received: (qmail 15532 invoked by uid 0); 15 Nov 2000 05:42:26 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx21) with SMTP; 15 Nov 2000 05:42:26 -0000 X-eGroups-Return: sentto-1101623-1467-974266940-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fj.egroups.com with NNFMP; 15 Nov 2000 05:42:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 05:42:19 -0000 Received: (qmail 55474 invoked from network); 15 Nov 2000 05:42:19 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Nov 2000 05:42:19 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 15 Nov 2000 06:43:24 -0000 Received: from f-cpu.org (nas1-155.ras.club-internet.fr [195.36.192.155]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA05168 for ; Wed, 15 Nov 2000 06:42:15 +0100 (MET) Message-ID: <3A122361.2AE5A090@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 06:47:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: Let the EC know what you think about software patents] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2c48f84e75d75ce973679fed42b50b64 Status: R X-Status: N Hello,

The situation regarding patents in Europe is going to change
drastically if nobody acts. Please read this letter carefully
and don't let the industrial lobbies steal our freedom of
creation.

YG

-------- Original Message --------
From: petition@eurolinux.org
Subject: Let the EC know what you think about software patents

Dear Sir,
Dear Madam,

The European Commission is currently researching the economic impact of
software patents. For quite obvious reasons, many patent attorneys and
IP lawyers who earn money through the patent system are currently lobbying
the European Commission in favor of a broad extension of the patent system
to software, business methods, intellectual methods, etc.

Unless you express your own opinion, only their opinion will be taken into
account in the decision process, whatever the consequences on your business,
whatever the consequences on innovation.

It is therefore very important and urgent, if you consider software patents
to be more harmful than useful, to send your opinion by email to:

      consultation@eurolinux.org

as soon as possible and, in any case, before December 15th, 2000. You
can write in the official language of any member country of the European
Union.

Your email will then be forwarded to the European Commission and published on
the EuroLinux Web in order to make sure that your point of view is taken into
consideration:

      http://petition.eurolinux.org/consultation

There is currently a consensus among economists on the fact that software
patents tend to stifle innovation and harm small and medium enterprises
because they create tremendous juridical uncertainty which only benefits to
patent attorneys and lawyers. There is also a consensus among patent
attorneys on the fact that patents on business methods are just a kind of
software patents and that it is impossible to ban business method patents
once software patents become legal.

Please write serious (but not necessarily long) emails, with a consistent
analysis based on economics, technology or real world examples from your
everyday practice. Here are a few advice for your email to reach maximal impact
within the European Commission:

      1- NO POLITICS - Do not include in your emails any political analysis.
Otherwise, certain civil servants at the European Commission will pretend that
you are politically biased and claim that your arguments are irrelevant.

      2- FREE MARKET RHETORICS - Use rhetorics based on free market,
competition, innovation, entrepreneurship, SMEs and property, just as if you
were the chief of the federation of enterprises in your country. EuroLinux has
experienced that "free market economy" is currently the only common language
which most civil servants at the European Commission understand. In order to
let them understand your point of view and take it into account, it is
compulsory to speak their language. Arguments based on epistemology, ethics or
history are acceptable but have in general no positive impact on the European
Commission because only few people will understand them.

      3- DAVOS COMPATIBLE - Imagine that you are introducing your point of
view at the Davos Economic Forum in front of CEOs who will only listen to you
if your arguments mean more profits to them. Incidentally, many Commissioners
at the European Commission used to be members of the steering committee of the
Davos Economic Forum.

      4- CONSENSUS AMONG ECONOMISTS - Always mention that there is a
consensus among economists on the fact that software patents harm innovation.

Please understand that our advice does not represent any political point of
view of the EuroLinux Alliance and is strictly designed at helping you to
present your arguments in such way that they are going to be taken into
account by the European Commission.

For more information on software patents, please read our knowledge
database and follow the links:

      http://petition.eurolinux.org/consultation
      http://petition.eurolinux.org/pr/pr5.html

If you need inspiration to write your own statement, you may also access our
statements database where 100 European companies have already published
position statements:

      http://petition.eurolinux.org/statements

Best regards,

EuroLinux Alliance
petition@eurolinux.org
http://petition.eurolinux.org
eGroups Sponsor
From Yann Guidon Wed Nov 15 07:27:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00468 for ; Wed, 15 Nov 2000 16:05:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:07 +0100 (MET) Received: (qmail 4910 invoked by uid 0); 15 Nov 2000 06:22:34 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx22) with SMTP; 15 Nov 2000 06:22:34 -0000 X-eGroups-Return: sentto-1101623-1468-974269349-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by hp.egroups.com with NNFMP; 15 Nov 2000 06:22:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 06:22:28 -0000 Received: (qmail 30794 invoked from network); 15 Nov 2000 06:22:28 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Nov 2000 06:22:28 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 15 Nov 2000 06:22:27 -0000 Received: from f-cpu.org (nas2-206.ras.club-internet.fr [195.36.192.206]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA03871 for ; Wed, 15 Nov 2000 07:22:24 +0100 (MET) Message-ID: <3A122CC3.FE5811A2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 07:27:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 22650d3bfeea23a18c91b4ffe4178d7c Status: R X-Status: N Some unsorted comments before in jump in the train this morning :

- pin number : goal is around 60 to 70 pins for a 2*16 bus.
the least and simplest, the best.

- ack : yes, it is similar to a "FIFO full/empty" signal.
just a bit more subtle, but it's similar.

- clock : so how do we decide who fast it goes ?
fully synchronous and clock sourcing is ok, but how
to decide of the rate ? one idea was to use a PLL
with a "slower/faster" bit/signal for each end,
but it's an analog part and it's uneasy to set up with
off-the-shel components. Any better idea ?

please continue to give good ideas,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Thomas Page Wed Nov 15 07:52:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00471 for ; Wed, 15 Nov 2000 16:05:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:08 +0100 (MET) Received: (qmail 1918 invoked by uid 0); 15 Nov 2000 06:50:39 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx18) with SMTP; 15 Nov 2000 06:50:39 -0000 X-eGroups-Return: sentto-1101623-1469-974271036-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 15 Nov 2000 06:50:37 -0000 X-Sender: Paget@conlog.co.za X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 06:50:36 -0000 Received: (qmail 79471 invoked from network); 15 Nov 2000 06:50:35 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 Nov 2000 06:50:35 -0000 Received: from unknown (HELO conlognt.conlog.co.za) (216.2.176.8) by mta3 with SMTP; 15 Nov 2000 07:51:40 -0000 Received: by intranet.hq.conlog.co.za with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Nov 2000 08:52:59 +0200 Message-ID: <640F9ED3CD2DD211A28600A0C982788CB1EC62@intranet.hq.conlog.co.za> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2650.21) From: Thomas Page MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 08:52:55 +0200 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5e5f5db34b33d9416676dbece675776e Status: R X-Status: N > -----Original Message-----
> From: Yann Guidon [mailto:whygee@f-cpu.org]
> Sent: 15 November 2000 08:27
> To: f-cpu@egroups.com
> Subject: Re: [f-cpu] F-Bus, G-Chip
>
>
> Some unsorted comments before in jump in the train this morning :
>
>
> please continue to give good ideas,
> WHYGEE


Hi Whygee

I joined the f-cpu list for the sake of interest, reference and inspiration.
However, my main interest is in working toward a multiprocessor machine that
really works fast and is economically viable, ie cheap. Linux helps me do
this, and I have been thinking/researching which processor(s) to use (this
is when I found f-cpu).

One big issue is buses, I've put a lot of thought into it, and want to try
it. I want it to be 100% open though, if only to make sure that some big
corporation cannot steal and patent it (I hate patents).

I will prepare it and post it to this list toward the end of this week.

ThomasP
eGroups Sponsor
From "Marco Al" Wed Nov 15 10:34:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00513 for ; Wed, 15 Nov 2000 16:05:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:19 +0100 (MET) Received: (qmail 21776 invoked by uid 0); 15 Nov 2000 09:28:45 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx21) with SMTP; 15 Nov 2000 09:28:45 -0000 X-eGroups-Return: sentto-1101623-1470-974280519-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 15 Nov 2000 09:28:43 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 09:28:38 -0000 Received: (qmail 24474 invoked from network); 15 Nov 2000 09:28:38 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 Nov 2000 09:28:38 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 15 Nov 2000 10:29:43 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id KAA13552 for ; Wed, 15 Nov 2000 10:28:36 +0100 (MET) Message-ID: <001101c04ee7$4170d760$29e65982@student.utwente.nl> To: References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 10:34:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 918ba3f28d94dd4cc0243e027930d1b0 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> Some unsorted comments before in jump in the train this morning :
>
> - pin number : goal is around 60 to 70 pins for a 2*16 bus.
> the least and simplest, the best.

Differential or still TTL compatible or...?

> - ack : yes, it is similar to a "FIFO full/empty" signal.
> just a bit more subtle, but it's similar.

As subtle as a brick :) I only see disadvantages giving it at full
instead of nearly full. Gates are cheap, destroying concurrency is not.
What am I missing?

> - clock : so how do we decide who fast it goes ?
> fully synchronous and clock sourcing is ok, but how
> to decide of the rate ? one idea was to use a PLL
> with a "slower/faster" bit/signal for each end,
> but it's an analog part and it's uneasy to set up with
> off-the-shel components. Any better idea ?

Use a common clock and use static multipliers/configuration
(dip-switches/boot time low rate handshaking/whatever). If you
absolutely want dynamic changes in the multiplier nothing has to change
>from that static case, just put negotiation into the protocol.

BTW what about LDT?  I think AMD has a royaltee free license...

Marco
eGroups Sponsor
From Nathaniel Downes Wed Nov 15 15:05:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00561 for ; Wed, 15 Nov 2000 16:05:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 15 Nov 2000 16:05:33 +0100 (MET) Received: (qmail 23198 invoked by uid 0); 15 Nov 2000 14:10:10 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net (mx09) with SMTP; 15 Nov 2000 14:10:10 -0000 X-eGroups-Return: sentto-1101623-1471-974297064-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mu.egroups.com with NNFMP; 15 Nov 2000 14:04:44 -0000 X-Sender: down@ici.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 14:04:24 -0000 Received: (qmail 44267 invoked from network); 15 Nov 2000 14:04:23 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 15 Nov 2000 14:04:23 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta2 with SMTP; 15 Nov 2000 14:04:22 -0000 Received: from storm (downix@dc-57-61.ici.net [207.180.57.61]) by bajor.ici.net (8.8.8/8.8.8) with SMTP id JAA08891 for ; Wed, 15 Nov 2000 09:04:40 -0500 (EST) Organization: Eddas, Inc To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <640F9ED3CD2DD211A28600A0C982788CB1EC62@intranet.hq.conlog.co.za> In-Reply-To: <640F9ED3CD2DD211A28600A0C982788CB1EC62@intranet.hq.conlog.co.za> Message-Id: <00111509063501.00843@storm> From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 09:05:17 -0500 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 617e9e5a585fdc4e36f9b72ef350743b Status: R X-Status: N On Wed, 15 Nov 2000, you wrote:
> <html><body>
> <tt>
> &gt; -----Original Message-----<BR>
> &gt; From: Yann Guidon [mailto:whygee@f-cpu.org]<BR>
> &gt; Sent: 15 November 2000 08:27<BR>
> &gt; To: f-cpu@egroups.com<BR>
> &gt; Subject: Re: [f-cpu] F-Bus, G-Chip<BR>
> &gt; <BR>
> &gt; <BR>
> &gt; Some unsorted comments before in jump in the train this morning :<BR>
> &gt; <BR>
> &gt; <BR>
> &gt; please continue to give good ideas,<BR>
> &gt; WHYGEE<BR>
> <BR>
> <BR>
> Hi Whygee<BR>
> <BR>
> I joined the f-cpu list for the sake of interest, reference and inspiration.<BR>
> However, my main interest is in working toward a multiprocessor machine that<BR>
> really works fast and is economically viable, ie cheap. Linux helps me do<BR>
> this, and I have been thinking/researching which processor(s) to use (this<BR>
> is when I found f-cpu).<BR>

I began with it myself in order to better learn how microprocessors work.  I'm
glad to see F-CPU shaping up here.

> <BR>
> One big issue is buses, I've put a lot of thought into it, and want to try<BR>
> it. I want it to be 100% open though, if only to make sure that some big<BR>
> corporation cannot steal and patent it (I hate patents).<BR>

If you can prove previous ownership nd stick to ideas that pre-exist, you can
usually avoid this.

> <BR>
> I will prepare it and post it to this list toward the end of this week.<BR>
> <BR>
> ThomasP<BR>
> </tt>
>
> <br>
>
> <!-- |**|begin egp html banner|**| -->
>
> <table border=0 cellspacing=0 cellpadding=2>
> <tr bgcolor=#FFFFCC>
> <td align=center><font size="-1" color=#003399><b>eGroups Sponsor</b></font></td>
> </tr>
> <tr bgcolor=#FFFFFF>
> <td width=470><!-- |@|begin eGroups banner|@| runid: 9663 crid: 3732 -->
> <a target="_blank" href="http://click.egroups.com/1/9663/0/_/3462/_/974271037/"><center>
> <img width="468" height="60"
>   border="0"
>   alt=""
>   src="http://adimg.egroups.com/img/9663/0/_/3462/_/974271037/WarningShopping468x602E.gif"></center><center><font color="black"></font></center></a>
> <!-- |@|end eGroups banner|@| --></td>
> </tr>
> </table>
>
> <!-- |**|end egp html banner|**| -->
>
>
>
> </body></html>
eGroups Sponsor
From Nicolas Boulay Wed Nov 15 18:46:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02215 for ; Thu, 16 Nov 2000 01:49:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:33 +0100 (MET) Received: (qmail 13578 invoked by uid 0); 15 Nov 2000 17:43:50 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx03) with SMTP; 15 Nov 2000 17:43:50 -0000 X-eGroups-Return: sentto-1101623-1472-974310220-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 15 Nov 2000 17:43:50 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 17:43:40 -0000 Received: (qmail 95097 invoked from network); 15 Nov 2000 17:43:38 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Nov 2000 17:43:38 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 15 Nov 2000 17:43:38 -0000 Received: from ifrance.com (nas24-147.vlt.club-internet.fr [195.36.223.147]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA04907 for ; Wed, 15 Nov 2000 18:43:35 +0100 (MET) Message-ID: <3A12CBE1.9776DE3A@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <001101c04ee7$4170d760$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 18:46:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e9b571771bc2b5a93771b2e4b649a6ef Status: R X-Status: N Marco Al a =E9crit :
>
> From: "Yann Guidon" <whygee@f-cpu.org>
>
> > Some unsorted comments before in jump in the train this morning :=
> >
> > - pin number : goal is around 60 to 70 pins for a 2*16 bus.
> > the least and simplest, the best.
>
> Differential or still TTL compatible or...?
>
LVTTL 3.3 V General Purpose
LVCMOS2 2.5 V General Purpose 
LVCMOS18** 1.8 V General Purpose 
PCI33_5*   33/66 MHz 5 V PCI Backplane
PCI33_3, PCI66_3 33/66 MHz 3.3 V PCI Backplane
SSTL2 (I,II), SSTL3(I,II), CTT SDRAM, DDR SRAM
HSTL(I,III,IV) SRAM, DDR SDRAM, Backplanes
GTL, GTL+, AGP Backplanes, Microprocessor Interfacing 
LVDS** Point-to-Point Backplanes, High Noise Immunity 
BLVDS**  Bus LVDS Backplanes, High Noise Immunity, Bus Architecture Backplanes 
LVPECL**  High Performance Clocking, Backplanes, Differential 100MHz+<= BR> Clocking, Optical Transceiver, High Speed Networking, and Mixed-Signal
Interfacing 
5 V TTL***( 4mA Iol )  Legacy 5V TTL Interfacing

Enough choices ?

> > - ack : yes, it is similar to a "FIFO full/empty" signa= l.
> > just a bit more subtle, but it's similar.
>
> As subtle as a brick :) I only see disadvantages giving it at full
> instead of nearly full. Gates are cheap, destroying concurrency is not= .
> What am I missing?
>
> > - clock : so how do we decide who fast it goes ?
> > fully synchronous and clock sourcing is ok, but how
> > to decide of the rate ? one idea was to use a PLL
> > with a "slower/faster" bit/signal for each end,
> > but it's an analog part and it's uneasy to set up with
> > off-the-shel components. Any better idea ?
>
> Use a common clock and use static multipliers/configuration
> (dip-switches/boot time low rate handshaking/whatever). If you
> absolutely want dynamic changes in the multiplier nothing has to chang= e
> from that static case, just put negotiation into the protocol.
>

Beark, use always the same fr=E9quencies and if you have a slow device use<= BR> a gateway and a fifo.

> BTW what about LDT?  I think AMD has a royaltee free license... >
> Marco
>

eGroups Sponsor=
3D""
From Nicolas Boulay Wed Nov 15 19:15:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02224 for ; Thu, 16 Nov 2000 01:49:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:36 +0100 (MET) Received: (qmail 16522 invoked by uid 0); 15 Nov 2000 18:14:03 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx18) with SMTP; 15 Nov 2000 18:14:03 -0000 X-eGroups-Return: sentto-1101623-1473-974312035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 15 Nov 2000 18:14:01 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 18:13:55 -0000 Received: (qmail 82341 invoked from network); 15 Nov 2000 18:13:54 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Nov 2000 18:13:54 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 15 Nov 2000 18:13:54 -0000 Received: from ifrance.com (nas22-36.vlt.club-internet.fr [195.36.172.36]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA14824 for ; Wed, 15 Nov 2000 19:13:47 +0100 (MET) Message-ID: <3A12D2DE.CB36F8D1@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A10E644.59686B68@f-cpu.org> <20001114181115.01122@thrai.stud.uni-hannover.de> <3A11AE0A.2B2D4484@ifrance.com> <002a01c04e99$0b450790$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 19:15:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f0e16e3e7f8bf8164d7e262983d3b336 Status: R X-Status: N Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > Migration (one copy of the data that move thought the network wit= h a
> > central data location center),
>
> COMA always sounds nice, but why isnt it performing in the market? (se= e the
> latest SUN supercomputer debacle)

Maybe, but hier we use all the 4 algorithmes. Read-replication for the
TEXT part of the programme (the code it-self). Migration, central memory for semaphore and replication for the data. The choice is made by the
User or the OS. The os could try different algo and choose the best.

>
> > One this, you use Mutex variable. The idae behind that that you d= on't
> > need to update an object written inside a critical section cover = by a
> > mutex. When you go out of the cs you could send your messages tho= ught
> > the network.
>
> How would the hardware know wich memory was covered by the mutex?
>

Arf, the big question. The simple answer is when enterring inside a
critical section, all the shared object aren't updated or invalidate
thought the network. And when you release the Mutex, you update all of
it.

The second answer is to put some informations with the mutex but this
could be horrible for the performance. And i think, it isn't usefull.

Anything else ?
nicO

> Marco
>
eGroups Sponsor=
3D""
From "Marco Al" Wed Nov 15 20:21:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02245 for ; Thu, 16 Nov 2000 01:49:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:44 +0100 (MET) Received: (qmail 20964 invoked by uid 0); 15 Nov 2000 19:16:06 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx14) with SMTP; 15 Nov 2000 19:16:06 -0000 X-eGroups-Return: sentto-1101623-1474-974315763-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by mk.egroups.com with NNFMP; 15 Nov 2000 19:16:04 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 19:15:57 -0000 Received: (qmail 32743 invoked from network); 15 Nov 2000 19:15:57 -0000 Received: from unknown (10.1.10.27) by m4.onelist.org with QMQP; 15 Nov 2000 19:15:57 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 15 Nov 2000 19:15:56 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id UAA01836 for ; Wed, 15 Nov 2000 20:15:55 +0100 (MET) Message-ID: <003901c04f39$4dd838c0$29e65982@student.utwente.nl> To: References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <001101c04ee7$4170d760$29e65982@student.utwente.nl> <3A12CBE1.9776DE3A@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 20:21:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8e2223c041373d4c8236785f4b500ca9 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> Enough choices ?

Well I think our choices are a bit more limited, but I wasnt asking for
choices... I was trying to gouge if he still wanted to hold on to that
part of the draft.

Marco
eGroups Sponsor
From "Marco Al" Wed Nov 15 20:24:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02248 for ; Thu, 16 Nov 2000 01:49:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:46 +0100 (MET) Received: (qmail 30999 invoked by uid 0); 15 Nov 2000 19:18:32 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx18) with SMTP; 15 Nov 2000 19:18:32 -0000 X-eGroups-Return: sentto-1101623-1475-974315897-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 15 Nov 2000 19:18:31 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 19:18:16 -0000 Received: (qmail 63394 invoked from network); 15 Nov 2000 19:18:16 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 15 Nov 2000 19:18:16 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 15 Nov 2000 19:18:16 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id UAA03020 for ; Wed, 15 Nov 2000 20:18:14 +0100 (MET) Message-ID: <003c01c04f39$a0b80ac0$29e65982@student.utwente.nl> To: References: <20001114021150.47353@thrai.stud.uni-hannover.de> <3A10E644.59686B68@f-cpu.org> <20001114181115.01122@thrai.stud.uni-hannover.de> <3A11AE0A.2B2D4484@ifrance.com> <002a01c04e99$0b450790$29e65982@student.utwente.nl> <3A12D2DE.CB36F8D1@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 20:24:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] G-chip draft Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2bfcba425283c5fe6d6cfcfda71f7991 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> > How would the hardware know wich memory was covered by the mutex?
> >
>
> Arf, the big question. The simple answer is when enterring inside a
> critical section, all the shared object aren't updated or invalidate
> thought the network. And when you release the Mutex, you update all of
> it.

Ok so basically that would mean additional instructions? (I was thinking
you perhaps had a way of using the existing caching hints in mind)

Marco
eGroups Sponsor
From Yann Guidon Wed Nov 15 23:51:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02269 for ; Thu, 16 Nov 2000 01:49:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:51 +0100 (MET) Received: (qmail 6915 invoked by uid 0); 15 Nov 2000 22:47:06 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx07) with SMTP; 15 Nov 2000 22:47:06 -0000 X-eGroups-Return: sentto-1101623-1479-974328421-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by ch.egroups.com with NNFMP; 15 Nov 2000 22:47:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 22:47:00 -0000 Received: (qmail 6626 invoked from network); 15 Nov 2000 22:47:00 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 15 Nov 2000 22:47:00 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 15 Nov 2000 22:46:59 -0000 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA11380 for ; Wed, 15 Nov 2000 23:46:53 +0100 (MET) Message-ID: <3A131387.DCC41EF1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 23:51:51 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] daily F-bus elaboration (+ bonus GIF !) Content-Type: multipart/mixed; boundary="------------065F850395A676335145556C" X-UIDL: 933b43ad575169b379dffacec7acb121 Status: R X-Status: N --------------065F850395A676335145556C Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

like often these times, i don't have time to post here
but i work enough in the train to come up with a slightly enhanced
solution.

objective :
- high performance bus without a complex technology (ie ECL or hairy stuff).
- simple protocol/state machine (well, that's the objective, not the facts...)
so it's easy to interface even with standard TTL parts (you know, LS245, 138
and 573 types...) at least at the functional level (it will certainly need a FPGA).
- scalable without big change : first version is a "32-bit" version, will be
64-bit then 128-bit etc... i've seen 1020 pin BGA chips and maybe it's possible
to use one in the future. scalability is not only putting more cores on a die.
- help reduce latency with reasonable means

main directions :
- 32-bits of paralle data bus.
- multiplexed data/addresses.
- point-to-point signals (no multi-point bus !) to garantee bandwidth
and forget priorities etc...
- completely symmetric transfer (ie any side can send an address...)
- fully synchronous, external clocking (well, clocking details will
certainly vary, it's not the object of the draft).
- able to address a huge amount of data on a very large scale system
  (hey, the latest T3E have run out of address pins !), allow easy
  "routing" with Xbar chips.
- able to reorder the words in a transaction (ie: we jump at address
8 of a 32-byte line, so we don't care about the contents of address 0,
we want to access the data at address 8 ASAP)[a bit similar to
today's PC chipsets]
- ability to handle transactional accesses (ie : send several addresses
and get the data after a while, during which we can still issue orders).
if 4 concurrent transactions seems to be enough, remember that the RDRAM
has a 40-stage pipeline, so 6 bits that "tag" the transaction will be needed
one day. the transaction ID should not be constrained in size, because the
gap between speed and latency will always increase. The situation gets even
worse on a very large scale system with hundreds of nodes to pass before we
can access the right data...

Latest decisions :
- unidirectional pins only : data bus is split into 2 symmetric "ways"
of 16-bit data path and control bits.
- protocol/pins (for each "way") :
   "data bus" : contains parts of the address or data
   "Opcode" : describes the current data
   "ACK" : if the internal buffers are ready
   "LSB/order" : either the LSB of the address to fetch, or the LSB
     of the address where the data was fetched (so we can support
     a fetch in the middle of a cache line).
optional :
   "ECC" : error detection/correction bits
   "tID" : transaction ID

description of the OpCode : (to be enhanced soon)
   0000 : Nop (cycle is inactive)
   0001 : Error (error number is on the data bus)
   0010 : IRQ (idem, see the data bus)
   0011 : the bus contains data (the LSB/order field says what part of the line it is)
   01xx : address read (part xx)
   10yy : address write (part yy)
   11zz : address prefetch (part zzz)
  
the first quarter is rather easy to understand, it can be decoded easily.
The address part is less straight-forward.

On the 16-bit bus, a 64-bit address is split into 4 parts, hence the 2 bits.
But we might issue addresses for different reasons : either we follow it with
data (we write to the device), or we request for data (reading said device),
or we simply prefetch. These are 3 different cases that can't be recognized
easily without adapted signaling. that's why we need the 3 remaining codes
in the MSB of the above array.
Plus, if we want to support OOO fetching, we have to issue the starting address
with its LSB, otherwise we'll get the whole cache line from the start, even
if we only care about the last words. So the LSB signals are used during the
first issue of a address read command.
These address commands should be sent in a precise order : from MSB to LSB,
so we ease the routing chip's work (the route is determined by the MSB...).
We can also start from the part that has not changed since the last transaction
(to reduce the bus occupation, just like when a DRAM page is read and only
column accesses are done). This means on a 64-bit address that if the LSB only has
changed, it will be sent without the whole rest (that's a potentially complex
and dangerous feature if not defined carefully).


Last things : let's see how an EPROM (ie boot BIOS) can be read with this
kind of system.

- the DATA bus of 2 EPROMs (or a 16-bit wide chip) is directly connected
to the input data bus of the device on the F-bus.
- The EPROM's OE (output enable) can be left as is, since the input data bus
is only validated/sampled on a "data" command on the inout control bus.
- The address is latched (LS573/574/whatever) when the command "read address part #0"
is detected (0100 according to the table). As soon as the address is latched,
an internal delay/counter can be triggered so it will send the "data" command
after the data is available from the EPROM (ie : 4-bit counter for a 150ns EPROM
on a 100MHz bus, or 15 cycles of latency).

I have enclosed a GIF picture that describes the functional design.
i tried to keep it as simple and cheap as possible. let's hope it works too :-)
Here we don't use at all the ECC and tID fields, let's do something simple first :-)


pin count estimations for 32- and 64-bit buses with/without ECC and tID :
             alone        ECC         tID     tID+ECC
32 bits       53          63           61       71
64 bits       81          93           91       103

details : pin count = clk + 2 x ( data [16/32] + Opcode + LSB + tID + ECC )
clk=1 (that's why all numbers are odd)
32 bits : data=16, opcode=4 (16 commands incl. NOP),
LSB=4 (16 bits * 2^4 = 256 bits = width of a cache line), ACK=1 bit, tID is 3 bits
   (for a small/low latency system), total = 28 pins -> ECC= 5 bits
64 bits : data=32, opcode=4 (10 commands), LSB=3, ACK=1, tID=5 (more latency) :
   total=40+5 bits -> ECC=6 bits

it is a reasonable pin count to my taste. the protocol is still a bit complex,
not even taking transactional access and ECC into account. But it's a decent
discussion and i am listening to your propositions. i don't think we can
shrink the bus more, it's not worth a single pin of difference (unless there
is a good reason). the 64-bit version seems not to be bloated, and the 32-bit
version can fit in a classic/cheap package. The 64-bit version looks like a
good compromise between bandwidth and pincount (price). Wider buses are maybe not
necessary in the future because we might prefer more buses and more interconnexions
with more neighbour chips.


ok i gotta leave.
read you soon !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
--------------065F850395A676335145556C Content-Type: image/gif; name="f-bus_eprom.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f-bus_eprom.gif" R0lGODlh7gE+AfcAAAAAAAAAMwAAZgAAmQAAzAAA/zMAADMAMzMAZjMAmTMAzDMA/2YAAGYA M2YAZmYAmWYAzGYA/5kAAJkAM5kAZpkAmZkAzJkA/8wAAMwAM8wAZswAmcwAzMwA//8AAP8A M/8AZv8Amf8AzP8A/wAzAAAzMwAzZgAzmQAzzAAz/zMzADMzMzMzZjMzmTMzzDMz/2YzAGYz M2YzZmYzmWYzzGYz/5kzAJkzM5kzZpkzmZkzzJkz/8wzAMwzM8wzZswzmcwzzMwz//8zAP8z M/8zZv8zmf8zzP8z/wBmAABmMwBmZgBmmQBmzABm/zNmADNmMzNmZjNmmTNmzDNm/2ZmAGZm M2ZmZmZmmWZmzGZm/5lmAJlmM5lmZplmmZlmzJlm/8xmAMxmM8xmZsxmmcxmzMxm//9mAP9m M/9mZv9mmf9mzP9m/wCZAACZMwCZZgCZmQCZzACZ/zOZADOZMzOZZjOZmTOZzDOZ/2aZAGaZ M2aZZmaZmWaZzGaZ/5mZAJmZM5mZZpmZmZmZzJmZ/8yZAMyZM8yZZsyZmcyZzMyZ//+ZAP+Z M/+ZZv+Zmf+ZzP+Z/wDMAADMMwDMZgDMmQDMzADM/zPMADPMMzPMZjPMmTPMzDPM/2bMAGbM M2bMZmbMmWbMzGbM/5nMAJnMM5nMZpnMmZnMzJnM/8zMAMzMM8zMZszMmczMzMzM///MAP/M M//MZv/Mmf/MzP/M/wD/AAD/MwD/ZgD/mQD/zAD//zP/ADP/MzP/ZjP/mTP/zDP//2b/AGb/ M2b/Zmb/mWb/zGb//5n/AJn/M5n/Zpn/mZn/zJn//8z/AMz/M8z/Zsz/mcz/zMz/////AP// M///Zv//mf//zP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA7gE+AQAI/gCvCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KFCYAgU8JRgVAterAqFevVd3aVOjTrVQNYoU4titCrlmlagX7FWza rGzLmtU5dezUgnfVvp3rM29CuQ4B87W7V6teqHgRHzbM9+ddrH4VlyXcuK/ivxQFm5UbmfFl z5ITF66c83HayZ9BA4Z8OuxlzaQtslbY9i1k16kHi01Nmbfv0Z5nW30d+2Pe46JRA59tWDjw 4rKvosWLPDTx2Jx/f1auPHdwuKef/kOvWL3u9O6g1X5N/x32eInMz4a3Lpp09vS9156vzx7x +vvNvceRX+v1h99i6gUI1XAKCohRfAsSeJ1+COqWHH/5IZgheAXqx5p7Dj4kYWeFbeifgsx1 GCJ54l0H4XfY7XbgXoKhV2OAEp644kWRuaYZhD/atmCFO0b0Yn05pghdfkASOaF3E9blZJEi /gYbg+LFF5aJVAbWoodSMYgliExNJx2ABkYo40Faqkhml0O9CeeaIMk5p0t23tlTnnryaaSe O/kJqE24DeplnYbeVGiijDbq6KOQRirppJRWaumlmGaq6aacmhTXp6CGKuqopJZq6qmopqrq qqy26uqr/rDGKuustNZqq6rjCdqpZR35qetcv0a66K5LDfvgRMF2layjtRHbFJYZ+dpnZctG 1+Cfztb034DITjtYtZnNhxmd2TpF37HweQussSX1diWb5cqkZLTd3gnuuCptm5KNZ6qJY7wx aUlvuvZyS66nOp6EppDBkQjwvlOySPCc966Wr7gsWYzklw+jdC+UC32M1K/DlXwtwk9efPC8 HZvba70US8zYbSC3Ky+8G9fcssIeSVtwuDmnaXPAOM/M8M549gwznLoCeCTPRLOJm48cIz2S yD7HDPRhT6PsstVxKj0x0zLnKDRJIm8NdlBYL90lyVObvVLabq/Nq8HYam3h/td2OyZ23mQ3 RvfYfe/5N1nqAntz4X6/TDiVgy/ON+OBHl7lz3u/FDnleG+UdeCZJ805T20/XuTmk7eE+ujo dn653opHzXpplh8K+2aSz65o7Q2tDpTvqueuu7a8MwT83bGnPrzwAwP+NrXMLy+753WfDv30 0kfPY/U7Hj+39tkH77jzkF+vfPjiu2476Mlrjv5MpZNvveDgvw/x+Ihj3r7o9ruP/+vswx32 +ve9/63vefQbIAHvp77eJU6A51ug16hnuu6Zz38SLGADjfdAZdUvgyKJX/5u50EFghBtxQtZ B5/1wRMaJ4W0WWGZWuhCA7ZuhAEsYQRr+EIbclB//hDEIA9R6EMVAlGHQhxiCGGIL/mcyXse kxq0vEJDJd5QI58Ti8CCWDXk8c+KIREhANeSMChqMGJsqyIYZUbBvA2razPkz8jUuEbuWQtb N/IPu5LCGTMRxYxF0+IU6+jAItJmjzTTWVHQBMg2JhGNhDTiBiXpRNXs72BpNOHZIhlDQ0pR klyaYycXmTuqcVJtWBSRw7gGyT/SqZGplJ1d/HhKSsbyhzqb5R5FSZ1delF8/KplISc5yhyy MGC+hOXoxHjA8iVwh12sJTOHacw44oldoRRmK+WHy2oWy38/GqQ2Mbm9Cq5ImUTMWDTHWcxb 4hCBoVNYNtnZzCvW04LP/nwSLeuGzv5Ns5vwbF8iLclEegK0ee9cpzWT9yGF2tGg1HTnGLOU TwE6LZ0QNScbJwqyfoYRehprji83Ss6TbVI+vsujDO/4zi31i0L+4iO1VDq1HlYSXguLmIqW eFNvkpSaUoIRy47i0Y9Wcp6olGNictqinRo1kD5NKlBH47CilnNd+EKqHc2zTzLexjwvDVlN CzUmsnZoTCv9aTdTZLInKsWqLwvSdmxaUpyZ0mgpW1NQkzSfu8LRQf+kpHPo89fGlVCuEaIb Yod5n5Ae1UV6hWxe50fMJg7Wr0OSqQ49Kte4FO2rPRInwwbLSqHu54j2jOh5ChS3kxrumIqc /qBSR8nXyZaWtKPFmEMvKNF7nhO2sR0aVEEpmSS5RzjVwatyzQZXaD60iQHlYvrqKkWaBdWr xhurLsOky69uc0kFHS5lL6lO6MKPp6iN6HfXG6OKTpe67/UkYJG1WI7iM57lNa8mU+tMI9XX tyFqrnxlm1H7xhCxctIqb5H4xQIbGDOdxaGAGUjeMzoYwHaFMOAmHEX35vfCGJZROMfWLBjB FLjS/TCID3rIrn7OlKTlsBsXrOIVt9O+Iw1kjIObSQX/jo4gFpTFXiwu786wsGHbr43Z20ki Exa+bFslLx+5ZPFeVcJFtq1RnPpNJVfZtQkFalnjJmPylPnKDf4y/pS5acuZ3mpVFo6vmpnM 4jpXuMbCpfKcefxg/eJXzhhN8575HGIr3znOeRb0oAN7Yw8D+mpAvvCR3JLYRWWRxo9Gr573 /CLuYOi5KN60phXNaapeaDGXdjSeA51pNXe6pz6mMyl9y9WzIBLRuC61d6DFltnaOcU4RWmF nmZGzg76s4csEZ3PXFnwBNvUUCp2pB1c2M7Eerez9hBaJ6Ovmqm0w86t8qv1Ekw2AztoUgrl fxPd6i+PW7fXJjRRGSskLr1LZeFeMmh9tFo/pnpvntU2Zk103FxT+Njy/rWfD20lZ++6zexe ta6bbehzP7yhu5W2l8Ud3jW/FeK1BlPF/sFM8YgvuuO+ZvjBCSzxOTN64RbHN7hF7WqUy9qV 55U5qV1uc2zjfNr81TnCX95TTLf8qTR3d88Tnu2NLx1RCL85zKce6p0j3epKH7DHNQt0NLeb 41pP+WbeDGehHz3rJRd7VDOZbxsTfeTRnbfT3f50Zif9x8gku95pxai3bz3AC11m3+vOrMBz zu5n1yjV+8t11iHe4FJVeNy3PLzHm93r6gWU5SHOuM3PvLeZTysVded5qKVd6sUpfdEpp3qT s7TPk2+64BPld6W2nq5Tnr2hwCXlT6M+5mx3/OCp13t9Dur2al8b8kfNI5f27qy7Nzzrhz+g PN1V89LvPPX9/rt3WGVfnt3nO6SWf3XY+/fptMM6oYS1/TCvv8tfJ97422/+tr82/jQhv+tj L/nhRk7/JId791d4tBd5bfZ/38dylTN/BQhq/sd8lKd+8vcoAIh+4TRLDWM0YBVWJwZ3eId/ OUeB9HdPl3Uce5VlJvZ3CwiCXScgFRh2yVdby6VbJwWAyrR5L1h+6WVnaLFjDSMmZnVvHyeB +cd+DVhBPuiDRbdusnd5dGGE0cc9J/hkJiaDTPhziTeBBBiF5uR8Iidy28WBohWAK5iFRciA XGhuIUiGWgh5u4OGx2eAZ5hjZeiG7yeCR6iGN0N+Nzh6eJiG7qct+teHf9FrAvdE/paGVnWV g1AHiPWnOeEXiaL2bcplfJklHY3miDvIefK3fIS4ejPiacnBbZkYh3kYiKDYf+PiiZMIaw13 IRiXith3io/YUaVIb3KXaQEnijRoGgnjgWt3X3qYckLogIbVcjVCaYeYG8jRe4wogJt4i5/F b0YmUsb4SyvnJDQ1bKHhjFBoioonYig4M8UHjNj4eb72bePmi8XYKM+IUKj4gCmoZYt3jAZH iTSCakfTjiNIQoXGNW3FHkiWfB+IjIZIid1VWkLzjjDognKYYVSokLVIOnfXhv0YjOZoHZgV kRNZh06Yfn8IjsMIkOQYVgP5e2fIgnPHeLMYjitJkUS4/oaCGIk0WZOkAnqhZ5ERqJL2l43O Ui1CNoC595E4wWEM2YKyxmw2WJEpeYcAA5QPiZQ6iY4w+YYPA5XXGJNVaYYy2ZTxgpUu2ZMe 6ZNPWJQtA5YjyZRCSZRW6ZRfiZPZZZO4An9cKZU6+JNwyZbjZYdT+ZKWgpZqOV9a6Zem95R5 SZYYeZdl2ZZvCY+D+R6faI9eqV9MtZa8d5hUGY1oI5evApLJVlJvwo+K6ZhRWZgimYu/lV2G FprSeHphqYr7x39RdpSc6HDq8SHGUjJkFlOD1CxByF1w4Ry/mZNpyWqiZxlcBl4qtBrlgWxV GCValFlWKJ3FxZH1CJvGqZkw/lmOf0aDQvVws8VckcWM5KmR49ia/xibLOmHJ1l15OYvl2Vr beJXtMQyPTiexjWGPkeQCuiPWAh4hViffWVE8wJHBdqLA3ouxBmPmemfSSaMjRaf+Nka0Ilu 1fmd5mmdssigptmSbxiQ3VibjtSg4Skmlwicl+h8uzmeGViNEvqD6SmiJCqb4BScmGhS/Bl0 EIiXOYqSmLmXXWmN1OmbbnVivPaFAdmeP6op6MGh/ZmY2bgtrEVGDTKlZRQmGhge8aajnbKl TAeN2hlnpjGlwllcuimO5FhTPuqkmaKkPQppF5lEDUWmWqqgypalKQNFtOkywVJUe6pWfEMZ zSie/u2Rj3hKNV76euWSnGyanQ6KQW7RnCWWgUZqaRrZbW7KpcSFiCPKgx1ZXZwZqqI6qnTI lxSFmKMJSomKnlNiJ8lSqqyqnujjqhsKpo76Q25iq6lIq9vzqkF6Sn96nXJUbWoKo6+BTWdV rCZKj4XUp7/KScFaq65Yac6ZhHk1hXilhM76pWzYiOMUrRmpIYZKJNB3agKJghe1qgSVlXDK TuCqgtqxVNfncI0loGZKn2OFek36qd6qTe/6pne6Ms92rguJoM+proD5mC70r0kZNAS7rhj6 brV1XTMCqMXZrt+6ngeUkJ+kIcqKrCvaouKqqKX5pITEsD73MX76ewnL/pMLq7ExuqAz56uk WZc8hLLcCpScpa7cuqaaukY4262T0rI2W0NBG7SyKrMdKk0wSyxEa6pKdLRnuaRJa0VS2zFP q5e9lJvU2COlibQ++5+LSrW3KouxmKup6pBAmi1Zi6qrGVlMQqWsBWO7qZ+Q2bS70rYzWl0C +4sYKKRzSq9Cq3L2MbU1C7W2uLVzVW+MG6kAa3RLQqqS231ki7Eb64UBu67l+i8j+6gZG3yB WbC/CLGI2riCC7b7OUSwapeVezYgmljyuh10a2SrC7n+Wruhm7ZLK60eClHdtpYuq6thq5wZ lVxbmbsvW2Dc2Zdaa7UrhoPPGkmoK5gFibwn/jS9alu9g9kd4tSkoaVdLhqy1EttfiiWz8mM f2ujVHW2hdqzO0m+oPuYuGVJsci5D3ul7Augkla+yLu50OUuRXog7JupbzW5BnzACJzAk8tG 1Zi5k7a4A5y6UXe8wFu++1puGmOf7Tu4E0zBHsy/DyyRSrJFVTqPHZyAZjmU3euwYchVG1ip 2Ou7/HvCNIydrFvDaCeZOLzDj2u9PMxz8fvDPwy9QlzE7tu8Opxgx7KtMay6M4y3ShvFRhy8 VGwu93nFSDqvQBhyVpFuhQpWXQyfdjvF/VrBfUGnc0qnfnu6A+rFekQcvljCZOy2btljJxK4 2RrGAVuucQx9CdnH/iY8x5Zrxq81phwSomvMSvEZwXCMvxIsyI16wwVkyHeMyJjLyNlakm6s yY58xJAcs4SZc5TMuSZ4MlssWW7sUhhYGxtIwJ/8mtHrtK/8vufYpWM8y55Zy7jsago8Krvc wU38yzcrzMSMxF26OMFcc2CzssU8hEijm3HMm10Lu9LcFv8BhPgxzc1ctG0Kx9y7wX7MxiVM sfm7zXQsyxu8x+CsbaG4ztzlv+ZssmzbyMMqzqYMi4LLuJ4cz/yKKSMCt/Yczjoi0GQ1JK7M z+y6KbTbsTCVv6eMXciVzXKM0FX7vBTNvG53yxe9uxvd0Tbs0R6dzCBdeSNd0h/dplzR1oNm sqwZ528mLckhmc7GdaNsJtLKu8wbQxio0Voo6tIolZ8vvaNfmdLB+bpSqrkpWJ+AfNBBHauc wm0wpmxHrc8Qm9MU2tRlfJX1rKBHDcAkrCblzMFYzbvH3LkHWolhPWIoAs9j/bN5S9T6yJtc vZG22Fov3Nati9fEbNN6bTV83deAHdiCPdh4+NeEjc6GfdhlndiKXSnLytSNPXHNGdmf3Fhi TdlATG64i9lDh6aMzdlHONmgTcaP/cijfdqondqqvdqs3dqu/dqwHduyPdu0nSgBAQAAOw== --------------065F850395A676335145556C-- From Yann Guidon Thu Nov 16 00:31:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02281 for ; Thu, 16 Nov 2000 01:49:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:57 +0100 (MET) Received: (qmail 1449 invoked by uid 0); 15 Nov 2000 23:26:45 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx01) with SMTP; 15 Nov 2000 23:26:45 -0000 X-eGroups-Return: sentto-1101623-1481-974330794-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 15 Nov 2000 23:26:44 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 23:26:34 -0000 Received: (qmail 63039 invoked from network); 15 Nov 2000 23:26:29 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 Nov 2000 23:26:29 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 16 Nov 2000 00:27:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA00070 for ; Thu, 16 Nov 2000 00:26:25 +0100 (MET) Message-ID: <3A131CC9.18E46D88@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 00:31:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2fa605f014176de92f7b4cd50d090d85 Status: R X-Status: N Michael Riepe wrote:
>
> On Wed, Nov 15, 2000 at 07:27:15AM +0100, Yann Guidon wrote:
>
> > - clock : so how do we decide who fast it goes ?
> > fully synchronous and clock sourcing is ok, but how
> > to decide of the rate ? one idea was to use a PLL
> > with a "slower/faster" bit/signal for each end,
> > but it's an analog part and it's uneasy to set up with
> > off-the-shel components. Any better idea ?
>
> Asynchronous (delay-insensitive) logic, but that needs 2 lines per bit=
> plus feedback, i.e. 33 data lines per direction; that's 66 lines for > a bidirectional bus (plus control, plus GND).  The good news is t= hat it
> automatically adapts to the slowest peer -- you could talk to a 2.5 MH= z
> Z80 or slow MCU with a software bus driver without any modifications.<= BR> >

hum, that's a bit too wide... and finally, synchronous/external clocking is the simplest.

but that can be left undefined like the 'electrical layer'.
OTOH i bother about the protocol and the internal state machines...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

Marco Al wrote:
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> > > Enough choices ?
> Well I think our choices are a bit more limited, but I wasnt asking fo= r
> choices... I was trying to gouge if he still wanted to hold on to that=
> part of the draft.
i'm open to suggestions and i can change my mind if a good argument is give= n :-)
in this case, the draft on f-cpu.de has been deprecated in less than 24 hou= rs.
but the electrical definition is not critical as long as you can interface = a
chip to others with as few pain as possible. it's just a matter of convenie= nce
without sacrificing all the rest. if your CPU is implemented completely in = AsGa,
well, you can use AsGA-adapted signaling on your bus, if you can connect a<= BR> chip that works with the same levels. My worries are at the higher level, the definition of the protocols and the elementary designs that could use t= he
f-bus.

> Marco




Marco Al wrote:
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> > > > How would the hardware know wich memory was covered by the m= utex?
> > Arf, the big question. The simple answer is when enterring inside= a
> > critical section, all the shared object aren't updated or invalid= ate
> > thought the network. And when you release the Mutex, you update a= ll of
> > it.
> Ok so basically that would mean additional instructions? (I was thinki= ng
> you perhaps had a way of using the existing caching hints in mind)

cache hints and special registers are here for that.
caching instructions do also help in that case.
but mutex instructions are definitely a BIG NO-NO
because the scheduling is too complex. we've investigated
this problem already, several times and long ago.
The SRs are perfect because they don't suffer from
scheduling troubles because they can restart the instruction
on a fault, they don't disturb the pipeline and they are atomic
even if they take up thousands of cycles to consult or write.

you get the point ?

if you want mutex instructions, use a PPC ;-P
if you want easy speed, don't do that, though. it'll spare you some headach= es...

> Marco




Nicolas Boulay wrote:

> Beark, use always the same fr=E9quencies and if you have a slow device= use
> a gateway and a fifo.
that's finally the best solution. FPGAs will be helpful.

> It isn't new instruction just how to design the MMU (i called it
> extended MMU)
heck, there's no "MMU" in the FC0, there's just a TLB. the entrie= s are
SW-replaced, that's all.

> and how to manage caches.
well, the memory is not badly managed... we have some
nice stuffs already. private space (local SDRAM + eDRAM/L2) is cachable, while external RAM is not, we can add some HW to manage the mutexes.

> Mutex should be global to the system and connected to the MMU.
mutex is global, ok, that's why the SRs are the best solution :
it abstracts them from the actual implementation and can evolve
as necessary. As for the "MMU" connexion, it's a double nonsense<= BR> because 1) there's no such "magic device", 2) you already have caching instructions. we can even flush a line from cache if needed.

> The next question is to know if you
> mapped the caches inside your memory map (maybe the L2 caches but not<= BR> > the L1, because usualy L2 is one way and L1 more or less
> fully-associative).

The OS should allocate "normal" data in private memory space,
that is : map the pages to cachable locations, and upon request,
map the mutexes to the corresponding HW or memory location.
what do you want more ? i don't get your point.

> nicO

> > - ack : yes, it is similar to a "FIFO full/empty" signa= l.
> > just a bit more subtle, but it's similar.
> As subtle as a brick :)
a 3.3V one, then ;-)

> I only see disadvantages giving it at full instead of nearly full.
well, it was a preliminary thought. we can discuss about the details
during months...
> Gates are cheap, destroying concurrency is not. What am I missing?
it's just a thought, that needs to be discussed. your comments are welcome,=
and if you can enhance or show flaws in the design, better now than too lat= e ;-)

> BTW what about LDT?  I think AMD has a royaltee free license... > Marco

IIRC the Athlon used the ALPHA socket, and it was'nt free 1 year ago...
but i may be wrong. if anyone has more data on this matter ... ?

later,

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Thu Nov 16 00:31:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02284 for ; Thu, 16 Nov 2000 01:49:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:58 +0100 (MET) Received: (qmail 6947 invoked by uid 0); 15 Nov 2000 23:26:45 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx10) with SMTP; 15 Nov 2000 23:26:45 -0000 X-eGroups-Return: sentto-1101623-1480-974330790-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 15 Nov 2000 23:26:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 23:26:29 -0000 Received: (qmail 59261 invoked from network); 15 Nov 2000 23:26:29 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Nov 2000 23:26:29 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 16 Nov 2000 00:27:34 -0000 Received: from f-cpu.org (nas1-168.ras.club-internet.fr [195.36.192.168]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13254 for ; Thu, 16 Nov 2000 00:26:26 +0100 (MET) Message-ID: <3A131CC7.82B4156D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <640F9ED3CD2DD211A28600A0C982788CB1EC62@intranet.hq.conlog.co.za> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 00:31:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6872fe1cab7eea6ca4e0b8641f1e43c Status: R X-Status: N hello,

As Nate wrote, you're welcome and please share your thoughts.
reading the big f-cpu manual (v0.2) will help, too :-)

Thomas Page wrote:
<snip>
> I will prepare it and post it to this list toward the end of this week.
it's always too late : once it's written, a draft is deprecated.
but it's how the design evolves. The best parts remain and the superfluous
disappears... so give it a try.

have fun,

> ThomasP
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Ben Franchuk Wed Nov 15 15:17:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02290 for ; Thu, 16 Nov 2000 01:49:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:49:59 +0100 (MET) Received: (qmail 25952 invoked by uid 0); 15 Nov 2000 23:33:56 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx23) with SMTP; 15 Nov 2000 23:33:56 -0000 X-eGroups-Return: sentto-1101623-1482-974331223-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 15 Nov 2000 23:33:54 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 15 Nov 2000 23:33:43 -0000 Received: (qmail 82894 invoked from network); 15 Nov 2000 23:33:42 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 15 Nov 2000 23:33:42 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 15 Nov 2000 23:33:40 -0000 Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA10169 for ; Wed, 15 Nov 2000 16:25:28 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A129AF1.9150BFA3@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 15 Nov 2000 14:17:21 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dd50c6a952423311d5386948db96d205 Status: R X-Status: N Michael Riepe wrote:

> Asynchronous (delay-insensitive) logic, but that needs 2 lines per bit
> plus feedback, i.e. 33 data lines per direction; that's 66 lines for
> a bidirectional bus (plus control, plus GND).  The good news is that it
> automatically adapts to the slowest peer -- you could talk to a 2.5 MHz
> Z80 or slow MCU with a software bus driver without any modifications.

Sounds like one needs to bring back I/O instructions again.
The twist here is that you have a hard time coded in the instruction.
I/O would have a delay of xxx units of real time.A i/o read would
send the address and expect data a lot later.A write would just send
normal. However the pipeline would not stall until a second i/o is encountered
or a i/o wait instruction is met.

The other question is what is the cpu and memory clocks timing
like.Is it single phase or two phase clock per cycle? The two phase clock could
also be like 6809's E and Q clocks. A two phase clock may help with internal cpu
logic
where D-Latches are used rather than D-FF's. The two phase clock also
has a bit better margin for hold times for memory access.
.
SINGLE  TWO      PHASE   
--__    --__--__  CLK
__--    ____----
MREQ                                                                                  
<###>   #><#####  ADDRESS/DATA

How fast is fiber links coming along?Can we soon drop the copper
links and go optical?
Ben.

"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From "Marco Al" Thu Nov 16 01:29:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02311 for ; Thu, 16 Nov 2000 01:50:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 01:50:04 +0100 (MET) Received: (qmail 18673 invoked by uid 0); 16 Nov 2000 00:28:07 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx09) with SMTP; 16 Nov 2000 00:28:07 -0000 X-eGroups-Return: sentto-1101623-1483-974334230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.38] by fh.egroups.com with NNFMP; 16 Nov 2000 00:23:52 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 16 Nov 2000 00:23:49 -0000 Received: (qmail 31245 invoked from network); 16 Nov 2000 00:23:49 -0000 Received: from unknown (10.1.10.26) by m4.onelist.org with QMQP; 16 Nov 2000 00:23:49 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 16 Nov 2000 00:23:49 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA06726 for ; Thu, 16 Nov 2000 01:23:48 +0100 (MET) Message-ID: <008c01c04f64$509cc870$29e65982@student.utwente.nl> To: References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 01:29:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2da89f8cc3bd771437ad8c37b11a68d Status: R X-Status: N > Marco Al wrote:
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
> > > > How would the hardware know wich memory was covered by the
mutex?
> > > Arf, the big question. The simple answer is when enterring inside
a
> > > critical section, all the shared object aren't updated or
invalidate
> > > thought the network. And when you release the Mutex, you update
all of
> > > it.
> > Ok so basically that would mean additional instructions? (I was
thinking
> > you perhaps had a way of using the existing caching hints in mind)
>
> cache hints and special registers are here for that.
> caching instructions do also help in that case.
> but mutex instructions are definitely a BIG NO-NO
> because the scheduling is too complex. we've investigated
> this problem already, several times and long ago.
> The SRs are perfect because they don't suffer from
> scheduling troubles because they can restart the instruction
> on a fault, they don't disturb the pipeline and they are atomic
> even if they take up thousands of cycles to consult or write.
>
> you get the point ?
>
> if you want mutex instructions, use a PPC ;-P
> if you want easy speed, don't do that, though. it'll spare you some
headaches...
>
> > Marco

Is this make speculations about Marco's intentions day or what? :)
Hardware accelerated mutex operations were not my idea, I was just
trying to understand what mr Boulay had in mind.

I did make some suggestions of my own...

> > > - ack : yes, it is similar to a "FIFO full/empty" signal.
> > > just a bit more subtle, but it's similar.
> > As subtle as a brick :)
> a 3.3V one, then ;-)
>
> > I only see disadvantages giving it at full instead of nearly full.
> well, it was a preliminary thought. we can discuss about the details
> during months...
> > Gates are cheap, destroying concurrency is not. What am I missing?
> it's just a thought, that needs to be discussed. your comments are
welcome,
> and if you can enhance or show flaws in the design, better now than
too late ;-)

Simply put ACK waste's a cycle after each command, if you exchange it
for a CTS signal instead you dont. IMO we should make the assumption
that the bus is error-less, and without error's ACK's are not necessary.

One important suggestion dropped out right about here, source
synchronous clocking. If each of the two uni-directional bus's is
accomponied by its own clock you can clock it a lot higher if you use
suitable signalling. Now I happen to like differential signalling, sure
it doubles the pins... but high speed non differential busses have a
hidden cost in the ground and power pins (and slow busses have the
obvious cost in the fact that they need to be very wide). Meeting EMC
requirements will be a lot easier thats for sure :)

> > BTW what about LDT?  I think AMD has a royaltee free license...
> > Marco
>
> IIRC the Athlon used the ALPHA socket, and it was'nt free 1 year
ago...
> but i may be wrong. if anyone has more data on this matter ... ?

Athlon uses the EV-6 bus, but they were moving to LDT for a coherent bus
to connect multiple motherboard chips (in essence thats the same place
the F-bus is at, because they put the memory controller in the chipset).
http://www.ebnews.com/story/OEG20000501S0006

One extra suggestion, you should be able to do long (page-size) bursts
on the f-bus without processor/os intervention. This would turn the
f-bus unit into a semi multichannel DMA unit (as many channels as
transactions) something which would be quite usefull IMO. For instance
it would be nearly necessary for something like COMA AFAICS. This would
probably mean you need an interrupt transaction command too :)

Marco
eGroups Sponsor
From whygee@club-internet.fr Thu Nov 16 12:33:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00398 for ; Thu, 16 Nov 2000 17:41:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 16 Nov 2000 17:41:19 +0100 (MET) Received: (qmail 11105 invoked by uid 0); 16 Nov 2000 11:35:34 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx04) with SMTP; 16 Nov 2000 11:35:34 -0000 X-eGroups-Return: sentto-1101623-1484-974374519-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 16 Nov 2000 11:35:24 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 16 Nov 2000 11:35:18 -0000 Received: (qmail 20073 invoked from network); 16 Nov 2000 11:35:18 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 16 Nov 2000 11:35:18 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 16 Nov 2000 12:36:24 -0000 Received: (from mnet@localhost) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA01216 for f-cpu@egroups.com; Thu, 16 Nov 2000 12:33:39 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 12:33:39 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-bus stuffs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d1bb2ff00cde3d12267635260bcc938 Status: R X-Status: N i don't remember who spoke about the ACK signal
but now, it makes sense to remove it. well, that's
two pins less to route. i hope that the scheduling
and the protocol will be easy to make.

@+
YG
eGroups Sponsor
From whygee@club-internet.fr Thu Nov 16 20:53:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02548 for ; Fri, 17 Nov 2000 03:36:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 03:36:31 +0100 (MET) Received: (qmail 2186 invoked by uid 0); 16 Nov 2000 19:53:21 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx23) with SMTP; 16 Nov 2000 19:53:21 -0000 X-eGroups-Return: sentto-1101623-1485-974404388-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 16 Nov 2000 19:53:18 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 16 Nov 2000 19:53:08 -0000 Received: (qmail 9454 invoked from network); 16 Nov 2000 19:53:08 -0000 Received: from unknown (10.1.10.26) by m3.onelist.org with QMQP; 16 Nov 2000 19:53:08 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 16 Nov 2000 19:53:07 -0000 Received: (from mnet@localhost) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id UAA25505 for f-cpu@egroups.com; Thu, 16 Nov 2000 20:53:05 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 20:53:05 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] ROP2 compiled with Leonardo Content-Type: multipart/mixed; boundary="=====================_974404385==_" X-UIDL: 5e62de664b70579ac0373602ffc920d0 Status: R X-Status: N --=====================_974404385==_ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello,

I'm learning the use of a "professional" tool.
It's Leonardo Spectrum with a custom (Mentor) GUI.
i just discovered it today, we had some exercises
and back to the office after the training,
i have checked if i had correctly understood
the manipulations. The problem with exercises
being that they don't reflect ALL the reality.

I have tested the raw design available at f-cpu.de,
f-cpu_config and ROP2.vhdl (only). It has compiled
without modification, i just needed to learn how to
configure the tool.

Not only it has compiled, but i can test it at
"full speed" on a HW accelerator. The runtime is
limited by the machine's clock cycle, not the design,
so i guess that it was mapped easily. it's in the MHz
class :-)

I don't regret the efforts i have put in this project,
it helps me learn more at work, and the tools at work
help the project. what more do i want ? :-)

I have included a GIF of the waveform editor, showing the
results of the machine after a few clock ticks.
One month ago, i have spoken about a "cool big toy"
and it wasn't far from the reality :-P

stay tuned. more people at work may help too...
one day. i don't know how and when.

enjoy,
YG.
eGroups Sponsor
--=====================_974404385==_ Content-Type: image/gif Content-Disposition: attachment; filename="rop2_1.gif" Content-Transfer-Encoding: base64 R0lGODdhpgSeAfMAAAAAAAD//zv6NFFR+1clO4U+JpeXl7JNeri4uNPT09ytwvoTQP+lAP//AP// /wAAACwAAAAApgSeAQAE/lDJSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AHSFILBqP yKRyyWw6n9CodEqtroYs7GHL7Xq/3yF4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKcGJ1BFqOCouTlJWWl5iZmpucnZ6foKGio6SIjXSPEnanpa2ur7CxsrO0tba3uLm6aqxyqZJb j8LDxMXECsbJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w18jYXL/1Vvj5 +vv8/f7/AAMKHEiwIJJ6kA70YrNwl8OHECNKnEixosWLGBc15AXszSl7/sE6utmYsaTJkyhTqlzJ sqVLMCTRxDzzMeFMMzdf6tzJs6fPn0CD/sxJhuiYmqpCxjEqtKnTp1CjSp1KdZXINqdA3EOYVOFV hl+rih1LtoyDsw7Kql3LNhbTMB3DwtwazKbcNG/b6t2r6ayXtF0A3/E7ibAiwWgFc1HMt7FjUXm7 ZMVLV6HdpXcfa96cyPABtIHzeO7M2NDo0Z9Lc17N2lDkypklVwbpFXPr27gDKQa9BfUc3xdR+wae u7hx24ziUlZat+tr5sejS29jmPfnwIl7M95tPTHi7IvT+h3PG/zf7drPE/bMPTx78arjq74+vb59 nLHxc8kfbPblLVpB/nffgANWR9+BB673V3jpNehgdRB+9x0Y6KWGXXoRLsaghdrNN5yH8xEoYnEk UVCUcjL55xyKNFU24ovGKcghiA9u2CCE5znIoY4favhge4glyCNgxPVIYYgwJqlZif0dxSJOKnY0 WYoCKmklZ+NhSOOOE26I44U7hvnekT5yCSSR9K3XXpg5fgEccVfGyRaTCp2433K1NSdlXNC4KOef emVpYWne+RhhoWa2OaaNbBraZWrewTdob+4hWqR8Y8AJ6KZTlSiMnQDiidSeyHFqKlmCCtrhjwi+ +eiNaw6ZqXhgNkopkbTqWKubmJJ56q9UPZfnAfzVCR1twgoL7LIo/lkHaa04xtomm2ruuiivrb4a WpDaMjrtruAyK65PyT5ZBgFR+gnWuOwGdS2r3oopK7zz6gruu7hqy569oWFLYbsA81TunVQOi2yx Tgas8Evvdigpv5BWi52z+Er7baOWWuwwrmYR2uvCIKM0cKgFj6ruGsqGrPLKgyEZL8swQzQysaJK +Z9HCMes885xuEwpz0DrMvM8zqRb5bpBJ6300kwLnDNcpR5catNUV2311UI/7cXMUieH9ddghy12 JzOPZDPRqWCDdjxst+3223DHLffcdNdt991456333nz3Pc3af6t9TAWRFm744YgnrvjijDfu+OOQ Ry755JRXbvnl/phnrvnmnHfu+eeghy766KSXbvrpqKeu+uqst+764xXY9PrstNdu++2456777rz3 7vvvwAcv/PDEF1+4AWdLeVYCzDfv/PPQRy/99NRXb/312Gev/fbcd+/99+CHL/745Jdv/vnop6/+ +uy37/778Mcv//z012///fjnj78ByHOlvAP6C6AAB0jAAhrwgAhMoAIXyMAGOvCBEIygBCcoPv4l rx7Lo6AGN8jBDnrwgyAMoQhHSMISmvCE+rOg/zAIQBS68IUwjKEMZ0jDGtrwhjjMofZUqCcW6vCH QAyiEIdIxCIa8YhIfCAPLeOcDCbxiVCMohSnSMUqWvGKCVwi/rKciMUuevGLYAyjGMdIxhNqUXYt dB4A1sjGNSbAjdprIxyb50Y4zjF6d2wj+vRIPTsCYI9/fGMg+djHQJbxkIhMpCIXyUgFzvGOajQk 9c7YxDTSUZKX3B4kI/m8TXIyk4BknidBqT4/ihKT0xtlI1fJyla68pWwJOUoVek8Sv4Penn8ox9p KUhc6vKXgqSlKXc5yGKespCcrGMxlXnKYRqSkHg0ZjCB+UhgTvOYvcwmNGPJzW5685vgLGE1m2lM ZkLPlj7spCSZacpUYlKZ1uSlM7UZT2lKL5fBpOcxnUlNe+IRm/3sZz7nqc92hvOgCE2oQhd6v3HO k43ZrGX//noYDC6SU6AGjaYeCSrPctZzn9Z0ZzKlydGPQtR67BRoL0sKUnqikqEwjalMZ0rTe8rR pB99HjoraklstvSmyPykOXn5RlGClI8prR4+28lSg55UpEltKklV2syaWvWqWM0qLB0qx5X6k3k7 VYhFI+pVsgYVlEN9qToJOlKz+rKt+iyrXHOpVrR6tKVzvSskn6rVvvr1r4CNIlfVGVeJXpCnb81k Ws961IIq9Zk5LWxQd1nQxbJ0snctK0Sdas+MBvazoA2taF04WM2a07ArRCxhFbvMul5Ur5BFaWyv aVfsEfK0eWVqa2UL0JymFZ9k3eZoh0vc4hp3geOkbVLP/jlRJt5SsK49rnSnS93qbtW1YSXAWI9I VOt697vgDe8UaZnd7Rqxu+JNr3rXy14Ykre5W+zpTdHry/mCb770vR5++dre/vr3vwAm4H6jO0n4 ojHACE6wghc83PL2lMEQjrCEJ/xNB1P4whjOsIbHaOENe/jDIA4xEDss4hKb+MQo7qCD+cfiFrv4 xTCOsYxnTOMa2/jGOM6xjnfM4x77+MdADrKQh0zkIhv5yEhOspKXzOQmO/nJUI6ylKdM5Spb+cpY zrKBm6jlLnv5y2AOs5jHTOYym/nMaE6zmtfM5ja7+c0wPqxCUkznOtv5zgWUMwHwzOc++/nP5tOz TuFM/uhCG/rQiE60ohfN6EY7+tGQjrSQoydo5xnv0pjOtKY3zelOe/rToA61qEdNasxROrVzHu+A V81qQLv61bC+YaWlyOpa7zfWuM61rkU4a7Aa+XmcA/bmbMq5OQbb0sNGtuaEvWxlZ47Zz57esZs3 beZVG3rXvja0Te1sblM72d9u9q6fmG1wW9vcCdB2AnqdACP3dHMG2Lbl4h1NeBtbc/QON+byfe7M 8Tvd+JZ35f4Nb+oVvNvzFjjl/q3wyRE84NKGuL4v93B/N1xyDB93EQ8+8YQjfOAXj1zG2c0/BJj8 5ChPucpTblHzco9/wiYfzOv9YO/x794yf3jOYz6+/pl/e+fIBvrPe57xoVdQ50Tn+dENXvPu+fzc Qo+ey7f3dIBH3epJD3rWNY7Eqe8Q6UvXetiNHr6qM4/kBli52tdu8pY3HdjWq7rXs2f2U84dezc3 5PIA8Ha865xx1ZM7AB03PcEDXHGB//vYoX5fANad7OAz/NYZnz0HLCB6j6e8tAMQd7CXveiaj7zn Ra/0z5ee9Fzvet+/fvrvSX7xWIf92VG9Z4myXOWJQUDuUe5261m+86dPjNSFL1Fir756acz7z/lu +qA7gNVpRMugY/78Wr/d8NUf8OoNz/zuA7CuPX2995if+dg3H/KuH73vL89cpvue84lvvc1Bb37i /m+7/WI/fM29g3/0X8+i4ld54Ud/qadDd3c9AZh+8ud0SEc5vnZqFJVqzVNyJ1d9LNdG2QcAvPdu q2d5C8B+hTd6GYhtXTWBRbdGTsR8cdRCygd1Knh80oN90EdtkCSD1heC1DeDBRZzKOh9o/R8lpSA 2NNC5Ed/Bwh8+Yd6/mdwIFh8EYd8ARCF8ZeECviENMhf6VaCJlh6IwhsWviAVPh/Tdhu6ieG01eA RpRBH7iGa8h6WodfbriEl8RLkpdG60RHRtU8H0iGEOhc9TBoFaiBQKh7uqeBbWeILMeByNeGO5iE zzd0GfSIZ+hLGYSCmlSEOOd985eDbCQAnigA/hh4hZMIdc/3iaZoipYYg3/XRqjIRtunc7VmaakI hnKoVN/neEYIgwhYhulGdWX4dr/Xf8MHhVLYiLUYh8NIg5DYQpI4ivWnd8zIjC/1eo+zh1sodtXY hOWHhjh0hFN4jHSnfrYmjFj3fUVVR+doVGvUhnWHdoFYiEDId3x3iA6Ae4oobWw4hs7Yci8YSJLY jNdIid9na7fWglYnjyr4cqvYiWsEiq6YGDW4ig45Xw55OHzofKzYkBgYivs4kG90i5sUj0HIi7IF hBcpPd5ojKGnjOHYesEodfp4ksmIklFYkyppfko4k1kojdbmj9PoeSaZhT05lOToRB6Yj0iJ/pQB SXlHmZROCYLbyI02NFYEhnkk6Yult0YDsJUDcFNc2ZWSZHjWWFR4mIcAoJTtSHuAeIjwKI/ZV4hr lIgLqIdseJP8aEdECZC0qE6VmJC2hYnQ+JEE6Zd7aXUZ6JATyXcZyEcymJhyVJGL6UY2qJEAkJjZ V3PcJ0q3qJcfGZSFSZWDWYTuN3mxFyn0lYAvqWwxWX5T5wA1WYyqOJdYaYU9iZdCeZsdKYu2+Y8/ KZvUM5YyiZPZA5xRKZU0ZFGz2JJvaF/KSXZa+ZXQ+ZV3JJZsiDhPGZyzF4G1Z4Lv+HyF+J1saY++ mQCMiIOOKEnxyJJOKJB0pIvt6WuZWH3u/pmbDnCKDWmKZwGHwbk89emYrOiJ+QlU2GeflYmfrmiV WXmLvSh1fimE+uWW2BmG/5ebtQlU/TZWAXiU2JaPzshz5mWTdjmfltah+QeQ6UmUFIqiO6l3vSmh 1jOGDvqiJGqc3ShfhLmL4+l3Wemf+AWK6wl1SRk9T3l5aamda2lyiumW8viO4umidBmTP4qTQGiH xoZKj4eCIgp38BmYmsiAnKh9n7SUhmlr17eQ2qdLmOl5XYqSDXqVfaSgrJml6QajJGlsHJqi1lae lqanhemhagWi5gmOUgd/YsqFijmH6hmlXDSliKqiYpqSgbqSm0ijQYScN4qE4GiRimpJ/gV6ip76 iWGpc07ZAMyzlU65oEXqh8FwpEhqiBr4qiiHiBuYo1C6qfX1TJ1EjpcEqaoYn9Y2qT8XmTfFqZg0 matWpl+6X3b4YOK3pgw6kjkqdZoZoYK6oXiaq3n6PHTKhXcKbKuZi3kJPYQaqcL5f+NKraF3W9h6 reqqRgjqpMhYrl5KqUBkqTV3a/tJhPalrHhaoP6Kip7or7Y6p0rJPAX7qxHqjmy3sLMKr80pqfPK nkTnqzk5pscapp85eI1Drvypg9M6sNN6qSEaPqJJmyaroY9qSfsHgmmkjUDZrZZ2rn2qdY/ImTJb lMe3qICKrlIKrBCLfAMYrZj6s7NJ/q8GaKNZGqNzKEdBm3//CooAC7U+mrL9NqRrGCkzq7CU03b3 6ID5eqGQM7OCxJ+VQ4Y4ZzlfC3gjm4c+a5iL00lBiX35ObeEJ7cOGKe+h556So0xGYwv6bKtx6fW trNiy3jxqJhq+7XIh547i7fUtgByqrT4mKJ9N3WS+7BGe0P2qpBCu6vsGrCgK7UCO7DR95TzxYIj p5a2R4gMu3L1qHtd6z2o66GyK7ZYmoWhGYoG2bG5e6CvV5Uca4cVy6vBNLsY2buWaKy5i4ujCbYQ 6Y/dyrfWmq16SLXaCpzURrg8G4nIa73OixZw5JqvWajY+IEbC7LZSLp/VDhDyb6K/uu+2Ia1PJu5 MLS5C/paJyV5+kmJnyu6oTu61ht95JmP/JqwqsudrNu6twe7tNs9xguJtUuttyusBImLZ4u8yQt2 wBubYrfB71qt9fXApIjBJRusJMy8J7tqBFuedcinflueUFmGffua5+q4j5hf3ou7tya+gGrDVnuq 3tuUP8zCZrqYPGnEGVuhloi1SDy/9OtC9iuyOBtHGJh8o/e0WBywFFq6SQmq9ynCzaO1Cox7XNvA 3APGkRjBV3qo1deKnfqpFWm2gdnGcByw92nHKGx0HjzFbBuxROtOqWiDblzHeJy2dzyRhBzHjvtY zrO3DainL4myBpvE0FOr2mvD/oPkx/K6WszTuOBKl21LvMTZgOt7x0fsxWgsjZ06eF3Vn3HsxE98 QvYaoDB4uWvVpqeXxf47tQHcyGu4jh9YmQwJxtmpqhLoa1wrOWVMs5NDyV67xryLmAzZoxl8wcJM zZSpyBoccvz3u9wsfDFatwspzZRJkRnMieR8zeZcwjqZStcLuM7XrS9cl5OsuNlzyZ/MmfF6d5jk yc1bz5zrsNKzrTRbytd8xJSZyrX5yiR40IUby1Bso8M6TSWov8zJvyArSv+70bzszE8KuZ+4hvZJ zOt2wMise1cbiMe6zJB4tVcIpu/r0kqMXyQ9tqx8zYi8X9pszTxazuScx5SH/kkUPNHerJszGM5k asg4Pc3rDNQWm8497dCLvD0EHazyzH5CTL22/Dw3O9XDK6cJUMOfDHvEy8c1m9Dti9bvi9ZMrNbF CdEkZKkW+o1/jJJ8TEccjcVbbLBtuJi/fKAGbKSre5SvC5fax9KGK9M6XMAtbL4vzdgnyMZeTKAU CaByHKxeXNmTbdlF/dhg2tkzza9IfYMDaseUfVOf6NT8udmZjdqcPdZUnaKCC4KM+JJ228x4i7Zb La4zSople9uSs9bphsppvcrOTNyLibup/dBwbUJTh167Tdc42anCDLrUvdcDjNU39dcqmKrIspaE rdKUDaCIXY6KTceZbdkx/u3YCz3IAlDTE3zClz3CGKzawkuWpUjI59zBebiYrb3fcpjfdQzg9I28 9r3Yy7u9YH3Xs/2k1KvUBq7gCB6aB06ayZrgykvhwo3El8m0zuzhDMqRb93cIfTckcSc0b22eG3d LK7FpJvdV0jA1Zm1Jk2GbZfSh6jOOf26vbfC0efTw+zM5w3kGgnfbCzfu3vTEV7UblSKOk3gsWdM /q3OvkuSTo7NBz7UpG2mvevUnavi5DnQ1TuntoreiKzf7By/yp3eaF7hsne87j3gaR7NbC7nFV6z 8ltU7luHeS5wzE3iI1TW11qF6Pevhu7ipDvkZ8lGC3CWwUzSWovjulfn/gHL41173pQOigrt49SW 6d0d2WR7twZwtr+twUxL5Y8J5Sl46hnpn25OglGtzdRX6rMu6v/81Y0s5vWcmoJM5E0t4W3s66it 6gve208t7Kk+5zcN1U+u7Fcn6FEK6CgE7Tn8m9dpzyte3VALwN67hw7AlUfJ6Gz46X343YMt6VqO guUdiYoO040NuZ59urZ7qBMbmKQJmsMd66/dek3uqW+83OFsx5r96rhu4QKNowffhKmp1MyO5cCe zUw97M5u8Ca81OUs8VkO8Ref7ARP6HWto9Jev+6JrykevLiUyB1Nydb44/vFiN5tE+CN7tC37szY 7pDtoTZP0/NO7VsK/sLSTZWhrfMJ6JNbPpfpXuVfbvIU//EID8Iwm8SufMj6/t7AztoC79pUX/Ic jJKDZ/VTn+Ver9P7fvBDu8lFG/LTXuwZXfC3vL8Dy7Lxvt00LtgIvLUMzMzB/b7NLMH0fnQ4d+/A mNSjfdRWLvhuirk8L+GA/+xK3uUPX9/YXrEXruEZPpgdH8pqT75oH+iZT8lk3flfa76SQ6SpS/cn PcZr1+Off3W7CvpJzvgRB3jhvLGzL/uHD/I+f5NJv/VMX/ahjtvgqtu33/TDKPy1Dvy7/8G9L92b H9euP/y+//wxV6vXQ/rlDvOri/pqp/rnt/y6b3fP//erv/jkP/7m/t/9al7+6J/4Xu3xZh+vyX/X 6y/9ZM/8zS9C7A/9P0//uU+uxWzuEJCkMc5enPWW3VIwFEfS6KSvVNfzBIB0lcXXc2YcbONc3u/e 7BcUnnhE0hCpaimXSSPwOXJOQ82olZrVXrEoadfEFY9tZUq1+2W33W94XD6n1+13fF6/5/f9iSMt NUEysUErLIWDRQICBUXGlooNykqMHbQ0o0yzlpcwsRoUTszMUrTTslTDTVM20LVWVFnVV1Ja1i9Y Qo/bXtff2b9h4mLjY+Rk5eW9XUTc2OBa6dwTyIPGx0Vs5m7lF/Bw8XFycu9z9HT1dfZ293f4ePl5 +nr7e/z88+ts/n79+XIBBZr7V9DgQYQJFS5k2NDhQ4gRJbbh58jfCU4ZNW7k2NHjR5AhRY4kWdLk SZQpVa5k2dLlS5gxZW5MtK2fzR+WdO7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXqVaxZ tW7l2tXrV6g1GVnEOdHsWYkOEpgY2NbtW7hx5c6lW9fuXbx59e7l29fvX8CBBQ8mXNjwYcSJFSfG U1FbJLSRJSdUy3bxZcyZNW/m3NnzZ9ChRY8mXTp0Y5tkIU9m3dpe5QSmZc+mXdv2bdy5de/m3fst 6rGPubkmXtwdbN/JlS9n3tz5c+jRpQsEjk318Dri/oiyE874/nd4yKePJ1/e/Hn06dX7rn5zNR1R 3NnFBwDe/jrx6/Xv59/f/38A0WvvOgLu4I6++GKrAZwOvFPwQfnaoO8+Cs/JL0AMM9RwQw479BCv AYUrsLv6JFiwxBNNRLG+CU9ksUQ3JqxwRmUu/PBGHHPUcUcekwvxog58aBDGFCFcUUVPXnxwyRiP xGgmKKNEyYi1FOzxSiyz1HJLLvX6sawgLXGBSCWNRHJJ7YqM8AsZbQDrTTjj5IlKy7q0804889Rz wy/fW0utNw4sU80jWxwURgmdpHFRPiqg08o9I5V0Ukorza1P7CYAtMkzDe30UDOZTPRMRkvFw1EP qrR0VVZb/nX1VcEwHTFMOLQbUkZcXQS1VgZN9dUOVFFQFVZiizX2WGJllWTTX5slLlhAhkV2Wmqr tbZHZTFi1lluJYPWxmvDFXdccs3LltZu043sW2nLdfddeOO17VxN1bXXLHbrlHdffvv19zB6/7x3 YIjyhfRfhBNWeOG2AoaWYIgRMphhiiu2+F+Ht414Y30mvvhjkEOuNmOOS/7HY5FTVnnlSUk2+WV7 UGZ5Zppr5tFlmHOOR2abe/b5Z/9whq9XYhDVeWCegVZ6aaahE1oORI3uQ+qj1U0aLgEWFmDrSbf2 OtKs8/Saa0m/xvPpWtls0MTY2l6RSDTXHJPqqu+72i2y/hEOG4C9uwZbz77LBifwLdEOVG224068 bTQXxwLuumm8e6CsCed3b8vFBjtzLTnH03MtDY8RccYhZ7z0tU9/PPXIK5y8LdD3jX3L2a+sHHC+ a8dS95vvcAzIeuEjHUXWbYWc7sWRb/1ZZsHFmmLebc/7c74BDzv6HcfOU3QJh0+e9eIdZ0P55V17 nXKGsc9SfQ+v9/vvF9jnkPvuU3fS9OPtP7x815tvVy75VSuAPRqghsZWwA4hkEOYO5vvUiOiZRmI aBD63q3CJ6omkI9/rTmfQBRYrA+2b3Dwo178BGfCO9HvHqbboHE6SI4D6k17ZZue5qwXwg2ZLYUO DA7w/gSWEFu10IX+01fTjHhEJN5GhUJk4hxemEQoRlGKiFliE63ohokdUItb5GIXvfhFMIZRjGMk YxnNeEY0plGNa2RjG934RjjGUY5zpGMd7XhHPOZRj3vk4x2reEVANmFiAagLDollyByecE+INOD2 eGgdCGorkJOUg8ECcEm6MNJVmsQQJ/vjSf6A8j+iFNAj3ZOpH1JSlWyw5CUJCcD0WYqU65mlemq5 n1uS54+rvGIrXQlLrclSkbirVC7Hs0teNtGXv3xeMIs5TBtSypjTQWYyhbjMVzZTYdNMDzfJ483x gNM84nRONXk1wdWpzpr9e5Qrs6nNhJHzm9AsoTQd/mmH34EpeNtxQf00uE7zETEBzATmNoVJQmLa s4H4fKAPH8YHo5EJbkRDJ0A5KFAAvDMu8qTdQRdJz48utA759NND9xDRChKvghYN6KPuwtHOeTSh MwVp6ExJoAgOA6WnUynV/snSgmF0ikMlalEJY8792c9BKlWR3IB6licaVapTpeo4kDq6fqoTdSt9 qreEWlWwhlWsToUDSVFpUj1E7YJMZWGSemW8pcb1rXJFUF3fZtem4vVgef3pvaI6VsAGFmhXTRQ6 KUoqBvW1qwr5q2Ad+1iVEXaxL2ssZC17WYZJdrIlqyxmPftZeWl2sxvrLGhNe9priXa0ECstal37 /lpYqXa1SPsqbG1725HdNJLomu01a4tb4AbXVbLtrdV+K1zkJndPxC1ut1qrXOhGV0PMba6znitd 7GZXP9St7q+uq13whpeaunWoxrpbte+KV73r9RF59ZnK80Yuveylb31rkzEp5Ve/+4XJce37XwC3 l6E9fO8k5HRgBCdYwUNxaYAd/ODdBCy+VnQehC184dO4108TbmKFMfxhEF9GwhwWoodDfGIUx0rD qGzNBUjMDhOnWMYzBtGKZ0Uc2LxYHTGmcY997JYRTybHOkYHj398ZCRXVA5mvfFa+IsEYZngyVOm MhGiHBuNJlnLWg5CC5gsiSrjAFCwCXOZzRyC/jGrKstbZrOPe7CtLz/pLBa4siaIjAw6R4sta25z n1NMAQQEOtA3EPSg4dzQAnciInkms6LvTAxGq9nPk6YxoAtN6EsfmsAldfRDIi3lTj/aD5/GMqVN jWJLGzrVCMhzB+IcpFA3hNR2FjWk07znU+f6w6tOQaa9jGhOz/nWTq61MUidUV0nG8KpzjOzNQ1J h8aaIbOWdrHxcGw+K1vb4nX2BAwg6FZL4NXeFnadq21tO2B72+umr6XD7e5nn7LJtF70sOmN7mYM G9ns5nd44f0kQ/9602c9N2XsXXB8y0Hd/WY4dgEdbm+zOt44lbNZqJ3wUes72w3nuG0frrGP/gsc 2okut56JjXE+LLzjKwcuBQKB5onvltwHKUDN23DxPNRc5wWQAM9PwPOd6zwBQfd50Dvg86O3AOk9 l8POlS70pP+c6XtY+tS7UfUoXHnfLOc6bHMA8XGfvCBIx7oNzK2Hsg896mtXexOWXvS3Sz3ucJh7 261u86innQ56v/orNN51wLt21YX2tTWATXCas/0HZ8/5F8iudKm7PfJAZzvlFe94zENe7Y+3O9R7 jvfN333onAf620HveNCX/ueWx4LKA/96zLp8ToYf+LwRDg/Ot/7gaGcD6yuPhbmzPve5b0PasV70 zk+d9HlXPdyV//nnW13yykd+20+/eJNv/h3223+s7CsxCZHLG8yJlz72G412o0de8593+ug9X/3h Xx74mZ989KuvfvhH3/qiT/4b7v9/v9O6jeM+Apwq2fuCA6S9kQs2gyA+86uSe9u73rO735u+/gs9 9ks9uqO/vEu6/Fu/DwTA/aM+zwM+qFu+8su67BvAAmzBoUpAQQI/BRS/ihs7+QMDxsMD41O8ulO/ EcTAqru/4uNA/bM8IeS/EOzA/uO7tRNBB1RB5GBBF5zCJIJBMAO7w7M98qPABwQ13pu/8uvBCjS9 MExBDiQ+NPzAH0zC0bM/JeRC/ENC6NOFv6NCOywqK3wSLKy98aO56+tCsbsDoivDyku//uDTvCDM QCZsv6MrwUTsvNN7PzfUwAssQROkvOHzPUDUvjvsxCqUwRjcwwVEPIvbPZ1hQohwPU9cxabJQ1gT RRqEtZI7P+IgOlSUwHawxWFQRVbsxZ9xRW+DRYqTxVLMQZi5RYc4NgboI2ZsRmd8RmiMRmmcRmqs Rmu8RmzMRm3cxi8CRicTRpkLxHozRpS7tjr0RXT0GW/Mw7CLwGQ0xXLMA15MR3pUmXUERXHLwj6c CJyLR3MUwHoMSJa5R3CMtlmEwNvzR90DSIFsyJAhyJgzyGI0OXdUSDiYR4fMyISByPAbxpnjR3i0 SDrASI0sSX7hyBn0SHFMxZAUSYU7/keTjMl+QUlX08caTIuWdMmLhEmZ7El4ocl85MObHEeKTEid BASe9EmlHBegTIB2NMp/6Mej3EmGXEqrFJemfMqD9MKpjAOSvEqwJJastEliBEly7MoAXMGwXMtp GUuhLEucPEu0XEi1ZEu7FEt81MOIJDk/5DupHIZB5MLSM7rATD/BXD8zRL3rY8TDhEM7OD4LScq7 nExKcctR1MIGvEGklMs+2EFCNMPg60HfQ8a6K81DpLrjkEzKXE09scxY/Mh/eEKzK8pj8MzGBM36 Q0MKvEXb7EAUdL/VezwApETVa8RF1MC0+0rWXM4tcU2VrMh6kE0cpE1j0DtN3E0w/ny++OM/N+hN 7VTC33Q+m3O+EcQ7EcxO8qTLKGRO9swT5wxH6KQH6dxM6iyGwJQ/02s/w1TD7exOIixPNwTBAEXB 8JxA/VNPSWtPBeWS95RIG0xM+qRF+5xAyMTPJvRA46RE/8zONzTCFCTQIgxR9/vDC3XM2VzPBU1R LGlQvnxQE41QhKxN+ntE3OzQHzxQA7VAG1XDEmVDAMXRGYVQGMU1FS3SHWFRBnRRvfvLP7BNGnXM 05zDRyTNOCxRKZXDAb3SNeROCzzCTZRCIw1T/0BSUmxAEj3RGK1OQ0TM/DzB+ntT5rNEt7NExpxS 4wxO8GQ64mzCM71TIVVOMQ1U/v4gU8w0y/rkH2TUB0AVVEZND0Ldx7g8VArRxSZ1B0odSdVsVE11 1Lx8xb1M0kiVUEQlSuRYRm48VVRNVVVdVVZtVVd9VViNVVntxk4Nxk8t01BN07m8uUzdVF8lj0cd SpbkzF1FUyL9VWQ9j2CFS1LV1WJF0GNNVmmdjmWFzWblymeF1lKbVm6NjmpdSU/LyWydThTtVnNl jm+NT4Vg0nEd0m09V3j1jXSFSkUV13Fd1HjNV9KY160E13vtVX0N2NHg14kU1XYl1wQVWIWVDYI1 VIM9WHxdWIm9jIbNVWw9WISN1ond2M6o2Gv112yNWI4d2cHw2GGVVIgFWJJd/tmSrdVvvNVCdYcF mFk3mNkF4FVilYCbtVmeTQCepVmf7VmdbYGbPYGi7YCjfQOhRVqbNVqiHdo9SFqo9QOpVVqk/YKm 9Vk3ENmRBR2YUlGTVYejrdqrndomYNeyTVutbYKkLVqgNduddVo4aFu1HVu6XVs9IFt2cNu3ldu1 1duMfVeWDYjbKYfCHdy2CNt0GFs2YFw6zFmpvdunLdu4hVu8vdzGxVq2HVrHtdu2fdvKZVzQ5dzP BVyd7dysDVrJxdypdVucrUvEhaERGgcGil2BUFx0EF2abVrH1daKrNrVrVvOTdveNV219VvKxVvX Vd7WPd2g/dvl5Vuo7d3N/v3bye3cyZ1e4k3LcrXdcGAg8J1d7yUH3D2H4mVeswVEdyTb0s3an01e 9I3fNtBb4NVe62Vd7L3f/M1f1j1eyeXf9G3eADZWwR3f6kGhwq1dAxaH8vUG6v1f7nXW7BXe6o3f ylXd0bVaLKhf5o3eCvbg+9Vfyl3aDT5fpnXfCd7eAQ5cThxfBX7hBR6HBu6G8zVh35W2yEVeChbd 9F3emtXc671aEPZbEPbhIfbhuRXgAM7hDz5eKEzYBYZhFDrgGAaHGWYG/jXiCL7YCrbcLkZioGVi 46Xgy33gIxbgIi5i+O1f+0Vi9GXi7KXeL61iEwrfOqbjcLhiLA5juz1d/tNFWzLG4DCWWzG+XhIu 4b7FYB024r5NXTXO4OJNZLZFXdDNYDJOXTZ21xY2YCmmYjwGAD0+CEA2jjFWiFLu4rNV2U9eZSt2 WXYkS2s92Yeth5+V5LyV2VqOWjv4Y1Vm5VUOZYMY5eI45YQg5hUmYAAw1VldZmZuZmd+ZmiOZmme ZmrWImAuCGHeVa715Ri+5qi015DtZW6mY2+u15wt1m0e5/Et53zI5rlMZ3W2XXbGB3dGS3iOZ8Sd 53uo5668Z3xmWX1+DXB+Vn/+Z5IN6Hrg56ksaIPmWISmB4U+SoZu6Il96HmIaJ1UxmreaI7uaI/+ aJAOaZGWVYuWB4x2/smJpuiFLel4OGmRTGmVFliWDo+BRmdxjmmAduW81EpEruTSNemajtr3xdyd zeVcFmT/TWFiPmQSLuQg1mXVNVpbRuHX7d4w9drvJZsYmt2tNpuuzhsdouIZyp3r8Wrt2WpBVdws RmOfbmQ+dt/3PeobTgb6TWonLmPnFd7gzVwVbt275WA+0GL5feOqhmIjPVza7eQpPuDAUeA7fmzG FmvIdp/qaexfbWATfmAiRuM1Fuy5Roa67mEd9uILptu93mAgJmTCdl4PtmWp/uv5jeNj1mQwXU3H HiHF7hutFofMoezKxm2uhuzgtmxfxWwVruHj7uzhFeJMdmk5ANwL/g7kHbbgvo5t1A7i/c1r6c3k tU5kSK7uORZTO5Zs2hXf365s3+btKT5c9kZgT3Zv4t5U4z7hvi5tR27iqKbvwuZiYpDrAW7ft/5u 6p7tu8bfNrZfESZwBB9kpQbvJ9ZYFa1dxCYczAFrxnafsfZkHTprrt5t9UZvrQ7rQJ1vC4Zrqg7h 5DbtrQ3qW9ZcwO5fG7bv+9ZgVA7h0OXswSbaE5djonZwZK5tylTs97acBC7vTr7typkhDC/v8zbv Ri1fCH5qG8dxFFdwd1XXFsdv6SZt5u7xTB7tJW7eM57y1PZsz1ZiwIVpnxRy3TZcsq6h9tZwJ4/z Jf9wxH5vRoXy/s3eczJf69Ve8XOGai334gkGYzd2Y75WYvll8O0+c9kecDm24VSuyquW7DZfbPJ2 78le7PGm802P7PjWVD1/bf2O6lp2a741cd7F5M8+hqOG4zIeathWbUI+5En2bkx26ucdc6zd3Vj/ ab8+bRYGctsW3yT/mq+O7w238KyucN8+dmePH7NG9svW6YJsUYsF2cgx5jrg9kTX1k3GaQOe6Xdw 7rM49WHwdnRP7SwHd2IXd4e2dpiF1I/Fcp3xdjrA9xSe9OxT5pH+d4APeIEfeIIv+I4m99QM9He+ aXiPd4jz1I6ET3ptZxa3Z4Zv+IqW94h30Gy3936+eIxfaY1P/kmJ71ePX2iQD3mZHvmafMtYDleF t3hKV3l5ZvmgvEx6l2UJTtmZp/l8tnmnhGVtXwhz90c19/lkRfh2KPp4PHqkr/aHt9WNx/Z6n3iL dPqnl2+g52mH3fl21WiDD3uxH3uyL3uzP/s1UnoYq/iP7/msH1m1xw+2R3m3f/uNjfsdm3uJTnm7 51bczXVUJ/VSz28/FvzC3+KhF2qhzWF0f/WlhXUvn1tWb2opX+Mkvm7AZ18GR/xwb0/OiSHQP2vR R/bR55rQJ33UN/3Sh3bWf/OvdUG1Vu4/F2w/9/NWN4bQjnwYr3Xkje5TjnK/pnUwp3Hhd3QA5ner XtA7l93v/v3wOXd+TA/1IYf+6W9+6w/TGX7xMN937Tfwx0XZdC/zQr9u7dVsYd/37S/t4G9t0y1q 4Sd/Knf3w3Zy6pd++69//L/+6M9/+gfbrRd6CDAm0Wrpuilfbn0FYpq4kVrlONQ6SSgcyyaclWBJ j6bXh/9M1znxgJzjEZOsLX0L0dMIFF5UrMQEEABwu94vOCwek8vmMzqtXrPb7jc8Lp/T1YLu/c7V A/j7r18f4KBXoCEhHuJfoaJg3SNkpOQkZaXlJWabhBXK5oqFwoEoAYFC6OjFS0zUB5Rrx2sr7GwM ZwvWRJDu6lPvEJFSL5LvzpKOT1AOFU1TsdTx6vOG8dQO/jSMLVaCVma39zd4uPi4JZ9eHp6AuXr6 uns7/B67/Dt9fN88fr0+eb//P8CAAh95glEQlKgDpEwlJJAql4wbwKpZo7hMIrZPt1Tt6vghGsaK U5AVCcZqGQplGJ04a0kSmLGXIkkqS5Aty5aBOnfy7OmTkrlEYA4xKir06CKkjpQSZdoo0M+oUqdS jXpQw1UKpxSW2urQAsdovz6OtRjSbC2N2sJ67KiSIo6UZFlSoSZ2YsuSMfPWREbTGpSRaa/grGr4 MOLEmIImNdp46eOmkZ9Sdgz5MlTFmjdz7jwmK1gDnCp47drwYQ1pe6/5VQ34dUbCuNrSfjuTbFlq rAKj/pQr+LcSl81EymL2W+bf2Da1cfPs/Dl0w+j+nEsU9Lr17NS1C8K+/Xt37tPDP45u/jz6fqAr gC7NEFVoXjhOTptvv9X9EPSJKd8IkfYuwuyWG37ExFXXbfXRlxJ/JuHGlw18gfRSg/z1sN9gyxWW HocdelgJY46os8+I95RoD4r8pHiiii2y+GI+LH44I401srEeBe01ZBp87P0HIJBB7nLTbEIaeSSS SQaopG9H1mSTWhvaOCWVVVp5JZZZWokjLqNpteN7CqHGJJlAEslWmWmqqWCDSD7JhIB3Gfkkkc1p eSeeeeq5J599RsKljqPwKGZ8axoqw5k/Hrooo0K+/ukkpIhGuQ0DI1p6KaaZaropp516+imooYo6 Kqmlmnoqqqmquiqrrbr6KqyxyjorrbXaeiuuueraKqCifUIamF6N2WijiRJ7LLLJKpvCpHb6+Sy0 0Uo7LbXR9eplAu4JW+iyahrbLbjhihtknTlVey666aq7Lrt/+mrQuwgJGuZXPo5L5rf36rsvv+W2 +y/AAQs8cLTX/vrlvNvay++R+TL8MMTH+kswxRVbfDHGnBl8gbancRsxbQ6DPDLJSk6cMcopq7wy y5ZsLC9X9A5b8pCTokkzzjnrcnLLPfv8M9A/vwxswh4vrPMMIiO9NNMsNGtu0FFLPTXV6Q6NcMwK /ueoaNPMynZz12GTzHPVZZt9Nto2Xp1tsEZvLbYGSsM998Nkp3033nnrXdXaHff4Nt1Of8114IWL W2eluyq+OOOjFtI45JFLPjnllVvux+WZa765rn23/XeRgcttOOnL2r13HJijnBnArKeresaun+t5 0aCD3fXopetO7Omow1Fd7BbL/np5FA9fLe1Zux063bnv/ryhvfvuBvAYH6/u9dVWf3H20ia/kNbM N1kffuXr92iSzqcpoF02sM/mMCfxBpdbbQrzoHFlJfNLhQsGQ1wVniaO4WFuHpdySjwOOJkEWgqB KFJgOLb3huNJBjMmihEGSZTBe8yBgGNQoIya/gJCAzZQKCVsDIzO0cADnlBGZPCgGFi4whmWSIY1 pCE7SqjDE+3whj7M4QnDIMEYvnCDKzKii5C4QAda0DLdK55SAEHCKQKRh0p0B1FGqMIXKcKKLvTC 9wZVL8Ax4TiuuQb5zme+/2XIP8iyDYIsIgQkPChCchwfhfQzF7zM4ECtSVD++sMcqHVjPEMJURaX EiMEjmeRC2wkIhvxjXz87jJDqYwJxaPITXqHPJ584gvLYEgiMoaSo/ykJZMCvOl0cpRQqU6IPijK VGJyibZs4ioXkUtP3rJ7lJQl61rJSU0KM5YVFOEwwXNKWQKTiLoEzxIbqUwURpMQkDxKBcEY/i+s bBNr4Fve7ezImjP+MZCrkYkF1FcmOM4PJX5EY0kAyEfiJKGcUbjQXywkT0DaJYCycVYmYqlJag4z kpncjkGfiVBsWgYcv2yDQB8n0XRMtJjErCUtK8nMjIooOwntaEPxkUmLQtOSsLRDKKHYS4we86C7 zGVLQxpDCkaxiUxMJioRWcCJykOVOJXmGVwXUZOWFJnCBKlIbWpNjzK0pl0Io8w+NoTk2BM2VR3n PtVJpr5cBH8VqSdw0Dk+r4LVJcHBqjl/sCD5waY3UPonIRcz0FQmdKh1reldizfUSYJSiAOVJklJ mlOWRkJ2R6VrUyEjwTwcFbAXbehJ02DY/rnGNIqV9SlIX1pUjBbRDIJdqVEcO83BTrN6okVlUDd6 2pFi8rSaheUQFbrJS6qUC1ANH9h0s5/d5qer+nNrOm1GuDW9z6tzjBObnpEc4N5xJWZF6zlH0s/5 iVVwGtpGXC9RSsXSVkUfVaUBE4vN8GI2tA/lqxy2K1jXIjGFoHXqBGf5zH0QdLaKtOJ8E2hCL9Jj i+qVrHw7qsEBO7GW7j2if/urYH1QkKb5VSqEk0jg0j52vfZNqTMFXB7YUvGCOdyvd8IbxLyaV3a3 Bedw2xpdCfmWrDsT7htBMpEcLFecyGWuPJ07guGkFbrAoV9b4ybASYo3wqg1MlCRbN9s/nJUu33t rkE1m1mfWviyTWYDDC9cZBILlJUjDSJpLVtSDGfYroR9L0GlDNMzB9XBS2YzlR9LHjUrtMrwlWl5 IxpZBx4ChN955ZvzLMmMnth2hEPuVRNNzjOiQKtMYieBZvya9u3TuL6ly4p7XOMgo7Em0gPKlmWa ZNhd8qPBDDQUn1yH866hrjhk7A9d+1MIM1mjqsXrhptK6j7rcLRyzjUvA1xmXBe4KFZO5JSnfGzJ uvm7y6ZwaV/NYFh/GNpHJjOUi6zhYltwu90BM1B3jZRTi6HQhDpaaqy6aBYrOqswPhak64jHr1Ia x1+tBoWGMyDhqJjR/RaklLyx2i6z/jbUDy4vZg1J8NqWg+Gp7SSakSprO/s6vp5NJsTHfeHDznbi 3AF2kv168RDLOdxwTjadn33xK4uW4mGW9U2NWvIrsxzjLqX1zJEq8Y4PQtyh/Uw3Q4Mtv52bjAzC 5xrTyMalK73pbfLndW+npuK20z4G2iPWjXC/iNivQvzTI9LBftbeKj3s7obrABlqwymWuIpsH2+s U3TfuLcogg5PLcJVfmAJe7jv6UVDlKlIbWNKkb4i4iGI9fu4H3JQ5CvveHvbC+ceJpjBEc9ebLOt y8hPmO9yx7ljVC7sW2++8iw8ZD2u48LOA7q/g//8F8w9RvHBzdHQUxb63JIkOg15/nodvDv2hCd8 mgefYLKf2dxsf3tY3Hj3j3Z+Gwfp+9/feV2qjtb1oUXqgWXfT8eXau3fvXx+5V73c0pasxLHufWz v/3ufz/84y//WC1+/va/f+a+j+7ki3/8/i/Tp02fAA4gARYg0GGLjwzd5xQd7YmN8v0fBL4Y2hkg BVagBQ6g/hkd/w1OBHYgkgTgBYagCI5gz2RgA4bNA3qgCgbXBJKgC74gDGaMCUod06TgCq4gCMag Du4gD3pf0CXgwbBN7TAgDS6NDd6gB+ZgDy4hEzZhjcxgitVg/yEhFUZfwDkhFmahFqYHFBrOEVbh /ynhFo4hGZYhT3Rh4XwhGI6f/hiaoRu+IRx2AxqKzhSuoR22IQnin/vVnx72oR/mCh/+oSAOYqzM YfPUoR2CIR6OYPf1yfZxn8A8YsU04p0Y4gZGXRQmogouYghSoiMCH7p4Ip5kHiQGjCWGHwdqYiJy 4gWK4p6QYru4opbAYsDI4pWcYrc83TyxICamW2Cwj/ts3Y21Uxzpwtadz4FIg5uUH0zUBtOpEXOx 4mFkWY3Y4iNQ407Q4jgYFqsFhDVSnxCBGUBoIzm4mU98Y+p8kDj6Ay7i3h01XaMh4lhU3bxNg7wl Yx/hRjJiiL0tiaMEyWqYkRVil4cs05h1CDr+nlAlJB10Yz8Y5F79A0PGlzkK/oRD+oNBVp9EZiMt TSQctGOyVNc7Wpcb5SMgudMe5RE+yomLxVMzDINa9cU9SQFvsZHZuU9LCiTAESSHmBkoeoZHUg+u BeXvECVK6ZVGbiNH1pZRtlpTHmVGXeRGDoRPnuEPbo0CDuHsFWGjOME9sZWkpGI+ngWNpWRYjWRz EYGNFcM59RM58Vim0VEg6aRISiNVWBiNPCWA+ZpeOuVSXhvx2Z1OHFZfAl5hPp7JHSbgDeZFSWU4 gGSMTdpvQV1J4kVZIuNuHCNc/hhLokX+bCaL+Ua76aO65QUALZeQtSB6/JeW9eQ5FtxPDpBiDluw zeZGUSVsfpE32iZtrtZf/lpkwZGXQEAmvOHbLnpNL+4PWTZJPmEmWuaYWqpVaAZkdLJbM/rYHKUb PFGm9LmmoMXmZvAmbRoZVYrnz90Sbv5lVZZnT+SVeToecCJcUn4DcRJLc1oaclbmXdCjpEFDvaEP HLkGaPaYaK4baWKnSKImd16heXBZXr6mfL5nOKqnxkEoY8oneAaUhCYWFm3ofBIZhgamHF5llwQh 0W1lJnalv72JOiGHcb2THsVR7u3jgY7dv+1bgdojghoodc7jO9rlXc6ah07CkP5akeqcN9qchXIk yWWodjmpXGVckQ5py33oiCIgVproAqKovhjIhSTXTubWSVodjs6lmcbP/psco4MAmW55ZUSIXafJ T0yApTkJIzSe3XUB1GpyaDVKRSRB0IV66J+uI0b+ROAJKpTKVd4t6YVC3obWJ9Kooe4A6Mgw40gC 6QAeKVAmKp9oqmKQY/ENDKTqjKQuCzBulTEyn5q6ozMOpJ7qoKdyhiRa3/Bx6idSzKjmTKmSDqVW aluwaPoRorAOK7EWq7Ee66sEIrIuK7PmKs7sqip6Ye/FIbVWq7W6DIkGivIYmrSKZbRWIaZeq7iO q7g6K81A67ceomqSK7u2q7uCgbmWDLqmKyrmaXa9K77mK7XG69jII71GYLjqq8AOrAjy68jM67/i zrQSLMM2LBMaLMgg/mzCSuG6OqzFXiwJQmzESOzERurCYizIhmwBaizEcGzH6urHiqzKrqzekGzd +OvJ3l7AsizN1mzFuCzDmGzMymvK2qzP/mzL4Gy/wOzO7s7MAi3SJm3BZGvQnSjy1at+Fi0b9qzS Vq3VsovQ7ovOSu3GUu3Vfi3YLi2WlijHbOnTOiDRcm232mvYtq3bim0QAmHZauXZomDaqi0dVuzb 7i3fbgnTZuW2EmGKkurd4u0l3sKr9q3iLm6HZK2+bK3haq3XMi7lVq7G/K2W0i34LcsXUEDnboMX DCRXRi7a6q3lni7qHobj3gvkku64HG3qxq7sXsLqvm7hum7TwO7s/u4u79JB7R7O7eKuEU5u7xav 8WLr2GrrN3FrGgav8BKu6R6v9E4vJPxuuLTu85oO8VIv93avGlgvuGBv9iaL7nqv+fYu+HaL+I6v xGzv+b4v/Kav9nor+0Jtd8Iv/uZv7PmKBPSv/zat2W6u3dJv/Q4w2+ovAufvJvwvAwPu8gru2kZt ASts9CawBR+vBCCABm8wB2uwA4tR3VJwck5w6R7wBZ8w9XqCCqwwC6/w3AYulzYvAZPw8FYwCt9w 6qpwC68wAGvu/tmvCwwuDUes++KwEStuBiNgEmcuDIdw7jrvEOdsER8xFbvtEnMTAnxwVP1wCUtw FKOsDVexGFux/gF48MFkcBYz8QPHcN6O8Bd7bBiPsRxfLRp7SR2rMQgLsAh78RvzbBzPMSAjLRqn 8dZssBbjlhA/KxT3se3+cSA/cs0OMidIMh5vsQYC8QkyMhE7MiR3ssgOchqD8iGjWASvRSJrciOb sCev8s+KsgO48guvsRNTrBujcr9yMivnMsGCchaXMQdrMSkE8yzXcC3b8iarsi4nc8jy8it38NAF M/iYgik8xA5XszVfMzZnszZvMwsPDjd/MziHsziPMzmXszmfMzpPsTKvc7vqMDZzjDQrQB6zRzrX sz27cNTdsz7vMz/3sz/fMy6zs0Bfq69scyzP8/LdgjHXoDYs/rRDPzRER7ThOq3/KbREyysuMLBG bzRHd7RHfzRIh7RIjzRJl7RJnzRKp7RKrzRLt7RLvzRMx7RMzzRN17RN3zRO57RO7zRPBwlF+whP 6/TgBDVRF7VR3zRhHLVSLzVTN7VTPzVUR7VUTzVVV7VVX7VTx21H/PTWYHVJC5dXh7VYn3SU8LIz l/E/p7VarzVbt7VbvzVcx7VczzVd17Vd3zVe5/Vd/7IDdLAza/UucDUu+LUh+zJhHzZiG3I6pzFi J0pjG3Zj67VkT/Y2M/Zh34RZm/ESUzZnd7ZnfzZoh7ZojzZpl7Zpn7Y4QzYLXzZg64JgZzYPJ7Zs s/Y5o/UK/hO2Y/t1bMs2avd2Wtu2CuB2WUO2GavAFV80cie3ci+3objyav+1Twewj/y1cRP3bM/2 2O7CZt82Xw8Odb+ydet2azN3Ie8wdGuIc3/CcZM3e7e3e7/3dCu20wS3fAPJaxt2Nw/2de83IQfJ cT93f/uHYk9yeJ83fE+3LXB3gGd0cZ+xbR84hEe4hKMyLDMLfWd3ENx3GttxgfO3eAvJekNJcDt2 fhcyb483eYf4amN2QcdtiE84jMe4jJNuhQdXidPGfeNzaHj4dWN4ELx4RieKjsd3Yvs4cwN5/7K4 /2Kxkc+4kz85lINhjQM1ibq2dBfykhM5j0c2iD84lS94/hAjQJabeJGj+JF7eVd7eQug8ZgPdpNH OZzHuZw/z5T7rxlHtw+TeZZn9pZ3t397uZ3fOSZu8J53eH1H+HEHOpiDcqH395w/OqRHuuFUuKI7 Oo5fuX4T+v/2eZl3eSj373kLOAczMHab+XIvcaUvunWT+ptLuqu/OqzfiyunuqW3hYb7Na1zumKv dC/DtnARdq7/9VgP+073eniz+GHbeXUTO7M3u7M/O7RHu7RPO7VXe0n/MqgLN5438Y4nu6H3OXir dC9z+aB7O3ZbO7qL9LizdlIbehKnO7zHu7zPO73Xu73fO1Vje6fbN6a7s2+3sDf/u8CbdrsPvMEf PMIn/rzCLzzDN7zD+/a2yzJYNPzXPLzFy3VSX7zGbzzHd7zHfzzIh/xcRzxCy2xDx3rDnDzKrzzL t3wVCjb0WLTLh4zKz7zN3zzOGw7MP4/M53wQ9LzPB73QD33E7LzR1jzRxw3SJz3TN73TL4rR6w54 P33cjC7VXz3WZz0MnGg8d73Xfz3Yh73Yjz3Zl73Znz3ap73arz3bt73bvz3cx73czz3d173d3z3e 573e7z3f973f/z3gB77gDz7hF77hHz7ih/0CJgTjN77jO34pPL7kTz7lV77lXz7mZ77mbz7nd77n fz7oh77ojz7pl77pnz7qp77qrz7rt77rvz7sx77sWM8+7de+7d8+7uf+50c+6T+w6PO+7ge/8A8/ 8Re/8R8/8ie/8i8/8ze/8z8/9Ee/9Nc+8P/+oPz+Vky/9m8/93e/938/+Ie/+I8/+Ze/+Z9/5ld/ 6JNCBAAAOw== --=====================_974404385==_-- From Nicolas Boulay Thu Nov 16 22:57:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02575 for ; Fri, 17 Nov 2000 03:36:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 03:36:40 +0100 (MET) Received: (qmail 12553 invoked by uid 0); 16 Nov 2000 22:15:39 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx14) with SMTP; 16 Nov 2000 22:15:39 -0000 X-eGroups-Return: sentto-1101623-1486-974411945-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mk.egroups.com with NNFMP; 16 Nov 2000 22:00:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 16 Nov 2000 21:59:05 -0000 Received: (qmail 58445 invoked from network); 16 Nov 2000 21:55:10 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 16 Nov 2000 21:55:10 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 16 Nov 2000 21:55:10 -0000 Received: from ifrance.com (nas23-84.vlt.club-internet.fr [195.36.173.84]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA03339 for ; Thu, 16 Nov 2000 22:55:01 +0100 (MET) Message-ID: <3A145855.878F6A90@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 22:57:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: multipart/mixed; boundary="------------423DE33A80F4755BB12324FC" X-UIDL: ecbd0bee608008b2cc7fcb081ce1d477 Status: R X-Status: N --------------423DE33A80F4755BB12324FC Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello !

My daily writing.

Yann Guidon a =E9crit :
>
> Michael Riepe wrote:
> >
> > On Wed, Nov 15, 2000 at 07:27:15AM +0100, Yann Guidon wrote:
> >
> > > - clock : so how do we decide who fast it goes ?
> > > fully synchronous and clock sourcing is ok, but how
> > > to decide of the rate ? one idea was to use a PLL
> > > with a "slower/faster" bit/signal for each end, > > > but it's an analog part and it's uneasy to set up with
> > > off-the-shel components. Any better idea ?
> >
> > Asynchronous (delay-insensitive) logic, but that needs 2 lines pe= r bit
> > plus feedback, i.e. 33 data lines per direction; that's 66 lines = for
> > a bidirectional bus (plus control, plus GND).  The good news= is that it
> > automatically adapts to the slowest peer -- you could talk to a 2= .5 MHz
> > Z80 or slow MCU with a software bus driver without any modificati= ons.
> >
>
> hum, that's a bit too wide... and finally, synchronous/external clocki= ng
> is the simplest.
>

Yes, it's. Have you ever heard about the metastability probleme which is responsible of the MTBF of the VME bus ?


> Marco Al wrote:
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > > Enough choices ?
> > Well I think our choices are a bit more limited, but I wasnt aski= ng for
> > choices... I was trying to gouge if he still wanted to hold on to= that
> > part of the draft.
> i'm open to suggestions and i can change my mind if a good argument is= given :-)

It's electrical caracteristic. We should choose the quickest and the
most royalty free things ("norme").

> in this case, the draft on f-cpu.de has been deprecated in less than 2= 4 hours.
> but the electrical definition is not critical as long as you can inter= face a

Completly ok but at ths end (the fpcu 1.0 should have one type of bus,
only)

> chip to others with as few pain as possible. it's just a matter of con= venience
> without sacrificing all the rest. if your CPU is implemented completel= y in AsGa,

You electrical caracteristaique never mind about your technologie...
(ok, it's difficult to receive a ttl signal with a 1.8V core voltage,
but... )

> well, you can use AsGA-adapted signaling on your bus, if you can conne= ct a
> chip that works with the same levels. My worries are at the higher lev= el,
> the definition of the protocols and the elementary designs that could = use the
> f-bus.

> > > > How would the hardware know wich memory was covered by = the mutex?
> > > Arf, the big question. The simple answer is when enterring i= nside a
> > > critical section, all the shared object aren't updated or in= validate
> > > thought the network. And when you release the Mutex, you upd= ate all of
> > > it.
> > Ok so basically that would mean additional instructions? (I was t= hinking
> > you perhaps had a way of using the existing caching hints in mind= )
>
> cache hints and special registers are here for that.
> caching instructions do also help in that case.
> but mutex instructions are definitely a BIG NO-NO
> because the scheduling is too complex. we've investigated
> this problem already, several times and long ago.
> The SRs are perfect because they don't suffer from
> scheduling troubles because they can restart the instruction
> on a fault, they don't disturb the pipeline and they are atomic
> even if they take up thousands of cycles to consult or write.
>
> you get the point ?
>

You only think about one chip cpu... How do you shared this information
thought other cpu ? Your connection thought the outside is the bus so a
Load/store unit. Yoiu don't want to create a third unit ? If you use the network, you need good algorithme to manage that.

The simplest way is a non cachable memory shared by all the chip.

> if you want mutex instructions, use a PPC ;-P
> if you want easy speed, don't do that, though. it'll spare you some he= adaches...
>
> > Marco
>
> Nicolas Boulay wrote:
>
> > Beark, use always the same fr=E9quencies and if you have a slow d= evice use
> > a gateway and a fifo.
> that's finally the best solution. FPGAs will be helpful.
>

Or memory inside the G-chip !

> > It isn't new instruction just how to design the MMU (i called it<= BR> > > extended MMU)
> heck, there's no "MMU" in the FC0, there's just a TLB. the e= ntries are
> SW-replaced, that's all.
>
> > and how to manage caches.
> well, the memory is not badly managed... we have some
> nice stuffs already. private space (local SDRAM + eDRAM/L2) is cachabl= e,
> while external RAM is not, we can add some HW to manage the mutexes. >

That true for usual SMP system not for multichip systems with more than
one node ! See my attached gif.

> > Mutex should be global to the system and connected to the MMU. > mutex is global, ok, that's why the SRs are the best solution :
> it abstracts them from the actual implementation and can evolve
> as necessary. As for the "MMU" connexion, it's a double nons= ense
> because 1) there's no such "magic device", 2) you already ha= ve
> caching instructions. we can even flush a line from cache if needed.
Mais non ! It's very simple. The MMU has 2 mode ics (inside critical
section) and none-ics. So in the ics mode there is no extra memory
updated outside the chip and is local caches (if you have SMP machine
with (true) shared memory, it's great). No more probleme with write and
so on. In the second mode, distributed objects are managed folowing one
on the 4 algorithmes.
>
> > The next question is to know if you
> > mapped the caches inside your memory map (maybe the L2 caches but= not
> > the L1, because usualy L2 is one way and L1 more or less
> > fully-associative).
>
> The OS should allocate "normal" data in private memory space= ,
> that is : map the pages to cachable locations, and upon request,
> map the mutexes to the corresponding HW or memory location.
> what do you want more ? i don't get your point.
>

You can't make that with Unix for example. In that case, you use the
network like a ethernet one, and you transfert messages. Furthermore all the algorithme you used will be written in SH. And those algorithme will one of those, i describe.

--------

My idea for the network. see attached gif.

At the begining i believe that you will need a central point to
concenrate the central information like the semaphore. So the topologie
seems to look like a bicycle wheels. But the center point (the memory
for the semaphore) will be overflooded. And the better predictable
network
ever made is the one in ring. Maybe a double ring should be nice to
reduice the means latency. (imagine that a request should make a
complete cycle to find the center information memory ). In that case,
the center memory (which contain the Mutex) will be in a specific memory adress.

--------

And now a "prise de tete" reflexion.

Nowadays, i read "Advanced Computer Architecture - Parallelism
scalability Programmability" from Kai Hwang. And i have read the chapt= er
about parallelism. The speak about the average ILP of 2-3 and the
different level of granularity in programme paralleliem. The 2 commmon
are : 1) multi-cpu computer with several process on it (some process in
the same time) 2) the other are the ILP (some instructions in the same
time). The book speak about intermediate level of parallelism :
Different blocs without dependancies (look though about 100
instructions), or the run of 2 functions simultaneously (around 1000
intructions).

This idea come when i see the program of whygee for SMP system (a
graphical program on DOS in pure ASM and MMX, my usual complet nightmare ;-). He use the both cpu inside each functions. So i think that usualy
you don't compile program to be run on 2 cpus. Only one are used. You're compiler manage to schedule 5 or more instruction to be run in the same
time. Why not for a higher level for BLOCKs of instructions ?

Why trying to push 20 instructions in the same time when only 3 are
possible. So not to waste HW put a 2 way cpu without OOO unit (don't
forget that the fcpu is a SIMD cpu that imply some ILP). But put 4 cpu
and use compilator that manage program to be run on 4 cpus tighly
coupled in the same time. The scheduling will be made in different level not only for consecutive instructions.

This could be practice for SMT processors. Pratically a SMT processor
could be simulated on a cpu with large register set (like the fcpu) BUT
the size of the instruction word is shorter, so you reduice the need for memory bandwith, you can hide the SRAM of the cache latency, have very
big pipeline (a want to write the 64*64 multiplier with ... 128 levels
of pipeline ;)... So you can change in the above text "4 cpus" by= "4
ways SMT processor".

Any comment from compilator guru ? And the other ?

nicO,
one "mind burning" proposal per days
eGroups Sponsor=
3D""
--------------423DE33A80F4755BB12324FC Content-Type: image/gif; name="network.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="network.gif" R0lGODlhygIsAqIAAP///39/f6+vrwAAALCwsI+Pj7+/v4CAgCH5BAAAAAAALAAAAADKAiwC QAP/CLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987/9A4MBALBqPSOKgcBh0 hslocnAoODdQqVZZvWK34KU1SC6bz+i02jcgCNzwtzxOf4uZXsxgzq/7BWJdGnt/hXyBY4OG i3ZMBYlrkZKTlJWWZm19moV3TViboHWIeRaEoaejWIyLS1WQl7CxsrO0tRKZq5udpKWnjKkZ prmij4KKvqGtj7y2zc7P0NEzuMh+u5/DmsB61aDbetnWjq/S5ebn6OkR1OGNxcwUwt1x373t 9MXkpfdzyvrqAAMKHCiJ3Tw78C7IazcgYYWFBxt+MBhOIsGLGDNqRNPQ/+GKjjZA0hC5saTJ kyhTDrKosqXLlzDPeYw0U03NmDhz6mx2M1bPSz93Ch1KdKRPnEGLKl3KFMugAFCjSp1KtarV AEkBZB1wtavXqgkpUgSEalDTs2jTmg32te3XrVjcyrUalt8fuGrzqmTJUm+pp1QBRBUcgPBV wYanXunYF8LWqoYJJ4ZcmO46Q6YginLqt/NGvnlALwDdmGhSrnNTR+3p5bFq1XUPYubsubZt nadfw6atR3fq2Jjt/OJ9u7hMklonlA6xHGDWFw1ld2sej8RYfniNa4/GmJT3vo1DOyDJWEH5 88i559As3e6hdSau92NPj/j2+/jVPR+xcAEcAP8EKPAGgAL+B8AcDgxoIIAKFijAaB+xkk12 +VVooSXdObZeexwOB8JN8nUESHSzrdVAeRemqKII3aVXiosQjrffA1t1OJ15LeYIowfyMcQA dT/SuKNyGa5oZFFFCiEkfCxQqJBvcwGXjDxLdLTMiTXNiEKSNIGhRUP/lOLll2GKOeYUVOyX xZlHpInfkGswQ52Wf631E2pQtiXlMJ38A2SMk8ApA32++FPmOjZS8cihl3Go6DvH2HWNWiiq JyOTH9n3o5yUTTUZVJ9a5tg9d4SVJTR/lkAoK+MwSmOirrhKo3uP4hFpe5MKJWg5ctI5kabx 5OnWnsgo6lGqyemHbDD/HRp6GqyLbkVrrJ4E4x4Bue61rHNLhgSscsLq2eiEWZ6q0a6IStrq s9NGq4qj1J52bbYZbVtvt3EWpOO+rJmb0rarJrPuINBeeStD8R4sG73O+TpQrwV95u9LQwbM iazpwjtjj6hUywHHrDpMib0uQTzStY7WkqrIDStEsqov8xezzCjNHBPLH4Nso4fS4EyQzfoe +YTPMBGdn9E/7/sMukLzCzSlTzcV9VJTl8G00DhWHV+i+UjraD4Y/zjvODWqGyvOfI0mUmmi adUa0rDgGe7cdIvbpNY/16333lQ5ZLE3Xb+LHdjyNks2NrgOrEOluPHt+ONwZ62U3I9XHm5Y /1w74vXgh1truCtlJ3421h9bbvrld0fO6+ms+4Y5rYErPCHhss/jT+ikKk46W633HmXqk/su vN2vwq654NIhEvZoY4OOeO6j78778NSDBTyS1WevWMacG+N59waD83n43JjtrvS9aa++6lKr v37O7DuG90ohzY/+j+5rHz/V+Wf/nNMADKAAB0jAAhrwgAG835b6V739BY+Bw3PgD66mwNVB UHgSNM0FMVjBDkJng6fL4ANBGEIPmpAnQErbCWchwhW6UBZO2xTj1kGa8EjEfi8UUo5yyMOi tXBFKnSbRdj2NhypjWZxKtjyzKPEzSUOUt97oq0Ipq7Yle9rx6tdLv+UVzjzLQ+HPXwRGG/x w+clL3pXxA4axVfFKbJRih5L48IW5T2FZK6OCjGe86IIPfIRKYwt40gTqQiv8/FxjlB8Y+4S KceK0HGJWrkjJLWiRz8+pHmWxBcgAzJG/gySWe3KZDzGxsh9GK6U9oAjJP92FysqMiK0O6Qj 90jDTZ6rjMr5ZCMjssY8ntKNvmxjHO0ozFVK0okMieUrZylKt9myZrgcjy6JWchm3oKUwDSl MHGHyCzucnbeXOZ0lBlM0Vmyk8+kBTo/tE4y/pCC8Wmn/MoIT+vIU35DS6eu7ilGBPrznwAN qEBjOJKBGvSgCE3oDoMRTX2qs6Ew5OeRJDr/DYg6tGcWLR0JLZdRF1Buo3oTIUUvapJ6jgSk puuoCj6K0r2pzqQk1c5Ib9HSyqk0BSytKd18BtOYkm6GH9Gp4266QKHyTUs99ekzF6rD5eTU qFDqVVJhwCX8QTWkaisSUJXK1XjO6ap1k+pMV7Kjp4L1NUTtqlpPdNa5pTU+bXXrWucaBLPG dVjmsOtdiUfXvi5ur1HNK2AD69fC4kCvgxWVBRP7O8M6FqMn0md4HktZvSxLq4spohDfmlcQ oWiImt1qZUdL2tKa9rSoTa1qV8va1hZWZxdD5UOOSUjwIXOOtHStbncCW13QkZvJDGcqbYu8 Pk5yt8j9GTaHOdzk/7myucHFozbNedzkWlc/ywUuLIU720relpnVva54eZVdM0bXmN4tLm6t Od72crK8tXUud+NBWy1W43buzS/FxjrVifB3rPoNsMoUSuACG7iAAk6wY/ur4AZjjbPMQZWD J7w0/aQDwhTOMI2mZ9Nv0TSl4+pHcO4SDA2bmAy5AbGJ0sfREKPMSSeO8Q1S7KlOSSVU1lvx kwJj48HgdVS68JGOZXyWtgkxa5k14pEnB5jBMAAyC3AyYhTQN+VsuMmgenJgopzlKX+KWLTy MJEr5B2qYRlyJXZNi4HMioDBeMxLxbBHyXrgchGUSHUGc8qGDGcmH1Gzmwr0kQEN2kB/B//A g+oBK3f2noeo6hfCKQuf+0xpnB4WZZjuAy+M1lue6aHSoG7SjB8khwO5wdQMCpCqFUTqVaNa 1QQ6dalZDWuRzanNkS5RiUPN64cYVFWXZLSk2CnLPSO5wL0+bYtqYDIWyUxEvxDtpVGRa7LQ ATwTo2pVk62ibVtNk5EVNf04jGY22+6R+kCWnDeL4vGxt3jVnGSnD5GwYvPpt7WRNlDAHSRx 7xpQH17zrFDBDoYp2cospKe70Rvv706n3uK8t2z3uW5gX8pbkwYXj2vsFRxjxcXFyu3FEc6r Ti762rqjphoNGfGQ49ve9335zRjMQn7H4M3BUvHAJ8Tckd/iIlX/O3k/Ug5dXrK8nAiTOdK7 2fN60VzCPk+Dmjts7lVcNttOZxd1Gb7yd+/8jEqf7iKz+bCKK9rmmJCYo/dLXy9yHexeH08o yT7KXza95GavK9oHJWxt5J2h1cENyZ6Ohf/S8+/appSM8uwEEvUd04xnPMlNY+fIW/7yAj0J omXCg4ZkWtecT8vmoYP4kpZenS48fZy8nXDVJ23ZE2TTFMK7JtkbAExqsn2baK/7IuAeZgA3 DmIH60DCSwzzkf/mOOdbd/CtEpPyXritWY+lt6UHJKMXAmPRej3sbb+x8CaufX9BTrGvN/pu d/1nvv+b7g9l+OyHyuuwKN1gO7+L1NXu/717mUP4x/+l2Ych8ScX8yd+MEd+ndNyVpeAyreA /PdC/sd+AKh+hzWAPxZ+8lV/zZeBcSc27qZ/MfeAqWeBepJ83keCXVGAzrUxsMOChrMxLyhZ KOgVFLhYM5hjZMVsALaDAShTN3gVNdgzP6hYDROEXBWB32eEqDKEOMhtLYGE26eES8OEVeaE vDWAPfh+QyiFVjhgrBdEn7VpoQVoqEV9XfhaSKNvFhJEdVV6tWd7VfIEved7vDeHt3d38fCG bOImcjiHv/cxdnh7ddh7f/gFdhiHLuNXsIdnWWVDjccyWdh2DRdfSdeBHrhN41coYVd0Esd8 t1BfB4gK5Wd/+f+XiGdIRjYxTZz4cEdnfo40cddkdyC4gM/VXfQnb5X0fB/4IqfIi5igirbY dbgoi5nIKrD4icWkdQaogKLIgK54biK3d72IT+02d8oId8OIiaFojHQniWOngch4iw63RaO4 gcblN1xIWZEYSdZIiUZnicxDjNsoMMfIPUz3duc1jsVSjsoBffCwjg4WgEJHD3iYS9Piguqi JmMDgwnJI1yDkCvIIwtJjdOIUwBpfAz1TjyokYfHkfVTeBVZUaIHkLZBksAXkoujhFAIVulY CjcYTSaJkllFE1QoFS3JVjW5GqQnk0CBkfyRk/InWED5cVsSkzxpT7i0ksQnlEDpMGr/eJRl l4ZDeZNW1ZQaMk9UCZWdF0BTiXxeqZTEd2daKT1guVdZaR5DSZRjCYFTyZQ5eZZrOYVWaYM1 CZdxyRNtSZdUaJd3uTRlWVNG+RF/2VKB2ZdA1Bq15EyKqZhGdjSISY2FpmSNaZiVVpiTw5eU mZmauZmc2Zme+ZmgWVKHiFSBCDR6uIekOZqheZQC5Yz95E8i6E7/FJuy6U+buJq9OG8oF43B iI3XWInZCEeYiZv954/m9Y74iJz6SIvdSJxWqJtDx5ve6JvuyHOtSIrfOJzOuULQCQf4VZ2s CI/sOInFSI/NuZ3J1p2NIJ0GSZ4N6HLiSUnyiJ6nqJ7Y4pq9/wmcv6mc6vWK50mfoWaf3wlK 7qly1FmesfWfAFqZxgmeW0SbjgGM2Ml02rmgCiSg+Dmd+umg8Bmc2WmhXYih7BmOwrif1hmf GFqPIApnIqom0PI/L/oEpFShK9p/hlc/HlmjnemTYoSjOkijOkpSXzmkRMovQXqkbGCZSLqk bQikTMptRRqlUuqkT3pCSvppA1al6ckrPaOlRIaZfEmlXuoXFaqdYjqmRXYUcUNEtoam7kVj VPdvLBancqdpnAB6deKm1gWn5SanOyZwdUoP3eEG3eENGaenq8WnQyVmjlFCVZcojIqopsWn EHBjUeZx23Oo6+ApD2CpVIapNgly9P8gB54naX4qqTZxpolGbqDiY5VhFZdKZZl6qg9hY5Jx GJ8qq6H6qN4pZLSKqikpaGR2Zq26cTfmYzgWFpgyp67KccfaqskqqsaGpcCapOYxcm0TmX7G rIsaeMHnkjoXqIyGc9X6o+SxbOhxQ2aIFMR6VFg6dX0qri8WqeWqL1f6bazqroDXri4lrddW qniap/WaWoqqr7+qcYB6Ip8HCPQ6sC3gIjNBNPdqaWfQEfMSNZC4sOTqsKvKhkm2mEb2mKB1 QyALKHB5UwD7eLoQFBnbdxvLsVRVfTOZLI4oOQenrYwphnm1AwOpshH7aNS2RQ0Ls3MFkwv7 eXJyAvbZaAf/S7SGlZQPkmoqu2q+mixKq7FD67Rd1UKLwQem1mqpFmusxgCy9h9m22pga7Yr FRoSciOaqrV0ZbRTuzO+kiVtiy2ephBwq1ZK860Uy6tza3XMASJYayI6srfoA0DVV1XN5mzP eLSaNjQK6bLC+nPHBieHi7hUs67WIY1vS0Y+a1FLWx9H5K1Fmbmae2Gce3N713jJ4bqw+7qy G7sk67qkl2f+Sqp+J6hYsnYztrocEVD+BVDsRLw8IrxNw6Px0boPC5L52q+A+wsQV7qTl6TK Gx+HWIsPUZqeqBzZO6LrUJrgm2/X62+VG26ZYhYs66hft3/XqW72OkF2l5zgBI6x/3h/COpb 44sW5TsNzGu+euu3NMK+8rqyuDCgvWu6lTB6PXuf2tuey7h09SueIhqfM9e/M/a/6Uurx9Jj kWGpF1jAopBrymAqvvtQGdTAfWKiy2e/uYuA+6uwu1hkGNx5ngvAAktDQwRlXIapH1yF7buP 5wm/3NFOKvxILEyO3fvCzRjDl1iKSDKxnRt1q9q0m2qszvqqWhwqeoYZ7EXEx8Fp85vEQuzC 0VvGFNyggncuN7zB1MqtBivCohixWIcOeHPED0yiHLicTZzGM7xfUuzG1GsUnzseBCzD5OJr J1x2HzLGHArDHrpdThyPXqSq8/SEbbxSWYuW4YrI9+VZi/8MdCaFx0uMgfnYny3sx5UMTZZs uQmcL/yKVWdsDaZYvcf3ntxoxtKUXvlLDBl6v1B8S7iRyWcnzApcM6vInLp8IqDIjF78y0zM KpPsl638xoMsdWp3zP9yLPOJy038P7w8jxezzNS8red7WAhVcqH8hM2BvMdrvO/sT8X7TxhR w11KxTfXwLbjDCtDcXqwkT/6kdrCv8TsSZBbtT2pzUjhWR0Z0Dq4zZZVP4HrKFlZzTljxxa9 wBltceg80Zxgx/xrl4GseRu9JYqmz9YwnCVNZ0yFQmE00mraf53R0rZgz2S60oOC0+uh0zAD 077G0xPUt0ENz5JLz/E8pUiNbBf/nNQKlc9ALQTAe3Pca8GnOSYGFw9TXZDh64d5DD+Ya0Tp erMlPZhXFT82nRckqc+1wseYMb2PG3Mqasrn1tXOy4g0O4bXfC5pOYH8+5L5yZ+9TG+32Y/d bKD+Sc4P+9SGnJdrq9iNOpdyfaKRLNlaLcedWNm7rEqOjWJ77X660tkR2o6BTZCDDcwf+sjm idiJC9qNPUJvaY8bOtqk6tYTetizqIl07UFk3VZ8fYKvHdoFKsHhqaCWDdfEndnfGF4TxdoW udk4CdnIfaDirA20bY4UepyXrdxGsttn1dsaxNjRHdvTLQrVTdjaSKDJ7dzaB96n69p1CduA Pd6CHdee/3za6H2P6j1Be22C3w3dzCza8k3a9P3E9u3NCaraZMncCc7ePxKjHxNK4HxKLtpG +b3e/r073M2SOmzUR31A8yzPwwviMsjgP6XgLpOjBeWjcWviJU7iP83UMF5nfZXhZV1BNA5V QHrWb8riD8bjnVXh23HjRgXkH9SVMc7fPCnkQkXkHuXjqcscTr7dUf7kg7uFJqTkOsXk23ks ZTbjLk7lGl0xZphkYQ2yWp7T/3fmW46656xD12rmYs1aOg7mqAI3Pp0iNE3n+4SG6JuSQp2q RF14gS7oHF7UCPThh97hHh7iIu7VjZ6HTzvmYI192qo1E1vVVl3KNMK9CG4e4v+Lop9+XJge BhDqGFMt6tk74D+S1Xei5kGTh4sR53DOInmn1rkd3pI82dCoysFs4Pp7nRAs3c7sDeVt2tft i9dFUVdq65r+3+KIyu6ri6uM2uMM7Hos3sN+F8UezandL1qppMyO4OGu69GOf+eI3SFo7fAt 2WxN7KXN7QcOymNpmeNOxpDc7tUu7b1u2LtOwRJq3ZRt7sf+R3FZmPVO7YDT7PV9fgIPXrct zeoO3CUK7R2K2QQ+8Kh4l4F58Pd9yrLtndA8y5o4zUyUfgiv7REv8m397irf7ZBumEbJ8b7e Sgp/8Q7/8euJotJ38tSd8kEc8DjvwP9556X1VjLP7xP/jO+/ru/nzvO76fPOPvE4XysWT8nC mfGceZHNnMxorPTiQPIVjH5bZ+8dA/ULD/QBPnQTR/SqFYlHz/X3TvEOyOtN3/H9Tr/D7fXz fdw2P9d0x/ZynlHMDqPGM7lmE+HmQ/jmpPgrZ/hwh/hS1LjEmX2Zp+gGhOiLbuiJbvkEhPmX z+iZr/mh/8oAOuc96tAV1dAFpfqpL9DjVqPraPo22/qon9Osb/uuf+JMCvhb6eqp2lljyvvo 7PtSV9HE71DCv/qKeJPJf2JE3xBbaKZMqJFEK/sT8eU1feGCqbnWH8szeLJTTut63v21qv14 if3Fq+eXzAboz0LhT2fqf/oV/2j+2d/+/3z8CfaUSmv/PoEAocvtD6OctLYBst687wF64kiW 5omm6sq27gvH8kzXHojZ4mD1/g/s5XREGi+ITCorwxWuWYxKp9Sq9YrNOp+p0Oi4DIuTUK0W PE6rKWXuB2eOy+f0uv1ee+oBejd/DRh4odEHh1dS6JWBJtiYhpGoeDhJWWl5iZlXyMHo6ElG mJj5tkn4ebpUFqo62ur6Chsr14lay4b4yvphyysk+wscLDyc12ssoUt8c8z8kKwMHS09PUnb 3Ps8bX3Nm039DR4uPrPNjeodXW5+ij7u/g7/rr7u2K48T99oH8/f7/+LLx+gfcMCClxD8J/C hQztGP88OCZhsIcQxUhsiDGjRiIUKyq5CNBjLZAbS5o8eQKESH0kgXVc6QulzJk0NUW6iTOn zp03ZfL8CTQoz5pEixo9pOiZIT6QvBhaelRKUkRJm+Z4Kimq1q1cq2RdhLVDVbChuhb5ytRp myFqy5p9CzeuGbRyL9Gtizev3r18+/r9Cziw4MGECxs+jDix4sWMGzt+DDmy5MmUK1u+jDmz 5s2cO3v+DDp0TaF7YpAu/eK0n9Sq74p+DdsKCAO0a9u+jdvAgAIgB+T+/Xv3Rd/Ai9cWDoO4 8eLIYzt/PkX58uAFqkuUPh33bustsGe3vZ23C+/faYdvCT29ej4C2rt/Dz//fvvw4lkMkI8f P32C9/P7d79fd/8NGOB6Bh7YxYD/FeiEgv4xmKCD+lXHnX0STkgheghu6Fl/F8IHYYQfvhdi SiOCSGF9DZ4IYIoacghjZh6yWKKJLM7nooU3ClCjCTOe2GOMQj7344hBklDkh0fusCOPOep4 45JDTglakhdKeUOTWHKi5ZMrRukllWLCZqWEW3K545mEdJmhgGmGOWacn5XpoJprvtnmlzTC iQKdCtopZ6CO+UkgnzaCmacKhC5oqI9sVihopDI+qqKilPJ3qZuIQippp5Qt+mCjiGSqJ5Ci Ikmqp6pGBmp+gLKHJ6d9pmpprJWuiutirWIo66y2/2L6q6Z7JpprsYjtKt+ryMYH6LIoEivi sL0aS21gzpJ46he0+rrprdxK62214vZ1bYvQfmvquY4GCyW4L44LL0rl4qjuut0Ce6+w6U4b b79wzetkvaOyW2u+7e4brr8KcwWwstse6q6+Rma7cMWjPQwxwvhGfPDEAlsM8kwNU5wlwdFq LLGSJIfMckYj82uvtAm9nHDM+77bcs7fjNxbl8P5nBzQOg/tU2stGU0S0jIoTXTTWkF1hmte SR0d1U5fbRTUWWi9tdVRcI112EeBLZvXX5vNEdpir60R2VPjvAXcXajNdt0LIY133nrvrZPd fsfo9t+CDw6W3IQfrnDgiP8vHrbijD9OtOOQT66Y5K0YHjXmlG9e9s7U0M156FGPo3kdoIuO OkfwlH4H66m/zgk/rrcOe+1S+TM7HrnbDvnuuuPOe/Cp3a2Q78LbbfxZpBF/fPNfpLNV8s43 vQ/fkXTXnfWl3LC3E9N/z4cT7GBv3/hMMvugq96D3zx/5q8v/ie6JFkmnfyxf7z78pMfvyfz J0ui+QhQP/bBn/D05z/+Kep9YmkSiApoQN4hsB4K7AID0eTA+VQwgqiboD42mJILfiCDAAIh BznnQUHMrDsivJOrQMAjApnwhJRLYQAAwAAcKkCHO+ThBFZYPgf4kIdD9CEytKUfEMkQgjTs YBD/G2DEGz4gihAAYv9yKMQpWuB/SVTSDJsoj+2RpXJPzOEGdigBIjpDbTOb4hmlGAE1OoCL AAzggr4IxjC+ATI2jCIVoRgBVbimjVkE5AT+GAA66geGf8JjHknXhLGQBSqWG1sZF/DHIWJy k3NE0g5YWMhQwnGUVFSkA634SNytZoxMcUtb8GLDgfhILKBM4PlIiMpUyu4qUJBkKxcBzLzE EiF9+kAtKXjLDOZSl6uLJFue6Uq/DFMN9rjKMT+YzFM6kplFW+VbpvkI7xHSliXD5Ta5aZJI CvOSKrTPOJFZTlcN8EHnROfawBkRd16zndmsI6GWac/B4dMi9dzF/vqZ/ywc3JGJAT3cQMMA UB+1cBEk1CBDG7qzrKDmCpV0h/RYo1ACeXN4eagojwqKUZdodJZpK8lH52ZSHvXGBgB74EVT +rm0EIITatkEF5ZCyab8EqgdLQgmatrImwatohHFKTSgGb7ChYWVU/nlUJ0ZTFbKrhJINVIX dLCokNJTqU59KimguseyCBWtr5RqL4sqjJc2MKZeZGlJF2QmlJY1F2JxZljY+tasSkKSbNlq 6+gaJU+ClUDzVB9Z94o1uVIUsYn95GKZqlfIgkyyXY2pIM9i0qZqlnp3EAAAKAuf0+Z1p18L bWZHuzC59ke1iKVtXa3KEdc+FrZDeykj3UPb0/9qoD0bIK5xTXtc4RJXtcE1bQaMq1PliTWh V3otb/sl2+QC97jIbS5y32Nb74p3uyel6Vf8dJ/fjhV+172aZG3rXOY+lwPxXS545Vvf/A63 pahKX2MJuNv2VsttnEVtmpaGLvT9N1kzPJ2AAdcHWjrEwEAiR4IPfNEIPzhXOHHrRjlK4TqR ox2dLa+He9KTDY/pNKzl6SxC7FjWpKyyWn0e01TMmQ4j6cNZTessSryg6o20VFrysWJXITkN 43hQohiPUrjXOiCT6L0lxqpd+5ocMS55L0reGpSroV4gObi1IlUiiKyMCyw0ectP4/EsvjyK vl1OpOotUmCvHIcus9n/pW52CJxj8U5sxrOLM/ptc9ySZt0NGdDlyc2YyVOeMfOh0drpDaVv I2lrLRopf4ZFoPk5aDOlyFtWey/34Gq6Sx/nY0hS9apr5iNX64bVX5D1rGGtK1S/GcsAeWgq kKiyUa8lJa7YtKJVI2x3tmZlPEU2s5F8mmdrOtO7dnGv2RkIU9Yp2bxOdC6oTWZw4TrUwYZZ f8W9MZQ1Rtec7jageyzRg5K7UIYqdVxNPcJujXuuBiPylbhdMI4dC9y/c7enWxxvcvL73/Wy NzHYTVNb7RuDAg+4x2i9cHUTxtgT6TRfEY6kicLKvx7qkcOfSvDxSDzdF584xVvuchdW/C8Q /7+cx4st4ZCbsQM7xyEiB4FQ6tKrZieXRs1Vrm+WlzvmMoe50hlubrlw3KwG/3jVTSFKTmKR CcB+YaEFVvSMnmHlHVv6zMjub6gzfWxHP/jV4V0NPP8hlDpEpAZumIFOBp1RMAs7ONpus6Wv nWZrHznCBo+xf6Xc7da+wVHjpkU0jhICPq9i17dtbr+LY/HzxjzGX97ysye97GrH9z04z3gj x84u+5y81rVeeWdc/k8f0zwkMTcv+iDeZCcT/NNF/fnRoF4Wgpzf4y/JATfmvYc+Xz4DtE1v pXjD9GpGfe4B3nuzz9jzUe8896lPfPDPofjPYz22Zbl3V0Xd9vFY/P/1pW14jVvc96QHfve7 eRLyW9YSn8727AuVDey3S3eFbvX3fdtHe/BHeOKXCVMHPG8XVfzXeujnfRMSgNO3EdT2fsHX dKGHgPTGgZPVb0XhgP+gf45nflckaBn3J9OHgXxmGmg3f9pngCB4f6BHg0QBeOFwgjnHVRNI TOmXLPsmgHdzOht4g/k2gtlnf0nYgTkoMjvIgzcHd2eRWS8BBND3IOhQhEYoegWYdk34hYf3 ewdIE1K4eVQYgdFxhSKHLF7ThQzRUUi4e0t4YU1YhzMHg0+jhiEACeHzh4EIiFEliIV4hdqj Z0ooYn3ygmdYTTLIhGL4gXwXgvHngfLSFT3/mHpt04jCd4fcl4fyF4kJWIkLmH8MaHMQ2ICn SGxZM32Q+IlmGIak6IQiqIdyiIo4p4rHt4fepoNSQ4dlSItj6HQ1aIO5WH3ImIqN927p1Ikk OEh4coRs8jOIMo3SmIHD1w+aaHXZ2Ipt9n9mkjRaMo5RUo7myGfKqIvMaDpSpo5L84xsJ2S+ pY0+Uo/2GBX3uI1quDUh9o5OJnf5iDZoqCj6+AUGeZBspxfc2I8wBiD/WJABKZAFSY8fRZBz 44pcxo9SIWXVpQ0BGBdmc5GMaJEIuQMQ+WPksou55ZAilQ5PJnVciIgzSZM1eT2eqJLNZpMd iUs7WZO++E0u6JND/0mUeIOT0jRhLblQqyNMKAmPB2KScqg7Snlm+7iQTpllBhKVDWF6PJlQ JkguWAmQ6rGVLkMJXmliVskXa/Z3YhmFZHSW3VM8YcmWGeWWRcMYd4mJNFeXn1OWfPkYetk2 g6Fldpkef/mWcyKY4YeYXbOYnGgZIxmSjcmJj7ljllk8NxmZfbZLfWkaiZiXzYSZmQmaumNr kgZp3/Fop5k0rAlWvaQrMBFOyRgbhWmasrYdw4GblbgIp1mLH7Cbv0kVINdX0IQVvDSaZyGb QVg2yWmCJeiYziacRoN9JCmdhUed8DecVThGbeWdzklTy0mBVCCZhVGeqZF4AwOGM1h6k/8Y Ktq5Y6fGS932naMhnv73NtCBiqZojO9Ziul5bmT4mtY5n1bVU+C5NPcJahyJoHSgEgr6A3AI oOEIisJ4jO6pfvB5NiEJoeN5Ng06F1jYoQoAjBMqhJT4m/w5izZYeBzJoSM6m1UDolsDoxAV oKIYiyxqoShKjPRHljWaT+RJmdoApDZ6ojyKobySoiZagSjaopchokW6AKxznu0npR9BobLI nhXan/6JnbDoHFF6pVQ6pOlwpVh6pF7ao2oXipe4ok46o7hzpqAgpHHqFXOKBFooiV2qpG0K haOoo+shplJKpnZKnngaBHqqpYAKp3yqpGuKh4ZqpYgaofkpdZT/WqlpmqHTCaaB96c52qg/ iqkxIaN1MahFqqjDmKRDqIBMyoJsKqmrM6qkyqCmOqtblKWq6qjMUp0Z46ZbSotPGpm3ynV1 aqvE+kO5eqG7+iz/yXug6qXCWhmnCqSFeqzIGkjKiqTMii2t+qy+CquCiq1HZKyXOq6Wp6mP uqq86q12CK6RKq7nKnvl+qLyCnRNuq1vGq07qqbr2qzCiRnUWqPWaq72+nza2q/cai7O6q6e Cq+iarBT6pPXGrGJhLCb+qWjp68Ju7F9GqvyULFT2iEhS6IXq64KO3RL+q0Oy6UQW7EfWxAk a7HpyqotioSQan/XsbJkIrMwG1c9a7Ks/1qNwzK0RIue1oggAgujPjsRQEuzzHKOYhaDaRK1 RsK0skqyVxsSWetkJUmPDlqmeem0OTa2cTN+lIm2YRubXNsZSjui19GYVZqQZ6u1GOG2HVq3 gFa2FEm3YAu2eSuHeysjgkugRWm4h7sTgnK3EAq4uUC426i2sfW4w8q2uNi4czK505q5ojk9 i6ugl3s5mxtGoNu2oisZnnufiKu6nmk7qCuepNuAPbu6swu7pVu5m+G6y1m7EmS6rNK7ezYX Ibu7dvG7wHsGETu8xHu7xstVubsOkRs9xcu8P0a71kMkyzu9XJkMK6W42Ju9pDk/hXWZatVT haOYBgu930u9YP9TVV9WnwaavEflvOaQvuqbZ56JFm5wXlDlS69RvdZrv5XZl3CovwV6VfW7 mQFsGHJmBPHbZgiswHrkojpjmxEMmK3LuhbMZRC8cZp5bBmswbDkwBJMnH+bYp7mmqmRwiqM m63paqi5wt0RwzLcwskxw9sZKe17ksZZvtE1YhPhmzYbxLoZnNcxxCysaucxHke8xC/Mm5NW xBEpKTpsbe/bv5/Za8tWitk5nVw8eF48M1q8xWKMnWT8xWRcTSPsUcXXVoj2vj9MfK6qiDj6 rnsKrLrasTWrsg2rngKax3qcxp1CwFNFWIDHwU/7r/yKsTi7qHXcyI4cqH/MrpyqsXf/vKwp ocZHWX1xvLNBO8kZy8eenMj+2q0Me4ssG6yKfLKYnDNlecj4yrGMmq+WPMvQGsuyjLF+2p4o GzCmTMcnCT6vjIO7TMu3bMuLzMu9DMp+XMzIzMu6p8qAzIjsI8xz/KvHvMrNnM3YLM3P3Kuo jMfa/Mm6bMc4/D3VbIu/fKPXzM2fHM3uTMoLu8en3MfFKMmjzMrU/I8qisvOfM+lTM6PDM6h Ks7w7M3tSs+qd87vyM/tjM//LM/v/NAFDdABHc79rMcWfcnxGUHV3NCQvNEY3c0UDdCMHMkk HdHxnLIaXcsbmT/q+NED3dIgPdP1zM40ncsSXdIqrcwsbcwr//nSc9bJiLzTydwscmzN4QrR KWvSBC3SBs3RHCTMMW3Tn4rT/vzUE53V8uzTWL3VK63TKR3VJ/TKVL3OVi3TP13VxIzSPR3W TM3T0GzU2YLOsZWLZi3KRb3UyvzWfB3X37zW5fzVbj3XtZfJVbKfSJ3ON53WXn3V2+zQXN3X DlPJg+3XwKxLEIzXRC3We33UQ83ZhO3Z2hmMhd13hx0acjvavszYgS3QZ83Wgy3Xq03J62nZ JofaoqHat43Q6gzbgv3YI93Ws93Wl73UxM3b6lLXrQx+mw3Ljh3cUJ3ctc3M073M9lzcNbLc FHyWj9LUlKizsfLdau3aIR3ZCxveCf+d152NaA3VldSIdEgb30bL0wFTtB5z3/h9tPRd37np 0qmEbw3TM1Q7tei43zRStUqS4Ape4FK7VAb+3wCOjLtdnH1r4fdbkRd+vzIGWYdM4c2m4SHq tX8b4qOTPbDFwR9OCiXumCxOm9TrtyeO4gis4qvg4hwVt2k74mcr49dVv/8L5KpLt0FO5Dup bA+WvkWu5Ea+vkvu5HI5N7lNJVJuj1T+kgO4ZNtdbFq+we1n5Su2wV9+es3EvFxuF2belCRc 5jz45HkjwG3eGopmv2i+A+OqtfNLD7Il5p5C54vwsiaIvNUWwTVODt67ecI7FyFs41v755OK 6Gqm6CCut4//jrWULqSRfmqeZuh/J71jiemZHrqW7lGdbrafPr6xK+qkQ+rWaeokqbyNXumw /pp73ls/vuk7s+pUQetOA7147hGG6uu/Puut3sCtc+ufk+sVTuzmFbfHTqTO7urLLl1bGewQ AezJbr7S/jazU+0Hce3QvsO7Hjrl2e0C8e2pjsl9DrycOR7g/lSEqzXQqe3JWGrsu+mEXup1 vryoIe/z3uSrpGXlng9vxe5gxmMCP/AnVvD+vuV+iGJcC+dxPnfCq2MM/5FrhvDPmxYgbPBN lvEaf1b4bvFpM1Ifzw0E3+//3gbYPvKAphT3js4ExvItb3Tufg8zT/Pvju48iPM57/9wNv/z QO/znL7zRF/0Q+/ogZ70So/0dyP0P/v0TW+mR4/sUS/1N0/1z571V2/0TA+yVs/1UC/row72 Ye8SZT/pW2/2Na/2Ot/2a4/1Y6/qaA/3jvv2QX/3dd+0eS/2cq/3uM73fW+v4h7AJt8NgXuu 6v73Tjaqit/AjU/4i696kY8UsCn5RCK+G0LFl08m7D6fP/XG6+b5kwQHU4VbnE+YmV/A9GnA jj/mgmX6btz6lI/6c6vrwVTI7Z2XQon7/ItWtQ8YpSnpG0/wp58Ywr/ibgXirg/8kDQlzN/8 lkv7cQn90W/914/92a/9QpIAADs= --------------423DE33A80F4755BB12324FC-- From "Erik Hansen" Fri Nov 17 01:12:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02611 for ; Fri, 17 Nov 2000 03:36:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 03:36:52 +0100 (MET) Received: (qmail 18587 invoked by uid 0); 17 Nov 2000 00:13:04 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx17) with SMTP; 17 Nov 2000 00:13:04 -0000 X-eGroups-Return: sentto-1101623-1487-974419971-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 17 Nov 2000 00:13:03 -0000 X-Sender: erik.hansen@berlin.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 00:12:51 -0000 Received: (qmail 28208 invoked from network); 17 Nov 2000 00:12:51 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 Nov 2000 00:12:51 -0000 Received: from unknown (HELO kxmail.berlin.de) (195.243.105.30) by mta1 with SMTP; 17 Nov 2000 00:12:50 -0000 Received: from schlappi ([149.225.54.106]) by kxmail.berlin.de (InterMail vK.4.03.01.00 201-232-122 license 28ef456dd6e1ff79938cc49572f166b0) with SMTP id <20001117001249.GHRG747.kxmail@schlappi> for ; Fri, 17 Nov 2000 01:12:49 +0100 Message-ID: <002101c0502b$100a4c20$7bcffea9@schlappi> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Erik Hansen" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 01:12:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f77d4a124b66c50644dfcf02e76fc25b Status: R X-Status: N > I'm learning the use of a "professional" tool.
> It's Leonardo Spectrum with a custom (Mentor) GUI.

For those of you who are interested to test their
own designs: check out http://www.altera.com/html/tools/download_2.html
The you will Free Versions of Leonardo Spectrum and
Synopsis FPGA Express. Although these Versions are limited
to the synthesis of Altera FPGA, but at least you can check
whether your design will be synthesible or not. Furthermore
you these tools estimate how fast your design will be on a
FPGA as well as other  statistics

I was able to synthesise rop2 and iadd, as well as an intermediate Version
of inc with both tools and they perfomed quite well.

So long

Erik
eGroups Sponsor
From "Marco Al" Fri Nov 17 01:40:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02623 for ; Fri, 17 Nov 2000 03:36:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 03:36:57 +0100 (MET) Received: (qmail 16526 invoked by uid 0); 17 Nov 2000 00:34:46 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx23) with SMTP; 17 Nov 2000 00:34:46 -0000 X-eGroups-Return: sentto-1101623-1488-974421271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.10.37] by ef.egroups.com with NNFMP; 17 Nov 2000 00:34:33 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 00:34:30 -0000 Received: (qmail 21287 invoked from network); 17 Nov 2000 00:34:30 -0000 Received: from unknown (10.1.10.142) by m3.onelist.org with QMQP; 17 Nov 2000 00:34:30 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 17 Nov 2000 01:35:36 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA03040 for ; Fri, 17 Nov 2000 01:34:29 +0100 (MET) Message-ID: <007101c0502e$fa59ca00$29e65982@student.utwente.nl> To: References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 01:40:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9dd3fe815deaf55c004a077ad150ccfe Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>


> It's electrical caracteristic. We should choose the quickest and the
> most royalty free things ("norme").

Is LVDS patent encumbered?  It seems to be becoming the norm,
SCI/Infiniband/LDT/RapidIO/VIA's HDIT etc all use it AFAIK, you can even get
away with chips with TTL only interfaces because of the readily available
ser-des chips.

As long as you dont want to have the hardware managed coherency rolling our
own version on top of LVDS shouldnt be a problem, but if you do using a
standard might be the best choice.

> > well, the memory is not badly managed... we have some
> > nice stuffs already. private space (local SDRAM + eDRAM/L2) is cachable,
> > while external RAM is not, we can add some HW to manage the mutexes.

BTW wouldnt it be smart to put cachebility in the page table so even non
local memory can be cached? (even if coherency is software controlled it
would be nice if you could cache memory on another processor if you had
guarantuees on it not changing, better than always having to replicate or
move it)

> Mais non ! It's very simple. The MMU has 2 mode ics (inside critical
> section) and none-ics.

How does it know which mode its in again? :)

> And the better predictable network ever made is the one in ring.

A shared bus isnt half bad either, both will need extra hierarchies to scale
past small amounts of processors.

> This idea come when i see the program of whygee for SMP system (a
> graphical program on DOS in pure ASM and MMX, my usual complet nightmare
> ;-). He use the both cpu inside each functions. So i think that usualy
> you don't compile program to be run on 2 cpus. Only one are used. You're
> compiler manage to schedule 5 or more instruction to be run in the same
> time. Why not for a higher level for BLOCKs of instructions ?

5 or more? Thats a bit optimistic, Merced wouldnt be having troubles if
compilers were that good :)

Finegrained multithreading is definetely a good idea, NEC has a nice article
on their SMT processor which describes some algorithms where your approach
works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf

> This could be practice for SMT processors. Pratically a SMT processor
> could be simulated on a cpu with large register set (like the fcpu) BUT
> the size of the instruction word is shorter, so you reduice the need for
> memory bandwith, you can hide the SRAM of the cache latency, have very
> big pipeline (a want to write the 64*64 multiplier with ... 128 levels
> of pipeline ;)... So you can change in the above text "4 cpus" by "4
> ways SMT processor".

Apart from the obvious changing to instruction fetching the instruction
decoding would have to change such that it automatically selects the correct
subset of registers though (or alternatively you could have 4 different
versions of all code :).

I think as a paradigm for parallel processing shared memory has some
problems. With SMT scaling is much improved, well thats what Tera/Cray says
anyway, but hardware support for Transputer like messaging/scheduling would
be nice too.

Marco
eGroups Sponsor
From Keyshaun Fri Nov 17 02:12:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02626 for ; Fri, 17 Nov 2000 03:36:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 03:36:58 +0100 (MET) Received: (qmail 909 invoked by uid 0); 17 Nov 2000 01:16:26 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 17 Nov 2000 01:16:26 -0000 X-eGroups-Return: sentto-1101623-1489-974423777-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 17 Nov 2000 01:16:24 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 01:16:16 -0000 Received: (qmail 3741 invoked from network); 17 Nov 2000 01:16:15 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 17 Nov 2000 01:16:15 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta1 with SMTP; 17 Nov 2000 01:16:14 -0000 Received: (qmail 25036 invoked from network); 17 Nov 2000 01:12:16 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 17 Nov 2000 01:12:16 -0000 X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 16 Nov 2000 18:12:16 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 137893db123878942c3170e943b9a2de Status: R X-Status: N I hope I don't get stoned for suggesting this, but could there be an
instruction mod that sets an external bit for IO instructions.  I know
this is reminescent of x86 with 64k IO space, but it seems like the kind
of thing that could be worth while in some applications.  Though it could
add OS complexity.  It would be a nice option for 1.2 or 2.0.

Kruger
eGroups Sponsor
From Gunnar Lindholm Fri Nov 17 06:44:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00325 for ; Fri, 17 Nov 2000 18:58:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:26 +0100 (MET) Received: (qmail 8938 invoked by uid 0); 17 Nov 2000 05:05:22 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx14) with SMTP; 17 Nov 2000 05:05:22 -0000 X-eGroups-Return: sentto-1101623-1490-974437474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 17 Nov 2000 05:05:17 -0000 X-Sender: gunix@telia.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 05:04:33 -0000 Received: (qmail 19007 invoked from network); 17 Nov 2000 05:04:33 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 17 Nov 2000 05:04:33 -0000 Received: from unknown (HELO d1o908.telia.com) (213.64.0.241) by mta1 with SMTP; 17 Nov 2000 05:04:33 -0000 Received: from dilbert (h234n2fls21o908.telia.com [213.64.153.234]) by d1o908.telia.com (8.8.8/8.8.8) with SMTP id GAA12817 for ; Fri, 17 Nov 2000 06:04:31 +0100 (CET) To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] Message-Id: <00111707062402.00283@dilbert> From: Gunnar Lindholm MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 06:44:20 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [OT] CPU on PCI card Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9927f7674a8470498a363c15b3dbf153 Status: R X-Status: N Hello.

I saw one nice toy yesterday at www.agelectronics.co.uk/tpe3,html, it was a
PowerPC CPU on a PCI card. Cool, the downside was the price. But
the idea is still nice. You get a CPU and some memory to work on the PCI card
and you talk TCP/IP over the PCI bus, and with a 5 PCI slot motherboard, you
get a small cluster with 6 CPU's. Isn't that nice to use with Beowulf 2.

So, how about also designing a PCI card that contains a F-CPU and some memory
slots??? Would it very hard to do that when the F-CPU is ready? What do you
guys think about this idea?

I'd buy a few of those...
Bye,
G.
eGroups Sponsor
From Yann Guidon Fri Nov 17 11:45:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00352 for ; Fri, 17 Nov 2000 18:58:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:32 +0100 (MET) Received: (qmail 2666 invoked by uid 0); 17 Nov 2000 10:41:08 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx16) with SMTP; 17 Nov 2000 10:41:08 -0000 X-eGroups-Return: sentto-1101623-1491-974457659-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 17 Nov 2000 10:41:06 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 10:40:58 -0000 Received: (qmail 85543 invoked from network); 17 Nov 2000 10:40:58 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 17 Nov 2000 10:40:58 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 17 Nov 2000 11:42:03 -0000 Received: from f-cpu.org (nas4-123.ras.club-internet.fr [195.36.203.123]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA29006 for ; Fri, 17 Nov 2000 11:40:54 +0100 (MET) Message-ID: <3A150C5A.23E5497A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 11:45:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e0ee6b0b91dac54675d1d15f3ade2829 Status: R X-Status: N hello,

Erik Hansen wrote:
> > I'm learning the use of a "professional" tool.
> > It's Leonardo Spectrum with a custom (Mentor) GUI.
> For those of you who are interested to test their
> own designs: check out http://www.altera.com/html/tools/download_2.html
> The you will Free Versions of Leonardo Spectrum and
> Synopsis FPGA Express. Although these Versions are limited
> to the synthesis of Altera FPGA, but at least you can check
> whether your design will be synthesible or not. Furthermore
> you these tools estimate how fast your design will be on a
> FPGA as well as other  statistics

that can be helpful, thanks.

my other interset was to test if i could map the f-cpu in the HW accelerator,
and it went very easily, except that i can't reuse the inout vectors
without modification. i've been lazy, i haven't fully tested the design,
but it seems to work.

> I was able to synthesise rop2 and iadd, as well as an intermediate Version
> of inc with both tools and they perfomed quite well.

i'll try to output a new version of the f-cpu vhdl package, please
send your corrections and suggestions.

> So long
> Erik
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Nov 17 11:45:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00355 for ; Fri, 17 Nov 2000 18:58:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:32 +0100 (MET) Received: (qmail 13231 invoked by uid 0); 17 Nov 2000 10:41:15 -0000 Received: from mk.egroups.com (208.50.144.76) by mx19.rz2.gmx.net (mx19) with SMTP; 17 Nov 2000 10:41:15 -0000 X-eGroups-Return: sentto-1101623-1492-974457661-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 17 Nov 2000 10:41:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 10:41:01 -0000 Received: (qmail 3453 invoked from network); 17 Nov 2000 10:41:01 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 Nov 2000 10:41:01 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 17 Nov 2000 10:41:01 -0000 Received: from f-cpu.org (nas4-123.ras.club-internet.fr [195.36.203.123]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA13075 for ; Fri, 17 Nov 2000 11:40:54 +0100 (MET) Message-ID: <3A150C5B.66DEBAFD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 11:45:47 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dc6bbb1dd2e95c1f205747758fef2286 Status: R X-Status: N hi !

Gunnar Lindholm wrote:
> Hello.
>
> I saw one nice toy yesterday at www.agelectronics.co.uk/tpe3,html, it was a
> PowerPC CPU on a PCI card. Cool, the downside was the price. But
> the idea is still nice. You get a CPU and some memory to work on the PCI card
> and you talk TCP/IP over the PCI bus, and with a 5 PCI slot motherboard, you
> get a small cluster with 6 CPU's. Isn't that nice to use with Beowulf 2.

"TCP/IP over the PCI bus" ?... that's a strange and slow idea...

OTOH i've seen PCI boards full of DSPs. that's what i call processing power.

> So, how about also designing a PCI card that contains a F-CPU and some memory
> slots??? Would it very hard to do that when the F-CPU is ready? What do you
> guys think about this idea?

several things have been investigated in the near and less near past.
first, the F-cpu packaging : something cheap but not too constrained.
at one time (almost 1 year ago) there was a discussion about using a
socket similar to the Socket 7, but only at the physical level (no
compatibility at all with PCs). it has the advantage that we can find
Zero-Insertion-Force sockets easily. That's 315 pins PGA, IIRC.
that is more or less enough for a system with the said 128-bit private
SDRAM bus and 32-bit IO bus.

At work, i see PBGA sockets with 352 balls, they use a technology that is
very sililar to this of the first chips we can make. Exit the socket,
we can make smaller modules : instead of more sockets for the SDRAM,
we could also solder SDRAM chips on the CPU module.

I've seen some 64Mb (8MByte) chips with 32-bit interface, it's more
or less the size of a stamp. If we want a dual-64-bit private bus
with 8 banks each, we need 8 such chips, giving a total of 64MBytes
per module. i hope that a 256MB version could appear soon.

So a CPU module would consist of a F-CPU chip and 8 SDRAM chips,
we could use DRAM-like connectors to plug a module on a
larger PCB. the interface would need a maximum of 100 pins for the
32-bit IO versionso we can reuse existing connectors easily.
The size of this module is rather compact, i have no estimation
or number yet but around 10*5 cm or a bit more.

you could probably put 4 or 8 such modules on a PCI board (the PCI
board would have the G-chips) but beware of the power consumption
(15W max/board).

Remember : a bus, either PCI or else, is not a good idea if you want big
clusters. The reason is simple : 1) the real bandwidth (measured) is
often lower than the specs let you think 2) the more boards you add,
the less speedup you gain. Same for the ring that Nicolas proposed.
remember that the memory bandwidth is proportional to the CPU's efficiency
(and vice versa). Lookup the Stream Benchmark results.

So, PCI boards are not impossible, but that's only for I/O with consumer boards.
if you want speed, you need a better private/local bus. last but not least :
you'll have to write drivers and SW to manage the boards. PCI is not as simple
as a simple VME backplane ;-)

> I'd buy a few of those...
me too.
> Bye,
> G.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Erik Hansen" Fri Nov 17 11:55:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00361 for ; Fri, 17 Nov 2000 18:58:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:34 +0100 (MET) Received: (qmail 30357 invoked by uid 0); 17 Nov 2000 10:55:48 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 17 Nov 2000 10:55:48 -0000 X-eGroups-Return: sentto-1101623-1493-974458544-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c9.egroups.com with NNFMP; 17 Nov 2000 10:55:47 -0000 X-Sender: erik.hansen@berlin.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 10:55:44 -0000 Received: (qmail 4573 invoked from network); 17 Nov 2000 10:55:44 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 Nov 2000 10:55:44 -0000 Received: from unknown (HELO kxmail.berlin.de) (195.243.105.30) by mta2 with SMTP; 17 Nov 2000 10:55:44 -0000 Received: from schlappi ([149.225.54.161]) by kxmail.berlin.de (InterMail vK.4.03.01.00 201-232-122 license 28ef456dd6e1ff79938cc49572f166b0) with SMTP id <20001117105542.HBVW747.kxmail@schlappi> for ; Fri, 17 Nov 2000 11:55:42 +0100 Message-ID: <000f01c05084$df7b9fa0$7bcffea9@schlappi> To: References: <002101c0502b$100a4c20$7bcffea9@schlappi> <3A150C5A.23E5497A@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Erik Hansen" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 11:55:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 62419324642caa26bc4b76c8366975bf Status: R X-Status: N > > I was able to synthesise rop2 and iadd, as well as an intermediate
Version
> > of inc with both tools and they perfomed quite well.
>
> i'll try to output a new version of the f-cpu vhdl package, please
> send your corrections and suggestions.
>
I'm still working on inc. So long it did perform well. Try to send you a
first
(better performing) version this weekend.

Erik

---
Der Philosophie scheint es nur um die Wahrheit zu gehen, aber vielleicht
phantasiert sie,
und der Literatur scheint es nur um die Phantasie zu gehen, aber vielleicht
sagt sie die Wahrheit.
(Antonio Tabucchi)
eGroups Sponsor
From Yann Guidon Fri Nov 17 12:31:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00370 for ; Fri, 17 Nov 2000 18:58:36 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:36 +0100 (MET) Received: (qmail 9039 invoked by uid 0); 17 Nov 2000 12:22:40 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx21) with SMTP; 17 Nov 2000 12:22:40 -0000 X-eGroups-Return: sentto-1101623-1494-974460419-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 17 Nov 2000 11:27:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 11:26:59 -0000 Received: (qmail 74881 invoked from network); 17 Nov 2000 11:26:59 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 17 Nov 2000 11:26:59 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 17 Nov 2000 11:26:58 -0000 Received: from f-cpu.org (nas3-9.ras.club-internet.fr [195.36.203.9]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA08737 for ; Fri, 17 Nov 2000 12:26:55 +0100 (MET) Message-ID: <3A151729.7418DA11@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 12:31:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 233d34619f40f6796bc686c5f36dd49a Status: R X-Status: N hi !

Keyshaun wrote:
> I hope I don't get stoned for suggesting this, but could there be an
> instruction mod that sets an external bit for IO instructions.
you'll be stoned, bashed, killed and amputed for even imagining the possibility
of an opportunity of the chance that this could exist :-)

more seriously, the last 20 years have proven that I/O instructions are
not compatible, necessary or benefic for a RISC system. Ok, it takes more
instructions to use memory-mapped I/O but the instructions are the same,
they are scheduled, protected and safe for the pipeline.

In the end, I/O instructions are CISCy, because they require a new family of
instructions, if not opcodes, they are scheduled differently, they require
specific ressources that overweight the platform in the future. look at the
x86 mess...

> I know this is reminescent of x86 with 64k IO space, but it seems like the kind
> of thing that could be worth while in some applications.  Though it could
> add OS complexity.  It would be a nice option for 1.2 or 2.0.

if you want "nice features", you are recommended to use the SR (Special Registers).
they have been designed so that protection, pipeline and the rest are not impacted
by possibly dangerous features. On top of that, it "isolates" the feature
precisely so there is no compatibility issue.

I hope this helps.

> Kruger
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From tomsoyyer@263.net Fri Nov 17 13:38:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00385 for ; Fri, 17 Nov 2000 18:58:40 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:40 +0100 (MET) Received: (qmail 10740 invoked by uid 0); 17 Nov 2000 12:38:37 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx21) with SMTP; 17 Nov 2000 12:38:37 -0000 X-eGroups-Return: sentto-1101623-1495-974464702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 17 Nov 2000 12:38:33 -0000 X-Sender: tomsoyyer@263.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 12:38:21 -0000 Received: (qmail 34766 invoked from network); 17 Nov 2000 12:38:21 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 17 Nov 2000 12:38:21 -0000 Received: from unknown (HELO mr.egroups.com) (10.1.1.37) by mta1 with SMTP; 17 Nov 2000 12:38:21 -0000 X-eGroups-Return: tomsoyyer@263.net Received: from [10.1.10.102] by mr.egroups.com with NNFMP; 17 Nov 2000 12:38:21 -0000 To: f-cpu@egroups.com Message-ID: <8v38rs+kfjs@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 211.99.228.66 From: tomsoyyer@263.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 12:38:20 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Is the F-CPU available? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dfe95d28aa05c74e1773190002ed6253 Status: R X-Status: N I want to have more information about it.
eGroups Sponsor
From Yann Guidon Fri Nov 17 14:11:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00394 for ; Fri, 17 Nov 2000 18:58:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:42 +0100 (MET) Received: (qmail 18735 invoked by uid 0); 17 Nov 2000 13:08:01 -0000 Received: from mq.egroups.com (208.50.144.79) by mx11.rz2.gmx.net (mx11) with SMTP; 17 Nov 2000 13:08:01 -0000 X-eGroups-Return: sentto-1101623-1496-974466425-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 17 Nov 2000 13:07:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 13:07:04 -0000 Received: (qmail 84962 invoked from network); 17 Nov 2000 13:07:03 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 17 Nov 2000 13:07:03 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 17 Nov 2000 13:07:03 -0000 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA23514 for ; Fri, 17 Nov 2000 14:06:05 +0100 (MET) Message-ID: <3A152E9F.BCB8E41F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> <007101c0502e$fa59ca00$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:11:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 758997065e666850d658da841b6d5e9f Status: R X-Status: N hi,

Marco Al wrote:
> Finegrained multithreading is definetely a good idea, NEC has a nice article
> on their SMT processor which describes some algorithms where your approach
> works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf

i've read most of it and i may explain my point of view. their design is
rather strange. i'm waiting for a real functionning chip :-)
The chip's die photograph looks a bit like the FC0, at least at the
fetch/decode level.
more about this later.

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Nov 17 14:20:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00406 for ; Fri, 17 Nov 2000 18:58:45 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:45 +0100 (MET) Received: (qmail 24259 invoked by uid 0); 17 Nov 2000 13:25:11 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 17 Nov 2000 13:25:11 -0000 X-eGroups-Return: sentto-1101623-1497-974466921-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 17 Nov 2000 13:15:34 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 13:15:20 -0000 Received: (qmail 6133 invoked from network); 17 Nov 2000 13:15:20 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 17 Nov 2000 13:15:20 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 17 Nov 2000 14:16:25 -0000 Received: from f-cpu.org (nas1-135.ras.club-internet.fr [195.36.192.135]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA14533 for ; Fri, 17 Nov 2000 14:15:16 +0100 (MET) Message-ID: <3A15308F.F3824D79@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:20:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e2fc3fdb8988460478f3b449725ed698 Status: R X-Status: N can you send a first version, even unfinished, of the INC unit
tonight or tomorrow ? i'll try to polish it this week-end.

Danke,

Erik Hansen wrote:
> I was able to synthesise rop2 and iadd, as well as an intermediate Version
> of inc with both tools and they perfomed quite well.
>
> So long
>
> Erik
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Marco Al" Fri Nov 17 14:37:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00412 for ; Fri, 17 Nov 2000 18:58:46 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:46 +0100 (MET) Received: (qmail 19153 invoked by uid 0); 17 Nov 2000 13:31:50 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx22) with SMTP; 17 Nov 2000 13:31:50 -0000 X-eGroups-Return: sentto-1101623-1498-974467878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 17 Nov 2000 13:31:37 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 13:31:18 -0000 Received: (qmail 65045 invoked from network); 17 Nov 2000 13:31:17 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 Nov 2000 13:31:17 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 17 Nov 2000 13:31:17 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id OAA10960 for ; Fri, 17 Nov 2000 14:31:14 +0100 (MET) Message-ID: <001701c0509b$7de73030$29e65982@student.utwente.nl> To: References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:37:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1234603f0e1fb3983b3c37b493100bf1 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> Remember : a bus, either PCI or else, is not a good idea if you want big
> clusters. The reason is simple : 1) the real bandwidth (measured) is
> often lower than the specs let you think 2) the more boards you add,
> the less speedup you gain. Same for the ring that Nicolas proposed.
> remember that the memory bandwidth is proportional to the CPU's efficiency
> (and vice versa). Lookup the Stream Benchmark results.

Im a bit late bringing this up, but better late then never...

I like a shared bus. IMO it would be ideal for a small (4 or less) number of
processors, if electrically its not too much of a nuisance, and if you want more
only then you use an extra chip in the form of a bridge for every group of
processors. Sure it doesnt scale for small numbers of processors, but whats
cheaper... slightly overengineering the bus and saving a chip (and latency...)
for small scale SMP or making a point to point connection tailored for a single
processor which necessitates engineering a high bandwith switch for even the
smallest multiprocessor systems?

How much performance-increase/cost-savings does using soldered chips instead of
DIMM-sockets give you? For cost reasons we would probably have to desolder chips
>from modules anyway :) I think its a bit of a nuisance not being able to
upgrade, it has to be worth the cost.

Marco
eGroups Sponsor
From Jeff Davies Fri Nov 17 15:57:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00436 for ; Fri, 17 Nov 2000 18:58:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:51 +0100 (MET) Received: (qmail 15531 invoked by uid 0); 17 Nov 2000 15:02:54 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx09) with SMTP; 17 Nov 2000 15:02:54 -0000 X-eGroups-Return: sentto-1101623-1499-974473363-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 17 Nov 2000 15:02:51 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 15:02:42 -0000 Received: (qmail 21566 invoked from network); 17 Nov 2000 15:02:41 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 17 Nov 2000 15:02:41 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 17 Nov 2000 16:03:47 -0000 Received: from modem-85.indiana.dialup.pol.co.uk ([62.137.65.85] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13wn2E-0000UF-00 for f-cpu@egroups.com; Fri, 17 Nov 2000 15:02:39 +0000 Message-ID: <3A15476C.ACAE64F0@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:57:49 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Yann - a plug in based XML editor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6e65fd17461d8b84e5db6cb5f829f9a7 Status: R X-Status: N I've found one: a GPL XML tree-based editor that is even better than
Xeena:

http://www.merlotxml.org/

What's more it's plug-in based, and by default has XML libraries. (files

in this case).

I was going to write one of these, but as this is GPL, what the hell...

//there is also another one on freshmeat called "collation" or something
like that (search by XML?)
//phew - look at www.freshmeat.net, then go back five minutes later -
there
//is relentless patch releases of free software!


Jeff Davies
eGroups Sponsor
From Jeff Davies Fri Nov 17 16:13:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00442 for ; Fri, 17 Nov 2000 18:58:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:53 +0100 (MET) Received: (qmail 28297 invoked by uid 0); 17 Nov 2000 15:18:20 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx13) with SMTP; 17 Nov 2000 15:18:20 -0000 X-eGroups-Return: sentto-1101623-1500-974474288-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 17 Nov 2000 15:18:18 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_2_1); 17 Nov 2000 15:18:07 -0000 Received: (qmail 91185 invoked from network); 17 Nov 2000 15:18:05 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 Nov 2000 15:18:05 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta2 with SMTP; 17 Nov 2000 15:18:04 -0000 Received: from modem-43.kansas.dialup.pol.co.uk ([62.137.67.43] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13wnH7-0001EQ-00 for f-cpu@egroups.org; Fri, 17 Nov 2000 15:18:02 +0000 Message-ID: <3A154B07.5E7BED6@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 15:13:11 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0c266f7e6eb0f336af328db07217ab0 Status: R X-Status: N I think GCC can be modified to do this, although in fact, a certain
amount could be performed by a
binary string replacement. (GCC would give some additional
optimisation).

Commercial Java compilers doing this translation are Asymmetrix
Supercede, Sun Hotspot, Caffeine,
(and IBM VisualAge Java)
and many JVMs do JIT bytecode to native compilation, so this can't be
difficult to do.

Although Java does not give explicit access to pointers, they are used
implicitly (and the code is safe).
What kind of things would be necessary to make available in, a core
iolib type package written in
FCPU assembler such that the Linux Kernel (or other) could be written in
Java, and compiled into
bytecode and from there into native code?

The main reason for this is that I have noticed that my productivity is
much greater in Java than in C++.
Even experienced C++ coders have to sometimes think very hard about what
they are passing, if it should
be const, if it should be ** or * or &, and what casting they should do.

It would also be much easier to audit. (and therefore prove it won't
crash, or be insecure).

Has anyone used say VisualAge Java, and compiled native? Is it slower
than C++??
(If not, then f**it, why waste time on all that pointer crap).

Jeff Davies
eGroups Sponsor
From Keyshaun Fri Nov 17 16:19:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00445 for ; Fri, 17 Nov 2000 18:58:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:53 +0100 (MET) Received: (qmail 5669 invoked by uid 0); 17 Nov 2000 15:19:54 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx23) with SMTP; 17 Nov 2000 15:19:54 -0000 X-eGroups-Return: sentto-1101623-1501-974474379-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 17 Nov 2000 15:19:49 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 15:19:38 -0000 Received: (qmail 1000 invoked from network); 17 Nov 2000 15:19:37 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 17 Nov 2000 15:19:37 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta1 with SMTP; 17 Nov 2000 15:19:37 -0000 Received: (qmail 991 invoked from network); 17 Nov 2000 15:19:35 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 17 Nov 2000 15:19:35 -0000 X-Sender: To: In-Reply-To: <3A151729.7418DA11@f-cpu.org> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 08:19:35 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8cec75ec316850792753e862dbada528 Status: R X-Status: N Ok, that makes good sense.  I had just wondered if the IO instructions
could be flagged (for a better term) so that the IO bus could catch them
and handle them differently.

Kruger

On Fri, 17 Nov 2000, Yann Guidon wrote:

> hi !
>
> Keyshaun wrote:
> > I hope I don't get stoned for suggesting this, but could there be an
> > instruction mod that sets an external bit for IO instructions.
> you'll be stoned, bashed, killed and amputed for even imagining the possibility
> of an opportunity of the chance that this could exist :-)
>
> more seriously, the last 20 years have proven that I/O instructions are
> not compatible, necessary or benefic for a RISC system. Ok, it takes more
> instructions to use memory-mapped I/O but the instructions are the same,
> they are scheduled, protected and safe for the pipeline.
>
> In the end, I/O instructions are CISCy, because they require a new family of
> instructions, if not opcodes, they are scheduled differently, they require
> specific ressources that overweight the platform in the future. look at the
> x86 mess...
>
> > I know this is reminescent of x86 with 64k IO space, but it seems like the kind
> > of thing that could be worth while in some applications.  Though it could
> > add OS complexity.  It would be a nice option for 1.2 or 2.0.
>
> if you want "nice features", you are recommended to use the SR (Special Registers).
> they have been designed so that protection, pipeline and the rest are not impacted
> by possibly dangerous features. On top of that, it "isolates" the feature
> precisely so there is no compatibility issue.
>
> I hope this helps.
>
> > Kruger
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
eGroups Sponsor
From Jeff Davies Fri Nov 17 16:21:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00451 for ; Fri, 17 Nov 2000 18:58:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:55 +0100 (MET) Received: (qmail 20679 invoked by uid 0); 17 Nov 2000 15:26:48 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx17) with SMTP; 17 Nov 2000 15:26:48 -0000 X-eGroups-Return: sentto-1101623-1502-974474798-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 17 Nov 2000 15:26:46 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_2_1); 17 Nov 2000 15:26:38 -0000 Received: (qmail 26012 invoked from network); 17 Nov 2000 15:26:37 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 Nov 2000 15:26:37 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta2 with SMTP; 17 Nov 2000 15:26:31 -0000 Received: from modem-43.kansas.dialup.pol.co.uk ([62.137.67.43] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13wnPA-0002eN-00 for f-cpu@egroups.org; Fri, 17 Nov 2000 15:26:20 +0000 Message-ID: <3A154CF9.8456CAE7@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 15:21:30 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] merlot xml editor screenshot using class dtd Content-Type: multipart/mixed; boundary="------------0B7BD7C5D40631BC6962AD46" X-UIDL: eb779d6152996ed0da8cd31798beabee Status: R X-Status: N --------------0B7BD7C5D40631BC6962AD46 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Here is merlot in action, editing a class implementation.
(merlot is written in java)

Note: merlot is plug-in enabled meaning you can, for example, when
adding an element of
type picture, you could have a picture browser open, which itself could
be a RMI wrapper
(remote method invocation) of a MySQL database of pictures.
Incredibly extensible, incredibly powerful, and GPL!!!

I haven't got the XSLT part of it to work yet, maybe I'm missing
something, I submitted
a bug report as a result to their Bugzilla.

Jeff Davies

by the way this may seem off topic, but it is following the GNL concept.

How about this - one tool for editing Documentation, Programs and
perhaps even hardware structures
(XML representation of VHDL, transformable into VHDL anyone??).
eGroups Sponsor
--------------0B7BD7C5D40631BC6962AD46 Content-Type: application/x-zip-compressed; name="Merlot.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Merlot.zip" UEsDBBQAAAAIAI95cSmGI9YHCB4AAB5FBAAKAAAAbWVybG90LmJtcO2du67jSHrHy94Bhkmb b+DY4QITeAEH2zDknsg4LzHQ6cyCd3GojAQWaBawgV5hQ2NSJwY62A38AP0C8w4ERrCUlevO IkWxKF4kfkf/ny68FUUd/fTVldT513//x3/7jine5OOf5OM/fyPn/56xv2Nm/X9tvmP/+w9M P5oU+s6KwkzUTa2ST3/729/kGqHvTAgzUTe1Sj0BspQZoMhOujtwQBG4o4txJwA94I4ucEcX uKML3NEF7ugCd3SBO7rAHV3gji5wRxe4owvc0QXu6AJ3dIE7usAdXeCOLnBHF7ijC9zRBe7o And0gTu6wB1d4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3gji5wRxe4owvc0QXu6AJ3dIE7usAd XeCOLnBHF7ijC9zRBe7oAnd0gTu6wB1d4I4ucPdo+CGephu4ezBnMfrDh7vHclD2RgJ3j+DM M/eZ8zPyTFpwntlyjnPB1f8W2Wf7yD4XwN1D4Pv9PtdzZ/9PYfLePTqAu4dwymzcnbM953tV 6t1e34S7u6PqJrLA03EmJwdxGlniwd3dKZUqKW2vDMpCbnRlBe7ujq6UlGUm6yvZGW0EUpQq 8KQ6+TiIw2hzcHd/TrqkO3NZTTnImBvfvIO7u1PuS9OSU+F3PpxvbtZ54O7eqHa4mmqDZaYy zpHA3Z05S1t7PVXOTmP6Uxxwd1+47kI5mLA7KJMYAyKC7rosMxd2cjJeHdzdGd3tvD+IkuuG nWqdI+6IcM72Jc9k7fKsm3ZnXu5R3hHBDBscygM/a3eCj8814e7OqI7MTFZUDvWJKnBHBFlb 2atM8zC+H9MBd/dH6lOF3fgKpgXu7s+53PPxOWUN3N2f8/hmQQO4m4cz7+DsJge7wkzLvVvW K/xCB73HhLt5+PWHReg9JtzNw69RDaPoPSbczcOvUQ2j6D0m3M3Dr1ENo+g9JtzNw3Gj2Hre Xl+zGeg9JtzNg3F3hU/bT17qbU57jwl389DrbrP5ycl7fXuLG6vpPSbczUN/3NVhJ3PTuLGa 3mPC3Tz0x91PviR8lZEXV+bpPSbczUOvu1qdrMPEhQX0HhPu5qHH3Y9vYZa5zRB3K6PHXX5+ 22yz7Wu2//LK34w6NXquThnb+6vv4O5h9Ljb89P20377KrK3z+L8JqfZXpRZbq7jgruH0+Pu 02b/x23+thVv2/84y0A7SCfnfSb1nbL8xOHu0fTWVV7/79Phy/Yg3Z22+yyX+eQ5K4XKNfNT 1ptr9h4T7uahv55Zbg+nbf5Funt9Vb4yoe95qebh7sH0uftps98eDm/5/20/n8u3bC99HYy7 0x7uHk9/2/zz22H/RWaYr2devn0+qxM0lT4ZdWe4ezh97l63P345ZKfPyt3r2eaW+n7KUM98 PH3uDj9tv4i3fXbeyuqmVCa0tf0J7tZBX7/K+dOmFG+fS7Hd7mXtpBR7XV/h2eGkMk+4ezB9 7k6fPklvryfZwHvlh3Iv5E1mnXsusv3hjDbCo+lrm59+2u5lzOWygbc1XdGHUtdRSl1d6aP3 mHA3D33lHTfuPosvWz+K4Mq5SCOh95hwNw997j6rzjAZcrJ97gJPd4xpTlesGXqPCXfz0Ofu E89y6W67P6mzVVyu2evM0XtMuJuH3rb5j3vOVcjx7Zsbe83hbjX0xt0nda6DGnZVD8upx1hN 7zHhbh6GnfPw+rrNXOCpH6eK0ntMuJuH3rgLzniozzTiQ3LN3mPC3Tz0jr3Wpxr5uspAeo8J d/MwNO62W7hbG79GLwsZRe8x4W4efo1qGEXvMeFuHn6NahhF7zE73J0ZWCtpzN0pWoSCBxF1 1/mbBWAFlHBHFrijyxB3uXgy5McST6SRX+w8mmgZzoPc9bfn3yHSXR5NpJHuHvXpDHQXD993 hXK3jyeTHJS7eLIlOMBdF3BHF7ijC9zRBe7oAnd0gTu6wB1d4I4ucEcXuKML3NEF7ugCd3SB O7q8K3dPRs4HXdmhUO4eBNx1Mtzd/nHu9jjXiDBwR5cB7hop3iW8iKdZIQPcfS/eO7xgBEmH uMvFO4cXp2jVYH0McjesrUOWg3RHsFAv4Q7uKAN3dIE7usAdXeCOLvdzV1xtqwXYtP2JErjT 3M/dIYuzs2lPvakSuNPc0V08CXfuet9RmcCdBu7oAnd0gTu6wB1d4I4ucEeXR7grZBO8SJKC y1uilgq35cJdIRviMinXySxwZ3mEO6UiKbQ7+aTm3ZYLd4lOk5hd7Dq4szzAXaHu2piaqHvE nUxaeHNw53mMO50ZWneM9cSdSq2SFlx3Y2rgzvIodzyIux53hTZm4i6x6+DO8ih3tsSLl3c6 qbnbdXBneVR5p2qXqpIZqWcmJqnyi3pmm0fVMxv0u2sDd5ZHte8axMq7JnBnQb8KXeCOLnBH F7ijC9zRBe7oAnd0gTu63NGdiFPZtP2pErjT4HoEusAdXeCOLnBHF7ijC9zRBe7oAnd0gTu6 wB1d4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3gji4D3A050eSunOFOM8Dd0H8xczfgzjDEnVgX J7gzwB1d4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3gji5wRxe4owvc0QXu6AJ3dIE7usAdXeCO LnBHF7ijC9zRBe7oAnd0gTu6wB1d4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3gji5wRxe4owvc 0QXu6AJ3dIE7usAdXeCOLnBHF7ijC9zRBe7oAnd0gTu6wB1d4I4ucEcXuKML3NEF7ugCd3SB O7rAHV3gji5wRxe4owvc0QXu6AJ3dIE7usAdXeCOLnBHF7ijC9zRBe7oAnd0gTu6wB1d4I4u cEcXuKML3NEF7ugCd3SBO7rAHV3gji5wRxe4owvc0QXu6AJ3dIE7usAdXeCOLnBHF7ijC9zR Be7oAnd0gTu6wB1d4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3gji5wRxe4o8uFu6LgnHGWFHIu SdQauFspne6UOJ7IZw3crZTLPFMGm7YGd2vnwp38DKQ1xriKPQ3crZRrcYc8c/3AHV268kxm 65kM9cxVcxl3sqKZ2DkzgbuV8q7d5WJxsgeSv+d+lVwsTh5NsRxwN408mmI5ns9dxeSeqbBP lRBqWU7TSsjXUJO0klP5kLNqu9DbmTC7qBm/XwV3tzHRnf7cA3eV9qPdqZfU7vREmITuoVOn bs/K3joPcSee1l3lJlqFqCRGkuTSnY5Aqc2GotsP7m5kcnlnPnzGvAOZ/V1xV6k8suVOwN1o xrrLTgpX3oVxJ2zc6fJOuVNlnX3Ibar0c7kq3E1icp5pntL0wl1HnmnrKsZdeuGu6jzEnXgi d3bJlnehOyUnFcxkn3K2311Y3sHdbcxTV/HubD1zgDtdQDbrmWnnIe7E88VdpcsxVYSpSeXb d8KWdyJo37nyLrV1FaHbd/V+KO9uBP0qlueLu3nJoymWA3E3jTyaYjkQd9PIoymW4127++Nm ce5wiKs8kbtFPma4uwnEneVp3P2ozhJQM8cXeRdCTzZyKh9ic9yo+4vaLte86Flh1shFsTEJ ZMI2cHcTI93Zh3G3UVrUnJpstKDNxj5etDgz0e7M7eWoF1rA3U2MdffRupNoSZIOd0dtV28y a49aobQHd9NZxp3MEY9td5umuw3cTWWku4+M/Sgx7lR5p9zJdP4hFYmjdXe8cPeC8m4Glom7 zTHIM182F+6OppRsA3c3MdGdMLUO+bwREXfHC3fIM6cxsZ45xN3RVTd9PVNs4G4GprbvNq59 t6nbd8KWd8KWd7qZoDcd0b6bEfSrWNCfOQ24uwnEnQVxNw24uwlcf2d5InfNpZnIoymWA3E3 jTyaYjmext1J5TJq5tr1d/6CkcrMqC3qehOXONXnQauz3+3Zm/okz/AQ9+Z53NmHOy/au3PX 3wm3vnZnD+HcyXXanT1rWm3FedG3MdZd1XDXvv5OeHdp6iLSHKIyflP7nMLdeCa6cxeDtK6/ Ez7WpDvGnDt1Crs++936NOe3e3co725jpDv5+fddf2cLMaWlcnFnyju7ThdvesH4Eyjvbmdy nmmeWtffCXt9lvakyzWXZ/p8VG+rXFLkmSOYp7xrX38Hd/dgnnpm+/o77047Cty5tXA3A9Pb dxW7vP7Ol3epiTRmW3DGnS38TBFpZlDejQD9Khb0Z04jj6ZYDsTdNPJoiuVA3E0jj6ZYDsTd NPrG15YGcTeNPJpiORB308ijKZYD43f1+J3+bUzVxgvafaZtV9XNdrfdTOHuNhYbvxNu8CcV fn3tzjbb/XbT8xIe4t5g/E5LdC6q2l1qe720UOOuCrfD3QgWHL9ruRPMjebZXkw9jOfdCbi7 leXG75QSxljtzmSZdsyuHsZLhUB5N4qFx+/CuLPlXuVCMg3KQ/MID3FvMH7ny7tLd2nUHfLM 21h4/M65MetVIribjeXG70x5l1o3er0WnNqhPb3Wbkd5Nwb0q1jQnzmNPJpiORB308ijKZYD cTeNPJpiORB30+gbX1saxN008miK5UDcTSOPpliO52vfuVZbZVpudfPNNMh7xuqE+ddA+kIT 91/wwkPcm2fsV3H9KYE7kyYyVud7X/yecHcjM/RF276wyim07iJjdbW7Srj9wkPcm2d1l1p3 bhRvyFid6SSz7gTcjWDi+J0txETlosuXd7GxOuHLO7gbyQxjQKaukrpyzcZRbKyunoO7kTzK Hcq76cwwfqfdVb4t4OOof6wO9czJTGzf+fKuspHmWnBGR89YnWi07/R+cHcb6FexoD9zGnk0 xXIg7qaRR1MsB+JuGnk0xXIg7qbRN762NEPc6TOJ1dlVjY/rYSDuLIPiLq2Cps3DQXlnGebO NHd0Y+fxzDB+p/83uW2rpWYwzrW3fbPdbddtQXsOp2kZCpa6fhUWHuLePI87EYzfucGfSpi/ KhWidld1/EymqITvkRGV7xNLEXe3McsYkBmm00Yq2+tlhKbCDSdcdZfaFWpzeIh7A3emczny M5kqCxWidifouKv0nXRdpTF+p93ZcTj3VwVjdn4YT226LO8oubPvmZFuI3SMAYm2u+s/12dT BEtU4m5dLODOOOpzR7a8Wxdzjd95N2agx47mDXBHqp65LmYYv7PlnTNiqiHGiSnvROquyOso 74SZpiTad+sC/SoWjCNMI4+mWA7E3TTyaIrlQNxNI4+mWA7E3TT6xteWBnE3jTyaYjkGuZOV aJaq0RA3/qrqz+akN3NGv7D1Zr2yClboh69km35Ds/lyh4qpm2A9u2tQ3lmGxZ3pXHcT4Vum wk/MwIlt6PoGbNApb/ZzXRcdO9htJt2V3TUztO8qd8ZlxYRtjdu3UJmxPREesI/cfhSVsJfk 6W+Z+tmWKq1sU1DNqy0mjR7809sEE/ZUT/msPxfbjBSt1Mxe7We/1vWxb3Ln/ib93HRX2wlT mE89rbde3cFu8+66dtfM0K+iXq2qvzjmG+K3mTa6GETtznfJqJdWvoT90tnvhlqZ+gR16tT2 yvmvaGpmw9Tms7EGgmPf5s7lfaLO6bwKxtz3WNR27Uq7X9NdYwe7zX65unfXTB8DSp07+6E1 3NnPNPiy9FG7s3+A+bDtCws78VZ9AudOEbgTbnMztTlI1fgK3+AurbxC4b+0oqHCviXnzu8Q ZHrp9R3UhPmU1t2MeaZouRNuaiJvsrtGnqnjTmfMRpLeUn8NvTuzzrsz+4mL1BPdVeZt2ajQ RUXqZoVw79P8WJddY3TolX4/dnUHNUl9iNm/oLm7YeL4nf3MzKejtpgeTHtFQpDFDaJ2Z+Tb 3bwNIbw789r2mxnmmUFqp6eVerw79ZfE/pRge9o5215xuUPa3Fx17K6ZL8/0n1Nqcs7aXSPQ +9DumHkBZ0PUZVqjvAv9XJZ3zG8Top16gjvGzPe+85Pvoer+8K8Spmfs2u7zl3dT3aUqcBt5 Zir0Ca3u2dQzU58L2rWunqmzIJfn2PcUpJ7irvtdP4z565kNd/qW3uaua4t/gTR4bm5z69xX yK1NL1Knwr3BgOccv2u073x5p/KXyhSxQ3MWkZuBvLYNMcFdUPV2K+zVfqPad6sC/SoW9GdO I4+mWA7E3TTyaIrlQNxNI4+mWI4h7vrGkB4Bxu8MA9ytEcSdGBR3awTlnXgidyeVy+g5076z vcW2h9b2Z95Obro+U2H7eAc3DGfgedzZh+050XfbLZaapvGoD7125zpp4C7CDP2Zpg84cNfd tRUhr6qq7myEuwFMvP5Ofb4mk9QPls7iTsDdEKaN3wkbd2F5B3f3Yoa4q/xwgoC7ezLH+J0Z 3p1c3ukTwerybujJEjPwtPXMS3cj65nWnXD1zOY4zZI8aftOTVMxT/tO/xQLQ/tuKOhXEU/l rrk0E3k0xXIg7qaRR1Msx5rcsYEkiDvNmtydesaqQhKM32nW5G7g+yiT9cXdqDrqVJ7I3SLk ZnK/hkHA07g7qVxGz3WP37kfXkzNT4oNJa9EMKhkTmR2VzcFl9AtwvO4E/3jd+Z6x8qcIj2c hjt/AUJqZutL6Bbhidz1j99VtjeyGuUurc84r9xlDkZaulyG+pTu9KfZGr+rzGntk9y5C+5s l1twCd0iPI+72PhdHXcjyjsXdyaiXXdptWTUrdSd/PC4bIEX6p7Iu1pQN8NMcdccv6tMtjki 7tLKXPIVlHfGnS36nqy8Szgv5C1Rd/2kFmZ01zF+59ylgt3oTssz7twFd6a8Cy+hW4RVu1Nz 87nrHb9Lx7rzc3V0+cv6Fmbl7go2m7tG+05N08b4ncnz9PSm8s7NsHoAML28hG4RVu6OzxZ3 C5FHUyzH2ss7745Ndtdcmok8mmI51urO1TNVhdPUM5nbirizrNadp2gnQ9xZKLhrLK4s7vrG 15YGY0DTyKMplgPuppFHUyzHO3d3UnmLXuwetUttD1Zl/9GdXjb/CMj0cZmn6uqvruTtFXfk vbsTkavunDthhxTqZdZwZ/e/aLTn7RV35FncuV7M9lV3adp055fdFSJ2Yva/vNggb6+4I0/k TgtqX3UXc8cY3A1hCXexUTvlitX/+Mcu26zzIu5SuLvCPeKufdWdibP0Iu6sNPO/e527jqG4 vL3ijqzJXfzdGpIJ5V3ryi1mf0zZubPLcLcgY+uZg92lLXf61nGNXt5ecUfeu7tG+05N08ao nQ6nsLwTdftONwcr88uVaN/NB/pVBNxNJY+mWA64m0YeTbEc3e5utLmLJ5kZuBPG3eXaW91d vsLSDHPHFieNJ1mMVLq7DLPVxx0/DHK3/M+2pg/8Zdj37S7+OhMp03iapSjhbhJwNwK4q90V BefqfLpCziVwN5TVuDPnH8vnJ3Mnd+X+WiM3I7/BAxjprtAnDyf6Ay/USahjqPPMRJ+CzGt3 6ndMCvUk/zL98ok5wVztlqijs8S8B/LuEu6+t+Y8bHs69hDGu2PmGqfm6fo34d3JP11ak5rU ixmZZlY93DeyvkiA22+Meg/vxR137vgd3BWF+55cnH86lHbcBXlmYv8gk5nqQzTcme3Fu4k7 nXEmfmZ5d/oaJ32phfqlptsZ4I67aeKUvTd3ury7c56pXz+ZLc9ktp7JktqdLe/0H8L0jP6S 1O6S91TeMc7czMLu3BfEXNc70Z3JgDWXeSa3cadl8SJwZ4rE9+DOXmvEuJtJIntppriT9b9C yZtez+xzl9jy7l27a7Fs3CUDX7+Pnn6Vjnpmw52+Je/BnWnftVi4vFvW3UX7zpd3ci0r3lH7 bgLozxwB3MHdROBuBHBn3R3aq+FuKA90x7W7i7PJ34s78c7pqq1eBGI/STTF7AxyFz/lgzad 7gZf1mHoeIGlgTtJPkMr8QEMccfePaoBTo8h52duwDoZ6O4j++W7y53F5SpwPwa6+/CNdewM d8vjcsiOmWHuPn74puLuRRxf1E0IPTmaiTjKFEJIk0LoJaGcCnNTTyaNTCw2bsf+9wtqTqY+ teuYGeZOht0vTPswn7xTcDRCNhtv0m6z7swavxbubsf2Eew6Zoa6+6YKPB1PXop1ocwJbUtL e5HLQlk1yTYb766OW7gbzlmfv6aUFSqjvNndR/ZBZ5pycaP0HBvuhI47F5WNPFPmrsfAnck/ 4e4WAndcDRUqd2okcag7Ke4DYxtXgm1Ew93Gu3tRAacjryvPRNyNoc4qa3f6FI/B7pgs775z NlS9Q90uyru6ZLP5Zsud8DvG3zMwdLnT4/jD80wZed/qeqapp2wu65mbOs/UhaBabXJSHa8b YXeMvWPg6HSnrhQY5k42zGXkSXcd6GLMcFWIThMkRMPwBibGnQw6k2d2MNjdBu5GMbG80627 K+7AwgTufBvhhnrmR6YCrzvPBAvT5c6uGZ5nwt1DmNivYvPMrt5osDRWQ9UxM8TdX5hqm//8 c/xA4J5g7JUuA9xxsE7i7gRYK1F3cf/gQRwi7gAR4I4ucEcXuKML3NEF7ugCd3SBO7rAHV3g ji5wRxe4owvc0QXu6AJ3dIE7usAdXeCOLnBHF7ijC9zRBe7oAnd0gTu6wB1d4I4u1l3H74OC lZNbd3f4cW8wM3BHF7ijC9zRBe7oAnd0gTu6NNyVpt2wv5raNy2upujE7XX9hcEIGu7UrOT7 a4lLxjpSlPofvBYsMFM2BJdwtwhNd+pJCG/Gf+h2eadniixruNupnwfkDaHmS+BUuVcoG+5u D1/QpOnO/DqHl7BzcWY/9F1W7s4X7tihSniRCFav2qn+0Sp0p+Zrd6VchruptOPu0HD3g+G3 /e7Oco8dPzTcHVru1LR2l8HdDPTFXfkbk2P+IeKOc+WOO3cyp43EXQl3c9B09ycecXfqcLdL yu9Lti/cSvmCkbhzxSjcTaLp7ne/D90V/3zhTv3DvrY7VfvcBVUTGXT9ceerQHA3iaa7r//T 5S4o7yzNVkS2yxj/3ouQQdcfd14d3E2i5e6vDXdCnIa4k5F3KOr6/5W4K337Du7moc9dyX74 QS3/LnSnZtvudkkatO5M3J2yXTPuyjru9nA3Bw13f/jznxrudqdENRF+1467sulOht1pX3er mLirRNGKO17HXbTzDQyg4e5fvn79/VnV+C27U6rae0nE3S4Ru3NR76Xjrjq34650rkoXeBxM IXT3p69fv/53EXRuybjjcXcy7CqW8lY9s6oTZY56RYmwm07o7s9fxdevhTjX7s6JirugT6zL nQw7lrE68FTchd2Zl+5KhN0cNOPurzLuRG1md5BxJ2uVdV+0pekur77nu5TX7kTZUHPhjkPc HFyUd0VdTvGMybhLgzjsdneQIVaycxB3QWHHde9ly12J/HIGLuqZRZAhlpmMu7Sj4GpEzU7n lrs0iLuqkateugNz0OoT+21YTkl5Mu6SIA7d4GzDQqb3KH0Vp1nYcV288YyjbjI3zXMe/tCO Dm3KL3XHXWmWvJqynYB37ASmg3ON6AJ3dIE7usAdXeCOLnBHF+9OAGo4dxkgB+KOLog7ujh3 gCJwRxe4owvc0WVudyy4HqhNcn0TGMH8cZeM2ALG4N0V8pEUvPBxIzfIJbnKrUnUXSVRq7m8 F3ont00+1B6JTJFwvd1QcL2HfEp6YhLcTttd4qMj4dZVsMK6cwpb7vSmIvHbDdqdXsMQebNy 6c6R8Ka7olD30F0iCRP7TfoL0HLHw+8FmIO2O+bzuoRPctfMMxlL4G5uanesDhmNKu8Gu2Ms abrzual84fqFEg7mI1LeFYE7rqshhXsqwgJPVVwSX94xlHf34Ho9M1ErpS63JrHuCvWTHCpP 7HRn6plyF9QzF6fhzqtQJO45cctJMyhDtDveSdHx2mAOgvKOhaWUKe94UN4pPTzxC010eWfn W5LgbinQn0kXuKML3NEF7ugCd3SBO7rAHV2Muw2gR+DuI/vlu0hqsCYCdx++sVhqcH9YC78i cPfxwzfE3Qo5mbOgd27qVwTuZNj9gsBbH2dbL3FTv6Lh7psq8F6O6i7ERt+EWgCP5GwGBXbn QmWUne4+sg8603w5ipejuklzZgIeSu2Oq7EY5U6NjobupLgPsvxz7jYbuFsHPs+s3RVJkTTd MVneybgTQhzlE+JuJXS40yefN/NMGXnfrDvkmauhy50Mu8CdbJjLyNPuNsLUVY7CTOIvDxYk Hncy6Fye6XUJ/wQeR7y806077e7omwVwtwZqd76N0KpnfmQq8FSe2XIHHkyHO7OilWdKd2Bl xPtVbJ6JTrHVYX+Ro3JTv8K7+wtTbfOff46/FlgLGHulC855IAzc0UW7u/itKkCBHev7VQ2w ZlSL7/8BUEsBAhQAFAAAAAgAj3lxKYYj1gcIHgAAHkUEAAoAAAAAAAAAAAAgALaBAAAAAG1l cmxvdC5ibXBQSwUGAAAAAAEAAQA4AAAAMB4AAAAA --------------0B7BD7C5D40631BC6962AD46-- From Nicolas Matringe Fri Nov 17 16:29:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00457 for ; Fri, 17 Nov 2000 18:58:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:58:58 +0100 (MET) Received: (qmail 1341 invoked by uid 0); 17 Nov 2000 15:44:44 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx15) with SMTP; 17 Nov 2000 15:44:44 -0000 X-eGroups-Return: sentto-1101623-1503-974475001-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ei.egroups.com with NNFMP; 17 Nov 2000 15:30:24 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 15:30:01 -0000 Received: (qmail 13377 invoked from network); 17 Nov 2000 15:30:01 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 17 Nov 2000 15:30:01 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 17 Nov 2000 15:30:00 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id PAA16220 for ; Fri, 17 Nov 2000 15:29:54 GMT X-To: Message-ID: <3A154EDD.4F0FF652@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@egroups.com References: From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 16:29:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb78b50e89abcaebed0a993cd2a49758 Status: R X-Status: N Keyshaun wrote:
>
> Ok, that makes good sense.  I had just wondered if the IO
> instructions could be flagged (for a better term) so that the IO
> bus could catch them and handle them differently.

If you have a large enough address bus (a 32 bits bus can address 4
Gbytes), you can decide to assign the upper half of this space to IO, so
that the address MSB flags the IO accesses.
Quite easy :o)

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
eGroups Sponsor
From Keyshaun Fri Nov 17 18:37:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00475 for ; Fri, 17 Nov 2000 18:59:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 17 Nov 2000 18:59:02 +0100 (MET) Received: (qmail 30852 invoked by uid 0); 17 Nov 2000 17:37:48 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 17 Nov 2000 17:37:48 -0000 X-eGroups-Return: sentto-1101623-1504-974482653-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 17 Nov 2000 17:37:43 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 17:37:33 -0000 Received: (qmail 65845 invoked from network); 17 Nov 2000 17:37:32 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 Nov 2000 17:37:32 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta2 with SMTP; 17 Nov 2000 17:37:30 -0000 Received: (qmail 27523 invoked from network); 17 Nov 2000 17:37:24 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 17 Nov 2000 17:37:24 -0000 X-Sender: To: In-Reply-To: <3A154EDD.4F0FF652@IPricot.com> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 10:37:26 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 49adc1c0ed2de8531e11bf3391a29a22 Status: R X-Status: N I guess so, Last night I was thinking how nice it would be if 64bit
processors would have a 48bit external address bus.  This was more of a
virtual memory problem in my mind though.  I want to see the removal of
the MMU from the processor and make it more featured.  The only trouble
with that is it (with todays processors) creates a limit of what can be
addressed.  Commonly the first 2GB are user and the last 2GB are OS or IO.
Though, I don't think that 2GB is all that shabby for a userland program.
I guess I just don't think that 2GB of userland is suitable for expansion
to super computing if desired.

I guess it's a moot point since no one plans on putting windows on this
kind of processor so we don't have so much bloat to worry about.

Shaun

On Fri, 17 Nov 2000, Nicolas Matringe wrote:

> Keyshaun wrote:
> >
> > Ok, that makes good sense.  I had just wondered if the IO
> > instructions could be flagged (for a better term) so that the IO
> > bus could catch them and handle them differently.
>
> If you have a large enough address bus (a 32 bits bus can address 4
> Gbytes), you can decide to assign the upper half of this space to IO, so
> that the address MSB flags the IO accesses.
> Quite easy :o)
>
> --
> Nicolas MATRINGE           IPricot European Headquarters
> Conception electronique    10-12 Avenue de Verdun
> Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
> Fax +33 1 46 52 53 01      http://www.IPricot.com/
>
>
>
>
eGroups Sponsor
From Michael Riepe Fri Nov 17 15:35:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00321 for ; Sat, 18 Nov 2000 18:00:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:50 +0100 (MET) Received: (qmail 12503 invoked by uid 0); 17 Nov 2000 18:54:19 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx03) with SMTP; 17 Nov 2000 18:54:19 -0000 X-eGroups-Return: sentto-1101623-1505-974487242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 17 Nov 2000 18:54:16 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 18:54:02 -0000 Received: (qmail 25522 invoked from network); 17 Nov 2000 18:54:01 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 17 Nov 2000 18:54:01 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.207) by mta1 with SMTP; 17 Nov 2000 18:53:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00760; Fri, 17 Nov 2000 15:35:43 +0100 Message-ID: <20001117153543.00722@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A151729.7418DA11@f-cpu.org>; from Yann Guidon on Fri, Nov 17, 2000 at 12:31:53PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 15:35:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2c390e3974d7bc88efa40d4a512171ef Status: R X-Status: N On Fri, Nov 17, 2000 at 12:31:53PM +0100, Yann Guidon wrote:

> > I hope I don't get stoned for suggesting this, but could there be an
> > instruction mod that sets an external bit for IO instructions.
> you'll be stoned, bashed, killed and amputed for even imagining the possibility
> of an opportunity of the chance that this could exist :-)

May I suggest tar and gzip^H^H^H^Hfeathers? ;)

> more seriously, the last 20 years have proven that I/O instructions are
> not compatible, necessary or benefic for a RISC system. Ok, it takes more
> instructions to use memory-mapped I/O but the instructions are the same,
> they are scheduled, protected and safe for the pipeline.

I used to like Intel-style I/O instructions because they have a separate
address space.  On the other hand, there's no big difference between
I/O read/write and uncached memory read/write operations -- implementing
both of them would be overkill.

While we're at it... I didn't see anybody mention interrupts and DMA so
far -- will the F-CPU handle external interrupts at all?  In that case,
the G-chip should probably contain an interrupt routing facility, as
well as a simple DMA engine that can transfer data between F-bus ports,
internal devices (like the IDE/SCSI controller) and local memory.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Fri Nov 17 14:33:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00324 for ; Sat, 18 Nov 2000 18:00:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:51 +0100 (MET) Received: (qmail 30613 invoked by uid 0); 17 Nov 2000 18:54:19 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx08) with SMTP; 17 Nov 2000 18:54:19 -0000 X-eGroups-Return: sentto-1101623-1506-974487253-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 17 Nov 2000 18:54:18 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 18:54:13 -0000 Received: (qmail 86952 invoked from network); 17 Nov 2000 18:54:13 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 Nov 2000 18:54:13 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.207) by mta1 with SMTP; 17 Nov 2000 18:54:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00601; Fri, 17 Nov 2000 14:33:58 +0100 Message-ID: <20001117143358.08241@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> X-Mailer: Mutt 0.84e In-Reply-To: <002101c0502b$100a4c20$7bcffea9@schlappi>; from Erik Hansen on Fri, Nov 17, 2000 at 01:12:13AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:33:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 88ddb21a7ebe9999c9ffd2ce8af829ec Status: R X-Status: N On Fri, Nov 17, 2000 at 01:12:13AM +0100, Erik Hansen wrote:

> I was able to synthesise rop2 and iadd, as well as an intermediate Version
> of inc with both tools and they perfomed quite well.

Yeah!  Thank you very much.  I think I'll have the next version of the
IMul EU ready in a few days, too... I already rewrote the 8x8 multipler
and the wallace trees, but I have problems simulating the whole unit
(it's too big -- Symphony EDA runs out of memory when I try to load the
structural architecture).  I wish I had one of those fine Octal-Xeon
servers with 16 GByte of RAM...

BTW: does anybody have an idea why this configuration doesn't work?
Simili still uses the default (most recently compiled) architecture
for the Mul8x8 and Wallace components :(

    configuration imultest_small of imultest is
        use work.all;
        for Arch_1
            for all : IMul
                use entity work.IMul(Behave_1);
                for Behave_1
                    for all : Mul8x8
                        use entity work.Mul8x8(Behave_1);
                    end for;
                    for all : Wallace
                        use entity work.Wallace(Behave_1);
                    end for;
                end for;
            end for;
        end for;
    end imultest_small;

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Fri Nov 17 14:55:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00327 for ; Sat, 18 Nov 2000 18:00:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:52 +0100 (MET) Received: (qmail 24375 invoked by uid 0); 17 Nov 2000 18:55:52 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 17 Nov 2000 18:55:52 -0000 X-eGroups-Return: sentto-1101623-1507-974487294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 17 Nov 2000 18:55:51 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 18:54:53 -0000 Received: (qmail 88187 invoked from network); 17 Nov 2000 18:54:07 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 Nov 2000 18:54:07 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.207) by mta1 with SMTP; 17 Nov 2000 18:54:03 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00651; Fri, 17 Nov 2000 14:55:19 +0100 Message-ID: <20001117145519.20577@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A150C5B.66DEBAFD@f-cpu.org>; from Yann Guidon on Fri, Nov 17, 2000 at 11:45:47AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 14:55:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9732ad65c90508961331fbdf455e4c1d Status: R X-Status: N On Fri, Nov 17, 2000 at 11:45:47AM +0100, Yann Guidon wrote:
[...]
> So a CPU module would consist of a F-CPU chip and 8 SDRAM chips,
> we could use DRAM-like connectors to plug a module on a
> larger PCB. the interface would need a maximum of 100 pins for the
> 32-bit IO versionso we can reuse existing connectors easily.
> The size of this module is rather compact, i have no estimation
> or number yet but around 10*5 cm or a bit more.

Don't forget the core voltage regulator(s).

> you could probably put 4 or 8 such modules on a PCI board (the PCI
> board would have the G-chips) but beware of the power consumption
> (15W max/board).

External power supply?

> Remember : a bus, either PCI or else, is not a good idea if you want big
> clusters. The reason is simple : 1) the real bandwidth (measured) is
> often lower than the specs let you think 2) the more boards you add,
> the less speedup you gain. Same for the ring that Nicolas proposed.

I'd prefer something more fault tolerant anyway, like the cube you
proposed, or maybe a flat (2-dimensional) hexagonal structure.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Ben Franchuk Fri Nov 17 10:40:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00333 for ; Sat, 18 Nov 2000 18:00:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:54 +0100 (MET) Received: (qmail 12927 invoked by uid 0); 17 Nov 2000 19:24:50 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx10) with SMTP; 17 Nov 2000 19:24:50 -0000 X-eGroups-Return: sentto-1101623-1508-974489061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 17 Nov 2000 19:24:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 19:24:20 -0000 Received: (qmail 18937 invoked from network); 17 Nov 2000 19:24:11 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 17 Nov 2000 19:24:11 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 17 Nov 2000 19:24:10 -0000 Received: from jetnet.ab.ca (dialin46.jetnet.ab.ca [207.153.6.46]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA17188 for ; Fri, 17 Nov 2000 12:15:50 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A14FD0C.6A95352B@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 09:40:28 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d765f746004ba4c6a3aecca1be50f912 Status: R X-Status: N Michael Riepe wrote:
>
> May I suggest tar and gzip^H^H^H^Hfeathers? ;)

I use tar to back up my system, It don't work well with Feathers.
While I/O instructions in modern machines are mostly useless,
the I/O concept was good on the older machines where a I/O instruction
could do alot with a single instruction. Say clear fault flags,
set up a DMA address and start the tape drive Z. Sadly to say
good designed I/O is still it seems a after thought on most
machines.Also the modern chips all seem to want huge amounts of bit
fiddling to do anything. Get chip address,get register n, fiddle with
bit z.
>
> While we're at it... I didn't see anybody mention interrupts and DMA so
> far -- will the F-CPU handle external interrupts at all?  In that case,
> the G-chip should probably contain an interrupt routing facility, as
> well as a simple DMA engine that can transfer data between F-bus ports,
> internal devices (like the IDE/SCSI controller) and local memory.

Are interrupts needed anyhow? The G-chip could most likely poll a fast as you
need.
The F-CPU could go to the next task on a fault.
Ben.
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Fri Nov 17 23:56:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00354 for ; Sat, 18 Nov 2000 18:00:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:58 +0100 (MET) Received: (qmail 27072 invoked by uid 0); 17 Nov 2000 22:51:28 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx03) with SMTP; 17 Nov 2000 22:51:28 -0000 X-eGroups-Return: sentto-1101623-1511-974501485-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 17 Nov 2000 22:51:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 22:51:25 -0000 Received: (qmail 21165 invoked from network); 17 Nov 2000 22:51:24 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 17 Nov 2000 22:51:24 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 17 Nov 2000 22:51:23 -0000 Received: from f-cpu.org (nas1-146.ras.club-internet.fr [195.36.192.146]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA05728 for ; Fri, 17 Nov 2000 23:51:19 +0100 (MET) Message-ID: <3A15B791.806526C7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A154EDD.4F0FF652@IPricot.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 23:56:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1a7a0c0db2afe2446fc6e6dae68878f6 Status: R X-Status: N hi Nico,

Nicolas Matringe wrote:
> Keyshaun wrote:
> > Ok, that makes good sense.  I had just wondered if the IO
> > instructions could be flagged (for a better term) so that the IO
> > bus could catch them and handle them differently.
> If you have a large enough address bus (a 32 bits bus can address 4
> Gbytes), you can decide to assign the upper half of this space to IO, so
> that the address MSB flags the IO accesses.
> Quite easy :o)

Things like that were done in the ol'good time of the 6800/6809/68000,
but a bit more sophisticated (a 74LS138 on the 3 MSB to decode 8 regions)...

ah... nostalgie...

:-)

> Nicolas MATRINGE           IPricot European Headquarters
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Nov 17 23:56:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00357 for ; Sat, 18 Nov 2000 18:00:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:00:59 +0100 (MET) Received: (qmail 6532 invoked by uid 0); 17 Nov 2000 22:51:40 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx01) with SMTP; 17 Nov 2000 22:51:40 -0000 X-eGroups-Return: sentto-1101623-1510-974501482-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 17 Nov 2000 22:51:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 22:51:22 -0000 Received: (qmail 30329 invoked from network); 17 Nov 2000 22:51:21 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Nov 2000 22:51:21 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 17 Nov 2000 23:52:26 -0000 Received: from f-cpu.org (nas1-146.ras.club-internet.fr [195.36.192.146]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA11199 for ; Fri, 17 Nov 2000 23:51:15 +0100 (MET) Message-ID: <3A15B78D.CB6FB5C3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A154CF9.8456CAE7@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 23:56:13 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] merlot xml editor screenshot using class dtd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4f5f83eda9b8dc7f3e91ec75d9f79ebd Status: R X-Status: N hi !

Jeff Davies wrote:
> Here is merlot in action, editing a class implementation.
> (merlot is written in java)
<snip>
> Jeff Davies
> by the way this may seem off topic, but it is following the GNL concept.

i still have to test this, but you seem to be optimistic,
so it can't be completely wrong. unfortunately, i don't have time
(yet) to work on the SW/compilation side. i may write some
programming/compiling guidelines though. it could be integrated
in the manual later.

If you could prepare an example with files that people could test,
it would be nice :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Nov 17 23:56:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00360 for ; Sat, 18 Nov 2000 18:01:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:00 +0100 (MET) Received: (qmail 5981 invoked by uid 0); 17 Nov 2000 22:51:28 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx01) with SMTP; 17 Nov 2000 22:51:28 -0000 X-eGroups-Return: sentto-1101623-1509-974501479-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 17 Nov 2000 22:51:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 22:51:19 -0000 Received: (qmail 39911 invoked from network); 17 Nov 2000 22:51:18 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 17 Nov 2000 22:51:18 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 17 Nov 2000 22:51:17 -0000 Received: from f-cpu.org (nas1-146.ras.club-internet.fr [195.36.192.146]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA14144 for ; Fri, 17 Nov 2000 23:51:13 +0100 (MET) Message-ID: <3A15B78C.148A3A9E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> <007101c0502e$fa59ca00$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 23:56:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cfb6d57486801fe1a41d050cdc1d16ea Status: R X-Status: N hi again,

Marco Al wrote:
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
> BTW wouldnt it be smart to put cachebility in the page table so even non
> local memory can be cached? (even if coherency is software controlled it
> would be nice if you could cache memory on another processor if you had
> guarantuees on it not changing, better than always having to replicate or
> move it)
i guess that the SW is still the best solution, otherwise coherency becomes
a problem. let's keep the specifications loosened on this part, so we can
see what goes on.

> > Mais non ! It's very simple. The MMU has 2 mode ics (inside critical
> > section) and none-ics.
> How does it know which mode its in again? :)
i don't know. I have difficulties to understand his point of view.
i hope that we'll be able to discuss about it in the pre-meeting in Paris.

oh, btw, yes, several french f-cpu team members are organising a "pre-meeting"
in/around Paris, as to organise the real meeting in Berlin during the 17C3.

> > And the better predictable network ever made is the one in ring.
> A shared bus isnt half bad either, both will need extra hierarchies to scale
> past small amounts of processors.
that's the real problem. there was a "supercomputer" made
with several hierarchies of rings
(Was it the KSR ? it was the same period...)
and it never reached outstanding performance.
read the comp.sys.super FAQ. Ring-based architecture sucks.

A higher degree of interconnexion is more than necessary. I have seen
that 4 links is a strict minimum. a T3D requires 6 links (3-D torus)
but it also needs another link to a central repository for
high-speed semaphores/synchronisation. A 3D torus with an internal
tree (a mix of 2 different topologies) seems to fit most of the
most demanding tasks. It is rather easy to route and can tolerate
faulty nodes through node re-routing. Architecturally, it's
something between the Thinking Machines CM-5 and the Cray Research T3E.
There, you don't have any bandwidth problem at all...

> > This idea come when i see the program of whygee for SMP system (a
> > graphical program on DOS in pure ASM and MMX, my usual complet nightmare
> > ;-). He use the both cpu inside each functions. So i think that usualy
> > you don't compile program to be run on 2 cpus. Only one are used. You're
> > compiler manage to schedule 5 or more instruction to be run in the same
> > time. Why not for a higher level for BLOCKs of instructions ?
> 5 or more? Thats a bit optimistic, Merced wouldnt be having troubles if
> compilers were that good :)

I think that i didn't understand Nicolas, and he didn't understand me well either.

The goal of the master thesis' program was to use a PC to its maximum.
the "reference platform" was my Pentium 200 MMX and i have developped
a method (the "heart" of GNL) to schedule instructions in a superscalar
CPU.

I have used a SMP system at a certain time, but quickly abandonned because
i had to write 3 codes : on for the monoCPU version, one for the master CPU
and one for the slave CPU (It was a dual P2/266 system). i have managed
the SMP without too much troubles though, only time was lacking and i needed
to reproduce the results (particularly the good ones ;-D) on any MMX-enabled
CPU. Both CPU in the SMP version communicate through simple semaphores in memory,
the computation domain was "statically" allocated during specification of the
model. nothing transcending.

The good thing is that during this master, i have developped
a method for statically scheduling
a whole block of instructions, not a few ones at once.
The larger block, the better (more optimisation opportunities),
and it's not limited by the number of register, in contrary :
less registers means difficult scheduling. It's not limited by
the number of concurrent instructions : it is limited by the
available execution units. No secret though : if your code requires
150 additions and can only do 2 additions per cycle, it won't
be shorter than 75 cycles. That's why a superscalar CPU should
have as many parallel execution units as possible.

> Finegrained multithreading is definetely a good idea, NEC has a nice article
> on their SMT processor which describes some algorithms where your approach
> works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf
their SIMD data are 32-bit wide. i am laughing :-)
Their mutlithreaded CPU can be outperformed by a 128-bit SIMD CPU.
They also renewed my interest for the scatter/gather instructions.
Their mutlithreading algorithm looks crazy, because they could do vectoring
or wide SIMD with a compiler that would be only a bit smarter.


> > This could be practice for SMT processors. Pratically a SMT processor
> > could be simulated on a cpu with large register set (like the fcpu) BUT
> > the size of the instruction word is shorter, so you reduice the need for
> > memory bandwith, you can hide the SRAM of the cache latency, have very
> > big pipeline (a want to write the 64*64 multiplier with ... 128 levels
> > of pipeline ;)... So you can change in the above text "4 cpus" by "4
> > ways SMT processor".

In practice, SMT surpasses multi-cores. few added complexity, easy porting,
dynamic load balancing, that's almost a dream.

A little bit of computer history : the first SMT computer ever is
the I/O processor of the CDC6600. it switched every cycle to one
of 10 "contexts" (was it 12 ?) and executed one instructions.
This made the CPU look like 10 slower CPUs. more info is available
on the web. It was an incredible machine, indeed.

> Apart from the obvious changing to instruction fetching the instruction
> decoding would have to change such that it automatically selects the correct
> subset of registers though (or alternatively you could have 4 different
> versions of all code :).
This is an obvious change to the CPU core. less obvious changes to a normal
core are the selection of the instructions and the detection of the free
ressources.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Fri Nov 17 23:56:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00363 for ; Sat, 18 Nov 2000 18:01:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:01 +0100 (MET) Received: (qmail 17210 invoked by uid 0); 17 Nov 2000 22:51:50 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx16) with SMTP; 17 Nov 2000 22:51:50 -0000 X-eGroups-Return: sentto-1101623-1512-974501491-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 17 Nov 2000 22:51:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 22:51:31 -0000 Received: (qmail 21442 invoked from network); 17 Nov 2000 22:51:30 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 17 Nov 2000 22:51:30 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 17 Nov 2000 22:51:29 -0000 Received: from f-cpu.org (nas1-146.ras.club-internet.fr [195.36.192.146]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA14195 for ; Fri, 17 Nov 2000 23:51:25 +0100 (MET) Message-ID: <3A15B798.DEABE043@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> <3A14FD0C.6A95352B@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 23:56:24 +0100 Reply-To: f-cpu@egroups.com Subject: (IRQ) (was : [f-cpu] IO instructions.) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4b14d3d2ec6e36dba81533af023c3012 Status: R X-Status: N Ben Franchuk wrote:
> Michael Riepe wrote:
> > May I suggest tar and gzip^H^H^H^Hfeathers? ;)
>
> I use tar to back up my system, It don't work well with Feathers.
> While I/O instructions in modern machines are mostly useless,
> the I/O concept was good on the older machines where a I/O instruction
> could do alot with a single instruction. Say clear fault flags,
> set up a DMA address and start the tape drive Z. Sadly to say
> good designed I/O is still it seems a after thought on most
> machines.Also the modern chips all seem to want huge amounts of bit
> fiddling to do anything. Get chip address,get register n, fiddle with
> bit z.

the badly designed IO problem remembers me the story of the first commercial
computer. The "CPU" (cabinet) was built, and the team was happy, they sent it
to the customer. Then they realised that they couldn't use it. The other
components were not going to be ready before they think about it...
it's well written in the "Supermen" book :-)

> > While we're at it... I didn't see anybody mention interrupts and DMA so
> > far -- will the F-CPU handle external interrupts at all?  In that case,
> > the G-chip should probably contain an interrupt routing facility, as
> > well as a simple DMA engine that can transfer data between F-bus ports,
> > internal devices (like the IDE/SCSI controller) and local memory.
> Are interrupts needed anyhow? The G-chip could most likely poll a fast as you
> need. The F-CPU could go to the next task on a fault.

IRQs are supported. There were some proposal in the "past" (1.5 year).
I propose a very simple method :
- IRQ signal -> querry the IRQ number.
- IRQn is ORed with the contents of SR_IRQ after a 6-bit shift
   <- SR_IRQ is a special register containing the base address of
      the interrupt table. the IRQ number gives the offset into this table.
- the CPU, when ready to decode instructions (decoder level), starts
to flush the register file (with the SRB mechanism) while fetching the
instructions from the address computed above. The latency of the memory
(if not in locked L1) is probably enough to flush the important parts of
the register file. the flush, however, might provoke some cache thrashing.
we better issue the instruction address /before/ the RF is flushed.
- The fetched instructions start at a fixed address, do some useful
job, then if 32 instructions is not enough, jump to another address
(as defined in the code). The 32 instructions slot leaves enough
time to prefetch the new instruction block. Don't forget that the
bus might be thrashing some kilobytes at the same time, it will require
some time to go to the address where the rest of the IRQ code is stored.

no microcode, no complex scheduling. smooth and no lost cycle.

OTOH, if the F-bus that i have in mind succeeds, the "IRQ" command will
do the trick : this command works very simply, put the right command code
and the IRQ number during a free cycle on the F-bus, that's all.
Well, now i realize that the IRQ ACK is missing.

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Fri Nov 17 20:18:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00366 for ; Sat, 18 Nov 2000 18:01:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:02 +0100 (MET) Received: (qmail 3432 invoked by uid 0); 17 Nov 2000 23:03:16 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx21) with SMTP; 17 Nov 2000 23:03:16 -0000 X-eGroups-Return: sentto-1101623-1513-974502185-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mr.egroups.com with NNFMP; 17 Nov 2000 23:03:14 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 23:03:05 -0000 Received: (qmail 46090 invoked from network); 17 Nov 2000 23:03:05 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 17 Nov 2000 23:03:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta3 with SMTP; 18 Nov 2000 00:04:07 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01859; Fri, 17 Nov 2000 20:18:16 +0100 Message-ID: <20001117201815.38854@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> X-Mailer: Mutt 0.84e In-Reply-To: <3A154B07.5E7BED6@llandre.freeserve.co.uk>; from Jeff Davies on Fri, Nov 17, 2000 at 03:13:11PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 20:18:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3defb94d062f49d6bb0a3085871dd8f6 Status: R X-Status: N On Fri, Nov 17, 2000 at 03:13:11PM +0000, Jeff Davies wrote:
[...]
> Although Java does not give explicit access to pointers, they are used
> implicitly (and the code is safe).
> What kind of things would be necessary to make available in, a core
> iolib type package written in
> FCPU assembler such that the Linux Kernel (or other) could be written in
> Java, and compiled into
> bytecode and from there into native code?

The Linux kernel is written in GNU C (plus assembler here and there).
Porting it to Java, Lisp, Smalltalk, Prolog, Fortran, Algol, Pascal,
Modula-<n>, BASIC, Ada or any other so-called high-level language would
be a *very* hard & dirty job...

Java is unsuitable for system programming anyway.

> The main reason for this is that I have noticed that my productivity is
> much greater in Java than in C++.

That's not surprising at all...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sat Nov 18 00:27:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00372 for ; Sat, 18 Nov 2000 18:01:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:04 +0100 (MET) Received: (qmail 6657 invoked by uid 0); 17 Nov 2000 23:28:06 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx21) with SMTP; 17 Nov 2000 23:28:06 -0000 X-eGroups-Return: sentto-1101623-1514-974503671-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 17 Nov 2000 23:28:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 17 Nov 2000 23:27:50 -0000 Received: (qmail 41031 invoked from network); 17 Nov 2000 23:27:49 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 17 Nov 2000 23:27:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta1 with SMTP; 17 Nov 2000 23:27:48 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00502; Sat, 18 Nov 2000 00:27:48 +0100 Message-ID: <20001118002748.18989@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> <3A14FD0C.6A95352B@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A14FD0C.6A95352B@jetnet.ab.ca>; from Ben Franchuk on Fri, Nov 17, 2000 at 09:40:28AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 00:27:48 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2941112f5cd3dfebbe8f42cc2d6be4e7 Status: R X-Status: N On Fri, Nov 17, 2000 at 09:40:28AM +0000, Ben Franchuk wrote:

> Are interrupts needed anyhow? The G-chip could most likely poll a fast as you
> need.

You're kidding, aren't you?  Of course we need interrupts!  Unless you
can offer something better, of course ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Sat Nov 18 01:37:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00387 for ; Sat, 18 Nov 2000 18:01:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:08 +0100 (MET) Received: (qmail 29326 invoked by uid 0); 18 Nov 2000 00:32:36 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx17) with SMTP; 18 Nov 2000 00:32:36 -0000 X-eGroups-Return: sentto-1101623-1517-974507551-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 18 Nov 2000 00:32:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:32:31 -0000 Received: (qmail 80981 invoked from network); 18 Nov 2000 00:32:30 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 18 Nov 2000 00:32:30 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 18 Nov 2000 00:32:30 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA06642 for ; Sat, 18 Nov 2000 01:32:26 +0100 (MET) Message-ID: <3A15CF44.9F70B911@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:37:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] todo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e956390ef6b8357e0561baef15b4f8c Status: R X-Status: N hello,

things to do (on my personal list) :

- f-bus protocol : better IRQ management, data burst length
(additional bits in the command word ?)

- VHDL : update F-CPU_config.vhdl :
* add SR_URL, SR_IRQ_base, and other SRs for IRQ and "general purpose".
* add new files : iadd, maybe inc
* include casting and similar modifications to the testbenches,
    as modified by Erik Hansen
* finish the cache, so i can work on the fetcher...
* check if Simili can scale enough to larger designs.

- prepare all the stuffs for 17C3

that's only a sample of all the things that really are on my
personal list, but it's the highest priority at the moment.
The F-bus definition is a big undertaking but it's not as complex
as a CPU. I hope that the VHDL side of the project will move
fast enough, having an forum to upload files at f-cpu.de would
be a must.
Things are moving. Lurk out and help :-) please :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Nov 18 01:37:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00390 for ; Sat, 18 Nov 2000 18:01:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:09 +0100 (MET) Received: (qmail 4126 invoked by uid 0); 18 Nov 2000 00:32:45 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx09) with SMTP; 18 Nov 2000 00:32:45 -0000 X-eGroups-Return: sentto-1101623-1516-974507550-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 18 Nov 2000 00:32:44 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:32:30 -0000 Received: (qmail 1724 invoked from network); 18 Nov 2000 00:32:30 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Nov 2000 00:32:30 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 18 Nov 2000 00:32:29 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA00600 for ; Sat, 18 Nov 2000 01:32:25 +0100 (MET) Message-ID: <3A15CF43.112BD52A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:37:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 360a262dfbbd3ccb438f15fc1617c519 Status: R X-Status: N hello,

Jeff Davies wrote:
<snip>

i'm ok to say that Java looks more stable and is more constrained
than C(++) and is safer. a good Java native compiler would do a good
job. anyway, vectoring (and then translation to SIMD) is not automatic
yet. F-CPU is a "raw RISC" CPU and might need a lot of support libraries,
so the undertaking is high.

I am now constrained to only answer emails, not do "useful stuffs",
and if i had 100 hours in a day, i'd like to make most of the f-cpu
alone. I have to give up some dreams and concentrate on the core,
so if i'm not happy with what others do, i do it myself when it becomes
annoying. I think that you (jeff) are doing an interesting investigation
and i encourage you to go on. The one who "does" something that works
is the one who is "right", and the facts show that it's you.

i'll look at http://www.merlotxml.org/ ASAP.

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sat Nov 18 01:37:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00393 for ; Sat, 18 Nov 2000 18:01:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:09 +0100 (MET) Received: (qmail 29434 invoked by uid 0); 18 Nov 2000 00:32:50 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx14) with SMTP; 18 Nov 2000 00:32:50 -0000 X-eGroups-Return: sentto-1101623-1515-974507549-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 18 Nov 2000 00:32:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:32:28 -0000 Received: (qmail 1615 invoked from network); 18 Nov 2000 00:32:28 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Nov 2000 00:32:28 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 18 Nov 2000 00:32:27 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA01093 for ; Sat, 18 Nov 2000 01:32:24 +0100 (MET) Message-ID: <3A15CF42.DE36F75E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> <20001117143358.08241@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:37:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 720cb105a7f519bd1c0e21f14ebfa1f9 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Fri, Nov 17, 2000 at 01:12:13AM +0100, Erik Hansen wrote:
> > I was able to synthesise rop2 and iadd, as well as an intermediate Version
> > of inc with both tools and they perfomed quite well.
> Yeah!  Thank you very much.  I think I'll have the next version of the
> IMul EU ready in a few days, too... I already rewrote the 8x8 multipler
> and the wallace trees, but I have problems simulating the whole unit
> (it's too big -- Symphony EDA runs out of memory when I try to load the
> structural architecture).  I wish I had one of those fine Octal-Xeon
> servers with 16 GByte of RAM...

what exactly is the symptom/problem ?
do you think that the port to Linux will help ? (ie memory management)
i guess that the (internal) memory leaks and misuse of malloc() can alter
the performance of this kind of software.

> BTW: does anybody have an idea why this configuration doesn't work?
> Simili still uses the default (most recently compiled) architecture
> for the Mul8x8 and Wallace components :(
<snip>
read the manual. I haven't tried to use configurations yet.
in the doubt, ask Simili's maintainer (email on the distro's manual)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Keyshaun Sat Nov 18 01:32:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00396 for ; Sat, 18 Nov 2000 18:01:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:10 +0100 (MET) Received: (qmail 2373 invoked by uid 0); 18 Nov 2000 00:32:58 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx15) with SMTP; 18 Nov 2000 00:32:58 -0000 X-eGroups-Return: sentto-1101623-1518-974507565-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 18 Nov 2000 00:32:56 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:32:45 -0000 Received: (qmail 93108 invoked from network); 18 Nov 2000 00:32:44 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 18 Nov 2000 00:32:44 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 18 Nov 2000 01:33:50 -0000 Received: (qmail 20504 invoked from network); 18 Nov 2000 00:32:41 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 18 Nov 2000 00:32:41 -0000 X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 17:32:43 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] It's up, but not done Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1096cbab38cdef7d3d32c4567e665927 Status: R X-Status: N Hi, last week I announced a new website when I joined this email list.
Well OpenAll.org is up now.  The purpose of it is to fund an entirely Free
standards based computer.  There is very little at this point, but I just
started working on it, what can I say I have a day job.  The most ironic
thing of all is that it is served from an NT server.  If someone doesn't
see the irony in that then they don't understand Free Software.

Shaun Kruger
eGroups Sponsor
Click Here!
From Yann Guidon Sat Nov 18 01:37:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00399 for ; Sat, 18 Nov 2000 18:01:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:11 +0100 (MET) Received: (qmail 2461 invoked by uid 0); 18 Nov 2000 00:33:02 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx15) with SMTP; 18 Nov 2000 00:33:02 -0000 X-eGroups-Return: sentto-1101623-1519-974507568-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 18 Nov 2000 00:32:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:32:48 -0000 Received: (qmail 5142 invoked from network); 18 Nov 2000 00:32:48 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Nov 2000 00:32:48 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 18 Nov 2000 00:32:47 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA08246 for ; Sat, 18 Nov 2000 01:32:44 +0100 (MET) Message-ID: <3A15CF57.F0B8DC0B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:37:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b2272cb329cabcbb6446cd075590045e Status: R X-Status: N hi,

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> Im a bit late bringing this up, but better late then never...
yup :-)

> I like a shared bus. IMO it would be ideal for a small (4 or less) number of
> processors, if electrically its not too much of a nuisance, and if you want more
> only then you use an extra chip in the form of a bridge for every group of
> processors.
my measurements on a dual CPU system show that a shared bus kills performance.
what's the point of buying additional CPUs if the computation power is not increased,
except for CPU-only computations (that don't need memory access, which is very rare) ?
i tried to address this point with the architecture i proposed last saturday :
when you add a CPU module, you also add bandwidth.

But if you really love shared buses, nothing keeps you from making one
(yet another one ;-D). just remember the troubles with signaling,
turnaround cycles, arbitration, deadlocks, all the bizarre stuffs...

when i try to push what looks a "high-end solution", i still try to keep the
price as low as possible. OTOH if you want the lowest possible price, you end up
doing harmful choices. i am simply trying to keep you from jumping blindly
forever in the endless hole of captive/nonscalable/unbalanced architectures.

> Sure it doesnt scale for small numbers of processors, but whats cheaper...
it's not only about the price, it's also what you get for the price.
if you have the bandwidth of 1 CPU with a 2 CPU system, it's not worth it.

> slightly overengineering the bus and saving a chip (and latency...)
well, there is still the possibility to include a F-cpu in a chip without
direct interface to the outside world, for embedded markets or specific
applications. you can do a SoC with a F-cpu if you want, or decorate your living
room as well. and overengineering is never too much ;-)

> for small scale SMP or making a point to point connection tailored for a single
> processor which necessitates engineering a high bandwith switch for even the
> smallest multiprocessor systems?
it's still too much application dependent. if you want a small core, ok,
as ok as a large scale computer. depending on the required I/O, you'll
include a PCI core or an EV4 bus. i am a performance freak so i prefer
point to point. it makes me think about the lego bricks of my youth :-)

> How much performance-increase/cost-savings does using soldered chips instead of
> DIMM-sockets give you?
there is a not negligible win when soldering the chips : a connector
is harder to route at the PCB level. it also uses much more space/room.
it also costs less to fab for mid/high quantities. i can't quantify it though.

> For cost reasons we would probably have to desolder chips
> from modules anyway :) I think its a bit of a nuisance not being able to
> upgrade, it has to be worth the cost.
well it's a choice to make. it still depends on the budget and the application.

example : f-cpu chip with dual 64-bit SDRAM banks on a small PCB

Case 1: target is the prototyping people, low cost and low volume,
with user-solderable pins. Solution : SDRAM on 2*2 DIMM sockets, 6-layer PCB
and PGA chip on a socket-7 ZIF (315 pins ?). The SDRAM can be bought ready
in a store, the PCB can be sent to a fab then soldered at home, the ZIF socket
can be found more or less easily (it's a standard). finding a 315-pin PGA
package for the chip is less easy, but it's possible (i don't know how,
but it #should# be somehow possible).

Case 2 : end-user board, low cost (still), more volume, can be sold as is,
no need of manual modifications. Solution : BGA socket (more pin density),
almost same PCB, soldered SDRAM chips so we can win in capacitance, surface
and volume (better routing). The higher density of the SDRAM pins
helps make a denser PCB and shorter traces. smaller PCB means cheaper
(in the long run). dual-side soldering of the SDRAM on the PCB
helps to increase the density.

So it depends on the goals and the available means/budget.
we'll certainly start with case 1, but in the present case,
upgradability would mean the possibility to add newer PCBs with more
memory on them (and a CPU that works faster). "old nodes" would
be used to handle I/O or stuffs like that, while the newer would
perform the main tasks... use your imagination :-)

> Marco



Michael Riepe wrote:
> On Fri, Nov 17, 2000 at 11:45:47AM +0100, Yann Guidon wrote:
> [...]
> > The size of this module is rather compact, i have no estimation
> > or number yet but around 10*5 cm or a bit more.
> Don't forget the core voltage regulator(s).
and clocks. i don't know yet where to do this.

> > you could probably put 4 or 8 such modules on a PCI board (the PCI
> > board would have the G-chips) but beware of the power consumption
> > (15W max/board).
> External power supply?
the solution i have seen with the 15*DSP board is a power connector that
comes from the PSU (like a HDD or FDD connector).
But PCI is mainly used for communication with the PC (memory/video stuffs).
When several 15x boards are installed, they are connected together with
special connectors and point to point wires. it looks like a spaghetti
but it's efficient.

> > Remember : a bus, either PCI or else, is not a good idea if you want big
> > clusters. The reason is simple : 1) the real bandwidth (measured) is
> > often lower than the specs let you think 2) the more boards you add,
> > the less speedup you gain. Same for the ring that Nicolas proposed.
> I'd prefer something more fault tolerant anyway, like the cube you
> proposed, or maybe a flat (2-dimensional) hexagonal structure.
the cube is one of the best solutions, but i wonder what you mean exactly by
"(2-dimensional) hexagonal structure" ...

btw, we need to think about the synch/semaphore bus.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Nov 18 01:40:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00402 for ; Sat, 18 Nov 2000 18:01:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:12 +0100 (MET) Received: (qmail 19060 invoked by uid 0); 18 Nov 2000 00:40:16 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx01) with SMTP; 18 Nov 2000 00:40:16 -0000 X-eGroups-Return: sentto-1101623-1520-974508010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 18 Nov 2000 00:40:14 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:40:10 -0000 Received: (qmail 23950 invoked from network); 18 Nov 2000 00:40:08 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 18 Nov 2000 00:40:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta2 with SMTP; 18 Nov 2000 00:40:07 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00740; Sat, 18 Nov 2000 01:40:04 +0100 Message-ID: <20001118014003.31483@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> <20001117143358.08241@thrai.stud.uni-hannover.de> <3A15CF42.DE36F75E@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A15CF42.DE36F75E@f-cpu.org>; from Yann Guidon on Sat, Nov 18, 2000 at 01:37:22AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:40:03 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 441bae330ec163ce786a93e9a7afea66 Status: R X-Status: N On Sat, Nov 18, 2000 at 01:37:22AM +0100, Yann Guidon wrote:

[OOM from vhdle.exe]
> what exactly is the symptom/problem ?

Fine-grained structural VHDL seems to need LOTS of RAM...
The compiler works fine, but simulation is impossible.  If I replace
the bigger components with their behavioral equivalents, it works.

> do you think that the port to Linux will help ? (ie memory management)
> i guess that the (internal) memory leaks and misuse of malloc() can alter
> the performance of this kind of software.

I don't know; I hope so.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sat Nov 18 01:49:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00405 for ; Sat, 18 Nov 2000 18:01:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:13 +0100 (MET) Received: (qmail 10978 invoked by uid 0); 18 Nov 2000 00:49:46 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx10) with SMTP; 18 Nov 2000 00:49:46 -0000 X-eGroups-Return: sentto-1101623-1521-974508577-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 18 Nov 2000 00:49:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:49:37 -0000 Received: (qmail 48344 invoked from network); 18 Nov 2000 00:49:36 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Nov 2000 00:49:36 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta1 with SMTP; 18 Nov 2000 00:49:34 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00765; Sat, 18 Nov 2000 01:49:31 +0100 Message-ID: <20001118014931.58916@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A15CF57.F0B8DC0B@f-cpu.org>; from Yann Guidon on Sat, Nov 18, 2000 at 01:37:43AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:49:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 797c9cd405181d18068ee3249607692d Status: R X-Status: N On Sat, Nov 18, 2000 at 01:37:43AM +0100, Yann Guidon wrote:
[...]
> > > you could probably put 4 or 8 such modules on a PCI board (the PCI
> > > board would have the G-chips) but beware of the power consumption
> > > (15W max/board).
> > External power supply?
> the solution i have seen with the 15*DSP board is a power connector that
> comes from the PSU (like a HDD or FDD connector).

Yep.  Some power-hungry AGP boards do that, too.

[...]
> > I'd prefer something more fault tolerant anyway, like the cube you
> > proposed, or maybe a flat (2-dimensional) hexagonal structure.
> the cube is one of the best solutions, but i wonder what you mean exactly by
> "(2-dimensional) hexagonal structure" ...

This one:

      \     /
       *---*
      /     \     /
   --*       *---*
      \     /     \
       *---*       *--
      /     \     /
   --*       *---*
      \     /     \
       *---*
      /     \

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Sat Nov 18 01:55:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00411 for ; Sat, 18 Nov 2000 18:01:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:15 +0100 (MET) Received: (qmail 30628 invoked by uid 0); 18 Nov 2000 00:51:39 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx18) with SMTP; 18 Nov 2000 00:51:39 -0000 X-eGroups-Return: sentto-1101623-1522-974508653-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 18 Nov 2000 00:51:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:50:53 -0000 Received: (qmail 47938 invoked from network); 18 Nov 2000 00:50:52 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 18 Nov 2000 00:50:52 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 18 Nov 2000 01:51:58 -0000 Received: from f-cpu.org (nas1-184.ras.club-internet.fr [195.36.192.184]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10861 for ; Sat, 18 Nov 2000 01:50:50 +0100 (MET) Message-ID: <3A15D394.BA353DC3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> <20001117143358.08241@thrai.stud.uni-hannover.de> <3A15CF42.DE36F75E@f-cpu.org> <20001118014003.31483@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:55:48 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 949a23837b2cb95d19d41f78910367df Status: R X-Status: N hi,

Michael Riepe wrote:
> On Sat, Nov 18, 2000 at 01:37:22AM +0100, Yann Guidon wrote:
> [OOM from vhdle.exe]
> > what exactly is the symptom/problem ?
> Fine-grained structural VHDL seems to need LOTS of RAM...
> The compiler works fine, but simulation is impossible.  If I replace
> the bigger components with their behavioral equivalents, it works.
hum, have we reached a limit here ?
now, my daywork takes a whole new revelance :-)
i have estimated that a FC0 will take half of a low-end machine's ressources
(around 10 boards). a entry-level machine can contain 24 boards, work up to
6MHz. highest config can contain 192 boards and speed is much reduced,
but the speedup is considerable compared to a SW solution. there are other
very nice features too.
It will be possible to simulate the booting of a single board (as described
on other mails) with the machine on which i work.

> > do you think that the port to Linux will help ? (ie memory management)
> > i guess that the (internal) memory leaks and misuse of malloc() can alter
> > the performance of this kind of software.
> I don't know; I hope so.
ain't unix nice, sometimes ? :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sat Nov 18 01:56:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00414 for ; Sat, 18 Nov 2000 18:01:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:16 +0100 (MET) Received: (qmail 9483 invoked by uid 0); 18 Nov 2000 00:56:31 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx03) with SMTP; 18 Nov 2000 00:56:31 -0000 X-eGroups-Return: sentto-1101623-1523-974508982-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 18 Nov 2000 00:56:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:56:21 -0000 Received: (qmail 75709 invoked from network); 18 Nov 2000 00:56:21 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 18 Nov 2000 00:56:21 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta1 with SMTP; 18 Nov 2000 00:56:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00807; Sat, 18 Nov 2000 01:56:17 +0100 Message-ID: <20001118015617.23264@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <002101c0502b$100a4c20$7bcffea9@schlappi> <20001117143358.08241@thrai.stud.uni-hannover.de> <3A15CF42.DE36F75E@f-cpu.org> <20001118014003.31483@thrai.stud.uni-hannover.de> <3A15D394.BA353DC3@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A15D394.BA353DC3@f-cpu.org>; from Yann Guidon on Sat, Nov 18, 2000 at 01:55:48AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 01:56:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] ROP2 compiled with Leonardo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: afe62ef8a41a74abd296a125c596285a Status: R X-Status: N On Sat, Nov 18, 2000 at 01:55:48AM +0100, Yann Guidon wrote:

> > Fine-grained structural VHDL seems to need LOTS of RAM...
> > The compiler works fine, but simulation is impossible.  If I replace
> > the bigger components with their behavioral equivalents, it works.
> hum, have we reached a limit here ?

No, I just need more RAM ;)

[...]
> > > do you think that the port to Linux will help ? (ie memory management)
> > > i guess that the (internal) memory leaks and misuse of malloc() can alter
> > > the performance of this kind of software.
> > I don't know; I hope so.
> ain't unix nice, sometimes ? :-)

That's why I use it...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Ben Franchuk Fri Nov 17 16:13:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00417 for ; Sat, 18 Nov 2000 18:01:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:17 +0100 (MET) Received: (qmail 5357 invoked by uid 0); 18 Nov 2000 00:58:00 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx09) with SMTP; 18 Nov 2000 00:58:00 -0000 X-eGroups-Return: sentto-1101623-1524-974509057-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 18 Nov 2000 00:57:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 00:57:37 -0000 Received: (qmail 78657 invoked from network); 18 Nov 2000 00:57:36 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 18 Nov 2000 00:57:36 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 18 Nov 2000 01:58:40 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA04347 for ; Fri, 17 Nov 2000 17:49:11 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A154B2F.6D4B6FA4@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> <3A14FD0C.6A95352B@jetnet.ab.ca> <20001118002748.18989@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 15:13:51 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0905129e0398f620d5f4fae12136ce60 Status: R X-Status: N Michael Riepe wrote:
>
> On Fri, Nov 17, 2000 at 09:40:28AM +0000, Ben Franchuk wrote:
>
> > Are interrupts needed anyhow? The G-chip could most likely poll a fast as you
> > need.
>
> You're kidding, aren't you?  Of course we need interrupts!  Unless you
> can offer something better, of course ;)

Umm Message passing?
The problem is the interrupt system still is kind of a catch all
for problems. You have error/danger signals , regular buffered service
calls,unbuffered service calls,software traps(floating point with no floating
point hardware),OS calls and timer ticks. All this stuff interrupts the
processor
and then requires task rescheduling and lots of flushing of buffers and cache.
We have streamlined the processor and memory but I/O and interrupts need to
be streamlined with hardware for bit fiddling.
Ben.

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Ben Franchuk Fri Nov 17 16:47:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00423 for ; Sat, 18 Nov 2000 18:01:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:19 +0100 (MET) Received: (qmail 9812 invoked by uid 0); 18 Nov 2000 01:31:00 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 18 Nov 2000 01:31:00 -0000 X-eGroups-Return: sentto-1101623-1525-974511050-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 18 Nov 2000 01:30:57 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 01:30:50 -0000 Received: (qmail 46768 invoked from network); 18 Nov 2000 01:30:49 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 18 Nov 2000 01:30:49 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 18 Nov 2000 02:31:55 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA05975 for ; Fri, 17 Nov 2000 18:22:28 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A1552FD.EAF955AE@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 15:47:09 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 47ac3a5ece805be2b24719184449e228 Status: R X-Status: N Michael Riepe wrote:
> > > I'd prefer something more fault tolerant anyway, like the cube you
> > > proposed, or maybe a flat (2-dimensional) hexagonal structure.
> > the cube is one of the best solutions, but i wonder what you mean exactly by
> > "(2-dimensional) hexagonal structure" ...
>
> This one:
>
>       \     /
>        *---*
>       /     \     /
>    --*       *---*
>       \     /     \
>        *---*       *--
>       /     \     /
>    --*       *---*
>       \     /     \
>        *---*
>       /     \

This is a nice mapping for a network of computers.
Ben.
PS.Now you just have to watch for little "war" figurines and
D&D characters on your grid. :)

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Sat Nov 18 02:39:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00426 for ; Sat, 18 Nov 2000 18:01:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:20 +0100 (MET) Received: (qmail 23004 invoked by uid 0); 18 Nov 2000 01:34:51 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx14) with SMTP; 18 Nov 2000 01:34:51 -0000 X-eGroups-Return: sentto-1101623-1526-974511286-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jj.egroups.com with NNFMP; 18 Nov 2000 01:34:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 01:34:45 -0000 Received: (qmail 67391 invoked from network); 18 Nov 2000 01:34:45 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 18 Nov 2000 01:34:45 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 18 Nov 2000 01:34:44 -0000 Received: from f-cpu.org (nas4-74.ras.club-internet.fr [195.36.203.74]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA06484 for ; Sat, 18 Nov 2000 02:34:36 +0100 (MET) Message-ID: <3A15DDD6.110ED63D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 02:39:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] my first experience with Merlot Content-Type: multipart/mixed; boundary="------------8BB211D80A29D710A058DD0A" X-UIDL: 3dbb973a03d91ae7b24695ce5f4d528c Status: R X-Status: N --------------8BB211D80A29D710A058DD0A Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit is Merlot a merge of "merlin" and "camelot" ?
ok, i'm new to XML but in french, "camelotte"
means "useless, worthless stuff" (approximately).
what strikes me is the number of programming
bugs, see the GIF to see what i mean. Is it
my Java version that is buggy otherwise ?

i'm waiting for Jeff's magic files, so i can play
with "his version of GNL" :-)

soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------8BB211D80A29D710A058DD0A Content-Type: image/gif; name="merlot1.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="merlot1.gif" R0lGODlhcgN2AvcAAAAAAAUFBQ0NDRISEj4+Ph4qZDQ2VDc8VCItZCIubCYybCo1bCs2dC46 dDI7dDM+fDxDVD9GXDZCfDpCfGJiAHxkJEpKSkNKXUZOZEpOZEtSZFBWbFVbclpedF1ie2Ji Ym5ubmBmfHp6egAAgDtFhD5KhEJLhENMjEZSjEpSjEtUk05alE5anFFajFJalFNcnFZepFtk lF5mnFZio1tjo15mrF5qrGVqhGluhmNsnG5yjHF2jHFylGJqpGNrrGZutGx0o3Z9pHF5rHh+ rDLNMnqCrH+FtJN6AJ52BIJwJIZ4JI52NJJ6NJJ+PKJ6BKJ+BKAi8P8A/46CJJKKJJaOLJaC PJyMPJuTLJ+WNKaCBKqGBKqKBK6OBK+SAK+SBLKWBLScBKGVPKOaNKOaPLKRLLaYMrqeNLqk BL6qBLqqHL2qJbqiNJKKfJKOe5aOfJWSe5aWfJqSepqWfJ6WfJ2afKagVNySAMCuBMKyBMCp NMa6KMKyNMi2NM6+NP+qAMO4SP+Pa9zcAP//ANHJa//Ga4CAgIaGhoyMjJeShJqWhJ6WhJyW jJ2ahJ6ajJGRkZycnIOKtImPtpKWtJGWvJWavZifvKKahaGeg6aehKKejKeihKaijKunhKqi jaqmjK6qjKqmlK2qlbOujLKulLOunbaynbiylLu2lLm2nL66lL64nKOjo6mpqbm2pL66p7a2 tpyhxKGmxKKmzKWqxKitzK6yzLO3zLK21Lq91I7//77C1LH//8O+osG+rv+xscLCq8fCqcvH qsXCtcnGts3KtM3KvN7OpNbOtNDOu9bWrN7SpNXSvNrWtN3ZvOPYpOXeouripMDAwM7NxM7O zsPF3MjL3NLSxdbSxdfWzNnWxN3azdra2t/f387O5NLU5Nnb5Nrd7OTexODezODe1OjkyePi 1OLi3Orm1Ojm3urq3PDs2v/w1Pv23P763Obm5uPk7Ovq5e7u5uzt9PLu6Pf25PPy6/b27P// 4f767PLy8vLy9Pb29fr69Pr6+vr6/P7+/iwAAAAAcgN2AgAI/gC5CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTUgTA7Z/LlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarPQiz/RdvKtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt6/fv4ADC1aLteXgw4gTK17MuLHjx5AjS55MubLluoW1RhvBubPn z6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9+emvmrZyJAFgeBQCU 5s0BEJlOhLj169iza9/Ovbv37+DD/osfT748aONZkY9wHt05lOXPly83T7++/fv48+vfz7+/ f9w7ARAgZwOOgJ5hm60HxXsLyuceewD8J+GEFFZo4YUYZqghd/80hFWHDGFFoIcRGhjNcQk6 yGB78L3XmUuewWiajBvWaOONOOao4448ltZhWR9yE42DRKI3IpAlHqgZZxC2CB+LL/4To5Qz UgkajT1mqeWWXHbp5Zer/UhWkEMSKZ+RI4i5XFdrnpikmwgy2WB88jUoX5RUvnQallOC6eef gAYq6KD1iTkWmQCAlaibR27VZpuMmogik3WuqGJzeBJII0yaSikjp2nySeiopJZq6qmoXink mAIKuahX/ouKmOaqjp7JlaxKqmfmg/E1iGdMmgb7qad5Epvqscgmq+yyGxoqFqKKoulsmV7h CueS6z1JpJ3zdQpsqJwOG6qwVjJr7rnopqsucdOCBe1XsZborINdWTtptrwyaGaU44rbZ7/F jrvuwAQXbPDBorX71buwSkvro6/am16KZjJoaYkACyzuxgGLivDHIIcscqBqFnlrq0NGG2nJ bMbLWa4U1wldpd0KHKy3Nw+7abkj9+zzz0BjWDK9J/+4a5uyKlztm/du+562dwYt9dRUV72l 0vWizGqjhzI9MaXbNsctxlaXbfbZaOv3TyFst+222wK+LXfb8s49t9dx4qvi/tNEpu3334AH ft3RhBfet96G441t4XTWLPjjkEcuOX8wT2755Zhnjh/Ml3Xu+eeghy766KSXbvrpqOOFYuqs t+7667DHLvvstNdu1+q256777rz37vvvwAePe/DEF2/88cgnr/zyXSPI/PPQRy/99NRXH9jw 1mev/fbcd++979h/L/745Jdv/vmAhV+rrYu+ypaZ8Doqf1nu158y/XiZfP9Z7svVf/9sQp8A B0jAAjZGffuLn1sA2LAA4k9+r2JgWCQIF/slcDD/EwsFDcjBDnrwg2hBIADbxxVb8W+CiSKh CTVYwvuRMGWQolYEH9XC+T1wfi/c35pemML6xfCG/jY0oQo3CMIiGvGI5ROhAnNIRAc2kIYX ZCEMcVgrKlJLh1i0IVksyEQc8pCHNTRLBrPYvhwi8YxoTGP2RChEK0ZRgyaLoBu3iEUwurGL U0whWvSHRzm6sIZNVBT8yBhENRrykIhEnhKfuL4fjoWBfjTjI+t4x0ISUo+B1CIgN2lFP5Yp k5osI/ssmchSmvKUslukAyV5QgX+8Y3RkqMdX0lLFU6xlYysZC1dCURachKWqAymMIdZGVVy 0pO9tCQrpRjGPv7Sk6B8ozOvOE1g8nKXLlwmMbfJzW4Oxph3dOQj+TjKK/Yyks0UYgyRmUwd qvOV0BQnM4MIqSF68574/sznXhCYyGjyxZ/6DKhAB5o155mSaI4BKEEXylBu8rOhEI2oRCe6 lodS9KIYzShELarRjnr0o8PkKEhHStKSGhFFdkupSlfK0pa69KUwjalMZ0rTmtr0pjjNqU53 ytOe+vSnQA2qUIdK1KIa9ahITSpSNYNSqzj1qVCNqlSnStWqWvWqWM2qVrfK1a4GpRBMnZgh xkrWspr1rGhNq1rXyta2uvWtcI2rXOdK17ra9a54zate98rXvvr1r4ANrGAHS9jCGvawiE2s YtsaVgQZwquQjaxkJ0vZylr2spjNrGY3a5THwsyzebGJSUdL2tLSDrQoAi1eQHQQ07r2tbAV /h1qxaqZ1dIqtrjNrW4lM1vH1vYuWNutcIdL3Lz0VjOqBe5ti8vc5jrXLcfdSnLtEtznWve6 141uNKbLlVd84AN2+K54xfuKsijtFYQDQXnT4ohDHMIR8I2vfOXrXkfIRQT4HQt+RcCKs7wC BAAOcIDXC5dHGPgRcjvwI7DL4AYnRrvc3coHAGAHQthhVx8gcFja9Yr/AiAXvtiFiAmwDRAQ QL1pce8hXKriuIjAAssRQVhEIB/+mgUE6dUwWx4R30KwghXwXcUqChHfBbPFSnlqGCaVOUtt OvjJGYXwb7sCXkIIwsIingYApkHjDI9lWq8wBIAB8ApfTMMd+SDA/j9KDAAUn6W+PJ6vnHns XhdvOcZfobGAAGDjsuAYxCLeBYlN7OYdO6Jtq1DwgdvmCCOrBckEUvIt0alLhUL50vqUcljs 4IdACCIQfrCDO7T8Dy4DwMsbvm2YcbwcQI/YJdtoc4ffTOQ4y1m+PC7EIR69XBq/4h945oqe S83n/vqZzL7YRj7+oWY2F1otuT40K2zd40M3+sgvinQAl/xJKGLT0pgOdzc1/RVOByIQ/zh3 qEld6i7rmCvO8vAg1oHsM+dDwG0G8LvBsuJG33q+ud51WqZF40e4A9h83sqwp4HePpPlzyHe xX8FLOB9jyXah57be2u9lkdAOk2S1mMU/intS3GbvKHk7oqVBSEIl7Cc5YQQkEu0jOqvxBvH 6xjEhyMeaBE7CARm6Te1/x1wXntFz9E4eIwXjt5i3xjZymb1rp5dFoy3V8VYt7ajz/KIQ3x8 ynYkeTVPTnaCprwr5va0uu2gZSLV3Cs3B8A6/lBvNL8kHwAYRBfaHPRa/1u+qzi0wNHSLqQr XT6lbrrDH75zEUM80IM+scXBYvUV2+3aaOl6IcCVJy7SE5olrCe4y056Q54d7Z3+dKhnPo3W 09zicZ87AHYBiJ4HOu97B3pZhP73+AZe10bP85oOTuPEx9jYYHEWjssc9bqnec04prpYKl8I IVv/EIF/79Yv/r7iR4im9ODX7em5UuUr28H2t397V5zlCJzTPRpHiL/85a93vu/e7733N/AH vlxhDz8f+KV4yJd8t/V4u2CAggZrssZ11gZf3Wd9rHAIrPB79lV13ccK3xd+Gvha4ydhAOAH guAH7nBwLzGC7nBqsFeAyzF/69CCLtiCR1B/ukcW/dZoiqZgiQZf+0d4/ed/KYRwTvdlKsh8 9+Z8+CZ9YUF91idkEjiBRNZ3jxCBGbiBVDhaHRgNEwaCfoB+6ZeCbPKCc/cHYjiGYngEXXAE 9keDRJZ/8rWDZxFcesYKo9ZmPzaANqeCroaAPbeAZkF9jwCBbViBZHFohtB1U1iF/ogIUleY hSG4DSRYgieofvB2WwCgBmR4iWR4hmg4g2NRg1iXdfPlhmahMPvFZ3rWeqa4eHA3hMlWhGVm b3fHh1XXgO1VfUu4hE84i4UwVoeYiL4YZY2FXFNGfhSGZVy4CyiYamxyBJjYjH8Qf2nYiUTW hLfIhNoneMHXFXrmINvIjXY4iV1hgHp4e0hIebT4gEJWhz+Wi7poCL34i/AoUYtIZmzniI/o EpHohVyBY5bojGQIjZwoFv0mgVc3gdd3jaJoXr22HD/2CMWmZ1HICsdHgOFIJMtnZnbnEnhX jl+hhNUoZOyoi2EhHPFYkh80j7vAc1yYjBTJFY4AAMzo/o9jeIbRKJDTmH0SuIRwho381xUS CQCssA3REGsyxgo0JpTb8JPfGA03R3GNh36ySBZ+CIHqGJKzOJLBYZJaaUDz+IrTYI8j+BIs eYdd4WFdcJZomZZpSQE1GRYDiZMGaY36N3hveFs/qRX/gHcyFg00FpRMyZAt2V0d1mEXCYsa GZUXd462+JFWWXVYCRxbGZkChJIqCZWSuBXx9pKJ83N9115wqZMISZejaJcMmZeAGQ1KaZpA GZhgMY4+x5FeYXWH9ofpWJWCCBckKZm6ST5daWZfuQ3AaYL5qIxlSXHGaZyT1xUr5l6JZmC3 uJMJSRYERyQD+JM1RpxhIXVH/gObXZFrb/ORIHmbb5Gbu1me3TOPm3mZTNl/g9me7umeXGd5 LyWaCil8p+mT14mdYDFxx6lvyRmboahS4ukW5GmeBmo9V+hd47Wg4zV51UUXXfeJEvqJAyqd PViHYYGhYlFd7/me0KZg+bd9bUE2CaMaPPMZB5qi1XOFcvGgn+OiawGjpUOioXGir6GiOBo9 LBoXMnoZPcqDriNLAhIjNpMn2SYsBJKkWJKjTLo8OwoXP1oZUTqaQQpIn/EpSZomRxowWqox 2takYFo8T/oWUzoZZWqhVYpDV7qlWdqlX9emSRamcgo8Y+oWZxoZd7qhPTijVkqkWWqkf8qm XTqo/nNaqL1Tp22xNnYzOorqNnPRqHJDOpG0poE6qIDqpnDaGYa6qbmDqO9DOKOzK3NROJL6 S1UET8fUZJrEqazqOhC2WLAaq7I6q912qhAUT6KHqjY0q7zaq776q8AarMI6rMRarLAajJjJ Wcq6rMOoMmsRSMwardI6rdRardbqVTBzrdq6VWKUFgglndsaruI6ruRaruGareaarlPBGOra ru76rvAar1KBrvJar0LBrvaar/q6r/zqrvTarwA7E/gasARbsAZ7sF31r+a6mQzbsA77sA4y VQOLsBRbsRZ7sUyhsOV6DxzbsR77sSAbsiI7siRbsiYrc1HVqxi7sizb/rIuK1rXkqzqarI0 W7M2e7Mii7Ivu7M827M+O60aS644O7REW7Qeq7M/m7RKu7RMe1VBO65GG7VSe7JNW7VWe7VY uxRPK65T27Ve27FIm7ViO7ZkW7bIypTt6rUAMLJrew9tO7TywbFvy7ZmW7d2e7c/u7Xh+rVs G7Vz67ZUi7eCO7iEa7B6u61vu7bLEbJxC7hy67huu7iRq7iPK7lyS7lgu7htm7iWC7aF+7mg G7rverja6riS+7eJW7mPC7mbu7qn67qo67qrC7lyK7q2e7u4S62ke62mC7Yfm7qA27q0K7us O7ux27vFe7S5u7zM27yTtbvW+rqze7mNm7yT/uu7yJu9xyu8RPK7zvu94Bu+UgW91aq9vwuy mPu3yCu85nu0xKu+niu+8ju/9KsU5DsVcwu8kUu87Yu90ju8wJu+xvu+/nu557u+2Bu/9bvA DNzAOXG/UoG6nau4+Wu5+pu5/Zu57Iu512vAG4zB22u8nVu7DlzCJlzCEBwV8HvAfNvCRbvC Nxu2JzzDNNy8KQwVMJzALrzDJesgXSvDNRzEQvy5N/wUOczDSJzEOTvETNzEhFvETnHESjzF SgzETnzFWNy0UNwUUkzFXuzCVpzFYjzGL7vFTNHFX5zGP0zGbNzGZRyzaHtVaKzGdPzCbnzH eEyxZrwUENvHfvzH/oDcx3k8yITMr3tcyIicyIpMFYe8yI78yJA8FI0cyZRcyZYsE5N8yZq8 yYucyZz8yaDsxp4cyqRcyk08yqacyqqMwnC8yq78yneMyrA8y7R8u7Jcy7icy3h7y7rcy76M tbz8y8I8zD4bzMR8zMh8scaczMzczAC7zM4czdIMr9A8zdZ8zeJazdi8zdwcrdrczeAczpb1 zeJczubMra18zuq8zuNKzuz8zvAcFe4cz/Rcz0cxz/acz/rcE/i8z/78zwKbzgA90ARdFf1c 0Ahdzwed0AzNzgvd0BBdzg8d0RTNzRNd0Rg9zRed0RzNzBvd0SA9zB8d0iStyyNd0ig9/ssn ndIsrcor3dIwHcovHdM0rckzXdM4Hck3ndM8rcg73dNAPcg/HdRE3cZDXdRIncVHndRMzcRL 3dRQTcNPHdVU7cBTXdVYTb9XndVcDb5b3dVgvbxfHdZkLbpjXdZo/cQCndZsbcln3dZwTbZv Hdd0fbVzXdd4vbR3ndd83bN73deA3bJ/HdiEbbGDXdiIbbhrndiMLdWL3diQbdWPHdmUrdWT XdmY7dWXndmcLdab3dmgbdafHdqkrdYoUtqobbuHndqsrayr3dqwjVmvHdu0/byjXdu4nbSz ndu8nVW73dvATVW/HdzE/VTDXdzIva63ndzMHbDH3dzQbb/L/h3d1C2vz13d2B0U153d3M0T 293d4H0T3x3e5I3J013e6C2t453e5b3e7B3e7v3e3R3f8p3d9F3f1X3f+B3d+r3fzd3f/p3c AB7gxT3gBB7cBn7gvZ3gCp7bDN7gtf3gEB7bEj7hrV3hFp7aGJ7hpb3hHB7aHv7hnR3iIp7Z JF7ilX3iKB7ZKr7ijd3iLp7YMB7jhT3jNB7YNn7jfZ3jOp7XPN7jdf3jQB7XQj7kbV3kRp7W SJ7kZb3kTM6slLhCuPIhKn3eTy7ED1NGJ/MyVA7LTn7lnLUq6+QyBtLlr/zlYK5Ze5o1XB7G pIzmaY5Za77lZe7mMm3lcX7CLpUk/mbuynCe55XVsG1Oy38O6JO1Gm5C6Hhu6A2M6H2+yoXO 6JBVUXYOypEu6QlLGJX+yZeO6eicFo/u0ovu6fNL6Yp+2qTu1Jp+6hOT6kxsJgEgHwEgAAuz 6Zzc6a5uVQGw67y+HAMQ6wAU6qmM67lOVWYiAMuB7LS+NKyOIMV+xf3gEvoQ67Xe7Jrx7Fi8 D8A2ANVe5aiO7Uwc7f7gSMJuysQO7lXlD9H+D9TO7N7e6uguxP7wD9oOAAHQ7V4+6vEuv+Ru 65t87vteVf1u7TIb8EE88O/u7AYvxAif79++8DTc8Geu7xDfvBLv5xRf8ct78ZCe8RqPuxwv 6g//8Q4c/vLD7vEkL7omb+4on/Kgu/KlDPAuj7/B7u823fIzD984n/PzvfM8b98+//P5HfRC z99EX/T/ffRIL+BKv/QF3vROj+BQH/ULPvVU7+BWf/URnvVaT+Fc3/UX/vVgr+FiP/YdXvZm D+Jon/YjvvZsb+Ju//YpHvdyz+J0X/cvfvd4L+N6v/c13vd+j+OAH/g7PviE7+OGf/hBnviK T+SM3/hH/viQr+SSP/lNXvmWH9Yyn/kejfmcz9Wb//nHHPqiL9KeX/pUTfqo78uqv/omffqu z9StH/u1PPu0n/DXfvu8bfu6j/Ej3/uwzfvAf/K/P/xkX/zGf/bIn/xqv/zM/t/2zv/8cB/9 0j/31F/9dn/92J/32r/9fN/93v/34B/+gj/+5F/45n/+iJ/+6r/47N/+jv/+8B/58j//lF// 9n/5+J//mg/7/A8Q/wQOJFjQ4EGECRUuZNjQ4UOIESVOpFjR4sWF0aIVAsDtn0aMIUWOJFnS 5EmUKVWuZNnS5UuYMWXOpFnT5k2LGjl6BInT50+gQYUOJVrU6FGkSZUuxamz48doTKVOpVrV 6lWsWbVu5RrUKc+oXcWOJVvW7Fm0adWS/Qp17Vu4ceXOpVvX7ta2Pe/u5dvX71/AgevmDSvY 8GHEiRUvZkyScGPIkSVPplw57WPLmTVv5tzZc0rM/p9FjyZd2rTk0KdVr2bd2rXY1K9lz6Zd 2/bL2Ld17+bd27fA3L+FDydePHNw48mVL2c+eONTvc2lT6dePSty69m1b+ceE3t38OHFj3/4 nfx59Om3m1ff3v174ezhz6dff7V8+/n176eMn/9/AAP0yz8BCzTwwLMIRHBBBhuUSkEHI5Rw wpsgpPBCDDM0yUINO/Tww4Y4BHFEEj8UsUQUU4zwRBVbdDFAFl+Uccb5YqTxRhzHszFHHnus bkcfgxSyOCCHNPLI24pEckkm73sOrCajlJI4Jae08krUnnQLSy67dHKnLb0Uc8zOqiTzTDTX MjNNNtvsak0345RzKjjn/rTzTqLqxHNPPmvSs09AA13pT0ELNTQkQg9VdNHytIyOUUgjxc3R wiS19NKTEsV000I15fRTPj0FddQ5RSX1VDZNRXXVMVVl9VUsXYV11ihlpfXWI23FdVcfdeX1 1xt9BXZYF4Ul9tgSjUV2WQ+VZfbZC52FdloHpaX22gOtxXZbALXl9tv8vAV3XPjEJffc9MxF d13x1GX33fUohXfeYuWl995k7cV332b15fffaP0FeOBqBSb44GwNRnjhbhVm+OFwHYZ44nIl pvjidC3GeON2Neb443jBfBRkkrtzt2SUGTs5ZZYPW7llmP96OWaa75q5ZpzlujlnntXauWeg /sv6OWiiuRq6aKSvOjppph/0uGmoLVs6aqrzfLpqrBebOmuubdq6a7C9uzpssvf6umy0UTo7 bbZHWrttuHMaO2662Zq7brzxujtvvq16u2/AC/o7cMIHJxxwww/nO3HF8Wa8cbofhxxuySdn u3LL0cY8c7I35xxszz/nOnTRsSa9dKpPRx1q1VdnunXXkYY9dqJnpx1o22/nOXfdcea9d5p/ Bx5m4YdnuXjjUUY+eZKXZ/5j55/fOHrpL6a++omvx/5h7bdfuHvvDwY//IHHJ/9f88/fN331 72W//Xnfh/9d+edft377z8U//3H35/9b//1vWwEU4LUIWMAC+cMf/gfBxz/8gY8HRhCCE5Rg Bf/RQIE0cIELNNreEOi6A36QWSEUIbJIWEJinRCFwFLhCrMiDk2oYhjBiEdBypGOdJCohS6s CjpoiEF+1CMe+xAIM4jhD23w4iE5REw76LJDHjKlHtk4xjgOIo5/oEMdGMyGFRlSDyX2xYn/ GGNByqgmD0ZROzUUSDrOgQ5gCMQcBblGKYrhCiIKxB+kYEg2gGGKBUFRjURBhjaywQ+BHEMg yxAIMi5hik98ohWhSMUohIENe3ACHgjZRz3GwQlLdKIe/EDHYs6IFkEOEimnmIcb/+EKUTCj Gc1IxTDSEQ5yNOMUmphDLxCCD02MwhJu/ggFKDwBDG2wUYx2SaUqjTIPYmjjH+lgBjnYwY52 iGKO5WBGO9TBjnB8wpejGMgmyxHKRLThEp6wBDCAgYpyKOaUQkujM8WDDnK0Q5+mkGYRk5EM dbSjGZYQBiauQYpgKPEYccDEG94whzl84hSo8OJb5nmQi16mnvYMDzmOwYxUMIMgyICkKHjh CkzwYhScmIMmpPGPa7ShEW1AxBtSiglk7CWjc2kmR5Gyj30gUiDwyMYnOmEKTMzBoXPghCc0 gYl4mgMObWjDGxQxClKU0i87JaPPNurT8fADFZ+wxCfo0AlM0IEODg3mHBTRCyIOoxRweAND 49hEjCboq2AN/s8xLBEHTmDCqJ7ARBwuwQY3xOENbrgrPNChjV+gAhOYSJjIKsVX+4iUGKYY RRssMQdLXOISdGBEHDphCVFkIxR8/Ec2CFKOTwSGq161LGb3wwxRmEIVdJCDJTzBCEyE0hKK wAQ6FliPOcDDHq4lCHPl+Zae2pYo+qjHMCzRhjmslRFwuEQikJFHgZTDE9o4x1YXMluzRFe6 ROHFKXoRh0SMYhPbfUMxDKINTQxjIfFMDHqxot71FsUViaDrdkOxSYMUYxMJ8aQr8KrR2gaY P8V4QyY24dB+GmQfcqhoQcwBWsD4FzZ7lbB25jGMtdLhFwbhhWOzIVllEmQUcdAE/jBcAU+1 nFLEeo1wifdzCUb0ApFCFUhRn+qKTVhiHzE2h2E7Udc4WEK/htkxnUjs4+yg4hJzdCAw5iEQ foTiEpZgRCkwMQpUINiBbujEJ0xxCTnMARP2pUuV33RlLFfHH/UgyDA+4YpxoCOwclAxL+SQ CmDUMB7BKAUjNKGJUqCVEaoIhTDsUkY7VwXAeTZKPQhNWjlwAs6oQAc2PBEMYhB1H6N4Ax02 AWlMeMIUnACvezbN6aJogxSYUIQpNiGHTUw5FKYgxicWWAzFfmIYw1CFK46hj7VUOdNLuTWu iYLETYz1E7wQ6jzkEIzY/sMco71EKQ4zbaf12NoAcmoq/oRMkF+MAhQDEccl4KCJUDBRp3Gp 9rqH4gnjGkQfiaDsQPQRj3rMg4NyETG6kdJvfwdF3wYZxhv4LCCIR1wkZCBDGTxuhjXkYQ97 4IMe+nBylKdc5Svvgx7SYHKWx1zmM6d5zW1+c5znnOV60AMfRp6HNZjB42Xg+FEyrnGMIAEJ TnBCFrTABS58AQxnOAMa0IAHrGdd61vnete9/nWwh13sYyd72c3+dTTcgepg+IIXuKCFLDBd 6UbHM9Jno3QnPMHpXPCC1Klu9Tt0PfBev0PhB392xCde8YtnPNYDb/W1t/3tcXfC3I1ydLtX BO96f3rfp171wB9+8aJvfOlN/n/6shceDZF3+xay8ITKO4Hu6s68dCpwe9wnQQm7l0LvpTAF 4Adf+MMXPhWGb3wqJF/5y2d+851/BehHX/rTp371rX99LFw/+ljAghi8/33wh1/84h9D+ccQ BvSHwQpVYH8TmMCEJSxh9tC5bO2ZUwD8I0ABCOA/AhJQAAUIwAQYQAIMQAM0QAZIwARcAAVs gAZggAd0QAl0QAeowAdwgAd4AAnYQA4kAQ/8QBAMwRIYQRIsgRM4QRQ8QRRYQRRQgRZ0QRhU ARmcQRpkARu0wRfIQR18gRnoQR2EgR4MwiCkASIswhqwASRMQiT0ASZsQid0wh+IwvmDEvub Dvy7/sIC6L//y8L+0z8FSIAvBMMDDMAFWAAFUMAElMA0lMAHYMMMlIAMfEMO3MAJ8EAJAMES NEETPME9TEEUSEEXbMEXpMEafAEWUIEd3EEYWMQfnAEamIFFLEIirIFJrIEjtAEasMQaeEJO fMIfYMJP/IEpDJMqvD8svMIu9L8B3D/9E0MDNEMGDEAGUAAGLMM1nMA2jEMMtMA5nMM6rMMQ FME97MMURMEVPAEXnIFJwAVcoAFCVIFDlEFDZIFETEQYeAEauMYidERJtMRMNEIb6AEfyERP 7MRQDEUfGMWRKUXjwEIEyEL8S4B37MIB9MIvHENaZAAG1Mc1XIAJpMAG/rhAgcxADITDDPzA O7zDYBzBEyCBE2DIhyxGFTzBQIyEb3gHIiqCZ5RBG0REaqRGa+RBbJwBbJREkzRCSvxGJhRH G+DET/QBdARFKby8umPH08i/d/w//ysAAiRAL5RHV8RHfdxHW4xAgLxAC8TAOITDXiQBFPjF DywBhxSCPOxDE5BIijzBSJAHIKABIACCjexIRFyBF3CBajzLHqSBkjRJSkxJG6DEcVzCcoTJ l5TJJlTH+rNJ4jjFeexLLeQ/fAzKWTxDW4RAw4TABnCAgAxIpbTAOHQBSIiFWvAGb6CFXwRG p8QFWiABE3RIiLxKrGzBF9AHaojBjYTGaKRG/hfAwbPERh18xJOMzbhUyU5swih8ydsURZqk Pb0kjneER+CkR6CUR//zvwPUx3w8w6H0R8RETAfMxV2MwxKABVsoghhIAXn4h2qYAMzMzH8A Aqn0zBM0AWI0RhSkhH+YBEE8zRlkARqQgRVgAbNsTZKMzdjURB/wxiYUR3F0SSh0QrzsTeVw xyyUR54kTgTFR3wsw3xcwAZgQAdkAMVcTKWMQxKwhUgogQm4Q2jzBhJQyAkwAV34B3loyBHk zM8ETaz0hn/ogRccxI00gm8wAh2czx88y0fkxm48yXHcxLesTds8x9sMUAFtx/w7xS1MUFYE yjGExVoszOZEzAoM/kikrEAHqIRKYEoJcIFu+Id3uEPuJIFZ+DJdONHyVFE/7AFq9Ad5kEEY fcZDZFEaWIEVsNFqJEkerM+1vM9NJEdy9IH+BFJOJNIi3Uu+TEWe1MIDNE4EJMwFrEV9VEOA ZMylhIcT0FIhmAUHwswheIcRhQTORNESkAFIMIIWOIGrpAFIeIETgAV5mIUi0M4VjEEfiIRJ 8AEafAF/eIcchMbWfAEgzEG1JMK0tM9M7AEaAFRBxU26pEvdLArMK1SEcMct5MJEVUV6VFAy LENIbUBcnNKBTIF/aAEN1MBYyAGB+FAJWIF3AIJ3+IcX8ECGhAVdYFFcMAEVoIR39YFK/vCH bxACWvgHSmBBRLyFaqCGfZCHIVABIcCFaiBRZvQBO83Ba9RBRyxJHd3RtuyBI+zTlWzJuoRJ UBxZJiRUaf2NI4XH/yPO4mxFMXTZVzRD5XzSCHXO50RKpDQBf6AFB5AADKwGFIA2F/BAaoAF F/DSUHXIWcAFFFgBL20BWJ0HeYgEbygCFziBb/hOFUDGF+gGXHgBFdDUb1ABHxgCavgHWC2C F6jTaqzYHPTBPZ1EI/xGGkDW/NzE2gxZZ31Wq+HNk92NU4THnCzOeiTce1RQfixMCI3QCWxM gqSFL9XAEvAGCXhXF5gASPAGE4iEf6iF8CwBINiHGCABIEBb/iCQ2H8AB1242qb1B33Y2q2l BXgAW7IVCGdUgay1gRwEyYnF0WE9yZQkwrfs2P7EW5H1TwDdTfr7W+EI3HlExQJ1RXscw1mE RX5Ew+ac0KS0QBJogQ10ACCIhQlg0RxQgXfIARIY0SL4wBMAB28ogRxQ3Ra4yliFhxlAwSGQ 1RX0gZ2lQYHAVV19BxlcAWk8y2vkRgQ2VrklwvzsgZZsSZeMwr2dSWitSebVDALlSS5c2VRs xVZ8RQRMXH78x8RUzKQkSKWUgFrIAQl4WCG4BfElgU1SgVANgn+whUnwBkpIgYcsAU2tBGMM WCBGxoAdgkF0IBdQASP4B1xgzRzs/t1EdIGLhQHgpduWpMS3TNZAFdTkrWC/veDayGBU/Euf BMPppcVYROPE3UeblUDHNcgHMAEPlQBc6FxwMIEJeIHUlVcSqGMdXoGIPEFv8IerRUEWBYI/ RIGs9YEUSAEV6IF/GFsVqIV/iASOZAGyBElFfE0eVOAFduBkZUJLhOAIlkkK7tvlBWPeCNxE 5WCgNFwxXEUyVGMRvkU2pNLtLddKkIQNpOR9CAIP5NzN/MB3BU/y3Fp89QdwAETXdUFWXaDy lUFISE8ZBAd/oAEbzAGzJEsoZkQacAEi7GS2TEn9nERltU10Pt67VF4qVGXdEOPgzFZFXVAy vN7DlNLE/nzOCr1ACYiBbygBDYSFf+iGDSSBswXmUBWIGBjBHMAFFTCB/K2FFCzdbjiBhj4B gRACFXDkbvAGsNVjcFABF4iEJi7LX71R1/Rk2lRWuARSCR5SdiZFdw5jAuW/AlXFwg1KBbXF Jy3KB3ROcK1AEsBAF/AGINBACYgEfhhdzrSHf6DhD1wgWJCBSuiGHLhKTYWEFOTcWygCakBk cPiHW5Bmc8BVFSjdbwCCW6gFtfTVX61PHc3YufVGujbevE3ndIzpdZzp13Be4GRZnOY/eTxc WjzD41TAfZTUxGzDgMwBb8AFWzAHI9hADTQCW5CAOhSCf9iHIugBpu5SL9WF/hdgyLB2AdBE gVggUV2ggRWEBH3YWVrQhR6YwdJN3Uj4aJE26U0G1h1UYHJOQnEMZbse2brMTZPl69ngyzHm wi4MQwFs0nx80jQ0zH9sw11013eoBiAwSMwu3w0lAR4YgiGQhFmgBKl0AVioBGPmwyAogmKk AVrQSBVEASGIBVqg0VyVBUq4XUw2xJPGU2KNW9/WYiYkZU/U2+NG7r5m5XjUYMDuv+deUG6d 8MNsXJx1gI322V7c0O9eyFCVShJEQRNE0xM4RorcaPZETURMYtX8VbUUVgFnSwK3RGU18HI8 xwRX8NYI3FduZZwGQyD/4AOMRXv2VhJmzOj0WTks/mh1hUo+lsoeRlUTuEoql8gXXUFHflMV IOAt91UX6GaRzFi5bstvJPMHzk8ujskc1/HVYPDgZG7AFPJ7ZNDCXs5INfLnRHKcLdclB0Y/ x0OGDPFARlWsREbTZM9DJGAbhOJqHHC5Dd7hxusg5duhiFZVXu4jJWNsHWw5N2xI7dbmfMAp pcCBLFc65PA6VEgRjMpAJ/FiZMFZRYFGTnGQzO22pdiRFFZj9cYlbMke2GIoRMe6XHM2v0nn /U3mRtDiJGwQRkBI/WlRd0PorNCC7HPMDkYUdciIHPEpJ/SJLEYYdGQ4bc/dBXMAD2dHL8Lh delgp3ShsHQwPtR43Emc/hzsADxjWaznT4dQmzXhfeZnyk5IEsBMzATxJ49IV3/1F51BcYfT RJdPTU5EABdJlW7LTcRbYC/lktXrvCz20zAAkD8AAzgAki95CDh5CIiAlEd5lY8Al395l7+A mI+AC6j5C8CAm795DMiAnccADdh5DQj6DMiAoC/6DTh6DTh6pV96DuCADWj6Dmh6Doj6qe8A q796D7B6D8j6rfeAEAiBrf96sf/6GxD7sg+BG0h7tU97HGj7G2h7HNCBuNcBuq/7uucBHtCB Hdh7HtgBvP/7vP97HQB8HiB2jyeNynsCztsCqfu8tCs8wiO9rCO9wws9PLD8y898zXe8zJd8 /scbPMgXO9DfutCH/NAL/bGj/M4nfa1D/cu/A8gDA7abPNizPC9O5cNnjc3Lgi3YAi+Q/apL u8+v/NbH/Nb/fM5PfuPf/M0/fdcXvOH3fM+ffMI7ftFvftV/fdOHfdaj/cpDAsPP/c/Au6br PL8DPdQ3PLAD/eWn/uTnuunPfuY/fdZ/ffd/f/iv/9HH/Od3/ekHCDx47hA8cwYMGC9btDxx 4hDJv4gSJ1KsaPEixowSo0UrBIDbP44aR5IsafIkypQqV7Js6fIlzJgyZ9KsafMmzpw6d95E gsTJkyxauHhBeAYNmjsClzIdqHQg1KhNnzadSpXgUqpMr2bVulWq/kClWMN+7eo0KtarXquu nTowqUEwX7xw2ZKloUOeLDl6BClSL+DAggcTLmz4MOLEihczVqnsMWRnkp09CwftMubMmjdz hkaus+bPmEWDzky6cx06zzyX5nx6dOvYsjWvfjbZGWRjuhtX5PsxZDTewocTL278OPLkypcz p4mKDqpf9uw1r9674++/1rdz7+79O/jw4seT9DcK1BtPxKxl8xcxnrVv9cg39u03OP38+vfz 7+//v3f8/GOPPvbw8wsqvWzSxib0lINMOvYUU2Ax8gA4mH3AXbghhx16+CGIIMrjijStwLEJ I5z80korm8Dxizr8iFNMOhHZE4x7Id6U/qF2Ovr4I5BBCjmkTqOM0kYbcDCyySiXJOKKJ3D0 Uk87v8DzDzrIoDIOdRLVs49E/OizDz/1jENYO9bxiB+Rbbr5JpxxhqgNKY1skggcb7yB4ibA /FMKHaXYI441/4yDjDn/IDNRPKjU4884wlzCiCrFYINYmsqtKSennXr6KajHzYMKI4hsAsoo b/ziipO//FPPKHIgc86i8CwzXzFe/lOMNsWMwogioHRSSo47ZdrdpqEquyyzzTrL0oEovtHG G4xYC8qpl77ayhvnFfvPMBE9+o80o4SSiBuNtDLMlZ4m+yy88co7b5z+XPPJJ5YwAkcimWQC Byj/ZpJoRPu4/gJHI6RMBM+31lwCRyikkCIPmIMdK9HFxr1LL8cde/xxf/BgMwwmmSySiJ2Z JIIIJoVO9AvC2kwkzUSuIJKJK5uEMgwp8RiWcXIbgzw00UUbjVw8BzOCbSONMNKKRcXAscg1 FvmjciOZtGKJJYrkahPQ4Al9NNllm322TvYoeSIjjSQSykXj7IvMt/9oY7IlpaCLSCgVGztS 2LyNjTbhhRt+eEY5Lx1KI28selE8oWziCjoT6TNKuPv00gjNigU+3OCIiz466Ua7yMgim2RS 0TjFFNOuKwwKUywoOWpz5s/bhV4677373mwpSy89kTmmdNKJJqM8XsomiDCCjc/m/shsN08Z f47xcbv/vj333Q/JSLXsLiyMJaN4YsklwxRTSiluJ3LJN+N0HlE58WhTN5zae78///37V0wm hiEgivACFJhgxMoYIYyCWcMVo4DDJTYxO3RULBujIBiaKnI9xOjPfx78IAitA4/pUYQUxAAF ItxgicZ1aSLYaEUmmteIBeZoE73w29/UhJ37hLCHPvxhd8yhCUygT2elgNtF3gFABLYCFMUQ RiieVgyf/cMf/oCHNHpBiq/pqINA/CIYwzgYZgSjT5sgRSZCYQmN1KMUscpE1hYBh0y8IYaT ssTKFkGtyuHEeqDboYbEKMhBEnIn6DCFKEzBC0xsohih/lhgRrIRjGUQgx/pwIY1SiFHfyGw X6HwV8IGGJMN/rEvgSwkKlOpSpUUAxif8MQmWqGPXlQtI/oohTXQwYtetAts2BMbIHu0ymES s5j/mAdK5iEOeLSrHvEoBWNImRgvGrOa1qxmNnx2Dagd5nPSFAw1rynOcRZSG+LIBg5zGJGw fbMw4SQnPOMpTw69c572vCc+v1PPfPKzn/4sZXbY9M+BErSgggumQA2q0IUydCf7bChEIyrR 65hSmBO9KEYzuhGEarSjHpXoQz8q0pFWM6QkPSlKCWnSlLK0pT1cqUtjKtPuwXSmNr2p6GqK 053ylGw67SlQg8qxnwq1qEZd/hZRj6rUpeaPo0x9KlTlldSoUrWqF5qqVbOqVfJgdate/aoO K5pQsJK1rP3pqlnTqtZpOnWtbn2r7toK17nSVWNyrSte88pWseq1r34lDFr/KtjBRiSwhD2s Xg2L2MXOVbGMfaxaHQvZyYJVspS9bFYti9nNQlWznP3sUT0L2tECVbSkPe1NTYva1bpUtax9 7UldC9vZelS2tL3tRW2L2902VLe8/W1BfQvc4fZTuMQ9rj2Ni9zlklO5zH1uSe8K3emm1LnU vW4hrYvd7YZxTRz5LnjDK97xkre85j0vetOr3vWyt73ufS984yvf+dK3vva9L37zq9/98re/ /v0vm4ADLOABE7jA7BWrgROs4AUzuMEOfjCEIyzhCVO4wha+MIbt25dCcLjDHv4wiEMs4hGT uMQmPjGKU6ziFbO4xS5+MYxjLOMZ07jGNr4xjnOs4x3zuMc+/jGQgyzkIbcYAEY+MpKTrOQl M7nJTn4ylKMs5SlTucpWvjKWs6zlLXO5y17+MpjDLOYxk7nMZj4zmtOs5jWzuc1aDggAADs= --------------8BB211D80A29D710A058DD0A-- From Yann Guidon Sat Nov 18 02:39:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00429 for ; Sat, 18 Nov 2000 18:01:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:23 +0100 (MET) Received: (qmail 15949 invoked by uid 0); 18 Nov 2000 01:38:22 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx07) with SMTP; 18 Nov 2000 01:38:22 -0000 X-eGroups-Return: sentto-1101623-1527-974511289-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 18 Nov 2000 01:34:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 01:34:49 -0000 Received: (qmail 48106 invoked from network); 18 Nov 2000 01:34:48 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Nov 2000 01:34:48 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 18 Nov 2000 01:34:48 -0000 Received: from f-cpu.org (nas4-74.ras.club-internet.fr [195.36.203.74]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA22955 for ; Sat, 18 Nov 2000 02:34:45 +0100 (MET) Message-ID: <3A15DDD9.E866FB11@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 02:39:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: multipart/mixed; boundary="------------0CB78A1A44CEF386D48636DB" X-UIDL: 55ef39736546a6f8d3b26ea33898d869 Status: R X-Status: N --------------0CB78A1A44CEF386D48636DB Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Riepe wrote:
> [...]
> > > I'd prefer something more fault tolerant anyway, like the cu= be you
> > > proposed, or maybe a flat (2-dimensional) hexagonal structur= e.
> > the cube is one of the best solutions, but i wonder what you mean= exactly by
> > "(2-dimensional) hexagonal structure" ...
>
> This one:
>
>       \     /
>        *---*
>       /     \ &= nbsp;   /
>    --*       *---*
>       \     / &= nbsp;   \
>        *---*    = ;   *--
>       /     \ &= nbsp;   /
>    --*       *---*
>       \     / &= nbsp;   \
>        *---*
>       /     \

Verbl=FCffend !

but if each node has 3 neighbours, there's an extension of the
cube topology that works with 16 nodes.

The principle : cut one cube in two halves, then connect the 8 broken
links to another cube, repeat with two other cubes but cut in different
orientations, and "plug" them on the central cube. This makes som= ething
like 3-D cross, it's hard to make ASCII art for this one.
i have enclosed a GIF.
The detail to remark is that the links between the nodes of the inner cube<= BR> are removed (otherwise, we would need more than 3 links/node). I presume th= at
this transformat can be applied to itself, obtaining 64 CPU clusters...
but i have not yet investigated.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
--------------0CB78A1A44CEF386D48636DB Content-Type: image/gif; name="topo3D.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="topo3D.gif" R0lGODlhUwHaAIAAAAAAAP///ywAAAAAUwHaAAAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovECSCqXzKbzCY1Cj9SqNRnEWrfcHyDw9YK75LItHO6h zew2K53ewd30uigez+Ht/D4mn3cD6EdY6BAYWINoyNiYmDjz2DjpBwkZY0mpSXd5+dK5GVrm 6dlCKop69VC6UsqaCqsH8YrCShuLK/N6W7Kb+ysnwTtCOwx83DthDHK7jPzsISU9TU1N4Qyd ncGLzcGtDZ7yDTMebk58jZl+zs68/vneLq9R7lI/j19x/xaf7x+xr1W/fwQZBFRxsKDCMcrU NVwIEUHCWgMjFpx4AqPF/nkakz3cuLAjCZEgzZG8U7EkvpMhWKqE5vJDzJfHZnawSTMXzg07 c8LquS2lT5NCKX4cKg/on6JIsylFwrTps6cWqEplZDWqxKvtsh6dxZWdV2Faw+IaC7Cs2Z9q UX5dO7Vttbl058LdRFJLNLV67zoq+6WbApGB/VLquEam1sSGsUado/jt4AOCGx/BuCcy2UNb LRuaOEhz2gahPRNKuEg0WIOTTZ9OKUn1KtatXfcJmEk259oJKtvOMhCUbtK8e/++3e/UcNqU dx+vU8+Vu6PSn0N/Z2v6ZobOrbcZ52v5AsbdvZv5Vkx72vTmv19rpn4W/Nt169tvouu+/vtj /gr77w/gfwIG2N+ABu6HIF0I+VYLg0g4WJVk5fEkIXGfQEgchuhoSBaH2432oTdyweNhZyXu xR0/KZoCYlurzRYhiyu6NSMOkKlYI0IjilccjAIZcGJmwTSHY47i+BgjihZC9SOQHhGpQ2lH dgZPhePFh+SLRkHZUo+KeDkSmFNeSQ+WXDK55ZlKUikImWmq2WSLWopopZhmaphbm26akKc9 ewalm28nOvknnYXqsuSTdma045pzZknjovpM6BBzYSYqI5xLqeZgkJRuimmllkZ6qI51Gscj qiGayWaZkFb56U2PNokhhDc6mqqgcsIaK4Wzmrpqr0nuKiyoxf4q/imjxBr6qo4c2mqkq6wm eyyh5Jw6bLNjLjuqr8GG6i2yACVIrjQuylduuk4QaKCT7Qb2LrvyqksvftiCi++24qLJrbL3 Wstsv9R+222jfv5LcKmMlshgYZfiWm3B+b6prbH7opNtxQhrKrHFGn/capEXT7qxoQybrGjA IE88MKkrIzyoqhlH3PHIHPNrc80td1nyy9HyfHO42Z6casgGZyrwzCwXTTM2glGFE1o5/6y0 zhATPTPWsvYctMyqPnuuzzHr2jPZCVetcNJGWws210uvvZzWBMsttM8tn8LNEmIDrTagW5+9 c9PTpj013jgT7rXKNJP8tsfC0i1t31bD/g0wtlaNVStffE9deOT7LhMe4IxLvljKb0PuN+l3 20115azvvTnEp2MsOsyeV2wME7Az7XrdjR8+MOqO/4445f6q3rlM9S5v+uK7A8/yfLYPHrjz D0/edeqKE796tbmHLTjvrWcftPDFTz+8zqEfvT32tVOcuPXvk94NZpyT3/vt8rs/fv7qN8+9 56FtUdWBHv/oR704nc9/7TPgAh9YwAd2T3zQQp/AzFc94tWPKcLR3uvCJ7uDaRCA6ZNg/KJ3 QAjGbn8qtKAJXei7ABrvhHAyG/IEGEMR8g+Do7vfDI2XmgZmcIQUZB8NhXjEASYRh17rFPiI GEKktZB2f7sh/v5+JqQq+hCEWmQiaZZXrwT+EIrMyZzbdihG+C1xjErs4QcZSEA4QimCWyQj Etk4vvWt8IVenJ900JO8IoqPilyMogdZiJnvBdKQa4RhsaTnsiH2EYGHsIsc+4dJSjKShFPs oiBLKEnWZOeMnbzjFZVDyl556oyXK98T0TjITTbyklZ0pC319UZYypKW+QMdAMf2SqlN0oGh nOUujVmZmGFyg6k8pAwLmcNSZhKPblTmMvX3TE9mU5faJKQbEanAXAoTmtEsJh6jU87IWZOX 0zynqOrITVOmc5GvJKYxJ6hDeEoTm7C0Ic/WeUp+8rGbA43nPAVqxFw6M4XuvFYz/ht6zLzF UhkAhag9JQJGeu3RIBlV17w+KqB4+aejJI0CQqm5UXPO0ox3qGBL38nCPEZifvfCU0JBiUyY MnSNFS2eh/R4zM24NDI9zZ4/C5orTrLzpkjN6UPt2TCF8miV25Qqm4bKrKLC0YlVHdygUOlN ci50n8BqKty02jFg7vShQSRocHS61F+hVWLK7NP16HlQdqLVrp6ca8GsGZvjDQ+r0NurWXvk 126ts618YmobA+pQlIYosaMCqJQE+80rwhOsUtQaZS1V0Syq0aAntSjSqPrZMoowtDglLOAM G1eSpZY2RSVPWfFaWshWCZizFeW1avtY167MsHXtLUcx/qHVkwiXtAtaUEkTlJ/nQlekIK3u SKkLL+nupz13rWQ9VzpO7koxQ98do8NoKl4xrAZqowlvem/rJvb6yL3vHS3A5Jso+ta3sZjC 75/0u9/uqsm/iQNwgCNZIwLXsLwH1ilfYxq/B3e1wTDtYC0LZWF9UvidnLXqmToM4Q3zio4e vu8wRTwkquF3lOhF8UxbJ1+ghtjFAmFPi8mrSRoDoS8nfs8tdawH7W73x0CmgoF1W2QyHFmv ST4Pgy+q2Sb7YMnXlHIXqExlK6cxthHVMhew/GQvR/bCeW2nmPV0Y7fe88w2CnNm18rmF6dZ nmaOs5zJnFsu2xlRT32snvc812YNj1WlgIbvjKH850KP99B+rrOiFz1hnEr20fkscaONS2l8 QhrOmcYlo9982E4LONKIdrSoMftpx54arpzOs6lXPepWD3rNsLYvoS9da1n0GdS3zjWdYTtn X6e016oWtqG/KGT+GJsGkKw0qZedW7/aGNp8trSkMZ1rFlf72dRG6GdJ3O1A0zrWrw53CGeb YXPDtbcSVrezjRtYd9850d3FNrUvi2Z6y1s09hbtvqttb+4EvNu2jZK+/62YgQMI4YJQOBgc TvBkK5vhFK+4xS+O8YyHuwAAADs= --------------0CB78A1A44CEF386D48636DB-- From Alan Grimes Sat Nov 18 02:52:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00432 for ; Sat, 18 Nov 2000 18:01:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:24 +0100 (MET) Received: (qmail 4379 invoked by uid 0); 18 Nov 2000 01:52:34 -0000 Received: from hp.egroups.com (208.50.99.201) by mx12.rz2.gmx.net (mx12) with SMTP; 18 Nov 2000 01:52:34 -0000 X-eGroups-Return: sentto-1101623-1528-974512347-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 18 Nov 2000 01:52:33 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 01:52:27 -0000 Received: (qmail 88225 invoked from network); 18 Nov 2000 01:52:25 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 18 Nov 2000 01:52:25 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta1 with SMTP; 18 Nov 2000 01:52:25 -0000 Received: from 207-172-184-21.s21.tnt6.lnhva.md.dialup.rcn.com ([207.172.184.21] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 13wxB2-00031a-00 for f-cpu@egroups.com; Fri, 17 Nov 2000 20:52:24 -0500 Message-ID: <3A15E0E4.8D032C33@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> <3A15DDD9.E866FB11@f-cpu.org> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 20:52:36 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 278a7cfd31bf0a07ba4b4f674ad880a4 Status: R X-Status: N > Michael Riepe wrote:
> > [...]
> > > > I'd prefer something more fault tolerant anyway, like t= he cube you
> > > > proposed, or maybe a flat (2-dimensional) hexagonal str= ucture.
> > > the cube is one of the best solutions, but i wonder what you= mean exactly by
> > > "(2-dimensional) hexagonal structure" ...
> >
> > This one:
> >
> >       \     / > >        *---*
> >       /     \&n= bsp;    /
> >    --*       *---* > >       \     /&n= bsp;    \
> >        *---*   =     *--
> >       /     \&n= bsp;    /
> >    --*       *---* > >       \     /&n= bsp;    \
> >        *---*
> >       /     \ >
> Verbl=FCffend !

Have you computed a growth model for this?

What is the maximum number of hopps for a network of N processorz?

That is the only thing that intrests me.

bye.

--
I suspect that it is significantly easier to become a proficient brain
surgeon than a linux user.
http://users.erols.com/alang= rimes/  <my website.

####### Begin Eschelon Block #######
unabomber anthrax plutonium militia delta force ruby ridge atf batf waco oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers FBI chemical weapons twa 800 roswell terrorist freedom
eGroups Sponsor=
3D""
From "Marco Al" Sat Nov 18 03:14:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00435 for ; Sat, 18 Nov 2000 18:01:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:25 +0100 (MET) Received: (qmail 32116 invoked by uid 0); 18 Nov 2000 02:08:27 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx15) with SMTP; 18 Nov 2000 02:08:27 -0000 X-eGroups-Return: sentto-1101623-1529-974513299-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 18 Nov 2000 02:08:23 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 02:08:18 -0000 Received: (qmail 33679 invoked from network); 18 Nov 2000 02:08:18 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 18 Nov 2000 02:08:18 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 18 Nov 2000 03:09:23 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id DAA05747 for ; Sat, 18 Nov 2000 03:08:16 +0100 (MET) Message-ID: <001f01c05105$401072c0$29e65982@student.utwente.nl> To: References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 03:14:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d1269adf341cf701f8075841e7df97d Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> when i try to push what looks a "high-end solution", i still try to keep the
> price as low as possible. OTOH if you want the lowest possible price, you end
up
> doing harmful choices. i am simply trying to keep you from jumping blindly
> forever in the endless hole of captive/nonscalable/unbalanced architectures.

I didnt intend the shared bus to be a low end solution, but a low cost one. x86
SMP systems do not have individual memory pools for processors. In a small SMP
system you would have a lot of broadcast traffic (coherency) on the F-bus, for
which a switch is merely nuisance. I didnt suggest taking the same speed bus and
making it shared, I suggested taking a faster bus and making it shared to get to
the same level of performance and seeing if it cost less.

> > Sure it doesnt scale for small numbers of processors, but whats cheaper...
> it's not only about the price, it's also what you get for the price.
> if you have the bandwidth of 1 CPU with a 2 CPU system, it's not worth it.

I said it didnt scale, I didnt say it wasnt scalled appropriately... you should
have the bandwith needed for 4 CPU's with a 2 CPU system, as I said:

> > slightly overengineering the bus

> it's still too much application dependent. if you want a small core, ok,

Assuming for a moment you couldnt compensate with a slightly faster bus but a
shared bus would be easy to implement... by going with what you call a high end
solution you lessen the systems applicability ($/performance ratio) for problems
which dont need it, or to speak in cliche's everything is a compromise.

Of course it doesnt have to be an either/or situation, the protocol could be the
same... just the physical interface would need to be a little difference (not
too much, BLVDS isnt that much different from LVDS) and you would need some
extra pins for round robin scheduling of access.

Anyone want to take a poke at giving a good guess of the actual bandwith the
F-Bus will need and what kinds of traffic (broad/multi/uni-cast) will be flowing
over it?

Marco
eGroups Sponsor
From tomsoyyer@263.net Sat Nov 18 03:59:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00438 for ; Sat, 18 Nov 2000 18:01:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:26 +0100 (MET) Received: (qmail 15943 invoked by uid 0); 18 Nov 2000 02:59:28 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx22) with SMTP; 18 Nov 2000 02:59:28 -0000 X-eGroups-Return: sentto-1101623-1530-974516361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 18 Nov 2000 02:59:23 -0000 X-Sender: tomsoyyer@263.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 02:59:21 -0000 Received: (qmail 60046 invoked from network); 18 Nov 2000 02:59:20 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Nov 2000 02:59:20 -0000 Received: from unknown (HELO hi.egroups.com) (10.1.10.41) by mta2 with SMTP; 18 Nov 2000 02:59:20 -0000 X-eGroups-Return: tomsoyyer@263.net Received: from [10.1.4.73] by hi.egroups.com with NNFMP; 18 Nov 2000 02:59:20 -0000 To: f-cpu@egroups.com Message-ID: <8v4ra7+pkph@eGroups.com> In-Reply-To: <3A154B07.5E7BED6@llandre.freeserve.co.uk> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 211.99.227.18 From: tomsoyyer@263.net MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 02:59:19 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab873a556b16b2f44f0111139edf4b81 Status: R X-Status: N --- In f-cpu@egroups.com, Jeff Davies <jeff@l...> wrote:
> I think GCC can be modified to do this, although in fact, a certain
> amount could be performed by a
> binary string replacement. (GCC would give some additional
> optimisation).
>
There was a Java compiler named GCJ which can build native binary
code from Java source code and Java byte code.It seems that only
AWT can not be supported now.
> Commercial Java compilers doing this translation are Asymmetrix
> Supercede, Sun Hotspot, Caffeine,
> (and IBM VisualAge Java)
> and many JVMs do JIT bytecode to native compilation, so this can't
be
> difficult to do.
>
The problem is the binary code builded from GCJ is a little big.  
> Although Java does not give explicit access to pointers, they are
used
> implicitly (and the code is safe).
> What kind of things would be necessary to make available in, a core
> iolib type package written in
> FCPU assembler such that the Linux Kernel (or other) could be
written in
> Java, and compiled into
> bytecode and from there into native code?
>
I think that  GCC for FCPU is not diffical to make.So we can
rebuild the current linux kernel for FCPU,why rewrite it in
Java ? For application,java is good,but for kernel ,C is more
efficiency.
> The main reason for this is that I have noticed that my
productivity is
> much greater in Java than in C++.
Me too.Java have a very good Basic Class Lib and easy to use ^&^
> Even experienced C++ coders have to sometimes think very hard about
what
> they are passing, if it should
> be const, if it should be ** or * or &, and what casting they
should do.
>
> It would also be much easier to audit. (and therefore prove it won't
> crash, or be insecure).
>
> Has anyone used say VisualAge Java, and compiled native? Is it
slower
> than C++??
> (If not, then f**it, why waste time on all that pointer crap).
>
> Jeff Davies
eGroups Sponsor
From Ben Franchuk Fri Nov 17 19:51:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00441 for ; Sat, 18 Nov 2000 18:01:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:27 +0100 (MET) Received: (qmail 3555 invoked by uid 0); 18 Nov 2000 04:51:24 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx07) with SMTP; 18 Nov 2000 04:51:24 -0000 X-eGroups-Return: sentto-1101623-1531-974523077-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 18 Nov 2000 04:51:22 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 04:51:17 -0000 Received: (qmail 39473 invoked from network); 18 Nov 2000 04:51:16 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 18 Nov 2000 04:51:16 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 18 Nov 2000 04:51:16 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA16849 for ; Fri, 17 Nov 2000 21:42:44 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A157E14.33F004BB@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 17 Nov 2000 18:51:00 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] is it possible have free anything? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d78163f6d09684e5a5eecc7f15a252e4 Status: R X-Status: N I found this on the FPGA news group.
Things like this make you wonder if a free cpu is even possable.
-------------------
While I could make quite a few comments on this,
I think I will just give you the link:


   http://www.xilinx.com/prs_rls/xilinxwin.htm

Philip

Philip Freidin
Fliptronics
--------------------
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Nicolas Boulay Sat Nov 18 14:17:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00450 for ; Sat, 18 Nov 2000 18:01:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:29 +0100 (MET) Received: (qmail 25808 invoked by uid 0); 18 Nov 2000 13:15:02 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx18) with SMTP; 18 Nov 2000 13:15:02 -0000 X-eGroups-Return: sentto-1101623-1532-974553297-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 18 Nov 2000 13:14:58 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 13:14:56 -0000 Received: (qmail 51383 invoked from network); 18 Nov 2000 13:14:55 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 18 Nov 2000 13:14:55 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 18 Nov 2000 13:14:55 -0000 Received: from ifrance.com (nas13-150.vlt.club-internet.fr [195.36.163.150]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA14665 for ; Sat, 18 Nov 2000 14:14:52 +0100 (MET) Message-ID: <3A168175.CBEF0B69@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> <007101c0502e$fa59ca00$29e65982@student.utwente.nl> <3A15B78C.148A3A9E@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 14:17:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip, network topoly, coherency, ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9a75feadb04b500f8c864c709ab51bb4 Status: R X-Status: N ~50 messages in 2 days, hard to read them all !!!!

Yann Guidon a =E9crit :
>
> hi again,
>
> Marco Al wrote:
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > BTW wouldnt it be smart to put cachebility in the page table so e= ven non
> > local memory can be cached? (even if coherency is software contro= lled it
> > would be nice if you could cache memory on another processor if y= ou had
> > guarantuees on it not changing, better than always having to repl= icate or
> > move it)
> i guess that the SW is still the best solution, otherwise coherency be= comes
> a problem. let's keep the specifications loosened on this part, so we = can
> see what goes on.
>

No problems with coherency, look more to the 4 algorithmes. All 4 keep
the coherency but depending on the application, you have to choose one.
2 don't you use replication, the 2 other does. So we need coherency
mecanism which are not very hard to implement.

Imagine in simple SMP machine like a bi-pentuim. The probleme is to keep the cache coherent. Now, each write is written inside the main memory.
And the second cpu look at the address on the bus to see if the memory
has change (bus snooping). So you have to access the main memory for
each write. In the other hand, inside your program you use mutex
variable to protect critical section (cs). In fact, inside a critical
section you don't need to update the main memory each time a write
occur. But only once, when the mutex is keep off.

In that case you use only the full-replication algorithme but for some
case, the other algorithme are much more quick.

> > > Mais non ! It's very simple. The MMU has 2 mode ics (inside = critical
> > > section) and none-ics.
> > How does it know which mode its in again? :)
> i don't know. I have difficulties to understand his point of view.
> i hope that we'll be able to discuss about it in the pre-meeting in Pa= ris.

Maybe one instruction to send thought special register. I haden't really think of it.

>
> oh, btw, yes, several french f-cpu team members are organising a "= ;pre-meeting"
> in/around Paris, as to organise the real meeting in Berlin during the = 17C3.
>
> > > And the better predictable network ever made is the one in r= ing.
> > A shared bus isnt half bad either, both will need extra hierarchi= es to scale
> > past small amounts of processors.
> that's the real problem. there was a "supercomputer" made > with several hierarchies of rings
> (Was it the KSR ? it was the same period...)
> and it never reached outstanding performance.
> read the comp.sys.super FAQ. Ring-based architecture sucks.
>
> A higher degree of interconnexion is more than necessary. I have seen<= BR> > that 4 links is a strict minimum. a T3D requires 6 links (3-D torus) > but it also needs another link to a central repository for
> high-speed semaphores/synchronisation. A 3D torus with an internal
> tree (a mix of 2 different topologies) seems to fit most of the
> most demanding tasks. It is rather easy to route and can tolerate
> faulty nodes through node re-routing. Architecturally, it's
> something between the Thinking Machines CM-5 and the Cray Research T3E= .
> There, you don't have any bandwidth problem at all...
>

So you need a 1500 BGA package... 6 nodes so 12 channel (because you
need 2 ways) * 32 or 64 bit * 2 (because of the grounds signal or the
complemtary signal) =3D 768 pins ;) You don't build a supercomputer but a workstation. Don't forget that ! Maximum performance is not has
important has the scalability or the programming ease and the fact to
compile in what ever computer you want ("portabilit=E9" in french= but i
don't know the word in english).

So i emphasis the fact that the ring network is best and the cheapest
one. And the simplest is the best (don't use a double one). You only
have 2 channels one each chips (+ the local memory buse). And most of
all, you don't need to make routing !!! Algorithme of routing is a
NP-hard problem, so imagine the silicium that you need to have... And
your OS will go crazy !

For memory coherency, a broadcast is easy to update or invalidate data.
A packet make the all cycle with somethink like "page number xxx is no= w
nnnnnnnnnn" or "page number xxx is invalidate, owner of the page = is ooo"
inside him. And each chip could update is own local memory.

The network is just used to maintain memory coherency thought the
system. Coherenry of copy are keep by Mutex. And what is a Mutex, it's a ressource used to say : "i'm using those variable don't write them any=
more, i will release it in a few times". So you don't need to maintain=
the coherency during the cs but at the end you update all the modified
memory page.

And adding a new chip is easy, just open the link and assert it. How do
you make that with a 3d torus ?

And you don't have any G-ship any more ;) You just need some gateway to
the PCI bus or the IO.

> > > This idea come when i see the program of whygee for SMP syst= em (a
> > > graphical program on DOS in pure ASM and MMX, my usual compl= et nightmare
> > > ;-). He use the both cpu inside each functions. So i think t= hat usualy
> > > you don't compile program to be run on 2 cpus. Only one are = used. You're
> > > compiler manage to schedule 5 or more instruction to be run = in the same
> > > time. Why not for a higher level for BLOCKs of instructions = ?
> > 5 or more? Thats a bit optimistic, Merced wouldnt be having troub= les if
> > compilers were that good :)
>
> I think that i didn't understand Nicolas, and he didn't understand me = well either.
>

I know that i simplify a lot ;) The idea is just to use more than 1 cpu
inside the same function. Wich is not possible in Unix, only 2
differents process are executed on differents cpus.

<snip>

> > Finegrained multithreading is definetely a good idea, NEC has a n= ice article
> > on their SMT processor which describes some algorithms where your= approach
> > works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf
> their SIMD data are 32-bit wide. i am laughing :-)
> Their mutlithreaded CPU can be outperformed by a 128-bit SIMD CPU.
> They also renewed my interest for the scatter/gather instructions.
> Their mutlithreading algorithm looks crazy, because they could do vect= oring
> or wide SIMD with a compiler that would be only a bit smarter.
>

I have read somewhere that data-parallelism are different from
instrutions parrallelism (ILP). So 2 level of ILP should be code, and
SIMD one should be interresting, too. The problem are decorrelated.

> > > This could be practice for SMT processors. Pratically a SMT = processor
> > > could be simulated on a cpu with large register set (like th= e fcpu) BUT
> > > the size of the instruction word is shorter, so you reduice = the need for
> > > memory bandwith, you can hide the SRAM of the cache latency,= have very
> > > big pipeline (a want to write the 64*64 multiplier with ... = 128 levels
> > > of pipeline ;)... So you can change in the above text "= 4 cpus" by "4
> > > ways SMT processor".
>
> In practice, SMT surpasses multi-cores. few added complexity, easy por= ting,
> dynamic load balancing, that's almost a dream.
>

It's big as a cpu but it's compute like 10 cpu but with the
communication problem, not as easy...

nicO
eGroups Sponsor=
3D""
From Alan Grimes Sat Nov 18 16:55:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00483 for ; Sat, 18 Nov 2000 18:01:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:41 +0100 (MET) Received: (qmail 17378 invoked by uid 0); 18 Nov 2000 15:56:03 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx05) with SMTP; 18 Nov 2000 15:56:03 -0000 X-eGroups-Return: sentto-1101623-1533-974562928-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 18 Nov 2000 15:55:43 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 15:55:27 -0000 Received: (qmail 67716 invoked from network); 18 Nov 2000 15:55:27 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 18 Nov 2000 15:55:27 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 18 Nov 2000 15:55:26 -0000 Received: from 216-164-134-147.s401.tnt3.lnhva.md.dialup.rcn.com ([216.164.134.147] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 13xAKq-0005XD-00 ; Sat, 18 Nov 2000 10:55:25 -0500 Message-ID: <3A16A67A.C0CFBB5A@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com, tunes@tunes.org From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 10:55:38 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Lets squeeze it! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d6c8827f9262ec1989c8b721ff9228c Status: R X-Status: N om

1
Okay, inside the modern RISC CPU there is a stage in the pipeline where
the raw *instruction stream* is examined and then a *Computation* is
constructed based on it. This computation is like a 3D rendition of the
linear instruction stream that takes into consideration data hazards,
and other dependancies and results in a set of commands that then
executes in the function units with optimal paralellization.

2
A compiler for such a CPU will look at a piece of code that can be
described as follows:

a REQUIRES b, c, d.
DO a.

The compiler would see this and then compile the code in such a way to
give hints to the processor as to how things can be done in paralell.

b > instruc.
c > instruc.
d > instruc.
b > instruc.
c > instruc.
d > instruc.
b > instruc......

Okay. By giving these clues the compiler can give the CPU a better
opportunity to make things go faster, as there are far fewer data
hazards within the instruction stream. This is better than generating
code like:

DO b.
DO c.
DO d.
DO a.

Which limits the CPU's ability to paralellize because the instructions
within b, c, and d are necessarily linear... Today's CPUs get around
this to some extent by generating a graph of the computation which
allows it to do some things out-of-order.

Naturally this solution is limited as it does not allow flexability in
execution. If a Function e were written that requires b, c, and f then
the compiler would have to generate a second optomized block for that
contingency.

3
The operating system for this machine running a dozen or so programs
will make decisions as to how these programs will share the CPU time
available. Devices will neccessarily run exclusively. Realtime tasks,
very much like devices, will be given time slices that allow them to do
what needs to be done. And finally the remaining programs will be run
whenever they are "available" to run, meaning that they will run when
they are not blocked. Hopefully Deadlock, Starvation, and race
conditions can be avoided successfuly.
      At all times the OS will attempt to ensure that no resource is
underutilized.

4
Just the other day I learend of a system called PBS or "Portable Batch
System" that caches jobs for large-scale paralell multicomputers, or
even singlehost machines that have a lot of work to do. This system
works by observing resource utilization throughout the system and then
launches tasks as the resources to execute them become available.

----

Now the question here is wheather it is possible to squeeze all these
very similar systems togeather into one recursive function, accelerated
by the processor, that solves these very similar optomization problems?

Ofcourse I am saying that you would start the function at 4 which would
then call itself as needed at 3 and soforth...

One of the key steps to making this happen is to remove these
unneccessary high-level abstractions, making the system flater and more
organic...

--
I suspect that it is significantly easier to become a proficient brain
surgeon than a linux user.
http://users.erols.com/alangrimes/  <my website.

####### Begin Eschelon Block #######
unabomber anthrax plutonium militia delta force ruby ridge atf batf waco
oklahoma city assault rifle sog sof m-16 clinton marx crack m-60 c5 c7
mlk panthers FBI chemical weapons twa 800 roswell terrorist freedom
eGroups Sponsor
From "Marco Al" Sat Nov 18 17:57:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00486 for ; Sat, 18 Nov 2000 18:01:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 18 Nov 2000 18:01:42 +0100 (MET) Received: (qmail 31104 invoked by uid 0); 18 Nov 2000 16:51:30 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx10) with SMTP; 18 Nov 2000 16:51:30 -0000 X-eGroups-Return: sentto-1101623-1534-974566284-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 18 Nov 2000 16:51:28 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 16:51:22 -0000 Received: (qmail 6100 invoked from network); 18 Nov 2000 16:51:22 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 18 Nov 2000 16:51:22 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 18 Nov 2000 17:52:27 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id RAA20005 for ; Sat, 18 Nov 2000 17:51:21 +0100 (MET) Message-ID: <003a01c05180$9e63d3a0$29e65982@student.utwente.nl> To: References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> <007101c0502e$fa59ca00$29e65982@student.utwente.nl> <3A15B78C.148A3A9E@f-cpu.org> <3A168175.CBEF0B69@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 17:57:18 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip, network topoly, coherency, ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2c421a26d9b9efd847ef0837575615fd Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> No problems with coherency, look more to the 4 algorithmes. All 4 keep
> the coherency but depending on the application, you have to choose one.
> 2 don't you use replication, the 2 other does. So we need coherency
> mecanism which are not very hard to implement.

Ill just quote your summation for easy reference here:
"Central server (uncachable memory),
Migration (one copy of the data that move thought the network with a central
data location center),
read-replication (many copy of the data in case of write, we INVALIDATE the
other copy, there're also a central data location center),
Full-replication (idem but the data are propagate)."

> Imagine in simple SMP machine like a bi-pentuim. The probleme is to keep
> the cache coherent. Now, each write is written inside the main memory.
> And the second cpu look at the address on the bus to see if the memory
> has change (bus snooping). So you have to access the main memory for
> each write. In the other hand, inside your program you use mutex
> variable to protect critical section (cs). In fact, inside a critical
> section you don't need to update the main memory each time a write
> occur. But only once, when the mutex is keep off.

Or if the cache overflows, cant keep dirty bits in memory (well you can, but you
dont want to). Keeping an extra set of dirty bits and cycling through the cache
for them to update the other processors doesnt sound exactly straightforward
though...

(Oops forgot about farther down, where you only invalidate pages, but Ill let
this stand anyway)

> So i emphasis the fact that the ring network is best and the cheapest
> one. And the simplest is the best (don't use a double one). You only
> have 2 channels one each chips (+ the local memory buse). And most of
> all, you don't need to make routing !!! Algorithme of routing is a
> NP-hard problem, so imagine the silicium that you need to have... And
> your OS will go crazy !

I think with only a small bit of effort you could create an interface which
could accomodate both (ring/pass-through-network and switched) hell maybe even 3
different interfaces including a shared bus :) But having both ring and switched
would be easiest, and for a dual processor it would allow you to forget about
the switch without any worries.

> For memory coherency, a broadcast is easy to update or invalidate data.
> A packet make the all cycle with somethink like "page number xxx is now
> nnnnnnnnnn" or "page number xxx is invalidate, owner of the page is ooo"
> inside him. And each chip could update is own local memory.

Oh you want to only do accounting on page level... that will create alot more
traffic than in for instance the dual Px setup.

> > > Finegrained multithreading is definetely a good idea, NEC has a nice
article
> > > on their SMT processor which describes some algorithms where your approach
> > > works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf
> > their SIMD data are 32-bit wide. i am laughing :-)
> > Their mutlithreaded CPU can be outperformed by a 128-bit SIMD CPU.
> > They also renewed my interest for the scatter/gather instructions.
> > Their mutlithreading algorithm looks crazy, because they could do vectoring
> > or wide SIMD with a compiler that would be only a bit smarter.
> >
>
> I have read somewhere that data-parallelism are different from
> instrutions parrallelism (ILP). So 2 level of ILP should be code, and
> SIMD one should be interresting, too. The problem are decorrelated.

Yes but some people very much like code with lots of long loops, where you can
turn one into the other ;) But thats not really the norm of the kind of code a
"UNIX CPU" will be swallowing.

Marco
eGroups Sponsor
From Yann Guidon Sat Nov 18 21:33:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03875 for ; Sun, 19 Nov 2000 09:18:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:18:47 +0100 (MET) Received: (qmail 23153 invoked by uid 0); 18 Nov 2000 20:28:45 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx05) with SMTP; 18 Nov 2000 20:28:45 -0000 X-eGroups-Return: sentto-1101623-1535-974579316-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 18 Nov 2000 20:28:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 20:28:35 -0000 Received: (qmail 62596 invoked from network); 18 Nov 2000 20:28:35 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 18 Nov 2000 20:28:35 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 18 Nov 2000 20:28:34 -0000 Received: from f-cpu.org (nas2-193.ras.club-internet.fr [195.36.192.193]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA24928 for ; Sat, 18 Nov 2000 21:28:31 +0100 (MET) Message-ID: <3A16E79B.68441B32@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> <3A14FD0C.6A95352B@jetnet.ab.ca> <20001118002748.18989@thrai.stud.uni-hannover.de> <3A154B2F.6D4B6FA4@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 21:33:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9501f6b08dfdca15daa408af139e5022 Status: R X-Status: N hi !

Ben Franchuk wrote:
> Michael Riepe wrote:
> > On Fri, Nov 17, 2000 at 09:40:28AM +0000, Ben Franchuk wrote:
> > > Are interrupts needed anyhow? The G-chip could most likely poll a fast as you
> > > need.
> > You're kidding, aren't you?  Of course we need interrupts!  Unless you
> > can offer something better, of course ;)
>
> Umm Message passing?
> The problem is the interrupt system still is kind of a catch all
> for problems. You have error/danger signals , regular buffered service
> calls,unbuffered service calls,software traps(floating point with no floating
> point hardware),OS calls and timer ticks. All this stuff interrupts the processor
> and then requires task rescheduling and lots of flushing of buffers and cache.
> We have streamlined the processor and memory but I/O and interrupts need to
> be streamlined with hardware for bit fiddling.
> Ben.

I wouldn't write it better.
Of course, the core needs to be finished, but your point of view is
very acurate.

I/O is done throught usual memory instructions, as we have discussed.
IRQ is half defined but shouldn't be a big problem.
Semaphores could use most of the same mechanisms (special messages on the I/O bus).

did i miss something ?

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Nicolas Boulay Sat Nov 18 22:31:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03884 for ; Sun, 19 Nov 2000 09:18:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:18:53 +0100 (MET) Received: (qmail 28334 invoked by uid 0); 18 Nov 2000 21:29:16 -0000 Received: from jk.egroups.com (208.50.144.83) by mx12.rz2.gmx.net (mx12) with SMTP; 18 Nov 2000 21:29:16 -0000 X-eGroups-Return: sentto-1101623-1536-974582936-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 18 Nov 2000 21:29:13 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 21:28:55 -0000 Received: (qmail 13404 invoked from network); 18 Nov 2000 21:28:54 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 18 Nov 2000 21:28:54 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 18 Nov 2000 22:30:00 -0000 Received: from ifrance.com (nas7-248.vlt.club-internet.fr [194.158.109.248]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA15360 for ; Sat, 18 Nov 2000 22:28:51 +0100 (MET) Message-ID: <3A16F53F.8AF21385@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3.0.6.32.20001114223829.008e49f0@mail.mindspring.com> <3A122CC3.FE5811A2@f-cpu.org> <20001115201938.05468@thrai.stud.uni-hannover.de> <3A131CC9.18E46D88@f-cpu.org> <3A145855.878F6A90@ifrance.com> <007101c0502e$fa59ca00$29e65982@student.utwente.nl> <3A15B78C.148A3A9E@f-cpu.org> <3A168175.CBEF0B69@ifrance.com> <003a01c05180$9e63d3a0$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 22:31:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip, network topoly, coherency, ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: afaa6fd19e551cedd3ba0332df7abea4 Status: R X-Status: N Hello,

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > No problems with coherency, look more to the 4 algorithmes. All 4= keep
> > the coherency but depending on the application, you have to choos= e one.
> > 2 don't you use replication, the 2 other does. So we need coheren= cy
> > mecanism which are not very hard to implement.
>
> Ill just quote your summation for easy reference here:
> "Central server (uncachable memory),
> Migration (one copy of the data that move thought the network with a c= entral
> data location center),
> read-replication (many copy of the data in case of write, we INVALIDAT= E the
> other copy, there're also a central data location center),
> Full-replication (idem but the data are propagate)."
>

Thinks !

> > Imagine in simple SMP machine like a bi-pentuim. The probleme is = to keep
> > the cache coherent. Now, each write is written inside the main me= mory.
> > And the second cpu look at the address on the bus to see if the m= emory
> > has change (bus snooping). So you have to access the main memory = for
> > each write. In the other hand, inside your program you use mutex<= BR> > > variable to protect critical section (cs). In fact, inside a crit= ical
> > section you don't need to update the main memory each time a writ= e
> > occur. But only once, when the mutex is keep off.
>
> Or if the cache overflows, cant keep dirty bits in memory (well you ca= n, but you
> dont want to). Keeping an extra set of dirty bits and cycling through = the cache
> for them to update the other processors doesnt sound exactly straightf= orward
> though...
>
> (Oops forgot about farther down, where you only invalidate pages, but = Ill let
> this stand anyway)

Humm. Always the same pb. L2 few 100kB, local mem few 100 MB, Hard disk
few 10 GB,... So you alwas need a system like VM (page remplacement).
But hier, instead of using the hd directly, you use the local mem then
the next local mem (it's quicker). Ok, it's a bit complicated but we
need it.

>
> > So i emphasis the fact that the ring network is best and the chea= pest
> > one. And the simplest is the best (don't use a double one). You o= nly
> > have 2 channels one each chips (+ the local memory buse). And mos= t of
> > all, you don't need to make routing !!! Algorithme of routing is = a
> > NP-hard problem, so imagine the silicium that you need to have...= And
> > your OS will go crazy !
>
> I think with only a small bit of effort you could create an interface = which
> could accomodate both (ring/pass-through-network and switched) hell ma= ybe even 3
> different interfaces including a shared bus :) But having both ring an= d switched
> would be easiest, and for a dual processor it would allow you to forge= t about
> the switch without any worries.
>

If you put a swith, brodcast or multicast became much more cost
effective compare to the ring. And it's the main part of the use of the
network (you propagate the write). So each time, it's a multicast (the
copy's owner). The other part are used for page replacement.

It's the main problem of the distributed memory. Each node have the same amount of memory. You can't make a flat physical adressing map, because
the access time aren't the same. But in the opposite only a flat
adressing mode could be used by a "common" OS like Unix. So the o= s
should see a linear memory but in fact, it isn't. You could imaging
seeing n fois x bytes of memory and the VM mecanism shared. I know it's
not enought ;)

So n times x bytes of global memory, the network to shared the page
named by a number, the MMU which need to give a good adresse in the
local memory ans keep it coherent,... And a system for Unix, each
process could access less memory than the overall memory present (x),
but the overall system has n*x bytes of memory. If we want to make a
meduim grain of parrallelism, a process should access few cpus. A
nightmare, no ?... But a nice feature !

> > For memory coherency, a broadcast is easy to update or invalidate= data.
> > A packet make the all cycle with somethink like "page number= xxx is now
> > nnnnnnnnnn" or "page number xxx is invalidate, owner of= the page is ooo"
> > inside him. And each chip could update is own local memory.
>
> Oh you want to only do accounting on page level... that will create al= ot more
> traffic than in for instance the dual Px setup.
>

NO ! 4 algorithme to adapt it to the application. The central and the
migration access what is needed. But a replication always use block.
(because of the latency, an external bus always use burst transfert to
fill caches, something that we could called page)

> > > > Finegrained multithreading is definetely a good idea, N= EC has a nice
> article
> > > > on their SMT processor which describes some algorithms = where your approach
> > > > works well here http://www.computer.org/micro/mi2000/pdf/m4012.pdf<= /a>
> > > their SIMD data are 32-bit wide. i am laughing :-)
> > > Their mutlithreaded CPU can be outperformed by a 128-bit SIM= D CPU.
> > > They also renewed my interest for the scatter/gather instruc= tions.
> > > Their mutlithreading algorithm looks crazy, because they cou= ld do vectoring
> > > or wide SIMD with a compiler that would be only a bit smarte= r.
> > >
> >
> > I have read somewhere that data-parallelism are different from > > instrutions parrallelism (ILP). So 2 level of ILP should be code,= and
> > SIMD one should be interresting, too. The problem are decorrelate= d.
>
> Yes but some people very much like code with lots of long loops, where= you can
> turn one into the other ;) But thats not really the norm of the kind o= f code a
> "UNIX CPU" will be swallowing.
>

Thats not a problem, it's just the compilator problem ;)

> Marco
nicO

>

eGroups Sponsor=
3D""
From Michael Riepe Sat Nov 18 23:25:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03896 for ; Sun, 19 Nov 2000 09:18:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:18:57 +0100 (MET) Received: (qmail 23920 invoked by uid 0); 18 Nov 2000 23:25:40 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx08) with SMTP; 18 Nov 2000 23:25:40 -0000 X-eGroups-Return: sentto-1101623-1538-974589935-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 18 Nov 2000 23:25:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:25:35 -0000 Received: (qmail 64755 invoked from network); 18 Nov 2000 23:25:35 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 18 Nov 2000 23:25:35 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.240) by mta1 with SMTP; 18 Nov 2000 23:25:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00565; Sat, 18 Nov 2000 23:25:29 +0100 Message-ID: <20001118232528.17965@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A151729.7418DA11@f-cpu.org> <20001117153543.00722@thrai.stud.uni-hannover.de> <3A14FD0C.6A95352B@jetnet.ab.ca> <20001118002748.18989@thrai.stud.uni-hannover.de> <3A154B2F.6D4B6FA4@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A154B2F.6D4B6FA4@jetnet.ab.ca>; from Ben Franchuk on Fri, Nov 17, 2000 at 03:13:51PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 23:25:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IO instructions. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7383fe3062e4bf0a4079d08f35ae7356 Status: R X-Status: N On Fri, Nov 17, 2000 at 03:13:51PM +0000, Ben Franchuk wrote:

> > You're kidding, aren't you?  Of course we need interrupts!  Unless you
> > can offer something better, of course ;)
>
> Umm Message passing?

You still need something that interrupts (sic!) the processor when a
message comes in -- or else it will have to poll an imaginary `there is
a message for you' status bit.

> The problem is the interrupt system still is kind of a catch all
> for problems. You have error/danger signals , regular buffered service
> calls,unbuffered service calls,software traps(floating point with no floating
> point hardware),OS calls and timer ticks. All this stuff interrupts the
> processor
> and then requires task rescheduling and lots of flushing of buffers and cache.
> We have streamlined the processor and memory but I/O and interrupts need to
> be streamlined with hardware for bit fiddling.

I understand the problem, but I don't see any solution.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sun Nov 19 00:12:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03899 for ; Sun, 19 Nov 2000 09:18:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:18:57 +0100 (MET) Received: (qmail 17666 invoked by uid 0); 18 Nov 2000 23:25:45 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx07) with SMTP; 18 Nov 2000 23:25:45 -0000 X-eGroups-Return: sentto-1101623-1537-974589928-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 18 Nov 2000 23:25:37 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:25:28 -0000 Received: (qmail 79939 invoked from network); 18 Nov 2000 23:25:27 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Nov 2000 23:25:27 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.240) by mta1 with SMTP; 18 Nov 2000 23:25:22 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00688; Sun, 19 Nov 2000 00:12:45 +0100 Message-ID: <20001119001245.55209@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> <3A15DDD9.E866FB11@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A15DDD9.E866FB11@f-cpu.org>; from Yann Guidon on Sat, Nov 18, 2000 at 02:39:37AM +0100 X-Mutt-References: <3A15DDD9.E866FB11@f-cpu.org> From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 00:12:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" X-UIDL: bfa74b288d6a12f6b3d708d9debc355b Status: R X-Status: N --a8Wt8u1KmwUX3Y2C Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, Nov 18, 2000 at 02:39:37AM +0100, Yann Guidon wrote:
[hexagonal grid]
> but if each node has 3 neighbours, there's an extension of the
> cube topology that works with 16 nodes.
>
> The principle : cut one cube in two halves, then connect the 8 broken
> links to another cube, repeat with two other cubes but cut in different
> orientations, and "plug" them on the central cube. This makes something
> like 3-D cross, it's hard to make ASCII art for this one.
> i have enclosed a GIF.

That's actually a mix of squares and hexagons (although the latter have
been bent and twisted a little bit).  See the color version of your
image attached below (hexagons are red, squares are green).

> The detail to remark is that the links between the nodes of the inner cube
> are removed (otherwise, we would need more than 3 links/node). I presume that
> this transformat can be applied to itself, obtaining 64 CPU clusters...

I think it can be repeated in 1, 2 or 3 dimensions, up to any size you like :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--a8Wt8u1KmwUX3Y2C Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="topo3D-2.gif" R0lGODdhLQEtAfEAAAAAAP////8AAAD/ACwAAAAALQEtAQAC/oyPqcvtD6OctNqLs968+w+G 4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKZzCIhKp9Sq9YrNarfSpxcJGIjH 5LL5jE6r1+xB9AuHtuf0up0MEADifF/4DhgomKfXZ5jzJ6i4uEZYeAg5k8hIWekmgPkYudky afkZ6Ii5x1ma4gmaSic6aupagqoqq8ba+nr7ETu7W1ZriwucoctL7PsbjDwxTLxrfJwM3bDM LOv8HI19ME2dan2dHb3N/en9DY4sPl5Zbn6Om67OyN7u7gofrzhPX895jx+aKaBAgaT4vfvH S1+mggbtIWw2MOJAhg37PZylMCDF/oqQ/F1cJTGkRo4WP3YTiVITSUMeTbLJOHHloZYuaaVM uVHmE5o10cCMmFMnE549zfwEKvQL0aJ4bjoNmvTIUqZijkqEGpXIVKpWr2ZdspVpV69fwVCV 5zTtvrI8whYdGxIr2x1ue8KNO1fO2Xxq+6rM26Nuzbsi5QKmIdgl4cKHA+/l69ev4cYvEptc jHIyZRZcOnv+DLpK5NGaN6vAPDp1YdV9S5tGgZq17IWzn762Ebs269xkb0vSDVw2b6S+fwc/ Hnl4zOIylCN/+pw4cxjOo2e2TnB6jOrYr3ZfqJ369/EaybsOn4u8eu5r0Ytgr16Pefed4o+H f57+Bvjr/ufrP23fd/j9B2CA2A1IIGwGHuhfgibwZ16DDpIA4X0STvjegtYhiOEIFQp4YYfp afgchyKC8GF3Jp7oQYoM3sdiCC5uGGKMGswY3Yo23khiiTXueAGOPsIIJAdCIqdjkRYceVyS SlLAZHBOPilBlMBNSSUEVuqGZZYObFlbl14yAOZsYo6pQJnC/YimND0iyWabC6i5W5xyJkCn amfeGUCeqe3ZWGiCTvFmk+YNimiioP3An5+kFQppa/lxFp+jyUWKKU5uBGafpZJlCipQVbUV oKethYrqKGNMqmCpqf75KqiTsPrggqaqdeubntBKoYa5QhcrpKjwmqGvwX56/myPsRCLorLJ 4vqsrz7hpmu0wFpbaRrMdsDkrzd5m622iAmLLU7lmteIcYWCe925Kr7UHKbsrubuhm1siwGY 88ZVb45z4LukrP0CNXCTq1QW6r7eFcxlHQArg6rCBDNsph0PR5CnxBNRLNwdFz/gp8YEcawn IB+7+arI5ZGcXCgFpsyyyn8OcsqxMo/Ccmv5tBrszfLl/NQiJyNwq88+pzXV0AbkajTQmsoD i7VNOx3XOr1KHTPVV1lyMrhTa60ROcVi+zXYeoBy8bxla53Yw/uu7bRlACsMd86WbcrtwHWT fDfe+xW8N8V9+y0Mw4EDntDfhmcN9OCjFi444zEz/kPrzYe76/iq+SrKeedXxOx56KFzw6rl knOcueZBon466qTnGznfcb++OuCt8017wHrfjjs1pe8uO9u5V0A375P7Djvmxh9PefLlXu46 8rWTvbzdw0P5fPXWS697tNAzX4zzyX4PfuLT26z97NwT/yz52zd/PszBmy3q+tj3nL7w9kMc q/vqw9+9iOUPbKl7XAAFNj/6VW1/VUqV//QHQPYlbID0KyDh7pepBxLwevyTFwUVaMHfeTCB CnxaBDG4rg+WMITicxYJS2jC8MXPWC+EYWY42MBq1dCGhcEhxnTIOh7iyodacmEQhYg0IoKM RBoUIgtn2J8dIrGHDPyh/oGaiMQnHjBCUpwiFU/YwSge0YtDrGIRK6VCMqrKjEsUY+zUqDM2 fsmNi4OjZJQ4x/uIbo+KsmPL5IgyAT1mEH68IxjDeKBBAqSQZTRfC+2lSI8xspEYUZwgI2mx SSaxGUZCFyYdpsmgVbKT9/kkKEMZQ7S1yJOmvBcqU8m1EV2ylS955Q270axS0rKWtlyg2HI5 y11qq5e+tJqMWClMnxBza7Ec27uSOcxlTqSZzkwkNJUpTYIY00PIvGZTshk2qEVNl97sBTjD ubNakbOcqzrnQoTGs2eys53uPBvN4mnNeValnvY02cvkqc+jdfNg/8xnQPnZEqXNaaDlFOg6 /v9Vn4ey06HBvJcL8KNPerrzHgoNJEDnSdGP0kI8Em0oQiFK0opO9KTw2g5DvRlSg04rXiWF KUvFpS6RmrSey+hoDlW6043idFw1vWZMIWmUG2A0o5fg6Rl8ikKZrtSpvUDES416UwMq9arQ PKq/VGfVonb1plCFYomY2lShXhAHS82oV89a1kd+1a0Ijevm+IgFtOIHr3xdVDj0qkc7mcaC 4+BOHgB1GMKSTkU4IxJ6FOu7F/1MQPSBLOVoRBvHhseyxcjRyDSrHc4mZEgro6x7RAsRQ20M tNNBLUZUu1rTPhawV+IXa5nj2mrU1ray3SxtzdSu3ob2t3UKrooq/ktcWJnrtsXJrSrgMg/E Asa5J9ET0gS7GeqizbrXZa5vtEsO5XZXuK1N7njPeyDkMvUn7MUuZcDLNWTJ97inNa9xT+Xd 28B3HdASL31nu170zje99Q3wt9aU39fslxLsuIt087JgtNzXvwQGMF3pBdwED9a+mQ2TewPF 4cl6WMPZ5XBsHjyXCAttYlL6cGLNyxsUs0XFkOkwbP/rWwM3lrQ4Hq6OnSPjstCYkCLmcYVz TFfDuni6emVPkL/S1yh3hovk5dNCu3glK1txjDnS8pbf2GUvn5HLTRLzl+tYIjOf2XZpVvOY wZxlN78ZzXGWcxvJLBw7rxl4XNLznvuFqRm7sgiL0vHzneH8J0P/FNHJUfSi6UwaRz+azYmW 9J/r1RVBF4nQmt50GttjaW18utNK0iCpS63CU6May9kJ9Rb5jBNXmxXTtpH1qwH9LVvPWnmZ 0fWuz+UNVY/pcMIe9vKKbewdIjvZeF42sxHt7GdDOtrSpvRffA25I1IbTVPbNrez5u1v8y3c 3JayubGA7XSre93sbre73w3veMt73vSut73vjW8vFAAAOw== --a8Wt8u1KmwUX3Y2C-- From DuaneMHunt170976@aol.com Sun Nov 19 00:31:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03902 for ; Sun, 19 Nov 2000 09:18:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:18:59 +0100 (MET) Received: (qmail 24472 invoked by uid 0); 18 Nov 2000 23:31:20 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx10) with SMTP; 18 Nov 2000 23:31:20 -0000 X-eGroups-Return: sentto-1101623-1539-974590273-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 18 Nov 2000 23:31:18 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:31:13 -0000 Received: (qmail 91633 invoked from network); 18 Nov 2000 23:31:13 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 18 Nov 2000 23:31:13 -0000 Received: from unknown (HELO imo-d01.mx.aol.com) (205.188.157.33) by mta3 with SMTP; 19 Nov 2000 00:32:18 -0000 Received: from DuaneMHunt170976@aol.com by imo-d01.mx.aol.com (mail_out_v28.33.) id a.f8.4bbe127 (16787) for ; Sat, 18 Nov 2000 18:31:11 -0500 (EST) Message-ID: To: f-cpu@egroups.com X-Mailer: Windows AOL sub 103 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 18:31:11 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 380a9063a6ac1a0dd30c8463561efe6c Status: R X-Status: N SMART COLOURS KIDD

When a 1/4 of the WORLD IS

RED AND GREEN COLOUR BLIND
eGroups Sponsor
From DuaneMHunt170976@aol.com Sun Nov 19 00:35:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03905 for ; Sun, 19 Nov 2000 09:19:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:00 +0100 (MET) Received: (qmail 10820 invoked by uid 0); 18 Nov 2000 23:36:52 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx16) with SMTP; 18 Nov 2000 23:36:52 -0000 X-eGroups-Return: sentto-1101623-1540-974590559-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 18 Nov 2000 23:36:12 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:35:58 -0000 Received: (qmail 85844 invoked from network); 18 Nov 2000 23:35:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Nov 2000 23:35:57 -0000 Received: from unknown (HELO imo-d02.mx.aol.com) (205.188.157.34) by mta2 with SMTP; 18 Nov 2000 23:35:57 -0000 Received: from DuaneMHunt170976@aol.com by imo-d02.mx.aol.com (mail_out_v28.33.) id a.b4.d6c262b (16787) for ; Sat, 18 Nov 2000 18:35:51 -0500 (EST) Message-ID: To: f-cpu@egroups.com X-Mailer: Windows AOL sub 103 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 18:35:51 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] Well any way Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c21a464bc61595d9d4518075e22e7bc2 Status: R X-Status: N Talking about CPUs but like the guy who made SPECCYS
ITS all down to the PROGRAMERS to get it to work

ie Speccys Graphics was well better than my Sinclair
had dreamed of

this was all due to PROGRAMERS using the hardware
in ways to save and use

The Main problem with Computers is that it has to keep
asking the hard drive for data

WHAT happend to the old OS on the ROM or a RAM chip
=A355 in the UK for 128Mb PC100 haaa 8ns
i cant even think in that time zone

Why not use this in DIRECT unit with the CPU

eGroups Sponsor=
3D""
From Jeff Davies Sun Nov 19 00:37:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03908 for ; Sun, 19 Nov 2000 09:19:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:00 +0100 (MET) Received: (qmail 16736 invoked by uid 0); 18 Nov 2000 23:40:09 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx22) with SMTP; 18 Nov 2000 23:40:09 -0000 X-eGroups-Return: sentto-1101623-1541-974590806-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 18 Nov 2000 23:40:08 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:40:05 -0000 Received: (qmail 10856 invoked from network); 18 Nov 2000 23:40:05 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Nov 2000 23:40:05 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta1 with SMTP; 18 Nov 2000 23:40:04 -0000 Received: from modem-3.medroxyprogest.dialup.pol.co.uk ([62.136.88.131] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13xHaU-00032N-00 for f-cpu@egroups.com; Sat, 18 Nov 2000 23:40:03 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A154CF9.8456CAE7@llandre.freeserve.co.uk> <3A15B78D.CB6FB5C3@f-cpu.org> In-Reply-To: <3A15B78D.CB6FB5C3@f-cpu.org> Message-Id: <00111823384701.24775@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 23:37:44 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] merlot xml editor screenshot using class dtd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 98d9b2b959fec250b19b62e4e4e2ba99 Status: R X-Status: N On Fri, 17 Nov 2000, you wrote:
> hi !
>
> Jeff Davies wrote:
> > Here is merlot in action, editing a class implementation.
> > (merlot is written in java)
> <snip>
> > Jeff Davies
> > by the way this may seem off topic, but it is following the GNL concept.
>
> i still have to test this, but you seem to be optimistic,
> so it can't be completely wrong. unfortunately, i don't have time
> (yet) to work on the SW/compilation side. i may write some
> programming/compiling guidelines though. it could be integrated
> in the manual later.
>
> If you could prepare an example with files that people could test,
> it would be nice :-)

Yes, I am working on it, which means I am, every week, maybe getting 2-3 hours
to put into this kind of thing. Sometimes more sometimes less.
You know the story.

>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

eGroups Sponsor
From Jeff Davies Sun Nov 19 00:40:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03911 for ; Sun, 19 Nov 2000 09:19:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:01 +0100 (MET) Received: (qmail 8392 invoked by uid 0); 18 Nov 2000 23:53:56 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx07) with SMTP; 18 Nov 2000 23:53:56 -0000 X-eGroups-Return: sentto-1101623-1542-974591628-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 18 Nov 2000 23:53:53 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 18 Nov 2000 23:53:48 -0000 Received: (qmail 41302 invoked from network); 18 Nov 2000 23:53:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 18 Nov 2000 23:53:48 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta2 with SMTP; 18 Nov 2000 23:53:47 -0000 Received: from modem-3.medroxyprogest.dialup.pol.co.uk ([62.136.88.131] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13xHnh-0004eH-00 for f-cpu@egroups.com; Sat, 18 Nov 2000 23:53:42 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> <3A15CF43.112BD52A@f-cpu.org> In-Reply-To: <3A15CF43.112BD52A@f-cpu.org> Message-Id: <00111823522602.24775@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 23:40:28 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 02dd00b103276d524d8f7822781010cd Status: R X-Status: N On Sat, 18 Nov 2000, you wrote:
> hello,
>
> Jeff Davies wrote:
> <snip>
>
> i'm ok to say that Java looks more stable and is more constrained
> than C(++) and is safer. a good Java native compiler would do a good
> job. anyway, vectoring (and then translation to SIMD) is not automatic
> yet. F-CPU is a "raw RISC" CPU and might need a lot of support libraries,
> so the undertaking is high.

I think michael doesn't understand what I say, but you do.
Sun Java compiler compiles to bytecode for the java processor. This bytecode
can be recompiled and optimised to fit any processor.
(Including all libraries without requiring source). The libraries, however are
normally wrappers for core OS functionality. (eg X will be wrapped by swing).

If you remove manual access to pointers from C++ you get Java. However I think
it is more awkward in C++ (or C) to access hardware efficiently than in
Assembler.

I am guessing that the linux kernel could be split into parts which
can be made safe (as in rewrite in java, then compile native) and parts best
done in assembler for raw speed (multimedia codecs for example).
I think I might hunt around for a functional spec for the linux kernel (or
write one), as this is the first step to rewriting, and with a good funcspec,
you can code like lightning. I find Java 3 times as fast to write code in as
C++, so there might be some point to this train of thought.


>
> I am now constrained to only answer emails, not do "useful stuffs",
> and if i had 100 hours in a day, i'd like to make most of the f-cpu
> alone. I have to give up some dreams and concentrate on the core,
> so if i'm not happy with what others do, i do it myself when it becomes
> annoying. I think that you (jeff) are doing an interesting investigation
> and i encourage you to go on. The one who "does" something that works
> is the one who is "right", and the facts show that it's you.
>
> i'll look at http://www.merlotxml.org/ ASAP.

I'm waiting for them to reply to by bug report re XSL, but maybe I'll play some
more. (XML program -> Java -> JVM bytecode -> native bytecode).

I can't promise anything for christmas, but I will try... At worst perhaps some
screenshots?

Jeff davies
eGroups Sponsor
From Jeff Davies Sun Nov 19 00:59:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03914 for ; Sun, 19 Nov 2000 09:19:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:02 +0100 (MET) Received: (qmail 25846 invoked by uid 0); 19 Nov 2000 00:08:29 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx21) with SMTP; 19 Nov 2000 00:08:29 -0000 X-eGroups-Return: sentto-1101623-1543-974592499-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 19 Nov 2000 00:08:27 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 00:08:18 -0000 Received: (qmail 73635 invoked from network); 19 Nov 2000 00:08:18 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Nov 2000 00:08:18 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta2 with SMTP; 19 Nov 2000 00:08:17 -0000 Received: from modem-3.medroxyprogest.dialup.pol.co.uk ([62.136.88.131] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13xI1m-0006GQ-00 for f-cpu@egroups.com; Sun, 19 Nov 2000 00:08:15 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <8v4ra7+pkph@eGroups.com> In-Reply-To: <8v4ra7+pkph@eGroups.com> Message-Id: <00111900065903.24775@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 23:59:16 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fe9d738a887e2e3bb98a07252c7b37bd Status: R X-Status: N > There was a Java compiler named GCJ which can build native binary
> code from Java source code and Java byte code.It seems that only
> AWT can not be supported now.
I don't know how GCJ was implemented, but if you think about it, you can
compiler jvm bytecode classes to native INCLUDING the base classes.
You don't need ANY access to the source at all.

> The problem is the binary code builded from GCJ is a little big.  

> I think that  GCC for FCPU is not diffical to make.So we can
> rebuild the current linux kernel for FCPU,why rewrite it in
> Java ? For application, java is good,but for kernel ,C is more
> efficiency.
I have also been looking at porting GCC to FCPU. Trying to
get my head around the RTL stuff.
I am interested in this part of the project too, it just occurred to me.. how
difficult would it be to reimplement, as I have been doing a bunch of rewriting
java stuff from C++ funcspecs recently. Java uses pointers implicitly - this
means it uses them, you just can't control them manually.

Jeff Davies
eGroups Sponsor
From Yann Guidon Sun Nov 19 02:56:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03920 for ; Sun, 19 Nov 2000 09:19:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:03 +0100 (MET) Received: (qmail 6812 invoked by uid 0); 19 Nov 2000 01:51:19 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx03) with SMTP; 19 Nov 2000 01:51:19 -0000 X-eGroups-Return: sentto-1101623-1544-974598676-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 19 Nov 2000 01:51:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 01:51:16 -0000 Received: (qmail 51161 invoked from network); 19 Nov 2000 01:51:15 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Nov 2000 01:51:15 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 19 Nov 2000 02:52:21 -0000 Received: from f-cpu.org (nas4-97.ras.club-internet.fr [195.36.203.97]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA12960 for ; Sun, 19 Nov 2000 02:51:11 +0100 (MET) Message-ID: <3A173335.FE771EFB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> <3A15CF43.112BD52A@f-cpu.org> <00111823522602.24775@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 02:56:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1abe154ee54105cdfbb357c7f84f9a34 Status: R X-Status: N hi,

Jeff Davies wrote:
> On Sat, 18 Nov 2000, you wrote:
> > i'm ok to say that Java looks more stable and is more constrained
> > than C(++) and is safer. a good Java native compiler would do a good
> > job. anyway, vectoring (and then translation to SIMD) is not automatic
> > yet. F-CPU is a "raw RISC" CPU and might need a lot of support libraries,
> > so the undertaking is high.
> I think michael doesn't understand what I say, but you do.
hey, it has to be proved :-) i'm not a XML and Java guru...

> Sun Java compiler compiles to bytecode for the java processor. This bytecode
> can be recompiled and optimised to fit any processor.
that looks too good to be true... i understand the trick, but i need a demo
to be convinced ;-)

> (Including all libraries without requiring source). The libraries, however are
> normally wrappers for core OS functionality. (eg X will be wrapped by swing).
yup, but since we don't have any "platform", i wonder what will really happen
and how it will all work...

> If you remove manual access to pointers from C++ you get Java. However I think
> it is more awkward in C++ (or C) to access hardware efficiently than in
> Assembler.
sure.
Java as a front-end langage is not a bad idea, but the same can be said of Pascal
or Ada... What bothers me is the machinery behind the scene, the "RTL" optimisations
etc.

> I am guessing that the linux kernel could be split into parts which
> can be made safe (as in rewrite in java, then compile native) and parts best
> done in assembler for raw speed (multimedia codecs for example).
i don't know at all... maybe it's a bit too optimistic ?

> I think I might hunt around for a functional spec for the linux kernel (or
> write one), as this is the first step to rewriting, and with a good funcspec,
> you can code like lightning. I find Java 3 times as fast to write code in as
> C++, so there might be some point to this train of thought.
probably. but as in VHDL, we can't do without good and free tools.

> I'm waiting for them to reply to by bug report re XSL, but maybe I'll play some
> more. (XML program -> Java -> JVM bytecode -> native bytecode).
hummm, a XML to binary translator would mybe work better. less intermediate
steps, lighter and faster. i'm getting crazy when it takes 2 minutes to compile
the ROP2 unit with a "commercial tool", so please make something simple and clean :-)

> I can't promise anything for christmas, but I will try... At worst perhaps some
> screenshots?
that's better than nothing...

> Jeff davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Nov 19 02:56:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03923 for ; Sun, 19 Nov 2000 09:19:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:04 +0100 (MET) Received: (qmail 3456 invoked by uid 0); 19 Nov 2000 01:51:21 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx14) with SMTP; 19 Nov 2000 01:51:21 -0000 X-eGroups-Return: sentto-1101623-1545-974598676-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 19 Nov 2000 01:51:20 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 01:51:15 -0000 Received: (qmail 99497 invoked from network); 19 Nov 2000 01:51:15 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 19 Nov 2000 01:51:15 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 19 Nov 2000 01:51:15 -0000 Received: from f-cpu.org (nas4-97.ras.club-internet.fr [195.36.203.97]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA13922 for ; Sun, 19 Nov 2000 02:51:12 +0100 (MET) Message-ID: <3A173337.4FBB5AB2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> <3A15DDD9.E866FB11@f-cpu.org> <20001119001245.55209@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 02:56:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0cfddfa7d716e6e64ac05f464343ee56 Status: R X-Status: N hi,

Michael Riepe wrote:
> That's actually a mix of squares and hexagons (although the latter have
> been bent and twisted a little bit).  See the color version of your
> image attached below (hexagons are red, squares are green).
oh, yeah, now that i think about it, there are hexagons. funny.

> > The detail to remark is that the links between the nodes of the inner cube
> > are removed (otherwise, we would need more than 3 links/node). I presume that
> > this transformat can be applied to itself, obtaining 64 CPU clusters...
> I think it can be repeated in 1, 2 or 3 dimensions, up to any size you like :)
i think it can, too, but i need a proof :-)

i have AMAPI at home, i can import 3D DXF files. if you can make a good 3D
graphical example, i'll be happy ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Lee Salzman Sun Nov 19 02:57:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03926 for ; Sun, 19 Nov 2000 09:19:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:05 +0100 (MET) Received: (qmail 22315 invoked by uid 0); 19 Nov 2000 01:59:59 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net (mx19) with SMTP; 19 Nov 2000 01:59:59 -0000 X-eGroups-Return: sentto-1101623-1546-974599196-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 19 Nov 2000 01:59:58 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 01:59:55 -0000 Received: (qmail 10085 invoked from network); 19 Nov 2000 01:59:55 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 19 Nov 2000 01:59:55 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta1 with SMTP; 19 Nov 2000 01:59:55 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sat, 18 Nov 2000 17:59:51 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A17337C.27120D2C@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 20:57:16 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e0cbfc51f36e170505156a413b595605 Status: R X-Status: N Jeff Davies wrote:
> I am guessing that the linux kernel could be split
> into parts which can be made safe (as in rewrite in java ...

This is a much larger undertaking than you realize. I suggest
you look at Jalapeno (a Java VM written in Java at IBM Research).
You have to provide all the Java facilities within the kernel,
the main offender being garbage collection which I'd cite as one
major reason for the increased productivity you claim (there are
C/C++ GCs that work just great as well). Beyond this, you also
have to provide modules for *breaking the safety* of Java if
you realistically hope to write great portions of a kernel
in Java (such as in Jalapeno which had to provide ways to convert
between Java integers and pointers for reflection on memory and such).
Java is not necessarily a great systems programming language.
Also, 90%+ of the linux kernel code is driver code and other
unsafe things, with the actual kernel occupying only a few files
(which would be one of the few things that could possibly be "safe").

> I have also been looking at porting GCC to FCPU. Trying to
> get my head around the RTL stuff.

Before you start porting, me and Mathias *already* have an almost
functional port of GCC (and this means GCJ as well) to the F-CPU.
The only thing that is really need is an assembler which could
either be gotten from porting binutils which would be a major
hastle, or just finishing up the assembler stuff Mathias was working
on.

> Jeff Davies
                              Lee Salzman
eGroups Sponsor
From Yann Guidon Sun Nov 19 03:45:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03929 for ; Sun, 19 Nov 2000 09:19:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:06 +0100 (MET) Received: (qmail 30622 invoked by uid 0); 19 Nov 2000 02:40:56 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx21) with SMTP; 19 Nov 2000 02:40:56 -0000 X-eGroups-Return: sentto-1101623-1547-974601650-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 19 Nov 2000 02:40:54 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 02:40:49 -0000 Received: (qmail 59641 invoked from network); 19 Nov 2000 02:40:49 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Nov 2000 02:40:49 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 19 Nov 2000 03:41:54 -0000 Received: from f-cpu.org (nas4-100.ras.club-internet.fr [195.36.203.100]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA09373 for ; Sun, 19 Nov 2000 03:40:46 +0100 (MET) Message-ID: <3A173ED7.8D9071B1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A17337C.27120D2C@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 03:45:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cd0972b33c893d78bf412c54cb4d0896 Status: R X-Status: N hi !

Lee Salzman wrote:
> > I have also been looking at porting GCC to FCPU. Trying to
> > get my head around the RTL stuff.
> Before you start porting, me and Mathias *already* have an almost
> functional port of GCC (and this means GCJ as well) to the F-CPU.
> The only thing that is really need is an assembler which could
> either be gotten from porting binutils which would be a major
> hastle, or just finishing up the assembler stuff Mathias was working
> on.

hello,

is the compiler able to output asm files ?
in this case, i can make an assembler. i have all the parts necessary,
it's not "binutils-compatible" but it's easy to use without GCC.

why has the GCC work stopped, by the way ?

regards,
> > Jeff Davies
>                                         Lee Salzman
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Lee Salzman Sun Nov 19 03:55:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03932 for ; Sun, 19 Nov 2000 09:19:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:06 +0100 (MET) Received: (qmail 18467 invoked by uid 0); 19 Nov 2000 02:58:48 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx09) with SMTP; 19 Nov 2000 02:58:48 -0000 X-eGroups-Return: sentto-1101623-1548-974602709-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 19 Nov 2000 02:58:44 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 02:58:29 -0000 Received: (qmail 97730 invoked from network); 19 Nov 2000 02:58:27 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Nov 2000 02:58:27 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta3 with SMTP; 19 Nov 2000 03:59:33 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sat, 18 Nov 2000 18:58:23 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A174135.69AD68B9@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 21:55:49 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f498d0fd0e9d1516b402ebc30e18995b Status: R X-Status: N Yann Guidon wrote:
>hello,
>
>is the compiler able to output asm files ?
>in this case, i can make an assembler. i have all the parts necessary,
>it's not "binutils-compatible" but it's easy to use without GCC.
>
>why has the GCC work stopped, by the way ?

Well, in a manner of speaking, the compiler is able to output assembly.
Things that need to be resolved at the moment, though:

1) Loading large constants into registers
2) Correct handling of conditional jumps
   (Need to write some code to map the condition code register to an   
    allocated register.)
3) symbol/relocation conventions
   (If the ability to link multiple object files is desired, which would
    in turn require a lot of binutils hackery, this is necessary. So
ATM,
    this is probably not desirable to worry about at all.)

As for why it stopped, Mathias migrated across Europe somewhere and was
not available for months, but recently started showing up on IRC again,
so we can probably coordinate something.

> WHYGEE

                        Lee Salzman
eGroups Sponsor
From Yann Guidon Sun Nov 19 04:45:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03935 for ; Sun, 19 Nov 2000 09:19:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:07 +0100 (MET) Received: (qmail 13836 invoked by uid 0); 19 Nov 2000 03:41:37 -0000 Received: from ml.egroups.com (208.50.144.77) by mx19.rz2.gmx.net (mx19) with SMTP; 19 Nov 2000 03:41:37 -0000 X-eGroups-Return: sentto-1101623-1549-974605295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 19 Nov 2000 03:41:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 03:41:34 -0000 Received: (qmail 34972 invoked from network); 19 Nov 2000 03:41:34 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Nov 2000 03:41:34 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 19 Nov 2000 03:41:34 -0000 Received: from f-cpu.org (nas4-100.ras.club-internet.fr [195.36.203.100]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA23322 for ; Sun, 19 Nov 2000 04:41:08 +0100 (MET) Message-ID: <3A174CC1.1BE6B019@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A174135.69AD68B9@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 04:45:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e62fd4a744351d8b834c74df050d8c79 Status: R X-Status: N Lee Salzman wrote:
> Yann Guidon wrote:
> >hello,
> >
> >is the compiler able to output asm files ?
> >in this case, i can make an assembler. i have all the parts necessary,
> >it's not "binutils-compatible" but it's easy to use without GCC.
> >
> >why has the GCC work stopped, by the way ?
>
> Well, in a manner of speaking, the compiler is able to output assembly.
cool :-)

> Things that need to be resolved at the moment, though:
>
> 1) Loading large constants into registers
i had made a code that does that.

> 2) Correct handling of conditional jumps
>    (Need to write some code to map the condition code register to an
>     allocated register.)
that's GCC dirty stuffs... i hope you'll do a good job.

> 3) symbol/relocation conventions
>    (If the ability to link multiple object files is desired, which would
>     in turn require a lot of binutils hackery, this is necessary. So ATM,
>     this is probably not desirable to worry about at all.)

if the asm output is ok, then the assembler is necessary, right ?

> As for why it stopped, Mathias migrated across Europe somewhere and was
> not available for months, but recently started showing up on IRC again,
> so we can probably coordinate something.

please speak about what's going on. i can't come on IRC.
if you do something, or if you need help, please talk about
it on the mailing list !


Oh, another request : can you make a bundle of the working code ?
i'll put it on f-cpu.de. i think that the code at sourceforge is
incomplete : only the configuration files are provided, we need
more files to get the compiler compiled ...


> > WHYGEE
>                                 Lee Salzman
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Nov 19 07:56:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA03938 for ; Sun, 19 Nov 2000 09:19:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 19 Nov 2000 09:19:08 +0100 (MET) Received: (qmail 12042 invoked by uid 0); 19 Nov 2000 06:51:44 -0000 Received: from c9.egroups.com (208.50.99.230) by mx11.rz2.gmx.net (mx11) with SMTP; 19 Nov 2000 06:51:44 -0000 X-eGroups-Return: sentto-1101623-1550-974616699-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 19 Nov 2000 06:51:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 06:51:38 -0000 Received: (qmail 97937 invoked from network); 19 Nov 2000 06:51:37 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 19 Nov 2000 06:51:37 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 19 Nov 2000 07:52:42 -0000 Received: from f-cpu.org (nas3-53.ras.club-internet.fr [195.36.203.53]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA22070 for ; Sun, 19 Nov 2000 07:51:34 +0100 (MET) Message-ID: <3A17799D.9AE8180E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 07:56:29 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4feb2a1dafc9bfcb86dee64c4c8411c1 Status: R X-Status: N hello,
i'm putting together a new bundle for the available f-cpu vhdl files.

I have finally read Michael's iadd file and i must say that i have been
impressed, really :-) I have the intention to recode the ROP2 unit the same
way, because it helps find the critical datapaths easily. The provided
gate library is good, too, because it corresponds more or less to the
available technologies and helps concentrate on the design complexity.
I encourage everybody willing to write F-CPU VHDL to reuse the style
of iadd.vhdl. I know, it's like writing SW in assembly langage, but
it runs so fast :-)

One suggestion, though (that's for Michael) :
your adder is stuck to 64 bits, that's ok. I don't think there is any need
(yet) for a 128-bit adder (or more). But we will certainly need a SIMD version,
and the extension is straight-forward.
Could you please make a file, named (for example) ASU.vhdl, that contains
a simple if-generate and for-generate, so we can generate a 32-bit adder
or multiple 64-bit adders, depending on the value of UMAX ...

if UMAX = 32 then generate (iadd(32))
else for i = 0 to UMAX / 64 do generate (iadd(64))...

that would be a good and easy thing.


One last thing to remember : in the execution pipeline, the data pass through
the Xbar between the R7 read and the first execution cycle. This gives enough
time to propagate and duplicate some signals, and particularly those with a big
fanout (1->64). a signal tree of 2 or 3 gates of depth is possible, some
pre-decoding is possible as well (ie : size or function lookup table).
I'll try to redesign the ROP2 unit and take this into account.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sun Nov 19 01:41:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00607 for ; Mon, 20 Nov 2000 00:55:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:55:45 +0100 (MET) Received: (qmail 7183 invoked by uid 0); 19 Nov 2000 15:14:05 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx14) with SMTP; 19 Nov 2000 15:14:05 -0000 X-eGroups-Return: sentto-1101623-1551-974645771-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 19 Nov 2000 14:56:47 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 14:56:11 -0000 Received: (qmail 42683 invoked from network); 19 Nov 2000 12:59:12 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 19 Nov 2000 12:59:12 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.66) by mta1 with SMTP; 19 Nov 2000 12:59:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01039; Sun, 19 Nov 2000 01:41:36 +0100 Message-ID: <20001119014136.01803@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> <3A15CF43.112BD52A@f-cpu.org> <00111823522602.24775@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00111823522602.24775@tiglath.pileser.sumeria>; from Jeff Davies on Sat, Nov 18, 2000 at 11:40:28PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 01:41:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ed22ff8a8db69d189e37435bc795ae3 Status: R X-Status: N On Sat, Nov 18, 2000 at 11:40:28PM +0000, Jeff Davies wrote:

> I think michael doesn't understand what I say, but you do.

I really hope I didn't understand, but...

[...]
> I am guessing that the linux kernel could be split into parts which
> can be made safe (as in rewrite in java, then compile native) and parts best
> done in assembler for raw speed (multimedia codecs for example).
> I think I might hunt around for a functional spec for the linux kernel (or
> write one), as this is the first step to rewriting, and with a good funcspec,
> you can code like lightning. I find Java 3 times as fast to write code in as
> C++, so there might be some point to this train of thought.

Why the heck do you want to rewrite the Linux kernel?
Please enlighten me.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Lee Salzman Sun Nov 19 21:22:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00646 for ; Mon, 20 Nov 2000 00:55:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:55:55 +0100 (MET) Received: (qmail 1512 invoked by uid 0); 19 Nov 2000 20:25:09 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx05) with SMTP; 19 Nov 2000 20:25:09 -0000 X-eGroups-Return: sentto-1101623-1552-974665501-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 19 Nov 2000 20:25:07 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 20:25:01 -0000 Received: (qmail 89185 invoked from network); 19 Nov 2000 20:24:58 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 19 Nov 2000 20:24:58 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta2 with SMTP; 19 Nov 2000 20:24:58 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sun, 19 Nov 2000 12:24:56 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A18367E.F51B4E28@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 15:22:22 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] The F-CPU-over-GCC 'What letter comes before alpha?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c0692cbdde06014d54ad001c5a3feacd Status: R X-Status: N To any and all interested:

http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz

This is not for the faint of heart and requires
signifigant knowledge of gcc build system to get running,
nor does it even completely work at the moment (there
is a strange bug where GCC is trying to do reloads of
VOIDmode calculations and such, need to track it down
still or someone else perhaps could *hint, hint*).

Other glaring problems:

1) GCC can't seem to understand there's no such thing
   as a PC-relative jump on F-CPU except via calculating
   target address and jumping indirectly.

2) Lots of glaring peepholes in the output code due to
   considerably simplistic machine description.

                        Lee Salzman
eGroups Sponsor
From Jeff Davies Sun Nov 19 22:43:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00661 for ; Mon, 20 Nov 2000 00:55:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:55:58 +0100 (MET) Received: (qmail 16226 invoked by uid 0); 19 Nov 2000 21:45:04 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx03) with SMTP; 19 Nov 2000 21:45:04 -0000 X-eGroups-Return: sentto-1101623-1553-974670295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 19 Nov 2000 21:45:02 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 21:44:54 -0000 Received: (qmail 95479 invoked from network); 19 Nov 2000 21:44:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 19 Nov 2000 21:44:54 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta2 with SMTP; 19 Nov 2000 21:44:53 -0000 Received: from modem-132.iowa.dialup.pol.co.uk ([62.137.66.132] helo=tiglath.pileser.sumeria) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13xcGY-0006wX-00 for f-cpu@egroups.com; Sun, 19 Nov 2000 21:44:50 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A154B07.5E7BED6@llandre.freeserve.co.uk> <00111823522602.24775@tiglath.pileser.sumeria> <20001119014136.01803@thrai.stud.uni-hannover.de> In-Reply-To: <20001119014136.01803@thrai.stud.uni-hannover.de> Message-Id: <00111921485200.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 21:43:08 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7f2c6c9f33c7f4f1e7376702af0b0a85 Status: R X-Status: N On Sun, 19 Nov 2000, you wrote:
> On Sat, Nov 18, 2000 at 11:40:28PM +0000, Jeff Davies wrote:
> Why the heck do you want to rewrite the Linux kernel?
> Please enlighten me.

With C Sharp on the horizon, you can bet M$ will be saying that Linux kernel
etc is unsafe.. blah blah blah
And, I don't Linux kernel is as resilient as say QNX, and if it is, maybe it
isn't as demonstrably resilient (in an auditing sort of way)..

I just thought that maybe by following the
kernel-source -> functional spec -> Java (aka safe C++) would probably not be
such a huge task, since removing the need to consider pointers speeds up coding
by a factor of 3 typically.

Anyway, no need to keep this thread alive, just an idea I will try to follow at
some time.

Jeff Davies
eGroups Sponsor
From Jeff Davies Sun Nov 19 22:49:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00664 for ; Mon, 20 Nov 2000 00:55:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:55:59 +0100 (MET) Received: (qmail 3058 invoked by uid 0); 19 Nov 2000 21:51:50 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx05) with SMTP; 19 Nov 2000 21:51:50 -0000 X-eGroups-Return: sentto-1101623-1554-974670699-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 19 Nov 2000 21:51:47 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 21:51:39 -0000 Received: (qmail 93274 invoked from network); 19 Nov 2000 21:51:39 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Nov 2000 21:51:39 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta3 with SMTP; 19 Nov 2000 22:52:44 -0000 Received: from modem-132.iowa.dialup.pol.co.uk ([62.137.66.132] helo=tiglath.pileser.sumeria) by cmailg6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13xcN6-0004A0-00 for f-cpu@egroups.com; Sun, 19 Nov 2000 21:51:37 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A18367E.F51B4E28@lvdi.net> In-Reply-To: <3A18367E.F51B4E28@lvdi.net> Message-Id: <00111921553801.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 21:49:56 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'What letter comes before alpha?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bd516c40a39a88f3452ce9cc1116bc7a Status: R X-Status: N On Sun, 19 Nov 2000, you wrote:
> To any and all interested:
>
> http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz
>
> This is not for the faint of heart and requires
> signifigant knowledge of gcc build system to get running,

No shit - the only doc I've read on porting so far was as readable as a EULA.
Any references to good GCC port guides?

Again we really need to have a CVS site, anyone got an on-line Linux box to put
pserver on? And IRCs should post to the mail discussion once in awhile.

Alternatively, can we get space on Sourceforge?? anyone know how to?

Suggested areas:

1. documentation including FCPU spec, and financial models <including contact
details as to how to get some built>

2. VHDL including the all-important Processor level VHDL which specifies the
interconnection of the component parts like regfile, cache and Execution Units.
[this should be easy from the

3. Code :
  a:   GCC
  b:   Simulator


Jeff Davies

>                         Lee Salzman
>

eGroups Sponsor
From Michael Riepe Sun Nov 19 16:40:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00685 for ; Mon, 20 Nov 2000 00:56:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:56:05 +0100 (MET) Received: (qmail 29575 invoked by uid 0); 19 Nov 2000 22:55:04 -0000 Received: from ml.egroups.com (208.50.144.77) by mx11.rz2.gmx.net (mx11) with SMTP; 19 Nov 2000 22:55:04 -0000 X-eGroups-Return: sentto-1101623-1555-974674493-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 19 Nov 2000 22:55:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 22:54:52 -0000 Received: (qmail 54862 invoked from network); 19 Nov 2000 22:54:50 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 19 Nov 2000 22:54:50 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta2 with SMTP; 19 Nov 2000 22:54:47 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA08222; Sun, 19 Nov 2000 16:40:23 +0100 Message-ID: <20001119164023.13141@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A17799D.9AE8180E@f-cpu.org>; from Yann Guidon on Sun, Nov 19, 2000 at 07:56:29AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 16:40:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2d32b61987664ea99bb40183a754878 Status: R X-Status: N On Sun, Nov 19, 2000 at 07:56:29AM +0100, Yann Guidon wrote:

> One suggestion, though (that's for Michael) :
> your adder is stuck to 64 bits, that's ok. I don't think there is any need
> (yet) for a 128-bit adder (or more). But we will certainly need a SIMD version,
> and the extension is straight-forward.

The problem is that wider adders will need more stages, so I will have
to re-balance several trees...

If you need a generic adder *without* SIMD capabilities -- I have made
a fast carry-increment adder (3+2*<n> gates for up to 4**<n> bits) that
scales automagically (you only specify the width); I still have to figure
out how to add automatic pipelining, though (insert registers every <n>
gates or something like that).

> Could you please make a file, named (for example) ASU.vhdl, that contains
> a simple if-generate and for-generate, so we can generate a 32-bit adder
> or multiple 64-bit adders, depending on the value of UMAX ...
>
> if UMAX = 32 then generate (iadd(32))
> else for i = 0 to UMAX / 64 do generate (iadd(64))...
>
> that would be a good and easy thing.

No problem.  We need a `wrapper entity' anyway to include the F-CPU
specific stuff I left out (intentionally -- I prefer reusable components).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sun Nov 19 16:12:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00688 for ; Mon, 20 Nov 2000 00:56:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:56:06 +0100 (MET) Received: (qmail 29645 invoked by uid 0); 19 Nov 2000 22:55:07 -0000 Received: from ml.egroups.com (208.50.144.77) by mx11.rz2.gmx.net (mx11) with SMTP; 19 Nov 2000 22:55:07 -0000 X-eGroups-Return: sentto-1101623-1556-974674496-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 19 Nov 2000 22:55:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 22:54:56 -0000 Received: (qmail 67533 invoked from network); 19 Nov 2000 22:54:55 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 19 Nov 2000 22:54:55 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta2 with SMTP; 19 Nov 2000 22:54:53 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA08139; Sun, 19 Nov 2000 16:12:46 +0100 Message-ID: <20001119161246.17586@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17337C.27120D2C@lvdi.net> X-Mailer: Mutt 0.84e In-Reply-To: <3A17337C.27120D2C@lvdi.net>; from Lee Salzman on Sat, Nov 18, 2000 at 08:57:16PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 16:12:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0756db7ceccbcd2ba4a481501015967a Status: R X-Status: N On Sat, Nov 18, 2000 at 08:57:16PM -0500, Lee Salzman wrote:

> Before you start porting, me and Mathias *already* have an almost
> functional port of GCC (and this means GCJ as well) to the F-CPU.

Where?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Mon Nov 20 00:01:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00691 for ; Mon, 20 Nov 2000 00:56:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:56:06 +0100 (MET) Received: (qmail 27286 invoked by uid 0); 19 Nov 2000 22:57:30 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx23) with SMTP; 19 Nov 2000 22:57:30 -0000 X-eGroups-Return: sentto-1101623-1557-974674618-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 19 Nov 2000 22:57:05 -0000 X-Sender: yguidon@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 22:56:57 -0000 Received: (qmail 72496 invoked from network); 19 Nov 2000 22:56:56 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 19 Nov 2000 22:56:56 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 19 Nov 2000 23:58:02 -0000 Received: from april.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA13167 for ; Sun, 19 Nov 2000 23:56:52 +0100 (MET) Message-ID: <3A185BD5.1F9A20B6@april.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A18367E.F51B4E28@lvdi.net> <00111921553801.01164@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 00:01:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'What letter comes before alpha?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 845b5f141cabbe39b8cf283e3ae45eb0 Status: R X-Status: N hi,

Jeff Davies wrote:
> On Sun, 19 Nov 2000, you wrote:
> > To any and all interested:
> > http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz
> >
> > This is not for the faint of heart and requires
> > signifigant knowledge of gcc build system to get running,
>
> No shit - the only doc I've read on porting so far was as readable as a EULA.
> Any references to good GCC port guides?

i've found (one day) PGCCFD ("Porting GCC For Dummies").
it should be available on the web somewhere. At the time,
the PDF version i had found couldn't be diplayed by Acroread 3...
but it's an old story now.

> Again we really need to have a CVS site, anyone got an on-line Linux box to put
> pserver on? And IRCs should post to the mail discussion once in awhile.

GCC is already on sourceforge, it's up to Mathias and Lee.
As for IRC<->ML, it's certainly very important :-)

> Alternatively, can we get space on Sourceforge?? anyone know how to?
Could this side of the project be reactivated by their maintainers ?
please ? :-)

> Suggested areas:
>
> 1. documentation including FCPU spec, and financial models <including contact
> details as to how to get some built>
well, we must have a functioning f-cpu source, before we can synthesise it
and even consider to sell it. I'm still waiting for the new version of the manual.
Sven will come from vacations on the 25 i believe... and he could maybe
setup some individual passwords on f-cpu.de. maybe.

> 2. VHDL including the all-important Processor level VHDL which specifies the
> interconnection of the component parts like regfile, cache and Execution Units.
> [this should be easy from the
>from the what ? :-)

plan for my side : collect and maintain a coherent bundle of VHDL files,
first : the execution units, second : memory-related units, third :
general schedulign and instruction decoding. we're still at stage 1, but
things seem to go well.

> 3. Code :
>   a:   GCC
>   b:   Simulator

i hope that something similar to GNL will appear one day, because
i don't want to program "the old way" anymore, i'm so bored of
endless code lines...

> Jeff Davies
> >                               Lee Salzman
WHYGEE (the other)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Michael Riepe Sun Nov 19 16:11:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00694 for ; Mon, 20 Nov 2000 00:56:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 00:56:07 +0100 (MET) Received: (qmail 24430 invoked by uid 0); 19 Nov 2000 22:58:08 -0000 Received: from hj.egroups.com (208.50.99.212) by mx19.rz2.gmx.net (mx19) with SMTP; 19 Nov 2000 22:58:08 -0000 X-eGroups-Return: sentto-1101623-1558-974674623-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 19 Nov 2000 22:57:13 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 19 Nov 2000 22:57:02 -0000 Received: (qmail 11108 invoked from network); 19 Nov 2000 22:57:02 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Nov 2000 22:57:02 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta2 with SMTP; 19 Nov 2000 22:55:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA08132; Sun, 19 Nov 2000 16:11:05 +0100 Message-ID: <20001119161105.34503@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <00111707062402.00283@dilbert> <3A150C5B.66DEBAFD@f-cpu.org> <001701c0509b$7de73030$29e65982@student.utwente.nl> <3A15CF57.F0B8DC0B@f-cpu.org> <20001118014931.58916@thrai.stud.uni-hannover.de> <3A15DDD9.E866FB11@f-cpu.org> <20001119001245.55209@thrai.stud.uni-hannover.de> <3A173337.4FBB5AB2@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A173337.4FBB5AB2@f-cpu.org>; from Yann Guidon on Sun, Nov 19, 2000 at 02:56:07AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 16:11:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] so much answers, so little time Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" X-UIDL: 21cf2767b74fc6e515864007fb5a474c Status: R X-Status: N --HcAYCG3uE/tztfnV Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, Nov 19, 2000 at 02:56:07AM +0100, Yann Guidon wrote:

> > I think it can be repeated in 1, 2 or 3 dimensions, up to any size you like :)
> i think it can, too, but i need a proof :-)

Cut off the ends of the `cross' and put them together.

> i have AMAPI at home, i can import 3D DXF files. if you can make a good 3D
> graphical example, i'll be happy ;-)

Here's a picture of a cluster of 160 nodes, straight out of POVray...
no DXF, sorry.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--HcAYCG3uE/tztfnV Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="3d.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD//gBICgpDUkVBVE9SOiBYViBWZXJzaW9uIDMuMDEgIFJl djogMy8zMC85MyAgUXVhbGl0eSA9IDkwLCBTbW9vdGhpbmcgPSAwCv/bAEMAAwICAwICAwMD AwQDAwQFCAUFBAQFCgcHBggMCgwMCwoLCw0OEhANDhEOCwsQFhARExQVFRUMDxcYFhQYEhQV FP/bAEMBAwQEBQQFCQUFCRQNCw0UFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFP/AABEIAd8B8QMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAA AAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE xcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAA AAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP1Toooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAorkPiT8TtJ+GmlRT3zifULosljpyOBJcuMZx12ouV3PjC5HVmVW8/sfjR4mu3+0Gx0tb Uybvs4WTzPLz93fvxuxxu24zzt7V8bnXF2T8P1Y0cdVtJ9Em7Lu7bfn5HRToVKqvFHt9FfOn xV/bx+GHwW0aGXxTNqseuSwrLHodhp0s0s37wI4jmYJAdud5DSKduOAWCn44+JX/AAWQ8Sz6 mE8A+BNJ03TopplM/iSWW7luYtw8lvLhaIQttDFl3yjLABvly36zw/w1mfE+Fp4/LKfNQmrx m2oxa8m7X100Ts7p2s7cFWtChJxm9V0PvPxx8dls/ER0LwqbPUbyzlKahczhpIYmGQYV2suZ AfvHOFI24Lbtk/hz4xXMWpiLxMLK1sZgFjvLdWjWF/8AppuZvlPHzcbcc8Elfw3n/aV+KGte M01iLxfq767dXnniLTyIkuLh5TJzbxKI5CzsflKEEELgjAr7n+PvxO8ReIP2ZtTQxQW3iy70 eBL+0sxGUQsIxdxoCWBGzzQMFmPUEtgn8j424b4p4S4iyyFbNKDp4qqoOKvy0480YuU7pNxS ldyVrNPbS/fhq1DEUp2g7xV/X0P05or+fPwz8Evj54M1u21nw/8ADX4l6FrFtu8jUNN0HULe 4i3KUbbIkYZcqzKcHkEjoas+Mvjn+0L8OdUi03xZ43+KHhfUZYRcR2etatqVpM8RZlEgSR1J UsjDdjGVI7Gv6hfh1g6k+XDZtSl6qz+5Sl+Z4v1uS+Kmz+gOiv53x+1f8XSP+SueOf8Awpb3 /wCO17T8Gfib+1vdK3iHwh4n8YapBPCYFk13UEvIHRtj744r5mQ9FxIq5wWAbBYV5uZ8CYTK aH1jGZxhqUdk6k/Zxv25mXDFSqO0abfpqftvRX4leL/2+/2pvAOtyaR4i8Y3ejajHk+Rd+H9 OQsoYrvQ/ZsOhKsA6kqccE1R03/gon8YNfuRYeNvG99qnhedSt7Y2GlWMElwn9zfHHGwUnG4 BsMMqQVYisK/h1mn9nzzDA16OISi5RVOcpOel0oWhZuWyd7a3bS1GsZDnUJJr16fifsDN8dP CxvIYbKa61WNpWilurOAmGHawUsWYrvXqQY9+QpIzkZ7DQPEeneKLD7bplyt1bh2jJCsrKw6 hlYAg9DyOQQRwQa/L/8AZu/be0/4h+PdO8G3vhGXRzewTfZ7yG/W4HmRxNIA6mNMKVRuQScg DHJI+uvhT42hsPjDp2nQ7nXWYZrV0WYqqskbTLIV6MQImUdMeYxB6g/yrXznivhzienkHFWC jRdVKUVFqTSk3GL5oTnFpyi01e6eui0PcVOhWourQle39eR9MUUUV+rnCFFFFABRRXK/FHx/ b/C/wJqnia5tJb+OyEarbQsFMjySJEgLH7q7nXJ5IGSAxAByq1YUacqtR2jFNt+S1Y0ruyOq or4a074z6B4n8Wadofi/xvp994suQFhsr+7ijKuwiUIsY2pE774iEAUvyQGwxHprftD6D8B4 Ip/GeuJYeEZGEAnuBJM9s+w7FiRFZ3B2gbFHABbgK2fzTLuN5Y/OMPlLwFWH1hpUpOLbqXdk 1FLVN6Jxcl+NuyeG5abnzLTfyPpiivmf/h5J+zn/ANFEP/gj1L/5Hqxpf/BRX9njV9TtLCD4 jQxz3UyQRvdaXfW8SszBQXlkgVI1yeXdgqjJJABNfusuGM9grywFZL/r3P8A+RPM9tS/mX3o +kKK8z/4ae+Dn/RWfA3/AIUln/8AHaQ/tP8AwbH/ADVrwN/4Uln/APHa815Xj1/zDz/8Bl/k Xzx7nptFcL4a+PPwz8Z63baN4f8AiJ4T13WLnd5Gn6ZrdtcXEu1S7bY0cs2FVmOBwFJ6Cu6r irUKuHlyVoOL7NNfmUmnsFFcP8Tvi1pfwwj0+O7t7m+1HUvNFna264DGNQWZ3PCKC0YPVvny FYBscXZ/GbxLdP8AaDY6YtqZN3kBZPM8vP3d+/G7HG7bjPO3tXwudcYZNkFZUMdVtN9Em7eb tt+fkdNPD1KqvFHtlFYPgvxfbeNNFF9BE9vJG5huIH58qUAEqGwAwwwII6gjIByBvV9XhsTR xlGGIw8lKEkmmuqZhKLi7MKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRXlHxV/ar+EnwTuJLXxj480nS9RimSCXTYXa7vYWePzEMltAry opTB3soX5l5+Zc9WGwmIxtT2OGpynLtFNv7ldkykoq8nY6Txf8WdA8HXsdjNK+o6iZNkljp5 SSaAbQ26QFgEBDLgE5O4EAgEinYfGvQLq7SK5ivdLjfGLm8iURbiwABKM23rncQFAByRX5h+ GP8AgoBok3iqwuNfs9WvH1Gdjq2tXmwNASAFdYkLb0HQqu3YqjYrYC19qahq9nLp6gPuJT5w wAAOTwOeRjHPFfg3G+d8b8F4+i8ywHsKNW7pqaV5Ri+WWqlpJXTcdGk4u3K036eGp4bExfJK 7W9j6nor8mfhl/wV18R+DNPutN1rwBp+vabE+NMW21SW1nt4t7nZNI6SiXCsiqVWIAIeCCAv af8AD6D/AKo8P/Cn/wDuOv63h4ccVuEXPCJNpNpVKbs2rtX5lez0vaztpoeE8ZQv8X4M91/b U8RX2gfEbwF9rayXRZrS7+yFd/2n7QHi8/fn5dm02+zHOfMzxtrM0D4iW400qHjIYDJIBI+h 7V82fFL/AIKXeEf2hPDaeFvGfw21Xw5pyzG8t9b0TW1vbqwukjcRSLbvFAkykuUZGkX5HYgh gpHgJ/abGlz3FvYPf3likjLb3FzAkMskYJ2s8YkcKxGCVDMAeMnrX4Dxz4F8XZnj3iaWClLm S2cZWsrbqT7HqYbM8PCNnIoftt+NNS17466lbahcTvpVnDCNMhkXbGsbRIZGTgBsybwW5OV2 5wgA8CNxbv1Cmv0x+AH/AAUB+B3wL0jUh/ZvxA1/XtVdGv8AVJNMs4VkSMv5MaRfbWCKokfn JZmdiTjaq+uar+0l+wtruqXmpalYeCtR1G9me4uby78BTSzTyuxZ5HdrIlmZiSWJJJJJr+u+ Esy4m4U4ewOSV8klahTjD3IOSbiknJ8sbKUn70n1k27vVng14Ua9WVRVN3fU/JnT/iTqelaV plhYtp9lFpzSNDNbaZax3Dl33EzTrGJJsH7vms2wcLtHFdN4f/aQ8e+Gdf0/WdP8QhdQsJRN bSXFlbTpHIAcPskjZCwPIJB2kBhggEfaf7X3xb/ZH8Wfs7eK9K+F+k+EoPHNwbP+z5NM8GvY XA23kDS7ZzaoE/dLJn5hkZHOcHzz9lH9lbwve6ZZeIPFmmQavqFwBLFZ3UZMFujKRtaM8OxD ZO8EAgYAI3HzOLOMOGuGcqnxDxJkVONZz5YQnQj7WpKybacoKyj1k3psrtpO6GHrVp+yo1Xb rrojlfDP/BUH4/6FrdtfXvi2x8RWsW7fpmp6PapbzZUqNxgjikGCQw2uvKjORkHuh/wWD+MJ /wCZc8C/+AF5/wDJdfR/iL9lT4U+IvD81lN4G0O2jlAzLYWaWswwQRtkiCuORzg8jIOQSK1v A/7AP7NvxN8K6nbR+A5dD1uFWtZ5rLX755bd2Q7LiJZJ3XGclRIjLuRgQ4U5/N+GPGzgLi7E Sw8sl9lVWytFJpdVytK66q17bN627K2XYrDq/tLo+fPAn/BUH4s/FDXx4bvdK8JaZZX0EsU1 5ptteQ3UKlCoeJzcsFcEgg4OMZr6T+G91YR2VtEWSGL5QWAztHrgVyGr/wDBJnwR4I0XUdb8 B+JvGFx4ts7aSXT7TU7y0ktrqUDIhcLBFw+NoYuApIY5C4Pi+jfFm/8ABd3Jo/iKyvNC1e2C iax1KF4Jo8qGXcjgEZVgRkcgg96/A/HDCUOIMxpYjJqPs8OoJKKT+K7cm9Xq9Ne1l0PUy2Tp QaqO7uemftieCdH+IPwj1hZ7eSe+06GTULA22fMFxHG+0ADO7cCVK4OQ3GDgj5R+C3/BNX43 fF280+fVNC/4V94cuMvLqXiP91cIizCN1WzB8/zMb3VZFjRgn+sUMpP158EYtX+PXxB0WG20 ue78J2t352qalNaebY7ItsjWzliEdpMxoUBZgsu4qVU1+hFfV+D+fcQcJ8PVstjK1Oc+aN7t xurS5U9k3Z9r38zDMKVKvVU+tj8H7XQNO/Y8+M+v6H4oY3XjDRlW2MsSGeGMSRrIJYSE48yN 0IydwVyrAEsK/T79i34bay+jW3xQ128MTeIdLT+ytLiYMq2UxjmWeU4/1jhUKoCNik7ss22P 8z/+CkX/ACe38S/rpv8A6bLWv2D/AGXP+TZfhH/2KGkf+kUVfqnE3BODoUcBxXiK9Stia61c 2mo6XtGyVlq7LbW++pw0cTJuVBJKK7Hp9FFcH4i+NHhzw/q66ajzavdDeJhpnlyrbMrbSkhL gBshhtGSNpyBkZ+Cx2YYTLaTr4yooR7t2OuMJTdoq53lcN8ZPiOPhh4Jl1SKOKfUp5ks7CCc P5bzvk/NtHRUV3Iyu7Zt3AsDVjQfipouu3yWmLnT55WVIReIFErHPAZWYA8Y5IySAMmvm/8A b+1CfQ9X+GWpm3lNgkmoW8t2EJijkcWzRozdAzCOQgHkhGx0NeDjM7o4rKK+NymrGo0mk4u9 ntr2avez/I0jTcaijUVjorXxZ4j8WzNfX2v30EkgIENhcPbRRrkkKFQjOM43NlsAZJxXz1/w UM+LPxXh+Dx0/TtVsI/CbzwnV7mCAw6llZt0WJQ+zyjJ5QIjRXBRfmZWcDrfB/xPihtEaO4K EoVJVsEgjBH0IJFfO/7fHjWLW/hnpUMZMnlavFK+0Z2r5My5PoMsB+Ir8h8KcyzdceYGGMr8 1KrU5aiqrng4v+62lzfyvTldt1eL78dCn9Vk4rVLS2jPj34aeEtZ8WeKtL/sy6l0SOOdZhrQ LJ9l2Et5iEEEuCvG0j5toJXOR97/ABB+F/ir9tiy/wCER8EXemW1zpMyapdXurvNHaou14lj MkUUmJGMhKqQMiOQg/Ka/NwarEe4pw1GBuu2v9IeIOA3xJxHguIamdwhLCNulFUVpzb3k6t3 suiStok22/kKWK9jRlSVN+9vr/wD7mH/AASA+Nw/5mbwF/4ML3/5DrhPE3/BMn9o3QNcubCx 8IWHiS1i27NU0vWrRLebKhjtFxJFKNpJU7kXlTjIwT5EP2rvi8f+at+OP/CkvP8A47Th+1V8 Xj/zVvxz/wCFLe//AB2vuqOF4pi7rN6MvWL/AEsczlQf/LtnpI/4Jw/tLf8ARND/AOD3TP8A 5Jqvqn/BPP8AaP0bS7y/uPhjcyQWkLzyJaapYXEzKqliEijnZ5GwOERSzHAAJIFc54O/bZ+N 3gfVJb/Tfin4kuZ5ITAyaxenU4QpZWyIrrzEVsqPnChgCQDhiD2Q/wCClf7RJH/JRv8Ayiab /wDI9dDp8bxn+5xuGlHz50/uSf5k3w3WMvwPKx+zf8Zz1+D/AI9/8Ji9/wDjVaHhf9mD4peI /EK6PdeDNU8M3GwStJ4ks5dPVUO4KwWRA7AlGXKK2D1xXon/AA8p/aJI/wCSj/8AlE03/wCR q+uPhb4xvPETnWNc1KXV9ZvSJbq+udu+Z8AZIUBVGAAFUBVAAUAAAfifi14n8ZeGuXUZ/uJ1 a/MoOPNJR5eXmbTUdfeVle19WmlZ+lgMFh8ZNrVJHjvw/wDgX8Sv2dvhr4i1O10vTfEutIWu bay0+aR9/wAqLkgohbaAzbF5bG0HJFc/+y9+1h8Tta+L3/CKeMbufV9Okt7hLmGTT4LZ9Oli GRLIUhDgblMRVio3SrnJVRX3bLrtmdPQKxLFDvDAYByen4Yr5Lh8K6Z4i/a+s/h74cePwxe+ NYJL+81WC185PNihuZNzR+YmSfIOcEfNIWOSTn+JOHOLanHsc7wub5PSxWPxcZTjW5UpUrJJ tXb5IwV5+5Zyl7s7xty/R1sOsL7OVOo4wjpbv/X/AAx9vfst6sdc1LxndxwyfZQbSFbgofLd x5xZA3QlQyEjqA656ivfq5j4cfDnRPhZ4VttA0G3aK1i+eWeUhprqUgBppWwNztgc4AAAVQq qoHT1+ocP5X/AGLllHAXvyJ/e22/xZx1Z+0m5BRRRX0BkFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFAHnXxk+LI+GFjpkdtax32q6nJJHBDM7IiIiZaU4UhgrNENm VJDnB4NeU2viTxL4gWO4vvEeomYRhM205tlIyTnbFtXPPXGenoK88/a+8RxaP+0TpELsFZvD ls/Pcfarof0qx4V8eRwRxyI8ZYDo6hxyMdCCK/lvxFzbNpZhLDUasoUoWsotq+127Wu+19un U9rCU6fJdrU9auPj9qHw90rUb/xBY3niWzgR7jGmRR/bAqoT5ccQ2rISQAASp5PJ4A+LPiR/ wWM8TXOphPAPgTSdN06KaZTP4kllu5bmLcPJby4WiELbQxZd8oywAb5ctH+3f8SdS0b4V6TN omsXuk3UmtRRvNYXLwO8ZgnJUlCCVyFOOmQPSvzsuNRN7cSz3ErTzysXklkYszsTkkk8kk85 r+0/o7ZDHPOHZZrxLONe83GmpSlzR5dJc3Sad7pttrbtb53Nqvsq3s6Onc9U+LH7V/xX+NNv Ja+M/Hurarp8sKQS6bE62llMqSeYhktoAkTsHwd7KW+VeflXHn/hHwl4l+ImqS6Z4R8Oav4o 1KKE3ElnotjLeTJEGVTIUjViFDOo3YxlgO4rO03UE0zU7O/iit5J7SZJ40ureO4iZlYMA8Ui ski5HKOpVhwQQSK+gfDH/BQH44eCdDttF8O+L7DQNGtd3kadpfhrSra3i3MXbbGlqFXLMzHA 5LE9TX9f4mjmGGpewyKNCnHtdxX3Rg1+J4EXCTvVu/69TnfG37HfxW+F13ZDx/4em8JafdSK gv2aO8hBbdgCSF2iL4Rz5ZkD4XOMEE/UWn/GrSPDnhmy0zT5FgsbK2jtreESFtkaKFVckknA AGSSa8L1v/goR8ZPGfhPxH4Z8X61pfjDRNb0+SwktNV0e2QWzsVZLqFoEjZZ4mUNGzFlVgG2 kqpHjnw7+KfiL4ZeO/Dvi3R9Tn/tTQ72O9txNcS7JCp+aOTa6sY3QtG6gjcjuucE1/OHGnhH xRx/VjLOcfT5KV3CEbuN2td7O+iV5bLbd39fD4+hhV+7g9dz7a8Af8EeNV8Z+ErDXNT+Il14 Pur4PMNEvvD4uJ7WIyN5QkcXKfOY9jEFFKlipUEEV0Q/4IqSj/mtP/lq/wD3bWH4K/4LI+Mr H7Z/wlvw90LW9+z7L/Yt5NpvlY3b9/mfaN+crjGzGDndkY6c/wDBaD/qjw/8Kf8A+4695ZF4 jYe1OEnOyS5uelrpvq0/XQy9rg3r+jPOfE3/AARv+KlnrlzF4d8ceEdV0ddvkXeqG6sriT5Q W3wpDMq4bcBiRsgA8E7R4D4p/Yg+L3h3xLfaVYafpXiq3ttm3VtD1OJ7O43Rq/7tpDGx27tp yo+ZWxkcn7t8N/t7az+01olxp9p4Yj8FaWJjDdmPVDeTXa7QfLz5MYjTnnG4vnHygEP6z4QS GaOGGPy1LcAyOqL+JJAFfzbxx448W8D5nLKKcIzrU9J895JNpOy9nON3rq+a17q2h7GGy2hi Ye0eie1v+CfmpD/wTp/aF1COKbSPBtnrlq8MMhuLLXbALG7xJI0LLJMjLJGX2MCuNynaWXax 4D4q/sx/E74IQSP440jStAnSGO4FhL4k0yS9kieTy1kjtkuWmkXcGGVQgbWJwFYj9WviDYya j4e1C30/WNU8P3NxCYhqGiX0lndRchgVljII+ZVOOQcYIIyK/Gzx1NqFj4x16HW759S1qO/u Evr2WZpnuLgSMJJGdvmcs24lm5Ocnmv2vwZ8VMf4k0sRLH4hYeeH5XKKi3zRlf3oyctNU000 7ab3083McDHBtciumZUZlK5chfaun1r4reKdYOnm78QXpGnSRzWiQy+SsEqElJVVMASLuOHx u969V0n9gv436n8Pdf8AG+qeFv8AhD/Dmj6PeazLN4jl+zXEqWwYvCtsA06yMEcr5iIhC53g Mu7zX4Z+FNL1PRvG2tamrTr4b0eLVViMYk87ff2tmY9pYAf8fgfJ3Y8vAHOR+6ZtnmW4nDVM fhMLHGVMKtG+SUoubUWouW3NZc3Luls3ZHmU6U4yUJS5VL9D9F/2f/jJq/iL4F+ErnxHPMdR W0MZNwz7pEV2RJTvJJaRFRy38RbcOCK+kv2RdWfXdR8b3iwy/ZN1nClyUPlu6iYsgboWUOhI HIDrnqK/M/4GfEuf4y/Ezwt8P7fUYfCw1m5Wzj1HUtiwQ/KSFVQ/zO20JHGMb3ZFyN2R+ynw 1+G2hfCjwna+H9AtmhtIvnlnlIaa6lIAaaVsDc7YHOAAAFUKqqo/znwXAuYZTxNWzjMML9W9 pKc407WSVRyso/3YptL0R9dLEwqUVThK9rK/odTX5A/8FeL+5sf2ofDv2a4mt9/g603eU5Xd i9vsZx9T+dfr9X48/wDBYI/8ZReGv+xOtf8A0tvq/pbw9o0sRxBRp1oqUWpaNJrbszx8W2qT aPu3/gmy7SfsW/Dx3Ys7NqbMzHJJOpXRJPvX0zXzL/wTX/5Mq+HX/cS/9OV1Xufjn4j6B8O7 S3l1q88mW6Lra2sSl5rhlXJCKO3QFjhQWUEjcM/I8UVaODzXHTqNQhGrU1eiS539x0UE5U4p b2R+Kn/BSL/k9v4mfXTf/TZa1+wf7Ln/ACbL8I/+xQ0j/wBIoq+Ifi/+yTon7R3xc8T/ABE1 zUNT0m71x7ZlsLCWMpbrFawwAFmjJckxFs4X7wGOMn6Hm/aAtf2W/wBmvSbe98Oar4ouvCej 2mlRx6WEUXIgtRGLiUscwxF4wH2iVkEgYBwrbVi/FDhbizA5Zw5leJviYWjaUXBSk0klGUrK 99LNpttWuEcFXoSnWmvdZ7N8e/Ht18MvhF4i8RWK7r22ijhgfKjypJpUhWT5lYHYZA+0jDbc cZzX50aN+2R8OPh7q9lok815fRkRCXUdMhSe0t9x/iYOGbaMMfLVuuBlgVHzr+0/+3F8Q/2m rt7TUrr/AIRvwim9IvDWkzyLbzJ5okRrok/6RIuyIbmAQGPciIWbPz7pmn3uv3qWunwPM7MF ZwDsTPQse3Q+5xxk19lmXgpkuMw/1/jbFuFOEXanCSjyt/ac3e7tb3UrXS1lsc0MyqRfJho6 93/kftfD4t0fxP4asdU0y5N3pmoWkV1bzPGYy6SIHB2nkcHuAfUA8V8sfGH/AIKL6R4h8Pa9 8MPGnwtfxZDpt7cWiaz/AMJCLe5WSKV0iuI/9EfZIq8ZJbI3BtwZgcz4eeL7D4T/AAu0fw1F fm4WwhbfKzD55HdpJCOB8u92wOuMZJPJzdY/4JJfGzxHrF9q0eu+DrGO/nkultNR1W8luYQ7 Fgkri3cM4zhmDuCQTubqf598E8k4Xy3O83WbxlVwj92k5OceaPPK0pKMl7zilo07Xeq1v6uY 1a86dP2ekuv3Hzppn7QWr6bF5ccB2BTt3TZOccD7o4zjn+dfX/7NP7evwU+CHhpbnVdB8Z6v 43v4VGp6nHY2bRxdCbe3LXQIiDAZYgNIQGYABET89vHPhDVfh7448R+FdRmtZtQ0HUrnS7mW 1dmieWCVonZCyglSyEgkA4xkDpXvo/4JuftMjr8Nf/K9pn/yTX9h1eBvDTLZ0sZLCuhzq8Xz y1XVrncu6v8A8E8BYnGTvHmvbyOQ/a3+LWkfHr9ojxf498P2t9aaPrH2TyINSREuF8qzggbe qO6jLRMRhjwR0PA/TT4C/t/fAXwX8DPh14e1nx39j1jSfDmnWF7bf2PfyeVPFaxpIm5YCrYZ SMqSDjgkV+P3jfwlr/w58W6r4Z161gt9a0qY295BbXsF0sMoA3RmSF3Qsp+VlDEqwZWwykDu tU/Zc+N+japeafcfCHxtJPaTPBI9poNzcQsysVJSWNGSRcjh0YqwwQSCDX22cZbwrmeXYTBY qtUp0qa/dtNLmVkr3lF8ytbVdzmpzrwnKUUm3ufp3q37SP7C2u6pealqVh4K1HUb2Z7i5vLv wFNLNPK7Fnkd2siWZmJJYkkkkmuu8Nax+xP4s0S21WytPgxBa3G7ZHqem6bYXA2sVO6CeNJE 5U43KMjBGQQT+R4/Zu+NP/RIPH3/AITF7/8AGq861RrrQtUvNN1OzuNO1Gzme3ubO7iaKaCV GKvG6MAVZWBBUgEEEGvmHwZwrXjy4XM6qfnKMtPRRibfWa6+KCP2W8Z/B39hfx3qkWoalc/C +1nihECpoviiHS4SoZmyYrW4jRmyx+cqWIABOFAHE+Lv2b/2NLTRQ3hDw5o3jLVbhmhgi0fx bfXcMLAAl5miuyFAyDtyGbOBgbmX8mBq0Z7ivor4I/F7SPhN8PX1OeM3F5PLI8NnG+HuZAdo 552qAoy2MAdiSAfzvxAyLE5Fk0P9WMdVxGLrVI0qcF3kpNv4tElF67J6vS7OvC1Y1aj9tFKK V2z7X+Hf7J3wt0LSjbp4N0u7Dt5jPqMP2x8kAcNNuIHA4BA6nHJqL4hfDC3+GGjtq3hoNBYW UZe5s5JmfEY5LqzEnIHUE8gccjB+MfCn7eXxT8L+K4NVutStdR0lZnabRGs4Y4XhcENGsgQy LhW+VizEEKW3cg/evjfxzbrpM++Rduw5yfav4Y8ROCONuBcwwn+s2KWIWIUpK1SdRe7yqUZc 6TUlzR1Sa1VpNppfS4TE4bFQl7GNreVjwXUv2i9P07THllvY40UDLM4AGeB+tL/wTu1yz+NP 7bWpeJNTtBLLofhq7uNJcSOphfzobfzCAQGJiupxtYEDf0yoI+ZPAvi+PRv2XfjMt5p66rqO t6l4d0C31G4lzNYRNJeX0uxirErI2mxKyAqCQjEnywD9M/8ABHHwde33xh8d+Ko5bcadpegp pc0TM3nNLdXCSRlRjBULZyhiSCCyYBySP7P4d8KsDwBlub5hWnz4iMVSUlpFKag3bq3LmUXe 3VWs7nz1XHSxU6cUtN/uufrLRRRXwB1hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAeMftPfs62/x/8ACdqttenSvFWj+bLpF87N5IZwu+GZRnMb7EywBZCo IyNyP+cGs+MPFHwo16bw94u0e90PWIF3NbXSEF03ugkQ9HjLRuFkUlW2nBOK/Yavyd/4LL+B 1sfir8OPGBvBKdV0e40kWZhx5P2SfzfM37ud/wBuxtwMeVnJ3YXmocEYPjPMaeDqz9nOd1zW 5tlfVXXRPqhyxMsPBySuU/Afw61P9ty5vPCumR2c2jabdW51fVLiZG/svcZCriMMJGdhFKoC YyThmVSTX2YP+CZP7NQ/5puf/B9qf/yTXyL/AMEbfGv2D4ofETwj9i8z+1dHt9V+2+bjyvsk 3leXs2/Nv+3Z3ZGPLxg7sr+rlfRYnhup4fYurkuCxE3BWle7ineKu1FNpa6d3b0Mo1li4qpJ HxD4n/4JB/AzXtcub+xvfF/hu1l27NL0vVInt4cKFO03EMspyQWO525Y4wMAZg/4I2/Bgf8A M1ePv/BhZf8AyHX3jRWsM+zSCtHES+8TpQfQ/MnVf+CKdtLql5JpnxhuLTTnmdra3u/DqzzR RFjsV5FuUDsFwCwRQSCQq5wPzAEEvkmQTZwM42//AF6/p1r+Zu80u90S5u9N1OzuNP1Gzle3 ubO7iaKaCVCVeN0YAqysCCpAIIINft3hzj8TndTFUsfVc3GKcdbW+K+1r9N7nm4yEaSi4o+1 x/wR2+N4/wCZo8Bf+DC9/wDkOs3xN/wSQ+PPh/Q7m/sbvwj4kuotuzS9L1OVLibLBTtNxBFE MAljudeFOMnAP7E3Hi3Q7TU/7Nn1nT4dR3pH9kkuo1l3tjauwnOTuGBjnI9a1q/L6PiBnTb9 niE+V6rf5PXQ7XhKfVH4t+Afg78Rv2V47S2+I/h7/hHH1u6mlsh9utrnzRGkIfmGRwuNy/ex nPHSvpDwx8Somtk/ejp619y/FX4VeHfjN4LvPDHiez+1WE+HjljIWa1mAISaF8Ha65ODgggl WDKzKfxj+OPiC+/Zq+MfiT4dXt5NrN1ossS/bLWIBJY5YUmibDMCrbJE3LyA24BmADH+duLe Dcw4xzarjcLTdSrVbk1Fa30voetQxEMPTUZOyR9f+JPiXCllITMOh719G/svfAnwboPg3QPH cvhbQp/G2rodXPiIWyzXipPHtiEczrviH2YxoyRkLnf1LMzfG/8AwTy8L6P+094y8S6r4lFx caZ4SFnINGuI18m9lnM2wykMdyJ5DEx4w5ZdxKhlf9R634T4NxfCNet9ci6dVrlcXo0nZ6rz stBV8RGuly6o8u/aoOP2Yfi//wBifrH/AKRTV+HX7O+oyxeIPFelFLefTtX8FeIoL22ubeOZ ZVg0u4vYSN6nayXNpbSq64YNEuD1z/QtX87/AOz3z401Q/8AUn+Kf/TBqFf114eTU8qzak1t BS+dpfla54OLXv035i/svjP7Sfwi/wCxv0f/ANLYa/ofr+eH9l3n9pL4Rf8AY36R/wClsVfq P+3F+1j4Q+HHi2y8GazftewWcEV/faRpjJcTzTtIrRRypwIzGoSYCR13CRWAJRCcPF5YyWKw v1DDTxFV0/dhBNyk+byTslu5PRK7Y8ByqMud2V92fa9fjx/wWCP/ABlH4a/7E61/9Lb6vqW1 +J3g238BD4s+FrgXUFnYyXQvrKKW2uJ4LWZpHtmz5btGZIDmMkI3fgmvzx/bO/aWtP2qvif4 e8Y22hT+HJrbQI9LurCW5W4VZY7u6kBjlCqXUxzRnJRSG3DBADN+eeCWY47iLNqmMqYKdD6r N06qlvGbT91ppSTTTUk4rldk9XY68yjGjTUVK/Mro/UL/gl/4n03Xv2OvC1jY3Pn3WiXmoWF /H5bL5M7XUlwEyQA37q4hbK5Hz4zkEDhvjt8Sz4o/aA1jTxfQXWm6AI7C1W2lLor7FefcNxU SiRmjbAB/dKpGVr5l/YS/b++Hv7Knwm1rwn4s0bxNqOo3uvTapHLotrbywiJ7e3iCkyTxndu hY4wRgjnqBd+Nvx/8JeP/wBoLxF4s8FeI4PEPh7U1tXWaK3uIHgdLeOFkkSeONgcxFgQCpDD nO4L8n4wZJjak8c6UJcjqtt20s23q1suZpK/Wxvl9WK5bvWx9d+EdfsgYvtTSeRg7vJxu6cY zx1xXP8Axj8UWOm/DnxLfXdlFqlta6bczy2MxGy4VYmYxtkEYYDByD16GvEPDnxYiNuh84dP WsX4xfE+LU/h74j08XUcb3mnXFurSPhQXjZQSfTmv4nynh6X9sYb20Xye0je107cyvZqzWnb XsfR1Kv7t27Hwn4Kn0LSfGGlX/inSJ/E3h+2mEt3o1tfGxe8UAkRmcI5RS2NxVdxXcFZCQy+ wfHn9onw38R9G8G6V8PPhlpnwlsvD8M8Ew0+4jvJNQVhEIzLIYEdmTy3O9y7MZWJOck5uqfs Y/FSLxDd6d4ettE8c2UAjMeueHNat5bC6Dxq+YpJGjZgN20naPmVsZHJ4X4ofBXx/wDBZ9MT xnoJ0ZtS802o+2QT+Z5ezf8A6qRsY8xOuOvHQ1/sJV4i8OuKMxhgq9SnXxN3ak6rlK6Tb/dc 7u0rt3jdJO+x+fqji6EHJJpd7fqfRf7Df7VXgb9n7xL4i8QfEjR9Z8Saw8UEOh3emWtvK1ip EouTh5YgrODEoYBjgOMqGYN9lH/gr98HP+hZ8dH/ALcLL/5Lr8lvBPw88c/Ek3n/AAiXgzxD 4p+xbPtX9i6XPeeRv3bN/lq23dsfGcZ2nHQ10GqfAH4uaDpd5qWp/Cvxtp2nWUL3FzeXfh28 ihgiRSzyO7RgKqqCSxIAAJNGI4a4BnXlePsW7e7FqCWi+zbS+/nuNVsUl3Knxh8VW3xB+Lvj vxVp0FxBp+va9f6pbRXQVZUinuJJUDhWYBgrDIBIznBNftAf+Ckv7OQ/5qIf/BHqX/yPX4Sj VlNSLqqetfRZzkfDHENHDUK+JnGNBNR5XHZ23vF3+FdjGnVrUW2luejftDaja61+0D8VNR06 5hv9PvfFWq3Ntd2sgkinie8lZJEdSQyspBDAkEEEV+7h/ag+DY/5q14F/wDCks//AI7X8766 mh/iFPGooR1FRnfCeTcQYbCYaWNcVQi4ppJ3vy76/wB0dKvUpSk+Xc/pqryD4v8Ax/tPAmpp 4e0T7NqXiYlHnily0NlGcMPN2kHeyn5UBBAIY4G0P/PsL2M+lfcf7NOsW2n+ENIjiCRjyEYh ePmIyT+JJNfyf4vcPy4EyWnicuxvtalWTjpDl5Uldv45a7Jad32PdwFX61UcZxsl5n3LpniT xFq8r3V54i1Np5cbhFctCnAA4RCFXp2AycnqTXy9+2H+yO3xZvNT8d6NqF1N41aCFJLa7nDQ 3qQx+WqgtykhRUAbO0lPmALtJXuPhLxnHZPFNtin2/8ALOYblPGORVjWvFUTWj5cYxX8J8O8 bcUcKZ1DNstxUvaReqk3KMlfWMk3qns9n1TT1Ppa2GoV6bpzjofk58JNJtrPW7HxTqrhbHT5 PtNugbG6SM5DsQRhVYZx3K88dfWf2hfif4h03QNJ0y7s7jT18TaWmqWck2P32nyPJGsoHPyy GKQLnGVww+VlLeU/tF6Xp9j8a/F4soFSGW6FyQSWzJJGskhyc9XZjjoM8YFfS/8AwVu0iy0L 9o3wdpum2dvp+nWXgiytraztIlihgiS7vVSNEUAKqqAAoAAAAFf6YUOF48W8RZNxTnVT2qxM FWp07WjTioxqRi9XzNOS5nopNaq2h8c63sKNShTVraN9+h4ZB4estM/Y01XXJNZt/wC0dd+I NlZQ6O21ZvKsNNu3knX5suu7U4kbCgIdmSfMAH2z/wAEYdLvYdP+LmovZ3CadcS6Vbw3bRMI ZZY1u2kjV8YLKssRYA5AkQnG4Z+EvFulXtj+zR8M7i6s57aC+8U+JLi0lmiZFuIhbaNGZIyR h1EkciZGRujYdVIH6Yf8EfDn9mnxP7eL7n/0isq/SOMqzjw5jp3v7Svb5Rkkvu5Ejkw6/fR8 l/X5n3RRRRX8tHthRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFfnF/wWd8HXt74K+F/iyOW3Gm6XqV7pc0TM3nNLdRRyxsoxgqFspQxJBBZMA5JH6O18X/8 FavBt74n/ZO/tO1lt44PDmv2WqXazMwaSJhLaBY8Agt5l3GcEgbVY5yAD9VwrX+rZ3hal/tp ffp+phXXNSkj4w/4JQeMbLwx+1jFp11FcST+I9CvdLtGhVSqSqY7stJkghfLtJBkAncVGMEk fs/X4JfsGeMrLwL+178L9Tv4riaCfUm0tVtlVmEt5DJaRMcsBtEk6FjnIUMQCcA/vFq+q2uh aVe6leyGGzs4XuJ5AjOVjRSzHaoJOADwAT6V9x4q0VRzuNd6KVOLb6aOSf3JI5sC707eZbor 59+Iv7ZPhn4fJDc3FsBp9wzR2895M8T3DqTkpEkUj7MbTuIGN4BAJGeF+JH/AAU/+D3gjwkd Q0x9W8Sa7KHW30SGxkt23BX2tLPIojSMsqAlDI6iRT5ZwQPw/I8bQ4lxf1HKG61R3soqVnbe 0mlF26tN23Z6VWLox5qmiPryv54P2mju/aW+L3/Y4ax/6WzV7t+0F/wU++KfxbEth4cuB8NP DzY/caJcs1/Jjy2+e9wrjDxsR5KxZWQo+8c18na62sTa5eXevC/bVtQK6jNNqe83Fz9oUTrO zP8AM/mrIsgc53BwwJBBr+s+A+Fcbw7i3Wx84qdSLXIneS63dtPub6anhYqvGtG0enU/Qiz+ KGkfGT9jfVH064N94l06zso9XtRCEnjmSWIyymNBgRsEkkDDC7Q3Qqyrz3wI/wCCqc/wL0S0 8C+JfC194x0nTr4QR6vHqixz2dlhFaGOFof3pjIk2BpVBBVAyqq4+fvgb8XPCvwv8Ia5pszT Xd3rSBNROyRVaPYyrCMcYUO/zDk7jzwMfoN4G/4JO/Dq++HN9Z/ESJp/G1/dtOdd8NX00Js4 wU2xxrIDFIWCMWd4M/vmA5VXr+Sco4YwXCvEeZQng60MDUnJ0XOLgnflU7fDzRjJNRte0XHm V3p7tStKvRhaS5ktbEaf8Fk/gvIcJ4W8fMfRdOsj/wC3dfA37cX7QXgz9pf4323jLwVoeoaH bNo9vZ341W0ht7i5uo5Jf3r+VI4f900CBmbdiMLjCrX33F/wRv8AgxCTs8U+PRnr/wATCy/+ Q6+BP25v2adH/ZX+ONr4V0DWL/WNIv8ARrfVYG1QIbiDfLNE0bOgVX+aBnDBFwHC4JXc39E8 FvIY5nSeClP2+ujXu29e+zPJxPtXB81rHsn/AATJ/ab+Gn7OMnxK/wCFieJP+Ee/tkaZ9h/0 C5ufO8n7X5n+pjfbjzY/vYzu4zg4/SzSv2u/ghrOl2eoW/xc8FRwXcKTxpd69bW8yqyhgHik dXjbB5R1DKcggEEV+Ov7JP7IjftaHxtYaf420/w14h0SyiubHS76287+0t/mKSSJA8caOsKv Iscm3z1+XOA3rS/8EdfjOOuv/D7/AMDrz/5Drbi/KchxWd16mKxzpVW480XFtL3VaztrdWb8 9BYepVjSSjG6P0U+JX7avwn8DeCr/WtJ8ZaD411CHEdvpHh7VoLuaaVgdgby2byk+UlpGGAA cBmKq34oeAtHvvhbq2ta3K0N/a/2FrOnLCkjIzfa9PuLQOcqQNon345zs25Gdw+svBv7KnxA /Yu8RS6n4yj0a60PVjbW0Or6LeeZD9o/ft5DJIscoYIhbds2YIG4nIHuPjLxB4a+Jfw71Dw7 riQXFheQSR+YY42lgZ42j82JnVtrqHO1scE1/J3E/HWM4J4gqZblv73Cy5E6i3lFpOVk49Oa UWr9D3aOFjiaSnPSWuh+T+kateaFeWep6feT6ff2UyXNvd2srRSwSowZJEdSCrKQCGBBBAIr 6V0n9hD41eNPBXiz4n+M7N/Cuk6fa3Wt6hP4qmlTVdQWMTSXDLDseUSZiY5nEe7zFZS4JNeI fBfxlZfDr4r+BvFmpRXE+naFrlhqlzFaKrTPFBcJK6oGKgsVQgAkDOMkda/fb9pPSr3Xf2dP inpum2dxqOo3nhXVbe2s7SJpZp5Xs5VSNEUEszMQAoBJJAFf2zx3xFjso+rYbB2h7aNnO3vJ XSajfRWvfW/ofN4WjGpzOWtuh+bf7HVpo/7Qb23wa0m8ksfDlno89zqsj+YJprUyKk4iJGBJ JJcdyAgdiAdoQ4n/AAU4/Zm+G37Os/w0Pw98OHw+dZGp/bs39zded5P2Ty/9fI+3Hmyfdxnd znAxH/wR2uhN+1B4lRTlF8HXXPqfttlXqX/BaX/XfBn/ALjX/thX5xw1keC4X41WCyqvUnTq zc5uc+Zzm4Sbk7JJ631tfzZ2Vqkq+G5ppJrRW6I83/YT/YC+H37Vfwj1nxX4s1nxNp+oWWvT aXHFot1bxQmJbe2kDESQSHdmZhnIGAOOpPr+o/8ABGyy03xFc3XhD4u6houlNtEFrqehx31w g2KHDypNCj5YEj92uAQOSNx7n/gj2Mfs1eKP+xvuf/SKyr6v+N/jW6+Hvws1/XLEf6bDHHDB JlR5Uk0qQrJ8ysDsMgfaRhtuDjOa8PjPPsXgM3zC9T92nJNNKScbaqzTTVunyNcPSjOnDTU/ Crx/4r1D4YfEjxd4OYLqUnh7WLzSTfxubZbnyJ3i8wRfPs3BM7dzYz1Nb/ir4SeKb74E6D8U de8ceEdC8PeIWu10jQrm5vH1K9ktpJUZBHHbOM7owN7OsYLxb2QsK8r+K08lz8XPHM000lzN Jrt+zzTOXeRjcSEszHkknkk8nNdj4p8MeErf4UfCS/e5bT9W1L7aNXext0nn+yLfSIs5jMqb nVQyoCVD7SpkUIK+9yjhXIMp/sfM8FhpRr4qa96MfaNP2NStdKV1D+HZSjFtOyVk21yVK9Wp 7SEnpFenVL57lPRvj38RoZvDGl+HNavNMl0sRwWdnpDMi3DqRgzJkiXO1QVfKYB+Ubmz7N+3 t43u/Gdp8M21OWzk1mC2vDf/ANn7hbidltd/lhuQm5W255xjNY/j/wCIvwQ0T9mjRPDfwt03 V7X4g6frdvd6r4l8RaVbx32pwtbXAnMUkck3lQpItviDcMZQjzGEj1816t4n1DxRqKy397Le eUu1DJ0UHrgf19h6VlLgyVbi/K87o4OlhKOFnWtHlca9R1YSTk/ds4XlfWTfM3fV2GsRahOm 5OTlb0Vj9Lv+CLf3/jJ9NG/9vq/Tavyg/wCCSXxV8FfDKT4r/wDCYeMNB8KfbRpP2X+3NTgs /tGz7bv8vzWXdt3pnGcbhnqK/SLwx8f/AIYeNtcttF8O/Efwjr+sXW7yNO0vXbW5uJdql22x pIWbCqzHA4Ck9BXxnH9KpLiTFzUXa8dbafBE6cI17GP9dT+dbQ9Kvdcns9N02zuNQ1G8kS3t rO0iaWaeVyFSNEUEszMQAoBJJAFf0j+M/AHhf4j6XFpvizw3pHijTophcR2etWMV3CkoVlEg SRWAYK7DdjOGI7mv5/f2Vhj9o/4Rf9jdpH/pbFX75fFb4reHPgx4KvPE/ie8+y6fb/JHFGA0 11KQSkMSZG52wcDIAALMVVWYfV+KWI9j/Z8W7KFNu/q1/kYYFX5/U/DzR9E8Ka9+3la6fpth o2o+Dbz4mJb2tpawxS6fPYPqoVERFBjaFoiAAAVKkAcV9K/tP2/7OmnePNbv9d+H2m6Vpej3 smh2WkeG7QadcXkkMhSeQx28saPh953sRhBGOGO0/Fnwj0/xD8M/iz4R8UNp0d9B4f1m01Ty XuxHHcC3mWXZuAZl3bMBthxnJHUUvxW8XeJfi14+8ReNfE9rHYSXuoqt/cWNg0dlZSzCR44l VAQCyxysuSWkKSOzM29zx5rhMt46q4WGGzF0aOFgnV9jO1We6Si4PmXM9JNJy1UUryTHCU8K pc0LuT0utF959p/8KH/Zs1T4QJ8RtD8GS3WkJYyaiYJ9Qv1kPlBjLCyG4HzBkdDtYAkZVsEN Xz14N+JWnPqd/c6FpR0DRvtL/ZdHF01ybKAsTFF5rYaQKmF3sASVJNfWv7Dfwh0/4/8Aw5Gm 4lj+Fujl9LvIzK6XGp3DKJZoRg741PnB3cYx5gWPBy0fZftHf8E2PhB4O+G/jXx74QbxF4Qv /Dvhu9v7fTtO1TzrSee3hlmVpRcpLIwYqisqyKpVRgA5J/nzLMjWLwWZ5ZnlTEupKvfDOvOU 5QpptKNSMpaSkmuZpaNJpWun606nLKE6SVra20u/I8H8P/F+IQr+/A+pqr44+Pdpoui3VzJP uEUZbarDLHsBk9ScAe5FfGFh8R9cjtlWX7JMw/5aSRHc3PfawHtwK+ovi/8AsF6j4c/ZG0/4 53/xJOrF9H0rVF0AaIIQv217dSnnCcglPtGd3l/Ns6LnjCj4J1sHjKE85lGnSqSSja8nN32S S92/eVrJ3Sew3mSlFqnq0fJfiTXp/Emr6lq90zGa7leZg7lyoJyFyewGAPYCvfv+CgPxhs/j Z+0/rWuaLrsHiHwtBpunW+iXVuiqqWzWsdwyH5Q24Tzz7hJ86sShxt2jwzwN4MvfiN4w8PeE 9Nlt4NR17UbbSraW7ZlhSWeVYkZyoYhQzgkgE4zgHpU3j/4fz/Crx/4h8H3ep2Gr32h3kmn3 V3pnnG3M8Z2yohljjc7HDITtAJUlSy4Y/wB9wwmGo5tgcPSVvY0mox6KL5V+HKkte+58s5Sd OTfVna/FXx1Nrnwr+CXheLVILvTdC0HUJzYwmNms7y41i+MokIG4M0MNo2xjwu1gBvJb9EP+ CevifUvBf7M+iReG9O0y1Go3N5fX892Jpnubr7Q8PmY8xQgEMMCbVGP3Zbqxr8tfFvhC98Ea 9Dpt/Jbyzy6bYakrWzMy+VeWkV3ECWAO4R3CBhjAYMASACfXP2cv2gfiH4V8ZeB/DGla7cJ4 djv1tpNMitYpENrNcpLclsoSThXbzCdyKX2soLZ/KPFXh/OM64NcOGsXCi4VZ15zldJwUasp RVoy1c5RtdJWTbfR92BrU6eIvWjfRL56H7l+AvH0HjeC7X7M9jf2bAT25YuoVi2xlfADAhTx gEEHjGCeqr5q/ZmvLjxf4+1rxBAgOlWVkdPaZlYb55JI5NqHG07Vjywzkb4+MNkfStfyhwnj 8bmeT0cTmCtVd7u1r2dk7dL+Wl9rLQ92vCMKjUNgooor64wCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiivItQ/aJ06fVZLXw7pra7bQu0cl+bgRQSEYwYSFYyLksN2F HygruBBrx80zjAZLR9vmFVQjtrd39Ek2/kjSFOVR2irnrtfPv7f3g298d/sd/E/TdPlt4Z4N OTVGa5ZlUxWc8d3KowCdxjgcKMYLFQSBkj0Hwr8X7TW9Si07UrJtHu53KQMZRJDIeNq78KQ5 JIAIwcAZyQKvfGnwZe/Eb4OeO/CemS28Go69oN/pdtLdsywpLPbyRIzlQxChnBJAJxnAPSu7 h/PMDmM6WPy+qpwjJO66NNPVOzXo0TVpSgnGSPwA+A/ibTfBfxt+HXiHWbn7Ho+keI9O1C9u fLaTyoIrqOSR9qgs2FUnCgk44BNft7+2VqOq6V8IIbmxx/Ziata/2uT5eBaksE+9z/x8fZvu fNz/AHd1fgPGd0H1Ff0mazo3hr4seB5LK9jsvEnhfW7VHDRyCWC5hcB45I5EP+66SIcghWUg gGv3nxnwKx2Hw1m17WnON/ut/wClO/keXl0uVy8mj8XfjB4rl8YfEHVbxy4hhcWkEbSlwiRj Z8voGYM+B0LnryT88fFLW79NYWwz5NmqJKi/KfMPzDf0yOpXH+znvX07+3N4F0T9lb4yxeF9 OutS1qz1DR4dYt5LzyzKjPLNE0cjqFB+aAsGCjiTGCV3N9tf8E8/gx4C8Z/su6d4s1nwrYa3 e+MPtCalDrUEd7EYre9kSOFUdNoTdbxykYJLgEk7EC/zxwjleN4XxFHH1cP+6guWMuZKztpK Nru9k+ne7TPVxE4104J6n5P/ALPP7SHiX9mzxzH4p8OafoWp3yZ+TW9MiuduYpI/3cuBNDxK 2fJkTfhQ+5RtqL4xfGjWf2g/ipr3j7xBaWNjq+rmDz7fTEdLdPKgjhXaHd2GViUnLHknoOK/ ef8A4ZW+Cv8A0SDwF/4TNl/8ar8l/wDgpl8HfBnwV/aNsNM8EaDb+HdO1TQYtXubO0d/JNzL d3auyIzERrtjQCNAqKFAVRX9O8HcQUMxz2mvZ2qNNcztdreze7+d/wADxsRRcKT10PljWdb0 h7TSLey0l9Pu7W0aHULkXDS/b5zPM4n2txHiJ4Yti8Hyd3VzX6WfCL/gsxosGlabp3xE8F6u 1xaadFFc65pFzBcTX94qoryG2KQJErnzHwrnacKFIOR+ad54Nv00Kz8Qz2xj0e/u7ixtroSL +8nt0geZNudw2rcwHJAB38EkNj9H/hd/wTV/Z88Ufs++EviV4j+IviDSbHUdItLvUtQ/tzT4 bC1upFRJYvMe3ITbOWi2sxYMNpO4V63GKoqnTeZUlUp88407czkpN6rRp3dtndaWS0M8Pe75 HZ2Vz1If8FkfgmSAPD3jnn10+zH/ALd18df8FD/2pLX9pbxB4MfStLuNN0LSUunsxqEIivCZ ktfMWVVkdchojgqRw2CMjJ+dviv4B8A+E9cjsvA3j2/8fWaZ8/Up/D50qBsqhXyQ88kj8s6t vSPBT5d4bI5LVNQl1HUElnmaeUg5ZznAznA9Bkngcc1x5XwZPB43B5xSj7GEJNuMnLmnzLkS 5ZapLmcnez0WnUqeJ5oypvVs+uP+CY3j6L4dftE6nqE6xyxT+Hbm2aAuFkkX7RbORFkgFwIy 2O4Vun3h+1tpdwX9rDc200dxbTIskU0TBkkQjIZSOCCCCCK/nN+E2nXWr+LksbG2mvb26i8i C2t4zJJLI0iBURRksxJAAHJJr+hD4W+F7rwR8MvCPh2+khlvdI0iz0+eS3YtG0kUKRsUJAJU lTgkA47CvyzxEddcYYqMpXp8lJpW2dnfXrfTTpbzO7CW+rx73ZoeLvCOj+PPDWoeH/EGnw6p o9/GYri1nB2uMgggjBVgQGVgQVIBBBANeBaf+wF8M7LXmvZLzxJeaa0kjjRJ9TxaqrBtsYZE WfamRt/e5+Ubi3OfpSivzevg8PimpV6ak1tdXOxScdmfzIRc2v4V/TfX8x9sd1qPpX9OFf0T 4pPmo5bL+7P/ANsPIwO8/l+p+Nf/AARoRv8AhpzxQ+Dt/wCEPuhn3+22Ver/APBaO7gfUPg7 bLNG1xHHq8jwhhvVWNkFYjqASjAHvtPoa8c/4JX+Ix4I+LfxC18WwuxpHw/1G/8As+/y/N8q 4tJNu7B2524zg4z0Ne9+H/2sPh9D4qmt/FfjKKTxNdXCpdz3EMpQStgYaVU8pFXIU/MFQLg7 QuB+dcZ51mPA/E9DEZVltTMKsIKcoU1LSLi023GFRpJyWri13tdHXh6cMTQanNQTdrv+kdz/ AMEeriJv2cfFcAlQzp4tuHaIMNyq1nZhSR1AJVgD32n0r60+N3w8l+Kvwq8ReF7e5+x3t7AG tJi+xFuI3WWHedrERmSNA2ATtLYwcGvmv4q/Gm2+AXh+98dWsc2oDSWTNrbOIjeI8qIImLAh VYsuThiv3gCygVxPhD/gsZ4BvNLml8V+BPEei36ykJBo81vqELRbVIdpJGtyGzuBXYQAAdxy QPjOHMZm3i7hsbxFg8tlCk6koSipxkk+VNpP3W7RkrvlS1R01o08BKNKU9bH5cfEnTtR0f4n +MbDV7f7Jq1rrN7BeW+9X8qZZ3WRdykg4YEZBIOODX29+zL/AME/Yv2qP2cdI8SaxrV14RvY klstB1G22XUc8S307TtPbEqSoZnRNskbbt7MGUJu+Kfi54ysfiN8X/HnizTI54dN17X7/VLW O6ULKkU9zJKgcKSAwVxkAkZzya/Sz9iL9ur4H/Bv9mDwZ4P8YeN/7I8R6b9t+1WX9k30/l+Z ezyp88UDIcpIh4Y4zg8giv6S4nhjMFw3lk8vco1KM425b3/hTi723Vn10vY8ei4yrTU9n/mj 5l/bE/4J6zfso/DHTfFZ+IY8VC/1ePSPsf8AYn2PZvgnl8zf9okzjycbcD72c8YPy94m8Bf8 IbpHgrUft32z/hJdHfVvL8nZ9m26heWfl53Hfn7Hv3YH+sxj5cn9Iv8AgpV+0V8NPjr+y/4T m8CeNNJ8Qyv4qhuDYwzeXexxJbXsbPJayBZo13FRl0AO5SMhlJ+AfihqllqPhT4RQWt3Bcz2 PhWe3u4opAzW8p1zVZAkgByrFJI3wcHa6nowJ9fhmtjsfgcHjcxcpVvbSjeV0+Xkk7W0Vrpa 2v0uZ1lGEpRhtY7b4D/sNfEv9p3wZ4g8WeD49JOmaNK1qsOo3vkzahcrEJWggAVgGCtEN0pj TMq4bhyu4f8Agmf+0Y7Zb4XYJ/u69poH6XNfeX/BHv8A5No8Tf8AY33P/pFZV9cfE/4j2vw4 8PSXRjjvtXnR107THm8o3cwHClwrFIwSu6Ta20HgMxVW/NeKeOMVkWa41TVL2UZaucU0rK27 f9X03Oyhho1YR3v5H85Ok6Tea7cWmmafaXGoX97Kltb2dpE0s08jsFWONFBLMxIAUAkkgCvr b9mz4ba18OoBp/xE8Ia7o9tcXU01hp/irT54IGYpCJpIYZlCliFhDuoyQsYJwBVL4A/sj/E3 wn8afAPia80a1l8M6Nrtlq0mrWuo28sNxbQTpNviAfe3mKnyZUcuu7aMkfrV8Yfg/wCF/wBp LwFBDLcCG6jDT6Rr1qm6aylPBODjchKhZImxnb/C6qy/N+KfFGUcX5asiyLGUq0nTjKUqc1K UbS0i3Fu17ap6p2va6NsDQqYeftasWteqPlK+8DfDHxFoKW154R0ePY4mE1lD9llyARgvEVJ XnODxkD0FfPv7Sfg6z8E/sOvp9hdC8tD8WFmjlIAk2nR3AEmBgsAAMjqADgdB9SeFf2FvH6+ I5LXxD440uPwvFISlxpcUrX1zGJBhTG4CQs0e47t0oVsDa45rkv+CofgPTPhn+xv4D8M6Obh rDT/ABZbqkl3KZZZGa0v3d3bpuZ2ZiAAo3YUKAAPwzwe4XzTJ+KcPVxdV+zckuVu93e9/L9d Pl6eYVoVKDUVqdH/AMEfDn9mnxP/ANjfc/8ApFZV9G/tc6rZaN+yz8XJ9QvLexgfwrqVsstz KsatLLbSRRRgkgbnkdEVerMygZJArwX/AIJI+GdS0H9lq9vr628i11rxJd39hJ5it50CxW9u XwCSv723mXDYPyZxggntP+Cmoz+xD8R/rpn/AKc7Wv3TiBRxPFteKejrW/8AJkmeZS92gvQ/ DGEYir9bf2xde/4V5/wS18FeG9c06/s9Y1jSfDehrayQbHtbqKKG5kWdXKsmFs5VIwWDlQQB kj8kk4i/Cv2B/wCCxoz+zP4W/wCxxtf/AEivq/Y+Mffx2T4ZrRzb/wDAeW35nn4fSNR+R8Ef 8E+PDGm+LP2xfhlY6tbfarWK8nv0j8xkxPbWs1xA+VIPyywxtjoduCCCQeC/aaGP2l/i/wD9 jhrH/pbNXsn/AATA8Nalr37Y/hK9sbbz7XRbTUL+/k8xV8mBrSS3D4JBb97cQrhcn584wCR8 weIfE+p+NNe1fxFrVz9s1nV7ubUL258tY/NnlcySPtQBVyzE4UADPAAr7Cl7/FNSSelOhFW7 Nym/yS/A53pQXmz9EtI/Yb8NfFjQfDmteLLvXNO8SQeH9NsNQi0y5g8sNbWsVuucxuMqkcce VO07AeSSx8++I37OXhX4E/Hz4c67Z3FvY+BNX12x0rVLXUbllWyhklUTSLcMwZEMKybmLAp8 x3YbC+4+E/jXZjTkP2hcbfWvnn9pe88R/tIfEXwV4B8CQNruuXBvJl0tLyKBZGSISBmMjqgK xxzEFiP4gOTg/wCb/hrxPxdxHxdRyrPMdN5fNVvawleVNU+SU37vZOK5W2+Xa/K5J/X4yhh6 NB1KUVz6WfW5+pHgL4x/BHQ7DRfCPhL4heCFiVo7LT9LsfEFrLLLI7YVFHml5JHdupyzsxJJ JOfWa/CbVP8Agnn+0do2l3l/c/DG5eC0heeRLTVbC4mZVUsQkUc7PI2BwiKWY4ABJArzsfs3 fGQ9fg/49/8ACYvf/jVf2EuA+GK6SwedRUVpZxi/ynG33HgfWqy+Kn/X3H9DtFfzxNffF/8A ZrI3p46+FX9t/wB4Xuj/AG/yf++PN8vzffb5nbdyo/at+Lj/APNXPHP/AIUt7/8AHapeF1Ks 74bNaUo9G01f5Jv82L6818UGf0OUV+FOlf8ABR39oHSNLs7C3+JU7wWsKQRvdaZY3ErKqhQX lkgZ5GwOXdizHJJJJNb3hn/gp/8AH/Q9btr698W2PiK1i3b9M1LR7VLebKlRuMEcUgwSGG11 5UZyMg8svCXObN0sTQl6Tld/fBL8fmV9fp9U/u/4J+2d1dQ2NtLcXEsdvbwoZJJZWCoigZLE ngADkk1y9j8V/CWo3lxbxa3ArQbt8s6tFCdrYO2VwEbnptJyORkc1+efgH9rLxX+0ZpkeveP 5NI0bS9MeSSG100Nb2aqq/NcyeZI53D513M2FVTgDcxb0f4bftM/Cv4k36aF4f8AE0N7rDxN IlpLaT25kVRlthlRQzAc7Rk4DHGFJH8icXZ/xBkWZYvBZdlzxEMG2q04qU4QtveUFywSs1eT 6PRWZ72HpUqsIynO3NstmfeVFeSfAHxlNrtvreiSu08ekNC0ErvkrHIHAixjOFMRIJJ4bAwF Fet19pk+Z085wFLH0otKavZ7p7NfJp69dznqQdOTi+gUUUV7JmFFFFABRRRQAUUVFdXUNlbS 3FxLHBbwoZJJZWCoigZLEngADkk0m0ldgS0VlaX4s0TXLk2+m6zp+oXAQyGK1uklcKCAWwpJ xkgZ9xS+JfFOjeC9EudZ8QavYaFpFtt8/UNTuUt7eLcwRd0jkKuWZVGTyWA6mlRnHE29i+a+ itrd9tAatualFfEfx0/4Ks/Df4a6m2leCtNn+JOoQzGO5ubW5+x6fGA0iuEuGRzKwZEIKRmN lkDLIcYP54/G/wDbp+L/AMcp7hNZ8Vz6Jos0Mlu2g+HHeysmikjVJUkUMXnVwpJEzyAb3C7V Yiv1bJfDjOs1SrYiKw9Lfmno/lH4vv5V5nDUxlOnotX5H6eftYft7/Cv4L+HPEHhtPElxrHj Ka2uLFLPwwVmm0+dlmjDyzb1SJo5Y8MgfzlJU7Mc1+cOg/t5+LL+8h0jSbOz8MQO6+RcptuJ eEx5bmRdhDNkghAfur6k8b8Cf2L/AIr/ALTkUc/hbw8LHw5ITjxLrha10/jzB+7faXm+eJoz 5KSbGID7Qc17p8b/APgmjc/st+C9T+Id1400/wAUeH9GSB55J7OS0nSSW4SFQkC+arYaRDuM g6n5cqCfmuOODuEaMXhpJ4utGFo2vJqbfSK93dR0fM7aK92nthsRiH73wr9DiPjL+198Rrv4 bJpTajDBcy3CI2rWkIhunGWfaSvyAYAX5VUkAZJ+bdD8L/8AgqJ8f/Bk6C/8R6d4wsILQWkd n4h02NgCNu2UyweVM8gCkFnkbO9iwLYYaX7Jvwr0X9rH4tr4MGprFpVtYvq2pyGAlzbRyxIU jDrt8xnmQAsCFAZiGKhW/SjxN/wTt/Z28W65c6te/DKwt7q42749LvbvT7cbVCjZBbzJEnCj O1Rk5JySSfmuAqWT8L0JUMxyvlvJyfupOV9rp2kkui27LVm2KdSu7wmfg7a58nB6jgiv0U+F n/BWz/hW3ww8IeEf+FVDUf7A0ez0r7Z/wkflef5ECReZs+ytt3bM7cnGcZPWvjj9pL4Z/wDC nf2gviF4PTTf7IsdN1m4/s+y8/z/AC7GRvNtPn3MTmCSI/MxYZw3zAivsD9mv/gmb4O/aI/Z e8O+OF8X6/4d8Yawbn95sgutPh8q+lh/499iSNmOL/nsMM27kDaf6yz7E5BVybB43OqLqUpW UbOSaco3u+Vq+i8/JHhUo1VUlGm7M8U/bo/an8N/tfQ/D3V9O8JzeFvE+kw31vrDTGKdZInk jNrHHcKFeVVCzNtdECNMwXdksfp7/gn5+3l8L/hT+z3pnw/8f6jN4V1Hw9NOtvdG1nvIdQin uJZ9y+TExjZGkKMrDBARlZtzKnz9+2F/wT1l/ZM+GmleLf8AhYY8VfbtYi0n7H/Yn2PZvgnl 8zf9okzjyMbcD72c8YPnH7L/AOxz41/ax03xBc+D/EHhixuNCnihvbHWZ7uKZFlVjFIDHbyI ysY5Rw+4GM5UAqW+cq4TgzHZPGX7ynh1J2km9Hfb3lLT3rK61vu2tNVLERqdGz9c/Cn7f/wA 8aeIbPRdN+I1mt/dsViOoWV3ZQkhS2DNPEkak4wNzDJIUZJAPzL+0/8ACgftv+IdC1xLmz8G JpKT29vP/ZguL26tnMbRpcSCVR8jLK6oMqpncAnlm+ZdR/4Jw/tCfDnxglyvhC28S6VpM0N3 Jqeh6nBJHPGoWR/KhkaO4dh8y7fK3MykKGBBP0H8Nf2g/DNolvZXGqx205GP3ysiAgZ5cjaO nrzX8o+KmbYjgzGYLFcA4ublyylKTjCbT2s04ctrPZx316K3u4KmsRGUcVH80cR8SP2FJNK+ BWm6BpXiKbU9X0O+1HWYme2SNL2W5ht42hCl/wB2MWduAxc4JkJyGUJ8RXGoeKNcOieDJJta 1V7C5ks9K8Pu00xt7ieUeZFb2/Ox5JMZVFBZsZBNfpp8Q/2pvDOnai+my3M99eNIUuHtYtyQ NxnecjPU5CbiNpBAPFerf8E5rLwLr/grxl4q0DwdY6V4ij8Tajpl94gJE13qIbyJ2IkYboov njAhVtmYg+AzkD1/CHxY4unhsb/rFTeIs/aU5yjGPJKbaktEtJXvFKOiulaLSM8fgKHNH2Tt 0a9D5d+AX/BInxR4oMWp/F7W/wDhEdPOf+JDoksVzqDf6xfnn+eCHBETjaJtysQfLYceif8A BUj4P+CPhL+yf4J0zwf4V0rw9a2niy3iiNlbKspDWFwrs8mN8juLeDe7sWcxIWJKg1+jtfDX /BYLSr3UP2XtDuLWzuLmCw8V2lxdywxM628RtruISSEDCKZJI03HA3SKOrAH9HwXEeY55n2F q4+rdc6storXov8AO78zklRhSpSUV0PhP/gmwM/tsfDY++pf+m26r90a/C7/AIJrf8nrfDf/ ALiX/ptuq/dGva8VF/wt033pR/8ASpmeB/hv1CiivI/jr8bE+HT2OgaW0UniTVI2kQs6N9ih B2+cyZySx3BMjaSjkk7CrfhuPx1DLcNPF4h2hBXf+S83selCLm1FH4E+NPBl78OfGXiLwnqU tvPqOg6jc6Vcy2jM0LywStE7IWCkqWQkEgHGMgdK/or+IvxO8KfCTwzN4g8Y6/YeHdIi3D7T fTBPNcIz+XGv3pZCqORGgZ22nAJr4b/4Y5+FPjXUNT1zV/DU2p6rfzyX19eSanebpZZHLPI2 JcZZ2yfc14J/wUc8JXLto3ia58WalqUqyPCmi6rqrzqikKHmtY5ZCV5WFZFjBByjEDaSfqcF 4s8L+KOdZTw7FVqErTTlKEbOVotKPLOTs+WS5mkk7XWrthLA1sFTqVtH8/8AgHxdoHiXWfCs V9/ZWr32kfb7OTT70WF08P2q2kx5kEu0jfG2BlGypwMg4rqPCfwg8Ra5p2keJNT0XVdM8B3t yYB4ge1dLe4Klg8cEpUqz/JIO4BRs/dIruP2E/Bvh34h/tYfD3RfGNha6noNxdXDy6ffH9zN JHazSwrIMgODKkf7s5V/usGDFT+9ulaVZaFpdnpum2dvp2nWUKW9tZ2kSxQwRIoVI0RQAqqo ACgAAAAV+/eIHF+KymP9l5WvZVKkE/aNJyUXeKaXfTS+3Y8vCYeNT356pPY/O7wX8Ita/bJ0 iTRr1NS0PwDOYpbzXli8szpHOD5VozqVkctEylgGWPBLZO1Ho+Kv+CLelX2s3T+HvizqGl6K +0QWmp6Il7cJ8oDb5knhVstuIxGuAQOcbj+lNFfzJwrPFcHYGWX5VXlGEm5SXRtpJu2q2SXy PZrqOIlzTWp/Nn8RfBH/AArL4leL/B/23+0v+Ef1i80n7b5XlfaPIneLzNm5tu7ZnbuOM4ye tfQPwX/4JnfE/wDaD+Gmj+P/AA7r3hGy0fV/O8iDVLy6juF8qaSBtypbOoy0TEYY8EdDwPJv 2mv+Tmfi/wD9jhrH/pbNX7Ef8E1P+TKPh1/3Ev8A05XVf09xZmFfBcMYKvSa5nKKd13hJ/oe LQgpVpJ/1qfjx8Zv2PPi9+z54XtfEXj/AMI/2Bo91eJp8Vz/AGlZ3O6dkeRU2wzOwysTnJGP l65Iz53L4Y1PQLLRb6/tvItdbs2v9Pk8xW86Bbia2L4BJX97bzLhsH5M4wQT+kf/AAW5/wCa Mf8Aca/9sK+GfiaP+Lf/AAQ/7E+4/wDUg1ivP4QxtXGV8LXqJXm5bX6KXm+xWIioqSRy+n/D Hxz4k8P6h4k0Lwl4g1bw5pokN7q+n6bPPZ2vloJJPNlVSibUKs24jCkE8Gun0nx7Pp3gHQ4L q6uNRkgSVLSyluGKQRmd2YIDkRoWZmwowWZjjJY19Y/sk/tn6D+yp+x34lggWDWviBqfim7b SdEdjtjX7HZr9qudpBWFWBAAIaRlKqQA7x/I8svjz9pD4tbV+3+NfH/ii84HBluJCPwSONEX /ZjijT+FE49bNeHp8U4jELO5OngKNXm+Jr2nKmrW6RTesl2stbtRCsqCXstZNfcdP8PPH+oz 3LXlnLcaPqtlgC6sZ2Q/OpUlGBDLn5gR6Hqc1+pv/BOn4keJ/iF4U8Ytr5lnt7W9g8m8FosU U0ro5lAZQAzqqwhlHCqYzjLEn5L+Hn/BOP4s2+n2uk3PhG00S+nYyXWuX2sW7woQpO0rCzuV z8q7UJywJIG41+lfwC+B+jfs/fDu28L6RPNesZTd319PkNdXLKqvIEyQi4RVVB0CjJZtzN/H mJy7AVOIq2NyuhKnh4NqHN8TVrPXflbvJJ+V9UfQRnJUlGbu+p6PX5jf8FpRm4+DB9BrX/th X6c1+ZH/AAWkGZvg19Na/wDbGv2DgKPNxLg15v8A9JkcGK0oyPpz/gmsc/sU/Dr66l/6crqs b/gqV4n0zQf2M/Fdjf3PkXWt3un6fp8fls3nTrdx3JTIBC/ureZstgfJjOSAdj/gmmc/sUfD r66l/wCnK6ryv/gsgM/sy+Ff+xxtf/SK+oqQVfi6on1xEn/5UbBaYden6H5O+AfBt78RPGnh 3wppstvBqOu6jbaXbS3TMsKSzyrEjOVDEKGYEkAnGcA9K/TP/gs/4yvbLwV8L/CccVudO1TU r3VJpWVvOWW1ijijVTnAUreylgQSSqYIwQfz+/Ze4/aV+Ef/AGN+kf8ApbDX3L/wWqGZvgx/ 3Gv/AGwr9p4ivV4nymhLZKT+dv8A7VHm0dKNRngH/BNbx1feAfjtrl5p1tBcXdz4cmtVNzuK Rg3do5YgEFuEIxkctnnGD6n4M/4Jx2PhvxnpGv8A/CXQ6tpWnalDff2JquirPHdQxyh/s8ze cFcMo2MdgBBPy84r5G+EHxNPwn0vxTrOmbE8VXEENhps7gOIVdmaZyhYA4EaEEhsNsBGCwP0 7+yL+1j488a+MdY8P+L9bj1XTF05r2EvaxQvFKkkafKY1UEMspzuBPyrgjnP4P4s0vEbL8dm /E3DGMjh8HQhTpzjJRc6nuxbdNSpzWntLOXNCV1JK9lf08A8JONOjWjeTba8vXXyPsV/gl8B v+FdeM/HGueADBP4etbrVNYsNG1K5iDrHE07NbwLcKqI4VgiHaoKlQcLur4D/wCCYuhax4o/ bI8J6lBG97Fo9pf3+ozyTLuigNpJbK53HLfvbiFcLk/NnGASOZ/bo8aJ4g+K+nRm4aW1g0tN sJclEdpZdxA6AkKgJ77R6CvE/BvxI174e6nJqPhTxFqnhnUJYTbvd6NfS2krxFlYoXjZSVLK pxnGVB7Cv0Dwl4ahW4L+uVcTTWKx1G0vdty3clrbdtavRK/RpHLj61sTypPliz+kyivwW8G/ t9fHjwPpkthpvxO1W5gkmM5fWEh1OUMVVcCW6SR1XCj5AwUHJAyxJ6jS/wDgpp+0JYanZ3U/ jqDUoIJklksrrRbFYrhVYExuY4UcKwGCUZWwThgcGrn4R5u23RxVGS6e9JN/Lkt+ILH0+sWf uDRX5BD/AILAfGI9PDngX/wAvP8A5LrsPB3/AAWR8S2WmSp4q+G2k61qBmLRz6PqUunxLFtX CmORLglt247t4BBA2jBJ8mr4V8T0480KUZ+SqRv+LS/E0WOovd/gffn/AAyt8Ff+iQeAv/CZ sv8A41WD4y/Yj+A3jvS4tP1L4U+GrWCKYTq+i2Y0uYsFZcGW18t2XDH5CxUnBIyoI+UfDX/B ZXR7vW7aLxB8Lb7TNIbd593pmtJeXEfykrtheGFWy20HMi4BJ5IwfQtN/wCCt3wh1XUrWyh8 NeNxNcypChaxswNzMAM/6X0ya83E8HcXZapVauHqRUU5NqSaSW7vGT2sXHEYeeiaPD/26v2U rj9nXwBrmufDDS/sPw2lsYoNRt5NRaV9PlknSFgvmt5jJL5qY+aQhjJkKm0V8f8A7JWh+JNa +Onh5fC2h3+vajAs7NDYQl/KR4mhEkjfdjjDyoDI5CjcMkV+ocfxF1j4t6jdX+rXU1tpt1tW PRoZ2NrFGrbkDLwJHB5LkZJ6YAVV37DQbTwR4kh8U6VY21j4hithb/bDABJLbMQ/kueC0THD bc4zhhggEfzfhfGvJ8mwma5FPAzqQx3PGdbnV/fjyN8jjrpzSu5p3b0PXll1SpKFVSty2svQ 9W/Zz+G1/wDDzwCja9bxQeKdUc3WoqjpL5PURQeYqjIRMZGWAd5drFSDXqdY/hDxLB4v8NWG r242Jcx5aPJPluCVdMkDO1gwzjBxkcGtivtsupYajg6UMH/C5Vy26pq6fz3Oebbk+bcKKKK9 AgKKKKACiiigAr40l8fyfGDxRLrl87GxV3TTbSRQv2a3LfLlQWHmMApc5OSMA7VUD7Lr8w9L 1rU/hB4t1LwV4lMEGt6Q6xTiCUPG4ZFdJEP910ZWGQCA2GCkED8g8SqWMr5dTpYZvkbfNbrt a/4/0jvwbipts+m7rS4ILaC4jxDKMSwyxPh0ZTwwIOVIIyOh71+Xf7aPxRT4l/ExLu08d33j TTLWMwRW9xcTSwWEqKkT+QGUR7ZFiiYvGW8xlZmJyCftnX/iRba14bv7A6jcWP2u2kg+1WU3 lzw7lK74352uM5B7EA1+emjfstfF3xNoviHWPD3gfUvEuk6HcraXN3pCCcySMwUCGIHzZuCr EIhKKys4UHNfX/Rho5fk+bYzMczxrpVYxUYU3y8s1Lm5pPmTu4tRtyuLV9W07HPnTnUpxhCN 11ZZ+DH7PNz8XLzT59U8feBfh94cuMvLqfiPxLZRXCIswjdVsxL5/mY3uqyLGjBP9YoZSf1l +BH/AATb+DXwa0xW1TQYPiJr8sIjudS8UW8dzCSVj3iG1YGKNd8ZZSQ8qh2UysDX45eJfgr8 TfBOh3OteI/hv4u0DR7Xb5+o6poV1bW8W5gi75HjCrlmVRk8lgOprhl1GJhyR+Nf3PnWXLif +HnPLD+VRVvwmn99/RHzVKfsN6ev9eR/TfXgv7eHgj/hYP7H/wAVNL+2/YPs+jvq3m+V5m77 E63nl43DG/7Ps3Z+XfnDYwfxR0n9pb4p6Jpdppum/FDxlp+nWcKW9taWniC7iigiRQqRoiyA KqqAAAAAAAK7KT9uT423nw8v/BF58Q77U/Dt/Z3Gn3UWp29vd3E8E4cSo1zLG0xyJGAO/KjA UgAY+Ap+F+MpVYVcLjaUnGSevMtE79pa+X4nU8bFq0os2v8Agl3qt7p37bPgS3tby4toL+HU be7ihlZFuIhYTyiOQA4dRJFG+05G6NT1UEfu5X823wv8b6l8IviL4e8aeHLlrbWNEvI7yAGR 1jl2n5opNjKxjkXcjqGG5HZehr9B/hB/wVW8f+PdXu/DmueEdDF5qMLR2Oq6G0tt/ZziOTMs kcxnE3zeXgZQAgg7twxwca8HZlhKNXOHyulRpuUmpK9o3baTtfTpu7WSbsisNiISap9WzwD/ AIKeeGtT0D9s7xde39t5Frrdpp9/p8nmK3nQLaR25fAJK/vbeZcNg/JnGCCft7/gkHrlxqX7 NOu2NzqEt1/Z3ie5it7aWcv9lge3tpAqKT8iNI0zYGAWZz1Jqlovw18G+MpF1HxH4c0jxFqT g773VrKK6mfLFzl5FLHLMzHnqxPUmu/j0PT/AIfWtrF4atrTQP7NZntY9KjjjihYkltqoNmG LNkYw245zk1/MWa/SIwOMyHD5D/Z0+anKKc+ZWUUmrpWu5Wto7J66o9qnlMo1XV59yr/AMFU PBtl4n/ZA1zU7qW4jn8OanYapaLCyhZJWmFoVkyCSvl3chwCDuVTnAIPz1/wRP5uPjZ/v6N/ O/r6S/apuL34+/sFfEWSzk0+11S3sTe3sXnsY4/sNzHdSrwCyu8MBZEbvIgLYO+viD/gjuc/ tVeK/wDsTrn/ANLLGv3vKMTTzLgitUpTvH2ikvSUVJenwv7zy6kXDEpPsfsbXyH+0H/wT00L 4oa/feJfCWr/APCL63efabq8tbpJLm2vruR2kEhYvug3MzBtodQNu1AVO768or8vxGGpYqHJ WjdHcpOOx+R/7WX7DviX9nz4Ef8ACcWviWHXJ7e4todYtra0EKWMUuUMkcry7pQJ2hjGIwxE m7ChTj6J/wCCPgx+zT4n/wCxvuf/AEisq5T/AIKC/tLaXL49k+EusaWdR8MWv2aXUrCTUHsW 1G4ZBNGivG25kTfbsARjeGypIjZfKPgr+038Of2Z7DXfEHhXwrd+E7yfyPtunPfT6ha6nEkg CRl2bMUg82Xa4TCcn58mNuqhxbluUZJU4cpYCq61WtBqpCMJRkk1GzftPaPlblZRhJLZbsh0 J1KqrOSslt/St+J+tNfMH/BTE4/Yj+I/103/ANOdrTP+HnH7NP8A0Un/AMoWp/8AyNXCf8FD fj98MPG37Hvj7RvDvxH8Ja/rFydO8jT9L1y1ubiXbqFs7bY0kLNhVZjgcBSegNfRZVg8VQzH DSqUpK04vVNbSV+hlUlFwlZ9D8xv2TtVvdH/AGnfhLPYXlxYzv4p0y3aW2laNmiluY45YyQQ Srxu6MvRlZgcgkV/QtX87f7MtzDZ/tF/Ci4uJUggi8WaTJJLIwVUUXkRLEngADnNf0SV+meK tnj8K+vs/wBWceB+GXqFfE37ddlceDvib4P8aM8z6dqFi2jykQHyreWGR5U3S5xukE8mFIBx AxBPO37Zrzf4h+L/AIceJtL1bwj4nuLbWbC6iaC9so4JbhBhyCpaJTskR0zwQ6MqkYODX83Z /SweIwE6GNqxpxl1k0lfpq2j2KTkpJxVz5F8OfFe2Nkh89enrXyR+3z4yHiO78GtAGmW3+2B 2QEhS3kYB+u0/ka6j9tKT4bfs9XVt4c+F/jXW/Efiy2mK6tZagqTWtrE0cckbCdI4wzEOPlT zBy25oygWTgf2Zv2Rfif+2jrZ1PUZ7rwz4OSKSQeKL+wd7d/mdFitIyyC4bzEZWIfCBDubds R9vC7w5xXCHEWF4txtVUKNOM5Rk9XNTpyguRdeZSdn13Satecbi44ilLDxV2/wBGfNcEGoXW l3+owabd3FjYbPtVzHA5it97bU8xwMJuIwM4yemaz7PxPqOlalaahpl1Npd/ZzJcW15aStHP BKjBkdHUgqwYAhhgggV+03w//wCCbun/AA+WTSbH4g6gnhSS4mmazg09I759ykIWuS7IXGI9 zCEBgpAVMjHvFt+yl8F7aCOM/CfwXcsihTPeaDbXE8mBjdJLIjPI56l3YsxJJJJJr9/reKua 5jWxFDE0eTD3tBqS5pRtb3lbS+uilazStpd+UsDCCTT1Pwhtv2pPjRNMqt8YfHqr3I8TXvT/ AL+165pP/BRr9oPR9Ls9Pt/iTPJBaQpBG93pljcTMqqFBeWSBnkbA5d2LMckkkk1+qfjP/gn 7+z1481SLUNS+F2kW08UIgVNFkn0uEqGZsmK1kjRmyx+cqWIABOFAHB+Mv8AglN+z34n0uK1 0zQtY8HzpMJWvtF1meSZ1CsPLIujOm0kg5ChsqMMBkHqyvjHIMNT9ni8vjUbd7yhCVvJXvb5 LX7hTw9WTvGdj8YvEXiXUfGninW/EGsXP2zV9Wvp7+8udip5s8sjPI+1QFXLMThQAM8ACvrb 9mX/AIKT+Mv2evA3hzwT/wAItoWv+EdH+0/u901tfzebLLN/r97xriSXP+pOVXHBO4fMnxb8 GWXw5+L3jvwnpstxPp2g69f6XbS3bK0zxQXEkSM5UKCxVASQAM5wB0r6a+En/BPbRfH37NFj 8avE3xjg8CaBLFdT3UVzoJuVtVhupLcAOLlDIztGNqKm4s4RQxIz+s5lisl/sjDyzah7SjUa UYpSupST5bKOqdrpW76HBCNT2j9m7NE/7QP7R8f/AAUD8efDnTLjwmvhCy8NveTXKnUzem7i mNvuQYiiKH9wBnJ+/njbg/U3gT4I/Du/0+wt7nwX4cuxDGIYftWm27CNSxbaCy4UbnZvTLE9 zX5gfBXxJJ4a+JEZUS3AaKRE2IAxUAOSRnj5UJ6nH05r7N8KftVxaTKYb3SrkWyA7JYJFd2O RjKHaBxn+I/j1r+A/HSjj453SwfD6nQoUoJxgpyTUm5c7u5c127rfRK1tz6nLHF03KrZts9f +O37MngLxf4AudG0/RNN8OTwO9zZ3Wk2kcPkTlQC+EADqwRQwP3gq8gqrL7p+xD+xv4a/Zh8 Dx6ktzZ+JPHOt2yNqPiO3+eHymw4t7RiMi3B2ndwZSA7YAjSPwCD4my/EkWOm+Fopta1HU2M NnbQqVeVhkHhsbQNrEs2AACxIAJr9B/DehQeF/Dul6NbSSy22nWsVnFJOQZGSNAgLEAAkgDO ABnsK8DwzzniRZXicqzDETlh+dSSk27Sd+ZJvWz0bV7c2trtt64ynR51OCVzSooor9VOIK/I z/gs9461Gf4y+APCmy3TTtM0B9UhlVD5zS3Vw8UisScFQtlEVAAILPknIA/Vrxp4hPhHwdru ui3F2dLsJ70W5k8vzfLjZ9m7B2524zg4z0Nfk3+1J4Q8P/Gi8vfGOv8Ai238QfEiFIxNoJ1B UNvZBWkMdtaIS6JGH835ifk8x2ZmJYzheKsLwzmVGrWjUlJqTXs4tuKtZybuuVK9m29L6hKh KtBpW+Z+ln7K5Lfsw/CAk5J8H6Pyf+vKGvk7/gst4m0y1+Bvgbw7Lc7NYv8AxINQtrby2PmQ W9rNHM+7G0bWuoBgkE7+AQGxz/7JX/BQDw38KfC6+Dfi54i/svR9Os7e38OXiaXJN5cEKLEb ZzbozHaoiKMyEn95ucnaK8S/4Kf/ALTfw0/aOm+GP/Cu/En/AAkP9jf2p9u/0C5tvJ877J5f +ujTdnypPu5xt5xkZ+z4RjPNM2w+NhTl7OU27tdr7vVbq25z4hqFNxvqePfsE+DbLx1+198L 9Nv5biGCDUm1RWtmVWMtnDJdxKcgjaZIEDDGSpYAg4I9e/4K+6ha3v7VWiRW9zDPLZ+E7SC4 jikDNBIbq7kCOAflbY6Ng84dT0Ir56/ZZ1vUPDvx48L3ul30unXq/a4luYCBIiyWkyPtP8JK swDDBGcgggEfptpvgbwv8QBayeJ9E0rxJch3dZtato7lleQgu26UHBYgFj3wM9K9DxX8TsP4 fcYYKpiMNKtFUU2otK15VFpdO7ulfbT7iMDgni8PJJ21/wAj8dUO1mY9ABzX6d/sp/8ABNjx fp3hi31nxZ4og8Mx63HZ30um2NpM9+sLKWa2mEwjW3mQOR9yTDMwIIQbvUvFXwg8AQaFFp6e DfDp06zv49TXTRp8QtJLiNlIZ0QAOGCBGH8SEqcqSK9GP/BSX9nMf81EP/gj1L/5HrxafiXU 8a8qrYDK8tqqnRmnUik6nMnd07uC01jJ8r6xTTettHg1ltRSnNXe3T1Oe/b88E6P8Pv2APHf h/QLRrLSbRrAwwNNJMVL6tbyN88jMxyzseScZwOABXy3/wAEk/hX4K+JrfFUeMPB+geK/sI0 n7L/AG5pkF59n3/bN+zzVbbu2JnGM7RnoK9T/wCCo/7RXhbxH+zRb6D4F8feHfEU+q6/aQan p+jala3s0lmkc0+SqMzIonhtzvGOQFJwxBh/4IzaFpMfwv8AiHr8V3IdfvdYgsbuweVCIbeC DfBIEA3Lve5uV3E4bygAAVbP3GCTyngnF4epF051KkeVWcdE4eSS+F6HNL95iYtapI+tdV/Z F+CGsaXeWE/wj8FRwXcLwSPaaDbW8yqylSUljRXjbB4dGDKcEEEA150P+CZf7Ng/5pwf/B9q f/yTX1BRX5hTzHG0f4daUfSTX6na4Re6PiTxN/wSI+B+va5c39hfeL/DdrLt2aXpeqRPbw4U KdhuIJZTkgsdztyxxgYA5nxN/wAEbPhtc6HcxeHfHXi7S9Ybb5F3qhtb23j+YFt0KQws2V3A YkXBIPIG0/oDRXrUuJs6o25MVPTzb/Pf5kOjTe8UfmKv/BFiYf8ANaQf+5V/+7a891L/AIJP /FzwHql9r1r4i8M67pGiyS31vDaNd/2hexQkuiLbiBlE0gUDyxIwDNgM3U/r5RXoz424gqUK mHnim4zTi7pbNWfQhYakmnyn5dfC74rWxsYf3wGAOCelejat8XbW3052adQAp5Jr52/bb8P3 3hX9o3UdL+D3w71WPQLG3iXU5dPsLiW1nvnZ5ZjbshdFRUkiiKBVCPE6hAF5+qP+Ce/7Pbal 8PbH4k/EbSWk8UT6nNNo9jdtMn9nQQs0StJA6qDMZFkcFgwCrAybGzX8q4rwpqVpxxftafs5 PpOLl/4CnzfekvM9uOOS92zufUnwK0jUdE+E/h631aI29+8T3MkDKyvEJZXlVHVgCrqrqGUj hgRzjNd5RRX7ThcPDCYenh6fwwSivRKyPPk+ZtsKKKK6iQooooAKKKKACvOvi3+z/wCBvjZZ FPE+ixy6gkXlW+r2p8m+thhwuyZeSqmRmEb7o93JU16LRWdSnCrFwqK6fRjTtsfzkH40eKby zZDdQxqykZjRty8dQSxGfqDX9AXwUk8NXPwh8G3ng7Sm0TwvfaTbX+nWEiBZIoZo1lUSYZsy Hfl23MSxYlmJJP4Y/tneDr3wL+1j8VtM1CW3mnn1641RWtmZlEV4ftcSnIB3COdAwxgMGAJG Cf2E/YH8Y3vjn9j/AOGOo38VvDPBpz6Wq2ysqmK0nktIickncY4ELHOCxYgAYA/YOK+GMlyz JMFmeUYaNL2nxOPXmjdXv6Py8tTz6FapOpKFR3se/wBVdV0qy13S7zTdSs7fUdOvYXt7mzu4 llhnidSrxujAhlZSQVIIIJBq1RX5InbVHeeXf8MrfBX/AKJB4C/8Jmy/+NV5eP8AgmV+zWP+ abn/AMH2p/8AyTXrvxu+Pvgj9nvwjca/4z1qCwVYZJbTTkkQ3uoshUGO2hLAyNukjBIwq7wz sq5YfmJ+0R/wVU8e/EX7bo/w7tv+Ff8Ah2TfF9v3CXVriM+amfM+5b7keNsRgyRumVmIr9E4 a4d4iz+XNl7lGnfWbk4x+/dtdkn8jjrVqNL49+x8afFzwRbeAPjN498JabNdz6ZoGu3+l2s1 yytK8cFy8SGRgoUsVUE4AGc4A6VVh1M6Hrd7eaBPf6TbySOLZXug9xDCXyiNMiR7mACguqoG IPyqDiqmta/datqd3qGoXk+oajeTPcXF1dSNLNPK7Fnd2YkszMSSSSSSTX3V+yz/AMErtW+L vhjQ/GnxF8SHw74Y1eziv7LSdEKy6jcQSo5jeSV1MUGQYJAAspZXKsImHH9F42vknC2BjHNq nt52s07tSe9uXVPbS+3keRFVa8v3asfNv7K3xJ1zwN8XdMh0YzT2OoN5OpWSShI3hAP71sgj MZO8YwTgoD85B+99e+LltFYOWnXAB6mvbb7/AIJvfBeOG0i8OWGseDFhMhk/sbU3kNwW28yG 5Ex428bcdec4XG14D/YT+G3gnxGmr3T6t4u8uJ40sPEksFzaBmGN5iWFA7AZAD7lG7ONwUj+ CfFDLv8AiIvESzhUIUUoqF18U1Fu0p20bSdl1SSXM0o2+pwU/qlH2d7mH4F+GviDW/2LPiBY 2kX27XPHOiapd6ZYbo48/abHybZPML7P3gWN9zFdvm4YDaTX5uf8EwPE+paB+2t4PsrC5EFr rlhqFhqEflq3nwLay3ATJBK/vbaFsrg/JjOCQf2L+MHxRi+GehWzQxxXWtajIbextZHAGQMt K65DGNPlzt7ui5XduH5N2XwM179iD4k+Bfifout2/ii7tmvIVjvdKeO1jd7dogrlJ85ZZpGU ZH+rPUA19hknFvD3DWV4rhjF11GrOEfZx5ZNyajK+qi4xez95x30OerQq1pxrRWnU/ZfVNUs tD0y71LUruDT9Os4XuLm7upViigiRSzu7sQFVVBJJOAASa/PL9rL/gqnZ+Gbi+8LfBpbfVNT gmmtbvxVeRLLZIPL2h7JQ+JmEjEiSQeX+64WZJAw+RPjn8cPjT+2P8R9D8FXjf21LdXSyaN4 X0G2FvaCYxBGl2s7MdoSVjJPIwjVpSCiFhX2B+yz/wAEpNI8NHQvFvxfu/7b1uPyrz/hD4FQ 6fbSDefKupPm+1YzESqbI9yOpM8Zyf1bK8r4cyTA0c3zeusRKpFShShezT1XNez9U1FJ3Tu0 cM6larJ06atbds+F9N/Z7+Of7XOoa78So/DuueJ1u3a8vvEd0qxrdAb1ItlYr5+zyWjEVuG2 bUTao2ivb/hN+wr8QPi9rNhoHiDw1r/h7wvHPbpq2qarGbGdbcNuYxechMkhEZAKowDMu/aD mv2B0rSrLQtLs9N02zt9O06yhS3trO0iWKGCJFCpGiKAFVVAAUAAAACrVfnPEuaVOIcfSxai qMaTvCMEkk1azvbfRdlptfU66NNUYuO9+5+Yuq/8ES7KbVLyTTfi/cWmnPM7W1vd+HVnmiiL HYryLdIHYLgFgiAkEhVzgYXwS/Zh8J/B7xP4q0OSZfFlzFdT6VdajqNgkPnxoxjkjEO+QLGW VuCxLjBbHCr9x/tPfth+A/2XNFca7d/2j4subN7rS/DNoT595hgil3ClYIyxP7x+ojk2LIyF K/FL41fGzWfjH4w13Vr1msNK1DVrrVbfR0kDx2xmkZgpYKpkZQxG4ju2AoYivbqcDcV+JOBj hIYr6thW7zquO6WyjFcrnrZ/FGOnxXSTzWJoYOXNy3l2/rY/VLRPgf8ADiwSHULTwL4Ytbm1 lR4riHSrZJYpAdyMpCBgQVyGHQgc9K+aP21vE+qfCO00++8F+OPEHgvVdTuXlm07Q9TurOHU AqojyssJCGVR5I3sVJQYy2xQL/7Knx017xL8J45fE909zdWt09pbXkykSXMCKm12Y/fYMXQu OuznLbifD/2sfD3iz4v/ABisG8I+F9Z8VyRaKgeLRLCW8kQJPJuLLGrEAebGMkY+YV/PPhdk 2PyXxUjgM+zKTjhXVjKXPzxqcqdoL2l1ySdm0037rtyytKPq42pGpgealD4rfL7jmvhL+2j8 ZfCXjnTrn/haXiSS2uJY7a6GvXz6hbiFpELnZciREbC4EgAYAkbgC1fof8IvFvh/UfDFrcWF 1bXli0ZVJrSRXRiMrwwyDhhg/QivyA8S6Vq/grXLnRfEWkX+gaxa7fP07VLV7a4i3KHXfG4D LlWVhkchgehrPXUYmHUV/X/if4Q5J4pTw9ejmkcK6at7tKMoyvrdpTg77K92rLbW54GCx9TB XThzX8/+Az9e7/8AZk+HH7Ufxe0+38VwXRGl2bXrDTZxA95Gk0QNvMwUsYm8xs7SrjcdrqSc /c+laVZaFpdnpum2dvp2nWUKW9tZ2kSxQwRIoVI0RQAqqoACgAAAAV/OJ4O+KXin4fTvN4V8 U6z4amkVkeTR9RmtGZWKlgTGy5BKJn12L6CvUvBP7c/x18B/bP7M+KOu3P2vZ5n9tSrqu3bu xs+1rL5f3jnZt3YGc7RjhybwWzPKMppZVTzaGIjRvyc/NFJN3slefLu3ZXVy6mYwqVHN07X3 /rQ/fOivxR8Hf8FSfj54a1OW61HX9J8WwPCYlstY0iCOFGLKfMBtRC+4AEYLFcMcqTgj0Pw1 /wAFh/iVa63bS6/4M8J6npC7vPtNNW5s7iT5SF2zPLMq4baTmNsgEcE5FV/CniKlf2Sp1Lfy z38lzKP42XmCx1F73XyP1rqvqOo2ukafc319cw2VlaxNPPc3EgjjijUFmd2OAqgAkk8ACvzf 0v8A4LNWc2p2iaj8JZ7XT2mRbm4tfEKzyxRFhvZI2tkDsFyQpdQSACy5yPSNX/bd8M/tOeC7 vQPCGj63p2n3Uv2bUrjWRHA7RjY5ijEMz7lfO19xAKblKsHO3844ryHN+DMtqZpm+HcKceqc ZJt7L3W9W+510KtPETUKb1Pyu+P2tWXiP9oD4oatptwt3p1/4p1S6trhAQssT3crIwzzgqQe fWusTUfi38XfAvwl+E+nadeahoO67PhnR7BNsd/O91cNPcSsW2l4y8ilnKrFEpbCh3d/vDSv 2LPg/wCI7ue7uPBv2i8upHnkEF/doCxJZiESUBR1OAAAOgAp/j/4HHwF4Q0qb4RazffD7xF4 b82XSbmyvJWjkV5VmltrkOzedDJJHGWV9wyi8MoKNhg/pLcNyhl+X0cNUjUi7SnVhHkh+7lF TjyVJSupuN7x/hudveshyyesnObat2T1evp2/E9n/ZS/4J+eA/gL4FEfijRtG8ceN9QCS6nq moWSXMMLAcQWqyr8kS5OXwHkPzNgBI473jj/AIJ2/CXxlr8uqW8eseGPOy0llod1GlsXLsxc JLHJs+9gKhVAFACjnP5dH/gp7+0mf+ahoP8AuB6d/wDI9eh6V/wWM+N+n6ZaWs+i+CdTnghS KS9utOuVluGVQDI4juUQMxGSEVVyThQMCvo834VxuY15YnFzhWnN3b1v+MY6eSMadeMFyxuk fqF8GP2Vvh38DEjm0DSDeawhJ/trVmFxeAneMo2AsXySFD5SpuUDduIzXrtflN4Y/wCC2GtW mh20XiL4UWGqawu7z7vS9beyt5PmJXbC8EzLhdoOZGyQTwDtHq3gv/gsb4B1LSHm8U+A/Emj X5lPl2+jzW+oRNFtUhmkkaAhslgVCEAAHcckDkwXBecVoyhgsLzKO6i49etr3frb1Lliaa1l I/QOivjfwf8A8FXPgb4m1SW11E+JPCcCQmVb7WNMEkLsGUeWBayTPuIJOSoXCnLA4Bi+Mn/B Qjw/pthbSeCLl7+zu4BLb3q2pSa4JAYMqTAeVFxsLyIWJZtqfJuPzfEeExvClKNXNsNUhzO0 Vyv3na9ovZu2r1surRtRlGu7U2memftwfHjwz8EPgF4nXWdQEWt+IdMvNK0TTogHnurmSEpv CZH7qMurSOSAoIAy7orfjx8CvCHjj4s/Fa38Uafpmt+JZdDv7XUtRutP0+a9dWV90MZWNTt3 eUVXOAFQ4+6FPrX7RPxDuv2uPEei3Gt6zceH7+yiFnZyareebpUCtJmR3jhtw0bMCN0qq5Ii jUrgBk/V/wDZt+Amjfs1/CLR/A2jzfbza7573U3t0hlv7qQ7pJnCj6IoYsyxxxqWbbk/UZRx Dk9Phit/Z11j8QnTm5RXNSg90nqmpLs2nLV35bGFSlUdZc/wrVebPjK5/wCCVq/GHQdW1XxR rE/w98QTXOdJ03T44by3so9y+a1witiQybWKJFKgjBUktkxr8RftjfstWf7JPj3QfCCeLZvF moXumf2pNKdHWxhhieV4owp+0Sl3JhlLZChQEwW3EL+/Nfjp/wAFiBn9qPwz/wBida/+lt9X q+HFavgsXQymjUfsUno7O9tdXa++u+5njEpRdRrU+ZvgJLPY+NptUispLqLTrNriaZIi4tUa WOLzGOPkBaVU3HHMgX+LB+7vBHxbt2s4yJ16DvXmX/BIbw2+u/Hnxs93pTahoLeEbiwvXmt/ NtSZrq22wykgrmRI5sI33gj8EKcfb2rf8E5fhbeatPeadf8Aifw/bybdun6dqEbQRYUA7TNF I/JBY7nPJOMDAH5/44cK/wCsHEkqsZK6hBWfTS/6nVltf2VG3mfOfxM+Ld9N4S1O20DzrrxB PbSQ6bb2kXnTS3TKRCkceDvcuVAXBySBg5r8+vE3wZ+J/gjQrnWvEfw28XaBo9tt8/UdU0O6 t7eLcwRd8joFXLMqjJ5LAdTX7r/Bj9ljwL8Ebia90u3uda1l5fMj1fXDHcXVsuwpshZUURqQ z5KgM28hiQFA9fqPC7F4vw0wtelhFFyrSi5PraKaSva7td26Jt92PGxjjJJy6H8zd99r0p41 vrK5smkQSoLiFoyyEkBhkDIyCM+xqBdUhbqRXuHxHivP2q/2udetPBEUd0virxJPBo7RpdeS LdpmxdOrh5Y0KbriX5QE3SkIijaP1w/Z5/ZJ/wCFQ6jo+r61r41a80qwjtdP06yjeK1sG8ox yfOzlrjCEorME4LMVLFSn9R5/wCIufcM0sBGtRjVq1o81RX5VTWlt1JybvZKy1i7tHiUsJSr OdnZLbzPw/8ABvxI1/4fanLqXhXxFqnhnUZYTbyXej3slpK8RZWKF42UlSyqcZxlQewrsx+1 N8X2/wCat+Ofw8S3v/x2v3H/AOGVvgr/ANEg8Bf+EzZf/Gq4PxP/AME7f2dvFuuXOrX3wysL e6uNu+PS7270+3G1Qo2QW8yRJwoztUZOSckkny14sYPET5sZl8ZPvaLf4r9TT6hJfDM/MIf8 FKP2iT/zUb/yiab/API9d14a/wCCtHxs0LRLaxvbbwp4iuot2/U9T02VLibLEjcIJooxgEKN qLwozk5J+yPG3/BJ34B+KvsX9l2PiDwZ9n3+Z/YervL9p3bceZ9rE+Nu042bfvnO7jHC+Jv+ CNXw1udDuYvDvjrxdpesNt8i71Q2t7bx/MC26FIYWbK7gMSLgkHkDaUuMuCMXFRxGVQj6U4r 73Gzt9/pcPq+JjtP8TyvwX/wWN8ZWP2z/hLfh7oWub9n2X+xbybTfKxu37/M+0b85TGNmMHO 7Ix6Bon7bGvftSwL9n0t/BOg20j28+nWuoNcPeOU+YyyhI8x7XwItuM7ixb5QnNL/wAEVpl/ 5rSP/CV/+7a8i1DwV4n/AGK7ibwz42Nld31pYNqkM2kztLBdxMzkbCyqwO5HQh1U5UnBXDH8 d8WMVwxj+HZUuF8M4YqpOEbpzVotO9k3y6tKOiW979/QwMa8Kt6791LyPubwla2z26ogjGEL fMwUYAyevfjp37VvaD4th8AeJbfU/NMOnysIr9FzteLkbiACSUyWGBnggEbjn8Tbj4meLtT8 SR+JrnxLqja/GGEWox3TxzQK27KRMpHlp87jYmFAYgDBr9J/AXxCvPjDp/gfTN3l6v4lisxN 9igaUQNKitLII852Rgu5y3CoSWABNfy/xp4NZz4Y1sqzShjFWqV5PSMXHkmrPl1b54tPd8t9 U4rd+1h8xp41Tg42SP0fooor9yPNCiiigAooooAKKKKACiiigD8W/wDgrB4OsvC/7W8uo2st xJP4j0Gy1W7WZlKxyqZbQLHhQQvl2kZwSTuZjnBAHtX/AAT9+Lvijwz+zi3hmynuYppdfubq 0vrl1mjtbIpCPKgjbcF3TrcMwIAG9iAWfcp/wWf8L7ZvhR4kg0fqNR0681eO1/695LeCSYD/ AK+mRGP/AD2Kj71cx+zJ4nt7XwLoMQZQUtIlIHqFGa+g8UOJsbg/DTBUcFpOdRxcusVBS+Hs 3pr0V7atNY4KjGWMk5bJH2Pa6lr96JJ5vEerGWVi7bL2RFBJycKrAKPQAADtiuR+OHxY+L/h 34XX9p4C1uyi1yLY8N9f2iT3IjTaTGjPmPcwUjdKj53NkgkOlvRfGkcNu4BjbehQ71DYBxyM 9D718mft5/HTW/DOn6B4e8P6hcaX/aXmz3l3bJJHKUjKbEjmGAMksXCndgJnCvh/4z8LocT5 3xjgsBl2IXPOV37a8qXLBOcueOvMnGLVtG20k03c+hxro08PKU1p5b/I+G/FPjDVfFus3Os+ INXvtc1e52+fqGp3L3FxLtUIu6RyWbCqqjJ4AA6CvqX4B/8ABMb4ufGcxah4lh/4Vh4cbP8A pGuWzNqEmPMX93ZZVxh41B85osrIHTzBxXzd4D+Jet/DjxivirRJ7M+IEcSx32p6dbai0Uok WQTILmORUlDopEqgOOcMMnP1b4Z/4K1/G7QtEtrG9tvCniO6i3b9T1PTZUuJssWG4W80UYwC FG1F4UZyck/7EcRU+KMTQVDJfZQhtpLVadE4qKS26+h+f0XQi71LnnX/AAUY+AXg39mz41+E vCvguzuLTTW8LWl5dTXdy8811c/abmN53LHAZliQlYwqAg7VXOK/Tz/gmoNv7FHw6HvqX/py uq/LP9sT9qv/AIa9Pgi/vfBth4Y8RaFZzWt/qdnP539o7/KZQAUDxxo6zMkbPJt89uc5Le4/ sGft3eAf2W/hDrPhXxVo/iTUNRvdem1SOXRra3kiET29vEFJknjO7dCxxjGCOeoH5ZmnCvEG I4eWHr0HKtGpGVk1Jy0nFu6k+6f9ad0K9JVrp6W/yP13or5c0v8A4KZfs76hplpdT+N7jTJ5 4UlksrrRb5pbdmUExuY4XQspOCUZlyDhiMGvTNL/AGsfgtq+mWl/B8V/BscF1Ck8aXWuW1vK qsoYB4pHV42weUdQynIIBBFfimIyDN8L/HwlSPrCS/Q9JVactpL7zy39vXQ/Gdv4b8O+NPCe nwana+GxdnU4XDPJFDKISJgikFkTyjvIOVDBsbQzL8EfE39obWvij4L07w9f2Vtapb3QvJpb d32yyKrpHhCflAWRwclsk5G3kH9ltL1Sy1zTLTUtNu4NQ068hS4tru1lWWKeJ1DI6OpIZWUg gg4IIIryW8/ZR+CuneIJ/Fl14F0O2mgRpZTMCmnxosW1ma2LfZwAoJJKcEbvvc1+U5twvQxu OWPslUW7d01ZW6eXRndTrOMeXofjb4d/YQ+O/wAV9NfxZ4S8EHVPD2qXFw9rdjWLGHzVWZ0P ySTqw+ZWHIHSovh94B/al+GunTad4Z8N/GLwzp0sxuHstGsNWtIXlKqpkZI1VSxVUGTzhR6C v2Lv/wBo86y80XhbSfMiHEWoallVYhyCRCuGKlQCCWVvm5UYwb2kfG/UrKMHXdJiuE3MWm0w lCq7eAI3J3Hd33jg9OOfscH415PleIpYPETp1HTSSvGThdaa7rzvst7nNLLak05K6v8AefjX 4X/4KDfHvwJpMun6R8TdWu0mmM5fWI4dUlViqrgS3UcjhcKMIGCg5OMk577wj/wVH/aH0jS9 Yt9R1/SNdlv4fLt7zUdHgSbTm2uPMhEAjQtllOJlkXKL8uNwZv7Zn7aPxO+N2t6p4P1qzk8B +FbeSFZ/CMMqyl5o8t5k9xsVpgWYOqjEWFiYKWUSN4P8G/hB4r/aA+Ien+C/Ben/AG7VbrMk k0hK29nACA9xO4B2RruGTgkkqqhnZVP9lYfJcqxOFjnuf0aMIyipKMOVxcWk1JzikpX30bTW zadj551ail7Kk38znfFXi/VvFmsXOs+INXvtd1e52+fqGp3L3FxLtUIu6RyWbCqqjJ4AA6Cu 7/Z0+F+i/Frxjf6X4jk1K3t1sRNaHTmRQZxcQgrMWU4QwmfG3DbtnYNX6Q+Df+CcPwG+BXwQ k1743iDXtT0+E3us68+pXlra2xbaBBbxwyIXUHCJlTLK7cAb1jX83vjTrvgXRfiX4qg+Dc2t 2HgK8L26/wBqXAd7lN7FvKyiyRwYIRUkZ5Ci5kbLlF8jGZ3i+OMBi8q4e5qHu8satuWnBXSc rp3clG7hBWu7XaV2tI0o4aUZ1tfLqz7f8PfsfX8GjRQ2fjxbS2iQKkMekABB6DEwr66/ZD8I aF4C0LxFoem2rPqMV1HPdarOA095G4byhI+edhWQBVVVAYEAszsfza/Yz+LWr+CfCGtWOs3s iaBvil0qGeRcRlvMM2wZ3KpPltg4XJJHLMT+iX7JPhLUNWn1D4iavpn2RNQtFtNEmlkdZpLV 2DzSGP7ojkaO3KMfmIjJGFYF/wDOvC5NnGQccYjLJ4qOKoUnJOrGKjGScb30TtJNqMld2kpR u1q/rZVKdXDKfLyt9D6Tr8n/APgsr4EWz+Kfw68XtdrN/a2jXGk/YjD/AKr7JP5vmb887/t2 Nu0Y8rOTuwv6wV+Yn/BaycW5+DbnnA1nA9f+PCv6l4Fqwo8QYeVX4PevftySf6Hi4pN0nY9+ +FH7EnwM+Ln7PXwi1HxL8N9Il1H/AIRbTriW703zNOluZZbSBpJJ3tnjMzFhnMhYgliMbmy3 xl/wSo/Z88T6XFa6ZoWseEJ0mErX2i6zPJM6hWHlkXRnTaSQchQ2VGGAyDvf8Ey3Mn7EPw4Y 9SdTPH/YTuq+oa8fG5ljMLjq0cPXkoqcratL4n0vb5GkYRlFXR+eXjL/AIIyeAb3S4o/CXxC 8T6JqImDSXGtQ2+owtFtbKiONLchtxU7t5AAI2nII878Tf8ABF3xBZ6Hcy+Hfizp+q6wu3yL TVNEeyt5PmAbdMk8zJhdxGI2yQBwDuH6o18R6v8AGbTfiX4zutY1HxAsPhu9v47LQrK8vPLt 5MblhaKN1TM0oLyYKmQeYUyVRceBnfiZnPDGFVeFWdWTdowVm31etm7Jb2ua08FTrSs0kfJG qf8ABIf46abpd5dQaz4J1SeCF5Y7G01K5Wa4ZVJEaGS2RAzEYBdlXJGWAya8u1PWvG37Jtlc eCdb0uDSPHYQSvCL21vRZJJlkd/JkkUSFSGWN8HBVipUrv8Arb9qT9rkfs7E6D4A1MJ49uY0 eZrcrJBp8bISrzoQUklKuSkbA7c72AG0P+aGr6vd6rqN3qOoXc+oajeTPcXN3dSNLNPK7Fnd 3YkszMSSSSSSSa/ZOAqGY+LmQ0c14yw7hglNVKdOf/LxxTUZdG6b5no4rn6XjrLzsU4YCq4Y d3lazfb/AIJ9afsz/th+NLz4jWXh/wAV3v8Aben6oDDFMloqS2kgVmDAQxjcjYw24YUYbcoV t31T42+JFvDpUzPMoUKSSTX576HaaN8DNQ0DV7vxLoGv6xq+jQ6pENJuTdDS1m3A282E/d3S hSHTqobGSCSf1I/ZY/Zigku9N+IWveMdF8ZR29y0ujr4WukvtLl2B42keZo/3jpLnaE2+W8I O5icL/MvirwJl+a8W/Wciy36nhklCTVP2dOcot3lCNktrJ8tlJrmtduT9nA4mcKFqs+aXrdn 0x4X8HR23wy0nwrr9rZapDHo8Ol6haugmtbhRCI5UKuuHjYbhhl5B5HauW/4ZW+Cv/RIPAX/ AITNl/8AGq9Ror7KjKWHgqdKTSWm/YweurPl3/h2P+zT/wBE2/8AK7qf/wAk1wniT/gkJ8Dd b1y6v9OvvF/hm1m27dL0rVImt4cKFO03EMspyQWO525Y4wMAfbtVtR1Oz0ezku7+7gsrSPG+ e5kWNFyQBliQBkkD6kV6cM5x+GftY4iSt15np970M3Tg9LH50eMP+CMHh671WKTwl8VNZ0XT hCFkt9b0yLUpWl3MSwkjkt1C7do27CQQTuOQB8xfGb4Lax+z948uvBWsXR1J7CGL7LqYgeJL 63KDy5VVunQqwBYK6OoZtua/bHS9Z0/XLdp9OvrbUIFbY0trMsihsA4JUkZwQce4r4Z/4LFN /Z37PHhDVrZUh1O38WQQRXaqPMSJ7S6Z4w3XYzRRFl6ExrkHaK5cyrZhxfSo4KriXJJ3jd3j drXbv31KgoYduSifDfgDwPqnxK8a6N4X0WLztT1W5S2hyrskeT80j7FYhEXLswB2qrHtX7rV 8D/8EfLW21v4FeKPE17Z2s/iE+Jrmw/tQ26C4FsLSyfyQ4GRHv8Am2DjcScZ5r74rxMLk88l qVKFWSlO6vbbTtf17L0NZVFUSaPOPjj8XofhJ4at5oYYr3W9RlNtp9pJIANwUlpXXIYxpxnb 1LouV3bh8I/tEfs0X37XXjTTPF+reMG0bVbay/s8xJpqTQiASySxqih0K7WmkGWZyQV5BBLe i/ts+J5dP/aJ8P2M11KbOPw7DPDbtITGkj3Nwruq5wGYRxgkckIuegx802X/AAUN0zQfEH2W 18LXGo6JHOqf2kLsRyvHkbpFgaPnuVVnXIxnbkgfIKn4iZpn1R8Bwk54aN3b2dkpJrX2vuSb 15Yu70birps3vhIUl9a2fr+h9Lfsj/BSb9jaDxLcWest4tk1ww/aoZLcWceyFX8oLgyMGDSy ZbJBDAbQRur7j0fWLLxBpkGoadcpd2c67o5YzwecEeoIIIIPIIIOCK+PB8TbDxPodtrFncJN Z6hAl3DKsflh45FDKQpA25BBxgY9BX53+Jv2t/i14C+MPiC48OfETXNPttO1S8hs9OF0ZbCO Pe8YH2R90B+U5yUJ3fP975q9HwiXFvidneZ085xadSEVJupHkfMmoKKjCKUVZe8re60rK7kR j/YYKnB046eR+6HiHXrHwroGpa1qk/2XTNNtpby6n2M/lxRoXdtqgscKpOACTjgV+ZXjX9vS 98a6xq51Dw/dXehahAbQ6MdVaK1NsykNFJEI2WTIZgzNneD0VcIvzbrv/BQr49+KNE1DR9V8 ei90vUbeS0u7ZtHsEE0MilHQskAYZUkZUgjPBBrx4/EPUT0itP8Avhv/AIqv2/iPwS4qx8YU cPOnOG75Ksoa9NbQen3d+lvNo5lQhq7/AHH3f8FPin+zt4I+LuifEm90GTwTqGj2MsGIk8q0 heaMq8ypDxMUQyxgMqswn+VHdY1X7z0v9rD4LavplpfwfFfwbHBdQpPGl1rltbyqrKGAeKR1 eNsHlHUMpyCAQRX4MeJPF58QaLcWAtBB523955u7GGDdNo9K4RtEnBOGQj6n/CvQ4a8K+JMP l7p59CtKcXaF6kKjjC17cyc21zN2Tlptta0VsdRcr0rW66Nan9MnhrxRo3jTRLbWfD+r2Gu6 Rc7vI1DTLlLi3l2sUbbIhKthlZTg8FSOorUr+Yb7DfRDapbaOm18D+ddL4K+KPxB+F/21fCP ivxB4X+27DdHRdQmtfP2btm8xsN23c+M9Nxx1NejiPDvEUU23Uj60nb05uZX9ba9kQsYn2+8 /pUor+evwj+2/wDH7wFqUt9YfFPxLPcSxGArrV0dSiClgxKxXQkQNlR84XcBkAgMQfQvDH/B VD9ovQNctr++8W2HiS1i3b9L1TRbRLebKlRuNvHFKMEhhtdeVGcjIPzGJ4RxdGbjCafreL9L Wf5m8cRF7o/dKvk7/gp74b0nUf2Q/FuuXenW91q+jG1On3cgPmW3n3cFvNtIIOGjkIKnKkhC QSqkfEVh/wAFjPjbf31vbReFPAs0s8ixpHFp18zMzHAAAu+Tk9K99+MF34v/AGzvDdhp3iK5 vPAPhx5Y5rjw7o9+Z/ORVJ2Ty7VWVvN8qTlCq+UAozmQ/F51XwfB31bG59OKpSqJWTUpWjaT fJ8TVtLpWTaTaujopqWIvGlvY/KcfJb59BX9BnwD/Zq8OfAWyuJrO4udc8Q3sSR3mtX4XzCo C7o4VAxFEXBfblmJ27nfYuPz70n9gVvAHj7wp4u8J+KJw2h6pY6j9j1KBJHdoblJHKyqAAdi /KpjILDBIDZX9Q/AviRvFvhPTtVkhaCadCssZTaBIjFHKjJ+UspIyc4IzzX0vFniTwr4h4nB RyGr7SVCE27xlFx5nBNWkl2Wquneyd0zHD4OvhFL2qtdo3qKKK+TOgKKKKACiiigAooooAKK KKAPjD/grT4OvfE37J/9p2ktvHB4c1+y1S7WZmDSRMJbQLGACC3mXcZwSBtVjnIAP5q/s0+I fEOp+IbfwnoNjc6vqc6T3FrZWwBeVYonnlVB1LBI5GC8lj8oBOAf2L/bb8G2Xjr9kr4q6dqE txDBb6DcaqrWzKrGWzH2uJSSCNpkgQMMZKlgCDgj8Tf2YfFP/CGftEfDHWn1f+wbW18R6ebv UGufsyRWrTotx5kmQFjMTSK+TtKMwbgmv2PIskwfFvCGPyfGxvyNzh3jJR91r8U/JtHnVakq GIjUj10PqmP40TaLcXFhqUVxYX9rI0Fxa3UbRywyKSrIykAqwIIIPIIp/hf4Lv8Atz+M7DSY Y2bSfD15Cda1SC+SGbT7afLMFRtxZ5Ft2Cfu3AYDO1STXE/8FZvA2neHP2uZNSt5LiWfxHoN lql2szgrHKpltAI8AEL5dpGcEk7ixzggD0H/AII2eLrvTvjF498KQwWw07VNBTVJ5Sh81ZbW 4SKMKQcBSt7KWBBJKpgjBB/Jsp8IY5RgFxbg8W1KmlKKiuWSu7SvK70s2mre8tNNjvqY/wBp P2Eo7nrfjL/gjH4BvdLij8JfELxPomoiYNJca1Db6jC0W1sqI40tyG3bTu3kAAjacgjzHxj/ AMEYPFmn6XFJ4T+KGka3qJmCyW+taXLp0KxbWywkjkuCW3BRt2AEEncMAH9NfiL8TvCnwk8M zeIPGOv2Hh3SItw+0X0wTzXCM/lxr96WQqjkRoGdtpwCa/LT9r7/AIKs+I/Fd5feFvg+Ljwv oEc00Enil/8Aj91SEx7MwoyA2q7mdg4PncRMDCQyH9BybMuJ8XaeHqy9knZzavFers9fJanJ UhQjutT4dvfBOs2WoPYxvZ3t5HnzYLe5XfHjHLBscHI5Gf1FWL74eeMNM8MHxHP4fvG0JZmt 5L+BRNFDIvl8SFCfLz5sYBbAYnC5IOJvC/w28ZeONNfxhp2h6m2haddrHfeI/skklnbz5VgH lxt35dPlJzmRM/eBP198Ivh74g+O/wALtc+GPh+xu5pdUv1klv442+zWBxG8clxJtIRM27HB +ZwrKgLECtc98RM84UzXB5esXDFU5SgqrjCSnGEmuZpKTV0m2otX92z3TFSwlKvTlPlcXrbX Q+FjqPlth1ZD6MMU9dRjbuK/Q3xr/wAEa/HWnfYv+EQ+I+ga9v3/AGr+3LKfTPKxt2bPKNz5 mcvnOzGBjdk7fJvGn/BLT9oLw1qsVtY+GtG8ZQvCJGv9H1eBIo2LMPLIuzA+4ABuFK4YYYnI H7rhuO8uq/w8wj6Tg4/e7/oeZLCzW8D5PF3G47GvpL9m/wCKHjXxRrUOhat428Q6h4V061jh h0O51i5ezQIVEKiAv5e1AnyrjClVIHAxxvjP9ij43+BdWisdU+Efia4uJYROH0SzbU4QpZlA MtoZI1bKnKEhgMEjDAnA8CXGqfBv4lS6Tr+m6l4e1T93FPpep2rwTxOwVo98bqHXKuCM9Q4P TBHzHiJmVbPeEcww+Aq0qlSUHblleXLdc1lbdwutHu7G2EgqVeDmmlc/VTwRqcMdrEARwBXb 6hqloYFEUjOCg3b1Aw2OQOTke/6V8leBvizBJax/vh09a7W6+K0KWxJnHT1r/G/GZDXVdrl6 n6DGqrGH8Yf2b/C37QHxH8PS+IPFen+B9I04tJq+rXU8UDy2W4DyYnkG3zTIyBC52oJJG2uQ Eb6W8Y/GH4GfsC/BNbTwnDpSR3MY1LSPDGk34mu9We43GO4aRmeQwt5ZBuXLKEjCruKxxnwT 4d6HF8aLXxet1cwRaZNYTaXFLPEsyi4ZVkEgXdndGVjYDAyXGGBU18OT/D5viHq+maVZS21n qt7dQ2cF3dFxEm+QL+82KzFRuJ+VSfQHOD/WHhhxbQaw/DnEdaX1TDNJ2ekVO8le/wBlO6k0 7xje2qseHjaD1rUV7zLv7RX7UXxC/a0+IAW9kvzpt3eRQ6L4L0ySSaCF8skKpEo/fXDeaymX bvYyFVCrtRfvb9jz/gmBo/w9az8X/F2Gw8VeIJ7P934UuLZLjT9MkfcG84ksl1IEKgfKI0Yu V8wiORfc/wBjz9kP4d/s3eG31XwtdTeJte1i3jS88S36qJXQBd8MKADyIjIpcxks+7Ad38tN v0ZX9N8QcdRxuGjlvD8fY4NLTl3mrb37PvduXV6tHjUcLyy56usj8MP+CktzKP20fidbCWT7 O7aazw7zsY/2ZaclemeB+Qr9uvCvifTPG3hfR/EWi3P23R9Xs4dQsrny2j82CVBJG+1gGXKs DhgCM8gGvxn/AOCqngj/AIRT9rzVNT+2/av+Em0ex1byfK2fZtiGz8vO478/Y9+7C/6zGPly f1c/ZW/5Ng+EH/YnaP8A+kUNPiqlQ/1dyitSik3GSdkld2gm33em4UG/bVEz1Gvy7/4Lc/8A NGP+41/7YV+olfn/AP8ABZHwrpd98EfA3iKe236xp3iQWNtc+Yw8uCe1mkmTaDtO5rWA5IJG zggFs/G8MU/bZxh6S05nb701+p0V3am2ev8A/BMpCn7EHw2DAgj+0uD/ANhK6r2r41fEq3+E Pwu8QeLbgZXT4VEeYjIolkkWKIuoZSUDyIWwc7Qcc4rxH/gnRqllov7Dnw+vNQu4LC0jOo77 i5lWONM6ncgZZiAMkgfUisn4nfG6T4p+Jr3QNOJg8L6ddNCxV1b+0JY3I80lSQYgy5RQTnhz ztCfD8f5vh+G6+O5pNyU6kYpWu3zSSfktLt2t67HThKbrKPojh/EP7Tuo6H4Uu/EUFz448V+ I41R7fTNN0q+iS5mAAUFRCIETgFyVxgN8rsdrfk9481nV/GvjLUNT1xWstRFxIkmnrbC1jsi HYmCOEACFEYkBABjnvmv2t0HS4XtwqRbtq5IVc4A6mvJP2jf2fPDHxb8O3IubWG01pIwLXV4 Yl8+EruKqT1aPLNlCcHcSMNhh+PeEfixkvCmbyhxDhZ1qdaSvWc3OdPVaqNkuXrNL3pf3rRi u/H4CpXp/upJNdLbn5Q6lqU13dXF5eXEt1d3EjTTXE7l5JXYkszMeSSSSSeSTX1h8L/+CXPx j+KngHw/4zstS8I6TY65Zx39pa6pqFwLhYJBuidhFbyIN6FXA3EgMAwVtyjkf2Wf2HNZ/atk +JthH4ng8Ka54NMEC2V3Zm4iurmT7SojklSQeUqvb4LqsnDkhTjB7/Vf+COnxv07S7y6t9Z8 FanPBC8sdjaajcrNcMqkiNDJbIgZiMAuyrkjLAZI/wBFOIuN6dWrHDZViY0YU7WfLdNWvG2y tZppq58nRwzS5pxvc+fv2oP2afFn7M3jzTvCviq70jUdSutMTVEm0WeSSIRPLLGFJkjjbcGh c4wRgjnrjR8b/sH/ALQHw++xf2p8K9fuvte/y/7DjTVtuzbnzPsjS+X94Y37d2DjO04yPjj8 Nfin8J/EukeHviymoQ6zb6RCNNtr/VY9Q8jTleRIY42SWRY41ZJQsYI288AHn3TT/wBoL9uf 4beD3SWH4h2uiaXDNcz6hrvhE3TQxAtJI811c2ruVUbjud8KoxwqgDzc3liZ4TC5hGtCdStz czlopWsk48u3ne9+663TUVKUbNJHjzeLfj1+zz4d0nRdT1b4lfDfSpfO/s/T7u51DSrdsPvl 8mNii/elDNtHWTJ+9XY+GP8Agod8fPC2iW2lWPxMvp7W33bJNStLW/uDuYsd09xE8j8scbmO BgDAAAyvEvxqufE3xDl1PWvEd3qfiy6uVkl1NsiT7QCoTDIAqEcBQgCoE2gKFAr7u/Y48W+G /wBo/wAX3fhf4geA/Dvia4sNKfUEutW06G8TzRLDE8kccilYWdWi37R8/lJ90Iq1+Z0PFV0a uGwGY5DTlSne05JXe9pcsoa83VqV1e9mmdjwN05Qqu/9eZ82eDf+CsPxw8NaZLa6jN4b8Wzv MZVvdZ0sxyopVR5YFrJCm0EE5KlsscsRgD6e0z4+v49sdL8V/EvWtF0aRoo4I4zOLWwgkZNz JF5rk5YqWJLFjt64UAez/HL9k79mHT/B9x4p8e+AvDXhrw/4fhknnvtMSTSVVWKjDizaMzMW CqiEOxZtqDL4P4nfGH4iD4jePdVbQkvLbwmt9cJoGkz5MlrZtKTDGw3PmTZsDHcxJXG4gCvH 4zybLfEunQwuCo/UaEHOVaUEry0XJGKuo6O7d7JJ3s2knph6k8E3KT5n0/U+y/i5+0f4hj+L x1PwTrk+i2eiO1rY3OnsF+0AOjStIQWWaJ5IlIVsoyomVyWz6t/wVe+KWmeMf2SvhG8o/s/W PFGpWviG20z5pdsC2EnnfvdoU7GvIF52lt+QMBsfKf7PvwI8afFaXSvDfh/TbjULlDHHd30i t9lsA+5gZ5RuCKqq4HdtmEDHC17v/wAFiPC9r4I8I/s+eHbGSaWy0ix1PT4JLhg0jRxR6fGp cgAFiFGSABnsK/PPD3LIZbj44GhLmo021GWylyqXvL/Fu/U68XNzhzPdntP/AARo/wCTYPE/ /Y43X/pFY19518h/8E2rnQvA/wCwf4O1y6W00m3lfUbvULtIgrTyC/niV32jdJIUjijXqxCI ozhRXrXjn9qzwJ8PPCXiHxLrEmoxaPpECzLOlmT9uZhhY4QSCHLlYx5vljcw5xlh7+dZjhYZ vLDVKkY1Kk+WMW0nJ3sklu7tWXnpuZUoSdPmS0SPjj/gsP4+8Ox2ngjwlDd348bIs160MKbb aPTZjscu/BMjy2yqqqSNqTbwN0efzJs7KTULy3s4MCWdwilgcLn+I4BOB1Jx0BrqPix8U9f+ NnxG13x14okt5Nc1iZZZxaQiKGNVRY440XkhUjREG4liFBZmYkn9E/8Agkz+zDBaaPL8b9cT zL29+06b4ftpI4XSKBWEc94rZZ1kZ0lgA+QhFlzvWVdv9W06FHw44UnUVliavXe9Rqy9VFL7 k+rPDbeMr2+yvyOS+Bng7xn8XdMsPDngfT5m0rTbUWZ1zVA8dlD5MSAJJMqEGQgx/IilvnDb QoJHtusf8Eg/g/resX2pXHinx4Li8nkuJAl/ZBdzsWOM2h4ya+5K8M/al+Lt78PNL0HQtKml stT8QyzL9tRR+5t4gnm7G3ApITLEAwBwN5BVgpr+KMvceC6OJzKhUkpy1nJaOWt7fNv7z6Of +0NQaPiXxF/wSJ8L2HiDUYIPj9aaVBHMzRWGpaRDJc28TfNGsri7jDMEK5YIgbqFUHA+L/2n /gW37N/xn1fwBD4ptfFj6bDbyS3kVnJaNG0sSy+XJG24Bgrq2Ud1KuuWDbkT9VfAF/4dvftm l2t/YSX2nJGbqzjlVpYN67ow6LkoWGSNwGQK+Pv+CiHwx8O2FppnjPTrRbbXLm8Swunhwq3C eVIys47uvlhQ3XacHIC7fd8LvGvNOIOLqHD+bwqQhW0hZ63a5o83uptSjs13Ts07rLG5bClQ dWnbTc8xs/8AgnT8fNb8M+F/EHhzw1p/inR/EGj2usQXOn6vbw+Sk6b1hkW5eJhIFKltoZPm GHJzjmvGv7E37QHw+Nl/avwq1+6+17/L/sONNW27Nud/2RpfL+8Mb9u7Bxnacfp58Lf27/2c /hp8MfCPhA/FE6l/wj+j2elfbR4e1KL7R5EKReZs8htu7Znbk4zjJ617mf2n/g2Ovxa8Df8A hSWf/wAdr+gK3F/GeXVWqmHmoXduanOLa+aXlfQ8pYfDzWjX3o/ATxr4C8Z/DP7F/wAJj4Q1 /wAJ/bt/2X+3NMns/tGzbv8AL81V3bd6ZxnG4Z6iubXVY27iv6YtL1Sy1zTLTUtNu4NQ068h S4tru1lWWKeJ1DI6OpIZWUggg4IIIrK8Z+APC/xH0uLTfFnhvSPFGnRTC4js9asYruFJQrKJ AkisAwV2G7GcMR3NXQ8X80pPlrUU++v6W/UHl8Hsz+bdb+Nu4pWlgmGGVWHoQDX9APif9jP4 FeLtDudJvvhL4Rgtbjbvk0vSorC4G1gw2z24SVOVGdrDIyDkEg+c6r/wS+/Zx1DS7y1t/A1z pc88LxR31prl+01uzKQJEEkzoWUnIDqy5AypGQfoaXjHTqR5cThm/ua/Gxk8ua+Fn5M/s1WF nJ8R0uXto2FvbsySFB8jllAwexI3D6Zr9I/AWrwpbxAEdBXmnx9/4J/+Hv2V/AX/AAnHgHWN f1aC3uootWt9cnt5PLhc7I5Y2SOIjEjKhXDk+Yp+UI2eM8C/FWIwRgygEDkE1/BvjliXxbxD PMMPT5afJCMUlbRLV2/xNn0+WR+r0uRvU+zTrNo1pF5bOXKfvA4GN2T932xj8c103wG8STN4 21XR43DWU1mbwoSTtkR0TKjOBkSc8ZO1eeK+U1+K0KW+TOBx617x+xtpmreJNd1jxtNHNb6G bVtOsnkjG28cyq0ro27O2MxBSdpBLkBsxsK/FOBMmxdDPqNammlG9/SzTv6/mejiqkXSaZ9W 0UUV/Xp4IUUUUAFFFFABRRRQAUUUUAFfzSeI/DOp+Ddf1fw7rVt9j1jSbubT7228xZPJnicx yJuQlWwykZUkHHBIr+iT4w/Edfhj4Mk1SOOKfUZ5ks7GCbdskmfJ+YqOioruQSudm3cCwNfn tffsFeDfif4n1rxNrOveJZdZ1y+n1K7NtNbIjTTSNLIVX7OcDcxOOwr3Mg8VOHvDzG1aWdzk lVin7sXLZu17PS93/W+VbA1cXFOn0Mb/AIKyXVl8RPBXwF+J+jaFcQadr2m3Dvqc1mqzJFNF a3FpbXEq7gGCvcsse8jPnFc/Ma+Q/wBmf9onX/2Y/iYfF/h+3gvp5dOutOmsroDyp1kTMe84 LBUnSCUhCjMItm9QxNfYX7f2hXOi/sz6D4dstYWDw14f1Wza00u+uC7bUt5LaOKBn3OxVHzs 3Y2rI3Uc/APgbw9Z+L/Gvh3Q9R1i38O6fqepW1nc6xdhTDYRSSqj3D7mUbUDFzllGFOSOtfs 3hPxFlnGHB9WtCnJ0IynFxlu4p81tG+j3T0e2qPOx9KeHxCV9dDtvHHxP+Kf7UPjWzj1rUte +IXiOTf9h0u0gaYpiJTJ9ntIV2JlIQz+WgzsLNk5NfdX7NP/AASRjiubTX/jde2+oRGFmHg7 SppAqs8abTcXcbKdyM0oMcOVLIjCZl3Iftj4D/ssfDT9nDTVh8FeG4LXUnh8m51y7/f6jdAr GH3ztyqs0SOYk2RBgSqLmvWa+d4i8QsRj6X9n5RBYfDJWSSSbXy0ivTXzNqOEUXz1HdlXStK stC0uz03TbO307TrKFLe2s7SJYoYIkUKkaIoAVVUABQAAAAKtUUV+QN31Z6AUUUUgCiiigD8 3P8Agpn8H/CPwM8FaP8AEjwjpR0fUNQ1q30e50rTykFiyG2uZPNSJU+STMMYO3CkAnbuYtXw b4S+I3ifx/418NeHdNsFmuNW1K3sEtJbn5p3llRFRX+QJktjLHHPOMV+uv8AwUzOP2IviP8A XTP/AE52tfheRuhP0r9S4O4DyDiPBVsTjKH72LlFNNpaq6dr2bV/w+7hxGKq0ZJReh+k/h34 sDwAp0DVNNm8MX1oB5ul3lqbSSEsA/MTAFdwYN053Z714h8L9W8HwfHyyF7q8GlaVYX7X0MY kZiBHIDAhba20FmjyXKjYGO4GvBfjR8bvFnx4+JWo+MfFmqvdarexm3EEDMlva2wJK20MeTt iXcflJJJJZizszHkdA1vVvCWjRajDpEX2K7nlt4tSuLZ9skkaxNLCsgIBKCSFmUHI8xCfvCv ynMfAirkVCs4YrmqVk48sbKzsrtyd07cz6Xfkd0M0VVr3dEfbnxF/wCCh/j/AOAnxw8TWng6 fRtV8NNb26xaXf27TWzyPFHL9qDRyI4k+cplWClNuVYqGG14J/4LUeMbE3v/AAl/w30PW94T 7J/Yl7Np3lEbt/meaLjfnK4xt24Od2Rt/Qb9jvwzpfhv9mP4aPpljDZPqvh+w1a+eJcNc3c9 tFJNM56lmY/QAKowqqBZ1X9kT4Iazpd5p9x8I/BUcF3C8Ej2mg21vMqspUlJY0V42weHRgyn BBBANfU5XicryzLMNlFbAwXsIQpuUdHNxSUpt6O8mnJ2et9TGcZznKopbu5+Lf7W/wC1N/w1 z8UNO8X/APCMf8Ip9h0eLSfsX9ofbN+yaeXzN/lR4z5+Nu0/dznnA/RX9mz/AIKO/Azw78CP BeheJfEV94Y1Tw/pFlo9xBfaVcTec8FtFG0sbW6SqYywYDcVf5TlAMZ+Tf8Agpd+yp4H/Zt8 WeBL7wBY/wBiaPr9ldQy6T509xsntnjLT+bNK7Hetyi7BgL5OeS5x3H7OH/BMrwb+0d+y54c 8bHxfr/h7xdq5uSH2wXOnw+VfSw/8e+xJGzHF/z2GGbPIG0/seP/ALExXCWEq4pTjTUpRhyv VS1+K6ldaO9tez1POh7WNeSja/U+/wDwt+2V8DPGOiWuq6f8WPCUNtc7tkWp6rFYXA2sVO6C 4KSpypI3KMjBGQQT81/8FJvEmh/Hj4J+FdH8EazY+JoIvElrqF5qekXUNza2tv5dxbFjIr4d vMnUbFJIwSdowT474o/4IveKNG0xJfCPxN0fXNSaZVkg1rS5dOiWLaxLLJG9wS27aNuwAgk7 htANvRfA118OvB2t/CHxA9np3iPSkjidrOYGB512TwyhtuTHIdjnKh9rnIVsgfz7xbnOG4Nw OFzjIa/tcR7VJqUHywhr73S8u2lt7o9WhTliJSp1VZW+89f+BngjSPC/hLSdHs0b7HZRGK3j nlaTy1aR5WALE4BeR2x0yx9a8S+EfiZtMt0srqN7W6tmMM0EylHjdThlZTyCCCCDWx4F+L/9 i7tP1HNpfWx2SwyEZUj9CO4I4III4rh/FPh7UNe8dXWo/D/T9R1+8vS97faTp0El1LGSw3zK EBOws4zngMwxwQF/jvD4TG4/HYpY+UqlSu+bnbcnKWrbbd23Lmvd79z6ByjCMeXRI+ptB8de RCfLnaPepRtrEZU9Qfb2rzT9qD4qXfhb4L+J7/S5xFfiBII5QzK0fmyJEzqVIIdVclTnhgDz 0rw3SvjX5EIEjOrAdCKxPjZ4s8T3/wAJbvWZPBetaj4Ru18p9Yl0yY6cg80R72n27FIkwo+Y HfgDkce7wjwlW/1lwE5UPaxjVpycHa0oxmnJO+lmlZ30tuZYiuvYyV7aM+XPDPi7VfBut22s +H9XvtC1e23eRqGm3L29xFuUo22RCGXKsynB5DEdDXrHg79tT44eB9Tlv9N+KfiS5nkhMBTW L06nCFLK2RFdeYgbKj5woYAkA4Yg+CBLR2ysrpnsG6fnT1tsn5brjsCuf61/sxVrwzDTE4Wl XvpvB6f9vW0/qx+epcnwya+89I+MXxq8ZfH7xNb+IPHeuHXNYt7NdPiuRawW+2BXd1TbEiKc NK5yRnnrgDH1Zef8Fdfi9f6FrVn/AGH4Tsb+6s2hsNRsLScPYzll/flJZpEk2p5gVCAN5Rm3 KrI/wasFwGOJY2HYkkf0oQ3Y/wCWX/jw/wAa4sXluT5hTp0MZljcYX5VGLtG9r25NFey9Soz qQbcZ7/11LukxDT9Xi1C4RtRkjfzdrzFC0mchicEnnnHc9+x/ST9iL9rb9nf4NaQ8etnXdF8 YXtmH1LxFqml+dbBtyf6HbfZ2llCAnduaNfMMe5iuI41/NmwtdU1GG5ltdNvLmO1jM07wwO4 iQAks5A+UAAnJ44NVU1VD3r43MeFOCM6xPPVcoVYJR0m7xTV17srpNrW9rtHRCviaSstU/I+ 4v8Agot+23H+0BqEHgf4fa7cyfDW3hinvZktZLU6pebi4DB8O0EQ8vajImZA7EPtiZflmT4L xWP7N118S7rV7GS/k8S2ei2mk2eoRS3EMDwXzyzXUCgvDve2QRbipYJMdhUxseITUUbuKlW8 Ru4r3o8IZIsHSwuXYj2fJvJpSctbvms46vuumm1kZPEVOZymrn6Xf8ETdGvrbSfi7qctncR6 ddS6VBBdtEwikkjF20iK+MFlWWIsAcgSIT94Zp/8Fuf+aMf9xr/2wr4F8FfFXxd8OPtn/CJe Ldc8Lfbdn2r+xdSms/P2btm/y2Xdt3tjOcbjjqa7fwd4u8S/Gv4h6B/wnHizXPFkejs91apr epz3YhYlM7PMc7cssZOOuwA5r834l4N/1feK4oeJjKlRg5ctmpO0LWW6vJ7dNdbLbso4j2vL Q5dW/wBT7b/Z4uNUk/Ze+DXg0xyWraN/aV/qdncwhcTS3sz2uCRu3CGWQkDAHmqDlgQnSfHz 4I+Ivjv4GsvDyeKn8OWUU4nuYLW08yK9AHyLKC4YhWAYANtzyVYhCl34dXcMNrCFwMAV7DZX tqdN8z7Qvn79vkbT93H3t3Trxiv8pM542zj/AFlXEmG5YYiEuaD5YyUWr2tGalF23V09dVrY +4p4an7H2L1T/rofjR8a/g/4m+BmtppXiO2jUzp5lteWzF7e5Axu2MQDlScFSARwcYZSfsX4 N/8ABXzUPAngDTfDmqfC7RrmLSYorDTk0jWJ7KKCziiSOKMrOty7su0/OZORjIyCW+qvEl/o cM0b6/o9n4h0FmUahpN/bJcwXUAYMVaJzscgqrqG4DojfwivXPE/7GfwK8XaHc6TffCXwjBa 3G3fJpelRWFwNrBhtntwkqcqM7WGRkHIJB/ujhXxhp+IeAp1eJcEqlWj7slFyjFt7TSTTi3b WPNa6drJ2XzVfL3hJNUZWT/qx8veEv8Agsp8PbnRprjxX4H8RaPfLMVjg0We31GJ49qkMZJG gIcksNuwgAA7jkgeX/tY/t2fCz9oD4baX4h8G6xrHh/x54evJobPQdc08q13bzLF5kitEJYe HSMgPMh2pN8pJjz9QeJ/+CV/7Omv6Hc2Fj4Sv/Dd1Lt2appetXb3EOGDHaLiSWI5AKncjcMc YOCPzM/bW+BXw3/Z2+MSeBfAWoa9qt1p1nHNrNzrlzHJ5c8oEkcMapbxAYiKOXDOG84L8pjb P3uAyXhzjHHwwGGw0qcJayi5OSsnd6u+j0Vr3v1OWdSth4c8nc8b8Barr2kfEnSNd07WLiDW 1vDdNfGVvNc8tJuY537xuDBshtxByCa9l/aJ+Nmo/GhPDOgW0sEd0tw32q2EiLC1ySI4z5jE CMDdJkMwC7vmJwDXhvhDwvqHxH8f+HvB2k3ENtfeINRttJhkuXZYRJPMkaGQqCdgZlJwCeMg Eis/SLs6c9rchPMMMiSBM43YIOM9q+zxvB+XYvi5Z3hIrnwNKSpRtf33GSTbbvZSd4xVrSV1 JXsc0cROND2ctpPU+kIf2EviNdeG5dcsda8J6tYrBLNE2n6hNL9oZFY+WjCHaWZl2DLBQx+Y qASF1P8A4J5/tH6Ppd5f3PwxuXgtIXnkS01WwuJmVVLEJFHOzyNgcIilmOAASQK4T4aePtYu 7u5uUkfStRsyvl3NhK8TBXVlIBByOAwODyGx9f3l+DaajH8IfA6avDNbasuhWIvIbiLypI5v s6eYrJgbWDZBXAweMCvzHKvE3j/J8fiMtzutCpOm19jlavryu0rPRp30ad7rt2zwWFqQU6aa v5n4Jr+zZ8ZG6/B/x7+Phi9/+NVT0z9p34n6FpNrp+nfFDxlYafZQpb21naeILuOKGJFCpGi LIAqgAAAAAACv6KKK+7fi3jq8eXGYSnU7XW33p/oc31CK+GTR+CHhv8A4KO/tA+E9Ft9KsPi Jfz2lvu2SanbWt9cNuYsd808Mkj8scbmOBgDAAA9V8H/APBXj406Zottp99a+FdevYt2/UdU 02VZ58sSNwt5oo/lBCjbGvCjOTkn9Sf+GVvgr/0SDwF/4TNl/wDGq8vX/gmT+zUjZHw3wR3G u6n/APJNeLS4vyivX58fl8JxvdpU6cW77+9FQd/VtN7mjw9RL3Jv72fMXw4/4KeeMvi7p1/4 M13wN4ek1HVElibVbR2Fpb2rIqsr2c3m+cxJYZMgX51yhCsG+JfiP8UW0T4qeJ7HS9GjtdMs b6WziginYNuibYz7iMYZlZtuPl3AAnHP6D+Pv+CZOj/BTw5J4s+FV94n8S+ILJgbnS9Wu7eU z2mCZPISK3QtMCEIXdyocAMxUH8qNT1mfxJreo6vdKi3WoXMt3KsQIQPI5ZgASTjJPUmvMwf D+R8a8W4ipQwvJgoUYJRvL45SblJXk7NpJXVrJKy1bdyq1cNQScryv8Agfcf7D/hG3+OGsya t4z0i4uvDMWp22lQWSakYluZZFYTb2jxIPL822cAbQxyMkE7f190/T7XSbC2sbG2hsrK1iWG C2t4xHHFGoAVFUYCqAAABwAK/K7/AIJt+C7nxdoOl6Pbxm/0qTVZNa1hpLZXgtolIjWCQM2G 84220Drh2O1hGxr9Wa/HaeChgc7zWhhocuHhWcKe+0EoS1er95Nt3s221oehzOVKDb1au/mF FFFeuQFFFFABRRRQAUUUUAFFFFAHz3+2ro2oz/DfStd02yvL7+xNRFzei3mfZBaGKQSTPEGw +1vL+bazIpcgqpkNeD+EfitbGyjZLgA46hq+9NR0611fT7mxvraG9srqJoJ7a4jEkcsbAqyO pyGUgkEHgg18+eKv2EPhv4h1yXUdOuNc8JpNlpLHQruNLYuXZiypLFJs+9gIhVAFACjnP5Tx dwX/AKw1liaUkpWs7+R3UMR7JWZ+cv8AwUK1a48YWPhC8s4muLWwa7SeSPDeWXELLkdcYifn GBjkjIz8ar80P4V+/wD4I/Y4+G3g7QNe0u5sLrxQdagms7m+12VZLpLeWF4JIYZIljMKskko LR7XO85YgKF/n+tW3wj3Ff2F4GKvl2RrIK9msOmo2vtOc5u+urUpS2S0tufP5nadX2q6/okj 2vwH+2p8cfAeoSX9j8V/E15dSwmB11q+bVIQpZWO2K68xFbKj5woYAsAQGIPr/gr/gqt8d/C /wBs/tLUtC8YfaNnl/23pSR/Ztu7Oz7IYM7twzv3fdGNvOfuD9kD4H/B346fsjeBtW1r4ReE Uur/AEiTS725/su3N3O8DyWklx9pSNJVkkMJl3qwdWfhiRuOn4m/4Ja/s767odzYWHhTUPDd 1Nt2appetXb3EOGDHYLiSWI5AKncjcMcYOCPTq8WcOUak8DmGVRvBuLajFv3Xa7lpLp3dyFQ rNKUKm58x+Dv+Cyniay0yVPFXw10nWtRMxaOfR9Tl0+JYtq4UxyJcEtu3HdvAIIG0YJPsGl/ 8FhPhRLplpJqPhHxna6i0KNc29pb2k8UcpUb1SRrhC6hsgMUUkAEqucDmvGv/BGPwfe/Yv8A hD/iVr+h7N/2r+3LKDU/Nzt2eX5RttmMPnO/ORjbg7vKfGP/AARu+I+n6pFH4T8f+GNb04wh pLjWYrjTpll3NlRHGlwCu0Kd28EkkbRgEyq3h1mDvKlKi32c1+fNFfILYuHW59t6X/wUW/Z3 1fU7Swg+I8Ec91MkEb3Wl31vErMwUF5ZIFSNcnl3YKoySQATVrU/2h9R8bTTweEEGmaYHxFq s8e6edQVIdInXEYOHGHDEqwOEbgflh4m/YX+NnwTu7rxP4q8MWFv4R8PXizXmurrliLeSBJg BJGjyrK2/jZH5YkYsqhNx217J8Ff219C1Dxrp3hm40a606xvWS2tNSlkDs07bQqPEoOxSxKh gzc7SQASV/C/FLhnNJ4L2nh5GpXpU4SnXqXg3FRtaMXaPvWu3GPNNq1klv6eCrwUrYuybdkv 6/4Y++dJ+LXibw40LatJFrdj5u6djCsdwEIxhCm1OD82GXnkbhkEb/j7472mmQ6ZaeFnt9V1 PUYlu45pkc28MG9lLNgqS5ZHTZkFSrFsYCt4rr/jm2ms2YmNMIFwnA4AGfqcZPua8TsfFUvh DxGms3lm9lpGuTzJY3kuFW7eARrNs7kLvRd2ME7gCSrAfyFkfF3Ejy/E4fndSSV4yeso6pPX re/W9nse/Vw9HmT2O4/b1+JfjXWP2bPEdhPpnh2/0G6jVNTjltrhZYlVg8M0TrdJhknSIgEO CSNylQwP5DRnMVfp7+0t4vuvil8Fdc8KaBJ9r1rU0hgs7VMu87iZH8mNQCS74KqAOWYcjOR+ YNud0Q+lf3V9GnNsyzPKMZHNKvNONSyT+JR5U7vTZu6T/utdD5jOKcIVI8i0sfcP/BQPwjp+ kfsx/sw674Z8H2PhjSdR0eW81AaHZtHaJe3VlpzjzJCWZpXWF8NK7SOsJJZipNfJeoeKtKuf gL4V8OLdbtXsfEet39zbeW37uC4tdKjhfcRtO5rWcYByNmSACpM3jD9on4jeNvhbofw01/xP car4L0G4SfTdOuYYma3ZFkSMCbZ5pVUldFRnKqu1QAFUDz+xtEuhIGcoRjH61+uZNhMZHEQw t1OcZVOVN6O/O3du2tm769FqcFSUbOXof0HfsQ+M7Lx5+yP8KNS0+K4hgg0G30tluVVWMtmP skrDBI2mSBypzkqVJAOQPcK/I/8AY+/4KU6N+z58KfCXw21/wPe32j6R9r8/XdM1BHuG82ea 4XbauiKcNKqHMw4Bbk/Kfqfwf/wVe+BvibU5bXUT4k8JwJCZVvtY0sSQuwZR5YFrJM+4gk5K hcKcsDgH8zzTgbiLD16k1g5yjdtctp6Xdvhb+7fyO2GKoyS948P/AOC0xxN8Gfca1/7YV9Pf 8E1Rj9ij4df9xL/05XVfOP7c+mQ/tvp4FufhtdxzWWhLcSR6jqKS20F3HdJCzFVaPzBt8mMD KjO5+BtUv6b+wB4b1L9mjwZN4F8TvDdPrmsNfJdWEbskFxIkUKxknl0ZYYzu2rtZiCGX5h85 j+OuGlwxh8iqY2McVTrtOm0+a/vrXTRXdrvS+nU2hhq3t3VUfda3+4+3K4X4jfA/wN8WZbeb xT4dttRu7faI72N5Le6VV34j86JlkMeZHOwttyc4yAa7qivmKlOFWLhUimn0eqN07bH5Pf8A BVL4ceH/AIHN8Jk8D2TaEb99YlupBcSXEk5VbFUDvMzsVUM21Sdql2IALMT7H/wR68SaXq/w l8fWTzrc+K4NeS5vneJvN+yS26C2Bk24KeZFd7UB+Qljhd43Yf8AwWk8GNd/DH4ceMlvvKOk 6xcaT9j8nPm/a4BL5m/Py7PsONu058zORtw3N/8ABE+4+0f8LlJGCP7FBA/7fq/TqGEyhcIS lCjGOIg1aSik7c/w3teyUr20/M4XKp9Y1en/AAD8wLazWWPLE5PpX6gPEq/8ESdgHy56f9zL X5jWR/dCv0K8FeMr3xP/AMEdPiLpt1FbxweHNfh0u0aFWDPE2o2F2WkySC3mXcgyABtCjGQS f1TP8DRjgcvqwgr+3pXfdar82cVKT5pryZ0//BGnQrDV9N+OOm6hZwahpt9BpFvc2V3EssM8 TLfq8bowIZWUkFSCCCQa+s/j/wDsV/Djxv8ABvxVo3hL4beENE8ST2m+wu9N0G0t7gyxusgi SVQhjMmzy9+4bRIScgYPxT/wRu8ZXtj8YvHfhSOK3OnapoKapNKyt5yy2twkUaqc4Clb2UsC CSVTBGCD+tFfkvHlKWDz/E06DcIyUWuVtbwW1ttb27HfhXzUk3qfz5ab8P8Awgskg1HTNQkh ZMKdO1HyJFbIOd0iSqRjIxt79Riui8S/sh+KfFPh2Xxh8IfDHibxT4LtQtvdyyyW11fx3fmY aNbaHErgJJC+URgA5JOA239pPHP7Onw1+JPiWz8QeJPB2m6nrFrKswu2Ro2nZQgUThCBOoEa KFlDgAEYwSD3+nada6Rp9tY2NtDZWVrEsEFtbxiOOKNQFVEUYCqAAABwAK+JyDO8/wAkxv1m pjZ1YK65Jzm4u/X4rprpZnRVpUqkeVRs/kfgl8GIfEHwQ+IjaV4y0PVvDGpX1tHcQ2mt2Etl K8QZ1DqkoDFSQ4BAx8jehr7q0H4j6Zq+hTWV6sF5ZXULQT21woeOWNlKsjqchlIJBB4IJFeC /wDBX+Rof2pfDLoxR18H2hVlOCCL6+5Br5H0b41+LtPthDDdwOikjfIh3EZ9AQPyA6UvEDwr zHxCrYfibLmva4he9C70dNKKkpNu6slu009rp6GFx0MInRnsv1Pr39oK9+D/AIK8MpeXHw28 N6jAt3bmTTLGGPTJrtBKjPEtxCnmR5QNkrzjPavl74/eOfg5410LwfN8LfhvqPw31eL7Z/b9 rcarNqNvNlo/s3kzSyFmwqyFv3ceDIB84Aav1m+F/wCxd8GPjX8BPhhrfjHwRFq2q3ug2eqz 3Q1G8hd7i5tLdpiWjmU7SyAhCdqZbaF3Nn4j/wCCnX7Kvw6/Zy1r4b3Pw+0m40K21uK/S7sG vZbmHfbtblJFMrO4ZhcEN85XEaYUHcW9rw0yn+yFDJ8RXqTxMpybbk3BO1ray1SSbvy3vpsk Z4yftL1EkkeN/A74QfBb4jfDpl8ZfFrUvh58Qm1v7Pb2w0OfVbSexMMe35IkUrI0zuNxmwFT Gz5g1Xbn4O3XwI+IUDrrP9sWNxaGa3lktvs0xiaTCl4w7hW/dtlQ7AccnPHoH7H37DOp/tCf DPVviTpHiwWOo+H9XltrXw9/Zqyf2hNBBBcIv2hp0WLzGlEeSpC43EnoL/x18Qwa3DoEElr9 k1nT/tFrewzxeXcRFWQCKRSAylWEg2t0JbvmsfFziHE5fmNPJsrrzlh6qnGtGSTSktlF8qdr K+71e9tB4CipwdSaV1ax6L8PviJG9tFiUdB3r1ix+IMYhH70fnXwXe+LZPA1vY3119ptLC9k miguzC7QySxCMyRhgOWUTRkgdA65xkZ6bwB8Yv8AhPvGfh7wnpWpQLqeuahb6XavcJKsYmml WNCxCEhdzDJAPHav5PxPAGPzBLE4bDzlCWqai2t7PVK3Q9yOKhD3ZPU+wBq8vxB8T6P4XspZ Rcatdx2gkghM7QqzYeUoCCVRdznkABSSQATX6IV4F+zL+y2vwOlu9d1nWjr/AIsv7ZbaSWBW itbSI7HkhjUnMmZEB81gCQq4VPm3ehfHqQRfAz4iuwyq+HNRJHqBayV+ocK5B/q5gajkvflq 16J2X4v7zjr1fbSR5ZqX7Sd/44uZ7fwdGNO0sSFYtWuI909woKkOkTriMHDjDhiVYHCNwPkT 48fsKaR4+uvEPivR9SudP8WanLNfzGZw1pc3UkjSyO67Syb2Yj5CFXghDjB6v4Q+N7b+zLfb IuNo6GvW9T8eQS2RLPGMIF+UAcAY7d/evw3/AIiJxlkedfX8txk6Uk/hXwNXvZw+Fr1Tb7np fVMPVp8s43Pyy/Zl8HarD+1p8MtGbTJ5tY07xlYfara2TzXi+z3aNOx2Z+WNY5GZugVGYnAz XkECgRxg16x8WPiNqB+OfjbW7KeKzvJpb/R2eGMMrWrwSWMi4fcMvAzKWHILErtIGPMPIiIA VyMehr/ZXhzB4rGYfD5tWUIzrUKTlGL2m05TV2ldLmsnu7an57WlGLdNX0bP0R/4I7eCND8W a78StV1vR7PVLzRG0uXSpbuIS/ZHka4Z5EByA+beEh8bl2/KRubP6q1+H37GP7Z1l+yFpvip Y/BM/ivUfEEtsZp21pbOGKKBZPLVY/s0h3bppSzF8EbAFXaS32V4a/4LC/Da60S2l8QeCvFe mau27z7TTBbXlunzELtmeWFmyu0nMa4JI5Ayfwzi7gLP62cYjG4PBuVOpJNNODbfKruyd909 0enh8VSVNRlLVH3vRXyp4a/4Kd/s+67oltfX3im/8O3Uu7fpmpaPdPcQ4YqNxt45YzkAMNrt wwzg5A9K8Ofth/BDxToVvq1p8VvCdtaT7tqapqkVhOu1ip3wXBSROQcblGRgjIIJ/L8Vw7nO BTeJwdSCWl3CSX32s/vO6NanL4ZL7z2GiqularZa7pdnqWm3lvqOnXsKXFteWkqywzxOoZJE dSQyspBDAkEEEVar59q2jNTgvj94n1PwT8CPiP4i0W5+xazpHhvUtQsrny1k8qeK1kkjfawK thlBwwIOOQRX85FsNsYr9uP+CmPxXsvDf7K/jrQNM1WZfEN8LWzmi0ycCS1he4gMouMMCkck TGPbyXE2NpTeR+JMfyxV++eFipVKeKrwknyy5Xbo0k7P5STt5+Z5WOunFH9A37FHg6y8C/sm /CvTbCW4mgn0K31RmuWVmEt4PtcqjAA2iSdwoxkKFBJOSfbKx/B2g6R4V8IaHovh+NIdB02x gs9PjjlaVUto41SIB2JLAIq/MSSepJrYr8NxeI+uYipib355OX3u56cY8qS7BRRRXIUFFFFA BRRRQAUUUUAFFFFABRRRQAV/Pf8Ate+GtT8JftVfFmw1a2+yXUviS+v0j8xXzBcytcQPlSR8 0UsbY6jdggEED+hCvxP/AOCq3gr/AIRT9sDUtT+2/av+Em0ex1byvK2fZtqNZ+Xncd+fse/d hf8AWYx8uT+s+GmK9hnTpP7cX96af5XODGxvTufbP/BI7xLqWu/ssXljfXPn2ui+JLywsI/L VfJgaKC4KZABb97cTNlsn58ZwAB9r1+Y/wDwRh8U4f4q+HJ9X6jTtQs9Ikuf+u8dxPHCT/16 q7gf88Qx+7X6cV83xnhvqvEGLp23lzf+BJS/XXzNsNLmpRYV89/tY/ts+BP2StMtI9cFxrni nUYZJbDw9prJ5zKFYLNOzHEMJkUJvwzE7tiPsfb87ftd/wDBUbTvCefDXwVu7DX9WPnxX/iW eBpLSzI3xhbUHCzyBgJBKd8O0LgShzs/Lu20HW/ip4ySys4bzxF4q1u6d97SGW4up3Jd5JHY 8knc7u54G5mIAJr6nKPD7F1MBPOM2lGhRgnK03ytpXbbb+BWV7u112WphUxcVP2dPV+R2Pxw /ab8bftK+JI9a8b6yb1rPzVsdOhiWG1sI5HLlIY1/wCAqXYtIwjQO7bVr0az/Yx+IHgf4O3P xp8d6XH4b8MaLewCTQNYhkj1K6Q3McAdrdoyFiMkgysmGZFchcMjN9P/ALDv7Hng/wCCmv6H 4z+KtnLd+M4ZBNYo80cul6TIwBR5V25M8ZXiXc0atJkKDEsx+1/2yvDGmeLf2UvixZatbfa7 WHw3e6gkfmMmJ7aJrmB8qQfllhjbHQ7cEEEg4T8UcHxBgY5Lw/VjGgn7OcqWjs3Z8q6XV7S+ 1vF9RrBSpS9pVWu6ufm3+z/8Uo/2jPjl4V+HIvbzT7TWHmM+oQRfMiRQSzui78YZlhKhsMFL AkNgqf1au/hL4QvvhvL4Bm0K2bwjLbG0bTQWVdhO7cHB3iTd8/mht+/59275q/B/9jvxNqXh T9qT4T32k3P2W6l8R2Vg8mxXzBcyrbzphgR80Usi56jdkEEAj+g6vjeIOA8q4HxFKhlibjUh duVnJu7vskkrW0XW500cVPEpufRn4a/8E4fGGqa3+2v8Mra71G7uokTUE2yTNtIGm3RGV6E+ 55r5p17wzqfgrxHq/h3Wrb7FrOkXk2n3tt5iyeVPE5jkTcpKthlIypIOOCRXvXwK/wCMfP8A go3omi+Hf9NtdI8ez+FoH1T947Wst1Jp7OxTYDIIpWYEALvAO0j5T5/+002f2m/i/wD9jjrH /pbNX7vwrOlDOZKhTjThOnFpRiorST6K382rd2+55ddN09Xd3PtPxH4X0zXv+CK2jX1/befd aJetqGnyeYy+TO2uzW5fAIDfuriZcNkfPnGQCPzk0OPUr3StUtrSwN1YQeVf308dksj2yKxh R2m2l4oy9yqEBlR3eLcCyx4/Qr4BeH9a+Jv/AASa+NWiRajv/svWLi8t0v53MVva2i2F/NFE MNt3bJ2VQApkkJJG5mr4s+HniTS/D3g74nWV7cC3uta8OQadp6eWzGaZdX024KZAIX91bzNl iB8mM5IBwyfATeOx1S9/Z4i9t9JST/BNsdSXuxXdH2Z+wZ+w58Nf2ov2etZ1bxSNY03XrLxV Nax6to195cxtktLdhAUlWSLbvmZt2zfkAbsZB639of8A4JbeCPhT4KTxf4b8Y689ppdxB/aG ma4kNz9tSW5hiCxyxLCYcB3JJWTOVxtwSd//AIJY/GvwP8OP2aPiQfE3iO00X+wNafWtR+1b l8q0mt7eKJ14/eFpIXQIm5y2xduZEDfJ37W37cfib9prx5b3GlvcaB4H0edpNG0l8bi+Cv2q 4HKvMylgBysasVUkl3k8jEYTijN89zDLslxboqHNZttRi3H3Ukk2tWndL3V73ZPRSoU6UJ1I 3Ptz4U+LfD32n+w7fU7B9WtoRJLp0dwhniTC4ZowdwHzryR/EPUV6J4x1fSbPSLu4nuY4rCC JpZbi52xqiBcszEkgAAHJJ6DNfjP4VudZufGmm3WlXJXXEvEu4764O8RSq4bzpCwbIDYJyDn 0OcH9AdX8dS/Fu2l8D6PDc6tqXiCGTT4rOxI81xIjKxBPyqApZi7fKoBZiACa/hDxO8GqHBG dYHCUcd9YdZJ1VGNpU2mk2ld3Urtwvr7rT7v6bBZi8TTlJxtbbzOr+Fn/BXbwppulXGneNPC viWY2jbLLU7CS3upryLe+DOjtEImVPKHDyljuJbIy3s3g/8A4Kj/AAC8TaZLdalrmreEp0mM S2WsaRNJK6hVPmA2omTaSSMFg2VOVAwT8car/wAEdvi9b3u3TPGPgu9tPKiPm3c93byeYY1M i7Ft5BtVy6q27LKAxCElV8o8Uf8ABOX9ovwr/a8p8AHV7HTfOb7XpWp2k/2qOPJ3ww+aJ33A ZVPLEhyBs3HbX954fJ/DjF0o0qFedKySXvu+itq6ik231vrfsfMOpjIu7Sfy/wAj6p/4Ko/H L4e/F79mHwingzxpofiS6l8S2d/9hsL6N7uKA2V388lvnzIsF0Vg6qVZgpAPFct/wRm1f/hH 9B+POqfYrzUvsVtpVz9i0+Lzbm42JqDeXEmRudsYVcjJIFfCXjj4WfEL4caMmpeKfAfibwvY zTC2ivNa0a4tIWlKswQPIigsVRyFznCk4wDXB6Vqt9ourWepabeXFhqdpOlxbXlrK0U0EqsG SRHUgqysAQwIIIBqM04ey2hgP7OyrFOopa8zSdtU0tHq9Nf6QQrTc+epGx2PxMuIbr4o+Mpr ays9MtpNavXistOhENtboZ3IjijHCRqOFXsABX1T+zpqWtfEH9hn4sfCDQ9BNxqmq67b6laa hNdpHDIUNpJJBgjIcC0jClsKfP5Zdhz8WWgKggnJBIyO9ewfBL9o3xR8ELS+ttDi026t7mcT mLUYXcI+0KSpR0PICggkj5RjHOff4jybiHH8L0MLw44SxlOVOS9o7RlyNXv622vtezvYzo1K UKzlWvyu+3mfZX/BPX4H+NP2bPipqPjbx1pkGmaVeaTNozW8d0s9zHvmtpRPti3IY/3TKRv3 9SFPGf0KtP2ifhTf69Dolt8TfB1xrU1ytlFpsWv2jXEk5fYIljEm4uWIUKBnPGM1+UEP/BSL xTdeGrqz1TwnpF1qjB1truzmkt4IwV+XfEd7SENkk+YuQQOMZrxP4E/B+L40eNprjXHklsIp RPeSF2827kYlipk68nJZs7ufVsj8Ur5HxnGhmvE/iZ7LCU6KhyeytJT0tyxUZze/KlztSbld 2irr0VVw94UcHeTe9/6X4H9BtFfF/wAP/hvoOiaNDY6dpdraWyKSsFvCqKM5JOAMdck/jXJf H/UPib4B8PT+Kfhn441jSNW0rT3hGkO/22yubZcN5aWsyyRpMNgCOiBsEoThvl/m7IfEvK84 zmGV4hfV4TlyxqTbcb/Z51GLcU9E2udRb10vJexVwc6dPnWrXT/I+df+Cwf/ACdB4b/7E61/ 9Lb6vjn4jeCf+FafErxj4Q+2/wBpf8I/rN7pP23yvK+0eRO8XmbNzbd2zO3JxnGT1r670b9t 34ReP5/7X+J/w7vPEXi64Rhc3s2l2WocAtsVZJXjITkfKFVUyQoIAz8hfELxDaeLfiL4u12w ilgsdT1e8vYIp1CyJHJO7qrAEgEBgDgkZ7mv7i8Oc5zjHSpZfjcrqYanh41F7Sbi41JOUbKP K3srt6210vufNYunTjecZpt207H9AH7LfP7Mnwi/7FDSP/SKKvhX/gtQP33wZ+mtf+2FfW/7 JHxq+HutfBP4S+E9P8eeGb7xUnhbTbdtDttYt5L5ZYrGMyxmAOXDIEcsuMrtbOMGvjz/AIKe 31x+0VH8Prv4caTqXjDTdBudUtLm+0i2NxHI8htwrRBMu6breZfM27MqMMQylvzXIsfhcr4r oTx9WNKMqk0nNqKb5Z21dlr089NzsqwlOg1BX0R9Gf8ABLLwbZeGP2QND1K1luJJ/EepX+qX azMpVJVmNoFjwAQvl2kZwSTuLHOCAPevGvwB+HPxF1aHVPEfgzR9T1OO5iuzeyWyrNM8a7UE rrgyoFABjkLIQACpwMeP/wDBPNp/Cn7NHgrwTrdldaT4nsYLy7m0+6hKssUl5JKjEjIU7Z4w UYhwdwKjBr6fr5fOsbhM4zPF4jD1I1abq1LSTUou0mtGrpm9OMqcIpqzsj8r/wDgsp4b0rwz pvwQ0rRtNs9H0u3/ALc8qysIEghj3NYs21EAAyzEnA5JJ718d/sc+Eb7xV+1P8J7LSLMXV1F 4kstQdN6oVgtpVuJ3yxA+WKGRsZyduACSAfpn/gsr4n1O7+Pfgjw7Lc79H0/w0NQtrby1Hlz 3F1PHM+7G47ltYBgkgbOACWz5L/wTT4/bY+HH/cS/wDTbdV+9cO0IYbhGtW5E5KnUa08pNHl 1m3iEvNH7q0UUV/OZ65+VH7aPgPSv2MvF3hufRdWupNA8Vy3slpps0Rf+zRAICY/N3FpFJnw uVyAoDFjlj5rp/xT1jx18Fvih420a9ijtfBNvppmimjfdcS3t2LeNVBAwqgSOx9kUA7iydn/ AMFlvGt5efGfwD4Uljtk03S9AfVIZQCJmlurh4pFYlsFQtlEVAAILPknIA4f4d6n4f8ADv8A wSw+LEl0tva614k8bWmj2twluTLdtCLG7SFpFUnakaXbrvIUEvj5nw31eD8LuHsZgsNnOIg5 VJ1IRcE1y2c7NtfF8PZpHPLG1YylTT0Sf5HzR4BFjrniy8utd0u214zRSTyR3Uk0StK0ikvm GSNs8njOOTx0x6pH4S+FeuRRJrPh+/8ACfk72N74c1GRo3B2Y86O7MxAXDncjD72Cp4I9i/4 JS/A/Sfiv8QviDqHiTStM1vw3p+grpk1nfIWmWe7mDRywnb8hVLWceYrK6l129SRp/8ABU/4 HeC/gcfhjF4I0h9Di1cap9vjW9uJ1n8o2ZjyJZGxt8x+mPvfSvpeKcpzPM+N6eXZVjp4anaE bQnOKjaF3aCag3y7XXbsY0JwhhnOcVJ67+vc+O/DXwI+J3jLR7bWPDvw+8Ya3o9zu8nUNO0G 6ureXaxVtksaFWwyspwTgqR1FcfqdpqOhateaZqEL2OoWUz29zaXkbQzQSoxV43RhlWVgQVP II5r91v+Ccml3ukfsX/DeC/s7ixneK9uFiuYmjZopb64kikAIB2vG6Op6MrKRkEGvpKvrsX4 kYnLsfXw0aPNGE5RTU5JtRbS35o6rskYRwcZxTvv5H8ya3U4bGxXHqrDH61Wv557mMRLFJgH 5sKea/ov1T9m34R65ql5qeo/C3wVqGpXsz3FzeXXh60kmnldizyO7RkszMSSxJJJJNeOap/w TD/Zzv8AS7y0tvBF1pc88LxR31prl+01uzKQJEEkzoWUnI3qy5AypGQe6filQxlCWHxMasYy 3s4y07bRdvvuifqLi7xsfhLaKrXCbyNgOTnv7V7DpP7SfxR0bTLTTdN+J/jLT9Os4Ut7a0tP EF3FFBEihUjRFkAVVUAAAYAAAr9GvE//AARf+GF3odzF4d8b+LtL1htvkXeqNa3tvH8wLboU hhZsruAxIuCQeQNp8z17/gitrel6VNdeHPirpusazGVMFlq+hPaWsvzANvlWaYrhdxH7tskA HAJIWTcc5Tg4OhVpxkpPecW7dP5ZWX47iqYWpJ3T+48h/a81uXxJ8GNP1K7mFxqN/wCJUvLq YIqeZLJDcs7YUADLMTgADmvnH4MWVpqPxe8CWd/bw3ljca9YQz29wgeOWNriMMjKeGUgkEHg g13f7WXhrxB8PPGFh4E8UrbJrnh9plmW0uPOjZZVhdHVsAlGUBgWCnBwVUggYX7NmrN4d+MO iavwIrFLiSRiwBAaB4hgdzukUYHPPsa+A4Fw1bhzw1zDFVHeo44idr2fN70Yrm11bSs+70T6 9eKarYyEVtoft9+ztr8t6PEek7w9nZSQzwgkkoZfM3qMnAXMYYAAcs5Oc17JXif7LPw91Twt 4PuPEGupe2WteIRHLLpd2iobOKMyeUCvLB2Vy7BsFdyqVVlbPtlfhHCuExGByXDYbF/HGOt+ 120vkrLy2PUryUqjcQooor6swCiiigAooooAKKKKACiiigAooooAK/J7/gssnhuT4k/Dq5si r+Khp13aao6NIQtujxSWsZ/5ZhgZ7lsD58SKW+Ux1+oPxD8QXPhPwB4m1uzWJ7zTNMur2Fbh S0ZeOJnUMAQSuVGQCDjuK+MfhlcpJarPcTPc3MzGWaedzJJK7HLOzHJZiSSSeSTzXzWZeIL8 Psbhswhh/bO8m483JdWa+Lll1aez287raGE+txcG7Hyh/wAErfEY8FfHXxRr1xpmoX2nx+GZ rSSSxhDBJZLq2dFZmZVBYQyEAnJ2HA4OLv7cX7dPxC+Kerz+DLHTNW+Gfha2NxFcae1yUu9X jYyRBrh0wphaMkeSjPGSzkvKAhT72urizFhEyyh5GB3ptxs54575HNfnz+0L8RPgr4++MEul eNLbxTDYaC72tzqnhS2tzeXUgEivbA3DqqIkmxvMKyZKyKqqG8w/YeGfitjfETjutjamRudC NNO0X7SVFxXKpNtQjPmk0rcvNFaxvyyZzYzAxwmFUVVs7+l/zPAvgd8AvFn7QuuarYeGjYad puj2b3+seIdbnNtpmlwKrMHuJgrbd2xgAASdrNgIjsvu37P/AMbPhV8CvHQ8PaVaNrdnNMbT /hP5bdbaS6LzKAzRy4eC22qjlS3yleVY5c+eftDftd618RtJ/wCFd+BNLHgb4H6Z5UOl+FLU Ksk6RMzLPdygl5JHdvNZCzJvCsfMkUyt1vwR/ZD0jxV8I/F/xG1zx/4XuNU0PwxP4n07wVpW pQX98Rb5lb+0IlY+UhRUXYNxDXC+ZtMbRP8A0RxxluH4sybEf62KrGDTVOhTcoe817spS0Um n0b9nH7XNo15OGm6FRewt5t/1/wT62/ak+Mc3g34L+IdY0RraHU4YoYoWkXzFQvLHEX2k8sA 5YZyN2MgjivkDw7/AMFHPizY+AtY8Ga9JoPjbwzqWmf2O1hrWnmEQWhieJ443s3t3+dGwWZm YbQVKnJPoH7Enxasvjt+0l4d8JeO9Mku9Lvbe6ktLKBhJBPdRRGZRdBsZh8uKYlQDufywwKF wf0h8TfsafAvxbodzpN78JvCVva3G3fJpelRafcDawYbZ7cJKnKjO1hkZByCQf588Ncmo+GG ArZZxPlMJ16s/aKfuuag0koprZJxcklLVyd0uvrYyo8bJTo1GktPI/AzwB48ufhz408O+KtO W3n1PQdQttUtobpWaJ5YZVkRXClSVLKAQGBxnkda/Ybw1/wVp+CWu63bWN7Z+LPDtrLu36nq WmxPbw4UsNwgmlkOSAo2o3LDOBkj8e/jV4Msvhx8Y/HnhPTZbifTtB16/wBLtpbtlaZ4oLiS JGcqFBYqgJIAGc4A6V9/fDr/AIJKQfE/4ceDPGNh8U59Ft/EGg6dqjafc6Et20Ms1pFJKBKL iMMvmM5UbAQpUEsQWP75mmMyDNo06nEPNFJWhKF766u+krva2lt+55VONWndUvnc+TvFfxC0 Dw3+3Fc/Euzvm8R+EofHi+KUu9Lt5Vea1N8Lsosc6xMJFUlCGCrvU4Yrhju/8FAfFei+N/2w /iDrPh3WLDXtHuf7P8jUdLukubeXbp9sjbZEJVsMrKcHgqR1FcD+0p+z54y/Zp8dHwf4xOny XjWkWoQXWl3BmguoHLKHQsquMOkiEOqnMZIBUqzcr4s+GXiX4ZN4fHiXTf7N/wCEh0e21/TP 38Uv2ixn3eTN+7Ztu7Y3ythhjkCvcy/D5dh82w1fAVJShKm1FyteSdndWS25ey66aGc5TdOS mtbn3b+wv8QYW/YT/aj8K3EEdrHpek3upC/knAEz3umywLDtIGCGsxg7juMwGBj5vkv9l2eG D43eG3uNDm8S2xjvEm0m3SJ2uY2s5lZdsrqjDaSSGYZAPU8H1n9gbV4bTxF4nsJ7vYtwLS4F mZcCQx+cvmbM8lfNxuxx5hHG7n1L9q79rax8I2ep+CPh00UHiG8kP9u67aIqm3YIsflxuOWu NiKjSf8ALNUVVO8fuvxnOOIs4xfGOc8AZLlbryxcEnVdRwhSVSklKpO0W+WPP9mUZOS5I2bV vQp0accPTxVSduV7Wu3Z7I+SfjL8UNZ+JOuz2F1YJ4W8PafOyWXhGwQ29lppVn48kBVM2Xk3 yFQxLsMKuFXz6SURlY0xuPAFd18Gvg14r+PnxA0/wX4L0/7bqt1l5JZCVt7OAEB7idwDsjXI ycEklVUM7Kp/YTwP/wAE1fgf4f8AhXpXhDxF4Wg8X31vML288Q3LSWt9dXJQqxEkLq8cODhY A5QYUtvfMh/f8yzzIfDrDUsrwFFc7tzKCs7dZNttuT196blKTbbb1Z5UKVXGSc5PTzPzN+K3 xb+D2m/swaH8OPhbpviq08UHXrbV9c8Taza29tJqZjtrmMjMVxIyIrTjy4fuqu4lmdmd+6/4 JZ/EXw74C/aL1/V/GnirTtAs5PClxaR3/iDUo7aN5DeWjCNXlYAsQrsFBzhWOODXt37eX/BP n4R/Cj4FeJviP4NtdY8PahosVlHDpUWotcWMzSXsULySCcSS7tkxGFkVfkU7fvbvg79nD4ID 9o340+Gvh4dY/wCEfGsfaf8AiZfZftPk+VbSz/6vem7PlbfvDG7POMH5WhTyPPcox+Nw0HG9 +adRKU1opS1V3a2yXTRI6G6tKpGL+5bH9B/hjxVovjbQ7bWvDusWGv6PdbvI1HS7pLm3l2sU bbIhKthlZTg8FSOoqXXvEOl+FdJn1TWtSs9H0yDb517fzpBDHuYKu53IAyzADJ5JA71+M3in /gkB8dNB0S5v7C78JeI7mLbs0vTNUlS4mywU7WuIIouASx3OvCnGTgHvPAfwh+NXhnXtLtf2 i9V8Rahp1zO91p2k6/4mGq280sIUb9izSqNonIOSM5A5G4H+ceJfqeQ5ZWzKjXVVQ+ylZvWy 6/jZHr0earNQatc9J/4KqfGPwx8SP2evDthoE2p3Fzb+Kba6k+1aLe2iLELS7QtvmhRT80iD Gc89ODXyT/wT0+Aeh/tDftL6fpniGbOkeHbJvEVxYNbpMmoeTcQIttIHyvls0qlwVbcisnBf cv1p+3Dr2n3P7LPimO3C+diy7g5P22E8ccDH16GvjX9gv9pPQP2WviT408ba/b3GoyP4VuLL TtNtgVa+vHu7R0iL4IiXEbszsOFRsBm2o3teGPGGN4k4Hxa9koVfbSguW+yjTlfXZ3lbtpcz xuHjRxMddLf5nnv7QulWWhftEfFPTdNs7fTtOsvFeq21tZ2kSxQwRJeSqkaIoAVVUABQAAAA K9Q/Yy/Yr8Q/tX+MjPJLc6H8P9LnC6xraKN0jYDfZbbcCGnYEEkgrGrBmBJRJPnzXPFGp+Nv EuseItauftus6veTahe3PlrH5s8shkkfaoCrlmJwoAGeABX69/8ABHf/AJNn8T/9jfdf+kVl X9AZ3mGIyrhaFWg7T92N9dO7Xn6/NHlUoKpXs9jxrxL/AMEX/EFlodzL4d+LGn6rrC7fItNU 0R7K3k+YBt8yTzMuF3EYjbJAHAO4eb6/8J/F3/BP2ygPjv8AsvWG1kyTabJoNy8kU8qBVaFj JGjIVyjFim3a42lmBUfsF4q8T6Z4J8L6x4i1q5+xaPpFnNqF7c+W0nlQRIZJH2qCzYVScKCT jgE1+DH7XX7Vt3+1R8X7zXjJqFl4Xs/9G0DRr6RT9kgwodyE+USSsvmPyxGVTe6xoa/L8tw+ M8RrZJnuJvg+aMp3snLld1BNW1ltpqlezvZPtm44P97Sj73Q+hv2av229d8X+OYfDXiPTrO2 a+icWd3pSvGEZI3d1lDyNlWQEAqRgjBBDZX2r4s/FSw0jwvqN3dTqlvBA8kjcnChSTwOTwO1 fmL8OfHln4H8Uf2xJbXNzd2ylbYwdI2ZSrMeRk7SQOo5PGQCPa/g1oHi79un41aP4Cgd9P8A C8DDUdcdblYZU0+OVFlkBKtmT50VECsPMdS3ygsv4t4h+EGV4rjBVsgw31XL4Rj7SX2XNX5n TTb1ceWNlZc6be936GEx844e1V803t/wTpP2Mf8AgnJrX7UHw71Lxre+Kz4J0k3RstML6S90 96Ux5so3SRL5QJ8sMrNl0kB2+Xhvmv4leCj8NviX4x8Im9/tI6BrN7pRvfK8r7R5E7xeZs3N t3bM7dxxnGT1r+jbwr4Y0zwT4X0fw7ott9i0fSLOHT7K28xpPKgiQRxpuYlmwqgZYknHJJr+ fD9pzj9pf4v/APY4ax/6WzV/TvAWd4vM8xrUqk37KMW4x6K7t+PXzPHxVKMIJrc9a8b/APBM v45/CHUU1i40nSPEegaXANUv9X0bVY/JtooyzygpceVKzKibsJGwIYAEnIHT/s4ftleGfg9q l34Y1zS7qXTWvTPJqkJ3rHIfLjZXiGG8tQrEurFuyoetffn/AAUR/aZT9nz4HXmm6Xdz2vjj xbBPp+iSQJIDbqNi3Nz5qMhiaOOUbGDFvMeMhWVXK/l3+wd+yJqH7VPxB1lTqi6Fofhu3hur u8ls0vFkneT9zbNC0qEq4jmYsMgCIqcF1NfkWY8N4LizA/2lxRScsOoyjFRbi3JfaTva6k0k mnFu907WO6FaVCXJQep+mOgeLLnUfij4Rt9EZX1B9QjyAUz9n5Nx97j/AFPm+/8Ad+bFfXVe N/An9myw+DN5caxc67e+JPElzbG0lvJVEFvHEZN5EUALbSdsW4u7nMfylAzKfZK/F+C+HanD eXPDVZXlKXM10WiX36a/LseliKqrTuj8Sv8Agq7rtxq/7YeoWs8/nRaXo1jaQJtUeUhVpiuQ Mn5pnbJyfmx0AA8D+A/xY174FfFHSfH/AIbsbS/1PQ1nkEeoQyS2yrLC9uWkEbowH7/AO4fM V69D1v7an7Qi/tK/tE6/4ospvO8O2gGk6H8u3/QoWfZJzGj/AL12km2uCyedsyQgrd/Ysu9I 0zX/AIl3+s+HdL8TRW3g+QW9prFpDcwxXEupafBHP5c0bozRmbeAV527cjOa/tnL6i4e4RnW xsFUjTi5Ti3vFu8o3X91uPqfNzXta9ou1z9C/gn+314++KWjaZc3HwjsLaN44ftGpP4ieCO4 JGJJIIPssjKuQWVHfoyje3LV9F6F8d7K5iB1vSrjRyWb95C32qJUC5BYhVfJORgIe3PJx8o/ Ca4tbbTbdECqqqAAO1exTXtobGPbIHZkJdSuNpyePfjB/H2r/MfiPxVzarm062Aw1OhRu7U1 zSVr6XlOTk33acVu1FKyX2dHAwULTbb7n5p/8FQ/jF4S+Nf7Quj6t4O1OTU7LT/DsOmXTTWV xaPDcx3d2zxNHPGj5AkTPGOcdQcZmqNaaD/wTe8M6TLqNvdaprfxFk8QQ2lqkrm2tlsp7MrM +wRpKZIGYR7ixR0boTh3/BQPw9pK/F+wuNNhMGp3WnrLfNtVYpQHZImyBuL4VlYn+FYwOhr1 D9kH9pP4e/DD4T6XoXifVn0rUrKWdXVrKaZZA8ryKymNG4w4HODlTxjBP9pSzjPqPCOV8UZB k1bExnKEnSjzTny2nd80IN25oq0vZ2s1dHzns6TxE6NWol5/8O/1PT/+CLVzEl18YbcyoJ3T R3WIsNzKpvQxA6kAsoJ/2h61w3/BYL4jHxH8ZfBXhS2msLrTdD0aa8861ffKl1cXLxTxSEMQ Nos4sLgMCz5JyAPYPFf7S/wzs/hjd6n4I8W6bZmw0+caVZWd6NMvEEaMiRRxfLJESF2qAvQj AIIz4P4G/b+8O2S2el+Ivh08mjIyyPNbX0dzJHJGd8LrC8SKSsioQd6lcbgcgA+VkXFHHHEO d4jinL+FqsvYzcZ0pVYU5xtBR0VSMZSlo7xjB6+7e5pVo4alSVCdda9bXW/l/mfpz+yndw3v 7MXwkkt5o54x4T0qMvGwYBltI1ZcjuGBBHYgjtXqdfn5+z//AMFJvhHp2r69Ya9c6z4W0q4V Lu2uL7TBLEZh8kin7MZZNzL5ZGV24ibkEgN9E+CP28P2f/iD9t/sv4qaDa/ZNnmf25I+k7t+ 7Hl/a1i8z7pzs3bcjONwzx1Mtz72UcZm2X1MNOpduMk3Z31XMlZ9PvV0ilOlflpzTSPeqKy/ DPinRfGuh22teHtXsNe0e63eRqGmXKXNvNtYo2yRCVbDKynB4II6itSvNlFxbjJWaNAoooqQ Pxf/AOCuXibTPEH7WVpZWFz591onhuz0/UI/LZfJnaW4uQmSAG/dXELZXI+fGcggdD/wSJ+E lt41+M/ifxfqNtZ3th4W06FIYbhnMiXtxLugmVANrBFtp+WPys0bKCQGXwb9vTxlZePP2x/i lqdhFcQwQamulstyqqxls4I7SVhgkbTJA5U5yVKkgHIH3N/wRn8FfYfhp8RvF/23zP7V1e30 n7H5WPK+yQmXzN+75t/27G3Ax5ecndhf6HxyWB4F9m95qC111bTf4XPJj72Kv6n6JUUUV/PB 6wUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBhePfDDeNvA3iLw6l39gbV9OubAXfl+Z5JliaPf tyN23dnGRnHUV+aGn+LL/wCGXirVfCPiEC11nR7hrWdcOqvtPyyJvVSY3XDqxA3KynvX294+ +Od+viXVPDPhiCBJLMiCbWJHWULKUO9YoxkbkJUZcnDK6lDjJ8T+OXh3xT8TPAWt6dqV9pOv X9xbsmm3muaVE0mkuV5e1kgETxszrEzFzIp8sKUKkqfwvi/POG8wxKy3E1nGpFtc3K3FPqm1 r80melh6VaC54rQ88ufjHbJakm4UDHrX50y/CjXNd+K0HgnwXbP4o1PUrxoNMsrR98zJkspl YqqrhMs7HCqFZiVUZr0b4S/s+fHT47fFDWPh9pTpbXejoJNV1C/l8uxsVZd0XmTRIzbpOAiI Cx+YkBUcr+wP7Mf7JXgf9l7wjaWOh2NvqPiZoWTUfFNzbIL29ZyhkUNyYoN0abYVYqNikl33 O37z4dZXPwyp18bhscqksRGNoU9YySTcKkptbLmdoxV5J35kt/Mxc/rrUXG1ur/FWPxT8c/s u/Gb4aXGqx+Ivhj4ntYNLhNxeahbadJd2MMQjEjSG6hDwlVQ5Zg5C4YNgqQPK01CN+4r+mys Dxn4A8L/ABH0uLTfFnhvSPFGnRTC4js9asYruFJQrKJAkisAwV2G7GcMR3NfueD8XMzpWWJp Rl6O34O/5nmSwEHsz+cnwz4u1TwdrdtrPh/Vr7QtYtt3kahply9vcRblKNtkQhlyrMpweQxH Q19E+F/+CkX7QPhn+yIh48/tax07yV+yapptrP8Aao48DZNN5YmfcBhn8wSHJO/cc14r8U9K 8N/DH9p/xhpY0E6j4O8PeMby2/sD7bLF9osYL11+zeflpF3Rps8zJYZzya/TPxL/AMEafhpc 6HcxeHfHXi7S9Ybb5F3qjWt7bx/MC26FIYWbK7gMSLgkHkDaftsx40ySsqbzrBRmpLRuMZWX XzVr9Pkc0MNUV/ZyPyt+IWtXXxI8d+JPFl/5FvqWvalc6pdRWykQpLPK0rqgYkhQzkAEk4xk nrX6afAb/gqh8Nfh58FPA/hTxB4X8VjV9A0e10mdtMhtZ7eT7PGsKyK7zxt86orFSo2liuWA 3H4c/bJ/Zrl/ZE+KGl+Dz4nHiz7bo8WrfbfsH2LZvnni8vZ5smceRnduH3sY4yed+H37OvxU +Kfw71Lxx4Q8Fah4l8OadefYLibSzHPcCfERKJbKxnkwJoySiEAEknCtjTEw4KzzDU51ounD SzTlHyS10/C4ovE0pNLVnsn/AAUq+MfhP9oj47aDrPw71KTxLpyeHrbTGkis54W+0i7unMYS VFdjtlj5AIO7AOQa3v2g/gL8R/jPZfCa48P+HIbyTw34J0/wrdRQ6jEP3lpv/fZlMfEnmnCj ONhyeRXg/wAFNMutG+KWhnXLC70tmR57ZL2BofP4K5XeBuGCTx6e1fpn4A8QwJZxYYdB3r+U PFjxEr8A5rl1DhKUa1OjTbvUXPGTk5rl9zkdo73jJXk7PRNP3cDhFioTdfRt9D5X/Z5/Yh8a 6GviDVvF11ceELma0aws4dNuYpLv5mR2m8xC6IMLsA5bLMfk2qW8Vtf2SfH+u/HSD4V6BZR6 nq9wv2mO+yUtorLdtN3O3JijU8NkE7sKgdmQN+p+o+J7eS2XaqRbUCnaSdx9Tk9T7cVk/B34 7eFPh38TNWsPFHibQPC+m6np5nF1rd/FaeZNDIiqiPI6qflnkJHJ4B4wc/n/AIeeO3F2L4px dbEwpyWMiouMIWUHCPuSi9ZtLW6lJr3m9LK3Vi8soRoRSb93z7/gesfsofst+Hv2VPhv/wAI 9pckOq61dytPq3iD7L5E2ouGbytyl32pGjbVQNtHzNjc7k+1VV0rVbLXdLs9S028t9R069hS 4try0lWWGeJ1DJIjqSGVlIIYEgggirVfo2JxFbFVpV8RJynJ3be7ZyRioqy2Pl//AIKZnH7E XxH+umf+nO1r8zP+CanP7a3w3/7iX/ptuq/W/wDbK8MaZ4u/ZS+LFjq1t9rtYfDd7qCR+YyY ntomuYHypB+WWGNsdDtwQQSD+LH7Fnju88BftZ/Ci90+G3nuLjXrbS3FyGZVivG+ySkBSDuE c7lTnAYKSGGQf2Tg+vBcN5nQk7NqSXrKFkvvR5+IX76D/rc/oLrgfjB8E/Dfxs0S1sNeS4tr mzl86y1TT3WO7tWJG8I7Kw2uAAyspU4U43KrL31FfhtWlCvB06ivF7pnpptao/BbxB441j4o eCbOw1y5b7PcW6vNHayuqOx2upwePlKqQCDg55Ir1L9lr9j/AMPeIdE1PxP4ghkutIlWaxt7 S6BzdZUBnzgDYh+6yfN5ik7l2YbwX4Xana+JLbT9Onu47KWJVjldxwsY4DgZ54wO3PoCK+8/ DPxHXWk0bwj4UtXv76VEstP062be5CpgDLHhVVSSzHAClmIAJr8f4zqZ9wxWrcP5Sp0Oao3y wukle8XHr7ytytPZJ9jvw6pVkqs9dD8yfH2h6T4a8e67pmhaoNa0i2umS2vhj96vXqOGwSV3 DhsbhwRX61f8Ed/+TZ/E/wD2N91/6RWVflf8bvhBrfwE+LOu+BPEdzYXmtaSYPtE+lyPJbt5 sEcy7GdEY/LIoOVHIPUcnjYGZmeMdDg59K/0eqZFDiLI6WXQxUmm01UcU5Tsm1KSTgk57u1k m9kj5BVfY1XNx+R9+f8ABTz9rxfif4mm+EvhS71C38N+H7yWDxC+fJi1O+jdQIdu0OY7d0fk na8h3BSIopG+Yv2aP2WdU+PmqeKdUjuLe08IeDdObVtbup2y7KI5HitkRWDFpfJkG/gIqsxJ YIj+SzyiBABgZ4r3T4Iftn/EX4E+G4/DGh3Oiaj4PY3DXnh3VdFtpLXUDMjI5uXREml4KjmX 7saIcou2u7NODVh8i/sbI1BYiK1qSfK7vd3Sd2+ieke6sk5hiOar7Srt2PHvHlvbWnxC8VwW UUcFnFq12kMUKhUSMTOFVQOAAMAAV9F/smft1ah+x/pd1Zx+CrDxXpWswedMROtldpMk0ix/ 6QInZowpk/duCAz7kKZk8z5j1jVRrniDVtRFrBYi8vJrgWtsZDFDvctsQyM7lRnA3MzYHJJy a+1P2eP2jf2ZPCH7P2meEPiV8Jr/AMW+JzHeQ6hq0ekWdw5SWeUosFzJcJNDtjdceXs2vuZf mJY/MZpkmJxWRYDBPDyrypNcyg9dKcouXmuZrqt77m0KqjVlK9r/AOZ7r4I/4LUeCr/7b/wm Hw41/Qtmz7L/AGHewal5ud2/zPNFtsxhMY35yc7cDd+bXxi8YWfxC+L/AI98VadFPBp+ua/q Gp20V0qrKkU1zJIiuFLAMAwBAJGc4J6199678KP2HviXoF5o/wANdH1a+8RSNFtuNIu9VtpL VN4LOZL5JIQCqlcGN2O7gDBdPmqT/gn98U7nxfdabp9pYyaGZHMGv3V7GkLR7Syl41zKGPCE CMgN3K/NX5/kPFXCfCea4nC5rW+pV40+ZxrPk93fTmesno1FNyau0rWOurQr14JwXMr9NTl/ 2oPjr4h/aw+ON74ht7Ke7NzMuj+G9JtrIC5Wz85/s0JjQuXnYylmwz5kkYL8u1R+z37JP7Oe m/sv/BTSfB9oTNqsuNQ1y7Fw0yXOovGizvGWVcRjy1RBtU7EUsC5Zj+Ymnf8ExPiJ448a+IL DwrrGgLoumCCWC7125mheUSmTCbYoZPnTyjuJwDuQjksq8zZ/se/tVfBC2vvFGi+D/Evh+dI Rbz3HhPWYZb6SJ5E/diOznaaRdwRiFUgbdxwFJH02LrcMcbZbhI5Lm9Olh4wjyRknaV+rbat LpJWbUlrZmEVWw05e0pts/cavjv/AIKJ/H9dB/Zs1fRvBMw8Qal4oR9OubrSB9risdOKE3c0 rrHJGoaP9yAzI375nQ5iOPkD4J/F39oPw9ro8FfE3UvHGm+G9bhnuFt/GFpMs12yNAsiR3Fy nnGMBkDRo+z5zlfnOfszSpdJbQNrBM7QAu0YIwc85+n5n05/k3jviz/iGfEVDB+xhjIx5Ztq bUZLdK9nrprv21Pew1D65RcruPQ/D1IliupFTO0Hj8q+vP8AgnD8PU+K3xF+JvhQrC0+o+Ar 1bRriR4447pb2xe3kZk+basqxscA5C4IIJB8d/an03TtI/aD8WWekWVnp2nQG1SG1sLaO3hQ C0h6IgC5JyScZYkkkkkn3D9i39oE/s3/ALPv7QXiWzl8vxFef2LpOh/LnF9MuobZOY3T90iy zbXG1/J2EguK/sarilxLwd9ZwdKyxkYOMH0VZxsna691S16aHzyj7HEcsn8N/wADwr44a5rl 98QdQ0PXY3tLjw3NLpD2RkDiGeJyk5+VmQkyKRuXgqidcV9J/spfGzVLf4W3NhrN+Lm1026N rYySzbpI4hGh8ojb9xdw2ksThiuFVFz8UkiCD6DpX3J/wSL0S78V/HPWxq2mJrHh/RdBe5gk ubJZoLC+a8t3gdZCpCTELOUOQ2Ecj7px4PilwLhHwFhuG8LSjy0HCTk1rG105R/vzbs1pdSl qa4HFS+tOtJ7/wBfgfL37RnxCuPHnxZ1W9juFvLO2WK1tim35EVQWXI6/vGk65POOgGPNRqE iLlo3AxnIGRXpH7TYx+0z8X/APscNY/9LZq9E/4J1fDaT4vftXeC7bybn7B4dm/4SO9ntpo0 aJLUq0LHf95WuTbIyqC22RiNuCy/f5FiKfCXDGFoxxDhGjRXKrK0nCK7LeT311b6s5aqdetJ 23Z4V4k0nVvBeuXOi+ItIv8AQNZttvn6dqls9tcRblDrujcBlyrKwyOQwPQ1QW7if0r9ov8A gqf8Wv8AhXv7MN34etLs2+r+MbyPSkFvf/Z7hLVf3tzIqAbpYyqLBIvC4uhuOCFb54/4Jj/s b+Dfip8EPHGv/Enwvb69p2u6nDY6al9ZvBNFFafO9xa3assgWSSUxt5RUZtWVi2Sq8uF8Ssy hlKzbG4dezcuRWe70va/ztfs9RywcHU9nF6n5z743H3iM+hIqq+k20mNpZPof8a/a/xl/wAE qf2ffE2lxWumaHrHhCdJhK19ouszyTOoVh5ZF0Z02kkHIUNlRhgMg+PeMf8AgjB4dvNUik8J fFLV9F04QhZLfWtLi1GZpdzZYSRyW4C7So27CQQTuOQALxR4ezJJZjhX843t6NXevkP6jVh8 Ej8vUj2IFAXaowB7V2GmfHn4x6Bplppul/FbxlYabZQpb2tpa+IryKKCJFCpGiLIAqqoACjg AACvrzxL/wAEdPipZa5cxeHvG/hHVdHXb5F3qjXVlcSfKC26FIZlXDbgMSNkAHgnaPFtT/4J 4/tI6Lpd5f3PwyuJILSF55EtNVsLiZlVSxCRRzs8jYHCIpZjgAEkCvoMVxRwbxHCnDF1EuT4 bu1r201XkvTyMY0MRRb5Ubukf8FMP2ibC/sbq68bw6hHDLHLLY3OiWIhuACC0bmOFXCtgglG VsE4YHBr6i+En7a/xn+Pfh7UI9Ri8N+GNMvI2t4b7QbOdL5TnDPG8s8iJjBUEoTkkjaQCfzi 8YfC3x/8OdLi1Lxb4E8TeFtOlmFvHea1o9xZwvKVZhGHkRQWKox25zhSexr7D/Zd1iz07wVo 0UGEUwLIRkn5m+Zjz6sSfxr8C8eszyTJ+FKcuHKVNV6s1DnhGKcYKLcmuVpKTfKr8r0crWdm erlcKtSu/bN2XTzPHvHv7C/xck8Y6pd6TpVn4mtL64lu1vbO8gtwN8rkK8crIVfGCQoZRuAD HBx+gf8AwTd8E618Cvh+fBnie3lsdS1u7uNUe0eWOUW9yMR7FaIMCHghjfJcgFSOC2K2vDfi uCO3O5Y5dybRvJ+U/wB4YI5+uR7VR8VeMf7MhS+tZlhu7V1nhlwG2Op3K2CCDggHkYr+KK3j jxVmOFweS4ynSVCjKLbhGUZzjFOPLK83C1nfSK95RfRp/RLLaEJSqRbu++x9l0UUV/QZ5YUU UUAFFFFABRRRQAUUUUAFFFFABRRRQB+ePw58W3WkXd7Ya9JINetLqWDURcTiaQXKOVl3uCQ7 bw2WBOTzk1oftCfGm88JfCDxHq+jRfaNUtbPZbiBFzEWITziNrBhGGMh3AghDkgcj3n9p39m S2+JWlaz4s8LpPZ/EO206Q2sVq8aQ6tNGoMUNwHwNxC+Usu5dodSxdY1Uflb8I/jzrXxR+MP w88L6naRLpGs+ItO0++iE75lt5bmOORAV2lSVYjcDkdvUfjGX+EeaZhnazHC0I4ihRnGpOMp JJxT5nGet7SSadk+tj0J4+EKfJJ2bVkcj8M/2zfjD8JINSj8MfEHUraHUZFmuEv1i1BS6ggO ouUkCEjAJXBYKu7O1ce0eCP+Cwvxl8ORaZa67pXhrxba284a7u7qzktb67iMhZlDwyLDG207 FYQkDCllc53fqd4s/Ze+EHjiC8j1v4Y+E76S7tFsZLo6PAlysKxCFFSdVEkZSNVVCjAoFXaR tGPDvGX/AASk/Z68T6ZFa6ZoGr+EJ0mErX2jaxPJLIoVh5ZF0Z02kkE4UNlRhgMg/wBh4/ir JM3hCFXL4UWt3CMddLbpRdl29OyPAhQq03pO55h4E/4LJ+ENTju28YfDjXdAK7Psq6Lew6kZ c7t/meYLfy8YXGN+cnO3HPtngb/gpZ8AvGlvpYn8WXHhnUb+YQDT9d06aJrdjIUUyzRq9uin ht5l2qrZYrhgPnLxz/wRkt3udVufBfxQnt4BCW0/TNe0tZmMojGFmuopEAVpAfmWAlVb7rlf m8M8Yf8ABKP4+eFtLiutOi8M+L53mETWOi6qY5kUqx8wm6jgTaCAMBi2WGFIyR7VPAeHuYwU YV6lGWm762680Wt9XZ+jSMnPFw6Jnj//AAUB1LwzrX7X3xC1HwhdaTf6BezWlzFd6JJFJazy vZwNPIrxEqzNMZS7Akly5POa/dr4V+N/+Fm/C/wf4w+xf2b/AMJBo9nq32LzfN+z+fAkvl79 q7tu/G7aM4zgdK/nn+Lvwq8VfBPxfJ4V8f8Ah6fQNbSGO4FvOySLJE4yskcsbMkikgqWRiAy spwysBpfD74/fFD4fnQ9O8GfEjxLodnY3aPZaXDq032CJ2l34NsSYmQuxZlZSrbm3A5OenPu EqGKwMKuX4yFSnSje7erilq7K66X0uKliHGTU4tNn11/wWl8MWtp8X/h94iTVoZr2/0KXT5d JUDzLaO3uGkSdjuztlN1IoyoGbdsFskL7X/wR48feH0+EXirwZ/aCp4kTxBLqX2Fo3XNvJa2 6IwcrsJJgm+QNuxGSRjmvh34iapdfFnX7/W/F0767q19KZp7y5/1hbjhSuNigKqhVwAqhQAA BX3n8JU8Nap8ENFu9L0ax0hL233XsNpYw2iTXSDyZpTHEAvzNGcHA+XbwMYH8u8QeK1HJ+HI 4BYSU6k5xXNzJRSi2+zbbi2ulmk7yWh7VLAupW5+aysa37Qf/BPG/wDF3jmPXvhrqel6LZTq TPpGqSSxw2cgOR9m8uN8Rtlj5ZACHO07WCp4P4il8XfALX30Dxrpk+nSpI8dvfhGNnfKoUmS CUgB1w6Ej7y7gGCtkD9J/g34qv8Axr8N9I1fU3ilvpjNHJJEmwP5czxhiOgJCAnGBknAAwB1 mo6da6vp9zY31tDe2V1E0E9tcRiSOWNgVZHU5DKQSCDwQa8fF8PZdn2FhXguVTSkvSSvt0NI 1Z0pWZ+Wlp8X7nxPdxaXoVrd63qtwG8mx02F7ieXapZtqICxwoJOBwAT2rS+MX/BMj4s/FtP DWuweJ/DdrqH2eQ3mh6s8sa6e7MpUJPDHKJmK4D8KqFAFMgO6v0p8L+DtA8EafJY+HdD03QL KSUzvbaXaR20bSEBS5VAAWIVRnrhR6VsV6fCORUuEMdHM8G060b8raTSuraJ318yMRVeIjyS 2PxL1L/gmx+0l4I8YJJofhm21WfTJoriy8QaFrtrAolAV1khM0kMyMjcbiikMmVyMMcEfHb9 q34BN/wket6z8S/D9tdf8S9bnxna3VxZs7fOERL5HiEhERIKjftV8HBbP7pUV/Q8fEnGYjTM 8JRxC/vQV383dfgeT9Tivgk18z8e9B/bl+KXx1+AfxL8HeLNQ0u9toPDt402sW1q9pqNySsk gVmhkSEJtTyyoiAZDhs5Yt8U/CG2ur/4t+Crey1CbSb2fXLKODULckSW0huECyqQQQykhhgg 5HUV9c/8FLv2k/Dnxu+LEGl+DZrS90DQ7I2F5rdpCFbVJvNLlBMGPnW0Rx5fAXe87ruVkY/F 3hDxC/hLxZouuRxefJpl7BerEW27zHIrhc4OM7cZwa9HF5Jj6GGxWYKmqKxcb0qK/wCXfLTU dbpazm3LVaJ2b6KI1YuUYXvy7vvqf0Mfsx/ErWviV8NWfxOI28UaLeyaRqlxbxqkNzKipIk0 YU9HiliY8J85cBFAAr1quZ+Gvglfh14I0vw8t9LqbWiuZLuZQhlkeRpHIUfdXc7bVySBgEsQ Semr8CwMa8cLSjinepyrm9ba/ierKzk+XY/DT9gfwTcaF+3T4W8H+KNNgN3Y3GtaRqum3Hlz x+YmnXkU0L4LI65DKcEqR6g1+sPxD8S+DP2atKSLwt4T0jStf8QbktrbTNOS1im8rGZJ2jVc rH5owudxL4XALMv5qfs3nH/BX/V/fxh4q/8ARWoV9Yftl+JpbH9ojQbCa6lNpH4ehnit2kJj R3ubhXdVzgMwjjBI5IRc9BX03ivnVaVGGOoxSqqjCKe9neWq+T/4cwwNNJuL2ufMHx3/AGNv iJ8evi3q/jm38U6PezawkDzvq+62lR44khCBYIShUJGmGwp5wQSNza/hP/gnhY6L8L9Xs/FG qRXPi2+cSRX2nAtDYeXvEYj3KrSBtxMgYKD8oABQOfpTwh4sijhiYMuVwRuAI/I9a29e8XxT QyyMyAuSxCgKBn0A4A9q/k2p408fUsFQyqhjPZxoyg4yjFKb5NYqUuquldW961pXTafurLsK 5Obje/3anN/8E7/2LtG+GXgDVvFviyGPW/E/ie3vNFu7K4AksYtOFw0bwiM5WYT+SkjNIPul ECriTf7p4y/Yj+A3jrS4tP1H4VeGrWCKYTq+i2Y0uYsFZcGW18t2XDH5CxUkAkZUEfkNof7c vxg8GeIvEuoeEvGN1oVlrd39pbTZIbe8hgCgqixrNEyoQm1WZFUvsUtkgY9q8L/8Fdvi5pX9 kQaxoPhPXbW28lLyY2s9vd3iLgSNvWby45HAJ3LFsVjkJgba/wBE8RwBxvjeXMsVWhLETjFz UKjXLLlV4q6SsndK0nprc+TWKw0fcinZd0fIPxw8M6b4K+OnxI8PaNbfY9H0nxLqVhZW3mNJ 5UEV1IkabnJZsKoGWJJxySa+oPgZ/wAEzdf+Pf7O2jfEbw5490+z1fVjP9n0LVNOeO3XyryS Bt90juwysTOMQnkheB8w+T/in4jm+I/xQ8X+MYoBp/8AwkGs3mrfYWl8wQefO8vl78Dft343 bRnGcDpX6Z/sI/tyfBz4S/sx+GPBnjTxLP4e1/Rpr2OaCXTLq4SVZbqW4SSN4I3G3bMF+ba2 5G+XG1m+1zuPE2V5Rh1gKFRV4OKlyrnvHld/h5tLpX/M5qXsalR87VvuPMPCv7NHir9jTVtM h8bajoF9ceInma2k0SeaXCwCIMHMsMeOZhgDPfp3+l9A+ItummFBJHtcDJIBIx6HqPwr2DWP HHwP/ar8LWvhKPxv4c8QSazELvT7Oy1SFdUgkERkWWKEnzYpkTcSrJkAOrrtLqfKJv8Agn7q 1vcXCad8VJYLAyN5EV1oYmljjydqu63CB2AwCwVQTztHSv8APjxH4MzbibOamaYm/talnLm9 16Ll2dtNP06H1eExFOjTUI7I1v2cfGTeJ/2gdWtLK3eeysPD8rXl6iFo4ZpLiDyYi4OFZlSV tp5IXI6GvrGuM+FPwk8OfBnwzJonhq3nit55zeXU1zO0st1csiI8zk8BmEakhAqg9FFdnX2f DuTrIstp4FO7je783qznrVPazcjiPjL8K7H4yeAL/wAN3lwbCaQpPZ6ikKSyWdwhykihvxVg CpZHdQy7sj8uP2c/jfP8fPjJovw10m9vdMt9We7W21q9skLCOG3lmVngWY4ZliwVEhClvvNj n9fq/Cn/AIJncfto/DUf9hH/ANNt1X6Bl/BGS8VYXHYvNKblPD0+aNnbW0nZ91deXqck8TUo SjGD3Z5Z+00yx/tG/EeyjjEcWma5daTG25maRLVzbLI5Yn944iDvjC7mbaqLhR53bRh5iT/C K9D/AGmxn9p34v8A/Y46x/6WzVwFsQsbt3z1r+v+DsLSp4DCUYRShCKsuiUY6Jemh4GIk3OT 6jLuTMip+NfpV/wRq1Sz0Wz+M93qF3BY2kf9iB7i5lWONcm9UZZiAMkgD3Ir4j/aD+BN78BL 3wBp+sLcQ6/r3hW31/UbO4DKbSWa6ulSHY0aMjJDFCHRgSJfNAJGMe1/sE2ssH/CS3M1x/oF 1c2yC2DthpYVkO9l6HC3BCnkjc/TPP5h4q8UUsNwdj83guZOUVBfzWqRS+Wjl6HZgaDeIjTf 9aHy3428Z3vxG8aeI/FupxW8Go69qNzqlzFaKywpLPK0rqgYsQoZyACScYyT1r9EP2GfCS/s 5fs1eKfilc2a6P448XayPDuiTX9ukxS3hciURqFLwuZI7wsspCs1nDlDhd/rUn7Onwm8Ra8v irUfB2j3WtruDGSE+VOX3l5JYR+6lfLkl3Utkqc/KMZnx3/aP8G/DH4a6r8P/GI8RCy8Qt9o 0y78PW8Nw9nLDJHKd6zTxjyzIIjsXBbdL8ykgj+cn4yR8S6dDg7hzAVIYirTlrLlbU4RlLlh yvWNk25PleiXJ1PY/s/6m3iK01ZP8+53XhDRtMvtNlnumSe4mzNLLOS8k0jHLMzHJLEkkknn nnNeZ/An/gob8Lvgxe3ngLxFBN4e8JDULiXQdQ02yElpaWpBZhLDEizIJJg7qQkh3XBVtix5 Pzlo/wC1t/avh1dCsbsafrOohLOGe5l+zxwNIQu9p2ZUi25P7xmCqRknAJr03wF/wTs+GPx+ 8IKh+M+mSfFNrVbk2HhrU7LVbXT7cSJlZoI38yVhvKtIsqIHkUDeFzJ+Z8AcB57w5m1etxHQ rUaUk780ZpO1/ed1Z2b0av17s7MViqVamlRabPtnwV+3d8APHxvRpvxT0G0NoIzJ/bkr6Tu3 hivl/a1i8z7pzs3bcjONwz7J4Y8VaL420O21rw7rFhr+j3W7yNR0u6S5t5drFG2yISrYZWU4 PBUjqK/Kvx9/wRd8b28tpJ4R+I+ga60m/wC1/wBt2U+meVjbs8vyjc78/PnOzGBjdk7fJ9Z/ 4Jg/tEeGdWuNMtPCNh4mtISvl6ppes2iW8wZQx2C4kil4JKndGvKnGRgn+msJkHD2YYqVKGZ eyp68spxTuk7K6bhZvf9Op40qtaEbuF35f0z9waK/CfSda/aw+GWlWl/DD8YNA0Tw5Ck6Jd2 uprp1nb26hgHikXyRCipyjrs2ggjbkV0/g//AIKn/Hfw1qM15qPiHSfFlu0LRiy1jSIEijbK nzAbUQvuABGCxXDHKk4I9yp4Y4mrFzy7H0KyX95xf5Nfe0ZrGxWk4tH7Y1+dX7Xv7Pfif4Zf EbV/iJ4V02fVvCWszSX+oQ2McksumT7TJPJKMsfKciSTzOFUllIQBN/mngb/AILT+KbewaDx X8MNI1rUnnJjuNF1OXToUi2rhTHIlwSwO8lt4GCBtGCT23x7/bx1n4w/sjeJNV8P6DH4VW+s JdP1O2uZlvfMS4nNo8cb7E+XypN+7arbyB91CZPx3iDhissJSeY07U6taFGMk0/3lT4Va99r t3srLe9j0KVdcz5Hqk38kecaF8d7aG3XzLgIQOjHFe+fs7+BPEXxw8SaJr93pTD4ewXDyz31 0yBL1osYhjjYMZUaTCudoQqkq7w4xXw3/wAE9bnWtL/aR0XW9Lkhlg8P2l3qV1ZXMzotxE0J tiq7QRvzcIQTwME84Cn9z9L1K31nTbS/s5PNtLuFJ4ZCpXcjKGU4IBGQRwRmvhsz8Ncp4b4g ll8sQq1SnGFRpR5bKTfLdNv+W7Sb0au9TphjKlalzWsnoWqKKK+zOcKKKKACiiigAooooAKK KKACiiigAooooAK/my+KHg1fhj8RPF/hFr7+0h4e1e80j7Z5XlfaDBM8XmbNzbd2zO3ccZ6n Ga/pNr8Ef+CkPgaPwF+2L4/trTS7jS9M1OaDWLczCTZdPcQJJcTxs5O5WuTcD5TtVlZRjbtH 6lwDmry7E4iC154adrp9fvZw4uHPFPzP3Z8K+J9M8beF9H8RaLc/bdH1ezh1CyufLaPzYJUE kb7WAZcqwOGAIzyAa1a8F/YP8b/8LB/Y/wDhXqn2L7B9n0dNJ8rzfM3fYnaz8zO0Y3/Z9+3H y78ZbGT71X5riKXsK06X8ra+52O1O6uFFFVdV1Wy0LS7zUtSvLfTtOsoXuLm8u5VihgiRSzy O7EBVVQSWJAABJrBK+iGflD/AMFgfH+k/Ejxh4H8N+Gml1m+8KHUI9VktE8yKGaf7PthBByz r5Db8DCkhSdwZV4vwZ+1R4T+GH7Olt8LPHvwx8NfEHxRoUWppoN3KqXEemNcXAYiWYZYMWaa XzLSQZRLZQysTInzh47+MZvPE2um2uG1l5buZhrrSyObti5JnxMiyHecsDIAxyCyg5WuBN+L iOWVC8rD55HbJIyQNzH6kc+pr9s4FybE5phFR4jcKOGpyU1C/wC8qP3rJu7UY++1JJc8nZe6 k+bzcVUjCV6OrfXov6sXdLl1q58YpcafK019N80jyZ2beAwf/Z6cduAOcV+gH7Lq+LfHHh9v CPhuyu9Sm+3kGdw/2TT45EDBpZMERISkrAdWIYKGY4Py3+zj+1749/ZiuLj/AIQy50l7C9m8 +/sNR0yKVb1hGUQSTKFuNqbiyIsqqGLHHzuG+sfB3/BZTxNZaXKnin4a6RrWomYtHPo+py6d EsW1cKY5EuCW3bju3gYIG0YJPm+InhJjuLcbGtgaFP6vG3LGEoqVuzbcUktkldJN2eulYTHx oRtJu/mfpZ8OvBVv8O/BGkeHbaTz1sYdsk+GHnSsS8sm1mYrvkZ225IXdgcAV0dfG3g//gq9 8DPE2py2uot4k8JwJCZVvtY0sSQuwZR5YFrJM+4gk5KhcKcsDgH3LwN+1d8HfiPb6XJoPxK8 N3E+qTC3s7C5v0tb2aUyGNUFtMUmDMwwoKAtlSuQwJ+DxPDGbZTTUK+DnCEUkvdfKklor2ts u51xr06jupJnq9FFcx44+Jfhn4b2sE3iHVorB7nd9mtVV5rq52lQ3kwRhpJdu9S2xTtBycDJ r5ypUhSi51Gklu3ol8zZK+iOnr8wf+Cm37at6+qX3wc8B6vbppiQmLxRqdhKxmklLMr6cGwA qqoHm7SxYv5TFdkqP0P7eX/BRy10/wCHtn4c+CutyXGp6550Oo+IIbS6tptMhAXCQGSJB5su XAkVi0axsQAzI6eCf8E2P2K9T+NXirTviJ400i3k+GOkzObe01KFmXXLlAVVETIDQRSYZ2bc jsnlbXBl8v8AUeDqeV4Bf29mq56cLunFWalNbX/Rd7N2S14cQ5z/AHUN+ps/sYfBSP4T6Tp3 xj8ceCZNf1y/Kz+AfD95cfZ0nEeGm1GXdGyoAHh+zs2SzMZAgXy5l+OPEvwA8e+DtQW11vw9 c6WHleKO5ucLDLsYBmRv41GQcrngj1Ffql+3n8UNL+Dnxl0XXtbtrxrW60KC3tTbQ7muZEuZ zIkZYhSUWRGbLDaHTPLqDX+Fnx38HfHPwFqsNmWltZ4nsdQ029/d3MKOCPmCMcB1BwyseCwy GDAfjXF/iRx1gcbiuJP7PdTAOUafO4y5YNLRRkmla7tdrlctLqTPQw+Dwsoxo89p7ns/7IH7 X8f7RMF9omt2MOleM9Pia7kisUf7JdW29V8yPcWKMpdFZGY5yGUkFlT33xf4v0bwF4a1DxB4 g1CHStH0+IzXN3OTtRc4AAGSzEkKqgEsSAASQK/n+vvjR4t+DHj/AEPXPBmqNomt6fHJPDeC GKYZkR4SDHIjKRsZxyD94HgqDXoPif8A4KG/GP4ofCm98FeKdX0zWrO+u0nub6XTYobpkQqy wZiCRiMOiyZCb88Fyvy193wxwlnXEOXxrYZwdSUW4qUrNq9l0t5vW9vO5zVsRToztK9jS+D3 xPtfCX/BRW6+KE2h61feHbrxHrd7bxWFoJLmZLxLpYAFLBSxM8eV3eo5PFfp7+1R8Gn/AGkP hnpGt+Cru2ufEWjvJd6Y7yMqXcTDbPa5LBUdmSPlx8rxBSUDMw/KL4DftH6X8LvHg1nV/Dsl 9ataS26yW8iSTWztjEkasFBOAUPzL8sjcn7pl0/9ub4v+BfEnie48G+OtX03QtSvpbm3sNSW G+jtYjLI6JHHOsqw8SHcI8A4Gc7Rj3ocA8a8T4+rg87wcMNShRhacpKUZy5mmk6bmotLVp+X TV5PFYahFSpyu2/u++x7nqHjDxF8KtYfQvGGkXvh/VYgSYL2MqJFDsnmRt92RCyMA6kq2Dgm uc8bftNafpNi6fafMuCuVhQ5Y9ccdgcEZPFQ+Gf+CuXxq0bQ7awuYvCXiS8j3btS1PTZUuJs sWG9beaKMbQQo2ovCjOTkn5Z8Na1pPin4323ir4pTX2s6Rfau2r+Ihplsgub8tKZpo0RZYVT zWJUsrpsDllB2hT8thPo9KnjPrWO/e0IvalKLcvJPVrv8N7dtzaWbXjyw0fmd18HP2aV+M+k 6dHpWsXlp4i1HUJrey01II7s3UIVdrDDx+WVZZ97PxtUMQqqSfUfGn/BKn9oTwkbL+zNP0Dx n9o3+YdE1ZIvs23bjzPtYgzu3HGzd9w528Z86/YJ8b+HPhj+1l8O/EXifU7bQ9FgnuoJ9Ruy RFC09nPDGXbHyqZJUBdsKoJZiFBI/cXwZ8aPh98R9Tl07wn478NeKNQihNxJaaLq9vdypEGV S5SN2IUF1GcYywHcV+nZvmfEvCuZ1eXFOrSn78Y8vu04tytDmvzStpeUpa6WUVocdOFGvBe7 ZrT1P5z/ABPp2p+CPFGseHdbtTZaxpF5Np97beYsnlTxOY5E3ISrYZSMqSDjgkVSj1ZG6n86 739pGez1j9o74sXdrNFd2lx4t1aaG5gcOkiNeSlWVhwQQQQRwc1+sf8AwT7+GfgP4pfsS/DK HxX4W8O+MZNJk1WKNdZ06C9Nm76jOzKokVvLLL5TEDGRsPpX6LjeNM1yPL8PmFVqcatl53cW /wBDjjhoVZuC0sfjMl9G46iuq8E/FTxd8Oftn/CI+Ldc8Lfbdn2r+xNSms/P2btm/wAtl3bd 74znG446mv2w8T/8E7P2dfFuu3OrX3wxsLe6uNu+PS7y70+3G1Qo2QW8qRJwoztUZOSckkn5 +8Zf8EYfAF5pcUfhL4heJ9E1ETBpLjWorfUYWi2tlRHGluQ24qd28gAEbTkEZ0PFvBYqPssf Quna90mv1/IbwEo6xZ8Y+Gv+Cgf7QPhXRLfSrH4mX81rb7tkmpWlrf3B3MWO6e4ieR+WONzH AwBgAAe6+GP+Cw3xJtNahl8Q+C/Cuq6SA3m2umfabKdztO3bK8syrg4JzGcgEcZyOL/aD/4J deK/gT4euPE9v470rXvCdpFGLu+ubVrGe2mdyil4i7r5O4xAyLIXBk/1e1S1fIPhXwvrvjLX LTR9HtUvdSut3lQeckW7ajO3zOVUYVSeTXoUsfwNxDRxFepgoKFGPPUmoumoxd3zSkuXT3W2 76Wd7EuOJotJS326n6s+D/8AgsT4CvdMlk8VeA/EmjagJisdvo01vqETRbVwxkka3IbcWG3Y QAAdxyQPi39if4Z61H4ytfHCajNo/wBjS4trFrKTbM/mwyW8r7xygCSSBSuHDfMCu0FvIb74 H/E3TLLVb6XwD4hn0zSVZ77U7HT5LqytlSMSOXuIg0QCoQzHd8o64r6x/Zg1y2tfBujpGEjH kIxVRj5iASfxJJ/GvwHxdzXJ+GuFZVOCazTxklGTjPnXs+WT916tc11Z3el+tmvUwEKlavbE r4fzOA+K/wCwb8TL/wAU614g8P3Vv40i1TUZLn/SL0R6g3mlpHkmM21GIclSwcsxIbaMkL6n 4H/4J86J4a8MaQ3judNW1WDWYr3URpEkvlTWCyJ5lmCWjJ3xq58weWytIMEhMt9VeFPFsdqY 5dsU20H5JV3KcjHIo8Q+I4Ws3yw6Gv43reOvH08HhsspYhUlRa9+EeWc0lZRm7uLj3SjG/2r rQ+gWWYVSc2r377L0Pzs/wCClevT69+2h43LajJqNhbW+mRWBM5liigbT7eXbFyQqF5ZJMLw WkZurEns/wBkT4T+Mr/4Ial8QvC1pP4gtbbxFLpd7o9hA0l3GBBbOk8aLkyqTNtZVG5dqthl LFPAP2n9QfVPj74ruJJ5Lg7raNXlcsQqWsSKoJ7KFCgdgABwK/Wf/glf4NsvDH7H2halay3E k/iPUr/VLtZmUrHKsxtAseACF8u0jOCSdxY5wQB/c/EFKhnPhtgYYiNlXjSduzcOb8D5qk3T xkrdLnz34d+PUOpG1srN3u765dIILWBS8ssjEKqKgyWYkgAAZJNXvif/AME5PH37RWkweOf+ EjsfC/iN7SKCy8N6zaSKphEpbfcToWaFysjnyxE5G1QxUswT9INe8Q6X4V0mfVNa1Kz0fTIN vnXt/OkEMe5gq7ncgDLMAMnkkDvXmPgf9rf4RfEXX4tF0PxtZzanNgQwXkE9n5zF1RUjadEV 3LMoCKSx5wDg4/nfhHJ6XA2arNMvxHLXs0tlo91Z3vc9fEVHiYck1ofg34D+H/iH4p/EyDwL 4Jgg8V65dzXEVibSYW8N4sKPI0iNc+UVUxxs4EgRsYBUNxXTeKP2cPi74L/thtb+F3i6ytdI 843t+dGuJLSFIs+ZJ9oVDE0YClvMVihUbgxHNdt/wTHGf24fht/3Ev8A02XVfvNX9eZh4l53 k2IjR92pFxT95a7tbrTp2Pn4YOnVV9j+cfwZ8b/G/gDTJdO8KeOfEfhnT5ZjcSWmjavcWkTy lVUuUjdQWIVRnGcKB2FevaP/AMFK/wBobwhLoscXj0atp2niFfseqaZaz/akjx8k83lCZ9yj DP5gkOSd4Y7q/bvxn4A8L/EfS4tN8WeG9I8UadFMLiOz1qxiu4UlCsokCSKwDBXYbsZwxHc1 4140/wCCf37PXj3VItQ1P4XaRbTxQiBU0aSfS4SoZmBMVrJGjNlj85UsRgE4UAeLmXiFl+eY eVLH5dBTbvzJRbT+aT1Wm5rDCTpO8Jnwn4C/4LOfECHVrh/F3gLwzq+mi3YpDo0txp8qyblw xkke4BXbuG0IDkg7hjB9A/4eyfBX4q+F/sHxZ+Dl/e+Teefb6X9mstdtBhNqzZuDDtk+eVcB DhT947iB33ij/gjn8HtUGsz6J4i8XeH7q7EzWcIu4Lm0smbJjXY0IlkjQlRtaXeyrgyZO6vD /GX/AARU8T2GmQyeFPidpGuagZ1EltrWly6dCsW1ssJI5LglshRt2AEEncMAH5p1uGcTCnGE fZzV7y95XvttdK3e19euhtavFvqjuIvGf/BP741PpGsar4Ug8LazcoLSPR7fS9Q014/3rBPM TTj9nZm3Z37mbayhiNu1YvDv7PXgvxBo+ueH9MstRtvAWo3bTWuj312Xlhh84SpGZVw2FYAg bmIACs8hBZvn/wATf8E9PjN8Ddes9f1nSbDxB4X0pU1K+1jw7fCWO2CuflaKVY5jt2qzMsZU I2Sw2tt9kn/aq8JfB/StN/tZ7q9u7oZSy01EkmWMA/vGDMoVcjAyck5wDtbH5B4wU8ZicXl2 RcCYitiZT/epJtuNSLfK4WtyuKTd94qzcjvy9xjGdXFJLp8jo/D37Kmi/AzXtY8W+DRfG5ud Oey/suW4DwhC0bnYWG7cWiH3nI+Y9BjH6HeCtPj0jwboNjDfR6nFa2FvCl9CAEuFWNVEigEj DAZGCevU18aeHfjz4d+KvgqLxDot0klpOu2SEqsclvIAN0UiDhXGRkdDkEEqQT9V/A6fUrn4 T+G5dUGLiS3LRfc/49y7fZ/u8f6ny/f+9zmvyPgjMc+xmc42lxLzyxcIxhKVS/OvZvl5JX1v 66uzuzvxMKUacXRtyvttqd1RRRX7cecFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfkZ/wWd8 DX0Hxo+H/ip5bc6dqmgyaXDGrN5yS2tw8sjMMY2lb2IKQSSVfIGAT+udfnl/wWb8H2F18Ivh 74ulluF1DStfk0uGJWXyWiurZ5JGYbclg1lEFIIADPkHII+r4VnThnFCNb4JOz6aPz6GFdN0 3Y7X/gkZ4j1HWv2VrywvbjzrTRPEd5YafH5ar5EDRQXBTIALfvbiZstk/PjOAAPtivyz/wCC MHifS7bxT8VNAe6A1fULLTr+2twjHzILd545n3AbRta6gGCQTv4BAbH6JzfG7wTFdy2667Hc tHjMlpBLPE2QCNsiIUbg9icHIPINZ8eVMHk2eYlV6kacJSum2op8yUtLtJ79AwqlUpKyudfq uq2WhaXealqV5b6dp1lC9xc3l3KsUMESKWeR3YgKqqCSxIAAJNfjD+3l+3hf/tM6tP4M8GT3 Gm/CqymBeQhoptelRsrNKpwVgVgGjiODkCRxv2LFnf8ABQX9oP4g/G/4gR6V4h0TUfCPgbTZ mfRtEuSNs7BQDdTOhMcsxV8YVmWEOUUkmR5PCvg38HPFXx6+IGn+C/Beni91W6y8kshK29nA CA9xO4B2RrkZOCSSqqGdlU/svBXBmX4fBw4lzavCdHl5o8slKPrzK8Zf9utq+lzz8TiJyk6N NNMpfCH4DeJvj/8AEDTvBvgnT/ter3WZJZZWK29pACA9xO+DsjXIycEklVUM7Kp/a/8AZb/Y V+HX7LdrbXulwza/4wERW48Raj/rCzIqyCGIfJEhIbb951WR1MjBjnqf2Xv2XvCn7LHw+Xw/ 4fX7dqt3sm1jXp4wtxqU4BwSMnZGuWEcQJCAnlnZ3f2OvzHjDiKjn2Ml9TpKnQTVkla9tpNb LyXzep24ei6Ufed2cb4y+C3w9+I2qxan4s8CeGfE+pRQi3jvNZ0e3u5kiDMwjDyIxChnY7c4 yxPc186+Mf8AglZ+z94l0uK10vQ9Y8ITpMJWvtG1meSaRQrDyyLozptJIOQobKjDAZB+vKK+ TwuZ47Au+GrSh6Sa/U3lCMviR+bXiT/gjFpdxrtzL4e+LF/pmjNt8i01TREvbiP5QG3zJPCr ZbcRiNcAgckbj4J4w/4JSfHrwvpcV1p8XhnxfO8wiax0XVTHNGpVj5hN1HAm0EAYDFssMKRk j9oKK+4wXiLxJgrJYjnXaST/AMn+JzSwdGXQ/n51f4JftH/s7+INZv7Lwp498GT6dZN/aGt+ HVuBbra7Vmcte2pMTRgKrN+8KqU+bBUgfaH7Lug3uq29p4r8ca5qPi3xOIBbWmoa1fy3s0Fv yflaRmKlmeQ43HAbAxlgf02r4G/aX+FOqfsyWfiL4h6RPbTfDpLmOaazjAin0szy7NiRqoRo BI8ars+ZRIqlSEaQ/i/irjM743wUYYeP7yUveUd5XSSSW9lqra6Ox6GBjTw0rvY+Ov2g/Bun eHfit4t0S3EU+ltdGaKNIRCiRyqsqxqgJChA4UYP8IIx0H7G+OvGPhn4D/CrVPEF9FBpPhfw zppdbOzWKBVijQLFbQISiBmISKOPKgsyKMZFfm/+zLofhT9rH4u63451jULPTPCHgS2s7/W/ t8KRpeHMzoJjKNghCW7eaz/wKqjhiyeG/t3/ALXl7+0v8SZ7DRdUnb4ZaNMBo1mYWtxdShNs l5KhJLMzGQR7gpWMgbEZ5d31vhXwTnWcOOX5gpUoQUXU5rrldkm7bKU9LXs7K70RhjsTTp+/ DW+x55+05+094q/ag8fSeI/Ebiy0213xaRoUEha302AkEqDgb5GwpeUgFyBwqqiJN4U8cap+ yzq+t6D4k0TVNM8T3SWk11p86orW8bQCeAMu7KuY7gMythlLbSqsrV9W/wDBMP8AYzm8Uato 3xx8VPbnQrGaZvDullY5jeXEbPE11KCCI1ikVvLAw5ljD5RUXzfM/wDgsXpVlp37U+jXFrZ2 9tPf+FLS4u5YYlRriUXN3EJJCBl2EcUabjk7Y1HRQB+88ZY3KM8h/qVhof7HBe9yu15Rkml5 pNXfVytd6O/l4eNSl/tLfvH3h4W/YO+Evh74Xa2/xY0nRfEuqXyHUdd8QXrm2SxWNjMy29xu SS3hT5izhlLjcXwpCL+U2t+A9G/aO/ag/wCEJ+A3hmw8OaBe3smn6MsuoXTx3MMQkd7+eS6Z pF3RI0pjVQVRVQI8gJf6H/4KYft3aZ8aLOz+GXw9uvtfg5fsuq6jrsE7KNTdoRLFbiMEYjj8 xWkSVd4mjAKxmHL/AGF/wTf/AGR4/wBnf4Sw+IfENjAfiB4nhS6uZZLaSO502zdEeOwYSYKs rDfKAqfvDtbeIUavzjJm+Fsv9tKUoyaapwTaSfd6/N9eml7rsqfv52+9nzj4k/4IxeILHQ7m Xw98V9P1bWF2+Raapoj2VvJ8wDb5knmZcLuIxG2SAOAdw8G+KP8AwTK+PfgGGeT+y9B13Rra zN7ea1Ya7bW1paom4uJWvGgZdqpvZtuwKR83DAfr18b/AIsz/DOw0i30yG2udb1W4KQR3auY 0hjwZZDtxkjdGoXcpzJu5CkH4o/bK8SDU/hZNpvizW9Y1m91+RPI00Xs8NnIYTGWkkihdI9q fIwUggybG2nBI+Nx3jbj8nxtPJsTWnVlV0klFO0Wtb6x6a2vte7OiOWwqRdRK1j8nrdUaZfM ICA5Oe/tW4txBJzx9RX6b/8ABJ39m3w1peueKfiXc6pDqniDTpW0nTtLeKJn0+GREdrticuJ JB5kKsuwbUnGW3kJ9/eM/gt8PfiNqkWp+LPAnhnxRqUUIt47zWdHt7uZIgzMIw8iMQoZ2O3O MsT3Nfs+UeJmHylNYWgqtOdm5Xs/SzXT87nnVME6nxOzP5yZbWCePZkqPY161+zH8K7Hx144 Kaji40uyCyyW79JHJ+UHjlflJI9h1BNU/wBj74L6X8fP2ivCHgPxFeahZ6LrH2vz7jS5US4T yrOeddpdHUZaJQcqeCeh5H1X+0V8H/An/BPzxnpf/CMeJNR8RTa5pr3D6Fqs8DXsLRS7UlLx ogEUplKjMeR9nlIL8qnr+InE9etlGJy3JcNOnmdaEY0nC6dpzUXZpq3u81nst7qxnhKKVRTq O8FuWvFv/BOzSviT4rvNd0PxXN4eS+DXNzYtp5vR5x3NLIreahVT94qc4O7BC4VfqT4JadF+ zVc+EvCvhkXlz4TubqHTLyzmke4kLTO6rcoNwVZPPlRpWAA8vf8AKfLiC/In7Of7a2teLvGc PhrxNptlD9sjb7HdaYroI3RGdhIHdsgqpwVIwQBghsr9Q+EPEl740+KHhbT9HtZdRmh1G3u7 gRYxDbxzI0krkkAKB69SVUZZgD/AnE1TxL4czvLuF+JsRKUaHJOnFODi4S9xNyglKbSUo3qN te9ayd39TQWDrU516K33/r/I+3KKKy/FPibTfBXhjV/EOs3P2PR9Js5r+9ufLaTyoIkLyPtU Fmwqk4UEnHAJr9wjFzajFXbPO2Pg3/grH+0le+CfCujfCnw7qNxYan4iha+1uW2Zo2/s3LxJ bk7MFZ5BJu2OCFtyjApNg/lt4N1fXtP8T2w8MW73Wu3J+xWUUFsbidpZSFUQoASZCTtAAJO4 jBzivRvEmq+LP2y/2l7m7tLT/ipPG2sLFa2zAyJZQ4EcSyNFECY7eBF3y+XnZEzsM5rV+Hng 6z+HX7e3h/wpp0txPp+hfE630u2lu2Vpnih1VYkZyoUFiFBJAAznAHSv60wuT4LJ8h/sDFQU 6lSnKpVi9np8Ltur6eai77s8GVSVSr7WOiTsj9gP2iPDPhf4XfshfFux0qz0/wAPaYfCmpxf LtjE072TQxl3JzJK5ESbmJdztGSSK/HH9mzxdrV1Fe6dp1hf6rJpNrJf3AtLeSbyLNCu+Zyu dqIWALHAAK+9fox/wUM1/RLzWZvD3inV4ItItPDb6nZadd3Ygha9drmNZCu4CRvkVFDbgMsA Bvbd8Mfs8a5pfwv+Itp4y0Yi0OnW9/f/AGvT9ryEJazMypk7SDtxsJ2noRgmv4gxua4LF5fi snq4ScuWUVBxSS5rbK+mztbr5bn0kacozjUUke1+HPjTbm3XNwAQOQTXbeBrzXvjZ4ns9A8N 2l5dxy3EUN9qNvAZYdOicsTLK2VVcKkjBSylym1csQKzfDf/AAUc+A/iXUNWvvHf7PdlY3s8 onS50yysNVlupHLNK8zTR25Vs7TnLlizZ24+b6b+E37fn7Nmrw+HPDHhXxDDoFxflI7bQI9A urZLSWU7mjcxwmBNrMxdw5jGGbeV+aufMPBTHZFWVfNaMowV3smnbV+9FtWtu76DhmMaqtBn 46/tD2s+nftAfEfTZtRvdVGleIL7S4LrUZvNnMFtM0EKs3HCxRIoAAACgAAAAfsp/wAE0Tn9 ib4c/wDcS/8ATldV+Mvx816w8VfHz4ma1pc/2rTNS8T6neWs+xk8yKS7ldG2sARlWBwQCM8i v3a/ZCs9Msf2WfhPHpMFpb2reGdPldLJFVDO8CPOxC8b2laRnPUuWJ5Jr+ouMJwo8M5fh4LR uLXpGDX6o8XDputNv+tTx/8Aaxvo9b+Meh+G9YdL7QbfSYr+PSrlFeD7Q808bTMhGGbZGqgt naN23G993zL+0j8O/COrfDnSPHXgVdL+y28jW942jiIW80LNtSUMj7Syy7kIVSx3jJwmB6R/ wWF1TRPDfgLwZcxXjWHi7VrmfTgsMZU3WmIgeffIq/wSNAqqzgbbmbCtlivwR+zr4+bwRp3j /V4oLzU7K00mKS+sYnQW7W73UVuZJI3IDsJbiFABkhZpOCNxH814zwwx2ZYLFcW0MY3WhOCp 4dLmdSLcYS+0uXWWkuVqPK21qnH2I42MJRoOOjWr7HafsdftGeD/ANkP9ozxT4l8R6Xqt1pN 3ob6ZDb6HDFJIksktrNkrJLGoTET9DwSABjp+jvhX/gqZ+zt4j0W1vLzxXqHh28m3btK1PRb t7iHDEDcbeOWI5ADDa7cMM4OQPgD9ib9kLw5+2xP8VrvxFqureGtS0iOxGlSaa0UkKPOlyoa dHQmUKYIyVRoyfm5XIK+o+LP+CMnjbRPsf8Awh3xE8P68ZN/2ptcsptMMWNuwR+V9p8zPzZz sxgY3ZO39ww+AymdShgs/rSo1YQhGbs27qKb1s0277v8TzXOok5UldO9j9KfDfx4+GnjLW7b RvD/AMRPCmuaxdbvI0/Tdbtri4l2qXbbGjlmwqsxwOApPQV3Vfh74y/4JiftF6Tql1plh4Qs PEdrGU26ppmtWiW82VDHYLiSKUYJ2ndGvKnGRgnyWyX9oD9nPw+vm/8ACy/hf4ZubzJB/tHS LOe6aP8A4AjSFIvqVj9FroxPCWV4jGU8Pk+YRqRly6ySVm297O9krPbuKOInGLdSFj+hyivw z8K/8FJfj74bGkRL4+/tWx07yV+yapptrP8Aao48DZNN5YmfcBhn8wSHJO/cc17t4K/4LHeM bH7Z/wAJZ8PtB1zfs+yjRbybTfKxu37/ADPtG/OVxjZjBzuyNvfifCniGkubDOnWX9yav/5P y+u5EcfSfxXXyP1O1HTrXV9PubG+tob2yuomgntriMSRyxsCrI6nIZSCQQeCDX4L/tx+CdN+ Gv7U/jPwpoomTRdJ+ypZRTymVoo5baK5Me48lVad1XOTtC5LHLH9Efhp/wAFRPDnxV006ZYe DNV0rxs8EkgtriWK402IiQKpM4ZJH+VlYr5S85XIHz1+Xf7QvjDXPHnx28d6z4jvzqertqs1 rJdGGOLfHAfIiG2NVXiOJFyBzjJySSdvDvKqmA40nl+YUuTEUKTm090pNJO6unez2ewsXUU8 NzQejZ9zf8E5P2VdX8ffCyLxP4kvhp/gu91aW4tdPtm3T6pGgEMhZ1YGBPNh2dC7BXxsGxz+ m1jY22l2VvZ2dvFaWdvGsMNvAgSOJFACqqjgAAAADgAV8xf8E57w6N+zL4M8J3phTUrSxfU4 zFLuE9vdzyXKEAgNuQTKrjBAJXDHdX1JX5FmuIwGYZ1j8ywNpKrVqXkuvLJx69renVbnoU1K FOMJdEgoooriKCiiigAooooAKKKKACiiigAooooAKKKKACvlX/gqBotrq37FHjyaewhvbmwl 0+6tJJIRI9tJ9ugjaSMkEo3lSSqWGDtdx0Jr6qr4t/bFg0f42fEO18A3+q3aaRoEKy3lnZsY w13MgbEodSkm2FoypA48+QZOSB5mYZ5R4cpLMq6bUJLRdddi4UnWfIup8A/8E/dJv7TxB4l1 q3v5bS3vbM6LNFCwHnQu8csqNxkAmOIcEZG5TkHB/SXwvpdt9lVFEabULfMQo4Ge/fjpXyq/ wQ039mYQ3/hq4vLzw3fXB+0C4UM1lJtjVC8gb5hIdwB2KF2qCSWGfUdD+K1sbRT569PWv5f8 Rc5qca5pLNcLKUqDsoJ6OKS+G2tne7e+99Uz2cJTWGh7OW5X/attPBf/AArPUo/F14mn6ZcF YVmG7zPOJynlhQWZgV3YAPCkkbQ1epfsSXv7OPwe+G2kaH4B+JHhvV9c16ZEvL/ULuOy1XV7 zeYkX7LKVmjUMWWKHbwHyC7SNI/wb+3HrM3jybwtJZS2hi06O/kme5vYbcD93HJtXzHXcxWF 9qLlmYBVBZlB+SLlLmxt7Ge7tJ7WC/hNxaSzxMi3EQkeIyRkjDqJIpEyMjdGw6qQP7T8D+B8 vxfA0I4nNZwqV6kpypXj7ODi3Be7u5SjGMm7q65Vy+7zP53MsTOOJdoJpLfqz+mOiv5vvBPx W8W/Dr7Z/wAIj4u1zwt9t2fajompTWfn7N2zf5bLu273xnONxx1NfSfg7/gqR8fPDWpy3Woa /pPi2B4TEtjrGkQRwoxZSJAbUQvuABGCxXDHKk4I/V8X4SZjH3svxVOqvO8H93vLv9pHDHHw +3Fo/a6ivzD8Df8ABZK+it9Lt/GPw0t7qczBdQ1LQtTaFREZDlorWVHJZYyPlacBmX7yBvl+ hvB//BUj4BeJdMlutS1zVvCU6TGIWWsaRNJK6hVPmA2omTaSSMFg2VOVAwT8LjuBOJMv/i4O Ul3haf8A6Td/ekdUcVRntL9D62orjvB/xl8AfEPVJdN8K+OfDfibUYoTcSWej6vb3cyRBlUy FI3YhQzKM4xlgO4rsa+Hq0alCXJVi4vs1Z/idKaewV81f8FINLvdY/Yr+JMGn2dxfTpFZXDR W0TSMsUV/byyyEAEhUjR3ZuiqrE4AJr13xj8ZfDXgu/uNOuZ573V4EjkbT7GEySAOeAWOI1O Pm2swO3Bx8y5+Qv29P2ofGF18HdV8O+AvB2pQabqtpLBr2v6glu32eydSkkMMKyOxZ1LB5GU CNMlcsd8RkWaYCtn+Fy6OKpxrOcbKU4x1Ulo23vfRR+JuySbaCrCSpSnyu1ux+UeheMdf0fw t4g8OWOqz2nh7XprSfUrGEhUvGtvMMHmHGWVWldgmdpbaxBKIV+i/wBhH9kO9/ac+JcF9rel zt8MNFmJ1m8E7W4upQm6OzicAlmZjGZApUpESd6M8W7yD4BfCC8+P/xk8MfDvTtSt9Hudamk U31yjOsEUUTzSsEXlmEcb7VyoZtoLKCWH75/B74T6B8DfhroXgbwxHcJoujwtHC13MZZpGZ2 kkkduBueR3chQFBYhVVQAP6t464lo8L4SWU5Y7YiteU5Lpfd37vaPZLyV/CwtF15e0nstjYv LrQ/hx4MnuGit9F8N6DYNIYrS32w2lrBHnCRxjhURMBVHQAAdq/Gj4hKP21P2h7PXPH3i6Dw ppSxywxi48lBBYJLLPHaRzbETzAJXUSyjnjhm2o37Q+IdBsfFWgalouqQfatM1K2ls7qDeye ZFIhR13KQwyrEZBBGeDX5H/Fn9i/4ofDHxLNY2vhrUvFmlPK4stV0Oze5WeNQpDPHHueFsOA VfAyG2s4Xcf4vzXGZpgnGvl1RwlZrmSTab0u1JST8rp6+dj6OEYS0mrna/D74Vfs7fAb9pz4 d+I9f8U2umQ2+mrJpkF0q3Fre3n7qG1vZ2WNkiGGkl84+WnmRrIGXY+79JPBfxQ8G/Ek3n/C JeLdC8U/Ytn2r+xdShvPI37tm/y2bbu2PjOM7Tjoa/N/R/8Agk14y+Jmk2OreLvH48D6lCjW 0OiJp66p5MIkdgWkW5RFLM7tsXcACCW3Myr4/wCMP+CUX7QXhXSY7rTk8LeMp3mEbWWj6mY5 o1KsfMJuo4E2gqBgMWywwpGSP0zhnLcoxmS4alnOaVfrcY2lKcIuOsm0t4PRO2rlr1tZLirT qRqSdOC5fI+9P22rDUPDGt+GPHYGpXOgWtvLY6iRJvtLBt6tFJ5YG5WlLOjPyD5UKnBKhvzm +Jvjy6+I/jK+1m4Z/KciK2icn91AvCKAWIB6sQDjczEdah1uH9sP4Dtc2N5YfEO00PQNOeG4 tp4pda0CKy+zEMjqRNZPCkLEEHKptOdpT5fCtF+NfiSx8aWviK4Gl6nJb3y6jJpt3psK2NyV kEhheCNUURMRtMabRtJAxxj5TNPCz63m88dlWJp1XJJcz5o/crPdJb2+43hjuWnyzi0ej6p8 BfjBJr2neKvDPgfxdqEVwsd7pOteHrC4uvs7RSMgKyQBvJlSaFztJVwQGwAVJo+B/wBvH4// AA9N4dM+KevXf2vZ5g1yVNWxs3Y2fa1l8vO452bd3Gc7Rj7x8Bf8FnvDOs6jOnin4Z6rolgk RKTaPqkWozNJlcKY5I7cBSN53byQVA2nOR7Ha/tn/s+/tLeE49NutFj8Waqm6+g8H+KNCErx yoxiWRnZJLdTiTO5XZgkh43ZSv1jE18yyjIMPPNcuX1bDU0nUSTjyx3lK3Ot027te87b2Rwp QqVWqc9W9j8nf2ZfjHH+z38Z/DPxDTSTr40gXBGmtdfZvN862lg/1mx9uPN3fdOduOM5Fb48 fGnXf2hfixrnjjX7ieR7uZ0sbOaYSrp9mHYw2sZCqNqBsZCjcxZyNzsTynxL+F3ij4PanbaT 4p0xtJ1O4tkvI4RcRzZhZmQNmNmUZaNhgnPFdH+zJ8EvEP7Svxd0bwFo04s1uw817qkls80e n2sa5kmcIP8AdRQxUNI8aFl3ZH7fh+IeHJVqWdOMZXpq1WEueDirtWs7Wve7im72V9DzHSrW dLz2eh7L+w/4M+EXifxRc3XxH+JcfgjVPP8As+mWxHlCSEQStPI9zLCbeAlvJVGMmTtmjKZk jav1m/Zx8CfCvw74clvfhzrOl+MmjmltbrxNBe2+oXLu2x2geeEbVAHknylCjhWKliWP5oeP f+CSXxs8NWOrXHh3UvDPi6C3lKWVrbXslrfXURkCq+yaNYY2CHeymcgYIVnON3zv4z/Yg+PX gPVYtP1L4UeJrmeWETq+jWR1SEKWZQDLa+YitlT8hYMAQSMMCfxvivL+H+Jc0/tfCYvmrzST ckvdS2jFPlaX631bbt6NCdWjD2co6H9BWu67YeGdIutU1S5SzsLZN8sz5wB0AAHJJJACgEkk AAkivh//AIKQePvEXxO+Cdn4S+G2nXGu6ZqVwbvX7mKMI8dvblJIoBFKgdzJLtk3RHcPs20g iTFfNn7HvxR8UfEPS7xvFvjXxD4qEN6BHHrer3F4kZWMYZVldgrfvHGRzg4r7bt7iwbSRyC5 BypAxjHHOfr2r+SeLfETH+HfFX1TB0Kdf6tJXc+ZxlKyenLKOib0euqu1bQ92hhI4uhzSbVz 5x/4JGfs775Na+Mmt2XC79I8O/aIvp9quk3x/SBZI3/5+kYV8ux8f8FMG/7K+f8A09V+uX7M uqxt4d1vRLezkgs9Nv3lhlS3WO2PnlpZEVlxuk80ySPnn98pyd3H44ePPGNl8Ov29vEfivUY rifT9D+J1zqdzFaqrTPFDqrSOqBioLFVIAJAzjJHWv634J4oq8dYnG55yOPtqL5YXvyrZRvp e3eyu9bK54WJoLCxjS7M96/4LBfEjSPGHxi0DwXpltCuo+F7Evq2oCMiSSWcLJDbMSgJWKMi QMrMubthhWVs++fse/8ABNnR/BmheEfFfjTUZ9Xe90yPULzwnf6UbYRXM8KloLkPIxdYwzRt GUTcVG4Y3I3yD+xz8OR+15+2VPq3iiCw+xNeXfjPW9PRP3Nx/pCv9nSORZA8bTzxKyOeYvMG 7djP7eV5HHGXYLJsNg8jpR/eQSnVd3Zze1/TXTa3L2NMNOVRyqvbZeh8neJf+CXf7PWuaFc2 Fh4W1Hw3dS7dmqaZrV3JcQ4YMdguJJYjkAqdyNwxxg4I+bNF/Zn8C/s8fHLxH4f8Mpqd2LFb eJr/AFu5iuLiTfCkx2+XDGET94o24JJTJY5Cr+olfmr/AMFDZ/E/wE+JGo/ECwtvtum+Jvsi WdzPblraC7jjWKS2kKvnJigMqk7d25gA3ltX47xT/rDxRl8MlwladSVWcYpOTa9521bvaN7N 9NLs76HsqE/aSSVi1rH7Dnwo+IGuf8JBdWl9p92bqS/v4rTUXVNSeSRWZZA+4qCS3EJjIDNz wuM39qS98Q/A/wCEelan8M/FGseEf+EUntDa2On3832eeMNHCsc0RfZMBiInzVfcIypyHavB /wBmz9rvxtqXj+20DxTfx6zp+oxuI5nhige1eON5Nw8tAGDBSpDf7JBGCG7v9qfTPE3xu+HO pf8ACKaTLrFt4WLa9rE6SRxx2dpFBNvdmdlBbGSEXLsFbap2nHx+E4d424S8Rcl4e4rzNzo0 nGaam6tNUpuSkkqiW6Uqb54+6tk48t+iVbDV8JUq0IWb8rO/y+8+QPjJ8eviJ+0ZqWn6h8SP ElxrtxpsLW9lH5UVvDArNucrFEqoGYhQz7dzBEBJCKBufsueDtO8eeK9d8F6nql3otn4l0l9 PS/tyNiTi5guIFlDEB1L26/J1YgAYOGXyWPVonHJA+taGla9PpF7Fe6deT2F5EwaO4tZWjkQ ggghlIIIIB+oFf6J5zwzgs0yWpgOH8XChXcbQqcq92XMpKTSstGu1ujTWh8lTrShUU6sW11R +tH7I3wbj/YvvtVZvE8Wv23iO5tItSmuYks4LeCPcI5AdzlWQzSsxLbSvGFI3V96V/PnYftT /FCy0u20/wD4S+e+tIGLKmp21vfF/mLYkaeNzIuTja5YY+XGOK+rPB//AAWJ8f2WpyyeKfAv hrWtOMJWO30eW40+VZdy4YySPOCu0MNuwEkg7hgg/wA7YXwl8RI1MTi88xdLHVakrqUJKLsk oq8XCnGN0l7sbpa69X68sfhLKNKLil3/AKZ+sFFfA/hv/gsL8NrrRLeXxB4K8V6bq7bvPtNM FreW6fMQu2Z5YWbK7ScxrgkjkDJ988H/ALefwC8canLYad8TNKtp44TOz6xHPpkJUMq4Et1H GhbLD5AxYjJAwpI8fHcH8QZdd4nBVElfVRclp5xuvR316GkcRSn8MkeleMvgt8PfiNqsWp+L PAnhnxPqUUIt47zWdHt7uZIgzMIw8iMQoZ2O3OMsT3NfP/iX/glx+zzrmh3NhYeFtR8NXUu3 Zqmma1dvcQ4YMdguJJYjkAqdyNwxxg4I+lfB3j3wz8RNMl1Hwr4i0nxNp8Uxt5LvR76K7iSU KrGMvGzAMFZTjOcMD3FbteJRx+YZdPlo1Z02uibX3o1cIT3Vz85fiZ+wL4e/ZW0RfiD4E1Dx HrsNjuTWotXlgm+zWZG5rlTHHFhUZBv+V/lbdlFjcn8r7RfLth7Cv6Af2nvGOi3nwj8feCIN QhuPE2t6FfaVb2EJ3vFLPbmNDNjPlKPOV/mwSoJUMRivyDt/2JPiDa+KdA0vVIoLfQ9QvrS0 vNesnE8WnxzTrE8rxsY3YRht7dFCjJYAEj9J8OuMMhy/Ocfi87zSEcVWjTjapUSbVNTsld7v mso7t7JtnFjMPVnThGlB8qvsu5+ln7DWk6glrZK5hms/Dvh620K4uot5jlugsORExUBgohJO cMBJHx83H1zVHRNC03w1pkOm6Rp9ppWnQ7jFaWMCwxJuYs21FAAyzEnA5JJ71er8JyrL/wCz cP7Jy5pSlKUnteUm27Lors9SpPndwooor2DMKKKKACiiigAooooAKKKKACiiigAooooAK+b/ ANqX4E+J/Gms6d418FudR1qzt49PuNDlljiW4gEjuskTuVVZFMrbldsMuMEMu2T6Qorz8fgK GZYeWFxKvGRcZODuj89IPDnxX8TT6n4dj+HGtS3MEcsdwmoQLb2kqhtjKs8xWGUHPAV23Lkj Kgmvmj9tj4P+LP2Q5/BUVn4ig1C28TWV1JLkszWd3FIDJHCCq5gSOe3VGcs7ssjMFBVR+0Vf np/wWZ8HWV78Ifh/4skluF1HS9ek0qGJWXyWiurd5ZGYYyWDWUQUggAM+Qcgi+BeDMkwOa08 PWpe0p1XZqVmutraaa2u+wsViKkoNp2aPzs+G3wH+JX7VFxrH/CKPbeKdf0ryZJNIudUgtbp oJA4aeGOZkQxIyRrIQ2Q08PB3EjK8Q/s/wDxg+C97da5rXgrxb4QHh68UnxANPuIre1nSYLH JHeIPL/1m3ZIjkElSpOQa+j/APgk54ysvDH7WUenXUVxJP4j0K90u0aFVKxyqY7stISQQvl2 kgyATuKjGCSP2kr954izCHDGarA0MND6uoxcYK8VZ6NXXmmeVRh7eHM3qfzGxSXEOl3NhC9q 9vPNHcM7W8Zm3RrIqhZSpdFIkbcisFYhCwJRCti81O2kvNZuZdJNiLvc9ha6fcsttYuZlbaf N82SWNYxIgUyB8lGZ22sr/0SeO/2cPhX8TbnVbvxT8O/DOtalqkJgu9UudLh+3SL5YjBFyFE qsqABXVgy7V2kYGPnPxr/wAEkfgR4r1KK404eJ/CNskIjNjo2qiSF2DMfMJuo533EMFwHC4U YUHJN0eNsrlFuNKpRn05Zc0fns/QHhp900fjpcjQ5Lixi03XbjY2mm4vJtY082yxXixu7W0Q hecyKzKiJKwjy0g3rEoLCa58P63Y7PO0u4O/OPJAlxj12E4696+3Pir/AMEjvEvwj0OTxhov xF0fxBpWg28+raqmp2MumyRw26iXEIVp1kZlWT77RgELydxK+TfAS38J/FXx5Hoer6vc6XHI H8iGKEia8YI7fI+1kQBULEvgngAZJK8ebeJfEWU0J47KKcsTh6MHOq+SUuSK2b5UrW1bbT91 NuyTkVTwVKo+Wo+Vt2R80pfxSDqDX0T+zb+0F8WbH4ieF9P0n4keJoNL05PKj0+bUpLiyit1 jKLGLaUtFsAKqo2fLwVwVBH258R7TwNB4Ag0K40HSZ9B04eZbWN3bpPFCwDDeBIG+f5ny5yx 3MSSSc9h8UP2EPB3hL4WjxV4N8FJD8UdMsbL7R/wj08iw3xiSKO5VbYkRnKK8n7uNJHdAeWd lb4jD+PdXjzIMxwzyz2dVU5xhJtTs5JpNaRala7Vr2dtzpeVrC1YPnur+hL4DhSaE3FxI9xc zMZJZ5mLvI7HLMzHkkkkknrmur8T6dbLbSwv5UmF5KMGU8eor59+H/xVtprCJlnUggd66PxH 8WbW2sJGadQAp5Jr/NjFZXi54xtp3ufYRnFRPAf2evAOn/D3/gqL4FtNKRINOvIb+9itYk2p b7tOvFZF5PG5GYAYADYAwBX7BV+GnhP4rayP+CiPw9vbETaRqNh4msvDk63EAEoSS4NtdxPH IvyMVnnjPGR1BBwR+5df6DcuPeWZfUzOTlWdGKk5O8m1f4ut7NXvre99T5VcvPNQ2uFFFFch QUUUUAFfzkftUHH7T/xf/wCxx1j/ANLZq/o3r+eL9srwfqnhT9qn4tWmqW/2W7l8S32oJFvV 8wXMrXED5UkfNFNG2Oo3YIBBA/QuDaM6+JrQpK7Ub262T1OTEtKKufrp43/4Jkfs++MbfVmt fCNx4V1LUZjOdR0DUZ4mt2MgdhDDIz26KeV2CLaqsQoXCkeEfEP9j3Qv2Jf+K88O63q2q+Dp ES31VdWQT3NjIDIyz74YlXymBCYKgh9gBfzQE/QXxT410PwVaJca1qMNisn+rjbLyy4Kg7I1 BZ8FlztBwDk4Ffnn/wAFSvjTq/jjwR4f8HeDLHVrzwrI76rr2qW9pOkLeVjybdzkfIpLSuJI 9u5YGRso4HydKvLiuS4NxmY8lPE2UoyqK9k1O6jJ73jdJbv5m7Sof7RGGq8j89vi98VNU+Mn ju/8U6sv2dp1SK2sllaSO0gQYSNS34s2AoLu7BRuxX6r/wDBL/8AZdtfhF8J0+I2qRh/Fnji ziuUWSOE/YdOJZ4EjkUs379THM/zD/lipQNES3wB+wn+zPD+038cINM1q0uJvBOiwnUNceF5 IRIv3YbYSqpCtLJjK7kYxxzlGDKDX7sV+1eIuPwOTYLC8IZPBQo0IxTS6JK0Y3d3tq3u9Lt3 Z52DhKpKWIqbsKKKK/n89U+c/wBqj9nrX/iTqekeL/Bclp/wkWmW0lrdWV3K8f2+3G6SJI2y UWRXLgBgobzjudQgr4u+Gv7Q0nxX17SfCnhEDWvEuqrJ9j06OeON5CkLzPkuyqmEjc/MR0x1 IB/Qz9qn/k2D4v8A/Ynax/6RTV+PP/BM8Bf21PhsAMD/AImXA/7Bt1U0/DHKeLqGLzXFScZU YuVlb3rRbs77bbg8bPDuMI9T9k/hJ4Jj+DPwz8nXNRs1uk83UtY1HzGjtlcjLtukOFSONFXd 8oIj3FVLEV/Pbc6prvxV8Y6lqt0J9b8SazeT6jdm2tx5k87s00riONQACd7EKAAM4AAr9c/+ Covi/WdK8NeBvD9nqE1to+ry3k1/aREKty0BtzEHPUqpkZtucE7SQSqkfD/7Od74V+GnxZt9 d1Owsra0ltp7aa6kt3lNtujO14kXO1yVCFgv3ZHH8RNdGRcd0PD+GKjh8I6rhTShFdWk2ovr Z6XtdvXS9mKrhXi+W8ra6n3x/wAEsvgnF8Nv2d18XXVvcQ6942m+3TC5hkhaOziZ47RArMQy sDJOsgVdy3K/eCqT9l1+dXg//gq54R8B6xd+ENd8J6rf6HoYksbbXNGubeeS4aOQIi/Zz5aL GEyA4lYkIhK5c7fc/A//AAUr+AXjS30sT+LLjwzqF/MIBp+uadNE1uxkKKZZo1eBFPDbzLtV WyxXDAfb5jk/E2dv+3sTgalsQlU0XPyqSuovlvblVlra1rOzOaFSjT/dKS007H1FX5If8Fcf jTceKPjFovw2sdQ36N4Ys0vL+1jEyf8AExuAWAkBISTZbmEoyqdv2iYbiSVX9NLT47fDrVPD HiTxDpfjbQtd0fw5Zvf6vc6LfR3/ANigVHcu6wF2HyxSEDGW2HAJFfz9fEb4ia18WPHniDxn 4in8/Wdbu5Ly42u7JHuPyxR72ZhHGu1EUsdqIq5wK+18LciniM6ni8TBpUFfVW96W2/ld/cc 2Oq8tPlXU+qP+Cdn7M+gfFq+8Z+PvG1xqdl4S8Iwx4+yQMsd3IQ0s6+eAWxHDGA6RASEXKEM nG/698R6To/xb+F+q/DrT/DVh4a+HV/NDIbC0jKXl0sPllGuJgxLSFoYnZh852KpdwCWg8K/ A9vgT/wThfTY9OvX13UIrLxLrcMlrLHPHPJcW0sokhZmMf2eCNI3wFGLdnZVJaqPwv8AH1ql jbSK8bbcMA2CD9R3Ffyh478X5lWz+eLyubgnopx0laLaST3S0ctGtZHuZZh4KkozV/I+GP2n /wBh64+D+kR+IPC1xd6rocK4v4roq89uM8SjaFDJ2bjK4zyMlfnXwB4Gu/iB8QfD3hDT54Id R16/t9MtJ7lmWKOaaVY0aQqGIUFucAnHQGv1D/a2+I9pp3wR8UtsW5a4tDZhN+3HnMIt2cH7 vmbsd8YyM5r87vgh8V9S+A3xV0P4geHbexu9a0jz/Ih1JHkt282CSFt6o6McLKxGGHIHUcH9 +8CsfxBxzwpiMfj1CdejVcISk1FzSgpNNLS65laXKr+bTZ5WZwpYauox0TV/Q/Wjxr/wSf8A gH4p+xf2VY+IPBn2ff5n9iau8v2ndtx5n2sT427TjZt++c7uMeGeJ/8AgjDMn9sT+G/iwD/r n0zT9V0T6mGKa5jn/wB1WkWH1YR/w0eBv+CyN7Fb6Xb+Mfhrb3U5mC6hqWham0KiIyHLRWsq OSyxkfK04DMv3kDfL754L/4Ko/AjxT9s/tO/13wf5Gzy/wC2tKeT7Tu3Z2fZDPjbtGd+37wx nnH1ssr8Qsh1hGq0v5Wqt9fLmf4J27GPPhKvb8j4R8af8EsP2gvCf2L+zdM0Hxn9o3+Z/Yer pH9m27ceZ9rEGd2442bvuHO3jPh3if8AZx+L3gr+2H1v4X+LrK10jzje350a4e0iSLPmSfaF QxNGApPmKxQqNwJHNfuN4G/au+DvxHt9Lk0H4k+G7ifVJhb2dhc36Wl7NKZDGsYtpikwZmGF BQFsqVyGBPq9XS8TeKMqn7LGw1XSUXF+f+WwngqFTWLP5mEvYZR1Br3n4bftifG/w94qtjpv xX8SPPfFbInWLs6pCivIvzCG68xAwIHzABsZAIDHP7i+N/hX4K+Jn2L/AITDwfoPiv7Dv+y/ 25pkF59n37d/l+arbd2xM4xnaM9BXzt8Sv8Agmp8FfEej69e+FvCMXhjxjcF7zT9Qs9Ruore 3uw/mIPILPCkJcBWRIsKjEIFIUj2cV4r4fMsJUpY/AxlPlkotqM0m1o7SXezej9GZxwDhJOE v0PL/hXItzELm5me6u7hjNNcTuXklkY5Z2Y5LMSSSTySa9ols7ZtOjZmicSKflUglcHHI7V8 f+BfHF14S1a90DWVFlq+l3MlleWxkV/KmjYo67lJBwykZBIPY17BD8U7cWmTMvTrmv8AIjPM oxaxcnJO9z72nUjyn098BfF73ial4burpZZNPCTWayzAyfZz8pRVxkrGwXnJx5qrwAor1yvn L9krSX159b8bT2+Ipv8AiW6fOxkUuitunIBAVkLiJQwyQ0Ug4wc/Rtf11wcsWsiwyxjvNLrv a75b/K1vKx4OI5favlCiiivsznCiiigAooooAKKKKACiiigAooooAKKKKACiiigAr5V/4Kfa XZX/AOxX45uLqzt7mewn064tJZoldreU38ERkjJGUYxyyJuGDtkYdGIP1VXBfH7wzqfjX4E/ Efw9ott9t1nV/DepWFlbeYsfmzy2siRpuYhVyzAZYgDPJAr0Mur/AFbGUa/8sov7mmRNc0Wj 8QP2GfG3/CA/tb/CzVPsX2/z9YTSvK83y9v2xGs/MztOdn2jftx82zGVzkfv5X80HhTxPqXg zxBpHiHRbn7HrGk3cN/ZXPlrJ5U8Th432sCrYZQcMCDjkEV/S/X614n0F9awuKX24Nf+Au// ALccGCfuyiFFFfnB/wAFH/8AgoBpnh6x174M+A7iDUNVvIZdO8TawFWWGyidSktlF1DTMCVk bkRAlR+9yYfyzKssq5ti4YSk1HmesnpGK7t9EjuqTVOLkzhf+Cgf/BQb/hPf7S+GHwv1L/il huttb8R2j/8AIU7NbW7j/l26h5B/ruVX91kzfIvhf4UeNvDPw0t/jgfC9xd+C9N1eGzt7lme PzZ8vi4G1T+4jljSMyMVUyyRxguQ6r6J+xD+yDrP7UHxBtL65tBB8N9FvIn1vUJ96x3YUq5s YSjKxkkUgMysPKR95O4xrJ+l/wDwUM8LeV+wv4+0bw7o+21sLTT/ACNP0y2wltawXts7bY0G EjiijZjgBVRCeAK/fs8zHKuHaFLg7K9VVajXmnZtSspe8rNSafR+6rJeXlUoTrN4ifTZHy3/ AME2PiVp3x3+N2tW/ivTJZdW0fTE1fRYQyyWkTJMsc0sucEyqZYPKABUfvGPzLGR+olfi3/w Sb8ZWXhj9rGLTrqK4kn8R6Fe6XaNCqlUlUx3ZaTJBC+XaSDIBO4qMYJI/aSvxXifhvLuFswe Ayul7OlyxklvurN3er1XU9KhWnXhzTd2fnd/wVI8BaH8IPAem/EvwlYLpXifV/EaWOo+U7fZ 7oS208jSNFnasm63B3Jt3GSQuGYgj4q/Zo/aN1Lw98evC3iDxTbwazpWlLe3X9mKqqtxcLZz G2y0mQhWYRMGAJUjIDEAV+nn/BT7SrLUP2K/HNxdWdvcz2E+nXFpLNErtbym/giMkZIyjGOW RNwwdsjDoxB/ELSdXfQr2O+jjWWSJX2qx4yVKgn25zj+Ve/w9wllWbZHjcbDCxli4qahJpfH yXi9dLptavqrmVbETp1Yx5vd0uem31z4uv8A9oW8+JcX2TTdVk8SN4mjuYADFHcG6+0AJG+8 /Kx4V8j5cEnv+zn7Hv7TE37R/grVZ9WtLPT/ABNo9yIry3sFkELxSAtDKofO3O2RCu9jmIsc B1A/M/8AY01/wz4li8Q6l4p0+2u9QtI44FtLy2jktDHISwlUPuO/MZXoMDJy2/C5P7QX7MPx lu/HsfxQ8B/D3XY/DVzcWkmhXfhiENcQukSsk8Vvbkzwrvjd1l2KuSrBvnUn8rwWNzXOeJqu Q5vahLC0k22tJX5OVK71lJTU7r7KenbtlGFOiqtPXmf+Z+3moaha6TYXN7e3MNnZW0bTT3Nw 4SOKNQSzsxwFUAEkngAV+V/7Yvx88YfETULaye/1Cz8IXpmuLawj/cQSxeYnlxzIpIlkQRRy Hcz7XkJUKCBXy1pH7afx+8F2et+Btc8c69c2M81xaatpniWNLu7UlfKngaW5R54uFKlFZdrF iAGJJ1/H37SGmeNtP03Sv7Ekih0+Y+Tq73B3GNkAceTt4BYIckk4ToCSK9TP+BOK8bOh/Y9H 29G1SU3CSTSilo1Jxu/eTjFczlrypuLtFLFUI39o7PS1zv8A4H/tEeMfgTr9pc6Hq95/Yn2l Jr7Q/OH2a8TfGZF2urrG7rGqeaq7wOhxxX7H+DvFFr438I6H4isY5orLV7GDUII7hQsixyxr IocAkBgGGQCRnua/BTxQs9hourAiS2uYLeYEHKvG4U/iCCK8c8C+OvFHw+1iTUPCfiXVvCuo TQm3lvdGvpbSVoiysULxspKlkU7c4yoPauDgXI8RnlKr7OrazSStfV+d1Zf1oViqqpNXR/TN X4c/t9aBL4t/4KH+NNGSQxrdz6WjsD0QaZalyODztBx71z/gT/god+0X4AttJtLb4gy69p1h MJTa65bQXzXK+YXaOa4kT7QytkrkShlU4VlwuOK8Q/HbWvjB+0z/AMLM8VWljp2q6nPCk8Wm QyJbKUtltkCB3duQi5yx5JPA6fqcuHs84YoYvHQi1KNKpyyin8Vrx6W6bJvscPtqVdxj5o/T nwUbjxHeT6xrF0+o6rev5txdTY3SNgDtwAAAAoAAAAAAAFegat4fgNiFmg2iRNyh1xuU9D9K 8D+GnxAgksISJVI2jvXo154/gW0OZRwPWv8ALTNMNi6mMlObbk3v5n20HFRsjvf2SNQ+Hnww bWfhtpMuleHtdvtSk1mHSftoSbUPNjwzwwvIWOxbZgVjRUVEXjO419N1/Ot8evGT+L/jN4w1 C4ESv/aMlsoiBAKQnyUPJPJWNSfcnAA4pPhz8dvH/wAJ/JXwb421zw5axXi3/wBhsL+RLSWc bfnkgz5cuQiKwdWDKoUgjiv9ZuHvCjF5hkGCxVXNFUxM6UJT50370optc/M2+W/Ldq7tfrZf C1cfGFWUVC0bu1j+iqivxc8F/wDBVD48eF/tn9paloXjDz9nl/23pKR/Ztu7Oz7IYM7twzv3 fdGMc5+hfh3/AMFjdInEEHjv4d31jss182/8OXiXPn3Q2httvN5flxt87DMzsuFX5slhwY/w u4mwScoUY1UusJJ/g+V/gXDHUZbu3qfZv7VP/JsHxf8A+xO1j/0imr8eP+CaLBf21/hqO5/t LH/gsuq+7/i3/wAFF/gf8Uf2bfH+mWniDUNJ8Ra54b1SwtdD1LSbj7QJ5LeWKJGeJJIRvJUg +YQAw3FSCB8Ef8E0i5/bk+GoZWUAakACMf8AMMuq7snwWPyPJcyp42hOnKUXFc0WvsyTautV 5rQmpKNWpDldz9kf2gf2fvDn7Q3gptF1pfsuoW+6TTNXiQNNYykDJHI3I2AHjJAYAcqyqy/E mg/8EvfHtzq0EeteK/Dmn6Y27zrmwNxdTJ8p27YnjiDZbAOXGASecYP6VUV+CYnLcNi5qpVj r91/U9RTcVZHxj4x/wCCS/wI8Vwad9nj8SeHru3VvtV7pmqBpNRdguZJhPHKitlWOIljXLtx gKF8G8c/8EYdVtoNVuvBPxViurgzE6fpniDTGiQRGQYWa6jkfLLHn5lgAZl+6gb5f1Hor7XA cRZrltlhcRKNrde34nNOjTn8SP5+f2l/2TPiB+ytqugWHjWXRtQttbhlms9Q0a4eWJ2iZRJG Q6RurKHiOSm0iQYYkMF8cvJlt4RuyVyAQOuK+pP+CkPxUi+Kn7WniUWklvPp/hiGLw3bzQwy RszQF3uBJv6stzLcJuUBSqLjP3m+mv8Agjl8K4hYePviXcR28k0k0fhywkWaTzolVUuLoMnC bXL2e1uWzE4+UH5v6rWe4zJOD1nGZPnr1Iq19/efurW+yd3fz9Dw/ZRqYj2cNEj558Jf8FdP jx4XsLi1v28M+LpHnaRL7WdKaOZEIUCMC1kgTaNpbJUtlzlsYA8zvv2rJNO8U6rL4U8NyaT4 elm8yz0ufVTdtaIVGY/OMalwG3bSRkKVBLEFm/bbx5+zd8KvifcardeKfh14Z1vUdUhMF3qd zpcP26RfLEYIuQolVlQAK6sGXau0jAx+Iv7bnww8M/Br9qXxx4Q8H6b/AGR4d077D9lsvPln 8vzLG3lf55WZzl3c8scZwOABX4LluU8N8cYmWCx+BSes9G4pLqo8rWjbXTaOlrs9Sc62GXNG R7T4/wDgb8Svj18JPDWt+HryDUfttul/d6E86wNIJFhaJEZ/kcpulZi7oDhcKWAr1j9k79hX 4T2s+n+GvjHoU+rePNds5L62gOtSQ2lv5LDfbxCB4mebZMjNzKp8qQqVVCZPkjw4up+GLPQp wLvSdRhtbS8t5PmhmjDRJLDKh4IyrI6sOoKkHkGvrb9gfw34u+Jv7Q9j4zvNQm1Sw8K28gvr zUrxpZVE8E8UMUe4liSzO3ZQEfJBKhv57y3POIMkqw4ewFWEMLTrVJe5BwqtNySjKalZxje9 +VS91JtpWXqzpUqi9rJNyaXXT7juPGH/AARr8B3elxR+EviF4m0XURMGkuNaht9RhaLa2VEc aW5Dbtp3byAARtOQR5F4v/4I6fEbT9Uij8K+PfDOt6aYQ0lxrMVxp0yy7myojjS4BXbtO7eC SSNowCf1mor9wwXHvEeBt7PFya7Ss/zV/wATzpYWjLeJ+CnjD9hb9oHwLpcV/qnwt1i4glmE ATRng1SYMVZsmK1kldVwp+cqFBIBOWAPnun+M/iJ8Bdd1XRbPVvFfw31mTyv7R06C5udKuGw peLzowUY/LKWXcOkmRw3P9FtVdV0qy13S7zTdSs7fUdOvYXt7mzu4llhnidSrxujAhlZSQVI IIJBr7rD+LuZyj7PMcNTrR6q1vz5kcry+G8G0fhn4O/4KfftBeB9S04N4ut/E2l6dELddN17 ToJVuFEZRTNNGqXDsDh95l3MwBYtlgfo74V/8FePG/iW3h0jWvh3ol/4g1C6MNpf6Vdz21tb IwVVaS3cStJsbe7YlQFcD5cFj9neN/2D/wBn/wCIP2L+1PhXoNr9k3+X/Ycb6Tu37c+Z9kaL zPujG/dtycY3HPz/APEH/gl34E+H2la940+HV34nfxHpwkv9P0G4u0uLTYCWe3jVbczufK3p GDIWLbNzHJJ+NxWd8P4mhjcRXwf71wqOnGK5Yqo03DWLWielrfkdEaVaLilLS6v6Hxf+2/8A FbxifjNoOoXusSaneS+H4HkaeNFU/vrhQAEChBwDhcDOSRknPYfsPXFv8Xtc129+IKyXmgaH LZrPY208sCSRTrcK7s0ZMhMflq4CEE7SDnPHzP8AH/xNL4s+LGqXbXUlzbxw20NuruWWJBAh KKD90b2dsDuzHqTX1B+w3qUFr8J9X0+ytIJNf1jxCLGEjYktwzRQLBEXYjjfI+AxwDIx4ya/ NOJMgoZV4Z4TOPYqePn7C0rJu85qb5rq8m43i+rv2OyjVc8ZKne0Vf8AyP2LsLC20qxt7Kyt 4rSzto1hht4ECRxRqAFRVHCqAAABwAKnoorRK2iAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooA/my+JXgn/hWnxJ8X+D/tv9pf8I9rF5pP23yvK+0eRO8XmbNzbd2zO3Jx nGT1r9/v2XvFP/Cafs4fDHWX1f8At66ufDlh9r1Brn7S8t0sCJceZJklpBKsivk7g6sDyDX4 x/8ABQXw1pnhL9s34n2Gk232S1lvbe/ePzGfM9zaQ3M75Yk/NLNI2Og3YAAAA+r/AIFft0+F f2b/ANgDwdZaWY9f+IKXOp6da6M8cixW8/2p7gzXDYGYljuoGwhzIX2KV2yNF/Q/EuBxHEWS 5ZLCQc6s2kl/ig279kuW76L5HkUZKjUnzbI9y/by/bys/wBnrTbjwX4LuIL/AOJt5CC8mFli 0OJ1ys0qnIadlIaOIgjBEjjbsSX8sf2aP2TfFX7UXxGj8O+Gs2mlW2yXWNduIi0GmQEkBjgj fI21hHECC5B5VFd0qfCz4V+N/wBpP4oReHfDsU+u+JtWmku73Ub+Z2WJS+Zru6mO4hQz5Zzl mZgqhndVb9yv2Yv2c9B/Ze+Fdr4N0O5uNRkeZr7UtSuSQ17eOiK8ojyREu2NFVFzhUXJdtzt XEGHyjgTKY5ZQSqY6dnKX8vnbtuoxfq+oUnUxVTnekUdh8Lvhvovwf8Ah34e8F+HYPI0fRLO Ozg3IivLtHzSybFVTJI253YKNzuzYyawf2ktKvdc/Z1+Kem6bZ3GoajeeFdVt7aztImlmnle 0lVI0RQSzMxACgEkkAV6PRX8+wrSjVVZ6tO/zvc9ZrSx+C3/AAT08T6b4T/bF+GN9q1z9ltZ byewSTy2fM9zazW8CYUE/NLNGueg3ZJABI/emv5z/wBmvVrLRPj/APC3UtSvLfT9Os/FOlXN zeXUqxQwRJdxM8juxAVVUEkkgAAk1/RhX614lU08bhsQvtU0vub/AMzgwb92S8zwb9u7QdF8 R/sg/FO11/Uf7LsY9He8jn89Id11A6z2sW5wQfMnjhj2j5m37VIZga/A7S9Nk1q+tLCFoFmu pUgRrq5jt4gzMFBeWRlSNeeXdgqjJJABNfYf/BS79shvj/47b4d+E7ywvfh14bvFnTUbM+aN TvliKPMJCoxFH5ksSBMq/wA0m5w0ez4xjO6H8K+y4AwGIweBq+1VvaapNaLT8el18jnxc1KS t0P35+BH7FPwy+CXw3s/DEnh7TPF19uNxqGs65p8U8t5cMqh2VXDCKPCgLEpwoAyWYs7e+UV 4p+1n+03oP7MHwsvtbvru3bxLewzQeHtJkQyte3gT5S0YZT5KMyNK+5cKQAd7orfz7TpYrOM daKc61aWveUn3/rReR6rcaceyR8kf8FZf2ktFXR4vgpZ6RYazq032bVtR1O4KSnSSGLRRwgE tHcuoJZmxiGYABhNlPzftPAHi658DX3j3T/Dd3feEdG1CCzvtWa3L2kU7/MkcnqDhQ3ZTLEG IMsYbf8ABfg/xh+058a4NGsJbfUPGni/Uri6mubpktomlffPcTvtACqoEkhVFJwCEUnCn9P/ ANrL4IaB+zx/wTO8WeC9At7dVs4tKa+voYTE2o3h1CzE11ICzHc5XOCzbFCop2ooH9N4yrhe BsuwvDdBqVfESj7V+UmlJ+XaPo3ueLFSxU5Vnstj89v2fPg54r/bg8feIfCo8UWmgX1noM2s QtLatJBdzRSQxRwysG3RqxmXLgPtCZEbGvQvGH/BKv4+eEIbGLTdK0Dxmk4cSDRNWSP7Nt24 8z7WsGd2442bvutnbxnpP+CO/wDyc14l/wCxQuv/AEtsq/YevznH5vW4BzSeCyGEKdLlj7vK mtVr2f49EdkKaxUOarqz+e7wx+zx4q0vxj4eTx34B8UeF9CvbwWxudW0q5sIpXEbyCIO6KNz CNuAd2AxHTI+km/4Jz+GvENlZS6F481PRmCubj+0rSK+EhwNgTYYdmPmzndnI6YOftz/AIKL /GrQPhL+zrqen6nbnUda8TN/Z+j2UV0sMkdwmJReMM7mjgdI3ICsGdoo2wshI/Nr9iTwl8W/ Gnj7X9X8A2U+vWdlEra/DLqMMP2h5lmNvu85wWcyI7bxyAHyfmw3zvE1TjriDLsRxjkmZLL4 4amlGnGKlGvUUpX0acVJqSjFuMryST5bcy1orDUprD1Ic93v2RmeNNS8Q/syeIrvQdW1e18Q 29rKI4ruwEgkKsC0YkR1ADFMMdruBuAyxBNc9rX7W2o3tqIbGzlj3hgZrhgAhxwQBnPPuK94 /bU/ZauPg1+zBovjLxbP9s+Iev8Ai23+2LE48mxiktbyRoRt+V5C6qzuPlBUKnALSeWf8E0v +T2Pht/3Ev8A023VfPcLcBZXm+Uz4jz6hGpiKfNOUV7kJuK5neMbKKb6RSS7dDavip06io0n ZM8CvvH3inWLjRJL/wARXGtw6LcyXen2OrkXdlayPIJZNltKHi2u6gumza+MMCOK6f4P/Du4 +KQbwxDpGn288dybyTxGbicXQQpsW22+aYhEWy+RAZNwxvCnA/fH4j/AX4cfF4zv4z8D6D4j u5bNtP8At9/YRvdxQHd8kVxjzYsF3ZSjKVZiykHmvjX9qn9lrwJ+yj8PF+JPw08NnSLTS5PK 1mz+33E/2hJSqW7755nKbZiseEUk/aNx4jr6TOeK41snq4bhzCSo41qMaShK8buSVrOz2b5f 71uhjToWqKVaV49bnxVrv7A3xM0+G4n0ZbbX4Y4GuR9kkXKqu5mTDFXZwq5wkZ3ZAHJwPGrj 4YeL7bW10iLRp7/UzL9nFlaIzTmfdt8kREBzJu42hSSSAOeK+vv2dv219Z8VeL4vDfifTrKE XkbfZLrTVdBG6IzsJA7tkFVOCuMEYwQ2V+j/AAV4Pt/jp8bvCl/Z2Rafw3e2+pXOsxx7hbRR SiZInO5QfMeMooO4rvdwpCvX5qvEjxV4D4gp8O8SRjUnNRlFq0k4S0TvFrZqSd7NNN2atfs+ p4HFUnVo6H5XeM/AHjH4afYv+Ex8I694T+3b/sv9uaZPZfaNm3fs81V3bd6ZxnG4Z6iueW5i kHY1+4H7fv7Quh/C74OeJ/Bklpcat4k8W+HtQs7S0tZExbpJEYfNmGd4B8xymEO9omXK4JH5 YfsJfCHwn8Ufinfy+P8Aw5qviPwfpWmy3E9tps7wK07EJCkjqVPOZGCCSMkxZyVVkb+nct8X 5LAYnG5lGKhh0nN32T0W/dtJa7voeLPL/ejGG72IvB37aXxw8EanLf6b8U/ElxPJCYCmsXp1 OEKWVsiK68xA2VHzhQwBIBwxB98+Gv8AwVu+K3hj+zbbxbo+heNrGDzftVwYmsL+63byn7yL MKbSUHEHKpg/MS9fRfxC/wCCRfwk8Z297qXgbxHrng6e8SGSxjjnTUtMgUBNzBJMTSB1DHJu OGfI+UBK+ffiL/wR7+Jnh7z5/BnjHQPF9rDZtN5N/HJpl3NONx8iJP3sR3AIFd5UG5iG2gbj 2R4r4Dz6KWPwcYN9eTle380PXv59ifYYql8Mj6A+Gv8AwVz8F+K5ILHX/AHiTSdZubsQQW+j ywajCYyFxI0jtAynJfKhCAFB3HJA66T4leKfixdXFxqGoT6dpVxvSPSLOUpCkLgKY5CoBmyB yXyMs2AoO2vz00j9kz4wfAvxdo2vePPBF9oujR+Y5v4ZYL23jOVjCyyW8jrCS0yhfMK7jkLn Bx9rfDfxFD9jhww6DvX8P/SBxuX5fjqOB4VqNUJU1KdpN3k5SXLd6tJJPd6vXVafS5VGc4uV da3L3jv9m7wT4902RdX8P2dzM0YjF0sYSdFB3ALKuHAzngHHJ9TX0B+x/wCHtE8AfBTS/A2j S3bL4dkmhlGoTxyTOZpnn8z5FX5GaVwuVGNhXLbdzcJP4mhmtI1xGmxNuU6tyTk+/OPwFP8A gd8Q7HRvinqdlfavaaZp93pjSuLuWOJZJY5YwmGbByFll4B5ycg4GPxDw74vzmhi4ZNisTOW Ek78kpNxjJRdpRTdovo7Wut72R6WLw9Nx9pFe8fUtfzr/tOjH7TPxf8A+xw1j/0tmr+hrSdc 07X7d59M1C11GBHMbS2kyyqrAA7SVJAOCDj3Ffzv+JLsftFftN6wnhsGx/4TzxhN/Zh1X935 P229Pk+f5e/bjzV3bd2MHG6v7+8OcVQo4utiZzXJy79NX3Xoz5bGRbikfv7qfwY+H+tR6fHq HgXw1fx6faR2FmlzpFvILa2jz5cMYZDsjXJwgwBngV0Og+HtL8K6TBpei6bZ6PpkG7ybKwgS CGPcxZtqIABlmJOByST3rQor8o5Y8znbV9ep3BRRRVAFFFFABRRWV4q8T6Z4J8L6x4i1q5+x aPpFnNqF7c+W0nlQRIZJH2qCzYVScKCTjgE00nJ2W4H88H7RGqWWuftEfFPU9NvLfUdOvfFe q3NteWkqywzxPeSskiOpIZWUghgSCCCK/YL/AIJ1/AvSPBP7Nnw/8R6p4ctoPGGoWkmofb53 FxIkE00727xHcyw77adNwTaSGw4yCB+HNuNsQr+kb4MeDb34dfB7wL4U1KW3n1HQtBsNLuZb VmaF5YLdInZCwUlSykgkA4xkDpX7fx7GFHJ8Dg5JO0uZXWt4xtddvi/E8zC61JSOyooor8PP TCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK5v4j+OLT4b+CNX8R3i+ZFYxZSHL DzpWYJFHlVYrvkZF3YIXdk8A10leZftK+GtT8W/BDxTp+jQ/adRWKK7jtwrs8wgmjnaNFRWZ nZY2VVA5YqOM5HJjJ1aeGqToq81FtettPxKik2rn56ftDfsxeKf2rviDp/jibxba2l7NHBZX dpdQyNFbWyvIxa3AY/dDgLDhQx3M0m5mJ9G8N/sm+F/hd8JtS8D3T3GvQXkrXF++ooqFpzHG j7FUAxqDEGUZZlP8RIBqx8PfiZaSabCyzKQVHQ1yf7U3jPUfE3we1zRPDsd9fa1qRt7S3s9L R5Li433EatEiJlm3KWUqAcgkYwa/nLDcWcZcTYnLuE8VmDpYdV6ajKyTg3NWqSkkpv2bfMve Vrb3s160qGHoxnXjC7s/npt8z3b/AIJx/An4bfD34bX3ivwpf2fifxLql3c2V/rcdzFcyW0M cxMVopTiIeWIZXXq7OrH5REqfYFfzP6nbT6Pqd5pmp2k2n6jZzPbXVndxGKaCVGKvG6MAVZW BBUgEEEGvbvBX7cfx28Cfbf7L+KWu3P2vZ5n9tSpqu3Zuxs+1rL5f3jnZt3YGc7Rj/SHH+F2 NzF/WsPmccTUla8prlbemrceZa+SSWyVj5CGNjD3XCy8j98qK/KfwX/wWO8aWH23/hLfh5oO ub9n2UaLeTab5WN2/f5n2jfnKYxsxg53ZG36Q8Of8FXfgXren6tcX0niTw9LZRCSC11LSw8l +2GOyEwPKoYFQP3rRjLrzjcV/N8x4B4ky28qmElJd4Wn+Ebv71+B2QxVGe0vv0PyY/amvCn7 TPxgQLz/AMJhrA3E/wDT7NX6Kf8ABVn9sY+D9Eu/gf4Wy2s61ZxS69qdvdYaytXbItFWN9wl lVQXEmF8mUDa4mynwJ+0z4q1n9oz46+KvH9vY2SDV3gYWtldq4t0jhSGNGLEEtsiGWwAxyQF +6PQv2cv2QNE+NfjLw7p9/4ifw7apdw2uryIFPmI8cjL5Du2BLJJH5QDLgGRWAcjY3VjeI8o qVsuWcYjl5Uly2u4NqLSkl7ybdlG61k1dpakxo1Ep+zR65/wS4/YzHxB8Rw/FjxdZ6hb+H9B vIZ9Bj/1UWp30TsTLuDBzHbui8AbXkO0sRFJG3wXe6Xe6HfXem6lZ3Gn6jZyvb3NndxNFNBK jFXjdGAKsrAgqQCCCDX9LHhXwzpvgrwxpHh7Rrb7Ho+kWcNhZW3mNJ5UESBI03OSzYVQMsST jkk1/PZ+04c/tNfF/wD7HHWP/S2avvODc8qZvm+IbXLT5UoR/lim7L1d25Pq2zlxFJU6a7n7 w/Bfx1NrP7O/gXxn4r1WBJ7rwrYavq2qXRjt4lZrRJZ5nICpGuSzHgKoz0Ar8U/2vv2ndS/a h+LV74iZ7+z8K2f+j6Do17Ip+xwYUO5VBtEkrL5j8sRlU3usaGu//aK/bMi+Jv7NXwl+EnhZ bi10jSdC09fEU8rSRSzXlqjW4tSgOx4AY1uASX3F4DiN4mU6v/BN39lCH4/fEubxb4msbe88 BeFZk8+yvraR4dVvGRjHADwjLEdksiktkGJGRllJHs8MZNhuDcHieKM1jaV5KlG2qV2lbzls u0etmzOvUeIlGhT+Z9pf8E1/2TpvgT8OJvGXiixuLPx34qhXzbG/to0l0qzV2McIPLq0o2Sy KxXBESMitESfQP8Agoj4Y1Pxd+xl8TbHSbb7XdQ2lvqDx+YqYgtruG5nfLED5YoZGx1O3ABJ AP0ZXl/7U5x+zF8Xv+xP1j/0imr8DrZvic0zhZliXecpp+Ss1ZLyS0R6qpxhT5I7WPyW/wCC WHjK98Mftg+H9NtYreSDxHpt/pd20ysWSJYGuw0eCAG8y0jGSCNpYYyQR+1+q6rZaFpd5qWp Xlvp2nWUL3FzeXcqxQwRIpZ5HdiAqqoJLEgAAk1+GX/BNHn9tf4b/wDcS/8ATbdV9jf8FW/2 ov8AhHvDNt8IPCevGDWtVzL4mOn3GJbaxKDZaSfIcfaN+9gHVvLjAZTHOM/pvFuS4jPOJqGC wcbzqU4t+STldvtZL8l1OKhUVKi5S6M+Hv2w/wBpLXP2rv2iL19De91rw5Be/wBk+FNIt1kk MkZZYxJDF5aP5ly6iTayGT50jJYRrj9kP2T/ANnjTv2ZfgxpXhG0Pm6pLjUNbuluGmS41F40 WZ4yyriMeWqIAq/IilgXLMfg/wD4JJ/spTXHiOf4360NthYfadN8PW0kU0cks7KI57sNlUeN UeWAffDO0udjQru/VKvleKczxFCEeHoy/dUHqla3MtOm9t2+7fU3oQTftnuz4P8A+CyRx+zJ 4W/7HG1/9Ir6vhn/AIJpf8nsfDf/ALiX/ptuq/Rj/gqv4MsvFH7Heu6ldS3Ec/hzU7DVLRYW UK8rTi0KyZBJXy7uQ4BB3KpzgEH85v8Agmic/tsfDf8A7iX/AKbbqvreF5qXCmPiukan/pF/ 1MK/8ePyP3Xr8pf+CuPx9/4STxzovwk02XNh4d2arq/y/evpYj5EfzRgjy4JC+5HKt9qwQGi r7//AGqfj1Y/s2/A3xJ42uXt21C3h+zaTaXBUi6v5MrAmwuhdQ37x1RtwijlYZ21+FPhXSfE 37SPxht9Ns5RqvjHxhq7PNcNCVQzzyF5riRIkOyJdzyOVTCIrHGFrm8Mcqws8dPOMfOMadBN pNrWVt7dVFXfq0+g8bUko+zjuzj9P8Q6hoWqrd6Xci0uo1KiYRq7LkYONwODjIyOcEjua/oJ /ZS02zsv2b/hpdW1nbWtzqfhvTNQvpbaBIjdXMlnCZJpNoG52IGWPJwK/Ff9tv4c6N8I/wBp 3xV4N8PQeRpGi2mk2kG5EV5dul2u6WTYqqZJG3O7BRud2bGTX7Y/st/8my/CP/sUNI/9Ioqf iE8LmVDDZ5GmlUrfat73Ja8Y37K+3e4YTmg5Ur6I/Nv9vsW2h/tZ+IJdflm0XS9TfT/KvpLW R1aI2kSNKigZkVTHKOO8bLnIr6V8I/E3wfrXw90//hFb6zu9FtLaO1iNtMZDGqopVJNxLK4Q oCrYYcZGc18T/wDBTH452Xxg/ad1DR9NjhOmeCYW0NbkQgSXF0rk3TMxjWTakh8kIWdP3TOh xK2fr/8AZA/4J/Xfhz4Z6Fe+OfEF9Aurxrq954YtbZrWS3lk8srBNK+HH7pAkkYRGV2YLJ8o J/nnjvwlw2N4awucvEyWLq1ZWp3jyKD1batzKSsur3S5dW362Fx7jWlTt7qW/W58meGv+Ck/ xV+GPifWbbw5q2k+IPB6XN2ul6XrGlqIYopLgyJIGi8qYtgkYdyMOcrkAj3jwh/wWhsoL3Sb Txp8Mp4LYwAX+qaBqizOZRGctFaSomFaQD5WnJVWPzOVwfsbxt+xT8CviBYLaar8LfDkCLcC 583R7QaZOz4YfNNamORlO4kqWKk4JGQCPnr4o/8ABHv4T+Lm1K78Ja7r/gi/n8oWtuZV1DT7 XbsD/upcTPuAc83HDPkfKAlfuVTN+D8Xl1LBxy/2FSmoxUovS0Ulry2u7a/AtdfJ+YqeIjNy 57pm9f8A7fX7MX7R/wAPj4T8SeLb7wyviJltXsNVsp7aezkE48mR7iNZLePDpHKGaQoBjzMD co+V7LxVe/DaeO3vtS0nWdPaWWC21vQNSh1CwujGRu2TRMwDBWjcxvtkVZYyyrvXMPjH/gjt 8UvDdxqsvhfxJ4X8VafbRGa0F00tjf3bCMMYxEUeKNi+VUtPtPBZkyQvyH8cvgn43+Bviux8 OePdD/4R/WLiyXUIrc3cFzvgd3jV90Luo+aJxgnPHTBGfns08N+GuLcFzYbMP9o05Yct3q9V ryvRXfl1ZrDGVqEvehp3PuqX472ptwkc/mytwscfzMx9ABya9b+EOgvd28mo6psa9u2DbAc+ UgHyp1wTySSPXHIAJ/LP4Y/EPVPAniS8u0v5DFqtuljqRlAcz26zwzBcsCwxJbwtlSD8mM4J B+ql/bmi8A6h/Zth4dOuJBGokuTfiAeYRkqAI3zjgEnBzuGOMn+d+KPAnibDYqjlOQUPrE60 HO6cIJcrSlFuclFcrcXvrzK3VHrUMzoyi6lV2SZ98SLd+BdSTVtLP2LUrcFSjqdsinBMci8Z U4HHsCCCAR+QPwG8OSeEf2yfhzokkhnbTvHunWfnbNok8vUY03AZOM4zjJ61+ill+0FonjLw HaeIdPuHWwu4mdRcLsdCCVZWHqrKwOCRxkEjBr8vvF+la94e1lo/Fml6ppWrXam7ZNZt5YZ5 gzMDKRIAzAsG+buQeeDX2v0b8hxNWtnGT5vivq8qfLFU5r3ue81OybT9zltJLq1c583qxSp1 Kcb36rtof0m0V/P38Of2wPjF8LfITw38SNdgtbezWwt7G+uPt1pBAu3akdvcCSOPaEUKVUEL kAgEg+/eBv8AgrV8YvDtvpdrrun+G/FsFvMGvLu5s3tr27iMhZlDwusMbbTsVhCQMKWVznP9 HYzwizuleWCq06y8pcr+5q3/AJMeRHMKT+JNH7DUV+f3hD/gsV4CvdMlk8VeAvEmj6gJisdv o01vqETRbVwxkka3IbduG3YQAAdxyQPo7wX+3H8B/Hv23+zfifodr9k2eZ/bcj6Vu3bsbPta xeZ9052Z25Gcbhn88zDhDP8AK7vFYOaS6qPMvvjdemuvQ64YilP4ZI9zoqrpWq2WuaZaalpt 3BqGnXkKXFtd2sqyxTxOoZHR1JDKykEEHBBBFWq+RacXZnQFeNftmeJ9M8JfsofFm+1a5+yW s3hu909JPLZ8z3MTW0CYUE/NLNGueg3ZJABI9lr5A/4Kr+MrLwx+x1rumXUVxJP4j1Ow0u0a FVKpKs4uy0mSCF8u0kGQCdxUYwSR6OWUfrGOo0u8or8VcibtFs/G/wCFXgn/AIWV8SfCPhD7 b/Zv/CQavZ6T9t8rzfs/nzJF5mzcu7bvztyM4xkda/pPr8Cv2BfBtl46/bA+F+m38txDBBqT aorWzKrGWzgku4lOQRtMkCBhjJUsAQcEfvrX6d4kVr4vDYa/wwv/AOBO3/tpxYNe7KXmFFFF fj56AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4Z8R/2OPAPxE8STa6H1 bw1qd1K897JoVykaXcjBcu8ciSIrZUklApZnZm3E5rV+Ev7Lngr4Qat/bFiNQ1vXF8xYdT1q 4WWW3R1VWSNUVI14B+fZvw7ru2tivXqK85Zdg41vrCpR5+9le/f1L55WtcwPGfgDwv8AEfS4 tN8WeG9I8UadFMLiOz1mxiu4UlCsokCSKwDBXYbsZwxHc181/EX/AIJe/APx8Z5bPQNQ8GX1 xeNeS3fhvUHj3btxaJYZhLBHHlgQsca7dihSq5U/WdFfQ4XMMZgZc2Fqyg/JtGMoRl8SPyy+ In/BGrX7Tz5/APxH0/UfMvG8rT/Elk9r5FqdxXdcQmXzZF+RTiGNWyzfLgKfl/4qfsMfHP4O 6fqGp634Eur/AESzuJIm1TQ5o7+Jo0DsbgxxMZo4SsZbfLGgUEBtrECv3tor9Dy7xK4hwFk6 qqL+8v1Vjkng6M+lj+ZhrhBI8UilJEJVkcYKkdQR61qWniXVbLULO/tNXvra+sp0ubW5huXW SCZCGSRGByrqQCGGCD0Nft/42/4J5fBPxxrdpqE3h2fTI4rtru4sNPuStrdlmDFGjcN5aD5l AgMWA5AIwu3mfGv/AASv/Z/8VWCwaboWreD7kXAma90PV5mkdcMDGVuTNGEJYH5UByowQMg/ d4HxYw2MlH+28BHmjtKNpWvu1dRa+X4nLLAOP8OZ8E/sz/tf/H4+NtL0Cy+Ieo6tpRvBf3sW vrHqTSRrsDxmWcNMqMFVNsci7d5YYJJqj8df2SPi38QvizrvifStKtPE0Osut7JfWr2WnlpW UCTzIcxL5hZSzOq4cvvJ3MwHv3in9hu3/Y51uDxZZ+Lh4i0PVtQbTbe3vrIQXdmGDyxKZFYr NlI2DsFi+ZFITDYT2vwZ44jtoIJYpQrphlYdjX8seJni7mHDfGCzDhXD01QVJR5ZU3yzcrSl OSjKEnJP3U+ayS0Wrb9zBYCFbD8ldu9+582+I/2HtK0f4FWOj3C2U3jawtJn/ti0VoUkuHcy BHOCZEXIjDMudq5AQnA/RH9nCz+GPg74e2fgD4YeJ9L8Q6X4VT7PcJZavFf3EMkkkjs9wUY7 Hkk85sYVc7gqqqhR84eOfF4vLX7LaxyXd3cMIobeBC8krscKiqOWYkgADkk1+bHxt/Z/+J3w 38ReKdU8V/DrX9D0yK8Nzc6lJZNNYxCdwyZu4t8BJMqL8shwx2/eGKXgzmGeeIv13BcR5m4U 1J1Yc+qVSpJ80YRbSUd2oxsot6L3nczGFPCcsqMNdvkj+gyuC+P3hjU/G3wI+I/h3Rbb7brO r+G9S0+ytvMWPzZ5bWSONNzEKuWYDLEAZ5IFfiT4J/bm+OngUXn9lfFLXbn7Xs8z+2pU1Xbt 3Y2fa1l8v7xzsxuwM52jH2V8GP29fih+0ZovibQNTsdH8N+asUMWteHI57eeBGEglCGSSQeY f3eHBBQZ4JZWT9d4v4QxnA+WVc/xVWFTD0rNuLd9WklytK92+jemrscGHxEcTNUkmmz4C/Zm +NZ/Z3+NPhr4gjRf+EhOj/aB/Zv2r7N53nW0sH+s2Ptx5u77pztxxnI3/Dml+K/2yf2mLW0u 7v8A4qTxtrDS3NypMiWUODJK0ayygmO3gRtkXmZ2RKinOKb4g/Zz8VfBTxzpMfiWLRryCGWK 9jVLgXMN7GpDFTF8sgQsDGfMVN2H27gDX6H/APBLjw34ON38SvEOnaMbDxXLLaw3BRENpb2j +Yyx2pIMse+SNzIhYqfLgK424X7qt4ocPYerKrlElXxFWglCrBqUI6t8r13V3JpLdcsrNJHK sFVkrVNEnqj7c8C+BNA+GXhDS/C/hfS4NF0DTIRBaWVsDtjXJJJJJLMzEszsSzMzMxJJJ3qK K/BZzlUk5zd29W3u2eqlY+X/APgpocfsRfEf66b/AOnO1r8vv+CcWq2Wj/tn/DS4v7y3sYHm vbdZbmVY1aWWxuIoowSQCzyOiKvVmZQMkgV+oH/BTT/kyH4j/XTP/Tna1+JPgHxhe/Dzxx4a 8VabFbzajoWp22p20V0rNC8sMqyIHClSVLKAQCDjOCOtfunA2HljMixuFjvPmivnBI8vEvlq xl2Ps7/grB8fm+KfxbtvhxouoB/Dvg3d9sEMu6K51R1/eZ2SMjeQmIhuVXjka6U5Br0f/gj5 +zUYZNd+MuvWIypfR/DvnxfT7VdR74/92BJI3/5+kYV8GeB/B3ib44fE7SvD2ny3Gr+KfE2o iNru8aWdnllctLcTuA7lVBeWSTDEKrsc4Nf0HfDD4c6N8I/h74f8G+HoPI0jRbOO0g3IivLt HzSybFVTJI253YKNzuzYya6OOsBgeFcpwuUYb+PJXm79Ort05pbeSYsLKVepKpLbofib/wAF Kv8Ak9/4lf8AcN/9NlrX6Xz/AB7sv2bP+CePgjxvcNbvqNv4K0i30izuCpF3fyWUSwR7DIhd Q37x1RtwijlYZ21+aH/BSr/k974lf9w3/wBNlrW/+258Y4/Gfwu+AHwx027uEtvC3grSb/VV WWQQyXlxp9u0SNEVCs0UGGWQFuLt1G0hgd6+TYjPsryjB4eHM7Xe2ygr3bsl0XzEqipTqSf9 anm37GfwSvv2r/2ntL0vXJ7jVdPMsuveJry7nZ5ri2Rw029zIkjNNLJHEXVi6mcvg7TX9Adf DP8AwSX+AF58K/ghqnjTVftEOo+OZ4biC0lDII7C38xbeQoyKQ0jSzSBgzK0bQMuMnP3NX5N xLi51sbLCt+7SbSSd1fTmemm6S00skd1CKUebuFFFFfJHQFfjj/wWM/5Oi8Mf9ida/8ApbfV +x1fjl/wWMGf2ofDP/YnWv8A6W31fecEK+dU/R/kcuJ/hsf/AMEzfBnw5u/DPxy8d/ELwdYe MbXwbo9tex29/Zx3nlwbLuacRQynyjIwtYwrNgjBAZQzZ+K9Q1CXUru7v7hII7i6leeRLW3j t4gzMWISKNVSNcnhEUKowAAABXofgH4qxeEf2efir4Kikt21HxjqWhRvBNDIzfY7Vry4lkjc YRWWYWi4bOVkbCnBZfMbt9qKo71/UuQYOeFxmY5pVb95xjC+yShG9vWTd/Q8SrLmjCCPo/4F /GO3+HHw7PiHxDo7XsFpdNYaPBFAVgmuI0jlIVyCokBkR3fkqGUgZYBvr34ZftSeGfjn4H1K 1ls5IfIiEGpaRqSLJERLGQwB5WSNtrryASF+ZQCM/DPxA1Gy0L9mr4O+FdOvNXE+rTav4w1e 2mlX7C8sl0dOtjGqkEskemzH5wSvnttbDlV+5/8AgmF+yt4Z8RfBq78feMNCkv7rV9XJ0xZr w/ZpLS1IQOYY2AbM/wBpRkmBDCNfl2nLfyF4heD3D+KyLGZ8uaGNqYh+ylzNJJTtJOOzTUZy TS5uZp3tdHvYTMKsasaX2UtT1L4TfsOfB/4p/D611jxf8N9KH2m9nu9N/s7z9MkFq6RIvmfZ zFvBMLOmdyhZNykb2rgPGH/BGvwHd6XFH4S+IPibRdREwaS41qG31GFotrZURxpbkNuKncXI ABG05BH6E0V52SZvmuQ4alhsJi52gktZN3t1s7rU0qU6dVtyij8cfHH/AASU+NXhm31W70HU fDPjCC3mK2dna3klrfXcRkCqxSZFhjbad7KZiBhgrOcbvnvxx+y/8Y/htc6rH4i+GPia1g0u E3F5qFvp0l3YwxCMSNIbqEPCVVTlmDkLhg2CpA/oSor9Sy/xW4hwelWUai81Z/ev8jhngKUt tD+azwx4x1LwjrdtrPh/V73Q9Xtt3kahply9vcRblKNtkQhlyrMpweQxHQ19AeBv+Ch3x78D W2l2lv4/uNZ0+xmEpttctYL1rlfMLtHNcSIZ2VslciUMFOFZcLj9oPGfwW+HvxG1SLU/FngT wz4n1KKEW8d5rOj293MkQZmEYeRGIUM7HbnGWJ7mvnbxh/wSt/Z+8S6XFa6XoeseEJ0mErX2 jazPJNIoVh5ZF0Z02kkHIUNlRhgMg/YLxPybNUo55lsZ+doytv3Sa36dzn+pVKf8KZ4B8LP+ Cu3ivVry00jxJ8NtL1jU7y9WOO60XUJbGKKFto+aKRJyxU72LbwMYGBgk5/7Sfwj8Z/tS/D+ zvJfEU+reKtJZrq0trxkjt7nMaq8SKAscLsEUggBSw+bG4usnxD/AOCYx/Z807WfiRonjy98 RWOhym5h0KTQ83AtWkCEyXCTYJiicu7iJQRGx2oDx3Hwu8eW8thARKCCB0NfyJ4y8UYfKM7y /MeC4ezhSSm0+ZxlU5pXUoyeyiktLfE7NPU97L6DqU5wxLvfT5Hj/wCwx+zv8RPgB8XLnx14 r8M6faRWOnvb2kN3Pb3MskkrKGaJoy/lERrIpfKt+9AAdWcV+r3h3X7TxRodlqti+62u4xIo JUsh7o20kBlOVIycEEdq+TdZ8eR3Nq8k0/mOVALMeTgYH6V7z+znfxap8HdDuYWDRvJdgEeo upgf1Br47hvxBz7jvPMTic4jGKcE1GCajHltH3VKUn7123eT12sdNbCUsLSUaffqelUUUV+r nCFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH NfEj4faT8VPBGq+FtcE/9m6jGqO9tKY5Y2V1eORG/vK6qwyCpK4YMCQfkTU/2KPiXomu38Hh nxHoN74eEhNlLq9zPDdiMgELKscDIWXldykBsbtq52j7gorxcxybA5ql9bp81uvU0hUlD4Wf NvwL/ZMuPB+uW3ibx5qdnr+t22Hs9Os0ZrOzmDtibe4DTOFCFcogRixAZgjr9JUUV14HAYbL qKoYWCjH+tWTKTm7yPL/AImfsv8Awm+MR1KTxf8AD7QdWv8AUvK+1aqLRYNQk8vZs/0uLbOM CNF4cZUbT8pIr5Q+Lf7N3hf9kvX9P13wVDPp3g/XbkW8un3FyZksbtYhtEckjmVllSORsNu2 sj/Nh0Rfv+qGu+H9L8U6VNpms6baavps+3zbO/gSeGTawZdyMCDhlBGRwQD2p5zQq5xllTKq tWSpytpd2utnbb/gBTapzU0tT8SvjF4mHi74ma9qYiESvOIAobdkRIsQbOB12Zx2zjnGa+6P +CXvgfVNH8FeMvFF3F5Oma3c21tZb1dXl+zCXzJBlQGTdMEDKT80cgONvPs9j+w98EdP1K3v o/A0UtxBKsyi51G8njZlbcN8bzMrjI5VgQRwQQa9t07TrXSNPtrGxtobKytYlggtreMRxxRq AqoijAVQAAAOABXzeTZDLLHT5pK0FZJX7W6+RtUq89/MsUUUV9kc58Uf8FPfics37PnjT4f6 RpF3rOpzxWF1fXFs6GOwgS6SdmZQS5cCFCV2gBJQ+7AIr8iPhh4Om+IXxB8N+HIIriU6lfww SfZULyJEXHmSAYPCIGckjACkngGv05+FPi//AIS27vPEF2lvFe6vdS6hcJbKVjWSVzI4UEkg ZY4yScdzXqXhbwJ4E8GKb7w94T0TQtTkjaGW603ToLd3iJU7NyICRuUEgnHC8cV+d5b481eE 8LmGXvCOdSbl7GSlblbXKuZNO/K0pab6rTRnVPK1XlCXNp1PNP8Agm7+yE3wy+JPjTxl4lms NQ1HSsaXoaxsjukcq7pbsxshaJmXEKMrg/8AH0pDKVY/odX5rfEb9ttv2V/i7DHa+HJPE8F/ pDtdWRvzZpuaZRDIHCSBioinBBT/AJajDD5gdq5/4K/+EdV+Ht2ieEPEGg+NZ7eaOERvb3Nj ayksI5PPOHfC7XwbfG75TkfNX7Pl1DjTjjI8PxdmWElUlWhe8Em2o3SahFuS5uXmslZt6JXS PPm8Nhqrw8JWs+v+Z8a/8FKv+T3viV/3Df8A02WteU/Av4S6l8cPin4V8B6TJ5F3rl2sL3O1 W+zQBTJPPtZ0D+XEkkmzcC2zaOSKvfFTV7/45fGPUvFMurRTS+IrtHludRuzJJbYREZnURhv LQKdqxoSqIAqnAz+lP7Cnw08C/D7xz4e17RJI9Q13VPDSaFd3mjXQayadYoJ5mkidQ6ufswI +4wLnehL5T9Ql4nZdwflWCy6vGUcXXp8kYuNnSqWSSqJ2a95OKte8lb4W5Li+pTxFSU18Kd/ VeR93aVpVloWl2em6bZwafp1nClvbWlrEsUMESKFSNEUAKqqAAAAAAAKtUUV+Gttu7PTCiii kAV+EX/BSsf8ZxfEr/uG/wDpsta/d2vwj/4KWD/jOH4k/XTf/TZa1+k8AK+cf9uP84nHi/4Z 832ceXZvTio7mTfckddoqa0YLC59D/QV3H7QHg/R/h78Xtc8LaNLBOmhRWel38tq0zRPqcFp DFqJQzBXKm8S5wcAYxtAXbX9WYvFQoUMNg471OaT9Itfq0eFGLbcux51HqItXZfL3ZPLA1/R 58CPh1/wqP4L+CPBrwWEF1oukW1pd/2Ym23kuljH2iVflUnfL5jlioZi5YjJNfiR+wl8Krj4 n/tXfDe3tPtECaVqUWv3d3BbNOsMVmROBJggIsjpHDvJwGmXhjhW/fKv528SsXjaVahleIqK UYpzSXRS0V9FrZPe++56+CjFpzS8gooor8TPSCiiigAooooAK+Pvix+wzfyeJrjW/hdq+naH Bdyh5vD2pLJHaQMQxd4JI1copOzEOzaMttZVCoPsGivPx2X4bMafssTDmRcZuDvE+Qfh3+xp 4rn1mOX4geINNOjwOjnT9Dkmke8XDbkeV0jMQyE5UMWBYAocNX1xZWVvptnBaWkEVraW8axQ wQIESNFGFVVHAAAAAHTFTUVhl2U4LKoOGEpqN9+7+Y51JT+JhRRRXrmYUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQB+dvx5+Ges/s9fETV9VsNHn/4V3qEpvbW+s4t1vp5dlD28oRFWBRK+2MEbSjIAzMG Aw7H40xah9mtLNnvLy5dYYLa3UySTSMQqoijJZiSAAOSTX6XVj6J4O0Dw1qGp32kaHpulXuq S+ff3NlaRwyXcmWbfKygF2y7nLZOWb1Nflua8AYHMsU8Qp8qbu1a/wBx2wxUoKx+YPxH/wCC bHxe+Ot/beObbXtG0i41Rf8AkA+JJLiCXT7dUjEQykcuGdvNdoyqFMrnLM6p8rfEL9jb46fC qwivfEfwz1pLN45ZnudLEepRwRxAF3ma1eQQqA2cybQQGxna2P3/AKK/pbhvjvOeGMDQy3DS UqVGKhFSWyirLa3z7+up49bC060nN7s/mYjvopR1Bqy1y01sluZ5PIQ7li3nYp9QOnc/ma/c b4hf8E9PhJ8QtZF/LaX+jxjewsLA272yO7lneNJ4ZfLzlRsjKoAigKMc8j40/wCCUHwD8UfY v7Ksdf8ABn2ff5n9iau8v2ndtx5n2sT427TjZt++c7uMfqmXeMFHGWjnWBScXdNNTV9dVdRa dvLq1tq+GeXuP8OX6H5U/Dr9o74sfCM6avg74i6/o1lp3m/ZdL+1GfT4/M3b/wDRJN0LZLu3 KHDHcMMAa+lfht/wVw+MPhL+zrbxdonh/wAeWFv5n2q4EbadqN1u3lP3keYE2lkHEHKpg/MS 9dP4z/4I1+OdN+xf8Ih8R9A17fv+1f23ZT6Z5WNuzy/KNz5mcvnOzGBjdk7fmjxn+xP8fvh/ 9i/tb4Va/c/bN/l/2JEmrbdm3PmfZGl8v7wxv27sHGdpx9FUxHh/xTJzqtQqS3bbjLr3MUsX Q22P0J+Gf/BX34VeJ30yz8Y6B4g8DX9wZBdXJiXUNOtSNxT97FiZ9wCDiDhnwflBevqH4a/t NfCn4vf2bH4S8faFq19qPm/ZdLN2sF/J5e/f/okm2YYCO3KDKjcPlINfzyx30Uo6g1KpRgMH GOwrlq+EmTYyLlgcZJN7bSS+Wjf/AIEtvO6pY+pH4on9MVfz5/tqfEe1+K/7V/xL8RWMcK2T aodPgkt7kXEc8dpGlos6OAAVkEAkGMgB8ZbG4+u/sbah4t1WxvdOm8Za/wD8IfDHJp8fhtdU mGnlZSXm3W2fLw2/njB3vkHOay/i7+wT48fxtfah4A0qLXtA1CV7iKAahElxaZVWdZPOMYK7 2k2bS52oNxzyfwHKuIsi4M44xXD2a4yFN0o29pNqEG/dk43k7KVmt3umk9NfUnSq4nDRqwi3 fpuzif2H/hCfjT+0t4I0C4tRd6PBff2tqayWP2y3NrbDzWjnQ/KI5WRICzfLmdeGJCnjv2ne P2mvi/8A9jjrH/pbNX6O/Bz4X6j+zH4D0V9PvrEeL7TS7jTbzW7eyR28qeZp3RC6ksscjKy5 GGaJSyYZkPwN8SP2fvjD4j+L3iWS98HazrOratrE1zLqlnYsbK5kuJTJ5omVREiMZMkkqEyQ wXaQPpOF/F3IeMM/xEo1o0qWHhKEXOSjGcYzf7yLlyu0lZ2avFNJ93jXwFXD0lpdt9PTY+xv +CN3wqmk1Lxz8SrmO4ight4/Dli6yx+VKzFLi6DJy4ZAlntbhcSuPmI+X9QK+bf2JPBfhj4N +B9R+Huiw3EN9BdyarcXN5dCSTUTKQnmheNvlpHDEwVQoAjbJZ2r6Sr4LOOJ8LxjjZ5zgZuV GpZQbVnyxXKrro9NV3OunQlh4qnLdBRRRXjGgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy3jf4V+CviYbL/hMPCGg+K/sO/7L/bemQXn 2fft3+X5qtt3bEzjGdoz0FfMXjT/AIJQfATxQbL+yrHX/Bn2ff5n9iau8v2ndtx5n2sT427T jZt++c7uMfY1FelhMzxuAd8LWlD0bX4bEShGfxK5+W0/7Pkv7G3ivSvCk+tyeI7bUbU38esH TDZRyyeYyPEB5kgZkURE/NkCRMgAjPu3hXxskdsrRzFCVKkq2OCMEfiOK+ivjr8CtB+PHhIa XqhNjqlqWl0vWYUDTWMxAyQMjfG2AHjJAYAcqyoy/H2ufsv/ABs8E6vJYaRpNr4w04AtDqVj fwW25dzBRJHPIjK+0KxC71G4AO2DX87cd8J4/OsxqZnC9SVR8zfXmer/AB7aI9bC1404KG1j oPiJ4zgXSJxu3EqQFXkk+gFdXonjWD+zdgdNrYJJAJ49D1H4Vc8G/sSXGtaZqq/EjXS11KyL YL4auWAtlVlcyl5YhudsFNpQqqljksymPmF/Yu+J+m60llZ+LvD93oHmRq2ozrPDdCMhfMYW wVlLKd21fOw2BllycfDVPDXM/qtPljrd6XV1fv8A16nSsZDmZ6L+z7qf9sfFzUpYYpJIINIk WSdUJRGaaEqpboCwRyAeTsbHQ19K1wnwf+EWl/CDwyLC0c3+p3G19R1aVAst5KAecZOxFyQk YJCgnlmZmbu6/oThbJpZDlVPBVHeSu36t3t8jyq9T2s3IKKKK+sMAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= --HcAYCG3uE/tztfnV-- From Michael Riepe Mon Nov 20 01:30:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01067 for ; Mon, 20 Nov 2000 04:37:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:02 +0100 (MET) Received: (qmail 23542 invoked by uid 0); 20 Nov 2000 00:31:31 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx18) with SMTP; 20 Nov 2000 00:31:31 -0000 X-eGroups-Return: sentto-1101623-1561-974680265-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 20 Nov 2000 00:31:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 00:31:04 -0000 Received: (qmail 45389 invoked from network); 20 Nov 2000 00:31:03 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Nov 2000 00:31:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta2 with SMTP; 20 Nov 2000 00:31:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA09849; Mon, 20 Nov 2000 01:30:54 +0100 Message-ID: <20001120013054.53000@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> <20001119164023.13141@thrai.stud.uni-hannover.de> <3A166CAB.72499EA8@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A166CAB.72499EA8@jetnet.ab.ca>; from Ben Franchuk on Sat, Nov 18, 2000 at 11:48:59AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 01:30:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5416e55c325a7f7bcb0edd0ff2df235a Status: R X-Status: N On Sat, Nov 18, 2000 at 11:48:59AM +0000, Ben Franchuk wrote:

> > The problem is that wider adders will need more stages, so I will have
> > to re-balance several trees...
>
> Offhand I think a 32 and 64 bit adder only needs 3 levels of look ahead.

Correct -- the 64-bit adder has 3 levels.

> 4 bits ... 16 bits .. 64 bits. The real gotya's in the design will be
> gate width. All the FPGA and semi-custom logic (not that much) that I have
> seen only have 3 or 4 wide input gates. Thus a 5..16 input gate has two
> levels of delay? One may be able to get a fast adder but connecting to the
> rest of the system may be tricky.

I didn't use gates with more than 4 inputs.  All I used were the
components from my `dummy library', and all of them can be put into a
single 4-input LUT-based FPGA cell, except the half and full adders
(which need 2 outputs) and the n-bit register.  Everything else (the
IAdd entity as well as other often-used structures like the building
blocks of the carry look-ahead tree) is built from these basic gates.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Yann Guidon Mon Nov 20 02:08:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01073 for ; Mon, 20 Nov 2000 04:37:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:04 +0100 (MET) Received: (qmail 5929 invoked by uid 0); 20 Nov 2000 01:04:08 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net (mx13) with SMTP; 20 Nov 2000 01:04:08 -0000 X-eGroups-Return: sentto-1101623-1562-974682230-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 20 Nov 2000 01:04:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 01:03:49 -0000 Received: (qmail 36782 invoked from network); 20 Nov 2000 01:03:48 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 20 Nov 2000 01:03:48 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 20 Nov 2000 02:04:53 -0000 Received: from f-cpu.org (nas4-169.aub.club-internet.fr [195.36.145.169]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA18055 for ; Mon, 20 Nov 2000 02:03:30 +0100 (MET) Message-ID: <3A18798F.6868DE7D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 02:08:31 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] vhdl : 0.2-beta bundle Content-Type: multipart/mixed; boundary="------------5DB0B489951A08941692C6C3" X-UIDL: 3e5e9c3bf54437348a6a49a0d87ba982 Status: R X-Status: N --------------5DB0B489951A08941692C6C3 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,
here's a snapshot of the current bundle, before i
upload it on the f-cpu.de site. I'm willing to add more stuff,
and make something more coherent.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
--------------5DB0B489951A08941692C6C3 Content-Type: application/x-zip-compressed; name="rel0.2-beta.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="rel0.2-beta.zip" UEsDBBQAAgAIAFUNdCkVc4sMVgsAADQgAAARAAAAZi1jcHVfY29uZmlnLnZoZGytWW132sYS /t5z8h+m+VKTYhkExom56anA2OEUYwo4qe8XziItoEbSqquVKf31d2ZXQryI3MZJkpMDaHbm 2Xmf0fk53PoBh9vz7uhx5opo4S+t55UXvPrh/BzO3Ao8sSiCu8f+zcOwCsJVFtj1Kti1Wk2T rFebJee/Ls7dOLWEXMIF6M+/8qUUaZxYrgg1of7vuWbZcA33vrtiPICxz2MO+Dlacg9uZ2Nn eNfLCRtI+HQHScxdf+Hjc7XikCZcnofCw1/YHHEj4kSxSCXwM9yNBvnZJgkZQyxFLBI8Oni4 u3f+mPT/26sST+Z5Gb/xw8gumFj5+Us8H4lnC+pX5q47xybjWX/8+6zjTJAZfpmOnVHxbfI0 6TqDQfHD43gAXLlWoQQAN5WSRwokDzhL+KGwgnS68hOImfuZLTl4fOFHPNG4X6PSJHMVl36i fBfWvqdWyWsQC32OSPwIn0YsgDTy8WowMrIkJ40qTYKflfRd5aMCNECD782OvhDbQCxtZKxP TPx/eP5Z8iUK5zJBUTDfKJ7pD7oMv3Ng0UaDWHIJbC6e8aAE/leKkJQAGx0JNS8Jj4g8vJYw pxk07PO5r8AP44CHqCdGAKvQ2JJraiRsNTXhM2JAiky61plv1BSKRPMRkuyLmpQs5Ai5qp8u fImP175amZPrFfoliAjdCm8QB2xjQYe+SL5IA7rPGn/a01MdlTPQVtnX0zANO3ht/OYyF78b mrP7x8mUVNP72BtWduBugaGR8f9QU6/EGkJS4qCecQn07win0A33smv3FYQpXge5//K+iWA9 mPFnHs3wF5dh3OTQUBZ6TBowCYPxI4Sc4s9PTJRSgHmwQEMpjUsKJdQm5hY4QSDW+OyZBWkG olmFFtn0LZypFVOk9GvDpd7CR016Zl+2DOwqfbus28ZT0NF/6+izv3UqFtwLZLcWaeDtuIRh pQ09sI0GLMuCeaq0dIzsxKcc4C9gI1JYMfQwHol0uSLHTkQqXX7g1nWnoyMFrh3PIyLopIkJ nip5MXkewsOUlEbuZzRYw/758n3dfnvX2TXXjpFIo4Zlpl6WMca8R1ZVQnsBWkKSIQ2Twpq7 DoZOKYSxOHp1AqG/XFGO+Cv18bqohIcpsTq4G4CDP7FERDohavNoAzJIQhYECDbxl1GmXfSO egvO7PsOsWIaKp0znOLVJvFdjM+Qh0JuKlWkYDGqO8lheBZ8YjLyoyU6vNpz3Sx6g0SUOnGu F301bb9MWLA58uatzaaZEy5RBrnXQnIOiVioNXJoa7NTqCIunzIZuga6gyLnv0AN6Dqx0Yzw xzTyuNQmInBJbq+74SPc8YhLvPYonQeYTAe+yyMMGLx2TL8kK/T7+WabWW8JxSRDAbcCOesU 1QaOuQSFZAkJtukg40gxYAorRguCR9eI6WBF58qAqeKsdVIHxVU9cllivxJYRk0IUj5Do891 qSSn0jwoZj71px8eHqfgDJ/gkzPGWjt9auvsJ/AppQpTNtAWVG3xbhJz5iYvKfe9cfcDnnE6 /UF/+kSxe9ufDnuTCdw+jNEJR8542u8+DpwxjB7Ho4dJzwKYcAJm3OsLml5oa0mqcYr5wU7U PqGJk5X2XR3gkrvcf0Z8DCMs3vx/K2ouLBDosXTXbV4jdbYpd0RCVWEtfXQdzDVH9tXnCxtX oR+5Fma3q0u4Z+jPzjOatcvCufS9JX68d6Bm1xvvqvA4cbJ7vPph0O+MnfET+Jzz9qsfsAfA xz391UqUNwvE0ndn9XqraWH30KYjedm/LTozND89OX/RH2PF/YKo276dJur65czpUjmj/f4h Yiolu1y/h0YbDv4gJqyVc3T8X97buzXetAR5id/2GntiSmXYb94U4tuFmC+3Lnt8H/H0PtNc 0ht42z6Af5qvrztKgCSdUw3NG1wK4py1pNZXyzuvgyfWEV65Bm3iO9aPKEtv2WaVxuNuQKXF pIld/h973SkGIwogp0qNVz1juyfkWSa9Am2DG6NKKhdD3xQLXaCwaIWYt/YFfJPDTUSIiVS6 K4wv19x5625VmFNckZlvuzVsvLAUfJMHojzslbpUXbF2J5jI0NlRmExNj6u7IoxjVtn31vpN 1hYceBL2LtoUN3hkt1MQsqj5HKXtFHRqGYxHHcpwSmUgtZHxkoZkj/9OJ7rDvwUZ/6/tTlF/ un2ITHSaljDvmZlSPIzV0R2HHdOiHkdkAa+dxXwZgj3Kyje63pTmFZoeEcV4G5jXONWKmCrc QooQJzRrVdlWm09UQ/M5M687po3A6QAr5LZToQ6ICF2qWqbrfUPj3vDxvtMbT2bYh0HOgIpx jG5HVXVlymw2CEKuXlTEThOEjLKpOOvxNOtb574/eDKct2Ox6UB1+JMyCc0ZBlMVI6pOc2fF 2orKB6OQk7Ew6EyTYNr9BEdRV99qZz5whVcgTXgWRLrRoM6HmpcQs5/h4HKsKeiyhGEX9mTa G436wzsNfB92yJLPmNye/URXVuLC/2akh6IBuHmAITa+9w83/dsnfUroHqsoWmkUUODQo4y9 ywxSo0ODxcELKNLRa2qHyTn5a4SXmH6JxTHHCycCMx5MFNuASqOsG/0O9bBwDFM29sKj1j5B a0y9H0rN9rbw1Gsa/8E4aHpCMjMaLzjGYbwISnDU2+W0mcft0TZrDbudA8m7CARi3NlCo4ZM fsYztb8ptZsDcH1eOQaU+8cxILt9ilZDOgBfVOTcoy72NwjHorHsznRZPxLdaJ+iPRa9bTVo zojy+ZbhgLo2ka3WArsbaJbcnRjWy4zRbJfTlhmjftjlYHrOhqF6Fdtm6a1pdKNmd/fS/3kP b09AsssgXZZDsssg2ach2S+D1CiD1CqH1Ch12dOQGi+D1CyDdFUOqVkG6e1pSM2vhtR96g56 UAZpV8z44lMVPuolAc2Sm4iFvkuthivzBGJ2Fe7G1Wn4UMzIucuD9UDMux0xIymo3+Ne1Ujs ikhJESTZBorWvWbHkPWX0B//XgVapeoeLduiwp9pGIOiBQUVbmpHKNshRwq0OJehUx2c6wbS OsSb72pL8t1x4iXi8oRQP86O28XvMbFdTpyz3ic+zjW7S+QD4uZJ4uNJqH7ZzrRLrRAtoov5 JN8Vml061014LHzTGJjaHKUsqEK2a6qi1ZTuq7fL7OnewEOG2Xqs3v7RihrZ/G3pyh6aBaEz 6fb72saxWafrobyWHNmN4EKpO9cp6qmia1bZPpJ6h5VS8fXFxXq9tsz7CI9fmO3XBfkLTgMq oBWh57PIOJ36iWaCjJNHzpZQW6T3OlmvTNOnkB6X1Bv9+OOPJThnH51BLcN5PHe1GtvBrkLw /3h9dTWzb+lfw5ld1WZXTfrXevu6fYJ3/Wt4XxLLVmNm38xarZndm6G0q6uTvO2v4N16N7tq zFqXs1aT0Gcfeid5N76Cd6022/1H7Huz1mnczX/N+0z3i8n7X36q/VQ5xe7y+7JrfV92Vy9m 9/IRqpih9DsyeomkV7482X3rZhruzXakKbY3LHIxeLha82yxOPcjplcMHtfxr5flrsIko0+K mGcbBxKKQmhO11klG9fwXmZRiNKfeeRzFGBOYtrfGx7yNwLrbM4J2WcSCSxJeIi1RGI20Cc/ frgZWNBdcfdzNtwG5rr6FWixlfQjk8C278m+y1BAgmbO8KY0yR3Uppx2+C8ad037x8O4lK9d QluQfrEJ1rTDE3ybZRgK4i81khmGIfyLDs9gKJR21HrRX8zwu1vT7Nd8nzoX3ub7LlV7Yaw2 FjzQ/srsBPLwCGlRIjF4lE8vPb3s9aHZipkFPawlDZ9YQdHbFmmUDdluvjnAzixIsVDqczoG fF2YNjo2Iu7SGxyMK3JWep+7fc0nxZ+YI75pgi1X5P8AUEsDBBQAAgAIAEIzXynQc4zBdwIA ADkEAAARAAAAZ2F0ZV9saWIvb3IyLnZoZGyFU01vGjEQPSdS/sM75NBIywbIR1U2rbogkqwU PrSAIk6RWRvWkrFXXi8p/75jQ8KhanvzjOc9z5s3brVgbDfelVyh1UK3JXXVOExybJgTF+eU G5hqb+WmdPgyuEK33W5jJIuSCYVcikrgYXsIf9au4XGjZatkWpudsDEXPzxH4JmXskZlzcay Lei4tkKgNmv3zqxIsDcNCqZhBZe1s3LVOAHpwDS/NhZbw+V6H4go2WguLFwp4ITd1jDrEDyN F3gSWlimMG1WShZ4kYXQtQCjt32mLgXH6kDkIY++i9mxCzwaYmZOGp1ASLq3IBk1xeh+PHJk jGhwgeULc755C1N54BV1vIei6X1i47/O4CSVQ+pAXxoaqSuJlHS+S6WwEmhqsW5UFDioGq/Z /HmymCMdL/Ga5nk6ni8TqnaloVuxEwcuua2UJGrSZpl2e5IQKEbDfPBMmLSfvWTzJSnBYzYf D2czPJL1KaZpPs8Gi5c0x3SRTyezYQzMhG/ssBT/mPQ6uEXD5MIxqeqT+iVZXFOHiqNkO0FW F0LuqD+Ggpbs/y4GFqaM3gStVH0aZwK5hjYuwruVtDrO/OlvwJ88jpDpIo5w//UOI1bXSHdk 64BtV1byDR1HKdrdzs23CItZSjoC/jLjvc9PE+3QiW/Cr7jutK9vOmjf9br3vfYtjr8Cw18V Lj1WyZVldo9sOBwmF+fkaTjGteNvymxk8dbp3N/GTKnElwvtJFk2ybu0KRfnZ5Wx9AXpcJZG 6KPnF8ZDm4BN/MWSsn4BTmnKXiWei3uiwMtsUdKACteQR33hnXjr+Nl/vLQSG6kJuMTDd9oF srN/pPiopvA3UEsDBBQAAgAIAEIzXykQZrMjfgIAAEkEAAASAAAAZ2F0ZV9saWIvYW5kMy52 aGRshVNNb+IwED23Uv/DO/TQSiHlo+1qSXe1gYU2UqEogCpOlUkMsWTsyHHS5d/v2NByWO3u xbLHfs/z5s20WmAq74VNkUu0Wui1hCpri3j6E1tm+cU5BYe63BuxLSyuhtfottttTERWMC6R Cl5yPOwOxx+VrfOwVqJVMKV0w02Y8++Ow/MsClGhNHpr2A603RjOUemNfWeGR9jrGhlTMDwX lTViXVsOYV2CN9pgp3Ox2XsiCtYq5wa24LDc7CrojT88Tpd45IobJjGr11JkeBYZVxUHo79d pCp4jvWByEHGLov5MQuMNTEzK7SKwAXdG5CMis7ofnxyZAygjWe5YtYlb6BLB7ymjPeQVL1P bPjXGpyk5hDK0xeaSmoLIiWd70JKrDnqim9qGXgOeo3XZPH0slyQUSu8xmkaTxeriF7bQtMt b/iBS+xKKYiatBmm7J4keIrJKB0+ESYeJM/JYkVKME4W09F8jvFLihizOF0kw+VznGK2TGcv 81EIzLlL7NAU/6j0xrtFxcy5ZUJWJ/UrsriiDGWOgjWcrM64aCg/hoya7P8uehYmtdp6rfT6 VM4IYgOlbYB3I6h1rP7TX48/eRwgUVkY4P7LHSasqhA3ZOuQ7dZG5FvaTmK0u53e1wDLeUw6 PP4yyfunsQkadMKeH4ubTvum10H7rt+977dvcRwLjH6VuHRgKdaGmT2S0WgUXZyTqX4bVjZ/ k3orsrdO5/42ZFJG7jlXVpBnNIw96pWL87NSGxpC2pzFAQaUKfquaxy89vjI3a0o6rrgFKbo deT4ck/myZnJCipTZmtyasCdH28d58Dnd2u+FYqgKzx8o5YgxRj4dXjk+kDR8TdQSwMEFAAC AAgAQjNfKbFNTNGDAgAAUgQAABIAAABnYXRlX2xpYi9hbmQ0LnZoZGyFk1Fv2jAQx59bqd/h /9CHVQopUNpppJsWKLSRCkUBVPFUmcQQS8aOHCcd335nQ8vDtO3Fss++n+/uf9dqgam8FzZF LtFqodcSqqwt4ukDtszyi3MyDnW5N2JbWHwZXqHbbrcxEVnBuEQqeMlxvzscf1a2zsNaiVbB lNINN2HOfziG5ywKUaE0emvYDrTdGM5R6Y19Z4ZH2OsaGVMwPBeVNWJdWw5hXYDX2mCnc7HZ exAZa5VzA1twWG52FfTGHx6nSzxyxQ2TmNVrKTI8i4yrioPR385SFTzH+gByLmMXxfwYBcaa yMwKrSJwQfcGlEZFZ3Q/PjkSA2jjKV+YdcEb6NI5XlHEe0iq3qdv+NcanFLNIZTHF5pKaguC Up7vQkqsOeqKb2oZeAa9xmuyeHpZLkioFV7jNI2ni1VEr22h6ZY3/MASu1IKQlNuhim7pxQ8 YjJKh0/kEw+S52SxokwwThbT0XyO8UuKGLM4XSTD5XOcYrZMZy/zUQjMuQvs0BT/qPTGq0XF zLllQlan7FckcUURyhwFazhJnXHRUHwMGTXZ/1X0FCa12vpc6fWpnBHEBkrbAO9GUOtY/ae+ 3v+kcYBEZWGAu6+3mLCqQtyQrEO2WxuRb2k7idHudm6+BVjOY8rD+18mef80NkGDTnjjx+K6 076+6aB92+/e9ds9HMcCo18lLp2zFGvDzB7JaDSKLs5JVL8NK5u/Sb0V2Vunc9cLmZSRe86V FaQZDWOPeuXi/KzUhoaQNmdxgAFFGuABfdc4jlB7ROSuV2R1jXAyk/Uqcsjc8zyfmaygSmW2 JrEG3Eny1nEifP645luhyHWF++/UFZQ0Bn4d+vXhSPzwpeNvUEsDBBQAAgAIAEIzXylPrpcN eQIAAEAEAAASAAAAZ2F0ZV9saWIvYW5kMi52aGRshVNNbxoxED0nUv7DO+SQSMsGyEdVNq26 oZCsFAhaQBGnyKwNa8nYK6+XlH/fsSHhULW92eN5z/PmzbRaYJp3423JFVotdFtSV41DOv6J NXPi7JSCfVPtrFyXDhf9S3Tb7TZGsiiZUMilqATuN/vrj9o1PG60bJVMa7MVNubiu+cIPLNS 1qisWVu2AR1XVgjUZuXemRUJdqZBwTSs4LJ2Vi4bJyCdL/DKWGwMl6tdIKJgo7mwcKWAE3ZT w6zC5XE8x6PQwjKFSbNUssCzLISuBRj97SN1KTiWeyIPGfoqpocqMDTEzJw0OoGQ9G5BMmq6 o/vxyYExgrGB5YI5X7yFqTzwkireQVH3PrHxX3twlMohdaAvDbXUlURKOt+lUlgKNLVYNSoK HJSN12z29DKfkVELvKZ5no5ni4SyXWnoVWzFnktuKiWJmrRZpt2OJASK0SDvPxEmfcies9mC lGCYzcaD6RTDlxwpJmk+y/rz5zTHZJ5PXqaDGJgKX9h+KP7R6VVwi5rJhWNS1Uf1C7K4pgoV R8m2gqwuhNxSfQwFDdn/XQwsTBm9Dlop+9jOBHIFbVyEdytpdJz509+AP3ocIdNFHOHuyy1G rK6RbsnWPtssreRrOo5StLud668R5tOUdAT8ecZ7x7WJtujE12Etrjrtq+sO2re97l2vfYPD WmDwq8K5Byu5tMzukA0Gg+TslEwNx7h2/E2ZtSzeOp27m5gplfh0oZ0kz2gZuzQrZ6cnlbG0 hHQ4SSM8oOdHxmObAE78w4KifgSOYYpeJp6MB6bAzGxRUo8K15BND8Kb8dbx7f/8aynWUhN0 gftvNA8kFw8Hlo98uv4GUEsDBBQAAgAIAEIzXynqHYFTfQIAAEEEAAARAAAAZ2F0ZV9saWIv b3IzLnZoZGyFU8tu2zAQPCdA/mEOOTSArPiRpKiVFpUNOxEQPyDbCHwKaIm2CNCkQFFK/fdd 0k58KNpeBGrJGc7sLFstaNMLmyKXaLXQawlV1hazFDtm+dUl1Ya6PBixKyy+DG/QbbfbmIis YFwiFbzkeNwff39Wts7DWolWwZTSDTdhzn84Ds+zLESF0uidYXvQcms4R6W39p0ZHuGga2RM wfBcVNaITW05hAVT+a022OtcbA+eiIq1yrmBLTgsN/sKeut/nqYrPHHFDZOY1xspMryIjKuK g9HdrlIVPMfmSOQgY6dicVKBsSZmZoVWEbigfQOyUdE/uh+XnBgDapxn+cKsE2+gSwe8IcUH SOreJzb8aw/OVnMI5ekLTS21BZGSz3chJTYcdcW3tQw8B53Ga7J8nq2WiKdrvMZpGk+X64hO 20LTLm/4kUvsSymImrwZpuyBLHiKySgdPhMmHiQvyXJNTjBOltPRYoExRR9jHqfLZLh6iVPM V+l8thiFwII7Yceh+Eentz4tambOLROyOrtfU8QVKZQ5CtZwijrjoiF9DBkN2f9T9CxMarXz Xun0uZ0RxBZK2wDvRtDoWP1nvh5/zjhAorIwwMPXe0xYVSFuKNYh22+MyHe0nMRodzu9bwFW i5h8ePx1kvc/H03QoBP2/Ku47bRvex207/vdh377DqdXgdGvEtcOK8XGMHNAMhqNoqtLytQv w8rmb1LvRPbW6TzchUzKyB3nygqKbJb2aFKuLi9KbegJ0uIiDjAgnei7mXHo2sMjt7emqpuB c5mqN5Gjyx2Xp2YmK6hHma0ppgF3Ybx1XPs/LtvwnVAEXOPxO40DJTpwn+GJ5wNCOn8DUEsD BBQAAgAIAEIzXynqaGK2ggIAAEkEAAARAAAAZ2F0ZV9saWIvb3I0LnZoZGyFk01v4jAQhs+t 1P/wHnpopZACpV0t6a42UGgjlQ8FUMWpMokhlowdOQ4t/37HhpbDancv1njseTwz77jRgDad cFfkEo0GOg2hytpikmLDLL84J19fl3sjNoXFVf8a7WaziZHICsYlUsFLjoftYfursnUe1ko0 CqaU3nET5vynY3jOvBAVSqM3hm1B5tpwjkqv7TszPMJe18iYguG5qKwRq9pyCAum8httsNW5 WO89iJy1yrmBLTgsN9sKeu03T+MFnrjihklM65UUGV5ExlXFweht56kKnmN1ALmQoctidswC Q01kZoVWEbigcwMqo6I92p+PHIkBNc5Trph1yRvo0gVeU8Z7SOreV2z41x6cSs0hlMcXmlpq C4JSne9CSqw46oqvaxl4Bt3GazJ/nizmiMdLvMZpGo/ny4hu20LTKd/xA0tsSykITbUZpuye SvCI0SDtP1NM3EtekvmSKsEwmY8HsxmGJH2MaZzOk/7iJU4xXaTTyWwQAjPuEjsMxT86vfZq UTNzbpmQ1an6JUlcUYYyR8F2nKTOuNhRfgwZDdn/VfQUJrXa+Frp9qmdEcQaStsA70bQ6Fj9 p74+/qRxgERlYYD7b3cYsapCvCNZ+2y7MiLfkDmK0Wy3br8HWMxiqsPHXyZ59+vTBDu0wlv/ K25azZvbFpp33fZ9t9nB8Vdg8FHi0sVKsTLM7JEMBoPo4pw09WZY2fxN6o3I3lqt+07IpIzc da6sIMkmaYcm5eL8rNSGviAZZ3GAHuUZ4BFdNzYOUHtC5I6X5HVjcHKT9zpyxNzhPJ2ZrKA2 ZbYmpXrc6fHWcgp8vrfiG6EocImHHzQRJGrPLX23PB5hn3G0/Q1QSwMEFAACAAgAQjNfKReS jf96AgAAQAQAABIAAABnYXRlX2xpYi94b3IyLnZoZGyFU01vGjEQPSdS/sM75NBIywbIR1U2 rbogkqwUCFpAKafIrA1rydgrr5eEf9+xIeFQtb3Z43nP8+bNtFp4N7Ybb0uu0Gqh25K6ahx+ PedYMyfOTik4MNXOynXp8GVwgW673cZIFiUTCrkUlcDdZn/9WbuGx42WrZJpbbbCxlz88ByB Z1bKGpU1a8s2oOPKCoHarNwbsyLBzjQomIYVXNbOymXjBKQD0/zSWGwMl6tdIKJgo7mwcKWA E3ZTw6zC5WE8x4PQwjKFSbNUssCTLISuBRj97SN1KTiWeyIPufdVTA9V4N4QM3PS6ARC0rsF yajpju7HJwfGCMYGli/M+eItTOWBF1TxDoq694mN/9qDo1QOqQN9aailriRS0vkmlcJSoKnF qlFR4KBsvGSzx+f5DOl4gZc0z9PxbJFQtisNvYqt2HPJTaUkUZM2y7TbkYRAMRrmg0fCpP3s KZstSAnus9l4OJ3inqxPMUnzWTaYP6U5JvN88jwdxsBU+ML2Q/GPTq+CW9RMLhyTqj6qX5DF NVWoOEq2FWR1IeSW6mMoaMj+72JgYcroddBK2cd2JpAraOMivFlJo+PMn/4G/NHjCJku4gi3 X28wYnWNdEu2DthmaSVf03GUot3tXH2LMJ+mpCPgzzPeO65NtEUnvgprcdlpX1510L7pdW97 7Wsc1gLD9wrnHqzk0jK7QzYcDpOzUzI1HOPa8Vdl1rJ47XRur2OmVOLThXaSPKNl7NKsnJ2e VMbSEtLhJI3QR8+PjMc2AZz4hwVF/QgcwxS9SDwZD0yBmdmipB4VriGb+sKb8drx7f/8aynW UhN0gbvvNA8kF/0Dy0c+XX8DUEsDBBQAAgAIAEIzXymy1ZuobwIAADMEAAASAAAAZ2F0ZV9s aWIvbm90MS52aGRshVNNbxoxED0nUv7DO+SQSLBhyUdVNq26RZCsFD60LIo4RWZtWEvGRl4v Kf++Y0PCoWp784znPc+bN263oY2Lo13FFdptjCcF1syJi3MK+ma7t3JdOVz1r9HtdDoYybJi QiGXYivwuDmEP2rX8KjRsl0xrc1O2IiL754j8BSVrLG1Zm3ZBnRcWSFQm5V7Z1Yk2JsGJdOw gsvaWblsnIB0YJrfGIuN4XK1D0SUbDQXFq4ScMJuaphVCJ7GczwJLSxTmDZLJUu8yFLoWoDR 2z5TV4JjeSDykKHvYnbsAkNDzMxJoxMISfcWJKOmGN2PR46MLRgbWK6Y881bmK0HXlPHeyia 3ic2+usMTlI5pA70laGRuopISee7VApLgaYWq0a1AgdV4zUrnifzAul4gdc0z9NxsUio2lWG bsVOHLjkZqskUZM2y7Tbk4RAMRrk/WfCpD+zl6xYkBIMs2I8mM0wnORIMU3zIuvPX9Ic03k+ ncwGETATvrHDUvxj0qvgFg2TC8ekqk/qF2RxTR0qjortBFldCrmj/hhKWrL/uxhYmDJ6HbRS 9WmcCeTKb3EL71bS6jjzp78Bf/K4hUyXUQsPX+4xYnWNdEe29tlmaSVf03GUotONb7+2MJ+l pCPgLzPeO32X1g5xdBu+xU3cubmN0bnvdR96nTscvwUGv7a49GAll5bZPbLBYJBcnJOp4RjV jr8ps5blWxw/3EVMqcSXC+0keUafMaZduTg/2xpLn5AOZyl6fl88sAnIxGcXlPX+n9KUvU48 Ew80gZbZsqIBla4hj34K78Rb7Gf/+dBSrKUm6AKP37xSpEeOj2oKfwNQSwMECgAAAAAAawN0 KQAAAAAAAAAAAAAAAAkAAABnYXRlX2xpYi9QSwMEFAACAAgAUoxrKVM3SbLhCAAAAygAABgA AAB0ZXN0YmVuY2hlcy9pYXRlc3Q1LnZoZGztGmtP28j2M5X6H07RSkloEmxgu71NqW7g0gWJ tAgSdfmExvYkHnDG0dgJ5N/vOcev2HGAZe/d2w9UqPH4POa8H4FOB5SIZRT/2l34XgAdGOLB kdr1YRwa+No5vhjBWd/zYKRV/PZNpwPH4Wxp1MSPoXncgj3LsmCgXF/IAC6VnEn4PE2O/47i udeda9XxhdbhQpquJ78QD+Yz9FUEMxNOjJgCPo6NlBCF4/heGNmDZTgHV2gw0lNRbJQzjyWo GIT2dlGyaeip8ZIZ4cu59qSB2JcQSzONIBzz4fdvI/hdamlEABdzJ1AunCtX6kiCwLvpTeRL D5yEEZF8JSmuUinga4icRaxC3QOpEG4A1YjwDHvZJSnHNoSGuTRFTMIbCGdE2EKJlxCglXPa 7kYbFKp6oDSz90M0aewjU9TzXgUBOBLmkRzPgzbzQGz4cTY8/T4aQv/bNfzoX172vw2ve4gd +yFC5UImvNR0FihkjboZoeMlqsAsBieXx6dI0z86Oz8bXgN5/mz47eTqCr5+v4Q+XPQvh2fH o/P+JVyMLi++X510Aa4kCSaZwyOWHrO30JiejIUKokL7a3RxhBIGHvhiIdHVrlQLlE+Ai0H2 tBeZiwhCPWFdEbswZw/UGHQYt+HeKAydOFz3L9MXPm7DmXa7bfjw268wEFEE/QW69VhMHaO8 CT4O+mDt2fv/asPoqo96MP0vZ96nUha1F2B39zkzdm1717bA2v+0Z+EPpJkBJw8z+IXoA+UY YZZwdnJy0nv7Bv3Kj90o9m6CcKLcG9v+cNAVQVAPjeUDSl6F6/lUGoQi3gqITiX8t2+kjhWG ASX4DSmAMUgvveINownj+mhDN56jG/t4uLHJOWWyLTfUUYxhhdH4n+EpfAItkACd9ukQPhww o61ITTS+GSCUlJgnWiyQdWiaB+CF9xodZbWIphlSwkVw+AUaVqPVK8j7bThqw2kbzmv58P0d +7ncroM2XH+k/3x68P8OT+SK8edKjyzFgYcJDc2IeRqlJ63EVlsLYZRwAgkBZegnCJSWJJMj J0oTAhM3CdqGiMVNXhFiE9/OCEBghpHPsuuqYnjhjZGz0GDBDpwgl4RZ0j94aMOyTumXycrM G83tH6ff+zA8Pbk8effu3Xar1YNH5K9n0ScjF6QpuP8SVke1rI5ewmpQy2rwElantaxOX8Lq vJbV+V9ghcHxCP+MfRXh4cnY/CuX7NZfsnxWAuSBXs0A15fu3U1aFTdkAaZBXQ6swJdFSVvL jHg6qy0bDw1stBOZiP9kHjGXwxo2cXgz11SupNdc0uwDezs7D41A6kmMRSt7Si2Hje+BLEns sEAx663cOKR+m3IewQk+2U6NMyuWjFVvSZZtUzUBEG1wHqsnIlA4ftWauylSVbJCaxMRiF5B V1uqmk4tnfM8u2Ovl1ge87sPIWPH9DTBKJrHUm8in3DG+mpsp3CPJoZlU7WQrtFp9CqQhwRC CL0NnkjDe8tIjC6d+4SuKXuFVcZXmeQ4fmAwzFG1dALG+o+vp6xm2tzvQ3PXpVZNbCc0R6Hv pmIGSU+j5sUPLYJzm2AgC9QnKHVb+sSWezV36GnQtFp4wJmUD3arzdgj62PyYg+hI/tDctin w/5ecjhIUbHf0ouk7WLL5Wdqv8lrbsb85BN62llRW9cPQxxl3NDgsBhDUgYQdA6fD4mYLU4C kC/sBsgAsfEWMuMp4/ibcPz8Es/gFGqAoz6KsviPyhkvFhjli/bGzF8bGCqhKMdYvniPQj4q jtq47RizxGKoph5CZFSUm+dF8YD02x6NRpa13SM9BK5tGB4yL52Yqs3tnZ0djhNMWsZQOLWZ uUsDMCBsu5XHPI7RmsJ+P1eiiHySkmrVR9ihWkSoSQzX1vXVO7P6XsZEdq1HGHTQRKxLIuIq 6oamQwaIZMycE0qyMkNIN1bMoq1gr1CKKicr/QV0UTnRsk0N7wED5jNHTFrrKG7qEKwcIa+r 5Xxm2aaCFjwanvPrxaI6VP7RSJVxNoNImwiXIplrxKG3e4DBV2hGuSMCd06LaIqe1DJBk6Py Yj/BSzZ7vOsAHct4PY5VepXA3sNBL7cWg6gfsZkP6f7CbHgnwachKnnAHmSGiVtnMLg6oq8U GDW7gj87YNdYcIv8t4KTSZPh0m2hy4scLSecTR1KFSe7hV8VimQsMvF7K5YiWjRnqHfD8XjF jGTsu9zQqwYmOqreVeIUirZKbtutGIkgd1XLUSw0Gb9j86ZRBBUHw0bYSkyu87Af4bECKxm9 cqKvWzRmGixEMMcSRfpHKSxvk0la7eyQw0pByCKx+9KCwiK0np55VFIjs7znzoSpJhb5mS6/ feJyUvolt9+u3b51RNc7xfVb9wLDm4SwQUfFawoKynEdmimumnm/Sv5xkT9Eo72H24ImD5U8 r9ZiJielj/dwVxCX3YUxvzrN4ZawjTtBjRG44bRKMnAhXL+4wvB6m5r2MzhWBcsskyRlxTDp IFyzsxfe1pV6R5aqOpwYNdmEO6CTQO80yjIVRXlDSeMPLEkVO/D3hThi4g99r5QXOi5xBRo5 E3305TCLyQoblpBtsJ6j5WxeQ7VKqBXz1scBhziundv87Um+ADzL5SktO9yvEleuqxq2cq4c qeIGUphV220sFLU9cHNm16NvrMbVkvlHbmNnE+TRLs8hHvEUR43pfz0hFTc9f06i+b002OR1 vJRX6yNgMSukGaZSi1TnhSyDeplrH/PjZlhe4tc8vZr06MHban44Ne+yBgJZKYfaEl5TiQqJ OCNXpbmleWQt7uyCAAPvFjLLUNxRHq0IB+VEKmXeOZfacuYV2to12tov0PYZebSiz5MC1pi+ nCTlUx6MKfYKtLzi2MmKE+FC+viKQxivK87rivO64vzsK479X1hxrNcV5yddcTrcHFOpX77s dF6XnZ9+2fn8uuu87jqvu84/uevYP8uuYz1z17H/zq5j/XO7jvV/23VouI/DGUUUjbRpRpWX nAIGbjidBTKWKwsOqZ39/jD9FVYv+fOe5G94+KI/AVBLAwQUAAIACADUDXQpvnBDD1oLAACD IQAAGQAAAHRlc3RiZW5jaGVzL3RlbXBsYXRlLnZoZGytWetz2kgS/56q/A8dUhXDHsGPvHYh bC225Zgq/DgM5/UnapAGmLOQOI1kzP31190zelmyk9wuH2yk7unpd/9mOL2C2eXVZAYnVxfX w5EDgxsY3nRev5qcD2/gjN7g/6vL0R0MYOJcXI8GE6cNwwlcTG8mcOyAczqcOKe4Amo/r1+9 /9s+JAtiqeO5DNzVLJbrjS9i2XlYeT50IX2GRRhBvJJw9v7kegqbKPy3dGNefBJudpFarmJo nrTg6ODgAO5EEMC36fD06hKa29VuKeUfi/fuJumE0bIFhwf7R0f7xPnH0cGKhfCf0xCCMAY3 XG+UL3E7pWGB3zowjAG/h4G/A5Hp1OFFtysZyQcZQSClJ702RBKprmRtfRnHMtLgTGGr4hW/ cx6lm8QqDGAaqHhPQyDWVtYk3ZF2E57YxNKDRRSueSEThq5wV3KWeYwdxatZwkJFOoZNMveV C6iVpn26ELpxB44+t9k9zLgOPbVQKL4Lh4f7h1/YHTDfwd03o6oTqXs4F4GWAeqIPlnLINad 3FusLAZiGYk16buIpAQdLuKtiGQPdmECrgjQHZ7ScaTmCUZRxSACbx9jyfvvWBC+TAJPmvii u9bo6QU/fLucwjcZyEj4cG1sGilXok4gtLFSr9CGuRHE+UFa3Fgt4CxEyYKc3QOJVuEmqVOO 0k2sxDaEEUtpipiUjyDc0MIWarwDine2Nnf3Ux/kpnqgAha/CjeUCygU7dwq34e5hETLReK3 WQZyw+1wcn41ncDg8g5uB+Px4HJy1+M4hEjF9DKyFCYexQxti0QQ79AEFnHhjE/Occ3geDga Tu7QEizzyaVzg+V+NcYqvx6MJ8OT6Wgwhuvp+PrqxukA3EhOUpbwgqcXHC10pidjoXydW3+H Idaooe/BSjxIDLUr1QPqJzBfNrvvR5GlCD8Mlml55O7sgVpQObZhGylMnTisxpfX5zHGHha4 nTZ8/vIJLoTWMHjAsJ6I9TxS3hK/Xgzg4Ojww29tmN4MMjv+1lbGGUHVG4CIqVPEpPla3GPK QiQ4BZfkDPRCublhRatgyULKLUJz/4mk8FisCjaYE9QM2rARkZb4FjSlBpbfLojFoy0GTDlP ahfzEVlMbWFveMC+GUa6TYUImF0ozFAjqRM/xibHT7hOSpPptDtVMuatm+g4XCtNMTbZ3GZu IxT7hFEgY1+JYIm8Umjl7zp/r7NfvxoNj8eD8R0oKWXPDKvpjcOPHR17Mz9cKnd2ePj5Y2cw Gj3PEctHdHZH+P5TniBZU6RmyGvJ6Z74psBMdCulvNM2jO47ZziyZm4YLNTSkk3fC1w/8bBD 4AChUbeiEnN9EXEyp9VDQUMXYiTVMsBGqeLOE/HO1BAz2a9fYatW2B6caT4oMClp3Tfn0hkP T5pGBmURjR/cnhoX1mG3Dw1aY9OkEz/GDUBlmcuqZGi8mMS0erShV9qN9RCRu8LSdeMkssmH Aio62RGeCje2YCptwiguOqTNZSIfBWd6l3YmTmwqnkKih7nchoHnYR7rmekZXbjBICcmykbr ZqtXWIm8Ele5/n0bxlhgMwcl3dJa/IbLj8PQlyLo9hfC1zIPHA4DWu5i66G5YJRZYUfy4EFE SsxRQ3fnkp7oObQfmbv9g14dn08tvgu+CiTwDkAt0JUeeW2DQYlt6OZyqQITt9sxArQmrWyb uO01G7/YHd+isEar1atwMpneowlGLqa0KXb2hraZaHQA6r/omH4cJTwnghQO1m2Or5E335by QS16mSB29A+LYu7nhdlI/bA4y9/NJQKcF3jTpKEW+9yeaVL88Kbpgu/uyqmas9SKO1VB/zk5 SHuyejS8dJoIJ66nkzan13NGDYOHnzHJsP+UG+tl4fCxvGuh778rEGf5fa0JL1mLjGm9nmHf EOAl67kZmBFhs3+dn47qC5fG8gxHF9Y1nOA/4XKN9+FyOuoBNUOW4tF4M8Q6KfNksbBl3bPn JlzJVc6IfrtS2AC30girbQzIO8MJNKfd0zbyXBdROUuliSxlzL2WFGhQdJqtBvZLRAV03GHo 1kgCS+h0Ok+aTeaPbp+Maqo0FqrbV/84LHmbjURoFtAsefPmDe4AIcLmhR9u0V/Svdf0mhgR sZByiyRwed6hlrMVtvem7la6dgtbAtoWVPu57Y1QCF91efMDmrsNEIgdtLr9ZkgoTPd/3zvY S03JVic1q/XeCs+XL4so+IuMQGQRbjAkGGUKzlf2nBFDlDTbOTJZ7rtCF7MvtYw+W6xOwM2g /zsa2P+zcdDoPaUe5tTDKvUopx5VqR9y6ocq9WNO/Vilfsqpn6rUzzn1c5X6Jad+qVJ/zam/ Vqm/5dTfqtRBTh1Uqcc59bhKPcmpJ1XqaU49rVKdnOpUqWc59axKFS/qPH9RZ/dFnb0XdZYv 6rx4SWdTCMRA3eD9YS+t1CTjpJZNqW2Qh16pRQy+xD/dlCNpJqUS+4glljTty9b7j3np9fIl pZqOC+OBCszsJR/x9GRQDd/d4MhzrkbpviVF0wZm6xhf0cEn0DGesxWd0QpY3FWRm6gYeRDM KuZxCekVUPduwy3dgNi12Fi8TYOcfEWINX1D8I9e0cSz7xBK0SuCpfYNIyJ6ZxCrfVtGu0gt vUi5LPwheopxLSVDukhKvzOp1UtdkJpt8HqEStIEIw/yfNGmR/HVFLGlXbkLE+fPCVxdO5cw dgans4urU752TE8cJl7lmWts468ZGOenAiKfG0ROy22oGJCreN+4qEmHBC3/k1AwCKKbWOkW 74fu/1rX/3ntVwZC5sVWqJjPG4cHEOgSU3oUqOMyFzqkl8XV68Q3p7l56O1s4pmZ0KTZi1lH DmkWXNdqFSeENY7dYE7+Oiub3GfF80m6jMY5Zn12WsuRR3aX2M2SS3hELqrRpoGVlVsBinT7 hQc7/ckoCtHTE8kvv9ABLvQIDPD+bwtQr7CiILFMZq3MJUU7hXaWPlwwxNrDdFrGq/3+gUWw uQcIWNHODeJrmDZg0Q1Y+ELqM/7ieZ31o++N7crkrh/epftz00t73Ev50nNP8z0Z36s+uWmn vgW5Xr1aUf8kUU8W1kRhdPaOsPvbt2/BoRufRfH4Tq87jXejswICL4qq83+ZCyugXr1JjXrY f/OkrR47XjKjcWtBZRewpmJFdwBjrnisNWvRm8a7Y2dUNUX6BmCXPsXqyeu+sCg9aNTYdvuC bc8fFH/WPJak/1/7SqPgaz9D188cO3M7DKinHHXDKMKdzdVz4MlH+nFDx3QXTK+y44+5a1wJ ja0P3SN8aig7aEicm0GjusMir5P9/l53r95L1Jd4fDbk4wbVwMFLvHMZb3kXYwe8A0/Eos1H mQVdBTeqNpUOjYUPj4PMM6WDdDlPssP8T6fKuD5VmiyWLrP/myVL6y8WA90P/8VkocDV5Er5 RF92TXq58rOeyYDjj7awt5AE9wFCPm6adHtdvOeqW59lGTW4shIFTPojHc+iSUpD07TFvpYb upgMo/0CpMzCi0j4dzM8zgnCcmTNVPLMj4xWGImiBWnNCMYE1KVJkZJp1aHwQn5XxlOWczyd +jSJavLtp/Yoi9xHme06mXX5i5yQVnUbluiPSiTr4vg8S35NRXgcXVkv78V5Vk3W9DRR4xLL TBF9CJVnr89L8ENGCA0N3BKar1gZCXaLkB4xZzaHemW8bkn2qfcEsltq+liCfvbmOT9MWGQL +T1UpBgaSW+ZJhkv6vb5H/V/ZhPeA59tuN2by+4UnpWhr73dkmZYWNBNuU6P9CtFURkDVnNl 8Nl/os0z4umqSodrVEit+SdBrBo3RU98p90r9gIG4ziYNpsd8xROh9mxZeb6oS4j8JTM4IaE 4MzbPAH0yEDS7CGoZ3508fgMhA//A1BLAwQUAAIACADMDnQpmQ6xg6sKAACJHwAAHwAAAHRl c3RiZW5jaGVzL3JvcDJfdGVzdGJlbmNoLnZoZGzVWetv2sgW/16p/8MpkTamlzhA+thCqcqz QSIhl5DtRroSMvYAszW25UdS7l9/zznjF7aTbrX9cvkQMnNmfucx5zXD2dmv+rx8cXYGi/lN exWKIFwLx9zpDzvLhg7PngaA8zwNG9eHcCdgcja8uQPPd/8SZsj7h6538OV2F4I2rEO72WzC veE48OVuOppfg/a4O2yF+Lw5M71Id/1tHVrN83b7nFZ+bjd3DMJ/ljsZwEbaAvDbsAwvFBZs fHfPnJmQyokS7z3bCAULrNN+xnho6m0U//4LmLYwHASgvdIJxVb4Wh1MIwhpykEGFlKDyPNc P1T6Ibh0toxDu4bzq8H0eoy7g9CPzFC6TqAnXC6Qy9iX3+DScAKE+yhwsPtsBnoYna2Fb0tH t8QnCEQIWxGuduK7AUYAcu9FvmAUw7Fgh1MsU+DuBZjIITQcHIU+ShKwWG4UelEIjzLcwaMv Q6HVM30BzMj3BW7xBSocCBSr1TpvvWf7psvYtHhqW9/Yk3U3vhDIchM+Gr7owsGNUAoHMSxJ rNdRiEYLScJzlGDvWnJzYCCcjBxLKGcIhb8PwN3w4Mv1HXwRjvANG26itS1NmElToHFIbY9m gh1afH1IDTwhKW5jKWDiIrJBVu6CQGWRyYPwAxxDO2ESIzbA9RlFM0ISHo3k0cY6SnwAcot0 r/6kDTJVLTxiht+5Hmq1Q1BJBrdtWAuIArGJ7AZj4Gr4Ol1ezu+W0L++h6/9xaJ/vbzv8vHg SYF4EAoLD9qWCI26+XikB1SBIa7Gi+El7ukPprPp8h41gcl0eT2+vYXJfAF9uOkvltPh3ay/ gJu7xc38dqwD3AoSTPnNM5be8GmhMS0RGtIOMu3v8YgDlNAmn3sQeNSmkA8on4Fe5x1+fIrK ZW3X2SpXDHPm7ILcgOOGDeWgELrl8+X92Rk3YOqYegPevX8LV0YQQP8Bj3Vo7Ne+tLb471Uf mu3WxYcG3N32Uz1+aeqbO/YB3qL++z16OuYcNBx7dxC6rgUHDN0O9Dscw6QPSm6s0FX66AeB cohBmTogKmh9ju8Bg9YwqkNp1uoNmGQbMMfCJnI4sai8MgeNTrCGEq2lI9A3anWGGYGWTuKY ZhEWLQ57gect/yss/dea5+WL2XSw6C/uQQohui9fYKrBkxjzUA9Ca2W7W2muWq13b/T+bPb0 ilB8Rw11w7aLa5xoj1nTXOHamJzwxJncYqLHKMecHl3/mz7BirTCzLmR25icJhhLmLbhs78l Dm6JQG4dPOYsk2Ha1wuY47sVVUDGwuQqMXyP6yQmENryZXw9XkyHmtpOJcox9pSDVQKHTg9q 6R4R/Md3vfYDVk7XxzrxPawBCso7YukUjYEIst4l9laBN0tl+OYOQ80MsZqwCgRRIWNcoY/V x8rOVS9vnw4xJCJG/kg6q36DvwaA2kxWf4yHy/miC9Wf2NyYpj3MHBhKOSyUaZV4OWHdomNE yjOUttoFWO6jgzmjWe8y1kUaFrCWYR5sqGJg1b8eNdIBZs08bPdYMKzzkqBwN6LSfxV4AUZQ pWytI9kIL3KwIFjQX17pMDhgsjN3KOw3rIOYTfS8EakcJJ8f2zAxoi+CyA5jJ6bGxScwExMn VTV1SjuMfgseDF8aa+yKzAM2O8jCMdAbcHGn1+xWrbNJog7YlEWSMJmguxlgRfs1eIYfIAtM YX9cjmbVrKjtWpk4iThD/DJMlqoH13czdXiMYoGZEKtQ1tFmEwvSzbRnubjfe9xJdN9HocAq VaFTw/yxJu6J4k/pLbMlSkaJgf+dFCVByBBAlcwUFgWTh5EbxvG9FlvpqOD+upguxxqZsKGC +1SrvY5Nf4IMavV6t7SSyTRPhmFczHN8zMpJAsA2RyhTV7PAaYrqNCI6GZ/L3Pp8lCV0rMla LmB6p63TOve+ivwkv3gP1b7rUcZO2OooitDzRRn5b2DPFxk0gmOWk5uEU37AQDPswzVsum7u lg124wpbZ2w4ffWqDcW0+j/DHjyDPfgH2JwynsIubn4CGm3XLXo03j+4GpDr13xhWFq9hnlN BNxBcDtYi5yYoOt6wfPTmO/0KF40mTpYpyf/1SqwRR7Y7jlU/V69eoUcwMVWfGO7j5gTBCVK nKaF6iaUpfrklqQFnVIermNaxPh1yhk6DlTIpajOsyWm09NculwEvU+nzdNElXR3VLE7ON3h Bfd5iJy9SAnsfVwPvRwzGSWgj2w5BUOUxO35ZNIgMOn+lmXYRDP6PNKVFZlB7xMq2Puz1qx1 i9RWRm2Vqe2M2i5TLzLqRZn6JqO+KVPfZtS3Zeq7jPquTH2fUd+Xqb9n1N/L1A8Z9UOZ2s+o /TJ1kFEHZeowow7L1FFGHZWp44w6LlMnGXVSphrPyrx+VmbzWZmtZ2UWz8q8eU5mFQi0gLLB WaubRGp0lNvJtVUZDHZyE4It8E8nWRFp0VGIvcEQi7R4sn72JteEZVuOYjrMlQ4KMMVLfMf2 UZVY6s6obI3ns4TvkaBJAovjGKdw/1Q9x0gjFPGDR0CvBab0zUhij6YabsmrTCpq8V0hvj4w G26094YX3xFUcSJ7qSY7NztIZgfJ7FHvjMT8WGtn+ifrc9Welue75cIK7JlzC+aLIp0b4twK GqeyUhtJouI3T9W7icESI6n7h48LuNgjkatRoDJa+pSX5PAOLMd/LmF+M76Gxbg/Wl3NR2OY 3qY3KnW6x10oCs3fpGy+de/0ME/ShvgoyefkPrLVNWftWofYAVRu1qgG4ukTKy0nVL2ez9Tc NOKVkTgGqeMm/FOW6eR8kcxlAFRg0Q/TW17W76bvmwkwLSVyXqAGlZA0AHINcKeXG8T1mNTj t8JCw/r6NV36XIvKM/M/yXVhuR05xGMyS6WeJBtJ1xHTpxvup0/xyLbh7rzXVA+tmQGomyfG NVpWU3EZtxsQ9xMkPTf9XEDTBPGjOloqpdXVNEdNkluXkxu/bOKt2ODHIIzio5XAiQQyubqV UP8mqMLGikOYTX6jTvjk5ATGmK3wYp679dO0XvttNsn1xnmoKvMfrzJkWBQv15J1qCHDyxE9 wznmIW7J9Apt+olh6LmKc1WBE8997KVtW9pZV4ANimCDCrBBAWzwBNgkD8ahE6fEAmY+W+ag i1elCg7zhEPy5jZfFLDpApRmH/7tgIO+fk5RX7gKPe0Kta/psWCCCqVn5391SPziVe23wXhW doj8hSz9ZNmndVrakNyrKlQeFVVGxf6vdFZp+KeUTnuXvxu0JxA53xysusmb8dG9v2p/mn8o pH8+onOtE0Dc0nhoIZWojPNAePR+5/rnub4mPSxsxz6phHlJfZRKx5wOLJevfjEYQdEGw6a6 cwCDCyJlJhLuSOhyIiwb+umUnHoQZ+QeZd962XF+iscx5DliNqowqxwRV8YWEFYDtmiP0llW neTTS7KbPLWEaMpqvB+e+LG7Ji1thUnixXSiD6604lfnfM/h4dXb9VWHYQT86JS99h71gx97 cTx3y81kTMP/jhqa+N0xnuBRp8df2IUkr68P3BoT//gNM+kmsFDx71WtJjhBvNyOM3rcYZOf 0pDe5ONt/IrWLbybrgXsDM878JrcFSDtNlem7QbH7V1C5oLJ1SREG6unuaRbxAWEFveu8a8B FreuOPgfUEsDBBQAAgAIAEEQdCn65OkkKAMAAFYRAAAfAAAAdGVzdGJlbmNoZXMvcm9wMnZl Y3RvcnMub3V0LnR4dL2YfWujMBjA/16h3+EBD64tO5vYtyn0oFsrO9gb7TEYCMVq2oZTU4z2 rt/+4tYWjQ53uNOSNvrkSX4J9YdxcfB3WxYcYDadQGvehufb6R3cMH9HPRJ2F9SPPTtiIdwz N/YIPG9db3YJzyTklAWA1f4lXMfUc5WepjYbN2x3COlmG7Vu2rBI9411ffRNQwipMPE8eG3E ISSchHviitQ5sV0abMA1rL0YxOLUpx61VjSw+LEjlQYUVFU0vqOr0A4P8JUSQr5eXIzH3+HL 4uX+6fbx4aUrot0fIvD6pYrsVMJvFv46JiTVt+hp7PMlK2Q7bRkRHq1I4GylU3Vvh0VJJF4m DU+/7zVbO7t46bBgTTfpemvF3ENbSjpPyhIzsJL5WKdJWTxylx7bUGeJ8bAvnf5zb0Hsk1Ak i27S9QpUEfkTUZa7UNjjxxa+ldTaH1z+lh06W3xsfaEAW8OCbgLb4/B2jGGI9FMo+cuzgAQR fwvhU+ApZA7hnPBjjnaOTEO6F/fBubee3m82poSLQeCO2W535tkrFtpRcqeI+o4TF35SnxiA 0NZAyDcQ5sawh33ebHQ6HXCJw14n5dGAgCJG6oBzcMR9p4ABWIwyf3zSYB0HTtKpgZoNmNJg ORkjhHG6HAPXY4SzHxGAKYsjkSFOU6WQQMsSaDkCXIkgA4AKCXpZgl6OQKtCkE0oJuhnCfo5 gl41ApwuhQSDLMEgR9CvQGDOZrN0KSQYZgmGOYJBNQIzXQoJRlmCUY5gWInANNOlkOAqS3CV IxhVITCzDIUEepZAz/tAXBEiWyWtDZg8TKv5IXMUGwpJikJ5Q9TOJGsz702tdiZJpDhv0l7t TJJacd6t/dqZJNnivG0HtTNJ+sV5/w4/lck006WYSRIyzht59IlMWaL31klSNB6V+Olx/t+X SXI2virRUw1IksSxXmKnSkimdBQ/5EkS11CJnGpAkhyu4RI31YAkPwtrJWqqAUkyuNYrMVMN SJLAtX6JmGpAEv5OMkBRFJgFbrJ12xMneamxpgmmoqhJi+O7jmSzxiO224nNmh0lM0AQ8Ez4 nb0c4gbW9GQv9xdQSwMEFAACAAgAQRB0KXzvfuUPAQAAOwIAABsAAAB0ZXN0YmVuY2hlcy9y b3AydmVjdG9ycy50eHRlkE1PhDAQhu8k/IfhpskudtgPD+sFQji2US9cWWxckqVVBI3/3mG6 g26EvNMJPDwdmiuF+DerQuH1vapUHFVIySgbypayo+wp93FUEnGAxpVw0/r+2DkLvX+xt/wG uWZcN1y3XHdc91zJYdhhhn8KwwrDCsMKwwrDCsMKw4rHA7xP3ZjGURyBf2vpexhscwbuqsm1 Y+cdPH/3R3/uWnBNb4kEpRTwRQ3SkkOuSyjmJ9QEAoVAtRB3RSA0IygSvCC1eQoSamYCERci bCMAXACZA8NEOWghtBC4EEFRC1ILgovkdxeelBo9Lw/rNSRJAuOJzrhxEx3Qp0oz6D7ga/Du FU52sOnVxCj/pOVk5uYHUEsDBBQAAgAIAFoQdCkJ3jFlkwAAAMwAAAAhAAAAdGVzdGJlbmNo ZXMvbW9kZWxzaW1fdGVzdHJvcDIuYmF0bY7LCsIwFET3gfzDXSrYNNaFuBMEd2IRXZcmvW0u zQOSWn/fKAgi7oY5nGEiOpgwTZdzXQnVTrDQS8BIozCtT+j3CqMlLzpcwVqW1baspJScxexd DSXIjjbQk0W4J0xwCh3aRE5wNltS8AhxzFEHB8VuA8fiUN8aHXxPg5hNZ7/Y+8OfrnkdVOi1 +dC8/0M44+wJUEsDBBQAAgAIAFoQdCl91YNXkQAAAMgAAAAiAAAAdGVzdGJlbmNoZXMvbW9k ZWxzaW1fdGVzdHJvcDIudW5peG2OQQrCMBRE94Hc4UM3CjaNcSHdeQFRxH1p0l/zaZqUJK3X ty4EEXfDPN4wBWRM+Xa5KqHbDBuzBYw0CNv6hP6kMTryosMd7GWljpWSUnJWwN1SgtUwFnpy CHPCBOfQoUs0Cs4WRxqeIQ5rNGGEsj5AX5ppbkzwPT3EYjv3xWKY1L+ued/T6I390HX/h3DG 2QtQSwMECgAAAAAA8hJ0KQAAAAAAAAAAAAAAAAwAAAB0ZXN0YmVuY2hlcy9QSwMEFAACAAgA aw50KRTBksJEAQAA9QIAABQAAABjb21waWxlX21vZGVsc2ltLmJhdH2Ry27CMBBF90j8wyxB gpCEVqisKlUVq+7aBRJS5NgTMiKxI9vh8fedJC3l0SBl4cyZe+d6bLEEacqKCkxKo7BwVAap 8DCSY0BLuyAX2qF+TdEWpAOFE4jCWbyYxWEYDgeW9Rb3EAYxrFfMFrMoatkEhBKVRwWZseBz BI0HcHWqyKL0xhK6oDM4CKtJb2HJbeSAP6Gh1h5dK+dsDDhTKU5swiUBnJUyksKT0QGM1qtx Z/XZGHB+mXe62qGDj9+LDQf7glI4GLvjI98bpi9zyKayqhNpdEbbYJ+rorN6a9fS5GrCb4VH YLEV9gTLC3UDEgYboVX8I/8Xzh/Bp16ojY96obHxAzZ/wPoHHv9M79fwfkRZN0uHL03eXW3i zFq0saa6C3fTQkKp3lHN86eoZY7XYy7q7YzkXLiddtlJovl7blu+AVBLAwQUAAIACABnDnQp bpZXA9QAAAAgAgAAEgAAAGNvbXBpbGVfc2ltaWxpLmJhdHWPyw6CMBBF9yb8wyw18QGoMXFr jB+gLkxMSCkDnQRa0haDfy/gCx9d9py5czsaC+CqKCnHyFBBOU1jZmHIR3DajSFYzYJgFvq+ 7w10M3oQZKAZ4ALSJgKVQQP7e84bXESSl5BOeFlFXMmUsmmL7tFN10IyAysQMmYRcoo101dY P6MtjRp6ZjIJH9lfM3eaxX8jlQ3+G6VDl5i7hKOkfu/6PXdbI68sKQlHSda8L36Jjp+1Kj8/ 9OWJJYmzxKKxMUousFfQg9326AU+evpjxNrXsvM3UEsDBBQAAgAIAGoPdCkfKXWi2gAAAEAB AAAUAAAAdGVzdF9yb3AyX3NpbWlsaS5iYXRdjsFqwzAQRO+B/MOSUwKpYvvSW0kxPfTUUl8L QZHWtogsGa1kN39frV1a6G1nmNl5AQeISPES/FhdyAzGGnGVEfb1Aeb+3iGe2wc1JuFDB+Xj qSxPVVEU203gZm8IWmMREiFBs9SPMMgbAqWAIK3NIVwyBDI7yg9jFlpsN1Ovc3MZZoQrOtXD E/zeSJ98f7y9V8KnKOJXXGdfW8AJwz3Puw4ygr/B3jhlk2aDB3daus6yeq7rl6bZwSyDy/pw XH+MFiWtOIzFnTj7H9D/syCdBjYmVNEH+sP5BlBLAwQUAAIACABOEHQpiETlMS4bAACYRwAA CwAAAENPUFlJTkcudHh0nVxbc9tGln4Oa/kfuvRiqYpWYmeTTKKpqaIkyuaMRCkkZUdvA5JN EWMQ4KIByfz3+51LNxq8ONl1TcYWCZw+ffpcvnNpffedwZ8Po0fzYTAajPu35uHx8nZ4ZfDf YDQZdDvf8RP488mWLi1y875n/lnn1rz79dd33U63Y66KzbZMn1eVOb06w8d/+7XHX5qb0loz KZbVa1Jac1PU+SKpQKJnhvn8HG/u/PnpVzO1601mzUOWzK15ayZ1Wlnz448/9Mxl4Sp69a5v fnj/7t27t+9+/OGXnnmc9EFo8GLLbQGmUmc2tlynVWUXpirMHLyZJF+YReqqMp3VIIdnZ+Bj TV+m1uH1YmmqFV7N0rnNnTWLYl6vbV71DF4w81WSP6f5s0krop8XlUmyrHi1i3Pa/3cioYfS JutZZlkkZrqynpozy6I0a7BvnJcF/bewLn3Ohc0q+YIPX5Ot2RZ12e0sIblFsaav3IpfwBaY D2yxOjfmcgvu86pMHJissBgfoc1tmWTmoZ5h7W7nVrcDptO8svlCFnuukzLBz5YXM99ai77r djzbb9/imTWx6mo8R8uGHWENepj3CumAS2dqB5U5J2GkkHKbO+OZSzabDKdAy7OM+CxsW3e6 nUZ53rhIjDlvKMm3psBLpdmUxXOZrM3rqiDSdbUqSgdJraEReLLbqZ0cJLg6nRRrq+8d09TW /uYFNAcinG27HS/y23RWJuXWHNlcmrvKJovzM2OeitrMk5z3uzXKDh+AMu1wkEVxLvrzeWVz 8wr5bmzyhWTCwvXc9Ogr4qq0S1uWtCWIQQ+yRxra7WxK8IBt3mOFw9y5PTWMzzapSD26nVXy Ikcd6UlkTGJDexyaU9Wi8pl1giQGEUIhXrC4SZdE3LymbnXWC4thO3ObvhCVupwT7QUOqGSx PVsYH7bl34QC4+foXXpItbalmHgfemjA5Vz4ZCq5ye2rsOzFfyHq5Ol9yYvXQHhREFFHpCFs p4c0Lejlys4rsSR2go4PJ7eRREtL4pqTQjlZABKZpYtuB5pLXotEanM2fl1HSBHzpN/ui3xV 0OGUZMglb1KeAjdTeam1DmzcZUnF1Oe2rBJsGk9s8GU6S7O0StU1EWkRa7dz8GRjefaIJz2E dbFIl6TLKo8bfGW/JuTBe/6ZgwRdPV+ZxEseAltZMsNuBz9WKW+b/YhZWlDipWq4hudUVRF6 koJWDgmRr2lEwdJlszKkt+didvzyjm7jnS0bXC9oXaRp+JbcXtBCEOpDOQInbgXlwENrrxaI OeSXmKyoDv6VYkfhiNiq7SGFgRlUK1O94nQru3G/mdN3Zxy4JKi2pQ8d7XZO359BjDB91Zgo dL2uUsiWJOX4y8w+w/A5JjoO3xoUe62zBtXvOUjxgcYrKuf9zEFSdCg2obNjzwpXrNshwmQ9 2JToP9un13/VPvIBkLz1sbomPXYV3nPhTMTT5gUIlBSktrwm77Adi3Aiw+VeCOINpOyj8fna 0jI2cxIpNolz+IpAxCsoqQtxsTaBYz08sPPq9YR1yYd+WrLAyaR5kvWwiO6KYhCEAQCw5mhb Fot6LoxwiKFThqoSBTjtjFSADiMiBm8g8eoNntjUFQcgrzk39ES27fE6sdsitqoVsAfiO5YD KCCJVggxLAIfPzf0fUXBGDpIbpf9ykuRLpiHBfnNUraNEOcVg4InzDVR2YfoSjtJ80X6ki5q YssUM3YvskoAPnACubHQ0zmbH4epVUQHfyNK2QoB9Fy9KZSDFAfnzWrEgl8nC0I9Zp7ZRHmE FPyexCBnAW4tREtVyd4oLKEQgI9J/OG5hHHceQPYNqQJwZo5gBXYpfhTokqGg130Gq+mit/t iObNBTUsC8KHoPxfHj9/C2Hj6+lgfDcx/dG1ubofXQ+nw/vRxNzcj/Hjw9Nw9KFnroeT6Xh4 +Uhf8YN399fDm+FVnz6QLfxwzkjrELJS7WSpYx8Cel6L8ov6C8KSOECgtIRkRCF6QxCc9ZcU pHFHqyKj8OOSrULiNVArxN94E0ijDiFKZOkB9mEgci7iP3kQDk8Auy3kBxfF+CbsgMNGtA3a AHtEaOgJ72aWiIXz0p4cDsciFhqb8rajr4gIEQaz6QuODsrGZIT9Zs9Z8vqb2nnK3GD3WFge VtmpdrdIm01RskIw7MB+lIWQgdAmyPnH2uO8Nw4RfEEOhURQSJTMYK118kxyO/0IlwnfsISc e+ENWpJB/zyrCfTTGkVNqg8crF/nAmLpfMxJvP4JodUBeXm1FHZ9yWIB8MBm48wJIssJG04f vv9FoESh0iUcdsxOWhtl+MlYtUHWoiaqFxfifRnF1ZVL2Q0gzIK815mE/OgSilLneyegDtuj IrvoKcJjcvCwcA3FOn4FwLCB+UVOOH3JS9IZc4Bg/5pWHDPNnsp1O37tU7hHuyGklnNKA0dG 7M0sYD37M2z1AM9nEOpnAUMmqFtZE0onYo7W8WEp7HNRWB8m3p0L4Em2fyXz9dhOCb1xLcxD Bx2DckLbac72skaIqIHbYIsIAXYRpQskoE06r4vaZbI+3BD7eSgyPtmQ5SP8YCOMJJTN+Cki 4i1PnZHuY54l6RqiAd8eH1yYL9ZuyEBIFRQNdjvynvMRjaASpdkt9yjJIwkgmTmbYxmKddhe oE0AfSGws8kxI7jQlh80gnfjnZ0uBCJZgWMWlNc8zkcWTksyJUa8CnnggldbB1vJVMvFvH3C J4spINwqmUSBZbFRt0MbD1AqAmsUmL/6JN9DbVWi940SKSBkmrK38rDueE+qDq/bEY+HR2oO nWth+aiT7mm4FZ1tYVP2+m0Hqb7fHAgzE93gO4h9Bks+oKTQEiD1tbWiL7IRZ6Ng/5sIwpjk rEkg5kntJP0IKHOZZhJf5xAxyxf7JItX9RMijlwu27lPVVnu4omEhPdLC8rXVAvlqXPPymyP FVZVEkMgHEkNIlJT0xyZHD7ReUUA568Zr5VViP38mZNYSHvb8Y16wkKEX2S4Xiwpi2rhL/iN RJdJSBReuSmEsX2m5aIhQ7p0DC54fOBlMD/zoD8cgYcDOXSMoSig8EJKPpxYUOGrTChKwft4 CcAJw/lGmaUIlBSWv8SJlRR2vYcmCyE1lPcjkowr01xZoupVuUA0LsmHcHoJ/lKKACWdDSAV qbeqVp4XNZwO1Rk1UrONtFyhOegJE6GgnxxPnU4JCCP76Xm0FhRFbUI5CW+cNSUQrt2xD4jy AVF/L3I+NSGxa0AaaW2W+QBH9AxnzYV5Se3rjrMUMg0ePB18nVt2Yr9RDG6F9crZbOmLmv4g wJ3QoGjIcT9ohByB1Bzyltx74tlaXilsaB9H/E+dllLWEZI71M7PGPD7Wgw/vZYiBdf8NNgE 1eVlG2PhjBYIhCADHkiQShpntZrDYqKclN8R3HTUVHsSt6iYMSNOElfkIMclY0JRJSPKBp/Q w87CGEnjaAXn4eEaon6hRK4is4htUk6YsBGbbI9KZFwZb7ZaUOwLO2DD2nFSXEFJ3M7iVN6u q/BCKxhwwp+sI8ngdfZGnKeK15GcJnWtgIOQtBNx2OHGAFVDmhDxaaW+5R2TFjKDFKTS3NRX JFEUpODxM1KPr1R+Vw1AGoATLnUhD0prDiRSXcEHnMDKzkr7nJQLhAlWA7xkXimQ+7rbFK/2 ot4Eccvl/ir4URUWRyqCUFF5kZGtq7QU7atohSaHJTVSABWYX6kp4LkLg8NaccLRrMWJEbb2 1ZaSRPuinFScqCKSHRR5lHxRnXiO3NnOQy7mDsIF3vgwp6wklY7Smvxf8vxMwvKUNWGSvZBo DpHqdnaBGftN/vAbgOWMfk7MS5HV1EVYUubsqqJEWqbevtmkwOXGM81K7xUj/tSbsoJTgnMk CP74bYS/u43dHXAWKuHWI6X3ZxTBitl/qEzjS+44xnldsQ8i9HYgQnc7E2+C75iL94YB1zG8 Bf9A1Ti1MamQQAwx1OrPEbY3BGugzeFU6LPMciwspX7NgXINSwHYekvxPuG+G2OtJn/pqR/w hhwVKL4BHDUStbfER62nOAe5Yp2UKcyh9uWmpgZJIUmQ2wXk2IvQ2/7ukmBgDNR75iXJUiEI yWXw2xXX9nRvW5uU3CRqMhLGUuwltj3F8Qq2cmqnSbE716YiIyhtsfnUgsKjLT1AV+nFytvj QC0nICR2BR/F8d0zap0Go0SN0X/tKI6fgm7m/3UU82OKluYkB/EeUeLLgFZjN5+TIoSdNtiR fROW4apckoGdXPycxzvaRpZSw5LrkzkhV3KhSPv2qie+JMFRkQgEFmNc9ufWzFtuAG0SFJDy e8imlJKRmdQzHzpmcgiEcRjitHp0y8bTSKlN2OHmpBzLOgRXeogbgloRbmd2kCo3Z28424gZ l2JfcAayPIULrC+L+lbQHmf4HKvUlGilTb6DzDCrneQ0iXPFPPWlNhgEjR8s7DLNUynoUpam L4iHLtONdLgXHPZ8gCP+Uq3AMUCicnyWJTG+aDaFjX6EAryQ6AkIAi5tLB+99fC3t7el2Hi4 zUghRUt93FHkHmUoHwUYHL93Svm/1CKVNOQ048yl26HjOmvMYp38h3HCGtrNaPZUNklMf4FK 20wgjCMHf6abBNqCX5G8121dBZzHpStyyG0ZUJIF0dY5AxzmOqwFNCxgP1GD5XJ2W4SMBJZ7 qCJagPBYZA/UJtIKHGs9WITY5nNeXidGGFEn2htnteByuOJg/5ohjA+fzZzuUNhTRI/RGb0y NXxRc3bgIogb6UnLe1JjhDB1/byKvH6qTXytoq43yLiiwZeIyk4NKhKItCmM+e8GWZBGSXVJ CkBIILlgL5A3hje2DaVEbUmX7dcN1Ys5/VI84D19hGmorUpVK+jHBjtgOPTK6LE4ysDx9dmv Uk9LFJLbVElNIaLSWEchJqUDbfVfDzDW7QTD9HIm4M39qOB0pRLGAvGtfz5mCh4BzkUVx9AB 9DMVadkMCQXW2JL4tCgzYiftWUA+SW02/G9ZZ+JssjRB+qng8Cc5Qp8fxhkrqeem2knhXEpV T98tFy3SaRD2wkEGBKRZ4amX+ky1AqkNt/vKWi0k537kgKjEVLndfovMCFHWnPikrpQ24Sqd pZU0BrLkNcwUaKq5vyUhhMBTUK+cBnWEJ+K9hcp3WgWnWr48XtE/k2oRdT3nQX+Eg0RLx62z rhjxUtOc65l+JOr/0loUnsMGJDd4aLe/XAztVQt+Ppf2TZWurQKZb2UIf7bt1sDFjj2pKVCm 7a3TOzpYsza29SuZZRGrbhcqo7EDzxnMnR1Uxf11e6Qp6+c71GWlCBtaF13WpfTKWjMxmsI1 Ffw3JuSr6nTVJbCOQxwrbq+dS6G+sSudohE8hfQY/z+n82osUntZkZ+WrewldL+cm+FSwj/X Z2CzoRdBEaKszH/qxTOXCQXMRBmutMBpnmlJAcn6p5Z6sL5jQRUgcyrd73Wqs5HaP4f91tad 9RjEeJVkAM3iZJUgLTrVKR3amfAFnMjIBUm3Xzny4Wc+mNOYIqym0gQhrLFjMj3p9olxcyih 4iqtHGLn8ZdlHETHtfj9uINQKIR3NF0ETXPpus5gt1a6VNIyQXx5VhTaBIRmiJILr82gocWh cqk/ek/hwd5RMlz3SnrEFHUYYX+IKgmHHEZ8ijoT1CejrqYstsgutm950iEy9ghL+GXIJQpO LnhYqAjtPW3rLBAw5jQ+wh2C8BPSUIYe2IrsUrwRJyQ6tkpKAb68jGcQFMFtqW7FUZAfm1k2 CLjqkkJaqDDxWX9jBx7vRc2mvTIX/rmyGYFvSahpBDAXI7WMCDU4Mw2yznmdJXDBaTmv1479 ubi9WZI1zt3G9KN5WtDhmqfv4finojbIzgCujoDmRvv58cLSyR22qnmbumTHdqCchyOqNYTz T+IG4vkY1wx8UFsBervVuhyXAv2ModYBpQSRVlvtQgEPUN1cHr1oL79KNBmiLUY8+jajH/eh rT+XStNPkjZ5euuwJVfohRIu3iZLIO8iMGAjkyPeFjZc/yexGXPH52kLGiAPg0PdzjPNnMDQ xRPpQiGjf6WpgpL7oDSYuMcUFY698rM/02yGhynV1Re5VNYd+1Meu5lHGR9NJMpbF1qmrTeh 88wjX98vilyOYYHQtOD5WJ4MM27F2kPIUSBAq+oQ2PUcNg5K2ZThmDDI4Z2jRkpx0KsiVQQ5 3bGiWGl5ko+YpYWol8DTWK+aZc4gC/ui9jCz+7FM4q6rDpQ1Ofv427lv7e1WPb7XCd4dT5a6 aLKD+xV+yJXTqpKcmaa4pDaNLcy2TVctzvfFfUewZW/midwlZ26uxcl++iDePlkspIZB+oCD f7b0/GbFLf3WLqO5HIQ96QSS2hXONrvpyXxpUrXfbd14kAJRzkBhXRCRRhjiTWqnS9gFxcxc +mLzROJv5KaRGhQwaWrLOHH2EZewfKior15qA3RWLLZHqta/nvO0ztExexKXnwwp7UvKbWQ5 eprTfpGrJ47HCnj0/vC4vQAFgr1kXvgbW5zQ/mIibEyspIABKTl+8O82ackz+b505ciU9RW5 BkI8AqfSRAVeWFjoWibuX0ajeJEwAiqtFaikjnAyIld6dGZUwqV6Jp0lTrvGzslh+ifyej2z ZTPkGjJsLhAtOe/feXgvBREfGk0BajQ+Yb9Og2WlJ3HSa7JAjut+fqQp1Ecl2jYID1Ntvkfp 2SpKP8rQWssfdDNceMMl7gN6sbf/pocictgeksJui24bZmwKnx74dyi7PczPwbsnfsrqh3OP Nv0obWQtDCn25mN4gk9cc2uY1mkHsWXTO0BctI771WRyth08OCjQFQEC/U1CrlAyhIjQFI2d 358dwM6Cx+z3gq+qFGtLNue4tGubEqYLM9x6HYWCHIufCyIwRKj/ouGGJuGfiyQTc2dbLF+8 Bgp2gBuqZTQZBJpqAn/k7zS1rgkpqWJdhNyfLjvJxMUCPkcjTHjnWTxMto3veI3uzef+eNwf TZ9UE96dm8vBVf9xMjDTjwPzML7/MO7fmeHEj/dem5vxYGDub8zVx/74w6BHz40H9ESLGg37 RhTw2D3/PPhjOhhNzcNgfDecTkHu8sn0Hx5AvX95OzC3/c8Q6uCPq8HD1Hz+OBh1O/e0wOch OJpM+/TGcGQ+j4fT4egDU6SR4vHww8ep+Xh/ez0Y89zx91ieXzQP/fF0OJh0O+Dk0/C6va+T /gScn5jPw+nH+8dp4J/21x89mX8NR9c9MxgypcEfD+PBBCIAT2MzvAPTA3w7HF3dPl7zUPMl SIzup5AVNgdOp/csHv+sJw92sEC3czcYQ4ijaf9yeDvEojQGfTOcjrAID0v3hfmrx9s+9vE4 frifDKgiRGIEFUh9PJz8y/SxOZXu74/9QAkiBpG7/uiKj2vnOGnH5un+kSIKtn57TQ+wkPgJ EtbAXA9uBlfT4SecMh7FQpPHu4EKfTJlId3emtHgChz3x09mMhh/Gl6RKLqd8eChP8Qh0Mz3 eExk7kfe37w/p0OEvgw+kTI8jm5py+PB74/Y1AGVICr9D9A7Eml0/t3O5yEYoJPa1YIev4Mv Gi14gkLdm7v+k8yaP6meEKthGr2tHtCORlH7l/ckiEtwNGTGwApJhU7qun/X/zCYYNtBG3hx HZHvmcnD4GpI/8D3UEKc+a2IBib1+yOdJj5QKqaPY+XdkUrq0ZFFktaNvLJg9V0rPW0W39FE VpDb+wnpHZaZ9g0zjb8vB/T4eDCCzNi2+ldXj2PYGT1Bb4CfySMsbzjik+l2aM9s3MPxtbcu Fra56Q9vH8d72oal7yFGoslaF04lqNvkrMeqYIY3WOzqo56haRnxk/mI87gc4LH+9achuSJZ CGTA51Dlcq8kVJjq7vg+LjbJrxy4nCBXG/obGiFKv/5GlWIKEn3ObKWWO2WsgA+fyCOPAI40 FjrRao2gC8TgrNggkCt+asZBo4t+OmOoQfWZ77vQ1ArSGKnD1S5EKUkRNYOnlIMKFFwCX1GO IiBJ5vg5UNGFwHbAkFgZLirRIFWrhhrdkA3ta1+ibO4G+vpvVSXa9WrAVJhPLuLWLeEdTqdc suTtEdfh9bV/mscTuclF32iDh1qU4RKtXLrRmUegiRe71b4ZoL9TaNeMUPPAEdFiIm7FFRoG g34OQTKAk4AdTpAN5FoUM5uCkygeG+I5RN5rLc0Ovu5JEACSCoOcfyexMgU/zRBJ4Q0QHjXJ hPgMycvSAB8kMv2UsDrwzPs/hNju/fPtFgswBQIIjJH+4RfmDDe6OtU694tw37N12gKbm/tx OgVaHR5bPXQVu5k5dy202cwaHkdWzZURuX3vV7lt2nFC5rQ9/H22j7zPj0khbg1rMreiEaRK pe1xGowMx9rTkRbkRB4HkIvyWOAiXDfRniVXkjOeePSTqQTSicZuRIeM/0JAn1grqXq4WXUk HeQj4zvOlKy5sH8q5sda3kx6tIZZjpP24xtRT7WR6AXlxtD8b4FnIbD7KxF65udffjJ3CZLJ Po2uXyVrqP/i2fpfe/Djr/wbD+TqDU1VUY0hnluhspy4Yh5zkIumBKwtDdWVRY49yF1IZApw f2nmC6qtCZLWbG3Pu0l/bSYh4ZVhJDlLv1gtlvPMJh5kD+XkukhrTBcWZMPI14ccePxFUgGv 3z9jhwcMum3O+6/PkXzoRdr+5eT+Fsjk9ilG2BesDaoIptpCu//Nt3hf35xHRrHrEppAxHHB ZrQQiXfHQwgJvTcW6lA+i7uIF5y/iVk59/M0q+2G0kPurDXj655HZiO8r7rrbyG3L8+00s+j F+7ul9zE0bZLsyD3rh3VTrdcI6E+H7ekkdxxhSK65nWQOb20Jc0A9gA09bUuQPTtHDx84drI 2uY1xGbX7u1b8umciLs6lb5y+J0I4Y6M7pgnCemCNj9Evyuk2OLFU/9bAcJEtb6/tuWZkSvu UBpHFYBMuiq5jOdTt5tuDza1vuaa0UlzEcejkhR+K6dfJODkzupHnbpPaKxjkyGC8JgXv0Qq 62+SPBXbYrHNrTdzipKzbVhLZpcaHthiCLmoM9746o8x/460/g315HjEEfbp5H6zMzpAQwM6 7izU6LDaP4kh8zGZf7GlusK/y3wL3YqHwky3ML0i/0fPvAOSK9OMf5kLoxn5pke/5cSl/lLb p3RuQ9n4iA8OBRvtVTWFElKm+Ky5RMJ1EX8pOPxqhtDdK2MXlVCXuCyoU05OiH8RR6j2yE00 GnbnO6oUBSR6cedTeAEA4RG0eMmoeu/CuAz13pi8L0iJp3j1A67+tvsCcM9fEjrw20EAvA/+ epADRdP/BVBLAwQUAAIACABMEHQp80aazsALAAAeGQAACgAAAFJFQURNRS50eHSdWV1zG7cV fecM/wOaTEdURlrZaupmlJlOFUu2NWPFrigncV9UcBckEe0CmwVWFPPQ395zLrBLWnYeWnss kbv4uLj33HPPhV8dv3z/QbWd/9WU8Ug5/1Co53+La3X67NkzdTaddKY2OhjllyqujQqm9K5S rS7v9cqoP00ni95VtanUYqs26+3KmH8sj8u2L3y3mk7497yOa9+v1qrZKmc2auO7e6WjujZR q/k2RNOEk2vjou/U6063a1uG6cQGFfW9dSvVGBrzZ1qAFaJtzJGyaq0fjFpap+t6qxrtYE2l op9OfB/bPsJYrNC3lY60TWws1A9moztOj6qxq3VUIdq6VjhS1NZhU6fLvtOlNUFVJrQ24uB9 JwOs630flFkufRdDoa72xmLR6cT5qHSAhx5MZ/jJutI3bW2icSaEI5XdcHZ8Qrfc0sDBj9kC rFRVNlrPT3Bz4yu7tKWWJ9PJsvONurblWpta3VjT4iiXnb1Xb7QLxsmUj9o59bq3lXcFt5H3 a1hTrk15Tx8hii2OoBe2tnE7BHawBJ4y3XRy7StTB9uovxZ/+eUSftJdNJ3ssPfq23K3x6bz 8BYQ8xXPRhds5GfwCCBMdis4Knq1MAhXZfiR+968e396F02IC+PKdfGwrmqEFcHiws8LhaWw NAPx0jeIcxUAIlPhIFrB/lgPi59xglLK19VZnjGrAYYj9dU3qtyWGPi1OlNfHX4vw4DEJ8NC 7AC3g5kMr3fjOUGmXAEvBmCV2C53fpDjaHW7bU2pQ1SVx1rVXe1Xtrx7QF75Dqv7tEY+PE5l HtvaloBiHCZGn42Qw58Watm7krFXKxPv1uZRqz7Aiw+6s3pR49MGybIm/JC5XSO5gLMgprJZ KH2LJEFetT2GDKsFNVN6SEpYspUFKlPW+A2/Bpm8MEy+sJZnh4Wa+8H40RjtlG0+WbrYD8Jn 1s+Kotg5/8nUJ6Omk6sDZLiOUQO5CbYp0JXgA+nkMQMQUxsLvmKq4THO3Nk28tDTyc/WVX4D csmRSlieZyzPiLrOt6fFQsdDpaYTonvu4QW7P+fbcm9o7+wjnQHn1VWiMtkeXmfa/GS6wLP4 PXgALRtT198fYw8l6YH0yknMxETKC5o3nqm37Gt1Pv+gZvOr64uTuY7gGFKYddGsYPV5VZ3M +4X64Gw8nE7iGkxaIhBIqwA8RQxUp8xXphvMeKFWmC8fK9PGNRgMDoWD35gEJqbRotOdMAHI vgET81uaJutLARD23zr8Cjax0xMmAfUmKoGPYqHOl3RyZ3RFHJHs6C1SN6jZ3eN3SE7sTErD gQ2mEy6AhBGa1hHhD2n3uEWAufNvvd7nrqvzi4u860vfk6pX8lyOgLCC4vmVpWPgfeQxTr6Q HYIvYV5ElYjccm3qVtziJSPvjWk5fTpBRbArp4L93fBcwTsmYaEuH8C9IASd3I78N8EdZNvT zroDVhHFF8fZJonFEcsgy+vevtjRVgiBXW4T5uEbVIBaoZLpVjOAEpOmp8VgEcscYJ2u+hI7 INkFB8UAM4O5+9w8TxUcuHJDoo2JxQ0Jx05JqSl1122PA0BRiivSd5S1TlCitIT4Cvm4QiZX UnvV2m84tkr0ThRLwFeSJxwg83UYgoQs0VtYgkn+HsUe8SKt0bFYWtfAQcqQ2jaWPvzumGEL fUvsqeNjvj7Bv/Ik9Av+W4AMN0gNfQ/gPM/cP8uJcHgkcQ5jYqHG4i3mB85dHkp5SYDbrH0N e1rbmto6jDpNiwUwgEo1jqkgJu4QsVWp7D8qsgYMJbhhEcqIjSM4pBwraoWtuCeZdXX95h2w cAAZ0S9R+S3cjL3eLbFm3wWyHpEoCdLqEHJmcCMMm/1w+/OZ+kk7iBqtfnpz8XZUSJ1JNGpj SI4M8FwyiAJGOAws8m/flvTHwgO6B8p0HWvXBoCjpRl5BmqDfqfBc6xV2+kkCSlmeOCe5jAj K66R3lKTaOf1h1+w2YxKKRXxw5FIGt+Z0XH87R3OjkyZxSQm+AO4ggTYAuGmtMA1qiaC8b3S Zek74RmMoIQwhXlMzqIUS+pso56fvvhub+0j2ZzskHikkTqIHHaV7qpMgLOrAwyANDNdJN2C 8gY4dGYF2oBbaozsdicmu8ksSD+19b1qgfDk4qRKGT1W5Qx0MQNJWcIoYlJ5l3Zq+jpaJDOF 1wrysMjVYzp553DSNtmt46iHU6KI4hJ/zrOfbrKlQi8iz++wH9I26S0Qw/zm7sPN2yOF31c3 /7z74Xx+OX6ZX/0rfbm9OX+/eyXfxnfzj/OX52/fptey3vAkDfGMBYFGvQ1f4jiApW5bo8FY PksHOlBO0hn0DwByyKzEkk9FDbgulwiqY2ItKtuJvAKEqRTh2wrn7LsFWV/YXXyBLbDXKDJN jnx2GtEouobSIbaZX7OeSKJAEnkoIwwftnsLwSwBQFXJRArFYRIxgyA1pIGsJKTaocRE2Aqe DFmvARvAR4sT4JS7JgYrXbl05p7DkX550cows4Ca0q+TC2jb2jcQQslTTjdMArRzKAU9YU+Y fWZANvY//+cfzn31ad/oS/DP6Ys/7huXtgvxf2gb39gjQUNUGx1GFpMKDggPi+u8blpMZG9m vZqIwGxAQvoyNbRiKP3Ux2kIzIDyhgyijwUMv9LRqdup0KkdSv8h2FWp/MOlAkUBMuovEpYv Q53KHrYRaerB53lpWkUXOFOiDaRs4Tih/wFSgwamqrESn6cJvjEHGTRND1HRGo/TCN8y4Ikw cNYA7TB2dCk4AhIcDyIRZQfMia+oJdOJVDfIim3IRxsqssS2UK8Gp7Pi4ER1qmTcRchecwcI oAZdUt7vwVZZnsO1Y3ItDPTRIB1/F4RPJ+dZ+RwlThyQAU24STUNzXVK84hSHUYv5lNJcKXy gpgfjPRkyHhNbUrMp9wZNVuKmSQ9U9vhBLGPon5bxHpw2ar2C10P6ObwVy+fpWoztOGy8RD8 PuRLh3TRsPMekxkaVT08K05zts3JRJUB8dWBCXK8i34yjj2YZf+HuoplpRGX96/fvy04Xlo1 8ap4NDNUJXai0ehr0TNSZ4ayrJKQm2+bdu1ROC8vzgv1o98T8uxAZDl0WqZpI2WcIjMNW2Zw jIX6E28ks1MrGcUTbBwlGGUpAoufWw/ci1ROI4/4kIURmOQM2+gVmE3qNdvC3IRIV9hBeCDO QuQydu/axbrPPC4XBmHPp2KRZpx8Gj1Db3r4eZQSV6eWJJ+CkiHfIOUY3o7RSpAH3+bIjc08 RdGoDHE6D930YM1m6Iy/3vujrjUr2j5Ezz4ZwDnfSFOUC/V+QDiBes7US7nRSuUhpHxVMitJ DR3yu+pLHlMzHv9QGvNEmAOlSSSSLiVKRJGYjhcWdJWNnGEeAdlApky2ysqfiouUzfKEiGBQ 8wWPbDiYnRqunIgNHfNJFnI02hREHjoGe9oSVbxJKkK0OgSgtGZJCAj0scvJQCzXH+a3wtdG khZlR7R32oSjk1eHMD0J1O2gHf4wQE/vsM5GYZ4e8qjDLR93GG+v2Nh3UAFx0NdsmemOdHMk p5AJ8MNSWhOdYouFIFVLsysn3HFhwBAWBF/sbEsrhSI+RtpFMZMfqVEfLPyD2V28fSOjBHgL zUnX8+OLd3NkEltaQd6+ShJqpZFd7/Zap/3jW4HWAANWCd7QqMxUXzAWPUM2ON/oZmiMa46R eppUNpTFF+M0Tr0j1ZEuh1hpNTxhI09q2mgnAIdz0/XElhfBfuN2qySqpeAohqTbD6YlscYc VvclkAxhzfc3JbSHb1gheS/AGjO45fL84vpyCB/LZQIF37189/7j1Y+v80vqnHa8F0HhkABv pd4jf3zNVl4kIosv4pCJ7Zxt7IZSQCpT9kHqKVA2futht6XKGN8haXlptejRuWpeMGDRVN32 BoEVkayGIN2phdwIEbdZU+zPcGti+kRuvrcn6WJiVyVxiuO/J+PzpTkETs/qkCUO/9MgjU8S PN1lMi5eusTexYEEnXmMu4o7XF6m/1foHeTnx9f/BVBLAwQUAAIACABUjGsps8MEzkQUAABw TAAAGAAAAEV4ZWN1dGlvblVuaXRzL2lhZGQudmhkbO1cW2/bSJZ+VgP9HyqDASx1aFskZcUr TwajKI5jbBIbtoNePzkUVZKqQ5FakrJb8+v3XKp4E2lJTtBYYLfRSSTynLqc63fqosNDobzJ 5OhxPgnE4aH4cDi6/ir6vcOxSsVwMjm+XY3T2PNT8TVU6a+/AMkoWq5jNZunoj3qCKfb7YrP yp97MhA3Si6l+MeCv/4rSVeTo1WoDudeGEaPMj6ayH9iG9TO3VwlYhlHs9hbCPg4jaUUSTRN n7xYnol1tBK+F4pYTlSSxmq8SqWAQXnh5DiKxSKaqOmaGoKHq3AiY5HOpUhlvEhENKUvF1++ igsZytgLxPVqHChffFK+DBMpPOgbnyRzORFjbghZPuAobvUoxIcIWvZSFYVnQip4HwuYRgLf hWM60S1aIoqplbaX4uBjES2RsQMjXovAS3Peo0YZ5FOdCBVS8/MIRJrOoVGY55MKAjGWYpXI 6SqwqA2gFr9f3n28+nonhl/uxe/Dm5vhl7v7M6BO5xG8lY+S21KLZaCgaZhb7IXpGqZATXw+ vxl9BJ7hu8tPl3f3MBPx4fLuy/ntrfhwdSOG4np4c3c5+vppeCOuv95cX92eHwlxK3Fgklp4 RtJT0hYIcyJTTwVJPvt7UHECIwwmYu49SlC1L9UjjM8TPhjZdi1SK14QhTOaK1Dn4jwTairC KLXEU6zAdNJoU7/En+vYEpehf2SJ/psT8dlLEjF8BLWOvMU4VpMZfPw8FF3Hdv/DEl9vhzAP 4v/75WSQO5H1KOwj+4T84ti2j+2u6LoDpwv/C+0X4vzPpfg7cgdqHHvxWlyen5+f/foLaJU+ HiXp5CGIZsp/sO1+78gLgjMkl2GqQGmX4JdgLL/+0pqhVEAcbfjc+v3y/d1HMRChl65QVIO3 4MctGOAkQjkI6DucyVdA2oHWWssoTpkRSMDGwCDQ5parFFtuDaElsEAcyYqH8ij9NIrb1M2h Da0+hSDTbgc7akfoG4l4+09x0D2g9lvvfrgFGFhiwg/4uxQy9MaBxFcQlqrNYyvAmnGSGFJ5 PA0ijhclfvCn5/lvLz+/Z64EbMufSxLL1+4pKN/uw1+us6WFUwqiqbcU4IRGrvenoBl8sItg zphjvicH9B3L2Srw4lLPe3e8R7/aqiTYEJrnmfaN/wyBQARqoVLysGRgnL9lD8QXsEoIY8Ea onYCIS+LDC1noKWXa+Epir8nFOzA1ZJjMIwpRswkiJ4gsrYd4a/9QCYd4od4GSLdMfzxkRb/ jEXbZqoORC9uP28rkRISRxoR/5hiZZQkCuyFY0tfzMCaEgtyDXSTiCeKwgKM6/tqCVoGwjy0 tdwBxHYJQe8JEk0YiWTp+RKMPBZgk/DCgmgYeDBxtZAdjE0q9IPVROrRQ356nGGqg4wwhXmG kBZWPknwqAUNrzkTQKgbQ8drEUqMmiFxw5QUUkIIYO0LdHWY8XtoCoYUptj4MTUcY+xTED5R xAmxP0XhQUrS1hnPIqF/gwGEPkjgwIRskFGymk6Vr6jJcP3krXMB9AaCRE66m1DPmOKjhYYY Cy9ceQGM6vLzxyuKzPyEmPMeOGhNxKCT5RuUIE1PmhTpYx9jCZaQ939CChBLtZSBCjG3zCC3 gqWAzSwUKDacYediGQA2gQ4wPUh0mOk000Ei/QhUkKTeDBQyRW40VGC1YLTfGY4A1dLDQAOG wfDE8IdiFqx4yNREQgqlGZjBpNFMooxNLrnCOIwdiM+okNxbMN5RcLEEhi76OEDr5dCNAmmg s6t0bM6rMFEznLiOk/iiDekXhDXrFJuyy12CUuu7tMtdluie6ZKicyebpw/IZH08juI4ekJV eQFYFfzzCMgBXUxErHKtmoKBi/b9HEMQez8kDOmFyB+YYRgrZyvMLU4g0EtWS2xETgbGhyyU mk9/g9PDdCw2aNQhBoxiCCmHGWphDn6vUkCiEP8Ko0yMzU5VnKS5eZKBnHGLZgQ6MEGUSYil OFkNjYoWamyIQmbFfCBtGbOA5JV9hBSm1cpTQfkU6e1Geru/jcEuM7jOHgxoQLoGyRgMQPCj xViFnE1IdSp89AI1yW0I0oocgGurMMV8BJ6NgZqwoQwhVqAlJJDQFxKRcbx+wkB9hs5MOYBN KMLoQ0YSgZ68JYTaZazQzaMwEzVIeZWw00IYzcWNkYdQGoUENGOxWAWpOgygw0CQkVPmOPTm 0pscQ/CPYTghGZOMOQ6jy5AufW/pjcExUwUZBmIWGBFbj2kt8FdYXySil5lPAigZHqwwzm30 d1a0HY5JKp5wc2x8IFbs+pABE+JCPUDUALkXyONRYVpWWHnFMoH5cf5rceIj500imPo3gEAH xnqLzDAPj8Jgbva6ISoakgg0lMWQQnI1NSkGEOgGqxoe3ATLum8Idttt/HvYEa/Fu86BTro5 NMD5rxJ0/m9DICHid0hsH4DefY8NBqMIhPnEVDmtQuDiUCK9RMH4sQoBMQIkmFD25HSs5U6Y mthNPn2aQyEgEqrGpkp7N6kaKmZK9zpEYA7n1MGShcIBBJTwPD1uAYz4v1e6fCEbJ5vLjSK3 SkKAgLTb7aH4E+QLYmT5YL3XxtiNkxjhoDsdQ6E558hpw8ghq414WoC9JFRXXUGO+aS4HGPb JQv4RoQHSEmIpuBDLBltElk8JuPnEI41M7UrMGeAIdFawBiryVWY1ca6IJpIP/BYL8YzL41N 0NOyZz7No0Bna/CABDIxhtMohsCAxZheYCC0pxPX0sSEnq6QLOEc0icSE5Ny/QQBBZ0E/TRE dAf+pxMbKwQt2aK0pLliXItIVgvGIFQHexocwqhsVvwtusIYjM0XkucFKAYoxpJWGRbq38A+ XcUkMcW5IfViABdst5zdsDdwNCo5p4DmOIZCLy5aQD43eQTYiNYevGBqshHFXtYBh2BcR+Ci WzJnafa/61c8eehHxo8w+0c926WO3+MIS2xyR9THnOzazJ7rBMdi0aam+wTcJjUmsFCTCWgT F10mb/sEpSF2gD09MZIvZ1gc2W8Q+2Hg//4NQCVaixf7c5VCXbPCqEc4+8FGqeR1Nkx4CWEf 4vPwy3sHDRo9nrQGvdpYLDEEGVpio+w9E/cbdRQVWJicspapYip35G7pyBKjn9ZXb3tflnj/ c7r7r6ubv0aGf10/f5mqrm7+Sk19ubqzn+vuR3rBJRod2lcJrcGKMUR87adAwG/FCJdZGlYg jnvVRQvNdPEcE2DXeq7rF3Hdd3vNbA08I0C/zV2dNnBdhv4L+gIuANi7y3AMxWmI7KgIiIQD MQ4i/7tZVqvojItjW8g//QDQJiDINVIaPXR3H26mhRfwjOz9eS7sfQwrG92LuFZhReH40gga xVpYaDRpdKJfaZdbdU9DaIJcktxv4S1Fm9YjsfUOexUycDImxegnbUzkQidxStrDcsomVSIe zPp08BPTDAiNK3T1LuZXI1VafQYQg5TI9E4CelHRKh7oJ63rblt1xD8Acw7xQwY68cM7eHJm CC8aCDHx54TjoGiMmXDTDcm2ctniJB4fPCChtJNLDjuysBeAH7p9wEkLITZJAeW+I2qajyFm DDtgSFBDfFEgxvhHA6ev+M0IL1cb17t5KciWlSnEZYX4DxQCajRC1rddJxRE2r3f1GuXJA5z gi8sav782i59c3I15bxOM28NtV2krnnfpfdQ9vM79eCyXN2CXDW3lXdk5SO0RHFaHdOMs6me umaK08p40c+fnYF66BZJSlOo1zBV7Q1rAMZTA/VdZqv3o09DWnw1G3mFgjL31B5+ggLI3tUs qm7kBQpg94WqDWxuYZsGkMAFSy17motDN3O9UzPX25oZRbs0M7K3NHNRboZmYLerQ94kui4Q 1UYZM6CTSrwvBp5N96OYGJElqXZX+41q29knJ/vkmu4xOhLLBT7MnkGcwqqdKInnArmfeZ+3 foE97kSZj+0Cx1sY0oiG1M6+t1zcuaMx5M+yhus73nhf7c7KSR3dvF3H3sRka6Zu8WFXbzFm T8yscHWC40WvGC9QLBbLxOIRWqw9+CcyvOli2a2JNcx7wbxpQYJAb9eEuFJfF9xXijLL2Zwd h8jTBu4spOFuMSY3LCEK3BfMnWpyWzNBC9ns/KiLjKOorQO13uPEN7Z+wwGSes0H69bKpDQ8 N8+nkcPDcyrDszWhhf04RWH0atsvCa9XpD+plXmd1E4Kw3J5WG5lWI5un8lpcO7++X7pxamC 8KIXPrOofoKf4GFjut8p2UNtooEVQzEEVqM8tq0feptohygtJrMEt9B5Zh56K6ARuJwY4EJV SF2GotJqJ+Ri9wvIhVZtcR+BYodtErghh/84QNgFkGKXAI5dTvqlPpxSH7u1WteORg72BvbR 7yvYpwnj2mBmDvxxnwe7DYHFNqDHzrGTnWGn1N4MMEWLwPqizGAwIUG1Tac1oy1qbEtYqBlh 6ua91IUGHlbqFvvJwwMiOMZnzYogDFckKutiFy/mXZQtoK6I5w6LKE681uv+tKTJW8yOAHdK cnzX1/jO2dl7fgjg2T8H4Nk/B+A5LwB4zi4Az9kR4PX3BXiCtx9RU9Av4ZLIEtl2J+2L6fX+ dmEXtfN/FyBmIXwLUNyk2wYYM5atDf4/hPzfDSHd6ppXM46sx4XEVIMK61FnqifUqwGdJ80j Ksn8pMjU35R5kak6m/6u8PNEk+8PP/nER7YRC+k00YeOoQM65FI4W1LNRsh12pCPTrelo92W 7eqr51H3tH2q8zSkKofzugZkTg7t+F1RA6IWdDgaa2j6wlqg/0BLttVyJGdJLVzG32+Nr3Co EY8N4SEpEHdZuIlaTF4sW9xpTT0A4UqVjwKfit+EOtsFU5rM96aa+QobCrsxbNUmtoRZIuPs Ubg1uqg5EsxVzWmARvD6DzIDOqRgQjNEdqxxoIZhgo03UNY0vGnzUp5uGI0IHrT/6JQ6nr/E +nLO19lMTzNEunnyORMZ6BXkXVdZFdf+Wpkc+VurXpz6Zak3flbqE9fA+WBGoZ8+f4bnxjL/ yCzzTdkiMwykDwbA2D06hUS7+q80jc5eldKTVuOx/kQVYF1SEL/JXNW1eaThalUzORWmmmqD FWsWfg2jW2RcP5zW7QQ47YwUamOwQ2I2XDVOT+IoHnfZlKq/Pn3ArR20EVUwEdVsIYatm7ER IcejHcJR/lbobb5sU/bu6v0VCOz9e3F9eX3+6fLLubg5v7i8vTu/ER/Pb87Fq1eviJYZnZ32 B52G/cGRu9eOa7bl+tyGZiNTv7c/0+2u27QNdxiKe3wa7Tet+JyaFZ+mdZLdVnygkGVj0Gs/ hdCmlyugqFLHGQJ6WXauT6imG8v0Ucina55XxaHuNT0kUx75HsmUTi3uVXlDG8eE0fW1iGeK 8URX43RCFCvyTllRUJC7DUm6/3N3XJyfU5A7P6cgdxubebaM7u2NDeoLyDYeFq6pZk1F5zq7 lZIbdNtLSc2ytcFnS8ni+MuvG4vKraVTtdLB20m6kqCqarPCLNUurrNZf9SVmU6Vqaa6bKqm 8sKwWk05zRNwKsVnQzWox1+qveqqwV4DU3XuvS21V6oHVqoQ9yq99NF2TgD5KY+uSQD9H1ry 75slf50KNhMAL3difOZ84MJnu/+zEoJbmxDyPq2sw1J26NdsRfAMODv0e/tlh+z+n0kNMOqK rIHkAQTwYE5y5JPWEBagDp9CN6gGT+vijsAkVninVv4JqcJXaaBxbXYaqY+TBBMbPYc5ygCC 5dBwE7J4jgjP+2AHq9B1NnWSq6R8qkgmpXNFLIY3oj1Z0dVYfUyWL/+0djpthFR2v46KRwcK 1lSuU0eF8sE5ZNVHBSjraofvAkjPn+Ndg3Sej57yMK9FlCFTDXys1Cg5Gst65BegOqqWqMJz SmC6CuyJ03U2O3adZzvWN2EqHWPGc51sDwL6LlaXTqm6dErVZdVfn3PYoseSy26uiTj5mohT XROBiFi3ReuU1kT0LIo1Ue6rzZIsB70CkmqWpI6jNZLs97I6vW0AVKdU8mux6t1ELdbiDmIj 3bWhK3LZ+3FdO8V9SN1Gd7tKn9sFrOrWrlUuD8nKZ1vc/iskZLee7Tpny2Ze3A8sJOne1hau 8xYyERS3/cjcapab88ZygVCsJaXvYXiFNKGjDaR37ztEdrqTUoxGSScPPJw9Whnrht2eNpvt hmoZfd9WzocS1i5U8xldpfLlU1AYsyCl5lDJUFcyBCN4FF+xAsyoK8mKqEmoQH3ayVeJNs0R /vS2mWQNzEdvuTUnP80FJBSF+Q+/l3bgNeYuXli61Yja7OYQPSSfRnoN1Q0SJ3rXaaYHsRC9 W7JyuwbuAIuF47d0oq561qZjMAf9nkCe2avu1MSGGfSrgQIlxyHU2zS+fo8uWqLOMgaw5TpX K2sYeNv7+tdczeblhL7hR0jyEJUPGu/vR7U2CX9OXmiX9/lSb5s9cZtVttBqRgy6txgkk7pO Rtpsi0zaz8D7hhluRHkebZMNbhjFSIPsZwxwk4eG/qz1bQ6rz5VA1fT0ltoWy0tPMga8yldZ aPZSvvtY+qEB+rkX/LGBnJxvfFviRj4edY8cfUsvuwpu8Y01Q/0Nb3MfCH0bXRsx33tEzIyX +OyDJKdvh6sF/R7Lo4cX/w8hvT/NVSDze5k5LbSBF8TNz9KUOfHWnyGknwjCHy1YAQLW902B aRLpG3A5Jd4NlaEv8e4aLmSZe3MHfBO3IAX8NR5yBy8YiG96fof2gfD8FMTAS7Salq7Rf8Nf EMAL2nx1FYbzFEfh7Kiqkfs9djkKDESRnuwUWMrvze/XsG5Kdx6y9JxfzMzX8Gy636DZfqDY Dkz20mU3XlzgbGkuMfxoUb0Bt++1H3E/pRo6qL27QLsqNNIXbQ04+nddzNVI89suj2rAnpC8 7UGRCX/hReRgGc/e/m26SMXhG0ccLg8P/zYQywAMVyLf/wBQSwMEFAACAAgAmxJ0KZmZhceE BwAAABMAABgAAABFeGVjdXRpb25Vbml0cy9yb3AyLnZoZGy1WF1vIscSfV9p/0PJL4YbwB57 s5uYbBTsxQ6SDRaGu+u8oGamgZaH6Un3jAn59fdU93zhzSb3Sr4oys5A1anqqlMf7W73tT5v 33S7NJ3cn/WeN1FM/pmGf8gwz5ROaJ6ojFbaULaRdN29up87jSud7o1abzJqXbXp7PT0lB5F ktDNfPRpMqbWbrNfS/nLqhumeU+bdZu1nObzae/sgu5UuBEypqmSqSQjISIS9aeMnJ2tUAkb 7a5lIo3IJMVap079Owq1MTLMClH88JSnlIllLGHW6GRNOnUeT6bjdmny/IIeb2AnjUUIzfnd 4MvJD7RT2Ybw+DD6bUgX3Ur63QUFwUnw4YQP1mHNnUgyS5kGxM4oOMS2c46Nx5geW1o7R9XS CLOnXq9XHZkozOFzkkE7lsJKauJXYrONspQavTZiS3hcGSnJ6lW2E0b2aa9zCkUCjEjZzKhl DnNwQCTRCU671ZFa7R0QvsyTSPqcZdJsLemVe7kZz+nGxTSm+3wZq5BuVSgTuCRgm7+xG8Rn 6YFcztmLh8ILutZAFsyMPkmcHEaepbHMlLPSSIHYIW0cSktk7LxBXlixDY/3FCNYlW7vmzGo jxoROMHwG51y+AHqoh/HtEQqrFzlccdhQJo+j2a/TuYzGowf6fNgOh2MZ499lyuNX+Wz9Fhq m8YK0DibQYb3OIKDuBtOr36FzuBydDuaPeIkdD2ajYcPD3Q9mdKA7gfT2ehqfjuY0v18ej95 GPaIHqTjhUP4m0ivXLYQzEhmQsW2Pv0jUmzhYRzRRjxzXYRSPcM/Adan+3/OokMRMReB42XW CGef1IoSnXWoYLD+Or9Ov85xh0ZJ2OvQ+w/f052wlgbPSOuV2C6NitZ4vBvQ6Vlw/mOH5g+D 6hyv2pscI/Af+7pSxmYV4ZBFU7Qm/M7F6DygUVYGEcRAual4T3afACBTf7o+wQxh7koGTjRH CKHdywLgM5NrKzIw1CJTMJnpSOy9F553od6mKpaWqw9mOFu27EzxvoARJlHIxIV3MNSRs8ca hX9Guk6X5ugLe8ZcqkRk2ihRULnpJCom3DAef9dhJ7Y5XMMZI52gfrkTaFeRMSITex+uc8Nf Md06PoR5ErrGftA463htNfNNCoO68OVblF2qUhmrhC3DYwHuxejfBcskfVkKQ+E+jGWvSBvC rNa0glOINiIMO2hELTylYu3oVfJZpy42K6O3FDAv37+DbmZ9P4ZDJhapfWEGnZF20nXErXjC +SlBDdCRVesEdZGB1kdFDBDUON6jHyWI8nIP7vtQc/oQ3lRbqzgKTADn+NXk7nI0HhbHRwfK fcyQCJtxx0GgHQVimXHmjOxGcgXAyOtvRZLDBx9V35Okb9BoNr3XLZG3b25Hl9PB9JGUlLL/ 9g3GDapx6F57NosWsV6rcBEE79/1Bre3LyWSfCsNfodkD2Hq13g7bZ4a0vzau8YCsAh1slLr Auztm2GSKbTO4XzhdgdlWSfVJmt55U8qWQw67p9LQjWAP9eLfw+vZpNpn3+nYtJggKToaUlk vR7QFhVdvd4DjpP78zyj0rRpnYH9uwScOW33HdJ5TXHmkIe68vleDMafOtULGvkLUO8OlU6J KFIMhFQCk58O0SwWlm/5FRz4xWh5giEV0WB216NLR8INHH2yjpa9IlRcK+XngvitDFUzUkba PM5YpY0MSDSUIvguHwODPpHBDbQVEDzcBFxoh+kpqgR1nKHZLDxgp3qfTOtnxAyuNDJWOFH8 Xjhjew3YWIdQrPJw8RfxOX+ZN7/MQa+Ducj9IOocZhIGlnKtEj7iK8+YiW8xKXfXF13m4nWN ETmDAWJy0IDdXPHntod9uiSx67QHJWGxTIaZJ86LiP/00X9NdIQNMzii3QYbDz8fdVy0kdSG RHBaSwS1xLgWCRoiQQnyZTJtStRmghKkIRCw8UIgqPwYH0oEtUQJ8eVQpLYSVH5g0a8lak/d MLR9Z8ad14V+gMXh91yU/XwpOekpbgYYBVFjqKBYyTHW7fW8iVazvRpwjVnDWCoJ4xzEdRO6 VyV7hMXMZAdD1A9zoBaSr85oV+r/TwafubVGekOub6OqsZSAlCt39MPW0mAktVo8Pt1UaLtt qHq/LN6vF1jYb4b08ecXxG6dt9ttDwRrXwOV4+afgc4Ogao59T97FPw90H/v0SmA+gW5zhHd sr9Opn5nBIV5VrioL5vz44LNXz7Ohotib4Eyr8WKJ1Nxu+3W84jKS7X3um75rR/+pb77UMrh pY2suYpyH19VZRYP0/sXqicfXb9xn6NSS8aoqvrr/qELOOHr+tDU/LYLXKLH22KzQ0hRrLyV i6X21wT0COzZO1wAgOvvTgK7d5yprtsAmpdYuo9z6zdtvuEm4Z627s8k8o805iW3qhm+rxzj ciYNcoWFMSwW5wd/Lfsa312HsTynaDC8jcR8BVhiZGzRRxLcFK0Vprh63ErGxonCJ3Y6jflA TBrr/i6BKIBQ1R9XmtwpGfiOScSLczFm3MDJxFp6urlFBZmp2UO+6bYa2xXifxwcF9XhA99c Kg7l+Ztvy/sU+2UH//8PUEsDBAoAAAAAAOwSdCkAAAAAAAAAAAAAAAAPAAAARXhlY3V0aW9u VW5pdHMvUEsBAhQAFAACAAgAVQ10KRVziwxWCwAANCAAABEAAAAAAAAAAQAgALaBAAAAAGYt Y3B1X2NvbmZpZy52aGRsUEsBAhQAFAACAAgAQjNfKdBzjMF3AgAAOQQAABEAAAAAAAAAAQAg ALaBhQsAAGdhdGVfbGliL29yMi52aGRsUEsBAhQAFAACAAgAQjNfKRBmsyN+AgAASQQAABIA AAAAAAAAAQAgALaBKw4AAGdhdGVfbGliL2FuZDMudmhkbFBLAQIUABQAAgAIAEIzXymxTUzR gwIAAFIEAAASAAAAAAAAAAEAIAC2gdkQAABnYXRlX2xpYi9hbmQ0LnZoZGxQSwECFAAUAAIA CABCM18pT66XDXkCAABABAAAEgAAAAAAAAABACAAtoGMEwAAZ2F0ZV9saWIvYW5kMi52aGRs UEsBAhQAFAACAAgAQjNfKeodgVN9AgAAQQQAABEAAAAAAAAAAQAgALaBNRYAAGdhdGVfbGli L29yMy52aGRsUEsBAhQAFAACAAgAQjNfKepoYraCAgAASQQAABEAAAAAAAAAAQAgALaB4RgA AGdhdGVfbGliL29yNC52aGRsUEsBAhQAFAACAAgAQjNfKReSjf96AgAAQAQAABIAAAAAAAAA AQAgALaBkhsAAGdhdGVfbGliL3hvcjIudmhkbFBLAQIUABQAAgAIAEIzXymy1ZuobwIAADME AAASAAAAAAAAAAEAIAC2gTweAABnYXRlX2xpYi9ub3QxLnZoZGxQSwECFAAKAAAAAABrA3Qp AAAAAAAAAAAAAAAACQAAAAAAAAAAABAA/0HbIAAAZ2F0ZV9saWIvUEsBAhQAFAACAAgAUoxr KVM3SbLhCAAAAygAABgAAAAAAAAAAQAgALaBAiEAAHRlc3RiZW5jaGVzL2lhdGVzdDUudmhk bFBLAQIUABQAAgAIANQNdCm+cEMPWgsAAIMhAAAZAAAAAAAAAAEAIAC2gRkqAAB0ZXN0YmVu Y2hlcy90ZW1wbGF0ZS52aGRsUEsBAhQAFAACAAgAzA50KZkOsYOrCgAAiR8AAB8AAAAAAAAA AQAgALaBqjUAAHRlc3RiZW5jaGVzL3JvcDJfdGVzdGJlbmNoLnZoZGxQSwECFAAUAAIACABB EHQp+uTpJCgDAABWEQAAHwAAAAAAAAABACAAtoGSQAAAdGVzdGJlbmNoZXMvcm9wMnZlY3Rv cnMub3V0LnR4dFBLAQIUABQAAgAIAEEQdCl8737lDwEAADsCAAAbAAAAAAAAAAEAIAC2gfdD AAB0ZXN0YmVuY2hlcy9yb3AydmVjdG9ycy50eHRQSwECFAAUAAIACABaEHQpCd4xZZMAAADM AAAAIQAAAAAAAAABACAA/4E/RQAAdGVzdGJlbmNoZXMvbW9kZWxzaW1fdGVzdHJvcDIuYmF0 UEsBAhQAFAACAAgAWhB0KX3Vg1eRAAAAyAAAACIAAAAAAAAAAQAgALaBEUYAAHRlc3RiZW5j aGVzL21vZGVsc2ltX3Rlc3Ryb3AyLnVuaXhQSwECFAAKAAAAAADyEnQpAAAAAAAAAAAAAAAA DAAAAAAAAAAAABAA/0HiRgAAdGVzdGJlbmNoZXMvUEsBAhQAFAACAAgAaw50KRTBksJEAQAA 9QIAABQAAAAAAAAAAQAgAP+BDEcAAGNvbXBpbGVfbW9kZWxzaW0uYmF0UEsBAhQAFAACAAgA Zw50KW6WVwPUAAAAIAIAABIAAAAAAAAAAQAgAP+BgkgAAGNvbXBpbGVfc2ltaWxpLmJhdFBL AQIUABQAAgAIAGoPdCkfKXWi2gAAAEABAAAUAAAAAAAAAAEAIAD/gYZJAAB0ZXN0X3JvcDJf c2ltaWxpLmJhdFBLAQIUABQAAgAIAE4QdCmIROUxLhsAAJhHAAALAAAAAAAAAAEAIAC2gZJK AABDT1BZSU5HLnR4dFBLAQIUABQAAgAIAEwQdCnzRprOwAsAAB4ZAAAKAAAAAAAAAAEAIAC2 gellAABSRUFETUUudHh0UEsBAhQAFAACAAgAVIxrKbPDBM5EFAAAcEwAABgAAAAAAAAAAQAg ALaB0XEAAEV4ZWN1dGlvblVuaXRzL2lhZGQudmhkbFBLAQIUABQAAgAIAJsSdCmZmYXHhAcA AAATAAAYAAAAAAAAAAEAIAC2gUuGAABFeGVjdXRpb25Vbml0cy9yb3AyLnZoZGxQSwECFAAK AAAAAADsEnQpAAAAAAAAAAAAAAAADwAAAAAAAAAAABAA/0EFjgAARXhlY3V0aW9uVW5pdHMv UEsFBgAAAAAaABoAugYAADKOAAAAAA== --------------5DB0B489951A08941692C6C3-- From Ben Franchuk Sat Nov 18 14:08:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01076 for ; Mon, 20 Nov 2000 04:37:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:12 +0100 (MET) Received: (qmail 2792 invoked by uid 0); 20 Nov 2000 01:04:18 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx05) with SMTP; 20 Nov 2000 01:04:18 -0000 X-eGroups-Return: sentto-1101623-1564-974682253-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 20 Nov 2000 01:04:16 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 01:04:13 -0000 Received: (qmail 66308 invoked from network); 20 Nov 2000 01:04:13 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 20 Nov 2000 01:04:13 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 20 Nov 2000 01:04:03 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA15136 for ; Sun, 19 Nov 2000 17:55:17 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A167F4E.BCC3FDD1@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> <20001119164023.13141@thrai.stud.uni-hannover.de> <3A166CAB.72499EA8@jetnet.ab.ca> <20001120013054.53000@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 13:08:30 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b1227ea6cc288d387ed21e69397913fe Status: R X-Status: N Michael Riepe wrote:
>
> I didn't use gates with more than 4 inputs.  All I used were the
> components from my `dummy library', and all of them can be put into a
> single 4-input LUT-based FPGA cell, except the half and full adders
> (which need 2 outputs) and the n-bit register.  Everything else (the
> IAdd entity as well as other often-used structures like the building
> blocks of the carry look-ahead tree) is built from these basic gates.

The logic looks clean and well written. I just find VHDL very
confusing like C++ java and Wirth languages, simply because of the
wordiness of the languages, thus reading the logic is hard.

If VHDL was to simplify logic design why do we have to create
'+ -' operations by hand if we want Carry in,Carry out and Overflow
bits? Give me a schematic any day.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Michael Riepe Mon Nov 20 02:03:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01079 for ; Mon, 20 Nov 2000 04:37:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:12 +0100 (MET) Received: (qmail 9244 invoked by uid 0); 20 Nov 2000 01:04:31 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx01) with SMTP; 20 Nov 2000 01:04:31 -0000 X-eGroups-Return: sentto-1101623-1563-974682244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 20 Nov 2000 01:04:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 01:04:04 -0000 Received: (qmail 65906 invoked from network); 20 Nov 2000 01:04:04 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 Nov 2000 01:04:04 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta2 with SMTP; 20 Nov 2000 01:03:57 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA09964; Mon, 20 Nov 2000 02:03:54 +0100 Message-ID: <20001120020354.55583@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> <20001119164023.13141@thrai.stud.uni-hannover.de> <3A185EA7.153BE448@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A185EA7.153BE448@f-cpu.org>; from Yann Guidon on Mon, Nov 20, 2000 at 12:13:43AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 02:03:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: multipart/mixed; boundary="ulUmNC+osPPQO6H1" X-UIDL: f736357358184225573f390192f645ae Status: R X-Status: N --ulUmNC+osPPQO6H1 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, Nov 20, 2000 at 12:13:43AM +0100, Yann Guidon wrote:

[wider add/sub unit]
> no need to touch the core of what you have done (at least for *64 versions).
> i simply meant that a 128-bit SIMD adder would consist only of 64-bit SIMD adders.
> Since 128-bit and more require more stages, it's not worth caring now.

Ok... putting several 64-bit adders in a row isn't a problem.

> > If you need a generic adder *without* SIMD capabilities -- I have made
> > a fast carry-increment adder (3+2*<n> gates for up to 4**<n> bits) that
> > scales automagically (you only specify the width); I still have to figure
> > out how to add automatic pipelining, though (insert registers every <n>
> > gates or something like that).
>
> i'm interested, yes ;-)

I'll attach my working version.

[...]
> > No problem.  We need a `wrapper entity' anyway to include the F-CPU
> > specific stuff I left out (intentionally -- I prefer reusable components).
>
> cool, can you send it ASAP ?

Tomorrow...

> I need to modify some files, i want to rewrite ROP2 with the "style"
> of iadd, i have to cleanup Michael's library (remove unused items),
> reorganize, compile and test the whole damn thing...

Please don't remove items... I might want to use them later :)

> BTW, i remarked that the architecture names are not coherent.
> Can we try to synchronize ourselves ? it's not critical now,
> but might become a big headache in the future...

I changed almost everything to Behave_<n> and Struct_<n> (<n> >= 1) now.
I could live with other names (and I know how to use sed ;), but please
don't throw away the numbers -- sometimes I have several versions in
the same file...

> -- File F-CPU_config.vhdl
> -- (c) Yann GUIDON, oct. 21, 2000
> -- whygee@f-cpu.org / f-cpu@egroups.com
> --
> -- v0.2 : Michael Riepe changed F_RANGE
> -- v0.3 : YG specified the user-modifiable constants + GPL
> -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants.

No longer needed.  See the `ilog' function in ciadd2.vhdl...
I apologize for the inconvenience ;)  On the other hand, defining
things this way makes sure that the number of bytes in a word is a
power of two (which is IMHO a good thing).

BTW: you can include `ilog' into F-CPU_config.vhdl if you like.

[...]
> -- The URL registers must be modified to point to the manual, sources, patches etc.
> -- The registers are hardwired, 64 char max., format is ASCII and padded with 0s.
>   constant SR_URL          : natural := 16;
> -- ASCII values for http://www.f-cpu.de/design/ in little endian
> -- It's an ASCII dump so beware of the bit ordering !!!
>   constant SR_URL_VAL0     : std_ulogic_vector(63 downto 0) := x"77_2F_2F_3A_70_74_74_68";
>   constant SR_URL_VAL1     : std_ulogic_vector(63 downto 0) := x"75_70_63_2D_66_2E_77_77";
>   constant SR_URL_VAL2     : std_ulogic_vector(63 downto 0) := x"69_73_65_64_2F_65_64_2E";
>   constant SR_URL_VAL3     : std_ulogic_vector(63 downto 0) := x"00_00_00_00_00_2F_6E_67";
>   constant SR_URL_VAL4     : std_ulogic_vector(63 downto 0) := (others=>'0');
>   constant SR_URL_VAL5     : std_ulogic_vector(63 downto 0) := (others=>'0');
>   constant SR_URL_VAL6     : std_ulogic_vector(63 downto 0) := (others=>'0');
>   constant SR_URL_VAL7     : std_ulogic_vector(63 downto 0) := (others=>'0');

s/std_ulogic_vector(63 downto 0)/F_VECTOR/g

What about a function that converts strings to vectors directly?
Like this (beware! untested code!):

    function s2v (st : string) return std_ulogic_vector is
      variable out : std_ulogic_vector(8 * st'length) := (others => '0');
    begin
      for i in 0 to st'length-1 loop
          out(8*i+7 downto 8*i) :=
            to_unsigned(character'pos(st(i+st'low)), 8);
      end loop;
      return out;
    end s2v;

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--ulUmNC+osPPQO6H1 Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Description: generic carry-increment adder Content-Disposition: attachment; filename="generic-adder.tar.gz" H4sIAIdxGDoCA+0ca3PiRnK/wq/obF0VwgYbCWwnJt46TByWqn1QtvcSf/IKGMxkhcRJAtv/ /rpnRqMHAoPXTnJ3msruopmenn5Pq2eUEbdHns8OltOx8+aVmtloHLda8AYATPUvWOpf7LIa TQvgxGocWceNkyOLupoN6w003vwJbRGEtg/wZsZHU5utlwGCTSZv/udavQ6jhAkAPndt33+s 992Rz2bMDaEzHjMfuggCF47oKhOUN3/0+d00BKNbBavRaMBHKUK45GzO4Gcl0X8G4WJ8sHB5 fWq7rrdk/sGYvUMUhOV6ygOY+96db88Af058xiDwJuG97bM2PHoLGNku+GzMg9Dnw0XIgIdg u+NDz4eZN+aTR8KDfQuXyAynDELmzwLwJuKh9+kL9JjLfNuBwWLo8BF84CPmBgxsXJp6gikb w1DgoRm/Eg1Xigb41UPEdsg9tw2M47gPyEKAz2BFayiENfB8QmLYIVHugzeneVUk9xEcO4yn HqxhP+ZyDNwVuKceyjKcIkrk8Z47DgwZLAI2WTg1QoHA8Fv/+v3nL9fQ+XQDv3UuLzufrm/a CBxOPRxlSyZR8dnc4YgZ+fJtN3xE8gnDx4vL7nuc0jnvf+hf3yAT8Gv/+tPF1RX8+vkSOjDo XF73u18+dC5h8OVy8Pnq4gDgihFZjBBsEPFEaAnFOGahzZ0gYvwGFRsgdc4YpvaSoYJHjC+R NhtGaFhPK4+Q2I7n3gk2ETgWZBv4BFwvrMG9z9FeQm9VrTQ91mwN0NoPanB8cgQf7SCAzhKV 2bVnQ5+P7/Dnxw40LLP5Uw2+XHUOyjT7H/3xacp1akswD0zhCYemeWiegHl8etTA/0B5Alw8 zOEf5bLDh77tP0L/4uKiXUZdil8HQTi+dbw7Pro1zePWge047XIZvY2jprr9zq3wQB6US3ck ERSFUS6Vfuv/cv0eTsG1wwVJCRV7x8AkpltwegatcqnaLpfmnh8KeKRcTLfJkVzs6HGcjbZG qy/k8ks2Cj3fEKjrJoy9exfRNQgPzUcxz+07jWCwM4IRBRhA08THroezyUq3n851ZJIo+ruj 0CKQGHqrGFZ4lZCDVUghYOaOtY5Qa7Y/mqLpjVAnDM4ZmfitSUad1OOQ3ZEA729bJMAJSFWi yjR5uCASMGJokUaP12DAq9il5pHsjEYVfj6DSqPSVh2m6OhxQ/JKXVbUZdLsUgnIw40BPVMg lcAauhlBWxloS0Ob1fyhXJR9TaRZiTokkQNNZD8iMsaQGmxGgysLxWCoQ0l3UxAHmrimJsmq 5g/lMbcBKJfNgadI3ACuiSVrUYrFR3qKNN4me2im7aH519nDdytPa8XKSHWDwLcS87OFa6WF a72kcLcRl5aImWF7A7M7smimWTSfzeIKP5r4RobCp+mipygSZiPkVegvRuFqhCyNvNncc0US +ukXS3SpraxTg/PsvtOGm5XoXFWEaEztDNZmFitu/C+CuJWDuAa/fD/uz5evIInPl68jiM+X LyuHrTbNoYODQ8cbfSMjDfidi5lRaNYgtPBPE/+08M8R/jlGwPSmr71h5N02cHTFKbDflP1Z 9w9ncxoRpirYndlz5do1CYYrmtUIC0Ui0mUCtidhiVQRqDVeS+JtpvFa1Rpk0Ft6SjOXFEvC ilWampSmIKWZIcWqKmlZgpymIodLwawEBy4FkxPzuGQ2XzADSXk/5pdLgjbyG89qxlJqyVmt 9KymBM8RVkvPPMpdLzEzktmRnnKcy1FTwgrRHUvYu1sPhHxbGfk2BZCyRLTInicnzOWEbThR Yhh4Ov4Ks981q3jCYf4bnOTVrfKVvVBbySYvXLWQJz1kG9PYlBOtMY2XNIndVbeLEWnBrjOi VaGut4dtpLkp/VojnDUSUKRnsi5FZzr3Wk22oqSqLcoVS44KYyGEwVkLgnv8i/17YTtz/+7s 7WQWQv3Egvq8Xn97CnOH2QErvyna/0EbcXs8tl61/P9U/b9xfHIi6/8nJ41moyWPBE6K+v+f V/+PTIDK/z1VXcw9Bigq/0Xlv6j8y8p/5DSi8P9jqvD/46l1cmr++DKF//H4yar/6Rkc51T6 g8Vshg5Dr9+dnYr057uW9HElenefiyL5zfeV9CWS7ncV9SWO3lZlfQk72FjYH49lGiXcFv+z YWn73B46rH7Px2iG4kyjHvNhU7REZ+mLn4Gww6+dijBeRPn1vIJM48qBeER6lnzMJJjPgoWD kpCu+/WmoohEbNfU0RVYZF88E2PlV718BaSsZPigOCpDx5hcAukRB0RR1FPrGbTSA87BBTBt RWJhX9C5D5hJk1upaCQ8bkQeLF0x8Ag7sivceOJ7M0E0DwPmTGoiTIl598LpQ/sbA3JfjImn VSHU/kSEe5fJKCBOh4RwakQzIhNkGV0hKqNbkWdcZ++gy91qVUgD2RrZzmhBsVYwNeH0niJZ Q8F14kMnkpqSiKKZEAiyhbwHFTC0fcjC69ce9kXmVVVIgpqINoyqnejUp4Tla5dMiJJ1WdUV s4nKysHmkqfy8deud/7+KrVDKtleevcSsQ5TuTFKvsBEIWrXw8ddzxp3Pl3c+Swx7+gwmhDN qB62smzsOAnn5GigLCNnyMiVEAkGpHA6A8On3Q1daTHHiZOFO6KNDjhCgPEQK6QNQ3zNSyvI qqLL4JOrO4VOo1gHj2lwfLfU7/33U44AD/BOot3bQ2DH8+bE7yMBP1IgiV6eaYR+q9UeFXdE JDE28lzMt9G0Plz86+LDVXpVApJiqgEZVLkULIbhIyZLMxtzqIdbX9jilipMTBSBHROkRzDS x+k/v6uSn8boxaKyFHIzw3xhhhTKUUNRnFxCxllKO9HxbfR/3OEfkSMfMaHq0J6nmE6TEjFh cwIRMg8ODvQSPVxisHEJpQRMYBi5lnS9n6kqjnqQ4DKSGdijKhPvUqNCF8Ix3wpLmWDOhnHq LfYHSJVPuYjqU5ZnA8kZxTK1nYnc7wIxMD4zyyURv5FkSgM5sdigGB0pIFERocyByhkiNMVl l47BqxicxN+DmdGo4i/hPDKOr5RpkvC9BHy6LiLom3A/COtC1moPjsm+makKjFgT53ejDsOj N4CAtp2KWakqXNltP8RUU2Fr7lt7SlMo9SEPT7HzqAbmcfRwgnmnHsEM0zrSQyadDqKZ3EqT UIKMaJbClMjT0hQQt26yZKd9KQjZPO1JwgDElHYK0mGTMA2pTKqOqQAcCkwkAF0P7OJW3Q9T NcHI5wSudPiLioi58LlhVhcXKdXk7h1GGikLNL98FZSkEtx9S9QL6Q3gNNqoxKl3tE8J61G1 uneSc0p4BExsXuKRtiuEQfMSi1czvNUk0EAADTYD4cZE+UuoHvvisR899rzkOvumRJLcEaK1 vORaeYACriqVpbYLf4bv1JQnyewoIasW/cbebfxWFGFX/bCr+SZP7IYGPyRroVJr5MHS51c8 /iY1MxR/3yQ407NR1U+t20+s283BkanZbqjnCmdWCR+GB4oESJQKmhQfqKeb7OmJ/E/3yDAy UDEl2fm3KNLieyyG8b+y/get1kkzuv9rNs0m1f/M1lFR//vz6n+RCeRd/01e/AWKnkUJsCgB FiXA06TfiBKglb372zptHr3Q3d/o9XrXIuCOL9g7vl/v+nq969v1c16ud3+3TlzfvRSvdhvv pkWaSJc/9I219fWPlZvZ/w+1kHXljnUVDf0K4qYNWyx42NJvuhgAnZUs1a1nztr9KOkn9ZTX Jv0tkSVnkn2V63Ojtcf3mxGn+KByb5Xmrx1XGb63blyl/GvH1TuAZ+gFZa5PHeVSLL5EGju3 /ZCTvOLrB7hJorUdnqGAniOZBJKNMsrYQ2vPzUppLYSW01oILam1EFpWblZW7hpZFRck4vw/ ZEH4V37/1zo5MlX+f4KZv/z+r9kq8v8/L//XJgCYluLvIXNHUxFd5dnEhchEisy/yPyLzF9m /tpjcj77+/G0YZ62jr8j9c8ZDNkD0pwZdhcz2rVvESweoYckdOoqwS0Rnn6VyHmPaP6UPPoW c7J5cQcfEseXMd5UYqzONXc7Fcw7ldyced7IbxV2SlZrMNg6LVUVa0XYFkuImnn2xEAfGUlq t6M0OgOS5K7OaSShy/L7njEpSHgBxhUwAjHR5+5dNXOe53jikMbhLkse5dFMg8ZqEAhpiR6C MmQptCZmRqKKVkqvP/Zu1YmS4YhLxJIEWcMtleChJo4TVzh6Bo0CccV4+9v7zx24fn9xefHD Dz+8rVbbsJ7wfAwdUlw8Uw13noHpPBfT+TMw3eRiunkGpm4upu4zMPVyMfWegWmQi2mwPSY0 rvXYI+SZ8YcnrHqHBQ5zF3jcwm20g6T9ZjRlo2+3KrLn+w46T57nxMOJc/qsO8lTm9U48iCv 1Qi6n/A9geIsB0fo3S5cClhsbDyK10Zrb++h4jD3Lpyi1NUvKS7crR9IeoQNA6U43tMiIbZr FCJwVN+455MoNidFlCc9QdWauANg12C4IfLYDscUMVfChq1YiIKuWRWXBtp6Wm5IM4a504Zb yFod6et1zyDCRZN1/UNpT9+4cHH/h3uUKjwavIqzKnX5TUU88CAHaLydL3tpxOqORubmRqwG VedRBGOKhHpfID8qMceNoVyaCdZEPlDeWGuolpNFBvm14I34YLAnv7+QH8fKI3a6vOVHH5yW S/6Cikb6MZasvUSFL2trTT83QYj1wibouOKdp0bH80EN5BFpdI/mmZvV3t6ekA4+qUxJ5WlG TjyRwlkfhYguTInHrAqIN4kgL/yQXS2zKcrvFXnUvm6AbC3AVJzpeluynhoZ3pOsShSKwjQ4 jeR0ayZjzjayJu9lRJcB5XrSO+gGjLiuKcxavMXKWxASqq0uPpxJbcM+tOR3SBM58E7VIXW4 opVoZOZh7tuqoxIkIkn0HD5enXM6Ni7RxQyJWd+j0OfQIqqh3EmDCCAA65oCCZe4aQKee+hN JlrgpJZvWiWm7he3juhuVWaiPEKfqAVEZVCzQ/3fIN2FlmIIWNQz0Rd9zkUkrxthTsDWzDbX ztYjCaGkfovrC3SraGk7C/RA4lQKN10Gxj2HhFlPyILISN7DEAtXn97EuPT46OZBqUPH+PZS PdGyf2xclph8zrp/ZNYtndPCw2jh0r2NpkbLm+AGUScpnF7CXM+f4RuDvtlcii51nKGQ9uGP CH6dEWho+mcfvkXwSV2USqk9GJPUtxioc3gVwbKa0Gx08y/zlHogc3eYreJNeZP+cgLVeqHn Aa+RQtZuf1fWOczvj2UTMxJFYIwF6RDYOxxEV0pkTGs/OyALq8/uX9oAkQmecq5htiNp0Ekb WzWwxGaP6T9qu1dbNWKM0mYUolMTBjhhkD+hEU2IqW1kqW28FrWNF6BWijJpwAk6V0hTyfNq cWBnmrcl2cyD774VWVWUXu9gS66H6egyyhqHye6h7v4baCrfEDN8b+Gt3eijge9w1UjpDaXv GiRg6pXt1WMmb+NFqkGojKOQfjL76nC165lKytCWWqyxuljjRRdL8Gqu5TW51ssy86KSSxkf 3WwNvTkEfEaJK/fcFYuMh0R10mEhi42SllbvZfp/wUMPsk7bLj7nLlrRila0ohWtaEUrWtGK VrSiFa1oRSta0YpWtKIVrWhFK1rRila0ohWtaEUrWtH+99p/AAjYBQQAeAAA --ulUmNC+osPPQO6H1-- From Michael Riepe Mon Nov 20 02:18:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01085 for ; Mon, 20 Nov 2000 04:37:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:15 +0100 (MET) Received: (qmail 23690 invoked by uid 0); 20 Nov 2000 01:22:33 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx09) with SMTP; 20 Nov 2000 01:22:33 -0000 X-eGroups-Return: sentto-1101623-1565-974683099-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 20 Nov 2000 01:18:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 01:18:18 -0000 Received: (qmail 55727 invoked from network); 20 Nov 2000 01:18:17 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 20 Nov 2000 01:18:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta1 with SMTP; 20 Nov 2000 01:18:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA10027; Mon, 20 Nov 2000 02:18:12 +0100 Message-ID: <20001120021812.33877@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> <20001119164023.13141@thrai.stud.uni-hannover.de> <3A166CAB.72499EA8@jetnet.ab.ca> <20001120013054.53000@thrai.stud.uni-hannover.de> <3A167F4E.BCC3FDD1@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A167F4E.BCC3FDD1@jetnet.ab.ca>; from Ben Franchuk on Sat, Nov 18, 2000 at 01:08:30PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 02:18:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 35a27ed3cd52f69c68256f5f88b546f2 Status: R X-Status: N On Sat, Nov 18, 2000 at 01:08:30PM +0000, Ben Franchuk wrote:

> The logic looks clean and well written. I just find VHDL very
> confusing like C++ java and Wirth languages, simply because of the
> wordiness of the languages, thus reading the logic is hard.

Yep.  VHDL is an Ada clone, which in turn is an insane mix of Pascal and
COBOL... need I say more?

> If VHDL was to simplify logic design why do we have to create
> '+ -' operations by hand if we want Carry in,Carry out and Overflow
> bits? Give me a schematic any day.

You don't have to.  Make the adder 2 bits wider, set A(A'low) to '1'
and B(B'low) to carry-in, drop Y(Y'low) and use Y(Y'high) as carry-out.
Overflow is also possible (xor of carry-out and sign bit, IIRC).
But there are still other problems: the built-in/library `+' and `-'
operators have undefined delay characteristics, don't support SIMD,
and most implementations won't grok 64-bit numbers.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Lee Salzman Mon Nov 20 02:53:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01091 for ; Mon, 20 Nov 2000 04:37:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 04:37:16 +0100 (MET) Received: (qmail 17433 invoked by uid 0); 20 Nov 2000 01:56:07 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx13) with SMTP; 20 Nov 2000 01:56:07 -0000 X-eGroups-Return: sentto-1101623-1566-974685362-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ej.egroups.com with NNFMP; 20 Nov 2000 01:56:06 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 01:56:02 -0000 Received: (qmail 85372 invoked from network); 20 Nov 2000 01:56:00 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 20 Nov 2000 01:56:00 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta2 with SMTP; 20 Nov 2000 01:56:00 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sun, 19 Nov 2000 17:55:56 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A188412.BB46D88C@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 20:53:22 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GCC and PC-Relative Branching Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 92a15938fa45acde960371736d60f709 Status: R X-Status: N After fussing around with GCC to no avail,
I have a few questions to ask:

Why is there no PC-relative branch instruction?

Are the actual savings of precomputing branch
targets and stuffing them in a register that
great (as opposed to the extra code space required
to now do any branching at all)?

(After looking around at GCC targets I found that
not even a single one lacked a PC-relative branch
instruction, so the situation seems to look grim.)
eGroups Sponsor
From Ben Franchuk Sat Nov 18 14:36:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA01557 for ; Mon, 20 Nov 2000 07:02:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 07:02:56 +0100 (MET) Received: (qmail 22261 invoked by uid 0); 20 Nov 2000 05:24:00 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx07) with SMTP; 20 Nov 2000 05:24:00 -0000 X-eGroups-Return: sentto-1101623-1567-974697835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 20 Nov 2000 05:23:58 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 05:23:54 -0000 Received: (qmail 49928 invoked from network); 20 Nov 2000 05:23:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Nov 2000 05:23:54 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 20 Nov 2000 05:23:53 -0000 Received: from jetnet.ab.ca (dialin56.jetnet.ab.ca [207.153.6.56]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA27024 for ; Sun, 19 Nov 2000 22:15:19 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A1685CC.CA266EFD@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A188412.BB46D88C@lvdi.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 18 Nov 2000 13:36:12 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GCC and PC-Relative Branching Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 53372556a03e47e15b4f7d1655921d57 Status: R X-Status: N Lee Salzman wrote:
>
> After fussing around with GCC to no avail,
> I have a few questions to ask:
>
> Why is there no PC-relative branch instruction?
>
Could not a quick hack be to have Pc relative branch macro.
lea reg??,[pc]dest; pc=reg; Since stacks and other registers
have to be defined for C code anyhow, why not register for
a bra macro? Any how the only thing with a Jump instruction
is you would have more fixups in the code generated.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Yann Guidon Mon Nov 20 08:38:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00314 for ; Mon, 20 Nov 2000 14:21:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:19 +0100 (MET) Received: (qmail 1898 invoked by uid 0); 20 Nov 2000 07:33:47 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx18) with SMTP; 20 Nov 2000 07:33:47 -0000 X-eGroups-Return: sentto-1101623-1569-974705623-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 20 Nov 2000 07:33:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 07:33:43 -0000 Received: (qmail 44050 invoked from network); 20 Nov 2000 07:33:42 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 20 Nov 2000 07:33:42 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 20 Nov 2000 08:34:47 -0000 Received: from f-cpu.org (nas2-245.ras.club-internet.fr [195.36.192.245]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA15130 for ; Mon, 20 Nov 2000 08:33:40 +0100 (MET) Message-ID: <3A18D500.A45D5AD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A17799D.9AE8180E@f-cpu.org> <20001119164023.13141@thrai.stud.uni-hannover.de> <3A185EA7.153BE448@f-cpu.org> <20001120020354.55583@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 08:38:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] vhdl, Michael's iadd, ROP2 etc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: afef10524e4b282fa44eb97169618a34 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Mon, Nov 20, 2000 at 12:13:43AM +0100, Yann Guidon wrote:
> [wider add/sub unit]
> > no need to touch the core of what you have done (at least for *64 versions).
> > i simply meant that a 128-bit SIMD adder would consist only of 64-bit SIMD adders.
> > Since 128-bit and more require more stages, it's not worth caring now.
> Ok... putting several 64-bit adders in a row isn't a problem.
that's exactly what i meant.
Where i can't help much (in so little time) is to make a 32-bit version
>from the 64-bit SIMD adder. it is required for the completeness, but not urgent.

> > i'm interested, yes ;-)
> I'll attach my working version.
thanks !

> > > No problem.  We need a `wrapper entity' anyway to include the F-CPU
> > > specific stuff I left out (intentionally -- I prefer reusable components).
> > cool, can you send it ASAP ?
> Tomorrow...
ok

> > I need to modify some files, i want to rewrite ROP2 with the "style"
> > of iadd, i have to cleanup Michael's library (remove unused items),
> > reorganize, compile and test the whole damn thing...
> Please don't remove items... I might want to use them later :)
i'll add them as they are required by the code that YOU will write :-)
i have not erased them in my local files.

> I changed almost everything to Behave_<n> and Struct_<n> (<n> >= 1) now.
> I could live with other names (and I know how to use sed ;), but please
> don't throw away the numbers -- sometimes I have several versions in
> the same file...
ok but how do we determine the number ?
do we "sed" the files so we replace the most recent numbers
with a special architecture name ? something like Struct_HEAD or Behave_HEAD
(like with CVS ?)

> > -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants.
> No longer needed.  See the `ilog' function in ciadd2.vhdl...
> I apologize for the inconvenience ;)  On the other hand, defining
> things this way makes sure that the number of bytes in a word is a
> power of two (which is IMHO a good thing).
well, i'll keep it as it is now...

> BTW: you can include `ilog' into F-CPU_config.vhdl if you like.
i'll move it ASAP.

> [...]
> >   constant SR_URL_VAL7     : std_ulogic_vector(63 downto 0) := (others=>'0');
> s/std_ulogic_vector(63 downto 0)/F_VECTOR/g
yup, but i was very unsure at the beginning, whether i had to reverse the range...
ok i'll replace it too.

> What about a function that converts strings to vectors directly?
> Like this (beware! untested code!):
<snip>

ok, let's test it :-)

we'll maybe have a new version available in a few days...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Mon Nov 20 08:38:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00317 for ; Mon, 20 Nov 2000 14:21:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:20 +0100 (MET) Received: (qmail 24186 invoked by uid 0); 20 Nov 2000 07:33:47 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx09) with SMTP; 20 Nov 2000 07:33:47 -0000 X-eGroups-Return: sentto-1101623-1568-974705616-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jk.egroups.com with NNFMP; 20 Nov 2000 07:33:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 07:33:35 -0000 Received: (qmail 99051 invoked from network); 20 Nov 2000 07:33:35 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 20 Nov 2000 07:33:35 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 20 Nov 2000 08:34:40 -0000 Received: from f-cpu.org (nas2-245.ras.club-internet.fr [195.36.192.245]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA03690 for ; Mon, 20 Nov 2000 08:33:31 +0100 (MET) Message-ID: <3A18D4F3.A8A2CCFB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A188412.BB46D88C@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 08:38:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GCC and PC-Relative Branching Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 09ddc0141a4a7e1ebf266044d003cfab Status: R X-Status: N hello,

Lee Salzman wrote:
> After fussing around with GCC to no avail,
> I have a few questions to ask:
>
> Why is there no PC-relative branch instruction?
>
> Are the actual savings of precomputing branch
> targets and stuffing them in a register that
> great (as opposed to the extra code space required
> to now do any branching at all)?
>
> (After looking around at GCC targets I found that
>  not even a single one lacked a PC-relative branch
>  instruction, so the situation seems to look grim.)

Ok, i'll try to answer your question. satisfaction is
not garantied, though.

first, as Michael said, it forces you to reuse your
computed data. For example, in the code below :

loop_label:
  ; compute
  jmp PC-lop_label

there is a slew of useless, repetitive things to do.

If you look at a DSP chip, it doesn't habe that much
complexity (well, it shouldn't have). Some even have
"zero-overhead loops" (Analog Devices chips are impressing,
for example). So what's wrong ?

Jumps are used 90% for loops (rough estimate).
each time you loop, you have the following succession
of operations to perform :
- fetch the PC
- add the immediate
- check against the TLB (just in case)
- fetch the new data
- etc
So you understand why delayed branches were useful in the past.

If we remove PC-related (or whatever), and leave only
"post-incremented addressing" (to reflect the similarity
with the L/S U), things become so much more simple for the scheduling.
When the decoder gets the instruction, it simply looks
at the 6 bits that indicate the pointer register, performs
a little table lookup and know with a few gates of delay whether
the address is valid. So yes, it makes GCC code complex, but when
loops use the correct form (loop_entry/loop), it's the most
efficient you can get.

Look at the gymnastics of other computers, and wonder if you
prefer delayed branches, branch latencies and branch prediction.
On top of that, the F-CPU's mechanism is fully safe (protectionwise)
and does not require special handling during task switch...


I don't know if you can use templates inside the GCC description,
but the correct way to make a loop is :
    ; r2=loop count
    loopentry r1;
    ; loop here
    loop r2,r1;

If there is an exit in the middle of the loop,
one must prepare a register to hold the exit address :
    loadaddri endloop-$,r3
    ; r2=loop count
    loopentry r1;
    if (exit condition) jmpa r3
    ; loop here
    loop r2,r1;
endloop:   


Anybody understands why i'm so skeptical about GCC's ability
to generate "good code" ? :-) It's not something against GCC,
it simply is not adapted to today's requirements. A PC+imm
jump in a superpipelined & superscalar CPU is a real catastrophe.

So to answer the question, the "precomputing branch
targets and stuffing them in a register
(as opposed to the extra code space required
to now do any branching at all)" is a big win in
speed and simplicity. You remember that it's a "RISC" CPU ? :-)

you have to understand that not only the target address is
written by loadaddri to the said register, but behind the
scene, there is a little lookup table that "links" the register
number (6 bits) to a cache line in the Fetcher, so no data
move is actually needed at all ! that's why it should
be possible to jump to a precomputed location in a single cycle,
without penalty or delay slot.
The write to the physical register is needed because when there
is a task switch, the 6->3 lookup table is flushed and we need
to know the real address (there are some cycles of penalty, then).


I don't know if you have understood this explanation, but you sure
win to be active in the mailing list :-)
regards,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Jeff Davies Mon Nov 20 10:01:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00326 for ; Mon, 20 Nov 2000 14:21:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:23 +0100 (MET) Received: (qmail 27381 invoked by uid 0); 20 Nov 2000 09:06:25 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx23) with SMTP; 20 Nov 2000 09:06:25 -0000 X-eGroups-Return: sentto-1101623-1570-974711178-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 20 Nov 2000 09:06:24 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 09:06:17 -0000 Received: (qmail 26549 invoked from network); 20 Nov 2000 09:06:16 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 20 Nov 2000 09:06:16 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta1 with SMTP; 20 Nov 2000 09:06:16 -0000 Received: from modem-205.kentucky.dialup.pol.co.uk ([62.137.68.205] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13xmty-0000HL-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 09:06:15 +0000 Message-ID: <3A18E85C.77753325@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A188412.BB46D88C@lvdi.net> <3A18D4F3.A8A2CCFB@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 09:01:17 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GCC and PC-Relative Branching Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 49545b0e3c4a85bc18fbc7538d397765 Status: R X-Status: N Yann Guidon wrote:

> hello,

I think we can do PC relative branching by copying PC to a Reg (is this a
GET? instructions - I've forgotten),
then math op, and goto reg.

OK it ain't optimal, but it will work. (3 instruction macro possibly?)

Jeff Davies
eGroups Sponsor
From whygee@club-internet.fr Mon Nov 20 12:30:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00377 for ; Mon, 20 Nov 2000 14:21:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:37 +0100 (MET) Received: (qmail 3241 invoked by uid 0); 20 Nov 2000 11:30:28 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx08) with SMTP; 20 Nov 2000 11:30:28 -0000 X-eGroups-Return: sentto-1101623-1571-974719817-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 20 Nov 2000 11:30:25 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 11:30:16 -0000 Received: (qmail 33457 invoked from network); 20 Nov 2000 11:30:12 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Nov 2000 11:30:12 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 20 Nov 2000 11:30:11 -0000 Received: (from mnet@localhost) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA02717; Mon, 20 Nov 2000 12:30:10 +0100 (MET) To: erik.hansen@berlin.de Cc: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 12:30:10 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] inc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 41557a001c975f91924526e1e88f4b2f Status: R X-Status: N hallo !

>> can you send a first version, even unfinished, of the INC unit
>> tonight or tomorrow ? i'll try to polish it this week-end.
>Sorry, I didn'1 check my email this weekend.
you have a lot to catch up, then ;-)

>Though it might be a little late i send you a copy of my inc unit.
it's not too late. either i release now and buggy, either
i release later and less buggy ;-)

>Unfortunately this version i've got is neither fully functionally nor
>bug free. Indeed it might be very buggy instead. ( Haven't testet
>is a lot). Nevertheless it gives an first impression on how it will
>be realized.
ok i'm warned :-)

>As you can see from the little block diagram, which i have included
>in the doc folder, it might be quite difficult to fit the device in
>one pipestage ( assuming a pipstage to be 6 gates deep ).

my estimates with 4-input gates gave something that "would" fit.
remember, the 6-gate goal is a goal, that's all. at
least, it makes us aware of the critical datapaths
so we're not stuck by a silly hidden CDP. If a unit is
too long, it can be split if we need more speed.
i confess that i'm satisfied because all the rough estimates
that i have made more than 1 year ago are becoming exact :-)))
Michael has also helped a lot !

>Width input inverter, input mux, output inverter and output mux
>this logic depth is alreadey reached without having calculated
>anything.
hmmm.... if you're stuck with the surrounding stuff,
try to concentrate only on the core, so you'll add "features"
only if you have enough room.

> And although i realize that my implementation is not
>very effective up to now, i belive that it would be very hard to
>fit all functions into one Pipestage.
i was probably a bit optimsitic in the manual.
yet, let's concentrate on the SIMD INC and MSB features.

>(Read more comment on this in inc.vhdl
>CU
thanks !

>Erik
YG (not Gauss)
eGroups Sponsor
From whygee@club-internet.fr Mon Nov 20 12:36:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00387 for ; Mon, 20 Nov 2000 14:21:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:38 +0100 (MET) Received: (qmail 32642 invoked by uid 0); 20 Nov 2000 11:36:44 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx17) with SMTP; 20 Nov 2000 11:36:44 -0000 X-eGroups-Return: sentto-1101623-1572-974720183-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ef.egroups.com with NNFMP; 20 Nov 2000 11:36:34 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 11:36:22 -0000 Received: (qmail 45932 invoked from network); 20 Nov 2000 11:36:22 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 20 Nov 2000 11:36:22 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 20 Nov 2000 12:37:27 -0000 Received: (from mnet@localhost) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA06109 for f-cpu@egroups.com; Mon, 20 Nov 2000 12:36:21 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 12:36:21 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] GCC and PC-Relative Branching Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ce7c2c725fccca0f513f0923b2ebbefe Status: R X-Status: N hi,

>-----Message d'origine-----
>A: f-cpu@egroups.com
>De: Jeff Davies <jeff@llandre.freeserve.co.uk>
>Date: Mon, 20 Nov 2000 09:01:17 +0000
>Sujet: Re: [f-cpu] GCC and PC-Relative Branching
>
>Yann Guidon wrote:
>
>> hello,
>
>I think we can do PC relative branching by copying PC to a Reg (is this a
>GET? instructions - I've forgotten),
>then math op, and goto reg.
>
>OK it ain't optimal, but it will work. (3 instruction macro possibly?)

If we are trying to do that,
the loadaddri instruction does that already.
So your macro will run faster and with
less penalty cycles.

If we want to use GCC and if we can afford
the performance loss (i guess : only using 30% of
the CPU's potential), yes we can hack around GCC.
the idea of a macro is good, it helps for the
GCC description files and it can be changed at any level.
For example, we can make an optimizer that will try to
"move" the loadaddri instruction as far as possible
>from the actual jump. If someone wants to hack that,
i'm ok ;-) but it's not a 'simple' flex or sed script...

>Jeff Davies
YG (not speaking aloud)
eGroups Sponsor
From Thomas Page Mon Nov 20 13:17:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00409 for ; Mon, 20 Nov 2000 14:21:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 20 Nov 2000 14:21:44 +0100 (MET) Received: (qmail 23543 invoked by uid 0); 20 Nov 2000 12:15:03 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx21) with SMTP; 20 Nov 2000 12:15:03 -0000 X-eGroups-Return: sentto-1101623-1573-974722497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 20 Nov 2000 12:15:02 -0000 X-Sender: Paget@conlog.co.za X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 12:14:56 -0000 Received: (qmail 29135 invoked from network); 20 Nov 2000 12:14:56 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 20 Nov 2000 12:14:56 -0000 Received: from unknown (HELO conlognt.conlog.co.za) (216.2.176.8) by mta3 with SMTP; 20 Nov 2000 13:16:01 -0000 Received: by intranet.hq.conlog.co.za with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 14:17:24 +0200 Message-ID: <640F9ED3CD2DD211A28600A0C982788CB1EC7F@intranet.hq.conlog.co.za> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2650.21) From: Thomas Page MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 14:17:12 +0200 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e965536b900592388ca677ad931eb77d Status: R X-Status: N Here's the link:
http://home.mweb.co.za/mw/mwpaget/bx1.htm

I put it together rather quickly last night, please excuse any mistakes...
Also, I am fairly new to all this, so if I miss the mark, well, its just my
ramblings.

Also, what (and where) is "the big f-cpu manual (v0.2)"? I always enjoy a
good read.

Finally, does anyone have recomendations for a book describing the Linux
kernel, and how it works? I have some Christmas money to spend...

Much thanks
ThomasP

> -----Original Message-----
> From: Yann Guidon [mailto:whygee@f-cpu.org]
> Sent: 16 November 2000 01:31
> To: f-cpu@egroups.com
> Subject: Re: [f-cpu] F-Bus, G-Chip
>
>
> hello,
>
> As Nate wrote, you're welcome and please share your thoughts.
> reading the big f-cpu manual (v0.2) will help, too :-)
>
> Thomas Page wrote:
> <snip>
> > I will prepare it and post it to this list toward the end
> of this week.
> it's always too late : once it's written, a draft is deprecated.
> but it's how the design evolves. The best parts remain and
> the superfluous
> disappears... so give it a try.
>
> have fun,
>
> > ThomasP
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> eGroups eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9698/0/_/3462/_/974330790/
> --------------------------------------------------------------
> -------_->
>
>
>

eGroups Sponsor
From whygee@club-internet.fr Mon Nov 20 17:34:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00327 for ; Tue, 21 Nov 2000 02:10:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:32 +0100 (MET) Received: (qmail 31716 invoked by uid 0); 20 Nov 2000 16:35:01 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx10) with SMTP; 20 Nov 2000 16:35:01 -0000 X-eGroups-Return: sentto-1101623-1574-974738060-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 20 Nov 2000 16:34:58 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 16:34:20 -0000 Received: (qmail 16758 invoked from network); 20 Nov 2000 16:34:18 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 20 Nov 2000 16:34:18 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 20 Nov 2000 16:34:17 -0000 Received: (from mnet@localhost) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA08737 for f-cpu@egroups.com; Mon, 20 Nov 2000 17:34:16 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 17:34:16 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: RE: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2971450c1a6de4d721b1aac6c5b9811a Status: R X-Status: N hello,

>Here's the link:
>http://home.mweb.co.za/mw/mwpaget/bx1.htm
ok, i'll read.

btw, the tux.org site is no longer maintained.
www.f-cpu.de or www.f-cpu.org are uptodate.

>I put it together rather quickly last night, please excuse any mistakes...
>Also, I am fairly new to all this, so if I miss the mark, well, its just my
>ramblings.
don't worry.

>Also, what (and where) is "the big f-cpu manual (v0.2)"? I always enjoy a
>good read.
you won't be disapointed :-)
the old v0.2 is located online at
http://www.f-cpu.de/man/i7/summary.html
the index is at http://www.f-cpu.de/man/
A newer version in Latex will appear.. one day...
It's a mix of philosophy, specs, classic RISC concepts
and others that are really f-cpu specific.

>Finally, does anyone have recomendations for a book describing the Linux
>kernel, and how it works? I have some Christmas money to spend...

spare that money, browse the Net and have fun reading
the kernel's sources ;-)

read you soon,
>Much thanks
>ThomasP
YG
eGroups Sponsor
From Michael Riepe Mon Nov 20 19:22:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00354 for ; Tue, 21 Nov 2000 02:10:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:40 +0100 (MET) Received: (qmail 8739 invoked by uid 0); 20 Nov 2000 18:25:22 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx15) with SMTP; 20 Nov 2000 18:25:22 -0000 X-eGroups-Return: sentto-1101623-1576-974744706-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 20 Nov 2000 18:25:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 18:25:06 -0000 Received: (qmail 94860 invoked from network); 20 Nov 2000 18:24:25 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Nov 2000 18:24:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.128) by mta2 with SMTP; 20 Nov 2000 18:24:21 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00519; Mon, 20 Nov 2000 19:22:44 +0100 Message-ID: <20001120192244.03558@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 19:22:44 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] EU wrapper entity for IAdd Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" X-UIDL: 4a03be1193e15319ecbed7997ba9da8f Status: R X-Status: N --6TrnltStXW4iwmi0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi *!

Here's the first version of the EU_ASU `wrapper entity'.
I also cleaned up the interface a little bit...

32-bit-only support is still missing (I have to change IAdd for that).

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
--6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Description: EU_ASU wrapper Content-Disposition: attachment; filename="asu.vhdl" -- asu.vhdl - Add/Subtract Execution Unit for the F-CPU. -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: asu.vhdl,v 1.1 2000/11/20 18:15:37 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; library work; use work.FCPU_config.all; entity EU_ASU is port( -- operands Din_0 : in F_VECTOR; Din_1 : in F_VECTOR; -- subtract flag (should be derived from opcode) Subtract : in std_ulogic; -- flag bits (directly copied from instruction word) Flags : in std_ulogic_vector(13 downto 8); -- SIMD mode bits (decoded) Size : in std_ulogic_vector(LOGMAXSIZE-1 downto 0); -- -- 8-bit result Dout_0 : out F_VECTOR; -- 8-bit carry output Dout_1 : out F_VECTOR; -- 16-bit result Dout_2 : out F_VECTOR; -- 16-bit carry output Dout_3 : out F_VECTOR ); end EU_ASU; architecture Struct_1 of EU_ASU is component IAdd is generic (WIDTH : natural := 64); port ( A : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); B : in std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); Sub : in std_ulogic := '0'; Sat : in std_ulogic := '0'; U08, U16, U32 : in std_ulogic := '0'; Y8l : out std_ulogic_vector(WIDTH-1 downto 0); Y8h : out std_ulogic_vector(WIDTH-1 downto 0); Yl : out std_ulogic_vector(WIDTH-1 downto 0); Yh : out std_ulogic_vector(WIDTH-1 downto 0) ); end component; -- internal unit width (only 64 is supported right now) constant w : natural := (UMAX - 1) mod 64 + 1; begin assert w = 64 report "width must be a multiple of 64" severity failure; -- many adders in a row... instantiate : for i in UMAX/w-1 downto 0 generate adder : IAdd generic map (WIDTH => w) port map ( A => Din_0(w*i+w-1 downto w*i), B => Din_1(w*i+w-1 downto w*i), Sub => Subtract, Sat => Flags(12), -- as defined in the manual U08 => Size(0), U16 => Size(1), U32 => Size(2), -- BEWARE! not available when UMAX < 64! Y8l => Dout_0(w*i+w-1 downto w*i), Y8h => Dout_1(w*i+w-1 downto w*i), Yl => Dout_2(w*i+w-1 downto w*i), Yh => Dout_3(w*i+w-1 downto w*i) ); end generate; end Struct_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --6TrnltStXW4iwmi0-- From Michael Riepe Mon Nov 20 14:37:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00357 for ; Tue, 21 Nov 2000 02:10:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:41 +0100 (MET) Received: (qmail 10790 invoked by uid 0); 20 Nov 2000 18:26:12 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx15) with SMTP; 20 Nov 2000 18:26:12 -0000 X-eGroups-Return: sentto-1101623-1575-974744688-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 20 Nov 2000 18:25:34 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 18:24:48 -0000 Received: (qmail 5805 invoked from network); 20 Nov 2000 18:24:34 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 20 Nov 2000 18:24:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.128) by mta2 with SMTP; 20 Nov 2000 18:24:32 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00504; Mon, 20 Nov 2000 14:37:23 +0100 Message-ID: <20001120143723.19484@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Nov 20, 2000 at 12:30:10PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 14:37:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] inc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 606eeb3371af34c1e27484969cb3300c Status: R X-Status: N On Mon, Nov 20, 2000 at 12:30:10PM +0100, whygee@club-internet.fr wrote:

> >Though it might be a little late i send you a copy of my inc unit.
> it's not too late. either i release now and buggy, either
> i release later and less buggy ;-)

Erik, could you please send me a copy, too?

[...]
> >Width input inverter, input mux, output inverter and output mux
> >this logic depth is alreadey reached without having calculated
> >anything.
> hmmm.... if you're stuck with the surrounding stuff,
> try to concentrate only on the core, so you'll add "features"
> only if you have enough room.

Forget the input/output mux for the moment.  Without them, you should be
able to do the inc, dec, neg, abs and lsbit operations in one pipeline
stage.  Compares, min/max and msbit operations can be done with a second
(reversed) tree that operates concurrently.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From "Erik Hansen" Mon Nov 20 19:56:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00366 for ; Tue, 21 Nov 2000 02:10:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:44 +0100 (MET) Received: (qmail 4204 invoked by uid 0); 20 Nov 2000 18:57:55 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx05) with SMTP; 20 Nov 2000 18:57:54 -0000 X-eGroups-Return: sentto-1101623-1577-974746653-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 20 Nov 2000 18:57:36 -0000 X-Sender: erik.hansen@berlin.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 18:57:32 -0000 Received: (qmail 6834 invoked from network); 20 Nov 2000 18:57:32 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 20 Nov 2000 18:57:32 -0000 Received: from unknown (HELO kxmail.berlin.de) (195.243.105.30) by mta1 with SMTP; 20 Nov 2000 18:57:31 -0000 Received: from schlappi ([149.225.52.202]) by kxmail.berlin.de (InterMail vK.4.03.01.00 201-232-122 license 28ef456dd6e1ff79938cc49572f166b0) with SMTP id <20001120185723.DNTK27130.kxmail@schlappi> for ; Mon, 20 Nov 2000 19:57:23 +0100 Message-ID: <000c01c05323$a59a7da0$7bcffea9@schlappi> To: References: <20001120143723.19484@thrai.stud.uni-hannover.de> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Erik Hansen" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 19:56:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] inc Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C0532C.0034CA60" X-UIDL: b75cd7a47a422c8a553effc7e1c5b0d0 Status: R X-Status: N ------=_NextPart_000_0009_01C0532C.0034CA60 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit > Erik, could you please send me a copy, too?

Should have posted it in the mailing list, which i do now.
Sorry for that!
So have a look and send your comments.

> Forget the input/output mux for the moment.  Without them, you should be
> able to do the inc, dec, neg, abs and lsbit operations in one pipeline
> stage.  Compares, min/max and msbit operations can be done with a second
> (reversed) tree that operates concurrently.

I thought of splitting the unit into two pipestages with the opportunity
either
to pic up the result of the faster command after one pipestage or to wait
for the final result after 2 pipestages. I think 2 pipestages will be needed
for
min/max anyway, even when introducing a 2nd reversed tree. Will check this
out. Futhermore I think that there is still some headroom for optimization
in the current version and a lot of things to keep me from learning for my
exams ;-)


So long

Erik


>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

--
Der Philosophie scheint es nur um die Wahrheit zu gehen, aber vielleicht
phantasiert sie,
und der Literatur scheint es nur um die Phantasie zu gehen, aber vielleicht
sagt sie die Wahrheit.
(Antonio Tabucchi)
eGroups Sponsor
------=_NextPart_000_0009_01C0532C.0034CA60 Content-Type: application/x-gzip; name="inc.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="inc.tar.gz" H4sIAI7fGDoAA+29aXccN5Io2l+nztN/yPGbdyx1U3QCidysdp+hJdrmHVvy1dLdfl/8imRJqmuy ilNVlKz59S92IJcqktbimW7SlgQmdiAQGyIC88XJF3/4yD9ZyOuyzP6QZVldBfzX5SGn3+Unhxyf F3nuixCwWO39H7LyYw8Mfy7Xm+kqy/4wvarc4pfF8u3iUwzpU/7MYf9P56/Olq8+Hhhcd/+r3Ic6 95DtXB1u9/9T/CT7D8mwf/bq5Qfvw+V5FcKW/XeuKFxJ+1/meQEbD998VRV/yPIPPpKRn3/y/b9f Tl5m68ki83U7cVWWT/yE/3WT7u/X/TffUt99oH+3je9Dlf9Y4/692+3v08ca7zY4cL3v/X8/9Hq8 Lxz9Vrj51OP+n/LvtnFf9f2m890GX9vw1VX9XXccNz1/1/33Q6/nfzd4+r37/6346aZ05GPty8eG 2/8B8LuGf95mTVFMigIYzKLIW/irlpSv8+zFpPBtCb87ynGc8nWNOUVewO8+x5yWU8CAUg4V91g8 1Jzy0CzmePrdw19lySlfUj9QCX/HzktJ+arkOtQP/hUk5WEoNDbqBxuqak75quGx0e8Vjq3klK94 BK7SmfpKZ8qjDrnmlLnmFNyP15zca07L/dBqNfBX4znlK1kdmgUOowmc8qXk0IioTsUpX/Ea8LDw r6bhlC+5nxpbL2x/IOVh7Sin0Zwm1xzH87GcUnNKrlMGy6kkJ3A/3nK85fDqFLnmFF5bK3jUlpNb DtfJK8tpNId3gWCJgK6uOOUrGhsCFw/Q03wg5YsqrluDIED7ASlf8m47/L3G4i5wyhfUj6e1L6lO zilf8Z5SQ6XXEUBKRsCgRmMLpYyt4NUp6HfMLipOed9ya9h6oBVtOSWj9o3TDSgbTvmCTxZBDAF7 WXPKV7xzDktW1FnLKV/wWaDWaWyVl7H5EM9CRcPKOeUDzydUCmp0SiDlvZztRsGTOoOUDzICHFbM hpRCLx63QFveVpwCETRCb1vjx4pT3sk5dXJAAuEMSPnCxdOISxR4d2ENCoaqohGQDnSWIeU97zbN HFFOYISFEF9EeKOFaAOnfF7b+Qkul/ODKe94dXBNAgOQ55TP+TQiXEidWusUdua4TmN14pnjOrjl VCfnUZc2AgRHbi2308itldKuaws7jVzHV9paMAzLdXzQOrI/NgLfap14grlOYXUaw2JcB3eB63hb Ua7jcq1TRhhtaj14kPKFjIAWppQVxZQPPFNP26mghSmfy4oSHq31NEJK6Q9hDtxo7yTlGhqbI8Ti KEdolGvoNDqmOtCZ90KjXE0zdXR4kTI5gklIuYZWxxFGwqE7piowU8YUjilIwBxJOaaAjqkONOka SbmG6zClKnFsjlOuofk4pm4V5giadUx/XKX0x9W5zpRH3Sh1dm3QnJLXQKmZC5LCidEIGkG7nulc A/3I6tAsasxpOOV4rR0hMPzoCdt7rMNrTSgUAcoT9oeUExrsFMfz/kDKMZXxXmmWV6qCk8fWWs3h +WAO03rXKs3ySlUcY2VXaQ6vDrXG81GKWLi60jq8osFyguVwHaWIhSu95vCeEtuCR9IxMwK7zVTG ETHH4p6YHkghaFBOEOzvCb+FNtYpBRV4oo2QcoxHed0QtDz1CCltjagB4kRH2B5SjukPrwHWcUTN sE4oIlzXBFVCVF2Q8xO0Hz5eUKco4uogavOEeyGFB4d2wQkm93T0IeUKF+G6JbjOOYXgRKOuBCF7 L6hZoYrwG0Fi6TjlmENh6AVcB2eq4ZQr5CzQCHCtaacg5Qo5CzQChzmeU05oPc0PF8YTfwMpVzAk OsTfuMx05jDlvOQgVsYTLGVgBIyVaVe4jvdahzkHLM51vNURuC6kDmEKquN41G1tOY22xqvTttpa Lu26XPa01Tq109YC5wSpI2WwDu9cbSMgOkd1KsNiXKe2Oo2deq5DNIvqeMNVXKcstU4Z4Q2nwrgX Uo45B8aJbSUriikENDtzeOA97zucLF/GfhCgfCHUyznBsKXQH2RmmP44wcpEj3B/gqScK3l/6Gw4 O1lOTxbjO85pNSehMkiuPPMUXqkMn2jOCZIj56etJId2F1N1xNb0XYmgYuta2QzaJ8opZd9aq+O0 lzJSBcqpNEeoQmn9l7XWaSPup5ygsxF8VFidQusIvShs1IWOuhCMqJjKBa9Yh2Aqr5Q257WlIAN4 USXNea2kmZmqPFfSnDdCmlta59wrZc5LoczMnOSFEua8FMLcBM5QupyXSpcLbkrJch4k1fJ4c6XK eS1UueWmnBLlvFaiLKNSmpwXKhNyjaAkOS9VYK546kqR81zlS24qV4KcN0KQmcvLc6XHedMoZeYM Jcd5q+TY8XCVGuetUGPexFwJoGwIpJi3yBuluHkjNJGPRF5ahgqFzA/lpdLbvBJa2cjqWoaKhMzZ 5EWwDBlGU/M8LEMFwpZrOKXCuZNhEGiDXCJEGFJKhANnkAyFW9uqZMfflTbnjdBmIlhSP9A0lDRL S0qZ80ooMyEjyCBxEAGRDhyKZTwolVRhvWtONXHR8a+cz27FfcOkiJDjoIjVI7EnLiHVIJyI1LqO hwBJcl4LcWaclpuonFfCJLPgyWuLm52TCAcpxxmlstk5YR1IVUU8BC3BukhxteyGyjt50yo+5owg pB3pHKXKEGEdN8IRcEOK2bicEC9SQ8dsQpExR5YHFd8dcxY+Y7UMTwvJuiMGBlM8D5K96Pgz3fJZ yX2QuEbHn4uETLASiZNUg6QzrCEZhdZotAYvO0lkjGJKqcE7WFrnJJphBi9i2WpTlTbKwOBbrVHI MFizkpOcRjW81GXWLS+scxLLsI/c8BvXKLRGMLzANUgowz4aQ2Ncw0ldJsoMV63hY0hVdUSVbS2L iClmkHNl7+CgVZIqYh/4V06cDP3KTRGpxj3PvaR42U3uRBrAKd7BRklbrkRPDk7TWIbSRR8JDtLO nBQjlOKMwjICp+R8MJHEDCaSBZ9mQeCUQfIQZshwvWYU0ihzKXlhXQYnGXUkEpThNSPYieIMp50X kRZQRi6NuuRE0ehbreE5w6bV6nBdxHyEGXJRZrk8nnPc7lxFAMEMvtYML/KEYJ/SaUaphL6MHADm +lxQonAGio19Idi4SjAl4ijCspgyPpxEfZZ9IVUmGLRU8gupkLSDnAcreWFA1A7rpJH7VO206qQJ v5Ag2tMVs06aclQ7LTppbxSbU6j9EO2uUX9OUY7oik1fTinKYU2G8UScohzRtqmOg1OUI/rLRnJk gJjDWhbiuCgneM0RzYzl5L436kpzfNUdNeu1ayF86agT/UvojJp1hqyQ7OvYTfeda50q6qA4xzfd nNJrTum7OXWlOXXVzalsPpXl8ExDpQ1xyrTIrPsmpQWngup9+VpCWUzJYQjxphHmVGyNpXhlHpPW GGJIvm91BEWiW6Uz0zbdfnLlUCQV+2EdQaF7moy6sd3u3zO0tqc9DTerfHNR+XbuGRqDt/49Q27n h1KFszsdWjKnk+IchtFaTyOnKCdEqIq3FiEfubWgFOW4CKPx1gJzhrcW2lpIID7eWlDO4NbCWivi WsdbC8oZ3Fpoa+mtRbwLw5kK3qkNSVAqWTe9AZNUEe/C9AZMUpgzuAsremsd78K87k//LoxTVKd/ F5brCGR/4h1Vrv3oHZXdROXamkKI3V7lttt5PCW+1lOStOZVkOFUUqco7GPR7Yd1kYT52m5rfBDt gCetEYmn1sq62xrJ215Iaqc14nuYENbd1ogp8aKC67TmDSd66yePmK+w6RIk1hFbMlQp9JZlxIkM 1waJLuJEPiUG1008WTT9Wm+85NRzScOjlMPnpzUc0r8/434NK1MdF6GXBKQgqn69idK7MUlRThvX IBj2r+3Gi4GQ6viqV6fQflgEshy51yoUrjGH77VMCpMU5CR0KRhdorb4Ls7ucTlVG83kWzrqpZGb yYa/6zp7FUQH94eSijeYdq8nKcP88S7Qm4Crd4F6fzi49UxuSl13P+NNttPVFDof7w+d7YDc2nhd Z70zlZtSvjkliHLdmXLJ0uok9Iqvswgp5t2ZEi2qiPrl2o+PObRunCqttSIe6R7NLozOFz06X5jB QBE6I+BbaiYmOmqBwnjPH3RsdXLnSGtd2Lq1cQTx5hdzWMDgG3QaW9kbW2lcQ9nlGuyOWFLJbusd sabiqPWOWFNxptF2o1J4F96NKBuzT7rbcidMBIlyvOvmUOeVKkdS2NG7aEklOaWeUbuflltpu6XW W9s85uQ6girvjoBLNlYn3u/yrjS6P8mdMJ+ARs9CvEfmu+eaZAW5hZa7Z+bLOEcuuvX229sI9C5T bzBZqDL+CNgnH4pIFwkVcKox7Mpkx6gF5hRNpIuNkcCkTqmj5hT1EyL1Y5RTdOvoHb6mGpsPKXpq AWkZQbwXT+9qG5tpXVoda62MFLNRTVVnBMZsVprj+ze/nPJ28xvtCTjlzZ6AOLZWeTfO4VEXcufA KcoRak53Gbki07S1MmhrfB8VWyOYZSa97bZWNTpqTsVR0z1LrnJ/2g8tWaucbdpPo3cmlEr7afS+ TUwhvFpOMA1vVcHIOXWkC5xjdWQXrE5lddqIQ6gfUmwl/fBdmqIyzqkih0Z1iqJbh6h7K6KF5PQs QSiV1ol2Jc511yDabuRVd92IirOQrjvH92AM7LnZWCVWKiZrDyxBWmOE+/YrrUlFY9YJqfWI71mP 5Fm0IxmxHqm0TpTlOKdvPaI2I5ryY9YjWketR6LFSd96xEbgdQQd6xFSAbRaZ2A90midyigt5+yw HtHVySN/IP30rEeIy2PDOIUqtTwyuxKnUMW4SqyKaNO69kVmVaSpWnG8WRVpqla6YFZFmqqVlphV kaQoh1c0GJVhm6qI34jdJDzKqYhHg4IapRiu+ZauUI2UWbKo/YpNf2BXUql8bpYsar9iXA2n8A5V bvaMP+AU5qhdieqqOEU5fFPqjFNW4x+zutFTwinqh2+yK5UvOEV15EZUzxynKIfvhIPlhKo76lr1 GpxKRm1n27WhN2odm3dNZ9RshUMaw749jtnJcArriJ1MrboqTiU5reqqnGoMJYfvntnqJu/muNzG ZvMRqwG7sWqFi1ZLkFb1QZIKmVhHEHuGlyWVcJaJPRK1VNXdlohjK9ViILYUFNlIKtiNdFApRlLa B+k7qY8Qun2wDq7QvdQ+vKke+pZIbGVEOT17I7Yy4pyuvRHbdtEJUH2K2naZVphTlCO2NnrSOEU5 VYSYaL0U8jHrJa85LsJftF7CnL71Eqcox0dojtZL1NrAeslaq+J6RuslyhlYL2lrlcxUrbU5hTNt BDLVWtur5sjWTZWhnCoiTlFLOElhzsAmru6udWITV+n+9G3iOEU5PZs4p7pFtYkzWzVOFS5aFSnb 7Eqbj0CIql9csN328RRQa1Xbba1WnZKri26dWnVKrq67/bSqU+JU0lqrOiVOxdb4/oTs6HLXaY3v Ruju39Wd1tiKhazyvOu2xho3gtGyO7Za8Z1TTaXtnMI1pwh2EkzI8GbQ20R8x3BtkBgivuNTYpDI IzAFnaQU45gVnaQi/rBbJkkpxjEbOqfad8VRZnc3sNUrrfey07tJ606ldbO6U02CpLT3wvAdp6Kd XmPYuelg52iB0PTwuQl0ktI+ar1FkJTN0Ntdgc/7tMEweptidLNAlFRcE7NA1FTSi96JSErHxVqy oPQHLRFDHmlWtESknCJCHuVQKsnhy1tsjVJJDt/FBqUplJNQoWh7RDlVhBaqo/ZJkpNYVqouwKig WklyKplPo5elnErHRtJ7rfQmGRvJWZRTVd0cvqKtlBLFfsw6U1JJjlpnSoqsPlmDodaZkor9SMk2 i7aPYvEos2h1PtFKkq3IKEdtLNWykjRblKN2mWqNGaw1tf9Uq8+qttZ61n7MBxs2adHwponUi6xG SpHw1Q6QdRCGm6iOj1SS6tShW6e1UbeV1mkjNaY6bdOpY7armmp1Pkw1G6OflJPg58SusdWZMuZr DAdiTplHHoIsHr3vjYB+r83CtjULW7N4lFQxtHiUVKEWj2zb6fJMU4XZT7KA0wouohylUUFb41Rs rVXpUFLWms/VEIhTsTUUbcVOk1M2auKr2E6TU0W00yzUysgX3X5Yn9CKhXraD0myZtVOOXxvyPa6 zGU6zWkMH3COszqtSQWSo3VEH08mLNSPGrOozTI7uNRC2zmnNuweWF5ounVYR1QLd8E5lVEdrlOG bh2zp+ZUsnNmLSupuNus86qF8+HWgnHAqQV00bOAdlm0hR6xgHZaRyyga8uptY4zzJdaQBdjFtBa R7yQcrVZHlhAq92zpoqeBbTLoi30iAW0tqYW0K3l6BoMLKCD5qgFtM1nYAHdCA6hFK11SKhMqzI6 5zCMlgZvPUt4s3/XVKO41+zfNdUovjb7d001Zgmv9u+aaowutIb92cY/4p1WzQIlZfiNaL9AvJ4F 10bONFpaR0pr9tUDbwCzr5YU1lFL62A5arCklta15DhVkgp2U8U1p6itMvLz0dIac4RnjKZmjY5Z La0tp9IctbS2/kujzW2UNaKlNfUj1NTGVujYxJ66sNYKba0VKDCpt2ft7oNJyn1rd9PH9G3n2cqe c8ROU6kP8+qmpehbyDMWbTSn74eltvIdC3m6O1Vb+Y6FfDA9SddCnqmS2tTrvulNklnE6+7Uekdt VvS6o5XeUUsKrWmF4zSdmFrRd2znK5MD+rbzwfRBie180HlKCvphi5HEC0vt6ztW9QhOZl9vVvXq SyqpKhO5SW+1JVVl0rvet0tKv1d68Scp/U6nmL63Ree705m3TldLbA9FSxLN99Vo33QufYN6r+pI M98Xo/1cV55TaLMlBvW69ZzCDDGoV/jKVQ8n9pi1qiJzVcOpk4HAqqQQ8nMxd9VzxCnIadn00dSN uaobWzFRt4y86ozXVFSciuMtVQvJqWS8eoQ4peMVnwNarJ73QfQMyKWGeAYUqoHkVMwoVQHJqZjR qP6RUzHD1Km5qlNbcQBQCVNSCDGcoeKtpEImxuuqfMzNGE5Mn1Wyz1Wyl5a8iqqS0pZyVT7mZgjH Y8pV95ibHZyAlQrjkrIuctU9Skq7MM1z3+nCzOb6vhVmJdP3rTD7zFzNqMRzpVS9Y652XOKHUqva MVejMPEqMeu3XK3fhm4aopxRNw3VEuZq+zZw0yilKXHTMMu3XC3fhm4a2lRyBqKbBmQM3TS0KfF8 UG1jblpAwRjq3COpZLFU2Zirqk8whjr3SAoyBm4+RXd5o5uPWmEN3HzUiHHg5uNcZ0OiC44atanr g2oZOYVNCTSokjFXAzmXADs1pbZu0lShKsZcTd2kRqEaRk7FPkpVMOaq4pSmStUv5mrnJk1Vql7k VGyqVu1irlpMaapR5WKuRm7SVKO6RU7FpgpDY2qcqBtlwFsI8DYu4jcGLIXRxDifgVcgrkk8A/gc KMSxGbz6/2gq9Px/NCWIIXrzaCqoN4/6/2gqmP+PKBV7vkcAAapTlJTiGKc6RUkZUnKqUszNpIr7 boOOthWdotQIhnNDB+cGQ9Khi6QL1SjmZjMlXnOqUszNZEo8iaypqofvDUuXHSytflOSiuuhflOa il2oOlFSOqjo2iOpVp181N9AUo1Xvyf1j5IUZtQRCimjcJ0M9WmQVMwwR2hOYUYbqU30oMAMIdhq d8EpRMmJOw25afmiM9ygCkZOJZ2rDVCuRtzqjKFXypyKGaVq/TgV+1DPMEnFDPUMkxRaOnFT6hkm qdhHJVrDxP2qjfOgDHXYEjctduzK1dVFHbvUFQyPkzqFiStYbk2p45m4m3nrXJ2QxPWIfclyQRdo oVG7SIfIJ4nMCYhpiJiHahSeM6om0jqqQUYLsUZZaY1SrEBqH+kp1SibTg11luMU1cgjEaSmajFl Et8q9agSBzXMaCN2oxqNNlVE8k+dN77buQj44vWGTUVmjFytJBUGTleSCup0RRZT5L9VaI1gOIbd /4LW8MZ7cFOcsqbIXIqa4pQ1ValFiKSsKVV/acqGaxFVJGV9kKkU9dEUnT4atVSRlPXRqOKMU5BR BiN1IVdShxlVPOecUUuNyhnHLhlawxvq4z4oFftguyqlzJTRGqLmGkXTqcFWVcoWUEZj1INruNCp Ef00XdWZeXTNc66zVmyFpcwKNVUbh5o6V4auc6VXgBt1rnRSQzJqy6izjnNlqRmlOCUOnSulRhkp Dmf0nCsL67yQzjvOlSR6hGyLc6U0pc6VNvOtzpW5Zsh+2Dz6zpWNYgYvW6sYThRpnCLwYdnfKVx1 HWqjG62mWsGi5karqVYcas2NVlOtYurSMDXrGg1llGrQx26vES2VqvPmFEJJwiNGP81IB807s+8x HL0zKUU+0IYZUj9N82NW70xJIfESP81SM4IQL/XTLDSjEFor7Id6Z0oKM+pIvKKfJmbIibLO1WVb /TRtHrnMQ/001QmTU1iD+U1z2+QUZrDm1fz1eu6xLjdDp557rNkj9j1tzYSx75trfl3Rg9ZHihNM LRA9bWMEh+haG7m+qlCur+dQG0z1EB1qS1U4SaoW9/hSFU6SqjNX2RHkLtSzVvYpxlZQJ93UNTeY PiS65npVgklK+/aqGpQU9C0Zpp9S593UZbcyZj5x2VX9m6S0C9N+SqrOfJ6lgSASp97ElbdyWeLU m7jyVkGFGOlCnWgLc6etsySiRDC9UfQibuQuOXoHC0drpnOd8AnivsuqYvku7vq0msiQBFlXkeic fs9d8t2biMQpwFFyJU8bHNQAC9CIXINWsqiSqjSkQpsViUMwnKJgbALLKLW0XyScelBOXRyI5Tca p7oku8hD02ZyqtKVlvlqiud1gW5XiaOwIx+CSfQPduTeMoluwY78DybRGxh/D+qRoU006hKlTbTq fyFNhFxdvbiJ4NTsGq+OEGaD2m7rh1KNxvVDpXarJPPxTMw91lPkR/UHwfNZoiubGuhKldKpd59U KX3q+opyX5F6vGIbNNk8aaPU2WsblbpT4CqiM4u6PXg0ZfGVVycEWCKMrlLoIDBgGYqUhXpQoPIO +myCmqujuSA00ZST6EdIVSp1oNAqtVrFa5VGjPutSqseD1KlzdVgX6q0Tn08MHQD/O4T/zycaVvr nshatI1+qEhm5g/mHIcMXDCfOPlQpiEeSZRLfLbYoCx11UJK7FIPLTR28Kn7FZYIidcVtVGmzlZY okp9rLCNOnWtwoPbpH5TuCx56hRFutXEF4p1YqlrEgnpqUcSMT6pIxJx54m3DK41wZe6wtCHSv1c AOUh/i6bxFUFSxCAqU8JHoCqTFxJkFWoqsSDBBUwVZ04jlCVJvEXoSpt4iaCK1DniXcItlG7xCkE 26h94guCbdRF4gKC8nYdEl8N+tAkjhj4ocnV+4HBtCDIVqN6kN9CXui5RykIenZ5YqYOxAT4CfWt oCOCvIFiF9lbaqNUXTxhezVol33JndoQA4KCxQ6umkSDc0TDrp5EO3OA+eCaxLy8wg+t2rpKG75Q g1lpA+HUIh9iGwinFg4S20A4NXttWOzgW71+lA8IlmadTR+cmrHBDFsHHwq9S9QPlU6upGuUgHBq 9s9YAsHSgk0CFAREvxYlssYSlVI/ON41Chl1YocKxC0gjJn5KXBnAWHMrE4BLELVJsamWAVhzGxM sQrCmJmWYhWEMbMopSpFYkhKVUJiP0pVSjXeAzRWY4kqsZfE2SKyNHNI+tAm1o74AVGhGTPiirVF YsNIJUJiIgj7UxIEaVxD+uDNILDGa7sSodDs86hEk5jlUYk2scbDDy5PjPBgoUrnEhsytGIpGaaa 9Eul9l8t22WUiNvMhovKENCotZUjibVMrKyQtS8JbNS6Cu18yqJOrKq4VpNYU3GtNrGiwivhEoHL rKeoHST/ZjVF7QSfWEtRO6FIrKTQjqZEHsHsmfhLk1gr0Rck+WbRgreoJQOdICWUTEqCB7USQeuh sq7NBoTuMsu61UPG2122ldoUMByWbW1mpbQzoW315DLIVLTdfAnf4qVRldfJbTbCTuXK5N6bv4Tk hpy/FMldOn/x5ufNXwoEE7upRrv/ComoXVGjFV+FVNTuptHgqkIyapfSaNlTIcKyaG/cTj2JEeO4 nWYSQ8VxO60ytNoO4ii780Wz9gpxkl328peg4px9KVVPjhFJAYFVCG92fYsHo0J4s4tbxK0Vwpvd 2FKtkKsgpbUQ3uySFhe8Qniz21lqJxSqWrd2gq6GtVOqBhwj8QL9qpDnjFH7APlXCIEx+F5AxYfT 8SCNQ/tmRHN2jYYGWRXiObs/Q2RV1YWKolYrqHrBauF49KqMa1Wqr7VatSo+rBauod6Kca12EsMT IvhVSJftnojm3uaTeENE64NI0q6GaA2BY4x3QlwGZxHSHUTEaddAXKacxPsfbgdnoRc/tF943OzG h2s1k3jVwy3bLGq2BamRt7QYdfyl1l3GAHOwUDUiYbvuoDLOT+I9B5XBM2gXHPwl6L5jaDvAGrWj WYiaHmlYzSelSb7QudDAZYhIa+QpTVvOZagd0W0juqsJwlWpjSi6JghXbTai35ogXNXYVIsgXPXX XAtnoYprNHGqCcJVY83tYO+qquZ2qknUUXM7BFGinEbjsxrxsKmS6UvpE1UxfwmJhhGNomqGcCd0 CoZRExyqWg/JbU1w2NiewngarzhBVz4PqjESmK8JEpoEWpo8V/wjMNbkdr4EizbUjooECHUNwYZv 0zJtokGhLwAbUeHBX2pTabTkedIQZ6g+E55C6flJ9NSgL02jXgL6pWgn0UOOv5ST6C+BBDS0RLV9 +gUpoHqN0JemUr5UvwSndEe/FEbO7EtQxlN6r2ANkzhogO8aZoGTvhpmaKtkNYiC1AkmaZhehKRM 4VOVBewiveVhSg/+4hJ1DX3xIVHs8JdiEiOs4ZcK+KWzLJ8cw59XJGl/f/gIlc0yC9RDozCc44Mi Wee/yeTg8SMbBXLxqOvIqSgkM2CSqYhFg6MSTkqgHqacTJ797ej5w+9ML1Vih6iqoiIxW9RZmI1y LvdhAyjVODVrpfUG5XUcuJXh0AxYpollmgytVa0MGzVimdrKIB0DTCRlVM2GZSopgzPFi+QJLx1f cRQ4RkBSvHJIt0b+n0yePC20Bp58vByQBWzwigQnRqUmqrPHq/qy0DVsUbwDTAIlgl024PIFXeaC bgkQ+SOfqUOkS1Va59LLEEmSHP4vnXP0SRqhthxQLKAS3CbdxxYhnTYc1rH/ZbhcgxvNtVG6tQGQ BXqDBblpYrq1aQFGoMFj/2vbTT5su8YLLCBJcNJDKaDJNzx4QvGzrBky17CEViTXIgoWBV2rAVKX EnSxNNqIHgG+raIipZZAvgImaiWsEWujJPGstW7C2EAAUnItwWboIwMpbKxlMdINgoHNl6ML9LsB lt6GSvd+o/OttQg/sdGfL2x/ZSXqkYEAr1ba3jR+ZCDA45TQxt8JLvm6M6RtFCiNl7WW4EvXkI6j QAG+bLQEX+SGtJcCbQTKVkvwdXJIcAeWQAlGjgdfK2OBoBiwosCrldMS1kSw01vg7lbe0I/FVEHN mPSDOkS04ShaK8b2JlRMJ01PS6DqqxJ4k5sIKuX1AHi6uqoSnOisjCEzDICDFyEVrPFj2ahSizlb ZSIKVVxlPxi6p2CjVVxm66xoY2dYpNAivh4WqXH2lW1FXgyLkEq9zq1IMxgL8OBQCoQKHUs1HC7p fEHK0D3Ph5sBGA+2nbGSb0mIQHkRSSSXQOZ45P+UjlUJHVNYivlyd4j5QedXVGl+bvk2rDJtv7H8 Wumk4SAOCF4mkN6StWYdT1yuJQwgyHKy8XZqKy1h58mT1qAWgGkmaj5GS6M9IT+LDCyp2lEfTypk gO5k8Lktjp4RkMCp0SBIVhq1rrERjHYJDTLmCQojXLAYKQiAcvT4ryaHYTlfxC32jrssTJqjEm2/ JUaGjdkXEjYcdudC/N8Wke0ne8vcIL9oxKAZWWYAniZXpoH5Z8QohUISsPgNRVwH4UtK8T1qt1SN WkCMqFUaA1JpKZsniDgwL3xBqtFSfLXcKQWoAZA0+b8aCcpHgAznZtSjrMaADPuzEn5s9jA7Ix5F NdILtmEEyPmxEgDKRgnzZmQccBwaI7h5GBtHgCVOoLaJUKt4oC3SI2lHuvA2kjQ/T+oXMo60/WZQ v4hEgxU7CHyufypcpPnOCjVpIWeElA3YQ3piW4IZZxiRjd/7RZD0GAJng+FBEdj8YNi5Hi0Cy+qT OddNHxMU6ZLXeT+7TZFgGQZ4JJUlwgDNtHWSXQwa9ykG935QO+IwdVVJs12OdOexsQE8e2PQyT2j DVYk1P0invSnbWVF2BenUySgNrxtpIj69XSKeFL3AqoWqHDe5DbFW01GXvdagHXzeTKXhtRhztg8 0efTtW4sQuYJetydBuCMQ2lIjeRMdmA/UYJukx2QEu74IzhJPEzrVHRCNTc6nKI7qpQ018YiFZ9w fo7M4FsRG8RZ06cSFPpT4l0I+mKi05dDAsHDpsszxLBRjHKAMnb8kcHw6zt1Kk6hsykadlEhbp5Y 6K4g6XI08Nj6RwVBtuSrU+kHzczQPRbtsdGBlkpTP6TGH/SDTNXWP7pcPh/24/j5JLw2cOSopdiU /WpRFRClBlQ04QUMzN5K5VqqtiZrugNxTgkou/Vua6ox4AxaqrSm2EUXVsAKWVORCnDUA+eC9RfG B4XrqceFfZq3DSoeh2K0P+RiDWHz01Ej/eEfPb/skb2lP6f0mH29h4uAqN1ZU64eHRTKHt5bf358 UHiHpiRAHNOLtCXigrCQEgHxki/SMVEhvA9TkiTu90XaHRXCMangIbEAikQ0o0Kon2TGxaICFKl0 Rkcf4cC3WijqTgw/IG5AOChyJbcSh6PsCBcNu8HiRaWLlFkCc5SpnIa+r3grgp6uzvhyCcdRprKa a9mL2BWVNci+ymVHXAscLA1dWh3K+I9lP0st6iJolBSBxAVn2+CHkylrHmHwtg/WbRS5Qi7zsLaq eqSULEqwjQ/FSKma7oUc6mSkVDMyrkbaamxc1aBULTNsDTzyYUs1IjlX5qnycSiVOZ9qJ8NQLHOu SAsM5TLnOvrNoWDmXG1HayCZuZrDdjnTy0gEpg6/il7GqPev4nEfyGeEExq6rjQJzScyEtoC1lUj y1zSBQFeN9KSAzjwJQKyeamgmjJRhYKsCWvs090V1iq+jKA2XVGquMYw0RXXOkVR24MCm1okdAQ2 gmrUkYrIJmYMHZHNWhMlSqM6cJHZ4vS7/TbdP0YLhsJbzU+Iuirv8EUj24DL2irzEoYinCOj2YZu V1ypope4xPdKVhTPC6PLubI2hmgoymFkOqSFeFWi5SQwQLcc3vxUju61nekE5HnOAWzSfI0gt0OZ jmATZxM6nODIouBEjP7XA8mOjwK2ZJxpORDuuBC2ZJQ9DOU7GhOurlHaMBDxeEx0wZWcXz+U8gDI 0wM+FPNc7dICI3Je7dMuhoKeq/OI/oeSnsFrHdmLoajHpVytWFiCJHZkMDywRMjqSH+H8h6XwrZq oyFDkY9L4SpHrmAo9VGplpBcsgauGaCVJl0jNxDOXJMssmvDsH6Chl0zkP1ck0h3LpUstX4yPol8 2q2fCI+uGIp/qCxgwU1ik6ZSGa05xR+xUhITtluqpDiqDpUoUqoaCIG05g0avpuoKPFmO6VwzVsi CSoAlGr7nVz2NVnnPynKMYk9thVlBQwstv2PIByJZlx1JDWU/B0/nC0lLYyuTyU1T6/GYEEVPSQw sEslNbxf9aSaKygqsHcqqdGOUHCfRFJDS6/tf2Qw/Ep21ZHUyBDBcyFu3ot/U2dV4Nht/yPT4Jrc fmT9GgrFjOYGyARTae6nLkf6YUOJLX+0n7oc9IPGFGiH5iWUtUv0GEWRKJJbq1CkBewkGcfj8zIt YEfROB5vYheHicZNjMILRvTGI+JaJQa8/FSqtj5qCgruc6U9HKV6W1ONddhqqTLOhyJOu9ZG5a2p Ks6JAlb7PFihdnxQCBZKoThE97ZBKbbmR+SH/aEviYmx/Ir8SH8VHh4txG6ko/35XHkXDl0+XAR8 Vs30QkXtRweF8WJMAi/qenxQ+EfRvsRz92lLJb+j4J1SIwku79MxlfxwgncqEkjUep92V/JLCd6U mBJC3yfCIBfCwcs1ugTT96kwSNilwIGLxChx9X0qDBL6QThwrS35gDFCTOrJ9sNWvB4wRvjoED7L 5O3+uKgHjBHtXY3xyE2glDcyQirMeHlmAwUUj0K48Pfy2siAv0edAbIyaA+MUg8yJfi4CD5kgk+W eB+sO36CI6TyqycnqZZeRPE+oYtF7vt00yN3JOIA2953xQHqjrp1PAzfqkjA7g9dkWBQHAVUEgvE 0aEjFlDJwjQX/DJISAVsfA4IeTZ071HhQZwqOsJDt9+4Oq6yJm110B0G/RzRT6bQ+yF9Aagvawwm RNsR/5gwL296hFSY5/nhHtZ2jOohdBT8rA36H0mpYMM2AZzbwQ3NrS0/UqplKAtaSl5V6ZaCEvQY iWGAYmRUlbRkeKJ0w1K0LCU5PunxLkdKCdyaQUfhB1w/HbiS3udK8fzYgXPkRiUcC3tMdIQuT6Ev SnpAzhdW0g8FOXx8Dh8Ew+fpfJGnXFBP7MKn7VDxjLH9PBsMFIo4eiXxKcvQkLGZN9mrKAcSE+Eh mrEhq3IgtTIeKsnpKyFHY8sSyBFMye1A9mK0V5JzmBLuZrxQIIcxLRTGx1SRE5kWykfHVDXkWJaw G4aBXNyDFEU1EUXFm5U6bSHy/obEqpTlGbmJ82XKNHWuArWFPC0QRlowAzRxxeuIeF00YdsZojDY 9EsWZefEdMUufEySqEYVOqdvrBS2V3bwy1ipivwI0/M+VooIY7IS9UBQ83W6UtXQFiCVx8V5sls/ 3aswENR8KmwXiTxv9dPxuYEg5+tUn5cKmpqv12/yKFL3+q3mx0x9FUuF4T0euUajG7vdGRZueJWH a45Ov7VdG/oorcdSLT0761FYfw0f9id/uP256c98cfLF6fzV2fLVF5Bs9s9evfzgfbg8rwDT/yHL srqifx2as+Pv8AMnFbiWrAYJBICoBnqCtySV+0OWf/CRjPxcrjfTVZb9YXpVucUvi+XbxacY0qf8 uV9OXmbryQKtQpD9msDB/Cj/+i3/vm977/v9pu3fdJ4fan5X/d7/N9/y77Z23vf7p/r3Gv2u4Z+3 4v0fn5TU6AOlvJVOBIUyHKfkWULz5LenkOVtZn1tPb6ELE+bq8t8YQ8hy0vt8fVjDQcgDybHd4/1 cfda3nikPsg5oeaUPpJOv0pICErJu9Dx7VQNwFD3HwfVQAz60rfXDI3hoI8o0wrR5aS47jXyCh6N nm5AxVPb959Q1oe59Y1gGhC5uTeckmeF7dEWe1JbXp2M72hryER5INgec7EHtRt5Ly5YRsUpeYTe W4Y+p10P3tCWYTTJQ+bxCW3MkCWpLEOG0ciz3+J+GcMfcHwjT2azZUjev9VnAenOGrdbHy0ukldp OZatGCRV8pSvBEUo7EF0DpXkrXN7ObiSR36JwfY6KnTgTF6pi28cVxr/izUX8TlYSOkLv3SBRqvb ckqeWLGnf+2JV46bFV8Lthde5Vno+IivPrxaJq/HxjdVK43TFOND2OOq8o60xQGwFzrlPeRGgVPf DpUHHOMzjfaworzTXGYSl85eT2wi6Laq/iOn4eT91eRtPi8xV+2h1vhIn7wRqW+7xjf65KlDfQ42 PtHXRnCjydtjj/F10/TdxlziBdljjVpEAz6lrzbWUqOyg8Y17NHGYActfbMxz+QdXeubfSvQ1E3P XzCVEqaCHb/0tcZcQjTZE41axGf6pqr17DvRtwqL/WdPNXpnqCrYZRl5JsbHN4O+9Mcu6E0EwkYd tTAlT2/qw7iFPSErWIT2TcEHU2VCOJoskhAhHCzukKqkg9QLe7TNSIjEqNcwPJJyuWJiC+pU6ON7 itSNnFHKaSw0C88jKchQOkc1UEmqbww2ydPaFgqaMuS9eo3vxSmnYZULC/zFqWS4lWb4qjPcUiOC cSoOt9ZRccqGK5Jlkw0JoBGnXOdRGvBwhm86GRpNSFIxQ6MKSSpmVDaPSjOaiHZYt0UpxfYWfkhT QVB0DEMkKY1HGMMRScqa0rBEmtKmYngiSWmgwhimSFLWh4UrKjQcufShYYs0ZcNtbGt7pN+ii/do UGHxyPuk30K39Ul/budDg1kLY1VqHOZCI2kLm1TrUSs0KrcwPfbUYKFPDQ64CI1HLlyEPTRY6EOD Qy5CmlIuwkg/pSy0ecpFaFMurm7kIjBjwEVIUykXEZlQnKDM3M6+BlyXtVLWU1KFMaHKekoKM/pM aNFd3ciE6juKfSbU62OJAyZUA8fLfkQGUR8DVAbR+EANLq7AYJyjxikX8NHAWJKKTWmALEnFGhoo S1KxDw2YJanYlAbOklRsSgNoSSo2pYG0JBWb0oBakopNaWAtScWmvGE4DfZeJ69QFzZLBLjk2WgG HwHRpogYjmFXAK5uI4bjYyAApy+eG0tZK69ZxRrBcCJmCAIwzNBjW7lLQ69QQ7APh1XyCqKYIY8O C+spKfIOjDMPhsJrZSljJLFCjfm1RqF9cARrzRDOsVDYxaaYn1VOWVK1RlaWNTXCgjWY0TU5yauJ vzwVyaFXsA8NwqLst66u14DrgsKNL5eUSQvGM3t9ebEsu1y2pAzpG1/ely8SicR1djBKiE4WUahz 5MudLnsikfDTxzpzEYENfFxngjFcm6SM4ljYNknZBImcVES8cumjjhm0VpwqtakiHtgurbU4b0XR pc4W701SRiAt7pukdHUToTnoqIrYOa1u0XQgUcUmSWGGPIFuoyq7oyqN0JcdQm+Cll5v29aqoKUp G64KWpqyCUa1R6VAHSKNYj5HT62LDAtleNfJsOh1nIpQosKcpGJGqWfQBLxS3pj3OqBKO5eMXDuv 8k7nXK6xGioo8SY0uh1RsmIQbxTYTRaTO3Ji20WOcz5yUZwhYqKIjt76VhGhiXxMbXwMcjl9CZ9T WCSi/NpQPmZUkaY1Rr9ijVJHyynMKCPpYiRSdGqo3KupRqfB1+vqx0QZwmP0BJ9G5sf30MZ1UeiX SOs4flnd7dvYwEoyZHomQnHKZ5HVZdmbUxoiudCghiL55RrwuNDghpyijNZoPDfFKWtKgx2KnBqb 0qCHnEqa0uCHmtLRagxETVkXGgtRZOrYhcZE5FTShcZGVHWBF92CmPYQ7FacwSG5xZ6HMqRGkCNj NSqpUeQRJ1Af7PlvfbCNkWIlaiqPDBS/71x0alg8cJbQsY+EraMaedupEdUtznVmHjUbedVZK7ah IoQk+8Qh0uUu2ZSOUXNjEm1fSWLRpPsqHYs/3RXlTZeiKd/VquRZ1K8MtSqiaPBRgOKMnlZFdSma 8kOtilQoDNfL965WxXr2quJItSokXrfbtCqq8vFGFjlju1ZFMkSr4mwSPa2KBurkFAFCovNrlNWl DJqHKNWqgXrNlGqaqgVBm1JNU7WgdFOqaaoWImBKNUlBhiALIw6sR1Q8ZQ45klJMGBSWKIWTwOW4 yCiKaQyIXFucXP61Vc6VoyFjALY0wDIFVk2CI1NrSbxlirOahFfGkG5pxGaK1JpERm56oZMbM9mR 370SLYpP3LZKXyg8saNQqDE8MbrzFml4Ykfhd5PwxOgyF6Uu9Ln0RSJtURULaqtVykS6oipVIlVR lTqRpqhKk0hRVKVVUkrhiR3F502CD6MvWZHGK0YvnCIN1dwGnZr8bpFk+XcKopyEIkYPlcjko0sh xZw2ZteRt0tUttOLXhQNOrcPbTR8od8pDHOIFZoq5XkdOZ1EXpemXqQ8riOPk0Sj78kZOZGVPHm3 JSyrJ4eQhCOlCGgJJ4q91J0guhTLMGWUS3JPSZRRZdZaDG8pQEG9jedmr5dEAiB/nlRtVWUUYdpU ZVVGQastTm9FPn9JnF72cUpY0prcKxLmtSXfjYTNbcnlI7lRoNdgE9YLwY+GkcRgdgQoSchlR4cm CVPsCcIt9rEnY/zIW+CHvE74FvoQEmYCbYTzNmFg6EOZUGOy/W0Sgi7GwEmE5UAWy5ERQUs7io5s kZ5bstmOjBV9MIhs6OUPDsZuEacLssiPVy2hE2odQy4HCbVu0aJLMueOcdYAMra7U/SjrG11nyDb wMxtd5tA9F3vcJggbMsBXlyxy1Wiysb+3+EigR7+VGKHf0Q29v8Ovwh6N5pCW+RUcMQlQnxXPD3F Mfh/ly9EQD6FjKKp4C43iHKbE4SYkTXbfCDULGuXCwQi5Ri4Y8z/oUb+zzxHR50fqJFogj70fKCw NOZIPub1QCTGgrqMuTzUiCqKaITabBlHSI1LB73UWWxh6OZQ4+Eym9IxFweeqvUx9G8oKQ5/kVra DwaByMfsTUccG2rCAtV2r4aCzeyb7S4NBVnRF+12f4aCbOPNunrEmYGED4pLt82TgUTX4Ld7MVS0 rdFpZODBINH3omfCwH0BADkNoDfmu0A3fsHiM445LpSBY85l7RafBRlvToHnGlT0cPA+wKV42x29 IkbcFPCS3qOayeU7XRTQBHaHh4JETSyxZ3Gw3uKckJZEa+qtfgkVB03b6pVQ0cNRTiMfeiI6VWCD YkZuQFTG/t/pxGDjqyyM3JgDQ8kR6ZDJHnVeGJlsHf+vdnossFFD4vUzdFcoKUBgUe3wVSh5Z3f4 KVQEVc0OHwWMyN1k0bVoxEUBJ8ShN7f6J5Q0n56pdbcIg2oR/caakbMEp7je5ZaAIZApttpWnwRA ixisK2TmBD7mj4ARhmu8oSurHb4IGKKN7IfKcocfAsb9LBGpmNf2iA9CSY851tGLzY/NHmMR7/A+ oFchGsNXQ9cD7CWJmzbid4AYrYoB7EacDhCjtTE+2ZjHQYs3fKmj8Ji7QVFs8zZgdNOUu50NOvbx HV+DQmayzdVA53GFp0E8/COOBhFH2FKNOBlIqWKHh0FTUiTQaod7Ab9LUocdvgUNxT61kI1jjgXM aod2p1dBGXY6FaTO3SM+BdVul4LU9XvEo6Dj0DB0KGjanf4E0Yt7xJ0AVhgghMJVbvMlqDAaHsWr 3OpIUJNNC/o1bPUigBVGGSf8s7oQdO3/V7Pz2WIzW31YN4Dd9v9lVQNoof0/iqkBMlChUfhb+/9P 8WP2/xh7AQ/Ebmvxq6zRf2/r8G1W8L/3OD61dfxNvQV+R2v933Vd/tn+/e86/3+0/dmGDz/Cv+zt UpLuuDJrPjICwDiVYvhFhiMkf3GZYDlsd1WIGp/qiLlfabYPlT4NJLaRodDWgrSrdYpoT6gjECto rmM2tNRaG6+ZWTbUsanltI3N29hCUofkJR2bGHQ6G5uzsaWePWafQa2VSR0yX9KxNS5ah/A7WjY2 sdDSsbEihFqrohmYJxcQG0FiscsRdm3UPqlDFmI2giKaabAmoNR1q6M9hjdrFNrtYCYLPGouEyyn MWO6RkxbnViDab+a43s50ao/YBRpGjTx7WbkQW+5JeZr2A0z/tRNYs2st6OSk7hqeO2LcxL78o49 rgGV1SmtDgNi28r6szsBShOynuYx1IhxFoaZMxMayqG7Xcwpm2iOU1o3lJPantnQKCdEg6rSpkM5 PtpClLYElJNHI6XSlo1iEbNpYa11vI7fhcTthgwq6Wk5SPGqsSdSMDMRfJssj5Zp3uZJz5QltkLe 1oZy+NqeTgjdtdMJacxKslErU76dRw0Mey/RqeDX1AtOObZQCWbrFAqxSGpdkoFVCHk06rjFGdhg ILO8Vk1jJQNtA3gFnFhvSwZqwwmr4SsAbZKBquZS1qxJRkWvHZINWhvErFsy8KaCAKQt1Xq70kcv SIWJKSemVfz0q61Wq6vF30zBzlUasxniHH5ZK1CIYbVaCPFmluoI8LWWo62JJYe92CGmSRRdmAdt dWqrk/jz8AN4teaIwWupA/aymE6s6pog9hqECzCF4alfiBqZLTlyselwYirjtE7htI4Y8HirU1id xLGN9plH4LIEyOiZMY6Y36gTC1uVY3uEItBxL7r1kHFnCGqLnxieY+FApz04c5TJdYH5HQEvvhGs TUCyFog+hkLs/b29JBAq0S4yLucMQuNBUhiz3Noi9U4jylh8dMK6J4TOZpZowREHXJtRdk1PCBDA UA1VbGOqFdM3MbtWs78cn1xQoLDmKdWW0ZKtMlseSLVixuPFkjqwhXStx549NTCD3Q1qfLABM1DJ w9gC0RGmGB1hPAihlG0hmJpPEf1aqQ0OprRGrnSyCZyqIkHy+rQ8pcR8ly5XaTJFwSl1lQlmrZ1z Sp1rWrO9LjklhuSNV9vrWlKCvBE7MHbGWWIqtEb1eR7UW1VbHyFjzE4riSkhXniLxTVo4Fgj0kim BU7qqpeH1xqF9FZGGz6uUUjdOnpHcI1SelMfy1JrBKkr1t9VpTVq6a2M7ozeXqinGhGpcY1GehM3 lrrVGo3UrcTSrFJbeJpH42UetBUCQ7UAQ2FkjhcRN4Wa4tWtgtYgeKlqhZIq1xpkxF9X5ruLGXTI actKgyuaIF120OPi+FCzkGX6FWkDPSEOqVAbm0MjCHSNjBdfwVhN6jeEwKkQ3Yqoo8A749VkO9B8 CTEFTgkfQUtCRqw0VUiFaP1Nswxlyyn1bScNMJlnlpwSGsPHWVW4mPIRLzEA619iXUhv3vF1hDTq xDQ7aEaQPlzCRFFGpTV4z6tGM2qpK95cTakZjRQR41cCgVaJLKUYdhv9lUEPU7lxNnJbphkC1Por g3c0My0to5QMobqh0gzaKKzRGC/IGYVkiCmrby1D1tknfiHsiq/2gJHi8oo3suzihGyG6nwgWjXz 9uqxKPiPeHHOsBq11BCqXqnnIJ8UzIj+qlFUoT7E1NSgxCmUlEwNnPQbGJ+WYonJB4dYA59zilEi v3OJ/fAr5C1bXPJvhIBKSZVJedx1DqddZ3zM6NaNzjOVx1T8XjZ6nDFMIn8n2uD0Owad4mUlgYmQ V+CUS74XiqzQp7eMZM4bP45vopdGgmQfKOVVJjJnU03FHHa1obtw380J2pqkYk5hdYpeHWd1XK9O bnXyXp1ELFQjNxX+fNYRCeooZNISGEdDdQaCad2tkygozPazNGaaW6uctiZ4w8QVTsU6pY26tFEL z2yKg9D0cirtJ2hrooaIsmRw3TqdWBKSI25BUd1R9HJsPoW2JgqKKM36qlvH23y8zUeohs3HNb0c m4/T1sQdNcrTznXrdMKFSI5ASFSRFL0cm09u8/FG6kTWrzp1TPbXVB1VJKY8sXd7NUfnI6laFSGJ TqFx3Tp6BDVVq1Nsa76vrVRphYCYf21jK8C706qVu6TsjLCOIzcnkajtSJlh0u3kwgyT14hk5Jzh hF9TgiYpZ34dzmgepZxXEl0Y7S50YK3xawnBjcb5ldWotIacTyPR7H3vjeCau1ojCFd1I6x1IKlB 9Q+Sw8yzeR9RHReFh8KcooKKAqZe0VRtihZWwRCSFmWM5pDYEgUYqtNGLJAoZ2pTzpTKvpsCx3Iq y6m0Th3PeqLQqU2hU1gdVfpoTrB+gtM6ZTzRiRKoNiWQtzrexuYjfiiVvnCdIp7bRHFUq+JIVEoE CDa2PGIBftvMxubi6UyUTbUpm1oTe1QhZTmV5ejYRMgxtZqkalNQ1VZHlVimukrFK6kjLGGroEMp +CpyPa+/QQlmJEJvYaI1ZiRyPSujtUYi1xdlFglsKtcXNEmtkcj1lNFojSiDMF/IKZNUW9V3S0oz JL4GbWWnRldDnmYUVqPo1kjiUnRrVJVmcMoyGiN/Og8ZrukSJVWrLpF8vSijrdMMtsZTvJNmeK0h KcsIViN0a5RWo+zWIFUGu4y7Tga77BCCKbs11EBMUrpR4n2urhNxayUqhHo7RGAQkHIGXAY+pkiS lAGcqZ44ZSAalVWcMqCOOhNO9RBloqmtRzS1nDIWKypkJdUIMRKXzkoXJWZ0wlilGSFGEOg2VViN olvDWQ3XrZFbjbxbg33rSeb2nQzVg2mqNo1YZXFjOBVzSjWYlFRSJ1VuUU6bUA/KKEMnQ5Vq0eW1 TfjR2ihlktEoiHKqVr2bOuRrqla9m6rhNKUZjF8qwzR9RWFlyKmvKKwMn/UUhZVhwJ6isIrqyK6i MNLiqCjs6CF5wKmi0Gi9KQpNbygprDG4UaCUFx25/NqMXBzkpbFTnbuGvit61F+afbcBvhPVVGvY n+MP8JtEL1QaY9rjNYeXhUOuyBGVHFHeWJ3C6iTSGFMZq5O44lNObnWE09U6nKIcb6eFmcz+/UEr ayUpfOVDVB/s704nzEmOjyDOrentg945EPrnGxzPdYQ9avSGQrxyAz1rp+gl6Ew6Vw6mE+VUMrTa HMfrWltztqPcml5Y6DVFpWofScUAGLk1lmtjuSE4aax3UROsm/7dSml19F7EqUdvqf3wDRK/nUk5 hQ6tLDpDI2GXHeRtc+rI8DYGvsnalCadlHk3hx2xVEHLOUn4ini/gDm5M7Y2WICi9KrI7qokZYMu bGhFb2iFTaew6ZSRKEbhKqnjbNDOBh0ivWyMXiZ17DV0TlFOEUkp6ZTbbj8sTzaVSpaUk8h8rV1w Y47oteiU8TERMBSKqfdekoo1ar2PkpTWqHKtoZeIWoNIgr1eFWsE6yP0+gjWR+j00dhBa/SgifgW DGaDwXni6Z4rdaQc0X+WBhilAoboUgubS9Gbi7e5+M5cnM3F9ebibC6uM5fc+si7fcQ7R0klOdqW pILeBeqoJKXfG52hpPiBWMWz6e1lsNvLJlidMHavSQJ/273X1HtOTYWYY6uf6+rnEpXQcvRWVO9C 9W5UUyHm2I45m08MkcU53sbWGH1Kb1ZDzLERFAYzTG3VbkJTrVhQBLqEIjJMIiXsXFtYDdaQdA1F 7I5QHPKjgoQgixBszxRALw8lBcIKs8R2zysp9H3gpvSeV1KYwaYAes+rqUoYdbvn1VQlrL3d82qq EmHA7nk1VYn4YPe8mqpE4GCTAZpg13iAjQzKEXOD0mr0DBRKq9EzaQhWo2cEEaxGz2yisBpdQ4t4 ScspqNG/pOVUm6tkyDewrZyUpEajBjhe8bRqH53KJpSyGqS6YKxNqVjDaSsSd9NqJBrEolODmSel XUmNoEDNqVijVARhsadUvK61Rll3alSt1qjaTo3aTL/q0KnBSCuiKctoTFxrqu6yt4KcOAUZgusq /d5WyXe+XeSLhyL9XtiFRJGn34NeqHLKvtONELPuIf1Ol06NBrCJ3+mqngSvrhFSeodPqUYXqbUb 4LZNsYtd6UuqtUhbeqUvqdZic+nNvaRaCx+nd/2SanMLPqaX+5xq88HlPqfa4eU+p1qNCh5vuDgV d0gv/SXVjFz6K3T0L/051aTRyuRu30tGYdwrZ3CqsbBZdlPPqUZv6pMLedkODW5u9+5OAEpjwUWL A8cKwSRcodyKyaFUw4JoP6BnLwpWYiagR6wxAYEzFMqrGGtacJIT6Olf+tcKC/1Lf041I5f+AiRy 6U9j4Zt1Wd30bp8yalnd9G6fMlpZXQ0MWGtG04FQMSygprRzkefsilKhpBKKqTU4hRm87NZ5z6ov 5I3VoP1QixwO/GPBmvGksUqdbNMko+JckcC9dd6xtmLzFeo7D52DRsiGMpyCVQyDyxnepSeQ0RDH XpX5qZa9sYymA4hBF1cMIho1gyjturgs08PMqIvvhQUW9OZSV6SoO6dcLCpU50Q1SpMdJKNNj7/Z g4iZYFDLELMH4RRlCO0VexBO0QYyD6H2IJyiGsyOqD0IpzCD18rsQThFGQw9avbBKWpK+BQxFOEU ZSQhg6MlgtN4TUVuhhN6hVWEiODsL8wQy5DElkQYe5E0zahBDDtyDXIWzTmItGAf8QYpmnNQxsCc Q0cVg7iJOYeMSnUAZpzBXpK52XmYxFAKNyuieWIAIp2rAYjZRwRZsKEBSCW0JTLZkhGkj6g3ipYh 1JQoAFWPJykLV2hL4m1JCqshGbK6LrGcMpMRyiitKWLXzQ5FrE94hZosWpWoLYlO0OsiFn0jE112 NTIJliEzVyMT23Oney4KM1tdJ6urMqSBj5MJDq1PhLXUOGCKAPpmKdHMJAhCETOTQrFIz8wkKP3j g9akZin0Xe8yQixfRvRjZinEdxOGIz7GzE8MQ/bMT0plbdXehC62L/AOT/UTni6C8V3wwqz9vZOQ T+rs4em57+jIESQClLpvlPTGdrx4IlsB1fRAfiNxlczZIpfIS+ZjgW88u0niQIFe1THyWKAgX005 SVwf+CnnInpJVPRqc5G4QOBTzqq6oXc9JTaTuiigzwN90Jt+bIZCbuk9Pq5lW06i8Qt+oAhaaidD H4pJNKmhD15Ijn1wk2ioQx8s/Jh8KFubS4XHmOYi068oihRN32mJRlas0BIavCrorU8uu6L3XBiK qaSATy754Cbx7ow+0Mb6+CFY4DT9YFHM9EOd3PHRB4ozJdeEFCMqTOKFIn2IIRbkA8Ucq5MPFB8s LYEDy5MSGMzLrkjpQ4TZCg0iGGgZqis0UmCo1pssfPmWtlJvsOhDOYk3V/ShmsQbK/pQT+JNFX1o JvGGij5gt3ozhR/osKiKHQ8JBdFSxTZ9oONVxg/ewvzpBzeJKmLk+ZyFEdQPuISqescPHLsrbRQ/ +LRRGnpSgqLiqVoN14XAQTVzxHc0k6jcow/VJOohWUM+iapMWttmErWhHMBXD6F+CIkGDuXhsphE tR/p8NtJ1BzSB4L1tAQtUFKCgr3VSYminkRtLX0oJ2os0KD84QuLa4fP/jh6/1a04YEkLXw2N97q 4nuEJa1p8qEodOcABOlxUDq3yYfCgC6QRSA++lmYPwB+oIHpNTS9IVkkjgE1P68aLyzpHcNiEu82 6QOFpZP7SXrtEBvV60doyxO60NvFBmOqtsk1GaANT6HtWASmm2sM1BZVF7iUrcbcsw8KdPYhTKIO hj74SVTj0Ic80QThBwrkp+oO+D9wlMlgHwoOQ1knH+pJVM/QB5ytanjoA0WIqZIPLtEz4QfCuKpM aTC8lpNza+Ogk62qKQdYx6nghpGJHJpK54knQevkg9qQ46VWQEg1LwQUBuIHNG/BKFUEzOq3gGeT MGibjC2ESZTVoKsQykniMIQ8ez2J/lYYc4qOjDoRUATAVj/A6sM8+YM6DWDAPyIP6v4Ah5U/qHE9 ao5DqXGmaH6wr/xF3QJQ8x3oCKipThvkg/oBOAC5UNb6BUbb6gdVJqLOPVC0TPWOaCv+YNb1eFkR 8IibogUv4wIiH7Ond0C1A+EFNaTHC9BASE4t6B2+yVMqAUcByeErbiUxDmIzj7dfoWwm0Vgerz4D 4gIzVUajpxA0DKl9ya2Wfam1L/uiQRfjl1LHbF9CosjjL0Wi8uMvXrnJUJJJV4kHyfhINAwruZZw imjghr7AZxhDr/AsuQAeyPa/Rn41519D9uzoB4qQhruOTy5nB7kEUfQU6u/R4UM1bKTfHx9+q1cC 9PvR44cTUVrQ7wdfP5Ore3wRGtp/ePB4QmptKfD10XMsYBUe/vAjbn1r/dfC+MmvlfBO8mspdE9+ DcJryK+FIEr5VVkk+dVJWEoHWIlDlzF/7tJoO6UF4hPe33XCYcGULLAZR4wFfBxjqWGkyobj0nmO 3Yo9FzFwXZ1pXCoRtkIacYroJEW9DRYJKx+UwlOMcQ0l1mNhklq3FK4DMcZaSiSsbo8OB0/MsZYq wrCtGgVV4mUtqpYbtlXhMnoO28ilWArslMIX/Ujoxsh5XIoF1W4pRMnI+YY0TCWfWp9EDwppsCnW anSy07BIrDnySUisMm2cVVGd7LQ267bS7FClgY2qfnaV1BYlYqd2ElRJlI+d7M6b3u1gYp1wUL6f 3YmhxYqxzsRcOu9mkJ2Gg/JukJ2ueR4G2emyNIM1T2NNCansZCdbIgpIzKZIrZifzjuuOcIsV08m LorNTvUyWXVRrvokilrl0uq2rPTWHVVv0uq2cBZ+Ln0mPcSl0dE5DXspHmc0NIs55lFnaC+Rixtb twgFWK0s5hg7zXWKBPL+qiymH19YdIqUxERUFsYzNMMi5FxWWRxP9hnsFqEQvbUF8mRHxG6REkUR C24m3o3dIqT2rDUWmzgjhTRcY0uBhQsJNylXTK4TwTKnIGsczY0vlDog5VCbXhteZ98p6qOMfVQU K1FCVpYjJVBosBB97ALVL+GSAKvs7NUvkVOAVYk7V42NA+iJBRNkp7R+CXRNS0ObDkvUafBTm4tF 0Kvo3gEjrMqS5YMiNUacSyLj1sVYERSObChVM9pRQcFeY/jEkVYcxVCWIm6sFawYYwG3o60UFJk2 hgseaaWksJuyP360lVKjgk5UNzlopaB4mDFy8UgrVRKXOB+ubkV3ExYyU5z7+q0gU2tA2ww3oKL7 iiLC9XDpanrg1QIHi+K23wopshOszBEAWw7aKGglyeabH8o2nC8diDlDnsb3Q3klhq4M9oRQLIFy RQxdKZYPnRIloiMLkCkmEJ0SdBliQTbFFqJTggL6WqBOMYrolKALPAtTKtYRnRIt4t+6shKDNlp6 aRAEUuIB4yMaFt0Y0BewjK3XArRnWN/itlKEklYDlXu1gCX9twQVx2c0tv8R/pOtwpDHtri7KHw5 MmLyFge9GGkeTYm2/tF46IU274wBRF9e5BKtUBELKYl1dI3QoKyoYyjGxlBmO/5oTTe2ODiArX9k YM4Wx2J+OnpWo+ZCEre+HTaPCu3tf4w9bq390ibONnWO1OQWiJ6shfp91NmOP9pHCNZHZX2w+Ixi bVKyjiWDlfRk++dIQsiNFY/rUljJhiwLUTB2rjWERHfPVNLi4TtHL4cYRuInjJssiR4rZSIVdNZO 2ytSp6SUizS9Iobwg7VSd4sYUWc9LhXxKo+hsSgaQbsYit6ehcqqbkORFhZWxHgU1Jag21LE+qUN yNuSFw0Xini/HR8SPtWR2/TzsKUULqsN3G1ri+wCU8I4WgrpntHpsK0thC7buWpbWwilxo/VVqrs LWjkHNrhWoWc1yqGtG/GewsI6YbO6pHThA8pbP9jfJK1H7rjDDEyfzEyTs/jtBGM4Wu8mNv+B89e g9KOKNbxP6E3Hq0BG3rPE2NWU2TrFifshB0W34gyS6Kv43gK48vtufKkQEtODviSjrwV0aitQxRl 0G62Qg8R9CtxIT4rkWtRE9aBXcairRTNtShbyLuU32/JS0aL2lMCYq7t01ZplIikfCc4ctOVH+hh HDwLJofEluq0EBmamzwTW6rSQiU9FpTIRVKoTAtV9LqPylexpZAWwj0wIYz9G3wKu1SoocdytCW6 vuiom9CXCz29moh1nemkEh6vQcRueil2r+yUAbaszektn4nJlnQJHDk8dLlEh0x8+EnR97Ah7AzH ZANqhwOqKNwyvpE0idGW+51RAXp1SvHX+MxKuuNWTDg6M3rjMFfCPjIzFDCAS2sN4fjxiaEIaIfd j0+MPHelLz8yMYz+X6JnleHS8XmRb7Bh5fF5kWexvnszNq+SXI9boxTl+LxwfWKZ8XlhU8oclWPz Ynfq1rA/u18P+mrpAlwReznaV6AXtSYR6vt90ZNbWWvr04SxvhCiqyihtqN9FXRDz32xS1q3L7wV wNNhqIFdYLCQ07PacgxEF/Uh+iZ1elZrjkrZVKkCZ1CITDeawlQiYw2VFNGgsSG5sYY4AmUTsdVY IU8xJZr4wsNId3ijgPeIsiMSrKBICXae0eRUqsmj7jfBZrWj991UNUVm2lVKdjBMQqCltBWqdThR RKkrivSAlheK9v1IqZLiTqDBhi7SWFuBomCgnYci/rG2CorJ4aq4lmNtcaBSF7Vv1UhbtJjkKdh5 4IbhKTINgWKkuOQtEb6bdR1xCmEuIJx3GCVPz2E1/bbiUzUcoIVK9QA4RM4z1zJ2WnTl66iBrGwP 22QPKbKErTsHwahSokyFAtn96ObEluqkEAdYTZWMUqhKW2pxezqvpXChMi2Etw52PKvYUkgL8Ttx nTcdqg5D6em9D1fHx2vCcMUV9kwPIOFTeqUE9uqoERxrS2Av6i+LsbYE9kyHKYFuepAgsIfa1Ju+ YoDx/x8++fGno8ff7m9+3XyUGPO74/8HYKVyiv9fAbFBjxuUYEN+G///U/z8y7/gHnz7+EX27eHj w6cH32c/vvj6+6OHGfw5fPzs8M6ES8DPX2er9Xy5yPxe9r8uFzN8FNHdmdyZZA+XF+9W81evN9nd h/fgc9PuUWb2zWo2y54tX27eTlez7Jvl5eJ0uoEm9rKjxck+1Oz9ADV5Pju/OJtlP55NT2bZ/ezZ 5XwzQ6Kzl329XG+w6g8HWe5BELoPsk69l714dgANHb6Zrd4tYVDzdXYxW53PN5vZabZZZicwtmy6 OM1O5+vNan58Cc1B2WMYxzlmzmdrqL58mW1eQ9Wz+clssZ5lp8uTS3wJYy+DCtnJ6+ni1XzxKptv sP3FcpNNz86Wb2en+zj/f+EV+nE1m54fn81oSbLnr2fa2jp7uVxl5zD8bK1rgX9OZ+v5qwUPczP9 BT6+nb7L3i0vV3cmL2HlTpfnmLV+TRVgCjQOmOJmP8u+fgejX2xW0zUMcgOd0RbOFrPV9Cz78fIY +r4z+V6mA4OeLzazxSl39upyuprC7zPqLNvVF+bdmeiw79+HMuc41PUllMNubUbQBxamucLqwCjX 2eUaQGYfF2MOq9wdXaaDm15cnMEuYPe0RrQXsy7s3JlE4Pl8nSzjgiY0XbzLllBplV2slq9W0/Ps 7eslNn25eb1crWGlzgEioOSdyeWaNxJGdffZ8nwm9bZBamd+J0uAHFjC43d3Jrrk38+PV9PVu2zL 5OaL9WY2Pd2/l2U/LS+zk+mC5vsuk+HQBsig17CRy+U+w8/fXs8W2VtY34vZ9BdcE1pcHc0eZuGo VrOXs9UKpwTLIBu5hxB6Z3KxgjHANJ9AD+OjWw/AMN3b6QbB487k9fQNb3UCJ8lh4jM0GGF2V6Bo 9YpgAlcMlhAA4g10ns1fYuPZ2/n69b096wymczKbv8FWLlcn2PYpbNCKlu3VDA4fTEtrAgDD70ld LCRQ2wFMqA9wmMEoT3ic1MoiW8ze8pB1+R8wOGl7iO6t4dMlNrrGpmGx17JJz5dYeTM72fBJIiS4 ps1ZzJIVXc1wuU4QoNbcAazI8fz0zgQgF7EWLulsQYdf+uGmcPAI3+tfOGuJm7PCg7yiSXIpGM1z rtTpB874+my6odZPZqvNFCYNJS4gc348P5tv5oKasGle1juT0Z1N13MPxySbcL48nb9EWJb1+Aay Zr9OEYPvaZnRBteXJ6+zqa48LNjrGR7DOxP4dTOnaRMeyV7OoCXqCuh09mouoAhwMoe2FrBCiGvi UtDq0rHKEG73+dhR5R5sQ513dOD2DOoSSINcRHsGhdDQAQCHjWT9GoADCp0rWADNQbxEzTLoQGoO M7ItolM9GwMYOAab19nmLezuZnax/jK76+4R4WKi2l19gNE7k7v+HiwjHH2BmIR0vX09h7XFlVpT 5tnsFRx8oolrIt9CFPc6ew2tfkFEijY07VFGfnC2hpXCTZlNce8IswIqlulgw3h6YFIM/3Q+Ff4F +hAHwMrPlFZfIhwD+7U4XdueMKZdLKGBFRKpd9QnzbBLi2BHjl4OSBBNYE44Gr6fz7Cb2dmaKcXF dL2GLGQi3kJLgkLWKTTBiGXzYDhvFU4IlpT0Y5dL2Jn5Ynq2B53IrJAGwWIAA3BO1Ha1PL084YEQ icFdBlDFFgBpnyEI4GYkjQE2YHr1OZS4uNwQAVLI+QZLnL3bo35StIXD2rwG3gPoO3QHTAGu6AZI DC2B0s8LzN8gMQYYRLRLeOXNcn5KYzhFvLniaQOJU8BA4gnHdSprb9QVZzJfnM7fzE8vcVjZ8pjQ C/dijA8ggUU2Azg9oeNHZOp10g78C1RqBgz4u33BpgAcCDiw3wRGtPDn01PkerKTs9lUxgiroHPi A3ls7NYpQ6kA2efCliAJgM+4/FZuSnzcfmTYLhAS7DQTAVvCLBmfYqt4cGAWexGrCeDfmTDknTDX 8HKJ/CG0/H8p/7yLw4bs54dPf3iWgYiXPXzy+NHR86Mnj59l3zx5molstpc9Onr2/OnR1y8wiwr+ 8OTR0TdHDw/wA08h3ydOa4yzEuikVYd5MNPzdrn6RfAF8pKwgcClTXGNkERfIAtO8IsAEtHR6+UZ kp/19J2wxOfAtcLyR2wCq3FpJIrXUhnscUZkn5f/sx95hJ8B2z2D9QMURfyNzYDIRjINnABhRIDQ z2g2x1M+4dS1NgebMwNamM3mNO0kCxvBhmGw8zewdQBs1AwPP875bPr2SznncxoNzB465sKydgLd naazi+WKAILYDpiPDMEkEJwEIv8UetaKjY2CnyJCwSVYMpU8g9N6OX2F63b3O0CZgBtewjrvWQ3s kpj+k7NLZPqxj+Ulgj7wwZK9YCYW9yf7LO3/M+RWDxHLy0kh1Dc9PQXmgY7NOvsMKMtndHAOAPe/ YVZiKauLfNi2c9KZKLGfxKtGzprBRODiAWNf4uIuN+s5oQEgs9C8wswU8ehLAJTLxWAHBGErVzQ7 3RMOj5oDDAuoYXmeVgHGMLL5ywXy6S+pS9xjIhCEX+cbopnZAOTuTLTvu4AeZxfIqS1IpAFEhsM7 ngFbT/gMpjoy5nuwqH9jZigzcFtdIpeOja2xHyVLNs/T5UzJhNtnhmf67jqSr/J20tDn6w7Pgxud MuXIbc8XdF7OgURcAt8GZxFIwCxyzbiVi/XF/ORyebk+4/4BDRGeB0CGLxd48oH8wESIk5BhpqWw ET15goxkHidn0/k5LA2MW/mDB9kvs9kFHhAEBeEG70y43lopGrJKKGZ30CMLj7gA0+P1bAHdIK2D 6VnbyKCfMtsZZcyEXeiuH0AEzUaRnXQEjZwtYZuZy4vFactst1hSIo5XWB5Awa/freGsnAmU8/FW gY87E4bwnTQzFcZyeSFoBydurFTCrCFh/lWFfGW1BYh8BCJhCKlNnttqHHYUkwrCuzNhjAdFLol0 nvOQtyLpPSG3DLMd3pSwfhdBCu7PRsjMM5mgg2U/hpM8AqQAJcCpn89mDC88kfUsIfZf8kJk2fRe FCBOppdrFj+My3w5P2P6egJLTOsL88QTL+DHjawR5dI5V1GV1p0xETeheOkU5TWBQi61r0M5HgyF QBWXwRpOVg2WSI6ayMiI8LGdt0DAKZv4tdXGaD99WzMtxLn1cKPsMDdCFYldX75EKarDfwHemEo3 U1wKBW4kYXQ+56vT2AzC0jZ2QfkDXYOTe8r02xYoO7AAGCNWFFjhU1b5kGCBiq/VFKkUYB9dAUDC gHwTyZIXFAGWMlEnjGRXMTSeEARDrp80SXzlfCFDQu3V6hSo8QpxCImXML45UoAV7g2wVAjeAlqL xfISkA7qGYVS0xnpoMJsFBNOuQX5sl10uouMMEg/e8qtGaDImZCRWI17UQVCujvCAYk8wOCvS067 xk30D5BQ2tnZmRI4bC8jqXmZvZnP3vaQJTcT+cG7h7+ezAiJfYk0uEPWN+vZ2UtVaupGwOi4DaSG RPcNIngLWOew6Kz7HmO2DlayCQ35iP+8nK9YrcNN9lrbv0cMv+piqPQ5KylI5yfExkCXuo2HhSRa 4ECQZYACUxAls/VMtDm0TCiTUh3mm7Ye1T2mW6jMOMaRTNfLBTRHKmPkolbEUUb+BAuvZ3AYEeKw h7Wyh+ew1G9QkNvgsUjPJO8w8kZ0ZPdQRUaa8TjVJdI+mwEdrB6SIg3KdN3rHNXblxur0CEGJPBP z5OVgeqEjUhOZazDMs183SE4QJJ6FIcQbsqgCknjRlSslFqKmESRaavAmuaoX2FBkTkF5Z9B9PgV 1e8CASAGwA6vpCNlSi+JkLB2BT6QAMszW81eTVenQCYIDKBS9hYJuerdnkPVveRuAkdL6v6N4VFZ LKJUyEIl6kXibNcbUUWrFm0pwuEKL1KAVaDxsk4Byj3IYLNek8AR+yLBCKb262zFQrQq5VjjhBqR s9ElT4Qv1BOfgOw8OzFZbD3KLtDEjxYolcz5Rukc8d/01StcLG1ZBCaeCy7NWFN3Jn3GjPAmfdzB sNzD36fZm+XZJd4ivETJeb1ZrkAsE2wfJ8nscsRMxyvFisn4BJsSgKOAs4UIFrs5/P40+jMgKZTJ rXJK/h5SsOXx/0E1jarcYRtPLjeEg5B7G6HQdybP9Ag6GoXPiOHaxm8BfkBtnJwx1pDAMqSs1sEJ kO0LZGsAmm1X8NvZjGjhivXXRCjP4aQAs3Uf6f2U7t2I14ryy57gAT3IiYJiB+MolKg7Jdpq2cUT aG55Pl3N4Thcqrop6iCRJDHn9gDWcS/h3oazm9oBI0Z9L3szPZtzg7ByZ4C3N6Tbk7m9m01XdEkU JRLipQhLvNsTPl6YrQVep7GyeyGXisRByRWbihZIHmcrZdBl9VLg3SNCzTvATfQXPqHj/T3q7AZx iUKjr7cV23dBJvObtuJkG6DNF7gOjD0SwZcYWqHdtE/CIfSuwbbMG3kZ0spNz2A4C8Zzyu/INTKr Gl6SfnKBnCuiUBD7BtoTVUkQVcQGbIgpX3b1aaYpR4Z2agCI8j2szYpVRtmzy2MlHce8CcjjEIvT uaN7GTENq9p4OHQ5ydtybsQVC9GFoGiEu5IdrCpdzn5D0kY6cFb2GTLg7pFcQP/cqV4FDUYG36GX SxS05lHeAcnw7HLNMs10vV6ezFXVBgcCzQ9OZy/nizkrdFFKkwqMoVfzC77hPiWypwQOxzcXDRwx SKiOPzubpvxFnBRM9DsAgDe49MgIArt0MaOtnyn7uzeYUnp46JoRSYqo+uhGke4oTX1kbHBa7y7K /6yLlKZhnY5Jcrkzwe26F4/F+fT/EJ9wDtBN3OxdniQO+hcA6dkZszBrRPD3ZJLAbQFeYbl3/W69 AT6PVFeIkLtrgEIWLO3lghgcGrX1BdwwM/tTObCkzu4uIXECLwdcRdIB8mPJecBrItHAEdTDEGHZ Tk6oe7EYIY56KnfjBBakDhc+WKtlyOMDzqaR9loYAKLy6MS9UmuQcUnSwTphcRM46WBPvBhBnvry 1esE68/lEl+0qOcXIHElhi9JKz0dVLIgfE2RZSFyFghRrF1iBRAIkKSwZ5Y3ZW86HAdyfwi2CMuz Xy9QX0zil/ADiukTngavVVFrBfBxATMgdugtcY/LrQPY3j/hVbzTYoCka6rpJZKIjdA6JDFz3NDO /evIwO5M7GDqOiPjTfdRhnRZE0YLolf/tM1IPIydSzSOdgOoNhXzVTQSsqHRSaLdQsmIkLQOAeRJ vGaD/19enjGyOZtPQfwU5rDkLVT5MJVYETwvNj0Rbj1HrafeljMUiTUIYWFbA2SkCeDxLvUV6gpY N9y9VxZtISL3LRuEKqbNun/fwjZCKDVPVahb8TXh6/nxfMMXA2fTt2ZTIKLmcErcEBCeJd6Vo6EO jwnH3uHKe1cFd0V9uV2jf4+1RXjreWLwwyOYiuq4s9cb4njx0pz0mWoSdZOrRR6zTYBlgx+711/r lLUXKKj2+fpmMz+fCSOzS0K4atqb1OCid57kKKCkradTER2cZrnYliy2ZeFT3VVUJmYHOjI47oSg NnS/PttyKav2HYKy5kA2RC/68nLFd2UdmxgR4aIG//PM5FVBuoISCMZhOV7T9do+K+rjuRIrGuan QDyGv09wv+KJlLusBE/zVAYCXb2fHb1k8k/6GTizdheBFGK1yf7P5ekrUhMyM5NIuHwFjvZML5Eg zbTUS9lYvbFADVB2l2+/z+diGyn353B+L2fre3vExChIEgNNy0kggVB0V6x0cGY8LuATiXMBoVt7 TnD4PSXmaKYIp2YjAoL10Tsye3zbx4ebSAkqV7Fno53bK7M5iJhrUf30BmEpLPwarYsA0tbz88sz OLczvqXiKxOgL6+EC40EIRpRkuI1GhrOYFNJ1Z/UE/ZgsJXEriuQbjmKYowwNKKa2iabic/y8oy5 PjZ1zVbLdyBdvLtPlg7JYU94Ce0GUSLzyUsyFlra9Z5c65wCwThB8xG6IbDfQAwl1gOmwrNkbEQC iZitIlDAuHSNj2GhkN1m7VZKBanY8YwOBKDqFZI00zDRXu+YgfJ7yWXTQM0FydezM2S+WaBGE8AF H9IZcYRCnKkNPJ0nl2dTQMHz1cnl+ZrwOaO94+lZRO6ztP3EnhbaIZ2n3uFoqeQapGeAKyagi0zu 89OO+Sb3qKPNu7hcEWIbUefBFl0KCaffGA2k9jHraPCB1woAt+9EL0eqQLUxFD0gqyDmm3dyCwX8 AOrNueiDbvevpyIM4RSTMeo1o5r74NRfraTNjViSRjm9s9ksK+yZChdq40lA7MJswAVbjuhZuCD9 Py5blv1A+zlbogG5GQ7dmbxCmxM46IyJpCOT6N+iVcGK7kHRMHEwKFQcK/ATPhNphowpBdUvF6xZ XxM+JbObk0TiQ4tErvVA1LSXF3bzTCZfX5wuF7wNp0CaTsk+lizDsvVrgh7kHJkF6GgdbLg6woig ZJhsHGOGHIochVIygn69nAsH+bx3ilKgJUs+HCx2hHcJZI31VqTMY1iL2Rs5D8ezIS1jurveDBC3 SB/Nvl7t9bUeX4gFbw+TzdeJZQfdV6iRK4lVK0RmIuIi2MSzcPwu3qql8j6j74RtGdg8IbokyW3d GclQfGBsPz09ZR0GwgNs/KsZlr94TVf6nVkmdjlA9vgmEMFuuZ7F2eyxfel0063b8XhgBdGCGIXz JTYSF4OxyeVaupidIs1c8L3YyZTpb4KmQTRYwpHGa5k1I/tklHDyAURVeykXoMfL04HxgzA57T5Z 62w1s8flUsuQ1ezNnK6ReevRTvsNu56syawAu9pibs+MArK9eLzgX5jiM5xf2ggdJgJSYAPmiPhh /OuL+Yps8lV1tcajLFXYDQTHCHwqWlRAhdMZwNoZo382jaJOzASUr1YAJMWEkzhyaQ/3DFW4qM/E vYTdvoSZI8LUEovL8+PZKhq5moRNCqKXJPf3Cg9EEMahiRWgUOPPCK+jYdlKm/hsL0qBRNfVfiQq 6hMVbZcJN6s2vaPUYS1XasrQ6Us3OhoXfkMq7hG4GMw/3qHwOrwbW4X+Fd07s7FZqnigdVC6HR/P qO+JWlnl+8ptqiltclqIpRjYx5AFH6PmjjHtWm4QO2e6x4gz1NF9NR65WZd4EFFAFwFk+qNALqyk kQi7FE2R31Ub0Otw2/l9QK4qy/MZnrk1qXZnUYW5NhtucUdBIkfLTwoROIgA/qdxNGgJ/2o5PePj Tmdx9UYhkHkHQEOXbJoMDURtAn1Sn6aOm5A0tTxfmuyPzk5scXEKOEcojNV5xRjm7F3q4/X4Sfa3 g6dPDx4//0kgwe1nXx8+PHjx7DB7/t1h9uPTJ98+PfghO3qm5r2Psm+eHh5mT77JHn538PTbwz0s 9/QQS3RaQ2PfpAUo9oR+P/z788PHz7MfD5/+cPT8OTT39U/ZwY8/QusHX39/mH1/8DdY1MO/Pzz8 8Xn2t+8OH9+ZPMEO/nYEI3r2/ABrHD3O/vb06PnR42+pRTQpfnr07XfPs++efP/o8CnZHX8B3VPF 7MeDp8+PDp/dmcBI/nr0qDuvzw6ewcg/y/529Py7Jy+e2/hxfgePf8r+4+jxo73s8IhaOvz7j08P n8ESwJieZkc/wKAPIffo8cPvXzwio+avoYnHT57DWsHkYKTPn9DyaFltHoYDHdyZ/HD4FBbx8fOD r4++P4JO0Qz6m6Pnj6ETMpY+4ME/fPH9AczjxdMfnzw7RI0QLiO0Aqv+9OjZf2QHMDlZ3f/94sBa giWGRn44ePyQtqu3nTjj7KcnL5CiwNS/f4QFaJGoBC7WYfbo8JvDh8+P/gq7DEWho2cvfjiURX/2 nBbp+++zx4cPYcQHT3/Knh0+/evRQ1yKO5Onhz8eHMEmoM3306fYzJPHim/8Pm4iwMvhXxEYXjz+ Hqf89PB/v4BJjYAEtnLwLcAdLmmy/3cmfzuCAeBO9aFgj+pARoSCnwCgnmQ/HPzEtuY/CZzgUM0a vQseAB0RUA++foIL8TWM6IgGBkPBVcGdenTww8G3h89g2gYN1LmYyO9lz348fHiECcgHIIQ9/56X Bo7U/36BuwkfpJXsALaVZocgKVuHJxKh7rECC/TeP6V3Y+c9SCQA+f7JM4Q76Ob5QUaDhn+/PsTi Tw8fw5rR2Tp4+PDFUzhnWAJrwHievYCTd/SYdubOBOdMh/vo6SM9XbTY2TcHR9+/eDqANuj6CSwj tklQZ7ti4Pbs3h6BQnb0DXT28DvZw6xziH/KvoP9+PoQih08+usRoiLuCJqBcR7JujyRJmQxBd2R Py5MkqqMOCewa8PBBZoQzX/9EjXFSCQOSLJlXe5z4hXg40+IkR8DcyS0cM1QLRT0FGjw2fICCLnw T9EcNHH0ExtDIaqvyN8FrVZAjGE93OXaqBSLiCLBo8iBCgpSgb9GGYWZJLbjJ0KFDoFdgsG00hyV 0JCqo0NNPGTt+lpVlNE3UPW/m81Ubr0iM2X2ycpwsnIDVoXEqfX0JU0PR23Vz7U0mSfSJRfmyAUP XlGaEy073YjNI3ATb2bv5N4MWP+1sHbRhJoMjrAtamT9mjQ0xAyqHQJLAJ8Z7/AZSAMLUYplF0sS oshsiOwQaa6XfNlB7p7IAsBKmSHnn3FZqQW1ZkhW4XPg8PCSjBs/BuHlZQb8wZStn6YEDmTz/hdu rO9//u4ddEAtIINAPNJftGOScBPXqc6+PzB/z85uM9sc/ePECnQzbrY65oodbc7XHW4z2hpu56yi ywh732sv38frOG7mbtf4+96Q897ftgrp1bAIc6/RBGkjq618Ghwy2NY9MWkBmUj5AERRygs8MHcT ubMkTfIZWTyqZSoy6dhGn6LDGl+DoD+bzVhUN8+qLeIgbRn5OKOwtrb5ozI/hfJo6dExZtnetJpv JHeqcUUfoGwMkL+LeeYG+iER9rKqLrMfpiBMHqDp+sPpOYD/6auZhj0oWop4wK43aFWFOobUbgXV coyKycyBHU2RsZ6hUd1quYA5sC8kSAqA/uZnqlDtWJB0bGv3FE2q28wUF29lJsln819moiwnm00o SBhqze4iHTNdOEEzM/n6dgH8+BsWBRS+K5jhyIHuHudh9RMQPsSR9uDrZ0++B87k+59SDvsBQYMA QrZ5B9D9/5EX79vP95ND0UcJkRARXZidYUe4vD0MwU2I35jpoVSKe5B2ePJ5OpR9tad5/e4CxUO6 WYvm6zpGGobVF9hVL+Su80xH/NzqcPfkJV3iyLVL7JDurteoO31HOhK856MraRDuSEORuHmNDk6c tvgygDAAWn2dL6HR+ycwhl9IN3I+W1zCss3O1/fvI04nQXx9Oed7ZYuJYD4yMmOyJEQHbSqEsUKW 76DiXY0KYBbVUv98trqXsYs7AM0aNQBnfKuyYPN8vO1G78Go64tuRp9FRxzlSuaAtxYYSGDNPqvf idX9FM06Ls6AgpCZF1VCkFVPkp+W75an7xYzPeZIJY/fWV9suxTHQCcGORdBxheq/cmy/y+B+s/x To5MHOF8rtm/eZ2JAQ0a6KzvmY4OevtfOKDsu+nJL7OVoMI/s30LesUDwDx/B0dvufjLXuaAk1vN zyiYC3EznLOHUU7Wc3Vq++v8ZGZq4y042BQ2clcVFSUITOlek4qE9CLqFGyhGex2b5WiqCneEq+W eFOOSIgCcZi2hz3R0NidfFSRCjD1optPHgswIGSClnaZaO/XZi6Dd2/UvCqkGFO8VQNX9XY/BXZP nYRGooMA4z0aHmREafqp4v9g/Kf1u8Xm9Rcfrw98IKcst8V/wh+J/5T7UAeK/wQF/pCVH29I8eef PP4T7f/q5CPu/s32v3IBs0uf3+7/p/jR/QcK7vffvD49+wh97I7/lnkMCYz7X9auqErcf194dxv/ 7VP83L+f2dZn8Iu/P18gi4/anlfETsLHLj/uc9ivH4DtmM7OsqfzGTC2fz7nX/99vbk83b9czO+/ xotm4On2T2d/wTaonQ8jfENDH0b2hoY+gOgNrVxL8t6yBjcWvaGN95W8oYn3FLyhhZvJ3TL7DyB4 I8S+j9wN9d9L7Ib6/3Z0+mU8NntvMrdf0LH4wuVfYFzV8ktffZmHTI5FdvjrRfZvWFnYyOzo8PDw AUajm1Fyf705/fls+Wp+8rNzVdgHaeABFkerKNgzOIyebGH+BS2esruooD3Yy77OvqSra6h7SZUf YMZP8BVBIH6Gr/ceYGOn1BK1PF2dvJ6jlQ6y/l/PcDN+drj81tfx7BUaVUB7f/4K4AFFvK+lFS3/ 4NPxqbc/H+cnof/F70T/MXz3gP47f0v/P8XPb0ZIxRhCAtS5BSfxTx8zJWipGKKlY0Qzc7YisR7H 0BL9/VDa0lq3yOk6P8n5D7/b+S9dcv4rPv/F7fn/FD+/+fyHLed/L3u0EwXsxgLhSiwQrsAC9Pej W1xwzZ/k/Je/l/yfu8Liv/ua6X9xG//9k/yANAOHirc+2ybsH67mv2TfTUH8WmR/nsEv+6/pl38/ nq3O5otbGf9Wxv/HkvF/M1Ust1PFvezwKsK4mzaWV9LG8lq0kf4+vKWQtz9/6ND/6nej/76O7784 of+38v8n+WH6X93S/1v6f0v/35/+Vzvp/172zTVYgN1cQHUlF1DdgAugv7+55QX+aX8S+l//bvQ/ RPm/EP1/EW7p/6f4Yfpf39L/W/p/S//fn/7XV9H/vezb67EAu7mA+kouoL4xF0B/f3vLC/xT/ST0 v/nd6H+ZyP+5v6X/n/CH6X9zS/9v6f8t/X9/+t9cg/7vZd9dmwXYzQU0V3IBzW/kAujv7255gX/4 n4T+t78b/a+LhP7nTP9v7f8/yQ/T//aW/t/S/1v6//70v70e/Ych3YQF2M0FtFdyAe17cQH099Et L/AP+aP0H/79WOR/N/13ua9cntz/s/zvbu3/PskPElrZenT/++b+wx9fZFW4/zWQJUCb/IBd9mIx 3/x23gBqfijO4EMxBh+EL7gmW7Bl+jdkCt6fJ3hvluCmHIFM/L35gfdkB96LG5A5/FXAIN934ujn vvD5xBiF+Ww2e0B8AqbG+ISJcglw3GD7J1kG/zOfwC85OaLyAAkJlf/5DRD05epuVWSngHxgdvm9 B1lGhxa9dN9Mzy5nmeMG/M0b+Jkb8NxAMcJnbG9AYgF1hhB+ews+u3uKEU9Ws1fZnzJ3j2Ns4Wz6 c3owziHhnKDgV9nn7nOM/D7jAESxh5UMcvbmJm1icW5zhTFqKMAKHsz5Zs2viZ1f3KQ5LM7NccwW AuZLRK9bWb8tP9gYvom0wplxEFMvz9Oe3GREp7OX08sz2LEZhTCBofFDeoiLr98KFeeJrSnU1Jo/ Ybwnam95s61cDrZyc37xM0yNB3c+v9HgaEQZVJLa019/Q+3pr1x7ery+eW2otDyjJ9gRFqmhF3lz kxWB4oCSXEVb/aLwGJCK24FvN2hHnizLZgt6l4qbgOYGTdwbbwNBZrqZZuv5f0ltEgxgawDHQeZ/ PH7yt8fZ0bNnLw6f4e9fJT+CTd0+U0NkK/SdAwwXCLSAHw1bYvh1nOc5MRvH9HL9O6B/r169+1ds we9nh4xOH81OzqZchwIn2rsxEqCRisPP0efn1M9/XiKdWL++pDCPMwlmRa9s0VtlJ6+B5ZE6Gv7J RkVRf9LnmenJvg1SCXyY8yE/L7ahaFkUDev1FEOk7Wd3ny1Xq3f/CmIfkXWMnb/AVwCm6+nFPawd 9rPHuArT9Uaja82np6cyEDzSK7eHKBofXVhg3Lc3QNan8qr2KY19vojve2FcOInptSeNpKGippk8 NAebSHtHOEgW5xJhdr3mqOfM+MEPnubTJT4msKTgTxoHDHomUo9lHutbc9jiib7zcYrBHvnBy0VG oAVI5wJ+xcdfvwrZ3YJfQMI31DH01EtmrXjezIHeoxbprdPZCUz5FW+cvISCj+CdflVld50gfMAZ QOILaVIac7E57EWoDxS9lz23Bu3Ru8tfZxy3mluk1xephrSmr30oDuZ54ShxOGvmxPgFToxH/+X9 u1ix3AcQwBjx9BwzsUPQx6slheiyGGv7+7qgj5aLzwn+15cAcXhygd/BTiysloY8m/0KGwq8JNWU c/bs+dMXD5+/eHrYOYfEtp685Fif+/tfnC5Z/Hu9OT/b4yHjQdogoFIcwfPZPWkwU4D8484fKuSy P2LJX/FhC6pCfxNFp1+v35KXuvwzh63pICQuVHQKDX5u0F24TktlpxDB2bBQ9cHGVHNLRFKpCi8F UvobttT0xsS/Lbvb0spnYm5G2iUknvdbuvYgnLvGwrjuti9Ht919qG0XAOe4y0dPHmPI6yH9iiRM cCvBM7KIuFK4HbRDuJrEohCngQwDVrl/s58Ji+Y8jzz549IPnb8mxM5JFTdWxfWqYI0FcNzba/Q7 wRpn6+N8fFhupEaWSR033stYHaxxnvbirlkj9nGtGrBtZ52ZaM2tc8ca82vX4LljnRn+/sfen25C /rIa85vUQK50fH1HxuVotaZyoK6YiYvrO/11fsMaile210hAUmpc1UevxhqF6JvU0POLDwIpYeMV vzu/JwhDInq/vFzEFyn1jUF5jmpjdfE87BGE7xHU0t9OWyLlDlBUexaFKfiGH0RC0Uva1grIl5/S gznvOOqshPDUN6hTNiR7Ons1J56RY+0SX4NdLLK7zZ6r9gq/V4V7/NCrDXie3U+Y2u6Un+D3lc0Z ONHTs/g2h9XSSoBvoOnVPqpVSESmZzhYBXWOUbtV5rFuSL2l7xIjW7vyzGSt4wAB0mAv9hAa6F/c Y61PlECkhovVDLmvU2XV17ORecFC4gvnMw5MqxupW4v8qvWb9nOwZtCit7spqjrFXqfI5GsZGfep NbrQoitntTAMvQCD1kCuez872LD66nh68ou8EMbvgJ1GEWWpVVjRRUVXxZ+Aqd2f7aPmBcb0dgYs WxRJlAs8+uERk7Psro5+zuLFvRECN0btUFQFaTz/nCVQTYLUSMkvs+b+MUVZPZ0lxd3W4q66orzr li/89cs7KF+FTvm7JKvgyzfn+MZ18sIlPxCo7K0gBV5phGd7BEbeWkWSPj8/pYZBTAJWncviFvOD TiQav52fbl4LC/83krqO323kpeYVyFZv6E0DFFYv+IVNftxA91wPF+30fdxpVSE/yR49sS2Tj3/k 6Nz8DvqSepie4iuHErZbHrY5Plue/LIWWSh5rY4CAJ9hsGJ6fVbeEc8wlPAqOUV0vmb0VNU+93oA EiatD4g9FM9alQIxm04qTRKOEamH54s9ojv8XvgqnsI11xKlxJovAhA5ghhKEJ67nH6yr/6SUcI5 wbCkSmBJkF5cIwGVVgIDGO5nXwNCxPZEEpW1fY3SjynQGA/j40jTM3wMUgWpLPvhcr0xIRbf/fqq wCNG4h0KryRVC/J4rRIvPbW2pHeb8G3JDU8O8BS+1ZhIwPx9s6LnKXCj1ig+w3HHka+zuyjpt4kE Sp/vca0nPz4/+uHo/z38V2kENmfP/iKo/6O+UbHBJ1VX1MIC/8KtePjDk2d0aXE+X9OJkGZRT8La EbqI2NB7Dm+nKhCyRIuRjkFGJX3P97PN5+vs1XI/+3a5PM2+vwRw7d5Grzery5MNh5cT7fdEdNBA uPilvcVmtTyDrwqOpKW1ny+vpdmCVb8L9e4lzagAc9NmoF7ajMldN2wG66XtXKLK7ze0A/XuZWk7 qPL7Le24qjMcVPv9lmYK31kd4z1v1gxU6y/yzwCeP9Ou3XCRKWBpsnPIF3K7MYY7sgr2LCcfqtg9 qZfntstfXu8S5WVy5wCdLG6sxR9OZ+Xu8TPrdF+RjM40Kdcd3cqx9oXuBWxB1qwBFn6OlwFfQ54D X/vrbNVbkcXPehKv3afck5wOWjqdr26ytjQyaI/fINYrzvdcYbpNQDZ8MDpFFdcbnW2IzjZbnmyI yvcbNgR0vYb5voCUsnZ19Z5zlqtshFRk1Qko3rNJm7Vdj71ng9OTk+WKtNj0KMN/zUZAVm7JlWjj OxfdxU6w/ZWLPajpf3PNYkfNrN5VM+yqWXVr9lcDVbPKrLACstf86p277pT4NlFaEwTJOs1Bm9de phu0uWsBf2ubu5b2em0Omiw/fJPL64KONIlTxbDaL8+Wb1GQPl8fv+fBw1fE+HINkFd3fIs4wOuN D8mXTuzeYK7XPprUVvaS32CmKSsWvJ+oLVQ+6OPbk5v1I0gaUO2fsh7BTbi+67UFwtxc95t0pIix tP1u28ubshq6tjDBe9vJOXJiKlJ1O4Scn4G2uC0dFm4rnpKa/uYYTmoW16y5ZU5yUQeyZG8JLze6 RdckrVGqJK4QtujXbLzNn1e/sU04kCPDFM7nek2KAo/ufKnhYXtAOth44FqIKAq5+3j/czwfb5HN CG7cIlTb1iJbFdy4Rai2rcUq/KYWodpoiyt3gxO4KoDT6TPlAN64u9uO1QgOZ1HXIP3lcjXa4rWO G2PKFMxYsv6AP3wuH8JqLheoMLejybY4qJV6nbyWHJUg/HwkqYIB+un9tvniFJ9WIh75ww6SR4IP uH47JTI2yQgCaMz4nW2/Enu7LDsYGs1IzjCEPuGnGT17Lo0+kD5R7vxW5tTpFAPp36TTr99/OJ3O iw/T+cMPPKzwsYf16AMPuPz9Bnz4gadS/XecyjcfeJL1/6xJfvuBp9/8o0z/uw+8MO0//sIcfRCK 9uTpOEF78vT3o2dPnv53JGdPnv63p2aDPbzFDx1g//s2aP/7pwd3HM7jreN5/IkHBP2Tx+hHkiie kfEyXqrePf3KiUrjx7E7GrEe+Tgiw9GiY5aD/f1VvEXItWg2O6WbjPSyx/HveN9j10Zf6d0N59EF TswjqXGSidMNezTMVl+KffHp7FfcqUTiFHkKJBmoxLuAG0d/aW3YxF+XICYSOJxPLxKQ+Oov0ONd avjenoEDfIXR7BkQwO8yQil674H2gqCgQ+gNWiE13Sq6TxZ5O92z6JhCpg9476CLKfcnG1ocu6aa oB8U3av8vPLXXJ60Cq7J4qaLsvK9r7Y02NbutYldj60Lqn274r6CwZuf+Y4TVsD1B0tDhWweDg0G b0TvUQ9YFe9cdlSF7LQq3ohbVfHq2VoX89PKdLf6II4aL7B3VIfstDZeW1vXeGe9q6qrOlVdlVQt /M6qhe9ULXwyYfbWQQ3A+IQhvzNhvJSWCX9YfJNgvc3bJWI9L8jiGV35DXHeJL29U2SyXBlocr76 idqVXBdtfcgpCMr84cXfyU80e/L4MLsbDVOye7xufIUJGONGCI42AZqX6945LgNXP9k7nZ3sLWav 9nCzSGsbzYYML6LlgNT9kp8LG0cCXZzXwQQLOzrI4Mi5GyJMusmOeEEHHjdgoWM/3zFWPsX03OLu gVbF/TGsFYeajgw+D0cWB4RWrndn9zq2lWprSbaPnSEyjrpiiIQkx8e4ZfXgc2eMHYxqwKMI9QK2 NLlKw1n0bjlQq/p6dvLLWlycjt+h1djb5ep0jcflFFPiLXefzN2hpTezff71wKAXDt80A9hmIJa7 CzRI6YFxfRWZxuZ+JkS5Y+mAFvEi/LG596e6B4eGR5OF0wscqRVsg6k7Qq47oB6745pf+Ht/BOT6 J1d2O036fKgoePsgbBR/ct2BEKq+3kDCvT8Cqv5T4XoDif0+VIR+nYH47kCqcOUGVEWv5+t1VGzj BhKY+egk5DW6uAMRKa4gImQmkR0dfSRi8CO2/hzoGfRKhOEuCjAHzw+f3VOu4efzy19/Xgq3ezzH s72LIMjCJkQBPb6WyO8+eboTqTNeth66e5vgx2GJhz3sNCyR4K80WwBhhGeWWSsWe3lJVDzBZGtF ZRPVuhgaQiSUoKBlX1LYiYHsBNCChR0LNsAogwUbPe6DRRs9i1rq0c6DtO24+d1sd1yZBx9VPH2J kT3gkAU5ZKOmJ3zAPtL5EuonXSEUzKZiT87nizJ+Xm9mF+66J6wLKlj+v2ar5ZfIOEbQRhv3rLkH 8llf3ErqZmZplJwJDC9F3uCZHo3e7mmPD+IAlovZ1v7drv4F0MfxvMA6cpD25evRg3w/gnUCjL2J 3ds9JZhDMiPg8bfOyF9vRiPI7jfO6OF4Ef/+k4ZpppNGqjQ67QznXVxv3iM46+PN+9F4keIDLA0u RrI4iEy2gkS43tKU/82W5nC8SHj/1cPVShcPOPati1fuWrxk9aqx1RtZvuus33UW8DoreJ0lzL4Z L1OmZa5c5+1LDWubLPV6/uvWla6uB6b1/zwwvcYSfztepHp/YIclTzcAnYu2bkF9vS1o/lm34Lvx IvUH2CXcl3GGNOHClOOPVd9JgfmMHJ+g05/Vhve3MvYU1HOcs0+2t7O5qmwYkXkuElWEG3Lu3QJx 3w/HC8Rd/2a8QNzzb8cLxB3/brxA3O+j8QJxt9O9Xu6WKtKN0V18Rl5vY2Kb6I86FrIUFCYxfJ2k IaDUlRfjLbBojpcecpk0X6cO4RhUomD+ntRVM23xt8LLmP57KAluvQjR+exev+5QP7JkBjQLJbNy l2SGPsBrKv7R9B+keOwccY4hZG7CfOQJPaCgeHT0G6U06GFUTPvi+kKa7wlpIxhwBwLUATxIBjQU 274Qke0qIpVfJbSNDK5HtVItafec+y5OT7p1V0lWV3druCTv08it4ymuSWNkSdMVHoqRX1xPhPwg Cxw1sTsXOJlQZ5m3C3Lvs8yW4/ocyNbx3mQDEomWfiVF6+geXCnOfkog/6h74Pt70AWNRzeB/mSI /iqh9uOAyei0DncCULgJAKVyP34YEfy/uJ7Q/0EAKF5q3BBLjorLv8u+WE7RFxe2zu4mRz7VNdDv Q2XDF1crGn5/svZBznoYnvV0jd/zrG/XDPz3ganRpfh2J7SFkXmPwFmiaMHfh5qWL66nZfmUxH0I Zh8EXw/AzHLKnWT9cDdS237sO2C4XTvyPwEMR5fqu5sAaLIuQzBNtFH065g66otrKqP+ARBiNUSI H5D5+SBE9gaHaXRaQ+bnm93HbDs48eSKrTqqf4hjNrqIRzsPYDluNTB6/q7SM7IiQVVU676KygwL JmSLJ1ZxHOsftTPvoXTcZQi2RYlEmxnNLJNVUd/Z3VqlsRmIeefJzxjtdFyip2FF+z3GJNG8lQ/y wPozDUF0TxeYTZ+TK3h650GDvUrw/oloeZawx28+kpouUWEOFnNxDf2mje/j6uaAfqBqrjLVXLSS +Gh6uDRahHnNT1LN289H76V7y0c5teuo3ca1bintuoIe5yk1dj7wSAY6t3uoTx589uOfw71rXCM9 eXol3fZXIvBitESKGm/AmsDs08Uoymp8MYrxWZfjn6t7V+ort1mffZjVeLiFtL73esECpetVjwLx dW4URy3JPtXkH22ho++9PPXQ/riLMJQEULxKorMYRk4j0PRtkcW9o0+xfrv13jZy2yVUg+u+HmHd RnivMLLrT+MjEw2KqAlko76nVPdkD0Oi7rFTSoaPInwc2oEBLH6Yws4QjaLnqORRHrnje0ZBnwkI Zi9fopntm9l+9vn/ulxvPqeYoxhWVKxd5YWJ30ZpZOP/vn3nBxfbQ6PN7hEYbD4McXhC+ntv8zAm E1kdu1XjS9CX89V6k+GdkMA9lFnMrm3o2536+fr42iYPabyU7MsRD8etaOw6ouhuNMZ8VopBR7AQ rsT10BBMWxA0xSjesgRfbEPSSbM8x23Ac5Mpdgr8adQy8voTpGltQTAMLx8Xr8z4ucLTrxrDK8TN c1SpPXq44eOayHc6xP1dzf7zcr5K3EqXo26lS3MrlWPb9y3lApLJR5A7+bnrYfqxsNDJNiy0HHEz hW9Xo53e8BX5pBEfdZ/Ut5TefLiLPqTkQiprFAM6i/scYikJjT4xz2po8+f5/MaLZIB+PbmYzkpV 3N+yWKsxHUjkZ84vRi76BkyLTeZj+50s5uyx3d7rbk0Mxvdhu54kVhYxTqHZ0iAp2rG189/Oeo1o iA86m9K3p/q6kztmUPVwS4kRZ4leiai0OtxSIiqvvtlSIiqxvt1SIiqzvttSYsys6vziCrOgZDvg QH9M4NwwB+nyHnAiDCQGOR8TRikKfi+YrXS8x+W2gy7GbEfd0pphXI6UetWiFyMZ4IxLBgedDVGd 6dedrwqK6eYFKMuaLuoAAzJco30/2n4x2r5L20fX52u0H0bbL0fb9532xVzjyh6q0R7q0R4K6eG0 uwcDifgme/BwdD0fXWM9Q2c0umFXDGb3gj4cXZpH11iaUgbzn+RkO4o4P9aqHI5O8JvRCX47OsHv rjHBitHax+VRz1T4dRpAhJ7O+LieZSTsLuhxkFfzV9PFZn7SjbXKzCjgzyk94mDPP/BjPYTb2LL1 5Wp5bsht0XMsH3vrg3Uqq1nnNaWUgUXnSai3/m0MbLS5NTl2loZSp7/68QJ2snCqMBmT+wySuyzu kAPmCJ0jF4JxvCRms3HwIH5Ad+gWbWCnt3W88BiGDbCzJgxqdj+7YvQcGfcmE9gVrAGK3nDwg/gM I6Lo1oHvHHbvIRgcOgXKJXreHTbH3t0JMmM6OUIxY+DTGSg1foORsiKGQ/COj/WqwAD9sb7ohQEw RJgM3gFS3DZ8V914+Bzvd3z4V4UTGAy/FzxgbPgYdCBsnUAxZlWwewIcXnh8AhqG4NoTiBfID3uE aNuIqzHrozhieffcBoX3tIsrTl5yXdt3Bh+H4odXi7IccPnaSgAlAR9XPbR5OztjTwLnh6T3Y9He J0ZmuSPgiicaBWC+sfeNu/Rwubo5ObSNv5ZcO6RQQxo3xKYDcB1DZAMJdwxdDITcsSM5kHPHTsFA 1B0A30DUHSVwWuodgfeIcdkO4IX9Is5xRndH/AQWP5H+6Mnjw3/910n684ff6QcYpC/Wq5MvMLjW /pvXp2cfoQ+X51UI2R9gueqK/nV5yOl3/PE5wHBW+7ysXVHVOWT7ogp/yPKPMJbBz+V6M11l2R+m V5Vb/LKAc/YphvQpf/hlCd56DaGOuOLOhKK+X7xbsf784T3YpzzPfpifvJ7OzrKn89nFLPvzOf/6 7+vN5en+5WJ+//V0sUAfuv3T2V+wDWqHXui7WC1frabnqJN9iTL6evly8xYo6YPs3fIy42cUTudw UObHl3gDRS/efYFM8PJ0/vIdNQQfLxenM37QazNbna/5um6Wffv4RfYtB6HPfrw8PgNZ5vv5yWyx phj0F/hl/ZoC11NDWOUbHMUzGUX2zRJapmvdB6oz1siQXjuRFvey5YpauTvd4OBX9I7ecoGizrsM 3+Oxuvtb1yBO1R42er28kFf35hsL63a5nr28PNujNqB09rej5989efEcqPdP2d8Onj49ePz8pwf6 OBY/S8iPr16czfH90OlqBaLdO5gCNfHD4dOH30Gdg6+Pvj96/hMqn745ev748Nmz7BsgPgcU2O3o 4YvvD55mP754+uOTZ4f7WfZsRo+nUgs7VppEFpQQT2eb6fxsHWf/E2yxvAxA7wKA2IUPxeJrjScA ZFfvIrUyPVsuXrF/3SZZzgcU8m652ZO3UeWd3M7+Uv24x3v4vOf+XlbVZfbDdL3ODt7Atj6cnh+v 5qevIPnDQZZ7V7R72YtnBzAPqv9vR6dfxuOy9yZz+wUdiy9c/kXhsrz80ldf5iGTY5Ed/nqR/RtW Ppsfr6ard9nR4eHhgzsTNCDD5D5eXfLzDs5VYX96dvYAi4PAOoc9I3Ow+frO5F845isk/kUCviZ3 nvh1GNIVvt57cIeIDzZDzXZeZfyaXmjgVxmtI+IaoOpPaKmE4TkPpA0tDb/+3ijr9ucD/ij9X678 xyL/V9P/2vXpv89v6f8n+UF5R7Yeyb+/z6HjJBrZLRdwywXccgFjXIAemo/PBOBNVp8H2NPo7jdh A6Ch3VyA9tRhAg4QOL6+5QL+QX8i/S9+N/rv8pT+e6b/7pb+f4ofov/B6H+4pf+39P+W/l+H/odP Rv+LMfq/p0/w3IwFKK5iAYptLAD+9fCWD/gH+4n0P/x+9N+N0P/ilv5/ip9b+n9L/2/p/39v+h+2 0P89fWvvZixAuIoFCDtZAPzr0S0f8A/yE+l/8/vp/wPT/8qVdVEHov/ulv5/kh+i/7z12RZif7ia /5J9NwX0u8j+PINf9l/TL/9+PFudzRdI46Hmh6LwH4rAfxD6fk3yvmX6NyTu70/b35u035Syy8Tf m66/J1l/L6o+Mbo8n2HcRgruAqkxsjyJRLmBHWaT9eQ91kiY97LDveybvezbva0P1f6Ujf6MvM0q hLuBVIdsHyP5ncOmENmmETHZJltCzUVrwFEijn8dEoDgX9/iX99JZ1r3wS1d/8f+ifS//f3of1km 9J/lf1ff0v9P8QN4AuO03TIAtwzALQNwIwagvT4DAAO6GQ+wkw1od7MB7YdgA/Cvo1te4B//R+k/ PZv+kTiAK+l/nsj/VYX0vyzzW/r/KX4AQfz98ZOn/pYBuGUAbhmAGzAAdGq2sQC7qP02wk4N7iLt 1uMu4v65+5yd8O8eZF9lX9+jaFHixJZ9nn9+S9Nvf9Ifo/8f0QHgavu/PLn/J/pf1Lf6/0/yAzjk 1zEHgL/fWgDcWgDcWgDssAD49dO5APz9g/kA/P1KJ4C/b/EC+PXWDeAf8UfpP4Y1mZ/NfsZAdWfr +fn+8XTzofoA+l6X5Vb6n3mfJ/I/6v9D5fwt/f8UP28AI2HkvF8mbwAEsvttER2c4yegwH/sfVqu +l8MISafFsNvAHG9L5vjn+3j770e/2w/ev6TPfjgfezm/50rgrfzHzz5/wK+uD3/n+IHeeC49Rnw p7P15ni2OHlNXNw39x/++ILeunmBz9zcqgdv1YO36sHrqAc3cIxEO4gcM/7a1+1tjmneUnBijxqc LBeb1fIsXgRGTv7nN1B3ubqbNRb0i+JQSc11tyrWXGEU4rtBi7tO8fl/zTo3jiMd+dGOVm4vW3n4 U8CfMFoziUt2T4KSI4+5XMACZRyvXkKTJbrTDKO6ZwPt6Wib+urByl+7hlUpRvSw2wZOFcJ1K2gX cxzPQAs8cs+rPcze3Kg8PltwjfI6GkDg12ldilMQzxsMZnnNyWrz5/Orm7ey019vMhSMXLhF+55h bMuRcWqmq3ZkFn6Yec9eD+pANkF7VNFvjiXo3+ECSQJRCjr0DD7rDEPs/utEXqIBvLYxCnzy7uRs Bh9er5aXr14DAkTkcH5O79BQLHyUnBZreaXm0XLxOYUufTXbEAp8O51vrML0JfYuIfQBE55R4F98 aeGEGpgglPBDP+svEbeezNYWsDXORjJiWYs2ebDJzmbT9YaRs2B7lCyyJ/9BZeBo//mr7LP8PX8+ 4z2BY/8BW6OlQurFK/pAJ/V8+gtQU4xvTCs6+3WKAYvXSq2ZPfphurhEpAhHON/36Vyd/FBXLqeE o//1H/rXyRcng3KfZnQ7FyaOZlsBd4Od0DXYUeL3nOu1R3etuV575bbN9eD0NDu/BARAvBTiA3pW ABFFGnRycBb1vRTlMyl3OxKRONyPZ7PTdTIEptTnHH77SkRgbVER40BwlZDqyEzTz7kC+GAVaAT6 +FdkEDqN4oufI406XfcdjULVLY0uZq+2NnrFSKHqyNTP1sf5lqm7KxrEquMtui1DvEaLbsvEz7eM 013dKlbd3uroWK/X6raxAstzNrqm7spNwqpbWkV+YcfWD49qbFWe2O1PHhiW7cN0Oyc//XWsQThx O+a9a4TnMQRwijD0zHbwxY/b8QVhH5QWEozB3VCH+IgA1cLmLrDcNfAGFpPJohgip+OzB3EeJU8j E6TIAdm7NdzOGhwWvVfD7arBkcj7NdyOGhz6e2yRaSH0oWJ5hGBFPORJPwQzCT0UP3tPqQz/LqHA SV6hAMTye5DfA/9OwgbGEmfwuKthuUmoSL7rCxckPCTfNbQ4iQnJd309g+SB5LsGT1/2+tWXOYjB T757+w5nI/mur34Q05581zdCLpFfx3DksJLWyCXy6fpRW7hE/lw/8oM2JHYf3xq47P5B/e/p8uSL j9lHFnbf/2SZ2n8UZVmg/UdeOveHrPyYg9Kff3L9r+4/aoBfb85/F/8fX0X/n9KR/Y8Pt/4/n+Tn z7jpf5n8+fVsegr/bOabs9lfJs8oXD0qKUUza/cATMj40fs/fyHF//yFVD9enr7Ljl+dLM+Wq6/+ 72/oBxt3wEbMXy2+OiEi+Jevp+v5icTEl06Q9GCj0JSDGqfzN90qMLTp8dksezs/3bz+qshz/EKf T6UgXUr8xcGgTvkzFw3l/2MjWs/P3gAN7jSMV5Q3rQP0Vqp8wWMYGYiPjUJD64vp4iufrZZvJbWz +fPLX69sv/jzFQXCrgEUOwdA7/xeOYLyyhLVlSXqOMhdA0IG5HolAY6u7LSJTV1zPc4vrtf78hqA 0Q5793/Zv7Kay68u4n77li+vA3POX12k6BT5gk7tXybJreHJDW4N//wFIAL8BxEL4RnCVr830rz9 uf25/bn9uf25/bn9uf35H/zz/wOHfWehAKgCAA== ------=_NextPart_000_0009_01C0532C.0034CA60-- From Paul Marques Mota Mon Nov 20 20:33:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00372 for ; Tue, 21 Nov 2000 02:10:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:52 +0100 (MET) Received: (qmail 5452 invoked by uid 0); 20 Nov 2000 19:34:19 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx13) with SMTP; 20 Nov 2000 19:34:19 -0000 X-eGroups-Return: sentto-1101623-1578-974748829-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 20 Nov 2000 19:34:18 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 19:33:46 -0000 Received: (qmail 26841 invoked from network); 20 Nov 2000 19:33:45 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Nov 2000 19:33:45 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 20 Nov 2000 19:33:45 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13xwhB-0006F5-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 20:33:41 +0100 Received: from alpha4.bocal.cs.univ-paris8.fr ([192.168.3.7]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13xwhB-0002s0-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 20:33:41 +0100 Received: from mota by alpha4.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 13xwhB-0007S3-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 20:33:41 +0100 To: f-cpu@egroups.com Message-ID: <20001120203341.A28424@bocal.cs.univ-paris8.fr> References: <640F9ED3CD2DD211A28600A0C982788CB1EC7F@intranet.hq.conlog.co.za> User-Agent: Mutt/1.0.1i In-Reply-To: <640F9ED3CD2DD211A28600A0C982788CB1EC7F@intranet.hq.conlog.co.za>; from Paget@conlog.co.za on Mon, Nov 20, 2000 at 02:17:12PM +0200 Sender: "Paul MARQUES MOTA,104175" From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 20:33:41 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6953028c4c6808762036057e3197b378 Status: R X-Status: N On Mon, Nov 20, 2000 at 02:17:12PM +0200, Thomas Page wrote:
>
> Finally, does anyone have recomendations for a book describing the Linux
> kernel, and how it works? I have some Christmas money to spend...
>

You should have a look at the linux-kernel mailing list FAQ:
http://www.tux.org/lkml/

There's a bunch of references under the "Basic linux kernel documentation"
section.

> Much thanks

You're welcome :)

> ThomasP

--
      Paul
eGroups Sponsor
From Paul Marques Mota Mon Nov 20 21:34:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00378 for ; Tue, 21 Nov 2000 02:10:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:10:53 +0100 (MET) Received: (qmail 27814 invoked by uid 0); 20 Nov 2000 20:35:20 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx23) with SMTP; 20 Nov 2000 20:35:20 -0000 X-eGroups-Return: sentto-1101623-1579-974752460-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 20 Nov 2000 20:34:37 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 20:34:19 -0000 Received: (qmail 32898 invoked from network); 20 Nov 2000 20:34:19 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 20 Nov 2000 20:34:19 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta1 with SMTP; 20 Nov 2000 20:34:18 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13xxdp-0007KT-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 21:34:17 +0100 Received: from alpha4.bocal.cs.univ-paris8.fr ([192.168.3.7]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13xxdp-0003ak-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 21:34:17 +0100 Received: from mota by alpha4.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 13xxdo-0007WP-00 for f-cpu@egroups.com; Mon, 20 Nov 2000 21:34:16 +0100 To: f-cpu@egroups.com Message-ID: <20001120213416.C28424@bocal.cs.univ-paris8.fr> References: <3A17337C.27120D2C@lvdi.net> <20001119161246.17586@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.0.1i In-Reply-To: <20001119161246.17586@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Sun, Nov 19, 2000 at 04:12:46PM +0100 Sender: "Paul MARQUES MOTA,104175" From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 21:34:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f4482c27677829da2b33b2f079b35524 Status: R X-Status: N On Sun, Nov 19, 2000 at 04:12:46PM +0100, Michael Riepe wrote:
> > Before you start porting, me and Mathias *already* have an almost
> > functional port of GCC (and this means GCJ as well) to the F-CPU.
>
> Where?
>

It's hosted on sourceforge:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=f-cpu

Good luck,
--
      Paul
eGroups Sponsor
From Michael Riepe Mon Nov 20 22:43:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00414 for ; Tue, 21 Nov 2000 02:11:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:11:01 +0100 (MET) Received: (qmail 888 invoked by uid 0); 20 Nov 2000 23:14:37 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 20 Nov 2000 23:14:37 -0000 X-eGroups-Return: sentto-1101623-1580-974762046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 20 Nov 2000 23:14:16 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 20 Nov 2000 23:14:05 -0000 Received: (qmail 59924 invoked from network); 20 Nov 2000 23:14:05 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 20 Nov 2000 23:14:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.250) by mta3 with SMTP; 21 Nov 2000 00:15:09 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01117; Mon, 20 Nov 2000 22:43:07 +0100 Message-ID: <20001120224306.21180@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A18367E.F51B4E28@lvdi.net> X-Mailer: Mutt 0.84e In-Reply-To: <3A18367E.F51B4E28@lvdi.net>; from Lee Salzman on Sun, Nov 19, 2000 at 03:22:22PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 22:43:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'What letter comes before alpha?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f10af13a20c0788368bf24dc09c2bf83 Status: R X-Status: N Hi *,

On Sun, Nov 19, 2000 at 03:22:22PM -0500, Lee Salzman wrote:
> To any and all interested:
>
> http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz

some observations:

-      In fcpu.c: the size prefix is not numeric (should be .b/.w/.d/.q).

-      Same file, function prologue/epilogue: seems like the return address
      isn't saved/restored (r60 is in the call_used_regs set), i.e. a nested
      function call will clobber it.  The frame pointer isn't saved/set either.

-      LONG_TYPE_SIZE (in fcpu.h) should be 64, not 32.  This matches
      other existing 64-bit architectures (LP64 programming model).
      The #define HOST_BITS_PER_LONG in xm-fcpu.h should be changed
      from 32 to 64 as well.

-      Since we can do partial register writes, WORD_REGISTER_OPERATIONS
      should not be defined (still in fcpu.h).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Keyshaun Tue Nov 21 01:40:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00435 for ; Tue, 21 Nov 2000 02:11:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 02:11:07 +0100 (MET) Received: (qmail 16283 invoked by uid 0); 21 Nov 2000 00:40:28 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx13) with SMTP; 21 Nov 2000 00:40:28 -0000 X-eGroups-Return: sentto-1101623-1581-974767221-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 21 Nov 2000 00:40:28 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_2_1); 21 Nov 2000 00:40:20 -0000 Received: (qmail 9735 invoked from network); 21 Nov 2000 00:40:19 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 21 Nov 2000 00:40:19 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta1 with SMTP; 21 Nov 2000 00:40:19 -0000 Received: (qmail 11541 invoked from network); 21 Nov 2000 00:40:11 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 21 Nov 2000 00:40:11 -0000 X-Sender: To: "'f-cpu@egroups.com'" In-Reply-To: <640F9ED3CD2DD211A28600A0C982788CB1EC7F@intranet.hq.conlog.co.za> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 17:40:15 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] F-Bus, G-Chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a849a2105d44ecdd4a8201b65d21b9be Status: R X-Status: N > Finally, does anyone have recomendations for a book describing the Linux
> kernel, and how it works? I have some Christmas money to spend...

I have "The Linux Kernel Book" it is a good overview, though it doesn't
have the kernel specific parts that I'm sure you are looking for.  I have
never seen a good book on porting Linux.  Only a handful of groups have
done it.  The Linux Kernel Book does however go in depth with the
structures that the kernel uses and how it uses them.  It covers
processes, signals, file systems, I/O, Memory management, POSIX terminals,
Comm by pipes, Sys V IPC, Loadable modules, and sys admin.  The reference
that it lists that could be pertinent to you is "Linux Kernel Internals"
>from Addison-Wesley.  Oh and it comes with RH 5.0 (for what it's worth)

Shaun
still writing www.openall.org but there is something to see there.

>
> Much thanks
> ThomasP
>
> > -----Original Message-----
> > From: Yann Guidon [mailto:whygee@f-cpu.org]
> > Sent: 16 November 2000 01:31
> > To: f-cpu@egroups.com
> > Subject: Re: [f-cpu] F-Bus, G-Chip
> >
> >
> > hello,
> >
> > As Nate wrote, you're welcome and please share your thoughts.
> > reading the big f-cpu manual (v0.2) will help, too :-)
> >
> > Thomas Page wrote:
> > <snip>
> > > I will prepare it and post it to this list toward the end
> > of this week.
> > it's always too late : once it's written, a draft is deprecated.
> > but it's how the design evolves. The best parts remain and
> > the superfluous
> > disappears... so give it a try.
> >
> > have fun,
> >
> > > ThomasP
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > -------------------------- eGroups Sponsor
> > -------------------------~-~>
> > eGroups eLerts
> > It's Easy. It's Fun. Best of All, it's Free!
> > http://click.egroups.com/1/9698/0/_/3462/_/974330790/
> > --------------------------------------------------------------
> > -------_->
> >
> >
> >
>
>
>
>
eGroups Sponsor
From Yann Guidon Tue Nov 21 07:56:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA01372 for ; Tue, 21 Nov 2000 08:29:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 08:29:48 +0100 (MET) Received: (qmail 19238 invoked by uid 0); 21 Nov 2000 06:51:43 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx09) with SMTP; 21 Nov 2000 06:51:43 -0000 X-eGroups-Return: sentto-1101623-1584-974789498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 21 Nov 2000 06:51:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 06:51:38 -0000 Received: (qmail 46305 invoked from network); 21 Nov 2000 06:51:38 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 21 Nov 2000 06:51:38 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 21 Nov 2000 06:51:38 -0000 Received: from f-cpu.org (nas1-147.ras.club-internet.fr [195.36.192.147]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA06545 for ; Tue, 21 Nov 2000 07:51:35 +0100 (MET) Message-ID: <3A1A1CA7.194F64BD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A18367E.F51B4E28@lvdi.net> <20001120224306.21180@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 07:56:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'What letter comes before alpha?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d0e84ccd654c1ac7b77e4b12bd670fe3 Status: R X-Status: N hi,
Michael Riepe wrote:
> Hi *,
> On Sun, Nov 19, 2000 at 03:22:22PM -0500, Lee Salzman wrote:
> > To any and all interested:
> > http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz
> some observations:
> -       In fcpu.c: the size prefix is not numeric (should be .b/.w/.d/.q).

The numeric "size postfix" (it's after the opcode) can be a power of two >8
for the cases when the CPU can do more than 64-bit widths. since there's
nothing after .q, .128 is more explicit than a more or less random letter.

IIRC, .b = .8, .w = .16, .d = 32, .q = 64 but after that, it's not defined.

<snip>

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
(tired but still efficient !)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Tue Nov 21 07:56:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA01375 for ; Tue, 21 Nov 2000 08:29:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 08:29:49 +0100 (MET) Received: (qmail 29293 invoked by uid 0); 21 Nov 2000 06:51:54 -0000 Received: from ei.egroups.com (208.50.99.235) by mx0.gmx.net (mx15) with SMTP; 21 Nov 2000 06:51:54 -0000 X-eGroups-Return: sentto-1101623-1582-974789494-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 21 Nov 2000 06:51:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 06:51:34 -0000 Received: (qmail 40472 invoked from network); 21 Nov 2000 06:51:33 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 21 Nov 2000 06:51:33 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 21 Nov 2000 06:51:33 -0000 Received: from f-cpu.org (nas1-147.ras.club-internet.fr [195.36.192.147]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA06486 for ; Tue, 21 Nov 2000 07:51:30 +0100 (MET) Message-ID: <3A1A1CA1.A68EC76C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001120192244.03558@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 07:56:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EU wrapper entity for IAdd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 285796a472b1e5977a4fb5cdc6124ef7 Status: R X-Status: N Michael Riepe wrote:
> Hi *!
jo :-)

> Here's the first version of the EU_ASU `wrapper entity'.
> I also cleaned up the interface a little bit...
cool !

i think that you can reuse the wrapper whenever there is a SIMD unit.
In fact, the wrapper is required for imul, iadd, shl, inc and idiv (i think).
maybe it could have been done at a higher level, at the Xbar level ?

> 32-bit-only support is still missing (I have to change IAdd for that).
ok, don't worry. 32-bit is not an emergency.

> Ciao,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Tue Nov 21 07:56:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA01378 for ; Tue, 21 Nov 2000 08:29:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 08:29:50 +0100 (MET) Received: (qmail 7910 invoked by uid 0); 21 Nov 2000 06:51:56 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx03) with SMTP; 21 Nov 2000 06:51:56 -0000 X-eGroups-Return: sentto-1101623-1583-974789498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 21 Nov 2000 06:51:48 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 06:51:38 -0000 Received: (qmail 40559 invoked from network); 21 Nov 2000 06:51:37 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Nov 2000 06:51:37 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 21 Nov 2000 06:51:37 -0000 Received: from f-cpu.org (nas1-147.ras.club-internet.fr [195.36.192.147]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA00828 for ; Tue, 21 Nov 2000 07:51:35 +0100 (MET) Message-ID: <3A1A1CA6.E7818C35@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001120143723.19484@thrai.stud.uni-hannover.de> <000c01c05323$a59a7da0$7bcffea9@schlappi> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 07:56:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] inc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 30283cb7e1f0eb37ae202f60e8e500bf Status: R X-Status: N hi,

Erik Hansen wrote:
> > Erik, could you please send me a copy, too?
> Should have posted it in the mailing list, which i do now.
> Sorry for that! So have a look and send your comments.
i haven't looked "much" but the inc.html file is a nice idea :-)
however, the implementation is curious...

i'll try to make something more simple.
i wonder what is the use of Imux, Omux and scan...

What i had in mind was roughly that :
- 1 XOR stage (that could be XORed too... 3-input XOR ?)
- 3 stages of carry
- 1 final stage of XOR (that can also be inverted if necessary, but this
is less important because it can overlap the precedent stages).

then, if there is some "room" left (pipe depth), we can play and try
to implement the last propositions of the manual. Ths first goal
was really to make the fastes INC/DEC possible. if the min/max instructions are
too long, the pipe can be split. Anyway, you seem to have done some big work,
it will require much time to analyse it completely.

thanks for the effort and thanks too for trying to compete with Michael :-P

> So long
> Erik
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Michael Riepe Tue Nov 21 03:01:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00347 for ; Tue, 21 Nov 2000 15:46:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 15:46:35 +0100 (MET) Received: (qmail 1930 invoked by uid 0); 21 Nov 2000 12:52:22 -0000 Received: from f19.egroups.com (64.211.240.234) by mx19.rz2.gmx.net (mx19) with SMTP; 21 Nov 2000 12:52:22 -0000 X-eGroups-Return: sentto-1101623-1585-974811128-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 21 Nov 2000 12:52:19 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 12:52:07 -0000 Received: (qmail 20623 invoked from network); 21 Nov 2000 12:52:07 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 21 Nov 2000 12:52:07 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.146) by mta2 with SMTP; 21 Nov 2000 12:51:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA01944; Tue, 21 Nov 2000 03:01:36 +0100 Message-ID: <20001121030136.35869@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001120143723.19484@thrai.stud.uni-hannover.de> <000c01c05323$a59a7da0$7bcffea9@schlappi> <20001121024818.32252@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: <20001121024818.32252@thrai.stud.uni-hannover.de>; from Michael Riepe on Tue, Nov 21, 2000 at 02:48:18AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 03:01:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] inc Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 934d035ac5c7c816659654171c26a7ee Status: R X-Status: N Quoting myself...

> There's *always* something you didn't think of ;)

Sad but true ;)

When I tried to feed inc.vhdl into Vanilla VHDL, it complained about
the declarative sections inside `generate' statements, i.e. the use of
`generate ... begin ... end generate;'.  Sigh.  It would be great if you
could use explicit blocks inside generate blocks if (and only if) you
need to declare local signals (yes I know that this is a legal VHDL'93
feature -- but I also know that most tools are far from being perfect).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Tue Nov 21 01:29:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00350 for ; Tue, 21 Nov 2000 15:46:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 15:46:36 +0100 (MET) Received: (qmail 17443 invoked by uid 0); 21 Nov 2000 12:52:59 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx23) with SMTP; 21 Nov 2000 12:52:59 -0000 X-eGroups-Return: sentto-1101623-1587-974811168-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 21 Nov 2000 12:52:55 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 12:52:48 -0000 Received: (qmail 39101 invoked from network); 21 Nov 2000 12:52:48 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 21 Nov 2000 12:52:48 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.146) by mta2 with SMTP; 21 Nov 2000 12:52:46 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01640; Tue, 21 Nov 2000 01:29:53 +0100 Message-ID: <20001121012953.40361@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A17337C.27120D2C@lvdi.net> <20001119161246.17586@thrai.stud.uni-hannover.de> <20001120213416.C28424@bocal.cs.univ-paris8.fr> X-Mailer: Mutt 0.84e In-Reply-To: <20001120213416.C28424@bocal.cs.univ-paris8.fr>; from Paul Marques Mota on Mon, Nov 20, 2000 at 09:34:16PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 01:29:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: faf606c4df788e1ed2b1dd14309a5ea0 Status: R X-Status: N On Mon, Nov 20, 2000 at 09:34:16PM +0100, Paul Marques Mota wrote:

> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=f-cpu

Seems to be unavailable :(

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Tue Nov 21 02:48:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00353 for ; Tue, 21 Nov 2000 15:46:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 21 Nov 2000 15:46:37 +0100 (MET) Received: (qmail 27771 invoked by uid 0); 21 Nov 2000 12:53:17 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx16) with SMTP; 21 Nov 2000 12:53:17 -0000 X-eGroups-Return: sentto-1101623-1586-974811165-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 21 Nov 2000 12:53:02 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 12:52:45 -0000 Received: (qmail 77917 invoked from network); 21 Nov 2000 12:52:45 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 21 Nov 2000 12:52:45 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.146) by mta2 with SMTP; 21 Nov 2000 12:52:42 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01887; Tue, 21 Nov 2000 02:48:18 +0100 Message-ID: <20001121024818.32252@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001120143723.19484@thrai.stud.uni-hannover.de> <000c01c05323$a59a7da0$7bcffea9@schlappi> X-Mailer: Mutt 0.84e In-Reply-To: <000c01c05323$a59a7da0$7bcffea9@schlappi>; from Erik Hansen on Mon, Nov 20, 2000 at 07:56:41PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 02:48:18 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] inc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 094dce21a49ee07d80f14cab2d288f12 Status: R X-Status: N On Mon, Nov 20, 2000 at 07:56:41PM +0100, Erik Hansen wrote:
> > Erik, could you please send me a copy, too?
>
> Should have posted it in the mailing list, which i do now.
> Sorry for that!
> So have a look and send your comments.

You shouldn't ask for comments -- you might get them ;)

[quoting from inc.vhdl]
> --    Normally inc could be done with an logic depth of= d=3D4 (3 for carry, 1 for
> --    increment) inc and dec together would need d=3D6 = (1 input inv., 3 carry,
> --    1 increment, 1 output inv) Together with the muxe= s for input and output
> --    and the compare logic inc needs even more time :-= (

Try `balancing' the delays.  You can invert the temporary result *befo= re*
xor'ing with the increment vector (xor is a commutative operation!),
e.g. instead of

    t1 <=3D r1 xor (r1'range =3D> iin); -- d=3D1
    t2 <=3D IncrementTree(t1);    &nb= sp;   -- d=3D4
    t3 <=3D t1 xor t2;      = ;          -- d=3D5
    r3 <=3D t3 xor (t3'range =3D> oin); -- d=3D6

you can use

    t1 <=3D r1 xor (r1'range =3D> iin); -- d=3D1
    t2 <=3D IncrementTree(t1);    &nb= sp;   -- d=3D4
    t3 <=3D t1 xor (t1'range =3D> oin); -- d=3D2
    r3 <=3D t3 xor t2;      = ;          -- d=3D5

et voil=E0.  If you pass t2 through an additional row of and2 gates th= at
mask off the whole vector when r1(r1'high) is '0', you will also get the `abs' instruction, with d=3D6.

[...]
> -- comments
> --
> --   cmple(i)
> --     these functions are not implementet

`cmple(a, b)' is `not cmpl(b, a)' -- which means that `cmple' is
redundant anyway.

[...]
> -- TO DO
> -- =3D=3D=3D=3D=3D
[...]
> -- * try to use smaller gates ( no 9 input and gates)

Yep.  Gates with 5...16 inputs count as d=3D2, and so on.  Try to= limit
yourself to 4 inputs (that is, to the components in my library --
it should be fairly complete, at least my original version was before
Whygee removed the components that are "not needed at the moment"= ;).

BTW: You need not write structural VHDL from the very beginning; I
usually start a design with a behavioural model (because that's easier
to understand, and it's also easier to play with alternatives, balance
delays and so on) and convert it later.  And finally, an equivalent behavioural model is also good documentation for the structural part :)

> -- * OPTIMIZE!
> -- * test,test,test
> -- (* change to nor and nand for CMOS optimisation)

Other target technologies may have different requirements, and code that is limited to and/or/not elements is MUCH easier to understand.  Synth= esis
tools should perform this kind of target-dependent optimizations anyway...<= BR>
> -- * I'm shure that there was still more to do..

There's *always* something you didn't think of ;)

(ok, I gotta read the rest of your code more carefully...)

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D"click
From Paul Marques Mota Tue Nov 21 21:13:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00302 for ; Wed, 22 Nov 2000 00:57:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 22 Nov 2000 00:57:35 +0100 (MET) Received: (qmail 11509 invoked by uid 0); 21 Nov 2000 20:14:08 -0000 Received: from hl.egroups.com (208.50.99.197) by mx12.rz2.gmx.net (mx12) with SMTP; 21 Nov 2000 20:14:08 -0000 X-eGroups-Return: sentto-1101623-1588-974837631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 21 Nov 2000 20:13:56 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 20:13:51 -0000 Received: (qmail 8192 invoked from network); 21 Nov 2000 20:13:50 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 21 Nov 2000 20:13:50 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta3 with SMTP; 21 Nov 2000 21:14:56 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13yJnQ-0004DH-00 for f-cpu@egroups.com; Tue, 21 Nov 2000 21:13:40 +0100 Received: from alpha16.bocal.cs.univ-paris8.fr ([192.168.3.20]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 13yJnQ-0001Rz-00 for f-cpu@egroups.com; Tue, 21 Nov 2000 21:13:40 +0100 Received: from mota by alpha16.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 13yJnP-0001FT-00 for f-cpu@egroups.com; Tue, 21 Nov 2000 21:13:39 +0100 To: f-cpu@egroups.com Message-ID: <20001121211339.A4089@bocal.cs.univ-paris8.fr> References: <3A17337C.27120D2C@lvdi.net> <20001119161246.17586@thrai.stud.uni-hannover.de> <20001120213416.C28424@bocal.cs.univ-paris8.fr> <20001121012953.40361@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.0.1i In-Reply-To: <20001121012953.40361@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Tue, Nov 21, 2000 at 01:29:53AM +0100 Sender: Paul MARQUES MOTA From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 21:13:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Java bytecode to FCPU native compiler idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 05f42bb225a92d83822097fe71e0826f Status: R X-Status: N On Tue, Nov 21, 2000 at 01:29:53AM +0100, Michael Riepe wrote:
>
> Seems to be unavailable :(
>

Sorry: you need to follow the link from the project home page:

http://sourceforge.net/cvs/?group_id=345

--
      Paul
eGroups Sponsor
click here
From Michael Riepe Tue Nov 21 14:33:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00326 for ; Wed, 22 Nov 2000 00:57:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 22 Nov 2000 00:57:42 +0100 (MET) Received: (qmail 21787 invoked by uid 0); 21 Nov 2000 23:00:00 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx05) with SMTP; 21 Nov 2000 23:00:00 -0000 X-eGroups-Return: sentto-1101623-1589-974847565-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 21 Nov 2000 22:59:42 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_1); 21 Nov 2000 22:59:24 -0000 Received: (qmail 50522 invoked from network); 21 Nov 2000 22:59:23 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 21 Nov 2000 22:59:23 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.148) by mta2 with SMTP; 21 Nov 2000 22:59:21 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00531; Tue, 21 Nov 2000 14:33:16 +0100 Message-ID: <20001121143316.14069@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001120192244.03558@thrai.stud.uni-hannover.de> <3A1A1CA1.A68EC76C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A1A1CA1.A68EC76C@f-cpu.org>; from Yann Guidon on Tue, Nov 21, 2000 at 07:56:33AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 21 Nov 2000 14:33:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EU wrapper entity for IAdd Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7b49e479086b987ed3d4851e09f719d7 Status: R X-Status: N On Tue, Nov 21, 2000 at 07:56:33AM +0100, Yann Guidon wrote:

> i think that you can reuse the wrapper whenever there is a SIMD unit.

That was my intent :)

> In fact, the wrapper is required for imul, iadd, shl, inc and idiv (i think).
> maybe it could have been done at a higher level, at the Xbar level ?

I thought about a TTA-like standard EU interface -- a number of `sockets'
where you can plug in the execution units.  They should all have the
same set of control lines (flags portion of instruction word, decoded
size bits and probably also the opcode itself), plus a (variable) number
of input/output ports.  Like LEGO :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Lee Salzman Thu Nov 23 12:48:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00432 for ; Mon, 27 Nov 2000 01:19:56 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:19:56 +0100 (MET) Received: (qmail 17951 invoked by uid 0); 23 Nov 2000 11:51:12 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx03) with SMTP; 23 Nov 2000 11:51:12 -0000 X-eGroups-Return: sentto-1101623-1590-974980265-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 23 Nov 2000 11:51:12 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 23 Nov 2000 11:51:04 -0000 Received: (qmail 8932 invoked from network); 23 Nov 2000 11:51:03 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 Nov 2000 11:51:03 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta3 with SMTP; 23 Nov 2000 12:52:09 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Thu, 23 Nov 2000 03:51:01 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A1D0406.F6FDC4BD@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 23 Nov 2000 06:48:22 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 962aba296f93ce61ee3c84045f51922f Status: R X-Status: N Again, to any and all interested:

http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu-2.tar.gz

Changes:
1) Correctly handles frame pointer, return address, etc.
2) Finally got GCC to live with only indirect jumps
3) General code cleanups and improvements
4) Removed 'build' macro in favor of directly implementing  
   loadaddr/loadcons
5) Few other miscellaneous instructions added

Caveats:
1) GCC is a despicably horrid mess...
2) GCC is full of bubble gum, tape, and staples...
3) GCC was eliminating perfectly good whole sections of
   code, and the only reason I can fathom it doing this
   right now is that it 'decided' the blocks were unused
   simply because it couldn't see the registers/indirect jumps
   pointing at them... Who needed that main loop of their program
   anyway? Bah.
4) There's still that silly problem with GCC not figuring out how
   to reload a constant when a conditional branch comes into play.
5) GCC totally bungs up loop-invariant code motion in the presence
   of indirect jumps, so F-CPU renders a lot of GCC moot.

</vent> </rant> </frustration>

Okay, unless anyone can wave a magic wand over this code and make
it work pristinely, I'm not going to touch it for a little while.

                        Lee
eGroups Sponsor
click here
From Yann Guidon Fri Nov 24 00:45:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00552 for ; Mon, 27 Nov 2000 01:20:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:20:23 +0100 (MET) Received: (qmail 14229 invoked by uid 0); 23 Nov 2000 23:41:14 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx08) with SMTP; 23 Nov 2000 23:41:14 -0000 X-eGroups-Return: sentto-1101623-1591-975022868-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 23 Nov 2000 23:41:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 23 Nov 2000 23:41:07 -0000 Received: (qmail 6925 invoked from network); 23 Nov 2000 23:41:07 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 Nov 2000 23:41:07 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 24 Nov 2000 00:42:12 -0000 Received: from f-cpu.org (nas3-123.aub.club-internet.fr [195.36.145.123]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA20638 for ; Fri, 24 Nov 2000 00:41:03 +0100 (MET) Message-ID: <3A1DAC31.63BEB4D4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 00:45:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cccc87143b66e93eb8c485b6efe643fd Status: R X-Status: N hi,

Lee Salzman wrote:
> Again, to any and all interested:
> http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu-2.tar.gz
i've downloaded it.

> Changes:
> 1) Correctly handles frame pointer, return address, etc.
cool :-P

> 2) Finally got GCC to live with only indirect jumps
pfiuh...

oh, btw, has anyone heard about the SH-5 ? it's a joint Hitachi-STMicro
core that implements the "split branch".

the f-cpu is more advanced than that because it also implements the
"split load/store" :-P

> 3) General code cleanups and improvements
please don't empty your dump bag in the environment ;-P

> 4) Removed 'build' macro in favor of directly implementing
>    loadaddr/loadcons
> 5) Few other miscellaneous instructions added
>
> Caveats:
> 1) GCC is a despicably horrid mess...
no kidding ... ;-)

> 2) GCC is full of bubble gum, tape, and staples...
> 3) GCC was eliminating perfectly good whole sections of
>    code, and the only reason I can fathom it doing this
>    right now is that it 'decided' the blocks were unused
>    simply because it couldn't see the registers/indirect jumps
>    pointing at them... Who needed that main loop of their program
>    anyway? Bah.
hum, yeah.

I think that a "dirty" remedy would be to generate a "dumb NOP".
NOP is a move to reg 0, if GCC doesn't detect that case/optimises it
by removing, you can put a move rpointer,r0 in the middle or end of
the loop. this way, you can pad in the case of a pipe bubble, and
GCC is happy.

> 4) There's still that silly problem with GCC not figuring out how
>    to reload a constant when a conditional branch comes into play.
well, if it works already, it is enough (i guess).

> 5) GCC totally bungs up loop-invariant code motion in the presence
>    of indirect jumps, so F-CPU renders a lot of GCC moot.

as long as the "compatibility" layer is preserved, it's ok.

> </vent> </rant> </frustration>
i understand and thank you very much.
you deserve a medail :-)

> Okay, unless anyone can wave a magic wand over this code and make
> it work pristinely, I'm not going to touch it for a little while.
pfiuh...

if i can figure how to use it, i'll start playing a bit.

I would like to use it to generate assembly dumps, and feed them
to a reparser for GNL (whenever it will exist...).

I think that functionality and stability should be more important than
performance because GCC will certainly never get the speed that
a f-cpu can reach. use asm and good coding rules if you want speed.
GNL is priority #2, just after the f-cpu, on my list.

>                                 Lee
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Lee Salzman Fri Nov 24 04:19:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00606 for ; Mon, 27 Nov 2000 01:20:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:20:37 +0100 (MET) Received: (qmail 19710 invoked by uid 0); 24 Nov 2000 03:22:30 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx23) with SMTP; 24 Nov 2000 03:22:30 -0000 X-eGroups-Return: sentto-1101623-1592-975036137-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 24 Nov 2000 03:22:29 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 03:22:16 -0000 Received: (qmail 22621 invoked from network); 24 Nov 2000 03:22:16 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 24 Nov 2000 03:22:16 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta3 with SMTP; 24 Nov 2000 04:23:21 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Thu, 23 Nov 2000 19:21:55 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A1DDE35.755DED1C@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 23 Nov 2000 22:19:17 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 47e5d4069c70a712dce36c773028ad74 Status: R X-Status: N Yann Guidon wrote:
>> 3) GCC was eliminating perfectly good whole sections of
>>    code, and the only reason I can fathom it doing this
>>    right now is that it 'decided' the blocks were unused
>>    simply because it couldn't see the registers/indirect jumps
>>    pointing at them... Who needed that main loop of their program
>>    anyway? Bah.
>hum, yeah.
>
>I think that a "dirty" remedy would be to generate a "dumb NOP".
>NOP is a move to reg 0, if GCC doesn't detect that case/optimises it
>by removing, you can put a move rpointer,r0 in the middle or end of
>the loop. this way, you can pad in the case of a pipe bubble, and
>GCC is happy.

Well, on that note, a better solution would ultimately be to
not let GCC know about such branches in the F-CPU. The way
I could imagine doing this is generating a generic instruction
that clobbers some dummy register (i.e. r0) but completely
represents the indirect jump, then generate a fake
jump instruction in tandem that uses the dummy register, so
GCC will be forced to lock them together. Later, an instruction
is generated for the generic instruction/indirect jump and
we simply output an empty string for the fake jump instruction
we planted in there. This could work and even maybe allow GCC
to do some decent and unhalf-assed optimization and would maybe
keep GCC from stupidly getting rid of the code. Since the indirect
jump will be represented as an "unspec" instruction, GCC won't
know its an indirect jump and so won't optimize it into a direct
one and all could be hypothetically well.

>> 4) There's still that silly problem with GCC not figuring out how
>>    to reload a constant when a conditional branch comes into play.
>well, if it works already, it is enough (i guess).

Actually, no, it causes GCC to do an abort (). It doesn't
quite work under those circumstances.

>I would like to use it to generate assembly dumps, and feed them
>to a reparser for GNL (whenever it will exist...).  
>
>I think that functionality and stability should be more important than
>performance because GCC will certainly never get the speed that
>a f-cpu can reach. use asm and good coding rules if you want speed.
>GNL is priority #2, just after the f-cpu, on my list.

Well, compilers are there so you don't have to code everything
in assembly. Remember: Computers should do what humans should not,
and humans should do what computers can not. :) Just because GCC
is a piece of trash doesn't mean all compilers suck. I was also
pondering making a small optimizer that just did some partial
redundancy elimination and hierarchical instruction scheduling,
but will see if the "unspec" kluge will make GCC behave like
a good little compiler before I do anything drastic.

On another note, I was seriously considering building a decent
optimizing compiler framework for some other stuff I'm working
on, so maybe this could work in with GNL and such. Who knows.

>>                                 Lee
>WHYGEE
                             Lee
eGroups Sponsor
click here
From Ben Franchuk Sun Nov 19 06:00:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00609 for ; Mon, 27 Nov 2000 01:20:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:20:38 +0100 (MET) Received: (qmail 9337 invoked by uid 0); 24 Nov 2000 05:07:55 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx14) with SMTP; 24 Nov 2000 05:07:55 -0000 X-eGroups-Return: sentto-1101623-1593-975042464-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 24 Nov 2000 05:07:51 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 05:07:43 -0000 Received: (qmail 11123 invoked from network); 24 Nov 2000 05:07:43 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 24 Nov 2000 05:07:43 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 24 Nov 2000 05:07:42 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA00310 for ; Thu, 23 Nov 2000 21:58:41 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A175E89.D7BAFC11@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 05:00:57 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a578c64fcafe5589dc0d22bf7b4b7555 Status: R X-Status: N Lee Salzman wrote:

> Well, compilers are there so you don't have to code everything
> in assembly. Remember: Computers should do what humans should not,
> and humans should do what computers can not. :) Just because GCC
> is a piece of trash doesn't mean all compilers suck. I was also
> pondering making a small optimizer that just did some partial
> redundancy elimination and hierarchical instruction scheduling,
> but will see if the "unspec" kluge will make GCC behave like
> a good little compiler before I do anything drastic.
>
> On another note, I was seriously considering building a decent
> optimizing compiler framework for some other stuff I'm working
> on, so maybe this could work in with GNL and such. Who knows.

One thing that I don't think any compilers do is to sort variables
by type. Most C models are - code, data,text, stack & heap.
This was ok for 16 bit processors like the PDP-11, but with
larger processors it makes more sense to map things this way.
code,simple variables,text,static arrays and records,stack & heap.
By separating arrays from simple variables the small quantity
of simple variables will generate short addressing modes rather
than full sized addresses.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Jeff Davies Fri Nov 24 16:20:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00753 for ; Mon, 27 Nov 2000 01:21:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:10 +0100 (MET) Received: (qmail 15002 invoked by uid 0); 24 Nov 2000 15:21:24 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx04) with SMTP; 24 Nov 2000 15:21:24 -0000 X-eGroups-Return: sentto-1101623-1594-975079227-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 24 Nov 2000 15:21:22 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 15:20:27 -0000 Received: (qmail 81225 invoked from network); 24 Nov 2000 15:20:24 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 24 Nov 2000 15:20:24 -0000 Received: from unknown (HELO cmailg4.svr.pol.co.uk) (195.92.195.174) by mta2 with SMTP; 24 Nov 2000 15:20:24 -0000 Received: from modem-123.adderall.dialup.pol.co.uk ([62.136.76.123] helo=tiglath.pileser.sumeria) by cmailg4.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13zKeD-0001LT-00 for f-cpu@egroups.com; Fri, 24 Nov 2000 15:20:22 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A1DDE35.755DED1C@lvdi.net> In-Reply-To: <3A1DDE35.755DED1C@lvdi.net> Message-Id: <00112415233405.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 15:20:23 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 71250dc57a101251b02abc54dc838784 Status: R X-Status: N On Fri, 24 Nov 2000, you wrote:
> Yann Guidon wrote:
> and humans should do what computers can not. :) Just because GCC
> is a piece of trash doesn't mean all compilers suck. I was also

This "peice of trash" is one of the core building blocks of the free software
world. If it's so crap, write a better one. What other compilers that  you know
of support more than one CPU? Visual C++ .... er no. Borland .... er no.

Saying something is a peice of trash is easy, suggesting a better way of doing
things is not.

Jeff Davies
eGroups Sponsor
click here
From Michael Riepe Fri Nov 24 18:30:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00882 for ; Mon, 27 Nov 2000 01:21:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:39 +0100 (MET) Received: (qmail 20102 invoked by uid 0); 24 Nov 2000 22:24:11 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx10) with SMTP; 24 Nov 2000 22:24:11 -0000 X-eGroups-Return: sentto-1101623-1596-975104646-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 24 Nov 2000 22:24:08 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:24:05 -0000 Received: (qmail 58331 invoked from network); 24 Nov 2000 22:24:05 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 24 Nov 2000 22:24:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.228) by mta1 with SMTP; 24 Nov 2000 22:24:02 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00451; Fri, 24 Nov 2000 18:30:29 +0100 Message-ID: <20001124183029.41472@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> <00112415233405.01164@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00112415233405.01164@tiglath.pileser.sumeria>; from Jeff Davies on Fri, Nov 24, 2000 at 03:20:23PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 18:30:29 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b58122857b92a2e14f305ca4112cab3f Status: R X-Status: N On Fri, Nov 24, 2000 at 03:20:23PM +0000, Jeff Davies wrote:
[gcc]
> This "peice of trash" is one of the core building blocks of the free software
> world. If it's so crap, write a better one. What other compilers that  you know
> of support more than one CPU? Visual C++ .... er no. Borland .... er no.

TenDRA, lcc, ...

BTW: talking about the `free software world' and then mentioning Visual C++
and Borland is, erm, at least strange.

> Saying something is a peice of trash is easy, suggesting a better way of doing
> things is not.

gcc *is* crap.  But IMHO it's still the best crap out of the set of free
craps, and I know pretty well how to deal with its crappiness (sp?).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Keyshaun Fri Nov 24 23:34:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00885 for ; Mon, 27 Nov 2000 01:21:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:40 +0100 (MET) Received: (qmail 10803 invoked by uid 0); 24 Nov 2000 22:34:09 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx09) with SMTP; 24 Nov 2000 22:34:09 -0000 X-eGroups-Return: sentto-1101623-1597-975105244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by b05.egroups.com with NNFMP; 24 Nov 2000 22:34:08 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:34:03 -0000 Received: (qmail 81532 invoked from network); 24 Nov 2000 22:34:02 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 24 Nov 2000 22:34:02 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 24 Nov 2000 23:35:07 -0000 Received: (qmail 18784 invoked from network); 24 Nov 2000 22:33:54 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 24 Nov 2000 22:33:54 -0000 X-Sender: To: In-Reply-To: <20001124183029.41472@thrai.stud.uni-hannover.de> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 15:34:00 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 47612bd5f908868c2682c9e04e524ed9 Status: R X-Status: N How helpful is the $35 "Using and Porting GNU CC 2.95" that can be
obtained at www.gnu.org?  Does GCC still have its nuances that really
don't make much sense until you have done it a dozen times?  I admit, I
havn't tried anything as grand as making a new processor definition, but I
expect GNU docs to more closely reflect what will happen.  I am reminded
of my MFC docs that had not basis in reality with MSVC 6.  But I'll stop
now before I confess my previous relation to the dark side too much.

Shaun Kruger

On Fri, 24 Nov 2000, Michael Riepe wrote:

> On Fri, Nov 24, 2000 at 03:20:23PM +0000, Jeff Davies wrote:
> [gcc]
> > This "peice of trash" is one of the core building blocks of the free software
> > world. If it's so crap, write a better one. What other compilers that  you know
> > of support more than one CPU? Visual C++ .... er no. Borland .... er no.
>
> TenDRA, lcc, ...
>
> BTW: talking about the `free software world' and then mentioning Visual C++
> and Borland is, erm, at least strange.
>
> > Saying something is a peice of trash is easy, suggesting a better way of doing
> > things is not.
>
> gcc *is* crap.  But IMHO it's still the best crap out of the set of free
> craps, and I know pretty well how to deal with its crappiness (sp?).
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>
eGroups Sponsor
click here
From "Marco Al" Fri Nov 24 23:45:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00888 for ; Mon, 27 Nov 2000 01:21:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:41 +0100 (MET) Received: (qmail 3714 invoked by uid 0); 24 Nov 2000 22:40:40 -0000 Received: from ho.egroups.com (208.50.99.200) by mx06.rz2.gmx.net (mx06) with SMTP; 24 Nov 2000 22:40:40 -0000 X-eGroups-Return: sentto-1101623-1598-975105591-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 24 Nov 2000 22:39:56 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:39:51 -0000 Received: (qmail 66398 invoked from network); 24 Nov 2000 22:39:51 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 24 Nov 2000 22:39:51 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 24 Nov 2000 22:39:49 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id XAA00337 for ; Fri, 24 Nov 2000 23:39:46 +0100 (MET) Message-ID: <000d01c05668$512d3a80$29e65982@student.utwente.nl> To: References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 23:45:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6cd4b5079774a353a78c82793cdff1a Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> oh, btw, has anyone heard about the SH-5 ? it's a joint Hitachi-STMicro
> core that implements the "split branch".

Did you know them Russians (Elbrus) were doing it in the nineties? :)

Marco
eGroups Sponsor
click here
From Yann Guidon Fri Nov 24 23:46:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00891 for ; Mon, 27 Nov 2000 01:21:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:41 +0100 (MET) Received: (qmail 17154 invoked by uid 0); 24 Nov 2000 22:41:27 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx21) with SMTP; 24 Nov 2000 22:41:27 -0000 X-eGroups-Return: sentto-1101623-1599-975105675-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ej.egroups.com with NNFMP; 24 Nov 2000 22:41:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:41:15 -0000 Received: (qmail 96631 invoked from network); 24 Nov 2000 22:41:14 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 24 Nov 2000 22:41:14 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 24 Nov 2000 22:41:14 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA01936 for ; Fri, 24 Nov 2000 23:41:11 +0100 (MET) Message-ID: <3A1EEFBB.25B0A596@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 23:46:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 62e8124dd7cbb30062be7caf96ab5ce8 Status: R X-Status: N re-hi,

Lee Salzman wrote:
> >NOP is a move to reg 0, if GCC doesn't detect that case/optimises it
> >by removing, you can put a move rpointer,r0 in the middle or end of
> >the loop. this way, you can pad in the case of a pipe bubble, and
> >GCC is happy.
>
> Well, on that note, a better solution would ultimately be to
> not let GCC know about such branches in the F-CPU. The way
> I could imagine doing this is generating a generic instruction
> that clobbers some dummy register (i.e. r0) but completely
> represents the indirect jump, then generate a fake
> jump instruction in tandem that uses the dummy register, so
> GCC will be forced to lock them together.
with a good assembler, it is probably possible to define a
"void" function through the macro processor ...

> Later, an instruction
> is generated for the generic instruction/indirect jump and
> we simply output an empty string for the fake jump instruction
> we planted in there. This could work and even maybe allow GCC
> to do some decent and unhalf-assed optimization and would maybe
> keep GCC from stupidly getting rid of the code. Since the indirect
> jump will be represented as an "unspec" instruction, GCC won't
> know its an indirect jump and so won't optimize it into a direct
> one and all could be hypothetically well.
i guess that your newest version is good, but i don't know how to test it...

> >I think that functionality and stability should be more important than
> >performance because GCC will certainly never get the speed that
> >a f-cpu can reach. use asm and good coding rules if you want speed.
> >GNL is priority #2, just after the f-cpu, on my list.
>
> Well, compilers are there so you don't have to code everything
> in assembly.
that was not the point. GNL works at a similar level as the RTL.

> Remember: Computers should do what humans should not,
> and humans should do what computers can not. :)
"but" they need each other's help ...

> Just because GCC
> is a piece of trash doesn't mean all compilers suck.
either they are trash or they are too expensive ;-)
remember DEC's ALPHA own compiler ?

> I was also
> pondering making a small optimizer that just did some partial
> redundancy elimination and hierarchical instruction scheduling,
no need...
> but will see if the "unspec" kluge will make GCC behave like
> a good little compiler before I do anything drastic.
>
> On another note, I was seriously considering building a decent
> optimizing compiler framework for some other stuff I'm working
> on, so maybe this could work in with GNL and such. Who knows.
i hope to find some hours here or there to advance on that ground.
i can't do everything... i have to get some money too :-)
Anyway, the best start is to make a good draft before starting coding.

>                                    Lee
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Fri Nov 24 23:46:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00894 for ; Mon, 27 Nov 2000 01:21:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:42 +0100 (MET) Received: (qmail 2833 invoked by uid 0); 24 Nov 2000 22:42:19 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx24) with SMTP; 24 Nov 2000 22:42:19 -0000 X-eGroups-Return: sentto-1101623-1600-975105676-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 24 Nov 2000 22:41:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:41:16 -0000 Received: (qmail 98196 invoked from network); 24 Nov 2000 22:41:16 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 24 Nov 2000 22:41:16 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 24 Nov 2000 23:42:21 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA13416 for ; Fri, 24 Nov 2000 23:41:13 +0100 (MET) Message-ID: <3A1EEFBC.90B3C955@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 24 Nov 2000 23:46:20 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 71826125bd1911853851965b8334d0fa Status: R X-Status: N hi !

Many thanks to Lee for his efforts, but can you please
do me a small favor ? can you publish your files at a
unique URL ? this way, i'll point to your file from
the f-cpu.org page, and we'll access the latest version only.
If you change the filename all the time, it's like
shooting a moving target...
thanks :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sat Nov 25 00:04:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00900 for ; Mon, 27 Nov 2000 01:21:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:44 +0100 (MET) Received: (qmail 8818 invoked by uid 0); 24 Nov 2000 23:00:56 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx21) with SMTP; 24 Nov 2000 23:00:56 -0000 X-eGroups-Return: sentto-1101623-1601-975106786-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 24 Nov 2000 22:59:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 24 Nov 2000 22:59:45 -0000 Received: (qmail 8548 invoked from network); 24 Nov 2000 22:59:45 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 24 Nov 2000 22:59:45 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 24 Nov 2000 22:59:45 -0000 Received: from f-cpu.org (nas1-205.aub.club-internet.fr [195.36.150.205]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA29571 for ; Fri, 24 Nov 2000 23:59:41 +0100 (MET) Message-ID: <3A1EF411.B4E6C592@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 00:04:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 670866e44161ab0f8732ff06a33c0689 Status: R X-Status: N hi,

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > oh, btw, has anyone heard about the SH-5 ? it's a joint Hitachi-STMicro
> > core that implements the "split branch".
> Did you know them Russians (Elbrus) were doing it in the nineties? :)

no, i didn't know, but now, "split branch" seems so "natural" to me
that i wonder /why/ it was not done before... There were some machines
in the 60s that did some funky things with data pointers (address/data
register pairs and no load/store op) but they were close to today's
RISC CPUs and the HLLs didn't match. asm ruled at that time.
Maybe i'm a utopist, but otherwise i wouldn't be there ;-)

i wish i had more time...

> Marco

then Shaun :

> How helpful is the $35 "Using and Porting GNU CC 2.95" that can be
> obtained at www.gnu.org?
i have no idea.
>  Does GCC still have its nuances that really
> don't make much sense until you have done it a dozen times?  I admit, I
> havn't tried anything as grand as making a new processor definition, but I
> expect GNU docs to more closely reflect what will happen.
all i know and have read show that GCC is a pile of funky layers.
i wonder why it works, but it works. that's all what matters and
what is interesting : portability. it's the entry point.

>  I am reminded
> of my MFC docs that had not basis in reality with MSVC 6.  But I'll stop
> now before I confess my previous relation to the dark side too much.
better late than too late ;-) ok, i work in a Mentor Graphics Division,
i hope that i'll be able to make them understand the benefits of the
Free Software based distributions and, in return, make efforts in
the promotion of this model. It's a win-win situation.

> Shaun Kruger
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Ben Franchuk Sun Nov 19 14:11:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00909 for ; Mon, 27 Nov 2000 01:21:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:46 +0100 (MET) Received: (qmail 17937 invoked by uid 0); 25 Nov 2000 00:14:29 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx24) with SMTP; 25 Nov 2000 00:14:29 -0000 X-eGroups-Return: sentto-1101623-1602-975111202-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 25 Nov 2000 00:13:49 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 00:13:20 -0000 Received: (qmail 97151 invoked from network); 25 Nov 2000 00:13:20 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 25 Nov 2000 00:13:20 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 25 Nov 2000 00:13:20 -0000 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA06764 for ; Fri, 24 Nov 2000 17:04:15 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A17D165.E59FC090@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> <3A1EF411.B4E6C592@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 13:11:01 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 360e9b06d7aad05b21cdaf77420cf078 Status: R X-Status: N Yann Guidon wrote:
>
> hi,
>
> Marco Al wrote:
> > From: "Yann Guidon" <whygee@f-cpu.org>
> > > oh, btw, has anyone heard about the SH-5 ? it's a joint Hitachi-STMicro
> > > core that implements the "split branch".
> > Did you know them Russians (Elbrus) were doing it in the nineties? :)
>
> no, i didn't know, but now, "split branch" seems so "natural" to me
> that i wonder /why/ it was not done before.

Just what is a split branch?
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Jonathan Vaughn Sat Nov 25 08:04:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00948 for ; Mon, 27 Nov 2000 01:21:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:55 +0100 (MET) Received: (qmail 15314 invoked by uid 0); 25 Nov 2000 07:04:54 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx02) with SMTP; 25 Nov 2000 07:04:54 -0000 X-eGroups-Return: sentto-1101623-1603-975135889-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 25 Nov 2000 07:04:53 -0000 X-Sender: biosehn@mail.airmail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 07:04:49 -0000 Received: (qmail 1906 invoked from network); 25 Nov 2000 07:04:48 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 25 Nov 2000 07:04:48 -0000 Received: from unknown (HELO smtp.airmail.net) (209.196.123.2) by mta3 with SMTP; 25 Nov 2000 08:05:54 -0000 Received: from sehnsucht from [64.217.234.46] by smtp.airmail.net (/\##/\ Smail3.1.30.16 #30.12) with smtp for sender: id ; Sat, 25 Nov 2000 01:05:15 -0600 (CST) Message-Id: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> X-Sender: biosehn@mail.airmail.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com X-eGroups-From: Jonathan Vaughn From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 01:04:47 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] size of F/G chips Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7c8ea59cc62595371975ea0bffc67981 Status: R X-Status: N What is the most # of pins we can get away with on these chips, do you think?

and do we still use a general rule of thumb of ~25% or so being power/ground?

-JV

[note: new email, FYI]
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
click here
From Jonathan Vaughn Sat Nov 25 08:35:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00951 for ; Mon, 27 Nov 2000 01:21:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:56 +0100 (MET) Received: (qmail 31877 invoked by uid 0); 25 Nov 2000 07:35:21 -0000 Received: from jk.egroups.com (208.50.144.83) by mx19.rz2.gmx.net (mx19) with SMTP; 25 Nov 2000 07:35:21 -0000 X-eGroups-Return: sentto-1101623-1604-975137714-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 25 Nov 2000 07:35:19 -0000 X-Sender: biosehn@mail.airmail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 07:35:14 -0000 Received: (qmail 40671 invoked from network); 25 Nov 2000 07:35:14 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 25 Nov 2000 07:35:14 -0000 Received: from unknown (HELO smtp.airmail.net) (209.196.123.2) by mta3 with SMTP; 25 Nov 2000 08:36:19 -0000 Received: from sehnsucht from [64.217.234.46] by smtp.airmail.net (/\##/\ Smail3.1.30.16 #30.12) with smtp for sender: id ; Sat, 25 Nov 2000 01:35:40 -0600 (CST) Message-Id: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> X-Sender: biosehn@mail.airmail.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com X-eGroups-From: Jonathan Vaughn From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 01:35:12 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 86306a966ce5c99443157d6213c4d669 Status: R X-Status: N OK, I'm sure Intel has approximately 10 million patents on QDR, but how hard
would it be to make a QDR speed bus? maybe have a pair of DDR clocks, that
are 1/4th of the clock rate off..
(DDR) = DDR derived (i.e., PLL'd or such to be 1/2 of input cycle later)

          0   1   2   3   4   5
Clock #0  ____----____----____----
(DDR)    --____----____----____--
Clock #1  -____----____----____---
(DDR)    ---____----____----____-

this uses fewer traces than sending 4 clocks, wouldn't require as tricky
hardware
to sync up sampling 4 times per clock, ...

the 2 clocks and their DDR derivitives would be fed into some kind of edge
triggered OR gate, the output of which would clock the input registers for the
bus.. the order would be (in this example starting at 1), #0, #1, DDR #0,
DDR #1.

this combined with a bus 'speed' of say, 400MHz, would give us a hefty 6.4GB/s
of bandwidth from just a 32bit wide bus, for example. (400MHz * 4 * (32 bits/
8 bits))

this is good, as if we intend to share memory accross chips, a PC266 (133DDR),
2 channel SDRAM interface would yield 4.256GB/s per dual channel interface
(133*2*(128/8)).

even though neither the PC266 nor the QDR bus would ever be able to saturate
due to latency etc, it should be sufficient to prevent too much of a
performance
hit for accessing memory not directly attatched to a chip.

thoughts?

-JV


-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
click here
From "Albert Abramson" Sat Nov 25 10:41:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00963 for ; Mon, 27 Nov 2000 01:21:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:21:59 +0100 (MET) Received: (qmail 14601 invoked by uid 0); 25 Nov 2000 09:43:20 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx08) with SMTP; 25 Nov 2000 09:43:20 -0000 X-eGroups-Return: sentto-1101623-1605-975145316-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 25 Nov 2000 09:42:03 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 09:41:56 -0000 Received: (qmail 98850 invoked from network); 25 Nov 2000 09:41:55 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Nov 2000 09:41:55 -0000 Received: from unknown (HELO femail2.sdc1.sfba.home.com) (24.0.95.82) by mta1 with SMTP; 25 Nov 2000 09:41:55 -0000 Received: from [24.10.43.202] by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> for ; Sat, 25 Nov 2000 01:41:41 -0800 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 01:41:54 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 711d375e3b03ffb5d0f1771575619d70 Status: R X-Status: N Or just go to bipolar SRAM's in a COMA architecture and get 2ns latency for
every memory transaction.  1024-bit wide buses to each cache at 1000 MHz
each.  I believe that's 65,536 GB/sec of bandwidth without too much
pipelining.  Then build the internal data paths to match and use GaAs or
SiGe to get those 16GHz clock rates.

--Maxx

----------
>From: Jonathan Vaughn <biosehn@airmail.net>
>To: f-cpu@egroups.com
>Subject: [f-cpu] feasibility of QDR and so forth
>Date: Fri, Nov 24, 2000, 11:35 PM
>

> OK, I'm sure Intel has approximately 10 million patents on QDR, but how hard
> would it be to make a QDR speed bus? maybe have a pair of DDR clocks, that
> are 1/4th of the clock rate off..
> (DDR) = DDR derived (i.e., PLL'd or such to be 1/2 of input cycle later)
>
>           0   1   2   3   4   5
> Clock #0  ____----____----____----
>  (DDR)    --____----____----____--
> Clock #1  -____----____----____---
>  (DDR)    ---____----____----____-
>
> this uses fewer traces than sending 4 clocks, wouldn't require as tricky
> hardware
> to sync up sampling 4 times per clock, ...
>
> the 2 clocks and their DDR derivitives would be fed into some kind of edge
> triggered OR gate, the output of which would clock the input registers for the
> bus.. the order would be (in this example starting at 1), #0, #1, DDR #0,
> DDR #1.
>
> this combined with a bus 'speed' of say, 400MHz, would give us a hefty 6.4GB/s
> of bandwidth from just a 32bit wide bus, for example. (400MHz * 4 * (32 bits/
> 8 bits))
>
> this is good, as if we intend to share memory accross chips, a PC266 (133DDR),
> 2 channel SDRAM interface would yield 4.256GB/s per dual channel interface
> (133*2*(128/8)).
>
> even though neither the PC266 nor the QDR bus would ever be able to saturate
> due to latency etc, it should be sufficient to prevent too much of a
> performance
> hit for accessing memory not directly attatched to a chip.
>
> thoughts?
>
> -JV
>
>
> -----------------------------------------------------
> Click here for Free Video!!
> http://www.gohip.com/free_video/
>
>
>
>
>

eGroups Sponsor
click here
From Nicolas Boulay Sat Nov 25 13:37:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00975 for ; Mon, 27 Nov 2000 01:22:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:02 +0100 (MET) Received: (qmail 710 invoked by uid 0); 25 Nov 2000 12:34:04 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx23) with SMTP; 25 Nov 2000 12:34:04 -0000 X-eGroups-Return: sentto-1101623-1607-975155636-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 25 Nov 2000 12:33:58 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 12:33:56 -0000 Received: (qmail 3327 invoked from network); 25 Nov 2000 12:33:56 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Nov 2000 12:33:56 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 25 Nov 2000 12:33:56 -0000 Received: from ifrance.com (nas22-143.vlt.club-internet.fr [195.36.172.143]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA13187 for ; Sat, 25 Nov 2000 13:33:47 +0100 (MET) Message-ID: <3A1FB274.BA6BA4BD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> <3A1EF411.B4E6C592@f-cpu.org> <3A17D165.E59FC090@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 13:37:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cb9c604d382343df2605f9d4f4e7be44 Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Yann Guidon wrote:
> >
> > hi,
> >
> > Marco Al wrote:
> > > From: "Yann Guidon" <whygee@f-cpu.org>
> > > > oh, btw, has anyone heard about the SH-5 ? it's a joint= Hitachi-STMicro
> > > > core that implements the "split branch".
> > > Did you know them Russians (Elbrus) were doing it in the nin= eties? :)
> >
> > no, i didn't know, but now, "split branch" seems so &qu= ot;natural" to me
> > that i wonder /why/ it was not done before.
>
> Just what is a split branch?

Very goog question ? Whygee ?

> Ben.
nicO
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>

eGroups Sponsor=
3D"click
From Nicolas Boulay Sat Nov 25 13:37:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00978 for ; Mon, 27 Nov 2000 01:22:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:02 +0100 (MET) Received: (qmail 769 invoked by uid 0); 25 Nov 2000 12:34:07 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx23) with SMTP; 25 Nov 2000 12:34:07 -0000 X-eGroups-Return: sentto-1101623-1606-975155635-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 25 Nov 2000 12:33:59 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 12:33:55 -0000 Received: (qmail 96938 invoked from network); 25 Nov 2000 12:33:54 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 25 Nov 2000 12:33:54 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 25 Nov 2000 12:33:54 -0000 Received: from ifrance.com (nas22-143.vlt.club-internet.fr [195.36.172.143]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA06743 for ; Sat, 25 Nov 2000 13:33:52 +0100 (MET) Message-ID: <3A1FB278.D28059F@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 13:37:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5f7a18ad26865c2f87e42d73edda5610 Status: R X-Status: N Bipolar SRAM ? I believe that we need more than 64 Ko of memory ;P(and
we don't need a hotplat)! And i don't think, i will buy 2000 =80 the
memory chip (RDRAM is half this price and nobody want to buy it ;) ).

nicO

Albert Abramson a =E9crit :
>
> Or just go to bipolar SRAM's in a COMA architecture and get 2ns latenc= y for
> every memory transaction.  1024-bit wide buses to each cache at 1= 000 MHz
> each.  I believe that's 65,536 GB/sec of bandwidth without too mu= ch
> pipelining.  Then build the internal data paths to match and use = GaAs or
> SiGe to get those 16GHz clock rates.
>
> --Maxx
>
> ----------
> >From: Jonathan Vaughn <biosehn@airmail.net>
> >To: f-cpu@egroups.com
> >Subject: [f-cpu] feasibility of QDR and so forth
> >Date: Fri, Nov 24, 2000, 11:35 PM
> >
>
> > OK, I'm sure Intel has approximately 10 million patents on QDR, b= ut how hard
> > would it be to make a QDR speed bus? maybe have a pair of DDR clo= cks, that
> > are 1/4th of the clock rate off..
> > (DDR) =3D DDR derived (i.e., PLL'd or such to be 1/2 of input cyc= le later)
> >
> >           0&nbs= p;  1   2   3   4   5
> > Clock #0  ____----____----____----
> >  (DDR)    --____----____----____--
> > Clock #1  -____----____----____---
> >  (DDR)    ---____----____----____-
> >
> > this uses fewer traces than sending 4 clocks, wouldn't require as= tricky
> > hardware
> > to sync up sampling 4 times per clock, ...
> >
> > the 2 clocks and their DDR derivitives would be fed into some kin= d of edge
> > triggered OR gate, the output of which would clock the input regi= sters for the
> > bus.. the order would be (in this example starting at 1), #0, #1,= DDR #0,
> > DDR #1.
> >
> > this combined with a bus 'speed' of say, 400MHz, would give us a = hefty 6.4GB/s
> > of bandwidth from just a 32bit wide bus, for example. (400MHz * 4= * (32 bits/
> > 8 bits))
> >
> > this is good, as if we intend to share memory accross chips, a PC= 266 (133DDR),
> > 2 channel SDRAM interface would yield 4.256GB/s per dual channel = interface
> > (133*2*(128/8)).
> >
> > even though neither the PC266 nor the QDR bus would ever be able = to saturate
> > due to latency etc, it should be sufficient to prevent too much o= f a
> > performance
> > hit for accessing memory not directly attatched to a chip.
> >
> > thoughts?
> >
> > -JV
> >
> >
> > -----------------------------------------------------
> > Click here for Free Video!!
> > http://www.gohip.com= /free_video/
> >
> >
> >
> >
> >
>

eGroups Sponsor=
3D"click
From "Albert Abramson" Sat Nov 25 14:44:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00981 for ; Mon, 27 Nov 2000 01:22:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:04 +0100 (MET) Received: (qmail 20602 invoked by uid 0); 25 Nov 2000 13:45:15 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx02) with SMTP; 25 Nov 2000 13:45:15 -0000 X-eGroups-Return: sentto-1101623-1608-975159865-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 25 Nov 2000 13:44:36 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 13:44:24 -0000 Received: (qmail 96887 invoked from network); 25 Nov 2000 13:44:24 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 25 Nov 2000 13:44:24 -0000 Received: from unknown (HELO femail2.sdc1.sfba.home.com) (24.0.95.82) by mta2 with SMTP; 25 Nov 2000 13:44:24 -0000 Received: from [24.10.43.202] by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001125134410.NGTS6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> for ; Sat, 25 Nov 2000 05:44:10 -0800 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20001125134410.NGTS6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 05:44:22 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0e1fad4f7cbbfc21d1d8631af0716b1d Status: R X-Status: N That's my American sense of humor.  It's the use of sarcasm to point o= ut a
trend in f-cpu towards the unreasonable approaches.  It's like saying,=
"Let's open up the barrel shifter bottleneck!"

--Maxx

Vote Libertarian and win a free country!   www.lp.org

----------
>From: Nicolas Boulay <nicolas.boulay@ifrance.com>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] feasibility of QDR and so forth
>Date: Sat, Nov 25, 2000, 4:37 AM
>

> Bipolar SRAM ? I believe that we need more than 64 Ko of memory ;P(and=
> we don't need a hotplat)! And i don't think, i will buy 2000 =80 the > memory chip (RDRAM is half this price and nobody want to buy it ;) ).<= BR> >
> nicO
>
> Albert Abramson a =E9crit :
>>
>> Or just go to bipolar SRAM's in a COMA architecture and get 2ns la= tency for
>> every memory transaction.  1024-bit wide buses to each cache = at 1000 MHz
>> each.  I believe that's 65,536 GB/sec of bandwidth without to= o much
>> pipelining.  Then build the internal data paths to match and = use GaAs or
>> SiGe to get those 16GHz clock rates.
>>
>> --Maxx
>>
>> ----------
>> >From: Jonathan Vaughn <biosehn@airmail.net>
>> >To: f-cpu@egroups.com
>> >Subject: [f-cpu] feasibility of QDR and so forth
>> >Date: Fri, Nov 24, 2000, 11:35 PM
>> >
>>
>> > OK, I'm sure Intel has approximately 10 million patents on QD= R, but how
hard
>> > would it be to make a QDR speed bus? maybe have a pair of DDR= clocks, that
>> > are 1/4th of the clock rate off..
>> > (DDR) =3D DDR derived (i.e., PLL'd or such to be 1/2 of input= cycle later)
>> >
>> >           0=    1   2   3   4   5
>> > Clock #0  ____----____----____----
>> >  (DDR)    --____----____----____--
>> > Clock #1  -____----____----____---
>> >  (DDR)    ---____----____----____-
>> >
>> > this uses fewer traces than sending 4 clocks, wouldn't requir= e as tricky
>> > hardware
>> > to sync up sampling 4 times per clock, ...
>> >
>> > the 2 clocks and their DDR derivitives would be fed into some= kind of edge
>> > triggered OR gate, the output of which would clock the input = registers for
the
>> > bus.. the order would be (in this example starting at 1), #0,= #1, DDR #0,
>> > DDR #1.
>> >
>> > this combined with a bus 'speed' of say, 400MHz, would give u= s a hefty
6.4GB/s
>> > of bandwidth from just a 32bit wide bus, for example. (400MHz= * 4 * (32
bits/
>> > 8 bits))
>> >
>> > this is good, as if we intend to share memory accross chips, = a PC266
(133DDR),
>> > 2 channel SDRAM interface would yield 4.256GB/s per dual chan= nel interface
>> > (133*2*(128/8)).
>> >
>> > even though neither the PC266 nor the QDR bus would ever be a= ble to
saturate
>> > due to latency etc, it should be sufficient to prevent too mu= ch of a
>> > performance
>> > hit for accessing memory not directly attatched to a chip. >> >
>> > thoughts?
>> >
>> > -JV
>> >
>> >
>> > -----------------------------------------------------
>> > Click here for Free Video!!
>> > http://www.gohip= .com/free_video/
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
>

eGroups Sponsor=
3D"click
From Yann Guidon Sat Nov 25 16:45:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01047 for ; Mon, 27 Nov 2000 01:22:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:20 +0100 (MET) Received: (qmail 12168 invoked by uid 0); 25 Nov 2000 15:40:45 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx02) with SMTP; 25 Nov 2000 15:40:45 -0000 X-eGroups-Return: sentto-1101623-1610-975166829-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 25 Nov 2000 15:40:43 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 15:40:29 -0000 Received: (qmail 65257 invoked from network); 25 Nov 2000 15:40:29 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 25 Nov 2000 15:40:29 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 25 Nov 2000 15:40:28 -0000 Received: from f-cpu.org (nas1-171.ras.club-internet.fr [195.36.192.171]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA18449 for ; Sat, 25 Nov 2000 16:40:24 +0100 (MET) Message-ID: <3A1FDE9B.FF38EE06@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 16:45:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] size of F/G chips Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2f8198bb833d5a3c50eabfd87dccd46f Status: R X-Status: N hello,

Jonathan Vaughn wrote:
> What is the most # of pins we can get away with on these chips, do you think?
>
> and do we still use a general rule of thumb of ~25% or so being power/ground?

If you remember last year, we tried something with a Socket7 package,
315 pins (?) and easy-to-find ZIF, but /not/ compatible with PCs.
it was more or less routable with  a high quality, 6-layers PCB.

Now i am investigating a new approach, based on the same architecture,
but with higher density and potentially faster signals (shorter traces).
It is based on what i see at work, and it gives me a good confindence
that it is feasible, provided we have several thousands of bucks
(this is not our problem because this would certainly be done with
some "collaborations" with commercial companies).

general description : mono-CPU PCB with two high-speed 64-bit SDRAM buses
and one 32-bit I/O bus.

changes : the CPU is in a BGA352 package, it has a smaller footprint and
the PCB can be smaller. The initial 128S-b DRAM bus has been split into 2
independent buses due to routing and trace length troubles. The SDRAM chips
are more recent, high-speed and wide chips (32-b data bus, 133 or 266 MHz
depending on the availability of the parts). To reduce skew and other nasty
stuffs, they are directly soldered by pairs of pairs, a 2*32-bit pair on each side
of the board. It increases the density and we can access 8 independent banks
(1 2*32-b chip pair has 4 banks each).

The same old rule-of-thumb about the ground/power pins applies, about 20 or 25%
of the BGA pins are used, but it depends on a lot of parameters.

Since there is no pin left for an external cache, we will need a large one on-chip,
but this is not a big problem because the funders propose their own libraries.
That's where we will decide what kind of RAM we want, eDRAM or usual SRAM etc...


other details : approx. size of the module is 5*9 cm. It could use an ol cheap DRAM
socket for connexion with I/Os (approx number of signals is 70) so there is
no connector to solder on the PCB. I don't know about the PCB manufacturing, but
the total cost is estimated around $150 (with a big 70% uncertainty factor) but
it will vary with the quantity or quality... Soldering the SDRAM on one PCB side
only might reduce the soldering cost but increase the PCB surface and cost...

The SDRAM chips would be 64Mbits parts so we would have 64Mbytes per board.
I don't know whether higher density parts will be available soon, but they
will be used instead, no replacement of the chip is possible by the user.

<!!!!!!!!!!>

I stress on a very important point : testability. If we produce such chips, we
will have to proveide a (vector) testbench for the chips to the fundry
as well as a physical testbench (go/no-go + diagnostics) to the PCB maker.
Given the price of a single module and the relatively low price of our
work horsepower, this is a crucial point for the overal yield of the project.

</!!!!!!!!!!>

still on the testability issue : we should write #now# the vectors that will be used
to test the f-cpu chips in the fundry. We already have a testbench for most of
the units, but they are "only" proofs of concept. Michael Riepe's testbenches
can not be used in the fundry to test the chips, we need an exhaustive but much faster
way to determine whether a unit is damaged. we should make a BIST, a kind of embedded
checker that will verify the chip when it's still on the waffer...


> -JV [note: new email, FYI]
WHYGEE (old good email)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sat Nov 25 16:45:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01050 for ; Mon, 27 Nov 2000 01:22:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:21 +0100 (MET) Received: (qmail 20447 invoked by uid 0); 25 Nov 2000 15:41:03 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx07) with SMTP; 25 Nov 2000 15:41:03 -0000 X-eGroups-Return: sentto-1101623-1609-975166828-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 25 Nov 2000 15:40:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 15:40:27 -0000 Received: (qmail 61917 invoked from network); 25 Nov 2000 15:40:27 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Nov 2000 15:40:27 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 25 Nov 2000 15:40:26 -0000 Received: from f-cpu.org (nas1-171.ras.club-internet.fr [195.36.192.171]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA00543 for ; Sat, 25 Nov 2000 16:40:22 +0100 (MET) Message-ID: <3A1FDE9A.F6C6DA5A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> <3A1EF411.B4E6C592@f-cpu.org> <3A17D165.E59FC090@jetnet.ab.ca> <3A1FB274.BA6BA4BD@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 16:45:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 455c911e2335bbd2acca1a41744c0723 Status: R X-Status: N hello,

Nicolas Boulay wrote:
> Ben Franchuk a =E9crit :
> > Yann Guidon wrote:
> > > Marco Al wrote:
> > > > From: "Yann Guidon" <whygee@f-cpu.org><= BR> nice cascade :-)

> > Just what is a split branch?
> Very goog question ? Whygee ?
yes, what ?

> > Ben.
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS: just kidding.

"split branch" is another technique to branch "quickly"= without
suffering from the latency of the memory. Other well known
ways are delayed branches and speculative execution.

"Delayed branches" only cover the pipeline latency. MIPS
used it at the start but their pipeline has become longer
so old SW would require recompiling and the newer chips would
need a "legacy" mode. The ALPHA doesn't use it because the
design team calculated that 4 parallel 7-stage pipelines
require 128 bytes of memory.

"Speculative execution" : we chose a direction and we execute
speculatively, hoping that the direction is the good one.
if the condition appears to be false (when the real condition
becomes available to the decoder), we decide if we unwind
the execution or not. It's used a lot in the Intel CPUs,
the PowerPC, and a lot of others.

A companion technique is the branch prediction : the goal
is : trying to predict whether the next branch will be taken
or not. you know the rest.


Now, "split branch" as implemented in the FC0 and the f-cpu
is a bit different : it is based on a prefetch/use pair
of instructions. The first instruction, knwon today as
"loadaddr", loads PC+4+value into a physical register.
Behind the scene, this value is also sent to the memory interface.
The CPU will fetch the data in memory, and might trigger a page
fault. When the data is available to the CPU (in the "fetcher" un= it),
it updates a little lookup table that "associates" the exact
location of the data with the physical register number.

Second act :
In the instruction flow, the decoder sees a jump instruction.
the unit looks up in the precedent table : if the indicated physical
register numbe is not present, it "re-calls" the prefetch (with a= ll
the penalties it means). If it is present, it takes almost no time
to retrieve the instructions pointed to by the table.


Split branches is a flexible way to jump to any location (it is
also used for function calls and returns). It can shadow both
the pipeline and the memory latencies (when correctly coded),
it doesn't require specific handling during a trap/fault/IRQ,
and it doesn't impact the coding style with CPU-version-specific
constraints (the pipeline can lengthen without needing to recode
everything, like with early MIPS).

I hope that it helps.
eGroups Sponsor=
3D"click
From Jeff Davies Sat Nov 25 16:46:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01056 for ; Mon, 27 Nov 2000 01:22:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:22 +0100 (MET) Received: (qmail 14127 invoked by uid 0); 25 Nov 2000 15:52:21 -0000 Received: from ej.egroups.com (64.211.240.230) by mx06.rz2.gmx.net (mx06) with SMTP; 25 Nov 2000 15:52:21 -0000 X-eGroups-Return: sentto-1101623-1611-975167523-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 25 Nov 2000 15:52:16 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 15:51:59 -0000 Received: (qmail 89840 invoked from network); 25 Nov 2000 15:51:56 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Nov 2000 15:51:56 -0000 Received: from unknown (HELO cmailg3.svr.pol.co.uk) (195.92.195.173) by mta1 with SMTP; 25 Nov 2000 15:51:56 -0000 Received: from modem-42.california.dialup.pol.co.uk ([62.137.56.42] helo=tiglath.pileser.sumeria) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13zhcE-0005LP-00 for f-cpu@egroups.com; Sat, 25 Nov 2000 15:51:51 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A1DDE35.755DED1C@lvdi.net> <00112415233405.01164@tiglath.pileser.sumeria> <20001124183029.41472@thrai.stud.uni-hannover.de> In-Reply-To: <20001124183029.41472@thrai.stud.uni-hannover.de> Message-Id: <00112515545307.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 15:46:38 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a5362026cf936742b74fae34ba50c86c Status: R X-Status: N On Fri, 24 Nov 2000, you wrote:
> On Fri, Nov 24, 2000 at 03:20:23PM +0000, Jeff Davies wrote:
> [gcc]
> > This "peice of trash" is one of the core building blocks of the free software
> > world. If it's so crap, write a better one. What other compilers that  you know
> > of support more than one CPU? Visual C++ .... er no. Borland .... er no.
>
> TenDRA, lcc, ...
??? never heard of them

> BTW: talking about the `free software world' and then mentioning Visual C++
> and Borland is, erm, at least strange.

I was pointing out commercial c++ compilers do less than gcc, and don't seem to
be better in any way.

>
> > Saying something is a peice of trash is easy, suggesting a better way of doing
> > things is not.
>
> gcc *is* crap.  But IMHO it's still the best crap out of the set of free
> craps, and I know pretty well how to deal with its crappiness (sp?).

You seem to imply the commercial stuff is better. I can;t say I've noticed a
huge difference, in fact, I have come across compile errors (and lack of
safety in places) with VC but not with gcc.
Borland seems to be insane about it's semicolons, but otherwise no better.
So, come on, what is crap about gcc? Is the structure wrong, does it not allow
sufficient optimisation ,.. or what?
I think it's pretty weak to complain about something without saying what it is
you don;t like about it.

If gcc isn;t going to cut the mustard with FCPU or other 64 bit cpus, lets look
at improving it rather than just calling it "crap". Lets be constructive.


>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

Jeff Davies
eGroups Sponsor
click here
From Ben Franchuk Sun Nov 19 22:04:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01071 for ; Mon, 27 Nov 2000 01:22:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:31 +0100 (MET) Received: (qmail 32454 invoked by uid 0); 25 Nov 2000 19:21:08 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx18) with SMTP; 25 Nov 2000 19:21:08 -0000 X-eGroups-Return: sentto-1101623-1612-975180058-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 25 Nov 2000 19:21:07 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 19:20:57 -0000 Received: (qmail 77930 invoked from network); 25 Nov 2000 19:20:56 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Nov 2000 19:20:56 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 25 Nov 2000 19:20:56 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA12127 for ; Sat, 25 Nov 2000 12:11:46 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A18405D.9CE2F999@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 21:04:29 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cb610f9c5c06fb73352405d224e2f038 Status: R X-Status: N Albert Abramson wrote:
>
> Or just go to bipolar SRAM's in a COMA architecture and get 2ns latency for
> every memory transaction.  1024-bit wide buses to each cache at 1000 MHz
> each.  I believe that's 65,536 GB/sec of bandwidth without too much
> pipelining.  Then build the internal data paths to match and use GaAs or
> SiGe to get those 16GHz clock rates.

Anybody for going back to ECL style logic for I/O. While ECL is power hungry
I don't think it will use more power than other logic over 500 MHZ, and
you don't have to worry about bus enable logic timing delays for Tri-state
buffers as the bus open collector type logic.It also may be easier of power
supplies, you have more current draw but don't have as large change in current
as other logic.

I favor a fast 2 phase clock and latches for I/O regardless of logic
used as latches are fast and simple. In my mind latches let data flow
thru a system and Flip/Flops stop data flow.

Also just what is the real speed of memory access time here?
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Yann Guidon Sat Nov 25 22:45:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01086 for ; Mon, 27 Nov 2000 01:22:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:34 +0100 (MET) Received: (qmail 6053 invoked by uid 0); 25 Nov 2000 21:41:28 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx05) with SMTP; 25 Nov 2000 21:41:28 -0000 X-eGroups-Return: sentto-1101623-1613-975188435-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 25 Nov 2000 21:40:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 21:40:34 -0000 Received: (qmail 96647 invoked from network); 25 Nov 2000 21:40:33 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Nov 2000 21:40:33 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 25 Nov 2000 21:40:33 -0000 Received: from f-cpu.org (nas3-124.aub.club-internet.fr [195.36.145.124]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA02304; Sat, 25 Nov 2000 22:40:22 +0100 (MET) Message-ID: <3A2032F8.2E08A0C0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com, hardlicense-discuss@seul.org From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 22:45:28 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] F-CPU guidelines Content-Type: multipart/mixed; boundary="------------7BAFC70F4408A119AF855D54" X-UIDL: 7d0e41791965ad165c90fa24cf8fd3fc Status: R X-Status: N --------------7BAFC70F4408A119AF855D54 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit As i'm trying to make a new vhdl bundle,
the old problem of the distribution licence
has resurfaced.

It is finally very heavy and not very useful
to rewrite something similar to the GPL so i have
found a way to bypass this : all the files are under
GPL or GFDL, the f-cpu part is moved to a charter
or convention, whatever you name it. It defines the
rules of the development teams and leaves a certain
degree of freedom for the people that want "only" to
comply with the GPL. Those who will want to make
a "real" F-CPU have to follow the guidelines : they are
not very restrictive in fact for those who are already
here, but this may be the conflict point for the eventual
distributors or funders who will "claim" to work with
the team. If they want the F-CPU logo on their chips,
they will have to obey some simple rules. This way, this
will discriminate the people who don't respect the F-CPU
philosophy, at least in the facts.

I have omitted the part about the URL because it has
now shifted to the SR_URL Special Register. I will try to
complete it as soon as possible.

please don't spare your remarks. I want to release a new
bundle as soon as possible. What do the subscribers think
about this approach ? Is a completely new licence possible ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS : I think that Graham Seaman can update his site with this mail
and the enclosed text.
eGroups Sponsor
click here
--------------7BAFC70F4408A119AF855D54 Content-Type: text/plain; charset=us-ascii; name="CHARTER.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CHARTER.txt" ~~~~~~~~~~~~~~~~~~~~~~~~~~~HEADER~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CHARTER.txt Revision : file created : nov. 23, 2000 by YG current version : nov. 23, 2000 by YG Like everything in the F-CPU project, it is a basis and subject for constructive discussions and it should not be considered as definitive. Everybody is asked to contribute to this decisive, non-technical side of the project. I have cut&pasted some parts of the previous "F-CPU licence proposal". It is still incomplete. ~~~~~~~~~~~~~~~~~~~~~~~~~INTRODUCTION~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Freedom CPU project (F-CPU for short) is the only fully parametised 64-bit SIMD CPU core available today in source code form. Not only it is designed to be able to replace (one day) the best existing RISC processors in workstations, but it is being developped in a net-community environment by students as well as professionals as a hobby. Because their work is performed for free, they want it to remain free, just like Linux or the GNU project. The purpose of this file is to introduce newcomers to the F-CPU design philosophy and basic rules. More about this can be read on the F-CPU mailing list(s) and manual. Because the GNU Public Licence covers most of the needs of the project, it is the only licence that you have to comply with. It determines the rights and duties concerning the distribution, modification, compilation etc. of the "source code" of the processor (that is : the VHDL sources contained in this tarball). However, the GPL doesn't apply to the "electronic" world and the implementors are completely free to do whatever they want with the derived physical devices. You don't have to read the rest of this file if you only want to use the files without modification. For example, it is not revelant if you just install the bundle and try to compile the files. However, if you modify a file, add a new file, adapt a file for compilation with a tool, build the circuit or add features, you should carefully read this text. This charter is intended to provide developpers with guidelines, "do and don't" rules that should be followed to keep the project up and running. If a chip is built from the F-CPU sources then distributed, the respect of these rules will determine if the chip can be labelled as "a F-CPU". The use of the F-CPU source files is completely free under the terms of the GPL, the implementation is not bound in any way, but the F-CPU development team follows these basic rules : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~GUIDELINES~~~~~~~~~~~~~~~~~~~~~~~~~ o "The name of the game is freedom". It is forbidden to forbid others. "One's freedom ends where other's freedom starts". These three well-known basic rules favor reciprocal respect and positive ununcumbered work. o We promote collaborative work, free communication and unconstrained sharing of knowledge and know-how. This project is not a way to earn money quickly and easily, but a mean to learn technics in a community, with the goal of redistributing the knowledge evenly. o The distribution, modification and knowledge of the sources (non physical forms of the design, as opposed to the "physical implementation" of this design) must not be bound or restricted in ANY way. o In particular, you need not be a customer of a F-CPU vendor in order to access the sources of any F-CPU version or derived work. o Similarly, in-progress works must be available upon a single request. An attempt to over-delay the transmission of the requested files can be interpreted as a "guilty" behaviour. o The reason for this break from the GPL principle is simple : the F-CPU is not the property of an individual or a company, but belongs to everybody. Anybody must be able to examine, use or modify any version of any document because it is not the exclusive property of a single person. If you have your kid in a kindergarten, you think it is normal to visit the location and see if your kid is safe or if nothing wrong can happen. Same goes with software that we write in community. o Do not promote secrecy. Just as the sources came to you openly, you should not promote secrets or hidden features. It is forbidden to patent existing features used in the F-CPU. The F-CPU forums and mailing lists provide you with different ways to share your remarks, additions, propositions, etc. Secrecy has no advantage in the F-CPU community and corresponds to a self-exclusion from the group. o Do not bind the files to a proprietary software or obscure file format. Anybody should be able to reuse your work without being forced to acquire a specific software. Standard formats are highly recommended (ISO, ANSI etc), GNU software is preferred, freeware or public domain is ok, too. If you use a "specific" software, you can add the required scripts or configuration files that interface the F-CPU source with said software. o When a source file is modified, the developer should update the comments and indicate his name, the date, and a short description of the modifications. It is the easiest way to keep track of the project's evolution. o When a source file is added to the F-CPU file pool, it must be distributed with the GPL. o Whenever a file is created or modified, the developper has to include his personal copyright notice. It is a crucial legal protection mechanism because different copyrights get thus inter-mixed. This strengthens the relations and dependcies between the developpers. If a legal problem arises, a single developper can not be attacked alone. o Please : document and comment your modifications or additions, because you can read and understand the existing sources. The lack of decent documentation, just like obfuscated source code, slows down the development team's work. o All documentations written about the F-CPU and the associated software must be distributed under the terms of the GFDL (GNU Free Documentation Licence). This applies to manuals, technical books, drafts or requests for comments (RFCs). o Personal opinions, articles or other individual expressions about the F-CPU are well covered by the copyright laws (that means that an article or conference doesn't need to be bound by the GFDL). o Even though the GLP allows to sell physical media containing GPL'd files, the present guidelines only allow it if the same files are available for free on the Internet with the conditions described here. This is consistent with the fact that the packaging of the files on a physical medium is a service only, it is not an exception to the present guidelines. o The modification of the F-CPU design is allowed under the sole condition that you agree to and respect these guidelines. You do not have to register yourself in a database, you do not need any authorization of any kind and you can do whatever you want with the F-CPU design, except : changing the copyright notices, altering these guidelines or use them against their spirit. o Unlike some "Open" standards and initiatives, you do not need to fill in a form, pay a fee or a licence to use the F-CPU design. In return, you may not restrict the direct access to the design that you have modified, even for the sake of collecting statistics or polling (or, in general, collecting individual/personal data or going through advertising pages). o to be continued... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These recommendations can be enforced through the copyright laws and are added to the terms of the GPL. --------------7BAFC70F4408A119AF855D54-- From "Marco Al" Sat Nov 25 22:50:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01089 for ; Mon, 27 Nov 2000 01:22:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:36 +0100 (MET) Received: (qmail 26156 invoked by uid 0); 25 Nov 2000 21:43:54 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 25 Nov 2000 21:43:54 -0000 X-eGroups-Return: sentto-1101623-1614-975188631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 25 Nov 2000 21:43:53 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 21:43:51 -0000 Received: (qmail 3411 invoked from network); 25 Nov 2000 21:43:50 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Nov 2000 21:43:50 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 25 Nov 2000 21:43:49 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id WAA07465 for ; Sat, 25 Nov 2000 22:43:45 +0100 (MET) Message-ID: <002901c05729$a95eeca0$29e65982@student.utwente.nl> To: References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> <3A1EF411.B4E6C592@f-cpu.org> <3A17D165.E59FC090@jetnet.ab.ca> <3A1FB274.BA6BA4BD@ifrance.com> <3A1FDE9A.F6C6DA5A@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 22:50:00 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 025c977843afe05d7e19cae120677a57 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> "split branch" is another technique to branch "quickly" without
> suffering from the latency of the memory. Other well known
> ways are delayed branches and speculative execution.

Personally I see it rather as a way to avoid the problem that you have to know
wether an instruction is a branch and what its target is before its even fully
decoded (if you dont want to create a bubble or necessitate a flush).

> "Speculative execution" : we chose a direction and we execute
> speculatively, hoping that the direction is the good one.
> if the condition appears to be false (when the real condition
> becomes available to the decoder), we decide if we unwind
> the execution or not. It's used a lot in the Intel CPUs,
> the PowerPC, and a lot of others.

If the conditional isnt available in time (not unlikely with short sequences and
wide superscalar processors) you might want it regardless. Elbrus for instance
still uses speculative execution, SH5 also speculatively fills the pipeline with
instructions according to how it thinks the branch will be taken.

> Second act :
> In the instruction flow, the decoder sees a jump instruction.
> the unit looks up in the precedent table : if the indicated physical
> register numbe is not present, it "re-calls" the prefetch (with all
> the penalties it means). If it is present, it takes almost no time
> to retrieve the instructions pointed to by the table.

Almost no time?

What of conditional branches? Between it being fetched and before the
conditional can be checked theres quite a few clock ticks arent there? What is
the IF (and subsequent pipeline stages) doing in the meantime?

Marco
eGroups Sponsor
click here
From Yann Guidon Sat Nov 25 23:10:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01098 for ; Mon, 27 Nov 2000 01:22:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:39 +0100 (MET) Received: (qmail 22039 invoked by uid 0); 25 Nov 2000 22:05:18 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx01) with SMTP; 25 Nov 2000 22:05:18 -0000 X-eGroups-Return: sentto-1101623-1615-975189907-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 25 Nov 2000 22:05:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 22:05:07 -0000 Received: (qmail 52044 invoked from network); 25 Nov 2000 22:05:05 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 25 Nov 2000 22:05:05 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 25 Nov 2000 23:06:11 -0000 Received: from f-cpu.org (nas3-76.aub.club-internet.fr [195.36.145.76]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA05419 for ; Sat, 25 Nov 2000 23:05:01 +0100 (MET) Message-ID: <3A2038BF.AB2EAE0C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> <00112415233405.01164@tiglath.pileser.sumeria> <20001124183029.41472@thrai.stud.uni-hannover.de> <00112515545307.01164@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 23:10:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 715ddf79a2af3ed3d47d0bb0f16cb111 Status: R X-Status: N hi,

Jeff Davies wrote:
> On Fri, 24 Nov 2000, you wrote:
> > On Fri, Nov 24, 2000 at 03:20:23PM +0000, Jeff Davies wrote:
> > [gcc]
> I think it's pretty weak to complain about something without saying what it is
> you don;t like about it.
>
> If gcc isn;t going to cut the mustard with FCPU or other 64 bit cpus, lets look
> at improving it rather than just calling it "crap". Lets be constructive.

certainly.

Anyway, the gcc port seems to work to a certain extent and that's all it is good
for : portability reasons. If it works with legacy software, it's enough.

OTOH, the most important and constructive part of the project is the investment
in "graphical programming". I have that we'll have a good software soon that
will eat gcc's asm shit and spit useful code, after a graphical and interactive
verification by the user. let's find a solution with the precedent ways :
XML/SGML/XGML/whatever, GNL...

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Michael Riepe Sat Nov 25 15:01:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01101 for ; Mon, 27 Nov 2000 01:22:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:40 +0100 (MET) Received: (qmail 19224 invoked by uid 0); 25 Nov 2000 22:24:00 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 25 Nov 2000 22:24:00 -0000 X-eGroups-Return: sentto-1101623-1616-975191034-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 25 Nov 2000 22:23:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 22:23:54 -0000 Received: (qmail 81783 invoked from network); 25 Nov 2000 22:23:53 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 25 Nov 2000 22:23:53 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta3 with SMTP; 25 Nov 2000 23:24:46 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00515; Sat, 25 Nov 2000 15:01:57 +0100 Message-ID: <20001125150156.02372@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]> X-Mailer: Mutt 0.84e In-Reply-To: <20001125094141.LFGW6907.femail2.sdc1.sfba.home.com@[24.10.43.202]>; from Albert Abramson on Sat, Nov 25, 2000 at 01:41:54AM -0800 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 15:01:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fdc6449e2af830d269fa765345eb8071 Status: R X-Status: N On Sat, Nov 25, 2000 at 01:41:54AM -0800, Albert Abramson wrote:
> Or just go to bipolar SRAM's in a COMA architecture and get 2ns latency for
> every memory transaction.  1024-bit wide buses to each cache at 1000 MHz
> each.  I believe that's 65,536 GB/sec of bandwidth without too much
> pipelining.  Then build the internal data paths to match and use GaAs or
> SiGe to get those 16GHz clock rates.

Suffering from gigantomania?

I expect the first `real' FC0 chips to run at frequencies in the 100...500
MHz range (if we manage to build one in 2001).  Using cheap, 3 year old
technology also means that current CPUs will run 4 times as fast as ours
(in terms of clock speed), according to Moore's Law.

Get real, please.
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Sat Nov 25 14:45:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01104 for ; Mon, 27 Nov 2000 01:22:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:40 +0100 (MET) Received: (qmail 18384 invoked by uid 0); 25 Nov 2000 22:27:16 -0000 Received: from hj.egroups.com (208.50.99.212) by mx06.rz2.gmx.net (mx06) with SMTP; 25 Nov 2000 22:27:16 -0000 X-eGroups-Return: sentto-1101623-1617-975191166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 25 Nov 2000 22:26:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 22:26:06 -0000 Received: (qmail 86388 invoked from network); 25 Nov 2000 22:26:06 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 25 Nov 2000 22:26:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta3 with SMTP; 25 Nov 2000 23:26:37 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00471; Sat, 25 Nov 2000 14:45:25 +0100 Message-ID: <20001125144525.25816@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> X-Mailer: Mutt 0.84e In-Reply-To: <3.0.6.32.20001125013512.008fd180@mail.airmail.net>; from Jonathan Vaughn on Sat, Nov 25, 2000 at 01:35:12AM -0600 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 14:45:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4462ebd3ded9e92ad8760c0dbd6617cb Status: R X-Status: N On Sat, Nov 25, 2000 at 01:35:12AM -0600, Jonathan Vaughn wrote:
> OK, I'm sure Intel has approximately 10 million patents on QDR, but how hard
> would it be to make a QDR speed bus? maybe have a pair of DDR clocks, that
> are 1/4th of the clock rate off..
> (DDR) = DDR derived (i.e., PLL'd or such to be 1/2 of input cycle later)
>
>           0   1   2   3   4   5
> Clock #0  ____----____----____----
>  (DDR)    --____----____----____--
> Clock #1  -____----____----____---
>  (DDR)    ---____----____----____-

The trick is to send data on both edges of the clock(s):
                 _______         _______
Clock #0  ______/       \_______/       \____
          __         _______         _______
Clock #1    \_______/       \_______/       \_
           ___ ___ ___ ___ ___ ___ ___ ___ ___
Data      <___X___X___X___X___X___X___X___X___>

That's already the whole magic.  I really don't know why people think
that QDR is a kind of holy grail...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From graham@belegost.mit.edu Sat Nov 25 23:29:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01107 for ; Mon, 27 Nov 2000 01:22:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:41 +0100 (MET) Received: (qmail 1804 invoked by uid 0); 25 Nov 2000 22:29:40 -0000 Received: from mu.egroups.com (208.50.99.218) by mx0.gmx.net (mx08) with SMTP; 25 Nov 2000 22:29:40 -0000 X-eGroups-Return: sentto-1101623-1618-975191367-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 25 Nov 2000 22:29:35 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 22:29:27 -0000 Received: (qmail 86035 invoked from network); 25 Nov 2000 22:29:26 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 25 Nov 2000 22:29:26 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta1 with SMTP; 25 Nov 2000 22:29:26 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA25601 for f-cpu@egroups.com; Sat, 25 Nov 2000 17:29:25 -0500 Message-Id: <200011252229.RAA25601@belegost.mit.edu> To: f-cpu@egroups.com In-Reply-To: <3A2032F8.2E08A0C0@f-cpu.org> from "Yann Guidon" at Nov 25, 2000 10:45:28 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 17:29:24 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU guidelines Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b59b6a2cc1ecec13daf0b4cc7e88822 Status: R X-Status: N >
> PS : I think that Graham Seaman can update his site with this mail
> and the enclosed text.
>
Done. It's at:

http://www.opencollector.org/hardlicense/charter.html

linked to from:
http://www.opencollector.org/hardlicense/fcpu.html

Let me know if anything needs to be changed.

Graham
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 20 00:36:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01110 for ; Mon, 27 Nov 2000 01:22:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:42 +0100 (MET) Received: (qmail 29875 invoked by uid 0); 25 Nov 2000 22:37:01 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx24) with SMTP; 25 Nov 2000 22:37:01 -0000 X-eGroups-Return: sentto-1101623-1619-975191783-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 25 Nov 2000 22:36:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 22:36:22 -0000 Received: (qmail 8149 invoked from network); 25 Nov 2000 22:36:21 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 25 Nov 2000 22:36:21 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 25 Nov 2000 22:36:20 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA22069; Sat, 25 Nov 2000 15:26:52 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A1863E8.ADE2E2F9@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com Cc: hardlicense-discuss@seul.org References: <3A2032F8.2E08A0C0@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 19 Nov 2000 23:36:08 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU guidelines Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7e5c507f9aa07a21da03fb0bf4c607ff Status: R X-Status: N Yann Guidon wrote:
>
> As i'm trying to make a new vhdl bundle,
> the old problem of the distribution licence
> has resurfaced.
>
> It is finally very heavy and not very useful
> to rewrite something similar to the GPL so i have
> found a way to bypass this : all the files are under
> GPL or GFDL, the f-cpu part is moved to a charter
> or convention, whatever you name it. It defines the
> rules of the development teams and leaves a certain
> degree of freedom for the people that want "only" to
> comply with the GPL. Those who will want to make
> a "real" F-CPU have to follow the guidelines : they are
> not very restrictive in fact for those who are already
> here, but this may be the conflict point for the eventual
> distributors or funders who will "claim" to work with
> the team. If they want the F-CPU logo on their chips,
> they will have to obey some simple rules. This way, this
> will discriminate the people who don't respect the F-CPU
> philosophy, at least in the facts.

This regulation might be useful with Vender ID and or Hardware Configuration
in a special Register. A Toaster with a F-CPU and Borg Main frame with
a LOT of F-CPU's (Ok a bit extreme) would have very different characteristics
and a standard configuration table for the models of F-Cpu's would be
useful.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Michael Riepe Sun Nov 26 00:05:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01113 for ; Mon, 27 Nov 2000 01:22:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:43 +0100 (MET) Received: (qmail 18002 invoked by uid 0); 25 Nov 2000 23:11:13 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx23) with SMTP; 25 Nov 2000 23:11:13 -0000 X-eGroups-Return: sentto-1101623-1620-975193864-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fj.egroups.com with NNFMP; 25 Nov 2000 23:11:11 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 23:11:03 -0000 Received: (qmail 94301 invoked from network); 25 Nov 2000 23:11:03 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 25 Nov 2000 23:11:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta3 with SMTP; 26 Nov 2000 00:10:35 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00614; Sun, 26 Nov 2000 00:05:44 +0100 Message-ID: <20001126000544.65316@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> <00112415233405.01164@tiglath.pileser.sumeria> <20001124183029.41472@thrai.stud.uni-hannover.de> <00112515545307.01164@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00112515545307.01164@tiglath.pileser.sumeria>; from Jeff Davies on Sat, Nov 25, 2000 at 03:46:38PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 00:05:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 725d1e49eb37d3e27652c77ecf781e97 Status: R X-Status: N On Sat, Nov 25, 2000 at 03:46:38PM +0000, Jeff Davies wrote:
[...]
> > gcc *is* crap.  But IMHO it's still the best crap out of the set of free
> > craps, and I know pretty well how to deal with its crappiness (sp?).
>
> You seem to imply the commercial stuff is better. I can;t say I've noticed a
> huge difference, in fact, I have come across compile errors (and lack of
> safety in places) with VC but not with gcc.

No, not at all.  There's free crap and there's commercial crap, and I
like free crap better.  There are some non-free C compilers that are
usable (Compaq's compiler for Linux/Alpha, for example, or the Unixware
C Compiler which generates much better code than gcc on Intel boxen),
but I prefer gcc anyway.

> Borland seems to be insane about it's semicolons, but otherwise no better.
> So, come on, what is crap about gcc? Is the structure wrong, does it not allow
> sufficient optimisation ,.. or what?
> I think it's pretty weak to complain about something without saying what it is
> you don;t like about it.

- code quality (of the generated machine code)
- execution speed / memory usage (of the compiler itself)
- massive source bloat

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Jeff Davies Sun Nov 26 00:45:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01128 for ; Mon, 27 Nov 2000 01:22:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:48 +0100 (MET) Received: (qmail 25844 invoked by uid 0); 25 Nov 2000 23:52:00 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx23) with SMTP; 25 Nov 2000 23:52:00 -0000 X-eGroups-Return: sentto-1101623-1621-975196316-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 25 Nov 2000 23:51:58 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 25 Nov 2000 23:51:55 -0000 Received: (qmail 75178 invoked from network); 25 Nov 2000 23:51:55 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 25 Nov 2000 23:51:55 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta3 with SMTP; 26 Nov 2000 00:53:00 -0000 Received: from modem-66.indiana.dialup.pol.co.uk ([62.137.65.66] helo=tiglath.pileser.sumeria) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13zp6l-0002Ox-00 for f-cpu@egroups.com; Sat, 25 Nov 2000 23:51:52 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A1DDE35.755DED1C@lvdi.net> <00112515545307.01164@tiglath.pileser.sumeria> <20001126000544.65316@thrai.stud.uni-hannover.de> In-Reply-To: <20001126000544.65316@thrai.stud.uni-hannover.de> Message-Id: <00112523545109.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 23:45:43 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6391d01ab538f18e49d4e9dbe666bd78 Status: R X-Status: N > > safety in places) with VC but not with gcc.
>
> No, not at all.  There's free crap and there's commercial crap, and I
> like free crap better.  There are some non-free C compilers that are
> usable (Compaq's compiler for Linux/Alpha, for example, or the Unixware
> C Compiler which generates much better code than gcc on Intel boxen),
> but I prefer gcc anyway.

Sorry, looking back my post was a bit ranty. Everything can be improved.
The one thing about GCC is that it has ported across to more CPUs than just
about any other compiler.

> > I think it's pretty weak to complain about something without saying what it is
> > you don;t like about it.
>
> - code quality (of the generated machine code)
> - execution speed / memory usage (of the compiler itself)
> - massive source bloat

Anyone know of funcspec for gcc, perhaps we can look at how it works, and
suggest ways to improve code quality etc etc.
(does code quality mean speed? - this is probably the down side of portability).

Source bloat??
With M4 macro preprocessor, you shouldn't have source bloat?
I think gcc handles all those things like     i= (thing? a:b );
Which long hand is

if (thing) {
i=a
} else {
i=b
}

Yes this is the way I like my brackets [to all those heathens who like this
form - go back to ada or pascal or something <just joking>]

if (thing)
{
  i=a
}
else
{
etc....


ps. I am looking at smalltalk at the moment re multicpu systems, since
functions calls is implemented apparently by message passing......
'everything is an object'    <everything is a thing>

Jeff Davies

>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>

eGroups Sponsor
click here
From Jeff Davies Sun Nov 26 00:55:10 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01134 for ; Mon, 27 Nov 2000 01:22:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:49 +0100 (MET) Received: (qmail 3675 invoked by uid 0); 25 Nov 2000 23:58:01 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx22) with SMTP; 25 Nov 2000 23:58:01 -0000 X-eGroups-Return: sentto-1101623-1622-975196674-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 25 Nov 2000 23:57:59 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_3_1_2); 25 Nov 2000 23:57:54 -0000 Received: (qmail 75093 invoked from network); 25 Nov 2000 23:57:54 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 25 Nov 2000 23:57:54 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta2 with SMTP; 25 Nov 2000 23:57:53 -0000 Received: from modem-66.indiana.dialup.pol.co.uk ([62.137.65.66] helo=tiglath.pileser.sumeria) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 13zpCZ-0003Gn-00 for f-cpu@egroups.org; Sat, 25 Nov 2000 23:57:52 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] Message-Id: <0011260000500A.01164@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 23:55:10 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] CPU power usage Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0961f2dd337056424290f5e70391c34a Status: R X-Status: N A bizzare idea occured to me earlier....
Is there any way the heat burnt by a CPU in a laptop can be converted to light.
(eg low temperature phosphorescent substances of some kind). In this way power
consumption in laptops could be reduced. You can imagine a fibre carrying light
>from the CPU's outer case which is coated with a phosphorescent substance to
be the LCD backlight.

Also, to reduce consumption when in a brightly lit environment, could the case
of the laptop be translucent, and a half silvered mirror or some device work as
a light rectifier to perform backlight type function??

I suppose even if the cpu wasn't in a laptop, you could have a transparent case,
and watch as it kicks into life, shining as you get into deep crap in unreal
tournament.

Jeff Davies
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 20 02:12:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01143 for ; Mon, 27 Nov 2000 01:22:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:52 +0100 (MET) Received: (qmail 12711 invoked by uid 0); 26 Nov 2000 00:12:35 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx05) with SMTP; 26 Nov 2000 00:12:35 -0000 X-eGroups-Return: sentto-1101623-1623-975197550-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hp.egroups.com with NNFMP; 26 Nov 2000 00:12:34 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 00:12:28 -0000 Received: (qmail 6808 invoked from network); 26 Nov 2000 00:12:28 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 26 Nov 2000 00:12:28 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 26 Nov 2000 00:12:28 -0000 Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA26709 for ; Sat, 25 Nov 2000 17:03:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A187A82.B699FC07@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <0011260000500A.01164@tiglath.pileser.sumeria> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 01:12:34 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] CPU power usage Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2c6e1725ce2fc7a3ab2ef10c0d1f3b7d Status: R X-Status: N Jeff Davies wrote:
>
> A bizzare idea occured to me earlier....
> Is there any way the heat burnt by a CPU in a laptop can be converted to light.
> (eg low temperature phosphorescent substances of some kind). In this way power
> consumption in laptops could be reduced. You can imagine a fibre carrying light
> from the CPU's outer case which is coated with a phosphorescent substance to
> be the LCD backlight.

As far as I know heat can't be turned into light with out melting the cpu.
Also I don't think you can get a phosphor to absorb low energy photons
and reemit them as higher energy ones.

> Also, to reduce consumption when in a brightly lit environment, could the case
> of the laptop be translucent, and a half silvered mirror or some device work as
> a light rectifier to perform backlight type function??

That is a good idea, light pipe with flip prism?

> I suppose even if the cpu wasn't in a laptop, you could have a transparent case,
> and watch as it kicks into life, shining as you get into deep crap in unreal
> tournament.

But alas light can mess-up transistor characteristics.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Michael Riepe Sun Nov 26 01:16:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01146 for ; Mon, 27 Nov 2000 01:22:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:53 +0100 (MET) Received: (qmail 20977 invoked by uid 0); 26 Nov 2000 00:21:17 -0000 Received: from ml.egroups.com (208.50.144.77) by mx06.rz2.gmx.net (mx06) with SMTP; 26 Nov 2000 00:21:17 -0000 X-eGroups-Return: sentto-1101623-1624-975198066-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 26 Nov 2000 00:21:14 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 00:21:05 -0000 Received: (qmail 45757 invoked from network); 26 Nov 2000 00:21:05 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 26 Nov 2000 00:21:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta2 with SMTP; 26 Nov 2000 00:20:28 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00881; Sun, 26 Nov 2000 01:16:44 +0100 Message-ID: <20001126011644.45332@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> <00112515545307.01164@tiglath.pileser.sumeria> <20001126000544.65316@thrai.stud.uni-hannover.de> <00112523545109.01164@tiglath.pileser.sumeria> X-Mailer: Mutt 0.84e In-Reply-To: <00112523545109.01164@tiglath.pileser.sumeria>; from Jeff Davies on Sat, Nov 25, 2000 at 11:45:43PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 01:16:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1e3236d897e9cc02e5891b7b5483bd6c Status: R X-Status: N On Sat, Nov 25, 2000 at 11:45:43PM +0000, Jeff Davies wrote:
[...]
> > - code quality (of the generated machine code)
> > - execution speed / memory usage (of the compiler itself)
> > - massive source bloat
>
> Anyone know of funcspec for gcc, perhaps we can look at how it works, and
> suggest ways to improve code quality etc etc.
> (does code quality mean speed? - this is probably the down side of portability).

Yes, it means speed.  Or size.  Depends on what you need ;)

> Source bloat??
> With M4 macro preprocessor, you shouldn't have source bloat?

I was talking about the source code for gcc.
*My* C code isn't bloated.  Never :)

[...]
> Yes this is the way I like my brackets [to all those heathens who like this
> form - go back to ada or pascal or something <just joking>]

Let's not discuss the One True Brace Style here, ok? ;)
Coding style is simply a matter of taste, nothing else.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Jonathan Vaughn Sun Nov 26 01:37:29 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01149 for ; Mon, 27 Nov 2000 01:22:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:53 +0100 (MET) Received: (qmail 3823 invoked by uid 0); 26 Nov 2000 00:37:42 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx23) with SMTP; 26 Nov 2000 00:37:42 -0000 X-eGroups-Return: sentto-1101623-1625-975199054-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 26 Nov 2000 00:37:40 -0000 X-Sender: biosehn@airmail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 00:37:34 -0000 Received: (qmail 71244 invoked from network); 26 Nov 2000 00:37:33 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 26 Nov 2000 00:37:33 -0000 Received: from unknown (HELO smtp.airmail.net) (209.196.123.2) by mta3 with SMTP; 26 Nov 2000 01:38:39 -0000 Received: from sehnsucht from [64.217.234.46] by smtp.airmail.net (/\##/\ Smail3.1.30.16 #30.12) with smtp for sender: id ; Sat, 25 Nov 2000 18:37:57 -0600 (CST) Message-Id: <3.0.6.32.20001125183729.008fee90@mail.airmail.net> X-Sender: biosehn@mail.airmail.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: <20001125144525.25816@thrai.stud.uni-hannover.de> References: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125013512.008fd180@mail.airmail.net> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 18:37:29 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e4b02ff4ce1c208a98faa0bf39d77558 Status: R X-Status: N Well, QDR would double the data rate without having to double the pin count.
Getting a fast enough bus for the inter-chip stuff, is a big thing. Current
CPUs are starving for bandwidth and they already have a pretty significant
amount.

Hrm. just take the two clocks, feed into a pair of edge (either) triggered
gizmos (not exactly a latch themselves really) (they pulse when they sense
an edge) and then OR the output of those and then send that to the bus
latches...

But how do you construct an edge sensitive triggering gizmo anyways?

-JV

At 02:45 PM 11/25/00 +0100, Michael Riepe wrote:
>On Sat, Nov 25, 2000 at 01:35:12AM -0600, Jonathan Vaughn wrote:
>> OK, I'm sure Intel has approximately 10 million patents on QDR, but how
hard
>> would it be to make a QDR speed bus? maybe have a pair of DDR clocks, that
>> are 1/4th of the clock rate off..
>> (DDR) = DDR derived (i.e., PLL'd or such to be 1/2 of input cycle later)
>>
>>           0   1   2   3   4   5
>> Clock #0  ____----____----____----
>>  (DDR)    --____----____----____--
>> Clock #1  -____----____----____---
>>  (DDR)    ---____----____----____-
>
>The trick is to send data on both edges of the clock(s):
>                 _______         _______
>Clock #0  ______/       \_______/       \____
>          __         _______         _______
>Clock #1    \_______/       \_______/       \_
>           ___ ___ ___ ___ ___ ___ ___ ___ ___
>Data      <___X___X___X___X___X___X___X___X___>
>
>That's already the whole magic.  I really don't know why people think
>that QDR is a kind of holy grail...
>
>--
> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> "All I wanna do is have a little fun before I die"

-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 20 02:46:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01158 for ; Mon, 27 Nov 2000 01:22:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:58 +0100 (MET) Received: (qmail 6074 invoked by uid 0); 26 Nov 2000 00:46:32 -0000 Received: from mw.egroups.com (208.50.144.94) by mx06.rz2.gmx.net (mx06) with SMTP; 26 Nov 2000 00:46:32 -0000 X-eGroups-Return: sentto-1101623-1626-975199589-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mw.egroups.com with NNFMP; 26 Nov 2000 00:46:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 00:46:28 -0000 Received: (qmail 90427 invoked from network); 26 Nov 2000 00:46:28 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 26 Nov 2000 00:46:28 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 26 Nov 2000 01:47:33 -0000 Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA28193 for ; Sat, 25 Nov 2000 17:37:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A18827A.D581778C@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1DDE35.755DED1C@lvdi.net> <00112515545307.01164@tiglath.pileser.sumeria> <20001126000544.65316@thrai.stud.uni-hannover.de> <00112523545109.01164@tiglath.pileser.sumeria> <20001126011644.45332@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 01:46:34 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f3791fa1949db37780424e881dd027da Status: R X-Status: N Michael Riepe wrote:
>
> On Sat, Nov 25, 2000 at 11:45:43PM +0000, Jeff Davies wrote:
> [...]
> > > - code quality (of the generated machine code)
> > > - execution speed / memory usage (of the compiler itself)
> > > - massive source bloat
> >
> > Anyone know of funcspec for gcc, perhaps we can look at how it works, and
> > suggest ways to improve code quality etc etc.
> > (does code quality mean speed? - this is probably the down side of portability).

The real question is still Bootstapable? Linux is becoming over burdened
with stuff that needed because portions are no longer use just the C libraries.
Is that the same now with GCC?

> Yes, it means speed.  Or size.  Depends on what you need ;)
>
> > Source bloat??
> > With M4 macro preprocessor, you shouldn't have source bloat?

Bloat is because local references are not used to any great extent.
Constructs like "int fee,fie[64K],foo,fum;" require long addressing all
variables
as you no longer have local variables.


> I was talking about the source code for gcc.
> *My* C code isn't bloated.  Never :)
>
> [...]
> > Yes this is the way I like my brackets [to all those heathens who like this
> > form - go back to ada or pascal or something <just joking>]

I like () better as you can have :) and :(.

> Let's not discuss the One True Brace Style here, ok? ;)
> Coding style is simply a matter of taste, nothing else.

  Start ... stop    is better. (grin).
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 20 02:58:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01161 for ; Mon, 27 Nov 2000 01:22:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:59 +0100 (MET) Received: (qmail 22156 invoked by uid 0); 26 Nov 2000 00:58:22 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx13) with SMTP; 26 Nov 2000 00:58:22 -0000 X-eGroups-Return: sentto-1101623-1627-975200290-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 26 Nov 2000 00:58:20 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 00:58:09 -0000 Received: (qmail 19507 invoked from network); 26 Nov 2000 00:58:09 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 26 Nov 2000 00:58:09 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 26 Nov 2000 00:58:08 -0000 Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA28732 for ; Sat, 25 Nov 2000 17:48:56 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A188536.C3FD6D4A@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125183729.008fee90@mail.airmail.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 01:58:14 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6fdf477dbe9e42666b72604985cd4944 Status: R X-Status: N Jonathan Vaughn wrote:
>
> Well, QDR would double the data rate without having to double the pin count.
> Getting a fast enough bus for the inter-chip stuff, is a big thing. Current
> CPUs are starving for bandwidth and they already have a pretty significant
> amount.

Nope they are starving for Random access of memory.
Most of the tricks to speed up memory assume that the next memory
access is the next address in memory. This was fine for some
problems like weather prediction or graphics crunching but most
problems now days are too random in both control and data to benifit
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 02:34:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01164 for ; Mon, 27 Nov 2000 01:22:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:22:59 +0100 (MET) Received: (qmail 20000 invoked by uid 0); 26 Nov 2000 01:31:09 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx02) with SMTP; 26 Nov 2000 01:31:09 -0000 X-eGroups-Return: sentto-1101623-1628-975202191-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 26 Nov 2000 01:31:08 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 01:29:50 -0000 Received: (qmail 93987 invoked from network); 26 Nov 2000 01:29:48 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 26 Nov 2000 01:29:48 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 26 Nov 2000 02:30:54 -0000 Received: from f-cpu.org (nas1-223.aub.club-internet.fr [195.36.150.223]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA04916 for ; Sun, 26 Nov 2000 02:29:45 +0100 (MET) Message-ID: <3A2068B4.76CC7FBF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A1D0406.F6FDC4BD@lvdi.net> <3A1DAC31.63BEB4D4@f-cpu.org> <000d01c05668$512d3a80$29e65982@student.utwente.nl> <3A1EF411.B4E6C592@f-cpu.org> <3A17D165.E59FC090@jetnet.ab.ca> <3A1FB274.BA6BA4BD@ifrance.com> <3A1FDE9A.F6C6DA5A@f-cpu.org> <002901c05729$a95eeca0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 02:34:44 +0100 Reply-To: f-cpu@egroups.com Subject: (x) Re: [f-cpu] The F-CPU-over-GCC 'Why did I even bother?' Release Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d3dc5b8fffc8b5441b7d331171e3cc30 Status: R X-Status: N hello again,

while i answer emails, i don't code, but i prefer to dissipate any doubt
about the architecture...

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > "split branch" is another technique to branch "quickly" without
> > suffering from the latency of the memory. Other well known
> > ways are delayed branches and speculative execution.
> Personally I see it rather as a way to avoid the problem that you have to know
> wether an instruction is a branch and what its target is before its even fully
> decoded (if you dont want to create a bubble or necessitate a flush).
that's also a good point of view.

> > "Speculative execution" : we chose a direction and we execute
> > speculatively, hoping that the direction is the good one.
> > if the condition appears to be false (when the real condition
> > becomes available to the decoder), we decide if we unwind
> > the execution or not. It's used a lot in the Intel CPUs,
> > the PowerPC, and a lot of others.
> If the conditional isnt available in time (not unlikely with short sequences and
> wide superscalar processors) you might want it regardless. Elbrus for instance
> still uses speculative execution, SH5 also speculatively fills the pipeline with
> instructions according to how it thinks the branch will be taken.
This is in fact a complementary feature.
split branch helps, just like speculative execution helps too.
The case of the FC0 though is not adapted to speculatively
execute anything : its architecture is explicitely designed to work with
one thread at a time, after the decoding stage. There is no way to
rewind execution, there is no renamed register. it keeps the architecture
simple and fast.

The next fcpus will be necessarily multithreaded and work with several
branches at a time : it will be easier to speculatively execute branches
under certain conditions. But not with the FC0...

> > Second act :
> > In the instruction flow, the decoder sees a jump instruction.
> > the unit looks up in the precedent table : if the indicated physical
> > register numbe is not present, it "re-calls" the prefetch (with all
> > the penalties it means). If it is present, it takes almost no time
> > to retrieve the instructions pointed to by the table.
> Almost no time?
yup :-)

striking, huh ?

> What of conditional branches? Between it being fetched and before the
> conditional can be checked theres quite a few clock ticks arent there? What is
> the IF (and subsequent pipeline stages) doing in the meantime?

in fact there are several scenarii. I will therefore only describe the
physical implementation of the jump instruction.

The decoding stage performs several operations, speculatively and in parallel.
The result is selected only at the end, when the exact condition is known.

The jump operation accepts 3 register operands and some parameters.
The first part is the condition : there is one register number and a 2-bit selector.
The indicated register is tested against the requested condition and the resulting bit
is reversed according to a third parameter bit.

The 3 possible conditions are : nullity (register is = 0), LSB and MSB.
LSB and MSB are easy to do : it is a 2*64-bit mux, that selects the bit #0 or #63
of one of the 64 registers (incl. reg. 0 which is hardwired). The inversion is
a simple XOR. The first condition (nullity) is a bit more complex (there are 8 partial
8-bit ORs with latches so we can keep it synchronised with the actual register contents).
Anyway, all these conditions are valid only if the register is ready, that means that
the value must be available in the register (we might use a bypass from the Xbar).

So, if you indicate a condition that is not yet available, the decoder will stall,
it will wait for the completion of the operation that will write to the register indicated
as condition in the jump instruction. There is no way to speculatively execute the
following instructions because there is no mean to rewind them. Worse : if a trap occurs,
the variable-length pipeline gives no chance to know what result belongs to what.
So, a simple stall requires no added HW (and avoids the use of additional pipe stages
for renaming etc...).


There is another interesting part, though it is not critical : the "result" field
of the opcode contains the number of the physical register that will be written with
PC+4. If it is unused, it is simply 0. Otherwise, it is used for saving the return
address, upon calling a function. One should care not to deadlock the CPU by indicating
the same result and condition register...


The last and most interesting part is the "pointer" field : the value is constantly
used as input of a 16-entry lookup table of 6 bits per entry.
This table constantly (speculatively) compares the "pointer" field against the 16
least most recently issued prefetch orders (the 6-bit key representing one
of the 63 usable registers). One half is dedicated to the instruction fetcher,
the other 8 entries are dedicated to the Load/Store Unit.
It works like a very high-speed, fully asssociative tiny cache : it "associates"
a register number with a fetcher or LSU line. It can be seen as 2 columns (LSU/fetcher)
of 8 6-bit key comparators. When a "match" is detected, the instruction decoder
is warned that it's ok, and the line corresponding to where the key was found is selected.

This explains why jumping is so quick, when all the conditions are met :
the critical datapath is kept very short, there is no redundant or inefficient
operation, no address computation or TLB lookup, no trap...
The register field is used for two purposes : remember the address in the case
of a context switch (the lookup table is then flushed), or if the lookup table
overflows, and it serves as a handle, or ID, for a valid jump. The machinery is
more complex than that, because we have to handle the special or faulty conditions,
but the "ideal case" can be executed very, very quickly.

I hope that this textual explanation helps.
The decoder is more complex than that because it has to allocate the Xbar's "time slots"
with a stack and a big lookup table that evaluates the latency of the instruction,
but i think that it can be the subject of a later mail...


> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 03:14:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01167 for ; Mon, 27 Nov 2000 01:23:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:01 +0100 (MET) Received: (qmail 14875 invoked by uid 0); 26 Nov 2000 02:09:23 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx09) with SMTP; 26 Nov 2000 02:09:23 -0000 X-eGroups-Return: sentto-1101623-1630-975204560-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 26 Nov 2000 02:09:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 02:09:20 -0000 Received: (qmail 68752 invoked from network); 26 Nov 2000 02:09:19 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 26 Nov 2000 02:09:19 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 26 Nov 2000 02:09:19 -0000 Received: from f-cpu.org (nas1-227.aub.club-internet.fr [195.36.150.227]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA16279 for ; Sun, 26 Nov 2000 03:09:16 +0100 (MET) Message-ID: <3A2071F4.C29402CB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 03:14:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F-CPU guidelines Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8068777225bd09d83f63dee9cca79563 Status: R X-Status: N hello,

Ben Franchuk wrote:
> > If they want the F-CPU logo on their chips,
> > they will have to obey some simple rules. This way, this
> > will discriminate the people who don't respect the F-CPU
> > philosophy, at least in the facts.
> This regulation might be useful with Vender ID and or Hardware Configuration
> in a special Register.
Well, the special registers are partly designed for that (same as the MSR of
the P5+ CPUs : they contain configuration info, signatures, IDs, BIST taps...).

The goal of the F-CPU team is not to allocate a vendor ID (There is enough
room in the SRs to store a whole ASCII string) but make them collaborate in
peace and benefit the end user.

Since we own the F-CPU trademark (at least in France), we can decide to only accept
the endorsement IF the vendor shows a nice behaviour. this is independent from the
royalties issue of course ;-)

> A Toaster with a F-CPU and Borg Main frame with
> a LOT of F-CPU's (Ok a bit extreme) would have very different characteristics
> and a standard configuration table for the models of F-Cpu's would be
> useful.

The best way is to not use tables, but direct encodings in the SRs.
The SR map is under constant rework. I guess that the end of its rework
will mean the end of the architecture. However, we will certainly define different
SR maps and formats so we can store more useful informations with the time.




graham@belegost.mit.edu wrote:
> > PS : I think that Graham Seaman can update his site with this mail
> > and the enclosed text.
> Done. It's at:
> http://www.opencollector.org/hardlicense/charter.html
> linked to from:
> http://www.opencollector.org/hardlicense/fcpu.html
> Let me know if anything needs to be changed.
> Graham

thank you very much :-)
i hope that we will find a good agreement on this matter,
so we can release "clean" bundles, from the technical and legal
points of view.

g'night,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 03:14:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01170 for ; Mon, 27 Nov 2000 01:23:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:02 +0100 (MET) Received: (qmail 3673 invoked by uid 0); 26 Nov 2000 02:09:33 -0000 Received: from hp.egroups.com (208.50.99.201) by mx19.rz2.gmx.net (mx19) with SMTP; 26 Nov 2000 02:09:33 -0000 X-eGroups-Return: sentto-1101623-1629-975204560-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 26 Nov 2000 02:09:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 02:09:20 -0000 Received: (qmail 74221 invoked from network); 26 Nov 2000 02:09:20 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 26 Nov 2000 02:09:20 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 26 Nov 2000 02:09:19 -0000 Received: from f-cpu.org (nas1-227.aub.club-internet.fr [195.36.150.227]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA28714 for ; Sun, 26 Nov 2000 03:09:16 +0100 (MET) Message-ID: <3A2071F3.859F5E26@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <0011260000500A.01164@tiglath.pileser.sumeria> <3A187A82.B699FC07@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 03:14:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] CPU power usage Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3829794052db9cf97366af0da468ba7d Status: R X-Status: N hi !

Ben Franchuk wrote:
> Jeff Davies wrote:
> > A bizzare idea occured to me earlier....
look at an old (1y ?) comp.arch thread.
ask the people there, they might remember the outcome...

> > Is there any way the heat burnt by a CPU in a laptop can be converted to light.
> > (eg low temperature phosphorescent substances of some kind). In this way power
> > consumption in laptops could be reduced. You can imagine a fibre carrying light
> > from the CPU's outer case which is coated with a phosphorescent substance to
> > be the LCD backlight.
> As far as I know heat can't be turned into light with out melting the cpu.
> Also I don't think you can get a phosphor to absorb low energy photons
> and reemit them as higher energy ones.
Jeff's idea is really wicked, but would be too funny if possible.
Anyway, if it ever was possible, it would be already implemented AFAIK.

if you get photons, it's ok : it is possible to convert 1 IR photon into
2 UV photons. The problem is to get the photons from the heat.
It is possible to get a photon from electricity (with laser or LED)
but not from small heat. A Peltier/Cambion device requires a good
temperature difference to work (and genererate electricity).

> > Also, to reduce consumption when in a brightly lit environment, could the case
> > of the laptop be translucent, and a half silvered mirror or some device work as
> > a light rectifier to perform backlight type function??
> That is a good idea, light pipe with flip prism?
patent, patent ! ;-)

> > I suppose even if the cpu wasn't in a laptop, you could have a transparent case,
> > and watch as it kicks into life, shining as you get into deep crap in unreal
> > tournament.
> But alas light can mess-up transistor characteristics.
true !

This remembers me of a story : a "robot" in a university with its EPROMs
not protected from the light. A journalist comes and takes a picture of
it, the flash lights and the robot hits a wall. In fact, the high intensity
of the flashing light has temporarily altered the data in the EPROM (but not
erased), so the control SW has crashed.
Remember that now, the width of the wires in a IC corresponds to visible or
UV wavelengths.


> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Keyshaun Sun Nov 26 03:35:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01176 for ; Mon, 27 Nov 2000 01:23:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:04 +0100 (MET) Received: (qmail 11579 invoked by uid 0); 26 Nov 2000 02:35:39 -0000 Received: from hn.egroups.com (208.50.99.199) by mx19.rz2.gmx.net (mx19) with SMTP; 26 Nov 2000 02:35:39 -0000 X-eGroups-Return: sentto-1101623-1631-975206136-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 26 Nov 2000 02:35:38 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 02:35:35 -0000 Received: (qmail 33682 invoked from network); 26 Nov 2000 02:35:35 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 26 Nov 2000 02:35:35 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 26 Nov 2000 03:36:40 -0000 Received: (qmail 3748 invoked from network); 26 Nov 2000 02:35:27 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 26 Nov 2000 02:35:27 -0000 X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 25 Nov 2000 19:35:34 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 143b63bacc1b7eedc57a459a2789db1d Status: R X-Status: N Until gEDA is ready will any *cringe* non-free EDA tool be good for
furthuring the F-CPU design?  So long as it doesn't force you to keep your
info in proprietary formats of course.  The best question perhaps is what
is the next step in the design going to be that can't be done with free
tools?

Shaun Kruger
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 20 04:06:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01185 for ; Mon, 27 Nov 2000 01:23:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:06 +0100 (MET) Received: (qmail 3021 invoked by uid 0); 26 Nov 2000 05:10:54 -0000 Received: from fg.egroups.com (208.50.144.70) by mx11.rz2.gmx.net (mx11) with SMTP; 26 Nov 2000 05:10:54 -0000 X-eGroups-Return: sentto-1101623-1632-975215433-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 26 Nov 2000 05:10:49 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 05:10:32 -0000 Received: (qmail 44302 invoked from network); 26 Nov 2000 05:10:31 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 26 Nov 2000 05:10:31 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 26 Nov 2000 05:10:31 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA10252 for ; Sat, 25 Nov 2000 22:01:18 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A18953C.64F8667C@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <0011260000500A.01164@tiglath.pileser.sumeria> <3A187A82.B699FC07@jetnet.ab.ca> <3A2071F3.859F5E26@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 20 Nov 2000 03:06:36 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] CPU power usage Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4e1c5c68e2aa8433b8e529c2fb1a3586 Status: R X-Status: N Yann Guidon wrote:

> if you get photons, it's ok : it is possible to convert 1 IR photon into
> 2 UV photons. The problem is to get the photons from the heat.
> It is possible to get a photon from electricity (with laser or LED)
> but not from small heat.

Is it not the other way around 2 IR for 1 UV as the IR has less energy.
Heat does generate photons but it is weak at room temperatures.
I did not think you could get something to stay in a higher energy state
to absorb a second IR photon. Got anything that converts UV to gamma rays.
I am looking for a low cost way to generate antimatter.:)


> This remembers me of a story : a "robot" in a university with its EPROMs
> not protected from the light. A journalist comes and takes a picture of
> it, the flash lights and the robot hits a wall. In fact, the high intensity
> of the flashing light has temporarily altered the data in the EPROM (but not
> erased), so the control SW has crashed.

I was thinking of one of the Muliti-million dollar computers of the late 50's
,early 60's that had nice smoked glass doors over the electronics. Lots of
diode logic with the glass cased diodes. Must have been the same  journalist
as the computer was scrambled after the flash. Also I remember reading a story
about a high speed computer that used glass switching diodes.The computer's
design
neglected the fact that the diodes switching curves where made in room light
and design around those numbers and thus would not work in the dark cabinet.They
ended up installing lights
in the computer,so the computer would work.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Michael Riepe Sun Nov 26 06:31:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01242 for ; Mon, 27 Nov 2000 01:23:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:20 +0100 (MET) Received: (qmail 10025 invoked by uid 0); 26 Nov 2000 12:46:56 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx16) with SMTP; 26 Nov 2000 12:46:56 -0000 X-eGroups-Return: sentto-1101623-1633-975242811-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 26 Nov 2000 12:46:55 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 12:46:49 -0000 Received: (qmail 43660 invoked from network); 26 Nov 2000 12:46:48 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 26 Nov 2000 12:46:48 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta1 with SMTP; 26 Nov 2000 12:46:43 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA01641; Sun, 26 Nov 2000 06:31:01 +0100 Message-ID: <20001126063101.53116@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A1FDE9B.FF38EE06@f-cpu.org>; from Yann Guidon on Sat, Nov 25, 2000 at 04:45:31PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 06:31:01 +0100 Reply-To: f-cpu@egroups.com Subject: Testability (was: Re: [f-cpu] size of F/G chips) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c779d32bbce7f8a9b3f1089dd0d8506a Status: R X-Status: N On Sat, Nov 25, 2000 at 04:45:31PM +0100, Yann Guidon wrote:
[...]
> I stress on a very important point : testability. If we produce such chips, we
> will have to proveide a (vector) testbench for the chips to the fundry
> as well as a physical testbench (go/no-go + diagnostics) to the PCB maker.
> Given the price of a single module and the relatively low price of our
> work horsepower, this is a crucial point for the overal yield of the project.
>
> </!!!!!!!!!!>
>
> still on the testability issue : we should write #now# the vectors that will be used
> to test the f-cpu chips in the fundry. We already have a testbench for most of
> the units, but they are "only" proofs of concept. Michael Riepe's testbenches
> can not be used in the fundry to test the chips, we need an exhaustive but much faster
> way to determine whether a unit is damaged. we should make a BIST, a kind of embedded
> checker that will verify the chip when it's still on the waffer...

I wrote my testbenches to check the design, not the hardware.

Some weeks ago when I was bored, I modified the testbench for the IAdd
unit and saved all vectors to a file.  It wasn't an exhaustive test,
but the output file became pretty big -- more than 64 MByte.  This is
of course far too much for a built-in self test.

Using an error model like stuck-at-0/stuck-at-1 will dramatically reduce
the number of vectors needed, but we will still need too many of them
to put them on the chip, and we can't generate them on-the-fly either.
On the other hand, they can (and should) be created automatically from the
(structural) VHDL sources and/or the resulting netlist (no need to write
anything!).  Of course this means that testing is a two-step process:
first, the sources must be proved to be correct (by simulating and/or
formally verifying them), and then the test vectors are used to verify
that the circuit matches its specifications (which have already been
verified).  This is the only way to keep the verification process short.

So far, this is only a static test (to identify damaged chips).  We will
also need a speed test to determine how fast the chip will run.  This is
a totally different animal -- it's usually not an exhaustive test, and
it will check only critical parts of the chip (so-called "speed paths").
I don't know (yet) how test vectors for this should look like, though.
Any experts out there?

A built-in self test certainly is an interesting option, and it may
be useful for the speed test, if there aren't too many test vectors.
But it's not a substitute for the static test.  One reason is that it
does not prove anything -- you can never know whether the rest of the
chip is OK because the BIST circuitry itself may be broken --, the
other reason is complexity.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Sun Nov 26 01:57:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01245 for ; Mon, 27 Nov 2000 01:23:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:22 +0100 (MET) Received: (qmail 17906 invoked by uid 0); 26 Nov 2000 12:47:06 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx22) with SMTP; 26 Nov 2000 12:47:06 -0000 X-eGroups-Return: sentto-1101623-1634-975242813-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jk.egroups.com with NNFMP; 26 Nov 2000 12:46:55 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 12:46:52 -0000 Received: (qmail 35348 invoked from network); 26 Nov 2000 12:46:52 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 26 Nov 2000 12:46:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.165) by mta1 with SMTP; 26 Nov 2000 12:46:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01046; Sun, 26 Nov 2000 01:57:43 +0100 Message-ID: <20001126015743.25551@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <20001125144525.25816@thrai.stud.uni-hannover.de> <3.0.6.32.20001125183729.008fee90@mail.airmail.net> X-Mailer: Mutt 0.84e In-Reply-To: <3.0.6.32.20001125183729.008fee90@mail.airmail.net>; from Jonathan Vaughn on Sat, Nov 25, 2000 at 06:37:29PM -0600 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 01:57:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d9369bf8bd1e05e7389bee5784320f00 Status: R X-Status: N On Sat, Nov 25, 2000 at 06:37:29PM -0600, Jonathan Vaughn wrote:
[...]
> Hrm. just take the two clocks, feed into a pair of edge (either) triggered
> gizmos (not exactly a latch themselves really) (they pulse when they sense
> an edge) and then OR the output of those and then send that to the bus
> latches...
>
> But how do you construct an edge sensitive triggering gizmo anyways?

You don't.  Use separate registers with positive and negative clock
inputs to de-multiplex bus data; then pass it along (at full width, or
using a higher, PLL/DLL-generated clock).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Jonathan Vaughn Sun Nov 26 16:31:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01284 for ; Mon, 27 Nov 2000 01:23:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:32 +0100 (MET) Received: (qmail 7603 invoked by uid 0); 26 Nov 2000 15:32:32 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx04) with SMTP; 26 Nov 2000 15:32:31 -0000 X-eGroups-Return: sentto-1101623-1635-975252719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 26 Nov 2000 15:32:08 -0000 X-Sender: biosehn@airmail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 15:31:58 -0000 Received: (qmail 62413 invoked from network); 26 Nov 2000 15:31:57 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 26 Nov 2000 15:31:57 -0000 Received: from unknown (HELO smtp.airmail.net) (209.196.123.2) by mta1 with SMTP; 26 Nov 2000 15:31:57 -0000 Received: from sehnsucht from [64.217.234.46] by smtp.airmail.net (/\##/\ Smail3.1.30.16 #30.12) with smtp for sender: id ; Sun, 26 Nov 2000 09:32:22 -0600 (CST) Message-Id: <3.0.6.32.20001126093154.008fcb50@mail.airmail.net> X-Sender: biosehn@mail.airmail.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: <3A188536.C3FD6D4A@jetnet.ab.ca> References: <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125013512.008fd180@mail.airmail.net> <3.0.6.32.20001125183729.008fee90@mail.airmail.net> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 09:31:54 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a968eef0b8db9b4e84d4abb56ac5681e Status: R X-Status: N Yes, the RAM is a bottleneck, but if we want to be accessing various SDRAM
banks across bus boundaries, then we need an extremely fast bus, unless you
want to max out at one memory transaction at a time (in the sense that they
can't be bursted and/or interleaved alternately, you'd have to wait for an
entire one to finish, OR, take a big performance hit, and do multiple ones
(burst and/or interleave) at the same time. The bus should handle enough
bandwidth for several cross-bus memory transactinos + IO at once, without
crawling.

-JV

At 01:58 AM 11/20/00 +0000, Ben Franchuk wrote:
>Jonathan Vaughn wrote:
>>
>> Well, QDR would double the data rate without having to double the pin
count.
>> Getting a fast enough bus for the inter-chip stuff, is a big thing. Current
>> CPUs are starving for bandwidth and they already have a pretty significant
>> amount.
>
>Nope they are starving for Random access of memory.
>Most of the tricks to speed up memory assume that the next memory
>access is the next address in memory. This was fine for some
>problems like weather prediction or graphics crunching but most
>problems now days are too random in both control and data to benifit
>--
>"We do not inherit our time on this planet from our parents...
> We borrow it from our children."
>"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
>
>
>
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 18:03:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01293 for ; Mon, 27 Nov 2000 01:23:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:34 +0100 (MET) Received: (qmail 20735 invoked by uid 0); 26 Nov 2000 16:58:50 -0000 Received: from jj.egroups.com (208.50.144.82) by mx12.rz2.gmx.net (mx12) with SMTP; 26 Nov 2000 16:58:50 -0000 X-eGroups-Return: sentto-1101623-1637-975257927-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 26 Nov 2000 16:58:50 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 16:58:47 -0000 Received: (qmail 62057 invoked from network); 26 Nov 2000 16:58:46 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 26 Nov 2000 16:58:46 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 26 Nov 2000 16:58:45 -0000 Received: from f-cpu.org (nas3-23.ras.club-internet.fr [195.36.203.23]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA21834 for ; Sun, 26 Nov 2000 17:58:42 +0100 (MET) Message-ID: <3A214277.68A3639F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 18:03:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 447814b090aad9fcb02db2bfa1963e00 Status: R X-Status: N hello,

Keyshaun wrote:
> Until gEDA is ready will any *cringe* non-free EDA tool be good for
> furthuring the F-CPU design?  So long as it doesn't force you to keep your
> info in proprietary formats of course.  The best question perhaps is what
> is the next step in the design going to be that can't be done with free
> tools?

i guess that today's situation is rather OK :
we have found some free (as "free as beer") SW that seem to
suit our requirements (ease of use, VHDL'93 and rather general)
that let people develop some parts "freely".
There is also the possibility to link the sources with
commercial SW through configuration files or scripts,
for example the recent bundle contained some scripts that
run a certain proprietary SW. As long as you don't modify the
VHDL source files to fit a "special" non-standard feature, it's ok.

I expect more or less that the next steps, if we speak about a
full-custom IC or ASIC, will look a bit like today : there is
a small set of "free" layout SW (i think about Alliance,
Electric Editor, and others i've forgotten).
There is also the possibility to use proprietary SW under
the same conditions as above. Unfortunately, there are not
many people skilled enough to manually layout an IC.
It is also much more implementation-dependent because it is
bound to the technology, budget and design goals.

In the end, i think that there is no problem if a proprietary
layout SW crunches our VHDL and generates a layout : a silicon
compiler is like another compiler and the final layout is still
under F-CPU's copyright. If you're a company that wants a customized
chip, you'll have to modify the sources or add some stuffs to a
certain extent, and those must be redistributed in your own bundle
(it can then be merged with the global f-cpu bundle).

In fact, it is not only a matter of free tools. it's also a matter
of freedom to design and redistribute... When the GNU SW stops,
the old proprietary SW is king, so only the file distribution model
matters. I don't believe that any of us (AFAIK) can make a whole
ASIC in his corner of the Net : we must be together and collaborate
with companies that are willing to help the project (and still respect
the design goals and the charter). I don't think that Free Software
can help much here. at least, this year...

So my "personal" answer to your first question is : non-free SW is
not of any good or bad, because there is no other tool. We have to use
them as long as nothing else exists. OTOH, our goal is to design stuff,
not to stay outside of the real world. We have to make some small
compromises and apply the principle of freedom in the other directions :-)

The next months (i don't know how long it will last) will still require
VHDL engineering. Simili and other tools will remain our swords, just
the way it is for one or two months. As for a "next step", it is naturally
the implementation as a chip. We will have to solve the BIST problem
in VHDL first, then find sponsors in the IC world. These sponsors
will determine which technology will be used, thus what SW and library
will be used. That's where the reality says : "there's no free SW here".

> Shaun Kruger
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 18:03:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01296 for ; Mon, 27 Nov 2000 01:23:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:35 +0100 (MET) Received: (qmail 20761 invoked by uid 0); 26 Nov 2000 16:58:51 -0000 Received: from jj.egroups.com (208.50.144.82) by mx12.rz2.gmx.net (mx12) with SMTP; 26 Nov 2000 16:58:51 -0000 X-eGroups-Return: sentto-1101623-1636-975257925-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 26 Nov 2000 16:58:50 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 16:58:44 -0000 Received: (qmail 37823 invoked from network); 26 Nov 2000 16:58:43 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 26 Nov 2000 16:58:43 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 26 Nov 2000 17:59:48 -0000 Received: from f-cpu.org (nas3-23.ras.club-internet.fr [195.36.203.23]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA26296 for ; Sun, 26 Nov 2000 17:58:40 +0100 (MET) Message-ID: <3A214275.37FC939A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> <20001126063101.53116@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 18:03:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Testability (was: Re: [f-cpu] size of F/G chips) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6994d49d59bb34f1b78f92d4931d29bf Status: R X-Status: N hi,

Michael Riepe wrote:
> I wrote my testbenches to check the design, not the hardware.
sure, i was simply remarking that it was not suitable for
BIST that's all...

> Some weeks ago when I was bored, I modified the testbench for the IAdd
> unit and saved all vectors to a file.  It wasn't an exhaustive test,
> but the output file became pretty big -- more than 64 MByte.  This is
> of course far too much for a built-in self test.
obviously :-)

> Using an error model like stuck-at-0/stuck-at-1 will dramatically reduce
> the number of vectors needed, but we will still need too many of them
> to put them on the chip, and we can't generate them on-the-fly either.
i've found some interesting stuff at work, but that doesn't apply to
a multiplier. It would be useful for the Xbar or the shuffler but not
iadd or imul. maybe we can find something similar.

> On the other hand, they can (and should) be created automatically from the
> (structural) VHDL sources and/or the resulting netlist (no need to write
> anything!).  Of course this means that testing is a two-step process:
> first, the sources must be proved to be correct (by simulating and/or
> formally verifying them), and then the test vectors are used to verify
> that the circuit matches its specifications (which have already been
> verified).  This is the only way to keep the verification process short.
sure.

> So far, this is only a static test (to identify damaged chips).  We will
> also need a speed test to determine how fast the chip will run.  This is
> a totally different animal -- it's usually not an exhaustive test, and
> it will check only critical parts of the chip (so-called "speed paths").
> I don't know (yet) how test vectors for this should look like, though.
> Any experts out there?
i guess that we should ask on the revelant newsgroups or mailing lists...
speed testing is not my current objective. there might be methods out there
that we can reuse.

> A built-in self test certainly is an interesting option, and it may
> be useful for the speed test, if there aren't too many test vectors.
it should also run at power-up and determine of the chip can boot...

> But it's not a substitute for the static test.  One reason is that it
> does not prove anything -- you can never know whether the rest of the
> chip is OK because the BIST circuitry itself may be broken --, the
> other reason is complexity.
true.

If anybody knows the field, please enlighten us :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE, trying to make a new bundle...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Ben Franchuk Sun Nov 26 09:02:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01305 for ; Mon, 27 Nov 2000 01:23:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:37 +0100 (MET) Received: (qmail 13791 invoked by uid 0); 26 Nov 2000 17:59:44 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx24) with SMTP; 26 Nov 2000 17:59:44 -0000 X-eGroups-Return: sentto-1101623-1638-975261575-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 26 Nov 2000 17:59:40 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 17:59:34 -0000 Received: (qmail 19412 invoked from network); 26 Nov 2000 17:59:34 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 26 Nov 2000 17:59:34 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 26 Nov 2000 17:59:34 -0000 Received: from jetnet.ab.ca (dialin56.jetnet.ab.ca [207.153.6.56]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA25580 for ; Sun, 26 Nov 2000 10:50:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A20C3AB.7D2A78E1@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A214277.68A3639F@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 08:02:51 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7672443ceb4ec52911cad0de2755c7bf Status: R X-Status: N Yann Guidon wrote:
> i guess that today's situation is rather OK :
> we have found some free (as "free as beer") SW that seem to
> suit our requirements (ease of use, VHDL'93 and rather general)

Just why was VHDL picked over other Hardware compiler languages?
I am distrustful of any hardware that can't be designed with
pencil and paper. Mind you "routing" is something don't mind
letting the computer do.


> I expect more or less that the next steps, if we speak about a
> full-custom IC or ASIC, will look a bit like today : there is
> a small set of "free" layout SW (i think about Alliance,
> Electric Editor, and others i've forgotten).
Having downloaded a few packages before I moved to FPGA's
for my work on my cpu designs, here are some random thoughts.

More work I think needs to be done with the free layout software
as many are a few years old. We have demo software (Size limitations)
limited and outdated libraries of macros. Alliance is a nice package
but some packages in version #4 are not free. The VHDL used is a subset
of normal VHDL and the libraries may be a year out of date. Also there
is a program name clash with 'lynx' the text web browser.

> There is also the possibility to use proprietary SW under
> the same conditions as above. Unfortunately, there are not
> many people skilled enough to manually layout an IC.
> It is also much more implementation-dependent because it is
> bound to the technology, budget and design goals.
>
> In the end, i think that there is no problem if a proprietary
> layout SW crunches our VHDL and generates a layout : a silicon
> compiler is like another compiler and the final layout is still
> under F-CPU's copyright. If you're a company that wants a customized
> chip, you'll have to modify the sources or add some stuffs to a
> certain extent, and those must be redistributed in your own bundle
> (it can then be merged with the global f-cpu bundle).

This does bother me since I still like all things in life bootstapble
and we are getting too many software packages that have a timed license.
I don't want the software to ask for a new license and die because the
company no longer supports that product.

> In fact, it is not only a matter of free tools. it's also a matter
> of freedom to design and redistribute... When the GNU SW stops,
> the old proprietary SW is king, so only the file distribution model
> matters. I don't believe that any of us (AFAIK) can make a whole
> ASIC in his corner of the Net : we must be together and collaborate
> with companies that are willing to help the project (and still respect
> the design goals and the charter). I don't think that Free Software
> can help much here. at least, this year...

True...
Hmm Santa I want a home foundry for XMASS?

> So my "personal" answer to your first question is : non-free SW is
> not of any good or bad, because there is no other tool. We have to use
> them as long as nothing else exists. OTOH, our goal is to design stuff,
> not to stay outside of the real world. We have to make some small
> compromises and apply the principle of freedom in the other directions :-)
>
> The next months (i don't know how long it will last) will still require
> VHDL engineering. Simili and other tools will remain our swords, just
> the way it is for one or two months. As for a "next step", it is naturally
> the implementation as a chip. We will have to solve the BIST problem
> in VHDL first, then find sponsors in the IC world. These sponsors
> will determine which technology will be used, thus what SW and library

I think a FREE FPGA would be a very useful idea, if one can get
past all the Patent crap.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Nicolas Boulay Sun Nov 26 22:46:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01353 for ; Mon, 27 Nov 2000 01:23:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:51 +0100 (MET) Received: (qmail 19474 invoked by uid 0); 26 Nov 2000 21:43:47 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx04) with SMTP; 26 Nov 2000 21:43:47 -0000 X-eGroups-Return: sentto-1101623-1639-975274998-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 26 Nov 2000 21:43:46 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 21:43:10 -0000 Received: (qmail 84081 invoked from network); 26 Nov 2000 21:43:10 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 26 Nov 2000 21:43:10 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 26 Nov 2000 22:44:15 -0000 Received: from ifrance.com (nas13-251.vlt.club-internet.fr [195.36.163.251]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA13392 for ; Sun, 26 Nov 2000 22:43:06 +0100 (MET) Message-ID: <3A2184BA.B2DC6533@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 22:46:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b4013813a739558065dd3c650e919629 Status: R X-Status: N I don't understand why you absolutely want to use VHDL 93. Almost none
VHDL software use VHDL 93 but 85 or some things like that. So if you
want to use it, you will never synthetise the f-cpu ! I still don't
understand you.

nicO
eGroups Sponsor
click here
From Nicolas Boulay Sun Nov 26 22:59:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01356 for ; Mon, 27 Nov 2000 01:23:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:52 +0100 (MET) Received: (qmail 24869 invoked by uid 0); 26 Nov 2000 21:56:37 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx16) with SMTP; 26 Nov 2000 21:56:37 -0000 X-eGroups-Return: sentto-1101623-1640-975275783-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 26 Nov 2000 21:56:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 21:56:22 -0000 Received: (qmail 31931 invoked from network); 26 Nov 2000 21:56:21 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 26 Nov 2000 21:56:21 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 26 Nov 2000 21:56:21 -0000 Received: from ifrance.com (nas13-251.vlt.club-internet.fr [195.36.163.251]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA08152 for ; Sun, 26 Nov 2000 22:56:18 +0100 (MET) Message-ID: <3A2187D2.4637DE32@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 22:59:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] size of F/G chips Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f825f049b3ccad4a0e1710c243bc9b1c Status: R X-Status: N

Yann Guidon a =E9crit :
>
> hello,
>
> Jonathan Vaughn wrote:
> > What is the most # of pins we can get away with on these chips, d= o you think?
> >
> > and do we still use a general rule of thumb of ~25% or so being p= ower/ground?
>
> If you remember last year, we tried something with a Socket7 package,<= BR> > 315 pins (?) and easy-to-find ZIF, but /not/ compatible with PCs.
> it was more or less routable with  a high quality, 6-layers PCB.<= BR> >

Actual mother board (for PC) are 4 layers (less expensive).

> general description : mono-CPU PCB with two high-speed 64-bit SDRAM bu= ses
> and one 32-bit I/O bus.
>
> changes : the CPU is in a BGA352 package, it has a smaller footprint a= nd

Much too expensive. BGA are 4 times more expensive compare to QFP. The
probleme is the "B" in BGA.

> the PCB can be smaller. The initial 128S-b DRAM bus has been split int= o 2
> independent buses due to routing and trace length troubles. The SDRAM = chips
> are more recent, high-speed and wide chips (32-b data bus, 133 or 266 = MHz
> depending on the availability of the parts). To reduce skew and other = nasty
> stuffs, they are directly soldered by pairs of pairs, a 2*32-bit pair = on each side
> of the board. It increases the density and we can access 8 independent= banks
> (1 2*32-b chip pair has 4 banks each).
>

Why not !

> The same old rule-of-thumb about the ground/power pins applies, about = 20 or 25%
> of the BGA pins are used, but it depends on a lot of parameters.
>
> Since there is no pin left for an external cache, we will need a large= one on-chip,
> but this is not a big problem because the funders propose their own li= braries.
> That's where we will decide what kind of RAM we want, eDRAM or usual S= RAM etc...
>

SRAM for L1, eDRAM for L2 (refresh will be a big problem !)

> other details : approx. size of the module is 5*9 cm. It could use an = ol cheap DRAM
> socket for connexion with I/Os (approx number of signals is 70) so the= re is
> no connector to solder on the PCB. I don't know about the PCB manufact= uring, but
> the total cost is estimated around $150 (with a big 70% uncertainty fa= ctor) but

No, much higher. I have paid (e=3Dm6) 100 =80 for a credit card size PCB fo= r
2 layers. So... double the price for a 4 layers and remember that you
paid every cm=B2.

> it will vary with the quantity or quality... Soldering the SDRAM on on= e PCB side
> only might reduce the soldering cost but increase the PCB surface and = cost...
>
> The SDRAM chips would be 64Mbits parts so we would have 64Mbytes per b= oard.
> I don't know whether higher density parts will be available soon, but = they
> will be used instead, no replacement of the chip is possible by the us= er.
>
> <!!!!!!!!!!>
>
> I stress on a very important point : testability. If we produce such c= hips, we
> will have to proveide a (vector) testbench for the chips to the fundry=
> as well as a physical testbench (go/no-go + diagnostics) to the PCB ma= ker.
> Given the price of a single module and the relatively low price of our=
> work horsepower, this is a crucial point for the overal yield of the p= roject.
>
> </!!!!!!!!!!>
>
> still on the testability issue : we should write #now# the vectors tha= t will be used
> to test the f-cpu chips in the fundry. We already have a testbench for= most of
> the units, but they are "only" proofs of concept. Michael Ri= epe's testbenches
> can not be used in the fundry to test the chips, we need an exhaustive= but much faster
> way to determine whether a unit is damaged. we should make a BIST, a k= ind of embedded
> checker that will verify the chip when it's still on the waffer...

Such test are generated by software.

>
> > -JV [note: new email, FYI]
> WHYGEE (old good email)
nicO
eGroups Sponsor=
3D"click
From Michael Riepe Sun Nov 26 21:32:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01359 for ; Mon, 27 Nov 2000 01:23:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:53 +0100 (MET) Received: (qmail 3980 invoked by uid 0); 26 Nov 2000 22:22:55 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx22) with SMTP; 26 Nov 2000 22:22:55 -0000 X-eGroups-Return: sentto-1101623-1641-975277363-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 26 Nov 2000 22:22:53 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 22:22:42 -0000 Received: (qmail 61733 invoked from network); 26 Nov 2000 22:22:40 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 26 Nov 2000 22:22:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.176) by mta2 with SMTP; 26 Nov 2000 22:22:34 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01811; Sun, 26 Nov 2000 21:32:38 +0100 Message-ID: <20001126213238.63320@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> <20001126063101.53116@thrai.stud.uni-hannover.de> <3A214275.37FC939A@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A214275.37FC939A@f-cpu.org>; from Yann Guidon on Sun, Nov 26, 2000 at 06:03:49PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 21:32:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Testability (was: Re: [f-cpu] size of F/G chips) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f8472acf9a0a88eb5442f4d0a8f07bc3 Status: R X-Status: N On Sun, Nov 26, 2000 at 06:03:49PM +0100, Yann Guidon wrote:

> Michael Riepe wrote:
> > I wrote my testbenches to check the design, not the hardware.
> sure, i was simply remarking that it was not suitable for
> BIST that's all...

Sure it isn't.  But it's needed anyway.

IMHO, a reasonable BIST/POST should be a minimal test that verifies
that the IF/ID unit, the caches, the register bank(s), all external
(bus) interfaces and all data paths inside the CPU work correctly.
Execution unit tests should be reduced to a minimum; just make sure that
you can clock data in and out (in other words: verify that the separate
units that have already been verified by the static test are able to
talk to each other the way they're supposed to, but don't care about
their internals).  Once that is done, start fetching and executing
instructions -- and let the software do the remaining work.

[...]
> > Using an error model like stuck-at-0/stuck-at-1 will dramatically reduce
> > the number of vectors needed, but we will still need too many of them
> > to put them on the chip, and we can't generate them on-the-fly either.
> i've found some interesting stuff at work, but that doesn't apply to
> a multiplier. It would be useful for the Xbar or the shuffler but not
> iadd or imul. maybe we can find something similar.

What is it, and what does it do?

[...]
> > A built-in self test certainly is an interesting option, and it may
> > be useful for the speed test, if there aren't too many test vectors.
> it should also run at power-up and determine of the chip can boot...

Yes, of course (see above).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 23:44:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01365 for ; Mon, 27 Nov 2000 01:23:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:55 +0100 (MET) Received: (qmail 952 invoked by uid 0); 26 Nov 2000 22:39:43 -0000 Received: from mo.egroups.com (208.50.144.78) by mx19.rz2.gmx.net (mx19) with SMTP; 26 Nov 2000 22:39:43 -0000 X-eGroups-Return: sentto-1101623-1642-975278377-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 26 Nov 2000 22:39:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 22:39:36 -0000 Received: (qmail 6642 invoked from network); 26 Nov 2000 22:39:35 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 26 Nov 2000 22:39:35 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 26 Nov 2000 22:39:35 -0000 Received: from f-cpu.org (nas3-89.aub.club-internet.fr [195.36.145.89]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA25925 for ; Sun, 26 Nov 2000 23:39:31 +0100 (MET) Message-ID: <3A219255.F56CE15E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A214277.68A3639F@f-cpu.org> <3A20C3AB.7D2A78E1@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 23:44:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9e0825d3ab2c9ecc238ceb94f8e8f019 Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann Guidon wrote:
> > i guess that today's situation is rather OK :
> > we have found some free (as "free as beer") SW that seem to
> > suit our requirements (ease of use, VHDL'93 and rather general)
> Just why was VHDL picked over other Hardware compiler languages?
if you consider that the most participating people are german and french,
VHDL looks like a natural choice ;-) Then there is the possibility
to translate to other langages if needed. a C rewrite is possible,
for example, but experience showed that it is possible only if the
specifications are complete and working.

Look at the OpenCollector.org website and search EDA SW.
one half is VHDL and the other half is VERILOG.
Today there is no "good" (as in free, portable, working and
uptodate) schematic AND simulation standard. Otherwise they would
have been used ! ;-)

Last thing : in practice, VHDL is not written like an improvisation.
The code corresponds to a well undestood and studied device.
Of course there is the possibility to write crappy code, but experience
shows that Michael's code is good enough ;-)

> I am distrustful of any hardware that can't be designed with
> pencil and paper. Mind you "routing" is something don't mind
> letting the computer do.
yup. but we have to maintain several independent "layers" in the
design. We'll route later. It was already (more or less) designed
with the routing constraints in mind, we'll see if the assumptions
were correct when the design will be implemented :-)

> > I expect more or less that the next steps, if we speak about a
> > full-custom IC or ASIC, will look a bit like today : there is
> > a small set of "free" layout SW (i think about Alliance,
> > Electric Editor, and others i've forgotten).
> Having downloaded a few packages before I moved to FPGA's
> for my work on my cpu designs, here are some random thoughts.
>
> More work I think needs to be done with the free layout software
> as many are a few years old. We have demo software (Size limitations)
> limited and outdated libraries of macros. Alliance is a nice package
> but some packages in version #4 are not free. The VHDL used is a subset
> of normal VHDL and the libraries may be a year out of date. Also there
> is a program name clash with 'lynx' the text web browser.

yup, Alliance is not adapted. Only the people who made it know how
to use it. that's why i think we'll ask them to help us when we will
be ready.

> > In the end, i think that there is no problem if a proprietary
> > layout SW crunches our VHDL and generates a layout : a silicon
> > compiler is like another compiler and the final layout is still
> > under F-CPU's copyright. If you're a company that wants a customized
> > chip, you'll have to modify the sources or add some stuffs to a
> > certain extent, and those must be redistributed in your own bundle
> > (it can then be merged with the global f-cpu bundle).
>
> This does bother me since I still like all things in life bootstapble
> and we are getting too many software packages that have a timed license.
> I don't want the software to ask for a new license and die because the
> company no longer supports that product.

the modified or added files will remain in a "transparent" format to avoid
such inconveniences... If the files are not salted with SW specific stuffs,
it's ok. Otherwise (ie there are proprietary stuffs in the file) it won't
be incorporated in the main f-cpu source tree.

> > I don't believe that any of us (AFAIK) can make a whole
> > ASIC in his corner of the Net : we must be together and collaborate
> > with companies that are willing to help the project (and still respect
> > the design goals and the charter). I don't think that Free Software
> > can help much here. at least, this year...
> True...
> Hmm Santa I want a home foundry for XMASS?
hey, me too ! meee tooo ! :-)))

> I think a FREE FPGA would be a very useful idea, if one can get
> past all the Patent crap.
true. But the big companies have to understand the benefits of
this approach. This won't happen before we finish the f-cpu.
it looks like a deadlocked situation, unless we forget the "nasty details".

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Sun Nov 26 23:50:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01371 for ; Mon, 27 Nov 2000 01:23:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:57 +0100 (MET) Received: (qmail 28494 invoked by uid 0); 26 Nov 2000 22:46:00 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx23) with SMTP; 26 Nov 2000 22:46:00 -0000 X-eGroups-Return: sentto-1101623-1643-975278753-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 26 Nov 2000 22:45:59 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 22:45:53 -0000 Received: (qmail 45670 invoked from network); 26 Nov 2000 22:45:53 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 26 Nov 2000 22:45:53 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 26 Nov 2000 23:46:58 -0000 Received: from f-cpu.org (nas3-89.aub.club-internet.fr [195.36.145.89]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA18128 for ; Sun, 26 Nov 2000 23:45:50 +0100 (MET) Message-ID: <3A2193D1.6080364D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 23:50:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 577282a47c36127e56ebd2834535a7a6 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> I don't understand why you absolutely want to use VHDL 93. Almost none
> VHDL software use VHDL 93 but 85 or some things like that. So if you
> want to use it, you will never synthetise the f-cpu ! I still don't
> understand you.

i believe (i may be wrong) that it is possible to transform '93 into '87
using simple syntactical transformations. what is the big difference anyway ?
iirc it is the file handling, and it's never used for synthesis.
if you have a better point, i'm ready :-)

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Lee Salzman Mon Nov 27 00:16:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01380 for ; Mon, 27 Nov 2000 01:23:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:23:59 +0100 (MET) Received: (qmail 28011 invoked by uid 0); 26 Nov 2000 23:26:30 -0000 Received: from jk.egroups.com (208.50.144.83) by mx19.rz2.gmx.net (mx19) with SMTP; 26 Nov 2000 23:26:30 -0000 X-eGroups-Return: sentto-1101623-1644-975280749-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 26 Nov 2000 23:19:11 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 23:19:08 -0000 Received: (qmail 49644 invoked from network); 26 Nov 2000 23:19:08 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 26 Nov 2000 23:19:08 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta2 with SMTP; 26 Nov 2000 23:19:07 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sun, 26 Nov 2000 15:18:50 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A2199B5.2CE20D3E@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0-test6 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 18:16:05 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GCC Miscellania Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 69fa0febb2df3abf399c93fb31f38989 Status: R X-Status: N Okay, as YG requested, from now on, the latest release
of GCC is now always at:

http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz

The original now has a '-1' suffix, but I doubt anyone
is going to be looking for that particular one. Also
fixed were some odd mistakes I had accidently left in
the the '-3' release. BTW, when using the release,
you must first have a working gcc-2.95.2 tree, which
you should untar the f-cpu release OVER. When
configuring, use the --target=fcpu-pc-linux-gnu
flag.

                        Lee
eGroups Sponsor
click here
From Michael Riepe Mon Nov 27 00:49:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01386 for ; Mon, 27 Nov 2000 01:24:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 01:24:00 +0100 (MET) Received: (qmail 2762 invoked by uid 0); 26 Nov 2000 23:53:47 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx02) with SMTP; 26 Nov 2000 23:53:47 -0000 X-eGroups-Return: sentto-1101623-1645-975282586-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 26 Nov 2000 23:49:54 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 26 Nov 2000 23:49:45 -0000 Received: (qmail 34793 invoked from network); 26 Nov 2000 23:49:44 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 26 Nov 2000 23:49:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.42) by mta2 with SMTP; 26 Nov 2000 23:49:42 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02420; Mon, 27 Nov 2000 00:49:45 +0100 Message-ID: <20001127004945.28096@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A2193D1.6080364D@f-cpu.org>; from Yann Guidon on Sun, Nov 26, 2000 at 11:50:57PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 00:49:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8a2275d4eaaea3a23694dd2d77c8bd08 Status: R X-Status: N On Sun, Nov 26, 2000 at 11:50:57PM +0100, Yann Guidon wrote:

> Nicolas Boulay wrote:
> > I don't understand why you absolutely want to use VHDL 93. Almost none
> > VHDL software use VHDL 93 but 85 or some things like that. So if you
> > want to use it, you will never synthetise the f-cpu ! I still don't
> > understand you.
>
> i believe (i may be wrong) that it is possible to transform '93 into '87
> using simple syntactical transformations. what is the big difference anyway ?
> iirc it is the file handling, and it's never used for synthesis.
> if you have a better point, i'm ready :-)

There are some syntactic and semantic differences.  E.g. it's not
possible to directly instantiate an entity (or a configuration) in
VHDL'87, like this:

      label : entity work.name port map (...);

Another point is that you can't put a declarative section after the
`generate' keyword (which I avoided anyway).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From "Albert Abramson" Mon Nov 27 01:44:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00313 for ; Mon, 27 Nov 2000 15:04:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:40 +0100 (MET) Received: (qmail 17337 invoked by uid 0); 27 Nov 2000 00:44:46 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx07) with SMTP; 27 Nov 2000 00:44:46 -0000 X-eGroups-Return: sentto-1101623-1646-975285881-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 27 Nov 2000 00:44:44 -0000 X-Sender: maxx@nventure.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 00:44:40 -0000 Received: (qmail 81331 invoked from network); 27 Nov 2000 00:44:39 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 27 Nov 2000 00:44:39 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta2 with SMTP; 27 Nov 2000 00:44:39 -0000 Received: from [24.10.43.202] by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001127004420.JTIM14040.femail1.sdc1.sfba.home.com@[24.10.43.202]> for ; Sun, 26 Nov 2000 16:44:20 -0800 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) To: f-cpu@egroups.com X-Priority: 3 Message-Id: <20001127004420.JTIM14040.femail1.sdc1.sfba.home.com@[24.10.43.202]> From: "Albert Abramson" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 16:44:39 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] feasibility of QDR and so forth Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9be1344b94c6a670b1bc911b95adaf14 Status: R X-Status: N Once again, folks.  I'm not being serious.  Unfortunately, it is difficult
to convey an expression of dry whit on my face.  It's like saying, "Let's
build a solid gold yacht."

What kind of memory system would I use?  Point-to-point I/O with a dedicated
bus to main memory.  That's what has worked best.  DDR or QDR everything.
That's not the point.  The point is that you isolate the memory path to
handle only memory transactions and you don't waste signal time on
extraneous things.

I would personally rather try to fit an entire 8 or 16 MB L3 cache right
onto the same package and handle most of my memory transactions that way.

----------
>From: Michael Riepe <michael@stud.uni-hannover.de>
>To: f-cpu@egroups.com
>Subject: Re: [f-cpu] feasibility of QDR and so forth
>Date: Sat, Nov 25, 2000, 6:01 AM
>

> On Sat, Nov 25, 2000 at 01:41:54AM -0800, Albert Abramson wrote:
>> Or just go to bipolar SRAM's in a COMA architecture and get 2ns latency for
>> every memory transaction.  1024-bit wide buses to each cache at 1000 MHz
>> each.  I believe that's 65,536 GB/sec of bandwidth without too much
>> pipelining.  Then build the internal data paths to match and use GaAs or
>> SiGe to get those 16GHz clock rates.
>
> Suffering from gigantomania?
>
> I expect the first `real' FC0 chips to run at frequencies in the 100...500
> MHz range (if we manage to build one in 2001).  Using cheap, 3 year old
> technology also means that current CPUs will run 4 times as fast as ours
> (in terms of clock speed), according to Moore's Law.
>
> Get real, please.
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>

eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 01:49:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00316 for ; Mon, 27 Nov 2000 15:04:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:41 +0100 (MET) Received: (qmail 30004 invoked by uid 0); 27 Nov 2000 00:46:05 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx16) with SMTP; 27 Nov 2000 00:46:05 -0000 X-eGroups-Return: sentto-1101623-1647-975285947-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 27 Nov 2000 00:45:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 00:45:47 -0000 Received: (qmail 69834 invoked from network); 27 Nov 2000 00:45:46 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 27 Nov 2000 00:45:46 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 27 Nov 2000 00:45:46 -0000 Received: from f-cpu.org (nas3-17.ras.club-internet.fr [195.36.203.17]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA19822 for ; Mon, 27 Nov 2000 01:45:03 +0100 (MET) Message-ID: <3A21AF7E.561ADE16@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> <20001127004945.28096@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 01:49:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5040593340446cc3a27bca0203bb85b2 Status: R X-Status: N hi,

Michael Riepe wrote:
> There are some syntactic and semantic differences.  E.g. it's not
> possible to directly instantiate an entity (or a configuration) in
> VHDL'87, like this:
>
>         label : entity work.name port map (...);
>
> Another point is that you can't put a declarative section after the
> `generate' keyword (which I avoided anyway).

well, i don't call this a reason to totally rewrite the source base...
it's just a matter of good coding habits...

If a synthesiser requires '87, then the little modifications will
be made.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 02:03:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00324 for ; Mon, 27 Nov 2000 15:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:44 +0100 (MET) Received: (qmail 7369 invoked by uid 0); 27 Nov 2000 01:00:08 -0000 Received: from jj.egroups.com (208.50.144.82) by mx11.rz2.gmx.net (mx11) with SMTP; 27 Nov 2000 01:00:08 -0000 X-eGroups-Return: sentto-1101623-1649-975286803-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 27 Nov 2000 01:00:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 01:00:02 -0000 Received: (qmail 23209 invoked from network); 27 Nov 2000 01:00:02 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 27 Nov 2000 01:00:02 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 27 Nov 2000 01:00:02 -0000 Received: from f-cpu.org (nas3-17.ras.club-internet.fr [195.36.203.17]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10927 for ; Mon, 27 Nov 2000 01:59:14 +0100 (MET) Message-ID: <3A21B2EB.1ECC0C9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 02:03:39 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] SH-5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6eed51215cf67032b4c253b3ac1772e1 Status: R X-Status: N http://www.hitachi.co.jp/Sicd/English/Products/micom/shmicome.htm
has a lot of docs. i'm d/ling some and i'll read later (if ever).
i've found NO data or architectural spec about the ELBRUS CPU.
i'm not worried anyway.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 02:02:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00327 for ; Mon, 27 Nov 2000 15:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:44 +0100 (MET) Received: (qmail 22624 invoked by uid 0); 27 Nov 2000 01:04:37 -0000 Received: from ci.egroups.com (208.50.99.231) by mx0.gmx.net (mx21) with SMTP; 27 Nov 2000 01:04:37 -0000 X-eGroups-Return: sentto-1101623-1648-975286716-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 27 Nov 2000 00:58:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 00:58:35 -0000 Received: (qmail 16586 invoked from network); 27 Nov 2000 00:58:35 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 27 Nov 2000 00:58:35 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 27 Nov 2000 01:59:40 -0000 Received: from f-cpu.org (nas3-17.ras.club-internet.fr [195.36.203.17]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA14878 for ; Mon, 27 Nov 2000 01:57:48 +0100 (MET) Message-ID: <3A21B28D.515A4609@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A2199B5.2CE20D3E@lvdi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 02:02:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] GCC Miscellania Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ad9c3ddf7713414b20ddf58c61e5b52c Status: R X-Status: N hello,

Lee Salzman wrote:
> Okay, as YG requested, from now on, the latest release
> of GCC is now always at:
>
> http://www.lvdi.net/~lee.salzman/gcc-2.95.2-fcpu.tar.gz

ok thanks !!! i've put the news on a new subdirectory at
http://www.f-cpu.de/gcc
i'll have to link all the other main pages to this new section.
it will take some time though.

>                                 Lee
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Keyshaun Mon Nov 27 02:41:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00336 for ; Mon, 27 Nov 2000 15:04:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:47 +0100 (MET) Received: (qmail 21692 invoked by uid 0); 27 Nov 2000 01:41:30 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx05) with SMTP; 27 Nov 2000 01:41:30 -0000 X-eGroups-Return: sentto-1101623-1650-975289286-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 27 Nov 2000 01:41:28 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 01:41:26 -0000 Received: (qmail 42694 invoked from network); 27 Nov 2000 01:41:25 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 27 Nov 2000 01:41:25 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta1 with SMTP; 27 Nov 2000 01:41:25 -0000 Received: (qmail 21352 invoked from network); 27 Nov 2000 01:41:16 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 27 Nov 2000 01:41:16 -0000 X-Sender: To: In-Reply-To: <3A20C3AB.7D2A78E1@jetnet.ab.ca> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 18:41:24 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f94b5496edf918e80a86f07dbd707841 Status: R X-Status: N I have been looking around and searching for IC layout tools, free or not.
Here are the places I looked at.

http://www.prolificinc.com/
http://www.mycad.com/  (dl demo)
http://www.cadabratech.com/home.html

I don't have any experiene to know if these will help when the time comes
to design a core, but if someone could take a look and tell me if they
will be useful that would be good.

Shaun Kruger
eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 02:52:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00342 for ; Mon, 27 Nov 2000 15:04:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:49 +0100 (MET) Received: (qmail 954 invoked by uid 0); 27 Nov 2000 01:49:23 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx10) with SMTP; 27 Nov 2000 01:49:23 -0000 X-eGroups-Return: sentto-1101623-1651-975289747-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by b05.egroups.com with NNFMP; 27 Nov 2000 01:49:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 01:49:07 -0000 Received: (qmail 24590 invoked from network); 27 Nov 2000 01:49:06 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 27 Nov 2000 01:49:06 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 27 Nov 2000 01:49:06 -0000 Received: from f-cpu.org (nas3-17.ras.club-internet.fr [195.36.203.17]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA23300 for ; Mon, 27 Nov 2000 02:48:39 +0100 (MET) Message-ID: <3A21BE6F.BA771E50@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 02:52:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EDA tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1795fc2217236b74d76c5c0ad560d829 Status: R X-Status: N hello,

Keyshaun wrote:
> I have been looking around and searching for IC layout tools, free or not.
> Here are the places I looked at.
<snip>
> I don't have any experiene to know if these will help when the time comes
> to design a core, but if someone could take a look and tell me if they
> will be useful that would be good.

i'll take a look.
But remember that IC technology is very diversified and volatile.
a layout may be unused when a new funder comes. it's usually
hard to make something completely independent from the factory.

> Shaun Kruger
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Keyshaun Mon Nov 27 07:19:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00363 for ; Mon, 27 Nov 2000 15:04:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:04:53 +0100 (MET) Received: (qmail 27855 invoked by uid 0); 27 Nov 2000 06:20:06 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx14) with SMTP; 27 Nov 2000 06:20:06 -0000 X-eGroups-Return: sentto-1101623-1652-975305996-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 27 Nov 2000 06:20:05 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 06:19:56 -0000 Received: (qmail 76678 invoked from network); 27 Nov 2000 06:19:55 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 27 Nov 2000 06:19:55 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta2 with SMTP; 27 Nov 2000 06:19:55 -0000 Received: (qmail 11455 invoked from network); 27 Nov 2000 06:19:45 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 27 Nov 2000 06:19:45 -0000 X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 23:19:54 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] IC Layout tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bff4d5240ef6f742f8098a843e520d2f Status: R X-Status: N What is needed in the IC Layout tools?  I have been seeing many things
talking about assembly using cells and autorouting between them.  Would a
layout editor that can abstract to the cell level be useful?

Example:
You have a cell library for registers and a set of libraries that have
various blocks of logic like adders and other mathematical functions or
whatever else is needed.  You place those cells and tell the tool to auto
route the signals between them using a netlist.

This sounds like what some programs already do, but they aren't Free.  If
we could define a standard for how this is handeled in software it
wouldn't be too hard to write the software.  You of all people know the
standard comes first.  I admit I am not much of a programmer, but I will
contribute what I can once a clear vision is defined.  I want to
contribute to the F-CPU, but I only have a website and some C experience.

Shaun Kruger
thekernel@subdimension.com
I want to do less talking and more contributing here.
eGroups Sponsor
click here
From Gregory Junker Mon Nov 27 13:52:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00417 for ; Mon, 27 Nov 2000 15:05:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 27 Nov 2000 15:05:06 +0100 (MET) Received: (qmail 30089 invoked by uid 0); 27 Nov 2000 12:50:21 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx14) with SMTP; 27 Nov 2000 12:50:21 -0000 X-eGroups-Return: sentto-1101623-1653-975329410-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 27 Nov 2000 12:50:18 -0000 X-Sender: gjunker@one.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 12:50:10 -0000 Received: (qmail 12170 invoked from network); 27 Nov 2000 12:50:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 27 Nov 2000 12:50:09 -0000 Received: from unknown (HELO mail4.one.net) (206.112.192.132) by mta3 with SMTP; 27 Nov 2000 13:51:15 -0000 Received: from shell.one.net ([206.112.192.106] EHLO shell.one.net ident: IDENT-NOT-QUERIED [port 15883]) by mail2.one.net with ESMTP id <47726-16257>; Mon, 27 Nov 2000 07:52:51 -0500 Received: from localhost (gjunker@localhost) by shell.one.net (8.9.3/8.9.3) with ESMTP id HAA21122 for ; Mon, 27 Nov 2000 07:42:26 -0500 X-Authentication-Warning: shell.one.net: gjunker owned process doing -bs To: Freedom CPU In-Reply-To: Message-ID: From: Gregory Junker MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 07:52:49 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IC Layout tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 23a8d8e97b98f1dd4022eedc6c0ef21a Status: R X-Status: N > Example:
> You have a cell library for registers and a set of libraries that have
> various blocks of logic like adders and other mathematical functions or
> whatever else is needed.  You place those cells and tell the tool to auto
> route the signals between them using a netlist.

yep, piece of cake. Should be able to code it up at weekend, no problem :)

Seriously, there are several commercial-grade tools that do this, and they
cost a lot of money, and there is a reason. Routing algorithms, especially
ones that (a) don't run in exponential time and therefore don't take 6
hours to route four cells, (b) aren't already patented or copyrighted, and
(c) aren't impossible to code, are few and far between.

I wouldn't want to be the one to dampen your enthusiasm, but I would not
want you to think that this is a trivial task. For example, have you
considered how to incorporate DRC into the routing process? As soon as
rules enter the picture the complexity goes off the scale...

> This sounds like what some programs already do, but they aren't Free.  If
> we could define a standard for how this is handeled in software it
> wouldn't be too hard to write the software.  You of all people know the

If I'm not mistaken, the standards already exist. I didn't take the VLSI
track in my CompE days, so I couldn't tell you what those standards
(read: formats) might be, but I'm sure they exist. It's simply a matter of
someone who does know chiming in.

greg
eGroups Sponsor
click here
From Ben Franchuk Sun Nov 26 17:35:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00368 for ; Tue, 28 Nov 2000 16:31:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:31:45 +0100 (MET) Received: (qmail 24455 invoked by uid 0); 27 Nov 2000 17:22:05 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 27 Nov 2000 17:22:05 -0000 X-eGroups-Return: sentto-1101623-1654-975344569-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fg.egroups.com with NNFMP; 27 Nov 2000 17:03:15 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 17:02:48 -0000 Received: (qmail 13759 invoked from network); 27 Nov 2000 17:02:48 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 27 Nov 2000 17:02:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 27 Nov 2000 17:02:47 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA10042 for ; Mon, 27 Nov 2000 09:53:25 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A213BB9.F18F9C4@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 26 Nov 2000 16:35:05 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] IC Layout tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b923d256b01c134288342e755fe7bfdc Status: R X-Status: N Gregory Junker wrote:
> Seriously, there are several commercial-grade tools that do this, and they
> cost a lot of money, and there is a reason. Routing algorithms, especially
> ones that (a) don't run in exponential time and therefore don't take 6
> hours to route four cells, (b) aren't already patented or copyrighted, and
> (c) aren't impossible to code, are few and far between.

In Routing it is not connecting things together that is the problem,It is laying
out the parts to have space for the wires. What parts do you move where?
The other question is what formats the foundries take for wafer design. It
is no use to have a Free layout tool and no way to make the parts, if the
libraries
use outdated processes.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Nicolas Boulay Mon Nov 27 21:55:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00451 for ; Tue, 28 Nov 2000 16:32:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:06 +0100 (MET) Received: (qmail 12267 invoked by uid 0); 27 Nov 2000 21:10:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx14) with SMTP; 27 Nov 2000 21:10:40 -0000 X-eGroups-Return: sentto-1101623-1655-975358295-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 27 Nov 2000 20:51:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 20:51:35 -0000 Received: (qmail 99444 invoked from network); 27 Nov 2000 20:51:34 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 27 Nov 2000 20:51:34 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 27 Nov 2000 21:52:39 -0000 Received: from ifrance.com (nas21-37.vlt.club-internet.fr [195.36.171.37]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA03953 for ; Mon, 27 Nov 2000 21:51:31 +0100 (MET) Message-ID: <3A22CA28.B2EE8FAA@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 21:55:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 407c8fb8120104df26786ec29abf7730 Status: R X-Status: N All IO function aren't the same (for debuging). That's a big problem for the simulation. After there is much more booleen fonctions (shift,..),
and many little tricky things which could make you lose many days.

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > I don't understand why you absolutely want to use VHDL 93. Almost= none
> > VHDL software use VHDL 93 but 85 or some things like that. So if = you
> > want to use it, you will never synthetise the f-cpu ! I still don= 't
> > understand you.
>
> i believe (i may be wrong) that it is possible to transform '93 into '= 87
> using simple syntactical transformations. what is the big difference a= nyway ?
> iirc it is the file handling, and it's never used for synthesis.
> if you have a better point, i'm ready :-)
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

eGroups Sponsor=
3D"click
From Michael Riepe Mon Nov 27 14:40:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00472 for ; Tue, 28 Nov 2000 16:32:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:12 +0100 (MET) Received: (qmail 16255 invoked by uid 0); 27 Nov 2000 22:38:21 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx15) with SMTP; 27 Nov 2000 22:38:21 -0000 X-eGroups-Return: sentto-1101623-1656-975364605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 27 Nov 2000 22:36:55 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 22:36:44 -0000 Received: (qmail 53716 invoked from network); 27 Nov 2000 22:36:44 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 27 Nov 2000 22:36:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.49) by mta1 with SMTP; 27 Nov 2000 22:36:41 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00474; Mon, 27 Nov 2000 14:40:05 +0100 Message-ID: <20001127144005.13481@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> <20001127004945.28096@thrai.stud.uni-hannover.de> <3A21AF7E.561ADE16@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A21AF7E.561ADE16@f-cpu.org>; from Yann Guidon on Mon, Nov 27, 2000 at 01:49:02AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 14:40:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ccb0614a51a307bc0b50df48e65600f0 Status: R X-Status: N On Mon, Nov 27, 2000 at 01:49:02AM +0100, Yann Guidon wrote:
[...]
> well, i don't call this a reason to totally rewrite the source base...
> it's just a matter of good coding habits...

Amen.

> If a synthesiser requires '87, then the little modifications will
> be made.

Piece of cake.  I checked iadd.vhdl yesterday, and it requires only a
single modification (in 5 or 6 places): remove the `is' keyword from
all component declarations.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 23:48:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00478 for ; Tue, 28 Nov 2000 16:32:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:14 +0100 (MET) Received: (qmail 2776 invoked by uid 0); 27 Nov 2000 22:43:47 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx18) with SMTP; 27 Nov 2000 22:43:47 -0000 X-eGroups-Return: sentto-1101623-1657-975365017-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 27 Nov 2000 22:43:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 22:43:36 -0000 Received: (qmail 52598 invoked from network); 27 Nov 2000 22:43:36 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Nov 2000 22:43:36 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 27 Nov 2000 22:43:35 -0000 Received: from f-cpu.org (nas1-205.aub.club-internet.fr [195.36.150.205]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA26326 for ; Mon, 27 Nov 2000 23:43:33 +0100 (MET) Message-ID: <3A22E4CC.151ADDED@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 23:48:44 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6b44f91257d2dd660c6e8493cbf795e9 Status: R X-Status: N hi,

i have no time anymore to reply as many mails as before, as
you can guess, so here are some thoughts :

- i am trying to put a new release together.
i have reorganized the files and the directories.
it's not coherent and not good to be put on the
web site. If anybody wants to have a look, it can be
downloaded from http://www.mime.up8.edu/~whygee/rel07.zip
(87KB) i stopped on sunday, i was working on EU_SR.vhdl

- I would like to rewrite the ROP2 unit.
or more precisely, write another implementation
in pure Riepe style :-) I got some useful hints
>from a VLSI coworker and i'll simply start
with a schematic view with Deasign Architect
(-> exported as a postscript and bitmap for convenience).

- Riepe's style is very good but according to this
coworker, no silicon compiler can handle this correctly.
it's good for two reasons : if we ever want to do manual
layout, or if we want to roughly estimate the complexity.
The objection is that "behavioural" style (well, to
a certain extent) is better understood (both by user and
compiler), there is no need to predict the clock and control
signal nets. other argument : it will optimize the logic
perfectly for the technology. In particular, negative logic
is handled automatically, without user intervention, and
it will certainly cut the latency in half (it removes
a lot of inverters at the gate outputs) [that's for CMOS
at least].

- If we had more schematic views of the available
designs, it would help clear up things. i'll do
whatever i can with the tools at work, with the few
time i have.

- Next steps :
After ROP2 is ok, we have to make a very good version of the
incrementer unit. then, i hope that Michael will have
a decent multiplier ready, and will start working on the idiv unit.
i'll restart the old Icache stuff. Then will come the tough time
of the scheduler...

So, before we really start to synthesise stuff, we have to
make a really good HDL version that works.
If we have this HDL, we can do anything.


French note : on saturday and sunday (dec. 2 and 3),
there is a pre-meeting in Paris. We will start to prepare
the Berlin 17C3 meeting. Please come ! s'il vous plait !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Mon Nov 27 23:50:49 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00481 for ; Tue, 28 Nov 2000 16:32:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:15 +0100 (MET) Received: (qmail 29209 invoked by uid 0); 27 Nov 2000 22:46:15 -0000 Received: from ck.egroups.com (208.50.144.69) by mx12.rz2.gmx.net (mx12) with SMTP; 27 Nov 2000 22:46:15 -0000 X-eGroups-Return: sentto-1101623-1658-975365141-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 27 Nov 2000 22:46:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 27 Nov 2000 22:45:41 -0000 Received: (qmail 40013 invoked from network); 27 Nov 2000 22:45:40 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Nov 2000 22:45:40 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 27 Nov 2000 23:46:45 -0000 Received: from f-cpu.org (nas1-205.aub.club-internet.fr [195.36.150.205]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA21839 for ; Mon, 27 Nov 2000 23:45:38 +0100 (MET) Message-ID: <3A22E549.9A7CF62B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> <20001127004945.28096@thrai.stud.uni-hannover.de> <3A21AF7E.561ADE16@f-cpu.org> <20001127144005.13481@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 23:50:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ddf443670cbee33cdd3e92a06294d9d Status: R X-Status: N hi,

Michael Riepe wrote:
> On Mon, Nov 27, 2000 at 01:49:02AM +0100, Yann Guidon wrote:
> [...]
> > well, i don't call this a reason to totally rewrite the source base...
> > it's just a matter of good coding habits...
> Amen.
hey, stop confirming me ;-)

> > If a synthesiser requires '87, then the little modifications will
> > be made.
> Piece of cake.  I checked iadd.vhdl yesterday, and it requires only a
> single modification (in 5 or 6 places): remove the `is' keyword from
> all component declarations.
cool. can you give a diff of the files you have checked ?
thx

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Michael Riepe Tue Nov 28 02:26:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00490 for ; Tue, 28 Nov 2000 16:32:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:17 +0100 (MET) Received: (qmail 16708 invoked by uid 0); 28 Nov 2000 01:28:03 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx09) with SMTP; 28 Nov 2000 01:28:03 -0000 X-eGroups-Return: sentto-1101623-1659-975374875-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 28 Nov 2000 01:28:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 01:27:54 -0000 Received: (qmail 78445 invoked from network); 28 Nov 2000 01:27:54 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 28 Nov 2000 01:27:54 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.119) by mta3 with SMTP; 28 Nov 2000 02:28:57 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02850; Tue, 28 Nov 2000 02:26:32 +0100 Message-ID: <20001128022632.08614@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> <20001127004945.28096@thrai.stud.uni-hannover.de> <3A21AF7E.561ADE16@f-cpu.org> <20001127144005.13481@thrai.stud.uni-hannover.de> <3A22E549.9A7CF62B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A22E549.9A7CF62B@f-cpu.org>; from Yann Guidon on Mon, Nov 27, 2000 at 11:50:49PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 02:26:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5692941a29216fd878a7ca0de159498 Status: R X-Status: N On Mon, Nov 27, 2000 at 11:50:49PM +0100, Yann Guidon wrote:

> > > If a synthesiser requires '87, then the little modifications will
> > > be made.
> > Piece of cake.  I checked iadd.vhdl yesterday, and it requires only a
> > single modification (in 5 or 6 places): remove the `is' keyword from
> > all component declarations.
> cool. can you give a diff of the files you have checked ?

I only changed iadd.vhdl so far; I will make a new bundle when I have
changed them all (and included the new multiplier), perhaps next weekend.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Tue Nov 28 02:22:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00493 for ; Tue, 28 Nov 2000 16:32:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:18 +0100 (MET) Received: (qmail 24786 invoked by uid 0); 28 Nov 2000 01:28:28 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx13) with SMTP; 28 Nov 2000 01:28:28 -0000 X-eGroups-Return: sentto-1101623-1660-975374899-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 28 Nov 2000 01:28:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 01:28:18 -0000 Received: (qmail 39997 invoked from network); 28 Nov 2000 01:28:18 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 28 Nov 2000 01:28:18 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.119) by mta3 with SMTP; 28 Nov 2000 02:29:21 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02832; Tue, 28 Nov 2000 02:22:52 +0100 Message-ID: <20001128022252.46845@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A22E4CC.151ADDED@f-cpu.org>; from Yann Guidon on Mon, Nov 27, 2000 at 11:48:44PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 02:22:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b4c4c408c293071c8f4361a189d84f5f Status: R X-Status: N On Mon, Nov 27, 2000 at 11:48:44PM +0100, Yann Guidon wrote:
[...]
> - Riepe's style is very good but according to this
> coworker, no silicon compiler can handle this correctly.
> it's good for two reasons : if we ever want to do manual
> layout, or if we want to roughly estimate the complexity.
> The objection is that "behavioural" style (well, to
> a certain extent) is better understood (both by user and
> compiler), there is no need to predict the clock and control
> signal nets. other argument : it will optimize the logic
> perfectly for the technology. In particular, negative logic
> is handled automatically, without user intervention, and
> it will certainly cut the latency in half (it removes
> a lot of inverters at the gate outputs) [that's for CMOS
> at least].

I was told that silicon compilers can handle structural VHDL better.
But I can also provide equivalent behavioral versions if necessary.

[...]
> - Next steps :
> After ROP2 is ok, we have to make a very good version of the
> incrementer unit. then, i hope that Michael will have
> a decent multiplier ready, and will start working on the idiv unit.

What about a 64x64 product in only 6 cycles?  Hold your hats guys :)

There's one thing left to discuss before I push this out: Does it
make sense to use the multiply-and-add capability of the multiplier?
The `integrated MAC' works fine as long as the destination register is
different each time, but when you want to sum up lots of products in a
single register, throughput decreases from 1 op/cycle to n+1 ops/cycle
(multiplier latency + 1 cycle for bypassing the result).

You can work around this limitation by using more than one result register
(and adding them later), but that will increase register pressure.
You can also use separate MUL and ADD instructions, but that isn't much
faster either (throughput depends on the latency of the ADD unit, and
the latency of a single `mac' is increased by 2 or 3).

Opinions anyone?
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Jonathan Vaughn Tue Nov 28 06:09:24 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00499 for ; Tue, 28 Nov 2000 16:32:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:19 +0100 (MET) Received: (qmail 32749 invoked by uid 0); 28 Nov 2000 05:09:29 -0000 Received: from fk.egroups.com (64.211.240.232) by mx11.rz2.gmx.net (mx11) with SMTP; 28 Nov 2000 05:09:29 -0000 X-eGroups-Return: sentto-1101623-1661-975388166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 28 Nov 2000 05:09:28 -0000 X-Sender: biosehn@airmail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 05:09:26 -0000 Received: (qmail 46935 invoked from network); 28 Nov 2000 05:09:25 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 28 Nov 2000 05:09:25 -0000 Received: from unknown (HELO smtp.airmail.net) (209.196.123.2) by mta1 with SMTP; 28 Nov 2000 05:09:25 -0000 Received: from sehnsucht from [64.217.234.46] by smtp.airmail.net (/\##/\ Smail3.1.30.16 #30.12) with smtp for sender: id ; Mon, 27 Nov 2000 23:09:51 -0600 (CST) Message-Id: <3.0.6.32.20001127230924.008fdbf0@mail.airmail.net> X-Sender: biosehn@mail.airmail.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@egroups.com, f-cpu@egroups.com In-Reply-To: <20001128022252.46845@thrai.stud.uni-hannover.de> References: <3A22E4CC.151ADDED@f-cpu.org> <3A22E4CC.151ADDED@f-cpu.org> From: Jonathan Vaughn MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 23:09:24 -0600 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 69136546699dfd993c0ada6c2254b15f Status: R X-Status: N At 02:22 AM 11/28/00 +0100, Michael Riepe wrote:
*snip*
>
>What about a 64x64 product in only 6 cycles?  Hold your hats guys :)
>
>There's one thing left to discuss before I push this out: Does it
>make sense to use the multiply-and-add capability of the multiplier?
>The `integrated MAC' works fine as long as the destination register is
>different each time, but when you want to sum up lots of products in a
>single register, throughput decreases from 1 op/cycle to n+1 ops/cycle
>(multiplier latency + 1 cycle for bypassing the result).

*snip*

if it's faster than manually adding it, then go for it - you can schedule
(if doing asm or having a compiler thats actually bright) code to go in
the 6 cycles probably, before you can issue another mac. as long as doing mac
in the multiply unit is faster than doing a mul then an add, then it makes
sense to support it.

-JV
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
eGroups Sponsor
click here
From Ben Franchuk Mon Nov 27 01:44:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00508 for ; Tue, 28 Nov 2000 16:32:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:21 +0100 (MET) Received: (qmail 5106 invoked by uid 0); 28 Nov 2000 05:36:50 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx01) with SMTP; 28 Nov 2000 05:36:50 -0000 X-eGroups-Return: sentto-1101623-1662-975389715-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 28 Nov 2000 05:36:48 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 05:35:14 -0000 Received: (qmail 94103 invoked from network); 28 Nov 2000 05:35:14 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 28 Nov 2000 05:35:14 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 28 Nov 2000 06:36:18 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA16936 for ; Mon, 27 Nov 2000 22:25:45 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A21AE67.38073A14@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> <3A22E4CC.151ADDED@f-cpu.org> <3.0.6.32.20001127230924.008fdbf0@mail.airmail.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 27 Nov 2000 00:44:23 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b940797d00b56663586cdd1d84f38034 Status: R X-Status: N Jonathan Vaughn wrote:
>
> >What about a 64x64 product in only 6 cycles?  Hold your hats guys :)
> if it's faster than manually adding it, then go for it - you can schedule
> (if doing asm or having a compiler thats actually bright) code to go in
> the 6 cycles probably, before you can issue another mac. as long as doing mac
> in the multiply unit is faster than doing a mul then an add, then it makes
> sense to support it.
>
What can one get for 1 cycle in the mac sub system? A 32x12->32 mult would be
useful
for unsigned multplies for array indexing of records.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From Colin Marquardt Tue Nov 28 06:09:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00514 for ; Tue, 28 Nov 2000 16:32:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:23 +0100 (MET) Received: (qmail 27935 invoked by uid 0); 28 Nov 2000 07:47:15 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 28 Nov 2000 07:47:15 -0000 X-eGroups-Return: sentto-1101623-1663-975397631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 28 Nov 2000 07:47:14 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 07:47:10 -0000 Received: (qmail 35111 invoked from network); 28 Nov 2000 07:47:10 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 28 Nov 2000 07:47:10 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 28 Nov 2000 07:47:09 -0000 Received: from morphin.marquardt-home.de (d254.nas21.sonic.net [209.204.136.254]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id IAA11233 for ; Tue, 28 Nov 2000 08:47:10 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 140d1h-0003zr-00 for ; Mon, 27 Nov 2000 21:09:57 -0800 To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> <20001126063101.53116@thrai.stud.uni-hannover.de> <3A214275.37FC939A@f-cpu.org> <20001126213238.63320@thrai.stud.uni-hannover.de> X-Now-Playing: GODFLESH's Us and Them - Bittersweet In-Reply-To: Michael Riepe's message of "Sun, 26 Nov 2000 21:32:38 +0100" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 28 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 27 Nov 2000 21:09:56 -0800 Reply-To: f-cpu@egroups.com Subject: Re: Testability (was: Re: [f-cpu] size of F/G chips) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9d71db9fac9b89accd34d59d7b78b9b7 Status: R X-Status: N Michael Riepe <michael@stud.uni-hannover.de> writes:

> IMHO, a reasonable BIST/POST should be a minimal test that verifies
> that the IF/ID unit, the caches, the register bank(s), all external
> (bus) interfaces and all data paths inside the CPU work correctly.

Currently, BIST is done for memories only. Logic BIST (LogicVision
seems to be *the* company in that area) is only starting to be
usable (means: we shouldn't waste time exploring that, unless
somebody is doing some tool evaluation for his company and needs a
demo design). Testing the logic is usually done with scan chains,
and there are tools which are doing the FF --> ScanFF thing. Tools
for ATPG (Automated Test Pattern Generation) are available -- as
usual with a hefty price tag. We need to find somebody who can do
this for us, and it's not going to be very easy.

There is not that much online info about testing, here are my links:

http://www.ednmag.com/reg/1996/020196/03df3.cfm
EDN -- 02.01.96 My memory is not what it used to be: Testing RAMs and ROMs

http://www.lvision.com/solution/membist_xt.htm
LogicVision: memBIST-XT[tm]

http://www.lvision.com/solution/membist_ic.htm"
LogicVision: memBIST-IC[tm]

http://www.mrc.unm.edu/symposiums/symp98/s8/ganesamorthi/npark_SRAM.html

eGroups Sponsor
click here
From Nicolas Matringe Tue Nov 28 09:40:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00517 for ; Tue, 28 Nov 2000 16:32:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:23 +0100 (MET) Received: (qmail 12487 invoked by uid 0); 28 Nov 2000 08:40:46 -0000 Received: from fl.egroups.com (64.211.240.233) by mx19.rz2.gmx.net (mx19) with SMTP; 28 Nov 2000 08:40:46 -0000 X-eGroups-Return: sentto-1101623-1664-975400843-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 28 Nov 2000 08:40:45 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 08:40:40 -0000 Received: (qmail 27296 invoked from network); 28 Nov 2000 08:40:40 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 28 Nov 2000 08:40:40 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 28 Nov 2000 09:41:45 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA23716 for ; Tue, 28 Nov 2000 08:40:38 GMT X-To: Message-ID: <3A236F73.1CB426F2@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <3A2032F8.2E08A0C0@f-cpu.org> <3A1863E8.ADE2E2F9@jetnet.ab.ca> <3A2071F4.C29402CB@f-cpu.org> <3A2184BA.B2DC6533@ifrance.com> <3A2193D1.6080364D@f-cpu.org> <3A22CA28.B2EE8FAA@ifrance.com> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 09:40:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ac71582913c101a01ac78abbb366fe28 Status: R X-Status: N Hi
Another difference is the use of hexadecimal with std_logic_vector. In
VHDL '87, you can not write this:

signal foo : std_logic_vector(31 DOWNTO 0);
...
foo <=3D x"12345678";

since x"12345678" is considered a bit_vector.

I encountered the problem yesterday with an entity that read a file
(with a '87 file declaration) and needed some vectors initialized ('93
style)

Nicolas Boulay wrote:
>
> All IO function aren't the same (for debuging). That's a big
> problem for the simulation. After there is much more booleen
> fonctions (shift,..), and many little tricky things which could
> make you lose many days.
>
> Yann Guidon a =E9crit :
> > Nicolas Boulay wrote:
> > > I don't understand why you absolutely want to use VHDL 93. > > > Almost none VHDL software use VHDL 93 but 85 or some things<= BR> > > > like that. So if you want to use it, you will never
> > > synthetise the f-cpu ! I still don't understand you.
> >
> > i believe (i may be wrong) that it is possible to transform
> > '93 into '87 using simple syntactical transformations. what is > > the big difference anyway ? iirc it is the file handling, and
> > it's never used for synthesis. if you have a better point, i'm > > ready :-)
> >
> > > nicO
> > WHYGEE
Nicolas MATRINGE          = ; IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLO= MBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
eGroups Sponsor=
3D"click
From Nicolas Matringe Tue Nov 28 09:45:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00523 for ; Tue, 28 Nov 2000 16:32:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:25 +0100 (MET) Received: (qmail 8466 invoked by uid 0); 28 Nov 2000 08:45:44 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx04) with SMTP; 28 Nov 2000 08:45:44 -0000 X-eGroups-Return: sentto-1101623-1665-975401137-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 28 Nov 2000 08:45:44 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 08:45:36 -0000 Received: (qmail 35451 invoked from network); 28 Nov 2000 08:45:36 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 28 Nov 2000 08:45:36 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 28 Nov 2000 09:46:41 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA23824 for ; Tue, 28 Nov 2000 08:45:36 GMT X-To: Message-ID: <3A23709D.58DFEB3C@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 09:45:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 982fb7efe6577e0f76ad7548d2233ca4 Status: R X-Status: N Yann Guidon wrote:

> - If we had more schematic views of the available
> designs, it would help clear up things. i'll do
> whatever i can with the tools at work, with the few
> time i have.

Since you work at Mentor, you should have access to some valuable tools:
First, Renoir. It's quite usefull for block diagrams but not much more
(I gave up trying to use it, the code it generated was really crappy)
Second, Leonardo Insight. It's an option to Leonardo Spectrum that shows
the schematics of the design (at the gate level). Really powerful.

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
eGroups Sponsor
click here
From whygee@club-internet.fr Tue Nov 28 10:41:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00529 for ; Tue, 28 Nov 2000 16:32:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:27 +0100 (MET) Received: (qmail 10118 invoked by uid 0); 28 Nov 2000 09:41:51 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx13) with SMTP; 28 Nov 2000 09:41:51 -0000 X-eGroups-Return: sentto-1101623-1666-975404504-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 28 Nov 2000 09:41:50 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 09:41:44 -0000 Received: (qmail 74293 invoked from network); 28 Nov 2000 09:41:44 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 28 Nov 2000 09:41:44 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 28 Nov 2000 09:41:43 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA27952 for f-cpu@egroups.com; Tue, 28 Nov 2000 10:41:42 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 10:41:42 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3baa5bd7898c3db614ec10c438cf3631 Status: R X-Status: N hi,

>De: Nicolas Matringe
>Yann Guidon wrote:
>> - If we had more schematic views of the available
>> designs, it would help clear up things. i'll do
>> whatever i can with the tools at work, with the few
>> time i have.
>Since you work at Mentor, you should have access to some valuable tools:
>First, Renoir. It's quite usefull for block diagrams but not much more
>(I gave up trying to use it, the code it generated was really crappy)
I tried it shortly.
i prefer DA anyway.

>Second, Leonardo Insight. It's an option to Leonardo Spectrum that shows
>the schematics of the design (at the gate level). Really powerful.
i'll check it.

>Nicolas MATRINGE
YG
eGroups Sponsor
click here
From whygee@club-internet.fr Tue Nov 28 10:48:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00532 for ; Tue, 28 Nov 2000 16:32:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:28 +0100 (MET) Received: (qmail 4747 invoked by uid 0); 28 Nov 2000 09:48:21 -0000 Received: from mu.egroups.com (208.50.99.218) by mx11.rz2.gmx.net (mx11) with SMTP; 28 Nov 2000 09:48:21 -0000 X-eGroups-Return: sentto-1101623-1667-975404898-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 28 Nov 2000 09:48:20 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 09:48:18 -0000 Received: (qmail 92094 invoked from network); 28 Nov 2000 09:48:18 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 28 Nov 2000 09:48:18 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 28 Nov 2000 10:49:23 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA01010 for f-cpu@egroups.com; Tue, 28 Nov 2000 10:48:15 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 10:48:15 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] CCC congress news Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5ee3886c1f37c9191b37e408f97461bd Status: R X-Status: N http://www.ccc.de/congress/
has all the available data.
Some info : entry ticket + sleeping
might cost around DM 100 ($50) aprox.

We have not yet negociated the participation
of the F-CPU team, i hope that one
or two people will have a free something.
i'll pay the normal price for almost
everything. i'll try to reserve some
room for 2 or 3 PCs.

Please bring your ID and some spare personal
pictures so your hardware can be tagged
by the security (so it won't be stealed)
if you come with a computer.

YG
eGroups Sponsor
click here
From whygee@club-internet.fr Tue Nov 28 11:15:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00541 for ; Tue, 28 Nov 2000 16:32:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:30 +0100 (MET) Received: (qmail 32574 invoked by uid 0); 28 Nov 2000 10:15:52 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx15) with SMTP; 28 Nov 2000 10:15:52 -0000 X-eGroups-Return: sentto-1101623-1668-975406549-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 28 Nov 2000 10:15:50 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 10:15:48 -0000 Received: (qmail 99576 invoked from network); 28 Nov 2000 10:15:48 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 28 Nov 2000 10:15:48 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 28 Nov 2000 10:15:48 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id LAA17628 for f-cpu@egroups.com; Tue, 28 Nov 2000 11:15:46 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 11:15:46 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] VHDL 93 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6558fe8203227bb0c485f75b3a74229c Status: R X-Status: N hi,


>De: Michael Riepe <michael@stud.uni-hannover.de>
>On Mon, Nov 27, 2000 at 11:50:49PM +0100, Yann Guidon wrote:
>> > > If a synthesiser requires '87, then the little modifications will
>> > > be made.
>> > Piece of cake.  I checked iadd.vhdl yesterday, and it requires only a
>> > single modification (in 5 or 6 places): remove the `is' keyword from
>> > all component declarations.
>> cool. can you give a diff of the files you have checked ?
>I only changed iadd.vhdl so far; I will make a new bundle when I have
>changed them all (and included the new multiplier), perhaps next weekend.

i'll need the new file and a diff output to see what changes.
i'll do whatever i can this week.
This week-end, some french people will meet and i hope to
release a new bundle on sunday night.

Can you please try to make a schematic view of your adder ?
(and other units as well ?)
if you have a scanner, it's a matter of some minutes,
upload the file somewhere. i'll see if i can make a cleaner
version. The schematics will be included in the /doc subdirectory
of the bundle. Maybe a gEDA file can do the trick,
if you can't make a tight JPEG/GIF.

> Michael "Tired" Riepe.
eGroups Sponsor
click here
From whygee@club-internet.fr Tue Nov 28 12:56:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00559 for ; Tue, 28 Nov 2000 16:32:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:34 +0100 (MET) Received: (qmail 11555 invoked by uid 0); 28 Nov 2000 11:56:34 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 28 Nov 2000 11:56:34 -0000 X-eGroups-Return: sentto-1101623-1669-975412589-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 28 Nov 2000 11:56:32 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 11:56:28 -0000 Received: (qmail 27646 invoked from network); 28 Nov 2000 11:56:28 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 28 Nov 2000 11:56:28 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 28 Nov 2000 11:56:27 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA13564 for f-cpu@egroups.com; Tue, 28 Nov 2000 12:56:26 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 12:56:26 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: edc82381253cd4ee995741289f8a03ad Status: R X-Status: N hi,

>De: Michael Riepe <michael@stud.uni-hannover.de>
>On Mon, Nov 27, 2000 at 11:48:44PM +0100, Yann Guidon wrote:
>[...]
>> - Riepe's style is very good but according to this
>> coworker, no silicon compiler can handle this correctly.
>> it's good for two reasons : if we ever want to do manual
>> layout, or if we want to roughly estimate the complexity.
>> The objection is that "behavioural" style (well, to
>> a certain extent) is better understood (both by user and
>> compiler), there is no need to predict the clock and control
>> signal nets. other argument : it will optimize the logic
>> perfectly for the technology. In particular, negative logic
>> is handled automatically, without user intervention, and
>> it will certainly cut the latency in half (it removes
>> a lot of inverters at the gate outputs) [that's for CMOS
>> at least].
>I was told that silicon compilers can handle structural VHDL better.
so the best way is to try with different SW suites...

>But I can also provide equivalent behavioral versions if necessary.

it is recommended to promote both styles. this way, there
is always a choice or option. one can compare the output
of the compiler for the two versions and choose the best
architecture.
One important thing with the strctural (gate-level)
implementation is that it proves that it is possible
within the design constraints. in fact it is easy to
create new featureful instructions, it is less funny
when it destroys the pipeline. So yes, both ways
are recommended... if ony one is available, it's still ok.

>[...]
>What about a 64x64 product in only 6 cycles?  Hold your hats guys :)
whoooo !

>There's one thing left to discuss before I push this out: Does it
>make sense to use the multiply-and-add capability of the multiplier?
it makes sense to use whatever HW does fast and best.
if you can do a unit that works great, it makes sense
to use its capabilities.

>The `integrated MAC' works fine as long as the destination register is
>different each time, but when you want to sum up lots of products in a
>single register, throughput decreases from 1 op/cycle to n+1 ops/cycle
>(multiplier latency + 1 cycle for bypassing the result).
i'm not sure to understand...
can you give asm examples ?

>You can work around this limitation by using more than one result register
>(and adding them later), but that will increase register pressure.
hey, we have 64 regs, we can easily unroll 4x !

>You can also use separate MUL and ADD instructions, but that isn't much
>faster either (throughput depends on the latency of the ADD unit, and
>the latency of a single `mac' is increased by 2 or 3).
>
>Opinions anyone?
well, if your unit does cool things, they'll find a place
in the architecture. we can rework the manual when everything
will be stable.

> Michael "Tired" Riepe
have fun,
YG
eGroups Sponsor
click here
From whygee@club-internet.fr Tue Nov 28 16:21:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00601 for ; Tue, 28 Nov 2000 16:32:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 28 Nov 2000 16:32:49 +0100 (MET) Received: (qmail 6607 invoked by uid 0); 28 Nov 2000 15:22:35 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx16) with SMTP; 28 Nov 2000 15:22:35 -0000 X-eGroups-Return: sentto-1101623-1670-975424888-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 28 Nov 2000 15:21:55 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 15:21:27 -0000 Received: (qmail 5821 invoked from network); 28 Nov 2000 15:21:25 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 28 Nov 2000 15:21:25 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 28 Nov 2000 15:21:25 -0000 Received: (from mnet@localhost) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA03539 for f-cpu@egroups.com; Tue, 28 Nov 2000 16:21:23 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 16:21:23 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: hosting for fcpu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d61db65222b459f3fb4858f9908e9cfc Status: R X-Status: N hi Graham !

>Hi Whygee,
>
>I've a feeling this may be too late now, but if F-cpu is
>still having hosting problems, it may be useful:
>the site Open Collector is on (and gEDA) would be interested
>in having F-cpu hosted there too.. As you know, it's
>in MIT - no commercial interests, no strings attached.
>Among the things they can offer are:
>Full access to an account on the system (no root, but
>roger (the sysadmin) has always been really quick at sorting out
>anything that needed root for me); web hosting; irc channels
>of your own; cvs with web interface; mailing list and
>archiving with decent spam filtering... basically, what
>you'd get from sourceforge but more personalized to
>what f-cpu needs. What do you think?

first thing i think is : thanks but you can ask this on
the public mailing list as well, there is no secret :-)

last year, the strategy was to span our project on as much
servers as possible. there is no active stuff in the US
so it is a good idea. unfortunately, i can't care about
all the sites at once, i need help to maintain them.

if seul.org can make personal passwords for each people
who will be responsible of a bit of the project,
it will be cool. Sven is in vacations (i guess) and
i don't know how it can be done at f-cpu.de.

things we need now :
- one password per user, so each one can
access his work directory (ex.: gcc, manual, vhdl, news...)
if the users are separated, there will be no security trouble.
- IRC, but i never use it and there are already some
established channels. the specialists will know :-)
- a message board. 10 lines per message, just to
quickly announce a release or an event or a bug etc...
(there would be a message board that the authorized
maintainers would access as well as another public one).
- CVS is ok. i don't have anything suitable for it,
so the web interface won't be enough... a mail interface
would be cool :-) (like a "CVS-majordomo")
- the hyper-cool thing would be time... but i don't know
where to find that stuff ...

I suppose that the other f-cpuers have other ideas.

>Graham
YG
eGroups Sponsor
click here
From Michael Riepe Tue Nov 28 14:25:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00483 for ; Wed, 29 Nov 2000 19:25:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:25:48 +0100 (MET) Received: (qmail 13108 invoked by uid 0); 28 Nov 2000 22:26:08 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 28 Nov 2000 22:26:08 -0000 X-eGroups-Return: sentto-1101623-1671-975450345-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 28 Nov 2000 22:26:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 22:25:44 -0000 Received: (qmail 57585 invoked from network); 28 Nov 2000 22:24:42 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 28 Nov 2000 22:24:42 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.167) by mta1 with SMTP; 28 Nov 2000 22:24:40 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00550; Tue, 28 Nov 2000 14:25:22 +0100 Message-ID: <20001128142522.54472@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Tue, Nov 28, 2000 at 12:56:26PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 14:25:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e63211b296164ad625b5466fe1b163db Status: R X-Status: N On Tue, Nov 28, 2000 at 12:56:26PM +0100, whygee@club-internet.fr wrote:
[...]
> >The `integrated MAC' works fine as long as the destination register is
> >different each time, but when you want to sum up lots of products in a
> >single register, throughput decreases from 1 op/cycle to n+1 ops/cycle
> >(multiplier latency + 1 cycle for bypassing the result).
> i'm not sure to understand...
> can you give asm examples ?

      mac r1, r2, r3      ; reads and writes r3
      mac r4, r5, r3      ; reads and writes r3

These two instructions have a read-after-write dependency that causes
a stall.

      Cycle   Action
      <0>     read r1, r2 and r3 and send them to the MUL unit
      <1..n>  first multiply-and-add
      <n+1>   write r3 (and bypass to MUL unit)
      <n+1>   read r4 and r5 and send them to the MUL unit
      <n+2>   start second multiply-and-add

To avoid the dependency (and the stall), you can use

      ; clear r6 somewhere
      mac r1, r2, r3      ; reads and writes r3
      mac r4, r5, r6      ; reads and writes r6
      ; and later:
      add r3, r6, r7      ; final result

or decompose the mac instruction.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Nicolas Boulay Tue Nov 28 23:39:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00486 for ; Wed, 29 Nov 2000 19:25:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:25:49 +0100 (MET) Received: (qmail 12119 invoked by uid 0); 28 Nov 2000 22:36:35 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx16) with SMTP; 28 Nov 2000 22:36:35 -0000 X-eGroups-Return: sentto-1101623-1672-975450989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 28 Nov 2000 22:36:32 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 28 Nov 2000 22:36:28 -0000 Received: (qmail 55230 invoked from network); 28 Nov 2000 22:36:09 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 28 Nov 2000 22:36:09 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 28 Nov 2000 22:36:08 -0000 Received: from ifrance.com (nas21-61.vlt.club-internet.fr [195.36.171.61]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA05986 for ; Tue, 28 Nov 2000 23:36:06 +0100 (MET) Message-ID: <3A24342F.1A7ED4@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001128142522.54472@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 28 Nov 2000 23:39:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 349707f1c9dc821f6020cf446ad3d32d Status: R X-Status: N Euh, you forget the Load instructions between each Mac...

nicO

Michael Riepe a =E9crit :
>
> On Tue, Nov 28, 2000 at 12:56:26PM +0100, whygee@club-internet.fr wrot= e:
> [...]
> > >The `integrated MAC' works fine as long as the destination re= gister is
> > >different each time, but when you want to sum up lots of prod= ucts in a
> > >single register, throughput decreases from 1 op/cycle to n+1 = ops/cycle
> > >(multiplier latency + 1 cycle for bypassing the result).
> > i'm not sure to understand...
> > can you give asm examples ?
>
>         mac r1, r2, r3  ;= reads and writes r3
>         mac r4, r5, r3  ;= reads and writes r3
>
> These two instructions have a read-after-write dependency that causes<= BR> > a stall.
>
>         Cycle   Acti= on
>         <0>  &= nbsp;  read r1, r2 and r3 and send them to the MUL unit
>         <1..n>  fir= st multiply-and-add
>         <n+1>  = ; write r3 (and bypass to MUL unit)
>         <n+1>  = ; read r4 and r5 and send them to the MUL unit
>         <n+2>  = ; start second multiply-and-add
>
> To avoid the dependency (and the stall), you can use
>
>         ; clear r6 somewhere >         mac r1, r2, r3  ;= reads and writes r3
>         mac r4, r5, r6  ;= reads and writes r6
>         ; and later:
>         add r3, r6, r7  ;= final result
>
> or decompose the mac instruction.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

eGroups Sponsor=
3D"click
From Yann Guidon Wed Nov 29 01:29:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00510 for ; Wed, 29 Nov 2000 19:25:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:25:56 +0100 (MET) Received: (qmail 10991 invoked by uid 0); 29 Nov 2000 00:27:22 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 29 Nov 2000 00:27:22 -0000 X-eGroups-Return: sentto-1101623-1673-975457603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 29 Nov 2000 00:27:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 00:26:42 -0000 Received: (qmail 97639 invoked from network); 29 Nov 2000 00:24:44 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Nov 2000 00:24:44 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 29 Nov 2000 00:24:44 -0000 Received: from f-cpu.org (nas4-82.ras.club-internet.fr [195.36.203.82]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA01664 for ; Wed, 29 Nov 2000 01:24:41 +0100 (MET) Message-ID: <3A244E01.97BBC4B2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 01:29:53 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 82a211c06b16c55e3378f3ab864fdb88 Status: R X-Status: N who remembers the popcount instruction ?

well, i was looking at its physical implementation
and it reminded me another "similar" function,
or at least similar to the parity function :

if this optional unit is implemented, it can easily
perform the SEC/ECC operations !

i have some verilog somewhere that does that,
it was posted by someone on this very list.
i don't understand this langage but it's rather
well commented.

If this idea goes on, it would be a simple
implementation, not something as optimized
as the other units...

g'nacht,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Wed Nov 29 02:07:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00522 for ; Wed, 29 Nov 2000 19:26:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:00 +0100 (MET) Received: (qmail 8808 invoked by uid 0); 29 Nov 2000 01:03:08 -0000 Received: from ho.egroups.com (208.50.99.200) by mx0.gmx.net (mx23) with SMTP; 29 Nov 2000 01:03:08 -0000 X-eGroups-Return: sentto-1101623-1675-975459755-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 29 Nov 2000 01:03:06 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 01:02:33 -0000 Received: (qmail 86979 invoked from network); 29 Nov 2000 01:02:32 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 29 Nov 2000 01:02:32 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 29 Nov 2000 01:02:32 -0000 Received: from f-cpu.org (nas3-30.ras.club-internet.fr [195.36.203.30]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA05279 for ; Wed, 29 Nov 2000 02:02:29 +0100 (MET) Message-ID: <3A2456DA.45827C5E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> <3A22E4CC.151ADDED@f-cpu.org> <3.0.6.32.20001127230924.008fdbf0@mail.airmail.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 02:07:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db88915f531596e5a4f5ce1087c4c15b Status: R X-Status: N hi,

Jonathan Vaughn wrote:
> *snip*
> if it's faster than manually adding it, then go for it - you can schedule
> (if doing asm or having a compiler thats actually bright) code to go in
> the 6 cycles probably, before you can issue another mac.
two important factors that you forget : pipelining and loop unrolling.
you can duplicate the loop kernel N times and use different partial registers,
and Michael Riepe seems "old enough" to put pipeline registers in the middle
of his design. He said : 6 cycles, and i guess that the throughput is 1.
even with a throughput of 2 or 3 it's good enough and really worth it :-)

> as long as doing mac
> in the multiply unit is faster than doing a mul then an add, then it makes
> sense to support it.
yup.

but the big "constraint" or challenge is to put instructions that are possible,
realistic or that can be implemented easily. if you have the sources for the unit,
even if it's a bit complex to understand, then there is no problem. Complex
instructions, when they deal with loads and stores etc, are much more difficult
to integrate in the design.


> -JV
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Wed Nov 29 02:07:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00525 for ; Wed, 29 Nov 2000 19:26:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:00 +0100 (MET) Received: (qmail 26038 invoked by uid 0); 29 Nov 2000 01:16:34 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx03) with SMTP; 29 Nov 2000 01:16:34 -0000 X-eGroups-Return: sentto-1101623-1674-975459755-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hl.egroups.com with NNFMP; 29 Nov 2000 01:02:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 01:02:33 -0000 Received: (qmail 70285 invoked from network); 29 Nov 2000 01:02:32 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 29 Nov 2000 01:02:32 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 29 Nov 2000 02:03:37 -0000 Received: from f-cpu.org (nas3-30.ras.club-internet.fr [195.36.203.30]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA29185 for ; Wed, 29 Nov 2000 02:02:29 +0100 (MET) Message-ID: <3A2456D8.E0278E8B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001128142522.54472@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 02:07:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 43f19e82ebcf2c452fefd8583cd6948d Status: R X-Status: N hi,

Michael Riepe wrote:
> On Tue, Nov 28, 2000 at 12:56:26PM +0100, whygee@club-internet.fr wrote:
> [...]
<snip>
>         mac r1, r2, r3  ; reads and writes r3
>         mac r4, r5, r3  ; reads and writes r3
<snip>
> To avoid the dependency (and the stall), you can use
>         ; clear r6 somewhere
>         mac r1, r2, r3  ; reads and writes r3
>         mac r4, r5, r6  ; reads and writes r6
>         ; and later:
>         add r3, r6, r7  ; final result
yup, that's a loop unrolling.

to avoid this annoying case, the 2r2w or 3r1w instructions (except L/S)
do write one result at register #N and the other result at #(N+1).
it helps a bit, particularly in this kind of configuration.

in our case :
          mac r1, r2, r3
will read r1, r2 and r3, then will write r4

(hum, i gotta reread the manual...)

anyway, it's the best time to ask this.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Wed Nov 29 02:07:40 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00528 for ; Wed, 29 Nov 2000 19:26:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:01 +0100 (MET) Received: (qmail 26113 invoked by uid 0); 29 Nov 2000 01:16:40 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx03) with SMTP; 29 Nov 2000 01:16:40 -0000 X-eGroups-Return: sentto-1101623-1676-975459759-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 29 Nov 2000 01:02:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 01:02:38 -0000 Received: (qmail 20013 invoked from network); 29 Nov 2000 01:02:32 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Nov 2000 01:02:32 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 29 Nov 2000 01:02:32 -0000 Received: from f-cpu.org (nas3-30.ras.club-internet.fr [195.36.203.30]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA29184 for ; Wed, 29 Nov 2000 02:02:29 +0100 (MET) Message-ID: <3A2456DC.1C759267@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> <3A22E4CC.151ADDED@f-cpu.org> <3.0.6.32.20001127230924.008fdbf0@mail.airmail.net> <3A21AE67.38073A14@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 02:07:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3c6833bc98c9c701a6f0b248891ac7d1 Status: R X-Status: N hi,

Ben Franchuk wrote:
> Jonathan Vaughn wrote:
> > >What about a 64x64 product in only 6 cycles?  Hold your hats guys :)
> > if it's faster than manually adding it, then go for it - you can schedule
> > (if doing asm or having a compiler thats actually bright) code to go in
> > the 6 cycles probably, before you can issue another mac. as long as doing mac
> > in the multiply unit is faster than doing a mul then an add, then it makes
> > sense to support it.
> What can one get for 1 cycle in the mac sub system? A 32x12->32 mult would be useful
> for unsigned multplies for array indexing of records.

what algo justifies multiplies inside a loop ?
usually, a loop such as

for (i=0; i<N; i++)
  a[i]=c[i]+f[i];

doesn't require a multiply, it MUST be replaced by
i=0;
do
  a[i]=c[i]+f[i];
  i++;       <-- there, you replace the +1 with the size of the element
while (i<N);

so only register+register or register+immediate formats are critical
(and are included as post-incremented forms in the f-cpu).
If you do something like @ = &a + (i*sizeof(element)) to encode a[i],
the sizeof is certainly a power of two and you spare a multiply.
then, if you access linearly to your data, you spare an index shift
(additiont only). Finally, if you access your data in a random fashion,
the multiply time is "shadowed" by the memory access time.
of course, multiplies can be pipelined, while memory accesses are less
easy to pipeline... so the win is not much interesting. you'd need
yet another parameter or field in the instruction.

maybe if the lack puts pressure on the CPU, we'll add a "feature"
but we have no room left ...

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 16:54:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00603 for ; Wed, 29 Nov 2000 19:26:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:19 +0100 (MET) Received: (qmail 23119 invoked by uid 0); 29 Nov 2000 15:54:40 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx24) with SMTP; 29 Nov 2000 15:54:40 -0000 X-eGroups-Return: sentto-1101623-1677-975513270-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 29 Nov 2000 15:54:39 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 15:54:29 -0000 Received: (qmail 8920 invoked from network); 29 Nov 2000 15:54:28 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 29 Nov 2000 15:54:28 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 29 Nov 2000 15:54:28 -0000 Received: (from mnet@localhost) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA05358; Wed, 29 Nov 2000 16:54:26 +0100 (MET) To: arma@mit.edu Cc: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 16:54:26 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: Re: [f-cpu] Re: hosting for fcpu (fwd) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d68f6fec6da0ab76780434b63733600 Status: R X-Status: N hi !

here are the details :

>> ok this sounds good enough for a start :-) you can
>> already start the config/adduser if you really want ;-)
>Ok. Start giving me usernames, then. :) Along with each username, you
>should give me an external email address (so I can notify them).

all the people in charge of a part of the design
(Michael Riepe, Olivier Jean, Erik Hansen, Lee etc)
should have a directory where hey can put files.
there would be also projects : gcc, manual, vhdl ...
that could be accessed by all.
This way, there can be several parallel versions
and the redundancy helps stabilise the project.


>Ok. We can handle (and even host dns for) the .org and .net, but we
>don't host .com's (nor should you point a .com at any seul machine).

.com and .net are used against netsquatting, .org is
a simple gateway and .de is stable. no need to host
.org at the mit. f-cpu.seul.org is an additional tool,
a la sourceforge, and it's ok.

>> i don't think that shell is necessary, ftp is
>> already a good start.
>Ok. We'll provide shell to everybody, but people should not plan to do
>serious development on cran.
no need to compile anything... otherwise we'd need
some CRAYs ;-)


>> something i propose is to make new accounts
>> in a new group ("f-cpu" sounds nice, huh ? ;-)).
>> i would have the rights over the group's
>> root files, plus some dirs, the others would have their
>> own directories. Someone at seul, with the help
>> of Graham, would watch out (if i ever get sick or
>> weird stuff like that) if i disappear, so the root files
>> would be updated by someone else.
>This seems very reasonable.

i hope that at least 3 people will watch over f-cpu.seul.org.
i have enough workload with the existing sites :-)

>> This way, they could upload their files through ftp
>> and make their own corner. A 10MB quota per people
>> would be short, but the overal doesn't need 1TB either ;-)
>> i guess that a group quota of 50M would be enough for a start.
>Don't worry too much about disk space.
it was just a hint ...

>> the URL, i guess, would be http://www.f-cpu.seul.org,
>> and the existing sites will continue to work the way they
>> do (that is : a bit). i'll put links to seul from everywhere.
>Ok. You can also point www.f-cpu.org at us directly.
at the DNS level ? (no need)

>I would suggest that you bite the bullet and install cvs on your
>home machine, if you're going to be doing development there.

i'll use ftp until i get a better conxion and an online linuxette.

thanks for your support,
>--roger
YG

PS: can we discuss on the f-cpu mailing list instead ?
eGroups Sponsor
click here
From Michael Riepe Wed Nov 29 14:12:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00609 for ; Wed, 29 Nov 2000 19:26:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:21 +0100 (MET) Received: (qmail 29309 invoked by uid 0); 29 Nov 2000 16:18:01 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx17) with SMTP; 29 Nov 2000 16:18:01 -0000 X-eGroups-Return: sentto-1101623-1679-975514673-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mw.egroups.com with NNFMP; 29 Nov 2000 16:17:56 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 16:17:52 -0000 Received: (qmail 1514 invoked from network); 29 Nov 2000 16:17:52 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 29 Nov 2000 16:17:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.123) by mta1 with SMTP; 29 Nov 2000 16:17:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00483; Wed, 29 Nov 2000 14:12:37 +0100 Message-ID: <20001129141236.64248@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001128142522.54472@thrai.stud.uni-hannover.de> <3A2456D8.E0278E8B@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A2456D8.E0278E8B@f-cpu.org>; from Yann Guidon on Wed, Nov 29, 2000 at 02:07:36AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 14:12:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5c1b4f70759ca46e0bffdf8163e8a548 Status: R X-Status: N On Wed, Nov 29, 2000 at 02:07:36AM +0100, Yann Guidon wrote:
[...]
> to avoid this annoying case, the 2r2w or 3r1w instructions (except L/S)
> do write one result at register #N and the other result at #(N+1).
> it helps a bit, particularly in this kind of configuration.
>
> in our case :
>           mac r1, r2, r3
> will read r1, r2 and r3, then will write r4
>
> (hum, i gotta reread the manual...)

IIRC the manual didn't say this.  It's true for 2r2w but not for 3r1w.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Wed Nov 29 14:17:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00612 for ; Wed, 29 Nov 2000 19:26:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:21 +0100 (MET) Received: (qmail 2780 invoked by uid 0); 29 Nov 2000 16:18:32 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx02) with SMTP; 29 Nov 2000 16:18:32 -0000 X-eGroups-Return: sentto-1101623-1680-975514692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by cj.egroups.com with NNFMP; 29 Nov 2000 16:18:29 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 16:18:11 -0000 Received: (qmail 2466 invoked from network); 29 Nov 2000 16:18:11 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 29 Nov 2000 16:18:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.123) by mta1 with SMTP; 29 Nov 2000 16:18:05 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00498; Wed, 29 Nov 2000 14:17:32 +0100 Message-ID: <20001129141732.14282@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A22E4CC.151ADDED@f-cpu.org> <3A22E4CC.151ADDED@f-cpu.org> <3.0.6.32.20001127230924.008fdbf0@mail.airmail.net> <3A2456DA.45827C5E@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A2456DA.45827C5E@f-cpu.org>; from Yann Guidon on Wed, Nov 29, 2000 at 02:07:38AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 14:17:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: df81dcb37614585c4773f1aa54f957c4 Status: R X-Status: N On Wed, Nov 29, 2000 at 02:07:38AM +0100, Yann Guidon wrote:

> > if it's faster than manually adding it, then go for it - you can schedule
> > (if doing asm or having a compiler thats actually bright) code to go in
> > the 6 cycles probably, before you can issue another mac.
> two important factors that you forget : pipelining and loop unrolling.
> you can duplicate the loop kernel N times and use different partial registers,
> and Michael Riepe seems "old enough" to put pipeline registers in the middle
> of his design. He said : 6 cycles, and i guess that the throughput is 1.

Yes, of course!

> even with a throughput of 2 or 3 it's good enough and really worth it :-)

Ok, you convinced me -- I'll put it in.  It doesn't cost much anyway.

Stay tuned,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From Michael Riepe Wed Nov 29 14:39:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00615 for ; Wed, 29 Nov 2000 19:26:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:22 +0100 (MET) Received: (qmail 12511 invoked by uid 0); 29 Nov 2000 16:18:17 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx99) with SMTP; 29 Nov 2000 16:18:17 -0000 X-eGroups-Return: sentto-1101623-1678-975514666-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 29 Nov 2000 16:18:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 16:17:45 -0000 Received: (qmail 72817 invoked from network); 29 Nov 2000 16:17:44 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 29 Nov 2000 16:17:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.123) by mta1 with SMTP; 29 Nov 2000 16:17:43 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00558; Wed, 29 Nov 2000 14:39:02 +0100 Message-ID: <20001129143902.10777@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A244E01.97BBC4B2@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A244E01.97BBC4B2@f-cpu.org>; from Yann Guidon on Wed, Nov 29, 2000 at 01:29:53AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 14:39:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5eca8d5250728da675be091c44b7f270 Status: R X-Status: N On Wed, Nov 29, 2000 at 01:29:53AM +0100, Yann Guidon wrote:
> who remembers the popcount instruction ?

Sounds familiar ;)

> well, i was looking at its physical implementation
> and it reminded me another "similar" function,
> or at least similar to the parity function :
>
> if this optional unit is implemented, it can easily
> perform the SEC/ECC operations !

Details, please :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 17:35:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00618 for ; Wed, 29 Nov 2000 19:26:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:23 +0100 (MET) Received: (qmail 31530 invoked by uid 0); 29 Nov 2000 16:35:10 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx07) with SMTP; 29 Nov 2000 16:35:10 -0000 X-eGroups-Return: sentto-1101623-1681-975515704-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 29 Nov 2000 16:35:09 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 16:35:03 -0000 Received: (qmail 30179 invoked from network); 29 Nov 2000 16:35:03 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 29 Nov 2000 16:35:03 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 29 Nov 2000 16:35:03 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA29118 for f-cpu@egroups.com; Wed, 29 Nov 2000 17:35:02 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 17:35:02 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3dd0d7c55d546d09378c78a79ae079e6 Status: R X-Status: N hi !

>> who remembers the popcount instruction ?
>Sounds familiar ;)
:-)

>> if this optional unit is implemented, it can easily
>> perform the SEC/ECC operations !
>Details, please :)

not much done, yet.
evaluation shows that it will require several pipestages :
a XOR requires 2 transistors level, so a 64-bit popcount
or parity requires more than 1 stage [at least].
i have some work to do, but let's remember this idea...

the popcount unit is not a priority yet.

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
yg
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 17:56:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00627 for ; Wed, 29 Nov 2000 19:26:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:24 +0100 (MET) Received: (qmail 4407 invoked by uid 0); 29 Nov 2000 17:00:53 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx13) with SMTP; 29 Nov 2000 17:00:53 -0000 X-eGroups-Return: sentto-1101623-1682-975517219-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 29 Nov 2000 17:00:50 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 17:00:19 -0000 Received: (qmail 58439 invoked from network); 29 Nov 2000 16:56:16 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 29 Nov 2000 16:56:16 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 29 Nov 2000 16:56:15 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA12921 for f-cpu@egroups.com; Wed, 29 Nov 2000 17:56:13 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 17:56:13 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 33ba1ef26974b49830354f1ef8e04880 Status: R X-Status: N hi,

>> to avoid this annoying case, the 2r2w or 3r1w instructions (except L/S)
>> do write one result at register #N and the other result at #(N+1).
>> it helps a bit, particularly in this kind of configuration.
>>
>> in our case :
>>           mac r1, r2, r3
>> will read r1, r2 and r3, then will write r4
>>
>> (hum, i gotta reread the manual...)
>
>IIRC the manual didn't say this.  It's true for 2r2w but not for 3r1w.

geeeez.
we'll have to fix some stuffs here and there...

YG
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 17:59:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00630 for ; Wed, 29 Nov 2000 19:26:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:25 +0100 (MET) Received: (qmail 9120 invoked by uid 0); 29 Nov 2000 17:05:04 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx17) with SMTP; 29 Nov 2000 17:05:04 -0000 X-eGroups-Return: sentto-1101623-1683-975517473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 29 Nov 2000 17:05:02 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 17:04:33 -0000 Received: (qmail 22195 invoked from network); 29 Nov 2000 16:59:19 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 29 Nov 2000 16:59:19 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 29 Nov 2000 18:00:24 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA15478 for f-cpu@egroups.com; Wed, 29 Nov 2000 17:59:16 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 17:59:16 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0a8c01b604a9531d9079d6caca2e3cc2 Status: R X-Status: N hi again,

>> you can duplicate the loop kernel N times and use different partial registers,
>> and Michael Riepe seems "old enough" to put pipeline registers in the middle
>> of his design. He said : 6 cycles, and i guess that the throughput is 1.
>Yes, of course!
heh. just like the rest of the design :-)

>> even with a throughput of 2 or 3 it's good enough and really worth it :-)
>Ok, you convinced me -- I'll put it in.  It doesn't cost much anyway.
yup.

>Stay tuned,
as always :-) even when it's tough...

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
YG
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 18:02:22 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00633 for ; Wed, 29 Nov 2000 19:26:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 19:26:26 +0100 (MET) Received: (qmail 15647 invoked by uid 0); 29 Nov 2000 17:06:47 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx99) with SMTP; 29 Nov 2000 17:06:47 -0000 X-eGroups-Return: sentto-1101623-1684-975517590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 29 Nov 2000 17:06:43 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 17:06:29 -0000 Received: (qmail 81615 invoked from network); 29 Nov 2000 17:02:24 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 29 Nov 2000 17:02:24 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 29 Nov 2000 17:02:23 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id SAA18211 for f-cpu@egroups.com; Wed, 29 Nov 2000 18:02:22 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 18:02:22 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] who needs an account at seul ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5f4f74b105c40bb99ece2fbf68fe3d9 Status: R X-Status: N hello,

Seul.org proposes web hosting, CVS and shell for f-cpu
designers. This way, everybody will be able to cooperate
without the old website limitations.

please tell us if you want to take a responsibility, and
which. on top of my head, the current ongoing parts :
Michael Riepe, Erik Hansen (+ ?) : vhdl
Lee : gcc
Olivier Jean : manual

if this list is false, please speak out.

have fun,
YG
eGroups Sponsor
click here
From Nathaniel Downes Wed Nov 29 19:46:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01106 for ; Wed, 29 Nov 2000 22:14:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 22:14:57 +0100 (MET) Received: (qmail 14551 invoked by uid 0); 29 Nov 2000 19:03:44 -0000 Received: from hn.egroups.com (208.50.99.199) by mx11.rz2.gmx.net (mx11) with SMTP; 29 Nov 2000 19:03:44 -0000 X-eGroups-Return: sentto-1101623-1685-975523590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 29 Nov 2000 18:46:36 -0000 X-Sender: down@ici.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 18:46:29 -0000 Received: (qmail 56629 invoked from network); 29 Nov 2000 18:46:24 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 29 Nov 2000 18:46:24 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta3 with SMTP; 29 Nov 2000 19:47:29 -0000 Received: from con1-pool-17.fcgnetworks.net (con1-pool-17.fcgnetworks.net [208.210.80.218]) by bajor.ici.net (8.8.8/8.8.8) with ESMTP id NAA18542 for ; Wed, 29 Nov 2000 13:46:48 -0500 (EST) To: f-cpu@egroups.com Message-Id: X-Mailer: Voyager Email for QNX (vmail v2.02) From: Nathaniel Downes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 13:46:23 -0500 (est) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] who needs an account at seul ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 022ad304535960596f352013a3f62626 Status: R X-Status: N Previously, you (whygee@club-internet.fr) wrote:
>
> [ attachment ]
>

Hey, count me in for VHDL as well.  (even if I am rather quiet on the list right now, so many other things going on)
eGroups Sponsor
click here
From whygee@club-internet.fr Wed Nov 29 20:53:17 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01121 for ; Wed, 29 Nov 2000 22:15:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 22:15:00 +0100 (MET) Received: (qmail 30344 invoked by uid 0); 29 Nov 2000 19:53:30 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx99) with SMTP; 29 Nov 2000 19:53:30 -0000 X-eGroups-Return: sentto-1101623-1686-975527603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 29 Nov 2000 19:53:27 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 19:53:22 -0000 Received: (qmail 26422 invoked from network); 29 Nov 2000 19:53:19 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Nov 2000 19:53:19 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 29 Nov 2000 20:54:24 -0000 Received: (from mnet@localhost) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id UAA25709 for f-cpu@egroups.com; Wed, 29 Nov 2000 20:53:17 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 20:53:17 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] who needs an account at seul ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 03865a3abc68ecb98d464a51977c5859 Status: R X-Status: N
eGroups Sponsor
click here
From yguidon@april.org Wed Nov 29 21:07:01 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01124 for ; Wed, 29 Nov 2000 22:15:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 29 Nov 2000 22:15:00 +0100 (MET) Received: (qmail 11112 invoked by uid 0); 29 Nov 2000 20:08:05 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx21) with SMTP; 29 Nov 2000 20:08:05 -0000 X-eGroups-Return: sentto-1101623-1687-975528430-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 29 Nov 2000 20:07:24 -0000 X-Sender: yguidon@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 29 Nov 2000 20:07:10 -0000 Received: (qmail 75770 invoked from network); 29 Nov 2000 20:07:10 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 29 Nov 2000 20:07:10 -0000 Received: from unknown (HELO ck.egroups.com) (10.1.2.83) by mta3 with SMTP; 29 Nov 2000 21:08:15 -0000 X-eGroups-Return: yguidon@april.org Received: from [10.1.2.48] by ck.egroups.com with NNFMP; 29 Nov 2000 20:07:10 -0000 To: f-cpu@egroups.com Message-ID: <903nl5+4q9d@eGroups.com> In-Reply-To: <3A23709D.58DFEB3C@IPricot.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 192.94.38.34 From: yguidon@april.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 29 Nov 2000 20:07:01 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: report for today Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1ba809d0fa83b310883ac1f447c10fec Status: R X-Status: N
eGroups Sponsor
click here
From Nicolas Boulay Thu Nov 30 12:33:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA03411 for ; Thu, 30 Nov 2000 14:28:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 30 Nov 2000 14:28:01 +0100 (MET) Received: (qmail 5289 invoked by uid 0); 30 Nov 2000 10:35:35 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx14) with SMTP; 30 Nov 2000 10:35:35 -0000 X-eGroups-Return: sentto-1101623-1688-975580530-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 30 Nov 2000 10:35:34 -0000 X-Sender: nicolas.boulay@isep.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 10:35:30 -0000 Received: (qmail 12975 invoked from network); 30 Nov 2000 10:35:30 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 30 Nov 2000 10:35:30 -0000 Received: from unknown (HELO herabis.isep.fr) (194.2.232.252) by mta3 with SMTP; 30 Nov 2000 11:36:33 -0000 Received: from lune.isep.fr ([194.3.122.148]) by herabis.isep.fr (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0G4U00LJN5FWXT@herabis.isep.fr> for f-cpu@egroups.com; Thu, 30 Nov 2000 11:33:32 +0000 (GMT) Received: from isep.fr (localhost [127.0.0.1]) by lune.isep.fr (8.9.1b+Sun/8.9.1) with ESMTP id LAA21420; Thu, 30 Nov 2000 11:33:31 +0000 (GMT) Sender: nboulay@lune.isep.fr To: nicolas.boulay@ifrance.com, f-cpu@egroups.com Message-id: <3A263B0B.63A9B395@isep.fr> Organization: ISEP X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 11:33:31 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Simple COMA Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4edc3fbb8219d9178e6c9099547060c Status: R X-Status: N http://www.sics.se/~ans/simple-coma/

An overview of differents multiprocessor architectures. For exemple :

http://playground.sun.com/pub/S3.mp/simple-coma/hpca-95/paper.html
eGroups Sponsor
click here
From JEAN Olivier Thu Nov 30 11:57:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA03414 for ; Thu, 30 Nov 2000 14:28:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 30 Nov 2000 14:28:02 +0100 (MET) Received: (qmail 6198 invoked by uid 0); 30 Nov 2000 10:57:43 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx03) with SMTP; 30 Nov 2000 10:57:43 -0000 X-eGroups-Return: sentto-1101623-1689-975581860-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 30 Nov 2000 10:57:42 -0000 X-Sender: O.JEAN@euronext.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 10:57:39 -0000 Received: (qmail 76920 invoked from network); 30 Nov 2000 10:57:39 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 30 Nov 2000 10:57:39 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta2 with SMTP; 30 Nov 2000 10:57:38 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XY8C5YCM; Thu, 30 Nov 2000 11:55:07 +0100 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Thu, 30 Nov 2000 11:57:34 +0100 Message-ID: <098A4E5B420CD3118F690008C75DD5DD04D36856@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 11:57:20 +0100 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] who needs an account at seul ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e7842e92b3e32564a269d0a5979e1289 Status: R X-Status: N Hi Everybody !

It's ok for me to deal with manual. I've contacted an author about a
wordprocessor for
Latex. He's ok to help me and perhaps to join our project ( I hope so ).

      Good bye.

            OlivieR.
eGroups Sponsor
click here
From whygee@club-internet.fr Thu Nov 30 12:33:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA03417 for ; Thu, 30 Nov 2000 14:28:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 30 Nov 2000 14:28:03 +0100 (MET) Received: (qmail 18431 invoked by uid 0); 30 Nov 2000 11:33:27 -0000 Received: from mq.egroups.com (208.50.144.79) by mx11.rz2.gmx.net (mx11) with SMTP; 30 Nov 2000 11:33:27 -0000 X-eGroups-Return: sentto-1101623-1690-975583989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 30 Nov 2000 11:33:24 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 11:33:09 -0000 Received: (qmail 95562 invoked from network); 30 Nov 2000 11:33:08 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 30 Nov 2000 11:33:08 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 30 Nov 2000 11:33:08 -0000 Received: (from mnet@localhost) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA04734 for f-cpu@egroups.com; Thu, 30 Nov 2000 12:33:07 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 12:33:07 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: RE: [f-cpu] who needs an account at seul ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 717aeb7e88a9500be5461c25ebaabe25 Status: R X-Status: N >De: JEAN Olivier <O.JEAN@euronext.fr>
> Hi Everybody !
>
> It's ok for me to deal with manual. I've contacted an author about a
>wordprocessor for
>Latex. He's ok to help me and perhaps to join our project ( I hope so ).
>
>      Good bye.
>
>            OlivieR.

ok, so the list today is :
Nate : VHDL
YG : the whole stuff
Olivier : manual

Anyone else ?

YG
eGroups Sponsor
click here
From Michael Riepe Thu Nov 30 06:30:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA03621 for ; Thu, 30 Nov 2000 15:01:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 30 Nov 2000 15:01:02 +0100 (MET) Received: (qmail 31487 invoked by uid 0); 30 Nov 2000 13:27:44 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx10) with SMTP; 30 Nov 2000 13:27:44 -0000 X-eGroups-Return: sentto-1101623-1691-975590830-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 30 Nov 2000 13:27:37 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 13:27:09 -0000 Received: (qmail 61314 invoked from network); 30 Nov 2000 13:27:09 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 30 Nov 2000 13:27:09 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.91) by mta3 with SMTP; 30 Nov 2000 14:28:13 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA01843; Thu, 30 Nov 2000 06:30:46 +0100 Message-ID: <20001130063046.44589@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Wed, Nov 29, 2000 at 05:35:02PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 06:30:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 08083291b598f71232236cecd598986b Status: R X-Status: N On Wed, Nov 29, 2000 at 05:35:02PM +0100, whygee@club-internet.fr wrote:
[popcount]
> not much done, yet.
> evaluation shows that it will require several pipestages :
> a XOR requires 2 transistors level, so a 64-bit popcount
> or parity requires more than 1 stage [at least].

8-bit takes a single stage (two rows of full adders, plus two half
adders), wider results probably two stages.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
From whygee@club-internet.fr Thu Nov 30 14:49:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA03627 for ; Thu, 30 Nov 2000 15:01:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 30 Nov 2000 15:01:04 +0100 (MET) Received: (qmail 31747 invoked by uid 0); 30 Nov 2000 13:50:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx15) with SMTP; 30 Nov 2000 13:50:06 -0000 X-eGroups-Return: sentto-1101623-1692-975592184-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 30 Nov 2000 13:50:01 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 13:49:44 -0000 Received: (qmail 34518 invoked from network); 30 Nov 2000 13:49:43 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 30 Nov 2000 13:49:43 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 30 Nov 2000 13:49:43 -0000 Received: (from mnet@localhost) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id OAA07116 for f-cpu@egroups.com; Thu, 30 Nov 2000 14:49:41 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 14:49:41 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 127b5933394476cc4a9063685a0db27d Status: R X-Status: N hi,

>On Wed, Nov 29, 2000 at 05:35:02PM +0100, whygee@club-internet.fr wrote:
>[popcount]
>> not much done, yet.
>> evaluation shows that it will require several pipestages :
>> a XOR requires 2 transistors level, so a 64-bit popcount
>> or parity requires more than 1 stage [at least].
>
>8-bit takes a single stage (two rows of full adders, plus two half
>adders), wider results probably two stages.
i'm not sure about the 8-bit popcount.
schematics, please ?

my POV :
8-bit popcount (old hack, found in CRAYs but wider)

In a software, i had studied a 7-bit popcount : result in
3 bits, the 6 first bits are used by two full adders,
the 7th is used as a "carry in" for the next stage that
consists of a 2x2bits+Cin adder. I don't remember how many
half adders it required.

Here, it is a bit more complex, but i remember that a
64-bit popcount can use the 64th bit as Cin too.
there are 21 FA for the first stage, then we add
2-bit numbers, then 3-bit numbers and so on until
it reaches the 6 bits of width.

depending on the FA's structure, it might require
>from 2 to 4 cycles of latency.

This makes me think about a trick :
can you add a generic component to your library ?
it would be a variable width pipeline stage (width
is determined by a generic)... it can be easily changed
(ie replaced by a boundary scan etc) and moved around
the design...

It's a matter of some minutes for you to do, but a nice
"feature" for us, designers :-)


have fun,
> Michael "Tired" Riepe
eGroups Sponsor
click here
From Michael Riepe Thu Nov 30 21:40:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00403 for ; Fri, 1 Dec 2000 07:54:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:19 +0100 (MET) Received: (qmail 29355 invoked by uid 0); 30 Nov 2000 21:05:04 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx22) with SMTP; 30 Nov 2000 21:05:04 -0000 X-eGroups-Return: sentto-1101623-1693-975618290-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 30 Nov 2000 21:05:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 21:04:49 -0000 Received: (qmail 12800 invoked from network); 30 Nov 2000 21:04:36 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 30 Nov 2000 21:04:36 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.47) by mta3 with SMTP; 30 Nov 2000 22:05:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00432; Thu, 30 Nov 2000 21:40:54 +0100 Message-ID: <20001130214054.49875@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Thu, Nov 30, 2000 at 02:49:41PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 21:40:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: Re: [f-cpu] today's idea :*) Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" X-UIDL: 154bcd53d6bd5010065ab73154022f07 Status: R X-Status: N --SUOF0GtieIMvvwua Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, Nov 30, 2000 at 02:49:41PM +0100, whygee@club-internet.fr wrote:
[...]
> i'm not sure about the 8-bit popcount.
> schematics, please ?

I'll include a GIF that contains two versions of an 8-bit popcount.
The first one uses half adders only, the second one both half and
full adders.

> my POV :
> 8-bit popcount (old hack, found in CRAYs but wider)
>
> In a software, i had studied a 7-bit popcount : result in
> 3 bits, the 6 first bits are used by two full adders,
> the 7th is used as a "carry in" for the next stage that
> consists of a 2x2bits+Cin adder. I don't remember how many
> half adders it required.
>
> Here, it is a bit more complex, but i remember that a
> 64-bit popcount can use the 64th bit as Cin too.
> there are 21 FA for the first stage, then we add
> 2-bit numbers, then 3-bit numbers and so on until
> it reaches the 6 bits of width.

Right.  But don't forget SIMD...

[...]
> This makes me think about a trick :
> can you add a generic component to your library ?
> it would be a variable width pipeline stage (width
> is determined by a generic)... it can be easily changed
> (ie replaced by a boundary scan etc) and moved around
> the design...

You mean, like lib/reg.vhdl?  I also made a similar component that can
be switched on and off (that is, replaced with wires if no register is
required) by setting a boolean generic, but I didn't use it yet.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
--SUOF0GtieIMvvwua Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="popcount.gif" R0lGODdhEwK9AvAAAAAAAP///ywAAAAAEwK9AgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+40FyOeAytxEl9vreDrFj6I3ARiWJzh4OGK4h3h3QiiRCAHpYsgX4diXGSkZIrjpsKiJ aNDJZdkYSDlpuvDZ6iGKCavwGnMZgPtA+8Eb6quBC/yq6wkailB8mkyqmnHMIKwcywftau3K TAOcOy3CXdu9Mpzs3Wtenk7GDb7Rzvxeih6szml/EP/drPpePU99IR+jWfXE/JOnYtUuhANT tGMnbQZEhd+wJbD1SKDA/j8HE218MtHiOYgMOR0EuG9XRBkkS2aMhO/kM5HXHHZcafBmzIQd dzaSGQxoS5cvTnoEioEmzoxCkQbU6dNgyo+pFkat+pLjPaItwB3lyUpW1q1jVRb84nVpn7B5 LFAl2NDs1UpG1ZbwZcnp05Rlf531kvYvCbyo4ipyOlTcLY6X3sLVCvaxXsiYtEnF6piVW8ST JVOeZLlo0zqZo5GOV7qmYrY03bVWnPpIPz2xL55G2rJ2ubYmoermO+t3TI2dWf98nZQ323W4 kScn3rs465Ah4Vi/jj279u3cu3v/Dj68+PHky5s/jz69+jKIxwV07xa+nTPtE76Pbx///Br1 /h3e969fIP+tM+AjBcKU334KSnTgXQ0O9qAiEQI2oScVRiPfHxcmqCGHg2T4oYcIsrdhLCVe BOKIHW5zIgf9CRiggTFetqCMNapo44o6stSiOz3SM6ODQYLxYo4h3igkkqDx9+MzTSb1ZJPS gRTlkFYpKaGVyDCppYVdglAkHlVGEWaSO+Io5pfZcImlPmqa+GYHZRI55pmVxemilDbMmWWb XvoJZp1U4ukjoaWkeCegIiYKo6JwOiqnoE7w6SakoRmJJqM8Guokp1B6qqcZlP5p55IAWorP npJqmimEoHI65aSrmlrqlY3WuiWLr6J66KK0YspqIbPaeiSupBaL/uxiuxqLoa/EpslrFaMG Ciuiv7ZaybC5MtuLtg1MuwW4j3IbjrPbJguDuJEui+61ZraLlrfNRhtrsO7emy272J4LLbnr RkuFunlWa+638hJ8qr8DAxwqifra+yzElSqc6jh5XYxxxvlozHHHG3sM8sVPhUwyRUuUjPLH Ka8M8sgsv5yxMTB7vNnMHddss8Y454yxFDxzvPPPNgctNMzGRPbZWobd1RzSINUrV9I5oAZ1 RUfbtJnTZCkt9WBV8/e1aVn3QLUPsQln29jOLO212n01gbZgUe9QNtlVxz3XY29rhjXbh/kc tmpd31A3D2cHXkvTfQ9utd+NQ4E3V3wb/q445VevzfjlwLXtuOaTIp5259tUTvfdoMvt1+Kb /y36OYBrrbcOhZfuOdNuc73647nXzkTkq+0++u1Tmw775HvPjfvWtpN5et7Gy0469LyznjmY 0S9fvevMF4/88MLjcDj3qWMOvPbZowR585J3D/717ddOCEXzzC7PIfI/H3s39lsz//Xx84+/ 3hXjf63o3/d+UZhyzeSA38rLvJLDO0kUkBf0I8oE0VHB32lwOOxjnwSnIRLfscAUHzQNBt03 NxJ+JIMpVIZzEhdBXVywg+M7ywxrqDwN3rCB3yvhNU74OhjKLYQoxKELV1hEHl6qfkGJYejC AUS2+RCKNFTi/hPXR5oqik2IzsuFF3EItyNeER5aFFz5vNgZFoIxG2kkHhclRxtzZHCK6aDF HGUoRju6j4470WMQx6jCDaLOiuWL4wJb90axbSR8iSTh+h5JyLk4UpBdXCMfe+VHKeJxTZlM nxkF6Y81lvGNLoTkKMeot1JSMn+u+aFYGIKNOybQJ7HcowNDV8se3lIdudxe4mYJS1iosYHK oSV0EGmbYgZTL4wE5ABRd0dU2qWSkbTgMysZzb9M05SyEaM2oZnELfYqNMc83xWvyU1xos+G A3zlINUpyXYq852ftOYvTZbNvAGTnkYIpDbdSU14snI3JjslP1GZzIKK8pDOPOcE/nXZUA7W M4B8PAoIbRlRJk70ZN6M524EGsAqWnQvyBzkSBkIwUbKMJEBnWhFWZpOhL4Uoauspg5XSlMR WuyTEoRpTUEqUp8atKVC/eJBacpQdv6zo5ujYyegkU+XPNWfXXOqPDeqBKpK9apFBepCpxpO rNqUKy/8qfAI6A+LTvWsmQAEJOZZQbTWTxrHiGtbHfHWVegUdnLVH13XWtK5upKgTUHpYO9J 2MAOVHc5pN4Z5RTWdX5OfGPdU2Rv4UbyNZaxi53eQj2bBN8NM3iK7Upmj/dZ6xnWfI91kfpM S1mvgm21LDlt8jqr2tKm1Jyu/SNqKztb3e40t5rFLWs3/gta2RL3abEVK2l5K5rkHte4kqUu ZGl7XV8WN6SWxW66bIu91rZSuN4lanY9qTrkPle8dJFudbnrXqTG96jjRe92h9pe8qa3t/uF 73LVO13/Bpijze2qRC773fnWl71JBfB78dvgMBZYvut1MGYV3ET9Qjem/N1whAU4Yfrm18Mj BC/nSExSFJeXwwuebH8hXOIVw/a/4bVwhxm8WxynmLkvTu2BZRxjGp9YxzIWLYJbLOEeA7fC 1k2w9Yq2y+NAWaGunDKV72nlsgIhywBVCZdZRrQvh0xmYg7zlM0MZTQXDXBibk6bUabmN/fM WhFzFcMQdit4Uehh+JoYsOzM/iA+13nQft7XsQy9DEHz6139+nO+7kwvOi8a0HrugsAKlTBH FzpdB1MgxYAE6U8blUCKNljBqJVpZYW60g/UtKlTLTFLdxpFp+5WrWHd50PHGtWi/tSqZVXq Vjd62IzmdLDX9OtdIzvPiA7XrJdYbEoTuyjPrliycy3saBNa1sf2tKt5/e1b0xrX2wZ3s8fF amd3e9zM1vamqb1uaGPb1tcu97LHcGlQt1va7h5htcfZ64bt295ayHenyP3uPgW63pMm+L8C jmd8/3vU4Ub3tB8N8UiLW94KT3fBJ/5ail884V0Bucnjbe2MQ+7kCNc1v+HN8Fer3OPsrnjN aTTz/nM/3OYLW3jOle3tkcuc5ymXOMoBTnR9J/3lDu85zZ2uc6gDPQsG9/XASe5yjD8d0z+f d9D7nW06HV3kYKf31f099qoLfOkh3zLLz27usrc87B2POte3rnS7W0HtaZd01kte7cmoT/Bz p/uegRzzhg+Y6YDfcd27fu/Emzfywvqw2Teu4Yk3nfIWlzzSj12ctv9AOroRfdE7X/jUKz7v oJf6zjU/+gdbXetI9rvtp453wx/87q+HvdmE7PubO572xr6x64dVL6hlxvRk46znc89xtOsK 9Xy+W9xnxXzDDRnyrG/y0h/f/Xon/+/QHzrOnb95ou81/YyffamnFLbQ/mM90bc1//S9Ln2f Lx7/kA6c4ONPH82Vfdi2frgndOG3eghogKKGOAMoO0Gme5viXBKof+THedTHf4YCOg44NSMW fWzygfdHgeAXgceXgCb4ddcXL9F1enQjYjBXgeiXghYofPPHYu5XeU7GgR9SgMF3gRb4WkJx akEYgD82BDvIfTjYfiFnFH7HhEXIIz2oFUiod+2XdaL3D1hof3JHddMnhSkkBFSIhaqUfz/I b3tFhSAIgzfYbml4gqoHbsyHQWsoh1C4hi/oWDUIPqoCg9nnDX4YglaobsWnXPWnh3wogmjn gGQIbwPohjF4a+vXhM2nhqbFgTiFWYtoh2Uo/mCyV4KEOIIeSIdGqGqkRnydaHkZeHtwKCGX 2IL+5oqicocq9oZbCImnmCCuGItkt4pd2HgZdl4KOIvDyCFfuIjCEIo52IuouGTPN3bs13mO WIqvyIp794ueWItJuHvJ6Ct1WIdmeICDWI3iJRxpKIageIh9ooW2+H1T0HanQxhwh3lcSH6i lY77x4vy+HHzmGP3eHnoCJD6OHj+iILUGI77qI/HhYaJGJA2B4/gyHvsSI9XQITt1YO7eIsT 2YASKYwEqYKHd5Dbd40j2ZATaVZd8jWogYsgKYicI4XSWIntaH3ZuIAGSYIseZM1dpI5aZIt +Y8/l4U/WX5KuII9/mmCBfiNDGmUgYh/8FeQH8ltPomPbPiUNDiO29iPqNJGvbeUPhOSweh9 XNmVUEmWASeERPl2RseTZVmIbImBnDiWM0iTn1eTc4mVyuiWxjd8cTmUedmRhEJ4SViRDmOD egmM7eiMVSgv7BCRE4iWfmmNhdmYhimZf5mQlvmYdMktD3mZFFmZWYlhz3aOnVkhTmmXifmI 3IiZiLeXkJmYdamNMzh+n1iVqxmZQvmWIumafYmbvQk/hyZCzZOa0ziZlBlirReTu6l0M2mT a2mb0qKcPnac2jiafKkfAKiZiAmbXpmbPiid74eIztmKDgKTUumZYpmKTFabvNmddzlc/nlI kr5Jf8XJmhDYnuyJnvQpIACIkVbpi/oZm7rpnpnJj4r5KMypieZ5mwNan7Uln/i5ngH6K7PZ nF8poURAemDZTfcJjZ8JoUFCFZNEjACKkASqimZjmiRKmtt5fIEJkdbpkXHwnBSGBG+Rocmp olg3KuUZnWQyo1SJofL3o/75oYpylh0aoSy6ciZKmyDGoCcqnkVKc8MwiSvJpDIaJV/oZFka nvlpoXN4oRz5mkHATK1ZcGXqnTGqpFdKjXw3pC/6nwwoKgZXnV6qoC3oovHJpguae8NZkmIq l3D5pHdaDyE6os8YexF3flVYpznao4eSonqKqL+nqHjJqF36/qZ7Cqhr+jB+eqhNWqEl2qeY qqlJajAUKqiTSokaR5hyiqNjGqqTs3xWKqWhtXaLWpONWqqOmm2RuoybiqWsaoquqpSwmp21 4qtXqaZ8eqmyWKmfCqWZmo/HWqtISq3zOarOKqyqWa3A2pY2KqkGyp3biqsnqqvGOq0GKKSp Kq4++qxFSawZyal96abrOKjimK2tmq/yaq27kqewl0ab2Kz6OrD8epq7upPNeLBV4qm0CqdM Gaf7yq39yjCoaqz/Wq7s17DhCqrXWqDpSqTL2qHveK+iWrBqGa8T6628Gqtmya4L667kaqm5 SqrzCqXliKZXubEv27Egi68nS5w2/muu40iyqlpbcjZmbIa0NPOrHsuhLcuyT2i037W0LcM8 Vcu0/Ci1Y+qmKUuRDaul8Pk+TeuzT+u0dhqorrmzwNdd2kU7ZLu1YXq2EGuqazuVDuq20gO3 e6u1fHumKOpbetu3g0u0fkt1YGu3tHhfdxq33Zq2Dxu1p4C4ges9hst2lmuhc+uklpO3lUu4 K9q47eq1eze5nTu2n3u5qJu5ZetinGtfb6u6PRm6QmuXiauhp8tjrlu4scu4mEu6gGu6hFO0 XJuWoiuxX7sH+6S5BtZPo9FloTe8csu6dBu5vBswpKNCWxm8NZS9hwm6vtu71uuO0XNE2vu6 W1O+3pu6/rvLvt8bLpGVRelZo/A7vcz7oI9rtvX7nLMbrRvaOoYEmgT2v6chvyG7vCUrsprK vxR7hNjLSf9HucajSosUvY4rsgsMs6MrLW6mV2kVwFnFwXXlwWY6E2UWZzzjMlyWwlkWwWDI buWUu1PhaTAMWW12wiicvCbMGDocw+qlvGFJpuH0w8xoY7UHYyTclrd7xA0Ku7tzUpknuE5M V0jMxEUMpEUWhEemvpvrxPZLo82LUu1ExVAMxEZWxWWcxS38VVyluE28WWB1xpNnxN9pnAqr xHQ8x6HlvIc1V4W1vSZUvn/lx3d7x3Zcx0l8yI5ZyPMLvOfrudhIyHg4xl+8/siKnMhgbDdq HFyRnMeI3MmW/MleHMpFELZ4HIaly8lbvMSlZcZkTMSn3Mg9/MiVDMmirMqmXMC2nMukjMqy jLu0DMySjMXTmbCjHKSx3LpufMnBLMe3bMjG3My7fMyZ/Mfqqb59lbZ2tT8F9MobhM33qM2N AUCrrLtRnMzmbJiXpFHPDEeb9EMQplWUREQQNUQUZLtWPGOO/Mvp7M6/BM9MJc/2TM9dNM+a lFMCXc2k6MvC60RDlK5RJc8PjVEOHUVV1c8oUtEL3bb6zNBCps4A7MntLFMEzM6gdNF9JEcT 7TwgDcqwTM0cvdHv9dGQBNGT1ElNddKYlNIDDUc0/n3PQGyf5zzL/LxPxFDS2etORh3SJl3U I9zSTJ3UTq3LW9bLQr3PtXdJ21TMIv1N2KTSZAVOPO3NYX21WAs0ZW3WMePROT3ENS1P+PTV 3txlW23S0jTXpUxmaT1n6aPXah1gFTXFTx3PVnVRYk3YSz3YF80/P82yCBuzKwqaM1XPho2J BB3XPXXQlH1zD4WtqxswZBvZis3GL5jYSyXYAP0VyXTaPGUXUMXY0mq8wKasbLXNaSXIugxW 4kwMt03JS6Xbtp1Yva1Pd7XbwS3MNQra7pjccfzPxNzKbYzPJ7Pcj62d0I3Gzp3GrkzO/TTd Szrb2o3Lz01krJzdPwuj/r3T3ePtYeId3ZN83NZ9hOkt25Dt3tB8xeSN3cQs3R87rvTN3OFd 3urNYOwdrP5N3Z5d38681B9c0gy+4AmO3vx94Oe93fhM4N3s4E+d4RNOqMot4fDd3Er24MMs 4v1d3YPy3SAO4Pld4lMN4fud4ihu4Cp+1AHe3iS+uJ/94TJ+4jeO3y0u3Aqu4S+eVfINN0aO 4RB+4RV+3UDO4whu4lAO3jXO4jk+4lOeqDE+3z0eHDwcHSqcw192wzkTlTP+5BSOQF7e5WIe 5mC+w2xu3l6j5mvOwjuOtgl8q7ILvvB65v27qgaLv3dOvfu75zh55FMr5feL5+/qofqLwIMO /p1RTruvyrOQS+jia8COruMczsAdSOk9q8CFnumvHaXxjehoHuqYrrai3tmHjq5aXresruiQ nuoE6+rSW+ntu77uq+sZW+Sn3uGjLuv5i8ErG+mcnsEu+OmW/uhQe+m9PrMR/upmLujO3uwH XOu8Pqx93ul7uOyBHuuqPuvWvunejetI/uzavuvr7uu2CuylrufiTuzDHrFbHtueXqzJDrTx Du1ih+zG7nbfvugyG779zuf2Pun5nusDr8Hwrul57u/mbsF/Su/hbvCNTuqNHvDTzuXVe/HC Lu/13sAAQPIlb/Inj/Ipr/Il7+4KD+oQ7/DF/vKSHsQrb/M3b/Mt/g/o4H7t2P4kA5mm+M7L +l2zDjvzsCnzAF9+GZ/pm/xbWb7zzC6uSa/0/cv0j7qlT0+pLt/t5O71/urwtO7hmGzlWx/1 R8/zUl8nzNnz5T7NZf/nKjuvycqXFuvYEt/ARC/wPU73xXv3D8/w3D56No6hRQ/2+fv3Pq/4 gY/wQaz3XA/rD698SI6xsH3rb6/1cR+06V7tln/AbI+ymG+IZGr4bJqS6F6/p6+tQ+/kD7j3 Uxr23lKlWN/4VI1YggWOJK/zcr8h/of6Huv7qy/69vTOuEw4pa+AG2nnZqj8tu74KmVCTA6t kS+bie64f2j9tT/4rI0hGU3KyB+RnEn9/l8n/tue99APQ7rf4OA//t4mnL9fc+8v/OefUdqg /ld+9qiuQEDf/vvf/7JBAPExdbn9DQBLVqtkzGxD/0FvCslwLMvpRE0WXV0xgOOHrvHcvfWe uzsaDCKYKPqQlCSLt2wmn8iob9qrLrG1a3YHhB0tlcaRKy2DttrZOcJus1XutJs+rFu9xu9K TJnfbQA54A7+XugMUwoJBRsDHWPIiiYxeMggWzDfuL7OEg/LOkM1STdL0fKI+Gj69E4VST8/ gEblao1uXxtlIcFaL2Zag4WFdNFKeR+VspKPmcc4jR2bBS+hqKuRnx2w7RidlKGkd8chrKW6 79J3sKrWTXOp/mTAy9Xrud/97rm1xWfpv8n7529fwIKF8lU6uEzTujkOEREcKHBhtIoI5ST0 1M8KqI62KGb6eLEdyWKeNMabFpJEt5REWIrM8XIhTSc2z92zaW4kk54q2UX6aXLowZx4iK6J paMZtZ1OZzJNKrHiUaY7qa7Ega1pxK1FYU0Fu8/qTKxmlqqJGXaj2rHOxEo1WXbr2bXZhGZt 6TUo2r5xv87FafdtHVkJD/P1qBcuYLcX6WohLLfhX4BsgU4s6dNxYJKRI02Omhbz5tLbTjPm 2flx1TCvYceW/TqpaFypLzfOHG43P9Z5P88WPjx2bY4ye0MDuXc58t/MfxuyjRqT/nTFui1C b6v9OXfH1p9PX4RbtW+DmpMP6r64M/jox7FTj2/auXz06+8Dds9aPLz89OfL7T8B58Gvvrj2 aw++ActT7rwCtzvQQAf5Y++7BSFMj6EIA2xQvQkZNI48ESsb8S7espPQww1BRFE/C18kTUW/ ZjzRPA5DbHG890ycC8PVHgQSxwxT7FDHHSvs8bMfXQQwx8I+HFLII6NUUEnImLxRQ2+kbJLA Kank0krvYiyRTCeJtC9NNMEME6bwYEQwSwq3vC1IL1cU0803eTxTrP6U8jNPO7vUssgndQSU RiOJAjTBQ9f8Es9FEW1RURvpvFBGRqFkEdI22ZyUyks7/tWzzOrilNRQNUFVNdM9/TuV0yUR Ic5W4l64VVfZct3VV2Ba+lVYUgslsUYfMxr21xSUXTbYZndlFlpdw5Ru2mt5vbKqWjNitttg vzVhsGpTnYrY0eAYF9x0vWV3XZTI1bam7p5SV9xwUcF3FnsTLdfYMeF1916B8yV4X31BfFRW TQ1m5g/Qumg34IEn7ldeo+jltmFz+D14Yxs6TtjfRjNGuJ2HQ+bYZJBXxk9hOeFsGR2JQ0FZ 5h9ujlnQfxmumBObP8YnZ4WCXu/lP0sumgqgfRYhZZaV1vlYWvts+mSaf8baYa2vHnVkZKuu uZIOgCUU53cRIpsYJM+mOO0T/srmcwym367bU6KPPNrcpK2exJKcIJZkjx+iCDwVjPwonG7E GddD8Xh3JllqsfE+yXGo3W48GMIxL9gVVTgXGm3NL1n787y/pjrJjf0e5PHRLd9cidczj730 QNv2HPTdh6Dd4sjBXr3vwRU6x3B9eAfd+MVtz2N5rlsv/gmIkb64oHM9G/70N5+HXXbN3+i+ 9u9jD3965slP33zRUbeeLL4pd5y2z00vX+Wx59+9fvXvlz8Movd3PPz9j37WoN7e3KcT+GWt cupbxdygRzy5GRB90ZtgEwS4PQcmT4PfwRauJBc2BmrQFwRE3vgs+LYAVlCCKqRgBDsIGwhG 54Mg/gwewOLHwRTWL4M6bCEPWUjCVfwNhj5UBRFpOLRxYK81IzSi3OzHv86RThQcBF//nsg2 KfaQimbbIhMjFrVygNEyTuwi+EzHxeZZMY1BTF4JT6i7M5avjeF52vUWuDX52a1sJrziFIcB tz70MW5SZJ/dAqmBIPgxiodUpCA3QMi1HbAelPQexiZnRj2O7yZc6+Qlr2FHJUqDjJwRo1k8 GUpQzmyVSxPlKUmZx65ZDZCzlOMmb2lLD47SGKVMHSph+UdVcnKYufwkf+74vkziUpNYbGYt j2nMYu4ymLrwZQJTyUpialOa3PQYLc2VTAUuU5fMdBovG+nNc1bzeuKs/qQso/lMR5rTmfSE 5jT1w4pf8LCe8yJnPO05z3L2E6AExSeCDhfF/aVznCIMqDoNCtF7SlSgBf1TQr/oOyz986AW rWhHP0rRGYKzNhi9nUa3xVGRurKVSGnpVbLJUmTGkX8ZEJ/qcCjPldL0obnTqU97KhiaSiKd lkSVSmWaw28qdZ0kBepAL5q4/CFuhTxbmMNqKBxpZTVb4uJqV1Hx1eIksYFgsKIwlenQk4lV hs9iKyOd9la4ckyuhUToUPU5V4a+E6nNmRW6pgbYv2ZvsHct6w9Ld827wcxMgSVspR4bqUFB cUKCI2ED0dpQ4fXil5Ft1WS1yCpRzfSwbLRs/gg3qxXgUcaxTZQspV5L1iNCcgSS9IVVGXvU 1QoWsq79LGx/K1um+lOtgNAbcEfL2sICp7VRZecpFNvcUK1quq+qbpU+lVxqOpWvxbUHNndL WdFS11XYNZBRu6nZnJIDvNJ9Smd9q918ovMV0V3udRdb3vyCNlb4NZXL3DlGeH43vPElL39x VyfxApi+0B2wYeDL3PuaUroUnnCjArzEB1+ntxLucBljWyovnjfDsezrnQ6M3BRjyrz+HTGD nzsn1HK2vfd9b40/bF/JNFjGN1RthSOc4OyuWMQLNlqJe7lhv37YwkwO8o0L7FzuCvjExWqx fv+L5Rdr2cj0QrI1/pWMYutyObQu7rKKx+zlui5UvT2jcZRBHNwil5nM/T3ymtH74/XiBc5N dnKFoQzkKp95xm7W85/7LGQ0E1m5iE5tiHFqaPYmGpuI8fB40ww5QVPZuxDGMaQz7edNuxdW +w21j6/K51FfmM6iXnWOS51lRm+00xwGtWcpveVX37rVmmY1px+t6l+/uiu8xfSV3XTcQqfa uEF2NXi5Yms5/27X9Q2zlU3NYiC7RNryrayz28xsAlfb29PWNbitp+NjZxvVuX0zuWddWIgs mdfnRTew99zsT5s7sO8I9LDzHW/iBlvfuYa3nQn97EWzm9oAT/Kgh3zqRhfG0vTm97f3/u1g iK9b1guPs6LnfOmL2zvjPY70pA+ObGOn5N+ODrjEaU3wcTu83ph5SctrbrR7a3jjZu61tj1D E5yP3GU7N3GtLV7uj5sBJ90WOMkNfnSZezrqLrd6zp8c63OrfNnuPjTWS+66pCNY3Vo3u9fB XnVlCN3pMD/72+G+dLcbWLk3bzvX4553vdv47q5led87vnfBD57hWw+5hDQydKUTnvFvV/bh Q1RxMeO98ZWP++MnbuzAKxzohk+YXeeW5/qWnXD9wbzm6Z7wsFPe8yRW5L5ALxjSA1A8p8e1 3DevdqLPnrVWiaToG8LmlCJ87HMXOe4Lf/Xd5933Zy3pdg1Z/nzW3z6B3JZ+8j+fK9Iadq8K /jnksZ/7tJP67MJ/6vPnm1lsi5/6AIfK9dlPYjVKmf7A53z4kU/06Rs//623FGjsLxZ4r3EC MN0A7+kWT/VQDwFdL72EKv26L+L27/iU7/sYMOsubwsKUAChbwPJb/IuUP+Ir/MUMFGugGy2 L7dqz+ic7O/uL/MSsD1q6wSn6qI80LhmsLFoTv/YjgVrbgDrwvweSQjJQq+C4wbdS1gwEATj jwL5z/KgMNkOsAQtcAGfcAmjMAv1TvEQkAuv0AC1MAwvbwqrkAqdcAL7zwzFcA2vrf3wzwvR 8AX9jw3pEOlgsAvJcAQPDwjrsA9T/u4NfXD54G8O/bAQu67OQC4G4QwO8c8QHRGTmJAQE5Hs 8nASH/ES2w0RbS/1GhELMfETcUsTA1HpGLEJQfEUNS4S1bAUJVEO1RAVYfHdvE8PTdEVy5AT azEWdXHmJBAQB/EVPXEXhdHafvEWadEK4zAYh3EZdWv9JJEVgREMmXEam3EWLTEZpdEZo5Ea uREXkdEXVdEY01Acu7Ecz3APRxEPi/EYzbEdz9Gr8MxZ3KquPK4V3fEex2+24tFXtmrN6nEb 8TEgc5GnRi+mXAodBTIh3dABewF9PMoW2VEhJdIeCRK6HBKkIPIaJ3IjKRKzCvKlgAkhOXIk FbGDPnKb/pLqGweSJN3RJcBo/h5SGVlyJl2yki5ypxZxJnWyI03SIg0SpkiQHHfSHGtyjG4y JReSJ4dyGotyiY7yIO/wC5eSGpuSlJ4SKEVyKkmyKocrpIAKWEBvCgJwE7WyHLkSq0DyrFLo iCZKJssyIc/yJgDQjf6IzcYyHd8SFOMSqkYql9ZyEVDKGwEyL3VxL8+vqZYqMddIerwyGwlT IQ0zdNIyAtWyhcbjplRSKR8TFSMz9CYz+p4KrIqhqoIyIjdzGTsTH2iLkD6zpiwTd16oNDXy NKkSKUFyLosIjWrQ+cbRNGlzF1PTM4dQGHDTe9ZykRLrH4XyNznTNunqM+fv/jg9EjQdkznb MTjZ0q1QkiB3KK8qsjdn0zqFETspUx81kHnAcpCIs5DucvXEkw3JsxquMiSjEhvf8xLjEwd/ kj4zczDvsxDzUx3msy6U0zf/ExMD1DAGdMdkkw8PFO3CyCn3k0Ab9EHN0jmRYUFDo0DD00I/ MUE1Zjuxsj470UP9EETpCwl5MyMd1EQzUfuMckIZNCtddDwxlANbkwnSgSxr9ERvNPhkdEMr tEeHEUXZSUXVLyeJ1Eahspc0NEJJdCWXVAuNdMp6EiPdckrxc2n2UR7DCs84tEW1NNy6oEv5 cR7pcUjHtDm7i+d0jxTXFBbJaE7xEg3FNE6lLk8f/u5N1RFPP5RMU/EPTfFO/ZQY8W1PBfUZ C/VP21RP8xHWFnVLGxVRdxBOI/UR6XRSH/UHLxVTAdXkNJNTO9UQM/VQN1UQR9VHNdVQE3UV UxVAP3VTKrBPX5UOS9VNW1UcCbVWCw5XHVUEq5NXqTRWdXBW+W9XhbUSqc5XjdVOkxU+ibUa mxUcn3VYVzVQK5VWqzUKb/VXS5LvttVaTZWu/DHdlNA9w7XorjUEw9FA6zRd1XVcv7UXpTRb 4RXqmPVURXEd77XUunVaozRUgbVfvWZdpVIbl5NPCbYNhQ1g+zNhc3Vhq0de2RVh3RVdJVbc ZFVfKZFfM7Z9KPZgrREa/j/W1yjVYZPSPzm2ZCWNVe1VTS2WZS0lWuuVXgV2XmV26op1ZWHW GnMWX721YkdWWX9W5wzWPmOWZIsWaE+WZ2nUZpcW40IWaYfWY6PWDr9uYJOWaK/25XZWa80C TGWza3VWWp32S8sV/MhWY78WZ6H0pzB2bY/WbMF2RrsSPOWWbenWbXWUx0Q2b0/OZVE2on40 bgG3aQX3bBWTLzPycBFoakt0ROFWYR0XcmVxcNuySVO2cic2X+tWSK30ZTkXcbEVcxtTcjd3 dA8RVFX2bYOKclU3cWWXb2E0dE03dlEuaP8WdBEpLAnXcHE3a0tXcRFzji7ndCM2eBsWzIBX /qD+8vWQV3SVd29ZF2IpVIjELnpvd3q5tl07dKCe16bOh0O5l2aFV2jt1ngvc3zHtnwt93x3 13UDCa5+D4N21H3L9nKJt5/+8oEOs3HxV3fbFn15V33nNzbVNoBnt3ovFnXTpzuRKIEVmIF5 cX9rSTp7sj0n+HE9l3Zz03LgaDrxdoOHd4Hjt2/36JFUWIVEGIBJeGNNmGrT93WT94URbFml d3FjsnltmHwrsfa+7HN7GIdJl4Dld4dhd4g5Dn5luIBpOIeV+IZ/GEhj7ISj2GenuDqC2IOv 2Od6FYp/14HfsYsHGIa5WET5M3XJeHljOHLTmHHfdY0luGob0m+b/liOvbiChRiFbdeC8diF vReI7diN/3iJc3d7vxMna7iQFzlYBTQefZiRoZaNzxht03SOJTmSA9l8W7eSMzmOH7aBt9Zq PxkRidiPWbR7S7l9+fVf/RhZg9eV97hjvXeVTTmL37eTjdiWR7iVOdl6EZmXa9aQgZmYRRmM hXmXabmDldmKk7mRlTSXi3mWnxmZwVOWPVmXqzmYP5CZnfmOt9maU3luh5mawzmbBXOa97WW z7mXN5mcb7aZ2/mbn5Z5kzie55meA1abe3aS89mdR1maj5mbqxmb5bme8/ifeThLQy9tkxeW cdegj/WXx1ihAZqOofmhLRqLfXmhmxei/mNXop0VntV4o8WZocFZij06nEWaWgUYk02akP35 ewfamC86pmXapnn0lBMap9G5onWVom/ap/kZoX96qM05plt6UIUakIm6nNc5o60ZpFV3qRWV pNP5qY96nO+5pEHZoq3aVbEaqLX6oPc5qMcaqZ86rNFaoNWaqNnaN+P6rX3a9Mw0WsqYlcu6 qC35rofDjFV6r9W5dq0SsDVZsGkaS7XYsPUasQU5RvMaprX6sSU0ss8asaGasJ2UsSV7ram4 sqn3sAWbsgvbskMZs/lahzOUsy8btQc7SAWUtU/btRNbkXfB9FR5tD+7tEO7sXV7sdEJSV+Z tr86jMM2RwNb/qqfmbSx6iFwm5Qxm7knd0Vzm6CXe7eNO5G1G7qVO5mlG2SsBblF27q9G7th Dzqfm51R+7vPeziRU7x9m7yFmb0ZkjqvlKdveb3NO6xc6L3RmKO7WqHpWzXRW7a9Wr+Bm7+1 s74BvLvne7/70pIZfKad+rfrGLJ7u7PhGsJX27QPPLo5HEczvLVpe8BDvLpRuZ1NPMH1t6cR /MJBu8XzG8RZfLM9PKuJe8VhXMaT28Kn4SXTO2ZL/MRr/JBtesiL/CR5fLzLWsd/3MBxHMl3 3MZHfLZd28lvG8rJOseDz69vRcvpGqeB2MttBcwrfK8JNc1RfLIZFhKF/MrbHI+4/tvHvfZF mZzNey6t3vzF8zfmGpzOW7Zz/xzN41zPB73JC72pi/uf1TzPFz2fGx1rP9yxEz2tzxzRHd3S H32eI73PJx3Q9TZwZ5zSM92tLx3PJX3gDh3VPV3VKRzOS92b4xvTU93NV524cT3XdX3Xeb3X ff3XgR3YjVD2xBRJY4/X69eDjh0yVPT3gh1JhDtgiFAnpn0xqHp0oz0Xsr2KEXPbWTrNWxQJ /fvZh+HIUrCYvH25q72dhAvdr91x153a252b0n2b6/2JayLx/Jfck9QowN2J7l3dtyvcXbCm lToH82nYmV3cEf7ZFd41Ht7fl10yAp7fLf7iMT7jNX7jFjm+4z3+40E+5EV+5Em+5E3+5Ku5 AAAAOw== --SUOF0GtieIMvvwua-- From Yann Guidon Fri Dec 1 00:35:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00418 for ; Fri, 1 Dec 2000 07:54:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:24 +0100 (MET) Received: (qmail 26094 invoked by uid 0); 30 Nov 2000 23:32:33 -0000 Received: from c3.egroups.com (208.50.99.225) by mx11.rz2.gmx.net (mx11) with SMTP; 30 Nov 2000 23:32:33 -0000 X-eGroups-Return: sentto-1101623-1694-975627109-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 30 Nov 2000 23:32:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 23:31:49 -0000 Received: (qmail 39810 invoked from network); 30 Nov 2000 23:30:49 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 30 Nov 2000 23:30:49 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 30 Nov 2000 23:30:48 -0000 Received: from f-cpu.org (nas1-183.ras.club-internet.fr [195.36.192.183]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA23125 for ; Fri, 1 Dec 2000 00:30:46 +0100 (MET) Message-ID: <3A26E45F.960B97CC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 01 Dec 2000 00:35:59 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] pipestages Content-Type: multipart/mixed; boundary="------------9C3C1F96A44F336D70A2C91F" X-UIDL: 2dfe8c77dcd3f3b72ebcd9da43662a48 Status: R X-Status: N --------------9C3C1F96A44F336D70A2C91F Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

here is another "gate" for the f-cpu generic gate library.
it has compiled OK under Simili but i have not tested
it with any simulator, so you're warned.

How to use it ? in the middle of a component. It bahaves like
a pass that can be controlled by a generic value, so
we can have several versions with different latencies and speed,
simply by modifying a number.

i have enclosed an example. This entity can be controlled
with a simple generic value.
it has compiled but it was not yet tested with a simulation.
i'll be pleased to have some feedback :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
--------------9C3C1F96A44F336D70A2C91F Content-Type: text/plain; charset=us-ascii; name="pipeline.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pipeline.vhdl" -- pipeline.vhdl -- one pipeline stage buffer -- Copyright (C) 2000 Yann GUIDON -- -- This is a configurable generic pipeline FF that is used inside -- Execution Units. It can be removed with the "generic" parameter -- or can be changed later to perform some boundary scan. -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. library IEEE; use IEEE.std_logic_1164.all; entity PIPE_STAGE is generic ( PASS : boolean := true ); port ( Ck : in std_ulogic; Din : in std_ulogic_vector; Dout : out std_ulogic_vector ); end PIPE_STAGE; architecture Arch_1 of PIPE_STAGE is begin do_pass: if PASS=true generate Dout <= Din; end generate; -- else no_pass: if PASS=false generate process (Ck) begin if (Ck'event and Ck='1') then Dout <= Din; end if; end process; end generate; end Arch_1; --------------9C3C1F96A44F336D70A2C91F Content-Type: text/plain; charset=us-ascii; name="ex_pipeline.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ex_pipeline.vhdl" -- ex_pipeline.vhdl -- example of a pipelined execution unit -- Copyright (C) 2000 Yann GUIDON -- -- This is a configurable generic pipeline FF that is used inside -- Execution Units. It can be removed with the "generic" parameter -- or can be changed later to perform some boundary scan. -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. library IEEE; use IEEE.std_logic_1164.all; library WORK; use WORK.PIPE_STAGE; entity EU_EXAMPLE is generic ( PIPESTAGES : natural := 3 -- for example :-) ); port ( Ck : in std_ulogic; Din : in std_ulogic_vector(20 downto 0); Dout : out std_ulogic_vector(20 downto 0) -- etc. ); end EU_EXAMPLE; architecture Arch_1 of EU_EXAMPLE is component PIPE_STAGE is generic ( Pass : boolean ); port ( Ck : in std_ulogic; Din : in std_ulogic_vector; Dout : out std_ulogic_vector ); end component; Signal D1,D2 : std_ulogic_vector(20 downto 0); begin -- stuff here.... stage1: PIPE_STAGE generic map(PIPESTAGES=3) port map (Ck => Ck, Din => Din, Dout => D1); -- stuff here.... stage2: PIPE_STAGE generic map(PIPESTAGES=1 or PIPESTAGES=3) port map (Ck => Ck, Din => D1, Dout => D2); -- stuff here.... stage3: PIPE_STAGE generic map(PIPESTAGES=3) port map (Ck => Ck, Din => D2, Dout => Dout); -- yet more stuff here again ... end Arch_1; --------------9C3C1F96A44F336D70A2C91F-- From Yann Guidon Fri Dec 1 01:01:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00427 for ; Fri, 1 Dec 2000 07:54:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:27 +0100 (MET) Received: (qmail 31055 invoked by uid 0); 30 Nov 2000 23:56:21 -0000 Received: from c3.egroups.com (208.50.99.225) by mx11.rz2.gmx.net (mx11) with SMTP; 30 Nov 2000 23:56:21 -0000 X-eGroups-Return: sentto-1101623-1695-975628572-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 30 Nov 2000 23:56:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 23:56:08 -0000 Received: (qmail 96167 invoked from network); 30 Nov 2000 23:56:02 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 30 Nov 2000 23:56:02 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 30 Nov 2000 23:55:57 -0000 Received: from f-cpu.org (nas1-232.aub.club-internet.fr [195.36.150.232]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA15093 for ; Fri, 1 Dec 2000 00:54:20 +0100 (MET) Message-ID: <3A26EA3F.4E9F0880@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A263B0B.63A9B395@isep.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 01 Dec 2000 01:01:03 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Simple COMA Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f84699bb54be473932d27417f06a04c2 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> http://www.sics.se/~ans/simple-coma/
> An overview of differents multiprocessor architectures. For exemple :
> http://playground.sun.com/pub/S3.mp/simple-coma/hpca-95/paper.html

i've looked at some slides and i confess that i still haven't understood
the point... we'll discuss about it soon anyway :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Yann Guidon Fri Dec 1 01:01:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00431 for ; Fri, 1 Dec 2000 07:54:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:28 +0100 (MET) Received: (qmail 30657 invoked by uid 0); 30 Nov 2000 23:56:43 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx13) with SMTP; 30 Nov 2000 23:56:43 -0000 X-eGroups-Return: sentto-1101623-1696-975628573-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 30 Nov 2000 23:56:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 30 Nov 2000 23:56:13 -0000 Received: (qmail 20886 invoked from network); 30 Nov 2000 23:55:58 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 30 Nov 2000 23:55:58 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 30 Nov 2000 23:55:57 -0000 Received: from f-cpu.org (nas1-232.aub.club-internet.fr [195.36.150.232]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA02819 for ; Fri, 1 Dec 2000 00:55:54 +0100 (MET) Message-ID: <3A26EA41.3FAD6967@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001130214054.49875@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 01 Dec 2000 01:01:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d6066d9f885a625ff74820926224063e Status: R X-Status: N hi,

Michael Riepe wrote:
> On Thu, Nov 30, 2000 at 02:49:41PM +0100, whygee@club-internet.fr wrote:
> [...]
> > i'm not sure about the 8-bit popcount.
> > schematics, please ?
> I'll include a GIF that contains two versions of an 8-bit popcount.
> The first one uses half adders only, the second one both half and
> full adders.

but a FA is twice slower than a HA. i would have more confidence in the
HA-based architecture.

> > Here, it is a bit more complex, but i remember that a
> > 64-bit popcount can use the 64th bit as Cin too.
> > there are 21 FA for the first stage, then we add
> > 2-bit numbers, then 3-bit numbers and so on until
> > it reaches the 6 bits of width.
> Right.  But don't forget SIMD...
i don't know if it's really important at our level...
the POPC unit will be used very rarely...
and a lookup table works faster for 8 bits :-)

> [...]
> > This makes me think about a trick :
> > can you add a generic component to your library ?
> > it would be a variable width pipeline stage (width
> > is determined by a generic)... it can be easily changed
> > (ie replaced by a boundary scan etc) and moved around
> > the design...
>
> You mean, like lib/reg.vhdl?  I also made a similar component that can
> be switched on and off (that is, replaced with wires if no register is
> required) by setting a boolean generic, but I didn't use it yet.

oooops, seems like our mails have crossed each other...
but the nice thing about that is that it separates cleanly all the
logic layers, and it helps tuning the architecture's latency/throughput etc...

If you could modify iadd.vhdl with the pipeline gate, or a similar technique,
it would be cool. it's better to do it now because it can force you to add and
rename some signals (better now than later).

g'nacht
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
click here
From Michael Riepe Fri Dec 1 01:48:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00440 for ; Fri, 1 Dec 2000 07:54:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:30 +0100 (MET) Received: (qmail 12237 invoked by uid 0); 1 Dec 2000 00:48:11 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx21) with SMTP; 1 Dec 2000 00:48:11 -0000 X-eGroups-Return: sentto-1101623-1697-975631683-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mw.egroups.com with NNFMP; 01 Dec 2000 00:48:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 00:48:02 -0000 Received: (qmail 74940 invoked from network); 1 Dec 2000 00:48:02 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 1 Dec 2000 00:48:02 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.85) by mta2 with SMTP; 1 Dec 2000 00:47:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01241; Fri, 1 Dec 2000 01:48:11 +0100 Message-ID: <20001201014811.25822@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001130214054.49875@thrai.stud.uni-hannover.de> <3A26EA41.3FAD6967@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A26EA41.3FAD6967@f-cpu.org>; from Yann Guidon on Fri, Dec 01, 2000 at 01:01:05AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 1 Dec 2000 01:48:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] today's idea :*) Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" X-UIDL: 7fa95826fbfb1744fa40921409f83abe Status: R X-Status: N --r5Pyd7+fXNt84Ff3 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, Dec 01, 2000 at 01:01:05AM +0100, Yann Guidon wrote:

[...]
> > I'll include a GIF that contains two versions of an 8-bit popcount.
> > The first one uses half adders only, the second one both half and
> > full adders.
>
> but a FA is twice slower than a HA. i would have more confidence in the
> HA-based architecture.

It depends.  In an FPGA, a FA can be as fast as a HA, for example.

> > Right.  But don't forget SIMD...
> i don't know if it's really important at our level...
> the POPC unit will be used very rarely...
> and a lookup table works faster for 8 bits :-)

Hmm... how fast *is* a 256-bit lookup table?  The address decoder
might be quite complex...

BTW: I also wrote a generic lookup table component with variable table
input (a static one is also possible, with the table data passed in as
a generic, but IMHO it's not really necessary).  I'll attach it, just
in case.

[pipeline register]
> > You mean, like lib/reg.vhdl?  I also made a similar component that can
> > be switched on and off (that is, replaced with wires if no register is
> > required) by setting a boolean generic, but I didn't use it yet.
>
> oooops, seems like our mails have crossed each other...
> but the nice thing about that is that it separates cleanly all the
> logic layers, and it helps tuning the architecture's latency/throughput etc...

Yep.  BTW: our ideas were very similar, the only difference is that my
register also has a reset input ;)

> If you could modify iadd.vhdl with the pipeline gate, or a similar technique,
> it would be cool. it's better to do it now because it can force you to add and
> rename some signals (better now than later).

That's the next thing I'm going to do with the adder (and the
multiplier, of course, but that's a little more effort).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
click here
--r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vlut.vhdl" -- vlut.vhdl -- variable lookup table -- Copyright (C) 2000 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id: vlut.vhdl,v 1.1 2000/11/19 03:05:29 michael Exp $ library IEEE; use IEEE.std_logic_1164.all; entity VLUT is generic ( INPUTS : natural := 4 ); port ( A : in std_ulogic_vector(INPUTS-1 downto 0); T : in std_ulogic_vector(2**INPUTS-1 downto 0); Y : out std_ulogic ); end VLUT; architecture Behave_1 of VLUT is begin process (A, T) variable i : integer := 0; begin lp : for j in A'range loop case to_X01(A(j)) is when 'X' => i := -1; exit lp; when '1' => i := i + 2**j; when '0' => null; end case; end loop lp; Y <= 'X'; if i >= 0 then Y <= T(i); end if; end process; end Behave_1; --r5Pyd7+fXNt84Ff3-- From Ben Franchuk Thu Nov 30 07:35:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00455 for ; Fri, 1 Dec 2000 07:54:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 01 Dec 2000 07:54:33 +0100 (MET) Received: (qmail 6105 invoked by uid 0); 1 Dec 2000 02:44:40 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx01) with SMTP; 1 Dec 2000 02:44:40 -0000 X-eGroups-Return: sentto-1101623-1698-975638670-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 01 Dec 2000 02:44:39 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 02:44:30 -0000 Received: (qmail 42833 invoked from network); 1 Dec 2000 02:44:29 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 1 Dec 2000 02:44:29 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 1 Dec 2000 02:44:26 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA14814 for ; Thu, 30 Nov 2000 19:34:42 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A25F54B.F30AB0BB@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <20001130214054.49875@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 30 Nov 2000 06:35:55 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9507267a175ff5e35d126066bacc22eb Status: R X-Status: N Michael Riepe wrote:
> I'll include a GIF that contains two versions of an 8-bit popcount.
> The first one uses half adders only, the second one both half and
For FPGA work the FA's and HA's used here may be slower than you think
because carry out (using fast carry logic) may need to be buffered
before feeding another logic cell. Since I have no understanding of
the 'POPCOUNT' function I can't modify the logic, but just ask if
the 3 - 4bit fast ripple carry adders could not be used instead.
BITS ABCD   EFGH
     [ADDER][ADDER]
        [ADDER]
         {result}

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
click here
From yguidon@april.org Fri Dec 1 19:22:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00336 for ; Sat, 2 Dec 2000 17:45:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:45:16 +0100 (MET) Received: (qmail 32181 invoked by uid 0); 1 Dec 2000 18:22:27 -0000 Received: from hk.egroups.com (208.50.99.220) by mx19.rz2.gmx.net (mx19) with SMTP; 1 Dec 2000 18:22:27 -0000 X-eGroups-Return: sentto-1101623-1699-975694941-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 01 Dec 2000 18:22:26 -0000 X-Sender: yguidon@april.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 18:22:21 -0000 Received: (qmail 5904 invoked from network); 1 Dec 2000 18:22:16 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 1 Dec 2000 18:22:16 -0000 Received: from unknown (HELO ef.egroups.com) (10.1.2.111) by mta1 with SMTP; 1 Dec 2000 18:22:16 -0000 X-eGroups-Return: yguidon@april.org Received: from [10.1.10.125] by ef.egroups.com with NNFMP; 01 Dec 2000 18:22:15 -0000 To: f-cpu@egroups.com Message-ID: <908q8e+i4q3@eGroups.com> In-Reply-To: <20001201014811.25822@thrai.stud.uni-hannover.de> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 192.94.38.34 From: yguidon@april.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 01 Dec 2000 18:22:06 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c092e814303a546232226a97f1263f69 Status: R X-Status: N hi,

> It depends.  In an FPGA, a FA can be as fast as a HA, for example.
in a FPGA, it wouldn't be routed the same anyway.
i am more thinking about a more-or-less
physical (full-custom@gate-level) implementation.

> BTW: I also wrote a generic lookup table component with variable
table
> input (a static one is also possible, with the table data passed in
as
> a generic, but IMHO it's not really necessary).  I'll attach it,
just
> in case.
just in case you want to synthesize a FPGA ;-)

> [pipeline register]
> > but the nice thing about that is that it separates cleanly all the
> > logic layers, and it helps tuning the architecture's
latency/throughput etc...
> Yep.  BTW: our ideas were very similar, the only difference is that
my
> register also has a reset input ;)
but you understand that in this special case, there is no need for
a reset... the pipeline and the data are flushed when an operation
is done. registers can also be hardwired so they initialize at 0
or 1 on reset.

> > If you could modify iadd.vhdl with the pipeline gate, or a similar
technique,
> > it would be cool. it's better to do it now because it can force
you to add and
> > rename some signals (better now than later).
>
> That's the next thing I'm going to do with the adder (and the
> multiplier, of course, but that's a little more effort).
yep. if you modify something, keep me informed :-)
i want to release a bundle before the 17C3...
i have a personal unfinished bundle that needs some serious
cleaning.

>  Michael "Tired" Riepe <Michael.Riepe@s...>
YG
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Fri Dec 1 19:46:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00346 for ; Sat, 2 Dec 2000 17:46:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:01 +0100 (MET) Received: (qmail 14268 invoked by uid 0); 1 Dec 2000 18:47:09 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx04) with SMTP; 1 Dec 2000 18:47:09 -0000 X-eGroups-Return: sentto-1101623-1700-975696415-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 01 Dec 2000 18:47:09 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 18:46:55 -0000 Received: (qmail 64311 invoked from network); 1 Dec 2000 18:46:38 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 1 Dec 2000 18:46:38 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 1 Dec 2000 19:47:43 -0000 Received: (from mnet@localhost) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id TAA15718; Fri, 1 Dec 2000 19:46:36 +0100 (MET) To: arma@mit.edu Cc: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 1 Dec 2000 19:46:36 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re:[f-cpu] Re: hosting for fcpu (fwd) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f199355ab5e0ee76bcce494e1f42b1b Status: R X-Status: N hi,

>These are neither usernames nor email addresses.
>It's closer, but still not quite it. :)

on top of my hat :
whygee : whygee@f-cpu.org
down : down@ici.net
i don't remember for Olivier...

>> i hope that at least 3 people will watch over f-cpu.seul.org.
>> i have enough workload with the existing sites :-)
>If you mean 'watch over to make sure cran doesn't go away', we'll
>take care of that. If you mean 'watch over to make sure you update
>it when you should', that's somebody else's problem (Graham?)

what i meant is : you're the server admin, so take care
of the security and usage of the accounts (you're the root
and have the right to cleanup things when you remark some
hypothetical abuse).
Another thing was : i have to "share the keys" with
several other people so i am not a bottlenck to the site's
evolution. Graham is overworked but in a sever situation
can make good use of my access rights. of course
we need yet someone else. Anyone on the list is volunteering ?

>> PS: can we discuss on the f-cpu mailing list instead ?
>Sure. I sent off the first message for subbing to it. We'll
>see how that goes.
welcome, then :-)

>Speaking of which, why is your mailing list still on egroups?
>That's an awful place to have it...
i know and it was already proposed.
it's for several reasons : mainly, the list owner has disappeared
and nobody can move the list to another server. without this,
we risk to loose a lot people when creating yet another new
mailing list. there are other mls but they are dedicated
to local activities : otherwise there are some distortions
between the discussions on the lists, people do crosspost
in several langages and it becomes a huge mess...
so the technical discussions happen at egroups, as well
as some other local/langage specific stuffs.

anyway, it's possible to make a new mailing list for the
developers that are hosted by seul. it would deal with file
synchro etc... because general technical discussions can't
be removed from egroups.

>--Roger
regards, YG
eGroups Sponsor
Click Here!
From graham@belegost.mit.edu Fri Dec 1 19:55:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00349 for ; Sat, 2 Dec 2000 17:46:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:02 +0100 (MET) Received: (qmail 11334 invoked by uid 0); 1 Dec 2000 18:55:36 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx24) with SMTP; 1 Dec 2000 18:55:36 -0000 X-eGroups-Return: sentto-1101623-1701-975696908-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 01 Dec 2000 18:55:36 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 18:55:08 -0000 Received: (qmail 43160 invoked from network); 1 Dec 2000 18:55:07 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 1 Dec 2000 18:55:07 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 1 Dec 2000 18:55:06 -0000 Received: (from graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA21420; Fri, 1 Dec 2000 13:55:05 -0500 Message-Id: <200012011855.NAA21420@belegost.mit.edu> To: f-cpu@egroups.com Cc: arma@belegost.mit.edu (Roger R Dingledine) In-Reply-To: from "whygee@club-internet.fr" at Dec 01, 2000 07:46:36 PM X-Mailer: ELM [version 2.5 PL0pre8] From: graham@belegost.mit.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 1 Dec 2000 13:55:05 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: hosting for fcpu (fwd) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6450dc916437d64a90037d39e601dd89 Status: R X-Status: N >
> on top of my hat :
> whygee : whygee@f-cpu.org
> down : down@ici.net
> i don't remember for Olivier...
O.JEAN@euronet.fr

Graham
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Fri Dec 1 21:16:21 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00352 for ; Sat, 2 Dec 2000 17:46:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:02 +0100 (MET) Received: (qmail 10654 invoked by uid 0); 1 Dec 2000 20:16:51 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx99) with SMTP; 1 Dec 2000 20:16:51 -0000 X-eGroups-Return: sentto-1101623-1702-975701797-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 01 Dec 2000 20:16:50 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 20:16:36 -0000 Received: (qmail 77079 invoked from network); 1 Dec 2000 20:16:24 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 1 Dec 2000 20:16:24 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 1 Dec 2000 20:16:23 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id VAA11768 for f-cpu@egroups.com; Fri, 1 Dec 2000 21:16:21 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 1 Dec 2000 21:16:21 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] rel07-2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dbe16ba58ab0c09cd6c668d3feff2cf8 Status: R X-Status: N hi,
i have put rel07-2 online
at http://www.f-cpu.de/design/rel07-2.tgz.
some stuffs were simulated with vcom/vsim.
please comment.
YG
eGroups Sponsor
Click Here!
From Michael Riepe Sat Dec 2 00:23:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00364 for ; Sat, 2 Dec 2000 17:46:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:05 +0100 (MET) Received: (qmail 25759 invoked by uid 0); 1 Dec 2000 23:23:58 -0000 Received: from cj.egroups.com (208.50.144.68) by mx12.rz2.gmx.net (mx12) with SMTP; 1 Dec 2000 23:23:58 -0000 X-eGroups-Return: sentto-1101623-1703-975713022-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 01 Dec 2000 23:23:56 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 23:23:41 -0000 Received: (qmail 51341 invoked from network); 1 Dec 2000 23:23:41 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 1 Dec 2000 23:23:41 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.87) by mta1 with SMTP; 1 Dec 2000 23:23:40 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00566; Sat, 2 Dec 2000 00:23:39 +0100 Message-ID: <20001202002339.29279@thrai.stud.uni-hannover.de> To: f-cpu@eGroups.com References: <20001201014811.25822@thrai.stud.uni-hannover.de> <908q8e+i4q3@eGroups.com> X-Mailer: Mutt 0.84e In-Reply-To: <908q8e+i4q3@eGroups.com>; from yguidon@april.org on Fri, Dec 01, 2000 at 06:22:06PM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 2 Dec 2000 00:23:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d9e255a08b33de1c1db6e6b118531587 Status: R X-Status: N On Fri, Dec 01, 2000 at 06:22:06PM -0000, yguidon@april.org wrote:

[...]
> but you understand that in this special case, there is no need for
> a reset... the pipeline and the data are flushed when an operation
> is done. registers can also be hardwired so they initialize at 0
> or 1 on reset.

I also initialize my variables properly ;)

[...]
> i have a personal unfinished bundle that needs some serious
> cleaning.

Same here...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 2 00:53:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00367 for ; Sat, 2 Dec 2000 17:46:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:05 +0100 (MET) Received: (qmail 577 invoked by uid 0); 1 Dec 2000 23:48:54 -0000 Received: from ci.egroups.com (64.211.240.235) by mx19.rz2.gmx.net (mx19) with SMTP; 1 Dec 2000 23:48:54 -0000 X-eGroups-Return: sentto-1101623-1704-975714504-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 01 Dec 2000 23:48:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@eGroups.com Received: (EGP: mail-6_3_1_2); 1 Dec 2000 23:48:23 -0000 Received: (qmail 73255 invoked from network); 1 Dec 2000 23:48:21 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 1 Dec 2000 23:48:21 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 1 Dec 2000 23:48:21 -0000 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA02800 for ; Sat, 2 Dec 2000 00:48:17 +0100 (MET) Message-ID: <3A2839FD.BE9D5F3B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@eGroups.com References: <20001201014811.25822@thrai.stud.uni-hannover.de> <908q8e+i4q3@eGroups.com> <20001202002339.29279@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 02 Dec 2000 00:53:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: today's idea :*) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e53bddc3f71f6cbf1e0f4974737df295 Status: R X-Status: N hi,

Michael Riepe wrote:
> [...]
> > but you understand that in this special case, there is no need for
> > a reset... the pipeline and the data are flushed when an operation
> > is done. registers can also be hardwired so they initialize at 0
> > or 1 on reset.
> I also initialize my variables properly ;)
ok, ok... :-)

> [...]
> > i have a personal unfinished bundle that needs some serious
> > cleaning.
> Same here...
can you publish it ?

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 2 01:53:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00370 for ; Sat, 2 Dec 2000 17:46:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:06 +0100 (MET) Received: (qmail 9755 invoked by uid 0); 2 Dec 2000 01:09:14 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx14) with SMTP; 2 Dec 2000 01:09:14 -0000 X-eGroups-Return: sentto-1101623-1705-975718100-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 02 Dec 2000 00:48:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 2 Dec 2000 00:48:20 -0000 Received: (qmail 68427 invoked from network); 2 Dec 2000 00:48:19 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 2 Dec 2000 00:48:19 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 2 Dec 2000 01:49:24 -0000 Received: from f-cpu.org (nas1-238.aub.club-internet.fr [195.36.150.238]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA17655 for ; Sat, 2 Dec 2000 01:48:16 +0100 (MET) Message-ID: <3A28480C.4EFBF4B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 02 Dec 2000 01:53:32 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-cpu-mr.tar.gz Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 89b243e864a7fed5e67886af8a9906e8 Status: R X-Status: N hi,
Michael's files are at http://www.f--cpu.de/design/f-cpu-mr.tar.gz

"
It's too big for the list, but maybe you can put it on f-cpu.*
Beware!  This is not a stable release.
"
ok.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 2 12:54:59 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00400 for ; Sat, 2 Dec 2000 17:46:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 02 Dec 2000 17:46:13 +0100 (MET) Received: (qmail 25295 invoked by uid 0); 2 Dec 2000 11:49:54 -0000 Received: from ef.egroups.com (64.211.240.229) by mx06.rz2.gmx.net (mx06) with SMTP; 2 Dec 2000 11:49:54 -0000 X-eGroups-Return: sentto-1101623-1706-975757791-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 02 Dec 2000 11:49:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 2 Dec 2000 11:49:50 -0000 Received: (qmail 59458 invoked from network); 2 Dec 2000 11:49:50 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Dec 2000 11:49:50 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 2 Dec 2000 12:50:55 -0000 Received: from f-cpu.org (nas3-54.ras.club-internet.fr [195.36.203.54]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA08971 for ; Sat, 2 Dec 2000 12:49:47 +0100 (MET) Message-ID: <3A28E313.C9F7155C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A28480C.4EFBF4B@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 02 Dec 2000 12:54:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu-mr.tar.gz + CD idea Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 536b6a0256e3774cb45861ed8aca4c34 Status: R X-Status: N ooops,

Yann Guidon wrote:
> hi,
> Michael's files are at http://www.f--cpu.de/design/f-cpu-mr.tar.gz
you will have corrected yourself : http://www.f-cpu.de/design/f-cpu-mr.tar.gz

i have had an idea : for the 17C3, i'll prepare some CDs containing a snapshot of
our working directories and a lot of goodies (VHDL, misc. souces, distros, humor etc.).
we'll probably distribute them for 1DM or 2DM at the end of the conferences.
i'll make half a dozen of copies, i count on the others to copy the copies later :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From whygee@mime.up8.edu Sun Dec 3 01:51:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00312 for ; Sun, 3 Dec 2000 17:26:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 03 Dec 2000 17:26:25 +0100 (MET) Received: (qmail 4288 invoked by uid 0); 3 Dec 2000 01:11:07 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx05) with SMTP; 3 Dec 2000 01:11:07 -0000 X-eGroups-Return: sentto-1101623-1707-975805850-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 03 Dec 2000 01:11:04 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 3 Dec 2000 01:10:49 -0000 Received: (qmail 10639 invoked from network); 3 Dec 2000 01:09:50 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 3 Dec 2000 01:09:50 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 3 Dec 2000 01:09:50 -0000 Received: from club-internet.fr (nas2-213.ras.club-internet.fr [195.36.192.213]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA17496 for ; Sun, 3 Dec 2000 02:09:47 +0100 (MET) Message-ID: <3A299925.26778E7B@club-internet.fr> X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: fr,en To: f-cpu@egroups.com From: whygee@mime.up8.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 03 Dec 2000 01:51:50 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8d2024d94aaea0283a8eb0426d8a7af4 Status: R X-Status: N hi,
here's a forward of Michael's mail:

> > now, we need a little better rop2, have a INC and ASU,
> > start the shifter. IMUL is not #0 priority but it is welcome :-)
> > we'll worry about the MAC register usage later.
>
> IMHO we should discuss the whole instruction again.  I'm not suggesting
> to drop it, but the way this instruction works bothers me.
sure.

> The MACL and MACH instructions aren't symmetric (what is MACH.64 going to
> mean, for example?), and the `widening' feature makes implementations too
> complex; we need to re-order the output bits for MAC, with respect to MUL,
> and that means that we will have even more output ports (12 instead of 8).
> If we restrict MAC to `(n bits) * (n bits) + (n bits) => (n bits)', we
> can use the same ports the MUL instruction uses, and MAC.64 won't behave
> differently on a 64-bit CPU and a wider one (which is a Bad Thing (tm)
> for upward compatibility anyway!).

by nature, MAC (and MUL) are n*n=>2n.
that's the math, and it's expected to work this way
(unless you work with C but it's not the point :oD).
so we have to find a way...

There are several options that we have to examine.

> The new multiplier can do this easily if I re-arrange the signals in the
> input stage.  It should also be possible to add another mode bit that
> allows to switch between MAC modes, but we still need additional output
> muxes (in the Xbar?) for the MAC instruction as it's currently defined.

i understand the problem (or so, i think) but the way to solve it is
very simple : please do your best at the VHDL level, and we'll
see later how this maps to the instruction set. "HW first" :
it's silly to constrain the HW. we can examine all the possible
options and combinations (except configuration bits or weird stuff
like that). there are enough free opcodes. we'll have to deeply update
the f-cpu manual anyway :-)

conclusion : please make a cool unit and we'll try not to spoil it.
don't bother too much about the instruction set, it can be changed
(at our point, at least). i think that we can reduce the MAC sizes
to 16*16, 32*32 and 64*64 (it can save some gates and ports).

i'll try to write a longer mail later...

...

during the meeting today,
Nicolas Boulay proposed to drop the 32bit mode/capability
(that means : no 32 bit version of the f-cpu).
it seems to be wise, even though it reduces the possibility
to map the core on a small fpga. he pointed out that the LEON
CPU was filling this purpose but i don't want the SPARC take
the 32 bit segment instead of us ;-) OTOH it doesn't force
us to write 32 bit versions of the units...

another proposition, for those writing VHDL code for
the f-cpu, is to "evaluate" the status of the file :
each file would have a mark, 0 means 'crap', 3 means
'some stuff inside', 5 stands for 'it starts to work a bit',
7 'it seems to work ok', 9 : 'i can't do better', 10 :
'unbelievable quality' :-) this helps keep track of
the status of the project. when every file is ='10',
it means that we're ready for synthesis and version 1.0 :-)

YG
eGroups Sponsor
Click Here!
From Michael Riepe Sun Dec 3 02:49:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00318 for ; Sun, 3 Dec 2000 17:26:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 03 Dec 2000 17:26:27 +0100 (MET) Received: (qmail 16527 invoked by uid 0); 3 Dec 2000 01:49:39 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx07) with SMTP; 3 Dec 2000 01:49:39 -0000 X-eGroups-Return: sentto-1101623-1708-975808175-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 03 Dec 2000 01:49:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 3 Dec 2000 01:49:34 -0000 Received: (qmail 14992 invoked from network); 3 Dec 2000 01:49:34 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 3 Dec 2000 01:49:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.110) by mta1 with SMTP; 3 Dec 2000 01:49:31 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01824; Sun, 3 Dec 2000 02:49:28 +0100 Message-ID: <20001203024928.33135@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A299925.26778E7B@club-internet.fr> X-Mailer: Mutt 0.84e In-Reply-To: <3A299925.26778E7B@club-internet.fr>; from whygee@mime.up8.edu on Sun, Dec 03, 2000 at 01:51:50AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 3 Dec 2000 02:49:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4ce2fcb67ebc095e352c9d8ede380618 Status: R X-Status: N On Sun, Dec 03, 2000 at 01:51:50AM +0100, whygee@mime.up8.edu wrote:
[...]
> > The MACL and MACH instructions aren't symmetric (what is MACH.64 going to
> > mean, for example?), and the `widening' feature makes implementations too
> > complex; we need to re-order the output bits for MAC, with respect to MUL,
> > and that means that we will have even more output ports (12 instead of 8).
> > If we restrict MAC to `(n bits) * (n bits) + (n bits) => (n bits)', we
> > can use the same ports the MUL instruction uses, and MAC.64 won't behave
> > differently on a 64-bit CPU and a wider one (which is a Bad Thing (tm)
> > for upward compatibility anyway!).
>
> by nature, MAC (and MUL) are n*n=>2n.
> that's the math, and it's expected to work this way
> (unless you work with C but it's not the point :oD).
> so we have to find a way...

In most high-level languages, it's n*n=>n.
I remember only one exception (forth).

> There are several options that we have to examine.
>
> > The new multiplier can do this easily if I re-arrange the signals in the
> > input stage.  It should also be possible to add another mode bit that
> > allows to switch between MAC modes, but we still need additional output
> > muxes (in the Xbar?) for the MAC instruction as it's currently defined.
>
> i understand the problem (or so, i think) but the way to solve it is
> very simple : please do your best at the VHDL level, and we'll
> see later how this maps to the instruction set. "HW first" :
> it's silly to constrain the HW. we can examine all the possible
> options and combinations (except configuration bits or weird stuff
> like that). there are enough free opcodes. we'll have to deeply update
> the f-cpu manual anyway :-)

Yep.

As I said, the hardware can probably do both versions (with only
minimal additional effort).  I think this means I will include both
and we decide later which one(s) to use.

> conclusion : please make a cool unit and we'll try not to spoil it.
> don't bother too much about the instruction set, it can be changed
> (at our point, at least). i think that we can reduce the MAC sizes
> to 16*16, 32*32 and 64*64 (it can save some gates and ports).

I don't bother about the instruction set but about the size and
complexity of the Xbar...

[...]
> Nicolas Boulay proposed to drop the 32bit mode/capability
> (that means : no 32 bit version of the f-cpu).

I second that, somehow.

> it seems to be wise, even though it reduces the possibility
> to map the core on a small fpga. he pointed out that the LEON
> CPU was filling this purpose but i don't want the SPARC take
> the 32 bit segment instead of us ;-) OTOH it doesn't force
> us to write 32 bit versions of the units...

We can still do that later.  In fact, stripping down the design to 32
bit will IMHO be easier than supporting both widths in a single design.
Some modules (most notably the EUs, except rop2) scale pretty badly.

> another proposition, for those writing VHDL code for
> the f-cpu, is to "evaluate" the status of the file :
> each file would have a mark, 0 means 'crap', 3 means
> 'some stuff inside', 5 stands for 'it starts to work a bit',
> 7 'it seems to work ok', 9 : 'i can't do better', 10 :
> 'unbelievable quality' :-) this helps keep track of
> the status of the project. when every file is ='10',
> it means that we're ready for synthesis and version 1.0 :-)

Which quality do you consider the files we already have?
Think careful before you answer ;)

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Ben Franchuk Sun Dec 3 01:50:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00321 for ; Sun, 3 Dec 2000 17:26:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 03 Dec 2000 17:26:28 +0100 (MET) Received: (qmail 30050 invoked by uid 0); 3 Dec 2000 01:56:56 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx13) with SMTP; 3 Dec 2000 01:56:56 -0000 X-eGroups-Return: sentto-1101623-1709-975808609-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 03 Dec 2000 01:56:55 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 3 Dec 2000 01:56:48 -0000 Received: (qmail 2021 invoked from network); 3 Dec 2000 01:56:48 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 Dec 2000 01:56:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 3 Dec 2000 01:56:47 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA23159 for ; Sat, 2 Dec 2000 18:46:45 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A2998E2.D9EF2AEF@jetnet.ab.ca> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A299925.26778E7B@club-internet.fr> <20001203024928.33135@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 03 Dec 2000 00:50:42 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0cd12b676a74bf00d12ed0055822ad05 Status: R X-Status: N Michael Riepe wrote:
> In most high-level languages, it's n*n=>n.
> I remember only one exception (forth).

Forth had one nice feature '*/' (star,slash?).  This was nice for scaling
as it was a*b->2n 2n/c ->n. Forth is a nice language but hell on
a Cache.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Yann Guidon Mon Dec 4 02:43:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00390 for ; Mon, 4 Dec 2000 15:35:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 04 Dec 2000 15:35:39 +0100 (MET) Received: (qmail 8346 invoked by uid 0); 4 Dec 2000 01:39:55 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 4 Dec 2000 01:39:55 -0000 X-eGroups-Return: sentto-1101623-1710-975893981-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 04 Dec 2000 01:39:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 4 Dec 2000 01:39:39 -0000 Received: (qmail 33993 invoked from network); 4 Dec 2000 01:38:33 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 4 Dec 2000 01:38:33 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta2 with SMTP; 4 Dec 2000 01:38:33 -0000 Received: from f-cpu.org (nas1-138.ras.club-internet.fr [195.36.192.138]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26209 for ; Mon, 4 Dec 2000 02:38:30 +0100 (MET) Message-ID: <3A2AF6D3.A4024183@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 04 Dec 2000 02:43:47 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: Call for Papers for 1. Oekonux conference]] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ed9c10080aad1d9efe8c268b0edc4789 Status: R X-Status: N hello,
Mathias is still alive, he has received this invitation
through the fcpu.tux.org site. I believe that i can participate,
and the other people are welcome. If Sven, Graham, Lee, Erik
or others could also come, it would be cool !

-------- Original Message --------
Subject: Call for Papers for 1. Oekonux conference
Date: Sat, 25 Nov 2000 16:31:55 +0100
From: Stefan Merten <smerten@dialup.nacamar.de>

Hi,

we find your Free CPU project very interesting.

Perhaps someone from your community is interested in the conference. I
add the Call for Papers to it. Unfortunately we only have a German
text. Though the conference language is German, we'll accept English
talks and workshops. We would appreciate if you could report about
your activities.

              &= nbsp;             &n= bsp;       Mit Freien Gr=FC=DFen

              &= nbsp;             &n= bsp;       Stefan

---- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- = 8< --- 8< --- 8<---
Call for Papers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1. Oekonux-Konfernz

28./29. April 2001

Dortmund

Projekt Oekonux [http://www.oekonux.de]<= /a>

Das Projekt Oekonux
- -------------------

Das Projekt Oekonux arbeitet seit Juli '99 an der Frage, ob und
inwieweit die Prinzipien Freier Software-Entwicklung -
Verwertungsfreiheit, individuelle Selbstentfaltung, kollektive
Selbstorganisation und globale Vernetzung - als Grundlage f=FCr eine
neue, Freie Gesellschaft dienen k=F6nnen.

Ausgehend von dem fundamental neuen Modell von Produktion, das in der
Freien Software tagt=E4glich und h=F6chst erfolgreich vorgemacht wird,
denken wir dar=FCber nach, ob dieses Modell auf andere Bereiche von
Produktion =FCbertragen werden kann bzw. wo es bereits =FCbertragen wird. So sind auf dem Sektor der Informationsg=FCter vor allem bei der Musik
(Stichworte: MP3 [http://www.mp3eu.net/= ], Napster
[http://www.napster.com/], Gnutel= la [http://gnutella.wego.com/])=
Entwicklungen erkennbar, die denen in der Freien Software in
mancherlei Hinsicht =E4hneln. Auch auf materielle Produkte orientierte
Projekte wie OSCar [http://www= .theoscarproject.org/] oder Freedom-CPU
[http://f-cpu.tux.org/] machen von s= ich reden.

Im Projekt werden aber auch deutlich ambitioniertere Fragen
diskutiert. So wird best=E4ndig dar=FCber nachgedacht, ob und unter
welchen Voraussetzungen vor allem industrielle Produktion nach den
Prinzipien der Freien Software organisiert werden kann.

Auf dieser Grundlage werden utopische Gedanken diskutiert, die bis hin
zu m=F6glichen Organisationsformen einer solchen, GPL-Gesellschaft
genannten Formation gehen, in der perspektivisch die
Tauschgesellschaft und damit Arbeit und Geld abgeschafft ist und die
Notwendigkeiten als Nebenprodukt der individuellen und kollektiven
Selbstentfaltung aller erledigt werden. Freie Software ist dann die
herangereifte Keimform, die eine emanzipative =DCberwindung der heute
dominierenden Gesellschaftsform auf dem erreichten Stand der Technik
wieder als M=F6glichkeit aufscheinen l=E4=DFt.

Untermauert werden die Diskussionen im Projekt von einer genauen
Beobachtung der aktuellen Entwicklungen bei der Freien Software und in
anderen Bereichen, die eine =DCbertragung derer Prinzipien versuchen.
Insbesondere werden die neueren Entwicklungen im Verh=E4ltnis
kommerzieller Unternehmen uns staatlicher Stellen zu Freier Software
untersucht.

Die Konferenz
- -------------

In den vergangenen Monaten wurden mehr und mehr Kontakte zu anderen
Organisationen und Einzelpersonen gekn=FCpft. Einige im obigen Sinne
interessante Projekte werden beobachtend begleitet. Es stellt sich
heraus, da=DF Menschen aus ganz unterschiedlichen Zusammenh=E4ngen
beginnen, =FCber gleiche oder =E4hnliche Fragen nachzudenken wie sie im
Projekt Oekonux im Mittelpunkt stehen.

Die Konferenzbeitr=E4ge k=F6nnen aus einem weiten Spektrum von Zug=E4ngen kommen, sollten jedoch ihren inhaltlichen Bezug zu den oben genannten
Prinzipien Freier Software verdeutlichen.

Beitr=E4ge aus folgenden Bereichen sind sehr erw=FCnscht:

Freie Software

     Erfahrungen aus Projekten, Erfolgsgeschichten, abe= r auch
     Konflikte, Widerspr=FCche (z.B. Geldverdienen vs. = Selbstentfaltung,
     Lohnarbeit vs. Freies Tun etc.)

=DCbertragung der Prinzipien Freier Software

     Pr=E4sentation von Projekten oder auch nur Gedanke= n, die die
     Prinzipien Freier Software-Entwicklung auf andere = Bereiche des
     menschlichen Lebens =FCbertragen wollen

Technologieentwicklung

     Beispiele offener und kooperativer Technikentwickl= ung; wie sieht
     herrschaftsfreie und nachhaltige Technologie aus u= nd wie kann sie
     entwickelt werden

Alternativ- oder Anti-=D6konomie

     Theoretische Modelle der =DCberwindung von Tausch,= Arbeit und Geld,
     praktische Erfahrungen in Projekten, Widerspr=FCch= e von Theorie und
     Praxis

Wissenschaft

     Wissenschaftlich orientierte Untersuchungen =FCber= die Umbr=FCche in
     der Arbeitswelt mit der Perspektive auf eine =DCbe= rwindung der
     Arbeitsgesellschaft

Politik

     =DCberlegungen aus dem Sektor politischer Organisa= tionen Freie
     Software und deren Prinzipien betreffend

Kultur

     Freie Musik und Freie Formate, Erfahrungen und Pro= jekte, neue
     Entwicklungen in verschiedenen Kulturbereichen

Neue Menschen

     Die neue Rolle der Subjektivit=E4t, anders Handeln= in Freien
     Projekten, Selbstorganisation und Selbstentfaltung= , theoretische
     Reflexionen und praktische Erfahrungen

Die geplante Konferenz soll die M=F6glichkeit bieten, die Gedanken, die
an verschiedenen Stellen unabh=E4ngig voneinander entstanden sind, zu
b=FCndeln, gemeinsam neu zu diskutieren und f=FCr alle fruchtbar zu
machen. Neben einem Kennenlernen soll auf Vortr=E4gen und in Workshops
der jeweils aktuelle Stand der Diskussion vorgestellt werden.

ReferentInnen gesucht
- ---------------------

Interessierte, die einen Vortrag halten oder einen Workshop anbieten
m=F6chten, reichen eine kurze Skizze des Vorhabens beim Projekt Oekonux
[mailto:projekt@oekonux.de] ein.

Abgabeschlu=DF f=FCr Vortrags- oder Workshopskizzen ist der

6. Januar 2001

Entscheidung =FCber die ausgew=E4hlten Beitr=E4ge bis zum 22. Januar 2001.<= BR>
Die Konferenzsprache ist Deutsch.
eGroups Sponsor=
3D"Click
From Yann Guidon Mon Dec 4 02:43:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00393 for ; Mon, 4 Dec 2000 15:35:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 04 Dec 2000 15:35:41 +0100 (MET) Received: (qmail 6581 invoked by uid 0); 4 Dec 2000 01:40:01 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx18) with SMTP; 4 Dec 2000 01:40:01 -0000 X-eGroups-Return: sentto-1101623-1711-975893989-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 04 Dec 2000 01:40:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 4 Dec 2000 01:39:49 -0000 Received: (qmail 33812 invoked from network); 4 Dec 2000 01:38:30 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 4 Dec 2000 01:38:30 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 4 Dec 2000 01:38:30 -0000 Received: from f-cpu.org (nas1-138.ras.club-internet.fr [195.36.192.138]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26359 for ; Mon, 4 Dec 2000 02:38:26 +0100 (MET) Message-ID: <3A2AF6D0.FC012B23@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A299925.26778E7B@club-internet.fr> <20001203024928.33135@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 04 Dec 2000 02:43:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a8a6d08d5d605180e8a3f55c5bd92efb Status: R X-Status: N hi !

Michael Riepe wrote:
> > by nature, MAC (and MUL) are n*n=>2n.
> > that's the math, and it's expected to work this way
> > (unless you work with C but it's not the point :oD).
> > so we have to find a way...
> In most high-level languages, it's n*n=>n.
> I remember only one exception (forth).

nothing keeps you from doing :

long int i,j;
long long int k;
k=i*j;

particularly, in the branches where dynamics is crucial
(audio and video processing, integer 3D transforms etc)
the range matters.
Similarly, almost every CPU gives a n*n=>2n result.
except the CDC6600 and the PPC that "can" give the low-part only.
(in CDC, you have to run 2 instructions : mul-hi and mul-lo if
you want both results).

in HLL, it's "if it can do more, it can do less" so they
don't care if they discard the high part of the result.
the y think that the user is not able to think about or
(or doesn't want to know, shich is suicidal). why is FORTH
so intelligent, in you opinion ? :-)

> > it's silly to constrain the HW. we can examine all the possible
> > options and combinations (except configuration bits or weird stuff
> > like that). there are enough free opcodes. we'll have to deeply update
> > the f-cpu manual anyway :-)
> Yep.
>
> As I said, the hardware can probably do both versions (with only
> minimal additional effort).  I think this means I will include both
> and we decide later which one(s) to use.
'ight.

> > conclusion : please make a cool unit and we'll try not to spoil it.
> > don't bother too much about the instruction set, it can be changed
> > (at our point, at least). i think that we can reduce the MAC sizes
> > to 16*16, 32*32 and 64*64 (it can save some gates and ports).
> I don't bother about the instruction set but about the size and
> complexity of the Xbar...
we'll find a compromise soon... i'm sure that there are some ways to solve
this problem !

> [...]
> > Nicolas Boulay proposed to drop the 32bit mode/capability
> > (that means : no 32 bit version of the f-cpu).
> I second that, somehow.
and, what are your arguments ? :-)

> > it seems to be wise, even though it reduces the possibility
> > to map the core on a small fpga. he pointed out that the LEON
> > CPU was filling this purpose but i don't want the SPARC take
> > the 32 bit segment instead of us ;-) OTOH it doesn't force
> > us to write 32 bit versions of the units...
> We can still do that later.
yup. or someone else can, too.

>  In fact, stripping down the design to 32
> bit will IMHO be easier than supporting both widths in a single design.
> Some modules (most notably the EUs, except rop2) scale pretty badly.
maybe i didn't understand correctly, but there is no plan
to make a single chip that supports both 64 and 32 bit "modes"
(as in the x86 world). the idea was to have different chip
versions, so it could be scaled down, and it would still have
binary compatibility.

we started with a 64-bit version, and rewriting the execution
units for a 32-b version is not a big problem (except that we
don't have time for this ...).
I am more worried by the possibility to extend the SIMD chunks
above 64 bits, and the possibility to have a "scatter/gather"
instruction.

> > another proposition, for those writing VHDL code for
> > the f-cpu, is to "evaluate" the status of the file :
> > each file would have a mark, 0 means 'crap', 3 means
> > 'some stuff inside', 5 stands for 'it starts to work a bit',
> > 7 'it seems to work ok', 9 : 'i can't do better', 10 :
> > 'unbelievable quality' :-) this helps keep track of
> > the status of the project. when every file is ='10',
> > it means that we're ready for synthesis and version 1.0 :-)
>
> Which quality do you consider the files we already have?
> Think careful before you answer ;)
well, it's not complex. it ranges from 2 to 8 in my own distro.
your files are very good but i don't understand them well,
it would be cool if you had written a little doc, just so the
architecture and fundamentals of your units were quickly understood.

otherwise, the real problem is the mixture of different files,
different qualities, authors and status : some are 95% finished
and can be mapped/synthesised, others are only a half-first attempt.
the "mark" system is an easy way to sort the files, so we can
concentrate on the files that need to be worked on. This way,
we can release a bundle with "good" only files, not including
the ones that were created some hours ago...
Of course, it's highly subjective, but so is the notion
of "quality" too :-D

> Ciao,
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Colin Marquardt Mon Dec 4 05:31:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00405 for ; Mon, 4 Dec 2000 15:35:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 04 Dec 2000 15:35:45 +0100 (MET) Received: (qmail 4663 invoked by uid 0); 4 Dec 2000 04:31:35 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 4 Dec 2000 04:31:35 -0000 X-eGroups-Return: sentto-1101623-1712-975904273-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 04 Dec 2000 04:31:34 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 4 Dec 2000 04:31:12 -0000 Received: (qmail 33961 invoked from network); 4 Dec 2000 04:30:37 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 4 Dec 2000 04:30:37 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 4 Dec 2000 04:30:36 -0000 Received: from morphin.marquardt-home.de (d104.nas21.sonic.net [209.204.136.104]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA15780 for ; Mon, 4 Dec 2000 05:30:36 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 142nI7-0000Cv-00 for ; Sun, 03 Dec 2000 20:31:51 -0800 To: f-cpu@egroups.com References: <3.0.6.32.20001125010447.008243b0@mail.airmail.net> <3A1FDE9B.FF38EE06@f-cpu.org> <20001126063101.53116@thrai.stud.uni-hannover.de> <3A214275.37FC939A@f-cpu.org> <20001126213238.63320@thrai.stud.uni-hannover.de> X-Now-Playing: Entombed's Clandestine - Crawl In-Reply-To: Colin Marquardt's message of "27 Nov 2000 21:09:56 -0800" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 58 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 03 Dec 2000 20:31:51 -0800 Reply-To: f-cpu@egroups.com Subject: Re: Testability (was: Re: [f-cpu] size of F/G chips) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee4ed52e6833b3d5c2812e52b75e53b3 Status: R X-Status: N Colin Marquardt <colin@marquardt-home.de> writes:

> Michael Riepe <michael@stud.uni-hannover.de> writes:
>
> > IMHO, a reasonable BIST/POST should be a minimal test that verifies
> > that the IF/ID unit, the caches, the register bank(s), all external
> > (bus) interfaces and all data paths inside the CPU work correctly.

> There is not that much online info about testing, here are my links:
[...]

Some more info:

>From the ESNUG-List, see www.deepchip.com:

| From: Ken Butler <kenb@ti.com>
|
| John,
|
| I noticed Morgan Monks' post about cheap-but-good ATPG.  I don't have a web
| site to tell him to look, but there are a number of universities over the
| years that have developed ATPG tools that they will give out freely.
| Probably the one that shows up the most frequently in research papers is
| HITEC from the University of Illinois.
|
| HITEC formed the basis for what became the Sunrise tools, portions of which
| are as we speak being ported into Synopsys TetraMAX.  HITEC's claim to fame
| was sequential ATPG, which may or may not be what he wants.
|
| I believe that Dong Ha at Virginia Tech (?) had another tool called, I
| believe, ATLANTA.  That might be worth a look.
|
| The problem with most tools like these might possibly be an inability to
| read whatever netlist format he's using and/or not being able to handle
| complex design structures like tristate buses or other non-FF and non-
| combinational gate type stuff.  Nothing ventured, nothing gained I guess.
|
|     - Ken Butler
|       Texas Instruments                          Dallas, TX
|
|          ----    ----    ----    ----    ----    ----   ----
|
| From: Mike Kondrat <mikek@fluence.com>
|
| Hi John,
|
| In your ESNUG 359, Morgan Monks asked about low cost ATPG tools.  I know I
| am a marketing weenie but I wanted to let your reader know that our ATPG
| tools are low cost compared to the big boys.  His application would be a
| good fit for our TDX product.
|
|     - Mike Kondrat
|       Fluence Technology                         Beaverton, OR

This might also be a good resource: http://janick.bergeron.com/guild

Cheers,
  Colin
eGroups Sponsor
Click Here!
From Michael Riepe Mon Dec 4 20:05:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00399 for ; Tue, 5 Dec 2000 23:46:25 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 05 Dec 2000 23:46:25 +0100 (MET) Received: (qmail 27691 invoked by uid 0); 4 Dec 2000 22:59:47 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx99) with SMTP; 4 Dec 2000 22:59:47 -0000 X-eGroups-Return: sentto-1101623-1713-975970762-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hi.egroups.com with NNFMP; 04 Dec 2000 22:59:46 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_2); 4 Dec 2000 22:59:21 -0000 Received: (qmail 96933 invoked from network); 4 Dec 2000 22:58:34 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 4 Dec 2000 22:58:34 -0000 Received: from unknown (HELO studserv.stud.uni-hannover.de) (130.75.176.2) by mta3 with SMTP; 4 Dec 2000 23:59:38 -0000 Received: from tribble.stud.uni-hannover.de (a063.home.uni-hannover.de [130.75.232.63]) by studserv.stud.uni-hannover.de (8.11.1/8.11.1/MX/check_local4.1) with ESMTP id eB4Mw7a24125 for ; Mon, 4 Dec 2000 23:58:07 +0100 (MET) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00875; Mon, 4 Dec 2000 20:05:53 +0100 Message-ID: <20001204200553.00673@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A299925.26778E7B@club-internet.fr> <20001203024928.33135@thrai.stud.uni-hannover.de> <3A2AF6D0.FC012B23@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A2AF6D0.FC012B23@f-cpu.org>; from Yann Guidon on Mon, Dec 04, 2000 at 02:43:44AM +0100 X-eGroups-From: Michael Riepe From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 4 Dec 2000 20:05:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b86fd0bc30b8d8708fac9defb2d94c4 Status: R X-Status: N On Mon, Dec 04, 2000 at 02:43:44AM +0100, Yann Guidon wrote:
[...]
> > In most high-level languages, it's n*n=>n.
> > I remember only one exception (forth).
>
> nothing keeps you from doing :
>
> long int i,j;
> long long int k;
> k=i*j;

That will calculate a long result and sign-extend it to long long.
The correct way to do this is

      k = (long long)i * (long long)j;

i.e. first convert the operands to the desired size.

> particularly, in the branches where dynamics is crucial
> (audio and video processing, integer 3D transforms etc)
> the range matters.

Programmers should use the appropriate range, then.

I agree that it's wise to use more bits for temporary results in order
to avoid overshoot/clipping, but there are at least two ways to do this.

[...]
> > > Nicolas Boulay proposed to drop the 32bit mode/capability
> > > (that means : no 32 bit version of the f-cpu).
> > I second that, somehow.
> and, what are your arguments ? :-)

See below ;)

> > > it seems to be wise, even though it reduces the possibility
> > > to map the core on a small fpga. he pointed out that the LEON
> > > CPU was filling this purpose but i don't want the SPARC take
> > > the 32 bit segment instead of us ;-) OTOH it doesn't force
> > > us to write 32 bit versions of the units...
> > We can still do that later.
> yup. or someone else can, too.

Even better :)  Since the F-CPU is `Free Hardware', everybody can do it.

> >  In fact, stripping down the design to 32
> > bit will IMHO be easier than supporting both widths in a single design.
> > Some modules (most notably the EUs, except rop2) scale pretty badly.
> maybe i didn't understand correctly, but there is no plan
> to make a single chip that supports both 64 and 32 bit "modes"
> (as in the x86 world). the idea was to have different chip
> versions, so it could be scaled down, and it would still have
> binary compatibility.

Wait a minute, please... do you want the 32-bit chip to have 64-bit
registers and perform 64-bit operations just like `the real one' does?
Or will it have 32-bit registers and be limited to 32-bit ops?  If the
former is true, I wonder what the difference is; the latter will
result in a `crippled' version of the F-CPU that will not be fully
compatible (but may be useful for embedded applications etc., like
the LEON).

> we started with a 64-bit version, and rewriting the execution
> units for a 32-b version is not a big problem (except that we
> don't have time for this ...).
> I am more worried by the possibility to extend the SIMD chunks
> above 64 bits, and the possibility to have a "scatter/gather"
> instruction.

Bigger chunks are not a problem for ASU and IMU if a) there is
enough space and b) the latency may increase for wider results.

The big problem is that we may not be able to make *generic* EUs that
can be scaled up and down by simply changing MAXSIZE/UMAX -- and if
we *are* able to do so, the resulting VHDL code may look extremely
ugly.  I'd rather use a wrapper unit that selects from a pool of
differently-sized components.

> > > another proposition, for those writing VHDL code for
> > > the f-cpu, is to "evaluate" the status of the file :
> > > each file would have a mark, 0 means 'crap', 3 means
> > > 'some stuff inside', 5 stands for 'it starts to work a bit',
> > > 7 'it seems to work ok', 9 : 'i can't do better', 10 :
> > > 'unbelievable quality' :-) this helps keep track of
> > > the status of the project. when every file is ='10',
> > > it means that we're ready for synthesis and version 1.0 :-)
> >
> > Which quality do you consider the files we already have?
> > Think careful before you answer ;)
> well, it's not complex. it ranges from 2 to 8 in my own distro.

Very realistic rating, IMHO.

> your files are very good but i don't understand them well,
> it would be cool if you had written a little doc, just so the
> architecture and fundamentals of your units were quickly understood.

Coding is so much more interesting *sigh*...

What kind of documentation would be appropriate for the iadd and imul64
units?  Schematics / block diagram plus some text that describes how
the pieces fit together?

> otherwise, the real problem is the mixture of different files,
> different qualities, authors and status : some are 95% finished
> and can be mapped/synthesised, others are only a half-first attempt.

I usually try not to publish something that hasn't reached level 6 or 7,
at least.  This doesn't conform to the basic rule of `bazaar-style'
development (publish early, publish often), but I don't like that
rule anyway.

The other thing I don't like is the kind of teamwork the bazaar model
implies -- everybody may work on everything.  Every team member should
be responsible for his/her own subset of the project, with little or no
overlap between subsets, and clearly defined interfaces between them.
That's the main reason why I stopped dealing with the cache and started
working on the EUs instead -- to separate my `playground' from Yann's.
When the time has come, we'll all come back and play together.  Of
course, comments and suggestions are always welcome ("your sandcastle
looks nice, but why don't you put towers at the corners?").

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From JEAN Olivier Tue Dec 5 09:29:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00453 for ; Tue, 5 Dec 2000 23:46:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 05 Dec 2000 23:46:38 +0100 (MET) Received: (qmail 30540 invoked by uid 0); 5 Dec 2000 08:30:28 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx16) with SMTP; 5 Dec 2000 08:30:28 -0000 X-eGroups-Return: sentto-1101623-1714-976005022-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 05 Dec 2000 08:30:26 -0000 X-Sender: O.JEAN@euronext.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Dec 2000 08:30:21 -0000 Received: (qmail 82816 invoked from network); 5 Dec 2000 08:30:21 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 5 Dec 2000 08:30:21 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta1 with SMTP; 5 Dec 2000 08:30:20 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XY8C8D5F; Tue, 5 Dec 2000 09:27:43 +0100 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Dec 2000 09:30:19 +0100 Message-ID: <098A4E5B420CD3118F690008C75DD5DD04D368A1@NTS40.sbf.bourseparis.com> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 5 Dec 2000 09:29:52 +0100 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Re: hosting for fcpu (fwd) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ef1e0697c2743cc1b2187764bef08bda Status: R X-Status: N Hi evevrybody.

> on top of my hat :
> whygee : whygee@f-cpu.org
> down : down@ici.net
> i don't remember for Olivier...
O.JEAN@euronet.fr

> There is a pb about my email. My email is O.JEAN@EURONEXT.FR
 
  Bye.
     
         Olivier
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Tue Dec 5 13:47:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00471 for ; Tue, 5 Dec 2000 23:46:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 05 Dec 2000 23:46:42 +0100 (MET) Received: (qmail 385 invoked by uid 0); 5 Dec 2000 12:47:40 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx15) with SMTP; 5 Dec 2000 12:47:40 -0000 X-eGroups-Return: sentto-1101623-1715-976020447-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 05 Dec 2000 12:47:39 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Dec 2000 12:47:26 -0000 Received: (qmail 3797 invoked from network); 5 Dec 2000 12:47:25 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 5 Dec 2000 12:47:25 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 5 Dec 2000 13:48:30 -0000 Received: (from mnet@localhost) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id NAA24794 for f-cpu@egroups.com; Tue, 5 Dec 2000 13:47:23 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 5 Dec 2000 13:47:23 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 891445ff23fdb61abcfe177faf5bdb1f Status: R X-Status: N hi !

>> > In most high-level languages, it's n*n=>n.
>> > I remember only one exception (forth).
>> nothing keeps you from doing :
>> long int i,j;
>> long long int k;
>> k=i*j;
>That will calculate a long result and sign-extend it
>to long long. The correct way to do this is
>      k = (long long)i * (long long)j;
>i.e. first convert the operands to the desired size.

now, do you understand why i dislike HLLs ?
it's anti-arithmetic-common-sense.

>> particularly, in the branches where dynamics is crucial
>> (audio and video processing, integer 3D transforms etc)
>> the range matters.
>Programmers should use the appropriate range, then.
the "should" probably means something...

>I agree that it's wise to use more bits for temporary results in order
>to avoid overshoot/clipping, but there are at least two ways to do this.

the easiest and simplest, the best.

>> > > it seems to be wise, even though it reduces the possibility
>> > > to map the core on a small fpga. he pointed out that the LEON
>> > > CPU was filling this purpose but i don't want the SPARC take
>> > > the 32 bit segment instead of us ;-) OTOH it doesn't force
>> > > us to write 32 bit versions of the units...
>> > We can still do that later.
>> yup. or someone else can, too.
>Even better :)  Since the F-CPU is `Free Hardware', everybody can do it.
that's what i meant...


>Wait a minute, please... do you want the 32-bit chip to have 64-bit
>registers and perform 64-bit operations just like `the real one' does?
>Or will it have 32-bit registers and be limited to 32-bit ops?
32-bit regs.

> If the
>former is true, I wonder what the difference is; the latter will
>result in a `crippled' version of the F-CPU that will not be fully
>compatible (but may be useful for embedded applications etc., like
>the LEON).
that's what i meant : a crippled version, but that would still
be able to run normal f-cpu binaries (with a slightly recompiled
kernel, so the tables etc are resized, like any version)

>> we started with a 64-bit version, and rewriting the execution
>> units for a 32-b version is not a big problem (except that we
>> don't have time for this ...).
>> I am more worried by the possibility to extend the SIMD chunks
>> above 64 bits, and the possibility to have a "scatter/gather"
>> instruction.
>Bigger chunks are not a problem for ASU and IMU if a) there is
>enough space and b) the latency may increase for wider results.
sure, but i wonder how it's managed from the programming point
of view... i should reread the manual...

>The big problem is that we may not be able to make *generic* EUs that
>can be scaled up and down by simply changing MAXSIZE/UMAX -- and if
>we *are* able to do so, the resulting VHDL code may look extremely
>ugly.  I'd rather use a wrapper unit that selects from a pool of
>differently-sized components.
i also prefer this last solution, and it works in practice.

>> your files are very good but i don't understand them well,
>> it would be cool if you had written a little doc, just so the
>> architecture and fundamentals of your units were quickly understood.
>Coding is so much more interesting *sigh*...
yup, but at this point, a code you write now can last
during decades, so we have to prepare the future...

>What kind of documentation would be appropriate for the iadd and imul64
>units?  Schematics / block diagram plus some text that describes how
>the pieces fit together?
genau :-)

>> otherwise, the real problem is the mixture of different files,
>> different qualities, authors and status : some are 95% finished
>> and can be mapped/synthesised, others are only a half-first attempt.
>
>I usually try not to publish something that hasn't reached level 6 or 7,
>at least.  This doesn't conform to the basic rule of `bazaar-style'
>development (publish early, publish often), but I don't like that
>rule anyway.
>
>The other thing I don't like is the kind of teamwork the bazaar model
>implies -- everybody may work on everything.  Every team member should
>be responsible for his/her own subset of the project, with little or no
>overlap between subsets, and clearly defined interfaces between them.
>That's the main reason why I stopped dealing with the cache and started
>working on the EUs instead -- to separate my `playground' from Yann's.
>When the time has come, we'll all come back and play together.  Of
>course, comments and suggestions are always welcome ("your sandcastle
>looks nice, but why don't you put towers at the corners?").

i agree :-)

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
YG
eGroups Sponsor
Click Here!
From f-cpu@seul.org Tue Dec 5 21:34:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00501 for ; Tue, 5 Dec 2000 23:46:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 05 Dec 2000 23:46:56 +0100 (MET) Received: (qmail 25004 invoked by uid 0); 5 Dec 2000 20:34:38 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx04) with SMTP; 5 Dec 2000 20:34:38 -0000 X-eGroups-Return: sentto-1101623-1716-976048454-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 05 Dec 2000 20:34:33 -0000 X-Sender: f-cpu@cran.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Dec 2000 20:34:13 -0000 Received: (qmail 785 invoked from network); 5 Dec 2000 20:34:12 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 5 Dec 2000 20:34:12 -0000 Received: from unknown (HELO cran.mit.edu) (18.244.0.188) by mta2 with SMTP; 5 Dec 2000 20:34:10 -0000 Received: (from f-cpu@localhost) by cran.mit.edu (8.9.3/8.9.3) id PAA19552 for f-cpu@egroups.com; Tue, 5 Dec 2000 15:34:06 -0500 Message-Id: <200012052034.PAA19552@cran.mit.edu> To: f-cpu@egroups.com From: f-cpu@seul.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 5 Dec 2000 15:34:06 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4a1fe5b70d6c0e3593e3c39dabb7ac2d Status: R X-Status: N Hello,
the f-cpu site at seul.org has opened !
.
eGroups Sponsor
Click Here!
From Michael Riepe Tue Dec 5 19:06:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00298 for ; Wed, 6 Dec 2000 17:37:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 06 Dec 2000 17:37:33 +0100 (MET) Received: (qmail 22894 invoked by uid 0); 5 Dec 2000 22:56:48 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx07) with SMTP; 5 Dec 2000 22:56:48 -0000 X-eGroups-Return: sentto-1101623-1717-976056987-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 05 Dec 2000 22:56:37 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Dec 2000 22:56:27 -0000 Received: (qmail 57534 invoked from network); 5 Dec 2000 22:56:18 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Dec 2000 22:56:18 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.235) by mta1 with SMTP; 5 Dec 2000 22:56:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01279; Tue, 5 Dec 2000 19:06:47 +0100 Message-ID: <20001205190646.21788@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Tue, Dec 05, 2000 at 01:47:23PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 5 Dec 2000 19:06:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 41c3782b2708aaa5ff007c2409ab2f2a Status: R X-Status: N On Tue, Dec 05, 2000 at 01:47:23PM +0100, whygee@club-internet.fr wrote:

[...`widening' mul/mac operation...]

> now, do you understand why i dislike HLLs ?
> it's anti-arithmetic-common-sense.

`common sense' is relative.  Most people (including most so-called
programmers) don't know how things work below a certain level of
abstraction.  They tend to have a mathematical point of view wrt numbers
and operators -- numbers can have arbitrary sizes, and operations never
overflow, just like integer and rational numbers in LISP.  Only few
blessed individuals know what's *really* going on inside a computer.

[...32-bit F-CPU...]
> that's what i meant : a crippled version, but that would still
> be able to run normal f-cpu binaries (with a slightly recompiled
> kernel, so the tables etc are resized, like any version)

And 64-bit operations will be emulated in software?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann Guidon Thu Dec 7 00:12:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA16100 for ; Thu, 7 Dec 2000 03:29:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Dec 2000 03:29:10 +0100 (MET) Received: (qmail 32154 invoked by uid 0); 6 Dec 2000 23:10:48 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx18) with SMTP; 6 Dec 2000 23:10:48 -0000 X-eGroups-Return: sentto-1101623-1718-976144144-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 06 Dec 2000 23:10:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 6 Dec 2000 23:09:03 -0000 Received: (qmail 79014 invoked from network); 6 Dec 2000 23:09:01 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 6 Dec 2000 23:09:01 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 6 Dec 2000 23:07:43 -0000 Received: from f-cpu.org (nas4-131.aub.club-internet.fr [195.36.145.131]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA23192 for ; Thu, 7 Dec 2000 00:07:37 +0100 (MET) Message-ID: <3A2EC7F4.5A4854CF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001205190646.21788@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 07 Dec 2000 00:12:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0c54418895b3d32e55cb3eb352119920 Status: R X-Status: N hello,

Michael Riepe wrote:
> On Tue, Dec 05, 2000 at 01:47:23PM +0100, whygee@club-internet.fr wrote:
> [...`widening' mul/mac operation...]
>
> > now, do you understand why i dislike HLLs ?
> > it's anti-arithmetic-common-sense.
> `common sense' is relative.  Most people (including most so-called
> programmers) don't know how things work below a certain level of
> abstraction.  They tend to have a mathematical point of view wrt numbers
> and operators -- numbers can have arbitrary sizes, and operations never
> overflow, just like integer and rational numbers in LISP.  Only few
> blessed individuals know what's *really* going on inside a computer.

if you program in C or Fortran or whatever usual langage, you are warned that
a variable type has a certain range. and a whole lot of people deal with that...

> [...32-bit F-CPU...]
> > that's what i meant : a crippled version, but that would still
> > be able to run normal f-cpu binaries (with a slightly recompiled
> > kernel, so the tables etc are resized, like any version)
>
> And 64-bit operations will be emulated in software?
???

if you don't require 64+ bit variables, an application will work without
recompilation... it will trap of course if you ask an unsupported width :
it's the same as if you ask for a 128-bit int on a 64-bit version.
now, what you do in the trap is your business only :-P

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Michael Riepe Thu Dec 7 01:15:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA16106 for ; Thu, 7 Dec 2000 03:29:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Dec 2000 03:29:12 +0100 (MET) Received: (qmail 21169 invoked by uid 0); 7 Dec 2000 00:15:28 -0000 Received: from ei.egroups.com (64.211.240.237) by mx12.rz2.gmx.net (mx12) with SMTP; 7 Dec 2000 00:15:28 -0000 X-eGroups-Return: sentto-1101623-1719-976148120-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 07 Dec 2000 00:15:27 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Dec 2000 00:15:19 -0000 Received: (qmail 44227 invoked from network); 7 Dec 2000 00:15:19 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 Dec 2000 00:15:19 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.44) by mta3 with SMTP; 7 Dec 2000 01:16:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00743; Thu, 7 Dec 2000 01:15:09 +0100 Message-ID: <20001207011508.59785@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001205190646.21788@thrai.stud.uni-hannover.de> <3A2EC7F4.5A4854CF@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A2EC7F4.5A4854CF@f-cpu.org>; from Yann Guidon on Thu, Dec 07, 2000 at 12:12:52AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 7 Dec 2000 01:15:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] MAC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40cf79c0831a6ea0c008985dfd808398 Status: R X-Status: N On Thu, Dec 07, 2000 at 12:12:52AM +0100, Yann Guidon wrote:

[...32-bit F-CPU...]
> if you don't require 64+ bit variables, an application will work without
> recompilation... it will trap of course if you ask an unsupported width :
> it's the same as if you ask for a 128-bit int on a 64-bit version.
> now, what you do in the trap is your business only :-P

Ok, that's what I wanted to know... you can catch the exception and
emulate the instruction in software, if necessary.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 7 13:30:13 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00337 for ; Thu, 7 Dec 2000 22:58:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 07 Dec 2000 22:58:57 +0100 (MET) Received: (qmail 32424 invoked by uid 0); 7 Dec 2000 12:30:30 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 7 Dec 2000 12:30:30 -0000 X-eGroups-Return: sentto-1101623-1720-976192217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 07 Dec 2000 12:30:23 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Dec 2000 12:30:16 -0000 Received: (qmail 42960 invoked from network); 7 Dec 2000 12:30:16 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 7 Dec 2000 12:30:16 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 7 Dec 2000 12:30:15 -0000 Received: (from mnet@localhost) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id NAA27993; Thu, 7 Dec 2000 13:30:13 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 7 Dec 2000 13:30:13 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] french trip @ 17C3/Berlin Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8a849867777fa39d32de01caee83860a Status: R X-Status: N Hello,
we have dates+hours for the french trip in Berlin,
for the 17C3 :

arrival :
dec. 26th, flight AF2034, Berlin Tegel, 15h.

cedric, nico et Jeff go away on dec. 30, Tegel @ 16h25,
flight AF/2035

me and Paul:
Jan 2nd, 16h25, Tegel, flight AF/2035

we have not yet baught the tickets themseves
but are going to do it this week end.


I know that there are some people in/around Berlin,
please join us during the meeting !

YG
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Fri Dec 8 12:04:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00367 for ; Sat, 9 Dec 2000 16:10:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:10:17 +0100 (MET) Received: (qmail 27122 invoked by uid 0); 8 Dec 2000 11:05:57 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx05) with SMTP; 8 Dec 2000 11:05:57 -0000 X-eGroups-Return: sentto-1101623-1721-976273477-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 08 Dec 2000 11:04:47 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Dec 2000 11:04:36 -0000 Received: (qmail 96602 invoked from network); 8 Dec 2000 11:04:35 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 Dec 2000 11:04:35 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 8 Dec 2000 11:04:34 -0000 Received: (from mnet@localhost) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id MAA05959 for f-cpu@egroups.com; Fri, 8 Dec 2000 12:04:30 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 8 Dec 2000 12:04:30 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7aa942e53212765944ba85f9a29826a8 Status: R X-Status: N plus on est de trolls...

>> Je penses que dantes =E0 raison, plus on gardera de choses en soft= , plus
>> les choses iront vite. Il est plus facile de coder que de s'embarq= uer
>> dans des circuits gargantuesques qui finissent toujours mal.
>> Mais, de toute fa=E7on, la philosophie du F-Cpu ( et du RISC en g= =E9n=E9ral)
>> n'est-elle pas de mettre le maximum de choses en soft ??
>tout a fait d'accord, en plus la communaute du libre fait d'abord du so= ft,
>donc il faut maximiser ses forces. En plus une partie du projet F-CPU e= st
>de faire un proc "le plus cool possible", donc il faut laisse= r la liberte
>a chacun d'implementer l'algorithme qu'il veut par la suite.

et c'est la dessus que j'arrive :
ma philo pour le FC0 a ete tres simple (et j'espere qu'elle
le restera). c'est : laisser faire au HW ce qu'il sait faire de
mieux, et idem pour le soft.

ca veut dire : si on peut rajouter un opcode simplement
en ajoutant une porte logique (pas trop pres du chemin critique)
alors on peut gagner un cycle ou plus dans une boucle.
Par contre, s'il faut rajouter une unite complexe pour ne faire
qu'une chose, c'est hors de question.
exemple : l'unite popcount. elle sert a la base pour compter
les bits a un dans un mot. c'est pas beaucoup utilise dans
les programmes courants et ne justifie pas d'efforts
d'implementation. par contre, je me suis apercu recemment
que c'etait proche d'une unite de ECC/SEC. l'unite
devient plus interessante.

Les unites d'execution du FC0 et les instructions sont classees
par type d'operation.
-ROP2 change la valeur des bits sans (trop) bouger leur place
-SHL : bouge la place des bits (bitrev, shift, rotate etc)
-ASU : addition/soustraction (pas de mystere sauf que c'est
critique donc optimise a mort)
-IMU : idem que ASU : optimise a mort
-IDU : pas tant utilise que ca, donc latence plus longue
-INC : sert a faire plein de trucs en plus de inc/dec :
  abs, findfirst, findlast, max/min/sort et plus...

quant au reste : pour les adresses on a une TLB, si on calcule
une adresse qui s'y trouve pas, on trappe. c'est tout.
La complexite au niveau hard ne sert pas, sauf pour des operations
arithmetiques assez courantes, d'ou l'interet de ASU et IMUL.
Des qu'on rend le controle complexe, sous pretexte de
simplifier le soft, on perd en evolutivite et en temps
de developpement. Le FC0 est finalement assz simple, non ? :-)

YG
eGroups Sponsor=
3D"Click
From Nicolas Boulay Sat Dec 9 00:15:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00632 for ; Sat, 9 Dec 2000 16:11:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:20 +0100 (MET) Received: (qmail 4379 invoked by uid 0); 8 Dec 2000 23:11:24 -0000 Received: from mx13.rz2.gmx.net (HELO mu.egroups.com) (10.1.72.113) by mxi1.gmx.net (mxi1) with SMTP; 8 Dec 2000 23:11:24 -0000 X-eGroups-Return: sentto-1101623-1722-976317046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mu.egroups.com with NNFMP; 08 Dec 2000 23:11:00 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Dec 2000 23:10:45 -0000 Received: (qmail 85710 invoked from network); 8 Dec 2000 23:10:45 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 8 Dec 2000 23:10:45 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 8 Dec 2000 23:10:43 -0000 Received: from ifrance.com (nas15-179.vlt.club-internet.fr [195.36.165.179]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA06428 for ; Sat, 9 Dec 2000 00:10:38 +0100 (MET) Message-ID: <3A316B80.C4B7F7AD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 09 Dec 2000 00:15:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f0530487117a8fc70243b9e8bda75629 Status: R X-Status: N Coucou,

whygee@club-internet.fr a =E9crit :
>
> plus on est de trolls...
>

Aaaaaaaaaaaaaaaah

> >> Je penses que dantes =E0 raison, plus on gardera de choses en= soft, plus
> >> les choses iront vite. Il est plus facile de coder que de s'e= mbarquer
> >> dans des circuits gargantuesques qui finissent toujours mal.<= BR> > >> Mais, de toute fa=E7on, la philosophie du F-Cpu ( et du RISC = en g=E9n=E9ral)
> >> n'est-elle pas de mettre le maximum de choses en soft ??

Non absolument pas ! La philosophie est de mettre ce qui est uniquement
utile dans le hard (apr=E8s des =E9tudes fait sur le code g=E9n=E9r=E9 par = des
compilo).

> >tout a fait d'accord, en plus la communaute du libre fait d'abord = du soft,
> >donc il faut maximiser ses forces. En plus une partie du projet F-= CPU est
> >de faire un proc "le plus cool possible", donc il faut l= aisser la liberte
> >a chacun d'implementer l'algorithme qu'il veut par la suite.
>

Le plus simple =E0 programmer est pas mal aussi. Regarder la PSX2 certains<= BR> la boudent car elle est trop complexe =E0 programmer !

> et c'est la dessus que j'arrive :
> ma philo pour le FC0 a ete tres simple (et j'espere qu'elle
> le restera). c'est : laisser faire au HW ce qu'il sait faire de
> mieux, et idem pour le soft.
>

Facile =E0 dire ! Pour trouver les limites faudraient de s=E9rieuses etude<= BR> sur des compilo qui n'existe pas trop (qui g=E8re le SIMD)

> ca veut dire : si on peut rajouter un opcode simplement
> en ajoutant une porte logique (pas trop pres du chemin critique)
> alors on peut gagner un cycle ou plus dans une boucle.
> Par contre, s'il faut rajouter une unite complexe pour ne faire
> qu'une chose, c'est hors de question.
> exemple : l'unite popcount. elle sert a la base pour compter
> les bits a un dans un mot. c'est pas beaucoup utilise dans
> les programmes courants et ne justifie pas d'efforts
> d'implementation. par contre, je me suis apercu recemment
> que c'etait proche d'une unite de ECC/SEC. l'unite
> devient plus interessante.
>
> Les unites d'execution du FC0 et les instructions sont classees
> par type d'operation.
> -ROP2 change la valeur des bits sans (trop) bouger leur place
> -SHL : bouge la place des bits (bitrev, shift, rotate etc)
> -ASU : addition/soustraction (pas de mystere sauf que c'est
> critique donc optimise a mort)
> -IMU : idem que ASU : optimise a mort
> -IDU : pas tant utilise que ca, donc latence plus longue
> -INC : sert a faire plein de trucs en plus de inc/dec :
>   abs, findfirst, findlast, max/min/sort et plus...
>
> quant au reste : pour les adresses on a une TLB, si on calcule
> une adresse qui s'y trouve pas, on trappe. c'est tout.
> La complexite au niveau hard ne sert pas, sauf pour des operations
> arithmetiques assez courantes, d'ou l'interet de ASU et IMUL.
> Des qu'on rend le controle complexe, sous pretexte de
> simplifier le soft, on perd en evolutivite et en temps
> de developpement. Le FC0 est finalement assz simple, non ? :-)
>

Il ne faut pas non plus que le fcpu soit aussi compliqu=E9 =E0 programmer qu'un DSP.

> YG
>
n
eGroups Sponsor=
3D"Click
From Yann Guidon Sat Dec 9 01:04:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00644 for ; Sat, 9 Dec 2000 16:11:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:23 +0100 (MET) Received: (qmail 30630 invoked by uid 0); 8 Dec 2000 23:59:58 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx15) with SMTP; 8 Dec 2000 23:59:58 -0000 X-eGroups-Return: sentto-1101623-1723-976319962-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 08 Dec 2000 23:59:55 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Dec 2000 23:59:15 -0000 Received: (qmail 497 invoked from network); 8 Dec 2000 23:59:10 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Dec 2000 23:59:10 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 8 Dec 2000 23:59:08 -0000 Received: from f-cpu.org (nas3-93.aub.club-internet.fr [195.36.145.93]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA22798 for ; Sat, 9 Dec 2000 00:59:03 +0100 (MET) Message-ID: <3A31770B.7762871D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 09 Dec 2000 01:04:27 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: F-CPU workshop] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 36870fbda190b8d14046f5cd7958d27c Status: R X-Status: N hi,

this is a little announcement for the 17C3 conference.
it will be split so each part will not collide with the other.

sven wrote:
> > > > - we can prepare one (or more, if you really want ;-D)
> > > > workshop about the f-cpu project, the architecture,
> > > > the organisation etc.
> > what do people think about a split conference ?
>     You name it, we organize it. Please pass me a short list of questions
>     that'll be answered during that workshop; so the others can figure out
>     as well.
>
>     Looks like Herbert Schmidt will be at the congress as well. He'd also
>     like to talk about fpgas and tools for half an hour; so you lads like
>     to include him in your plans?
>
>     Best regards,
>     Sven

In fact, it is a reminder and a call for help about the organisation
of the meeting/conference/workshop.
We have to prepare a distro on CD (that will find its way through
the ftp servers present in the hackcenter) as well a slideshows
(html is enough). The timing will be a big problem...
If you have questions, suggestions etc, please tell us !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 9 01:04:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00653 for ; Sat, 9 Dec 2000 16:11:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:26 +0100 (MET) Received: (qmail 26002 invoked by uid 0); 9 Dec 2000 00:17:28 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx10) with SMTP; 9 Dec 2000 00:17:28 -0000 X-eGroups-Return: sentto-1101623-1724-976319968-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 08 Dec 2000 23:59:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Dec 2000 23:59:28 -0000 Received: (qmail 20768 invoked from network); 8 Dec 2000 23:59:28 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Dec 2000 23:59:28 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 8 Dec 2000 23:59:21 -0000 Received: from f-cpu.org (nas3-93.aub.club-internet.fr [195.36.145.93]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA11592 for ; Sat, 9 Dec 2000 00:59:13 +0100 (MET) Message-ID: <3A317716.7161AEA5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 09 Dec 2000 01:04:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 477d06f968d863f2afe6df74205bd2c7 Status: R X-Status: N ooops !

whygee@club-internet.fr wrote:
>
> plus on est de trolls...
>

<snip>

i have sent the message to the wrong list.

we needed to make the discussion more global anyway.

maybe we'll translate, or simply go on in english ?

@+
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Michael Riepe Sat Dec 9 01:12:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00656 for ; Sat, 9 Dec 2000 16:11:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:26 +0100 (MET) Received: (qmail 18107 invoked by uid 0); 9 Dec 2000 00:25:10 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx05) with SMTP; 9 Dec 2000 00:25:10 -0000 X-eGroups-Return: sentto-1101623-1725-976320778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 09 Dec 2000 00:13:06 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Dec 2000 00:12:57 -0000 Received: (qmail 39946 invoked from network); 9 Dec 2000 00:12:57 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 9 Dec 2000 00:12:57 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.113) by mta1 with SMTP; 9 Dec 2000 00:12:55 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02441; Sat, 9 Dec 2000 01:12:45 +0100 Message-ID: <20001209011245.11877@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A317716.7161AEA5@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A317716.7161AEA5@f-cpu.org>; from Yann Guidon on Sat, Dec 09, 2000 at 01:04:38AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 9 Dec 2000 01:12:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d8f563626f02ae3508cdcebe67503697 Status: R X-Status: N On Sat, Dec 09, 2000 at 01:04:38AM +0100, Yann Guidon wrote:

[something about trolls(?)]
> i have sent the message to the wrong list.
>
> we needed to make the discussion more global anyway.

Yes, *please*!

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 9 01:36:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00659 for ; Sat, 9 Dec 2000 16:11:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:27 +0100 (MET) Received: (qmail 14040 invoked by uid 0); 9 Dec 2000 00:37:27 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx15) with SMTP; 9 Dec 2000 00:37:27 -0000 X-eGroups-Return: sentto-1101623-1726-976321859-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mw.egroups.com with NNFMP; 09 Dec 2000 00:31:05 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Dec 2000 00:30:58 -0000 Received: (qmail 4569 invoked from network); 9 Dec 2000 00:30:58 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 9 Dec 2000 00:30:58 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 9 Dec 2000 01:32:02 -0000 Received: from f-cpu.org (nas3-59.ras.club-internet.fr [195.36.203.59]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA09205 for ; Sat, 9 Dec 2000 01:30:51 +0100 (MET) Message-ID: <3A317E80.EA4E4005@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 09 Dec 2000 01:36:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 93301018cd4960da3d4bfa625d87da3c Status: R X-Status: N re-coucou,

hey we're on the english list here...
so i'll answer in english ;-)

Nicolas Boulay wrote:
> > >> Je penses que dantes =E0 raison, plus on gardera de chos= es en soft, plus
> > >> les choses iront vite. Il est plus facile de coder que d= e s'embarquer
> > >> dans des circuits gargantuesques qui finissent toujours = mal.
> > >> Mais, de toute fa=E7on, la philosophie du F-Cpu ( et du = RISC en g=E9n=E9ral)
> > >> n'est-elle pas de mettre le maximum de choses en soft ??=
>
> Non absolument pas ! La philosophie est de mettre ce qui est uniquemen= t
> utile dans le hard (apr=E8s des =E9tudes fait sur le code g=E9n=E9r=E9= par des
> compilo).

this affirmation is made difficult because there is no compiler (see your o= wn
comment below).

it is a real error to create a compiler on top of a CPU and vice versa.
they should match and correspond to each other, they have to be designed together, so as to reach the same goal : run SW faster and better.

analysing a compiler output (sorry i repeat what i said hundreds of times on this list) is very irrevelant. you can analyse a special case, like the<= BR> efficiency of a compiler to generate the fastest code for a certain kind of algorithm. But otherwise, what you analyse is often a "static"= code,
it analyses a specific code, often written with oldfashioned styles that don't match the CPU etc...

forget about that. make a good CPU, not an academic chip.

> > >tout a fait d'accord, en plus la communaute du libre fait d'a= bord du soft,
> > >donc il faut maximiser ses forces. En plus une partie du proj= et F-CPU est
> > >de faire un proc "le plus cool possible", donc il f= aut laisser la liberte
> > >a chacun d'implementer l'algorithme qu'il veut par la suite.<= BR> > Le plus simple =E0 programmer est pas mal aussi. Regarder la PSX2 cert= ains
> la boudent car elle est trop complexe =E0 programmer !

well, OTOH most of the companies i've seen (during job interviews) are
aiming at PS2 and Xbox. heh.

> > et c'est la dessus que j'arrive :
> > ma philo pour le FC0 a ete tres simple (et j'espere qu'elle
> > le restera). c'est : laisser faire au HW ce qu'il sait faire de > > mieux, et idem pour le soft.
> Facile =E0 dire ! Pour trouver les limites faudraient de s=E9rieuses e= tude
> sur des compilo qui n'existe pas trop (qui g=E8re le SIMD)

so, the "old way" (20 y old) of analysing code is not adapted. we have designed a CPU from scratch, but there are good recipes
and bad ones. f-cpu will not execute much C code (except for compatibility<= BR> reasons). what matters is the ease to map algorithms in the CPU.

> Il ne faut pas non plus que le fcpu soit aussi compliqu=E9 =E0 program= mer
> qu'un DSP.

do you think i'm a beginner ? :-P
of course not, it will not ressemble a TMS320C4x :-)

OTOH you'll need a good background on ALPHA, RISC and
superscalar / superpipeline programming.

> > YG
> n
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From Steve Van der Hoeven Sat Dec 9 14:44:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00722 for ; Sat, 9 Dec 2000 16:11:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 09 Dec 2000 16:11:42 +0100 (MET) Received: (qmail 18829 invoked by uid 0); 9 Dec 2000 11:38:30 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx23) with SMTP; 9 Dec 2000 11:38:30 -0000 X-eGroups-Return: sentto-1101623-1728-976361905-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mr.egroups.com with NNFMP; 09 Dec 2000 11:38:29 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Dec 2000 11:38:24 -0000 Received: (qmail 19446 invoked from network); 9 Dec 2000 11:38:23 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 9 Dec 2000 11:38:23 -0000 Received: from unknown (HELO andira.wanadoo.fr) (193.252.19.152) by mta1 with SMTP; 9 Dec 2000 11:38:23 -0000 Received: from essi.fr (193.253.219.8) by andira.wanadoo.fr; 9 Dec 2000 12:38:22 +0100 Sender: root@pop.gmx.net Message-ID: <3A323727.9EAF5D72@essi.fr> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 09 Dec 2000 14:44:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d8b5c4537091a5bb2bb50e3b13e982c6 Status: R X-Status: N Marco Al wrote:

> From: "Yann Guidon" <whygee@f-cpu.org>
>
> > f-cpu will not execute much C code
>
> Who will use it then?
>
> Wasn't it supposed to be a "UNIX processor"?
>
> Marco

Java processor?... Let's stop this war at the begining.

We are at the edge of Big change of minds in the software industry.
They all want portable and secure languages. The facts: .net, java, intel's
VM....

It looks like the no more want core dumps....

I know only for the Java JVM, it's base on a virtual stack processor.  A
Son of Forth.

All this is very high level, a resources hungry. I don't agree with it, but
I'm not one of them

We can't also forget the legacy of C code.

And we cannot forget lisp, scheme, haskell , erlang and ml. Yes, functional
language can be compiled.
But they are only popular in research and eduction. Even if they are much
better than most of the other languages.
   Java is illegimated of C++ and lisp....

For the operating systems.... There are plenty of free OS.

There is no war to leed just to try to make the best decision for the
furtur.

-We can include high level assembly functions to make them run faster...
but a more complex processor
-Make a risk processor, and let's hope someone will write a correct JVM or
better a JIT
-and we have also the option of code morphing like the cursoe
-Be different and smart and find another way

Steve
eGroups Sponsor
Click Here!
From Michael Riepe Sat Dec 9 15:47:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02940 for ; Sun, 10 Dec 2000 00:44:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 00:44:11 +0100 (MET) Received: (qmail 3443 invoked by uid 0); 9 Dec 2000 22:42:23 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx08) with SMTP; 9 Dec 2000 22:42:23 -0000 X-eGroups-Return: sentto-1101623-1729-976401738-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 09 Dec 2000 22:42:22 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Dec 2000 22:42:17 -0000 Received: (qmail 53391 invoked from network); 9 Dec 2000 22:42:17 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 9 Dec 2000 22:42:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.89) by mta3 with SMTP; 9 Dec 2000 23:43:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00689; Sat, 9 Dec 2000 15:47:58 +0100 Message-ID: <20001209154758.49422@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> X-Mailer: Mutt 0.84e In-Reply-To: <3A323727.9EAF5D72@essi.fr>; from Steve Van der Hoeven on Sat, Dec 09, 2000 at 02:44:07PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 9 Dec 2000 15:47:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 95251d6c71a8330d3c6a964d05798f77 Status: R X-Status: N On Sat, Dec 09, 2000 at 02:44:07PM +0100, Steve Van der Hoeven wrote:
[...]
> Java processor?... Let's stop this war at the begining.

Yep.  The F-CPU is going to be a general processor (that can be
programmed in all existing languages).  There may of course be
languages that take care of its special features and create more
effective machine code... like Fortran 77 ;)

> We are at the edge of Big change of minds in the software industry. > They all want portable and secure languages. The facts: .net, java, in= tel's
> VM....

There ain't no such thing as a `secure' language.  Programmers can
make really bad mistakes in *all* languages (and even worse mistakes in
Fortran and C).

> It looks like the no more want core dumps....
>
> I know only for the Java JVM, it's base on a virtual stack processor.&= nbsp; A
> Son of Forth.

Let's call it a bastard of Forth and P-code Pascal ;)

[switch]

IMHO, the future of programming will look totally different.  Function= al
and object-oriented languages are only a minor step.  Future programmi= ng
environments will probably take concepts and ideas as inputs and transfer them to machine code -- or maybe reconfigurable hardware -- directly.

You won't have to specify how to e.g. sort numbers -- just tell the
computer that you want it to sort them, how to sort them, and what
to do with the result.  The PE will choose an appropriate number
representation and sorting algorithm from its database and put them
together automagically.

You won't have to learn programming languages or type statements, either (unless you want to, of course).  In the beginning, there will probabl= y
be a graphical user interface, and speech recognition =E0 la USS Enterprise=
later ("Computer? What's the nature of the universe?").

Most of the basics are already there.  Lisp (which is several decades<= BR> old) implements a lot of them; some have been re-invented in the 70s and 80s when OO languages became popular (and once again in the 90s, in Java and -- finally -- Db, erm, C#).  There have also been attempts to buil= d
graphical programming environments, and there is at least one company
that claims to have a working GUI-to-reconfigurable-hardware translator
(http://www.starbridgesyste= ms.com/), although the statements on their
web site are at least a little blurry... judge yourself.

[switch back]

This may be a very interesting topic for at least some of us (including
myself), but our primary goal is not the future of programming (or
computing per se) but the design and implementation of a free CPU.
To make this CPU usable, we need some supporting tools -- an assembler,
a (C) compiler and a linker.  They don't need to support all nifty
features of the F-CPU; if they can be used to compile and run an OS and
applications, they will be sufficient.  We (or some of us, or somebody=
else) can do the rest later.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D"Click
From Jeff Davies Sun Dec 10 00:59:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA03230 for ; Sun, 10 Dec 2000 01:59:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 01:59:35 +0100 (MET) Received: (qmail 21310 invoked by uid 0); 10 Dec 2000 00:02:57 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx23) with SMTP; 10 Dec 2000 00:02:57 -0000 X-eGroups-Return: sentto-1101623-1730-976406570-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 10 Dec 2000 00:02:51 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 00:02:49 -0000 Received: (qmail 20280 invoked from network); 10 Dec 2000 00:02:49 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 10 Dec 2000 00:02:49 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta1 with SMTP; 10 Dec 2000 00:02:48 -0000 Received: from modem-183.scandium.dialup.pol.co.uk ([62.136.20.183] helo=tiglath.pileser.sumeria) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 144tx0-0007DF-00 for f-cpu@egroups.com; Sun, 10 Dec 2000 00:02:47 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A316B80.C4B7F7AD@ifrance.com> In-Reply-To: <3A316B80.C4B7F7AD@ifrance.com> Message-Id: <00121000072504.26410@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 9 Dec 2000 23:59:39 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/plain Content-Transfer-Encoding: 8bit X-UIDL: 28c91927afe0e22b579dbe0545d9a359 Status: R X-Status: N On Fri, 08 Dec 2000, you wrote: > Le plus simple à programmer est pas mal aussi. Regarder la PSX2 certains > la boudent car elle est trop complexe à programmer ! I think that the PS2 is just going to take some time for software companies to figure out how to drive it best. On the face of it, a 4meg Video RAM doesn;t look like much, but when you learn it is on the SAME CHIP as the 3d graphics controller connected by a 2500 bit bus , you realise it isn't conventional. Also the PS2 has a 128 bit processor, and can perform apparently 14 simultaneous floating point operations in a single cycle (that's what I read anyway) - even better than Apple iMac. 's PowerPC G4 (8 simultaneous fp operations). Anything that isn't conventional takes time to learn. Once they perfect their engines, in probably 1-2 years, games will get really really awesome. Apparently Tekken (I think that's the one) is very very good already, but Unreal Tournament is more blocky than PC version. Like C to C++ was a steep curve, it requires the negotiation of a steep learning curve to program this hardware to it's best. Jeff Davies. -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/0/_/3462/_/976406570/ ---------------------------------------------------------------------_-> From Jeff Davies Sun Dec 10 01:11:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA03233 for ; Sun, 10 Dec 2000 01:59:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 01:59:36 +0100 (MET) Received: (qmail 5878 invoked by uid 0); 10 Dec 2000 00:09:52 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx04) with SMTP; 10 Dec 2000 00:09:52 -0000 X-eGroups-Return: sentto-1101623-1731-976406981-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 10 Dec 2000 00:09:50 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 00:09:41 -0000 Received: (qmail 47998 invoked from network); 10 Dec 2000 00:09:40 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 10 Dec 2000 00:09:40 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta2 with SMTP; 10 Dec 2000 00:09:40 -0000 Received: from modem-183.scandium.dialup.pol.co.uk ([62.136.20.183] helo=tiglath.pileser.sumeria) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 144u3e-0007zR-00 for f-cpu@egroups.com; Sun, 10 Dec 2000 00:09:38 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A323727.9EAF5D72@essi.fr> <20001209154758.49422@thrai.stud.uni-hannover.de> In-Reply-To: <20001209154758.49422@thrai.stud.uni-hannover.de> Message-Id: <00121000141605.26410@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 00:11:45 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e6164edfe600a2c8d225c34d696b6ddb Status: R X-Status: N On Sat, 09 Dec 2000, you wrote:
> On Sat, Dec 09, 2000 at 02:44:07PM +0100, Steve Van der Hoeven wrote:
> [...]
> > Java processor?... Let's stop this war at the begining.
>
> Yep.  The F-CPU is going to be a general processor (that can be
> programmed in all existing languages).  There may of course be
> languages that take care of its special features and create more
> effective machine code... like Fortran 77 ;)
>
> > We are at the edge of Big change of minds in the software industry.
> > They all want portable and secure languages. The facts: .net, java, intel's
> > VM....

Personally I think Smalltalk will best suit the future of computing, objects
with messages being passed instead of function calls. It does look a bit
single threaded tho. Perhaps I just haven't read enough about it.

(gst = gnu smalltalk seems to run under yet another virutal machine).

Jeff Davies
eGroups Sponsor
Click Here!
From Yann Guidon Sun Dec 10 04:00:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03923 for ; Sun, 10 Dec 2000 04:31:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 04:31:07 +0100 (MET) Received: (qmail 31130 invoked by uid 0); 10 Dec 2000 02:55:31 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx03) with SMTP; 10 Dec 2000 02:55:31 -0000 X-eGroups-Return: sentto-1101623-1732-976416926-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 10 Dec 2000 02:55:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 02:55:25 -0000 Received: (qmail 95577 invoked from network); 10 Dec 2000 02:55:25 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 10 Dec 2000 02:55:25 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 10 Dec 2000 02:55:24 -0000 Received: from f-cpu.org (nas2-231.ras.club-internet.fr [195.36.192.231]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA24337 for ; Sun, 10 Dec 2000 03:55:21 +0100 (MET) Message-ID: <3A32F1DF.2D008C99@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 04:00:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a30d88784ecef0bebc16fd0be829e8fa Status: R X-Status: N hi,

Steve Van der Hoeven wrote:
> Marco Al wrote:
> > From: "Yann Guidon" <whygee@f-cpu.org>
> > > f-cpu will not execute much C code
> > Who will use it then?
> > Wasn't it supposed to be a "UNIX processor"?
>from what i've heard in a french f-cpu meeting today,
it will be a hell to port Linux (at least for the
multi-CPU servers). But another free flavor of Unix is
of course preferred :-)

> > Marco
>
> Java processor?... Let's stop this war at the begining.
it was stopped at least 1 year ago anyway ;-)

> We are at the edge of Big change of minds in the software industry.
> They all want portable and secure languages. The facts: .net, java, intel's VM....
JAVA for HPC ? do you believe in Santa Claus ? :-))

> It looks like the no more want core dumps....
i'm a programmer and will always have core dumps/exceptions/faults/traps whatever.
and if you don't like these funny dumps (;-P) just setup your
system parameters properly (iirc : "set ulimit" or something like that).

> I know only for the Java JVM, it's base on a virtual stack processor.  A
> Son of Forth.
if you want a FORTH CPU, buy the Mup21 or build a 4Stack ... :-)

here the initial goal (2 years ago) was to design a "merced killer".
now it looks more like a SH-5 and ALPHA from the ISA point of view,
and it's not too clumbered. what more do you want ?

> All this is very high level, a resources hungry. I don't agree with it, but
> I'm not one of them
>
> We can't also forget the legacy of C code.

sure, that was the point of my previous message :
there's a GCC port that has started long ago. GCC is not adapted
at all to the kind of CPU that the F-CPU is. that's why "legacy" code
is only for portability purposes, it will not run at the CPU's full speed.
when i said that C wouldn't be much "used", it was meant : for critical purposes.
the kernel will be coded from scratch by hand, certainly in asm/macrolangage,
like all the performance critical parts of software.
The f-cpu group has started to work on new programming tools and
methods long ago, and i wish that they'll succeed. i'm really fed up of
textual programming techniques.

> And we cannot forget lisp, scheme, haskell , erlang and ml. Yes, functional
> language can be compiled.
but they are still textual, need a parser and leave room for typing & syntax errors.

> For the operating systems.... There are plenty of free OS.
yep. and there will probably be new ones in the future.

> There is no war to leed just to try to make the best decision for the furtur.
in fact it's an everyday "war", a choice, a compromise, between evolution and
revolution. that's what this mailing list is made for :-)

> -We can include high level assembly functions to make them run faster...
> but a more complex processor
nope. unless you propose something new, the current instruction set form
(well, it's slightly buggy but few people know how much ;-D) is plenty enough.
I know no CPU with "high level assembly functions" (this is a pleonasm, by the way)
and i don't see what they could do. a CPU computes, it has all the instructions
it needs (at least until today) and there's no need to "bootstrap" the ASM
novice into unused/unuseful instructions.

> -Make a risk processor, and let's hope someone will write a correct JVM or
> better a JIT
or compile a slow version of a slow JVM with a slow compiler ... :-)
i told you, if you want to run JAVA, use a 4 Stack or an adapted CPU...

> -and we have also the option of code morphing like the cursoe
what's the use ? we don't need any SW translation : the f-cpu binaries
are extremely simple to decode, simpler than a crusoe instruction.
and what a waste of raw performance :-)

> -Be different and smart and find another way
that's what is being done here.
something like programming with XML sheets/editors,
a simple set of simple SW wizzards and compilers that
give a lot of freedom and flexibility for anybody's
coding workflow.


> Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Marco Al" Sun Dec 10 05:45:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA04465 for ; Sun, 10 Dec 2000 07:24:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 07:24:48 +0100 (MET) Received: (qmail 27392 invoked by uid 0); 10 Dec 2000 04:38:41 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx22) with SMTP; 10 Dec 2000 04:38:41 -0000 X-eGroups-Return: sentto-1101623-1733-976423113-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 10 Dec 2000 04:38:40 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 04:38:32 -0000 Received: (qmail 19718 invoked from network); 10 Dec 2000 04:38:32 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 10 Dec 2000 04:38:32 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 10 Dec 2000 04:38:31 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id FAA24165 for ; Sun, 10 Dec 2000 05:38:29 +0100 (MET) Message-ID: <001f01c06263$fd4b0390$29e65982@student.utwente.nl> To: References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 05:45:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d158df5da95219a4b3d241d4b93eed0 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> from what i've heard in a french f-cpu meeting today,
> it will be a hell to port Linux (at least for the
> multi-CPU servers). But another free flavor of Unix is
> of course preferred :-)

The choices are somewhat limited, so I assume you mean xBSD... what would make
porting it easier?

> here the initial goal (2 years ago) was to design a "merced killer".
> now it looks more like a SH-5 and ALPHA from the ISA point of view,
> and it's not too clumbered. what more do you want ?

Personally... the world on a platter. I find it a pity its not a little more
sexy like OpenRISC 2K for instance :)

A "general purpose processor" which needs the equivalent of assembly level
programming to be competitive is only usefull as a glorified DSP for the world
at large. Getting people to buy a processor is one thing, getting them to use a
new programming language is a slighly more difficult task. The only way to kill
a merced is to beat it at the standard benchmarks, and most of them are written
in you know what, now merced isn't all what they cracked it up to be long ago...
but still.

> > -and we have also the option of code morphing like the cursoe
> what's the use ? we don't need any SW translation : the f-cpu binaries
> are extremely simple to decode, simpler than a crusoe instruction.
> and what a waste of raw performance :-)

Dunno... they dont have to keep a scoreboard, a foreward-compatible/"scalable"
ISA has some unavoidable overhead. And they have the tendency to accumulate more
of it with each new backward compatible generation.

Marco
eGroups Sponsor
Click Here!
From Colin Marquardt Sun Dec 10 05:33:25 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA04468 for ; Sun, 10 Dec 2000 07:24:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 07:24:49 +0100 (MET) Received: (qmail 4907 invoked by uid 0); 10 Dec 2000 04:43:17 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx23) with SMTP; 10 Dec 2000 04:43:17 -0000 X-eGroups-Return: sentto-1101623-1734-976423389-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 10 Dec 2000 04:43:16 -0000 X-Sender: colin@morphin.marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 04:43:09 -0000 Received: (qmail 28930 invoked from network); 10 Dec 2000 04:43:08 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Dec 2000 04:43:08 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta1 with SMTP; 10 Dec 2000 04:43:08 -0000 Received: from morphin.marquardt-home.de (d155.nas23.sonic.net [209.204.137.155]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id FAA17593 for ; Sun, 10 Dec 2000 05:43:05 +0100 (MET) Received: from colin by morphin.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 144yAv-0000gi-00 for ; Sat, 09 Dec 2000 20:33:25 -0800 To: f-cpu@egroups.com References: <3A323727.9EAF5D72@essi.fr> <20001209154758.49422@thrai.stud.uni-hannover.de> <00121000141605.26410@tiglath.pileser.sumeria> X-Now-Playing: Master's Faith Is In Season - Broken Promise In-Reply-To: Jeff Davies's message of "Sun, 10 Dec 2000 00:11:45 +0000" X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) Sender: Colin Marquardt From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 09 Dec 2000 20:33:25 -0800 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc20fe103ebacc5c9a20f22a0f7ebb6a Status: R X-Status: N Jeff Davies <jeff@llandre.freeserve.co.uk> writes:

> Personally I think Smalltalk will best suit the future of computing, objects
> with messages being passed instead of function calls. It does look a bit
> single threaded tho. Perhaps I just haven't read enough about it.

Indeed. And the stuff on www.squeak.org looks impressive. Apparently
Ada also makes good progress. gcc will have full Ada support again
soon.

Sorry for fueling yet another language war... :-)
  Colin
eGroups Sponsor
Click Here!
From Yann Guidon Sun Dec 10 16:42:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00746 for ; Sun, 10 Dec 2000 21:22:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 21:22:58 +0100 (MET) Received: (qmail 25243 invoked by uid 0); 10 Dec 2000 15:37:18 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx17) with SMTP; 10 Dec 2000 15:37:18 -0000 X-eGroups-Return: sentto-1101623-1735-976462634-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 10 Dec 2000 15:37:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 15:37:14 -0000 Received: (qmail 67709 invoked from network); 10 Dec 2000 15:37:14 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 10 Dec 2000 15:37:14 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 10 Dec 2000 15:37:13 -0000 Received: from f-cpu.org (nas4-143.aub.club-internet.fr [195.36.145.143]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA14748 for ; Sun, 10 Dec 2000 16:37:11 +0100 (MET) Message-ID: <3A33A45C.72664F46@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 16:42:20 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5d98cfaa3099c45ed44eb77e26dfdca Status: R X-Status: N hi,

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > from what i've heard in a french f-cpu meeting today,
> > it will be a hell to port Linux (at least for the
> > multi-CPU servers). But another free flavor of Unix is
> > of course preferred :-)
> The choices are somewhat limited, so I assume you mean xBSD...
> what would make porting it easier?
i've heard about BSD and Hurd. anyway :
- Linux on a single CPU is possible
- we'll have to write some parts of the kernel anyway in asm...

> > here the initial goal (2 years ago) was to design a "merced killer".
> > now it looks more like a SH-5 and ALPHA from the ISA point of view,
> > and it's not too clumbered. what more do you want ?
> Personally... the world on a platter.
hum, that would be rather ... heavy ...

> I find it a pity its not a little more sexy like OpenRISC 2K for instance :)
OR2K ? sexy ??? it remembers me of the Illiac IV !

> A "general purpose processor" which needs the equivalent of assembly level
> programming to be competitive is only usefull as a glorified DSP for the world
> at large.
i'm sorry, but today, all CPU need ASM to get their full speed.
for example : my mouse pad is in fact a book called "Alpha RISC Architecture
for Programmers", they show how to program the AXP in asm, and they show the
difference between asm and C coding. i find this book rather basic
because i'm used to more sophisticated code written by some "gurus" like
Paul Hsieh, Mathiesen, Abrash etc. but the last chapter is very interesting,
it compares Fortran, C and Pascal with several levels of optimisation. Geez.

so you have a choice to make : either you write a new compiler (and reinvent
the wheel) and you spend years on it, or you make your critical loops in asm.
this is not a "glorified DSP" approach, it's the approach of someone who doesn't
like compromises when it's all about performance.

> Getting people to buy a processor is one thing, getting them to use a
> new programming language is a slighly more difficult task. The only way to kill
> a merced is to beat it at the standard benchmarks, and most of them are written
> in you know what, now merced isn't all what they cracked it up to be long ago...
> but still.

of course, if you mean SPEC, then we're not going to see a SPEC rating soon.
it requires a stable HW platform, with GB of RAM and HDD...
OTOH, the Stream benchmark is much more useful and realistic.

> > > -and we have also the option of code morphing like the cursoe
> > what's the use ? we don't need any SW translation : the f-cpu binaries
> > are extremely simple to decode, simpler than a crusoe instruction.
> > and what a waste of raw performance :-)
> Dunno... they dont have to keep a scoreboard,
really ?

> a foreward-compatible/"scalable" ISA has some unavoidable overhead.
not if it is correctly done. the MIPS and ALPHA are not youg, but they are
balanced enough to last a decade... The f-cpu isa is even simpler !

> And they have the tendency to accumulate more
> of it with each new backward compatible generation.
not if the first versions are correctly designed.

anyway...

huh, VHDL anyone ? :-)

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Marco Al" Sun Dec 10 21:37:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01087 for ; Sun, 10 Dec 2000 23:21:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 23:21:58 +0100 (MET) Received: (qmail 9608 invoked by uid 0); 10 Dec 2000 20:31:26 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx23) with SMTP; 10 Dec 2000 20:31:26 -0000 X-eGroups-Return: sentto-1101623-1736-976480274-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 10 Dec 2000 20:31:24 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 20:31:13 -0000 Received: (qmail 42805 invoked from network); 10 Dec 2000 20:31:12 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 10 Dec 2000 20:31:12 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 10 Dec 2000 20:31:12 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id VAA00905 for ; Sun, 10 Dec 2000 21:31:10 +0100 (MET) Message-ID: <000501c062e9$14e64070$29e65982@student.utwente.nl> To: References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 21:37:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 642ecdb4f3bb9485c3dac09d1f65d612 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> of course, if you mean SPEC, then we're not going to see a SPEC rating soon.
> it requires a stable HW platform, with GB of RAM and HDD...
> OTOH, the Stream benchmark is much more useful and realistic.

Realistic for what uses? Compilers/databases/AI?

Marco
eGroups Sponsor
Click Here!
From Steve Van der Hoeven Mon Dec 11 01:06:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01126 for ; Sun, 10 Dec 2000 23:22:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 10 Dec 2000 23:22:10 +0100 (MET) Received: (qmail 15233 invoked by uid 0); 10 Dec 2000 22:01:08 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx07) with SMTP; 10 Dec 2000 22:01:08 -0000 X-eGroups-Return: sentto-1101623-1737-976485618-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 10 Dec 2000 22:00:22 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 22:00:18 -0000 Received: (qmail 66313 invoked from network); 10 Dec 2000 22:00:17 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 10 Dec 2000 22:00:17 -0000 Received: from unknown (HELO citronier.wanadoo.fr) (193.252.19.222) by mta3 with SMTP; 10 Dec 2000 23:01:23 -0000 Received: from essi.fr (193.253.219.8) by citronier.wanadoo.fr; 10 Dec 2000 23:00:17 +0100 Sender: root@pop.gmx.net Message-ID: <3A341A77.1D81771@essi.fr> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> <000501c062e9$14e64070$29e65982@student.utwente.nl> From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 01:06:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4bd4fdafd04a9b2738d1e088e6e0ad1f Status: R X-Status: N Marco Al wrote:

> From: "Yann Guidon" <whygee@f-cpu.org>
>
> > of course, if you mean SPEC, then we're not going to see a SPEC rating soon.
> > it requires a stable HW platform, with GB of RAM and HDD...
> > OTOH, the Stream benchmark is much more useful and realistic.
>
> Realistic for what uses? Compilers/databases/AI?
>
> Marco

private joke...

Win specs?

Steve
eGroups Sponsor
Click Here!
From Michael Riepe Mon Dec 11 00:09:55 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01673 for ; Mon, 11 Dec 2000 01:41:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 01:41:50 +0100 (MET) Received: (qmail 11358 invoked by uid 0); 10 Dec 2000 23:10:10 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx13) with SMTP; 10 Dec 2000 23:10:10 -0000 X-eGroups-Return: sentto-1101623-1738-976489799-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 10 Dec 2000 23:10:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Dec 2000 23:09:59 -0000 Received: (qmail 12078 invoked from network); 10 Dec 2000 23:09:58 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Dec 2000 23:09:58 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.215) by mta1 with SMTP; 10 Dec 2000 23:09:57 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00523; Mon, 11 Dec 2000 00:09:55 +0100 Message-ID: <20001211000955.35256@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A33A45C.72664F46@f-cpu.org>; from Yann Guidon on Sun, Dec 10, 2000 at 04:42:20PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 00:09:55 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f90f41ea7dabfb70d5f3fadc7448aecc Status: R X-Status: N On Sun, Dec 10, 2000 at 04:42:20PM +0100, Yann Guidon wrote:

> anyway...
>
> huh, VHDL anyone ? :-)

Patience, please.  The next version of EU_IMU is on its way...
Features: both widening and same-size MAC instructions, fine-grained
variable pipelining (allows stage depths that are any multiple of 2),
latency: 3...6 cycles with standard 6-gate stages, throughput: 1/cycle.
Availability: before Xmas :)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Jeff Davies Mon Dec 11 00:47:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01679 for ; Mon, 11 Dec 2000 01:41:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 01:41:51 +0100 (MET) Received: (qmail 14830 invoked by uid 0); 11 Dec 2000 00:01:54 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx05) with SMTP; 11 Dec 2000 00:01:54 -0000 X-eGroups-Return: sentto-1101623-1739-976492910-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 11 Dec 2000 00:01:53 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 00:01:50 -0000 Received: (qmail 34919 invoked from network); 11 Dec 2000 00:01:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 11 Dec 2000 00:01:49 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta3 with SMTP; 11 Dec 2000 01:02:54 -0000 Received: from modem-113.protactinium.dialup.pol.co.uk ([62.136.65.113] helo=tiglath.pileser.sumeria) by cmailg6.svr.pol.co.uk with smtp (Exim 3.13 #0) id 145GPZ-0004qC-00 for f-cpu@egroups.com; Mon, 11 Dec 2000 00:01:46 +0000 To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> In-Reply-To: <3A32F1DF.2D008C99@f-cpu.org> Message-Id: <00121100055500.28142@tiglath.pileser.sumeria> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 23:47:43 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 42afdff9ebf72b1f57ec9c588d72ac38 Status: R X-Status: N > > -Make a risk processor, and let's hope someone will write a correct JVM or
> > better a JIT
> or compile a slow version of a slow JVM with a slow compiler ... :-)
> i told you, if you want to run JAVA, use a 4 Stack or an adapted CPU...

There are native Java compilers eg IBM VisualAge, that compile from Java source
code to eg X86 machine code. I very much doubt any JVM limitations are
encountered, since all java source is in essence is C++ sans pointers (ie no
direct access to memory). Also since a java class can be decompiled, you
can regard it merely as a tokenised form of the source, and so, there is no
reason why your JIT native compiler should use registers (including stacks
which don't per se exist in FCPU) in anything like the way that a JVM
would.
There should be no problem linking to a library produced from an
assembler, so you can still code fast bits in machine code. This is a
non-discussion, hammering out any inconsistencies in the instruction set
as mentioned is probably a more worthy topic of conversation.

> > -Be different and smart and find another way
> that's what is being done here.
> something like programming with XML sheets/editors,
> a simple set of simple SW wizzards and compilers that
> give a lot of freedom and flexibility for anybody's
> coding workflow.
Agree whole heartedly. There is no limit to what can be achieved in software,
the
hard part is getting a real FCPU.
I think that setting up charities in various countries, collecting funds for an
initial batch of FCPUs should probably be a core task right now.
I can set one up in the UK, what I need is some people to be trustees. I forget
the figure we worked out once, was it about 150,000 euros to get 2000 fc0 made?
That would be about 750 euros from 200 people. Once FCPUs created, we could
maybe sell quite a few on ebay as collectors items.
Originally, I thought to prove in an FPGA was a good idea, now I think FPGA
structure is so different, it doesn't prove much to prove it in a FPGA in any
case.
Obviously, we need a perfect set of VHDL, even more, perhaps a physical layout
(eg Alliance), where the CPU has been tested to the nth degree, before cutting
silicon. We also need software tools in place (C compiler, test suite,
reasonable level of OS), and a board to drop the CPU into after manufacture - to
test/use it.

Happily, if 64 bit CPUs give way to 128 bit CPUs before we manufacture one, I
think the architecture is pretty well easily adaptable to 128 bit etc etc.

Jeff Davies
eGroups Sponsor
Click Here!
From "Marco Al" Mon Dec 11 01:53:11 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01892 for ; Mon, 11 Dec 2000 02:21:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 02:21:29 +0100 (MET) Received: (qmail 10183 invoked by uid 0); 11 Dec 2000 00:54:24 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx01) with SMTP; 11 Dec 2000 00:54:24 -0000 X-eGroups-Return: sentto-1101623-1740-976495589-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 11 Dec 2000 00:46:57 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 00:46:28 -0000 Received: (qmail 50234 invoked from network); 11 Dec 2000 00:46:25 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 11 Dec 2000 00:46:25 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 11 Dec 2000 00:46:25 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA06754 for ; Mon, 11 Dec 2000 01:46:23 +0100 (MET) Message-ID: <000c01c0630c$bc3dd4a0$29e65982@student.utwente.nl> To: References: <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <00121100055500.28142@tiglath.pileser.sumeria> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 01:53:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 920a2f7e4c8cf5b0b996333a5b264590 Status: R X-Status: N From: "Jeff Davies" <jeff@llandre.freeserve.co.uk>

> Obviously, we need a perfect set of VHDL, even more, perhaps a physical layout
> (eg Alliance), where the CPU has been tested to the nth degree, before cutting
> silicon. We also need software tools in place (C compiler, test suite,
> reasonable level of OS), and a board to drop the CPU into after manufacture -
to
> test/use it.

Dont know if everyone's seen this, but I found the Sulima project interesting
(http://www.cse.unsw.edu.au/~disy/Sulima/). Might be a little easier than
inventing another wheel.

> Happily, if 64 bit CPUs give way to 128 bit CPUs before we manufacture one, I
> think the architecture is pretty well easily adaptable to 128 bit etc etc.

I think an address space of 18 million tera bytes should suffice for a while.

Marco
eGroups Sponsor
Click Here!
From Sun Dec 10 18:18:09 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01898 for ; Mon, 11 Dec 2000 02:21:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 02:21:31 +0100 (MET) Received: (qmail 27143 invoked by uid 0); 11 Dec 2000 01:11:38 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx23) with SMTP; 11 Dec 2000 01:11:38 -0000 X-eGroups-Return: sentto-1101623-1741-976497088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 11 Dec 2000 01:11:32 -0000 X-Sender: crispyj@amele.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 01:11:27 -0000 Received: (qmail 12590 invoked from network); 11 Dec 2000 01:11:26 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 11 Dec 2000 01:11:26 -0000 Received: from unknown (HELO gibson.menta.net) (212.78.128.22) by mta3 with SMTP; 11 Dec 2000 02:12:29 -0000 Received: from _[125.113.90.241]_by ([212.78.131.112]) by gibson.menta.net (Netscape Messaging Server 4.15) with SMTP id G5DPUX07.03I; Mon, 11 Dec 2000 02:08:58 +0100 Received: from [72.51.243.223] by _[125.113.90.241]_by with SMTP id A42C13E9 Sun, 10 Dec 2000 17:00:52 PDT From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Dec 2000 17:18:09 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Just imagine... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Message-ID: <20001211011138.27177gmx1@mx23.gmx.net> X-UIDL: 4a23d0649f698f9ff667326cc58fa994 Status: R X-Status: N Untitled Document

Our 20 Year Old International Company,
Traded on NASDAQ Is Offering You:
 A Complete Home Based On-Line Business Opportunity At NO RISK !



You Can Earn $1,500 - $8,500
or more per month (PT/FT)

If this kind of business opportunity excites you, please fill
out the form below completely, and a personal business
consultant will contact you within 24 hours.
Your Name:
Address:
City:
State:
Zip:
E-mail Address:
Telephone:
Best Time/Day to Call:
Current Occupation:
Age:
Have you operated a home business before?
 YES NO
Weekly income you would like to earn?

To be removed from our mailing list simply CLICK HERE

eGroups Sponsor
Click Here!
From Yann Guidon Mon Dec 11 03:38:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02057 for ; Mon, 11 Dec 2000 03:41:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 03:41:10 +0100 (MET) Received: (qmail 15008 invoked by uid 0); 11 Dec 2000 02:34:01 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx17) with SMTP; 11 Dec 2000 02:34:01 -0000 X-eGroups-Return: sentto-1101623-1742-976502020-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 11 Dec 2000 02:34:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 02:33:38 -0000 Received: (qmail 36317 invoked from network); 11 Dec 2000 02:33:38 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 11 Dec 2000 02:33:38 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 11 Dec 2000 02:33:38 -0000 Received: from f-cpu.org (nas3-22.ras.club-internet.fr [195.36.203.22]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA00418 for ; Mon, 11 Dec 2000 03:33:15 +0100 (MET) Message-ID: <3A343E29.F2BA41D1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <00121100055500.28142@tiglath.pileser.sumeria> <000c01c0630c$bc3dd4a0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 03:38:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1d3492c168b2f7bc055dcb8425e84740 Status: R X-Status: N hi,
some words...

Marco Al wrote:
> > Happily, if 64 bit CPUs give way to 128 bit CPUs before we manufacture one, I
> > think the architecture is pretty well easily adaptable to 128 bit etc etc.
> I think an address space of 18 million tera bytes should suffice for a while.

1) 64/128-bits is for data, not pointers. above 64 bits, most of the
data is SIMD...
2) i guess that the physical limit is 256 bits for pointers.
it's more or less the number of atoms in the universe. that's the above limit.
OTOH, the latest parallel computers based on ALPHA chips (like the T3E) have
already reached their physical addressing limit : the pointers are 43 bits
in HW (even though the 64 bits are validated) and the 2048 CPU of a T3E
can have a lot of memory. so, even though it will take a while to reach, i believe
that 64-bit address space (and a bit more) can be useful : the F-CPU architecture
is designed to last several decades and the 64-bit addressing barrier will certainly
be important "one day". Of course, inside the CPU, the physical address lines/pins
can be limited to 30... (with a granularity of 32 bytes so it corresponds
to 35 bits).

well, let's program, now :-)

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Mon Dec 11 04:00:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02170 for ; Mon, 11 Dec 2000 04:04:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 04:04:08 +0100 (MET) Received: (qmail 10071 invoked by uid 0); 11 Dec 2000 02:57:36 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 11 Dec 2000 02:57:36 -0000 X-eGroups-Return: sentto-1101623-1743-976503451-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 11 Dec 2000 02:57:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 02:57:30 -0000 Received: (qmail 19507 invoked from network); 11 Dec 2000 02:57:29 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 11 Dec 2000 02:57:29 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 11 Dec 2000 02:57:29 -0000 Received: from f-cpu.org (nas3-22.ras.club-internet.fr [195.36.203.22]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22463 for ; Mon, 11 Dec 2000 03:56:35 +0100 (MET) Message-ID: <3A34436A.D9FB201@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <00121100055500.28142@tiglath.pileser.sumeria> <000c01c0630c$bc3dd4a0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 04:00:58 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5dad8fa90329d758feac688ee4e07769 Status: R X-Status: N Marco Al wrote:
> Dont know if everyone's seen this, but I found the Sulima project interesting
> (http://www.cse.unsw.edu.au/~disy/Sulima/). Might be a little easier than
> inventing another wheel.

indeed : very interesting :-) it looks simple enough (though i don't know much
about all the different projects).

check it.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Mon Dec 11 04:16:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00310 for ; Mon, 11 Dec 2000 14:40:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 14:40:28 +0100 (MET) Received: (qmail 23594 invoked by uid 0); 11 Dec 2000 03:12:46 -0000 Received: from mu.egroups.com (64.211.240.238) by mx19.rz2.gmx.net (mx19) with SMTP; 11 Dec 2000 03:12:46 -0000 X-eGroups-Return: sentto-1101623-1744-976504250-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 11 Dec 2000 03:12:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 03:10:49 -0000 Received: (qmail 32769 invoked from network); 11 Dec 2000 03:10:49 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 11 Dec 2000 03:10:49 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 11 Dec 2000 03:10:49 -0000 Received: from f-cpu.org (nas3-22.ras.club-internet.fr [195.36.203.22]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA27006 for ; Mon, 11 Dec 2000 04:10:46 +0100 (MET) Message-ID: <3A3446F8.91B0C9BE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <00121100055500.28142@tiglath.pileser.sumeria> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 04:16:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d69e82b531a14c3d7a2c8f53371beb4e Status: R X-Status: N hi,

Jeff Davies wrote:
> > > -Be different and smart and find another way
> > that's what is being done here.
> > something like programming with XML sheets/editors,
> > a simple set of simple SW wizzards and compilers that
> > give a lot of freedom and flexibility for anybody's
> > coding workflow.
> Agree whole heartedly. There is no limit to what can be achieved in software, the
> hard part is getting a real FCPU.
> I think that setting up charities in various countries, collecting funds for an
> initial batch of FCPUs should probably be a core task right now.
money is not our problem today : we achieved a lot of things with
a minimal budget in the past, and it would be cool if this could go on this way.
i hate financial issues...

> I can set one up in the UK, what I need is some people to be trustees. I forget
> the figure we worked out once, was it about 150,000 euros to get 2000 fc0 made?
> That would be about 750 euros from 200 people. Once FCPUs created, we could
> maybe sell quite a few on ebay as collectors items.

let the industry do its work : take risks and make money. if they have a stable
and powerful design, they'll offer the protos. TSMC has done it for the OpenCores
project, and other companies will jump into that fashion. no need to
risk our mager economies for an "amateur" project :-) we only need to "hint/help"
the industry into good designs.

> Originally, I thought to prove in an FPGA was a good idea, now I think FPGA
> structure is so different, it doesn't prove much to prove it in a FPGA in any case.

it helps to prove that "it does indeed works".
but in my company, in the future, i will probably have the opportunity
to prove more than that :-)

> Obviously, we need a perfect set of VHDL, even more, perhaps a physical layout
> (eg Alliance), where the CPU has been tested to the nth degree, before cutting
> silicon.
i don't think it's an issue now : the manual and the VHDL must be finished,
validated, proofed and checked. if we install quality policies, it will take some
time to organise and clean all the files and directories. it will help to
gain the confidence and support of the industry (even though they might do
"amateurish" things, companies usually promote clean and clear SW).
once it's gained, it will be really easy to get prototyping help :-)

> We also need software tools in place (C compiler, test suite,
> reasonable level of OS), and a board to drop the CPU into after manufacture - to
> test/use it.

let's stick to SW only stuff. the compiling issue is a major one, for example.
the physical implementations will vary a lot, so let's not jump too rapidly ...

> Happily, if 64 bit CPUs give way to 128 bit CPUs before we manufacture one, I
> think the architecture is pretty well easily adaptable to 128 bit etc etc.
depending on the available sources, i think that i can easily simulate a 256-bit
version on the emulation machines at work.

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Mon Dec 11 04:19:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00313 for ; Mon, 11 Dec 2000 14:40:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 14:40:29 +0100 (MET) Received: (qmail 23372 invoked by uid 0); 11 Dec 2000 03:14:41 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx09) with SMTP; 11 Dec 2000 03:14:41 -0000 X-eGroups-Return: sentto-1101623-1745-976504461-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 11 Dec 2000 03:14:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 03:14:21 -0000 Received: (qmail 73480 invoked from network); 11 Dec 2000 03:14:21 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 11 Dec 2000 03:14:21 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 11 Dec 2000 04:15:26 -0000 Received: from f-cpu.org (nas3-22.ras.club-internet.fr [195.36.203.22]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA09455 for ; Mon, 11 Dec 2000 04:14:17 +0100 (MET) Message-ID: <3A3447CB.F8F8A1A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> <20001211000955.35256@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 04:19:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3d7f2ee79cd83136375a1cbf72bdae19 Status: R X-Status: N hi,

Michael Riepe wrote:
> On Sun, Dec 10, 2000 at 04:42:20PM +0100, Yann Guidon wrote:
> > huh, VHDL anyone ? :-)
>
> Patience, please.  The next version of EU_IMU is on its way...
as usually :-)

> Features: both widening and same-size MAC instructions, fine-grained
> variable pipelining (allows stage depths that are any multiple of 2),
> latency: 3...6 cycles with standard 6-gate stages, throughput: 1/cycle.
6-input gates ?

> Availability: before Xmas :)
will you present it at the 17C3 ?

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From careerathome@looksmart.co.uk Mon Dec 11 10:51:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00345 for ; Mon, 11 Dec 2000 14:40:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 14:40:37 +0100 (MET) Received: (qmail 13512 invoked by uid 0); 11 Dec 2000 10:13:35 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx02) with SMTP; 11 Dec 2000 10:13:35 -0000 X-eGroups-Return: sentto-1101623-1746-976529607-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 11 Dec 2000 10:13:29 -0000 X-Sender: careerathome@looksmart.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 10:13:26 -0000 Received: (qmail 28829 invoked from network); 11 Dec 2000 10:13:26 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Dec 2000 10:13:26 -0000 Received: from unknown (HELO mail.lundeneset.vgs.no) (193.215.124.94) by mta2 with SMTP; 11 Dec 2000 10:13:25 -0000 Message-Id: <200012111026.LAA11495@mail.lundeneset.vgs.no> From: careerathome@looksmart.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 01:51:26 -0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Start A Career From Home Content-Type: multipart/mixed; boundary="----=_NextPart_000_24F8_00006A01.000037D8" To: sloyment@gmx.net X-UIDL: 0d9e28b031cf0ccd58474bd1a107bb8f Status: R X-Status: N ------=_NextPart_000_24F8_00006A01.000037D8 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit LOOKING FOR GEMS! It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income! Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need. Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-320-9895 ext. 6396 We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! The call is FREE, and there is absolutely no obligation, So what have you got to lose? Call Toll Free 1-800-320-9895 ext. 6396 P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life! Please, serious inquiries only. To be removed from future mailings send a blank email with remove in the subject line and the email address or addresses to be removed in the body to careerathome@looksmart.co.uk

LOOKING FOR GEMS!


eGroups Sponsor
Click Here!
------=_NextPart_000_24F8_00006A01.000037D8-- From Michael Riepe Mon Dec 11 14:27:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00350 for ; Mon, 11 Dec 2000 20:38:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 20:38:56 +0100 (MET) Received: (qmail 22998 invoked by uid 0); 11 Dec 2000 18:14:07 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx09) with SMTP; 11 Dec 2000 18:14:07 -0000 X-eGroups-Return: sentto-1101623-1747-976558425-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 11 Dec 2000 18:14:02 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 18:13:44 -0000 Received: (qmail 8828 invoked from network); 11 Dec 2000 18:13:44 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 11 Dec 2000 18:13:44 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.125) by mta1 with SMTP; 11 Dec 2000 18:13:25 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00487; Mon, 11 Dec 2000 14:27:39 +0100 Message-ID: <20001211142739.18171@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> <20001211000955.35256@thrai.stud.uni-hannover.de> <3A3447CB.F8F8A1A@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A3447CB.F8F8A1A@f-cpu.org>; from Yann Guidon on Mon, Dec 11, 2000 at 04:19:39AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 14:27:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f15d2b1d45142acbe50fc1d322a16056 Status: R X-Status: N On Mon, Dec 11, 2000 at 04:19:39AM +0100, Yann Guidon wrote:

> > > huh, VHDL anyone ? :-)
> >
> > Patience, please.  The next version of EU_IMU is on its way...
> as usually :-)

I think it will be finished soon...

> > Features: both widening and same-size MAC instructions, fine-grained
> > variable pipelining (allows stage depths that are any multiple of 2),
> > latency: 3...6 cycles with standard 6-gate stages, throughput: 1/cycle.
> 6-input gates ?

No, of course not.  I still use the same gate library.

> > Availability: before Xmas :)
> will you present it at the 17C3 ?

I don't think so.  The documentation isn't done yet, and I still have to
run some tests (which takes a lot of time on my computer, unfortunately).
There are also some non-technical reasons: my back hurts too much, and I
can't afford the trip to Berlin anyway (lots of bills to pay on Jan 1st).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Nicolas Boulay Mon Dec 11 20:19:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00370 for ; Mon, 11 Dec 2000 20:39:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 20:39:01 +0100 (MET) Received: (qmail 16304 invoked by uid 0); 11 Dec 2000 19:14:59 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx18) with SMTP; 11 Dec 2000 19:14:59 -0000 X-eGroups-Return: sentto-1101623-1748-976562072-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 11 Dec 2000 19:14:55 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 19:14:24 -0000 Received: (qmail 58538 invoked from network); 11 Dec 2000 19:14:22 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Dec 2000 19:14:22 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 11 Dec 2000 19:14:21 -0000 Received: from ifrance.com (nas13-175.vlt.club-internet.fr [195.36.163.175]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA16377 for ; Mon, 11 Dec 2000 20:14:19 +0100 (MET) Message-ID: <3A3528AC.1B2B03B0@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A316B80.C4B7F7AD@ifrance.com> <3A317E80.EA4E4005@f-cpu.org> <000a01c06181$2f01daa0$29e65982@student.utwente.nl> <3A323727.9EAF5D72@essi.fr> <3A32F1DF.2D008C99@f-cpu.org> <001f01c06263$fd4b0390$29e65982@student.utwente.nl> <3A33A45C.72664F46@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 20:19:08 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8af27d01f6ea5f753e124a8a3fff2066 Status: R X-Status: N Hello !

Yann Guidon a =E9crit :
>
> > A "general purpose processor" which needs the equivalen= t of assembly level
> > programming to be competitive is only usefull as a glorified DSP = for the world
> > at large.
> i'm sorry, but today, all CPU need ASM to get their full speed.
> for example : my mouse pad is in fact a book called "Alpha RISC A= rchitecture
> for Programmers", they show how to program the AXP in asm, and th= ey show the
> difference between asm and C coding. i find this book rather basic
> because i'm used to more sophisticated code written by some "guru= s" like
> Paul Hsieh, Mathiesen, Abrash etc. but the last chapter is very intere= sting,
> it compares Fortran, C and Pascal with several levels of optimisation.= Geez.
>
> so you have a choice to make : either you write a new compiler (and re= invent
> the wheel) and you spend years on it, or you make your critical loops = in asm.
> this is not a "glorified DSP" approach, it's the approach of= someone who doesn't
> like compromises when it's all about performance.
>
Hum ! Where is the critical loop of a mpeg 4 encoder ? between the line
number 10 and line number 4000 ;P

For java, if the fcpu have no specic pointer register it will be great
for Java and its stacks.

Another things, why not using direct operand though memory (like DSP). I know that it's completly out of RISC philosophy. But having a dual (3?)
ported memory cache (L1) could be easy. The register has pointer. Hard
to write, but compact and fast code.

No ?

Sorry, i'll be sleeping...

nicO
eGroups Sponsor=
3D"Click
From whygee@club-internet.fr Mon Dec 11 20:49:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00480 for ; Mon, 11 Dec 2000 21:14:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 11 Dec 2000 21:14:19 +0100 (MET) Received: (qmail 8872 invoked by uid 0); 11 Dec 2000 19:50:17 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx05) with SMTP; 11 Dec 2000 19:50:17 -0000 X-eGroups-Return: sentto-1101623-1749-976564190-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 11 Dec 2000 19:50:09 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 19:49:49 -0000 Received: (qmail 8658 invoked from network); 11 Dec 2000 19:49:47 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Dec 2000 19:49:47 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 11 Dec 2000 20:50:52 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id UAA20363 for f-cpu@egroups.com; Mon, 11 Dec 2000 20:49:45 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 20:49:45 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: aba776bf6291a7c9cada209b04741202 Status: R X-Status: N hi !

>De: Nicolas Boulay <nicolas.boulay@ifrance.com>
>Date: Mon, 11 Dec 2000 20:19:08 +0100
>Sujet: Re: [f-cpu] HW/SW
>
>Hello !
>
>Yann Guidon a =E9crit :
<snip>
>> this is not a "glorified DSP" approach, it's the approac= h of someone who doesn't
>> like compromises when it's all about performance.
>>
>Hum ! Where is the critical loop of a mpeg 4 encoder ? between the line=
>number 10 and line number 4000 ;P
do you have any proof to back that assumption ? ;-)


>Another things, why not using direct operand though memory (like DSP).<= BR> what DSP do you know does this ?

> I know that it's completly out of RISC philosophy. But having a dual (= 3?)
>ported memory cache (L1) could be easy. The register has pointer. Hard<= BR> >to write, but compact and fast code.
>No ?

I don't see what you mean. memory-to-memory ?
memory-mapped register ? or like the CDC6600 ?

pointer generators (look at ADi) are really cool
but unRISCy. OTOH i have of course some ideas...

>Sorry, i'll be sleeping...

moi aussi...

>nicO
YG
eGroups Sponsor=
3D"Click
From DuaneMHunt170976@aol.com Tue Dec 12 00:12:06 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01490 for ; Wed, 13 Dec 2000 03:27:32 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 03:27:32 +0100 (MET) Received: (qmail 29682 invoked by uid 0); 11 Dec 2000 23:12:40 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx18) with SMTP; 11 Dec 2000 23:12:40 -0000 X-eGroups-Return: sentto-1101623-1750-976576337-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 11 Dec 2000 23:12:31 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Dec 2000 23:12:16 -0000 Received: (qmail 70225 invoked from network); 11 Dec 2000 23:12:16 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 11 Dec 2000 23:12:16 -0000 Received: from unknown (HELO imo-r08.mx.aol.com) (152.163.225.8) by mta2 with SMTP; 11 Dec 2000 23:12:16 -0000 Received: from DuaneMHunt170976@aol.com by imo-r08.mx.aol.com (mail_out_v28.34.) id a.46.dbebf58 (4330) for ; Mon, 11 Dec 2000 18:12:06 -0500 (EST) Message-ID: <46.dbebf58.2766b946@aol.com> To: f-cpu@egroups.com X-Mailer: Windows AOL sub 105 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 18:12:06 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Just imagine... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 68f38e0c30923ad69fbe0192ef424d17 Status: R X-Status: N if this all this MAILING IS GOING TO BECOME i think ill quit

ive seem to be getting JUNK MAIL NOW
eGroups Sponsor
Click Here!
From Keyshaun Tue Dec 12 04:35:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01553 for ; Wed, 13 Dec 2000 03:27:47 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 03:27:47 +0100 (MET) Received: (qmail 26168 invoked by uid 0); 12 Dec 2000 09:38:01 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx09) with SMTP; 12 Dec 2000 09:38:01 -0000 X-eGroups-Return: sentto-1101623-1751-976613869-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 12 Dec 2000 09:37:59 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Dec 2000 09:37:49 -0000 Received: (qmail 36486 invoked from network); 12 Dec 2000 09:37:48 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 12 Dec 2000 09:37:48 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 12 Dec 2000 10:38:54 -0000 Received: (qmail 10844 invoked from network); 12 Dec 2000 03:35:53 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 12 Dec 2000 03:35:53 -0000 X-Sender: To: In-Reply-To: <200012111026.LAA11495@mail.lundeneset.vgs.no> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 11 Dec 2000 20:35:53 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8bc2043e2d4f2df8db1374ea066af68c Status: R X-Status: N Can we get careerathome@looksmart.co.uk kicked from this list?

Shaun

On Mon, 11 Dec 2000 careerathome@looksmart.co.uk wrote:

> LOOKING FOR GEMS! It's So Simple To Earn $2,000 - $5,000 Per Week
> Nowadays... We're searching for only 10 elite individuals with the work
> ethic necessary to generate a cash-flow for themselves of $2,000 -
> $5,000per week, and to increase that to over $20,000 per month, in as
> little as four to six months. And you know what? If you really have a
> burning desire and commitment, we guarantee you that you'll reach this
> explosive income! Can you read a short script to our qualified leads, and
> then turn the interested prospects over to our electronic sales medium?
> (you will not be required to do any selling.)Do you have the
> self-discipline to ignore the TV for a couple of hours per day? Are you
> looking for a legitimate home-based business opportunity, that is not
> multi-level marketing, or a chain-letter scheme? If you would like to
> build an amazing income that will grow lightning-fast and have you profit
> $1,000.00 every time only one prospect makes a purchase, then this is for
> you! You can build the business under our guidance and support without
> having to attend meetings or sell people things they don't need. Call NOW
> our TOLL FREE, PRE-RECORDED Message: 1-800-320-9895 ext. 6396 We market a
> real product, that pays real commissions to you,$1,000.00 per sale, just
> for making the initial contacts. With our turn-key lead generation
> systems you'll always talk to people who actually WANT to talk to you.
> You have nothing to lose, there's no risk involved, nor is there any
> obligation whatsoever, and you may be qualified to earn thousands of
> extra dollars per month! So call now! The call is FREE, and there is
> absolutely no obligation, So what have you got to lose? Call Toll Free
> 1-800-320-9895 ext. 6396 P.S. You literally have a once-in-a-lifetime
> opportunity to GET INVOLVED NOW! Don't let this one go by. You have
> absolutely nothing to lose! This could be the most fascinating and
> profitable business of your life! Please, serious inquiries only. To be
> removed from future mailings send a blank email with remove in the
> subject line and the email address or addresses to be removed in the body
> to careerathome@looksmart.co.uk
>
> LOOKING FOR GEMS!
>
>
> eGroups Sponsor
> Click Here!
>
eGroups Sponsor
Click Here!
From Nicolas Boulay Tue Dec 12 20:20:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00333 for ; Wed, 13 Dec 2000 16:32:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:34 +0100 (MET) Received: (qmail 14000 invoked by uid 0); 12 Dec 2000 20:58:00 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 12 Dec 2000 20:58:00 -0000 X-eGroups-Return: sentto-1101623-1752-976648524-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 12 Dec 2000 19:15:32 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Dec 2000 19:15:24 -0000 Received: (qmail 64565 invoked from network); 12 Dec 2000 19:15:23 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 12 Dec 2000 19:15:23 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 12 Dec 2000 19:15:23 -0000 Received: from ifrance.com (nas12-245.vlt.club-internet.fr [195.36.162.245]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA14628 for ; Tue, 12 Dec 2000 20:15:20 +0100 (MET) Message-ID: <3A367A6E.F99C2438@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Dec 2000 20:20:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] HW/SW Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 7b9cc52da5a7e1b2dd73c025b61a7eb0 Status: R X-Status: N Hello,

whygee@club-internet.fr a =E9crit :
>
> hi !
>
> >De: Nicolas Boulay <nicolas.boulay@ifrance.com>
> >Date: Mon, 11 Dec 2000 20:19:08 +0100
> >Sujet: Re: [f-cpu] HW/SW
> >
> >Hello !
> >
> >Yann Guidon a =E9crit :
> <snip>
> >> this is not a "glorified DSP" approach, it's the ap= proach of someone who doesn't
> >> like compromises when it's all about performance.
> >>
> >Hum ! Where is the critical loop of a mpeg 4 encoder ? between the= line
> >number 10 and line number 4000 ;P
> do you have any proof to back that assumption ? ;-)
>

An MPEG4 encoder analyse image to exctract spirit and texture from the
movies. This analyse are very heavy, and aren't made by a simple IDCT,
for exemple.

> >Another things, why not using direct operand though memory (like D= SP).
> what DSP do you know does this ?
>

I think all the lastest TI DSP ( ex: IMAC (R0+) (R1+) (R2+) which need 3 memory buses, but imac (R0+) R1 (R1+) should be good, too)

> > I know that it's completly out of RISC philosophy. But having a d= ual (3?)
> >ported memory cache (L1) could be easy. The register has pointer. = Hard
> >to write, but compact and fast code.
> >No ?
>
> I don't see what you mean. memory-to-memory ?
> memory-mapped register ? or like the CDC6600 ?
>

A little bit like that. Each registers are seen like pointers or a head
of stack. You could skip lots of load&store operation and have truely one mac operation per clock cycle ! You can avoid the overhead by having a deep pipeline. We just need a multiported L1 cache.

For usual non-mathematical operation, you could avoid the dependencies
on the stack pointer. (some compiler maker who can speak about that ? ). I remember you the true ilp off gcc which come to 3 to more than 200
without stack pointer dependencies !!

> pointer generators (look at ADi) are really cool
> but unRISCy. OTOH i have of course some ideas...
>
> >Sorry, i'll be sleeping...
>
> moi aussi...
>
> >nicO
> YG
nicO
eGroups Sponsor=
3D"Click
From home-biz.info@usa Sun Jan 18 01:43:02 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00336 for ; Wed, 13 Dec 2000 16:32:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:36 +0100 (MET) Received: (qmail 26789 invoked by uid 0); 12 Dec 2000 22:23:40 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx05) with SMTP; 12 Dec 2000 22:23:40 -0000 X-eGroups-Return: sentto-1101623-1753-976659408-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 12 Dec 2000 22:17:29 -0000 X-Sender: home-biz.info@usa. X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Dec 2000 22:16:47 -0000 Received: (qmail 5183 invoked from network); 12 Dec 2000 22:16:45 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 12 Dec 2000 22:16:45 -0000 Received: from unknown (HELO dns.) (202.207.160.2) by mta3 with SMTP; 12 Dec 2000 23:17:48 -0000 Received: from 202.207.160.2 by dns. (SMI-8.6/SMI-SVR4) id GAA03944; Wed, 13 Dec 2000 06:14:52 -0800 Message-Id: <200012131414.GAA03944@dns.> To: f-cpu@egroups.com From: home-biz.info@usa MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Dec 00 13:14:46 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] Voted #1 Online Business Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0db7ce76028299d84702d9287859b551 Status: R X-Status: N Dear Friend,

May I have your permission to send you FREE information
regarding an exciting and very profitable SELF-RUN online business?

It is truly the HOTTEST and the EASIEST home business today!
Voted #1 online business in a major business magazine!
You can make up to $14,000 per month in your spare time!

It is NOT a chain letter, NOT an illegal get-rich-quick scam. it is a
legitimate online business which has been around for over 4 YEARS!

This home business is for REAL! No Hype!

Please click below to receive FREE VITAL INFORMATION:

Mailto:  ljfeeney@usa.com

Write the word "INTERESTED" in the SUBJECT field.

You will be glad that you did!

Thank you and have a great day!

With My Warmest Regards,
Lyle Feeney.
eGroups Sponsor
Click Here!
From Michael Riepe Tue Dec 12 14:49:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00339 for ; Wed, 13 Dec 2000 16:32:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:36 +0100 (MET) Received: (qmail 11627 invoked by uid 0); 12 Dec 2000 22:32:24 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 12 Dec 2000 22:32:24 -0000 X-eGroups-Return: sentto-1101623-1754-976660055-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 12 Dec 2000 22:27:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Dec 2000 22:27:34 -0000 Received: (qmail 93781 invoked from network); 12 Dec 2000 22:27:31 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Dec 2000 22:27:31 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.78) by mta2 with SMTP; 12 Dec 2000 22:27:22 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00555; Tue, 12 Dec 2000 14:49:50 +0100 Message-ID: <20001212144950.10371@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200012111026.LAA11495@mail.lundeneset.vgs.no> X-Mailer: Mutt 0.84e In-Reply-To: ; from Keyshaun on Mon, Dec 11, 2000 at 08:35:53PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Dec 2000 14:49:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e930b71713c74c4ef36fe64975434e67 Status: R X-Status: N On Mon, Dec 11, 2000 at 08:35:53PM -0700, Keyshaun wrote:
> Can we get careerathome@looksmart.co.uk kicked from this list?

Can we kick the full-quoters, too?  One copy of this shit is enough ;(

I'm sure they aren't on the list -- they just use it to send their SPAM
to all of us.  We can't block that (and eGroups won't do it, I guess).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Michael Riepe Wed Dec 13 01:41:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00369 for ; Wed, 13 Dec 2000 16:32:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:44 +0100 (MET) Received: (qmail 26806 invoked by uid 0); 13 Dec 2000 00:47:48 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx03) with SMTP; 13 Dec 2000 00:47:48 -0000 X-eGroups-Return: sentto-1101623-1755-976668104-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 13 Dec 2000 00:41:51 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 00:41:43 -0000 Received: (qmail 74268 invoked from network); 13 Dec 2000 00:41:42 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 13 Dec 2000 00:41:42 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.78) by mta2 with SMTP; 13 Dec 2000 00:41:41 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03296; Wed, 13 Dec 2000 01:41:35 +0100 Message-ID: <20001213014135.54754@thrai.stud.uni-hannover.de> To: F-CPU Mailing List X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 01:41:35 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] New Release of EU_IMU and other stuff... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 38a8ae6a89997918ab77935a72e0c498 Status: R X-Status: N Hi!

I have put the latest version (Codename: Advent) on my homepage (better
than sending ~30k to this list).  Please have a look at

      http://www.stud.uni-hannover.de/~michael/f-cpu/f-cpu-mr.tar.gz

I have adopted Yann's directory structure; the only difference is the
`compile/simili' subdir that contains the batch files for compiling my
stuff with Simili.  There's plenty of room for other subdirs (e.g. for
modelsim & friends); feel free do add them yourself.

The package also contains the EU_ASU unit, but it isn't pipelined yet;
that will be my next task before I concentrate on the divider.

Have fun,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Keyshaun Wed Dec 13 02:25:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00381 for ; Wed, 13 Dec 2000 16:32:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:46 +0100 (MET) Received: (qmail 30216 invoked by uid 0); 13 Dec 2000 02:05:27 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx05) with SMTP; 13 Dec 2000 02:05:27 -0000 X-eGroups-Return: sentto-1101623-1756-976673057-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 13 Dec 2000 02:04:37 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 02:04:16 -0000 Received: (qmail 79262 invoked from network); 13 Dec 2000 02:04:15 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 13 Dec 2000 02:04:15 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta3 with SMTP; 13 Dec 2000 03:05:21 -0000 Received: (qmail 25955 invoked from network); 13 Dec 2000 01:25:23 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 13 Dec 2000 01:25:23 -0000 X-Sender: To: In-Reply-To: <20001212144950.10371@thrai.stud.uni-hannover.de> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 12 Dec 2000 18:25:23 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af468e91063390f80e82698b87f4ab6a Status: R X-Status: N > Can we kick the full-quoters, too?  One copy of this shit is enough ;(
I'll watch that next time.  It's just to easy to hit "ryyy" in pine.



>
> I'm sure they aren't on the list -- they just use it to send their SPAM
> to all of us.  We can't block that (and eGroups won't do it, I guess).
>
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Wed Dec 13 11:00:52 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00402 for ; Wed, 13 Dec 2000 16:32:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:53 +0100 (MET) Received: (qmail 32361 invoked by uid 0); 13 Dec 2000 10:11:35 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx13) with SMTP; 13 Dec 2000 10:11:35 -0000 X-eGroups-Return: sentto-1101623-1759-976701655-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 13 Dec 2000 10:00:57 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 10:00:54 -0000 Received: (qmail 31322 invoked from network); 13 Dec 2000 10:00:54 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 13 Dec 2000 10:00:54 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 13 Dec 2000 11:01:59 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id LAA24623 for f-cpu@egroups.com; Wed, 13 Dec 2000 11:00:52 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 11:00:52 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] F-CPU II (was: HW/SW) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5ba4f5963052d2ad96adf5a1a271c072 Status: R X-Status: N hi there,

>De: Nicolas Boulay <nicolas.boulay@ifrance.com>
>Hello,
>whygee@club-internet.fr a =E9crit :
>> hi !
>> >De: Nicolas Boulay <nicolas.boulay@ifrance.com>
>> >Hum ! Where is the critical loop of a mpeg 4 encoder ? between= the line
>> >number 10 and line number 4000 ;P
>> do you have any proof to back that assumption ? ;-)
>An MPEG4 encoder analyse image to exctract spirit and texture from the<= BR> >movies. This analyse are very heavy, and aren't made by a simple IDCT,<= BR> >for exemple.

by "proof" i meant : source code... hehe :-)
any link ?

>> >Another things, why not using direct operand though memory (li= ke DSP).
>> what DSP do you know does this ?
>I think all the lastest TI DSP ( ex: IMAC (R0+) (R1+) (R2+) which need = 3
>memory buses, but imac (R0+) R1 (R1+) should be good, too)
ok i see.

>> > I know that it's completly out of RISC philosophy. But having= a dual (3?)
>> >ported memory cache (L1) could be easy. The register has point= er. Hard
>> >to write, but compact and fast code.
>> >No ?
>> I don't see what you mean. memory-to-memory ?
>> memory-mapped register ? or like the CDC6600 ?
>A little bit like that. Each registers are seen like pointers or a head=
>of stack. You could skip lots of load&store operation and have true= ly
>one mac operation per clock cycle ! You can avoid the overhead by havin= g
>a deep pipeline. We just need a multiported L1 cache.

FYI that's what i intend to do for a "long" time.
it won't appear soon but one day, when the F-CPU will be
ok, i'll try to launch "F-CPU II" :-)
>from a programming point of view, it's the same except that
the register bank is split into two categories :
32 normal registers and 16 pairs of (index/data) registers.
when an instruction accesses a data register (R/W), the
index is updated and the corresponding data is transferred
from/to memory to/from the Xbar. the Special Registers will
contain the base, limit, increment and mode attributes
of each pair (a bit like a DSP i know...).

hey, it was you who spoke about a "magnified DSP" ?...

>For usual non-mathematical operation, you could avoid the dependencies<= BR> >on the stack pointer. (some compiler maker who can speak about that ? )= .
>I remember you the true ilp off gcc which come to 3 to more than 200 >without stack pointer dependencies !!

hence my advocacy for a very large logical register bank...

>> >nicO
>> YG
>nicO
YG
eGroups Sponsor=
3D"Click
From Steve Van der Hoeven Wed Dec 13 14:53:36 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00408 for ; Wed, 13 Dec 2000 16:32:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:54 +0100 (MET) Received: (qmail 18837 invoked by uid 0); 13 Dec 2000 12:30:14 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx04) with SMTP; 13 Dec 2000 12:30:14 -0000 X-eGroups-Return: sentto-1101623-1761-976708066-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 13 Dec 2000 11:47:49 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 11:47:45 -0000 Received: (qmail 41956 invoked from network); 13 Dec 2000 11:47:44 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 13 Dec 2000 11:47:44 -0000 Received: from unknown (HELO andira.wanadoo.fr) (193.252.19.152) by mta1 with SMTP; 13 Dec 2000 11:47:44 -0000 Received: from essi.fr (193.253.219.8) by andira.wanadoo.fr; 13 Dec 2000 12:47:44 +0100 Sender: root@pop.gmx.net Message-ID: <3A377F60.6FFF62A@essi.fr> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 14:53:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dfc0772abb68ca25f414d38cf4dedc1d Status: R X-Status: N F-CPU dev account wrote:

> hello,
>
> as seul.org's site is getting more used, the spartiate
> (inexistant) web design is looking awfull. can someone plaese
> help and design some decent HTML pages ? thanks.
>

what do you want to set up?

>
> these locations are active :
> http://www.f-cpu.seul.org/
> http://www.f-cpu.seul.org/whygee
>

are empty...

> http://www.f-cpu.seul.org/olivier
>

anonymous don't have acces to it....


Steve
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Wed Dec 13 10:41:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00417 for ; Wed, 13 Dec 2000 16:32:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:56 +0100 (MET) Received: (qmail 6040 invoked by uid 0); 13 Dec 2000 12:39:41 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx08) with SMTP; 13 Dec 2000 12:39:41 -0000 X-eGroups-Return: sentto-1101623-1757-976700492-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 13 Dec 2000 09:41:35 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 09:41:31 -0000 Received: (qmail 52177 invoked from network); 13 Dec 2000 09:41:31 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 13 Dec 2000 09:41:31 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 13 Dec 2000 09:41:30 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA15861; Wed, 13 Dec 2000 10:41:28 +0100 (MET) To: stefan.meretz@hbv.org Cc: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 10:41:28 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Re: [pox] Freedom CPU at Oekonux conference Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e040ca15bd191f43d4c3aadd9c703bdd Status: R X-Status: N hi !

>De: Stefan Meretz <stefan.meretz@hbv.org>
>A: projekt@oekonux.de
>Copie =E0: whygee@f-cpu.org
>Sujet: Re: [pox] Freedom CPU at Oekonux conference
>
>Hi Yann,
>
>Stefan Merten schrieb:
>> Stefan Meretz: Yann asks whether he can meet someone from Oekonux = on
>> the CCC congress. Any news in this area?
>> (...)
>> > i will be present with several german and french F-CPU people= in Berlin
>> > for the 17C3 (see ht= tp://www.ccc.de/congress), can we meet there too ?
>>
>> Unfortunately I'll not be there personally. However, there are pla= ns
>> of at least Stefan Meretz being there. You may contact him directl= y at
>> `Stefan Meretz <stefan.meretz@hbv.org>'.
>
>I give two talks at 17C3, however, the schedules are not published
>yet. Titles of the talks are: "Von der Freien Software zur Freien<= BR> >Gesellschaft" and "Von Offener Theorie zur Offenen Enzyklop= =E4die"
>(together with Torsten W=F6llert). There, you can find me. Or do you >have some meeting point for the F-CPU people? Do you give a
>presentation or a workshop?
>
>Ciao,
>Stefan

The F-CPU team will be present at the hackcenter and we are
trying to organize a "long" workshop, split into two (or
three ???) parts or "time slots". you'll find us easily :-)
last year, we have displayed several announcements in
the coridors, with the F-CPU logo.

The expected program is :
- part 1 : FPGA and free designs, half an hour presented by
someone of the f-cpu team (i have forgotten his name)
followed, if we have some luck, by an overview of the
"free hardware" world and the several projects.
maybe Nicloas Boulay will explain a bit what he does
with the Leon, and how ? :-)

- Part 2 : F-CPU history, philosophy and organisation,
that is the part that will be also presented in Dortmund.

- Part 3 : F-CPU design, structure, programming and miscellaneous
techniques. that's the technical part of the project,
explaining the f-cpu instruction set, the FC0 microarchitecture
and how it can be programmed.

Stay tuned,

YG
eGroups Sponsor=
3D"Click
From whygee@club-internet.fr Wed Dec 13 10:48:27 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00420 for ; Wed, 13 Dec 2000 16:32:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:57 +0100 (MET) Received: (qmail 6668 invoked by uid 0); 13 Dec 2000 12:40:00 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx08) with SMTP; 13 Dec 2000 12:40:00 -0000 X-eGroups-Return: sentto-1101623-1758-976700909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 13 Dec 2000 09:48:31 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 09:48:29 -0000 Received: (qmail 64643 invoked from network); 13 Dec 2000 09:48:29 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 13 Dec 2000 09:48:29 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 13 Dec 2000 09:48:28 -0000 Received: (from mnet@localhost) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA19226 for f-cpu@egroups.com; Wed, 13 Dec 2000 10:48:27 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 10:48:27 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] New Release of EU_IMU and other stuff... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 18bc67f8f2fa4d49c98f9494f9797fc4 Status: R X-Status: N yeah !

i just needed a good kick in the back :-)


>Hi!
>
>I have put the latest version (Codename: Advent) on my homepage (better
>than sending ~30k to this list).  Please have a look at
http://www.stud.uni-hannover.de/~michael/f-cpu/f-cpu-mr.tar.gz

ok i got it. i'll have to work hard on it. if i ever find time
:-(

>I have adopted Yann's directory structure; the only difference is the
>`compile/simili' subdir that contains the batch files for compiling my
>stuff with Simili.  There's plenty of room for other subdirs (e.g. for
>modelsim & friends); feel free do add them yourself.

good idea :-)

>The package also contains the EU_ASU unit, but it isn't pipelined yet;
>that will be my next task before I concentrate on the divider.

ok, what will be your strategy for the pipelining ?

>Have fun,
more than you'd think...

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
it is sad that you can't come meet us in Berlin.
maybe on IRC ? :-)

YG
eGroups Sponsor
Click Here!
From F-CPU dev account Wed Dec 13 12:37:50 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00423 for ; Wed, 13 Dec 2000 16:32:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 16:32:58 +0100 (MET) Received: (qmail 9989 invoked by uid 0); 13 Dec 2000 12:42:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx18) with SMTP; 13 Dec 2000 12:42:15 -0000 X-eGroups-Return: sentto-1101623-1760-976707473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 13 Dec 2000 11:37:59 -0000 X-Sender: f-cpu@cran.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 11:37:52 -0000 Received: (qmail 73745 invoked from network); 13 Dec 2000 11:37:52 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 13 Dec 2000 11:37:52 -0000 Received: from unknown (HELO cran.mit.edu) (18.244.0.188) by mta1 with SMTP; 13 Dec 2000 11:37:52 -0000 Received: (from f-cpu@localhost) by cran.mit.edu (8.9.3/8.9.3) id GAA27908 for f-cpu@egroups.com; Wed, 13 Dec 2000 06:37:50 -0500 Message-Id: <200012131137.GAA27908@cran.mit.edu> To: f-cpu@egroups.com From: F-CPU dev account MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 06:37:50 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c5f5dca12cefa4cb0567245b0fb3c939 Status: R X-Status: N hello,

as seul.org's site is getting more used, the spartiate
(inexistant) web design is looking awfull. can someone plaese
help and design some decent HTML pages ? thanks.

these locations are active :
http://www.f-cpu.seul.org/
http://www.f-cpu.seul.org/whygee
http://www.f-cpu.seul.org/olivier

please apply on the list :-)

YG
eGroups Sponsor
Click Here!
From Michael Riepe Wed Dec 13 14:37:42 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01108 for ; Wed, 13 Dec 2000 22:19:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 13 Dec 2000 22:19:11 +0100 (MET) Received: (qmail 16353 invoked by uid 0); 13 Dec 2000 18:20:09 -0000 Received: from hh.egroups.com (208.50.99.210) by mx12.rz2.gmx.net (mx12) with SMTP; 13 Dec 2000 18:20:09 -0000 X-eGroups-Return: sentto-1101623-1762-976729493-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 13 Dec 2000 17:45:04 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 17:44:52 -0000 Received: (qmail 97358 invoked from network); 13 Dec 2000 17:44:52 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 13 Dec 2000 17:44:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.77) by mta2 with SMTP; 13 Dec 2000 17:44:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00518; Wed, 13 Dec 2000 14:37:42 +0100 Message-ID: <20001213143742.23920@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Wed, Dec 13, 2000 at 10:48:27AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 13 Dec 2000 14:37:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] New Release of EU_IMU and other stuff... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6e211580ce04c53a0f91ba2720235ff7 Status: R X-Status: N On Wed, Dec 13, 2000 at 10:48:27AM +0100, whygee@club-internet.fr wrote:
[...]
> >The package also contains the EU_ASU unit, but it isn't pipelined yet;
> >that will be my next task before I concentrate on the divider.
>
> ok, what will be your strategy for the pipelining ?

For the divider?  None yet.

> it is sad that you can't come meet us in Berlin.
> maybe on IRC ? :-)

I'm on IrcNet every day^H^H^Hnight; nickname: `Tired'.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann Guidon Thu Dec 14 00:17:16 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00314 for ; Thu, 14 Dec 2000 16:09:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:15 +0100 (MET) Received: (qmail 8923 invoked by uid 0); 13 Dec 2000 23:17:19 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx18) with SMTP; 13 Dec 2000 23:17:19 -0000 X-eGroups-Return: sentto-1101623-1763-976749114-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 13 Dec 2000 23:12:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 23:11:53 -0000 Received: (qmail 75525 invoked from network); 13 Dec 2000 23:11:50 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Dec 2000 23:11:50 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 13 Dec 2000 23:11:48 -0000 Received: from f-cpu.org (nas1-207.aub.club-internet.fr [195.36.150.207]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA07606 for ; Thu, 14 Dec 2000 00:11:46 +0100 (MET) Message-ID: <3A38037C.26D392F4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 00:17:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b8210d13a2f0d50004317f354e32fdd2 Status: R X-Status: N hi,

Steve Van der Hoeven wrote:
> F-CPU dev account wrote:
> > hello,
> >
> > as seul.org's site is getting more used, the spartiate
> > (inexistant) web design is looking awfull. can someone plaese
> > help and design some decent HTML pages ? thanks.
> what do you want to set up?

"as much as can be" :-) it's like a blank page today... it is, indeed.

> > these locations are active :
> > http://www.f-cpu.seul.org/
> > http://www.f-cpu.seul.org/whygee
> are empty...
exactly :-) at least http://www.f-cpu.seul.org/ should be index'ed...

> > http://www.f-cpu.seul.org/olivier
> anonymous don't have acces to it....
he hasn't chmoded his directories yet...

propositions, anyone ? :-/

> Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Steve Van der Hoeven Thu Dec 14 02:34:23 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00359 for ; Thu, 14 Dec 2000 16:09:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:27 +0100 (MET) Received: (qmail 13094 invoked by uid 0); 13 Dec 2000 23:40:34 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx05) with SMTP; 13 Dec 2000 23:40:34 -0000 X-eGroups-Return: sentto-1101623-1764-976750117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 13 Dec 2000 23:28:55 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Dec 2000 23:28:36 -0000 Received: (qmail 29306 invoked from network); 13 Dec 2000 23:28:36 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 13 Dec 2000 23:28:36 -0000 Received: from unknown (HELO andira.wanadoo.fr) (193.252.19.152) by mta1 with SMTP; 13 Dec 2000 23:28:36 -0000 Received: from essi.fr (193.253.219.8) by andira.wanadoo.fr; 14 Dec 2000 00:28:35 +0100 Sender: root@pop.gmx.net Message-ID: <3A38239F.414566DD@essi.fr> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> <3A38037C.26D392F4@f-cpu.org> From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 02:34:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bc390941d1e91bc39aac568c4e7a668a Status: R X-Status: N > > > as seul.org's site is getting more used, the spartiate
> > > (inexistant) web design is looking awfull. can someone plaese
> > > help and design some decent HTML pages ? thanks.
> > what do you want to set up?
>
> "as much as can be" :-) it's like a blank page today... it is, indeed.
>
> propositions, anyone ? :-/

www.f-cpu.org and related are  mainly for communication with the outside
world...
utopia is for the communication with related free hardware projects
Whygee 's page is for Whygee's glory... ;)

Let's make something more functional for us.

Quick indexes to the manual,  source code milestones, tools source code
links, members adresses, work plan (we don't need to invent twice the rop
unit)...
Not fancy, just static but quick and helpfull for us.

We could base it on xml files... It's easier to maintain (separation of the
informationa and presentation), and not much more to learn.

And I could do a christmas present to the FCPU team...
;)

Steve
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 14 01:19:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00362 for ; Thu, 14 Dec 2000 16:09:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:28 +0100 (MET) Received: (qmail 9743 invoked by uid 0); 14 Dec 2000 00:27:48 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx04) with SMTP; 14 Dec 2000 00:27:48 -0000 X-eGroups-Return: sentto-1101623-1765-976753541-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 14 Dec 2000 00:25:49 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 00:25:40 -0000 Received: (qmail 26665 invoked from network); 14 Dec 2000 00:25:39 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 14 Dec 2000 00:25:39 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta2 with SMTP; 14 Dec 2000 00:25:39 -0000 Received: from modem-178.chlorine.dialup.pol.co.uk ([62.136.16.178] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 146MDJ-0004Lk-00 for f-cpu@egroups.com; Thu, 14 Dec 2000 00:25:38 +0000 Message-ID: <3A3811F6.95FEBFFC@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> <3A38037C.26D392F4@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 00:19:03 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 26082de950882b3c987b392e9ff111e8 Status: R X-Status: N

Yann Guidon wrote:

> hi,
>
> > > help and design some decent HTML pages ? thanks.
> > what do you want to set up?
>
> "as much as can be" :-) it's like a blank page today... it is, indeed.
>

By decent, please have no panes, no javascript, none of that crap, and
definitely no shock.
Just plain simple HTML and JPG/GIF (animated if you must).
www.google.com is my ideal kind of web site. Very very to the point.
<also by far and away now the most successful search engine - not
surprising, compare it to lycos:
you can't see the box to enter your search terms for all the adverts and
confusing munge of stuff>

Jeff Davies
eGroups Sponsor
Click Here!
From "Christian Schubert" Thu Dec 14 06:35:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00435 for ; Thu, 14 Dec 2000 16:09:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:45 +0100 (MET) Received: (qmail 30426 invoked by uid 0); 14 Dec 2000 05:38:12 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx02) with SMTP; 14 Dec 2000 05:38:12 -0000 X-eGroups-Return: sentto-1101623-1766-976772238-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 14 Dec 2000 05:37:25 -0000 X-Sender: cms@pnetservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 05:37:17 -0000 Received: (qmail 67114 invoked from network); 14 Dec 2000 05:37:17 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 14 Dec 2000 05:37:17 -0000 Received: from unknown (HELO moutvdom01.kundenserver.de) (195.20.224.200) by mta1 with SMTP; 14 Dec 2000 05:37:17 -0000 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 146R4s-0003CP-00 for f-cpu@egroups.com; Thu, 14 Dec 2000 06:37:14 +0100 Received: from pd9019f66.dip.t-dialin.net ([217.1.159.102] helo=apex) by mrvdom04.kundenserver.de with smtp (Exim 2.12 #2) id 146R4p-0006Bh-00 for f-cpu@egroups.com; Thu, 14 Dec 2000 06:37:11 +0100 Message-ID: <00a701c0658f$e6eb8fa0$0200a8c0@schubert> To: References: <200012111026.LAA11495@mail.lundeneset.vgs.no> <20001212144950.10371@thrai.stud.uni-hannover.de> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Christian Schubert" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 06:35:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 29d97899e576b35253efe37997312c61 Status: R X-Status: N From: "Michael Riepe" <michael@stud.uni-hannover.de>
> I'm sure they aren't on the list -- they just use it to send their
SPAM
> to all of us.  We can't block that (and eGroups won't do it, I
guess).

That's quite wrong, eGroups can be configured to block postings from
people not on the list, but as the ops are gone, there is no chance to
do this (except eGroups would make e.g. YG list-op)
eGroups Sponsor
Click Here!
From Yann Guidon Thu Dec 14 09:29:28 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00441 for ; Thu, 14 Dec 2000 16:09:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:46 +0100 (MET) Received: (qmail 8681 invoked by uid 0); 14 Dec 2000 08:25:49 -0000 Received: from mv.egroups.com (208.50.144.81) by mx11.rz2.gmx.net (mx11) with SMTP; 14 Dec 2000 08:25:49 -0000 X-eGroups-Return: sentto-1101623-1768-976782256-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 14 Dec 2000 08:24:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 08:24:15 -0000 Received: (qmail 48662 invoked from network); 14 Dec 2000 08:24:15 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 14 Dec 2000 08:24:15 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 14 Dec 2000 08:24:15 -0000 Received: from f-cpu.org (nas4-175.aub.club-internet.fr [195.36.145.175]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA06618 for ; Thu, 14 Dec 2000 09:24:12 +0100 (MET) Message-ID: <3A3884E8.E760B4A6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200012111026.LAA11495@mail.lundeneset.vgs.no> <20001212144950.10371@thrai.stud.uni-hannover.de> <00a701c0658f$e6eb8fa0$0200a8c0@schubert> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 09:29:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0c92994154eac9b46a6b7365f2ed4270 Status: R X-Status: N hi,

Christian Schubert wrote:
> From: "Michael Riepe" <michael@stud.uni-hannover.de>
> > I'm sure they aren't on the list -- they just use it to send their SPAM
> > to all of us.  We can't block that (and eGroups won't do it, I guess).
> That's quite wrong, eGroups can be configured to block postings from
> people not on the list, but as the ops are gone, there is no chance to
> do this (except eGroups would make e.g. YG list-op)

nooooo....

i don't want to have something more to worry. I operate the french list
already, plus several websites (that lag a lot !) so i don't want
to be in charge of yet another stuff.

Anyway, this situation lasts for a long time now, and i doubt that
egroups would change it now. On the other side, this uncontrollable
situation preserves the freedom of speech.

If we have to move the list to another place, it will take a long
time to do, maybe several months. all the websites, configurations etc
will have to be updated, the discussions might be lost.

the discussion is left open... but it is obvious that we CAN'T
close the egroups list ourselves.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Thu Dec 14 09:29:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00444 for ; Thu, 14 Dec 2000 16:09:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:47 +0100 (MET) Received: (qmail 31307 invoked by uid 0); 14 Dec 2000 08:26:58 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx05) with SMTP; 14 Dec 2000 08:26:58 -0000 X-eGroups-Return: sentto-1101623-1767-976782254-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ef.egroups.com with NNFMP; 14 Dec 2000 08:24:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 08:24:12 -0000 Received: (qmail 18276 invoked from network); 14 Dec 2000 08:24:12 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 14 Dec 2000 08:24:12 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 14 Dec 2000 08:24:11 -0000 Received: from f-cpu.org (nas4-175.aub.club-internet.fr [195.36.145.175]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA24730 for ; Thu, 14 Dec 2000 09:24:09 +0100 (MET) Message-ID: <3A3884E6.561D17F2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> <3A38037C.26D392F4@f-cpu.org> <3A3811F6.95FEBFFC@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 09:29:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 88441f93f35deb9ee2e6568fe5d9a230 Status: R X-Status: N hi,

Jeff Davies wrote:
> Yann Guidon wrote:
> By decent, please have no panes, no javascript, none of that crap, and
> definitely no shock. Just plain simple HTML and JPG/GIF (animated if you must).

wherever you go on the f-cpu websites, the most "sophisticated" you can see
is PHP3 pages, but that's a server side stuff... no worries :-)

> www.google.com is my ideal kind of web site. Very very to the point.
> <also by far and away now the most successful search engine - not
> surprising, compare it to lycos:
> you can't see the box to enter your search terms for all the adverts and
> confusing munge of stuff>

the f-cpu is not a marketing business, we need no professional graphists
(we don't refuse though, if someone volunteers) and plain HTML is not
as outdated as it looks... :-)

> Jeff Davies

Steve Van der Hoeven wrote:
> > > what do you want to set up?
> > "as much as can be" :-) it's like a blank page today... it is, indeed.
> > propositions, anyone ? :-/
> www.f-cpu.org and related are  mainly for communication with the outside world...
> utopia is for the communication with related free hardware projects
> Whygee 's page is for Whygee's glory... ;)
well summed up :-P

> Let's make something more functional for us.
if you like... at least something must exist so we can browse the site...

> Quick indexes to the manual,  source code milestones, tools source code
> links, members adresses, work plan (we don't need to invent twice the rop
> unit)... Not fancy, just static but quick and helpfull for us.
site map, public and "private" PHP3 notepads...

> We could base it on xml files... It's easier to maintain (separation of the
> informationa and presentation), and not much more to learn.
but who can do and compile XML ?

> And I could do a christmas present to the FCPU team...
> ;)
there is no little measure :-)
what matters is your will to do something good :-)

i hope that my "withdrawal" from the f-cpu project (for professional reasons)
will be solved soon. but it won't change the fact that we need webmasterS,
as well as VHDL coderS. we have reached a maximum number of websites.

> Steve
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 14 10:46:26 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00462 for ; Thu, 14 Dec 2000 16:09:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:51 +0100 (MET) Received: (qmail 15799 invoked by uid 0); 14 Dec 2000 09:54:39 -0000 Received: from hl.egroups.com (208.50.99.197) by mx06.rz2.gmx.net (mx06) with SMTP; 14 Dec 2000 09:54:39 -0000 X-eGroups-Return: sentto-1101623-1769-976787589-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 14 Dec 2000 09:53:18 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 09:53:09 -0000 Received: (qmail 65466 invoked from network); 14 Dec 2000 09:53:08 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 Dec 2000 09:53:08 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta3 with SMTP; 14 Dec 2000 10:54:13 -0000 Received: from modem-93.tin.dialup.pol.co.uk ([62.136.41.93] helo=llandre.freeserve.co.uk) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 146V4T-0004Ak-00 for f-cpu@egroups.com; Thu, 14 Dec 2000 09:53:05 +0000 Message-ID: <3A3896F2.1B9D807@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> <3A38037C.26D392F4@f-cpu.org> <3A3811F6.95FEBFFC@llandre.freeserve.co.uk> <3A3884E6.561D17F2@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 09:46:26 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e1573ca5244beb007e9b594461021cd2 Status: R X-Status: N Yann Guidon wrote:

> > Quick indexes to the manual,  source code milestones, tools source code
> > links, members adresses, work plan (we don't need to invent twice the rop
> > unit)... Not fancy, just static but quick and helpfull for us.
> site map, public and "private" PHP3 notepads...
>

I was wondering (personally) if there was a package on freshmeat that is essentially a
PHP free software project website set of scripts. (delete and replace with hardware).

> > We could base it on xml files... It's easier to maintain (separation of the
> > informationa and presentation), and not much more to learn.
> but who can do and compile XML ?

I can send anyone who wants it my FCPU multimedia DTD. I haven't written XSL for it
yet, but this is
trivial. Two very good free editing tools are
1. IBM xeena (IBM alphaworks site). Don't like it's handling of CDATA tho. XSLT works
very well with this.
Note this is free download but not GPL.
2. Merlot (www.merlotxml.org or is it merlot-xml.org?). This is my favourite. The XSLT
by default fires up
(on windows systems) IE5, automatically presuming that you are converting your XML to
HTML.
You can change this behaviour by editing a config file stored inside a .jar.
Licence is GPL.
**NOTE both the above require Java 2 (1.3). //whygeee -> perhaps this is why your's
didn't work??

Jeff Davies


Note -as the compiler project is (supposed to be) on Sourceforge (this is CVS - right),
couldn't we just make
a sub project containing the VHDL files? Then that's the CVS sorted, or has someone put
up a pserver since?
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 14 11:28:47 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00465 for ; Thu, 14 Dec 2000 16:09:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:53 +0100 (MET) Received: (qmail 16868 invoked by uid 0); 14 Dec 2000 10:37:17 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx04) with SMTP; 14 Dec 2000 10:37:17 -0000 X-eGroups-Return: sentto-1101623-1770-976790148-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ck.egroups.com with NNFMP; 14 Dec 2000 10:35:56 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 10:35:47 -0000 Received: (qmail 10024 invoked from network); 14 Dec 2000 10:35:47 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 14 Dec 2000 10:35:47 -0000 Received: from unknown (HELO cmailg2.svr.pol.co.uk) (195.92.195.172) by mta2 with SMTP; 14 Dec 2000 10:35:47 -0000 Received: from modem-93.tin.dialup.pol.co.uk ([62.136.41.93] helo=llandre.freeserve.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 146Vje-0003am-00 for f-cpu@egroups.com; Thu, 14 Dec 2000 10:35:41 +0000 Message-ID: <3A38A0DF.3809339@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 10:28:47 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Ooops Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b602daf78fdd067804b89e64e4e8e8b6 Status: R X-Status: N Sorry YG I do beg your pardon, I've just been to the www.f-cpu.org web
site <very very nice>,
and seen the link to sourceforge.
The GCC files on sourceforge are 8 months old, have any mods been made
since that?

Wasn't someone working on a simulator?
Why not put the manual into the CVS site also?
<would be nice if one could grab a total snapshot of the system from one
CVS tree>.

Jeff Davies
eGroups Sponsor
Click Here!
From Steve Van der Hoeven Thu Dec 14 16:37:38 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00486 for ; Thu, 14 Dec 2000 16:09:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 16:09:58 +0100 (MET) Received: (qmail 18902 invoked by uid 0); 14 Dec 2000 13:32:37 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx18) with SMTP; 14 Dec 2000 13:32:37 -0000 X-eGroups-Return: sentto-1101623-1771-976800714-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 14 Dec 2000 13:32:04 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 13:31:53 -0000 Received: (qmail 89965 invoked from network); 14 Dec 2000 13:31:52 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 14 Dec 2000 13:31:52 -0000 Received: from unknown (HELO antholoma.wanadoo.fr) (193.252.19.153) by mta1 with SMTP; 14 Dec 2000 13:31:52 -0000 Received: from essi.fr (193.253.219.8) by antholoma.wanadoo.fr; 14 Dec 2000 14:31:52 +0100 Sender: root@pop.gmx.net Message-ID: <3A38E942.2BB947C3@essi.fr> X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en To: f-cpu@egroups.com References: <200012131137.GAA27908@cran.mit.edu> <3A377F60.6FFF62A@essi.fr> <3A38037C.26D392F4@f-cpu.org> <3A3811F6.95FEBFFC@llandre.freeserve.co.uk> <3A3884E6.561D17F2@f-cpu.org> From: Steve Van der Hoeven MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 16:37:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d956a35295ce266e9b843ecc1f8dc13c Status: R X-Status: N Okay I will do some stuff in two weeks, just need some time to finish my exams


> > Let's make something more functional for us.
> if you like... at least something must exist so we can browse the site...
>

... I should need to know what's on the site ...

>
> > Quick indexes to the manual,  source code milestones, tools source code
> > links, members adresses, work plan (we don't need to invent twice the rop
> > unit)... Not fancy, just static but quick and helpfull for us.
> site map, public and "private" PHP3 notepads...
>

do we need server side application?.. do we have the possibility for server side
applications?
why notepads? would this not leed to a diffusion of information.... I like the emails,
because it's a passive wait to be notified. And every thing is centrelized, no need to
action three different process to stay in touch...

> > We could base it on xml files... It's easier to maintain (separation of the
> > informationa and presentation), and not much more to learn.
> but who can do and compile XML ?
>

Don't worry. My idea is to make it easier to maintain.

> what matters is your will to do something good :-)

My best.

Steve
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 14 17:25:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00809 for ; Thu, 14 Dec 2000 17:46:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 17:46:31 +0100 (MET) Received: (qmail 7614 invoked by uid 0); 14 Dec 2000 16:36:34 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx13) with SMTP; 14 Dec 2000 16:36:34 -0000 X-eGroups-Return: sentto-1101623-1772-976811124-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 14 Dec 2000 16:25:45 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 16:25:23 -0000 Received: (qmail 72549 invoked from network); 14 Dec 2000 16:25:21 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 14 Dec 2000 16:25:21 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 14 Dec 2000 16:25:21 -0000 Received: (from mnet@localhost) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA22128 for f-cpu@egroups.com; Thu, 14 Dec 2000 17:25:18 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 17:25:18 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Ooops Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eee04e0bbe0a1b090d415eb6f2de8e62 Status: R X-Status: N hi !

>De: Jeff Davies
>Sorry YG I do beg your pardon, I've just been to the
> www.f-cpu.org web site <very very nice>,
hey, i HAD free time when i did it :-)

>and seen the link to sourceforge.
>The GCC files on sourceforge are 8 months old, have any mods been made
>since that?

some big ones. i haven't tested them anyway, i can't seem to find the
proper directory and files on my SuSE distro...
Look at the mail archives, seek posts from Lee.

>Wasn't someone working on a simulator?
the simulator is currently done in VHDL.
it's not fast but when it works, it is very acurate :-)

>Why not put the manual into the CVS site also?
Olivier said he'll release the files soon (for the Nth time)...

><would be nice if one could grab a total snapshot of the system from one
>CVS tree>.

sure !

at the 17C3, i would like to distribute some CDs containing
my unsorted working files, directories, goodies and so on...
if  it was cleaned up an sorted, it would even be better :-D

>Jeff Davies
eGroups Sponsor
Click Here!
From Michael Riepe Thu Dec 14 13:50:57 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01399 for ; Thu, 14 Dec 2000 22:18:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 22:18:43 +0100 (MET) Received: (qmail 14360 invoked by uid 0); 14 Dec 2000 16:42:33 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx09) with SMTP; 14 Dec 2000 16:42:33 -0000 X-eGroups-Return: sentto-1101623-1773-976811601-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 14 Dec 2000 16:33:30 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 16:33:20 -0000 Received: (qmail 33407 invoked from network); 14 Dec 2000 16:33:20 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 14 Dec 2000 16:33:20 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.180) by mta1 with SMTP; 14 Dec 2000 16:33:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00498; Thu, 14 Dec 2000 13:50:57 +0100 Message-ID: <20001214135057.40255@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200012111026.LAA11495@mail.lundeneset.vgs.no> <20001212144950.10371@thrai.stud.uni-hannover.de> <00a701c0658f$e6eb8fa0$0200a8c0@schubert> X-Mailer: Mutt 0.84e In-Reply-To: <00a701c0658f$e6eb8fa0$0200a8c0@schubert>; from Christian Schubert on Thu, Dec 14, 2000 at 06:35:14AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 13:50:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: af76c07dbc9095b1a64b4b418b4fca48 Status: R X-Status: N On Thu, Dec 14, 2000 at 06:35:14AM +0100, Christian Schubert wrote:
[SPAM-blocking @ eGroups]
> That's quite wrong, eGroups can be configured to block postings from
> people not on the list, but as the ops are gone, there is no chance to
> do this (except eGroups would make e.g. YG list-op)

That's what I meant.  On the other hand, subscriber-only mode is a
royal pain in the a**, and I try to avoid it if possible.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 14 17:38:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01405 for ; Thu, 14 Dec 2000 22:18:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 22:18:45 +0100 (MET) Received: (qmail 32551 invoked by uid 0); 14 Dec 2000 17:07:47 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx18) with SMTP; 14 Dec 2000 17:07:47 -0000 X-eGroups-Return: sentto-1101623-1774-976811891-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 14 Dec 2000 16:38:25 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 16:38:08 -0000 Received: (qmail 50309 invoked from network); 14 Dec 2000 16:38:07 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 14 Dec 2000 16:38:07 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 14 Dec 2000 16:38:07 -0000 Received: (from mnet@localhost) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id RAA29653 for f-cpu@egroups.com; Thu, 14 Dec 2000 17:38:04 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 17:38:04 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] Who wants to make the index.html for f-cpu.seul.org ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4a9ed4b994a707d14c56d1f723f40462 Status: R X-Status: N hi,

>De: Steve Van der Hoeven <vanderho@essi.fr>
>Okay I will do some stuff in two weeks, just need some time to finish my exams

ok, thanks !

>> > Let's make something more functional for us.
>> if you like... at least something must exist so we can browse the site...
>... I should need to know what's on the site ...
well, nothing yet :-)
but you can start with some existing (and up to date) things
on f-cpu.de...

>> > Quick indexes to the manual,  source code milestones, tools source code
>> > links, members adresses, work plan (we don't need to invent twice the rop
>> > unit)... Not fancy, just static but quick and helpfull for us.
>> site map, public and "private" PHP3 notepads...
>do we need server side application?..
that can be useful sometimes...
> do we have the possibility for server side applications?
i have to check how, but this is certainly possible at seul.org.

>why notepads? would this not leed to a diffusion of information.... I like the emails,
>because it's a passive wait to be notified. And every thing is centrelized, no need to
>action three different process to stay in touch...

maybe the PHP can send an email to the mailing list as well ?
and, in the same way, maybe the mailing list could be stored
in a database there, and displayed online in HTML...

>> > We could base it on xml files... It's easier to maintain (separation of the
>> > informationa and presentation), and not much more to learn.
>> but who can do and compile XML ?
>Don't worry. My idea is to make it easier to maintain.
cool :-)

>> what matters is your will to do something good :-)
>My best.
great :-)))

i know that a lot of people here are frustrated that they
can't help at all. at least, now, they can :-)

>Steve
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 14 18:44:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01411 for ; Thu, 14 Dec 2000 22:18:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 14 Dec 2000 22:18:46 +0100 (MET) Received: (qmail 3709 invoked by uid 0); 14 Dec 2000 17:48:02 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx08) with SMTP; 14 Dec 2000 17:48:02 -0000 X-eGroups-Return: sentto-1101623-1775-976815911-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jk.egroups.com with NNFMP; 14 Dec 2000 17:45:17 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Dec 2000 17:45:10 -0000 Received: (qmail 14690 invoked from network); 14 Dec 2000 17:44:48 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 14 Dec 2000 17:44:48 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 14 Dec 2000 17:44:48 -0000 Received: (from mnet@localhost) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id SAA09776 for f-cpu@egroups.com; Thu, 14 Dec 2000 18:44:46 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 14 Dec 2000 18:44:46 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] Start A Career From Home Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 593fd999d56ce086851750c04b064a3b Status: R X-Status: N hi,
>That's what I meant.  On the other hand, subscriber-only mode is a
>royal pain in the a**, and I try to avoid it if possible.

if this helps, i have already gotten spam through
"private" FSF-bound mailing lists (gnu.org and april.org).
nobody is safe from that.

> Michael "Tired" Riepe
YG
eGroups Sponsor
Click Here!
From koiqii33@unipress.be Tue Jan 20 17:01:40 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00359 for ; Fri, 15 Dec 2000 23:31:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Dec 2000 23:31:59 +0100 (MET) Received: (qmail 17989 invoked by uid 0); 15 Dec 2000 09:33:24 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx02) with SMTP; 15 Dec 2000 09:33:24 -0000 X-eGroups-Return: sentto-1101623-1776-976872798-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 15 Dec 2000 09:33:21 -0000 X-Sender: koiqii33@unipress.be X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Dec 2000 09:33:17 -0000 Received: (qmail 14601 invoked from network); 15 Dec 2000 09:33:17 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 15 Dec 2000 09:33:17 -0000 Received: from unknown (HELO mail.stnorbfdn.mb.ca) (204.112.48.39) by mta3 with SMTP; 15 Dec 2000 10:34:22 -0000 Received: from tgi7t7 (d45.as0.hmtn.oh.voyager.net [207.90.123.109]) by mail.stnorbfdn.mb.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XP45NJR7; Fri, 15 Dec 2000 03:31:09 -0600 To: koiqii33@unipress.be Comments: Authenticated sender is Message-Id: <200012153038ZAA3182@dfrtghyu6t.stnorbfdn.mb.ca> X-eGroups-From: koiqii33@unipress.be (Charles) From: koiqii33@unipress.be MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Reply-To: f-cpu@egroups.com Subject: [f-cpu] Need I.D. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Fri, 15 Dec 00 09:33:24 GMT X-UIDL: d5c0b5b00b3eafb43b805fbfb71839f8 Status: R X-Status: N INTERNATIONAL DRIVER'S LICENSE

Need a new driver's license?

Too many points or other trouble?

Want a license that can never be suspended
or revoked?

Want ID for nightclubs or hotel check-in?

Avoid tickets, fines, and mandatory driver's
education.

Protect your privacy, and hide your identity.

The United Nations gave you the privilege to
drive freely throughout the world! (Convention
on International Road Traffic of September 19,
1949 & World Court Decision, The Hague,
Netherlands, January 21, 1958)

Take advantage of your rights.  Order a valid
International Driver's License that can never
be suspended or revoked.

Confidentiality assured.

CALL NOW!!!

1-937-586-9313












=================================
rem--  we4422909@yahoo.com
=================================

215296961017656530541906
s'be
From: koiq
eGroups Sponsor
Click Here!
From whygee@f-cpu.org Fri Dec 15 20:08:45 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00463 for ; Fri, 15 Dec 2000 23:33:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Dec 2000 23:33:10 +0100 (MET) Received: (qmail 9164 invoked by uid 0); 15 Dec 2000 19:14:46 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx16) with SMTP; 15 Dec 2000 19:14:46 -0000 X-eGroups-Return: sentto-1101623-1777-976907676-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 15 Dec 2000 19:14:45 -0000 X-Sender: yanng@relay1.mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Dec 2000 19:14:35 -0000 Received: (qmail 65010 invoked from network); 15 Dec 2000 19:14:34 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Dec 2000 19:14:34 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 15 Dec 2000 19:14:34 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA03205; Fri, 15 Dec 2000 11:14:33 -0800 (PST) Received: from zeus (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YZRN0GJG; Fri, 15 Dec 2000 20:14:31 +0100 Received: by zeus (SMI-8.6/CF5.38L) id UAA07838; Fri, 15 Dec 2000 20:08:45 +0100 Message-Id: <200012151908.UAA07838@zeus> Apparently-To: f-cpu@egroups.com From: whygee@f-cpu.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Dec 2000 20:08:45 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Quality... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 46751abda9e1e293adce9cc0e0bf8b35 Status: R X-Status: N Hello,

I have not yet examined Michael's distro, but
i have found some minutes to write the following text.
It is located in the root directory of my own package.
It is a good reading and it will require some update,
but it's a good start. And yes, it breaks with :
"release soon, release alot, release buggy, ..."
Enjoy the reading and please report errors.
YG


QUALITY.TXT, (C) Yann GUIDON Tue Dec 12 20:08:29 MET 2000


Quality policies and some helpful advices


I must recognize that i'm not the best coder of the world.
My memory is limited and I sometimes face difficult compromises
that affect the code i write, whatever the langage.

We all know that a good documentation and easy to use SW are
more sometimes more important than the speed or usefulness
improvements. For example, you just discovered this text and
you decided to read it. You have opened it in a text editor
of your choice, assuming (from the .TXT file extension) that
it is in ASCII format. You now enjoy its insightful contents
and it all lasted only a few seconds :-)

The same goes for source code.


The goal of this document is not to "rule" but to "guide"
coders, whatever their project. When a package must be released,
it is often very long to check the consistency and status
of every file. Even though it's not considered as a "noble" task,
each one should consider spending a large amount of time
writing comments and READMEs.

It is not possible either to spend all you time writing documents,
but please consider the total amount of time that will be spent
by people trying to understand your code. If you code all the time,
you don't document, and if you write comments all the time, there
is no code written in the end.

That is why the document must be written while programming.
It doesn't take much time at all because it is an integral part
of the coding activity and it follows closely your ideas of the
moment. For one ASCII character of code, there should be in
average one character that describes what is being done. This
average concerns the whole file. This kind of documentation is very
helpful, not only for the newcomer, but for the coder himself,
because it helps him debug the code. When the code is ready and
ready for distribution, an external file (ie HTML) can be written,
describing the overal architecture of the code and the basic
principles.

I consider a program source file as a story that should be
understood with the first reading. A source code must tell you a
story : good comments with a good style (not "only" a descriptive
comment) can explain what is really going on. Old good
spaghetti style is not good. Not because it is spaghetti,
not because it makes use of direct jumps or labels (we always
need some from time to time) but because the structure doesn't
appear during a linear reading.


Now, here are some practical, everyday advices :

- When creating or updating a file, always put the copyright, the
author's (you) name, and the date. I usually type "date"
on a Un*x console and then cutn'paste it in emacs.

- indicate as much hints as possible, even though it ends up
with pages of comments. they'll be sorted later if they're
useful. Removing comments might lead to some misunderstanding
with others.

- here are some standard hints, after the date and name :
* type of modification : several lines are often necessary
(unless you only mistyped a character...)
* name of the file. It might be lost when sent in an email
or when printed, depending on the software (do not think that
because your SW does it for you, the others will have it too).
* compilation command, or indication of the makefile.
This shows what flags and compiler are needed.
* if it is included in another source, name the file.
* Portability across platforms : indicate what tool is used
(ie a certain flavour of)
or if there are incompatible features (ie: a particular
data alignment/ordering/organisation, CPU-dependent structures...)
* Link to documentation : in the directory or in the package,
or on the web, etc...
* whether is is tested, how and in what circumstances (platforms,
dataset, coverage...)
* Status of the file : something like the following notes
-> just created,
-> not yet working
-> just working
-> enhancements
-> satisfying
-> a bug was discovered somewhere...
-> foolproofed
-> don't touch
-> locally released
-> ready for public release

The hints apply for a sing file, a directory, a package...
Note that the

These hints are highly subjective and are influenced by
everyone's standards. This evaluation can be summarized in a single
number, from 0 to 10.
* 0 corresponds to a rather inexistent or empty package
* 1 : the first functions are written
* 2 : some stuffs are starting to work together
* 3 : addition of some test vectors and testbenches
* 4 : under debug
* 5 : enhanced
* 6 : all features are available
* 7 : correctly working
* 8 : fully documented
* 9 : exhaustively tested across many platforms
* 10 means that it can't be enhanced anymore.
Of course this is only indicative about the general status.
The mark can vary a lot during the life of the project.


The goal of thes hints and subjective evaluations is to help
maintain and bundle the packages. A directory containing
low-evaluated files will not be included in a package.

Ideally, a package should only contain "10" files but in
practice and in a closed-room development environment,
some factors are not revelant. A F-CPU package would average
8 for practical reasons (time, platforms, prototyping/evaluation
only etc).


Today (dec. 2000), all the files of the F-CPU project don't
comply with this policy. Before the distribution grows out of
control, it becomes necessary to closely examine, document
and test all the source code. Then, only "satisfying" files
or directories would be included in a certain package (as several
F-CPU packages are possible).

                       -----------------

I hope that this text has helped you understand the importance
of individual quality evaluation. Next time you finish a software,
don't think that it is ok : higher quality means less time
spent during debug sessions and packaging. It also means more
attention on the code writing : correctly indenting a source file
is not enough.

Please spend more time explaining what you do (on the file).
Remember that few good working code files are better than a whole
bunch of unorganized, unsorted, undocumented files that don't
work. The first has more value because it can be easily compiled,
executed, modified and redistributed.
eGroups Sponsor
Click Here!
From whygee@f-cpu.org Fri Dec 15 20:32:43 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00481 for ; Fri, 15 Dec 2000 23:33:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 15 Dec 2000 23:33:16 +0100 (MET) Received: (qmail 23654 invoked by uid 0); 15 Dec 2000 19:39:13 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx03) with SMTP; 15 Dec 2000 19:39:13 -0000 X-eGroups-Return: sentto-1101623-1778-976909114-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 15 Dec 2000 19:39:10 -0000 X-Sender: yanng@relay1.mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Dec 2000 19:38:34 -0000 Received: (qmail 35797 invoked from network); 15 Dec 2000 19:38:33 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Dec 2000 19:38:33 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 15 Dec 2000 19:38:33 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA06016; Fri, 15 Dec 2000 11:38:31 -0800 (PST) Received: from zeus (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YZRN0GJX; Fri, 15 Dec 2000 20:38:30 +0100 Received: by zeus (SMI-8.6/CF5.38L) id UAA12839; Fri, 15 Dec 2000 20:32:43 +0100 Message-Id: <200012151932.UAA12839@zeus> Apparently-To: f-cpu@egroups.com From: whygee@f-cpu.org MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Dec 2000 20:32:43 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-cpu.de design update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: c7c3ce34636ca2981bfe12ea15168772 Status: R X-Status: N hello,
i have just uploaded some file to
http://www.f-cpu.de/design/
You'll find some snapshots and fresher files,
unfortunately not much from my side.

Have fun,
YG
eGroups Sponsor
Click Here!
From Jeff Davies Sat Dec 16 00:34:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01712 for ; Sat, 16 Dec 2000 06:17:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Dec 2000 06:17:56 +0100 (MET) Received: (qmail 10524 invoked by uid 0); 15 Dec 2000 23:43:42 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx03) with SMTP; 15 Dec 2000 23:43:42 -0000 X-eGroups-Return: sentto-1101623-1779-976923695-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 15 Dec 2000 23:41:58 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Dec 2000 23:41:35 -0000 Received: (qmail 18918 invoked from network); 15 Dec 2000 23:41:34 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 Dec 2000 23:41:34 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta1 with SMTP; 15 Dec 2000 23:41:34 -0000 Received: from modem-46.neptunium.dialup.pol.co.uk ([62.136.66.46] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 1474Tk-00087g-00 for f-cpu@egroups.com; Fri, 15 Dec 2000 23:41:33 +0000 Message-ID: <3A3AAA9E.8F40437E@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <200012151932.UAA12839@zeus> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 15 Dec 2000 23:34:54 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu.de design update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90e1af7daebf42f7c33a9c8a0c371b93 Status: R X-Status: N To facilitate easy entry for VHDL coders onto the project:

Can someone write functional description for the units comprising the fcpu
(probably a single paragraph -
for example: enough for someone who can generally design TLBs to know how to
make the DTLB for
FCPU):

Imul
Idiv
Add/Sub (a bit more detail like what happens to carry/underflow
is there one calculated etc).
Shuffler (perhaps I can volunteer for this since we spent such a long
time talking about it).
Inc/Cmp/Min
Xbar (1 and 2)
DTLB
ITLB
LSU
Tags
fetch predict logic
Tags
SRs + monitors
Registers (eg: why 2 bus in 3 out?)
Scoreboard
Decoder
Fetcher
ECC (look up in textbook for general form
and apply).
DCache
ICache
Tags-LRU

Bundled together, the aggregation of these will be nearly a full spec (in
terms of what's required by a VHDL dude)
to code the FCPU.
Apologies if this info is already out there and I am ignorant of it.
Jeff Davies






whygee@f-cpu.org wrote:

> hello,
> i have just uploaded some file to
> http://www.f-cpu.de/design/
> You'll find some snapshots and fresher files,
> unfortunately not much from my side.
>
> Have fun,
> YG
>
eGroups Sponsor
Click Here!
From Michael Riepe Sat Dec 16 01:36:34 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01727 for ; Sat, 16 Dec 2000 06:18:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Dec 2000 06:18:00 +0100 (MET) Received: (qmail 7995 invoked by uid 0); 16 Dec 2000 00:36:55 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx05) with SMTP; 16 Dec 2000 00:36:55 -0000 X-eGroups-Return: sentto-1101623-1780-976927010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 16 Dec 2000 00:36:54 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Dec 2000 00:36:49 -0000 Received: (qmail 14835 invoked from network); 16 Dec 2000 00:36:49 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 16 Dec 2000 00:36:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.170) by mta2 with SMTP; 16 Dec 2000 00:36:40 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02068; Sat, 16 Dec 2000 01:36:34 +0100 Message-ID: <20001216013634.31735@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200012151932.UAA12839@zeus> <3A3AAA9E.8F40437E@llandre.freeserve.co.uk> X-Mailer: Mutt 0.84e In-Reply-To: <3A3AAA9E.8F40437E@llandre.freeserve.co.uk>; from Jeff Davies on Fri, Dec 15, 2000 at 11:34:54PM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Dec 2000 01:36:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu.de design update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c688f72c9d94a3d6df76472fcbdd55f3 Status: R X-Status: N On Fri, Dec 15, 2000 at 11:34:54PM +0000, Jeff Davies wrote:
> To facilitate easy entry for VHDL coders onto the project:
>
> Can someone write functional description for the units comprising the fcpu
> (probably a single paragraph -
> for example: enough for someone who can generally design TLBs to know how to
> make the DTLB for
> FCPU):

What exactly do you need to know?

> Imul
> Idiv
> Add/Sub (a bit more detail like what happens to carry/underflow
> is there one calculated etc).
> Shuffler (perhaps I can volunteer for this since we spent such a long
> time talking about it).
> Inc/Cmp/Min

What these units do is pretty well-documented in the F-CPU manual.
How they do it is the implementor's choice -- there's always more
than one way.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Jeff Davies Sat Dec 16 02:18:48 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01751 for ; Sat, 16 Dec 2000 06:18:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 16 Dec 2000 06:18:04 +0100 (MET) Received: (qmail 31341 invoked by uid 0); 16 Dec 2000 02:16:22 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx05) with SMTP; 16 Dec 2000 02:16:22 -0000 X-eGroups-Return: sentto-1101623-1781-976929930-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mk.egroups.com with NNFMP; 16 Dec 2000 01:26:21 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Dec 2000 01:25:29 -0000 Received: (qmail 35995 invoked from network); 16 Dec 2000 01:25:29 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 16 Dec 2000 01:25:29 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta1 with SMTP; 16 Dec 2000 01:25:28 -0000 Received: from modem-46.neptunium.dialup.pol.co.uk ([62.136.66.46] helo=llandre.freeserve.co.uk) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14766J-00020n-00 for f-cpu@egroups.com; Sat, 16 Dec 2000 01:25:27 +0000 Message-ID: <3A3AC2F8.EDCBC844@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <200012151932.UAA12839@zeus> <3A3AAA9E.8F40437E@llandre.freeserve.co.uk> <20001216013634.31735@thrai.stud.uni-hannover.de> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Dec 2000 01:18:48 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu.de design update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2c9449b83db7b3defc9140d71fad37f0 Status: R X-Status: N Well I guess a list of in/out nodes, verbal description. Like I said, maybe I
ought to read the manual
a bit more.
kind of thing I had in mind was:

Imul:
  Inputs:
    two off 64 bit words, unsigned integers.
    2 control lines, enable and output tristate buffer enable.
  Outputs:
    one off 64 bit word, unsigned integer.
    carry is ignored
  Function:
    Integer Multiply inputs in one quadrant (ie no handling of negative numbers).

Jeff Davies


Michael Riepe wrote:

> On Fri, Dec 15, 2000 at 11:34:54PM +0000, Jeff Davies wrote:
> > To facilitate easy entry for VHDL coders onto the project:
> >
> > Can someone write functional description for the units comprising the fcpu
> > (probably a single paragraph -
> > for example: enough for someone who can generally design TLBs to know how to
> > make the DTLB for
> > FCPU):
>
> What exactly do you need to know?
>
> > Imul
> > Idiv
> > Add/Sub (a bit more detail like what happens to carry/underflow
> > is there one calculated etc).
> > Shuffler (perhaps I can volunteer for this since we spent such a long
> > time talking about it).
> > Inc/Cmp/Min
>
> What these units do is pretty well-documented in the F-CPU manual.
> How they do it is the implementor's choice -- there's always more
> than one way.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Michael Riepe Sat Dec 16 02:43:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04074 for ; Sun, 17 Dec 2000 02:28:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Dec 2000 02:28:15 +0100 (MET) Received: (qmail 29107 invoked by uid 0); 16 Dec 2000 14:36:34 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx07) with SMTP; 16 Dec 2000 14:36:34 -0000 X-eGroups-Return: sentto-1101623-1782-976977390-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 16 Dec 2000 14:36:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Dec 2000 14:36:29 -0000 Received: (qmail 33659 invoked from network); 16 Dec 2000 14:36:29 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 16 Dec 2000 14:36:28 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.50) by mta3 with SMTP; 16 Dec 2000 15:37:32 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02319; Sat, 16 Dec 2000 02:43:52 +0100 Message-ID: <20001216024351.37928@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200012151932.UAA12839@zeus> <3A3AAA9E.8F40437E@llandre.freeserve.co.uk> <20001216013634.31735@thrai.stud.uni-hannover.de> <3A3AC2F8.EDCBC844@llandre.freeserve.co.uk> X-Mailer: Mutt 0.84e In-Reply-To: <3A3AC2F8.EDCBC844@llandre.freeserve.co.uk>; from Jeff Davies on Sat, Dec 16, 2000 at 01:18:48AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 16 Dec 2000 02:43:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu.de design update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e3a22874eafe1d45073cf509a689ab4f Status: R X-Status: N On Sat, Dec 16, 2000 at 01:18:48AM +0000, Jeff Davies wrote:
> Well I guess a list of in/out nodes, verbal description. Like I said, maybe I
> ought to read the manual
> a bit more.
> kind of thing I had in mind was:
>
> Imul:
>   Inputs:
>     two off 64 bit words, unsigned integers.
>     2 control lines, enable and output tristate buffer enable.
>   Outputs:
>     one off 64 bit word, unsigned integer.
>     carry is ignored
>   Function:
>     Integer Multiply inputs in one quadrant (ie no handling of negative numbers).

Looks like the lengthy comment I added in eu_asu/iadd.vhdl should be
sufficient for that unit.  I can add similar descriptions to my other
units, too -- and if there's still something missing, please tell me.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Yann Guidon Sun Dec 17 03:52:20 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA04639 for ; Sun, 17 Dec 2000 06:55:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 17 Dec 2000 06:55:29 +0100 (MET) Received: (qmail 26229 invoked by uid 0); 17 Dec 2000 02:47:01 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx04) with SMTP; 17 Dec 2000 02:47:01 -0000 X-eGroups-Return: sentto-1101623-1783-977021211-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 17 Dec 2000 02:46:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Dec 2000 02:46:51 -0000 Received: (qmail 26298 invoked from network); 17 Dec 2000 02:46:51 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Dec 2000 02:46:51 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 17 Dec 2000 03:47:56 -0000 Received: from f-cpu.org (nas1-237.aub.club-internet.fr [195.36.150.237]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA12182 for ; Sun, 17 Dec 2000 03:46:47 +0100 (MET) Message-ID: <3A3C2A64.675125C7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Dec 2000 03:52:20 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2423558ebdf7a52eaacf46cac82a934e Status: R X-Status: N hello,

most of this message concerns Michael,
i've looked at your most recent package and remarked
some things.
- there's a version clash between my version of the eu_asu directory
and your version. in particular, i would like to simplify some
details in your implementation of your ASU wrapper.
- I've included the imul unit but i'll need a good doc about it :-)
- i'm ok to move the batch files into a special directory,
although the paths are getting messy. We'll have to organise this !!!
- we still need a decent INC and SHL unit.

finally, we'll have to apply the quality check measures
before the package grows out of control. Michael is a big contributor
and it would be good if he added some hints, readmes and other
suggestions found in quality.txt.

another snapshot will appear soon on f-cpu.de. please comment,
take into account and suggest enhancements. don't be shy ! :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Michael Riepe Sun Dec 17 18:15:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00420 for ; Mon, 18 Dec 2000 23:35:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:35:55 +0100 (MET) Received: (qmail 19201 invoked by uid 0); 17 Dec 2000 22:12:13 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx17) with SMTP; 17 Dec 2000 22:12:13 -0000 X-eGroups-Return: sentto-1101623-1784-977091111-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 17 Dec 2000 22:12:11 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Dec 2000 22:11:51 -0000 Received: (qmail 76942 invoked from network); 17 Dec 2000 22:11:49 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 17 Dec 2000 22:11:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.60) by mta3 with SMTP; 17 Dec 2000 23:12:13 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01201; Sun, 17 Dec 2000 18:15:15 +0100 Message-ID: <20001217181515.18559@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A3C2A64.675125C7@f-cpu.org>; from Yann Guidon on Sun, Dec 17, 2000 at 03:52:20AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Dec 2000 18:15:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fdcc53154b1bac59f932738c63df0c04 Status: R X-Status: N On Sun, Dec 17, 2000 at 03:52:20AM +0100, Yann Guidon wrote:

> most of this message concerns Michael,
> i've looked at your most recent package and remarked
> some things.
> - there's a version clash between my version of the eu_asu directory
> and your version. in particular, i would like to simplify some
> details in your implementation of your ASU wrapper.

What exactly?

> - I've included the imul unit but i'll need a good doc about it :-)

Good docs don't write themselves, unfortunately ;(

> - i'm ok to move the batch files into a special directory,
> although the paths are getting messy. We'll have to organise this !!!

Yep.  My idea was that the batch files should have the same name as
the directory they're responsible for, and that you can select a
subdirectory that corresponds to the tools you use (by copying its
contents or setting the PATH variable appropriately).

> - we still need a decent INC and SHL unit.

Erik is working on INC, IIRC.

> finally, we'll have to apply the quality check measures
> before the package grows out of control. Michael is a big contributor
> and it would be good if he added some hints, readmes and other
> suggestions found in quality.txt.

"Time is nature's way of stopping everything happening all at once".

I do not agree with the idea that code and documentation should be written
at the same time.  Keeping redundant information uptodate all the time
is a lot of additional work.  Even worse, it decreases my productivity
dramatically -- switching between `code mode' and `comment mode' is
like context switches in a CPU; I have to purge my tiny mental caches
and load another `program' again and again.

Expressing technical things precisely in natural languages is quite
difficult if you want the reader to really understand.  IMHO it's much
harder than coding itself, and it requires a different way of thinking.
Being interrupted all the time and being forced to change both my point
of view and the language I write in doesn't help at all.  It's an order
of magnitude harder than switching between languages at the same `level',
e.g. German and English -- or C, VHDL, Lisp and Bourne Shell.

On the other hand, I refuse to add `alibi comments' to my code --
e.g. silly phrases like `let A become the XOR of B and C' after each
assignment.  This doesn't help at all.  I'd rather remove all comments
and let the source code speak for itself; after all, source code *is*
documentation -- if you're able to read and understand it ;)

One more point is that useful documentation needs pictures and other
graphical elements that you can't put into a source file.  For a unit as
complex as the multiplier, `ASCII art' isn't sufficient -- I need high
resolution color graphics to visualize some of the more complex aspects
(e.g. the handling of SIMD, MAC and signed/unsigned modes).

For the final public release, a separate, automagically created, browsable
(HTML) version of the source would be nice -- including hyperlinks to the
documentation, the components used (click on the instantiation statement
or component declaration and the browser will show the corresponding
entity) and so on.  But I have to write the code first.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From jeff@llandre.freeserve.co.uk Sun Dec 17 23:08:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00423 for ; Mon, 18 Dec 2000 23:35:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:35:57 +0100 (MET) Received: (qmail 17553 invoked by uid 0); 17 Dec 2000 22:13:05 -0000 Received: from fj.egroups.com (64.211.240.231) by 10.1.4.106 (mx06) with SMTP; 17 Dec 2000 22:13:05 -0000 X-eGroups-Return: sentto-1101623-1785-977091173-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fj.egroups.com with NNFMP; 17 Dec 2000 22:13:05 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Dec 2000 22:12:53 -0000 Received: (qmail 99337 invoked from network); 17 Dec 2000 22:12:53 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Dec 2000 22:12:53 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 17 Dec 2000 23:13:58 -0000 Received: from modem-249.cobalt.dialup.pol.co.uk ([62.136.26.249] helo=62.136.26.249) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 147m30-0006mi-00 for f-cpu@egroups.com; Sun, 17 Dec 2000 22:12:51 +0000 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Dec 2000 22:08 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] turing machine Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 287ee060fe3c5298bef4a39514bdb3e9 Status: R X-Status: N A turing machine! Apparently all software written to date
for it occupies 26k bytes.
There is a java implementation based on it which is tiny,
runs on 8 bit cpus and is very very fast.
The details are light, but if this is real, this could herald a
new dawn.
checkout  www.180sw.com

Jeff Davies
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From "Gregory Junker" Mon Dec 18 01:52:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00435 for ; Mon, 18 Dec 2000 23:36:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:36:01 +0100 (MET) Received: (qmail 17872 invoked by uid 0); 18 Dec 2000 00:53:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx14) with SMTP; 18 Dec 2000 00:53:29 -0000 X-eGroups-Return: sentto-1101623-1786-977100800-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 18 Dec 2000 00:53:27 -0000 X-Sender: gjunker@shockwaveaudio.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 00:53:20 -0000 Received: (qmail 71258 invoked from network); 18 Dec 2000 00:53:19 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 18 Dec 2000 00:53:19 -0000 Received: from unknown (HELO oh01ap01.shockwaveaudio.com) (216.23.14.16) by mta3 with SMTP; 18 Dec 2000 01:54:24 -0000 To: Message-ID: content-class: urn:content-classes:message Thread-Topic: [f-cpu] turing machine Thread-Index: AcBojMw8eHcfcqMQTXKIu1G/3LeXwg== X-MimeOLE: Produced By Microsoft Exchange V6.0.4208.0 From: "Gregory Junker" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 17 Dec 2000 19:52:31 -0500 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] turing machine Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 189f9426c6a7aba17ce457dac065747b Status: R X-Status: N did they perfect cold fusion while they were at it? Details were light
on that, too...

inquiring minds... :)

greg


-----Original Message-----
From: jeff@llandre.freeserve.co.uk [mailto:jeff@llandre.freeserve.co.uk]
Sent: Sunday, December 17, 2000 5:13 PM
To: f-cpu@egroups.com
Subject: [f-cpu] turing machine


A turing machine! Apparently all software written to date
for it occupies 26k bytes.
There is a java implementation based on it which is tiny,
runs on 8 bit cpus and is very very fast.
The details are light, but if this is real, this could herald a
new dawn.
checkout  www.180sw.com

Jeff Davies



eGroups Sponsor     

<http://rd.yahoo.com/M=168680.1256385.2848396.908943/D=egroupmail/S=1700
005378:N/A=540658/?http://www.net2phone.com/jump/campaign> Paid
Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!     


eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Yann Guidon Mon Dec 18 03:23:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00444 for ; Mon, 18 Dec 2000 23:36:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:36:32 +0100 (MET) Received: (qmail 26114 invoked by uid 0); 18 Dec 2000 02:18:16 -0000 Received: from fj.egroups.com (64.211.240.231) by 10.1.4.111 (mx11) with SMTP; 18 Dec 2000 02:18:16 -0000 X-eGroups-Return: sentto-1101623-1787-977105886-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 18 Dec 2000 02:18:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 02:18:05 -0000 Received: (qmail 78188 invoked from network); 18 Dec 2000 02:18:05 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Dec 2000 02:18:05 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 18 Dec 2000 02:18:05 -0000 Received: from f-cpu.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA12124 for ; Mon, 18 Dec 2000 03:17:58 +0100 (MET) Message-ID: <3A3D7524.8F0A24D8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> <20001217181515.18559@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 03:23:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab0953e517e67987d1af7f1190a67222 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Dec 17, 2000 at 03:52:20AM +0100, Yann Guidon wrote:
> > most of this message concerns Michael,
> > i've looked at your most recent package and remarked
> > some things.
> > - there's a version clash between my version of the eu_asu directory
> > and your version. in particular, i would like to simplify some
> > details in your implementation of your ASU wrapper.
> What exactly?

your parameter w is not very well defined.
i think that we should characterize it more globally
in the ISA. for example : create a new characteristic width
parameter called "MAX_CHUNK_SIZE", so it can be read in the
SR too.

> > - I've included the imul unit but i'll need a good doc about it :-)
> Good docs don't write themselves, unfortunately ;(
yup. it's only a faithless prayer...

> > - i'm ok to move the batch files into a special directory,
> > although the paths are getting messy. We'll have to organise this !!!
> Yep.  My idea was that the batch files should have the same name as
> the directory they're responsible for, and that you can select a
> subdirectory that corresponds to the tools you use (by copying its
> contents or setting the PATH variable appropriately).
it should have been written down on a file, so i could guess it more easily ;-)
so what do you decide ? $PATH or copy ? it's getting very complex.
we have changed the directory structure several times and now the links
are almost all broken.

> > - we still need a decent INC and SHL unit.
> Erik is working on INC, IIRC.
i'll try to make a "YG" INC and finish that damn Icache,
but someone must care about the SHL. we'll need a real professional
(or something like that ;-D) because a SIMD 64-bit shift/rotate unit
is very difficult to make correctly. some things i see at work and
in books indicate that we will face some troubles...

> > finally, we'll have to apply the quality check measures
> > before the package grows out of control. Michael is a big contributor
> > and it would be good if he added some hints, readmes and other
> > suggestions found in quality.txt.
>
> "Time is nature's way of stopping everything happening all at once".
hmmm Darwin ? :-)

> I do not agree with the idea that code and documentation should be written
> at the same time.  Keeping redundant information uptodate all the time
> is a lot of additional work.  Even worse, it decreases my productivity
> dramatically -- switching between `code mode' and `comment mode' is
> like context switches in a CPU; I have to purge my tiny mental caches
> and load another `program' again and again.
i agree that it is not easy to code like mad and make perfectly maintainable
code. i guess that the current status will last some time until we rewrite
everything and clean/update/document all the files.

> Expressing technical things precisely in natural languages is quite
> difficult if you want the reader to really understand.  IMHO it's much
> harder than coding itself, and it requires a different way of thinking.
> Being interrupted all the time and being forced to change both my point
> of view and the language I write in doesn't help at all.  It's an order
> of magnitude harder than switching between languages at the same `level',
> e.g. German and English -- or C, VHDL, Lisp and Bourne Shell.
i can switch from german to english at will. well, i've practiced,
so it doesn't count ;-)
About the interruption : this is probably the wrong way to see this.
in fact, the comments must be a continuation of what you have
in mind, or what is expected to happen. you CAN't write a whole tutorial
for every line, so just drop a phrase about what goes on in your head.
it only takes a few seconds for me and it helps me give a new point
of view for the reader.

> On the other hand, I refuse to add `alibi comments' to my code --
> e.g. silly phrases like `let A become the XOR of B and C' after each
> assignment.  This doesn't help at all.  I'd rather remove all comments
> and let the source code speak for itself; after all, source code *is*
> documentation -- if you're able to read and understand it ;)
some people can't, and a lot of circumstances don't allow this :
for example, a CRC algo fits in a few lines but is very hard to explain
with few lines. the goal is not to comment obvious code (like the example
you gave) but to give a "higher level of understanding". For example,
some hand-optimized codes can pack data and the side effects can be
larger than expected for someone who first reads the code.

> One more point is that useful documentation needs pictures and other
> graphical elements that you can't put into a source file.  For a unit as
> complex as the multiplier, `ASCII art' isn't sufficient -- I need high
> resolution color graphics to visualize some of the more complex aspects
> (e.g. the handling of SIMD, MAC and signed/unsigned modes).
that is for the external doc. of course.

> For the final public release, a separate, automagically created, browsable
> (HTML) version of the source would be nice -- including hyperlinks to the
> documentation, the components used (click on the instantiation statement
> or component declaration and the browser will show the corresponding
> entity) and so on.  But I have to write the code first.
sure.
i also should write more code too, but the current set of files
must be clean before i start to add other stuffs, otherwise it
will be only a huge bunch of bytes that noone will want to see.
it's ok to not release often, but then it should be better than that....

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From "Richard E.Hartney" Mon Dec 18 10:18:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00471 for ; Mon, 18 Dec 2000 23:36:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:36:39 +0100 (MET) Received: (qmail 10549 invoked by uid 0); 18 Dec 2000 09:15:01 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx08) with SMTP; 18 Dec 2000 09:15:01 -0000 X-eGroups-Return: sentto-1101623-1788-977130893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 18 Dec 2000 09:14:54 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 09:14:46 -0000 Received: (qmail 94388 invoked from network); 18 Dec 2000 09:14:46 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Dec 2000 09:14:46 -0000 Received: from unknown (HELO mail0.lig.bellsouth.net) (205.152.0.90) by mta1 with SMTP; 18 Dec 2000 09:14:45 -0000 Received: from 0018728164 (host-209-215-24-214.bix.bellsouth.net [209.215.24.214]) by mail0.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id EAA04218; Mon, 18 Dec 2000 04:14:41 -0500 (EST) Message-ID: <000801c068d3$777f6640$d618d7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 03:18:18 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Documentation Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C068A1.2ADCA320" X-UIDL: 801bae9edfec880f57759e59dec473cc Status: R X-Status: N ------=_NextPart_000_0005_01C068A1.2ADCA320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Although I am no longer on the F-CPU list; I am still browsing. The TIPS Operating System I am capturing is extremely well documented. Eac= h Relocatable major Routine is preceded with a description of intent. Each= line of Code has a Comment. This was deviated by only ONE so-called brill= iant mind from MIT who refused to follow even minimal direction. Fortunate= ly he didn't write or debug very much code.=20=20 This person was primarily a hardware designer. One of his tasks was to des= ign a Modem Interface that was to include CRC generation and LRC checking. = He was unable to do either so he volunteered to write the related software= without telling our Section Head of his failures. The resulting code had = virtually no meaningful comments. Fortunately I won't be using HIS code an= yway because of the high performance required of our resulting system. If the shoe fits - wear it. Do it while its fresh on your mind - not later and ask yourself - what was = I doing?? Sincerely Richard E. Hartney Research Director Erin Greene & Associates email - rhartney@bellsouth.net ------=_NextPart_000_0005_01C068A1.2ADCA320 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Although I am no longer on the F-CPU list;= I am=20 still browsing.
 
The TIPS Operating System I am capturing i= s=20 extremely well documented.  Each Relocatable major Routine is preceded= with=20 a description of intent.  Each line of Code has a Comment.  This = was=20 deviated by only ONE so-called brilliant mind from MIT who refused to follo= w=20 even minimal direction.  Fortunately he didn't write or debug very muc= h=20 code. 
 
This person was primarily a hardware=20 designer.  One of his tasks was to design a Modem Interface that was t= o=20 include CRC generation and LRC checking.  He was unable to do either s= o he=20 volunteered to write the related software without telling our Section Head = of=20 his failures.  The resulting code had virtually no meaningful=20 comments.  Fortunately I won't be using HIS code anyway because of the= high=20 performance required of our resulting system.
 
If the shoe fits - wear it.
 
Do it while its fresh on your mind - not l= ater and=20 ask yourself - what was I doing??
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
email - rhartney@bellsouth.net

eGroups Sponsor=
3D"Paid=
Paid Net2phone Adver= tisement - Click Here!
------=_NextPart_000_0005_01C068A1.2ADCA320-- From Michael Riepe Mon Dec 18 07:37:15 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00507 for ; Mon, 18 Dec 2000 23:36:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:36:52 +0100 (MET) Received: (qmail 14353 invoked by uid 0); 18 Dec 2000 13:15:34 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx08) with SMTP; 18 Dec 2000 13:15:34 -0000 X-eGroups-Return: sentto-1101623-1789-977145326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 18 Dec 2000 13:15:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 13:15:25 -0000 Received: (qmail 56555 invoked from network); 18 Dec 2000 13:15:25 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Dec 2000 13:15:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.106) by mta1 with SMTP; 18 Dec 2000 13:15:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id HAA03426; Mon, 18 Dec 2000 07:37:15 +0100 Message-ID: <20001218073715.61147@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> <20001217181515.18559@thrai.stud.uni-hannover.de> <3A3D7524.8F0A24D8@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A3D7524.8F0A24D8@f-cpu.org>; from Yann Guidon on Mon, Dec 18, 2000 at 03:23:32AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 07:37:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2fe5a3e877f53c220b965f97b8c04e8a Status: R X-Status: N On Mon, Dec 18, 2000 at 03:23:32AM +0100, Yann Guidon wrote:

> > > - there's a version clash between my version of the eu_asu directory
> > > and your version. in particular, i would like to simplify some
> > > details in your implementation of your ASU wrapper.
> > What exactly?
>
> your parameter w is not very well defined.

It's 32 if UMAX equals 32, and 64 if UMAX is a multiple of 64.
Other cases are undefined.

> i think that we should characterize it more globally
> in the ISA. for example : create a new characteristic width
> parameter called "MAX_CHUNK_SIZE", so it can be read in the
> SR too.

Good idea.

> > > - I've included the imul unit but i'll need a good doc about it :-)
> > Good docs don't write themselves, unfortunately ;(
> yup. it's only a faithless prayer...

Don't worry, you *will* get that documentation (unless I drop dead
before I can write it, but I really don't intend to ;).  I hope to be
able to use the days after Xmas when you guys are visiting Berlin...

> > > - i'm ok to move the batch files into a special directory,
> > > although the paths are getting messy. We'll have to organise this !!!
> > Yep.  My idea was that the batch files should have the same name as
> > the directory they're responsible for, and that you can select a
> > subdirectory that corresponds to the tools you use (by copying its
> > contents or setting the PATH variable appropriately).
> it should have been written down on a file, so i could guess it more easily ;-)
> so what do you decide ? $PATH or copy ? it's getting very complex.
> we have changed the directory structure several times and now the links
> are almost all broken.

Setting PATH is better if you're going to change tools now and then.

> > > - we still need a decent INC and SHL unit.
> > Erik is working on INC, IIRC.
> i'll try to make a "YG" INC and finish that damn Icache,
> but someone must care about the SHL. we'll need a real professional
> (or something like that ;-D) because a SIMD 64-bit shift/rotate unit
> is very difficult to make correctly. some things i see at work and
> in books indicate that we will face some troubles...

What's it going to be, a barrel shifter or a pass gate array (aka
`crossbar for bits')?

> > > finally, we'll have to apply the quality check measures
> > > before the package grows out of control. Michael is a big contributor
> > > and it would be good if he added some hints, readmes and other
> > > suggestions found in quality.txt.
> >
> > "Time is nature's way of stopping everything happening all at once".
> hmmm Darwin ? :-)

A line from a song from a british band whose name I have forgotten ten
years ago.

[...]
> i can switch from german to english at will. well, i've practiced,
> so it doesn't count ;-)

Most germans can speak German and English at the same time... the result
is called `Denglish' or `Neudeutsch' ;)

But can you switch from German to Lisp, too?
(might (become 'difficult) 'sometimes)
(not (thinkp 'you))

> About the interruption : this is probably the wrong way to see this.
> in fact, the comments must be a continuation of what you have
> in mind, or what is expected to happen. you CAN't write a whole tutorial
> for every line, so just drop a phrase about what goes on in your head.
> it only takes a few seconds for me and it helps me give a new point
> of view for the reader.

Perhaps the problem is that there is nothing going on in my head,
except code.  I *knew* this would happen one day... ;)

> > On the other hand, I refuse to add `alibi comments' to my code --
> > e.g. silly phrases like `let A become the XOR of B and C' after each
> > assignment.  This doesn't help at all.  I'd rather remove all comments
> > and let the source code speak for itself; after all, source code *is*
> > documentation -- if you're able to read and understand it ;)
> some people can't, and a lot of circumstances don't allow this :
> for example, a CRC algo fits in a few lines but is very hard to explain
> with few lines. the goal is not to comment obvious code (like the example
> you gave) but to give a "higher level of understanding". For example,
> some hand-optimized codes can pack data and the side effects can be
> larger than expected for someone who first reads the code.

Non-trivial things like these need a line or two, right.  At least
there should be a line that says `you won't believe it, but this is a
CRC algorithm' ;)

> > One more point is that useful documentation needs pictures and other
> > graphical elements that you can't put into a source file.  For a unit as
> > complex as the multiplier, `ASCII art' isn't sufficient -- I need high
> > resolution color graphics to visualize some of the more complex aspects
> > (e.g. the handling of SIMD, MAC and signed/unsigned modes).
> that is for the external doc. of course.

And that will be necessary to understand the code, IMHO.

> > For the final public release, a separate, automagically created, browsable
> > (HTML) version of the source would be nice -- including hyperlinks to the
> > documentation, the components used (click on the instantiation statement
> > or component declaration and the browser will show the corresponding
> > entity) and so on.  But I have to write the code first.
> sure.
> i also should write more code too, but the current set of files
> must be clean before i start to add other stuffs, otherwise it
> will be only a huge bunch of bytes that noone will want to see.
> it's ok to not release often, but then it should be better than that....

You haven't seen much of the source code that `open source programmers'
release, have you?  It's often much worse than everything we have so far.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From whygee@club-internet.fr Mon Dec 18 14:44:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00516 for ; Mon, 18 Dec 2000 23:36:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:36:56 +0100 (MET) Received: (qmail 7810 invoked by uid 0); 18 Dec 2000 13:44:31 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx09) with SMTP; 18 Dec 2000 13:44:31 -0000 X-eGroups-Return: sentto-1101623-1790-977147058-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 18 Dec 2000 13:44:30 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 13:44:18 -0000 Received: (qmail 49430 invoked from network); 18 Dec 2000 13:44:17 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Dec 2000 13:44:17 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 18 Dec 2000 13:44:17 -0000 Received: (from mnet@localhost) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id OAA17278 for f-cpu@egroups.com; Mon, 18 Dec 2000 14:44:14 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 14:44:14 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Documentation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bb2a5902345388f554d475013688425c Status: R X-Status: N hello,

"Richard E.Hartney" wrote
>Although I am no longer on the F-CPU list; I am still browsing.
and your messages are welcome.

>The TIPS Operating System I am capturing is extremely well documented.  Each Relocatable major Routine is preceded with a description of intent.  Each line of Code has a Comment.  This was deviated by only ONE so-called brilliant mind from MIT who refused to follow even minimal direction.  Fortunately he didn't write or debug very much code. 
<snip>
>Do it while its fresh on your mind - not later and ask yourself - what was I doing??

can you propose enhancements to the QUALITY.TXT file ?
Do you have interesting hints or techniques ?

thanks,
YG

>Sincerely
>Richard E. Hartney
>Research Director
>Erin Greene & Associates
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From whygee@club-internet.fr Mon Dec 18 19:44:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00582 for ; Mon, 18 Dec 2000 23:37:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 18 Dec 2000 23:37:16 +0100 (MET) Received: (qmail 22591 invoked by uid 0); 18 Dec 2000 18:47:01 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx17) with SMTP; 18 Dec 2000 18:47:01 -0000 X-eGroups-Return: sentto-1101623-1791-977165104-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 18 Dec 2000 18:45:10 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 18:44:55 -0000 Received: (qmail 11687 invoked from network); 18 Dec 2000 18:44:53 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 18 Dec 2000 18:44:53 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 18 Dec 2000 19:45:57 -0000 Received: (from mnet@localhost) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id TAA00937 for f-cpu@egroups.com; Mon, 18 Dec 2000 19:44:46 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 19:44:46 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a305b42637a81e52b17ef187371f6f8a Status: R X-Status: N hallo, alle,


>De: Michael Riepe
>On Mon, Dec 18, 2000 at 03:23:32AM +0100, Yann Guidon wrote:
>> your parameter w is not very well defined.
>It's 32 if UMAX equals 32, and 64 if UMAX is a multiple of 64.
>Other cases are undefined.
that's what bothers me... in fact, it is an integral part
of the architecture but it is defined nowhere...

>> i think that we should characterize it more globally
>> in the ISA. for example : create a new characteristic width
>> parameter called "MAX_CHUNK_SIZE", so it can be read in the
>> SR too.
>Good idea.
that, and the pointer size. i forgotten about it :-/
we might see strange things, like 44-bit pointers,
ie the ALPHA has 64-bit registers but only 43 bits are used
in HW. for f-cpu, it might be 32, 64 or 128...

>> > > - I've included the imul unit but i'll need a good doc about it :-)
>> > Good docs don't write themselves, unfortunately ;(
>> yup. it's only a faithless prayer...
>Don't worry, you *will* get that documentation (unless I drop dead
>before I can write it, but I really don't intend to ;).  I hope to be
>able to use the days after Xmas when you guys are visiting Berlin...

ok i think that the delay is reasonable :-)

>> so what do you decide ? $PATH or copy ? it's getting very complex.
>> we have changed the directory structure several times and now the links
>> are almost all broken.
>Setting PATH is better if you're going to change tools now and then.

hmmm.... might become tricky, soon... let's try anyway...

>> > > - we still need a decent INC and SHL unit.
>> > Erik is working on INC, IIRC.
>> i'll try to make a "YG" INC and finish that damn Icache,

ok, i've written to Erik and we'll discuss about the INC
during the 17C3.

>> but someone must care about the SHL. we'll need a real professional
>> (or something like that ;-D) because a SIMD 64-bit shift/rotate unit
>> is very difficult to make correctly. some things i see at work and
>> in books indicate that we will face some troubles...
>What's it going to be, a barrel shifter or a pass gate array (aka
>`crossbar for bits')?

after a short discussion with a colleague, pass-transistor
arrays are too technology dependent. it should be reserved
for specific ( or ASIC ) implementation.

a first idea would be an array (with a well-chosen network)
of 8-bit barrell shifter/rotation. it will be rather tricky
but it looks interesting.

>[...]
>> i can switch from german to english at will. well, i've practiced,
>> so it doesn't count ;-)
>Most germans can speak German and English at the same time... the result
>is called `Denglish' or `Neudeutsch' ;)
french+english=frangliche :-)

>But can you switch from German to Lisp, too?
>(might (become 'difficult) 'sometimes)
>(not (thinkp 'you))
no parlare lisp...
i had a lesson about it, one day...


>Perhaps the problem is that there is nothing going on in my head,
>except code.  I *knew* this would happen one day... ;)

bad, bad, bad... but you will find a rich employer easily ;-)

>Non-trivial things like these need a line or two, right.
it's a minimum ! :-)
>  At least
>there should be a line that says `you won't believe it, but this is a
>CRC algorithm' ;)

>You haven't seen much of the source code that `open source programmers'
>release, have you?  It's often much worse than everything we have so far.

here, we are in the "free world", not the open one... hehe.

> Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
YG
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Berkane Azdine Mon Dec 18 22:02:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01458 for ; Tue, 19 Dec 2000 04:34:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 19 Dec 2000 04:34:51 +0100 (MET) Received: (qmail 6127 invoked by uid 0); 18 Dec 2000 23:00:52 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx01) with SMTP; 18 Dec 2000 23:00:52 -0000 X-eGroups-Return: sentto-1101623-1792-977180425-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 18 Dec 2000 23:00:47 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 18 Dec 2000 23:00:24 -0000 Received: (qmail 67895 invoked from network); 18 Dec 2000 23:00:23 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 18 Dec 2000 23:00:23 -0000 Received: from unknown (HELO semeur.localdomain) (212.27.40.118) by mta3 with SMTP; 19 Dec 2000 00:01:25 -0000 Received: from infolibre.org (semeur.localdomain [127.0.0.1]) by semeur.localdomain (Postfix) with ESMTP id 59AB5244E for ; Mon, 18 Dec 2000 22:02:20 +0100 (CET) Sender: worker@semeur.localdomain Message-ID: <3A3E7B5B.F81CDDBE@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> <20001217181515.18559@thrai.stud.uni-hannover.de> <3A3D7524.8F0A24D8@f-cpu.org> <20001218073715.61147@thrai.stud.uni-hannover.de> X-eGroups-From: Berkane Azdine From: Berkane Azdine MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 22:02:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7a95a49aeca54183ce47c46c5272ffe9 Status: R X-Status: N Hey  GROS Quand on fait Paris 8 plus du lobbying for FREE SOFTWARE FUNDATION on
n'oublie pas GNU
VOILA ? je voulais surtout te peter ta putain de guelle  a la CON.
tu te rappelle tes confusion @ Metafaiible.
Remenber
eGroups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!
From Yann GUIDON Tue Dec 19 10:56:32 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00441 for ; Wed, 20 Dec 2000 09:30:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Dec 2000 09:30:06 +0100 (MET) Received: (qmail 12740 invoked by uid 0); 19 Dec 2000 10:03:18 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx24) with SMTP; 19 Dec 2000 10:03:18 -0000 X-eGroups-Return: sentto-1101623-1793-977220190-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 19 Dec 2000 10:03:15 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 19 Dec 2000 10:03:10 -0000 Received: (qmail 46564 invoked from network); 19 Dec 2000 10:03:09 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 19 Dec 2000 10:03:09 -0000 Received: from unknown (HELO ns1.mentorg.com) (192.94.38.65) by mta2 with SMTP; 19 Dec 2000 10:03:09 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by ns1.mentorg.com (8.8.8/CF5.40F) id CAA25084; Tue, 19 Dec 2000 02:03:08 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZAF4T804; Tue, 19 Dec 2000 11:02:21 +0100 Sender: yanng@ns1.mentorg.com Message-ID: <3A3F30CF.56D52AFE@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Dec 2000 10:56:32 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] DATE: design contest Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4e60cf6e5824fd3ac4c047ad238ab37d Status: R X-Status: N hi,

http://www.date-conference.com/conference/design-contest.htm

"
The purpose for the DATE Design Contest is to promote the
research and development at Universities and Research
Laboratories in the Integrated Circuit design of electronic
systems. Competition is open to students, graduate and
undergraduate, at universities and colleges, and researchers at
public funded research institutes or centers. There are two
design contest categories: 'Operational' and 'Conceptual'. Both
are organized by CMP and EUROPRACTICE IC Service
respectively as follows:

1.Operational Design Contest forOperational designs that
   have been implemented in silicon and tested
   (measurement data). This is organized by CMP
   (Contact: Dr. Bernard Courtois E-mail:
   Bernard.Courtois@imag.fr, http://cmp.imag.fr).
2.Conceptual designs for designs that are fully simulated
   (RTL, Gates and/or transistor) with test plans. It is not
   required that the design has not been implemented in
   silicon. This contest is organized by EUROPRACTICE
   IC Service (Contact: Dr. Carl Das, E-Mail:
   das@imec.be, http://www.imec.be/europractice).

A panel of experts for each design contest category will judge
submissions. The design must comply with the rules and
criteria defined by each design contest organizer. Submission
deadline for the design contest is December 31, 2000. Winners
will be selected by the end of January. Three Prizes for each
design contest category will be awarded and announced during
the Plenary Session at DATE 2001.
"

it is too late for this year.
Anyway, i am sure that we'll have enough RTL next year
to compete. the prizes are usually a waffer...
And the most interesting "side effect" is the publicity
and the publication. since the design will be exposed to
the public, it protects us against patent issues...

YG
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Tue Dec 19 20:38:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00603 for ; Wed, 20 Dec 2000 09:30:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 20 Dec 2000 09:30:49 +0100 (MET) Received: (qmail 4482 invoked by uid 0); 19 Dec 2000 19:42:50 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx16) with SMTP; 19 Dec 2000 19:42:50 -0000 X-eGroups-Return: sentto-1101623-1794-977254838-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 19 Dec 2000 19:41:10 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 19 Dec 2000 19:40:38 -0000 Received: (qmail 42458 invoked from network); 19 Dec 2000 19:40:36 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 19 Dec 2000 19:40:36 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 19 Dec 2000 20:41:41 -0000 Received: (from mnet@localhost) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id UAA08642 for f-cpu@egroups.com; Tue, 19 Dec 2000 20:38:54 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 19 Dec 2000 20:38:54 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] LaTeX manual ready ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d865dbb606feea7fda2c9acfa55f7ca Status: R X-Status: N       hello,

Finally Olivier has published his version of the manual.
it is available at http://www.f-cpu.seul.org/manual
and a PostScript version is available from
http://www.mime.up8.edu/~whygee/manuel/

we'll need to setup a clean website at seul...

@+
YG
eGroups Sponsor
Click Here!
From Jeff Davies Wed Dec 20 20:43:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02385 for ; Thu, 21 Dec 2000 02:04:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 02:04:36 +0100 (MET) Received: (qmail 12785 invoked by uid 0); 20 Dec 2000 19:51:04 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx14) with SMTP; 20 Dec 2000 19:51:04 -0000 X-eGroups-Return: sentto-1101623-1795-977341845-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 20 Dec 2000 19:50:59 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 20 Dec 2000 19:50:43 -0000 Received: (qmail 87860 invoked from network); 20 Dec 2000 19:50:43 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 20 Dec 2000 19:50:43 -0000 Received: from unknown (HELO mail4.svr.pol.co.uk) (195.92.193.211) by mta2 with SMTP; 20 Dec 2000 19:50:43 -0000 Received: from modem-162.south-dakota.dialup.pol.co.uk ([62.137.92.162] helo=llandre.freeserve.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 148pG3-0007iC-00; Wed, 20 Dec 2000 19:50:40 +0000 Message-ID: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com, rms@gnu.org From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Dec 2000 19:43:54 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 84d7a203175681728dc617d9ff81f830 Status: R X-Status: N Basically, what a tool like Merlot (GPL XML editor, which requires Java
1.3 to run) gives you is a tree control
pane on the left, and a dialog type pane on the right, with drop down
list fields, text fields etc on the right.

The DTD defines the structure of the tree on the left, and what fields
appear on the right.

XSL is a file type which contains commands in a language which can
transform the (XML) output from
Merlot. By "transform", imagine text substitution. XSL processing is
performed by an "XSLT" program.

I produced a DTD which allows you to "draw" a program in the above
editor, and an XSL file to convert
it to java source. As discussed on the list previously, this could
equally convert directly to assembler or
machine code direct. (might require a bespoke program instead of XSL,
but it is very easy).

As merlot is plug in-enabled, instead of the dialog type pane on the
right, you could equally write a "visio"
type drawing plug in, using the XML tree to store data.

I have this vision of using the one gui for everything.

1. The layout is similar to typical file system explorers. Why not use
it as a file system explorer as well.
Have a bit of code that converts file system directory tree to XML, and
hey presto.
Obviously, you could have a config file somewhere which maps file
extensions to DTDs and plug ins
so that you double click on a file, and another instance of Merlot
opens, using the plug in and DTD for that
file type.

2. Structured documentation
3. Programming
4. DESIGNING HARDWARE (note above note about a drawing gui plug in
(optional extra).
You could design your circuit using XML editor, and transform the XML
into C++ for simulation, or
VHDL!!!

5. System configuration:

a. You could spend the rest of your life rewriting all linux distro
software to use XML, or..
b. have a DTD for example for the configuration of a DNS (named). you
use the GUI to configure the DNS
and then... transform using an XSL sheet into the format required by
DNS!!!!

IE a gui tool for configuring a DNS without a single line of code!!
<writing a DTD and XSL is pretty simple>.

The one thing that Merot could do with (in my opinion) is a guile (or
another scripting language) type binding layer
between gui events and the back end libraries. <as in emacs or word etc
etc>.

What has this to do with fcpu??
Well the documentation and some programs might be written in XML,
and perhaps it would be easier to write a plug in "drawing tool" for
knocking up circuit diagrams,
the results of which can be transformed into simulator code or VHDL very
simply.

I also have the idea of adding a node serial number and last mod date to
all elements so that replication
and change tracking becomes supreme, and diff'ing is no longer the black
art it is now.

Ok this ties one to a java implementation, but this doesn't have to be
bloated - look at the
www.180sw.com turing machine based java implementation - very very
small, and can run on even
8 bit cpus. (pity it isn't GPL, but if they have done it,  free software
in the same ilk will follow).

In the case of PDAs etc, it could certainly be an advantage to use a
single tool for all data viewing/editing.

Jeff Davies
eGroups Sponsor
Click Here!
From Ben Franchuk Wed Dec 20 20:46:35 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02388 for ; Thu, 21 Dec 2000 02:04:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 02:04:38 +0100 (MET) Received: (qmail 28650 invoked by uid 0); 20 Dec 2000 20:12:43 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx21) with SMTP; 20 Dec 2000 20:12:43 -0000 X-eGroups-Return: sentto-1101623-1796-977343146-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 20 Dec 2000 20:12:41 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 20 Dec 2000 20:12:25 -0000 Received: (qmail 11652 invoked from network); 20 Dec 2000 20:12:24 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 20 Dec 2000 20:12:24 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 20 Dec 2000 20:12:23 -0000 Received: from jetnet.ab.ca (dialin43.jetnet.ab.ca [207.153.6.43]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA07448 for ; Wed, 20 Dec 2000 13:00:34 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A410C9B.A366E25F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.15 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 20 Dec 2000 12:46:35 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 173693e86c66e9dd256df7c91976ce99 Status: R X-Status: N Jeff Davies wrote:
>
> Basically, what a tool like Merlot (GPL XML editor, which requires Java
> 1.3 to run) gives you is a tree control
> pane on the left, and a dialog type pane on the right, with drop down
> list fields, text fields etc on the right.

I don't like java because Java support is only on what SUN considers
to VALID OS's. Linux is NOT considered a OS, is the feeling I get from the
Java web site.
I like simple HTML pages - no song or dance and no java script.
(I don't like banner ads but I can't do nothing about that).
I don't want to have have the LATEST version of NETSCAPE just to visit my
favorite
pages or a High Speed link. Since I don't have cable TV, a cable modem is NOT a
option.
Fancy stuff may be good for getting the number hits per page
but the content brings them back.
One tool I am looking at (for my meager web pages) is
a HTML pre processor called HTMLPAIN. http://artho.com/webtools/plain/
This permits creation of your own custom tags and permits better automation
of link handling and file organization.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Berkane Azdine Mon Dec 18 22:02:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02412 for ; Thu, 21 Dec 2000 02:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 02:04:44 +0100 (MET) Received: (qmail 31793 invoked by uid 0); 20 Dec 2000 22:06:16 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx13) with SMTP; 20 Dec 2000 22:06:16 -0000 X-eGroups-Return: sentto-1101623-1797-977349880-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 20 Dec 2000 22:06:15 -0000 X-Sender: asdean@infolibre.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 20 Dec 2000 22:04:40 -0000 Received: (qmail 51467 invoked from network); 20 Dec 2000 22:04:39 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 20 Dec 2000 22:04:39 -0000 Received: from unknown (HELO semeur.localdomain) (212.27.55.22) by mta3 with SMTP; 20 Dec 2000 23:05:44 -0000 Received: from infolibre.org (semeur.localdomain [127.0.0.1]) by semeur.localdomain (Postfix) with ESMTP id 59AB5244E for ; Mon, 18 Dec 2000 22:02:20 +0100 (CET) Sender: worker@semeur.localdomain Message-ID: <3A3E7B5B.F81CDDBE@infolibre.org> X-Mailer: Mozilla 4.73 [fr] (X11; I; Linux 2.2.15-4mdk i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> <20001217181515.18559@thrai.stud.uni-hannover.de> <3A3D7524.8F0A24D8@f-cpu.org> <20001218073715.61147@thrai.stud.uni-hannover.de> X-eGroups-From: Berkane Azdine From: Berkane Azdine MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 18 Dec 2000 22:02:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5c86df5589c64e2c88a1a495aed48981 Status: R X-Status: N Hey  GROS Quand on fait Paris 8 plus du lobbying for FREE SOFTWARE FUNDATION on
n'oublie pas GNU
VOILA ? je voulais surtout te peter ta putain de guelle  a la CON.
tu te rappelle tes confusion @ Metafaiible.
Remenber
eGroups Sponsor
Click Here!
From Michael Riepe Thu Dec 21 00:53:39 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02430 for ; Thu, 21 Dec 2000 02:04:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 02:04:49 +0100 (MET) Received: (qmail 1006 invoked by uid 0); 21 Dec 2000 00:05:24 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx16) with SMTP; 21 Dec 2000 00:05:24 -0000 X-eGroups-Return: sentto-1101623-1798-977356430-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 20 Dec 2000 23:54:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 20 Dec 2000 23:53:50 -0000 Received: (qmail 38363 invoked from network); 20 Dec 2000 23:53:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 20 Dec 2000 23:53:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.244) by mta3 with SMTP; 21 Dec 2000 00:54:53 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00764; Thu, 21 Dec 2000 00:53:39 +0100 Message-ID: <20001221005339.04869@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A3C2A64.675125C7@f-cpu.org> <20001217181515.18559@thrai.stud.uni-hannover.de> <3A3D7524.8F0A24D8@f-cpu.org> <20001218073715.61147@thrai.stud.uni-hannover.de> <3A3E7B5B.F81CDDBE@infolibre.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A3E7B5B.F81CDDBE@infolibre.org>; from Berkane Azdine on Mon, Dec 18, 2000 at 10:02:19PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 00:53:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] package update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 23fa4e199e663ded36c925ce051a11d3 Status: R X-Status: N On Mon, Dec 18, 2000 at 10:02:19PM +0100, Berkane Azdine wrote:
> Hey  GROS Quand on fait Paris 8 plus du lobbying for FREE SOFTWARE FUNDATION on
> n'oublie pas GNU
> VOILA ? je voulais surtout te peter ta putain de guelle  a la CON.
> tu te rappelle tes confusion @ Metafaiible.
> Remenber

Even if you repeat that 1000 times, I won't understand it.
Please stop.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann GUIDON Thu Dec 21 11:04:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00353 for ; Thu, 21 Dec 2000 12:53:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 12:53:30 +0100 (MET) Received: (qmail 17088 invoked by uid 0); 21 Dec 2000 10:11:05 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx04) with SMTP; 21 Dec 2000 10:11:05 -0000 X-eGroups-Return: sentto-1101623-1799-977393397-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 21 Dec 2000 10:10:59 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 21 Dec 2000 10:09:56 -0000 Received: (qmail 29341 invoked from network); 21 Dec 2000 10:09:56 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Dec 2000 10:09:56 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 21 Dec 2000 10:09:56 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA09237; Thu, 21 Dec 2000 02:09:54 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZAF44CKR; Thu, 21 Dec 2000 11:09:52 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A41D590.67389756@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 11:04:00 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] web doc writing + misc urls Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 79da95ea772b3f2489b44a1d44403cc5 Status: R X-Status: N http://artho.com/webtools/
thank you Ben for the link !

http://www.opentheory.org/proj/oxkonferenz/v0005.phtml
is an interesting way to collaborate on a document.

http://www.ccc.de/congress
is slightly updated. no schedule for the f-cpu team yet
but the suspense won't last (hopefully).

http://www.epita.fr/~bail_c/
a starting for a f-bus+g-chip draft
in french...
eGroups Sponsor
Click Here!
From Richard Stallman Thu Dec 21 14:39:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00333 for ; Thu, 21 Dec 2000 19:40:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 19:40:55 +0100 (MET) Received: (qmail 31743 invoked by uid 0); 21 Dec 2000 13:40:12 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx17) with SMTP; 21 Dec 2000 13:40:11 -0000 X-eGroups-Return: sentto-1101623-1800-977406002-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 21 Dec 2000 13:40:10 -0000 X-Sender: rms@santafe.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 21 Dec 2000 13:40:02 -0000 Received: (qmail 4561 invoked from network); 21 Dec 2000 13:40:01 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 21 Dec 2000 13:40:01 -0000 Received: from unknown (HELO pele.santafe.edu) (192.12.12.119) by mta2 with SMTP; 21 Dec 2000 13:40:01 -0000 Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.9.3/8.9.1) with ESMTP id GAA15012; Thu, 21 Dec 2000 06:39:56 -0700 (MST) Received: (from rms@localhost) by wijiji.santafe.edu (8.9.3+Sun/8.9.1) id GAA15527; Thu, 21 Dec 2000 06:39:56 -0700 (MST) Message-Id: <200012211339.GAA15527@wijiji.santafe.edu> X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@wijiji.santafe.edu using -f To: jeff@llandre.freeserve.co.uk Cc: f-cpu@egroups.com In-reply-to: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> (message from Jeff Davies on Wed, 20 Dec 2000 19:43:54 +0000) References: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> From: Richard Stallman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 06:39:56 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7b4e9ee046c695c049c07601d72e5237 Status: R X-Status: N     Basically, what a tool like Merlot (GPL XML editor, which requires Java
    1.3 to run)

It is a tragedy when a free program requires non-free Java 1.3 to run.
That means it cannot be part of a free operating system.  Can you help
spread the word asking people who use Java to stick to the features
and libraries supported by free Java platforms?

I would like to contact the Merlot developers about this, and ask them
to try to rewrite the program not to use the newer features.  Would
you please tell me how to send them email?
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 21 15:06:18 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00348 for ; Thu, 21 Dec 2000 19:40:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 19:40:59 +0100 (MET) Received: (qmail 21991 invoked by uid 0); 21 Dec 2000 14:17:19 -0000 Received: from cj.egroups.com (208.50.144.68) by 10.1.4.119 (mx19) with SMTP; 21 Dec 2000 14:17:19 -0000 X-eGroups-Return: sentto-1101623-1801-977408046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 21 Dec 2000 14:14:15 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 21 Dec 2000 14:14:05 -0000 Received: (qmail 51508 invoked from network); 21 Dec 2000 14:13:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 21 Dec 2000 14:13:09 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 21 Dec 2000 15:14:14 -0000 Received: from modem-32.sodium.dialup.pol.co.uk ([62.136.10.32] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 1496Sf-0001x8-00 for f-cpu@egroups.com; Thu, 21 Dec 2000 14:12:49 +0000 Message-ID: <3A420E5A.1AA4EE07@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> <200012211339.GAA15527@wijiji.santafe.edu> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 14:06:18 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 48b32750d465ba6e459804cbdc926740 Status: R X-Status: N Their site www.merlotxml.org appears to have disappeared. I'd like to find out
what has happened to them.
I do worry some times that GPL projects disappear and return disguised
elsewhere as closed software.

I hope this isn't the case this time.

I think i only have binaries, although these can be decompiled, they may have
been name munged.
I agree, that free versions are better. Personally, I'd like to use a free java
compiler.
(java is really only pointerless C++ anyhow), and a free set of classes. I will
look at CLASSPATH
and gcj (the gnu c++ compiler you wrote modified to compile java).

Jeff Davies

Richard Stallman wrote:

>     Basically, what a tool like Merlot (GPL XML editor, which requires Java
>     1.3 to run)
>
> It is a tragedy when a free program requires non-free Java 1.3 to run.
> That means it cannot be part of a free operating system.  Can you help
> spread the word asking people who use Java to stick to the features
> and libraries supported by free Java platforms?
>
> I would like to contact the Merlot developers about this, and ask them
> to try to rewrite the program not to use the newer features.  Would
> you please tell me how to send them email?
>
eGroups Sponsor
Click Here!
From Yann GUIDON Thu Dec 21 15:28:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00357 for ; Thu, 21 Dec 2000 19:41:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 19:41:02 +0100 (MET) Received: (qmail 3981 invoked by uid 0); 21 Dec 2000 14:39:34 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx22) with SMTP; 21 Dec 2000 14:39:34 -0000 X-eGroups-Return: sentto-1101623-1802-977409562-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hi.egroups.com with NNFMP; 21 Dec 2000 14:39:33 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 21 Dec 2000 14:39:21 -0000 Received: (qmail 73885 invoked from network); 21 Dec 2000 14:34:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 21 Dec 2000 14:34:45 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 21 Dec 2000 14:34:44 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA02970; Thu, 21 Dec 2000 06:34:41 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZAF44DBW; Thu, 21 Dec 2000 15:34:36 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A42139E.7B7772C4@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com Cc: rms@gnu.org References: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> <200012211339.GAA15527@wijiji.santafe.edu> From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 15:28:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5464bfef244fe743bbc8d961bc13eee3 Status: R X-Status: N hi,

Richard Stallman wrote:
>
>     Basically, what a tool like Merlot (GPL XML editor, which requires Java
>     1.3 to run)
>
> It is a tragedy when a free program requires non-free Java 1.3 to run.
> That means it cannot be part of a free operating system.  Can you help
> spread the word asking people who use Java to stick to the features
> and libraries supported by free Java platforms?
>
> I would like to contact the Merlot developers about this, and ask them
> to try to rewrite the program not to use the newer features.  Would
> you please tell me how to send them email?

although i am mostly agreeing, i remark that the use of this tool
might influence people and force some to write a GPL port of J1.3.

We have faced the same problem for the f-cpu, and i guess that a lot
of people do. it's either : "live in a cocoon" or "open up to the
world".
We can't live in a closed environment, we have to interact and bring
something
in return from something else. If a "win-win" agreement is found, then
why be so negative ? We are conscious anyway that the choices are
difficult
and might be a temporary bad side of the project, but philosphy doesn't
solve
everything and one day, we have to wake/stand up and code.

OK i agree for this special case that Merlot did behave very badly
when i tried it. But if more people work with it, they will
enhance it and it will probably become much better.
At least, i hope so...

YG

PS: the website is www.merlotxml.org but it doesn't seem to answer...
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 21 15:32:44 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00360 for ; Thu, 21 Dec 2000 19:41:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 19:41:03 +0100 (MET) Received: (qmail 14292 invoked by uid 0); 21 Dec 2000 14:48:20 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx08) with SMTP; 21 Dec 2000 14:48:20 -0000 X-eGroups-Return: sentto-1101623-1803-977410076-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 21 Dec 2000 14:48:15 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 21 Dec 2000 14:47:55 -0000 Received: (qmail 46482 invoked from network); 21 Dec 2000 14:39:36 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Dec 2000 14:39:36 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 21 Dec 2000 14:39:35 -0000 Received: from modem-32.sodium.dialup.pol.co.uk ([62.136.10.32] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 1496sX-00008H-00 for f-cpu@egroups.com; Thu, 21 Dec 2000 14:39:33 +0000 Message-ID: <3A42148C.46EE3215@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 14:32:44 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] merlot dead, perhaps write own XML tree based editor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a070226f7861f7933c061f3e8a81c6b4 Status: R X-Status: N In regard to my pervious mail message about merlot, the site has gone
offline, perhaps something to do with
(after a little research) Merlot coming from www.channelpoint.org
employees. channelpoint has been taken
over by IBM. IBM offer xeena for the same role from their alphaworks
site.

I am rather sure that merlot was gpl, however, freshmeat reports it as
Apache licence (I have no idea how this
compares). I have sent a mail to the authors asking for source code,
however, I might just write one from
scratch using the GPL CLASSPATH (is that right?) libraries and gcj.

I'm a newbie to GPL java, so anything anyone knows about it will be
helpful.

To recap, I think a tree based plug in-able XML editor could be used for
authoring documents, programs,
and even hardware <see previous mail>.

The only reason for wanting to use java is that it is essentially
pointerless C++, and consequentially,
is much faster to code in.

Jeff Davies
eGroups Sponsor
Click Here!
From Jeff Davies Thu Dec 21 15:53:58 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00375 for ; Thu, 21 Dec 2000 19:41:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 21 Dec 2000 19:41:09 +0100 (MET) Received: (qmail 32690 invoked by uid 0); 21 Dec 2000 15:42:26 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 21 Dec 2000 15:42:26 -0000 X-eGroups-Return: sentto-1101623-1804-977411434-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 21 Dec 2000 15:10:51 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_3_1_3); 21 Dec 2000 15:10:33 -0000 Received: (qmail 52164 invoked from network); 21 Dec 2000 15:00:49 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Dec 2000 15:00:49 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta1 with SMTP; 21 Dec 2000 15:00:49 -0000 Received: from modem-67.beryllium.dialup.pol.co.uk ([62.136.3.67] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 1497D5-0007aS-00; Thu, 21 Dec 2000 15:00:48 +0000 Message-ID: <3A421985.89D7AE2B@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com, phil@aicom.co.uk From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 21 Dec 2000 14:53:58 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] GCJ compiles to native code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8f4d3e7c91e6a222b50c27ca5b54a73e Status: R X-Status: N And whats more can compile .class files to native code.
(this is continuing a discussion of some weeks ago)
So coupled with the Classpath (gpl java libraries) project, it looks
like you can write a program in java, and
compile it to be totally native code, or leave part or all of it in
bytecode.
I'm guessing, but I'd imagine since gcj == gcc, you can pretty easily
link in C++ files as well.
Cool, and all GPL.

Jeff Davies

"GCJ works in three ways: First GCJ can take .java files as input and
compile architecture-specific object files. Second, by using the -C
option, GCJ can take .java
files as input, and generate .class files. Third, GCJ can take .class
files as input to create architecture-specific object files. "
eGroups Sponsor
Click Here!
From Fri Dec 22 10:11:02 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00335 for ; Sat, 23 Dec 2000 09:54:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Dec 2000 09:54:23 +0100 (MET) Received: (qmail 23400 invoked by uid 0); 22 Dec 2000 09:10:53 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx10) with SMTP; 22 Dec 2000 09:10:53 -0000 X-eGroups-Return: sentto-1101623-1805-977476244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 22 Dec 2000 09:10:50 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 22 Dec 2000 09:10:44 -0000 Received: (qmail 24431 invoked from network); 22 Dec 2000 09:10:43 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 22 Dec 2000 09:10:43 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta1 with SMTP; 22 Dec 2000 09:10:43 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.11.1/8.11.1) with ESMTP id eBM9AUf29898 for ; Fri, 22 Dec 2000 10:10:30 +0100 (MET) Message-Id: <200012220910.eBM9AUf29898@essi.essi.fr> In-Reply-To: <3A42148C.46EE3215@llandre.freeserve.co.uk> To: f-cpu@egroups.com User-Agent: IMHO/0.98.1 (Webmail for Roxen) From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 22 Dec 2000 10:11:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] merlot dead, perhaps write own XML tree based editor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7515d9adcd1e29c1f967bdf11418125e Status: R X-Status: N Whow... some calm please.

XML editors can be found very easily.

For the XML -> HTML translation... I'm working on it for the new
website at seul.
Free tools for it exists: link xerces to xalan and you have one of
them. They are both part of xml apache project so they are free.
  So I'm trying to make a short set of xslt stylesheet who would do
the job.: generate
the indexes, manage the cross references...

See you later folks.

Steve
eGroups Sponsor
Click Here!
From jeff@llandre.freeserve.co.uk Fri Dec 22 13:38:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA00363 for ; Sat, 23 Dec 2000 09:54:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 23 Dec 2000 09:54:33 +0100 (MET) Received: (qmail 26099 invoked by uid 0); 22 Dec 2000 12:44:02 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx08) with SMTP; 22 Dec 2000 12:44:02 -0000 X-eGroups-Return: sentto-1101623-1806-977489006-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hp.egroups.com with NNFMP; 22 Dec 2000 12:43:44 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 22 Dec 2000 12:43:26 -0000 Received: (qmail 9721 invoked from network); 22 Dec 2000 12:43:25 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 22 Dec 2000 12:43:25 -0000 Received: from unknown (HELO mail2.svr.pol.co.uk) (195.92.193.210) by mta3 with SMTP; 22 Dec 2000 13:44:30 -0000 Received: from modem-37.samarium.dialup.pol.co.uk ([62.136.50.165] helo=62.136.50.165) by mail2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 149RXb-0007Px-00 for f-cpu@egroups.com; Fri, 22 Dec 2000 12:43:20 +0000 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 22 Dec 2000 12:38 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FWD: RE: What has happened to merlot xml? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b2ea58e016daadf48db0083cb791f50a Status: R X-Status: N looks like merlot is still free, just a long lasting network
problem.
steve: merlot uses xerces as a parser, and lotus xslt engine
(any xslt could be substituted)
Merlot is an editor like xmetal etc.
licence is apache like xerces and xalan.
Jeff Davies

-------------Forwarded message-------------
Date: Thu, 21 Dec 2000 12:57:15 -0700
From: Tim McCune <timm@channelpoint.com>
To: 'Jeff Davies' <jeff@llandre.freeserve.co.uk>
Subject: RE: What has happened to merlot xml?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We've been having network trouble over the past couple weeks.
Not
sure why.  The site is back up now.  If you notice any outages in
the
future, please let me know.  If you could CC the mail to
7192103454@messaging.sprintpcs.com, it'll page me too.
Thanks Jeff.

> -----Original Message-----
> From: Jeff Davies [mailto:jeff@llandre.freeserve.co.uk]
> Sent: Thursday, December 21, 2000 7:22 AM
> To: timm@channelpoint.com
> Subject: What has happened to merlot xml?
>
>
> Are you experiencing network difficulties. If you are giving up
on
> the project, can I have the source code to
> continue it?
>
> Thanks
>
> Jeff Davies
>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use
<http://www.pgp.com>

iQA/AwUBOkJgatUPOr8a7vy5EQIgWACg4C4nicwVT0D3seSa3
EBt2n6s5A4AoKla
vs8IzWNOabgv3KU2m6NBONAs
=xLWc
-----END PGP SIGNATURE-----
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 23 17:38:56 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00359 for ; Sun, 24 Dec 2000 02:42:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Dec 2000 02:42:21 +0100 (MET) Received: (qmail 25104 invoked by uid 0); 23 Dec 2000 16:45:05 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx01) with SMTP; 23 Dec 2000 16:45:05 -0000 X-eGroups-Return: sentto-1101623-1808-977589217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 23 Dec 2000 16:33:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 23 Dec 2000 16:33:36 -0000 Received: (qmail 44446 invoked from network); 23 Dec 2000 16:33:36 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 23 Dec 2000 16:33:36 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 23 Dec 2000 16:33:36 -0000 Received: from f-cpu.org (nas3-26.ras.club-internet.fr [195.36.203.26]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA14122; Sat, 23 Dec 2000 17:33:30 +0100 (MET) Message-ID: <3A44D520.750C0980@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com Cc: rms@gnu.org References: <3A410BFA.1BC729D3@llandre.freeserve.co.uk> <200012211339.GAA15527@wijiji.santafe.edu> <3A42139E.7B7772C4@mentor.com> <200012221850.LAA12983@wijiji.santafe.edu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Dec 2000 17:38:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: more XML stuff (ideas) re tools Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: efa4b7f375445adb10d7c26f06fb5c9b Status: R X-Status: N hello,

Richard Stallman wrote:
>     although i am mostly agreeing, i remark that the use of this tool
>     might influence people and force some to write a GPL port of J1.3.
>
> There are many reasons to try to implement Java 1.3.  (This would not
> be a "port", it would be an extension of existing implementations.)
> The problem is that Sun makes vague noises about suing people if they
> do it.  Nobody has dared challenge them yet.
funny.

> In this situation, additional programs written in Java 1.3 will do
> very little to help encourage free implementations.  What they WILL do
> is increase the amount of problems that are caused if we cannot
> implement Java 1.3.
>
> Please don't use Java 1.3.

thanks but i didn't start ;-)
Java is slow, bloated, and doesn't allow me to do what i want.
Some people disagree, but it's their own business.
Therefore, don't worry.

>     We have faced the same problem for the f-cpu, and i guess that a lot
>     of people do. it's either : "live in a cocoon" or "open up to the
>     world".
>
> To make the decision on a merely technical basis is to live in an
> engineer's cocoon.  Engineers tend to do that if they don't watch
> out--they often cite "progress" as an excuse to ignore the effects of
> their work on other people.
that shouldn't be the case here, or else i have probably missed an episode...

>  To open up to the world, we must consider
> the political and social consequences of our decisions.
probably, but i don't work with Sun and i don't know all their intentions.

> Free software developers should avoid using Java 1.3 because of those
> consequences.
first, i don't use it, second, other people have spoken about some other
"native" XML editors, third, since the name of the game is freedom,
i see no reason to forbid JEff to use, or at least give a try to a piece
of SW that he has chosen for his personal use. If he wasn't aware of other
possibilities, or had a special reason to do it, he shouldn't be blamed.



>      If a "win-win" agreement is found, then why be so negative ?
> A "win-win agreement" is by definition good for everyone.
> However, I can't see how this relates to the topic
> we are discussing.  Agreement between whom?  About what?

Sorry, we are not helped by lawyers.

Anyway, we count on you to point other possible "licence troubles".
Until now, it went rather well : we use VHDL'93, HTML, LaTex
and some public agora. This way, we are not closely bound by the software
licences. For example, the only good working VHDL compiler that is free of
charge is "free as beer" (but has other advantages). If we ever run into
licence troubles with Simili, we can change the tool without changing
the VHDL source. Same with XML : if the editor is giving us some trouble,
there are other XML editors out there.


We don't want to spend out whole life re-writing vi, simply because
all our tools are not "free". you know that the source matters most.
when the source is made, we can chat about what tool is best. but when
there is no alternative, we have no choice, we have to go forward
and hope that the tools will appear someday soon. And i care more
about the GNU EDA tools (i've tried several and none is useful) than
about Sun's whims. We can make a CPU without Java, but we can't make a
free CPU without free EDA tools.

have a nice day,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sat Dec 23 17:42:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00377 for ; Sun, 24 Dec 2000 02:42:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 24 Dec 2000 02:42:25 +0100 (MET) Received: (qmail 14433 invoked by uid 0); 23 Dec 2000 16:43:19 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx09) with SMTP; 23 Dec 2000 16:43:19 -0000 X-eGroups-Return: sentto-1101623-1809-977589401-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 23 Dec 2000 16:37:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 23 Dec 2000 16:36:40 -0000 Received: (qmail 57478 invoked from network); 23 Dec 2000 16:36:40 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 23 Dec 2000 16:36:40 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 23 Dec 2000 16:36:39 -0000 Received: from f-cpu.org (nas3-26.ras.club-internet.fr [195.36.203.26]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA01584 for ; Sat, 23 Dec 2000 17:36:34 +0100 (MET) Message-ID: <3A44D5E6.777F2B3A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 23 Dec 2000 17:42:14 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] http://www.ccc.de/congress/fahrplan/day3.en.html Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f37d31b7c71088190abafaead91d7f04 Status: R X-Status: N hello,

looks like our conference will take place on the third day.
be ready at 12 !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Alan Grimes Mon Dec 25 06:57:46 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA00332 for ; Mon, 25 Dec 2000 11:35:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Dec 2000 11:35:40 +0100 (MET) Received: (qmail 25041 invoked by uid 0); 25 Dec 2000 05:56:33 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx10) with SMTP; 25 Dec 2000 05:56:33 -0000 X-eGroups-Return: sentto-1101623-1811-977723775-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 25 Dec 2000 05:56:24 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 25 Dec 2000 05:56:15 -0000 Received: (qmail 39743 invoked from network); 25 Dec 2000 05:56:15 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Dec 2000 05:56:15 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 25 Dec 2000 05:56:14 -0000 Received: from 66-44-59-209.s463.tnt3.lnhva.md.dialup.rcn.com ([66.44.59.209] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14AQcH-0007OR-00 for f-cpu@egroups.com; Mon, 25 Dec 2000 00:56:13 -0500 Message-ID: <3A46E1DA.F2FBECF6@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 25 Dec 2000 00:57:46 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Have you seen this. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9774efd72ba786aa6d0c9ddf508c38f0 Status: R X-Status: N Keyshaun wrote:
> From this there are 2 things that must happen.  There must be a free
> hardware project to make ATA style disk as they are now that will never
> include copy protection.

nah...
When did you get your first IDE drive?
To up it to 32 bits or beyond and keep it at 66/100 mhz, you will have
to re-design your case so none of the drives are more than 6" from the
controller... =P

I also hear that there is a standard called "fiberchannel". A fiber
optic HD system?

Anyway the world is going serial it seems. =)
Within the case you don't need to be as robust as USB and raw unbridled
speed will be the overriding concern followed by the allmighty god of
all engineering, SIMPLICITY. Ofcourse you still want to keep in mind the
wide variety of drives and RAID RAID RAID!!! ;)

Regardless, if you start a company, count me in as a founding partner. I
know the basics of business and can get you off the ground, if not into
orbit...

> When I put data on a disk I never want to be
> limited in the way I can handel my information.  Linux has shown us
> that we can be free in our operating system.  Now opencollector.org and
> opencores.org are showing us that we may be free in our hardware.  Even
> if you can't do anything just know that an industry is preparing to
> damage the ease of storage of our information.  Let us all hope that we
> may avoid corperate bondage.

BTW: does anybody know where I can get an affordable non-IA mobo?

--
If a "bug" in one program causes another to fail, the OS is at fault.
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From Ben Franchuk Sun Dec 24 21:32:12 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02206 for ; Tue, 26 Dec 2000 00:12:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 26 Dec 2000 00:12:52 +0100 (MET) Received: (qmail 435 invoked by uid 0); 25 Dec 2000 06:19:03 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx23) with SMTP; 25 Dec 2000 06:19:03 -0000 X-eGroups-Return: sentto-1101623-1812-977724593-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 25 Dec 2000 06:09:56 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 25 Dec 2000 06:09:53 -0000 Received: (qmail 31336 invoked from network); 25 Dec 2000 06:09:52 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 25 Dec 2000 06:09:52 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 25 Dec 2000 06:09:51 -0000 Received: from jetnet.ab.ca (dialin43.jetnet.ab.ca [207.153.6.43]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA11688 for ; Sun, 24 Dec 2000 22:57:35 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A465D4C.C3ECDC39@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18pre21 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A46E1DA.F2FBECF6@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Dec 2000 13:32:12 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Have you seen this. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 82d52e841ad386fa05d4493b6e52c0ac Status: R X-Status: N Alan Grimes wrote:
>
> Anyway the world is going serial it seems. =)
> Within the case you don't need to be as robust as USB and raw unbridled
> speed will be the overriding concern followed by the allmighty god of
> all engineering, SIMPLICITY. Ofcourse you still want to keep in mind the
> wide variety of drives and RAID RAID RAID!!! ;)

BUG SPAY!!!! for the HD's?
Anyway I have a nice url for a FPGA with a 2.5 gbit fiber cable built in.
Just the thing for do-it your self serial interfaces.
http://www.quicklogic.com/devices/QuickFC/

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From sentto-1101623-1810-977722284-sloyment=gmx.net@returns.onelist.com Mon Dec 25 11:35:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA00335 for ; Mon, 25 Dec 2000 11:35:41 +0100 Date: Mon, 25 Dec 2000 11:35:41 +0100 From: sentto-1101623-1810-977722284-sloyment=gmx.net@returns.onelist.com Message-Id: <200012251035.LAA00335@WintelPC.Potential> X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 25 Dec 2000 11:35:41 +0100 (MET) Received: (qmail 7751 invoked by uid 0); 25 Dec 2000 05:33:11 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx14) with SMTP; 25 Dec 2000 05:33:11 -0000 X-eGroups-Return: sentto-1101623-1810-977722284-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 25 Dec 2000 05:31:34 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 25 Dec 2000 05:31:23 -0000 Received: (qmail 6058 invoked from network); 25 Dec 2000 05:31:23 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 25 Dec 2000 05:31:23 -0000 Received: from unknown (HELO mail.inconnect.com) (209.140.64.7) by mta2 with SMTP; 25 Dec 2000 05:31:23 -0000 Received: (qmail 24635 invoked from network); 25 Dec 2000 05:31:22 -0000 Received: from ultra1.inconnect.com (209.140.64.2) by mail with SMTP; 25 Dec 2000 05:31:22 -0000 X-Sender: To: Alissa Leavitt , Brad Hanson , Hilary Brunt , hilary brunt , Byron Kruger , Chrissy , Chuck Grandgent , Dan , Deborah Meyerink , Brett Error , Freedom CPU , Suzanne Grandgent , =?X-UNKNOWN?Q?G=C5R=A5?= , James , Janet Pancoast , Jessica Kirkham , Julie Davis , Kaylene Martin , Sarah A Lampe , ALISSA LEAVITT , Michael Richardson , Michelle Lutz , Shoshana , Holly Smith , Rachel Ann Soderquist , Steve Wyall , "TairBear X-UIDL": baby_tbear@hotmail.com Status: RO X-Status: O Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 24 Dec 2000 22:31:22 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] Have you seen this. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi folks.  This will be the one and only time I send to my entire address
book(contains friends and some of their familes).  Never again will this
happen, but I must state my outright objection to this attempt to put us,
the people, the consumers in a form of bondage.  The ATA standard is being
expanded to adopt hardware level copy protection.  Read about it at
http://www.theregister.co.uk/content/2/15620.html  From this there are 2
things that must happen.  There must be a free hardware project to make
ATA style disk as they are now that will never include copy protection.
When I put data on a disk I never want to be limited in the way I can
handel my information.  Linux has shown us that we can be free in our
operating system.  Now opencollector.org and opencores.org are showing us
that we may be free in our hardware.  Even if you can't do anything just
know that an industry is preparing to damage the ease of storage of our
information.  Let us all hope that we may avoid corperate bondage.

Shaun Kruger
eGroups Sponsor
Click Here!
From jeff@llandre.freeserve.co.uk Tue Dec 26 14:28:00 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA01016 for ; Tue, 26 Dec 2000 17:30:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 26 Dec 2000 17:30:27 +0100 (MET) Received: (qmail 15676 invoked by uid 0); 26 Dec 2000 13:33:43 -0000 Received: from hi.egroups.com (208.50.99.211) by 10.1.4.112 (mx12) with SMTP; 26 Dec 2000 13:33:43 -0000 X-eGroups-Return: sentto-1101623-1813-977837579-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 26 Dec 2000 13:33:41 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.org Received: (EGP: mail-6_3_1_3); 26 Dec 2000 13:32:59 -0000 Received: (qmail 88586 invoked from network); 26 Dec 2000 13:32:58 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 26 Dec 2000 13:32:58 -0000 Received: from unknown (HELO cmailg7.svr.pol.co.uk) (195.92.195.177) by mta2 with SMTP; 26 Dec 2000 13:32:58 -0000 Received: from modem-8.niobium.dialup.pol.co.uk ([62.136.36.8] helo=62.136.36.8) by cmailg7.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14AuDg-0005Zg-00; Tue, 26 Dec 2000 13:32:50 +0000 To: rms@gnu.org, f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 26 Dec 2000 13:28 +0000 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Have you seen this. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2f58e9646f17bb50c7b49df5974a0f9 Status: R X-Status: N I think we should treat this ATA thing as a general trend:
there appears to be a move where all hardware and all
software will have to have a certificate within it, validating
its authenticity, and also neatly stitching up the market for
all big software and hardware manufacturers.

Then the peice de resistance, all internet access requires
a certificate also, and perhaps a "free" equivalent made
illegal.
Wont stop the mob, but it will stop all free software dead.

The certificates wont be optional, and you cant break them
without breaking DMCA. (and its equivalents that USA has
encouraged governments to adopt around the world).
Bye bye to being able to run your own software.

We must fight this cartel.
I suggest contacting your democratic represenative.
This will be the biggest ac of state paranoia since Cicero
rejected a fire service vor alexandria on the grounds of
any assembly of men being a threat to the state.

Jeff Davies
eGroups Sponsor
Click Here!
From asicdesigner2000@yahoo.com Wed Dec 27 05:17:08 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00302 for ; Wed, 27 Dec 2000 15:58:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 27 Dec 2000 15:58:46 +0100 (MET) Received: (qmail 19942 invoked by uid 0); 27 Dec 2000 04:17:20 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx01) with SMTP; 27 Dec 2000 04:17:20 -0000 X-eGroups-Return: sentto-1101623-1814-977890630-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 27 Dec 2000 04:17:18 -0000 X-Sender: asicdesigner2000@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 27 Dec 2000 04:17:09 -0000 Received: (qmail 37163 invoked from network); 27 Dec 2000 04:17:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 27 Dec 2000 04:17:09 -0000 Received: from unknown (HELO hj.egroups.com) (10.1.10.42) by mta3 with SMTP; 27 Dec 2000 05:18:14 -0000 X-eGroups-Return: asicdesigner2000@yahoo.com Received: from [10.1.2.161] by hj.egroups.com with NNFMP; 27 Dec 2000 04:17:09 -0000 To: f-cpu@egroups.com Message-ID: <92bqg4+hoev@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 24.147.25.49 From: asicdesigner2000@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Dec 2000 04:17:08 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Are f-cpu members interested in using NCSim? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0476799cefbd1a78be5255e274aec326 Status: R X-Status: N Hi - I work for Cadence on the NCSim team. I found the f-cpu project
while looking for VHDL/Verilog to add the list of NC compliant in-
house tested designs.

I noticed you are using a freeware simulator for your design. As I
work for the simulation group I am in a position to give free
simulation licenses of NCVHDL and NCVerilog to groups that qualify.
It comprises the mixed language simulator on either Linux or Win98
and the Signalscan waveviewer. There are no catches,and I would
expect the only thing that our marketing department would ask is that
you can acknowledge we give you simulation licenses at no-cost. I
would also request that you ship any source code with the supporting
files for NCSim.

Im in the process of signing up another group of users so now is a
good opportunity to say if you are interested. If so, can someone be
nominated as the main point of contact with me.

Martyn Pollard
eGroups Sponsor
Click Here!
From Michael Riepe Wed Dec 27 14:17:51 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00366 for ; Thu, 28 Dec 2000 19:08:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Dec 2000 19:08:04 +0100 (MET) Received: (qmail 23344 invoked by uid 0); 27 Dec 2000 18:40:54 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx22) with SMTP; 27 Dec 2000 18:40:54 -0000 X-eGroups-Return: sentto-1101623-1815-977942426-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 27 Dec 2000 18:40:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 27 Dec 2000 18:40:26 -0000 Received: (qmail 83431 invoked from network); 27 Dec 2000 18:40:25 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 27 Dec 2000 18:40:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.120) by mta3 with SMTP; 27 Dec 2000 19:41:28 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00446; Wed, 27 Dec 2000 14:17:51 +0100 Message-ID: <20001227141751.34034@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com Cc: asicdesigner2000@yahoo.com References: <92bqg4+hoev@eGroups.com> X-Mailer: Mutt 0.84e In-Reply-To: <92bqg4+hoev@eGroups.com>; from asicdesigner2000@yahoo.com on Wed, Dec 27, 2000 at 04:17:08AM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Dec 2000 14:17:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Are f-cpu members interested in using NCSim? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c648aa76fe27d30698d9df00941873b3 Status: R X-Status: N A little too late for an Xmas present, but... ;)

On Wed, Dec 27, 2000 at 04:17:08AM -0000, asicdesigner2000@yahoo.com wrote:
> Hi - I work for Cadence on the NCSim team. I found the f-cpu project
> while looking for VHDL/Verilog to add the list of NC compliant in-
> house tested designs.
>
> I noticed you are using a freeware simulator for your design. As I
> work for the simulation group I am in a position to give free
> simulation licenses of NCVHDL and NCVerilog to groups that qualify.
> It comprises the mixed language simulator on either Linux or Win98
> and the Signalscan waveviewer. There are no catches,and I would
> expect the only thing that our marketing department would ask is that
> you can acknowledge we give you simulation licenses at no-cost. I
> would also request that you ship any source code with the supporting
> files for NCSim.

If NCVHDL for Linux works, doesn't need too much RAM, and understands
a good portion of VHDL'93, I won't say no.  What are the system
requirements?

> Im in the process of signing up another group of users so now is a
> good opportunity to say if you are interested. If so, can someone be
> nominated as the main point of contact with me.

Yann?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From M P Wed Dec 27 23:35:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00443 for ; Thu, 28 Dec 2000 19:09:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Dec 2000 19:09:11 +0100 (MET) Received: (qmail 21150 invoked by uid 0); 27 Dec 2000 22:35:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx08) with SMTP; 27 Dec 2000 22:35:32 -0000 X-eGroups-Return: sentto-1101623-1816-977956514-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 27 Dec 2000 22:35:24 -0000 X-Sender: asicdesigner2000@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 27 Dec 2000 22:35:13 -0000 Received: (qmail 33462 invoked from network); 27 Dec 2000 22:35:13 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 27 Dec 2000 22:35:13 -0000 Received: from unknown (HELO web11704.mail.yahoo.com) (216.136.172.70) by mta2 with SMTP; 27 Dec 2000 22:35:12 -0000 Message-ID: <20001227223507.96438.qmail@web11704.mail.yahoo.com> Received: from [24.147.25.49] by web11704.mail.yahoo.com; Wed, 27 Dec 2000 14:35:07 PST To: Michael Riepe , f-cpu@egroups.com From: M P MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Dec 2000 14:35:07 -0800 (PST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Are f-cpu members interested in using NCSim? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 043f62596ad671244a4adf0cd8d20d21 Status: R X-Status: N > If NCVHDL for Linux works, doesn't need too much
> RAM, and understands
> a good portion of VHDL'93, I won't say no.  What are
> the system
> requirements?
>
> > Im in the process of signing up another group of
> users so now is a
> > good opportunity to say if you are interested. If
> so, can someone be
> > nominated as the main point of contact with me.
>
> Yann?
NCVHDL certainly works on Linux and as for system
requirements, I think anything that is PII or better
would be fine. You need more RAM as your design scales
up in size or you do gate level simulations. Its fully
v93 compliant.

If theres a few people that want to get it installed
and running, can someone can gather together a list of
names to send me.

I need, Name of User, hostid, email address, location
in world. I'll create you temporary licenses and then
you can try it out to see if you like it.
For the hostid of you machine (ethernet address) type;
%> hostid


Thanks, Martyn




__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 28 00:26:30 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00452 for ; Thu, 28 Dec 2000 19:09:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Dec 2000 19:09:13 +0100 (MET) Received: (qmail 18794 invoked by uid 0); 27 Dec 2000 23:27:29 -0000 Received: from c9.egroups.com (208.50.99.230) by 10.1.4.112 (mx12) with SMTP; 27 Dec 2000 23:27:29 -0000 X-eGroups-Return: sentto-1101623-1817-977959592-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 27 Dec 2000 23:26:46 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 27 Dec 2000 23:26:31 -0000 Received: (qmail 40544 invoked from network); 27 Dec 2000 23:26:31 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 27 Dec 2000 23:26:31 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 27 Dec 2000 23:26:31 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id AAA19534 for f-cpu@egroups.com; Thu, 28 Dec 2000 00:26:30 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Dec 2000 00:26:30 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] Are f-cpu members interested in using NCSim? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bff43f2969b4a8c0bc725a14569e6b88 Status: R X-Status: N hello,

>> Yann?
no way. i might get into trouble with my boss...

>NCVHDL certainly works on Linux and as for system
>requirements, I think anything that is PII or better
>would be fine. You need more RAM as your design scales
>up in size or you do gate level simulations. Its fully
>v93 compliant.
ok but i have no such machine.

>If theres a few people that want to get it installed
>and running, can someone can gather together a list of
>names to send me.
can someone else do it ? or maybe you, Martyn ?

As for the availability of the source files,
they are distributed under the strict sense of the
GPL and are freely available from f-cpu.de/design
before we get a fully working site at f-cpu.seul.org.

I hope that the certification of this company will
push the f-cpu developers to worry more about the
quality and the documentations of the design.

>Thanks, Martyn
have a lot of fun,
YG
eGroups Sponsor
Click Here!
From YG Thu Dec 28 00:33:41 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00455 for ; Thu, 28 Dec 2000 19:09:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 28 Dec 2000 19:09:13 +0100 (MET) Received: (qmail 26832 invoked by uid 0); 27 Dec 2000 23:34:10 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx17) with SMTP; 27 Dec 2000 23:34:10 -0000 X-eGroups-Return: sentto-1101623-1818-977960027-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 27 Dec 2000 23:34:07 -0000 X-Sender: whygee@cran.mit.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 27 Dec 2000 23:33:47 -0000 Received: (qmail 5619 invoked from network); 27 Dec 2000 23:33:46 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 27 Dec 2000 23:33:46 -0000 Received: from unknown (HELO cran.mit.edu) (18.244.0.188) by mta2 with SMTP; 27 Dec 2000 23:33:45 -0000 Received: (from whygee@localhost) by cran.mit.edu (8.9.3/8.9.3) id SAA30737 for f-cpu@egroups.com; Wed, 27 Dec 2000 18:33:41 -0500 Message-Id: <200012272333.SAA30737@cran.mit.edu> To: f-cpu@egroups.com From: YG MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 27 Dec 2000 18:33:41 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2365a114d6c0a37f12463cc6aa0103f Status: R X-Status: N cc: asicdesigner2000@yahoo.com

hi !

hi every body,

i'm writing this email in very difficult conditions,
here at the 17C3, no secure mail or login and
i revert to the Java SSH interface at seul.org.

i've heard about the message on the list but i haven't
checked my mailbox ... it's so uneasy ...

I have no means to be responsible of this tool,
first i usually have no time anymore,
second my computer is very cranky and slow,
and finally i would like someone else to volunteer.

If this software works under Unix,
we can maybe setup a server at one university,
probably Paris8 but the CPU ressources are
very limited : it's either an oldfashioned SPARC IPX
with 16MB RAM, or we setup a batch controller to spread
job snippets to the ALPHAs. Don't expect much.
i could do far better with the machines at Mentor...

If someone has an idea, please propose it, because
i can't support this proposition. Simili or
FreeHDL are less painful to use... i am glad that
the group has another opportunity anyway and i wish
that a solution will appear soon.

Anyway, the congress of the CCC is going very well and
i will miss this ambiance when i'll go back to Paris.
i regret that others couldn't come, really. We miss
Graham and Michael most, they are the absent heroes of
this congress ;-)

i'll be back in a week.
most of all : have fun and enjoy the new year's evening !!!

whygee, far from stuff but in the middle of the
hacker's world...


PS : one good thing that Cadence could do for us :
help us publish papers about the f-cpu, in the IEEE or ACM
magazines, as to ensure some garanties of prior art in the
design of CPUs. please ... we don't need anything more than that ...

.
eGroups Sponsor
Click Here!
From whygee@club-internet.fr Thu Dec 28 23:44:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02628 for ; Fri, 29 Dec 2000 05:12:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Dec 2000 05:12:27 +0100 (MET) Received: (qmail 23468 invoked by uid 0); 28 Dec 2000 22:46:21 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx15) with SMTP; 28 Dec 2000 22:46:21 -0000 X-eGroups-Return: sentto-1101623-1819-978043497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 28 Dec 2000 22:46:19 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 28 Dec 2000 22:44:56 -0000 Received: (qmail 96058 invoked from network); 28 Dec 2000 22:44:56 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 28 Dec 2000 22:44:56 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 28 Dec 2000 22:44:55 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id XAA18328 for f-cpu@egroups.com; Thu, 28 Dec 2000 23:44:54 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Dec 2000 23:44:54 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] conference Content-Type: multipart/mixed; boundary="=====================_978043494==_" X-UIDL: 14b75b12e3011bf8c46c5ce6689a082e Status: R X-Status: N --=====================_978043494==_ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello all,
i just finished the "rail" for the conference tomorrow.
this is a file that will be displayed while i speak, so
people can understand what it is about....

please submit your suggestions. It is not exhaustive but
if i missed a point, please warn me !

thanks,
YG
eGroups Sponsor
Click Here!
--=====================_978043494==_ Content-Type: text/html Content-Disposition: attachment; filename="conférence17C3.html" Content-Transfer-Encoding: quoted-printable
F-CPU Project
 Year 2000 status quo







Program

 Forewords, presentation and remarks

 Part 0 : The "Open Hardware" trend

     It's about FPGA, OpenCollector, IP, Hobbyists, SoC....
Part 1 : Organisation, Philosophy & History
  • What is the F-CPU ?
  • Goal/Purpose
  • Origins of the project
  • Web organisation
  • Evolution/history of the organisation (who does what)
  • Enabling technologies
  • Bus iness Model
  • Licences Issues
  • Patent Issues
  • Organisation Issues
  • Communication and collaborations
  • Projects
  • Ongoing discussions and extensions
  • Target platform
  • Calendar 2K
  • Association & Verein
  • Freedom : philosophie or religion ?
Questions from the audience

CD ?

Pause (3 mins)

Part 2 : F-CPU & FC0 scratch course

  • Background / Introduction to CPU architectures
    • The RISC backgrounds : the "canonical" MIPS
    • The lessons from the past
    • New applications, technologies, tools and requirements
    • The modifications and extensions of a canonical architecture
  • The F-CPU compatibility layers
  • Main characteristics of the F-CPU
  • The F-CPU ISA
  • Forward and backward compatibility
  • Main Characteristics of the FC0
  • The LEGO bricks
  • The design rules
Questions from the audience

CD ?

Au revoir & CU@18C3 !!!

Forewords

  • langage : english
  • Presentation of the team members
  • Presentation of the subjects and the program
  • About the workshop

Part 0 : The "Open Hardware" trend

  • Overview
  • families and licences
  • FPGA
  • existing Projects
  • interaction between the industry, researchers and hobbyists

Part 1 : Organisation, Philosophy & History

What is the F-CPU ?

There is no exact definition. There are several points of view, depending on everyone's expectations and culture.

The F-CPU as a microprocessor is the only fully-customizable SIMD, superpipelined, 64-bit microprocessor. The sources are distributed under the terms of the GNU Public Licence, supplemented with a strong distribution charter and a quality charter.

It is also a group of people working together around the globe who are trying to design this microprocessor. They communicate through mailing lists and emails on the Internet, or they try to share their knowledge during meetings. Their skills range from lurkers to professional electronic= ians, with different degrees of involvement.
 

Goal/Purpose

The goal of this project is to design a CPU that could replace and surpass existing CPUs in consumer or niche markets. It is not realistic to want the fastest CPU ever : we can't win against the big companies. But instead, the goal is to design the coolest, sexiest CPU of the 21th century, while still attempting to get the most perfomance. As the original design goal was to make a "Merced-killer", a more interesting competitor wou ld be the Alpha CPU class.

The team has adopted a "constitution" in order to solve the design confl= icts : 

           &nbs=
p; To develop and make freely available an
architecture, and all other intellectual property necessary
to fabricate one or more implementations of that architecture,
with the following priorities, in decreasing order of importance:

       1. Versatility and usefulness in as wi=
de a range of
             ap=
plications as possible
       2. Performance, emphasizing user-level=
 parallelism and
             de=
rived through intelligent architecture rather
             th=
an advanced silicon process
       3. Architecture lifespan and forward c=
ompatibility
&n
bsp;      4. Cost, including monetary and thermal =
considerations
We must limit ourselves to this goal, and not forget the initial purpose of this project. The goal is to make a CPU core, not a whole computer. It's already difficult enough and we don't have time to study the clusters, the PCB or the support software, these problem should be left to other specialized groups for the moment.
 

Origins of the project

Linux kernel contributors : Andrew D. Balsa, Rafael Reilova and Richard Gooch. They created the Freedom project in august 1998, as well as a mailin= g list, a first website, they studied a first design and triggered the F-CPU shockwave before they disapeared.

The original inspiration was a dream or a utopy based on real facts and their need for a "clean" platform that would make coding much easier than on today's machines.

Web organisation

  • web sites
  • mailing lists
    • f-cpu@egroups.com
    • f-cpu_france@egroups.com
    • fcpu-ger@egroups.com
  • Utopia Computing webring
  • IRC

Evolution/history of the organisation (who does what)

  • No leader : freedom of research + decision by consensus
  • People should become more responsible, more involved and more conscious about the value of their work : they have to make sure that their part works correctly, is correctly documented and well understood.

Enabling technologies and conditions

  • The GNU/Linux shockwave
  • Free/GNU/"Open" EDA tools
  • Trend towards "IP reuse" in the companies
  • Intel's monopoly with a shit

Business Model

Who will make the F-CPU ?

The F-CPU will first exist in software and in reprogrammable logic befor= e it can beturned into a real full-custom chip.

Making a chip is extremely expensive, a simple ASIC costs several millio= n dollars. A subscription has been proposed but

  • who will collect the money ?
  • who will invest the millions ?
  • what about the taxes ?
  • ...
We should concentrate on the design, and not loose time on things that we don't understand. The goal of the project is not to create a new company but a new design. We should let the industry play its role : manufacture and make money. This will provide a fair ground for innovation and new developments.

The easiest way to "make" the F-CPU is with sponsors : we provide them with a free design and they let us develop the chip using their tech nology. The first company that does it will have a lot of advance because the masks and the adapted files will be ready before the others. It spares us a lot of time, not filling papers to create a fundation or something similar.

Examples of cooperations with the "free HW world" : (see http://www.opencollector.org/news/)

  • OpenCores : 1 TSMC wafer, 0.25u, 5LM
  • Potential help from Cadence and Mentor Graphics

Licences Issues

see http://www.openco= llector.org/hardlicense/

Patent Issues

  • The inefficiency of the patent system : blocking patents, silly patents, workarounds, expensive...
  • Prior art and publication : who can help us to publish papers at the ACM and IEEE magazines ? (or something else)
  • The lizzard's strategy
  • Today we're safe because we don't build anything, we only describe the HW.

Organisation Issues

  • Leaving leaders : "dangling" websites and mailing lists (ie : f-cpu.tux.org= , f-cpu@egroups.com ...)
  • Lack of time
  • Parallel discussions on IRC, mailing lists, meetings etc... that are not resyncronised with the rest of the group
  • The old mailing list that is not controlled

Communication and collaborations

  • CCC : sponsors f-cpu.xxx name and web hosting
  • Press : several articles in different magazines around the world
  • Communication with other groups (or members thereof) : OpenCores, OpenColle= cor.org, LEON...
  • Group members in the Industry, Research or other branches, where they can lobby in favor of free designs

Projects

  • FC0 VHDL design
  • Manual
  • GCC port
  • GNL/XML (alternative code generators)
  • Website update

Ongoing discussions and extensions

  • F-bus
  • G-chip
  • multi-FC0
  • alternative programming methods

Target platform

Anywhere we need a good CPU...
From embedded appliances to multi-CPU servers, running whatever OS that will be ported to it.

Calendar 2K

  • dec. 1999 : 16C3
  • feb. 2000 : Linux Expo / Paris -> disccussions about the Metafort
  • mar. 2000 : DATE 2000, contacts with the industry
  • apr. 2000 : brand deposited in France, logo contest
  • sep. 2000 : EDA tool testings, master thesis
  • oct. 2000 : first VHDL package
  • nov. 2000 : multiplier, seul.org + Mentor Graphics
  • dec. 2000 : Cadence + 17C3

Association & Verein

Nothing yet ... It is not the biggest priority now...

Freedom : philosophie or religion ?

Should the "free hardware" be split into "churches", like in the Free Softw= are world ?
Should the "free hardware" be separated from the "open hardware" ?
Is there a risk of excess à la RMS ?
 
 

Conclusion :
FREEDOM means
"design and let design"
 
 


Part 2 : F-CPU & FC0 scratch course

 
 











Yann GUIDON, 27/28/29 décembre 2000, Berlin/HAKP/= 17C3

--=====================_978043494==_-- From Michael Riepe Thu Dec 28 15:44:33 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02637 for ; Fri, 29 Dec 2000 05:12:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Dec 2000 05:12:32 +0100 (MET) Received: (qmail 7390 invoked by uid 0); 29 Dec 2000 00:33:19 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx13) with SMTP; 29 Dec 2000 00:33:19 -0000 X-eGroups-Return: sentto-1101623-1820-978049977-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 29 Dec 2000 00:33:13 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 00:32:56 -0000 Received: (qmail 19948 invoked from network); 29 Dec 2000 00:32:56 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Dec 2000 00:32:56 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.69) by mta1 with SMTP; 29 Dec 2000 00:32:49 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00728; Thu, 28 Dec 2000 15:44:33 +0100 Message-ID: <20001228154433.01504@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200012272333.SAA30737@cran.mit.edu> X-Mailer: Mutt 0.84e In-Reply-To: <200012272333.SAA30737@cran.mit.edu>; from YG on Wed, Dec 27, 2000 at 06:33:41PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Dec 2000 15:44:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5cd8f0f0450075b1260e066211fdde11 Status: R X-Status: N On Wed, Dec 27, 2000 at 06:33:41PM -0500, YG wrote:

> I have no means to be responsible of this tool,
> first i usually have no time anymore,
> second my computer is very cranky and slow,
> and finally i would like someone else to volunteer.

Couldn't somebody from `The Verein' (or its French counterpart) do that?

And while we're talking about old & slow computers -- we definitely need
more computing power, and lots of RAM... my P166 with 96 MByte already
reaches its limits when I simulate the multiplier; a full-size gate-level
simulation is impossible on that machine.

I'd really like to have a sponsor (or two, or ...) who provides some
fast machines for a (probably longer) while, or at least some accounts
on them.  Half a dozen Celerons @ 500 MHz with 1/4 GByte of RAM each would
already be a big win.  Not to mention a dozen of those neat, flat (1U)
rack-mountable dual 933 MHz Coppermines that some vendors offer nowadays
(I tested one of them for iX recently; see the 2/2001 issue).

I guess I gotta go sponsor-hunting at the CeBIT (before you ask:
22.-28.3.2001 in Hannover, Germany -- 2...3 km from here).

Halali! ;)
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From asicdesigner2000@yahoo.com Fri Dec 29 03:20:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02643 for ; Fri, 29 Dec 2000 05:12:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Dec 2000 05:12:33 +0100 (MET) Received: (qmail 24750 invoked by uid 0); 29 Dec 2000 02:20:55 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx02) with SMTP; 29 Dec 2000 02:20:55 -0000 X-eGroups-Return: sentto-1101623-1821-978056429-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 29 Dec 2000 02:20:48 -0000 X-Sender: asicdesigner2000@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 02:20:29 -0000 Received: (qmail 75567 invoked from network); 29 Dec 2000 02:20:29 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 29 Dec 2000 02:20:29 -0000 Received: from unknown (HELO ho.egroups.com) (10.1.2.219) by mta3 with SMTP; 29 Dec 2000 03:21:34 -0000 X-eGroups-Return: asicdesigner2000@yahoo.com Received: from [10.1.10.93] by ho.egroups.com with NNFMP; 29 Dec 2000 02:20:28 -0000 To: f-cpu@egroups.com Message-ID: <92gsd3+7h9m@eGroups.com> In-Reply-To: <20001228154433.01504@thrai.stud.uni-hannover.de> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 24.147.25.49 From: asicdesigner2000@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Dec 2000 02:20:19 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 16ded8660c3940cfd8d097471c549629 Status: R X-Status: N > I guess I gotta go sponsor-hunting at the CeBIT (before you ask:
> 22.-28.3.2001 in Hannover, Germany -- 2...3 km from here).
Well if you can get the machines, Cadence will donate the simulator
NCSim for you to use when you are designing in either VHDL or Verilog.

If you want to put together a press release to get you more
visibility, then I will get our marketing department to approve it.
How many members are part of your team? Also, how far through the
project are you?

hope this helps, Martyn
eGroups Sponsor
Click Here!
From "Gregory Junker" Fri Dec 29 05:28:53 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA03817 for ; Fri, 29 Dec 2000 10:14:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Dec 2000 10:14:06 +0100 (MET) Received: (qmail 11578 invoked by uid 0); 29 Dec 2000 04:29:30 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx14) with SMTP; 29 Dec 2000 04:29:30 -0000 X-eGroups-Return: sentto-1101623-1822-978064146-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 29 Dec 2000 04:29:16 -0000 X-Sender: gjunker@one.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 04:29:06 -0000 Received: (qmail 43575 invoked from network); 29 Dec 2000 04:29:05 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 29 Dec 2000 04:29:05 -0000 Received: from unknown (HELO mail3.one.net) (206.112.192.120) by mta2 with SMTP; 29 Dec 2000 04:29:05 -0000 Received: from port-cvx1-313.access.one.net ([216.23.14.59] HELO tsunami ident: IDENT-NOT-QUERIED [port 10279]) by mail2.one.net with SMTP id <301156-532>; Thu, 28 Dec 2000 23:29:00 -0500 To: Message-ID: <000201c0714f$d606d160$699b01c0@shockwaveaudio.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal From: "Gregory Junker" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 28 Dec 2000 23:28:53 -0500 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] Have you seen this. Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C07125.ED30C960" X-UIDL: e1d05715f64f0cf2c60b18112271a657 Status: R X-Status: N ------=_NextPart_000_0003_01C07125.ED30C960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit it's clear that the article's author holds the technology in no high regard. It is also not clear whether the proposal will be open to public comment (I doubt that it will). One unlikely ally for the opposition, Microsoft, may possess the clout necessary to kill the measure, but it seems that for the typical average user, we are screwed. I suppose the best hope is that enough targeted outrage may defeat its unilateral implementation, much like the Pentium III ID controversy ended up with a BIOS opt-in compromise, with the eventual implementation a jumper setting on the drive (like we currently have for master/slave).... Beyond this, I don't see much that we as the consumer can do except patronize manufacturers that resist the urge to adopt this technology without option... greg -----Original Message----- From: Keyshaun [mailto:thekernel@subdimension.com] Sent: Monday, December 25, 2000 12:32 AM To: Alissa Leavitt; Brad Hanson; Hilary Brunt; hilary brunt; Byron Kruger; Chrissy; Chuck Grandgent; Dan; Deborah Meyerink; Brett Error; Freedom CPU; Suzanne Grandgent; GÅR¥; James; Janet Pancoast; Jessica Kirkham; Julie Davis; Kaylene Martin; Sarah A Lampe; ALISSA LEAVITT; Michael Richardson; Michelle Lutz; Shoshana; Holly Smith; Rachel Ann Soderquist; Steve Wyall; TairBear Subject: [f-cpu] Have you seen this. Hi folks. This will be the one and only time I send to my entire address book(contains friends and some of their familes). Never again will this happen, but I must state my outright objection to this attempt to put us, the people, the consumers in a form of bondage. The ATA standard is being expanded to adopt hardware level copy protection. Read about it at http://www.theregister.co.uk/content/2/15620.html From this there are 2 things that must happen. There must be a free hardware project to make ATA style disk as they are now that will never include copy protection. When I put data on a disk I never want to be limited in the way I can handel my information. Linux has shown us that we can be free in our operating system. Now opencollector.org and opencores.org are showing us that we may be free in our hardware. Even if you can't do anything just know that an industry is preparing to damage the ease of storage of our information. Let us all hope that we may avoid corperate bondage. Shaun Kruger eGroups Sponsor ------=_NextPart_000_0003_01C07125.ED30C960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
it's=20 clear that the article's author holds the technology in no high regard. It = is=20 also not clear whether the proposal will be open to public comment (I doubt= that=20 it will). One unlikely ally for the opposition, Microsoft, may possess the = clout=20 necessary to kill the measure, but it seems that for the typical average us= er,=20 we are screwed. I suppose the best hope is that enough targeted outrage may= =20 defeat its unilateral implementation, much like the Pentium III ID controve= rsy=20 ended up with a BIOS opt-in compromise, with the eventual implementation a= =20 jumper setting on the drive (like we currently have for=20 master/slave)....
 
Beyond=20 this, I don't see much that we as the consumer can do except patronize=20 manufacturers that resist the urge to adopt this technology without=20 option...
 
greg
 
-----Original Message-----
From: Keyshaun=20 [mailto:thekernel@subdimension.com]
Sent: Monday, December 25, = 2000=20 12:32 AM
To: Alissa Leavitt; Brad Hanson; Hilary Brunt; hilary= =20 brunt; Byron Kruger; Chrissy; Chuck Grandgent; Dan; Deborah Meyerink; Bre= tt=20 Error; Freedom CPU; Suzanne Grandgent; G=C5R=A5; James; Janet Pancoast; J= essica=20 Kirkham; Julie Davis; Kaylene Martin; Sarah A Lampe; ALISSA LEAVITT; Mich= ael=20 Richardson; Michelle Lutz; Shoshana; Holly Smith; Rachel Ann Soderquist; = Steve=20 Wyall; TairBear
Subject: [f-cpu] Have you seen=20 this.

Hi folks.  This will be the one and on= ly=20 time I send to my entire address
book(contains friends and some of the= ir=20 familes).  Never again will this
happen, but I must state my outr= ight=20 objection to this attempt to put us,
the people, the consumers in a fo= rm of=20 bondage.  The ATA standard is being
expanded to adopt hardware le= vel=20 copy protection.  Read about it at
http://www.the= register.co.uk/content/2/15620.html =20 From this there are 2
things that must happen.  There must be a f= ree=20 hardware project to make
ATA style disk as they are now that will neve= r=20 include copy protection.
When I put data on a disk I never want to be= =20 limited in the way I can
handel my information.  Linux has shown = us=20 that we can be free in our
operating system.  Now opencollector.o= rg=20 and opencores.org are showing us
that we may be free in our hardware.&= nbsp;=20 Even if you can't do anything just
know that an industry is preparing = to=20 damage the ease of storage of our
information.  Let us all hope t= hat=20 we may avoid corperate bondage.

Shaun Kruger



eGroups Sponsor=
3D"Click
------=_NextPart_000_0003_01C07125.ED30C960-- From JEAN Olivier Fri Dec 29 10:10:05 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA03924 for ; Fri, 29 Dec 2000 10:28:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 29 Dec 2000 10:28:47 +0100 (MET) Received: (qmail 8508 invoked by uid 0); 29 Dec 2000 09:10:11 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx16) with SMTP; 29 Dec 2000 09:10:11 -0000 X-eGroups-Return: sentto-1101623-1823-978081009-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 29 Dec 2000 09:10:10 -0000 X-Sender: O.JEAN@euronext.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 09:10:08 -0000 Received: (qmail 94822 invoked from network); 29 Dec 2000 09:10:08 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 29 Dec 2000 09:10:08 -0000 Received: from unknown (HELO nts07.sbfparis.com) (195.68.61.195) by mta3 with SMTP; 29 Dec 2000 10:11:13 -0000 Received: from nts06.bourse-de-paris.com (NTS06 [176.175.249.6]) by nts07.sbfparis.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Z1C916XG; Fri, 29 Dec 2000 10:07:13 +0100 Received: by NTS06 with Internet Mail Service (5.5.2448.0) id ; Fri, 29 Dec 2000 10:10:06 +0100 Message-ID: To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: JEAN Olivier MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Dec 2000 10:10:05 +0100 Reply-To: f-cpu@egroups.com Subject: RE: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6e111f229ef2e3d287fb479a429f7a46 Status: R X-Status: N Hi, Everybody.

My name is Olivier and I'm in charge of manuel ( translation into LaTeX ).
If you have need a lot of power to calculate or to simulate, i can propose
my computer ( K7 650 Mhz, 256 Mo ). I know it's a tiny computer but it can
simulate more quickly the elements of the F-CPU.

      Bye.

            OlivieR


> I have no means to be responsible of this tool,
> first i usually have no time anymore,
> second my computer is very cranky and slow,
> and finally i would like someone else to volunteer.

Couldn't somebody from `The Verein' (or its French counterpart) do that?

And while we're talking about old & slow computers -- we definitely need
more computing power, and lots of RAM... my P166 with 96 MByte already
reaches its limits when I simulate the multiplier; a full-size gate-level
simulation is impossible on that machine.

I'd really like to have a sponsor (or two, or ...) who provides some
fast machines for a (probably longer) while, or at least some accounts
on them.  Half a dozen Celerons @ 500 MHz with 1/4 GByte of RAM each would
already be a big win.  Not to mention a dozen of those neat, flat (1U)
rack-mountable dual 933 MHz Coppermines that some vendors offer nowadays
(I tested one of them for iX recently; see the 2/2001 issue).

I guess I gotta go sponsor-hunting at the CeBIT (before you ask:
22.-28.3.2001 in Hannover, Germany -- 2...3 km from here).

Halali! ;)
eGroups Sponsor
Click Here!
From Volker Birk Fri Dec 29 13:16:03 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA05574 for ; Sat, 30 Dec 2000 00:14:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Dec 2000 00:14:19 +0100 (MET) Received: (qmail 22485 invoked by uid 0); 29 Dec 2000 12:17:01 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 29 Dec 2000 12:17:01 -0000 X-eGroups-Return: sentto-1101623-1824-978092171-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 29 Dec 2000 12:16:17 -0000 X-Sender: vb@kanguruh.ebios.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 12:16:11 -0000 Received: (qmail 34821 invoked from network); 29 Dec 2000 12:16:11 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 29 Dec 2000 12:16:11 -0000 Received: from unknown (HELO kanguruh.ebios.de) (195.126.148.2) by mta1 with SMTP; 29 Dec 2000 12:16:09 -0000 Received: (from vb@localhost) by kanguruh.ebios.de (8.11.0/8.8.8) id eBTCG4020907 for f-cpu@egroups.com; Fri, 29 Dec 2000 13:16:04 +0100 To: f-cpu@egroups.com Message-ID: <20001229131603.A20204@ebios.de> User-Agent: Mutt/1.2.5i From: Volker Birk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Dec 2000 13:16:03 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] computing power Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7520eb11f670f62391590dfe206adf6c Status: R X-Status: N Hello,

it would be nice to support your work. We just sold some HP workstations
and have a HP C 3600 here in our office on February 2001. This
machine is only waiting then for beeing needed for supporting matters.

If you are interested in you could have access via ssh.

If you'll further be interested, I talk to HP to get a machine
only for you.

Yours,
VB.
--
*** ebios Informationssysteme, Germany      ***   vb@kangu:~ $ cd /pub/
*** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***   vb@kangu:/pub $ more beer
*** Phone +49-7524-93421 Fax +49-7524-93423 ***   Aaahhhh! That was good!
*** mailto:vb@ebios.de                      ***   vb@kangu:/pub $ _
eGroups Sponsor
Click Here!
From Michael Riepe Fri Dec 29 14:33:37 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05837 for ; Sat, 30 Dec 2000 01:48:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 30 Dec 2000 01:48:32 +0100 (MET) Received: (qmail 7722 invoked by uid 0); 29 Dec 2000 22:28:54 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 29 Dec 2000 22:28:54 -0000 X-eGroups-Return: sentto-1101623-1825-978128919-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 29 Dec 2000 22:28:53 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 29 Dec 2000 22:28:38 -0000 Received: (qmail 37548 invoked from network); 29 Dec 2000 22:28:38 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 29 Dec 2000 22:28:38 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.46) by mta1 with SMTP; 29 Dec 2000 22:28:35 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00474; Fri, 29 Dec 2000 14:33:37 +0100 Message-ID: <20001229143337.41250@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <20001229131603.A20204@ebios.de> X-Mailer: Mutt 0.84e In-Reply-To: <20001229131603.A20204@ebios.de>; from Volker Birk on Fri, Dec 29, 2000 at 01:16:03PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Dec 2000 14:33:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] computing power Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aace9ce4038c3cd353e547b7a6dc8170 Status: R X-Status: N On Fri, Dec 29, 2000 at 01:16:03PM +0100, Volker Birk wrote:

> it would be nice to support your work. We just sold some HP workstations
> and have a HP C 3600 here in our office on February 2001. This
> machine is only waiting then for beeing needed for supporting matters.

I remember that the C 360 (predecessor?) that I tested a year ago was
a nice and pretty fast computer (I liked the Visualize-fx6 graphics
processor very much ;), but IIRC it was a PA-RISC machine.  I'm afraid
I'll need an Intel box that runs both NT (for Simili) and Linux (for
NCVHDL and Vanilla VHDL) -- which also means that I must be able to reboot
it and switch OSes --, unless I can get simulation software for HP-UX.

> If you are interested in you could have access via ssh.
>
> If you'll further be interested, I talk to HP to get a machine
> only for you.

Don't they build Intel-based workstations, too?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From "Christian Schubert" Tue Jan 2 00:03:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00387 for ; Sun, 7 Jan 2001 23:06:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:06:21 +0100 (MET) Received: (qmail 14207 invoked by uid 0); 1 Jan 2001 23:03:48 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx01) with SMTP; 1 Jan 2001 23:03:48 -0000 X-eGroups-Return: sentto-1101623-1831-978390223-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 01 Jan 2001 23:03:47 -0000 X-Sender: cms@pnetservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 1 Jan 2001 23:03:43 -0000 Received: (qmail 21370 invoked from network); 1 Jan 2001 23:03:42 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 1 Jan 2001 23:03:42 -0000 Received: from unknown (HELO moutvdom01.kundenserver.de) (195.20.224.200) by mta2 with SMTP; 1 Jan 2001 23:03:42 -0000 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14DDzO-000430-00 for f-cpu@egroups.com; Tue, 2 Jan 2001 00:03:38 +0100 Received: from pd901a118.dip.t-dialin.net ([217.1.161.24] helo=apex) by mrvdom04.kundenserver.de with smtp (Exim 2.12 #2) id 14DDzP-0007MD-00 for f-cpu@egroups.com; Tue, 2 Jan 2001 00:03:39 +0100 Message-ID: <001f01c07447$0c200920$0200a8c0@schubert> To: References: <200012272333.SAA30737@cran.mit.edu> <20001228154433.01504@thrai.stud.uni-hannover.de> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Christian Schubert" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 2 Jan 2001 00:03:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4a8d916cfecdbb0ba0a0cb4009e53020 Status: R X-Status: N > Half a dozen Celerons @ 500 MHz with 1/4 GByte of RAM each would
> already be a big win.

Hey, damn, that's exactly my configuration... okay... got only one of
those *g*
eGroups Sponsor
Click Here!
From wxw Tue Jan 2 02:08:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00390 for ; Sun, 7 Jan 2001 23:06:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:06:22 +0100 (MET) Received: (qmail 10021 invoked by uid 0); 2 Jan 2001 01:21:07 -0000 Received: from ci.egroups.com (64.211.240.235) by 10.1.4.119 (mx19) with SMTP; 2 Jan 2001 01:21:07 -0000 X-eGroups-Return: sentto-1101623-1832-978398463-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ci.egroups.com with NNFMP; 02 Jan 2001 01:21:05 -0000 X-Sender: xunweiwu@nbu.edu.cn X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 2 Jan 2001 01:21:02 -0000 Received: (qmail 39437 invoked from network); 2 Jan 2001 01:21:02 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 2 Jan 2001 01:21:02 -0000 Received: from unknown (HELO center.nbu.edu.cn) (210.33.16.2) by mta3 with SMTP; 2 Jan 2001 02:22:06 -0000 Received: from cas09 ([210.33.16.106]) by center.nbu.edu.cn (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA07337 for ; Wed, 3 Jan 2001 09:08:37 +0800 Message-Id: <200101030108.JAA07337@center.nbu.edu.cn> To: "f-cpu@egroups.com" X-mailer: FoxMail 3.0 beta 2 [cn] From: wxw MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 2 Jan 2001 9:8:40 +0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-UIDL: 53c476053bacdf1ac720e96a7567c6a5 Status: R X-Status: N f-cpu=A3=AC=C4=FA=BA=C3=A3=A1
eGroups Sponsor=
3D"Click
From Keyshaun Tue Jan 2 04:23:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00402 for ; Sun, 7 Jan 2001 23:06:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:06:25 +0100 (MET) Received: (qmail 7984 invoked by uid 0); 2 Jan 2001 03:17:26 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx07) with SMTP; 2 Jan 2001 03:17:26 -0000 X-eGroups-Return: sentto-1101623-1833-978405436-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 02 Jan 2001 03:17:24 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 2 Jan 2001 03:17:15 -0000 Received: (qmail 11564 invoked from network); 2 Jan 2001 03:17:15 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 2 Jan 2001 03:17:15 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta1 with SMTP; 2 Jan 2001 03:17:14 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14DI2W-0000tu-00 for ; Mon, 01 Jan 2001 20:23:08 -0700 X-X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 1 Jan 2001 20:23:08 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] F-CPU host Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5f0d6d96c4419e4440810ffbbb720d2d Status: R X-Status: N Hi, I don't recall where the new address of the F-CPU page is going to be.
I need a secondary name server for my domain so I can get off of my
present provider.  At present I have Bind 8 running on my Linux box at
home.  All that is needed is a system to act as a slave to it.  Can anyone
tell me who to ask?

Shaun Kruger
eGroups Sponsor
Click Here!
From Michael Riepe Wed Jan 3 00:36:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00504 for ; Sun, 7 Jan 2001 23:06:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:06:53 +0100 (MET) Received: (qmail 13661 invoked by uid 0); 2 Jan 2001 23:37:19 -0000 Received: from hh.egroups.com (208.50.99.210) by 10.1.4.112 (mx12) with SMTP; 2 Jan 2001 23:37:19 -0000 X-eGroups-Return: sentto-1101623-1834-978478617-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 02 Jan 2001 23:37:18 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 2 Jan 2001 23:36:57 -0000 Received: (qmail 15232 invoked from network); 2 Jan 2001 23:36:56 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 2 Jan 2001 23:36:56 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.113) by mta3 with SMTP; 3 Jan 2001 00:38:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02271; Wed, 3 Jan 2001 00:36:51 +0100 Message-ID: <20010103003651.59032@thrai.stud.uni-hannover.de> To: F-CPU Mailing List X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 3 Jan 2001 00:36:51 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] EU_IMU docs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4a6b3568b9ec0d95e44ea5a98aa3a090 Status: R X-Status: N Happy New Year everybody!

I have put some preliminary HTML documentation for the multiplier in

      http://www.stud.uni-hannover.de/~michael/f-cpu/imu-guide.tar.gz

Please do not put this on the project's homepage yet.

Ciao,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Plan the wedding of your dreams! Click here.
Plan the wedding of your dreams! Click here.
From Nicolas Boulay Sat Dec 30 20:50:19 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00612 for ; Sun, 7 Jan 2001 23:07:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:07:23 +0100 (MET) Received: (qmail 10194 invoked by uid 0); 30 Dec 2000 19:44:04 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx23) with SMTP; 30 Dec 2000 19:44:04 -0000 X-eGroups-Return: sentto-1101623-1826-978205429-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 30 Dec 2000 19:44:03 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 30 Dec 2000 19:43:48 -0000 Received: (qmail 36590 invoked from network); 30 Dec 2000 19:43:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 30 Dec 2000 19:43:48 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 30 Dec 2000 19:43:47 -0000 Received: from ifrance.com (nas24-57.vlt.club-internet.fr [195.36.223.57]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA07522 for ; Sat, 30 Dec 2000 20:40:41 +0100 (MET) Message-ID: <3A4E3C7B.68CF1BBC@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20001229131603.A20204@ebios.de> <20001229143337.41250@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Dec 2000 20:50:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] computing power Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4c5fc3bc9c98c73fc246eeec6d77b3cb Status: R X-Status: N I know that there are normaly Cadence on this machine... So I'm waiting
for some ssh login ;p

Thinks,
nicO

Michael Riepe a =E9crit :
>
> On Fri, Dec 29, 2000 at 01:16:03PM +0100, Volker Birk wrote:
>
> > it would be nice to support your work. We just sold some HP works= tations
> > and have a HP C 3600 here in our office on February 2001. This > > machine is only waiting then for beeing needed for supporting mat= ters.
>
> I remember that the C 360 (predecessor?) that I tested a year ago was<= BR> > a nice and pretty fast computer (I liked the Visualize-fx6 graphics > processor very much ;), but IIRC it was a PA-RISC machine.  I'm a= fraid
> I'll need an Intel box that runs both NT (for Simili) and Linux (for > NCVHDL and Vanilla VHDL) -- which also means that I must be able to re= boot
> it and switch OSes --, unless I can get simulation software for HP-UX.=
>
> > If you are interested in you could have access via ssh.
> >
> > If you'll further be interested, I talk to HP to get a machine > > only for you.
>
> Don't they build Intel-based workstations, too?
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

eGroups Sponsor=
3D"Click
From Nicolas Boulay Sat Dec 30 21:30:04 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00615 for ; Sun, 7 Jan 2001 23:07:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:07:24 +0100 (MET) Received: (qmail 30902 invoked by uid 0); 30 Dec 2000 20:24:07 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx15) with SMTP; 30 Dec 2000 20:24:07 -0000 X-eGroups-Return: sentto-1101623-1827-978207814-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 30 Dec 2000 20:24:02 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 30 Dec 2000 20:23:33 -0000 Received: (qmail 36560 invoked from network); 30 Dec 2000 20:23:33 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 30 Dec 2000 20:23:33 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 30 Dec 2000 21:24:38 -0000 Received: from ifrance.com (nas23-241.vlt.club-internet.fr [195.36.173.241]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA16070 for ; Sat, 30 Dec 2000 21:23:31 +0100 (MET) Message-ID: <3A4E45CC.328D17F@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Dec 2000 21:30:04 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Computing power and sponsoring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d2248f0421c8f3be41c34c913532c87 Status: R X-Status: N Hello, Everybody.

Sponsoring are a good idea. BUT, how can we manage ourself if we receive
a machine ? I don't think that somebody just said, "ok, i take it. Does
it annoye anyone ?". We need machine online. But does anyone have a
permanent access to the net ? (capable to keep a full fonctionnal
machine).

For information, i just try to synthetise the LEON. For a "medium"
compilation, It take 4 hours to compile on a UltraSparc II 400 Mh with
512 Mo de RAM and 1.5 Go of swap (just bevore i receive a "out of memory
swap" at 1 Go ! ). It take around 30 Kgates without caches.

The scale of the time is around 1 / 250 000 for a simulation on the
vhdl...

nicO
eGroups Sponsor
Click Here!
From Michael Riepe Sun Dec 31 00:16:54 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00630 for ; Sun, 7 Jan 2001 23:07:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:07:28 +0100 (MET) Received: (qmail 11596 invoked by uid 0); 30 Dec 2000 23:17:07 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx22) with SMTP; 30 Dec 2000 23:17:07 -0000 X-eGroups-Return: sentto-1101623-1828-978218213-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 30 Dec 2000 23:17:04 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 30 Dec 2000 23:16:52 -0000 Received: (qmail 45019 invoked from network); 30 Dec 2000 23:16:52 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 30 Dec 2000 23:16:52 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.113) by mta3 with SMTP; 31 Dec 2000 00:17:55 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01948; Sun, 31 Dec 2000 00:16:54 +0100 Message-ID: <20001231001654.00454@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A4E45CC.328D17F@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A4E45CC.328D17F@ifrance.com>; from Nicolas Boulay on Sat, Dec 30, 2000 at 09:30:04PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 31 Dec 2000 00:16:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Computing power and sponsoring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f51758d24bcafbf4d752f31285c17570 Status: R X-Status: N On Sat, Dec 30, 2000 at 09:30:04PM +0100, Nicolas Boulay wrote:

> Sponsoring are a good idea. BUT, how can we manage ourself if we receive
> a machine ? I don't think that somebody just said, "ok, i take it. Does
> it annoye anyone ?". We need machine online. But does anyone have a
> permanent access to the net ? (capable to keep a full fonctionnal
> machine).

The easy solution is to get one machine for each developer :)

No, I don't have permanent connectivity, unfortunately.

> For information, i just try to synthetise the LEON. For a "medium"
> compilation, It take 4 hours to compile on a UltraSparc II 400 Mh with
> 512 Mo de RAM and 1.5 Go of swap (just bevore i receive a "out of memory
> swap" at 1 Go ! ). It take around 30 Kgates without caches.
>
> The scale of the time is around 1 / 250 000 for a simulation on the
> vhdl...

Lucky you... on my pentium, it takes *much* longer.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Ben Franchuk Fri Dec 29 18:25:14 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00645 for ; Sun, 7 Jan 2001 23:07:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:07:32 +0100 (MET) Received: (qmail 12583 invoked by uid 0); 31 Dec 2000 01:46:56 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx17) with SMTP; 31 Dec 2000 01:46:56 -0000 X-eGroups-Return: sentto-1101623-1829-978227211-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 31 Dec 2000 01:46:54 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 31 Dec 2000 01:46:51 -0000 Received: (qmail 56810 invoked from network); 31 Dec 2000 01:46:51 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 31 Dec 2000 01:46:51 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 31 Dec 2000 01:46:49 -0000 Received: from jetnet.ab.ca (dialin39.jetnet.ab.ca [207.153.6.39]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA00729 for ; Sat, 30 Dec 2000 18:33:54 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A4CC8FA.8FDFB48B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A4E45CC.328D17F@ifrance.com> <20001231001654.00454@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 29 Dec 2000 10:25:14 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Computing power and sponsoring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6984e9222a48ca70b34989507e65677a Status: R X-Status: N Michael Riepe wrote:
>> No, I don't have permanent connectivity, unfortunately.
>
> > For information, i just try to synthetise the LEON. For a "medium"
> > compilation, It take 4 hours to compile on a UltraSparc II 400 Mh with
> > 512 Mo de RAM and 1.5 Go of swap (just bevore i receive a "out of memory
> > swap" at 1 Go ! ). It take around 30 Kgates without caches.
> >
> > The scale of the time is around 1 / 250 000 for a simulation on the
> > vhdl...
>
> Lucky you... on my pentium, it takes *much* longer.

Lucky me... All my cpu designs can still be done with pencial and paper.
Ben.
PS I was reading on the PDP10 news group.
"40 bits of address is just too small for large systems"

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Alan Grimes Sun Dec 31 05:04:07 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00651 for ; Sun, 7 Jan 2001 23:07:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:07:33 +0100 (MET) Received: (qmail 32348 invoked by uid 0); 31 Dec 2000 04:02:33 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx05) with SMTP; 31 Dec 2000 04:02:33 -0000 X-eGroups-Return: sentto-1101623-1830-978235340-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 31 Dec 2000 04:02:32 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 31 Dec 2000 04:02:19 -0000 Received: (qmail 30428 invoked from network); 31 Dec 2000 04:02:19 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 31 Dec 2000 04:02:19 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta3 with SMTP; 31 Dec 2000 05:03:24 -0000 Received: from 66-44-65-184.s438.tnt6.lnhva.md.dialup.rcn.com ([66.44.65.184] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14CZhK-0002VU-00 for f-cpu@egroups.com; Sat, 30 Dec 2000 23:02:18 -0500 Message-ID: <3A4EB037.696E1E5E@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <3A4E45CC.328D17F@ifrance.com> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 30 Dec 2000 23:04:07 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Computing power and sponsoring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0199bf6e67422c3a7ab3c141b95805b8 Status: R X-Status: N Nicolas Boulay wrote:
> For information, i just try to synthetise the LEON. For a "medium"
> compilation, It take 4 hours to compile on a UltraSparc II 400 Mh with
> 512 Mo de RAM and 1.5 Go of swap (just bevore i receive a "out of
> memory swap" at 1 Go ! ). It take around 30 Kgates without caches.
>
> The scale of the time is around 1 / 250 000 for a simulation on the
> vhdl...

This is a very interesting problem. I would like to learn much more
about this and why it takes so long to execute.

My research is leading me to delieve that much of intelligence is
accomplished through combinational circuits, such as the ones that seem
to be taking so long to compute. So this is becoming an increasingly
important field for me to be studying.

-- thanx.

--
The 'apocolypse' happened in 1848.
Now if everybody would only just look... =\
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From Yann Guidon Wed Jan 3 01:44:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00771 for ; Sun, 7 Jan 2001 23:08:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:08:03 +0100 (MET) Received: (qmail 26937 invoked by uid 0); 3 Jan 2001 00:39:40 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx08) with SMTP; 3 Jan 2001 00:39:40 -0000 X-eGroups-Return: sentto-1101623-1835-978482299-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 03 Jan 2001 00:39:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 3 Jan 2001 00:38:19 -0000 Received: (qmail 93460 invoked from network); 3 Jan 2001 00:38:18 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 3 Jan 2001 00:38:18 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 3 Jan 2001 01:39:23 -0000 Received: from f-cpu.org (nas1-240.aub.club-internet.fr [195.36.150.240]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA10602 for ; Wed, 3 Jan 2001 01:38:14 +0100 (MET) Message-ID: <3A5275D7.11FCBE78@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20001229131603.A20204@ebios.de> <20001229143337.41250@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 03 Jan 2001 01:44:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] computing power Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac9d4e01bb351e0660cdcc65df670ede Status: R X-Status: N hi,

i'm back/sick/tired/etc from the Berlin trip.
things are heating now....

some patches for the manual will be available but
i can't test the LaTeX result yet. i'm an absolute
beginner with this stuff so it will take a few weeks
to get it running smoothly.

Michael Riepe wrote:
> On Fri, Dec 29, 2000 at 01:16:03PM +0100, Volker Birk wrote:
>
> > it would be nice to support your work. We just sold some HP workstations
> > and have a HP C 3600 here in our office on February 2001. This
> > machine is only waiting then for beeing needed for supporting matters.
>
> I remember that the C 360 (predecessor?) that I tested a year ago was
> a nice and pretty fast computer (I liked the Visualize-fx6 graphics
> processor very much ;), but IIRC it was a PA-RISC machine.  I'm afraid
> I'll need an Intel box that runs both NT (for Simili) and Linux (for
> NCVHDL and Vanilla VHDL) -- which also means that I must be able to reboot
> it and switch OSes --, unless I can get simulation software for HP-UX.

PA-RISC might also be another opportunity to test the design on another platform.
plus, even though HP-UX might be rather funky, the machine is somewhat faster
than a desktop box...

> > If you are interested in you could have access via ssh.
> >
> > If you'll further be interested, I talk to HP to get a machine
> > only for you.

well, how could anyone refuse this ? :-)

> Don't they build Intel-based workstations, too?

like everybody... But how does the memory system behaves, compared to a C3600 ? :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Wed Jan 3 01:45:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00774 for ; Sun, 7 Jan 2001 23:08:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:08:04 +0100 (MET) Received: (qmail 16997 invoked by uid 0); 3 Jan 2001 00:42:18 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx10) with SMTP; 3 Jan 2001 00:42:18 -0000 X-eGroups-Return: sentto-1101623-1836-978482390-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ei.egroups.com with NNFMP; 03 Jan 2001 00:41:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 3 Jan 2001 00:39:50 -0000 Received: (qmail 67722 invoked from network); 3 Jan 2001 00:39:50 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 3 Jan 2001 00:39:50 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 3 Jan 2001 00:39:49 -0000 Received: from f-cpu.org (nas1-240.aub.club-internet.fr [195.36.150.240]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA27552 for ; Wed, 3 Jan 2001 01:39:47 +0100 (MET) Message-ID: <3A527634.8C83F7CF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <20010103003651.59032@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 03 Jan 2001 01:45:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] EU_IMU docs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6387cf2264a04b751b9c9f9611ed7afb Status: R X-Status: N hi,

Michael Riepe wrote:
>
> Happy New Year everybody!
>
> I have put some preliminary HTML documentation for the multiplier in
>
>         http://www.stud.uni-hannover.de/~michael/f-cpu/imu-guide.tar.gz

yeah !

> Please do not put this on the project's homepage yet.

at least, it's in my personal preliminary snapshot.
it's useful anyway, even though it's not definitive.

have fun,
YG

> Ciao,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Wed Jan 3 03:47:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00813 for ; Sun, 7 Jan 2001 23:08:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:08:16 +0100 (MET) Received: (qmail 15380 invoked by uid 0); 3 Jan 2001 04:55:52 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx18) with SMTP; 3 Jan 2001 04:55:52 -0000 X-eGroups-Return: sentto-1101623-1837-978489711-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 03 Jan 2001 02:42:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 3 Jan 2001 02:41:50 -0000 Received: (qmail 72840 invoked from network); 3 Jan 2001 02:41:49 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 3 Jan 2001 02:41:49 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 3 Jan 2001 02:41:49 -0000 Received: from f-cpu.org (nas3-66.aub.club-internet.fr [195.36.145.66]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA23594 for ; Wed, 3 Jan 2001 03:41:35 +0100 (MET) Message-ID: <3A5292B5.58BDE2F2@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 03 Jan 2001 03:47:17 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] updates Content-Type: multipart/mixed; boundary="------------EEB344B0C281B689A62FD4FE" X-UIDL: 407536ffc1ff17a0eab7c87a2691f728 Status: R X-Status: N --------------EEB344B0C281B689A62FD4FE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

i've updated the config file with a new field : CHUNK_SIZE,
so it eases the design of the SIMD units. So please, Michael,
update your files too and change your asserts :-)

the IMU doc is very interesting and i hope that a more
"definitive" version will exist. At least i find it
satisfying :-)

If there are other stuffs to discuss, please speak out.

i've put a preliminary patch to the latex manual at
http://www.f-cpu.seul.org/manual/

If Michael can add his multiplier part to it, it will
be wonderful ! Erik Hansen will certainly do the same
soon for the incrementer.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
--------------EEB344B0C281B689A62FD4FE Content-Type: text/plain; charset=us-ascii; name="f-cpu_config.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f-cpu_config.vhdl" -- File F-CPU_config.vhdl -- (c) Yann GUIDON, oct. 21, 2000 -- whygee@f-cpu.org / f-cpu@egroups.com -- -- v0.2 : Michael Riepe changed F_RANGE -- v0.3 : YG specified the user-modifiable constants + GPL -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants. -- v0.5 : nov. 17, 2000, YG added SR_IRQ_BASE, SR_TRAP_BASE, -- SR_SYSCALL_BASE, SR_URL etc. -- v0.6 : nov. 26, 2000, YG moved some SR stuff to /VHDL/EU_sr -- v0.7 : dec. 31, 2000, YG added SR_MAX_CHUNK_SIZE and SR_TLBMISS_BASE -- -- current release : dec. 31, 2000 -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. -- -- * LOGMAXSIZE : Log2 of the Size of the registers in bytes. -- Can be any integer above or equal to 2. 2 corresponds to -- a 32-bit implementation, 3 correspods to a 64-bit version. -- This is the most important parameter, the first with -- which one can play. Be careful anyway. The 32-bit version will -- not work yet. -- -- * L1LogLines : Log2 of the NumBer of cache Lines (MUST be EVEN) -- This parameter determines how many L1 cache lines are implemented. -- It must be >=4 and _even_ because of the particular LRU mechanism -- used for this prototype. Allowed values are 4, 6 or 8 (that is : -- 16, 64 or 256 lines, or 512 bytes, 2KB or 8KB). More would correspond -- to a L2 cache... but are possible if you have enough ressources. -- -- * L1ABwidth :Address Bus width, in 32-byte chuncks (32+5=128GB) -- This determines the width of the address comparator of every L1 -- cache line. Be careful, too many bits might require a LOT of ressources. -- A reasonable value for a small design would be 16 (2MB of adressable -- physical memory), adapt as required. Warning : this parameter -- also determines how many address bits are physically implemented. -- -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ -- Number >=2, 3 corresponds to 64-bit registers constant LOGMAXSIZE : natural := 3; -- Size of the registers in bytes constant MAXSIZE : natural := 2**LOGMAXSIZE; -- Size of the registers in bits. constant UMAX : natural := MAXSIZE * 8; -- Range of a register width declaration. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- shortcut for a very common declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; -- MAX_CHUNK_SIZE in bits constant MAX_CHUNK_SIZE : natural := 64 ; ------------------------------------------------------ -- Some architectural constants, bound to FC0 only : ------------------------------------------------------ ------------------------------------------------------ -- L1 Caches (split instructions and data) ------------------------------------------------------ -- Data Bus width, or width of each cache line (32 bytes) constant L1DBwidth : natural := 256 ; -- Address Bus width, in 32-byte chuncks (32+5=128GB) constant L1ABwidth : natural := 32 ; -- Log2 of the NumBer of cache Lines (MUST be EVEN) -- (small number for the first attempts) constant L1LogLines : natural := 6 ; -- NumBer of cache Lines (2**L1LogLines) constant L1NBlines : natural := 2**L1LogLines ; ------------------------------------------------------ -- The Special Registers : (adapted from SR.h) -- -- What the user should modify when implementing the core : -- * SR_NUMBERS_val should be updated when the -- number of implemented SR changes. -- * SR_FAMILY_val specifies the type of core (FC0, FC1 etc). -- This is meant to be used for selecting particular code -- sections that are optimized for certain cores. -- * SR_STEPPING_val specifies the mask revision, for example. -- * SR_URL_val contains the Internet URL where the source, -- software and documentation are stored (64 char max.) -- -- DO NOT MODIFY the other constants unless the specifications -- change. New SRs will appear soon. Stay tuned. ------------------------------------------------------ -- number of SRs that are implemented in this model constant SR_NUMBERS : natural := 0; constant SR_NUMBERS_val : natural := SR_LAST_SR; -- F-CPU core number. remark : 0xFC0 = 4032d :-) constant SR_FAMILY : natural := 1; constant SR_FAMILY_val : natural := 4032; -- revision/implementation constant SR_STEPPING : natural := 2; constant SR_STEPPING_val : natural := 1; -- in bytes, a power of two >= 4 constant SR_MAX_SIZE : natural := 3; constant SR_MAX_SIZE_val : natural := MAXSIZE; -- Size attribute 1, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_1 : natural := 4; constant SR_SIZE_1_val : natural := 1; -- Size attribute 2, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_2 : natural := 5; constant SR_SIZE_2_val : natural := 2; -- Size attribute 3, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_3 : natural := 6; constant SR_SIZE_3_val : natural := 4; -- Size attribute 4, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_4 : natural := 7; constant SR_SIZE_4_val : natural := 8; -- SIMD chunck size, hardwired. constant SR_MAX_CHUNK_SIZE : natural := 8; constant SR_MAX_CHUNK_SIZE_val : natural := MAX_CHUNK_SIZE*8; -- R/W, Value is dynamic, incremented every cycle. constant SR_CYCLE : natural := 9; -- Protected, R/W, Controls the paged memory. constant SR_PAGING : natural := 10; -- IRQ, TRAP and SYSCALL jump tables : all are R/W in protected mode - only. constant SR_IRQ_BASE : natural := 11; -- For the hardware interrupt requests constant SR_IRQ_SIZE : natural := 12; constant SR_TRAP_BASE : natural := 13; -- faults and system errors constant SR_TRAP_SIZE : natural := 14; constant SR_SYSCALL_BASE : natural := 15; -- OS system call constant SR_SYSCALL_SIZE : natural := 16; constant SR_TLBMISS_BASE : natural := 17; -- TLB miss trap -- The URL registers must be modified to point to the manual, sources, patches etc. -- The registers are hardwired, format is ASCII and padded with 0s. constant SR_URL : natural := 18; -- 64 characters max. for a 64-bit version, 32 chars for a 32-bit version... constant SR_URL_size : natural := 8; constant SR_URL_val : string := "http://www.f-cpu.de/design/"; -- last SR : constant SR_LAST_SR : natural := 26; ------------------------------------------------------- -- The ROP2 unit : these constants specify the -- correspondance between the binary code and the actual -- operation. These data are copied here for convenience -- only, for example if you want to make an assembler in -- VHDL. Check the file ROP2.vhdl for more informations. -------------------------------------------------------- constant ROP2_AND : natural := 0; constant ROP2_ANDN : natural := 1; constant ROP2_XOR : natural := 2; constant ROP2_OR : natural := 3; constant ROP2_NOR : natural := 4; constant ROP2_XNOR : natural := 5; constant ROP2_ORN : natural := 6; constant ROP2_NAND : natural := 7; end FCPU_config; package body FCPU_config is -- The use of the ilog functions is not recommended inside -- the synthesisable processes, they are provided for -- convenience only. -- integer logarithm (rounded up) [MR version] function ilog (x : natural; base : natural := 2) return natural is variable y : natural := 1; begin while x > base ** y loop y := y + 1; end loop; return y; end ilog; -- integer logarithm (rounded up) [YG version] -- i wonder if there is an off-by-1 error... ? function ilog2 (x : natural) return natural is variable y : natural := 1; variable z : natural := 1; begin while x > z loop y := y + 1; z := z + z; -- you can notice the "little" enhancement :o) end loop; return y; end ilog2; ------------------------------------------------------ -- Some useful wrappers or functions could be included -- here if they are necessary for rest of the project. ------------------------------------------------------ end FCPU_config; --------------EEB344B0C281B689A62FD4FE-- From Wed Jan 3 16:47:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00897 for ; Sun, 7 Jan 2001 23:08:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:08:42 +0100 (MET) Received: (qmail 32215 invoked by uid 0); 3 Jan 2001 15:47:33 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 3 Jan 2001 15:47:33 -0000 X-eGroups-Return: sentto-1101623-1838-978536835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 03 Jan 2001 15:47:25 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 3 Jan 2001 15:47:14 -0000 Received: (qmail 65194 invoked from network); 3 Jan 2001 15:47:13 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 3 Jan 2001 15:47:13 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta3 with SMTP; 3 Jan 2001 16:48:18 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.11.1/8.11.1) with ESMTP id f03Fkkf10762 for ; Wed, 3 Jan 2001 16:46:46 +0100 (MET) Message-Id: <200101031546.f03Fkkf10762@essi.essi.fr> To: f-cpu@egroups.com In-Reply-To: User-Agent: IMHO/0.98.1 (Webmail for Roxen) From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 Jan 2001 16:47:53 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: xml to pdf translators =?iso-8859-1?q?=3F?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2dfd75f8aa8170a06fb7f373a4c79f66 Status: R X-Status: N -------------------
>
> Dear Steve,
>
> Could you point me towards some xml to pdf (etc.) translators ?
> Reply to f-cpu@egroups.com; I think others will also be interested.
>

If I remembre, try to look in the IBM blue project. It's the
collection of all their open source projects. And If I  rember their
is an xml-> pdf and a xml-> latex system

steve
eGroups Sponsor
Create your family tree at MyFamily.com!
From Nicolas Boulay Wed Jan 3 22:15:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00972 for ; Sun, 7 Jan 2001 23:09:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 07 Jan 2001 23:09:05 +0100 (MET) Received: (qmail 15783 invoked by uid 0); 3 Jan 2001 21:11:08 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx09) with SMTP; 3 Jan 2001 21:11:08 -0000 X-eGroups-Return: sentto-1101623-1839-978556095-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 03 Jan 2001 21:08:28 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 3 Jan 2001 21:08:14 -0000 Received: (qmail 13346 invoked from network); 3 Jan 2001 21:08:11 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 3 Jan 2001 21:08:11 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 3 Jan 2001 21:08:11 -0000 Received: from ifrance.com (nas12-173.vlt.club-internet.fr [195.36.162.173]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA03728 for ; Wed, 3 Jan 2001 22:08:08 +0100 (MET) Message-ID: <3A539656.CA5887C2@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <200101031546.f03Fkkf10762@essi.essi.fr> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 03 Jan 2001 22:15:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] a link about paper for computer science Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e58cb0c594a3293d702e917808169423 Status: R X-Status: N http://citeseer.nj.nec.com/directory.html
eGroups Sponsor
Wireless web technology from Motorola
From Jeff Davies Thu Jan 4 02:19:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01758 for ; Mon, 8 Jan 2001 00:41:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:41:21 +0100 (MET) Received: (qmail 28317 invoked by uid 0); 4 Jan 2001 01:28:02 -0000 Received: from ci.egroups.com (64.211.240.235) by 10.1.4.111 (mx11) with SMTP; 4 Jan 2001 01:28:02 -0000 X-eGroups-Return: sentto-1101623-1840-978571616-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 04 Jan 2001 01:28:01 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 4 Jan 2001 01:26:55 -0000 Received: (qmail 52143 invoked from network); 4 Jan 2001 01:26:54 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 4 Jan 2001 01:26:54 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta1 with SMTP; 4 Jan 2001 01:26:54 -0000 Received: from modem-84.potassium.dialup.pol.co.uk ([62.136.18.84] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14DzB6-0003Su-00 for f-cpu@egroups.com; Thu, 04 Jan 2001 01:26:52 +0000 Message-ID: <3A53CF9B.9CB60358@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <200101031546.f03Fkkf10762@essi.essi.fr> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 04 Jan 2001 01:19:23 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: xml to pdf translators ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 060bcb662cb0f08118a3c8bc2fa1cf5a Status: R X-Status: N You can use simple string replace (this is very easy via sed),

can't remember the switch format, use man. The command file will look
like this:
s/<DOCTITLE>/.title/
s/</DOCTITLE>/.end-title/

ok so the above isn't latex, can't remember what latex commands look
like.

or, for HTML, an example might be
s/<DOCTITLE>/<P><H1>/
s/</DOCTITLE>/</H1><P>/

or for more advanced stuff,
XSL. The easiest way to use XSL (and indeed XML) is via an XML editor
like Merlot.
Merlot is a GPL editor which is written in Java. (most XML stuff non-M$
seems to be written
in Java).
XSL is a sort of tag-replacement language, which is processed by an
"XSLT" engine.
Merlot had one built in, but you need to configure it for Linux use by
modifying a file in
a .jar (a java archive, a bit like a zip file).

Merlot runs under Java 1.3, or 1.2.2(?). - see www.merlot-xml.org

There are freely available html2ps and ps2pdf tools (search the web using
www.google.com).

Jeff Davies



vanderho@essi.fr wrote:

> -------------------
> >
> > Dear Steve,
> >
> > Could you point me towards some xml to pdf (etc.) translators ?
> > Reply to f-cpu@egroups.com; I think others will also be interested.
> >
>
> If I remembre, try to look in the IBM blue project. It's the
> collection of all their open source projects. And If I  rember their
> is an xml-> pdf and a xml-> latex system
>
> steve
eGroups Sponsor
Corbis - The Place for Pictures Online
From Yann Guidon Thu Jan 4 06:01:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01764 for ; Mon, 8 Jan 2001 00:41:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:41:23 +0100 (MET) Received: (qmail 14124 invoked by uid 0); 4 Jan 2001 04:55:35 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx17) with SMTP; 4 Jan 2001 04:55:35 -0000 X-eGroups-Return: sentto-1101623-1841-978584123-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 04 Jan 2001 04:55:34 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 4 Jan 2001 04:55:23 -0000 Received: (qmail 91819 invoked from network); 4 Jan 2001 04:55:22 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 4 Jan 2001 04:55:22 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 4 Jan 2001 05:56:27 -0000 Received: from f-cpu.org (nas3-17.ras.club-internet.fr [195.36.203.17]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA03205; Thu, 4 Jan 2001 05:55:19 +0100 (MET) Message-ID: <3A540399.98206CF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm Cc: JEAN Olivier From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 04 Jan 2001 06:01:13 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] man part1 : update Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 55db4700fb077fd69cf29b1e8e58a449 Status: R X-Status: N hello,

i installed some new SW on my computer,
played a bit and finally, the first part of
the (preliminary) manual is available from
http:///www.f-cpu.de/man_0.2/man_0.2.1.2_part1.src.tgz
http:///www.f-cpu.de/man_0.2/man_0.2.1.2_part1.ps.gz

except for the size of the letters on the cover,
the file is ok. I have vectorized the f-cpu logo
with tgif so it takes less room.

two other parts will follow...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Wireless web technology from Motorola
From Colin Marquardt Thu Jan 4 18:06:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01857 for ; Mon, 8 Jan 2001 00:41:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:41:49 +0100 (MET) Received: (qmail 1359 invoked by uid 0); 4 Jan 2001 18:01:23 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx23) with SMTP; 4 Jan 2001 18:01:23 -0000 X-eGroups-Return: sentto-1101623-1842-978631274-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 04 Jan 2001 18:01:19 -0000 X-Sender: colin@marquardt-home.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 4 Jan 2001 18:01:13 -0000 Received: (qmail 18159 invoked from network); 4 Jan 2001 18:00:26 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 4 Jan 2001 18:00:26 -0000 Received: from unknown (HELO post.webmailer.de) (192.67.198.65) by mta3 with SMTP; 4 Jan 2001 19:01:31 -0000 Received: from sigkill.marquardt-home.de (r1532.str.dial.surf-callino.de [213.21.16.8]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA24204 for ; Thu, 4 Jan 2001 19:00:21 +0100 (MET) Received: from colin by sigkill.marquardt-home.de with local (Exim 3.12 #1 (Debian)) id 14EDqb-0000Rc-00 for ; Thu, 04 Jan 2001 09:06:41 -0800 To: f-cpu@egroups.com X-Home-Page: http://www.marquardt-home.de X-GnuPG-Key: gpg --keyserver pgp.ai.mit.edu --recv-keys F53AF5C4 X-Fingerprint: F374 9BE1 87BE 8166 6D31 08BE 04CB CC2A F53A F5C4 Organization: I'd rather call it chaos. In-Reply-To: Michael Riepe's message of "Wed, 3 Jan 2001 00:36:51 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) From: Colin Marquardt MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: 04 Jan 2001 09:06:41 -0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] de.org.ccc posting about F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b394806c6b2a1340dba9b703fb30b241 Status: R X-Status: N Hi,

in de.org.ccc, there was a posting about the F-CPU (in German of
course). It is not that enthusiastic, to put it mildly...

The posting implies that the text is from http://www.fefe.de/ccc/17c3

| Message-ID: <slrn9572vf.tqn.fefe@baileys.convergence.de>
| From: Felix von Leitner <usenet-20010103@fefe.de>
| Newsgroups: de.org.ccc
| Subject: Re: 17. Chaos Communication Congress - Wie war ehr?
| Date: Wed, 03 Jan 2001 20:30:39 GMT

Cheers,
  Colin
eGroups Sponsor
Click Here!
From Michael Riepe Thu Jan 4 23:48:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01953 for ; Mon, 8 Jan 2001 00:42:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:20 +0100 (MET) Received: (qmail 1113 invoked by uid 0); 4 Jan 2001 22:48:20 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx03) with SMTP; 4 Jan 2001 22:48:20 -0000 X-eGroups-Return: sentto-1101623-1843-978648489-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 04 Jan 2001 22:48:18 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 4 Jan 2001 22:48:08 -0000 Received: (qmail 63025 invoked from network); 4 Jan 2001 22:48:04 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 4 Jan 2001 22:48:04 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.93) by mta3 with SMTP; 4 Jan 2001 23:49:08 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00983; Thu, 4 Jan 2001 23:48:02 +0100 Message-ID: <20010104234801.52439@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Colin Marquardt on Thu, Jan 04, 2001 at 09:06:41AM -0800 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 4 Jan 2001 23:48:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] de.org.ccc posting about F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dea618d3d52da77210253a5b5d62df82 Status: R X-Status: N On Thu, Jan 04, 2001 at 09:06:41AM -0800, Colin Marquardt wrote:

> in de.org.ccc, there was a posting about the F-CPU (in German of
> course). It is not that enthusiastic, to put it mildly...

I think we don't have to care about that.  Whether Felix likes the
F-CPU or not doesn't matter ;)

I think he expected something different -- things that are already
done (like the ISA) or in progress (implementation).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Create your family tree at MyFamily.com!
From Yann Guidon Fri Jan 5 01:40:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02013 for ; Mon, 8 Jan 2001 00:42:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:38 +0100 (MET) Received: (qmail 29640 invoked by uid 0); 5 Jan 2001 00:34:45 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx03) with SMTP; 5 Jan 2001 00:34:45 -0000 X-eGroups-Return: sentto-1101623-1844-978654862-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 05 Jan 2001 00:34:44 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 00:34:22 -0000 Received: (qmail 16052 invoked from network); 5 Jan 2001 00:34:20 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 5 Jan 2001 00:34:20 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 5 Jan 2001 01:35:25 -0000 Received: from f-cpu.org (nas1-171.ras.club-internet.fr [195.36.192.171]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA09146; Fri, 5 Jan 2001 01:34:14 +0100 (MET) Message-ID: <3A5517E2.5E5499C8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en Newsgroups: de.org.ccc To: Felix von Leitner Cc: fm References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 01:40:02 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9e41e91eaa39d9d559f4dbe89096688e Status: R X-Status: N Michael Riepe wrote:
> On Thu, Jan 04, 2001 at 09:06:41AM -0800, Colin Marquardt wrote:
> > in de.org.ccc, there was a posting about the F-CPU (in German of<= BR> > > course). It is not that enthusiastic, to put it mildly...
> I think we don't have to care about that.  Whether Felix likes th= e
> F-CPU or not doesn't matter ;)
sure, because it's his personal opinion, but the conference was not
totally OK. there were a lot of things that tainted the ambiance.

> I think he expected something different -- things that are already
> done (like the ISA) or in progress (implementation).
sure. selbstverst=E4ndlich. but last year's experience proved that we can't=
attack the conference directly with the technical stuffs, otherwise
we spend the day on this subject, and forget the "status quo" stu= ff.

Maybe next year we'll have to organise a separate workshop, with our
own schedule, so we can spend more time on this matter ?
The format of the workshops in the common rooms is too short and
unpractical. Maybe we should organize something like the "Haecksecente= r",
where they have their own room, their own stuff and staff...
This way, we'll make a general workshop like usually, and invite the
people to come to the special workshops in our room. More people could
thus speak with us and get the information they want.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"

to Felix :

hallo,

first, sorry if you expected something else from the conference :
it was clearly written on the subject : "year 2000 status quo". I think that this part ran rather smoothly and i explained the important stuff.

then, jeff completely messed everything, as you noticed. he blew a fuse
and others told me, after the conference, that he only thought about
his presentation, only the evening before. Everything was completely
fresh in his mind, and he did something like a university lesson,
not a presentation of the results of the F-CPU design team's work.

this was a complete nightmare for me. but who am i to rule over the others = ?
i'm rather angry, but the thing is done and i can't correct
the past. i'll be much more strict next year (and i was already rather
strict this year).

So what i read below is what most people think : they feel disapointed,
they want all the things right now and for free. then, they leave and
shut the door. i agree that the network presentation sucked big balls.

OTOH, if you want a detailed presentation of the architecture,
you have to read the manual. It takes some time to read it, around 6 hours,=
don't expect much from a 20mins presentation. maybe you left before
i did it. i was disturbed when i closed the debate, because i had
to repair all the things that were said before (plus, i was sick and very h= ungry).

Jeff doesn't know a fuck
about SMP (he's only a user, even though he teaches UNIX to NT people)
and what he presented doesn't reflect anything from what was discussed
in the group. Our goal is not to reinvent the VME-64 or PCI-X buses.
his presentation was wrong, long, he didn't know what he spoke about
(the n-cube routing algo is a well-known thing tought to undergrads
at the university !) and he was doing it on his own, not reporting to
anybody. OTOH, before i made my presentation, i published the script
on the mailing list and i asked for comments (but got none).

Next year, will be allowed as spokesperson, the people who have
an approved program for the presentation. Or maybe not. i don't
want the same kind of embarrass next year. it's not only for my
own little comfort, it's also the minimal respect of the audience
that is at stake.

now :

We're working on the update of the manual, which can be read at
http://www.f-cpu.de/man= /i7/summary.html (for the old version),
snapshots for the new LaTeX version are available from
http://www.f-cpu.seul.org/manu= al and you'll see that it's far
>from a bad design.

The early design files are available from http://www.f-cpu.de/design/
and the ongoing VHDL work is very interesting.

So i don't agree with you that the F-CPU is doomed so quickly.
ok, i know more than you about it, but one good way for you
to check is to come back next year and see how it has evolved.
I invite you to come and ask questions.

And yes, we'll have to make a serious de-briefing on the f-cpu mailing list= s.

Felix von Leitner wrote:
>
> Johannes Segitz <jusenet@Segitz.de> wrote:
> > Aber um mal auf was Anderes zu kommen: Was haltet ihr von dem F-C= PU
> > Projekt?
>
> Ich ging da mit gro=DFen Hoffnungen rein und kam mit der Gewi=DFheit r= aus,
> da=DF das Projekt gescheitert ist.  Schade eigentlich.
>
> Details aus http://www.fefe.d= e/ccc/17c3:
>
> 12:00 F-CPU.  Auf der Treppe habe ich Andreas getroffen, der Digi= tal-TV
> macht, und der meinte, er erz=E4hlt nichts neues und ich soll mir F-CP= U
> angucken, die h=E4tten gerade erste Pl=E4ne ver=F6ffentlich.  Au = ja, guck ich
> mir also F-CPU an und erwarta da jetzt Schaltpl=E4ne und Diskussionen = des
> Busprotokolls, ALU-Anordnungen, =DCberlegungen zum Instruction Set, so= was
> halt.  Stattdessen kommt da ein Franzose und erz=E4hlt von Mailin= glisten
> und Webseiten, von Lizenzen und wie sie sich finanzieren wollen. = Mhh.
> Nach einer Stunde gibt er das Mikrofon an einen anderen Franzosen ab,<= BR> > der dann von Hardware reden soll, und der konnte mich so gar nicht
> =FCberzeugen.  Er meinte, er wolle massive SMP-Performance und > Ausfallsicherheit und malte dann auf einer Folie eine Sterntopologie,<= BR> > die er mit "skaliert nicht und zu teuer" wegwischte, dann ka= m eine
> n-Cube Topologie, und dann ein Ring, und schlie=DFlich meinte er, da= =DF sie
> sich ja eine Erweiterung des Ringes =FCberlegt h=E4tten, die alle gute= n
> Eigenschaften vereinen w=FCrden, und das war dann... ein Bus?  Hu= h?
> Dazu kommt, da=DF er auf dem Bus Gigabyte (ja, byte, nicht -bit, was m= ich
> ja nachdenklich machte, ob der wirklich wei=DF, wovon er da spricht) > Ethernet sprechen will, und dann k=F6nnte man da einen I/O-Device habe= n
> und n CPU+RAM Devices, und er will pro CPU RAM haben und die CPUs soll= en
> sich die Last teilen, indem sie auf dem Bus sagen, wie ausgelastet sie=
> sind und dann halt Last =FCbernehmen k=F6nnen.  Rein technisch fu= nktioniert
> das nat=FCrlich so gar nicht, weil es von der Proze=DFpriorit=E4t abh= =E4ngt, ob
> eine CPU noch einen Proze=DF unterbringen kann oder nicht.  Und G= igabit
> Ethernet ist zwar keine so abwegige Idee (die PCI-Nachfolger =FCberleg= en
> das auch), aber billig ist das mit Sicherheit nicht, eher im Gegenteil= .
> Und nur ein I/O-Board zulassen zu wollen ist auch Humbug.  Als > Skalierungs-Konzept schlug er dann kurzerhand vor, Switches zwischen d= ie
> Busse zu tun.  Was soll ich sagen: F-CPU is doomed.  Wenn da= s ihr
> Techniker war, dann kommen die nicht weit.  Ach ja: gegen n-Cube = sprach
> seiner Meinung nach, da=DF das Routing problematisch w=E4re.  ?!?=
> Schade eigentlich.  Ich hatte mir da viel von versprochen.
>
> Fefe

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Wireless
From dantes@free.fr Fri Jan 5 02:04:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02022 for ; Mon, 8 Jan 2001 00:42:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:42 +0100 (MET) Received: (qmail 22305 invoked by uid 0); 5 Jan 2001 01:04:33 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx18) with SMTP; 5 Jan 2001 01:04:33 -0000 X-eGroups-Return: sentto-1101623-1845-978656661-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 05 Jan 2001 01:04:30 -0000 X-Sender: dantes@free.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 01:04:21 -0000 Received: (qmail 44979 invoked from network); 5 Jan 2001 01:04:21 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 5 Jan 2001 01:04:21 -0000 Received: from unknown (HELO postfix2.free.fr) (212.27.32.74) by mta3 with SMTP; 5 Jan 2001 02:05:25 -0000 Received: from dantes.free.fr (paris11-nas1-41-15.dial.proxad.net [212.27.41.15]) by postfix2.free.fr (Postfix) with ESMTP id 244827435E; Fri, 5 Jan 2001 02:04:18 +0100 (MET) Message-Id: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> X-Sender: dantes@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: f-cpu@egroups.com, usenet-20010103@fefe.de In-Reply-To: <3A5517E2.5E5499C8@f-cpu.org> References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> From: dantes@free.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 02:04:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 49e9eeac979da10d142c99d9c4de6a26 Status: R X-Status: N
OK, before retiring from this (something that has been through my mind for
a while), I'd like to answer to what have been said around about me. It's
not a egoistic behaviour, as I could easily screw up the list with
irrelevent mails about what I've heard after the conf. I don't want to,
basically, behave like Whygee ("I didn't do it, it's his fault"), I'd like
to explain.


At 01:40 05/01/01 +0100, Yann Guidon wrote:

[snip]

>then, jeff completely messed everything, as you noticed. he blew a fuse
>and others told me, after the conference, that he only thought about
>his presentation, only the evening before. Everything was completely
>fresh in his mind, and he did something like a university lesson,
>not a presentation of the results of the F-CPU design team's work.

YOU were meant to do the presentation of those results. OTOH, this subject
had been around fore a while, even if the idea was fairly fresh. I chatted
with people who came to the conf just to hear about it, and quite a few
people are interested into such a design.

>this was a complete nightmare for me. but who am i to rule over the others ?
>i'm rather angry, but the thing is done and i can't correct
>the past. i'll be much more strict next year (and i was already rather
>strict this year).

No comment.

>So what i read below is what most people think : they feel disapointed,
>they want all the things right now and for free. then, they leave and
>shut the door. i agree that the network presentation sucked big balls.

No comment again.

[snip]

>Jeff doesn't know a fuck about SMP

Thx a lot for you support...

>(he's only a user, even though he teaches UNIX to NT people)

I guess that's fairly irrelevent to the subject.

>and what he presented doesn't reflect anything from what was discussed
>in the group. Our goal is not to reinvent the VME-64 or PCI-X buses.
>his presentation was wrong, long, he didn't know what he spoke about
>(the n-cube routing algo is a well-known thing tought to undergrads
>at the university !) and he was doing it on his own, not reporting to
>anybody. OTOH, before i made my presentation, i published the script
>on the mailing list and i asked for comments (but got none).

You should have spend more time with the "group", as you call it, to listen
a bit. My presentation was maybe wrong in your opinion, but I guess it was
NOT long (a mere 15 minutes for a subject that could have lasted for hours).


The point not a lot of people seem to understand, and what I said in the
beginning of my part of the conf, is that that was only an awfully fast
overview of such a subject, and an ONGOING DISCUSSION (which will, by the
way, be closed, considering the feddback we've got). It means that it was
definitive, and that we needed people to bring ideas, not to criticize in
such a destructive way. I had to present the architectures we thought
about, and the ideas we had, all in 15 minutes. Basically impossible. Which
lead obviously to such a misunderstanding.

I made some mistakes, I know it. Sorry for calling a "bus" in a generic way
the network to link the cards. Felix noted it. But i have no shame saying
that if you can avoid routing problems, then avoid them. And the n-cube is
a cool concept, but of no use to people trying to design a cool Open
architecture with other goals than puser sheer supercomputing performances.

I feel sorry for the fact that only a few people I chatted with before
prior to the conference understood something and got interested. I also
feel sorry about such an agressive reaction. But I guess I've got nothing
really to answer. You're free to say whatever you want.


Farewell the F-CPU, I'll got on with something else to do.


Dantes
(Jeff)
eGroups Sponsor
Click Here!
From Nicolas Boulay Fri Jan 5 02:17:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02025 for ; Mon, 8 Jan 2001 00:42:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:43 +0100 (MET) Received: (qmail 2546 invoked by uid 0); 5 Jan 2001 01:11:10 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx05) with SMTP; 5 Jan 2001 01:11:10 -0000 X-eGroups-Return: sentto-1101623-1846-978657042-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 05 Jan 2001 01:11:09 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 01:10:42 -0000 Received: (qmail 63757 invoked from network); 5 Jan 2001 01:10:41 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 5 Jan 2001 01:10:41 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 5 Jan 2001 01:10:41 -0000 Received: from ifrance.com (nas14-188.vlt.club-internet.fr [195.36.164.188]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA03352 for ; Fri, 5 Jan 2001 02:10:37 +0100 (MET) Message-ID: <3A5520B2.A241FC76@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 02:17:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 510c79456db4e7526bedcf651fe14a6a Status: R X-Status: N That's very difficult to understand the debat. So if somebody could
translate what "Felix von Leitner" has written.

nicO

Yann Guidon a =E9crit :
>
> Michael Riepe wrote:
> > On Thu, Jan 04, 2001 at 09:06:41AM -0800, Colin Marquardt wrote:<= BR> > > > in de.org.ccc, there was a posting about the F-CPU (in Germa= n of
> > > course). It is not that enthusiastic, to put it mildly... > > I think we don't have to care about that.  Whether Felix lik= es the
> > F-CPU or not doesn't matter ;)
> sure, because it's his personal opinion, but the conference was not > totally OK. there were a lot of things that tainted the ambiance.
>
> > I think he expected something different -- things that are alread= y
> > done (like the ISA) or in progress (implementation).
> sure. selbstverst=E4ndlich. but last year's experience proved that we = can't
> attack the conference directly with the technical stuffs, otherwise > we spend the day on this subject, and forget the "status quo"= ; stuff.
>
> Maybe next year we'll have to organise a separate workshop, with our > own schedule, so we can spend more time on this matter ?
> The format of the workshops in the common rooms is too short and
> unpractical. Maybe we should organize something like the "Haeckse= center",
> where they have their own room, their own stuff and staff...
> This way, we'll make a general workshop like usually, and invite the > people to come to the special workshops in our room. More people could=
> thus speak with us and get the information they want.
>
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
>
> to Felix :
>
> hallo,
>
> first, sorry if you expected something else from the conference :
> it was clearly written on the subject : "year 2000 status quo&quo= t;.
> I think that this part ran rather smoothly and i explained the importa= nt
> stuff.
>
> then, jeff completely messed everything, as you noticed. he blew a fus= e
> and others told me, after the conference, that he only thought about > his presentation, only the evening before. Everything was completely > fresh in his mind, and he did something like a university lesson,
> not a presentation of the results of the F-CPU design team's work.
>
> this was a complete nightmare for me. but who am i to rule over the ot= hers ?
> i'm rather angry, but the thing is done and i can't correct
> the past. i'll be much more strict next year (and i was already rather=
> strict this year).
>
> So what i read below is what most people think : they feel disapointed= ,
> they want all the things right now and for free. then, they leave and<= BR> > shut the door. i agree that the network presentation sucked big balls.=
>
> OTOH, if you want a detailed presentation of the architecture,
> you have to read the manual. It takes some time to read it, around 6 h= ours,
> don't expect much from a 20mins presentation. maybe you left before > i did it. i was disturbed when i closed the debate, because i had
> to repair all the things that were said before (plus, i was sick and v= ery hungry).
>
> Jeff doesn't know a fuck
> about SMP (he's only a user, even though he teaches UNIX to NT people)=
> and what he presented doesn't reflect anything from what was discussed=
> in the group. Our goal is not to reinvent the VME-64 or PCI-X buses. > his presentation was wrong, long, he didn't know what he spoke about > (the n-cube routing algo is a well-known thing tought to undergrads > at the university !) and he was doing it on his own, not reporting to<= BR> > anybody. OTOH, before i made my presentation, i published the script > on the mailing list and i asked for comments (but got none).
>
> Next year, will be allowed as spokesperson, the people who have
> an approved program for the presentation. Or maybe not. i don't
> want the same kind of embarrass next year. it's not only for my
> own little comfort, it's also the minimal respect of the audience
> that is at stake.
>
> now :
>
> We're working on the update of the manual, which can be read at
> http://www.f-cpu.d= e/man/i7/summary.html (for the old version),
> snapshots for the new LaTeX version are available from
> http://www.f-cpu.seul.org= /manual and you'll see that it's far
> from a bad design.
>
> The early design files are available from http://www.f-cpu.de/design/
> and the ongoing VHDL work is very interesting.
>
> So i don't agree with you that the F-CPU is doomed so quickly.
> ok, i know more than you about it, but one good way for you
> to check is to come back next year and see how it has evolved.
> I invite you to come and ask questions.
>
> And yes, we'll have to make a serious de-briefing on the f-cpu mailing= lists.
>
> Felix von Leitner wrote:
> >
> > Johannes Segitz <jusenet@Segitz.de> wrote:
> > > Aber um mal auf was Anderes zu kommen: Was haltet ihr von de= m F-CPU
> > > Projekt?
> >
> > Ich ging da mit gro=DFen Hoffnungen rein und kam mit der Gewi=DFh= eit raus,
> > da=DF das Projekt gescheitert ist.  Schade eigentlich.
> >
> > Details aus http://www.f= efe.de/ccc/17c3:
> >
> > 12:00 F-CPU.  Auf der Treppe habe ich Andreas getroffen, der= Digital-TV
> > macht, und der meinte, er erz=E4hlt nichts neues und ich soll mir= F-CPU
> > angucken, die h=E4tten gerade erste Pl=E4ne ver=F6ffentlich. = ; Au ja, guck ich
> > mir also F-CPU an und erwarta da jetzt Schaltpl=E4ne und Diskussi= onen des
> > Busprotokolls, ALU-Anordnungen, =DCberlegungen zum Instruction Se= t, sowas
> > halt.  Stattdessen kommt da ein Franzose und erz=E4hlt von M= ailinglisten
> > und Webseiten, von Lizenzen und wie sie sich finanzieren wollen.&= nbsp; Mhh.
> > Nach einer Stunde gibt er das Mikrofon an einen anderen Franzosen= ab,
> > der dann von Hardware reden soll, und der konnte mich so gar nich= t
> > =FCberzeugen.  Er meinte, er wolle massive SMP-Performance u= nd
> > Ausfallsicherheit und malte dann auf einer Folie eine Sterntopolo= gie,
> > die er mit "skaliert nicht und zu teuer" wegwischte, da= nn kam eine
> > n-Cube Topologie, und dann ein Ring, und schlie=DFlich meinte er,= da=DF sie
> > sich ja eine Erweiterung des Ringes =FCberlegt h=E4tten, die alle= guten
> > Eigenschaften vereinen w=FCrden, und das war dann... ein Bus?&nbs= p; Huh?
> > Dazu kommt, da=DF er auf dem Bus Gigabyte (ja, byte, nicht -bit, = was mich
> > ja nachdenklich machte, ob der wirklich wei=DF, wovon er da spric= ht)
> > Ethernet sprechen will, und dann k=F6nnte man da einen I/O-Device= haben
> > und n CPU+RAM Devices, und er will pro CPU RAM haben und die CPUs= sollen
> > sich die Last teilen, indem sie auf dem Bus sagen, wie ausgelaste= t sie
> > sind und dann halt Last =FCbernehmen k=F6nnen.  Rein technis= ch funktioniert
> > das nat=FCrlich so gar nicht, weil es von der Proze=DFpriorit=E4t= abh=E4ngt, ob
> > eine CPU noch einen Proze=DF unterbringen kann oder nicht.  = Und Gigabit
> > Ethernet ist zwar keine so abwegige Idee (die PCI-Nachfolger =FCb= erlegen
> > das auch), aber billig ist das mit Sicherheit nicht, eher im Gege= nteil.
> > Und nur ein I/O-Board zulassen zu wollen ist auch Humbug.  A= ls
> > Skalierungs-Konzept schlug er dann kurzerhand vor, Switches zwisc= hen die
> > Busse zu tun.  Was soll ich sagen: F-CPU is doomed.  We= nn das ihr
> > Techniker war, dann kommen die nicht weit.  Ach ja: gegen n-= Cube sprach
> > seiner Meinung nach, da=DF das Routing problematisch w=E4re. = ; ?!?
> > Schade eigentlich.  Ich hatte mir da viel von versprochen. > >
> > Fefe
>
> --
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From Felix von Leitner Fri Jan 5 02:25:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02028 for ; Mon, 8 Jan 2001 00:42:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:45 +0100 (MET) Received: (qmail 26461 invoked by uid 0); 5 Jan 2001 01:25:18 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx03) with SMTP; 5 Jan 2001 01:25:18 -0000 X-eGroups-Return: sentto-1101623-1847-978657908-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 05 Jan 2001 01:25:17 -0000 X-Sender: leitner@codeblau.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 01:25:08 -0000 Received: (qmail 56111 invoked from network); 5 Jan 2001 01:25:08 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 Jan 2001 01:25:08 -0000 Received: from unknown (HELO codeblau.de) (212.84.209.34) by mta3 with SMTP; 5 Jan 2001 02:26:13 -0000 Received: (qmail 4831 invoked by uid 100); 5 Jan 2001 01:25:12 -0000 To: dantes@free.fr Cc: f-cpu@egroups.com Message-ID: <20010105022512.A4825@codeblau.de> References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> User-Agent: Mutt/1.2i In-Reply-To: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr>; from dantes@free.fr on Fri, Jan 05, 2001 at 02:04:10AM +0100 From: Felix von Leitner MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 5 Jan 2001 02:25:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4c511b23763043466d674a4d3835c1af Status: R X-Status: N I am sorry to see the devastating effect my comments had on the F-CPU
project.  I did not mean to talk down on Jeff as much as I did.  My bad
mood can be explained by CCC internal stressful discussions.  I have no
reason besides the few technical points I noted in the usenet posting to
believe that the CPU part of F-CPU will not or can not work.

Unfortunately, I don't have the time to correct the damage I have
apparently done.  This email reached me very unexpectedly, and I am
sorry!

I hope Jeff will reconsider!
It is by no means a bad thing to evaluate crazy ideas.  In the contrary,
that is what gives projects an edge!

Off the top of my head, I would like to make these technical remarks
about F-CPU and buses:

  1. get the target audience straight.  Many, if not all of the tricks
     to be used to speed up data transfers on buses is patented.  In my
     opinion, it is not feasible to design a new bus AND a new CPU.  I
     would just choose some el-cheapo off-the-shelf PC architecture as
     bus interface.  That way, people don't have to buy expensive
     evaluation boards to get pre-done motherboards.

  2. try to make the CPU as cool as possible.  All the modern CPU
     designs are "my dream architecture" type designs that have been
     stripped down until they looked feasible.  A free CPU design can
     leave the decision what to strip open, thus being much more
     flexible than other CPUs that are optimized for benchmarks and what
     the vendor thinks you will want to do with the CPU, not for what
     you actually want to do with the CPU.

Personally, I would be perfectly happy if F-CPU became a cool embedded
design with comparatively high memory latency.  Others may find memory
latency more important.  Try not to make any decisions for the user.

I am not sure if SIMD is the way to go.  I have always had the
impression that SIMD is a kludge to be faster in benchmarks and very few
selected applications.  While it is interesting for academics, I would
rather go for a compact architecture like ARM ;-)

But in the end, as long as a Forth system and later Linux will run on
it, everything is just fine.

Good luck to your project!

Felix
eGroups Sponsor
Click Here!
From Ben Franchuk Fri Jan 5 03:36:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02031 for ; Mon, 8 Jan 2001 00:42:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:46 +0100 (MET) Received: (qmail 7160 invoked by uid 0); 5 Jan 2001 01:58:50 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx01) with SMTP; 5 Jan 2001 01:58:50 -0000 X-eGroups-Return: sentto-1101623-1848-978659920-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 05 Jan 2001 01:58:49 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 01:58:39 -0000 Received: (qmail 58618 invoked from network); 5 Jan 2001 01:58:39 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 Jan 2001 01:58:39 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 5 Jan 2001 02:59:43 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA08079 for ; Thu, 4 Jan 2001 18:53:26 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A55334B.B4B3EB46@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <20010105022512.A4825@codeblau.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 04 Jan 2001 19:36:59 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8e65c795ea255213e35de5d8c933f295 Status: R X-Status: N Felix von Leitner wrote:
>
>   2. try to make the CPU as cool as possible.  All the modern CPU
>      designs are "my dream architecture" type designs that have been
>      stripped down until they looked feasible.  A free CPU design can
>      leave the decision what to strip open, thus being much more
>      flexible than other CPUs that are optimized for benchmarks and what
>      the vendor thinks you will want to do with the CPU, not for what
>      you actually want to do with the CPU.
<cut>
> Personally, I would be perfectly happy if F-CPU became a cool embedded
> design with comparatively high memory latency.  Others may find memory
> latency more important.  Try not to make any decisions for the user.
<cut>
> But in the end, as long as a Forth system and later Linux will run on
> it, everything is just fine.

Forth sounds like it would be a good language to test of memory latency.
No Matter how you slice it memory access is the killer.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Create your family tree at MyFamily.com!
From Nicolas Boulay Fri Jan 5 03:07:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02034 for ; Mon, 8 Jan 2001 00:42:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:47 +0100 (MET) Received: (qmail 26499 invoked by uid 0); 5 Jan 2001 02:01:08 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx14) with SMTP; 5 Jan 2001 02:01:08 -0000 X-eGroups-Return: sentto-1101623-1849-978660058-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 05 Jan 2001 02:01:07 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 02:00:58 -0000 Received: (qmail 85730 invoked from network); 5 Jan 2001 02:00:58 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 5 Jan 2001 02:00:58 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 5 Jan 2001 02:00:57 -0000 Received: from ifrance.com (nas14-188.vlt.club-internet.fr [195.36.164.188]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA11426 for ; Fri, 5 Jan 2001 02:57:35 +0100 (MET) Message-ID: <3A552C7C.CFF5D29E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 03:07:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 19c8a3234af02281b86aa452b826e4c5 Status: R X-Status: N > Farewell the F-CPU, I'll got on with something else to do.
>
> Dantes
> (Jeff)

What a pity !

For the conference, Dantes made, maybe, to much simplification (Bus !=
Network). But some german person think that the whygee show were much
too long and boring. (around 1 hours to speak about no technical stuff
and a lot of repetitions). So we believe that the presentation need more
dynamism. And Dantes made his presentation about an "on going" debat
(which should take place at the end, previously). And then Whygee take
45 min to present all the technical stuff of the core. And the next
workshop take us out because we were late.

The basic idea express by Dantes was to make some hot swap capabilites
with plugin cards composed with ram+cpu. The network will made around
gigabit ethernet link (the electrical part) because it's well known (and
free ? ). With 8 ethernet links, we can reach the true gigabytes. This
made around 8*2*2*2 (2 pairs with 2 ways and 2 time 500Mhz) pins for a
multidirectionnal link, very few in fact ! compare to the normal usual
parrallel bus (for a link at 133 Mhz compare to the >500 Mhz for the
giga ethernet link and without to many routing problem with long wires).

Each cpu will have a full 128 bits wide bus for DDR-SDRAM and "some"
gigabit ethernet links for system communication. Then you can connect
the cpu or a IO sub-system for ide/scsi bus, usb, rs232 ...

The "delicat" part is : what taken as network ? Everybody knows that i
prefer a double ring. Double to make a failure revovery (to plug and
replug one card without shutting down the system). And its easy to
expand wihtout having any routing problems. Routing is a problem for
latency and complexty of the nod. But this needs much more explication.

Everybody should stay calm ! We need everybody.

nicO
eGroups Sponsor
Create your family tree at MyFamily.com!
From Nicolas Boulay Fri Jan 5 03:18:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02037 for ; Mon, 8 Jan 2001 00:42:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:42:48 +0100 (MET) Received: (qmail 12791 invoked by uid 0); 5 Jan 2001 02:12:00 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx10) with SMTP; 5 Jan 2001 02:12:00 -0000 X-eGroups-Return: sentto-1101623-1850-978660709-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ck.egroups.com with NNFMP; 05 Jan 2001 02:11:59 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 02:11:48 -0000 Received: (qmail 2022 invoked from network); 5 Jan 2001 02:11:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 5 Jan 2001 02:11:48 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 5 Jan 2001 02:11:47 -0000 Received: from ifrance.com (nas14-188.vlt.club-internet.fr [195.36.164.188]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA27656 for ; Fri, 5 Jan 2001 03:11:44 +0100 (MET) Message-ID: <3A552F05.B63CF4AE@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <20010105022512.A4825@codeblau.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 03:18:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 364dfc23b21c7cace1676326d7eb6d23 Status: R X-Status: N Nobody sleep tonight !

Felix von Leitner a =E9crit :
>
> I am sorry to see the devastating effect my comments had on the F-CPU<= BR> > project.  I did not mean to talk down on Jeff as much as I did.&n= bsp; My bad
> mood can be explained by CCC internal stressful discussions.  I h= ave no
> reason besides the few technical points I noted in the usenet posting = to
> believe that the CPU part of F-CPU will not or can not work.
>
> Unfortunately, I don't have the time to correct the damage I have
> apparently done.  This email reached me very unexpectedly, and I = am
> sorry!
>
> I hope Jeff will reconsider!

I hope so ! It's a very kind person.

> It is by no means a bad thing to evaluate crazy ideas.  In the co= ntrary,
> that is what gives projects an edge!
>
> Off the top of my head, I would like to make these technical remarks > about F-CPU and buses:
>
>   1. get the target audience straight.  Many, if not al= l of the tricks
>      to be used to speed up data transfers on= buses is patented.  In my
>      opinion, it is not feasible to design a = new bus AND a new CPU.  I
>      would just choose some el-cheapo off-the= -shelf PC architecture as
>      bus interface.  That way, people do= n't have to buy expensive
>      evaluation boards to get pre-done mother= boards.
>

That's very difficult because a bus isn't just a state machine written
in VHDL. You need electrical spec and a lot of knownledge about ECM and
physical problem. That's why i propose to use 1000 baseT, but we have to verify that isn't too much patented. In the other hand, only the chip
maker wil pay the bill.

>   2. try to make the CPU as cool as possible.  All the = modern CPU
>      designs are "my dream architecture&= quot; type designs that have been
>      stripped down until they looked feasible= .  A free CPU design can
>      leave the decision what to strip open, t= hus being much more
>      flexible than other CPUs that are optimi= zed for benchmarks and what
>      the vendor thinks you will want to do wi= th the CPU, not for what
>      you actually want to do with the CPU. >

That what is suppose to be done.

> Personally, I would be perfectly happy if F-CPU became a cool embedded=
> design with comparatively high memory latency.  Others may find m= emory
> latency more important.  Try not to make any decisions for the us= er.
>

me too ;p

> I am not sure if SIMD is the way to go.  I have always had the > impression that SIMD is a kludge to be faster in benchmarks and very f= ew

All what we need is a good compiler to use the instruction. i'm looking
about that. The idea behind that is how we can easly expand the power of a cpu without out-of-order execution. The easiest way is to have a cpu
which could have this register double in size without recompiling the
C-sources. An other way is SMT.

> selected applications.  While it is interesting for academics, I = would
> rather go for a compact architecture like ARM ;-)
>

Yes, but 64 bits and SIMD, it's just the size above ;p

> But in the end, as long as a Forth system and later Linux will run on<= BR> > it, everything is just fine.
>
??
> Good luck to your project!
>
> Felix
nicO
eGroups Sponsor=
3D"Corbis<= /td>
From Yann Guidon Fri Jan 5 07:55:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02073 for ; Mon, 8 Jan 2001 00:43:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:00 +0100 (MET) Received: (qmail 4540 invoked by uid 0); 5 Jan 2001 06:50:14 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx05) with SMTP; 5 Jan 2001 06:50:14 -0000 X-eGroups-Return: sentto-1101623-1851-978677403-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 05 Jan 2001 06:50:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 06:50:02 -0000 Received: (qmail 29722 invoked from network); 5 Jan 2001 06:50:02 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Jan 2001 06:50:02 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 5 Jan 2001 06:50:01 -0000 Received: from f-cpu.org (nas4-77.ras.club-internet.fr [195.36.203.77]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA20516 for ; Fri, 5 Jan 2001 07:49:58 +0100 (MET) Message-ID: <3A556FF8.9C7F626@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 07:55:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2ccffa26d164737a6518f525493def6d Status: R X-Status: N hi,

Nicolas Boulay wrote:
> > Farewell the F-CPU, I'll got on with something else to do.
> >
> > Dantes
> > (Jeff)
>
> What a pity !
i hope that it's a temporary disagreement.

> For the conference, Dantes made, maybe, to much simplification (Bus !=
> Network). But some german person think that the whygee show were much
> too long and boring. (around 1 hours to speak about no technical stuff
> and a lot of repetitions).
yes i agree that it seemed long.
On one hand, we come to present what we have done during the past year.
On the other hand, the audience is rather new to the subject and expects
an architecture scratch course.
It's like going to a peepshow and getting a lesson about AIDS.

But i see no point of repeating what i say every year. They can read
the manual and consult the CCC archives. They asked no question. Not
many people were interested in fact. maybe 20 persons, us included,
were really concerned. So : what to do ? satisfy the 20 concerned
persons, or the remaining crowd ? It's a dilemma that can't be
solved without new troubles.

> So we believe that the presentation need more dynamism.
i agree.

> And Dantes made his presentation about an "on going" debat
> (which should take place at the end, previously).
why did Jeff decide to reschedule his speech ?

> And then Whygee take
> 45 min to present all the technical stuff of the core. And the next
> workshop take us out because we were late.
i correct you : i had 20 minutes sharp for the core.
it was very difficult for me.

> The basic idea express by Dantes was to make some hot swap capabilites
> with plugin cards composed with ram+cpu.
nothing really groundbreaking... it's common place in the telco and
industrial applications.

> The network will made around
> gigabit ethernet link (the electrical part) because it's well known (and
> free ? ). With 8 ethernet links, we can reach the true gigabytes. This
> made around 8*2*2*2 (2 pairs with 2 ways and 2 time 500Mhz) pins for a
> multidirectionnal link, very few in fact !
you forget several things... no chip can do 8xGb links. you forget the ground
connexions in the backplane. This backplane is going to be extremely expensive,
and i doubt that a "f-cpu hacker" can afford a 30-layer PCB made with Teflon.
the idea of the ethernet is simply science fiction.

> compare to the normal usual
> parrallel bus (for a link at 133 Mhz compare to the >500 Mhz for the
> giga ethernet link and without to many routing problem with long wires).
i compare what can be compared.
the current idea is simply not realistic.
i want a draft, numbers, several case studies, feasibility studies,
the reference of the used parts, the protocol, the VHDL...

> Each cpu will have a full 128 bits wide bus for DDR-SDRAM and "some"
> gigabit ethernet links for system communication. Then you can connect
> the cpu or a IO sub-system for ide/scsi bus, usb, rs232 ...

i don't care about this side. you're simply going into a lot of troubles.

one way to realize this is by searching the parts on the catalogs or databases.
one connector is going to cost as much as the f-cpu chip. One backplane
will cost 100KF to prototype. it's not a "hacker's architecture".

> The "delicat" part is : what taken as network ? Everybody knows that i
> prefer a double ring. Double to make a failure revovery (to plug and
> replug one card without shutting down the system). And its easy to
> expand wihtout having any routing problems. Routing is a problem for
> latency and complexty of the nod. But this needs much more explication.
routing is not a problem. the routing algorithms are known for a long time
and there's already a large variety of choices.

> Everybody should stay calm ! We need everybody.
yep. F-CPU didn't appear in one day.

anyway, the debate has shifted very far from the initial
requirement, and it's rather off-topic. What we need is a simple
parallel interface to connect the F-CPU to the G-chip and other
G-chips. Since they're on the same PCB, we don't need hotswap.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Corbis - The Place for Pictures Online
From Yann Guidon Fri Jan 5 07:55:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02076 for ; Mon, 8 Jan 2001 00:43:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:02 +0100 (MET) Received: (qmail 11636 invoked by uid 0); 5 Jan 2001 06:50:17 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx03) with SMTP; 5 Jan 2001 06:50:17 -0000 X-eGroups-Return: sentto-1101623-1852-978677405-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 05 Jan 2001 06:50:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 06:50:05 -0000 Received: (qmail 20211 invoked from network); 5 Jan 2001 06:50:05 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 5 Jan 2001 06:50:05 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 5 Jan 2001 06:50:04 -0000 Received: from f-cpu.org (nas4-77.ras.club-internet.fr [195.36.203.77]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA01045 for ; Fri, 5 Jan 2001 07:46:40 +0100 (MET) Message-ID: <3A556FF9.47B38B3B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <20010105022512.A4825@codeblau.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 07:55:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 663ba6245a98daf2cd393f2a4d7d1183 Status: R X-Status: N hallo,

Felix von Leitner wrote:
> I am sorry to see the devastating effect my comments had on the F-CPU
> project.  I did not mean to talk down on Jeff as much as I did.  My bad
> mood can be explained by CCC internal stressful discussions.  I have no
> reason besides the few technical points I noted in the usenet posting to
> believe that the CPU part of F-CPU will not or can not work.

i don't think it's devastating. We have to voice out what we think,
and the experience at the 17C3 is quite new : 5 french f-cpu persons
together at the same place, it's a world record. the social relationships
are quite different than usually, too, and we have to find a new equilibrium.
it's not a devastation, it's an evolution.

> Unfortunately, I don't have the time to correct the damage I have
> apparently done.  This email reached me very unexpectedly, and I am
> sorry!
>
> I hope Jeff will reconsider!
> It is by no means a bad thing to evaluate crazy ideas.  In the contrary,
> that is what gives projects an edge!

even 6 months ago, the f-cpu mailing list was known to be a place where really
crazy ideas fly around. every month, someone came with yet another revolutionary
idea, it was discussed during one day, one week or one month, then disapeared.
we were used (more or less) to this "natural" dynamics.

At least, these people knew that these ideas were "teaching toys", so they
played with it until it broken, and then they find a new toy and start playing
again with a bit more experience. The people who came with the craziest ideas
were not the craziest people. But these people would not have made big claims
before an audience such as the 17C3. making claims is another mark of amateurism.

I have the feeling that what Jeff has presented is the equivalent of the
M2M era of the f-cpu. This is a bunch of raw ideas, without real coherence
and strength, that are exposed naively. Now i hope that it won't stop here,
just like the first F-CPU architecture. I hope that Jeff, Cedric, Nico (and whoever
wants) will at least make some first drafts and dig into the subject.
The architecture can be a failure, but the idea can't.  Now they have to
go until the end.


> Off the top of my head, I would like to make these technical remarks
> about F-CPU and buses:
>
>   1. get the target audience straight.  Many, if not all of the tricks
>      to be used to speed up data transfers on buses is patented.
patents are not a real problem today. in the future, it can be,
but we have enough time to find workarounds.

>      In my opinion, it is not feasible to design a new bus AND a new CPU.
yup.

>      I would just choose some el-cheapo off-the-shelf PC architecture as
>      bus interface.  That way, people don't have to buy expensive
>      evaluation boards to get pre-done motherboards.
RTFM, PC motherboards are a real mess, we'll spend 10 years and swallow
millions of $ before something works. plus, Socket 7 is dead slow and
the others are not better.

>   2. try to make the CPU as cool as possible.
that's what i said during the conference ;-)

>      All the modern CPU
>      designs are "my dream architecture" type designs that have been
>      stripped down until they looked feasible.
unfortunately, not everybody has the same dream. Particularly true for
the f-cpu : everybody expects something different and it's hard
to ask for compromises. when people dream, they want 'everything or nothing'
and they leave after a short while because they're not satisfied.

>      A free CPU design can
>      leave the decision what to strip open, thus being much more
>      flexible than other CPUs that are optimized for benchmarks and what
>      the vendor thinks you will want to do with the CPU, not for what
>      you actually want to do with the CPU.
>
> Personally, I would be perfectly happy if F-CPU became a cool embedded
> design with comparatively high memory latency.  Others may find memory
> latency more important.  Try not to make any decisions for the user.

i don't think it's a problem for the current implementation of the f-cpu.
you can easily scale it down to 32 bits and scale up later.

> I am not sure if SIMD is the way to go.  I have always had the
> impression that SIMD is a kludge to be faster in benchmarks and very few
> selected applications.
SIMD is just another way to see the vector computers. Instead of streaming
the memory to the execution units, the registers are simply wider.
of course, you don't really need SIMD to write emails, but it's useful
if you do some substring search or any vector-like algo, such as
updating the screen, filtering sound or simply : playing MP3, displaying
JPEG and MPEG, computing 3D...

>  While it is interesting for academics, I would
> rather go for a compact architecture like ARM ;-)
if so, you can start your own ARM clone but it's already encumbered by the
patents. if you want an "embedded clone", try the LEON.

> But in the end, as long as a Forth system and later Linux will run on
> it, everything is just fine.
i don't know if FORTH will be first implemented. It's not a huge problem
in fact, but a FORTH compiler would get some serious boost over interpreted FORTH,
simply with the register reallocation... hehe...

> Good luck to your project!
thanks, and CU@18C3,

> Felix
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Corbis - The Place for Pictures Online
From Yann Guidon Fri Jan 5 07:55:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02079 for ; Mon, 8 Jan 2001 00:43:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:03 +0100 (MET) Received: (qmail 11681 invoked by uid 0); 5 Jan 2001 06:50:19 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx03) with SMTP; 5 Jan 2001 06:50:19 -0000 X-eGroups-Return: sentto-1101623-1853-978677407-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 05 Jan 2001 06:50:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 06:50:07 -0000 Received: (qmail 29879 invoked from network); 5 Jan 2001 06:50:06 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 Jan 2001 06:50:06 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 5 Jan 2001 07:51:11 -0000 Received: from f-cpu.org (nas4-77.ras.club-internet.fr [195.36.203.77]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA05864 for ; Fri, 5 Jan 2001 07:50:02 +0100 (MET) Message-ID: <3A556FFA.482D3F6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <3A5517E2.5E5499C8@f-cpu.org> <3A5520B2.A241FC76@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 07:55:54 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c11ffc13c7c2f397d979dd4c82a4c249 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> That's very difficult to understand the debat. So if somebody could
> translate what "Felix von Leitner" has written.
3/4 is a dump of Jeff's presentation, with striking keywords
and despaired comments. i'll let Felix detail that.
and of course, he was disapointed by my status quo
presentation, all he expected was ISA discussions,
ALU structures etc. (which i understand).

well, i presume that it was more or less the thoughts
of a lot of people. a 2h conference is not enough anyway.
we'll have to find a new organisation for the 18C3,
so we can make our own workshops.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Corbis - The Place for Pictures Online
From Yann Guidon Fri Jan 5 07:55:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02082 for ; Mon, 8 Jan 2001 00:43:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:04 +0100 (MET) Received: (qmail 19350 invoked by uid 0); 5 Jan 2001 06:50:29 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx02) with SMTP; 5 Jan 2001 06:50:29 -0000 X-eGroups-Return: sentto-1101623-1854-978677408-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 05 Jan 2001 06:50:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 06:50:08 -0000 Received: (qmail 20772 invoked from network); 5 Jan 2001 06:50:08 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 5 Jan 2001 06:50:08 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 5 Jan 2001 06:50:08 -0000 Received: from f-cpu.org (nas4-77.ras.club-internet.fr [195.36.203.77]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA01065 for ; Fri, 5 Jan 2001 07:46:43 +0100 (MET) Message-ID: <3A556FFC.C7E61ADA@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 07:55:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 88cb9117067a3d263c32bb978dffdc37 Status: R X-Status: N good morning, everybody,

it seems that we're effectively, finally, doing this CCC de-briefing.
it is more movemented than expected, but the latent situation couldn't
stay forever. Now that everybody is awake, let's go back to cartesian mode...

dantes@free.fr wrote:
> OK, before retiring from this (something that has been through my mind for
> a while),
for how long ? for what reason ?

> I'd like to answer to what have been said around about me. It's
> not a egoistic behaviour, as I could easily screw up the list with
> irrelevent mails about what I've heard after the conf. I don't want to,
> basically, behave like Whygee ("I didn't do it, it's his fault"), I'd like
> to explain.
i didn't expect less.

> At 01:40 05/01/01 +0100, Yann Guidon wrote:
>
> [snip]
>
> >then, jeff completely messed everything, as you noticed. he blew a fuse
> >and others told me, after the conference, that he only thought about
> >his presentation, only the evening before. Everything was completely
> >fresh in his mind, and he did something like a university lesson,
> >not a presentation of the results of the F-CPU design team's work.
>
> YOU were meant to do the presentation of those results.
and you wanted to do it and you did it.

> OTOH, this subject had been around fore a while,
a while ? We started the discussion about the F-BUS and the
G-chip in november, and you didn't even speak about it.
OTOH, the FC0 started around may 1999. it is stable and documented.

> even if the idea was fairly fresh. I chatted
> with people who came to the conf just to hear about it, and quite a few
> people are interested into such a design.
of course, these people don't know about the other existing bus specifications.
IIRC, the industrial PCI standard does hotswap and multimaster.
OTOH, the industrial PCI boards are ... well, extremely expensive.
and i doubt that your solutions are cheaper.

> [snip]
>
> >Jeff doesn't know a fuck about SMP
> Thx a lot for you support...
some keywords you pronounced proved that.
i don't want to play the old fart, but you said yourself that
you're not an electronician. if you ever read the specs of
an existing "multimaster bus" (ie : VME or PCI), you'll learn
a lot of things.

> >(he's only a user, even though he teaches UNIX to NT people)
> I guess that's fairly irrelevent to the subject.
xcuz.

> >and what he presented doesn't reflect anything from what was discussed
> >in the group. Our goal is not to reinvent the VME-64 or PCI-X buses.
> >his presentation was wrong, long, he didn't know what he spoke about
> >(the n-cube routing algo is a well-known thing tought to undergrads
> >at the university !) and he was doing it on his own, not reporting to
> >anybody. OTOH, before i made my presentation, i published the script
> >on the mailing list and i asked for comments (but got none).
>
> You should have spend more time with the "group", as you call it, to listen
> a bit.
what group ?
remember what you said the day before : "go to bed whygee, i care for the rest".
nothing comes out (yet) from your discussions with Cedric and nicO.
OTOH, there are some drafts from me and Cedric, about the F-bus and
the G-chip, that are far more on-topic, but you decided to skip that.
The F-bus is a direct connexion to the F-CPU, while your presentation
was speaking about something more general and useless at our present level.
but i'm still waiting for some drafts on the "H-Arch".
Btw, i don't encourage you to keep this name because in german,
"Arsch" means "ass". it could be misunderstood and we can avoid this tiny
trouble before it gets spread.

> My presentation was maybe wrong in your opinion, but I guess it was
> NOT long (a mere 15 minutes for a subject that could have lasted for hours).
correction. montre en main : 40 minutes.
i kept my watch under the eyes during all the conference.
it helped me to be punctual (1 minute of precision, personal record).

> The point not a lot of people seem to understand, and what I said in the
> beginning of my part of the conf, is that that was only an awfully fast
> overview of such a subject, and an ONGOING DISCUSSION (which will, by the
> way, be closed, considering the feddback we've got). It means that it was
> definitive, and that we needed people to bring ideas, not to criticize in
> such a destructive way. I had to present the architectures we thought
> about, and the ideas we had, all in 15 minutes. Basically impossible. Which
> lead obviously to such a misunderstanding.
I think that you didn't catch the meaning of this conference.
As you have seen, the persons that attended are waiting for something
that is interesting (yup), groundbreaking (of course) and solid.
what you presented was not solid. worse, it didn't seem serious
(of course, you were dead serious). I mean : some of your key assertions are
false (just read some specialized books at Jussieu, it's one of the
best libraries i know about almost everything) even though they might
seem brilliant to ignorant people. And THIS is wrong to me.
I don't like when people come to the f-cpu mailing list and ask wrong questions,
because it's a nightmare to answer them and correct their beliefs.

what if i started to speak about something that just dropped from the
top of my head ? the audience would start to believe what i say
(because i'm believing what i say) and they would both spread the news
and think about this. But if my speach is not "backed up", serious
and "real" (in the sense that it really exists, with all the necessary
references and documentation), what will happen ? first, an overflow
because much time is spent explaining the idea, less time coding.
second : with the saturation, nothing gets done, the discussions shift
towards other subjects, and people leave because they're disapointed.

This is more or less the story of the F-CPU.

> I made some mistakes, I know it. Sorry for calling a "bus" in a generic way
> the network to link the cards. Felix noted it. But i have no shame saying
> that if you can avoid routing problems, then avoid them.
it depends what you call "problem". if "problem" is a case that you
don't know how to solve, read the litterature about it, invent something
or bypass it. If you can bypass it (a bus is yet another kind of "problem",
did you study the deadlocks ?), ok, if you can't, you have to "crunch" the
problem.

> And the n-cube is
> a cool concept, but of no use to people trying to design a cool Open
> architecture with other goals than puser sheer supercomputing performances.
the "problem" is that "a cool Open architecture" is not very precise.
depending on what i've seen, it should work first, without hidden problem.
What you propose is a bag of HW bugs. i leave you the SW troubles as
a homework.

> I feel sorry for the fact that only a few people I chatted with before
> prior to the conference understood something and got interested. I also
> feel sorry about such an agressive reaction. But I guess I've got nothing
> really to answer. You're free to say whatever you want.
i was angry because i didn't have a way to express the trouble.
maybe that the direct and objective discussion will help.

> Farewell the F-CPU, I'll got on with something else to do.
whatever you decide, it's up to you, but remember that what you presented
at the conference is similar to a promise. If we drop everything every year,
people won't think about the F-CPU as something serious.
I think that a whole year won't be too much for you to prove that
you are right. If you drop, it's like you agree that you're not serious.
you are invited at the 18C3, but with at least some results.

> Dantes
> (Jeff)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Corbis - The Place for Pictures Online
From Ben Franchuk Fri Jan 5 05:33:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02085 for ; Mon, 8 Jan 2001 00:43:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:06 +0100 (MET) Received: (qmail 17764 invoked by uid 0); 5 Jan 2001 06:57:15 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx03) with SMTP; 5 Jan 2001 06:57:15 -0000 X-eGroups-Return: sentto-1101623-1855-978677830-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 05 Jan 2001 06:57:15 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 06:57:09 -0000 Received: (qmail 33189 invoked from network); 5 Jan 2001 06:57:08 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 5 Jan 2001 06:57:08 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 5 Jan 2001 06:57:06 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id XAA22544 for ; Thu, 4 Jan 2001 23:51:54 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A554EB6.C32B6237@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 04 Jan 2001 21:33:58 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8f67009559f0b5d239fdb29ed022fe6a Status: R X-Status: N Yann Guidon wrote:

> > The network will made around
> > gigabit ethernet link (the electrical part) because it's well known (and
> > free ? ). With 8 ethernet links, we can reach the true gigabytes. This
> > made around 8*2*2*2 (2 pairs with 2 ways and 2 time 500Mhz) pins for a
> > multidirectionnal link, very few in fact !
> you forget several things... no chip can do 8xGb links. you forget the ground
> connexions in the backplane. This backplane is going to be extremely expensive,
> and i doubt that a "f-cpu hacker" can afford a 30-layer PCB made with Teflon.
> the idea of the ethernet is simply science fiction.

True but Optical links @ 2 Gbs is becoming more common.
http://www.chipcenter.com/pld/pldf084.htm
My 2 cents worth umm .02 cents with inflation.:)
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Corbis - The Place for Pictures Online
From Michael Riepe Fri Jan 5 16:13:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02109 for ; Mon, 8 Jan 2001 00:43:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:19 +0100 (MET) Received: (qmail 15331 invoked by uid 0); 5 Jan 2001 17:51:37 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx05) with SMTP; 5 Jan 2001 17:51:37 -0000 X-eGroups-Return: sentto-1101623-1856-978717088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 05 Jan 2001 17:51:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 17:51:28 -0000 Received: (qmail 8425 invoked from network); 5 Jan 2001 17:48:04 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 5 Jan 2001 17:48:04 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta1 with SMTP; 5 Jan 2001 17:47:57 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00720; Fri, 5 Jan 2001 16:13:34 +0100 Message-ID: <20010105161334.43300@thrai.stud.uni-hannover.de> To: F-CPU Mailing List X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 5 Jan 2001 16:13:34 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] 17C3 aftermath Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: cbb72e6a28167105f2fd3b664222b306 Status: R X-Status: N Hello everybody!

After reading Felix' comment on the F-CPU presentation and all the
reactions on this list, I feel that I have something to say, too ;)

First, Felix' article wasn't very polite.  Sure, he was disappointed,<= BR> and he obviously had expected something very different, but that's no
excuse for being rude and desctructive.  His statement that "F-CP= U is
doomed" is simply too ridiculous to be taken seriously.

Second, it became very clear to me that the F-Bus/G-Chip/Topology
discussion is far from being finished.  Unfortunately, most of this discussion seems to take place in the "ivory tower" of the french= mailing
list or in real-life meetings somewhere near the "hottest spot" o= f the
F-CPU community (Paris, France).  I can understand that it's easier to=
discuss things in your native language, and that some of you may feel
very uncomfortable with english (I prefer german, too), but I think that all non-trivial discussions should be moved to the international list.
The F-CPU Project is supposed to be open, but de facto parts of it aren't.<= BR>
Third, I don't know if this mess could have been avoided, and I really
don't care.  Shit happens.  Schwamm dr=FCber.  And please do= not accuse
selected individuals because it's all "their fault".  It isn= 't.

C U on the bazaar,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D"Create
From Michael Riepe Fri Jan 5 15:08:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02112 for ; Mon, 8 Jan 2001 00:43:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:20 +0100 (MET) Received: (qmail 18711 invoked by uid 0); 5 Jan 2001 17:55:25 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx24) with SMTP; 5 Jan 2001 17:55:25 -0000 X-eGroups-Return: sentto-1101623-1857-978717166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fj.egroups.com with NNFMP; 05 Jan 2001 17:55:21 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 17:52:44 -0000 Received: (qmail 69025 invoked from network); 5 Jan 2001 17:48:11 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 5 Jan 2001 17:48:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.72) by mta1 with SMTP; 5 Jan 2001 17:48:09 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00566; Fri, 5 Jan 2001 15:08:14 +0100 Message-ID: <20010105150814.01046@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A556FFC.C7E61ADA@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A556FFC.C7E61ADA@f-cpu.org>; from Yann Guidon on Fri, Jan 05, 2001 at 07:55:56AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 5 Jan 2001 15:08:14 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] H-Arch Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 15a1e90994994eef407d85be3fca8877 Status: R X-Status: N On Fri, Jan 05, 2001 at 07:55:56AM +0100, Yann Guidon wrote:
[...]
> The F-bus is a direct connexion to the F-CPU, while your presentation
> was speaking about something more general and useless at our present level.
> but i'm still waiting for some drafts on the "H-Arch".
> Btw, i don't encourage you to keep this name because in german,
> "Arsch" means "ass". it could be misunderstood and we can avoid this tiny
> trouble before it gets spread.
[...]

Don't worry, most germans pronounce it differently.  It's "Architektur",
not "Arschitektur" (although there are people who pronounce "Chemie" as
"Schemie" or "Kemie").

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Create your family tree at MyFamily.com!
From Yann Guidon Fri Jan 5 20:47:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02148 for ; Mon, 8 Jan 2001 00:43:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:31 +0100 (MET) Received: (qmail 9772 invoked by uid 0); 5 Jan 2001 19:56:59 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx05) with SMTP; 5 Jan 2001 19:56:59 -0000 X-eGroups-Return: sentto-1101623-1858-978724608-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ck.egroups.com with NNFMP; 05 Jan 2001 19:56:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 5 Jan 2001 19:56:47 -0000 Received: (qmail 18326 invoked from network); 5 Jan 2001 19:41:27 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Jan 2001 19:41:27 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 5 Jan 2001 19:41:27 -0000 Received: from f-cpu.org (nas3-116.aub.club-internet.fr [195.36.145.116]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA28886 for ; Fri, 5 Jan 2001 20:41:22 +0100 (MET) Message-ID: <3A5624BF.CBE82E0C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A554EB6.C32B6237@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 05 Jan 2001 20:47:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1f89cb5fd859cb3ca16599ab1d454eec Status: R X-Status: N hi,

Ben Franchuk wrote:
> Yann Guidon wrote:
> True but Optical links @ 2 Gbs is becoming more common.
>  http://www.chipcenter.com/pld/pldf084.htm
> My 2 cents worth umm .02 cents with inflation.:)

i thought about it, too, but new questions arise.
optical links are not easier to use. it is not well
adapted to mass production, and prototyping is also
very expensive.

Now, here's some food for thought : whether you use
GbE or optical links, it is a serial link and the
clocking is very difficult, it's very close to an
analog transmission (with its problems, calibration,
consumption, room...).

Not only they want a multimaster bus, but they want it
to be asynchronous. geez.

> Ben.
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Create your family tree at MyFamily.com!
From Yann Guidon Sat Jan 6 01:43:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02232 for ; Mon, 8 Jan 2001 00:43:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:43:59 +0100 (MET) Received: (qmail 5797 invoked by uid 0); 6 Jan 2001 00:42:06 -0000 Received: from hk.egroups.com (208.50.99.220) by 10.1.4.112 (mx12) with SMTP; 6 Jan 2001 00:42:06 -0000 X-eGroups-Return: sentto-1101623-1860-978741456-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 06 Jan 2001 00:37:40 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 6 Jan 2001 00:37:35 -0000 Received: (qmail 15766 invoked from network); 6 Jan 2001 00:37:35 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 6 Jan 2001 00:37:35 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 6 Jan 2001 01:38:39 -0000 Received: from f-cpu.org (nas1-229.aub.club-internet.fr [195.36.150.229]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA23241 for ; Sat, 6 Jan 2001 01:37:31 +0100 (MET) Message-ID: <3A566A23.6851FE40@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 06 Jan 2001 01:43:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8d0c8ed7f344a05c7d42c777c6a09595 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> hi,
>
> Yann Guidon a =E9crit :
> > > The network will made around
> > > gigabit ethernet link (the electrical part) because it's wel= l known (and
> > > free ? ). With 8 ethernet links, we can reach the true gigab= ytes. This
> > > made around 8*2*2*2 (2 pairs with 2 ways and 2 time 500Mhz) = pins for a
> > > multidirectionnal link, very few in fact !
> > you forget several things... no chip can do 8xGb links. you forge= t the ground
> > connexions in the backplane. This backplane is going to be extrem= ely expensive,
> > and i doubt that a "f-cpu hacker" can afford a 30-layer= PCB made with Teflon.
> > the idea of the ethernet is simply science fiction.
>
> Oups, i omit to say for reduice the cost that i would like to try to > have only one chip and avoid many differents chips. So the 8 links wil= l
> be "inside" the fcpu chip. This is the main system bus.

hum, hum... just a reminder : the SiO2 process is not much the same
for a CPU and a tranceiver. you CAN't put it on the same die...

> The 8 ethernet link could be say has 2 one-way gigabyte links. So, if<= BR> > you use a ring, you need 2 of this links (one by ring). So you will on= ly
> need a 1 layer PCB !
beep. wrong. gigabit ethernet, or any ethernet, requires a very special
medium to propagate. the shield, the impedence adaptation, the diameter, the propagation, etc. are more or less taught in the IUT or ingenieur schoo= l.
they're a lot of formula etc, so you can't simply draw a line and say "= ;ok".
it can't be so. otherwise, network cables would be much cheaper.
have you heard about "Cat. 5" cables ? did you wonder why it was = more
expensive than other cables ? Plus, you'll need very special connectors...<= BR> the usual cheap connectors are not adapted at all.

> > > compare to the normal usual
> > > parrallel bus (for a link at 133 Mhz compare to the >500 = Mhz for the
> > > giga ethernet link and without to many routing problem with = long wires).
> > i compare what can be compared.
> > the current idea is simply not realistic.
> Yes, the idea that you have understood, not mine !

talk about a monodirectional synchronous parallel (byte ?)
bus with some control signals, a clock (dual edge ?) and it's ok for
me, whatever your idea is. Anybody can implement that with a
few PALs and 74Fxxx, or a simple/cheap FPGA.

now you're asynchronous, you have to deal with PLL and clock
recovery, hyperfrequencies, signal integrity, skew, etc...
that a lot of troubles for almost nothing.

you want speed ? put the wires in parallel, don't serialize the bits...

> > i want a draft, numbers, several case studies, feasibility studie= s,
> > the reference of the used parts, the protocol, the VHDL...
>
> Yeah, yeah, the bear and the bear's skin ;p

i'm just putting the pressure on your shoulders.
i'd like to see where your seriousness ends...

> > > Each cpu will have a full 128 bits wide bus for DDR-SDRAM an= d "some"
> > > gigabit ethernet links for system communication. Then you ca= n connect
> > > the cpu or a IO sub-system for ide/scsi bus, usb, rs232 ...<= BR> > >
> > i don't care about this side. you're simply going into a lot of t= roubles.
>
> In fact, it should.
"should" what ?

> In usual core, you have simple bus and it's easy to
> put rom or eeprom to boot. But here, you need something more special t= o boot.
and who will build that ? do you have the spare parts somewhere ?

> > one way to realize this is by searching the parts on the catalogs= or databases.
> > one connector is going to cost as much as the f-cpu chip. One bac= kplane
> > will cost 100KF to prototype. it's not a "hacker's architect= ure".
>
> Ben, non...
>
ok, now we're going to agree on something...

start with something simple and that works with easy-to-find parts.

> > > The "delicat" part is : what taken as network ? Ev= erybody knows that i
> > > prefer a double ring. Double to make a failure revovery (to = plug and
> > > replug one card without shutting down the system). And its e= asy to
> > > expand wihtout having any routing problems. Routing is a pro= blem for
> > > latency and complexty of the nod. But this needs much more e= xplication.
> > routing is not a problem. the routing algorithms are known for a = long time
> > and there's already a large variety of choices.
>
> Have you a link for a preditive routing algorithme ? I think that my > collegue which make a thesis about real time network will be very
> interrested to know that exist.

the routing stuff is taught during the DEUG at Paris 8 university.
ask Amal Stri from the transversal department.

When at Boston, in a (expensive) library, i found (but didn't buy)
a VERY cool about the T3E and similar architectures. The routing
algos are rather simple and very efficient.

> > > Everybody should stay calm ! We need everybody.
> > yep. F-CPU didn't appear in one day.
> >
> > anyway, the debate has shifted very far from the initial
> > requirement, and it's rather off-topic. What we need is a simple<= BR> > > parallel interface to connect the F-CPU to the G-chip and other > > G-chips. Since they're on the same PCB, we don't need hotswap. >
> If we made a simple core (like ARM), we don't need g-ship and all that= crap.
not true. ARM chips require I/O chips. Unless you buy the synthesised core,=
and implement it in the middle of a sea-of-gates ASIC with your prefered I/= O.

ARM, just like any chip, requires a memory controller and I/O.
look at the Crystal Semiconductors catalog... they have all the parts
necessary to make a PDA or laptop PC.

> If we made a processor ("a system") we should consider to ha= ve
> fault tolerance capabilities. And hot swap is the basis !
not necessarily. fault detection and bypass are a SW matter,
with the help of some HW (ECC/SEC). but the rest is purely an electrical problem.


some designs that you should investigate (using several different books, saying different stuffs) : T3D/E (it's a 3D torus with ALPHAs at the nodes)= ,
CM1 (12-cube with extremely simple routing), CM5 (fault tolerance, "bi= g tree"
network, message passing communication etc.), SGI/SUN/HP scalable computing= nodes
(i found the Convex (circa 1995) very interesting, but Convex is now owned = by HP).

i know, it's a matter of culture...

> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From "Marco Al" Sat Jan 6 18:49:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02382 for ; Mon, 8 Jan 2001 00:44:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:44:49 +0100 (MET) Received: (qmail 25965 invoked by uid 0); 6 Jan 2001 17:43:35 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx02) with SMTP; 6 Jan 2001 17:43:34 -0000 X-eGroups-Return: sentto-1101623-1861-978802929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mk.egroups.com with NNFMP; 06 Jan 2001 17:43:33 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 6 Jan 2001 17:42:09 -0000 Received: (qmail 58932 invoked from network); 6 Jan 2001 17:42:08 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 6 Jan 2001 17:42:08 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 6 Jan 2001 17:42:07 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id SAA09482 for ; Sat, 6 Jan 2001 18:42:05 +0100 (MET) Message-ID: <002701c07809$112bb610$29e65982@student.utwente.nl> To: References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 6 Jan 2001 18:49:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bbef6fe497b91886a7254f501da61ad9 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> talk about a monodirectional synchronous parallel (byte ?)
> bus with some control signals, a clock (dual edge ?) and it's ok for
> me, whatever your idea is. Anybody can implement that with a
> few PALs and 74Fxxx, or a simple/cheap FPGA.

Is LVDS usually in the standard cell libraries? If you want to have the option
of using cables its IMO the clear choice, together with source synchronous
clocking of course (chips will probably still share clocks, ie be synchronous,
the source clock is just to deal with the delay's at high signalling speeds over
long wires). There is AFAICS a pretty clear consensus in the industry that its
is the way forward for backplanes too. And there are plenty of TTL interface
chips on the market, plus some FPGA support, so no worries there.

I still like a shared bidirectional (B-LVDS) bus using repeaters/bridges/routers
for scalability. In other words the Intel way, the AMD party line swung me too
for a while... but now I dont think point to point busses use the resources
(pin's and system cost) most effectively. The only way to proove/disproove that
IMO is to model both alternatives, but Im both too lazy and I dont have the
necessary knowledge (AFAICS I would need to know feasibly physical bandwith per
pin in point to point and bus setups, and have a good traffic breakdown for
multiprocessor setups) .With a lot of broadcast traffic I just dont think the
effective bandwith per pin of a point to point bus compares favourably, let
alone the extra costs and latency of the routing chips for small SMP setups.

Marco
eGroups Sponsor
Click Here!
From "Marco Al" Sat Jan 6 18:49:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02391 for ; Mon, 8 Jan 2001 00:44:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:44:52 +0100 (MET) Received: (qmail 7772 invoked by uid 0); 6 Jan 2001 17:49:52 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx21) with SMTP; 6 Jan 2001 17:49:52 -0000 X-eGroups-Return: sentto-1101623-1861-978802929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 06 Jan 2001 17:43:37 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 6 Jan 2001 17:42:09 -0000 Received: (qmail 58932 invoked from network); 6 Jan 2001 17:42:08 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 6 Jan 2001 17:42:08 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta1 with SMTP; 6 Jan 2001 17:42:07 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id SAA09482 for ; Sat, 6 Jan 2001 18:42:05 +0100 (MET) Message-ID: <002701c07809$112bb610$29e65982@student.utwente.nl> To: References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 6 Jan 2001 18:49:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0bbb1ce28ee07eae9d7415a4a9c92a0d Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> talk about a monodirectional synchronous parallel (byte ?)
> bus with some control signals, a clock (dual edge ?) and it's ok for
> me, whatever your idea is. Anybody can implement that with a
> few PALs and 74Fxxx, or a simple/cheap FPGA.

Is LVDS usually in the standard cell libraries? If you want to have the option
of using cables its IMO the clear choice, together with source synchronous
clocking of course (chips will probably still share clocks, ie be synchronous,
the source clock is just to deal with the delay's at high signalling speeds over
long wires). There is AFAICS a pretty clear consensus in the industry that its
is the way forward for backplanes too. And there are plenty of TTL interface
chips on the market, plus some FPGA support, so no worries there.

I still like a shared bidirectional (B-LVDS) bus using repeaters/bridges/routers
for scalability. In other words the Intel way, the AMD party line swung me too
for a while... but now I dont think point to point busses use the resources
(pin's and system cost) most effectively. The only way to proove/disproove that
IMO is to model both alternatives, but Im both too lazy and I dont have the
necessary knowledge (AFAICS I would need to know feasibly physical bandwith per
pin in point to point and bus setups, and have a good traffic breakdown for
multiprocessor setups) .With a lot of broadcast traffic I just dont think the
effective bandwith per pin of a point to point bus compares favourably, let
alone the extra costs and latency of the routing chips for small SMP setups.

Marco
eGroups Sponsor
Click Here!
From Nicolas Boulay Sun Jan 7 00:35:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02468 for ; Mon, 8 Jan 2001 00:45:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:27 +0100 (MET) Received: (qmail 19658 invoked by uid 0); 6 Jan 2001 23:28:50 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx23) with SMTP; 6 Jan 2001 23:28:50 -0000 X-eGroups-Return: sentto-1101623-1862-978823718-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 06 Jan 2001 23:28:46 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 6 Jan 2001 23:28:37 -0000 Received: (qmail 20843 invoked from network); 6 Jan 2001 23:28:36 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 6 Jan 2001 23:28:36 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 7 Jan 2001 00:29:41 -0000 Received: from ifrance.com (nas22-85.vlt.club-internet.fr [195.36.172.85]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA22722 for ; Sun, 7 Jan 2001 00:28:32 +0100 (MET) Message-ID: <3A57ABCF.16D91A2B@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 00:35:43 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b0ac35562175b259980c07e3628c8ef5 Status: R X-Status: N Hi,

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > hi,
> >
> > Yann Guidon a =E9crit :
> > > > The network will made around
> > > > gigabit ethernet link (the electrical part) because it'= s well known (and
> > > > free ? ). With 8 ethernet links, we can reach the true = gigabytes. This
> > > > made around 8*2*2*2 (2 pairs with 2 ways and 2 time 500= Mhz) pins for a
> > > > multidirectionnal link, very few in fact !
> > > you forget several things... no chip can do 8xGb links. you = forget the ground
> > > connexions in the backplane. This backplane is going to be e= xtremely expensive,
> > > and i doubt that a "f-cpu hacker" can afford a 30-= layer PCB made with Teflon.
> > > the idea of the ethernet is simply science fiction.
> >
> > Oups, i omit to say for reduice the cost that i would like to try= to
> > have only one chip and avoid many differents chips. So the 8 link= s will
> > be "inside" the fcpu chip. This is the main system bus.=
>
> hum, hum... just a reminder : the SiO2 process is not much the same > for a CPU and a tranceiver. you CAN't put it on the same die...
>

I don't think that you know about what you speak ! New silicon process
are silicium on insulator, soon used by IBM for there udge processor for mainfrain (a little beast with 35 ppc on the same die). And now, for the next powerG3. Next, the SiGe are new process used to have
hyperfrequencies, or mixed analogue and digital part. But then, it could be used for very quick digital circuit.

And, for information, gigabit ethernet need 500 Mhz. So, "usual proces= s"
are must enought to make a tranceiver.

> > The 8 ethernet link could be say has 2 one-way gigabyte links. So= , if
> > you use a ring, you need 2 of this links (one by ring). So you wi= ll only
> > need a 1 layer PCB !
> beep. wrong. gigabit ethernet, or any ethernet, requires a very specia= l
> medium to propagate. the shield, the impedence adaptation, the diamete= r,
> the propagation, etc. are more or less taught in the IUT or ingenieur = school.

A=EFe ! You just have to respect electrical rules of the gigabit ethernet (L and C).

> they're a lot of formula etc, so you can't simply draw a line and say = "ok".
> it can't be so. otherwise, network cables would be much cheaper.
> have you heard about "Cat. 5" cables ? did you wonder why it= was more

You have never learn that this kind of cable could be around 50 meter
long ! Here 1 or 2 meters is much enought !

> expensive than other cables ? Plus, you'll need very special connector= s...
> the usual cheap connectors are not adapted at all.
>
> > > > compare to the normal usual
> > > > parrallel bus (for a link at 133 Mhz compare to the >= ;500 Mhz for the
> > > > giga ethernet link and without to many routing problem = with long wires).
> > > i compare what can be compared.
> > > the current idea is simply not realistic.
> > Yes, the idea that you have understood, not mine !
>
> talk about a monodirectional synchronous parallel (byte ?)
> bus with some control signals, a clock (dual edge ?) and it's ok for > me, whatever your idea is. Anybody can implement that with a

Fast clock one large network, you have to deal with clock skew. Most of
the time, each founder (ST microelectronics, TSMC, infineon,...) have a
macro cell to do gigaethernet and do all the hard things (serial,
deserials).

> few PALs and 74Fxxx, or a simple/cheap FPGA.
>

Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify 5V and some nF of charge. I don't want to repeat it each time.
1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compare to
usual system.
2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around 300 Mhz with DDR or more with QDR. With LVDS, you can reach around 600 Mhz by
pin. BUT you can't really add a connector between 2 pins at that speed.
My choice is to have a quick link (performance are our goal, isn't it
?). Then you just had to provide a bridge between the quick link and a
SRAM like bus. I think that could be easy : Just a link like for the
fcpu and a little glue for the interface.

> now you're asynchronous, you have to deal with PLL and clock
> recovery, hyperfrequencies, signal integrity, skew, etc...
> that a lot of troubles for almost nothing.
>

Not at all ! because you deal with macrocell and all the suft are soon
made.

> you want speed ? put the wires in parallel, don't serialize the bits..= .
>

Yes, but the limit are the number of pin and the prices ! And then you
alwas have the speed of the clock with LVDS, you always have the
electrical and speed problem.

> > > i want a draft, numbers, several case studies, feasibility s= tudies,
> > > the reference of the used parts, the protocol, the VHDL... > >
> > Yeah, yeah, the bear and the bear's skin ;p
>
> i'm just putting the pressure on your shoulders.
> i'd like to see where your seriousness ends...
>
> > > > Each cpu will have a full 128 bits wide bus for DDR-SDR= AM and "some"
> > > > gigabit ethernet links for system communication. Then y= ou can connect
> > > > the cpu or a IO sub-system for ide/scsi bus, usb, rs232= ...
> > >
> > > i don't care about this side. you're simply going into a lot= of troubles.
> >
> > In fact, it should.
> "should" what ?
>
> > In usual core, you have simple bus and it's easy to
> > put rom or eeprom to boot. But here, you need something more spec= ial to boot.
> and who will build that ? do you have the spare parts somewhere ?
>

"spare part", i don't understand. One day, you say you want perfo= rmance,
the other days somthing so slow to be compatible with TTL. I don't
understand you...

> > > one way to realize this is by searching the parts on the cat= alogs or databases.
> > > one connector is going to cost as much as the f-cpu chip. On= e backplane
> > > will cost 100KF to prototype. it's not a "hacker's arch= itecture".
> >
> > Ben, non...
> >
> ok, now we're going to agree on something...
>
> start with something simple and that works with easy-to-find parts. >
> > > > The "delicat" part is : what taken as network= ? Everybody knows that i
> > > > prefer a double ring. Double to make a failure revovery= (to plug and
> > > > replug one card without shutting down the system). And = its easy to
> > > > expand wihtout having any routing problems. Routing is = a problem for
> > > > latency and complexty of the nod. But this needs much m= ore explication.
> > > routing is not a problem. the routing algorithms are known f= or a long time
> > > and there's already a large variety of choices.
> >
> > Have you a link for a preditive routing algorithme ? I think that= my
> > collegue which make a thesis about real time network will be very=
> > interrested to know that exist.
>
> the routing stuff is taught during the DEUG at Paris 8 university.
> ask Amal Stri from the transversal department.
>
> When at Boston, in a (expensive) library, i found (but didn't buy)
> a VERY cool about the T3E and similar architectures. The routing
> algos are rather simple and very efficient.
>

I seriously doubt about the complexity and the scalability...

> > > > Everybody should stay calm ! We need everybody.
> > > yep. F-CPU didn't appear in one day.
> > >
> > > anyway, the debate has shifted very far from the initial
> > > requirement, and it's rather off-topic. What we need is a si= mple
> > > parallel interface to connect the F-CPU to the G-chip and ot= her
> > > G-chips. Since they're on the same PCB, we don't need hotswa= p.
> >
> > If we made a simple core (like ARM), we don't need g-ship and all= that crap.
> not true. ARM chips require I/O chips. Unless you buy the synthesised = core,
> and implement it in the middle of a sea-of-gates ASIC with your prefer= ed I/O.
>

One more times, you don't unsderstand ! i propose like leon, just to
develope the fc0 (the core) and let other gays to use it.

> ARM, just like any chip, requires a memory controller and I/O.
> look at the Crystal Semiconductors catalog... they have all the parts<= BR> > necessary to make a PDA or laptop PC.
>
> > If we made a processor ("a system") we should consider = to have
> > fault tolerance capabilities. And hot swap is the basis !
> not necessarily. fault detection and bypass are a SW matter,
> with the help of some HW (ECC/SEC). but the rest is purely an electric= al
> problem.
>

Not really, i don't speak about fault detection but failure tolerant (a
single dead card don't stop the all system, you just have to change it).
> some designs that you should investigate (using several different book= s,
> saying different stuffs) : T3D/E (it's a 3D torus with ALPHAs at the n= odes),
> CM1 (12-cube with extremely simple routing), CM5 (fault tolerance, &qu= ot;big tree"
> network, message passing communication etc.), SGI/SUN/HP scalable comp= uting nodes
> (i found the Convex (circa 1995) very interesting, but Convex is now o= wned by HP).
>

Just for information : how much for a single chip ? And how much heat
for a chip ? You try to give some piece of your knowledge but you don't
understand the "simple coma" from SUN for their last system (from= an URL
given on the list), so ?

> i know, it's a matter of culture...
>

I just see it's like jam, ...

> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D"Click
From bethweinstein@yahoo.com Sun Jan 7 04:31:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02489 for ; Mon, 8 Jan 2001 00:45:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:35 +0100 (MET) Received: (qmail 19590 invoked by uid 0); 7 Jan 2001 02:56:32 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx21) with SMTP; 7 Jan 2001 02:56:32 -0000 X-eGroups-Return: sentto-1101623-1863-978836182-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mo.egroups.com with NNFMP; 07 Jan 2001 02:56:30 -0000 X-Sender: wil_lopez@gtemail.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 02:56:21 -0000 Received: (qmail 60661 invoked from network); 7 Jan 2001 02:56:21 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 Jan 2001 02:56:21 -0000 Received: from unknown (HELO ns1.okhosting.co.kr) (211.171.244.56) by mta1 with SMTP; 7 Jan 2001 02:56:20 -0000 Received: from 216.97.206.70 (216-97-206-070.ppp.mpinet.net [216.97.206.70]) by ns1.okhosting.co.kr (8.10.1/8.9.3) with SMTP id f07BsDQ22234; Sun, 7 Jan 2001 20:54:15 +0900 Message-ID: <0000215359b9$00000dc9$0000521f@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: wil_lopez@gtemail.net From: bethweinstein@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 06 Jan 2001 22:31:11 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] IT'S HERE.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a01625e3eb8ab48ddc133f520c98b88e Status: R X-Status: N Expand your business with
    Email Marketing!

Market your product or service
     to MILLIONS!

Don't waste another minute...

Click Reply with your name,
telephone number and the
product or service you wish
to market. We will be in
touch with you shortly!





Removal Instructions
****************************
To be removed from this list
please reply with "REMOVE"
in the subject.













Expand your business with
    Email Marketing!

Market your product or service
     to MILLIONS!

Don't waste another minute...

Click Reply with your name,
eGroups Sponsor
From Yann Guidon Sun Jan 7 04:32:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02492 for ; Mon, 8 Jan 2001 00:45:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:36 +0100 (MET) Received: (qmail 31528 invoked by uid 0); 7 Jan 2001 03:27:12 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx18) with SMTP; 7 Jan 2001 03:27:12 -0000 X-eGroups-Return: sentto-1101623-1864-978838028-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 07 Jan 2001 03:27:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 03:27:07 -0000 Received: (qmail 18544 invoked from network); 7 Jan 2001 03:27:07 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 Jan 2001 03:27:07 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 7 Jan 2001 04:28:11 -0000 Received: from f-cpu.org (nas4-176.aub.club-internet.fr [195.36.145.176]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA12003 for ; Sun, 7 Jan 2001 04:27:01 +0100 (MET) Message-ID: <3A57E362.1046463B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 04:32:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6ab8f6accdefa658fd8e9bdc62acb5c8 Status: R X-Status: N hi !

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > talk about a monodirectional synchronous parallel (byte ?)
> > bus with some control signals, a clock (dual edge ?) and it's ok = for
> > me, whatever your idea is. Anybody can implement that with a
> > few PALs and 74Fxxx, or a simple/cheap FPGA.
>
> Is LVDS usually in the standard cell libraries? If you want to have th= e option
> of using cables its IMO the clear choice, together with source synchro= nous
> clocking of course (chips will probably still share clocks, ie be sync= hronous,
> the source clock is just to deal with the delay's at high signalling s= peeds over
> long wires). There is AFAICS a pretty clear consensus in the industry = that its
> is the way forward for backplanes too. And there are plenty of TTL int= erface
> chips on the market, plus some FPGA support, so no worries there.

yup. Even though it's not the "hottest" stuff around (compared to=
optical fibers, I2C and mental waves), it works, it's very well understood,=
it's widely spread... and it's not over expensive (accessibility of the
technology vs price vs performance vs...)

> I still like a shared bidirectional (B-LVDS) bus using repeaters/bridg= es/routers
> for scalability. In other words the Intel way, the AMD party line swun= g me too
> for a while...
after a few months playing with the idea of two unidirectional buses ("= ;full-duplex",
even though the bandwidth is halved) i feel that it is not a bad idea at al= l.
No arbitration, few synchronisation, very low complexity... i like it :-)
> but now I dont think point to point busses use the resources
> (pin's and system cost) most effectively.
it depends on your criteria. low pin count ? price ? speed ? bandwidth ?...=
and also on your needs and "budget".

> The only way to proove/disproove that
> IMO is to model both alternatives, but Im both too lazy and I dont hav= e the
> necessary knowledge (AFAICS I would need to know feasibly physical ban= dwith per
> pin in point to point and bus setups, and have a good traffic breakdow= n for
> multiprocessor setups) .With a lot of broadcast traffic I just dont th= ink the
> effective bandwith per pin of a point to point bus compares favourably= , let
> alone the extra costs and latency of the routing chips for small SMP s= etups.

well, there's the architecture side here...

if you target "small SMP" only, maybe you can do it with a shared= bus,
but don't expect wonders above 4 CPU. If you're doing CPU-only tasks, it's<= BR> ok, but when you start to move things around, it's the real mess.
Intel sticks to this because the architecture is more or less stuck.
they want cheap systems and make big profits, but still compete (with
some pain) in the SPEC contests.

I am trying to find the "least common denominator" for a F-CPU sy= stem
that can range from 1 CPU to any arbitrary number of CPUs (just like
the register width : not bound to anything). let's take a few cases,
with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" should also sc= ale
to much more CPUs : the widest systems today (see the monters at the LANL)<= BR> can scale to more than 10K CPU, so let's round up to 65536.

now let's compare the alternatives...

Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's disastrous with more CPU.

buses are known, used and they work, but some people here want a "mult= imaster"
bus. This means that the bandwidth is drawn by several points and the bus is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU, equal to<= BR> the available bandwidth provided by the bus and divided by N CPU).

that's what i try to avoid.

Clearly, this B=3DL/N is a thing that i try to avoid for other things as we= ll,
and it's my "hammer" argument when i try to promote point to poin= t links.
We spare the (distributed) control logic (all the nasty deadlock stuffs etc= )
and it's very simple to implement. the PCB is simpler, too.

If you connect more than 2 CPU on the same bus, they compete for the ressou= rce
and the bottleneck gets even narrow.

On the pin count vs bandwidth argument, it's similar. Of course, we can fin= d
a lot of counter-examples and special cases, but the example of the broadca= st
is not the best one. Most of the requests are from one node to a single oth= er
and here, the efficiency of a bus drops dramatically ! for a N-CPU system,<= BR> the efficiency is of 2 used bus interfaces for N bus interfaces (you can replace "bus interface" with "pin"), 2/N is similar to = the 1/N scheme
(if we speak about the "big O" or complexity). This means that :<= BR> the more CPU, the least efficient ! you'll see that the best way to avoid this is by having as few CPU by link as possible, and the minimum is 2.
that's "point to point"...


Now, another stuff. Nico usually wants a ring. It's "simple to route&q= uot;,
it's fun and doesn't need much "efforts". But there is still the = same
problem as before : the more CPU, the less bandwidth when one CPU wants
to talk to another. 1/N (or 2 pins / N CPU if you want the "real effic= iency").
The solution is rather easy : you have to expand that to the other 2 dimens= ions,
hence the "CRAY T3D" and the extension, T3E. Routing is still the= same but the
address is split into 3 fields that are interpreted as an independent ring = address.

here, you don't have 1 ring but x*y*z rings. It means that there is
no bandwidth problem at all, because each CPU communicates with its 6 neigh= bours.
It works very well, it can be tweaked to become "fault tolerant" = (through dynamic
node addresses) and scales perfectly (almost linearly with the CPU number).=

So if you want the simplest system, you have 1 CPU with no ring,
and when you scale up, add a few links when needed and use like "lego = bricks"
in a cubic connexion.

I think that the G-chip was an easy way to make the topology reconfigurable=
by the user/implementor. If we provide the brick, the user will make a lot<= BR> of stuffs, but if we restrict the choices, the scalability and the flexibil= ity
will suffer.


> Marco

Nicolas Boulay wrote:
>
> Hi,
>
> Yann Guidon a =E9crit :
> >
> > hi,
> >
> > Nicolas Boulay wrote:
> > > hi,
> > >
> > > Oups, i omit to say for reduice the cost that i would like t= o try to
> > > have only one chip and avoid many differents chips. So the 8= links will
> > > be "inside" the fcpu chip. This is the main system= bus.
> >
> > hum, hum... just a reminder : the SiO2 process is not much the sa= me
> > for a CPU and a tranceiver. you CAN't put it on the same die... >
> I don't think that you know about what you speak ! New silicon process=
> are silicium on insulator, soon used by IBM for there udge processor f= or
> mainfrain (a little beast with 35 ppc on the same die).
duh. and how will you ask IBM to make your chip ?
it's not something that everybody can do. it's not free, it's expensive
and it's not connectable to anything...

> And now, for the next powerG3. Next, the SiGe are new process used to = have
> hyperfrequencies, or mixed analogue and digital part. But then, it cou= ld
> be used for very quick digital circuit.
It is. but how many people would use such a chip ? what can they connect it= to ?
how will you "solve" the RF issues ? Do you know how difficult it= is to route
a 50 MHz signal ? So who will buy you the SW needed to design a RF PCB ?
> And, for information, gigabit ethernet need 500 Mhz. So, "usual p= rocess"
> are must enought to make a tranceiver.
Maybe you should stop to use the term "ethernet". If it's a simpl= e
"serial link", you're just making a firewire clone...

> > > The 8 ethernet link could be say has 2 one-way gigabyte link= s. So, if
> > > you use a ring, you need 2 of this links (one by ring). So y= ou will only
> > > need a 1 layer PCB !
> > beep. wrong. gigabit ethernet, or any ethernet, requires a very s= pecial
> > medium to propagate. the shield, the impedence adaptation, the di= ameter,
> > the propagation, etc. are more or less taught in the IUT or ingen= ieur school.
> A=EFe ! You just have to respect electrical rules of the gigabit ether= net
> (L and C).
that's a pretty quick simplification. even though at your level it fits, when you make the PCB it takes another dimension ...

> > they're a lot of formula etc, so you can't simply draw a line and= say "ok".
> > it can't be so. otherwise, network cables would be much cheaper.<= BR> > > have you heard about "Cat. 5" cables ? did you wonder w= hy it was more
> You have never learn that this kind of cable could be around 50 meter<= BR> > long ! Here 1 or 2 meters is much enought !
and you think that it's not the same problem ????
have you heard about Xtalk and such stuff ? you CAN't make it with a 1-laye= r PCB.
you need at least 3 layers to make a decent transmission line
(shield/insulator/signal/insulator/shield). And depending on your signal's<= BR> characteristics, you have to change the dimensions of the tracks,
so they are adapted to the thickness of the PCB and the permeability of
the insulator (if it's epoxy or teflon or something else).

Whether the wire is 50m or 1m, the problem is the same...

> > > > i compare what can be compared.
> > > > the current idea is simply not realistic.
> > > Yes, the idea that you have understood, not mine !
> > talk about a monodirectional synchronous parallel (byte ?)
> > bus with some control signals, a clock (dual edge ?) and it's ok = for
> > me, whatever your idea is. Anybody can implement that with a
> Fast clock one large network, you have to deal with clock skew.
it's an old known problem and there are some old known solutions.
ever heard about a "clock tree" ?... if you have a good architect= ure,
you don't have skew troubles.

> Most of the time, each founder (ST microelectronics, TSMC, infineon,..= .)
> have a macro cell to do gigaethernet and do all the hard things (seria= l,
> deserials).
and you'll by the components ? come on...
and please, don't talk about "Ethernet", it seems like it's
only a serial point to point link (if i remember one of your messages).

> > few PALs and 74Fxxx, or a simple/cheap FPGA.
> Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify 5V a= nd
> some nF of charge. I don't want to repeat it each time.
hey, i'm not dumb, i know that TTL is slow. thanks.

but just a question : how will you debug your stuff ? will you use
a 10GS/s logic analyser ? with a simple enough protocol, i can
debug the interface with "off the shelf parts" that i can solder = at will,
the old school way, just like any "hacker".

Then, when it's developped, you only have to change the electrical
levels (that is : the pin's driving gates) and you can do LVTTL or whatever=
high-speed connexion. it's just a matter of changing the electrical spec. Yes i want speed, but a "hacker" needs a way to see what happens = without
the need of extremely expensive devices. by clocking the chip slower
and adapting the electrical level (with the adapted buffers or transmitters= ),
you can hook anything to the F-BUS.

> 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compare to=
> usual system.
this kind of speed is used for I/O with maybe a controller or something
like that. When i speak about "TTL parts", it's something like a = 8255
or any very slow byte-based I/O chip. just like during the old days
of the 8-bit systems...

> 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around 300 M= hz
> with DDR or more with QDR. With LVDS, you can reach around 600 Mhz by<= BR> > pin. BUT you can't really add a connector between 2 pins at that speed= .
then it must be soldered. but then, this speed is not required for
handcrafting your own I/O board on a pre-drilled PCB. do you know a mouse or a keyboard or even a LCD screen that requires 600M x N pins of data
per second ?

Scalability means scale-down and scale-up. 500Mbps is fine, but when you don't need that much, it's an overkill. And you propose to make an adapter<= BR> that will bother of the I/O, but how many custom chips will you require
to interface your connexion to any other stuffs ? Having a simple and
one-fits-all protocol that does low and high-speed helps reduce the
number of different chips and interfaces...

> My choice is to have a quick link (performance are our goal, isn't it = ?).
not only. In the design goals of the F-CPU, there are 3 other stuffs.

> Then you just had to provide a bridge between the quick link and a
> SRAM like bus. I think that could be easy : Just a link like for the > fcpu and a little glue for the interface.
i'll give you the honnor of doing the first one...

> > now you're asynchronous, you have to deal with PLL and clock
> > recovery, hyperfrequencies, signal integrity, skew, etc...
> > that a lot of troubles for almost nothing.
> Not at all ! because you deal with macrocell and all the suft are soon= made.
ain't it magical ??...
are you so confident and faithfull in the technologies ?

> > you want speed ? put the wires in parallel, don't serialize the b= its...
> Yes, but the limit are the number of pin and the prices ! And then you=
> alwas have the speed of the clock with LVDS, you always have the
> electrical and speed problem.

ok, let's compare serial and parallel.

you want 1Gbps links. halve it now, because the actual efficiency
of a serial bus is not the raw peak number. With 10Base, one can't transfer=
more than 500K bytes per second. or 520. whatever.
So let's imagine that you can SUSTAIN 50 M bytes per second.
caugh. caugh. ok, imagine you can reach 70M bytes in the two directions. 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M bytes/s
(or 8 Gbps).

Ok, i know, you want to reach 8Bgps by using 8 links.
but how are they connected ? if you want to make a ring, you'll
dissipate your bandwidth, and if you want to make neighbour to neighbour connexions, you'll require 64 pins (or better 100, counting grounds/VCC) per neighbour. retour case d=E9part...


> > > In usual core, you have simple bus and it's easy to
> > > put rom or eeprom to boot. But here, you need something more= special to boot.
> > and who will build that ? do you have the spare parts somewhere ?=
> "spare part", i don't understand.
i mean : go buy some such chips at St Quentin Radio or Radio Shacks...
a chip that is available for sale in public catalogs.

> One day, you say you want performance,
> the other days somthing so slow to be compatible with TTL. I don't
> understand you...

i want something that can do both, but of course not at the same time.
you can't access a mouse or handcrafted I/O board (anything that you
see in Elektor or Electronique Pratique) with the same means as another CPU= .
But the protocol and the layout must remain the same, as to ease the PCB de= sign
and the easy replacement of the chips.

> > > Have you a link for a preditive routing algorithme ? I think= that my
> > > collegue which make a thesis about real time network will be= very
> > > interrested to know that exist.
> >
> > the routing stuff is taught during the DEUG at Paris 8 university= .
> > ask Amal Stri from the transversal department.
> >
> > When at Boston, in a (expensive) library, i found (but didn't buy= )
> > a VERY cool about the T3E and similar architectures. The routing<= BR> > > algos are rather simple and very efficient.
>
> I seriously doubt about the complexity and the scalability...

remember, it's a torus. only, it's 3D :-)
for the other details, it's up to you to go to the library,
read as many book as you can and ask the teachers and the
educated people from comp.arch and comp.sys.super...
i won't do it for you, you wouldn't believe what i say :-P

> > > If we made a simple core (like ARM), we don't need g-ship an= d all that crap.
> > not true. ARM chips require I/O chips. Unless you buy the synthes= ised core,
> > and implement it in the middle of a sea-of-gates ASIC with your p= refered I/O.
> One more times, you don't unsderstand ! i propose like leon, just to > develope the fc0 (the core) and let other gays to use it.
so let's drop this silly network/bus whatever debate for a while...

> > > If we made a processor ("a system") we should cons= ider to have
> > > fault tolerance capabilities. And hot swap is the basis ! > > not necessarily. fault detection and bypass are a SW matter,
> > with the help of some HW (ECC/SEC). but the rest is purely an ele= ctrical
> > problem.
> >
> Not really, i don't speak about fault detection but failure tolerant (= a
> single dead card don't stop the all system, you just have to change it= ).

it's the SAME thing. You can't be "fault tolerant" if you can't d= etect
the fault and take the necessary SW measures. It's obvious...
i'm just trying to avoid "buzzwords" that taint the debate with b= lack magic ;-)


> > some designs that you should investigate (using several different= books,
> > saying different stuffs) : T3D/E (it's a 3D torus with ALPHAs at = the nodes),
> > CM1 (12-cube with extremely simple routing), CM5 (fault tolerance= , "big tree"
> > network, message passing communication etc.), SGI/SUN/HP scalable= computing nodes
> > (i found the Convex (circa 1995) very interesting, but Convex is = now owned by HP).
>
> Just for information : how much for a single chip ? And how much heat<= BR> > for a chip ? You try to give some piece of your knowledge but you don'= t
> understand the "simple coma" from SUN for their last system = (from an URL
> given on the list), so ?

i've tried, but it's not that clear for me, what's so special ?
when there's a page fault, i trap. Just make the correct fault handler,
and you implement any memory protection and sharing you want.
It leaves the door open to ANY memory system implementation.
what else do you want ? i'm still waiting for a clear and HW proposition.
> > i know, it's a matter of culture...
> I just see it's like jam, ...
J'en ai une meilleure, mais je ne l'ai pas invent=E9e non plus,
elle est de Jacques Brel : "La culture, c'est la m=E9moire des
cons qui n'ont rien invent=E9". Il avait vraiment des id=E9es
noires avant de mourir... La culture, il faut se la faire
tous les jours et ne pas trop camper sur ses positions...
avec le f-cpu, on a ce qu'il faut comme action :-)

bonne nuit,

> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From "maurizio zoboli" Sun Jan 7 11:18:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02525 for ; Mon, 8 Jan 2001 00:45:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:47 +0100 (MET) Received: (qmail 11136 invoked by uid 0); 7 Jan 2001 10:46:43 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx05) with SMTP; 7 Jan 2001 10:46:43 -0000 X-eGroups-Return: sentto-1101623-1865-978862802-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 07 Jan 2001 10:20:05 -0000 X-Sender: maurizio.zoboli@unimo.it X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 10:20:01 -0000 Received: (qmail 67574 invoked from network); 7 Jan 2001 10:20:00 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 7 Jan 2001 10:20:00 -0000 Received: from unknown (HELO mail.unimo.it) (155.185.1.1) by mta2 with SMTP; 7 Jan 2001 10:20:00 -0000 Received: from k527.ing.unimo.it (k527.ing.unimo.it [155.185.48.73]) by mail.unimo.it (2.1.2/8.9.1/Execmail 2.1) with SMTP id LAA4234551 for ; Sun, 7 Jan 2001 11:13:32 +0100 (CET) Message-Id: <200101071013.LAA4234551@mail.unimo.it> To: "f-cpu@egroups.com" Priority: Normal X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05 In-Reply-To: <0000215359b9$00000dc9$0000521f@> From: "maurizio zoboli" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 11:18:39 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 13768efa9a2d49c0626fe2cf5e9689da Status: R X-Status: N On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:

>Expand your business with
>    Email Marketing!
>
>Market your product or service
>     to MILLIONS!
>
>Don't waste another minute...
>
>Click Reply with your name,
>telephone number and the
>product or service you wish
>to market. We will be in
>touch with you shortly!
>
>
>
>
>
>Removal Instructions
>****************************
>To be removed from this list
>please reply with "REMOVE"
>in the subject.
>
>
>
>
>
>
>
>
>
>
>
>
>
>Expand your business with
>    Email Marketing!
>
>Market your product or service
>     to MILLIONS!
>
>Don't waste another minute...
>
>Click Reply with your name,
>
>
>
>
>
>
>
>
>
>
>
>
>



Prof. Maurizio Zoboli
Dipartimento di Scienze dell'Ingegneria
Universita' di Modena e Reggio Emilia
via Vignolese 905
I-41100 Modena, Italy
Tel.: +39 059 2056163
Fax: +39 059 2056129
e-mail: maurizio.zoboli@unimo.it
eGroups Sponsor
Click here!
From Nicolas Boulay Sun Jan 7 13:46:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02546 for ; Mon, 8 Jan 2001 00:45:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:53 +0100 (MET) Received: (qmail 25118 invoked by uid 0); 7 Jan 2001 12:39:53 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx05) with SMTP; 7 Jan 2001 12:39:53 -0000 X-eGroups-Return: sentto-1101623-1866-978871185-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 07 Jan 2001 12:39:47 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 12:39:44 -0000 Received: (qmail 75577 invoked from network); 7 Jan 2001 12:39:44 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 7 Jan 2001 12:39:44 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 7 Jan 2001 13:40:48 -0000 Received: from ifrance.com (nas20-152.vlt.club-internet.fr [195.36.170.152]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA29181 for ; Sun, 7 Jan 2001 13:39:35 +0100 (MET) Message-ID: <3A586520.68469E14@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 13:46:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 66b3e3c2e3811db575db66273bdbb909 Status: R X-Status: N
Yann Guidon a =E9crit :
>
> hi !
>
> Marco Al wrote:
> > The only way to proove/disproove that
> > IMO is to model both alternatives, but Im both too lazy and I don= t have the
> > necessary knowledge (AFAICS I would need to know feasibly physica= l bandwith per
> > pin in point to point and bus setups, and have a good traffic bre= akdown for
> > multiprocessor setups) .With a lot of broadcast traffic I just do= nt think the
> > effective bandwith per pin of a point to point bus compares favou= rably, let
> > alone the extra costs and latency of the routing chips for small = SMP setups.
>
> well, there's the architecture side here...
>
> if you target "small SMP" only, maybe you can do it with a s= hared bus,
> but don't expect wonders above 4 CPU. If you're doing CPU-only tasks, = it's
> ok, but when you start to move things around, it's the real mess.
> Intel sticks to this because the architecture is more or less stuck. > they want cheap systems and make big profits, but still compete (with<= BR> > some pain) in the SPEC contests.
>

You always forget one big thing. Here we speak about private memory and
communication network to speed up memory interface. So in the intel
architecture, 4 is a maximum because all the 4 cpu read the memory
thought the same shared bus. In our system, only message go thought the
network. In the best case, only I/O instruction go thought the network
and very few message from the processes.

> I am trying to find the "least common denominator" for a F-C= PU system
> that can range from 1 CPU to any arbitrary number of CPUs (just like > the register width : not bound to anything). let's take a few cases, > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" should al= so scale
> to much more CPUs : the widest systems today (see the monters at the L= ANL)
> can scale to more than 10K CPU, so let's round up to 65536.
>
> now let's compare the alternatives...
>
> Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's disastr= ous
> with more CPU.
>
> buses are known, used and they work, but some people here want a "= ;multimaster"
> bus. This means that the bandwidth is drawn by several points and the = bus
> is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU, equa= l to
> the available bandwidth provided by the bus and divided by N CPU).
>
> that's what i try to avoid.
>
> Clearly, this B=3DL/N is a thing that i try to avoid for other things = as well,
> and it's my "hammer" argument when i try to promote point to= point links.
> We spare the (distributed) control logic (all the nasty deadlock stuff= s etc)

There are always possible traffic Jam. How do you manage when 2 nodes
try to speak to the same nod ? You have to manage something to avoid
losing informations.

> and it's very simple to implement. the PCB is simpler, too.
>
> If you connect more than 2 CPU on the same bus, they compete for the r= essource
> and the bottleneck gets even narrow.
>

Yes, but less drastically as intel SMP.

> On the pin count vs bandwidth argument, it's similar. Of course, we ca= n find
> a lot of counter-examples and special cases, but the example of the br= oadcast
> is not the best one. Most of the requests are from one node to a singl= e other

In fact, not. It depend how much process communicate between them. And
sometimes the only [simple] way to find a "moving" ressources is = to send
a braodcast.

> and here, the efficiency of a bus drops dramatically ! for a N-CPU sys= tem,
> the efficiency is of 2 used bus interfaces for N bus interfaces (you c= an
> replace "bus interface" with "pin"), 2/N is simila= r to the 1/N scheme
> (if we speak about the "big O" or complexity). This means th= at :
> the more CPU, the least efficient ! you'll see that the best way to av= oid
> this is by having as few CPU by link as possible, and the minimum is 2= .
> that's "point to point"...
>
> Now, another stuff. Nico usually wants a ring. It's "simple to ro= ute",
> it's fun and doesn't need much "efforts". But there is still= the same
> problem as before : the more CPU, the less bandwidth when one CPU want= s
> to talk to another. 1/N (or 2 pins / N CPU if you want the "real = efficiency").
> The solution is rather easy : you have to expand that to the other 2 d= imensions,
> hence the "CRAY T3D" and the extension, T3E. Routing is stil= l the same but the
> address is split into 3 fields that are interpreted as an independent = ring address.
>

In the flight back to France, we have spoken about ring of ring.(and
called the architecture the lord of the ring ;p). A ring is composed
around 8 to 16 card (cpu+ram or IO). A card could be used to communicate with other ring. Maybe it's possible to grow in hierachy without to much trouble.

> here, you don't have 1 ring but x*y*z rings. It means that there is > no bandwidth problem at all, because each CPU communicates with its 6 = neighbours.
> It works very well, it can be tweaked to become "fault tolerant&q= uot; (through dynamic
> node addresses) and scales perfectly (almost linearly with the CPU num= ber).
>
So !

> So if you want the simplest system, you have 1 CPU with no ring,
> and when you scale up, add a few links when needed and use like "= lego bricks"
> in a cubic connexion.
>
Cubic ~=3D  ring ????
> I think that the G-chip was an easy way to make the topology reconfigu= rable
> by the user/implementor. If we provide the brick, the user will make a= lot
> of stuffs, but if we restrict the choices, the scalability and the fle= xibility
> will suffer.
>
> > Marco
>
> Nicolas Boulay wrote:
> >
> > Hi,
> >
> > Yann Guidon a =E9crit :
> > >
> > > hi,
> > >
> > > Nicolas Boulay wrote:
> > > > hi,
> > > >
> > > > Oups, i omit to say for reduice the cost that i would l= ike to try to
> > > > have only one chip and avoid many differents chips. So = the 8 links will
> > > > be "inside" the fcpu chip. This is the main s= ystem bus.
> > >
> > > hum, hum... just a reminder : the SiO2 process is not much t= he same
> > > for a CPU and a tranceiver. you CAN't put it on the same die= ...
> >
> > I don't think that you know about what you speak ! New silicon pr= ocess
> > are silicium on insulator, soon used by IBM for there udge proces= sor for
> > mainfrain (a little beast with 35 ppc on the same die).
> duh. and how will you ask IBM to make your chip ?
> it's not something that everybody can do. it's not free, it's expensiv= e

And you think that actual 0.18 =B5m are free ? In 2 years, SOI will be
used in every silicon process, because it reduice the power consumption
and doesn't cost so much (it's just a little traitement on wafer).

> and it's not connectable to anything...
>
??? I think you miss something... The only electrical rules to respect
is the higher voltage in input, most of the time lower than 3.3 V, to
avoid destroying transistor, that's all.

> > And now, for the next powerG3. Next, the SiGe are new process use= d to have
> > hyperfrequencies, or mixed analogue and digital part. But then, i= t could
> > be used for very quick digital circuit.
> It is. but how many people would use such a chip ? what can they conne= ct it to ?
> how will you "solve" the RF issues ? Do you know how difficu= lt it is to route
> a 50 MHz signal ? So who will buy you the SW needed to design a RF PCB= ?
>

I think that Cadence has offer something. (any news ?) You want
performance and you think that 50 Mhz signal are to much. How do you
want to deal with 133 Mhz DDR-SDRAM ?

> > And, for information, gigabit ethernet need 500 Mhz. So, "us= ual process"
> > are must enought to make a tranceiver.
> Maybe you should stop to use the term "ethernet". If it's a = simple

But in electrical rules, gigaethernet is only a serial point to point
link, not much more (just add the mac adress and a crc).

> "serial link", you're just making a firewire clone...
>

A=EFe ! Firewire isn't a point to point serial link !!!! It's a complete network system which include the 3rd layer of the OSI system. It include the routing protocole and all that stuff (the same thing than IP )!

> > > > The 8 ethernet link could be say has 2 one-way gigabyte= links. So, if
> > > > you use a ring, you need 2 of this links (one by ring).= So you will only
> > > > need a 1 layer PCB !
> > > beep. wrong. gigabit ethernet, or any ethernet, requires a v= ery special
> > > medium to propagate. the shield, the impedence adaptation, t= he diameter,
> > > the propagation, etc. are more or less taught in the IUT or = ingenieur school.
> > A=EFe ! You just have to respect electrical rules of the gigabit = ethernet
> > (L and C).
> that's a pretty quick simplification. even though at your level it fit= s,
> when you make the PCB it takes another dimension ...
>
> > > they're a lot of formula etc, so you can't simply draw a lin= e and say "ok".
> > > it can't be so. otherwise, network cables would be much chea= per.
> > > have you heard about "Cat. 5" cables ? did you won= der why it was more
> > You have never learn that this kind of cable could be around 50 m= eter
> > long ! Here 1 or 2 meters is much enought !
> and you think that it's not the same problem ????
> have you heard about Xtalk and such stuff ? you CAN't make it with a 1= -layer PCB.

That's why ethernet cable are made by pair (like lvds, d is for
differential). And with some ground it could pass.

> you need at least 3 layers to make a decent transmission line

so 4 layers, like usual mother board.

> (shield/insulator/signal/insulator/shield). And depending on your sign= al's
> characteristics, you have to change the dimensions of the tracks,
> so they are adapted to the thickness of the PCB and the permeability o= f
> the insulator (if it's epoxy or teflon or something else).
>
> Whether the wire is 50m or 1m, the problem is the same...
>

Not really. The Characteristique are made to say that your cable could
be 50 meter long, so the signal could be mixed with a certain level of
noise. If you need shortest cable, you could adjust the quality of the
cable.

> > > > > i compare what can be compared.
> > > > > the current idea is simply not realistic.
> > > > Yes, the idea that you have understood, not mine !
> > > talk about a monodirectional synchronous parallel (byte ?) > > > bus with some control signals, a clock (dual edge ?) and it'= s ok for
> > > me, whatever your idea is. Anybody can implement that with a=
> > Fast clock one large network, you have to deal with clock skew. > it's an old known problem and there are some old known solutions.
> ever heard about a "clock tree" ?... if you have a good arch= itecture,
> you don't have skew troubles.
>

Don't forget that i'm microelectronic engineer and clock tree are a
basis... Which is not so simple at all.

> > Most of the time, each founder (ST microelectronics, TSMC, infine= on,...)
> > have a macro cell to do gigaethernet and do all the hard things (= serial,
> > deserials).
> and you'll by the components ? come on...

The chip maker will by it.

> and please, don't talk about "Ethernet", it seems like it's<= BR> > only a serial point to point link (if i remember one of your messages)= .
>

But, it is !

> > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify= 5V and
> > some nF of charge. I don't want to repeat it each time.
> hey, i'm not dumb, i know that TTL is slow. thanks.
>
> but just a question : how will you debug your stuff ? will you use
> a 10GS/s logic analyser ? with a simple enough protocol, i can
> debug the interface with "off the shelf parts" that i can so= lder at will,
> the old school way, just like any "hacker".
>

Like everybody, you will use a standart JTAG port.

> Then, when it's developped, you only have to change the electrical
> levels (that is : the pin's driving gates) and you can do LVTTL or wha= tever
> high-speed connexion. it's just a matter of changing the electrical sp= ec.
> Yes i want speed, but a "hacker" needs a way to see what hap= pens without
> the need of extremely expensive devices. by clocking the chip slower > and adapting the electrical level (with the adapted buffers or transmi= tters),
> you can hook anything to the F-BUS.
>

If you use low voltage it's because you can't manage with higher one. So it could be impossible to change it !

> > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compa= re to
> > usual system.
> this kind of speed is used for I/O with maybe a controller or somethin= g
> like that. When i speak about "TTL parts", it's something li= ke a 8255
> or any very slow byte-based I/O chip. just like during the old days > of the 8-bit systems...
>

And you want performance by slow down the network only to put good old
I/o chip....

> > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around = 300 Mhz
> > with DDR or more with QDR. With LVDS, you can reach around 600 Mh= z by
> > pin. BUT you can't really add a connector between 2 pins at that = speed.
> then it must be soldered. but then, this speed is not required for
> handcrafting your own I/O board on a pre-drilled PCB. do you know a mo= use
> or a keyboard or even a LCD screen that requires 600M x N pins of data=
> per second ?
>
????? I speak only for the network system, to be compared to the bus
system in intel board the 64 bit now 200 Mhz multipomped bus. Not to the PCI or EISA.

> Scalability means scale-down and scale-up. 500Mbps is fine, but when y= ou
> don't need that much, it's an overkill. And you propose to make an ada= pter
> that will bother of the I/O, but how many custom chips will you requir= e
> to interface your connexion to any other stuffs ? Having a simple and<= BR> > one-fits-all protocol that does low and high-speed helps reduce the > number of different chips and interfaces...
>

First only one to connect other system (PCI, IO,...) and no G-ship
(include inside the fcpu)

> > My choice is to have a quick link (performance are our goal, isn'= t it ?).
> not only. In the design goals of the F-CPU, there are 3 other stuffs.<= BR> >
Which one ?

> > Then you just had to provide a bridge between the quick link and = a
> > SRAM like bus. I think that could be easy : Just a link like for = the
> > fcpu and a little glue for the interface.
> i'll give you the honnor of doing the first one...
>
> > > now you're asynchronous, you have to deal with PLL and clock=
> > > recovery, hyperfrequencies, signal integrity, skew, etc... > > > that a lot of troubles for almost nothing.
> > Not at all ! because you deal with macrocell and all the suft are= soon made.
> ain't it magical ??...
> are you so confident and faithfull in the technologies ?
>
Read there spec.

> > > you want speed ? put the wires in parallel, don't serialize = the bits...
> > Yes, but the limit are the number of pin and the prices ! And the= n you
> > alwas have the speed of the clock with LVDS, you always have the<= BR> > > electrical and speed problem.
>
> ok, let's compare serial and parallel.
>
> you want 1Gbps links. halve it now, because the actual efficiency
> of a serial bus is not the raw peak number. With 10Base, one can't tra= nsfer
> more than 500K bytes per second. or 520. whatever.
> So let's imagine that you can SUSTAIN 50 M bytes per second.
> caugh. caugh. ok, imagine you can reach 70M bytes in the two direction= s.
> 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M bytes/s<= BR> > (or 8 Gbps).
>

True but with how many wire ?

> Ok, i know, you want to reach 8Bgps by using 8 links.
> but how are they connected ? if you want to make a ring, you'll
> dissipate your bandwidth, and if you want to make neighbour to neighbo= ur
> connexions, you'll require 64 pins (or better 100, counting grounds/VC= C)
> per neighbour. retour case d=E9part...
>

Compare the number of wire and the cost of a BGA compare to a PGA.

> > > > In usual core, you have simple bus and it's easy to
> > > > put rom or eeprom to boot. But here, you need something= more special to boot.
> > > and who will build that ? do you have the spare parts somewh= ere ?
> > "spare part", i don't understand.
> i mean : go buy some such chips at St Quentin Radio or Radio Shacks...=
> a chip that is available for sale in public catalogs.
>

You are realy funny, even by Radiospares you can't buy 3.3 V logic, and
you want an killing design to compet against alpha !

> > One day, you say you want performance,
> > the other days somthing so slow to be compatible with TTL. I don'= t
> > understand you...
>
> i want something that can do both, but of course not at the same time.=
> you can't access a mouse or handcrafted I/O board (anything that you > see in Elektor or Electronique Pratique) with the same means as anothe= r CPU.
> But the protocol and the layout must remain the same, as to ease the P= CB design
> and the easy replacement of the chips.
>

*<;p
> > > > Have you a link for a preditive routing algorithme ? I = think that my
> > > > collegue which make a thesis about real time network wi= ll be very
> > > > interrested to know that exist.
> > >
> > > the routing stuff is taught during the DEUG at Paris 8 unive= rsity.
> > > ask Amal Stri from the transversal department.
> > >
> > > When at Boston, in a (expensive) library, i found (but didn'= t buy)
> > > a VERY cool about the T3E and similar architectures. The rou= ting
> > > algos are rather simple and very efficient.
> >
> > I seriously doubt about the complexity and the scalability...
>
> remember, it's a torus. only, it's 3D :-)
> for the other details, it's up to you to go to the library,
> read as many book as you can and ask the teachers and the
> educated people from comp.arch and comp.sys.super...
> i won't do it for you, you wouldn't believe what i say :-P
>
> > > > If we made a simple core (like ARM), we don't need g-sh= ip and all that crap.
> > > not true. ARM chips require I/O chips. Unless you buy the sy= nthesised core,
> > > and implement it in the middle of a sea-of-gates ASIC with y= our prefered I/O.
> > One more times, you don't unsderstand ! i propose like leon, just= to
> > develope the fc0 (the core) and let other gays to use it.
> so let's drop this silly network/bus whatever debate for a while... >
> > > > If we made a processor ("a system") we should= consider to have
> > > > fault tolerance capabilities. And hot swap is the basis= !
> > > not necessarily. fault detection and bypass are a SW matter,=
> > > with the help of some HW (ECC/SEC). but the rest is purely a= n electrical
> > > problem.
> > >
> > Not really, i don't speak about fault detection but failure toler= ant (a
> > single dead card don't stop the all system, you just have to chan= ge it).
>
> it's the SAME thing. You can't be "fault tolerant" if you ca= n't detect
> the fault and take the necessary SW measures. It's obvious...
> i'm just trying to avoid "buzzwords" that taint the debate w= ith black magic ;-)
>
> > > some designs that you should investigate (using several diff= erent books,
> > > saying different stuffs) : T3D/E (it's a 3D torus with ALPHA= s at the nodes),
> > > CM1 (12-cube with extremely simple routing), CM5 (fault tole= rance, "big tree"
> > > network, message passing communication etc.), SGI/SUN/HP sca= lable computing nodes
> > > (i found the Convex (circa 1995) very interesting, but Conve= x is now owned by HP).
> >
> > Just for information : how much for a single chip ? And how much = heat
> > for a chip ? You try to give some piece of your knowledge but you= don't
> > understand the "simple coma" from SUN for their last sy= stem (from an URL
> > given on the list), so ?
>
> i've tried, but it's not that clear for me, what's so special ?
> when there's a page fault, i trap. Just make the correct fault handler= ,
> and you implement any memory protection and sharing you want.
> It leaves the door open to ANY memory system implementation.
> what else do you want ? i'm still waiting for a clear and HW propositi= on.
>

HW or SW that not the point, you can used both for the same thing, the
only 2 issue are cost and performance. Bevore, we had to find the
algorythmes and then implement it.

> > > i know, it's a matter of culture...
> > I just see it's like jam, ...
> J'en ai une meilleure, mais je ne l'ai pas invent=E9e non plus,
> elle est de Jacques Brel : "La culture, c'est la m=E9moire des > cons qui n'ont rien invent=E9". Il avait vraiment des id=E9es
> noires avant de mourir... La culture, il faut se la faire
> tous les jours et ne pas trop camper sur ses positions...
> avec le f-cpu, on a ce qu'il faut comme action :-)
>
> bonne nuit,
>

"La culture est ce qui reste quand on ne sait rien faire" Francoi= se
SAGAN, un peu provoc, l=E0... ;p

> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D""
From "Didi" Sun Jan 7 17:17:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02555 for ; Mon, 8 Jan 2001 00:45:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:45:59 +0100 (MET) Received: (qmail 5372 invoked by uid 0); 7 Jan 2001 15:18:25 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx24) with SMTP; 7 Jan 2001 15:18:25 -0000 X-eGroups-Return: sentto-1101623-1867-978880692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 07 Jan 2001 15:18:21 -0000 X-Sender: flei@wanadoo.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 15:18:12 -0000 Received: (qmail 71482 invoked from network); 7 Jan 2001 15:18:11 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 7 Jan 2001 15:18:11 -0000 Received: from unknown (HELO antholoma.wanadoo.fr) (193.252.19.153) by mta3 with SMTP; 7 Jan 2001 16:19:16 -0000 Received: from celeron (193.251.78.86) by antholoma.wanadoo.fr; 7 Jan 2001 16:18:11 +0100 Message-ID: <001701c078c5$aac98d80$3d8dfea9@celeron> To: References: <200101071013.LAA4234551@mail.unimo.it> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Didi" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 16:17:04 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5f5b3640ce6eaa5a744970e3f09c0f35 Status: R X-Status: N
----- Original Message -----
From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
To: <f-cpu@egroups.com>
Sent: Sunday, January 07, 2001 10:18 AM
Subject: [f-cpu] REMOVE


> On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:
>
> >Expand your business with
> >    Email Marketing!
> >
> >Market your product or service
> >     to MILLIONS!
> >
> >Don't waste another minute...
> >
> >Click Reply with your name,
> >telephone number and the
> >product or service you wish
> >to market. We will be in
> >touch with you shortly!
> >
> >
> >
> >
> >
> >Removal Instructions
> >****************************
> >To be removed from this list
> >please reply with "REMOVE"
> >in the subject.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Expand your business with
> >    Email Marketing!
> >
> >Market your product or service
> >     to MILLIONS!
> >
> >Don't waste another minute...
> >
> >Click Reply with your name,
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> Prof. Maurizio Zoboli
> Dipartimento di Scienze dell'Ingegneria
> Universita' di Modena e Reggio Emilia
> via Vignolese 905
> I-41100 Modena, Italy
> Tel.: +39 059 2056163
> Fax: +39 059 2056129
> e-mail: maurizio.zoboli@unimo.it
>
>
>
>


eGroups Sponsor
From Yann Guidon Sun Jan 7 18:21:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02600 for ; Mon, 8 Jan 2001 00:46:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:09 +0100 (MET) Received: (qmail 14106 invoked by uid 0); 7 Jan 2001 17:17:06 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx21) with SMTP; 7 Jan 2001 17:17:06 -0000 X-eGroups-Return: sentto-1101623-1870-978887773-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 07 Jan 2001 17:16:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 17:16:12 -0000 Received: (qmail 42791 invoked from network); 7 Jan 2001 17:15:57 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 Jan 2001 17:15:57 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 7 Jan 2001 18:17:01 -0000 Received: from f-cpu.org (nas3-95.aub.club-internet.fr [195.36.145.95]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA18357 for ; Sun, 7 Jan 2001 18:15:52 +0100 (MET) Message-ID: <3A58A5AA.FFEB0D70@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200101071013.LAA4234551@mail.unimo.it> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 18:21:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f00135d7b7933871f3b3275c1147ddc7 Status: R X-Status: N hello,

look at the header of the message, it contains :
"List-Unsubscribe:  <mailto:f-cpu-unsubscribe@egroups.com>"

if you want to unsubscribe, sending messages to the list
will not work. you have to send a message to the addresse copied
above.

although this should work, the egroups.com site mentions
another address, please read the notice on the web.

regards,

maurizio zoboli wrote:
<snip>
>
> Prof. Maurizio Zoboli
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "Didi" Sun Jan 7 17:28:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02606 for ; Mon, 8 Jan 2001 00:46:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:11 +0100 (MET) Received: (qmail 15961 invoked by uid 0); 7 Jan 2001 17:18:24 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.112 (mx12) with SMTP; 7 Jan 2001 17:18:24 -0000 X-eGroups-Return: sentto-1101623-1868-978881191-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 07 Jan 2001 15:26:40 -0000 X-Sender: flei@wanadoo.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 15:26:31 -0000 Received: (qmail 24836 invoked from network); 7 Jan 2001 15:26:29 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 7 Jan 2001 15:26:29 -0000 Received: from unknown (HELO mahonia.wanadoo.fr) (193.252.19.58) by mta1 with SMTP; 7 Jan 2001 15:26:28 -0000 Received: from celeron (193.251.78.86) by mahonia.wanadoo.fr; 7 Jan 2001 16:26:28 +0100 Message-ID: <001d01c078c6$d32a5b00$3d8dfea9@celeron> To: References: <200101071013.LAA4234551@mail.unimo.it> <001701c078c5$aac98d80$3d8dfea9@celeron> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 From: "Didi" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 16:28:07 -0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] NO MORE SPAM MAIL !!! DO YOU UNDERSTAND ME ? STUPID GUY Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 803e4ad507920e712446f64b9c714295 Status: R X-Status: N
----- Original Message -----
From: "Didi" <flei@wanadoo.fr>
To: <f-cpu@egroups.com>
Sent: Sunday, January 07, 2001 4:17 PM
Subject: [f-cpu] REMOVE


>
> ----- Original Message -----
> From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> To: <f-cpu@egroups.com>
> Sent: Sunday, January 07, 2001 10:18 AM
> Subject: [f-cpu] REMOVE
>
>
> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:
> >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >telephone number and the
> > >product or service you wish
> > >to market. We will be in
> > >touch with you shortly!
> > >
> > >
> > >
> > >
> > >
> > >Removal Instructions
> > >****************************
> > >To be removed from this list
> > >please reply with "REMOVE"
> > >in the subject.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Prof. Maurizio Zoboli
> > Dipartimento di Scienze dell'Ingegneria
> > Universita' di Modena e Reggio Emilia
> > via Vignolese 905
> > I-41100 Modena, Italy
> > Tel.: +39 059 2056163
> > Fax: +39 059 2056129
> > e-mail: maurizio.zoboli@unimo.it
> >
> >
> >
> >
>
>
>
>


eGroups Sponsor
Click Here!
From rvsicam@aol.com Sun Jan 7 17:39:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02609 for ; Mon, 8 Jan 2001 00:46:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:12 +0100 (MET) Received: (qmail 7832 invoked by uid 0); 7 Jan 2001 17:29:34 -0000 Received: from unknown (HELO mu.egroups.com) (64.211.240.238) by mx0.gmx.net (mx13) with SMTP; 7 Jan 2001 17:29:34 -0000 X-eGroups-Return: sentto-1101623-1869-978885583-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 07 Jan 2001 16:40:08 -0000 X-Sender: RVSICAM@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 16:39:42 -0000 Received: (qmail 2104 invoked from network); 7 Jan 2001 16:39:42 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 7 Jan 2001 16:39:42 -0000 Received: from unknown (HELO imo-r13.mail.aol.com) (152.163.225.67) by mta2 with SMTP; 7 Jan 2001 16:39:41 -0000 Received: from RVSICAM@aol.com by imo-r13.mx.aol.com (mail_out_v28.35.) id a.e8.ed0f913 (24896) for ; Sun, 7 Jan 2001 11:39:36 -0500 (EST) Message-ID: To: f-cpu@egroups.com X-Mailer: 6.0 sub 171 From: rvsicam@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 11:39:35 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] remove Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4fc991838dab89916f7bbb5ef69fe039 Status: R X-Status: N

eGroups Sponsor
From "Marco Al" Sun Jan 7 22:38:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02669 for ; Mon, 8 Jan 2001 00:46:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:29 +0100 (MET) Received: (qmail 28360 invoked by uid 0); 7 Jan 2001 21:36:49 -0000 Received: from unknown (HELO fk.egroups.com) (64.211.240.232) by mx0.gmx.net (mx08) with SMTP; 7 Jan 2001 21:36:49 -0000 X-eGroups-Return: sentto-1101623-1872-978903244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 07 Jan 2001 21:34:14 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 21:34:02 -0000 Received: (qmail 50269 invoked from network); 7 Jan 2001 21:30:43 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 7 Jan 2001 21:30:43 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 7 Jan 2001 21:30:42 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id WAA12551 for ; Sun, 7 Jan 2001 22:30:41 +0100 (MET) Message-ID: <00a901c078f2$2bfacf50$29e65982@student.utwente.nl> To: References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 22:38:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 69e20ca54b6e098391594c14a7ad5b87 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>


> Yann Guidon a =E9crit :

> > if you target "small SMP" only, maybe you can do it wit= h a shared bus,
> > but don't expect wonders above 4 CPU. If you're doing CPU-only ta= sks, it's
> > ok, but when you start to move things around, it's the real mess.=
> > Intel sticks to this because the architecture is more or less stu= ck.
> > they want cheap systems and make big profits, but still compete (= with
> > some pain) in the SPEC contests.
> >
>
> You always forget one big thing. Here we speak about private memory an= d
> communication network to speed up memory interface. So in the intel > architecture, 4 is a maximum because all the 4 cpu read the memory
> thought the same shared bus. In our system, only message go thought th= e
> network. In the best case, only I/O instruction go thought the network=
> and very few message from the processes.

You seem to presuppose that it wont have a single memory space with hardwar= e
maintained coherency... I dont mind, I like transputers. But a lot of users= of
parallel systems disagree.

> > Clearly, this B=3DL/N is a thing that i try to avoid for other th= ings as well,
> > and it's my "hammer" argument when i try to promote poi= nt to point links.
> > We spare the (distributed) control logic (all the nasty deadlock = stuffs etc)


Thats one way of looking at it, the other way is that its a given that L ha= s to
be B*N' and that for N>N' you need extra hierarchies.

And you wont get away from hierarchies, a single chip can only connect to s= o
many processors and have so much backplane capacity. The control will alway= s be
distributed at a certain point.

> > Now, another stuff. Nico usually wants a ring. It's "simple = to route",
> > it's fun and doesn't need much "efforts". But there is = still the same
> > problem as before : the more CPU, the less bandwidth when one CPU= wants
> > to talk to another. 1/N (or 2 pins / N CPU if you want the "= real
efficiency").
> > The solution is rather easy : you have to expand that to the othe= r 2
dimensions,
> > hence the "CRAY T3D" and the extension, T3E. Routing is= still the same but
the
> > address is split into 3 fields that are interpreted as an indepen= dent ring
address.

Exactly.

My opinion also kind of depends on where the motherboard chipset functional= ity
would be present and how many pins that would need.

I think making a bridge which can have a point-to-point/shared/ring connect= ion
to the processors which itself plugs into a socket-7 board (or perhaps even= a
PCI slot) is a good solution :) (bios should be local though, obviously) Ge= tting
a processor made, no matter how many frills you remove is a huge task... I = think
designing a motherboard chipset on top of that is an unnecessary burden. Yo= u can
always later replace the bridge with a true motherboard chipset.

Marco
eGroups Sponsor=
3D"Click
From jeff@llandre.freeserve.co.uk Sun Jan 7 23:46:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02675 for ; Mon, 8 Jan 2001 00:46:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:30 +0100 (MET) Received: (qmail 27361 invoked by uid 0); 7 Jan 2001 22:52:33 -0000 Received: from c3.egroups.com (208.50.99.225) by 10.1.4.112 (mx12) with SMTP; 7 Jan 2001 22:52:33 -0000 X-eGroups-Return: sentto-1101623-1873-978907921-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 07 Jan 2001 22:52:12 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 22:52:00 -0000 Received: (qmail 66381 invoked from network); 7 Jan 2001 22:51:59 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 7 Jan 2001 22:51:59 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta1 with SMTP; 7 Jan 2001 22:51:58 -0000 Received: from modem-50.dysprosium.dialup.pol.co.uk ([62.136.52.178] helo=62.136.52.178) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14FOfI-0005R6-00 for f-cpu@egroups.com; Sun, 07 Jan 2001 22:51:54 +0000 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 22:46 +0000 Reply-To: f-cpu@egroups.com Subject: RE: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9b9e20e34631340f57c308a3b0694415 Status: R X-Status: N Regarding this rather strange multi cpu argument:

10 base t is not cutting edge, 1000 base t is.
You can buy it off the shelf. full duplex via a switch,
you can get 200 megabytes per second without compression
between hosts. Obviously, multiple lan adaptors enable
multiple segments to be used in parallel, and therefore
it is quite easy to exceed the bandwidth of an sdram in this
way (but rather pointless).

smt as used by intel etc seems to share the whole of
system ram between all cpus which is dumb.
Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
but they also share the third sdram for comms.

Not exactly a new idea, but much better than smt.

All the multi cpu stuff is interesting but pointless. It
doesnt change the core. Why not get back to that. We
shouldnt waste whygee or michaels time, when they are
doing so well with the vhdl.
like someone said, shit happens, forget 17c3,
success is the sweetest form of revenge.
Once core is around, you multi cpu dudes can work on your
own multiprocessors.

Jeff Davies
eGroups Sponsor
Click here!
From Vanderhoeven Steve Sun Jan 7 20:50:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02696 for ; Mon, 8 Jan 2001 00:46:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 00:46:35 +0100 (MET) Received: (qmail 32072 invoked by uid 0); 7 Jan 2001 23:21:22 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx13) with SMTP; 7 Jan 2001 23:21:22 -0000 X-eGroups-Return: sentto-1101623-1871-978896984-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 07 Jan 2001 19:49:52 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 19:49:37 -0000 Received: (qmail 4044 invoked from network); 7 Jan 2001 19:49:22 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 Jan 2001 19:49:22 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta3 with SMTP; 7 Jan 2001 20:50:26 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.11.1/8.11.1) with ESMTP id f07Jmrf15344 for ; Sun, 7 Jan 2001 20:48:53 +0100 (MET) Message-Id: <200101071948.f07Jmrf15344@essi.essi.fr> To: f-cpu@egroups.com User-Agent: IMHO/0.98.1 (Webmail for Roxen) In-Reply-To: <3A57E362.1046463B@f-cpu.org> From: Vanderhoeven Steve MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 Jan 2001 20:50:06 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war =?iso-8859-1?q?ehr=3F?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9c738edac803c731503834470542b26a Status: R X-Status: N
> If you connect more than 2 CPU on the same bus, they compete for the ressource
> and the bottleneck gets even narrow.
>

atm?

steve
eGroups Sponsor
From Michael Riepe Mon Jan 8 01:00:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03315 for ; Mon, 8 Jan 2001 03:59:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:34 +0100 (MET) Received: (qmail 18847 invoked by uid 0); 8 Jan 2001 00:02:42 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by 10.1.4.112 (mx12) with SMTP; 8 Jan 2001 00:02:42 -0000 X-eGroups-Return: sentto-1101623-1875-978912087-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 08 Jan 2001 00:01:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 00:01:26 -0000 Received: (qmail 65808 invoked from network); 8 Jan 2001 00:00:16 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Jan 2001 00:00:16 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.138) by mta1 with SMTP; 8 Jan 2001 00:00:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02348; Mon, 8 Jan 2001 01:00:11 +0100 Message-ID: <20010108010011.63476@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <200101071013.LAA4234551@mail.unimo.it> <001701c078c5$aac98d80$3d8dfea9@celeron> <001d01c078c6$d32a5b00$3d8dfea9@celeron> X-Mailer: Mutt 0.84e In-Reply-To: <001d01c078c6$d32a5b00$3d8dfea9@celeron>; from Didi on Sun, Jan 07, 2001 at 04:28:07PM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 01:00:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] NO MORE SPAM MAIL !!! DO YOU UNDERSTAND ME ? STUPID GUY Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2abe10faf82eb7a11386bee3c3292b37 Status: R X-Status: N On Sun, Jan 07, 2001 at 04:28:07PM -0000, Didi wrote:
>
> ----- Original Message -----
> From: "Didi" <flei@wanadoo.fr>
> To: <f-cpu@egroups.com>
> Sent: Sunday, January 07, 2001 4:17 PM
> Subject: [f-cpu] REMOVE
>
>
> >
> > ----- Original Message -----
> > From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 10:18 AM
> > Subject: [f-cpu] REMOVE

Interesting how many people read this list but never say something.

On the other hand, these dumbheads who are unable to read headers
and quote the whole spam just to say "remove" to the wrong person(s)
(or even quote the replies, like in this case) are worse than spammers :(

Guys, you have a brain.  PLEASE USE IT.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Sun Jan 7 15:46:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03336 for ; Mon, 8 Jan 2001 03:59:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:39 +0100 (MET) Received: (qmail 3919 invoked by uid 0); 8 Jan 2001 00:32:35 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx14) with SMTP; 8 Jan 2001 00:32:35 -0000 X-eGroups-Return: sentto-1101623-1874-978908633-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 07 Jan 2001 23:03:58 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 7 Jan 2001 23:03:52 -0000 Received: (qmail 48313 invoked from network); 7 Jan 2001 23:03:51 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 7 Jan 2001 23:03:51 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.138) by mta1 with SMTP; 7 Jan 2001 23:03:42 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00744; Sun, 7 Jan 2001 15:46:44 +0100 Message-ID: <20010107154644.14953@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A586520.68469E14@ifrance.com>; from Nicolas Boulay on Sun, Jan 07, 2001 at 01:46:24PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 15:46:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 13ff8f3c2a33c43becb0ec90e6eb3506 Status: R X-Status: N On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote:
[...]
> You always forget one big thing. Here we speak about private memory an= d
> communication network to speed up memory interface. So in the intel > architecture, 4 is a maximum because all the 4 cpu read the memory
> thought the same shared bus. In our system, only message go thought th= e
> network. In the best case, only I/O instruction go thought the network=
> and very few message from the processes.

It depends.  If you use ccNUMA or COMA, there will be a lot of additio= nal
traffic to keep the caches up-to-date.  And if you're running certain<= BR> parallelized tasks with high communication overhead, even Gbps ethernet
becomes too slow.

> > I am trying to find the "least common denominator" for = a F-CPU system
> > that can range from 1 CPU to any arbitrary number of CPUs (just l= ike
> > the register width : not bound to anything). let's take a few cas= es,
> > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" shou= ld also scale
> > to much more CPUs : the widest systems today (see the monters at = the LANL)
> > can scale to more than 10K CPU, so let's round up to 65536.
> >
> > now let's compare the alternatives...
> >
> > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's di= sastrous
> > with more CPU.
> >
> > buses are known, used and they work, but some people here want a = "multimaster"
> > bus. This means that the bandwidth is drawn by several points and= the bus
> > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU,= equal to
> > the available bandwidth provided by the bus and divided by N CPU)= .
> >
> > that's what i try to avoid.

It's actually worse than B=3DL/N.  Don't forget the overhead for bus arbitration and transfer direction turn-arounds.  I wouldn't be surpri= sed
at all if bandwidth drops below B=3DL/N/2.  If you want to come closer=
to B=3DL/N, you need to do large block transfers (unreasonable except for mass storage access), and then you'll get problems with latencies (other devices have to wait until the transfer is over and a new bus master
can be elected).  Another problem is that arbitration and turn-around<= BR> times rise dramatically when the bus becomes longer (signal delay,
bad impedance matching when tri-state drivers are used, and so on).

> > Clearly, this B=3DL/N is a thing that i try to avoid for other th= ings as well,
> > and it's my "hammer" argument when i try to promote poi= nt to point links.
> > We spare the (distributed) control logic (all the nasty deadlock = stuffs etc)
>
> There are always possible traffic Jam. How do you manage when 2 nodes<= BR> > try to speak to the same nod ? You have to manage something to avoid > losing informations.

They will have to share the available bandwidth.  The G-Chip will have=
to queue the second message while it's sending the first one.  This could be avoided by putting 4 F-Bus interfaces into the CPU itself
(did anybody say "transputer"?), which makes the G-chip obsolete<= BR> except for peripheral I/O and message routing/switching, or by using a
faster (4x) link between F-CPU and G-chip.

> > and it's very simple to implement. the PCB is simpler, too.
> >
> > If you connect more than 2 CPU on the same bus, they compete for = the ressource
> > and the bottleneck gets even narrow.
> >
>
> Yes, but less drastically as intel SMP.
> 
> > On the pin count vs bandwidth argument, it's similar. Of course, = we can find
> > a lot of counter-examples and special cases, but the example of t= he broadcast
> > is not the best one. Most of the requests are from one node to a = single other
>
> In fact, not. It depend how much process communicate between them. And=
> sometimes the only [simple] way to find a "moving" ressource= s is to send
> a braodcast.

Yep.  Very common when (simple) COMA is used, IIRC.

> > and here, the efficiency of a bus drops dramatically ! for a N-CP= U system,
> > the efficiency is of 2 used bus interfaces for N bus interfaces (= you can
> > replace "bus interface" with "pin"), 2/N is s= imilar to the 1/N scheme
> > (if we speak about the "big O" or complexity). This mea= ns that :
> > the more CPU, the least efficient ! you'll see that the best way = to avoid
> > this is by having as few CPU by link as possible, and the minimum= is 2.
> > that's "point to point"...
> >
> > Now, another stuff. Nico usually wants a ring. It's "simple = to route",
> > it's fun and doesn't need much "efforts". But there is = still the same
> > problem as before : the more CPU, the less bandwidth when one CPU= wants
> > to talk to another. 1/N (or 2 pins / N CPU if you want the "= real efficiency").
> > The solution is rather easy : you have to expand that to the othe= r 2 dimensions,
> > hence the "CRAY T3D" and the extension, T3E. Routing is= still the same but the
> > address is split into 3 fields that are interpreted as an indepen= dent ring address.

A ring is actually much better than a bus because it is a unidirectional device (no change of transfer direction, no tri-state buffers necessary, faster signalling) and arbitration is both simpler and faster (e.g. token ring).  The members of the ring still share the available bandwidth, but you come closer to B=3DL/N.  Per-CPU bandwidth is still limited, t= hough.

> In the flight back to France, we have spoken about ring of ring.(and > called the architecture the lord of the ring ;p). A ring is composed > around 8 to 16 card (cpu+ram or IO). A card could be used to communica= te
> with other ring. Maybe it's possible to grow in hierachy without to mu= ch
> trouble.
>
> > here, you don't have 1 ring but x*y*z rings. It means that there = is
> > no bandwidth problem at all, because each CPU communicates with i= ts 6 neighbours.
> > It works very well, it can be tweaked to become "fault toler= ant" (through dynamic
> > node addresses) and scales perfectly (almost linearly with the CP= U number).
> >
> So !
[...]

scales "perfectly" <EM>as long as the number of members per= ring is limited</EM>.
Sorry for shouting ;)

For highest-speed n-to-n communication, use direct connections.
Since this doesn't scale at all, you need to find a compromise when
the number of CPUs increases -- switches or crossbars, trees or rings.
In any case, the solution depends on the work the system has to do.
With the drafted G-chip with 4 links, we could build

      - a 4-CPU directly-connected system
      - a single ring (double ring requires 5 link= s, 1 for CPU)
      - a binary or trinary tree (USB-style)
      - a flat hexagonal `beehive' structure
      - a cube
      - ...

This is a pretty long list of options, isn't it?  Let the implementor = (or
system integrator) choose from this list; we don't have to care.  We j= ust
need to make sure that the G-chip is versatile enough to support at least two or three of the most common topologies, and probably mixed topologies (like a tree or ring of directly-connected clusters, for example).
Preferably with auto-sensing capabilities =E0 la USB, i.e. the structure is determined at run (or boot) time.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D"Click
From Alan Grimes Mon Jan 8 01:39:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03339 for ; Mon, 8 Jan 2001 03:59:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:41 +0100 (MET) Received: (qmail 16230 invoked by uid 0); 8 Jan 2001 00:37:40 -0000 Received: from hl.egroups.com (208.50.99.197) by 10.1.4.112 (mx12) with SMTP; 8 Jan 2001 00:37:40 -0000 X-eGroups-Return: sentto-1101623-1878-978914256-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hl.egroups.com with NNFMP; 08 Jan 2001 00:37:39 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 00:37:35 -0000 Received: (qmail 80159 invoked from network); 8 Jan 2001 00:37:32 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 8 Jan 2001 00:37:32 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta3 with SMTP; 8 Jan 2001 01:38:37 -0000 Received: from 66-44-56-243.s243.tnt2.lnhva.md.dialup.rcn.com ([66.44.56.243] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14FQJW-0002kC-00 for f-cpu@egroups.com; Sun, 07 Jan 2001 19:37:30 -0500 Message-ID: <3A590C44.6F355AE2@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 19:39:32 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] This project really sucks. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e5bc81b150340307f93060cda93f067c Status: R X-Status: N =P

om   (I'm invincible!)

      Hey, you morons, whomever thinks he is running this project is doing an
absolutly, unforgivably, horrible job. If you were, say, working for a
company and were working in a well-managed tightly optomized R&D team,
you guys would be briliant. BUT YOU'RE NOT!!!

      In a private company you have the luxury of closed-door face2face
meetings where you can get a lot done. But, for an internet project such
as this, that is totally inadqiquate. You must keep and maintain a
current website...  oops! I *thought* it was f-cpu.tux.org (which should
be updated or deleted.). For the ammount of traffic on the list,
f-cpu.org is also stale, so my point holds, though not as strongly.. =\

      An project, such as what this one pretends to be, must provide an easy
"on-ramp" for people who are new to the project to become active
participants. Such consessions to the newbies must include:

in order of importance:

      - A glossary.
      - A reading list.
      - A document/source managment system. that is easily accessable to any
reasonable web browser.
      - A job managment system that can manage tasks and bugs from proposal
to retirement.


The point I am trying to make here is that I have been on the list for
two and a half years and I can't even say for certain what the status of
the project is or wheather we have reached any "milestones". I am really
frustrated by the apparent lack of progress. I need a gnu machine! =P

I therefore make the following demands:

- A Czar or voting comission with a fixed registered membership must be
appointed or elected for the sole purpose of approving contributions to
the document/source managment system with the objective of focusing the
efforts of the group towards the completion (*ghasp*) and delivery of a
product to market.

- A formal contributor development system, like what you would find in a
company, that will provide training or mentoring to aspiring
contributors.

- The founding of an American branch of the apparently extant french
F-CPU orgainization. This is in recognition that local groups work
better.


Really, This project serves me only when it yields something that is
useful. Failing that it can go to hell...

I will see what happens over the next two months and then go bug the
opencore people some more, and perhaps work up a project over there.

--
The 'apocolypse' happened in 1848.
Now if everybody would only just look... =\
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click here!
From Keyshaun Mon Jan 8 01:21:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03345 for ; Mon, 8 Jan 2001 03:59:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:43 +0100 (MET) Received: (qmail 17211 invoked by uid 0); 8 Jan 2001 00:47:27 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx14) with SMTP; 8 Jan 2001 00:47:27 -0000 X-eGroups-Return: sentto-1101623-1876-978912886-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 08 Jan 2001 00:14:52 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 00:14:46 -0000 Received: (qmail 2139 invoked from network); 8 Jan 2001 00:14:42 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 8 Jan 2001 00:14:42 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta2 with SMTP; 8 Jan 2001 00:14:42 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14FQ3e-0001Wc-00 for ; Sun, 07 Jan 2001 17:21:06 -0700 X-X-Sender: To: In-Reply-To: <20010108010011.63476@thrai.stud.uni-hannover.de> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 7 Jan 2001 17:21:06 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] NO MORE SPAM MAIL !!! DO YOU UNDERSTAND ME ? STUPID GUY Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6d0e49aaef598b4c9dc9bea28f0a177a Status: R X-Status: N I must say that I am often one of the people who has little to say.  I
just find the discussion of hardware design to be quite interesting.  On
another note I almost responded to f-CPU with REMOVE in the subject.
Other than that I think you guys are doing great work, though I must say
that for a CPU project it's amazing how much is focused away from the
processor.  Things like the G-Chip seem like they should branch into their
own seperate but related project.  Keep it simple, if I were trying to
design something I would probably consider discarding the G-Chip as
bloatware for anything other than SMP.  The F-CPU looks great to me, I
would love to use it.  I would contribute skill to the project if I had
it.  Because I don't I must sit back and enjoy learning from the
discussions I read.  None the less my big point I have ended up going into
is this...  It is the Freedom CPU project not the Freedom SMP application
system project.  Keep a good focus and more will get done.  When a CPU is
ready the solutions to SMP and anything else you want to do will play
themselves out.

Shaun Kruger
thekernel@subdimension.com

> Interesting how many people read this list but never say something.
>
> On the other hand, these dumbheads who are unable to read headers
> and quote the whole spam just to say "remove" to the wrong person(s)
> (or even quote the replies, like in this case) are worse than spammers :(
>
> Guys, you have a brain.  PLEASE USE IT.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
eGroups Sponsor
Click here!
From "Marco Al" Mon Jan 8 01:35:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03348 for ; Mon, 8 Jan 2001 03:59:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:44 +0100 (MET) Received: (qmail 19763 invoked by uid 0); 8 Jan 2001 00:48:22 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx07) with SMTP; 8 Jan 2001 00:48:22 -0000 X-eGroups-Return: sentto-1101623-1877-978913665-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 08 Jan 2001 00:27:48 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 00:27:44 -0000 Received: (qmail 7288 invoked from network); 8 Jan 2001 00:27:44 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 8 Jan 2001 00:27:44 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 8 Jan 2001 00:27:43 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id BAA26960 for ; Mon, 8 Jan 2001 01:27:42 +0100 (MET) Message-ID: <001a01c0790a$e6afab00$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 01:35:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eab98cebbebed1fe9715572e744f2647 Status: R X-Status: N From: <jeff@llandre.freeserve.co.uk>

> smt as used by intel etc seems to share the whole of
> system ram between all cpus which is dumb.
> Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> but they also share the third sdram for comms.

IMO thats combining the bad aspects of NUMA and message passing combined in a
single framework...

> Once core is around, you multi cpu dudes can work on your
> own multiprocessors.

It doesnt have to, if you dont mind have suck ass performance in a shared memory
space multiprocessor system (which is ok, for most processors multiprocessor
setups are at best an afterthought... allows people like Cray etc to make some
money with custom hardware to maintain coherency, although in this case adding
that kind of functionality afterwards would be neigh impossible with the direct
memory interface).

If you want to make a processor which can scale decently in multiprocessor
setups you have to know which scheme you will be using at least in time for the
design of the MMU.

Marco
eGroups Sponsor
Click here!
From Michael Riepe Mon Jan 8 02:02:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03354 for ; Mon, 8 Jan 2001 03:59:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:45 +0100 (MET) Received: (qmail 3586 invoked by uid 0); 8 Jan 2001 01:02:35 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx14) with SMTP; 8 Jan 2001 01:02:35 -0000 X-eGroups-Return: sentto-1101623-1879-978915741-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 08 Jan 2001 01:02:25 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 01:02:19 -0000 Received: (qmail 51760 invoked from network); 8 Jan 2001 01:02:16 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 8 Jan 2001 01:02:16 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.138) by mta2 with SMTP; 8 Jan 2001 01:02:14 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02536; Mon, 8 Jan 2001 02:02:09 +0100 Message-ID: <20010108020209.12003@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> X-Mailer: Mutt 0.84e In-Reply-To: <3A590C44.6F355AE2@starpower.net>; from Alan Grimes on Sun, Jan 07, 2001 at 07:39:32PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 02:02:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] This project really sucks. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4ed5dbd9cd181d7a346562d77db4685c Status: R X-Status: N On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:
[...]
> The point I am trying to make here is that I have been on the list for
> two and a half years and I can't even say for certain what the status of
> the project is or wheather we have reached any "milestones". I am really
> frustrated by the apparent lack of progress. I need a gnu machine! =P

You should learn how to read.  Or contribute.  Or shut up.

> I therefore make the following demands:

Demands?  F*ck off.  You have no right to demand *anything*.

[...]
> Really, This project serves me only when it yields something that is
> useful. Failing that it can go to hell...

Don't ask what this project can do for you,
ask what YOU can do for the project.
(misquoting John F. Kennedy, IIRC)

> I will see what happens over the next two months and then go bug the
> opencore people some more, and perhaps work up a project over there.

Fine.  Better go NOW and start bugging somebody else.

This attitude makes me sick...
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Alan Grimes Mon Jan 8 02:32:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03357 for ; Mon, 8 Jan 2001 03:59:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:46 +0100 (MET) Received: (qmail 4873 invoked by uid 0); 8 Jan 2001 01:37:34 -0000 Received: from jj.egroups.com (208.50.144.82) by 10.1.4.112 (mx12) with SMTP; 8 Jan 2001 01:37:34 -0000 X-eGroups-Return: sentto-1101623-1880-978917849-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 08 Jan 2001 01:37:33 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 01:37:28 -0000 Received: (qmail 94941 invoked from network); 8 Jan 2001 01:30:17 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 8 Jan 2001 01:30:17 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 8 Jan 2001 01:30:17 -0000 Received: from 66-44-56-243.s243.tnt2.lnhva.md.dialup.rcn.com ([66.44.56.243] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14FR8Z-0004yP-00 for f-cpu@egroups.com; Sun, 07 Jan 2001 20:30:15 -0500 Message-ID: <3A59189B.EC5FD29D@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 20:32:11 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] This project really sucks. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a0b506f2d4c55dac08b203d2b3677f21 Status: R X-Status: N Michael Riepe wrote:
> You should learn how to read.

I can read anything that is within the reach of a highschool graduate
and a fair ammount of mathematical and technical stuff to... As I
mentioned in my post, there is little to suggest WHAT I should read,
unless you want me to spend the rest of my life reading crap untill I
finally hit on something that is relevant... It took me fully eighteen
months of applying that self same process to learning how linker-loaders
work. I literally had NO CLUE. Now its all perfectly clear to me. The
position I am taking is that I have no intention of repeating that
process.

> Or contribute.

I can't, for the reasons that I attempted to explain in my last posting.
READ IT.

> Or shut up.

Pleas understand that I am running Windows 3.11 on an Athalon processor.

The PC is far too fucked for me to write my own OS. (I have discovered
this through great labor). But I *can* write an OS for F-cpu (I hope).

I am hurting.

In a year or so I won't be able to get anything done on the net at
all... I will be profoundly fucked. "Shutting up" is not a very good
option for me, now is it?


> > I therefore make the following demands:
>
> Demands?  F*ck off.  You have no right to demand *anything*.

Maybe not. But the fact that you can't take an ounce of criticism with
regards to this project is equally un-cool. I have been observing this
project practicaly from day one. I have seen many things not happen. ;)
This posting was my attempt to encapsulate all the observations I made
into a single simple workable agenda for making things happen. If you
can't take it then go work for a company, you have nothing valuble to
contribute to an open-source project if you canot accept contributions.


> [...]
> > Really, This project serves me only when it yields something that is
> > useful. Failing that it can go to hell...
>
> Don't ask what this project can do for you, ask what YOU can do for the
> project. (misquoting John F. Kennedy, IIRC)

Read my fucking posting before making brainless comments like this. It
really shows me that you can't think one wit beyond your VHDL (or
whatever) compiler to see that other people can hardly understand what
it is you are doing. THEN you will realize that this posting WAS a
contribution. It contributed the observation that people such as myself
are essentially left-out of the project *and* it proposes a concise and
understandable method for remedying the situation. If you would like to
give me some permissions over at the sourceforge project then I will
apply suggestions and my training in project managment towards achieving
actual results.

I am sorry that linux users tend to be so goddamned dense that they
can't see or accept a simple and logical suggestion even when it is
explained to them!  No wonder their operating system is as terrible as
it is...


> > I will see what happens over the next two months and then go bug the
> > opencore people some more, and perhaps work up a project over there.
>
> Fine.  Better go NOW and start bugging somebody else.

Hey! Wanna make a CPU?  I not only can but I will make it happen. This
is what needs to be done.

> This attitude makes me sick...

So does yours.

I must appologise, I shouldn't have jumped as hard as I did but I do
really feel a lot of frustration with this...

--
The 'apocolypse' happened in 1848.
Now if everybody would only just look... =\
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
From "Iancu Silvius" Mon Jan 8 02:37:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03360 for ; Mon, 8 Jan 2001 03:59:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:48 +0100 (MET) Received: (qmail 13878 invoked by uid 0); 8 Jan 2001 01:49:20 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx13) with SMTP; 8 Jan 2001 01:49:20 -0000 X-eGroups-Return: sentto-1101623-1881-978918519-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 08 Jan 2001 01:49:04 -0000 X-Sender: silvius@mail.dnttm.ro X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 01:48:38 -0000 Received: (qmail 64884 invoked from network); 8 Jan 2001 01:39:30 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 8 Jan 2001 01:39:30 -0000 Received: from unknown (HELO terminus.dnttm.ro) (193.226.98.11) by mta3 with SMTP; 8 Jan 2001 02:40:32 -0000 Received: from silvius (ppp145.dnttm.ro [193.231.207.18]) by terminus.dnttm.ro (8.9.3/8.9.3) with SMTP id DAA15677 for ; Mon, 8 Jan 2001 03:39:17 +0200 Message-ID: <000901c07913$9ccb90e0$2618fea9@silvius> To: References: <978864180.67847@egroups.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: "Iancu Silvius" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 03:37:48 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3e45981e78f89b0d4416132e58f9d0f7 Status: R X-Status: N
----- Original Message -----
From: <f-cpu@egroups.com>
To: <f-cpu@egroups.com>
Sent: Sunday, January 07, 2001 12:43 PM
Subject: [f-cpu] Digest Number 240


> There are 5 messages in this issue.
>
> Topics in this digest:
>
>       1. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : "Marco Al" <marco@simplex.nl>
>       2. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       3. IT'S HERE..
>            From= : bethweinstein@yahoo.com
>       4. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Yann Guidon <whygee@f-cpu.org>
>       5. REMOVE
>            From= : "maurizio zoboli" <maurizio.zoboli@unimo.it>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 1
>    Date: Sat, 6 Jan 2001 18:49:49 +0100
>    From: "Marco Al" <marco@simplex.nl><= BR> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> From: "Yann Guidon" <whygee@f-cpu.org>
>
>
> > talk about a monodirectional synchronous parallel (byte ?)
> > bus with some control signals, a clock (dual edge ?) and it's ok = for
> > me, whatever your idea is. Anybody can implement that with a
> > few PALs and 74Fxxx, or a simple/cheap FPGA.
>
> Is LVDS usually in the standard cell libraries? If you want to have th= e
option
> of using cables its IMO the clear choice, together with source synchro= nous
> clocking of course (chips will probably still share clocks, ie be
synchronous,
> the source clock is just to deal with the delay's at high signalling speeds over
> long wires). There is AFAICS a pretty clear consensus in the industry = that
its
> is the way forward for backplanes too. And there are plenty of TTL
interface
> chips on the market, plus some FPGA support, so no worries there.
>
> I still like a shared bidirectional (B-LVDS) bus using
repeaters/bridges/routers
> for scalability. In other words the Intel way, the AMD party line swun= g me
too
> for a while... but now I dont think point to point busses use the
resources
> (pin's and system cost) most effectively. The only way to proove/dispr= oove
that
> IMO is to model both alternatives, but Im both too lazy and I dont hav= e
the
> necessary knowledge (AFAICS I would need to know feasibly physical
bandwith per
> pin in point to point and bus setups, and have a good traffic breakdow= n
for
> multiprocessor setups) .With a lot of broadcast traffic I just dont th= ink
the
> effective bandwith per pin of a point to point bus compares favourably= ,
let
> alone the extra costs and latency of the routing chips for small SMP setups.
>
> Marco
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 2
>    Date: Sun, 07 Jan 2001 00:35:43 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> Hi,
>
> Yann Guidon a =E9crit :
> >
> > hi,
> >
> > Nicolas Boulay wrote:
> > > hi,
> > >
> > > Yann Guidon a =E9crit :
> > > > > The network will made around
> > > > > gigabit ethernet link (the electrical part) becaus= e it's well
known (and
> > > > > free ? ). With 8 ethernet links, we can reach the = true gigabytes.
This
> > > > > made around 8*2*2*2 (2 pairs with 2 ways and 2 tim= e 500Mhz) pins
for a
> > > > > multidirectionnal link, very few in fact !
> > > > you forget several things... no chip can do 8xGb links.= you forget
the ground
> > > > connexions in the backplane. This backplane is going to= be extremely
expensive,
> > > > and i doubt that a "f-cpu hacker" can afford = a 30-layer PCB made
with Teflon.
> > > > the idea of the ethernet is simply science fiction.
> > >
> > > Oups, i omit to say for reduice the cost that i would like t= o try to
> > > have only one chip and avoid many differents chips. So the 8= links wil
l
> > > be "inside" the fcpu chip. This is the main system= bus.
> >
> > hum, hum... just a reminder : the SiO2 process is not much the sa= me
> > for a CPU and a tranceiver. you CAN't put it on the same die... > >
>
> I don't think that you know about what you speak ! New silicon process=
> are silicium on insulator, soon used by IBM for there udge processor f= or
> mainfrain (a little beast with 35 ppc on the same die). And now, for t= he
> next powerG3. Next, the SiGe are new process used to have
> hyperfrequencies, or mixed analogue and digital part. But then, it cou= ld
> be used for very quick digital circuit.
>
> And, for information, gigabit ethernet need 500 Mhz. So, "usual p= rocess"
> are must enought to make a tranceiver.
>
> > > The 8 ethernet link could be say has 2 one-way gigabyte link= s. So, if
> > > you use a ring, you need 2 of this links (one by ring). So y= ou will
only
> > > need a 1 layer PCB !
> > beep. wrong. gigabit ethernet, or any ethernet, requires a very s= pecial
> > medium to propagate. the shield, the impedence adaptation, the di= ameter,
> > the propagation, etc. are more or less taught in the IUT or ingen= ieur
school.
>
> A=EFe ! You just have to respect electrical rules of the gigabit ether= net
> (L and C).
>
> > they're a lot of formula etc, so you can't simply draw a line and= say
"ok".
> > it can't be so. otherwise, network cables would be much cheaper.<= BR> > > have you heard about "Cat. 5" cables ? did you wonder w= hy it was more
>
> You have never learn that this kind of cable could be around 50 meter<= BR> > long ! Here 1 or 2 meters is much enought !
>
> > expensive than other cables ? Plus, you'll need very special
connectors...
> > the usual cheap connectors are not adapted at all.
> >
> > > > > compare to the normal usual
> > > > > parrallel bus (for a link at 133 Mhz compare to th= e >500 Mhz for
the
> > > > > giga ethernet link and without to many routing pro= blem with long
wires).
> > > > i compare what can be compared.
> > > > the current idea is simply not realistic.
> > > Yes, the idea that you have understood, not mine !
> >
> > talk about a monodirectional synchronous parallel (byte ?)
> > bus with some control signals, a clock (dual edge ?) and it's ok = for
> > me, whatever your idea is. Anybody can implement that with a
>
> Fast clock one large network, you have to deal with clock skew. Most o= f
> the time, each founder (ST microelectronics, TSMC, infineon,...) have = a
> macro cell to do gigaethernet and do all the hard things (serial,
> deserials).
>
> > few PALs and 74Fxxx, or a simple/cheap FPGA.
> >
>
> Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify 5V a= nd
> some nF of charge. I don't want to repeat it each time.
> 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compare to=
> usual system.
> 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around 300 M= hz
> with DDR or more with QDR. With LVDS, you can reach around 600 Mhz by<= BR> > pin. BUT you can't really add a connector between 2 pins at that speed= .
>
> My choice is to have a quick link (performance are our goal, isn't it<= BR> > ?). Then you just had to provide a bridge between the quick link and a=
> SRAM like bus. I think that could be easy : Just a link like for the > fcpu and a little glue for the interface.
>
> > now you're asynchronous, you have to deal with PLL and clock
> > recovery, hyperfrequencies, signal integrity, skew, etc...
> > that a lot of troubles for almost nothing.
> >
>
> Not at all ! because you deal with macrocell and all the suft are soon=
> made.
>
> > you want speed ? put the wires in parallel, don't serialize the b= its...
> >
>
> Yes, but the limit are the number of pin and the prices ! And then you=
> alwas have the speed of the clock with LVDS, you always have the
> electrical and speed problem.
>
> > > > i want a draft, numbers, several case studies, feasibil= ity studies,
> > > > the reference of the used parts, the protocol, the VHDL= ...
> > >
> > > Yeah, yeah, the bear and the bear's skin ;p
> >
> > i'm just putting the pressure on your shoulders.
> > i'd like to see where your seriousness ends...
> >
> > > > > Each cpu will have a full 128 bits wide bus for DD= R-SDRAM and
"some"
> > > > > gigabit ethernet links for system communication. T= hen you can
connect
> > > > > the cpu or a IO sub-system for ide/scsi bus, usb, = rs232 ...
> > > >
> > > > i don't care about this side. you're simply going into = a lot of
troubles.
> > >
> > > In fact, it should.
> > "should" what ?
> >
> > > In usual core, you have simple bus and it's easy to
> > > put rom or eeprom to boot. But here, you need something more= special
to boot.
> > and who will build that ? do you have the spare parts somewhere ?=
> >
>
> "spare part", i don't understand. One day, you say you want = performance,
> the other days somthing so slow to be compatible with TTL. I don't
> understand you...
>
> > > > one way to realize this is by searching the parts on th= e catalogs or
databases.
> > > > one connector is going to cost as much as the f-cpu chi= p. One
backplane
> > > > will cost 100KF to prototype. it's not a "hacker's= architecture".
> > >
> > > Ben, non...
> > >
> > ok, now we're going to agree on something...
> >
> > start with something simple and that works with easy-to-find part= s.
> >
> > > > > The "delicat" part is : what taken as ne= twork ? Everybody knows
that i
> > > > > prefer a double ring. Double to make a failure rev= overy (to plug
and
> > > > > replug one card without shutting down the system).= And its easy to
> > > > > expand wihtout having any routing problems. Routin= g is a problem
for
> > > > > latency and complexty of the nod. But this needs m= uch more
explication.
> > > > routing is not a problem. the routing algorithms are kn= own for a
long time
> > > > and there's already a large variety of choices.
> > >
> > > Have you a link for a preditive routing algorithme ? I think= that my
> > > collegue which make a thesis about real time network will be= very
> > > interrested to know that exist.
> >
> > the routing stuff is taught during the DEUG at Paris 8 university= .
> > ask Amal Stri from the transversal department.
> >
> > When at Boston, in a (expensive) library, i found (but didn't buy= )
> > a VERY cool about the T3E and similar architectures. The routing<= BR> > > algos are rather simple and very efficient.
> >
>
> I seriously doubt about the complexity and the scalability...
>
> > > > > Everybody should stay calm ! We need everybody. > > > > yep. F-CPU didn't appear in one day.
> > > >
> > > > anyway, the debate has shifted very far from the initia= l
> > > > requirement, and it's rather off-topic. What we need is= a simple
> > > > parallel interface to connect the F-CPU to the G-chip a= nd other
> > > > G-chips. Since they're on the same PCB, we don't need h= otswap.
> > >
> > > If we made a simple core (like ARM), we don't need g-ship an= d all that
crap.
> > not true. ARM chips require I/O chips. Unless you buy the synthes= ised
core,
> > and implement it in the middle of a sea-of-gates ASIC with your p= refered
I/O.
> >
>
> One more times, you don't unsderstand ! i propose like leon, just to > develope the fc0 (the core) and let other gays to use it.
>
> > ARM, just like any chip, requires a memory controller and I/O. > > look at the Crystal Semiconductors catalog... they have all the p= arts
> > necessary to make a PDA or laptop PC.
> >
> > > If we made a processor ("a system") we should cons= ider to have
> > > fault tolerance capabilities. And hot swap is the basis ! > > not necessarily. fault detection and bypass are a SW matter,
> > with the help of some HW (ECC/SEC). but the rest is purely an ele= ctrical
> > problem.
> >
>
> Not really, i don't speak about fault detection but failure tolerant (= a
> single dead card don't stop the all system, you just have to change it= ).
>
> > some designs that you should investigate (using several different= books,
> > saying different stuffs) : T3D/E (it's a 3D torus with ALPHAs at = the
nodes),
> > CM1 (12-cube with extremely simple routing), CM5 (fault tolerance= , "big
tree"
> > network, message passing communication etc.), SGI/SUN/HP scalable=
computing nodes
> > (i found the Convex (circa 1995) very interesting, but Convex is = now
owned by HP).
> >
>
> Just for information : how much for a single chip ? And how much heat<= BR> > for a chip ? You try to give some piece of your knowledge but you don'= t
> understand the "simple coma" from SUN for their last system = (from an URL
> given on the list), so ?
>
> > i know, it's a matter of culture...
> >
>
> I just see it's like jam, ...
>
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 3
>    Date: Sat, 06 Jan 2001 22:31:11 -0500
>    From: bethweinstein@yahoo.com
> Subject: IT'S HERE..
>
> Expand your business with
>     Email Marketing!
>
> Market your product or service
>      to MILLIONS!
>
> Don't waste another minute...
>
> Click Reply with your name,
> telephone number and the
> product or service you wish
> to market. We will be in
> touch with you shortly!
>
>
>
>
>
> Removal Instructions
> ****************************
> To be removed from this list
> please reply with "REMOVE"
> in the subject.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Expand your business with
>     Email Marketing!
>
> Market your product or service
>      to MILLIONS!
>
> Don't waste another minute...
>
> Click Reply with your name,
>
>
>
>
>
>
>
>
>
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 4
>    Date: Sun, 07 Jan 2001 04:32:50 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> hi !
>
> Marco Al wrote:
> > From: "Yann Guidon" <whygee@f-cpu.org>
> > > talk about a monodirectional synchronous parallel (byte ?) > > > bus with some control signals, a clock (dual edge ?) and it'= s ok for
> > > me, whatever your idea is. Anybody can implement that with a=
> > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> >
> > Is LVDS usually in the standard cell libraries? If you want to ha= ve the
option
> > of using cables its IMO the clear choice, together with source synchronous
> > clocking of course (chips will probably still share clocks, ie be=
synchronous,
> > the source clock is just to deal with the delay's at high signall= ing
speeds over
> > long wires). There is AFAICS a pretty clear consensus in the indu= stry
that its
> > is the way forward for backplanes too. And there are plenty of TT= L
interface
> > chips on the market, plus some FPGA support, so no worries there.=
>
> yup. Even though it's not the "hottest" stuff around (compar= ed to
> optical fibers, I2C and mental waves), it works, it's very well
understood,
> it's widely spread... and it's not over expensive (accessibility of th= e
> technology vs price vs performance vs...)
>
> > I still like a shared bidirectional (B-LVDS) bus using
repeaters/bridges/routers
> > for scalability. In other words the Intel way, the AMD party line= swung
me too
> > for a while...
> after a few months playing with the idea of two unidirectional buses ("full-duplex",
> even though the bandwidth is halved) i feel that it is not a bad idea = at
all.
> No arbitration, few synchronisation, very low complexity... i like it = :-)
>
> > but now I dont think point to point busses use the resources
> > (pin's and system cost) most effectively.
> it depends on your criteria. low pin count ? price ? speed ? bandwidth=
?...
> and also on your needs and "budget".
>
> > The only way to proove/disproove that
> > IMO is to model both alternatives, but Im both too lazy and I don= t have
the
> > necessary knowledge (AFAICS I would need to know feasibly physica= l
bandwith per
> > pin in point to point and bus setups, and have a good traffic bre= akdown
for
> > multiprocessor setups) .With a lot of broadcast traffic I just do= nt
think the
> > effective bandwith per pin of a point to point bus compares favou= rably,
let
> > alone the extra costs and latency of the routing chips for small = SMP
setups.
>
> well, there's the architecture side here...
>
> if you target "small SMP" only, maybe you can do it with a s= hared bus,
> but don't expect wonders above 4 CPU. If you're doing CPU-only tasks, = it's
> ok, but when you start to move things around, it's the real mess.
> Intel sticks to this because the architecture is more or less stuck. > they want cheap systems and make big profits, but still compete (with<= BR> > some pain) in the SPEC contests.
>
> I am trying to find the "least common denominator" for a F-C= PU system
> that can range from 1 CPU to any arbitrary number of CPUs (just like > the register width : not bound to anything). let's take a few cases, > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" should al= so scale
> to much more CPUs : the widest systems today (see the monters at the L= ANL)
> can scale to more than 10K CPU, so let's round up to 65536.
>
> now let's compare the alternatives...
>
> Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's disastr= ous
> with more CPU.
>
> buses are known, used and they work, but some people here want a
"multimaster"
> bus. This means that the bandwidth is drawn by several points and the = bus
> is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU, equa= l to
> the available bandwidth provided by the bus and divided by N CPU).
>
> that's what i try to avoid.
>
> Clearly, this B=3DL/N is a thing that i try to avoid for other things = as
well,
> and it's my "hammer" argument when i try to promote point to= point links.
> We spare the (distributed) control logic (all the nasty deadlock stuff= s
etc)
> and it's very simple to implement. the PCB is simpler, too.
>
> If you connect more than 2 CPU on the same bus, they compete for the ressource
> and the bottleneck gets even narrow.
>
> On the pin count vs bandwidth argument, it's similar. Of course, we ca= n
find
> a lot of counter-examples and special cases, but the example of the broadcast
> is not the best one. Most of the requests are from one node to a singl= e
other
> and here, the efficiency of a bus drops dramatically ! for a N-CPU sys= tem,
> the efficiency is of 2 used bus interfaces for N bus interfaces (you c= an
> replace "bus interface" with "pin"), 2/N is simila= r to the 1/N scheme
> (if we speak about the "big O" or complexity). This means th= at :
> the more CPU, the least efficient ! you'll see that the best way to av= oid
> this is by having as few CPU by link as possible, and the minimum is 2= .
> that's "point to point"...
>
>
> Now, another stuff. Nico usually wants a ring. It's "simple to ro= ute",
> it's fun and doesn't need much "efforts". But there is still= the same
> problem as before : the more CPU, the less bandwidth when one CPU want= s
> to talk to another. 1/N (or 2 pins / N CPU if you want the "real<= BR> efficiency").
> The solution is rather easy : you have to expand that to the other 2 dimensions,
> hence the "CRAY T3D" and the extension, T3E. Routing is stil= l the same but
the
> address is split into 3 fields that are interpreted as an independent = ring
address.
>
> here, you don't have 1 ring but x*y*z rings. It means that there is > no bandwidth problem at all, because each CPU communicates with its 6<= BR> neighbours.
> It works very well, it can be tweaked to become "fault tolerant&q= uot; (through
dynamic
> node addresses) and scales perfectly (almost linearly with the CPU
number).
>
> So if you want the simplest system, you have 1 CPU with no ring,
> and when you scale up, add a few links when needed and use like "= lego
bricks"
> in a cubic connexion.
>
> I think that the G-chip was an easy way to make the topology
reconfigurable
> by the user/implementor. If we provide the brick, the user will make a= lot
> of stuffs, but if we restrict the choices, the scalability and the
flexibility
> will suffer.
>
>
> > Marco
>
> Nicolas Boulay wrote:
> >
> > Hi,
> >
> > Yann Guidon a =E9crit :
> > >
> > > hi,
> > >
> > > Nicolas Boulay wrote:
> > > > hi,
> > > >
> > > > Oups, i omit to say for reduice the cost that i would l= ike to try to
> > > > have only one chip and avoid many differents chips. So = the 8 links
will
> > > > be "inside" the fcpu chip. This is the main s= ystem bus.
> > >
> > > hum, hum... just a reminder : the SiO2 process is not much t= he same
> > > for a CPU and a tranceiver. you CAN't put it on the same die= ...
> >
> > I don't think that you know about what you speak ! New silicon pr= ocess
> > are silicium on insulator, soon used by IBM for there udge proces= sor for
> > mainfrain (a little beast with 35 ppc on the same die).
> duh. and how will you ask IBM to make your chip ?
> it's not something that everybody can do. it's not free, it's expensiv= e
> and it's not connectable to anything...
>
> > And now, for the next powerG3. Next, the SiGe are new process use= d to
have
> > hyperfrequencies, or mixed analogue and digital part. But then, i= t could
> > be used for very quick digital circuit.
> It is. but how many people would use such a chip ? what can they conne= ct
it to ?
> how will you "solve" the RF issues ? Do you know how difficu= lt it is to
route
> a 50 MHz signal ? So who will buy you the SW needed to design a RF PCB= ?
>
> > And, for information, gigabit ethernet need 500 Mhz. So, "us= ual process"
> > are must enought to make a tranceiver.
> Maybe you should stop to use the term "ethernet". If it's a = simple
> "serial link", you're just making a firewire clone...
>
> > > > The 8 ethernet link could be say has 2 one-way gigabyte= links. So,
if
> > > > you use a ring, you need 2 of this links (one by ring).= So you will
only
> > > > need a 1 layer PCB !
> > > beep. wrong. gigabit ethernet, or any ethernet, requires a v= ery
special
> > > medium to propagate. the shield, the impedence adaptation, t= he
diameter,
> > > the propagation, etc. are more or less taught in the IUT or = ingenieur
school.
> > A=EFe ! You just have to respect electrical rules of the gigabit = ethernet
> > (L and C).
> that's a pretty quick simplification. even though at your level it fit= s,
> when you make the PCB it takes another dimension ...
>
> > > they're a lot of formula etc, so you can't simply draw a lin= e and say
"ok".
> > > it can't be so. otherwise, network cables would be much chea= per.
> > > have you heard about "Cat. 5" cables ? did you won= der why it was more
> > You have never learn that this kind of cable could be around 50 m= eter
> > long ! Here 1 or 2 meters is much enought !
> and you think that it's not the same problem ????
> have you heard about Xtalk and such stuff ? you CAN't make it with a 1-layer PCB.
> you need at least 3 layers to make a decent transmission line
> (shield/insulator/signal/insulator/shield). And depending on your sign= al's
> characteristics, you have to change the dimensions of the tracks,
> so they are adapted to the thickness of the PCB and the permeability o= f
> the insulator (if it's epoxy or teflon or something else).
>
> Whether the wire is 50m or 1m, the problem is the same...
>
> > > > > i compare what can be compared.
> > > > > the current idea is simply not realistic.
> > > > Yes, the idea that you have understood, not mine !
> > > talk about a monodirectional synchronous parallel (byte ?) > > > bus with some control signals, a clock (dual edge ?) and it'= s ok for
> > > me, whatever your idea is. Anybody can implement that with a=
> > Fast clock one large network, you have to deal with clock skew. > it's an old known problem and there are some old known solutions.
> ever heard about a "clock tree" ?... if you have a good arch= itecture,
> you don't have skew troubles.
>
> > Most of the time, each founder (ST microelectronics, TSMC, infine= on,...)
> > have a macro cell to do gigaethernet and do all the hard things (= serial,
> > deserials).
> and you'll by the components ? come on...
> and please, don't talk about "Ethernet", it seems like it's<= BR> > only a serial point to point link (if i remember one of your messages)= .
>
> > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify= 5V and
> > some nF of charge. I don't want to repeat it each time.
> hey, i'm not dumb, i know that TTL is slow. thanks.
>
> but just a question : how will you debug your stuff ? will you use
> a 10GS/s logic analyser ? with a simple enough protocol, i can
> debug the interface with "off the shelf parts" that i can so= lder at will,
> the old school way, just like any "hacker".
>
> Then, when it's developped, you only have to change the electrical
> levels (that is : the pin's driving gates) and you can do LVTTL or
whatever
> high-speed connexion. it's just a matter of changing the electrical sp= ec.
> Yes i want speed, but a "hacker" needs a way to see what hap= pens without
> the need of extremely expensive devices. by clocking the chip slower > and adapting the electrical level (with the adapted buffers or
transmitters),
> you can hook anything to the F-BUS.
>
> > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compa= re to
> > usual system.
> this kind of speed is used for I/O with maybe a controller or somethin= g
> like that. When i speak about "TTL parts", it's something li= ke a 8255
> or any very slow byte-based I/O chip. just like during the old days > of the 8-bit systems...
>
> > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around = 300 Mhz
> > with DDR or more with QDR. With LVDS, you can reach around 600 Mh= z by
> > pin. BUT you can't really add a connector between 2 pins at that = speed.
> then it must be soldered. but then, this speed is not required for
> handcrafting your own I/O board on a pre-drilled PCB. do you know a mo= use
> or a keyboard or even a LCD screen that requires 600M x N pins of data=
> per second ?
>
> Scalability means scale-down and scale-up. 500Mbps is fine, but when y= ou
> don't need that much, it's an overkill. And you propose to make an ada= pter
> that will bother of the I/O, but how many custom chips will you requir= e
> to interface your connexion to any other stuffs ? Having a simple and<= BR> > one-fits-all protocol that does low and high-speed helps reduce the > number of different chips and interfaces...
>
> > My choice is to have a quick link (performance are our goal, isn'= t it
?).
> not only. In the design goals of the F-CPU, there are 3 other stuffs.<= BR> >
> > Then you just had to provide a bridge between the quick link and = a
> > SRAM like bus. I think that could be easy : Just a link like for = the
> > fcpu and a little glue for the interface.
> i'll give you the honnor of doing the first one...
>
> > > now you're asynchronous, you have to deal with PLL and clock=
> > > recovery, hyperfrequencies, signal integrity, skew, etc... > > > that a lot of troubles for almost nothing.
> > Not at all ! because you deal with macrocell and all the suft are= soon
made.
> ain't it magical ??...
> are you so confident and faithfull in the technologies ?
>
> > > you want speed ? put the wires in parallel, don't serialize = the
bits...
> > Yes, but the limit are the number of pin and the prices ! And the= n you
> > alwas have the speed of the clock with LVDS, you always have the<= BR> > > electrical and speed problem.
>
> ok, let's compare serial and parallel.
>
> you want 1Gbps links. halve it now, because the actual efficiency
> of a serial bus is not the raw peak number. With 10Base, one can't
transfer
> more than 500K bytes per second. or 520. whatever.
> So let's imagine that you can SUSTAIN 50 M bytes per second.
> caugh. caugh. ok, imagine you can reach 70M bytes in the two direction= s.
> 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M bytes/s<= BR> > (or 8 Gbps).
>
> Ok, i know, you want to reach 8Bgps by using 8 links.
> but how are they connected ? if you want to make a ring, you'll
> dissipate your bandwidth, and if you want to make neighbour to neighbo= ur
> connexions, you'll require 64 pins (or better 100, counting grounds/VC= C)
> per neighbour. retour case d=E9part...
>
>
> > > > In usual core, you have simple bus and it's easy to
> > > > put rom or eeprom to boot. But here, you need something= more special
to boot.
> > > and who will build that ? do you have the spare parts somewh= ere ?
> > "spare part", i don't understand.
> i mean : go buy some such chips at St Quentin Radio or Radio Shacks...=
> a chip that is available for sale in public catalogs.
>
> > One day, you say you want performance,
> > the other days somthing so slow to be compatible with TTL. I don'= t
> > understand you...
>
> i want something that can do both, but of course not at the same time.=
> you can't access a mouse or handcrafted I/O board (anything that you > see in Elektor or Electronique Pratique) with the same means as anothe= r
CPU.
> But the protocol and the layout must remain the same, as to ease the P= CB
design
> and the easy replacement of the chips.
>
> > > > Have you a link for a preditive routing algorithme ? I = think that my
> > > > collegue which make a thesis about real time network wi= ll be very
> > > > interrested to know that exist.
> > >
> > > the routing stuff is taught during the DEUG at Paris 8 unive= rsity.
> > > ask Amal Stri from the transversal department.
> > >
> > > When at Boston, in a (expensive) library, i found (but didn'= t buy)
> > > a VERY cool about the T3E and similar architectures. The rou= ting
> > > algos are rather simple and very efficient.
> >
> > I seriously doubt about the complexity and the scalability...
>
> remember, it's a torus. only, it's 3D :-)
> for the other details, it's up to you to go to the library,
> read as many book as you can and ask the teachers and the
> educated people from comp.arch and comp.sys.super...
> i won't do it for you, you wouldn't believe what i say :-P
>
> > > > If we made a simple core (like ARM), we don't need g-sh= ip and all
that crap.
> > > not true. ARM chips require I/O chips. Unless you buy the sy= nthesised
core,
> > > and implement it in the middle of a sea-of-gates ASIC with y= our
prefered I/O.
> > One more times, you don't unsderstand ! i propose like leon, just= to
> > develope the fc0 (the core) and let other gays to use it.
> so let's drop this silly network/bus whatever debate for a while... >
> > > > If we made a processor ("a system") we should= consider to have
> > > > fault tolerance capabilities. And hot swap is the basis= !
> > > not necessarily. fault detection and bypass are a SW matter,=
> > > with the help of some HW (ECC/SEC). but the rest is purely a= n
electrical
> > > problem.
> > >
> > Not really, i don't speak about fault detection but failure toler= ant (a
> > single dead card don't stop the all system, you just have to chan= ge it).
>
> it's the SAME thing. You can't be "fault tolerant" if you ca= n't detect
> the fault and take the necessary SW measures. It's obvious...
> i'm just trying to avoid "buzzwords" that taint the debate w= ith black
magic ;-)
>
>
> > > some designs that you should investigate (using several diff= erent
books,
> > > saying different stuffs) : T3D/E (it's a 3D torus with ALPHA= s at the
nodes),
> > > CM1 (12-cube with extremely simple routing), CM5 (fault tole= rance,
"big tree"
> > > network, message passing communication etc.), SGI/SUN/HP sca= lable
computing nodes
> > > (i found the Convex (circa 1995) very interesting, but Conve= x is now
owned by HP).
> >
> > Just for information : how much for a single chip ? And how much = heat
> > for a chip ? You try to give some piece of your knowledge but you= don't
> > understand the "simple coma" from SUN for their last sy= stem (from an URL
> > given on the list), so ?
>
> i've tried, but it's not that clear for me, what's so special ?
> when there's a page fault, i trap. Just make the correct fault handler= ,
> and you implement any memory protection and sharing you want.
> It leaves the door open to ANY memory system implementation.
> what else do you want ? i'm still waiting for a clear and HW propositi= on.
>
> > > i know, it's a matter of culture...
> > I just see it's like jam, ...
> J'en ai une meilleure, mais je ne l'ai pas invent=E9e non plus,
> elle est de Jacques Brel : "La culture, c'est la m=E9moire des > cons qui n'ont rien invent=E9". Il avait vraiment des id=E9es
> noires avant de mourir... La culture, il faut se la faire
> tous les jours et ne pas trop camper sur ses positions...
> avec le f-cpu, on a ce qu'il faut comme action :-)
>
> bonne nuit,
>
> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 5
>    Date: Sun, 07 Jan 2001 11:18:39 +0100 (CET)
>    From: "maurizio zoboli" <maurizio.zobol= i@unimo.it>
> Subject: REMOVE
>
> On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:
>
> >Expand your business with
> >    Email Marketing!
> >
> >Market your product or service
> >     to MILLIONS!
> >
> >Don't waste another minute...
> >
> >Click Reply with your name,
> >telephone number and the
> >product or service you wish
> >to market. We will be in
> >touch with you shortly!
> >
> >
> >
> >
> >
> >Removal Instructions
> >****************************
> >To be removed from this list
> >please reply with "REMOVE"
> >in the subject.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Expand your business with
> >    Email Marketing!
> >
> >Market your product or service
> >     to MILLIONS!
> >
> >Don't waste another minute...
> >
> >Click Reply with your name,
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> Prof. Maurizio Zoboli
> Dipartimento di Scienze dell'Ingegneria
> Universita' di Modena e Reggio Emilia
> via Vignolese 905
> I-41100 Modena, Italy
> Tel.: +39 059 2056163
> Fax: +39 059 2056129
> e-mail: maurizio.zoboli@unimo.it
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
>
eGroups Sponsor=
3D""
From Yann Guidon Mon Jan 8 02:53:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03363 for ; Mon, 8 Jan 2001 03:59:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 03:59:54 +0100 (MET) Received: (qmail 18046 invoked by uid 0); 8 Jan 2001 02:05:50 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx09) with SMTP; 8 Jan 2001 02:05:50 -0000 X-eGroups-Return: sentto-1101623-1882-978918943-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 08 Jan 2001 01:56:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 01:55:41 -0000 Received: (qmail 36094 invoked from network); 8 Jan 2001 01:48:17 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Jan 2001 01:48:17 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 8 Jan 2001 01:48:16 -0000 Received: from f-cpu.org (nas3-34.ras.club-internet.fr [195.36.203.34]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA25408 for ; Mon, 8 Jan 2001 02:48:10 +0100 (MET) Message-ID: <3A591DB4.DB7F8076@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <87vgs1wndr.fsf@c0re.bewaff.net> <874rzgr8zk.fsf@c0re.bewaff.net> <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 02:53:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d4c08075bf3c8e64b10a186e5e998f81 Status: R X-Status: N hello,

Nicolas Boulay wrote:
> Yann Guidon a =E9crit :
> > hi !
> > Marco Al wrote:
<snip>
> > if you target "small SMP" only, maybe you can do it wit= h a shared bus,
> > but don't expect wonders above 4 CPU. If you're doing CPU-only ta= sks, it's
> > ok, but when you start to move things around, it's the real mess.=
> > Intel sticks to this because the architecture is more or less stu= ck.
> > they want cheap systems and make big profits, but still compete (= with
> > some pain) in the SPEC contests.
> You always forget one big thing. Here we speak about private memory an= d
> communication network to speed up memory interface.
in such a system, a good bandwidth ratio between external and private buses=
is critical. Even a message is a heavy stuff. do you imagine that they
only send messages for the new year's eve invitation ? :-P

> So in the intel
> architecture, 4 is a maximum because all the 4 cpu read the memory
> thought the same shared bus. In our system, only message go thought th= e
> network. In the best case, only I/O instruction go thought the network=
> and very few message from the processes.
hey, i thought that we shouldn't decide for the user ?

remember that you cite I/O. Ok, you're used to your slow PC and your little=
SPARC. but when Synopsys starts to swap, don't you wish you had more I/O ?.= ..
I/O shouldn't be the 5th wheel of the car. if you do "multimedia"= (sound and video),
you understand that it is critical.

> > Clearly, this B=3DL/N is a thing that i try to avoid for other th= ings as well,
> > and it's my "hammer" argument when i try to promote poi= nt to point links.
> > We spare the (distributed) control logic (all the nasty deadlock = stuffs etc)
> There are always possible traffic Jam. How do you manage when 2 nodes<= BR> > try to speak to the same nod ? You have to manage something to avoid > losing informations.
losing information ? when ?
there is no information loss possible in the protocol i try to setup.
when there is a contention, there is a delay but that's all.

> > and it's very simple to implement. the PCB is simpler, too.
> >
> > If you connect more than 2 CPU on the same bus, they compete for = the ressource
> > and the bottleneck gets even narrow.
>
> Yes, but less drastically as intel SMP.
>
hum, what's the difference ?...

> > On the pin count vs bandwidth argument, it's similar. Of course, = we can find
> > a lot of counter-examples and special cases, but the example of t= he broadcast
> > is not the best one. Most of the requests are from one node to a = single other
>
> In fact, not. It depend how much process communicate between them. And=
> sometimes the only [simple] way to find a "moving" ressource= s is to send
> a braodcast.

And what if no boradcast was possible ?
the solution is to interrogate a list of the ressources, located in
a public memory, just like you explained in one of your lesson,
where the 4 shared memory schemes are explained.

> > Now, another stuff. Nico usually wants a ring. It's "simple = to route",
> > it's fun and doesn't need much "efforts". But there is = still the same
> > problem as before : the more CPU, the less bandwidth when one CPU= wants
> > to talk to another. 1/N (or 2 pins / N CPU if you want the "= real efficiency").
> > The solution is rather easy : you have to expand that to the othe= r 2 dimensions,
> > hence the "CRAY T3D" and the extension, T3E. Routing is= still the same but the
> > address is split into 3 fields that are interpreted as an indepen= dent ring address.
>
> In the flight back to France, we have spoken about ring of ring.(and > called the architecture the lord of the ring ;p).
know your history ;-) look at the KSR-1 and successors (that never really worked, btw). hum, was it Kendal Square Research or another similar
"small supercomputing" company ?

> A ring is composed
> around 8 to 16 card (cpu+ram or IO). A card could be used to communica= te
> with other ring. Maybe it's possible to grow in hierachy without to mu= ch
> trouble.

in theory, yes. In practice, it's not used. it's been done and never took o= ff.

> > here, you don't have 1 ring but x*y*z rings. It means that there = is
> > no bandwidth problem at all, because each CPU communicates with i= ts 6 neighbours.
> > It works very well, it can be tweaked to become "fault toler= ant" (through dynamic
> > node addresses) and scales perfectly (almost linearly with the CP= U number).
> >
> So !
>
"so what" ?

> > So if you want the simplest system, you have 1 CPU with no ring,<= BR> > > and when you scale up, add a few links when needed and use like &= quot;lego bricks"
> > in a cubic connexion.
> Cubic ~=3D  ring ????

            __A_____= C_____E______G______I__
1 ring :   (__B_____D_____F______H______J__)

(notice the pairs of nodes : one pair is added to extend the ring)

a 2D ring :
    A   B   C   D   = E ....

1   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
    ||  ||  ||  ||  ||
2   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
    ||  ||  ||  ||  ||
3   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
    ||  ||  ||  ||  ||
4   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
    ||  ||  ||  ||  ||
5   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
    ||  ||  ||  ||  ||
...

one "8" is a node that establish the connexion between
a vertical ring and a horizontal ring. So a "node" comprises
4 CPU and 4 bidirectional links.

3D : extend to 6 CPU and 6 links per node.
Here, the node is a "cube" with one connexion on every facet.
that's why i used the term of "lego brick" : when you want to add=
a CPU, you add a cube. when you want to replace or add cubes,
you deal with "boxes".

In practice, the physical implementation is not so simple
(we have to deal with 2D PCBs and connectors) but the routing
is the same as with your everyday "ring" network, except that
the address is split into 3 fields that are routed almost
independently. when you see a match on your X and Y values but
a wrong Z, you simply send to the Z link. Whether it's +Z or -Z
depends on the substraction of the current address and the desired
address : send to +Z link if the result is negative and vice versa.

One CPU is dead ? break the links (invalide the link in the neighbours)
and ignore the corresponding routing field in the neighbours.
This way, no message will go through the dead node.
Want to replace a CPU ? rename the nodes : change the address of
every working node so the "good" spare node becomes visible in th= e machine.
Usually, in a 1000 CPU system, around 30 or 50 CPUs are left for the
reserve. they are remapped when a CPU fails. otherwise, they serve
as "spies" in the network and they help analyse the traffic.

this is not verbatim how the T3E works, but there's no big difference AFAIK= .

> > > Marco
> > Nicolas Boulay wrote:
> > > Hi,
> > > Yann Guidon a =E9crit :
> > > > hi,
> > > > Nicolas Boulay wrote:
> > > > > hi,
> > > I don't think that you know about what you speak !
hey ! i read Electronique Internationale Hebdo every week :-)
i know more or less who opens what plant and where, for what technology
and what price.

> > > New silicon process
> > > are silicium on insulator, soon used by IBM for there udge p= rocessor for
> > > mainfrain (a little beast with 35 ppc on the same die).
> > duh. and how will you ask IBM to make your chip ?
> > it's not something that everybody can do. it's not free, it's exp= ensive
> And you think that actual 0.18 =B5m are free ?
listen, boy, "they" made the first ALPHA chip in 0.75u technology= , back around 1992.
if we can _reach_ that, you'll be able to dream like you want.
we're still rookies, we have not much experience and we dream a lot.

> In 2 years, SOI will be
> used in every silicon process, because it reduice the power consumptio= n
> and doesn't cost so much (it's just a little traitement on wafer).
it's a matter of accessing the technology, not a matter of what technology<= BR> is better.

> > and it's not connectable to anything...
> ??? I think you miss something... The only electrical rules to respect=
> is the higher voltage in input, most of the time lower than 3.3 V, to<= BR> > avoid destroying transistor, that's all.

by that, i meant : where do you plug it ? you have to design everything !
> > > And now, for the next powerG3. Next, the SiGe are new proces= s used to have
> > > hyperfrequencies, or mixed analogue and digital part. But th= en, it could
> > > be used for very quick digital circuit.
> > It is. but how many people would use such a chip ? what can they = connect it to ?
> > how will you "solve" the RF issues ? Do you know how di= fficult it is to route
> > a 50 MHz signal ? So who will buy you the SW needed to design a R= F PCB ?
> I think that Cadence has offer something. (any news ?)
only high-level RTL design tools, no PCB design yet.

> You want performance and you think that 50 Mhz signal are to much. How= do you
> want to deal with 133 Mhz DDR-SDRAM ?
i didn't say that 50 MHZ is to much. I say that it causes already a lot of<= BR> troubles that rookies like us can't solve with a simple "let's do this= " workaround.
when i started electronics, 27MHz was rather difficult, and the 144MHz was = almost
black magic. Now you come and you want 500MHz. i say : ok, but let's make s= omething
"work" first, so we can see what to not do with higher frequencie= s.
If we ever get a 50MHz, or even 10MHz chip working correctly, i'll be happy= .
didn't they tell you at ASIME that almost none of their chips works above 1= 00MHz ?

> > > And, for information, gigabit ethernet need 500 Mhz. So, &qu= ot;usual process"
> > > are must enought to make a tranceiver.
> > Maybe you should stop to use the term "ethernet". If it= 's a simple
> But in electrical rules, gigaethernet is only a serial point to point<= BR> > link, not much more (just add the mac adress and a crc).
it implies too much. Just reuse/paraphrase what you just wrote :
"a serial point to point link" and that's ok for me.

> > "serial link", you're just making a firewire clone... > A=EFe ! Firewire isn't a point to point serial link !!!! It's a comple= te
> network system which include the 3rd layer of the OSI system. It inclu= de
> the routing protocole and all that stuff (the same thing than IP )! remember what you wrote : "But in electrical rules, "....
I don't care about the OSI or whatever. I care about the efficiency
of the stuff.

> > > You have never learn that this kind of cable could be around= 50 meter
> > > long ! Here 1 or 2 meters is much enought !
> > and you think that it's not the same problem ????
> > have you heard about Xtalk and such stuff ? you CAN't make it wit= h a 1-layer PCB.
> That's why ethernet cable are made by pair (like lvds, d is for
> differential). And with some ground it could pass.
i like the last phrase :-)

now i think that you should look at the "Autobahn" bus, added to = some
VME backplanes designed by whatever company (Force Computers ?).
They added a high-speed serial link to VME, 5 years ago IIRC.
You could learn a lot about their designs and their errors.

> > you need at least 3 layers to make a decent transmission line
> so 4 layers, like usual mother board.
hum....
i learnt something during the last year : we shouldn't be too optimistic with PCB layers. you need 3 layers for _transmitting_ the signal, but
depending on your connectors and backplane, you can easily reach
10 or even 20 layers very quickly ! if your connectors are too dense,
you'll have to route some tracks with additional layers.

> > (shield/insulator/signal/insulator/shield). And depending on your= signal's
> > characteristics, you have to change the dimensions of the tracks,=
> > so they are adapted to the thickness of the PCB and the permeabil= ity of
> > the insulator (if it's epoxy or teflon or something else).
> >
> > Whether the wire is 50m or 1m, the problem is the same...
>
> Not really. The Characteristique are made to say that your cable could=
> be 50 meter long, so the signal could be mixed with a certain level of=
> noise. If you need shortest cable, you could adjust the quality of the=
> cable.
it's not a good reason to be laxist...
you still have to respect the electrical rules
and use severe constraints on the PCB.

> > > Fast clock one large network, you have to deal with clock sk= ew.
> > it's an old known problem and there are some old known solutions.=
> > ever heard about a "clock tree" ?... if you have a good= architecture,
> > you don't have skew troubles.
>
> Don't forget that i'm microelectronic engineer and clock tree are a > basis... Which is not so simple at all.
>
but at least they are known and used for what they're worth.

> > > Most of the time, each founder (ST microelectronics, TSMC, i= nfineon,...)
> > > have a macro cell to do gigaethernet and do all the hard thi= ngs (serial,
> > > deserials).
> > and you'll by the components ? come on...
>
> The chip maker will by it.
>
and then let the end user pay the bill.

> > and please, don't talk about "Ethernet", it seems like = it's
> > only a serial point to point link (if i remember one of your mess= ages).
> >
>
> But, it is !
>
so stop about speaking about Ethernel, but try "fast serial link"= ...

> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL si= gnify 5V and
> > > some nF of charge. I don't want to repeat it each time.
> > hey, i'm not dumb, i know that TTL is slow. thanks.
> >
> > but just a question : how will you debug your stuff ? will you us= e
> > a 10GS/s logic analyser ? with a simple enough protocol, i can > > debug the interface with "off the shelf parts" that i c= an solder at will,
> > the old school way, just like any "hacker".
> >
>
> Like everybody, you will use a standart JTAG port.
>
LMFAO :-)

when i speak about "debug", i speak about seeking errors
in the dynamic mode, at high speed, i don't speak about seeking
static errors. dynamic errors are harder to track and JTAG is useless
here (it's not a terabit link ;-P)

> > Then, when it's developped, you only have to change the electrica= l
> > levels (that is : the pin's driving gates) and you can do LVTTL o= r whatever
> > high-speed connexion. it's just a matter of changing the electric= al spec.
> > Yes i want speed, but a "hacker" needs a way to see wha= t happens without
> > the need of extremely expensive devices. by clocking the chip slo= wer
> > and adapting the electrical level (with the adapted buffers or tr= ansmitters),
> > you can hook anything to the F-BUS.
>
> If you use low voltage it's because you can't manage with higher one. = So
> it could be impossible to change it !
>
hey, some chips are here for that ...
there are also mixed-voltage FPGAs that can do both the electrical
adaptation and the protocol management.

> > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow = compare to
> > > usual system.
> > this kind of speed is used for I/O with maybe a controller or som= ething
> > like that. When i speak about "TTL parts", it's somethi= ng like a 8255
> > or any very slow byte-based I/O chip. just like during the old da= ys
> > of the 8-bit systems...
>
> And you want performance by slow down the network only to put good old=
> I/o chip....
>
here you mix everything. i want flexibility : being able to go at full stea= m
with specific electrical interfaces, and allow anybody to plug a custom
board without pain. What's the use of a ultra-high-speed bus if you can't connect anything on it ?
let's compare ISA and PCI : the first is slow, but it survives because
it's very easy to design boards for this bus. The second bus is faster,
is sexier but a big mess : you need a more expensive technology
and very specific tools. Circuits like the AMCC "matchbox" didn't= appear
until recently. I don't say that PCI is worse than ISA, i say that
it is less useful. It was imposed (remember the VLB ?) by some industry
cartel and slowly accepted. If we provide an easy entry in the system
with an easy-to-interface bus, we'll have a broader user base and easy ramp= -up
in frequency. thus more success.


> > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or ar= ound 300 Mhz
> > > with DDR or more with QDR. With LVDS, you can reach around 6= 00 Mhz by
> > > pin. BUT you can't really add a connector between 2 pins at = that speed.
> > then it must be soldered. but then, this speed is not required fo= r
> > handcrafting your own I/O board on a pre-drilled PCB. do you know= a mouse
> > or a keyboard or even a LCD screen that requires 600M x N pins of= data
> > per second ?
> >
> ????? I speak only for the network system, to be compared to the bus > system in intel board the 64 bit now 200 Mhz multipomped bus. Not to t= he
> PCI or EISA.
>
i think that i have lost track anyway.

> > Scalability means scale-down and scale-up. 500Mbps is fine, but w= hen you
> > don't need that much, it's an overkill. And you propose to make a= n adapter
> > that will bother of the I/O, but how many custom chips will you r= equire
> > to interface your connexion to any other stuffs ? Having a simple= and
> > one-fits-all protocol that does low and high-speed helps reduce t= he
> > number of different chips and interfaces...
>
> First only one to connect other system (PCI, IO,...) and no G-ship
> (include inside the fcpu)
>

if the "g-chip" (not "g-ship") is included inside the f= -cpu chip, then
it's only a f-cpu with more communication channels, but more pins.
I don't think that we can afford all the sexy technology now...

> > > My choice is to have a quick link (performance are our goal,= isn't it ?).
> > not only. In the design goals of the F-CPU, there are 3 other stu= ffs.
> >
> Which one ?
>
I thought that you read the presentation text, the manual and saw the
conference in Berlin...

c&p of the F-CPU manual, part1.html :
"
             To= develop and make freely available an architecture, and all other intellect= ual
property necessary to fabricate one or more implementations of that archite= cture, with the
following priorities, in decreasing order of importance:

       1. Versatility and usefulness in as wi= de a range of applications as possible
       2. Performance, emphasizing user-level= parallelism and derived through intelligent
             ar= chitecture rather than advanced silicon process
       3. Architecture lifespan and forward c= ompatibility
       4. Cost, including monetary and therma= l considerations
"

i didn't write it. i participated in the debates but it was accepted during= a poll
on this mailing list. it can be tracked down easily with the eGroups websit= e search engine.

i think that your propositions are off-topic for the f-cpu project.
1) high-speed serial links are not useful everywhere. it require specific<= BR>      interface chips that don't exist yet.
2) performance : you use brute-force technology, not an "intelligent = architecture".
     i am still waiting for a groundbreaking idea :-) 3) lifespan : you'll drop the Gbps when something "sexier" will = appear.
4) cost : what budget do you expect ?

i don't want to bring you down. Some people are enthusiastic and i don't want to break their hopes. You have sparkled an idea, now you need two thin= gs :
- you have to find your place in the landscape of the Free Hardware projec= ts.
     it seems that this list and this project is not a = good place to do this,
     we better speak about scheduling and the ISA... - you need a good architecture. Remember that it took almost a year before=
     we found something good for the F-CPU.

You, and i hope Jeff and others, will have a lot of work to do.


> > > > now you're asynchronous, you have to deal with PLL and = clock
> > > > recovery, hyperfrequencies, signal integrity, skew, etc= ...
> > > > that a lot of troubles for almost nothing.
> > > Not at all ! because you deal with macrocell and all the suf= t are soon made.
> > ain't it magical ??...
> > are you so confident and faithfull in the technologies ?
> Read there spec.
i was below the reality. You're playing with fire :-)
some bad experiences with Intel and ADi documentations
taught me to NEVER TRUST them. it's clearly written in
the disclaimer part : everything is "thought" to be acurate
and can be changed at any time without the consent of the
customer. but you won't learn until you get burnt :-)

> > > > you want speed ? put the wires in parallel, don't seria= lize the bits...
> > > Yes, but the limit are the number of pin and the prices ! An= d then you
> > > alwas have the speed of the clock with LVDS, you always have= the
> > > electrical and speed problem.
> >
> > ok, let's compare serial and parallel.
> >
> > you want 1Gbps links. halve it now, because the actual efficiency=
> > of a serial bus is not the raw peak number. With 10Base, one can'= t transfer
> > more than 500K bytes per second. or 520. whatever.
> > So let's imagine that you can SUSTAIN 50 M bytes per second.
> > caugh. caugh. ok, imagine you can reach 70M bytes in the two dire= ctions.
> > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M byt= es/s
> > (or 8 Gbps).
>
> True but with how many wire ?
>
that's rather similar, but now i'll add an argument :
how much time ?

with a serial bus, when you want to pass a message to a node,
you have to transmit a packet containing :
- who will receive it
- who sent it
- how large
- some control and description stuff.

In a 64-bit machine with 64-bit address space,
it takes around 150 bits (more or less 30%)
plus the data. that makes : 150 * 1 ns/bit (1Gbps peak rate)
or 150 ns.

now, how long does it takes to transmit the address
and the control signals on a paralle wire ? 10ns ?
even if it took 15ns, it would be 10x faster than
your serial link. so i can say that the latency
of your network is nearly disastrous :-P

> > Ok, i know, you want to reach 8Bgps by using 8 links.
> > but how are they connected ? if you want to make a ring, you'll > > dissipate your bandwidth, and if you want to make neighbour to ne= ighbour
> > connexions, you'll require 64 pins (or better 100, counting groun= ds/VCC)
> > per neighbour. retour case d=E9part...
>
> Compare the number of wire and the cost of a BGA compare to a PGA.
>
it's rather off-topic, we can't decide that it will work only with BGA.
you know (i presume) that there are some other technologies as well,
such as flip-chip etc... And you know that the number of pins
is only one of the problems. for example, if you reach higher yields
in the whole production fab, you'll reduce the cost of the chips
and the relative cost per pin as well.

> > > > > In usual core, you have simple bus and it's easy t= o
> > > > > put rom or eeprom to boot. But here, you need some= thing more special to boot.
> > > > and who will build that ? do you have the spare parts s= omewhere ?
> > > "spare part", i don't understand.
> > i mean : go buy some such chips at St Quentin Radio or Radio Shac= ks...
> > a chip that is available for sale in public catalogs.
> You are realy funny, even by Radiospares you can't buy 3.3 V logic, an= d
> you want an killing design to compet against alpha !
yes.
but i know that St Quentin Radio, Selectronics etc, they sell
some FPGA and other affordable chips that can play the interface
with a 3.3V F-BUS and a custom board. It's the same kind
of technology, or even cheaper as what you can read in Elektor...

> > But the protocol and the layout must remain the same, as to ease = the PCB design
> > and the easy replacement of the chips.
> *<;p
at least, you have some sense of humor ;-P

> > > Just for information : how much for a single chip ? And how = much heat
> > > for a chip ? You try to give some piece of your knowledge bu= t you don't
> > > understand the "simple coma" from SUN for their la= st system (from an URL
> > > given on the list), so ?
> > i've tried, but it's not that clear for me, what's so special ? > > when there's a page fault, i trap. Just make the correct fault ha= ndler,
> > and you implement any memory protection and sharing you want.
> > It leaves the door open to ANY memory system implementation.
> > what else do you want ? i'm still waiting for a clear and HW prop= osition.
> HW or SW that not the point, you can used both for the same thing, the=
> only 2 issue are cost and performance. Bevore, we had to find the
> algorythmes and then implement it.
of course it's the point because the good separation is critical for the performance/cost. read P&H :-)
So please analyse your preferred algorithm, and tell me what HW does
the most critical thing. It should be a simple unit, or at least pipelineab= le,
just like any unit in the F-CPU. I don't want a "COMA controler"-= like name,
i want something that anybody can interpret without going through the Webst= ers.
something like : lookup table, comparator, adder, ...
then, there's no problem to support COMA or whatever but don't give me all = the
work. You proposed something, you have to help if you want your idea to suc= ceed.
Similarly for your micro-network : you have to do it. There's no magic.

> "La culture est ce qui reste quand on ne sait rien faire" Fr= ancoise
> SAGAN, un peu provoc, l=E0... ;p
elle en connait un rayon l=E0-dessus ;-P

> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Mon Jan 8 05:14:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00302 for ; Mon, 8 Jan 2001 16:48:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:48:52 +0100 (MET) Received: (qmail 24152 invoked by uid 0); 8 Jan 2001 04:14:46 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx13) with SMTP; 8 Jan 2001 04:14:46 -0000 X-eGroups-Return: sentto-1101623-1884-978926931-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 08 Jan 2001 04:09:05 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 04:08:51 -0000 Received: (qmail 42922 invoked from network); 8 Jan 2001 04:08:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 8 Jan 2001 04:08:48 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 8 Jan 2001 04:08:47 -0000 Received: from f-cpu.org (nas3-120.aub.club-internet.fr [195.36.145.120]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA14689 for ; Mon, 8 Jan 2001 05:08:40 +0100 (MET) Message-ID: <3A593EA2.6352FA1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <200101071948.f07Jmrf15344@essi.essi.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 05:14:26 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5eb4a575f21e69a7ba43a2f09bcbb721 Status: R X-Status: N Yeah !!!
OH YES !!!
at last/least, some lurkers are speaking !!!!
but the results can be curious, such as :

Vanderhoeven Steve wrote:
> > If you connect more than 2 CPU on the same bus, they compete for = the ressource
> > and the bottleneck gets even narrow.
> atm?
hmm do you mean "At The Moment" or "ATM network" ?...
> steve


Marco Al wrote:
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> > > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
>
> You seem to presuppose that it wont have a single memory space with ha= rdware
> maintained coherency... I dont mind, I like transputers. But a lot of = users of
> parallel systems disagree.
>

at least we must leave the end user free of some critical choices.

> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as well,
> > > and it's my "hammer" argument when i try to promot= e point to point links.
> > > We spare the (distributed) control logic (all the nasty dead= lock stuffs etc)
>
> Thats one way of looking at it, the other way is that its a given that= L has to
> be B*N' and that for N>N' you need extra hierarchies.

often, "higher" hierarchies have a lower bandwidth, this makes th= e compilation
still more difficult (the mapping of the algorithm to the architecture is more complex if you have more levels). That's why the T3D is so seducing :-= ))

> And you wont get away from hierarchies, a single chip can only connect= to so
> many processors and have so much backplane capacity. The control will = always be
> distributed at a certain point.
at least we can try to avoid hierarchies as long as we can.
An homogeneous machine is always easier to use than a heterogeneous one.
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2 dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same but the
> > > address is split into 3 fields that are interpreted as an in= dependent ring address.
>
> Exactly.
>
> My opinion also kind of depends on where the motherboard chipset funct= ionality
> would be present and how many pins that would need.

examples ?

> I think making a bridge which can have a point-to-point/shared/ring co= nnection
> to the processors which itself plugs into a socket-7 board (or perhaps= even a
> PCI slot) is a good solution :) (bios should be local though, obviousl= y)
then, i'll leave you the burden of writing all the support code.
I don't want to deal with Socket-7 anymore, but i'll do it if you make
all the nasty stuffs at my place :-P

> Getting a processor made, no matter how many frills you remove is a hu= ge task...
we see this :-) but we're a few step further than 2 years ago....

> I think designing a motherboard chipset on top of that is an unnecessa= ry burden.
if some of you can cope with a EV-4 slot, it will be ok for me...

> You can always later replace the bridge with a true motherboard chipse= t.
it can also be left up to the end user...

but yes : let's concentrate on the CPU design :-)

> Marco

jeff@llandre.freeserve.co.uk wrote:
>
> Regarding this rather strange multi cpu argument:
<snip>
> All the multi cpu stuff is interesting but pointless. It
> doesnt change the core. Why not get back to that. We
> shouldnt waste whygee or michaels time, when they are
> doing so well with the vhdl.
if i wasn't at work, i could maybe do a bit better,
so anybody can challenge my skills ;-)
all i can do today is : to try to keep stuffs put together.
except for the latest manual patches, i didn't do
anything groundbreaking these last 3 months, which makes
me feel dumb and uncomfortable. work sucks for that
matter, but it pays so good that i feel almost guilty :-P

call for participation :
- whoever wants to participate with VHDL, manual, desing...
- whoever wants an account at seul.org
- whoever asks for the use of Cadence tools

please voice up on the list.

> like someone said, shit happens,
hmm sure. we're so used to it that we didn't care :-)

> forget 17c3,
no, we should remember the lesson.
But things weren't easy at 16C3 either.
Compared to last year, if we balance with the
number of people, 17C3 seems to work marvelously !
it is just the fact that more people were present
and the work is not the same as on the Net.

> success is the sweetest form of revenge.
yup.
> Once core is around, you multi cpu dudes can work on your
> own multiprocessors.
i propose that they don't stop, but try to organise their
own stuff. Of course we collaborate, but as pointed out on another
precedent mail, the goals were completely different.
We will spare a lot of troubles and useless discussion,
and we will restart to work, if the people make their own group.
yes, this sounds like a "split", but it's better than a
complete give-up. They started so well that it would
be sad if they stopped straight now...

> Jeff Davies



Marco Al wrote:
> From: <jeff@llandre.freeserve.co.uk>
>
> > smt as used by intel etc seems to share the whole of
> > system ram between all cpus which is dumb.
> > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> > but they also share the third sdram for comms.
>
> IMO thats combining the bad aspects of NUMA and message passing combin= ed in a
> single framework...

i'll comment with a ":-D"

> If you want to make a processor which can scale decently in multiproce= ssor
> setups you have to know which scheme you will be using at least in tim= e for the
> design of the MMU.

if you have an enhancement to propose to the TLB or the protected memory sy= stem,
i'm listening :-)

> Marco

Michael Riepe wrote:
> On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote:
> [...]
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
>
> It depends.  If you use ccNUMA or COMA, there will be a lot of ad= ditional
> traffic to keep the caches up-to-date.  And if you're running cer= tain
> parallelized tasks with high communication overhead, even Gbps etherne= t
> becomes too slow.

to me, Gb serial link is too slow and has too much latency anyway...

> > > buses are known, used and they work, but some people here wa= nt a "multimaster"
> > > bus. This means that the bandwidth is drawn by several point= s and the bus
> > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per= CPU, equal to
> > > the available bandwidth provided by the bus and divided by N= CPU).
> > >
> > > that's what i try to avoid.
>
> It's actually worse than B=3DL/N.  Don't forget the overhead for = bus
> arbitration and transfer direction turn-arounds.  I wouldn't be s= urprised
> at all if bandwidth drops below B=3DL/N/2.  If you want to come c= loser
> to B=3DL/N, you need to do large block transfers (unreasonable except = for
> mass storage access), and then you'll get problems with latencies (oth= er
> devices have to wait until the transfer is over and a new bus master > can be elected).  Another problem is that arbitration and turn-ar= ound
> times rise dramatically when the bus becomes longer (signal delay,
> bad impedance matching when tri-state drivers are used, and so on).
that's why i try to keep the f-bus (the one that connects the F-chips and the I/Os together) as simple as possible.

> > There are always possible traffic Jam. How do you manage when 2 n= odes
> > try to speak to the same nod ? You have to manage something to av= oid
> > losing informations.
>
> They will have to share the available bandwidth.  The G-Chip will= have
> to queue the second message while it's sending the first one.

well, the messages that i envision are packets with 256-bits of data
and an address with some additional info (byte ordering of the transfer, if we start from the end or the middle of the line etc...)

it's also a transactional bus, with around 16 transaction, so the
FIFO is 16*(256+64) bits. when the FIFO overflows, the transaction IDs
are not allowed and the bus stalls. of course, you can continue to interlea= ve
other packets (not addressed to the slow port) so you can still benefit
>from the remaining bandwidth if you have to transfer a lot of data
simultaneously with a 3rd port.

mmmh, the g-chip is getting interesting :-)

>  This could be avoided by putting 4 F-Bus interfaces into the CPU= itself
no, the "convergence" problem would remain anyway, but at a large= r (system) scale...
OTOH, the single-F-bus bottleneck would disappear but we'll need :
250 (SDRAM) + 4 * 100 (F-bus) pins, or roughly 700 pins for a f-cpu.
i would like one, it looks sexy, but it might be rather... expensive.
and the PCB routing might be ... tricky.... oh yes, it's sexy ;-)

> (did anybody say "transputer"?), which makes the G-chip obso= lete
> except for peripheral I/O and message routing/switching, or by using a=
> faster (4x) link between F-CPU and G-chip.
i think it's pointless. Every f-bus interface can be "rated" at a= certain
maximum speed. If you have a 200MHz f-cpu connected to a 150MHz g-chip, you= 'll
run at 150 MHz everywhere (f-cpu's f-bus interface and I/Os that can do mor= e
than 150MHz). OTOH, if the g-chip is connected to one 100MHz (or even 20 or anything) device, it won't slow down the whole system (unless this link<= BR> becomes the bottleneck because of its critical use by the SW, like ... swap= ping
etc...)

> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2 dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same but the
> > > address is split into 3 fields that are interpreted as an in= dependent ring address.
>
> A ring is actually much better than a bus because it is a unidirection= al
> device (no change of transfer direction, no tri-state buffers necessar= y,
> faster signalling) and arbitration is both simpler and faster (e.g. to= ken
> ring).  The members of the ring still share the available bandwid= th,
> but you come closer to B=3DL/N.  Per-CPU bandwidth is still limit= ed, though.

in a real system or computer, the ring is often either folded (with pairs o= f
nodes) or dual-way. So that's why it goes from L/N/2 to L/N : the bus
is physically 2x wider if you "cut" it somewhere.

> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6 neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant" (through dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU number).
> > >
> > So !
> [...]
>
> scales "perfectly" <EM>as long as the number of member= s per ring is limited</EM>.
> Sorry for shouting ;)

:-D

everybody has his/her own criteria...

> For highest-speed n-to-n communication, use direct connections.
if you can rewrap the wires in less than a millisecond, it's ok for me ;-P<= BR>
> Since this doesn't scale at all, you need to find a compromise when > the number of CPUs increases -- switches or crossbars, trees or rings.=
> In any case, the solution depends on the work the system has to do. > With the drafted G-chip with 4 links, we could build
>
>         - a 4-CPU directly-con= nected system
>         - a single ring (doubl= e ring requires 5 links, 1 for CPU)
>         - a binary or trinary = tree (USB-style)
>         - a flat hexagonal `be= ehive' structure
>         - a cube
>         - ...
>
> This is a pretty long list of options, isn't it?  Let the impleme= ntor (or
> system integrator) choose from this list; we don't have to care. = We just
> need to make sure that the G-chip is versatile enough to support at le= ast
> two or three of the most common topologies, and probably mixed topolog= ies
> (like a tree or ring of directly-connected clusters, for example).
> Preferably with auto-sensing capabilities =E0 la USB, i.e. the structu= re
> is determined at run (or boot) time.

yup. Let's stick to that... Lego brick ? :-)

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"




WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""
From Yann Guidon Mon Jan 8 05:14:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00308 for ; Mon, 8 Jan 2001 16:48:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:48:56 +0100 (MET) Received: (qmail 2036 invoked by uid 0); 8 Jan 2001 06:56:30 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx07) with SMTP; 8 Jan 2001 06:56:30 -0000 X-eGroups-Return: sentto-1101623-1883-978926931-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 08 Jan 2001 04:08:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 04:08:50 -0000 Received: (qmail 42912 invoked from network); 8 Jan 2001 04:08:48 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Jan 2001 04:08:48 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 8 Jan 2001 04:08:47 -0000 Received: from f-cpu.org (nas3-120.aub.club-internet.fr [195.36.145.120]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA01767 for ; Mon, 8 Jan 2001 05:08:39 +0100 (MET) Message-ID: <3A593EA1.91D8887D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 05:14:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] This project really sucks. (yes we know, but that's what makes it so interesting :-D) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 39ce79ab1bd98b3adda3bf660d13a33b Status: R X-Status: N some ramble-commenting,
discard if you don't care...

Alan Grimes wrote:
> =P
>
> om   (I'm invincible!)
me too ! me too ! me ... <wham>

>         Hey, you morons, whomever thinks he is running this project is doing an
> absolutly, unforgivably, horrible job. If you were, say, working for a
> company and were working in a well-managed tightly optomized R&D team,
> you guys would be briliant. BUT YOU'RE NOT!!!
hey, do you know ANY "well-managed tightly optomized R&D team" ? :-P
if so, i'd like to see it :-)

>         In a private company you have the luxury of closed-door face2face
> meetings where you can get a lot done.
make me dream... what's the name of this company ? :-)
<no, i won't leave Mentor>

> But, for an internet project such
> as this, that is totally inadqiquate. You must keep and maintain a
> current website...
is there a webmaster in the room ?
any ?

i'd like to do a million things, sleep, eat, have fun, go to gigs and
have a wife or two, but the VHDL and manual are my top priorities.
If anybody wants to take the responsibility of the web sites, it's ok
for me, i'll pass the rights and tricks, but please ... stop shouting :-)

>  oops! I *thought* it was f-cpu.tux.org (which should
> be updated or deleted.).
status : like the mailing list. Mathis is unreachable,
he's gone the AlphaGhost, Balsa and other's way.
let's remember this and not repeat the errors...

> For the ammount of traffic on the list,
> f-cpu.org is also stale, so my point holds, though not as strongly.. =\

if you want to contribute, please mail me an updated version of the page
(i'll upload it whenever i connect to the site one day) or take the responsibilities
of your requests. it's not that difficult after all : it takes "some time", patience
and a PC with a modem.

>         An project, such as what this one pretends to be, must provide an easy
> "on-ramp" for people who are new to the project to become active
> participants. Such consessions to the newbies must include:
>
> in order of importance:
>
>         - A glossary.
>         - A reading list.
>         - A document/source managment system. that is easily accessable to any
> reasonable web browser.
>         - A job managment system that can manage tasks and bugs from proposal
> to retirement.

hmmm, you seem to be the best one to do all that :-)

ok ok, i stop my silly irony. Of course, all that is fine.
we want a working CPU, plus a lot of professional tools...
what we really need is TIME and involved persons. Up to now,
the largest teams were 2 or 3 people.

how did the f-cpu advance ? Mathias+me : fc0 + manual, Michael+me : VHDL,
of course with very helpful punctual help from a lot of others.
Olivier now helps for the manual's technical maintainance, i update the contents.
Mathias left, i hope that Michael will stay much longer, and i hope that
i won't slowly abandon the project. it's too much work and it would fade away...

> The point I am trying to make here is that I have been on the list for
> two and a half years and I can't even say for certain what the status of
> the project is or wheather we have reached any "milestones".
are there any milestones after all ?
one BIG psychological milestone is that we started to make some decent VHDL.
Anybody can now contribute to this part. I estimate that it's a first good step.
But, just like the manual, it's a new burden of work to carry on and make work.

> I am really frustrated by the apparent lack of progress.
everybody is frustrated. But what keeps you from helping ?

> I need a gnu machine! =P
i first read "machine gun" ;-)
I also need this gnu HW, like a lot of people.
but do you think it will fall from the start with the force of your prayers ?

> I therefore make the following demands:
now that you have formalized them, please help them come true :-)
you will help yourself and others as well.

> - A Czar or voting comission with a fixed registered membership must be
> appointed or elected for the sole purpose of approving contributions to
> the document/source managment system with the objective of focusing the
> efforts of the group towards the completion (*ghasp*) and delivery of a
> product to market.
what market ?

we have an open arena where everybody can submit and discuss ideas.
if somebody feels isolated or not understood, he can do his own version and
start his own development.

> - A formal contributor development system, like what you would find in a
> company, that will provide training or mentoring to aspiring
> contributors.
name that company :-)

> - The founding of an American branch of the apparently extant french
> F-CPU orgainization. This is in recognition that local groups work
> better.
seeing the lack of action in France, where we seem to be more
organized than outside of Europe, this is going to be a big
undertaking. I'll send you a reward (cheese ? wine ?) if you succeed !
Frankly, i hope that more people organize themselves around the globe...

> Really, This project serves me only when it yields something that is
> useful. Failing that it can go to hell...
sure, Al, but do you think it can be for free ?
if you don't participate actively, you don't have the garantee that
it will work one day. Now, you don't participate because it's not successful.
but if you reverse the situation and make some continuous efforts,
you'll give us more chances.
And maybe : if you get more involved, you will feel less disapointed.

> I will see what happens over the next two months and then go bug the
> opencore people some more, and perhaps work up a project over there.
well, you do whatever you can. you can lurk whenever you want, but
you won't get much for free. if you don't participate, then you won't
have no right to criticize ... heh.


Michael Riepe wrote:
> On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:
> [...]
> > I therefore make the following demands:
> Demands?  F*ck off.  You have no right to demand *anything*.
he has the right to make any demands he wants. we all have expectations.
but it's not a "one-way" deal. his demand will not be fullfilled if
there's nothing in return. logic.

> [...]
> > Really, This project serves me only when it yields something that is
> > useful. Failing that it can go to hell...
>
> Don't ask what this project can do for you,
> ask what YOU can do for the project.
> (misquoting John F. Kennedy, IIRC)

it's been misquoted so many times that i wonder if it was JFK the first who told that...
:-)

> > I will see what happens over the next two months and then go bug the
> > opencore people some more, and perhaps work up a project over there.
> Fine.  Better go NOW and start bugging somebody else.
>
> This attitude makes me sick...
in one year or two, you won't ever care :-)

this list is an interesting place anyway. it's like an experience
on entropy, darwinism, cyberculture etc...

and it keeps you ready for anything : the worse like the best.
the remedy for boredom.


then, the backfire :

Alan Grimes wrote:
> Michael Riepe wrote:
> > You should learn how to read.
> I can read anything that is within the reach of a highschool graduate
> and a fair ammount of mathematical and technical stuff to...
this answer is the proof :-)

> As I mentioned in my post, there is little to suggest WHAT I should read,
> unless you want me to spend the rest of my life reading crap untill I
> finally hit on something that is relevant...
if you don't want to read crap, please contribute with something more interesting
than basic sparks (i don't call that flames...). you're free, you're adult
(?) and you have a brain. now it's time to prove that they work well together.

> It took me fully eighteen
> months of applying that self same process to learning how linker-loaders
> work. I literally had NO CLUE. Now its all perfectly clear to me. The
> position I am taking is that I have no intention of repeating that
> process.
you don't want to send time learning ? i don't get it.
anyway, it's sure that if you want something, praying or asking is not enough.

> > Or contribute.
> I can't, for the reasons that I attempted to explain in my last posting.
> READ IT.
i didn't understand much ...
you don't contribute because you find it's crap ?

> > Or shut up.
> Pleas understand that I am running Windows 3.11 on an Athalon processor.
geez. it works ? cool :-)

> The PC is far too fucked for me to write my own OS. (I have discovered
> this through great labor). But I *can* write an OS for F-cpu (I hope).
cool. but you understand that, before writing the OS, you have to get
a sort of loader or BIOS and HW drivers, and that they can't work before
the motherboard/platform is defined, and that won't happen before the
first F-CPU is released.

2 solutions :
- you're very patient. cool, then wait for an hypothetical f-cpu to appear.
- you're impatient. either you drop or you contribute to the f-cpu, and
you have the satisfaction that it is sped up.

> I am hurting.
>
>  In a year or so I won't be able to get anything done on the net at
> all... I will be profoundly fucked. "Shutting up" is not a very good
> option for me, now is it?
it's your choice. it's up to you.

> > > I therefore make the following demands:
> > Demands?  F*ck off.  You have no right to demand *anything*.
> Maybe not. But the fact that you can't take an ounce of criticism with
> regards to this project is equally un-cool.
equal to what ?

> I have been observing this project practicaly from day one.
> I have seen many things not happen. ;)
And do you feel comforted for that ?
did you finally understand that the best way to see things happen
is to participate ?

> This posting was my attempt to encapsulate all the observations I made
> into a single simple workable agenda for making things happen. If you
> can't take it then go work for a company, you have nothing valuble to
> contribute to an open-source project if you canot accept contributions.
what did you contribute ?

did you understand that if you made propositions, you were automatically
designated to apply them ? ;-) </k>

of course your precedent list was fine. my wish list to Santa Claus was
ever finer, but he didn't accept it. Now what to do ?
you can start a sub-project that will care about the organisation of the F-CPU.
you want it ? do it. then you won't lament as much, and you'll have the
satisfaction of shouting at the people who do nothing :-)

> > [...]
> > > Really, This project serves me only when it yields something that is
> > > useful. Failing that it can go to hell...
> > Don't ask what this project can do for you, ask what YOU can do for the
> > project. (misquoting John F. Kennedy, IIRC)
> Read my fucking posting before making brainless comments like this. It
> really shows me that you can't think one wit beyond your VHDL (or
> whatever) compiler to see that other people can hardly understand what
> it is you are doing.
if you don't like it, you have the possibility to make one yourself
or take a pre-designed one off the Net. The f-cpu design is not tied
to his implementation.

> THEN you will realize that this posting WAS a contribution.
i fail to see how it contributed, except to show that you are still
alive (which is of course a good news).

> It contributed the observation that people such as myself
> are essentially left-out of the project *and* it proposes a concise and
> understandable method for remedying the situation. If you would like to
> give me some permissions over at the sourceforge project then I will
> apply suggestions and my training in project managment towards achieving
> actual results.
Mathias is in charge of the sourforge stuff. he left. maybe you can still
reach him with a polite email but it would be faster to make your own
site (and share the access rights with someone else you choose, just
in case you leave the project).
You are free to contribute and i do whatever i can to help the contributors.

> I am sorry that linux users tend to be so goddamned dense that they
> can't see or accept a simple and logical suggestion even when it is
> explained to them!  No wonder their operating system is as terrible as
> it is...
what's wrong with my w95 ? </silly>

anyway i still don't see the point of the OS.

what we don't accept anyway is a "demand" with nothing in return.
the menace that you will leave is not a satisfaction, it's a sign
that you don't care.

Now if you want to participate more actively, by taking something that
you care in charge, nobody will refuse (i think, but it's a free list...)

> > > I will see what happens over the next two months and then go bug the
> > > opencore people some more, and perhaps work up a project over there.
> > Fine.  Better go NOW and start bugging somebody else.
> Hey! Wanna make a CPU?  I not only can but I will make it happen. This
> is what needs to be done.
and it will be done. one day.

> > This attitude makes me sick...
> So does yours.
at least, he has the satisfaction of having contributed in a critical
part of the project ;-) of course it's not an excuse for anything,
but it adds some weight...

> I must appologise, I shouldn't have jumped as hard as I did but I do
> really feel a lot of frustration with this...
we are all frustrated. maybe because of the "real" turn of the millenium.
we better speak openly about it, rather than just throwing everything away.
but being polite and an 1/4 ounce of respect can do wonders...

ok now i have to sleep. 2 hours left. i'll be stoned at work, tomorrow.
maybe i care too much for that project ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From "maurizio zoboli" Mon Jan 8 09:05:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00329 for ; Mon, 8 Jan 2001 16:49:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:49:04 +0100 (MET) Received: (qmail 13369 invoked by uid 0); 8 Jan 2001 09:20:40 -0000 Received: from unknown (HELO fj.egroups.com) (64.211.240.231) by mx0.gmx.net (mx24) with SMTP; 8 Jan 2001 09:20:40 -0000 X-eGroups-Return: sentto-1101623-1885-978941236-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fj.egroups.com with NNFMP; 08 Jan 2001 08:07:22 -0000 X-Sender: maurizio.zoboli@unimo.it X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 08:07:15 -0000 Received: (qmail 54721 invoked from network); 8 Jan 2001 08:07:15 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 Jan 2001 08:07:15 -0000 Received: from unknown (HELO mail.unimo.it) (155.185.1.1) by mta1 with SMTP; 8 Jan 2001 08:07:14 -0000 Received: from k527.ing.unimo.it (k527.ing.unimo.it [155.185.48.73]) by mail.unimo.it (2.1.2/8.9.1/Execmail 2.1) with SMTP id JAA3759005; Mon, 8 Jan 2001 09:00:44 +0100 (CET) Message-Id: <200101080800.JAA3759005@mail.unimo.it> To: "Didi" , "f-cpu@egroups.com" Priority: Normal X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05 In-Reply-To: <001701c078c5$aac98d80$3d8dfea9@celeron> From: "maurizio zoboli" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 09:05:53 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d00a1a222e63dd86ecb84c571bf15feb Status: R X-Status: N On Sun, 7 Jan 2001 16:17:04 -0000, Didi wrote:

>
>----- Original Message -----
>From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
>To: <f-cpu@egroups.com>
>Sent: Sunday, January 07, 2001 10:18 AM
>Subject: [f-cpu] REMOVE
>
>
>> On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:
>>
>> >Expand your business with
>> >    Email Marketing!
>> >
>> >Market your product or service
>> >     to MILLIONS!
>> >
>> >Don't waste another minute...
>> >
>> >Click Reply with your name,
>> >telephone number and the
>> >product or service you wish
>> >to market. We will be in
>> >touch with you shortly!
>> >
>> >
>> >
>> >
>> >
>> >Removal Instructions
>> >****************************
>> >To be removed from this list
>> >please reply with "REMOVE"
>> >in the subject.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Expand your business with
>> >    Email Marketing!
>> >
>> >Market your product or service
>> >     to MILLIONS!
>> >
>> >Don't waste another minute...
>> >
>> >Click Reply with your name,
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>> Prof. Maurizio Zoboli
>> Dipartimento di Scienze dell'Ingegneria
>> Universita' di Modena e Reggio Emilia
>> via Vignolese 905
>> I-41100 Modena, Italy
>> Tel.: +39 059 2056163
>> Fax: +39 059 2056129
>> e-mail: maurizio.zoboli@unimo.it
>>
>>
>>
>>
>
>
>
>



Prof. Maurizio Zoboli
Dipartimento di Scienze dell'Ingegneria
Universita' di Modena e Reggio Emilia
via Vignolese 905
I-41100 Modena, Italy
Tel.: +39 059 2056163
Fax: +39 059 2056129
e-mail: maurizio.zoboli@unimo.it
eGroups Sponsor
Click Here!
From "maurizio zoboli" Mon Jan 8 09:08:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00333 for ; Mon, 8 Jan 2001 16:49:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:49:05 +0100 (MET) Received: (qmail 13980 invoked by uid 0); 8 Jan 2001 09:20:51 -0000 Received: from unknown (HELO fj.egroups.com) (64.211.240.231) by mx0.gmx.net (mx24) with SMTP; 8 Jan 2001 09:20:51 -0000 X-eGroups-Return: sentto-1101623-1886-978941384-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 08 Jan 2001 08:09:48 -0000 X-Sender: maurizio.zoboli@unimo.it X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 08:09:44 -0000 Received: (qmail 62246 invoked from network); 8 Jan 2001 08:09:44 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 8 Jan 2001 08:09:44 -0000 Received: from unknown (HELO mail.unimo.it) (155.185.1.1) by mta3 with SMTP; 8 Jan 2001 09:10:48 -0000 Received: from k527.ing.unimo.it (k527.ing.unimo.it [155.185.48.73]) by mail.unimo.it (2.1.2/8.9.1/Execmail 2.1) with SMTP id JAA4749622; Mon, 8 Jan 2001 09:03:13 +0100 (CET) Message-Id: <200101080803.JAA4749622@mail.unimo.it> To: "Didi" , "f-cpu@egroups.com" Priority: Normal X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05 In-Reply-To: <001d01c078c6$d32a5b00$3d8dfea9@celeron> From: "maurizio zoboli" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 09:08:30 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4da1e8850d9aea3fb62f5e6d54f7722a Status: R X-Status: N On Sun, 7 Jan 2001 16:28:07 -0000, Didi wrote:

>
>----- Original Message -----
>From: "Didi" <flei@wanadoo.fr>
>To: <f-cpu@egroups.com>
>Sent: Sunday, January 07, 2001 4:17 PM
>Subject: [f-cpu] REMOVE
>
>
>>
>> ----- Original Message -----
>> From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
>> To: <f-cpu@egroups.com>
>> Sent: Sunday, January 07, 2001 10:18 AM
>> Subject: [f-cpu] REMOVE
>>
>>
>> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote:
>> >
>> > >Expand your business with
>> > >    Email Marketing!
>> > >
>> > >Market your product or service
>> > >     to MILLIONS!
>> > >
>> > >Don't waste another minute...
>> > >
>> > >Click Reply with your name,
>> > >telephone number and the
>> > >product or service you wish
>> > >to market. We will be in
>> > >touch with you shortly!
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >Removal Instructions
>> > >****************************
>> > >To be removed from this list
>> > >please reply with "REMOVE"
>> > >in the subject.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >Expand your business with
>> > >    Email Marketing!
>> > >
>> > >Market your product or service
>> > >     to MILLIONS!
>> > >
>> > >Don't waste another minute...
>> > >
>> > >Click Reply with your name,
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > Prof. Maurizio Zoboli
>> > Dipartimento di Scienze dell'Ingegneria
>> > Universita' di Modena e Reggio Emilia
>> > via Vignolese 905
>> > I-41100 Modena, Italy
>> > Tel.: +39 059 2056163
>> > Fax: +39 059 2056129
>> > e-mail: maurizio.zoboli@unimo.it
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
>
>
>



Prof. Maurizio Zoboli
Dipartimento di Scienze dell'Ingegneria
Universita' di Modena e Reggio Emilia
via Vignolese 905
I-41100 Modena, Italy
Tel.: +39 059 2056163
Fax: +39 059 2056129
e-mail: maurizio.zoboli@unimo.it
eGroups Sponsor
Click Here!
From Vanderhoeven Steve Mon Jan 8 12:14:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00350 for ; Mon, 8 Jan 2001 16:49:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:49:10 +0100 (MET) Received: (qmail 30652 invoked by uid 0); 8 Jan 2001 11:14:14 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx23) with SMTP; 8 Jan 2001 11:14:14 -0000 X-eGroups-Return: sentto-1101623-1887-978952443-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 08 Jan 2001 11:14:08 -0000 X-Sender: vanderho@essi.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 11:14:02 -0000 Received: (qmail 33497 invoked from network); 8 Jan 2001 11:14:02 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 8 Jan 2001 11:14:02 -0000 Received: from unknown (HELO essi.essi.fr) (157.169.25.1) by mta2 with SMTP; 8 Jan 2001 11:13:47 -0000 Received: from 0 (news-srv.essi.fr [157.169.25.200]) by essi.essi.fr (8.11.1/8.11.1) with ESMTP id f08BDif23539 for ; Mon, 8 Jan 2001 12:13:45 +0100 (MET) Message-Id: <200101081113.f08BDif23539@essi.essi.fr> To: f-cpu@egroups.com User-Agent: IMHO/0.98.1 (Webmail for Roxen) In-Reply-To: <3A593EA2.6352FA1@f-cpu.org> From: Vanderhoeven Steve MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 Jan 2001 12:14:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war =?iso-8859-1?q?ehr=3F?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ebbffb237120864ae646bb5657607046 Status: R X-Status: N
> Vanderhoeven Steve wrote:
> > > If you connect more than 2 CPU on the same bus, they compete for the ressource
> > > and the bottleneck gets even narrow.
> > atm?
> hmm do you mean "At The Moment" or "ATM network" ?...

I was just sugesting you to look at the idea of ATM networks. It has service like reserving a part of the bandwidth for communication between two points.

Steve
eGroups Sponsor
Click here!
From "Iancu Silvius" Mon Jan 8 14:02:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00390 for ; Mon, 8 Jan 2001 16:49:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 08 Jan 2001 16:49:21 +0100 (MET) Received: (qmail 10018 invoked by uid 0); 8 Jan 2001 14:29:23 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by mx0.gmx.net (mx13) with SMTP; 8 Jan 2001 14:29:23 -0000 X-eGroups-Return: sentto-1101623-1888-978959700-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 08 Jan 2001 13:15:27 -0000 X-Sender: silvius@mail.dnttm.ro X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 13:14:53 -0000 Received: (qmail 40470 invoked from network); 8 Jan 2001 13:14:51 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 8 Jan 2001 13:14:51 -0000 Received: from unknown (HELO terminus.dnttm.ro) (193.226.98.11) by mta3 with SMTP; 8 Jan 2001 14:15:37 -0000 Received: from silvius (ppp66.dnttm.ro [193.231.207.71]) by terminus.dnttm.ro (8.9.3/8.9.3) with SMTP id PAA27717 for ; Mon, 8 Jan 2001 15:14:03 +0200 Message-ID: <002b01c07974$ae21ecc0$7802fea9@silvius> To: References: <978954451.37500@egroups.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: "Iancu Silvius" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 15:02:37 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] "REMOVE" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4e981b3d47d85254b2c2c2c0a02c07d0 Status: R X-Status: N
----- Original Message -----
From: <f-cpu@egroups.com>
To: <f-cpu@egroups.com>
Sent: Monday, January 08, 2001 1:47 PM
Subject: [f-cpu] Digest Number 241


> There are 22 messages in this issue.
>
> Topics in this digest:
>
>       1. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       2. REMOVE
>            From= : "Didi" <flei@wanadoo.fr>
>       3. NO MORE SPAM MAIL !!!  DO = YOU UNDERSTAND ME ?  STUPID GUY
>            From= : "Didi" <flei@wanadoo.fr>
>       4. remove
>            From= : rvsicam@aol.com
>       5. Re: REMOVE
>            From= : Yann Guidon <whygee@f-cpu.org>
>       6. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Vanderhoeven Steve <vanderho@essi.fr>
>       7. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : "Marco Al" <marco@simplex.nl>
>       8. RE: Re: Re: 17. Chaos Communica= tion Congress - Wie war ehr?
>            From= : jeff@llandre.freeserve.co.uk
>       9. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      10. Re: NO MORE SPAM MAIL !!!  DO Y= OU UNDERSTAND ME ?  STUPID GUY
>            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      11. Re: NO MORE SPAM MAIL !!!  DO Y= OU UNDERSTAND ME ?  STUPID GUY
>            From= : Keyshaun <thekernel@subdimension.com>
>      12. Re: Re: Re: 17. Chaos Communication = Congress - Wie war ehr?
>            From= : "Marco Al" <marco@simplex.nl>
>      13. This project really sucks.
>            From= : Alan Grimes <alangrimes@starpower.net>
>      14. Re: This project really sucks.
>            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      15. Re: This project really sucks.
>            From= : Alan Grimes <alangrimes@starpower.net>
>      16. REMOVE
>            From= : "Iancu Silvius" <silvius@mail.dnttm.ro>
>      17. Re: Re: 17. Chaos Communication Cong= ress - Wie war ehr?
>            From= : Yann Guidon <whygee@f-cpu.org>
>      18. Re: This project really sucks. (yes = we know, but that's what
makes it so interesting :-D)
>            From= : Yann Guidon <whygee@f-cpu.org>
>      19. Re: Re: 17. Chaos Communication Cong= ress - Wie war ehr?
>            From= : Yann Guidon <whygee@f-cpu.org>
>      20. REMOVE
>            From= : "maurizio zoboli" <maurizio.zoboli@unimo.it>
>      21. REMOVE
>            From= : "maurizio zoboli" <maurizio.zoboli@unimo.it>
>      22. Re: Re: 17. Chaos Communication Cong= ress - Wie war ehr?
>            From= : Vanderhoeven Steve <vanderho@essi.fr>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 1
>    Date: Sun, 07 Jan 2001 13:46:24 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
>
> Yann Guidon a =E9crit :
> >
> > hi !
> >
> > Marco Al wrote:
> > > The only way to proove/disproove that
> > > IMO is to model both alternatives, but Im both too lazy and = I dont
have the
> > > necessary knowledge (AFAICS I would need to know feasibly ph= ysical
bandwith per
> > > pin in point to point and bus setups, and have a good traffi= c
breakdown for
> > > multiprocessor setups) .With a lot of broadcast traffic I ju= st dont
think the
> > > effective bandwith per pin of a point to point bus compares<= BR> favourably, let
> > > alone the extra costs and latency of the routing chips for s= mall SMP
setups.
> >
> > well, there's the architecture side here...
> >
> > if you target "small SMP" only, maybe you can do it wit= h a shared bus,
> > but don't expect wonders above 4 CPU. If you're doing CPU-only ta= sks,
it's
> > ok, but when you start to move things around, it's the real mess.=
> > Intel sticks to this because the architecture is more or less stu= ck.
> > they want cheap systems and make big profits, but still compete (= with
> > some pain) in the SPEC contests.
> >
>
> You always forget one big thing. Here we speak about private memory an= d
> communication network to speed up memory interface. So in the intel > architecture, 4 is a maximum because all the 4 cpu read the memory
> thought the same shared bus. In our system, only message go thought th= e
> network. In the best case, only I/O instruction go thought the network=
> and very few message from the processes.
>
> > I am trying to find the "least common denominator" for = a F-CPU system
> > that can range from 1 CPU to any arbitrary number of CPUs (just l= ike
> > the register width : not bound to anything). let's take a few cas= es,
> > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" shou= ld also scale
> > to much more CPUs : the widest systems today (see the monters at = the
LANL)
> > can scale to more than 10K CPU, so let's round up to 65536.
> >
> > now let's compare the alternatives...
> >
> > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's disastrous
> > with more CPU.
> >
> > buses are known, used and they work, but some people here want a<= BR> "multimaster"
> > bus. This means that the bandwidth is drawn by several points and= the
bus
> > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU,= equal to
> > the available bandwidth provided by the bus and divided by N CPU)= .
> >
> > that's what i try to avoid.
> >
> > Clearly, this B=3DL/N is a thing that i try to avoid for other th= ings as
well,
> > and it's my "hammer" argument when i try to promote poi= nt to point
links.
> > We spare the (distributed) control logic (all the nasty deadlock = stuffs
etc)
>
> There are always possible traffic Jam. How do you manage when 2 nodes<= BR> > try to speak to the same nod ? You have to manage something to avoid > losing informations.
>
> > and it's very simple to implement. the PCB is simpler, too.
> >
> > If you connect more than 2 CPU on the same bus, they compete for = the
ressource
> > and the bottleneck gets even narrow.
> >
>
> Yes, but less drastically as intel SMP.
>
> > On the pin count vs bandwidth argument, it's similar. Of course, = we can
find
> > a lot of counter-examples and special cases, but the example of t= he
broadcast
> > is not the best one. Most of the requests are from one node to a = single
other
>
> In fact, not. It depend how much process communicate between them. And=
> sometimes the only [simple] way to find a "moving" ressource= s is to send
> a braodcast.
>
> > and here, the efficiency of a bus drops dramatically ! for a N-CP= U
system,
> > the efficiency is of 2 used bus interfaces for N bus interfaces (= you can
> > replace "bus interface" with "pin"), 2/N is s= imilar to the 1/N scheme
> > (if we speak about the "big O" or complexity). This mea= ns that :
> > the more CPU, the least efficient ! you'll see that the best way = to
avoid
> > this is by having as few CPU by link as possible, and the minimum= is 2.
> > that's "point to point"...
> >
> > Now, another stuff. Nico usually wants a ring. It's "simple = to route",
> > it's fun and doesn't need much "efforts". But there is = still the same
> > problem as before : the more CPU, the less bandwidth when one CPU= wants
> > to talk to another. 1/N (or 2 pins / N CPU if you want the "= real
efficiency").
> > The solution is rather easy : you have to expand that to the othe= r 2
dimensions,
> > hence the "CRAY T3D" and the extension, T3E. Routing is= still the same
but the
> > address is split into 3 fields that are interpreted as an indepen= dent
ring address.
> >
>
> In the flight back to France, we have spoken about ring of ring.(and > called the architecture the lord of the ring ;p). A ring is composed > around 8 to 16 card (cpu+ram or IO). A card could be used to communica= te
> with other ring. Maybe it's possible to grow in hierachy without to mu= ch
> trouble.
>
> > here, you don't have 1 ring but x*y*z rings. It means that there = is
> > no bandwidth problem at all, because each CPU communicates with i= ts 6
neighbours.
> > It works very well, it can be tweaked to become "fault toler= ant"
(through dynamic
> > node addresses) and scales perfectly (almost linearly with the CP= U
number).
> >
> So !
>
> > So if you want the simplest system, you have 1 CPU with no ring,<= BR> > > and when you scale up, add a few links when needed and use like &= quot;lego
bricks"
> > in a cubic connexion.
> >
> Cubic ~=3D  ring ????
> > I think that the G-chip was an easy way to make the topology
reconfigurable
> > by the user/implementor. If we provide the brick, the user will m= ake a
lot
> > of stuffs, but if we restrict the choices, the scalability and th= e
flexibility
> > will suffer.
> >
> > > Marco
> >
> > Nicolas Boulay wrote:
> > >
> > > Hi,
> > >
> > > Yann Guidon a =E9crit :
> > > >
> > > > hi,
> > > >
> > > > Nicolas Boulay wrote:
> > > > > hi,
> > > > >
> > > > > Oups, i omit to say for reduice the cost that i wo= uld like to try
to
> > > > > have only one chip and avoid many differents chips= . So the 8 links
will
> > > > > be "inside" the fcpu chip. This is the m= ain system bus.
> > > >
> > > > hum, hum... just a reminder : the SiO2 process is not m= uch the same
> > > > for a CPU and a tranceiver. you CAN't put it on the sam= e die...
> > >
> > > I don't think that you know about what you speak ! New silic= on process
> > > are silicium on insulator, soon used by IBM for there udge p= rocessor
for
> > > mainfrain (a little beast with 35 ppc on the same die).
> > duh. and how will you ask IBM to make your chip ?
> > it's not something that everybody can do. it's not free, it's exp= ensive
>
> And you think that actual 0.18 =B5m are free ? In 2 years, SOI will be=
> used in every silicon process, because it reduice the power consumptio= n
> and doesn't cost so much (it's just a little traitement on wafer).
>
> > and it's not connectable to anything...
> >
> ??? I think you miss something... The only electrical rules to respect=
> is the higher voltage in input, most of the time lower than 3.3 V, to<= BR> > avoid destroying transistor, that's all.
>
> > > And now, for the next powerG3. Next, the SiGe are new proces= s used to
have
> > > hyperfrequencies, or mixed analogue and digital part. But th= en, it
could
> > > be used for very quick digital circuit.
> > It is. but how many people would use such a chip ? what can they = connect
it to ?
> > how will you "solve" the RF issues ? Do you know how di= fficult it is to
route
> > a 50 MHz signal ? So who will buy you the SW needed to design a R= F PCB ?
> >
>
> I think that Cadence has offer something. (any news ?) You want
> performance and you think that 50 Mhz signal are to much. How do you > want to deal with 133 Mhz DDR-SDRAM ?
>
> > > And, for information, gigabit ethernet need 500 Mhz. So, &qu= ot;usual
process"
> > > are must enought to make a tranceiver.
> > Maybe you should stop to use the term "ethernet". If it= 's a simple
>
> But in electrical rules, gigaethernet is only a serial point to point<= BR> > link, not much more (just add the mac adress and a crc).
>
> > "serial link", you're just making a firewire clone... > >
>
> A=EFe ! Firewire isn't a point to point serial link !!!! It's a comple= te
> network system which include the 3rd layer of the OSI system. It inclu= de
> the routing protocole and all that stuff (the same thing than IP )! >
> > > > > The 8 ethernet link could be say has 2 one-way gig= abyte links. So,
if
> > > > > you use a ring, you need 2 of this links (one by r= ing). So you
will only
> > > > > need a 1 layer PCB !
> > > > beep. wrong. gigabit ethernet, or any ethernet, require= s a very
special
> > > > medium to propagate. the shield, the impedence adaptati= on, the
diameter,
> > > > the propagation, etc. are more or less taught in the IU= T or
ingenieur school.
> > > A=EFe ! You just have to respect electrical rules of the gig= abit
ethernet
> > > (L and C).
> > that's a pretty quick simplification. even though at your level i= t fits,
> > when you make the PCB it takes another dimension ...
> >
> > > > they're a lot of formula etc, so you can't simply draw = a line and
say "ok".
> > > > it can't be so. otherwise, network cables would be much= cheaper.
> > > > have you heard about "Cat. 5" cables ? did yo= u wonder why it was
more
> > > You have never learn that this kind of cable could be around= 50 meter
> > > long ! Here 1 or 2 meters is much enought !
> > and you think that it's not the same problem ????
> > have you heard about Xtalk and such stuff ? you CAN't make it wit= h a
1-layer PCB.
>
> That's why ethernet cable are made by pair (like lvds, d is for
> differential). And with some ground it could pass.
>
> > you need at least 3 layers to make a decent transmission line
>
> so 4 layers, like usual mother board.
>
> > (shield/insulator/signal/insulator/shield). And depending on your=
signal's
> > characteristics, you have to change the dimensions of the tracks,=
> > so they are adapted to the thickness of the PCB and the permeabil= ity of
> > the insulator (if it's epoxy or teflon or something else).
> >
> > Whether the wire is 50m or 1m, the problem is the same...
> >
>
> Not really. The Characteristique are made to say that your cable could=
> be 50 meter long, so the signal could be mixed with a certain level of=
> noise. If you need shortest cable, you could adjust the quality of the=
> cable.
>
> > > > > > i compare what can be compared.
> > > > > > the current idea is simply not realistic.
> > > > > Yes, the idea that you have understood, not mine !=
> > > > talk about a monodirectional synchronous parallel (byte= ?)
> > > > bus with some control signals, a clock (dual edge ?) an= d it's ok for
> > > > me, whatever your idea is. Anybody can implement that w= ith a
> > > Fast clock one large network, you have to deal with clock sk= ew.
> > it's an old known problem and there are some old known solutions.=
> > ever heard about a "clock tree" ?... if you have a good= architecture,
> > you don't have skew troubles.
> >
>
> Don't forget that i'm microelectronic engineer and clock tree are a > basis... Which is not so simple at all.
>
> > > Most of the time, each founder (ST microelectronics, TSMC, infineon,...)
> > > have a macro cell to do gigaethernet and do all the hard thi= ngs
(serial,
> > > deserials).
> > and you'll by the components ? come on...
>
> The chip maker will by it.
>
> > and please, don't talk about "Ethernet", it seems like = it's
> > only a serial point to point link (if i remember one of your mess= ages).
> >
>
> But, it is !
>
> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL si= gnify 5V
and
> > > some nF of charge. I don't want to repeat it each time.
> > hey, i'm not dumb, i know that TTL is slow. thanks.
> >
> > but just a question : how will you debug your stuff ? will you us= e
> > a 10GS/s logic analyser ? with a simple enough protocol, i can > > debug the interface with "off the shelf parts" that i c= an solder at
will,
> > the old school way, just like any "hacker".
> >
>
> Like everybody, you will use a standart JTAG port.
>
> > Then, when it's developped, you only have to change the electrica= l
> > levels (that is : the pin's driving gates) and you can do LVTTL o= r
whatever
> > high-speed connexion. it's just a matter of changing the electric= al
spec.
> > Yes i want speed, but a "hacker" needs a way to see wha= t happens without
> > the need of extremely expensive devices. by clocking the chip slo= wer
> > and adapting the electrical level (with the adapted buffers or transmitters),
> > you can hook anything to the F-BUS.
> >
>
> If you use low voltage it's because you can't manage with higher one. = So
> it could be impossible to change it !
>
> > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow = compare to
> > > usual system.
> > this kind of speed is used for I/O with maybe a controller or som= ething
> > like that. When i speak about "TTL parts", it's somethi= ng like a 8255
> > or any very slow byte-based I/O chip. just like during the old da= ys
> > of the 8-bit systems...
> >
>
> And you want performance by slow down the network only to put good old=
> I/o chip....
>
> > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or ar= ound 300 Mhz
> > > with DDR or more with QDR. With LVDS, you can reach around 6= 00 Mhz by
> > > pin. BUT you can't really add a connector between 2 pins at = that
speed.
> > then it must be soldered. but then, this speed is not required fo= r
> > handcrafting your own I/O board on a pre-drilled PCB. do you know= a
mouse
> > or a keyboard or even a LCD screen that requires 600M x N pins of= data
> > per second ?
> >
> ????? I speak only for the network system, to be compared to the bus > system in intel board the 64 bit now 200 Mhz multipomped bus. Not to t= he
> PCI or EISA.
>
> > Scalability means scale-down and scale-up. 500Mbps is fine, but w= hen you
> > don't need that much, it's an overkill. And you propose to make a= n
adapter
> > that will bother of the I/O, but how many custom chips will you r= equire
> > to interface your connexion to any other stuffs ? Having a simple= and
> > one-fits-all protocol that does low and high-speed helps reduce t= he
> > number of different chips and interfaces...
> >
>
> First only one to connect other system (PCI, IO,...) and no G-ship
> (include inside the fcpu)
>
> > > My choice is to have a quick link (performance are our goal,= isn't it
?).
> > not only. In the design goals of the F-CPU, there are 3 other stu= ffs.
> >
> Which one ?
>
> > > Then you just had to provide a bridge between the quick link= and a
> > > SRAM like bus. I think that could be easy : Just a link like= for the
> > > fcpu and a little glue for the interface.
> > i'll give you the honnor of doing the first one...
> >
> > > > now you're asynchronous, you have to deal with PLL and = clock
> > > > recovery, hyperfrequencies, signal integrity, skew, etc= ...
> > > > that a lot of troubles for almost nothing.
> > > Not at all ! because you deal with macrocell and all the suf= t are soon
made.
> > ain't it magical ??...
> > are you so confident and faithfull in the technologies ?
> >
> Read there spec.
>
> > > > you want speed ? put the wires in parallel, don't seria= lize the
bits...
> > > Yes, but the limit are the number of pin and the prices ! An= d then you
> > > alwas have the speed of the clock with LVDS, you always have= the
> > > electrical and speed problem.
> >
> > ok, let's compare serial and parallel.
> >
> > you want 1Gbps links. halve it now, because the actual efficiency=
> > of a serial bus is not the raw peak number. With 10Base, one can'= t
transfer
> > more than 500K bytes per second. or 520. whatever.
> > So let's imagine that you can SUSTAIN 50 M bytes per second.
> > caugh. caugh. ok, imagine you can reach 70M bytes in the two dire= ctions.
> > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M byt= es/s
> > (or 8 Gbps).
> >
>
> True but with how many wire ?
>
> > Ok, i know, you want to reach 8Bgps by using 8 links.
> > but how are they connected ? if you want to make a ring, you'll > > dissipate your bandwidth, and if you want to make neighbour to ne= ighbour
> > connexions, you'll require 64 pins (or better 100, counting groun= ds/VCC)
> > per neighbour. retour case d=E9part...
> >
>
> Compare the number of wire and the cost of a BGA compare to a PGA.
>
> > > > > In usual core, you have simple bus and it's easy t= o
> > > > > put rom or eeprom to boot. But here, you need some= thing more
special to boot.
> > > > and who will build that ? do you have the spare parts s= omewhere ?
> > > "spare part", i don't understand.
> > i mean : go buy some such chips at St Quentin Radio or Radio Shac= ks...
> > a chip that is available for sale in public catalogs.
> >
>
> You are realy funny, even by Radiospares you can't buy 3.3 V logic, an= d
> you want an killing design to compet against alpha !
>
> > > One day, you say you want performance,
> > > the other days somthing so slow to be compatible with TTL. I= don't
> > > understand you...
> >
> > i want something that can do both, but of course not at the same = time.
> > you can't access a mouse or handcrafted I/O board (anything that = you
> > see in Elektor or Electronique Pratique) with the same means as a= nother
CPU.
> > But the protocol and the layout must remain the same, as to ease = the PCB
design
> > and the easy replacement of the chips.
> >
>
> *<;p
> > > > > Have you a link for a preditive routing algorithme= ? I think that
my
> > > > > collegue which make a thesis about real time netwo= rk will be very
> > > > > interrested to know that exist.
> > > >
> > > > the routing stuff is taught during the DEUG at Paris 8 = university.
> > > > ask Amal Stri from the transversal department.
> > > >
> > > > When at Boston, in a (expensive) library, i found (but = didn't buy)
> > > > a VERY cool about the T3E and similar architectures. Th= e routing
> > > > algos are rather simple and very efficient.
> > >
> > > I seriously doubt about the complexity and the scalability..= .
> >
> > remember, it's a torus. only, it's 3D :-)
> > for the other details, it's up to you to go to the library,
> > read as many book as you can and ask the teachers and the
> > educated people from comp.arch and comp.sys.super...
> > i won't do it for you, you wouldn't believe what i say :-P
> >
> > > > > If we made a simple core (like ARM), we don't need= g-ship and all
that crap.
> > > > not true. ARM chips require I/O chips. Unless you buy t= he
synthesised core,
> > > > and implement it in the middle of a sea-of-gates ASIC w= ith your
prefered I/O.
> > > One more times, you don't unsderstand ! i propose like leon,= just to
> > > develope the fc0 (the core) and let other gays to use it. > > so let's drop this silly network/bus whatever debate for a while.= ..
> >
> > > > > If we made a processor ("a system") we s= hould consider to have
> > > > > fault tolerance capabilities. And hot swap is the = basis !
> > > > not necessarily. fault detection and bypass are a SW ma= tter,
> > > > with the help of some HW (ECC/SEC). but the rest is pur= ely an
electrical
> > > > problem.
> > > >
> > > Not really, i don't speak about fault detection but failure = tolerant
(a
> > > single dead card don't stop the all system, you just have to= change
it).
> >
> > it's the SAME thing. You can't be "fault tolerant" if y= ou can't detect
> > the fault and take the necessary SW measures. It's obvious...
> > i'm just trying to avoid "buzzwords" that taint the deb= ate with black
magic ;-)
> >
> > > > some designs that you should investigate (using several= different
books,
> > > > saying different stuffs) : T3D/E (it's a 3D torus with = ALPHAs at the
nodes),
> > > > CM1 (12-cube with extremely simple routing), CM5 (fault= tolerance,
"big tree"
> > > > network, message passing communication etc.), SGI/SUN/H= P scalable
computing nodes
> > > > (i found the Convex (circa 1995) very interesting, but = Convex is now
owned by HP).
> > >
> > > Just for information : how much for a single chip ? And how = much heat
> > > for a chip ? You try to give some piece of your knowledge bu= t you
don't
> > > understand the "simple coma" from SUN for their la= st system (from an
URL
> > > given on the list), so ?
> >
> > i've tried, but it's not that clear for me, what's so special ? > > when there's a page fault, i trap. Just make the correct fault ha= ndler,
> > and you implement any memory protection and sharing you want.
> > It leaves the door open to ANY memory system implementation.
> > what else do you want ? i'm still waiting for a clear and HW
proposition.
> >
>
> HW or SW that not the point, you can used both for the same thing, the=
> only 2 issue are cost and performance. Bevore, we had to find the
> algorythmes and then implement it.
>
> > > > i know, it's a matter of culture...
> > > I just see it's like jam, ...
> > J'en ai une meilleure, mais je ne l'ai pas invent=E9e non plus, > > elle est de Jacques Brel : "La culture, c'est la m=E9moire d= es
> > cons qui n'ont rien invent=E9". Il avait vraiment des id=E9e= s
> > noires avant de mourir... La culture, il faut se la faire
> > tous les jours et ne pas trop camper sur ses positions...
> > avec le f-cpu, on a ce qu'il faut comme action :-)
> >
> > bonne nuit,
> >
>
> "La culture est ce qui reste quand on ne sait rien faire" Fr= ancoise
> SAGAN, un peu provoc, l=E0... ;p
>
> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 2
>    Date: Sun, 7 Jan 2001 16:17:04 -0000
>    From: "Didi" <flei@wanadoo.fr>
> Subject: REMOVE
>
>
> ----- Original Message -----
> From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> To: <f-cpu@egroups.com>
> Sent: Sunday, January 07, 2001 10:18 AM
> Subject: [f-cpu] REMOVE
>
>
> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote= :
> >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >telephone number and the
> > >product or service you wish
> > >to market. We will be in
> > >touch with you shortly!
> > >
> > >
> > >
> > >
> > >
> > >Removal Instructions
> > >****************************
> > >To be removed from this list
> > >please reply with "REMOVE"
> > >in the subject.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Prof. Maurizio Zoboli
> > Dipartimento di Scienze dell'Ingegneria
> > Universita' di Modena e Reggio Emilia
> > via Vignolese 905
> > I-41100 Modena, Italy
> > Tel.: +39 059 2056163
> > Fax: +39 059 2056129
> > e-mail: maurizio.zoboli@unimo.it
> >
> >
> >
> >
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 3
>    Date: Sun, 7 Jan 2001 16:28:07 -0000
>    From: "Didi" <flei@wanadoo.fr>
> Subject: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ?  STUP= ID GUY
>
>
> ----- Original Message -----
> From: "Didi" <flei@wanadoo.fr>
> To: <f-cpu@egroups.com>
> Sent: Sunday, January 07, 2001 4:17 PM
> Subject: [f-cpu] REMOVE
>
>
> >
> > ----- Original Message -----
> > From: "maurizio zoboli" <maurizio.zoboli@unimo.it>= ;
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 10:18 AM
> > Subject: [f-cpu] REMOVE
> >
> >
> > > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com = wrote:
> > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >telephone number and the
> > > >product or service you wish
> > > >to market. We will be in
> > > >touch with you shortly!
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Removal Instructions
> > > >****************************
> > > >To be removed from this list
> > > >please reply with "REMOVE"
> > > >in the subject.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Prof. Maurizio Zoboli
> > > Dipartimento di Scienze dell'Ingegneria
> > > Universita' di Modena e Reggio Emilia
> > > via Vignolese 905
> > > I-41100 Modena, Italy
> > > Tel.: +39 059 2056163
> > > Fax: +39 059 2056129
> > > e-mail: maurizio.zoboli@unimo.it
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 4
>    Date: Sun, 7 Jan 2001 11:39:35 EST
>    From: rvsicam@aol.com
> Subject: remove
>
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 5
>    Date: Sun, 07 Jan 2001 18:21:46 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: REMOVE
>
> hello,
>
> look at the header of the message, it contains :
> "List-Unsubscribe:  <mailto:f-cpu-unsubscribe@egroups.com= >"
>
> if you want to unsubscribe, sending messages to the list
> will not work. you have to send a message to the addresse copied
> above.
>
> although this should work, the egroups.com site mentions
> another address, please read the notice on the web.
>
> regards,
>
> maurizio zoboli wrote:
> <snip>
> >
> > Prof. Maurizio Zoboli
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 6
>    Date: Mon, 07 Jan 2001 20:50:06 +0100
>    From: Vanderhoeven Steve <vanderho@essi.fr> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
>
> > If you connect more than 2 CPU on the same bus, they compete for = the
ressource
> > and the bottleneck gets even narrow.
> >
>
> atm?
>
> steve
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 7
>    Date: Sun, 7 Jan 2001 22:38:27 +0100
>    From: "Marco Al" <marco@simplex.nl><= BR> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
>
> > Yann Guidon a =E9crit :
>
> > > if you target "small SMP" only, maybe you can do i= t with a shared bus,
> > > but don't expect wonders above 4 CPU. If you're doing CPU-on= ly tasks,
it's
> > > ok, but when you start to move things around, it's the real = mess.
> > > Intel sticks to this because the architecture is more or les= s stuck.
> > > they want cheap systems and make big profits, but still comp= ete (with
> > > some pain) in the SPEC contests.
> > >
> >
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
>
> You seem to presuppose that it wont have a single memory space with hardware
> maintained coherency... I dont mind, I like transputers. But a lot of<= BR> users of
> parallel systems disagree.
>
> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as
well,
> > > and it's my "hammer" argument when i try to promot= e point to point
links.
> > > We spare the (distributed) control logic (all the nasty dead= lock
stuffs etc)
>
>
> Thats one way of looking at it, the other way is that its a given that= L
has to
> be B*N' and that for N>N' you need extra hierarchies.
>
> And you wont get away from hierarchies, a single chip can only connect= to
so
> many processors and have so much backplane capacity. The control will<= BR> always be
> distributed at a certain point.
>
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU
wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real
> efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2
> dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same
but
> the
> > > address is split into 3 fields that are interpreted as an in= dependent
ring
> address.
>
> Exactly.
>
> My opinion also kind of depends on where the motherboard chipset
functionality
> would be present and how many pins that would need.
>
> I think making a bridge which can have a point-to-point/shared/ring connection
> to the processors which itself plugs into a socket-7 board (or perhaps=
even a
> PCI slot) is a good solution :) (bios should be local though, obviousl= y)
Getting
> a processor made, no matter how many frills you remove is a huge task.= .. I
think
> designing a motherboard chipset on top of that is an unnecessary burde= n.
You can
> always later replace the bridge with a true motherboard chipset.
>
> Marco
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 8
>    Date: Sun, 7 Jan 2001 22:46 +0000
>    From: jeff@llandre.freeserve.co.uk
> Subject: RE: Re: Re: 17. Chaos Communication Congress - Wie war ehr? >
> Regarding this rather strange multi cpu argument:
>
> 10 base t is not cutting edge, 1000 base t is.
> You can buy it off the shelf. full duplex via a switch,
> you can get 200 megabytes per second without compression
> between hosts. Obviously, multiple lan adaptors enable
> multiple segments to be used in parallel, and therefore
> it is quite easy to exceed the bandwidth of an sdram in this
> way (but rather pointless).
>
> smt as used by intel etc seems to share the whole of
> system ram between all cpus which is dumb.
> Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> but they also share the third sdram for comms.
>
> Not exactly a new idea, but much better than smt.
>
> All the multi cpu stuff is interesting but pointless. It
> doesnt change the core. Why not get back to that. We
> shouldnt waste whygee or michaels time, when they are
> doing so well with the vhdl.
> like someone said, shit happens, forget 17c3,
> success is the sweetest form of revenge.
> Once core is around, you multi cpu dudes can work on your
> own multiprocessors.
>
> Jeff Davies
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 9
>    Date: Sun, 7 Jan 2001 15:46:44 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote:
> [...]
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
>
> It depends.  If you use ccNUMA or COMA, there will be a lot of ad= ditional
> traffic to keep the caches up-to-date.  And if you're running cer= tain
> parallelized tasks with high communication overhead, even Gbps etherne= t
> becomes too slow.
>
> > > I am trying to find the "least common denominator"= for a F-CPU system
> > > that can range from 1 CPU to any arbitrary number of CPUs (j= ust like
> > > the register width : not bound to anything). let's take a fe= w cases,
> > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system"= should also scale
> > > to much more CPUs : the widest systems today (see the monter= s at the
LANL)
> > > can scale to more than 10K CPU, so let's round up to 65536.<= BR> > > >
> > > now let's compare the alternatives...
> > >
> > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it= 's
disastrous
> > > with more CPU.
> > >
> > > buses are known, used and they work, but some people here wa= nt a
"multimaster"
> > > bus. This means that the bandwidth is drawn by several point= s and the
bus
> > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per= CPU, equal
to
> > > the available bandwidth provided by the bus and divided by N= CPU).
> > >
> > > that's what i try to avoid.
>
> It's actually worse than B=3DL/N.  Don't forget the overhead for = bus
> arbitration and transfer direction turn-arounds.  I wouldn't be s= urprised
> at all if bandwidth drops below B=3DL/N/2.  If you want to come c= loser
> to B=3DL/N, you need to do large block transfers (unreasonable except = for
> mass storage access), and then you'll get problems with latencies (oth= er
> devices have to wait until the transfer is over and a new bus master > can be elected).  Another problem is that arbitration and turn-ar= ound
> times rise dramatically when the bus becomes longer (signal delay,
> bad impedance matching when tri-state drivers are used, and so on). >
> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as
well,
> > > and it's my "hammer" argument when i try to promot= e point to point
links.
> > > We spare the (distributed) control logic (all the nasty dead= lock
stuffs etc)
> >
> > There are always possible traffic Jam. How do you manage when 2 n= odes
> > try to speak to the same nod ? You have to manage something to av= oid
> > losing informations.
>
> They will have to share the available bandwidth.  The G-Chip will= have
> to queue the second message while it's sending the first one.  Th= is
> could be avoided by putting 4 F-Bus interfaces into the CPU itself
> (did anybody say "transputer"?), which makes the G-chip obso= lete
> except for peripheral I/O and message routing/switching, or by using a=
> faster (4x) link between F-CPU and G-chip.
>
> > > and it's very simple to implement. the PCB is simpler, too.<= BR> > > >
> > > If you connect more than 2 CPU on the same bus, they compete= for the
ressource
> > > and the bottleneck gets even narrow.
> > >
> >
> > Yes, but less drastically as intel SMP.
> >
> > > On the pin count vs bandwidth argument, it's similar. Of cou= rse, we
can find
> > > a lot of counter-examples and special cases, but the example= of the
broadcast
> > > is not the best one. Most of the requests are from one node = to a
single other
> >
> > In fact, not. It depend how much process communicate between them= . And
> > sometimes the only [simple] way to find a "moving" ress= ources is to send
> > a braodcast.
>
> Yep.  Very common when (simple) COMA is used, IIRC.
>
> > > and here, the efficiency of a bus drops dramatically ! for a= N-CPU
system,
> > > the efficiency is of 2 used bus interfaces for N bus interfa= ces (you
can
> > > replace "bus interface" with "pin"), 2/N= is similar to the 1/N scheme
> > > (if we speak about the "big O" or complexity). Thi= s means that :
> > > the more CPU, the least efficient ! you'll see that the best= way to
avoid
> > > this is by having as few CPU by link as possible, and the mi= nimum is
2.
> > > that's "point to point"...
> > >
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU
wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real
efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2
dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same
but the
> > > address is split into 3 fields that are interpreted as an in= dependent
ring address.
>
> A ring is actually much better than a bus because it is a unidirection= al
> device (no change of transfer direction, no tri-state buffers necessar= y,
> faster signalling) and arbitration is both simpler and faster (e.g. to= ken
> ring).  The members of the ring still share the available bandwid= th,
> but you come closer to B=3DL/N.  Per-CPU bandwidth is still limit= ed, though.
>
> > In the flight back to France, we have spoken about ring of ring.(= and
> > called the architecture the lord of the ring ;p). A ring is compo= sed
> > around 8 to 16 card (cpu+ram or IO). A card could be used to comm= unicate
> > with other ring. Maybe it's possible to grow in hierachy without = to much
> > trouble.
> >
> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6
neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant"
(through dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU
number).
> > >
> > So !
> [...]
>
> scales "perfectly" <EM>as long as the number of member= s per ring is
limited</EM>.
> Sorry for shouting ;)
>
> For highest-speed n-to-n communication, use direct connections.
> Since this doesn't scale at all, you need to find a compromise when > the number of CPUs increases -- switches or crossbars, trees or rings.=
> In any case, the solution depends on the work the system has to do. > With the drafted G-chip with 4 links, we could build
>
> - a 4-CPU directly-connected system
> - a single ring (double ring requires 5 links, 1 for CPU)
> - a binary or trinary tree (USB-style)
> - a flat hexagonal `beehive' structure
> - a cube
> - ...
>
> This is a pretty long list of options, isn't it?  Let the impleme= ntor (or
> system integrator) choose from this list; we don't have to care. = We just
> need to make sure that the G-chip is versatile enough to support at le= ast
> two or three of the most common topologies, and probably mixed topolog= ies
> (like a tree or ring of directly-connected clusters, for example).
> Preferably with auto-sensing capabilities =E0 la USB, i.e. the structu= re
> is determined at run (or boot) time.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 10
>    Date: Mon, 8 Jan 2001 01:00:11 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ?  = STUPID GUY
>
> On Sun, Jan 07, 2001 at 04:28:07PM -0000, Didi wrote:
> >
> > ----- Original Message -----
> > From: "Didi" <flei@wanadoo.fr>
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 4:17 PM
> > Subject: [f-cpu] REMOVE
> >
> >
> > >
> > > ----- Original Message -----
> > > From: "maurizio zoboli" <maurizio.zoboli@unimo.= it>
> > > To: <f-cpu@egroups.com>
> > > Sent: Sunday, January 07, 2001 10:18 AM
> > > Subject: [f-cpu] REMOVE
>
> Interesting how many people read this list but never say something. >
> On the other hand, these dumbheads who are unable to read headers
> and quote the whole spam just to say "remove" to the wrong p= erson(s)
> (or even quote the replies, like in this case) are worse than spammers= :(
>
> Guys, you have a brain.  PLEASE USE IT.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 11
>    Date: Sun, 7 Jan 2001 17:21:06 -0700 (MST)
>    From: Keyshaun <thekernel@subdimension.com> > Subject: Re: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ?  = STUPID GUY
>
> I must say that I am often one of the people who has little to say.&nb= sp; I
> just find the discussion of hardware design to be quite interesting.&n= bsp; On
> another note I almost responded to f-CPU with REMOVE in the subject. > Other than that I think you guys are doing great work, though I must s= ay
> that for a CPU project it's amazing how much is focused away from the<= BR> > processor.  Things like the G-Chip seem like they should branch i= nto their
> own seperate but related project.  Keep it simple, if I were tryi= ng to
> design something I would probably consider discarding the G-Chip as > bloatware for anything other than SMP.  The F-CPU looks great to = me, I
> would love to use it.  I would contribute skill to the project if= I had
> it.  Because I don't I must sit back and enjoy learning from the<= BR> > discussions I read.  None the less my big point I have ended up g= oing into
> is this...  It is the Freedom CPU project not the Freedom SMP app= lication
> system project.  Keep a good focus and more will get done.  = When a CPU is
> ready the solutions to SMP and anything else you want to do will play<= BR> > themselves out.
>
> Shaun Kruger
> thekernel@subdimension.com
>
> > Interesting how many people read this list but never say somethin= g.
> >
> > On the other hand, these dumbheads who are unable to read headers=
> > and quote the whole spam just to say "remove" to the wr= ong person(s)
> > (or even quote the replies, like in this case) are worse than spa= mmers
:(
> >
> > Guys, you have a brain.  PLEASE USE IT.
> >
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> >
> >
> >
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 12
>    Date: Mon, 8 Jan 2001 01:35:28 +0100
>    From: "Marco Al" <marco@simplex.nl><= BR> > Subject: Re: Re: Re: 17. Chaos Communication Congress - Wie war ehr? >
> From: <jeff@llandre.freeserve.co.uk>
>
> > smt as used by intel etc seems to share the whole of
> > system ram between all cpus which is dumb.
> > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> > but they also share the third sdram for comms.
>
> IMO thats combining the bad aspects of NUMA and message passing combin= ed
in a
> single framework...
>
> > Once core is around, you multi cpu dudes can work on your
> > own multiprocessors.
>
> It doesnt have to, if you dont mind have suck ass performance in a sha= red
memory
> space multiprocessor system (which is ok, for most processors
multiprocessor
> setups are at best an afterthought... allows people like Cray etc to m= ake
some
> money with custom hardware to maintain coherency, although in this cas= e
adding
> that kind of functionality afterwards would be neigh impossible with t= he
direct
> memory interface).
>
> If you want to make a processor which can scale decently in multiproce= ssor
> setups you have to know which scheme you will be using at least in tim= e
for the
> design of the MMU.
>
> Marco
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 13
>    Date: Sun, 07 Jan 2001 19:39:32 -0500
>    From: Alan Grimes <alangrimes@starpower.net> > Subject: This project really sucks.
>
> =3DP
>
> om   (I'm invincible!)
>
> Hey, you morons, whomever thinks he is running this project is doing a= n
> absolutly, unforgivably, horrible job. If you were, say, working for a=
> company and were working in a well-managed tightly optomized R&D t= eam,
> you guys would be briliant. BUT YOU'RE NOT!!!
>
> In a private company you have the luxury of closed-door face2face
> meetings where you can get a lot done. But, for an internet project su= ch
> as this, that is totally inadqiquate. You must keep and maintain a
> current website...  oops! I *thought* it was f-cpu.tux.org (which= should
> be updated or deleted.). For the ammount of traffic on the list,
> f-cpu.org is also stale, so my point holds, though not as strongly.. = =3D\
>
> An project, such as what this one pretends to be, must provide an easy=
> "on-ramp" for people who are new to the project to become ac= tive
> participants. Such consessions to the newbies must include:
>
> in order of importance:
>
> - A glossary.
> - A reading list.
> - A document/source managment system. that is easily accessable to any=
> reasonable web browser.
> - A job managment system that can manage tasks and bugs from proposal<= BR> > to retirement.
>
>
> The point I am trying to make here is that I have been on the list for=
> two and a half years and I can't even say for certain what the status = of
> the project is or wheather we have reached any "milestones".= I am really
> frustrated by the apparent lack of progress. I need a gnu machine! =3D= P
>
> I therefore make the following demands:
>
> - A Czar or voting comission with a fixed registered membership must b= e
> appointed or elected for the sole purpose of approving contributions t= o
> the document/source managment system with the objective of focusing th= e
> efforts of the group towards the completion (*ghasp*) and delivery of = a
> product to market.
>
> - A formal contributor development system, like what you would find in= a
> company, that will provide training or mentoring to aspiring
> contributors.
>
> - The founding of an American branch of the apparently extant french > F-CPU orgainization. This is in recognition that local groups work
> better.
>
>
> Really, This project serves me only when it yields something that is > useful. Failing that it can go to hell...
>
> I will see what happens over the next two months and then go bug the > opencore people some more, and perhaps work up a project over there. >
> --
> The 'apocolypse' happened in 1848.
> Now if everybody would only just look... =3D\
> http://users.erols.com/= alangrimes/  <my website.
>
> Unsolicited "spam" messages to this account are subject to u= sage fees
> and
> in cases of fraud or egregeous abuse, prosecution.
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 14
>    Date: Mon, 8 Jan 2001 02:02:09 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: This project really sucks.
>
> On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:
> [...]
> > The point I am trying to make here is that I have been on the lis= t for
> > two and a half years and I can't even say for certain what the st= atus of
> > the project is or wheather we have reached any "milestones&q= uot;. I am really
> > frustrated by the apparent lack of progress. I need a gnu machine= ! =3DP
>
> You should learn how to read.  Or contribute.  Or shut up. >
> > I therefore make the following demands:
>
> Demands?  F*ck off.  You have no right to demand *anything*.=
>
> [...]
> > Really, This project serves me only when it yields something that= is
> > useful. Failing that it can go to hell...
>
> Don't ask what this project can do for you,
> ask what YOU can do for the project.
> (misquoting John F. Kennedy, IIRC)
>
> > I will see what happens over the next two months and then go bug = the
> > opencore people some more, and perhaps work up a project over the= re.
>
> Fine.  Better go NOW and start bugging somebody else.
>
> This attitude makes me sick...
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 15
>    Date: Sun, 07 Jan 2001 20:32:11 -0500
>    From: Alan Grimes <alangrimes@starpower.net> > Subject: Re: This project really sucks.
>
> Michael Riepe wrote:
> > You should learn how to read.
>
> I can read anything that is within the reach of a highschool graduate<= BR> > and a fair ammount of mathematical and technical stuff to... As I
> mentioned in my post, there is little to suggest WHAT I should read, > unless you want me to spend the rest of my life reading crap untill I<= BR> > finally hit on something that is relevant... It took me fully eighteen=
> months of applying that self same process to learning how linker-loade= rs
> work. I literally had NO CLUE. Now its all perfectly clear to me. The<= BR> > position I am taking is that I have no intention of repeating that
> process.
>
> > Or contribute.
>
> I can't, for the reasons that I attempted to explain in my last postin= g.
> READ IT.
>
> > Or shut up.
>
> Pleas understand that I am running Windows 3.11 on an Athalon processo= r.
>
> The PC is far too fucked for me to write my own OS. (I have discovered=
> this through great labor). But I *can* write an OS for F-cpu (I hope).=
>
> I am hurting.
>
>  In a year or so I won't be able to get anything done on the net = at
> all... I will be profoundly fucked. "Shutting up" is not a v= ery good
> option for me, now is it?
>
>
> > > I therefore make the following demands:
> >
> > Demands?  F*ck off.  You have no right to demand *anyth= ing*.
>
> Maybe not. But the fact that you can't take an ounce of criticism with=
> regards to this project is equally un-cool. I have been observing this=
> project practicaly from day one. I have seen many things not happen. ;= )
> This posting was my attempt to encapsulate all the observations I made=
> into a single simple workable agenda for making things happen. If you<= BR> > can't take it then go work for a company, you have nothing valuble to<= BR> > contribute to an open-source project if you canot accept contributions= .
>
>
> > [...]
> > > Really, This project serves me only when it yields something= that is
> > > useful. Failing that it can go to hell...
> >
> > Don't ask what this project can do for you, ask what YOU can do f= or the
> > project. (misquoting John F. Kennedy, IIRC)
>
> Read my fucking posting before making brainless comments like this. It=
> really shows me that you can't think one wit beyond your VHDL (or
> whatever) compiler to see that other people can hardly understand what=
> it is you are doing. THEN you will realize that this posting WAS a
> contribution. It contributed the observation that people such as mysel= f
> are essentially left-out of the project *and* it proposes a concise an= d
> understandable method for remedying the situation. If you would like t= o
> give me some permissions over at the sourceforge project then I will > apply suggestions and my training in project managment towards achievi= ng
> actual results.
>
> I am sorry that linux users tend to be so goddamned dense that they > can't see or accept a simple and logical suggestion even when it is > explained to them!  No wonder their operating system is as terrib= le as
> it is...
>
>
> > > I will see what happens over the next two months and then go= bug the
> > > opencore people some more, and perhaps work up a project ove= r there.
> >
> > Fine.  Better go NOW and start bugging somebody else.
>
> Hey! Wanna make a CPU?  I not only can but I will make it happen.= This
> is what needs to be done.
>
> > This attitude makes me sick...
>
> So does yours.
>
> I must appologise, I shouldn't have jumped as hard as I did but I do > really feel a lot of frustration with this...
>
> --
> The 'apocolypse' happened in 1848.
> Now if everybody would only just look... =3D\
> http://users.erols.com/= alangrimes/  <my website.
>
> Unsolicited "spam" messages to this account are subject to u= sage fees
> and
> in cases of fraud or egregeous abuse, prosecution.
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 16
>    Date: Mon, 8 Jan 2001 03:37:48 +0200
>    From: "Iancu Silvius" <silvius@mail.dnt= tm.ro>
> Subject: REMOVE
>
>
> ----- Original Message -----
> From: <f-cpu@egroups.com>
> To: <f-cpu@egroups.com>
> Sent: Sunday, January 07, 2001 12:43 PM
> Subject: [f-cpu] Digest Number 240
>
>
> > There are 5 messages in this issue.
> >
> > Topics in this digest:
> >
> >       1. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: "Marco Al" <marco@simplex.nl>
> >       2. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: Nicolas Boulay <nicolas.boulay@ifrance.com>
> >       3. IT'S HERE..
> >           = From: bethweinstein@yahoo.com
> >       4. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: Yann Guidon <whygee@f-cpu.org>
> >       5. REMOVE
> >           = From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 1
> >    Date: Sat, 6 Jan 2001 18:49:49 +0100
> >    From: "Marco Al" <marco@simplex.nl= >
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > From: "Yann Guidon" <whygee@f-cpu.org>
> >
> >
> > > talk about a monodirectional synchronous parallel (byte ?) > > > bus with some control signals, a clock (dual edge ?) and it'= s ok for
> > > me, whatever your idea is. Anybody can implement that with a=
> > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> >
> > Is LVDS usually in the standard cell libraries? If you want to ha= ve the
> option
> > of using cables its IMO the clear choice, together with source synchronous
> > clocking of course (chips will probably still share clocks, ie be=
> synchronous,
> > the source clock is just to deal with the delay's at high signall= ing
> speeds over
> > long wires). There is AFAICS a pretty clear consensus in the indu= stry
that
> its
> > is the way forward for backplanes too. And there are plenty of TT= L
> interface
> > chips on the market, plus some FPGA support, so no worries there.=
> >
> > I still like a shared bidirectional (B-LVDS) bus using
> repeaters/bridges/routers
> > for scalability. In other words the Intel way, the AMD party line= swung
me
> too
> > for a while... but now I dont think point to point busses use the=
> resources
> > (pin's and system cost) most effectively. The only way to
proove/disproove
> that
> > IMO is to model both alternatives, but Im both too lazy and I don= t have
> the
> > necessary knowledge (AFAICS I would need to know feasibly physica= l
> bandwith per
> > pin in point to point and bus setups, and have a good traffic bre= akdown
> for
> > multiprocessor setups) .With a lot of broadcast traffic I just do= nt
think
> the
> > effective bandwith per pin of a point to point bus compares favou= rably,
> let
> > alone the extra costs and latency of the routing chips for small = SMP
> setups.
> >
> > Marco
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 2
> >    Date: Sun, 07 Jan 2001 00:35:43 +0100
> >    From: Nicolas Boulay <nicolas.boulay@ifrance= .com>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > Hi,
> >
> > Yann Guidon a =E9crit :
> > >
> > > hi,
> > >
> > > Nicolas Boulay wrote:
> > > > hi,
> > > >
> > > > Yann Guidon a =E9crit :
> > > > > > The network will made around
> > > > > > gigabit ethernet link (the electrical part) b= ecause it's well
> known (and
> > > > > > free ? ). With 8 ethernet links, we can reach= the true
gigabytes.
> This
> > > > > > made around 8*2*2*2 (2 pairs with 2 ways and = 2 time 500Mhz) pins
> for a
> > > > > > multidirectionnal link, very few in fact ! > > > > > you forget several things... no chip can do 8xGb l= inks. you forget
> the ground
> > > > > connexions in the backplane. This backplane is goi= ng to be
extremely
> expensive,
> > > > > and i doubt that a "f-cpu hacker" can af= ford a 30-layer PCB made
> with Teflon.
> > > > > the idea of the ethernet is simply science fiction= .
> > > >
> > > > Oups, i omit to say for reduice the cost that i would l= ike to try to
> > > > have only one chip and avoid many differents chips. So = the 8 links
wil
> l
> > > > be "inside" the fcpu chip. This is the main s= ystem bus.
> > >
> > > hum, hum... just a reminder : the SiO2 process is not much t= he same
> > > for a CPU and a tranceiver. you CAN't put it on the same die= ...
> > >
> >
> > I don't think that you know about what you speak ! New silicon pr= ocess
> > are silicium on insulator, soon used by IBM for there udge proces= sor for
> > mainfrain (a little beast with 35 ppc on the same die). And now, = for the
> > next powerG3. Next, the SiGe are new process used to have
> > hyperfrequencies, or mixed analogue and digital part. But then, i= t could
> > be used for very quick digital circuit.
> >
> > And, for information, gigabit ethernet need 500 Mhz. So, "us= ual process"
> > are must enought to make a tranceiver.
> >
> > > > The 8 ethernet link could be say has 2 one-way gigabyte= links. So,
if
> > > > you use a ring, you need 2 of this links (one by ring).= So you will
> only
> > > > need a 1 layer PCB !
> > > beep. wrong. gigabit ethernet, or any ethernet, requires a v= ery
special
> > > medium to propagate. the shield, the impedence adaptation, t= he
diameter,
> > > the propagation, etc. are more or less taught in the IUT or = ingenieur
> school.
> >
> > A=EFe ! You just have to respect electrical rules of the gigabit = ethernet
> > (L and C).
> >
> > > they're a lot of formula etc, so you can't simply draw a lin= e and say
> "ok".
> > > it can't be so. otherwise, network cables would be much chea= per.
> > > have you heard about "Cat. 5" cables ? did you won= der why it was more
> >
> > You have never learn that this kind of cable could be around 50 m= eter
> > long ! Here 1 or 2 meters is much enought !
> >
> > > expensive than other cables ? Plus, you'll need very special=
> connectors...
> > > the usual cheap connectors are not adapted at all.
> > >
> > > > > > compare to the normal usual
> > > > > > parrallel bus (for a link at 133 Mhz compare = to the >500 Mhz for
> the
> > > > > > giga ethernet link and without to many routin= g problem with long
> wires).
> > > > > i compare what can be compared.
> > > > > the current idea is simply not realistic.
> > > > Yes, the idea that you have understood, not mine !
> > >
> > > talk about a monodirectional synchronous parallel (byte ?) > > > bus with some control signals, a clock (dual edge ?) and it'= s ok for
> > > me, whatever your idea is. Anybody can implement that with a=
> >
> > Fast clock one large network, you have to deal with clock skew. M= ost of
> > the time, each founder (ST microelectronics, TSMC, infineon,...) = have a
> > macro cell to do gigaethernet and do all the hard things (serial,=
> > deserials).
> >
> > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > >
> >
> > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL signify= 5V and
> > some nF of charge. I don't want to repeat it each time.
> > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow compa= re to
> > usual system.
> > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or around = 300 Mhz
> > with DDR or more with QDR. With LVDS, you can reach around 600 Mh= z by
> > pin. BUT you can't really add a connector between 2 pins at that = speed.
> >
> > My choice is to have a quick link (performance are our goal, isn'= t it
> > ?). Then you just had to provide a bridge between the quick link = and a
> > SRAM like bus. I think that could be easy : Just a link like for = the
> > fcpu and a little glue for the interface.
> >
> > > now you're asynchronous, you have to deal with PLL and clock=
> > > recovery, hyperfrequencies, signal integrity, skew, etc... > > > that a lot of troubles for almost nothing.
> > >
> >
> > Not at all ! because you deal with macrocell and all the suft are= soon
> > made.
> >
> > > you want speed ? put the wires in parallel, don't serialize = the
bits...
> > >
> >
> > Yes, but the limit are the number of pin and the prices ! And the= n you
> > alwas have the speed of the clock with LVDS, you always have the<= BR> > > electrical and speed problem.
> >
> > > > > i want a draft, numbers, several case studies, fea= sibility
studies,
> > > > > the reference of the used parts, the protocol, the= VHDL...
> > > >
> > > > Yeah, yeah, the bear and the bear's skin ;p
> > >
> > > i'm just putting the pressure on your shoulders.
> > > i'd like to see where your seriousness ends...
> > >
> > > > > > Each cpu will have a full 128 bits wide bus f= or DDR-SDRAM and
> "some"
> > > > > > gigabit ethernet links for system communicati= on. Then you can
> connect
> > > > > > the cpu or a IO sub-system for ide/scsi bus, = usb, rs232 ...
> > > > >
> > > > > i don't care about this side. you're simply going = into a lot of
> troubles.
> > > >
> > > > In fact, it should.
> > > "should" what ?
> > >
> > > > In usual core, you have simple bus and it's easy to
> > > > put rom or eeprom to boot. But here, you need something= more special
> to boot.
> > > and who will build that ? do you have the spare parts somewh= ere ?
> > >
> >
> > "spare part", i don't understand. One day, you say you = want performance,
> > the other days somthing so slow to be compatible with TTL. I don'= t
> > understand you...
> >
> > > > > one way to realize this is by searching the parts = on the catalogs
or
> databases.
> > > > > one connector is going to cost as much as the f-cp= u chip. One
> backplane
> > > > > will cost 100KF to prototype. it's not a "hac= ker's architecture".
> > > >
> > > > Ben, non...
> > > >
> > > ok, now we're going to agree on something...
> > >
> > > start with something simple and that works with easy-to-find= parts.
> > >
> > > > > > The "delicat" part is : what taken = as network ? Everybody knows
> that i
> > > > > > prefer a double ring. Double to make a failur= e revovery (to plug
> and
> > > > > > replug one card without shutting down the sys= tem). And its easy
to
> > > > > > expand wihtout having any routing problems. R= outing is a problem
> for
> > > > > > latency and complexty of the nod. But this ne= eds much more
> explication.
> > > > > routing is not a problem. the routing algorithms a= re known for a
> long time
> > > > > and there's already a large variety of choices. > > > >
> > > > Have you a link for a preditive routing algorithme ? I = think that my
> > > > collegue which make a thesis about real time network wi= ll be very
> > > > interrested to know that exist.
> > >
> > > the routing stuff is taught during the DEUG at Paris 8 unive= rsity.
> > > ask Amal Stri from the transversal department.
> > >
> > > When at Boston, in a (expensive) library, i found (but didn'= t buy)
> > > a VERY cool about the T3E and similar architectures. The rou= ting
> > > algos are rather simple and very efficient.
> > >
> >
> > I seriously doubt about the complexity and the scalability...
> >
> > > > > > Everybody should stay calm ! We need everybod= y.
> > > > > yep. F-CPU didn't appear in one day.
> > > > >
> > > > > anyway, the debate has shifted very far from the i= nitial
> > > > > requirement, and it's rather off-topic. What we ne= ed is a simple
> > > > > parallel interface to connect the F-CPU to the G-c= hip and other
> > > > > G-chips. Since they're on the same PCB, we don't n= eed hotswap.
> > > >
> > > > If we made a simple core (like ARM), we don't need g-sh= ip and all
that
> crap.
> > > not true. ARM chips require I/O chips. Unless you buy the sy= nthesised
> core,
> > > and implement it in the middle of a sea-of-gates ASIC with y= our
prefered
> I/O.
> > >
> >
> > One more times, you don't unsderstand ! i propose like leon, just= to
> > develope the fc0 (the core) and let other gays to use it.
> >
> > > ARM, just like any chip, requires a memory controller and I/= O.
> > > look at the Crystal Semiconductors catalog... they have all = the parts
> > > necessary to make a PDA or laptop PC.
> > >
> > > > If we made a processor ("a system") we should= consider to have
> > > > fault tolerance capabilities. And hot swap is the basis= !
> > > not necessarily. fault detection and bypass are a SW matter,=
> > > with the help of some HW (ECC/SEC). but the rest is purely a= n
electrical
> > > problem.
> > >
> >
> > Not really, i don't speak about fault detection but failure toler= ant (a
> > single dead card don't stop the all system, you just have to chan= ge it).
> >
> > > some designs that you should investigate (using several diff= erent
books,
> > > saying different stuffs) : T3D/E (it's a 3D torus with ALPHA= s at the
> nodes),
> > > CM1 (12-cube with extremely simple routing), CM5 (fault tole= rance,
"big
> tree"
> > > network, message passing communication etc.), SGI/SUN/HP sca= lable
> computing nodes
> > > (i found the Convex (circa 1995) very interesting, but Conve= x is now
> owned by HP).
> > >
> >
> > Just for information : how much for a single chip ? And how much = heat
> > for a chip ? You try to give some piece of your knowledge but you= don't
> > understand the "simple coma" from SUN for their last sy= stem (from an URL
> > given on the list), so ?
> >
> > > i know, it's a matter of culture...
> > >
> >
> > I just see it's like jam, ...
> >
> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 3
> >    Date: Sat, 06 Jan 2001 22:31:11 -0500
> >    From: bethweinstein@yahoo.com
> > Subject: IT'S HERE..
> >
> > Expand your business with
> >     Email Marketing!
> >
> > Market your product or service
> >      to MILLIONS!
> >
> > Don't waste another minute...
> >
> > Click Reply with your name,
> > telephone number and the
> > product or service you wish
> > to market. We will be in
> > touch with you shortly!
> >
> >
> >
> >
> >
> > Removal Instructions
> > ****************************
> > To be removed from this list
> > please reply with "REMOVE"
> > in the subject.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Expand your business with
> >     Email Marketing!
> >
> > Market your product or service
> >      to MILLIONS!
> >
> > Don't waste another minute...
> >
> > Click Reply with your name,
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 4
> >    Date: Sun, 07 Jan 2001 04:32:50 +0100
> >    From: Yann Guidon <whygee@f-cpu.org>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > hi !
> >
> > Marco Al wrote:
> > > From: "Yann Guidon" <whygee@f-cpu.org>
> > > > talk about a monodirectional synchronous parallel (byte= ?)
> > > > bus with some control signals, a clock (dual edge ?) an= d it's ok for
> > > > me, whatever your idea is. Anybody can implement that w= ith a
> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > >
> > > Is LVDS usually in the standard cell libraries? If you want = to have
the
> option
> > > of using cables its IMO the clear choice, together with sour= ce
> synchronous
> > > clocking of course (chips will probably still share clocks, = ie be
> synchronous,
> > > the source clock is just to deal with the delay's at high si= gnalling
> speeds over
> > > long wires). There is AFAICS a pretty clear consensus in the= industry
> that its
> > > is the way forward for backplanes too. And there are plenty = of TTL
> interface
> > > chips on the market, plus some FPGA support, so no worries t= here.
> >
> > yup. Even though it's not the "hottest" stuff around (c= ompared to
> > optical fibers, I2C and mental waves), it works, it's very well > understood,
> > it's widely spread... and it's not over expensive (accessibility = of the
> > technology vs price vs performance vs...)
> >
> > > I still like a shared bidirectional (B-LVDS) bus using
> repeaters/bridges/routers
> > > for scalability. In other words the Intel way, the AMD party= line
swung
> me too
> > > for a while...
> > after a few months playing with the idea of two unidirectional bu= ses
> ("full-duplex",
> > even though the bandwidth is halved) i feel that it is not a bad = idea at
> all.
> > No arbitration, few synchronisation, very low complexity... i lik= e it
:-)
> >
> > > but now I dont think point to point busses use the resources=
> > > (pin's and system cost) most effectively.
> > it depends on your criteria. low pin count ? price ? speed ? band= width
> ?...
> > and also on your needs and "budget".
> >
> > > The only way to proove/disproove that
> > > IMO is to model both alternatives, but Im both too lazy and = I dont
have
> the
> > > necessary knowledge (AFAICS I would need to know feasibly ph= ysical
> bandwith per
> > > pin in point to point and bus setups, and have a good traffi= c
breakdown
> for
> > > multiprocessor setups) .With a lot of broadcast traffic I ju= st dont
> think the
> > > effective bandwith per pin of a point to point bus compares<= BR> favourably,
> let
> > > alone the extra costs and latency of the routing chips for s= mall SMP
> setups.
> >
> > well, there's the architecture side here...
> >
> > if you target "small SMP" only, maybe you can do it wit= h a shared bus,
> > but don't expect wonders above 4 CPU. If you're doing CPU-only ta= sks,
it's
> > ok, but when you start to move things around, it's the real mess.=
> > Intel sticks to this because the architecture is more or less stu= ck.
> > they want cheap systems and make big profits, but still compete (= with
> > some pain) in the SPEC contests.
> >
> > I am trying to find the "least common denominator" for = a F-CPU system
> > that can range from 1 CPU to any arbitrary number of CPUs (just l= ike
> > the register width : not bound to anything). let's take a few cas= es,
> > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system" shou= ld also scale
> > to much more CPUs : the widest systems today (see the monters at = the
LANL)
> > can scale to more than 10K CPU, so let's round up to 65536.
> >
> > now let's compare the alternatives...
> >
> > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it's disastrous
> > with more CPU.
> >
> > buses are known, used and they work, but some people here want a<= BR> > "multimaster"
> > bus. This means that the bandwidth is drawn by several points and= the
bus
> > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per CPU,= equal to
> > the available bandwidth provided by the bus and divided by N CPU)= .
> >
> > that's what i try to avoid.
> >
> > Clearly, this B=3DL/N is a thing that i try to avoid for other th= ings as
> well,
> > and it's my "hammer" argument when i try to promote poi= nt to point
links.
> > We spare the (distributed) control logic (all the nasty deadlock = stuffs
> etc)
> > and it's very simple to implement. the PCB is simpler, too.
> >
> > If you connect more than 2 CPU on the same bus, they compete for = the
> ressource
> > and the bottleneck gets even narrow.
> >
> > On the pin count vs bandwidth argument, it's similar. Of course, = we can
> find
> > a lot of counter-examples and special cases, but the example of t= he
> broadcast
> > is not the best one. Most of the requests are from one node to a = single
> other
> > and here, the efficiency of a bus drops dramatically ! for a N-CP= U
system,
> > the efficiency is of 2 used bus interfaces for N bus interfaces (= you can
> > replace "bus interface" with "pin"), 2/N is s= imilar to the 1/N scheme
> > (if we speak about the "big O" or complexity). This mea= ns that :
> > the more CPU, the least efficient ! you'll see that the best way = to
avoid
> > this is by having as few CPU by link as possible, and the minimum= is 2.
> > that's "point to point"...
> >
> >
> > Now, another stuff. Nico usually wants a ring. It's "simple = to route",
> > it's fun and doesn't need much "efforts". But there is = still the same
> > problem as before : the more CPU, the less bandwidth when one CPU= wants
> > to talk to another. 1/N (or 2 pins / N CPU if you want the "= real
> efficiency").
> > The solution is rather easy : you have to expand that to the othe= r 2
> dimensions,
> > hence the "CRAY T3D" and the extension, T3E. Routing is= still the same
but
> the
> > address is split into 3 fields that are interpreted as an indepen= dent
ring
> address.
> >
> > here, you don't have 1 ring but x*y*z rings. It means that there = is
> > no bandwidth problem at all, because each CPU communicates with i= ts 6
> neighbours.
> > It works very well, it can be tweaked to become "fault toler= ant"
(through
> dynamic
> > node addresses) and scales perfectly (almost linearly with the CP= U
> number).
> >
> > So if you want the simplest system, you have 1 CPU with no ring,<= BR> > > and when you scale up, add a few links when needed and use like &= quot;lego
> bricks"
> > in a cubic connexion.
> >
> > I think that the G-chip was an easy way to make the topology
> reconfigurable
> > by the user/implementor. If we provide the brick, the user will m= ake a
lot
> > of stuffs, but if we restrict the choices, the scalability and th= e
> flexibility
> > will suffer.
> >
> >
> > > Marco
> >
> > Nicolas Boulay wrote:
> > >
> > > Hi,
> > >
> > > Yann Guidon a =E9crit :
> > > >
> > > > hi,
> > > >
> > > > Nicolas Boulay wrote:
> > > > > hi,
> > > > >
> > > > > Oups, i omit to say for reduice the cost that i wo= uld like to try
to
> > > > > have only one chip and avoid many differents chips= . So the 8 links
> will
> > > > > be "inside" the fcpu chip. This is the m= ain system bus.
> > > >
> > > > hum, hum... just a reminder : the SiO2 process is not m= uch the same
> > > > for a CPU and a tranceiver. you CAN't put it on the sam= e die...
> > >
> > > I don't think that you know about what you speak ! New silic= on process
> > > are silicium on insulator, soon used by IBM for there udge p= rocessor
for
> > > mainfrain (a little beast with 35 ppc on the same die).
> > duh. and how will you ask IBM to make your chip ?
> > it's not something that everybody can do. it's not free, it's exp= ensive
> > and it's not connectable to anything...
> >
> > > And now, for the next powerG3. Next, the SiGe are new proces= s used to
> have
> > > hyperfrequencies, or mixed analogue and digital part. But th= en, it
could
> > > be used for very quick digital circuit.
> > It is. but how many people would use such a chip ? what can they = connect
> it to ?
> > how will you "solve" the RF issues ? Do you know how di= fficult it is to
> route
> > a 50 MHz signal ? So who will buy you the SW needed to design a R= F PCB ?
> >
> > > And, for information, gigabit ethernet need 500 Mhz. So, &qu= ot;usual
process"
> > > are must enought to make a tranceiver.
> > Maybe you should stop to use the term "ethernet". If it= 's a simple
> > "serial link", you're just making a firewire clone... > >
> > > > > The 8 ethernet link could be say has 2 one-way gig= abyte links. So,
> if
> > > > > you use a ring, you need 2 of this links (one by r= ing). So you
will
> only
> > > > > need a 1 layer PCB !
> > > > beep. wrong. gigabit ethernet, or any ethernet, require= s a very
> special
> > > > medium to propagate. the shield, the impedence adaptati= on, the
> diameter,
> > > > the propagation, etc. are more or less taught in the IU= T or
ingenieur
> school.
> > > A=EFe ! You just have to respect electrical rules of the gig= abit
ethernet
> > > (L and C).
> > that's a pretty quick simplification. even though at your level i= t fits,
> > when you make the PCB it takes another dimension ...
> >
> > > > they're a lot of formula etc, so you can't simply draw = a line and
say
> "ok".
> > > > it can't be so. otherwise, network cables would be much= cheaper.
> > > > have you heard about "Cat. 5" cables ? did yo= u wonder why it was
more
> > > You have never learn that this kind of cable could be around= 50 meter
> > > long ! Here 1 or 2 meters is much enought !
> > and you think that it's not the same problem ????
> > have you heard about Xtalk and such stuff ? you CAN't make it wit= h a
> 1-layer PCB.
> > you need at least 3 layers to make a decent transmission line
> > (shield/insulator/signal/insulator/shield). And depending on your=
signal's
> > characteristics, you have to change the dimensions of the tracks,=
> > so they are adapted to the thickness of the PCB and the permeabil= ity of
> > the insulator (if it's epoxy or teflon or something else).
> >
> > Whether the wire is 50m or 1m, the problem is the same...
> >
> > > > > > i compare what can be compared.
> > > > > > the current idea is simply not realistic.
> > > > > Yes, the idea that you have understood, not mine !=
> > > > talk about a monodirectional synchronous parallel (byte= ?)
> > > > bus with some control signals, a clock (dual edge ?) an= d it's ok for
> > > > me, whatever your idea is. Anybody can implement that w= ith a
> > > Fast clock one large network, you have to deal with clock sk= ew.
> > it's an old known problem and there are some old known solutions.=
> > ever heard about a "clock tree" ?... if you have a good= architecture,
> > you don't have skew troubles.
> >
> > > Most of the time, each founder (ST microelectronics, TSMC, infineon,...)
> > > have a macro cell to do gigaethernet and do all the hard thi= ngs
(serial,
> > > deserials).
> > and you'll by the components ? come on...
> > and please, don't talk about "Ethernet", it seems like = it's
> > only a serial point to point link (if i remember one of your mess= ages).
> >
> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL si= gnify 5V
and
> > > some nF of charge. I don't want to repeat it each time.
> > hey, i'm not dumb, i know that TTL is slow. thanks.
> >
> > but just a question : how will you debug your stuff ? will you us= e
> > a 10GS/s logic analyser ? with a simple enough protocol, i can > > debug the interface with "off the shelf parts" that i c= an solder at
will,
> > the old school way, just like any "hacker".
> >
> > Then, when it's developped, you only have to change the electrica= l
> > levels (that is : the pin's driving gates) and you can do LVTTL o= r
> whatever
> > high-speed connexion. it's just a matter of changing the electric= al
spec.
> > Yes i want speed, but a "hacker" needs a way to see wha= t happens without
> > the need of extremely expensive devices. by clocking the chip slo= wer
> > and adapting the electrical level (with the adapted buffers or > transmitters),
> > you can hook anything to the F-BUS.
> >
> > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow = compare to
> > > usual system.
> > this kind of speed is used for I/O with maybe a controller or som= ething
> > like that. When i speak about "TTL parts", it's somethi= ng like a 8255
> > or any very slow byte-based I/O chip. just like during the old da= ys
> > of the 8-bit systems...
> >
> > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or ar= ound 300 Mhz
> > > with DDR or more with QDR. With LVDS, you can reach around 6= 00 Mhz by
> > > pin. BUT you can't really add a connector between 2 pins at = that
speed.
> > then it must be soldered. but then, this speed is not required fo= r
> > handcrafting your own I/O board on a pre-drilled PCB. do you know= a
mouse
> > or a keyboard or even a LCD screen that requires 600M x N pins of= data
> > per second ?
> >
> > Scalability means scale-down and scale-up. 500Mbps is fine, but w= hen you
> > don't need that much, it's an overkill. And you propose to make a= n
adapter
> > that will bother of the I/O, but how many custom chips will you r= equire
> > to interface your connexion to any other stuffs ? Having a simple= and
> > one-fits-all protocol that does low and high-speed helps reduce t= he
> > number of different chips and interfaces...
> >
> > > My choice is to have a quick link (performance are our goal,= isn't it
> ?).
> > not only. In the design goals of the F-CPU, there are 3 other stu= ffs.
> >
> > > Then you just had to provide a bridge between the quick link= and a
> > > SRAM like bus. I think that could be easy : Just a link like= for the
> > > fcpu and a little glue for the interface.
> > i'll give you the honnor of doing the first one...
> >
> > > > now you're asynchronous, you have to deal with PLL and = clock
> > > > recovery, hyperfrequencies, signal integrity, skew, etc= ...
> > > > that a lot of troubles for almost nothing.
> > > Not at all ! because you deal with macrocell and all the suf= t are soon
> made.
> > ain't it magical ??...
> > are you so confident and faithfull in the technologies ?
> >
> > > > you want speed ? put the wires in parallel, don't seria= lize the
> bits...
> > > Yes, but the limit are the number of pin and the prices ! An= d then you
> > > alwas have the speed of the clock with LVDS, you always have= the
> > > electrical and speed problem.
> >
> > ok, let's compare serial and parallel.
> >
> > you want 1Gbps links. halve it now, because the actual efficiency=
> > of a serial bus is not the raw peak number. With 10Base, one can'= t
> transfer
> > more than 500K bytes per second. or 520. whatever.
> > So let's imagine that you can SUSTAIN 50 M bytes per second.
> > caugh. caugh. ok, imagine you can reach 70M bytes in the two dire= ctions.
> > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 M byt= es/s
> > (or 8 Gbps).
> >
> > Ok, i know, you want to reach 8Bgps by using 8 links.
> > but how are they connected ? if you want to make a ring, you'll > > dissipate your bandwidth, and if you want to make neighbour to ne= ighbour
> > connexions, you'll require 64 pins (or better 100, counting groun= ds/VCC)
> > per neighbour. retour case d=E9part...
> >
> >
> > > > > In usual core, you have simple bus and it's easy t= o
> > > > > put rom or eeprom to boot. But here, you need some= thing more
special
> to boot.
> > > > and who will build that ? do you have the spare parts s= omewhere ?
> > > "spare part", i don't understand.
> > i mean : go buy some such chips at St Quentin Radio or Radio Shac= ks...
> > a chip that is available for sale in public catalogs.
> >
> > > One day, you say you want performance,
> > > the other days somthing so slow to be compatible with TTL. I= don't
> > > understand you...
> >
> > i want something that can do both, but of course not at the same = time.
> > you can't access a mouse or handcrafted I/O board (anything that = you
> > see in Elektor or Electronique Pratique) with the same means as a= nother
> CPU.
> > But the protocol and the layout must remain the same, as to ease = the PCB
> design
> > and the easy replacement of the chips.
> >
> > > > > Have you a link for a preditive routing algorithme= ? I think that
my
> > > > > collegue which make a thesis about real time netwo= rk will be very
> > > > > interrested to know that exist.
> > > >
> > > > the routing stuff is taught during the DEUG at Paris 8 = university.
> > > > ask Amal Stri from the transversal department.
> > > >
> > > > When at Boston, in a (expensive) library, i found (but = didn't buy)
> > > > a VERY cool about the T3E and similar architectures. Th= e routing
> > > > algos are rather simple and very efficient.
> > >
> > > I seriously doubt about the complexity and the scalability..= .
> >
> > remember, it's a torus. only, it's 3D :-)
> > for the other details, it's up to you to go to the library,
> > read as many book as you can and ask the teachers and the
> > educated people from comp.arch and comp.sys.super...
> > i won't do it for you, you wouldn't believe what i say :-P
> >
> > > > > If we made a simple core (like ARM), we don't need= g-ship and all
> that crap.
> > > > not true. ARM chips require I/O chips. Unless you buy t= he
synthesised
> core,
> > > > and implement it in the middle of a sea-of-gates ASIC w= ith your
> prefered I/O.
> > > One more times, you don't unsderstand ! i propose like leon,= just to
> > > develope the fc0 (the core) and let other gays to use it. > > so let's drop this silly network/bus whatever debate for a while.= ..
> >
> > > > > If we made a processor ("a system") we s= hould consider to have
> > > > > fault tolerance capabilities. And hot swap is the = basis !
> > > > not necessarily. fault detection and bypass are a SW ma= tter,
> > > > with the help of some HW (ECC/SEC). but the rest is pur= ely an
> electrical
> > > > problem.
> > > >
> > > Not really, i don't speak about fault detection but failure = tolerant
(a
> > > single dead card don't stop the all system, you just have to= change
it).
> >
> > it's the SAME thing. You can't be "fault tolerant" if y= ou can't detect
> > the fault and take the necessary SW measures. It's obvious...
> > i'm just trying to avoid "buzzwords" that taint the deb= ate with black
> magic ;-)
> >
> >
> > > > some designs that you should investigate (using several= different
> books,
> > > > saying different stuffs) : T3D/E (it's a 3D torus with = ALPHAs at the
> nodes),
> > > > CM1 (12-cube with extremely simple routing), CM5 (fault= tolerance,
> "big tree"
> > > > network, message passing communication etc.), SGI/SUN/H= P scalable
> computing nodes
> > > > (i found the Convex (circa 1995) very interesting, but = Convex is now
> owned by HP).
> > >
> > > Just for information : how much for a single chip ? And how = much heat
> > > for a chip ? You try to give some piece of your knowledge bu= t you
don't
> > > understand the "simple coma" from SUN for their la= st system (from an
URL
> > > given on the list), so ?
> >
> > i've tried, but it's not that clear for me, what's so special ? > > when there's a page fault, i trap. Just make the correct fault ha= ndler,
> > and you implement any memory protection and sharing you want.
> > It leaves the door open to ANY memory system implementation.
> > what else do you want ? i'm still waiting for a clear and HW
proposition.
> >
> > > > i know, it's a matter of culture...
> > > I just see it's like jam, ...
> > J'en ai une meilleure, mais je ne l'ai pas invent=E9e non plus, > > elle est de Jacques Brel : "La culture, c'est la m=E9moire d= es
> > cons qui n'ont rien invent=E9". Il avait vraiment des id=E9e= s
> > noires avant de mourir... La culture, il faut se la faire
> > tous les jours et ne pas trop camper sur ses positions...
> > avec le f-cpu, on a ce qu'il faut comme action :-)
> >
> > bonne nuit,
> >
> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 5
> >    Date: Sun, 07 Jan 2001 11:18:39 +0100 (CET)
> >    From: "maurizio zoboli" <maurizio.= zoboli@unimo.it>
> > Subject: REMOVE
> >
> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com wrote= :
> >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >telephone number and the
> > >product or service you wish
> > >to market. We will be in
> > >touch with you shortly!
> > >
> > >
> > >
> > >
> > >
> > >Removal Instructions
> > >****************************
> > >To be removed from this list
> > >please reply with "REMOVE"
> > >in the subject.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >Expand your business with
> > >    Email Marketing!
> > >
> > >Market your product or service
> > >     to MILLIONS!
> > >
> > >Don't waste another minute...
> > >
> > >Click Reply with your name,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Prof. Maurizio Zoboli
> > Dipartimento di Scienze dell'Ingegneria
> > Universita' di Modena e Reggio Emilia
> > via Vignolese 905
> > I-41100 Modena, Italy
> > Tel.: +39 059 2056163
> > Fax: +39 059 2056129
> > e-mail: maurizio.zoboli@unimo.it
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> >
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 17
>    Date: Mon, 08 Jan 2001 02:53:56 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> hello,
>
> Nicolas Boulay wrote:
> > Yann Guidon a =E9crit :
> > > hi !
> > > Marco Al wrote:
> <snip>
> > > if you target "small SMP" only, maybe you can do i= t with a shared bus,
> > > but don't expect wonders above 4 CPU. If you're doing CPU-on= ly tasks,
it's
> > > ok, but when you start to move things around, it's the real = mess.
> > > Intel sticks to this because the architecture is more or les= s stuck.
> > > they want cheap systems and make big profits, but still comp= ete (with
> > > some pain) in the SPEC contests.
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface.
> in such a system, a good bandwidth ratio between external and private<= BR> buses
> is critical. Even a message is a heavy stuff. do you imagine that they=
> only send messages for the new year's eve invitation ? :-P
>
> > So in the intel
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
> hey, i thought that we shouldn't decide for the user ?
>
> remember that you cite I/O. Ok, you're used to your slow PC and your little
> SPARC. but when Synopsys starts to swap, don't you wish you had more I= /O
?...
> I/O shouldn't be the 5th wheel of the car. if you do "multimedia&= quot; (sound
and video),
> you understand that it is critical.
>
> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as
well,
> > > and it's my "hammer" argument when i try to promot= e point to point
links.
> > > We spare the (distributed) control logic (all the nasty dead= lock
stuffs etc)
> > There are always possible traffic Jam. How do you manage when 2 n= odes
> > try to speak to the same nod ? You have to manage something to av= oid
> > losing informations.
> losing information ? when ?
> there is no information loss possible in the protocol i try to setup.<= BR> > when there is a contention, there is a delay but that's all.
>
> > > and it's very simple to implement. the PCB is simpler, too.<= BR> > > >
> > > If you connect more than 2 CPU on the same bus, they compete= for the
ressource
> > > and the bottleneck gets even narrow.
> >
> > Yes, but less drastically as intel SMP.
> >
> hum, what's the difference ?...
>
> > > On the pin count vs bandwidth argument, it's similar. Of cou= rse, we
can find
> > > a lot of counter-examples and special cases, but the example= of the
broadcast
> > > is not the best one. Most of the requests are from one node = to a
single other
> >
> > In fact, not. It depend how much process communicate between them= . And
> > sometimes the only [simple] way to find a "moving" ress= ources is to send
> > a braodcast.
>
> And what if no boradcast was possible ?
> the solution is to interrogate a list of the ressources, located in > a public memory, just like you explained in one of your lesson,
> where the 4 shared memory schemes are explained.
>
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU
wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real
efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2
dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same
but the
> > > address is split into 3 fields that are interpreted as an in= dependent
ring address.
> >
> > In the flight back to France, we have spoken about ring of ring.(= and
> > called the architecture the lord of the ring ;p).
> know your history ;-) look at the KSR-1 and successors (that never rea= lly
> worked, btw). hum, was it Kendal Square Research or another similar > "small supercomputing" company ?
>
> > A ring is composed
> > around 8 to 16 card (cpu+ram or IO). A card could be used to comm= unicate
> > with other ring. Maybe it's possible to grow in hierachy without = to much
> > trouble.
>
> in theory, yes. In practice, it's not used. it's been done and never t= ook
off.
>
> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6
neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant"
(through dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU
number).
> > >
> > So !
> >
> "so what" ?
>
> > > So if you want the simplest system, you have 1 CPU with no r= ing,
> > > and when you scale up, add a few links when needed and use l= ike "lego
bricks"
> > > in a cubic connexion.
> > Cubic ~=3D  ring ????
>
>            = ; __A_____C_____E______G______I__
> 1 ring :   (__B_____D_____F______H______J__)
>
> (notice the pairs of nodes : one pair is added to extend the ring)
>
> a 2D ring :
>     A   B   C   D&nb= sp;  E ....
>
> 1   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
>     ||  ||  ||  ||  ||
> 2   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
>     ||  ||  ||  ||  ||
> 3   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
>     ||  ||  ||  ||  ||
> 4   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
>     ||  ||  ||  ||  ||
> 5   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D
>     ||  ||  ||  ||  ||
> ...
>
> one "8" is a node that establish the connexion between
> a vertical ring and a horizontal ring. So a "node" comprises=
> 4 CPU and 4 bidirectional links.
>
> 3D : extend to 6 CPU and 6 links per node.
> Here, the node is a "cube" with one connexion on every facet= .
> that's why i used the term of "lego brick" : when you want t= o add
> a CPU, you add a cube. when you want to replace or add cubes,
> you deal with "boxes".
>
> In practice, the physical implementation is not so simple
> (we have to deal with 2D PCBs and connectors) but the routing
> is the same as with your everyday "ring" network, except tha= t
> the address is split into 3 fields that are routed almost
> independently. when you see a match on your X and Y values but
> a wrong Z, you simply send to the Z link. Whether it's +Z or -Z
> depends on the substraction of the current address and the desired
> address : send to +Z link if the result is negative and vice versa. >
> One CPU is dead ? break the links (invalide the link in the neighbours= )
> and ignore the corresponding routing field in the neighbours.
> This way, no message will go through the dead node.
> Want to replace a CPU ? rename the nodes : change the address of
> every working node so the "good" spare node becomes visible = in the
machine.
> Usually, in a 1000 CPU system, around 30 or 50 CPUs are left for the > reserve. they are remapped when a CPU fails. otherwise, they serve
> as "spies" in the network and they help analyse the traffic.=
>
> this is not verbatim how the T3E works, but there's no big difference<= BR> AFAIK.
>
> > > > Marco
> > > Nicolas Boulay wrote:
> > > > Hi,
> > > > Yann Guidon a =E9crit :
> > > > > hi,
> > > > > Nicolas Boulay wrote:
> > > > > > hi,
> > > > I don't think that you know about what you speak !
> hey ! i read Electronique Internationale Hebdo every week :-)
> i know more or less who opens what plant and where, for what technolog= y
> and what price.
>
> > > > New silicon process
> > > > are silicium on insulator, soon used by IBM for there u= dge processor
for
> > > > mainfrain (a little beast with 35 ppc on the same die).=
> > > duh. and how will you ask IBM to make your chip ?
> > > it's not something that everybody can do. it's not free, it'= s
expensive
> > And you think that actual 0.18 =B5m are free ?
> listen, boy, "they" made the first ALPHA chip in 0.75u techn= ology, back
around 1992.
> if we can _reach_ that, you'll be able to dream like you want.
> we're still rookies, we have not much experience and we dream a lot. >
> > In 2 years, SOI will be
> > used in every silicon process, because it reduice the power consu= mption
> > and doesn't cost so much (it's just a little traitement on wafer)= .
> it's a matter of accessing the technology, not a matter of what techno= logy
> is better.
>
> > > and it's not connectable to anything...
> > ??? I think you miss something... The only electrical rules to re= spect
> > is the higher voltage in input, most of the time lower than 3.3 V= , to
> > avoid destroying transistor, that's all.
>
> by that, i meant : where do you plug it ? you have to design everythin= g !
>
> > > > And now, for the next powerG3. Next, the SiGe are new p= rocess used
to have
> > > > hyperfrequencies, or mixed analogue and digital part. B= ut then, it
could
> > > > be used for very quick digital circuit.
> > > It is. but how many people would use such a chip ? what can = they
connect it to ?
> > > how will you "solve" the RF issues ? Do you know h= ow difficult it is
to route
> > > a 50 MHz signal ? So who will buy you the SW needed to desig= n a RF PCB
?
> > I think that Cadence has offer something. (any news ?)
> only high-level RTL design tools, no PCB design yet.
>
> > You want performance and you think that 50 Mhz signal are to much= . How
do you
> > want to deal with 133 Mhz DDR-SDRAM ?
> i didn't say that 50 MHZ is to much. I say that it causes already a lo= t of
> troubles that rookies like us can't solve with a simple "let's do= this"
workaround.
> when i started electronics, 27MHz was rather difficult, and the 144MHz= was
almost
> black magic. Now you come and you want 500MHz. i say : ok, but let's m= ake
something
> "work" first, so we can see what to not do with higher frequ= encies.
> If we ever get a 50MHz, or even 10MHz chip working correctly, i'll be<= BR> happy.
> didn't they tell you at ASIME that almost none of their chips works ab= ove
100MHz ?
>
> > > > And, for information, gigabit ethernet need 500 Mhz. So= , "usual
process"
> > > > are must enought to make a tranceiver.
> > > Maybe you should stop to use the term "ethernet". = If it's a simple
> > But in electrical rules, gigaethernet is only a serial point to p= oint
> > link, not much more (just add the mac adress and a crc).
> it implies too much. Just reuse/paraphrase what you just wrote :
> "a serial point to point link" and that's ok for me.
>
> > > "serial link", you're just making a firewire clone= ...
> > A=EFe ! Firewire isn't a point to point serial link !!!! It's a c= omplete
> > network system which include the 3rd layer of the OSI system. It = include
> > the routing protocole and all that stuff (the same thing than IP = )!
> remember what you wrote : "But in electrical rules, ".... > I don't care about the OSI or whatever. I care about the efficiency > of the stuff.
>
> > > > You have never learn that this kind of cable could be a= round 50
meter
> > > > long ! Here 1 or 2 meters is much enought !
> > > and you think that it's not the same problem ????
> > > have you heard about Xtalk and such stuff ? you CAN't make i= t with a
1-layer PCB.
> > That's why ethernet cable are made by pair (like lvds, d is for > > differential). And with some ground it could pass.
> i like the last phrase :-)
>
> now i think that you should look at the "Autobahn" bus, adde= d to some
> VME backplanes designed by whatever company (Force Computers ?).
> They added a high-speed serial link to VME, 5 years ago IIRC.
> You could learn a lot about their designs and their errors.
>
> > > you need at least 3 layers to make a decent transmission lin= e
> > so 4 layers, like usual mother board.
> hum....
> i learnt something during the last year : we shouldn't be too optimist= ic
> with PCB layers. you need 3 layers for _transmitting_ the signal, but<= BR> > depending on your connectors and backplane, you can easily reach
> 10 or even 20 layers very quickly ! if your connectors are too dense,<= BR> > you'll have to route some tracks with additional layers.
>
> > > (shield/insulator/signal/insulator/shield). And depending on= your
signal's
> > > characteristics, you have to change the dimensions of the tr= acks,
> > > so they are adapted to the thickness of the PCB and the perm= eability
of
> > > the insulator (if it's epoxy or teflon or something else). > > >
> > > Whether the wire is 50m or 1m, the problem is the same... > >
> > Not really. The Characteristique are made to say that your cable = could
> > be 50 meter long, so the signal could be mixed with a certain lev= el of
> > noise. If you need shortest cable, you could adjust the quality o= f the
> > cable.
> it's not a good reason to be laxist...
> you still have to respect the electrical rules
> and use severe constraints on the PCB.
>
> > > > Fast clock one large network, you have to deal with clo= ck skew.
> > > it's an old known problem and there are some old known solut= ions.
> > > ever heard about a "clock tree" ?... if you have a= good architecture,
> > > you don't have skew troubles.
> >
> > Don't forget that i'm microelectronic engineer and clock tree are= a
> > basis... Which is not so simple at all.
> >
> but at least they are known and used for what they're worth.
>
> > > > Most of the time, each founder (ST microelectronics, TS= MC,
infineon,...)
> > > > have a macro cell to do gigaethernet and do all the har= d things
(serial,
> > > > deserials).
> > > and you'll by the components ? come on...
> >
> > The chip maker will by it.
> >
> and then let the end user pay the bill.
>
> > > and please, don't talk about "Ethernet", it seems = like it's
> > > only a serial point to point link (if i remember one of your=
messages).
> > >
> >
> > But, it is !
> >
> so stop about speaking about Ethernel, but try "fast serial link&= quot;...
>
> > > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? T= TL signify 5V
and
> > > > some nF of charge. I don't want to repeat it each time.=
> > > hey, i'm not dumb, i know that TTL is slow. thanks.
> > >
> > > but just a question : how will you debug your stuff ? will y= ou use
> > > a 10GS/s logic analyser ? with a simple enough protocol, i c= an
> > > debug the interface with "off the shelf parts" tha= t i can solder at
will,
> > > the old school way, just like any "hacker".
> > >
> >
> > Like everybody, you will use a standart JTAG port.
> >
> LMFAO :-)
>
> when i speak about "debug", i speak about seeking errors
> in the dynamic mode, at high speed, i don't speak about seeking
> static errors. dynamic errors are harder to track and JTAG is useless<= BR> > here (it's not a terabit link ;-P)
>
> > > Then, when it's developped, you only have to change the elec= trical
> > > levels (that is : the pin's driving gates) and you can do LV= TTL or
whatever
> > > high-speed connexion. it's just a matter of changing the ele= ctrical
spec.
> > > Yes i want speed, but a "hacker" needs a way to se= e what happens
without
> > > the need of extremely expensive devices. by clocking the chi= p slower
> > > and adapting the electrical level (with the adapted buffers = or
transmitters),
> > > you can hook anything to the F-BUS.
> >
> > If you use low voltage it's because you can't manage with higher = one. So
> > it could be impossible to change it !
> >
> hey, some chips are here for that ...
> there are also mixed-voltage FPGAs that can do both the electrical
> adaptation and the protocol management.
>
> > > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very = slow compare to
> > > > usual system.
> > > this kind of speed is used for I/O with maybe a controller o= r
something
> > > like that. When i speak about "TTL parts", it's so= mething like a 8255
> > > or any very slow byte-based I/O chip. just like during the o= ld days
> > > of the 8-bit systems...
> >
> > And you want performance by slow down the network only to put goo= d old
> > I/o chip....
> >
> here you mix everything. i want flexibility : being able to go at full=
steam
> with specific electrical interfaces, and allow anybody to plug a custo= m
> board without pain. What's the use of a ultra-high-speed bus if you ca= n't
> connect anything on it ?
> let's compare ISA and PCI : the first is slow, but it survives because=
> it's very easy to design boards for this bus. The second bus is faster= ,
> is sexier but a big mess : you need a more expensive technology
> and very specific tools. Circuits like the AMCC "matchbox" d= idn't appear
> until recently. I don't say that PCI is worse than ISA, i say that
> it is less useful. It was imposed (remember the VLB ?) by some industr= y
> cartel and slowly accepted. If we provide an easy entry in the system<= BR> > with an easy-to-interface bus, we'll have a broader user base and easy=
ramp-up
> in frequency. thus more success.
>
>
> > > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) = or around 300
Mhz
> > > > with DDR or more with QDR. With LVDS, you can reach aro= und 600 Mhz
by
> > > > pin. BUT you can't really add a connector between 2 pin= s at that
speed.
> > > then it must be soldered. but then, this speed is not requir= ed for
> > > handcrafting your own I/O board on a pre-drilled PCB. do you= know a
mouse
> > > or a keyboard or even a LCD screen that requires 600M x N pi= ns of data
> > > per second ?
> > >
> > ????? I speak only for the network system, to be compared to the = bus
> > system in intel board the 64 bit now 200 Mhz multipomped bus. Not= to the
> > PCI or EISA.
> >
> i think that i have lost track anyway.
>
> > > Scalability means scale-down and scale-up. 500Mbps is fine, = but when
you
> > > don't need that much, it's an overkill. And you propose to m= ake an
adapter
> > > that will bother of the I/O, but how many custom chips will = you
require
> > > to interface your connexion to any other stuffs ? Having a s= imple and
> > > one-fits-all protocol that does low and high-speed helps red= uce the
> > > number of different chips and interfaces...
> >
> > First only one to connect other system (PCI, IO,...) and no G-shi= p
> > (include inside the fcpu)
> >
>
> if the "g-chip" (not "g-ship") is included inside = the f-cpu chip, then
> it's only a f-cpu with more communication channels, but more pins.
> I don't think that we can afford all the sexy technology now...
>
> > > > My choice is to have a quick link (performance are our = goal, isn't
it ?).
> > > not only. In the design goals of the F-CPU, there are 3 othe= r stuffs.
> > >
> > Which one ?
> >
> I thought that you read the presentation text, the manual and saw the<= BR> > conference in Berlin...
>
> c&p of the F-CPU manual, part1.html :
> "
>            = ;  To develop and make freely available an architecture, and all
other intellectual
> property necessary to fabricate one or more implementations of that architecture, with the
> following priorities, in decreasing order of importance:
>
>        1. Versatility and usefulnes= s in as wide a range of applications as
possible
>        2. Performance, emphasizing = user-level parallelism and derived
through intelligent
>            = ;  architecture rather than advanced silicon process
>        3. Architecture lifespan and= forward compatibility
>        4. Cost, including monetary = and thermal considerations
> "
>
> i didn't write it. i participated in the debates but it was accepted during a poll
> on this mailing list. it can be tracked down easily with the eGroups website search engine.
>
> i think that your propositions are off-topic for the f-cpu project. >  1) high-speed serial links are not useful everywhere. it require= specific
>      interface chips that don't exist yet. >  2) performance : you use brute-force technology, not an "in= telligent
architecture".
>      i am still waiting for a groundbreaking = idea :-)
>  3) lifespan : you'll drop the Gbps when something "sexier&q= uot; will appear.
>  4) cost : what budget do you expect ?
>
> i don't want to bring you down. Some people are enthusiastic and i don= 't
> want to break their hopes. You have sparkled an idea, now you need two=
things :
>  - you have to find your place in the landscape of the Free Hardw= are
projects.
>      it seems that this list and this project= is not a good place to do
this,
>      we better speak about scheduling and the= ISA...
>  - you need a good architecture. Remember that it took almost a y= ear
before
>      we found something good for the F-CPU. >
> You, and i hope Jeff and others, will have a lot of work to do.
>
>
> > > > > now you're asynchronous, you have to deal with PLL= and clock
> > > > > recovery, hyperfrequencies, signal integrity, skew= , etc...
> > > > > that a lot of troubles for almost nothing.
> > > > Not at all ! because you deal with macrocell and all th= e suft are
soon made.
> > > ain't it magical ??...
> > > are you so confident and faithfull in the technologies ?
> > Read there spec.
> i was below the reality. You're playing with fire :-)
> some bad experiences with Intel and ADi documentations
> taught me to NEVER TRUST them. it's clearly written in
> the disclaimer part : everything is "thought" to be acurate<= BR> > and can be changed at any time without the consent of the
> customer. but you won't learn until you get burnt :-)
>
> > > > > you want speed ? put the wires in parallel, don't = serialize the
bits...
> > > > Yes, but the limit are the number of pin and the prices= ! And then
you
> > > > alwas have the speed of the clock with LVDS, you always= have the
> > > > electrical and speed problem.
> > >
> > > ok, let's compare serial and parallel.
> > >
> > > you want 1Gbps links. halve it now, because the actual effic= iency
> > > of a serial bus is not the raw peak number. With 10Base, one= can't
transfer
> > > more than 500K bytes per second. or 520. whatever.
> > > So let's imagine that you can SUSTAIN 50 M bytes per second.=
> > > caugh. caugh. ok, imagine you can reach 70M bytes in the two=
directions.
> > > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 = M bytes/s
> > > (or 8 Gbps).
> >
> > True but with how many wire ?
> >
> that's rather similar, but now i'll add an argument :
> how much time ?
>
> with a serial bus, when you want to pass a message to a node,
> you have to transmit a packet containing :
> - who will receive it
> - who sent it
> - how large
> - some control and description stuff.
>
> In a 64-bit machine with 64-bit address space,
> it takes around 150 bits (more or less 30%)
> plus the data. that makes : 150 * 1 ns/bit (1Gbps peak rate)
> or 150 ns.
>
> now, how long does it takes to transmit the address
> and the control signals on a paralle wire ? 10ns ?
> even if it took 15ns, it would be 10x faster than
> your serial link. so i can say that the latency
> of your network is nearly disastrous :-P
>
> > > Ok, i know, you want to reach 8Bgps by using 8 links.
> > > but how are they connected ? if you want to make a ring, you= 'll
> > > dissipate your bandwidth, and if you want to make neighbour = to
neighbour
> > > connexions, you'll require 64 pins (or better 100, counting<= BR> grounds/VCC)
> > > per neighbour. retour case d=E9part...
> >
> > Compare the number of wire and the cost of a BGA compare to a PGA= .
> >
> it's rather off-topic, we can't decide that it will work only with BGA= .
> you know (i presume) that there are some other technologies as well, > such as flip-chip etc... And you know that the number of pins
> is only one of the problems. for example, if you reach higher yields > in the whole production fab, you'll reduce the cost of the chips
> and the relative cost per pin as well.
>
> > > > > > In usual core, you have simple bus and it's e= asy to
> > > > > > put rom or eeprom to boot. But here, you need= something more
special to boot.
> > > > > and who will build that ? do you have the spare pa= rts somewhere ?
> > > > "spare part", i don't understand.
> > > i mean : go buy some such chips at St Quentin Radio or Radio= Shacks...
> > > a chip that is available for sale in public catalogs.
> > You are realy funny, even by Radiospares you can't buy 3.3 V logi= c, and
> > you want an killing design to compet against alpha !
> yes.
> but i know that St Quentin Radio, Selectronics etc, they sell
> some FPGA and other affordable chips that can play the interface
> with a 3.3V F-BUS and a custom board. It's the same kind
> of technology, or even cheaper as what you can read in Elektor...
>
> > > But the protocol and the layout must remain the same, as to = ease the
PCB design
> > > and the easy replacement of the chips.
> > *<;p
> at least, you have some sense of humor ;-P
>
> > > > Just for information : how much for a single chip ? And= how much
heat
> > > > for a chip ? You try to give some piece of your knowled= ge but you
don't
> > > > understand the "simple coma" from SUN for the= ir last system (from an
URL
> > > > given on the list), so ?
> > > i've tried, but it's not that clear for me, what's so specia= l ?
> > > when there's a page fault, i trap. Just make the correct fau= lt
handler,
> > > and you implement any memory protection and sharing you want= .
> > > It leaves the door open to ANY memory system implementation.=
> > > what else do you want ? i'm still waiting for a clear and HW=
proposition.
> > HW or SW that not the point, you can used both for the same thing= , the
> > only 2 issue are cost and performance. Bevore, we had to find the=
> > algorythmes and then implement it.
> of course it's the point because the good separation is critical for t= he
> performance/cost. read P&H :-)
> So please analyse your preferred algorithm, and tell me what HW does > the most critical thing. It should be a simple unit, or at least
pipelineable,
> just like any unit in the F-CPU. I don't want a "COMA controler&q= uot;-like
name,
> i want something that anybody can interpret without going through the<= BR> Websters.
> something like : lookup table, comparator, adder, ...
> then, there's no problem to support COMA or whatever but don't give me= all
the
> work. You proposed something, you have to help if you want your idea t= o
succeed.
> Similarly for your micro-network : you have to do it. There's no magic= .
>
> > "La culture est ce qui reste quand on ne sait rien faire&quo= t; Francoise
> > SAGAN, un peu provoc, l=E0... ;p
> elle en connait un rayon l=E0-dessus ;-P
>
> > > > > > > > nicO
> > > > > > > WHYGEE
> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 18
>    Date: Mon, 08 Jan 2001 05:14:25 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: This project really sucks. (yes we know, but that's what<= BR> makes it so interesting :-D)
>
> some ramble-commenting,
> discard if you don't care...
>
> Alan Grimes wrote:
> > =3DP
> >
> > om   (I'm invincible!)
> me too ! me too ! me ... <wham>
>
> >         Hey, you morons, = whomever thinks he is running this project is
doing an
> > absolutly, unforgivably, horrible job. If you were, say, working = for a
> > company and were working in a well-managed tightly optomized R&am= p;D team,
> > you guys would be briliant. BUT YOU'RE NOT!!!
> hey, do you know ANY "well-managed tightly optomized R&D team= " ? :-P
> if so, i'd like to see it :-)
>
> >         In a private comp= any you have the luxury of closed-door
face2face
> > meetings where you can get a lot done.
> make me dream... what's the name of this company ? :-)
> <no, i won't leave Mentor>
>
> > But, for an internet project such
> > as this, that is totally inadqiquate. You must keep and maintain = a
> > current website...
> is there a webmaster in the room ?
> any ?
>
> i'd like to do a million things, sleep, eat, have fun, go to gigs and<= BR> > have a wife or two, but the VHDL and manual are my top priorities.
> If anybody wants to take the responsibility of the web sites, it's ok<= BR> > for me, i'll pass the rights and tricks, but please ... stop shouting = :-)
>
> >  oops! I *thought* it was f-cpu.tux.org (which should
> > be updated or deleted.).
> status : like the mailing list. Mathis is unreachable,
> he's gone the AlphaGhost, Balsa and other's way.
> let's remember this and not repeat the errors...
>
> > For the ammount of traffic on the list,
> > f-cpu.org is also stale, so my point holds, though not as strongl= y.. =3D\
>
> if you want to contribute, please mail me an updated version of the pa= ge
> (i'll upload it whenever i connect to the site one day) or take the responsibilities
> of your requests. it's not that difficult after all : it takes "s= ome
time", patience
> and a PC with a modem.
>
> >         An project, such = as what this one pretends to be, must provide
an easy
> > "on-ramp" for people who are new to the project to beco= me active
> > participants. Such consessions to the newbies must include:
> >
> > in order of importance:
> >
> >         - A glossary.
> >         - A reading list.=
> >         - A document/sour= ce managment system. that is easily accessable
to any
> > reasonable web browser.
> >         - A job managment= system that can manage tasks and bugs from
proposal
> > to retirement.
>
> hmmm, you seem to be the best one to do all that :-)
>
> ok ok, i stop my silly irony. Of course, all that is fine.
> we want a working CPU, plus a lot of professional tools...
> what we really need is TIME and involved persons. Up to now,
> the largest teams were 2 or 3 people.
>
> how did the f-cpu advance ? Mathias+me : fc0 + manual, Michael+me : VH= DL,
> of course with very helpful punctual help from a lot of others.
> Olivier now helps for the manual's technical maintainance, i update th= e
contents.
> Mathias left, i hope that Michael will stay much longer, and i hope th= at
> i won't slowly abandon the project. it's too much work and it would fa= de
away...
>
> > The point I am trying to make here is that I have been on the lis= t for
> > two and a half years and I can't even say for certain what the st= atus of
> > the project is or wheather we have reached any "milestones&q= uot;.
> are there any milestones after all ?
> one BIG psychological milestone is that we started to make some decent=
VHDL.
> Anybody can now contribute to this part. I estimate that it's a first = good
step.
> But, just like the manual, it's a new burden of work to carry on and m= ake
work.
>
> > I am really frustrated by the apparent lack of progress.
> everybody is frustrated. But what keeps you from helping ?
>
> > I need a gnu machine! =3DP
> i first read "machine gun" ;-)
> I also need this gnu HW, like a lot of people.
> but do you think it will fall from the start with the force of your prayers ?
>
> > I therefore make the following demands:
> now that you have formalized them, please help them come true :-)
> you will help yourself and others as well.
>
> > - A Czar or voting comission with a fixed registered membership m= ust be
> > appointed or elected for the sole purpose of approving contributi= ons to
> > the document/source managment system with the objective of focusi= ng the
> > efforts of the group towards the completion (*ghasp*) and deliver= y of a
> > product to market.
> what market ?
>
> we have an open arena where everybody can submit and discuss ideas. > if somebody feels isolated or not understood, he can do his own versio= n
and
> start his own development.
>
> > - A formal contributor development system, like what you would fi= nd in a
> > company, that will provide training or mentoring to aspiring
> > contributors.
> name that company :-)
>
> > - The founding of an American branch of the apparently extant fre= nch
> > F-CPU orgainization. This is in recognition that local groups wor= k
> > better.
> seeing the lack of action in France, where we seem to be more
> organized than outside of Europe, this is going to be a big
> undertaking. I'll send you a reward (cheese ? wine ?) if you succeed !=
> Frankly, i hope that more people organize themselves around the globe.= ..
>
> > Really, This project serves me only when it yields something that= is
> > useful. Failing that it can go to hell...
> sure, Al, but do you think it can be for free ?
> if you don't participate actively, you don't have the garantee that > it will work one day. Now, you don't participate because it's not
successful.
> but if you reverse the situation and make some continuous efforts,
> you'll give us more chances.
> And maybe : if you get more involved, you will feel less disapointed.<= BR> >
> > I will see what happens over the next two months and then go bug = the
> > opencore people some more, and perhaps work up a project over the= re.
> well, you do whatever you can. you can lurk whenever you want, but
> you won't get much for free. if you don't participate, then you won't<= BR> > have no right to criticize ... heh.
>
>
> Michael Riepe wrote:
> > On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:
> > [...]
> > > I therefore make the following demands:
> > Demands?  F*ck off.  You have no right to demand *anyth= ing*.
> he has the right to make any demands he wants. we all have expectation= s.
> but it's not a "one-way" deal. his demand will not be fullfi= lled if
> there's nothing in return. logic.
>
> > [...]
> > > Really, This project serves me only when it yields something= that is
> > > useful. Failing that it can go to hell...
> >
> > Don't ask what this project can do for you,
> > ask what YOU can do for the project.
> > (misquoting John F. Kennedy, IIRC)
>
> it's been misquoted so many times that i wonder if it was JFK the firs= t
who told that...
> :-)
>
> > > I will see what happens over the next two months and then go= bug the
> > > opencore people some more, and perhaps work up a project ove= r there.
> > Fine.  Better go NOW and start bugging somebody else.
> >
> > This attitude makes me sick...
> in one year or two, you won't ever care :-)
>
> this list is an interesting place anyway. it's like an experience
> on entropy, darwinism, cyberculture etc...
>
> and it keeps you ready for anything : the worse like the best.
> the remedy for boredom.
>
>
> then, the backfire :
>
> Alan Grimes wrote:
> > Michael Riepe wrote:
> > > You should learn how to read.
> > I can read anything that is within the reach of a highschool grad= uate
> > and a fair ammount of mathematical and technical stuff to...
> this answer is the proof :-)
>
> > As I mentioned in my post, there is little to suggest WHAT I shou= ld
read,
> > unless you want me to spend the rest of my life reading crap unti= ll I
> > finally hit on something that is relevant...
> if you don't want to read crap, please contribute with something more<= BR> interesting
> than basic sparks (i don't call that flames...). you're free, you're a= dult
> (?) and you have a brain. now it's time to prove that they work well together.
>
> > It took me fully eighteen
> > months of applying that self same process to learning how linker-= loaders
> > work. I literally had NO CLUE. Now its all perfectly clear to me.= The
> > position I am taking is that I have no intention of repeating tha= t
> > process.
> you don't want to send time learning ? i don't get it.
> anyway, it's sure that if you want something, praying or asking is not=
enough.
>
> > > Or contribute.
> > I can't, for the reasons that I attempted to explain in my last p= osting.
> > READ IT.
> i didn't understand much ...
> you don't contribute because you find it's crap ?
>
> > > Or shut up.
> > Pleas understand that I am running Windows 3.11 on an Athalon pro= cessor.
> geez. it works ? cool :-)
>
> > The PC is far too fucked for me to write my own OS. (I have disco= vered
> > this through great labor). But I *can* write an OS for F-cpu (I h= ope).
> cool. but you understand that, before writing the OS, you have to get<= BR> > a sort of loader or BIOS and HW drivers, and that they can't work befo= re
> the motherboard/platform is defined, and that won't happen before the<= BR> > first F-CPU is released.
>
> 2 solutions :
> - you're very patient. cool, then wait for an hypothetical f-cpu to appear.
> - you're impatient. either you drop or you contribute to the f-cpu, an= d
> you have the satisfaction that it is sped up.
>
> > I am hurting.
> >
> >  In a year or so I won't be able to get anything done on the= net at
> > all... I will be profoundly fucked. "Shutting up" is no= t a very good
> > option for me, now is it?
> it's your choice. it's up to you.
>
> > > > I therefore make the following demands:
> > > Demands?  F*ck off.  You have no right to demand *= anything*.
> > Maybe not. But the fact that you can't take an ounce of criticism= with
> > regards to this project is equally un-cool.
> equal to what ?
>
> > I have been observing this project practicaly from day one.
> > I have seen many things not happen. ;)
> And do you feel comforted for that ?
> did you finally understand that the best way to see things happen
> is to participate ?
>
> > This posting was my attempt to encapsulate all the observations I= made
> > into a single simple workable agenda for making things happen. If= you
> > can't take it then go work for a company, you have nothing valubl= e to
> > contribute to an open-source project if you canot accept contribu= tions.
> what did you contribute ?
>
> did you understand that if you made propositions, you were automatical= ly
> designated to apply them ? ;-) </k>
>
> of course your precedent list was fine. my wish list to Santa Claus wa= s
> ever finer, but he didn't accept it. Now what to do ?
> you can start a sub-project that will care about the organisation of t= he
F-CPU.
> you want it ? do it. then you won't lament as much, and you'll have th= e
> satisfaction of shouting at the people who do nothing :-)
>
> > > [...]
> > > > Really, This project serves me only when it yields some= thing that is
> > > > useful. Failing that it can go to hell...
> > > Don't ask what this project can do for you, ask what YOU can= do for
the
> > > project. (misquoting John F. Kennedy, IIRC)
> > Read my fucking posting before making brainless comments like thi= s. It
> > really shows me that you can't think one wit beyond your VHDL (or=
> > whatever) compiler to see that other people can hardly understand= what
> > it is you are doing.
> if you don't like it, you have the possibility to make one yourself > or take a pre-designed one off the Net. The f-cpu design is not tied > to his implementation.
>
> > THEN you will realize that this posting WAS a contribution.
> i fail to see how it contributed, except to show that you are still > alive (which is of course a good news).
>
> > It contributed the observation that people such as myself
> > are essentially left-out of the project *and* it proposes a conci= se and
> > understandable method for remedying the situation. If you would l= ike to
> > give me some permissions over at the sourceforge project then I w= ill
> > apply suggestions and my training in project managment towards ac= hieving
> > actual results.
> Mathias is in charge of the sourforge stuff. he left. maybe you can st= ill
> reach him with a polite email but it would be faster to make your own<= BR> > site (and share the access rights with someone else you choose, just > in case you leave the project).
> You are free to contribute and i do whatever i can to help the
contributors.
>
> > I am sorry that linux users tend to be so goddamned dense that th= ey
> > can't see or accept a simple and logical suggestion even when it = is
> > explained to them!  No wonder their operating system is as t= errible as
> > it is...
> what's wrong with my w95 ? </silly>
>
> anyway i still don't see the point of the OS.
>
> what we don't accept anyway is a "demand" with nothing in re= turn.
> the menace that you will leave is not a satisfaction, it's a sign
> that you don't care.
>
> Now if you want to participate more actively, by taking something that=
> you care in charge, nobody will refuse (i think, but it's a free list.= ..)
>
> > > > I will see what happens over the next two months and th= en go bug the
> > > > opencore people some more, and perhaps work up a projec= t over there.
> > > Fine.  Better go NOW and start bugging somebody else. > > Hey! Wanna make a CPU?  I not only can but I will make it ha= ppen. This
> > is what needs to be done.
> and it will be done. one day.
>
> > > This attitude makes me sick...
> > So does yours.
> at least, he has the satisfaction of having contributed in a critical<= BR> > part of the project ;-) of course it's not an excuse for anything,
> but it adds some weight...
>
> > I must appologise, I shouldn't have jumped as hard as I did but I= do
> > really feel a lot of frustration with this...
> we are all frustrated. maybe because of the "real" turn of t= he millenium.
> we better speak openly about it, rather than just throwing everything<= BR> away.
> but being polite and an 1/4 ounce of respect can do wonders...
>
> ok now i have to sleep. 2 hours left. i'll be stoned at work, tomorrow= .
> maybe i care too much for that project ?
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 19
>    Date: Mon, 08 Jan 2001 05:14:26 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
> Yeah !!!
> OH YES !!!
> at last/least, some lurkers are speaking !!!!
> but the results can be curious, such as :
>
> Vanderhoeven Steve wrote:
> > > If you connect more than 2 CPU on the same bus, they compete= for the
ressource
> > > and the bottleneck gets even narrow.
> > atm?
> hmm do you mean "At The Moment" or "ATM network" ?= ...
>
> > steve
>
>
> Marco Al wrote:
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface. So in th= e intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> >
> > You seem to presuppose that it wont have a single memory space wi= th
hardware
> > maintained coherency... I dont mind, I like transputers. But a lo= t of
users of
> > parallel systems disagree.
> >
>
> at least we must leave the end user free of some critical choices.
>
> > > > Clearly, this B=3DL/N is a thing that i try to avoid fo= r other things
as well,
> > > > and it's my "hammer" argument when i try to p= romote point to point
links.
> > > > We spare the (distributed) control logic (all the nasty= deadlock
stuffs etc)
> >
> > Thats one way of looking at it, the other way is that its a given= that L
has to
> > be B*N' and that for N>N' you need extra hierarchies.
>
> often, "higher" hierarchies have a lower bandwidth, this mak= es the
compilation
> still more difficult (the mapping of the algorithm to the architecture= is
> more complex if you have more levels). That's why the T3D is so seduci= ng
:-))
>
> > And you wont get away from hierarchies, a single chip can only co= nnect
to so
> > many processors and have so much backplane capacity. The control = will
always be
> > distributed at a certain point.
> at least we can try to avoid hierarchies as long as we can.
> An homogeneous machine is always easier to use than a heterogeneous on= e.
>
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same but the
> > > > address is split into 3 fields that are interpreted as = an
independent ring address.
> >
> > Exactly.
> >
> > My opinion also kind of depends on where the motherboard chipset<= BR> functionality
> > would be present and how many pins that would need.
>
> examples ?
>
> > I think making a bridge which can have a point-to-point/shared/ri= ng
connection
> > to the processors which itself plugs into a socket-7 board (or pe= rhaps
even a
> > PCI slot) is a good solution :) (bios should be local though, obv= iously)
> then, i'll leave you the burden of writing all the support code.
> I don't want to deal with Socket-7 anymore, but i'll do it if you make=
> all the nasty stuffs at my place :-P
>
> > Getting a processor made, no matter how many frills you remove is= a huge
task...
> we see this :-) but we're a few step further than 2 years ago....
>
> > I think designing a motherboard chipset on top of that is an unne= cessary
burden.
> if some of you can cope with a EV-4 slot, it will be ok for me...
>
> > You can always later replace the bridge with a true motherboard c= hipset.
> it can also be left up to the end user...
>
> but yes : let's concentrate on the CPU design :-)
>
> > Marco
>
> jeff@llandre.freeserve.co.uk wrote:
> >
> > Regarding this rather strange multi cpu argument:
> <snip>
> > All the multi cpu stuff is interesting but pointless. It
> > doesnt change the core. Why not get back to that. We
> > shouldnt waste whygee or michaels time, when they are
> > doing so well with the vhdl.
> if i wasn't at work, i could maybe do a bit better,
> so anybody can challenge my skills ;-)
> all i can do today is : to try to keep stuffs put together.
> except for the latest manual patches, i didn't do
> anything groundbreaking these last 3 months, which makes
> me feel dumb and uncomfortable. work sucks for that
> matter, but it pays so good that i feel almost guilty :-P
>
> call for participation :
> - whoever wants to participate with VHDL, manual, desing...
> - whoever wants an account at seul.org
> - whoever asks for the use of Cadence tools
>
> please voice up on the list.
>
> > like someone said, shit happens,
> hmm sure. we're so used to it that we didn't care :-)
>
> > forget 17c3,
> no, we should remember the lesson.
> But things weren't easy at 16C3 either.
> Compared to last year, if we balance with the
> number of people, 17C3 seems to work marvelously !
> it is just the fact that more people were present
> and the work is not the same as on the Net.
>
> > success is the sweetest form of revenge.
> yup.
> > Once core is around, you multi cpu dudes can work on your
> > own multiprocessors.
> i propose that they don't stop, but try to organise their
> own stuff. Of course we collaborate, but as pointed out on another
> precedent mail, the goals were completely different.
> We will spare a lot of troubles and useless discussion,
> and we will restart to work, if the people make their own group.
> yes, this sounds like a "split", but it's better than a
> complete give-up. They started so well that it would
> be sad if they stopped straight now...
>
> > Jeff Davies
>
>
>
> Marco Al wrote:
> > From: <jeff@llandre.freeserve.co.uk>
> >
> > > smt as used by intel etc seems to share the whole of
> > > system ram between all cpus which is dumb.
> > > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> > > but they also share the third sdram for comms.
> >
> > IMO thats combining the bad aspects of NUMA and message passing c= ombined
in a
> > single framework...
>
> i'll comment with a ":-D"
>
> > If you want to make a processor which can scale decently in
multiprocessor
> > setups you have to know which scheme you will be using at least i= n time
for the
> > design of the MMU.
>
> if you have an enhancement to propose to the TLB or the protected memo= ry
system,
> i'm listening :-)
>
> > Marco
>
> Michael Riepe wrote:
> > On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote: > > [...]
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface. So in th= e intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> >
> > It depends.  If you use ccNUMA or COMA, there will be a lot = of
additional
> > traffic to keep the caches up-to-date.  And if you're runnin= g certain
> > parallelized tasks with high communication overhead, even Gbps et= hernet
> > becomes too slow.
>
> to me, Gb serial link is too slow and has too much latency anyway... >
> > > > buses are known, used and they work, but some people he= re want a
"multimaster"
> > > > bus. This means that the bandwidth is drawn by several = points and
the bus
> > > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidt= h per CPU,
equal to
> > > > the available bandwidth provided by the bus and divided= by N CPU).
> > > >
> > > > that's what i try to avoid.
> >
> > It's actually worse than B=3DL/N.  Don't forget the overhead= for bus
> > arbitration and transfer direction turn-arounds.  I wouldn't= be
surprised
> > at all if bandwidth drops below B=3DL/N/2.  If you want to c= ome closer
> > to B=3DL/N, you need to do large block transfers (unreasonable ex= cept for
> > mass storage access), and then you'll get problems with latencies= (other
> > devices have to wait until the transfer is over and a new bus mas= ter
> > can be elected).  Another problem is that arbitration and tu= rn-around
> > times rise dramatically when the bus becomes longer (signal delay= ,
> > bad impedance matching when tri-state drivers are used, and so on= ).
>
> that's why i try to keep the f-bus (the one that connects the F-chips = and
> the I/Os together) as simple as possible.
>
> > > There are always possible traffic Jam. How do you manage whe= n 2 nodes
> > > try to speak to the same nod ? You have to manage something = to avoid
> > > losing informations.
> >
> > They will have to share the available bandwidth.  The G-Chip= will have
> > to queue the second message while it's sending the first one.
>
> well, the messages that i envision are packets with 256-bits of data > and an address with some additional info (byte ordering of the transfe= r,
> if we start from the end or the middle of the line etc...)
>
> it's also a transactional bus, with around 16 transaction, so the
> FIFO is 16*(256+64) bits. when the FIFO overflows, the transaction IDs=
> are not allowed and the bus stalls. of course, you can continue to
interleave
> other packets (not addressed to the slow port) so you can still benefi= t
> from the remaining bandwidth if you have to transfer a lot of data
> simultaneously with a 3rd port.
>
> mmmh, the g-chip is getting interesting :-)
>
> >  This could be avoided by putting 4 F-Bus interfaces into th= e CPU itself
> no, the "convergence" problem would remain anyway, but at a = larger
(system) scale...
> OTOH, the single-F-bus bottleneck would disappear but we'll need :
> 250 (SDRAM) + 4 * 100 (F-bus) pins, or roughly 700 pins for a f-cpu. > i would like one, it looks sexy, but it might be rather... expensive.<= BR> > and the PCB routing might be ... tricky.... oh yes, it's sexy ;-)
>
> > (did anybody say "transputer"?), which makes the G-chip= obsolete
> > except for peripheral I/O and message routing/switching, or by us= ing a
> > faster (4x) link between F-CPU and G-chip.
> i think it's pointless. Every f-bus interface can be "rated"= at a certain
> maximum speed. If you have a 200MHz f-cpu connected to a 150MHz g-chip= ,
you'll
> run at 150 MHz everywhere (f-cpu's f-bus interface and I/Os that can d= o
more
> than 150MHz). OTOH, if the g-chip is connected to one 100MHz (or even = 20
> or anything) device, it won't slow down the whole system (unless this = link
> becomes the bottleneck because of its critical use by the SW, like ...=
swapping
> etc...)
>
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same but the
> > > > address is split into 3 fields that are interpreted as = an
independent ring address.
> >
> > A ring is actually much better than a bus because it is a unidire= ctional
> > device (no change of transfer direction, no tri-state buffers nec= essary,
> > faster signalling) and arbitration is both simpler and faster (e.= g.
token
> > ring).  The members of the ring still share the available ba= ndwidth,
> > but you come closer to B=3DL/N.  Per-CPU bandwidth is still = limited,
though.
>
> in a real system or computer, the ring is often either folded (with pa= irs
of
> nodes) or dual-way. So that's why it goes from L/N/2 to L/N : the bus<= BR> > is physically 2x wider if you "cut" it somewhere.
>
> > > > here, you don't have 1 ring but x*y*z rings. It means t= hat there is
> > > > no bandwidth problem at all, because each CPU communica= tes with its
6 neighbours.
> > > > It works very well, it can be tweaked to become "f= ault tolerant"
(through dynamic
> > > > node addresses) and scales perfectly (almost linearly w= ith the CPU
number).
> > > >
> > > So !
> > [...]
> >
> > scales "perfectly" <EM>as long as the number of m= embers per ring is
limited</EM>.
> > Sorry for shouting ;)
>
> :-D
>
> everybody has his/her own criteria...
>
> > For highest-speed n-to-n communication, use direct connections. > if you can rewrap the wires in less than a millisecond, it's ok for me= ;-P
>
> > Since this doesn't scale at all, you need to find a compromise wh= en
> > the number of CPUs increases -- switches or crossbars, trees or r= ings.
> > In any case, the solution depends on the work the system has to d= o.
> > With the drafted G-chip with 4 links, we could build
> >
> >         - a 4-CPU directl= y-connected system
> >         - a single ring (= double ring requires 5 links, 1 for CPU)
> >         - a binary or tri= nary tree (USB-style)
> >         - a flat hexagona= l `beehive' structure
> >         - a cube
> >         - ...
> >
> > This is a pretty long list of options, isn't it?  Let the im= plementor
(or
> > system integrator) choose from this list; we don't have to care.&= nbsp; We
just
> > need to make sure that the G-chip is versatile enough to support = at
least
> > two or three of the most common topologies, and probably mixed topologies
> > (like a tree or ring of directly-connected clusters, for example)= .
> > Preferably with auto-sensing capabilities =E0 la USB, i.e. the st= ructure
> > is determined at run (or boot) time.
>
> yup. Let's stick to that... Lego brick ? :-)
>
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
>
>
>
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 20
>    Date: Mon, 08 Jan 2001 09:05:53 +0100 (CET)
>    From: "maurizio zoboli" <maurizio.zobol= i@unimo.it>
> Subject: REMOVE
>
> On Sun, 7 Jan 2001 16:17:04 -0000, Didi wrote:
>
> >
> >----- Original Message -----
> >From: "maurizio zoboli" <maurizio.zoboli@unimo.it>=
> >To: <f-cpu@egroups.com>
> >Sent: Sunday, January 07, 2001 10:18 AM
> >Subject: [f-cpu] REMOVE
> >
> >
> >> On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com w= rote:
> >>
> >> >Expand your business with
> >> >    Email Marketing!
> >> >
> >> >Market your product or service
> >> >     to MILLIONS!
> >> >
> >> >Don't waste another minute...
> >> >
> >> >Click Reply with your name,
> >> >telephone number and the
> >> >product or service you wish
> >> >to market. We will be in
> >> >touch with you shortly!
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Removal Instructions
> >> >****************************
> >> >To be removed from this list
> >> >please reply with "REMOVE"
> >> >in the subject.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Expand your business with
> >> >    Email Marketing!
> >> >
> >> >Market your product or service
> >> >     to MILLIONS!
> >> >
> >> >Don't waste another minute...
> >> >
> >> >Click Reply with your name,
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> Prof. Maurizio Zoboli
> >> Dipartimento di Scienze dell'Ingegneria
> >> Universita' di Modena e Reggio Emilia
> >> via Vignolese 905
> >> I-41100 Modena, Italy
> >> Tel.: +39 059 2056163
> >> Fax: +39 059 2056129
> >> e-mail: maurizio.zoboli@unimo.it
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
> Prof. Maurizio Zoboli
> Dipartimento di Scienze dell'Ingegneria
> Universita' di Modena e Reggio Emilia
> via Vignolese 905
> I-41100 Modena, Italy
> Tel.: +39 059 2056163
> Fax: +39 059 2056129
> e-mail: maurizio.zoboli@unimo.it
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 21
>    Date: Mon, 08 Jan 2001 09:08:30 +0100 (CET)
>    From: "maurizio zoboli" <maurizio.zobol= i@unimo.it>
> Subject: REMOVE
>
> On Sun, 7 Jan 2001 16:28:07 -0000, Didi wrote:
>
> >
> >----- Original Message -----
> >From: "Didi" <flei@wanadoo.fr>
> >To: <f-cpu@egroups.com>
> >Sent: Sunday, January 07, 2001 4:17 PM
> >Subject: [f-cpu] REMOVE
> >
> >
> >>
> >> ----- Original Message -----
> >> From: "maurizio zoboli" <maurizio.zoboli@unimo.i= t>
> >> To: <f-cpu@egroups.com>
> >> Sent: Sunday, January 07, 2001 10:18 AM
> >> Subject: [f-cpu] REMOVE
> >>
> >>
> >> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.= com wrote:
> >> >
> >> > >Expand your business with
> >> > >    Email Marketing!
> >> > >
> >> > >Market your product or service
> >> > >     to MILLIONS!
> >> > >
> >> > >Don't waste another minute...
> >> > >
> >> > >Click Reply with your name,
> >> > >telephone number and the
> >> > >product or service you wish
> >> > >to market. We will be in
> >> > >touch with you shortly!
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >Removal Instructions
> >> > >****************************
> >> > >To be removed from this list
> >> > >please reply with "REMOVE"
> >> > >in the subject.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >Expand your business with
> >> > >    Email Marketing!
> >> > >
> >> > >Market your product or service
> >> > >     to MILLIONS!
> >> > >
> >> > >Don't waste another minute...
> >> > >
> >> > >Click Reply with your name,
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > Prof. Maurizio Zoboli
> >> > Dipartimento di Scienze dell'Ingegneria
> >> > Universita' di Modena e Reggio Emilia
> >> > via Vignolese 905
> >> > I-41100 Modena, Italy
> >> > Tel.: +39 059 2056163
> >> > Fax: +39 059 2056129
> >> > e-mail: maurizio.zoboli@unimo.it
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
> Prof. Maurizio Zoboli
> Dipartimento di Scienze dell'Ingegneria
> Universita' di Modena e Reggio Emilia
> via Vignolese 905
> I-41100 Modena, Italy
> Tel.: +39 059 2056163
> Fax: +39 059 2056129
> e-mail: maurizio.zoboli@unimo.it
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 22
>    Date: Tue, 08 Jan 2001 12:14:31 +0100
>    From: Vanderhoeven Steve <vanderho@essi.fr> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
>
> > Vanderhoeven Steve wrote:
> > > > If you connect more than 2 CPU on the same bus, they co= mpete for the
ressource
> > > > and the bottleneck gets even narrow.
> > > atm?
> > hmm do you mean "At The Moment" or "ATM network&qu= ot; ?...
>
> I was just sugesting you to look at the idea of ATM networks. It has service like reserving a part of the bandwidth for communication between tw= o
points.
>
> Steve
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
>
eGroups Sponsor=
3D"Wireless
From DuaneMHunt170976@aol.com Mon Jan 8 19:22:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01577 for ; Tue, 9 Jan 2001 00:43:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 00:43:17 +0100 (MET) Received: (qmail 8910 invoked by uid 0); 8 Jan 2001 19:05:08 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx04) with SMTP; 8 Jan 2001 19:05:08 -0000 X-eGroups-Return: sentto-1101623-1889-978978211-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 08 Jan 2001 18:23:34 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 18:23:24 -0000 Received: (qmail 48261 invoked from network); 8 Jan 2001 18:22:15 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 8 Jan 2001 18:22:15 -0000 Received: from unknown (HELO imo-r02.mx.aol.com) (152.163.225.2) by mta2 with SMTP; 8 Jan 2001 18:22:15 -0000 Received: from DuaneMHunt170976@aol.com by imo-r02.mx.aol.com (mail_out_v28.35.) id a.14.e099cfe (17533) for ; Mon, 8 Jan 2001 13:22:07 -0500 (EST) Message-ID: <14.e099cfe.278b5f4e@aol.com> To: f-cpu@egroups.com X-Mailer: 6.0 sub 36 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 13:22:06 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] This project really sucks. Content-Type: multipart/alternative; boundary="part1_14.e099cfe.278b5f4e_boundary" X-UIDL: 71710053814e9a3e364b4a58dcd4bd04 Status: R X-Status: N --part1_14.e099cfe.278b5f4e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit NOTE IF YOU DONT LIKE IT YOU CAN GO!! IF YOUR JUST HERE TO SPAM US ALL THEN THAT IS SAD LIFE YOU HAVE !! READ AND JOIN IN THE CHAT BY EMAIL OR JUST READ AND LEARN BUT BUT DONT MON ABOUT IT --part1_14.e099cfe.278b5f4e_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit NOTE

IF YOU DONT LIKE IT YOU CAN GO!!

IF YOUR JUST HERE TO SPAM US ALL
THEN THAT IS SAD LIFE YOU HAVE !!

READ AND JOIN IN THE CHAT BY EMAIL
OR JUST READ AND LEARN
BUT BUT DONT MON ABOUT IT
eGroups Sponsor
Click Here!
--part1_14.e099cfe.278b5f4e_boundary-- From DuaneMHunt170976@aol.com Mon Jan 8 20:56:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01586 for ; Tue, 9 Jan 2001 00:43:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 00:43:19 +0100 (MET) Received: (qmail 4755 invoked by uid 0); 8 Jan 2001 20:00:48 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx05) with SMTP; 8 Jan 2001 20:00:48 -0000 X-eGroups-Return: sentto-1101623-1890-978984007-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 08 Jan 2001 20:00:10 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 20:00:06 -0000 Received: (qmail 56505 invoked from network); 8 Jan 2001 19:56:39 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 8 Jan 2001 19:56:39 -0000 Received: from unknown (HELO imo-d03.mx.aol.com) (205.188.157.35) by mta1 with SMTP; 8 Jan 2001 19:56:38 -0000 Received: from DuaneMHunt170976@aol.com by imo-d03.mx.aol.com (mail_out_v28.35.) id a.c.f9b91e8 (16785) for ; Mon, 8 Jan 2001 14:56:32 -0500 (EST) Message-ID: To: f-cpu@egroups.com X-Mailer: 6.0 sub 36 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 14:56:32 EST Reply-To: f-cpu@egroups.com Subject: [f-cpu] Hay Content-Type: multipart/alternative; boundary="part1_c.f9b91e8.278b7570_boundary" X-UIDL: bddc4718c05e29693ce5a7ffad792185 Status: R X-Status: N --part1_c.f9b91e8.278b7570_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hay i didnt send any ADVERT on that LAST EMAIL i sent what gives --part1_c.f9b91e8.278b7570_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hay i didnt send any ADVERT on that LAST EMAIL i sent what gives
eGroups Sponsor
Click here!
--part1_c.f9b91e8.278b7570_boundary-- From Nicolas Boulay Mon Jan 8 23:26:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01607 for ; Tue, 9 Jan 2001 00:43:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 00:43:24 +0100 (MET) Received: (qmail 32408 invoked by uid 0); 8 Jan 2001 22:21:31 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx08) with SMTP; 8 Jan 2001 22:21:31 -0000 X-eGroups-Return: sentto-1101623-1892-978992478-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 08 Jan 2001 22:21:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 22:21:17 -0000 Received: (qmail 51792 invoked from network); 8 Jan 2001 22:19:37 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 Jan 2001 22:19:37 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 8 Jan 2001 22:19:37 -0000 Received: from ifrance.com (nas24-20.vlt.club-internet.fr [195.36.223.20]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA15792 for ; Mon, 8 Jan 2001 23:19:33 +0100 (MET) Message-ID: <3A5A3E91.51711AF@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <5.0.0.25.2.20010105014049.00a6ed70@pop.free.fr> <3A552C7C.CFF5D29E@ifrance.com> <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 23:26:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 71ad951eb814c3b809d3c0c3cbafacf0 Status: R X-Status: N

Michael Riepe a =E9crit :
>
> On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote:
> [...]
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
>
> It depends.  If you use ccNUMA or COMA, there will be a lot of ad= ditional
> traffic to keep the caches up-to-date.  And if you're running cer= tain
> parallelized tasks with high communication overhead, even Gbps etherne= t
> becomes too slow.
>


That's why i said "in the best case". But remember that a 64 bit = 133 Mhz
run at 1Go/s so 8 gigabits links run at the same speed. I would like to
create something to optimise the transfert (my extended MMU).

> > > I am trying to find the "least common denominator"= for a F-CPU system
> > > that can range from 1 CPU to any arbitrary number of CPUs (j= ust like
> > > the register width : not bound to anything). let's take a fe= w cases,
> > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system"= should also scale
> > > to much more CPUs : the widest systems today (see the monter= s at the LANL)
> > > can scale to more than 10K CPU, so let's round up to 65536.<= BR> > > >
> > > now let's compare the alternatives...
> > >
> > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it= 's disastrous
> > > with more CPU.
> > >
> > > buses are known, used and they work, but some people here wa= nt a "multimaster"
> > > bus. This means that the bandwidth is drawn by several point= s and the bus
> > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per= CPU, equal to
> > > the available bandwidth provided by the bus and divided by N= CPU).
> > >
> > > that's what i try to avoid.
>
> It's actually worse than B=3DL/N.  Don't forget the overhead for = bus
> arbitration and transfer direction turn-arounds.  I wouldn't be s= urprised
> at all if bandwidth drops below B=3DL/N/2.  If you want to come c= loser
> to B=3DL/N, you need to do large block transfers (unreasonable except = for
> mass storage access), and then you'll get problems with latencies (oth= er

Not really. Don't only think like SRAM READ, but you can make burst
transfert like for COMA arch.

> devices have to wait until the transfer is over and a new bus master > can be elected).  Another problem is that arbitration and turn-ar= ound
> times rise dramatically when the bus becomes longer (signal delay,
> bad impedance matching when tri-state drivers are used, and so on). >

So, hourra for the ring ?

> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as well,
> > > and it's my "hammer" argument when i try to promot= e point to point links.
> > > We spare the (distributed) control logic (all the nasty dead= lock stuffs etc)
> >
> > There are always possible traffic Jam. How do you manage when 2 n= odes
> > try to speak to the same nod ? You have to manage something to av= oid
> > losing informations.
>
> They will have to share the available bandwidth.  The G-Chip will= have
> to queue the second message while it's sending the first one.  Th= is
> could be avoided by putting 4 F-Bus interfaces into the CPU itself
> (did anybody say "transputer"?), which makes the G-chip obso= lete
> except for peripheral I/O and message routing/switching, or by using a=
> faster (4x) link between F-CPU and G-chip.
>

You can't have the same bandwith between memory and the fcpu and between the fcpu and the network. Memory will be always quicker. I don't like to have 2 seperate chips because you will have a link between them. This
"waste" could be used instead for simple serial link. Using commo= n
serial link is to replace wire by speed. So the "true" bandwith b= etween
the memory and the network could be maximum in a one chip system. If you have 4 link by g-chip, 3 links speak to the same node but you have only
the 1/3 to communicate to the node memories, but if you have one chip,
it's easy to have 3 times the bandwith of the f-bus to the memory.

> > > and it's very simple to implement. the PCB is simpler, too.<= BR> > > >
> > > If you connect more than 2 CPU on the same bus, they compete= for the ressource
> > > and the bottleneck gets even narrow.
> > >
> >
> > Yes, but less drastically as intel SMP.
> >
> > > On the pin count vs bandwidth argument, it's similar. Of cou= rse, we can find
> > > a lot of counter-examples and special cases, but the example= of the broadcast
> > > is not the best one. Most of the requests are from one node = to a single other
> >
> > In fact, not. It depend how much process communicate between them= . And
> > sometimes the only [simple] way to find a "moving" ress= ources is to send
> > a braodcast.
>
> Yep.  Very common when (simple) COMA is used, IIRC.
>
In NORMA arch, too, no ?

> > > and here, the efficiency of a bus drops dramatically ! for a= N-CPU system,
> > > the efficiency is of 2 used bus interfaces for N bus interfa= ces (you can
> > > replace "bus interface" with "pin"), 2/N= is similar to the 1/N scheme
> > > (if we speak about the "big O" or complexity). Thi= s means that :
> > > the more CPU, the least efficient ! you'll see that the best= way to avoid
> > > this is by having as few CPU by link as possible, and the mi= nimum is 2.
> > > that's "point to point"...
> > >
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2 dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same but the
> > > address is split into 3 fields that are interpreted as an in= dependent ring address.
>
> A ring is actually much better than a bus because it is a unidirection= al
> device (no change of transfer direction, no tri-state buffers necessar= y,
> faster signalling) and arbitration is both simpler and faster (e.g. to= ken
> ring).  The members of the ring still share the available bandwid= th,
> but you come closer to B=3DL/N.  Per-CPU bandwidth is still limit= ed, though.
>

The idea is to have a much higher bandwith for the link. In some year
will come the 10 000base T, so maybe 10 Go/s will be possible ;p.

> > In the flight back to France, we have spoken about ring of ring.(= and
> > called the architecture the lord of the ring ;p). A ring is compo= sed
> > around 8 to 16 card (cpu+ram or IO). A card could be used to comm= unicate
> > with other ring. Maybe it's possible to grow in hierachy without = to much
> > trouble.
> >
> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6 neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant" (through dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU number).
> > >
> > So !
> [...]
>
> scales "perfectly" <EM>as long as the number of member= s per ring is limited</EM>.
> Sorry for shouting ;)
>

8 or 16, is enough, no ?

> For highest-speed n-to-n communication, use direct connections.
> Since this doesn't scale at all, you need to find a compromise when > the number of CPUs increases -- switches or crossbars, trees or rings.=
> In any case, the solution depends on the work the system has to do. > With the drafted G-chip with 4 links, we could build
>
>         - a 4-CPU directly-con= nected system
>         - a single ring (doubl= e ring requires 5 links, 1 for CPU)
>         - a binary or trinary = tree (USB-style)
>         - a flat hexagonal `be= ehive' structure
>         - a cube
>         - ...
>
> This is a pretty long list of options, isn't it?  Let the impleme= ntor (or
> system integrator) choose from this list; we don't have to care. = We just
> need to make sure that the G-chip is versatile enough to support at le= ast
> two or three of the most common topologies, and probably mixed topolog= ies
> (like a tree or ring of directly-connected clusters, for example).
> Preferably with auto-sensing capabilities =E0 la USB, i.e. the structu= re
> is determined at run (or boot) time.
>

It isn't so simple. Topology is importante when you choose your
algorithme for shared memory. You can choose to make it by SW (like
SUN). Or by HW, so the network must be known. If you use mostly
broadcast, a ring is fine (in a cube you lost a lot of bandwith), a
point to point is quick, but you have to make some routing and you have
to know were is a ressource !

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
nicO
eGroups Sponsor=
3D"Click
From james729@japan.com Mon Jan 8 22:03:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01623 for ; Tue, 9 Jan 2001 00:43:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 00:43:30 +0100 (MET) Received: (qmail 4251 invoked by uid 0); 8 Jan 2001 22:35:06 -0000 Received: from c3.egroups.com (208.50.99.225) by 10.1.4.112 (mx12) with SMTP; 8 Jan 2001 22:35:06 -0000 X-eGroups-Return: sentto-1101623-1891-978989047-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 08 Jan 2001 21:24:12 -0000 X-Sender: james729@japan.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 21:24:07 -0000 Received: (qmail 87884 invoked from network); 8 Jan 2001 21:23:22 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 8 Jan 2001 21:23:22 -0000 Received: from unknown (HELO gmaquest.com.) (202.61.64.37) by mta3 with SMTP; 8 Jan 2001 22:24:27 -0000 Received: (from uucp@localhost) by gmaquest.com. (8.9.1b+Sun/8.9.1) id FAA11394; Tue, 9 Jan 2001 05:27:46 -0800 (GMT) Received: from 1cust233.tnt12.dfw5.da.uu.net(63.44.237.233) by gmaquest.com. via smap (V2.1) id xmao11176; Tue, 9 Jan 01 05:26:37 -0800 Message-ID: <000048734e02$0000429c$000045ae@mis.trebley.com> To: X-Priority: 3 X-MSMail-Priority: Normal From: james729@japan.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 08 Jan 2001 15:03:09 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] A DishNetwork sys. Free Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 35fbbbeba10ce168c7d5a3902d238809 Status: R X-Status: N   FREE SATELLITE T.V. SYSTEM

Watch over 500 channels of Digital Broadcast quality television on
your own FREE satellite television system. These new Digital satellite
systems use the new 20 inch satellite dish antenna.

For a limited time we'll give you this top of the line
Digital Satellite System for FREE!
We'll even include Free installation and 3 FREE months of all the movie
channels!

This is the New DishNetwork 3922 digital satellite system. It has
interactive T.V capabilities , on screen program guide, 2 dual LNB's, stereo
CD sound and infrared remote. Normal cost for all these items is over $500
but we're giving it away for FREE!

All you have to do is call us to arrange delivery and order the channels you
want to receive. Satellite television offers over 500 channels of all
digital broadcast video quality, movies, sports, specials, network , cables
channels and more all with CD audio stereo sound. You may even get local
channels now. Don't miss this offer, it's only available while supplies last.


For your Free Satellite System call  877-699-8548  24 hours a day.


Authorized DishNetwork dealer
                                                                                                               
Under Bill s.1618 TITLE III passed by the 105th US Congress, this letter cannot be considered spam as long as the sender includes contact information and removal instructions.
This is a one-time e-mail transmission. No request for removal is necessary
eGroups Sponsor
Click here!
From Michael Riepe Mon Jan 8 15:47:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01644 for ; Tue, 9 Jan 2001 00:43:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 00:43:37 +0100 (MET) Received: (qmail 29476 invoked by uid 0); 8 Jan 2001 23:28:07 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx07) with SMTP; 8 Jan 2001 23:28:07 -0000 X-eGroups-Return: sentto-1101623-1893-978995578-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 08 Jan 2001 23:13:18 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 8 Jan 2001 23:12:57 -0000 Received: (qmail 15797 invoked from network); 8 Jan 2001 23:08:57 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Jan 2001 23:08:57 -0000 Received: from unknown (HELO studserv.stud.uni-hannover.de) (130.75.176.3) by mta1 with SMTP; 8 Jan 2001 23:08:57 -0000 Received: from tribble.stud.uni-hannover.de (a126.home.uni-hannover.de [130.75.232.126]) by studserv.stud.uni-hannover.de (8.11.2/8.11.2/MX/check_local4.2) with ESMTP id f08N8SK19810 for ; Tue, 9 Jan 2001 00:08:41 +0100 (MET) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00713; Mon, 8 Jan 2001 15:47:42 +0100 Message-ID: <20010108154742.60671@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> X-Mailer: Mutt 0.84e In-Reply-To: <3A59189B.EC5FD29D@starpower.net>; from Alan Grimes on Sun, Jan 07, 2001 at 08:32:11PM -0500 X-eGroups-From: Michael Riepe From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 8 Jan 2001 15:47:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] This project really sucks. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 79baa441a2821de70d693e3bed3d98e3 Status: R X-Status: N On Sun, Jan 07, 2001 at 08:32:11PM -0500, Alan Grimes wrote:
[...]
> Pleas understand that I am running Windows 3.11 on an Athalon processor.

I only have a slow Pentium.  So what?

> The PC is far too fucked for me to write my own OS. (I have discovered
> this through great labor). But I *can* write an OS for F-cpu (I hope).
>
> I am hurting.

Me too.

[...]
> > Demands?  F*ck off.  You have no right to demand *anything*.
>
> Maybe not. But the fact that you can't take an ounce of criticism with
> regards to this project is equally un-cool. I have been observing this
> project practicaly from day one. I have seen many things not happen. ;)

Criticism != destructivity.  Saying that "This project sucks" is not
criticism, it's the Felix-von-Leitner way.

I've browsed the mailing list archive before I joined.  I've seen many
things not happen, too.  And I know that you have been there all the time,
and you didn't make things happen either.  I've seen people join and quit
(sometimes in anger) because things didn't happen or they were unable to
find a compromise that satisfied everybody.  Now, things actually *do*
happen -- the ISA is kind of stable, and we have some pieces of code
already -- but you still aren't satisfied.

> This posting was my attempt to encapsulate all the observations I made
> into a single simple workable agenda for making things happen. If you
> can't take it then go work for a company, you have nothing valuble to
> contribute to an open-source project if you canot accept contributions.

Demands != contributions.

"Making things happen" means, in the context of a free (GNU-style)
project, that you *do* something.  If you have your own company, you can
sit around and manage things, demand things, tell your employees what
to do next and so on -- in a free project, people decide themselves.
Maybe they could get things done faster if they had a management, but
they usually don't WANT one.  The day this project is managed like a
company (by an individual or a committee) is my last day.  Farewell,
goodbye, hasta la vista, baby.

[...]
> I am sorry that linux users tend to be so goddamned dense that they
> can't see or accept a simple and logical suggestion even when it is
> explained to them!  No wonder their operating system is as terrible as
> it is...

Linux users are (and want to be) free to do what they like.
The results may look terrible, but there *are* results, after all.

[...]
> Hey! Wanna make a CPU?  I not only can but I will make it happen. This
> is what needs to be done.

"We are Alan Grimes of Borg.  You will make a CPU for us. Resistance
is futile."

Well, you can try.  Come and assimilate me.  Good luck.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From whygee@club-internet.fr Tue Jan 9 11:41:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00365 for ; Tue, 9 Jan 2001 16:54:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 16:54:31 +0100 (MET) Received: (qmail 967 invoked by uid 0); 9 Jan 2001 10:41:49 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx13) with SMTP; 9 Jan 2001 10:41:49 -0000 X-eGroups-Return: sentto-1101623-1895-979036905-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 09 Jan 2001 10:41:47 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 10:41:44 -0000 Received: (qmail 32500 invoked from network); 9 Jan 2001 10:41:44 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 9 Jan 2001 10:41:44 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 9 Jan 2001 11:42:49 -0000 Received: (from mnet@localhost) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id LAA18134 for f-cpu@egroups.com; Tue, 9 Jan 2001 11:41:42 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 11:41:42 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c7eca1685956f5b937d3234bbe7b4a69 Status: R X-Status: N hi,

some oil on the fire...

>De: Nicolas Boulay <nicolas.boulay@ifrance.com>
>Michael Riepe a =E9crit :
>>
>> On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote: >> [...]
>That's why i said "in the best case". But remember that a 64 = bit 133 Mhz
>run at 1Go/s so 8 gigabits links run at the same speed.
did you forget that i showed that it had more latency ?

> I would like to
>create something to optimise the transfert (my extended MMU).
do it and publish the draft, damnit !
but please don't use "magic words" but real physical
names for the units (ie : compare, register, add ... forget
words like "manager" or "handler" that don't mean anyth= ing)


>> It's actually worse than B=3DL/N.  Don't forget the overhead = for bus
>> arbitration and transfer direction turn-arounds.  I wouldn't = be surprised
>> at all if bandwidth drops below B=3DL/N/2.  If you want to co= me closer
>> to B=3DL/N, you need to do large block transfers (unreasonable exc= ept for
>> mass storage access), and then you'll get problems with latencies = (other
>
>Not really. Don't only think like SRAM READ, but you can make burst tra= nsfert like for COMA arch.

burst are fine, but when you want to transfer a simple semaphore,
it takes a lot of time for the setup (just like vector vs SIMD :
the time to fill the vector pipeline influences the performance)

>> devices have to wait until the transfer is over and a new bus mast= er
>> can be elected).  Another problem is that arbitration and tur= n-around
>> times rise dramatically when the bus becomes longer (signal delay,=
>> bad impedance matching when tri-state drivers are used, and so on)= .
>>
>So, hourra for the ring ?

no, houra for unidirectional buses.
your ring uses them, but other topologies use them too.


>> They will have to share the available bandwidth.  The G-Chip = will have
>> to queue the second message while it's sending the first one. = ; This
>> could be avoided by putting 4 F-Bus interfaces into the CPU itself=
>> (did anybody say "transputer"?), which makes the G-chip = obsolete
>> except for peripheral I/O and message routing/switching, or by usi= ng a
>> faster (4x) link between F-CPU and G-chip.
>>
>
>You can't have the same bandwith between memory and the fcpu and betwee= n
>the fcpu and the network. Memory will be always quicker. I don't like t= o
>have 2 seperate chips because you will have a link between them. This >"waste" could be used instead for simple serial link. Using c= ommon
>serial link is to replace wire by speed. So the "true" bandwi= th between
>the memory and the network could be maximum in a one chip system. If yo= u
>have 4 link by g-chip, 3 links speak to the same node but you have only=
>the 1/3 to communicate to the node memories, but if you have one chip,<= BR> >it's easy to have 3 times the bandwith of the f-bus to the memory.

Fine but you forget about pin counts. And pin counts scales
with price too. not only chip price but PCB routing and layer number....
a 800-pin chip takes months to route.

>> > In fact, not. It depend how much process communicate between = them. And
>> > sometimes the only [simple] way to find a "moving" = ressources is to send
>> > a braodcast.
>>
>> Yep.  Very common when (simple) COMA is used, IIRC.
>>
>In NORMA arch, too, no ?

but i don't care about your norma, coma, IIRC etc ...
we should speak about the core... damnit...


>> A ring is actually much better than a bus because it is a unidirec= tional
>> device (no change of transfer direction, no tri-state buffers nece= ssary,
>> faster signalling) and arbitration is both simpler and faster (e.g= . token
>> ring).  The members of the ring still share the available ban= dwidth,
>> but you come closer to B=3DL/N.  Per-CPU bandwidth is still l= imited, though.
>
>The idea is to have a much higher bandwith for the link.
so it's more expensive and consumes more power !
in CMOS-like, if you  drive the signal 10x faster, you consume
10x more. and your serial link is not going to use 1V signalling.

> In some year
>will come the 10 000base T, so maybe 10 Go/s will be possible ;p.

no. never. do NEVER believe peak rates.
you never burst a 10 billion bit stream .


>> > So !
>> [...]
>>
>> scales "perfectly" <EM>as long as the number of me= mbers per ring is limited</EM>.
>> Sorry for shouting ;)
>
>8 or 16, is enough, no ?
>
should be. 16x16x16 =3D 4096
if we could go to 32^3, we'd use 16 bit node addressing.

>It isn't so simple. Topology is importante when you choose your
>algorithme for shared memory.
both are in the hands of the end user.
EOT.

> You can choose to make it by SW (like
>SUN). Or by HW, so the network must be known. If you use mostly
>broadcast, a ring is fine (in a cube you lost a lot of bandwith), a
>point to point is quick, but you have to make some routing and you have=
>to know were is a ressource !
fine. Prove me that you can't know where the ressources are.

I WANT a node with 6 CPU, a HDD and 6 link controllers.
this way, i could build a cube by assembling the nodes.
i don't care about the SW.

happy new year and bonjour chez vous.

>>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-h= annover.de>
>>  "All I wanna do is have a little fun before I die"=
>nicO
YG
eGroups Sponsor=
3D"Click
Click here to Win a 2001 Acura MDX
From "Marco Al" Tue Jan 9 14:43:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00446 for ; Tue, 9 Jan 2001 16:54:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 16:54:53 +0100 (MET) Received: (qmail 3752 invoked by uid 0); 9 Jan 2001 13:36:08 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx07) with SMTP; 9 Jan 2001 13:36:08 -0000 X-eGroups-Return: sentto-1101623-1896-979047360-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 09 Jan 2001 13:36:06 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 13:35:59 -0000 Received: (qmail 97230 invoked from network); 9 Jan 2001 13:35:59 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Jan 2001 13:35:59 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 9 Jan 2001 13:35:58 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id OAA28715 for ; Tue, 9 Jan 2001 14:35:57 +0100 (MET) Message-ID: <000d01c07a42$30b21020$29e65982@student.utwente.nl> To: References: <200101071948.f07Jmrf15344@essi.essi.fr> <3A593EA2.6352FA1@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 14:43:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: 17. Chaos Communication Congress - Wie war ehr? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dfef14f016186d616de2d33583b71cd3 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> often, "higher" hierarchies have a lower bandwidth, this makes the compilation
> still more difficult (the mapping of the algorithm to the architecture is
> more complex if you have more levels). That's why the T3D is so seducing :-))

If the latency and bandwith are always better then the complexity is not a
problem, you can choose to ignore the potential for extra performance without
cost.

> > My opinion also kind of depends on where the motherboard chipset
> > functionality would be present and how many pins that would need.
>
> examples ?

Well if you could easily get away putting 4 ports on a motherboard chipset
(which would already have a lot of pins, a little less then usual since it
doesnt have memory attached but still) then there isnt much problem, but I doubt
the pin count for the ports would be low enough.

> if some of you can cope with a EV-4 slot, it will be ok for me...

EV-4? Mobo's are not exactly readily available.

> it can also be left up to the end user...

Well thats you the first time you get anything made isnt it? :)

> if you have an enhancement to propose to the TLB or the protected memory
> system, i'm listening :-)

I am no expert, and AFAICS neither in the market or in the academia theres a
clear consensus... so its hard for me to suggest anything usefull apart from the
blatantly obvious. On top of a cachability flag a write-through caching flag
would be handy. Maybe some instrumentation registers per tlb entry to count
accesses for intelligent page migration?

> mmmh, the g-chip is getting interesting :-)

Only the g-chip, shouldn't the protocol you use be the same one you use to
communicate with the mobo chipset?

Marco
eGroups Sponsor
Click here for Business information
Click here for Business information
From Konrad Gajewski Tue Jan 9 14:56:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00452 for ; Tue, 9 Jan 2001 16:54:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 09 Jan 2001 16:54:55 +0100 (MET) Received: (qmail 23693 invoked by uid 0); 9 Jan 2001 14:07:45 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by 10.1.4.119 (mx19) with SMTP; 9 Jan 2001 14:07:45 -0000 X-eGroups-Return: sentto-1101623-1897-979049252-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 09 Jan 2001 14:07:40 -0000 X-Sender: etkopa@obta.uw.edu.pl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 14:07:31 -0000 Received: (qmail 97296 invoked from network); 9 Jan 2001 14:07:15 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Jan 2001 14:07:15 -0000 Received: from unknown (HELO maryjane.etkopa.dom) (213.76.104.37) by mta2 with SMTP; 9 Jan 2001 14:07:08 -0000 Received: from lsd.etkopa.dom (IDENT:etkopa@lsd.etkopa.dom [10.0.0.2]) by maryjane.etkopa.dom (8.10.2/8.10.2) with SMTP id f09Fkj200202 for ; Tue, 9 Jan 2001 16:47:01 +0100 X-Mailer: KMail [version 1.1.99] To: f-cpu@egroups.com Message-Id: <01010913565804.00814@lsd.etkopa.dom> From: Konrad Gajewski MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 13:56:58 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] unsubscribe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f9790a6db677769069123c84cf72c187 Status: R X-Status: N unsubscribe
eGroups Sponsor
Click here for Business information
Click here for Business information
From richardrubenstein@yahoo.com Tue Jan 9 22:37:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03304 for ; Wed, 10 Jan 2001 04:38:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:38:30 +0100 (MET) Received: (qmail 21108 invoked by uid 0); 9 Jan 2001 18:51:48 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx13) with SMTP; 9 Jan 2001 18:51:48 -0000 X-eGroups-Return: sentto-1101623-1898-979066294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ck.egroups.com with NNFMP; 09 Jan 2001 18:51:42 -0000 X-Sender: tradebhijit_bagal@address.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 18:51:33 -0000 Received: (qmail 42948 invoked from network); 9 Jan 2001 18:46:30 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 9 Jan 2001 18:46:30 -0000 Received: from unknown (HELO dns.longred.com.tw) (202.154.202.100) by mta2 with SMTP; 9 Jan 2001 18:46:28 -0000 Received: from 216.97.206.110 (216-97-206-110.ppp.mpinet.net [216.97.206.110]) by dns.longred.com.tw (8.9.3/8.8.7) with SMTP id CAA16635; Wed, 10 Jan 2001 02:49:30 +0800 Message-ID: <000034403f6d$00004a38$0000201f@216.97.206.110> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: tradebhijit_bagal@address.com From: richardrubenstein@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 09 Jan 2001 13:37:58 -0800 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FRANCS?PESO'S? . Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d96ac2e2a06f514caa3f2790ba5746e4 Status: R X-Status: N Interested in a new Investment Opportunity?
Are you tired of all the rest?
Well look no further!!!

This is the start of an EXPLO$IVE OPPORTUNITY!
IT'S SIMPLE!
IT'S FUN!
And MOST OF ALL...
IT CAN MAKE YOU RICH!!!!

For a free Audio Tape with all the
HOW'S and WHY'S....

Reply with your Name, Address and Phone Number!

*You must be at least 21 years of age to participate.

To be removed from future mailings, reply with
"REMOVE" in the subject line.













Interested in a new Investment Opportunity?
Are you tired of all the rest?
eGroups Sponsor
Click Here!
From "Iancu Silvius" Tue Jan 9 20:34:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03319 for ; Wed, 10 Jan 2001 04:38:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:38:34 +0100 (MET) Received: (qmail 26892 invoked by uid 0); 9 Jan 2001 19:39:21 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx18) with SMTP; 9 Jan 2001 19:39:21 -0000 X-eGroups-Return: sentto-1101623-1899-979069143-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 09 Jan 2001 19:39:21 -0000 X-Sender: silvius@mail.dnttm.ro X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 19:38:54 -0000 Received: (qmail 13316 invoked from network); 9 Jan 2001 19:36:36 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 Jan 2001 19:36:36 -0000 Received: from unknown (HELO terminus.dnttm.ro) (193.226.98.11) by mta3 with SMTP; 9 Jan 2001 20:37:32 -0000 Received: from silvius (ppp101.dnttm.ro [193.231.207.106]) by terminus.dnttm.ro (8.9.3/8.9.3) with SMTP id VAA03424 for ; Tue, 9 Jan 2001 21:35:42 +0200 Message-ID: <004101c07a73$284aeac0$19a4fea9@silvius> To: References: <979043014.86682@egroups.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: "Iancu Silvius" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 21:34:04 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] REMOVE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c63478ae3dc4e80222f302aec16712c1 Status: R X-Status: N
----- Original Message -----
From: <f-cpu@egroups.com>
To: <f-cpu@egroups.com>
Sent: Tuesday, January 09, 2001 2:23 PM
Subject: [f-cpu] Digest Number 242


> There are 8 messages in this issue.
>
> Topics in this digest:
>
>       1. "REMOVE"
>            From= : "Iancu Silvius" <silvius@mail.dnttm.ro>
>       2. Re: This project really sucks.<= BR> >            From= : DuaneMHunt170976@aol.com
>       3. Hay
>            From= : DuaneMHunt170976@aol.com
>       4. A DishNetwork sys. Free
>            From= : james729@japan.com
>       5. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       6. Re: This project really sucks.<= BR> >            From= : Michael Riepe <michael@stud.uni-hannover.de>
>       7. Re: This project really sucks.<= BR> >            From= : Jeff Davies <jeff@llandre.freeserve.co.uk>
>       8. networks, bus, topologies, link= s.............
>            From= : whygee@club-internet.fr
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 1
>    Date: Mon, 8 Jan 2001 15:02:37 +0200
>    From: "Iancu Silvius" <silvius@mail.dnt= tm.ro>
> Subject: "REMOVE"
>
>
> ----- Original Message -----
> From: <f-cpu@egroups.com>
> To: <f-cpu@egroups.com>
> Sent: Monday, January 08, 2001 1:47 PM
> Subject: [f-cpu] Digest Number 241
>
>
> > There are 22 messages in this issue.
> >
> > Topics in this digest:
> >
> >       1. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: Nicolas Boulay <nicolas.boulay@ifrance.com>
> >       2. REMOVE
> >           = From: "Didi" <flei@wanadoo.fr>
> >       3. NO MORE SPAM MAIL !!! = ; DO YOU UNDERSTAND ME ?  STUPID GUY
> >           = From: "Didi" <flei@wanadoo.fr>
> >       4. remove
> >           = From: rvsicam@aol.com
> >       5. Re: REMOVE
> >           = From: Yann Guidon <whygee@f-cpu.org>
> >       6. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: Vanderhoeven Steve <vanderho@essi.fr>
> >       7. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: "Marco Al" <marco@simplex.nl>
> >       8. RE: Re: Re: 17. Chaos Comm= unication Congress - Wie war ehr?
> >           = From: jeff@llandre.freeserve.co.uk
> >       9. Re: Re: 17. Chaos Communic= ation Congress - Wie war ehr?
> >           = From: Michael Riepe <michael@stud.uni-hannover.de>
> >      10. Re: NO MORE SPAM MAIL !!! = DO YOU UNDERSTAND ME ?  STUPID GUY
> >           = From: Michael Riepe <michael@stud.uni-hannover.de>
> >      11. Re: NO MORE SPAM MAIL !!! = DO YOU UNDERSTAND ME ?  STUPID GUY
> >           = From: Keyshaun <thekernel@subdimension.com>
> >      12. Re: Re: Re: 17. Chaos Communica= tion Congress - Wie war ehr?
> >           = From: "Marco Al" <marco@simplex.nl>
> >      13. This project really sucks.
> >           = From: Alan Grimes <alangrimes@starpower.net>
> >      14. Re: This project really sucks.<= BR> > >           = From: Michael Riepe <michael@stud.uni-hannover.de>
> >      15. Re: This project really sucks.<= BR> > >           = From: Alan Grimes <alangrimes@starpower.net>
> >      16. REMOVE
> >           = From: "Iancu Silvius" <silvius@mail.dnttm.ro>
> >      17. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
> >           = From: Yann Guidon <whygee@f-cpu.org>
> >      18. Re: This project really sucks. = (yes we know, but that's what
> makes it so interesting :-D)
> >           = From: Yann Guidon <whygee@f-cpu.org>
> >      19. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
> >           = From: Yann Guidon <whygee@f-cpu.org>
> >      20. REMOVE
> >           = From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> >      21. REMOVE
> >           = From: "maurizio zoboli" <maurizio.zoboli@unimo.it>
> >      22. Re: Re: 17. Chaos Communication= Congress - Wie war ehr?
> >           = From: Vanderhoeven Steve <vanderho@essi.fr>
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 1
> >    Date: Sun, 07 Jan 2001 13:46:24 +0100
> >    From: Nicolas Boulay <nicolas.boulay@ifrance= .com>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> >
> > Yann Guidon a =E9crit :
> > >
> > > hi !
> > >
> > > Marco Al wrote:
> > > > The only way to proove/disproove that
> > > > IMO is to model both alternatives, but Im both too lazy= and I dont
> have the
> > > > necessary knowledge (AFAICS I would need to know feasib= ly physical
> bandwith per
> > > > pin in point to point and bus setups, and have a good t= raffic
> breakdown for
> > > > multiprocessor setups) .With a lot of broadcast traffic= I just dont
> think the
> > > > effective bandwith per pin of a point to point bus comp= ares
> favourably, let
> > > > alone the extra costs and latency of the routing chips = for small SMP
> setups.
> > >
> > > well, there's the architecture side here...
> > >
> > > if you target "small SMP" only, maybe you can do i= t with a shared bus,
> > > but don't expect wonders above 4 CPU. If you're doing CPU-on= ly tasks,
> it's
> > > ok, but when you start to move things around, it's the real = mess.
> > > Intel sticks to this because the architecture is more or les= s stuck.
> > > they want cheap systems and make big profits, but still comp= ete (with
> > > some pain) in the SPEC contests.
> > >
> >
> > You always forget one big thing. Here we speak about private memo= ry and
> > communication network to speed up memory interface. So in the int= el
> > architecture, 4 is a maximum because all the 4 cpu read the memor= y
> > thought the same shared bus. In our system, only message go thoug= ht the
> > network. In the best case, only I/O instruction go thought the ne= twork
> > and very few message from the processes.
> >
> > > I am trying to find the "least common denominator"= for a F-CPU system
> > > that can range from 1 CPU to any arbitrary number of CPUs (j= ust like
> > > the register width : not bound to anything). let's take a fe= w cases,
> > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system"= should also scale
> > > to much more CPUs : the widest systems today (see the monter= s at the
> LANL)
> > > can scale to more than 10K CPU, so let's round up to 65536.<= BR> > > >
> > > now let's compare the alternatives...
> > >
> > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it= 's
> disastrous
> > > with more CPU.
> > >
> > > buses are known, used and they work, but some people here wa= nt a
> "multimaster"
> > > bus. This means that the bandwidth is drawn by several point= s and the
> bus
> > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per= CPU, equal
to
> > > the available bandwidth provided by the bus and divided by N= CPU).
> > >
> > > that's what i try to avoid.
> > >
> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as
> well,
> > > and it's my "hammer" argument when i try to promot= e point to point
> links.
> > > We spare the (distributed) control logic (all the nasty dead= lock
stuffs
> etc)
> >
> > There are always possible traffic Jam. How do you manage when 2 n= odes
> > try to speak to the same nod ? You have to manage something to av= oid
> > losing informations.
> >
> > > and it's very simple to implement. the PCB is simpler, too.<= BR> > > >
> > > If you connect more than 2 CPU on the same bus, they compete= for the
> ressource
> > > and the bottleneck gets even narrow.
> > >
> >
> > Yes, but less drastically as intel SMP.
> >
> > > On the pin count vs bandwidth argument, it's similar. Of cou= rse, we
can
> find
> > > a lot of counter-examples and special cases, but the example= of the
> broadcast
> > > is not the best one. Most of the requests are from one node = to a
single
> other
> >
> > In fact, not. It depend how much process communicate between them= . And
> > sometimes the only [simple] way to find a "moving" ress= ources is to send
> > a braodcast.
> >
> > > and here, the efficiency of a bus drops dramatically ! for a= N-CPU
> system,
> > > the efficiency is of 2 used bus interfaces for N bus interfa= ces (you
can
> > > replace "bus interface" with "pin"), 2/N= is similar to the 1/N scheme
> > > (if we speak about the "big O" or complexity). Thi= s means that :
> > > the more CPU, the least efficient ! you'll see that the best= way to
> avoid
> > > this is by having as few CPU by link as possible, and the mi= nimum is
2.
> > > that's "point to point"...
> > >
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU
wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real
> efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2
> dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same
> but the
> > > address is split into 3 fields that are interpreted as an in= dependent
> ring address.
> > >
> >
> > In the flight back to France, we have spoken about ring of ring.(= and
> > called the architecture the lord of the ring ;p). A ring is compo= sed
> > around 8 to 16 card (cpu+ram or IO). A card could be used to comm= unicate
> > with other ring. Maybe it's possible to grow in hierachy without = to much
> > trouble.
> >
> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6
> neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant"
> (through dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU
> number).
> > >
> > So !
> >
> > > So if you want the simplest system, you have 1 CPU with no r= ing,
> > > and when you scale up, add a few links when needed and use l= ike "lego
> bricks"
> > > in a cubic connexion.
> > >
> > Cubic ~=3D  ring ????
> > > I think that the G-chip was an easy way to make the topology=
> reconfigurable
> > > by the user/implementor. If we provide the brick, the user w= ill make a
> lot
> > > of stuffs, but if we restrict the choices, the scalability a= nd the
> flexibility
> > > will suffer.
> > >
> > > > Marco
> > >
> > > Nicolas Boulay wrote:
> > > >
> > > > Hi,
> > > >
> > > > Yann Guidon a =E9crit :
> > > > >
> > > > > hi,
> > > > >
> > > > > Nicolas Boulay wrote:
> > > > > > hi,
> > > > > >
> > > > > > Oups, i omit to say for reduice the cost that= i would like to
try
> to
> > > > > > have only one chip and avoid many differents = chips. So the 8
links
> will
> > > > > > be "inside" the fcpu chip. This is = the main system bus.
> > > > >
> > > > > hum, hum... just a reminder : the SiO2 process is = not much the
same
> > > > > for a CPU and a tranceiver. you CAN't put it on th= e same die...
> > > >
> > > > I don't think that you know about what you speak ! New = silicon
process
> > > > are silicium on insulator, soon used by IBM for there u= dge processor
> for
> > > > mainfrain (a little beast with 35 ppc on the same die).=
> > > duh. and how will you ask IBM to make your chip ?
> > > it's not something that everybody can do. it's not free, it'= s
expensive
> >
> > And you think that actual 0.18 =B5m are free ? In 2 years, SOI wi= ll be
> > used in every silicon process, because it reduice the power consu= mption
> > and doesn't cost so much (it's just a little traitement on wafer)= .
> >
> > > and it's not connectable to anything...
> > >
> > ??? I think you miss something... The only electrical rules to re= spect
> > is the higher voltage in input, most of the time lower than 3.3 V= , to
> > avoid destroying transistor, that's all.
> >
> > > > And now, for the next powerG3. Next, the SiGe are new p= rocess used
to
> have
> > > > hyperfrequencies, or mixed analogue and digital part. B= ut then, it
> could
> > > > be used for very quick digital circuit.
> > > It is. but how many people would use such a chip ? what can = they
connect
> it to ?
> > > how will you "solve" the RF issues ? Do you know h= ow difficult it is
to
> route
> > > a 50 MHz signal ? So who will buy you the SW needed to desig= n a RF PCB
?
> > >
> >
> > I think that Cadence has offer something. (any news ?) You want > > performance and you think that 50 Mhz signal are to much. How do = you
> > want to deal with 133 Mhz DDR-SDRAM ?
> >
> > > > And, for information, gigabit ethernet need 500 Mhz. So= , "usual
> process"
> > > > are must enought to make a tranceiver.
> > > Maybe you should stop to use the term "ethernet". = If it's a simple
> >
> > But in electrical rules, gigaethernet is only a serial point to p= oint
> > link, not much more (just add the mac adress and a crc).
> >
> > > "serial link", you're just making a firewire clone= ...
> > >
> >
> > A=EFe ! Firewire isn't a point to point serial link !!!! It's a c= omplete
> > network system which include the 3rd layer of the OSI system. It = include
> > the routing protocole and all that stuff (the same thing than IP = )!
> >
> > > > > > The 8 ethernet link could be say has 2 one-wa= y gigabyte links.
So,
> if
> > > > > > you use a ring, you need 2 of this links (one= by ring). So you
> will only
> > > > > > need a 1 layer PCB !
> > > > > beep. wrong. gigabit ethernet, or any ethernet, re= quires a very
> special
> > > > > medium to propagate. the shield, the impedence ada= ptation, the
> diameter,
> > > > > the propagation, etc. are more or less taught in t= he IUT or
> ingenieur school.
> > > > A=EFe ! You just have to respect electrical rules of th= e gigabit
> ethernet
> > > > (L and C).
> > > that's a pretty quick simplification. even though at your le= vel it
fits,
> > > when you make the PCB it takes another dimension ...
> > >
> > > > > they're a lot of formula etc, so you can't simply = draw a line and
> say "ok".
> > > > > it can't be so. otherwise, network cables would be= much cheaper.
> > > > > have you heard about "Cat. 5" cables ? d= id you wonder why it was
> more
> > > > You have never learn that this kind of cable could be a= round 50
meter
> > > > long ! Here 1 or 2 meters is much enought !
> > > and you think that it's not the same problem ????
> > > have you heard about Xtalk and such stuff ? you CAN't make i= t with a
> 1-layer PCB.
> >
> > That's why ethernet cable are made by pair (like lvds, d is for > > differential). And with some ground it could pass.
> >
> > > you need at least 3 layers to make a decent transmission lin= e
> >
> > so 4 layers, like usual mother board.
> >
> > > (shield/insulator/signal/insulator/shield). And depending on= your
> signal's
> > > characteristics, you have to change the dimensions of the tr= acks,
> > > so they are adapted to the thickness of the PCB and the perm= eability
of
> > > the insulator (if it's epoxy or teflon or something else). > > >
> > > Whether the wire is 50m or 1m, the problem is the same... > > >
> >
> > Not really. The Characteristique are made to say that your cable = could
> > be 50 meter long, so the signal could be mixed with a certain lev= el of
> > noise. If you need shortest cable, you could adjust the quality o= f the
> > cable.
> >
> > > > > > > i compare what can be compared.
> > > > > > > the current idea is simply not realistic= .
> > > > > > Yes, the idea that you have understood, not m= ine !
> > > > > talk about a monodirectional synchronous parallel = (byte ?)
> > > > > bus with some control signals, a clock (dual edge = ?) and it's ok
for
> > > > > me, whatever your idea is. Anybody can implement t= hat with a
> > > > Fast clock one large network, you have to deal with clo= ck skew.
> > > it's an old known problem and there are some old known solut= ions.
> > > ever heard about a "clock tree" ?... if you have a= good architecture,
> > > you don't have skew troubles.
> > >
> >
> > Don't forget that i'm microelectronic engineer and clock tree are= a
> > basis... Which is not so simple at all.
> >
> > > > Most of the time, each founder (ST microelectronics, TS= MC,
> infineon,...)
> > > > have a macro cell to do gigaethernet and do all the har= d things
> (serial,
> > > > deserials).
> > > and you'll by the components ? come on...
> >
> > The chip maker will by it.
> >
> > > and please, don't talk about "Ethernet", it seems = like it's
> > > only a serial point to point link (if i remember one of your=
messages).
> > >
> >
> > But, it is !
> >
> > > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? T= TL signify 5V
> and
> > > > some nF of charge. I don't want to repeat it each time.=
> > > hey, i'm not dumb, i know that TTL is slow. thanks.
> > >
> > > but just a question : how will you debug your stuff ? will y= ou use
> > > a 10GS/s logic analyser ? with a simple enough protocol, i c= an
> > > debug the interface with "off the shelf parts" tha= t i can solder at
> will,
> > > the old school way, just like any "hacker".
> > >
> >
> > Like everybody, you will use a standart JTAG port.
> >
> > > Then, when it's developped, you only have to change the elec= trical
> > > levels (that is : the pin's driving gates) and you can do LV= TTL or
> whatever
> > > high-speed connexion. it's just a matter of changing the ele= ctrical
> spec.
> > > Yes i want speed, but a "hacker" needs a way to se= e what happens
without
> > > the need of extremely expensive devices. by clocking the chi= p slower
> > > and adapting the electrical level (with the adapted buffers = or
> transmitters),
> > > you can hook anything to the F-BUS.
> > >
> >
> > If you use low voltage it's because you can't manage with higher = one. So
> > it could be impossible to change it !
> >
> > > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very = slow compare to
> > > > usual system.
> > > this kind of speed is used for I/O with maybe a controller o= r
something
> > > like that. When i speak about "TTL parts", it's so= mething like a 8255
> > > or any very slow byte-based I/O chip. just like during the o= ld days
> > > of the 8-bit systems...
> > >
> >
> > And you want performance by slow down the network only to put goo= d old
> > I/o chip....
> >
> > > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) = or around 300
Mhz
> > > > with DDR or more with QDR. With LVDS, you can reach aro= und 600 Mhz
by
> > > > pin. BUT you can't really add a connector between 2 pin= s at that
> speed.
> > > then it must be soldered. but then, this speed is not requir= ed for
> > > handcrafting your own I/O board on a pre-drilled PCB. do you= know a
> mouse
> > > or a keyboard or even a LCD screen that requires 600M x N pi= ns of data
> > > per second ?
> > >
> > ????? I speak only for the network system, to be compared to the = bus
> > system in intel board the 64 bit now 200 Mhz multipomped bus. Not= to the
> > PCI or EISA.
> >
> > > Scalability means scale-down and scale-up. 500Mbps is fine, = but when
you
> > > don't need that much, it's an overkill. And you propose to m= ake an
> adapter
> > > that will bother of the I/O, but how many custom chips will = you
require
> > > to interface your connexion to any other stuffs ? Having a s= imple and
> > > one-fits-all protocol that does low and high-speed helps red= uce the
> > > number of different chips and interfaces...
> > >
> >
> > First only one to connect other system (PCI, IO,...) and no G-shi= p
> > (include inside the fcpu)
> >
> > > > My choice is to have a quick link (performance are our = goal, isn't
it
> ?).
> > > not only. In the design goals of the F-CPU, there are 3 othe= r stuffs.
> > >
> > Which one ?
> >
> > > > Then you just had to provide a bridge between the quick= link and a
> > > > SRAM like bus. I think that could be easy : Just a link= like for the
> > > > fcpu and a little glue for the interface.
> > > i'll give you the honnor of doing the first one...
> > >
> > > > > now you're asynchronous, you have to deal with PLL= and clock
> > > > > recovery, hyperfrequencies, signal integrity, skew= , etc...
> > > > > that a lot of troubles for almost nothing.
> > > > Not at all ! because you deal with macrocell and all th= e suft are
soon
> made.
> > > ain't it magical ??...
> > > are you so confident and faithfull in the technologies ?
> > >
> > Read there spec.
> >
> > > > > you want speed ? put the wires in parallel, don't = serialize the
> bits...
> > > > Yes, but the limit are the number of pin and the prices= ! And then
you
> > > > alwas have the speed of the clock with LVDS, you always= have the
> > > > electrical and speed problem.
> > >
> > > ok, let's compare serial and parallel.
> > >
> > > you want 1Gbps links. halve it now, because the actual effic= iency
> > > of a serial bus is not the raw peak number. With 10Base, one= can't
> transfer
> > > more than 500K bytes per second. or 520. whatever.
> > > So let's imagine that you can SUSTAIN 50 M bytes per second.=
> > > caugh. caugh. ok, imagine you can reach 70M bytes in the two=
directions.
> > > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 = M bytes/s
> > > (or 8 Gbps).
> > >
> >
> > True but with how many wire ?
> >
> > > Ok, i know, you want to reach 8Bgps by using 8 links.
> > > but how are they connected ? if you want to make a ring, you= 'll
> > > dissipate your bandwidth, and if you want to make neighbour = to
neighbour
> > > connexions, you'll require 64 pins (or better 100, counting<= BR> grounds/VCC)
> > > per neighbour. retour case d=E9part...
> > >
> >
> > Compare the number of wire and the cost of a BGA compare to a PGA= .
> >
> > > > > > In usual core, you have simple bus and it's e= asy to
> > > > > > put rom or eeprom to boot. But here, you need= something more
> special to boot.
> > > > > and who will build that ? do you have the spare pa= rts somewhere ?
> > > > "spare part", i don't understand.
> > > i mean : go buy some such chips at St Quentin Radio or Radio= Shacks...
> > > a chip that is available for sale in public catalogs.
> > >
> >
> > You are realy funny, even by Radiospares you can't buy 3.3 V logi= c, and
> > you want an killing design to compet against alpha !
> >
> > > > One day, you say you want performance,
> > > > the other days somthing so slow to be compatible with T= TL. I don't
> > > > understand you...
> > >
> > > i want something that can do both, but of course not at the = same time.
> > > you can't access a mouse or handcrafted I/O board (anything = that you
> > > see in Elektor or Electronique Pratique) with the same means= as
another
> CPU.
> > > But the protocol and the layout must remain the same, as to = ease the
PCB
> design
> > > and the easy replacement of the chips.
> > >
> >
> > *<;p
> > > > > > Have you a link for a preditive routing algor= ithme ? I think
that
> my
> > > > > > collegue which make a thesis about real time = network will be
very
> > > > > > interrested to know that exist.
> > > > >
> > > > > the routing stuff is taught during the DEUG at Par= is 8 university.
> > > > > ask Amal Stri from the transversal department.
> > > > >
> > > > > When at Boston, in a (expensive) library, i found = (but didn't buy)
> > > > > a VERY cool about the T3E and similar architecture= s. The routing
> > > > > algos are rather simple and very efficient.
> > > >
> > > > I seriously doubt about the complexity and the scalabil= ity...
> > >
> > > remember, it's a torus. only, it's 3D :-)
> > > for the other details, it's up to you to go to the library,<= BR> > > > read as many book as you can and ask the teachers and the > > > educated people from comp.arch and comp.sys.super...
> > > i won't do it for you, you wouldn't believe what i say :-P > > >
> > > > > > If we made a simple core (like ARM), we don't= need g-ship and
all
> that crap.
> > > > > not true. ARM chips require I/O chips. Unless you = buy the
> synthesised core,
> > > > > and implement it in the middle of a sea-of-gates A= SIC with your
> prefered I/O.
> > > > One more times, you don't unsderstand ! i propose like = leon, just to
> > > > develope the fc0 (the core) and let other gays to use i= t.
> > > so let's drop this silly network/bus whatever debate for a w= hile...
> > >
> > > > > > If we made a processor ("a system")= we should consider to have
> > > > > > fault tolerance capabilities. And hot swap is= the basis !
> > > > > not necessarily. fault detection and bypass are a = SW matter,
> > > > > with the help of some HW (ECC/SEC). but the rest i= s purely an
> electrical
> > > > > problem.
> > > > >
> > > > Not really, i don't speak about fault detection but fai= lure tolerant
> (a
> > > > single dead card don't stop the all system, you just ha= ve to change
> it).
> > >
> > > it's the SAME thing. You can't be "fault tolerant"= if you can't detect
> > > the fault and take the necessary SW measures. It's obvious..= .
> > > i'm just trying to avoid "buzzwords" that taint th= e debate with black
> magic ;-)
> > >
> > > > > some designs that you should investigate (using se= veral different
> books,
> > > > > saying different stuffs) : T3D/E (it's a 3D torus = with ALPHAs at
the
> nodes),
> > > > > CM1 (12-cube with extremely simple routing), CM5 (= fault tolerance,
> "big tree"
> > > > > network, message passing communication etc.), SGI/= SUN/HP scalable
> computing nodes
> > > > > (i found the Convex (circa 1995) very interesting,= but Convex is
now
> owned by HP).
> > > >
> > > > Just for information : how much for a single chip ? And= how much
heat
> > > > for a chip ? You try to give some piece of your knowled= ge but you
> don't
> > > > understand the "simple coma" from SUN for the= ir last system (from an
> URL
> > > > given on the list), so ?
> > >
> > > i've tried, but it's not that clear for me, what's so specia= l ?
> > > when there's a page fault, i trap. Just make the correct fau= lt
handler,
> > > and you implement any memory protection and sharing you want= .
> > > It leaves the door open to ANY memory system implementation.=
> > > what else do you want ? i'm still waiting for a clear and HW=
> proposition.
> > >
> >
> > HW or SW that not the point, you can used both for the same thing= , the
> > only 2 issue are cost and performance. Bevore, we had to find the=
> > algorythmes and then implement it.
> >
> > > > > i know, it's a matter of culture...
> > > > I just see it's like jam, ...
> > > J'en ai une meilleure, mais je ne l'ai pas invent=E9e non pl= us,
> > > elle est de Jacques Brel : "La culture, c'est la m=E9mo= ire des
> > > cons qui n'ont rien invent=E9". Il avait vraiment des i= d=E9es
> > > noires avant de mourir... La culture, il faut se la faire > > > tous les jours et ne pas trop camper sur ses positions... > > > avec le f-cpu, on a ce qu'il faut comme action :-)
> > >
> > > bonne nuit,
> > >
> >
> > "La culture est ce qui reste quand on ne sait rien faire&quo= t; Francoise
> > SAGAN, un peu provoc, l=E0... ;p
> >
> > > > > > > > nicO
> > > > > > > WHYGEE
> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 2
> >    Date: Sun, 7 Jan 2001 16:17:04 -0000
> >    From: "Didi" <flei@wanadoo.fr><= BR> > > Subject: REMOVE
> >
> >
> > ----- Original Message -----
> > From: "maurizio zoboli" <maurizio.zoboli@unimo.it>= ;
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 10:18 AM
> > Subject: [f-cpu] REMOVE
> >
> >
> > > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com = wrote:
> > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >telephone number and the
> > > >product or service you wish
> > > >to market. We will be in
> > > >touch with you shortly!
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Removal Instructions
> > > >****************************
> > > >To be removed from this list
> > > >please reply with "REMOVE"
> > > >in the subject.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Prof. Maurizio Zoboli
> > > Dipartimento di Scienze dell'Ingegneria
> > > Universita' di Modena e Reggio Emilia
> > > via Vignolese 905
> > > I-41100 Modena, Italy
> > > Tel.: +39 059 2056163
> > > Fax: +39 059 2056129
> > > e-mail: maurizio.zoboli@unimo.it
> > >
> > >
> > >
> > >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 3
> >    Date: Sun, 7 Jan 2001 16:28:07 -0000
> >    From: "Didi" <flei@wanadoo.fr><= BR> > > Subject: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ? = STUPID GUY
> >
> >
> > ----- Original Message -----
> > From: "Didi" <flei@wanadoo.fr>
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 4:17 PM
> > Subject: [f-cpu] REMOVE
> >
> >
> > >
> > > ----- Original Message -----
> > > From: "maurizio zoboli" <maurizio.zoboli@unimo.= it>
> > > To: <f-cpu@egroups.com>
> > > Sent: Sunday, January 07, 2001 10:18 AM
> > > Subject: [f-cpu] REMOVE
> > >
> > >
> > > > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo= .com wrote:
> > > >
> > > > >Expand your business with
> > > > >    Email Marketing!
> > > > >
> > > > >Market your product or service
> > > > >     to MILLIONS!
> > > > >
> > > > >Don't waste another minute...
> > > > >
> > > > >Click Reply with your name,
> > > > >telephone number and the
> > > > >product or service you wish
> > > > >to market. We will be in
> > > > >touch with you shortly!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Removal Instructions
> > > > >****************************
> > > > >To be removed from this list
> > > > >please reply with "REMOVE"
> > > > >in the subject.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Expand your business with
> > > > >    Email Marketing!
> > > > >
> > > > >Market your product or service
> > > > >     to MILLIONS!
> > > > >
> > > > >Don't waste another minute...
> > > > >
> > > > >Click Reply with your name,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Prof. Maurizio Zoboli
> > > > Dipartimento di Scienze dell'Ingegneria
> > > > Universita' di Modena e Reggio Emilia
> > > > via Vignolese 905
> > > > I-41100 Modena, Italy
> > > > Tel.: +39 059 2056163
> > > > Fax: +39 059 2056129
> > > > e-mail: maurizio.zoboli@unimo.it
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 4
> >    Date: Sun, 7 Jan 2001 11:39:35 EST
> >    From: rvsicam@aol.com
> > Subject: remove
> >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 5
> >    Date: Sun, 07 Jan 2001 18:21:46 +0100
> >    From: Yann Guidon <whygee@f-cpu.org>
> > Subject: Re: REMOVE
> >
> > hello,
> >
> > look at the header of the message, it contains :
> > "List-Unsubscribe:  <mailto:f-cpu-unsubscribe@egroup= s.com>"
> >
> > if you want to unsubscribe, sending messages to the list
> > will not work. you have to send a message to the addresse copied<= BR> > > above.
> >
> > although this should work, the egroups.com site mentions
> > another address, please read the notice on the web.
> >
> > regards,
> >
> > maurizio zoboli wrote:
> > <snip>
> > >
> > > Prof. Maurizio Zoboli
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 6
> >    Date: Mon, 07 Jan 2001 20:50:06 +0100
> >    From: Vanderhoeven Steve <vanderho@essi.fr&g= t;
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> >
> > > If you connect more than 2 CPU on the same bus, they compete= for the
> ressource
> > > and the bottleneck gets even narrow.
> > >
> >
> > atm?
> >
> > steve
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 7
> >    Date: Sun, 7 Jan 2001 22:38:27 +0100
> >    From: "Marco Al" <marco@simplex.nl= >
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> >
> >
> > > Yann Guidon a =E9crit :
> >
> > > > if you target "small SMP" only, maybe you can= do it with a shared
bus,
> > > > but don't expect wonders above 4 CPU. If you're doing C= PU-only
tasks,
> it's
> > > > ok, but when you start to move things around, it's the = real mess.
> > > > Intel sticks to this because the architecture is more o= r less stuck.
> > > > they want cheap systems and make big profits, but still= compete
(with
> > > > some pain) in the SPEC contests.
> > > >
> > >
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface. So in th= e intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> >
> > You seem to presuppose that it wont have a single memory space wi= th
> hardware
> > maintained coherency... I dont mind, I like transputers. But a lo= t of
> users of
> > parallel systems disagree.
> >
> > > > Clearly, this B=3DL/N is a thing that i try to avoid fo= r other things
as
> well,
> > > > and it's my "hammer" argument when i try to p= romote point to point
> links.
> > > > We spare the (distributed) control logic (all the nasty= deadlock
> stuffs etc)
> >
> >
> > Thats one way of looking at it, the other way is that its a given= that L
> has to
> > be B*N' and that for N>N' you need extra hierarchies.
> >
> > And you wont get away from hierarchies, a single chip can only co= nnect
to
> so
> > many processors and have so much backplane capacity. The control = will
> always be
> > distributed at a certain point.
> >
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
> wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
> > efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
> > dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same
> but
> > the
> > > > address is split into 3 fields that are interpreted as = an
independent
> ring
> > address.
> >
> > Exactly.
> >
> > My opinion also kind of depends on where the motherboard chipset<= BR> > functionality
> > would be present and how many pins that would need.
> >
> > I think making a bridge which can have a point-to-point/shared/ri= ng
> connection
> > to the processors which itself plugs into a socket-7 board (or pe= rhaps
> even a
> > PCI slot) is a good solution :) (bios should be local though, obv= iously)
> Getting
> > a processor made, no matter how many frills you remove is a huge = task...
I
> think
> > designing a motherboard chipset on top of that is an unnecessary = burden.
> You can
> > always later replace the bridge with a true motherboard chipset.<= BR> > >
> > Marco
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 8
> >    Date: Sun, 7 Jan 2001 22:46 +0000
> >    From: jeff@llandre.freeserve.co.uk
> > Subject: RE: Re: Re: 17. Chaos Communication Congress - Wie war e= hr?
> >
> > Regarding this rather strange multi cpu argument:
> >
> > 10 base t is not cutting edge, 1000 base t is.
> > You can buy it off the shelf. full duplex via a switch,
> > you can get 200 megabytes per second without compression
> > between hosts. Obviously, multiple lan adaptors enable
> > multiple segments to be used in parallel, and therefore
> > it is quite easy to exceed the bandwidth of an sdram in this
> > way (but rather pointless).
> >
> > smt as used by intel etc seems to share the whole of
> > system ram between all cpus which is dumb.
> > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> > but they also share the third sdram for comms.
> >
> > Not exactly a new idea, but much better than smt.
> >
> > All the multi cpu stuff is interesting but pointless. It
> > doesnt change the core. Why not get back to that. We
> > shouldnt waste whygee or michaels time, when they are
> > doing so well with the vhdl.
> > like someone said, shit happens, forget 17c3,
> > success is the sweetest form of revenge.
> > Once core is around, you multi cpu dudes can work on your
> > own multiprocessors.
> >
> > Jeff Davies
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 9
> >    Date: Sun, 7 Jan 2001 15:46:44 +0100
> >    From: Michael Riepe <michael@stud.uni-hannov= er.de>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote: > > [...]
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface. So in th= e intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> >
> > It depends.  If you use ccNUMA or COMA, there will be a lot = of
additional
> > traffic to keep the caches up-to-date.  And if you're runnin= g certain
> > parallelized tasks with high communication overhead, even Gbps et= hernet
> > becomes too slow.
> >
> > > > I am trying to find the "least common denominator&= quot; for a F-CPU
system
> > > > that can range from 1 CPU to any arbitrary number of CP= Us (just like
> > > > the register width : not bound to anything). let's take= a few cases,
> > > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system&= quot; should also scale
> > > > to much more CPUs : the widest systems today (see the m= onters at the
> LANL)
> > > > can scale to more than 10K CPU, so let's round up to 65= 536.
> > > >
> > > > now let's compare the alternatives...
> > > >
> > > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU a= nd it's
> disastrous
> > > > with more CPU.
> > > >
> > > > buses are known, used and they work, but some people he= re want a
> "multimaster"
> > > > bus. This means that the bandwidth is drawn by several = points and
the
> bus
> > > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidt= h per CPU,
equal
> to
> > > > the available bandwidth provided by the bus and divided= by N CPU).
> > > >
> > > > that's what i try to avoid.
> >
> > It's actually worse than B=3DL/N.  Don't forget the overhead= for bus
> > arbitration and transfer direction turn-arounds.  I wouldn't= be
surprised
> > at all if bandwidth drops below B=3DL/N/2.  If you want to c= ome closer
> > to B=3DL/N, you need to do large block transfers (unreasonable ex= cept for
> > mass storage access), and then you'll get problems with latencies= (other
> > devices have to wait until the transfer is over and a new bus mas= ter
> > can be elected).  Another problem is that arbitration and tu= rn-around
> > times rise dramatically when the bus becomes longer (signal delay= ,
> > bad impedance matching when tri-state drivers are used, and so on= ).
> >
> > > > Clearly, this B=3DL/N is a thing that i try to avoid fo= r other things
as
> well,
> > > > and it's my "hammer" argument when i try to p= romote point to point
> links.
> > > > We spare the (distributed) control logic (all the nasty= deadlock
> stuffs etc)
> > >
> > > There are always possible traffic Jam. How do you manage whe= n 2 nodes
> > > try to speak to the same nod ? You have to manage something = to avoid
> > > losing informations.
> >
> > They will have to share the available bandwidth.  The G-Chip= will have
> > to queue the second message while it's sending the first one.&nbs= p; This
> > could be avoided by putting 4 F-Bus interfaces into the CPU itsel= f
> > (did anybody say "transputer"?), which makes the G-chip= obsolete
> > except for peripheral I/O and message routing/switching, or by us= ing a
> > faster (4x) link between F-CPU and G-chip.
> >
> > > > and it's very simple to implement. the PCB is simpler, = too.
> > > >
> > > > If you connect more than 2 CPU on the same bus, they co= mpete for the
> ressource
> > > > and the bottleneck gets even narrow.
> > > >
> > >
> > > Yes, but less drastically as intel SMP.
> > >
> > > > On the pin count vs bandwidth argument, it's similar. O= f course, we
> can find
> > > > a lot of counter-examples and special cases, but the ex= ample of the
> broadcast
> > > > is not the best one. Most of the requests are from one = node to a
> single other
> > >
> > > In fact, not. It depend how much process communicate between= them. And
> > > sometimes the only [simple] way to find a "moving"= ressources is to
send
> > > a braodcast.
> >
> > Yep.  Very common when (simple) COMA is used, IIRC.
> >
> > > > and here, the efficiency of a bus drops dramatically ! = for a N-CPU
> system,
> > > > the efficiency is of 2 used bus interfaces for N bus in= terfaces (you
> can
> > > > replace "bus interface" with "pin")= , 2/N is similar to the 1/N
scheme
> > > > (if we speak about the "big O" or complexity)= . This means that :
> > > > the more CPU, the least efficient ! you'll see that the= best way to
> avoid
> > > > this is by having as few CPU by link as possible, and t= he minimum is
> 2.
> > > > that's "point to point"...
> > > >
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
> wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
> efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
> dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same
> but the
> > > > address is split into 3 fields that are interpreted as = an
independent
> ring address.
> >
> > A ring is actually much better than a bus because it is a unidire= ctional
> > device (no change of transfer direction, no tri-state buffers nec= essary,
> > faster signalling) and arbitration is both simpler and faster (e.= g.
token
> > ring).  The members of the ring still share the available ba= ndwidth,
> > but you come closer to B=3DL/N.  Per-CPU bandwidth is still = limited,
though.
> >
> > > In the flight back to France, we have spoken about ring of r= ing.(and
> > > called the architecture the lord of the ring ;p). A ring is = composed
> > > around 8 to 16 card (cpu+ram or IO). A card could be used to=
communicate
> > > with other ring. Maybe it's possible to grow in hierachy wit= hout to
much
> > > trouble.
> > >
> > > > here, you don't have 1 ring but x*y*z rings. It means t= hat there is
> > > > no bandwidth problem at all, because each CPU communica= tes with its
6
> neighbours.
> > > > It works very well, it can be tweaked to become "f= ault tolerant"
> (through dynamic
> > > > node addresses) and scales perfectly (almost linearly w= ith the CPU
> number).
> > > >
> > > So !
> > [...]
> >
> > scales "perfectly" <EM>as long as the number of m= embers per ring is
> limited</EM>.
> > Sorry for shouting ;)
> >
> > For highest-speed n-to-n communication, use direct connections. > > Since this doesn't scale at all, you need to find a compromise wh= en
> > the number of CPUs increases -- switches or crossbars, trees or r= ings.
> > In any case, the solution depends on the work the system has to d= o.
> > With the drafted G-chip with 4 links, we could build
> >
> > - a 4-CPU directly-connected system
> > - a single ring (double ring requires 5 links, 1 for CPU)
> > - a binary or trinary tree (USB-style)
> > - a flat hexagonal `beehive' structure
> > - a cube
> > - ...
> >
> > This is a pretty long list of options, isn't it?  Let the im= plementor
(or
> > system integrator) choose from this list; we don't have to care.&= nbsp; We
just
> > need to make sure that the G-chip is versatile enough to support = at
least
> > two or three of the most common topologies, and probably mixed topologies
> > (like a tree or ring of directly-connected clusters, for example)= .
> > Preferably with auto-sensing capabilities =E0 la USB, i.e. the st= ructure
> > is determined at run (or boot) time.
> >
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 10
> >    Date: Mon, 8 Jan 2001 01:00:11 +0100
> >    From: Michael Riepe <michael@stud.uni-hannov= er.de>
> > Subject: Re: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ?&n= bsp; STUPID GUY
> >
> > On Sun, Jan 07, 2001 at 04:28:07PM -0000, Didi wrote:
> > >
> > > ----- Original Message -----
> > > From: "Didi" <flei@wanadoo.fr>
> > > To: <f-cpu@egroups.com>
> > > Sent: Sunday, January 07, 2001 4:17 PM
> > > Subject: [f-cpu] REMOVE
> > >
> > >
> > > >
> > > > ----- Original Message -----
> > > > From: "maurizio zoboli" <maurizio.zoboli@u= nimo.it>
> > > > To: <f-cpu@egroups.com>
> > > > Sent: Sunday, January 07, 2001 10:18 AM
> > > > Subject: [f-cpu] REMOVE
> >
> > Interesting how many people read this list but never say somethin= g.
> >
> > On the other hand, these dumbheads who are unable to read headers=
> > and quote the whole spam just to say "remove" to the wr= ong person(s)
> > (or even quote the replies, like in this case) are worse than spa= mmers
:(
> >
> > Guys, you have a brain.  PLEASE USE IT.
> >
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 11
> >    Date: Sun, 7 Jan 2001 17:21:06 -0700 (MST)
> >    From: Keyshaun <thekernel@subdimension.com&g= t;
> > Subject: Re: NO MORE SPAM MAIL !!!  DO YOU UNDERSTAND ME ?&n= bsp; STUPID GUY
> >
> > I must say that I am often one of the people who has little to sa= y.  I
> > just find the discussion of hardware design to be quite interesti= ng.  On
> > another note I almost responded to f-CPU with REMOVE in the subje= ct.
> > Other than that I think you guys are doing great work, though I m= ust say
> > that for a CPU project it's amazing how much is focused away from= the
> > processor.  Things like the G-Chip seem like they should bra= nch into
their
> > own seperate but related project.  Keep it simple, if I were= trying to
> > design something I would probably consider discarding the G-Chip = as
> > bloatware for anything other than SMP.  The F-CPU looks grea= t to me, I
> > would love to use it.  I would contribute skill to the proje= ct if I had
> > it.  Because I don't I must sit back and enjoy learning from= the
> > discussions I read.  None the less my big point I have ended= up going
into
> > is this...  It is the Freedom CPU project not the Freedom SM= P
application
> > system project.  Keep a good focus and more will get done.&n= bsp; When a CPU
is
> > ready the solutions to SMP and anything else you want to do will = play
> > themselves out.
> >
> > Shaun Kruger
> > thekernel@subdimension.com
> >
> > > Interesting how many people read this list but never say som= ething.
> > >
> > > On the other hand, these dumbheads who are unable to read he= aders
> > > and quote the whole spam just to say "remove" to t= he wrong person(s)
> > > (or even quote the replies, like in this case) are worse tha= n spammers
> :(
> > >
> > > Guys, you have a brain.  PLEASE USE IT.
> > >
> > > --
> > >  Michael "Tired" Riepe <Michael.Riepe@stud= .uni-hannover.de>
> > >  "All I wanna do is have a little fun before I die= "
> > >
> > >
> > >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 12
> >    Date: Mon, 8 Jan 2001 01:35:28 +0100
> >    From: "Marco Al" <marco@simplex.nl= >
> > Subject: Re: Re: Re: 17. Chaos Communication Congress - Wie war e= hr?
> >
> > From: <jeff@llandre.freeserve.co.uk>
> >
> > > smt as used by intel etc seems to share the whole of
> > > system ram between all cpus which is dumb.
> > > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram,
> > > but they also share the third sdram for comms.
> >
> > IMO thats combining the bad aspects of NUMA and message passing c= ombined
> in a
> > single framework...
> >
> > > Once core is around, you multi cpu dudes can work on your > > > own multiprocessors.
> >
> > It doesnt have to, if you dont mind have suck ass performance in = a
shared
> memory
> > space multiprocessor system (which is ok, for most processors
> multiprocessor
> > setups are at best an afterthought... allows people like Cray etc= to
make
> some
> > money with custom hardware to maintain coherency, although in thi= s case
> adding
> > that kind of functionality afterwards would be neigh impossible w= ith the
> direct
> > memory interface).
> >
> > If you want to make a processor which can scale decently in
multiprocessor
> > setups you have to know which scheme you will be using at least i= n time
> for the
> > design of the MMU.
> >
> > Marco
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 13
> >    Date: Sun, 07 Jan 2001 19:39:32 -0500
> >    From: Alan Grimes <alangrimes@starpower.net&= gt;
> > Subject: This project really sucks.
> >
> > =3DP
> >
> > om   (I'm invincible!)
> >
> > Hey, you morons, whomever thinks he is running this project is do= ing an
> > absolutly, unforgivably, horrible job. If you were, say, working = for a
> > company and were working in a well-managed tightly optomized R&am= p;D team,
> > you guys would be briliant. BUT YOU'RE NOT!!!
> >
> > In a private company you have the luxury of closed-door face2face=
> > meetings where you can get a lot done. But, for an internet proje= ct such
> > as this, that is totally inadqiquate. You must keep and maintain = a
> > current website...  oops! I *thought* it was f-cpu.tux.org (= which should
> > be updated or deleted.). For the ammount of traffic on the list,<= BR> > > f-cpu.org is also stale, so my point holds, though not as strongl= y.. =3D\
> >
> > An project, such as what this one pretends to be, must provide an= easy
> > "on-ramp" for people who are new to the project to beco= me active
> > participants. Such consessions to the newbies must include:
> >
> > in order of importance:
> >
> > - A glossary.
> > - A reading list.
> > - A document/source managment system. that is easily accessable t= o any
> > reasonable web browser.
> > - A job managment system that can manage tasks and bugs from prop= osal
> > to retirement.
> >
> >
> > The point I am trying to make here is that I have been on the lis= t for
> > two and a half years and I can't even say for certain what the st= atus of
> > the project is or wheather we have reached any "milestones&q= uot;. I am really
> > frustrated by the apparent lack of progress. I need a gnu machine= ! =3DP
> >
> > I therefore make the following demands:
> >
> > - A Czar or voting comission with a fixed registered membership m= ust be
> > appointed or elected for the sole purpose of approving contributi= ons to
> > the document/source managment system with the objective of focusi= ng the
> > efforts of the group towards the completion (*ghasp*) and deliver= y of a
> > product to market.
> >
> > - A formal contributor development system, like what you would fi= nd in a
> > company, that will provide training or mentoring to aspiring
> > contributors.
> >
> > - The founding of an American branch of the apparently extant fre= nch
> > F-CPU orgainization. This is in recognition that local groups wor= k
> > better.
> >
> >
> > Really, This project serves me only when it yields something that= is
> > useful. Failing that it can go to hell...
> >
> > I will see what happens over the next two months and then go bug = the
> > opencore people some more, and perhaps work up a project over the= re.
> >
> > --
> > The 'apocolypse' happened in 1848.
> > Now if everybody would only just look... =3D\
> > http://users.erols= .com/alangrimes/  <my website.
> >
> > Unsolicited "spam" messages to this account are subject= to usage fees
> > and
> > in cases of fraud or egregeous abuse, prosecution.
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 14
> >    Date: Mon, 8 Jan 2001 02:02:09 +0100
> >    From: Michael Riepe <michael@stud.uni-hannov= er.de>
> > Subject: Re: This project really sucks.
> >
> > On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:
> > [...]
> > > The point I am trying to make here is that I have been on th= e list for
> > > two and a half years and I can't even say for certain what t= he status
of
> > > the project is or wheather we have reached any "milesto= nes". I am
really
> > > frustrated by the apparent lack of progress. I need a gnu ma= chine! =3DP
> >
> > You should learn how to read.  Or contribute.  Or shut = up.
> >
> > > I therefore make the following demands:
> >
> > Demands?  F*ck off.  You have no right to demand *anyth= ing*.
> >
> > [...]
> > > Really, This project serves me only when it yields something= that is
> > > useful. Failing that it can go to hell...
> >
> > Don't ask what this project can do for you,
> > ask what YOU can do for the project.
> > (misquoting John F. Kennedy, IIRC)
> >
> > > I will see what happens over the next two months and then go= bug the
> > > opencore people some more, and perhaps work up a project ove= r there.
> >
> > Fine.  Better go NOW and start bugging somebody else.
> >
> > This attitude makes me sick...
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 15
> >    Date: Sun, 07 Jan 2001 20:32:11 -0500
> >    From: Alan Grimes <alangrimes@starpower.net&= gt;
> > Subject: Re: This project really sucks.
> >
> > Michael Riepe wrote:
> > > You should learn how to read.
> >
> > I can read anything that is within the reach of a highschool grad= uate
> > and a fair ammount of mathematical and technical stuff to... As I=
> > mentioned in my post, there is little to suggest WHAT I should re= ad,
> > unless you want me to spend the rest of my life reading crap unti= ll I
> > finally hit on something that is relevant... It took me fully eig= hteen
> > months of applying that self same process to learning how linker-= loaders
> > work. I literally had NO CLUE. Now its all perfectly clear to me.= The
> > position I am taking is that I have no intention of repeating tha= t
> > process.
> >
> > > Or contribute.
> >
> > I can't, for the reasons that I attempted to explain in my last p= osting.
> > READ IT.
> >
> > > Or shut up.
> >
> > Pleas understand that I am running Windows 3.11 on an Athalon pro= cessor.
> >
> > The PC is far too fucked for me to write my own OS. (I have disco= vered
> > this through great labor). But I *can* write an OS for F-cpu (I h= ope).
> >
> > I am hurting.
> >
> >  In a year or so I won't be able to get anything done on the= net at
> > all... I will be profoundly fucked. "Shutting up" is no= t a very good
> > option for me, now is it?
> >
> >
> > > > I therefore make the following demands:
> > >
> > > Demands?  F*ck off.  You have no right to demand *= anything*.
> >
> > Maybe not. But the fact that you can't take an ounce of criticism= with
> > regards to this project is equally un-cool. I have been observing= this
> > project practicaly from day one. I have seen many things not happ= en. ;)
> > This posting was my attempt to encapsulate all the observations I= made
> > into a single simple workable agenda for making things happen. If= you
> > can't take it then go work for a company, you have nothing valubl= e to
> > contribute to an open-source project if you canot accept contribu= tions.
> >
> >
> > > [...]
> > > > Really, This project serves me only when it yields some= thing that is
> > > > useful. Failing that it can go to hell...
> > >
> > > Don't ask what this project can do for you, ask what YOU can= do for
the
> > > project. (misquoting John F. Kennedy, IIRC)
> >
> > Read my fucking posting before making brainless comments like thi= s. It
> > really shows me that you can't think one wit beyond your VHDL (or=
> > whatever) compiler to see that other people can hardly understand= what
> > it is you are doing. THEN you will realize that this posting WAS = a
> > contribution. It contributed the observation that people such as = myself
> > are essentially left-out of the project *and* it proposes a conci= se and
> > understandable method for remedying the situation. If you would l= ike to
> > give me some permissions over at the sourceforge project then I w= ill
> > apply suggestions and my training in project managment towards ac= hieving
> > actual results.
> >
> > I am sorry that linux users tend to be so goddamned dense that th= ey
> > can't see or accept a simple and logical suggestion even when it = is
> > explained to them!  No wonder their operating system is as t= errible as
> > it is...
> >
> >
> > > > I will see what happens over the next two months and th= en go bug the
> > > > opencore people some more, and perhaps work up a projec= t over there.
> > >
> > > Fine.  Better go NOW and start bugging somebody else. > >
> > Hey! Wanna make a CPU?  I not only can but I will make it ha= ppen. This
> > is what needs to be done.
> >
> > > This attitude makes me sick...
> >
> > So does yours.
> >
> > I must appologise, I shouldn't have jumped as hard as I did but I= do
> > really feel a lot of frustration with this...
> >
> > --
> > The 'apocolypse' happened in 1848.
> > Now if everybody would only just look... =3D\
> > http://users.erols= .com/alangrimes/  <my website.
> >
> > Unsolicited "spam" messages to this account are subject= to usage fees
> > and
> > in cases of fraud or egregeous abuse, prosecution.
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 16
> >    Date: Mon, 8 Jan 2001 03:37:48 +0200
> >    From: "Iancu Silvius" <silvius@mai= l.dnttm.ro>
> > Subject: REMOVE
> >
> >
> > ----- Original Message -----
> > From: <f-cpu@egroups.com>
> > To: <f-cpu@egroups.com>
> > Sent: Sunday, January 07, 2001 12:43 PM
> > Subject: [f-cpu] Digest Number 240
> >
> >
> > > There are 5 messages in this issue.
> > >
> > > Topics in this digest:
> > >
> > >       1. Re: Re: 17. Chaos Com= munication Congress - Wie war ehr?
> > >          &= nbsp; From: "Marco Al" <marco@simplex.nl>
> > >       2. Re: Re: 17. Chaos Com= munication Congress - Wie war ehr?
> > >          &= nbsp; From: Nicolas Boulay <nicolas.boulay@ifrance.com>
> > >       3. IT'S HERE..
> > >          &= nbsp; From: bethweinstein@yahoo.com
> > >       4. Re: Re: 17. Chaos Com= munication Congress - Wie war ehr?
> > >          &= nbsp; From: Yann Guidon <whygee@f-cpu.org>
> > >       5. REMOVE
> > >          &= nbsp; From: "maurizio zoboli" <maurizio.zoboli@unimo.it> > > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > > Message: 1
> > >    Date: Sat, 6 Jan 2001 18:49:49 +0100
> > >    From: "Marco Al" <marco@simpl= ex.nl>
> > > Subject: Re: Re: 17. Chaos Communication Congress - Wie war = ehr?
> > >
> > > From: "Yann Guidon" <whygee@f-cpu.org>
> > >
> > >
> > > > talk about a monodirectional synchronous parallel (byte= ?)
> > > > bus with some control signals, a clock (dual edge ?) an= d it's ok for
> > > > me, whatever your idea is. Anybody can implement that w= ith a
> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > >
> > > Is LVDS usually in the standard cell libraries? If you want = to have
the
> > option
> > > of using cables its IMO the clear choice, together with sour= ce
> synchronous
> > > clocking of course (chips will probably still share clocks, = ie be
> > synchronous,
> > > the source clock is just to deal with the delay's at high si= gnalling
> > speeds over
> > > long wires). There is AFAICS a pretty clear consensus in the= industry
> that
> > its
> > > is the way forward for backplanes too. And there are plenty = of TTL
> > interface
> > > chips on the market, plus some FPGA support, so no worries t= here.
> > >
> > > I still like a shared bidirectional (B-LVDS) bus using
> > repeaters/bridges/routers
> > > for scalability. In other words the Intel way, the AMD party= line
swung
> me
> > too
> > > for a while... but now I dont think point to point busses us= e the
> > resources
> > > (pin's and system cost) most effectively. The only way to > proove/disproove
> > that
> > > IMO is to model both alternatives, but Im both too lazy and = I dont
have
> > the
> > > necessary knowledge (AFAICS I would need to know feasibly ph= ysical
> > bandwith per
> > > pin in point to point and bus setups, and have a good traffi= c
breakdown
> > for
> > > multiprocessor setups) .With a lot of broadcast traffic I ju= st dont
> think
> > the
> > > effective bandwith per pin of a point to point bus compares<= BR> favourably,
> > let
> > > alone the extra costs and latency of the routing chips for s= mall SMP
> > setups.
> > >
> > > Marco
> > >
> > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > > Message: 2
> > >    Date: Sun, 07 Jan 2001 00:35:43 +0100
> > >    From: Nicolas Boulay <nicolas.boulay@if= rance.com>
> > > Subject: Re: Re: 17. Chaos Communication Congress - Wie war = ehr?
> > >
> > > Hi,
> > >
> > > Yann Guidon a =E9crit :
> > > >
> > > > hi,
> > > >
> > > > Nicolas Boulay wrote:
> > > > > hi,
> > > > >
> > > > > Yann Guidon a =E9crit :
> > > > > > > The network will made around
> > > > > > > gigabit ethernet link (the electrical pa= rt) because it's well
> > known (and
> > > > > > > free ? ). With 8 ethernet links, we can = reach the true
> gigabytes.
> > This
> > > > > > > made around 8*2*2*2 (2 pairs with 2 ways= and 2 time 500Mhz)
pins
> > for a
> > > > > > > multidirectionnal link, very few in fact= !
> > > > > > you forget several things... no chip can do 8= xGb links. you
forget
> > the ground
> > > > > > connexions in the backplane. This backplane i= s going to be
> extremely
> > expensive,
> > > > > > and i doubt that a "f-cpu hacker" c= an afford a 30-layer PCB made
> > with Teflon.
> > > > > > the idea of the ethernet is simply science fi= ction.
> > > > >
> > > > > Oups, i omit to say for reduice the cost that i wo= uld like to try
to
> > > > > have only one chip and avoid many differents chips= . So the 8 links
> wil
> > l
> > > > > be "inside" the fcpu chip. This is the m= ain system bus.
> > > >
> > > > hum, hum... just a reminder : the SiO2 process is not m= uch the same
> > > > for a CPU and a tranceiver. you CAN't put it on the sam= e die...
> > > >
> > >
> > > I don't think that you know about what you speak ! New silic= on process
> > > are silicium on insulator, soon used by IBM for there udge p= rocessor
for
> > > mainfrain (a little beast with 35 ppc on the same die). And = now, for
the
> > > next powerG3. Next, the SiGe are new process used to have > > > hyperfrequencies, or mixed analogue and digital part. But th= en, it
could
> > > be used for very quick digital circuit.
> > >
> > > And, for information, gigabit ethernet need 500 Mhz. So, &qu= ot;usual
process"
> > > are must enought to make a tranceiver.
> > >
> > > > > The 8 ethernet link could be say has 2 one-way gig= abyte links. So,
> if
> > > > > you use a ring, you need 2 of this links (one by r= ing). So you
will
> > only
> > > > > need a 1 layer PCB !
> > > > beep. wrong. gigabit ethernet, or any ethernet, require= s a very
> special
> > > > medium to propagate. the shield, the impedence adaptati= on, the
> diameter,
> > > > the propagation, etc. are more or less taught in the IU= T or
ingenieur
> > school.
> > >
> > > A=EFe ! You just have to respect electrical rules of the gig= abit
ethernet
> > > (L and C).
> > >
> > > > they're a lot of formula etc, so you can't simply draw = a line and
say
> > "ok".
> > > > it can't be so. otherwise, network cables would be much= cheaper.
> > > > have you heard about "Cat. 5" cables ? did yo= u wonder why it was
more
> > >
> > > You have never learn that this kind of cable could be around= 50 meter
> > > long ! Here 1 or 2 meters is much enought !
> > >
> > > > expensive than other cables ? Plus, you'll need very sp= ecial
> > connectors...
> > > > the usual cheap connectors are not adapted at all.
> > > >
> > > > > > > compare to the normal usual
> > > > > > > parrallel bus (for a link at 133 Mhz com= pare to the >500 Mhz
for
> > the
> > > > > > > giga ethernet link and without to many r= outing problem with
long
> > wires).
> > > > > > i compare what can be compared.
> > > > > > the current idea is simply not realistic.
> > > > > Yes, the idea that you have understood, not mine !=
> > > >
> > > > talk about a monodirectional synchronous parallel (byte= ?)
> > > > bus with some control signals, a clock (dual edge ?) an= d it's ok for
> > > > me, whatever your idea is. Anybody can implement that w= ith a
> > >
> > > Fast clock one large network, you have to deal with clock sk= ew. Most
of
> > > the time, each founder (ST microelectronics, TSMC, infineon,= ...) have
a
> > > macro cell to do gigaethernet and do all the hard things (se= rial,
> > > deserials).
> > >
> > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > >
> > >
> > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? TTL si= gnify 5V
and
> > > some nF of charge. I don't want to repeat it each time.
> > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very slow = compare to
> > > usual system.
> > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) or ar= ound 300 Mhz
> > > with DDR or more with QDR. With LVDS, you can reach around 6= 00 Mhz by
> > > pin. BUT you can't really add a connector between 2 pins at = that
speed.
> > >
> > > My choice is to have a quick link (performance are our goal,= isn't it
> > > ?). Then you just had to provide a bridge between the quick = link and a
> > > SRAM like bus. I think that could be easy : Just a link like= for the
> > > fcpu and a little glue for the interface.
> > >
> > > > now you're asynchronous, you have to deal with PLL and = clock
> > > > recovery, hyperfrequencies, signal integrity, skew, etc= ...
> > > > that a lot of troubles for almost nothing.
> > > >
> > >
> > > Not at all ! because you deal with macrocell and all the suf= t are soon
> > > made.
> > >
> > > > you want speed ? put the wires in parallel, don't seria= lize the
> bits...
> > > >
> > >
> > > Yes, but the limit are the number of pin and the prices ! An= d then you
> > > alwas have the speed of the clock with LVDS, you always have= the
> > > electrical and speed problem.
> > >
> > > > > > i want a draft, numbers, several case studies= , feasibility
> studies,
> > > > > > the reference of the used parts, the protocol= , the VHDL...
> > > > >
> > > > > Yeah, yeah, the bear and the bear's skin ;p
> > > >
> > > > i'm just putting the pressure on your shoulders.
> > > > i'd like to see where your seriousness ends...
> > > >
> > > > > > > Each cpu will have a full 128 bits wide = bus for DDR-SDRAM and
> > "some"
> > > > > > > gigabit ethernet links for system commun= ication. Then you can
> > connect
> > > > > > > the cpu or a IO sub-system for ide/scsi = bus, usb, rs232 ...
> > > > > >
> > > > > > i don't care about this side. you're simply g= oing into a lot of
> > troubles.
> > > > >
> > > > > In fact, it should.
> > > > "should" what ?
> > > >
> > > > > In usual core, you have simple bus and it's easy t= o
> > > > > put rom or eeprom to boot. But here, you need some= thing more
special
> > to boot.
> > > > and who will build that ? do you have the spare parts s= omewhere ?
> > > >
> > >
> > > "spare part", i don't understand. One day, you say= you want
performance,
> > > the other days somthing so slow to be compatible with TTL. I= don't
> > > understand you...
> > >
> > > > > > one way to realize this is by searching the p= arts on the
catalogs
> or
> > databases.
> > > > > > one connector is going to cost as much as the= f-cpu chip. One
> > backplane
> > > > > > will cost 100KF to prototype. it's not a &quo= t;hacker's
architecture".
> > > > >
> > > > > Ben, non...
> > > > >
> > > > ok, now we're going to agree on something...
> > > >
> > > > start with something simple and that works with easy-to= -find parts.
> > > >
> > > > > > > The "delicat" part is : what t= aken as network ? Everybody
knows
> > that i
> > > > > > > prefer a double ring. Double to make a f= ailure revovery (to
plug
> > and
> > > > > > > replug one card without shutting down th= e system). And its
easy
> to
> > > > > > > expand wihtout having any routing proble= ms. Routing is a
problem
> > for
> > > > > > > latency and complexty of the nod. But th= is needs much more
> > explication.
> > > > > > routing is not a problem. the routing algorit= hms are known for a
> > long time
> > > > > > and there's already a large variety of choice= s.
> > > > >
> > > > > Have you a link for a preditive routing algorithme= ? I think that
my
> > > > > collegue which make a thesis about real time netwo= rk will be very
> > > > > interrested to know that exist.
> > > >
> > > > the routing stuff is taught during the DEUG at Paris 8 = university.
> > > > ask Amal Stri from the transversal department.
> > > >
> > > > When at Boston, in a (expensive) library, i found (but = didn't buy)
> > > > a VERY cool about the T3E and similar architectures. Th= e routing
> > > > algos are rather simple and very efficient.
> > > >
> > >
> > > I seriously doubt about the complexity and the scalability..= .
> > >
> > > > > > > Everybody should stay calm ! We need eve= rybody.
> > > > > > yep. F-CPU didn't appear in one day.
> > > > > >
> > > > > > anyway, the debate has shifted very far from = the initial
> > > > > > requirement, and it's rather off-topic. What = we need is a simple
> > > > > > parallel interface to connect the F-CPU to th= e G-chip and other
> > > > > > G-chips. Since they're on the same PCB, we do= n't need hotswap.
> > > > >
> > > > > If we made a simple core (like ARM), we don't need= g-ship and all
> that
> > crap.
> > > > not true. ARM chips require I/O chips. Unless you buy t= he
synthesised
> > core,
> > > > and implement it in the middle of a sea-of-gates ASIC w= ith your
> prefered
> > I/O.
> > > >
> > >
> > > One more times, you don't unsderstand ! i propose like leon,= just to
> > > develope the fc0 (the core) and let other gays to use it. > > >
> > > > ARM, just like any chip, requires a memory controller a= nd I/O.
> > > > look at the Crystal Semiconductors catalog... they have= all the
parts
> > > > necessary to make a PDA or laptop PC.
> > > >
> > > > > If we made a processor ("a system") we s= hould consider to have
> > > > > fault tolerance capabilities. And hot swap is the = basis !
> > > > not necessarily. fault detection and bypass are a SW ma= tter,
> > > > with the help of some HW (ECC/SEC). but the rest is pur= ely an
> electrical
> > > > problem.
> > > >
> > >
> > > Not really, i don't speak about fault detection but failure = tolerant
(a
> > > single dead card don't stop the all system, you just have to= change
it).
> > >
> > > > some designs that you should investigate (using several= different
> books,
> > > > saying different stuffs) : T3D/E (it's a 3D torus with = ALPHAs at the
> > nodes),
> > > > CM1 (12-cube with extremely simple routing), CM5 (fault= tolerance,
> "big
> > tree"
> > > > network, message passing communication etc.), SGI/SUN/H= P scalable
> > computing nodes
> > > > (i found the Convex (circa 1995) very interesting, but = Convex is now
> > owned by HP).
> > > >
> > >
> > > Just for information : how much for a single chip ? And how = much heat
> > > for a chip ? You try to give some piece of your knowledge bu= t you
don't
> > > understand the "simple coma" from SUN for their la= st system (from an
URL
> > > given on the list), so ?
> > >
> > > > i know, it's a matter of culture...
> > > >
> > >
> > > I just see it's like jam, ...
> > >
> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > > Message: 3
> > >    Date: Sat, 06 Jan 2001 22:31:11 -0500
> > >    From: bethweinstein@yahoo.com
> > > Subject: IT'S HERE..
> > >
> > > Expand your business with
> > >     Email Marketing!
> > >
> > > Market your product or service
> > >      to MILLIONS!
> > >
> > > Don't waste another minute...
> > >
> > > Click Reply with your name,
> > > telephone number and the
> > > product or service you wish
> > > to market. We will be in
> > > touch with you shortly!
> > >
> > >
> > >
> > >
> > >
> > > Removal Instructions
> > > ****************************
> > > To be removed from this list
> > > please reply with "REMOVE"
> > > in the subject.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Expand your business with
> > >     Email Marketing!
> > >
> > > Market your product or service
> > >      to MILLIONS!
> > >
> > > Don't waste another minute...
> > >
> > > Click Reply with your name,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > > Message: 4
> > >    Date: Sun, 07 Jan 2001 04:32:50 +0100
> > >    From: Yann Guidon <whygee@f-cpu.org>=
> > > Subject: Re: Re: 17. Chaos Communication Congress - Wie war = ehr?
> > >
> > > hi !
> > >
> > > Marco Al wrote:
> > > > From: "Yann Guidon" <whygee@f-cpu.org><= BR> > > > > > talk about a monodirectional synchronous parallel = (byte ?)
> > > > > bus with some control signals, a clock (dual edge = ?) and it's ok
for
> > > > > me, whatever your idea is. Anybody can implement t= hat with a
> > > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > >
> > > > Is LVDS usually in the standard cell libraries? If you = want to have
> the
> > option
> > > > of using cables its IMO the clear choice, together with= source
> > synchronous
> > > > clocking of course (chips will probably still share clo= cks, ie be
> > synchronous,
> > > > the source clock is just to deal with the delay's at hi= gh signalling
> > speeds over
> > > > long wires). There is AFAICS a pretty clear consensus i= n the
industry
> > that its
> > > > is the way forward for backplanes too. And there are pl= enty of TTL
> > interface
> > > > chips on the market, plus some FPGA support, so no worr= ies there.
> > >
> > > yup. Even though it's not the "hottest" stuff arou= nd (compared to
> > > optical fibers, I2C and mental waves), it works, it's very w= ell
> > understood,
> > > it's widely spread... and it's not over expensive (accessibi= lity of
the
> > > technology vs price vs performance vs...)
> > >
> > > > I still like a shared bidirectional (B-LVDS) bus using<= BR> > > repeaters/bridges/routers
> > > > for scalability. In other words the Intel way, the AMD = party line
> swung
> > me too
> > > > for a while...
> > > after a few months playing with the idea of two unidirection= al buses
> > ("full-duplex",
> > > even though the bandwidth is halved) i feel that it is not a= bad idea
at
> > all.
> > > No arbitration, few synchronisation, very low complexity... = i like it
> :-)
> > >
> > > > but now I dont think point to point busses use the reso= urces
> > > > (pin's and system cost) most effectively.
> > > it depends on your criteria. low pin count ? price ? speed ?= bandwidth
> > ?...
> > > and also on your needs and "budget".
> > >
> > > > The only way to proove/disproove that
> > > > IMO is to model both alternatives, but Im both too lazy= and I dont
> have
> > the
> > > > necessary knowledge (AFAICS I would need to know feasib= ly physical
> > bandwith per
> > > > pin in point to point and bus setups, and have a good t= raffic
> breakdown
> > for
> > > > multiprocessor setups) .With a lot of broadcast traffic= I just dont
> > think the
> > > > effective bandwith per pin of a point to point bus comp= ares
> favourably,
> > let
> > > > alone the extra costs and latency of the routing chips = for small SMP
> > setups.
> > >
> > > well, there's the architecture side here...
> > >
> > > if you target "small SMP" only, maybe you can do i= t with a shared bus,
> > > but don't expect wonders above 4 CPU. If you're doing CPU-on= ly tasks,
> it's
> > > ok, but when you start to move things around, it's the real = mess.
> > > Intel sticks to this because the architecture is more or les= s stuck.
> > > they want cheap systems and make big profits, but still comp= ete (with
> > > some pain) in the SPEC contests.
> > >
> > > I am trying to find the "least common denominator"= for a F-CPU system
> > > that can range from 1 CPU to any arbitrary number of CPUs (j= ust like
> > > the register width : not bound to anything). let's take a fe= w cases,
> > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system"= should also scale
> > > to much more CPUs : the widest systems today (see the monter= s at the
> LANL)
> > > can scale to more than 10K CPU, so let's round up to 65536.<= BR> > > >
> > > now let's compare the alternatives...
> > >
> > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU and it= 's
> disastrous
> > > with more CPU.
> > >
> > > buses are known, used and they work, but some people here wa= nt a
> > "multimaster"
> > > bus. This means that the bandwidth is drawn by several point= s and the
> bus
> > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidth per= CPU, equal
to
> > > the available bandwidth provided by the bus and divided by N= CPU).
> > >
> > > that's what i try to avoid.
> > >
> > > Clearly, this B=3DL/N is a thing that i try to avoid for oth= er things as
> > well,
> > > and it's my "hammer" argument when i try to promot= e point to point
> links.
> > > We spare the (distributed) control logic (all the nasty dead= lock
stuffs
> > etc)
> > > and it's very simple to implement. the PCB is simpler, too.<= BR> > > >
> > > If you connect more than 2 CPU on the same bus, they compete= for the
> > ressource
> > > and the bottleneck gets even narrow.
> > >
> > > On the pin count vs bandwidth argument, it's similar. Of cou= rse, we
can
> > find
> > > a lot of counter-examples and special cases, but the example= of the
> > broadcast
> > > is not the best one. Most of the requests are from one node = to a
single
> > other
> > > and here, the efficiency of a bus drops dramatically ! for a= N-CPU
> system,
> > > the efficiency is of 2 used bus interfaces for N bus interfa= ces (you
can
> > > replace "bus interface" with "pin"), 2/N= is similar to the 1/N scheme
> > > (if we speak about the "big O" or complexity). Thi= s means that :
> > > the more CPU, the least efficient ! you'll see that the best= way to
> avoid
> > > this is by having as few CPU by link as possible, and the mi= nimum is
2.
> > > that's "point to point"...
> > >
> > >
> > > Now, another stuff. Nico usually wants a ring. It's "si= mple to route",
> > > it's fun and doesn't need much "efforts". But ther= e is still the same
> > > problem as before : the more CPU, the less bandwidth when on= e CPU
wants
> > > to talk to another. 1/N (or 2 pins / N CPU if you want the &= quot;real
> > efficiency").
> > > The solution is rather easy : you have to expand that to the= other 2
> > dimensions,
> > > hence the "CRAY T3D" and the extension, T3E. Routi= ng is still the same
> but
> > the
> > > address is split into 3 fields that are interpreted as an in= dependent
> ring
> > address.
> > >
> > > here, you don't have 1 ring but x*y*z rings. It means that t= here is
> > > no bandwidth problem at all, because each CPU communicates w= ith its 6
> > neighbours.
> > > It works very well, it can be tweaked to become "fault = tolerant"
> (through
> > dynamic
> > > node addresses) and scales perfectly (almost linearly with t= he CPU
> > number).
> > >
> > > So if you want the simplest system, you have 1 CPU with no r= ing,
> > > and when you scale up, add a few links when needed and use l= ike "lego
> > bricks"
> > > in a cubic connexion.
> > >
> > > I think that the G-chip was an easy way to make the topology=
> > reconfigurable
> > > by the user/implementor. If we provide the brick, the user w= ill make a
> lot
> > > of stuffs, but if we restrict the choices, the scalability a= nd the
> > flexibility
> > > will suffer.
> > >
> > >
> > > > Marco
> > >
> > > Nicolas Boulay wrote:
> > > >
> > > > Hi,
> > > >
> > > > Yann Guidon a =E9crit :
> > > > >
> > > > > hi,
> > > > >
> > > > > Nicolas Boulay wrote:
> > > > > > hi,
> > > > > >
> > > > > > Oups, i omit to say for reduice the cost that= i would like to
try
> to
> > > > > > have only one chip and avoid many differents = chips. So the 8
links
> > will
> > > > > > be "inside" the fcpu chip. This is = the main system bus.
> > > > >
> > > > > hum, hum... just a reminder : the SiO2 process is = not much the
same
> > > > > for a CPU and a tranceiver. you CAN't put it on th= e same die...
> > > >
> > > > I don't think that you know about what you speak ! New = silicon
process
> > > > are silicium on insulator, soon used by IBM for there u= dge processor
> for
> > > > mainfrain (a little beast with 35 ppc on the same die).=
> > > duh. and how will you ask IBM to make your chip ?
> > > it's not something that everybody can do. it's not free, it'= s
expensive
> > > and it's not connectable to anything...
> > >
> > > > And now, for the next powerG3. Next, the SiGe are new p= rocess used
to
> > have
> > > > hyperfrequencies, or mixed analogue and digital part. B= ut then, it
> could
> > > > be used for very quick digital circuit.
> > > It is. but how many people would use such a chip ? what can = they
connect
> > it to ?
> > > how will you "solve" the RF issues ? Do you know h= ow difficult it is
to
> > route
> > > a 50 MHz signal ? So who will buy you the SW needed to desig= n a RF PCB
?
> > >
> > > > And, for information, gigabit ethernet need 500 Mhz. So= , "usual
> process"
> > > > are must enought to make a tranceiver.
> > > Maybe you should stop to use the term "ethernet". = If it's a simple
> > > "serial link", you're just making a firewire clone= ...
> > >
> > > > > > The 8 ethernet link could be say has 2 one-wa= y gigabyte links.
So,
> > if
> > > > > > you use a ring, you need 2 of this links (one= by ring). So you
> will
> > only
> > > > > > need a 1 layer PCB !
> > > > > beep. wrong. gigabit ethernet, or any ethernet, re= quires a very
> > special
> > > > > medium to propagate. the shield, the impedence ada= ptation, the
> > diameter,
> > > > > the propagation, etc. are more or less taught in t= he IUT or
> ingenieur
> > school.
> > > > A=EFe ! You just have to respect electrical rules of th= e gigabit
> ethernet
> > > > (L and C).
> > > that's a pretty quick simplification. even though at your le= vel it
fits,
> > > when you make the PCB it takes another dimension ...
> > >
> > > > > they're a lot of formula etc, so you can't simply = draw a line and
> say
> > "ok".
> > > > > it can't be so. otherwise, network cables would be= much cheaper.
> > > > > have you heard about "Cat. 5" cables ? d= id you wonder why it was
> more
> > > > You have never learn that this kind of cable could be a= round 50
meter
> > > > long ! Here 1 or 2 meters is much enought !
> > > and you think that it's not the same problem ????
> > > have you heard about Xtalk and such stuff ? you CAN't make i= t with a
> > 1-layer PCB.
> > > you need at least 3 layers to make a decent transmission lin= e
> > > (shield/insulator/signal/insulator/shield). And depending on= your
> signal's
> > > characteristics, you have to change the dimensions of the tr= acks,
> > > so they are adapted to the thickness of the PCB and the perm= eability
of
> > > the insulator (if it's epoxy or teflon or something else). > > >
> > > Whether the wire is 50m or 1m, the problem is the same... > > >
> > > > > > > i compare what can be compared.
> > > > > > > the current idea is simply not realistic= .
> > > > > > Yes, the idea that you have understood, not m= ine !
> > > > > talk about a monodirectional synchronous parallel = (byte ?)
> > > > > bus with some control signals, a clock (dual edge = ?) and it's ok
for
> > > > > me, whatever your idea is. Anybody can implement t= hat with a
> > > > Fast clock one large network, you have to deal with clo= ck skew.
> > > it's an old known problem and there are some old known solut= ions.
> > > ever heard about a "clock tree" ?... if you have a= good architecture,
> > > you don't have skew troubles.
> > >
> > > > Most of the time, each founder (ST microelectronics, TS= MC,
> infineon,...)
> > > > have a macro cell to do gigaethernet and do all the har= d things
> (serial,
> > > > deserials).
> > > and you'll by the components ? come on...
> > > and please, don't talk about "Ethernet", it seems = like it's
> > > only a serial point to point link (if i remember one of your=
messages).
> > >
> > > > > few PALs and 74Fxxx, or a simple/cheap FPGA.
> > > > Arrrrghhh ! What speed do you want to reach ! 5 Mhz ? T= TL signify 5V
> and
> > > > some nF of charge. I don't want to repeat it each time.=
> > > hey, i'm not dumb, i know that TTL is slow. thanks.
> > >
> > > but just a question : how will you debug your stuff ? will y= ou use
> > > a 10GS/s logic analyser ? with a simple enough protocol, i c= an
> > > debug the interface with "off the shelf parts" tha= t i can solder at
> will,
> > > the old school way, just like any "hacker".
> > >
> > > Then, when it's developped, you only have to change the elec= trical
> > > levels (that is : the pin's driving gates) and you can do LV= TTL or
> > whatever
> > > high-speed connexion. it's just a matter of changing the ele= ctrical
> spec.
> > > Yes i want speed, but a "hacker" needs a way to se= e what happens
without
> > > the need of extremely expensive devices. by clocking the chi= p slower
> > > and adapting the electrical level (with the adapted buffers = or
> > transmitters),
> > > you can hook anything to the F-BUS.
> > >
> > > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, very = slow compare to
> > > > usual system.
> > > this kind of speed is used for I/O with maybe a controller o= r
something
> > > like that. When i speak about "TTL parts", it's so= mething like a 8255
> > > or any very slow byte-based I/O chip. just like during the o= ld days
> > > of the 8-bit systems...
> > >
> > > > 2=B0) a quick link about 500 Mhz by bin (gigaethernet) = or around 300
Mhz
> > > > with DDR or more with QDR. With LVDS, you can reach aro= und 600 Mhz
by
> > > > pin. BUT you can't really add a connector between 2 pin= s at that
> speed.
> > > then it must be soldered. but then, this speed is not requir= ed for
> > > handcrafting your own I/O board on a pre-drilled PCB. do you= know a
> mouse
> > > or a keyboard or even a LCD screen that requires 600M x N pi= ns of data
> > > per second ?
> > >
> > > Scalability means scale-down and scale-up. 500Mbps is fine, = but when
you
> > > don't need that much, it's an overkill. And you propose to m= ake an
> adapter
> > > that will bother of the I/O, but how many custom chips will = you
require
> > > to interface your connexion to any other stuffs ? Having a s= imple and
> > > one-fits-all protocol that does low and high-speed helps red= uce the
> > > number of different chips and interfaces...
> > >
> > > > My choice is to have a quick link (performance are our = goal, isn't
it
> > ?).
> > > not only. In the design goals of the F-CPU, there are 3 othe= r stuffs.
> > >
> > > > Then you just had to provide a bridge between the quick= link and a
> > > > SRAM like bus. I think that could be easy : Just a link= like for the
> > > > fcpu and a little glue for the interface.
> > > i'll give you the honnor of doing the first one...
> > >
> > > > > now you're asynchronous, you have to deal with PLL= and clock
> > > > > recovery, hyperfrequencies, signal integrity, skew= , etc...
> > > > > that a lot of troubles for almost nothing.
> > > > Not at all ! because you deal with macrocell and all th= e suft are
soon
> > made.
> > > ain't it magical ??...
> > > are you so confident and faithfull in the technologies ?
> > >
> > > > > you want speed ? put the wires in parallel, don't = serialize the
> > bits...
> > > > Yes, but the limit are the number of pin and the prices= ! And then
you
> > > > alwas have the speed of the clock with LVDS, you always= have the
> > > > electrical and speed problem.
> > >
> > > ok, let's compare serial and parallel.
> > >
> > > you want 1Gbps links. halve it now, because the actual effic= iency
> > > of a serial bus is not the raw peak number. With 10Base, one= can't
> > transfer
> > > more than 500K bytes per second. or 520. whatever.
> > > So let's imagine that you can SUSTAIN 50 M bytes per second.=
> > > caugh. caugh. ok, imagine you can reach 70M bytes in the two=
directions.
> > > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain 1000 = M bytes/s
> > > (or 8 Gbps).
> > >
> > > Ok, i know, you want to reach 8Bgps by using 8 links.
> > > but how are they connected ? if you want to make a ring, you= 'll
> > > dissipate your bandwidth, and if you want to make neighbour = to
neighbour
> > > connexions, you'll require 64 pins (or better 100, counting<= BR> grounds/VCC)
> > > per neighbour. retour case d=E9part...
> > >
> > >
> > > > > > In usual core, you have simple bus and it's e= asy to
> > > > > > put rom or eeprom to boot. But here, you need= something more
> special
> > to boot.
> > > > > and who will build that ? do you have the spare pa= rts somewhere ?
> > > > "spare part", i don't understand.
> > > i mean : go buy some such chips at St Quentin Radio or Radio= Shacks...
> > > a chip that is available for sale in public catalogs.
> > >
> > > > One day, you say you want performance,
> > > > the other days somthing so slow to be compatible with T= TL. I don't
> > > > understand you...
> > >
> > > i want something that can do both, but of course not at the = same time.
> > > you can't access a mouse or handcrafted I/O board (anything = that you
> > > see in Elektor or Electronique Pratique) with the same means= as
another
> > CPU.
> > > But the protocol and the layout must remain the same, as to = ease the
PCB
> > design
> > > and the easy replacement of the chips.
> > >
> > > > > > Have you a link for a preditive routing algor= ithme ? I think
that
> my
> > > > > > collegue which make a thesis about real time = network will be
very
> > > > > > interrested to know that exist.
> > > > >
> > > > > the routing stuff is taught during the DEUG at Par= is 8 university.
> > > > > ask Amal Stri from the transversal department.
> > > > >
> > > > > When at Boston, in a (expensive) library, i found = (but didn't buy)
> > > > > a VERY cool about the T3E and similar architecture= s. The routing
> > > > > algos are rather simple and very efficient.
> > > >
> > > > I seriously doubt about the complexity and the scalabil= ity...
> > >
> > > remember, it's a torus. only, it's 3D :-)
> > > for the other details, it's up to you to go to the library,<= BR> > > > read as many book as you can and ask the teachers and the > > > educated people from comp.arch and comp.sys.super...
> > > i won't do it for you, you wouldn't believe what i say :-P > > >
> > > > > > If we made a simple core (like ARM), we don't= need g-ship and
all
> > that crap.
> > > > > not true. ARM chips require I/O chips. Unless you = buy the
> synthesised
> > core,
> > > > > and implement it in the middle of a sea-of-gates A= SIC with your
> > prefered I/O.
> > > > One more times, you don't unsderstand ! i propose like = leon, just to
> > > > develope the fc0 (the core) and let other gays to use i= t.
> > > so let's drop this silly network/bus whatever debate for a w= hile...
> > >
> > > > > > If we made a processor ("a system")= we should consider to have
> > > > > > fault tolerance capabilities. And hot swap is= the basis !
> > > > > not necessarily. fault detection and bypass are a = SW matter,
> > > > > with the help of some HW (ECC/SEC). but the rest i= s purely an
> > electrical
> > > > > problem.
> > > > >
> > > > Not really, i don't speak about fault detection but fai= lure tolerant
> (a
> > > > single dead card don't stop the all system, you just ha= ve to change
> it).
> > >
> > > it's the SAME thing. You can't be "fault tolerant"= if you can't detect
> > > the fault and take the necessary SW measures. It's obvious..= .
> > > i'm just trying to avoid "buzzwords" that taint th= e debate with black
> > magic ;-)
> > >
> > >
> > > > > some designs that you should investigate (using se= veral different
> > books,
> > > > > saying different stuffs) : T3D/E (it's a 3D torus = with ALPHAs at
the
> > nodes),
> > > > > CM1 (12-cube with extremely simple routing), CM5 (= fault tolerance,
> > "big tree"
> > > > > network, message passing communication etc.), SGI/= SUN/HP scalable
> > computing nodes
> > > > > (i found the Convex (circa 1995) very interesting,= but Convex is
now
> > owned by HP).
> > > >
> > > > Just for information : how much for a single chip ? And= how much
heat
> > > > for a chip ? You try to give some piece of your knowled= ge but you
> don't
> > > > understand the "simple coma" from SUN for the= ir last system (from an
> URL
> > > > given on the list), so ?
> > >
> > > i've tried, but it's not that clear for me, what's so specia= l ?
> > > when there's a page fault, i trap. Just make the correct fau= lt
handler,
> > > and you implement any memory protection and sharing you want= .
> > > It leaves the door open to ANY memory system implementation.=
> > > what else do you want ? i'm still waiting for a clear and HW=
> proposition.
> > >
> > > > > i know, it's a matter of culture...
> > > > I just see it's like jam, ...
> > > J'en ai une meilleure, mais je ne l'ai pas invent=E9e non pl= us,
> > > elle est de Jacques Brel : "La culture, c'est la m=E9mo= ire des
> > > cons qui n'ont rien invent=E9". Il avait vraiment des i= d=E9es
> > > noires avant de mourir... La culture, il faut se la faire > > > tous les jours et ne pas trop camper sur ses positions... > > > avec le f-cpu, on a ce qu'il faut comme action :-)
> > >
> > > bonne nuit,
> > >
> > > > > > > > nicO
> > > > > > > WHYGEE
> > > > > > nicO
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > > Message: 5
> > >    Date: Sun, 07 Jan 2001 11:18:39 +0100 (CET= )
> > >    From: "maurizio zoboli" <maur= izio.zoboli@unimo.it>
> > > Subject: REMOVE
> > >
> > > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.com = wrote:
> > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >telephone number and the
> > > >product or service you wish
> > > >to market. We will be in
> > > >touch with you shortly!
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Removal Instructions
> > > >****************************
> > > >To be removed from this list
> > > >please reply with "REMOVE"
> > > >in the subject.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Expand your business with
> > > >    Email Marketing!
> > > >
> > > >Market your product or service
> > > >     to MILLIONS!
> > > >
> > > >Don't waste another minute...
> > > >
> > > >Click Reply with your name,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Prof. Maurizio Zoboli
> > > Dipartimento di Scienze dell'Ingegneria
> > > Universita' di Modena e Reggio Emilia
> > > via Vignolese 905
> > > I-41100 Modena, Italy
> > > Tel.: +39 059 2056163
> > > Fax: +39 059 2056129
> > > e-mail: maurizio.zoboli@unimo.it
> > >
> > >
> > >
> > >
________________________________________________________________________ > > >
________________________________________________________________________ > > >
> > >
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 17
> >    Date: Mon, 08 Jan 2001 02:53:56 +0100
> >    From: Yann Guidon <whygee@f-cpu.org>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > hello,
> >
> > Nicolas Boulay wrote:
> > > Yann Guidon a =E9crit :
> > > > hi !
> > > > Marco Al wrote:
> > <snip>
> > > > if you target "small SMP" only, maybe you can= do it with a shared
bus,
> > > > but don't expect wonders above 4 CPU. If you're doing C= PU-only
tasks,
> it's
> > > > ok, but when you start to move things around, it's the = real mess.
> > > > Intel sticks to this because the architecture is more o= r less stuck.
> > > > they want cheap systems and make big profits, but still= compete
(with
> > > > some pain) in the SPEC contests.
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface.
> > in such a system, a good bandwidth ratio between external and pri= vate
> buses
> > is critical. Even a message is a heavy stuff. do you imagine that= they
> > only send messages for the new year's eve invitation ? :-P
> >
> > > So in the intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> > hey, i thought that we shouldn't decide for the user ?
> >
> > remember that you cite I/O. Ok, you're used to your slow PC and y= our
> little
> > SPARC. but when Synopsys starts to swap, don't you wish you had m= ore I/O
> ?...
> > I/O shouldn't be the 5th wheel of the car. if you do "multim= edia" (sound
> and video),
> > you understand that it is critical.
> >
> > > > Clearly, this B=3DL/N is a thing that i try to avoid fo= r other things
as
> well,
> > > > and it's my "hammer" argument when i try to p= romote point to point
> links.
> > > > We spare the (distributed) control logic (all the nasty= deadlock
> stuffs etc)
> > > There are always possible traffic Jam. How do you manage whe= n 2 nodes
> > > try to speak to the same nod ? You have to manage something = to avoid
> > > losing informations.
> > losing information ? when ?
> > there is no information loss possible in the protocol i try to se= tup.
> > when there is a contention, there is a delay but that's all.
> >
> > > > and it's very simple to implement. the PCB is simpler, = too.
> > > >
> > > > If you connect more than 2 CPU on the same bus, they co= mpete for the
> ressource
> > > > and the bottleneck gets even narrow.
> > >
> > > Yes, but less drastically as intel SMP.
> > >
> > hum, what's the difference ?...
> >
> > > > On the pin count vs bandwidth argument, it's similar. O= f course, we
> can find
> > > > a lot of counter-examples and special cases, but the ex= ample of the
> broadcast
> > > > is not the best one. Most of the requests are from one = node to a
> single other
> > >
> > > In fact, not. It depend how much process communicate between= them. And
> > > sometimes the only [simple] way to find a "moving"= ressources is to
send
> > > a braodcast.
> >
> > And what if no boradcast was possible ?
> > the solution is to interrogate a list of the ressources, located = in
> > a public memory, just like you explained in one of your lesson, > > where the 4 shared memory schemes are explained.
> >
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
> wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
> efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
> dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same
> but the
> > > > address is split into 3 fields that are interpreted as = an
independent
> ring address.
> > >
> > > In the flight back to France, we have spoken about ring of r= ing.(and
> > > called the architecture the lord of the ring ;p).
> > know your history ;-) look at the KSR-1 and successors (that neve= r
really
> > worked, btw). hum, was it Kendal Square Research or another simil= ar
> > "small supercomputing" company ?
> >
> > > A ring is composed
> > > around 8 to 16 card (cpu+ram or IO). A card could be used to=
communicate
> > > with other ring. Maybe it's possible to grow in hierachy wit= hout to
much
> > > trouble.
> >
> > in theory, yes. In practice, it's not used. it's been done and ne= ver
took
> off.
> >
> > > > here, you don't have 1 ring but x*y*z rings. It means t= hat there is
> > > > no bandwidth problem at all, because each CPU communica= tes with its
6
> neighbours.
> > > > It works very well, it can be tweaked to become "f= ault tolerant"
> (through dynamic
> > > > node addresses) and scales perfectly (almost linearly w= ith the CPU
> number).
> > > >
> > > So !
> > >
> > "so what" ?
> >
> > > > So if you want the simplest system, you have 1 CPU with= no ring,
> > > > and when you scale up, add a few links when needed and = use like
"lego
> bricks"
> > > > in a cubic connexion.
> > > Cubic ~=3D  ring ????
> >
> >           =   __A_____C_____E______G______I__
> > 1 ring :   (__B_____D_____F______H______J__)
> >
> > (notice the pairs of nodes : one pair is added to extend the ring= )
> >
> > a 2D ring :
> >     A   B   C  = D   E ....
> >
> > 1   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D<= BR> > >     ||  ||  ||  ||  || > > 2   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D<= BR> > >     ||  ||  ||  ||  || > > 3   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D<= BR> > >     ||  ||  ||  ||  || > > 4   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D<= BR> > >     ||  ||  ||  ||  || > > 5   8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D8=3D=3D=3D<= BR> > >     ||  ||  ||  ||  || > > ...
> >
> > one "8" is a node that establish the connexion between<= BR> > > a vertical ring and a horizontal ring. So a "node" comp= rises
> > 4 CPU and 4 bidirectional links.
> >
> > 3D : extend to 6 CPU and 6 links per node.
> > Here, the node is a "cube" with one connexion on every = facet.
> > that's why i used the term of "lego brick" : when you w= ant to add
> > a CPU, you add a cube. when you want to replace or add cubes,
> > you deal with "boxes".
> >
> > In practice, the physical implementation is not so simple
> > (we have to deal with 2D PCBs and connectors) but the routing
> > is the same as with your everyday "ring" network, excep= t that
> > the address is split into 3 fields that are routed almost
> > independently. when you see a match on your X and Y values but > > a wrong Z, you simply send to the Z link. Whether it's +Z or -Z > > depends on the substraction of the current address and the desire= d
> > address : send to +Z link if the result is negative and vice vers= a.
> >
> > One CPU is dead ? break the links (invalide the link in the neigh= bours)
> > and ignore the corresponding routing field in the neighbours.
> > This way, no message will go through the dead node.
> > Want to replace a CPU ? rename the nodes : change the address of<= BR> > > every working node so the "good" spare node becomes vis= ible in the
> machine.
> > Usually, in a 1000 CPU system, around 30 or 50 CPUs are left for = the
> > reserve. they are remapped when a CPU fails. otherwise, they serv= e
> > as "spies" in the network and they help analyse the tra= ffic.
> >
> > this is not verbatim how the T3E works, but there's no big differ= ence
> AFAIK.
> >
> > > > > Marco
> > > > Nicolas Boulay wrote:
> > > > > Hi,
> > > > > Yann Guidon a =E9crit :
> > > > > > hi,
> > > > > > Nicolas Boulay wrote:
> > > > > > > hi,
> > > > > I don't think that you know about what you speak !=
> > hey ! i read Electronique Internationale Hebdo every week :-)
> > i know more or less who opens what plant and where, for what tech= nology
> > and what price.
> >
> > > > > New silicon process
> > > > > are silicium on insulator, soon used by IBM for th= ere udge
processor
> for
> > > > > mainfrain (a little beast with 35 ppc on the same = die).
> > > > duh. and how will you ask IBM to make your chip ?
> > > > it's not something that everybody can do. it's not free= , it's
> expensive
> > > And you think that actual 0.18 =B5m are free ?
> > listen, boy, "they" made the first ALPHA chip in 0.75u = technology, back
> around 1992.
> > if we can _reach_ that, you'll be able to dream like you want. > > we're still rookies, we have not much experience and we dream a l= ot.
> >
> > > In 2 years, SOI will be
> > > used in every silicon process, because it reduice the power<= BR> consumption
> > > and doesn't cost so much (it's just a little traitement on w= afer).
> > it's a matter of accessing the technology, not a matter of what technology
> > is better.
> >
> > > > and it's not connectable to anything...
> > > ??? I think you miss something... The only electrical rules = to respect
> > > is the higher voltage in input, most of the time lower than = 3.3 V, to
> > > avoid destroying transistor, that's all.
> >
> > by that, i meant : where do you plug it ? you have to design ever= ything
!
> >
> > > > > And now, for the next powerG3. Next, the SiGe are = new process used
> to have
> > > > > hyperfrequencies, or mixed analogue and digital pa= rt. But then, it
> could
> > > > > be used for very quick digital circuit.
> > > > It is. but how many people would use such a chip ? what= can they
> connect it to ?
> > > > how will you "solve" the RF issues ? Do you k= now how difficult it is
> to route
> > > > a 50 MHz signal ? So who will buy you the SW needed to = design a RF
PCB
> ?
> > > I think that Cadence has offer something. (any news ?)
> > only high-level RTL design tools, no PCB design yet.
> >
> > > You want performance and you think that 50 Mhz signal are to= much. How
> do you
> > > want to deal with 133 Mhz DDR-SDRAM ?
> > i didn't say that 50 MHZ is to much. I say that it causes already= a lot
of
> > troubles that rookies like us can't solve with a simple "let= 's do this"
> workaround.
> > when i started electronics, 27MHz was rather difficult, and the 1= 44MHz
was
> almost
> > black magic. Now you come and you want 500MHz. i say : ok, but le= t's
make
> something
> > "work" first, so we can see what to not do with higher = frequencies.
> > If we ever get a 50MHz, or even 10MHz chip working correctly, i'l= l be
> happy.
> > didn't they tell you at ASIME that almost none of their chips wor= ks
above
> 100MHz ?
> >
> > > > > And, for information, gigabit ethernet need 500 Mh= z. So, "usual
> process"
> > > > > are must enought to make a tranceiver.
> > > > Maybe you should stop to use the term "ethernet&qu= ot;. If it's a simple
> > > But in electrical rules, gigaethernet is only a serial point= to point
> > > link, not much more (just add the mac adress and a crc).
> > it implies too much. Just reuse/paraphrase what you just wrote :<= BR> > > "a serial point to point link" and that's ok for me. > >
> > > > "serial link", you're just making a firewire = clone...
> > > A=EFe ! Firewire isn't a point to point serial link !!!! It'= s a complete
> > > network system which include the 3rd layer of the OSI system= . It
include
> > > the routing protocole and all that stuff (the same thing tha= n IP )!
> > remember what you wrote : "But in electrical rules, "..= ..
> > I don't care about the OSI or whatever. I care about the efficien= cy
> > of the stuff.
> >
> > > > > You have never learn that this kind of cable could= be around 50
> meter
> > > > > long ! Here 1 or 2 meters is much enought !
> > > > and you think that it's not the same problem ????
> > > > have you heard about Xtalk and such stuff ? you CAN't m= ake it with a
> 1-layer PCB.
> > > That's why ethernet cable are made by pair (like lvds, d is = for
> > > differential). And with some ground it could pass.
> > i like the last phrase :-)
> >
> > now i think that you should look at the "Autobahn" bus,= added to some
> > VME backplanes designed by whatever company (Force Computers ?).<= BR> > > They added a high-speed serial link to VME, 5 years ago IIRC.
> > You could learn a lot about their designs and their errors.
> >
> > > > you need at least 3 layers to make a decent transmissio= n line
> > > so 4 layers, like usual mother board.
> > hum....
> > i learnt something during the last year : we shouldn't be too opt= imistic
> > with PCB layers. you need 3 layers for _transmitting_ the signal,= but
> > depending on your connectors and backplane, you can easily reach<= BR> > > 10 or even 20 layers very quickly ! if your connectors are too de= nse,
> > you'll have to route some tracks with additional layers.
> >
> > > > (shield/insulator/signal/insulator/shield). And dependi= ng on your
> signal's
> > > > characteristics, you have to change the dimensions of t= he tracks,
> > > > so they are adapted to the thickness of the PCB and the= permeability
> of
> > > > the insulator (if it's epoxy or teflon or something els= e).
> > > >
> > > > Whether the wire is 50m or 1m, the problem is the same.= ..
> > >
> > > Not really. The Characteristique are made to say that your c= able could
> > > be 50 meter long, so the signal could be mixed with a certai= n level of
> > > noise. If you need shortest cable, you could adjust the qual= ity of the
> > > cable.
> > it's not a good reason to be laxist...
> > you still have to respect the electrical rules
> > and use severe constraints on the PCB.
> >
> > > > > Fast clock one large network, you have to deal wit= h clock skew.
> > > > it's an old known problem and there are some old known = solutions.
> > > > ever heard about a "clock tree" ?... if you h= ave a good
architecture,
> > > > you don't have skew troubles.
> > >
> > > Don't forget that i'm microelectronic engineer and clock tre= e are a
> > > basis... Which is not so simple at all.
> > >
> > but at least they are known and used for what they're worth.
> >
> > > > > Most of the time, each founder (ST microelectronic= s, TSMC,
> infineon,...)
> > > > > have a macro cell to do gigaethernet and do all th= e hard things
> (serial,
> > > > > deserials).
> > > > and you'll by the components ? come on...
> > >
> > > The chip maker will by it.
> > >
> > and then let the end user pay the bill.
> >
> > > > and please, don't talk about "Ethernet", it s= eems like it's
> > > > only a serial point to point link (if i remember one of= your
> messages).
> > > >
> > >
> > > But, it is !
> > >
> > so stop about speaking about Ethernel, but try "fast serial = link"...
> >
> > > > > > few PALs and 74Fxxx, or a simple/cheap FPGA.<= BR> > > > > > Arrrrghhh ! What speed do you want to reach ! 5 Mh= z ? TTL signify
5V
> and
> > > > > some nF of charge. I don't want to repeat it each = time.
> > > > hey, i'm not dumb, i know that TTL is slow. thanks.
> > > >
> > > > but just a question : how will you debug your stuff ? w= ill you use
> > > > a 10GS/s logic analyser ? with a simple enough protocol= , i can
> > > > debug the interface with "off the shelf parts"= ; that i can solder at
> will,
> > > > the old school way, just like any "hacker". > > > >
> > >
> > > Like everybody, you will use a standart JTAG port.
> > >
> > LMFAO :-)
> >
> > when i speak about "debug", i speak about seeking error= s
> > in the dynamic mode, at high speed, i don't speak about seeking > > static errors. dynamic errors are harder to track and JTAG is use= less
> > here (it's not a terabit link ;-P)
> >
> > > > Then, when it's developped, you only have to change the= electrical
> > > > levels (that is : the pin's driving gates) and you can = do LVTTL or
> whatever
> > > > high-speed connexion. it's just a matter of changing th= e electrical
> spec.
> > > > Yes i want speed, but a "hacker" needs a way = to see what happens
> without
> > > > the need of extremely expensive devices. by clocking th= e chip slower
> > > > and adapting the electrical level (with the adapted buf= fers or
> transmitters),
> > > > you can hook anything to the F-BUS.
> > >
> > > If you use low voltage it's because you can't manage with hi= gher one.
So
> > > it could be impossible to change it !
> > >
> > hey, some chips are here for that ...
> > there are also mixed-voltage FPGAs that can do both the electrica= l
> > adaptation and the protocol management.
> >
> > > > > 1=B0) a ttl compliant bus (~30Mhz max), but slow, = very slow compare
to
> > > > > usual system.
> > > > this kind of speed is used for I/O with maybe a control= ler or
> something
> > > > like that. When i speak about "TTL parts", it= 's something like a
8255
> > > > or any very slow byte-based I/O chip. just like during = the old days
> > > > of the 8-bit systems...
> > >
> > > And you want performance by slow down the network only to pu= t good old
> > > I/o chip....
> > >
> > here you mix everything. i want flexibility : being able to go at= full
> steam
> > with specific electrical interfaces, and allow anybody to plug a = custom
> > board without pain. What's the use of a ultra-high-speed bus if y= ou
can't
> > connect anything on it ?
> > let's compare ISA and PCI : the first is slow, but it survives be= cause
> > it's very easy to design boards for this bus. The second bus is f= aster,
> > is sexier but a big mess : you need a more expensive technology > > and very specific tools. Circuits like the AMCC "matchbox&qu= ot; didn't appear
> > until recently. I don't say that PCI is worse than ISA, i say tha= t
> > it is less useful. It was imposed (remember the VLB ?) by some in= dustry
> > cartel and slowly accepted. If we provide an easy entry in the sy= stem
> > with an easy-to-interface bus, we'll have a broader user base and= easy
> ramp-up
> > in frequency. thus more success.
> >
> >
> > > > > 2=B0) a quick link about 500 Mhz by bin (gigaether= net) or around 300
> Mhz
> > > > > with DDR or more with QDR. With LVDS, you can reac= h around 600 Mhz
> by
> > > > > pin. BUT you can't really add a connector between = 2 pins at that
> speed.
> > > > then it must be soldered. but then, this speed is not r= equired for
> > > > handcrafting your own I/O board on a pre-drilled PCB. d= o you know a
> mouse
> > > > or a keyboard or even a LCD screen that requires 600M x= N pins of
data
> > > > per second ?
> > > >
> > > ????? I speak only for the network system, to be compared to= the bus
> > > system in intel board the 64 bit now 200 Mhz multipomped bus= . Not to
the
> > > PCI or EISA.
> > >
> > i think that i have lost track anyway.
> >
> > > > Scalability means scale-down and scale-up. 500Mbps is f= ine, but when
> you
> > > > don't need that much, it's an overkill. And you propose= to make an
> adapter
> > > > that will bother of the I/O, but how many custom chips = will you
> require
> > > > to interface your connexion to any other stuffs ? Havin= g a simple
and
> > > > one-fits-all protocol that does low and high-speed help= s reduce the
> > > > number of different chips and interfaces...
> > >
> > > First only one to connect other system (PCI, IO,...) and no = G-ship
> > > (include inside the fcpu)
> > >
> >
> > if the "g-chip" (not "g-ship") is included in= side the f-cpu chip, then
> > it's only a f-cpu with more communication channels, but more pins= .
> > I don't think that we can afford all the sexy technology now... > >
> > > > > My choice is to have a quick link (performance are= our goal, isn't
> it ?).
> > > > not only. In the design goals of the F-CPU, there are 3= other
stuffs.
> > > >
> > > Which one ?
> > >
> > I thought that you read the presentation text, the manual and saw= the
> > conference in Berlin...
> >
> > c&p of the F-CPU manual, part1.html :
> > "
> >           =    To develop and make freely available an architecture, and
all
> other intellectual
> > property necessary to fabricate one or more implementations of th= at
> architecture, with the
> > following priorities, in decreasing order of importance:
> >
> >        1. Versatility and usef= ulness in as wide a range of applications
as
> possible
> >        2. Performance, emphasi= zing user-level parallelism and derived
> through intelligent
> >           =    architecture rather than advanced silicon process
> >        3. Architecture lifespa= n and forward compatibility
> >        4. Cost, including mone= tary and thermal considerations
> > "
> >
> > i didn't write it. i participated in the debates but it was accep= ted
> during a poll
> > on this mailing list. it can be tracked down easily with the eGro= ups
> website search engine.
> >
> > i think that your propositions are off-topic for the f-cpu projec= t.
> >  1) high-speed serial links are not useful everywhere. it re= quire
specific
> >      interface chips that don't exist ye= t.
> >  2) performance : you use brute-force technology, not an &qu= ot;intelligent
> architecture".
> >      i am still waiting for a groundbrea= king idea :-)
> >  3) lifespan : you'll drop the Gbps when something "sex= ier" will appear.
> >  4) cost : what budget do you expect ?
> >
> > i don't want to bring you down. Some people are enthusiastic and = i don't
> > want to break their hopes. You have sparkled an idea, now you nee= d two
> things :
> >  - you have to find your place in the landscape of the Free = Hardware
> projects.
> >      it seems that this list and this pr= oject is not a good place to do
> this,
> >      we better speak about scheduling an= d the ISA...
> >  - you need a good architecture. Remember that it took almos= t a year
> before
> >      we found something good for the F-C= PU.
> >
> > You, and i hope Jeff and others, will have a lot of work to do. > >
> >
> > > > > > now you're asynchronous, you have to deal wit= h PLL and clock
> > > > > > recovery, hyperfrequencies, signal integrity,= skew, etc...
> > > > > > that a lot of troubles for almost nothing. > > > > > Not at all ! because you deal with macrocell and a= ll the suft are
> soon made.
> > > > ain't it magical ??...
> > > > are you so confident and faithfull in the technologies = ?
> > > Read there spec.
> > i was below the reality. You're playing with fire :-)
> > some bad experiences with Intel and ADi documentations
> > taught me to NEVER TRUST them. it's clearly written in
> > the disclaimer part : everything is "thought" to be acu= rate
> > and can be changed at any time without the consent of the
> > customer. but you won't learn until you get burnt :-)
> >
> > > > > > you want speed ? put the wires in parallel, d= on't serialize the
> bits...
> > > > > Yes, but the limit are the number of pin and the p= rices ! And then
> you
> > > > > alwas have the speed of the clock with LVDS, you a= lways have the
> > > > > electrical and speed problem.
> > > >
> > > > ok, let's compare serial and parallel.
> > > >
> > > > you want 1Gbps links. halve it now, because the actual = efficiency
> > > > of a serial bus is not the raw peak number. With 10Base= , one can't
> transfer
> > > > more than 500K bytes per second. or 520. whatever.
> > > > So let's imagine that you can SUSTAIN 50 M bytes per se= cond.
> > > > caugh. caugh. ok, imagine you can reach 70M bytes in th= e two
> directions.
> > > > 150M bytes ? a 133 MHz 64-bit SDRAM module can sustain = 1000 M
bytes/s
> > > > (or 8 Gbps).
> > >
> > > True but with how many wire ?
> > >
> > that's rather similar, but now i'll add an argument :
> > how much time ?
> >
> > with a serial bus, when you want to pass a message to a node,
> > you have to transmit a packet containing :
> > - who will receive it
> > - who sent it
> > - how large
> > - some control and description stuff.
> >
> > In a 64-bit machine with 64-bit address space,
> > it takes around 150 bits (more or less 30%)
> > plus the data. that makes : 150 * 1 ns/bit (1Gbps peak rate)
> > or 150 ns.
> >
> > now, how long does it takes to transmit the address
> > and the control signals on a paralle wire ? 10ns ?
> > even if it took 15ns, it would be 10x faster than
> > your serial link. so i can say that the latency
> > of your network is nearly disastrous :-P
> >
> > > > Ok, i know, you want to reach 8Bgps by using 8 links. > > > > but how are they connected ? if you want to make a ring= , you'll
> > > > dissipate your bandwidth, and if you want to make neigh= bour to
> neighbour
> > > > connexions, you'll require 64 pins (or better 100, coun= ting
> grounds/VCC)
> > > > per neighbour. retour case d=E9part...
> > >
> > > Compare the number of wire and the cost of a BGA compare to = a PGA.
> > >
> > it's rather off-topic, we can't decide that it will work only wit= h BGA.
> > you know (i presume) that there are some other technologies as we= ll,
> > such as flip-chip etc... And you know that the number of pins
> > is only one of the problems. for example, if you reach higher yie= lds
> > in the whole production fab, you'll reduce the cost of the chips<= BR> > > and the relative cost per pin as well.
> >
> > > > > > > In usual core, you have simple bus and i= t's easy to
> > > > > > > put rom or eeprom to boot. But here, you= need something more
> special to boot.
> > > > > > and who will build that ? do you have the spa= re parts somewhere
?
> > > > > "spare part", i don't understand.
> > > > i mean : go buy some such chips at St Quentin Radio or = Radio
Shacks...
> > > > a chip that is available for sale in public catalogs. > > > You are realy funny, even by Radiospares you can't buy 3.3 V= logic,
and
> > > you want an killing design to compet against alpha !
> > yes.
> > but i know that St Quentin Radio, Selectronics etc, they sell
> > some FPGA and other affordable chips that can play the interface<= BR> > > with a 3.3V F-BUS and a custom board. It's the same kind
> > of technology, or even cheaper as what you can read in Elektor...=
> >
> > > > But the protocol and the layout must remain the same, a= s to ease the
> PCB design
> > > > and the easy replacement of the chips.
> > > *<;p
> > at least, you have some sense of humor ;-P
> >
> > > > > Just for information : how much for a single chip = ? And how much
> heat
> > > > > for a chip ? You try to give some piece of your kn= owledge but you
> don't
> > > > > understand the "simple coma" from SUN fo= r their last system (from
an
> URL
> > > > > given on the list), so ?
> > > > i've tried, but it's not that clear for me, what's so s= pecial ?
> > > > when there's a page fault, i trap. Just make the correc= t fault
> handler,
> > > > and you implement any memory protection and sharing you= want.
> > > > It leaves the door open to ANY memory system implementa= tion.
> > > > what else do you want ? i'm still waiting for a clear a= nd HW
> proposition.
> > > HW or SW that not the point, you can used both for the same = thing, the
> > > only 2 issue are cost and performance. Bevore, we had to fin= d the
> > > algorythmes and then implement it.
> > of course it's the point because the good separation is critical = for the
> > performance/cost. read P&H :-)
> > So please analyse your preferred algorithm, and tell me what HW d= oes
> > the most critical thing. It should be a simple unit, or at least<= BR> > pipelineable,
> > just like any unit in the F-CPU. I don't want a "COMA contro= ler"-like
> name,
> > i want something that anybody can interpret without going through= the
> Websters.
> > something like : lookup table, comparator, adder, ...
> > then, there's no problem to support COMA or whatever but don't gi= ve me
all
> the
> > work. You proposed something, you have to help if you want your i= dea to
> succeed.
> > Similarly for your micro-network : you have to do it. There's no = magic.
> >
> > > "La culture est ce qui reste quand on ne sait rien fair= e" Francoise
> > > SAGAN, un peu provoc, l=E0... ;p
> > elle en connait un rayon l=E0-dessus ;-P
> >
> > > > > > > > > nicO
> > > > > > > > WHYGEE
> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 18
> >    Date: Mon, 08 Jan 2001 05:14:25 +0100
> >    From: Yann Guidon <whygee@f-cpu.org>
> > Subject: Re: This project really sucks. (yes we know, but that's = what
> makes it so interesting :-D)
> >
> > some ramble-commenting,
> > discard if you don't care...
> >
> > Alan Grimes wrote:
> > > =3DP
> > >
> > > om   (I'm invincible!)
> > me too ! me too ! me ... <wham>
> >
> > >         Hey, you mor= ons, whomever thinks he is running this project is
> doing an
> > > absolutly, unforgivably, horrible job. If you were, say, wor= king for a
> > > company and were working in a well-managed tightly optomized= R&D team,
> > > you guys would be briliant. BUT YOU'RE NOT!!!
> > hey, do you know ANY "well-managed tightly optomized R&D= team" ? :-P
> > if so, i'd like to see it :-)
> >
> > >         In a private= company you have the luxury of closed-door
> face2face
> > > meetings where you can get a lot done.
> > make me dream... what's the name of this company ? :-)
> > <no, i won't leave Mentor>
> >
> > > But, for an internet project such
> > > as this, that is totally inadqiquate. You must keep and main= tain a
> > > current website...
> > is there a webmaster in the room ?
> > any ?
> >
> > i'd like to do a million things, sleep, eat, have fun, go to gigs= and
> > have a wife or two, but the VHDL and manual are my top priorities= .
> > If anybody wants to take the responsibility of the web sites, it'= s ok
> > for me, i'll pass the rights and tricks, but please ... stop shou= ting
:-)
> >
> > >  oops! I *thought* it was f-cpu.tux.org (which should > > > be updated or deleted.).
> > status : like the mailing list. Mathis is unreachable,
> > he's gone the AlphaGhost, Balsa and other's way.
> > let's remember this and not repeat the errors...
> >
> > > For the ammount of traffic on the list,
> > > f-cpu.org is also stale, so my point holds, though not as st= rongly..
=3D\
> >
> > if you want to contribute, please mail me an updated version of t= he page
> > (i'll upload it whenever i connect to the site one day) or take t= he
> responsibilities
> > of your requests. it's not that difficult after all : it takes &q= uot;some
> time", patience
> > and a PC with a modem.
> >
> > >         An project, = such as what this one pretends to be, must provide
> an easy
> > > "on-ramp" for people who are new to the project to= become active
> > > participants. Such consessions to the newbies must include:<= BR> > > >
> > > in order of importance:
> > >
> > >         - A glossary= .
> > >         - A reading = list.
> > >         - A document= /source managment system. that is easily
accessable
> to any
> > > reasonable web browser.
> > >         - A job mana= gment system that can manage tasks and bugs from
> proposal
> > > to retirement.
> >
> > hmmm, you seem to be the best one to do all that :-)
> >
> > ok ok, i stop my silly irony. Of course, all that is fine.
> > we want a working CPU, plus a lot of professional tools...
> > what we really need is TIME and involved persons. Up to now,
> > the largest teams were 2 or 3 people.
> >
> > how did the f-cpu advance ? Mathias+me : fc0 + manual, Michael+me= :
VHDL,
> > of course with very helpful punctual help from a lot of others. > > Olivier now helps for the manual's technical maintainance, i upda= te the
> contents.
> > Mathias left, i hope that Michael will stay much longer, and i ho= pe that
> > i won't slowly abandon the project. it's too much work and it wou= ld fade
> away...
> >
> > > The point I am trying to make here is that I have been on th= e list for
> > > two and a half years and I can't even say for certain what t= he status
of
> > > the project is or wheather we have reached any "milesto= nes".
> > are there any milestones after all ?
> > one BIG psychological milestone is that we started to make some d= ecent
> VHDL.
> > Anybody can now contribute to this part. I estimate that it's a f= irst
good
> step.
> > But, just like the manual, it's a new burden of work to carry on = and
make
> work.
> >
> > > I am really frustrated by the apparent lack of progress.
> > everybody is frustrated. But what keeps you from helping ?
> >
> > > I need a gnu machine! =3DP
> > i first read "machine gun" ;-)
> > I also need this gnu HW, like a lot of people.
> > but do you think it will fall from the start with the force of yo= ur
> prayers ?
> >
> > > I therefore make the following demands:
> > now that you have formalized them, please help them come true :-)=
> > you will help yourself and others as well.
> >
> > > - A Czar or voting comission with a fixed registered members= hip must
be
> > > appointed or elected for the sole purpose of approving contr= ibutions
to
> > > the document/source managment system with the objective of f= ocusing
the
> > > efforts of the group towards the completion (*ghasp*) and de= livery of
a
> > > product to market.
> > what market ?
> >
> > we have an open arena where everybody can submit and discuss idea= s.
> > if somebody feels isolated or not understood, he can do his own v= ersion
> and
> > start his own development.
> >
> > > - A formal contributor development system, like what you wou= ld find in
a
> > > company, that will provide training or mentoring to aspiring=
> > > contributors.
> > name that company :-)
> >
> > > - The founding of an American branch of the apparently extan= t french
> > > F-CPU orgainization. This is in recognition that local group= s work
> > > better.
> > seeing the lack of action in France, where we seem to be more
> > organized than outside of Europe, this is going to be a big
> > undertaking. I'll send you a reward (cheese ? wine ?) if you succ= eed !
> > Frankly, i hope that more people organize themselves around the g= lobe...
> >
> > > Really, This project serves me only when it yields something= that is
> > > useful. Failing that it can go to hell...
> > sure, Al, but do you think it can be for free ?
> > if you don't participate actively, you don't have the garantee th= at
> > it will work one day. Now, you don't participate because it's not=
> successful.
> > but if you reverse the situation and make some continuous efforts= ,
> > you'll give us more chances.
> > And maybe : if you get more involved, you will feel less disapoin= ted.
> >
> > > I will see what happens over the next two months and then go= bug the
> > > opencore people some more, and perhaps work up a project ove= r there.
> > well, you do whatever you can. you can lurk whenever you want, bu= t
> > you won't get much for free. if you don't participate, then you w= on't
> > have no right to criticize ... heh.
> >
> >
> > Michael Riepe wrote:
> > > On Sun, Jan 07, 2001 at 07:39:32PM -0500, Alan Grimes wrote:=
> > > [...]
> > > > I therefore make the following demands:
> > > Demands?  F*ck off.  You have no right to demand *= anything*.
> > he has the right to make any demands he wants. we all have expect= ations.
> > but it's not a "one-way" deal. his demand will not be f= ullfilled if
> > there's nothing in return. logic.
> >
> > > [...]
> > > > Really, This project serves me only when it yields some= thing that is
> > > > useful. Failing that it can go to hell...
> > >
> > > Don't ask what this project can do for you,
> > > ask what YOU can do for the project.
> > > (misquoting John F. Kennedy, IIRC)
> >
> > it's been misquoted so many times that i wonder if it was JFK the= first
> who told that...
> > :-)
> >
> > > > I will see what happens over the next two months and th= en go bug the
> > > > opencore people some more, and perhaps work up a projec= t over there.
> > > Fine.  Better go NOW and start bugging somebody else. > > >
> > > This attitude makes me sick...
> > in one year or two, you won't ever care :-)
> >
> > this list is an interesting place anyway. it's like an experience=
> > on entropy, darwinism, cyberculture etc...
> >
> > and it keeps you ready for anything : the worse like the best. > > the remedy for boredom.
> >
> >
> > then, the backfire :
> >
> > Alan Grimes wrote:
> > > Michael Riepe wrote:
> > > > You should learn how to read.
> > > I can read anything that is within the reach of a highschool= graduate
> > > and a fair ammount of mathematical and technical stuff to...=
> > this answer is the proof :-)
> >
> > > As I mentioned in my post, there is little to suggest WHAT I= should
> read,
> > > unless you want me to spend the rest of my life reading crap= untill I
> > > finally hit on something that is relevant...
> > if you don't want to read crap, please contribute with something = more
> interesting
> > than basic sparks (i don't call that flames...). you're free, you= 're
adult
> > (?) and you have a brain. now it's time to prove that they work w= ell
> together.
> >
> > > It took me fully eighteen
> > > months of applying that self same process to learning how linker-loaders
> > > work. I literally had NO CLUE. Now its all perfectly clear t= o me. The
> > > position I am taking is that I have no intention of repeatin= g that
> > > process.
> > you don't want to send time learning ? i don't get it.
> > anyway, it's sure that if you want something, praying or asking i= s not
> enough.
> >
> > > > Or contribute.
> > > I can't, for the reasons that I attempted to explain in my l= ast
posting.
> > > READ IT.
> > i didn't understand much ...
> > you don't contribute because you find it's crap ?
> >
> > > > Or shut up.
> > > Pleas understand that I am running Windows 3.11 on an Athalo= n
processor.
> > geez. it works ? cool :-)
> >
> > > The PC is far too fucked for me to write my own OS. (I have = discovered
> > > this through great labor). But I *can* write an OS for F-cpu= (I hope).
> > cool. but you understand that, before writing the OS, you have to= get
> > a sort of loader or BIOS and HW drivers, and that they can't work= before
> > the motherboard/platform is defined, and that won't happen before= the
> > first F-CPU is released.
> >
> > 2 solutions :
> > - you're very patient. cool, then wait for an hypothetical f-cpu = to
> appear.
> > - you're impatient. either you drop or you contribute to the f-cp= u, and
> > you have the satisfaction that it is sped up.
> >
> > > I am hurting.
> > >
> > >  In a year or so I won't be able to get anything done o= n the net at
> > > all... I will be profoundly fucked. "Shutting up" = is not a very good
> > > option for me, now is it?
> > it's your choice. it's up to you.
> >
> > > > > I therefore make the following demands:
> > > > Demands?  F*ck off.  You have no right to dem= and *anything*.
> > > Maybe not. But the fact that you can't take an ounce of crit= icism with
> > > regards to this project is equally un-cool.
> > equal to what ?
> >
> > > I have been observing this project practicaly from day one.<= BR> > > > I have seen many things not happen. ;)
> > And do you feel comforted for that ?
> > did you finally understand that the best way to see things happen=
> > is to participate ?
> >
> > > This posting was my attempt to encapsulate all the observati= ons I made
> > > into a single simple workable agenda for making things happe= n. If you
> > > can't take it then go work for a company, you have nothing v= aluble to
> > > contribute to an open-source project if you canot accept
contributions.
> > what did you contribute ?
> >
> > did you understand that if you made propositions, you were automa= tically
> > designated to apply them ? ;-) </k>
> >
> > of course your precedent list was fine. my wish list to Santa Cla= us was
> > ever finer, but he didn't accept it. Now what to do ?
> > you can start a sub-project that will care about the organisation= of the
> F-CPU.
> > you want it ? do it. then you won't lament as much, and you'll ha= ve the
> > satisfaction of shouting at the people who do nothing :-)
> >
> > > > [...]
> > > > > Really, This project serves me only when it yields= something that
is
> > > > > useful. Failing that it can go to hell...
> > > > Don't ask what this project can do for you, ask what YO= U can do for
> the
> > > > project. (misquoting John F. Kennedy, IIRC)
> > > Read my fucking posting before making brainless comments lik= e this. It
> > > really shows me that you can't think one wit beyond your VHD= L (or
> > > whatever) compiler to see that other people can hardly under= stand what
> > > it is you are doing.
> > if you don't like it, you have the possibility to make one yourse= lf
> > or take a pre-designed one off the Net. The f-cpu design is not t= ied
> > to his implementation.
> >
> > > THEN you will realize that this posting WAS a contribution.<= BR> > > i fail to see how it contributed, except to show that you are sti= ll
> > alive (which is of course a good news).
> >
> > > It contributed the observation that people such as myself > > > are essentially left-out of the project *and* it proposes a = concise
and
> > > understandable method for remedying the situation. If you wo= uld like
to
> > > give me some permissions over at the sourceforge project the= n I will
> > > apply suggestions and my training in project managment towar= ds
achieving
> > > actual results.
> > Mathias is in charge of the sourforge stuff. he left. maybe you c= an
still
> > reach him with a polite email but it would be faster to make your= own
> > site (and share the access rights with someone else you choose, j= ust
> > in case you leave the project).
> > You are free to contribute and i do whatever i can to help the > contributors.
> >
> > > I am sorry that linux users tend to be so goddamned dense th= at they
> > > can't see or accept a simple and logical suggestion even whe= n it is
> > > explained to them!  No wonder their operating system is= as terrible as
> > > it is...
> > what's wrong with my w95 ? </silly>
> >
> > anyway i still don't see the point of the OS.
> >
> > what we don't accept anyway is a "demand" with nothing = in return.
> > the menace that you will leave is not a satisfaction, it's a sign=
> > that you don't care.
> >
> > Now if you want to participate more actively, by taking something= that
> > you care in charge, nobody will refuse (i think, but it's a free<= BR> list...)
> >
> > > > > I will see what happens over the next two months a= nd then go bug
the
> > > > > opencore people some more, and perhaps work up a p= roject over
there.
> > > > Fine.  Better go NOW and start bugging somebody el= se.
> > > Hey! Wanna make a CPU?  I not only can but I will make = it happen. This
> > > is what needs to be done.
> > and it will be done. one day.
> >
> > > > This attitude makes me sick...
> > > So does yours.
> > at least, he has the satisfaction of having contributed in a crit= ical
> > part of the project ;-) of course it's not an excuse for anything= ,
> > but it adds some weight...
> >
> > > I must appologise, I shouldn't have jumped as hard as I did = but I do
> > > really feel a lot of frustration with this...
> > we are all frustrated. maybe because of the "real" turn= of the
millenium.
> > we better speak openly about it, rather than just throwing everyt= hing
> away.
> > but being polite and an 1/4 ounce of respect can do wonders... > >
> > ok now i have to sleep. 2 hours left. i'll be stoned at work, tom= orrow.
> > maybe i care too much for that project ?
> >
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 19
> >    Date: Mon, 08 Jan 2001 05:14:26 +0100
> >    From: Yann Guidon <whygee@f-cpu.org>
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> > Yeah !!!
> > OH YES !!!
> > at last/least, some lurkers are speaking !!!!
> > but the results can be curious, such as :
> >
> > Vanderhoeven Steve wrote:
> > > > If you connect more than 2 CPU on the same bus, they co= mpete for the
> ressource
> > > > and the bottleneck gets even narrow.
> > > atm?
> > hmm do you mean "At The Moment" or "ATM network&qu= ot; ?...
> >
> > > steve
> >
> >
> > Marco Al wrote:
> > > From: "Nicolas Boulay" <nicolas.boulay@ifrance.= com>
> > > > You always forget one big thing. Here we speak about pr= ivate memory
> and
> > > > communication network to speed up memory interface. So = in the intel
> > > > architecture, 4 is a maximum because all the 4 cpu read= the memory
> > > > thought the same shared bus. In our system, only messag= e go thought
> the
> > > > network. In the best case, only I/O instruction go thou= ght the
network
> > > > and very few message from the processes.
> > >
> > > You seem to presuppose that it wont have a single memory spa= ce with
> hardware
> > > maintained coherency... I dont mind, I like transputers. But= a lot of
> users of
> > > parallel systems disagree.
> > >
> >
> > at least we must leave the end user free of some critical choices= .
> >
> > > > > Clearly, this B=3DL/N is a thing that i try to avo= id for other
things
> as well,
> > > > > and it's my "hammer" argument when i try= to promote point to point
> links.
> > > > > We spare the (distributed) control logic (all the = nasty deadlock
> stuffs etc)
> > >
> > > Thats one way of looking at it, the other way is that its a = given that
L
> has to
> > > be B*N' and that for N>N' you need extra hierarchies.
> >
> > often, "higher" hierarchies have a lower bandwidth, thi= s makes the
> compilation
> > still more difficult (the mapping of the algorithm to the archite= cture
is
> > more complex if you have more levels). That's why the T3D is so s= educing
> :-))
> >
> > > And you wont get away from hierarchies, a single chip can on= ly connect
> to so
> > > many processors and have so much backplane capacity. The con= trol will
> always be
> > > distributed at a certain point.
> > at least we can try to avoid hierarchies as long as we can.
> > An homogeneous machine is always easier to use than a heterogeneo= us one.
> >
> > > > > Now, another stuff. Nico usually wants a ring. It'= s "simple to
> route",
> > > > > it's fun and doesn't need much "efforts"= . But there is still the
> same
> > > > > problem as before : the more CPU, the less bandwid= th when one CPU
> wants
> > > > > to talk to another. 1/N (or 2 pins / N CPU if you = want the "real
> efficiency").
> > > > > The solution is rather easy : you have to expand t= hat to the other
2
> dimensions,
> > > > > hence the "CRAY T3D" and the extension, = T3E. Routing is still the
> same but the
> > > > > address is split into 3 fields that are interprete= d as an
> independent ring address.
> > >
> > > Exactly.
> > >
> > > My opinion also kind of depends on where the motherboard chi= pset
> functionality
> > > would be present and how many pins that would need.
> >
> > examples ?
> >
> > > I think making a bridge which can have a point-to-point/shar= ed/ring
> connection
> > > to the processors which itself plugs into a socket-7 board (= or perhaps
> even a
> > > PCI slot) is a good solution :) (bios should be local though= ,
obviously)
> > then, i'll leave you the burden of writing all the support code.<= BR> > > I don't want to deal with Socket-7 anymore, but i'll do it if you= make
> > all the nasty stuffs at my place :-P
> >
> > > Getting a processor made, no matter how many frills you remo= ve is a
huge
> task...
> > we see this :-) but we're a few step further than 2 years ago....=
> >
> > > I think designing a motherboard chipset on top of that is an=
unnecessary
> burden.
> > if some of you can cope with a EV-4 slot, it will be ok for me...=
> >
> > > You can always later replace the bridge with a true motherbo= ard
chipset.
> > it can also be left up to the end user...
> >
> > but yes : let's concentrate on the CPU design :-)
> >
> > > Marco
> >
> > jeff@llandre.freeserve.co.uk wrote:
> > >
> > > Regarding this rather strange multi cpu argument:
> > <snip>
> > > All the multi cpu stuff is interesting but pointless. It
> > > doesnt change the core. Why not get back to that. We
> > > shouldnt waste whygee or michaels time, when they are
> > > doing so well with the vhdl.
> > if i wasn't at work, i could maybe do a bit better,
> > so anybody can challenge my skills ;-)
> > all i can do today is : to try to keep stuffs put together.
> > except for the latest manual patches, i didn't do
> > anything groundbreaking these last 3 months, which makes
> > me feel dumb and uncomfortable. work sucks for that
> > matter, but it pays so good that i feel almost guilty :-P
> >
> > call for participation :
> > - whoever wants to participate with VHDL, manual, desing...
> > - whoever wants an account at seul.org
> > - whoever asks for the use of Cadence tools
> >
> > please voice up on the list.
> >
> > > like someone said, shit happens,
> > hmm sure. we're so used to it that we didn't care :-)
> >
> > > forget 17c3,
> > no, we should remember the lesson.
> > But things weren't easy at 16C3 either.
> > Compared to last year, if we balance with the
> > number of people, 17C3 seems to work marvelously !
> > it is just the fact that more people were present
> > and the work is not the same as on the Net.
> >
> > > success is the sweetest form of revenge.
> > yup.
> > > Once core is around, you multi cpu dudes can work on your > > > own multiprocessors.
> > i propose that they don't stop, but try to organise their
> > own stuff. Of course we collaborate, but as pointed out on anothe= r
> > precedent mail, the goals were completely different.
> > We will spare a lot of troubles and useless discussion,
> > and we will restart to work, if the people make their own group.<= BR> > > yes, this sounds like a "split", but it's better than a=
> > complete give-up. They started so well that it would
> > be sad if they stopped straight now...
> >
> > > Jeff Davies
> >
> >
> >
> > Marco Al wrote:
> > > From: <jeff@llandre.freeserve.co.uk>
> > >
> > > > smt as used by intel etc seems to share the whole of > > > > system ram between all cpus which is dumb.
> > > > Imagine 2 cpus, 3 sdrams. each cpu has its own sdram, > > > > but they also share the third sdram for comms.
> > >
> > > IMO thats combining the bad aspects of NUMA and message pass= ing
combined
> in a
> > > single framework...
> >
> > i'll comment with a ":-D"
> >
> > > If you want to make a processor which can scale decently in<= BR> > multiprocessor
> > > setups you have to know which scheme you will be using at le= ast in
time
> for the
> > > design of the MMU.
> >
> > if you have an enhancement to propose to the TLB or the protected= memory
> system,
> > i'm listening :-)
> >
> > > Marco
> >
> > Michael Riepe wrote:
> > > On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wro= te:
> > > [...]
> > > > You always forget one big thing. Here we speak about pr= ivate memory
> and
> > > > communication network to speed up memory interface. So = in the intel
> > > > architecture, 4 is a maximum because all the 4 cpu read= the memory
> > > > thought the same shared bus. In our system, only messag= e go thought
> the
> > > > network. In the best case, only I/O instruction go thou= ght the
network
> > > > and very few message from the processes.
> > >
> > > It depends.  If you use ccNUMA or COMA, there will be a= lot of
> additional
> > > traffic to keep the caches up-to-date.  And if you're r= unning certain
> > > parallelized tasks with high communication overhead, even Gb= ps
ethernet
> > > becomes too slow.
> >
> > to me, Gb serial link is too slow and has too much latency anyway= ...
> >
> > > > > buses are known, used and they work, but some peop= le here want a
> "multimaster"
> > > > > bus. This means that the bandwidth is drawn by sev= eral points and
> the bus
> > > > > is the bottleneck. it's a B=3DL/N scheme (B is Ban= dwidth per CPU,
> equal to
> > > > > the available bandwidth provided by the bus and di= vided by N CPU).
> > > > >
> > > > > that's what i try to avoid.
> > >
> > > It's actually worse than B=3DL/N.  Don't forget the ove= rhead for bus
> > > arbitration and transfer direction turn-arounds.  I wou= ldn't be
> surprised
> > > at all if bandwidth drops below B=3DL/N/2.  If you want= to come closer
> > > to B=3DL/N, you need to do large block transfers (unreasonab= le except
for
> > > mass storage access), and then you'll get problems with late= ncies
(other
> > > devices have to wait until the transfer is over and a new bu= s master
> > > can be elected).  Another problem is that arbitration a= nd turn-around
> > > times rise dramatically when the bus becomes longer (signal = delay,
> > > bad impedance matching when tri-state drivers are used, and = so on).
> >
> > that's why i try to keep the f-bus (the one that connects the F-c= hips
and
> > the I/Os together) as simple as possible.
> >
> > > > There are always possible traffic Jam. How do you manag= e when 2
nodes
> > > > try to speak to the same nod ? You have to manage somet= hing to avoid
> > > > losing informations.
> > >
> > > They will have to share the available bandwidth.  The G= -Chip will have
> > > to queue the second message while it's sending the first one= .
> >
> > well, the messages that i envision are packets with 256-bits of d= ata
> > and an address with some additional info (byte ordering of the tr= ansfer,
> > if we start from the end or the middle of the line etc...)
> >
> > it's also a transactional bus, with around 16 transaction, so the=
> > FIFO is 16*(256+64) bits. when the FIFO overflows, the transactio= n IDs
> > are not allowed and the bus stalls. of course, you can continue t= o
> interleave
> > other packets (not addressed to the slow port) so you can still b= enefit
> > from the remaining bandwidth if you have to transfer a lot of dat= a
> > simultaneously with a 3rd port.
> >
> > mmmh, the g-chip is getting interesting :-)
> >
> > >  This could be avoided by putting 4 F-Bus interfaces in= to the CPU
itself
> > no, the "convergence" problem would remain anyway, but = at a larger
> (system) scale...
> > OTOH, the single-F-bus bottleneck would disappear but we'll need = :
> > 250 (SDRAM) + 4 * 100 (F-bus) pins, or roughly 700 pins for a f-c= pu.
> > i would like one, it looks sexy, but it might be rather... expens= ive.
> > and the PCB routing might be ... tricky.... oh yes, it's sexy ;-)=
> >
> > > (did anybody say "transputer"?), which makes the G= -chip obsolete
> > > except for peripheral I/O and message routing/switching, or = by using a
> > > faster (4x) link between F-CPU and G-chip.
> > i think it's pointless. Every f-bus interface can be "rated&= quot; at a
certain
> > maximum speed. If you have a 200MHz f-cpu connected to a 150MHz g= -chip,
> you'll
> > run at 150 MHz everywhere (f-cpu's f-bus interface and I/Os that = can do
> more
> > than 150MHz). OTOH, if the g-chip is connected to one 100MHz (or = even 20
> > or anything) device, it won't slow down the whole system (unless = this
link
> > becomes the bottleneck because of its critical use by the SW, lik= e ...
> swapping
> > etc...)
> >
> > > > > Now, another stuff. Nico usually wants a ring. It'= s "simple to
> route",
> > > > > it's fun and doesn't need much "efforts"= . But there is still the
> same
> > > > > problem as before : the more CPU, the less bandwid= th when one CPU
> wants
> > > > > to talk to another. 1/N (or 2 pins / N CPU if you = want the "real
> efficiency").
> > > > > The solution is rather easy : you have to expand t= hat to the other
2
> dimensions,
> > > > > hence the "CRAY T3D" and the extension, = T3E. Routing is still the
> same but the
> > > > > address is split into 3 fields that are interprete= d as an
> independent ring address.
> > >
> > > A ring is actually much better than a bus because it is a unidirectional
> > > device (no change of transfer direction, no tri-state buffer= s
necessary,
> > > faster signalling) and arbitration is both simpler and faste= r (e.g.
> token
> > > ring).  The members of the ring still share the availab= le bandwidth,
> > > but you come closer to B=3DL/N.  Per-CPU bandwidth is s= till limited,
> though.
> >
> > in a real system or computer, the ring is often either folded (wi= th
pairs
> of
> > nodes) or dual-way. So that's why it goes from L/N/2 to L/N : the= bus
> > is physically 2x wider if you "cut" it somewhere.
> >
> > > > > here, you don't have 1 ring but x*y*z rings. It me= ans that there
is
> > > > > no bandwidth problem at all, because each CPU comm= unicates with
its
> 6 neighbours.
> > > > > It works very well, it can be tweaked to become &q= uot;fault tolerant"
> (through dynamic
> > > > > node addresses) and scales perfectly (almost linea= rly with the CPU
> number).
> > > > >
> > > > So !
> > > [...]
> > >
> > > scales "perfectly" <EM>as long as the number= of members per ring is
> limited</EM>.
> > > Sorry for shouting ;)
> >
> > :-D
> >
> > everybody has his/her own criteria...
> >
> > > For highest-speed n-to-n communication, use direct connectio= ns.
> > if you can rewrap the wires in less than a millisecond, it's ok f= or me
;-P
> >
> > > Since this doesn't scale at all, you need to find a compromi= se when
> > > the number of CPUs increases -- switches or crossbars, trees= or rings.
> > > In any case, the solution depends on the work the system has= to do.
> > > With the drafted G-chip with 4 links, we could build
> > >
> > >         - a 4-CPU di= rectly-connected system
> > >         - a single r= ing (double ring requires 5 links, 1 for CPU)
> > >         - a binary o= r trinary tree (USB-style)
> > >         - a flat hex= agonal `beehive' structure
> > >         - a cube
> > >         - ...
> > >
> > > This is a pretty long list of options, isn't it?  Let t= he implementor
> (or
> > > system integrator) choose from this list; we don't have to c= are.  We
> just
> > > need to make sure that the G-chip is versatile enough to sup= port at
> least
> > > two or three of the most common topologies, and probably mix= ed
> topologies
> > > (like a tree or ring of directly-connected clusters, for exa= mple).
> > > Preferably with auto-sensing capabilities =E0 la USB, i.e. t= he structure
> > > is determined at run (or boot) time.
> >
> > yup. Let's stick to that... Lego brick ? :-)
> >
> > > --
> > >  Michael "Tired" Riepe <Michael.Riepe@stud= .uni-hannover.de>
> > >  "All I wanna do is have a little fun before I die= "
> >
> >
> >
> >
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 20
> >    Date: Mon, 08 Jan 2001 09:05:53 +0100 (CET)
> >    From: "maurizio zoboli" <maurizio.= zoboli@unimo.it>
> > Subject: REMOVE
> >
> > On Sun, 7 Jan 2001 16:17:04 -0000, Didi wrote:
> >
> > >
> > >----- Original Message -----
> > >From: "maurizio zoboli" <maurizio.zoboli@unimo.i= t>
> > >To: <f-cpu@egroups.com>
> > >Sent: Sunday, January 07, 2001 10:18 AM
> > >Subject: [f-cpu] REMOVE
> > >
> > >
> > >> On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@yahoo.= com wrote:
> > >>
> > >> >Expand your business with
> > >> >    Email Marketing!
> > >> >
> > >> >Market your product or service
> > >> >     to MILLIONS!
> > >> >
> > >> >Don't waste another minute...
> > >> >
> > >> >Click Reply with your name,
> > >> >telephone number and the
> > >> >product or service you wish
> > >> >to market. We will be in
> > >> >touch with you shortly!
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >Removal Instructions
> > >> >****************************
> > >> >To be removed from this list
> > >> >please reply with "REMOVE"
> > >> >in the subject.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >Expand your business with
> > >> >    Email Marketing!
> > >> >
> > >> >Market your product or service
> > >> >     to MILLIONS!
> > >> >
> > >> >Don't waste another minute...
> > >> >
> > >> >Click Reply with your name,
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >> Prof. Maurizio Zoboli
> > >> Dipartimento di Scienze dell'Ingegneria
> > >> Universita' di Modena e Reggio Emilia
> > >> via Vignolese 905
> > >> I-41100 Modena, Italy
> > >> Tel.: +39 059 2056163
> > >> Fax: +39 059 2056129
> > >> e-mail: maurizio.zoboli@unimo.it
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> >
> > Prof. Maurizio Zoboli
> > Dipartimento di Scienze dell'Ingegneria
> > Universita' di Modena e Reggio Emilia
> > via Vignolese 905
> > I-41100 Modena, Italy
> > Tel.: +39 059 2056163
> > Fax: +39 059 2056129
> > e-mail: maurizio.zoboli@unimo.it
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 21
> >    Date: Mon, 08 Jan 2001 09:08:30 +0100 (CET)
> >    From: "maurizio zoboli" <maurizio.= zoboli@unimo.it>
> > Subject: REMOVE
> >
> > On Sun, 7 Jan 2001 16:28:07 -0000, Didi wrote:
> >
> > >
> > >----- Original Message -----
> > >From: "Didi" <flei@wanadoo.fr>
> > >To: <f-cpu@egroups.com>
> > >Sent: Sunday, January 07, 2001 4:17 PM
> > >Subject: [f-cpu] REMOVE
> > >
> > >
> > >>
> > >> ----- Original Message -----
> > >> From: "maurizio zoboli" <maurizio.zoboli@un= imo.it>
> > >> To: <f-cpu@egroups.com>
> > >> Sent: Sunday, January 07, 2001 10:18 AM
> > >> Subject: [f-cpu] REMOVE
> > >>
> > >>
> > >> > On Sat, 06 Jan 2001 22:31:11 -0500, bethweinstein@y= ahoo.com wrote:
> > >> >
> > >> > >Expand your business with
> > >> > >    Email Marketing!
> > >> > >
> > >> > >Market your product or service
> > >> > >     to MILLIONS!
> > >> > >
> > >> > >Don't waste another minute...
> > >> > >
> > >> > >Click Reply with your name,
> > >> > >telephone number and the
> > >> > >product or service you wish
> > >> > >to market. We will be in
> > >> > >touch with you shortly!
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >Removal Instructions
> > >> > >****************************
> > >> > >To be removed from this list
> > >> > >please reply with "REMOVE"
> > >> > >in the subject.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >Expand your business with
> > >> > >    Email Marketing!
> > >> > >
> > >> > >Market your product or service
> > >> > >     to MILLIONS!
> > >> > >
> > >> > >Don't waste another minute...
> > >> > >
> > >> > >Click Reply with your name,
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > Prof. Maurizio Zoboli
> > >> > Dipartimento di Scienze dell'Ingegneria
> > >> > Universita' di Modena e Reggio Emilia
> > >> > via Vignolese 905
> > >> > I-41100 Modena, Italy
> > >> > Tel.: +39 059 2056163
> > >> > Fax: +39 059 2056129
> > >> > e-mail: maurizio.zoboli@unimo.it
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> >
> > Prof. Maurizio Zoboli
> > Dipartimento di Scienze dell'Ingegneria
> > Universita' di Modena e Reggio Emilia
> > via Vignolese 905
> > I-41100 Modena, Italy
> > Tel.: +39 059 2056163
> > Fax: +39 059 2056129
> > e-mail: maurizio.zoboli@unimo.it
> >
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> > Message: 22
> >    Date: Tue, 08 Jan 2001 12:14:31 +0100
> >    From: Vanderhoeven Steve <vanderho@essi.fr&g= t;
> > Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?<= BR> > >
> >
> > > Vanderhoeven Steve wrote:
> > > > > If you connect more than 2 CPU on the same bus, th= ey compete for
the
> ressource
> > > > > and the bottleneck gets even narrow.
> > > > atm?
> > > hmm do you mean "At The Moment" or "ATM netwo= rk" ?...
> >
> > I was just sugesting you to look at the idea of ATM networks. It = has
> service like reserving a part of the bandwidth for communication betwe= en
two
> points.
> >
> > Steve
> >
> >
> > _________________________________________________________________= _______
> > _________________________________________________________________= _______
> >
> >
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 2
>    Date: Mon, 8 Jan 2001 13:22:06 EST
>    From: DuaneMHunt170976@aol.com
> Subject: Re: This project really sucks.
>
> NOTE
>
> IF YOU DONT LIKE IT YOU CAN GO!!
>
> IF YOUR JUST HERE TO SPAM US ALL
> THEN THAT IS SAD LIFE YOU HAVE !!
>
> READ AND JOIN IN THE CHAT BY EMAIL
> OR JUST READ AND LEARN
> BUT BUT DONT MON ABOUT IT
>
>
> [This message contained attachments]
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 3
>    Date: Mon, 8 Jan 2001 14:56:32 EST
>    From: DuaneMHunt170976@aol.com
> Subject: Hay
>
> Hay i didnt send any ADVERT on that LAST EMAIL i sent what gives
>
>
> [This message contained attachments]
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 4
>    Date: Mon, 08 Jan 2001 15:03:09 -0600
>    From: james729@japan.com
> Subject: A DishNetwork sys. Free
>
>   FREE SATELLITE T.V. SYSTEM
>
> Watch over 500 channels of Digital Broadcast quality television on
> your own FREE satellite television system. These new Digital satellite=
> systems use the new 20 inch satellite dish antenna.
>
> For a limited time we'll give you this top of the line
> Digital Satellite System for FREE!
> We'll even include Free installation and 3 FREE months of all the movi= e
> channels!
>
> This is the New DishNetwork 3922 digital satellite system. It has
> interactive T.V capabilities , on screen program guide, 2 dual LNB's,<= BR> stereo
> CD sound and infrared remote. Normal cost for all these items is over = $500
> but we're giving it away for FREE!
>
> All you have to do is call us to arrange delivery and order the channe= ls
you
> want to receive. Satellite television offers over 500 channels of all<= BR> > digital broadcast video quality, movies, sports, specials, network , cables
> channels and more all with CD audio stereo sound. You may even get loc= al
> channels now. Don't miss this offer, it's only available while supplie= s
last.
>
>
> For your Free Satellite System call  877-699-8548  24 hours = a day.
>
>
> Authorized DishNetwork dealer
>
> Under Bill s.1618 TITLE III passed by the 105th US Congress, this lett= er
cannot be considered spam as long as the sender includes contact informatio= n
and removal instructions.
> This is a one-time e-mail transmission. No request for removal is
necessary
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 5
>    Date: Mon, 08 Jan 2001 23:26:25 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Re: 17. Chaos Communication Congress - Wie war ehr?
>
>
>
> Michael Riepe a =E9crit :
> >
> > On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrote: > > [...]
> > > You always forget one big thing. Here we speak about private= memory
and
> > > communication network to speed up memory interface. So in th= e intel
> > > architecture, 4 is a maximum because all the 4 cpu read the = memory
> > > thought the same shared bus. In our system, only message go = thought
the
> > > network. In the best case, only I/O instruction go thought t= he network
> > > and very few message from the processes.
> >
> > It depends.  If you use ccNUMA or COMA, there will be a lot = of
additional
> > traffic to keep the caches up-to-date.  And if you're runnin= g certain
> > parallelized tasks with high communication overhead, even Gbps et= hernet
> > becomes too slow.
> >
>
>
> That's why i said "in the best case". But remember that a 64= bit 133 Mhz
> run at 1Go/s so 8 gigabits links run at the same speed. I would like t= o
> create something to optimise the transfert (my extended MMU).
>
> > > > I am trying to find the "least common denominator&= quot; for a F-CPU
system
> > > > that can range from 1 CPU to any arbitrary number of CP= Us (just like
> > > > the register width : not bound to anything). let's take= a few cases,
> > > > with 1 CPU, 4 CPU, 16 CPU and 64 CPU. the "system&= quot; should also scale
> > > > to much more CPUs : the widest systems today (see the m= onters at the
LANL)
> > > > can scale to more than 10K CPU, so let's round up to 65= 536.
> > > >
> > > > now let's compare the alternatives...
> > > >
> > > > Bus : works for 1 CPU, 2 CPU, starts to drop at 4 CPU a= nd it's
disastrous
> > > > with more CPU.
> > > >
> > > > buses are known, used and they work, but some people he= re want a
"multimaster"
> > > > bus. This means that the bandwidth is drawn by several = points and
the bus
> > > > is the bottleneck. it's a B=3DL/N scheme (B is Bandwidt= h per CPU,
equal to
> > > > the available bandwidth provided by the bus and divided= by N CPU).
> > > >
> > > > that's what i try to avoid.
> >
> > It's actually worse than B=3DL/N.  Don't forget the overhead= for bus
> > arbitration and transfer direction turn-arounds.  I wouldn't= be
surprised
> > at all if bandwidth drops below B=3DL/N/2.  If you want to c= ome closer
> > to B=3DL/N, you need to do large block transfers (unreasonable ex= cept for
> > mass storage access), and then you'll get problems with latencies= (other
>
> Not really. Don't only think like SRAM READ, but you can make burst > transfert like for COMA arch.
>
> > devices have to wait until the transfer is over and a new bus mas= ter
> > can be elected).  Another problem is that arbitration and tu= rn-around
> > times rise dramatically when the bus becomes longer (signal delay= ,
> > bad impedance matching when tri-state drivers are used, and so on= ).
> >
>
> So, hourra for the ring ?
>
> > > > Clearly, this B=3DL/N is a thing that i try to avoid fo= r other things
as well,
> > > > and it's my "hammer" argument when i try to p= romote point to point
links.
> > > > We spare the (distributed) control logic (all the nasty= deadlock
stuffs etc)
> > >
> > > There are always possible traffic Jam. How do you manage whe= n 2 nodes
> > > try to speak to the same nod ? You have to manage something = to avoid
> > > losing informations.
> >
> > They will have to share the available bandwidth.  The G-Chip= will have
> > to queue the second message while it's sending the first one.&nbs= p; This
> > could be avoided by putting 4 F-Bus interfaces into the CPU itsel= f
> > (did anybody say "transputer"?), which makes the G-chip= obsolete
> > except for peripheral I/O and message routing/switching, or by us= ing a
> > faster (4x) link between F-CPU and G-chip.
> >
>
> You can't have the same bandwith between memory and the fcpu and betwe= en
> the fcpu and the network. Memory will be always quicker. I don't like = to
> have 2 seperate chips because you will have a link between them. This<= BR> > "waste" could be used instead for simple serial link. Using = common
> serial link is to replace wire by speed. So the "true" bandw= ith between
> the memory and the network could be maximum in a one chip system. If y= ou
> have 4 link by g-chip, 3 links speak to the same node but you have onl= y
> the 1/3 to communicate to the node memories, but if you have one chip,=
> it's easy to have 3 times the bandwith of the f-bus to the memory.
>
> > > > and it's very simple to implement. the PCB is simpler, = too.
> > > >
> > > > If you connect more than 2 CPU on the same bus, they co= mpete for the
ressource
> > > > and the bottleneck gets even narrow.
> > > >
> > >
> > > Yes, but less drastically as intel SMP.
> > >
> > > > On the pin count vs bandwidth argument, it's similar. O= f course, we
can find
> > > > a lot of counter-examples and special cases, but the ex= ample of the
broadcast
> > > > is not the best one. Most of the requests are from one = node to a
single other
> > >
> > > In fact, not. It depend how much process communicate between= them. And
> > > sometimes the only [simple] way to find a "moving"= ressources is to
send
> > > a braodcast.
> >
> > Yep.  Very common when (simple) COMA is used, IIRC.
> >
> In NORMA arch, too, no ?
>
> > > > and here, the efficiency of a bus drops dramatically ! = for a N-CPU
system,
> > > > the efficiency is of 2 used bus interfaces for N bus in= terfaces (you
can
> > > > replace "bus interface" with "pin")= , 2/N is similar to the 1/N
scheme
> > > > (if we speak about the "big O" or complexity)= . This means that :
> > > > the more CPU, the least efficient ! you'll see that the= best way to
avoid
> > > > this is by having as few CPU by link as possible, and t= he minimum is
2.
> > > > that's "point to point"...
> > > >
> > > > Now, another stuff. Nico usually wants a ring. It's &qu= ot;simple to
route",
> > > > it's fun and doesn't need much "efforts". But= there is still the
same
> > > > problem as before : the more CPU, the less bandwidth wh= en one CPU
wants
> > > > to talk to another. 1/N (or 2 pins / N CPU if you want = the "real
efficiency").
> > > > The solution is rather easy : you have to expand that t= o the other 2
dimensions,
> > > > hence the "CRAY T3D" and the extension, T3E. = Routing is still the
same but the
> > > > address is split into 3 fields that are interpreted as = an
independent ring address.
> >
> > A ring is actually much better than a bus because it is a unidire= ctional
> > device (no change of transfer direction, no tri-state buffers nec= essary,
> > faster signalling) and arbitration is both simpler and faster (e.= g.
token
> > ring).  The members of the ring still share the available ba= ndwidth,
> > but you come closer to B=3DL/N.  Per-CPU bandwidth is still = limited,
though.
> >
>
> The idea is to have a much higher bandwith for the link. In some year<= BR> > will come the 10 000base T, so maybe 10 Go/s will be possible ;p.
>
> > > In the flight back to France, we have spoken about ring of r= ing.(and
> > > called the architecture the lord of the ring ;p). A ring is = composed
> > > around 8 to 16 card (cpu+ram or IO). A card could be used to=
communicate
> > > with other ring. Maybe it's possible to grow in hierachy wit= hout to
much
> > > trouble.
> > >
> > > > here, you don't have 1 ring but x*y*z rings. It means t= hat there is
> > > > no bandwidth problem at all, because each CPU communica= tes with its
6 neighbours.
> > > > It works very well, it can be tweaked to become "f= ault tolerant"
(through dynamic
> > > > node addresses) and scales perfectly (almost linearly w= ith the CPU
number).
> > > >
> > > So !
> > [...]
> >
> > scales "perfectly" <EM>as long as the number of m= embers per ring is
limited</EM>.
> > Sorry for shouting ;)
> >
>
> 8 or 16, is enough, no ?
>
> > For highest-speed n-to-n communication, use direct connections. > > Since this doesn't scale at all, you need to find a compromise wh= en
> > the number of CPUs increases -- switches or crossbars, trees or r= ings.
> > In any case, the solution depends on the work the system has to d= o.
> > With the drafted G-chip with 4 links, we could build
> >
> >         - a 4-CPU directl= y-connected system
> >         - a single ring (= double ring requires 5 links, 1 for CPU)
> >         - a binary or tri= nary tree (USB-style)
> >         - a flat hexagona= l `beehive' structure
> >         - a cube
> >         - ...
> >
> > This is a pretty long list of options, isn't it?  Let the im= plementor
(or
> > system integrator) choose from this list; we don't have to care.&= nbsp; We
just
> > need to make sure that the G-chip is versatile enough to support = at
least
> > two or three of the most common topologies, and probably mixed topologies
> > (like a tree or ring of directly-connected clusters, for example)= .
> > Preferably with auto-sensing capabilities =E0 la USB, i.e. the st= ructure
> > is determined at run (or boot) time.
> >
>
> It isn't so simple. Topology is importante when you choose your
> algorithme for shared memory. You can choose to make it by SW (like > SUN). Or by HW, so the network must be known. If you use mostly
> broadcast, a ring is fine (in a cube you lost a lot of bandwith), a > point to point is quick, but you have to make some routing and you hav= e
> to know were is a ressource !
>
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 6
>    Date: Mon, 8 Jan 2001 15:47:42 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: This project really sucks.
>
> On Sun, Jan 07, 2001 at 08:32:11PM -0500, Alan Grimes wrote:
> [...]
> > Pleas understand that I am running Windows 3.11 on an Athalon pro= cessor.
>
> I only have a slow Pentium.  So what?
>
> > The PC is far too fucked for me to write my own OS. (I have disco= vered
> > this through great labor). But I *can* write an OS for F-cpu (I h= ope).
> >
> > I am hurting.
>
> Me too.
>
> [...]
> > > Demands?  F*ck off.  You have no right to demand *= anything*.
> >
> > Maybe not. But the fact that you can't take an ounce of criticism= with
> > regards to this project is equally un-cool. I have been observing= this
> > project practicaly from day one. I have seen many things not happ= en. ;)
>
> Criticism !=3D destructivity.  Saying that "This project suc= ks" is not
> criticism, it's the Felix-von-Leitner way.
>
> I've browsed the mailing list archive before I joined.  I've seen= many
> things not happen, too.  And I know that you have been there all = the time,
> and you didn't make things happen either.  I've seen people join = and quit
> (sometimes in anger) because things didn't happen or they were unable = to
> find a compromise that satisfied everybody.  Now, things actually= *do*
> happen -- the ISA is kind of stable, and we have some pieces of code > already -- but you still aren't satisfied.
>
> > This posting was my attempt to encapsulate all the observations I= made
> > into a single simple workable agenda for making things happen. If= you
> > can't take it then go work for a company, you have nothing valubl= e to
> > contribute to an open-source project if you canot accept contribu= tions.
>
> Demands !=3D contributions.
>
> "Making things happen" means, in the context of a free (GNU-= style)
> project, that you *do* something.  If you have your own company, = you can
> sit around and manage things, demand things, tell your employees what<= BR> > to do next and so on -- in a free project, people decide themselves. > Maybe they could get things done faster if they had a management, but<= BR> > they usually don't WANT one.  The day this project is managed lik= e a
> company (by an individual or a committee) is my last day.  Farewe= ll,
> goodbye, hasta la vista, baby.
>
> [...]
> > I am sorry that linux users tend to be so goddamned dense that th= ey
> > can't see or accept a simple and logical suggestion even when it = is
> > explained to them!  No wonder their operating system is as t= errible as
> > it is...
>
> Linux users are (and want to be) free to do what they like.
> The results may look terrible, but there *are* results, after all.
>
> [...]
> > Hey! Wanna make a CPU?  I not only can but I will make it ha= ppen. This
> > is what needs to be done.
>
> "We are Alan Grimes of Borg.  You will make a CPU for us. Re= sistance
> is futile."
>
> Well, you can try.  Come and assimilate me.  Good luck.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 7
>    Date: Tue, 9 Jan 2001 00:19:52 +0000
>    From: Jeff Davies <jeff@llandre.freeserve.co.uk&g= t;
> Subject: Re: This project really sucks.
>
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
>
> Michael, there are those of us out here who really appreciate what you= do.
> Ignore these timewasters,and carry on with the VHDL please. You are > very close now.
>
> Thanks for everything you are doing.
>
> Jeff Davies
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 8
>    Date: Tue, 9 Jan 2001 11:41:42 +0100 (MET)
>    From: whygee@club-internet.fr
> Subject: networks, bus, topologies, links.............
>
> hi,
>
> some oil on the fire...
>
> >De: Nicolas Boulay <nicolas.boulay@ifrance.com>
> >Michael Riepe a =E9crit :
> >>
> >> On Sun, Jan 07, 2001 at 01:46:24PM +0100, Nicolas Boulay wrot= e:
> >> [...]
> >That's why i said "in the best case". But remember that = a 64 bit 133 Mhz
> >run at 1Go/s so 8 gigabits links run at the same speed.
> did you forget that i showed that it had more latency ?
>
> > I would like to
> >create something to optimise the transfert (my extended MMU).
> do it and publish the draft, damnit !
> but please don't use "magic words" but real physical
> names for the units (ie : compare, register, add ... forget
> words like "manager" or "handler" that don't mean = anything)
>
>
> >> It's actually worse than B=3DL/N.  Don't forget the over= head for bus
> >> arbitration and transfer direction turn-arounds.  I woul= dn't be
surprised
> >> at all if bandwidth drops below B=3DL/N/2.  If you want = to come closer
> >> to B=3DL/N, you need to do large block transfers (unreasonabl= e except for
> >> mass storage access), and then you'll get problems with laten= cies
(other
> >
> >Not really. Don't only think like SRAM READ, but you can make burs= t
transfert like for COMA arch.
>
> burst are fine, but when you want to transfer a simple semaphore,
> it takes a lot of time for the setup (just like vector vs SIMD :
> the time to fill the vector pipeline influences the performance)
>
> >> devices have to wait until the transfer is over and a new bus= master
> >> can be elected).  Another problem is that arbitration an= d turn-around
> >> times rise dramatically when the bus becomes longer (signal d= elay,
> >> bad impedance matching when tri-state drivers are used, and s= o on).
> >>
> >So, hourra for the ring ?
>
> no, houra for unidirectional buses.
> your ring uses them, but other topologies use them too.
>
>
> >> They will have to share the available bandwidth.  The G-= Chip will have
> >> to queue the second message while it's sending the first one.=   This
> >> could be avoided by putting 4 F-Bus interfaces into the CPU i= tself
> >> (did anybody say "transputer"?), which makes the G-= chip obsolete
> >> except for peripheral I/O and message routing/switching, or b= y using a
> >> faster (4x) link between F-CPU and G-chip.
> >>
> >
> >You can't have the same bandwith between memory and the fcpu and b= etween
> >the fcpu and the network. Memory will be always quicker. I don't l= ike to
> >have 2 seperate chips because you will have a link between them. T= his
> >"waste" could be used instead for simple serial link. Us= ing common
> >serial link is to replace wire by speed. So the "true" b= andwith between
> >the memory and the network could be maximum in a one chip system. = If you
> >have 4 link by g-chip, 3 links speak to the same node but you have= only
> >the 1/3 to communicate to the node memories, but if you have one c= hip,
> >it's easy to have 3 times the bandwith of the f-bus to the memory.=
>
> Fine but you forget about pin counts. And pin counts scales
> with price too. not only chip price but PCB routing and layer number..= ..
>
> a 800-pin chip takes months to route.
>
> >> > In fact, not. It depend how much process communicate bet= ween them.
And
> >> > sometimes the only [simple] way to find a "moving&q= uot; ressources is to
send
> >> > a braodcast.
> >>
> >> Yep.  Very common when (simple) COMA is used, IIRC.
> >>
> >In NORMA arch, too, no ?
>
> but i don't care about your norma, coma, IIRC etc ...
> we should speak about the core... damnit...
>
>
> >> A ring is actually much better than a bus because it is a
unidirectional
> >> device (no change of transfer direction, no tri-state buffers=
necessary,
> >> faster signalling) and arbitration is both simpler and faster= (e.g.
token
> >> ring).  The members of the ring still share the availabl= e bandwidth,
> >> but you come closer to B=3DL/N.  Per-CPU bandwidth is st= ill limited,
though.
> >
> >The idea is to have a much higher bandwith for the link.
> so it's more expensive and consumes more power !
> in CMOS-like, if you  drive the signal 10x faster, you consume > 10x more. and your serial link is not going to use 1V signalling.
>
> > In some year
> >will come the 10 000base T, so maybe 10 Go/s will be possible ;p.<= BR> >
> no. never. do NEVER believe peak rates.
> you never burst a 10 billion bit stream .
>
>
> >> > So !
> >> [...]
> >>
> >> scales "perfectly" <EM>as long as the number = of members per ring is
limited</EM>.
> >> Sorry for shouting ;)
> >
> >8 or 16, is enough, no ?
> >
> should be. 16x16x16 =3D 4096
> if we could go to 32^3, we'd use 16 bit node addressing.
>
> >It isn't so simple. Topology is importante when you choose your > >algorithme for shared memory.
> both are in the hands of the end user.
> EOT.
>
> > You can choose to make it by SW (like
> >SUN). Or by HW, so the network must be known. If you use mostly > >broadcast, a ring is fine (in a cube you lost a lot of bandwith), = a
> >point to point is quick, but you have to make some routing and you= have
> >to know were is a ressource !
> fine. Prove me that you can't know where the ressources are.
>
> I WANT a node with 6 CPU, a HDD and 6 link controllers.
> this way, i could build a cube by assembling the nodes.
> i don't care about the SW.
>
> happy new year and bonjour chez vous.
>
> >>  Michael "Tired" Riepe <Michael.Riepe@stud.= uni-hannover.de>
> >>  "All I wanna do is have a little fun before I die&= quot;
> >nicO
> YG
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
>
eGroups Sponsor=
3D""
From Alan Grimes Tue Jan 9 22:44:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03409 for ; Wed, 10 Jan 2001 04:39:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:39:34 +0100 (MET) Received: (qmail 23926 invoked by uid 0); 9 Jan 2001 21:59:37 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx09) with SMTP; 9 Jan 2001 21:59:37 -0000 X-eGroups-Return: sentto-1101623-1900-979076886-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 09 Jan 2001 21:48:45 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 21:48:06 -0000 Received: (qmail 842 invoked from network); 9 Jan 2001 21:42:03 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 9 Jan 2001 21:42:03 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta1 with SMTP; 9 Jan 2001 21:42:02 -0000 Received: from 66-44-55-33.s287.tnt1.lnhva.md.dialup.rcn.com ([66.44.55.33] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14G6Wn-0000i0-00 for f-cpu@egroups.com; Tue, 09 Jan 2001 16:42:01 -0500 Message-ID: <3A5B8627.FEF4CB49@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 09 Jan 2001 16:44:07 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Behold and rejoice! =) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aef52008b1f349765d7d4e83d58cd574 Status: R X-Status: N Hello everybody!

I have taken my own advice from my recient posting and have applied it
by creating a new project, FreeProc at Soruceforge. As this new site
will be administered by me, and whomever provides me with a functioning
"SSH1" (whatever the hell that is) and CVS clients (with tutoring as
needed) that will work with either BeOS or Win 3.11.

I hope that all of you will subscribe to the freeproc-main mailing list
as a replacement for this unmaintained spam ridden feature poor F-CPU
list. =)

I will be bresenting a draft product roadmap to the new list for
discussion in a few days before adding it to the docmunet archive. From
there we will import and revise all the informal documentation from the
f-cpu.org site according to my insane demented ideas. ;)

I have high hopes that through skilled managment I will be able to
produce the results that the f-cpu people have long been hoping for.

I will be unsubscribing myself from this old list in a week or two...
Those other losers can send themselves UNSUBSCRIBE!!!!!/flood messages
untill they grow old... ;)

All you have to do:
1. Create an account or log into sourceforge.net
2. Join this project: https://sourceforge.net/projects/freeproc/
3. Contribute! ;)

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
From "Christian Schubert" Tue Jan 9 23:29:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03427 for ; Wed, 10 Jan 2001 04:39:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:39:39 +0100 (MET) Received: (qmail 4811 invoked by uid 0); 9 Jan 2001 22:35:14 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx18) with SMTP; 9 Jan 2001 22:35:14 -0000 X-eGroups-Return: sentto-1101623-1901-979079679-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 09 Jan 2001 22:35:10 -0000 X-Sender: cms@pnetservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 22:34:38 -0000 Received: (qmail 60479 invoked from network); 9 Jan 2001 22:29:29 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 9 Jan 2001 22:29:29 -0000 Received: from unknown (HELO moutvdom01.kundenserver.de) (195.20.224.200) by mta3 with SMTP; 9 Jan 2001 23:30:34 -0000 Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14G7Ge-0006Q2-00 for f-cpu@egroups.com; Tue, 9 Jan 2001 23:29:24 +0100 Received: from pd9019fb3.dip.t-dialin.net ([217.1.159.179] helo=apex) by mrvdom03.kundenserver.de with smtp (Exim 2.12 #2) id 14G7Ga-00031f-00 for f-cpu@egroups.com; Tue, 9 Jan 2001 23:29:22 +0100 Message-ID: <001a01c07a8b$9c8e7b00$0200a8c0@schubert> To: References: <979043014.86682@egroups.com> <004101c07a73$284aeac0$19a4fea9@silvius> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Christian Schubert" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 23:29:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5e7037bf9b2df0883b8cd7697eaae400 Status: R X-Status: N Hey, damn, are there only dumb bastards in the world out there?

Quoting the 'daily digest' back to the list is worse than SPAM (if
someone considers this list SPAM...), it's mailbombing...

but hey... what am I praying? No one hears me...

sch=F6nen Abend noch...

Christian
eGroups Sponsor=
3D""
From "Christian Schubert" Tue Jan 9 23:35:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03439 for ; Wed, 10 Jan 2001 04:39:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:39:41 +0100 (MET) Received: (qmail 8718 invoked by uid 0); 9 Jan 2001 22:42:57 -0000 Received: from unknown (HELO ho.egroups.com) (64.211.240.236) by mx0.gmx.net (mx14) with SMTP; 9 Jan 2001 22:42:57 -0000 X-eGroups-Return: sentto-1101623-1902-979080141-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 09 Jan 2001 22:42:48 -0000 X-Sender: cms@pnetservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 22:42:21 -0000 Received: (qmail 62568 invoked from network); 9 Jan 2001 22:36:20 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 9 Jan 2001 22:36:20 -0000 Received: from unknown (HELO moutvdom00.kundenserver.de) (195.20.224.149) by mta1 with SMTP; 9 Jan 2001 22:36:19 -0000 Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14G7NK-0005sy-00 for f-cpu@egroups.com; Tue, 9 Jan 2001 23:36:18 +0100 Received: from pd9019fb3.dip.t-dialin.net ([217.1.159.179] helo=apex) by mrvdom03.kundenserver.de with smtp (Exim 2.12 #2) id 14G7NB-0004ah-00 for f-cpu@egroups.com; Tue, 9 Jan 2001 23:36:11 +0100 Message-ID: <002001c07a8c$901fff00$0200a8c0@schubert> To: References: <3A5B8627.FEF4CB49@starpower.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Christian Schubert" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 9 Jan 2001 23:35:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Behold and rejoice! =) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 06064f3e3c6dae7569be9c51999b094c Status: R X-Status: N > I will be unsubscribing myself from this old list in a week or
two...
> Those other losers can send themselves UNSUBSCRIBE!!!!!/flood
messages
> untill they grow old... ;)

Yeah, and if they'll keep full-quoting their own full-quotes soon
their mailboxes start exploding *g*, better move this list sooner than
later...

> 2. Join this project: https://sourceforge.net/projects/freeproc/

One problem with sourceforge: isn't it horrible slow? I tried to
download some stuff (more than once)... and all I got (if something at
all) was something like 1kb/sec...

> Perhaps I will upgrade my OS from win 3.11...
> But It has to be *better* than win 3.11...

Novell DOS 7.0 rockzz da house :)
eGroups Sponsor
From Ben Franchuk Sun Jan 7 17:23:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03451 for ; Wed, 10 Jan 2001 04:39:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:39:44 +0100 (MET) Received: (qmail 24471 invoked by uid 0); 9 Jan 2001 23:00:41 -0000 Received: from jj.egroups.com (208.50.144.82) by 10.1.4.111 (mx11) with SMTP; 9 Jan 2001 23:00:41 -0000 X-eGroups-Return: sentto-1101623-1903-979081199-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 09 Jan 2001 23:00:29 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 22:59:58 -0000 Received: (qmail 43507 invoked from network); 9 Jan 2001 22:54:02 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 9 Jan 2001 22:54:02 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 9 Jan 2001 23:55:06 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA13756 for ; Tue, 9 Jan 2001 15:48:23 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A5897FB.BEE33756@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5B8627.FEF4CB49@starpower.net> <002001c07a8c$901fff00$0200a8c0@schubert> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 07 Jan 2001 09:23:23 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Behold and rejoice! =) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9859f9698e2efb827be99014942d265d Status: R X-Status: N Christian Schubert wrote:

> > Perhaps I will upgrade my OS from win 3.11...
> > But It has to be *better* than win 3.11...
>
> Novell DOS 7.0 rockzz da house :)

How about "FreeDos".
http://www.freedos.org/
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Michael Riepe Wed Jan 10 00:39:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03499 for ; Wed, 10 Jan 2001 04:39:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 04:39:55 +0100 (MET) Received: (qmail 19068 invoked by uid 0); 9 Jan 2001 23:51:35 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx02) with SMTP; 9 Jan 2001 23:51:35 -0000 X-eGroups-Return: sentto-1101623-1904-979084087-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 09 Jan 2001 23:48:57 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 9 Jan 2001 23:48:06 -0000 Received: (qmail 52730 invoked from network); 9 Jan 2001 23:39:24 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 9 Jan 2001 23:39:24 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.124) by mta2 with SMTP; 9 Jan 2001 23:39:22 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01465; Wed, 10 Jan 2001 00:39:18 +0100 Message-ID: <20010110003918.24204@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <979043014.86682@egroups.com> <004101c07a73$284aeac0$19a4fea9@silvius> <001a01c07a8b$9c8e7b00$0200a8c0@schubert> X-Mailer: Mutt 0.84e In-Reply-To: <001a01c07a8b$9c8e7b00$0200a8c0@schubert>; from Christian Schubert on Tue, Jan 09, 2001 at 11:29:01PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 00:39:18 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] REMOVE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b9e19d2b3d91e0ed04ab3134f35eefa1 Status: R X-Status: N On Tue, Jan 09, 2001 at 11:29:01PM +0100, Christian Schubert wrote:
> Hey, damn, are there only dumb bastards in the world out there?

There are also some extremely dumb bastards among them,
and some complete idiots. *sigh*

> Quoting the 'daily digest' back to the list is worse than SPAM (if
> someone considers this list SPAM...), it's mailbombing...
>
> but hey... what am I praying? No one hears me...

You mean, "preaching"?  Praying doesn't help, at least my us= ual prayer
"Herr, schmei=DF Hirn vom Himmel" doesn't ;(

> sch=F6nen Abend noch...

Jo, Dir auch.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
eGroups Sponsor=
3D"Click
Click here to subscribe.
From cable@yourfather.co.uk Wed Jan 10 05:33:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00324 for ; Wed, 10 Jan 2001 19:20:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 19:20:43 +0100 (MET) Received: (qmail 22683 invoked by uid 0); 10 Jan 2001 04:46:18 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx24) with SMTP; 10 Jan 2001 04:46:18 -0000 X-eGroups-Return: sentto-1101623-1906-979101972-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 10 Jan 2001 04:46:12 -0000 X-Sender: cable@yourfather.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 04:46:11 -0000 Received: (qmail 73940 invoked from network); 10 Jan 2001 04:46:10 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Jan 2001 04:46:10 -0000 Received: from unknown (HELO cindy.infomart.or.jp) (210.159.6.52) by mta1 with SMTP; 10 Jan 2001 04:46:10 -0000 Received: from nonooo (1Cust222.tnt11.phoenix.az.da.uu.net [63.14.204.222]) by cindy.infomart.or.jp (8.8.8/3.6Winfomart-cindy20001228) with SMTP id NAA24801; Wed, 10 Jan 2001 13:37:19 +0900 (JST) Message-Id: <200101100437.NAA24801@cindy.infomart.or.jp> X-Priority: 3 X-MSMail-Priority: Normal From: cable@yourfather.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 09 Jan 2001 21:33:18 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] *THE LEGAL CABLE TV DESCRAMBLER* Content-Type: multipart/mixed; boundary="----=_NextPart_000_77BF_000034A0.00006C58" To: sloyment@gmx.net X-UIDL: f9e9e8c292885dffadd36e9a9e189af8 Status: R X-Status: N ------=_NextPart_000_77BF_000034A0.00006C58 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV
DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION
PLEASE CLICK DELETE NOW. THANK YOU--


LEGAL CABLE TV DE-SCRAMBLER

Want to watch Sporting Events?--Movies?--Pay-Per-View??

*This is the Famous R-D-O Shack TV Descrambler
You can assemble it from R-D-O Shack parts for about $12 or $15.

We Send You:
E-Z To follow Assembly Instructions.
E-Z To read Original Drawings.
The Famous R-D-O Shack Parts List.

PLUS SOMETHING NEW YOU MUST HAVE!

Something you can't do without.

THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY



Warning: You should not build a TV Descrambler without
reading this report first.

Frequently Asked Questions--CABLE TV DESCRAMBLER

Q: Will the descrambler work on Fiber, TCI, Jarrod
and satellite systems?
A: The answer is YES. In respect to satellite,
you just get more stuff! There is one exception:
The descrambler will not work with DSS satellite.

Q: Do I need a converter box?
A: This plan works with or without a converter box.
Specific instructions are included in the plans for each!

Q: Can the cable company detect that I have the descrambler?
A: No, the signal descrambles right at the box and does
not move back through the line!

Q: Do I have to alter my existing cable system,
television or VCR?
A: The answer is no!

Q: Does this work with my remote control?
A: The answer is yes. The descrambler is
manually controlled--but very easy to use!

Q: Can you email me the plans?
A: No the program comes with an easy to follow picture guide.

Q: Does this work everywhere across the country?
A: Yes, every where in the USA plus England,
Brazil, Canada and other countries!

Q: When I order, when will I get my stuff?
A: We mail out all orders within 48 hours of receiving them.

YOU SUPPLY A SELF-ADDRESSED, STAMPED, #10 LONG ENVELOPE, WITH
TWO-FIRST CLASS STAMPS.


Q: How much does it cost to get the instruction
plans, the easy to follow diagram, and most
important of all the Using a Descrambler LEGALLY.

A: You get the complete package all for just--$10.00
(Cash, Check or Postal Money Order.)
(Arizona residents include 7% Arizona State Sales Tax)

(All orders outside the U.S.A. add $5.00)

ORDERS OUTSIDE THE US MUST BE IN THE FORM OF AN
INTERNATIONAL MONEY ORDER PAYABLE FROM A US BANK OR US CASH!
NO POSTAGE COUPONS ACCEPTED!
FOREIGN CHECKS WILL BE RETURNED!

Q: How do I order?
A: Fill out form below and send it, along with your payment
AND YOUR SELF ADDRESSED 2 STAMPED ENVELOPE to:

N Duran
PO BOX 8051
Mesa, AZ 85214-8051

MAKE CHECKS PAYABLE TO: N Duran

PRINT YOUR:
(orders without an envelope or stamps will be processed
up to 2 weeks later than complete orders)

DO NOT FORGET YOUR STAMPS!

NAME_____________________________________________

ADDRESS__________________________________________

CITY/STATE/ZIP_____________________________________

DO NOT FORGET YOUR 2, 33 cent stamps and #10 evenlope!





*N Duran is NOT ASSOCIATED in any way with RADIO SHACK.
Neither the design nor instructions were developed
by, are sold by, or are endorsed by Radio Shack.
Parts for this fine-tuning device are available
at many electronics stores (including Radio Shack)
This is not a Radio Shack product.








**********************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.

PLEASE understand that any effort to disrupt, close or block this
REMOVE account can only result in difficulties for others wanting
to be removed from our mailing list as it will be impossible to take
anyone off the list if the remove instruction can not be received.

To be removed from our mailing list please
send an email to: movemeplease14@looksmart.com.au
and place remove in the subject
Thank you
*********************************************************








NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV

DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION

PLEASE CLICK DELETE NOW. THANK YOU--



eGroups Sponsor
Click here for Business information
Click here for Business information
------=_NextPart_000_77BF_000034A0.00006C58-- From Jeff Davies Wed Jan 10 11:19:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00382 for ; Wed, 10 Jan 2001 19:21:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 19:21:15 +0100 (MET) Received: (qmail 29652 invoked by uid 0); 10 Jan 2001 10:28:04 -0000 Received: from unknown (HELO fl.egroups.com) (64.211.240.233) by mx0.gmx.net (mx15) with SMTP; 10 Jan 2001 10:28:04 -0000 X-eGroups-Return: sentto-1101623-1907-979122471-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 10 Jan 2001 10:27:57 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 10:27:51 -0000 Received: (qmail 13288 invoked from network); 10 Jan 2001 10:27:50 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 10 Jan 2001 10:27:50 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta3 with SMTP; 10 Jan 2001 11:28:55 -0000 Received: from modem-87.protactinium.dialup.pol.co.uk ([62.136.65.87] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14GITt-0000rB-00 for f-cpu@egroups.com; Wed, 10 Jan 2001 10:27:49 +0000 Message-ID: <3A5C371B.DA6258D@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 10:19:07 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Whygee, Michael et al are you joining Grimesey's list? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8cca5d64e4389f4a4c556b95dec17133 Status: R X-Status: N Whygee, Michael et al are you joining Grimesey's list?
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Wed Jan 10 12:02:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00397 for ; Wed, 10 Jan 2001 19:21:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 19:21:20 +0100 (MET) Received: (qmail 26767 invoked by uid 0); 10 Jan 2001 11:09:10 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by 10.1.4.111 (mx11) with SMTP; 10 Jan 2001 11:09:10 -0000 X-eGroups-Return: sentto-1101623-1908-979124928-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 10 Jan 2001 11:08:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 11:08:48 -0000 Received: (qmail 97171 invoked from network); 10 Jan 2001 11:08:47 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 10 Jan 2001 11:08:47 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 10 Jan 2001 12:09:52 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA11323; Wed, 10 Jan 2001 03:08:46 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PBSD; Wed, 10 Jan 2001 12:08:35 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5C4148.DE251E5E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5C371B.DA6258D@llandre.freeserve.co.uk> From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 12:02:32 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Whygee, Michael et al are you joining Grimesey's list? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e83ffeeed0e1e3f8033c06a52fc13ebb Status: R X-Status: N Jeff Davies wrote:
>
> Whygee, Michael et al are you joining Grimesey's list?

hi,
unfortunately i have a big make all going on,
i have no time to see what it's about.
and i get enough spam from egroups.
Plus, i gotta update the F-CPU manual.

maybe Al wants to steal our "vaporware of the millenium" award ?

have fun anyway,
YG
eGroups Sponsor
Click here for Business information
Click here for Business information
From DuaneMHunt170976@aol.com Wed Jan 10 19:52:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00712 for ; Wed, 10 Jan 2001 21:38:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 10 Jan 2001 21:38:10 +0100 (MET) Received: (qmail 6816 invoked by uid 0); 10 Jan 2001 19:06:32 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx22) with SMTP; 10 Jan 2001 19:06:32 -0000 X-eGroups-Return: sentto-1101623-1909-979153565-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 10 Jan 2001 19:06:18 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 19:06:05 -0000 Received: (qmail 96865 invoked from network); 10 Jan 2001 18:52:42 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 10 Jan 2001 18:52:42 -0000 Received: from unknown (HELO imo-r01.mail.aol.com) (152.163.225.1) by mta3 with SMTP; 10 Jan 2001 19:53:47 -0000 Received: from DuaneMHunt170976@aol.com by imo-r01.mx.aol.com (mail_out_v28.35.) id a.65.e516fa5 (17531) for ; Wed, 10 Jan 2001 13:52:16 -0500 (EST) Message-ID: <65.e516fa5.278e095f@aol.com> To: f-cpu@egroups.com X-Mailer: 6.0 sub 36 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 13:52:15 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] *THE LEGAL CABLE TV DESCRAMBLER* Content-Type: multipart/alternative; boundary="part1_65.e516fa5.278e095f_boundary" X-UIDL: d0bfb7d25830f17bf9edc73a838bb04d Status: R X-Status: N --part1_65.e516fa5.278e095f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit RIGHT WHERE DO I GO TO QUIT THIS JUNK MAIL STUFF THEN --part1_65.e516fa5.278e095f_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit RIGHT WHERE DO I GO TO QUIT THIS JUNK MAIL STUFF THEN
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
--part1_65.e516fa5.278e095f_boundary-- From Jecel Assumpcao Jr Wed Jan 10 21:50:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02534 for ; Thu, 11 Jan 2001 12:14:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:14:55 +0100 (MET) Received: (qmail 1248 invoked by uid 0); 10 Jan 2001 21:23:41 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx22) with SMTP; 10 Jan 2001 21:23:41 -0000 X-eGroups-Return: sentto-1101623-1911-979161351-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 10 Jan 2001 21:16:10 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 21:15:50 -0000 Received: (qmail 48269 invoked from network); 10 Jan 2001 21:00:47 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 10 Jan 2001 21:00:47 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta2 with SMTP; 10 Jan 2001 21:00:45 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA13216 for ; Wed, 10 Jan 2001 19:13:18 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <3A5CC5E1.1CE5ADD3@ifrance.com> In-Reply-To: <3A5CC5E1.1CE5ADD3@ifrance.com> Message-Id: <01011019070202.00393@gandalf> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 18:50:10 -0200 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e37e2170204fa556495f222aa077d8f4 Status: R X-Status: N Could someone please tell me why standard technologies aren't good
enough for the FCPU?

I would think at least one of these would do the job:

    Scalable Coherent Interface
    SCI
    IEEE 1596
    http://www.SCIzzL.com/

    Infiniband
    http://www.infinibandta.org

    Serial Plus
    IEEE P2100 (ex IEEE P1394.2)
    http://www.SCIzzL.com/P2100/index.html

I don't see the need for the G chip - just put in the memory interfaces
(north bridge, in PC speak) and one of the above in the CPU itself.

-- Jecel
eGroups Sponsor
From Nicolas Boulay Wed Jan 10 21:28:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02574 for ; Thu, 11 Jan 2001 12:15:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:00 +0100 (MET) Received: (qmail 3616 invoked by uid 0); 10 Jan 2001 20:39:40 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by 10.1.4.111 (mx11) with SMTP; 10 Jan 2001 20:39:40 -0000 X-eGroups-Return: sentto-1101623-1910-979158913-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 10 Jan 2001 20:35:35 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 20:35:12 -0000 Received: (qmail 75605 invoked from network); 10 Jan 2001 20:20:51 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 10 Jan 2001 20:20:51 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 10 Jan 2001 21:21:56 -0000 Received: from ifrance.com (nas23-188.vlt.club-internet.fr [195.36.173.188]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA09571 for ; Wed, 10 Jan 2001 21:20:45 +0100 (MET) Message-ID: <3A5CC5E1.1CE5ADD3@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 21:28:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0382420d657a3013a8ff1badb5326bc8 Status: R X-Status: N Some patchwork answer.

> I was just sugesting you to look at the idea of ATM networks. It has service like reserving a part of the bandwidth for communication between two points.

Mmmh, it's a bad idea because of the very bad latency. Respond time is
worst than a 100 Mega ethernet  switch, much too bad for us ( > 1ms !).

> >That's why i said "in the best case". But remember that a 64 bit 133 Mhz
> >run at 1Go/s so 8 gigabits links run at the same speed.
> did you forget that i showed that it had more latency ?

Yeah, that's the bill. But it's the only way to use less wire !

> > I would like to
> >create something to optimise the transfert (my extended MMU).
> do it and publish the draft, damnit !
> but please don't use "magic words" but real physical
> names for the units (ie : compare, register, add ... forget
> words like "manager" or "handler" that don't mean anything)

Ok, ok ! Could you give me an account to seul ?

> >Not really. Don't only think like SRAM READ, but you can make burst transfert like for COMA arch.
> burst are fine, but when you want to transfer a simple semaphore,
> it takes a lot of time for the setup (just like vector vs SIMD :
> the time to fill the vector pipeline influences the performance)

It will be explain in the draft. That's the story of the 4 algorythmes.
2 use pages. 2 use word.

> >You can't have the same bandwith between memory and the fcpu and between
> >the fcpu and the network. Memory will be always quicker. I don't like to
> >have 2 seperate chips because you will have a link between them. This
> >"waste" could be used instead for simple serial link. Using common
> >serial link is to replace wire by speed. So the "true" bandwith between
> >the memory and the network could be maximum in a one chip system. If you
> >have 4 link by g-chip, 3 links speak to the same node but you have only
> >the 1/3 to communicate to the node memories, but if you have one chip,
> >it's easy to have 3 times the bandwith of the f-bus to the memory.
>
>Fine but you forget about pin counts. And pin counts scales
>with price too. not only chip price but PCB routing and layer number....
>
Hmm, reread  me ! I want to use quick serial link to use less wire and
decrease the number of pin used.

> >The idea is to have a much higher bandwith for the link.
> so it's more expensive and consumes more power !
> in CMOS-like, if you  drive the signal 10x faster, you consume
> 10x more. and your serial link is not going to use 1V signalling.

You forget one very big point, you have 4 times less wire... (500 Mhz
compare to 133Mhz for the same bandwith)

> > In some year
> >will come the 10 000base T, so maybe 10 Go/s will be possible ;p.
>
> no. never. do NEVER believe peak rates.
> you never burst a 10 billion bit stream .

Why not ? It's plan, and it should work in few years ! And 80% of this,
is good enought !

> >It isn't so simple. Topology is importante when you choose your
> >algorithme for shared memory.
> both are in the hands of the end user.
> EOT.

So you considere not to use HW acceleration (like for the
extended-MMU-which-i-must-write-a-draft-about-it).

> > You can choose to make it by SW (like
> >SUN). Or by HW, so the network must be known. If you use mostly
> >broadcast, a ring is fine (in a cube you lost a lot of bandwith), a
> > point to point is quick, but you have to make some routing and you have
> >to know were is a ressource !
> fine. Prove me that you can't know where the ressources are.

I not say that you can't find it. But that you need a location table
somewhere. So it's some more unusefull communication on the system
network.

nicO
eGroups Sponsor
From Nicolas Boulay Wed Jan 10 22:52:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02595 for ; Thu, 11 Jan 2001 12:15:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:09 +0100 (MET) Received: (qmail 8225 invoked by uid 0); 10 Jan 2001 22:11:22 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx05) with SMTP; 10 Jan 2001 22:11:22 -0000 X-eGroups-Return: sentto-1101623-1912-979164564-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 10 Jan 2001 22:11:19 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:09:23 -0000 Received: (qmail 79165 invoked from network); 10 Jan 2001 21:45:21 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Jan 2001 21:45:21 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 10 Jan 2001 21:45:21 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10300 for ; Wed, 10 Jan 2001 22:45:17 +0100 (MET) Message-ID: <3A5CD9B2.32B44524@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 22:52:50 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Let's go back to the core ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0cdb9dcc45cb7c963112d1d9ed6ae570 Status: R X-Status: N > >> Yep.  Very common when (simple) COMA is used, IIRC.
> >>
> >In NORMA arch, too, no ?
>
> but i don't care about your norma, coma, IIRC etc ...
> we should speak about the core... damnit...

Let's go ;p

I would speak about some feature of the core. It's a "discussion" about
how make a cpu whish is easy to   expand (Or how make Pentuim IV more
easy and simple when you come from the 8088). Or how to make easly fc1,
fc2,...

I have recently read an article about "why Pentuim IV suxx ?"(
http://www.emulators.com/pentium4.htm ). It's explain that Intel have
big idea but cut to much feature to compete with athlon. For exemple,
they beleave in the trace cache, around 96 Ko of memory, but it is
compared to a 8 Ko L1 cache ! And because of such cache, they just put
one decoder compare to the 3 include inside the Athlon. So it's much
slower to decode "not-in-trace-cache" code.

If you look to the athlon pipeline you will see around 12 or 14 stage.
But only one for the ALU, all other was for scheduling, register
renaming and all that kind of stuff. So silicon are mainly used for
scheduling (to know which instruction to execute) than for calculing.

Athlon and PIV are design to perfome the same operation 3 time per clock
tick (they have 3 alu, 3 fpu,...). But they want to xlr8 the old code,
too. And dependancies between register made that you can't speed up code
by just having a scorebord. You need register renaming and all that
stuff, to really have 3 intructions run in the same time.

The probleme came when you want to speed up old binaries. Pentuim use 2
decoder, but Pentuim pro have 3 but can excute only one complex
instruction (memory to memory,...) and 2 "simple" RISC-like instruction.
So the programming rules changes and the "true" speed up is less evident
(or why some time a pentuim MMX could outperforme a PIII).

To increase the speed of a cpu, you could increase the clock
frequencies. That's easy but you add depencies problemes with long
pipeline (20 for PIV more for the FCPU ?). You can try to execute
differente type of instruction in the same time (ALU, load&store). It's
just a little more decode, the unit are soon here. And then, you can add
some more unit like an ALU. Here, is the problem, how could we expect to
increase speed linearly compare to the number of unit?

How can we broke depencies soon increase by the deep pipeline (true
dependence are now around 10 instructions or even more) ? Scorebording
is the easy and first step to do it, but if there is to much depencies
the code will as slow as befor.

Big register bank could help to broke depencies. But it's always a limit
put in the design. SIMD parrallelism are maybe a good way to increase
speed. If you can really double the size of this register, and the code
always work, you could be close to double your speed in your calcul
intensive task. But the compiler and the coding rules could be hard to
write and follow.

An other means could be used is the SMT technologies. Having virtualy
few processors but using the same hardware.  You just make a cpu with an
enormous pipeline (why not 100 stages). And for each new instruction you
take an instruction from an other thread. It's like having a true SMP
system with 4, 8, 16 or 32 slower processors. So you have some different
register banks. With that you broke pipeline depencies a lot. Some
people would break the memory latencies, too. It's a good idea, but a
cache miss cost around 150 cycles. So you need to have a lot of thread
(-> very difficult to write the code) or having a complex scheduling
unit to know wich thread could be executed, with the big risk to
recreate register depencies.

So there are lot of problem. The worst is to write a good compiler for
that. How could it be easy to add some thread capabilities ? You could
excute 4 threads and what happen to the code with 8 or 16 ? With such
big pipeline, the speed reach by the processor could became fabulous (5
or 6 GHz with today technologies !) and the cache memory must follow.
But by adding some more pipeline stage, maybe we can solve the problem
;p

In the other hand i have read in comp.arch, that there is a very strong
dependancies on the stack pointer. Without this dependancy, the true ILP
of lot of program could reach 100 or more. This imply to develop a new
way to make function call to avoid such depencies. But 100 compare to
the usual number of 3 is to much to be forgotten (for GCC).

I like very much to take a few a lot of different thing to speed up our
design. So few SIMD spec, few SMT, few vliw (at the very beginning
having a pair rules to the instruction). But we always have the problem
to have a good compiler to handle all that new stuff.

I know that some people would say that we haven't soon one little FC0
BUT things made for the 8088 are  always inside the P4, ...

nicO
eGroups Sponsor
From Nicolas Boulay Wed Jan 10 22:52:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02613 for ; Thu, 11 Jan 2001 12:15:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:16 +0100 (MET) Received: (qmail 11065 invoked by uid 0); 10 Jan 2001 22:10:59 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx21) with SMTP; 10 Jan 2001 22:10:59 -0000 X-eGroups-Return: sentto-1101623-1912-979164564-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 10 Jan 2001 22:10:53 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:09:23 -0000 Received: (qmail 79165 invoked from network); 10 Jan 2001 21:45:21 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 10 Jan 2001 21:45:21 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 10 Jan 2001 21:45:21 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10300 for ; Wed, 10 Jan 2001 22:45:17 +0100 (MET) Message-ID: <3A5CD9B2.32B44524@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 22:52:50 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Let's go back to the core ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5392e4198ce261191bef83979c824cd5 Status: R X-Status: N > >> Yep.  Very common when (simple) COMA is used, IIRC.
> >>
> >In NORMA arch, too, no ?
>
> but i don't care about your norma, coma, IIRC etc ...
> we should speak about the core... damnit...

Let's go ;p

I would speak about some feature of the core. It's a "discussion" about
how make a cpu whish is easy to   expand (Or how make Pentuim IV more
easy and simple when you come from the 8088). Or how to make easly fc1,
fc2,...

I have recently read an article about "why Pentuim IV suxx ?"(
http://www.emulators.com/pentium4.htm ). It's explain that Intel have
big idea but cut to much feature to compete with athlon. For exemple,
they beleave in the trace cache, around 96 Ko of memory, but it is
compared to a 8 Ko L1 cache ! And because of such cache, they just put
one decoder compare to the 3 include inside the Athlon. So it's much
slower to decode "not-in-trace-cache" code.

If you look to the athlon pipeline you will see around 12 or 14 stage.
But only one for the ALU, all other was for scheduling, register
renaming and all that kind of stuff. So silicon are mainly used for
scheduling (to know which instruction to execute) than for calculing.

Athlon and PIV are design to perfome the same operation 3 time per clock
tick (they have 3 alu, 3 fpu,...). But they want to xlr8 the old code,
too. And dependancies between register made that you can't speed up code
by just having a scorebord. You need register renaming and all that
stuff, to really have 3 intructions run in the same time.

The probleme came when you want to speed up old binaries. Pentuim use 2
decoder, but Pentuim pro have 3 but can excute only one complex
instruction (memory to memory,...) and 2 "simple" RISC-like instruction.
So the programming rules changes and the "true" speed up is less evident
(or why some time a pentuim MMX could outperforme a PIII).

To increase the speed of a cpu, you could increase the clock
frequencies. That's easy but you add depencies problemes with long
pipeline (20 for PIV more for the FCPU ?). You can try to execute
differente type of instruction in the same time (ALU, load&store). It's
just a little more decode, the unit are soon here. And then, you can add
some more unit like an ALU. Here, is the problem, how could we expect to
increase speed linearly compare to the number of unit?

How can we broke depencies soon increase by the deep pipeline (true
dependence are now around 10 instructions or even more) ? Scorebording
is the easy and first step to do it, but if there is to much depencies
the code will as slow as befor.

Big register bank could help to broke depencies. But it's always a limit
put in the design. SIMD parrallelism are maybe a good way to increase
speed. If you can really double the size of this register, and the code
always work, you could be close to double your speed in your calcul
intensive task. But the compiler and the coding rules could be hard to
write and follow.

An other means could be used is the SMT technologies. Having virtualy
few processors but using the same hardware.  You just make a cpu with an
enormous pipeline (why not 100 stages). And for each new instruction you
take an instruction from an other thread. It's like having a true SMP
system with 4, 8, 16 or 32 slower processors. So you have some different
register banks. With that you broke pipeline depencies a lot. Some
people would break the memory latencies, too. It's a good idea, but a
cache miss cost around 150 cycles. So you need to have a lot of thread
(-> very difficult to write the code) or having a complex scheduling
unit to know wich thread could be executed, with the big risk to
recreate register depencies.

So there are lot of problem. The worst is to write a good compiler for
that. How could it be easy to add some thread capabilities ? You could
excute 4 threads and what happen to the code with 8 or 16 ? With such
big pipeline, the speed reach by the processor could became fabulous (5
or 6 GHz with today technologies !) and the cache memory must follow.
But by adding some more pipeline stage, maybe we can solve the problem
;p

In the other hand i have read in comp.arch, that there is a very strong
dependancies on the stack pointer. Without this dependancy, the true ILP
of lot of program could reach 100 or more. This imply to develop a new
way to make function call to avoid such depencies. But 100 compare to
the usual number of 3 is to much to be forgotten (for GCC).

I like very much to take a few a lot of different thing to speed up our
design. So few SIMD spec, few SMT, few vliw (at the very beginning
having a pair rules to the instruction). But we always have the problem
to have a good compiler to handle all that new stuff.

I know that some people would say that we haven't soon one little FC0
BUT things made for the 8088 are  always inside the P4, ...

nicO
eGroups Sponsor
From Nicolas Boulay Wed Jan 10 23:11:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02616 for ; Thu, 11 Jan 2001 12:15:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:18 +0100 (MET) Received: (qmail 4297 invoked by uid 0); 10 Jan 2001 22:25:34 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx22) with SMTP; 10 Jan 2001 22:25:34 -0000 X-eGroups-Return: sentto-1101623-1915-979165446-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 10 Jan 2001 22:25:28 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:24:06 -0000 Received: (qmail 47434 invoked from network); 10 Jan 2001 22:03:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 10 Jan 2001 22:03:45 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 10 Jan 2001 22:03:44 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA05036 for ; Wed, 10 Jan 2001 23:03:41 +0100 (MET) Message-ID: <3A5CDE02.C77497DF@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5C371B.DA6258D@llandre.freeserve.co.uk> <3A5C4148.DE251E5E@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 23:11:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Whygee, Michael et al are you joining Grimesey's list? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e3aeaa62dd6e78a4e974df5e1cb559cd Status: R X-Status: N I don't like what is written on the forum of the "freeproc".

"The Freedom CPU project is reborn as the FreeProc initiative!
  This new initiative will take full advantage of sourceforge's advanc= ed
features
  and bring the principles of quality managment to the dissorganized a= nd
  anarchistic F-CPU project."

How this personn could write that ? And he want some persons from the
fcpu project ? It's a joke ? ;(

nicO

Yann GUIDON a =E9crit :
>
> Jeff Davies wrote:
> >
> > Whygee, Michael et al are you joining Grimesey's list?
>
> hi,
> unfortunately i have a big make all going on,
> i have no time to see what it's about.
> and i get enough spam from egroups.
> Plus, i gotta update the F-CPU manual.
>
> maybe Al wants to steal our "vaporware of the millenium" awa= rd ?
>
> have fun anyway,
> YG
eGroups Sponsor=
3D"Click
From Nicolas Boulay Wed Jan 10 23:32:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02631 for ; Thu, 11 Jan 2001 12:15:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:22 +0100 (MET) Received: (qmail 32514 invoked by uid 0); 10 Jan 2001 22:48:33 -0000 Received: from unknown (HELO ef.egroups.com) (64.211.240.229) by 10.1.4.119 (mx19) with SMTP; 10 Jan 2001 22:48:33 -0000 X-eGroups-Return: sentto-1101623-1917-979166888-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ef.egroups.com with NNFMP; 10 Jan 2001 22:48:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:48:06 -0000 Received: (qmail 51595 invoked from network); 10 Jan 2001 22:25:19 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 10 Jan 2001 22:25:19 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 10 Jan 2001 23:26:24 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA14740 for ; Wed, 10 Jan 2001 23:25:16 +0100 (MET) Message-ID: <3A5CE311.DC864275@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <01011019070202.00393@gandalf> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 23:32:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 22573f6ae7c2ade403c2a4bfd5d1e696 Status: R X-Status: N http://www.SCIzzL.com/ what is this = organisation ? It's seems to be
something free.

nicO

Jecel Assumpcao Jr a =E9crit :
>
> Could someone please tell me why standard technologies aren't good
> enough for the FCPU?
>
> I would think at least one of these would do the job:
>
>     Scalable Coherent Interface
>     SCI
>     IEEE 1596
>     http://www.= SCIzzL.com/
>
>     Infiniband
>     http:/= /www.infinibandta.org
>
>     Serial Plus
>     IEEE P2100 (ex IEEE P1394.2)
>     http://www.SCIzzL.com/P2100/index.html
>
> I don't see the need for the G chip - just put in the memory interface= s
> (north bridge, in PC speak) and one of the above in the CPU itself. >
> -- Jecel
eGroups Sponsor=
3D"Click
Click here to subscribe.
From Michael Riepe Wed Jan 10 14:40:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02638 for ; Thu, 11 Jan 2001 12:15:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:24 +0100 (MET) Received: (qmail 19176 invoked by uid 0); 10 Jan 2001 22:54:43 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx21) with SMTP; 10 Jan 2001 22:54:43 -0000 X-eGroups-Return: sentto-1101623-1918-979167193-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 10 Jan 2001 22:54:41 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:53:13 -0000 Received: (qmail 69009 invoked from network); 10 Jan 2001 22:30:22 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 10 Jan 2001 22:30:22 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.152) by mta1 with SMTP; 10 Jan 2001 22:30:19 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00595; Wed, 10 Jan 2001 14:40:28 +0100 Message-ID: <20010110144028.17804@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5C371B.DA6258D@llandre.freeserve.co.uk> X-Mailer: Mutt 0.84e In-Reply-To: <3A5C371B.DA6258D@llandre.freeserve.co.uk>; from Jeff Davies on Wed, Jan 10, 2001 at 10:19:07AM +0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 14:40:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Whygee, Michael et al are you joining Grimesey's list? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e55ae9ecedbd6dba09780f589a9c1300 Status: R X-Status: N On Wed, Jan 10, 2001 at 10:19:07AM +0000, Jeff Davies wrote:
> Whygee, Michael et al are you joining Grimesey's list?

Maybe, but only as a lurker :)

I really have no time left for yet another project;
so I'll stay here and help finish the F-CPU first.
After that -- who knows?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click here to subscribe.
Click here to subscribe.
From Nicolas Boulay Wed Jan 10 23:40:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02642 for ; Thu, 11 Jan 2001 12:15:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:26 +0100 (MET) Received: (qmail 2244 invoked by uid 0); 10 Jan 2001 22:59:59 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx13) with SMTP; 10 Jan 2001 22:59:59 -0000 X-eGroups-Return: sentto-1101623-1919-979167590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 10 Jan 2001 22:59:57 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:59:49 -0000 Received: (qmail 22611 invoked from network); 10 Jan 2001 22:32:42 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 10 Jan 2001 22:32:42 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 10 Jan 2001 23:33:47 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA27452 for ; Wed, 10 Jan 2001 23:32:40 +0100 (MET) Message-ID: <3A5CE4CC.46A81D00@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 23:40:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 21c2391ca170696525073b056426de02 Status: R X-Status: N Since the beginning, the fcpu have 2 links to the outside. 1, low
latencie, full speed 128 bits DDR-SDRAM or QDR-SDRAM to access to the
memory. 2, beside that there is a "link" to the global system net= work to
communicate with the other cpu and IO, which is slower than the memory
bus, because of the problem of the number of pins.

nicO

Ben Franchuk a =E9crit :
>
> I think one still needs to concentrate on the memory <-> cpu int= erface.
> It is not how fast one device can access memory but a group of devices=
> sharing memory. One needs to SLOW down the fastest device to let other= s
> use the bus so why add the speed if not needed?.
> Bus latency can be got around I think if one can make
> it visible to the Software like delayed branches.A load instruction > may specify that the value loaded can have #n cycles to complete rathe= r
> than stall.(Note I have not checked the new manual to see if you do th= at
> now).
> Can one still assume that we have Random Access memory rather
> than a serial mess for regular data access?It may be useful to have > segmented memory for I/O devices since small memory is cheap.
> Ben.
> PS. For a console for a proto-type F-CPU with all I/O features
> here a idea.
> http://www= .angelfire.com/scifi/B205/paulj2.html
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor=
3D""
From Michael Riepe Wed Jan 10 23:52:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02654 for ; Thu, 11 Jan 2001 12:15:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:32 +0100 (MET) Received: (qmail 18635 invoked by uid 0); 10 Jan 2001 23:13:30 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx01) with SMTP; 10 Jan 2001 23:13:30 -0000 X-eGroups-Return: sentto-1101623-1920-979168383-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 10 Jan 2001 23:13:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 23:13:02 -0000 Received: (qmail 51822 invoked from network); 10 Jan 2001 22:52:14 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 10 Jan 2001 22:52:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.152) by mta3 with SMTP; 10 Jan 2001 23:53:18 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01201; Wed, 10 Jan 2001 23:52:14 +0100 Message-ID: <20010110235214.27894@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5C371B.DA6258D@llandre.freeserve.co.uk> <3A5C4148.DE251E5E@mentor.com> <3A5CDE02.C77497DF@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A5CDE02.C77497DF@ifrance.com>; from Nicolas Boulay on Wed, Jan 10, 2001 at 11:11:14PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 23:52:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Whygee, Michael et al are you joining Grimesey's list? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d351a44c936422b48d06da2cbbf8d5db Status: R X-Status: N On Wed, Jan 10, 2001 at 11:11:14PM +0100, Nicolas Boulay wrote:
> I don't like what is written on the forum of the "freeproc".
>
>  "The Freedom CPU project is reborn as the FreeProc initiative!
>   This new initiative will take full advantage of sourceforge's advanced
> features
>   and bring the principles of quality managment to the dissorganized and
>   anarchistic F-CPU project."

I just love being "dissorganized and anarchistic" :)

> How this personn could write that ? And he want some persons from the
> fcpu project ? It's a joke ? ;(

No, I'm afraid he's serious.  But I'm laughing anyway ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click here!
From Nicolas Boulay Wed Jan 10 23:28:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02657 for ; Thu, 11 Jan 2001 12:15:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:33 +0100 (MET) Received: (qmail 19863 invoked by uid 0); 10 Jan 2001 22:42:40 -0000 Received: from cj.egroups.com (208.50.144.68) by 10.1.4.111 (mx11) with SMTP; 10 Jan 2001 22:42:40 -0000 X-eGroups-Return: sentto-1101623-1916-979166544-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 10 Jan 2001 22:42:34 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 22:42:22 -0000 Received: (qmail 10377 invoked from network); 10 Jan 2001 22:21:16 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 10 Jan 2001 22:21:16 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 10 Jan 2001 23:22:21 -0000 Received: from ifrance.com (nas13-70.vlt.club-internet.fr [195.36.163.70]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA18708 for ; Wed, 10 Jan 2001 23:21:14 +0100 (MET) Message-ID: <3A5CE21E.CE521B1E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <01011019070202.00393@gandalf> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 23:28:46 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e2cb13d20d3635d91e6049616c91cd1c Status: R X-Status: N I just read about Serial Plus, nice stuff ! I have heard something to
compete against Infiniband but more free. Any idea ?

nicO

Jecel Assumpcao Jr a =E9crit :
>
> Could someone please tell me why standard technologies aren't good
> enough for the FCPU?
>
> I would think at least one of these would do the job:
>
>     Scalable Coherent Interface
>     SCI
>     IEEE 1596
>     http://www.= SCIzzL.com/
>
>     Infiniband
>     http:/= /www.infinibandta.org
>
>     Serial Plus
>     IEEE P2100 (ex IEEE P1394.2)
>     http://www.SCIzzL.com/P2100/index.html
>
> I don't see the need for the G chip - just put in the memory interface= s
> (north bridge, in PC speak) and one of the above in the CPU itself. >
> -- Jecel
eGroups Sponsor=
3D"Click
Click here to subscribe.
From "Marco Al" Thu Jan 11 00:11:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02663 for ; Thu, 11 Jan 2001 12:15:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:35 +0100 (MET) Received: (qmail 14535 invoked by uid 0); 10 Jan 2001 23:25:27 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx13) with SMTP; 10 Jan 2001 23:25:27 -0000 X-eGroups-Return: sentto-1101623-1921-979169086-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 10 Jan 2001 23:25:19 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 23:24:45 -0000 Received: (qmail 23183 invoked from network); 10 Jan 2001 23:03:11 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 10 Jan 2001 23:03:11 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 10 Jan 2001 23:03:10 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id AAA17667 for ; Thu, 11 Jan 2001 00:03:08 +0100 (MET) Message-ID: <001c01c07b5a$98c27dd0$29e65982@student.utwente.nl> To: References: <3A5930AE.3DD011BA@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 00:11:00 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 93eb5b925817b663eb2da55ecf93b282 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> may specify that the value loaded can have #n cycles to complete rather
> than stall.(Note I have not checked the new manual to see if you do that
> now).

They have a prefetch instruction you could use (load to register 0) although if
you want to use it to compensate for memory latency you have to issue it many
10's of cycles early (probably 100+ for non local memory accesses if you use a
single memory space for multiprocessor setups). Using a load instruction with a
latency of 10's of cycles instead of the prefetch would IMO not be a good idea,
with that kind of latency you have to have far too many load instructions in the
pipeline.

From: "Jecel Assumpcao Jr" <jecel@merlintec.com>

> Could someone please tell me why standard technologies aren't good
> enough for the FCPU?

Some of them are a little too generic, and some come at a hefty cost. And it
just makes it easier for the patent owners to hunt you down :)

> I would think at least one of these would do the job:
>
>     Scalable Coherent Interface
>     SCI
>     IEEE 1596
>     http://www.SCIzzL.com/

Yes its usable, but its mostly aimed at ccNUMA. You first have to decide wether
you want to use automatic cache coherency (and if you do go to that length you
will probably want to go the final yard and extend it with support for page
migration, and possibly replication) otherwise it doesnt make much sense.

>     Infiniband
>     http://www.infinibandta.org

Least suited of the bunch.

>     Serial Plus
>     IEEE P2100 (ex IEEE P1394.2)
>     http://www.SCIzzL.com/P2100/index.html

And LDT and Rapid-IO (although I think the last one is strictly an
interconnect).

> I don't see the need for the G chip - just put in the memory interfaces
> (north bridge, in PC speak) and one of the above in the CPU itself.

I agree.

Marco
eGroups Sponsor
Click Here!
From Jecel Assumpcao Jr Thu Jan 11 00:03:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02669 for ; Thu, 11 Jan 2001 12:15:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:37 +0100 (MET) Received: (qmail 14289 invoked by uid 0); 10 Jan 2001 23:44:25 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx09) with SMTP; 10 Jan 2001 23:44:25 -0000 X-eGroups-Return: sentto-1101623-1922-979170225-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 10 Jan 2001 23:44:15 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 10 Jan 2001 23:43:44 -0000 Received: (qmail 53096 invoked from network); 10 Jan 2001 23:20:31 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 10 Jan 2001 23:20:31 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta3 with SMTP; 11 Jan 2001 00:21:34 -0000 Received: from gandalf (root@gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id VAA13450 for ; Wed, 10 Jan 2001 21:33:06 -0200 Organization: Merlintec Computers To: f-cpu@egroups.com X-Mailer: KMail [version 1.0.28] References: <01011019070202.00393@gandalf> <3A5CE21E.CE521B1E@ifrance.com> In-Reply-To: <3A5CE21E.CE521B1E@ifrance.com> Message-Id: <01011021264600.01713@gandalf> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 21:03:35 -0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Serial Plus (was: networks, bus, topologies, links.............) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3b77a4e7905b84daf1a5b80856d10516 Status: R X-Status: N On Wed, 10 Jan 2001, Nicolas Boulay wrote:
> I just read about Serial Plus, nice stuff ! I have heard something to
> compete against Infiniband but more free. Any idea ?

I haven't taken a look at the Infiniband standard yet, but am planning
to use Serial Plus (http://www.merlintec.com/merlin6/e_main.html). It
is a great combination of the features in SCI and Firewire. The problem
that I see is that all the big companies are supporting Infiniband and
the Serial Plus standards effort seems to be very slow or even stopped.

This means that in the future there might be lots of stuff to connect
to Infiniband but nothing for Serial Plus (remember EISA and
Microchannel vs PCI?).

On the other hand, not only don't I have to pay $20 to read the P2100
draft standard, I can send feedback to the developers and it might get
changed to better suit my needs. But I hardly have to explain the joys
of freedom in this list, do I?

-- Jecel
eGroups Sponsor
From DuaneMHunt170976@aol.com Thu Jan 11 00:42:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02678 for ; Thu, 11 Jan 2001 12:15:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:39 +0100 (MET) Received: (qmail 8405 invoked by uid 0); 11 Jan 2001 00:04:20 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx15) with SMTP; 11 Jan 2001 00:04:20 -0000 X-eGroups-Return: sentto-1101623-1923-979171264-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 11 Jan 2001 00:01:08 -0000 X-Sender: DuaneMHunt170976@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 00:01:03 -0000 Received: (qmail 66408 invoked from network); 10 Jan 2001 23:42:16 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 10 Jan 2001 23:42:16 -0000 Received: from unknown (HELO imo-r05.mail.aol.com) (152.163.225.5) by mta2 with SMTP; 10 Jan 2001 23:42:15 -0000 Received: from DuaneMHunt170976@aol.com by imo-r05.mx.aol.com (mail_out_v28.35.) id a.bc.ed20b13 (6964) for ; Wed, 10 Jan 2001 18:42:03 -0500 (EST) Message-ID: To: f-cpu@egroups.com X-Mailer: 6.0 sub 36 From: DuaneMHunt170976@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 18:42:02 EST Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: multipart/alternative; boundary="part1_bc.ed20b13.278e4d4a_boundary" X-UIDL: f76d1269948559844184b84e7fa1d0bd Status: R X-Status: N --part1_bc.ed20b13.278e4d4a_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit right im quitting this JUNK MAIL LARK you lot are rude at times i asked how to get off and nout came of it i WANT OFF and cant remeber how i got on in the first place ill try blocking the lot --part1_bc.ed20b13.278e4d4a_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit right im quitting this JUNK MAIL LARK

you lot are rude at times

i asked how to get off and nout came of it

i WANT OFF and cant remeber how i got on in the first place
ill try blocking the lot

eGroups Sponsor
Click here!
--part1_bc.ed20b13.278e4d4a_boundary-- From David Sullins Thu Jan 11 01:00:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02684 for ; Thu, 11 Jan 2001 12:15:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:15:41 +0100 (MET) Received: (qmail 9219 invoked by uid 0); 11 Jan 2001 00:27:16 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx21) with SMTP; 11 Jan 2001 00:27:16 -0000 X-eGroups-Return: sentto-1101623-1924-979172764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 11 Jan 2001 00:27:04 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 00:26:03 -0000 Received: (qmail 55467 invoked from network); 11 Jan 2001 00:06:24 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 11 Jan 2001 00:06:24 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta3 with SMTP; 11 Jan 2001 01:07:29 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id SAA28051; Wed, 10 Jan 2001 18:06:23 -0600 Received: from eceultra19 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id SAA17884; Wed, 10 Jan 2001 18:06:18 -0600 (CST) Received: from localhost by eceultra19 (8.8.8+Sun/ECESolaris-Client) id AAA03276; Thu, 11 Jan 2001 00:00:43 GMT To: f-cpu@egroups.com In-Reply-To: <20010110144028.17804@thrai.stud.uni-hannover.de> Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 10 Jan 2001 18:00:43 -0600 (CST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] f-cpu project management Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d87bd2d8aa04ff78622e0f53f7990776 Status: R X-Status: N Warning: long post from a lurker.

Hi, I've been checking up on the f-cpu list from time to time trying to
decide when or if I should get involved.  Two things have kept me from
jumping in so far:
1) laziness
2) lack of a central CVS repository

These are not unrelated.  CVS helps the lazy (like me) to quickly identify
the latest version of anything so I don't have to hunt around a mailing
list to find it.  I originally wanted to help test out the small bits of
code that were already written, but it seemed too annoying always needing
to figure out if I've got the latest version.

Although this Grimes guy is obviously a troll, he makes some good points. 
Some things that he mentioned that might help the F-CPU project recruit
more members (definitely something you could use):

1) organized central way of getting/updating latest source and docs (CVS)
This makes it easier for a new person to get up to speed on where the
project is.  See above.

2) milestones, goals, or at least a "to do" list
This gives a new person a way to see what can be done.  Right now the todo
list includes just about everything, but if the project grows you'll be
glad you have something like this.

3) who is working on what
This is related to #2.  Once you have a list of things to do, people can
volunteer to be responsible for a certain part.

4) better mailing list management
Has anyone ever tried to contact egroups and get control of the mailing
list from whoever used to be in charge?  If not, can I?  I don't mind.

Another minor thing I'd like to mention is that I've noticed the use of
language inappropriate for a group of engineers.  I'm no Miss Manners
myself, but I try to keep my professional correspondence sounding
professional.

I hope I've translated Mr. Grimes' troll-speak into a more helpful and
reasonable set of suggestions.

-Helpful Dave
eGroups Sponsor
Click here to subscribe.
Click here to subscribe.
From Yann GUIDON Thu Jan 11 11:58:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA02756 for ; Thu, 11 Jan 2001 12:16:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 11 Jan 2001 12:16:02 +0100 (MET) Received: (qmail 16504 invoked by uid 0); 11 Jan 2001 11:06:03 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx22) with SMTP; 11 Jan 2001 11:06:03 -0000 X-eGroups-Return: sentto-1101623-1926-979211108-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 11 Jan 2001 11:05:14 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 11:05:07 -0000 Received: (qmail 21098 invoked from network); 11 Jan 2001 11:05:06 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Jan 2001 11:05:06 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 11 Jan 2001 12:06:11 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA27007; Thu, 11 Jan 2001 03:05:03 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P1CG; Thu, 11 Jan 2001 12:05:00 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D91EE.2A16C9C4@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 11:58:54 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] todo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 96e4199edafc02b1a7f9ff60d306cb0f Status: R X-Status: N hello,

here's a list of things that i have to do in the next days or weeks.
This way, you have a rough idea of what's going on...

- update the manual :
i have detected some flaws in my own patch (parts 1-3) and i have to
finish the other parts. New illustrations are to be done and some
chapters
must be written, then a new part (which ?) will be added.
It is a very high priority because it is more than 1 year old now
and it's the most lagging part of the project.
translation to french : Philippe has started, thanks.

- create a coherent design bundle. i have to update a lot of files
because the paths etc were completely messed up. it comes as #2.
A lot of work : apply/respect the qulity guidelines, verify everything
with different SW(/HW), make everything homogeneous and documented.
it will be packaged in a "F-CPU package".

- continue the lobbying : press, radio, industry... it's an everyday
work
(see below).

- from time to time i may update one or two files on the web, but it's
so heavy that it's very slow. Philippe Trbich has helped me update
f-cpu.org,
others can send me the files with the updates. it lightens up my
workload.
still seeking for someone ready to spend a lot of time on this subject.
shouldn't Paul mota be the first in the list ?

- radio : Charlie Nestel invites us in his program, several hours
will be necessary, so if you're around/in paris and want to speak about
your vision about the f-cpu, contact him.

- Conferences/showrooms : DATE2001, Oekonux, 18C3.

- execution units : INC will be redesigned (Erik ?...),
but the SHL unit is giving me some troubles.

- scheduler : it will be a new chapter in the manual, with some
schematics.

i may forget some things. As for the details, it takes 10 pages.
don't expect everything to work perfectly before 6 months...




Can the others share their todolist with us ?

YG
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Thu Jan 11 12:10:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04812 for ; Fri, 12 Jan 2001 03:01:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:37 +0100 (MET) Received: (qmail 8395 invoked by uid 0); 11 Jan 2001 11:16:38 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx10) with SMTP; 11 Jan 2001 11:16:38 -0000 X-eGroups-Return: sentto-1101623-1927-979211777-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 11 Jan 2001 11:16:30 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 11:16:15 -0000 Received: (qmail 46257 invoked from network); 11 Jan 2001 11:16:15 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 11 Jan 2001 11:16:15 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Jan 2001 11:16:15 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA27871; Thu, 11 Jan 2001 03:16:12 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P1C6; Thu, 11 Jan 2001 12:16:09 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D948C.6CB92CA5@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:10:04 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b5b4f334a570faccd079d588a364b1ca Status: R X-Status: N Ben Franchuk wrote:
> I think one still needs to concentrate on the memory <-> cpu interface.
a large part of the CPU is dedicated to that...

> It is not how fast one device can access memory but a group of devices
> sharing memory. One needs to SLOW down the fastest device to let others
> use the bus so why add the speed if not needed?.
> Bus latency can be got around I think if one can make
> it visible to the Software like delayed branches.A load instruction
> may specify that the value loaded can have #n cycles to complete rather
> than stall.(Note I have not checked the new manual to see if you do that
> now).
Delayed branches are bad, because the code needs to be deterministic.
the HW evolves and the latency varies a lot, whether it's in the cache,
the good line, the DRAM chip etc...

> Can one still assume that we have Random Access memory rather
> than a serial mess for regular data access?It may be useful to have
> segmented memory for I/O devices since small memory is cheap.
I/O is done through memory-mapped addresses or through the Special
Registers.
no need of segments. As for the (HW) nature of the I/O, it should be as
independent as possible from the SW.

but i wonder if i answered your question...

> Ben.
> PS. For a console for a proto-type F-CPU with all I/O features
> here a idea.
> http://www.angelfire.com/scifi/B205/paulj2.html
hmm nice, very 50's style :-) wow... booting by entering the
binary numbers by hand... yum :-P
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Thu Jan 11 12:14:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04818 for ; Fri, 12 Jan 2001 03:01:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:39 +0100 (MET) Received: (qmail 19063 invoked by uid 0); 11 Jan 2001 11:20:55 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx10) with SMTP; 11 Jan 2001 11:20:55 -0000 X-eGroups-Return: sentto-1101623-1928-979212037-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 11 Jan 2001 11:20:44 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 11:20:36 -0000 Received: (qmail 93762 invoked from network); 11 Jan 2001 11:20:36 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 11 Jan 2001 11:20:36 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Jan 2001 11:20:36 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA28130; Thu, 11 Jan 2001 03:20:33 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P1C9; Thu, 11 Jan 2001 12:20:31 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D9593.838F45F7@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:14:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4c66087a15121a4461c0cc93f8328629 Status: R X-Status: N Nicolas Matringe wrote:
>
> Nicolas Boulay wrote:
> >
> > Since the beginning, the fcpu have 2 links to the outside. 1,
> > low latencie, full speed 128 bits DDR-SDRAM or QDR-SDRAM to
> > access to the memory. 2, beside that there is a "link" to the
> > global system network to communicate with the other cpu and IO,
> > which is slower than the memory bus, because of the problem of
> > the number of pins.

that's fairly acurate :-)

> Hi
> I'm still worried about that. What happens when an IO device needs to
> transfer heaps of data to/from the memory? There has to be a direct link
> between the 2 busses (that's what the D stands for in DMA)
> Did I really miss something?
no...

there are several cases and solutions, but in the case i envision,
the physical address ranges are not the same for public and private
addresses. so you'll move the data by moving their physical location.
This can be done by HW or SW as you wish. The interface can be through
a dedicated SR or simply using a special instruction ( i recommend the
SR because it avoids all the nasty pipeline problems and it is more
scalable).

> Nicolas MATRINGE           IPricot European Headquarters
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Thu Jan 11 12:21:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04830 for ; Fri, 12 Jan 2001 03:01:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:42 +0100 (MET) Received: (qmail 20004 invoked by uid 0); 11 Jan 2001 11:27:44 -0000 Received: from cj.egroups.com (208.50.144.68) by 10.1.4.112 (mx12) with SMTP; 11 Jan 2001 11:27:44 -0000 X-eGroups-Return: sentto-1101623-1929-979212451-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 11 Jan 2001 11:27:42 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 11:27:30 -0000 Received: (qmail 19710 invoked from network); 11 Jan 2001 11:27:30 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 11 Jan 2001 11:27:30 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Jan 2001 11:27:30 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA28511; Thu, 11 Jan 2001 03:27:28 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P1DP; Thu, 11 Jan 2001 12:27:25 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D9731.64BC92A5@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <001c01c07b5a$98c27dd0$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:21:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e2fa2d7ba7bee68f916363ac650ff47 Status: R X-Status: N Marco Al wrote:
>
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
>
> > may specify that the value loaded can have #n cycles to complete rather
> > than stall.(Note I have not checked the new manual to see if you do that
> > now).
>
> They have a prefetch instruction you could use (load to register 0) although if
> you want to use it to compensate for memory latency you have to issue it many
> 10's of cycles early (probably 100+ for non local memory accesses if you use a
> single memory space for multiprocessor setups). Using a load instruction with a
> latency of 10's of cycles instead of the prefetch would IMO not be a good idea,
> with that kind of latency you have to have far too many load instructions in the
> pipeline.


In practice, a good scheduling for the F-CPU is to issue (code) the load
instruction
as soon as you know the address, and use the result (that is : the
register where
you put the memory data) as late as possible. Because of the scoreboard,
it avoids
some problems and it doesn't bloat your code/pipeline with prefetch
instructions.

The prefetch is here anyway and can be used, because there's no
dependency with reg 0.
in the FC0, it's something like a "side effect" that will ve useful for
later cores.

> From: "Jecel Assumpcao Jr" <jecel@merlintec.com>
> > Could someone please tell me why standard technologies aren't good
> > enough for the FCPU?
> Some of them are a little too generic, and some come at a hefty cost. And it
> just makes it easier for the patent owners to hunt you down :)
the latest news from opencollector.org say something similar,
but in the domain of the VME bus and AMBA (or something like that...).

>
> > I don't see the need for the G chip - just put in the memory interfaces
> > (north bridge, in PC speak) and one of the above in the CPU itself.
> I agree.

it's a problem of pin count. if you can afford the pins, it's ok,
but otherwise it 's /very/ expensive...

> Marco
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Thu Jan 11 12:38:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04842 for ; Fri, 12 Jan 2001 03:01:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:44 +0100 (MET) Received: (qmail 7249 invoked by uid 0); 11 Jan 2001 11:45:12 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx15) with SMTP; 11 Jan 2001 11:45:12 -0000 X-eGroups-Return: sentto-1101623-1930-979213481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 11 Jan 2001 11:45:11 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 11:44:40 -0000 Received: (qmail 68993 invoked from network); 11 Jan 2001 11:44:24 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 11 Jan 2001 11:44:24 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Jan 2001 11:44:24 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA29442; Thu, 11 Jan 2001 03:44:23 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P112; Thu, 11 Jan 2001 12:44:20 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D9B28.D4FEB845@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:38:16 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu project management Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 672745225bdd568b73eb369f305a6846 Status: R X-Status: N David Sullins wrote:
> Warning: long post from a lurker.
at last.
it's good to read new names...


> Hi, I've been checking up on the f-cpu list from time to time trying to
> decide when or if I should get involved.  Two things have kept me from
> jumping in so far:
> 1) laziness
> 2) lack of a central CVS repository
it's a matter of methods, too.
in my own personal culture, CVS is not necessarily a good thing,
but i hope that someone will help setup a repository at seul.org.
if someone wants to manage it, please apply here :-)))

> These are not unrelated.  CVS helps the lazy (like me) to quickly identify
> the latest version of anything so I don't have to hunt around a mailing
> list to find it.
although "digging" in the list archive might give you a certain
understanding
of the work and the what/whys...

>  I originally wanted to help test out the small bits of
> code that were already written, but it seemed too annoying always needing
> to figure out if I've got the latest version.
just hang out in the list :-) and apply so we know who to warn when
there's a change.

> Although this Grimes guy is obviously a troll, he makes some good points.
> Some things that he mentioned that might help the F-CPU project recruit
> more members (definitely something you could use):
... if we had more time...

It seems like others have more time and could have helped for the
organisation...


> 1) organized central way of getting/updating latest source and docs (CVS)
> This makes it easier for a new person to get up to speed on where the
> project is.  See above.

problem though : the electronics world DOESN'T work like in the SW
world.
you can't make a chip with partially working stuff. Any work on a unit
is
atomic : it starts and it is finished when it works and has been tested.
putting sources on the CVS would encourage the spreading of unfinished
and buggy files (even though this helps debug them).

> 2) milestones, goals, or at least a "to do" list
milestones ? heck...
goals ? it's been decided long ago. it's rather clear and we stick
rather
closely to it until now.

> This gives a new person a way to see what can be done.
it can start by RTFM, which is being updated currently
(Olivier Jean, Philippe Trbich and me. if you want to join the team....)

>  Right now the todo list includes just about everything,
that's fairly acurate :-)

> but if the project grows you'll be
> glad you have something like this.
i have some short-term goals and the details take 10 pages...
a fucking lot of details to make coherent in the manual, the websites
etc...

> 3) who is working on what
who wants to make a list ?

> This is related to #2.  Once you have a list of things to do, people can
> volunteer to be responsible for a certain part.
i think that it's not that easy in practice. often, it takes some
time for someone to find his role where he is in coherence with the
project.
it is usually a matter of months...

> 4) better mailing list management
heh.

> Has anyone ever tried to contact egroups and get control of the mailing
> list from whoever used to be in charge?  If not, can I?  I don't mind.
you can. but please be responsible : it's not an easy task.

> Another minor thing I'd like to mention is that I've noticed the use of
> language inappropriate for a group of engineers.  I'm no Miss Manners
> myself, but I try to keep my professional correspondence sounding
> professional.
there are not only professionals here, we're mostly humans too.
a bit of nettiquette helps, certainly. patience and self-control :
obviously
(but not everybody knows or understands that).

> I hope I've translated Mr. Grimes' troll-speak into a more helpful and
> reasonable set of suggestions.
i hope too. let's be adult.

have a nice day,

> -Helpful Dave
tired/busy YG
eGroups Sponsor
From Yann GUIDON Thu Jan 11 12:53:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04845 for ; Fri, 12 Jan 2001 03:01:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:46 +0100 (MET) Received: (qmail 6717 invoked by uid 0); 11 Jan 2001 12:00:24 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx07) with SMTP; 11 Jan 2001 12:00:24 -0000 X-eGroups-Return: sentto-1101623-1931-979214406-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hp.egroups.com with NNFMP; 11 Jan 2001 12:00:23 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 12:00:06 -0000 Received: (qmail 84858 invoked from network); 11 Jan 2001 12:00:05 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Jan 2001 12:00:05 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 11 Jan 2001 12:00:05 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA00439; Thu, 11 Jan 2001 04:00:03 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P118; Thu, 11 Jan 2001 13:00:01 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5D9ED5.25175855@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:53:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 48083a80ab1824181dfc044eba0a0357 Status: R X-Status: N Nicolas Boulay wrote:
> Some patchwork answer.
some quick irresponsible stuff...

> > I was just sugesting you to look at the idea of ATM networks.
> It has service like reserving a part of the bandwidth for communication between two points.
> Mmmh, it's a bad idea because of the very bad latency. Respond time is
> worst than a 100 Mega ethernet  switch, much too bad for us ( > 1ms !).
<wham> :-)

> > >That's why i said "in the best case". But remember that a 64 bit 133 Mhz
> > >run at 1Go/s so 8 gigabits links run at the same speed.
> > did you forget that i showed that it had more latency ?
> Yeah, that's the bill. But it's the only way to use less wire !
glups. so how come that around 64 bits/pins can do the same latency
(one with 64 parallel bits, the other with 8 pairs of dual differential
pins)
with one having 150 ns of latency, while the other can be as low as 10ns
?

> > > I would like to
> > >create something to optimise the transfert (my extended MMU).
> > do it and publish the draft, damnit !
> > but please don't use "magic words" but real physical
> > names for the units (ie : compare, register, add ... forget
> > words like "manager" or "handler" that don't mean anything)
> Ok, ok ! Could you give me an account to seul ?
i don't "give".
it's the work of Roger Dingledine from seul.org, the root of the cran
server.
i don't have his address at hand, but he sent a message on the mailing
list
a month ago... ask him gently, say that it's for the f-cpu project,
tell him your name, email address and your desired account name.
i'll be warned when your account opens and i'll symlink
your public_html directory from the f-cpu account. just don't forget
to chmod your ~/ and ~/public_html to 755 so it can be read from the
web.

http://f-cpu.seul.org/
has already some stuff from Michael, Olivier and me,
Nate has an account but hasn't chmoded yet AFAIK.


> > >Not really. Don't only think like SRAM READ, but you can make burst transfert like for COMA arch.
> > burst are fine, but when you want to transfer a simple semaphore,
> > it takes a lot of time for the setup (just like vector vs SIMD :
> > the time to fill the vector pipeline influences the performance)
> It will be explain in the draft. That's the story of the 4 algorythmes.
> 2 use pages. 2 use word.
i'm eager to read that...

> > >So the "true" bandwith between
> > >the memory and the network could be maximum in a one chip system. If you
> > >have 4 link by g-chip, 3 links speak to the same node but you have only
> > >the 1/3 to communicate to the node memories, but if you have one chip,
> > >it's easy to have 3 times the bandwith of the f-bus to the memory.
> >Fine but you forget about pin counts. And pin counts scales
> >with price too. not only chip price but PCB routing and layer number....
> Hmm, reread  me ! I want to use quick serial link to use less wire and
> decrease the number of pin used.
if you still use 8 differential and bidirectional pairs for each link,
it will use the same number of pins as the f-bus, while the latency will
remain high.

> > >The idea is to have a much higher bandwith for the link.
> > so it's more expensive and consumes more power !
> > in CMOS-like, if you  drive the signal 10x faster, you consume
> > 10x more. and your serial link is not going to use 1V signalling.
> You forget one very big point, you have 4 times less wire... (500 Mhz
> compare to 133Mhz for the same bandwith)
nope.
more latency, more clocking/wire issues, and only 2x less pins.

> > > In some year
> > >will come the 10 000base T, so maybe 10 Go/s will be possible ;p.
> > no. never. do NEVER believe peak rates.
> > you never burst a 10 billion bit stream .
> Why not ? It's plan, and it should work in few years ! And 80% of this,
> is good enought !
on a network, expect 50%...

> > >It isn't so simple. Topology is importante when you choose your
> > >algorithme for shared memory.
> > both are in the hands of the end user.
> > EOT.
> So you considere not to use HW acceleration (like for the
> extended-MMU-which-i-must-write-a-draft-about-it).
i'll consider integrating your stuff when i read the draft ;-)
it should be useful for as many cases as possible without
any complex colocked/scheduled stuff...

> > > You can choose to make it by SW (like
> > >SUN). Or by HW, so the network must be known. If you use mostly
> > >broadcast, a ring is fine (in a cube you lost a lot of bandwith), a
> > > point to point is quick, but you have to make some routing and you have
> > >to know were is a ressource !
> > fine. Prove me that you can't know where the ressources are.
> I not say that you can't find it. But that you need a location table
> somewhere. So it's some more unusefull communication on the system
> network.
but at least, you can make a multiported dedicated HW to hold the
table...

ok, i gotta eat...

> nicO
eGroups Sponsor
Click Here!
From Jeff Davies Thu Jan 11 13:14:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04851 for ; Fri, 12 Jan 2001 03:01:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:48 +0100 (MET) Received: (qmail 30443 invoked by uid 0); 11 Jan 2001 12:23:59 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx10) with SMTP; 11 Jan 2001 12:23:59 -0000 X-eGroups-Return: sentto-1101623-1932-979215808-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 11 Jan 2001 12:23:58 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 12:23:26 -0000 Received: (qmail 48383 invoked from network); 11 Jan 2001 12:23:25 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Jan 2001 12:23:25 -0000 Received: from unknown (HELO mail1.svr.pol.co.uk) (195.92.193.18) by mta3 with SMTP; 11 Jan 2001 13:24:30 -0000 Received: from modem-211.tin.dialup.pol.co.uk ([62.136.41.211] helo=llandre.freeserve.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14GglH-00068E-00 for f-cpu@egroups.com; Thu, 11 Jan 2001 12:23:23 +0000 Message-ID: <3A5DA3AC.ABAB6B06@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 12:14:36 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: ToDo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 175c2902e2e6c8a600377841c12a6841 Status: R X-Status: N Has anyone got an update to the following graphic which showed the ROP2
as ready, etc.
Perhaps someone could put this gif (the current version) on the front
page of www.f-cpu.org.

FC0-26_10_2000.gif

Go Michael!!!
Go YG!!!

Jeff Davies
eGroups Sponsor
Click here for Business information
Click here for Business information
From "Marco Al" Thu Jan 11 13:49:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04857 for ; Fri, 12 Jan 2001 03:01:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:49 +0100 (MET) Received: (qmail 19753 invoked by uid 0); 11 Jan 2001 12:42:42 -0000 Received: from c3.egroups.com (208.50.99.225) by 10.1.4.119 (mx19) with SMTP; 11 Jan 2001 12:42:42 -0000 X-eGroups-Return: sentto-1101623-1933-979216927-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 11 Jan 2001 12:42:41 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 12:42:06 -0000 Received: (qmail 18556 invoked from network); 11 Jan 2001 12:42:05 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 11 Jan 2001 12:42:05 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta3 with SMTP; 11 Jan 2001 13:43:10 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id NAA29119 for ; Thu, 11 Jan 2001 13:42:03 +0100 (MET) Message-ID: <003d01c07bcd$0030bc80$29e65982@student.utwente.nl> To: References: <3A5930AE.3DD011BA@jetnet.ab.ca> <001c01c07b5a$98c27dd0$29e65982@student.utwente.nl> <3A5D9731.64BC92A5@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 13:49:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fa7c66651bb26596ce64b1a9df9a406f Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>


> In practice, a good scheduling for the F-CPU is to issue (code) the load
> instruction
> as soon as you know the address, and use the result (that is : the
> register where
> you put the memory data) as late as possible. Because of the scoreboard,
> it avoids
> some problems and it doesn't bloat your code/pipeline with prefetch
> instructions.

You must have a pretty realistic estimation on the clock speed if you want to
bridge main memory latency through registers ;)

> there are several cases and solutions, but in the case i envision,
> the physical address ranges are not the same for public and private
> addresses.

That makes some sense for access by peripherals but for multiprocessing it seems
needlessly constricting, the MMU of the remote processor already takes care of
memory protection.

You could also specify that the remote nodes always have to take care of memory
protection, then if you want simplicity you could do the same coarse grained
check for 2 domains inside the chipset... but if you wanted to do something more
flexible you still could. Putting the choice with the user as you say :)

Marco
eGroups Sponsor
Click here for Business information
Click here for Business information
From Yann GUIDON Thu Jan 11 13:44:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04863 for ; Fri, 12 Jan 2001 03:01:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:51 +0100 (MET) Received: (qmail 5857 invoked by uid 0); 11 Jan 2001 12:50:57 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx04) with SMTP; 11 Jan 2001 12:50:57 -0000 X-eGroups-Return: sentto-1101623-1934-979217447-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 11 Jan 2001 12:50:53 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 12:50:46 -0000 Received: (qmail 22592 invoked from network); 11 Jan 2001 12:50:46 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 11 Jan 2001 12:50:46 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 11 Jan 2001 12:50:45 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA03764; Thu, 11 Jan 2001 04:50:44 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P12W; Thu, 11 Jan 2001 13:50:41 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5DAAB3.C1F8D2C1@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5DA3AC.ABAB6B06@llandre.freeserve.co.uk> From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 13:44:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: ToDo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 60db0ca8a07ef0d70d0eb57c32e19569 Status: R X-Status: N Jeff Davies wrote:
>
> Has anyone got an update to the following graphic which showed the ROP2
> as ready, etc.
> Perhaps someone could put this gif (the current version) on the front
> page of www.f-cpu.org.
>
> FC0-26_10_2000.gif
>
> Go Michael!!!
> Go YG!!!
>
> Jeff Davies

hi,
well, i should better use the updated drawing
(i have redrawn the GIF into EPS).
not many changes but it's a bit more acurate.

so, i have to color the boxes, make a bitmap,
and display it on f-cpu.org with a link to the files.
hey, give me the week-end... or send me the updated files,
so i only have to upload them on the server.
i'm not lazy, i'm too busy, it's the difference ;-)

YG
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Nicolas Matringe Thu Jan 11 14:04:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04872 for ; Fri, 12 Jan 2001 03:01:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:53 +0100 (MET) Received: (qmail 31388 invoked by uid 0); 11 Jan 2001 13:04:00 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx03) with SMTP; 11 Jan 2001 13:04:00 -0000 X-eGroups-Return: sentto-1101623-1935-979218194-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 11 Jan 2001 13:03:45 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 13:03:13 -0000 Received: (qmail 6951 invoked from network); 11 Jan 2001 13:02:45 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 11 Jan 2001 13:02:45 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 11 Jan 2001 13:02:45 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id NAA22498 for ; Thu, 11 Jan 2001 13:02:42 GMT X-To: Message-ID: <3A5DAF41.593D33BE@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 14:04:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8704eb83c5ae0fb6461a69cba678dc74 Status: R X-Status: N Yann GUIDON wrote:

> there are several cases and solutions, but in the case i
> envision, the physical address ranges are not the same for
> public and private addresses. so you'll move the data by moving
> their physical location.

I don't understand what you mean. How do you move the physical location?
You can't pick up the chips, you know? ;o)
--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
eGroups Sponsor
Click here to subscribe.
Click here to subscribe.
From Yann GUIDON Thu Jan 11 14:34:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04884 for ; Fri, 12 Jan 2001 03:01:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:01:55 +0100 (MET) Received: (qmail 16657 invoked by uid 0); 11 Jan 2001 13:41:33 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx10) with SMTP; 11 Jan 2001 13:41:33 -0000 X-eGroups-Return: sentto-1101623-1936-979220465-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 11 Jan 2001 13:41:32 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 13:41:03 -0000 Received: (qmail 420 invoked from network); 11 Jan 2001 13:41:02 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 11 Jan 2001 13:41:02 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 11 Jan 2001 13:41:02 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA07500; Thu, 11 Jan 2001 05:41:01 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77P1QD; Thu, 11 Jan 2001 14:40:59 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5DB66F.53FC5744@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 14:34:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ebbb237e4184ea46449639eb9b2a417 Status: R X-Status: N Nicolas Matringe wrote:
>
> Yann GUIDON wrote:
>
> > there are several cases and solutions, but in the case i
> > envision, the physical address ranges are not the same for
> > public and private addresses. so you'll move the data by moving
> > their physical location.
>
> I don't understand what you mean. How do you move the physical location?
> You can't pick up the chips, you know? ;o)

ooops, i meant : make a memcpy... when you're in kernel mode.
otherwise, if you're a user task, ask the OS to do it for you,
that is : to remap your "logical" address (corresponding to the block)
to another physical location (sorry : address range)
where you access the data faster or slower.

hmmm i wonder if this answers your first question...
but this boils down to making a memcpy. it can be done in HW or SW.

> Nicolas MATRINGE
YG
eGroups Sponsor
Click here to Win a 2001 Acura MDX
Click here to Win a 2001 Acura MDX
From Yann GUIDON Thu Jan 11 17:15:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04935 for ; Fri, 12 Jan 2001 03:02:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:07 +0100 (MET) Received: (qmail 23673 invoked by uid 0); 11 Jan 2001 16:33:56 -0000 Received: from mo.egroups.com (208.50.144.78) by 10.1.4.112 (mx12) with SMTP; 11 Jan 2001 16:33:56 -0000 X-eGroups-Return: sentto-1101623-1938-979230719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 11 Jan 2001 16:32:25 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 16:31:59 -0000 Received: (qmail 23708 invoked from network); 11 Jan 2001 16:21:46 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 11 Jan 2001 16:21:46 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Jan 2001 16:21:46 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA24528; Thu, 11 Jan 2001 08:21:44 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PFDB; Thu, 11 Jan 2001 17:21:42 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5DDC28.18084F40@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 17:15:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's go back to the rock ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2bb668bfc1aac949bb13f0825f4ff889 Status: R X-Status: N Nicolas Boulay wrote:
> > >> Yep.  Very common when (simple) COMA is used, IIRC.
> > >>
> > >In NORMA arch, too, no ?
> >
> > but i don't care about your norma, coma, IIRC etc ...
> > we should speak about the core... damnit...
>
> Let's go ;p

ahhhh !!

that's good...

>
> I would speak about some feature of the core. It's a "discussion" about
> how make a cpu whish is easy to   expand (Or how make Pentuim IV more
> easy and simple when you come from the 8088). Or how to make easly fc1,
> fc2,...

FC0 is rather ok, i think it can survive in the next years,
with some known techniques it will maybe scale to 2, 3 or 4 instructions
per cycle but it will look like a 'modified' Alpha 21164.

I guess that we better start FC1 when when we want to increase the
decoding
bandwidth. that is : when FC0 works and someone proposes to decode more
instruction per cycle, the project could split : one way will extend
the FC0 to make a FC0-2 or FC0-4 (doing like a superscalar CPU but
without
some of the advantages of FC0 like fast jump, because register dependecy
tests
will make decoding longer). The other way will make FC1, seeking an
alternate way
to redesign the core, investigating new scheduling stuffs.

I don't see that happening before ... 2 years ?
Anyway, it will be also the right time to add some extensions to the ISA
(specifically : PFQ-based instructions).

> If you look to the athlon pipeline you will see around 12 or 14 stage.
around 20 for P4... scary...

> But only one for the ALU, all other was for scheduling, register
> renaming and all that kind of stuff. So silicon are mainly used for
> scheduling (to know which instruction to execute) than for calculing.
heh.

> Athlon and PIV are design to perfome the same operation 3 time per clock
> tick (they have 3 alu, 3 fpu,...). But they want to xlr8 the old code,
> too. And dependancies between register made that you can't speed up code
> by just having a scorebord. You need register renaming and all that
> stuff, to really have 3 intructions run in the same time.
just compute : you want 3 op/c, with a latency of at least 3 cycles,
this means a minimum of 9 registers. there are only 7 useable regs...
x86 is dead. Vive le F-CPU !

> The probleme came when you want to speed up old binaries. Pentuim use 2
> decoder, but Pentuim pro have 3 but can excute only one complex
> instruction (memory to memory,...) and 2 "simple" RISC-like instruction.
> So the programming rules changes and the "true" speed up is less evident
> (or why some time a pentuim MMX could outperforme a PIII).
i tested it myself, my P200MMX ran faster than a PII-266 with a code
that
is optimized for the PMMX.
If you can correctly pair instructions for the PMMX, you can kill
PII's performace because the rules are completely different.

> To increase the speed of a cpu, you could increase the clock
> frequencies. That's easy but you add depencies problemes with long
> pipeline (20 for PIV more for the FCPU ?).
there is also the fact that you can't go below a certain minimal
granularity.
We have pipelined the adder, Intel did this too, but we can't go much
below because
we hit some realities : number of FF/number of gates...

> You can try to execute
> differente type of instruction in the same time (ALU, load&store). It's
> just a little more decode, the unit are soon here.
that's what ALPHA did. one alu, one l/s. then, for the 164, 2ALU, 2L/S.
today they decode 4 instructions and perform 2L/S (3 ?), 2 int and 2 FP.
IIRC. and they kill some other chips.

> And then, you can add
> some more unit like an ALU. Here, is the problem, how could we expect to
> increase speed linearly compare to the number of unit?
with a good decoding scheme. that's why even though Intel blew up the
P4,
they found a good way to bypass the x86's sucking opcode formats.

> How can we broke depencies soon increase by the deep pipeline (true
> dependence are now around 10 instructions or even more) ?
the FC0 is a way to do this. a 2-way superscalar FC0 ("FC0-2")
will require some rework of the decoder/scheduler, a 5r3w R7,
a larger scoreboard, another L/SU but that's all...
a FC0-4 would have 2 symmetrical FC0-2 and a big pre-decoder
that will handle the register dependencies. that's the "evolutionary
way".
we'll have to make some stronger coding rules, a big instruction
reorderer and analyse the possibility of a pseudo-VLIW encoding.
above 4 ipc, we need something else : FC1. there, we can study anything.


> Scorebording
> is the easy and first step to do it, but if there is to much depencies
> the code will as slow as befor.
dunno. we have 63 regs, we can do 3 pipelines with 8 stages, or 4
pipelines
with 5 stages (execution pipeline, of course). it gives us enough time
before we require more physical registers.

> Big register bank could help to broke depencies.
but what about the logical number ? how does the SW manage that ?
explicit register renaming is a possibility but it has not been a
studied
feature... yet ...

> But it's always a limit
> put in the design. SIMD parrallelism are maybe a good way to increase
> speed.
not "speed" but MHz/MOPS ratio. we're safe from this POV.
SIMD algos are studied for 20 years now...

> If you can really double the size of this register, and the code
> always work, you could be close to double your speed in your calcul
> intensive task. But the compiler and the coding rules could be hard to
> write and follow.
i explained you a way to do that : use a "vectoring" compiler,
that can recognize vector coding. then, each time it detects a vector
loop,
it splits the vector into "registers" of N chucks, N is not known in
advance.
then for each loop iteration it performs N operations, depending on the
implementation. it is not extremely straightforward to implement,
but it is not impossible.
btw, there's no particular pragma or keyword to describe a vector loop
in C.
i don't want to program in Fortran either ;-)

> An other means could be used is the SMT technologies.
yup but we're not mature yet.

> Having virtualy
> few processors but using the same hardware.  You just make a cpu with an
> enormous pipeline (why not 100 stages).
no need for so much.

> And for each new instruction you
> take an instruction from an other thread. It's like having a true SMP
> system with 4, 8, 16 or 32 slower processors.
except that it is easier and cheaper.
FC0's execution pipeline could be used but the decoder would require
a certain amount of rework.

> So you have some different
> register banks. With that you broke pipeline depencies a lot. Some
> people would break the memory latencies, too. It's a good idea, but a
> cache miss cost around 150 cycles.
and 1500 if you use a serial link ;-PPP

> So you need to have a lot of thread
> (-> very difficult to write the code)
nope if you hit the OS' scheduler.
and i don't want of the "microtasks" ...

> or having a complex scheduling
> unit to know wich thread could be executed, with the big risk to
> recreate register depencies.
the OS kernel is the best place to do this.

> So there are lot of problem. The worst is to write a good compiler for
> that. How could it be easy to add some thread capabilities ?
the SMT side should be managed by the OS.
If you see a usual UNIX server that handles lots of connexions,
you see that it's the good place.

> You could
> excute 4 threads and what happen to the code with 8 or 16 ?
don't do that in HW, you just found one good argument :-)

> With such
> big pipeline, the speed reach by the processor could became fabulous (5
> or 6 GHz with today technologies !) and the cache memory must follow.
nope. cache is always late.

> But by adding some more pipeline stage, maybe we can solve the problem
> ;p
i don't believe this... look at the latest SPARC, where they use wave
pipelining
(the clock is slightly higher than the latency...)


> In the other hand i have read in comp.arch, that there is a very strong
> dependancies on the stack pointer. Without this dependancy, the true ILP
> of lot of program could reach 100 or more. This imply to develop a new
> way to make function call to avoid such depencies. But 100 compare to
> the usual number of 3 is to much to be forgotten (for GCC).
burn C/GCC, burn ! :-)


> I like very much to take a few a lot of different thing to speed up our
> design. So few SIMD spec, few SMT, few vliw (at the very beginning
> having a pair rules to the instruction). But we always have the problem
> to have a good compiler to handle all that new stuff.
i don't think it's really the main problem.
the problem is to find the time to do it.
I have the ideas and i'm not alone in this subject : Cedric is learning
some stuffs, Jeff is in the train, and Ingo has joined.
i'm sure that something good will appear.

> I know that some people would say that we haven't soon one little FC0
> BUT things made for the 8088 are  always inside the P4, ...
i know, i know, that's what this list is for...

> nicO
YG
eGroups Sponsor
From Andreas Romeyke Thu Jan 11 17:33:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04947 for ; Fri, 12 Jan 2001 03:02:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:11 +0100 (MET) Received: (qmail 32476 invoked by uid 0); 11 Jan 2001 16:37:41 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 11 Jan 2001 16:37:41 -0000 X-eGroups-Return: sentto-1101623-1939-979231025-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 11 Jan 2001 16:37:29 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 16:37:05 -0000 Received: (qmail 59492 invoked from network); 11 Jan 2001 16:28:31 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 11 Jan 2001 16:28:31 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta1 with SMTP; 11 Jan 2001 16:28:30 -0000 Received: from it-netservice.de (dev-gate.intern.itns.de [192.168.2.2] (may be forged)) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id RAA08107; Thu, 11 Jan 2001 17:29:05 +0100 Sender: art1@mail.it-netservice.de Message-ID: <3A5DE054.42C4EB29@it-netservice.de> Organization: free member of GAOS X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: de, en To: f-cpu@egroups.com Cc: Kay Pruefer , Udo Stenzel From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 17:33:24 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Support from GAOS? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: ed251e061a1bfe6c2638eaf9659406ca Status: R X-Status: N Hello,

I am Andreas Romeyke and I want to work in f-cpu-development (more in
the other mail). I am also a member of GAOS (means: Association for Free Application Systems and Technologies, in german: Gesellschaft f=FCr die
Anwendung offener Systeme e.V.).

The GAOS was founded by Leipziger Linux User Group (Lug-L) in 1999 to
extend the support for free technologies like Linux User Groups for
Linux does.
We are a lot of enthusiastic (german) members and interested in
practical realizations in the ideas of open source.
"Free" and "open source" is meant by us that technologi= es are public and
free available, open in source and with free interfaces like definition
of the Debian-project.

We want to support you, because two members of us were in contact with
F-CPU-member (Yann?) in december 2000 (17C3). I am also interested in
F-CPU-Project, so we had a little discussion on our last meeting, so we
decided to contact you.

We cannot support you with details in VHDL (with exception of me,
later...) and CPU-design, but in contacts, media, ideas, documentation,
organisation and so on.

We suggests you to maintain your mailinglist, in detail, there is no
problem for us to create a mailinglist based on Gnu mailman for the
F-CPU-Project if needed.

We are planned to organise a test-computer with a lot of RAM, but we
cannot guaranted that at the moment. But there will be not a problem to
accomodate this or an another one with permanent internet availability.

We arrange monthly lectures in cooperation with the MPI
(Max-Planck-Institute of Cognitive Neuroscience), so we want to invite
you to make a presentation of F-CPU-project.

Thats were our suggestions, how we can support you also in other ways?

If you have any questions, please do not hesitate to contact me under
art1@it-netservice.de

Thanks

Bye Andreas

PS.: Further information about GAOS e.V.: http= ://gaos.org.
eGroups Sponsor=
3D"Click
From Andreas Romeyke Thu Jan 11 18:14:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04962 for ; Fri, 12 Jan 2001 03:02:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:14 +0100 (MET) Received: (qmail 16654 invoked by uid 0); 11 Jan 2001 17:21:06 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx21) with SMTP; 11 Jan 2001 17:21:06 -0000 X-eGroups-Return: sentto-1101623-1940-979233621-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 11 Jan 2001 17:21:02 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 17:20:13 -0000 Received: (qmail 75414 invoked from network); 11 Jan 2001 17:09:06 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 11 Jan 2001 17:09:06 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta3 with SMTP; 11 Jan 2001 18:10:11 -0000 Received: from it-netservice.de (dev-gate.intern.itns.de [192.168.2.2] (may be forged)) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id SAA11351 for ; Thu, 11 Jan 2001 18:09:41 +0100 Sender: art1@mail.it-netservice.de Message-ID: <3A5DE9D8.C3D29D89@it-netservice.de> Organization: free member of GAOS X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: de, en To: "f-cpu@egroups.com" From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 18:14:00 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FCPU-Newbie... questions to VHDL-compiler, TODO-list... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 43198a91e19e35987ce8141e177603c5 Status: R X-Status: N Hello,

my name is Andreas Romeyke and I want to join the f-cpu-team.
I am a student at university of applied science Leipzig and there was my
first contact with VHDL and CPU/Logic-Design. I have some experiences
with C++ and Perl. For VHDL and logic-design I used the ALTERA
BaselineMaxII system, but that is not the right tool to compile the
f-cpu-sources.

In last weeks I have tried to use vaul, freehdl, savant and alliance,
but there are some problems. Can you help me, which free or commercial
compilers, simulators are ready to use?

FreeHDL and Savant compiles good, the VHDL-Compiler works well and
produced C++-output, but both have problems, if I want compile the
translated VHDL-Code for testing (one needs an VHDLKernel.hh, the other
i have forgotten...)

ALTERA cannot be used, because there are  problems with size of my
student version...

Any hints?

Ok. Thats my problems at the moment. My next question is, what is todo
in f-cpu, what should be coded in VHDL (as first step, not too
complicated, because I need a period of vocational adjustment)?

Bye Andreas
eGroups Sponsor
Click Here!
From Yann GUIDON Thu Jan 11 18:20:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04968 for ; Fri, 12 Jan 2001 03:02:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:15 +0100 (MET) Received: (qmail 12745 invoked by uid 0); 11 Jan 2001 17:40:15 -0000 Received: from unknown (HELO fj.egroups.com) (64.211.240.231) by mx0.gmx.net (mx17) with SMTP; 11 Jan 2001 17:40:14 -0000 X-eGroups-Return: sentto-1101623-1941-979234732-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fj.egroups.com with NNFMP; 11 Jan 2001 17:39:46 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 17:38:52 -0000 Received: (qmail 41231 invoked from network); 11 Jan 2001 17:27:05 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 11 Jan 2001 17:27:05 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 11 Jan 2001 17:27:05 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA03312; Thu, 11 Jan 2001 09:27:02 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PFJV; Thu, 11 Jan 2001 18:26:59 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5DEB72.12BC5E6C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 18:20:51 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f4751688df6b292669a106534253f168 Status: R X-Status: N Nicolas Matringe wrote:
>
> Yann GUIDON wrote:
> >
> > Nicolas Matringe wrote:
>
> > > I don't understand what you mean. How do you move the physical
> > > location? You can't pick up the chips, you know? ;o)
> > ooops, i meant : make a memcpy... when you're in kernel mode.
> > otherwise, if you're a user task, ask the OS to do it for you,
> > that is : to remap your "logical" address (corresponding to the
> > block) to another physical location (sorry : address range)
> > where you access the data faster or slower.
>
> So you mean the data remain in the IO device and the CPU accesses them
> through some kind of address translator? Doesn't make much sense I
> think. This would require big amounts of memory to be embedded in the
> devices.
> Or would it use an external DMA, like with the ISA bus?
>
> Nico (the other one)

I think that i have merded.
the "address translator" is the TLB that is used to translate
the "logic addresses" seen by a user task, to "physical"addresses
understood by the HW. at the user level, nothing to worry.
at the low level, you can move with L/S instructions or with a "DMA"
(a simple machine) but due to the coherency troubles,
it is required that the data go through the LSU.
So the DMA will simply be a dual address generator that steals
cycles to the user SW.

did i merde again this time ?
...
eGroups Sponsor
Click here!
From Yann GUIDON Thu Jan 11 18:29:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04977 for ; Fri, 12 Jan 2001 03:02:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:17 +0100 (MET) Received: (qmail 32365 invoked by uid 0); 11 Jan 2001 17:47:43 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx22) with SMTP; 11 Jan 2001 17:47:43 -0000 X-eGroups-Return: sentto-1101623-1942-979235242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 11 Jan 2001 17:47:39 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 17:47:22 -0000 Received: (qmail 84806 invoked from network); 11 Jan 2001 17:35:37 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 11 Jan 2001 17:35:37 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 11 Jan 2001 17:35:37 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA04523; Thu, 11 Jan 2001 09:35:35 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PFK4; Thu, 11 Jan 2001 18:35:32 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5DED75.B7AC1AC7@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5DE9D8.C3D29D89@it-netservice.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 18:29:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FCPU-Newbie... questions to VHDL-compiler, TODO-list... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 428bc1fc8690bb716d0a1cd28d0dfcd7 Status: R X-Status: N Andreas Romeyke wrote:
>
> Hello,
>
> my name is Andreas Romeyke and I want to join the f-cpu-team.
i have seen your other mail about GAOS.
nice to meet people that cam to the 17C3 :-)))

> I am a student at university of applied science Leipzig and there was my
> first contact with VHDL and CPU/Logic-Design. I have some experiences
> with C++ and Perl. For VHDL and logic-design I used the ALTERA
> BaselineMaxII system, but that is not the right tool to compile the
> f-cpu-sources.

at least you can play with some separate units...

> In last weeks I have tried to use vaul, freehdl, savant and alliance,
> but there are some problems. Can you help me, which free or commercial
> compilers, simulators are ready to use?

we use simili (http://www.symphonyeda.com/) with win32,
and some people can access Leonardo Spectrum or other tools.
I have access to certain professional HW and SW but it's another story
:-)
Cadence proposed free licences recently, you can apply.

> FreeHDL and Savant compiles good, the VHDL-Compiler works well and
> produced C++-output, but both have problems, if I want compile the
> translated VHDL-Code for testing (one needs an VHDLKernel.hh, the other
> i have forgotten...)
>
> ALTERA cannot be used, because there are  problems with size of my
> student version...
>
> Any hints?

if you have Windows, give Simili a try for small designs.
very simple and it works.

> Ok. Thats my problems at the moment. My next question is, what is todo
> in f-cpu,
a lot :-)

> what should be coded in VHDL (as first step, not too
> complicated, because I need a period of vocational adjustment)?

we need a good SIMD multisize shift/rotate unit. look at the manual for
some of the details. my last tries gave something like a 3-level Omega
network
of 4->4 bit shufflers. the decoding part is even harder but worth the
work.

other contributions required : website management (who wants to be
webmaster ?)
manual foolproofer, CVS maintainer... you can read the list in some of
the latest
20 messages :-)

have fun, YG
> Bye Andreas
eGroups Sponsor
Click Here!
From Ben Franchuk Thu Jan 11 08:38:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04989 for ; Fri, 12 Jan 2001 03:02:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:20 +0100 (MET) Received: (qmail 23572 invoked by uid 0); 11 Jan 2001 18:39:49 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by 10.1.4.119 (mx19) with SMTP; 11 Jan 2001 18:39:49 -0000 X-eGroups-Return: sentto-1101623-1943-979238255-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 11 Jan 2001 18:38:04 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 18:37:34 -0000 Received: (qmail 11792 invoked from network); 11 Jan 2001 18:25:07 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Jan 2001 18:25:07 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 11 Jan 2001 18:25:07 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA19094 for ; Thu, 11 Jan 2001 11:19:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A5D62FD.CF871673@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5DE9D8.C3D29D89@it-netservice.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 00:38:37 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FCPU-Newbie... questions to VHDL-compiler, TODO-list... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dc648b2c3f209170b11a24a98c903913 Status: R X-Status: N Andreas Romeyke wrote:
>
> Hello,
>
> my name is Andreas Romeyke and I want to join the f-cpu-team.
> I am a student at university of applied science Leipzig and there was my
> first contact with VHDL and CPU/Logic-Design. I have some experiences
> with C++ and Perl. For VHDL and logic-design I used the ALTERA
> BaselineMaxII system, but that is not the right tool to compile the
> f-cpu-sources.
> ALTERA cannot be used, because there are  problems with size of my
> student version...
>


Right now I am doing FPGA design using schematic entry for a ALTERA
10k10 chip for my own tiny cpu. I like schematics because you see what
you get.
If in moment of total insanity I decide to create the B-CPU (The Bad Cpu).
This is the F-CPU several small FPGA's with several hundreds of pages of
schematics,
and slower speed (no pipelining). Assuming the BUS configuration is similar to
the 'REAL' F-CPU does my (fictional) B-CPU implementation make a Valid F-CPU or
is there specific hardware standards that have to be met?

Ben.



--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Gregory Junker Thu Jan 11 20:41:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04995 for ; Fri, 12 Jan 2001 03:02:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:22 +0100 (MET) Received: (qmail 7064 invoked by uid 0); 11 Jan 2001 19:55:25 -0000 Received: from unknown (HELO ef.egroups.com) (64.211.240.229) by mx0.gmx.net (mx01) with SMTP; 11 Jan 2001 19:55:25 -0000 X-eGroups-Return: sentto-1101623-1944-979242838-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 11 Jan 2001 19:54:32 -0000 X-Sender: gjunker@one.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 19:53:57 -0000 Received: (qmail 42071 invoked from network); 11 Jan 2001 19:41:46 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 11 Jan 2001 19:41:46 -0000 Received: from unknown (HELO mail1.one.net) (206.112.192.107) by mta1 with SMTP; 11 Jan 2001 19:41:46 -0000 Received: from shell.one.net ([206.112.192.106] EHLO shell.one.net ident: IDENT-NOT-QUERIED [port 41992]) by mail.one.net with ESMTP id <845996-503>; Thu, 11 Jan 2001 14:41:39 -0500 Received: from localhost (gjunker@localhost) by shell.one.net (8.9.3/8.9.3) with ESMTP id OAA08602 for ; Thu, 11 Jan 2001 14:41:32 -0500 X-Authentication-Warning: shell.one.net: gjunker owned process doing -bs To: f-cpu@egroups.com In-Reply-To: <3A5DED75.B7AC1AC7@mentor.com> Message-ID: From: Gregory Junker MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 14:41:37 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FCPU-Newbie... questions to VHDL-compiler, TODO-list... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 57531a11a5d4a42d3f3edbc4d0f74177 Status: R X-Status: N > other contributions required : website management (who wants to be
> webmaster ?)

does the site have to be in or on a particular place/nation/continent? The
reason I ask is I have dedicated bandwidth to offer, and whatever server
hardware is needed for http, ftp, cvs, dns, email/list, whatever is
required. The hardware would be located in the U.S. midwest (think Alsace
without the wine). Access for the principals, and as soon as I get my
Electronics Workbench licenses I might even start in on the VHDL...after
all, it would be a waste of a good Computer Engineering degree on simple
software development :)

> manual foolproofer, CVS maintainer... you can read the list in some of
> the latest
> 20 messages :-)
eGroups Sponsor
Click here!
From Michael Riepe Thu Jan 11 17:21:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04998 for ; Fri, 12 Jan 2001 03:02:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:23 +0100 (MET) Received: (qmail 29927 invoked by uid 0); 11 Jan 2001 20:28:23 -0000 Received: from ck.egroups.com (208.50.144.69) by 10.1.4.111 (mx11) with SMTP; 11 Jan 2001 20:28:23 -0000 X-eGroups-Return: sentto-1101623-1945-979244870-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 11 Jan 2001 20:28:21 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 20:27:49 -0000 Received: (qmail 54046 invoked from network); 11 Jan 2001 20:17:40 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 11 Jan 2001 20:17:40 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.92) by mta1 with SMTP; 11 Jan 2001 20:17:38 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00832; Thu, 11 Jan 2001 17:21:02 +0100 Message-ID: <20010111172102.42866@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A5DBA0C.BE1ACC7D@IPricot.com>; from Nicolas Matringe on Thu, Jan 11, 2001 at 02:50:04PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 17:21:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] F Cpu Information Interface. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: df8b3f64237d40cda3218c4888e0d3b1 Status: R X-Status: N On Thu, Jan 11, 2001 at 02:50:04PM +0100, Nicolas Matringe wrote:

> So you mean the data remain in the IO device and the CPU accesses them
> through some kind of address translator? Doesn't make much sense I
> think. This would require big amounts of memory to be embedded in the
> devices.
> Or would it use an external DMA, like with the ISA bus?

This is going to become much too complex...

IIRC, peripherals are connected to the G-chip (memory mapped).  The F-CPU
can read/write to/from them via the F-bus (register <-> global memory).

For "direct" memory access (which is the wrong term since the DRAM is
CPU-private) the G-chip will need a DMA (or DTA -- data transfer engine)
that reads data from the I/O device and pushes it down the F-bus (or
vice versa), and a similar engine inside the CPU that transfers data
between the F-bus and the local RAM, and also updates or invalidates
D-cache lines on the fly (to maintain cache consistency).

For more complex topologies, the G-chip must also be able to transfer
data from one F-bus interface to another, and maybe from (G-chip-)local
memory to (G-chip-)local memory (where local memory may be memory mapped
I/O in either case).

Or am I completely wrong?
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
From Michael Riepe Thu Jan 11 15:33:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05001 for ; Fri, 12 Jan 2001 03:02:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:24 +0100 (MET) Received: (qmail 29407 invoked by uid 0); 11 Jan 2001 20:30:47 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx13) with SMTP; 11 Jan 2001 20:30:47 -0000 X-eGroups-Return: sentto-1101623-1946-979245035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 11 Jan 2001 20:30:44 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 20:30:34 -0000 Received: (qmail 32088 invoked from network); 11 Jan 2001 20:19:24 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Jan 2001 20:19:24 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.92) by mta1 with SMTP; 11 Jan 2001 20:19:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00579; Thu, 11 Jan 2001 15:33:47 +0100 Message-ID: <20010111153347.49057@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5D91EE.2A16C9C4@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A5D91EE.2A16C9C4@mentor.com>; from Yann GUIDON on Thu, Jan 11, 2001 at 11:58:54AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 15:33:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] todo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0d19ff4528496590281dfe9e7b51580 Status: R X-Status: N On Thu, Jan 11, 2001 at 11:58:54AM +0100, Yann GUIDON wrote:

> - execution units : INC will be redesigned (Erik ?...),
> but the SHL unit is giving me some troubles.

What kind of troubles?  Please think louder ;)

[...]
> Can the others share their todolist with us ?

1. pipelined EU_ASU
2. design and implementation of EU_IDU (integer divide unit)
3. whatever comes next...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Michael Riepe Thu Jan 11 16:50:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05004 for ; Fri, 12 Jan 2001 03:02:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:25 +0100 (MET) Received: (qmail 19689 invoked by uid 0); 11 Jan 2001 20:31:13 -0000 Received: from unknown (HELO fj.egroups.com) (64.211.240.231) by mx0.gmx.net (mx07) with SMTP; 11 Jan 2001 20:31:13 -0000 X-eGroups-Return: sentto-1101623-1947-979245045-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 11 Jan 2001 20:31:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 20:30:45 -0000 Received: (qmail 85015 invoked from network); 11 Jan 2001 20:19:22 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 11 Jan 2001 20:19:22 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.92) by mta1 with SMTP; 11 Jan 2001 20:19:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00748; Thu, 11 Jan 2001 16:50:56 +0100 Message-ID: <20010111165056.60176@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5D9B28.D4FEB845@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A5D9B28.D4FEB845@mentor.com>; from Yann GUIDON on Thu, Jan 11, 2001 at 12:38:16PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 16:50:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] f-cpu project management Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 66a0aba97ccf8c3ae63bb9e9715e822f Status: R X-Status: N On Thu, Jan 11, 2001 at 12:38:16PM +0100, Yann GUIDON wrote:
> David Sullins wrote:
[...]
> > Hi, I've been checking up on the f-cpu list from time to time trying to
> > decide when or if I should get involved.  Two things have kept me from
> > jumping in so far:
> > 1) laziness
> > 2) lack of a central CVS repository
> it's a matter of methods, too.
> in my own personal culture, CVS is not necessarily a good thing,
> but i hope that someone will help setup a repository at seul.org.
> if someone wants to manage it, please apply here :-)))
[...]

As far as I have seen, seul.org does already have a central repository,
including pserver (cran is aliased as cvs.seul.org).  We only need a
top-level directory with proper write permissions (for user/group f-cpu).

On the other hand, CVS will not necessarily the latest versions.  Since
I'm not online 24/7, I work with a local repository and I'll update the
central (remote) one only sporadically.  I could also tar/gzip my tree
and put it on an FTP or HTTP server, like I do now.

In fact, I don't like working with remote CVS at all, but I already
mentioned that.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click here to subscribe.
Click here to subscribe.
From Nicolas Boulay Thu Jan 11 21:56:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05016 for ; Fri, 12 Jan 2001 03:02:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:28 +0100 (MET) Received: (qmail 18977 invoked by uid 0); 11 Jan 2001 21:01:00 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx04) with SMTP; 11 Jan 2001 21:01:00 -0000 X-eGroups-Return: sentto-1101623-1948-979246840-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 11 Jan 2001 21:00:53 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 21:00:40 -0000 Received: (qmail 98884 invoked from network); 11 Jan 2001 20:49:27 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 11 Jan 2001 20:49:27 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 11 Jan 2001 20:49:26 -0000 Received: from ifrance.com (nas14-89.vlt.club-internet.fr [195.36.164.89]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA14050 for ; Thu, 11 Jan 2001 21:49:20 +0100 (MET) Message-ID: <3A5E1DEB.719AF9CE@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 21:56:11 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's go back to the rock ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6def04e2804d19e27ca4f3aded237c63 Status: R X-Status: N Yeeeeeeeeeeeeeeeehaaaaaaaaaaaaaaaaaaaaa ! [D=E9sol=E9]

Yann GUIDON a =E9crit :
>
> Nicolas Boulay wrote:
> > > >> Yep.  Very common when (simple) COMA is used, = IIRC.
> > > >>
> > > >In NORMA arch, too, no ?
> > >
> > > but i don't care about your norma, coma, IIRC etc ...
> > > we should speak about the core... damnit...
> >
> > Let's go ;p
>
> ahhhh !!
>
> that's good...
>
> >
> > I would speak about some feature of the core. It's a "discus= sion" about
> > how make a cpu whish is easy to   expand (Or how make P= entuim IV more
> > easy and simple when you come from the 8088). Or how to make easl= y fc1,
> > fc2,...
>
> FC0 is rather ok, i think it can survive in the next years,
> with some known techniques it will maybe scale to 2, 3 or 4 instructio= ns
> per cycle but it will look like a 'modified' Alpha 21164.
>
> I guess that we better start FC1 when when we want to increase the
> decoding
> bandwidth. that is : when FC0 works and someone proposes to decode mor= e
> instruction per cycle, the project could split : one way will extend > the FC0 to make a FC0-2 or FC0-4 (doing like a superscalar CPU but
> without
> some of the advantages of FC0 like fast jump, because register depende= cy
> tests
> will make decoding longer). The other way will make FC1, seeking an > alternate way
> to redesign the core, investigating new scheduling stuffs.
>
> I don't see that happening before ... 2 years ?
> Anyway, it will be also the right time to add some extensions to the I= SA
> (specifically : PFQ-based instructions).
>
> > If you look to the athlon pipeline you will see around 12 or 14 s= tage.
> around 20 for P4... scary...
>
> > But only one for the ALU, all other was for scheduling, register<= BR> > > renaming and all that kind of stuff. So silicon are mainly used f= or
> > scheduling (to know which instruction to execute) than for calcul= ing.
> heh.
>
> > Athlon and PIV are design to perfome the same operation 3 time pe= r clock
> > tick (they have 3 alu, 3 fpu,...). But they want to xlr8 the old = code,
> > too. And dependancies between register made that you can't speed = up code
> > by just having a scorebord. You need register renaming and all th= at
> > stuff, to really have 3 intructions run in the same time.
> just compute : you want 3 op/c, with a latency of at least 3 cycles, > this means a minimum of 9 registers. there are only 7 useable regs...<= BR> > x86 is dead. Vive le F-CPU !
>
> > The probleme came when you want to speed up old binaries. Pentuim= use 2
> > decoder, but Pentuim pro have 3 but can excute only one complex > > instruction (memory to memory,...) and 2 "simple" RISC-= like instruction.
> > So the programming rules changes and the "true" speed u= p is less evident
> > (or why some time a pentuim MMX could outperforme a PIII).
> i tested it myself, my P200MMX ran faster than a PII-266 with a code > that
> is optimized for the PMMX.
> If you can correctly pair instructions for the PMMX, you can kill
> PII's performace because the rules are completely different.
>
> > To increase the speed of a cpu, you could increase the clock
> > frequencies. That's easy but you add depencies problemes with lon= g
> > pipeline (20 for PIV more for the FCPU ?).
> there is also the fact that you can't go below a certain minimal
> granularity.
> We have pipelined the adder, Intel did this too, but we can't go much<= BR> > below because
> we hit some realities : number of FF/number of gates...
>
> > You can try to execute
> > differente type of instruction in the same time (ALU, load&st= ore). It's
> > just a little more decode, the unit are soon here.
> that's what ALPHA did. one alu, one l/s. then, for the 164, 2ALU, 2L/S= .
> today they decode 4 instructions and perform 2L/S (3 ?), 2 int and 2 F= P.
> IIRC. and they kill some other chips.
>
> > And then, you can add
> > some more unit like an ALU. Here, is the problem, how could we ex= pect to
> > increase speed linearly compare to the number of unit?
> with a good decoding scheme. that's why even though Intel blew up the<= BR> > P4,
> they found a good way to bypass the x86's sucking opcode formats.
>
> > How can we broke depencies soon increase by the deep pipeline (tr= ue
> > dependence are now around 10 instructions or even more) ?
> the FC0 is a way to do this. a 2-way superscalar FC0 ("FC0-2"= ;)
> will require some rework of the decoder/scheduler, a 5r3w R7,
> a larger scoreboard, another L/SU but that's all...
> a FC0-4 would have 2 symmetrical FC0-2 and a big pre-decoder
> that will handle the register dependencies. that's the "evolution= ary
> way".
> we'll have to make some stronger coding rules, a big instruction
> reorderer and analyse the possibility of a pseudo-VLIW encoding.
> above 4 ipc, we need something else : FC1. there, we can study anythin= g.
>

This paper was about "How it could be possible to AVOID out of order execution ?" !!!!

> > Scorebording
> > is the easy and first step to do it, but if there is to much depe= ncies
> > the code will as slow as befor.
> dunno. we have 63 regs, we can do 3 pipelines with 8 stages, or 4
> pipelines
> with 5 stages (execution pipeline, of course). it gives us enough time=
> before we require more physical registers.
>

Hemm ! In some paper you give the number of "6 gates" between 2 flip-flops. Athlon have 14 stages of pipeline. And this stage are big
enought to handle 32 bits adder. So Fcpu will be far above the number of 14 maybe around 50 !

> > Big register bank could help to broke depencies.
> but what about the logical number ? how does the SW manage that ?
> explicit register renaming is a possibility but it has not been a
> studied
> feature... yet ...
>

That's not how actual P3 handle register renaming ? Few month ago, i
have think about a system where you don't give a register number but an
offset to a register pointer. So your are virtualy not limited by the
number of register your are just limited for each instruction to access
between -32 and 32th registers near the last register access. But it
could be strange to code, no ?

> > But it's always a limit
> > put in the design. SIMD parrallelism are maybe a good way to incr= ease
> > speed.
> not "speed" but MHz/MOPS ratio. we're safe from this POV. > SIMD algos are studied for 20 years now...
>

Algo, yes. But not compiler !!!!!

> > If you can really double the size of this register, and the code<= BR> > > always work, you could be close to double your speed in your calc= ul
> > intensive task. But the compiler and the coding rules could be ha= rd to
> > write and follow.
> i explained you a way to do that : use a "vectoring" compile= r,
> that can recognize vector coding. then, each time it detects a vector<= BR> > loop,
> it splits the vector into "registers" of N chucks, N is not = known in
> advance.
> then for each loop iteration it performs N operations, depending on th= e
> implementation. it is not extremely straightforward to implement,
> but it is not impossible.

The problems are at the beginning and at the end of the loop.

> btw, there's no particular pragma or keyword to describe a vector loop=
> in C.
> i don't want to program in Fortran either ;-)
>

I know that's the big problem. But in the other way, we have the choice
to use different kind of parrelism (SIMD, SMT, VLIW...). NO COMPILER
GURU, ARROUND ??? So we need to have such C compiler.

> > An other means could be used is the SMT technologies.
> yup but we're not mature yet.
>
Why not ?
> > Having virtualy
> > few processors but using the same hardware.  You just make a= cpu with an
> > enormous pipeline (why not 100 stages).
> no need for so much.
>
That's the interrest of SMT !! Without the big depencies pb.
> > And for each new instruction you
> > take an instruction from an other thread. It's like having a true= SMP
> > system with 4, 8, 16 or 32 slower processors.
> except that it is easier and cheaper.
> FC0's execution pipeline could be used but the decoder would require > a certain amount of rework.
>
> > So you have some different
> > register banks. With that you broke pipeline depencies a lot. Som= e
> > people would break the memory latencies, too. It's a good idea, b= ut a
> > cache miss cost around 150 cycles.
> and 1500 if you use a serial link ;-PPP
>
;p
> > So you need to have a lot of thread
> > (-> very difficult to write the code)
> nope if you hit the OS' scheduler.
> and i don't want of the "microtasks" ...
>
??????????????????? You are crazy ???? We speak to change of task, each
instruction and to choose wich one should be executed you want to call
the kernel ?!?!?!?!?! So to exectute one more instruction you need to
execute some 100 in the kernel. *~<:=A7

> > or having a complex scheduling
> > unit to know wich thread could be executed, with the big risk to<= BR> > > recreate register depencies.
> the OS kernel is the best place to do this.
>

Of courses, not. Much far to slow !

> > So there are lot of problem. The worst is to write a good compile= r for
> > that. How could it be easy to add some thread capabilities ?
> the SMT side should be managed by the OS.
> If you see a usual UNIX server that handles lots of connexions,
> you see that it's the good place.
>

I don't want this at all. You are going to have big trouble with the TLB which could become to small. The cache will be always fluched : in true
thread, code and often datas are shared between the thread. Even on
actual thread, there is no hardwar protection between thread. So here,
to keep the core simple, we need to avoid this. But everybody know that
it isn't easy to write code with many threads, so the compiler could do
it. So if the number of thread go from 4 to 16, the program should use
the 12 new virtual processor to speed up their code.

> > You could
> > excute 4 threads and what happen to the code with 8 or 16 ?
> don't do that in HW, you just found one good argument :-)
>

See just above !

> > With such
> > big pipeline, the speed reach by the processor could became fabul= ous (5
> > or 6 GHz with today technologies !) and the cache memory must fol= low.
> nope. cache is always late.
>

Not really, i have read somewhere that IBM have laboratory SRAM that run at 2 Ghz...

> > But by adding some more pipeline stage, maybe we can solve the pr= oblem
> > ;p
> i don't believe this... look at the latest SPARC, where they use wave<= BR> > pipelining
> (the clock is slightly higher than the latency...)
>

In a SMT system, the access to the memory could pipelinned, too. So the
true speed could easly be hidden.

> > In the other hand i have read in comp.arch, that there is a very = strong
> > dependancies on the stack pointer. Without this dependancy, the t= rue ILP
> > of lot of program could reach 100 or more. This imply to develop = a new
> > way to make function call to avoid such depencies. But 100 compar= e to
> > the usual number of 3 is to much to be forgotten (for GCC).
> burn C/GCC, burn ! :-)
>

I don't speak about what are done by GCC but i speak about the program
it-self (and this code).

> > I like very much to take a few a lot of different thing to speed = up our
> > design. So few SIMD spec, few SMT, few vliw (at the very beginnin= g
> > having a pair rules to the instruction). But we always have the p= roblem
> > to have a good compiler to handle all that new stuff.
> i don't think it's really the main problem.
> the problem is to find the time to do it.
> I have the ideas and i'm not alone in this subject : Cedric is learnin= g
> some stuffs, Jeff is in the train, and Ingo has joined.
> i'm sure that something good will appear.
>

Until now, nobody have given this point of view about compiler. That's a very difficult task ! It's a very new task to use all that parallelism
in a compiler. We can write this kind of chip, but what happen if it's
very hard to use all that power ?

In the same way, if you publish a sexy cpu, lot of gay are going to try
to write something for it, so...

> > I know that some people would say that we haven't soon one little= FC0
> > BUT things made for the 8088 are  always inside the P4, ...<= BR> > i know, i know, that's what this list is for...
>
> > nicO
> YG
nicO
eGroups Sponsor=
3D"Click
Click here to subscribe.
From Nicolas Boulay Thu Jan 11 22:34:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05025 for ; Fri, 12 Jan 2001 03:02:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:33 +0100 (MET) Received: (qmail 10772 invoked by uid 0); 11 Jan 2001 21:41:04 -0000 Received: from mv.egroups.com (208.50.144.81) by 10.1.4.106 (mx06) with SMTP; 11 Jan 2001 21:41:04 -0000 X-eGroups-Return: sentto-1101623-1949-979249243-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 11 Jan 2001 21:40:59 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 21:40:42 -0000 Received: (qmail 80403 invoked from network); 11 Jan 2001 21:27:16 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 11 Jan 2001 21:27:16 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 11 Jan 2001 22:28:21 -0000 Received: from ifrance.com (nas14-89.vlt.club-internet.fr [195.36.164.89]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA26213 for ; Thu, 11 Jan 2001 22:27:13 +0100 (MET) Message-ID: <3A5E26FA.B3BE362D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 22:34:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 700010a64a6b112f725e7f938df649ae Status: R X-Status: N > > > > I would like to
> > > >create something to optimise the transfert (my extended MMU).
> > > do it and publish the draft, damnit !
> > > but please don't use "magic words" but real physical
> > > names for the units (ie : compare, register, add ... forget
> > > words like "manager" or "handler" that don't mean anything)
> > Ok, ok ! Could you give me an account to seul ?
> i don't "give".
> it's the work of Roger Dingledine from seul.org, the root of the cran
> server.
> i don't have his address at hand, but he sent a message on the mailing
> list
> a month ago... ask him gently, say that it's for the f-cpu project,
> tell him your name, email address and your desired account name.
> i'll be warned when your account opens and i'll symlink
> your public_html directory from the f-cpu account. just don't forget
> to chmod your ~/ and ~/public_html to 755 so it can be read from the
> web.
>
> http://f-cpu.seul.org/
> has already some stuff from Michael, Olivier and me,
> Nate has an account but hasn't chmoded yet AFAIK.
>

I don't find his email address. So if you could do something...


<snip>
> > > > You can choose to make it by SW (like
> > > >SUN). Or by HW, so the network must be known. If you use mostly
> > > >broadcast, a ring is fine (in a cube you lost a lot of bandwith), a
> > > > point to point is quick, but you have to make some routing and you have
> > > >to know were is a ressource !
> > > fine. Prove me that you can't know where the ressources are.
> > I not say that you can't find it. But that you need a location table
> > somewhere. So it's some more unusefull communication on the system
> > network.
> but at least, you can make a multiported dedicated HW to hold the
> table...
>

It's always a message to send thought the network thought the fbus, so
you waste some bandwith. More i think more i beleive that we should
forget the network and concentrate one the chip. At the very beginning,
it could be very hard to produice more than one chip, the best way to
use all the current peripheral is to use PCI bus. The idea to use PC has
"Host" aren't so stupid. You don't have to write all interface for each
connection. Then you can put 4 card in the same pc if you want. But we
focus only on a card with a cpu + SDRAM + PCI link to the host (+RS232
link and JTAG for debugging at the beginning). It seems wise, no ?

We live the network to be used to the end user. And we concentrate to
the other stuff.

> ok, i gotta eat...
>
> > nicO
nicO
eGroups Sponsor
Click Here for moving resources by Rent Net!
From "Marco Al" Fri Jan 12 00:03:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05040 for ; Fri, 12 Jan 2001 03:02:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:38 +0100 (MET) Received: (qmail 20112 invoked by uid 0); 11 Jan 2001 23:04:23 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx14) with SMTP; 11 Jan 2001 23:04:23 -0000 X-eGroups-Return: sentto-1101623-1950-979254243-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 11 Jan 2001 23:04:15 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 23:04:02 -0000 Received: (qmail 15018 invoked from network); 11 Jan 2001 22:55:32 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 11 Jan 2001 22:55:32 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 11 Jan 2001 22:55:32 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id XAA03225 for ; Thu, 11 Jan 2001 23:55:31 +0100 (MET) Message-ID: <005e01c07c22$b41940a0$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 00:03:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 884bc5ef6edbd5b5e2885c1d2144b407 Status: R X-Status: N From: Nicolas Boulay <nicolas.boulay@ifrance.com>

> > > Scorebording
> > > is the easy and first step to do it, but if there is to much depencies
> > > the code will as slow as befor.
> > dunno. we have 63 regs, we can do 3 pipelines with 8 stages, or 4
> > pipelines
> > with 5 stages (execution pipeline, of course). it gives us enough time
> > before we require more physical registers.
> >
>
> Hemm ! In some paper you give the number of "6 gates" between 2
> flip-flops. Athlon have 14 stages of pipeline. And this stage are big
> enought to handle 32 bits adder. So Fcpu will be far above the number of
> 14 maybe around 50 !

I think you are overestimating the complexity for a 32 bit adder, in fact you
could do it with a logic depth of 2 ;)

> That's not how actual P3 handle register renaming ? Few month ago, i
> have think about a system where you don't give a register number but an
> offset to a register pointer. So your are virtualy not limited by the
> number of register your are just limited for each instruction to access
> between -32 and 32th registers near the last register access. But it
> could be strange to code, no ?

How is that different from register windows?

> > > But it's always a limit
> > > put in the design. SIMD parrallelism are maybe a good way to increase
> > > speed.
> > not "speed" but MHz/MOPS ratio. we're safe from this POV.
> > SIMD algos are studied for 20 years now...
> >
>
> Algo, yes. But not compiler !!!!!

Even if you had a good compiler, without lots of loops wich can be unrolled to a
sufficient degree its almost useless. SIMD is good for DSP, but if we are
serious about general purpose processing we will have to look elsewhere.

> > > And for each new instruction you
> > > take an instruction from an other thread. It's like having a true SMP
> > > system with 4, 8, 16 or 32 slower processors.
> > except that it is easier and cheaper.
> > FC0's execution pipeline could be used but the decoder would require
> > a certain amount of rework.

And the MMU if you really wanted it to be equivalent to SMP.

> > > or having a complex scheduling
> > > unit to know wich thread could be executed, with the big risk to
> > > recreate register depencies.
> > the OS kernel is the best place to do this.
> >
>
> Of courses, not. Much far to slow !

Gotta agree, even for vertical multithreading (to have something to on a cache
miss) its slow, and for anything more finegrained its useless. IMO the only
thing you could do in the OS is switch tasks on misses on remote accesses in a
multiprocessor environment.

> > > So there are lot of problem. The worst is to write a good compiler for
> > > that. How could it be easy to add some thread capabilities ?
> > the SMT side should be managed by the OS.
> > If you see a usual UNIX server that handles lots of connexions,
> > you see that it's the good place.
> >
>
> I don't want this at all. You are going to have big trouble with the TLB
> which could become to small. The cache will be always fluched : in true
> thread, code and often datas are shared between the thread. Even on
> actual thread, there is no hardwar protection between thread. So here,
> to keep the core simple, we need to avoid this. But everybody know that
> it isn't easy to write code with many threads, so the compiler could do
> it. So if the number of thread go from 4 to 16, the program should use
> the 12 new virtual processor to speed up their code.

A solution is to take it to the extreme, have enough processes to bridge main
memory latency even with the cache pollution (thats the basic idea behind
Tera/Cray's MT architecture I think). You could instrument the processor such
that the OS could schedule processes according to memory locality, if you have
plenty of threads working with the same set fine... if not do the best you can.

> Until now, nobody have given this point of view about compiler. That's a
> very difficult task ! It's a very new task to use all that parallelism
> in a compiler. We can write this kind of chip, but what happen if it's
> very hard to use all that power ?

Thats the advantage of MP over MT.

> It's always a message to send thought the network thought the fbus, so
> you waste some bandwith. More i think more i beleive that we should
> forget the network and concentrate one the chip. At the very beginning,
> it could be very hard to produice more than one chip, the best way to
> use all the current peripheral is to use PCI bus. The idea to use PC has
> "Host" aren't so stupid. You don't have to write all interface for each
> connection. Then you can put 4 card in the same pc if you want. But we
> focus only on a card with a cpu + SDRAM + PCI link to the host (+RS232
> link and JTAG for debugging at the beginning). It seems wise, no ?

I have thought about it... and I think the easiest and most scalable way to get
to the PCI bus is via SCI. You can just get a dolphin SCI-PCI bridge and put it
in a PCI backplane and you have a system, and while I dont think making a SCI
interface is easy... I doubt its much more difficult than a PCI one.

Marco
eGroups Sponsor
Click here for Business information
Click here for Business information
From Jeff Davies Fri Jan 12 00:29:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05046 for ; Fri, 12 Jan 2001 03:02:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:40 +0100 (MET) Received: (qmail 6326 invoked by uid 0); 11 Jan 2001 23:48:51 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx17) with SMTP; 11 Jan 2001 23:48:51 -0000 X-eGroups-Return: sentto-1101623-1951-979256903-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 11 Jan 2001 23:48:48 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 11 Jan 2001 23:48:20 -0000 Received: (qmail 64417 invoked from network); 11 Jan 2001 23:38:33 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Jan 2001 23:38:33 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta1 with SMTP; 11 Jan 2001 23:38:32 -0000 Received: from modem-150.xenon.dialup.pol.co.uk ([62.136.45.150] helo=llandre.freeserve.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14GrIb-0001hv-00 for f-cpu@egroups.com; Thu, 11 Jan 2001 23:38:29 +0000 Message-ID: <3A5E41E2.3EE6DB2A@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 23:29:39 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's go back to the rock ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5a89f415f480484c570069ca018a436c Status: R X-Status: N > Until now, nobody have given this point of view about compiler. That's a
> very difficult task ! It's a very new task to use all that parallelism
> in a compiler. We can write this kind of chip, but what happen if it's
> very hard to use all that power ?
>

The simplest way would be manually in the first place. ie. use GCC as is, and
make libraries with
assembler doing the SIMD stuff for some common functions, and then rewrite some
programs to
use this code (like perhaps some accelerator parts of X?).

What is SIMD used for most of the time these days anyway - is it:
1. codecs
2. geometry transfer (as in geometry transfer engine in playstation 1).
This is matrix maths for rotation, translation in 3d environment.
3. I guess SIMD is also used for Texture Fill, Antialiasing, that kind of thing.

Overall, when you want to do lots and lots of similar instructions over and
over.
(like the box says).

ps: Playstation One is amazing graphics/gameplay for a 32 bit risc running at 33
mhz
with 2 meg of RAM. This is the same specification as my HP 300LX windows CE
machine.
Yet, one is capable of fast 3d graphics, the other is a complete dog (and yet
has 44mhz clock
despite also being a 32 bit risc!).
Must be the GPU (does 2d fill and stuff), and the GTE (geometry transfer engine)
which does the
3d coordinate calculations.
BTW: The (rather old) playstation one has better graphics/speed than my brothers
old 166MMX cpu!
Perhaps 200MHz FCPU will outpace 2 GHz pentiums??

Jeff Davies
eGroups Sponsor
Click Here!
From Alan Grimes Fri Jan 12 01:25:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05052 for ; Fri, 12 Jan 2001 03:02:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:42 +0100 (MET) Received: (qmail 2222 invoked by uid 0); 12 Jan 2001 00:34:22 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx18) with SMTP; 12 Jan 2001 00:34:22 -0000 X-eGroups-Return: sentto-1101623-1952-979259571-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 12 Jan 2001 00:34:20 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 00:32:50 -0000 Received: (qmail 20518 invoked from network); 12 Jan 2001 00:22:54 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Jan 2001 00:22:54 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta3 with SMTP; 12 Jan 2001 01:23:59 -0000 Received: from 66-44-60-243.s243.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.243] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14GrzZ-0001Ip-00 for f-cpu@egroups.com; Thu, 11 Jan 2001 19:22:53 -0500 Message-ID: <3A5E4EE0.F2854663@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <3A5E41E2.3EE6DB2A@llandre.freeserve.co.uk> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 19:25:04 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's go back to the rock ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 55746d3344c60d06fdd80f9c01573dd2 Status: R X-Status: N > Perhaps 200MHz FCPU will outpace 2 GHz pentiums??

Eventually... Especially if Intel doesn't fix the P4 which has the same
ammount of Data cache/and single instruction issue system as the 486...

=P

Now people, Why don't you come join FreeProc over at sourceforge!
I mean sourceforge is not just a discussion forum, it provides advanced
project managment features that will allow us to follow a well defined
and highly visable development process. =)

Sourceforge is great.

- No spam
- enhanced version controlled file managment.
- Controlled document archives.
- no "UNSUBSCRIBE!!!!"
- Advanced team managment and job allocation systems.
- tastes great
- maximum security unix based configuration (Heck! Even I can't get in!
=P)
- less filling
- Friendly product managers.
- Maximum cool PNG graphics that aren't compatable with my browser...
- Sucess is guarenteed! =)


Egroups is terrable...

- The list manager is clinicaly d34d.
- F-cpu@egroups.com is on every spam list in the entire world...
- chaotic file archives.
- UNSUBSCRIBE!!!!!
- No orgainization; many people are discussing chipsets (which belong on
f-mainboard not here)..
- No path, of any kind, for lurkers to become contributors.
- Very small chance for any form of success.
- No progress metrics...
- the ship is sinking.


--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
From Yann Guidon Fri Jan 12 02:28:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05073 for ; Fri, 12 Jan 2001 03:02:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:02:47 +0100 (MET) Received: (qmail 3651 invoked by uid 0); 12 Jan 2001 01:32:16 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx08) with SMTP; 12 Jan 2001 01:32:16 -0000 X-eGroups-Return: sentto-1101623-1954-979263086-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mw.egroups.com with NNFMP; 12 Jan 2001 01:31:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 01:31:26 -0000 Received: (qmail 96708 invoked from network); 12 Jan 2001 01:22:15 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 12 Jan 2001 01:22:15 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 12 Jan 2001 01:22:14 -0000 Received: from f-cpu.org (nas3-10.ras.club-internet.fr [195.36.203.10]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA04498 for ; Fri, 12 Jan 2001 02:22:11 +0100 (MET) Message-ID: <3A5E5DAC.5354BA78@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 02:28:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0785a293df09b4233bdcb3573bcff713 Status: R X-Status: N quick answer before i sleep,

Nicolas Boulay wrote:
> > http://f-cpu.seul.org/
> > has already some stuff from Michael, Olivier and me,
> > Nate has an account but hasn't chmoded yet AFAIK.
> I don't find his email address. So if you could do something...
done.

> <snip>
> > > > fine. Prove me that you can't know where the ressources are.
> > > I not say that you can't find it. But that you need a location table
> > > somewhere. So it's some more unusefull communication on the system
> > > network.
> > but at least, you can make a multiported dedicated HW to hold the
> > table...
> It's always a message to send thought the network thought the fbus, so
> you waste some bandwith.
it is sent through one f-bus, not everybody. i don't think it's a waste.
it's jsut like a semaphore : you can use the same mechanism.

> More i think more i beleive that we should
> forget the network and concentrate one the chip.
are we finally going to do anything ? :-)

> At the very beginning,
> it could be very hard to produice more than one chip,
<snip>
> We live the network to be used to the end user. And we concentrate to
> the other stuff.

now my worry is about the SHL unit. a rough estimate gave a Omega network
with 3 layers of 16 shufflers of 4 inputs and 4 outputs.
Maybe with a 4 in/8 out, we can do something better ?
Sign extension is still worrying...
grrrr.... we need another genius : Michael is busy with the multiplier.
Can anybody make some netsearches on this matter ?...

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Keyshaun Fri Jan 12 02:26:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA05243 for ; Fri, 12 Jan 2001 03:32:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 03:32:33 +0100 (MET) Received: (qmail 31734 invoked by uid 0); 12 Jan 2001 02:04:12 -0000 Received: from c3.egroups.com (208.50.99.225) by 10.1.4.111 (mx11) with SMTP; 12 Jan 2001 02:04:12 -0000 X-eGroups-Return: sentto-1101623-1953-979262915-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 12 Jan 2001 01:30:07 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 01:28:34 -0000 Received: (qmail 22076 invoked from network); 12 Jan 2001 01:20:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 12 Jan 2001 01:20:08 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta1 with SMTP; 12 Jan 2001 01:20:08 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14GszT-000204-00 for ; Thu, 11 Jan 2001 18:26:51 -0700 X-X-Sender: To: Freedom CPU Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 18:26:51 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0fdbbe8523f7d14f037c876a19739afd Status: R X-Status: N Before I get to my question I must say that Alan Grimes really must think
that he is going to be some savior to this project.  Oh well.  On to
important business...  Granted I have declared myself as a lurker I am
wondering if anyone can suggest a good VHDL book that I can find at the
local university book store.  I feel like I did when I hand't learned C
yet.  I have my own projects and it would really be good if I could use
FPGAs for them.  I use the Cadsoft Eagle layout editor and if I could
reduce my logic chip count I just may be able to stay withing the tiny
board size.  I wonder if they have a student rate...  I just hope I can
soon contribute a bit after I have done some basic i186 frontend interface
stuff on my own FPGA.  Forgive the reference to intel, but where else can
you go for a common dumb processor?

Shaun
eGroups Sponsor
Click here for Business information
Click here for Business information
From Alan Grimes Fri Jan 12 03:18:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00299 for ; Fri, 12 Jan 2001 14:29:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:29:44 +0100 (MET) Received: (qmail 26457 invoked by uid 0); 12 Jan 2001 02:25:41 -0000 Received: from mk.egroups.com (208.50.144.76) by 10.1.4.111 (mx11) with SMTP; 12 Jan 2001 02:25:41 -0000 X-eGroups-Return: sentto-1101623-1955-979266332-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mk.egroups.com with NNFMP; 12 Jan 2001 02:25:41 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 02:25:31 -0000 Received: (qmail 50116 invoked from network); 12 Jan 2001 02:16:09 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 12 Jan 2001 02:16:09 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta1 with SMTP; 12 Jan 2001 02:16:09 -0000 Received: from 66-44-60-243.s243.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.243] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Gtl9-000373-00 for f-cpu@egroups.com; Thu, 11 Jan 2001 21:16:07 -0500 Message-ID: <3A5E696A.53FD3344@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 21:18:18 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4cccbc4970afcccf9dcee0baa9d85640 Status: R X-Status: N Keyshaun wrote:
>
> Before I get to my question I must say that Alan Grimes really must
> think that he is going to be some savior to this project.  Oh well.

what project?
I don't see much of a prject here... Well maybe if you call Yann's hobby
a project, there is one. I don't mean to disparage Yann's work but there
isn't even a F-CPU technical committee anymore. =\ Without ways for
morons such as myself to become active members the project might as well
not even exist. < (I'm going to say this in each message from now on)

I am not "saving this project" I am creating a new project, FreeProc,
that will hopefully attract the same people who were attracted to this
list. It will break down the very large F-CPU manual as it exists today,
into short byte sized (not literally) chunks that can be effectively
reviewed and contributed to by individuals. It will offer people direct
and easy access to the source. It will allow people who are NOT Yann to
propose and effect changes to any part of the project with the powerful
utilites at sourceforge.

I want to make this happen, and I know how to do it! The answer is
structure. With sourceforge I can make everything work in a focused and
well considered, if not *completely* democratic, manner... I can also
guarentee you that Yann alone will not be able to pull anything really
interesting off by himself. We must work togeather and make far better
use of all the people who are interested in this project. I know that
I've been unable to contribute in any way since the preferred language
on the list switched to Bache'... =P

If I can't manage to attract the pratcipants I need in the freeProc
project then I'll take my ideas and start working on a fully propriatary
processor. ;)

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
From Keyshaun Fri Jan 12 04:13:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00320 for ; Fri, 12 Jan 2001 14:29:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:29:52 +0100 (MET) Received: (qmail 30609 invoked by uid 0); 12 Jan 2001 03:18:12 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx18) with SMTP; 12 Jan 2001 03:18:12 -0000 X-eGroups-Return: sentto-1101623-1956-979269220-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 12 Jan 2001 03:13:59 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 03:13:39 -0000 Received: (qmail 38403 invoked from network); 12 Jan 2001 03:06:31 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 12 Jan 2001 03:06:31 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta1 with SMTP; 12 Jan 2001 03:06:31 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14GueR-00020P-00 for ; Thu, 11 Jan 2001 20:13:15 -0700 X-X-Sender: To: In-Reply-To: <3A5E696A.53FD3344@starpower.net> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 20:13:15 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 324a0036af410af7d8872638e24eb50c Status: R X-Status: N I am not an active member of the F-CPU project, but I believe the
following to be true.
> what project?
> I don't see much of a prject here... Well maybe if you call Yann's hobby
> a project, there is one. I don't mean to disparage Yann's work but there
> isn't even a F-CPU technical committee anymore. =\ Without ways for
> morons such as myself to become active members the project might as well
> not even exist. < (I'm going to say this in each message from now on)

Didn't all free software start as a hobby?  My hobby happens to be
research in whatever form it may be in.  That is why I got an Atari 800XL
last week, so I could learn how to make simple devices for a simple
computer.  I applaud Yann for his efforts, I know how it is to work on
something but have life get in the way.

> I am not "saving this project" I am creating a new project, FreeProc,
> that will hopefully attract the same people who were attracted to this
> list. It will break down the very large F-CPU manual as it exists today,

Either you are FCPU or you aren't.  Know your role and give proper credit.
YOU are a newcomer.  I am too, but I'm not trying to take over the
oproject or make management changes.

> and easy access to the source. It will allow people who are NOT Yann to
> propose and effect changes to any part of the project with the powerful
> utilites at sourceforge.
Last I checked he was very open to letting others handle things.  If noone
offers noone can do a job.

> I want to make this happen, and I know how to do it! The answer is
> structure. With sourceforge I can make everything work in a focused and
> well considered, if not *completely* democratic, manner... I can also
> guarentee you that Yann alone will not be able to pull anything really
> interesting off by himself. We must work togeather and make far better
> use of all the people who are interested in this project. I know that
> I've been unable to contribute in any way since the preferred language
> on the list switched to Bache'... =P

Ahh, yes...  Democracy will get us through.  Can we recount votes until
the project finishes too?  Sourceforge is just a forum.  My own inability
to contribute to this project has bee mostly due to the fact that I can't
find good docs about VHDL and its design methods.  I learned C with little
trouble because I had enough books on the subject to litter the house with
and cross reference with eachother.  VHDL isn't a topic found in my local
library.


> If I can't manage to attract the pratcipants I need in the freeProc
> project then I'll take my ideas and start working on a fully propriatary
> processor. ;)

I can't speak for the others, but after your behavior here I wouldn't want
to contribute to your project.  You didn't by chance get after Linus in
'91 for spending too much time on school and not enough time on Linux?

You must remember what the F in F-CPU means.  It means Freedom.  That is
my biggest interest in this project.  I love even the thought of being
free, that is why I use Linux despite the fact that I don't have what it
takes to have a good box.  That is why we have the GNU project.  When
people are free you can't go about telling them they are doing it wrong
and expect anything good to happen.  Don't rush freedom or you end up
damaging it.

Shaun
eGroups Sponsor
From David Sullins Fri Jan 12 05:19:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00324 for ; Fri, 12 Jan 2001 14:29:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:29:53 +0100 (MET) Received: (qmail 12870 invoked by uid 0); 12 Jan 2001 04:26:57 -0000 Received: from mr.egroups.com (208.50.144.80) by 10.1.4.119 (mx19) with SMTP; 12 Jan 2001 04:26:57 -0000 X-eGroups-Return: sentto-1101623-1958-979273547-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 12 Jan 2001 04:26:46 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 04:25:47 -0000 Received: (qmail 21514 invoked from network); 12 Jan 2001 04:25:36 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 12 Jan 2001 04:25:36 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta2 with SMTP; 12 Jan 2001 04:25:36 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id WAA25301; Thu, 11 Jan 2001 22:25:35 -0600 Received: from eceultra19 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id WAA03524; Thu, 11 Jan 2001 22:25:34 -0600 (CST) Received: from localhost by eceultra19 (8.8.8+Sun/ECESolaris-Client) id EAA05710; Fri, 12 Jan 2001 04:19:58 GMT To: Freedom CPU In-Reply-To: Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 22:19:58 -0600 (CST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 354ca8a50bf6e0ccbc91b843717a8692 Status: R X-Status: N On Thu, 11 Jan 2001, Keyshaun wrote:

> Granted I have declared myself as a lurker I am
> wondering if anyone can suggest a good VHDL book that I can find at the
> local university book store.

Whether it's at the local university book store or not, I'd recommend
finding a copy of "The Designer's Guide to VHDL" by Peter J. Ashenden. 
It's the number one recommended book on comp.lang.vhdl.  This book covers
the entire VHDL language.  Of course, you are probably only interested in
synthesis, which uses a subset of the VHDL language.  But the book has an
appendix on synthesis, and you can find out from the documentation for
your synthesis tool what you can and cannot do to remain synthesizable.

Part 2 of the comp.lang.vhdl FAQ has a list of nearly every VHDL book ever
published, and even has a list of the most recommended books.  You should
probably look through the FAQ for other book ideas.

Dave
eGroups Sponsor
Click Here!
From Alan Grimes Fri Jan 12 05:12:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00327 for ; Fri, 12 Jan 2001 14:29:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:29:54 +0100 (MET) Received: (qmail 21303 invoked by uid 0); 12 Jan 2001 04:35:00 -0000 Received: from hm.egroups.com (208.50.99.198) by 10.1.4.119 (mx19) with SMTP; 12 Jan 2001 04:35:00 -0000 X-eGroups-Return: sentto-1101623-1957-979272608-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 12 Jan 2001 04:10:46 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 04:10:07 -0000 Received: (qmail 86588 invoked from network); 12 Jan 2001 04:09:59 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 12 Jan 2001 04:09:59 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta3 with SMTP; 12 Jan 2001 05:11:05 -0000 Received: from 66-44-60-243.s243.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.243] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14GvXJ-0003K8-00 for f-cpu@egroups.com; Thu, 11 Jan 2001 23:09:57 -0500 Message-ID: <3A5E8418.2AE58750@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 23:12:08 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3d4b7f0433321dc58fd5cc5f27e8bb7d Status: R X-Status: N Please take the time to read my replies to this.

Keyshaun wrote:

> Didn't all free software start as a hobby?

no.
Some was orrigionally pay software, developed according to the practices
that I am trying to apply here, and then later liberated after the
industry moved on or the company went under...

One could argue that almost no free software was not first developed and
perfected by a for-pay orgainization and then "liberated" by people who
decided to clone it and make it free... The entire "GNU" project is
based on that practice. Very little in linux shows any orrigional
thought. =\

I will argue here that while we aren't in a position to start a company,
we too must apply the same techniques as those companies to make this
project work.


> Either you are FCPU or you aren't.  Know your role and give proper
> credit.

When someone explains to me exactly what has been done, I'll give as
much credit as you want. ;)


> YOU are a newcomer.

Please locate the first posting I made to the f-cpu project in the list
archives and then reconsider that statement.
Try message 303 of 6600. ;)
I might as well sumarize the things I've learend since writing that:
- Trying to utilize PC motherboards is pointless..
- I have leaned that suckeyness is intrinsic to the linux operating
system and not just a symptom of the particular of the distribution I
mentioned in that article..
- Most importantly of all, I have learned that to make this project work
I can't just sit back and let it happen as I suggest in my last
paragraph from that article, I must get my hands dirty and MAKE it
happen! I have also learned how to do that.


>   I am too, but I'm not trying to take over the oproject or make
> management changes.

I am trying to take over the project because nobody else has stepped up
to do so.
I am strongly suggesting managment changes because that is the only way
that we will be diciplined enough to get things done.


> Last I checked he was very open to letting others handle things.  If
> noone offers noone can do a job.

aah!
That's the problem.
People can't see jobs until people who have aleady undertaken jobs
determine what needs to be done!
Sourceforge fixes that. It lets managers and their peers CREATE jobs
that people can then sign up for. =) Instead of getting out my ouigi
borard and trying to devine what needs to be done next, a creative
person such as myself can produce a whole menu to choose from.
It needs to be done this way otherwise it will be too dificult and turn
people away. =\


> Ahh, yes...  Democracy will get us through.  Can we recount votes until
> the project finishes too? 

;)
The procedures would be either I decide it or it is placed for a
fixed-length machine vote. =)

> Sourceforge is just a forum.

eGroups is just a forum.

Sourceforge is a sophisticated project managment system! It has software
for jobs you havn't even considered!
Unfortunately it is a little TOO advanced and I have no way of accessing
many of its features. =(

>  My own  inability to contribute to this project has bee mostly due to
> the fact that I can't find good docs about VHDL and its design methods.

I blame the current contributors for this. Obviously the current
contributors have already FOUND the documents you reportedly can't find.
Therefore it is THEIR fault for not providing a reading list to give
people such as yourself a leg-up. =\

I am more than a little upset at them, and many other people, about
this.


>  I learned C with little trouble because I had enough books on the
> subject to litter the house with and cross reference with eachother.

I only needed two...
Ansi C made easy  (1988)
and
C: The complete refference, Second ed. (1990)
Today I am reccomending: 0-13-110370-9

I'm not that interested in C anymore. =\

 
> VHDL isn't a topic found in my local library.

Libraries, as any other government service, suck. ( www.lp.org ) < gotta
throw that in every now and then. ;)

> I can't speak for the others, but after your behavior here I wouldn't
> want to contribute to your project.  You didn't by chance get after
> Linus in '91 for spending too much time on school and not enough time
> on Linux?

No.
I'd get mad at him for cloning a bad OS. ;)

> You must remember what the F in F-CPU means.  It means Freedom.  That
> is my biggest interest in this project.  I love even the thought of
> being free, that is why I use Linux despite the fact that I don't have
> what it takes to have a good box.

That's foolish but I guess you're free to do it...

> That is why we have the GNU project.  When people are free you can't
> go about telling them they are doing it wrong and expect anything good
> to happen.  Don't rush freedom or you end up damaging it.

You are right. To the extent that I can shut up and walk my own path
with my own path, that is the correct way of looking at things.
Unfortunately things can't work beyond the odd utility here and there.
If I were to coin a phrase I would call it the Transhumanist's Lament.
It will go like this:

"I am not the giant I would like to be.
I am not as strong as the ant nor as fast as the chetah.
But if I am to hope that I will ever be I must work togeather with my
peers and with our combined hight, strength, and speed, we can become
all those things and more."

Or to put it in other terms:

"A man cannot build a pyramid."

Even if I were to dedicate my life to making my OS, which to an extent I
have, I cannot dream of doing anything more than laying the conceptual
framework in which it will be built. My only prayr of making it happen
is to find (or create) a machine that is simple enough for me to master
and then implement a small tiny subset of its features on to it. Once I
have done this I can take it to investors and beg them to finance me
with the hundreds of millions I will need to deliver a state of the art
computing solution.

In this light all of my actions over the last week on this list will
become perfectly plain and perhaps even logical.

Thanks for your attention.

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
From Keyshaun Fri Jan 12 06:06:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00335 for ; Fri, 12 Jan 2001 14:29:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:29:56 +0100 (MET) Received: (qmail 27787 invoked by uid 0); 12 Jan 2001 05:00:17 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx14) with SMTP; 12 Jan 2001 05:00:17 -0000 X-eGroups-Return: sentto-1101623-1959-979275605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 12 Jan 2001 05:00:16 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 05:00:05 -0000 Received: (qmail 47360 invoked from network); 12 Jan 2001 05:00:04 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Jan 2001 05:00:04 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta2 with SMTP; 12 Jan 2001 05:00:04 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14GwQL-00020e-00 for ; Thu, 11 Jan 2001 22:06:49 -0700 X-X-Sender: To: In-Reply-To: <3A5E8418.2AE58750@starpower.net> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 22:06:48 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cb822615a8298edb3035a37b08e907b8 Status: R X-Status: N > > Either you are FCPU or you aren't.  Know your role and give proper
> > credit.
>
> When someone explains to me exactly what has been done, I'll give as
> much credit as you want. ;)

I consider the writing of the manual to be just as big as the writing of
the VHDL.

>
> Sourceforge is a sophisticated project managment system! It has software
> for jobs you havn't even considered!
> Unfortunately it is a little TOO advanced and I have no way of accessing
> many of its features. =(

Well, all hail Srouceforge since people don't know how to manage their own
projects.

>
> >  My own  inability to contribute to this project has bee mostly due to
> > the fact that I can't find good docs about VHDL and its design methods.
>
> I blame the current contributors for this. Obviously the current
> contributors have already FOUND the documents you reportedly can't find.
> Therefore it is THEIR fault for not providing a reading list to give
> people such as yourself a leg-up. =\
>
> I am more than a little upset at them, and many other people, about
> this.

Oh yes, it's terrible that I had to speak up and ask to get a
recommendation on a book.  I would rather get a suggestion from saying "I
need <this>" what should I get?  Than just looking at a list of books.

> >  I learned C with little trouble because I had enough books on the
> > subject to litter the house with and cross reference with eachother.
>
> I only needed two...
> Ansi C made easy  (1988)
> and
> C: The complete refference, Second ed. (1990)
> Today I am reccomending: 0-13-110370-9
>
> I'm not that interested in C anymore. =\

For the record C is a very powerful language if used correctly.  nuff
said.

> > VHDL isn't a topic found in my local library.
>
> Libraries, as any other government service, suck. ( www.lp.org ) < gotta
> throw that in every now and then. ;)
>
> > I can't speak for the others, but after your behavior here I wouldn't
> > want to contribute to your project.  You didn't by chance get after
> > Linus in '91 for spending too much time on school and not enough time
> > on Linux?
>
> No.
> I'd get mad at him for cloning a bad OS. ;)

now for the nitpicky...  Linux isn't an OS.  GNU/Linux is.  Linux is a
kernel.  While Linux is what you call a UNIX clone it is only because the
design methods for UNIX were well thought out.  As a programmer I would
rather have a powerful program interface (POSIX) over anything else.  You
can write anything to run on any hardware that Linux runs on just so long
as the hardware is there.  Don't fault Linux if X doesn't do what you
like.

>
> > You must remember what the F in F-CPU means.  It means Freedom.  That
> > is my biggest interest in this project.  I love even the thought of
> > being free, that is why I use Linux despite the fact that I don't have
> > what it takes to have a good box.
>
> That's foolish but I guess you're free to do it...

I have 2 options.  Lame MS Windows, or stable text interface with a little
bit of X.  Oh and did I mention better dev tools than windows?

> Even if I were to dedicate my life to making my OS, which to an extent I
> have, I cannot dream of doing anything more than laying the conceptual
> framework in which it will be built. My only prayr of making it happen
> is to find (or create) a machine that is simple enough for me to master
> and then implement a small tiny subset of its features on to it. Once I
> have done this I can take it to investors and beg them to finance me
> with the hundreds of millions I will need to deliver a state of the art
> computing solution.
>
> In this light all of my actions over the last week on this list will
> become perfectly plain and perhaps even logical.

There is more to this than making money.  Until you realize that we will
never agree.  I admit that I consider how things like this could be used
to make money, but I am really here because I enjoy it.  When I am at work
sometimes all I can think as I walk through the warehouse is how to make
something work or perhaps what would be required to make a test model.  I
like making stuff, if in doing so I gain skill that helps me get a good
job or start a company that is a nice side affect.  In my estimation free
software and the like is great because it is made by people who want it to
work and will spend their good time to make it so.  Linux 2.4 took so long
to get out because people were trying to get it right, not meet deadlines.

> Thanks for your attention.
Wasn't deserved but you had it.

> --
> Perhaps I will upgrade my OS from win 3.11...
> But It has to be *better* than win 3.11...

Leaving the dark ages?


Shaun
eGroups Sponsor
From Jeff Davies Fri Jan 12 10:36:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00395 for ; Fri, 12 Jan 2001 14:30:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:30:06 +0100 (MET) Received: (qmail 28149 invoked by uid 0); 12 Jan 2001 09:45:13 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx03) with SMTP; 12 Jan 2001 09:45:13 -0000 X-eGroups-Return: sentto-1101623-1960-979292708-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 12 Jan 2001 09:45:12 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 09:45:07 -0000 Received: (qmail 39477 invoked from network); 12 Jan 2001 09:45:07 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Jan 2001 09:45:07 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta2 with SMTP; 12 Jan 2001 09:45:06 -0000 Received: from modem-36.endostatin.dialup.pol.co.uk ([62.136.92.164] helo=llandre.freeserve.co.uk) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14H0ld-000056-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 09:45:05 +0000 Message-ID: <3A5ED008.AC489B81@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A5E8418.2AE58750@starpower.net> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 09:36:09 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f7dce2085988042182e5cb7442339b5a Status: R X-Status: N

Alan Grimes wrote:

> Please take the time to read my replies to this.
>
> Keyshaun wrote:
>
> > Didn't all free software start as a hobby?
>
> no.
> Some was orrigionally pay software, developed according to the practices
> that I am trying to apply here, and then later liberated after the
> industry moved on or the company went under...
>

> based on that practice. Very little in linux shows any orrigional
> thought. =\
>

Try looking at freshmeat occaisionally. A big stream of free software
milestones. Most of the projects
I see there have no commercial equivalents.

Jeff Davies.
eGroups Sponsor
Click Here!
From Jeff Davies Fri Jan 12 10:43:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00399 for ; Fri, 12 Jan 2001 14:30:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:30:07 +0100 (MET) Received: (qmail 24763 invoked by uid 0); 12 Jan 2001 09:52:57 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx15) with SMTP; 12 Jan 2001 09:52:57 -0000 X-eGroups-Return: sentto-1101623-1961-979293162-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 12 Jan 2001 09:52:56 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 09:52:41 -0000 Received: (qmail 26710 invoked from network); 12 Jan 2001 09:52:41 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 12 Jan 2001 09:52:41 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta2 with SMTP; 12 Jan 2001 09:52:40 -0000 Received: from modem-36.endostatin.dialup.pol.co.uk ([62.136.92.164] helo=llandre.freeserve.co.uk) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14H0sw-0001HW-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 09:52:39 +0000 Message-ID: <3A5ED1CF.FA584390@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 09:43:43 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 878e98178744c73809873f6d7ae43e19 Status: R X-Status: N > I am not an active member of the F-CPU project, but I believe the
> following to be true.
> > what project?
> > I don't see much of a prject here... Well maybe if you call Yann's hobby
> > a project, there is one. I don't mean to disparage Yann's work but there
> > isn't even a F-CPU technical committee anymore. =\ Without ways for
> > morons such as myself to become active members the project might as well
> > not even exist. < (I'm going to say this in each message from now on)

The ISA was created by many people talking for a long time, chewing over ideas
etc.
The bones of the GCC compiler and the initial manual were written by Mathias
(& others).
Then YG took over the manual.
Now YG and Michael (possibly Michael is doing more VHDL) are implementing the
first FCPU
(FC0 core).
I think it is impossible for YG and Michael to provide the "leg-up" that
others require (including me),
due to their personal time restraints, and we should instead allow them to
finish the FC0 VHDL.
(behavioural?). Then, later, people will write documents to understand the
CPU, which will enable
extension by less knowledgeable people (me for example) etc etc.

Jeff Davies
eGroups Sponsor
Click Here!
From Jeff Davies Fri Jan 12 10:52:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00403 for ; Fri, 12 Jan 2001 14:30:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:30:08 +0100 (MET) Received: (qmail 25028 invoked by uid 0); 12 Jan 2001 10:01:59 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by mx0.gmx.net (mx08) with SMTP; 12 Jan 2001 10:01:59 -0000 X-eGroups-Return: sentto-1101623-1962-979293688-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 12 Jan 2001 10:01:58 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 10:01:27 -0000 Received: (qmail 52325 invoked from network); 12 Jan 2001 10:01:27 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Jan 2001 10:01:27 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta2 with SMTP; 12 Jan 2001 10:01:26 -0000 Received: from modem-36.endostatin.dialup.pol.co.uk ([62.136.92.164] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14H11I-0002M7-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 10:01:17 +0000 Message-ID: <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 09:52:20 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] SHIFT LEFT Content-Type: multipart/mixed; boundary="------------A899AB3BC00F093981C7A2CB" X-UIDL: b70cf2df06e7ce7434797815888b0dd6 Status: R X-Status: N --------------A899AB3BC00F093981C7A2CB Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit >
> now my worry is about the SHL unit. a rough estimate gave a Omega network
> with 3 layers of 16 shufflers of 4 inputs and 4 outputs.
> Maybe with a 4 in/8 out, we can do something better ?
> Sign extension is still worrying...
> grrrr.... we need another genius : Michael is busy with the multiplier.
> Can anybody make some netsearches on this matter ?...
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is my offering which probably won't do since it only shifts one bit at a
time.
You probably want a shift left n bits kind of unit.

Jeff Davies
eGroups Sponsor
Click Here!
--------------A899AB3BC00F093981C7A2CB Content-Type: image/bmp; name="shl.bmp" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="shl.bmp" Qk2OwwAAAAAAAD4AAAAoAAAADQMAAPQBAAABAAEAAAAAAFDDAADEDgAAxA4AAAAAAAAAAAAA AAAAAP///wD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////4 AAD///////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD//////////////////////w3rvf////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////71y7////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// ///////////+9au///////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// /vWrv/////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////71a7////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP/////////////////////+9Wu///////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD//////////////////////vTrv/////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////716g////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD////////////////////////////////v//////////// //+///////////////////////////////////////////////////////////////////// ////////////+AAA////////////////////////////////3///////////////3/////// //////////////////////////////////////////////////////////////////////// //gAAP//////////////////////Der+/BBf37470Hg3fvu/ffutoO////////////////// ///////////////////////////////////////////////////////////////4AAD///// /////////////////vXq/v3339+925f71377v337ra/v//////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// ///////16v7999/fu+tX+9d/B7+D+6qv7/////////////////////////////////////// //////////////////////////////////////////gAAP//////////////////////zer+ /fff37vrV/vXf3e/u/uqr+////////////////////////////////////////////////// ///////////////////////////////4AAD//////////////////////zwKHv3wQ9+76tB4 F3+vv9f7qqDv//////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////796v7999/fu+rX+9d/r7/X+6cv 7/////////////////////////////////////////////////////////////////////// //////////gAAP/////////////////////+9er+/fff393Z1/vXf6+/1/unL9////////// ///////////////////////////////////////////////////////////////////////4 AAD//////////////////////w3qCD3wQQfuO9B4NB/eD+/gr6C///////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////gAAP////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////4AAD///////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD///////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////4AAD///// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+AAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////gAAP////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////4AAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////+AAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////gAAP///////////////////////////////////////////+////////////// ///////////////////////////////////////////////////////////////////////4 AAD////////////////////////////////////////////v//////////////////////// ////////////////////////////////////////////////////////////+AAA//////// //////////////////////////4ePw8f//h97w+//hwfGY////////////////////////// //////////////////////////////////////////////////gAAP////////97jhwYf/// ///////////////97d927/f7vf93v77u/ut3//////////////////////////////////// ///////////////////////////////////////4AAD/////////c3bt97////////////// /////+vveu8Y+93/e7jG9377f/////////////////////////////////////////////// ////////////////////////////+AAA/////////2r69f+///////////////////+b73rv /3vd/3u/+ve+C3////////////////////////////////////////////////////////// //////////////////gAAP////////9q+vX+f//////////////////+e+967/j73f97v8b3 3ut3//////////////////////////////////////////////////////////////////// ///////4AAD/////////Wvr0Gf///////////////////fvveu/3+9X/er++998Rj/////// ////////////////////////////////////////////////////////////////////+AAA /////////1r69ff///////////////////3t33bv//u5/3c//u3f+/////////////////// //////////////////////////////////////////////////////////gAAP////////87 du33v//////////////////+Hj8PH//4ff8Pv/4eP/v///////////////////////////// ///////////////////////////////////////////////4AAD/////////e44cGH////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////////////////////////////////////+///////////////////////// //////////////////////////////////////////////////////////////////gAAP// ////////////////////////////////////v/////////////////////////////////// ///////////////////////////////////////////////////////4AAD///////////// /////////////////////egvQb3uOHBh99eg+G9X9wQ///////////////////////////// ////////////////////////////////////////////+AAA/////////4b2G9X9wQ////// //////////3r7t/9zdu33vfXb/evV/d93/////////////////////////////////////// //////////////////////////////////gAAP////////965evV/d93///////////////9 6+7f/avr1/74N2//r1f3fe////////////////////////////////////////////////// ///////////////////////4AAD/////////etfr1f3fe////////////////evt3/2r69f5 +7bv/m9X933v//////////////////////////////////////////////////////////// ////////////+AAA/////////3rXm9X933v///////////////wIIMH9a+vQZ/1wYPngUPcF 7/////////////////////////////////////////////////////////////////////// //gAAP////////96tngUPcF7///////////////96+9f/Wvr19/9d6/371f3fe////////// ///////////////////////////////////////////////////////////////4AAD///// /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// ////////////////////////////////////////////////////+AAA//////3//3p169X9 33f///////+///////3oIMH97jhwYf7wYPhvUEEEP/////7///////////////////////// //////////////////////////////////////////gAAP/////9//969hvUEEEP//////// H//////////////////////////////////+//////////////////////////////////// ///////////////////////////////4AAD//////f///////////////////y////////// /////////////////////////v////////////////////////////////////////////// ////////////////////+AAA//////3///////////////////63//////////////////// //////////////7///////////////////////////////////////////////////////// //////////gAAP/////9///////////////////+u/////////////////////////////// ///+///////////////////////////////////////////////////////////////////4 AAD//////f///////////////////b3//////////////////////////////////v////// ////////////////////////////////////////////////////////////+AAA//////3/ //////////////////2+//////////////////////////////////7///////////////// //////////////////////////////////////////////////gAAP/////9//////////// ///////7v3/////////////////////////////////+//////////////////////////// ///////////////////////////////////////4AAD//////f//////////////////+7// /////////////////////////////////v////////////////////////////////////// ////////////////////////////+AAA//////3///////////////////+///////////// //////////////////////7///////////////////////////////////////////////// //////////////////gAAP/////9////////////////////v/////////////////////// ///////////+//////////////////////////////////////////////////////////// ///////4AAD//////f///////////////////7////////////////////////////////// /v//////////////////////////////////////////////////////////////////+AAA //////3///////////////////+///////////////////////////////////7///////// //////////////////////////////////////////////////////////gAAP/////9//// ////////////////v//////////////////////////////////+//////////////////// ///////////////////////////////////////////////4AAD//////f////////////// /////7///////////////////////////////////v////////////////////////////// ////////////////////////////////////+AAA//////3///////////////////+///// //////////////////////////////7///////////////////////////////////////// //////////////////////////gAAP/////9////////////////////v/////////////// ///////////////////+//////////////////////////////////////////////////// ///////////////4AAD//////f///////////////////7////////////////////////// /////////v////////////////////////////////////////////////////////////// ////+AAA//////3///////////////////+///////////////////////////////////3/ //////////////////////////////////////////////////////////////////gAAP// ///9////////////////////v//////////////////////////////////9//////////// ///////////////////////////////////////////////////////4AAD//////f////// /////////////7///////////////////////////////////f////////////////////// ////////////////////////////////////////////+AAA//////3///////////////// //+///////////////////////////////////3///////////////////////////////// //////////////////////////////////gAAP/////9////////////////////v/////// ///////////////////////////9//////////////////////////////////////////// ///////////////////////4AAD//////f///////////////////7////////////////// /////////////////f////////////////////////////////////////////////////// ////////////+AAA//////3///////////////////+///////////////////////////// /////v3///////////////////////////////////////////////////////////////// //gAAP/////9////////////////////v/////////////////////////////////99//// ///////////////////////////////////////////////////////////////4AAD///// /f///////////////////7//////////////////////////////////ff7///////////// ////////////////////////////////////////////////////+AAA/////93///////// //////////+//////////////////////////////////739//////////////////////// //////////////////////////////////////////gAAP/////t//////////////////// v/////////////////////////////////+9+/////////////////////////////////// ///////////////////////////////4AAD/////7d///////////////////7////////// ////////////////////////3ff///////////////////////////////////////////// ////////////////////+AAA//////W///////////////////+///////////////////// /////////////93P//////////////////////////////////////////////////////// //////////gAAP/////0f///////////////////v/////////////////////////////// ///tv//////////////////////////////////////////////////////////////////4 AAD/////+f///////////////////7//////////////////////////////////9X////// ////////////////////////////////////////////////////////////+AAA+AAAAAAA AAAAf/////////////+///////////////////////////////////T///////////////// //////////////////////////////////////////////////gAAPv////9/////3//wAAA AAAAAAAAAAAAAAAAAAAAAAAAA//////////////////5//////////////////////////// ///////////////////////////////////////4AAD7//////////9//9////////////// //////////////v/////////////////+f////////////////////////////////////// ////////////////////////////+AAA+///////////f//f//////////////////////// ///7/////////4AAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////////////////////// //////////////////gAAPv//////////3//3///////////////////////////+/////// //+///////////////////////////7///////////////////////////////////////// ///////4AAD7//////////9//9////////////////////////////v/////////v/////// ///////////////////+////////////////////////////////////////////////+AAA +///////////f//f///////////////////////////7/////////7////////////////// /////////v////////////////////////////////////////////////gAAPv///////// /3//3///////////////////////////+/////////+///////////////////////////7/ ///////////////////////////////////////////////4AAD7//////////9//9////// //////////////////////v/////////v//////////////////////////+//////////// ////////////////////////////////////+AAA+///////////f//f//////////////// ///////////7/////////7///////////////////////////v////////////////////// //////////////////////////gAAPv//////////3//3/////////////////////////// +/////////+///////////////////////////7///////////////////////////////// ///////////////4AAD7//////////9//9////////////////////////////v///////// v//////////////////////////+//////////////////////////////////////////// ////+AAA+///////////f//f///////////////////////////7/////////7////////// /////////////////v////////////////////////////////////////////////gAAPv/ /////////3//3///////////////////////////+/////////+///////////////////// //////7////////////////////////////////////////////////4AAD7//////////9/ /9////////////////////////////v/////////v//////////////////////////+//// ////////////////////////////////////////////+AAA+6ct3G//////f//f//////// ///////////////////7/////////7///////////////////////////v////////////// //////////////////////////////////gAAPuazduv/////3//3/////////////////// ////////+/////////+///////////////////////////7///////////////////////// ///////////////////////4AAD7uu3b7/////9//9////////////////////////////v/ ////////v/+XYzKY+nLdxv/////////////+//////////////////////////////////// ////////////+AAA+7rt2C//////f//f///////////////////////////7/////////7// t11st3ms3br//////////////v////////////////////////////////////////////// //gAAPua7dun/////3//3///////////////////////////+/////////+//7d7brf7rt2+ //////////////7////////////////////////////////////////////////4AAD7puiM a/////9//9////////////////////////////v/////////v/+3Z3Cwe67dgv////////// ///+////////////////////////////////////////////////+AAA+7/93///////f//f ///////////////////////////7/////////7//s11ut3mu3bp//////////////v////// //////////////////////////////////////////gAAPu//u///////3//3/////////// ////////////////+/////////+//xViMRj6bojGv/////////////7///////////////// ///////////////////////////////4AAD7//////////9//9////////////////////// //////v/////////v/+//3+/+//d///////////////+//////////////////////////// ////////////////////+AAA+///////////f//f///////////////////////////7//// /////7//v39/v/v/7v///////////////v////////////////////////////////////// //////////gAAPv//////////3//3//ZTG7/////////////////////+/////////+///// //////////////////////7////////////////////////////////////////////////4 AAD7//////////9//9//1luu//////////////////////v/////////v/////////////// ///////////+////////////////////////////////////////////////+AAA+/////// ////f//f/9db7v/////////////////////7/////////7////////////////////////// /v////////////////////////////////////////////////gAAPv//////////3//3//Y W+7/////////////////////+/////////+///////////////////////////7///////// ///////////////////////////////////////4AAD7l2MymP////9//9//11um//////// //////////////v/////////v//////////////////////////+//////////////////// ////////////////////////////+AAA+7ddbLd/////f//f/9iMaf////////////////// ///7/////////7///////////////////////////v////////////////////////////// //////////////////gAAPu3e263/////3//3//f3+//////////////////////+/////// //+///////////////////////////7///////////////////////////////////////// ///////4AAD7t2dwsH////9//9//39/v//////////////////////v/////////v/////// ///////////////////+////////////////////////////////////////////////+AAA +7Ndbrd/////f//f///////////////////////////7/////////7////////////////// /////////v////////////////////////////////////////////////gAAPsVYjEY//// /3//3///////////////////////////+/////////+///////////////////////////7/ ///////////////////////////////////////////////4AAD7v/9/v/////9//9////// //////////////////////v/////////v//////////////////////////+//////////// ////////////////////////////////////+AAA+79/f7//////f//f//////////////// ///////////7/////////7///////////////////////////v////////////////////// //////////////////////////gAAPv//////////3//3/////////////////////////// +/////////+///////////////////////////7///////////////////////////////// ///////////////4AAD7//////////9//9////////////////////////////v///////// v//////////////////////////+//////////////////////////////////////////// ////+AAA+///////////f//f///////////////////////////7/////////7////////// /////////////////v////////////////////////////////////////////////gAAPv/ /////////3//3///////////////////////////+/////////+AAAAAAAAAAAAAAAAAAAAA AAAAAAD////////////////////////////////////////////////4AAD7//////////9/ /9////////////////////////////v///////////////////////////////////////// ////////////////////////////////////////////+AAA+AAAAAAAAAAAf//AAAAAAAAA AAAAAAAAAAAAAAAAAAAD//////////////////3///////////////////////////////// //////////////////////////////////gAAP//////////////////////////v/////// ///////////////////////////9//////////////////////////////////////////// ///////////////////////4AAD//////v///////////////////x////////////////// /////////////////f////////////////////////////////////////////////////// ////////////+AAA//////7///////////////////yf//////////////////////////// //////3///////////////////////////////////////////////////////////////// //gAAP/////+///////////////////7r//////////////////////////////////9//// ///////////////////////////////////////////////////////////////4AAD///// /v//////////////////97f//////////////////////////////////f////////////// ////////////////////////////////////////////////////+AAA//////7///////// /////////++7//////////////////////////////////3///////////////////////// //////////////////////////////////////////gAAP/////+//////////////////// u//////////////////////////////////9//////////////////////////////////// ///////////////////////////////4AAD//////v///////////////////73///////// /////////////////////////f////////////////////////////////////////////// ////////////////////+AAA//////7///////////////////+///////////////////// //////////////v///////////////////////////////////////////////////////// //////////gAAP/////+////////////////////v/////////////////////////////// ///7///////////////////////////////////////////////////////////////////4 AAD//////v///////////////////7+/////////////////////////////////+/////// ////////////////////////////////////////////////////////////+AAA//////7/ //////////////////+/f/////////////////////////////////v///////////////// //////////////////////////////////////////////////gAAP/////+//////////// ////////vv/////////////////////////////////7//////////////////////////// ///////////////////////////////////////4AAD//////v///////////////////7n/ ////////////////////////////////+/////////////////////////////////////// ////////////////////////////+AAA//////7///////////////////+3//////////// //////////////////////v///////////////////////////////////////////////// //////////////////gAAP/////+////////////////////AAAAAAAAAAAAAAAAAD////// ///////////7//////////////////////////////////////////////////////////// ///////4AAD//////v///////////////////5/////////////////AAAAAAAAAAAAAAAAA A///////////////////////////////////////////////////////////////////+AAA //////7///////////////////+n//////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP/////+//// ////////////////uf////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD//////v////////////// /////77///////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////7///////////////////+///// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP/////+////////////////////v/////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD//////v///////////////////7////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////7///////////////////+///////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// ///+////////////////////v/////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD//////v////// /////////////7////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////7///////////////// //+///////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP/////+////////////////////v/////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD//////v///////////////////7////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////7////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAf//////////// //////////////////////////////////////////////////////////////////////// //gAAP/////+////////9///////////////////////////3/////////////////////// ///////////////////////////////////////////////////////////////4AAD///// /v////////f//////////////////////////9////////////////////////////////// ////////////////////////////////////////////////////+AAA//////7////////3 ///////////////////////////f//////////////////////////////////////////// //////////////////////////////////////////gAAP/////+////////9/////////// ////////////////3/////////////////////////////////////////////////////// ///////////////////////////////4AAD//////v////////f///////////////////// /////9////////////////////////////////////////////////////////////////// ////////////////////+AAA//////7////////3///////////////////////////f//// //////////////////////////////////////////////////////////////////////// //////////gAAP/////+////////9///////////////////////////3/////////////// ///////////////////////////////////////////////////////////////////////4 AAD//////v////////f//////////////////////////9////////////////////////// ////////////////////////////////////////////////////////////+AAA//////7/ ///////3///////////////////////////f//////////////////////////////////// //////////////////////////////////////////////////gAAP/////+////////9/// ////////////////////////3/////////////////////////////////////////////// ///////////////////////////////////////4AAD//////v////////f///////////// /////////////9////////////////////////////////////////////////////////// ////////////////////////////+AAA//////7////////3//////////////////////// ///f//////////////////////////////////////////////////////////////////// //////////////////gAAP//////f///////9///////////////////////////3/////// //////////////////////////////////////////////////////////////////////// ///////4AAD//////3////////f//////////////////////////9////////////////// ////////////////////////////////////////////////////////////////////+AAA //////9////////3///////////////////////////f//////////////////////////// //////////////////////////////////////////////////////////gAAP//////f/// ////9///////////////////////////3/////////////////////////////////////// ///////////////////////////////////////////////4AAD//////3////////f8uxmU x9OW7jf//////////////9////////////////////////////////////////////////// ////////////////////////////////////+AAA//////9////////3/brrZbvNZu3X//// ///////////f//////////////////////////////////////////////////////////// //////////////////////////gAAP//////f///////9/2723W/3Xbt9/////////////// 3/////////////////////////////////////////////////////////////////////// ///////////////4AAD//////3////////f9uzuFg9127Bf//////////////9////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////9////////3/ZrrdbvNdu3T///////////////f//////////////////// //////////////////////////////////////////////////////////////////gAAP// ////f///////9/irEYjH03RGNf//////////////3/////////////////////////////// ///////////////////////////////////////////////////////4AAD//////3////// //f9//v9/9/+7////////////////9////////////////////////////////////////// ////////////////////////////////////////////+AAA//////9////////3/fv7/f/f /3f////////////////f//////////////////////////////////////////////////// //////////////////////////////////gAAP//////f///////9/////////////////// ////////3/////////////////////////////////////////////////////////////// ///////////////////////4AAD//////3////////f//////////////////////////9// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////9////////3///////////////////////////f//////////// //////////////////////////////////////////////////////////////////////// //gAAP//////f///////9///////////////////////////3/////////////////////// ///////////////////////////////////////////////////////////////4AAD///// /3////////f//////////////////////////9////////////////////////////////// ////////////////////////////////////////////////////+AAA//////9////////3 ///////////////////////////f//////////////////////////////////////////// //////////////////////////////////////////gAAP//////f///////9/////////// ////////////////3/////////////////////////////////////////////////////// ///////////////////////////////4AAD//////3////////f///////////////////// /////9////////////////////////////////////////////////////////////////// ////////////////////+AAA//////9////////3///////////////////////////f//// //////////////////////////////////////////////////////////////////////// //////////gAAP//////f///////9///////////////////////////3/////////////// ///////////////////////////////////////////////////////////////////////4 AAD//////3////////f//////////v///////////////9////////////////////////// ////////////////////////////////////////////////////////////+AAA//////9/ ///////3//////////7////////////////f//////////////////////////////////// //////////////////////////////////////////////////gAAP//////f///////8AAA AAAAAAAAAAAAAAAAAAAAAAAAH/////////////////////////////////////////////// ///////////////////////////////////////4AAD//////3///////////////////H// //////////////////////////////////////////////////////////////////////// ////////////////////////////+AAA//////9///////////////////q///////////// //////////////////////////////////////////////////////////////////////// //////////////////gAAP//////f//////////////////6v/////////////////////// //////////////////////////////////////////////////////////////////////// ///////4AAD//////3//////////////////9t////////////////////////////////// ////////////////////////////////////////////////////////////////////+AAA //////9//////////////////+7v//////////////////////////////////////////// //////////////////////////////////////////////////////////gAAP//////f/// ///////////////u7/////////////////////////////////////////////////////// ///////////////////////////////////////////////4AAD//////3////////////// ////3vf///////////////////////////////////////////////////////////////// ////////////////////////////////////+AAA//////9///////////////////73//// //////////////////////////////////////////////////////////////////////// //////////////////////////gAAP/////3ff/////////////////++/////////////// //////////////////////////////////////////////////////////////////////// ///////////////4AAD/////+3v//////////////////v////////////////////////// //////////////////////////////////////////////////////////////////////// ////+AAA//////t3//////////////////7///////////////////////////////////// //////////////////////////////////////////////////////////////////gAAP// ///9b//////////////////+//////////////////////////////////////////////// ///////////////////////////////////////////////////////4AAD//////W////// /////////////v////////////////////////////////////////////////////////// ////////////////////////////////////////////+AAA//////5f//////////////// //7///////////////////////////////////////////////////////////////////// //////////////////////////////////gAAP/////+P//////////////////+//////// //////////////////////////////////////////////////////////////////////// ///////////////////////4AAD//////3///////////////////v////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB///////////////////////////////////////////////////////////// //gAAP///f/////////////////////+//////////////////////////////////////// f//////////////////////////////////////////////////////////////4AAD///3/ /////////////////////v///////////////////////////////////////3////////// ////////////////////////////////////////////////////+AAA///9//////////// //////////7///////////////////////////////////////9///////////////////// //////////////////////////////////////////gAAP///f/////////////////////+ ////////////////////////////////////////f/////////////////////////////// ///////////////////////////////4AAD///3//////////////////////v////////// /////////////////////////////3////////////////////////////////////////// ////////////////////+AAA///9//////////////////////7///////////////////// //////////////////9///////////////////////////////////////////////////// //////////gAAP///f/////////////////////+//////////////////////////////// ////////f//////////////////////////////////////////////////////////////4 AAD///3//////////////////////////////////////////////////////////////3// ////////////////////////////////////////////////////////////+AAA///9//// //////////////////////////////////////////////////////////9///////////// //////////////////////////////////////////////////gAAP///f////////////// ////////////////////////////////////////////////f/////////////////////// ///////////////////////////////////////4AAD///3/////////8spl6csf//////// /////////////////////////////////////3////////////////////////////////// ////////////////////////////+AAA///9/////////+yy2eay7/////////////////// //////////////////////////9///////////////////////////////////////////// //////////////////gAAP///f/////////uut3uu9////////////////////////////// ////////////////f/////////////////////////////////////////////////////// ///////4AAD///3/////////7sLh7rs///////////////////////////////////////// /////3//////////////////////////////////////////////////////////////+AAA ///9/////////+y63ea67/////////////////////////////////////////////9///// //////////////////////////////////////////////////////////gAAP///f////// ///yxGPpux//////////////////////////////////////////////f/////////////// ///////////////////////////////////////////////4AAD///3//////////v7/7/// /////////////////////////////////////////////3////////////////////////// ////////////////////////////////////+AAA///9//////////7+/+////////////// //////////////////////////////////9///////////////////////////////////// //////////////////////////gAAP///f////////////////////////////////////// ////////////////////////f/////////////////////////////////////////////// ///////////////4AAD///3///////////////////////////////////////////////// /////////////3////////////////////////////////////////////////////////// ////+AAA///9//////////////////////////////////////////////////////////// //9///////////////////////////////////////////////////////////////gAAP// /f//////////////////////////////////////////////////////////////f/////// ///////////////////////////////////////////////////////4AAD///3///////// /////////////////////////////////////////////////////3////////////////// ////////////////////////////////////////////+AAA///9//////////////////// //////////////////////////////////////////9///////////////////////////// //////////////////////////////////gAAP///AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/////////////////////////////////////// ///////////////////////4AAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////+AAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //gAAA== --------------A899AB3BC00F093981C7A2CB-- From Yann GUIDON Fri Jan 12 12:58:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00433 for ; Fri, 12 Jan 2001 14:30:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 12 Jan 2001 14:30:22 +0100 (MET) Received: (qmail 29434 invoked by uid 0); 12 Jan 2001 12:04:33 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx09) with SMTP; 12 Jan 2001 12:04:33 -0000 X-eGroups-Return: sentto-1101623-1963-979301067-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 12 Jan 2001 12:04:32 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 12:04:27 -0000 Received: (qmail 24563 invoked from network); 12 Jan 2001 12:04:26 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Jan 2001 12:04:26 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 12 Jan 2001 13:05:31 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA12083; Fri, 12 Jan 2001 04:04:24 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PGT8; Fri, 12 Jan 2001 13:04:23 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5EF15B.A592336F@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 12:58:19 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL (or so it was...) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e15b6103d451653ef8154505f80ae10e Status: R X-Status: N ok, i am happy that new voices are heard on this list.
i thought i was alone to speak with Nico :-)

What to do now ? still work.
i wish i was paid to design the f-cpu with others,
but IRL it's different. shit happens.

Al is unhappy ? we can understand. He wants to modify
the organisation ? alright but he should understand
some parameters such as the nature of the project
and the motivation. I am sure that he's not
alone to be unsatisfied, but his point of view is
personal and he can respect other's. Maybe hasn't yet
found the good way to contribute. it's never easy.

He wants to make another CPU ? fine. it's the good solution
if he estimates that there is no satisfying outcome.
Now there are some things that i hope he will answer :
- you start a project as a reaction and with anger.
you don't start with a utopy or an architecture,
but you start from the organisation and the outcome.
What will succeed first ? an slow project or an empty one ?
- f-cpu has a long story (even though not everybody knows it,
but we do, more or less, right ?) and it has slowly built
an identity and a coherent architecture. Now you want to
make a project (more than a CPU) it seems. you'll define
milestones and goals but who will contribute under pressure ?
will the deadlines influence the quality of the code and
the architecture ? how will you cope with the endless
discussions that never fail to appear ?
- last point : waste of time and saliva. You have three
solutions and you have tried them all :
* lurk, stay mute for a while and then shout out because
you see nothing happen.
* criticize and try to change things, but you expect
others to do what you ask.
* angry, you create a clone that will be shape with your
image, but your behaviour doesn't change : you expect
others to do everything and you wish you can make some
money with it in the end, just to realize your dream
(if i have correctly understood).
My point is : do what you say, don't expect much from others.
you'll have more results if you start yourself or find
a way to integrate your work into a larger frame.
if the frame's shape doesn't satify you, make a new
one, don't expect others to do it for you.
* If you stay silent, there's no wonder nothing goes the way you
like. we can't read in your mind.
* if you want things to change, make an effort and show
the first signs. don't ask. To refresh your memory, that's
how i was hooked by the f-cpu for good : remember the SRB ?
When there was a problem with the register backup, i proposed
a simple, convenient and efficient solution that could be
integrated transparently in the existing design.
OTOH, you want to change everything : no wonder noone wants
to throw away what was so difficult to build. This doesn't
satisfies me either, but "that's how it works".
If you proposed a simple and easy solution, it would be followed.
but when a big undertaking is necessary, you have no chance
to convince if you don't do anything in the direction you show.
You know, it's like when a group has to cross a bridge made
of ropes, about a huge ravine. And you say : "i used
it recently, it's safe". noone will cross before you've
crossed the bridge yourself. Instead, you stay and treat us
as cowards.

In the end, we lost the initial goal of the project : design.
I would like to spend much more time to design and document.
i'm sure others do. so : "design and let design".
it's not the army, here.

thanks for not reading,
YG
PS : 1 pm ? time to "eat and let eat"...
eGroups Sponsor
Click Here!
From Alan Grimes Fri Jan 12 15:17:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00599 for ; Sat, 13 Jan 2001 02:29:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:29:54 +0100 (MET) Received: (qmail 25715 invoked by uid 0); 12 Jan 2001 14:15:54 -0000 Received: from mq.egroups.com (208.50.144.79) by 10.1.4.119 (mx19) with SMTP; 12 Jan 2001 14:15:54 -0000 X-eGroups-Return: sentto-1101623-1964-979308935-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 12 Jan 2001 14:15:51 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 14:15:35 -0000 Received: (qmail 37344 invoked from network); 12 Jan 2001 14:15:12 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 12 Jan 2001 14:15:12 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta1 with SMTP; 12 Jan 2001 14:15:12 -0000 Received: from 66-44-63-121.s375.tnt5.lnhva.md.dialup.rcn.com ([66.44.63.121] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14H4yz-00038T-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 09:15:10 -0500 Message-ID: <3A5F11F3.C4B72E7F@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 09:17:23 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d1be1bde9d8e2e27536186f972016128 Status: R X-Status: N Keyshaun wrote:

> I consider the writing of the manual to be just as big as the writing
> of the VHDL.

I looked at the manual last night...
It seemed like it would be better to put the first chapter into a set of
seperate controlled documents.

During development the manual should be broken down as much as possible
and then integrated in such a way that it matches the packaged chip in a
1:1 ratio.

Second there were too many groupings of optional instructions..
That makes things much more difficult... Remember in the days of the
386, you had your base set and then an optional group that you could add
by inserting a 387. Anything more complex will give your compiler a
migrane...

Let me lay out my proposal here...

A 64x64 register file will take aeons to swap... Its only advantage is
that it allows for very large programs and eliminates the need for
"register renaming" because the compiler can just "move down" when it
wants something done in paralell. =) So what I want to do is keep the
register file as it is but also allow for fine-grained object
orrientation.

The solution is clear if not simple... Use a two tiered system. The base
will be a MISC core that is essentially a FORTH CPU with 8 bit
instruction words. Its advantage is that calls and returns are
practicaly free of overhead. Then on top of that a RISC level can be
implemented with the same instruction set but three more bytes for
register naming.

This will let you have your cake and eat it too. You can compile your
heuristical stuff into a MISC stream and then your data-stream stuff
into your RISC stream. =)

> Well, all hail Srouceforge since people don't know how to manage their
> own projects.

Okay, explain to me F-CPU's current version control and job managment
system.


> Oh yes, it's terrible that I had to speak up and ask to get a
> recommendation on a book.  I would rather get a suggestion from saying
> "I need <this>" what should I get?  Than just looking at a list of
> books.

Problem: I seldom know what <this> evaluates to. =\


> For the record C is a very powerful language if used correctly.  nuff
> said.

You have not taken the time to learn a REAL language.
Read up on Forth and LISP. =)

> > No.
> > I'd get mad at him for cloning a bad OS. ;)
>
> now for the nitpicky...  Linux isn't an OS.  GNU/Linux is.  Linux is a
> kernel.  While Linux is what you call a UNIX clone it is only because
> the design methods for UNIX were well thought out.

No, they aren't. =\
MVS seems to be but I don't know enough about it...
You may think unix is flexable for being able to run on your plamtop as
well as your server. I think unix is horribly and unforgivably
inflexable for doing things exactly the same way on both platfroms...

>   As a programmer I would rather have a powerful program interface
> (POSIX) over anything else.

Posix is weak, kludgy, and obsolescant.


> I have 2 options.  Lame MS Windows, or stable text interface with a
> little bit of X.  Oh and did I mention better dev tools than windows?

I don't have any option.
Linux is unusable.
BeOS crashes and is underdeveloped, not that much better than linux
either. =(
Windows 3.11 plods along and functions at an acceptable level.


> Simply do it better, create a better OS, and than people will apreciate
> your work.

Oh yeah, Simply grant me $20,000,000 and I'll give you something that is
almost as functional as windows 3.11 and has a compatability list of a
dozen or so products...

You have no idea how hard it is to write an OS...
Especially these days! =\

> In my point of view I have not seen any better OS than Linux.
> (I have tried win95/98/2000/nt4, NeXtStep, OpenStep, OS/2, DOS, ....)

I have not seen a single OS that could make a valid claim of being
better (more usable; more compatable) than DOS. ;)

> Could you explain what is bad at Unixish OSes ??

vi
emacs
Look at those two and you will understand the vast usability deficit
that I keep screaming about, then extrapolate it for an entire
distribution...

As I mentioned above, there is only ONE way to do things in a UNIX OS,
wheather that suits your needs or not, you're stuck.

The way functions are "factored" togeather to make the OS is all wrong.
It places many high-level features into the core system. When you get
UNIX you get it all at once. There is no way to simplify or pick and
choose what you want.

Take one look at the learning curve and you'd think you're on the
baddest rollercoaster in the world! =\ AN OS SHOULD BE A TRAIN NOT A
ROLLERCOASTER!!!

Linux developers are the most intelligent morons in the world... They
keep looking for more ingenious ways for doing the WRONG THING!!! =\

I have a design that fixes all of this. I scrapped it because I have
reciently discovered a RADICALLY better way of doing things that I am
still working out the details of... Gonna take me a long while for me to
do that though... =(

> > Perhaps I will upgrade my OS from win 3.11...
> > But It has to be *better* than win 3.11...
>
> Leaving the dark ages?

Yes, certainly!
As soon as both of my conditions are met. ;)

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From Ben Franchuk Fri Jan 12 01:56:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00646 for ; Sat, 13 Jan 2001 02:30:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:03 +0100 (MET) Received: (qmail 2919 invoked by uid 0); 12 Jan 2001 14:57:18 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx01) with SMTP; 12 Jan 2001 14:57:18 -0000 X-eGroups-Return: sentto-1101623-1965-979311409-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 12 Jan 2001 14:57:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 14:56:48 -0000 Received: (qmail 75234 invoked from network); 12 Jan 2001 14:55:47 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 12 Jan 2001 14:55:47 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 12 Jan 2001 15:56:52 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA01225 for ; Fri, 12 Jan 2001 07:49:51 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A5E5650.F0B01E2C@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5F11F3.C4B72E7F@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 11 Jan 2001 17:56:48 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: beb972388effa991a81674cd6aaeba2d Status: R X-Status: N Alan Grimes wrote:

>
> Second there were too many groupings of optional instructions..
> That makes things much more difficult... Remember in the days of the
> 386, you had your base set and then an optional group that you could add
> by inserting a 387. Anything more complex will give your compiler a
> migrane...

How soon people forget all the tricks needed to make 8086 programs compile.
4 STUPID memory models and them more Crap with the 386 code.

> A 64x64 register file will take aeons to swap... Its only advantage is
> that it allows for very large programs and eliminates the need for
> "register renaming" because the compiler can just "move down" when it
> wants something done in paralell. =) So what I want to do is keep the
> register file as it is but also allow for fine-grained object
> orrientation.
It can't do that - registers are still STATIC. They have to be saved
with every major state change.

> The solution is clear if not simple... Use a two tiered system. The base
> will be a MISC core that is essentially a FORTH CPU with 8 bit
> instruction words. Its advantage is that calls and returns are
> practicaly free of overhead. Then on top of that a RISC level can be
> implemented with the same instruction set but three more bytes for
> register naming.

I like forth but a tiny Stack based micro-coded machine is not the way to
go.

> Oh yeah, Simply grant me $20,000,000 and I'll give you something that is
> almost as functional as windows 3.11 and has a compatability list of a
> dozen or so products...
>
> You have no idea how hard it is to write an OS...
> Especially these days! =\

The OS is EASY... Getting manufactures to give out hardware details
is hard. look here for a nice OS.
ftp://ftp.mayn.de/pub/cpm/GEM/INDEX.html

> The way functions are "factored" togeather to make the OS is all wrong.
> It places many high-level features into the core system. When you get
> UNIX you get it all at once. There is no way to simplify or pick and
> choose what you want.

You can always run "HURD" instead of linux.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Alan Grimes Fri Jan 12 16:14:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00652 for ; Sat, 13 Jan 2001 02:30:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:05 +0100 (MET) Received: (qmail 32609 invoked by uid 0); 12 Jan 2001 15:12:55 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx24) with SMTP; 12 Jan 2001 15:12:55 -0000 X-eGroups-Return: sentto-1101623-1966-979312355-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 12 Jan 2001 15:12:53 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 15:12:34 -0000 Received: (qmail 93393 invoked from network); 12 Jan 2001 15:12:20 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Jan 2001 15:12:20 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta3 with SMTP; 12 Jan 2001 16:13:25 -0000 Received: from 66-44-63-121.s375.tnt5.lnhva.md.dialup.rcn.com ([66.44.63.121] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14H5sJ-0004Z1-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 10:12:19 -0500 Message-ID: <3A5F1F58.6E1C3C9@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <3A5F11F3.C4B72E7F@starpower.net> <3A5E5650.F0B01E2C@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 10:14:32 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a2d563fd102d1618b9fb42abdc465d09 Status: R X-Status: N Ben Franchuk wrote:

> How soon people forget all the tricks needed to make 8086 programs
> compile. 4 STUPID memory models and them more Crap with the 386 code.

Yeah! =)
I'm trying to keep it down to two types of streams and only flat
addressing mode... To run Linux, Paging will be implemented and enabled
by the OS during bootup.

> It can't do that - registers are still STATIC. They have to be saved
> with every major state change.

Only in RISC mode. ;)

> I like forth but a tiny Stack based micro-coded machine is not the way
> to go.

It has the advantage of being mature. Otherwise we're stuck in RISC mode
untill someone invents another minimal context MISC sub-machine...

> The OS is EASY... Getting manufactures to give out hardware details
> is hard.

Amen!
I hope you now understand exactly why I show so much intrest in this
project.

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From "Marco Al" Fri Jan 12 17:13:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00692 for ; Sat, 13 Jan 2001 02:30:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:13 +0100 (MET) Received: (qmail 21876 invoked by uid 0); 12 Jan 2001 16:11:10 -0000 Received: from jj.egroups.com (208.50.144.82) by 10.1.4.119 (mx19) with SMTP; 12 Jan 2001 16:11:10 -0000 X-eGroups-Return: sentto-1101623-1967-979315836-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 12 Jan 2001 16:11:07 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 16:10:36 -0000 Received: (qmail 50411 invoked from network); 12 Jan 2001 16:05:31 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Jan 2001 16:05:31 -0000 Received: from unknown (HELO studict.student.utwente.nl) (130.89.220.2) by mta2 with SMTP; 12 Jan 2001 16:05:31 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id RAA07299 for ; Fri, 12 Jan 2001 17:05:29 +0100 (MET) Message-ID: <003801c07cb2$978c4870$29e65982@student.utwente.nl> To: References: <3A5F11F3.C4B72E7F@starpower.net> <3A5E5650.F0B01E2C@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 17:13:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0e8da9c9505154b20e6309323333ab99 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> It can't do that - registers are still STATIC. They have to be saved
> with every major state change.

But what is a major state change? If you mean a context change sure, but
function calls etc are a little more frequent. And there register windows and
stacks can avoid it as long as theres no overflow. Conceivably with a
finegrained protection mechanism even in the case of a context switch it could
be avoided.

> > The solution is clear if not simple... Use a two tiered system. The base
> > will be a MISC core that is essentially a FORTH CPU with 8 bit
> > instruction words. Its advantage is that calls and returns are
> > practicaly free of overhead. Then on top of that a RISC level can be
> > implemented with the same instruction set but three more bytes for
> > register naming.
>
> I like forth but a tiny Stack based micro-coded machine is not the way to
> go.

Why not? For a finegrained reconfigurable processor array I think it could be
pretty good, and that would be much more suited to the DSP type of stuff than
F-CPU with lots of SIMD. Because of long latency of complex instructions you
would get into trouble running traditional serial tasks... but perhaps
simultaneous multiprocessing could come to the rescue?

The compiling would be horrendously complex though, and putting it into hardware
for automatic translation of RISC level codes wont make the task any easier...
more difficult in fact.

> You can always run "HURD" instead of linux.

If only MACH wasnt such a dog, it almost single handedly gave microkernels their
bad name. Now L4, theres a nice microkernel, or Eros if you like security.

Marco
eGroups Sponsor
Click Here!
From Yann GUIDON Fri Jan 12 18:36:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00751 for ; Sat, 13 Jan 2001 02:30:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:34 +0100 (MET) Received: (qmail 1952 invoked by uid 0); 12 Jan 2001 17:49:04 -0000 Received: from unknown (HELO ci.egroups.com) (64.211.240.235) by mx0.gmx.net (mx15) with SMTP; 12 Jan 2001 17:49:04 -0000 X-eGroups-Return: sentto-1101623-1968-979321693-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 12 Jan 2001 17:48:46 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 17:48:11 -0000 Received: (qmail 76706 invoked from network); 12 Jan 2001 17:42:09 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 12 Jan 2001 17:42:09 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 12 Jan 2001 17:42:08 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA15207; Fri, 12 Jan 2001 09:42:07 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PHYZ; Fri, 12 Jan 2001 18:42:05 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A5F4080.A6C8D9FD@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 18:36:00 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] report for today... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f8af8a04c82a9039784939da17fff46f Status: R X-Status: N Hello,
even though i should be doing other "productive tasks" for Mentor,
here are some news that fallen on my back today.

- 1 : trademark operation : the french office refused to register
the name because there was a flaw, or more precisely a missing paper
in the file. We have to restart almost everything from scratch again,
except that here i'll be able to pay the operation.
Will be on the paper, the name of the people who send out a written
authorisation to delegate the responsibility to someone (probably me
:-/)
so this time, the file won't be refused. i'll have to check at the
trademark office, but i'll ask all the participants of last year's
attempt.

- 2 : LNS : got an answer from the leader of the european LNS adder
project.
Cooperation is ok, they have VHDL and working designs, but they can't
give it
out. we'll find maybe a compromise. if this spares us some troubles
with IEEE756, it's worth it :-) more news soon.

- 3 : manual : refresh is ongoing, a french translation is started.
Al proposed to split it down to bytes, well, i think that chapters is
enough. we're still polishing the first parts, so don't except wonders.

hmm i have to leave, they shutdown the server soon...
eGroups Sponsor
Click Here!
From Nicolas Boulay Fri Jan 12 20:35:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00766 for ; Sat, 13 Jan 2001 02:30:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:39 +0100 (MET) Received: (qmail 16375 invoked by uid 0); 12 Jan 2001 19:28:48 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx22) with SMTP; 12 Jan 2001 19:28:48 -0000 X-eGroups-Return: sentto-1101623-1969-979327713-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fg.egroups.com with NNFMP; 12 Jan 2001 19:28:46 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 19:28:32 -0000 Received: (qmail 89089 invoked from network); 12 Jan 2001 19:27:56 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 12 Jan 2001 19:27:56 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 12 Jan 2001 19:27:55 -0000 Received: from ifrance.com (nas15-30.vlt.club-internet.fr [195.36.165.30]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA13063 for ; Fri, 12 Jan 2001 20:27:53 +0100 (MET) Message-ID: <3A5F5C87.2B622D70@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <3A5E41E2.3EE6DB2A@llandre.freeserve.co.uk> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 20:35:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Let's go back to the rock ! Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 66d3e23e718d90057640d01dbedf751e Status: R X-Status: N Hello,

Jeff Davies a =E9crit :
>
> > Until now, nobody have given this point of view about compiler. T= hat's a
> > very difficult task ! It's a very new task to use all that parall= elism
> > in a compiler. We can write this kind of chip, but what happen if= it's
> > very hard to use all that power ?
> >
>
> The simplest way would be manually in the first place. ie. use GCC as = is, and
> make libraries with
> assembler doing the SIMD stuff for some common functions, and then rew= rite some
> programs to
> use this code (like perhaps some accelerator parts of X?).
>

There is not only SIMD, but SMT (in the futur) and, especialy special
instruction of the ISA. But it seems to be the easiest way : rewrite all the STL library of the C++ in ASM !  i have soon propose this, a long<= BR> time ago.

> What is SIMD used for most of the time these days anyway - is it:
> 1. codecs
> 2. geometry transfer (as in geometry transfer engine in playstation 1)= .
> This is matrix maths for rotation, translation in 3d environment.
> 3. I guess SIMD is also used for Texture Fill, Antialiasing, that kind= of thing.
>
> Overall, when you want to do lots and lots of similar instructions ove= r and
> over.
> (like the box says).
>

In fact, it's very common. (each time you use a "for" loop withou= t
depencies between 2 passes)
<snip>
> Jeff Davies
nicO
eGroups Sponsor=
3D"Click
From Nicolas Boulay Fri Jan 12 20:35:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00769 for ; Sat, 13 Jan 2001 02:30:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:40 +0100 (MET) Received: (qmail 8317 invoked by uid 0); 12 Jan 2001 19:29:59 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx09) with SMTP; 12 Jan 2001 19:29:59 -0000 X-eGroups-Return: sentto-1101623-1970-979327788-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 12 Jan 2001 19:29:55 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 19:29:48 -0000 Received: (qmail 25443 invoked from network); 12 Jan 2001 19:28:05 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 12 Jan 2001 19:28:05 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 12 Jan 2001 19:28:04 -0000 Received: from ifrance.com (nas15-30.vlt.club-internet.fr [195.36.165.30]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA13162 for ; Fri, 12 Jan 2001 20:28:01 +0100 (MET) Message-ID: <3A5F5C90.DAA2B423@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 20:35:44 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d7bcb88a9e12acc8b7013b223b260852 Status: R X-Status: N Hello,

Marco Al a =E9crit :
>
> From: Nicolas Boulay <nicolas.boulay@ifrance.com>
>
> > > > Scorebording
> > > > is the easy and first step to do it, but if there is to= much depencies
> > > > the code will as slow as befor.
> > > dunno. we have 63 regs, we can do 3 pipelines with 8 stages,= or 4
> > > pipelines
> > > with 5 stages (execution pipeline, of course). it gives us e= nough time
> > > before we require more physical registers.
> > >
> >
> > Hemm ! In some paper you give the number of "6 gates" b= etween 2
> > flip-flops. Athlon have 14 stages of pipeline. And this stage are= big
> > enought to handle 32 bits adder. So Fcpu will be far above the nu= mber of
> > 14 maybe around 50 !
>
> I think you are overestimating the complexity for a 32 bit adder, in f= act you
> could do it with a logic depth of 2 ;)
>

A simple adder has soon 3 level at least, so...

> > That's not how actual P3 handle register renaming ? Few month ago= , i
> > have think about a system where you don't give a register number = but an
> > offset to a register pointer. So your are virtualy not limited by= the
> > number of register your are just limited for each instruction to = access
> > between -32 and 32th registers near the last register access. But= it
> > could be strange to code, no ?
>
> How is that different from register windows?
>

In a register windows system, only at call, you translate the windows.

> > > > But it's always a limit
> > > > put in the design. SIMD parrallelism are maybe a good w= ay to increase
> > > > speed.
> > > not "speed" but MHz/MOPS ratio. we're safe from th= is POV.
> > > SIMD algos are studied for 20 years now...
> > >
> >
> > Algo, yes. But not compiler !!!!!
>
> Even if you had a good compiler, without lots of loops wich can be unr= olled to a
> sufficient degree its almost useless. SIMD is good for DSP, but if we = are
> serious about general purpose processing we will have to look elsewher= e.
>

No, that's false. SIMD, here are small for 64 bit register you handel
2*32, 4*16,8*8, that's not much, you can use it for lot of different
stuff (Mostly calcul but Excel made some, too ).

> > > > And for each new instruction you
> > > > take an instruction from an other thread. It's like hav= ing a true SMP
> > > > system with 4, 8, 16 or 32 slower processors.
> > > except that it is easier and cheaper.
> > > FC0's execution pipeline could be used but the decoder would= require
> > > a certain amount of rework.
>
> And the MMU if you really wanted it to be equivalent to SMP.
>

True !

> > > > or having a complex scheduling
> > > > unit to know wich thread could be executed, with the bi= g risk to
> > > > recreate register depencies.
> > > the OS kernel is the best place to do this.
> > >
> >
> > Of courses, not. Much far to slow !
>
> Gotta agree, even for vertical multithreading (to have something to on= a cache
> miss) its slow, and for anything more finegrained its useless. IMO the= only
> thing you could do in the OS is switch tasks on misses on remote acces= ses in a
> multiprocessor environment.
>
> > > > So there are lot of problem. The worst is to write a go= od compiler for
> > > > that. How could it be easy to add some thread capabilit= ies ?
> > > the SMT side should be managed by the OS.
> > > If you see a usual UNIX server that handles lots of connexio= ns,
> > > you see that it's the good place.
> > >
> >
> > I don't want this at all. You are going to have big trouble with = the TLB
> > which could become to small. The cache will be always fluched : i= n true
> > thread, code and often datas are shared between the thread. Even = on
> > actual thread, there is no hardwar protection between thread. So = here,
> > to keep the core simple, we need to avoid this. But everybody kno= w that
> > it isn't easy to write code with many threads, so the compiler co= uld do
> > it. So if the number of thread go from 4 to 16, the program shoul= d use
> > the 12 new virtual processor to speed up their code.
>
> A solution is to take it to the extreme, have enough processes to brid= ge main
> memory latency even with the cache pollution (thats the basic idea beh= ind
> Tera/Cray's MT architecture I think). You could instrument the process= or such
> that the OS could schedule processes according to memory locality, if = you have
> plenty of threads working with the same set fine... if not do the best= you can.
>

Reread, the post "Let's go back to the core!" I explain that is t= oo
difficult for the user or compiler to find enought thread in the code,
to fill all this.

> > Until now, nobody have given this point of view about compiler. T= hat's a
> > very difficult task ! It's a very new task to use all that parall= elism
> > in a compiler. We can write this kind of chip, but what happen if= it's
> > very hard to use all that power ?
>
>  Thats the advantage of MP over MT.
>
too many problem ! Just read up.
> > It's always a message to send thought the network thought the fbu= s, so
> > you waste some bandwith. More i think more i beleive that we shou= ld
> > forget the network and concentrate one the chip. At the very begi= nning,
> > it could be very hard to produice more than one chip, the best wa= y to
> > use all the current peripheral is to use PCI bus. The idea to use= PC has
> > "Host" aren't so stupid. You don't have to write all in= terface for each
> > connection. Then you can put 4 card in the same pc if you want. B= ut we
> > focus only on a card with a cpu + SDRAM + PCI link to the host (+= RS232
> > link and JTAG for debugging at the beginning). It seems wise, no = ?
>
> I have thought about it... and I think the easiest and most scalable w= ay to get
> to the PCI bus is via SCI. You can just get a dolphin SCI-PCI bridge a= nd put it
> in a PCI backplane and you have a system, and while I dont think makin= g a SCI
> interface is easy... I doubt its much more difficult than a PCI one. >
> Marco
nicO
eGroups Sponsor=
3D"Click
From Alan Grimes Fri Jan 12 22:59:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00815 for ; Sat, 13 Jan 2001 02:30:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:30:54 +0100 (MET) Received: (qmail 23727 invoked by uid 0); 12 Jan 2001 21:59:57 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx07) with SMTP; 12 Jan 2001 21:59:57 -0000 X-eGroups-Return: sentto-1101623-1973-979336743-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 12 Jan 2001 21:59:47 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 21:59:02 -0000 Received: (qmail 44824 invoked from network); 12 Jan 2001 21:57:16 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 12 Jan 2001 21:57:16 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta1 with SMTP; 12 Jan 2001 21:57:16 -0000 Received: from 66-44-68-202.s202.tnt8.lnhva.md.dialup.rcn.com ([66.44.68.202] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14HCCA-0001Vk-00 for f-cpu@egroups.com; Fri, 12 Jan 2001 16:57:14 -0500 Message-ID: <3A5F7E3F.E2F2466A@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 16:59:27 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Elite inf0z. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d08d805fedd2c234f2b81e9f0793ae63 Status: R X-Status: N If indeed the maintainers of f-cpu.org prefer to respond to e-mail
inquiries from lamers such as myself than to waste preascious time
actually writing a reading list for their site then they wouldn't mind
answering these:

The documentation of the PCI bus can be gotten from PCI SIG for an arm
and a leg...

But where can I get the inf0z for for the ISA bus, including the recient
PNP extensions?

I also need a good general intr0 on FPGAz, I wouldn't want a "For
Dummies" book, rather I would like something that will give me a good
solid foundation of the subject and also serve as an authoratative
refferance... As long as it doesn't go crazy with all this elite
abstract algebra stuff that I don't understand like that "topology" book
I bought. =\

These subjects, and countless hundreds others, should be carefuly
indexed and refferenced similar to the review project over at
www.tunes.org.

I'm not unwilling to contribute to such a list but I only have a few
titles relating to PC hardware which doesn't really relate to the
general chipmaking stuff that should go on this list... The only books I
got on me are:

Theory and design of Digital computer systems; Lewin and Noaks
Computer orgainization and Design: the hardware/software interface;
Patterson, Hennessay
THIS BOOK REALLY SUCKS, it was just used in my comp orgainization class.

Discrete Mathematics and its Applications; Rosen
Hey, its a math book! If you graduated from anywhere with any kind of
computer science degree without taking a course in discrete mathematics
you went to a bad, bogus school that should loose its accredidation. ;)

That isn't much of a list but that's all I have to trade for your
list... =P

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From "Marco Al" Fri Jan 12 22:54:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00827 for ; Sat, 13 Jan 2001 02:31:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:31:01 +0100 (MET) Received: (qmail 12965 invoked by uid 0); 12 Jan 2001 22:41:51 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx21) with SMTP; 12 Jan 2001 22:41:51 -0000 X-eGroups-Return: sentto-1101623-1974-979339296-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 12 Jan 2001 22:41:48 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 12 Jan 2001 22:41:35 -0000 Received: (qmail 63523 invoked from network); 12 Jan 2001 22:40:55 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Jan 2001 22:40:55 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 12 Jan 2001 22:40:54 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id C63422908 for ; Fri, 12 Jan 2001 23:40:53 +0100 (CET) Message-ID: <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 22:54:29 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 07ea7cab0f07af6f57ff5b77e2e22230 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> > I think you are overestimating the complexity for a 32 bit adder, in fact
you
> > could do it with a logic depth of 2 ;)
> >
>
> A simple adder has soon 3 level at least, so...

With 64 input and/or gates... :) (consider it from the truth table POV)

> In a register windows system, only at call, you translate the windows.

You can always fake it.

>  No, that's false. SIMD, here are small for 64 bit register you handel
> 2*32, 4*16,8*8, that's not much, you can use it for lot of different
> stuff (Mostly calcul but Excel made some, too ).

A lot perhaps, but not enough IMO.

> > A solution is to take it to the extreme, have enough processes to bridge
main
> > memory latency even with the cache pollution (thats the basic idea behind
> > Tera/Cray's MT architecture I think). You could instrument the processor
such
> > that the OS could schedule processes according to memory locality, if you
have
> > plenty of threads working with the same set fine... if not do the best you
can.
> >
>
> Reread, the post "Let's go back to the core!" I explain that is too
> difficult for the user or compiler to find enought thread in the code,
> to fill all this.

I was thinking more of a server environment, with plenty of single and
multi-threaded processes running concurrently.

> >  Thats the advantage of MP over MT.
> >
> too many problem ! Just read up.

Apart from having fears of not having enough to do, which IMO goes counter your
SIMD argument (if its suitable to extract SIMD instructions from, then its
likely more than suitable to extract micro-threads from), those problems boil
down to two... poor locality, which I dont think is insurmountable, and the need
for a lot of protection domains in hardware... which IMO is a good thing, even
with added complexity.

Marco
eGroups Sponsor
Click Here!
From Keyshaun Sat Jan 13 01:55:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00866 for ; Sat, 13 Jan 2001 02:31:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 02:31:14 +0100 (MET) Received: (qmail 25829 invoked by uid 0); 13 Jan 2001 01:05:23 -0000 Received: from unknown (HELO ho.egroups.com) (64.211.240.236) by 10.1.4.106 (mx06) with SMTP; 13 Jan 2001 01:05:23 -0000 X-eGroups-Return: sentto-1101623-1975-979346942-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 13 Jan 2001 00:49:17 -0000 X-Sender: thekernel@subdimension.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Jan 2001 00:49:00 -0000 Received: (qmail 88847 invoked from network); 13 Jan 2001 00:48:58 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 13 Jan 2001 00:48:58 -0000 Received: from unknown (HELO dalaena.home.kru) (207.173.107.104) by mta3 with SMTP; 13 Jan 2001 01:50:03 -0000 Received: from cisco.home.kru ([172.17.1.50] helo=dalaena.home.kru) by dalaena.home.kru with esmtp (Exim 3.12 #1 (Debian)) id 14HEyx-00027N-00 for ; Fri, 12 Jan 2001 17:55:47 -0700 X-X-Sender: To: In-Reply-To: <003801c07cb2$978c4870$29e65982@student.utwente.nl> Message-ID: From: Keyshaun MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 17:55:47 -0700 (MST) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] VHDL Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1052831cae630693ff0b35f23e0f20ef Status: R X-Status: N > If only MACH wasnt such a dog, it almost single handedly gave microkernels their
> bad name. Now L4, theres a nice microkernel, or Eros if you like security.

If I may insert something...  We must all remember that MACH was made by
people who were technicaly called students.  It was designed with the
purpose of studying a microkernel architecture.  I would never fault the
people at the University of Utah (my local university) for its "poor
quality".  Besides Linux is a good enough kernel.  I like it because it is
stable, scalable, and most of all alterable.

Shaun
eGroups Sponsor
Click Here!
From Yann Guidon Sat Jan 13 16:43:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA03101 for ; Sat, 13 Jan 2001 17:04:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 17:04:00 +0100 (MET) Received: (qmail 2259 invoked by uid 0); 13 Jan 2001 15:37:56 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx15) with SMTP; 13 Jan 2001 15:37:56 -0000 X-eGroups-Return: sentto-1101623-1976-979400256-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 13 Jan 2001 15:37:55 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Jan 2001 15:37:36 -0000 Received: (qmail 17169 invoked from network); 13 Jan 2001 15:37:35 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 13 Jan 2001 15:37:35 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 13 Jan 2001 15:37:34 -0000 Received: from f-cpu.org (nas1-223.aub.club-internet.fr [195.36.150.223]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA23856 for ; Sat, 13 Jan 2001 16:37:32 +0100 (MET) Message-ID: <3A6077A6.F6C24BDE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 13 Jan 2001 16:43:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SHIFT LEFT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab5bb9f823ad1ee722f441c37c12f873 Status: R X-Status: N hi,

Jeff Davies wrote:
> > now my worry is about the SHL unit. a rough estimate gave a Omega network
> > with 3 layers of 16 shufflers of 4 inputs and 4 outputs.
> > Maybe with a 4 in/8 out, we can do something better ?
> > Sign extension is still worrying...
> > grrrr.... we need another genius : Michael is busy with the multiplier.
> > Can anybody make some netsearches on this matter ?...
> >
> > > nicO
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Here is my offering which probably won't do since it only shifts one bit at a time.
> You probably want a shift left n bits kind of unit.
right. in theory, we can shift / rotate 64 bits within the critical datapath constraints.
In practice, it's much more difficult. that's why a netsearch and a search in the
existing bibliography would help save some time...
Is there a barrel shifter specialist in the room ?

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Marco Al" Sat Jan 13 17:35:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA03705 for ; Sat, 13 Jan 2001 19:01:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 13 Jan 2001 19:01:13 +0100 (MET) Received: (qmail 932 invoked by uid 0); 13 Jan 2001 16:27:38 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 13 Jan 2001 16:27:38 -0000 X-eGroups-Return: sentto-1101623-1977-979403242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 13 Jan 2001 16:27:34 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 13 Jan 2001 16:27:21 -0000 Received: (qmail 56009 invoked from network); 13 Jan 2001 16:27:21 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 13 Jan 2001 16:27:21 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 13 Jan 2001 17:28:26 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 6FB9B2B81 for ; Sat, 13 Jan 2001 17:27:20 +0100 (CET) Message-ID: <000501c07d7e$d0616910$29e65982@student.utwente.nl> To: References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> <3A6077A6.F6C24BDE@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 13 Jan 2001 17:35:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] SHIFT LEFT Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 595e2c9dd4ef5b0463cf7f37e3262dd7 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> right. in theory, we can shift / rotate 64 bits within the critical datapath
constraints.
> In practice, it's much more difficult. that's why a netsearch and a search in
the
> existing bibliography would help save some time...
> Is there a barrel shifter specialist in the room ?
>
> > Jeff Davies
> WHYGEE

I doubt it... but Im curious, whats the problem with just using a log-2 shifter?

BTW are you sure the standard cell library wont have a barrel shifter? To me the
most straightforward implementation would seem to be with pass transistors,
regardless of wether you use a barrel/log/whatever shifter, which we cant use
ourselves.

Marco
eGroups Sponsor
Click Here!
From Yann Guidon Sun Jan 14 02:44:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06127 for ; Sun, 14 Jan 2001 17:08:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:01 +0100 (MET) Received: (qmail 11690 invoked by uid 0); 14 Jan 2001 01:38:36 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx04) with SMTP; 14 Jan 2001 01:38:36 -0000 X-eGroups-Return: sentto-1101623-1979-979436301-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 14 Jan 2001 01:38:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 01:38:20 -0000 Received: (qmail 7050 invoked from network); 14 Jan 2001 01:38:20 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 14 Jan 2001 01:38:20 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 14 Jan 2001 01:38:20 -0000 Received: from f-cpu.org (nas1-139.ras.club-internet.fr [195.36.192.139]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26482 for ; Sun, 14 Jan 2001 02:38:15 +0100 (MET) Message-ID: <3A610472.212F0CAD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 02:44:18 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FCPU-Newbie... questions to VHDL-compiler, TODO-list... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ce4eeed53f0f20ff973656410a4a72e Status: R X-Status: N hello,

i didn't answer because i thought that we had enough websites like that...

but now, i realize that if at least someone could be more responsible of less
parts, (that is : spending more time to do a specific task correctly),
we decidedly need a CVS repository. Things are going slowly with

Gregory Junker wrote:
>
> > other contributions required : website management (who wants to be
> > webmaster ?)
>
> does the site have to be in or on a particular place/nation/continent? The
> reason I ask is I have dedicated bandwidth to offer, and whatever server
> hardware is needed for http, ftp, cvs, dns, email/list, whatever is
> required. The hardware would be located in the U.S. midwest (think Alsace
> without the wine). Access for the principals, and as soon as I get my
> Electronics Workbench licenses I might even start in on the VHDL...after
> all, it would be a waste of a good Computer Engineering degree on simple
> software development :)
>
> > manual foolproofer, CVS maintainer... you can read the list in some of
> > the latest
> > 20 messages :-)

--
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sun Jan 14 02:44:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06130 for ; Sun, 14 Jan 2001 17:08:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:01 +0100 (MET) Received: (qmail 11096 invoked by uid 0); 14 Jan 2001 01:40:10 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx08) with SMTP; 14 Jan 2001 01:40:10 -0000 X-eGroups-Return: sentto-1101623-1978-979436301-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 14 Jan 2001 01:38:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 01:38:21 -0000 Received: (qmail 38039 invoked from network); 14 Jan 2001 01:38:20 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 Jan 2001 01:38:20 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 14 Jan 2001 02:39:25 -0000 Received: from f-cpu.org (nas1-139.ras.club-internet.fr [195.36.192.139]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA26484 for ; Sun, 14 Jan 2001 02:38:17 +0100 (MET) Message-ID: <3A610474.DC843359@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5D91EE.2A16C9C4@mentor.com> <20010111153347.49057@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 02:44:20 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] todo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b82bfc69e606a5b7ad48767539e1e3a8 Status: R X-Status: N ooops i didn't see this one...

Michael Riepe wrote:
> On Thu, Jan 11, 2001 at 11:58:54AM +0100, Yann GUIDON wrote:
> > - execution units : INC will be redesigned (Erik ?...),
> > but the SHL unit is giving me some troubles.
> What kind of troubles?  Please think louder ;)
the design goal (6 simple gates with 4 inputs) is difficult
and maybe too optimistic to hold the promise of a 1-cycle SHL unit.
The theory says that it is possible, now i wonder ... how ?

> [...]
> > Can the others share their todolist with us ?
> 1. pipelined EU_ASU
> 2. design and implementation of EU_IDU (integer divide unit)
> 3. whatever comes next...

sure. you're kind of "responsible" for those parts.
but divisions are less useful than shifts. we'll need one
soon, or at least a good analysis thereof, so we can decide
what structure will be best. implementation is "just" a
"common" problem. we need probably to study several options.
mainly, the shift array is easy, but the control part is less
straight-forward.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sun Jan 14 03:41:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06133 for ; Sun, 14 Jan 2001 17:08:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:02 +0100 (MET) Received: (qmail 11784 invoked by uid 0); 14 Jan 2001 02:36:14 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx07) with SMTP; 14 Jan 2001 02:36:14 -0000 X-eGroups-Return: sentto-1101623-1980-979439766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 14 Jan 2001 02:36:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 02:36:05 -0000 Received: (qmail 12443 invoked from network); 14 Jan 2001 02:36:04 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 Jan 2001 02:36:04 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 14 Jan 2001 03:37:09 -0000 Received: from f-cpu.org (nas4-111.ras.club-internet.fr [195.36.203.111]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA09447 for ; Sun, 14 Jan 2001 03:36:00 +0100 (MET) Message-ID: <3A6111F7.F6F8AE7E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> <3A6077A6.F6C24BDE@f-cpu.org> <000501c07d7e$d0616910$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 03:41:59 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] some elements about the shifter. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 53787ce2cbfc98aef4c19518d41870db Status: R X-Status: N hi,

i guess that now we can discuss it, since no easy solution appears...

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > right. in theory, we can shift / rotate 64 bits within the critic= al datapath constraints.
> > In practice, it's much more difficult. that's why a netsearch and= a search in the
> > existing bibliography would help save some time...
> > Is there a barrel shifter specialist in the room ?
> I doubt it... but Im curious, whats the problem with just using a log-= 2 shifter?
it's not so easy in this case. more on this below.

> BTW are you sure the standard cell library wont have a barrel shifter?= To me the
> most straightforward implementation would seem to be with pass transis= tors,
> regardless of wether you use a barrel/log/whatever shifter, which we c= ant use
> ourselves.

If one can use a barrel shifter that is already synthesised, no problem but= there
are several problems or contradictory things.

First let's examine the transistor array that seems to be the best and easi= est solution.
The advantage is that it seems simple and fast. The control logic is not to= o complex.
Now, the problems are more important than i thought : it scales in O(n=B2),= it is not suitable
for very large arrays, the wires are long and loaded so a large version wil= l actually
be slower than a barrel shifter (L, R and C are getting very important). I know a technique for reducing the transistor count of a n to n matrix, bu= t it
is not suitable for n>16 because of the R,L,C factors anyway.
Finally, this technique is not suitable for something else than ASIC and fu= ll-custom
circuits. If someone wants to use it for a FPGA he'll have a tough time...<= BR>
Now, a barrel shifter is (according to a book i have found at my university= )
almost perfect because it's the best compromise between time and space. it'= s
roughly O(n*log(n)) and the stages are rather simple.
let's take a 6-level shifter made of 2-to-1 muxes. The control logic is
straight-forward because every bit from the 'shift amount' is fed to the corresponding stage. Now there's also a problem : we have to route the
metal layers as to avoid over-concentration in some regions (same problem as a wallace-tree-based multiplier). we need a minimum of 3 metal layers but "optimized" versions will require more... it's still technolo= gy dependent
but more workable.

You think it's ok ? remember that the goal of the SHL unit is to
do shift, rotate, bit extraction/insersion/change/test, byte reversing,
chunk duplication etc... on SIMD words, plus the arithmetic shifts must
be handled. Now the control logic looks different.

I propose to investigate some possibilities such as :
2 stages of 8*8 matrices, or 3 stages of 4*4 matrices. The interconnexion network can be similar to an OMEGA network, or something like that.
This way, if we use HWired Xbars (made of transistor arrays) we'll have
much less surface (case 1 : 2* 8*8*8=3D1024 transistors=B2, case 2 : 3*16*4= *4=3D768t=B2).
compare that to 64*64=3D4096. the control logic is manageable, i think.
Plus, we can easily implement the small Xbars matrices with discrete gates.=
The interco net is still undetermined.

The problem is that a simple barrel shifter is complex to adapt for SIMD operations. shift is simple but we must do rotation, arith. shift,
and everything with 8-, 16-, 32- and 64-bit sizes. Read the manual to see all the operations it is meant to do, there are some rather nasty stuffs...=
And last but not least : it must fit in the aimed critical datapath of 6 ga= tes,
including the control gates (that command each stage).

i don't know if i can do this alone. Just like the multiplier and the adder= ,
it's a critical and non-obvious part. I have clear ideas and algos for
the scheduler, but not for the SHL's implementation.
> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From Ben Franchuk Fri Jan 12 22:13:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06136 for ; Sun, 14 Jan 2001 17:08:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:03 +0100 (MET) Received: (qmail 2910 invoked by uid 0); 14 Jan 2001 04:07:12 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx08) with SMTP; 14 Jan 2001 04:07:12 -0000 X-eGroups-Return: sentto-1101623-1981-979445190-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 14 Jan 2001 04:07:00 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 04:06:29 -0000 Received: (qmail 17364 invoked from network); 14 Jan 2001 04:06:28 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 14 Jan 2001 04:06:28 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 14 Jan 2001 04:06:26 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA01050 for ; Sat, 13 Jan 2001 21:00:19 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A5F738E.BEA7172E@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> <3A6077A6.F6C24BDE@f-cpu.org> <000501c07d7e$d0616910$29e65982@student.utwente.nl> <3A6111F7.F6F8AE7E@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 12 Jan 2001 14:13:50 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some elements about the shifter. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 428ea76fc4db3fe61e6ed7e057ae5dda Status: R X-Status: N Yann Guidon wrote:
>
> You think it's ok ? remember that the goal of the SHL unit is to
> do shift, rotate, bit extraction/insersion/change/test, byte reversing,
> chunk duplication etc... on SIMD words, plus the arithmetic shifts must
> be handled. Now the control logic looks different.

What about having the SHL unit do two stages of shifting since delays
are going to be too long.
The primary SHL stage would do just the stuff on byte boundaries,
byte stuffing and masking and shift left 1,2,3,4 bit positions. This
would cover 90%? of the shifts needed in one stage and once pre scaled the
second
stage only would need to shift 8 bit chunks.

Ben.
PS. All FPGA's can do a  2:1 multplexer with enable in one logic cell
but most can not do a 4:1 multiplexer in one logic cell..
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Yann Guidon Sun Jan 14 07:06:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06145 for ; Sun, 14 Jan 2001 17:08:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:05 +0100 (MET) Received: (qmail 22053 invoked by uid 0); 14 Jan 2001 06:01:10 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx08) with SMTP; 14 Jan 2001 06:01:10 -0000 X-eGroups-Return: sentto-1101623-1982-979452057-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 14 Jan 2001 06:01:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 06:00:56 -0000 Received: (qmail 269 invoked from network); 14 Jan 2001 06:00:56 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 14 Jan 2001 06:00:56 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 14 Jan 2001 06:00:56 -0000 Received: from f-cpu.org (nas3-11.ras.club-internet.fr [195.36.203.11]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA19460 for ; Sun, 14 Jan 2001 07:00:50 +0100 (MET) Message-ID: <3A6141FE.19A9880B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 07:06:54 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] man patch Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 044b8c985f2b247e7c9c6db501547cf9 Status: R X-Status: N hello,

http://www.f-cpu.seul.org/in
contains my last (unverified) patch for
the first part of the manual.
please update and comment.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From Yann Guidon Sun Jan 14 07:10:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06148 for ; Sun, 14 Jan 2001 17:08:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:06 +0100 (MET) Received: (qmail 11511 invoked by uid 0); 14 Jan 2001 06:04:10 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx13) with SMTP; 14 Jan 2001 06:04:10 -0000 X-eGroups-Return: sentto-1101623-1983-979452247-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 14 Jan 2001 06:04:09 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 06:04:07 -0000 Received: (qmail 79647 invoked from network); 14 Jan 2001 06:04:06 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 14 Jan 2001 06:04:06 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 14 Jan 2001 06:04:05 -0000 Received: from f-cpu.org (nas3-11.ras.club-internet.fr [195.36.203.11]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id HAA28585 for ; Sun, 14 Jan 2001 07:04:02 +0100 (MET) Message-ID: <3A6142BF.DE3FF83A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A6141FE.19A9880B@f-cpu.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 07:10:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] man patch Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3bc5ae1ebb9d47f65f10bb50804a8a81 Status: R X-Status: N Yann Guidon wrote:
> hello,
>
> http://www.f-cpu.seul.org/in
> contains my last (unverified) patch for
> the first part of the manual.
> please update and comment.

oooops it's http://www.f-cpu.seul.org/new :-/

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Marco Al" Sun Jan 14 07:54:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06151 for ; Sun, 14 Jan 2001 17:08:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:06 +0100 (MET) Received: (qmail 11787 invoked by uid 0); 14 Jan 2001 06:46:40 -0000 Received: from cj.egroups.com (208.50.144.68) by 10.1.4.106 (mx06) with SMTP; 14 Jan 2001 06:46:40 -0000 X-eGroups-Return: sentto-1101623-1984-979454797-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by cj.egroups.com with NNFMP; 14 Jan 2001 06:46:39 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 06:46:36 -0000 Received: (qmail 46800 invoked from network); 14 Jan 2001 06:46:36 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 14 Jan 2001 06:46:36 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 14 Jan 2001 06:46:35 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id F2E082C1F for ; Sun, 14 Jan 2001 07:46:34 +0100 (CET) Message-ID: <00dd01c07df6$d9ffa310$29e65982@student.utwente.nl> To: References: <3A5CC5E1.1CE5ADD3@ifrance.com> <3A5D9ED5.25175855@mentor.com> <3A5E26FA.B3BE362D@ifrance.com> <3A5E5DAC.5354BA78@f-cpu.org> <3A5ED3D4.54E6B0CD@llandre.freeserve.co.uk> <3A6077A6.F6C24BDE@f-cpu.org> <000501c07d7e$d0616910$29e65982@student.utwente.nl> <3A6111F7.F6F8AE7E@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 07:54:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some elements about the shifter. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: da5095fd4cec962ef2c39e5779a93e17 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>


> You think it's ok ? remember that the goal of the SHL unit is to
> do shift, rotate, bit extraction/insersion/change/test, byte reversing,
> chunk duplication etc... on SIMD words, plus the arithmetic shifts must
> be handled. Now the control logic looks different.

With 4:1 mux's I am pretty sure you could fit it into 6 stages of them, although
bitops are a bit of a sqeeze, wiring would be a nightmare though (control logic
delay for later stages isnt really an issue).

Marco
eGroups Sponsor
Click Here!
From art1 Sun Jan 14 10:27:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA06154 for ; Sun, 14 Jan 2001 17:08:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 17:08:07 +0100 (MET) Received: (qmail 17752 invoked by uid 0); 14 Jan 2001 08:22:24 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.112 (mx12) with SMTP; 14 Jan 2001 08:22:24 -0000 X-eGroups-Return: sentto-1101623-1985-979460540-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 14 Jan 2001 08:22:23 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 08:22:17 -0000 Received: (qmail 84255 invoked from network); 14 Jan 2001 08:22:15 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 14 Jan 2001 08:22:15 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta2 with SMTP; 14 Jan 2001 08:22:15 -0000 Received: from art1.none.de (dialin238.pg2-nt.berlin.nikoma.de [213.54.65.238]) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id JAA27319 for ; Sun, 14 Jan 2001 09:23:02 +0100 Received: from art1.none.de (art1@art1.none.de [192.168.42.2]) by art1.none.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA07039 for ; Sun, 14 Jan 2001 10:27:47 +0100 To: f-cpu@egroups.com In-Reply-To: <3A6111F7.F6F8AE7E@f-cpu.org> Message-ID: From: art1 MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 10:27:47 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] some elements about the shifter. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 78874218b38a96291e0b50f914c4e98a Status: R X-Status: N Hello,

> You think it's ok ? remember that the goal of the SHL unit is to
> do shift, rotate, bit extraction/insersion/change/test, byte reversing,
> chunk duplication etc... on SIMD words, plus the arithmetic shifts must
> be handled. Now the control logic looks different.

It's ok, when we have following operations (logic control):

n -> n-shifts/rotates (with 64 bit or in direction of chunksize, for every
chunk-shifting a special n?)
l -> shift with filling 0, filling 1, rotate, filling MSB, filling
LSB
d -> direction right, left
c -> chunks: 8bit, 16bit, 32bit, 64bit (means in which range operation
will be done)

thats means n has 3bit*8 (if we need special n for every chunk), or 6
bit
(64bit size)
l has 3bit,
d has 1bit,
c has 2bits

(30 bits control logic + registers (max), or 12 bits)

If thats right then I want to play with it...

If we need additional features, please give me an explanation...

Bye Andreas
eGroups Sponsor
Click Here!
From "Marco Al" Sun Jan 14 19:45:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA07042 for ; Sun, 14 Jan 2001 21:36:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 21:36:23 +0100 (MET) Received: (qmail 14213 invoked by uid 0); 14 Jan 2001 19:11:10 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx05) with SMTP; 14 Jan 2001 19:11:10 -0000 X-eGroups-Return: sentto-1101623-1987-979497432-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 14 Jan 2001 18:37:23 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 18:37:12 -0000 Received: (qmail 75649 invoked from network); 14 Jan 2001 18:37:10 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 14 Jan 2001 18:37:10 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 14 Jan 2001 19:38:15 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 2D22B2D4A for ; Sun, 14 Jan 2001 19:37:09 +0100 (CET) Message-ID: <001301c07e5a$1f2356e0$29e65982@student.utwente.nl> To: References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> <20010111172102.42866@thrai.stud.uni-hannover.de> <3A61B67F.813FEBF8@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 19:45:09 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Questioning the reasoning behind a single bitshuffling unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 024518bf2fdf2d29fa74233399c5f6d3 Status: R X-Status: N If it turns out the unit as anticipated can not be made a single stage couldnt
you cut it up?

The present combination of the bit shuffling instructions into a single unit
makes sense (although making two unidirectional units might be a good idea), but
do the non shifting instructions (byterev/mix/expand/sdup) really have to be in
there?

BTW check "A Low-power 32-bit Datapath Design" at
http://www.cag.lcs.mit.edu/scale/publications.html a low level simulated
implementation of a logarithmic shifter which combined multiple shifts into one
layer, via larger mux's, performed as well as a shifter using an array of
switches which they call a barrel shifter.

Marco
eGroups Sponsor
Click Here!
From jeff@llandre.freeserve.co.uk Sun Jan 14 20:41:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA07063 for ; Sun, 14 Jan 2001 21:36:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 14 Jan 2001 21:36:28 +0100 (MET) Received: (qmail 778 invoked by uid 0); 14 Jan 2001 19:47:25 -0000 Received: from unknown (HELO fj.egroups.com) (64.211.240.231) by 10.1.4.119 (mx19) with SMTP; 14 Jan 2001 19:47:25 -0000 X-eGroups-Return: sentto-1101623-1988-979501615-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 14 Jan 2001 19:47:24 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 19:46:54 -0000 Received: (qmail 48991 invoked from network); 14 Jan 2001 19:46:53 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 Jan 2001 19:46:53 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta3 with SMTP; 14 Jan 2001 20:47:58 -0000 Received: from modem-98.potassium.dialup.pol.co.uk ([62.136.18.98] helo=62.136.18.98) by cmailg5.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14Ht6s-0001go-00 for f-cpu@egroups.com; Sun, 14 Jan 2001 19:46:39 +0000 To: f-cpu@egroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 19:41 +0000 Reply-To: f-cpu@egroups.com Subject: [f-cpu] shift unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9d16d2846633c377fa833bbca649bcbb Status: R X-Status: N If you replace my basic single shift left unit with
one based on and/or gates (and with the enable,
or with all signals that would be outputting on the
tristate node) then repeat the circuit for all 63
possibilities, and the enable for each possibility
comes from a 6 to 64 bit decoder.
Simplify using boolean techniques.
That would do it wouldnt it??
I dont know how many gates depth the decoder
will be.
You only need to bolt on a 2nd decoder to make
this into a right shift, and some minor mods to
make 8,16,32 bit support and rotate.
Jeff Davies.
Failing the above, I seem to remember alliance
(gpl) has a barrel shift generation program (makes
vhdl from input parameters of word length etc etc).
eGroups Sponsor
Click Here!
From "Richard E.Hartney" Sun Jan 14 22:45:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09022 for ; Mon, 15 Jan 2001 05:10:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:48 +0100 (MET) Received: (qmail 2273 invoked by uid 0); 14 Jan 2001 21:44:27 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx02) with SMTP; 14 Jan 2001 21:44:27 -0000 X-eGroups-Return: sentto-1101623-1989-979508512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by b05.egroups.com with NNFMP; 14 Jan 2001 21:42:25 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 21:41:51 -0000 Received: (qmail 21468 invoked from network); 14 Jan 2001 21:41:41 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 14 Jan 2001 21:41:41 -0000 Received: from unknown (HELO mail5.lig.bellsouth.net) (205.152.0.12) by mta1 with SMTP; 14 Jan 2001 21:41:40 -0000 Received: from 0018728164 (host-208-60-244-5.bix.bellsouth.net [208.60.244.5]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id QAA23251; Sun, 14 Jan 2001 16:41:34 -0500 (EST) Message-ID: <000e01c07e73$602748e0$05f43cd0@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 15:45:54 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Barrel Shifter Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C07E41.1481D180" X-UIDL: 39eed0897a24e088d5b021477758aa80 Status: R X-Status: N ------=_NextPart_000_000B_01C07E41.1481D180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm still off the mailing list but keep reading the stuff. As I said quite some time ago - read the Data Sheet for the AMD AM25s10 int= egrated circuit. It shows you how to implement Schematically.=20=20 For circuit reduction - design it for a Left Shift. For circuit reduction = - do a Bit Reversal on both ends of the Shifter. Use it for Left and Right= Shifts. On both ends of the Shifter - design some End Logic for the Six (= 6) types of Shifts - being Arithmetic, Logical & Rotate. Estimated design time equal 1000 engineering= man-hours. Or you can save time and contact Mr Patrick Pelgrims at the fo= llowing address -- patrick.pelgrims@pandora.be I sent him hard copy of the design quite some time ago - its for a 32 bit b= arrel shifter with the above design considerations.. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_000B_01C07E41.1481D180 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm still off the mailing list but keep re= ading the=20 stuff.
 
As I said quite some time ago - read the D= ata Sheet=20 for the AMD AM25s10 integrated circuit.  It shows you how to implement= =20 Schematically. 
 
For circuit reduction - design it for a Le= ft=20 Shift.  For circuit reduction - do a Bit Reversal on both ends of the= =20 Shifter.  Use it for Left and Right Shifts.  On both ends of the= =20 Shifter - design some End Logic for the Six (6) types of Shifts -=20 being
Arithmetic, Logical & Rotate.  Es= timated=20 design time equal 1000 engineering man-hours.  Or you can save time an= d=20 contact Mr Patrick Pelgrims at the following
address  --  patrick.pelgrims@pandora.be=
 
I sent him hard copy of the design quite s= ome time=20 ago - its for a 32 bit barrel shifter with the above design=20 considerations..
 
Sincerely
Richard E. Hartney
Research Director
Erin Greene & Associates
 
 

eGroups Sponsor=
------=_NextPart_000_000B_01C07E41.1481D180-- From "Marco Al" Sun Jan 14 23:08:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09028 for ; Mon, 15 Jan 2001 05:10:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:51 +0100 (MET) Received: (qmail 3007 invoked by uid 0); 14 Jan 2001 22:03:06 -0000 Received: from unknown (HELO ef.egroups.com) (64.211.240.229) by mx0.gmx.net (mx24) with SMTP; 14 Jan 2001 22:03:06 -0000 X-eGroups-Return: sentto-1101623-1990-979509667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 14 Jan 2001 22:02:58 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 22:01:06 -0000 Received: (qmail 8841 invoked from network); 14 Jan 2001 22:00:24 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 14 Jan 2001 22:00:24 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 14 Jan 2001 22:00:23 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 9E6712D4A for ; Sun, 14 Jan 2001 23:00:22 +0100 (CET) Message-ID: <001c01c07e76$82dbfdb0$29e65982@student.utwente.nl> To: References: <000e01c07e73$602748e0$05f43cd0@0018728164> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 23:08:23 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Barrel Shifter Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 74fd8513bd4ba37dcc08fe84c8a198e7 Status: R X-Status: N From: "Richard E.Hartney" <rhartny@bellsouth.net>

> For circuit reduction - design it for a Left Shift.  For circuit reduction -
> do a Bit Reversal on both ends of the Shifter.  Use it for Left and
> Right Shifts.  On both ends of the Shifter - design some End Logic for
> the Six (6) types of Shifts - being Arithmetic, Logical & Rotate.

AFAICS these tricks are all relatively well known, Id seen the bit reverse trick
in a logarithmic shifter before at least and Im an expert at nothing. The
problem is that the SIMD forms make the end stage complex, using 8+:1 mux's on
the end is probably not an option. Trying to fit in the chunk based instructions
which also introduce parts of a second 64 bit word probably wont help, lots of
horizontal wiring there.

> Estimated design time equal 1000 engineering man-hours.

Really?

Marco
eGroups Sponsor
Click Here!
From Nicolas Boulay Sun Jan 14 23:20:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09040 for ; Mon, 15 Jan 2001 05:10:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:54 +0100 (MET) Received: (qmail 11889 invoked by uid 0); 14 Jan 2001 23:24:26 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx17) with SMTP; 14 Jan 2001 23:24:26 -0000 X-eGroups-Return: sentto-1101623-1991-979510459-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 14 Jan 2001 22:14:38 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 22:14:19 -0000 Received: (qmail 85601 invoked from network); 14 Jan 2001 22:12:37 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 14 Jan 2001 22:12:37 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 14 Jan 2001 22:12:37 -0000 Received: from ifrance.com (nas7-73.vlt.club-internet.fr [194.158.109.73]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA16487 for ; Sun, 14 Jan 2001 23:12:30 +0100 (MET) Message-ID: <3A622629.9DE00110@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 23:20:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: bba79b3313e423ff0e9abdda9a3a3ad7 Status: R X-Status: N Hello !

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > > I think you are overestimating the complexity for a 32 bit a= dder, in fact
> you
> > > could do it with a logic depth of 2 ;)
> > >
> >
> > A simple adder has soon 3 level at least, so...
>
> With 64 input and/or gates... :) (consider it from the truth table POV= )
>
> > In a register windows system, only at call, you translate the win= dows.
>
> You can always fake it.
>
> >  No, that's false. SIMD, here are small for 64 bit register = you handel
> > 2*32, 4*16,8*8, that's not much, you can use it for lot of differ= ent
> > stuff (Mostly calcul but Excel made some, too ).
>
> A lot perhaps, but not enough IMO.
>

Mostly 99 % of the time with so little vector ! Think of manipulating
string, or look in to a look up table (with an index),... GCC the worst
// program ever seen, have an ILP of 3. So you can execute an average of 3 instruction in the same time, so 2 time the same instruction (if you
think of 2*32) isn't so hard to find.

> > > A solution is to take it to the extreme, have enough process= es to bridge
> main
> > > memory latency even with the cache pollution (thats the basi= c idea behind
> > > Tera/Cray's MT architecture I think). You could instrument t= he processor
> such
> > > that the OS could schedule processes according to memory loc= ality, if you
> have
> > > plenty of threads working with the same set fine... if not d= o the best you
> can.
> > >
> >
> > Reread, the post "Let's go back to the core!" I explain= that is too
> > difficult for the user or compiler to find enought thread in the = code,
> > to fill all this.
>
> I was thinking more of a server environment, with plenty of single and=
> multi-threaded processes running concurrently.
>
> > >  Thats the advantage of MP over MT.
> > >
> > too many problem ! Just read up.
>
> Apart from having fears of not having enough to do, which IMO goes cou= nter your
> SIMD argument (if its suitable to extract SIMD instructions from, then= its
> likely more than suitable to extract micro-threads from), those proble= ms boil
> down to two... poor locality, which I dont think is insurmountable, an= d the need
> for a lot of protection domains in hardware... which IMO is a good thi= ng, even
> with added complexity.
>

If you think of microthread, you need some thing as 50 to 200 threads to hide cache miss. But don't forget that usual L2 cache is 4 ways
associative (sometimes 16) so it became very easy to trash it. Here SIMD vector are very short : 2 maybe 8, 32b calcul in the futur, that's very
few.

One of my collegue (a professor in electronique architecture) explain
how transputer work many years ago. An hardware schedulor was include
inside it. So you just have to write microprocess and dispatch it
thought many transputer.(imagine microthread for cellular automate, you
just write the microprocess for one cell, then you can dispatch it to
how many proc you have, for how many grid size you want !). But you need to rewrite all programme to have good performmance.

In a "professionnal" publication, i have read something about an<= BR> implementation of the realloc() C function. They have written a
realloc() because malloc() and free() have soon been implemented ;) They work to create a dynamic MMU. Todays, i haven't try to find in the web
if it was a free project but it's an interresting way. I think that
malloc() are very often used in program and in HW it could be very fast
! But i have to verify that all the protection stuff could be made.


> Marco
eGroups Sponsor=
3D"Click
From Michael Riepe Mon Jan 15 00:21:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09043 for ; Mon, 15 Jan 2001 05:10:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:55 +0100 (MET) Received: (qmail 14050 invoked by uid 0); 14 Jan 2001 23:25:22 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx24) with SMTP; 14 Jan 2001 23:25:22 -0000 X-eGroups-Return: sentto-1101623-1992-979514512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 14 Jan 2001 23:22:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 14 Jan 2001 23:21:51 -0000 Received: (qmail 15870 invoked from network); 14 Jan 2001 23:21:14 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 14 Jan 2001 23:21:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.107) by mta2 with SMTP; 14 Jan 2001 23:21:12 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01956; Mon, 15 Jan 2001 00:21:07 +0100 Message-ID: <20010115002107.16134@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> <20010111172102.42866@thrai.stud.uni-hannover.de> <3A61B67F.813FEBF8@f-cpu.org> <001301c07e5a$1f2356e0$29e65982@student.utwente.nl> X-Mailer: Mutt 0.84e In-Reply-To: <001301c07e5a$1f2356e0$29e65982@student.utwente.nl>; from Marco Al on Sun, Jan 14, 2001 at 07:45:09PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 00:21:07 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Questioning the reasoning behind a single bitshuffling unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a3b4d099c2f551508f525c37e9df97dd Status: R X-Status: N On Sun, Jan 14, 2001 at 07:45:09PM +0100, Marco Al wrote:
> If it turns out the unit as anticipated can not be made a single stage couldnt
> you cut it up?
>
> The present combination of the bit shuffling instructions into a single unit
> makes sense (although making two unidirectional units might be a good idea), but
> do the non shifting instructions (byterev/mix/expand/sdup) really have to be in
> there?

I agree that at least the mix/expand instructions should be handled in
a different unit (or maybe in the Xbar).  They're totally different
(two source operands, but none of them is a shift count).  Bitrev,
byterev and sdup, on the other hand, permute the bits of a single
operand, just a little more complicated than ordinary shifts.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From Yann Guidon Mon Jan 15 01:09:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09049 for ; Mon, 15 Jan 2001 05:10:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:56 +0100 (MET) Received: (qmail 2676 invoked by uid 0); 15 Jan 2001 00:12:17 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx23) with SMTP; 15 Jan 2001 00:12:17 -0000 X-eGroups-Return: sentto-1101623-1994-979517022-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 15 Jan 2001 00:06:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 00:03:42 -0000 Received: (qmail 77683 invoked from network); 15 Jan 2001 00:03:34 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 Jan 2001 00:03:34 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 15 Jan 2001 01:04:38 -0000 Received: from f-cpu.org (nas1-147.ras.club-internet.fr [195.36.192.147]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12768 for ; Mon, 15 Jan 2001 01:03:31 +0100 (MET) Message-ID: <3A623FBF.D2A2FBD7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 01:09:35 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] yet another man patch Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 23a19ec46954e286a22bc40230dd7e73 Status: R X-Status: N hello,
as usually there's a new version of the first 4 parts of the manual.
i found new LaTeX keywords that ease some of the previous work, and
now it looks cleaner :-) i've also added some stuffs here and there,
started some new chapters. I'll have to finish them and add some
drawings before i get to Part V.

http://www.f-cpu.seul.org/new/
look at the most recent files : p.ps.gz and patch_YG_p1-4.tgz

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Richard E.Hartney" Mon Jan 15 01:35:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09058 for ; Mon, 15 Jan 2001 05:10:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:10:59 +0100 (MET) Received: (qmail 19249 invoked by uid 0); 15 Jan 2001 00:31:48 -0000 Received: from mk.egroups.com (208.50.144.76) by 10.1.4.119 (mx19) with SMTP; 15 Jan 2001 00:31:48 -0000 X-eGroups-Return: sentto-1101623-1995-979518690-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 15 Jan 2001 00:31:37 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 00:31:29 -0000 Received: (qmail 97077 invoked from network); 15 Jan 2001 00:31:19 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 15 Jan 2001 00:31:19 -0000 Received: from unknown (HELO mail4.lig.bellsouth.net) (205.152.0.32) by mta1 with SMTP; 15 Jan 2001 00:31:19 -0000 Received: from 0018728164 (host-209-215-11-131.bix.bellsouth.net [209.215.11.131]) by mail4.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id TAA07047; Sun, 14 Jan 2001 19:31:15 -0500 (EST) Message-ID: <000c01c07e8b$150e8180$830bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 18:35:33 -0600 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Barrel Shifter Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C07E58.C7918B00" X-UIDL: ae192b02f37d8e9e112a1f924ced2553 Status: R X-Status: N ------=_NextPart_000_0009_01C07E58.C7918B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And as I also said before ---- try the Fairchld 54\74F350 application data. Erin Greene ------=_NextPart_000_0009_01C07E58.C7918B00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And as I also said before ---- try the Fai= rchld=20 54\74F350 application data.
 
Erin Greene

eGroups Sponsor=
------=_NextPart_000_0009_01C07E58.C7918B00-- From Yann Guidon Mon Jan 15 02:18:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09061 for ; Mon, 15 Jan 2001 05:11:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:11:00 +0100 (MET) Received: (qmail 20889 invoked by uid 0); 15 Jan 2001 01:14:15 -0000 Received: from hi.egroups.com (208.50.99.211) by 10.1.4.112 (mx12) with SMTP; 15 Jan 2001 01:14:15 -0000 X-eGroups-Return: sentto-1101623-1997-979521189-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 15 Jan 2001 01:13:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 01:13:08 -0000 Received: (qmail 78398 invoked from network); 15 Jan 2001 01:12:50 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 15 Jan 2001 01:12:50 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 15 Jan 2001 01:12:49 -0000 Received: from f-cpu.org (nas3-77.aub.club-internet.fr [195.36.145.77]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA29327 for ; Mon, 15 Jan 2001 02:12:46 +0100 (MET) Message-ID: <3A624FF9.55B0844F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 02:18:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8ce8f92b8bb19747254661288cef0ad1 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Hello !
> Marco Al a =E9crit :
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > >  No, that's false. SIMD, here are small for 64 bit regi= ster you handel
> > > 2*32, 4*16,8*8, that's not much, you can use it for lot of d= ifferent
> > > stuff (Mostly calcul but Excel made some, too ).
> > A lot perhaps, but not enough IMO.
>  Mostly 99 % of the time with so little vector ! Think of manipul= ating
> string, or look in to a look up table (with an index),... GCC the wors= t
> // program ever seen, have an ILP of 3. So you can execute an average = of
> 3 instruction in the same time, so 2 time the same instruction (if you=
> think of 2*32) isn't so hard to find.
good point :-)
the problem is still the memory bandwidth though...
but the advantage of SIMD over microtasks is that it doesn't thrash the cac= he
as much. We can even benefit from streaming of packets through the memory i= nterface
and benefit from the stream hint bits.


> In a "professionnal" publication, i have read something abou= t an
> implementation of the realloc() C function. They have written a
> realloc() because malloc() and free() have soon been implemented ;) Th= ey
> work to create a dynamic MMU. Todays, i haven't try to find in the web=
> if it was a free project but it's an interresting way. I think that > malloc() are very often used in program and in HW it could be very fas= t
> ! But i have to verify that all the protection stuff could be made.
malloc() etc. are too bound to the kernel/OS : they can't be hardwired.
they can be eased, but a HW unit would be unused for some cases, which
make it less interesting. it's like the 2MB segments in the Pentium :
who uses it ??? it's just wasted transistors...

OTOH if you can come up with a simple and useful unit, we'll examine it :-)=
btw i'm still waiting for your other works... hehehe :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Click
From Yann Guidon Mon Jan 15 02:18:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09064 for ; Mon, 15 Jan 2001 05:11:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:11:01 +0100 (MET) Received: (qmail 1015 invoked by uid 0); 15 Jan 2001 01:15:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 15 Jan 2001 01:15:11 -0000 X-eGroups-Return: sentto-1101623-1996-979521189-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 15 Jan 2001 01:13:52 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 01:13:08 -0000 Received: (qmail 40442 invoked from network); 15 Jan 2001 01:12:47 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 15 Jan 2001 01:12:47 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 15 Jan 2001 01:12:46 -0000 Received: from f-cpu.org (nas3-77.aub.club-internet.fr [195.36.145.77]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA24570 for ; Mon, 15 Jan 2001 02:12:43 +0100 (MET) Message-ID: <3A624FF7.821956E5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> <20010111172102.42866@thrai.stud.uni-hannover.de> <3A61B67F.813FEBF8@f-cpu.org> <001301c07e5a$1f2356e0$29e65982@student.utwente.nl> <20010115002107.16134@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 02:18:47 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Questioning the reasoning behind a single bitshuffling unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a5e67917a979a80636629c7c2421232c Status: R X-Status: N hello,

Michael Riepe wrote:
>
> On Sun, Jan 14, 2001 at 07:45:09PM +0100, Marco Al wrote:
> > If it turns out the unit as anticipated can not be made a single stage couldnt
> > you cut it up?
> >
> > The present combination of the bit shuffling instructions into a single unit
> > makes sense (although making two unidirectional units might be a good idea), but
> > do the non shifting instructions (byterev/mix/expand/sdup) really have to be in
> > there?
>
> I agree that at least the mix/expand instructions should be handled in
> a different unit (or maybe in the Xbar).  They're totally different
> (two source operands, but none of them is a shift count).  Bitrev,
> byterev and sdup, on the other hand, permute the bits of a single
> operand, just a little more complicated than ordinary shifts.

I have to say that i have read a lot of /interesting/ mails about the shift
unit recently, and the participation of a lot of people is very encouraging.

Now it is obvious that the optimistic description of the manual will be
redesigned almost from scratch. I count on you all to give your help
because this unit escapes me...

If it is required, the unit can be pipelined, i guess it won't exceed
2 stages.

for the bitrev instructions, it's similar to a normal shift because
i presume that the bit reverse part will be done on the Xbar
(it's something in common with the INC unit).

but yes, the SHL unit is much more complex than expected.
I have to digest and fully understand 5 posts about it.
it's not the #1 priority (let's finish and polish and validate the
existing VHDL parts) but the discussions about it are a good sign.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Click Here!
From "Marco Al" Mon Jan 15 01:09:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA09067 for ; Mon, 15 Jan 2001 05:11:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 05:11:02 +0100 (MET) Received: (qmail 8794 invoked by uid 0); 15 Jan 2001 01:17:49 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx21) with SMTP; 15 Jan 2001 01:17:49 -0000 X-eGroups-Return: sentto-1101623-1993-979516952-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 15 Jan 2001 00:03:35 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 00:02:32 -0000 Received: (qmail 34266 invoked from network); 15 Jan 2001 00:02:00 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 15 Jan 2001 00:02:00 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 15 Jan 2001 00:01:59 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id CCEBE2DA3 for ; Mon, 15 Jan 2001 01:01:58 +0100 (CET) Message-ID: <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 01:09:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: add39e44d7fa74fd461606d5336ebce1 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

>  Mostly 99 % of the time with so little vector ! Think of manipulating
> string, or look in to a look up table (with an index),... GCC the worst
> // program ever seen, have an ILP of 3. So you can execute an average of
> 3 instruction in the same time, so 2 time the same instruction (if you
> think of 2*32) isn't so hard to find.

Actually, with that ILP if I assume even a small number of instructions with
evenly distributed independent probabilities (too far fetched?) I dont see SIMD
making much impact.

> > Apart from having fears of not having enough to do, which IMO goes counter
your
> > SIMD argument (if its suitable to extract SIMD instructions from, then its
> > likely more than suitable to extract micro-threads from), those problems
boil
> > down to two... poor locality, which I dont think is insurmountable, and the
need
> > for a lot of protection domains in hardware... which IMO is a good thing,
even
> > with added complexity.
> >
>
> If you think of microthread, you need some thing as 50 to 200 threads to
> hide cache miss.

As I understand the term microthreads are supposed to extract the same kind of
ILP as superscalar execution and SIMD, ie localized... so I didnt mean them to
combat latency, I meant you could use them to make the processor at the same
time as capable (actually moreso) to use localized ILP as SIMD but flexible
enough to use the same mechanism to extract other forms of parallelism if
needed.

Of course flexibility comes at a cost, and has its benefits (elk voordeel heb
zijn nadeel).

> In a "professionnal" publication, i have read something about an
> implementation of the realloc() C function. They have written a
> realloc() because malloc() and free() have soon been implemented ;) They
> work to create a dynamic MMU. Todays, i haven't try to find in the web
> if it was a free project but it's an interresting way.

http://csl.csam.iit.edu/~dmm/ as for open, I seriously doubt it.... I wish it
were different. I hope the Academia will reform itself, as I read on a wavelet's
researchers page:
"An article about computational science in a scientific publication is not the
scholarship itself, it is merely advertising of the scholarship. The actual
scholarship is the complete software development environment and the complete
set of instructions which generated the figures."

(Im trying to implement an artificial neural network with which some researchers
had amazing speech recognition results with only 11 neurons, but the description
of the manner in which those neurons work was blatantly wrong in their first
three articles which they managed to upgrade to simply inconsistent in their
latest)

> I think that
> malloc() are very often used in program and in HW it could be very fast
> ! But i have to verify that all the protection stuff could be made.

Just like a good developer can use SIMD effectively themselves they can use
existing MMU's efficiently :)

Marco
eGroups Sponsor
Click Here!
From "Guillaume Lederrey" Mon Jan 15 11:38:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00375 for ; Mon, 15 Jan 2001 12:34:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 12:34:50 +0100 (MET) Received: (qmail 12053 invoked by uid 0); 15 Jan 2001 10:43:03 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx15) with SMTP; 15 Jan 2001 10:43:03 -0000 X-eGroups-Return: sentto-1101623-1998-979555131-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 15 Jan 2001 10:38:59 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 10:38:49 -0000 Received: (qmail 42768 invoked from network); 15 Jan 2001 10:38:49 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 15 Jan 2001 10:38:49 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.55) by mta1 with SMTP; 15 Jan 2001 10:38:47 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f0FAcab03584 for ; Mon, 15 Jan 2001 11:38:38 +0100 Message-Id: <200101151038.f0FAcab03584@PrintServer.LedCom> To: "f-cpu@egroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 11:38:41 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Sponsors for the F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5bbc792295c05e1f4acdf690a6c7b2d0 Status: R X-Status: N   I have a friend how might be able to find investissors for the
f-cpu.  Now the question I have is : do we need there money ?
At what conditions ?  Or do we need s/t else (a dedicated server
?) ...

  Do I ask my friend to continue his search for sponsors ?

      Bye

            Guillaume
eGroups Sponsor
Click Here!
From Nicolas Boulay Mon Jan 15 21:47:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA03179 for ; Mon, 15 Jan 2001 22:18:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 15 Jan 2001 22:18:21 +0100 (MET) Received: (qmail 27705 invoked by uid 0); 15 Jan 2001 20:58:34 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by mx0.gmx.net (mx14) with SMTP; 15 Jan 2001 20:58:34 -0000 X-eGroups-Return: sentto-1101623-1999-979592307-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 15 Jan 2001 20:58:34 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 20:58:26 -0000 Received: (qmail 54211 invoked from network); 15 Jan 2001 20:39:34 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 Jan 2001 20:39:34 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 15 Jan 2001 20:39:34 -0000 Received: from ifrance.com (nas21-26.vlt.club-internet.fr [195.36.171.26]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA02588 for ; Mon, 15 Jan 2001 21:39:30 +0100 (MET) Message-ID: <3A6361E2.CE0E1FA4@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 21:47:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4ba9e049ab0d8e02f08a5ed87c2c35d8 Status: R X-Status: N Hello,

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> >  Mostly 99 % of the time with so little vector ! Think of ma= nipulating
> > string, or look in to a look up table (with an index),... GCC the= worst
> > // program ever seen, have an ILP of 3. So you can execute an ave= rage of
> > 3 instruction in the same time, so 2 time the same instruction (i= f you
> > think of 2*32) isn't so hard to find.
>
> Actually, with that ILP if I assume even a small number of instruction= s with
> evenly distributed independent probabilities (too far fetched?) I dont= see SIMD
> making much impact.
>

Hummmm, Humm, heu, tu le fais expres ou quoi ? Hum, sorry, the remark
"too far fetched" give a big doubt : do you really understand wha= t SIMD
means ? SIMD instruction are used by the compiler or the user, so it
have to find the parrallelism. Mostly all "for loop" could be rew= ritten
to use SIMD instruction, and you can rewritte string function to be
speed up, or all hash function, and many different thing. So compare to
a "normal" 32 bit register a 2*32 bit register program will be al= most
100 % quicker.
Gcc is the WORST exemple for ILP. The best program could reach 20 or
even more. But reread me, i have soon written that without stack pointer dependancy, GCC could reach an ILP of more than 100 !!! So we have to do something to break this.

> > > Apart from having fears of not having enough to do, which IM= O goes counter
> your
> > > SIMD argument (if its suitable to extract SIMD instructions = from, then its
> > > likely more than suitable to extract micro-threads from), th= ose problems
> boil
> > > down to two... poor locality, which I dont think is insurmou= ntable, and the
> need
> > > for a lot of protection domains in hardware... which IMO is = a good thing,
> even
> > > with added complexity.
> > >
> >
> > If you think of microthread, you need some thing as 50 to 200 thr= eads to
> > hide cache miss.
>
> As I understand the term microthreads are supposed to extract the same= kind of
> ILP as superscalar execution and SIMD, ie localized... so I didnt mean= them to

Of course, but it's a more flexible way to do parrallelism, it is find
inside in a "function" level, not at the instruction level, and i= t's
different from the process level of usual unix system on mutliproc
computer. So you use another way to speed the code.

> combat latency, I meant you could use them to make the processor at th= e same
> time as capable (actually moreso) to use localized ILP as SIMD but fle= xible
> enough to use the same mechanism to extract other forms of parallelism= if
> needed.
>
> Of course flexibility comes at a cost, and has its benefits (elk voord= eel heb
> zijn nadeel).
>

The problem is to use the OS scheduler which is a very slow function
:context switch, write of some stat,  trash the cache memory, then you=
load another task. A thread use "user" scheduler wich cost less (= no
cache trash) : switch inside the user application like lightweight
thread of SUN.

> > In a "professionnal" publication, i have read something= about an
> > implementation of the realloc() C function. They have written a > > realloc() because malloc() and free() have soon been implemented = ;) They
> > work to create a dynamic MMU. Todays, i haven't try to find in th= e web
> > if it was a free project but it's an interresting way.
>
> http://csl.csam.iit.edu/~dmm= / as for open, I seriously doubt it.... I wish it
> were different. I hope the Academia will reform itself, as I read on a= wavelet's
> researchers page:
> "An article about computational science in a scientific publicati= on is not the
> scholarship itself, it is merely advertising of the scholarship. The a= ctual
> scholarship is the complete software development environment and the c= omplete
> set of instructions which generated the figures."
>
> (Im trying to implement an artificial neural network with which some r= esearchers
> had amazing speech recognition results with only 11 neurons, but the d= escription
> of the manner in which those neurons work was blatantly wrong in their= first
> three articles which they managed to upgrade to simply inconsistent in= their
> latest)
>
> > I think that
> > malloc() are very often used in program and in HW it could be ver= y fast
> > ! But i have to verify that all the protection stuff could be mad= e.
>
> Just like a good developer can use SIMD effectively themselves they ca= n use
> existing MMU's efficiently :)
>

Not really, don't forget than you can pipeline HW not the software (not
in the same way), and HW have a very strong // capabilities.

> Marco
nicO
eGroups Sponsor=
3D"Click
From Nicolas Boulay Mon Jan 15 22:43:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA03703 for ; Tue, 16 Jan 2001 00:07:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 00:07:20 +0100 (MET) Received: (qmail 14070 invoked by uid 0); 15 Jan 2001 21:58:52 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx02) with SMTP; 15 Jan 2001 21:58:52 -0000 X-eGroups-Return: sentto-1101623-2001-979595918-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 15 Jan 2001 21:58:51 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 21:58:38 -0000 Received: (qmail 46172 invoked from network); 15 Jan 2001 21:35:52 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Jan 2001 21:35:52 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 15 Jan 2001 22:36:57 -0000 Received: from ifrance.com (nas22-105.vlt.club-internet.fr [195.36.172.105]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA14145 for ; Mon, 15 Jan 2001 22:35:50 +0100 (MET) Message-ID: <3A636F16.8C7554DA@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <200101151038.f0FAcab03584@PrintServer.LedCom> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 22:43:50 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sponsors for the F-CPU Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4dbb706b4a2cb9907e624a74586b077b Status: R X-Status: N Very hard question, until now we have to few VHDL to need a good
computer. But very soon, we will need a good one (a very good one with
almost 1Go of RAM )! But where can we put this computer ? We need also
some professionnal tools (a good simulator to begin then a synthesis
tools like synopsys to see how it's big ;p). Maybe, it could be usefull
to have "some" licence for guy like Michael, Whygee and all peopl= e with
good VHDL knowledge.

Guillaume Lederrey a =E9crit :
>
>   I have a friend how might be able to find investissors for= the
> f-cpu.  Now the question I have is : do we need there money ?
> At what conditions ?  Or do we need s/t else (a dedicated server<= BR> > ?) ...
>
>   Do I ask my friend to continue his search for sponsors ? >
>         Bye
>
>            = ;     Guillaume
eGroups Sponsor=
3D"Click
From Nicolas Boulay Mon Jan 15 22:42:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA03700 for ; Tue, 16 Jan 2001 00:07:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 00:07:05 +0100 (MET) Received: (qmail 31961 invoked by uid 0); 15 Jan 2001 21:58:32 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 15 Jan 2001 21:58:32 -0000 X-eGroups-Return: sentto-1101623-2000-979595868-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 15 Jan 2001 21:58:31 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 21:57:47 -0000 Received: (qmail 44292 invoked from network); 15 Jan 2001 21:35:15 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 Jan 2001 21:35:15 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 15 Jan 2001 21:35:13 -0000 Received: from ifrance.com (nas22-105.vlt.club-internet.fr [195.36.172.105]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA25615 for ; Mon, 15 Jan 2001 22:34:39 +0100 (MET) Message-ID: <3A636ECE.872032FC@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A5930AE.3DD011BA@jetnet.ab.ca> <3A5CE4CC.46A81D00@ifrance.com> <3A5D7729.2CC9D8F6@IPricot.com> <3A5D9593.838F45F7@mentor.com> <3A5DAF41.593D33BE@IPricot.com> <3A5DB66F.53FC5744@mentor.com> <3A5DBA0C.BE1ACC7D@IPricot.com> <20010111172102.42866@thrai.stud.uni-hannover.de> <3A61B67F.813FEBF8@f-cpu.org> <001301c07e5a$1f2356e0$29e65982@student.utwente.nl> <20010115002107.16134@thrai.stud.uni-hannover.de> <3A624FF7.821956E5@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 22:42:38 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] smt compiler Content-Type: multipart/mixed; boundary="------------2C040365D21623A5001DE9D8" X-UIDL: ad12bfe704bd4bc66fd994a9d65fed83 Status: R X-Status: N --------------2C040365D21623A5001DE9D8 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit I have found something about smt compiler (in a dark corner of my hard
disk ;p)

nicO
eGroups Sponsor
Click Here!
--------------2C040365D21623A5001DE9D8 Content-Type: application/pdf; name="smtcompiler.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="smtcompiler.pdf" JVBERi0xLjINJeLjz9MNCjQzIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA0NSANL0gg WyA2NDIgMjczIF0gDS9MIDc1NjY1IA0vRSA1MDEzIA0vTiAxMiANL1QgNzQ2ODcgDT4+IA1l bmRvYmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTQzIDEyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA1ODcg MDAwMDAgbg0KMDAwMDAwMDkxNSAwMDAwMCBuDQowMDAwMDAxMDY5IDAwMDAwIG4NCjAwMDAw MDEyMDUgMDAwMDAgbg0KMDAwMDAwMTMxMiAwMDAwMCBuDQowMDAwMDAxNDE3IDAwMDAwIG4N CjAwMDAwMDQ1NzEgMDAwMDAgbg0KMDAwMDAwNDY3OSAwMDAwMCBuDQowMDAwMDA0Nzg0IDAw MDAwIG4NCjAwMDAwMDA2NDIgMDAwMDAgbg0KMDAwMDAwMDg5NCAwMDAwMCBuDQp0cmFpbGVy DTw8DS9TaXplIDU1DS9JbmZvIDQyIDAgUiANL1Jvb3QgNDQgMCBSIA0vUHJldiA3NDY3NyAN L0lEWzxiNzE2NDZhODI5YzJjMDVhNzY2NDI2YjYzMjZiYzM5NT48YjcxNjQ2YTgyOWMyYzA1 YTc2NjQyNmI2MzI2YmMzOTU+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgIA00NCAwIG9i ag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyA0MCAwIFIgDT4+IA1lbmRvYmoNNTMgMCBv YmoNPDwgL1MgMTUzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTQgMCBSID4+IA1z dHJlYW0NCkiJYmBgYGZgYGoCkysY+BgQgI+BBQw5FoB4xjxrnY7wHUvTDPoWs5HnesUWEfED DMFurWUtzkCd5kbhas3hTWaRy9WaS5Wz25Uj0ltXqh03CjcKVy1gEGvwYNBgUo1gYBDUYBRr YBCUYGCUYGBgyWCIYOAQacBqNBAoMTDKtQBpDiDmBTvJj4GH5YAV4wXpAw5yjBsYmBgkGC8o sSUwMAAEGADi7ipQDWVuZHN0cmVhbQ1lbmRvYmoNNTQgMCBvYmoNMTY3IA1lbmRvYmoNNDUg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM5IDAgUiANL1Jlc291cmNlcyA0NiAw IFIgDS9Db250ZW50cyA0OSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQ2IDAgb2JqDTw8 IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDQ4IDAgUiAvRjMgNDcg MCBSIC9GNCA1MCAwIFIgL0Y1IDUxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAg UiA+PiANPj4gDWVuZG9iag00NyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9U eXBlMSANL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIA0vQmFzZUZvbnQgL1RpbWVzLVJv bWFuIA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5 cGUxIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lcy1Cb2xk IA0+PiANZW5kb2JqDTQ5IDAgb2JqDTw8IC9MZW5ndGggMzA3OSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiZRXy47bSBK891fUZQC2IdF8Sxxf1s8ZGzbGQGvgBdo+UGSJ pM2HlkW2LC/2M/fqb9nIyuJD7R5j9uB2t1TMyoyMjAy6Ir96/NuNK3J15YpSXDnCEZHriU3s iU5eHa7CrR2KTRiJIA7F2nX0p4/440D/+PHzjefQx7aDb2LXDnzz5bPd1eNXnnDF7nDlBoLu wn+uE9ORaBvZ0UbsauSQ498upR+nK2s3NGWTi+dtfSwr2Yk/jn1Zl9+SvmwbJQ5tJ27Keqj6 pJHtoMQ7/Fr2RSeTDI9d7z7jTt/c6fGdSMFx7Y0nosihC603SfpFvLXF23YlbgaVNOKNLV7m uezUSvwum+4s3uFbeXem7z8nZ3Fji/dJJ78UK5E0mXgh8QyO7IaqUrJ5RNe+3AHSnBGJvI29 9YXn+/Z2q0EJNzMoc15RbLuAwo3ptIHCeiGPvS3ag4Zg6AHBTVrKJpX66pdNXjZSdqbYyA4c B1e4thsRnC+urGftV+GHnh86dGDt2Rs/vDzxZ1PeodayP9M1HxJVIFrfNnTesT0HySyP38ik 7yu5Eh+einjrxuF6DO66XIlLlQQbEUYBqieI//25ArjqaECTBtwKmP7nH6myT9OltsyGBX4+ wCAAtzbw8fxAo7cJHkLPB8pujLMOnR3he/R/4efacbgJf4LO86QqQbqmTMAFdP1FKfOWnvRt L/IvgYpDxxG/lVVN5zpE0Q3AgfjyhreJeNNWFSI+B6KeE/trx3WDS0R9GiVXQ7qJNaY9s43g G1KV3QNOEy/0QzsMGTc/9In0D8zidIcbYmoDEQJtz50QfLpXfZekPQ9TYB5y+CFHbCK6yAmJ 2vQI9QCDe2tNI9tejGzSXftbSwLMXjYiI1wasT+DHDItv6fXn3ZvCCRNUY/wcZCTxyETpYb6 aOLs26EXfSHF0GSyq84kExQ8stKi7GXaD/hjY3Gfy/pYybUOvntEIU2StWx6nRg1l4L1nF8u e1EnCNRIW7yCysivCYVYiVOBfHFqGczlYHiIklBFwjdn61rWLeSDBKo86g/bVCrVEvkxDElV yUqYL/IuqdUc1N1GpmhTRsp4ZqJvRV02BKnUd+HOlShRAQ7GFrCgE5lMGehEySkoByzKvFin rerpKQzEtedY64vs6K4awptqaGz9/LIla6rZFL0rSoVajriWEyWkAJsSSmJwkmpM/B4RHmq0 B/nTQVENNSNtkd/XnnqjlipfG5WnZrPSi4/Wzbvdx2sI8qIvQcjhLotjQO+RpC+SXpTgFxIv GzB+SM2K4WdrvnTRdS8OTPSKHuc4SaYIfUr+MDQ6BBAAlL0SEnwS6TmtQKk/m6r8IhepQpN1 sL9JHhSreRNZ7V2ZIWci+V42S467W4Pm935RxnecAdXQoWxkD+F7DyJE4+vncEFo0FRn1cva dFu1jCAefII6qSqRDh1zr+mp9KP+4yL3BYqG5fLrsVWLOsacI8qZaerG1nrGedmlNRaJrBZB p8abGStVzYNblJotVQLxwRpQWNqF5GQPLYdeTTydsCS+O6ZBzApNF1YbCMzRoHfsSgTWrgQM UJrAkDfDAqMnixl3NoZCNUzFXqIkDhVdhCK8Nr5liw/XsWfJa8cy2N+VWEtinAP5Y96O7fvR Mm09V5jXChLQ/yqqtj2uMQYdS6BKCyyRSuuJgj6fqMDQWtDUjYwSk1oPQBHqDWnE7xSA3RAF FX1JYWzxx6BlIQZRQGNoQtGelqgaEWE4q4qL2S6L4cTx3FARMwjsqgR3s/JwkBy66aszSlvg 6nhj3AsRoalJ9DOL6Qd06tfpYhrg+TLNn+XMexvtSolS35DECSokEj3UZboSwLEg+S2w8ROx r9r0Cw4lVd52OFg/oRVqCjcJNkReAmy5BMYEmranJJatECPwMtNoL2rm1G6tUW4VnkczGlgt AYuj98Zew5HKjqafNyhdHFjYvUpWi2l3HU0cS5XfaGDQT6mVrU56UjFQGbkAA0zQszNoWlXt SR/UvG/kydRKPTbDmA9QqoomYCXmJFNglWPgO6J72majFNdHXXF7R/cW93cY1g1GA84qlQv1 YvQMH0nXGt3ycfB4kV04S3JIvssOKQgD+v0BhzR7TH4ITtN3ncki3VruNV6CHMd63fRdm7Eo 6cvmt4/JMPn+RjsmmP2AHVPIpPpLwwRIzkcs4wo0nwyTMZNs5UPen77HPSMrdShT8Tf80jQI cmqY6+u9YU2+6SGT9JcGaQoThhxmbrXRF6lZuWYNhqs+Gv2hDYm8wLIphseqa01+J8UgERKY zL4Aj9qO/M7Fwt7D8WTUemLNVBM7CzgBs4f+q3jbC1VhyjqJAKUJoFn+le+bl/gcytPe0aKl LgYSOu4Uqx+a1KZauTv5r4GlaaCE7rBqkz1P0Vyfr2fD6mReYql2ioe0kQfEPnRYfSii7MQh UdDHlFLHKNY0dR+wzqY4ga+F1MLcCVMitZfkKytzzEQKScqlmc5F1xd1BVHAbZ9JsxKQa3Jx sL0SRkQRUvIuqQaq0LR/PSMTM5EzeZTgGLb/w9aPzaoxqiPUYxRu03K82QtSafMg63c18xpr yB/G3Jebh5zipUsUt7736dZ3P9167qeLQRqDBezHrFvX/wSiQM0XkdDNiUcw2qrMG2MIKuoh BXQuxtLgMhriC/wvhhS1noqSBHYcmgncDcuoVSRYuT31lXkJfnWSNiKWLbZOY6yhSW8ex4DR uedtR19rPKxef6TIPBvsZGe2coifGtsdHkngAZPsLoFq5NJoxiwLW7NXFl3im9d8aZockz2m qj+vRI23lLmYOYZvpobcZ2pcI9kHY5nVsB9N6nxkoXChy8stOzd4V2FhJS9MS7FueYuNcJBD BAFonqo5ghPwsBxkQtpJFMFVR4BaYsa1bVtyOIffVoREUumSvH8uxo5zwaLr4CcyaWBQAwIo 5JZ0XF/XDnmBRCPnF0GH5wgjopThGtQ6rsZqLl8hRgtONNu3fTFHcHlx8CsODtIirfE85uX9 y+exB9OO/2HD4xDTQ9mMznomh1FYeuTt05vf1+ahw1E/c2q7L1ULPJ+wC0Oakld7OXPc2zDH afmjRNo7NA+0MaARvfEXJNmnrD3pdZQsOsNDR3i+MDoyWwHuJjFarz/h/SJoti+UxIxrbMb1 Z0JyRLeRnVqMyP1l7LK5nfYfUmXPSlXVMDqVpol5I5m24PxusiDbtI/HNzZtlOiDLOkTTP6P T2vfgODZYk14hir78/133LamQ49fBexW4E2cEHZlAhK95gOjncEba2QOjGFvLXEfb2wQMrGf aXPs2V3CKKFH7hIpL2Ck+gKvgPyOMo4fO2z6+2HPYIvXc3lxzKOUZCyOK+7a2oRalGz0rWxS fKMWULsmlR9eLsXyVfKj9frte5AazddfEj0ggQXeqhZzaQRbvw2QppKVBxCQgvnNgclrioWV xlRi2ad9u1D+YGOs+JD/r+wqWmoQBoK/cu8CJdC0ad+c2pnq2MpY/QBAVMbaMIGq/Xv3ktBS fYIykF42e7t7b5W14JJ1BixmoCHBZzO6tFn2JF7FJ16pMA6SUDwVIvHKSCH0IrZGKh2GXukp YPPqjPxX0zFffODlpCmED63N0fA0SYL75na5XEaUHQrghLDXH2bGFVZMdFbBvlfd6cdT6fa3 rkujwzQO6KYqq88CLSPCNHALY6FHtBxbJz0hSVnYstx8nB1OxFNH7402gHGRG41pA92RQUid XbXejiDXGGQAIB7iHmyCvGCmigZZRjm3W/UJyL6EXMV5RAOwBvB3I1zdZv+s+jqwq0R6WmKd rrbJjP0BTae9jzYH04D7LT9nUWBa2jYaDlKJ8CWVmLaQHjAIWFlt7ScQpByQ2LuXmuNsceh8 sW1lvjhcDmoSqV8MtXc2SLtdMUT5/giB8eeKQ2QF03uWrR48/tv/uHOsw2kbV1XgAiNYrwtP +j7ReposNBJC2c3PTO9Ztc73iA4A/UQv54HZ6QxaGtlVaIu91eXAmWXizGyBglHLiMZjSSsN cO+h5fidRQ/caT+EQUfw7xo22+XfOQLH5u4ih8ZKSRnyewE9b6+RBapd1bwDjDnRFbSn20U0 i1UoJ0mYziaTyPfbL3ewcpwKZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PCANL1R5cGUg L0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIA0v QmFzZUZvbnQgL1RpbWVzLUl0YWxpYyANPj4gDWVuZG9iag01MSAwIG9iag08PCANL1R5cGUg L0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIA0v QmFzZUZvbnQgL0hlbHZldGljYSANPj4gDWVuZG9iag01MiAwIG9iag08PCANL1R5cGUgL0V4 dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9i ag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzOSAwIFIgDS9SZXNvdXJjZXMg MiAwIFIgDS9Db250ZW50cyAzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Ny b3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiA0OCAwIFIgL0YzIDQ3 IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANPj4gDWVuZG9iag0zIDAg b2JqDTw8IC9MZW5ndGggMzExNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iYRXTY/juBW8+1fwOD2wPZYsf+WWQXaSDTZIkDGwh3QObImyuSuJiki14/z61HukJMpt7GIx 24ZlPb6PelXFRFwWX/78PREXu0iEFouN2Ih9korDKRWdWpSL3XG9E4fdXmSnnVglG/72s/86 4/99/P6QbkS6zcRqvz2F77+eF1++bUUizuUioUM2An/8r5PtersV5xqHX/DvnC826012FOfb 4tNVF0pU0qkm18oK2RRC/bc1Vokff/qHkE64q6JvVIOvTCl0k3dKWlW8nH9BrFWyTnbi/CdE 3B4SjljcG1nrHL+0rutzp00jctM3zv5B4KNsxPe/nTmsP/a+olDnzwiRncakdHMRb6pRpXZW 1PIuGuPwhWiUKlSx5ER9aq6TY4Ak8zlEZ/u3c3zoa4VmWdN3OSp1VxSHvKqCwr4p51Q3xOEY vdOV/p/C47uYxdNUT5P3Xaca6g/6Udg1vZusj3FHNvs9R/qqctmjfXVfOd1WaniHsqH237S7 IqgUFlXjMfpD0VaP4TKO1nYG+VvTLakBKA0dza9KttVd2KvsFLKra3S6kE5ynzQlO/Uo9U1u jMBUZeXuouxMLUpZIUeKgCzW4scG3+QuHBJGwb+cxkWoQqS8M9aufFHCttJpWYnK5LLS7r4W 56u2yLKqqHXOiP/0ylInxzj7kw9j6lZXqlsVnX5XjWhlh5cUhiAZRE7l10bT20thOn3RSL66 j1HSg+9Pod5VZVoMrjSdKDQmp996p4pVrWrT3cMYhi7aJUNhCpP6LsvOaT6W24i02+vdairj HgcdZ4lfyHejizHQ5rgbyqr7Bm9yNJpHbq4K2MlpUtbZtfj7sBZLgR4DryHIJ0YmdT6nllIS Y0+UQAmXTtZWWOPRzJMKhc2gTItiJeCPhgC6Tl9601uu7BluD5kfCA+ula3qMLh3GtoFG2uH vWP0G3G76vz6DK/bjQea1dRx2Sg6k5vve0YrLstS5c6H7D3DWMwPRU4DOc7hIUzrdB1AYRmo PKy8ryR24ka5gYAaBGvUNI1xrNy/CUzi9VNlTLvS2H8/IottKvqK0iu5YQGWU6zDfhaMWUK2 bRWGbF9fPD/dzDxZPyai3BALzQqUF7D5lIkj9llVhO5pA/fZPBNbox5rSncjIrCtoq44rBNi 4fMIQSo5qsejRFPNry/AY98RN2FUmD8+5AC7Aj8VGuNi1uutvPC0cCyvgJoBbl717aqa0Mah qUEFxi18BsNk7xfoZ4VXeuZ7CT4C3sCRb+CXX5UvJJ5YWJ4PWDx5YXhjmJV9NScHepP3HDT8 kTHGRu12YViPDJLf84ok7xmGsEMIMiExCXQHwHSm7TQmHrdEdvkVcXLXd2qJ7ffSAVroEBAH TnsRZk+rc/7pK2IYh3AYDsYy4jyG5Vp818Q6QV98NrtTiBIkqW9YpQctGqtk2Hh9YUmedybZ JkG50QFUcF/6fpI4vXlVoR2BLF1ixtQ14r/PsTMIB80ibEULsD1V2CTxEPn+24gnB8AiKGRR MKt7fnlEye7w6B4EsusgroUnaWJPSJOPAN0u1Epb20c0c/R9sD1Y06IQoqQ4Hoo3/eXa9o6A 0dueBaUyN6EaejBGOmzDXDyxAwNT7nM/An4l7Q8W54MXerA8N7Y8BiG7m0bUixF9A4ihwr+Y G3Ev1LWJNN5HeVxY2kNFDY/IfenZPTiBCPDHD23lro1m0sZtASz4M0rar9M4lyQ7DLkcV9T8 OJ3fIT0AcarpODgF6CdFUR0WsJbYjWWkJUiA9rIh1iWFeBts7wjV2XI9M4ABDd9/SwEry3sg SQaZzTwPP3WAu7DyoxPyOkOEaMkSWFUpbvB6Pi38Dp0pZfehlxWe47XGam4Ymv8uiZMGpzvF BnqaGf6jfs6NqV16U4BSLSyjRop4Nea7NywGuh1pfBbo2d0UxALdh7zQ2ZbdMS/Is7Wk+qea jr4mW7MqTW97dw8MgJXBo0So1LervgDD+ANyJWOznvLJ/PY9NBECC2NBBTi2RhNuhEXeDtgz LlodX9NdhPvMeF8RNfCP5EDUXGkXJ4tfTe5g551GtPoeOd4HiFj3iUmxE3RfmQQrOUyCNWIO lhzHee200Z3MXsN1aKKzoFWFIvmGFylGszkIPzE5PYReCua3YDWpomWkDx4j6DO13GMJL7Py QmwUVeL8W7x1CrMK8XHZAxQj4dt50i8Me7xHP8/VsfA2fkw3sH8ntacZru2H8yIRl8U2Oa13 4pBuRLrNxGq/PQEci/Lz4iuebwT9hz/hV8l2TdedGqt/idQ3xgDG+QAYHmhtCrIFqrqvaJHm FBIUzvZv9m6dqlkWucGIRr5ByMsFFG5pOwvcFy/PqSYJjp3wXUusHBnlMuDUW3iMurvIxrtV iy5X2Cof7JFosoG4PJuIdEAXiES8dVqVlAtsYeu3sQwQmoCXpXNOACGFWFtyWHnPC0ASTzUW ykldkWEeob/Z+fWJ/BDQL6EbdRuZaeI1f4mYIz897n//8sGeUmmYXVwYyoHJZ5JzODzcTXXn z2KqngykaZ5LUNQRj9pRkpajEQ+MP7UoY9cNnkUu/cTZmywLITBPXeM5OlIrdzWFqczlPgaw YjcoqjgM16Gps2nIhFaMMaLE88vVMow9yJFntXBhmSUxXBYkU72s7lbbqZyjh0wV2cWBV0Yk sCGZ0mB/YP3a0lwJXGvxT0X3o/kC3Uz3K2mLkh3jaTj05Pt7o9qavOoLFT9NNoz7L99SAaSX iyT1656Gdd9lvOv/+pS+rJLNZsObVeu8M7E/Z+DPLNDLv89/RWK0Svv9gZbpgXsndvDnb8P5 E91sD3T+5jjQzToL1026lRG/eBagfcbSKWiYYzME29a7lSlXpsPyP7UPj0vp+QnevGDYolEO +mQ9AVPggeHX4gcIbjS/o58f3XsUAygW51I5IKtvoKv8UVFEJB+71mhROVLZmVqMiLyZ6WTq fBxRvhOzknZHirAfLjGji/SvL/2rfO2kEyjVKDpzSLRfftmv8t0XVaqbgoOZue2b1CxaoOm3 wWCSef5j6dS0qsF7D4cv5zEkU14OXYC4BQZSF3CJ8k7to2yqBppaLAfKunMIxFQdcREufQYD C9JKD5wiV2GmhNK9b1FZGS+6raGrYjw2+Ens3Fr8fFVNyMpgx3HkNK3N6RCMGlYVzPsO2pZv UPp5ga9+nrK5h06/vgTL78yU0mG8v5Z9kwd/Q0MOCByYci2+wXXhnrR8CqHQIae5JeTKwg2E dg0Ovxa8Ec9U87jxjPqTdq5SAxl+3PNGKX9h9d7ocbFOwQzgjsu7iZHQQBrqDA4fSHV+W5p6 untm0sRqBW0E+th5NSwGLHaNHy+pId1VkPSkMWEtqe+xU1+K4g4AQeAqMiHYyKInAxjdUifv u81Oo5eo5S88iFy1E3KpRcG2DqiFyUelr5+26bQBafZEvyeYt4xV7+/aCuIMmhWM81htBsoa 33t9WfICR4641S0cMLygdfKiPHZkTgwXTPcYbZ8m82hImUwk8w69FjuDW8eLzgdGMdLs423W 0xP1FTtR+66Tyfp/31WQ1CAQBL/CA9BKgkiiJ3OzyvLkzfLAbkikDMFi4eBD/Y89M+zuCOiB U8gy2zPd020QU4SzDna9U5FpNdoTNawNQh3cmWsgWm7AefBofoBtO1yo3hQVAsjoTzaZ3AhX tx/yM2hAJYhUdOUnLMaptlIG1gSKO9aV7Ep9r9VWkH552vOrBsQnC06N7hMzwGPBxD23PYb6 iwOMElXlzm9zqQiZpKcdRV6opi7Fm4aFQ5CP06ibXswQJk/GvnguFdfJY3wvDnEmHieeTrVw Yij56uWEINPd+SsGKp7czZWchQ3dpgXwl276qeHVYiji4jT2iPgnUIAqU3RjOCUSpLycUVbs UOGXwQkASk4gPO8ZF0+diG5Iq44Vo7tSirP1+5L6EVhMS4ZwOZ5rC7mB7WrgrIRFnDq5mTDK UXGK/F+Wh7YFz/GNqX6HP7TChtEriZDOyOmqKnnN1m88KSopQAaW5Hyzk2oekE1ZoSIYh7KH U+PGQdDpbFuSM0kTDLxLF0NQ7tU0sAG2/FAL54kHFergEXD4Do1A05J4nCPPb4qdQnp0M0q7 sGic87yIyE+4uS5kDqXkZLmgcFV+DKA2IRIh8P4AXUMAvgplbmRzdHJlYW0NZW5kb2JqDTQg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM5IDAgUiANL1Jlc291cmNlcyA1IDAg UiANL0NvbnRlbnRzIDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDQ4IDAgUiAvRjMgNDcgMCBS IC9GNCA1MCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRv YmoNNiAwIG9iag08PCAvTGVuZ3RoIDMxNjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIl8V8uS2zgSvPdX4Ng9IdF8iHqsT36Md71hxzq2tbEHtQ4QCUnwkICGAFsj/+f+ z2YBEEk97IPbtpoqVmVVZmUlbPfw5u/PCduZh4RJ9hCzmE2TlM0WKWvEw/Yhn0c5m+VTNlnk bJzE7tPf/McT9+P281kaszSbsPE0W4TP3y8f3nzKWMKW24eEXhIz/OWfTrIomcf4VY3X7/Bn WTzEUZrmbHl8eHz+uvyfYULtuSpEySpuhSpO470spdqxgh/4RlbSSmHYKk3WI3bcy0o8Lb8j 0DiJEkT5iHDZLHXhll/eM6msaLaiQSCBCIptBONl2Qhj8IajtHvGmRXFXsk/Wxdq+Rulha+X whSN3OAxqdizKKzUiuURPfPmUxrqS319qa9vOl1EWU7VrR6zJ0AVx4//FnYv1R+uAl0fkHDD 9MHKWv7gFNI8rZf/vIfYbEoRc9Q1d3hFk8nCJfYOGP11qLhUyI1v9KsYMSPrtrJcCd0aRv9E ZY3gBBwlDHTmQ4gSH6kRFYGJujhTiFOxreC2bQTb6oZxa/EOSnyHUMCRHRpdADndnIGKqPcU 6QCUdVNT4/7G7B5Y6/ZQ0Xf19iofxhUhX4pxF2U2n7ooUhnbtB5paUwr2ObETLEXZetiDX5v 2LbRdRchyzPfNLl13bbMv89Q8ygfw2skdSoqEbEl/q/EkaHDcqe6GNPco4Iq64M1DEhajaF+ lUbanzQPsbntIkz84PHW6hq/L3hVndiBN/gbSP8QrNL6YBy43ZTXotbNqS9kkVwDSoC9wVek KlCSEezzl28R+0x1ScNMmMyj6JsyD1iYojVI8ajZlhdWN4ZxwFNYvBbAerq1bvIDFqO+FI9F yS1nZs8b17ha4+cZWGojIctfuaw8M0/odg9nkv2kqabS1oyoM5Xc7S2NCAUVHcYXPLzGW5xC FVdUTDxxEk/FPJ5EuROax8+kAWOfNhsW5L9/n3iT+TQQL4niqe/rB61eMVrIg1eDtrrMehFB jrzZCXuPd/OgdI4RHZs8FhCzYt+jCxIe9ifjh6hvbT4799ZCnFpqJV7ej30fFHOuWQ0C1zR5 BQeNujDJwldU6H3QRuqmE8txF4HaUWM8Cl8g9KHZI7d+RvLJvB8SCkDjzbrUrlABYFAB+hCP 9vOeJlcF+RaBeaCQA6QHAp8edKV3Jz8yfT3zAMslrhH71jVpqL+GpE2A44jXhYiDBpWCHtOg GT9AwYrz3A2wNCdV7Butzq0f1jNbzAKyQ+w2wh6FUJ7/aMzp4Ps68hyWZsBdTzy0S4pXT1Q8 qSkQUZDg/a7RKRDfMceh5RQFX+nTmE7PWuaxwIrQTqw8g2gVHnXzB3peioPAD2X9mPlVOvUD 62Ksssl6lcTr1WztKHe9S2LPcwhSoZVtuLEjt1IUKczIq/+hEt1oi79EQX3W6u5qCq3sRHtQ guc94TCUR1J4SNyRn0zUT3ju5+qTbCifjcamx+srN6dbXhkRxv2OLkCcsfkqLw8TLw+dHFEr qgvlIA/gUo896KvHIOqMF5S5MIFdRdtgzbKedD2lyAOM0yEOeSDGRhS8RbZotRdsShJz8SXx nI4YZMkIUIw62JMzDhQPNY1cDpgoFarvPsf8bYQSW1lIXkXkdLQqgdhAdIaBPFIXq2DkSBpq 3mptDw0NKDLmfYxgys6yOWTX2ZihrBYrcYR/GBoat/GJO1YMHMfUE8QV74oin7cRe/4qifLv qdPndWfa3U4YC9oQ83rRyaaXokNJQFlkcfIcKarW4KWorOGoraECFRhH2VthRhcLqmPg9aT/ ckGlSRqR5JCzy+KQ0JdfWN57+/ZM2J6sAP0nC/dX2y6ZZxE5qNoxx1u6fylWa2BHMlFp12bn 2nzIfs8we1aze3ROF5PQLqU0RAu4wlSyPRb/RaKATLe7/aElsnYj30/zZBLYdxx+bVwJcq3d LjZ18HuygSVWuwrW2MtNWPdBHCdBYqhNRKB71g6K2WL/cEyR3tojSNdnM/WLzxwQGmeKfBXn 1/h14Dehlc61vjxiNjbQDToCXp7AFtDkYvMsglHq/R2+BOEPY4CvO2pcWeBwIMnBPHZiDAYd SCqBzoleiRkHnHjc3zxOXNFMJpyiMjc17u1DnLJQJj1dnhSvZXHxfnh8ZSP2Ee+SVvjhLEvp DVLvA29sYBCMS2NHhsdniNHaSss3aB4F+X2Je3X3kCWLn96b/TSHp3BnZll3ZcLuzC60lN4+ LOSsw92FWND61iC2KC+ojuHSpAdHSfujBNW3rSqCI8S6t+behgw26X14Ox0T/EzNm5OmU5H7 yzEZTK4ZhSXbs5HtMa9bccQwk8E5DQXgba+hi/O95ZRydKalu3XvcbJTaKeG/YAkPh1iM6SS HsbBk2LwawjW+WqEoip/YxYDA33jNaIk9V0yLba7gaLwhq2SbB2xT21D78V+AZ+p3lKTIIbV wL7rTdCK+AKsZBKycyzq2OIT8vIQ1j8KH7rxMCeDKzfMsMVRKMydpml1Vn3vXM0fuKgqOBI8 28M182G4ckPkbjivMQqW41XCUtaAx7ODY6OI2qPVTyHW352jqOYn6k6F/CnBbVuNSDTcti8F VhzF4dVoECW9IURHgovqyAwLkNvJho898P+LG2q7RQinUJJg0iLXbQNcI+8FXRRpz3YXp9XE T5CRNPZcCd0azwCP5vUWHDHFbdtc3ERJ6ouxGhpO69lvl67fFz5uEc3mZ8PmvkUp6dZebMcs iuPk7OpCeLi6S4Eb4uT9Gzb6bJ4NRtC3KuB65QZSL1lpkKwcP+c5SdbqcfI0TuI4fvwqkFrp Dh73gjvbO8tm7thNouk8eImwvt8LGiCsJU53izNroruArjfd8a7apHG474QpYJNEsHldUjQP ZVi4eBFY6wYNzf6vuKV3HIx9sb85rhyFKMjzt98/MBjXVZKuR+F/OVtl8XoQb+rjZUEuaN0+ f/vy7vkfMNCrLF+TnS32Ncd1Y1pJ8/DyuKR1wtKXp4i9q6obqchn3bm0a3htAEjToVX2O/Mr TeaWTAjunOJOkUmghIE5LdtqeHWyVZquSR12cNs0p+wjyntXHfac6c13rOGbtNI4d9G2+D5Q 7d9+hMo7HFXvliBO58ieAeOBX/Hl/dlyco1IqYSQtsZdlDvotDFkYbADLFb8IHciszN9PWFz Tza3V0be57Sq0VXVHRlO3MjEjDET+sJRJEF3LsYPOljTMEjcL+N79wE18Dwdd+Zqnoe1Qb1+ efK929Ld1xvDH+ji5uRn7D+fPw2akuTrt9fAu3j0HM6tDwzqQCuQMHdnwFY4ke+6cW/lp7Ev 9J03fiI4wnsHh7MaqvJsuktDz8L+wuiWfe85ae1vBJKTgNKtDcfMXvCTtCvqbTcyR+EpfIH1 zdTfUi+JPfVIYoEyBM44G7X14K7ytXecpSwZuX7cZs5U0X4CcmEBXIz6LOx+ty5IkC4qwYLk FVa98l6bVzvdILu6n/BgjF46sXLC9Cy8k8kxFuSnMZ6Rz5FXRmNI1P/brnadhoEg2PMV/gAi YpFAIioKOgRNJApE4WBHnPBL56SA/+R/mJm7y14gXaI4693Z3dmZeqJMb0gPdtdu19FsDCPI ERcU2gPqaCJQfoC75fae9mKGhJSrQR6pgOGhNr6bcBsxkliyA8WNjOPU7IO3k6GdLpPPy2RD GbbXtnuv/nCL74iUUW/qWlhBPmZRlpGZlIme6qoehMA42FHgctbNYOxtfeO1bnriVV9hnPWB 2EIuu91XOjRGVWnTfizMKvS6Q8FAtQgdG/U2Mh26/+Ggiuhg3I6CTd+zSpb/ZUcUqB2ubV1k vgx7Fff+yNjBAy5uc6KmGns5h+QWUEZipOgwTr0p1yddqdU4eRfIyto7ii+9c7pT45kDcsIs mQ6b293ZBbPoejzbVQn6wsKjjFCxRGHA2TCJ5Zxscpqk1M3wny4UVjE5KQMLEhvjevJdmk7K Za4ynKLPTjV/EXnUB58FMTWnJM5xYzkPRW8oOnX41PY/tWbHjnwOcD7/0GM6ANfz8qjkQNY+ 8dFEQmKq90+PxeviTXho+T18K7r8XwZEdd26ra+8rMJQvMvGRAw57jhYz3gLfUgsdDBLVK5W qaMkBrmNBlR76LUgDsWFk5/FU2I0FjYX67hoCcfZtgLWl7nmnLXQ921hWMt5gBPanPjLxTJq OBi8VnDY/RjdiNvYk3WOkh3uaxz8XiOLy6eBf9hc/ALFpKIKCmVuZHN0cmVhbQ1lbmRvYmoN NyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzkgMCBSIA0vUmVzb3VyY2VzIDgg MCBSIA0vQ29udGVudHMgOSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTggMCBvYmoNPDwg DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNDggMCBSIC9GMyA0NyAw IFIgL0Y0IDUwIDAgUiAvRjUgNTEgMCBSIC9GNiAzNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRvYmoNOSAwIG9iag08PCAvTGVuZ3RoIDQwOTEgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImcV9uS28YRfedXzCPpWmIxd8CpPEiW 7Ni7SqVqmYqrJD9A4JCEBRAMAGrJ/Gde/S05PQAIgFxJSar2MoPuOdPTlzM9nG1n9z89cbat Z5xlbBaykBkumI0Fq9xsM9NRoJnVhqlYsyUP/dfv2s/K/7n9bkXIhFRsaWTcfX+9mt3/KBln q82M0yYhwz+vzYUOpGSrAptv8btKZ2EgjWKr59m83CzLau0q5k4uPTZZub9jyX7Nmp1jbt9k lWOFK8rqzHaZq5Iq3Z3vFqvfAbPkAdds9YbAIunBsn2aH9fZfstWj6/ZsU62LmCr3S0Ey/as PFYEtPqOAELuAQ5Vmbq6LiuWlvs6q5ualRvWPJcsd59d7mdpku7cHXvOmh2rs3+5+m6AiYSH yZPG7dMMIn+Wj/jznK2hn+6SKkkbVwE6S0lcs3pXPu9hEKEY7zjDTByEEf6a1mvAfD9/dTjk WZqQixaIh454IOdvkiZhtWsWv61+mYkokLGxTMDd5PA3s/nP+7qpjunSuyzAGuv9ZqBFYgKr SbYMg9heCeusONJJ1qSgg9CykfCxWxWqq1VvSMADa2DByJCnIWi95lMPIRC+kYDj7IqyZP52 RSrWO8UibZFMxsYApXAVbSoNyB70b10w5m/7wQ/9YNMPDv0g7ge6NVqjLgjl/TyBs4+LpZQi DtRcypP/YUlVJeeF0fh2xwTLEMmk9eHSci0DOxdWsHeIjxQyiOe/4rtH+NUHCFaKgCsRt5vs zuuqFOvFUggeQWkKyGUUw4FzZdWXEWH8+3mxrTKgSG4EBEad/A+jr3eoyAvoYhlxbeYyEOw1 ALUJA/4iYH0UaVnBriiio3Jz6n/u2GeXNqiP3O0Dph6uvcBjqedY860NnrOCvBspfNdcnPDb 2xtO3aol5bni8Tec0JQFiuMzjG5jprkE6lXI9BTb+JDx6CvYS58Vo7B9Kd8e+8GrfvDUD/7S D5b9QFzn22bBLY65WYTzZrFURigYZtQDW1OBH8ps35B3hfBVL32OyZCI9eXUevw7UNqs6t1b JE2VnQgkDCW5VHJCEdYOKLCNCpITDHFOlaxpiVSxofzU5oF9cmfwlhcwjvgD+gHYJxKwz0l+ dNgiws5ybhjtBp+SsWK6TUdqz+CXasHjwMA53Tn44Ot9/c9jUvUMpDVXjI9O6Y9V5rg4cuJa yZqscHXjDkPiRDa8OeWyg1qiEiLdReAbltQHZE2S//+G2EjdGmLBqlND/ns6y/rBvh80X+G1 qDU0LYtDhRsOgbGWiq+pkoxun8Ox8fcIyoBzRcFTX8yxDmtbIsfgilsUsELdlHsXL5ax0JRs NrwNgy/bPANIHOsXTRGRIVOEjl5eXETRp5qYhEeCUr2Bz8dWrHfV2RsC5muhuLmNgoc6uCrH cWOf6DfHqdMq+fgxd3SeiEgZ/dK1d77CFMOnr8QzviUHHSA72vuzOBVsU5XFLeRfXz29si/m 5bwteYZrvMkO+Zm6F9TwCX71fQn+4564RfSU6dsClLEhC8a5LjxbKmUjT+7+6KArbpDA40Te Fs3/bDEqKQxP+GU/Jce6zpI9c3lWZPvu/oIx5H2pfRQV6HCwoS9qFWiqKX+QdXa7O6jUbbsL 8UWv8YcTf2C1b+FyRhVzbLw62+Diq8v8MzrMG1ykUFIRRbB15tlczTeuohYWnxxorL10yNSX vMrNjVfvfzQv9tNS8b6fDjjaRE+kq4VV8wQpyvj37DVM3xVJ9akOOiTdIkUeKGLcUKCukKxu oXzHnCcopWZXOQcP5MdiX7NsTafZnKk37zJeBmFs6XkAGNE146HgbRdcN+jFXU299vMuS3e+ p0+GLrbG3ezQpbt1wD7MH9+wP7O8LA/wH3rW7GP7GLj4uYP3yE9Pb6Fcl5vmmSDqAxEvMD+7 62fECnpNliNgHxYBYV0eKX1XyZVF68sk3YneFbg8Oft56dt8aoHiGDcYPr3pP6FP0AjSo2if Ap0reBDLyExv4R9I7h8JOODHM+jpwwJBlrHFLYPqe2D3TIoH7GKsuf5kdex7L/YOn+jCv1xK qDDeXfPZ/hbfgHNB3wt6nSHTroYXxnud7D/RPcClCucRVCKvMoz4oLtaSCK6KtnXSGp/u93j VfNpsdR4iBCvsvScEj8qLf3ay1wq6gBUO68HyFcpvbRcfd8pWhuhe75sTjbr0EPdj4xuPfpH nnsbcOoW1rtVSzMCEKMTXZY/+ocZMrhke3dq2lcdEUmk5yive8Yj332FtG8/Bz/Q3ERfrUoe q0sthdZcV6X4nr27foSCMJLCoe34UpkKjTebuoZuq+sfO7eniqqcf0aBgcPwuhK18CU9z1Bq eHuWWeroDvBdGtoUqsc/KtT5hzkNYR3qc7ul/gCl9GHBKkfNAqoe668LMRBhCw5SdCmxBbEj CPvp3YplxSF3BRa2vFmVx+0uP3d8cnZJ5VmBeKS98wgtsi3csTmSHShemE3sQKoJIu5OuKQz Qq0Dz1G1S0uo4YYmVTJ/gJOiY7PmfADf5HTuplwn538vfG8K/TYc9fFjjSbBFfVkT2SIK4hU 3FB3ko9ICK1LUm1RDL5DJxuoDmv2XsS//QnPjLH15N2WhVhPiuU+PyM5Aj1vY/92Bdif8PsL Iv87CwO8I5+ZDCKq//e/hWw9a8lfK4pA0c4s+lXwbz57/d3MxGAeyCV9KbopSqCV0kVBk8KP LDJc6F5iaMUFuJsbxKOTxyQYyf38IhcSd0k8bNzNx1sI9F4TlXY+UaFuVI9U2vlEBa9FJP+g 0s4nKqgUGw+2dvOxmwR6zVDRqtaJwm/SydDFwOu9jomiiw6NvU4XmYuOleTsKIBvaTzew+ho kOloKlOjdepqnRitE1fr+Ggdl8OxwRM6ji+5geN206mGaX3Xa5hrv+howKfxRGYGu2g8kenR On21ToaDTIZTi8JoYnM7nWroic3tdIyvYnHBp/FEZu0gs3YqM6N15mqdGq1TdmKRogwfLOqm U41wbHM3neCH8YAfxpPV0k580k2nGhOfdNMxPrXIfe7S2MswVQy8fUGHHheXpRyXPNL8otDN pyogz4mKn09UoihAEESoWhO7ueQjLyn4gw8q3XyiEgvw22Wfdjrehr7Q0X094Ci8HV/VsdcR sbno0PiqjludaMARQ963MhsOMhtOZdoOMm2nMqUGmVJTmeSDDOOJjEeDjEdTWagHWdi7nG1n EhzXUpmQeAWh4cP1Pdv8h+1q6XHbBsL3/AoeN8XasWzZa6OnbpEtiiRAgSzQw6YH2qJtdiXR JaVVnF/fb2YoUY59aupEw3l+j1/ePT4n0Zs0S/znWa96ZwgBE5BnTMLPolmm6m+SBYUpmcJY 7qqtOeo36zwEdlCdATHjvywGB0vUK4R5ztGIV7dtgJGA9apJEYC/O6eePz9G0uxMdAIsIi50 wUZUxpUzGMsBCJh8sLQKv3hLmhAKxw2BgEkshcqyRRDwujq6jstCGLxa6VrU0dVLQ4h8LfWc HCwMO5sA4q+DZefRpIKm0UKxPsCPQ4RZzsLwbiys1Mm7Lfcb/dnbQ+uT2dSoTAQR1NjB1FCO 5WSIls1FCp5af3LBkPL6lSsKFfQSno6qiEyXdydvqWoJC80cUl2Ltcxp0H6qMMEe4KFCC9+m Q6/roIhIdxcWctKNEsmkuXiFRD3tRkfKFAr3YOKIyahFLQYlGEURDMWBmj5EWswllflk/eVx qp6Q7NY1x7Qq96qyZBuw3P+1lmJikfZtWaYQMqQo73S0Gfd4ctd6TxpMq2w1E0OC4de6bM78 VGoINAPF2CI/1I9ZFXYnprLjPUWIL7sn7UnSTUJzRqDjeettkVoSJx2/RR2dRR0aILGa0Iae 71U+6fSZpONEo2k7Kw5WHk3lPEg9DW1Tgzvaw4GJucVQ4Bc5GKKUhp9pjrohrY+FSBOe9QWZ pjPwDVodSixdCTMSGmpTSvPbHYbZ/7y1De5IHkuXNFvFkyRdPf4S1X2S4pT8ZR+n4f2m1BJI rJKWvrN1Yb7TQdW4Iq3yT32L5hOkoC5eotvgeEjsZZ7/M6WQ2XQ9Rh5BsUf4EhoWSX+6R1Mf MIL4f8GyvEe0wFMtbWUbwwOc/BRtlgsGuRZq3zTalgCq9D1WMeAuAiEA4wlsHc6vxIlUp1Ys UFqtWTwV5/nbmA0uFJgi6UQ7VgOT+Fr7l+rD6PKlwuGp8fff3svhUBBbA5x0aX9IpqejptuR RxPGxvMdB+k3HYNXe3J3o3qJEWTP2MUMSa3kduO/xDsDaSBccPIJfjsL3ncaBXbRxo4OR5pd aWDEqIN97vypNxS1YH5qOELrazNcn0xLIObWwJjSeG8+PM0jM86FGeeRGfNsNV0siRlf7pbv J9lsNrv7fMUM5NxukevigdTKBiy9ZnKFH5XePDvkXrQ7AvuqauvYbr6wnSPMZBZ6M/5o9M1l fFjP48mkVEwxiXDHAD3AMNreb4j9Md6f2VJAhfqL5vgAs3sq3Vmu/MNTLhVBPW42KGm40y0u 8VX6PJS9APzHf9PHfbkTFk2PxxEScZ6JlalxkyybkvQdF7eUNqXKFI7Sx7vQO+9CUKm8qfpN jVKSZV6vLkNwewPRGarE2mArsD4FrmwIBCQhbWLr1rUj0Iz7rL0HTBe60TymUUK80BAO9sQL T/tWIe4TkbhRGQ5xCLZayNji383VIACIV8PJYCtOQdh5dIaprFl+cfHgwgL3KXQWe3Cpj5hv GpFZqabNQ7xRcOlU/eFckR4ninZbnEsdhRhKO99OZ5YLoQDz5czrttpCcTCyUHtZHIFy8WeA CGkxpNXTftQnieM2MjNi+RuKLJg3Ej40+IPXFQHk8Vx4Ny/urxgudLYSdmxchazfMNvC4LOC sINaslKobN2nKVJtnbTMci65xC3ZIX0qBX1v7A5j9qReKoJvXTeoKnJM5UIzSmZ9Bah4HFJ5 a9TFBEEZ0LGlA8nhR6R11L4AMCY8XOX9qUI8f2+oqVGNYfuhXc7BhmtOS3C6FqaAimpAgGb3 qiqDJdlRoIKSoywiMKtQuq5wHZZHxjrC9qhbienilHU40vrFmfJ9YIBsC1Lo7XkcZ5gyiTjl mSQQTOzG4haTL6JupynJegzvknYuIAF3jUp5jeDgZ+TM8uGEGktNQhQSqhaY0G+qLHPjGqxb 5/wrPQSBRpF1PZrv8uf5DovQrz99DX6km/zXQddIgxALK/dnfQVX9CztkCy74b0DfDNgxekO O9tr3zAaTxZJEwdLbYoeKO0n4THcCn5l7vauPRz7w0p3mAk6sHNRjHtoMtH8Dp7mq6V75PuE 79L+nEpS443txUkbWtb60QdhyUh4Rg8A5fqY7ME9vVIa0hmuvt4WkZR2KFzQiXvDSd6UgMvV sDgECugEZDXSflV77yr19a+Pv+9PcJfJEYY44yv9t5BQOD9vKoOL1WBLQ3OkdLm392qjLttG vkvMB2/jx+d3/w8AFYfBIgplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAv UGFnZSANL1BhcmVudCAzOSAwIFIgDS9SZXNvdXJjZXMgMTEgMCBSIA0vQ29udGVudHMgMTIg MCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzNSAwIFIgL0YyIDQ4IDAgUiAvRjMgNDcgMCBSIC9G NCA1MCAwIFIgL0Y1IDUxIDAgUiAvRjYgMzQgMCBSIA0vRjcgMzYgMCBSID4+IA0vRXh0R1N0 YXRlIDw8IC9HUzEgNTIgMCBSID4+IA0+PiANZW5kb2JqDTEyIDAgb2JqDTw8IC9MZW5ndGgg NjgxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXS5PbOA6++1fwMlXu lK2Ienuq9pBkk9lNTba2Nq7KoXsObIm2mUiiR492nF+/H0jq5e7J7mEyTQsEgQ/AB4Cz4+r1 b585O7YrzhRb+cxnCQ9YugtYI1eHVZx5MUvjhEW7mG25b359ZX+OzD8v/L7LvDBkQRixbcRT +tt+fbtfvf4QMs72hxWnp3yG/5k7YZB6Scr2FUw44r99vvK9ONyx/WW11jWTIj8x1clGdApH fWDdSbJS67PHvpxkPR6Zau/2X6Fhyz0es/3foScIIqPnLBpRlrJUP2TB+lbVRybYY6nzbzgX qu0a9diT/o1RV4hOsP3vb0nf/hX0hHFo9By07s6Nqjs8xnZMNI24tuwVy3CtkaJo2d9YGtBV Jmsole1m1BH4qdEhv+dlX5AJ9JQTA05/9qqBNQfdMI0vjbECPqruxER9nfQERg290cIfVsq2 hSpR4+UNfjrW6qByARthk2hP9NJFlSXTed43gxqjQ9SFMWKCx4IM52rdsXOjD6oTj6X06Br3 sjm2/s5iuz9ZG3APVku6DGs6o5iMxFmw9iTIuUa2um9ySeq2t/oy65i5XEsJMDvNHiWrRC2O uCwP8EsBsPLKVA1M2OdPe4+96fC8aLsRID/dOUWNlEyc4QZyCBgDFNKX67pVBUwtfmUPa/5w 5zLiIC9AnZCcVCWZUTXF90IpN+GFexsoCaBE1TlE2iGwtzlk9FDANgwRfliHuLLQY5K4RTYe DrCNvHwJdb4LR9QPqmk7JkoUR43APUnW17XMEQvRKIBUqkp1rbGmbyVK5yXYeTKgJZ2TDLEq LogXIdXJ7127YZQptVQmL+X3c6lJMeCfgR4bNbVuFilF+JdIR8orE1B8VA079PgI48+6g6tK lB6DR5M2lwuthAkFy09a5ZIQ7hvKplzjKqVAnpvkV5U0Fg6Gb2ZmWUUA6aT74wmVgHKahSo/ qTMrJDKio2qFYV0Pz5EzpFo3E6eA0BxiqU38Slwpnag+yDEYo6tKI+62XDJDcxnjWeQljEex 5Ti6yU1gRx7kWWYkuJEY9N+v2fsnJJuxuBTNEdAjn8Aof+w/rt7voeu3VcA+QsdX5ntw9MJC L0vYJ3b/h8+KVcA5+JUHGatWSer+LFefiY0H4wwFc383UrAxz9gPlSB4cPFQnllqzfpyl4GF 1vLOX4OtesMhKNkkGsmsUIUhkFaXT9KmQ6MBU+Wxf+iLfJLNXZh44Rp5RUZtjUdb+yD3goG8 dy6nSO11LCgmnrRCJdKfI8PZDBUt+6COFL/gEUEuKO9mFGwzARGHBS1rz+CY/kzJ7RjEcC9Z +/nf798dzuhv5s1Wdq1BJDWgpWyHZEBfTLlDbf1mynETWeC+QyACj0fBjpxZ/6uvHhE/070M kZhSjLzYTznbBl4UQB6CoRcG1ALv1zy42/Is8HbriP6IAFcy/JJZwFISpnqOoYQgszep4vq7 bRRzH7JA9Rfc2wUcGvCDOfAdvnDP/9kXeuL1h8A2bcB3vz5di+YObT1a66Bw311TT7w0hKs+ mXEPZXyumU+ab76kN8/w2MuAq9WzRor8QjiNr2yDwIuzucv36+rYqALehlFo9C988ucv//UX bs0wTrZ9kOsGCv0kuTU49oLpWjoHNpl/ib34OXzr9qKqhTe3mAVz+4K5fcEtTJCJonC4ShMU iQexSZedF1l5ZAsIkBJsAmzd6QqZ+vRTS/6v6AXPkgTRC6focRNe80zybPJLvCRhYRoOvOMF qWOX/V0arQ2nhr+aGq8UKL6hQvbcc7FVNxEs/L9VZpnj03iXUT9rT/pSmyoXthUiwxJLOmEY Zo52Qnf5pfnQ0gwG4O2SlEz7Yo+6LAYSHPvGSGec216E9MIcdKbGhrZRSNOL8M5ZNjAN0w5a 3QNanxzJDKPCxY26Cy6rb1mFXUCBrrvJwpCWaRQf2SqLqTeEWUIVVLkjDew+NYW3r1YgYg8U P0q480IkBFBzEXteiMTIfiviGxF7jjJOV6xIFnrJTMIc5wLUuJJgknDnhUiIlhXPROx5IZKY xWI01p3nxtJP2Hfc2mJASfhwXEhk3EqQx8l4tiIYodB6R9EkWiizRyPpmvQoGfOFZMyfPRsu DQufGxbECwl7XEjwYCFhj3OJcLebS7jjQgIYziXs0QYTS1sIcsCuGPh280uwvP1s7bPiUWIM GfY+zw/tqH2yA8IGOx+tDoVsVTOMWBjZ+1yOm8W0jZnCfLb9+TRRQaVdE1jX9JJmVnbRzbdS Y9C96B4FSytGX3YKM8qxEVWFvWCcHzEaucWP5l5RnUvM71a6/KshNzda5XeZ99000qaR9a/T R0lj9AZyFaw3U2ilGznWsNnlhlF2vB8FoWMPO5NbxnETe4v9puhLcIF9fDhjOShZNq2xUThu RvTSMO/YReIlbzb0vR4WgdkOapFFT+vykwlNb+iJ2YndjmMliLdhTuZR5N/c/D9N575lRPO+ x/5JKmh9vJ5pWwGTPqlG1xUYlbJhjNaMKLeTrjAxui6qNblSqRrrzw+5WMZmKdPIP3tFO+nj lUkMhTOQbMhnKHjg4zctbZxjDryQgwfbVYyS2AJ9k1dT5pkdtO0o9rhHowEhtiB3mrYwZ01u HxG0zm2oZpZ3ncZ7uPsfiyJQbQoTkoo2p6mmMKDbttZgCUWT1GOPebYmZolLv+qsKNGW5fgc YI/9R5h1kcyd6mlnIz71VLf4IsCycQVEmx0buq9ujqJWP1w2qikHeZQ6iwgfWnCFnTYiSzgx bHYzjQU0v+YI6GLwIQoKnMygEHvXouPD0bzsW4u8dDsnYXUYpvA44HOo0mA3C345FTaKSLOD vEDTWRwROKTVF9ruJssc6ViQUJCdIhvMgmOSxCYDZU+PnXdHs82AMaNV9/e3k5YgHbcnxPbh zmPvzDtsrhcM0eqhGFrsQS3hD/f7fFhnbMVb9tKg5hMxDmKUizLvUeNGS9OI66QYkxD2Qlqt sAfWU5FmjpFreSzVUT1SJYmyO+n+eAKtgiasAdVZN51AUR1E3unGm5xK7Gz2sH6HRBSNzb4h VyjDLZY2pxZxzHWxnJ5I2uQtfHGTFn+5lvzMRtRJhUyVlBF2sDSs53ZJrJKdULVlFTGL6205 Ra7bLSwkcAdfLIPuTZVGhn+ht12wJ+fJzTxJkciRCsgtcmosytkIzUzCzdUEiVUzzrR0g/rG oqkVijiooyq4kAZxm7R+9Mwhw+iGcXLRDkipY60OUFt34+g72DrzzOI92C5b6pY9aqmwr5Om UsNbnvjGEDn6OfF4bFPlLGuk2HVjZmO6WImv6Hsus4aaGIfmmxqKhqZ7gFRnYHUbFGLNAhOl aKjwDYPj+EfmgvhojnJi95vZyG4dM1ahAkt92ZgEIORdx5hhmzlXpg2BAlL/l/hq25Ejt6Hv 8xX12M54yqVLSVXr7MMahhdIgASBDSwQex/aMz12G93Tk77srPOf+Z8cUird6jIL5CH2Qw+L lERRPOTh4VydLvf3G9zjp3Nl2JsueuM9/c/JDwJE1iQNAy2ovWNsqhG1NtWNxPAGdgzeBlJn MBzoymI8wigkLKpkdaMkCQmv80OdZVpnq2ENxsKuEYHXOaRhgDkcAXi8BCPTFWHhp0/ewVRW 8w6NpoOw/oYIAm116/jXp9W36sdKvK6+VX+uHvBzfT2glUc4YWj+ezsYb2HcvK62MN7jZ8b4 4+oiPn779eP2V5hfpP/z+sWNadTqLF5hWKj+VP3TfeeC7+NoFDYymF1AYgWNA+gBkIDJhRjx GtsNg6oLEK73GQEaithAw3zPc6GyRagkbyQ8g56O1H79+6fVA7zff0euvKqQekMnuq7Ey0p8 evHap9iqon8UV9Amt+jTipZdw2hi6cNo6RDe8Kr/y6NMv0k1eg4+z8f4RtMe1NApJm99YG/h /m3oerNxLc6fiSeF8TpNwOr6xyQ0/58ADOmoacpte1tjYpG9JAZ60wtU94l8jLPYsIzmizwl h474AyanP9RfPTWuXRBad1LHB3XDObavreFzgBdlA0Gl3szTSKTY7oSHzYnHwBPGwgcmhsRj fqGZ5MKTUyCKYfqToWl3dtSSHHHn42hXpjkXmgLWXNo/0+7skLsl6vGJ7pZ6cEs2f08orfUz 1aZCifuK+n+HpKNQbfAbmUL19HULgkPMhjsqWgDzSWZOxGQ8sxxPJI21rWOmftwb5rbz0wH7 wdGtI5Pv8P12tz5uz99fWLCtFZoe9j0xWQxdivz/yX0Dbzy7s6iy+V5jHPs8Hp5yHxEE+dc3 OKYVsro7XIiaPB43t1sO0Wa3oUGNd2eOMSRNGv7YnP3rfwSTQ7heshPDNBso9hqL719IjFMr 9DgaAzs4QNyZHmK/2R+OuKhd+RP9o31aIfAv442kHs7CE27wpC/atlarl55F0OxxIi4CQnmg 8PP4gSb74Ij1mcjQ4enEnOj+cDkGPn8+hENcm2O/sZgyE8EJzmIP5j5rCvl2z+Pj5eTmJ0ri 0TBZpw1bd3Vv0VktQUg0PWXcjUBU5NCPkYRkaDB7wBAdHSxZN1xSiMMEqzZaGdQGlIhopYKV TazQ2PTEVslx1IUwHExtpBIr6BvvFNemqcMUjVITNn1qo+u+H9mk/oCogNCMd0m9kX3dx5P0 pDfS1mp8Uu6NBGUZn5V6I6kjPeON6OvumdDg8THOLTsjQJz0ojMgZxhVl51BfpnnvGksDTLL 3oDGGTEKcepNQ1RxtAv3KZHzJglyqYkatvRsvk2lTXqLQoHqc/IlBn2gQ0OjmfXthBLwoZ0l ygCy1RjhCSe6fGZJm6iOOBdtUyiBzoao9EKCL+T1Qjov5PFC+i5k7UKyLmTpfHIu5ORCKi7k 4ELqLWTcQqItZNj7vFhOPdubslROvN+bUe0aPyRsFt6ydITeVD3jCB5XP+MHPbKd9SN/Zz3l R/beetKNiYcf+TGRAYkfE0lQ+jGRDCNHJrJi5Ailx/jx0gzpFx3J2unEDn1PbXFebeq2X1Dr ujFj9XyrntijW9i/M7W2Ua1LtQpJdzMbwYQDTJyAabazC2pTq6XVqu7EgjrhFiXuTUdle0Zn alk+StCp2vRFSGTfUbr6t3bDEyx075SGsnVOqShP55SCEnRG2XWUmXNKQ6UrKnWmVHU7v62o Gzm3Eq+Fv2ZWWrRXM6tUaIazSur9Mzq8k7KzyrbuZuOOl1Kzcc/QWVxzgLBCncEOpmspjXCU rG4MZU2KssEIocEJE0Y2NQJXmNgpPQxXaib2YV7TOl7TMa/pKiUFiq3pmtqogdY0TGg+uEmo 8WwG4RWW59pBI/woNciykBXJr96Zgki1trYIKVzVHVMemlX9pBaZE5EeOosGWDdUecbzryuF 62EMsbKpRGcp3jdS29owjH6pHlwoghHlabTratF7mvcPCkjPbhEYNe1gMT5YpnRwbI2zdXeD oe/4vbpbn9c0IQ3EC6/7M0921VN11aKrCYQR7BCnGco2BL6xE4Ef4tAqQXg3Dbiv4eNE4HQ/ 4wp/qeCJTDZvUeYRsX1x2A5yx6cWsrffFet3nJpEt/0V+KTsGt5y6hqF9y2aR0iblXzuAsCv iBdIHCwd9jLb74r17gJ2+QJsGS5g5i+ACijjDfQzN0AaqTa9QfCw9NjJzn5XrHc36Jev4Ez/ yBt0WGDCFcxzV+B+th+5NHbZy2y/K9bvfIGb8Z1tct/fT7mO1gzuQ8nfPeM2GoNMcye6Vbrp ZGe/K9aT21wdqIiCMqCtoqMI1F1w0hvinSadAX3pEg27jZ9hXdfXNoQcccCJH56uVu+2Xy7H TSV/qN4/bjZ3l8dTdfhtc6wOD5vqzEXRFzhBta3hNfeH41D9qsf1cb3bbXbbf6/PmPFqV0CL it2C16LdE81u3Mz4t8v+8+ZIxgK1RCi//+pwzyNkU3eKXsJ9dH6cfLhbKhqoQpo3218pYNAO 4s6LFiSXgVto+UmbyuCR4ZmGlTRM8Fvn1/rxcXdhF8BBjLFMdiR78fX73fEg75zPQlD0oWtg Q9r9l+P2zvveNsItVMIpTxd5e+DbUo74lW7X09N278+TQeOXnQ/72/X5N7+rECJ1Z41XWn/Z +KBodHTC3kxQBnWr69ZEtROjGg1IJKudGNVISKui2olRDfIFTAW1E6Maidslq50Y1MWDeZHU kpri/MWcetZzp55xLQO4At9BWzNaEI4pGTDkuuRXdSNkz2EX6TcAkb7J5Jv039TwDW9GJyjL k5kxYXePt/CA7OlcGKZKF0UOtMTHQlJTADMSvupqwQGe06Ka9e2sFtyksbNaI4mRzGmtZUI3 o+0lla8ZbVlJ8xvuIWPy0unrOzlNVCvGcrDPYoL9UD4bk+qdHNZ7+1IO9lkUsZ/STHOi3slh vbcv5WCfxR376b5Oj3NiWO2tSzmYZ++E3YyutUz1Tg7rvX0pB/vsZbEfUrpNX8PLYb23L+Vg n+UC9gMzM+lreDms9/alHGv7HEnM84a5B3quVQEqaRo4ta3bAJX0UVmLkUnJgJXkjYa1JizO Ys5qvLnqA1jSEDo1xjcd0JJGZFitzSxc0msSXEydxtuJVtIwFsFTyiUYwm6SWlSi9zL4RZva l3IJhggWQzdN9E7uNJGwaF/KBRrCdi1HJqq9TPQnWudSiYSIFJM0nV2Q0fG0TuxLuURC2K8T WdNyIsGhT6xLucRBxAmqUHqal+FNKxL7Uk5xMk3ks4Th4qws5YTPxiwBnLr1MyzjJH1PSVu2 cCxU/ux9WK0Aoy4AJQ25U1s6zqvTCPLR2NtGnKQRYbWW1DjncJJck2DCXDrBiZNxZN9H3BRi CYMIEwxUaU33MvX/PoVNIZcwiDDp8lx0sm0aYv7BvpRHOIg4UVkuOtFqKqUJagq5REJESpfn opdptrGJfSkXUIhAQQ1Kn8LJdDnbB/NCHAEhAqWnPxK9k0H/tEnsSzkFyszIm+eMawqK8mOA SpoErnCbJJuzN5XUzlo0nNCP0icaVf085KwWDSF9QEoaQqixE+F9QEoakqGZNWoWKek1iTA1 tU4pgZe7rm50Cp1CLsEQwYICkoHJyV3j08Xbl3IBhoQwNdTWkx7BsgUPbLsUPLlcoiFipSVQ JWonh8rqwZOLJRYiX0I6pYd5OUxh3r6UCzAkYMkLEYu20bXNoJPLIzAMu2ForWWy3SCj/TZd Cp5CTsEyQkmWLlzUdUcZiWzLn551EjsyRPJndK0EpIpV2ZO4JgQC43RZgFnHgMwCNXQHyUvy W7u2Yxz1ez9GQ3YdQoPMs83L4KWAekRHKZfZHtFg6y5rHU62inh9tC/lItsTNEiqX4meZcp+ U6DDjNfvilgTHADr1H8vW27zCTwKuUz4CAiVpdwgA0Y5QNTU+l3+roSHoth4GVZKRPNCLPM9 4iEvNYOMUtRm+CjkiIc3H65evUNxrj7cX/VVg/89iq0mxtQCPK2sPuyRY1+uVp//y3e17MaR w8D7fEUfnQVm0JJaavV1sbnlEsRALnsZxINsFnbsTOws8vcpinqQdHpPnnJRaoli8fH3m8n5 fLx8fb7+nO7Oz+fp9t2fb27/Pby9xcaR2sEYAh8sYO3a4H2DKF3od16x9RSRTzFPaTomHGSZ VxJAdKVXxzFuzk9P9y/0xaNDUUjrdPTlhH8dbv75eXd99HdEgnNwKXEzbIh9+Hz9UrgjHDE7 Xhgck99f/KfHK7GkobqSd/3+35eH+j3fmbrs+fHh0/n5R93VOSePc/5xuZ4/X6p3Frg9xF3v NHoplbzTDAWNTLsJusBBcx/b6djiu9Lo/iGbTjMcNAasJI7GcNAUQOJoDAWdKWcMusBBm3dn SLSnwrbvFqZ378307sWY3jl5ibm1BPw6hRxPAZEWShKlSEO7UQKCsm3yW3lTx/+7/eNw48fP MH4ubREigbYO1D7jCLFv++Hpcrl7eephwUfccc9vixU8urrmo1ImHPJXnzEcXj3s02jRtrhP Lyvl7F06oRXb9mkaDf/naCgwy/7RXjd18qI0/wQa8kRwMJYqIHuLu73yDJVF1PEkecZ9fbW3 uNsrV9IEtJxcljzjvr7aW9ztle+pLG4n+TmGfXW1tribq6eiCQijkpc8476+2lvc7dXbUlHc RLq/77ivr/YWd3sVDDQEoeLI16i4r6/2Fo8KMsM9v5+BZNyUWcJjCM1dMDIMGh37iKRelaec snMTjHgkXhypLW56kU5nOpCbml6kD5leaWRsepEuYRqpbd3Vi7wn6YUaByGXAmNpr4d6LLZq 6Lt5KoCCrxjr0yLsLbZqGGpBfyO/V3FCb7UJe4uNHPp2sYyeg64YrV9yw9xAK4YhliTK0n3H qKhxE/YWWzH0/bJTZY0h5t28CGuLrRSGVBINXIJnjNkje2FvsZTKuiMVETIlQXu04i0cVQQw myjDNqHIB+UhylMfXGn1QG2Oir4rRXqc6ZUHHGKl/9pkFDur/NFmrXm/rohLkkxK+y10whhD wSZ1o6GVwZBJab8FzzhuNPwJ2RhsZTBkknUkVozZZQ7C3mKrg6GToCKRIXI9N3PV2mKrg6GT rCOx4lSHjWZvsRHCkElJRoJmvGJ+HNYaWREMkWz0Q/CMU6RZcNhbLEWy7alERkxL2/PadSJD gGlkmy4E9aKg47Qgx/XV8oG43OCePdSVw9unc683yoGgsdNME1QTivQJb76cNr8rFHlPaphm aupFiWCM13VeKMdiq4WhlUjZWPCMU6nsw95iq4XRMM3U+IsSwRjaCF5rR2EjhiGVSJ4VNGPk +iyko5AVwuiWZkqFokAwhqs2p4WjsFXCUIrOQgxhFJywtthqoe0W0Sl7sV3Daa3jZ9OOwVIr r0SigqXle1aBfvjCoacqUarfkKsIOopQOPUgLc8H5pSDuTjl01yKk3JWoeJCDw9K35xPkija wH04fDsEpAdYrn6eXF7pQkePRjuV2vJx+vpaM+rapBmvY7LiHtNNQwZbTQzNQO6qvjBGm5SU hgy2mhia8fSmgmcMjaSsNaSwFcUQTaZ8KnjG8GPIUkQGW2EM4QQVmg0nR92lEJLBRhlDNyYl VYy3TUEISUOri6EbnZAaTttpyVJHBg/deIQOgqxEFIKMWJcj/UGcRbIqgfj+8GsAxp8JaApl bmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzOSAw IFIgDS9SZXNvdXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vTWVkaWFCb3ggWyAw IDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag0xNCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8 IC9GMiA0OCAwIFIgL0YzIDQ3IDAgUiAvRjUgNTEgMCBSIC9GNiAzNCAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTUgMCBvYmoNPDwgL0xlbmd0 aCA1NzM4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlFfLsttGDt3rK3rj Ktl1RbPJbj5mF8/EqaTG8yirKgs7C16JkuhIpMKHb27+c/5nDrqb7Id0PZOFr3UIEI0GcACQ s+Pq7Q8fOTsOK84atopZzDKesLxMWF+vDitZRJLlMmOilGzDY/X0jX4s1J/b53kSsyQVbJOl pXn+brt6+z5lnG0PK06HxAz/Ke20yKM0ZdsLDj/i33a3iqMkx5On1frx3O1+rfdsX40V2/79 Hbs0w8D6aqzZl+lyhWTsWPKKVe2ecf7q4fX2C0xseMQl2/6NrMHIrpqGpj2yiu26vq+Ha9fu CZ+aX2vWtGy41vV+urJD17Pd8+7c7CKyw6PCsYT/c2Xtu8ehO09wYHFlICPjqWbnqj/WvXW2 6vGseyJjm8BanOoL1m03HU/s83oapup8fmZTu4cJRODVA6t/39XXUflVXa/nSV1zmBJcQ910 +4YsCe3X06nZnRDuandCWOKofPX5NbyqRnbphpHtTlV7hKvXvttPO2icm3E816zrjaV127HH uq0PzehGgv3YImzt2FfD+GAOZ0P1xPb1sa9w1aZrrTNZXOq81RT02hhhA/k0nSnoTbuDjwM5 0HVXXLfvziRYTHB9naYdxn7akXnWfa37U13tI7Y9NbhC3cPBS9XuatcL9lQNi5U0FspM241s qGsIm/GkkjRcEGeEmBI0NH/UD8x39j+LEe3HBRH7CndJ/4TYqOLrDoehHpW9xbk7NZOKRBn5 cOybvYpapYvEu4M54lK3KvL3ygUk0XHtcIvZ88G63h1guUeMdcBQj/vntro0OxvW5Dauu25q x4h9N7D3zXECMxh/1FTaseZ8nqCJyz6YwDimdO1eq55CeW7+0PHv69+mhqwc6icEeNddrtOo RIOyigI7d+1x48X3jBPa3TPbN1+bfX0viLHQqUQhDtPlUvXPDxR43BpnTedxwOMjSntkC811 1VGB3QsmF1IZ3De4YPM4Keep5D9+2D5Qfk/wHszRpEYM9g2pVGdm2pGtsjK7sRSx9zA1x0YR t9mZKKgi1AVATcLY4VGc6Cseum689k07DnPQmeekJQ8qBoV/sTkxBWJ62RChpfxcq5KbH7Fq QAGj2eB/EXG0l6+GF4uVnHNlZeFJM5zYx399/9fDFW2+rw91XyvWUYcDAYYIPeb90kIQEK4L /vbWM+3Uq3fu+dh3v9bOdXRAyMWI/bNFY0RNd23txvOBPSFTNWUJf8F+VBnr9k56itTU/Fj3 la75pQ/47YcdIEdbRbz3Qb3r7tr1A6Ll0PY+34u5VCt2QW02yNOuHgZUBCiK+mLLA1y9ck66 KdI0vy3Sp246o4+MICeoT7HoO8SROhLdCyGi9g+iGSblatLmGOlRnjDJkyjhetKqSWZDScqZ Us4YT8ooF0ymaVQUpP1pLYoNmlP/TK3nNaZ9moooX/PEffzL9qfVBmOnwD6Q0B0+rf8xXR5r dfPxhLrdD683RcZTvHorUa8nUSnm1xO4nCS0DuAgkRXqT3ApWj9ye6edLrzJu02c0XpBevNt 4le4Q1oU8EO6vwv1u0Qa1zK1z7mk34X6HVuVkluVsrC/C2l1svKVupjvciGMy+vT877vkv09 f6Hk+euer90SL/hSBuqFUgmN3NyH7N36mvPZ1wvNsHueQuUlT+974Yb+z/i5KNy6iU3SuKk3 FN/PVPkJndlPEzsnXt5vHVP3ef6/buNWgMmGtnI3qkIu7j41l3tBhcb/EdQ7nv7p7H8jqunc L9Zjd0Gj+HrPUyh5nsZSwt4mMyC3IC3KdZl9w1do2xdllN+14kjI47fvs7ufFYLPLKOppLbS T+vt61ysq0esveIv7Edn7fq83td6tGKgoY3OnxrqCP1BYb8n9M6P3nVvRNM6OO8Jqgd/v8Vr P+DfT/DuCxZzdOInht6asQ/s0y8x25uvqSTHZsUuGkmBZTph59W7N6syo368yDX0FMoocRUU dBU4V99YIsno0WXGkqs3tEoKWeaoaOypIPJl6aho7Knk0j9IY0+lTCPBrbcGe+6WMOypKOyq JBgjri8Guwclaer5YrCnIhPv0gZ7Kmhv3kEaeyol1wcZdw323MUjWahHIIvKcSJn6GkkhdZA EkU5Q0+DZ56Ghloj4hlqa9GMhXeahkrTVOGsKUruahronirywtPIb/wSmfQ0NPQ0ZOJpaOhp pKWnoaGnkWSeRmJv/9sKXQufJjkigr1coK+hrjYcCYsLLK+rn1m74uz4shqnHXd1eLP69+rd Fp1F6s5C3W5DbY9KNU9ZVoooVW0xjSRRHNtamQrsLZEQSDwaxRoLtiE/B/FXMpF0Ji0/kkok zUUUL/i8YOQUhX4r/0gOUWPeUIdOaTlAgVFItCPL2kOdKkNuNykuLXPli7NlQIr1zpMucx3L m4y58IR2mlLFiNQXmtmFM5NQ5gwM7h9XV62JTIrmkBXfCoqWJwi3K9fYylOJWzlyja1cSD+o Glu5REN15RpbeZb7/mls5eCC55/GVl6Uvn8aW3mYdI1JntGPb8RHy1/yXxVNoaZiwVKaoRle jullqpk4ilViGVp0SSMc2eH2mVAPkvkBPk7IVCrgHOUsoaPJzEf9eckw94ZpmEcfvbSM5lL5 gCaKTQwdMY/RuaR6+RHj1n5GqG9D+paY60Pf76X4fCTizaOVRh4amh+zlBqiwN+SiI0egYtG 8kacpUYskphS44oz/JylglNgvZc5eWTEUE1fPpo2+m94JrFOhZ5JypgW0wrB1T11476pjQLp zJ3aMNjWslsrYW2dg8BcViLmUebYmzGqCF3S6od40fciCXtJGiWuPYPzPIpd/RAv+l7sYU+g Bbr2DJYiktLRD/Gi7yUL9rIsEq49g+d4zfohXvS97MIetlo3HzNe3jf6IZ71/XLAuANn3HzM WJo5POuH2A4QrMGYfXcY41UOCi/HdI/Kpei9QtBi0DBbGOPmVYkRGdibKeOmSYnTAlNyoYwb dW3co0xx41oS5dlCmfLGtW9RxrsoUSalEDiU0RjrAXyyFApxSAlLGdxVuHKNQRFZ+BTycEgJ S5mMIuXINQZzZelSKMAhJSxlEE3XnsGS0x7kUCjAISUsZRB+157BliIhhQKKedmFPawzbj5m jPeTwqeQh0NKLJTBjHLzMWNLkZBCPsWIMvkLlHErB4XHkNOiWBjj1gFJEUix1LSXVZJmCYVt 5oubI/WuN2HciCupyxYvfqHUj4aSqjXmJa64NySuZFHqcUVjLM3CoU4AQyZYpqDBeHKNkYmY u8wJcMgEy5Qykp5cYzCDZz5zPBwyYbEHCnBXbrAdJoY5AQ6ZsNjL0bVcucGWGSFzAmZ5mSWm CC8bM17et8zxcMgEyxTp5WPG6HyxcPRD7DKlfIkqbuGoHi1jSs7MFbcS5unikMVNrJ4uLlu8 POm342gZTV7Ub4eLF8QbsR8TLc6iTL5IGPeeRJjSm78zztTstAQKcUiJJeWc+/uQwZYiIYUC inmRhL008fchgy1FQgoFFPNCT5QR/j5kMP7jAYX47fvnIFlEGentQzNeSjqkUEgxL7tEmdzf Tw22FPkv42Wy3MhxhOE7nqKOHAUB9b74pglZEXLI4XAQYR00OjS7i0R7Gt1QL6Th9/T7+M/a qwAq5jLDRFZl5/JlVVbYQn6L+ThQy9RePbRcRESK00KB7LbMba/UN08AjZxff6nTjeLXUr5a dJf4dZH7hEuk83Lsv0j8fPk6P3b9VCmF7ulOZ9TeJJvWiXfNallnynRKIIfk287I/LFHyaYT wk4JO8nLHnVG7o89SjadEHZK2ElexqkzSn/sUXKOd2ftdkogh+Tbzqj9MVTJthPCTgk6yass vSyi4GUhZdsJYaf4neTTAHtJ4tVDy3lNYdn1oRx2Rp7khyTV3wU3ZUaTkPFDkpbg6qWP0Qpy TPw5qD/xb+b//rT7fNx9/1POYnZ8gYGS7UsWsTiq8DrKQRoQOZ6heN09NJfLsH06/nu3BzAY bdgeD5sqL9nxx93D6drNU9KRmnDCQOpqz69zL3R73HURzjlXuWxJO82kpRbJUl/53p/VN5NQ t07ntlnfxDf9z/FmpF//etzVtWj/m3zIn5P4UBmFEIwKFBdGJQSjQuPbNArBqMBqYlRCMCqc W1pR5PZn0GhdEIJR4Qq0LgjBqLxKCmHYxQA1rW5j1b/f803Uv0LFI1YxvOdoiokqKvkDHnei JiyHdcpqLH84frd7SLQOZabdJZJAWY5oKfY+XTjvtgt74/OyLex5mNqvXADw/U+FZK0WH61Z jIu0ylmJ+7ksxebmyyeWVXs+rvOVdc3asOMvn1U5dSz34r93hTg50RNNoV8PMQpef6SDkDu6 AqJWFfkhdreJIVDpUKXSN6lfFAm11AcqpMBzJD+kxQdzlVfkOEpp4NZllgIqizC8snuyXGxj hxmcLLExowSzTa0MZbnYpglmcDmXxowScEjlzsJAlEttQmGkQJqMESXkiZyz9cpQlott7mEG R1dtzChBMa8XBqJY6lTpvEtwM5r0akHt0gsDUS619YSRNLXJ1QLO7LRwVoayOptRsLuPCKfu ehBPEkO1KaZ+PkSFodpUSFMdlQZrk3i5rzxEtcHaZPOGXZsjqUqojZXOhn5j8pZrExJxXdDP mmspYExIEpfzQPboVVwjJGNGCXkuHxiG80D26FVcI3pjRgl0+ZY+557s8SvNlDFd6EqjBBrC apf0QPb4lWbqlF4MSqMEg3IAutMETqGI7MwmWAsYuMrSJT2QPYIV24VNsBZ0CIb1QDZslx+w bWqP9YRvbQ9sU0+lygyhtkakMuM+qWzeSZWL6UupbC6FQRfrzPPCo7rwvCjJ+kdQm1gIalx0 FmopgL46dSEPZA9daSaND5nRKAHbstqH3JM9dKUZVDcyGiXgGi8yF/JA9tBVUONasBop4FhJ SmdlKHvoKqjFCaY1UtAUB4y7/DtlIqhLm2AtWIhDyN0OsCUlqGubYC0AYjGMO5B7soG6/ohq U3z9VrVY24pKXUldq3S2TPodm8QGbJN7ocPS2Ni0CRU63HGZQbv0XXEAdmKXJjFZ5R/CbUJC AePEmQqUYGEOYXc7wUZPcGfOXKAE5LrOXdgD2UNYwV04c4ESAHMSwJ4EOwc3pwR3aScDLRQZ ZdmBPZA9hNWYehdvBX7tDGVKUPOsUyhQmUQ2wVowFGrYA9lDWJrBSWYSrAXcNVnurAxlA/cN 1bbqetaQJ7JTRzloaGydyvgTiJNrochRW7nDZkgoNMlOQsTvKGclLDkhyk9kh1Qonm4Rtv4T woUzACjBHKQWaU/2QFUIl84AoATDmloZyh6oCuHaGQCUYIYMjXQge6CqOThy52ApoBqZh3Qg 38L4AagSqShxxgMlaIRtkQjhzJmElVBlVDa7MpQ9UBXCuU2wFsqcimxXhrJG+O7hnCDuJMWm 5JCmrKIK7+tDVKmD7/MRr9ZcvlpL8WotWUKjFdjCAwQPX3q1xmw9zbzp1EM1RE1/g+7CnKLw vglHq1zcR6Es1w/B/j97HPgrTTSljSYMgl4fFQVB6XlIvi0QXMdA7nzj2I3jSpbrh2D/n02C /spvCQRXWRpHsQkl+7ZQwJAkK3DtxnUly/VDsP9P739/6bfEkla0VUdSfFskmEaizInEeBp6 rmS5fgj23z/s/TV+lzzdiwBvWRy/1BvVt3mfFIe6cLw33oXeKlmuH4L91vskqw6lGhzPOxxJ 9mn0BAded8RogiGnIv4zOnoStqd3oBijXlTrF7L140jEh//0tvhQGtbwRRw4x/fdw0/96zZz lv6FPV0477YLa9a16Ufesecra6/t0LdseuMzex6m9it+vjRzMwx86P/brP00HihN5sSpxFcr llZIeeV+lb6Yy09OM+NNe2LN5QLrwsojcs4Z/w9vNxLZ2p85e5lmMr7PokORY/M+RgGp938k c5Eyp/3qFzZO87mBY5DWiWE1mWDwlo3b+ZnPC5teVHGXAzuetuVRevLczKydzgiNL8KTRSWD 9t9Lwnu/nuRC8hCTTFEQUOSZcKo5c+G60uxjUj1IL1wnFGN/kImclUnEsjqjMWZPE1osJt1f 2SggTADhDndrFbMypuVZnRyqDEuLktgVZP9ToJLGNfQ5GqhKWZJiTYbBovJASUNQ1KZUN4IE JU9lmn9gp+vz3N/Un10mZOfKzv3raWXPnHV86efmeeCPFFxEVcPVKWtWxMLWepq219OjzGJj ktr1yzr3z5KApp2nZWGXeWr5skyo3TqRweN3KsXnfuzPqDXrx5XPe7OQCnneRgWWwjNRwSYy 2EQFm9U5XWAI9reH4tM+jqLo4Wl6Wd8BAjHQbgOsvDlkfvr9+Le7yUupYbOy1Mk7ZOh+8vM4 dc31f0DvspK//fgqUOsH4nHmw5VRtK+vQG/BpwQ28aFy85Yk0lQ7dXCrPQHNgewA8lPfUQaQ uK0VeYPDfGx7DsB/HtnrMD03gy1EUahK4GlDFl1jvD2N/R8bR1MsG7UnUj43rffF35Lkdybb UhlULkaFNHi6XvgsCupvS39/dN1c2Ms8nVH7y8y7vl15dwsLJiHR33MzwptLA1bOzZUQO6MX O9Y84z+YaKex68loMzC5+FGDcojUMbdMaLlmpZbtZ+eceeaoBXreqTXy9oJDkM3bSKeQtZXW maKXswn/zMx1DcfP2nzl8iQb9SGijRojSSLbycsF0bYtfAABrBnRYhNquPZosyt7b5aV2zbw WgDITNsMhaA8gKaUvfaPEXnfT3MHf5cNxVnaZmjoKJzZv375+VfktD3hvF8e75En6ivyFzYF kkcnLie3mvn6SKlsEISI/NTMHS23daikN4jjDcTSUe3y0QD9ZUUykX043Izs6e/H26BxoSbC zJeH99O0uBdGO8G5ntLHpm3dTy+3IX/59IjPrsZYFdfC2DQizRSbV5PuOjZnHCJUA+UpMTd2 an8sGp1SY6uMpdIjeXu6mUB+NvvpNJbpOG/D2su7gNJA/g9AFWnsTHM7Df3l4QdxPRk7RSW7 zl4slDd1uZC5fmzxN8x53Wf2xyqf2EEn8mVbpQN623L48gn3JJ85LkIuL2npz3UP5+CzU5pC tisf+Uu/iqv2lhr3KNXdPOKq5Z2NKZUxUTc8EqX8jVOjsm10aKM2IW+aTve+w1oRtpi4vE9I Cl0W89RtrawQ4pzmmbery/XiXzNwsuOvc4NSAKUXGjGI0zsdl+mW2+iIwWIcHyMy8Y78iWvx dZR15W/NsCGNupY3XafKggFpni7z/wutthsEYSi6SgewxEdUop+u4AIIrZiANRRD2N5ze6lt icRfCBTO+0GIUzb8h9TtncDvNucMTdxEy0eheSzEZ6Gxe9247u4HI3RR9q5rEZbft+wPrPRK oWhRu3AKHlRaAzgc7z6NDsYpJwEb91hLHI0JklPUc7mXb1TL6GiMeQpC/AXwZs2OvTBpzSg9 CqpK3VsXgOVp5qKfA+072svjHBSx/PKVqM0AUXahGg5HxhlqJH5JmFN+JH9XGnRKFhkqMuJm HiYRqzByS/nG3ipRDEx02M82REvuLY0OczAQw0lue/QxfrN7thKNMS95o5SIui73eQ3pt5an mnq42sNFjfkiq47YJ4sS6YpCF/dl0fUJ74kiRFDBL4Z3Wzb/lQak2KejfBFSO83oD9KdknwK ZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzkg MCBSIA0vUmVzb3VyY2VzIDE3IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+ IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8 PCAvRjIgNDggMCBSIC9GMyA0NyAwIFIgL0Y0IDUwIDAgUiAvRjUgNTEgMCBSIC9GNiAzNCAw IFIgL0Y4IDM3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANPj4gDWVu ZG9iag0xOCAwIG9iag08PCAvTGVuZ3RoIDY4MDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImUV8uS27YS3esrsEkV5RrRBAgCZLxyHDu5rqSuq0a3vLCzoCRKYiKRCklZ 8c/mW3IaAElQI41zF/YQQqPRffr0A5ztZi9/euRs1844K9ksYhFTXDCdCdYUs+0sScOE6UQx mSVswSPz6wv7szT/Pf1di4iJWLKFijP3+w/L2ct3MeNsuZ1xuiRi+GOkY6VCpdnyiMt3+Ldc z3jIVcqWl1mwKrpLUVTsc3Bq6m15KBabpvxSVJ/n8+Xvs9QoShmkQ8FiHQ2K6KwgkfEyrgUJ DbcNl3wKWHsq1udD3kE1y6sNq+pqMf9t+X624DyMNRwMecKWP86ikGNJ2v0jX4qmLeuqZfWW 1eeG5afToVxjD7+F7PGYHw6srNZNkbdFS1YtX0BTIhOjqaxYty/Y5muVH8s1BNuuOa/pMFvX 56rDLxvSVkAs70h2UCE0NyrW9fEEcBrgdCm7vdGXt23Zdnm1LsgsC19Z7aBtWzdHY5xF0WgC OkbTPm/ZihDPVwdcWLN8vT43uPzwFToKGNKxy75c79kp7/Ytu5TwbWUsiggmybXBySgr/gJG XbEJ/WBlCp6zmAMACkMQX4Upisx+pOw+Vjp2YXoDPIs/z0XVHb4+jEEDUMf8KyEM7KvaBk6G IpKTwHGjJjgVVX7oygKR+bnc7QHaEBp83Q/Dw4gVuE2aahu4uiMle/DmgR2LvGKXpq52C8LH t7F9MNTKezXWmKZeGaQPdWuuf/x1yU5FY0KE0BnkeJiOjvBQ2Eh93CPiEzNr8HBf5BsK8QEo reGRY8tioiMKI4tpUGy3xZo4XBWtoa9n8AMrwb0WiHbWzwoc2Obrrm5CtvRYKLXF41B8KQ6k xDeq2zf1ebc/nYnHRMNdkx+JN92+PncjpoJP0wpHcXd+aGtWHk91AyZ3D2DaOj+3BVm2Kbqi OZYwnO3ry5hVsc0qBLSEvX6aDvisEaQVMmTV1s0K9GQfYc2gQdvS056323JdFiYBR3/Ktj0X bIVQXsoNIvw5ONQX9p8Pbz7PR4a4EIFYddMA4AkPDFmtG1UN3jTHVwYOtjd0JCVvl+DHTzPB 3iMpfmewSbALi8NUsV/Zp98itpkJVKYERQ2VT7PjTOlxdZg9UsFVoTRJRX9NpeWKe9VxkpQq DlGdEw2WQGIBggibcx/naRTGQTGPAgaLNxTBv4cyPMlBFAtsfik3QBbwtt1ijaRiVJvypmyN hM1N1Gkio+gzM9GJvQ3sn+s4TAKEZC7hYGBp4m5FCh3rpmDHsnW1yOB5qc+HDYCkEFO1whal mrnLkks6/ea0lyZDWCdKTP3bISWo7oEdftmZqyR4GDWL2JoetPW2u+TQ7iPi6bzUDbDwMpuK OSQKNEhi94NfFmBo/oep1V1LLKVUpqZS5A0rCHbjxwoW/r0u8wODTmagkwhVaKx7GvwoDVNt K+6N0EdJ3zvhk2txr1HaKfEfP7x9sz2hz/fZ+8CafFP+xbZNfcTuL68ff14IW94o2g1qiSk6 13G2at2pt2/KqssSHGuo/NWnxQp02bxi1C0NZu20cXrVeVJDnzZMk01eIIy/2viryV+ZMh2J MI4jkxDBI0TJQRJToZDoqiiVUqRkd/CdK6BCcNtQ3ManoDdtvuBKpMB+8MrEgItQgdv/ry4h nC6Lq1WFpLhjlMh8RaMe2oeiDNuCtjN7D80m5/lCxmmKGsC/my/SRAdD2BZJlMlQYiv7ztz8 8p2wY5vAJKQ4scro2W67+UKrlAewTfeybsRb9MLUdxIaUujI/uumqcVmvoiF1gEfb5D2VBYm Sa9+V0N7rDFQBATjlS2ofSkfbfnlfxAWGSfR5F+Zctw1JQyRiEMQjWfEU0MOJRDikiKiw/hK +ZUdJiuMKUAWeiMrfmWCsMLtWaA7AIxMSsjyZ8A4pukfbXlEcGKOhA5kr/meIRcUrmbOs1AF i6r984wUM7CD9Brpf9suB017oZuklPE3rEIxO5CzKjImZf/epBazEeoW4R/xb1vU1UeMv1/g AJEWnO9vUjcfFAq1LI5tLUtjN+JTcQzMpJV8zz4UzRrVPN8VQ3XxiwspN8Ms7+tWdqfQbM6F a3t+T3StwBUpaqZu9PSHETsb98Xp5bvE+jI+aXSIGS1J46FMGUXCtpsf8y43hbPF7FOZBpDS qIW2hrn2c/Dfyo19cagS+4ARke6HP/fwsPKsOh9XeMCgF0EfunfV4bWBOa6hdw0mFYymxed5 yF57rxqCa1UfNsPcz4ciH6n+JQEvaaSZzGA351VqHEYSY9T1ZGjD5xXzV/CztgEruxwWta71 03hK7Yo6LKiWSJojppwcegBYxxIqs4Ynn4K+xaGSRyILM3OhOQtGKRnb0mtKaIAXhm1uYKNy tdcVV3MKKjI9aQb0i/KVIje0wOHbWsH7m1pVAh1DW7A/yKlS3beub5hqTxniucxexFGYxfDU Sz3XLIyYQxAmJFBhkpqSfqIDTUN4m3pyEiUxglpXDsaGI5I4hjCnJmoGGFS3J9U+ln0lMY3H 16vCOOn1BgpnzaYYLYJP/aa8cpmHKBb6aZeaxxRA6lUT+kycx8B03/mkv+qm89TcUMojdFk5 uI155Dm30eOe8Vo/53X6Ta9dP7wbaB2K+75qxG56++grtc8rs/nAj+S+0fIJuJ5O22bvopFc hXmi2G3eBMF15LsoqN7RWygMzLsZ8aGDiyTV8E54bOfTFjsJe983BZIzWHidaSgOtr3P4zQo rtjqQPGS/joBrnjCp8jEFhQaB56BJHkOEvEMJHZ8kDpJ0P/TAQ8Mk7fxQBUTCNUdVJ5QYRD+ ltfJXT70c8cz3j+TFoktjujAUqL4egb14485enuGkUK63kRdP5LXQ4z6ni33TX3e7U/nDv1+ 8pQFsmz9dX1A1zbd9HqgMe2Zeq5rtXfmF/8F5bpxMB00bk8uMF3FTJoHlnlefXDPxn5oYONo cNXwF2kolIr9ccVv/Q8M7ai9Giq8QWIcDaxlqQsLOBW7sTVwM8PEdLwa3K4xzT6dEFwcGkeb T8GTCSMJhZsw3i4B63s2swMo1/TmPdqVxswLVw6zH17M8LTKsK3oh6NdaZBYuG2Cjo/H7dI/ z2GV8gVoORHAi0lLpkRmr3Br/xIR4fqUqTiyStza1yKiDGz1Rcx6IpJgPlXjRW49uQj+gbmj FrueaMFPwmBg0YIcfdu9kCt2Yb2MypJBhr6NTIQxypdJxSiDb/8OpbJxD9+TvUSNe/ie7KFU DHv4nuzFo930PcQoNSQY9/Bt9mxuxz49Ehn79JAK+yM/sEykHAnCQRkxSrj1RCQGaeLxErf2 r+E4riYiZj0R0ajJkkk58MisJxfBvNiTMEtfQKD0JWK8xq39awRSIZqImPVEJMEpDxS3nlyE xhF5qLj1RISwzLyL7HpyEX7SxsUhbvT9hIskI0ZO0PcTLpIMH7lB3/4dMhu5Qd+TvXS8n74n e2q8l74HmIX+h/Jq6W0bScJ3/4q+LOAsLEZks/nAnmZnJ7uzyCGAMpjD5EJLlEyEEgVKspN/ v1919Vuy4T3ZpapuVn31dT1Eqfz36H+X6aahsL1OJt/TOnuJVeZidyfxUPk9FhLtt5KtmPu7 7d/v/vnV90Pft9jcN64lrsDigdJC7QY9aWH2zd8/f6Hlcj+hxZhO8vBq0+G2ZXfLWt+FnfeC LvLYixEbBHWvLao62uIDflt3F90BMMnN/fo8/lzYG/uN3SmzUuqOGrdN+rp2ahy+91TpJ0Fb Sn/udYsSuHd7Gd0dRZ5f30H9Ef6s4Rf+w4IzXWYIukOLYzefB3JlfhDb/rx+8nexO49oyi/D Bt+i7ry9HPSt3Sguh+EshtPpgpaeia88AsC7w7nD5/01stD3UI8K3CKU7ahADvbd+klMW93K aMMb1hpu7uf6oopaHi76BOvTtO8pJm7h1LAHbsGYMjQuNnXudC5NnsLOPRw2+juHHd+46Xdz 35Mb3SOwOnIj1075eJZXF7len4nfIcB6Bns0OmKcXvrZc2Daeo9qBrjbbAYD6VM3bzThbJII zi2wOOO+/XQ6i8NEpPopPuf2Hn3HGuiBKMhGz4hhYgxJKitttrI+P8e5sP6DEnOvWUlEO51h udaDR3JdUXMqHufugLQd5x446pu69foyd+ufmPKILrcTHs2nLobztOsJumi0lXi4ZizGzFnz yCn6H8cRJNNkQR76zeVIdAYxxm79nX6e+2kLH4YRs9l51u+MRqIF3xc+X/NexKdhdwHyZSb+ fOppJgSLtt36PM0ngRSa2fCb5vFhOizGaTouXDKVAaQ7Abvt9vyAB/ugIfj8x7cPD95LO96G BNX1pEQ1Z3Cr8opg2gFwE4GccDdg3xFpL0fKU1H8TefcDrsqbzLUgaLE+lBz1aP79MIRjPRF oa3QfYyV/TIA/n0rpkPPkNH0VOUhZsuKUWN4xEunaU71U0+j+2nTE+Rh1OT/fjgM+84XK4lm R9fgHADtfwync384G4hXX377dXvETBUWA4p8M/wgXN0tS8Vw6e1rwZtnT+P8hr2xI/0/xG7C I+KdV2dGL3se/trAj95J97kLbj10VLwQ8RL9vwWfW+nhVjHcJWZRMmlagzV/Blj/aRjRD8Rb w7kHxj6nCaeMXjIT7VZrEk/9eOx1XLQM4Gn2TEGqr2EJs6Ww21Ol6U7UJFCtHvtDj6Z14gqG 1rN+Gs5oV3gWJ7FYkMnTsAluYaCoXhzWA2zoW/0P+KMLyFPgXFxvTmYZwoJS0IJS1rTs5GVF Q+H+ThaNF8e7FfX2Kis1kvSXm3oOqyakd5QRSS0fNsqRe9m67gHXTnGXAenI+Q4t8MUUcNER bceRXi/+DScDYd7tAk1Jr4W2lhTSVCiU+s0D97LNc4eOuNNdBVAe6N2iCxR5pu63Ufp2wH/u RlAO3QLt6CT65/6giQDA8bFlznX3L2A+f8DCpe53vPLV95n4xfcR6yc65POwMRMEOj0u78fh tGda6DIJbvBDXV8W9lP40rKpbXKvkve+mUSkM0jUsG7MI5mhhB7zqOhgB0MlayrUKEkT46Jo ykxJGvgwDUog2EiYYDpvYIInXJAJcG3MTJhrctFGQytTQcMk2KWwHDh5tHK9XJLZtX7Fo6Xi frQUtVjUoJissFvm2DVRZNtlbofLe2LVxfTMvILFAvcopYvL/dPPzTwV+gmBLViUWIsNjrTn aQ86PnP7Xi6t1pzd72Z+fCCCWiZHT5dizQjTxI8fI+XLsDfYygowvYEFq7maeTXLTl3hUQVa LTplXcdXs+zUTZO1MlCzbNVpEoxM6uLtJBr9bdd0Cl1lKPVWgc0BRQRZuwfbuQsUWZtXDBk+ a+h6n1s1CEh3SDRM1JIq14HRBSvucro5pKvCx08VE6fVn2+FbIqswgazbInKdLzDnGK7nUsT h/MaWis9uPwbTv1X6EEdKx4h2FYWkiLD2E0VtLbPBYmoy1hNzcWqW0n+eHVOp6vKqEu4i59e u7xEnc3jw5I6ldGWS3q+0WEkpjXqJQLJdSC8q8aBIPiqzIomzDXLAKO0rCT7VHb2UeS4r6EJ JtAbualoHvL2qezsI6hwX6sIx0DPsqO2sU9lax9ju78rc5SUUG9kG5+1T2VnHyYD1xU1hptQ zXKDFBTePBGddZQ73EavJ1RrsakJcW+dyr6WYmxAlbzF3jDJTKEaVoadUcosgwrlyBtm4Jqd EaCW2wF5Q4DsywjYG0ScOnbN3TAM4m4V1K3RyU1LQ1jA5UROuem5Cw8iPcsAXBUhlxM55abn LlaFSM+ye0uey5GcctNzV7eKQM+y42rK5ZTrUS6IvCh8kZ5lz9aUzAnZw+QRe1WmIjXLFn5L 51gM2Vu/wt4wzdR6owoXZ62gQzF9wyRYtTsdY8qXR/QNIeLTZVa7yh2FbNVSvkrgKm60VRMX NyPbF+4IncgpQT2BS8pUoGfZEzYldEL4CCtkFBNCyDcWnTeWzomc0tPTF8C2oZ5lT9eUzgnd o1zgPkylbR3ojQx/ljKkcyKn/PT8RStSoZ5ltKoqpHMshvxtXyNwE1fQPCFwmLUrdZSEq+oc g3pdfiOMrot3FPLV3HLN3yYucDXG8AAxK3u+pnxO+B5FTvytqIsHepbdec/nSE4I6ulbkOOB mmVLf8/nUEzp6emLVSdUa9GTNSVzQvYoEUTeknawQM+yO2/JnMgpOd19Cr0o1BvZzlkBmSM5 pO8Vb6P0UrplVtbX6bbyU5LAeBiNs2FpzkSOsI1ZGgMVv444aNbZ8ru6Zu//GU4cDLGzJXcD PcuejSlbYzbHABA9FRWmQM+y52NK14TOIWjUzTEOhmoje0YmhI3pHMFM/KQyF6i16EZPy9ZE Ttnn2Rk3GivbWurJWl2d1ty8WVfLRi9RFFIO3LBgikVNfnD1wlr68ZPiBdHup2WLZkCg5Fmd 6wUxF+enue82ZjlMSeO+saTKtU++CV9p36hvyNp+TM6/NaTHlreiSYOoy6wsKAiC5754XyAg vVJhINbR1HEjs/2YnH9rXost3xNIhZm/dIGU7wsEs1BRBYE4R1PHjcz2Y3L+zcYdm74nEtVm jXKRVO+LRDXkwP7KsyvPjcz2Y3L+dg2PbeIQVjcjKDJVLfltNO/0H2tGE/jv/Ev9tbK2H5Pz 3v9SVRnPgSifqLsAtW6tPJrKrlDpq1oo9EW4TbP0ksqkkUcn07pR3tDr4JeiBhyIX1YtFQSV t1QdKfbPf1DUcKiCy4sCcwb+fv3X3f1uYkVRN5VWSKPYbs+skW10YBzo50WeFUXBGllKrTn2 86h1qIYSm2l4at8030/DntR0Eu8j/NZLd+7nhf5cdMr/ju8pZVy3p9bT/jj3pxPpC0SGiMPD c7cZfphcy6qggvYGvKxHjda5t3qWvV6hH6tAz7LXg9sgm9ez7PV1TVn2epa9Pk0vy6SXNEa8 4T/rX/MvehsSnFBFQ92eqIHuxMgXeE4VpxKn/W9K/5RbMySWbpISL6wFx2TGz2t17PvN5Sim 534Wp2O/vozdeZgOdOrjp4o7V6t9aIVsVFY3QuGZgnd0/PHbB7H68vmX1X8K0R02+P+3X1sl hsPZ5ZBjfA3DmzNfRYSwOBVZQ5WBqobdVXJqzV4drxuyxftRr54uc8wL0WF0eulWGcwYeARe XetJr7FqpKaWgVqUGk+jRbnHYBsdhn1l1S2eQ5UcVvZqtWxp0wwPh45R6mUbHUbhUq8uSSGC hDoWxZB4WkSb1cXMWqeyM48ApyFUEqqBnmXkFOuGt09lZx9liHckKb3eys4fY5/Kzj5MKQ+h dR6ojQwvZO3NE9FZRwygIbSliTzQs1xXWR2YJ6KzjghDQyhSHoZq5LoxK5GxT2VnH1EM99Uq a8PvGbn+H+HlstzGDUTRPb8CS8pVGnPeM1m6Ei+yFXdxFrQ0oumiSYYPK/n7dANooG8PXSot pKvGYwDcPmj4RM3trU7twZM03kjs6XQ8aPqeTjU3Ulqjh38s2jIkWIpHLVsv7a1O7cH0NB79 UaqzEi0wkfZW5/v2V4UvJAhnV1vlrEe/+9wb+K+Y1uBe37fOmYlmtEmP5pqhDN0SwvxiEtzo s593hqMMYcVBPBsB4VBLGLY69FaomwNH7R/zhjZe88ZL2sZe0QeUZUlmTccHoeJB92OxajR7 jLYsyaxpVU2xT3pogmUSe4y2MMmwoXoSYBO0ZEhsbqSFSRqtKfkxm+NRC0kTfIy2OEnj0W1b q4QSTbvVAn6MtjjJuBm4DFbxoNP3CH6MtjjJuOnZsCoetJBe2lttgZKB08LNJZoAM7QIINAW KBk4mkZ+5yKYE3qM1qi5/6CD3AjTA2u03yXlx1RigH1D7zYTAcw4y2l01xwYYBaZOnMOzj6E dWkER3kHNy3WdFjdwLzvkEZtH/GhL+FCE53oguRBLMFeM2uorhh1PGhyX3gPxPZWW5Zk1vRw nYmmbi2wx2jLksyaTr0n9kmLm6W91ZYmmTZUXOjsizplr6WPpRMYhmlTI42iFjYr+oC2NEnj 0UL0dEFKpSXoQWlJkkkzGhIFncliyYNkQv8yaYaiAdIEnUqZTB7QAJOMma4YdMzLjJbGCA2Z 8ReUgby4gxlt9Vm2onNp90pKvztOFv31gzGnT/CmaBNbwGqzhxMYZxbVNvBBwM6IRZChjj4l YVaVsaP2nY9hLLpydg5qkTMYwS4zjepi1C+nqIU/Bk6WXXAoNNpYAa6CTK+gTCfQ98/o/TPE A2TaUG0BtAl6oPtm1PQx2tIk06ZnP6h40OmpI/Qx2tIk04ZqC6BN0Km/0Mdog5MMm6bQuxGk 0AXRY7gEFiQbUcnY63SOOqPFogfRhKal8aqyqJQPRNPXVL1qb/VdG7/r8qe7MNG2hicOeJQi Pedf42sGNFxAUBdzE81V+ZK9ZPtwDIwCrx48c98tkQIOEIsbPJHQTb4SdxerHtyqsLouLvzp Dgz0LjEMOo4oGAQtT4sEB6NNvmcatHAjiSYbNQ3gQctkUjgMpgHVBjoboh76aMrY3mpLgzQe pL7nQsWXu+KG0ZYDaSQuDPVNHXV6owg3jLYcyJwYuARW8aAzFyw3DFe0r5gTfVHpoirqVCRF cKC0LMisoLtMP2iillNU7ABtWZBZ0XBtpeJBS8mV2GF0hoF2PI3XVEWj54ualuc9K+2ttjRp G2/y2I7MTKVfW+V+T4tP68XHz60r3fqVMqt3j71bOd7ckZHi93j9gyLbxfJw+ee2OU8vD+vv C4IGXaPukZKzaWq3/n2xvJw2191mz9E/1pSh20Vd0TQNDUOtS1dRWVzX7pEeTuFp9PohzN6F 2cuV4x/6Jf04QxuZnhbUknhbLD/vtrfz5Jrf3NNpml5up4s7vrrN6bTfPdMnHA8XN/07Pd+u u8OWv2blHunC52/ksq30Y7ztrt+Ot6u7HF+vb7QodzlRj73v7o4/p7PjFtx7TeVHseo73023 +pLVz0lmpP8///e8ny7uozscc/921t12+PJQcPN0GIPfDQZtVzRcP5VxM5afNueLu37bXB1/ +PY8ba7Tmfs+0g3Ujl3N661WfeuXzBP/taTmB0fmcLvDC+/SFAY4HGHhu4v7Ol15tLZdFg9/ r//ko/x/AMouzg0KZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PCANL1R5cGUgL1BhZ2Ug DS9QYXJlbnQgMzkgMCBSIA0vUmVzb3VyY2VzIDIwIDAgUiANL0NvbnRlbnRzIDIxIDAgUiAN L01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Um90YXRlIDAgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIA0vRm9udCA8PCAvRjIgNDggMCBSIC9GMyA0NyAwIFIgL0Y0IDUwIDAgUiAvRjUgNTEg MCBSIC9GNiAzNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1l bmRvYmoNMjEgMCBvYmoNPDwgL0xlbmd0aCAxMjg1OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiXRXTXPjNhK961f00Z6SOPyQKHlzym4yqcnu1KZqVJWD7QNEQiLGJKEF SGuU/7nXzV/JawAiKVt7sGYsk41G9+v3Xid0mH385WtCBztLSNEsppjyJKX1Q0pGzvaz1SZa 0XqV0/JhRYskdt9+8F8v3cf779dpTGm2pEWePYTv/76dffyUUULb/SzhQ2LCP/7pJIuyjLYN Dj/gZ1vwx2l2p7tKmpOyklRZS9r3bdEp3Yqa+lZ1Nrrffpsl0QanR8mKtj/N4miTL92r20rS TnedbqhWLQJY6irRzelUKYSqtT4udsLKkmMs3gR5WGUuiDgea1UIPtOSrXRfl7STVOjmiCAl nVRXkdX77iSM5EDbD3g7ReX4bXuURV/j7VdJ8jv+z3Hm1Op2wcfT7eiXMC7E5ST+8uOnpa/e MspWS5QPqd5xBrrv/N9DdbMojhP/9zjKNi6ZxztSXUQ/adUekDFJxaUl1RyNfpWWvn7Z3j9v f50t1gi+mtbCVwKPHYxo6CjNXptGtIUkbagRqu3wYxHdUtEbI9uOavkqa1osOKuYYy2T3AXz oSYh0JUWDxuqetO5dm4cMjaU5MsoTilfrqJ8zdC4y/0l0wCh1EMo9RDKU7Q+w7Xx5OPd+h54 jOO7f3GZOwUAHNztbgBwnfPbcRpOQfdC7z+3uGCJ1Dp9KRMVomBYyUq8Km3mDkW4tmhD397i KEk9GDuHFgTqxIskUb4KVO2ACu6pFJ3AhPRWRoQjuwolsbLwUDmNoMqylQslv4uG8dyddLgZ imh7af/Gv0qy6g98yNqHINHi3OoaVKWynVE7B0dOgd+zLrvKSFHeHKskXvuq7Dnc5CikW1Ta ypbhbPTRKNHJ+jx3jxlZ9i6Pm8VZ+0IrvAoIcD0a2WhzJlEU0iIj1eArbSRPbuumTrYW4e0A rCT3wIripZ85IOuSIJcGTTMV7kSAaGd8LpYe0/j5MUmeH/PniJ4cVRS6lGPUkOFyOWT4SR16 gyrlO1fSvCBV1z1icjruRKt7U7iWcg8nfXvwVBYyebqP6N/cFx65OVX6xPifXxJuxJkZBg0Z QzwsNy7ETrZyrwol6gj5GAsyQ4z/WpJtxdNUEshGtsV5UamSIT8QUuZhWIij2OGcTiFnPgnT 6hDuz+7bVnLhhTlH9FUWui3nU/BEywcPAlGWKvDwBYLT8nJk1RbAkp0Q31iRZRKGopFzOoAd 23CPSh2YlJ7umr7ulEejRMUYmLo/VMfec4S/lC+Kax/OEQ4maIMAaPai6LTxjI9U9nUvmW1O lXSs1+mrebgQOF0IW0ZP97dmYOMT32qMcGkcRN3ZfgB5XCmMZ+kmROyC0tyCf574prTSgjqd kpRqv5eOQa8HoaiEwY2kweCqws7HGqSBE1yNGe8XZBFmkd/VJiInhQ47OMjP+xQdWewTeUXf uUStryMPt/bT7mnPTbpoD7IEOhpR19JMJO+CMDxpgav/9IoL6h/zDOOkt6ioFV1v8D2DpDMa DDGRzpW/kZv6CaiGQXbDwzk5a0DIBxi1b7KJ881Au5ZEDb07+oPQjRNee8M3fmx4KBYLUpGM xgoPvCL5PYzEHpKN/qDl/nGrXTph8jzjcSdCwVHCIVaSZJe0PG3joQ5djeh3h10j93xt9EEF ALkuOGpuMEz9xGPESy8HfPaVoDZHIIUbB1XhZo0Nn9Tw94mu5MHqcJWsahz+SycvoTqVQrFM USmfyUH0B3lFC0nIBe2UjFPuF252koCShw5fY35d7bOXJlxyQi++bfy0R20tzAFlDy9y9ZmG nWNCpY8YQQwLOjyEWKXJxa7s3PTxKITXbb+zZ9vJhvbOueBGmD2gbEwgebi8HXTLi9p31ThR o4zOUhh+xzV93wPJEnxl5aQamS/o16DAS2b87YDY60uw2HvwojyQoKvBHGCsS3EGPb7vx9wV EUFKadWh9R6DrYoq5aQqSb4ap2oi0+SyGHrlrIiVnQs6adwYJ81CHJ9p8D+Ou3yr5n58vGqD vmvHWPMhtJ0wRhoALLiYmmkUY94bnpyiaoR5sZA5L+dORwBzKAb6Pb9ib4lEg3Ohk7BBUPi0 o2B19oP0dDdxBS2mBV25QfHBr3m1pxUNEHs7Z4inO+jflby9pfhVIMVz4ejv/7sc38fy3EI8 irHcgQynPFjoHvLAAL6e7wtVBL8X2jGGiv1c3Jok6CvTRUubRSgjD81wsSsG2zyMNZ+sLx4x 8GeCPRJYDzBEB1DrWl6Cmt7V6Oct+vbLLKVf4b+/URytUzpRhr2NvtDjc0zlLE0SePIkyzFL 1Mzy9fhbPfvKi2QeLZ1/53+d/U+STbTxBt4luLraJXKsl3hkNXj8OFn5pejnVyd3bC447Qr4 AdPTn1o4OT1iXercxfrO72kQMWDK3KdYwu4W9ohvgYIK9xN+f4KwMwRSBwH8FqeZN01sbujz b/+gsLINboPr93SHNSQQRZABJ8KTDXJqsSYNSTxGeNWtITnFi/QAYDJm7uxbqL7H19jSWylg dq7myo0wqOJ/HRNpFHqX0GGWJQ8o+TqNiY3lIofDNXK2/8CdGRcr/9QySZGkb8yB5WYVXNtI rFzoCdrc7PaYNVsIoJgek+w5VOadQY+DQQfq4BiZl0tGpPTGb9RZHAUtdoKgR+/9Df6dhlvf of941M1YC1gEgzv4KLDRl++NM7eg+4YhDqMuRvWIhw2tkEe/v2ECioF1dgaf2HeHdZLJbE7Y w8gfPYmVpuvrWP5GFuuC9VaBX0AoOMOGiZOH8cynXAlzHnYPhGjUH67PEf1m9MGIxtIt24g4 ULiJQ4YqB4Q5CGIBUw6OnR5p5wdCbqJuNNezrid8NAFqPl1fS7e6OL52XUG0ijXrnSEDUOzE 9KwDIfo2l7Q7eyHGC/Tjlx+3VPTmVdqne2c2OQvkUuMMNHB3ZXpDs95Zo3EAOUEUmVcx6OuR VyWQwWSRWYa1yjI3FLj5QRsMVuNsUilBE3xVctUX06owfw9R1utgWYRBlJ4hH1w0z+xJmxdO kLUzos8OnFg6sftNcOdV5jZq3WLkZrlWL+xhuNRQIkzZkNBElD1gLPwAs4PuInIU6SQejLHQ +4U2vDMOE+uNi3m/3405gH7gEiQ3gu04CtN6TgsKUSo5Zjx6ubBTOK/TwU1BkhGqFsULCGK/ VwAIGnK989Kw4P4wBNqMFbJYTPBSfXaL7XlYVFyBgM2ie1+VsNjUF6ZE+4xu/GIEZcDj5paV SMKp20s8N+LssluNMblyExewCNyHS33TTGQPg+N3mBSHA++gXMd3DvdpoEQcNrb3AljQSMsz EgbJ88bImLq9gB822pFkYbS1QQKW65QVdx3kOUs346839NnrQLK6Fuj8SqAzllM8c1Fo1s14 44f9n1IemeFQntJnyWp7GsURNHDRM3iMBfspFpCjNl2wfcDWwpX0SpxxxnrtWeAv0qtlt47j iO71FbOkgGg0Pf0ceWUgcIAACRDYQBZa0Ze0JORSlHlFyM5/Zuv8Sk69umv4uFxkRZ57urpr uqtOVf1Bn00XQqvvrrXi0gj3B89SENp9tYZcnO5P/kd0Ud9u749XDye09xecbT9Tg00tAHqH XC6ksyUx/HKk7u8rLkH6pJM1GGgvPp9+vUf6QubA/AuCjVTkLkNeU2/o/QVnJ5VqyqU77n+d Z99NeG6Y3r1OCKmLP9EH/i7PDDnA5/wNgfLpv7ff/gPP0NWcxhEx6AWpxP2MlvNAR10jbvgq qNs+PbwfFPAjPvXrdH31AV/H7rlpZNM9v1xfX91/oftFlM/T38lHPAAFt7zEBzzAHdQMiXs4 3p8490TQP94er95NaHo+6rYUMUE7rQ+3t1dPuEpyerz9Nt3Q51pXSg0ZKeRn+IKLpsb6dPvL 12/4zef/+wv/fVz6OTZcD/xkPX1d45wvZr5RpM6vr+KCGA9TRVKgxK8JWVOnN9DduUbqov45 fZYe68l1kbqpqt1WXAqKB5a0OSQswUkrbZXmNdCSH1/9Q9u1dS5pSi2glqNlixT/b5Bryzr6 trc/lAmy/cuugRO7muYWRwcXtiA3YkPSu+mn16FdiHSY7PCbj0FEFYrvQTo4kiLKwaLVYmgX vdNueDu9lcdiyXj7QxZHTTsyvj/HKaHJx+dxe489RXu/p2ZEGqI3a8YVl8iHl7KqAsQi3c1H lO5/o7Qi2i5/u5aq2SvBPH0/AMXrgu+5/MxxL5L53Wh36PO0AkQLSHiPnJ541l1471s0Blc0 zp5kxJp0PEW6YOvTPWU9tXV3d5e/j8qaVRORI9Q8nrhdmShtEITO85vrr3efDtxnQDQuj/eq 8ezru31g69Q5PZoykYP7EXeSQZYfCM3W60ozEN4+hBHhAXMdIq7MuNdSwlwKlYi2zlsxfDRc F0RWJizrH+Kx3vA6t0D7PeI3dB2eV2z8irTx9oY7n+bN0wI7W+fSPK3Y+IiX8eaGOx8paR2v uPN5hiQ6XnHnG4mD4xUbD1lP3t5w56EI3t5w5yu00/OKOw9x8t9n2PiMfsDbG+58RmPpecWd b6jEnldsfFkoLAZvuPNQvuJ5xZ0v++gw3PltHx2Gja9hFx0KO5v2sWm483X2hyvsmUCjkaMN 7zPF8Q8y6aXMeCk2X4qNF96Guz3p9ajTy/zw6CLqSkr8/mJ5/WZtraAGZvxXVvov0I8xZfo3 87/tYl1MQM7f9o8kq9Nf8J3diafkAGSlacaRgo1s8xY9yVjJVtGvDo6hUluhUjs4wUKqet08 VjO8WW7O3SfUkPjusfLdY+PNaePNaeXNb6XNb2W760p314Uf3j/S5jrHdvaymT9z38I/f+XM P3vrzJ65eOLP3v0LhWg9f/Pr+Ytfz937ev7a1+dv/UfpyVZpdUaCwYg+B0nMCYb8krEmT6ho hdoOSi+p75RU3I+ASjLyXMTxk6xO4wcehvBTXnZ9VuXD60RlpdBVY5zjIe3i5rcbHQkXSsnx /auXYcKbk/GOtYy0RiPuKEMda5lrG/k6pGxbqTEeZZn63TqKODrp5JUR4hMlkrhNVkyRkufg aV3O6u3iEHrXNNBKdGHK7XlpKGWeJehYDQXIHrpcdY0aiChBba6q55W+19qPugSqBMSiHcAk sCy0p1g3Wt7mOGiBndXVROP6NrulG/YlFH9reotQgeSam00ca3Mh4zynVY0LyWCkAul4xo7n 9fRkQXxbzfU2t+ae0J50IZ9HdYJzMal94u2r+L7JvQW9N6WDXavSvJwCaqFJRwOIdq+cPSOg NMBQkaPrq8Qb4hGgiXEMal81JILjBQ9e1tP5PJhoQFNtzTShPA74ordreKNLEvtF/GX3EieT J2r/eZNYyIGOdic2emV3oqZcP1GxnZjx6e5A3EezM5WqntBTUatjT3TqEfB7fCLxM+nB6N9g vnCUQI1bYS9TUvsmmSpSabxJqfG8nvhMOTrOhz+LFxoTon6+4n5+IkUb58M+Z3++8na+8XY+ NCM1J3wtEKF49HCNn98VCpQRsY/zJufHqvabnL8UzzN2PK8Hj3TLeEW8SuNXxUG1Y7KHDK2e T9zDDV7XI/w2Z48Xz1LJCp+HYNmq2pfE60v1PGPH83ryr3JU9vORoPSe/Xzz385X3M9HzazJ nQ95QML28/e1snC5KlOEIC6yCrdO5erPzw26+GW6+XQ84oeTFrR+pn2TnWnfJOUhU/lwfXfG 1QXXtz/EBQK4KzcP8FgvE6zbX7HxMsEO3nDnqYY4WmBnWeQdrTjvSu3gDXeeJ1jHK+48T7CO V5x3yut4xcbLBDt4w53nKcXxijvPSup4xZ1n3XO8YuNlgh284c7zBOt4xZ3nKcnxio0XBRy8 4c6zQjlecefLPjoMd37bR4dh43moGrTCzqZ9bBvuPI2wjhbYI50n2EEbfpgZnX+QKS9l1kux +VJsvPA2qib5YeedJQIWaiH+r9H2uWv3o63++MTXE0kNjhu1FOuIuqzazajCCFYyBKqUgxRs JJIgeJKxkiJUN4+FS8bH4fATwkd891n57rOOp91tFcrutvLdc+W758ab88ab88p3/x8JMQ+Q 5y6cm8oz18r8s5fHc97Z61nPf/36/MednRIz2ob2cEpMPDg+MSU+Hvdi4l4e0r7IuNemrx/v ri+vTo+HPnrOkp1SAa+rU7qOVWmBc3BKDRx9ZaDwWF22o/xKh6qVCi1CbKPObSRBR58QuUlK TX+d+Gd2KtM8IONZXYP9QHBJfEaqDkbqmg6vOkYgFaHFONCX9L0ZHSQetm3QPD8OY4V9b8V2 tBmrY97vg3ws4U0bJeDArvAPNPolchShjXa/w0pXe3jVMZr/hWgzzjS69r0ZHXisrOoK04V6 3GGssO+t2I42Y3XM+32QR2TjYCNpLcF+ILjIUegEB8zkvRxlV9aEFuNIOWFbMzjwwJniNlip g91WYd9asZ1sxuqX8/ogkVl4cbbhNPN98g886ibeu+peTWKsJXWsSZA19USM0UjBT9ub0YEH 3bBtgw6UDd3YoO1tWI/uxuLYzu+DZJw8vEwnmGI3jQv8QHAVxyu9rMFIRodXHa9zW4QW45Wa 7743I1qNz2RXhE6opm0YG7S9DdvRZqyOeb8PoiRy4UGm1zKvS7AfuCjL06NbGxA5wcYKobuJ WLMNpIF9a0ZyVKvboJukqRk3k0DZWqEdbLbqlvf6wPrYnFLBeCtDqQBXJxcGTU0Mq9h0Y5Ei 3dqECuNViUOocqDS0G0N2taG9eRurH45rw8i+vJRi7W3iz4F/sS82V5rzANGcp6O2syTSHt3 40DjYN+bEZ1Fb7ANepXoNuPVEkn2NqxHd2NxbOf3gYtZ8Z+xqtTo6tWESPZaTdr7Uar85kkt 7jNk6/4VSaVG2SxCZLYK+9bZZExONmP1y3l9kAotIher9hBLC/ZDbGGW9M6kFYqwA8euwhU1 l0izRN8apr4xI1qMvM3boJOUGzNW2LdWbAebsXrlnT6gkAcu5NY9VSz2c1GhPNzNVYLHnJfX /VwoeDeH9m6iQ+sFG8X1kTsBst7mTZroNodkeDe5yO5++ZHrL3eajTJeyl4KhsfhSXqX/fIj Lw/Fm6NYbZ6XzmjY+/VHqTj++MjPNHibo7q9X38UpV+dPalz9rzepdnv1h9ZYtNmlynSlqO7 XHubpIPBbv1RxK06e1Kk4Hl9627v1x9FVuS8pMkci0IXOXiD9HD1UZI5O+PMud1ZDUMz9quP kkUSJ0kyMHGzJPg4ohqNzfpoPTCygFKjJrpQss/8pYJHl4ufsWvN8xb1lIZypD8QpDEXKOQ8 IPbQbGQIhUnCiu1KLtjODGgxWq7s2MoP2W0V2s4K7VyzVa+czwf+UqjD+AaoA4mHrYZ4UMja Xgb1JIPqR7cVL21r+wjqfzZHV1KaYazQtlZoB5utuuW9PjyYygrPUwWrGvU8dF7beJ766fbr 5XH6H+tV0xrJzYTv/hVztANrWmqpWzoaAoGF3HzL5mA6Q2KY2YW1E7L/PvX1lGrGu21eeE8z Tz8qqVSqz+O/x+3v1+cvnw/bt+10fDk8fz6cn08n+oJBS3OfecHSWH54geLTeMKJk9BZDZ+B T2O99K/X622WvFaWFpNjs7IP/xy/Pv15PJyP5y9fvx2etu348nJ4fT4fWWFT/dPtw68Pj5/u TG9+kbYEldiMKaiEK0Gli/UjoU6FE+V5YHqkJQTONaburSxB/hr7+kRBXuL+hsHnLHXWeWDn JWMPWqGzmpAHbRi8JVzngZ2f2SyBN+w8+VuNvGHnNSEP3jD4QmkmygM7z+1F5A07rwl78Iad 14Q8eMPgK7WaUR7YeWonozyw800cePCGwVtKdx7Yec3agzfs/HLpHcDO90vvAAa/pgvvMOhs ufRtYOfX+3i4Qff06T5F3wK+jgznryLlvch6zzff84133sZSZNUUWSTrlAM3TOQBhZIPDQCU dX67ne4+5MYN1W2lf0vmf4k/ysR2m6r8bbd5uvv98aMknV2zU62knuwXurBr853bM5mS5Vkj FRuZp/taAqkYZOc4DWS39MYkdUUtB1KxkZqozm8TFz1fbUHh7yQ+5l1n411n411t411t8NAc PDQ33pU33pU33vV/k4hX6WV3DC78jlmF/6Hx6Ly8b568f/v848tdlvPhq1na2ynxoMIVcuKq 94H2PBRx359v2FPp2+NPN+yf9M89fpVdqO2YyUK0C/WyZGjeJR1e//p6fPrDSujEvgp9Ufkt UVEwUD4fiY5wziHxUjlqsbMmvKZQGGjAyGsI9izbjsJF66dQ5nK1xh7GT5zuRvtJn1mrOfOp Z5l+1pzwgSHNAYymNUDZZLtxTOG5KC3C5IGkGvZWtKk/9D7oJu24Cxv0vQ3jaBOGYlHvTW/L Z608AGhVT6KKfOCxjJtzzkTcCgJSCyjCBimZcxvpstTYrAffWhCv5pasD3qRucCFDWJrgzgY sqZW1HrTNxTZdbVZc10SPjCc9KTea4T0BnqU4Jl+lFbhzO0bthawyZxYxH2M1SrosgZ9a8d6 MoRNr6D1po6pOHcbeWtO+CATqhq7pjqguLEqJjjfL5NqosKUFMlg2FsQn0XeIvY0mn7aEAbE 3sB2tAurYhd6bxpwiicJDUot3e4hm680dMhmeQ1w5jSy3TjmgVXpbveofJbtLYhX0zXtHkyX 6T63IQyIvYFxNIRNsaj3polEfb/Ie1B+z5JZ5IOU5KzPx0YBLLwJSxsmZ+fNXXjmUcP3FqRn tbUPumkGgLBB39swjoawKRb13iRBaiQt2rw0ip2EDwyzxl2b64CFX1yPMhP2rLQKU3fOULcW QIsrjTKWW5mlPD/nIQuIrYHtZBc2vYLWm2b9IhHfZ2tvpynhw1y77rXqyAq46EALWHXcdVnq mtaDby2Ij0r3i1UUobO7twgbtK0B7WCXVbUutN6klmlpsx46W6qRDwwlEVFamOuAC9cnPWrS l1qz0ipceBDC1gJ4cbFUY2zVRARZg761YZwMYdMraL1pgc5Sfyrap6klfJhb4t49c1WujiQ5 saxCclhOl5Bk66UDNlbEi+f7tfZBF602EDboWxvGwSYMraLSG5XxJGUcrSNVrjlORWS1Fqcq cuE4ZALGuWG0ElPl3byVIKidB3rr5b5pH0jrCDZOXWcp3KkAh+WVP18tP0nxlS4TFa8kAePY 2Rq+sfAkCxNfUHTQIpM6cLgCVfY3y09aZZrgJM0llYKegINFMu9yvf6k2T2LSRaxN2fkChwM nK0Vv1h/kqxaepQna8yR1+bP5S/WnzSdrUGec1CKvDaTQz6uP2kmmYO8hb/z8BfIX6w/aQxX sceqGaBKTCs+Df9DL3+x/qTxU8QntO1kp2/Ap+HPWZ/vYjnhXtl5SiePEGnuqgyO1pa+NvqI 8k1HNEp89oEheVLpVkMBUWKBrQK7sNZn2xrVm0bdtQZ25cccsgZ9a8M4GcKmV9B6k5suJdyC pJY2VtOm5Le+FyCOAjZNXFj1xN64RqcmtQeautJgAkDf2zCOhrApFvXersaxRQaphVY1bhP4 wK6D1OOX16fT4fjvcfv79fnL58P2bTsdXw7Pnw/n59OJvrzYiKVpz/yALNrX4AiKT/6KjaJB 6JV7GYWnsXrhTu1qtU2Q15rSWroWa/rwz/Hr05/Hw/l4/vL12+Fp244vL4fX5/ORtTW9P90+ /Prw+OnOlOb3oPzj+rAJ09AHt4E+cTXDzsG3cGnmlFco5ihmDZ+A1wkDpK6/xr7eMY1QEsNX fJlW7qmddwye8voUeWDw3J5GHhg8zW6U0wYPDJ5y6hJ5YOcpJ1/whsFXyqGRB7601+Cv7Pmu fd67/7v329ffQqZqyBRxxCKOSD68VMoamR2RGm069XG7+e12uvuQOfHepruZPt5O2X7vUr2d 7X/Bt98fP7JPvmcGyqZUrn+h55+4JLn7vXUX5dfJxj7jFQe+WecLXvDgOUYDLXCwHQXb6G4F 2Xhz9vMb5y+LdEI7waM8tAfv2oM37Z2H9sab9qChvbHQHrRrr7xrfx3KfLu57dt+bvu2n9u+ 7ee2Z/u57dt+bvu2X9K+7Ze0b/sl7dt+SXu2X9K+7Zf0Y9tfVq4RhpUbvoX6pFnCcOIQpKii RP+BevND5n7z8eeb2yTfHn+6uc3yb2KqkCyT8/ikq8v4sK66psonTwSraEBlKlOLtpKenScB rkhPfzxbnZk4Xkm1wlZbtHMolVpS9oHK3fhIr8RXTVedqx/zMjIgXa08IHI2J3PShVcqWWJW GsFoEBniqTPBvJo1rfy6/EjyiO5y0hCw0yQeLgyz07SAw3ppN4LLLnwLdTrD2cRteY8sw8Da XUjX5Lpp5k516Oq6y93OjhvlGJVvynfuSlVesN+9BRx4Wc+2k+468GvAwZaVX/A8cNPpheXn GvVvWK9PB15w4HE/esuSw/2oMpf4lnjbwgX/PLDLL4pX7f5ZXnDV+dF56A9+1e6/0LA2uS+d Zf104Vvma+Kq54E7DxnMN8XtHuIC4altwMA2TQdzGRRNeT24ODyerLGGgk1qaZ6ZZ2BVm4ZG wXBp8ObSzuNaFHF1Dc9CQ2FdYsRZBBYems4Dw2wkb1jdhoZMW9/myOPZwMOtSr6Pr07bp5gA kBAgDoxXL+l+DY9O4ksPj2403hw0lF8km483pW4sx3SE9KQR6xC2qzLQWviruPDyVoHH24FH uqBi06+y4cCnkS0Lz7nngdchbzhrM9mxvke6mPY9rPZkVqmzn0MrWWkASaEVvcZLbnp7JL8r PNZra+77OwavrenggcFraz54YPAaCYMHBq+uMnhg56W1Dbxh8NqaDx742j7gr+z1rn3fu/+7 99vXX3qEqw69UrXI/88O/Ye3v+rQ7ft3rAC+a4w43y2GjKexcw1dpOHAU6WOVlY8evSJjBe7 TMWBp5iMXaziwafEaX7wigNPKSbSDAPbNT853S0BGU+uPUVxxYFvmt2vY856dLfu25g13qzr PKxrPKwL3q0L3qzrPKxrMwSsixzh1gVv1nUe1jUe1gXv1gWv1nXarAvWrOs0rGs8rOsZDNYF b9a9znA2Q+z67tz2fXNu+743t33fmtu+98xt3zuWtO8dS9p//SXtv+6S9l9vSfvvs6Qf2393 yqltvm//25TD/2b/V/zfj4aZRJ0YNWbUQU06zLTD619fj09/vLwdaWqftH3THkHhKEIM19FO BaxJvU/oUqWrDFi6XMFtdOGMl3lMBY7dxUgLzcKHjwf9SnYnd1lt8ljXjA8y5ZAIzWy9OqJp oRy2G0A6pikpkhTA1KnYvgo28ceSGz7INOWiQLYvoB7qktAo6LvJJVc2Qlb9uVK27h8YZkZJ 9wKc7CTDlPNEj/94r3ZdSXIbmvdX3PDOAttTepaUL8bAxjdbbGCUvTYWPYmx/w/zdShW99xu R466Tx1SoiiKDygPabawtqJDxpJWx6LnWXnerT3PW5syDIt2q3SNxyDpPUfpGZZS5BsJdDNM cxlZwxEyF/l1BIJBVZGva9A2hSYsCvYeEotDydxsAttaxgfuzyQbUte5B7hx43FcgMmO1pk2 ZTKSkg3WVnTIgLRvY9H7WXm/W3s/b23KMCzardKtC07FhrG9ZHyQwa/LYqW1BSlCzbDNKmi1 rYoeo+9vWFrRIWNfsXMJPc/K87z0PG9sujArWn1o5hjhFDTY9bZOwWPkWIsB2lYGYQh0zUxb 2k9BGbBs6xQET8rlvHQ5b2y6MCtafWg+VLwlGw+znYI+yDSqi+XSFtx4TDsuwGRJ4YuGMtkp W+vainSvuT5wao7KBn1tYGxtyjAs2q3SvcZzzOtIOYqnelpMoJ9DsZ/DlJehvYZz0FBbezhH PikbXOfIp62hbIad7D60fGkMjmlDzywZHxhmpVNqC25cco8LMJmSN6WnPQ5qGLC2okMG0maP g2kqpFHZoK8NjK1NGYZFu1W61ngOSn8pR/FZw2IG/RyK/RymvAytNZyjk2t7OEc6KRtc50in raFshp3sPqiAJy7g3mRk65TQZWTr9NBmlGtqsc0oXJ5Cm1H5mkObUSkoYptReffQZshIGtqM xnl2tRlUh+YUPPg9d6ofu3RBXN0dB/ld256z/E1qdOL9dpszaP/UgcP+hfLUg7zyQ7HOGbTw wuE8VIMexG9Sm2qW4yapzOSehYN7sjWuJ/mbFoUm7pm6/Qw4uDtf24P4TbPxFLzLnFIqQLi6 zO/5XvimObDL0aaEBuetHTiEQuJl7uWVTxoaQ5p4yhcZMERW4hPfi9/0yQ+NLJ0B6JlO4Fvs h7VhPckrP1PUTwHfYntt+uPEY+baKoutGWwrnC1uPtPc49opDQb9e+zy1L6OsL5j8EmeyOKB wWd5YosHBm/X6zwwePO/88DOD84UgTcMnvy9RR743j/g7/z10r+vzv/yfM/tlxlwjX6DG75K P0VGP5rMaDMa/36j+e/n3Mu1vacvhT6+b9l+v6T2Xux/xbffP37lAe7V6Wl+oinlbzLZUOK0 7z/wAnjpRwIvePHJyhF4xYGnUSV6WfHiKa21GnjFga+c1wIvOPBTE5zz0xKY8dSs1Rx4xYGn 4D/xghevvcbiFQdeXtn3h1dXe5WmEf59fLXGm3+dh3+Nh3/Bu3/Bm3+dh3+Nh3/Bu3/Bm3+d h3/Bm3+dh3+Nh3/Bu3/Bm3+dh3+Nh389i8G/4M2/91mO/V/G8/gt43l8lvE8/sp4Hl9lPI+f Mp7HR0/P46On5/ff0/P77en5/fX0/H56+tz/ksW+fstv6e3jj5DOGk+kjZqlKels41RG2enj z8vPZNlb5ibo45fLe5JvHz9d3rP/K/6v+r8m/75+a7rRLhvRxJayFI2W+Di00Xt6++vf//nn 3//B4pQHN85xVmlL5R5r9ZgUoxpjVnnozNZ4aGNBQ1dPIdOTz8oMTQ/1KyX2mPRZekj0ZNxL zdDjkdiuuEinsHy4SStMYrsu03YrOGP6B4aZUadV2oLtOmQ6Beb2RWlVrtxI+tqCWJrqTR2L nmflebf2PG8NZTMs2q3SVYSzeJul94wPLD1l6bovVLn6HRdAqnbd9hHNzI7DugIO6YQzu9FY gkHVENY1aJu6plkU7D3kNoe9+CJ9TaOeNuMDtzmSEKhS84wKSH21KBukq63MQrdd+/7mSws6 pF3et7Ho/ay8n5fezxtD18yKVqs0N8MUupt2ZyTOE6t+kEadaZrRSltw48BUwzbNEiXbXqxM ezc1jNdWxNJk0hiLnmflebf2PG9tyjAs2n3o2xsirfmL/nT2qH6QmWHoU+TINEhbVPEZMM2v HNdQpk1o3MHaili6XMs2Fl3OyuVu7XLe2pRhWLT70JzCb16GCD7HoHDL+CCzC4vPa0ttwcHO OC6OKZFsTJty6dyyY21FutdcH2RuCsqAWBsYW5syDIt2q3SvIl3lddOfkTI+yBBVNXXuAUqG UMsEUzx1pVW58eTnawvivWg062PR+aQMiLWBbWtXVsNOdh9aA7rUBK2rND1MeR/yQYY5pRM7 BbBw3Toujmmi3JRWZdqTHI61BbE0uXYMp3mQDMqAWBsYW0PZDIt2q3RVpxTJViTeU8YHGSrV pY2fJiBVQnOCwEK+0a1UN1/H/uZLCzpkgM19LDqdlAFtaUDb2HXVrJPVB1XAJBXQCnXaLLis UBPeY6Gmop9SKNSE6x4KNdXXnkOhTijEVqhT4wy0CjVXnRoKNf3obJO5oq1ejWpqYnG6EfE1 /UkdOKh3tupeXvmhuEsuozq0cDAHvftJ/ibFpWbhd4lZrgyOw/EK+pJ6x5NhLcwKnInjfnBX 5hC7l79pNp3ivqJvvwIE36MxPQnfNIV1uQvpMznr7AbDTeKmo7TSSS92SJdLbz0DhrjYrAE7 id/0uQ7EyXd9YjPEjcXZRkbkB3nlZ9K40yEtBXzzuN1omfIgT3hs3El2UuvcRLfauEobvgHv G4Yulb/HLu+YHqJc5APfuNMNvGHwU/y1eGDnGx8k8IZhLw01FCHOO3aempFIKwRL10TXsmhg 56WVCbxh8NzM5cADO0/PIFoHDF4jc/HAzlPYl8gb9ttKHKuLB/5fb+eF919695X/Xvnnxfll pMMkV3dKXm+9dS6yNF9RBduoutI09xuNcz/nvV/be/qS6Cv92bL/K/6v+r/m/7r/+/L7x688 qL3yKg1J18TD3JCWzt/Sj96G8HTpkWa42B1tmNGKAy9Tb+CrjYLg6YGXyAte/ChcwxevOPB0 9kgzXOxMJ9sFBrZznxPobmOs8juFSwu84cBLVvn+kGVarSHOfpSljFfPOq2eBQvPgoZnnTfP Om+edd4867x5Fjw8Cx6edV4967R6Fqx5Fqx51lnzrNPmWePds56vzbPOm2cf83niIvgkZpX/ PCqN/zTqlP8sqpT9PG6EfxoXZT6PC+af3bzwT26W+c9vjtlnd0P8p76XbPb1W35Lbx9/hLRG PQ1nF+oYJK9tnNIoG338efk5vWXu6z5+ubynTT59/HR5z/p3Y5I6LaFL+KYKNXzZd5Vq+u3r t6ZG7GIEdTtk48aOn9wKkRHv//r+F0tSOtwo1flRC3cXnMgrtxWMpzwZUtR8oO3mnJyk9y1Z +zezVP1Jfo5dBH22XJR5tDNM906pXrbLK1eJ/GbtLrDMvRo3bS7zWL/ro0qRZhhYkWbrqu4m 1nEVTNwsLWthPbVi0jAq5jfXZffJc4fgZOrUJLN4YBU6q8LsuMT9oXmK6XHNNXpOPNnpRxwD xxa+LivQBKk7HKa9myV7oAUGWsS5fCcJPb02Lu+DY9CvEbdKYS3xblDPJQ3yWF5h5ZFEeubI Cw68yHNv0PU1SQhxSBUexFZIIcSs03Xc2J3WWwncuqlPDZm9B1pgoG3e4kmqh3iuRa/YQiJk 5T7iU2946p3nPj5c00RUeb7ygHU+o0QYL/Ie0G2QD0Jxb9Qdp9CG3+Oeh40w9gDusMtbmx3W NwxeG73FAzsvbXbgDcMebQSdd+w899mBVghW28RFAzsvbXbgDYPXNnLxwM5Lmx14w+BtIHQe 2HlpswNv2G9DGsLFA7v3n9/uK++/9O4r/73yz4vz/6DtbnSE/H9puz/16l3bbd9/4F3w81r3 yAtePL31PbQ4hgM/+AkHXvBqfjmLxmKkOPBdU4/zXTMTeEq+2wi84sC3a+yRBAaWCkEcCxQv nrLlFtUVB14yx/eHTGINpHv3MRMZb9513rwLHt4FD+86b9513ryLBhjeReaDd5037zpv3gUP 74KHd51X7zqt3nXWvOu0eRc8vOt52bzrvHn3MW9Lg/skdpX/PDa1gf489v5LebXr2nHDwN5f ccqbwterxz7UBzbg2p2RwlgbcHHSOP5/hK8hufdk9yDdjkakKEpLcZQ/v1vGn94e5a9uRxvX t4P5q9PnR//qdJm/Oj3hL86H+bP8X7bgMwm47f+14PzZ4rPH51mnzS9pHVRtl9a4vHGvvd1+ //z149v3fx477pmehlKj/WFcvTUz1ttExqNEy8p4zv0C5XlbtZbePt90mEZF+GpjvG4DA+jC qdncKHsOKz/Guzfp1KqOqrQaF2514FrALherc0cEtvLm3RYQroFtZTfWuHLUu+6VtkqtFrp3 jsMGpJnnPJKLNUFKTBXjgvI1L0qL8bbxhTXXCnZp5TkOZ7s+ULBVGK4NY2UzRlwp6l0OcBOo J8HawzbBOybYdBOSD8DJ0mWYApFswpgw51pdK9ilmVhKwQALkLq6LSBcO9aV3Rhxpah3vZSb Th4mGCZubHSAFUAvgoqsbHDi/2t/B0yR1IlpM6ZkU22Ab0W79DzLKE4XK6xmbNB9A9vSMEZg Oe5d/rXDPri8p33UdtgHINYyjFBgbIGab98H9aZ5H6yK0j4Mhu/lsA8YI7B+3EeXshz74OrY m09n0bOFM0CsZRihwNgCNd++D8JjXYNeWKaFscLwbRhLmzECy3HvVK0KV6v02LQ1lUTCvUdN JFhbqoGOow8c8hZq/eJV7C2s/MgYTvM3/kXfzr9r6VCVMuQtp/+9NOC0fnudH6bf5aetPcz5 Tysj81rS3TxPv8vf0moyL/YfO6/JUOvj7LveUfa2vhZN5aLvuuB7pLbZu3qYf9e7MSuWi7VI nWSUxGvjM34zOfJK9bvn/pqKfU1a9wHTGj2rq7cY86F1w79h8Ka2nAd2XrVu8IYRj6kx8I6d F7EbtEKwptWcBnZetW7whsGblnMe2HnVusEbBm9az3lg51XrBm/YT0NVmfPAnv3r032W/afZ fZa/Z/l5sn/pEKMxpKddn1vpC+kln+gpp+bwK3WH7yv1jfNLcSVb/av5V/ev2b8W//rjry+f ueN7llXq1+jf+eTaVMf/I7vgyfuWecHBF3sRwCtOPDXE+fQUB09JnZO6NJx4eojmzAtO/NC6 4/zQugKeeuNeE6848St36okXHHynnj3HpzjxUjv+fqglUKfI72MtMt7y67zlF3zxF1d55Nd5 y6/zll/wyC945Nd5y6/zll/nLb/OD9Rt5ZFf8Miv85Zf5y2/4JFfr82WX+ctv4+1W/uw8/ur /Pn9VP78/hl/er+UP78/yl/djzau7wfzV+fP/NX5Cn9xfsxfnQ/zZ/mX6vbhY1VNGmVukd5B 1BjXuYlL3IsI2PflVrkZ+/Lnu5cS8rbGZ4vPHp+zfn74OOtaq6y1UjFdX7khnAvviNZ6Kbff P3/9+Padp1MpnKjMeVrH67KkTo97mhLNDZX+PqdWiZv8mjov4lf89fkUqZpyP2kSrFT2koSj DkAZktMlCUf2mYUjRbJm4UiN1nDhqCAJR7CqDN1WYbg2jJXNGHGlqF04lsZZTcJRB6AMaXZd E5REhXCklduShCMFNg+oOwVJOOoAlKHZOjTXjnVlN0ZcKeoQjjy5ZOGoA1CG5Lu3EI58/FsS jhxXTcKRhtfZxZ2iJByNNmUIY4Puu3hB6i0JRwSW4w7hyLMPwlEHoAz5oJNwlGuQhCMFtmXh SHgK4agoCUfQqgzdeMG21iwcfWkzRmA57hCOvPk1C0cdgDIkZ/MI4ch/a0/CkUJZtiQc6ZHk Jc23oiQcQasydGOD7luxL23GCCzH/SAcqUrLo2HlQWDqWMdrSzKPfFBaQxYqTtPRUh3mh86b ZM2QhYqjOE38dz/MD6EHe+jC4LXYhX2eH1LP7U0YBq9/tZkfp4fSc3NThsFbKYb9YX6IPbdX aRi0HQXMD9O5NP87AGAWfwQKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgMzkgMCBSIA0vUmVzb3VyY2VzIDIzIDAgUiANL0NvbnRlbnRzIDI0 IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzUgMCBSIC9GMyA0NyAwIFIgL0Y0IDUwIDAgUiAv RjUgNTEgMCBSIC9GNiAzNCAwIFIgL0Y3IDM2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzOCAwIFIgPj4gDT4+IA1lbmRvYmoN MjQgMCBvYmoNPDwgL0xlbmd0aCAxNDA1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiaxX23LbRhJ951f0S6p0IWHcAa6jBzkbpyoV2Zs1q/wg6QEERuRIuNAAaIn+z/xP Ts8MCJAiqdTWPtiggOmevpzuPu3QYvTuty8OLZqRQ5JGNtkUOi5FU5dqMXoYBbEVUBSE5E8D mji2enuhX/vqv9fvI9cm1/NpEnpT8/7DbPTuo0cOzR5GDl9iEx5aS+BZnkezApcv8G+WjmzL nuLN8+isEEVVb2gpRZ3UKR4N3Z1V9ZiSvBV1mbTyu8g3+JPqpFwIqh4oS9qEGtGezx6hbeJY TkCzf0OnF0dKZyN/iObu3KJfX0S6bmVVUisLQbIZs3xaretGjHHnYilw01ykyboRrG52ATUu nGI1K1E/VHWRlCmLEuwUlImVKDNRtgSl1zfXM1oldVII2NqMtxrsMFYa6qTFDdQuE7Ygl+WC qu+iXooks+hzmW8oyaS6H9Y1Oexp8S4XTbNV5YVKU1vlCBBf+8CacBo+UrrkmDQWXbe4RFCe 1Piz7U9s1Th2YMKdNOtaZAiy57547t35mGTbaFdkmdb4jq/NMqlXHPZXsVFaYIQs4fKkXUIg 0388iFqoUJXKlqZI8pzSJF0Kiz5WHAXZu2VHOv15Va2ohM1jElIHC7Y3MKBa5xmuV27AoIqj 2BLrfJCtuWSrLvC0e+o6JLkmRHyAoC76rUiXpfy2FvA/E01ay7nIOi1Kw1zk1fPd+cAAuJ9Z fMax4iHa3ECnZsbOirQqM1LemKtk06wVbjgYmWxa3KWxWD2wtsmeuqmnI6L9b9lfji2S+3Up SgWzPBe5/MHK+aKGgM5tBHzP0Qle561c1VUKEFXAJAonkw8qNwYXMAmaqjRpEVfcIxCzPr+u VrPVgEBpQxATHC6SF1kw9GqBuCDKGX5la5V2BkSfYN/dU5RWRbEuJe5FEBj+nKMvNzMUYvUs vnMldqErezWBr6Oy5ApMylKwIpOZTCCoBRxLcov+U8vvcGlMqx6XKpZG1xlywJWfLMQueHWx APB8NTvUlYHKXFtBe++WG3f29LIPVdWuIK16goI+NOVi0rsOL1Uce8DasQZsw5X/kKQtcqUR XiRPgubIz5MwgJIwVgWNGqA7W3OMdjAry2SFy2ADAsCo4AvR/w6B1tYt8r+DzrSQ39l1xgF1 BY2WUD2X2r87lBWgp+rk3Udf9/g9+Ora0Vbrc2YWeJbjYBaoy23VV2/PTJ659yQmWPqmFNbM dTLg/Hyjyt3Uwfj8fvb7aKL0DR3ydUKScj9aTaduW3zQmW7SXLI70J3W1U6jNZ2Wk66vhOc7 PgdWGAXGGd1ulLYdf12MOrdz2OgceGxB5xch6KNcoA1TqLKVANKZ0P7Flo0UDRy0Q90XxMsq T8rEdJAtQthvbYa5Y6xeGf3RsEds3RPoB+kWrYN6UZM1TzbVuj0MH9/VQfqgx4KuENNUdNbG u9aYHBxqeI6vW021alVLUQk3tad6dadbjTr0HtNougnaZ05D+u6sczrlOH/FONED0cyUQ5Zl qJp+iJjeJ3ZYQ8PRRn3lpnM1ZL7zMC/1mOu7cOwMWQ3KECjMq4ZtMBMM2tTrZ7aPOcWg12nW kCwWNfoGj63X7IgB9BmtcrXGMCwrVcXPCSb1zjh03VcMBveiRyxAVszdKjZbMqWqhRX8Oht9 G7A8F05NaeIGU8tWjPErlWCSzON+G7n0O6D+SLYVufRMnhWHdEO39zZlIxaIWAdKlFzHtzCg oCa0NGX8cDH6U+kJQyuOKXJiFnbtAJMM57zAcqIhtYx0ecWKWcbUSXnwdcssUTq2o+iljiNG VlXLBdpjrnqDLlRHawqVprDTZPt8PzRNejVnD2r+PdIVOe/h5s/0CY/LS10YgQJzGEYMZ3P0 SR99wtE/8Li8vDs/fljqwxKHb/A4dji9fby/fbqnyytKbiX/vJjzK3n/Xjt0MDSQ7kLT+zNH RLrGoavgREjCID4QkvUcVheyvDv7dHF3Vmxkduncnb8r14VpmpfOmD7dnb/vxm6uBJIXFuDj e0edwVET7tlVPkecZ/TzFa3Vr8urxxl3gVPRfJpdceSVFMceQk9vCkklJGcmBZCRx2VuOwNh jYJDF4gxLNQGTpQ7E4D37FHlk3v6EXuvVFAQgqeZiYG3c4xRZG74Ywx3nvobemRNjvgFPxSy jIKbMXyTvYL/M9iCaPoabOjCux33BNaCyD6NNbogjTa6pF288YujiIOYEnpH+wKHcAexfeRx IP4J9kzd9+hjwX+CP9MDtghkuSEGtxE/rIB7E9DHTr7fia+DgGoacnYCqYygyIzlLe4e2YY+ XieB9haKbU7kNqfP/yOqJ/ut/TjKkV256+BeVcmjpfMG9jEY1bzyQN7JjzHIAjWvMN4mrsPD bjCuwi4LCuZ4GDEUSjjdDizlkOUHmsB0nPBf9AvooGKGr1keW2Kz2W5PQ0GIGsVMmKkosmO4 cCma1hrY7jlTNdcdCyPZg92hF1vTod3evt1axEV9Rn4/aLs1SO0dem8AydG8QjEiUVso/49w QbwkxSrHXmbci3sXtkzQ0axS5vkaVB1LjNmFnvc4nKKCTMtBkHDK7C8xJXWdbHo+aHZGkQte DhtmuFgC8JujtN+VDK3MqHgp/urXAduwyuub6xmJslovlkzhMmF2wwRB51VylywaTr3V4nja FBMTcCxscFs6t2HGGzg/8YZVFSvQZ76iy7ks+60zmg4REvMcZ0jgNIdIluQFPw23AuMarEkG StwhN23W82bTtKIA+2NfcsN29QL7g9e+7rrELAMmMNqWzyXvUK06D/mNyXvTDkh7Jhm6HanH llAORoEmzK7mvB2pV+z+eSnyglnyXw0lcwi0G3Z1KbOOEe+sNDmgUKabQ/uKY4jwLzsZ52UF P3NS8F3VEgrMIlas81biZQoCrjen7drCu5zaOINAm6yJvEXXPT/HZkm38T1oJy0381puM9EV ymvsxxpnhVwsW95Wiwoh1BsaNgCLdk1Pq3We8TFsX5z/Pi2RXhPRjtU2hQYAYzhyCLrgEt16 NabnJafoNRM0mrRF+qpMoiLlfN3qZQwJSeuqaXptDacG7VffKkuU5WQnPduTML4o1qXZo7q+ 9G3kTs2e4JAboDW56Ke+Y4XRcN04dAg9Ne667p9c+Djn2w4vI6EP+uugTXPbmqD3BuYc+tjw lG/54cFT0+Ep3DfU5ZtTzuAMGik6xiFNQ6uw1njuAU27VnkuGuybVrlTy/UOnBpa5YaWM33T KtezHP/NWCH49vSg7UOrnIjlT1u1c5l/0CTQl+nhxAxNsiNrejjJQ5N4tTuUmqFJeMTuIU3Y cu0TW+5JuJ1E2UlwnUTVSTCdxNBJ6JzEzEmonETISWAcR8RJIJzM/8m0n8y3jywiFyaZ6u2E j3j6o2954dGPDufiyEdk0Y2Ofgw4F/1Hf+ejiwFxTBJZRNyOSCKLyMUxSfXimKR9ROzLyHdC axoc0+p4nI0jWh214B2RRB5j95gk8hgdjR6n81j0vuz1lGnIXP2tnjL1duF/uM1NbZ7gp3tK HFmHm9PQqNjfLYu/Ca+CLblxG3ifr+ijk/csS6JIUdd9efsD9jGXTdveOLF38za5JF8fgKgC oR6q5zRTZBdYZBEANe4IVb4v3i50+37OlVGf2rfpGBa6k6p9OefOWFWpUx11oLOqkqd91M2i qrKqZ281hdw+nt4yMJepjBtMVJXTNOovUVSepzyy5ul9enqNnt6eZ9fm6W15ekme3o2nl+Lp XXh6BZ46/9Typ04/NfiZr08NZdE3N0dFfw+T26Doj5ko+heTVvTHYVH0x0wU/TETRf+CaUX/ gjlf0HrRH0dF0R9HRdEfM1H0x0wU/QumFf0h82MLfMgp1GPKtx8ONSFv3wXKGc0JWNdJOimP ML3kgI16f3Go3UXuKqk1SynxZRTob4/pUMk2uSxTDkxCxAX0VUGFpKD3/vJVIldDe9uNhK+Z A01hbpGy/CXUdVZuIJsMrRski8a2buW/9+bVvPQ5kVgCk5CBgbkuyVTliu9iyE+fXj78XG7L 7dPXlyov6flWm5RdrkYtkwj69EMe2b++vJvxTWhV2M5BCpckWfexzlqrgpE2QK/2Y0pzd9LY 3cpd3swpWLknrQy+VkPBTEzDL5IJGZuYS/MmQFjU7YYqTNFQG6BjEms9uqGylLzmu6GiZC3B UNFZkp27/RsMxRwcI5OQgYmxrt8GqHLFMPTRR+kgZXcft4GP0gykcHUfSyvDwUcboFFFuuDa fTR297HI7crBxyIWbH7WhoKPmIZRJBMyNjGXJhnCom73URvgEn20ARqlsfbuoy5Vgo+qZAs+ qs7Fjtv+DT5iDkaRScjAxFjXyVDlii98lK68VfexRh/l627ZWwmQlX44PlYlio9LlbaVOKBd I++tQizb7tDY9xfHqlOtAFmqTxYy12pIfr1KS8x7n06tO5BMyNjAXJpkCDvpbj7qyNpGzEoV 01plG1CpG8K1IzUYd7JBTDMEZJW63BjbEHaSwnTfiZKf7ESXJhnCTrofDV321rWlwMo6NHQZ GLpLe6/BUMnzXKOhNkDH9ioPyW6osbuh+pQ8gqFSfVL1QzcUDOW07ZNkQsYmxtJ+G0zYSXc0 VEbkFRkMtQE6JrVuzt1QKYXzFgyVSjmvwVCVevihGwqGchpSQSZkbGIs7bfBhJ10XxgqZyQ9 iIbmaKg8HPcjZCiwZ2iS59jcM1SfkkdIE4P97gEjyUhGCnItZmjSB1vP0FT4cjJy4bvKYgNz aZIh7KS7GSojdQsZqmLWkAh9Jy1NrneiSUYyUhCxPUNFTM1hWm5DJAOGnWxhaZIh7KT70VDR 0W7xKUPXgaGeoTx0Zqh7gkSwfXqaAHoWASPJSEYKci1mKD3htDnmZEDGJsbSfhtM2El3NNQz 1D1BIkAq0wTQswgYSUYyUhCxPUPpCafNMScDMjYxlvbbYMJOui8MPWdoiYZuSd/PPUOBPUM3 fU/3DE2Hvhl7mhjsdw8YSUYyUpBrMUM3+WfuGbrtVmtIBmRsYC5NMoSddDdD+4hlqIoJPVSk 1tDIAONOamiDJCMFw04W7iT0UJUayXt4p2AnYWmSIeyk+9FQ0ZEeEzQN/PQEpVImqFuCPDDD PEsAPYmAkWMkIwO5FhOUlnDaDHMyIGMTY2m/DCbspDv66QnqliAPzDDPEkBPImDkGMnIwLCT I/rJaTPMyYCMTYyl/TKYsJPusZ/n/Nzh5yxTv76kdZ92/Xot0ypvfnnrp9v7ZdVy88eXl69/ lp/t4Wd1ExHxZ9V/doSf7Ysex+BnS/hRPtoGXv9oqCnpwjLvk0k19sntNCnvinzF1Ly5Ip72 92pykW+Lq6hi11GumHpJ10tmPKxHpn68pCumfATJn6vJtX3FjSdPZ/9qskxluxKU01QuiZJO r09Pbnn7nGhuttH39pM2OU/bGiZznJSPulSvmKXd6ivmMq3HFTNXHb1g5mxPq/GkPsSvwm5S gK+IW5nmckH8KNNJb9YFV6tkuZws1jHHk8ma0Hhynurl+Z0y8GHy40PpkPqUl7dLR8pTWt8u HfLBsGxvlY5lDskWlxxqerym2zZtl3dYSuZ2WR5SndJ+xTxt8BVzndbLVJXn3XqZ5Gs5F7rz ZDytV5PzNF+WSPm6mi9L5HKZ/qeTf6TNUgMvT33ezmXuPCk18HWBROUwMy8qh0+OKseYicpx wbTKMWaicoyZqBwXk1Y5xmGtcoyJqBxDYq8cYy4qx8WkVY6LSascF5NWOcaTpwS8qhzSgmUk S3nZ5Di1T73fpa3IT37ysoHf1No+QPCbfPiPjvYeXfUF1QPlGGgJv/Aw+RRGHksffl5u8tr9 6q+mdIjeVYIuU8l8NkkqzXLQn+4v7z79/Y8vv3y+zfqOmqX8THNa5Hn1F59ZdKbIGclrTo5K OnGcXQNPfhBm2kv7/ZKnI8vlXeTN0Ga/3T5/+/Hlt39/+/03o9bbe9WaJL8PuXDrqh9wovPd P86//PBzOe9sk7YvT8ldKqZ41HamG7r/9U+33//1n28/vv3vy+fb/b/379/u4dGfUnsUtUeV PvodJ43yXfAqVzRxQK/HZt8bi7y8HTb2/YVYDFnk3e5k/ehQssU2dG+3dE57n97Vk0422GMD c2mQKSzq1kd/G7G3ZD3azlRM5kCTah+nq7xrHM5aBLCT1MSsa745WaUeN8Y2hJ0cYbpd7042 2GMDc2mQKSzqfnj0p9RqqT5zc3/1zwND9+imPG5LNLNhmiXfHkftXu7RSPnimpdgpLx1Nz/r BoKNmDSbnAkYLfQV6b/JCVqjgbWlajDQBtwhyd6lwy4/ta+uowb39GMp+wkbCu5x2uxxMmAN 1vmi9B2SouIL6yRs2rTaPDFP3v7y0+5fObQdBgNtgC5JQ6xzd9DY3cQiNykFE+XjYV39vA0F GzltXjkZ0GMDc2mSISzqjmbqyBLNtAEaJuH2vZup30Al+Cli9i34KVKXxY/dUPCT0+aZkwE9 NjCXJhnCou4LSyXyUp4aqh9WKRiad30UBkNtgI7Ja0PecB02djc0y/3agqHyaTYnP3RDwVBO m2NOBvTYwFyaZAiLuqOhOnIqrzZAxzRcKK+6WiyvKiaWV3ksHb0EGgqGctocczKgxwbm0iBT WNR9Yaic2FHHhsqTbdUCcOiT44djqdbySBFD5ftj3XwgyQuldU+Nuzs0tkglliySeu7kap9m XKugb8hba132Pn20p5qTAT22YV8aZAqLupuhOtIGcrupomWpmQOqNGeLJodJqItVbKRh0aKF kOTaVkFoA9xHmJUgkQvooQ37yiBTV1D96KY+GyXqcriVy8DKXS5+CVZK9V5LtNIG6JU0L3kA d9jY3Uop72UPVkpPmYsft6FgJafNKycDemxgLs17AGFRd7CyLkhNd6MN0CuNlruVutgWrFQt a7BSvtc09yy0gWAlZ80r5wJ6aGCuzHsAXUH1yEqJGvrmyEqp6VsNVkrVnmu00gbolZT8rXQr jd2tlLK+HcFK+Xqs1Y/bULCS0+aVkwE9NjCXJhnCou5gZWlv+2ClDdCros/BbqUsltdgpWjJ c7BSle48bwPBSs6aV84F9NDAXJlk6AqqR1ZKZ67rG2ZKPcf1BS76IA5m2gDdknK/7t1MY3cz pVmkOZgp+svhB24omMlpc8vJgB4bmEuDTGFRdzBTBo5TibUBuqXRQonVxWKJzZrmwUxV6nXQ QDCTs+aWcwE9NDBXBpm6guqRmdItJb1PVr7Xl1dZb9KJJW3bl+4v8iH6t++/3//55XM0O1ev 9q2fAns/1dMrvZ+qxNybGqD3PGK0RJLRMLkW+2mZxb7eT+VSboFMyNjAXJpkCou6m9k6Evqp aNlDPxWlS+hqgN70iNETSUbHtNDeT1VK6KdhH8oN+6gP+9CVSaauoPrRbFFR1seWug7c9JbK E2dLdUOsc8Eu9jVCtj1idEWS0TO5FlsqDcE0tkkyIWMTY2m/ChAWdQc3vaW6Ida6YBcbGyH7 HjHaIslomhbaWyoNwWzYx5pP+9ge9pGDm9QVVF+4ee6qIze9qxKzq9IQNC/YxdZGyM5HjMbo ZGubjM2uSkMwjW2STMjYxFjayRAWdQc3vavSEHQv2MXeRsjWR4zO6GTrmwjNrkpDMNv30bh9 Hxa676Ot7GToCqov3HxsrCM/vbESs7HSEvQvGMbuRsjmR4zeSDI6J2J7Y6UlmP4/4VXT3DaO RO/+FTjaqZghCH5pb7s166qd29akag6TPcgyE2tiSxlJ3kz21+9roB/Y9JD0SXpoduMBr9EN 6ELpTMjYxDo1nUnM8jZ65sZKSbSBqWBsb4TsfsTaHOmsrTOFzo2Vkqh1XEdlam0ObdZhay15 GdYLek5760RN5EHTm86pOHdOSaLN2DmRY5vetK8Ex+6mmM1PndkadS52zs4XTTt2TpQqb5wJ GVsxp6YziVneUU2MtKZzChfTOYWp7V8Jju1NMbufOrM3xtC5c4JKazoniFbGl5ChFXNmOpOX Yf1aTbAI7evOGWbUzJ2TO87OmQVJDUrlyu1LYe5uitn81JmtUedi56Qgala56EzI2MQ6dU4F JWZ5GzVz58yCpA6lcuX+pTC3N8XsfurM3hhD585JQdSqctGXkKGJdeacCsrLsF5Qc9o559TM nZOYnZOCaINSuXL7Upi7m2I2Pzpra9TY7JwURM0qF50JGZtYp87OSszyNmrmzklBtEOpXLl/ KcztTTG7H521N6bQ7JwURK0qF30JGZpYZ87OysuwXlDzdeec0zN3TmJ2TkqiDUoFy+1LYe5u itn81JmtMcXOnZOSqFkFozMhYxPr1HQmMcvb6Jk7JyXRDqWC5f6lMLc3xex+6szeGEPnzklJ 1KqC0ZeQoYl1ZjqTl2G9oOe0c07UDLUkf1v7ootqEjdFiGqGKp4VHQihlIPU1qHoZEsJozeY Kg7oEiIInUMvtZ6xE5Kv23jQsrmXkzU6JzjGVsyp1ZnELO+opozUcaT2cWUgI9uYBoQq4qZw zQgxW6srEQwyXd247CxUvWPshHQljTGDqnVOcIytmFOrM4lZ3q8FBQ/0EonsQxa0nhG0kqwY 9QxIIStnxFkuHIx+VDO6jmJWaBLeiCmdjZO0VsZoSCJlH4WMqApzPuqfyBimVsDAQpM1iANZ IZ96lkKZqjYCCpPKCFg1sR9q7ISMgDQnhbKzwhxb9eXUVF+JWd4LAlatVIs1AT26UGUUrHxR TiRMA1TJb4q6HDVM3qOIHtkUjIg+oMLnPU/ISElz0is7K8yxFXNq5oESs7ytoDLSWEHTABWT cN5AzGb0BJfQGz3BNJ6hFDohoyfNSbDsrJChFXJi5oLSsqwX5PQ1jvKqnGUjr4NRzrKXB4GR Mw1Qr7IrqmqUM3mPcpbSEYycpZfMzLE981QVoTnplZ0V5tiKOTWdlZjlbeXESOqXlCQNUDAJ txnllNl6o6eQaY2eQjXkTU/I6ElzUiw7K8yxFXNqOisxy3tB0LKSy8FE0A933uFK9PmqB1OI 4KsCkVGFf7oqi7KU69Lu6nrvHvbPw+G8Px7ESWLeSvCwqYt4akUxCXz9+/TLD3ethlcqdVnL DnWYp1MqMsH9pxu3+7F72u80y8oigGMdnyhoG7h3eFf3BZ4rt0FS9jRcfX6Hrzr7Fbagnf1q Y7/y0oLGr2r9yptvsNWhm41kWQUcvGom0pSV7H3/JitUYbxP//qVZYXyihvFW6wq3A/rN/eq KiWZ5rhbVqgl8F9nNZmsnqXkEXVeGEsJib2ZF9lSQv70c9JYSjhPfTXzzWo6rWbRavKsZs1q sqzmyGpqrObEaiqsZsCq8MuKrwq9qu+qrKt6NuhdoaGYcfQ2fSJGDy28MdYTYxPL4YIntKiW PMv4wFzwLKFFtWgM6aI/HxZahAXPetPK7W3eE32y2NQLnr/ALIdnwbXvin5p/+oeeiza4pV/ IWqHf37Jc3L+Xnn+8qpoYNnV23UM6/dv1zFsg3+rjmE75quPJYVtmZyL+ZKPDSrfrmRdNz0s c42oQ3+dq2RTVp2fHp55Vi0uOXMtZsqqbaQxr29VW4n1rarf4GEx364sq6aVW9xbAjahmGsg llRTFs2cNKv5tJpGq9mzljar2bKaJKu5sZoUq7mwmgKryq9Kvqr0qsBruq4Kyqqf1Fyo+gvG VPUXjKnqZ+Nc1Z/3lKofFj1T1V/wTFV/1siqv2BMVX/WmKv+LCNW/fm4UvX9omcq+/OeWvYX jPYE/qXs131fVPDt8arFiyvDDtXkCRBeuP8kLAxbMSJiTHOF4rq7yhBMvXxM1zKeUY0rYBc3 yW86Gjc+rpyehBqXUGfNromS4StPSBnwbRzAXfE5rsDXDQeEZJOCdV0zwiC7m9bQKJO6caMz 5kyLiLEj0lV0o9ksQ5zNMtrpOuLU2VmJWd6vnpA1fCQfpWo1+QlZ6mst1mHdBxSDOhgd2yBZ boRMA9SqlRv1qGTyHqVsQKY2UjZNqmA6V0RGTDXrOulMyNiKOTWdSczytoK2Ma+NoGmAisVw I5TZjJ7gEnqjJ5hG9VPohIyeah4XEp3NQl6vw8hJWpb1gpwozqj5lLOakRPvFkQZ5cQjB7lk 5EwD1CugHdajnMl7lDOgz3ZGzuCLps1bnpCRU826TjoTMjaxTp2dlZjlbeXESD85n2mAgkk4 cz7tSholY8+nUB3PUEJGTzWblZjzObcSez5JzPJeEBQvScxDQWsjqLS4sonFoJcszhiHpIGg DR5vZRs40JR9EeuOnKhuhNF7d5UxGMNpdC6LCs6MHRG+9rgJhW40o5BaZ4WMTaxTZ+dEbMJb BI0jdRxpQlwZyFQNB4Rq2KRwm2aEmK3XlYSNkmnc6AyqweXYEelKGmNu5OozOitkbGKdOjsn YhPerwSVS0cfYmTcTCmonxEU1aDpjaA48L63gqYBKtbKmRoFTd6joCg1zcYIikK06fOmJ2QE pTkplp0VMrZiTk1nJTbhbQWVkc4KmgaomIQLo6AyW2UEFTKlEVR6Q5c3PSEjKM1JseyskLEV c2o6K7EJ7wVBUXJxe6egQQT9cOcdDu3nq1vUFjkfRVMHlOWf8AoqS7wSPu6urvfuYf88HM77 40F8JOStxK7lUo87ZlUVdUyU69+nX2q6VKIT3hXY+KruirZytyg36RKGZxKYfrhrEw1fRs74 SU54sUUWiXMpdCQ7Ovfx+9X13f7Ly2lw3d/c393u+Pxte9qfjwd3/Ozun467r8OD2x4e3O7H 7mm/c5f90/7wJfG/9WmFod/EQJdh93jY//EynN3n48k9vzxd9t+eBnd5PA3bh3ORdqpJFHPd a1vZ8qaVV6UQRLg+Efv4OGQKaV63P0uQW7whSrmh4kcKTGRRddh4cTs/Hr8f3P7gtp9uCvfP 7e5RvAf4uq2r/6zd9nTa/pD1DU8DtvlyLpxMdXh5vh9O5+nafOWrGPU0fDsNZ3yN5QzueHoY TjLH98e9xkd07OJ2txvOZxC+/+GGOHVcfOHujieJ/PFd2vlI9bfrya6+Vw8le8afJ0v5pkNv uH7v7l8u7nD8Honkjx8xu8x685+PP+ssmzTL9RZhqIH71wH/4TD8uX2GOO8tS/dluJzd8TC4 E8JjgzjDe7c9G/aqT97oe9noX/eXRze7nhT7+/H0VYJjRednUML+7R5fDl/HuL1uCiZ+2F62 bnvBtxechPfufCQXyYLjf4fTo8TEOr4g+GU43TT9dVzc7tPN+3Fnzvv/DeOO+F7FhN/+sIOn KHU5uv7PXn6wgy+7IQmsU6R1YY1ZmrSqzDo0uhu6TIRGnnw74vTeg4AcBPR83UsmnOynbFxK pf2X/WH7xIgxGNNeVSq0DPyBIlBJke1wAmpXoYoFlIGqrtC9pA786g5XlfvZ4TvU9Q7f4WD0 rkJtRC+4rUIr7Tu+2v6diop8HHyPd5GrO1wmK1fJ5UYO1wbFrJOP//EOn2yKDS5jHa6BmBi3 oSp+4qVSpwLkJZTcruQpghgbKfy1vMcUPmWIM59eFOnjV1A/zrDGYyde816ZWxk3ZsU0b6SG G7NiNYN5UxszMc34nZgV0wzGE7NimnFXtdYEdQ9KH196tGZMc4gXzdGsmObY5YxZMc24LE/M itWMVtoa3hnTHKQWG7Nimhs8x6xZMc1d0VtrgmqURDTG/1Nf7TpyJTc076/oUDKg9q13VWqs vcCmmszhBRwsZv4/NR+HLN4eSb3pQoHm9CkWeVl8AhqZHz2SCo2sHMmBBTZaOmKggY1ejxFt Ngyaxu0UacNG10uUODaaRoHIKjRyUVQHUuE1EZy95smr0P91+L0Kgl89hUw8Q3ozL4GZx75K LqVRGdPDf78cX7+lVGlG+9K+fpuDSsGXRL81Kk3lS2r2Vz6k8lLZeuHl71ya779fnfDpo42t PCEEWnHgO9fCwAvefCuPHK9XHPh19bnip9r18Vy7/s62k//J+7ydjk9HGg2l+WpBKiEL2YKy U9ghKker9LK77hhETaOuJKctfjtH4i6+NIWPBFxLaBONexpMY1MLr19uqpue1NTgrGH8WtGZ tOxlOd965AUHHs6u1BdnMvO0Nxzjaq6Yb/YZbo8jQZ52kdqrrn3Mly7naQIKvODAy3nmKR0T vMU0VeERnKe+bFMD0VxLHwN2ZYHHgPDoEih0avOKN6/n+eUqRyxejktL5sHCX9JfVj55dy/a mVqB/LEEJ4iLuso1O9CCA98RRklvq5BeavxTkJHfQm8j08qCcFZdq9tO2mLIgi/4NOPlvIb0 CsppVUxROQLelAO68sILW1BOwfGUL/2iHLwpz5QCM/BZNr9P6ZfgdsAKr5N0Wtt0Yo8stqrX jc7wuvH4tEwjRo26+fegGpXAdQO78vZoLSiv7JKgHLQrBw/lNNq2GeoOlcxZDIe6lPjn3UhJ HHUrc9ZKQNpAmvTbc4+84MDLeS0GFGNlNH6fj43lP5U/PuN6DI4Ol3/Gfr7OwfrC/cDOL3Zj 4IGNp7l1rsAbdr7y9wUe2Pn+6Bce2Pml3+f8un4vTa818I6dL9zCAg/sfOcwCjyw85MLTOCB jacsXcF+x84XDqfAAztPBe7CAzs/+eECD2w8TU8t8oadz5zBgQd2vvEKF3hg5wd3rcADG18O rpibN+w8FZILDwz+u8y083KiXiKolcGpEXhg59ejX3jg5wwx/iljXmXYqwh9GSGvXuilh2w6 jXb/vBJMaiM18IoDLw8Y+KFjifGcoIEWGOoKNbW5aeDnuvPxqe78Zet/bd1P9V/3hrHUhZRr ifcGWhne/rx9I8c3Ks5UoRqN/2+/3XhvIOLtHzfeFugvWhaO4GvaP1oNWTFt3kUWKb+zfMrY savCxMhnVYfwMUNM0SQpY41Vxdl5stpVlf7Tkc28kdkMnZj/uMvPU271yIWV3MvZmKI6eWQy KFecN8fp0bnZmmx6AE0Dp028TlKkjiAJ6BcDm17Iwqhg8anfSZj3tYnuUQ1W/Xp2wlgXSD5U WcG0w/DNKkrtaehZvlcRn808wjqbH6MFSUC/2LHqVdlt1Lb41JebEqc+TDuUxSHJs651gVll gWkCETtUlMYXPot7BakeiQCw7ZFakAT0ix0v3IVcauFmQafG4pTDeAO6xSDfNNXEsS7wMEWC KzypokW9jHuLvYGUAmcHj11bEtAvdqx6IQujosWnZpf6qnb0+GqQAYcJL1GkN0C6UGUFU9Gl gc1EE6er3yvo1OWjb7ZKmLgkoF/sWPVC1o3aFp9aL/C6FVNEnYZlE1jqK3oyh4X3CxUWzLtK vrts5hXKbxZ0ypZR62ZlbN2igH4zsCmGrFu1bT61BnZ5sjSxQsg3CpaFQr+hrQDFD+ct4NTz 3WVl+Pabs0Ys41k3W2Vic1GHuBnYFEMWVkWbz13XKUZtj6nTsOwlMJIVG+QAgLBgqhvsTJOl gV5lVzd06kJVN1vU0SZa7FmqHca7qGLIulXb5lN7lb6LVCReaBBrIlvN0VwaAszqAOAshcVl 00MON4v/NaFp1s3q5Oyi3d4BNzteuGvWbVW0+dT+W8M70FbU/BtlRxrbHQbNW4bhTJNVT9vN 9g683+XIrhREAf1mYFMMWVgVbT6pRyfu0T74DMqhOEocGIxsIBc+jBKiKowSiVtmWGgGl44w ntLU2eLC5TwWsoHRwwYv4zlRVB6DWdPxdT6Nx90WyHhe7z+yYLSPrOcFXxbEsT6df9cmmIN+ 7l0j3o/vMf2X8+/aghgvLZ3SOYbh4B/493qe/Zl1YYN+qdvh+93f0H89r++Tsr3Xh9bM/oP3 O3R0u55/l8onQVR59PvQejUMh3iw97+cf/eqo+//4bXC4sHjq3MYPp9/14xvcr82z6w9PGl4 +D44+auej79rskX1nCI1XG/hb+ov599vZRz8PJWWvibPT/vlcvzuuHf+in3+Gdt5x42j5OMH fJE9YvPAzjf+sMADOz84fAIPbDy9c468YeezzMGbB3a+6vc7Xy/+4LGtXHhg5xfnWeCBjaf0 TPH7DDsvfwQe2HlyfLTfsPOL4yXwwPaeB5fWzTt2vnJ4Bh7Y+c4NKvDAzk8uN4EHNp7SM4fv c+w8zT4XHtj5LjvQ5oGdn0wEHtjj+bjEj2PnC+dH4IGdp5H/wgM/5cvmr/n0Mj9exeeL+Hj5 Pi/8Q5vtI91/f7L7s53GUzk5auAVB35wtQy84M03Gkda4BWHunNc/aT4uS59fKpLf3f7v9/+ 9Xb753/KPd3f/ncb94P+UVfqsu/VwgPQ/e3j9uX4+vbn7dvxaHdqe9S77m+/3b5k+fXgn2ot 8lOVn/79Rr/+Ho2nVruTsMlquJPYsBWRRr2nhCLkGEWuNc6VHcRtQB5FuC3O1V3EO3pwcJ7M SGUkniGAyTl9yfnN43xitcH5VWcals/j+jiJ3NYymxF4wYHH48lwYeYx3fn3YC7Mp5EghR7U aSSAdCVEzhtgcxXpowVaYKDlOPuKGrS5iunFc9N2nbly6NMZ7hhvGE+VnwvytEvWNnV8cl5w 4OU88+XR7OU+xJrR4kviZTvvVrs8sXkT4lmv7xX8UeX8ypEXHHg5z5FFLzkskpifGmkeWYi0 gs8zLPaofBmC1bvEi74K9xgvOPAdj0PT67TA1u56tB8EfuFtZXdfMm8UiDeBJl2qnG4jsAID zac56eglo+rJg15QjRx01cCumgbqoHryFhRUK+uqQZvqxcM08l2b9pF/UA8y95Ld1ElcdxqS r+pVGUKZL5pv8urOZ3115yt2JpqpUwn6aUYvM+i3+mT6DZt+nvlr0J8QRabfeNNvvOnPMl3v ekj1MWXDodhnfRvHTZOS5Zve1xb4qt8/e+QFB17O0+tQPa9VdrQuUWm46o7DUTs+43oMJLWe f8b7fJG2Ee4Hdn5yFgQe2Ph66E5nvGHnybEXHtj5xu8ZeGDnh36f8+P6ve3goN+8YedpJ7vw wM5XrtyBB3Z+cDwGHtj5xfESeGDjuZhH3rDzlctT4IGd7xyfgQd2fnGPCDyw8dTPeuQNg/9+ 4z+P+IWG/YbOERl4YOcnt6fAAxvPXSvyhp0v1wgy7HzTtdV5YOcn18rAAz9niPHPGfMqw15F 6KsIefVCL/xjY/fV7p9XAhLPNfCKAz94qwu84M0vHlU2vTC5WF2h8jg3Dfxcdz4+152/av2v rfup/u8yvQYfpBJiWSebnQ2OkY10XkcoZC/xOpOgWvB9K8TCtIEN1WxmdGJUPwrhVUNs8f1m 5R93+bl0ERMrCxX/CciAOplMV2kGeD9vDmgcoKnS5GhOI524U8ApKqROKEePWIIcoN5pAPpU DrYEO0/9OoY0cU3U+mMaLmXxpF0md64AC9vIehwninOXJQfPu98siDXJruVsYvduUYfTDguG YpNVqy42n/piXYRHRT/iequY0QEjRTFg5ldU4QNvk/PdZZO0HLtZEB/2txeWrC1BFNBvBjbF kHWrts2nRqHiLLlUq8aPYEZVje5jbpj4jvMWcK757rKURyyLmwWpplk32y1UVNQhbgY2xZCF VdHmUzMLL17/z3m1LLdxXNE9vmKWpCqEpufVM9nJkpWqVGWRGFVexFlAI4hCPCASAIykfL3P fc4dkDZdLi7AM/fRp7vvq7UvWzzACM+3TknTccyw4gMwjLulw1RbxDo1BvUsiJRrjgeT1hIs ZqrQPTuWhWuPw9mzoJGrRQ5pDFh5Grc8B3taOWQ7BZqOaiepqj4tjfF4qzyNAbqQxgaTKnYh jdVOuQSeIxe9FGjTW9VpA1SBtkO2U2DLi51SE59Ou5IpQ2Q4xEhbofg0oOuJnXIJPMe5duOy O51kVFzSyiVPHXDUUPAZLGnnZOy4pNBVW/BrusJnIkakXNGM71JcdwqmDrMpM7aFxdZYRc6k XFNjCXvQPFftmtrK7Eqhr+RYiGgHVZbied4D0nwWossOwdJhNt08hHXZdOY0Mx6lwwpubJrS QCPP/bDuZQc990mHOBMYGy7XDfqt2YJkLyhXhmglhNssTPQemi0VmuMZ87piqpwWjEf04MQ9 2AaSbp3j1NtSai7mZsHzHJ+H5dyvOL4zrt9FYcrMMglQ72Z5TwPFgdtwXRleTKXif6E/cTvN zH6QoRR31xqe4jOsrq/VZW5J0brme4niIVpH9YlbSButUfcX1j4gq3VQn6R4R+pUcqso9xea mC/0J6medpAHLnxtGw52foA1w7X6JEUsWmOn0Xp+nol1VJ+8jABjHjxI8leGp/i66p6oT5zB mEuDuTTfWe5Pr+6J+iTpwzHAiYelEoPFG6dJS81p1ZQDTyD2wHCso3eDJ2XzFPvorvrXeNZP iSug+zfscpSQhVyxyxE/OcoVu7y3VFN5bzcs8ipZaorcsMuXDzzHLpdBZZYrdnm/eMA5Nnld yk2Y3LDLaystKq/tllWOfIn8Dbs8SxS5XLHJkevxAenY5bE0HWbs8oYno1mu2OV40C7kil0u tcXFAk2KdE5x94ZdjlSL5oZd3kkou1yxy4dl9Bj2aPZCLvLOU1TljYyHLld8nR0uv8qWl7Lr peh8KTpeup0XzgdPTtTuv1zx/vUqIJPwLBcc5Jm6aZAznuUDnpNBzDDUlJJmxsNcUxhf15zD 05rze9n/NrtfXR+nFM4IVmimHsqAqDdzIgC3IS9JO6SxGM9lw8R6731HQ9xc1YDrHKqgm9sO egpHYYixhT7LnFXJOfQy3DAmVNdsQy8wh1keaAHT+81tO3rcmeNOXn4E+VUgwlQKebWcoTg2 bOuqrZIKjEfZZ8+63Mea1K4dEmgSozQEiDPp2VYxZrauKsy0WyfSVb+MZB1+9KgUgdQGS4Xu WLGtq7ZKKjIe5eZ6CYNe+1FlkDz1QnEYFrCyhRi3eEkSDzFFSveF+2VEuoM8cFQ68Jzjlgrd seNBtdlWSUXGo8Si4JpzvUIaGCRQ6SGT7QzLhm0VI9qrqjDThuYP98tI1mkX0qENlgrdsWNZ V22VVGQ8cnIlvyHaQZYdyo0B8UtVr9Og3bZhDQazlUgxzxZHwPyEU+kg71UzVeieFdvCaqus IudRCkbcQy3ToGrXPIK6K4O2kmElYrbC0jzbHmqZaEyKmAl7MOieFdvCaqusIudRauBiDznk Crnq4x4UhpX6uIccMtg9+x60nKoUJxv3oNA9K7aF1VZZRc6jlPW4B7xnwj0AxXswaCsZViJm KyzNs+0BONxD0y/uwaB77hf3YLbKKi/vgTpVx1W2tCGs6g2TK70HHMUMuTnKSopL1h7sHhpB eg8NK7el3QNJgfTg2XSG2ZT1Hnhhs1VWkfM4d1+7h66l9mI7BmrzfBwG7bQM62GarZy0ebZ7 6Pgt6VKcZegqBt2zYltYbZVV5DyiS/93VaP2Yu2GXnFNUdUYoNriLuG9Vg/Fabf6sXhYJe7l s3Efxw2U7iqOGywO80ZPVTwMHFh7MXD0RDxMHC2FZJg42rW8C23iaOm5FiaOgVr+xOMCyfG2 HHjWoC6fDC8mFJlgFvqTdGs+VumSWbQJhsUb6iZL5UnapERVZlttbozDThrdaVSfpEUxTL1O 3ENrOJxLs26Ha/WJu0Mt15B5cdR0erAIXsx1z+hPXJlbPoWSeyuV08bwM2NiVJ9YfWBnvdRT 7SCD3uE8c1bDtfok1UiuIElE9dysBS8n2O6J/iSVoGbcyGOipFhTPIWBGFrX6pMnoS+vqePu 5/lall/o04z7+u25LcZzkfjvPMqHtz/ohx/e8hTMVeRLsWqpY8A/wqOkU6CgQJB2LaXZd69W f5c8qzNHaN2V65po1R1nkGIfrfkzAqGryBupEc3WPtQgn+kHeUyzosGSCvG4MoznZ1OSWI1b 6UTqWxBpQy3P4lxSkXBjhe7bsC2txkYs8h5lu13YR85KSdRzJ4zUmUFfS7BTUWMjKr59H3kQ LyruS17CjBW6b8O2tBobscibaul3m1UuSvxJzFGotHzjm8PqZnO8bKdi93U3Pl72x4fisj/s iv1DcdhPE/C5OH4qxm/jtDvfbv69+n6zjIU2rXMKsSB44mvsaT+1lB46egphwdOsz1u61p+e J92wDZF+87/daXu/Kw67w/H0rdiO4+58dupCt/jp5s3f3mx+ulXefCNNoIRTjIxsR8ZooX7N aGhon1RQEUDE6N23h+1hP2L58+X0OPJRjsfHh0s8S2Ly+n2LDNx8Wt3VGJdRylFFu74rNu9W /7wpb+9Swjbrm/b2rs9pnW4SvrVDhU+ptf+q8vZfm7+uUOrJwR2OpVx6AC320NE/4qGm/649 IMtzJhcIqBaV8PeSIGfq4g5toEs4DK68f4xDnXG9oNLhBx7gAAcFTm2LDwmBkdgzeYFg82pF tqQC26oj/vCcnhiDFBkH0zJ6Ex+v39dyH1W1rkr4wM1W166emrGnpqn5UyOKmJUGIkPjuN3H B8QfaCZ0v+FmBKAtv37faQwknG6nF1Cpt62HbCruV3UlTwX0uxZjUIVenYq7hjsVyvOnVxSX qeTAxI+po7v2mSKzhA8EOp5Tmy/g835//3jaFf2fi81tyjf7af9wX/xnd/p0PB22D+OO0r2/ u3w+7bYfi8PXw1oJa9AOvM7gy2CCACtaBreP9s5rbG7RTjv43hXn/f+RiVusuJ2OWOnyeVd8 vdt+3Z/XxT9258fpItLz5+OXhwIkiq2eUYlZDwMD+XwH73Ut3m8+TMfx591HJDtT3z58ZKfT 9nS/O1lBOD9+OH87X3aHPxUf5DQRNHQKmM+fcfJlf/nMXs6H7TQ96wbrmBv2gKvkOoOUFydQ mc7Hl12t9W5/GQDbqKb/CmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDM5IDAgUiANL1Jlc291cmNlcyAyNiAwIFIgDS9Db250ZW50cyAyNyAw IFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIg XSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL0YyIDQ4IDAgUiAvRjMgNDcgMCBSIC9GNCA1MCAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRvYmoNMjcgMCBvYmoNPDwg L0xlbmd0aCAzMjA3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJfFfLltu4 Ed33V2DZniPRfEiUlKw8nswcJ/YZH1snXshaQCQkISYJBSC7rfnP/E9uoUCRasletNtNgoV6 3Lp1KxGHh9d/fE7EwT0kQouHWMQiT1KxWKXCqof9w3wZzcVinovZai6mSeyf/sKPZ/6f2+eL NBZpNhPTPFuF57+uH17/nopErPcPME/X4Befxn/WNW4+4Gdd0D/PD5vH5StYjePHP9ujsqIw 9UlX+I85tbrWf8lWm8a92q7/CbtZsBuz3VgsctjNV1m0zLzpKJ4vyerju0bIstT0sWiNgOlr g8K1XalVKTTeH7UTJ3lSdvJq/Z+HaRItEWiUzMX6N5hMZwtvsvdsWmqrihbfnqzaq7Y46uYw oT9KXUh6rr6rovNXy6Ykk+tfyM5y5u04s2+fpVXipE+q0g2+Fu5ouqoUsnJG7BRSOVVPsuq8 Ne+h6s0EV5pWfW+F2eMG8fnDGrebQjlnbEQHX0SQz/jmP+EQEtw8qYa8k9Xw2UTchHeVizyY yrLUmxqFLjZpvhUFHIHnnVP7rhJ7Y5F2WEO2caJWtbFnMhiP/UoWK2+sQpxNoZWbCOlEZfAF fvdXCPOk7FHJUnx9LDtF5exfXXKbJGxJN661XeFLPLkgAIGyB2KHgjzrsj1OqDSv4WUhiyG5 UZrOgp1W2b2ycEt9fSWAjxqFqmUVCUqiz/mEgXPxTrvBTJx5M7hTiVK1VtdIuaz+JnQrLrad aAxq2FRn8azbowdpe7SwdTE0ixl7paE00oErzO26ljFDxVMtLHpDhjrpCjBs1l2Boy9pkvId H+8BeJNm202SbzfpcktpQOjS4vYWEOmsrO41TJKG4EtVEXqfjxpVHJVmZD/A5tBJW+Li3Xko aco53BngCKcu/eWQB9lSWpVFVRTsK08dODS6ZDAU0B96DLfx9bgO9W+6qtJ7MEEk3oYOcN4r mGwIzgNq8zwQQpwzSPZT30zWcaa2nmmsbBzgX1OjtdZUcPSkmpKQ5Kj25qYNZhlzVilbOT5N AANMdmc4fDLONxIB6t37j5F4r78NsH1BLO6E+NBU+kkNqQbiDweAztHTPpnjPKWLhMnF57Ho 7Lh/xtW7IN575s03h5GZ/KYVuWLkmtK+VJesUwlAQmVXEOu5rmrdC+CGDxuFW6ke5R0QJ1Ga 862f75DrZgX4LgDjJX6A4hoXPil3l+vz9KXzwoEgyq4iSwiYgq/k6dT34wBls7/kIEvZmxrx 6FOlwGnmhN73fIh8ROKT9HlAeM3YVTrnJgN0c6Y1YngqSwAuXVxTZ50kWrDiLnOK/sLLI1qJ UnCxMg/ehKmB23/zdALeoK+fdGgqRWUHTyDHqMVBu3ZgkShLZj3xO9dRQYBxfH4GVTtTaM8b nn3uzLfoJjMfKDPMSuRKcTX+wGY7NPYLe1e4GOVM7wEOmmLSnu9Nv3TJ7fXBOD8xb7VAqV3R OfdSDdwXA2zsGY0J7OqDbnwSSuX0gVwGBfRZFNSylZpymL5thy5ZcWW/HME4RAtW9uf6ompX E+O6VlcVgdbYVjY0L0B0Qz6z/IKQ0TB3mqAnG2U6jK7rXFuYRr1HnT8PDHmBaxgXPGrNky4v g33k3ORK3cTLvJ80pjscTx3lGmMd9UQ5cZ9k8hoCQYaJJyWobrCymLMnNDOLyEsbK7Xr8Qno KaohixWKxiuNy52DoRU3Mt7SCXldi0j8jofqu6wR7UTsral5uILLwZ1EnENyAtuT1gpWhO2a hgmArHmedi9ARVJmqFIIC1XuGZUa53RCJfB5Lc8Ee8KQlbvKSxwQNHHiSPlFWbwcDfP/ucEN yItI/IqU+0ikOFRmR+puCGfEKQlbwSxAz46TB32FivLQ2VOtfMFC4Z+N/QYlVAzY4+msBASU Bjn7cVAhAW1PjbI2XeNbbjyQyJDvgx+tCclyFWGdgJzfPK7CbvBJVUww+Pinu0CywCzgNePS q+ugq9QPlovb/r/X+XlPgEQNIFmEslPAN+SkQjE1hABa9dBL9sY0U6B3gNGSp+tIPSkw8fur wTCeNQRbBy5X5XRAdRhPQc1yv/Zd7+CUY5+G5QE1+WKqfd+q8bWYjzmk97IWm2y2nYi30oI9 PhT/0k2lzr7DxdopGqILvH4DZWIdtMQdURSS/aYGQ1CbHBV/zsa3/MdbrWyj5Td+o8UmibeT G0GUBXIEgHCzV7NI1do3Ge9tDulBycR1ylhbMcrnYQKTbNd/+dLXXRM0j7/enZsC2G8CDC6y 5u9k5B/rhwR7agYsLZIlaPbOnjtAj48lUb64LLiQnZwQtDopGy8nUPOSZ7z3wAu+Sp4Neo/m BgsTNBQVdMSJXPTKFLLS7dkjQ6HrRkufeOfFQKupzexQKKFoQYiG7k+D1GTE+zbdwfA3+EUe Feei0gUIiQUO5bb2a9nA9BcVgI0GVHNUnYVSwEfkVnE0LFR3qn0mJJJSuR3K+B1zUH8wU42K +IJFK+hcEtU8JIZ9NMAu4TKPvt+kKcDmOnSpj8zhyXzrozuexw+zO8hLkqwvmnkGZkoiQY+O r9CERdX5CTqmM34NZpSFNW68AnKmd2iGgnP8M0HP7d7CZkGzYWj5sAWFAFGmf79/94XhQ8wz 5ZHow3X4VFKnvPN51/a249N5WBXQRWfqHrrakzaco04lu190RdDZJKst3Or8SJDt7dqSB1t9 NkzTqwUn+umCl/D75DuVgD/dkbwcRtqcO73paoWBzyOxkJeloaHviEr7A1QS5xffkaRMwlhE yIIjK3WJz1rBNVOs1Pd70K6jefSMtj9MT9DgV6geryz3lKRPI859tBDNpKxoHBHZe6BcNj9O BRU0dHR5b57EYU+6tDWxN44DGKjyk7T+hr2VtaJruOSyOkB0tsd6ANpqzkDzAFIVjXvgyh9G Ms/+D2io5uCFE9XgFhZ5gMV1CGiSZLbdZNl2k2NzwgaFGYE58IKKb+k7Z8xCt3ZIqGzH+UfP NOAsL8RZwXFczvTBD1ttyl75AcAr1EsHPRU20EyBc7yg8Waj2xGVzLN+3E3EJ1jdKXvgueRn 5CaNaQSaSkGU+sf9ILyTsWzhbW2SpB9tGJ093QokDMMbFML764Dq22TNGAYjNexVv2qc9gSD wUDZa2lPcJhkfFsg4GHeZRwblMWx0f/tFOdmAMTle0gEv+Fxt0Jt1lN6PFhaMsj9OMCUUV7z Q5CDYCYA0rC3ttIeFKNN7PV3CJWxoYv89m/YkimK7oQQzz8SgDRIZ3EazRes/5L41XQO/ffW UCM7qvmP5F82w89yFs1Y/CXLWRB//TrnG4w0v18tfyAFdXO3VwNyqBCFaVr13cta+dM9a6z0 hsVvFvx60/jlZnwIrIUWsY5V/KknmX7lGkwkq1spSTTkIMMtTVOsonoPxGFCP8szJsLv2rp2 IsaCNF7NRtuEY605SAqPsqAz3dm1qiYVYzpb0O64v6qy5GrOuCRxtIwXqAky98j7Er8OFUuj bLni15d5u3kcXUzyDKhp1PSA1Y9qRTMU2EN0JLch0HHCw2CaRckqHyoV7vMy5v91l7tOw0AQ RXu+wiU0ETgQY6VDokNKQco0zu4kWRFs5AdBfD13ZtbetWO6NBnPzuPOuXBEm1FrxQdq1bGa 3TlyOhFgq5g2RB+8eXuI1cG1vUPEKI0S45rhi6O1uCKA4rtyMhCuZVPI222rkvidmCW8SQ1h D/ta8yDvHiMnrL9I3gn/ttLT5CQ315WQR+9wwzrf67CwfyoNkzPwoxP2iM+dvlCVtjAqPDoY 61AcrwzjjRGFE55RkGEzy6cXzrDE7SfL58LVNjDoMsun5zZ2oYLn8ixU6uSOp/Vcox7z/3LB zUfiyCaOb8SKcm6W0D07lqlIfOfu/uBtynDEvIB42yZX7qhoHmvCnJikz6vQ0SAXkY/7xNnE tpkKa/wrxxOv6UTWQ1+9HTWYGjSMFMIxF5uu5k1F8EZPEPMZqwHUvEH7L1zLJJrTh0zFjSse thDiMZ5+fKg8yiU50aCeIUieXfVjKMuVPbmQpEZKlmDrh93dEOpppaG8F4HC1T5cgPzdLRap +lJW4j1VDxOdw4ktAKBjmoS2cY0BGrVjLgmaAKYkU3QNReK28EcedJwUeyeUho9hSzujTLN9 e0GMqkW4sl0jrRQfaqpDeyniYc0npIzxoR/81tGUSkPk7Gw6Lhz5NFPStaQT3mCR6dCdk/lN 4nyWyEfJSagohEp7d9oDZZ/HmekM0mKoZoljvcXOoAm4m7794WGeOnBVTRsjSp+8zNSYbCT+ gDcc6nV78wet08q2CmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmoNPDwgDS9UeXBlIC9QYWdl IA0vUGFyZW50IDQxIDAgUiANL1Jlc291cmNlcyAyOSAwIFIgDS9Db250ZW50cyAzMCAwIFIg DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSAN L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl eHQgXSANL0ZvbnQgPDwgL0YyIDQ4IDAgUiAvRjMgNDcgMCBSIC9GNCA1MCAwIFIgPj4gDS9F eHRHU3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRvYmoNMzAgMCBvYmoNPDwgL0xl bmd0aCA0NTE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlFfbcts4En3X V/TTljIlMgR4n31SZHvGju2oLKWyVZN5gClIwpq3Bck4mq/0S/5nGxdRomSnZh7i2CQIdJ8+ ffqAwGb0/rcFgU0zIiBg5IEHEaEQpxQkH61HYeKGEIcRBGkIDvH001/M40D/OH8eUw+oH4AT +al9/mE5en/lA4HlekTUIR7gf2Y18V3fh2WBh2/w3zIbeS4lISyfR+O2glbkHBrxF/83sHIF X8fB13eQV1Wt3ohyA7hGlJnkrOETkKzdcgntlpXvlv/F7Rziqr0ucFMSmU0lX3UZrhVly6XT bvHTlT1myyRuia8aKCrJgdW1rGopWMthXUm15fIX3MqPfb0VK2Fxt5zAI89Y13AQbR9Lg0Fw fFHyNT6t1vvN93vo7wuOx+yg2TUtLxCrpupkxhtXLXp/RS1g1ABGDWBRmCi0xtPsqayec77a FLxsG/PJGcZxpD7xUzcxGLvEJ/roLxyeqy5fQS6euAJRYfYEN9W2hE8/Lqqy5Hmu4r78X8da kzuCmRwjGhoUljzbllVebQRvJnBdZq4u1VLuNptvHK6qpukKtdWF2IiW5T2MgS0zHiFqlQXM Klm7CmqNnoHDBMdhmtdbBtP/zPvvYxro779x2YiqVEeohXdd3op1Xj1DVhU1FlYa7tzwshRr figjCWP9/bRc4Q6HDS4uZ/CFY01kCQ+84UxmW7hlj5VUSOwGVAhTkwMS5ZtYKUJ2DTyLdguL z9dXTs0ky3OeI4FXGE6NENlTDmTyzQ6L+eVsXeN2SJpsWzD51LgYBrC8qV6r1WEDW4cbvl5L voMLznQqOo2HW527SktyTJ6rGj1vq+YQAPENDIiWphJseV5juKJQSeGBW+yHmtVcurBUv8s9 Js+s6XehNNW7NF1dV7LF7x93+tgvrNkiLi3i2zNlBzOu2m8C94urQyDUcHMjmQrj7nrupJFP 0ziewGz24KTU8xKfTnRG+gG+jaN0clTRRO9wMX2YT0HvA1e+F3nUSWOHOh6l0QQ+3T+APePe 8zwSOAcsA1OMlDo3DvGxGuosuyoNHOIQ4uMWFlsTChs09Robp3rGnGtYy6rAhmh5rpmt+IM8 /Wl7B1GMP1WDP+hylagHg95O9PLErg5il8RqueO5Xqhj/2P8B/nznZOSdDx13zk0RJKOp8ic Ugern6F2x+N7kVU561z4VLeiYLmR1QNjTbAY/7s/lzcYQGACoCGeFPkYBIrAeDq7g8X1bxpB h1I3jRKjEVSLhArLs/ya307v4Qe+nlXl2gXkw1xWWIeiUG1zy8pNxzbYfbwRGxPrdVHnHDnp DABudWADUKjuIhPRBFBCfC958Qny5qYrOZA0STTqTuAGlKqR5fbhqYFnYKMWthsNEWrmeIpI lBPgLXahq+I+kpqsKltZ5bDiNUcBKY1SrVjLjh65GjvqekkcHsFiErm2SVhgievhNDRZqMCI CWxs4HrgWSVXe4laYvtsYVpifXQFdkVtEcUBJBA1LTOIr2OFW299GsAZ+CdUc+MBqCSOX0iS Iqis7BgKIeLqG1yJhxMmPgCL4dMeV/8M1zsM24ruBBaWpfF4jo9R+FiDMW25aa47/ZbiRwsX 4yxcuFAQq1coWM4b+LrEqFHdGbZAi/3eoHAX+s9Gz5hCDQrUOGyxppKNpvpxQagS5ySxEFyJ tYJ8wHe74Pjgvmya7q8V5l/4B8tagYRRNbL9dtwMQ26HbnpUBXOwenZaTRJFLyROFOdzVZs0 tIt7dHonZAsTnBXmQ7XL+Z7ww75Hvel7bI4Kzx7RMtmgDZ7HqVhMh7YkQVb0lHLh9ypvJyZE 7MtXGuRBlBxtU2uY8EWUTasIoyzGRJEvfiNBb8+80CZ4aSlGxx+6TSmq4542FsFZCckzNbZq JUKojJWya6c8eZNvnnWXrxIJLS719zxa8G+6eXEu/MgPWjjFgSpaDKFDEGFhpqiB1WBsKGe3 GiqsAlX7yUEva9A+4dhGyuPzhXaZJxWJUMv7yHST0yB4oWGIUzJrq0c000gkizPWjwRGRvZZ J/F+5kQW6kUP9YxJqWP4aOkVjj+iBeOr3QF2eMyr7Ik9opdvd6odyq7gUmQIAcs31VtwGyOP Lqs4BzvAIPdQd5i9MoGdRuBHSk/0jfgnCkeCF0IDtCVofAqbPbXZB64fDVgW2NTjV1Of9Hlr 6brLPooy5zvrXswUHn9BS9XwcnOESKWmsZ2+zev562FvzAbyw/g0laAePggoU2ieAUPUPvsB M16I73+DhHZ82C+HhE/MWD/l6T8mIfXdkA7KgHr/YjrbvDqtPI3ogJ/BmzrQz6DE1uj2uEba gd707LziUrlCO3gWvXm6Qqnq0BujXPwuMBMFkmKovYGaGrw9iTw7ELSbXkGjSNng90wC/qZn knIKZ+UK3IT0gqvUh6v7xf7+APeiV5E9P9X6U6xORdlUoajdkxujGx1GnSmCn77QAIVgWkuR H80TZEOMFRiYKC/aA52eec9LJDeqOI6+Z6TKVo1+YDWiwfAKgZapyQQKoliLDLBt2A7qPtJf 8cLB3+6BwOoeG9B2ZQykhWk6x4C9D++v5guHRAGsWSHynTsc9MSl6R7q68vLS92NXWunvHl7 Cqy5SPYIKgN0pKQk+DpOv777lSQvFG3oBc/2epKQPVtTOhBTYo2yMvAeohggine9hMyQeaVg T2YU2sf++Fa48Bmvtbu+/40zMt70xPW8bZZsLysqr0TTSvHYqVnYYN34yil4oe69BRYMJ/K5 5OJgSCg5uRIYu5+G+9GR0BMFIQENjwzuP7gPvHYDCN04fsUm4cMz9fDCF3p0N3jTJ3mkv1AR W48jia8wFFYeBpzm+pHQo7KjnkMj/sIfPEd2Kh/a6QbMEEl0f/Jt0fDtpWnDSjsL9ElG4dmu 6trX9D3ux9lJEQZ3rl7U41MTYxI+vxf8zSKQ1I2TEzsRo4qkngHbnGsXndnXnxQi7W0GobYS B8wvxHeBaNzzZ5jNP8Mj3ru2eIt4QqVFUUBrKqsCFvPL2St3WTXTUZ69QxizT3fz2af7/X2W xoNQx+ghsENwsLVKYGqmtHyAQeymMT25i4Z4F0UIrvijtPcmayoulyMCm5GPmIQQUw9FNwAn 8lOQfLT+ZfRhOVJoepCAXYMqHyEzCox2Y3xAj4x/xtEbFy43G4ywt7sLocwsK3nVNcbXtlvJ 2Upr7RTqnLVKLvRMK/n39qcGbMNLPdeRVT+5ReFoOZh+La53IpPVADQcXVEP2SvGM3bp/zkv l63GjSiKzvMVGjpZoLiqVHr0jIB5dHA3q6HDpCeykW2tFpZiSYDzlZ7kf3JvvaTSw016imWj OnXvOftQyq3E4SbaiacOfmFG4irebhHypU+C90w+xtlCsdefrceyLH2Jt6ALOGWVrNNENhm5 n/iwoKlR6PeUbxqD3MKy4G44i72zzvIFxFEhTa3jxZ0AYi7VAsClyVp4qhEIPupKLyMdX/Ci ZdfnGnXtrWTulBl1+bcJh1ziYXDwid9WOwyV2twlxN6/VjLxXjIBw17D+5gZm8dvCLDoH63m BLPRxh3nFSYPA/rYgN1/vbl0lgqMbcV8KIx0ILI7qQyPEZ+aw9Po24RQOH7oHcLIiuXIN5gf BS26wXQ0K+arw9+ZFbsua3ENMynH5CJ+SZ9KuF9AxfUm22MUL+vdDmdCQ5/BmwFDGmqWih8J A8XOtltXUbugOLR0ffI2viddY/Y925RC/8AibvsyPtO35dAfs2VmqI8EPVtWXa/dAO14bM1J lucFmKkk1bR8xi/9qPqM1B7nJY3l760ga3Vs6iXBzesaFG5YoFNLHlrlXrOBdgpgPsuXUAVH lzfpHga5zT6eOL4pW4/57nu5yYs+vlhdtAGYgcVgU3LAQHDO6nUNUQTjywYv6dSimLC3u7fx M5hfvqpeAfScIi1A/q0Mg62TrFZILS/AL2CHT7VoOzBem236d53gUUfxJRSv+dftzeM4NYZu YLLX5hUoIkNMKA6ovtVV5P+SCofgt/YBQJ3R0EChMcPA9Txr6oln9IyG9BT/+kvjjmkm7OAW Zr0S5U3D+SrLX/GErbl/lyGQQHEziX7aEOjUZcTGFM8/cIDiebyXg6SeGMA0Ojpq1IQy7TcY WH6Q50RaJZ9iL/ySVxuw37UM5rlxVfjoMc9gAKD+qTBuZce4M2irxF/LiwrtRTYf1H0BFvEd UjLO1vkO0ud5gFUC1+DrZV7vzNKacTxTsSyfbF8LZdBv8J+3u+h9XRRQeqUtDLQbaR+fC8FR csIfftPpty+r5NmmS+YSv5VncG0+OwTeiXNW7NIMfUC1S+5SzgLrcpiBaKrrzMdmcOFychPh cNyXZFeJfRd8eJolL2BobYuucifdgq3WotjgA6NthuqJ7fwEWnU5TqQdRpq6HrX84gGJCm9F D6z4vDuwZhlQ6SFNI1tTAoTEvv160vJWjaHEFhUH3khKe2hwhZK+bpO9kRWneY5HFKsPQLi0 rLUhHdsCApdPza4KPNTh4JEBaKphmpaDJOi7nDc7HwAL/Y4wxMmBeFSsfitJQsCBDnM3eU/7 ZeMME32TfU/McWcmP/TJoJI1+1Dskqd0GSO4Jm/Jsh4ZHxFhan5E16hLOZeJs9nDUcVa9zeZ uAHRZ6XcLLLxSFFC4lFgAgaOdB5LXU+k6L4b2bY4Qe/kB+7ZODlskkgvjYheT8T58jLeZQIN YW4XIoudBcz5cqP0qkTHehApDMTjfEmEoA+fjlY1BqR/MTs/fYTimuy28K0ywcODES1y8B5o Lyb6jqAENT2A6h7w6D4qE+GT69famvWy1vfT4QkLIhzEhCN3bxxd/JyCaDlRA1UKLt6P7G1x jqxECLsVDOwEpdEBmuOJtpa+r9jb0r/naWi00rXhQd0zm5zDsuSvKPrcVFSdj3jUM5WRV3VR xW4bapKXOKvFufFk8bBuE7NwJuz0yq2SCnls3d8Y7nLPCHeZrobCT67Lqe6J3KOdskLUov5M +g26s164d26iTw8BtJr7pKh+sIrC0Jp51gXmD1NgvgCfxLLdnasRDyZXWQyrs0Nofh7mYnmo GMY9LtNsP5aJ01D+74n6jXiRgaHBXf0DeAjata1JCLiBPtmmIPjnKbBtukqXGhtgQSWB6FHv XTJ3oyZKiKf5UXcSY4yFTd2NLwZgqzDYLQAhITvonuQPBTAY6YnzGYxLXkdIRjaGsCZNw5Hb sOzlfP+0ix3uPCUAFZUA/UyaxFJlfj9JheytWbqZzWbydTw3ivz22xtysBTwzNkp/UDogcG0 fYy3dbxDOwgjeTh/oIY1+BX18OsOBgq03sBviRMTBLLrZAu9qdwPWsI91l2YO81TjrqycrST TRUc4zAJ0IJvLOH3IVA+OPOk2uRPeZav99Jm3mJsT2WPwVikxwelcwY1As4g7wxPCo4bgN96 9MCnGEHZEVcF7ZjuFfd3s/PO9cINGivHj53zu6/Ov/C+TVrO8aYye6SZGwTme24L+7jCPqic vENC3Iwq0yx9YUZ1DuNZZ1mZbBsUeiuyPBUmt9zk6TL5AJtp4NkRpix0T8sSUjHfjt6isiwI RCc1/Ra94whIO+ame4YAEEkD3XnkXVG2e9KAKT5rXdfPtU1wDYg42zUicqDTBjp9pXXkMuaz titMjUczelRqRVGY+bP1GkhB7s11++Hb5GWPq9aV6gh7eirRtJiwK/EbNksUFooPnLlot5p+ sAJjGBKluMkdEfWU8T63vU9eOFxbWxbRgzdlDdDpQaYu77rS1NAo00g/N640w2TIVkJG8VdO gVElp8CiOE9xFTuAd+BE1d7Ji0rLYqhDiGF78EAU6nqIpe7+5uru9uwT7C1pwGMIHlpQpPNP OrrZClytji/RILClmh48rxGK6OrDfNt1vHdoQ1rKZDmEaYX9VMS1WHJoLIDZmg7ibAzYER1D cRSNblXuPMuZS6xJs8cM4reJZmHOD/gCUkCdEvjfL9JSEZz6Snfqql26qLGXDQEZmLvJUEzB bxMP/ZvDzAWkHfRKzdnDL/8NAMcnQrsKZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iag08PCAN L1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDEgMCBSIA0vUmVzb3VyY2VzIDMyIDAgUiANL0NvbnRl bnRzIDMzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAg NjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzIgMCBvYmoNPDwgDS9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjMgNDcgMCBSIC9GNCA1MCAwIFIgPj4gDS9F eHRHU3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDT4+IA1lbmRvYmoNMzMgMCBvYmoNPDwgL0xl bmd0aCAzMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlskb1uwjAUhXc/ xRlDRYztxPnpRukv6lApljoghigxIRWJkTFC7VN26fvUCVQd2sGWdXTv+e7x5WjI7KHgaA6E owVhYEi4QJoLWE02RGZUIpUJ4lwi5GxUr85yPF5/9VQwiChGmET5Rb9RZHYfgUNtSIaBkuFc y2OapFCdRzf+qIowyqNEQJ3IKlhFcj0JY54HBZ2EQjIqggXFqzFTaIdyR6G2GsXL87x4DAX2 1jS27A7XWGxLW1ZO2/ajdK3pUfb1ZK2WRFCWpcPMlAsJdUtCRpkcnicSdNptTW12pmmrcofK 9Ie21nZ0OFA89RP15pPE5yQ88rNLH8a7BEL0NeZ9P1S5rx2K925P4cEL0+2PLhw6w0vHL5yN WG0xt9W2dbpyR6vPkMt3JX5e8QOZwnuK+DNKplgeew2e55IO9XfKb7AhEc//38C3AAMAc/J5 qgplbmRzdHJlYW0NZW5kb2JqDTM0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1R5cGUxIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0 aWNhLUJvbGQgDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlw ZSAvVHlwZTEgDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0NvdXJp ZXIgDT4+IA1lbmRvYmoNMzYgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlw ZTEgDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0NvdXJpZXItQm9s ZCANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBl MSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0aWNhLU9i bGlxdWUgDT4+IA1lbmRvYmoNMzggMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hpdGVQb2ludCBb IDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAyLjIyMjIxIDIuMjIyMjEgXSAN L01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAw LjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNMzkgMCBvYmoNPDwgDS9UeXBl IC9QYWdlcyANL0tpZHMgWyA0NSAwIFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAg UiAxNiAwIFIgMTkgMCBSIDIyIDAgUiAyNSAwIFIgDV0gDS9Db3VudCAxMCANL1BhcmVudCA0 MCAwIFIgDT4+IA1lbmRvYmoNNDAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAz OSAwIFIgNDEgMCBSIF0gDS9Db3VudCAxMiANPj4gDWVuZG9iag00MSAwIG9iag08PCANL1R5 cGUgL1BhZ2VzIA0vS2lkcyBbIDI4IDAgUiAzMSAwIFIgXSANL0NvdW50IDIgDS9QYXJlbnQg NDAgMCBSIA0+PiANZW5kb2JqDTQyIDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDEw MTE1MjIyNDEwKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDQuMCBmb3IgV2luZG93 cykNL01vZERhdGUgKEQ6MjAwMTAxMTUyMjI0MTArMDEnMDAnKQ0+PiANZW5kb2JqDXhyZWYN MCA0MyANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA0ODYyIDAwMDAwIG4NCjAwMDAwMDUw MTMgMDAwMDAgbg0KMDAwMDAwNTEyNiAwMDAwMCBuDQowMDAwMDA4MzE0IDAwMDAwIG4NCjAw MDAwMDg0NjUgMDAwMDAgbg0KMDAwMDAwODU4OSAwMDAwMCBuDQowMDAwMDExODI2IDAwMDAw IG4NCjAwMDAwMTE5NzcgMDAwMDAgbg0KMDAwMDAxMjEyMyAwMDAwMCBuDQowMDAwMDE2Mjg4 IDAwMDAwIG4NCjAwMDAwMTY0NDIgMDAwMDAgbg0KMDAwMDAxNjYxMiAwMDAwMCBuDQowMDAw MDIzNTA2IDAwMDAwIG4NCjAwMDAwMjM2NjAgMDAwMDAgbg0KMDAwMDAyMzc5NiAwMDAwMCBu DQowMDAwMDI5NjA5IDAwMDAwIG4NCjAwMDAwMjk3NjMgMDAwMDAgbg0KMDAwMDAyOTkyMSAw MDAwMCBuDQowMDAwMDM2ODAzIDAwMDAwIG4NCjAwMDAwMzY5NTcgMDAwMDAgbg0KMDAwMDAz NzEwNCAwMDAwMCBuDQowMDAwMDUwMDM5IDAwMDAwIG4NCjAwMDAwNTAxOTMgMDAwMDAgbg0K MDAwMDA1MDM4MiAwMDAwMCBuDQowMDAwMDY0NTA5IDAwMDAwIG4NCjAwMDAwNjQ2NjMgMDAw MDAgbg0KMDAwMDA2NDc4OCAwMDAwMCBuDQowMDAwMDY4MDcwIDAwMDAwIG4NCjAwMDAwNjgy MjQgMDAwMDAgbg0KMDAwMDA2ODM0OSAwMDAwMCBuDQowMDAwMDcyOTQxIDAwMDAwIG4NCjAw MDAwNzMwOTUgMDAwMDAgbg0KMDAwMDA3MzIwOSAwMDAwMCBuDQowMDAwMDczNjIxIDAwMDAw IG4NCjAwMDAwNzM3MzEgMDAwMDAgbg0KMDAwMDA3MzgzMyAwMDAwMCBuDQowMDAwMDczOTQw IDAwMDAwIG4NCjAwMDAwNzQwNTIgMDAwMDAgbg0KMDAwMDA3NDIzMiAwMDAwMCBuDQowMDAw MDc0Mzc2IDAwMDAwIG4NCjAwMDAwNzQ0NTAgMDAwMDAgbg0KMDAwMDA3NDUzOSAwMDAwMCBu DQp0cmFpbGVyDTw8DS9TaXplIDQzDS9JRFs8YjcxNjQ2YTgyOWMyYzA1YTc2NjQyNmI2MzI2 YmMzOTU+PGI3MTY0NmE4MjljMmMwNWE3NjY0MjZiNjMyNmJjMzk1Pl0NPj4Nc3RhcnR4cmVm DTE3Mw0lJUVPRg0= --------------2C040365D21623A5001DE9D8-- From "Marco Al" Mon Jan 15 23:19:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA03715 for ; Tue, 16 Jan 2001 00:07:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 00:07:23 +0100 (MET) Received: (qmail 20217 invoked by uid 0); 15 Jan 2001 22:33:15 -0000 Received: from hi.egroups.com (208.50.99.211) by 10.1.4.106 (mx06) with SMTP; 15 Jan 2001 22:33:15 -0000 X-eGroups-Return: sentto-1101623-2002-979597985-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hi.egroups.com with NNFMP; 15 Jan 2001 22:33:11 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 22:33:03 -0000 Received: (qmail 62496 invoked from network); 15 Jan 2001 22:11:16 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 15 Jan 2001 22:11:16 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 15 Jan 2001 23:12:21 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 6FEAA2F2D for ; Mon, 15 Jan 2001 23:11:15 +0100 (CET) Message-ID: <000501c07f41$333161d0$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 23:19:17 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5c6d68aae717de1ffac609ec9a1aff92 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>


> Hello,
>
> Marco Al a =E9crit :
> >
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> >
> > >  Mostly 99 % of the time with so little vector ! Think = of manipulating
> > > string, or look in to a look up table (with an index),... GC= C the worst
> > > // program ever seen, have an ILP of 3. So you can execute a= n average of
> > > 3 instruction in the same time, so 2 time the same instructi= on (if you
> > > think of 2*32) isn't so hard to find.
> >
> > Actually, with that ILP if I assume even a small number of instru= ctions with
> > evenly distributed independent probabilities (too far fetched?) I= dont see
SIMD
> > making much impact.
> >
>
> Hummmm, Humm, heu, tu le fais expres ou quoi ? Hum, sorry, the remark<= BR> > "too far fetched" give a big doubt : do you really understan= d what SIMD
> means ? SIMD instruction are used by the compiler or the user, so it > have to find the parrallelism. Mostly all "for loop" could b= e rewritten
> to use SIMD instruction, and you can rewritte string function to be > speed up, or all hash function, and many different thing. So compare t= o
> a "normal" 32 bit register a 2*32 bit register program will = be almost
> 100 % quicker.

I said "code without a lot of long loops" a little earlier in the= discussion...
I thought you were trying to say that even more general ILP like superscala= r
processors extract on the fly could be caught by SIMD. Which would be rathe= r
difficult with a semi-random instruction stream.... because instructions wh= ich
could be combined would rarely match up.

> Gcc is the WORST exemple for ILP. The best program could reach 20 or > even more. But reread me, i have soon written that without stack point= er
> dependancy, GCC could reach an ILP of more than 100 !!! So we have to = do
> something to break this.

With SIMD (or VLIW for that matter) everything runs in lock step... say you= have
two nicely behaved loops behind eachother, nice enough so even a C compiler= can
determine if they can be parallelized, one loops X time's the other Y
(determined at runtime). How do you suggest combining that? Compile code fo= r
iterations of loop1, loop1&loop2 and loop3 and at runtime select the co= rrect
one's to execute to get the correct operation? Possible, but thats just 2 loops... codebloat to the extreme and a lot of complexity in determining wh= at
exactly to do at runtime.

Compare that to putting loop1 into a thread and loop2 into another easy to = run
parallel if the resources are present.

> Of course, but it's a more flexible way to do parrallelism, it is find=
> inside in a "function" level, not at the instruction level, = and it's
> different from the process level of usual unix system on mutliproc
> computer. So you use another way to speed the code.

You compile to microthreads just like you compile to SIMD, I didnt mean it = as a
language construct.

> The problem is to use the OS scheduler which is a very slow function > :context switch, write of some stat,  trash the cache memory, the= n you
> load another task. A thread use "user" scheduler wich cost l= ess (no
> cache trash) : switch inside the user application like lightweight
> thread of SUN.

The context switch can be made cheap with tagged TLB's and physically tagge= d
caches. Having the choice of using process level parallelism doesnt mean yo= u
have to, its an option... when you run out of local ILP (which will be a ha= rd
found with legacy code and existing compiler-technology/programming-languag= es)
you look for it more remotely.

> > Just like a good developer can use SIMD effectively themselves th= ey can use
> > existing MMU's efficiently :)
> >
>
> Not really, don't forget than you can pipeline HW not the software (no= t
> in the same way), and HW have a very strong // capabilities.

It was meant sarcastically...

Marco
eGroups Sponsor=
From "Marco Al" Tue Jan 16 00:17:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA03911 for ; Tue, 16 Jan 2001 01:22:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 01:22:52 +0100 (MET) Received: (qmail 16890 invoked by uid 0); 15 Jan 2001 23:29:31 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx10) with SMTP; 15 Jan 2001 23:29:31 -0000 X-eGroups-Return: sentto-1101623-2003-979601313-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 15 Jan 2001 23:29:24 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 15 Jan 2001 23:28:33 -0000 Received: (qmail 79071 invoked from network); 15 Jan 2001 23:09:37 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Jan 2001 23:09:37 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 15 Jan 2001 23:09:36 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 8AA4C2F3B for ; Tue, 16 Jan 2001 00:09:35 +0100 (CET) Message-ID: <000701c07f49$597872e0$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 00:17:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a44e71daeae5c9d288f66a8bf48e3e05 Status: R X-Status: N From: "Marco Al" <marco@simplex.nl>

> The context switch can be made cheap with tagged TLB's and physically
> tagged caches.

I could have phrased that better... its true, but beyond that with a system like
that you can even run different processes concurrently without having explicit
context switches.

Marco
eGroups Sponsor
Click Here!
From art1 Tue Jan 16 09:20:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00341 for ; Tue, 16 Jan 2001 17:38:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:17 +0100 (MET) Received: (qmail 10756 invoked by uid 0); 16 Jan 2001 07:17:29 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx14) with SMTP; 16 Jan 2001 07:17:29 -0000 X-eGroups-Return: sentto-1101623-2004-979629410-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 16 Jan 2001 07:17:20 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 07:16:49 -0000 Received: (qmail 41822 invoked from network); 16 Jan 2001 07:16:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 16 Jan 2001 07:16:47 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta2 with SMTP; 16 Jan 2001 07:16:46 -0000 Received: from art1.none.de (dialin209.pg2-nt.berlin.nikoma.de [213.54.65.209]) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id IAA18536 for ; Tue, 16 Jan 2001 08:17:40 +0100 Received: from art1.none.de (art1@art1.none.de [192.168.42.2]) by art1.none.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA04756 for ; Tue, 16 Jan 2001 09:20:01 +0100 To: f-cpu@egroups.com In-Reply-To: <3A636F16.8C7554DA@ifrance.com> Message-ID: From: art1 MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 09:20:01 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Sponsors for the F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ed38437308f5b1488c5f0a64e34d6007 Status: R X-Status: N Hello,

On Mon, 15 Jan 2001, Nicolas Boulay wrote:

> Very hard question, until now we have to few VHDL to need a good
> computer. But very soon, we will need a good one (a very good one with
> almost 1Go of RAM )! But where can we put this computer ? We need also

GAOS e.V. (see my first mail one/two weeks ago) could be place it. We try
to organise a standard-PC with 1 GB of RAM and enough HD-space.
We are also in search for sponsors for F-CPU.

More information (just in german, we working on translation) about GAOS
e.V. can be read under http://gaos.org

Bye Andreas
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 10:21:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00356 for ; Tue, 16 Jan 2001 17:38:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:21 +0100 (MET) Received: (qmail 14256 invoked by uid 0); 16 Jan 2001 09:28:17 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx07) with SMTP; 16 Jan 2001 09:28:17 -0000 X-eGroups-Return: sentto-1101623-2005-979637277-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 16 Jan 2001 09:28:07 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 09:27:55 -0000 Received: (qmail 22809 invoked from network); 16 Jan 2001 09:27:55 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 Jan 2001 09:27:55 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 16 Jan 2001 09:27:54 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA15607; Tue, 16 Jan 2001 01:27:52 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PKXR; Tue, 16 Jan 2001 10:27:50 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A6412A6.8C13AB46@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 10:21:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 02e830d78e8090c1ab00665aedc12175 Status: R X-Status: N Marco Al wrote:
>
> From: "Marco Al" <marco@simplex.nl>
>
> > The context switch can be made cheap with tagged TLB's and physically
> > tagged caches.
>
> I could have phrased that better... its true, but beyond that with a system like
> that you can even run different processes concurrently without having explicit
> context switches.
>
> Marco

hi,

The VMID is the "tag", but it is manageable by the user.
this means that several thread/task (?) can share the same
logical addressing space. This also means that a trap handler
that calls a user function will not completely thrash the TLB.

But the cache memory is still working with physical addresses only
(on the FC0). This is left undefined for the F-CPU global architecture.

comments ? propositions ? mail them ! :-)
YG
eGroups Sponsor
Click Here!
From Jeff Davies Tue Jan 16 11:33:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00362 for ; Tue, 16 Jan 2001 17:38:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:23 +0100 (MET) Received: (qmail 14969 invoked by uid 0); 16 Jan 2001 10:43:19 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 16 Jan 2001 10:43:19 -0000 X-eGroups-Return: sentto-1101623-2006-979641772-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 16 Jan 2001 10:43:16 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 10:42:51 -0000 Received: (qmail 34065 invoked from network); 16 Jan 2001 10:42:51 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 16 Jan 2001 10:42:51 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta1 with SMTP; 16 Jan 2001 10:42:50 -0000 Received: from modem-187.idaho.dialup.pol.co.uk ([62.137.63.187] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14ITZg-0003TO-00 for f-cpu@egroups.com; Tue, 16 Jan 2001 10:42:49 +0000 Message-ID: <3A642387.F795FD00@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 10:33:43 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1dafa7adcf86d22be976e57703bcfbce Status: R X-Status: N > > I could have phrased that better... its true, but beyond that with a system like
> > that you can even run different processes concurrently without having explicit
> > context switches.
> >
> > Marco
>
> hi,
>
> The VMID is the "tag", but it is manageable by the user.
> this means that several thread/task (?) can share the same
> logical addressing space. This also means that a trap handler
> that calls a user function will not completely thrash the TLB.
>
> But the cache memory is still working with physical addresses only
> (on the FC0). This is left undefined for the F-CPU global architecture.
>
> comments ? propositions ? mail them ! :-)
> YG

What about a fast MMU to RAM transfer mechanism?
I think that there should be the possibility to have not just one VMID controlling the
sharing of
memory when multiple threads are running. I think it is more powerful to have the
ability to
keep a shared space between threads, and threadsafe memory. Also blocks of memory
should be
write protectable.

I think the cache should be on the memory side of the MMU, so physical addresses are
ok.
Jeff Davies
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 12:11:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00365 for ; Tue, 16 Jan 2001 17:38:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:24 +0100 (MET) Received: (qmail 17313 invoked by uid 0); 16 Jan 2001 11:18:11 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 16 Jan 2001 11:18:11 -0000 X-eGroups-Return: sentto-1101623-2007-979643870-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 16 Jan 2001 11:18:03 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 11:17:49 -0000 Received: (qmail 45856 invoked from network); 16 Jan 2001 11:17:49 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 Jan 2001 11:17:49 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 16 Jan 2001 11:17:49 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA24805; Tue, 16 Jan 2001 03:17:47 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PLAJ; Tue, 16 Jan 2001 12:17:45 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A642C69.775C968A@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 12:11:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 69ec77c36b1f3331b02d8851352da939 Status: R X-Status: N Jeff Davies wrote:
>
> > > I could have phrased that better... its true, but beyond that with a system like
> > > that you can even run different processes concurrently without having explicit
> > > context switches.
> > >
> > > Marco
> >
> > hi,
> >
> > The VMID is the "tag", but it is manageable by the user.
> > this means that several thread/task (?) can share the same
> > logical addressing space. This also means that a trap handler
> > that calls a user function will not completely thrash the TLB.
> >
> > But the cache memory is still working with physical addresses only
> > (on the FC0). This is left undefined for the F-CPU global architecture.
> >
> > comments ? propositions ? mail them ! :-)
> > YG
>
> What about a fast MMU to RAM transfer mechanism?
> I think that there should be the possibility to have not just one VMID controlling the
> sharing of
> memory when multiple threads are running. I think it is more powerful to have the
> ability to
> keep a shared space between threads, and threadsafe memory. Also blocks of memory
> should be
> write protectable.
>
> I think the cache should be on the memory side of the MMU, so physical addresses are
> ok.
> Jeff Davies

hi,

first comment : I have banned the term MMU from my vocabulary.
The FC0 is mature enough (it's 20 months old) to not use any "back box"
names. Ther is NO MMU but a TLB.

Second : One year ago, with the help of Sven Klose, we worked on the
TLB.
It has not evolved much since then ... except that i have refined
the usage bit use (16 bits instead of 1).

Proposed structure :
The number of entries is not fixed, but here are given the numbers for
the first
early/cheap implementations. There are 4 page sizes, each having 3 bits
more (or less)
than the other. We start with 4KB, then 32K, 256 and finally 2M pages.
Finally there are "fence" registers that can manage arbitrarily large
pages, as to reduce TLB miss rate with large random access in arrays.
I propose that in the beginning, there are 4 or 8 descriptors of each
size
(20 or 40 parallel comparisons in the TLB). The kernel
is responsible of the use and allocation of the right page size.
It is helped with the use of the "activity" (other name ?) bits.

The page descriptor contains (not exhaustive) :
- present/absent flag. (cleared to invalidate the page).
- size (3 bits : 4/32/256/2M/fence)
- cachability informations
- VMID (16 bits) : it determines a logical address space that can be
shared with other tasks.
- activity : 16 bits. it's in fact : 8x 2-bit saturation counters (0:
unused, 1, 2 : used, 3: used more times).
    the 8 fields are independent : they are addressed by the 8 address
bits just below the limit of
    the  page granularity. For example for a 32K page, the 15LSB are
kept as is and transmitted to the
    memory system while the bits 15..63 are compared in the TLB and
replaced by a physical address. The bits
    12..14 are the number of the "usage" counter that will be
incremented.
    This way, the OS can determine if a smaller page can be used (the
current page is fragmented).
    Note that the activity bits are therefore not used for 4K pages.
- Physical address : bits 15..X where the page is mapped.
- Logical address : bits 15..63 that are compared with the logical
address / pointer to be checked.

Note that the VMID is compared with the value present in the Machine
Status Register.
This way, when a task switch occurs, the VMID can change (or not)
without flushing the TLB.
When the pointers of the new task are checked, they won't be compared to
the entries that
don't match the VMID. I have found a more sophisticated mechanism that
uses less physical bits
(4 VMID can be active at the same time, using a LRU cache, so we need
only 2 bits per TLB entry)
but the principle remains the same.

So yes, 4 VMID can be "active" at the same time (or 8 if you want) but
they're not used at the same time.
OTOH it is meant to reduce the TLB thrashing (and the time spent to
replace the entries) with simple,
predictable and fast mechanisms.

A fast dedicated access to the memory is a complex stuff to do. you have
to ensure that the data is in
the LSU. It might work if you freeze some cache lines but here again,
this is not garanteed because
frozen lines can also spill. If you can reserve a dedicated location and
HW it would work but the
overall performance would not benefit directly from this new dedicated
HW. It benefits only if you
have a lot of TLB misses but otherwise (on code that doesn't trap or
miss) the added HW will not
be useful.

One solution would be to integrate the TLB as a part of the CONTEXT (in
the CMB). but it looks
like a huge stinking can of worms.

let's keep it simple, ok ? let'd see how it works in practice then we'll
enhance what really needs to
be sped up.
eGroups Sponsor
Click Here!
From Michael Riepe Tue Jan 16 03:32:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00380 for ; Tue, 16 Jan 2001 17:38:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:28 +0100 (MET) Received: (qmail 29330 invoked by uid 0); 16 Jan 2001 12:54:40 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx15) with SMTP; 16 Jan 2001 12:54:40 -0000 X-eGroups-Return: sentto-1101623-2008-979649671-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 16 Jan 2001 12:54:39 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 12:54:31 -0000 Received: (qmail 55088 invoked from network); 16 Jan 2001 12:54:30 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 16 Jan 2001 12:54:30 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.219) by mta3 with SMTP; 16 Jan 2001 13:55:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02140; Tue, 16 Jan 2001 03:32:27 +0100 Message-ID: <20010116033227.60155@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <3A624FF9.55B0844F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A624FF9.55B0844F@f-cpu.org>; from Yann Guidon on Mon, Jan 15, 2001 at 02:18:49AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 03:32:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2bb9551c296059502b906a99220820b1 Status: R X-Status: N On Mon, Jan 15, 2001 at 02:18:49AM +0100, Yann Guidon wrote:
[...]
> malloc() etc. are too bound to the kernel/OS : they can't be hardwired.
> they can be eased, but a HW unit would be unused for some cases, which
> make it less interesting. it's like the 2MB segments in the Pentium :
> who uses it ??? it's just wasted transistors...
[...]

Absolutely not.  Linux uses them to create large memory mappings like
video framebuffers, physical memory mapping in the upper 1 GByte range,
and so on.  If you had to map a 32 MByte framebuffer using 4 KByte pages,
you would need 8K page table entries (which means you have to waste 8
perfectly good pages of ordinary RAM for basically nothing), while 4
MByte segments need only 8 entries in the page table directory.

If you map the (former) maximum 1 GByte of RAM using 4 KByte pages, you'll
need 1 MByte of RAM for page tables ONLY.  That's what *I* call "wasted".

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
From "Marco Al" Tue Jan 16 14:08:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00383 for ; Tue, 16 Jan 2001 17:38:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:29 +0100 (MET) Received: (qmail 15216 invoked by uid 0); 16 Jan 2001 13:01:12 -0000 Received: from unknown (HELO fl.egroups.com) (64.211.240.233) by mx0.gmx.net (mx10) with SMTP; 16 Jan 2001 13:01:12 -0000 X-eGroups-Return: sentto-1101623-2009-979650051-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 16 Jan 2001 13:01:09 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 13:00:51 -0000 Received: (qmail 56779 invoked from network); 16 Jan 2001 13:00:50 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 16 Jan 2001 13:00:50 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 16 Jan 2001 14:01:55 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 4E4112F94 for ; Tue, 16 Jan 2001 14:00:49 +0100 (CET) Message-ID: <003201c07fbd$79a58110$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 14:08:53 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 44d8ec8413905e1a9d6641461db5050e Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>

> first comment : I have banned the term MMU from my vocabulary.
> The FC0 is mature enough (it's 20 months old) to not use any "back
> box" names. Ther is NO MMU but a TLB.

Whatever floats your boat.

> The bits 12..14 are the number of the "usage" counter that will be
> incremented. This way, the OS can determine if a smaller page can
> be used (the current page is fragmented). Note that the activity bits
> are therefore not used for 4K pages.

You can try to roll this in with activity monitoring for COMA.

> Note that the VMID is compared with the value present in the
> Machine Status Register.

I think this is a bit restrictive, you dont have to flush... but you still have
to switch to an OS handler a lot. I was thinking more along the lines of X bits
for shared memory spaces (only one space per bit obviously) and a process ID.
Working under the assumption that shared space's (apart from threading, for
which the process ID suffices) are pretty rare.

> This way, when a task switch occurs, the VMID can change (or not)
> without flushing the TLB.
> When the pointers of the new task are checked, they won't be compared to
> the entries that
> don't match the VMID. I have found a more sophisticated mechanism that
> uses less physical bits
> (4 VMID can be active at the same time, using a LRU cache, so we need
> only 2 bits per TLB entry)
> but the principle remains the same.

Transistors are cheap... premature optimisation is the root blah blah.

Marco
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 14:56:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00417 for ; Tue, 16 Jan 2001 17:38:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:47 +0100 (MET) Received: (qmail 22373 invoked by uid 0); 16 Jan 2001 14:03:34 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx14) with SMTP; 16 Jan 2001 14:03:34 -0000 X-eGroups-Return: sentto-1101623-2010-979653778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c9.egroups.com with NNFMP; 16 Jan 2001 14:03:31 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 14:02:57 -0000 Received: (qmail 89066 invoked from network); 16 Jan 2001 14:02:44 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 16 Jan 2001 14:02:44 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 16 Jan 2001 15:03:49 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA07812; Tue, 16 Jan 2001 06:02:41 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PLLY; Tue, 16 Jan 2001 15:02:39 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A64530F.67DAA97C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <3A624FF9.55B0844F@f-cpu.org> <20010116033227.60155@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 14:56:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1bb2aa4a621c8984f7bdac0849f4fe5f Status: R X-Status: N Michael Riepe wrote:
>
> On Mon, Jan 15, 2001 at 02:18:49AM +0100, Yann Guidon wrote:
> [...]
> > malloc() etc. are too bound to the kernel/OS : they can't be hardwired.
> > they can be eased, but a HW unit would be unused for some cases, which
> > make it less interesting. it's like the 2MB segments in the Pentium :
> > who uses it ??? it's just wasted transistors...
> [...]
>
> Absolutely not.  Linux uses them to create large memory mappings like
> video framebuffers, physical memory mapping in the upper 1 GByte range,
> and so on.  If you had to map a 32 MByte framebuffer using 4 KByte pages,
> you would need 8K page table entries (which means you have to waste 8
> perfectly good pages of ordinary RAM for basically nothing), while 4
> MByte segments need only 8 entries in the page table directory.
>
> If you map the (former) maximum 1 GByte of RAM using 4 KByte pages, you'll
> need 1 MByte of RAM for page tables ONLY.  That's what *I* call "wasted".
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

read my precedent mail about the TLB and tell me if i have correctly
understood what "waste" means :-)

other detail : does anyone know how complex it is to use the 2MB segs in the Pentium ?
I want to keep the TLB and the paged system AS SIMPLE AND EASY TO USE as possible.
no fat. just muscles.

YG

speaking for himself
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 15:08:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00424 for ; Tue, 16 Jan 2001 17:38:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:49 +0100 (MET) Received: (qmail 17639 invoked by uid 0); 16 Jan 2001 14:17:54 -0000 Received: from unknown (HELO fl.egroups.com) (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 16 Jan 2001 14:17:54 -0000 X-eGroups-Return: sentto-1101623-2011-979654620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 16 Jan 2001 14:17:17 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 14:16:59 -0000 Received: (qmail 31164 invoked from network); 16 Jan 2001 14:14:37 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 Jan 2001 14:14:37 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 16 Jan 2001 14:14:37 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA08802; Tue, 16 Jan 2001 06:14:35 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PLNF; Tue, 16 Jan 2001 15:14:33 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A6455D9.3CCFECE@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 15:08:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6b228aef066c1fbf5cf494d68e0098b0 Status: R X-Status: N Marco Al wrote:
> From: "Yann GUIDON" <whygee@f-cpu.org>
> > first comment : I have banned the term MMU from my vocabulary.
> > The FC0 is mature enough (it's 20 months old) to not use any "back
> > box" names. Ther is NO MMU but a TLB.
> Whatever floats your boat.
yep but this is not yet clear for even 10% of the people here...

> > The bits 12..14 are the number of the "usage" counter that will be
> > incremented. This way, the OS can determine if a smaller page can
> > be used (the current page is fragmented). Note that the activity bits
> > are therefore not used for 4K pages.
> You can try to roll this in with activity monitoring for COMA.
Can anybody tell me what HW acceleration is required for COMA ?
please answer with physical units such as "adder", "LUT" etc, and
not "manager", "handler"... i'm dumb, i know,
i have no time to be intelligent...

> > Note that the VMID is compared with the value present in the
> > Machine Status Register.
> I think this is a bit restrictive, you dont have to flush...
maybe i wasn't clear...
When the MSR change, the TLB is not cleared.
it goes through the following stages :

* VMID(MSR) is compared with the four latest used VMIDs.
If it is not present, VMID(MSR) takes the place of the
least recently used entry and it flushes the corresponding
TLB entries ...

* it outputs a 2-bit code that is fed to every TLB entry

* this 2-bit code is compared with the 2-bit tag, and the entry is
enable if they match.

* when an address must be checked in the TLB, the entry is enabled
for comparison if the enable tag is ok and if the VMID is ok.

> but you still have to switch to an OS handler a lot.
depends on the case...

> I was thinking more along the lines of X bits
> for shared memory spaces (only one space per bit obviously) and a process ID.
where do you put the X bits ? i don't understand... can you explain it more clearly
for a tired /me ?

> Working under the assumption that shared space's (apart from threading, for
> which the process ID suffices) are pretty rare.
well at least it eases some programming sides...

> > This way, when a task switch occurs, the VMID can change (or not)
> > without flushing the TLB.
> > When the pointers of the new task are checked, they won't be compared to
> > the entries that
> > don't match the VMID. I have found a more sophisticated mechanism that
> > uses less physical bits
> > (4 VMID can be active at the same time, using a LRU cache, so we need
> > only 2 bits per TLB entry)
> > but the principle remains the same.
> Transistors are cheap... premature optimisation is the root blah blah.
it's not a matter of transistor count, but a matter of critical datapath.
It doesn't matter that much if we loose one cycle or two during a task switch,
but it matters if this latency appears everytime you check the TLB.
I have optimized the latency of the most common case. And it is only for the FC0,
it is transparent at the F-CPU level.


Anyway, this and the SHL discussion are very interesting...
it's constructive and instructive :-)


> Marco
YG

speaking for himself
eGroups Sponsor
Click Here!
From "Marco Al" Tue Jan 16 16:33:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00437 for ; Tue, 16 Jan 2001 17:38:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:54 +0100 (MET) Received: (qmail 11583 invoked by uid 0); 16 Jan 2001 15:32:57 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx24) with SMTP; 16 Jan 2001 15:32:57 -0000 X-eGroups-Return: sentto-1101623-2012-979659130-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 16 Jan 2001 15:32:32 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 15:32:09 -0000 Received: (qmail 22403 invoked from network); 16 Jan 2001 15:25:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 16 Jan 2001 15:25:49 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 16 Jan 2001 16:26:54 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 3845C2FE0 for ; Tue, 16 Jan 2001 16:25:48 +0100 (CET) Message-ID: <002c01c07fd1$bab52520$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 16:33:52 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0258a8409728a42e84f87dd2d2d727ba Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>

> Marco Al wrote:
> > From: "Yann GUIDON" <whygee@f-cpu.org>
> > > first comment : I have banned the term MMU from my vocabulary.
> > > The FC0 is mature enough (it's 20 months old) to not use any "back
> > > box" names. Ther is NO MMU but a TLB.
> > Whatever floats your boat.
> yep but this is not yet clear for even 10% of the people here...

Clear? Its a matter of indulgement, I didnt mean I was gonna call the MMU a TLB
:)

> Can anybody tell me what HW acceleration is required for COMA ?
> please answer with physical units such as "adder", "LUT" etc, and
> not "manager", "handler"... i'm dumb, i know,
> i have no time to be intelligent...

I should have said reactive NUMA (which has page migration in common with it).
Its simple, you count accesses to a page. The processor with the most accesses
gets the physical page (with some hysteresis obviously, and the OS checks the
counters).

> maybe i wasn't clear...
> When the MSR change, the TLB is not cleared.
> it goes through the following stages :
>
> * VMID(MSR) is compared with the four latest used VMIDs.
> If it is not present, VMID(MSR) takes the place of the
> least recently used entry and it flushes the corresponding
> TLB entries ...
>
> * it outputs a 2-bit code that is fed to every TLB entry
>
> * this 2-bit code is compared with the 2-bit tag, and the entry is
> enable if they match.
>
> * when an address must be checked in the TLB, the entry is enabled
> for comparison if the enable tag is ok and if the VMID is ok.

How can the enable tag be set if the VMID is not ok?

> > I was thinking more along the lines of X bits
> > for shared memory spaces (only one space per bit obviously) and a process
ID.
> where do you put the X bits ? i don't understand... can you explain it more
clearly
> for a tired /me ?

In the process ID and page table flags, its just a set of bitmapped permission
flags for shared spaces (so if all the bits are 0 its not a shared space).

In your implementation it would be the first X bits of your VMID. The check for
which pages to enable would be split up, any pages belonging to VMID's where an
AND of the first X bits with that of the present VMID was greater than 0 would
get enabled. And of course when the latter bits of the VIMD's exactly match up
they would get enabled too.

> it's not a matter of transistor count, but a matter of critical datapath.

Wont that much sooner go through the check for availability in the cache?

Marco
eGroups Sponsor
Click Here!
From Ben Franchuk Sun Jan 14 09:17:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00450 for ; Tue, 16 Jan 2001 17:38:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:38:57 +0100 (MET) Received: (qmail 13078 invoked by uid 0); 16 Jan 2001 16:07:47 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx09) with SMTP; 16 Jan 2001 16:07:47 -0000 X-eGroups-Return: sentto-1101623-2013-979659824-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 16 Jan 2001 15:44:17 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 15:43:43 -0000 Received: (qmail 50162 invoked from network); 16 Jan 2001 15:35:54 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 Jan 2001 15:35:54 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 16 Jan 2001 15:35:53 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA26529 for ; Tue, 16 Jan 2001 08:29:32 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A6160B0.10B80405@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A562619.D666A28E@ifrance.com> <3A566A23.6851FE40@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 14 Jan 2001 01:17:52 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5f7252351aa19db84022f7882c5b9af3 Status: R X-Status: N Yann GUIDON wrote:

> Proposed structure :
> The number of entries is not fixed, but here are given the numbers for
> the first
> early/cheap implementations. There are 4 page sizes, each having 3 bits
> more (or less)
> than the other. We start with 4KB, then 32K, 256 and finally 2M pages.
> Finally there are "fence" registers that can manage arbitrarily large
> pages, as to reduce TLB miss rate with large random access in arrays.
> I propose that in the beginning, there are 4 or 8 descriptors of each
> size
> (20 or 40 parallel comparisons in the TLB). The kernel
> is responsible of the use and allocation of the right page size.
> It is helped with the use of the "activity" (other name ?) bits.

What is with this 4k (byte) page size? I think this is a relic from a time
when a typical program had 4k words of memory and 8k of code, running 50
students with basic.I think one needs to be better mapped to today's hard
disk sizes as that is what you swap too and segments are bigger.
How about 8k 64k 256k 1meg. I see virtual memory and hard disk file systems
much the same. Both map fixed sized blocks of memory to dynamic sized segments
called files or memory images. Has anything new in disk management that could
be applied to virtual memory? Also I think the way program segments are
mapped out is wrong. data,stack,code is outdated because it the non-static
data that needs to be virtual not on a time based sort.


> let's keep it simple, ok ? let'd see how it works in practice then we'll
> enhance what really needs to
> be sped up.
Good point.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 17:08:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00459 for ; Tue, 16 Jan 2001 17:39:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 17:39:00 +0100 (MET) Received: (qmail 13486 invoked by uid 0); 16 Jan 2001 16:26:52 -0000 Received: from unknown (HELO ei.egroups.com) (64.211.240.237) by mx0.gmx.net (mx24) with SMTP; 16 Jan 2001 16:26:52 -0000 X-eGroups-Return: sentto-1101623-2014-979662385-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 16 Jan 2001 16:26:50 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 16:26:24 -0000 Received: (qmail 64515 invoked from network); 16 Jan 2001 16:14:18 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 Jan 2001 16:14:18 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 16 Jan 2001 16:14:18 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA22124; Tue, 16 Jan 2001 08:14:16 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PLZQ; Tue, 16 Jan 2001 17:14:14 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A6471E5.72477D07@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 17:08:05 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 94e08d5d0d1e55e864993e319b25bc32 Status: R X-Status: N Marco Al wrote:
> From: "Yann GUIDON" <whygee@f-cpu.org>
> > Marco Al wrote:
> > > From: "Yann GUIDON" <whygee@f-cpu.org>
> > Can anybody tell me what HW acceleration is required for COMA ?
> > please answer with physical units such as "adder", "LUT" etc, and
> > not "manager", "handler"... i'm dumb, i know,
> > i have no time to be intelligent...
> I should have said reactive NUMA (which has page migration in common with it).
> Its simple, you count accesses to a page. The processor with the most accesses
> gets the physical page (with some hysteresis obviously, and the OS checks the
> counters).
hey, i CAN undestand that :-)
thx !
so OK for a counter...

> > maybe i wasn't clear...
> > When the MSR change, the TLB is not cleared.
> > it goes through the following stages :
> >
> > * VMID(MSR) is compared with the four latest used VMIDs.
> > If it is not present, VMID(MSR) takes the place of the
> > least recently used entry and it flushes the corresponding
> > TLB entries ...
> >
> > * it outputs a 2-bit code that is fed to every TLB entry
> >
> > * this 2-bit code is compared with the 2-bit tag, and the entry is
> > enable if they match.
> >
> > * when an address must be checked in the TLB, the entry is enabled
> > for comparison if the enable tag is ok and if the VMID is ok.
>
> How can the enable tag be set if the VMID is not ok?

during startup, or when the processor is not yet initialized...
or when a page is being replaced... "we'll optimize later" ;-)

if you want we can compress the VALID flag to 2 bits,
with the ABSENT state represented as 11 (default value after reset)
and the AND of both bits enables the entry. We can still have 3 VMID
in the TLB.

> > > I was thinking more along the lines of X bits
> > > for shared memory spaces (only one space per bit obviously) and a process ID.
> > where do you put the X bits ? i don't understand... can you explain it more clearly
> > for a tired /me ?
> In the process ID and page table flags, its just a set of bitmapped permission
> flags for shared spaces (so if all the bits are 0 its not a shared space).

So for example, you want to reserve 8 or 16 bits,
you define the same number of "sharable" space, and the VMID represents
which space you can access. Is it correct ?

I don't think that it is very efficient.
Using a raw number, one can define any numbre of sharable spaces
which are compiled by the SW into the task's page table.
If zone Z is shared between tasks T1 and T2, the page that maps Z1
will be added in the page table of T1 and T2. If you want to add N
zones, you won't need N bits in the VMID. You will be able to code
2^N intersctions.Now if you add a shared zone to a task, you have
to seek if the intersection already exists so you don't assign two
page table to the same mapping...

> In your implementation it would be the first X bits of your VMID. The check for
> which pages to enable would be split up, any pages belonging to VMID's where an
> AND of the first X bits with that of the present VMID was greater than 0 would
> get enabled. And of course when the latter bits of the VIMD's exactly match up
> they would get enabled too.
I don't get it...
i am a bit confused with the exact meaning.

> > it's not a matter of transistor count, but a matter of critical datapath.
> Wont that much sooner go through the check for availability in the cache?
it's not the point... we speak about the TLB. The cache is another subject.

> Marco

YG

speaking for himself
eGroups Sponsor
Click Here!
From "Marco Al" Tue Jan 16 18:03:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01346 for ; Tue, 16 Jan 2001 23:25:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 23:25:05 +0100 (MET) Received: (qmail 14311 invoked by uid 0); 16 Jan 2001 17:07:06 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx08) with SMTP; 16 Jan 2001 17:07:06 -0000 X-eGroups-Return: sentto-1101623-2015-979664798-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 16 Jan 2001 17:07:05 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 17:06:37 -0000 Received: (qmail 94559 invoked from network); 16 Jan 2001 16:55:36 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 Jan 2001 16:55:36 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 16 Jan 2001 16:55:36 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 2A7742F46 for ; Tue, 16 Jan 2001 17:55:35 +0100 (CET) Message-ID: <000b01c07fde$45a7b560$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 18:03:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 669f166b8ca0564d68a754720eab6728 Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>

> So for example, you want to reserve 8 or 16 bits,
> you define the same number of "sharable" space, and the VMID represents
> which space you can access. Is it correct ?

No shareable spaces are the exception, only a small number of bits of the VMID
would be dedicated to this. The majority would be a normal process ID, which are
checked for exact equivalence.

Its so you can share TLB entries.

> I don't think that it is very efficient.
> Using a raw number, one can define any numbre of sharable spaces
> which are compiled by the SW into the task's page table.
> If zone Z is shared between tasks T1 and T2, the page that maps Z1
> will be added in the page table of T1 and T2. If you want to add N
> zones, you won't need N bits in the VMID. You will be able to code
> 2^N intersctions.Now if you add a shared zone to a task, you have
> to seek if the intersection already exists so you don't assign two
> page table to the same mapping...

I like the concept of SAOS's :) (single address space operating systems) Having
to check for process ID's while checking the tags (because of duplicate entries)
would put a delay in the critical path :(

> > > it's not a matter of transistor count, but a matter of critical datapath.
> > Wont that much sooner go through the check for availability in the cache?
> it's not the point... we speak about the TLB. The cache is another subject.

Do you need an exact exception? The memory access isnt slowed down, only the
security exception.

Marco
eGroups Sponsor
Click Here!
From Yann GUIDON Tue Jan 16 18:42:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01388 for ; Tue, 16 Jan 2001 23:25:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 23:25:16 +0100 (MET) Received: (qmail 20606 invoked by uid 0); 16 Jan 2001 17:57:47 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx02) with SMTP; 16 Jan 2001 17:57:47 -0000 X-eGroups-Return: sentto-1101623-2016-979667846-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 16 Jan 2001 17:57:47 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 17:57:24 -0000 Received: (qmail 2216 invoked from network); 16 Jan 2001 17:48:28 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 16 Jan 2001 17:48:28 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 16 Jan 2001 18:49:33 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA03332; Tue, 16 Jan 2001 09:48:26 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CT77PMCM; Tue, 16 Jan 2001 18:48:24 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A6487F6.2E525D5C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 18:42:14 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c8a1c393d6062d7408956958e8467bf Status: R X-Status: N Marco Al wrote:
> From: "Yann GUIDON" <whygee@f-cpu.org>
> > So for example, you want to reserve 8 or 16 bits,
> > you define the same number of "sharable" space, and the VMID represents
> > which space you can access. Is it correct ?
>
> No shareable spaces are the exception, only a small number of bits of the VMID
> would be dedicated to this.
that's what I understood.

> The majority would be a normal process ID, which are
> checked for exact equivalence.
but then how do you combine the "normal" and "bitmap" access rights ?

> Its so you can share TLB entries.
The current scheme can share the physical or logical address space,
But now i get the point.

> > I don't think that it is very efficient.
> > Using a raw number, one can define any numbre of sharable spaces
> > which are compiled by the SW into the task's page table.
> > If zone Z is shared between tasks T1 and T2, the page that maps Z1
> > will be added in the page table of T1 and T2. If you want to add N
> > zones, you won't need N bits in the VMID. You will be able to code
> > 2^N intersctions.Now if you add a shared zone to a task, you have
> > to seek if the intersection already exists so you don't assign two
> > page table to the same mapping...
>
> I like the concept of SAOS's :) (single address space operating systems) Having
> to check for process ID's while checking the tags (because of duplicate entries)
> would put a delay in the critical path :(

SASOS are OK but they are not the only ones...
Anyway...
The Process' VMID (this ID can be shared) is checked only once, when the
process (or task, whatever) changes. So the critical datapath hshouldn't suffer.

> > > > it's not a matter of transistor count, but a matter of critical datapath.
> > > Wont that much sooner go through the check for availability in the cache?
> > it's not the point... we speak about the TLB. The cache is another subject.
> Do you need an exact exception? The memory access isnt slowed down, only the
> security exception.
Exact exceptions are important, but "clean" exceptions are even more critical.
The exception shouldn't flush things from the pipeline (we don't have any means to
roll-back) and it is primordial.

But the memory access time is another problem.
The physical address is speculatively sent to the cache and the LSU,
and the result is discarded if there's a fault.
Unless you have a better/smarter idea ?

> Marco

YG

speaking for himself
eGroups Sponsor
Click Here!
From "Marco Al" Tue Jan 16 20:52:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01454 for ; Tue, 16 Jan 2001 23:25:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 16 Jan 2001 23:25:34 +0100 (MET) Received: (qmail 1959 invoked by uid 0); 16 Jan 2001 19:58:53 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx17) with SMTP; 16 Jan 2001 19:58:53 -0000 X-eGroups-Return: sentto-1101623-2017-979675119-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 16 Jan 2001 19:58:51 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 16 Jan 2001 19:58:33 -0000 Received: (qmail 58031 invoked from network); 16 Jan 2001 19:44:27 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 16 Jan 2001 19:44:27 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 16 Jan 2001 19:44:27 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 3DE0C2F52 for ; Tue, 16 Jan 2001 20:44:26 +0100 (CET) Message-ID: <001001c07ff5$dc62a020$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 20:52:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a11c03f558bfd98e7152e2b22150f886 Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>


> Marco Al wrote:

> > The majority would be a normal process ID, which are
> > checked for exact equivalence.
> but then how do you combine the "normal" and "bitmap" access rights ?

The "normal" part of the ID is matched with a comparator like always... and if
it matches you always have access.

The output of the AND check on the "bitmap" is OR'd with the normal check.

Basically it would work like this OS side:

The shared space is given its own (normal) ID, each process would also have its
own ID and a subscription list with ID's of shared spaces (more scalable, but
not as suitable for hardware). The OS keeps a mapping of shared ID's to bits in
the "bitmap" and when a process is being made active it uses that to generate
the "bitmap" to enter into the MSR. I originally wasnt really suggesting this
for F0 BTW, just for my general SMT dream processor :)

Marco
eGroups Sponsor
Click Here!
From Alan Grimes Wed Jan 17 02:23:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00360 for ; Wed, 17 Jan 2001 16:09:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:09:49 +0100 (MET) Received: (qmail 28056 invoked by uid 0); 17 Jan 2001 01:38:51 -0000 Received: from hh.egroups.com (208.50.99.210) by 10.1.4.106 (mx06) with SMTP; 17 Jan 2001 01:38:51 -0000 X-eGroups-Return: sentto-1101623-2018-979695475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 17 Jan 2001 01:38:43 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 01:37:54 -0000 Received: (qmail 73166 invoked from network); 17 Jan 2001 01:21:20 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 17 Jan 2001 01:21:20 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta3 with SMTP; 17 Jan 2001 02:22:25 -0000 Received: from 66-44-90-18.s526.tnt2.lnhva.md.dialup.rcn.com ([66.44.90.18] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14IhHr-0001HP-00 for f-cpu@egroups.com; Tue, 16 Jan 2001 20:21:20 -0500 Message-ID: <3A64F420.28F3BF46@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 20:23:44 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] THE MONSTER!!! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ed607386fcb851bcf42b0be2121ee2b Status: R X-Status: N I've begun to breathe new life into THE MONSTER.

This thing is mid-90's vintage FULL TOWER...

Incase you've forgotten, this thing is all steel, has a total of THREE
full-height drive bays... Each one can (theoreticaly) pack in an entire
modern RAID array. =) (It's 3.5x5.25... unfortunately it was cut so
there is only really 3.3 inches of usable height... =(

For all you loosers out there, that means 6 DVD-ROM sized devices...

=P~ 

That's a lot of space...

Below that it has two exposed 3.5 and two hidden...

Below that are card-holders for EIGHT FULL-LENGTH card slots....

A man's case if there ever was one....

Just this afternoon I loaded it with a Passive Backplane..
(unfortunately only the ISA/PICMG slots match the full-length rack in
the back of the case.)

The entire thing is fueled by 250 watts of pure stock power...
(yeah, new procs suck too much juice... At the time an XT would be
comfortably with 150, Average was 200, and this was EXTREEM!!!)

It doesn't appear that there is a 3.3 volt power supply (on the
backplane) for the PCI slots, so that *may* have to come from the PICMG
card... =\

Join FreeProc!!! =)

--
Perhaps I will upgrade my OS from win 3.11...
But It has to be *better* than win 3.11...
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.
eGroups Sponsor
Click Here!
From Jeff Davies Wed Jan 17 10:51:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00411 for ; Wed, 17 Jan 2001 16:10:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:10:02 +0100 (MET) Received: (qmail 2337 invoked by uid 0); 17 Jan 2001 10:01:20 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx05) with SMTP; 17 Jan 2001 10:01:20 -0000 X-eGroups-Return: sentto-1101623-2019-979725664-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 17 Jan 2001 10:01:11 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 10:01:03 -0000 Received: (qmail 78918 invoked from network); 17 Jan 2001 10:01:02 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Jan 2001 10:01:02 -0000 Received: from unknown (HELO cmailg4.svr.pol.co.uk) (195.92.195.174) by mta3 with SMTP; 17 Jan 2001 11:02:07 -0000 Received: from modem-214.aluminum.dialup.pol.co.uk ([62.136.12.214] helo=llandre.freeserve.co.uk) by cmailg4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14IpOh-0001KO-00 for f-cpu@egroups.com; Wed, 17 Jan 2001 10:00:59 +0000 Message-ID: <3A656B1F.9D3F3074@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <002701c07809$112bb610$29e65982@student.utwente.nl> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.com> <003201c07fbd$79a58110$29e65982@student.utwente.nl> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 09:51:27 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: be104c85acecad5f5db78ce66d1eb60b Status: R X-Status: N

> > box" names. Ther is NO MMU but a TLB.
>
> Whatever floats your boat.
>

I thought TLB was a subset of MMU types. Anyway, I suppose anyone not
liking the
way the
TLB works can always substitute their own MMU later. Whatever YG wants,
fine by me,
since
chances are YG will be implementing.

>
> I think this is a bit restrictive, you dont have to flush... but you still have
> to switch to an OS handler a lot. I was thinking more along the lines of X bits
> for shared memory spaces (only one space per bit obviously) and a process ID.
> Working under the assumption that shared space's (apart from threading, for
> which the process ID suffices) are pretty rare.
>

please bear in mind my (work NT) machine only executes kernel code for 5
to 10% of
cpu time
even while heavily used, even including IO, so at this stage, context
switching
shouldn't be
too much of a priority. [ie the core should be optimised for the other
95% first].

YG and progress on barrel shifter?

Jeff Davies
eGroups Sponsor
Click Here!
Click Here!
From Yann GUIDON Wed Jan 17 11:10:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00417 for ; Wed, 17 Jan 2001 16:10:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:10:04 +0100 (MET) Received: (qmail 3468 invoked by uid 0); 17 Jan 2001 10:16:38 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx08) with SMTP; 17 Jan 2001 10:16:38 -0000 X-eGroups-Return: sentto-1101623-2020-979726593-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c9.egroups.com with NNFMP; 17 Jan 2001 10:16:37 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 10:16:33 -0000 Received: (qmail 11326 invoked from network); 17 Jan 2001 10:16:32 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 Jan 2001 10:16:32 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 17 Jan 2001 10:16:32 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA03237; Wed, 17 Jan 2001 02:16:30 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDQ8WQ89; Wed, 17 Jan 2001 11:16:22 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A656F82.15FFF042@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A57E362.1046463B@f-cpu.org> <3A586520.68469E14@ifrance.com> <20010107154644.14953@thrai.stud.uni-hannover.de> <3A590C44.6F355AE2@starpower.net> <20010108020209.12003@thrai.stud.uni-hannover.de> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.com> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A656B1F.9D3F3074@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 11:10:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: adbabb2a663e013b006d9980c929145c Status: R X-Status: N hi,

Jeff Davies wrote:
> > > box" names. Ther is NO MMU but a TLB.
> > Whatever floats your boat.
> I thought TLB was a subset of MMU types.
I still have no precise definition of what a MMU is.
it changes from CPU family to CPU family,
it's not the same in a 68xx, 68K, x86, MIPS...
The ALPHA solves this problem pretty well : it's a TLB.
Otherwise, the older families has microcode that could
fetch data etc, and it's REALLY too complicated. herrrrk.

> Anyway, I suppose anyone not liking the way the
> TLB works can always substitute their own MMU later. Whatever YG wants,
> fine by me, since chances are YG will be implementing.
Whatever. The problem is to find a decent, suitable and efficient
compromise between HW and SW, so it can be implemented easily
in HW and SW. If the OS programmer is too lazy, the "MMU" becomes
a huge mess and never works correctly. Ever seen an Intel errata sheet ?...

Once the first F-CPU chips will be built, i think that it
will be too late to change anything without much impact on the rest.
so let's discuss constructively and find good ideas :-)


> please bear in mind my (work NT) machine only executes kernel code for 5 to 10% of cpu time
> even while heavily used, even including IO, so at this stage, context switching shouldn't be
> too much of a priority. [ie the core should be optimised for the other 95% first].
that's pretty obvious but not for everybody :-)
A first step was done with the SRB. Now we seek other similar good ideas
that can compensate for the reduced size of the TLB.

> YG and progress on barrel shifter?
not much AFAIK.
annoying, ain't it ?

> Jeff Davies
YG

speaking for himself
eGroups Sponsor
Click Here!
Click Here!
From Yann GUIDON Wed Jan 17 11:13:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00423 for ; Wed, 17 Jan 2001 16:10:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:10:06 +0100 (MET) Received: (qmail 7653 invoked by uid 0); 17 Jan 2001 10:20:56 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx10) with SMTP; 17 Jan 2001 10:20:56 -0000 X-eGroups-Return: sentto-1101623-2021-979726787-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 17 Jan 2001 10:20:08 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 10:19:47 -0000 Received: (qmail 18772 invoked from network); 17 Jan 2001 10:19:47 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Jan 2001 10:19:47 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 17 Jan 2001 11:20:52 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA03519; Wed, 17 Jan 2001 02:19:45 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDQ8WQ9L; Wed, 17 Jan 2001 11:19:43 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A657045.5D3C8FC@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A59189B.EC5FD29D@starpower.net> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 11:13:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] networks, bus, topologies, links............. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: afa7027730e1a85dee75fc3c430ee1e2 Status: R X-Status: N Marco Al wrote:
> From: "Yann GUIDON" <whygee@f-cpu.org>
> > Marco Al wrote:
> > > The majority would be a normal process ID, which are
> > > checked for exact equivalence.
> > but then how do you combine the "normal" and "bitmap" access rights ?
>
> The "normal" part of the ID is matched with a comparator like always... and if
> it matches you always have access.
>
> The output of the AND check on the "bitmap" is OR'd with the normal check.
>
> Basically it would work like this OS side:
>
> The shared space is given its own (normal) ID, each process would also have its
> own ID and a subscription list with ID's of shared spaces (more scalable, but
> not as suitable for hardware). The OS keeps a mapping of shared ID's to bits in
> the "bitmap" and when a process is being made active it uses that to generate
> the "bitmap" to enter into the MSR. I originally wasnt really suggesting this
> for F0 BTW, just for my general SMT dream processor :)


Hello,

after a night of reflexion (i slept, too), i have to come to the conclusion
that there must be another better solution. i don't know yet which, but your
proposition is "not good enough" for the F-CPU. If we want a SMT (F-)CPU one
day, we have to prepare the protected memory stuffs with the FC0.

Yet this is an interesting proposition but i still fail to find a good
modification, let's see...

The number of bits in the VMID is reduced and low. it is 16 for the FC0
and wouldn't exceed 32 in larger CPU or systems. So if we include a "bitmap"
it would use 8 or 16 bits, which is not much at all.
In the F-CPU philosophy, /no ressource must be bound/ and this bitmap
is severely limited.


OTOH the purpose is to reduce the TLB thrashing by sharing of TLB entries
between several different tasks (with possibly different VMID). I think that
it's the starting idea that must be investigated. We have to start with the
goal, not the means :-)


ok i'll extrapolate soon/later.


> Marco

YG

speaking for himself
eGroups Sponsor
Click Here!
Click Here!
From Jamil Khatib Wed Jan 17 12:11:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00429 for ; Wed, 17 Jan 2001 16:10:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:10:07 +0100 (MET) Received: (qmail 24105 invoked by uid 0); 17 Jan 2001 11:11:24 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx21) with SMTP; 17 Jan 2001 11:11:24 -0000 X-eGroups-Return: sentto-1101623-2022-979729879-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 17 Jan 2001 11:11:22 -0000 X-Sender: jamilkhatib75@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 11:11:18 -0000 Received: (qmail 15012 invoked from network); 17 Jan 2001 11:11:18 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 17 Jan 2001 11:11:18 -0000 Received: from unknown (HELO web10415.mail.yahoo.com) (216.136.172.140) by mta3 with SMTP; 17 Jan 2001 12:12:23 -0000 Message-ID: <20010117111118.57088.qmail@web10415.mail.yahoo.com> Received: from [199.203.4.26] by web10415.mail.yahoo.com; Wed, 17 Jan 2001 03:11:18 PST To: f-cpu@egroups.com X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 03:11:18 -0800 (PST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] FPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b470ba08dec3edd4f95abdb604d2b5c3 Status: R X-Status: N Hi all,
Are you intrested in adding FPU core to your system?

I am working on one, it should be IEEE compatible.
The code (Adder subtractor only) is ready but I want
to test it using test patterns.

Please let me know if you are intrested
Jamil Khatib


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
eGroups Sponsor
Click Here!
Click Here!
From Yann GUIDON Wed Jan 17 12:44:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00462 for ; Wed, 17 Jan 2001 16:10:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 17 Jan 2001 16:10:18 +0100 (MET) Received: (qmail 7788 invoked by uid 0); 17 Jan 2001 11:51:09 -0000 Received: from mk.egroups.com (208.50.144.76) by 10.1.4.119 (mx19) with SMTP; 17 Jan 2001 11:51:09 -0000 X-eGroups-Return: sentto-1101623-2023-979732241-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 17 Jan 2001 11:50:48 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-6_3_1_3); 17 Jan 2001 11:50:39 -0000 Received: (qmail 47678 invoked from network); 17 Jan 2001 11:50:38 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 17 Jan 2001 11:50:38 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 17 Jan 2001 12:51:43 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA13192; Wed, 17 Jan 2001 03:50:36 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDQ8WRFR; Wed, 17 Jan 2001 12:50:30 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A658593.B3C0B6AA@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <20010117111118.57088.qmail@web10415.mail.yahoo.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 12:44:19 +0100 Reply-To: f-cpu@egroups.com Subject: design constraints (was Re: [f-cpu] FPU) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8f4e451ec5fcf241c3dad9f6859cde4e Status: R X-Status: N Jamil Khatib wrote:
>
> Hi all,
> Are you intrested in adding FPU core to your system?
>
> I am working on one, it should be IEEE compatible.
> The code (Adder subtractor only) is ready but I want
> to test it using test patterns.
>
> Please let me know if you are intrested
> Jamil Khatib

hrllo,

of course we are still interested.
However, In order to be integratd in the FC0,
the design must follow certain design rules
(with some 20% margin but it's already tight...)

- We use VHDL'93 for all the files.
If you use '87 it's still OK, but if you use Verilog,
it must be translated ... (but keep the verilog version)
- the unit should capable of handling 32-b and 64-b data
(well if you only support one format, it's not
severe, the unit can be enhanced later).
it must however be embedded in a "SIMD wrapper"
at the VHDL hierarchical level, so a large SIMD
implementation can be compiled without touching
the execution unit (it is simply replicated).
- no undetermined latency (it must be predictible
at decode time), or if you prefer : no data-dependent
latency.
- no trap (unless you leave a provision to stall
the pipeline until the exception is sure to be avoided)
- the pipeline is made of 4-input logical gates
(it's what maps best to any technology, whether ASIC/FPGA/FullCustom...)
- the critical datapath must not count more than 6 gates
per pipeline stage (if it counts more, split the stage into
finer stages).
- not more than 3 XOR or MUX gates in the CDP (since they
are complex than OR or AND at the transistor level).
The goal is that it takes around 10 transistors of critical
datapath per pipestage.
- Beware of long wires !

For the multiplier, you may require an INT multiplier :
Michael Riepe has already designed one which almost
respect the rules as written above. Get in touch with him
for more details.

I know, the rules are looking very strict. Some are critical
for the scheduler but the others can be worked around for the
first protos. The goal is to have a very high quality and efficient
unit, so it doesn't look like a student's hack...

As for the critical datapath, the goal is to balance the latency
of each stage evenly on all the design, so we don't find situations
where one stage requires 50% more time than the others and forces
to slow down the clock. Since pure clock speed is not the goal for
the protos, it can be left for the future, but if we can make most of
the units compliant from the start, we'll have a well balanced design.


YG

speaking for himself
eGroups Sponsor
Click Here!
Click Here!
From Nicolas Boulay Wed Jan 17 19:56:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02518 for ; Thu, 18 Jan 2001 04:51:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:51:42 +0100 (MET) Received: (qmail 5329 invoked by uid 0); 17 Jan 2001 19:04:21 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx13) with SMTP; 17 Jan 2001 19:04:21 -0000 X-eGroups-Return: sentto-1101623-2025-979758209-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 17 Jan 2001 19:04:13 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_1); 17 Jan 2001 19:03:22 -0000 Received: (qmail 19755 invoked from network); 17 Jan 2001 18:48:29 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 Jan 2001 18:48:29 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 17 Jan 2001 18:48:29 -0000 Received: from ifrance.com (nas22-183.vlt.club-internet.fr [195.36.172.183]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA23354 for ; Wed, 17 Jan 2001 19:48:26 +0100 (MET) Message-ID: <3A65EAE4.53CBFFE9@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <20010108154742.60671@thrai.stud.uni-hannover.de> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 19:56:36 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] smt Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5c402a0e207baa2f99bff878f2596818 Status: R X-Status: N Hello,

Yann GUIDON a =E9crit :
>
> Marco Al wrote:
> > From: "Yann GUIDON" <whygee@f-cpu.org>
> > > Marco Al wrote:
> > > > The majority would be a normal process ID, which are > > > > checked for exact equivalence.
> > > but then how do you combine the "normal" and "= ;bitmap" access rights ?
> >
> > The "normal" part of the ID is matched with a comparato= r like always... and if
> > it matches you always have access.
> >
> > The output of the AND check on the "bitmap" is OR'd wit= h the normal check.
> >
> > Basically it would work like this OS side:
> >
> > The shared space is given its own (normal) ID, each process would= also have its
> > own ID and a subscription list with ID's of shared spaces (more s= calable, but
> > not as suitable for hardware). The OS keeps a mapping of shared I= D's to bits in
> > the "bitmap" and when a process is being made active it= uses that to generate
> > the "bitmap" to enter into the MSR. I originally wasnt = really suggesting this
> > for F0 BTW, just for my general SMT dream processor :)
>
> Hello,
>
> after a night of reflexion (i slept, too), i have to come to the concl= usion
> that there must be another better solution. i don't know yet which, bu= t your
> proposition is "not good enough" for the F-CPU. If we want a= SMT (F-)CPU one
> day, we have to prepare the protected memory stuffs with the FC0.
>
> Yet this is an interesting proposition but i still fail to find a good=
> modification, let's see...
>
> The number of bits in the VMID is reduced and low. it is 16 for the FC= 0
> and wouldn't exceed 32 in larger CPU or systems. So if we include a &q= uot;bitmap"
> it would use 8 or 16 bits, which is not much at all.
> In the F-CPU philosophy, /no ressource must be bound/ and this bitmap<= BR> > is severely limited.
>

I don't think that implemented a memory protection between thread is a
good idea.
- You increase the need of TLB entries (if you make usual thread, Text
(the code itself) page are shared)
- Because you access more different page, as for the TLB you will trash
the cache memory.

The cache is a very hard problem. Don't forget that L2 cache of
PIII/Athlon are direct mapped so if you have more than one thread, you
will destroy all the benefit of the cache. One the worst case, you alwas have a cache miss !

I don't know exactly but it seems that OS have to do some protection
between processes. So here, it will need an overhead of HW to manage
this.

I have speak a little with a professor in my university and i will
receive courses about "automatic parallelisation". So i think tha= t it
could be possible to write good SMT compiler, if the ISA have a good
orthogonality. Also, if you see all the new big project as the kernel
and apache, they all use several threads. So it's a good way to follow.

The other problem is : How many threads ? 4, 8, 16, 32, with more thread the peak performance will be better BUT a poor designed programm will be slow. So a number around 16 will be good for me. We have not to forget
that if the program cache are shared, it's a little bit different for
the data cache. So a lot of thread could make the design of the cache
difficulte.


> OTOH the purpose is to reduce the TLB thrashing by sharing of TLB entr= ies
> between several different tasks (with possibly different VMID). I thin= k that
> it's the starting idea that must be investigated. We have to start wit= h the
> goal, not the means :-)
>
> ok i'll extrapolate soon/later.
>
> > Marco
>
> YG
>
> speaking for himself
nicO
eGroups Sponsor=
3D""
From Nicolas Boulay Wed Jan 17 20:07:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02533 for ; Thu, 18 Jan 2001 04:51:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:51:47 +0100 (MET) Received: (qmail 9343 invoked by uid 0); 17 Jan 2001 19:17:42 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 17 Jan 2001 19:17:42 -0000 X-eGroups-Return: sentto-1101623-2026-979758975-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 17 Jan 2001 19:17:11 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_1); 17 Jan 2001 19:16:12 -0000 Received: (qmail 85413 invoked from network); 17 Jan 2001 18:59:48 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 17 Jan 2001 18:59:48 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 17 Jan 2001 20:00:53 -0000 Received: from ifrance.com (nas22-183.vlt.club-internet.fr [195.36.172.183]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA08948 for ; Wed, 17 Jan 2001 19:59:46 +0100 (MET) Message-ID: <3A65ED8C.14610F3B@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <20010117111118.57088.qmail@web10415.mail.yahoo.com> <3A658593.B3C0B6AA@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 20:07:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: design constraints (was Re: [f-cpu] FPU) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b4c925d53ce3e353f45347c558bd0c07 Status: R X-Status: N reHello,

Yann GUIDON a =E9crit :
>
> Jamil Khatib wrote:
> >
> > Hi all,
> > Are you intrested in adding FPU core to your system?
> >
> > I am working on one, it should be IEEE compatible.
> > The code (Adder subtractor only) is ready but I want
> > to test it using test patterns.
> >
> > Please let me know if you are intrested
> > Jamil Khatib
>
> hrllo,
>
> of course we are still interested.
> However, In order to be integratd in the FC0,
> the design must follow certain design rules
> (with some 20% margin but it's already tight...)
>
> - We use VHDL'93 for all the files.
> If you use '87 it's still OK, but if you use Verilog,
> it must be translated ... (but keep the verilog version)

I repeat myself but only VHDL'87 are supported by Synopsys. So if you
want sone test, soon...

> - the unit should capable of handling 32-b and 64-b data
> (well if you only support one format, it's not
> severe, the unit can be enhanced later).
> it must however be embedded in a "SIMD wrapper"
> at the VHDL hierarchical level, so a large SIMD
> implementation can be compiled without touching
> the execution unit (it is simply replicated).
> - no undetermined latency (it must be predictible
> at decode time), or if you prefer : no data-dependent
> latency.

> - no trap (unless you leave a provision to stall
> the pipeline until the exception is sure to be avoided)
Is that possible for a fpu ?

> - the pipeline is made of 4-input logical gates
> (it's what maps best to any technology, whether ASIC/FPGA/FullCustom..= .)
You speak about the size of the logical gate inside a FPGA (it's
completly wrong for semi-custom ASIC and even more for FullCustom,
because you make your own gates !!!!! ;~) But you HAVE to believe in the synthetiser, think only in multiple of 4 for your entries.

> - the critical datapath must not count more than 6 gates
> per pipeline stage (if it counts more, split the stage into
> finer stages).

Stop, it isn't serious. When Synopsys rerun in my work, it try to
synthetise the multiplier and i give you the number of gate between 2
flip-flop wall. You will receive a very big surprise i think. The only
thing to do is to be constant between the slice.

> - not more than 3 XOR or MUX gates in the CDP (since they
> are complex than OR or AND at the transistor level).
> The goal is that it takes around 10 transistors of critical
> datapath per pipestage.

Hummmmmmmmmm, HUMMM ! A complex flip-flop (with reset and complementary
output) is made by around 40 transistors... So be serious ;p When you
say 6 gates per pipelines stages, i understand 6 gates in the critical
datapath. It's evident ! It is the thing that fix the speed of the unit.
> - Beware of long wires !
>
> For the multiplier, you may require an INT multiplier :
> Michael Riepe has already designed one which almost
> respect the rules as written above. Get in touch with him
> for more details.
>
> I know, the rules are looking very strict. Some are critical
> for the scheduler but the others can be worked around for the
> first protos. The goal is to have a very high quality and efficient > unit, so it doesn't look like a student's hack...
>
> As for the critical datapath, the goal is to balance the latency
> of each stage evenly on all the design, so we don't find situations > where one stage requires 50% more time than the others and forces
> to slow down the clock. Since pure clock speed is not the goal for
> the protos, it can be left for the future, but if we can make most of<= BR> > the units compliant from the start, we'll have a well balanced design.=

To avoid this, the best way is to make a configurable unit, where you
could choose the number of pipeline stage, but i don't think it could be easy.

>
> YG
>
> speaking for himself
nicO
eGroups Sponsor=
3D"Click
3D""
From Yann GUIDON Wed Jan 17 21:23:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02578 for ; Thu, 18 Jan 2001 04:52:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:02 +0100 (MET) Received: (qmail 8505 invoked by uid 0); 17 Jan 2001 20:59:04 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 17 Jan 2001 20:59:04 -0000 X-eGroups-Return: sentto-1101623-2029-979765071-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 17 Jan 2001 20:59:03 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_1); 17 Jan 2001 20:57:33 -0000 Received: (qmail 68308 invoked from network); 17 Jan 2001 20:29:58 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 17 Jan 2001 20:29:58 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 17 Jan 2001 21:31:03 -0000 Received: from svr-frp-exc-01.fra.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA11600; Wed, 17 Jan 2001 12:29:55 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frp-exc-01.fra.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDQ8WSQP; Wed, 17 Jan 2001 21:29:53 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3A65FF4F.A9827BAA@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <20010117111118.57088.qmail@web10415.mail.yahoo.com> <3A658593.B3C0B6AA@mentor.com> <3A65ED8C.14610F3B@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 21:23:43 +0100 Reply-To: f-cpu@egroups.com Subject: nitpicking :-) (was : Re: design constraints (was Re: [f-cpu] FPU)) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0e6931466fce148425045033c720e435 Status: R X-Status: N Nicolas Boulay wrote:
> reHello,
idem

> > - We use VHDL'93 for all the files.
> > If you use '87 it's still OK, but if you use Verilog,
> > it must be translated ... (but keep the verilog version)
> I repeat myself but only VHDL'87 are supported by Synopsys. So if you
> want sone test, soon...
i thought it was discussed already...
anyway, Synopsys is not the ONLY VHDL tool out there,
there are even worse ones ;-P <i know i'm silly when i'm tired...>

> > - no trap (unless you leave a provision to stall
> > the pipeline until the exception is sure to be avoided)
> Is that possible for a fpu ?
There are two things : provide a preliminary flag to the scheduler,
or/and allow for "biased" results that are not fully IEEE.
both are possible and can be selected with the appropriate flag in the
F-CPU ISA. I think that it's not a big problem for a FPU.

> > - the pipeline is made of 4-input logical gates
> > (it's what maps best to any technology, whether ASIC/FPGA/FullCustom...)
> You speak about the size of the logical gate inside a FPGA (it's
> completly wrong for semi-custom ASIC and even more for FullCustom,
> because you make your own gates !!!!! ;~)
a gate designer told me that above 4 inputs, the trade-off between
conductivity and width is not interesting.
For example a AND gate is a number of pass transistors in series.
After 4 trans. passes, the signal is not strong enough.

As for the FPGA and other stuffs, almost everybody does 4-input logic.

> But you HAVE to believe in the
> synthetiser, think only in multiple of 4 for your entries.
Never believe in an automated tool. Never. No trust.
No confidence. It can be "suitable" but nothing else.
Once you know how it is made, you understand...

> > - the critical datapath must not count more than 6 gates
> > per pipeline stage (if it counts more, split the stage into
> > finer stages).
> Stop, it isn't serious. When Synopsys rerun in my work, it try to
> synthetise the multiplier and i give you the number of gate between 2
> flip-flop wall.
MR's multiplier ?

> You will receive a very big surprise i think. The only
> thing to do is to be constant between the slice.
That's one of the goals. The other goal is to have the shortest
useful CDP in every stage.
I know that the goal is a bit extremistic, but it puts some
pressure on the design. it's longer but the result is better.
It forces us to understand what is really being done.

> > - not more than 3 XOR or MUX gates in the CDP (since they
> > are complex than OR or AND at the transistor level).
> > The goal is that it takes around 10 transistors of critical
> > datapath per pipestage.
> Hummmmmmmmmm, HUMMM ! A complex flip-flop (with reset and complementary
> output) is made by around 40 transistors... So be serious ;p When you
> say 6 gates per pipelines stages, i understand 6 gates in the critical
> datapath. It's evident ! It is the thing that fix the speed of the unit.
The FF were not counted of course :-)
but your 40 T are not in the CDP and i've seen much shorter FFs.
But it's not the problem anyway... What matters is what we put between them :-)

> > As for the critical datapath, the goal is to balance the latency
> > of each stage evenly on all the design, so we don't find situations
> > where one stage requires 50% more time than the others and forces
> > to slow down the clock. Since pure clock speed is not the goal for
> > the protos, it can be left for the future, but if we can make most of
> > the units compliant from the start, we'll have a well balanced design.
> To avoid this, the best way is to make a configurable unit, where you
> could choose the number of pipeline stage, but i don't think it could be
> easy.

it is. MR and me did this. it's just a bit of VHDL.
the code should be somewhere near...

> > YG
> nicO
YG

speaking for himself
eGroups Sponsor
Click Here!
From Nicolas Boulay Thu Jan 18 01:29:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02617 for ; Thu, 18 Jan 2001 04:52:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:12 +0100 (MET) Received: (qmail 6767 invoked by uid 0); 18 Jan 2001 00:53:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx05) with SMTP; 18 Jan 2001 00:53:29 -0000 X-eGroups-Return: sentto-1101623-2030-979779170-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 18 Jan 2001 00:53:19 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_1); 18 Jan 2001 00:51:59 -0000 Received: (qmail 29517 invoked from network); 18 Jan 2001 00:21:48 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 18 Jan 2001 00:21:48 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 18 Jan 2001 00:21:48 -0000 Received: from ifrance.com (nas21-127.vlt.club-internet.fr [195.36.171.127]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12854 for ; Thu, 18 Jan 2001 01:21:46 +0100 (MET) Message-ID: <3A663905.D80FF8A5@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> <3A65EAE4.53CBFFE9@ifrance.com> <3A621F6C.BCCE6789@jetne! t.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 18 Jan 2001 01:29:57 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] smt Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: eaab3164f421bf53d79c9657b0b089e1 Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
>
> > The cache is a very hard problem. Don't forget that L2 cache of > > PIII/Athlon are direct mapped so if you have more than one thread= , you
> > will destroy all the benefit of the cache. One the worst case, yo= u alwas
> > have a cache miss !
>
> I would assume you would have one program cache per thread with a
> shared data cache.

It's possible but it's a more complex SRAM memory decoder. But you have
around 64 Ko, or maximum 128 Ko at the L1 level. So you will have 128/16 =3D 8 Ko by thread ! If the cache are shared the 128 Ko could be entierely<= BR> used by each thread.

> Ben.
nicO
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor=
3D""
From Jeff Davies Thu Jan 18 01:15:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02620 for ; Thu, 18 Jan 2001 04:52:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:13 +0100 (MET) Received: (qmail 22575 invoked by uid 0); 18 Jan 2001 00:58:50 -0000 Received: from unknown (HELO mu.egroups.com) (64.211.240.238) by mx0.gmx.net (mx24) with SMTP; 18 Jan 2001 00:58:50 -0000 X-eGroups-Return: sentto-1101623-2031-979779420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 18 Jan 2001 00:57:56 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_1); 18 Jan 2001 00:56:42 -0000 Received: (qmail 38054 invoked from network); 18 Jan 2001 00:24:58 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Jan 2001 00:24:58 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 18 Jan 2001 00:24:57 -0000 Received: from modem-155.chromium.dialup.pol.co.uk ([62.136.23.155] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14J2so-00079t-00 for f-cpu@egroups.com; Thu, 18 Jan 2001 00:24:55 +0000 Message-ID: <3A6635AC.943E5DB5@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> <3A65EAE4.53CBFFE9@ifrance.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 18 Jan 2001 00:15:40 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] smt Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 99c87421fe39305bdb20872134da55a6 Status: R X-Status: N Normally the threads in a process are not protected between themselves, as = they use
(and often need to use
the same process heap etc).

Jeff Davies

Nicolas Boulay wrote:

> Hello,
>
> Yann GUIDON a =E9crit :
> >
> > Marco Al wrote:
> > > From: "Yann GUIDON" <whygee@f-cpu.org>
> > > > Marco Al wrote:
> > > > > The majority would be a normal process ID, which a= re
> > > > > checked for exact equivalence.
> > > > but then how do you combine the "normal" and = "bitmap" access rights ?
> > >
> > > The "normal" part of the ID is matched with a comp= arator like always... and if
> > > it matches you always have access.
> > >
> > > The output of the AND check on the "bitmap" is OR'= d with the normal check.
> > >
> > > Basically it would work like this OS side:
> > >
> > > The shared space is given its own (normal) ID, each process = would also have its
> > > own ID and a subscription list with ID's of shared spaces (m= ore scalable, but
> > > not as suitable for hardware). The OS keeps a mapping of sha= red ID's to bits in
> > > the "bitmap" and when a process is being made acti= ve it uses that to generate
> > > the "bitmap" to enter into the MSR. I originally w= asnt really suggesting this
> > > for F0 BTW, just for my general SMT dream processor :)
> >
> > Hello,
> >
> > after a night of reflexion (i slept, too), i have to come to the = conclusion
> > that there must be another better solution. i don't know yet whic= h, but your
> > proposition is "not good enough" for the F-CPU. If we w= ant a SMT (F-)CPU one
> > day, we have to prepare the protected memory stuffs with the FC0.=
> >
> > Yet this is an interesting proposition but i still fail to find a= good
> > modification, let's see...
> >
> > The number of bits in the VMID is reduced and low. it is 16 for t= he FC0
> > and wouldn't exceed 32 in larger CPU or systems. So if we include= a "bitmap"
> > it would use 8 or 16 bits, which is not much at all.
> > In the F-CPU philosophy, /no ressource must be bound/ and this bi= tmap
> > is severely limited.
> >
>
> I don't think that implemented a memory protection between thread is a=
> good idea.
> - You increase the need of TLB entries (if you make usual thread, Text=
> (the code itself) page are shared)
> - Because you access more different page, as for the TLB you will tras= h
> the cache memory.
>
> The cache is a very hard problem. Don't forget that L2 cache of
> PIII/Athlon are direct mapped so if you have more than one thread, you=
> will destroy all the benefit of the cache. One the worst case, you alw= as
> have a cache miss !
>
> I don't know exactly but it seems that OS have to do some protection > between processes. So here, it will need an overhead of HW to manage > this.
>
> I have speak a little with a professor in my university and i will
> receive courses about "automatic parallelisation". So i thin= k that it
> could be possible to write good SMT compiler, if the ISA have a good > orthogonality. Also, if you see all the new big project as the kernel<= BR> > and apache, they all use several threads. So it's a good way to follow= .
>
> The other problem is : How many threads ? 4, 8, 16, 32, with more thre= ad
> the peak performance will be better BUT a poor designed programm will = be
> slow. So a number around 16 will be good for me. We have not to forget=
> that if the program cache are shared, it's a little bit different for<= BR> > the data cache. So a lot of thread could make the design of the cache<= BR> > difficulte.
>
> > OTOH the purpose is to reduce the TLB thrashing by sharing of TLB= entries
> > between several different tasks (with possibly different VMID). I= think that
> > it's the starting idea that must be investigated. We have to star= t with the
> > goal, not the means :-)
> >
> > ok i'll extrapolate soon/later.
> >
> > > Marco
> >
> > YG
> >
> > speaking for himself
> nicO
eGroups Sponsor=
3D""
From Nicolas Boulay Thu Jan 18 01:18:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02623 for ; Thu, 18 Jan 2001 04:52:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:15 +0100 (MET) Received: (qmail 2545 invoked by uid 0); 18 Jan 2001 01:47:56 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx17) with SMTP; 18 Jan 2001 01:47:55 -0000 X-eGroups-Return: sentto-1101623-2032-979782401-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 18 Jan 2001 01:47:37 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 18 Jan 2001 01:46:41 -0000 Received: (qmail 9979 invoked from network); 18 Jan 2001 00:10:22 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 18 Jan 2001 00:10:22 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta3 with SMTP; 18 Jan 2001 01:11:26 -0000 Received: from ifrance.com (nas21-127.vlt.club-internet.fr [195.36.171.127]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA20654 for ; Thu, 18 Jan 2001 01:10:19 +0100 (MET) Message-ID: <3A663657.186C965D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A556FF8.9C7F626@f-cpu.org> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> <3A65EAE4.53CBFFE9@ifrance.com> <000501c080bc$40d7b7e0$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 18 Jan 2001 01:18:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] smt Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d33c409c56c6247c9de6731a265e9370 Status: R X-Status: N I will begin to understand that you don't read all my messages. It's
completly evident that user defined thread shared the same code by
definition ! So you access the same page of code with different thread.
This has nothing to do with datas !

nicO

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > I don't think that implemented a memory protection between thread= is a
> > good idea.
> > - You increase the need of TLB entries (if you make usual thread,= Text
> > (the code itself) page are shared)
> > - Because you access more different page, as for the TLB you will= trash
> > the cache memory.
>
> Thats not a logical statement... the mere presence of the feature does= not cause
> this.
>
> There is no rule saying that the OS cant be smart enough to only sched= ule
> processes which have "small enough" working sets.
>
> Marco
eGroups Sponsor=
3D""
From "Marco Al" Thu Jan 18 03:01:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02626 for ; Thu, 18 Jan 2001 04:52:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:16 +0100 (MET) Received: (qmail 10816 invoked by uid 0); 18 Jan 2001 02:24:21 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx05) with SMTP; 18 Jan 2001 02:24:21 -0000 X-eGroups-Return: sentto-1101623-2033-979784597-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 18 Jan 2001 02:23:27 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 18 Jan 2001 02:23:16 -0000 Received: (qmail 84597 invoked from network); 18 Jan 2001 01:53:16 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 18 Jan 2001 01:53:16 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 18 Jan 2001 01:53:15 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 2CC652B0E for ; Thu, 18 Jan 2001 02:53:14 +0100 (CET) Message-ID: <003301c080f2$8d9d4870$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A5CD9B2.32B44524@ifrance.com> <3A5DDC28.18084F40@mentor.com> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> <3A65EAE4.53CBFFE9@ifrance.com> <3A6635AC.943E5DB5@llandre.freeserve.co.uk> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 18 Jan 2001 03:01:21 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] smt Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f1205932e9630b6c134a0aadc4fdf870 Status: R X-Status: N From: "Jeff Davies" <jeff@llandre.freeserve.co.uk>

> Normally the threads in a process are not protected between themselves, as
they use

Thats a given.

Hes argueing thats all you should support, and you shouldnt even allow the
possibility of running threads from different protection domains concurrently.

Marco
eGroups Sponsor
Free Horoscopes!
From "Marco Al" Thu Jan 18 03:11:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02629 for ; Thu, 18 Jan 2001 04:52:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 18 Jan 2001 04:52:17 +0100 (MET) Received: (qmail 22859 invoked by uid 0); 18 Jan 2001 02:32:54 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx17) with SMTP; 18 Jan 2001 02:32:54 -0000 X-eGroups-Return: sentto-1101623-2034-979785119-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 18 Jan 2001 02:32:51 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 18 Jan 2001 02:31:59 -0000 Received: (qmail 60341 invoked from network); 18 Jan 2001 02:03:26 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 Jan 2001 02:03:26 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 18 Jan 2001 02:03:25 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 3DDD72B0E for ; Thu, 18 Jan 2001 03:03:24 +0100 (CET) Message-ID: <004301c080f3$f93fa540$29e65982@student.utwente.nl> To: References: <3A556FF8.9C7F626@f-cpu.org> <3A5E1DEB.719AF9CE@ifrance.com> <005e01c07c22$b41940a0$29e65982@student.utwente.nl> <3A5F5C90.DAA2B423@ifrance.com> <000401c07ce9$d4b17e00$29e65982@student.utwente.nl> <3A622629.9DE00110@ifrance.com> <005401c07e87$7fd2f3b0$29e65982@student.utwente.nl> <3A6361E2.CE0E1FA4@ifrance.com> <000501c07f41$333161d0$29e65982@student.utwente.nl> <000701c07f49$597872e0$29e65982@student.utwente.nl> <3A6412A6.8C13AB46@mentor.com> <3A642387.F795FD00@llandre.freeserve.co.uk> <3A642C69.775C968A@mentor.co! m> <003201c07fbd$79a58110$29e65982@student.utwente.nl> <3A6455D9.3CCFECE@mentor.com> <002c01c07fd1$bab52520$29e65982@student.utwente.nl> <3A6471E5.72477D07@mentor.com> <000b01c07fde$45a7b560$29e65982@student.utwente.nl> <3A6487F6.2E525D5C@mentor.com> <001001c07ff5$dc62a020$29e65982@student.utwente.nl> <3A657045.5D3C8FC@mentor.com> <3A65EAE4.53CBFFE9@ifrance.com> <000501c080bc$40d7b7e0$29e65982@student.utwente.nl> <3A663657.186C965D@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 18 Jan 2001 03:11:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] smt Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 93e6934e2838fb1efc93a4e384a1899c Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>


> I will begin to understand that you don't read all my messages. It's
> completly evident that user defined thread shared the same code by
> definition ! So you access the same page of code with different thread.
> This has nothing to do with datas !

Lets try to keep this civil.

User defined threads belonging to the same process will do that, but if you dont
have enough of those you can look to those belonging to other processes.

Marco
eGroups Sponsor
Click Here!
From whygee@mime.up8.edu Fri Jan 19 12:44:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00331 for ; Fri, 19 Jan 2001 16:14:26 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 19 Jan 2001 16:14:26 +0100 (MET) Received: (qmail 14866 invoked by uid 0); 19 Jan 2001 11:45:41 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 19 Jan 2001 11:45:41 -0000 X-eGroups-Return: sentto-1101623-2035-979904678-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 19 Jan 2001 11:45:34 -0000 X-Sender: whygee@mime.univ-paris8.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 19 Jan 2001 11:44:38 -0000 Received: (qmail 73862 invoked from network); 19 Jan 2001 11:44:37 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 19 Jan 2001 11:44:37 -0000 Received: from unknown (HELO or.mime.univ-paris8.fr) (193.54.153.27) by mta3 with SMTP; 19 Jan 2001 12:45:41 -0000 Received: from nickel.mime.univ-paris8.fr (nickel.mime.univ-paris8.fr [193.54.153.6]) by or.mime.univ-paris8.fr (8.9.3/8.9.3) with ESMTP id MAA29286 for ; Fri, 19 Jan 2001 12:44:33 +0100 (CET) Received: (from whygee@localhost) by nickel.mime.univ-paris8.fr (8.11.0/8.11.0) id f0JBiV112343 for f-cpu@egroups.com; Fri, 19 Jan 2001 12:44:31 +0100 (MET) Message-Id: <200101191144.f0JBiV112343@nickel.mime.univ-paris8.fr> X-eGroups-From: whygee@mime.univ-paris8.fr From: whygee@mime.up8.edu MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 19 Jan 2001 12:44:31 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: [f-cpu] (unknown) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 661463ae9a590101b25c809ea1e118ed Status: R X-Status: N SIMILI UPDATE !

http://www.symphonyeda.com/proddownloads.htm
the new version is meant to support larger designs.
It will be very useful :-)
No indication about when the Linux port will be ready though.

YG
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann Guidon Sat Jan 20 00:22:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00415 for ; Sat, 20 Jan 2001 05:23:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 05:23:39 +0100 (MET) Received: (qmail 14257 invoked by uid 0); 19 Jan 2001 23:17:07 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx07) with SMTP; 19 Jan 2001 23:17:07 -0000 X-eGroups-Return: sentto-1101623-2036-979946196-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fg.egroups.com with NNFMP; 19 Jan 2001 23:16:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 19 Jan 2001 23:16:35 -0000 Received: (qmail 32279 invoked from network); 19 Jan 2001 23:16:34 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Jan 2001 23:16:34 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta3 with SMTP; 20 Jan 2001 00:17:38 -0000 Received: from f-cpu.org (nas4-99.ras.club-internet.fr [195.36.203.99]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA21468; Sat, 20 Jan 2001 00:16:19 +0100 (MET) Message-ID: <3A68CC2C.535BC91F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 00:22:20 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] conferences Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 54ea0a359ba89e770e187812234e7ffc Status: R X-Status: N hello,

i have just asked for information about a call for paper
about electronic design etc. for a conference held in california
in april. I'm waiting for additional informations next week.
I don't do that for the fun and the sun, but for spreading the
informations etc. about the f-cpu : such conferences are good ways
to become widely known and heard, to enter in the books and
create some proofs of prior art.

If you hear about such a conference, please let the group know.
I don't know whether i'll be able to go to calif. (Munich & Darmstadt
in a month is a bit much for me) so if someone can attend it, please
let us know :-) I hope that Peter is still listening...

It's curious that, even though almost everything about the F-CPU
is happening in Europe, most of the "real stuff" is coming from the US...

OK, i have to check the french translation of the manual.
please don't stay mute and let's discuss about the shift unit :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Michael Riepe Sat Jan 20 01:12:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA00426 for ; Sat, 20 Jan 2001 05:23:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 05:23:42 +0100 (MET) Received: (qmail 3545 invoked by uid 0); 20 Jan 2001 00:14:54 -0000 Received: from unknown (HELO fk.egroups.com) (64.211.240.232) by mx0.gmx.net (mx16) with SMTP; 20 Jan 2001 00:14:54 -0000 X-eGroups-Return: sentto-1101623-2037-979949685-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 20 Jan 2001 00:14:53 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 00:14:44 -0000 Received: (qmail 57091 invoked from network); 20 Jan 2001 00:14:42 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Jan 2001 00:14:42 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.102) by mta2 with SMTP; 20 Jan 2001 00:14:27 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA06431; Sat, 20 Jan 2001 01:12:36 +0100 Message-ID: <20010120011236.44776@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A68CC2C.535BC91F@f-cpu.org>; from Yann Guidon on Sat, Jan 20, 2001 at 12:22:20AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 01:12:36 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cc6cc6c211694ed603e44e1f88e61aef Status: R X-Status: N On Sat, Jan 20, 2001 at 12:22:20AM +0100, Yann Guidon wrote:
[...]
> please don't stay mute and let's discuss about the shift unit :-)

I'm working on a proposal (no I do NOT volunteer to do the SHL unit
myself, at least not at the moment -- I want to get the integer arithmetic
stuff done first).

The basic idea is to cut the input into 8-bit chunks, extend them
to 16 bits (in the shifting direction) and shift them by 0...7 bits
in the first stage.  In the second stage, the partial results can be
ORed together one way or another; this allows SIMD operations as well
as several operating modes: so far it should be able to do shiftl,
shiftr, shiftra, rotl, rotr, bitrev and byterev.  Higher-order shifts
(by multiples of 8 bits) are also done in the second part.

I have no working VHDL yet, and I can't tell you how fast this unit is
going to be (I'm afraid it won't fit into a single pipeline stage either).

BTW, I encountered another open question: when doing SIMD shifts, is
the second operand a SIMD operand, too?  Or will all chunks be shifted
by the same number of bits?  My unit will do the latter, but the former
might be interesting, too.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Ben Franchuk Tue Jan 16 06:12:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA01327 for ; Sat, 20 Jan 2001 09:07:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 09:07:31 +0100 (MET) Received: (qmail 9559 invoked by uid 0); 20 Jan 2001 06:35:15 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx17) with SMTP; 20 Jan 2001 06:35:15 -0000 X-eGroups-Return: sentto-1101623-2038-979972490-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 20 Jan 2001 06:35:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 06:34:49 -0000 Received: (qmail 42217 invoked from network); 20 Jan 2001 06:34:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 Jan 2001 06:34:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 20 Jan 2001 06:34:47 -0000 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id XAA23889 for ; Fri, 19 Jan 2001 23:28:01 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A63D852.AC4F2DD@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 22:12:50 -0700 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1607222e0de2bddf78e94a0507cef5be Status: R X-Status: N In a RISC machine like the F-CPU does a cache work?
Is multi stage pipelining practical?
Reading elsewhere that the latest generation of FPGA's are super
large and fast (and low voltage 1.5 volts) the chip designs remind
me more and more of the 1st generation of tube computers
that used a magnetic drum or CRT storage block serial memory
and core memory with read then write back.
Both pipelining and cache and virtual memory control use a large
amount of cpu resources and little savings because most programs
don't loop and data is too random to be cached. If say small 32 word
register program history and 16 word address cache for virtual memory
and a single stage of pipeline is used you may have average quality
single CPU but because the design is small you may duplicate the
CPU several times to give a fast multiprocessing cpu?
I think a cache and pipelining and virtual memory
are still useful but I don't think current form used now will
be useful when you want to go past 500 MHZ.
Ben. 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From art1 Sat Jan 20 11:18:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA01504 for ; Sat, 20 Jan 2001 10:29:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 10:29:14 +0100 (MET) Received: (qmail 9851 invoked by uid 0); 20 Jan 2001 09:13:45 -0000 Received: from hk.egroups.com (208.50.99.220) by 10.1.4.119 (mx19) with SMTP; 20 Jan 2001 09:13:45 -0000 X-eGroups-Return: sentto-1101623-2039-979981996-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 20 Jan 2001 09:13:44 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 09:13:16 -0000 Received: (qmail 28662 invoked from network); 20 Jan 2001 09:13:15 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 20 Jan 2001 09:13:15 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta1 with SMTP; 20 Jan 2001 09:13:15 -0000 Received: from art1.none.de (dialin36.pg4-nt.berlin.nikoma.de [213.54.67.36]) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id KAA18474 for ; Sat, 20 Jan 2001 10:14:30 +0100 Received: from art1.none.de (art1@art1.none.de [192.168.42.2]) by art1.none.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA02583 for ; Sat, 20 Jan 2001 11:18:17 +0100 To: f-cpu@egroups.com In-Reply-To: <20010120011236.44776@thrai.stud.uni-hannover.de> Message-ID: From: art1 MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 11:18:17 +0100 (CET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1aefa3c78e48a8e914aa55bb07fac294 Status: R X-Status: N Hello,
> I'm working on a proposal (no I do NOT volunteer to do the SHL unit
> myself, at least not at the moment -- I want to get the integer arithmetic
> stuff done first).

I want to do it, but my questions were not answered.

> BTW, I encountered another open question: when doing SIMD shifts, is
> the second operand a SIMD operand, too?  Or will all chunks be shifted
> by the same number of bits?  My unit will do the latter, but the former
> might be interesting, too.

I suggested an unit with support for all kinds of shift/rotate
(arithmetic, logic), direction (left/right), shift-counter (how many
shifts?), SIMD-operation (8x8bit, 4x16bit, 2x32bit, 1x64bit chunks). The
shiftcounter has a size of 8x3bit=24bit to to individual shiftsize per
chunk. It is an idea, that it could more useful and flexible way as an
SIMD-operation with same shifts (shiftcounter has 6bits) on all chunks.

I want to play with it in Altera, if it useful, I message you...

Bye Andreas


eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From polz@writeme.com Sat Jan 20 11:30:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00299 for ; Sat, 20 Jan 2001 22:19:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:30 +0100 (MET) Received: (qmail 29887 invoked by uid 0); 20 Jan 2001 10:46:54 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx01) with SMTP; 20 Jan 2001 10:46:54 -0000 X-eGroups-Return: sentto-1101623-2040-979987611-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 20 Jan 2001 10:46:52 -0000 X-Sender: polz@writeme.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 10:46:50 -0000 Received: (qmail 35604 invoked from network); 20 Jan 2001 10:46:50 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 20 Jan 2001 10:46:50 -0000 Received: from unknown (HELO razor.arnes.si) (193.2.1.80) by mta1 with SMTP; 20 Jan 2001 10:46:50 -0000 Received: from mojastwar.burek.net (kr2-14a.dial-up.arnes.si [194.249.3.141]) by razor.arnes.si (Postfix) with ESMTP id A1C9316ED02 for ; Sat, 20 Jan 2001 11:46:47 +0100 (MET) Received: from localhost (mojastwar.burek.net) [127.0.0.1] (polz) by mojastwar.burek.net with esmtp (Exim 3.11 #1 (Debian)) id 14JvI8-0000Xz-00; Sat, 20 Jan 2001 11:30:40 +0100 X-Mailer: exmh version 2.1.1 10/15/1999 (debian) To: f-cpu@egroups.com In-reply-to: Your message of "Mon, 15 Jan 2001 22:12:50 MST." <3A63D852.AC4F2DD@jetnet.ab.ca> References: <3A63D852.AC4F2DD@jetnet.ab.ca> Message-Id: From: polz@writeme.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 11:30:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ef6474e6ae6f78bfad14979c65db910 Status: R X-Status: N
> Both pipelining and cache and virtual memory control use a large
> amount of cpu resources and little savings because most programs
> don't loop and data is too random to be cached.
Unless everything they've been teaching me for the last 3 months is wrong,
the cache hit probability in a modern CPU is usually somewhere between
90% and 99%. I would not call shis a little saving.
Pipelining is used so the parts of the CPU which would just wait and do
nothing most of the time in a single-stage CPU get used more often.
Fetching, decoding and executing an instruction takes a certain ammount and
at least a few clock cycles. In each stage of this process only one
part of the CPU is used. Pipelining lets you use the other parts at
the same time so pipelining is a good thing.

> If say small 32 word
> register program history and 16 word address cache for virtual memory
> and a single stage of pipeline is used you may have average quality
> single CPU but because the design is small you may duplicate the
> CPU several times to give a fast multiprocessing cpu?
You can also duplicate a small pipelined CPU with cache and make a VLIW
"multiprocessing" CPU. I beleive that's basically what the smart people
on this list are doing.

I suggest you take a class on computer architecture keep lurking on this list
untill you can give well thought-out, meaningfull suggestions. I know that's what
I intend to do.

/me burries himself just like a nice little lurker should.
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann Guidon Sat Jan 20 14:55:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00329 for ; Sat, 20 Jan 2001 22:19:39 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:39 +0100 (MET) Received: (qmail 20795 invoked by uid 0); 20 Jan 2001 13:49:58 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx22) with SMTP; 20 Jan 2001 13:49:58 -0000 X-eGroups-Return: sentto-1101623-2041-979998594-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 20 Jan 2001 13:49:56 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 13:49:53 -0000 Received: (qmail 6635 invoked from network); 20 Jan 2001 13:49:53 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 20 Jan 2001 13:49:53 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 20 Jan 2001 13:49:52 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA14655 for ; Sat, 20 Jan 2001 14:49:49 +0100 (MET) Message-ID: <3A6998E8.C494D870@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 14:55:52 +0100 Reply-To: f-cpu@egroups.com Subject: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 28aafc8f1316746c0aa4edb9071108c3 Status: R X-Status: N hello,

Michael Riepe wrote:
> On Sat, Jan 20, 2001 at 12:22:20AM +0100, Yann Guidon wrote:
> > please don't stay mute and let's discuss about the shift unit :-)
> I'm working on a proposal (no I do NOT volunteer to do the SHL unit
> myself, at least not at the moment -- I want to get the integer arithmetic
> stuff done first).
hey, i don't want to drown you with work :-)

> The basic idea is to cut the input into 8-bit chunks, extend them
> to 16 bits (in the shifting direction) and shift them by 0...7 bits
> in the first stage.  In the second stage, the partial results can be
> ORed together one way or another; this allows SIMD operations as well
> as several operating modes: so far it should be able to do shiftl,
> shiftr, shiftra, rotl, rotr, bitrev and byterev.  Higher-order shifts
> (by multiples of 8 bits) are also done in the second part.
that seems to be one of the best ways : either do 3 stages with 4x4
switches, or 2 stages with 8x8 switches. 2*8 looks like the way to go
because the SHL unit can be split (beware of the number of partial result
bits, though).

> I have no working VHDL yet, and I can't tell you how fast this unit is
> going to be (I'm afraid it won't fit into a single pipeline stage either).
well, if this can be done cleanly, it's ok.

> BTW, I encountered another open question: when doing SIMD shifts, is
> the second operand a SIMD operand, too?  Or will all chunks be shifted
> by the same number of bits?  My unit will do the latter, but the former
> might be interesting, too.
This question has been raised long ago, during a discussion with Thilo Reichelt.
I think that the operation was called "permute" or something like that.
In fact that possibilities are so large that it's difficult to make
a good first decision. In particular, the SIMD words are not fixed-size
and the extension to 1024 or even 65536 bits is not often straight-forward.

We'll have to complete the Instruction Set Census and examine the possibilities.
We have enough free room in the ISA anyway so we can add interesting extensions :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

then art1 wrote:
> Hello,
> > I'm working on a proposal (no I do NOT volunteer to do the SHL unit
> > myself, at least not at the moment -- I want to get the integer arithmetic
> > stuff done first).
> I want to do it, but my questions were not answered.
sorry if i didn't answer... i was overflowed with emails this week.
But i think that other people can give you some answers.

> > BTW, I encountered another open question: when doing SIMD shifts, is
> > the second operand a SIMD operand, too?  Or will all chunks be shifted
> > by the same number of bits?  My unit will do the latter, but the former
> > might be interesting, too.
> I suggested an unit with support for all kinds of shift/rotate
> (arithmetic, logic), direction (left/right), shift-counter (how many shifts?),
sorry, what is "shift-counter" ? is it related to the LSB-seeking capability of
the INC unit ?

> SIMD-operation (8x8bit, 4x16bit, 2x32bit, 1x64bit chunks).
don't forget that SIMD is "undetermined size". the sizes you give are for a particular
implementation.

> The shiftcounter has a size of 8x3bit=24bit to to individual shiftsize per
> chunk. It is an idea, that it could more useful and flexible way as an
> SIMD-operation with same shifts (shiftcounter has 6bits) on all chunks.
And what if, one day, the registers are 128-bit or 256-bit wide ?
And how do you manage the 3-bit fields in the registers ?
frankly, i doubt that 512-bit versions will appear soon, so the shiftcount
can be 8-bit wide. This lets us use byte-wide SIMD chunks.

> I want to play with it in Altera, if it useful, I message you...
have fun and keep us informed !

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann Guidon Sat Jan 20 14:55:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00332 for ; Sat, 20 Jan 2001 22:19:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:41 +0100 (MET) Received: (qmail 8058 invoked by uid 0); 20 Jan 2001 13:49:58 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx14) with SMTP; 20 Jan 2001 13:49:58 -0000 X-eGroups-Return: sentto-1101623-2042-979998596-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 20 Jan 2001 13:49:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 13:49:56 -0000 Received: (qmail 44889 invoked from network); 20 Jan 2001 13:49:56 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 20 Jan 2001 13:49:56 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 20 Jan 2001 14:51:00 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA14671 for ; Sat, 20 Jan 2001 14:49:53 +0100 (MET) Message-ID: <3A6998EC.4A083CAC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 14:55:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2eea97b8e317250add62183258d20ae5 Status: R X-Status: N hi !
it looks like an interesting thread ;-)

OK i remember our dear lurker ("polz" ?) that Ben
might be in the computer world well before we knew it
existed, just look at http://www.jetnet.ab.ca/users/bfranchuk
and you will understand his background.
His perspective is interesting because sometimes, we might
believe that we have invented something incredible and new,
but in fact it was discovered long ago...
Sometimes he has some little problems to understand
some concepts but it doesn't mean that he's dumb :-)

polz@writeme.com wrote:
> > Both pipelining and cache and virtual memory control use a large
> > amount of cpu resources and little savings because most programs
> > don't loop and data is too random to be cached.
> Unless everything they've been teaching me for the last 3 months is wrong,
> the cache hit probability in a modern CPU is usually somewhere between
> 90% and 99%. I would not call shis a little saving.
Now, it's up to you to make your own measurements and see that
it's never so simple. some codes can fit entirely in a cache,
while some others will never do. At least, the cache is here to catch
what can be caught. With the help of some specific algorithms,
one can significantly multiply the speed of a code that is "memory-bound",
by enhancing the reuse of the least recently used data.

> Pipelining is used so the parts of the CPU which would just wait and do
> nothing most of the time in a single-stage CPU get used more often.
> Fetching, decoding and executing an instruction takes a certain ammount and
> at least a few clock cycles. In each stage of this process only one
> part of the CPU is used. Pipelining lets you use the other parts at
> the same time so pipelining is a good thing.
i still don't think that pipelining control uses too much ressources.
With a superpipeline such as the FC0, the latches might easily take a significant
place on the die but there's no magic : if you want to increase the clock speed,
you have to use a sort of "carpaccio" pipeline.
OTOH if you think that you can do your stuf without pipelining, you'll probably
have less die occupation but the clock speed will significantly drop.

> > If say small 32 word
> > register program history and 16 word address cache for virtual memory
> > and a single stage of pipeline is used you may have average quality
> > single CPU but because the design is small you may duplicate the
> > CPU several times to give a fast multiprocessing cpu?
> You can also duplicate a small pipelined CPU with cache and make a VLIW
> "multiprocessing" CPU. I beleive that's basically what the smart people
> on this list are doing.
i'm still waiting for the IQ test results ;-)
we start from a simple core that can keep some promises.
If you want to use it as LEGO bricks, it's a possibility
and i don't think that it's impossible. OTOH, it is significantly easier
to extend the architecture with larger registers through the SIMD capability :
it will give any code a serious boost at almost no difficult cost,
whereas multi-core chips are more difficult to use efficiently,
unless you have a  very specific application in mind.
There's no wonder : we don't have multi-x86 chips today in our PCs.
And when we want to make a multi-chip system, it's not easy at all
to use (i know, i have already played in asm "by hand" with a dual PII)

> I suggest you take a class on computer architecture
we all need to... and then look around us at the reality.
Some people believe that Patterson and Hennessy are gods, that their
books are bibles etc. But they often forget that the future must be
written somehow. Of course the lessons of the past are very important
but some "taboos" don't have any reason to exist today, while others
appear, because the computer science is not an exact science, it evolves
all the time. What we say today might be false in three years, and P&H
have written their books very long ago...

> keep lurking on this list untill you can give well thought-out,
> meaningfull suggestions. I know that's what I intend to do.
but beware, i don't want to play the "blue helmet" all my life...
there's a lot of things to learn, to say, to invent and to discuss,
but a minimum of respect is necessary :-)

> /me burries himself just like a nice little lurker should.
hmmm that's too easy ! ;-P
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Nicolas Boulay Sat Jan 20 16:07:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00342 for ; Sat, 20 Jan 2001 22:19:44 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:44 +0100 (MET) Received: (qmail 13236 invoked by uid 0); 20 Jan 2001 14:59:17 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx01) with SMTP; 20 Jan 2001 14:59:17 -0000 X-eGroups-Return: sentto-1101623-2043-980002749-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ej.egroups.com with NNFMP; 20 Jan 2001 14:59:12 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 14:59:09 -0000 Received: (qmail 89852 invoked from network); 20 Jan 2001 14:59:08 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 20 Jan 2001 14:59:08 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 20 Jan 2001 14:59:08 -0000 Received: from ifrance.com (nas25-176.vlt.club-internet.fr [195.36.224.176]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA28248 for ; Sat, 20 Jan 2001 15:59:05 +0100 (MET) Message-ID: <3A69A9B3.4A15261E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 16:07:31 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: fb101bfe4871e0c7905c90fa704972ce Status: R X-Status: N Hello,

Michael Riepe a =E9crit :
>
> On Sat, Jan 20, 2001 at 12:22:20AM +0100, Yann Guidon wrote:
> [...]
> > please don't stay mute and let's discuss about the shift unit :-)=
>
> I'm working on a proposal (no I do NOT volunteer to do the SHL unit > myself, at least not at the moment -- I want to get the integer arithm= etic
> stuff done first).
>
> The basic idea is to cut the input into 8-bit chunks, extend them
> to 16 bits (in the shifting direction) and shift them by 0...7 bits > in the first stage.  In the second stage, the partial results can= be
> ORed together one way or another; this allows SIMD operations as well<= BR> > as several operating modes: so far it should be able to do shiftl,
> shiftr, shiftra, rotl, rotr, bitrev and byterev.  Higher-order sh= ifts
> (by multiples of 8 bits) are also done in the second part.
>
> I have no working VHDL yet, and I can't tell you how fast this unit is=
> going to be (I'm afraid it won't fit into a single pipeline stage eith= er).
>
> BTW, I encountered another open question: when doing SIMD shifts, is > the second operand a SIMD operand, too?  Or will all chunks be sh= ifted
> by the same number of bits?  My unit will do the latter, but the = former
> might be interesting, too.
>

I think that the parameter could be in SIMD, too. Because it's much more general. And what you do in SISD, you could do it in SIMD.

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
eGroups Sponsor=

Get 3 CDs for ONLY $9.99!<= /a>
3D""
From Nicolas Boulay Sat Jan 20 16:07:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00345 for ; Sat, 20 Jan 2001 22:19:45 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:45 +0100 (MET) Received: (qmail 24229 invoked by uid 0); 20 Jan 2001 14:59:18 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx14) with SMTP; 20 Jan 2001 14:59:18 -0000 X-eGroups-Return: sentto-1101623-2044-980002750-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 20 Jan 2001 14:59:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 14:59:10 -0000 Received: (qmail 89876 invoked from network); 20 Jan 2001 14:59:10 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 20 Jan 2001 14:59:10 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta1 with SMTP; 20 Jan 2001 14:59:09 -0000 Received: from ifrance.com (nas25-176.vlt.club-internet.fr [195.36.224.176]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA25543 for ; Sat, 20 Jan 2001 15:59:07 +0100 (MET) Message-ID: <3A69A9B5.55B26654@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 16:07:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 25f3bad07df48b743f61017e4df5c7aa Status: R X-Status: N Don't forget to put a constant on the unit that could double (*4,*8,...) the size of the output. For 64, 128, 256 bit large register,... For some application such big registers could be more interresting than a FPU.

If the algorithme need a longer longest path. Maybe we can add some
pipeline stage.

nicO

art1 a =E9crit :
>
> Hello,
> > I'm working on a proposal (no I do NOT volunteer to do the SHL un= it
> > myself, at least not at the moment -- I want to get the integer a= rithmetic
> > stuff done first).
>
> I want to do it, but my questions were not answered.
>
> > BTW, I encountered another open question: when doing SIMD shifts,= is
> > the second operand a SIMD operand, too?  Or will all chunks = be shifted
> > by the same number of bits?  My unit will do the latter, but= the former
> > might be interesting, too.
>
> I suggested an unit with support for all kinds of shift/rotate
> (arithmetic, logic), direction (left/right), shift-counter (how many > shifts?), SIMD-operation (8x8bit, 4x16bit, 2x32bit, 1x64bit chunks). T= he
> shiftcounter has a size of 8x3bit=3D24bit to to individual shiftsize p= er
> chunk. It is an idea, that it could more useful and flexible way as an=
> SIMD-operation with same shifts (shiftcounter has 6bits) on all chunks= .
>
> I want to play with it in Altera, if it useful, I message you...
>
> Bye Andreas
eGroups Sponsor=

Get 3 CDs for ONLY $9.99!
3D""
From Ben Franchuk Tue Jan 16 07:28:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00370 for ; Sat, 20 Jan 2001 22:19:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:50 +0100 (MET) Received: (qmail 24340 invoked by uid 0); 20 Jan 2001 18:36:33 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 20 Jan 2001 18:36:33 -0000 X-eGroups-Return: sentto-1101623-2045-980015790-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 20 Jan 2001 18:36:32 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 18:36:29 -0000 Received: (qmail 69479 invoked from network); 20 Jan 2001 18:36:29 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 20 Jan 2001 18:36:29 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 20 Jan 2001 19:37:32 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA09120 for ; Sat, 20 Jan 2001 11:29:36 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A63E9FC.9FE2CBEA@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 15 Jan 2001 23:28:12 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5072a4677650d576e29763b8a3455f8f Status: R X-Status: N polz@writeme.com wrote:
.
> Unless everything they've been teaching me for the last 3 months is wrong,
> the cache hit probability in a modern CPU is usually somewhere between
> 90% and 99%. I would not call shis a little saving.

Compared to what? Cache was designed for the time when
CPU's had small amounts of data (<4K words) and CISC with
a lot of looping.Here a small cache ( few words ) would give
a 80%? hit rate on REPEATED data. The key word here is REPEATED
data.In a modern RISC machine any repeated data is stuffed into a
register and reused. A program that fits in the cache nowdays is rare.


To me the fastest a cpu can GO is 2 cycles for a Van Neuman architecture
and 1 cycle for a Harvard design. RISC's are Harvard WANT A BE's
thus they are about 1 3/4? cycles based on memory access. Rather than
make a CPU faster make a CPU more efficient. Our design can SAVE xx%
in a XXX architecture makes more sense to me than Marketing people
saying we are XX% faster than bla-bla-bla. The IBM PC with the 8086
cpu was slower than the 4Mhz Z80 8 bit cpu but they never told you that.


Take a C program fragment  while(*s) *d++= *s++;
Here only a few program instructions are repeated.
Data is reused only once. A data cache here is not useful.
A large program cache is waste here.

> Pipelining is used so the parts of the CPU which would just wait and do
> nothing most of the time in a single-stage CPU get used more often.
> Fetching, decoding and executing an instruction takes a certain ammount and
> at least a few clock cycles. In each stage of this process only one
> part of the CPU is used. Pipelining lets you use the other parts at
> the same time so pipelining is a good thing.

Two or three stages of pipelining is useful. 304 stages I would question.
I can see many stages of pipelining used to give a single ported memory
the illusion of a multiported memory or fast shifting for a floating point
unit, but still the adder delay in the alu is the most critical.
How ever with mult-ported memory and muilti-bit shifts in a single stage
more common is that many stages of pipeline needed?
Also if the main memory can't keep up with a super fast CPU why build
it so fast?


> > If say small 32 word
> > register program history and 16 word address cache for virtual memory
> > and a single stage of pipeline is used you may have average quality
> > single CPU but because the design is small you may duplicate the
> > CPU several times to give a fast multiprocessing cpu?
> You can also duplicate a small pipelined CPU with cache and make a VLIW
> "multiprocessing" CPU. I beleive that's basically what the smart people
> on this list are doing.
>
> I suggest you take a class on computer architecture keep lurking on this list
> untill you can give well thought-out, meaningfull suggestions. I know that's what
> I intend to do.

I did in 1982, on a PDP-8E. A nice 12 bit CPU with 8K of core memory.
Mind you paper tape was slow on the TTY. In the mean time I will go back to
lurking  as well and CPU design (see link).

>
> /me burries himself just like a nice little lurker should.
And stays hidden until ground hog day. :)
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From "Marco Al" Sat Jan 20 21:35:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00388 for ; Sat, 20 Jan 2001 22:19:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 22:19:55 +0100 (MET) Received: (qmail 20671 invoked by uid 0); 20 Jan 2001 20:54:55 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx18) with SMTP; 20 Jan 2001 20:54:55 -0000 X-eGroups-Return: sentto-1101623-2046-980022446-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 20 Jan 2001 20:27:34 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 20:27:25 -0000 Received: (qmail 2828 invoked from network); 20 Jan 2001 20:27:21 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 20 Jan 2001 20:27:21 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 20 Jan 2001 20:27:21 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 410262D03 for ; Sat, 20 Jan 2001 21:27:20 +0100 (CET) Message-ID: <004501c08320$896b0be0$29e65982@student.utwente.nl> To: References: <3A63D852.AC4F2DD@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 21:35:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 63b41f06ccdd63d21fa18a2fc5bd76d3 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>


> In a RISC machine like the F-CPU does a cache work?

Yes, even if it werent to do much for data there is always instructions... which
take considerable bandwith.

And cache gives a nice storage space to overcome latency through prefetching
too, but most important of all... it works in practice, just check any empirical
testing. Intuition goes a long way, but not always the right one.

> Is multi stage pipelining practical?

Yes, unless you want to try wavepipelining its the only way to get a lot of work
out of every single transistor (a large pipeline stage sits idle most of the
time).

> Reading elsewhere that the latest generation of FPGA's are super
> large and fast (and low voltage 1.5 volts) the chip designs remind
> me more and more of the 1st generation of tube computers
> that used a magnetic drum or CRT storage block serial memory
> and core memory with read then write back.

Traditional CPU's like the present design are almost entirely aimed at serial
computation... and consequently vastly innefficient for more parallel
computations, allowing FPGA's even with their huge wiring overhead, slow logic
and large amounts of configuration memory to outperform them in some area's in
transistor/performance ratio.

But they are very good at what they are meant to do, you can try to go a little
parallel without impacting on serial processing too much... but in the end you
need to make a choice, serial or parallel.

I prefer parallel, but alas... choices have been made already. I see vastly more
oppurtunity for a small scale team to make a dent there... because there is less
hardware to develop, there is a lot of replication in those kind of designs, and
the forest of patents is a little less thick (although I think it will be
impossible to avoid them whatever you try).

> Both pipelining and cache and virtual memory control use a large
> amount of cpu resources and little savings because most programs
> don't loop and data is too random to be cached.

Transistors are cheap, thats the basis of high end general purpose processors.
You cant ignore that if you want to compete with them on their own ground (which
I doubt most people here take as a serious objective anymore :) but as long as
its the goal however theoretical you have to stick by it).

> If say small 32 word
> register program history and 16 word address cache for virtual memory
> and a single stage of pipeline is used you may have average quality
> single CPU but because the design is small you may duplicate the
> CPU several times to give a fast multiprocessing cpu?
> I think a cache and pipelining and virtual memory
> are still useful but I don't think current form used now will
> be useful when you want to go past 500 MHZ.

500 MHz is not a realistic goal without heavy pipelining, and I think its a
mistake to develop a parallel processor in a non holistic way.

Marco
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Ben Franchuk Tue Jan 16 10:13:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00544 for ; Sat, 20 Jan 2001 23:03:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 20 Jan 2001 23:03:48 +0100 (MET) Received: (qmail 31475 invoked by uid 0); 20 Jan 2001 21:22:01 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx15) with SMTP; 20 Jan 2001 21:22:01 -0000 X-eGroups-Return: sentto-1101623-2047-980025706-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 20 Jan 2001 21:21:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 21:21:45 -0000 Received: (qmail 78407 invoked from network); 20 Jan 2001 21:21:45 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 20 Jan 2001 21:21:45 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 20 Jan 2001 22:22:48 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA16918 for ; Sat, 20 Jan 2001 14:14:52 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A6410BB.C979B4C6@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 02:13:31 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d8dbb2bbb0350a8d53b9284640f569cd Status: R X-Status: N Marco Al wrote:
>
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
>
> > In a RISC machine like the F-CPU does a cache work?
>
> Yes, even if it werent to do much for data there is always instructions... which
> take considerable bandwith.
>
> And cache gives a nice storage space to overcome latency through prefetching
> too, but most important of all... it works in practice, just check any empirical
> testing. Intuition goes a long way, but not always the right one.

That is true, but pre-fetching only works in two cases 1) Program Instructions.
2) Simple arrays like in DO I=0,100 A[I]=B[I]*C[I].

> > Is multi stage pipelining practical?
I expect to see more pipelining as machines get faster
but fewer pipelines between stages. Right now transistors switch
in a few 100 ps. If in the next generation you switch in 10's of ps,
a simple and slower logic design may be faster than a large but faster
design because of delays between transistors. With transit time longer
than gate delays what is pipelined like memory become more important than
raw speed.


> Yes, unless you want to try wavepipelining its the only way to get a lot of work
> out of every single transistor (a large pipeline stage sits idle most of the
> time).
That is good, less heat.
>
> > Reading elsewhere that the latest generation of FPGA's are super
> > large and fast (and low voltage 1.5 volts) the chip designs remind
> > me more and more of the 1st generation of tube computers
> > that used a magnetic drum or CRT storage block serial memory
> > and core memory with read then write back.
>
> Traditional CPU's like the present design are almost entirely aimed at serial
> computation... and consequently vastly innefficient for more parallel
> computations, allowing FPGA's even with their huge wiring overhead, slow logic
> and large amounts of configuration memory to outperform them in some area's in
> transistor/performance ratio.

The problem is most computing is still random access for most things.
Computer science would have computers good at weather prediction
but totally ignore the fact that 99.99% of the computers used to day
have programs like spell checkers and spread sheets.

> But they are very good at what they are meant to do, you can try to go a little
> parallel without impacting on serial processing too much... but in the end you
> need to make a choice, serial or parallel.
>
> I prefer parallel, but alas... choices have been made already. I see vastly more
> oppurtunity for a small scale team to make a dent there... because there is less
> hardware to develop, there is a lot of replication in those kind of designs, and
> the forest of patents is a little less thick (although I think it will be
> impossible to avoid them whatever you try).

> Transistors are cheap, thats the basis of high end general purpose processors.

BUT you can't ignore heat. A 4 MHZ Z80 has the gives off the same amount of heat
a stove element. Today's chips are magnitudes hotter.

> You cant ignore that if you want to compete with them on their own ground (which
> I doubt most people here take as a serious objective anymore :) but as long as
> its the goal however theoretical you have to stick by it).

The point I am asking with the rules of computer design changing
as we go deeper into the very fast but very simple logic gates in a cpu
are the guide lines based for cache design still valid or is a
different view point needed.


> 500 MHz is not a realistic goal without heavy pipelining, and I think its a
> mistake to develop a parallel processor in a non holistic way.

But is faster and bigger better? Take the space program for example,
Rockets have become bigger and faster but the idea of small reusable
space craft has yet to get funding. Did you know of launch costs
about 5% of it is for rocket fuel, the rest is to buy the and test the
rocket. Lots of money for the rocket makers but very little
is spent in new ideas. Lets hope computers have not become as
heavy in red tape for new ideas as the space program.

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From "Marco Al" Sat Jan 20 23:10:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01220 for ; Sun, 21 Jan 2001 00:16:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 21 Jan 2001 00:16:54 +0100 (MET) Received: (qmail 5560 invoked by uid 0); 20 Jan 2001 22:47:56 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx10) with SMTP; 20 Jan 2001 22:47:56 -0000 X-eGroups-Return: sentto-1101623-2048-980028123-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 20 Jan 2001 22:02:23 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 22:02:02 -0000 Received: (qmail 7277 invoked from network); 20 Jan 2001 22:02:01 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 Jan 2001 22:02:01 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 20 Jan 2001 22:02:00 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id CD32B2D15 for ; Sat, 20 Jan 2001 23:01:59 +0100 (CET) Message-ID: <001901c0832d$c2c807f0$29e65982@student.utwente.nl> To: References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 23:10:12 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 109a3ec825cfc4adf8b7db0ceb9e58f5 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> > Yes, unless you want to try wavepipelining its the only way to get a lot of
work
> > out of every single transistor (a large pipeline stage sits idle most of the
> > time).
> That is good, less heat.

The switching is the basic element of computation, if one transistor isnt doing
it another one is... the heat from switching is distributed over a greater area,
but meanwhile leakage current is increased too.

> BUT you can't ignore heat. A 4 MHZ Z80 has the gives off the same amount of
heat
> a stove element. Today's chips are magnitudes hotter.

High end processors can have high end cooling solutions. Anything short of
needing water cooling is ok, and even that is ok for some.

> The point I am asking with the rules of computer design changing
> as we go deeper into the very fast but very simple logic gates in a cpu
> are the guide lines based for cache design still valid or is a
> different view point needed.

Basically IMO with single instruction stream superscalar processing we are at a
point of diminishing returns... even if the cache is not very effective it
doesnt matter, anything remotely effective is worth sacrificing transistors
for... its not like you can spend them on something else more usefully.

> > 500 MHz is not a realistic goal without heavy pipelining, and I think its a
> > mistake to develop a parallel processor in a non holistic way.
>
> But is faster and bigger better? Take the space program for example,
> Rockets have become bigger and faster but the idea of small reusable
> space craft has yet to get funding. Did you know of launch costs
> about 5% of it is for rocket fuel, the rest is to buy the and test the
> rocket. Lots of money for the rocket makers but very little
> is spent in new ideas. Lets hope computers have not become as
> heavy in red tape for new ideas as the space program.

Telling your customer what they want doesnt work... if they want to run a single
program written in a serial manner in C(++) you make a processor which can do
that as fast as possible at as low a price as they will still pay. Demand drives
architecture... I think you are looking at the wrong place for the properties
you seek, look at low-power processing (mobile) or massively parallel processing
(DSP/media-processing).

Marco
eGroups Sponsor
From Ben Franchuk Tue Jan 16 11:13:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01223 for ; Sun, 21 Jan 2001 00:16:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 21 Jan 2001 00:16:55 +0100 (MET) Received: (qmail 1816 invoked by uid 0); 20 Jan 2001 23:08:53 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx08) with SMTP; 20 Jan 2001 23:08:53 -0000 X-eGroups-Return: sentto-1101623-2049-980032125-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 20 Jan 2001 23:08:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 23:08:44 -0000 Received: (qmail 53669 invoked from network); 20 Jan 2001 23:08:43 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 Jan 2001 23:08:43 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 20 Jan 2001 23:08:42 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA21755 for ; Sat, 20 Jan 2001 16:01:50 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A641EDC.AF6D4D61@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 03:13:48 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0bf7d3ea5bc97022f57a09a6f9abdc65 Status: R X-Status: N Marco Al wrote:
> Telling your customer what they want doesnt work... if they want to run a single
> program written in a serial manner in C(++) you make a processor which can do
> that as fast as possible at as low a price as they will still pay. Demand drives
> architecture...
Funny I thought that was Marketing people. Why else would I need a new computer
after only 2 years?

C++ !???. Hey I still a using C. C++ is way too bloated for me.

I think you are looking at the wrong place for the properties
> you seek, look at low-power processing (mobile) or massively parallel processing
> (DSP/media-processing).

But alas the F-CPU has too do all 3 markets and more.

> Marco
Ben.
PS. I forgot a GOOD CPU has too have the blinking lights too. :)
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Michael Riepe Sat Jan 20 16:59:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04184 for ; Mon, 22 Jan 2001 02:33:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:43 +0100 (MET) Received: (qmail 16247 invoked by uid 0); 20 Jan 2001 23:40:35 -0000 Received: from unknown (HELO ho.egroups.com) (64.211.240.236) by mx0.gmx.net (mx24) with SMTP; 20 Jan 2001 23:40:35 -0000 X-eGroups-Return: sentto-1101623-2050-980033971-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 20 Jan 2001 23:40:32 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 23:39:29 -0000 Received: (qmail 87751 invoked from network); 20 Jan 2001 23:39:28 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 20 Jan 2001 23:39:28 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.253) by mta3 with SMTP; 21 Jan 2001 00:40:22 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00601; Sat, 20 Jan 2001 16:59:56 +0100 Message-ID: <20010120165956.16075@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> <3A6998E8.C494D870@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A6998E8.C494D870@f-cpu.org>; from Yann Guidon on Sat, Jan 20, 2001 at 02:55:52PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 16:59:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1175a45202b721925a13fe575fa35eec Status: R X-Status: N On Sat, Jan 20, 2001 at 02:55:52PM +0100, Yann Guidon wrote:
[...]
> > > please don't stay mute and let's discuss about the shift unit :-)
> > I'm working on a proposal (no I do NOT volunteer to do the SHL unit
> > myself, at least not at the moment -- I want to get the integer arithmetic
> > stuff done first).
> hey, i don't want to drown you with work :-)

Hehe... don't worry, if you don't do it, somebody else will ;)

> > The basic idea is to cut the input into 8-bit chunks, extend them
> > to 16 bits (in the shifting direction) and shift them by 0...7 bits
> > in the first stage.  In the second stage, the partial results can be
> > ORed together one way or another; this allows SIMD operations as well
> > as several operating modes: so far it should be able to do shiftl,
> > shiftr, shiftra, rotl, rotr, bitrev and byterev.  Higher-order shifts
> > (by multiples of 8 bits) are also done in the second part.
> that seems to be one of the best ways : either do 3 stages with 4x4
> switches, or 2 stages with 8x8 switches. 2*8 looks like the way to go
> because the SHL unit can be split (beware of the number of partial result
> bits, though).

4x4x4 should be possible, too; I still have to investigate what's
better.  For the moment, 8x8 looks nicer because it matches the
minimum chunk size.  On the other hand, 4-bit chunks will reduce the
size of the input matrix by 50% (compared to 8-bit chunks), and maybe
the control logic will become simpler (and faster), too.

[...]
> > BTW, I encountered another open question: when doing SIMD shifts, is
> > the second operand a SIMD operand, too?  Or will all chunks be shifted
> > by the same number of bits?  My unit will do the latter, but the former
> > might be interesting, too.
> This question has been raised long ago, during a discussion with Thilo Reichelt.
> I think that the operation was called "permute" or something like that.
> In fact that possibilities are so large that it's difficult to make
> a good first decision. In particular, the SIMD words are not fixed-size
> and the extension to 1024 or even 65536 bits is not often straight-forward.
>
> We'll have to complete the Instruction Set Census and examine the possibilities.
> We have enough free room in the ISA anyway so we can add interesting extensions :-)

Yep.  While we're at it: I re-read the manual and saw that the `bitop'
instructions (bchg, bset, bclr, btst) are supposed to be handled by the
bit shuffling unit, too.  I think that they're better done in the ROP2 unit
(with a 6-to-64 decoder in front of it) because they're not bit shuffling
operations at all (only a single bit is changed).  There should be enough
room for the decoder if we drop `combine' mode (or move it to a second
stage, which is needed for a full-width combine anyway).

[...]
> then art1 wrote:
> > Hello,
> > > I'm working on a proposal (no I do NOT volunteer to do the SHL unit
> > > myself, at least not at the moment -- I want to get the integer arithmetic
> > > stuff done first).
> > I want to do it, but my questions were not answered.
> sorry if i didn't answer... i was overflowed with emails this week.
> But i think that other people can give you some answers.

You're not the only one... I'm 2 or 3 weeks behind with my e-mail, and
the heap is growing every day :(  Remind me to never begin a new year
(decade, century, millenium) on a monday again ;)

Andreas, you asked about VHDL tools, right?  I use VHDL Simili on
Windows/NT (http://www.symphonyeda.com/proddownloads.htm) and Vanilla
VHDL on Linux (http://www.freehdl.seul.org/).  Both are free, but there's
no source code.

I also tried Alliance and Savant -- Alliance doesn't support full VHDL,
and Savant was too resource hungry (I also had problems with the C++
code it generated -- it dumped core).  So far, VHDL Simili is most useful
(if I only had a Linux version...).  Vanilla VHDL doesn't grok VHDL'93
sometimes, and the simulator throws strange error messages ("opcode
botch") when the components become larger, but at least it's useful for
syntax checking on my Linux system.

--
Michael "I don't like mondays" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Click Here!
Click Here!
From "Marco Al" Sun Jan 21 00:52:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04199 for ; Mon, 22 Jan 2001 02:33:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:47 +0100 (MET) Received: (qmail 8978 invoked by uid 0); 21 Jan 2001 00:12:17 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx17) with SMTP; 21 Jan 2001 00:12:17 -0000 X-eGroups-Return: sentto-1101623-2051-980034274-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hp.egroups.com with NNFMP; 20 Jan 2001 23:45:50 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 20 Jan 2001 23:44:34 -0000 Received: (qmail 98824 invoked from network); 20 Jan 2001 23:44:34 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 20 Jan 2001 23:44:34 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 20 Jan 2001 23:44:34 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 79DD32D28 for ; Sun, 21 Jan 2001 00:44:32 +0100 (CET) Message-ID: <000701c0833c$1626eca0$29e65982@student.utwente.nl> To: References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 00:52:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: beaa853fd877c0e623393dcf31d0428c Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> Funny I thought that was Marketing people. Why else would I need a new
computer
> after only 2 years?

Games.

> > I think you are looking at the wrong place for the properties
> > you seek, look at low-power processing (mobile) or massively parallel
processing
> > (DSP/media-processing).
>
> But alas the F-CPU has too do all 3 markets and more.

If you compromise on everything you end up with something which excels at
nothing.

Marco
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Yann Guidon Sun Jan 21 03:38:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04226 for ; Mon, 22 Jan 2001 02:33:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:54 +0100 (MET) Received: (qmail 1387 invoked by uid 0); 21 Jan 2001 02:32:27 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx09) with SMTP; 21 Jan 2001 02:32:27 -0000 X-eGroups-Return: sentto-1101623-2056-980044343-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 21 Jan 2001 02:32:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 02:32:23 -0000 Received: (qmail 33288 invoked from network); 21 Jan 2001 02:32:22 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 21 Jan 2001 02:32:22 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 21 Jan 2001 03:33:27 -0000 Received: from f-cpu.org (nas4-73.ras.club-internet.fr [195.36.203.73]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22170 for ; Sun, 21 Jan 2001 03:32:18 +0100 (MET) Message-ID: <3A6A4BA4.C2DEE4D0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A69A9B5.55B26654@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 03:38:28 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e40454c90aa22f04071a25ca9fa1cad1 Status: R X-Status: N hello,

Nicolas Boulay wrote:
>
> Don't forget to put a constant on the unit that could double (*4,*8,...)
> the size of the output. For 64, 128, 256 bit large register,... For some
> application such big registers could be more interresting than a FPU.

i don't understand what you write ... example ?

> If the algorithme need a longer longest path. Maybe we can add some
> pipeline stage.

?

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Yann Guidon Sun Jan 21 03:38:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04229 for ; Mon, 22 Jan 2001 02:33:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:55 +0100 (MET) Received: (qmail 28501 invoked by uid 0); 21 Jan 2001 02:32:32 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx04) with SMTP; 21 Jan 2001 02:32:32 -0000 X-eGroups-Return: sentto-1101623-2054-980044343-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 21 Jan 2001 02:32:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 02:32:22 -0000 Received: (qmail 98075 invoked from network); 21 Jan 2001 02:32:22 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Jan 2001 02:32:22 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 21 Jan 2001 02:32:22 -0000 Received: from f-cpu.org (nas4-73.ras.club-internet.fr [195.36.203.73]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA18448 for ; Sun, 21 Jan 2001 03:32:17 +0100 (MET) Message-ID: <3A6A4BA0.5E7DB94A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 03:38:24 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9cb9c1991487b8a6f9a8b9c6ea9bf895 Status: R X-Status: N Nicolas Boulay wrote:
> Since the beginning, i try find a way to speed up the fcpu without the
> need of OOO and register renaming.
better SMT than OOO... FC0 is already OOOC and it's a good enough compromise.

> 64 registers are good but if you have
> a depencies of 8 instructions (with big pipelining) you could execute 8
> instruction at the same times. that's good.
wrong. You forget that an instruction has (in average) 2 sources
and 1 destination. so we can do 64/3=21 instructions without stalling.
that's 2*2*5 or 3*7 and optimistic because in reality, it's never that easy.

> To had more register as for
> Sparc, windowed register with 2 more ASM instructions to slide the
> windows could increase the number of usable register. But i think you
> could only save some access to the main memory.
explicit renaming is interesting but it creates enough troubles
everywhere that we must be very careful. It adds more informations
to store, to backup (how ?) and keep coherent.

> The first thing to do to execute more than 1 inst per clock cycle is to
> try to use during the same times differents units. But you have to
> reconise which instruction could be use in the same times.

i've thought about a trick to detect if 2 instructions (or any number)
could be issued at the same time. If we estimate that the unit is coded
in the opcode and only in the upper part, a 6-bit substract could done
between 2 consecutive instructions. If the result is above a certain limit,
there's no chance of unit hazard. This can be applied in parallel
with a reasonable amount of different instructions.

> So i propose to add a depencies bit inside the instruction.
too late.

> All consecutive instruction with the bit equal could be used in parallel.
> You will have packet with 1, then a packet with 0.
are you just copying the c6x or what ? :-P

> If the fcpu have many decoder, he could launch every packet in the same
> time if he had enought unit. So a coding rules will be to interleave the
> use of the different unit. And after that you could add one more adder
> and speed up the code a little bit.
>
> I think it's easy what do you think of it ?
it's incomplete. the register hazards are another problem.

I propose several alternatives that can be used in conjunction.
- The "VLIW" approach has been studied... a lot and since a long time.
the raw VLIW and the superscalar approaches can't be used verbatim,
something more synthetic and flexible must be used.
A good way to help is with the help of a "hint instruction",
something that is decoded as NOP when it is not supported,
but otherwise explicits the data and unit hazards for the
next N instructions. The format is not yet determined, it must
fit in 24 bits, that's all.
- The "dynamic" approach. it is similar to the Pentium or P4 approach :
the instructions are decoded when they enter the Instruction cache,
the register and unit hazards are decoded, so there's a performance hit
only at the first execution. The Pentium did that for decoding the
packet (instruction pairs) : the data from the cache is executed once,
the instructions boundaries are written to the instruction cache,
so for the next executions, the decoder already knows if it can execute
1 or 2 instructions.
Since it is regenerated everytime, it's "dynamic" and is independent
>from the rest.
- Better : a F-CPU/RISC->TTA translator. it's implicitely OOO but
it might be very interesting. the instructions are recoded as TTA
instructions and stored in a big buffer acting as the instruction cache,
it's similar to the P4 architecture but less heavy :-)
- SMT. did you forget that ? :-)

ok gotta sleep...

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
From Yann Guidon Sun Jan 21 03:38:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04232 for ; Mon, 22 Jan 2001 02:33:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:56 +0100 (MET) Received: (qmail 25956 invoked by uid 0); 21 Jan 2001 02:47:58 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx24) with SMTP; 21 Jan 2001 02:47:58 -0000 X-eGroups-Return: sentto-1101623-2053-980044342-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 21 Jan 2001 02:32:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 02:32:21 -0000 Received: (qmail 78868 invoked from network); 21 Jan 2001 02:32:21 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 21 Jan 2001 02:32:21 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 21 Jan 2001 02:32:20 -0000 Received: from f-cpu.org (nas4-73.ras.club-internet.fr [195.36.203.73]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA07213 for ; Sun, 21 Jan 2001 03:32:17 +0100 (MET) Message-ID: <3A6A4BA3.C6B6174@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 03:38:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a6a584822edfa4ab0aca71acbc6c0451 Status: R X-Status: N hi,

Marco Al wrote:
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
> > Funny I thought that was Marketing people. Why else would I need a new computer
> > after only 2 years?
> Games.
well, i don't need Tetris with Phong shading ;-)

> > > I think you are looking at the wrong place for the properties
> > > you seek, look at low-power processing (mobile) or massively parallel processing
> > > (DSP/media-processing).
> > But alas the F-CPU has too do all 3 markets and more.
??? was it a joke ? or you really meant it ?
Nobody said that the F-CPU was AIMED at mobile applications.
There are already enough cores for this branch.
The primary idea was to propose an architecture that could compete
with IA64 for the high-end and personal computers. the FC0 is a
first step that we have to reach, so we chose to leave it rather
simple and compact. It's something that should be implemented
with much less pain than any IA64 CPU. Then we'll decode more
instructions.

if you want to adapt the F-CPU for mobile applications, fine but it's
not the goal. They specify heat and power dissipation as priority #4 only.
The more important goals specify that the architecture should get more
performance with an innovative architecture rather than with "advanced"
funding technology, so we have to exploit every single transistor.

These goals were voted in mid-1999 but i never thought that i would have to
quote it so often... this shows that our preliminary efforts to
better define the project were not vain.

> If you compromise on everything you end up with
> something which excels at nothing.
at least now we excel at ... discussing ?
i gotta update the french translation of the manual...

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Ben Franchuk Tue Jan 16 15:07:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04235 for ; Mon, 22 Jan 2001 02:33:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:57 +0100 (MET) Received: (qmail 6324 invoked by uid 0); 21 Jan 2001 03:02:49 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx23) with SMTP; 21 Jan 2001 03:02:49 -0000 X-eGroups-Return: sentto-1101623-2057-980046165-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 21 Jan 2001 03:02:47 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 03:02:45 -0000 Received: (qmail 56130 invoked from network); 21 Jan 2001 03:02:44 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Jan 2001 03:02:44 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 21 Jan 2001 03:02:43 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA02781 for ; Sat, 20 Jan 2001 19:55:50 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A6455B8.4EABB1A0@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 07:07:52 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e60bfacbce6ebbc9737d52b816401989 Status: R X-Status: N Yann Guidon wrote:

> > > > I think you are looking at the wrong place for the properties
> > > > you seek, look at low-power processing (mobile) or massively parallel processing
> > > > (DSP/media-processing).
> > > But alas the F-CPU has too do all 3 markets and more.
> ??? was it a joke ? or you really meant it ?
> Nobody said that the F-CPU was AIMED at mobile applications.

I meant in this case that the F-CPU still is a General processor.
I don't expect a F-CPU in my phone but a F-CPU Could be used in a
Laptop or a Rack of 16 servers. For now the core is High end PC's
but with a  open design that could change overnight.

> There are already enough cores for this branch.
> The primary idea was to propose an architecture that could compete
> with IA64 for the high-end and personal computers. the FC0 is a
> first step that we have to reach, so we chose to leave it rather
> simple and compact. It's something that should be implemented
> with much less pain than any IA64 CPU. Then we'll decode more
> instructions.

This has me confused. What is the critical data path
for the f-Cpu? Off hand I don't think it is in instruction fetching
or decoding.

> if you want to adapt the F-CPU for mobile applications, fine but it's
> not the goal. They specify heat and power dissipation as priority #4 only.
> The more important goals specify that the architecture should get more
> performance with an innovative architecture rather than with "advanced"
> funding technology, so we have to exploit every single transistor.

They sound like good goals to me.
>
> > If you compromise on everything you end up with
> > something which excels at nothing.
> at least now we excel at ... discussing ?
> i gotta update the french translation of the manual...

Well I better read the English Version.

> > Marco
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ben.
PS.All the game I can afford are $5 DOS games at the garage sales.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From polz@writeme.com Sat Jan 20 22:34:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04244 for ; Mon, 22 Jan 2001 02:33:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:33:59 +0100 (MET) Received: (qmail 30487 invoked by uid 0); 21 Jan 2001 09:13:34 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx22) with SMTP; 21 Jan 2001 09:13:34 -0000 X-eGroups-Return: sentto-1101623-2058-980068411-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 21 Jan 2001 09:13:32 -0000 X-Sender: polz@writeme.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 09:13:30 -0000 Received: (qmail 4048 invoked from network); 21 Jan 2001 09:13:30 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 21 Jan 2001 09:13:30 -0000 Received: from unknown (HELO razor.arnes.si) (193.2.1.80) by mta1 with SMTP; 21 Jan 2001 09:13:30 -0000 Received: from mojastwar.burek.net (kr4-5a.dial-up.arnes.si [194.249.3.148]) by razor.arnes.si (Postfix) with ESMTP id 09C9B16EDBC for ; Sun, 21 Jan 2001 10:12:40 +0100 (MET) Received: from localhost (mojastwar.burek.net) [127.0.0.1] (polz) by mojastwar.burek.net with esmtp (Exim 3.11 #1 (Debian)) id 14K5eJ-00018X-00; Sat, 20 Jan 2001 22:34:15 +0100 X-Mailer: exmh version 2.1.1 10/15/1999 (debian) To: f-cpu@egroups.com In-reply-to: Your message of "Mon, 15 Jan 2001 23:28:12 MST." <3A63E9FC.9FE2CBEA@jetnet.ab.ca> References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> Message-Id: From: polz@writeme.com MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 20 Jan 2001 22:34:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 34d64af59871c9f0262f4e70ce68db27 Status: R X-Status: N
> >
> > /me burries himself just like a nice little lurker should.
> And stays hidden until ground hog day. :)
> Ben.
Or longer. 10x for the long explanation of why I am wrong.
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Nicolas Boulay Sun Jan 21 15:10:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04280 for ; Mon, 22 Jan 2001 02:34:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:08 +0100 (MET) Received: (qmail 26260 invoked by uid 0); 21 Jan 2001 14:01:46 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx15) with SMTP; 21 Jan 2001 14:01:46 -0000 X-eGroups-Return: sentto-1101623-2059-980085702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 21 Jan 2001 14:01:45 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 14:01:42 -0000 Received: (qmail 56559 invoked from network); 21 Jan 2001 14:01:42 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 21 Jan 2001 14:01:42 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 21 Jan 2001 15:02:46 -0000 Received: from ifrance.com (nas7-12.vlt.club-internet.fr [194.158.109.12]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA05949 for ; Sun, 21 Jan 2001 15:01:38 +0100 (MET) Message-ID: <3A6AEDC2.9D304989@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> <3A6A4BA0.5E7DB94A@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 15:10:10 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2aa641d995d4d3d8c431ae219eff4880 Status: R X-Status: N Hello,

Yann Guidon a =E9crit :
>
> Nicolas Boulay wrote:
> > Since the beginning, i try find a way to speed up the fcpu withou= t the
> > need of OOO and register renaming.
> better SMT than OOO... FC0 is already OOOC and it's a good enough comp= romise.
>
OOOC isn't the same usfullness as OOO.

> > 64 registers are good but if you have
> > a depencies of 8 instructions (with big pipelining) you could exe= cute 8
> > instruction at the same times. that's good.
> wrong. You forget that an instruction has (in average) 2 sources
> and 1 destination. so we can do 64/3=3D21 instructions without stallin= g.
> that's 2*2*5 or 3*7 and optimistic because in reality, it's never that= easy.
>

Sorry, i was much more too optimistik ;p

> > To had more register as for
> > Sparc, windowed register with 2 more ASM instructions to slide th= e
> > windows could increase the number of usable register. But i think= you
> > could only save some access to the main memory.
> explicit renaming is interesting but it creates enough troubles
> everywhere that we must be very careful. It adds more informations
> to store, to backup (how ?) and keep coherent.
>
If you know when you slide the window, you could save your register
(it's only slower)

> > The first thing to do to execute more than 1 inst per clock cycle= is to
> > try to use during the same times differents units. But you have t= o
> > reconise which instruction could be use in the same times.
>
> i've thought about a trick to detect if 2 instructions (or any number)=
> could be issued at the same time. If we estimate that the unit is code= d
> in the opcode and only in the upper part, a 6-bit substract could done=
> between 2 consecutive instructions. If the result is above a certain l= imit,
> there's no chance of unit hazard. This can be applied in parallel
> with a reasonable amount of different instructions.
>

No really, 2 concecutives instruction could see as in the same bloc with your scheme. And read a bit is much more easy. (imagine to do 6
substracts for 6 decoders, it's make a very long path)

> > So i propose to add a depencies bit inside the instruction.
> too late.
>
Hum, i don't think so, the insctruction as been defined with the binary
code, but without knowing what all is need. A good number of instruction have been chosen, but why not change how to code all of this ? Nothing
is written about it (in vhdl).

> > All consecutive instruction with the bit equal could be used in p= arallel.
> > You will have packet with 1, then a packet with 0.
> are you just copying the c6x or what ? :-P
>
YES ! But it seems so easy to use it for variable lenght superscalar
processor !

> > If the fcpu have many decoder, he could launch every packet in th= e same
> > time if he had enought unit. So a coding rules will be to interle= ave the
> > use of the different unit. And after that you could add one more = adder
> > and speed up the code a little bit.
> >
> > I think it's easy what do you think of it ?
> it's incomplete. the register hazards are another problem.
>
No, it's totally fixe by the dependance bit. You just have to check the
code of the instruction. Scoreboard are used in the same manner as
befor.

> I propose several alternatives that can be used in conjunction.
> - The "VLIW" approach has been studied... a lot and since a = long time.
> the raw VLIW and the superscalar approaches can't be used verbatim, > something more synthetic and flexible must be used.

That's not what i propose ?

> A good way to help is with the help of a "hint instruction",=
> something that is decoded as NOP when it is not supported,
> but otherwise explicits the data and unit hazards for the
> next N instructions. The format is not yet determined, it must
> fit in 24 bits, that's all.
no, you can't do that without having an explosion of the code size.
> - The "dynamic" approach. it is similar to the Pentium or P4= approach :
> the instructions are decoded when they enter the Instruction cache, > the register and unit hazards are decoded, so there's a performance hi= t
> only at the first execution. The Pentium did that for decoding the
> packet (instruction pairs) : the data from the cache is executed once,=
> the instructions boundaries are written to the instruction cache,
> so for the next executions, the decoder already knows if it can execut= e
> 1 or 2 instructions.

It's the story of the trace cache, read
http://www.emulators.com/= pentium4.htm and you will hate the trace cache
: it's a gain of decoding but your 96 Kbyte of cache is like a 8Ko of L&= ;
cache compare to the 128 Ko of the athlon.

> Since it is regenerated everytime, it's "dynamic" and is ind= ependent
> from the rest.

But too small !

> - Better : a F-CPU/RISC->TTA translator. it's implicitely OOO but > it might be very interesting. the instructions are recoded as TTA
> instructions and stored in a big buffer acting as the instruction cach= e,
> it's similar to the P4 architecture but less heavy :-)
Bof, too far from our risc architecture, and maybe hard to make it
parallel.

> - SMT. did you forget that ? :-)
In smt, you don't increase the number of instruction issued by clock
cycle !
>
> ok gotta sleep...
>
> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Nicolas Boulay Sun Jan 21 15:15:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04283 for ; Mon, 22 Jan 2001 02:34:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:10 +0100 (MET) Received: (qmail 3774 invoked by uid 0); 21 Jan 2001 14:07:15 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx22) with SMTP; 21 Jan 2001 14:07:15 -0000 X-eGroups-Return: sentto-1101623-2060-980086027-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 21 Jan 2001 14:07:13 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 14:07:06 -0000 Received: (qmail 48973 invoked from network); 21 Jan 2001 14:07:06 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 21 Jan 2001 14:07:06 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 21 Jan 2001 14:07:06 -0000 Received: from ifrance.com (nas7-12.vlt.club-internet.fr [194.158.109.12]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA08124 for ; Sun, 21 Jan 2001 15:07:03 +0100 (MET) Message-ID: <3A6AEF06.CB83F16D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 15:15:34 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8ddbe5c5cb1b68c470e4de2c79463fdb Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi,
>
> Marco Al wrote:
> > From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
> > > Funny I thought that was Marketing people. Why else would I = need a new computer
> > > after only 2 years?
> > Games.
> well, i don't need Tetris with Phong shading ;-)
>
> > > > I think you are looking at the wrong place for the prop= erties
> > > > you seek, look at low-power processing (mobile) or mass= ively parallel processing
> > > > (DSP/media-processing).
> > > But alas the F-CPU has too do all 3 markets and more.
> ??? was it a joke ? or you really meant it ?
> Nobody said that the F-CPU was AIMED at mobile applications.

But in fact, it will be the first used of it. Because it the simpler one !

> There are already enough cores for this branch.
> The primary idea was to propose an architecture that could compete
> with IA64 for the high-end and personal computers. the FC0 is a
> first step that we have to reach, so we chose to leave it rather
> simple and compact. It's something that should be implemented
> with much less pain than any IA64 CPU. Then we'll decode more
> instructions.
>
> if you want to adapt the F-CPU for mobile applications, fine but it's<= BR> > not the goal. They specify heat and power dissipation as priority #4 o= nly.
> The more important goals specify that the architecture should get more=
> performance with an innovative architecture rather than with "adv= anced"
> funding technology, so we have to exploit every single transistor.

A=EFe ! ARM aren't made in specific funding technology at all. It use just<= BR> a different design, as a specific flip-flop design or so one. We can
make clock gating without loosing to much speed.

>
> These goals were voted in mid-1999 but i never thought that i would ha= ve to
> quote it so often... this shows that our preliminary efforts to
> better define the project were not vain.
>
> > If you compromise on everything you end up with
> > something which excels at nothing.
> at least now we excel at ... discussing ?
> i gotta update the french translation of the manual...
>
> > Marco
> WHYGEE

nicO
eGroups Sponsor=

Get 3 CDs for ONLY $9.99!
3D""
From Nicolas Boulay Sun Jan 21 15:23:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04286 for ; Mon, 22 Jan 2001 02:34:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:11 +0100 (MET) Received: (qmail 15819 invoked by uid 0); 21 Jan 2001 14:14:41 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx08) with SMTP; 21 Jan 2001 14:14:41 -0000 X-eGroups-Return: sentto-1101623-2061-980086473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c9.egroups.com with NNFMP; 21 Jan 2001 14:14:40 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 14:14:33 -0000 Received: (qmail 62457 invoked from network); 21 Jan 2001 14:14:32 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 21 Jan 2001 14:14:32 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 21 Jan 2001 14:14:32 -0000 Received: from ifrance.com (nas7-12.vlt.club-internet.fr [194.158.109.12]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA10900 for ; Sun, 21 Jan 2001 15:14:29 +0100 (MET) Message-ID: <3A6AF0C5.27A71976@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A69A9B5.55B26654@ifrance.com> <3A6A4BA4.C2DEE4D0@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 15:23:01 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] conferences Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6ad608f7861f285c0081ef9642af0d75 Status: R X-Status: N You write a 64 bit unit, but in the near futur 128 bit could be used. So if each unit could be double the size of this input and ouput. When you
synthetise your chip, you will choose the size of the register. That's
all. When i use the leon, i choose the size of the window register (2 to 32 windows) and the size of the cache. Here, i want to possibly change
the size of the register.

Yann Guidon a =E9crit :
>
> hello,
>
> Nicolas Boulay wrote:
> >
> > Don't forget to put a constant on the unit that could double (*4,= *8,...)
> > the size of the output. For 64, 128, 256 bit large register,... F= or some
> > application such big registers could be more interresting than a = FPU.
>
> i don't understand what you write ... example ?
>
> > If the algorithme need a longer longest path. Maybe we can add so= me
> > pipeline stage.
>
> ?
>
I don't know how you will make your design but by doubling the size of
the register could increase the longuest path. So it will be better to
create a new pipeline stage.

> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Nicolas Boulay Sun Jan 21 15:29:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04289 for ; Mon, 22 Jan 2001 02:34:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:12 +0100 (MET) Received: (qmail 13983 invoked by uid 0); 21 Jan 2001 14:21:11 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx03) with SMTP; 21 Jan 2001 14:21:11 -0000 X-eGroups-Return: sentto-1101623-2062-980086859-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 21 Jan 2001 14:21:08 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 14:20:59 -0000 Received: (qmail 18292 invoked from network); 21 Jan 2001 14:20:59 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 21 Jan 2001 14:20:59 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 21 Jan 2001 15:22:03 -0000 Received: from ifrance.com (nas7-12.vlt.club-internet.fr [194.158.109.12]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA13452 for ; Sun, 21 Jan 2001 15:20:56 +0100 (MET) Message-ID: <3A6AF247.103F5854@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 15:29:27 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5ec3c9d656b6a526b305273999413abc Status: R X-Status: N Hello,

Ben Franchuk a =E9crit :
>
> polz@writeme.com wrote:
> .
> > Unless everything they've been teaching me for the last 3 months = is wrong,
> > the cache hit probability in a modern CPU is usually somewhere be= tween
> > 90% and 99%. I would not call shis a little saving.
>
> Compared to what? Cache was designed for the time when
> CPU's had small amounts of data (<4K words) and CISC with
> a lot of looping.Here a small cache ( few words ) would give
> a 80%? hit rate on REPEATED data. The key word here is REPEATED
> data.In a modern RISC machine any repeated data is stuffed into a
> register and reused. A program that fits in the cache nowdays is rare.=
>

Go to your bios of your computer, then turn off your cache L1 and L2
(called internal and external cache). And you will see what happen...

> To me the fastest a cpu can GO is 2 cycles for a Van Neuman architectu= re
> and 1 cycle for a Harvard design. RISC's are Harvard WANT A BE's
> thus they are about 1 3/4? cycles based on memory access. Rather than<= BR> > make a CPU faster make a CPU more efficient. Our design can SAVE xx% > in a XXX architecture makes more sense to me than Marketing people
> saying we are XX% faster than bla-bla-bla. The IBM PC with the 8086 > cpu was slower than the 4Mhz Z80 8 bit cpu but they never told you tha= t.
>
>
> Take a C program fragment  while(*s) *d++=3D *s++;
> Here only a few program instructions are repeated.
> Data is reused only once. A data cache here is not useful.
> A large program cache is waste here.
>
Yes, but program cache will be very usefull.

> > Pipelining is used so the parts of the CPU which would just wait = and do
> > nothing most of the time in a single-stage CPU get used more ofte= n.
> > Fetching, decoding and executing an instruction takes a certain a= mmount and
> > at least a few clock cycles. In each stage of this process only o= ne
> > part of the CPU is used. Pipelining lets you use the other parts = at
> > the same time so pipelining is a good thing.
>
> Two or three stages of pipelining is useful. 304 stages I would questi= on.

No more with smt.

> I can see many stages of pipelining used to give a single ported memor= y
> the illusion of a multiported memory or fast shifting for a floating p= oint
> unit, but still the adder delay in the alu is the most critical.
> How ever with mult-ported memory and muilti-bit shifts in a single sta= ge
> more common is that many stages of pipeline needed?
> Also if the main memory can't keep up with a super fast CPU why build<= BR> > it so fast?
Use cache ...

>
>
> > > If say small 32 word
> > > register program history and 16 word address cache for virtu= al memory
> > > and a single stage of pipeline is used you may have average = quality
> > > single CPU but because the design is small you may duplicate= the
> > > CPU several times to give a fast multiprocessing cpu?
> > You can also duplicate a small pipelined CPU with cache and make = a VLIW
> > "multiprocessing" CPU. I beleive that's basically what = the smart people
> > on this list are doing.
> >
> > I suggest you take a class on computer architecture keep lurking = on this list
> > untill you can give well thought-out, meaningfull suggestions. I = know that's what
> > I intend to do.
>
> I did in 1982, on a PDP-8E. A nice 12 bit CPU with 8K of core memory.<= BR> > Mind you paper tape was slow on the TTY. In the mean time I will go ba= ck to
> lurking  as well and CPU design (see link).
>
> >
> > /me burries himself just like a nice little lurker should.
> And stays hidden until ground hog day. :)
> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs fo= r $0.49 each!
3D""
From Nicolas Boulay Sun Jan 21 15:48:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04292 for ; Mon, 22 Jan 2001 02:34:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:13 +0100 (MET) Received: (qmail 2733 invoked by uid 0); 21 Jan 2001 14:40:28 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx08) with SMTP; 21 Jan 2001 14:40:28 -0000 X-eGroups-Return: sentto-1101623-2063-980088024-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 21 Jan 2001 14:40:26 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 14:40:23 -0000 Received: (qmail 30936 invoked from network); 21 Jan 2001 14:40:23 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Jan 2001 14:40:23 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 21 Jan 2001 14:40:22 -0000 Received: from ifrance.com (nas7-12.vlt.club-internet.fr [194.158.109.12]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA02865 for ; Sun, 21 Jan 2001 15:40:20 +0100 (MET) Message-ID: <3A6AF6D3.78AAB536@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 15:48:51 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Shared memory Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 38b9286e4d1149320d3b33ef9cc3f6d8 Status: R X-Status: N A little draft about shared memory and the extended MMU (read TLB,
Whygee ;p),
http://f-cpu.seul.org/nico/

nicO
eGroups Sponsor
CLICK HERE for low travel rates!!
From Ben Franchuk Tue Jan 16 21:08:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04316 for ; Mon, 22 Jan 2001 02:34:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:21 +0100 (MET) Received: (qmail 3208 invoked by uid 0); 21 Jan 2001 16:49:08 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 21 Jan 2001 16:49:08 -0000 X-eGroups-Return: sentto-1101623-2064-980095706-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 21 Jan 2001 16:48:33 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 16:48:26 -0000 Received: (qmail 10870 invoked from network); 21 Jan 2001 16:48:25 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 21 Jan 2001 16:48:25 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 21 Jan 2001 17:49:30 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA20774 for ; Sun, 21 Jan 2001 09:41:30 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A64AA24.529272DF@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 13:08:04 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fb3cecc768d485b2d5954369ba3ce82a Status: R X-Status: N Nicolas Boulay wrote:

> Go to your bios of your computer, then turn off your cache L1 and L2
> (called internal and external cache). And you will see what happen...

Yes I know massive slow down. On this old machine I have 256k of
external cache and a unknown amount of internal cache on my P-150.
With dynamic ram 60 ns? (I can never get a true figure from the data
sheets) or static 20 ns? for main memory. A cache has to match the
clock speed of the cpu. With a external cache @ 5 ns? and a internal
cache @ 1ns (1GHZ machine) I can't see external memory getting faster
do transit time between parts. Pipelining the memory helps but this is
near the limit of physics here for speed. As clock speeds get faster
it not possible to build bigger caches, so I am asking are there alternatives
to large caches?

> No more with smt.

I have read the F-manual again, but it still does not explain
SMT. Can some explain the details of that here?

The rest of the F-CPU still looks clean and well thought out
and I can understand it all.
The only change I can think of  make is adding a few more instructions
to the increment unit. Incriment/decriment by word size might
be useful. Also this would permit the control unit to decode
addi,subi #1,#word size as special cases and send it to the faster
increment unit.

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Lee Salzman Sun Jan 21 17:50:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04319 for ; Mon, 22 Jan 2001 02:34:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:22 +0100 (MET) Received: (qmail 2766 invoked by uid 0); 21 Jan 2001 16:57:54 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx04) with SMTP; 21 Jan 2001 16:57:54 -0000 X-eGroups-Return: sentto-1101623-2065-980096073-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 21 Jan 2001 16:54:34 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 16:54:32 -0000 Received: (qmail 66728 invoked from network); 21 Jan 2001 16:54:32 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Jan 2001 16:54:32 -0000 Received: from unknown (HELO object) (128.2.166.156) by mta1 with SMTP; 21 Jan 2001 16:54:31 -0000 Received: from lvdi.net (really [127.0.0.1]) by object via in.smtpd with esmtp (ident lee using rfc1413) id (Debian Smail3.2.0.102) for ; Sun, 21 Jan 2001 11:50:44 -0500 (EST) Sender: lee@pop.gmx.net Message-ID: <3A6B1364.5722CFB2@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0 i686) X-Accept-Language: en To: f-cpu@egroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 11:50:44 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] Re: Shared memory Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a25c9e804909325947a544d3787e172c Status: R X-Status: N Nicolas Boulay wrote:
>A little draft about shared memory and the extended
>MMU (read TLB, Whygee ;p),
>http://f-cpu.seul.org/nico/

>Java optimising consideration
> ... snip ...
  
   The notion of optimizing a processor for Java
is VERY dubious. Many languages more dynamic than
Java have existed for much longer and have been
optimized quite well and without complaint for
ages. I refer you to Self (research.sun.com/self/,
>from which Sun derived lots of Java optimization
technology) and CMUCL for examples of optimized
yet-more-dynamic-than-java languages on
ordinary hardware. :) IMO, the best way to
optimize a processor for a language is either
put the whole language in hardware (if you're
insane) or to try to assume as little policy
about what code is being run on the processor
as possible (to make it flexible for language
implementers).

>Garbage Collection
>Most of the time, the yougest object became often garbage.
>So an optimised system try to show this type of object
>first. Most of the time the garbage collection is made
>by using a "write barriers". The goal is to show the
>write of pointer inside "old" object which can made a
>recent object garbage. Usual MMU can't see that they
>write a pointer, so each write must be follow by some
>code to do some garbage collection check. So it could
>be better to use a specific store instruction, to trap
>only when it's a write of a pointer.

   This idea is very misleading, although it might
sound lucid to the unitiated. As a concrete advantage
you could cite a reduction in code size due to not
needing several extra instructions to perform write
barrier checks in hardware.
   However, after this it all gets messy. Firstly,
you need to consider how expensive that single trap
is compared to inlined write barrier code. Traps to
executive code (and if this requires a trip through
the operating system to get to it, you can add on
a hundred or couple hundred cycles) are definitely
more expensive than even a few jmpa instructions.
Now, this may be very feasable if stores were
extremely frequent and the garbage collector had
direct control of the processor, however, these
situations are most unlike what you will find in
even most Java implementations.
   Elaborating, the F-CPU has a prodigious amount
of registers meaning that, ideally, memory accesses
will be very infrequent (so code size advantages are
greatly nullified). Further, you can just as well
emulate this functionality by preceding or succeeding
every store instruction with a syscall instruction
(for reasons cited above, however, this is not
even desirable). Another trick is using memory
instructions that trap if done on unaligned addresses
(even x86 hardware can do this!). If I were to truly
implement a write barrier that trapped every store
on the F-CPU, I would have the address of GC
write-barrier code pre-loaded in a dedicated register
and simply issue a jmpa (with return address safely
stashed in another register) to the GC code, examine
the instruction to find out where the write was
happening and with what (or include this information
encoded after the jmpa and notch the return address,
however, this is unnecessary because of simple F-CPU
instruction encoding). This is not only compact but
much more efficient than any trap.
    However, I said if I were to implement a write
barrier that trapped every store instruction. :)
For a generational garbage collector, and maybe even
an incremental one, it is very sufficient to just
use the vanilla features on any MMU. Simply write
protect the page which holds the heap area you
with to protect. When a store is done on this
page, the page in which the write was done is
recorded and the page added to a list of dirty
pages managed by the garbage collector. Following
this, the page's write-protection is *removed*.
All succeeding writes are now practically free
and you just need to re-examine the recorded page
later and re-write-protect it when the need arises.

                  My $0.02 USD on Java and GC,
                  Lee Salzman
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From "Marco Al" Sun Jan 21 18:35:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04331 for ; Mon, 22 Jan 2001 02:34:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:25 +0100 (MET) Received: (qmail 6580 invoked by uid 0); 21 Jan 2001 17:27:30 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx16) with SMTP; 21 Jan 2001 17:27:30 -0000 X-eGroups-Return: sentto-1101623-2066-980098044-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 21 Jan 2001 17:27:28 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 17:27:23 -0000 Received: (qmail 84631 invoked from network); 21 Jan 2001 17:27:23 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 21 Jan 2001 17:27:23 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 21 Jan 2001 17:27:23 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 3097B2DC8 for ; Sun, 21 Jan 2001 18:27:22 +0100 (CET) Message-ID: <001d01c083d0$913acd00$29e65982@student.utwente.nl> To: References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> <3A64AA24.529272DF@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 18:35:37 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7178a3047b56ea3518183cbf3d702d99 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>


> so I am asking are there alternatives to large caches?

In a way... not something relevant to us though.

You can use massive main memory bandwith and massive multithreading (many ten's
of threads, vertical multithreading suffices though) to get rid of caches.

> I have read the F-manual again, but it still does not explain
> SMT. Can some explain the details of that here?

Simultaneous multithreading. For a nice mix between populist and technical
reporting see http://www.realworldtech.com/ they had a 3 part story on SMT in
future Alpha's.

Marco
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Nicolas Boulay Sun Jan 21 19:02:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04337 for ; Mon, 22 Jan 2001 02:34:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:27 +0100 (MET) Received: (qmail 22853 invoked by uid 0); 21 Jan 2001 17:55:28 -0000 Received: from hh.egroups.com (208.50.99.210) by 10.1.4.111 (mx11) with SMTP; 21 Jan 2001 17:55:28 -0000 X-eGroups-Return: sentto-1101623-2067-980099660-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 21 Jan 2001 17:55:25 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 17:54:20 -0000 Received: (qmail 49496 invoked from network); 21 Jan 2001 17:54:19 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 21 Jan 2001 17:54:19 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 21 Jan 2001 17:54:19 -0000 Received: from ifrance.com (nas23-198.vlt.club-internet.fr [195.36.173.198]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA01304 for ; Sun, 21 Jan 2001 18:54:17 +0100 (MET) Message-ID: <3A6B2448.800F986E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> <3A64AA24.529272DF@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 19:02:49 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5bb5360b160d85a31a9cb1472d7cd618 Status: R X-Status: N reHello,

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
>
> > Go to your bios of your computer, then turn off your cache L1 and= L2
> > (called internal and external cache). And you will see what happe= n...
>
> Yes I know massive slow down. On this old machine I have 256k of
> external cache and a unknown amount of internal cache on my P-150.
> With dynamic ram 60 ns? (I can never get a true figure from the data > sheets) or static 20 ns? for main memory. A cache has to match the
> clock speed of the cpu. With a external cache @ 5 ns? and a internal > cache @ 1ns (1GHZ machine) I can't see external memory getting faster<= BR> > do transit time between parts. Pipelining the memory helps but this is=
> near the limit of physics here for speed. As clock speeds get faster > it not possible to build bigger caches, so I am asking are there alter= natives
> to large caches?
>
You can try to reduice the size of the code at the maximum, to save
space. I try to propose to make something which look like the opposite
of CISC. In CISC, you have a 32 bit decoders and some instruction about
20 byte. Here, i propose to have a larger decoder compare to the size of usual instruction. Imagine having a 64 bit decoders with 64, 32 and 16
bit instruction. The goal is to avoid to have unused bit inside
instruction, it's waste of space. It's used by TI to reduice code
footprint for this DSP (32 bit decoder with 8 to 48 bit instruction).
ARM use a different technique. There have 32 instructions RISC
processors, and make a compact subset of 16 bit instructions. They have
also an instruction to change the type of the instruction used. They
lose a little performance but have a gain of somethink like 30-40% in
code size.

> > No more with smt.
>
> I have read the F-manual again, but it still does not explain
> SMT. Can some explain the details of that here?
>

In fact, it's very simple. Imagine each time you execute one
instruction, you change the thread where the instruction come from. So
you just have to add enought register bank and you cut the latency of
the pipeline. You can hide cache miss latency also, but only a few.

> The rest of the F-CPU still looks clean and well thought out
> and I can understand it all.
> The only change I can think of  make is adding a few more instruc= tions
> to the increment unit. Incriment/decriment by word size might
> be useful. Also this would permit the control unit to decode
> addi,subi #1,#word size as special cases and send it to the faster
> increment unit.
>
> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs fo= r $0.49 each!
3D""
From Nicolas Boulay Sun Jan 21 19:26:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04340 for ; Mon, 22 Jan 2001 02:34:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:28 +0100 (MET) Received: (qmail 21543 invoked by uid 0); 21 Jan 2001 18:18:55 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx22) with SMTP; 21 Jan 2001 18:18:55 -0000 X-eGroups-Return: sentto-1101623-2068-980101132-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 21 Jan 2001 18:18:54 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 21 Jan 2001 18:18:51 -0000 Received: (qmail 52365 invoked from network); 21 Jan 2001 18:18:51 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 21 Jan 2001 18:18:51 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 21 Jan 2001 19:19:56 -0000 Received: from ifrance.com (nas20-201.vlt.club-internet.fr [195.36.170.201]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA01529 for ; Sun, 21 Jan 2001 19:18:47 +0100 (MET) Message-ID: <3A6B29D6.6CD4DAAF@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A6B1364.5722CFB2@lvdi.net> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 21 Jan 2001 19:26:30 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Re: Shared memory Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: da933b10d25b2bc9a505b1c6ab68f05f Status: R X-Status: N Hello, nice to read something like that !

What i have understand, is to avoid to make write barrer to each write
but only for pointer. So how to reduice the overhead ? Don't you think
that a special store instruction could be nice ? to limit the overhead.
Inline is good but is it good for all write ? Couldn't save anything ?

nicO

Lee Salzman a =E9crit :
>
> Nicolas Boulay wrote:
> >A little draft about shared memory and the extended
> >MMU (read TLB, Whygee ;p),
> >http://f-cpu.seul.org/nico= /
>
> >Java optimising consideration
> > ... snip ...
>
>    The notion of optimizing a processor for Java
> is VERY dubious. Many languages more dynamic than
> Java have existed for much longer and have been
> optimized quite well and without complaint for
> ages. I refer you to Self (research.sun.com/self/,
> from which Sun derived lots of Java optimization
> technology) and CMUCL for examples of optimized
> yet-more-dynamic-than-java languages on
> ordinary hardware. :) IMO, the best way to
> optimize a processor for a language is either
> put the whole language in hardware (if you're
> insane) or to try to assume as little policy
> about what code is being run on the processor
> as possible (to make it flexible for language
> implementers).
>
> >Garbage Collection
> >Most of the time, the yougest object became often garbage.
> >So an optimised system try to show this type of object
> >first. Most of the time the garbage collection is made
> >by using a "write barriers". The goal is to show the
> >write of pointer inside "old" object which can made a > >recent object garbage. Usual MMU can't see that they
> >write a pointer, so each write must be follow by some
> >code to do some garbage collection check. So it could
> >be better to use a specific store instruction, to trap
> >only when it's a write of a pointer.
>
>    This idea is very misleading, although it might
> sound lucid to the unitiated. As a concrete advantage
> you could cite a reduction in code size due to not
> needing several extra instructions to perform write
> barrier checks in hardware.
>    However, after this it all gets messy. Firstly,
> you need to consider how expensive that single trap
> is compared to inlined write barrier code. Traps to
> executive code (and if this requires a trip through
> the operating system to get to it, you can add on
> a hundred or couple hundred cycles) are definitely
> more expensive than even a few jmpa instructions.
> Now, this may be very feasable if stores were
> extremely frequent and the garbage collector had
> direct control of the processor, however, these
> situations are most unlike what you will find in
> even most Java implementations.
>    Elaborating, the F-CPU has a prodigious amount
> of registers meaning that, ideally, memory accesses
> will be very infrequent (so code size advantages are
> greatly nullified). Further, you can just as well
> emulate this functionality by preceding or succeeding
> every store instruction with a syscall instruction
> (for reasons cited above, however, this is not
> even desirable). Another trick is using memory
> instructions that trap if done on unaligned addresses
> (even x86 hardware can do this!). If I were to truly
> implement a write barrier that trapped every store
> on the F-CPU, I would have the address of GC
> write-barrier code pre-loaded in a dedicated register
> and simply issue a jmpa (with return address safely
> stashed in another register) to the GC code, examine
> the instruction to find out where the write was
> happening and with what (or include this information
> encoded after the jmpa and notch the return address,
> however, this is unnecessary because of simple F-CPU
> instruction encoding). This is not only compact but
> much more efficient than any trap.
>     However, I said if I were to implement a write=
> barrier that trapped every store instruction. :)
> For a generational garbage collector, and maybe even
> an incremental one, it is very sufficient to just
> use the vanilla features on any MMU. Simply write
> protect the page which holds the heap area you
> with to protect. When a store is done on this
> page, the page in which the write was done is
> recorded and the page added to a list of dirty
> pages managed by the garbage collector. Following
> this, the page's write-protection is *removed*.
> All succeeding writes are now practically free
> and you just need to re-examine the recorded page
> later and re-write-protect it when the need arises.
>
>            = ;             M= y $0.02 USD on Java and GC,
>            = ;             L= ee Salzman
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Yann Guidon Mon Jan 22 01:33:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04412 for ; Mon, 22 Jan 2001 02:34:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:55 +0100 (MET) Received: (qmail 14787 invoked by uid 0); 22 Jan 2001 00:38:23 -0000 Received: from unknown (HELO ef.egroups.com) (64.211.240.229) by 10.1.4.106 (mx06) with SMTP; 22 Jan 2001 00:38:23 -0000 X-eGroups-Return: sentto-1101623-2073-980123271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 22 Jan 2001 00:28:24 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 00:27:51 -0000 Received: (qmail 94746 invoked from network); 22 Jan 2001 00:27:50 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 22 Jan 2001 00:27:50 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 22 Jan 2001 00:27:49 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12770 for ; Mon, 22 Jan 2001 01:27:40 +0100 (MET) Message-ID: <3A6B7FE1.26FEAB7E@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A69A9B5.55B26654@ifrance.com> <3A6A4BA4.C2DEE4D0@f-cpu.org> <3A6AF0C5.27A71976@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 01:33:37 +0100 Reply-To: f-cpu@egroups.com Subject: sizes (was : Re: [f-cpu] conferences) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 633ebd3b1bba84863b607141d724bf00 Status: R X-Status: N Nicolas Boulay wrote:
> You write a 64 bit unit, but in the near futur 128 bit could be used. = So
> if each unit could be double the size of this input and ouput. When yo= u
> synthetise your chip, you will choose the size of the register. That's=
> all. When i use the leon, i choose the size of the window register (2 = to
> 32 windows) and the size of the cache. Here, i want to possibly change=
> the size of the register.

mmmh ok now i get it.

The size of the registers is determined by the constant MAXSIZE.

Here is a copy/paste of the beginning of f-cpu_config.vhdl

package FCPU_config is

------------------------------------------------------
-- Most important F-CPU constants :
------------------------------------------------------

-- Number >=3D2, 3 corresponds to 64-bit registers
  constant LOGMAXSIZE : natural :=3D 3;

-- Size of the registers in bytes
  constant MAXSIZE : natural :=3D 2**LOGMAXSIZE;

-- Size of the registers in bits.
  constant UMAX : natural :=3D MAXSIZE * 8;

-- Range of a register width declaration.
  subtype F_RANGE is natural range UMAX-1 downto 0 ;

-- shortcut for a very common declaration.
  subtype F_VECTOR is std_ulogic_vector(F_RANGE) ;

-- MAX_CHUNK_SIZE in bits
  constant MAX_CHUNK_SIZE : natural :=3D 64 ;


Note that MAX_CHUNK_SIZE determines the size of the SIMD chunks.
it is not fixed to 64-bits : SIMD "subdomains" can be 32-bits
only, as well as 128-bits...


> Yann Guidon a =E9crit :
> >
> > hello,
> >
> > Nicolas Boulay wrote:
> > >
> > > Don't forget to put a constant on the unit that could double= (*4,*8,...)
> > > the size of the output. For 64, 128, 256 bit large register,= ... For some
> > > application such big registers could be more interresting th= an a FPU.
> >
> > i don't understand what you write ... example ?
> >
> > > If the algorithme need a longer longest path. Maybe we can a= dd some
> > > pipeline stage.
> >
> > ?
> >
> I don't know how you will make your design but by doubling the size of=
> the register could increase the longuest path. So it will be better to=
> create a new pipeline stage.

we'll have probably the occasion to put this advice in practice ;-)

> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Yann Guidon Mon Jan 22 01:33:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04418 for ; Mon, 22 Jan 2001 02:34:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:57 +0100 (MET) Received: (qmail 2442 invoked by uid 0); 22 Jan 2001 00:49:13 -0000 Received: from mx04.rz2.gmx.net (HELO hj.egroups.com) (10.1.72.104) by mxi1.gmx.net (mxi1) with SMTP; 22 Jan 2001 00:49:13 -0000 X-eGroups-Return: sentto-1101623-2071-980123269-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 22 Jan 2001 00:28:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 00:27:48 -0000 Received: (qmail 92786 invoked from network); 22 Jan 2001 00:27:47 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 22 Jan 2001 00:27:47 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta3 with SMTP; 22 Jan 2001 01:28:52 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12773 for ; Mon, 22 Jan 2001 01:27:43 +0100 (MET) Message-ID: <3A6B7FE3.A526A384@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 01:33:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7673a47214a82bcd318a6cbd928042e0 Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann Guidon wrote:
> > > > > I think you are looking at the wrong place for the properties
> > > > > you seek, look at low-power processing (mobile) or massively parallel processing
> > > > > (DSP/media-processing).
> > > > But alas the F-CPU has too do all 3 markets and more.
> > ??? was it a joke ? or you really meant it ?
> > Nobody said that the F-CPU was AIMED at mobile applications.
> I meant in this case that the F-CPU still is a General processor.
> I don't expect a F-CPU in my phone but a F-CPU Could be used in a
> Laptop or a Rack of 16 servers. For now the core is High end PC's
> but with a  open design that could change overnight.
ok : now it's clear.

> > There are already enough cores for this branch.
> > The primary idea was to propose an architecture that could compete
> > with IA64 for the high-end and personal computers. the FC0 is a
> > first step that we have to reach, so we chose to leave it rather
> > simple and compact. It's something that should be implemented
> > with much less pain than any IA64 CPU. Then we'll decode more
> > instructions.
> This has me confused. What is the critical data path
> for the f-Cpu? Off hand I don't think it is in instruction fetching
> or decoding.
indeed, it is. Even though we can pipeline almost everything,
>from the adder to the multiplier, the control logic for the decoder
is less easy to pipeline. i am not sure that the FC0 decoder will
fit in the aimed 6 gates of latency. this stage does a LOT of things
at the same time. Maybe it will fit in 10 or 8 gates, but 6 gates will
be tough.
And that's only 1 instruction. For more instructions, "it's a whole new problem".
I think that the team has started to succeed to reach good results for the
"execution" side of the CPU. the control/decoding/scheduling is less straight-forward
because it contains a lot of different problems.
So i think that decoding IS the major problem when we want to execute more
instructions per cycle.

> > > If you compromise on everything you end up with
> > > something which excels at nothing.
> > at least now we excel at ... discussing ?
> > i gotta update the french translation of the manual...
> Well I better read the English Version.
of course :-) So do the french people (they want to read the french version).

> > > Marco
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ben.
> PS.All the game I can afford are $5 DOS games at the garage sales.
:-D
ain't the F-CPU a great strategy/RPG game ? :-P

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann Guidon Mon Jan 22 02:13:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04424 for ; Mon, 22 Jan 2001 02:34:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:58 +0100 (MET) Received: (qmail 3710 invoked by uid 0); 22 Jan 2001 01:07:59 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx14) with SMTP; 22 Jan 2001 01:07:59 -0000 X-eGroups-Return: sentto-1101623-2075-980125654-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 22 Jan 2001 01:07:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 01:07:34 -0000 Received: (qmail 98121 invoked from network); 22 Jan 2001 01:07:34 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 22 Jan 2001 01:07:34 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 22 Jan 2001 01:07:33 -0000 Received: from f-cpu.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA01046 for ; Mon, 22 Jan 2001 02:07:29 +0100 (MET) Message-ID: <3A6B8945.4B2BDB64@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> <3A64AA24.529272DF@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 02:13:42 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f33e8b30a74045258cda7e5644d5ed7 Status: R X-Status: N hi,

Ben Franchuk wrote:
> Nicolas Boulay wrote:
<snip>
> Pipelining the memory helps but this is
> near the limit of physics here for speed. As clock speeds get faster
> it not possible to build bigger caches, so I am asking are there alternatives
> to large caches?
yes : multiple banks.
look at a CDC6600 ;-P it ran at 35MHz with core memory...
the trick is that there were 8 individual/parallel/interleaved memory banks.
the bank was determined with the 3 LSB of the pointer so you ran
full-speed with linear access ("vector loop") code.

Something similar can be found in the F-CPU : there are 3 "stream hint bits"
that can say where a datum is located for a Load/store instruction.

The historical problem is the bandwidth and the number of pins.
we can't put 100K pins on the die... yet...

> > No more with smt.
> I have read the F-manual again, but it still does not explain
> SMT. Can some explain the details of that here?
Nicolas has sent a PDF about that last week.
SMT means "simultaneous multi-threading" and it multiplexes
instructions from different threads as to fill the bubbles
in a pipeline.

> The rest of the F-CPU still looks clean and well thought out
> and I can understand it all.
pfiuh ! all that work was finally worth :-)))

> The only change I can think of  make is adding a few more instructions
> to the increment unit. Incriment/decriment by word size might
> be useful. Also this would permit the control unit to decode
> addi,subi #1,#word size as special cases and send it to the faster
> increment unit.

probably.
The Xbar necessarily has provision for sending a constant
to a unit. now the problem is to include this feature in the INC unit's structure
(INC has already reached the latency limit of the pipe stage...).

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Yann Guidon Mon Jan 22 02:13:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04427 for ; Mon, 22 Jan 2001 02:34:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:34:59 +0100 (MET) Received: (qmail 30334 invoked by uid 0); 22 Jan 2001 01:08:42 -0000 Received: from unknown (HELO ho.egroups.com) (64.211.240.236) by mx0.gmx.net (mx17) with SMTP; 22 Jan 2001 01:08:42 -0000 X-eGroups-Return: sentto-1101623-2076-980125655-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 22 Jan 2001 01:08:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 01:07:35 -0000 Received: (qmail 57421 invoked from network); 22 Jan 2001 01:07:33 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 22 Jan 2001 01:07:33 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 22 Jan 2001 01:07:33 -0000 Received: from f-cpu.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA19107 for ; Mon, 22 Jan 2001 02:07:30 +0100 (MET) Message-ID: <3A6B8943.909BA0F1@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> <3A64AA24.529272DF@jetnet.ab.ca> <3A6B2448.800F986E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 02:13:39 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 20e411617ebefbb1fc3c91d600fb672e Status: R X-Status: N Nicolas Boulay wrote:
> reHello,
idem again,

> Ben Franchuk a =E9crit :
> > Nicolas Boulay wrote:
> > > Go to your bios of your computer, then turn off your cache L= 1 and L2
> > > (called internal and external cache). And you will see what = happen...
> > Yes I know massive slow down.
<snip>
> > Pipelining the memory helps but this is
> > near the limit of physics here for speed. As clock speeds get fas= ter
> > it not possible to build bigger caches, so I am asking are there = alternatives
> > to large caches?
> You can try to reduice the size of the code at the maximum, to save > space.
that's only one side of the problem. What about the data ????

> I try to propose to make something which look like the opposite
> of CISC. In CISC, you have a 32 bit decoders and some instruction abou= t
> 20 byte. Here, i propose to have a larger decoder compare to the size = of
> usual instruction. Imagine having a 64 bit decoders with 64, 32 and 16=
> bit instruction. The goal is to avoid to have unused bit inside
> instruction, it's waste of space. It's used by TI to reduice code
> footprint for this DSP (32 bit decoder with 8 to 48 bit instruction).<= BR> > ARM use a different technique. There have 32 instructions RISC
> processors, and make a compact subset of 16 bit instructions. They hav= e
> also an instruction to change the type of the instruction used. They > lose a little performance but have a gain of somethink like 30-40% in<= BR> > code size.
unless you're running in a smartcard, it's useless.
you better try to :
- remove all the "dead code"
- use the best optimisation flags with a good compiler (you win your 30%) - pack your data with the right alignment and avoid all the
  useless temporary representations or tables
- reuse as much data and code as possible
etc...
the list is endless, look at a good book.

Coding in HLL often hides the real loss in space.
C is particularly wasteful. C++ is even worse.
coding in asm might give you good results (if you care
to analyse properly your application).

there's no magic, no secret.

> > Ben.
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Ben Franchuk Wed Jan 17 01:10:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA04430 for ; Mon, 22 Jan 2001 02:35:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 02:35:00 +0100 (MET) Received: (qmail 30383 invoked by uid 0); 22 Jan 2001 01:21:58 -0000 Received: from mq.egroups.com (208.50.144.79) by 10.1.4.106 (mx06) with SMTP; 22 Jan 2001 01:21:58 -0000 X-eGroups-Return: sentto-1101623-2077-980126495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 22 Jan 2001 01:21:46 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 01:21:35 -0000 Received: (qmail 76992 invoked from network); 22 Jan 2001 01:21:35 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 22 Jan 2001 01:21:35 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 22 Jan 2001 02:22:39 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA12597 for ; Sun, 21 Jan 2001 18:14:39 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A64E313.6661F79@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> <3A6B7FE3.A526A384@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 16 Jan 2001 17:10:59 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c0224ead0fe707ce0dd7fe7c51532be0 Status: R X-Status: N Yann Guidon wrote:
>
> hi !
> indeed, it is. Even though we can pipeline almost everything,
> from the adder to the multiplier, the control logic for the decoder
> is less easy to pipeline. i am not sure that the FC0 decoder will
> fit in the aimed 6 gates of latency. this stage does a LOT of things
> at the same time. Maybe it will fit in 10 or 8 gates, but 6 gates will
> be tough.

Yes you are right,as register decoding is done here too.
You got 3 gates to decode the registers and 3 gates to select register set from
the
instruction register. Close indeed as any gates over 4 inputs may map poorly
to the hardware technology.

> And that's only 1 instruction. For more instructions, "it's a whole new problem".
> I think that the team has started to succeed to reach good results for the
> "execution" side of the CPU. the control/decoding/scheduling is less straight-forward
> because it contains a lot of different problems.
> So i think that decoding IS the major problem when we want to execute more
> instructions per cycle.

Also as I still not have figured how SIMD instructions work with the F-CPU
so I can't see decoding impact here.

> ain't the F-CPU a great strategy/RPG game ? :-P
Right now I am playing a NICE adult game from Japan (translated into english).
Shapely females look better than a blob of plastic with a [F@] on it. :)

> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ben.
PS. You would think that since France is the LAND of romance you would have
some nice adult games from there.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Yann Guidon Mon Jan 22 02:13:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00324 for ; Mon, 22 Jan 2001 15:11:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:37 +0100 (MET) Received: (qmail 7603 invoked by uid 0); 22 Jan 2001 01:40:42 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx22) with SMTP; 22 Jan 2001 01:40:42 -0000 X-eGroups-Return: sentto-1101623-2074-980125654-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 22 Jan 2001 01:07:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 01:07:34 -0000 Received: (qmail 96925 invoked from network); 22 Jan 2001 01:07:33 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 22 Jan 2001 01:07:33 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 22 Jan 2001 02:08:38 -0000 Received: from f-cpu.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA21439 for ; Mon, 22 Jan 2001 02:07:29 +0100 (MET) Message-ID: <3A6B8944.5B91FA55@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> <3A6998E8.C494D870@f-cpu.org> <20010120165956.16075@thrai.stud.uni-hannover.de> <3A6A4BA5.7F3104F2@f-cpu.org> <20010121143943.46340@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 02:13:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e5d5b9baca53ce196c5cd2a861d361df Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Jan 21, 2001 at 03:38:29AM +0100, Yann Guidon wrote:
> [...]
> > that's an interesting problem but if we extend the shifter to 2 stages,
> > there's certainly enough room. The ROP2 unit's "chunks" are slightly larger
> > and do more diverse things. I don't think that there's a benefit if we "chain"
> > the SHL to the ROP2 unit. ROP2 is more "exhaustive" and flexible, while the
> > added optional logic in SHL is like a "goodie" (if we have some transistors left).
> It's not a room (or delay) problem, IMHO.  The ROP2 unit is the more
> logical (sic!) place to do the bit operations.  The SHL can also do it,
> but it will require lots of additional control logic (which is already
> fairly complex).
mmmm...

my todo list has exploded.

"merging" the ROP2 and the SHL is a major pain because
only the Xbar is meant to transmit data (it keeps the scheduler simple).

Now, if you code

  bitop r1,r2,r3 (assuming SHL is 1 cycle)
  and   r4,r5,r6 (unit hazard here !)

How will the decoder detect the hazard ?
Ok; the solution is rather simple /here/ (just a few flip-flops and
simple gates) but if this becomes a habit, the decoder might become
soon as complex as a PowerPC or x86 decoder.

bitop etc. are fairly optional features, they are supported if enough
ressources are available, ie if the critical datapath is not bloated.
Otherwise, if we want to support ALL the optional features,
the chip will never see the light of the day :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann Guidon Mon Jan 22 01:33:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00327 for ; Mon, 22 Jan 2001 15:11:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:38 +0100 (MET) Received: (qmail 27925 invoked by uid 0); 22 Jan 2001 02:14:03 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx17) with SMTP; 22 Jan 2001 02:14:03 -0000 X-eGroups-Return: sentto-1101623-2072-980123270-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 22 Jan 2001 00:28:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 00:27:50 -0000 Received: (qmail 53960 invoked from network); 22 Jan 2001 00:27:49 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 22 Jan 2001 00:27:49 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 22 Jan 2001 00:27:48 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA26634 for ; Mon, 22 Jan 2001 01:27:43 +0100 (MET) Message-ID: <3A6B7FE2.6789E633@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> <3A6A4BA0.5E7DB94A@f-cpu.org> <3A6AEDC2.9D304989@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 01:33:38 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 96cc6d7e1acdf744da5b7a9cd01fc048 Status: R X-Status: N hi !

Nicolas Boulay wrote:
> Hello,
> Yann Guidon a =E9crit :
> > Nicolas Boulay wrote:
> > > Since the beginning, i try find a way to speed up the fcpu w= ithout the
> > > need of OOO and register renaming.
> > better SMT than OOO... FC0 is already OOOC and it's a good enough= compromise.
> OOOC isn't the same usfullness as OOO.
it depends. OOOC requires good binaries, while OOO is meant to compensate f= or
"old" binaries. We have no old binaries, so we can make good code= from the start.

But if you look closely, OOOC is simply a "reversed" OOO.
OOO is like a normal CPU, or OOOC, with the "completion" unit at = the end
of the pipeline, instead of at the decoder stage. OOO adds renamed register= s.
Otherwise, it's roughly similar.

> > > 64 registers are good but if you have
> > > a depencies of 8 instructions (with big pipelining) you coul= d execute 8
> > > instruction at the same times. that's good.
> > wrong. You forget that an instruction has (in average) 2 sources<= BR> > > and 1 destination. so we can do 64/3=3D21 instructions without st= alling.
> > that's 2*2*5 or 3*7 and optimistic because in reality, it's never= that easy.
> Sorry, i was much more too optimistik ;p
maybe you should write more asm code ;-P

> > > To had more register as for
> > > Sparc, windowed register with 2 more ASM instructions to sli= de the
> > > windows could increase the number of usable register. But i = think you
> > > could only save some access to the main memory.
> > explicit renaming is interesting but it creates enough troubles > > everywhere that we must be very careful. It adds more information= s
> > to store, to backup (how ?) and keep coherent.
> If you know when you slide the window, you could save your register > (it's only slower)
in fact, my problem with explicit renaming (window shifting) is the
"fragmentation". let me explain it.

register windows, in our case, is meant to increase the number of logical and usable registers. But in real cases, we access register in a almost-ran= dom
fashion. this means that in the worst case, we would have to "slide&qu= ot; the window
three times per instruction (with 3-op instructions) because the operands a= re all
out of reach. reducing this is a big pain for the compiler.

> > > The first thing to do to execute more than 1 inst per clock = cycle is to
> > > try to use during the same times differents units. But you h= ave to
> > > reconise which instruction could be use in the same times. > >
> > i've thought about a trick to detect if 2 instructions (or any nu= mber)
> > could be issued at the same time. If we estimate that the unit is= coded
> > in the opcode and only in the upper part, a 6-bit substract could= done
> > between 2 consecutive instructions. If the result is above a cert= ain limit,
> > there's no chance of unit hazard. This can be applied in parallel=
> > with a reasonable amount of different instructions.
>
> No really, 2 concecutives instruction could see as in the same bloc wi= th
> your scheme. And read a bit is much more easy. (imagine to do 6
> substracts for 6 decoders, it's make a very long path)

you forget a little detail...
1) the substracts are in parallel
2) we don't make a DSP, but a platform that will run with several kinds
of cores. pairing rules that apply to a core will give bad performance
on other cores. look at the transition from the Pentium to the PII,
and from PII/PIII to P4.

This means that we have to find a "generic" way to do this.

Fortunately, we have enough time to search a good method, because we
better build a 1-inst/cycle version before designing a larger version
that would never exist and force us to use a specific and possibly wrong method.

> > > So i propose to add a depencies bit inside the instruction.<= BR> > > too late.
> Hum, i don't think so, the insctruction as been defined with the binar= y
> code, but without knowing what all is need.
I have first tried to promote a 7-bit opcode.
After the instruction census started, it appeared that it would not be enou= gh.

> A good number of instruction have been chosen, but why not change how = to
> code all of this ? Nothing is written about it (in vhdl).
how/what do you want to change ?

> > > All consecutive instruction with the bit equal could be used= in parallel.
> > > You will have packet with 1, then a packet with 0.
> > are you just copying the c6x or what ? :-P
> YES ! But it seems so easy to use it for variable lenght superscalar > processor !
too easy. so easy that it will trap you later.

The case is easy for the C6x : TI controls everything and the target market=
is very limited. The CPU is meant to run "trusted code" that is m= eant to be perfect.
In the F-CPU world, the chip will certainly be used in a multi-user station=
that can run "untrusted" code and even viruses. We don't control = the evolution
of the core (anybody can modify it) and TI's "trick" will reach i= ts limits quickly.
For example : imagine that we implement that in the FC1. Everything will be= fine.
Now somebody makes FC2 with a different decoder/execution pipeline. The bit= s
that you have put in the instruction will not be useful at all, so you wast= e 1/32
of the memory bandwidth. Now, somebody generates badly packed instructions<= BR> (the packet bit is wrong). Will the CPU burn ?
Intel knew these problems and have not implemented a "pure" VLIW = for the IA64.
scalability and security are very important problems and it's priority #1 i= n the
project.

> > > If the fcpu have many decoder, he could launch every packet = in the same
> > > time if he had enought unit. So a coding rules will be to in= terleave the
> > > use of the different unit. And after that you could add one = more adder
> > > and speed up the code a little bit.
> > >
> > > I think it's easy what do you think of it ?
> > it's incomplete. the register hazards are another problem.
> No, it's totally fixe by the dependance bit. You just have to check th= e
> code of the instruction. Scoreboard are used in the same manner as
> befor.
outside of the opcode, every additional information is considered as
"hint" (indice) that is meant to enhance the performance of the c= ode.
The problem here is that your bit is not general enough. You can use
this for superscalar cores, ok, but it's useless for OOO cores or
single-issue cores (like the FC0).
Maybe you can pack all your bits inside one instruction,
inside a 16-bit field. This instruction is interpreted as NOP on
the architectures that don't use it. Otherwise, it can contain
almost any hint about a packet of instructions. You can prefix a
packet of 7 or 15 instructions with one "hint" instruction that will inform (early !) the decoder of the dependencies inside the packet. THAT is a possible solution and compromise.

> > I propose several alternatives that can be used in conjunction. > > - The "VLIW" approach has been studied... a lot and sin= ce a long time.
> > the raw VLIW and the superscalar approaches can't be used verbati= m,
> > something more synthetic and flexible must be used.
> That's not what i propose ?
no. It's "too simple" and you hit the wall when you exceed the ta= rget goal.
more specifically : it's not flexibe enough.

> > A good way to help is with the help of a "hint instruction&q= uot;,
> > something that is decoded as NOP when it is not supported,
> > but otherwise explicits the data and unit hazards for the
> > next N instructions. The format is not yet determined, it must > > fit in 24 bits, that's all.
> no, you can't do that without having an explosion of the code size. i explained in the above paragraph how you avoid this code explosion.
And when you're not inside a critical section, you can remove this
hinting instruction. OTOH when you're sure that the code runs 99% in the ca= che,
you can use (in average) 1 hint instruction ("PACK") every 8 inst= ructions
(the first 32 bits of a 256-bit wide cache line).

THAT is what i call flexible ;-P

> > - The "dynamic" approach. it is similar to the Pentium = or P4 approach :
> > the instructions are decoded when they enter the Instruction cach= e,
> > the register and unit hazards are decoded, so there's a performan= ce hit
> > only at the first execution. The Pentium did that for decoding th= e
> > packet (instruction pairs) : the data from the cache is executed = once,
> > the instructions boundaries are written to the instruction cache,=
> > so for the next executions, the decoder already knows if it can e= xecute
> > 1 or 2 instructions.
>
> It's the story of the trace cache, read
> http://www.emulators= .com/pentium4.htm and you will hate the trace cache
> : it's a gain of decoding but your 96 Kbyte of cache is like a 8Ko of = L&
> cache compare to the 128 Ko of the athlon.

i spoke about the old good P53C (the "Pentium" that sits on my de= sk), not
about the newer "P4" (expensive and deceiving).

"trace cache" would be in a RISC->TTA core, but since it's a R= ISC ISA
as input, there is much less bloat ;-)

> > Since it is regenerated everytime, it's "dynamic" and i= s independent
> > from the rest.
> But too small !
hey ! we don't have to decode x86 instructions !
one RISC instruction (32-bits) can generate in average 3 TTA instructions (4 or 5 for L/S) and these instructions are commonly 16-bits
(it can be changed easily because it's internal and hidden to the user). i expect around 30% bloat but much more parallelism !

> > - Better : a F-CPU/RISC->TTA translator. it's implicitely OOO = but
> > it might be very interesting. the instructions are recoded as TTA=
> > instructions and stored in a big buffer acting as the instruction= cache,
> > it's similar to the P4 architecture but less heavy :-)
> Bof, too far from our risc architecture, and maybe hard to make it
> parallel.
far from it. You're too young on the list ;-P when AlphaRisc was there,
he would have flamed you for that remark ;-D TTA has certain advantages
and a RISC->TTA core would be a good solution to bypass the patents on the OOO cores.

> > - SMT. did you forget that ? :-)
> In smt, you don't increase the number of instruction issued by clock c= ycle !
au contraire. You enhance the use of the decoder and the execution units. OTOH you completely overflow the memory bandwidth ... but it'd another disc= ussion.

An illustration of what i said is with "lazy SMT". it's for examp= le a
core with 4 instructions issued at every cycle, from 4 different threads (a bit like 4xFC0 in parallel). The dependency checks are only local.
When there is a "bubble", you can check the neighbours to sse if = they can execute
another instruction that would fill the empty slot.
So then YES SMT /can/ increase and ease this increase in IPC.

read you all tomorrow,

> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Michael Riepe Mon Jan 22 02:25:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00330 for ; Mon, 22 Jan 2001 15:11:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:41 +0100 (MET) Received: (qmail 2522 invoked by uid 0); 22 Jan 2001 02:50:28 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx21) with SMTP; 22 Jan 2001 02:50:28 -0000 X-eGroups-Return: sentto-1101623-2078-980126732-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 22 Jan 2001 01:25:37 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 01:25:32 -0000 Received: (qmail 38493 invoked from network); 22 Jan 2001 01:25:31 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 22 Jan 2001 01:25:31 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.30) by mta2 with SMTP; 22 Jan 2001 01:25:29 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02507; Mon, 22 Jan 2001 02:25:25 +0100 Message-ID: <20010122022525.31883@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> <3A6998E8.C494D870@f-cpu.org> <20010120165956.16075@thrai.stud.uni-hannover.de> <3A6A4BA5.7F3104F2@f-cpu.org> <20010121143943.46340@thrai.stud.uni-hannover.de> <3A6B8944.5B91FA55@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A6B8944.5B91FA55@f-cpu.org>; from Yann Guidon on Mon, Jan 22, 2001 at 02:13:40AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 02:25:25 +0100 Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 70a6c4fa4211653bfdf0892bc30f7d26 Status: R X-Status: N On Mon, Jan 22, 2001 at 02:13:40AM +0100, Yann Guidon wrote:
[...]
> "merging" the ROP2 and the SHL is a major pain because
> only the Xbar is meant to transmit data (it keeps the scheduler simple).
[...]

I do not suggest to merge them.  I just think we should move the
bitop instruction from the SHL unit to the ROP2 unit, where it belongs.
After all, bitop is a logical operation, not a shift operation -- and the
`1 << n' part can be done faster and cheaper with a 6-to-64 decoder than
with the comparatively slow SHL unit.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From "Marco Al" Mon Jan 22 10:45:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00354 for ; Mon, 22 Jan 2001 15:11:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:47 +0100 (MET) Received: (qmail 20799 invoked by uid 0); 22 Jan 2001 09:37:34 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx16) with SMTP; 22 Jan 2001 09:37:34 -0000 X-eGroups-Return: sentto-1101623-2079-980156246-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 22 Jan 2001 09:37:29 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 09:37:25 -0000 Received: (qmail 20526 invoked from network); 22 Jan 2001 09:37:25 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Jan 2001 09:37:25 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 22 Jan 2001 09:37:25 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 694B62ACB for ; Mon, 22 Jan 2001 10:37:24 +0100 (CET) Message-ID: <004b01c08458$15194520$29e65982@student.utwente.nl> To: References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> <3A6B7FE3.A526A384@f-cpu.org> <3A64E313.6661F79@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 10:45:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fc51380890f731a584484fb035cc6e63 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> > it not possible to build bigger caches, so I am asking are there
alternatives
> > to large caches?
> yes : multiple banks.


You will not overcome 100's of cycle of latency, no matter how many registers
you throw at the problem (in fact registers arent a realistic solution even at
this point in time IMO, if it isnt in the cache you stall).

From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>


> Close indeed as any gates over 4 inputs may map poorly
> to the hardware technology.

Nicolas is right, this is not a very usefull way to look at it. At some point
you will have to go to semi-custom, use what works best (for instance most high
performance shifters Ive seen described use 4:1 mux's, 6 inputs, and the most
appropriate adder structures would seem to consist of 4 or even 8 bits CLA's
which I doubt you want to make by synthesis)

This will be a slight problem AFAICS, VHDL and synthesis are close enough to
programming to find some people who can become proficient at it and have some
free tools available... but both the tools and the skills for library
development in deep sub micron processes are a little more rare (for instance
are there any free tools which can do phase shift compensation etc. ?) and of
course for layout we will need commercial tools regardless. And then there's
timing verification...

Marco
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann GUIDON Mon Jan 22 12:15:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00372 for ; Mon, 22 Jan 2001 15:11:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:54 +0100 (MET) Received: (qmail 28542 invoked by uid 0); 22 Jan 2001 11:21:25 -0000 Received: from unknown (HELO ej.egroups.com) (64.211.240.230) by mx0.gmx.net (mx22) with SMTP; 22 Jan 2001 11:21:25 -0000 X-eGroups-Return: sentto-1101623-2080-980162481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 22 Jan 2001 11:21:24 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 11:21:20 -0000 Received: (qmail 6226 invoked from network); 22 Jan 2001 11:21:20 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 22 Jan 2001 11:21:20 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 22 Jan 2001 12:22:25 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA03570; Mon, 22 Jan 2001 03:21:17 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DCLTWVMS; Mon, 22 Jan 2001 11:26:02 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A6C1636.EC31DB8@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> <3A6B7FE3.A526A384@f-cpu.org> <3A64E313.6661F79@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 12:15:02 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f848e1048c78c844b7da0d7814e1c03a Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann Guidon wrote:
> >
> > hi !
> > indeed, it is. Even though we can pipeline almost everything,
> > from the adder to the multiplier, the control logic for the decoder
> > is less easy to pipeline. i am not sure that the FC0 decoder will
> > fit in the aimed 6 gates of latency. this stage does a LOT of things
> > at the same time. Maybe it will fit in 10 or 8 gates, but 6 gates will
> > be tough.
>
> Yes you are right,as register decoding is done here too.
> You got 3 gates to decode the registers and 3 gates to select register set from
> the instruction register. Close indeed as any gates over 4 inputs may map poorly
> to the hardware technology.

reading the register is done speculatively on the 3 fields and it takes 3 or 4 gates,
it's not the problem. the critical datapath is whether the instruction is "issued"
(valid) : OPCODE is OK, write slot (in the Xbar) Ok, registers (read) are OK, unit
is ready, pointer is valid etc... that will take some gates.

> > And that's only 1 instruction. For more instructions, "it's a whole new problem".
> > I think that the team has started to succeed to reach good results for the
> > "execution" side of the CPU. the control/decoding/scheduling is less straight-forward
> > because it contains a lot of different problems.
> > So i think that decoding IS the major problem when we want to execute more
> > instructions per cycle.
>
> Also as I still not have figured how SIMD instructions work with the F-CPU
> so I can't see decoding impact here.

in fact the impact is ... almost inexistant, at least today.
All instructions are SIMD by definition. if you have a 8 or 32-bit operation
makes no difference at the decoding stage, except for some known cases (ie multiply)
because it changes the latency, but it's "static" (known by construction).
So we issue instructions and the units treat the data in SIMD.
However the difference is when the data is written back to the register :-)
only one part or the whole register is written/validated, if it's SIMD or not.
ok, it consumes some power, but it's sooo simple for the decoder?scoreboard etc... :-)
and for the execution units, only the SIMD versions are designed. you don't have
to care for different gated clocks etc...

So all we need to care is the write back cycle, the registers are partially written,
that's all.

> > ain't the F-CPU a great strategy/RPG game ? :-P
> Right now I am playing a NICE adult game from Japan (translated into english).
> Shapely females look better than a blob of plastic with a [F@] on it. :)
>
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ben.
> PS. You would think that since France is the LAND of romance you would have
> some nice adult games from there.

France is the land of cheese, dark chocolate, tourism and silliness.
if you're looking for adult stuff, you will not find them here...

YG

speaking for himself
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann GUIDON Mon Jan 22 12:22:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00375 for ; Mon, 22 Jan 2001 15:11:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 15:11:55 +0100 (MET) Received: (qmail 23707 invoked by uid 0); 22 Jan 2001 11:29:22 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.112 (mx12) with SMTP; 22 Jan 2001 11:29:22 -0000 X-eGroups-Return: sentto-1101623-2081-980162957-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 22 Jan 2001 11:29:21 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 11:29:17 -0000 Received: (qmail 66458 invoked from network); 22 Jan 2001 11:29:16 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 22 Jan 2001 11:29:16 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 22 Jan 2001 11:29:16 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA04143; Mon, 22 Jan 2001 03:29:13 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DCLTWVM7; Mon, 22 Jan 2001 11:33:59 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A6C1813.45C86951@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> <3A6998E8.C494D870@f-cpu.org> <20010120165956.16075@thrai.stud.uni-hannover.de> <3A6A4BA5.7F3104F2@f-cpu.org> <20010121143943.46340@thrai.stud.uni-hannover.de> <3A6B8944.5B91FA55@f-cpu.org> <20010122022525.31883@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 12:22:59 +0100 Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9dbe553353143ccd47e77a61e378ae5f Status: R X-Status: N hi,


Michael Riepe wrote:
> Yann Guidon wrote:
> > "merging" the ROP2 and the SHL is a major pain because
> > only the Xbar is meant to transmit data (it keeps the scheduler simple).
>
> I do not suggest to merge them.  I just think we should move the
> bitop instruction from the SHL unit to the ROP2 unit, where it belongs.
> After all, bitop is a logical operation, not a shift operation -- and the
> `1 << n' part can be done faster and cheaper with a 6-to-64 decoder than
> with the comparatively slow SHL unit.

the ROP2 unit is already full.

Plus, there's another problem :

SHL is a shuffler with a tiny logic level,
ROP2 is a exhaustive logic array with some additional bytewise OR/AND.

For the bitop, ROP2 would need to move the bytewise operations in front of
the logic level.

maybe we should drop this instruction temporarily ?
the opcode and behaviour is reserved, the implementation is
not too difficult but it doesn't fit in the FC0, it's not a catastrophe/drama...
plus, there's no bitop in high-level langages. we will have enough
time to implement it later...

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

YG

speaking for himself
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Ben Franchuk Wed Jan 17 08:29:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01151 for ; Mon, 22 Jan 2001 21:20:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 22 Jan 2001 21:20:26 +0100 (MET) Received: (qmail 25416 invoked by uid 0); 22 Jan 2001 17:00:15 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx17) with SMTP; 22 Jan 2001 17:00:15 -0000 X-eGroups-Return: sentto-1101623-2082-980182805-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 22 Jan 2001 17:00:15 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 17:00:05 -0000 Received: (qmail 82815 invoked from network); 22 Jan 2001 16:50:05 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 22 Jan 2001 16:50:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 22 Jan 2001 16:50:04 -0000 Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA07962 for ; Mon, 22 Jan 2001 09:43:03 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A6549CE.2BA14F59@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> <3A6B7FE3.A526A384@f-cpu.org> <3A64E313.6661F79@jetnet.ab.ca> <004b01c08458$15194520$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 00:29:18 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 517b337d53d123dc88ab11c73c021a99 Status: R X-Status: N Marco Al wrote:

> This will be a slight problem AFAICS, VHDL and synthesis are close enough to
> programming to find some people who can become proficient at it and have some
> free tools available... but both the tools and the skills for library
> development in deep sub micron processes are a little more rare (for instance
> are there any free tools which can do phase shift compensation etc. ?) and of
> course for layout we will need commercial tools regardless. And then there's
> timing verification...
>
At the very high speeds I guess still 90% of the layout still
will be by hand. Since I am using FPGA's for my Computer designs
I have not looked at this site, but some DAM fast chips are designed
here. Read all you can about Chuck Moore and his cad system. 
http://www.ultratechnology.com/people.htm
If you need to go commercial this guy is a good contact.
> Marco
Ben.
PS. Also a great place to buy a FORTH processor.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From "Iancu Silvius" Mon Jan 22 22:51:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02025 for ; Tue, 23 Jan 2001 00:23:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 00:23:06 +0100 (MET) Received: (qmail 13695 invoked by uid 0); 22 Jan 2001 22:20:17 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 22 Jan 2001 22:20:17 -0000 X-eGroups-Return: sentto-1101623-2083-980201966-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 22 Jan 2001 22:20:15 -0000 X-Sender: silvius@mail.dnttm.ro X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 22:19:25 -0000 Received: (qmail 61119 invoked from network); 22 Jan 2001 21:52:48 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Jan 2001 21:52:48 -0000 Received: from unknown (HELO terminus.dnttm.ro) (193.226.98.11) by mta1 with SMTP; 22 Jan 2001 21:52:44 -0000 Received: from silvius (ppp98.dnttm.ro [193.231.207.103]) by terminus.dnttm.ro (8.9.3/8.9.3) with SMTP id XAA32510 for ; Mon, 22 Jan 2001 23:52:30 +0200 Message-ID: <000901c084bd$6e687a00$569afea9@silvius> To: References: <980183449.592.99637.l10@egroups.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: "Iancu Silvius" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 23:51:01 +0200 Reply-To: f-cpu@egroups.com Subject: [f-cpu] "Remove" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 03f86e4fe2af2ff4e367cc5b3fb481ef Status: R X-Status: N
----- Original Message -----
From: <f-cpu@egroups.com>
To: <f-cpu@egroups.com>
Sent: Monday, January 22, 2001 7:10 PM
Subject: [f-cpu] Digest Number 257


> There are 24 messages in this issue.
>
> Topics in this digest:
>
>       1. Re: scalar processor
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       2. Re: Cache use?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       3. Re: conferences
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       4. Re: Cache use?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       5. Shared memory
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>       6. Re: Cache use?
>            From= : Ben Franchuk <bfranchuk@jetnet.ab.ca>
>       7. Re: Shared memory
>            From= : Lee Salzman <lee.salzman@lvdi.net>
>       8. Re: Cache use?
>            From= : "Marco Al" <marco@simplex.nl>
>       9. Re: Cache use?
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>      10. Re: Re: Shared memory
>            From= : Nicolas Boulay <nicolas.boulay@ifrance.com>
>      11. 2-Stage Shifter Proof Of Concept
>            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      12. Re: shifter (was Re: conferences) >            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      13. Re: Cache use?
>            From= : Yann Guidon <whygee@f-cpu.org>
>      14. Re: scalar processor
>            From= : Yann Guidon <whygee@f-cpu.org>
>      15. sizes (was : Re: conferences)
>            From= : Yann Guidon <whygee@f-cpu.org>
>      16. Re: shifter (was Re: conferences) >            From= : Yann Guidon <whygee@f-cpu.org>
>      17. Re: Cache use?
>            From= : Yann Guidon <whygee@f-cpu.org>
>      18. Re: Cache use?
>            From= : Yann Guidon <whygee@f-cpu.org>
>      19. Re: Cache use?
>            From= : Ben Franchuk <bfranchuk@jetnet.ab.ca>
>      20. Re: shifter (was Re: conferences) >            From= : Michael Riepe <michael@stud.uni-hannover.de>
>      21. Re: Cache use?
>            From= : "Marco Al" <marco@simplex.nl>
>      22. Re: Cache use?
>            From= : Yann GUIDON <whygee@f-cpu.org>
>      23. Re: shifter (was Re: conferences) >            From= : Yann GUIDON <whygee@f-cpu.org>
>      24. Re: Cache use?
>            From= : Ben Franchuk <bfranchuk@jetnet.ab.ca>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 1
>    Date: Sun, 21 Jan 2001 15:10:10 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: scalar processor
>
> Hello,
>
> Yann Guidon a =E9crit :
> >
> > Nicolas Boulay wrote:
> > > Since the beginning, i try find a way to speed up the fcpu w= ithout the
> > > need of OOO and register renaming.
> > better SMT than OOO... FC0 is already OOOC and it's a good enough=
compromise.
> >
> OOOC isn't the same usfullness as OOO.
>
> > > 64 registers are good but if you have
> > > a depencies of 8 instructions (with big pipelining) you coul= d execute
8
> > > instruction at the same times. that's good.
> > wrong. You forget that an instruction has (in average) 2 sources<= BR> > > and 1 destination. so we can do 64/3=3D21 instructions without st= alling.
> > that's 2*2*5 or 3*7 and optimistic because in reality, it's never= that
easy.
> >
>
> Sorry, i was much more too optimistik ;p
>
> > > To had more register as for
> > > Sparc, windowed register with 2 more ASM instructions to sli= de the
> > > windows could increase the number of usable register. But i = think you
> > > could only save some access to the main memory.
> > explicit renaming is interesting but it creates enough troubles > > everywhere that we must be very careful. It adds more information= s
> > to store, to backup (how ?) and keep coherent.
> >
> If you know when you slide the window, you could save your register > (it's only slower)
>
> > > The first thing to do to execute more than 1 inst per clock = cycle is
to
> > > try to use during the same times differents units. But you h= ave to
> > > reconise which instruction could be use in the same times. > >
> > i've thought about a trick to detect if 2 instructions (or any nu= mber)
> > could be issued at the same time. If we estimate that the unit is= coded
> > in the opcode and only in the upper part, a 6-bit substract could= done
> > between 2 consecutive instructions. If the result is above a cert= ain
limit,
> > there's no chance of unit hazard. This can be applied in parallel=
> > with a reasonable amount of different instructions.
> >
>
> No really, 2 concecutives instruction could see as in the same bloc wi= th
> your scheme. And read a bit is much more easy. (imagine to do 6
> substracts for 6 decoders, it's make a very long path)
>
> > > So i propose to add a depencies bit inside the instruction.<= BR> > > too late.
> >
> Hum, i don't think so, the insctruction as been defined with the binar= y
> code, but without knowing what all is need. A good number of instructi= on
> have been chosen, but why not change how to code all of this ? Nothing=
> is written about it (in vhdl).
>
> > > All consecutive instruction with the bit equal could be used= in
parallel.
> > > You will have packet with 1, then a packet with 0.
> > are you just copying the c6x or what ? :-P
> >
> YES ! But it seems so easy to use it for variable lenght superscalar > processor !
>
> > > If the fcpu have many decoder, he could launch every packet = in the
same
> > > time if he had enought unit. So a coding rules will be to in= terleave
the
> > > use of the different unit. And after that you could add one = more adder
> > > and speed up the code a little bit.
> > >
> > > I think it's easy what do you think of it ?
> > it's incomplete. the register hazards are another problem.
> >
> No, it's totally fixe by the dependance bit. You just have to check th= e
> code of the instruction. Scoreboard are used in the same manner as
> befor.
>
> > I propose several alternatives that can be used in conjunction. > > - The "VLIW" approach has been studied... a lot and sin= ce a long time.
> > the raw VLIW and the superscalar approaches can't be used verbati= m,
> > something more synthetic and flexible must be used.
>
> That's not what i propose ?
>
> > A good way to help is with the help of a "hint instruction&q= uot;,
> > something that is decoded as NOP when it is not supported,
> > but otherwise explicits the data and unit hazards for the
> > next N instructions. The format is not yet determined, it must > > fit in 24 bits, that's all.
> no, you can't do that without having an explosion of the code size. > > - The "dynamic" approach. it is similar to the Pentium = or P4 approach :
> > the instructions are decoded when they enter the Instruction cach= e,
> > the register and unit hazards are decoded, so there's a performan= ce hit
> > only at the first execution. The Pentium did that for decoding th= e
> > packet (instruction pairs) : the data from the cache is executed = once,
> > the instructions boundaries are written to the instruction cache,=
> > so for the next executions, the decoder already knows if it can e= xecute
> > 1 or 2 instructions.
>
> It's the story of the trace cache, read
> http://www.emulators= .com/pentium4.htm and you will hate the trace cache
> : it's a gain of decoding but your 96 Kbyte of cache is like a 8Ko of = L&
> cache compare to the 128 Ko of the athlon.
>
> > Since it is regenerated everytime, it's "dynamic" and i= s independent
> > from the rest.
>
> But too small !
>
> > - Better : a F-CPU/RISC->TTA translator. it's implicitely OOO = but
> > it might be very interesting. the instructions are recoded as TTA=
> > instructions and stored in a big buffer acting as the instruction= cache,
> > it's similar to the P4 architecture but less heavy :-)
> Bof, too far from our risc architecture, and maybe hard to make it
> parallel.
>
> > - SMT. did you forget that ? :-)
> In smt, you don't increase the number of instruction issued by clock > cycle !
> >
> > ok gotta sleep...
> >
> > > nicO
> > WHYGEE
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 2
>    Date: Sun, 21 Jan 2001 15:15:34 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Cache use?
>
> Yann Guidon a =E9crit :
> >
> > hi,
> >
> > Marco Al wrote:
> > > From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>= ;
> > > > Funny I thought that was Marketing people. Why else wou= ld I need a
new computer
> > > > after only 2 years?
> > > Games.
> > well, i don't need Tetris with Phong shading ;-)
> >
> > > > > I think you are looking at the wrong place for the= properties
> > > > > you seek, look at low-power processing (mobile) or= massively
parallel processing
> > > > > (DSP/media-processing).
> > > > But alas the F-CPU has too do all 3 markets and more. > > ??? was it a joke ? or you really meant it ?
> > Nobody said that the F-CPU was AIMED at mobile applications.
>
> But in fact, it will be the first used of it. Because it the simpler o= ne
> !
>
> > There are already enough cores for this branch.
> > The primary idea was to propose an architecture that could compet= e
> > with IA64 for the high-end and personal computers. the FC0 is a > > first step that we have to reach, so we chose to leave it rather<= BR> > > simple and compact. It's something that should be implemented
> > with much less pain than any IA64 CPU. Then we'll decode more
> > instructions.
> >
> > if you want to adapt the F-CPU for mobile applications, fine but = it's
> > not the goal. They specify heat and power dissipation as priority= #4
only.
> > The more important goals specify that the architecture should get= more
> > performance with an innovative architecture rather than with &quo= t;advanced"
> > funding technology, so we have to exploit every single transistor= .
>
> A=EFe ! ARM aren't made in specific funding technology at all. It use = just
> a different design, as a specific flip-flop design or so one. We can > make clock gating without loosing to much speed.
>
> >
> > These goals were voted in mid-1999 but i never thought that i wou= ld have
to
> > quote it so often... this shows that our preliminary efforts to > > better define the project were not vain.
> >
> > > If you compromise on everything you end up with
> > > something which excels at nothing.
> > at least now we excel at ... discussing ?
> > i gotta update the french translation of the manual...
> >
> > > Marco
> > WHYGEE
>
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 3
>    Date: Sun, 21 Jan 2001 15:23:01 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: conferences
>
> You write a 64 bit unit, but in the near futur 128 bit could be used. = So
> if each unit could be double the size of this input and ouput. When yo= u
> synthetise your chip, you will choose the size of the register. That's=
> all. When i use the leon, i choose the size of the window register (2 = to
> 32 windows) and the size of the cache. Here, i want to possibly change=
> the size of the register.
>
> Yann Guidon a =E9crit :
> >
> > hello,
> >
> > Nicolas Boulay wrote:
> > >
> > > Don't forget to put a constant on the unit that could double=
(*4,*8,...)
> > > the size of the output. For 64, 128, 256 bit large register,= ... For
some
> > > application such big registers could be more interresting th= an a FPU.
> >
> > i don't understand what you write ... example ?
> >
> > > If the algorithme need a longer longest path. Maybe we can a= dd some
> > > pipeline stage.
> >
> > ?
> >
> I don't know how you will make your design but by doubling the size of=
> the register could increase the longuest path. So it will be better to=
> create a new pipeline stage.
>
> > > nicO
> > WHYGEE
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 4
>    Date: Sun, 21 Jan 2001 15:29:27 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Cache use?
>
> Hello,
>
> Ben Franchuk a =E9crit :
> >
> > polz@writeme.com wrote:
> > .
> > > Unless everything they've been teaching me for the last 3 mo= nths is
wrong,
> > > the cache hit probability in a modern CPU is usually somewhe= re between
> > > 90% and 99%. I would not call shis a little saving.
> >
> > Compared to what? Cache was designed for the time when
> > CPU's had small amounts of data (<4K words) and CISC with
> > a lot of looping.Here a small cache ( few words ) would give
> > a 80%? hit rate on REPEATED data. The key word here is REPEATED > > data.In a modern RISC machine any repeated data is stuffed into a=
> > register and reused. A program that fits in the cache nowdays is = rare.
> >
>
> Go to your bios of your computer, then turn off your cache L1 and L2 > (called internal and external cache). And you will see what happen...<= BR> >
> > To me the fastest a cpu can GO is 2 cycles for a Van Neuman archi= tecture
> > and 1 cycle for a Harvard design. RISC's are Harvard WANT A BE's<= BR> > > thus they are about 1 3/4? cycles based on memory access. Rather = than
> > make a CPU faster make a CPU more efficient. Our design can SAVE = xx%
> > in a XXX architecture makes more sense to me than Marketing peopl= e
> > saying we are XX% faster than bla-bla-bla. The IBM PC with the 80= 86
> > cpu was slower than the 4Mhz Z80 8 bit cpu but they never told yo= u that.
> >
> >
> > Take a C program fragment  while(*s) *d++=3D *s++;
> > Here only a few program instructions are repeated.
> > Data is reused only once. A data cache here is not useful.
> > A large program cache is waste here.
> >
> Yes, but program cache will be very usefull.
>
> > > Pipelining is used so the parts of the CPU which would just = wait and
do
> > > nothing most of the time in a single-stage CPU get used more= often.
> > > Fetching, decoding and executing an instruction takes a cert= ain
ammount and
> > > at least a few clock cycles. In each stage of this process o= nly one
> > > part of the CPU is used. Pipelining lets you use the other p= arts at
> > > the same time so pipelining is a good thing.
> >
> > Two or three stages of pipelining is useful. 304 stages I would question.
>
> No more with smt.
>
> > I can see many stages of pipelining used to give a single ported = memory
> > the illusion of a multiported memory or fast shifting for a float= ing
point
> > unit, but still the adder delay in the alu is the most critical.<= BR> > > How ever with mult-ported memory and muilti-bit shifts in a singl= e stage
> > more common is that many stages of pipeline needed?
> > Also if the main memory can't keep up with a super fast CPU why b= uild
> > it so fast?
> Use cache ...
>
> >
> >
> > > > If say small 32 word
> > > > register program history and 16 word address cache for = virtual
memory
> > > > and a single stage of pipeline is used you may have ave= rage quality
> > > > single CPU but because the design is small you may dupl= icate the
> > > > CPU several times to give a fast multiprocessing cpu? > > > You can also duplicate a small pipelined CPU with cache and = make a
VLIW
> > > "multiprocessing" CPU. I beleive that's basically = what the smart
people
> > > on this list are doing.
> > >
> > > I suggest you take a class on computer architecture keep lur= king on
this list
> > > untill you can give well thought-out, meaningfull suggestion= s. I know
that's what
> > > I intend to do.
> >
> > I did in 1982, on a PDP-8E. A nice 12 bit CPU with 8K of core mem= ory.
> > Mind you paper tape was slow on the TTY. In the mean time I will = go back
to
> > lurking  as well and CPU design (see link).
> >
> > >
> > > /me burries himself just like a nice little lurker should. > > And stays hidden until ground hog day. :)
> > Ben.
> > --
> > "We do not inherit our time on this planet from our parents.= ..
> >  We borrow it from our children."
> > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk > nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 5
>    Date: Sun, 21 Jan 2001 15:48:51 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Shared memory
>
> A little draft about shared memory and the extended MMU (read TLB,
> Whygee ;p),
> http://f-cpu.seul.org/nico/
>
> nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 6
>    Date: Tue, 16 Jan 2001 13:08:04 -0700
>    From: Ben Franchuk <bfranchuk@jetnet.ab.ca> > Subject: Re: Cache use?
>
> Nicolas Boulay wrote:
>
> > Go to your bios of your computer, then turn off your cache L1 and= L2
> > (called internal and external cache). And you will see what happe= n...
>
> Yes I know massive slow down. On this old machine I have 256k of
> external cache and a unknown amount of internal cache on my P-150.
> With dynamic ram 60 ns? (I can never get a true figure from the data > sheets) or static 20 ns? for main memory. A cache has to match the
> clock speed of the cpu. With a external cache @ 5 ns? and a internal > cache @ 1ns (1GHZ machine) I can't see external memory getting faster<= BR> > do transit time between parts. Pipelining the memory helps but this is=
> near the limit of physics here for speed. As clock speeds get faster > it not possible to build bigger caches, so I am asking are there
alternatives
> to large caches?
>
> > No more with smt.
>
> I have read the F-manual again, but it still does not explain
> SMT. Can some explain the details of that here?
>
> The rest of the F-CPU still looks clean and well thought out
> and I can understand it all.
> The only change I can think of  make is adding a few more instruc= tions
> to the increment unit. Incriment/decriment by word size might
> be useful. Also this would permit the control unit to decode
> addi,subi #1,#word size as special cases and send it to the faster
> increment unit.
>
> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 7
>    Date: Sun, 21 Jan 2001 11:50:44 -0500
>    From: Lee Salzman <lee.salzman@lvdi.net>
> Subject: Re: Shared memory
>
> Nicolas Boulay wrote:
> >A little draft about shared memory and the extended
> >MMU (read TLB, Whygee ;p),
> >http://f-cpu.seul.org/nico= /
>
> >Java optimising consideration
> > ... snip ...
>
>    The notion of optimizing a processor for Java
> is VERY dubious. Many languages more dynamic than
> Java have existed for much longer and have been
> optimized quite well and without complaint for
> ages. I refer you to Self (research.sun.com/self/,
> from which Sun derived lots of Java optimization
> technology) and CMUCL for examples of optimized
> yet-more-dynamic-than-java languages on
> ordinary hardware. :) IMO, the best way to
> optimize a processor for a language is either
> put the whole language in hardware (if you're
> insane) or to try to assume as little policy
> about what code is being run on the processor
> as possible (to make it flexible for language
> implementers).
>
> >Garbage Collection
> >Most of the time, the yougest object became often garbage.
> >So an optimised system try to show this type of object
> >first. Most of the time the garbage collection is made
> >by using a "write barriers". The goal is to show the
> >write of pointer inside "old" object which can made a > >recent object garbage. Usual MMU can't see that they
> >write a pointer, so each write must be follow by some
> >code to do some garbage collection check. So it could
> >be better to use a specific store instruction, to trap
> >only when it's a write of a pointer.
>
>    This idea is very misleading, although it might
> sound lucid to the unitiated. As a concrete advantage
> you could cite a reduction in code size due to not
> needing several extra instructions to perform write
> barrier checks in hardware.
>    However, after this it all gets messy. Firstly,
> you need to consider how expensive that single trap
> is compared to inlined write barrier code. Traps to
> executive code (and if this requires a trip through
> the operating system to get to it, you can add on
> a hundred or couple hundred cycles) are definitely
> more expensive than even a few jmpa instructions.
> Now, this may be very feasable if stores were
> extremely frequent and the garbage collector had
> direct control of the processor, however, these
> situations are most unlike what you will find in
> even most Java implementations.
>    Elaborating, the F-CPU has a prodigious amount
> of registers meaning that, ideally, memory accesses
> will be very infrequent (so code size advantages are
> greatly nullified). Further, you can just as well
> emulate this functionality by preceding or succeeding
> every store instruction with a syscall instruction
> (for reasons cited above, however, this is not
> even desirable). Another trick is using memory
> instructions that trap if done on unaligned addresses
> (even x86 hardware can do this!). If I were to truly
> implement a write barrier that trapped every store
> on the F-CPU, I would have the address of GC
> write-barrier code pre-loaded in a dedicated register
> and simply issue a jmpa (with return address safely
> stashed in another register) to the GC code, examine
> the instruction to find out where the write was
> happening and with what (or include this information
> encoded after the jmpa and notch the return address,
> however, this is unnecessary because of simple F-CPU
> instruction encoding). This is not only compact but
> much more efficient than any trap.
>     However, I said if I were to implement a write=
> barrier that trapped every store instruction. :)
> For a generational garbage collector, and maybe even
> an incremental one, it is very sufficient to just
> use the vanilla features on any MMU. Simply write
> protect the page which holds the heap area you
> with to protect. When a store is done on this
> page, the page in which the write was done is
> recorded and the page added to a list of dirty
> pages managed by the garbage collector. Following
> this, the page's write-protection is *removed*.
> All succeeding writes are now practically free
> and you just need to re-examine the recorded page
> later and re-write-protect it when the need arises.
>
> My $0.02 USD on Java and GC,
> Lee Salzman
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 8
>    Date: Sun, 21 Jan 2001 18:35:37 +0100
>    From: "Marco Al" <marco@simplex.nl><= BR> > Subject: Re: Cache use?
>
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
>
>
> > so I am asking are there alternatives to large caches?
>
> In a way... not something relevant to us though.
>
> You can use massive main memory bandwith and massive multithreading (m= any
ten's
> of threads, vertical multithreading suffices though) to get rid of cac= hes.
>
> > I have read the F-manual again, but it still does not explain
> > SMT. Can some explain the details of that here?
>
> Simultaneous multithreading. For a nice mix between populist and techn= ical
> reporting see http://www.rea= lworldtech.com/ they had a 3 part story on SMT
in
> future Alpha's.
>
> Marco
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 9
>    Date: Sun, 21 Jan 2001 19:02:49 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Cache use?
>
> reHello,
>
> Ben Franchuk a =E9crit :
> >
> > Nicolas Boulay wrote:
> >
> > > Go to your bios of your computer, then turn off your cache L= 1 and L2
> > > (called internal and external cache). And you will see what = happen...
> >
> > Yes I know massive slow down. On this old machine I have 256k of<= BR> > > external cache and a unknown amount of internal cache on my P-150= .
> > With dynamic ram 60 ns? (I can never get a true figure from the d= ata
> > sheets) or static 20 ns? for main memory. A cache has to match th= e
> > clock speed of the cpu. With a external cache @ 5 ns? and a inter= nal
> > cache @ 1ns (1GHZ machine) I can't see external memory getting fa= ster
> > do transit time between parts. Pipelining the memory helps but th= is is
> > near the limit of physics here for speed. As clock speeds get fas= ter
> > it not possible to build bigger caches, so I am asking are there<= BR> alternatives
> > to large caches?
> >
> You can try to reduice the size of the code at the maximum, to save > space. I try to propose to make something which look like the opposite=
> of CISC. In CISC, you have a 32 bit decoders and some instruction abou= t
> 20 byte. Here, i propose to have a larger decoder compare to the size = of
> usual instruction. Imagine having a 64 bit decoders with 64, 32 and 16=
> bit instruction. The goal is to avoid to have unused bit inside
> instruction, it's waste of space. It's used by TI to reduice code
> footprint for this DSP (32 bit decoder with 8 to 48 bit instruction).<= BR> > ARM use a different technique. There have 32 instructions RISC
> processors, and make a compact subset of 16 bit instructions. They hav= e
> also an instruction to change the type of the instruction used. They > lose a little performance but have a gain of somethink like 30-40% in<= BR> > code size.
>
> > > No more with smt.
> >
> > I have read the F-manual again, but it still does not explain
> > SMT. Can some explain the details of that here?
> >
>
> In fact, it's very simple. Imagine each time you execute one
> instruction, you change the thread where the instruction come from. So=
> you just have to add enought register bank and you cut the latency of<= BR> > the pipeline. You can hide cache miss latency also, but only a few. >
> > The rest of the F-CPU still looks clean and well thought out
> > and I can understand it all.
> > The only change I can think of  make is adding a few more in= structions
> > to the increment unit. Incriment/decriment by word size might
> > be useful. Also this would permit the control unit to decode
> > addi,subi #1,#word size as special cases and send it to the faste= r
> > increment unit.
> >
> > Ben.
> > --
> > "We do not inherit our time on this planet from our parents.= ..
> >  We borrow it from our children."
> > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk > nicO
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 10
>    Date: Sun, 21 Jan 2001 19:26:30 +0100
>    From: Nicolas Boulay <nicolas.boulay@ifrance.com&= gt;
> Subject: Re: Re: Shared memory
>
> Hello, nice to read something like that !
>
> What i have understand, is to avoid to make write barrer to each write=
> but only for pointer. So how to reduice the overhead ? Don't you think=
> that a special store instruction could be nice ? to limit the overhead= .
> Inline is good but is it good for all write ? Couldn't save anything ?=
>
> nicO
>
> Lee Salzman a =E9crit :
> >
> > Nicolas Boulay wrote:
> > >A little draft about shared memory and the extended
> > >MMU (read TLB, Whygee ;p),
> > >http://f-cpu.seul.org= /nico/
> >
> > >Java optimising consideration
> > > ... snip ...
> >
> >    The notion of optimizing a processor for Java > > is VERY dubious. Many languages more dynamic than
> > Java have existed for much longer and have been
> > optimized quite well and without complaint for
> > ages. I refer you to Self (research.sun.com/self/,
> > from which Sun derived lots of Java optimization
> > technology) and CMUCL for examples of optimized
> > yet-more-dynamic-than-java languages on
> > ordinary hardware. :) IMO, the best way to
> > optimize a processor for a language is either
> > put the whole language in hardware (if you're
> > insane) or to try to assume as little policy
> > about what code is being run on the processor
> > as possible (to make it flexible for language
> > implementers).
> >
> > >Garbage Collection
> > >Most of the time, the yougest object became often garbage. > > >So an optimised system try to show this type of object
> > >first. Most of the time the garbage collection is made
> > >by using a "write barriers". The goal is to show th= e
> > >write of pointer inside "old" object which can made= a
> > >recent object garbage. Usual MMU can't see that they
> > >write a pointer, so each write must be follow by some
> > >code to do some garbage collection check. So it could
> > >be better to use a specific store instruction, to trap
> > >only when it's a write of a pointer.
> >
> >    This idea is very misleading, although it might=
> > sound lucid to the unitiated. As a concrete advantage
> > you could cite a reduction in code size due to not
> > needing several extra instructions to perform write
> > barrier checks in hardware.
> >    However, after this it all gets messy. Firstly,=
> > you need to consider how expensive that single trap
> > is compared to inlined write barrier code. Traps to
> > executive code (and if this requires a trip through
> > the operating system to get to it, you can add on
> > a hundred or couple hundred cycles) are definitely
> > more expensive than even a few jmpa instructions.
> > Now, this may be very feasable if stores were
> > extremely frequent and the garbage collector had
> > direct control of the processor, however, these
> > situations are most unlike what you will find in
> > even most Java implementations.
> >    Elaborating, the F-CPU has a prodigious amount<= BR> > > of registers meaning that, ideally, memory accesses
> > will be very infrequent (so code size advantages are
> > greatly nullified). Further, you can just as well
> > emulate this functionality by preceding or succeeding
> > every store instruction with a syscall instruction
> > (for reasons cited above, however, this is not
> > even desirable). Another trick is using memory
> > instructions that trap if done on unaligned addresses
> > (even x86 hardware can do this!). If I were to truly
> > implement a write barrier that trapped every store
> > on the F-CPU, I would have the address of GC
> > write-barrier code pre-loaded in a dedicated register
> > and simply issue a jmpa (with return address safely
> > stashed in another register) to the GC code, examine
> > the instruction to find out where the write was
> > happening and with what (or include this information
> > encoded after the jmpa and notch the return address,
> > however, this is unnecessary because of simple F-CPU
> > instruction encoding). This is not only compact but
> > much more efficient than any trap.
> >     However, I said if I were to implement a = write
> > barrier that trapped every store instruction. :)
> > For a generational garbage collector, and maybe even
> > an incremental one, it is very sufficient to just
> > use the vanilla features on any MMU. Simply write
> > protect the page which holds the heap area you
> > with to protect. When a store is done on this
> > page, the page in which the write was done is
> > recorded and the page added to a list of dirty
> > pages managed by the garbage collector. Following
> > this, the page's write-protection is *removed*.
> > All succeeding writes are now practically free
> > and you just need to re-examine the recorded page
> > later and re-write-protect it when the need arises.
> >
> >           =             &nb= sp; My $0.02 USD on Java and GC,
> >           =             &nb= sp; Lee Salzman
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 11
>    Date: Sun, 21 Jan 2001 23:34:50 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: 2-Stage Shifter Proof Of Concept
>
> Hi F-gang ;)
>
> I send you a copy of my shifter test unit; it's only behavioral VHDL > and some things are still missing.  So far it can do shiftl, shif= tr,
> rotl, rotr, byterev and sdup (all fully verified, testbench included).=
> Bitrev and shiftra aren't fully implemented but are IMHO also possible= .
>
> There are also two pictures that show the contents of the input and ou= tput
> matrices for several operating modes, SIMD chunk sizes and shift count= s.
> There's no documentation except the basic outline I desscribed on this=
> list some days ago; if in doubt, feel free to ask...
>
> Have fun,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> [This message contained attachments]
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 12
>    Date: Sun, 21 Jan 2001 14:39:43 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: shifter (was Re: conferences)
>
> On Sun, Jan 21, 2001 at 03:38:29AM +0100, Yann Guidon wrote:
> [...]
> > > Yep.  While we're at it: I re-read the manual and saw t= hat the `bitop'
> > > instructions (bchg, bset, bclr, btst) are supposed to be han= dled by
the
> > > bit shuffling unit, too.  I think that they're better d= one in the ROP2
unit
> > > (with a 6-to-64 decoder in front of it) because they're not = bit
shuffling
> > > operations at all (only a single bit is changed).  Ther= e should be
enough
> > > room for the decoder if we drop `combine' mode (or move it t= o a second
> > > stage, which is needed for a full-width combine anyway).
> >
> > that's an interesting problem but if we extend the shifter to 2 s= tages,
> > there's certainly enough room. The ROP2 unit's "chunks"= are slightly
larger
> > and do more diverse things. I don't think that there's a benefit = if we
"chain"
> > the SHL to the ROP2 unit. ROP2 is more "exhaustive" and= flexible, while
the
> > added optional logic in SHL is like a "goodie" (if we h= ave some
transistors left).
>
> It's not a room (or delay) problem, IMHO.  The ROP2 unit is the m= ore
> logical (sic!) place to do the bit operations.  The SHL can also = do it,
> but it will require lots of additional control logic (which is already=
> fairly complex).
>
> [...]
> > The linux port should still be going on, but Simili version 1.5 i= s
online !
> > i've d/l it, i have to install it. it is meant to be much faster = for
large
> > designs, the memory allocation code is rewritten. maybe you'll be= able
to
> > simulate the multiplier faster ? :-)
>
> I grabbed a copy of 15b9, too.  Didn't install it yet, though. >
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 13
>    Date: Mon, 22 Jan 2001 01:33:39 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Cache use?
>
> hi !
>
> Ben Franchuk wrote:
> > Yann Guidon wrote:
> > > > > > I think you are looking at the wrong place fo= r the properties
> > > > > > you seek, look at low-power processing (mobil= e) or massively
parallel processing
> > > > > > (DSP/media-processing).
> > > > > But alas the F-CPU has too do all 3 markets and mo= re.
> > > ??? was it a joke ? or you really meant it ?
> > > Nobody said that the F-CPU was AIMED at mobile applications.=
> > I meant in this case that the F-CPU still is a General processor.=
> > I don't expect a F-CPU in my phone but a F-CPU Could be used in a=
> > Laptop or a Rack of 16 servers. For now the core is High end PC's=
> > but with a  open design that could change overnight.
> ok : now it's clear.
>
> > > There are already enough cores for this branch.
> > > The primary idea was to propose an architecture that could c= ompete
> > > with IA64 for the high-end and personal computers. the FC0 i= s a
> > > first step that we have to reach, so we chose to leave it ra= ther
> > > simple and compact. It's something that should be implemente= d
> > > with much less pain than any IA64 CPU. Then we'll decode mor= e
> > > instructions.
> > This has me confused. What is the critical data path
> > for the f-Cpu? Off hand I don't think it is in instruction fetchi= ng
> > or decoding.
> indeed, it is. Even though we can pipeline almost everything,
> from the adder to the multiplier, the control logic for the decoder > is less easy to pipeline. i am not sure that the FC0 decoder will
> fit in the aimed 6 gates of latency. this stage does a LOT of things > at the same time. Maybe it will fit in 10 or 8 gates, but 6 gates will=
> be tough.
> And that's only 1 instruction. For more instructions, "it's a who= le new
problem".
> I think that the team has started to succeed to reach good results for= the
> "execution" side of the CPU. the control/decoding/scheduling= is less
straight-forward
> because it contains a lot of different problems.
> So i think that decoding IS the major problem when we want to execute = more
> instructions per cycle.
>
> > > > If you compromise on everything you end up with
> > > > something which excels at nothing.
> > > at least now we excel at ... discussing ?
> > > i gotta update the french translation of the manual...
> > Well I better read the English Version.
> of course :-) So do the french people (they want to read the french version).
>
> > > > Marco
> > > WHYGEE
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Ben.
> > PS.All the game I can afford are $5 DOS games at the garage sales= .
> :-D
> ain't the F-CPU a great strategy/RPG game ? :-P
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 14
>    Date: Mon, 22 Jan 2001 01:33:38 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: scalar processor
>
> hi !
>
> Nicolas Boulay wrote:
> > Hello,
> > Yann Guidon a =E9crit :
> > > Nicolas Boulay wrote:
> > > > Since the beginning, i try find a way to speed up the f= cpu without
the
> > > > need of OOO and register renaming.
> > > better SMT than OOO... FC0 is already OOOC and it's a good e= nough
compromise.
> > OOOC isn't the same usfullness as OOO.
> it depends. OOOC requires good binaries, while OOO is meant to compens= ate
for
> "old" binaries. We have no old binaries, so we can make good= code from the
start.
>
> But if you look closely, OOOC is simply a "reversed" OOO. > OOO is like a normal CPU, or OOOC, with the "completion" uni= t at the end
> of the pipeline, instead of at the decoder stage. OOO adds renamed
registers.
> Otherwise, it's roughly similar.
>
> > > > 64 registers are good but if you have
> > > > a depencies of 8 instructions (with big pipelining) you= could
execute 8
> > > > instruction at the same times. that's good.
> > > wrong. You forget that an instruction has (in average) 2 sou= rces
> > > and 1 destination. so we can do 64/3=3D21 instructions witho= ut stalling.
> > > that's 2*2*5 or 3*7 and optimistic because in reality, it's = never that
easy.
> > Sorry, i was much more too optimistik ;p
> maybe you should write more asm code ;-P
>
> > > > To had more register as for
> > > > Sparc, windowed register with 2 more ASM instructions t= o slide the
> > > > windows could increase the number of usable register. B= ut i think
you
> > > > could only save some access to the main memory.
> > > explicit renaming is interesting but it creates enough troub= les
> > > everywhere that we must be very careful. It adds more inform= ations
> > > to store, to backup (how ?) and keep coherent.
> > If you know when you slide the window, you could save your regist= er
> > (it's only slower)
> in fact, my problem with explicit renaming (window shifting) is the > "fragmentation". let me explain it.
>
> register windows, in our case, is meant to increase the number of logi= cal
> and usable registers. But in real cases, we access register in a
almost-random
> fashion. this means that in the worst case, we would have to "sli= de" the
window
> three times per instruction (with 3-op instructions) because the opera= nds
are all
> out of reach. reducing this is a big pain for the compiler.
>
> > > > The first thing to do to execute more than 1 inst per c= lock cycle is
to
> > > > try to use during the same times differents units. But = you have to
> > > > reconise which instruction could be use in the same tim= es.
> > >
> > > i've thought about a trick to detect if 2 instructions (or a= ny number)
> > > could be issued at the same time. If we estimate that the un= it is
coded
> > > in the opcode and only in the upper part, a 6-bit substract = could done
> > > between 2 consecutive instructions. If the result is above a= certain
limit,
> > > there's no chance of unit hazard. This can be applied in par= allel
> > > with a reasonable amount of different instructions.
> >
> > No really, 2 concecutives instruction could see as in the same bl= oc with
> > your scheme. And read a bit is much more easy. (imagine to do 6 > > substracts for 6 decoders, it's make a very long path)
>
> you forget a little detail...
> 1) the substracts are in parallel
> 2) we don't make a DSP, but a platform that will run with several kind= s
> of cores. pairing rules that apply to a core will give bad performance=
> on other cores. look at the transition from the Pentium to the PII, > and from PII/PIII to P4.
>
> This means that we have to find a "generic" way to do this.<= BR> >
> Fortunately, we have enough time to search a good method, because we > better build a 1-inst/cycle version before designing a larger version<= BR> > that would never exist and force us to use a specific and possibly wro= ng
> method.
>
> > > > So i propose to add a depencies bit inside the instruct= ion.
> > > too late.
> > Hum, i don't think so, the insctruction as been defined with the = binary
> > code, but without knowing what all is need.
> I have first tried to promote a 7-bit opcode.
> After the instruction census started, it appeared that it would not be=
enough.
>
> > A good number of instruction have been chosen, but why not change= how to
> > code all of this ? Nothing is written about it (in vhdl).
> how/what do you want to change ?
>
> > > > All consecutive instruction with the bit equal could be= used in
parallel.
> > > > You will have packet with 1, then a packet with 0.
> > > are you just copying the c6x or what ? :-P
> > YES ! But it seems so easy to use it for variable lenght supersca= lar
> > processor !
> too easy. so easy that it will trap you later.
>
> The case is easy for the C6x : TI controls everything and the target market
> is very limited. The CPU is meant to run "trusted code" that= is meant to
be perfect.
> In the F-CPU world, the chip will certainly be used in a multi-user station
> that can run "untrusted" code and even viruses. We don't con= trol the
evolution
> of the core (anybody can modify it) and TI's "trick" will re= ach its limits
quickly.
> For example : imagine that we implement that in the FC1. Everything wi= ll
be fine.
> Now somebody makes FC2 with a different decoder/execution pipeline. Th= e
bits
> that you have put in the instruction will not be useful at all, so you=
waste 1/32
> of the memory bandwidth. Now, somebody generates badly packed instruct= ions
> (the packet bit is wrong). Will the CPU burn ?
> Intel knew these problems and have not implemented a "pure" = VLIW for the
IA64.
> scalability and security are very important problems and it's priority= #1
in the
> project.
>
> > > > If the fcpu have many decoder, he could launch every pa= cket in the
same
> > > > time if he had enought unit. So a coding rules will be = to interleave
the
> > > > use of the different unit. And after that you could add= one more
adder
> > > > and speed up the code a little bit.
> > > >
> > > > I think it's easy what do you think of it ?
> > > it's incomplete. the register hazards are another problem. > > No, it's totally fixe by the dependance bit. You just have to che= ck the
> > code of the instruction. Scoreboard are used in the same manner a= s
> > befor.
> outside of the opcode, every additional information is considered as > "hint" (indice) that is meant to enhance the performance of = the code.
> The problem here is that your bit is not general enough. You can use > this for superscalar cores, ok, but it's useless for OOO cores or
> single-issue cores (like the FC0).
> Maybe you can pack all your bits inside one instruction,
> inside a 16-bit field. This instruction is interpreted as NOP on
> the architectures that don't use it. Otherwise, it can contain
> almost any hint about a packet of instructions. You can prefix a
> packet of 7 or 15 instructions with one "hint" instruction t= hat
> will inform (early !) the decoder of the dependencies inside the packe= t.
> THAT is a possible solution and compromise.
>
> > > I propose several alternatives that can be used in conjuncti= on.
> > > - The "VLIW" approach has been studied... a lot an= d since a long time.
> > > the raw VLIW and the superscalar approaches can't be used ve= rbatim,
> > > something more synthetic and flexible must be used.
> > That's not what i propose ?
> no. It's "too simple" and you hit the wall when you exceed t= he target
goal.
> more specifically : it's not flexibe enough.
>
> > > A good way to help is with the help of a "hint instruct= ion",
> > > something that is decoded as NOP when it is not supported, > > > but otherwise explicits the data and unit hazards for the > > > next N instructions. The format is not yet determined, it mu= st
> > > fit in 24 bits, that's all.
> > no, you can't do that without having an explosion of the code siz= e.
> i explained in the above paragraph how you avoid this code explosion.<= BR> > And when you're not inside a critical section, you can remove this
> hinting instruction. OTOH when you're sure that the code runs 99% in t= he
cache,
> you can use (in average) 1 hint instruction ("PACK") every 8= instructions
> (the first 32 bits of a 256-bit wide cache line).
>
> THAT is what i call flexible ;-P
>
> > > - The "dynamic" approach. it is similar to the Pen= tium or P4 approach
:
> > > the instructions are decoded when they enter the Instruction= cache,
> > > the register and unit hazards are decoded, so there's a perf= ormance
hit
> > > only at the first execution. The Pentium did that for decodi= ng the
> > > packet (instruction pairs) : the data from the cache is exec= uted once,
> > > the instructions boundaries are written to the instruction c= ache,
> > > so for the next executions, the decoder already knows if it = can
execute
> > > 1 or 2 instructions.
> >
> > It's the story of the trace cache, read
> > http://www.emul= ators.com/pentium4.htm and you will hate the trace cache
> > : it's a gain of decoding but your 96 Kbyte of cache is like a 8K= o of L&
> > cache compare to the 128 Ko of the athlon.
>
> i spoke about the old good P53C (the "Pentium" that sits on = my desk), not
> about the newer "P4" (expensive and deceiving).
>
> "trace cache" would be in a RISC->TTA core, but since it'= s a RISC ISA
> as input, there is much less bloat ;-)
>
> > > Since it is regenerated everytime, it's "dynamic" = and is independent
> > > from the rest.
> > But too small !
> hey ! we don't have to decode x86 instructions !
> one RISC instruction (32-bits) can generate in average 3 TTA instructi= ons
> (4 or 5 for L/S) and these instructions are commonly 16-bits
> (it can be changed easily because it's internal and hidden to the user= ).
> i expect around 30% bloat but much more parallelism !
>
> > > - Better : a F-CPU/RISC->TTA translator. it's implicitely= OOO but
> > > it might be very interesting. the instructions are recoded a= s TTA
> > > instructions and stored in a big buffer acting as the instru= ction
cache,
> > > it's similar to the P4 architecture but less heavy :-)
> > Bof, too far from our risc architecture, and maybe hard to make i= t
> > parallel.
> far from it. You're too young on the list ;-P when AlphaRisc was there= ,
> he would have flamed you for that remark ;-D TTA has certain advantage= s
> and a RISC->TTA core would be a good solution to bypass the patents= on
> the OOO cores.
>
> > > - SMT. did you forget that ? :-)
> > In smt, you don't increase the number of instruction issued by cl= ock
cycle !
> au contraire. You enhance the use of the decoder and the execution uni= ts.
> OTOH you completely overflow the memory bandwidth ... but it'd another=
discussion.
>
> An illustration of what i said is with "lazy SMT". it's for = example a
> core with 4 instructions issued at every cycle, from 4 different threa= ds
> (a bit like 4xFC0 in parallel). The dependency checks are only local.<= BR> > When there is a "bubble", you can check the neighbours to ss= e if they can
execute
> another instruction that would fill the empty slot.
> So then YES SMT /can/ increase and ease this increase in IPC.
>
> read you all tomorrow,
>
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 15
>    Date: Mon, 22 Jan 2001 01:33:37 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: sizes (was : Re: conferences)
>
> Nicolas Boulay wrote:
> > You write a 64 bit unit, but in the near futur 128 bit could be u= sed. So
> > if each unit could be double the size of this input and ouput. Wh= en you
> > synthetise your chip, you will choose the size of the register. T= hat's
> > all. When i use the leon, i choose the size of the window registe= r (2 to
> > 32 windows) and the size of the cache. Here, i want to possibly c= hange
> > the size of the register.
>
> mmmh ok now i get it.
>
> The size of the registers is determined by the constant MAXSIZE.
>
> Here is a copy/paste of the beginning of f-cpu_config.vhdl
>
> package FCPU_config is
>
> ------------------------------------------------------
> -- Most important F-CPU constants :
> ------------------------------------------------------
>
> -- Number >=3D2, 3 corresponds to 64-bit registers
>   constant LOGMAXSIZE : natural :=3D 3;
>
> -- Size of the registers in bytes
>   constant MAXSIZE : natural :=3D 2**LOGMAXSIZE;
>
> -- Size of the registers in bits.
>   constant UMAX : natural :=3D MAXSIZE * 8;
>
> -- Range of a register width declaration.
>   subtype F_RANGE is natural range UMAX-1 downto 0 ;
>
> -- shortcut for a very common declaration.
>   subtype F_VECTOR is std_ulogic_vector(F_RANGE) ;
>
> -- MAX_CHUNK_SIZE in bits
>   constant MAX_CHUNK_SIZE : natural :=3D 64 ;
>
>
> Note that MAX_CHUNK_SIZE determines the size of the SIMD chunks.
> it is not fixed to 64-bits : SIMD "subdomains" can be 32-bit= s
> only, as well as 128-bits...
>
>
> > Yann Guidon a =E9crit :
> > >
> > > hello,
> > >
> > > Nicolas Boulay wrote:
> > > >
> > > > Don't forget to put a constant on the unit that could d= ouble
(*4,*8,...)
> > > > the size of the output. For 64, 128, 256 bit large regi= ster,... For
some
> > > > application such big registers could be more interresti= ng than a
FPU.
> > >
> > > i don't understand what you write ... example ?
> > >
> > > > If the algorithme need a longer longest path. Maybe we = can add some
> > > > pipeline stage.
> > >
> > > ?
> > >
> > I don't know how you will make your design but by doubling the si= ze of
> > the register could increase the longuest path. So it will be bett= er to
> > create a new pipeline stage.
>
> we'll have probably the occasion to put this advice in practice ;-) >
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 16
>    Date: Mon, 22 Jan 2001 02:13:40 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: shifter (was Re: conferences)
>
> hi !
>
> Michael Riepe wrote:
> > On Sun, Jan 21, 2001 at 03:38:29AM +0100, Yann Guidon wrote:
> > [...]
> > > that's an interesting problem but if we extend the shifter t= o 2
stages,
> > > there's certainly enough room. The ROP2 unit's "chunks&= quot; are slightly
larger
> > > and do more diverse things. I don't think that there's a ben= efit if we
"chain"
> > > the SHL to the ROP2 unit. ROP2 is more "exhaustive"= ; and flexible,
while the
> > > added optional logic in SHL is like a "goodie" (if= we have some
transistors left).
> > It's not a room (or delay) problem, IMHO.  The ROP2 unit is = the more
> > logical (sic!) place to do the bit operations.  The SHL can = also do it,
> > but it will require lots of additional control logic (which is al= ready
> > fairly complex).
> mmmm...
>
> my todo list has exploded.
>
> "merging" the ROP2 and the SHL is a major pain because
> only the Xbar is meant to transmit data (it keeps the scheduler simple= ).
>
> Now, if you code
>
>   bitop r1,r2,r3 (assuming SHL is 1 cycle)
>   and   r4,r5,r6 (unit hazard here !)
>
> How will the decoder detect the hazard ?
> Ok; the solution is rather simple /here/ (just a few flip-flops and > simple gates) but if this becomes a habit, the decoder might become > soon as complex as a PowerPC or x86 decoder.
>
> bitop etc. are fairly optional features, they are supported if enough<= BR> > ressources are available, ie if the critical datapath is not bloated.<= BR> > Otherwise, if we want to support ALL the optional features,
> the chip will never see the light of the day :-)
>
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 17
>    Date: Mon, 22 Jan 2001 02:13:42 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Cache use?
>
> hi,
>
> Ben Franchuk wrote:
> > Nicolas Boulay wrote:
> <snip>
> > Pipelining the memory helps but this is
> > near the limit of physics here for speed. As clock speeds get fas= ter
> > it not possible to build bigger caches, so I am asking are there<= BR> alternatives
> > to large caches?
> yes : multiple banks.
> look at a CDC6600 ;-P it ran at 35MHz with core memory...
> the trick is that there were 8 individual/parallel/interleaved memory<= BR> banks.
> the bank was determined with the 3 LSB of the pointer so you ran
> full-speed with linear access ("vector loop") code.
>
> Something similar can be found in the F-CPU : there are 3 "stream= hint
bits"
> that can say where a datum is located for a Load/store instruction. >
> The historical problem is the bandwidth and the number of pins.
> we can't put 100K pins on the die... yet...
>
> > > No more with smt.
> > I have read the F-manual again, but it still does not explain
> > SMT. Can some explain the details of that here?
> Nicolas has sent a PDF about that last week.
> SMT means "simultaneous multi-threading" and it multiplexes<= BR> > instructions from different threads as to fill the bubbles
> in a pipeline.
>
> > The rest of the F-CPU still looks clean and well thought out
> > and I can understand it all.
> pfiuh ! all that work was finally worth :-)))
>
> > The only change I can think of  make is adding a few more in= structions
> > to the increment unit. Incriment/decriment by word size might
> > be useful. Also this would permit the control unit to decode
> > addi,subi #1,#word size as special cases and send it to the faste= r
> > increment unit.
>
> probably.
> The Xbar necessarily has provision for sending a constant
> to a unit. now the problem is to include this feature in the INC unit'= s
structure
> (INC has already reached the latency limit of the pipe stage...).
>
> > Ben.
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 18
>    Date: Mon, 22 Jan 2001 02:13:39 +0100
>    From: Yann Guidon <whygee@f-cpu.org>
> Subject: Re: Cache use?
>
> Nicolas Boulay wrote:
> > reHello,
> idem again,
>
> > Ben Franchuk a =E9crit :
> > > Nicolas Boulay wrote:
> > > > Go to your bios of your computer, then turn off your ca= che L1 and L2
> > > > (called internal and external cache). And you will see = what
happen...
> > > Yes I know massive slow down.
> <snip>
> > > Pipelining the memory helps but this is
> > > near the limit of physics here for speed. As clock speeds ge= t faster
> > > it not possible to build bigger caches, so I am asking are t= here
alternatives
> > > to large caches?
> > You can try to reduice the size of the code at the maximum, to sa= ve
> > space.
> that's only one side of the problem. What about the data ????
>
> > I try to propose to make something which look like the opposite > > of CISC. In CISC, you have a 32 bit decoders and some instruction= about
> > 20 byte. Here, i propose to have a larger decoder compare to the = size of
> > usual instruction. Imagine having a 64 bit decoders with 64, 32 a= nd 16
> > bit instruction. The goal is to avoid to have unused bit inside > > instruction, it's waste of space. It's used by TI to reduice code=
> > footprint for this DSP (32 bit decoder with 8 to 48 bit instructi= on).
> > ARM use a different technique. There have 32 instructions RISC > > processors, and make a compact subset of 16 bit instructions. The= y have
> > also an instruction to change the type of the instruction used. T= hey
> > lose a little performance but have a gain of somethink like 30-40= % in
> > code size.
> unless you're running in a smartcard, it's useless.
> you better try to :
> - remove all the "dead code"
> - use the best optimisation flags with a good compiler (you win your 3= 0%)
> - pack your data with the right alignment and avoid all the
>   useless temporary representations or tables
> - reuse as much data and code as possible
> etc...
> the list is endless, look at a good book.
>
> Coding in HLL often hides the real loss in space.
> C is particularly wasteful. C++ is even worse.
> coding in asm might give you good results (if you care
> to analyse properly your application).
>
> there's no magic, no secret.
>
> > > Ben.
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 19
>    Date: Tue, 16 Jan 2001 17:10:59 -0700
>    From: Ben Franchuk <bfranchuk@jetnet.ab.ca> > Subject: Re: Cache use?
>
> Yann Guidon wrote:
> >
> > hi !
> > indeed, it is. Even though we can pipeline almost everything,
> > from the adder to the multiplier, the control logic for the decod= er
> > is less easy to pipeline. i am not sure that the FC0 decoder will=
> > fit in the aimed 6 gates of latency. this stage does a LOT of thi= ngs
> > at the same time. Maybe it will fit in 10 or 8 gates, but 6 gates= will
> > be tough.
>
> Yes you are right,as register decoding is done here too.
> You got 3 gates to decode the registers and 3 gates to select register= set
from
> the
> instruction register. Close indeed as any gates over 4 inputs may map<= BR> poorly
> to the hardware technology.
>
> > And that's only 1 instruction. For more instructions, "it's = a whole new
problem".
> > I think that the team has started to succeed to reach good result= s for
the
> > "execution" side of the CPU. the control/decoding/sched= uling is less
straight-forward
> > because it contains a lot of different problems.
> > So i think that decoding IS the major problem when we want to exe= cute
more
> > instructions per cycle.
>
> Also as I still not have figured how SIMD instructions work with the F= -CPU
> so I can't see decoding impact here.
>
> > ain't the F-CPU a great strategy/RPG game ? :-P
> Right now I am playing a NICE adult game from Japan (translated into english).
> Shapely females look better than a blob of plastic with a [F@] on it. = :)
>
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ben.
> PS. You would think that since France is the LAND of romance you would=
have
> some nice adult games from there.
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 20
>    Date: Mon, 22 Jan 2001 02:25:25 +0100
>    From: Michael Riepe <michael@stud.uni-hannover.de= >
> Subject: Re: shifter (was Re: conferences)
>
> On Mon, Jan 22, 2001 at 02:13:40AM +0100, Yann Guidon wrote:
> [...]
> > "merging" the ROP2 and the SHL is a major pain because<= BR> > > only the Xbar is meant to transmit data (it keeps the scheduler s= imple).
> [...]
>
> I do not suggest to merge them.  I just think we should move the<= BR> > bitop instruction from the SHL unit to the ROP2 unit, where it belongs= .
> After all, bitop is a logical operation, not a shift operation -- and = the
> `1 << n' part can be done faster and cheaper with a 6-to-64 deco= der than
> with the comparatively slow SHL unit.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 21
>    Date: Mon, 22 Jan 2001 10:45:40 +0100
>    From: "Marco Al" <marco@simplex.nl><= BR> > Subject: Re: Cache use?
>
> From: "Yann Guidon" <whygee@f-cpu.org>
>
> > > it not possible to build bigger caches, so I am asking are t= here
> alternatives
> > > to large caches?
> > yes : multiple banks.
>
>
> You will not overcome 100's of cycle of latency, no matter how many registers
> you throw at the problem (in fact registers arent a realistic solution=
even at
> this point in time IMO, if it isnt in the cache you stall).
>
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
>
>
> > Close indeed as any gates over 4 inputs may map poorly
> > to the hardware technology.
>
> Nicolas is right, this is not a very usefull way to look at it. At som= e
point
> you will have to go to semi-custom, use what works best (for instance = most
high
> performance shifters Ive seen described use 4:1 mux's, 6 inputs, and t= he
most
> appropriate adder structures would seem to consist of 4 or even 8 bits=
CLA's
> which I doubt you want to make by synthesis)
>
> This will be a slight problem AFAICS, VHDL and synthesis are close eno= ugh
to
> programming to find some people who can become proficient at it and ha= ve
some
> free tools available... but both the tools and the skills for library<= BR> > development in deep sub micron processes are a little more rare (for instance
> are there any free tools which can do phase shift compensation etc. ?)= and
of
> course for layout we will need commercial tools regardless. And then there's
> timing verification...
>
> Marco
>
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 22
>    Date: Mon, 22 Jan 2001 12:15:02 +0100
>    From: Yann GUIDON <whygee@f-cpu.org>
> Subject: Re: Cache use?
>
> hi !
>
> Ben Franchuk wrote:
> > Yann Guidon wrote:
> > >
> > > hi !
> > > indeed, it is. Even though we can pipeline almost everything= ,
> > > from the adder to the multiplier, the control logic for the = decoder
> > > is less easy to pipeline. i am not sure that the FC0 decoder= will
> > > fit in the aimed 6 gates of latency. this stage does a LOT o= f things
> > > at the same time. Maybe it will fit in 10 or 8 gates, but 6 = gates will
> > > be tough.
> >
> > Yes you are right,as register decoding is done here too.
> > You got 3 gates to decode the registers and 3 gates to select reg= ister
set from
> > the instruction register. Close indeed as any gates over 4 inputs= may
map poorly
> > to the hardware technology.
>
> reading the register is done speculatively on the 3 fields and it take= s 3
or 4 gates,
> it's not the problem. the critical datapath is whether the instruction= is
"issued"
> (valid) : OPCODE is OK, write slot (in the Xbar) Ok, registers (read) = are
OK, unit
> is ready, pointer is valid etc... that will take some gates.
>
> > > And that's only 1 instruction. For more instructions, "= it's a whole
new problem".
> > > I think that the team has started to succeed to reach good r= esults for
the
> > > "execution" side of the CPU. the control/decoding/= scheduling is less
straight-forward
> > > because it contains a lot of different problems.
> > > So i think that decoding IS the major problem when we want t= o execute
more
> > > instructions per cycle.
> >
> > Also as I still not have figured how SIMD instructions work with = the
F-CPU
> > so I can't see decoding impact here.
>
> in fact the impact is ... almost inexistant, at least today.
> All instructions are SIMD by definition. if you have a 8 or 32-bit
operation
> makes no difference at the decoding stage, except for some known cases= (ie
multiply)
> because it changes the latency, but it's "static" (known by = construction).
> So we issue instructions and the units treat the data in SIMD.
> However the difference is when the data is written back to the registe= r
:-)
> only one part or the whole register is written/validated, if it's SIMD= or
not.
> ok, it consumes some power, but it's sooo simple for the
decoder?scoreboard etc... :-)
> and for the execution units, only the SIMD versions are designed. you<= BR> don't have
> to care for different gated clocks etc...
>
> So all we need to care is the write back cycle, the registers are
partially written,
> that's all.
>
> > > ain't the F-CPU a great strategy/RPG game ? :-P
> > Right now I am playing a NICE adult game from Japan (translated i= nto
english).
> > Shapely females look better than a blob of plastic with a [F@] on= it. :)
> >
> > > WHYGEE
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Ben.
> > PS. You would think that since France is the LAND of romance you = would
have
> > some nice adult games from there.
>
> France is the land of cheese, dark chocolate, tourism and silliness. > if you're looking for adult stuff, you will not find them here...
>
> YG
>
> speaking for himself
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 23
>    Date: Mon, 22 Jan 2001 12:22:59 +0100
>    From: Yann GUIDON <whygee@f-cpu.org>
> Subject: Re: shifter (was Re: conferences)
>
> hi,
>
>
> Michael Riepe wrote:
> > Yann Guidon wrote:
> > > "merging" the ROP2 and the SHL is a major pain bec= ause
> > > only the Xbar is meant to transmit data (it keeps the schedu= ler
simple).
> >
> > I do not suggest to merge them.  I just think we should move= the
> > bitop instruction from the SHL unit to the ROP2 unit, where it be= longs.
> > After all, bitop is a logical operation, not a shift operation --= and
the
> > `1 << n' part can be done faster and cheaper with a 6-to-64= decoder than
> > with the comparatively slow SHL unit.
>
> the ROP2 unit is already full.
>
> Plus, there's another problem :
>
> SHL is a shuffler with a tiny logic level,
> ROP2 is a exhaustive logic array with some additional bytewise OR/AND.=
>
> For the bitop, ROP2 would need to move the bytewise operations in fron= t of
> the logic level.
>
> maybe we should drop this instruction temporarily ?
> the opcode and behaviour is reserved, the implementation is
> not too difficult but it doesn't fit in the FC0, it's not a
catastrophe/drama...
> plus, there's no bitop in high-level langages. we will have enough
> time to implement it later...
>
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
>
> YG
>
> speaking for himself
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
> Message: 24
>    Date: Wed, 17 Jan 2001 00:29:18 -0700
>    From: Ben Franchuk <bfranchuk@jetnet.ab.ca> > Subject: Re: Cache use?
>
> Marco Al wrote:
>
> > This will be a slight problem AFAICS, VHDL and synthesis are clos= e
enough to
> > programming to find some people who can become proficient at it a= nd have
some
> > free tools available... but both the tools and the skills for lib= rary
> > development in deep sub micron processes are a little more rare (= for
instance
> > are there any free tools which can do phase shift compensation et= c. ?)
and of
> > course for layout we will need commercial tools regardless. And t= hen
there's
> > timing verification...
> >
> At the very high speeds I guess still 90% of the layout still
> will be by hand. Since I am using FPGA's for my Computer designs
> I have not looked at this site, but some DAM fast chips are designed > here. Read all you can about Chuck Moore and his cad system.
> http://www.ultra= technology.com/people.htm
> If you need to go commercial this guy is a good contact.
> > Marco
> Ben.
> PS. Also a great place to buy a FORTH processor.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
> ______________________________________________________________________= __
> ______________________________________________________________________= __
>
>
>
eGroups Sponsor=
3D"Click
3D""
From Michael Riepe Mon Jan 22 15:04:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02037 for ; Tue, 23 Jan 2001 00:23:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 00:23:21 +0100 (MET) Received: (qmail 32582 invoked by uid 0); 22 Jan 2001 23:14:20 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx02) with SMTP; 22 Jan 2001 23:14:20 -0000 X-eGroups-Return: sentto-1101623-2084-980205216-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 22 Jan 2001 23:13:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 23:13:35 -0000 Received: (qmail 38455 invoked from network); 22 Jan 2001 22:51:38 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 22 Jan 2001 22:51:38 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.40) by mta1 with SMTP; 22 Jan 2001 22:51:31 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00529; Mon, 22 Jan 2001 15:04:15 +0100 Message-ID: <20010122150415.24172@thrai.stud.uni-hannover.de> To: f-cpu@egroups.com References: <3A68CC2C.535BC91F@f-cpu.org> <20010120011236.44776@thrai.stud.uni-hannover.de> <3A6998E8.C494D870@f-cpu.org> <20010120165956.16075@thrai.stud.uni-hannover.de> <3A6A4BA5.7F3104F2@f-cpu.org> <20010121143943.46340@thrai.stud.uni-hannover.de> <3A6B8944.5B91FA55@f-cpu.org> <20010122022525.31883@thrai.stud.uni-hannover.de> <3A6C1813.45C86951@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A6C1813.45C86951@mentor.com>; from Yann GUIDON on Mon, Jan 22, 2001 at 12:22:59PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 15:04:15 +0100 Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2dd0a99031c6e4ebb83ec92a1703fc0 Status: R X-Status: N On Mon, Jan 22, 2001 at 12:22:59PM +0100, Yann GUIDON wrote:
[...]
> the ROP2 unit is already full.

The SHL unit won't be empty either, and it will be rather hard to squeeze
it into a single pipeline stage.  Dropping the tiny logic unit at the
end may help a lot.

> Plus, there's another problem :
>
> SHL is a shuffler with a tiny logic level,
> ROP2 is a exhaustive logic array with some additional bytewise OR/AND.
>
> For the bitop, ROP2 would need to move the bytewise operations in front of
> the logic level.

I don't think so.

> maybe we should drop this instruction temporarily ?
> the opcode and behaviour is reserved, the implementation is
> not too difficult but it doesn't fit in the FC0, it's not a catastrophe/drama...
> plus, there's no bitop in high-level langages. we will have enough
> time to implement it later...

Hmm... a bitop can be replaced with 3 other instructions: loadcons,
shiftl, and/or/xor.  If the shift count is a constant, you can calculate
the shifted constant at compile time (2 instructions).  You lose one
or two registers this way, but it really is no drama, right.

Ok, let's drop it for now.  It's an optional instruction anyway.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Nicolas Boulay Mon Jan 22 23:58:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02040 for ; Tue, 23 Jan 2001 00:23:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 00:23:23 +0100 (MET) Received: (qmail 860 invoked by uid 0); 22 Jan 2001 23:15:17 -0000 Received: from ho.egroups.com (64.211.240.236) by 10.1.4.106 (mx06) with SMTP; 22 Jan 2001 23:15:17 -0000 X-eGroups-Return: sentto-1101623-2085-980205249-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 22 Jan 2001 23:15:16 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 23:14:09 -0000 Received: (qmail 30192 invoked from network); 22 Jan 2001 22:50:01 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Jan 2001 22:50:01 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 22 Jan 2001 22:50:00 -0000 Received: from ifrance.com (nas13-239.vlt.club-internet.fr [195.36.163.239]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA09926 for ; Mon, 22 Jan 2001 23:45:44 +0100 (MET) Message-ID: <3A6CBB1B.EFC2675F@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <3A63E9FC.9FE2CBEA@jetnet.ab.ca> <3A6AF247.103F5854@ifrance.com> <3A64AA24.529272DF@jetnet.ab.ca> <3A6B2448.800F986E@ifrance.com> <3A6B8943.909BA0F1@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 23:58:35 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4daed34c1993fe923cee179fd08b9daf Status: R X-Status: N re...

Yann Guidon a =E9crit :
>
> Nicolas Boulay wrote:
> > reHello,
> idem again,
>
> > Ben Franchuk a =E9crit :
> > > Nicolas Boulay wrote:
> > > > Go to your bios of your computer, then turn off your ca= che L1 and L2
> > > > (called internal and external cache). And you will see = what happen...
> > > Yes I know massive slow down.
> <snip>
> > > Pipelining the memory helps but this is
> > > near the limit of physics here for speed. As clock speeds ge= t faster
> > > it not possible to build bigger caches, so I am asking are t= here alternatives
> > > to large caches?
> > You can try to reduice the size of the code at the maximum, to sa= ve
> > space.
> that's only one side of the problem. What about the data ????
>
> > I try to propose to make something which look like the opposite > > of CISC. In CISC, you have a 32 bit decoders and some instruction= about
> > 20 byte. Here, i propose to have a larger decoder compare to the = size of
> > usual instruction. Imagine having a 64 bit decoders with 64, 32 a= nd 16
> > bit instruction. The goal is to avoid to have unused bit inside > > instruction, it's waste of space. It's used by TI to reduice code=
> > footprint for this DSP (32 bit decoder with 8 to 48 bit instructi= on).
> > ARM use a different technique. There have 32 instructions RISC > > processors, and make a compact subset of 16 bit instructions. The= y have
> > also an instruction to change the type of the instruction used. T= hey
> > lose a little performance but have a gain of somethink like 30-40= % in
> > code size.
> unless you're running in a smartcard, it's useless.

NO, it's used in every handy, all over the world. And in a lot of system with strong control need.

> you better try to :
> - remove all the "dead code"
> - use the best optimisation flags with a good compiler (you win your 3= 0%)
> - pack your data with the right alignment and avoid all the
>   useless temporary representations or tables
> - reuse as much data and code as possible
> etc...
> the list is endless, look at a good book.
>

Your are tiring. This 30% gain is ALWAYS true. So after save 30 % of the code size with your methode, you will gain another 30% when you use the
THUMB instruction set.

> Coding in HLL often hides the real loss in space.
> C is particularly wasteful. C++ is even worse.
> coding in asm might give you good results (if you care
> to analyse properly your application).
>
> there's no magic, no secret.
>
Coding an application is a balance between the cost and the time, only ! More time, less money. That simple, ASM =3D much longer, so never ASM. The<= BR> usual rules is L^1.5~=3Dmonth*men with L the number of lines, With a size of 10 times the size of the C code, you imagine the time lost !

To apply your trick, you need some weeks. To switch between normal code
to THUMB code, it's one second (if it's written in C of coures ;>>>= ;)

> > > Ben.
> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Nicolas Boulay Mon Jan 22 23:58:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00324 for ; Tue, 23 Jan 2001 17:14:22 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:14:22 +0100 (MET) Received: (qmail 12011 invoked by uid 0); 22 Jan 2001 23:20:14 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 22 Jan 2001 23:20:14 -0000 X-eGroups-Return: sentto-1101623-2086-980205537-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 22 Jan 2001 23:20:09 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 23:18:56 -0000 Received: (qmail 17543 invoked from network); 22 Jan 2001 22:50:13 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 22 Jan 2001 22:50:13 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 22 Jan 2001 22:50:12 -0000 Received: from ifrance.com (nas13-239.vlt.club-internet.fr [195.36.163.239]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA25553 for ; Mon, 22 Jan 2001 23:50:08 +0100 (MET) Message-ID: <3A6CBB25.1FE9ABB@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> <3A6A4BA0.5E7DB94A@f-cpu.org> <3A6AEDC2.9D304989@ifrance.com> <3A6B7FE2.6789E633@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 23:58:45 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6091206dab68fc5daae482a63f03ce2e Status: R X-Status: N hello,

Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas Boulay wrote:
> > Hello,
> > Yann Guidon a =E9crit :
> > > Nicolas Boulay wrote:
> > > > Since the beginning, i try find a way to speed up the f= cpu without the
> > > > need of OOO and register renaming.
> > > better SMT than OOO... FC0 is already OOOC and it's a good e= nough compromise.
> > OOOC isn't the same usfullness as OOO.
> it depends. OOOC requires good binaries, while OOO is meant to compens= ate for
> "old" binaries. We have no old binaries, so we can make good= code from the start.
>
Klar ! Sur ! (Evidement is too long ;p)
> But if you look closely, OOOC is simply a "reversed" OOO. > OOO is like a normal CPU, or OOOC, with the "completion" uni= t at the end
> of the pipeline, instead of at the decoder stage. OOO adds renamed reg= isters.
> Otherwise, it's roughly similar.
>

Register renaming has nothing to do with ooo !

> > > > 64 registers are good but if you have
> > > > a depencies of 8 instructions (with big pipelining) you= could execute 8
> > > > instruction at the same times. that's good.
> > > wrong. You forget that an instruction has (in average) 2 sou= rces
> > > and 1 destination. so we can do 64/3=3D21 instructions witho= ut stalling.
> > > that's 2*2*5 or 3*7 and optimistic because in reality, it's = never that easy.
> > Sorry, i was much more too optimistik ;p
> maybe you should write more asm code ;-P
>
Not time to waste ;p
> > > > To had more register as for
> > > > Sparc, windowed register with 2 more ASM instructions t= o slide the
> > > > windows could increase the number of usable register. B= ut i think you
> > > > could only save some access to the main memory.
> > > explicit renaming is interesting but it creates enough troub= les
> > > everywhere that we must be very careful. It adds more inform= ations
> > > to store, to backup (how ?) and keep coherent.
> > If you know when you slide the window, you could save your regist= er
> > (it's only slower)
> in fact, my problem with explicit renaming (window shifting) is the > "fragmentation". let me explain it.
>
> register windows, in our case, is meant to increase the number of logi= cal
> and usable registers. But in real cases, we access register in a almos= t-random
> fashion. this means that in the worst case, we would have to "sli= de" the window
> three times per instruction (with 3-op instructions) because the opera= nds are all
> out of reach. reducing this is a big pain for the compiler.
>

Not realy, SPARC do that for a very long time, now !

> > > > The first thing to do to execute more than 1 inst per c= lock cycle is to
> > > > try to use during the same times differents units. But = you have to
> > > > reconise which instruction could be use in the same tim= es.
> > >
> > > i've thought about a trick to detect if 2 instructions (or a= ny number)
> > > could be issued at the same time. If we estimate that the un= it is coded
> > > in the opcode and only in the upper part, a 6-bit substract = could done
> > > between 2 consecutive instructions. If the result is above a= certain limit,
> > > there's no chance of unit hazard. This can be applied in par= allel
> > > with a reasonable amount of different instructions.
> >
> > No really, 2 concecutives instruction could see as in the same bl= oc with
> > your scheme. And read a bit is much more easy. (imagine to do 6 > > substracts for 6 decoders, it's make a very long path)
>
> you forget a little detail...
> 1) the substracts are in parallel

I simply said that you method don't work at all !
imagine ADD coded by 3
      SUB coded by 4
ADD R1 R2 R3 (write in R1 as usual)
SUB R4 R1 R2

So you're trick work but it's false here !


> 2) we don't make a DSP, but a platform that will run with several kind= s
> of cores. pairing rules that apply to a core will give bad performance=
> on other cores. look at the transition from the Pentium to the PII, > and from PII/PIII to P4.
>
There is no pairing rules. You just have to say : make big bloc of
none-dependant code using the maximum differents units. It's much more
general than pairing rules, no ?

> This means that we have to find a "generic" way to do this.<= BR> >
I try !

> Fortunately, we have enough time to search a good method, because we > better build a 1-inst/cycle version before designing a larger version<= BR> > that would never exist and force us to use a specific and possibly wro= ng
> method.
>
> > > > So i propose to add a depencies bit inside the instruct= ion.
> > > too late.
> > Hum, i don't think so, the insctruction as been defined with the = binary
> > code, but without knowing what all is need.
> I have first tried to promote a 7-bit opcode.
> After the instruction census started, it appeared that it would not be= enough.
>
> > A good number of instruction have been chosen, but why not change= how to
> > code all of this ? Nothing is written about it (in vhdl).
> how/what do you want to change ?
>

How instructions are binary coded ! I would like to add 2 more bit by
register call to do some op with memory. So in each instruction you
could have :
XXX R1 R2 R3
XXX [R1] R2 R3
XXX R2 [R1++] R3
XXX R2 [R1++] [R3--]
And all the combination you want. -- isn't so usefull but i have an op
left.

- No more load and store (save code space, so some bandwith).
- much less dependancies with the use of concecutive ++ or --.(less
bubble in the pipeline)
- use of dual ported memory (2 read and one write), possible only with
the L1 cache but you could increase the speed between 2 to 3 !!!!!!!!!
(in fact like DSP does)

DSP use an other trick to be sure that every clock its MAC unit are
always used ! They have a "repeat bloc" instruction.
ex :
REPEAT R1 , <imm>
XXX
XXX

imm is number of instruction to repeat, it must be small as ~16
instructions (without jmp instruction). R1 is the "bound" registe= r, it
is loaded and decrease each loop. The big problem is its impossible to
switch the context. Because it's impossible to save the state "we are = in
REPEAT loop". DSP does this, but they don't switch during repeat loop.=
We could do the same thing BUT we must limit the number inside the
register. It could be done by a special register.
- it save lot of code space (the usual way to avoid loop management is
to... unroll totally or partially the loop)
- Avoid the bubble at the beginning of the decoder (with a big pipeline, the "taken" jmp instruction has to be decoded before the load of = the new
PC, even with branch prediction)

> > > > All consecutive instruction with the bit equal could be= used in parallel.
> > > > You will have packet with 1, then a packet with 0.
> > > are you just copying the c6x or what ? :-P
> > YES ! But it seems so easy to use it for variable lenght supersca= lar
> > processor !
> too easy. so easy that it will trap you later.
>
> The case is easy for the C6x : TI controls everything and the target m= arket
> is very limited. The CPU is meant to run "trusted code" that= is meant to be perfect.
> In the F-CPU world, the chip will certainly be used in a multi-user st= ation
> that can run "untrusted" code and even viruses. We don't con= trol the evolution
> of the core (anybody can modify it) and TI's "trick" will re= ach its limits quickly.
> For example : imagine that we implement that in the FC1. Everything wi= ll be fine.
> Now somebody makes FC2 with a different decoder/execution pipeline. Th= e bits
> that you have put in the instruction will not be useful at all, so you= waste 1/32
> of the memory bandwidth. Now, somebody generates badly packed instruct= ions
> (the packet bit is wrong). Will the CPU burn ?

No you just make a big pipeline stall (the scoreboard is always
working). You should be stupid to think of creating a self-burning
design ;p

> Intel knew these problems and have not implemented a "pure" = VLIW for the IA64.
> scalability and security are very important problems and it's priority= #1 in the
> project.
>
They add some bit to  encapsulat a packet so you can't add any more pipeline

> > > > If the fcpu have many decoder, he could launch every pa= cket in the same
> > > > time if he had enought unit. So a coding rules will be = to interleave the
> > > > use of the different unit. And after that you could add= one more adder
> > > > and speed up the code a little bit.
> > > >
> > > > I think it's easy what do you think of it ?
> > > it's incomplete. the register hazards are another problem. > > No, it's totally fixe by the dependance bit. You just have to che= ck the
> > code of the instruction. Scoreboard are used in the same manner a= s
> > befor.
> outside of the opcode, every additional information is considered as > "hint" (indice) that is meant to enhance the performance of = the code.
> The problem here is that your bit is not general enough. You can use > this for superscalar cores, ok, but it's useless for OOO cores or

OOO is stupid, it's how to repear error from the past !!!! :(
And the ooo core could always try to schedule the packet.

> single-issue cores (like the FC0).
> Maybe you can pack all your bits inside one instruction,
> inside a 16-bit field. This instruction is interpreted as NOP on
> the architectures that don't use it. Otherwise, it can contain
> almost any hint about a packet of instructions. You can prefix a
> packet of 7 or 15 instructions with one "hint" instruction t= hat
> will inform (early !) the decoder of the dependencies inside the packe= t.
> THAT is a possible solution and compromise.
>

That's put a fsm to remember how to choose instruction, so ... i don't
like it so much. But for memory footprint it could be great. (But i
imagine that no compiler designer will use this unuseful instruction for fc0, and you loose it's gain for fc1)

> > > I propose several alternatives that can be used in conjuncti= on.
> > > - The "VLIW" approach has been studied... a lot an= d since a long time.
> > > the raw VLIW and the superscalar approaches can't be used ve= rbatim,
> > > something more synthetic and flexible must be used.
> > That's not what i propose ?
> no. It's "too simple" and you hit the wall when you exceed t= he target goal.
> more specifically : it's not flexibe enough.
>
> > > A good way to help is with the help of a "hint instruct= ion",
> > > something that is decoded as NOP when it is not supported, > > > but otherwise explicits the data and unit hazards for the > > > next N instructions. The format is not yet determined, it mu= st
> > > fit in 24 bits, that's all.
> > no, you can't do that without having an explosion of the code siz= e.
> i explained in the above paragraph how you avoid this code explosion.<= BR> > And when you're not inside a critical section, you can remove this
> hinting instruction. OTOH when you're sure that the code runs 99% in t= he cache,
> you can use (in average) 1 hint instruction ("PACK") every 8= instructions
> (the first 32 bits of a 256-bit wide cache line).
>
> THAT is what i call flexible ;-P
>
> > > - The "dynamic" approach. it is similar to the Pen= tium or P4 approach :
> > > the instructions are decoded when they enter the Instruction= cache,
> > > the register and unit hazards are decoded, so there's a perf= ormance hit
> > > only at the first execution. The Pentium did that for decodi= ng the
> > > packet (instruction pairs) : the data from the cache is exec= uted once,
> > > the instructions boundaries are written to the instruction c= ache,
> > > so for the next executions, the decoder already knows if it = can execute
> > > 1 or 2 instructions.
> >
> > It's the story of the trace cache, read
> > http://www.emul= ators.com/pentium4.htm and you will hate the trace cache
> > : it's a gain of decoding but your 96 Kbyte of cache is like a 8K= o of L&
> > cache compare to the 128 Ko of the athlon.
>
> i spoke about the old good P53C (the "Pentium" that sits on = my desk), not
> about the newer "P4" (expensive and deceiving).
>
> "trace cache" would be in a RISC->TTA core, but since it'= s a RISC ISA
> as input, there is much less bloat ;-)
>
> > > Since it is regenerated everytime, it's "dynamic" = and is independent
> > > from the rest.
> > But too small !
> hey ! we don't have to decode x86 instructions !
> one RISC instruction (32-bits) can generate in average 3 TTA instructi= ons
> (4 or 5 for L/S) and these instructions are commonly 16-bits
> (it can be changed easily because it's internal and hidden to the user= ).
> i expect around 30% bloat but much more parallelism !
>
> > > - Better : a F-CPU/RISC->TTA translator. it's implicitely= OOO but
> > > it might be very interesting. the instructions are recoded a= s TTA
> > > instructions and stored in a big buffer acting as the instru= ction cache,
> > > it's similar to the P4 architecture but less heavy :-)
> > Bof, too far from our risc architecture, and maybe hard to make i= t
> > parallel.
> far from it. You're too young on the list ;-P when AlphaRisc was there= ,
> he would have flamed you for that remark ;-D TTA has certain advantage= s
> and a RISC->TTA core would be a good solution to bypass the patents= on
> the OOO cores.
>
> > > - SMT. did you forget that ? :-)
> > In smt, you don't increase the number of instruction issued by cl= ock cycle !
> au contraire. You enhance the use of the decoder and the execution uni= ts.
> OTOH you completely overflow the memory bandwidth ... but it'd another= discussion.
>
> An illustration of what i said is with "lazy SMT". it's for = example a
> core with 4 instructions issued at every cycle, from 4 different threa= ds
> (a bit like 4xFC0 in parallel). The dependency checks are only local.<= BR> > When there is a "bubble", you can check the neighbours to ss= e if they can execute
> another instruction that would fill the empty slot.
> So then YES SMT /can/ increase and ease this increase in IPC.
>
4 cores, how do you call that ? It isn't smt, it's simply SMP. If you
have to choose which is the next instruction it will became horrible
(scheduling, ...).
> read you all tomorrow,
>
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs fo= r $0.49 each!
3D""
From Nicolas Boulay Mon Jan 22 23:58:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00327 for ; Tue, 23 Jan 2001 17:14:25 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:14:25 +0100 (MET) Received: (qmail 29562 invoked by uid 0); 22 Jan 2001 23:24:12 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx22) with SMTP; 22 Jan 2001 23:24:12 -0000 X-eGroups-Return: sentto-1101623-2087-980205846-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 22 Jan 2001 23:24:09 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 22 Jan 2001 23:24:05 -0000 Received: (qmail 16989 invoked from network); 22 Jan 2001 22:50:05 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 22 Jan 2001 22:50:05 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta3 with SMTP; 22 Jan 2001 23:51:09 -0000 Received: from ifrance.com (nas13-239.vlt.club-internet.fr [195.36.163.239]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA11459 for ; Mon, 22 Jan 2001 23:50:02 +0100 (MET) Message-ID: <3A6CBB20.DA36B76E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A4BA3.C6B6174@f-cpu.org> <3A6455B8.4EABB1A0@jetnet.ab.ca> <3A6B7FE3.A526A384@f-cpu.org> <3A64E313.6661F79@jetnet.ab.ca> <004b01c08458$15194520$29e65982@student.utwente.nl> <3A6549CE.2BA14F59@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 22 Jan 2001 23:58:40 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 004eb83d96a357cb974689a7015b9bc5 Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> Marco Al wrote:
>
> > This will be a slight problem AFAICS, VHDL and synthesis are clos= e enough to
> > programming to find some people who can become proficient at it a= nd have some
> > free tools available... but both the tools and the skills for lib= rary
> > development in deep sub micron processes are a little more rare (= for instance
> > are there any free tools which can do phase shift compensation et= c. ?) and of
> > course for layout we will need commercial tools regardless. And t= hen there's
> > timing verification...
> >
> At the very high speeds I guess still 90% of the layout still

Not any more ! I have speak with the C5000 team leader from TI. All the
new core (c55) was written in vhdl, just the memory was added after (and register, too, i suppose).

> will be by hand. Since I am using FPGA's for my Computer designs
> I have not looked at this site, but some DAM fast chips are designed > here. Read all you can about Chuck Moore and his cad system.
> http://www.ultra= technology.com/people.htm
> If you need to go commercial this guy is a good contact.
> > Marco
> Ben.
> PS. Also a great place to buy a FORTH processor.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
nicO
eGroups Sponsor=
3D"Choose
Choose 3 DVDs fo= r $0.49 each!
3D""
From Ben Franchuk Wed Jan 17 14:11:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00342 for ; Tue, 23 Jan 2001 17:14:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:14:30 +0100 (MET) Received: (qmail 30854 invoked by uid 0); 23 Jan 2001 00:27:21 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx17) with SMTP; 23 Jan 2001 00:27:21 -0000 X-eGroups-Return: sentto-1101623-2088-980209321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mw.egroups.com with NNFMP; 23 Jan 2001 00:22:21 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 00:22:00 -0000 Received: (qmail 57103 invoked from network); 22 Jan 2001 23:48:13 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 22 Jan 2001 23:48:13 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 22 Jan 2001 23:48:12 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA29439 for ; Mon, 22 Jan 2001 16:41:07 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A6599E5.413577C3@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> <3A6A4BA0.5E7DB94A@f-cpu.org> <3A6AEDC2.9D304989@ifrance.com> <3A6B7FE2.6789E633@f-cpu.org> <3A6CBB25.1FE9ABB@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 17 Jan 2001 06:11:01 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8a63fa94b9094e6325ee04d7705b1c91 Status: R X-Status: N Nicolas Boulay wrote:
> > of the memory bandwidth. Now, somebody generates badly packed instructions
> > (the packet bit is wrong). Will the CPU burn ?
> No you just make a big pipeline stall (the scoreboard is always
> working). You should be stupid to think of creating a self-burning
> design ;p

Even with a good packet a CPU can burn.
Some where I read that some combinations of instructions
could cause a early F21 cpu to melt. I could not find where
I read that but here good page on the very  highspeeds that
that can be reached in a CPU.(about a year old)
http://www.ultratechnology.com/echo.htm
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From whygee@club-internet.fr Tue Jan 23 10:44:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00391 for ; Tue, 23 Jan 2001 17:15:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:15:54 +0100 (MET) Received: (qmail 1232 invoked by uid 0); 23 Jan 2001 09:45:06 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx15) with SMTP; 23 Jan 2001 09:45:06 -0000 X-eGroups-Return: sentto-1101623-2089-980243099-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 23 Jan 2001 09:45:04 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 09:44:58 -0000 Received: (qmail 59597 invoked from network); 23 Jan 2001 09:44:57 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 Jan 2001 09:44:57 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta1 with SMTP; 23 Jan 2001 09:44:57 -0000 Received: (from mnet@localhost) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA01626; Tue, 23 Jan 2001 10:44:54 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 Jan 2001 10:44:54 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: shifter (was Re: [f-cpu] conferences) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7e3ab4c54461953ea27952e52a9b0f78 Status: R X-Status: N hello,
Michael Riepe wrote:
> Yann GUIDON wrote:
> [...]
> > the ROP2 unit is already full.
> The SHL unit won't be empty either, and it will be rather hard to squeeze
> it into a single pipeline stage.  Dropping the tiny logic unit at the
> end may help a lot.
but that's temporary...

> > maybe we should drop this instruction temporarily ?
> > the opcode and behaviour is reserved, the implementation is
> > not too difficult but it doesn't fit in the FC0, it's not a catastrophe/drama...
> > plus, there's no bitop in high-level langages. we will have enough
> > time to implement it later...
> Hmm... a bitop can be replaced with 3 other instructions: loadcons,
> shiftl, and/or/xor.  If the shift count is a constant, you can calculate
> the shifted constant at compile time (2 instructions).  You lose one
> or two registers this way, but it really is no drama, right.
jop.
no need to be a comletist if we want to make a prototype...

> Ok, let's drop it for now.  It's an optional instruction anyway.
exactly.

have fun,

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
YG
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From whygee@club-internet.fr Tue Jan 23 10:48:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00394 for ; Tue, 23 Jan 2001 17:15:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:15:55 +0100 (MET) Received: (qmail 31343 invoked by uid 0); 23 Jan 2001 09:48:48 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx05) with SMTP; 23 Jan 2001 09:48:48 -0000 X-eGroups-Return: sentto-1101623-2090-980243302-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 23 Jan 2001 09:48:32 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 09:48:22 -0000 Received: (qmail 63767 invoked from network); 23 Jan 2001 09:48:22 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 Jan 2001 09:48:22 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 23 Jan 2001 09:48:21 -0000 Received: (from mnet@localhost) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA03098; Tue, 23 Jan 2001 10:48:18 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 Jan 2001 10:48:18 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 27eb1ed1a58df297769a7310b0aab79c Status: R X-Status: N coucou !
continuons cette sympathique engueulade en regle ;-)

Nicolas Boulay wrote:
> hello,
> Yann Guidon a =E9crit :
> > hi !
> > Nicolas Boulay wrote:
> > > Hello,
> > > Yann Guidon a =E9crit :
> > > > Nicolas Boulay wrote:
etc. etc.

> > But if you look closely, OOOC is simply a "reversed" OO= O.
> > OOO is like a normal CPU, or OOOC, with the "completion"= ; unit at the end
> > of the pipeline, instead of at the decoder stage. OOO adds rename= d registers.
> > Otherwise, it's roughly similar.
> Register renaming has nothing to do with ooo !
u'r kiddin' ?
regren is CRITICAL ! without that, it's impossible to even issue instructio= ns
out of order, because you have to remap the "new" value. If the i= ssue was too
speculative and appears to be false, you have to restore the old value.
read some opt. books for the PPC...

> > > Sorry, i was much more too optimistik ;p
> > maybe you should write more asm code ;-P
> Not time to waste ;p
and you think that you have nothing to learn, too ?
writing some apps in asm will teach you a lot.
you'll understand for example that a lot of things
are pure waste.


> > > If you know when you slide the window, you could save your r= egister
> > > (it's only slower)
> > in fact, my problem with explicit renaming (window shifting) is t= he
> > "fragmentation". let me explain it.
> >
> > register windows, in our case, is meant to increase the number of= logical
> > and usable registers. But in real cases, we access register in a = almost-random
> > fashion. this means that in the worst case, we would have to &quo= t;slide" the window
> > three times per instruction (with 3-op instructions) because the = operands are all
> > out of reach. reducing this is a big pain for the compiler.
>
> Not realy, SPARC do that for a very long time, now !
>
no. it does slide the window when there's a call.
it's different. and it's worse because it means that you have
less usable registers at a time.

> > > > i've thought about a trick to detect if 2 instructions = (or any number)
> > > > could be issued at the same time. If we estimate that t= he unit is coded
> > > > in the opcode and only in the upper part, a 6-bit subst= ract could done
> > > > between 2 consecutive instructions. If the result is ab= ove a certain limit,
> > > > there's no chance of unit hazard. This can be applied i= n parallel
> > > > with a reasonable amount of different instructions.
> > >
> > > No really, 2 concecutives instruction could see as in the sa= me bloc with
> > > your scheme. And read a bit is much more easy. (imagine to d= o 6
> > > substracts for 6 decoders, it's make a very long path)
> >
> > you forget a little detail...
> > 1) the substracts are in parallel
>
> I simply said that you method don't work at all !
> imagine ADD coded by 3
>         SUB coded by 4
> ADD R1 R2 R3 (write in R1 as usual)
> SUB R4 R1 R2
>
> So you're trick work but it's false here !

the trick is not to take the result of the substraction "verbatim"= ;
but to "evaluate the distance" of the opcodes.
so 3-4=3D-1, just remove the -, and that's all. if the minimal distance
is 4 for example, you'll see that there's a dependency.
Of course this should be enhanced... but it gives you a rough idea.

finally, a simple hardwired LUT would do the trick.

> > 2) we don't make a DSP, but a platform that will run with several= kinds
> > of cores. pairing rules that apply to a core will give bad perfor= mance
> > on other cores. look at the transition from the Pentium to the PI= I,
> > and from PII/PIII to P4.
> There is no pairing rules. You just have to say : make big bloc of
> none-dependant code using the maximum differents units. It's much more=
> general than pairing rules, no ?
of course it's more general and it must be promoted.
i would even add some other specifications.
The problem is that in the reality we don't know the actual
"packing" rules and it changes all the time.

> > This means that we have to find a "generic" way to do t= his.
> I try !
that's not good enough ;-P

> > > A good number of instruction have been chosen, but why not c= hange how to
> > > code all of this ? Nothing is written about it (in vhdl). > > how/what do you want to change ?
> How instructions are binary coded ! I would like to add 2 more bit by<= BR> > register call to do some op with memory. So in each instruction you > could have :
> XXX R1 R2 R3
> XXX [R1] R2 R3
> XXX R2 [R1++] R3
> XXX R2 [R1++] [R3--]
> And all the combination you want. -- isn't so usefull but i have an op= left.

I understand what you mean.
unfortunately it's too late to do that on the existing ISA.
OTOH i have already explained how it can be integrated (differently
and more efficiently !)

> - No more load and store (save code space, so some bandwith).
no. in fact, the memory bandwidth will be even more saturated.
you'll win some bytes of instructions in the loops, but you'll
code much more L/S and this will stall the core unless you have
4 independent memory ports etc...

> - much less dependancies with the use of concecutive ++ or --.(less > bubble in the pipeline)
not sure, but it's an argument.

> - use of dual ported memory (2 read and one write), possible only with=
> the L1 cache but you could increase the speed between 2 to 3 !!!!!!!!!=
> (in fact like DSP does)
DSP are often low-speed, the constraints will be much worse on a high-speed=
design. it will put a lot of pressure on the memory system and it's the fir= st
thing we'll have to redesign.

> DSP use an other trick to be sure that every clock its MAC unit are > always used ! They have a "repeat bloc" instruction.
> ex :
> REPEAT R1 , <imm>
> XXX
> XXX

that is for the TI. other DSP do other things,
but the TI DSP (before the c6x) were ... hum...
awfull. disastrous. ie: on the early TI DSP,
the vector codes would not be efficient if the loop
was not 4 instructions. it was because of the wicked pipeline...

> imm is number of instruction to repeat, it must be small as ~16
> instructions (without jmp instruction). R1 is the "bound" re= gister, it
> is loaded and decrease each loop. The big problem is its impossible to=
> switch the context.
now you understand why we don't use this in hte f-cpu :-)

> Because it's impossible to save the state "we are in
> REPEAT loop". DSP does this, but they don't switch during repeat = loop.
the ADi DSP (21xx, 21K) have a "loop stack" but it's very complex= to manage and it
does not suit at all for a simple RISC CPU. it implicitly limits the
architecture and it was rejected. otherwise, the context buffer would grow = out of
measure...

> We could do the same thing BUT we must limit the number inside the
> register. It could be done by a special register.
> - it save lot of code space (the usual way to avoid loop management is=
> to... unroll totally or partially the loop)
> - Avoid the bubble at the beginning of the decoder (with a big pipelin= e,
> the "taken" jmp instruction has to be decoded before the loa= d of the new
> PC, even with branch prediction)
it's out of question...

the current loop instruction is plain enough and it's completely flexible.<= BR> In the DSP, the special instructions are "0 delay", they're execu= ted once
and not inside the loop. If you unroll the loop 2 or 3, an additional instr= uction
at the end of the loop block is acceptable. so it's a simple jump with para= llel
decrement. And since we jump to a register, there's no overhead at the deco= de
stage.

> No you just make a big pipeline stall (the scoreboard is always
> working). You should be stupid to think of creating a self-burning
> design ;p
a lot of people smarter than me have made buggy designs,
or potentially dangerous. i try to avoid any potentially dangerous situatio= n.

> > Intel knew these problems and have not implemented a "pure&q= uot; VLIW for the IA64.
> > scalability and security are very important problems and it's pri= ority #1 in the
> > project.
> They add some bit to  encapsulat a packet so you can't add any mo= re
> pipeline
??

> OOO is stupid, it's how to repear error from the past !!!! :(
> And the ooo core could always try to schedule the packet.
one of the weak points of an OOO is the decode unit,
then the completion unit. if you rely too much on the core,
you might get disastrous performance.

> > Maybe you can pack all your bits inside one instruction,
> > inside a 16-bit field. This instruction is interpreted as NOP on<= BR> > > the architectures that don't use it. Otherwise, it can contain > > almost any hint about a packet of instructions. You can prefix a<= BR> > > packet of 7 or 15 instructions with one "hint" instruct= ion that
> > will inform (early !) the decoder of the dependencies inside the = packet.
> > THAT is a possible solution and compromise.
>
> That's put a fsm to remember how to choose instruction, so ... i don't=
> like it so much. But for memory footprint it could be great. (But i > imagine that no compiler designer will use this unuseful instruction f= or
> fc0, and you loose it's gain for fc1)

don't imagine, think ! :-)
if you're kazy, you don't have to use this added instruction,
but if you're fed up of slow binaries, you'll use it. that's all.

> > > > - SMT. did you forget that ? :-)
> > > In smt, you don't increase the number of instruction issued = by clock cycle !
> > au contraire. You enhance the use of the decoder and the executio= n units.
> > OTOH you completely overflow the memory bandwidth ... but it'd an= other discussion.
> >
> > An illustration of what i said is with "lazy SMT". it's= for example a
> > core with 4 instructions issued at every cycle, from 4 different = threads
> > (a bit like 4xFC0 in parallel). The dependency checks are only lo= cal.
> > When there is a "bubble", you can check the neighbours = to sse if they can execute
> > another instruction that would fill the empty slot.
> > So then YES SMT /can/ increase and ease this increase in IPC.
> >
> 4 cores, how do you call that ? It isn't smt, it's simply SMP. If you<= BR> > have to choose which is the next instruction it will became horrible > (scheduling, ...).

and now, imagine that your 4 cores share execution units ...
how do you call that ?

reread the paper (PDF about SMT) that you sent to the list
as well as other ressources. there's not much difference...


> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
YG
eGroups Sponsor=

Get 3 CDs for ONLY $9.99!
3D""
From whygee@club-internet.fr Tue Jan 23 10:49:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00397 for ; Tue, 23 Jan 2001 17:15:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:15:57 +0100 (MET) Received: (qmail 5542 invoked by uid 0); 23 Jan 2001 09:49:42 -0000 Received: from mq.egroups.com (208.50.144.79) by 10.1.4.106 (mx06) with SMTP; 23 Jan 2001 09:49:42 -0000 X-eGroups-Return: sentto-1101623-2091-980243378-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 23 Jan 2001 09:49:41 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 09:49:38 -0000 Received: (qmail 78848 invoked from network); 23 Jan 2001 09:49:38 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 23 Jan 2001 09:49:38 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 23 Jan 2001 09:49:37 -0000 Received: (from mnet@localhost) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA03654; Tue, 23 Jan 2001 10:49:34 +0100 (MET) To: f-cpu@egroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 Jan 2001 10:49:34 +0100 (MET) Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f338eb540b5fd73de5004fc89eeda007 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> re...
> Yann Guidon a =E9crit :
> > Nicolas Boulay wrote:
> > > reHello,
> > idem again,
> > > Ben Franchuk a =E9crit :
> > > > Nicolas Boulay wrote:
> > > > > Go to your bios of your computer, then turn off yo= ur cache L1 and L2
> > > > > (called internal and external cache). And you will= see what happen...
> > > > Yes I know massive slow down.
<snip>
> > > ARM use a different technique. There have 32 instructions RI= SC
> > > processors, and make a compact subset of 16 bit instructions= . They have
> > > also an instruction to change the type of the instruction us= ed. They
> > > lose a little performance but have a gain of somethink like = 30-40% in
> > > code size.
> > unless you're running in a smartcard, it's useless.
> NO, it's used in every handy, all over the world. And in a lot of syst= em
> with strong control need.

that's almost smartcard for me... just a bit more power hungry.

> > you better try to :
> > - remove all the "dead code"
> > - use the best optimisation flags with a good compiler (you win y= our 30%)
> > - pack your data with the right alignment and avoid all the
> >   useless temporary representations or tables
> > - reuse as much data and code as possible
> > etc...
> > the list is endless, look at a good book.
>
> Your are tiring.
and you think you are a good coder because you know C and you
believe the ads ;-)

> This 30% gain is ALWAYS true.
no. it's highly dependent on a lot of things.

> So after save 30 % of the
> code size with your methode, you will gain another 30% when you use th= e
> THUMB instruction set.
no.
plus, you have to put a translator in front of the decoder.
If you only run a small SW, you lose the RAM room that you won.

> > Coding in HLL often hides the real loss in space.
> > C is particularly wasteful. C++ is even worse.
> > coding in asm might give you good results (if you care
> > to analyse properly your application).
> >
> > there's no magic, no secret.
>
> Coding an application is a balance between the cost and the time, only= !
> More time, less money. That simple, ASM =3D much longer, so never ASM.= The
> usual rules is L^1.5~=3Dmonth*men with L the number of lines, With a s= ize
> of 10 times the size of the C code, you imagine the time lost !
it's not a matter of time.
if you speak about handys, you know that it doesn't have TB of code.
-1) most of the code (codec, interface etc) is already written by third par= ties.
-2) all you have to do is link the code and fit in the device.
now, you speak about time. maybe you have never programmed in asm,
so you can't speak about it.

> To apply your trick, you need some weeks. To switch between normal cod= e
> to THUMB code, it's one second (if it's written in C of coures ;>&g= t;>)
that's a bit... short for a demonstration.
your faith in C compilers is a proof of youth, that's all :-)

> > > > Ben.
> > > nicO
> > WHYGEE
> nicO
YG
eGroups Sponsor=
3D"Choose
Choose 3 DVDs fo= r $0.49 each!
3D""
From Jeff Davies Tue Jan 23 11:44:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00409 for ; Tue, 23 Jan 2001 17:16:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:16:03 +0100 (MET) Received: (qmail 10694 invoked by uid 0); 23 Jan 2001 10:54:31 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx23) with SMTP; 23 Jan 2001 10:54:31 -0000 X-eGroups-Return: sentto-1101623-2092-980247270-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 23 Jan 2001 10:54:31 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 10:54:29 -0000 Received: (qmail 18715 invoked from network); 23 Jan 2001 10:54:29 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 Jan 2001 10:54:29 -0000 Received: from unknown (HELO cmailg6.svr.pol.co.uk) (195.92.195.176) by mta2 with SMTP; 23 Jan 2001 10:54:29 -0000 Received: from modem-14.sulfur.dialup.pol.co.uk ([62.136.15.14] helo=llandre.freeserve.co.uk) by cmailg6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14L15m-0008GM-00 for f-cpu@egroups.com; Tue, 23 Jan 2001 10:54:27 +0000 Message-ID: <3A6D6070.5706A69D@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@egroups.com References: From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 Jan 2001 10:44:00 +0000 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1d45b2a26c236a9ff03a520e408d4baa Status: R X-Status: N whygee@club-internet.fr wrote:

> > Register renaming has nothing to do with ooo !
> u'r kiddin' ?
> regren is CRITICAL ! without that, it's impossible to even issue instructions
> out of order, because you have to remap the "new" value. If the issue was too
> speculative and appears to be false, you have to restore the old value.
> read some opt. books for the PPC...

Wow. I hadn't thought of register renaming being used in this way. This is absolutely
amazingly excellent.
Have any studies been done to work out how many registers would you need for best OOO
performance,
given 64 register "names"?
What else would register renaming be used for?
Perhaps context switches?
How does this affect smooth register backup?

ps what is OOOC?

Jeff Davies
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Yann GUIDON Tue Jan 23 12:55:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00427 for ; Tue, 23 Jan 2001 17:16:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 23 Jan 2001 17:16:08 +0100 (MET) Received: (qmail 5552 invoked by uid 0); 23 Jan 2001 12:01:53 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx04) with SMTP; 23 Jan 2001 12:01:53 -0000 X-eGroups-Return: sentto-1101623-2093-980251305-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 23 Jan 2001 12:01:49 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 23 Jan 2001 12:01:45 -0000 Received: (qmail 57186 invoked from network); 23 Jan 2001 12:01:44 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 Jan 2001 12:01:44 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 23 Jan 2001 13:02:49 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA03696; Tue, 23 Jan 2001 04:01:40 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWDQ8; Tue, 23 Jan 2001 12:06:23 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A6D712A.2D92962E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com References: <3A6D6070.5706A69D@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 23 Jan 2001 12:55:22 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f8628b34409611d3489ad35999638407 Status: R X-Status: N Jeff Davies wrote:
>
> whygee@club-internet.fr wrote:
>
> > > Register renaming has nothing to do with ooo !
> > u'r kiddin' ?
> > regren is CRITICAL ! without that, it's impossible to even issue instructions
> > out of order, because you have to remap the "new" value. If the issue was too
> > speculative and appears to be false, you have to restore the old value.
> > read some opt. books for the PPC...
>
> Wow. I hadn't thought of register renaming being used in this way. This is absolutely
> amazingly excellent.
> Have any studies been done to work out how many registers would you need for best OOO
> performance,
> given 64 register "names"?
> What else would register renaming be used for?
> Perhaps context switches?
> How does this affect smooth register backup?
>
> ps what is OOOC?
>
> Jeff Davies

hi,

the Power architecture and the PPC have a certain number of
"renamed registers", around 1 per unit, to store the temporary
results of speculative execution. when the completion unit
validates the instruction, it is retired from the instruction buffer
and the associated cached register is written to the bank (or
something like that). that's how the 601, 603 etc. work.

Then the P6 core came and added a slew of registers to hide
memory latency and compensate for the low number of actual
registers.

As for the number of registers needed for OOOing a 64-reg CPU,
i don't know. there is already some pressure on the register
set, it is already rather large. 128 would be ok, it's the
size for some OOO cores (add to that the high number of ports
that double the actual surface and latency...).

SRB with OOO is even smoother because the new registers are "fresh",
you don't have to flush the physical location before you use the
register.

OOOC : a term i invented to describe the FC0,
look at the F-CPU manual, ie : http://www.f-cpu.de/man/i7/part3.html#OOOC
it's still a statically scheduled core but operations can overlap.
for example you can issue a load or a division (or another long instruction),
do some other operations, and use the result later.

it's very different from OOO because there is a physical register
set that maps directly to the instructions. there is no renamed or
temporary register and the scheduler is very simple, but all the operations
must be deterministic and should not trap (otherwise it's a impossible to
restore the old state).

ok, gotta eat... RTFM ;-)

YG

speaking for himself
eGroups Sponsor
Choose 3 DVDs for $0.49 each!
Choose 3 DVDs for $0.49 each!
From Nicolas Boulay Wed Jan 24 19:06:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA04659 for ; Thu, 25 Jan 2001 05:59:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 25 Jan 2001 05:59:01 +0100 (MET) Received: (qmail 21172 invoked by uid 0); 24 Jan 2001 18:14:12 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx18) with SMTP; 24 Jan 2001 18:14:12 -0000 X-eGroups-Return: sentto-1101623-2095-980359797-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 24 Jan 2001 18:11:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 24 Jan 2001 18:09:57 -0000 Received: (qmail 61400 invoked from network); 24 Jan 2001 17:57:25 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 24 Jan 2001 17:57:25 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta2 with SMTP; 24 Jan 2001 17:57:25 -0000 Received: from ifrance.com (nas20-64.vlt.club-internet.fr [195.36.170.64]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA05334 for ; Wed, 24 Jan 2001 18:57:22 +0100 (MET) Message-ID: <3A6F1991.86C54AFD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: <3A63D852.AC4F2DD@jetnet.ab.ca> <004501c08320$896b0be0$29e65982@student.utwente.nl> <3A6410BB.C979B4C6@jetnet.ab.ca> <001901c0832d$c2c807f0$29e65982@student.utwente.nl> <3A641EDC.AF6D4D61@jetnet.ab.ca> <000701c0833c$1626eca0$29e65982@student.utwente.nl> <3A6A3042.73971564@ifrance.com> <3A6A4BA0.5E7DB94A@f-cpu.org> <3A6AEDC2.9D304989@ifrance.com> <3A6B7FE2.6789E633@f-cpu.org> <3A6CBB25.1FE9ABB@ifrance.com> <3A6599E5.413577C3@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 Jan 2001 19:06:09 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] scalar processor Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 01d8b2ba11ab73441f7fcfc3311e5f2a Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> > > of the memory bandwidth. Now, somebody generates badly packe= d instructions
> > > (the packet bit is wrong). Will the CPU burn ?
> > No you just make a big pipeline stall (the scoreboard is always > > working). You should be stupid to think of creating a self-burnin= g
> > design ;p
>
> Even with a good packet a CPU can burn.
> Some where I read that some combinations of instructions
> could cause a early F21 cpu to melt. I could not find where

This cpu was asynchronous that's why it can burn. And if you want burn
an 800 Mhz Athlon put it around 1000 or 1100 Ghz and raised the
voltage...

> I read that but here good page on the very  highspeeds that
> that can be reached in a CPU.(about a year old)
> http://www.ultrate= chnology.com/echo.htm
> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor=
3D"Choose
Choose 3 DVDs f= or $0.49 each!
3D""
From Nicolas Boulay Wed Jan 24 20:10:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA04683 for ; Thu, 25 Jan 2001 05:59:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 25 Jan 2001 05:59:09 +0100 (MET) Received: (qmail 21773 invoked by uid 0); 24 Jan 2001 19:17:57 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx23) with SMTP; 24 Jan 2001 19:17:57 -0000 X-eGroups-Return: sentto-1101623-2097-980363876-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 24 Jan 2001 19:18:01 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 24 Jan 2001 19:17:56 -0000 Received: (qmail 51866 invoked from network); 24 Jan 2001 19:01:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 24 Jan 2001 19:01:49 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 24 Jan 2001 20:02:53 -0000 Received: from ifrance.com (nas20-64.vlt.club-internet.fr [195.36.170.64]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA25655 for ; Wed, 24 Jan 2001 20:01:45 +0100 (MET) Message-ID: <3A6F28A9.77192377@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@egroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 Jan 2001 20:10:33 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] Cache use? Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3f6489174b5d586cafe1b405abfc687c Status: R X-Status: N Hello,
whygee@club-internet.fr a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > re...
> > Yann Guidon a =E9crit :
> > > Nicolas Boulay wrote:
> > > > reHello,
> > > idem again,
> > > > Ben Franchuk a =E9crit :
> > > > > Nicolas Boulay wrote:
> > > > > > Go to your bios of your computer, then turn o= ff your cache L1 and L2
> > > > > > (called internal and external cache). And you= will see what happen...
> > > > > Yes I know massive slow down.
> <snip>
> > > > ARM use a different technique. There have 32 instructio= ns RISC
> > > > processors, and make a compact subset of 16 bit instruc= tions. They have
> > > > also an instruction to change the type of the instructi= on used. They
> > > > lose a little performance but have a gain of somethink = like 30-40% in
> > > > code size.
> > > unless you're running in a smartcard, it's useless.
> > NO, it's used in every handy, all over the world. And in a lot of= system
> > with strong control need.
>
> that's almost smartcard for me... just a bit more power hungry.
>
> > > you better try to :
> > > - remove all the "dead code"
> > > - use the best optimisation flags with a good compiler (you = win your 30%)
> > > - pack your data with the right alignment and avoid all the<= BR> > > >   useless temporary representations or tables
> > > - reuse as much data and code as possible
> > > etc...
> > > the list is endless, look at a good book.
> >
> > Your are tiring.
> and you think you are a good coder because you know C and you
> believe the ads ;-)
>
> > This 30% gain is ALWAYS true.
> no. it's highly dependent on a lot of things.
>
> > So after save 30 % of the
> > code size with your methode, you will gain another 30% when you u= se the
> > THUMB instruction set.
> no.
> plus, you have to put a translator in front of the decoder.
> If you only run a small SW, you lose the RAM room that you won.
>
You beleive that a decoder is as big as a RAM ????? Do you believe that
ARM and the half of handy maker are crazy ? We speak about programm
size, not performance.

> > > Coding in HLL often hides the real loss in space.
> > > C is particularly wasteful. C++ is even worse.
> > > coding in asm might give you good results (if you care
> > > to analyse properly your application).
> > >
> > > there's no magic, no secret.
> >
> > Coding an application is a balance between the cost and the time,= only !
> > More time, less money. That simple, ASM =3D much longer, so never= ASM. The
> > usual rules is L^1.5~=3Dmonth*men with L the number of lines, Wit= h a size
> > of 10 times the size of the C code, you imagine the time lost ! > it's not a matter of time.
> if you speak about handys, you know that it doesn't have TB of code. > -1) most of the code (codec, interface etc) is already written by thir= d parties.
> -2) all you have to do is link the code and fit in the device.
> now, you speak about time. maybe you have never programmed in asm,
> so you can't speak about it.
>
So you can't speak about C, C++ and VHDL ?

> > To apply your trick, you need some weeks. To switch between norma= l code
> > to THUMB code, it's one second (if it's written in C of coures ;&= gt;>>)
> that's a bit... short for a demonstration.
> your faith in C compilers is a proof of youth, that's all :-)
As the 99 % of the (true) professionnal. You should be a very old
programer to say that.
>
> > > > > Ben.
> > > > nicO
> > > WHYGEE
> > nicO
> YG
nicO
eGroups Sponsor=

Get 3 CDs for ONLY $9.99!
3D""
From Thu Jan 25 03:44:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA04809 for ; Thu, 25 Jan 2001 05:59:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 25 Jan 2001 05:59:46 +0100 (MET) Received: (qmail 32169 invoked by uid 0); 25 Jan 2001 02:40:54 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx08) with SMTP; 25 Jan 2001 02:40:54 -0000 X-eGroups-Return: sentto-1101623-2098-980390443-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 25 Jan 2001 02:40:59 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_1_2); 25 Jan 2001 02:40:42 -0000 Received: (qmail 47641 invoked from network); 25 Jan 2001 02:39:40 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 25 Jan 2001 02:39:40 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 25 Jan 2001 03:40:45 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 4A03B461F3; Wed, 24 Jan 2001 21:44:34 -0500 (EST) To: Phoenix@phinixi.com, f-cpu@egroups.com Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 24 Jan 2001 21:44:34 -0500 (EST) Reply-To: f-cpu@egroups.com Subject: [f-cpu] test for procmail Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b1b8d8f1181106eff93e7bf58a82c6c0 Status: R X-Status: N
ignore sorry just testing
eGroups Sponsor
Get 3 CDs for ONLY $9.99!
Get 3 CDs for ONLY $9.99!
From Yann GUIDON Thu Jan 25 10:15:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00308 for ; Thu, 25 Jan 2001 15:41:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 25 Jan 2001 15:41:55 +0100 (MET) Received: (qmail 1179 invoked by uid 0); 25 Jan 2001 09:21:58 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx21) with SMTP; 25 Jan 2001 09:21:58 -0000 X-eGroups-Return: sentto-1101623-2099-980414512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jj.egroups.com with NNFMP; 25 Jan 2001 09:21:57 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 25 Jan 2001 09:21:51 -0000 Received: (qmail 5063 invoked from network); 25 Jan 2001 09:21:51 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 25 Jan 2001 09:21:51 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 25 Jan 2001 10:22:56 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA00245; Thu, 25 Jan 2001 01:21:49 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWF01; Thu, 25 Jan 2001 09:26:30 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A6FEEAD.FFB27DAF@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@egroups.com X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 10:15:25 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] [Fwd: RE: "free" CPUs] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8aa1e12547f50527ac27862e655b37eb Status: R X-Status: N just as the subject states.

If any of the LEON or OpenCores or any other team members want to present
a paper, THAT's the ... highway to recognition !

the original article is still there :
http://www.chipanalyst.com/mpr_public/editorials/edit15_03.html

-------- Original Message --------
From: "Baron, Max (Cahners MDR)" <mbaron@mdr.cahners.com>
To: "'whygee@f-cpu.org'" <whygee@f-cpu.org>
Subject: RE: "free" CPUs
Date: Wed, 24 Jan 2001 20:57:59 -0500

Thank you again, Yann,

If you or your previous organization would like to present a paper on the
status of new core(s) please let me know.
The next Embedded Microprocessor Forum is in June 2001 and the deadline for
submittals is still one week away.

Best Regards,

max

-----Original Message-----
From: Yann GUIDON [mailto:yann_guidon@mentorg.com]
Sent: Tuesday, January 23, 2001 6:38 AM
To: mbaron@mdr.cahners.com
Subject: "free" CPUs


hello,

I have just read your recent article about the increasing success
of the LEON project. As one of the participants of the free hardware
movement, i am glad that this trend has finally caught your eyes :-)

There are a lot of similar projects, i belong to the F-CPU team,
and it includes people that participate to the LEON project or
to the OpenCores.org team. Other "alternative" projects are
listed by the OpenCollector.org web site. And even though most of them
are still in the early stages, OpenCores got a deal with TSMC.
The F-CPU is not going to be "ready" (that means : complete, tested,
verified and aproved) before a year, but we have had some early
propositions (nothing firm but "never the bear's skin before you
killed it").

I think that you must be prepared to an increasing flood of new CPU cores.
ARC and Tensilica are only the first signs. The really free, customizable
and successful cores will come from the bottom up, because the
electronicians
are fed up of reinventing the wheel. The darwinian evolution (selection and
death) of the current market will succumb to the coming CPU with a
"free gene pool" : they will mix, evolve, react even faster to the market
and never bore like a x86 does...

Now that i am hired (3 months) by Mentor, i have less time to participate
to this exciting world. I can only confirm that the LEON is not
only a student's hack.

regards,
YG

speaking for himself
eGroups Sponsor

www.
From Yann GUIDON Thu Jan 25 13:58:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00332 for ; Thu, 25 Jan 2001 15:42:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 25 Jan 2001 15:42:01 +0100 (MET) Received: (qmail 11802 invoked by uid 0); 25 Jan 2001 13:05:53 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx03) with SMTP; 25 Jan 2001 13:05:53 -0000 X-eGroups-Return: sentto-1101623-2100-980427947-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 25 Jan 2001 13:05:57 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 25 Jan 2001 13:05:47 -0000 Received: (qmail 67940 invoked from network); 25 Jan 2001 13:05:46 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 25 Jan 2001 13:05:46 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 25 Jan 2001 13:05:46 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA19480; Thu, 25 Jan 2001 05:04:39 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWGJS; Thu, 25 Jan 2001 13:09:26 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7022ED.A86A9E9E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: Epfprogram@mdronline.com X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 13:58:21 +0100 Reply-To: f-cpu@egroups.com Subject: [f-cpu] early proposal, request for comments Content-Type: multipart/mixed; boundary="------------8E1F216263F63348CDCFA24B" X-UIDL: d5756edd97b72b87e925e244dd59beae Status: R X-Status: N --------------8E1F216263F63348CDCFA24B Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello,

here is a preliminary submission.
Since i was warned this morning,
i have not yet written the abstract body.

Please keep us informed and comment.


YG

speaking for himself
eGroups Sponsor
www. .com
--------------8E1F216263F63348CDCFA24B Content-Type: text/plain; charset=us-ascii; name="cfp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cfp.txt" 1. The name of the chip, product or technology the F-CPU Instruction Set Architecture and the F-CPU Core #0 ("FC0") 2. General features of the chip, product or technology * Fully parameterizable VHDL'93 source code distributed under GPL and F-CPU Charter. * retargetable to a broad range of technologies * SIMD, "undetermined register size" (32, 64, 128, 256 ...) * 64 registers (64-bit wide in the first implementation) * 32-bit instructions with 4 instruction formats only * superpipelined with an average of 6 4-input gates in the critical datapath * In-Order Issue and Out Of Order Completion (1 instruction issued per cycle for the first FC0) * Zero-delay branch instruction (in the ideal case) * Smooth Register Back ("SRB") mechanism lowers context switch time 3. Specific features that will be discussed in detail at Embedded Processor Forum * instruction scheduling * memory interface 4. Whether the chip will be formally announced or disclosed for the first time at Embedded Processor Forum (if not, what prior disclosures or announcements are planned) It is the first public presentation in a congress in the US. The F-CPU team was presented during two conferences in Berlin (17C3 : http://www.ccc.de/congress/fahrplan/event/153.en.html 16C3 : http://www.ccc.de/events/congress99/doku/fcpu.html) but there was only a short technical introduction, while some key details (see 3.) will be discussed. 5. For non-chip announcements, please provide details on the product to be announced, its relevance to the event, and particulars that will help evaluate the presentation Contrarily to the LEON, the F-CPU defines a new instruction set and is designed to last much longer. It is "by design" extensible and scalable in several ways, providing forward and backward compatibility for several decades. The goal is to provide a free alternative for the aging MIPS, SPARC, ALPHA... 6. Other descriptive information about the presentation {not defined yet. maybe a free distribution of CDROMs} 7. Company name It is a community development on the Internet, not a company "product". 8. Speaker's name (should be the chief architect or lead designer of the product) Yann Guidon 9. Speaker's job title Software development Engineer at Mentor Graphics (that's how i earn my life), main F-CPU contributor. 10. Speaker's biography (30 words or less) Joined the F-CPU Design Team on the Internet in Dec. 1999, influenced the design when the F-CPU ISA became RISC and defined the FC0, Mentor Graphics employee since nov. 2000. 11. Speaker's address, phone, fax, email address and administrator (if any) email : whygee@f-cpu.org (personal) and yann_guidon@mentor.com (job) snail mail address : Yann Guidon 13 rue Francois Couperin 93110 Rosny sous bois France phone : +33 1 64 86 62 07 (business) 12. Abstract title proposed title (could change) : Instruction scheduling and the memory interface of the F-CPU Core #0 13. P.R. or Marcom contact (include phone, fax, and email) no marketing. see http://www.f-cpu.org or email me. 14. Your abstract or outline should not exceed 1000 words. --------------8E1F216263F63348CDCFA24B-- From Alan Grimes Fri Jan 26 01:44:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00375 for ; Fri, 26 Jan 2001 22:45:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 Jan 2001 22:45:48 +0100 (MET) Received: (qmail 21844 invoked by uid 0); 26 Jan 2001 01:16:12 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx24) with SMTP; 26 Jan 2001 01:16:12 -0000 X-eGroups-Return: sentto-1101623-2101-980471725-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 26 Jan 2001 01:16:35 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 26 Jan 2001 01:15:24 -0000 Received: (qmail 70021 invoked from network); 26 Jan 2001 00:45:06 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 26 Jan 2001 00:45:06 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 26 Jan 2001 00:45:06 -0000 Received: from 66-44-92-133.s514.tnt7.lnhva.md.dialup.rcn.com ([66.44.92.133] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14LwzP-0002qh-00 ; Thu, 25 Jan 2001 19:43:43 -0500 Message-ID: <3A70C869.A79279D6@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: cores@opencores.org, f-cpu@egroups.com From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 19:44:25 -0500 Reply-To: f-cpu@egroups.com Subject: [f-cpu] FreeProc: The Open CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 39b5b6409588b455877bfc4d6f63fac8 Status: R X-Status: N Hey, I am getting ready to start my own renegade CPU project. But I
can't do it without you! If you want to help build the cornerstone of a
forthcoming Open Platform initiative here's your chance!

You need to set up an account over at sourceforge, then send me your
user name so I can add you to the project... Then vote YES, as described
in the news article, to begin the new project... Ofcourse you could also
join to vote "NO" but if you do that please show me your own solution
for creating a free and open hardware platform. Otherwise I'll just
remove you from the project. =P

The url for the project is:
https://sourceforge.net/projects/freeproc/

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
eGroups Sponsor
Personalize your company´s name. Choose the domain name below and press SEARCH!
www.
Yahoo! Domains
From Ben Franchuk Thu Jan 25 13:19:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00386 for ; Fri, 26 Jan 2001 22:45:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 Jan 2001 22:45:50 +0100 (MET) Received: (qmail 971 invoked by uid 0); 26 Jan 2001 01:55:44 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx24) with SMTP; 26 Jan 2001 01:55:44 -0000 X-eGroups-Return: sentto-1101623-2102-980474146-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 26 Jan 2001 01:56:03 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 26 Jan 2001 01:55:46 -0000 Received: (qmail 69216 invoked from network); 26 Jan 2001 01:32:06 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 26 Jan 2001 01:32:06 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 26 Jan 2001 01:32:04 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA15251 for ; Thu, 25 Jan 2001 18:24:24 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7019E9.392EBC8@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@egroups.com References: <3A70C869.A79279D6@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 05:19:53 -0700 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FreeProc: The Open CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 08ca7aaa950b6b0df5265d5567201448 Status: R X-Status: N Alan Grimes wrote:
>
> Hey, I am getting ready to start my own renegade CPU project. But I
> can't do it without you! If you want to help build the cornerstone of a
> forthcoming Open Platform initiative here's your chance!
>
> You need to set up an account over at sourceforge, then send me your
> user name so I can add you to the project... Then vote YES, as described
> in the news article, to begin the new project... Ofcourse you could also
> join to vote "NO" but if you do that please show me your own solution
> for creating a free and open hardware platform. Otherwise I'll just
> remove you from the project. =P

Is it possible in the interests of FREEDOM and just lurk on BOTH groups.
I don't think a RICS machine is the best for a Free-cpu ( A shameless
plug for a 12 bit cpu) but that is the best design so far.
To all people working on free cpu's lets be careful not shoot our self's
in the the feet by hiding or restricting information.
Ben.
PS.I have a great 16 bit cpu I am working on but it still a tad too small
to make a good FREE-CPU just yet. Take my 12 bit CPU and expand to 16 bits
is the best way to describe it.


--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
From Alan Grimes Fri Jan 26 04:03:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00391 for ; Fri, 26 Jan 2001 22:45:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 Jan 2001 22:45:51 +0100 (MET) Received: (qmail 20926 invoked by uid 0); 26 Jan 2001 03:19:15 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx16) with SMTP; 26 Jan 2001 03:19:15 -0000 X-eGroups-Return: sentto-1101623-2103-980479079-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 26 Jan 2001 03:19:39 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 26 Jan 2001 03:17:59 -0000 Received: (qmail 97567 invoked from network); 26 Jan 2001 03:02:59 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 26 Jan 2001 03:02:59 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 26 Jan 2001 03:02:58 -0000 Received: from 66-44-92-133.s514.tnt7.lnhva.md.dialup.rcn.com ([66.44.92.133] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14LzA8-0001kL-00 for f-cpu@egroups.com; Thu, 25 Jan 2001 22:02:57 -0500 Message-ID: <3A70E90B.4598E9EA@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@egroups.com References: <3A70C869.A79279D6@starpower.net> <3A7019E9.392EBC8@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 22:03:39 -0500 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FreeProc: The Open CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c31428e6967572fc89930124c52a5cc Status: R X-Status: N Ben Franchuk wrote:
> Is it possible in the interests of FREEDOM and just lurk on BOTH
> groups. I don't think a RICS machine is the best for a Free-cpu ( A
> shameless plug for a 12 bit cpu) but that is the best design so far.
> To all people working on free cpu's lets be careful not shoot our
> self's in the the feet by hiding or restricting information.
> Ben.

Hey, that's great. =)

If you want my advice on developing and managing your project I'll be
glad to help as much as I can. =)

If the FreeProc project gets off the ground then I'd be more than happy
to help define interoperability standards on both hardware and software
levels...

My biggest interest in persuing this project is so that I can have a
kludge-free architecture to facilitate my work in compilers. =)

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
eGroups Sponsor

www.
From "Marco Al" Fri Jan 26 04:39:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00398 for ; Fri, 26 Jan 2001 22:45:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 Jan 2001 22:45:53 +0100 (MET) Received: (qmail 14417 invoked by uid 0); 26 Jan 2001 03:47:19 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx15) with SMTP; 26 Jan 2001 03:47:19 -0000 X-eGroups-Return: sentto-1101623-2104-980480741-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 26 Jan 2001 03:47:40 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2); 26 Jan 2001 03:45:38 -0000 Received: (qmail 63035 invoked from network); 26 Jan 2001 03:31:31 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 26 Jan 2001 03:31:31 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 26 Jan 2001 03:31:31 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 57C2F291E for ; Fri, 26 Jan 2001 04:31:30 +0100 (CET) Message-ID: <004e01c08749$a6a72c70$29e65982@student.utwente.nl> To: References: <3A70C869.A79279D6@starpower.net> <3A7019E9.392EBC8@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@egroups.com; contact f-cpu-owner@egroups.com Delivered-To: mailing list f-cpu@egroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 Jan 2001 04:39:56 +0100 Reply-To: f-cpu@egroups.com Subject: Re: [f-cpu] FreeProc: The Open CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5ccfff943a680baf2dbb5733a5b6b297 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> A shameless plug for a 12 bit cpu

That gets my vote :) 12 bit 1 operand stack processor, should be a little easier
on the compiler and not too hard on the hardware compared to a 0 operand one,
put a couple in a VLIW setup with connected ALU's so you can use it for higher
precision too.

Marco
eGroups Sponsor

www. 
From Nicolas Boulay Fri Jan 26 21:01:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00538 for ; Fri, 26 Jan 2001 22:46:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 26 Jan 2001 22:46:30 +0100 (MET) Received: (qmail 2472 invoked by uid 0); 26 Jan 2001 19:51:55 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx22) with SMTP; 26 Jan 2001 19:51:55 -0000 X-eGroups-Return: sentto-1101623-2105-980538743-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 26 Jan 2001 19:52:26 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 26 Jan 2001 19:52:22 -0000 Received: (qmail 82409 invoked from network); 26 Jan 2001 19:52:09 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 26 Jan 2001 19:52:09 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta3 with SMTP; 26 Jan 2001 20:53:14 -0000 Received: from ifrance.com (nas20-241.vlt.club-internet.fr [195.36.170.241]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA20653 for ; Fri, 26 Jan 2001 20:52:06 +0100 (MET) Message-ID: <3A71D780.F3CFC31F@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 Jan 2001 21:01:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f49830ff5e96b8240794dea0b3c29c4a Status: R X-Status: N Hello,

Yann GUIDON a =E9crit :
>
> Hello,
>
> here is a preliminary submission.
> Since i was warned this morning,
> i have not yet written the abstract body.
>
Ok !
> Please keep us informed and comment.
>
> YG
>
> speaking for himself
>
>   ----------------------------------------------------------= --------------
> 1. The name of the chip, product or technology
>
> the F-CPU Instruction Set Architecture and the F-CPU Core #0 ("FC= 0")
>
> 2. General features of the chip, product or technology
>
> * Fully parameterizable VHDL'93 source code distributed under GPL
>   and F-CPU Charter.
> * retargetable to a broad range of technologies
> * SIMD, "undetermined register size" (32, 64, 128, 256 ...)<= BR> > * 64 registers (64-bit wide in the first implementation)
> * 32-bit instructions with 4 instruction formats only
> * superpipelined with an average of 6 4-input gates in the critical da= tapath
RIPE THIS OUT ! How many times i have to say THAT's SOUND TOTALY
RIDICULOUS FOR A MICROELECTRONIC DESIGNER !!!!!!!!
> * In-Order Issue and Out Of Order Completion
>    (1 instruction issued per cycle for the first FC0) Out of order with 1 instruction per cycle...
> * Zero-delay branch instruction (in the ideal case)
So you will not pipeline the decoder, sound strange(ideal case are
usual, it's "a not taken branch", you don't touch the pipeline) > * Smooth Register Back ("SRB") mechanism lowers context swit= ch time
>
OK !
> 3. Specific features that will be discussed in detail at
>    Embedded Processor Forum
>
> * instruction scheduling
> * memory interface
>
> 4. Whether the chip will be formally announced or
>    disclosed for the first time at Embedded Processor >    Forum (if not, what prior disclosures or announcemen= ts
>    are planned)
>
> It is the first public presentation in a congress in the US.
> The F-CPU team was presented during two conferences in Berlin
> (17C3 : http://www.ccc.de/congress/fahrplan/event/153.en.html
>  16C3 : http://www.ccc.de/events/congress99/doku/fcpu.html)
> but there was only a short technical introduction, while
> some key details (see 3.) will be discussed.
>
> 5. For non-chip announcements, please provide details
>    on the product to be announced, its relevance to the=
>    event, and particulars that will help evaluate the >    presentation
>
> Contrarily to the LEON, the F-CPU defines a new instruction
> set and is designed to last much longer. It is "by design" > extensible and scalable in several ways, providing forward
> and backward compatibility for several decades. The goal is
> to provide a free alternative for the aging MIPS, SPARC, ALPHA...
>
> 6. Other descriptive information about the presentation
>
> {not defined yet. maybe a free distribution of CDROMs}
>
> 7. Company name
>
> It is a community development on the Internet, not a company "pro= duct".
>
> 8. Speaker's name (should be the chief architect or lead
>    designer of the product)
>
> Yann Guidon
>
> 9. Speaker's job title
>
> Software development Engineer at Mentor Graphics (that's how i
> earn my life), main F-CPU contributor.
>
> 10. Speaker's biography (30 words or less)
>
> Joined the F-CPU Design Team on the Internet in Dec. 1999,
> influenced the design when the F-CPU ISA became RISC
> and defined the FC0, Mentor Graphics employee since nov. 2000.
>
> 11. Speaker's address, phone, fax, email address and
>     administrator (if any)
>
> email : whygee@f-cpu.org (personal) and yann_guidon@mentor.com (job) > snail mail address :
>  Yann Guidon
>  13 rue Francois Couperin
>  93110 Rosny sous bois
>  France
> phone : +33 1 64 86 62 07 (business)
>
> 12. Abstract title
>
> proposed title (could change) :
> Instruction scheduling and the memory interface of the F-CPU Core #0 >
> 13. P.R. or Marcom contact (include phone, fax, and email)
>
> no marketing. see http://www.f-cpu.or= g or email me.
>
> 14. Your abstract or outline should not exceed 1000 words.
eGroups Sponsor=
=
www.
3D""
From Ben Franchuk Thu Jan 25 22:08:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03248 for ; Sun, 28 Jan 2001 07:51:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:02 +0100 (MET) Received: (qmail 13569 invoked by uid 0); 27 Jan 2001 01:41:34 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 27 Jan 2001 01:41:34 -0000 X-eGroups-Return: sentto-1101623-2106-980559729-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 27 Jan 2001 01:42:12 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 01:42:08 -0000 Received: (qmail 82958 invoked from network); 27 Jan 2001 01:42:07 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Jan 2001 01:42:07 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 27 Jan 2001 01:42:05 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA08825 for ; Fri, 26 Jan 2001 18:34:09 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7095EA.A97EF9DF@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 14:08:58 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ebc2aa477473b0bcd8369f90349a5c2d Status: R X-Status: N http://www.fokus.gmd.de/linux/HOWTO/CPU-Design-HOWTO.html#toc4
This has a lot of GOOD links. I even found a good
explanation of SIMD.Ben.
PS. I don't like SIMD now because it looks like you can't handle
linked lists and other data structures than STUPID fortran style
arrays.Also it looks like it only will work with 'mathematical'
operations. I can't search or sort with multiple threads.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
eGroups Sponsor
www. .com
From Yann Guidon Sat Jan 27 04:28:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03257 for ; Sun, 28 Jan 2001 07:51:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:05 +0100 (MET) Received: (qmail 13595 invoked by uid 0); 27 Jan 2001 03:21:23 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx17) with SMTP; 27 Jan 2001 03:21:23 -0000 X-eGroups-Return: sentto-1101623-2107-980565710-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 27 Jan 2001 03:21:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 03:21:49 -0000 Received: (qmail 44930 invoked from network); 27 Jan 2001 03:21:49 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 27 Jan 2001 03:21:49 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta1 with SMTP; 27 Jan 2001 03:21:48 -0000 Received: from f-cpu.org (nas3-11.ras.club-internet.fr [195.36.203.11]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA09832 for ; Sat, 27 Jan 2001 04:21:46 +0100 (MET) Message-ID: <3A724047.A50FE310@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 04:28:07 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6f3e41200fd495f670a9a55b8f88f475 Status: R X-Status: N hello and thank you for the comments,

Nicolas Boulay wrote:
> Yann GUIDON a =E9crit :
> > here is a preliminary submission.
> > Since i was warned this morning,
> > i have not yet written the abstract body.
> Ok !
it should be ready within a few days.

> >   -----------------------------------------------------= -------------------

> > * superpipelined with an average of 6 4-input gates in the critic= al datapath
> RIPE THIS OUT ! How many times i have to say THAT's SOUND TOTALY
> RIDICULOUS FOR A MICROELECTRONIC DESIGNER !!!!!!!!
ok ok ok .......
i keep "superpipeline", but how do i give an indication of the co= mplexity of the stages ?

> > * In-Order Issue and Out Of Order Completion
> >    (1 instruction issued per cycle for the first F= C0)
> Out of order with 1 instruction per cycle...
mmmm... "out of order" means "out of order issue" (impl= icitly).
i feel that your proposition is misleading.
Any other proposition ?

> > * Zero-delay branch instruction (in the ideal case)
> So you will not pipeline the decoder, sound strange(ideal case are
> usual, it's "a not taken branch", you don't touch the pipeli= ne)
i will pipeline the decoder later. we might exceed the average
complexity of the pipeline but it's too early now, it's like
hitting a moving target...
Otherwise, if/when the decoder will be split, it will give birth
to 2 units : "decode" and "issue". since "issue&qu= ot; controls the
rest of the pipeline, the branches will certainly be 0 latency.

> > * Smooth Register Back ("SRB") mechanism lowers context= switch time
> OK !
does it "sells" ? :-)


For the abstract, i'll try to sum up the presentation that i intend to do.<= BR> it's around 15 or 20 slides, so it's an average of 50 words per slide.

i'll keep you informed.

Oh, btw, to whoever will come to DATE2001 in Munich, i have free passes
(well, it's free anyway, but there's no paper to fill etc.).

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
eGroups Sponsor=
3D""3D""
www. .com=  
3D""
From Ben Franchuk Fri Jan 26 01:56:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03263 for ; Sun, 28 Jan 2001 07:51:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:07 +0100 (MET) Received: (qmail 13610 invoked by uid 0); 27 Jan 2001 05:28:32 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx07) with SMTP; 27 Jan 2001 05:28:32 -0000 X-eGroups-Return: sentto-1101623-2108-980573340-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 27 Jan 2001 05:29:12 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 05:29:00 -0000 Received: (qmail 94595 invoked from network); 27 Jan 2001 05:28:59 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 27 Jan 2001 05:28:59 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 27 Jan 2001 06:30:04 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA20116 for ; Fri, 26 Jan 2001 22:21:32 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A70CB37.485E6DB1@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 25 Jan 2001 17:56:23 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fca5b593fb7467494c992fa743f42e92 Status: R X-Status: N Yann Guidon wrote:
> i keep "superpipeline", but how do i give an indication of the complexity of the stages ?
optimally matched data paths ?

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www. .com
From Yann Guidon Sat Jan 27 11:25:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03275 for ; Sun, 28 Jan 2001 07:51:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:09 +0100 (MET) Received: (qmail 16844 invoked by uid 0); 27 Jan 2001 10:18:19 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx22) with SMTP; 27 Jan 2001 10:18:19 -0000 X-eGroups-Return: sentto-1101623-2109-980590739-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 27 Jan 2001 10:19:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 10:18:58 -0000 Received: (qmail 2601 invoked from network); 27 Jan 2001 10:18:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 27 Jan 2001 10:18:57 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 27 Jan 2001 10:18:57 -0000 Received: from f-cpu.org (nas4-104.ras.club-internet.fr [195.36.203.104]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA24976 for ; Sat, 27 Jan 2001 11:18:54 +0100 (MET) Message-ID: <3A72A20A.92BBB14D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A70CB37.485E6DB1@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 11:25:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 48329770797aa945be4f03249d8e4f9a Status: R X-Status: N hi !

Ben Franchuk wrote:
>
> Yann Guidon wrote:
> > i keep "superpipeline", but how do i give an indication of the complexity of the stages ?
> optimally matched data paths ?

mmmm that's a gooood idea :-)
OTOH i wouldn't say that it is already "optimal" ;-)
"superpipeline with very short matched stages" or something like that...

ok, keep on polishing the words,
i have to go to a studio i rented for 3 hours.
i gotta record and rehearse some music ...
and then i'll write the abstract :-)
@+
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Do you know the name you want? Enter the domain name below and press GO!
www.
Yahoo! Domains
From Nicolas Boulay Sat Jan 27 12:52:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03290 for ; Sun, 28 Jan 2001 07:51:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:14 +0100 (MET) Received: (qmail 19873 invoked by uid 0); 27 Jan 2001 11:46:09 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx16) with SMTP; 27 Jan 2001 11:46:09 -0000 X-eGroups-Return: sentto-1101623-2110-980595844-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 27 Jan 2001 11:44:06 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 11:44:04 -0000 Received: (qmail 91829 invoked from network); 27 Jan 2001 11:44:03 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 27 Jan 2001 11:44:03 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 27 Jan 2001 11:44:02 -0000 Received: from ifrance.com (nas6-156.vlt.club-internet.fr [194.158.108.156]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA00662 for ; Sat, 27 Jan 2001 12:43:58 +0100 (MET) Message-ID: <3A72B67E.5316777C@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 12:52:30 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 36b1381e49d7d5fb7b82d05faa5d5513 Status: R X-Status: N Coucou,

Yann Guidon a =E9crit :
>
> hello and thank you for the comments,
>
> Nicolas Boulay wrote:
> > > * superpipelined with an average of 6 4-input gates in the c= ritical datapath
> > RIPE THIS OUT ! How many times i have to say THAT's SOUND TOTALY<= BR> > > RIDICULOUS FOR A MICROELECTRONIC DESIGNER !!!!!!!!
> ok ok ok .......
> i keep "superpipeline", but how do i give an indication of t= he complexity of the stages ?
>
If you give a number of gate, it doesn't say anything. A number of stage is much more evident for a reader. With 6 gates stage, you will have
around 100 stages !

> > > * In-Order Issue and Out Of Order Completion
> > >    (1 instruction issued per cycle for the fi= rst FC0)
> > Out of order with 1 instruction per cycle...
> mmmm... "out of order" means "out of order issue" = (implicitly).
> i feel that your proposition is misleading.
> Any other proposition ?
>

You could simply say that you have different pipeline depth for each
unit (like C6000 DSP).

> > > * Zero-delay branch instruction (in the ideal case)
> > So you will not pipeline the decoder, sound strange(ideal case ar= e
> > usual, it's "a not taken branch", you don't touch the p= ipeline)
> i will pipeline the decoder later. we might exceed the average
> complexity of the pipeline but it's too early now, it's like
> hitting a moving target...

A=EFe ! In a 5 stages pipelines, you have the fetch, the decode, execute, memory and then register. So decod take 1/5 of the path... If you have
20 stages pipeline but with only a stage for the decod. The speed will
be like the one for a 5 stages pipeline. Stupid, no ?

> Otherwise, if/when the decoder will be split, it will give birth
> to 2 units : "decode" and "issue". since "iss= ue" controls the
> rest of the pipeline, the branches will certainly be 0 latency.
>
2 stages for the decod, why not ? But what you speak is called time
budgeting, it's maid to know where to put the time barrier (the
fliflop). In intel, some designer do only that ! 2 is the begining,
usualaly execute is the alu, so a decod are as big as a 32 bit ALU. So
to be coherent, the decod must be as pipelined as ALU.

> > > * Smooth Register Back ("SRB") mechanism lowers co= ntext switch time
> > OK !
> does it "sells" ? :-
>
> For the abstract, i'll try to sum up the presentation that i intend to= do.
> it's around 15 or 20 slides, so it's an average of 50 words per slide.=
>
> i'll keep you informed.
>
> Oh, btw, to whoever will come to DATE2001 in Munich, i have free passe= s
> (well, it's free anyway, but there's no paper to fill etc.).
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nicO
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www.   
=0D=
3D""
From Nicolas Boulay Sat Jan 27 13:02:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03293 for ; Sun, 28 Jan 2001 07:51:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:16 +0100 (MET) Received: (qmail 2638 invoked by uid 0); 27 Jan 2001 11:52:38 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx24) with SMTP; 27 Jan 2001 11:52:38 -0000 X-eGroups-Return: sentto-1101623-2111-980596396-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fj.egroups.com with NNFMP; 27 Jan 2001 11:53:23 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 11:53:15 -0000 Received: (qmail 3540 invoked from network); 27 Jan 2001 11:53:15 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Jan 2001 11:53:15 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 27 Jan 2001 11:53:14 -0000 Received: from ifrance.com (nas6-156.vlt.club-internet.fr [194.158.108.156]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA18731 for ; Sat, 27 Jan 2001 12:53:11 +0100 (MET) Message-ID: <3A72B8C5.5DA6578D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 13:02:13 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 734b5a5c40c4ccec175506364ea9c938 Status: R X-Status: N There is 10 line about SIMD !
We could add that our SIMD machine have a very small vector 2 or 4
scalar value compare to 1024 or 16000, in super computing. That's how
work MMX, SSE, SSE II,...
Just one question in SSE, there one intersting thing about stream. I
have understand that you could make a prefetch with indication about how the cache must be used (nocache, all cache, only L2 cache).
And if a compiler is too hard to optimise we can always rewrite C/C++
librairy (as Compaq for Alpha).

nicO

Ben Franchuk a =E9crit :
>
> http://www.fokus.gmd.de/linux/HOWTO/CPU-Design-HOWTO.html#toc4
> This has a lot of GOOD links. I even found a good
> explanation of SIMD.Ben.
> PS. I don't like SIMD now because it looks like you can't handle
> linked lists and other data structures than STUPID fortran style
> arrays.Also it looks like it only will work with 'mathematical'
> operations. I can't search or sort with multiple threads.
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www.   
=0D= 3D"" From Yann Guidon Sat Jan 27 22:01:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03365 for ; Sun, 28 Jan 2001 07:51:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:37 +0100 (MET) Received: (qmail 8764 invoked by uid 0); 27 Jan 2001 20:54:27 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx01) with SMTP; 27 Jan 2001 20:54:27 -0000 X-eGroups-Return: sentto-1101623-2112-980628915-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 27 Jan 2001 20:55:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 20:55:12 -0000 Received: (qmail 35709 invoked from network); 27 Jan 2001 20:55:11 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Jan 2001 20:55:11 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 27 Jan 2001 21:56:16 -0000 Received: from f-cpu.org (nas2-233.ras.club-internet.fr [195.36.192.233]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA09987 for ; Sat, 27 Jan 2001 21:55:07 +0100 (MET) Message-ID: <3A73371B.8DDAF215@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 22:01:15 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2cf935503e00b642188621ba48146487 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Coucou,
> Yann Guidon a =E9crit :
> > hello and thank you for the comments,
> > Nicolas Boulay wrote:
> > > > * superpipelined with an average of 6 4-input gates in = the critical datapath
> > > RIPE THIS OUT ! How many times i have to say THAT's SOUND TO= TALY
> > > RIDICULOUS FOR A MICROELECTRONIC DESIGNER !!!!!!!!
> > ok ok ok .......
> > i keep "superpipeline", but how do i give an indication= of the complexity of the stages ?
> If you give a number of gate, it doesn't say anything. A number of sta= ge
> is much more evident for a reader. With 6 gates stage, you will have > around 100 stages !
??? it is not related...
now the question is (again) : what do i write ?
i have a temporary version :
"* superpipelined (very short matched pipeline stages)"

> > > > * In-Order Issue and Out Of Order Completion
> > > >    (1 instruction issued per cycle for t= he first FC0)
> > > Out of order with 1 instruction per cycle...
> > mmmm... "out of order" means "out of order issue&q= uot; (implicitly).
> > i feel that your proposition is misleading.
> > Any other proposition ?
> You could simply say that you have different pipeline depth for each > unit (like C6000 DSP).
i have found that :
"* Issues 1 instruction per cycle In-Order and completes Out Of Order&= quot;
=E7a va ?

> > > > * Zero-delay branch instruction (in the ideal case)
> > > So you will not pipeline the decoder, sound strange(ideal ca= se are
> > > usual, it's "a not taken branch", you don't touch = the pipeline)
> > i will pipeline the decoder later. we might exceed the average > > complexity of the pipeline but it's too early now, it's like
> > hitting a moving target...
> A=EFe ! In a 5 stages pipelines, you have the fetch, the decode, execu= te,
> memory and then register.
that's the old MIPS way. most of all : memory doesn't work like that on the= FC0
(but you knew it)

> So decod take 1/5 of the path... If you have
> 20 stages pipeline but with only a stage for the decod. The speed will=
> be like the one for a 5 stages pipeline. Stupid, no ?
i don't understand your point ...
what is it about ?
and what is the relationship with the branch ?

> > Otherwise, if/when the decoder will be split, it will give birth<= BR> > > to 2 units : "decode" and "issue". since &quo= t;issue" controls the
> > rest of the pipeline, the branches will certainly be 0 latency. > 2 stages for the decod, why not ?
time :-) let's make it work first, then we'll see where we can split it.
> But what you speak is called time
> budgeting, it's maid to know where to put the time barrier (the
> fliflop). In intel, some designer do only that !
poor, poor Intel engineers :-)

> 2 is the begining,
> usualaly execute is the alu, so a decod are as big as a 32 bit ALU. So=
> to be coherent, the decod must be as pipelined as ALU.
not necessarily. and we have no "ALU" :-) just a certain number o= f
execution units that communicate through what is called the Xbar (even that=
may be a simple bus...).


OK this sounds interesting but i have had no time at all this week-end
for the F-CPU. i'll try to write the abstract before the deadline, though := -)


> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www. =
=0D 3D"" From Nicolas Boulay Sun Jan 28 00:52:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03375 for ; Sun, 28 Jan 2001 07:51:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:41 +0100 (MET) Received: (qmail 10188 invoked by uid 0); 27 Jan 2001 23:48:16 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx07) with SMTP; 27 Jan 2001 23:48:16 -0000 X-eGroups-Return: sentto-1101623-2113-980639006-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 27 Jan 2001 23:43:44 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 27 Jan 2001 23:43:26 -0000 Received: (qmail 656 invoked from network); 27 Jan 2001 23:43:25 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Jan 2001 23:43:25 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 28 Jan 2001 00:44:29 -0000 Received: from ifrance.com (nas22-41.vlt.club-internet.fr [195.36.172.41]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA20834 for ; Sun, 28 Jan 2001 00:43:22 +0100 (MET) Message-ID: <3A735F3B.21640BBA@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> <3A73371B.8DDAF215@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 00:52:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f3d9be80b05dee6dccac68072ad1a81a Status: R X-Status: N Hello,

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > Coucou,
> > Yann Guidon a =E9crit :
> > > hello and thank you for the comments,
> > > Nicolas Boulay wrote:
> > > > > * superpipelined with an average of 6 4-input gate= s in the critical datapath
> > > > RIPE THIS OUT ! How many times i have to say THAT's SOU= ND TOTALY
> > > > RIDICULOUS FOR A MICROELECTRONIC DESIGNER !!!!!!!!
> > > ok ok ok .......
> > > i keep "superpipeline", but how do i give an indic= ation of the complexity of the stages ?
> > If you give a number of gate, it doesn't say anything. A number o= f stage
> > is much more evident for a reader. With 6 gates stage, you will h= ave
> > around 100 stages !
> ??? it is not related...
??? Not related ?

For me, the number of gates, it's for the critical path wich give the
worst case for the timing of the stage. For a fixed number of gate, you
could no more decide the number of stage.

> now the question is (again) : what do i write ?
> i have a temporary version :
> "* superpipelined (very short matched pipeline stages)"

Yes, that's what it is suppose to be.

>
> > > > > * In-Order Issue and Out Of Order Completion
> > > > >    (1 instruction issued per cycle = for the first FC0)
> > > > Out of order with 1 instruction per cycle...
> > > mmmm... "out of order" means "out of order is= sue" (implicitly).
> > > i feel that your proposition is misleading.
> > > Any other proposition ?
> > You could simply say that you have different pipeline depth for e= ach
> > unit (like C6000 DSP).
> i have found that :
> "* Issues 1 instruction per cycle In-Order and completes Out Of O= rder"
> =E7a va ?
>
Ouaip ! I should understand how C6000 work.
> > > > > * Zero-delay branch instruction (in the ideal case= )
> > > > So you will not pipeline the decoder, sound strange(ide= al case are
> > > > usual, it's "a not taken branch", you don't t= ouch the pipeline)
> > > i will pipeline the decoder later. we might exceed the avera= ge
> > > complexity of the pipeline but it's too early now, it's like=
> > > hitting a moving target...
> > A=EFe ! In a 5 stages pipelines, you have the fetch, the decode, = execute,
> > memory and then register.
> that's the old MIPS way. most of all : memory doesn't work like that o= n the FC0
> (but you knew it)
>

That's just an exemple to have a relative size of the decoder.

> > So decod take 1/5 of the path... If you have
> > 20 stages pipeline but with only a stage for the decod. The speed= will
> > be like the one for a 5 stages pipeline. Stupid, no ?
> i don't understand your point ...
> what is it about ?

4 stages of pipeline for the add is absolutely useless, if the decoder
use only 1 stage (that's not coherent at all).

> and what is the relationship with the branch ?
Without !
>
> > > Otherwise, if/when the decoder will be split, it will give b= irth
> > > to 2 units : "decode" and "issue". since= "issue" controls the
> > > rest of the pipeline, the branches will certainly be 0 laten= cy.
> > 2 stages for the decod, why not ?
> time :-) let's make it work first, then we'll see where we can split i= t.
>

I repeat myself, if the time need to cross the decoder is 4 times the
one for each stage of the add unit, you will decrease the clock speed to match with the size of the decod unit. And you're superpipeline unit are useless.

> > But what you speak is called time
> > budgeting, it's maid to know where to put the time barrier (the > > fliflop). In intel, some designer do only that !
> poor, poor Intel engineers :-)
>
;p
> > 2 is the begining,
> > usualaly execute is the alu, so a decod are as big as a 32 bit AL= U. So
> > to be coherent, the decod must be as pipelined as ALU.
> not necessarily. and we have no "ALU" :-) just a certain num= ber of
> execution units that communicate through what is called the Xbar (even= that
> may be a simple bus...).
>
> OK this sounds interesting but i have had no time at all this week-end=
> for the F-CPU. i'll try to write the abstract before the deadline, tho= ugh :-)
>
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
nicO
Yahoo! Groups Spons= or
3D""
3D""
From David Sullins Sun Jan 28 06:51:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03384 for ; Sun, 28 Jan 2001 07:51:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 07:51:44 +0100 (MET) Received: (qmail 15037 invoked by uid 0); 28 Jan 2001 05:57:00 -0000 Received: from ch.egroups.com (208.50.99.226) by 10.1.4.111 (mx11) with SMTP; 28 Jan 2001 05:57:00 -0000 X-eGroups-Return: sentto-1101623-2114-980661469-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 28 Jan 2001 05:57:50 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 28 Jan 2001 05:57:48 -0000 Received: (qmail 17086 invoked from network); 28 Jan 2001 05:57:48 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 28 Jan 2001 05:57:48 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta2 with SMTP; 28 Jan 2001 05:57:47 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id XAA13557; Sat, 27 Jan 2001 23:57:47 -0600 Received: from eceultra19 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id XAA12073; Sat, 27 Jan 2001 23:57:46 -0600 (CST) Received: from localhost by eceultra19 (8.8.8+Sun/ECESolaris-Client) id FAA23972; Sun, 28 Jan 2001 05:51:49 GMT To: f-cpu@yahoogroups.com Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 23:51:49 -0600 (CST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 176f2865562f1fc91d3a44901d3e4fe5 Status: R X-Status: N I can find no source that definitively explains what each execution unit
looks like externally.  Part 3 of the manual shows several useful
diagrams, but it lacks a diagram showing the actual bits entering/exiting
an execution unit.  A simple VHDL entity declaration for each EU would be
helpful.

A specific "black box" diagram of each EU is needed to resolve some
inconsistencies in the manual.  Example:

I decided to start by trying to understand the ROP2 unit, since that is a
very simple unit.  Section 3.3.1 of the F-CPU manual (revision 0.2)
describes the implementation of the ROP2 unit.  The first unnumbered table
of that section shows all 16 possible functions of the unit.  The next
paragraph explains that some of these functions will not be used, and the
four bits representing the function will NOT be in the opcode.  It
specifies that the functions used will be 1, 2, 6, 7, 8, 9, C, D, E, and F
(10 instructions).  There is also a description of the combine AND and
combine OR functions.

Section 6.3.1 describes the "logic" instruction of the FC0 machine
language.  This time, the function IS encoded into the opcode, making all
functions 0 through F available (16 instructions).  No mention of combine
AND or combine OR is included.

Finally, Yann's implementation of the ROP2 unit (rop2.vhdl) has only the
unique instructions with two operands which are 1, 2, 6, 7, 8, 9, D, and E
(8 instructions).  Combine AND and combine OR are implemented.

This gives three conflicting version of the same execution unit.  I have a
feeling that the design of this processor is well thought-out in someone's
head, but it's not in the manual.  So if someone who knows what these EUs
actually do could take some time to explain it, then it would make it
easier for yutzes like myself to contribute.

Thanks,
Dave
Yahoo! Groups Sponsor
www. .com 
From Yann Guidon Sun Jan 28 16:34:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04904 for ; Sun, 28 Jan 2001 20:58:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 20:58:34 +0100 (MET) Received: (qmail 31944 invoked by uid 0); 28 Jan 2001 16:13:04 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx01) with SMTP; 28 Jan 2001 16:13:04 -0000 X-eGroups-Return: sentto-1101623-2116-980695702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 28 Jan 2001 15:28:25 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 28 Jan 2001 15:28:21 -0000 Received: (qmail 2252 invoked from network); 28 Jan 2001 15:28:20 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 28 Jan 2001 15:28:20 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 28 Jan 2001 15:28:19 -0000 Received: from f-cpu.org (nas2-250.ras.club-internet.fr [195.36.192.250]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA18435 for ; Sun, 28 Jan 2001 16:28:15 +0100 (MET) Message-ID: <3A743C07.176BDE3@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> <3A73371B.8DDAF215@f-cpu.org> <3A735F3B.21640BBA@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 16:34:31 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2138d8a27ade555ab3cbb8a95699e562 Status: R X-Status: N hi !

Nicolas Boulay wrote:
> Hello,
> Yann Guidon a =E9crit :
> > hi,
> > Nicolas Boulay wrote:
> > > Coucou,
> > > Yann Guidon a =E9crit :
> > > > hello and thank you for the comments,
> > > > Nicolas Boulay wrote:
<snip>

> > > If you give a number of gate, it doesn't say anything. A num= ber of stage
> > > is much more evident for a reader. With 6 gates stage, you w= ill have
> > > around 100 stages !
> > ??? it is not related...
> ??? Not related ?
>
> For me, the number of gates, it's for the critical path wich give the<= BR> > worst case for the timing of the stage. For a fixed number of gate, yo= u
> could no more decide the number of stage.

this number of stages depends on
- the granularity of the pipeline (the CDP)
- the complexity of the microarchitecture
but you know that some units are simpler than others.

> > now the question is (again) : what do i write ?
> > i have a temporary version :
> > "* superpipelined (very short matched pipeline stages)"=
> Yes, that's what it is suppose to be.
ok, if it suits everybody, i keep it and i'll start to
write the abstract :-)

> > > > Any other proposition ?
> > > You could simply say that you have different pipeline depth = for each
> > > unit (like C6000 DSP).
> > i have found that :
> > "* Issues 1 instruction per cycle In-Order and completes Out= Of Order"
> > =E7a va ?
> Ouaip ! I should understand how C6000 work.
don't they give the manual for free on their websites ?
i have it on CDROMs (dating back to the introduction of the family, around = 1996)
I simply hope that they enhanced their compiler ! ;-P

> > > > > > * Zero-delay branch instruction (in the ideal= case)
> > > > > So you will not pipeline the decoder, sound strang= e(ideal case are
> > > > > usual, it's "a not taken branch", you do= n't touch the pipeline)
> > > > i will pipeline the decoder later. we might exceed the = average
> > > > complexity of the pipeline but it's too early now, it's= like
> > > > hitting a moving target...
> > > A=EFe ! In a 5 stages pipelines, you have the fetch, the dec= ode, execute,
> > > memory and then register.
> > that's the old MIPS way. most of all : memory doesn't work like t= hat on the FC0
> > (but you knew it)
> That's just an exemple to have a relative size of the decoder.
what is this point anyway ?
you compare things and purposes that are not related, and therefore need no "coherency" (at that level at least).

it's like : "well your rop2 is 1 stage and the ASU is 2 stages, you ha= ve to
pipeline ROP2".

1) The decoder is not yet completely determined. it's not a good practice to apply top-bottom approach on something that lacks specification.
particularly, the complexity of the decoder  depends A LOT on the
used technology.

2) The decoder has a different purpose than that of the execution units. its latency and depth don't have the same impact on the performance.

if i take your argument, one CPU would need 15 pipeline stages
to decode an instruction that divides a 64-bit integer number.

> > > So decod take 1/5 of the path... If you have
> > > 20 stages pipeline but with only a stage for the decod. The = speed will
> > > be like the one for a 5 stages pipeline. Stupid, no ?
> > i don't understand your point ...
> > what is it about ?
>
> 4 stages of pipeline for the add is absolutely useless, if the decoder=
> use only 1 stage (that's not coherent at all).
you compare apples and chairs...
you eat apples, but you need a chair to sit.
you don't need N chairs for M apples.
it's not correllated.

> > > > Otherwise, if/when the decoder will be split, it will g= ive birth
> > > > to 2 units : "decode" and "issue". = since "issue" controls the
> > > > rest of the pipeline, the branches will certainly be 0 = latency.
> > > 2 stages for the decod, why not ?
> > time :-) let's make it work first, then we'll see where we can sp= lit it.
> I repeat myself, if the time need to cross the decoder is 4 times the<= BR> > one for each stage of the add unit, you will decrease the clock speed = to
> match with the size of the decod unit. And you're superpipeline unit a= re
> useless.

1) i don't expect such a slowdown, at least at this level.
if i expected something like that, i would have done it long ago ;-)

2) the decoder (the part that "decodes" the instruction into expl= icit bits)
is not very complex. maybe 4 gates and hardware tables, all in parallel, doing explicit speculative decoding on all the possible opcodes.

3) the "selection" or "issue" (the real control part) t= akes approximately
the same latency. so if the work is done "nicely" we could fit th= at in
around 8 gates. This is not much of a budget overflow, compared to the
"custom" gates that Micahel uses in the multiplier.

4) we can still modify the design later. splitting the decoder is
nothing compared to the major redesign caused by a change of pipeline granu= larity
of all the CPU.


it's a shame, but i think that i did almost nothing for the project this we= ek.
i feel almost guilty, and this doesn't help much.

i had a todo list, and i'm behind all schedule. the new top priorities : 1) write abstract EPF (deadline : tuesday)
2) radio program on tuesday
3) prepare DATE 2001

my birthday is on feb. 24th : if you love me, buy me a linux laptop ;-P

i'll post the abstract ASAP.

> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""3D""
www. .com=  
3D""
From Yann Guidon Sun Jan 28 16:34:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04910 for ; Sun, 28 Jan 2001 20:58:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 28 Jan 2001 20:58:36 +0100 (MET) Received: (qmail 14427 invoked by uid 0); 28 Jan 2001 16:22:46 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.112 (mx12) with SMTP; 28 Jan 2001 16:22:46 -0000 X-eGroups-Return: sentto-1101623-2115-980695702-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 28 Jan 2001 15:29:00 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 28 Jan 2001 15:28:21 -0000 Received: (qmail 23915 invoked from network); 28 Jan 2001 15:28:20 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 28 Jan 2001 15:28:20 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 28 Jan 2001 15:28:19 -0000 Received: from f-cpu.org (nas2-250.ras.club-internet.fr [195.36.192.250]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA11718 for ; Sun, 28 Jan 2001 16:28:15 +0100 (MET) Message-ID: <3A743C08.C043173C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 16:34:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 503e479b671905afc9e56cdee1f4e9d5 Status: R X-Status: N hello,

David Sullins wrote:
> I can find no source that definitively explains what each execution unit
> looks like externally.  Part 3 of the manual shows several useful
> diagrams, but it lacks a diagram showing the actual bits entering/exiting
> an execution unit.  A simple VHDL entity declaration for each EU would be
> helpful.

<snip>

> This gives three conflicting version of the same execution unit.  I have a
> feeling that the design of this processor is well thought-out in someone's
> head, but it's not in the manual.  So if someone who knows what these EUs
> actually do could take some time to explain it, then it would make it
> easier for yutzes like myself to contribute.

you're right, the manual is "under rework". it was not touched during
almost a year and now, some updated parts are not coherent with the old
parts. Since the time when Olicier disclosed his LaTeX version of the manual
(november IIRC), i have updated the parts 1 to 4 and you can find them on
the seul.org site. However, you understand that the 6th part is the most difficult,
so it will require a lot of work. It was even incomplete in v0.2.

Today, the ROP2 unit is in a satisfactory state (even though it is still never
perfect) when it comes to the VHDL implementation. The other units (SHL, INC)
are more difficult. For the ASU and IMU, Michael's implementation will remain
until a better formal description appears.

It is not because we have a manual that everything is perfect : that's why it's
still rev. 0.2 and not 1.2 :-)


> Thanks,
> Dave
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
From Nicolas Boulay Sun Jan 28 20:14:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA00347 for ; Mon, 29 Jan 2001 08:50:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 08:50:14 +0100 (MET) Received: (qmail 9947 invoked by uid 0); 28 Jan 2001 22:59:37 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx18) with SMTP; 28 Jan 2001 22:59:37 -0000 X-eGroups-Return: sentto-1101623-2117-980708764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 28 Jan 2001 19:07:13 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 28 Jan 2001 19:06:02 -0000 Received: (qmail 34723 invoked from network); 28 Jan 2001 19:05:51 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 28 Jan 2001 19:05:51 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta1 with SMTP; 28 Jan 2001 19:05:51 -0000 Received: from ifrance.com (nas20-171.vlt.club-internet.fr [195.36.170.171]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA05307 for ; Sun, 28 Jan 2001 20:05:47 +0100 (MET) Message-ID: <3A746F97.5796334@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> <3A73371B.8DDAF215@f-cpu.org> <3A735F3B.21640BBA@ifrance.com> <3A743C07.176BDE3@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 20:14:31 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 435719ab9f6fd40f65296bc5fbd837e4 Status: R X-Status: N hi

Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas Boulay wrote:
> > Hello,
> > Yann Guidon a =E9crit :
> > > hi,
> > > Nicolas Boulay wrote:
> > > > Coucou,
> > > > Yann Guidon a =E9crit :
> > > > > hello and thank you for the comments,
> > > > > Nicolas Boulay wrote:
> <snip>
>
> > > > If you give a number of gate, it doesn't say anything. = A number of stage
> > > > is much more evident for a reader. With 6 gates stage, = you will have
> > > > around 100 stages !
> > > ??? it is not related...
> > ??? Not related ?
> >
> > For me, the number of gates, it's for the critical path wich give= the
> > worst case for the timing of the stage. For a fixed number of gat= e, you
> > could no more decide the number of stage.
>
> this number of stages depends on
> - the granularity of the pipeline (the CDP)
> - the complexity of the microarchitecture
> but you know that some units are simpler than others.
>
And when you have defined your microarch, you could put how many stage
you want, which fix the clock speed(and add few depencies;).
i think you have some problem to visualise what is precisely a pipeline.
> > > now the question is (again) : what do i write ?
> > > i have a temporary version :
> > > "* superpipelined (very short matched pipeline stages)&= quot;
> > Yes, that's what it is suppose to be.
> ok, if it suits everybody, i keep it and i'll start to
> write the abstract :-)
>
> > > > > Any other proposition ?
> > > > You could simply say that you have different pipeline d= epth for each
> > > > unit (like C6000 DSP).
> > > i have found that :
> > > "* Issues 1 instruction per cycle In-Order and complete= s Out Of Order"
> > > =E7a va ?
> > Ouaip ! I should understand how C6000 work.
> don't they give the manual for free on their websites ?
> i have it on CDROMs (dating back to the introduction of the family, ar= ound 1996)
> I simply hope that they enhanced their compiler ! ;-P
>
> > > > > > > * Zero-delay branch instruction (in the = ideal case)
> > > > > > So you will not pipeline the decoder, sound s= trange(ideal case are
> > > > > > usual, it's "a not taken branch", y= ou don't touch the pipeline)
> > > > > i will pipeline the decoder later. we might exceed= the average
> > > > > complexity of the pipeline but it's too early now,= it's like
> > > > > hitting a moving target...
> > > > A=EFe ! In a 5 stages pipelines, you have the fetch, th= e decode, execute,
> > > > memory and then register.
> > > that's the old MIPS way. most of all : memory doesn't work l= ike that on the FC0
> > > (but you knew it)
> > That's just an exemple to have a relative size of the decoder. > what is this point anyway ?
> you compare things and purposes that are not related, and therefore ne= ed
> no "coherency" (at that level at least).
>
> it's like : "well your rop2 is 1 stage and the ASU is 2 stages, y= ou have to
> pipeline ROP2".
>
> 1) The decoder is not yet completely determined. it's not a good pract= ice
> to apply top-bottom approach on something that lacks specification. > particularly, the complexity of the decoder  depends A LOT on the=
> used technology.
>
> 2) The decoder has a different purpose than that of the execution unit= s.
> its latency and depth don't have the same impact on the performance. >
> if i take your argument, one CPU would need 15 pipeline stages
> to decode an instruction that divides a 64-bit integer number.
>
If you want a single cycle divide unit. You have 3 stages on the divide
unit and 1 for the decoder. If you want double the number of stage, the
divide unit take 6 stages and the decoder 2.

You have different pipelened depth unit. But each stage must have the
same longuest path.

> > > > So decod take 1/5 of the path... If you have
> > > > 20 stages pipeline but with only a stage for the decod.= The speed will
> > > > be like the one for a 5 stages pipeline. Stupid, no ? > > > i don't understand your point ...
> > > what is it about ?
> >
> > 4 stages of pipeline for the add is absolutely useless, if the de= coder
> > use only 1 stage (that's not coherent at all).
> you compare apples and chairs...
> you eat apples, but you need a chair to sit.
> you don't need N chairs for M apples.
> it's not correllated.

It's totally correllated  !! For a given architecture !

>
> > > > > Otherwise, if/when the decoder will be split, it w= ill give birth
> > > > > to 2 units : "decode" and "issue&qu= ot;. since "issue" controls the
> > > > > rest of the pipeline, the branches will certainly = be 0 latency.
> > > > 2 stages for the decod, why not ?
> > > time :-) let's make it work first, then we'll see where we c= an split it.
> > I repeat myself, if the time need to cross the decoder is 4 times= the
> > one for each stage of the add unit, you will decrease the clock s= peed to
> > match with the size of the decod unit. And you're superpipeline u= nit are
> > useless.
>
> 1) i don't expect such a slowdown, at least at this level.
> if i expected something like that, i would have done it long ago ;-) >
> 2) the decoder (the part that "decodes" the instruction into= explicit bits)
> is not very complex. maybe 4 gates and hardware tables, all in paralle= l,
> doing explicit speculative decoding on all the possible opcodes.
>
> 3) the "selection" or "issue" (the real control pa= rt) takes approximately
> the same latency. so if the work is done "nicely" we could f= it that in
> around 8 gates. This is not much of a budget overflow, compared to the=
> "custom" gates that Micahel uses in the multiplier.
>
> 4) we can still modify the design later. splitting the decoder is
> nothing compared to the major redesign caused by a change of pipeline = granularity
> of all the CPU.
>
> it's a shame, but i think that i did almost nothing for the project th= is week.
> i feel almost guilty, and this doesn't help much.
>
> i had a todo list, and i'm behind all schedule. the new top priorities= :
> 1) write abstract EPF (deadline : tuesday)
> 2) radio program on tuesday
> 3) prepare DATE 2001
>
> my birthday is on feb. 24th : if you love me, buy me a linux laptop ;-= P
>
> i'll post the abstract ASAP.
>
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.   
=0D
=
3D""
From Ben Franchuk Sat Jan 27 03:59:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA00359 for ; Mon, 29 Jan 2001 08:50:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 08:50:18 +0100 (MET) Received: (qmail 1490 invoked by uid 0); 28 Jan 2001 23:37:55 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx22) with SMTP; 28 Jan 2001 23:37:55 -0000 X-eGroups-Return: sentto-1101623-2118-980723647-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 28 Jan 2001 23:14:18 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 28 Jan 2001 23:14:06 -0000 Received: (qmail 83278 invoked from network); 28 Jan 2001 23:14:05 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 28 Jan 2001 23:14:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 29 Jan 2001 00:15:10 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA06904 for ; Sun, 28 Jan 2001 16:06:27 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7239AD.880A5E@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> <3A73371B.8DDAF215@f-cpu.org> <3A735F3B.21640BBA@ifrance.com> <3A743C07.176BDE3@f-cpu.org> <3A746F97.5796334@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 26 Jan 2001 19:59:58 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 554169abc7157054d47825492a480889 Status: R X-Status: N > > my birthday is on feb. 24th : if you love me, buy me a linux laptop ;-P
I will look around but laptops running the F-CPU are still very RARE. :-)
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www. .com 
From Yann Guidon Mon Jan 29 03:11:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA00368 for ; Mon, 29 Jan 2001 08:50:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 08:50:21 +0100 (MET) Received: (qmail 30938 invoked by uid 0); 29 Jan 2001 02:04:04 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx08) with SMTP; 29 Jan 2001 02:04:04 -0000 X-eGroups-Return: sentto-1101623-2120-980733894-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 29 Jan 2001 02:05:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 02:04:53 -0000 Received: (qmail 54617 invoked from network); 29 Jan 2001 02:04:50 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 29 Jan 2001 02:04:50 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta2 with SMTP; 29 Jan 2001 02:04:49 -0000 Received: from f-cpu.org (nas2-199.ras.club-internet.fr [195.36.192.199]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA25837 for ; Mon, 29 Jan 2001 03:04:46 +0100 (MET) Message-ID: <3A74D13B.BCB9CD52@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7022ED.A86A9E9E@mentor.com> <3A71D780.F3CFC31F@ifrance.com> <3A724047.A50FE310@f-cpu.org> <3A72B67E.5316777C@ifrance.com> <3A73371B.8DDAF215@f-cpu.org> <3A735F3B.21640BBA@ifrance.com> <3A743C07.176BDE3@f-cpu.org> <3A746F97.5796334@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 03:11:07 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] early proposal, request for comments Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8e5d00370840ed94fdaa72b46698e6bd Status: R X-Status: N bon, je m'aper=E7ois que le d=E9bat se r=E9duit et que
les grandes lignes sont trac=E9es, reste plus qu'=E0 pinailler :-)

Nicolas Boulay wrote:
> hi
idem

> Yann Guidon a =E9crit :
> > Nicolas Boulay wrote:
> > > Yann Guidon a =E9crit :
> > > > Nicolas Boulay wrote:
> > > > > Yann Guidon a =E9crit :
> > > > > > Nicolas Boulay wrote:
> > <snip>

> > > For me, the number of gates, it's for the critical path wich= give the
> > > worst case for the timing of the stage. For a fixed number o= f gate, you
> > > could no more decide the number of stage.
> >
> > this number of stages depends on
> > - the granularity of the pipeline (the CDP)
> > - the complexity of the microarchitecture
> > but you know that some units are simpler than others.
> >
> And when you have defined your microarch, you could put how many stage=
> you want, which fix the clock speed(and add few depencies;).
> i think you have some problem to visualise what is precisely a pipelin= e.




> > 1) The decoder is not yet completely determined. it's not a good = practice
> > to apply top-bottom approach on something that lacks specificatio= n.
> > particularly, the complexity of the decoder  depends A LOT o= n the
> > used technology.
> >
> > 2) The decoder has a different purpose than that of the execution= units.
> > its latency and depth don't have the same impact on the performan= ce.
> >
> > if i take your argument, one CPU would need 15 pipeline stages > > to decode an instruction that divides a 64-bit integer number. > >
> If you want a single cycle divide unit. You have 3 stages on the divid= e
> unit and 1 for the decoder. If you want double the number of stage, th= e
> divide unit take 6 stages and the decoder 2.
>
> You have different pipelened depth unit. But each stage must have the<= BR> > same longuest path.

sure. but as of today you know that nothing exists firmly. so it's too earl= y
to overpipeline it. We have to make it work first, and even when it works,<= BR> the thing will blow away everything else. If you're still unsatisfied, you'= ll
split the decoder.

in one word : "ok but later".
well, three. never mind.

> > > > > So decod take 1/5 of the path... If you have
> > > > > 20 stages pipeline but with only a stage for the d= ecod. The speed will
> > > > > be like the one for a 5 stages pipeline. Stupid, n= o ?
> > > > i don't understand your point ...
> > > > what is it about ?
> > >
> > > 4 stages of pipeline for the add is absolutely useless, if t= he decoder
> > > use only 1 stage (that's not coherent at all).
> > you compare apples and chairs...
> > you eat apples, but you need a chair to sit.
> > you don't need N chairs for M apples.
> > it's not correllated.
>
> It's totally correllated  !! For a given architecture !

the decoder's size is related to the instruction set's complexity
(which is not an issue for the FC0) and it is the same whether
it decodes a ROP2 instruction or a divide instruction.

The execution unit's size and length is related to the operation
that must be performed. It is 1 cycle for ROP2 or tens of cycles for
a divide. it is NOT related to the instruction format.

that's why i say that it is not corellated.

> > > > > > WHYGEE
> > > > > nicO
> > > > WHYGEE
> > > nicO
> > WHYGEE
WHYGEE
Yahoo! Groups Spons= or
=0D= =0D=0D=0D=0D=0D= =0D=0D=0D=0D=0D=0D=0D
=0D
= =0DGrab the opportunity to mark= et your company. Choose the domain name below and press GO!=0D
=0D=0D=0D=0D=0D=0D
=0Dwww.=0D=0D=0D
=0D		= =0D3D"Yahoo!
3D""
From Yann Guidon Mon Jan 29 02:35:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA00371 for ; Mon, 29 Jan 2001 08:50:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 08:50:22 +0100 (MET) Received: (qmail 23047 invoked by uid 0); 29 Jan 2001 02:40:07 -0000 Received: from fk.egroups.com (64.211.240.232) by 10.1.4.119 (mx19) with SMTP; 29 Jan 2001 02:40:07 -0000 X-eGroups-Return: sentto-1101623-2119-980731738-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 29 Jan 2001 01:29:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 01:28:57 -0000 Received: (qmail 73299 invoked from network); 29 Jan 2001 01:28:49 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 29 Jan 2001 01:28:49 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 29 Jan 2001 02:29:53 -0000 Received: from f-cpu.org (nas3-122.aub.club-internet.fr [195.36.145.122]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA20350 for ; Mon, 29 Jan 2001 02:28:46 +0100 (MET) Message-ID: <3A74C8CC.8D141A8C@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 02:35:08 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ae5efca0d6e24fd94064ab53b7461ee Status: R X-Status: N hi !

Ben Franchuk wrote:
> http://www.fokus.gmd.de/linux/HOWTO/CPU-Design-HOWTO.html#toc4
> This has a lot of GOOD links. I even found a good
> explanation of SIMD.Ben.
> PS. I don't like SIMD now because it looks like you can't handle
> linked lists and other data structures than STUPID fortran style
> arrays.Also it looks like it only will work with 'mathematical'
> operations. I can't search or sort with multiple threads.

Now that i think about it, your limitation is related to how pointers
work. i am trying to find a way to perform 'scatter-gather' instructions,
they'll help perform what you expect, and even more.

Unfortunately, scatter-gather is very difficult to implement in the FC0.
we can reserve some opcodes but the exact behaviour and implementation
are still unsolved questions. There are several means but nothing is coherent
with the basic design philosophy of the FC0.

For those who don't know what "scatter-gather" mean, its the same as
"store-load" but with each chunck of a SIMD word representing a pointer.
so a "scatter" will perform a "multi-store" and a gather will do "multi-load"
with one large register. Now, memory protection and pipeline scheduling
are big issues. The access must be serialized because every pointer must
be checked in the TLB (having 4 TLB containing the same values is an overkill).
One solution is to use "fence" registers because there's not much overhead
and it can be easily parallelized. we can split the address
into a "base" and an "offset" (but not a segmented memory) so only
one register will be checked in the TLB (the base pointer) and the
offset will be the SIMD word. Unfortunately, this method doesn't allow
us to do pointer post-modification.

the debate is open !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.
From Rares Marian Mon Jan 29 09:26:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA01402 for ; Mon, 29 Jan 2001 16:10:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 16:10:49 +0100 (MET) Received: (qmail 15870 invoked by uid 0); 29 Jan 2001 08:20:35 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx13) with SMTP; 29 Jan 2001 08:20:35 -0000 X-eGroups-Return: sentto-1101623-2121-980756486-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 29 Jan 2001 08:21:30 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 08:21:26 -0000 Received: (qmail 39869 invoked from network); 29 Jan 2001 08:21:25 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 29 Jan 2001 08:21:25 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 29 Jan 2001 08:21:25 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 6737245262; Mon, 29 Jan 2001 03:26:24 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010129032623.A13081@moonbase.res.wpi.net> References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> In-Reply-To: <3A74C8CC.8D141A8C@f-cpu.org>; from whygee@f-cpu.org on Sun, Jan 28, 2001 at 20:35:08 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 03:26:23 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f795830350cf6a7ccd0bd54c55788e21 Status: R X-Status: N
On Sun, 28 Jan 2001 20:35:08 Yann Guidon wrote:
> hi !
> Now that i think about it, your limitation is related to how pointers
> work. i am trying to find a way to perform 'scatter-gather' instructions,
> they'll help perform what you expect, and even more.
>
> Unfortunately, scatter-gather is very difficult to implement in the FC0.
> we can reserve some opcodes but the exact behaviour and implementation
> are still unsolved questions. There are several means but nothing is
> coherent
> with the basic design philosophy of the FC0.

Okay, I may have been quiet lately (school, biz), but I definitely want to
be
in on this discussion.

> For those who don't know what "scatter-gather" mean, its the same as
> "store-load" but with each chunck of a SIMD word representing a pointer.
> so a "scatter" will perform a "multi-store" and a gather will do
> "multi-load"
> with one large register. Now, memory protection and pipeline scheduling
> are big issues. The access must be serialized because every pointer must
> be checked in the TLB (having 4 TLB containing the same values is an
> overkill).
> One solution is to use "fence" registers because there's not much
> overhead
> and it can be easily parallelized. we can split the address
> into a "base" and an "offset" (but not a segmented memory) so only
> one register will be checked in the TLB (the base pointer) and the
> offset will be the SIMD word. Unfortunately, this method doesn't allow
> us to do pointer post-modification.
>
> the debate is open !

I'm in.

> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>

Rares
Yahoo! Groups Sponsor

www.   
From "C. M. Herkert" Tue Jan 30 13:14:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00351 for ; Mon, 29 Jan 2001 20:51:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 29 Jan 2001 20:51:18 +0100 (MET) Received: (qmail 5773 invoked by uid 0); 29 Jan 2001 18:25:04 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx17) with SMTP; 29 Jan 2001 18:25:04 -0000 X-eGroups-Return: sentto-1101623-2122-980792768-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 29 Jan 2001 18:26:09 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 18:26:07 -0000 Received: (qmail 1966 invoked from network); 29 Jan 2001 18:14:28 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 29 Jan 2001 18:14:28 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta1 with SMTP; 29 Jan 2001 18:14:27 -0000 Received: from default (p0132-ip04osakakita.osaka.ocn.ne.jp [211.123.240.132]) by violin.ocn.ne.jp (8.9.1a/OCN/) with SMTP id DAA05603 for ; Tue, 30 Jan 2001 03:14:25 +0900 (JST) Message-ID: <000b01c08ab6$2e692ea0$84f07bd3@default> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "C. M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 03:14:19 -0900 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] F-an Mail Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C08A6A.BC5000A0" X-UIDL: e97b0878bc4c9d4a6d35917bfe1bcd5f Status: R X-Status: N ------=_NextPart_000_0007_01C08A6A.BC5000A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Congrats, how's the project coming. Would like to get on the mailing list and get some more info on everything. Any news on production/availability. Please kep me posted. put@violin.ocn.ne.jp ------=_NextPart_000_0007_01C08A6A.BC5000A0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Congrats, how's the project coming. Would like to get on the mailing list and get some more info on everything. Any news on production/availability. Please kep me posted.
 

Yahoo! Groups Sponsor
www. .com
------=_NextPart_000_0007_01C08A6A.BC5000A0-- From Michael Riepe Mon Jan 29 13:39:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00395 for ; Tue, 30 Jan 2001 07:47:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 07:47:45 +0100 (MET) Received: (qmail 15475 invoked by uid 0); 29 Jan 2001 22:35:23 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 29 Jan 2001 22:35:23 -0000 X-eGroups-Return: sentto-1101623-2123-980807796-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 29 Jan 2001 22:36:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 22:36:35 -0000 Received: (qmail 98339 invoked from network); 29 Jan 2001 22:18:53 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 29 Jan 2001 22:18:53 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.43) by mta2 with SMTP; 29 Jan 2001 22:18:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00478; Mon, 29 Jan 2001 13:39:59 +0100 Message-ID: <20010129133959.07750@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A74C8CC.8D141A8C@f-cpu.org>; from Yann Guidon on Mon, Jan 29, 2001 at 02:35:08AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 13:39:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b7a9a89cc86eda4527b6d2894768449c Status: R X-Status: N On Mon, Jan 29, 2001 at 02:35:08AM +0100, Yann Guidon wrote:
[...]
> For those who don't know what "scatter-gather" mean, its the same as
> "store-load" but with each chunck of a SIMD word representing a pointer.
> so a "scatter" will perform a "multi-store" and a gather will do "multi-load"
> with one large register. Now, memory protection and pipeline scheduling
> are big issues. The access must be serialized because every pointer must
> be checked in the TLB (having 4 TLB containing the same values is an overkill).
> One solution is to use "fence" registers because there's not much overhead
> and it can be easily parallelized. we can split the address
> into a "base" and an "offset" (but not a segmented memory) so only
> one register will be checked in the TLB (the base pointer) and the
> offset will be the SIMD word. Unfortunately, this method doesn't allow
> us to do pointer post-modification.
>
> the debate is open !

Just one point: why can't the TLB have multiple read ports?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From "Guillaume Lederrey" Mon Jan 29 23:53:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00398 for ; Tue, 30 Jan 2001 07:47:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 07:47:46 +0100 (MET) Received: (qmail 32225 invoked by uid 0); 29 Jan 2001 23:17:46 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx24) with SMTP; 29 Jan 2001 23:17:46 -0000 X-eGroups-Return: sentto-1101623-2124-980810275-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 29 Jan 2001 23:18:03 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 23:17:49 -0000 Received: (qmail 51881 invoked from network); 29 Jan 2001 22:53:44 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 29 Jan 2001 22:53:44 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.154) by mta3 with SMTP; 29 Jan 2001 23:54:47 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f0TMrWL01167 for ; Mon, 29 Jan 2001 23:53:34 +0100 Message-Id: <200101292253.f0TMrWL01167@PrintServer.LedCom> To: "f-cpu design team" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 23:53:40 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 87510c25f4fe1d7ac62215cffe598e49 Status: R X-Status: N   I'm trying to reread the french translation of the manual.
But i do have some problem understanding which english version
is the last one.  I'm thinking that a CVS account at sourceforge
would be quite helpfull.

  So, here are a couple of questions :

  - What do you think about the idea ?
  - Should I open one ?
  - Under which name ?
  - Who should be the administrators ?

  Let me know ...

            Guillaume
Yahoo! Groups Sponsor

www.   
From "Marco Al" Tue Jan 30 00:16:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00404 for ; Tue, 30 Jan 2001 07:47:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 07:47:48 +0100 (MET) Received: (qmail 20664 invoked by uid 0); 29 Jan 2001 23:31:41 -0000 Received: from ml.egroups.com (208.50.144.77) by 10.1.4.119 (mx19) with SMTP; 29 Jan 2001 23:31:41 -0000 X-eGroups-Return: sentto-1101623-2125-980811172-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 29 Jan 2001 23:33:01 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 29 Jan 2001 23:32:50 -0000 Received: (qmail 84107 invoked from network); 29 Jan 2001 23:07:31 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 29 Jan 2001 23:07:31 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 29 Jan 2001 23:07:31 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 289772866 for ; Tue, 30 Jan 2001 00:07:30 +0100 (CET) Message-ID: <000901c08a49$73434cd0$29e65982@student.utwente.nl> To: References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 00:16:03 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b7b823c6bc29cd6c497ba435b7389ee8 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> the debate is open !

Why not scatter-gather from registers to registers only?

Marco
Yahoo! Groups Sponsor

www.   
From "philippe.trbich" Tue Jan 30 06:52:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA00419 for ; Tue, 30 Jan 2001 07:47:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 07:47:52 +0100 (MET) Received: (qmail 19193 invoked by uid 0); 30 Jan 2001 05:51:16 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx16) with SMTP; 30 Jan 2001 05:51:16 -0000 X-eGroups-Return: sentto-1101623-2126-980833951-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 30 Jan 2001 05:52:38 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 05:52:30 -0000 Received: (qmail 21114 invoked from network); 30 Jan 2001 05:52:29 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 30 Jan 2001 05:52:29 -0000 Received: from unknown (HELO postfix1-2.free.fr) (213.228.0.130) by mta3 with SMTP; 30 Jan 2001 06:53:34 -0000 Received: from free.fr (unknown [213.228.7.31]) by postfix1-2.free.fr (Postfix) with ESMTP id 0608D102864 for ; Tue, 30 Jan 2001 06:52:24 +0100 (CET) Sender: root@free.fr Message-ID: <3A765693.E55577AB@free.fr> X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200101292253.f0TMrWL01167@PrintServer.LedCom> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 06:52:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1fd0e38d991c312e786308ef4bcbb187 Status: R X-Status: N Guillaume Lederrey wrote:
>
>   I'm trying to reread the french translation of the manual.
> But i do have some problem understanding which english version
> is the last one.  I'm thinking that a CVS account at sourceforge
> would be quite helpfull.
>
>   So, here are a couple of questions :
>
>   - What do you think about the idea ?
>   - Should I open one ?
>   - Under which name ?
>   - Who should be the administrators ?
we are working with whygee to make a directory for the french
translation on http://www.f-cpu.seul.org
A+
>
>   Let me know ...
>
>                 Guillaume
>

Yahoo! Groups Sponsor
www. .com 
From Yann GUIDON Tue Jan 30 10:22:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00449 for ; Tue, 30 Jan 2001 20:46:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:04 +0100 (MET) Received: (qmail 24916 invoked by uid 0); 30 Jan 2001 09:27:48 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx13) with SMTP; 30 Jan 2001 09:27:48 -0000 X-eGroups-Return: sentto-1101623-2127-980846943-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 30 Jan 2001 09:29:08 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 09:29:01 -0000 Received: (qmail 17843 invoked from network); 30 Jan 2001 09:29:00 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 30 Jan 2001 09:29:00 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 30 Jan 2001 09:29:00 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA13971; Tue, 30 Jan 2001 01:28:55 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWJ5V; Tue, 30 Jan 2001 09:33:45 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7687D8.95036886@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200101292253.f0TMrWL01167@PrintServer.LedCom> <3A765693.E55577AB@free.fr> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 10:22:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 04506ba251a0ea1bd4ae9394164a5326 Status: R X-Status: N "philippe.trbich" wrote:
> Guillaume Lederrey wrote:
> >   I'm trying to reread the french translation of the manual.
> > But i do have some problem understanding which english version
> > is the last one.  I'm thinking that a CVS account at sourceforge
> > would be quite helpfull.
> >   So, here are a couple of questions :
> >   - What do you think about the idea ?
yes, CVS is becoming ... critical :-)
> >   - Should I open one ?
> >   - Under which name ?
> >   - Who should be the administrators ?
i think that CVS at seul.org would be better
because wwe know more people at seul. the admins at seul
are open and ready to help, and their workload is lower
than on sourceforge, meaning that they would solve problems
faster if one appears.

> we are working with whygee to make a directory for the french
> translation on http://www.f-cpu.seul.org
> A+
BTW, Philippe, what do you decide ? do you create an account
for the manual ?

> >   Let me know ...
> >                 Guillaume

CVS at seul is interesting but we need somebody who watches over it.
I don't remember who proposed/volunteered but it was not followed by acts.
If someone else wants to manage the CVS tree, don't hesitate !

YG

speaking for himself
Yahoo! Groups Sponsor
www. .com
From zipogae68@carnation.hu Sat Mar 7 17:39:44 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00452 for ; Tue, 30 Jan 2001 20:46:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:06 +0100 (MET) Received: (qmail 5762 invoked by uid 0); 30 Jan 2001 10:11:28 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx05) with SMTP; 30 Jan 2001 10:11:28 -0000 X-eGroups-Return: sentto-1101623-2128-980847789-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 30 Jan 2001 09:43:11 -0000 X-Sender: zipogae68@carnation.hu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 09:43:08 -0000 Received: (qmail 67141 invoked from network); 30 Jan 2001 09:43:08 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 30 Jan 2001 09:43:08 -0000 Received: from unknown (HELO kit2.bdtf.hu) (193.224.74.216) by mta2 with SMTP; 30 Jan 2001 09:43:07 -0000 Received: from 5th76v5 (d57.as1.mdtw.oh.voyager.net [207.90.109.185]) by kit2.bdtf.hu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id C5A5VTBX; Tue, 30 Jan 2001 10:41:35 +0100 To: zipogae68@carnation.hu Comments: Authenticated sender is Message-Id: <200101301099JAA29063@asdcfvgb6h.bdtf.hu> X-eGroups-From: zipogae68@carnation.hu (JEFF) From: zipogae68@carnation.hu MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Call 24 hours a day Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 30 Jan 01 10:11:28 GMT X-UIDL: c52306715c6f5c68aef0134e7b93b2a9 Status: R X-Status: N UNIVERSITY DIPLOMAS

Obtain a prosperous future, money earning power,
and the admiration of all.

Diplomas from prestigious non-accredited
universities based on your present knowledge
and life experience.

No required tests, classes, books, or interviews.

Bachelors, masters, MBA, and doctorate (PhD)
diplomas available in the field of your choice.

No one is turned down.

Confidentiality assured.

CALL NOW to receive your diploma
within days!!!

1-212-465-3248

Call 24 hours a day, 7 days a week, including
Sundays and holidays.









=================================
rem -- pt_2003@mail.com
=================================

820808127360278221956
uQFrom: zipogae68@carnation.hu (JEFF)
Comments: Authenticated sender is <zipog
Yahoo! Groups Sponsor

www.

From Yann GUIDON Tue Jan 30 10:39:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00458 for ; Tue, 30 Jan 2001 20:46:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:08 +0100 (MET) Received: (qmail 12193 invoked by uid 0); 30 Jan 2001 09:44:57 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx01) with SMTP; 30 Jan 2001 09:44:57 -0000 X-eGroups-Return: sentto-1101623-2129-980847982-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 30 Jan 2001 09:46:24 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 09:46:22 -0000 Received: (qmail 24353 invoked from network); 30 Jan 2001 09:46:22 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 30 Jan 2001 09:46:22 -0000 Received: from unknown (HELO ns1.mentorg.com) (192.94.38.65) by mta3 with SMTP; 30 Jan 2001 10:47:27 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by ns1.mentorg.com (8.8.8/CF5.40F) id BAA01071; Tue, 30 Jan 2001 01:46:16 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWJ65; Tue, 30 Jan 2001 09:50:17 -0000 Sender: yanng@ns1.mentorg.com Message-ID: <3A768BB8.BDAAB0@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> <20010129133959.07750@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 10:39:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5dedce92ae20a9648516aa12f36b79da Status: R X-Status: N Michael Riepe wrote:
> Just one point: why can't the TLB have multiple read ports?

at the layout level, it doubles the surface : it's as if you had
two identical TLB.

i don't know yet for the details of the scatter-gather
because the FC0 was not meant to do it. maybe with FC1 or FC2 ?

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

YG

speaking for himself
Yahoo! Groups Sponsor

www.

From Yann GUIDON Tue Jan 30 10:43:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00461 for ; Tue, 30 Jan 2001 20:46:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:09 +0100 (MET) Received: (qmail 338 invoked by uid 0); 30 Jan 2001 09:49:38 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx21) with SMTP; 30 Jan 2001 09:49:38 -0000 X-eGroups-Return: sentto-1101623-2130-980848168-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 30 Jan 2001 09:49:31 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 09:49:27 -0000 Received: (qmail 29506 invoked from network); 30 Jan 2001 09:49:27 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 30 Jan 2001 09:49:27 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 30 Jan 2001 09:49:26 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA15072; Tue, 30 Jan 2001 01:49:23 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWJ7C; Tue, 30 Jan 2001 09:54:15 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A768CA6.82CD1917@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> <000901c08a49$73434cd0$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 10:43:02 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aabbd76ed0f11fa77e66d29b9f5bc5ce Status: R X-Status: N Marco Al wrote:
>
> From: "Yann Guidon" <whygee@f-cpu.org>
>
> > the debate is open !
>
> Why not scatter-gather from registers to registers only?
>
> Marco

?

what does that mean ? i don't see ...


YG

speaking for himself
Yahoo! Groups Sponsor
From "Guillaume Lederrey" Tue Jan 30 11:37:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00464 for ; Tue, 30 Jan 2001 20:46:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:10 +0100 (MET) Received: (qmail 21783 invoked by uid 0); 30 Jan 2001 10:37:21 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx14) with SMTP; 30 Jan 2001 10:37:21 -0000 X-eGroups-Return: sentto-1101623-2131-980851065-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 30 Jan 2001 10:38:52 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 10:37:44 -0000 Received: (qmail 57717 invoked from network); 30 Jan 2001 10:37:44 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 30 Jan 2001 10:37:44 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.72) by mta1 with SMTP; 30 Jan 2001 10:37:42 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f0UAbcH01175 for ; Tue, 30 Jan 2001 11:37:39 +0100 Message-Id: <200101301037.f0UAbcH01175@PrintServer.LedCom> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <3A7687D8.95036886@mentor.com> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 11:37:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: df4f4b53b1a4c7b6bc02ea5e50d27262 Status: R X-Status: N >i think that CVS at seul.org would be better
>because wwe know more people at seul. the admins at seul
>are open and ready to help, and their workload is lower
>than on sourceforge, meaning that they would solve problems
>faster if one appears.

  You are probably right.  I just dont know seul.org at all.
Though sourceforge seems very profesionnal.  I'm opening an
account there and I'm going to test that anyway.  One of the
good point of being at sourceforge is the visibility of the
f-cpu.  There is probably more people browsing sourceforge that
people browsing seul.org.  And sourceforge has a "job
advertisement" feature where you can ask poeple to help for your
project.

>CVS at seul is interesting but we need somebody who watches over it. >I don't remember who proposed/volunteered but it was not followed by ac= ts.
>If someone else wants to manage the CVS tree, don't hesitate !

  Anywhere it is (sourceforge or seul.org), I'm ready to try to
do it.  I'm not a CVS guru at all, but I should be able to do
it.  Just give me the name of the person to contact.

      Amiti=E9s

            Guillaume
=0D
Yahoo! Groups Spons= or
=0D =0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D
3D""3D""
=0D=0D
www.=0D =0D.com =0D
=0D
=0D
3D""
From Yann GUIDON Tue Jan 30 13:42:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00482 for ; Tue, 30 Jan 2001 20:46:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:15 +0100 (MET) Received: (qmail 19307 invoked by uid 0); 30 Jan 2001 12:49:01 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx16) with SMTP; 30 Jan 2001 12:49:01 -0000 X-eGroups-Return: sentto-1101623-2132-980858932-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 30 Jan 2001 12:48:54 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 12:48:51 -0000 Received: (qmail 92511 invoked from network); 30 Jan 2001 12:48:51 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 30 Jan 2001 12:48:51 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 30 Jan 2001 13:49:55 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA00136; Tue, 30 Jan 2001 04:48:48 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWK17; Tue, 30 Jan 2001 12:53:40 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A76B6B2.88756D66@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200101301037.f0UAbcH01175@PrintServer.LedCom> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 13:42:26 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 080ed27ae645021ba494cc1dc795e381 Status: R X-Status: N hi !

Guillaume Lederrey wrote:
> >i think that CVS at seul.org would be better
> >because wwe know more people at seul. the admins at seul
> >are open and ready to help, and their workload is lower
> >than on sourceforge, meaning that they would solve problems
> >faster if one appears.
>
>   You are probably right.  I just dont know seul.org at= all.
> Though sourceforge seems very profesionnal.
just as egroups did. now, you see that it is bought by yahoo...
no risk of this kind with seul :-)

>  I'm opening an
> account there and I'm going to test that anyway.
yup.

>  One of the good point of being at sourceforge is the visibility = of the
> f-cpu.  There is probably more people browsing sourceforge that > people browsing seul.org.
certainly. but these are not the same people.

>  And sourceforge has a "job advertisement" feature wher= e you can
> ask poeple to help for your project.
is it necessarily for a sourceforge project ?
Anyway, nothing keeps us from using sourceforge as a second "backup&qu= ot; repository.
But the experience with egroups tells me not to trust 100% a private compan= y.

> >CVS at seul is interesting but we need somebody who watches over i= t.
> >I don't remember who proposed/volunteered but it was not followed = by acts.
> >If someone else wants to manage the CVS tree, don't hesitate !
>   Anywhere it is (sourceforge or seul.org), I'm ready to try= to
> do it.  I'm not a CVS guru at all, but I should be able to do
> it.  Just give me the name of the person to contact.
His name is Roger Dingledine but i don't have his address at work.
I think that the managers can be reached at seul@seul.org.
Ask them to open an account for you in the F-CPU project,
give your email address and your wanted login name.

>         Amiti=E9s
>
>            = ;     Guillaume

YG

speaking for himself
Yahoo! Groups Spons= or
=0D =0D=0D=0D=0D=0D=0D<= /table>=0D
3D""3D""
=0D=0D=0D=0D=0D=0D=0D=0D
www.=0D =0D.com =0D
=0D
3D""
From Yann GUIDON Tue Jan 30 14:53:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00491 for ; Tue, 30 Jan 2001 20:46:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:19 +0100 (MET) Received: (qmail 12157 invoked by uid 0); 30 Jan 2001 14:02:35 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx08) with SMTP; 30 Jan 2001 14:02:35 -0000 X-eGroups-Return: sentto-1101623-2133-980863274-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 30 Jan 2001 14:02:33 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 14:01:12 -0000 Received: (qmail 88309 invoked from network); 30 Jan 2001 14:00:45 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 30 Jan 2001 14:00:45 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 30 Jan 2001 15:01:49 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA07324; Tue, 30 Jan 2001 05:59:34 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWKLC; Tue, 30 Jan 2001 14:04:26 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A76C749.7F001803@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: Epfprogram@mdronline.com X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 14:53:13 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Submission update Content-Type: multipart/mixed; boundary="------------5F941EBBB54481DC4C459053" X-UIDL: 70d43f20142c3e98e8aef0d7a3bb16e0 Status: R X-Status: N --------------5F941EBBB54481DC4C459053 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello,

I have changed some details for the submission to EPF.
No "abstract" is ready yet but the slides for the presentation
are prepared. Both files are enclosed in this mail.
However, the abstract and the presentation text are preliminary.
The abstract will be derived from the presentation text and the
slides will be written in HTML. Some illustrations are not yet ready.
Please

regards,

YG

speaking for himself
Yahoo! Groups Sponsor
www. .com
--------------5F941EBBB54481DC4C459053 Content-Type: text/plain; charset=us-ascii; name="cfp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cfp.txt" 1. The name of the chip, product or technology the F-CPU Instruction Set Architecture and the F-CPU Core #0 ("FC0") 2. General features of the chip, product or technology * Fully parameterizable VHDL'93 source code distributed under GPL and F-CPU Charter. * retargetable to a broad range of technologies * SIMD, "undetermined register size" (32, 64, 128, 256 ...) * 64 registers (64-bit wide in the first implementation) * 32-bit instructions with 4 instruction formats only * superpipelined (very short matched pipeline stages) * 1 instruction per cycle issued In-Order and Out Of Order Completion (for the FC0) * Execution pipeline freed from exceptions (no rollback possible) * Zero-delay branch instruction (in the ideal case) * Smooth Register Back ("SRB") mechanism lowers context switch time 3. Specific features that will be discussed in detail at Embedded Processor Forum * instruction scheduling * memory interface 4. Whether the chip will be formally announced or disclosed for the first time at Embedded Processor Forum (if not, what prior disclosures or announcements are planned) It is the first public presentation in a congress in the US. The F-CPU team was presented during two conferences in Berlin (17C3 : http://www.ccc.de/congress/fahrplan/event/153.en.html 16C3 : http://www.ccc.de/events/congress99/doku/fcpu.html) but there was only a short technical introduction, while some key details (see 3.) will be discussed. 5. For non-chip announcements, please provide details on the product to be announced, its relevance to the event, and particulars that will help evaluate the presentation Today, the F-CPU is the only configurable SIMD 64-bit general-purpose RISC core aimed at high performance applications (multimedia or scientific computations). It is a very recent design (1999) originally meant to provide a free, ununcumbered alternative to the Merced. Contrarily to the LEON, the F-CPU defines a new instruction set and is designed to last much longer. It is "by design" extensible and scalable in several ways, providing forward and backward compatibility for several decades. The first core (FC0) could be used as replacement for the aging MIPS, SPARC, ALPHA... Contrarily to the ARC Cores and similar "configurable cores" offers, the F-CPU is not a "black box" but a completely transparent design that allows complete visibility to the engineer. The F-CPU is based around a clean ISA and some simple scheduling rules, leaving a lot of freedom to the implementor. 6. Other descriptive information about the presentation {not defined yet. maybe a free distribution of CDROMs} 7. Company name It is a community development on the Internet, not a company "product". 8. Speaker's name (should be the chief architect or lead designer of the product) Yann Guidon 9. Speaker's job title Software development Engineer at Mentor Graphics (that's how i earn my life), main F-CPU contributor. 10. Speaker's biography (30 words or less) Joined the F-CPU Design Team on the Internet in Dec. 1998, influenced the design when the F-CPU ISA became RISC and defined the FC0 in mid-1999, Mentor Graphics employee since nov. 2000. 11. Speaker's address, phone, fax, email address and administrator (if any) email : whygee@f-cpu.org (personal) and yann_guidon@mentor.com (job) snail mail address : Yann Guidon 13 rue Francois Couperin 93110 Rosny sous bois France phone : +33 1 64 86 62 07 (business) 12. Abstract title proposed title : Instruction scheduling and the memory interface of the F-CPU Core #0 13. P.R. or Marcom contact (include phone, fax, and email) no marketing. see http://www.f-cpu.org or email me. 14. Your abstract or outline should not exceed 1000 words. --------------5F941EBBB54481DC4C459053 Content-Type: text/plain; charset=us-ascii; name="epf_slides.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="epf_slides.txt" Slide 1 Title --------------- "Instruction scheduling and the memory interface of the F-CPU Core #0" * This is a technical (not marketing) overview of some major characteristics of the F-CPU design philosophy and the implementation in the FC0. * It presents the backgrounds and design choices of an ongoing (unfinished) work. * Not all the details are presented here ! RTFM @ http://www.f-cpu.seul.org/manual Slide 2 Short introduction to the F-CPU ---------------------------------------- F-CPU Project goals (voted 1999) : " To develop and make freely available an architecture, and all other intellectual property necessary to fabricate one or more implementations of that architecture, with the following priorities, in decreasing order of importance: 1) Versatility and usefulness in as wide a range of applications as possible 2) Performance, emphasizing user-level parallelism and derived through intelligent architecture rather than advanced silicon process 3) Architecture lifespan and forward compatibility 4) Cost, including monetary and thermal considerations " In the end, the goal is not to make the fastest ever CPU, because it's an endless race. The purpose of this project is more to design the "coolest/sexiest" CPU possible. Slide 3 Short introduction to the F-CPU (2) -------------------------------------------- Some features of the F-CPU Instruction Set Architecture : * 32-bit instructions with 4 instruction formats only [illustration of the formats] * Instruction set census : ~110 reserved opcodes as of today, with several variations, "core" and "optional" features. * 64 registers (64-bit wide in the first implementation) with R0=0 * SIMD flag in most instructions allows parallel operation on registers with "undetermined" width (32, 64, 128, 256 bits ...) * Support for saturated arithmetics, IEEE Floating point, IEEE LNS and fractional integers * 2r1w, 3r1w and 2r2w instructions * memory : 3 "stream hint bits" + cachability bit * One addressing mode only for code and data : register (post-increment possible for data) example of some instructions : Opcode Example Explicitly - add add r1,r2,r3 r3=r1+r2 - load load r1,r2,r3 r3=[r2], r2+=r1 - jump if r1=0 jump r2 link r3 if cond, r3=PC, PC=r2 Slide 4 Starting point of the FC0 : Clock speed issue ------------------------------------------------------ Technology handicap ---> "carpaccio" CPU * faster clock -> shorter Critical Datapath -> 6 4-input gates in the CDP or approximatively 10 transistors between two pipeline flip-flops. (I know, Nicolas, it's an heresy but you know the arguments... And this rough design rule maps so easily in FPGAs :-D) * stage is deep enough to perform a 8-bit add/sub or a 64-bit increment. * CDP determined from the start : - no "hidden CDP" that slows the clock down in the middle of the project - very simple and easy design of the units - emphasis on short stage pipelining for every part of the project favours "matched" and balanced pipeline stage design. Slide 5 Variable latency ------------------------- Every Execution Unit of the F-CPU is dedicated to a certain kind of operation : * ROP2 : bit-to-bit boolean operations : 1 cycle * SHL : bit/byte shuffling, 1 or 2 cycles * ASU : SIMD integer addition and substraction with carry and saturation : 2 cycles in the general case, 1-cycle for 8-bit operations * IMU : SIMD integer multiply and MAC : 6 cycles (MR design) * IDU, LSU, POPC, INC ... EUs are "LEGO bricks" with a particular and deterministic latency. They are all SIMD-capable and are duplicated when the register width increases. Slide 6 Connexion of the EUs around the Xbar --------------------------------------------- [drawing] Slide 7 General layout of the FC0 ---------------------------------- [drawing] Slide 8 Scheduling of one instruction -------------------------------------- [drawing] Fetcher : 1 cycle {bypass possible} decoder : 1 cycles (more if stall) Xbar read : 1 cycle (unless bypass possible) EU : 1+ cycle (latency depends on the unit) Xbar : 1 cycle Register write : 1 cycle Slide 9 Scheduling of one instruction (2) ------------------------------------------ hazard detection with a scoreboard [drawing] * every register is associated to a "not ready bit" * the bit is set when the instruction is issued * the bit is reset when the scheduler commands a write to the register. * The decode pipeline is stalled if all the necessary bits for the current instruction are not cleared. Slide 10 Scheduling of one instruction (3) ------------------------------------------ allocation of the Xbar slots with a FIFO [drawing] * the opcode and the flags are the inputs of a hardwired lookup table. The output indicates how many slots are required (1 or 2 write buses ?) and how many cycles are required for the completion of the operation. * When the operation is issued (if no hazard on the scoreboard and the FIFO is detected), the selected slot is filled the number of the register that must be written to. * When the FIFO shifts down, the number reaches the bottom and commands the control wires of the Xbar and the Register Set. * The depth of the FIFO is 8 cycles. It corresponds to the highest latency of the execution units (IMU: 6 cycles) plus the 2 X bar cycles. * An additional down-counter extends the FIFO for the long and high-latency divide unit (not pipelined version). When the counter is elapsed, the behaviour is normal for the rest of the FIFO (the register number is injected on the top of the FIFO). * Load instructions require special handling when the data is not present in the LSU's buffer. Slide 11 Memory protection --------------------------- All the pointers are available from the Xbar and checked by a TLB that translates the task's logical address into a physical address. [drawing] * TLB entries are SW-replaced through Special Registers. * 4 page sizes : 4KB, 32KB, 256KB and 2MB, plus probably a set of "fence registers" for larger pages. * TLB entries contain cachability informations, access rights (R/W/RW/X), access counter and subdomain usage counters, VMID tag ... Slide 12 Connexion of the address bus -------------------------------------- [drawing] * If there is a TLB miss, the pointer register is marked as invalid and a future use of this register as pointer will trigger a trap at the decode stage. * The address output by the TLB is compared to the address tags of the Fetcher, the L/SU, the internal Icache and Dcache. * If there is a cache or buffer hit - the register is marked as valid - the data is brought to the LSU or the Fetcher (depending on the access type) if the data is not available in the required buffer. Slide 13 LSU/Fetcher/Decoder coupling to detect faulty pointers ---------------------------------------------------------------- The R2 field of the instruction is compared to a set of 8*2 6-bit comparators. [drawing] * Each 256-bit line of the Fetcher and the LSU is tagged with an address and the number of the associated register. * The association of a line and a register is determined with two rules : - LRU - double-buffering (to avoid thrashing when scanning a large linear region of memory) with a pair of line * When the register number is compared to all the entries, a signal is sent to the decoder, saying whether the data is available or not. - if the data is present AND the instruction is a load/store or jump (plus all the other scheduling, scoreboarding etc. rules), the instruction is issued and can complete in 2 cycles. - if the data is not present in any buffer AND it is a load/store or jump, a "prefetch" instruction is simulated in the decoder. * the pointer's value is present on the Xbar because it is accessed in parallel with the decode * the pointer is checked in the TLB and the result goes the usual way. Slide 14 Pipelining of a load instruction ------------------------------------------ Due to the relatively high latency of the load and store instruction, some particular coding techniques must be used to benefit from the FC0's performance. * loop unrolling and interleaving (2x or 3x depending on the size of the loop, the available registers...) * explicit and agressive prefetch. Example : usual code : asm code : loadimm @item1, r4 ; prefetch load [r4],r0 ; prefetch (2) load [item1],r1 loadi item2-item1,[r4], r1 load [item2],r2 loadi item3-item2,[r4], r2 load [item3],r3 loadi item4-item3,[r4], r3 * pointer duplication : a pointer with post-increment takes approx. 6 cycles to complete, other pointers must be used and interleaved if the same memory block must be accessed within this 6-cycle period. * Of course, a memory access without prefetch will work but at the cost of a substantial stall (it is necessary because a task switch will flush the "register tags" in the LSU and the Fetcher) * Similar rules apply for the jump/call/return instructions but the constraints are looser (no pointer update usually). Slide 15 Code example : vector loop ------------------------------------ These are exemples of the typical code that runs best on the F-CPU : 1) Vector style --------------- Pseudocode : #define N 1024 char A[N], B[N], S[N] loop (N) S[i]=A[i]+B[i] ; LOOP PREPARATION : ; r4 = base address of A ; r6 = base address of B ; r8 = base address of S load.s1 r4,r0 ; prefetch load.s2 r6,r0 ; prefetch load.s3 r8,r0 ; prefetch get SR_MAX_SIZE,r1 ; r1 is loaded with 8, 16, 32... ; depending on the chip version (number of bytes per register) get SR_LOG_MAX_SIZE,r2 ; ie r2 = 3 if MAX_SIZE=8 (64-bit) loadimm N/2,r3 ; N/2 because we unroll the loop twice add r1,r4,r5 ; r5 = r4+max_size (pointer duplication) add r1,r6,r7 ; idem add r1,r8,r9 ; idem shl 1,r1,r1 ; r1 = r1*2 shr r2,r3,r3 ; r3 = final loop count loopentry r2 ; r2 = PC+4 ; LOOP KERNEL : loadf.s1 r1,r4,r10 loadf.s1 r1,r5,r12 loadf.s2 r1,r6,r11 loadf.s2 r1,r7,r13 sadd.8 r10,r11,r11 ; SIMD add on 8-bit chuncks sadd.8 r12,r13,r13 ; stall storef.s3 r1,r8,r11 storef.s3 r1,r9,r13 loop r2,r3 ; decrement r3 // jump to r1 if r3 is not zero {remaining of the loop here, in case of an odd loop count} 2) Packed style --------------- Pseudocode : #define N 1024 struct {char A,B} M[N] char S[N] loop (N) S[i]=M[i].A + M[i].B ; r4 = base address of A ; r6 = base address of S load.s1 r4,r0 ; prefetch load.s2 r6,r0 ; prefetch get SR_MAX_SIZE,r1 ; r1 is loaded with 8, 16, 32... ; depending on the chip version (number of bytes per register) get SR_LOG_MAX_SIZE,r2 ; ie r2 = 3 if MAX_SIZE=8 (64-bit) loadimm N,r7 add r1,r4,r5 ; r5 = r4+max_size (pointer duplication) shr r2,r7,r7 ; loop count shl 1,r1,r2 ; r1 = r1*2 loopentry r3 loadf.s1 r2,r4,r10 loadf.s1 r2,r5,r11 mixhi.8 r10,r11,r12 mixlo.8 r10,r11,r13 ; stall sadd.8 r13,r12,r12 ; stall storef.s2 r1,r6,r13 loop r4,r3 ; decrement r3 // jump to r1 if r3 is not zero Slide 16 The future of the FC0 ------------------------------- * Adding new execution units : LNS Add/Sub/Conversion, IEEE floating point units, Popcount/ECC ... * adding other memory interfaces, ie DDR SDRAM * Extension to 2-issue then 4-issue * Split/pipelining of the decode/issue unit * Coding constraint for a superscalar F-CPU : 2-issue : 64/(2*3)= 10 instructions without dependency 3-issue : 64/(3*3)= 7 ... 4-issue : 64/(3*4)= 5 <-- current limit of the FC0 Slide 17 Evolution of the F-CPU -------------------------------- * explicit register renaming -> more usable registers * Possible directions : - SMT (Simultaneous Multi Threading), - multi-core chips - RISC->TTA translator - eDRAM (embedded DRAM) - F-BUS, ... * New instructions : Scatter-Gather, Permute ... Slide 18 Conclusion -------------------- * URL of the slides http://www.f-cpu.de/epf2001/ (not yet created) * Coming milestones : complete VHDL and manual v1 on CVS * F-CPU official web site : http://www.f-cpu.org * F-CPU manual available from http://www.f-cpu.seul.org --------------5F941EBBB54481DC4C459053-- From "Marco Al" Tue Jan 30 15:10:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00506 for ; Tue, 30 Jan 2001 20:46:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:25 +0100 (MET) Received: (qmail 734 invoked by uid 0); 30 Jan 2001 14:25:29 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx10) with SMTP; 30 Jan 2001 14:25:29 -0000 X-eGroups-Return: sentto-1101623-2134-980863337-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 30 Jan 2001 14:02:25 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 14:02:17 -0000 Received: (qmail 90458 invoked from network); 30 Jan 2001 14:01:29 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 30 Jan 2001 14:01:29 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 30 Jan 2001 14:01:28 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 77B382933 for ; Tue, 30 Jan 2001 15:01:27 +0100 (CET) Message-ID: <001d01c08ac6$5658c5f0$29e65982@student.utwente.nl> To: References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> <000901c08a49$73434cd0$29e65982@student.utwente.nl> <3A768CA6.82CD1917@mentor.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 15:10:02 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cbc8436e7189d87092e06cd23efb8713 Status: R X-Status: N From: "Yann GUIDON" <whygee@f-cpu.org>

> what does that mean ? i don't see ...

Hmmm, first explain something to me... the message that kicked this off was
about how to use SIMD effectively. It doesnt seem to make sense to be able to
gather 4 complete full width words in one cycle, thats much more data than you
can handle. It doesnt really help the pointer chasing problem either, you can
save some pointer registers because the post increment can be done on parts of a
SIMD word so you dont need individual pointers... but isnt that the sort of
thing what you have a large register file for?

I assumed the scatter/gather mechanism disassembled/assembled chunks from/into
words, to parallelize loops working on seperate structures, instead of SoA
(structure of array's). Was that what you meant to use the mechanism for?

Marco
Yahoo! Groups Sponsor
www. .com
From Yann GUIDON Tue Jan 30 15:24:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00509 for ; Tue, 30 Jan 2001 20:46:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 30 Jan 2001 20:46:26 +0100 (MET) Received: (qmail 12940 invoked by uid 0); 30 Jan 2001 14:33:16 -0000 Received: from ei.egroups.com (64.211.240.237) by 10.1.4.111 (mx11) with SMTP; 30 Jan 2001 14:33:16 -0000 X-eGroups-Return: sentto-1101623-2135-980865117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 30 Jan 2001 14:32:03 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 14:31:56 -0000 Received: (qmail 75601 invoked from network); 30 Jan 2001 14:31:10 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 30 Jan 2001 14:31:10 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 30 Jan 2001 14:31:09 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA10575; Tue, 30 Jan 2001 06:31:05 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWKNF; Tue, 30 Jan 2001 14:35:54 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A76CEA9.5E466255@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7095EA.A97EF9DF@jetnet.ab.ca> <3A74C8CC.8D141A8C@f-cpu.org> <000901c08a49$73434cd0$29e65982@student.utwente.nl> <3A768CA6.82CD1917@mentor.com> <001d01c08ac6$5658c5f0$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 15:24:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cf3d5c42dbf53f97cde6b53be5ce535c Status: R X-Status: N Marco Al wrote:
>
> From: "Yann GUIDON" <whygee@f-cpu.org>
>
> > what does that mean ? i don't see ...
>
> Hmmm, first explain something to me... the message that kicked this off was
> about how to use SIMD effectively. It doesnt seem to make sense to be able to
> gather 4 complete full width words in one cycle, thats much more data than you
> can handle. It doesnt really help the pointer chasing problem either, you can
> save some pointer registers because the post increment can be done on parts of a
> SIMD word so you dont need individual pointers... but isnt that the sort of
> thing what you have a large register file for?
>
> I assumed the scatter/gather mechanism disassembled/assembled chunks from/into
> words, to parallelize loops working on seperate structures, instead of SoA
> (structure of array's). Was that what you meant to use the mechanism for?

these s/g instructions are meant in the "old vector" sense, except that we don't have
vector registers but SIMD registers. i am not sure but it seems to be more or less
what you write :

example for scatter :
  for every chunk of a register do
    memory[ptr{i}]=src{i};

gather :
  for every chunk of a register do
    dest{i}=memory[ptr{i}];

in short, for a single pointer register, we can do several memory access.
It is rather easy to do for a vector computer (read : Cray-2 for example)
but here it's more difficult :
-less memory bandwidth
-SIMD (parallel) instead of vector (serial) operation
-TLB-based memory protection instead of fence registers
-...

If you make a sort algorithm for example, you can accelerate it a lot
by using several pointers at once. It also works for parallel lookup-table
access, graphics, and other random [non-vector or not-serial] access to memory.
Specifically, the latency of a load from memory is high and pointer-chasing
takes around 4 cycles per indirection in the best case (data present in the LSU).
so if you want to speed this up, you can make several parallel pointer-chasing
algorithms. However, remember that hashtable and binary trees are more efficient
than linked lists ;-)

> Marco
YG

speaking for himself
Yahoo! Groups Sponsor
From Tue Jan 30 17:22:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00366 for ; Wed, 31 Jan 2001 14:09:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:09:28 +0100 (MET) Received: (qmail 15972 invoked by uid 0); 30 Jan 2001 16:27:14 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx02) with SMTP; 30 Jan 2001 16:27:14 -0000 X-eGroups-Return: sentto-1101623-2136-980871987-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fj.egroups.com with NNFMP; 30 Jan 2001 16:27:13 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 16:26:26 -0000 Received: (qmail 17668 invoked from network); 30 Jan 2001 16:16:55 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 30 Jan 2001 16:16:55 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 30 Jan 2001 16:16:55 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 6ABE54513A for ; Tue, 30 Jan 2001 11:22:06 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <3A76CEA9.5E466255@mentor.com> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 11:22:06 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6557bc6f4b6a14b3a8572e3b51f19db6 Status: R X-Status: N

On Tue, 30 Jan 2001, Yann GUIDON wrote:

> these s/g instructions are meant in the "old vector" sense, except that we don't have
> vector registers but SIMD registers. i am not sure but it seems to be more or less
> what you write :
>
> example for scatter :
>   for every chunk of a register do
>     memory[ptr{i}]=src{i};
>
> gather :
>   for every chunk of a register do
>     dest{i}=memory[ptr{i}];
>
> in short, for a single pointer register, we can do several memory access.
> It is rather easy to do for a vector computer (read : Cray-2 for example)
> but here it's more difficult :
>  -less memory bandwidth
>  -SIMD (parallel) instead of vector (serial) operation
>  -TLB-based memory protection instead of fence registers
>  -...

The only thing I can imagine is creating some sort of state machine (you
had that 1.5x bandwidth thing earlier).

Or this:

If I have 3 numbers A, B, C such that the following operations produced
unique values I could have 2x the bandwidth.

A xor B = D
B xor C = E
C xor A = F
A xor B xor C = G

4 gets us even more possibilities

Picking an operation so that A op B != B op A would be doubly useful.

A - B = D
B - A = E
C - B = F
B - C = G
C - A = H
A - C = I

All you would need is a stream that contained those values A-I. I'll write
a program to investigate the possibilities.

My bet:

As n (num of primitives A,B,C,etc) increases the number of collisions
within a bitfield B increases.
As n increases C (num of combinations) increases.
As b (bitlength required to represent C) increases C increases much more
quickly.

With a little twiddling even the collisions could be avoided.

Rares

> > Marco
> YG
>
> speaking for himself
>
>
>
>
>


Yahoo! Groups Sponsor
www. .com
From frankberman@yahoo.com Sat Jan 27 22:31:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00378 for ; Wed, 31 Jan 2001 14:09:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:09:31 +0100 (MET) Received: (qmail 26742 invoked by uid 0); 30 Jan 2001 17:07:06 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx21) with SMTP; 30 Jan 2001 17:07:06 -0000 X-eGroups-Return: sentto-1101623-2137-980874308-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 30 Jan 2001 17:07:03 -0000 X-Sender: ldista_long@usa.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 17:05:07 -0000 Received: (qmail 48434 invoked from network); 30 Jan 2001 16:51:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 30 Jan 2001 16:51:57 -0000 Received: from unknown (HELO duck.softart.loc) (212.11.9.202) by mta2 with SMTP; 30 Jan 2001 16:51:57 -0000 Received: from [216.3.181.166] by duck.softart.loc (Netscape Messaging Server 3.56) with SMTP id 462; Sat, 27 Jan 2001 22:38:41 +0100 Message-ID: <000059a119b5$00004ad3$000025f7@> To: Undisclosed.Recipients@duck.softart.loc X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: ldista_long@usa.net From: frankberman@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 27 Jan 2001 16:31:21 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Flat Rate Long Distance! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 34356aa2ef69538229f88c5c0d903b0f Status: R X-Status: N Save Money On Your Long distance!

Pay only one flat rate!

Flat rate for USA, Canada and
International calls!

Save Money TODAY.

For more information reply
with your name and telephone
number!




To be removed from future offers
reply with "remove" in the subject.


















Save Money On Your Long distance!

Pay only one flat rate!

Flat rate for USA, Canada and
Yahoo! Groups Sponsor
www.
From Michael Riepe Tue Jan 30 16:33:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00504 for ; Wed, 31 Jan 2001 14:10:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:06 +0100 (MET) Received: (qmail 24051 invoked by uid 0); 30 Jan 2001 23:49:15 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 30 Jan 2001 23:49:15 -0000 X-eGroups-Return: sentto-1101623-2138-980898514-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 30 Jan 2001 23:48:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 23:48:32 -0000 Received: (qmail 49189 invoked from network); 30 Jan 2001 23:24:33 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 30 Jan 2001 23:24:33 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.66) by mta2 with SMTP; 30 Jan 2001 23:24:25 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00732; Tue, 30 Jan 2001 16:33:47 +0100 Message-ID: <20010130163347.13961@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200101292253.f0TMrWL01167@PrintServer.LedCom> <3A765693.E55577AB@free.fr> <3A7687D8.95036886@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A7687D8.95036886@mentor.com>; from Yann GUIDON on Tue, Jan 30, 2001 at 10:22:32AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 16:33:47 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 492e486f981f9d6a3f72184cafdc510d Status: R X-Status: N On Tue, Jan 30, 2001 at 10:22:32AM +0100, Yann GUIDON wrote:
[...]
> CVS at seul is interesting but we need somebody who watches over it.
> I don't remember who proposed/volunteered but it was not followed by acts.
> If someone else wants to manage the CVS tree, don't hesitate !

There's usually little additional work once the repository is setup,
but we have to decide carefully how the repository should look like
(directory structure!), and who's permitted to do what.

I'm willing to play the `CVS master' if nobody else volunteers, but
first we'll have to talk about some things:

      - will/can we use the existing repository at seul,
        or should we create a `private' one?

      - directory structure and areas of responsibility

      - guidelines for `peaceful coexistence' of developers
        (some do's and dont's to keep everybody happy)

To start the discussion -- the directory structure we currently have
looks like this:

      f-cpu/doc/      # probably with subdirectories tex/, html/ and so on
      f-cpu/vhdl/compile/<EDAtool>/      # batch files for <EDAtool> go here
      f-cpu/vhdl/eu_asu/
      f-cpu/vhdl/eu_idu/
      f-cpu/vhdl/eu_imu/
      f-cpu/vhdl/eu_inc/
      f-cpu/vhdl/eu_rop2/
      f-cpu/vhdl/eu_shl/
      f-cpu/vhdl/eu_sr/
      f-cpu/vhdl/gate_lib/
      f-cpu/vhdl/generic_adder/
      f-cpu/vhdl/templates/

We should add another top-level directory for tools we write (or port)
ourselves:

      f-cpu/tools/binutils/
      f-cpu/tools/gcc/
      ...

Later, we'll also need f-cpu/bios/, f-cpu/linux/ (Linux port) and so on.

Finally, some of the guidelines metioned above:

      - First of all, do not step on other developer's toes.      If you
        need a change in somebody's files, talk to him first.  This rule
        helps avoiding merge conflicts.

      - When editing files, do not re-indent them without a reason.
        Also, do not replace tabs with spaces or vice versa.      This will
        only blow up the repository (CVS cares about every single
        character, and keeps track of *all* changes).

      - All source files shall be in Unix format, i.e. use `LF' as
        the line termination character, and the ISO-8859-1 (aka latin-1)
        character set.  If you have to add binary files (you'd better
        avoid that), don't forget to turn off keyword substitution!!

      - Files used exclusively on DOS/Windows systems (e.g. .BAT files)
        shall have `CRLF' as the line termination `character', and shall
        use an appropriate DOS/Windows character sets (preferably only the
        lower half, i.e. US-ASCII).

      - Never check in files that are created automatically; instead,
        check in the files they're created from (e.g. check in the
        .tex sources, but not the resulting .ps files).

      - When setting tags, prefix them with your username (e.g.
        `whygee-' or `tired-').  Other tags are considered `global'
        and should only be set or deleted by the project's CVS admin
        (or with his/her explicit consent).

      - Never change the repository manually (e.g. move directories
        around) unless you have talked to the CVS admin and the
        developers before.

Comments?
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.  
From Nicolas Boulay Tue Jan 30 00:32:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00507 for ; Wed, 31 Jan 2001 14:10:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:07 +0100 (MET) Received: (qmail 28489 invoked by uid 0); 30 Jan 2001 23:57:24 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx15) with SMTP; 30 Jan 2001 23:57:24 -0000 X-eGroups-Return: sentto-1101623-2139-980899030-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 30 Jan 2001 23:57:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 30 Jan 2001 23:57:10 -0000 Received: (qmail 30802 invoked from network); 30 Jan 2001 23:23:44 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 30 Jan 2001 23:23:44 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 31 Jan 2001 00:24:49 -0000 Received: from ifrance.com (nas13-234.vlt.club-internet.fr [195.36.163.234]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA07602 for ; Wed, 31 Jan 2001 00:23:41 +0100 (MET) Message-ID: <3A75FD95.DDF206F5@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 00:32:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4c27178b60b0654dc6c6c7030f280f95 Status: R X-Status: N > 
> * faster clock -> shorter Critical Datapath -> 6 4-input gates i= n the CDP
>    or approximatively 10 transistors between two pipeli= ne flip-flops.
>    (I know, Nicolas, it's an heresy but you know the ar= guments...
>     And this rough design rule maps so easily in F= PGAs :-D)
>
:>>>> :<
- a flip-flop could have 40 transistors (at least ~10). So 10
transistors between to flip-flop is.. euh.. funny :)
- a 0.18 =B5m technology have around 20 ps of delay propagation thought
nand gates. So why usual design don't run at 8 Ghz ?...
- an simple full adder need 3 gates at least. So a 2 bits adder have 6
levels of gates, usualy in carry lookhead adder you use block of 4 bits
ripple carry adder on which you add the cost of the multiplexer.
- VHDL use synthetise tools, so you can't know wich kind of cell are
used. The number of entry on a cell depend on the fpga used (Virtex used around 8 entries per cells). Some entries are general others no (for
exemple, to make quick adder).

The problem with such argument, is that your are going to kill the
credibility of the fcpu team because it's a no sense.

nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.   
=0D
<= /td>
3D""
From "Guillaume Lederrey" Wed Jan 31 01:46:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00528 for ; Wed, 31 Jan 2001 14:10:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:14 +0100 (MET) Received: (qmail 20447 invoked by uid 0); 31 Jan 2001 01:08:34 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx18) with SMTP; 31 Jan 2001 01:08:34 -0000 X-eGroups-Return: sentto-1101623-2142-980903304-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 31 Jan 2001 01:08:32 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 01:08:23 -0000 Received: (qmail 22665 invoked from network); 31 Jan 2001 00:46:26 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 31 Jan 2001 00:46:26 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.122) by mta1 with SMTP; 31 Jan 2001 00:46:24 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f0V0kHj01344 for ; Wed, 31 Jan 2001 01:46:18 +0100 Message-Id: <200101310046.f0V0kHj01344@PrintServer.LedCom> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <20010130163347.13961@thrai.stud.uni-hannover.de> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 01:46:24 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c5da681920f32063d3ee8eccc6afde1 Status: R X-Status: N >I'm willing to play the `CVS master' if nobody else volunteers, but
>first we'll have to talk about some things:

  Good !  It already sounds like you will be a good "CVS master"
!

>      f-cpu/doc/      # probably with subdirectories tex/, html/ and so on

      f-cpu/doc/fr
      f-cpu/doc/eng ...  # or at least something to have the
different traduction clearly separated.  The graphics should be
soft links or should be in a common directory.
Yahoo! Groups Sponsor

www.   
From Rares Marian Wed Jan 31 04:34:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00549 for ; Wed, 31 Jan 2001 14:10:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:20 +0100 (MET) Received: (qmail 27408 invoked by uid 0); 31 Jan 2001 03:44:58 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx08) with SMTP; 31 Jan 2001 03:44:58 -0000 X-eGroups-Return: sentto-1101623-2143-980912640-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 31 Jan 2001 03:44:56 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 03:43:57 -0000 Received: (qmail 86100 invoked from network); 31 Jan 2001 03:29:39 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 31 Jan 2001 03:29:39 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 31 Jan 2001 03:29:39 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 1727845358; Tue, 30 Jan 2001 22:34:31 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010130223431.B27206@moonbase.res.wpi.net> References: <3A7751ED.37C1BCA5@f-cpu.org> In-Reply-To: <3A7751ED.37C1BCA5@f-cpu.org>; from whygee@f-cpu.org on Tue, Jan 30, 2001 at 18:44:45 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 22:34:31 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ab334163484c04ee006aec440fd6c4e Status: R X-Status: N
On Tue, 30 Jan 2001 18:44:45 Yann Guidon wrote:
> hi !
>
> rares@moonbase.res.wpi.net wrote:
> > On Tue, 30 Jan 2001, Yann GUIDON wrote:
> >
> <snip>
>
> increasing the bandwidth is fine, but this doesn't solve the problem for
> the instruction scheduling and the hazard and fault detection.
> Some golden rules for the FC0 are : never issue an instruction that could
> fault,
> use deterministic latency units, and perform atomic operations.

Sanity first!

> A load and store are already problematic instructions, they are treated
> in
> a non-obvious way in the FC0 and it's ok. But s/g is close to a
> microprogrammed
> instruction and that's what i call a "challenge"...

Ok let me see if I understand:
We want to s & g in parallel

I'm ready to bet it can't be done.  Even if you use my combination hash, to
get it all across the bus you end up having to unhash at the endpoints.  On
the other hand the bandwidth hash would free up the bus for devices to talk
to each other.

I suppose thAt's something... Digital technology sucks.  Too much
control/precision crap.  Analog was smooth and versatile. 

> > With a little twiddling even the collisions could be avoided.
> you'll discover that you'll need a lot of "twiddling" :-)

Dammit...

> Because in our case it is a synchronous communication, the mathematics is
> changed, compared to the usual "run length limited" techniques : there
> is no lower bound and the spectrum is virtually unlimited (but since it's
> in the lower frequencies, it's not interesting, heh).
> However, 2x boost with 4x oversampling sounds still fair. it could
> be used with the F-BUS (if only i had enough time...)

Hmm I'd like to learn more about this.

> > Rares
> WHYGEE@home
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>


Yahoo! Groups Sponsor
www. .com 
From Yann GUIDON Wed Jan 31 12:21:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00570 for ; Wed, 31 Jan 2001 14:10:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:29 +0100 (MET) Received: (qmail 24151 invoked by uid 0); 31 Jan 2001 11:29:17 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx08) with SMTP; 31 Jan 2001 11:29:17 -0000 X-eGroups-Return: sentto-1101623-2144-980940517-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 31 Jan 2001 11:29:05 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 11:28:36 -0000 Received: (qmail 1651 invoked from network); 31 Jan 2001 11:28:11 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 31 Jan 2001 11:28:11 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 31 Jan 2001 11:28:11 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA04884; Wed, 31 Jan 2001 03:28:07 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWLQT; Wed, 31 Jan 2001 11:32:59 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A77F549.43B444C9@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 12:21:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f15c05d2d2943e040582dc3fd8fe755d Status: R X-Status: N Hello,

Nicolas Boulay wrote:
> > * faster clock -> shorter Critical Datapath -> 6 4-input ga= tes in the CDP
> >    or approximatively 10 transistors between two p= ipeline flip-flops.
> >    (I know, Nicolas, it's an heresy but you know t= he arguments...
> >     And this rough design rule maps so easily= in FPGAs :-D)
> >
> :>>>> :<
> - a flip-flop could have 40 transistors (at least ~10). So 10
> transistors between to flip-flop is.. euh.. funny :)
the example you gave (i think i remember your toy-CPU project)
is very specific. FF in SRAM cells are 4 or 6 transistors,
FF for pipelines can be 6-transistors.
I think that some of the transistors that were added on your example
(correct me if i'm wrong) were used for compensation (of whatever),
boundary scan, testability ... only a few transistor are really needed
to "latch" data.

> - a 0.18 =B5m technology have around 20 ps of delay propagation though= t
> nand gates. So why usual design don't run at 8 Ghz ?...
don't ask me that question.
Even though i know that some DSP in InP worked at 1Ghz in 1993.
it's probably a price/application ratio, 10 GHz is possible on
small and specific designs and not on general-purpose consumer products. industrial scale is not prototyping.

> - an simple full adder need 3 gates at least. So a 2 bits adder have 6=
> levels of gates, usualy in carry lookhead adder you use block of 4 bit= s
> ripple carry adder on which you add the cost of the multiplexer.
?... there's something that i don't catch here...
are you saying that a half adder ("2 bits adder") takes 6 levels = of gates ???


> - VHDL use synthetise tools, so you can't know wich kind of cell are > used. The number of entry on a cell depend on the fpga used (Virtex us= ed
> around 8 entries per cells). Some entries are general others no (for > exemple, to make quick adder).
>
> The problem with such argument, is that your are going to kill the
> credibility of the fcpu team because it's a no sense.

Although the means (that is : the "specification" of 6 gates) is = not
excellent, remember that we must make a compromise at one point or another.=

First, we have to give a rough estimation of the core's complexity, and it = is
often expressed in "gates". Second, when the complexity estimatio= n started,
we had a 4-input multiplexor gate FPGA architecture in mind ; it was the technology used by ChipExpress and seemed to be a good compromise for porta= bility
and efficiency.

So i agree that the specification is not perfect, but now what do you want = to do ?
unbalanced or unmatched pipeline stages ? do you know ANY UNIVERSAL metrics=
for calibrating pipeline stages ?

now, another question : are there any remarks on the presentation synopsys<= BR> i submitted ? did i spell something wrong or is something too unclear ?

read you soon,

> nicO

YG

speaking for himself
Yahoo! Groups Spons= or
=
www.
3D""
From Yann GUIDON Wed Jan 31 12:34:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00573 for ; Wed, 31 Jan 2001 14:10:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:30 +0100 (MET) Received: (qmail 24593 invoked by uid 0); 31 Jan 2001 11:42:23 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx14) with SMTP; 31 Jan 2001 11:42:23 -0000 X-eGroups-Return: sentto-1101623-2145-980941283-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 31 Jan 2001 11:41:40 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 11:41:22 -0000 Received: (qmail 67531 invoked from network); 31 Jan 2001 11:40:57 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 31 Jan 2001 11:40:57 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 31 Jan 2001 12:42:02 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA05873; Wed, 31 Jan 2001 03:40:55 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWLR2; Wed, 31 Jan 2001 11:45:49 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A77F84B.9AC6AFA0@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200101310046.f0V0kHj01344@PrintServer.LedCom> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 12:34:35 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8da873e0267cd9120c671c315a35f249 Status: R X-Status: N Guillaume Lederrey wrote:
> >I'm willing to play the `CVS master' if nobody else volunteers, but
> >first we'll have to talk about some things:
>
>   Good !  It already sounds like you will be a good "CVS master" !
i confirm ;-P

> >       f-cpu/doc/      # probably with subdirectories tex/, html/ and so on
>         f-cpu/doc/fr
>         f-cpu/doc/eng ...  # or at least something to have the
> different traduction clearly separated.  The graphics should be
> soft links or should be in a common directory.

some other files ("classes") need also soft links.

looks like Michael will be the "master" and Guillaume and Philippe will be
the "backup" :-) it's better to have several people than only one
overbusy person. nice :-)


YG

speaking for himself
Yahoo! Groups Sponsor
From Yann GUIDON Wed Jan 31 12:46:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00576 for ; Wed, 31 Jan 2001 14:10:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:31 +0100 (MET) Received: (qmail 7081 invoked by uid 0); 31 Jan 2001 11:53:32 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx05) with SMTP; 31 Jan 2001 11:53:32 -0000 X-eGroups-Return: sentto-1101623-2146-980941973-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 31 Jan 2001 11:53:18 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 11:52:52 -0000 Received: (qmail 32848 invoked from network); 31 Jan 2001 11:52:23 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 31 Jan 2001 11:52:23 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 31 Jan 2001 11:52:22 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA06688; Wed, 31 Jan 2001 03:52:20 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWLRT; Wed, 31 Jan 2001 11:57:13 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A77FAF8.CBAA6ED4@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200101292253.f0TMrWL01167@PrintServer.LedCom> <3A765693.E55577AB@free.fr> <3A7687D8.95036886@mentor.com> <20010130163347.13961@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 12:46:00 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 75354190cc2c956a38067b778e3bcbe9 Status: R X-Status: N Michael Riepe wrote:
> I'm willing to play the `CVS master' if nobody else volunteers, but
> first we'll have to talk about some things:
>
>         - will/can we use the existing repository at seul,
>           or should we create a `private' one?
i don't know how it works at seul.
whatever simplest and handiest (so we can move the tree around the net).

>         - directory structure and areas of responsibility
structure : as it exists now, because it seems to be ok as of today.
responsibility : the last people that modified the file.
a readme.txt per directory is not too much either.

>         f-cpu/doc/      # probably with subdirectories tex/, html/ and so on

/doc/common  (LaTeX classes, pictures, etc)
/doc/en
/doc/fr
/doc/de
....
but i don't know how simlinks work woth CVS and latex.

>         f-cpu/vhdl/compile/<EDAtool>/   # batch files for <EDAtool> go here

on the root directory of /vhdl/compile
we can put a set of little batch files :
* set_simili.bat
* set_modelsim
* set_whatever... etc.
So they define the compile command and the directories of the libraries etc.
then we can simply type a unique command for compiling and testing.

<does and don't>
fine, copy and paste them in a file that will be located at the tree root :-)

>         - Never check in files that are created automatically; instead,
>           check in the files they're created from (e.g. check in the
>           .tex sources, but not the resulting .ps files).
but where will we put them for those who don't have the necessary compilers etc ?
we can make a /result directory that contains the .exe, .ps, etc...

> Comments?
really nice.
Now the challenge is to make it, and finally make it work smoothly :-)


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

YG

speaking for himself
Yahoo! Groups Sponsor

www.
From Yann GUIDON Wed Jan 31 13:01:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00585 for ; Wed, 31 Jan 2001 14:10:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:34 +0100 (MET) Received: (qmail 20791 invoked by uid 0); 31 Jan 2001 12:08:42 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx15) with SMTP; 31 Jan 2001 12:08:42 -0000 X-eGroups-Return: sentto-1101623-2147-980942899-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 31 Jan 2001 12:08:40 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 12:08:18 -0000 Received: (qmail 77887 invoked from network); 31 Jan 2001 12:07:49 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 31 Jan 2001 12:07:48 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 31 Jan 2001 12:07:48 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA08041; Wed, 31 Jan 2001 04:07:47 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWLSC; Wed, 31 Jan 2001 12:12:40 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A77FE97.EA4240FE@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7751ED.37C1BCA5@f-cpu.org> <20010130223431.B27206@moonbase.res.wpi.net> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 13:01:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A How To of your very own. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4108d238060276ba652aa8b90b1dea0e Status: R X-Status: N Rares Marian wrote:
> On Tue, 30 Jan 2001 18:44:45 Yann Guidon wrote:
> > hi !
> > rares@moonbase.res.wpi.net wrote:
> > > On Tue, 30 Jan 2001, Yann GUIDON wrote:
<snip>


> > A load and store are already problematic instructions, they are treated in
> > a non-obvious way in the FC0 and it's ok. But s/g is close to a
> > microprogrammed instruction and that's what i call a "challenge"...
> Ok let me see if I understand:
> We want to s & g in parallel
or more precisely : scatter is a multiple store in parallel, gather is a multiple
load in parallel.

> I'm ready to bet it can't be done.
it is done is some specific architectures.

>  Even if you use my combination hash, to
> get it all across the bus you end up having to unhash at the endpoints.  On
> the other hand the bandwidth hash would free up the bus for devices to talk
> to each other.
>
> I suppose thAt's something... Digital technology sucks.  Too much
> control/precision crap.  Analog was smooth and versatile.
but difficult to tune, calibrate etc...
do you remember the precision of an analog computer ?

> > > With a little twiddling even the collisions could be avoided.
> > you'll discover that you'll need a lot of "twiddling" :-)
> Dammit...
but if you're into it, you'll enjoy and wish you didn't miss
the math classes when you were young ;-)

> > Because in our case it is a synchronous communication, the mathematics is
> > changed, compared to the usual "run length limited" techniques : there
> > is no lower bound and the spectrum is virtually unlimited (but since it's
> > in the lower frequencies, it's not interesting, heh).
> > However, 2x boost with 4x oversampling sounds still fair. it could
> > be used with the F-BUS (if only i had enough time...)
> Hmm I'd like to learn more about this.
about what ? spectrum spreading ?
it's in advanced telco books.
The principle is simple : When you send bits over a wire, the spectrum
analysis shows a large number of regularly spaced peaks.
The space between the peaks corresponds to the bitrate and the distribution
of the peaks is related to the entropy of the signal.
Now if you want to increase the bitrate/bandwidth, you can
either increase the highest frequency of the medium (that's the usual technique)
or have more peaks towards the maximum frequency allowed by this transmission
medium. This corresponds to an increase of the sampling frequency,
or "oversampling", we transmit more information than the medium
allows otherwise. In fact, it's the same thing in the modems, the CD, the HDD etc...

now the sport is to create a packet protocol with a minimal overhead and latency
and with substancial increase in bandwidth. 4x oversampling seems to provide
2x increase, but we need rather long sequences (16 samples or so...).
it's a very hadache-prone sport, you're warned. Part of the difficulty is
that the packets don't transmit power-of-two data !

YG

speaking for himself
Yahoo! Groups Sponsor

www.
From Michael Riepe Wed Jan 31 04:33:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00594 for ; Wed, 31 Jan 2001 14:10:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:37 +0100 (MET) Received: (qmail 29470 invoked by uid 0); 31 Jan 2001 12:47:55 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx18) with SMTP; 31 Jan 2001 12:47:55 -0000 X-eGroups-Return: sentto-1101623-2148-980945250-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 31 Jan 2001 12:47:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 12:47:29 -0000 Received: (qmail 43401 invoked from network); 31 Jan 2001 12:47:11 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 31 Jan 2001 12:47:11 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.140) by mta3 with SMTP; 31 Jan 2001 13:48:12 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01939; Wed, 31 Jan 2001 04:33:02 +0100 Message-ID: <20010131043302.03341@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <20010130163347.13961@thrai.stud.uni-hannover.de> <200101310046.f0V0kHj01344@PrintServer.LedCom> X-Mailer: Mutt 0.84e In-Reply-To: <200101310046.f0V0kHj01344@PrintServer.LedCom>; from Guillaume Lederrey on Wed, Jan 31, 2001 at 01:46:24AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 04:33:02 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ff1dd3dc79f754044cff903ade562864 Status: R X-Status: N On Wed, Jan 31, 2001 at 01:46:24AM +0100, Guillaume Lederrey wrote:
> >I'm willing to play the `CVS master' if nobody else volunteers, but
> >first we'll have to talk about some things:
>
>   Good !  It already sounds like you will be a good "CVS master"
> !

You didn't notice the `if' in the sentence above, did you? ;)

> >      f-cpu/doc/      # probably with subdirectories tex/, html/ and so on
>
>       f-cpu/doc/fr
>       f-cpu/doc/eng ...  # or at least something to have the
> different traduction clearly separated.  The graphics should be
> soft links or should be in a common directory.

For the moment, all documentation, comments etc. should be in english.
There's no reason to waste time translating documents that will change
again and again, when there are more important things to do.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www..com
From Michael Riepe Wed Jan 31 05:31:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00597 for ; Wed, 31 Jan 2001 14:10:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 14:10:38 +0100 (MET) Received: (qmail 13677 invoked by uid 0); 31 Jan 2001 12:49:36 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx17) with SMTP; 31 Jan 2001 12:49:36 -0000 X-eGroups-Return: sentto-1101623-2149-980945323-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 31 Jan 2001 12:49:31 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 12:48:43 -0000 Received: (qmail 87206 invoked from network); 31 Jan 2001 12:47:06 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 31 Jan 2001 12:47:06 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.140) by mta3 with SMTP; 31 Jan 2001 13:48:09 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA02078; Wed, 31 Jan 2001 05:31:33 +0100 Message-ID: <20010131053133.53041@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A75FD95.DDF206F5@ifrance.com>; from Nicolas Boulay on Tue, Jan 30, 2001 at 12:32:37AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 05:31:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4d1d5e95ce8cb28a29a3a6cc3cfe1854 Status: R X-Status: N On Tue, Jan 30, 2001 at 12:32:37AM +0100, Nicolas Boulay wrote:
> > 
> > * faster clock -> shorter Critical Datapath -> 6 4-input ga= tes in the CDP
> >    or approximatively 10 transistors between two p= ipeline flip-flops.
> >    (I know, Nicolas, it's an heresy but you know t= he arguments...
> >     And this rough design rule maps so easily= in FPGAs :-D)
> >
> :>>>> :<
> - a flip-flop could have 40 transistors (at least ~10). So 10
> transistors between to flip-flop is.. euh.. funny :)

A standard SRAM cell has 6 transistors, IIRC, and a pretty short CDP --
why should a pipeline register be bigger?  Dynamic RAM cells may also<= BR> be possible, and they're even smaller (and faster).

> - a 0.18 =B5m technology have around 20 ps of delay propagation though= t
> nand gates. So why usual design don't run at 8 Ghz ?...

Wire length...

> - an simple full adder need 3 gates at least. So a 2 bits adder have 6=
> levels of gates, usualy in carry lookhead adder you use block of 4 bit= s
> ripple carry adder on which you add the cost of the multiplexer.

That would be the "74xx" implementation...

The carry output of a CMOS full adder can have a rather short delay
(two transistors).  This means that an n-bit ripple-carry adder will have a delay of ~2*n transistors.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
From pascal.van.leeuwen@philips.com Wed Jan 31 14:53:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00993 for ; Wed, 31 Jan 2001 15:51:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 15:51:51 +0100 (MET) Received: (qmail 32179 invoked by uid 0); 31 Jan 2001 14:00:59 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx13) with SMTP; 31 Jan 2001 14:00:59 -0000 X-eGroups-Return: sentto-1101623-2150-980949639-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 31 Jan 2001 14:00:57 -0000 X-Sender: pascal.van.leeuwen@philips.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 14:00:39 -0000 Received: (qmail 98516 invoked from network); 31 Jan 2001 13:52:24 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 31 Jan 2001 13:52:24 -0000 Received: from unknown (HELO gw-nl4.philips.com) (212.153.190.6) by mta1 with SMTP; 31 Jan 2001 13:52:23 -0000 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA26677 for ; Wed, 31 Jan 2001 14:52:21 +0100 (MET) (envelope-from pascal.van.leeuwen@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma026673; Wed, 31 Jan 01 14:52:21 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA03970 for ; Wed, 31 Jan 2001 14:52:21 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA13559 for ; Wed, 31 Jan 2001 14:52:20 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890020399239; Wed, 31 Jan 2001 14:53:58 +0100 To: Message-ID: <0056890020399239000002L992*@MHS> From: pascal.van.leeuwen@philips.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 14:53:58 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a8e40fe572342a4319783af6f6331e42 Status: R X-Status: N >> >
>> > * faster clock -> shorter Critical Datapath -> 6 4-inpu= t gates in the CDP
>> >    or approximatively 10 transistors between t= wo pipeline flip-flops.
>> >    (I know, Nicolas, it's an heresy but you kn= ow the arguments...
>> >     And this rough design rule maps so ea= sily in FPGAs :-D)
>> >
>> :>>>> :<
>> - a flip-flop could have 40 transistors (at least ~10). So 10
>> transistors between to flip-flop is.. euh.. funny :)
>
> A standard SRAM cell has 6 transistors, IIRC, and a pretty short CDP -= -
> why should a pipeline register be bigger?  Dynamic RAM cells may = also
> be possible, and they're even smaller (and faster).
>
Hmm, I'm usually just a lurker but I couldn't help myself here.
Yes, standard SRAM cells are 6 transistors (and even 4 is possible
depending on the process used).
However, an SRAM cell is something *completely different* from
a flipflop !!
SRAM cells are *not* edge triggered devices.
They tend to have very funky asychronous timing.

An edge triggered flipflop needs a lot of extra transistors to
detect the edge and safely capture the data.
If you would build one from gates it would take you about *8*
gates to build a safe one. With 5 transistors per gate (4 functional
+ 1 drive) that's 40 transistors ... (so that's where the 40
comes from). Of course this can be significantly optimised if you
use transistors directly instead of gates.
On top of that you probably also want a scan mux included
since full scan is the easiest way to test a nicely synchronous
design (you really don't want to mess with functional tests or
logic BIST, believe me).
I think 34 transistors is about a bare minimum for a good scanflop,
with the min path through the flop being about 6 transistors.

Dynamic flipflops use somewhat less transistors but are not
recommended as you cannot turn off the clock then.
(i.e. clock gating for power reduction)
Also they usually really suck w.r.t. timing parameters (slow)
and tend to be less 'safe' (i.e. more susceptible to metastability)

As far as realistic paths between 2 pipeline flipflops are concerned:
in a really flat, well-pipelined design I'm achieving about 8 gates
between flipflops.
You really can't do very much in 8 gates I can assure you!
People often only think of the functional gates required but you
also need buffer/inverter trees to provide sufficient drive
capability if the output of a piece of logic is used more than once.
Still, this 8 gate path takes less than 1 ns of delay in a 0.18u
CMOS process @ WCMIL PVT (125C,1.65V,slow process).

BTW: 8 gates would mean 8*5=3D40 transistors in the critical path.


Pascal van Leeuwen





michael@stud.uni-hannover.de on 31-01-2001 13:52:29
Please respond to f-cpu@yahoogroups.com@SMTP
To:      f-cpu@yahoogroups.com@SMTP
cc:     
Subject:      Re: [f-cpu] Submission update : last= but not least
Classification:     

On Tue, Jan 30, 2001 at 12:32:37AM +0100, Nicolas Boulay wrote:
> >
> > * faster clock -> shorter Critical Datapath -> 6 4-input ga= tes in the CDP
> >    or approximatively 10 transistors between two p= ipeline flip-flops.
> >    (I know, Nicolas, it's an heresy but you know t= he arguments...
> >     And this rough design rule maps so easily= in FPGAs :-D)
> >
> :>>>> :<
> - a flip-flop could have 40 transistors (at least ~10). So 10
> transistors between to flip-flop is.. euh.. funny :)

A standard SRAM cell has 6 transistors, IIRC, and a pretty short CDP --
why should a pipeline register be bigger?  Dynamic RAM cells may also<= BR> be possible, and they're even smaller (and faster).

> - a 0.18 =B5m technology have around 20 ps of delay propagation though= t
> nand gates. So why usual design don't run at 8 Ghz ?...

Wire length...

> - an simple full adder need 3 gates at least. So a 2 bits adder have 6=
> levels of gates, usualy in carry lookhead adder you use block of 4 bit= s
> ripple carry adder on which you add the cost of the multiplexer.

That would be the "74xx" implementation...

The carry output of a CMOS full adder can have a rather short delay
(two transistors).  This means that an n-bit ripple-carry adder will have a delay of ~2*n transistors.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>=
"All I wanna do is have a little fun before I die"
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
From Ben Franchuk Sun Jan 28 14:06:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01266 for ; Wed, 31 Jan 2001 18:23:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 18:23:04 +0100 (MET) Received: (qmail 1882 invoked by uid 0); 31 Jan 2001 16:29:04 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 31 Jan 2001 16:29:04 -0000 X-eGroups-Return: sentto-1101623-2153-980958427-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fg.egroups.com with NNFMP; 31 Jan 2001 16:27:27 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 16:27:06 -0000 Received: (qmail 16200 invoked from network); 31 Jan 2001 15:52:57 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 31 Jan 2001 15:52:57 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 31 Jan 2001 16:54:02 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA04092 for ; Wed, 31 Jan 2001 08:45:02 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A741968.9EEBAEB9@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 06:06:48 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5b2377f484a6aaea91d3a2d5e9d1ff6d Status: R X-Status: N Jeff Davies wrote:
>
> I've just been doing some asm level optimisation on x86, and, having had
> f-cpu architecture in my
> mind a bit, it is quite frankly startling how crap the x86 architecture
> is.

The intel CPU is good at fixed sized math, 8 bits , 16 bits , 32 bits,
but only the A register can do sign extend.
This is fine for a language like Pascal where you use a function
to convert data types. Other languages like C sign promote shorter data
to longer data thus making very crummy programs as A in the critical
path.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
From Ben Franchuk Sun Jan 28 14:23:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01272 for ; Wed, 31 Jan 2001 18:23:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 18:23:06 +0100 (MET) Received: (qmail 29682 invoked by uid 0); 31 Jan 2001 16:47:31 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx21) with SMTP; 31 Jan 2001 16:47:31 -0000 X-eGroups-Return: sentto-1101623-2154-980959615-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 31 Jan 2001 16:47:12 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 16:46:54 -0000 Received: (qmail 58331 invoked from network); 31 Jan 2001 16:10:02 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 31 Jan 2001 16:10:02 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 31 Jan 2001 16:10:02 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA04916 for ; Wed, 31 Jan 2001 09:02:07 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A741D69.3AEBEFBF@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 06:23:53 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 41197632994fa6f6f6d87d3d5e144755 Status: R X-Status: N Jeff Davies wrote:

> I was (about a year ago) of the opinion that a 32 bit cpu would be
> possibly of more general interest than
> a 64 bit one, but in retrospect, I think 32 bit address space will
> probably be ok for PDAs etc for the next 10
> years, but it is already commonplace for servers to have 2 gig of ram.
> [i'm not even going to consider the comments of anyone talking about
> segmentation or paging to keep
> 32 bit cpus in there].

But will a 32 bit address be segment be fine for a single data type
like code or text or heap?. The last thing needed is several layers of paged
memory
on the page tables.
Ben.
PS. The current cpu I am working on at home here will have
32KB of memory (12 bit bytes). Reserving 8K for the OS, I have 24K
of memory to play with. Looking at the old 8 Bit OS's and cpu's
am reminded what a well crafted program can do in a small amount of memory.
BTW I have a 4k text editor called t.com that I keep on my boot floppies.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Sun Jan 28 14:35:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01275 for ; Wed, 31 Jan 2001 18:23:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 31 Jan 2001 18:23:07 +0100 (MET) Received: (qmail 6187 invoked by uid 0); 31 Jan 2001 17:01:03 -0000 Received: from mw.egroups.com (208.50.144.94) by 10.1.4.119 (mx19) with SMTP; 31 Jan 2001 17:01:03 -0000 X-eGroups-Return: sentto-1101623-2155-980960442-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mw.egroups.com with NNFMP; 31 Jan 2001 17:01:01 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 17:00:42 -0000 Received: (qmail 82121 invoked from network); 31 Jan 2001 16:21:14 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 31 Jan 2001 16:21:14 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 31 Jan 2001 16:21:13 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA05428 for ; Wed, 31 Jan 2001 09:13:18 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A742009.1B7B9529@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 06:35:05 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Plastic Cpu's Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 667190fcc776e7dc56f6a80dccaa01ce Status: R X-Status: N Is the next generation plastic?
http://www.business2.com/content/magazine/breakthrough/2001/01/29/25390
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.  
From Wed Jan 31 18:05:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02640 for ; Thu, 1 Feb 2001 03:48:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:45 +0100 (MET) Received: (qmail 23661 invoked by uid 0); 31 Jan 2001 17:49:45 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx27) with SMTP; 31 Jan 2001 17:49:45 -0000 X-eGroups-Return: sentto-1101623-2156-980963353-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 31 Jan 2001 17:49:32 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 17:49:12 -0000 Received: (qmail 90689 invoked from network); 31 Jan 2001 17:05:32 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 31 Jan 2001 17:05:32 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 31 Jan 2001 18:06:37 -0000 Received: from localhost (graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA17639 for ; Wed, 31 Jan 2001 12:05:22 -0500 To: Freedom CPU In-Reply-To: <3A742009.1B7B9529@jetnet.ab.ca> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 12:05:22 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Plastic Cpu's Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0771f7dbbbd003c18a79f8bd1a03525 Status: R X-Status: N
Yahoo! Groups Sponsor

www.

From "Nathaniel Downes" Wed Jan 31 18:31:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02649 for ; Thu, 1 Feb 2001 03:48:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:48 +0100 (MET) Received: (qmail 18671 invoked by uid 0); 31 Jan 2001 18:19:12 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx13) with SMTP; 31 Jan 2001 18:19:12 -0000 X-eGroups-Return: sentto-1101623-2157-980965128-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 31 Jan 2001 18:19:03 -0000 X-Sender: down@ici.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 18:18:48 -0000 Received: (qmail 61316 invoked from network); 31 Jan 2001 17:30:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 31 Jan 2001 17:30:45 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 31 Jan 2001 17:30:44 -0000 Received: from kenny (h00105ac6ea34.ne.mediaone.net [66.31.4.143]) by bajor.ici.net (8.8.8/8.8.8) with SMTP id MAA07885 for ; Wed, 31 Jan 2001 12:31:35 -0500 (EST) Message-ID: <001901c08bab$b34843e0$8f041f42@ne.mediaone.net> To: References: <3A742009.1B7B9529@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Nathaniel Downes" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 12:31:52 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Plastic Cpu's Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C08B81.C9FCBDC0" X-UIDL: a6e415f962aa63f272cbbead68d1d1ba Status: R X-Status: N ------=_NextPart_000_0016_01C08B81.C9FCBDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Remember, it was "low-cost" chips. And it's quite obvious that you can mak= e plastic conductors, you just need to make polymers out of conductive mate= rials, right? ----- Original Message -----=20 From: Ben Franchuk=20 To: Freedom CPU=20 Sent: Sunday, January 28, 2001 8:35 AM Subject: [f-cpu] Plastic Cpu's Is the next generation plastic? http://www.business2.com/content/magazine/breakthrough/2001/01/29/25390 --=20 "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk Yahoo! Groups Sponsor=20 =20=20=20=20=20=20=20=20=20=20=20 www.=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20 =20=20=20=20=20=20=20 ------=_NextPart_000_0016_01C08B81.C9FCBDC0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Remember, it was "low-cost" chips.  And it's quite obvious that you can make plastic conductors, you just need to make polymers out of conductive materials, right?
----- Original Message -----
Sent: Sunday, January 28, 2001 8:35 AM
Subject: [f-cpu] Plastic Cpu's

Is the next generation plastic?
http://www.business2.com/content/magazine/breakthrough/2001/01/29/25390
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk


Yahoo! Groups Sponsor

www.   
------=_NextPart_000_0016_01C08B81.C9FCBDC0-- From box1771@yahoo.com Wed Jan 31 19:19:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02667 for ; Thu, 1 Feb 2001 03:48:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:53 +0100 (MET) Received: (qmail 24387 invoked by uid 0); 31 Jan 2001 19:21:42 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx24) with SMTP; 31 Jan 2001 19:21:42 -0000 X-eGroups-Return: sentto-1101623-2160-980968346-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 31 Jan 2001 19:12:27 -0000 X-Sender: s6621@postkassa.no X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 19:12:26 -0000 Received: (qmail 18533 invoked from network); 31 Jan 2001 18:27:37 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 31 Jan 2001 18:27:37 -0000 Received: from unknown (HELO exgsvr.integrate.com.tw) (61.13.169.33) by mta3 with SMTP; 31 Jan 2001 19:28:42 -0000 Received: from internetscan (internetscan.integrate.com.tw [61.13.169.1]) by exgsvr.integrate.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1AH0A832; Thu, 1 Feb 2001 02:29:40 +0800 Received: from 63.20.101.198 by internetscan (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 02:28:00 +0800 Message-ID: <000031a95931$00003f15$00004d6f@202.181.208.212> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: s6621@postkassa.no From: box1771@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 13:19:33 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] REDUCE TAXES - MAKE MORE MONEY 19823 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-UIDL: 76fd3fe8fc1a05665ce1f318d8524db6 Status: R X-Status: N How Would You Like to...... 1. Drastically Reduce Personal, Business and Capital gains taxes? 2. Create a six figure income every 4 months? 3. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? TAKE A SERIOUS LOOK AT YOUR LIFE..... Do you think you are paid what you are worth? Will you be set to retire in the next few years? Do you control the course of your day, or does someone watch over you? The fact is we have many people in our enterprise that earn over 50k per month from the privacy of their own homes, and are retiring in 2-3 years (wealthy) and having total freedom-both personal and financial. Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. The sad truth is, t's been designed that way by the ultra-rich and ultra powerful since before any of us were born. If you are interested in radically changing your financial and personal future, I invite you to call: TOLL FREE 1-800-352-3288 ext.4340 **Only Highly Motivated People Should call** This is NOT Multi-Level Marketing. My name is Mike, and I look forward to working with you! ************* removal see below ************** ========================================================== If you feel you received this message in error, please send a blank email to: We PROMPTLY honor ALL remove requests. mailto:box1771@yahoo.com?subject=Remove_me If there is an error with the above remove link, please notify us immediately so that we can fix the problem. ANY and ALL attempts to tamper with the remove link will severely hinder our efforts to honor remove requests. Or FAX your email address to 1-413-683-0270. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> eGroups is now Yahoo! Groups Click here for more details http://click.egroups.com/1/11231/0/_/3462/_/980968347/ ---------------------------------------------------------------------_-> From seoremove@earthlink.net Tue Jan 30 10:41:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02673 for ; Thu, 1 Feb 2001 03:48:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:54 +0100 (MET) Received: (qmail 8682 invoked by uid 0); 31 Jan 2001 19:25:30 -0000 Received: from fk.egroups.com (64.211.240.232) by 10.1.4.111 (mx11) with SMTP; 31 Jan 2001 19:25:30 -0000 X-eGroups-Return: sentto-1101623-2159-980967772-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 31 Jan 2001 19:03:13 -0000 X-Sender: seoremove@earthlink.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 19:02:51 -0000 Received: (qmail 25304 invoked from network); 31 Jan 2001 18:16:14 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 31 Jan 2001 18:16:14 -0000 Received: from unknown (HELO smtp-out1.bellatlantic.net) (199.45.40.143) by mta2 with SMTP; 31 Jan 2001 18:16:14 -0000 Received: from linux33pool.com (adsl-151-202-80-70.nyc.adsl.bellatlantic.net [151.202.80.70]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id NAA28668; Wed, 31 Jan 2001 13:16:07 -0500 (EST) Message-Id: <162.353446.766509@linux33pool.com> From: seoremove@earthlink.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 30 Jan 2001 09:41:17 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Free Search Engine Ranking Report Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net X-UIDL: 0599f35819f6b4ef662ce2535f17f3b1 Status: R X-Status: N Submission alone is not enough!
Many web hosting companies and site submission services offer to
submit your web site to hundreds, even thousands of search
engines on the Web.

Simply getting listed does not mean that your site will be found
in the engines by anyone searching for your products or services!
In fact, not being listed in the top search results is like not
being listed at all!

We offer a Free Search Engine Ranking Report at no obligation to
you so that you can see for yourself how well your site is
ranking on major search engines and directories. The results may
surprise you!

We can list your website in all major Search Engines and achieve
Top 10 positions. GUARANTEED!

You pay only after results are shown to you.

We key on the following major search engines:
* Yahoo-Looksmart-AltaVista-Dogpile-WebCrawler-Lycos-
* Excite-iwon-AskJeeves-AOL Search-Netscape-HotBot-MSN-
* GO(Infoseek)-NBCi(Snap)-Google-BrainFox-
* Open Directory-Findwhat-Fast Search(alltheweb)-Goto-Canada.


For more information and to order your Free Search Engine Ranking
Report, please go to: http://www.websiteoptimizationplus.com












------------------------------------------------------------

To be removed from this list, please mail to:
mailto:seoremove@earthlink.net?subject=Remove
subject line and you will be removed from our list.
xxx-00004
------------------------------------------------------------
Yahoo! Groups Sponsor
Do you know the name you want? Enter the domain name below and press GO!
www.
Yahoo! Domains
From Ben Franchuk Sun Jan 28 16:22:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02676 for ; Thu, 1 Feb 2001 03:48:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:55 +0100 (MET) Received: (qmail 13900 invoked by uid 0); 31 Jan 2001 19:28:30 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx02) with SMTP; 31 Jan 2001 19:28:30 -0000 X-eGroups-Return: sentto-1101623-2158-980967358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 31 Jan 2001 18:56:02 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 18:55:57 -0000 Received: (qmail 5561 invoked from network); 31 Jan 2001 18:08:36 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 31 Jan 2001 18:08:36 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 31 Jan 2001 19:09:40 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA10953 for ; Wed, 31 Jan 2001 11:00:39 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A743933.DBD3C915@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 08:22:27 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Plastic Cpu's Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f02b2d0f448c4c10d452215b60dab4b5 Status: R X-Status: N graham@belegost.mit.edu wrote:
> Yes, but they'll only run at 5kHz ;-)
I can see it Now.
New Book "The Vacuum Tube generation of computers " $100.
The CDROM ........................................  $10
The Computers (2nd Generation plastic) ...........   $1
Ben. 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
From Yann GUIDON Wed Jan 31 19:51:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02682 for ; Thu, 1 Feb 2001 03:48:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:57 +0100 (MET) Received: (qmail 1122 invoked by uid 0); 31 Jan 2001 19:39:54 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx23) with SMTP; 31 Jan 2001 19:39:54 -0000 X-eGroups-Return: sentto-1101623-2162-980969984-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 31 Jan 2001 19:39:50 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 19:39:43 -0000 Received: (qmail 1918 invoked from network); 31 Jan 2001 18:57:46 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 31 Jan 2001 18:57:46 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 31 Jan 2001 18:57:46 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA29958; Wed, 31 Jan 2001 10:57:42 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWMD4; Wed, 31 Jan 2001 19:02:34 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A785EA8.C7EA653B@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 19:51:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ca0b164d38dd6e3a068706d547c3c71 Status: R X-Status: N Ben Franchuk wrote:
>
> Jeff Davies wrote:
>
> > I was (about a year ago) of the opinion that a 32 bit cpu would be
> > possibly of more general interest than
> > a 64 bit one, but in retrospect, I think 32 bit address space will
> > probably be ok for PDAs etc for the next 10
> > years, but it is already commonplace for servers to have 2 gig of ram.
> > [i'm not even going to consider the comments of anyone talking about
> > segmentation or paging to keep
> > 32 bit cpus in there].
>
> But will a 32 bit address be segment be fine for a single data type
> like code or text or heap?. The last thing needed is several layers of paged
> memory
> on the page tables.

IIRC there is a 32-bit RISC CPU that uses paging ...
HP-PA. nothing close to x86, however it's interesting to know :-)

> Ben.
> PS. The current cpu I am working on at home here will have
> 32KB of memory (12 bit bytes). Reserving 8K for the OS, I have 24K
> of memory to play with. Looking at the old 8 Bit OS's and cpu's
> am reminded what a well crafted program can do in a small amount of memory.
> BTW I have a 4k text editor called t.com that I keep on my boot floppies.

ah the good days :-)

However, from Jeff's remark, i conclude that we didn't do a too bad job
at the F-CPU ISA, which is rather recomforting :-) I've spent so many
bad hours (nights) with x86 asm that i don't wish it to anyone.
kill the PC, Kill Intel, Kill x86, make a F-CPU :-)

YG

speaking for himself
Yahoo! Groups Sponsor
From shallowviolet@hushmail.com Wed Jan 31 20:12:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02688 for ; Thu, 1 Feb 2001 03:48:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:48:59 +0100 (MET) Received: (qmail 15279 invoked by uid 0); 31 Jan 2001 20:19:32 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx22) with SMTP; 31 Jan 2001 20:19:32 -0000 X-eGroups-Return: sentto-1101623-2163-980970810-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 31 Jan 2001 19:53:35 -0000 X-Sender: muchhilarity@i-mail.com.au X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 19:53:18 -0000 Received: (qmail 64521 invoked from network); 31 Jan 2001 19:13:22 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 31 Jan 2001 19:13:22 -0000 Received: from unknown (HELO cnoperu.lima.pe.odebrecht.com) (200.37.79.83) by mta3 with SMTP; 31 Jan 2001 20:14:25 -0000 Received: from localhost ([63.93.81.149]) by cnoperu.lima.pe.odebrecht.com (Netscape Messaging Server 3.6) with SMTP id AAA54BC; Wed, 31 Jan 2001 14:13:17 -0500 Message-Id: To: personalite@i-email.to X-Mailer: Mozilla 4.72 [en] (Win98; I) From: shallowviolet@hushmail.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 11:12:58 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Go Offshore Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1b839cb9ddaed863403f27e51d45da93 Status: R X-Status: N PCI

Create, Build, and Protect Wealth Offshore!

 Protect your hard earned income. The benefits from becoming a member of our network are so unique that you have the ability to apply them to both your business and personal financial needs. Nothing is left to chance. You do not need any experience or special education to be successful.

ALL YOU NEED IS SINCERE DESIRE!

Offshore Banking, Privacy,Asset Protection & Wealth Building

You will be exposed to investment strategies and income generation opportunities that pay high yield returns on your money. Learn about investment yields that are substantially higher per month than traditional domestic investments. These investments are the jealously guarded secrets of the wealthy that have been profiting from this knowledge for years.

Finally, you can take advantage of the same offshore tax havens that wealthy individuals have been utilizing for years to protect their assets. You don't need to be wealthy to start

Click Here to find out more!


All requests to be taken off our mailing list are AUTOMATICALLY and IMMEDIATELY
honored upon receipt. Click here to be taken off our list.


Each year in the U.S. alone, the "postal" bulk mail industry consumes over 450 million trees just to make the paper used in sending their advertisements and promotions. Using email instead can significantly reduce this consumption, while at the same time decreasing the billions of tons of paper
waste filling our landfills. Save the trees, save the planet, use email!

Yahoo! Groups Sponsor
www.
From Alan Grimes Wed Jan 31 22:33:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02700 for ; Thu, 1 Feb 2001 03:49:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:03 +0100 (MET) Received: (qmail 23804 invoked by uid 0); 31 Jan 2001 21:54:04 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx10) with SMTP; 31 Jan 2001 21:54:04 -0000 X-eGroups-Return: sentto-1101623-2165-980978039-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 31 Jan 2001 21:54:04 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 21:53:58 -0000 Received: (qmail 15083 invoked from network); 31 Jan 2001 21:33:02 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 31 Jan 2001 21:33:02 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta3 with SMTP; 31 Jan 2001 22:34:07 -0000 Received: from 66-44-73-151.s405.tnt10.lnhva.md.dialup.rcn.com ([66.44.73.151] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14O4s6-00067p-00 for f-cpu@yahoogroups.com; Wed, 31 Jan 2001 16:32:59 -0500 Message-ID: <3A7884C3.E5B72B01@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A74573B.272D0B94@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 16:33:55 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 73302c3801825951b7e42871913bfa5f Status: R X-Status: N Ben Franchuk wrote:

> You know by the time I figure out the 8086 segments the F-CPU will be
> out. :-).

You know, one of the reasons that I have lost my sanity was back 'bout
five years ago when I was really hyped up about writing my own operating
system I actually forced myself to LEARN that shit... =P I succeded...
(total waste of neurons that I deeply regret now...) I will go ahead and
explain it here because I assume the F-CPU will be an

OPERATING SYSTEM SUPPORTING PROCESSOR

Better processors don't support OSes. ;)

In so far as you are working in protected mode version 1, things can be
pretty simple... Unfortunately they went ahead and built version 2
without first clearing away the old shit... =(

The system is very simple, in theory...

You have five programs that you want to run concurrently...

Each of those programs can't know anything about any of the other
programs... So ideally you would want the programs to be *relocatable*.
That is, the programs would be written in such a way that they can be
loaded into any part of memory... Unfortunately that would require more
pointer registers than the architecture would allow, and fixed location
code runs faster anyway because the pointers can be taken directly from
the instruction stream without any additional arithmatic... This meathod
saves space and boosts performance.

So you write non-relocatable code. But the problem of loading these
programs concurrently is still an issue!

Well look at the 8086... Back in '78 the concept of SEGMENTS were
popular... Your program loader will take your code and then set Reg CS
to the beginning of your code and then all of your refferances in your
nonrelocatable code can be automaticaly be calculated, in hardware, as
being relative to the segment register... That's how dos does it... The
simplest executable format, the Com file, is loaded at offset 100h by
DOS

With this method you get everything you want except memory protection...
But before I go on to that I would like to point out some other cool
things DOS does...

Since the memory map of a .com file is fixed and standardized, you can
actually put operating system data structures and other services in this
region of space. Here is a list of things yor .com program can find in
the first 256 bytes of its address space, also known as the Program
Segment Prefix:

- Program exit. (excuting the code JMP 0 from within a com program will
cause a normal program termination. =)

You can also terminate a .com program by executing a simple RET
instruction, though you must be in the MAIN procedure and have properly
exited all your subfunctions. =)

- A vector to OS services (A callable function). (Int 21h would could be
completely replaced if only programmers were smart enough to use the
highly advanced dynamic services routines that DOS provides instead of
forcing DOS to support kludgy interfaces such as systems based on the
processor's interrupt vector table...)

- Varrious signal vectors. (You can trap these like you do a signal in
unix with the appropriate code).

- A pointer to the parent process, This is what allows dos to find the
shell that spawned any given process. =)

- Memory allocation information. (Dos doesn't have memory leaks.)

- File handles, (up to twenty files can be opened by your program using
DOS, Unlimited files can be accessed using the primative FCB system....)

I LOVE DOS!!!!

The 386 type segments are a simple and direct extension to this system
that allows for memory protection and a FAST way to switch contexts with
the OS... (other than by reloading the page tables).

The 386 allows you to specify small segments with byte sized granularity
and large segments with 4k granularity. You can move segments and adjust
permissions based on process rank (there are four). Highly ranked KERNEL
code can execute instructions that are forbidden to DRIVER or USER level
code.

Hey, If you want to complain about kludge, complain elsewhere, this is
the basic fundamental shit that needs to be handled by ANY OS...
I am nolonger a fan of OS technology but if you want to run an OS on
your CPU you need something that is functionaly equivalent to this! =P

Unfortunately, with segments alone you run into the problem of memory
fragmentation where the memory you need is available but not all in one
chunk... You COULD implement a memory-controller based paging system...
but Intel chose to add it to the processor...

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.

From Ben Franchuk Sun Jan 28 18:30:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02706 for ; Thu, 1 Feb 2001 03:49:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:06 +0100 (MET) Received: (qmail 2721 invoked by uid 0); 1 Feb 2001 00:19:56 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx03) with SMTP; 1 Feb 2001 00:19:56 -0000 X-eGroups-Return: sentto-1101623-2164-980974034-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 31 Jan 2001 20:47:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 20:47:13 -0000 Received: (qmail 84094 invoked from network); 31 Jan 2001 20:16:44 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 31 Jan 2001 20:16:44 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 31 Jan 2001 20:16:43 -0000 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA17886 for ; Wed, 31 Jan 2001 13:08:45 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A74573B.272D0B94@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 10:30:35 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4f4c5965e8bd1ae7840466ddcf5c8a8c Status: R X-Status: N Yann GUIDON wrote:
> However, from Jeff's remark, i conclude that we didn't do a too bad job
> at the F-CPU ISA, which is rather recomforting :-) I've spent so many
> bad hours (nights) with x86 asm that i don't wish it to anyone.
> kill the PC, Kill Intel, Kill x86, make a F-CPU :-)

You know by the time I figure out the 8086 segments the F-CPU will be out.
:-). The F-cpu ISA looks to real stable ( A good sign of a good CPU) but the
real test will be writing programs with it or fine tuning the hardware for it.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.  
From "Marco Al" Thu Feb 1 01:35:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02709 for ; Thu, 1 Feb 2001 03:49:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:07 +0100 (MET) Received: (qmail 22674 invoked by uid 0); 1 Feb 2001 00:28:10 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx08) with SMTP; 1 Feb 2001 00:28:10 -0000 X-eGroups-Return: sentto-1101623-2169-980987270-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 01 Feb 2001 00:28:02 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 00:27:49 -0000 Received: (qmail 56483 invoked from network); 1 Feb 2001 00:26:39 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 1 Feb 2001 00:26:39 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 1 Feb 2001 00:26:38 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 6BAEB2945 for ; Thu, 1 Feb 2001 01:26:37 +0100 (CET) Message-ID: <003101c08be6$d820a190$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Feb 2001 01:35:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1026479f580165742b47bfd0bf293fa3 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> > > - an simple full adder need 3 gates at least. So a 2 bits adder have 6
> > > levels of gates, usualy in carry lookhead adder you use block of 4 bits
> > > ripple carry adder on which you add the cost of the multiplexer.
> > ?... there's something that i don't catch here...
> > are you saying that a half adder ("2 bits adder") takes 6 levels of gates
???
> >
>
> YES ! (ripple adder since the lsb bit to the last carry)

But who would use a ripple adder in a high end processor? CLA can do it in 2n
gate delay's, redundant arithmetic much faster of course.

The most you are likely to find in the basic standard cell library from the
foundry is probably a full adder though, you brought it up before but I never
saw an answer... F-CPU really needs some semi-custom parts, how is that going to
be handled?

> Just one thing to add about the OOOC. That's what is made in fact by the
> C6000 DSP family from texas (vliw with 8 instructions used), 3 types of
> units but different latency (3 for mul, 1 for an add) BUT each single
> unit have access to the register bank. So you have 8 write ports and 8
> read ports !!!! (and 32 registers !). I had some question like "How is
> it possible to write on a register without waiting or killing the
> pipeline with different depth of pipelined unit ?".

They dont just expose the pipeline latencies to the programmer anymore? Bah,
thats what makes DSP programming so much fun.

Marco
Yahoo! Groups Sponsor
From Ben Franchuk Sun Jan 28 19:52:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02712 for ; Thu, 1 Feb 2001 03:49:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:08 +0100 (MET) Received: (qmail 16625 invoked by uid 0); 1 Feb 2001 01:12:41 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx14) with SMTP; 1 Feb 2001 01:12:41 -0000 X-eGroups-Return: sentto-1101623-2170-980987624-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 01 Feb 2001 00:34:02 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 00:33:43 -0000 Received: (qmail 77047 invoked from network); 1 Feb 2001 00:33:33 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 1 Feb 2001 00:33:33 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 1 Feb 2001 01:34:37 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA00845 for ; Wed, 31 Jan 2001 17:25:32 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A746A5F.5206BA44@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A74573B.272D0B94@jetnet.ab.ca> <3A7884C3.E5B72B01@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 11:52:15 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c8315f0fa4740257c7c0b852f36f47c3 Status: R X-Status: N Alan Grimes wrote:
You know, one of the reasons that I have lost my sanity was back 'bout
> five years ago when I was really hyped up about writing my own operating
> system I actually forced myself to LEARN that shit... =P I succeded...
> (total waste of neurons that I deeply regret now...) I will go ahead and
> explain it here because I assume the F-CPU will be an
> <cut>
> Well look at the 8086... Back in '78 the concept of SEGMENTS were
> popular... Your program loader will take your code and then set Reg CS
> to the beginning of your code and then all of your refferances in your
> nonrelocatable code can be automaticaly be calculated, in hardware, as
> being relative to the segment register..

The problem with the 8086 is the Segment was TOO small.
16 bits for a segement works ok for TINY programs but nothing
else.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.
From Ben Franchuk Sun Jan 28 20:36:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02715 for ; Thu, 1 Feb 2001 03:49:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:09 +0100 (MET) Received: (qmail 19480 invoked by uid 0); 1 Feb 2001 01:25:46 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx13) with SMTP; 1 Feb 2001 01:25:46 -0000 X-eGroups-Return: sentto-1101623-2171-980990291-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 01 Feb 2001 01:19:20 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 01:18:10 -0000 Received: (qmail 94780 invoked from network); 1 Feb 2001 01:18:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 1 Feb 2001 01:18:09 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 1 Feb 2001 02:19:13 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA03340 for ; Wed, 31 Jan 2001 18:10:11 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7474D8.D154D3FC@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 12:36:56 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1c9c353783508e176252bba3e439d1d0 Status: R X-Status: N Yann GUIDON wrote:

> However, from Jeff's remark, i conclude that we didn't do a too bad job
> at the F-CPU ISA, which is rather recomforting :-) I've spent so many
> bad hours (nights) with x86 asm that i don't wish it to anyone.
> kill the PC, Kill Intel, Kill x86, make a F-CPU :-)

I bet when you are done the F-CPU you will want to kill Penguins
too.
I was thinking also of a real sticky problem with the current crop
of software - Heap fragmentation. That is where your heap of free
memory has so many holes in it that it becomes useless. You can't
move stuff around to get the space back because the OS has no track
of what POINTERS in memory need to be modified. Have there been any
new ideas in computer science how Software,OS's and Cpu hardware needs
to work together to handle lost and moved pointers?
Ben.


--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From Ben Franchuk Sun Jan 28 20:49:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02718 for ; Thu, 1 Feb 2001 03:49:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:10 +0100 (MET) Received: (qmail 11168 invoked by uid 0); 1 Feb 2001 01:32:13 -0000 Received: from hh.egroups.com (208.50.99.210) by 10.1.4.106 (mx06) with SMTP; 1 Feb 2001 01:32:13 -0000 X-eGroups-Return: sentto-1101623-2172-980991079-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 01 Feb 2001 01:31:24 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 01:31:18 -0000 Received: (qmail 30698 invoked from network); 1 Feb 2001 01:31:18 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 1 Feb 2001 01:31:18 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 1 Feb 2001 02:32:19 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA03961 for ; Wed, 31 Jan 2001 18:23:15 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7477E7.92F622C8@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A74573B.272D0B94@jetnet.ab.ca> <3A7884C3.E5B72B01@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 12:49:59 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 45116677ef6d0d024e031a471c3b8c0d Status: R X-Status: N Alan Grimes wrote:
>
> You know, one of the reasons that I have lost my sanity was back 'bout
> five years ago when I was really hyped up about writing my own operating
> system I actually forced myself to LEARN that shit... =P I succeded...
> (total waste of neurons that I deeply regret now...) I will go ahead and
> explain it here because I assume the F-CPU will be an

That great - now you can write a NEW OS for the F-CPU.
The  mascot would be a vampire Bat as it was your only friend during the
long nights programing and you want to Suck the life out of  Bill G... and
assorted penguins.
Bad features from DOS.
One thing most programs still do is they Assume they have all the
memory and I/O resources like mice and video.Most programs don't want
to share resources and few Languages let you manage virtual memory effectively.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.  
From Alan Grimes Thu Feb 1 02:43:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02724 for ; Thu, 1 Feb 2001 03:49:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:12 +0100 (MET) Received: (qmail 20691 invoked by uid 0); 1 Feb 2001 01:42:21 -0000 Received: from ej.egroups.com (64.211.240.230) by 10.1.4.106 (mx06) with SMTP; 1 Feb 2001 01:42:21 -0000 X-eGroups-Return: sentto-1101623-2173-980991736-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 01 Feb 2001 01:42:20 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 01:42:16 -0000 Received: (qmail 77478 invoked from network); 1 Feb 2001 01:42:15 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 1 Feb 2001 01:42:15 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta2 with SMTP; 1 Feb 2001 01:42:15 -0000 Received: from 66-44-66-194.s194.tnt7.lnhva.md.dialup.rcn.com ([66.44.66.194] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14O8lJ-0004Iy-00 for f-cpu@yahoogroups.com; Wed, 31 Jan 2001 20:42:14 -0500 Message-ID: <3A78BF2E.3D43A61@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A7474D8.D154D3FC@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 20:43:10 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a3693726d8e426ba4f740866e2bf8de0 Status: R X-Status: N > I bet when you are done the F-CPU you will want to kill Penguins
> too.

I got to pondering a quake style game where penguins were the monsters
and linux developers were the daemons quite a few years ago...


>Have there been any new ideas in computer science how Software,OS's and
> Cpu hardware needs to work together to handle lost and moved pointers?

The ideas needed to solve the problems of fragmentation that you
describe are quite streight-forward... They just aren't implemented
because everybody keeps worshiping this design that was orrigionally
developed in assembly language. =(

I will be glad to discuss it at length some other time when my brain has
recovered from its daily beating... I would be happy to bring you
on-board my project that seeks to solve these problems... =)

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Thu Feb 1 00:34:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02727 for ; Thu, 1 Feb 2001 03:49:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Feb 2001 03:49:13 +0100 (MET) Received: (qmail 12591 invoked by uid 0); 1 Feb 2001 01:51:39 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx01) with SMTP; 1 Feb 2001 01:51:39 -0000 X-eGroups-Return: sentto-1101623-2166-980983573-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fg.egroups.com with NNFMP; 31 Jan 2001 23:26:21 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 23:26:13 -0000 Received: (qmail 82995 invoked from network); 31 Jan 2001 23:25:23 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 31 Jan 2001 23:25:23 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 31 Jan 2001 23:25:23 -0000 Received: from ifrance.com (nas20-203.vlt.club-internet.fr [195.36.170.203]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA09039 for ; Thu, 1 Feb 2001 00:25:18 +0100 (MET) Message-ID: <3A78A112.5875648@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Feb 2001 00:34:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c5a4d836a65b18ee7e4180bb00fb187c Status: R X-Status: N Salut,

Yann GUIDON a =E9crit :
>
> Hello,
>
> Nicolas Boulay wrote:
> > > * faster clock -> shorter Critical Datapath -> 6 4-inp= ut gates in the CDP
> > >    or approximatively 10 transistors between = two pipeline flip-flops.
> > >    (I know, Nicolas, it's an heresy but you k= now the arguments...
> > >     And this rough design rule maps so e= asily in FPGAs :-D)
> > >
> > :>>>> :<
> > - a flip-flop could have 40 transistors (at least ~10). So 10
> > transistors between to flip-flop is.. euh.. funny :)
> the example you gave (i think i remember your toy-CPU project)
> is very specific. FF in SRAM cells are 4 or 6 transistors,
> FF for pipelines can be 6-transistors.
> I think that some of the transistors that were added on your example > (correct me if i'm wrong) were used for compensation (of whatever), > boundary scan, testability ... only a few transistor are really needed=
> to "latch" data.
>

I realy ask myself, if you have soon forget the part "me" from yo= ur
"mime" courses. 10 transistors is the absolute minimum. I hope yo= u could
believe that you could make some mistakes, some times.

> > - a 0.18 =B5m technology have around 20 ps of delay propagation t= hought
> > nand gates. So why usual design don't run at 8 Ghz ?...
> don't ask me that question.
> Even though i know that some DSP in InP worked at 1Ghz in 1993.

I speak about CMOS process !!!!!!!!!!!! Give the name of only one
million gates circuit made by an other technology than CMOS (or BiCMOS)
using other materials than Si (or SOI or SiGe, which always use silicon) !!

> it's probably a price/application ratio, 10 GHz is possible on
> small and specific designs and not on general-purpose consumer product= s.
> industrial scale is not prototyping.

With a big fridge on it, maybe !

>
> > - an simple full adder need 3 gates at least. So a 2 bits adder h= ave 6
> > levels of gates, usualy in carry lookhead adder you use block of = 4 bits
> > ripple carry adder on which you add the cost of the multiplexer.<= BR> > ?... there's something that i don't catch here...
> are you saying that a half adder ("2 bits adder") takes 6 le= vels of gates ???
>

YES ! (ripple adder since the lsb bit to the last carry)

> > - VHDL use synthetise tools, so you can't know wich kind of cell = are
> > used. The number of entry on a cell depend on the fpga used (Virt= ex used
> > around 8 entries per cells). Some entries are general others no (= for
> > exemple, to make quick adder).
> >
> > The problem with such argument, is that your are going to kill th= e
> > credibility of the fcpu team because it's a no sense.
>
> Although the means (that is : the "specification" of 6 gates= ) is not
> excellent, remember that we must make a compromise at one point or ano= ther.
>

A good way is to see our goal. 20 pipelines stages, more, less ? Then
after making some synthese you could say which unit need to be pipelined more or not.

> First, we have to give a rough estimation of the core's complexity, an= d it is
> often expressed in "gates". Second, when the complexity esti= mation started,
> we had a 4-input multiplexor gate FPGA architecture in mind ; it was t= he
> technology used by ChipExpress and seemed to be a good compromise for = portability
> and efficiency.
>

Yes, but it's change with the fpga used. So believe in compiler !

> So i agree that the specification is not perfect, but now what do you = want to do ?
> unbalanced or unmatched pipeline stages ? do you know ANY UNIVERSAL me= trics
> for calibrating pipeline stages ?
>

There isn't. But you could not say in a word : 6 gates per stages, and
make a one stage decoder. You have to be constant.

> now, another question : are there any remarks on the presentation syno= psys
> i submitted ? did i spell something wrong or is something too unclear = ?
>

Just one thing to add about the OOOC. That's what is made in fact by the C6000 DSP family from texas (vliw with 8 instructions used), 3 types of
units but different latency (3 for mul, 1 for an add) BUT each single
unit have access to the register bank. So you have 8 write ports and 8
read ports !!!! (and 32 registers !). I had some question like "How is=
it possible to write on a register without waiting or killing the
pipeline with different depth of pipelined unit ?". The only answer found (by me, and one of my collegue, a specialist in DSP and computer
architecture) is to have for each unit, an access to the register bank.

> read you soon,
You just do it ! ;p
>
> > nicO
>
> YG
nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
From David Sullins Thu Feb 1 06:34:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00430 for ; Sat, 3 Feb 2001 02:26:08 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:08 +0100 (MET) Received: (qmail 4266 invoked by uid 0); 1 Feb 2001 05:39:21 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx22) with SMTP; 1 Feb 2001 05:39:21 -0000 X-eGroups-Return: sentto-1101623-2174-981005957-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 01 Feb 2001 05:39:20 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 05:39:16 -0000 Received: (qmail 72885 invoked from network); 1 Feb 2001 05:39:16 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 1 Feb 2001 05:39:16 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta1 with SMTP; 1 Feb 2001 05:39:15 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id XAA26456; Wed, 31 Jan 2001 23:39:13 -0600 Received: from eceultra3 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id XAA06574; Wed, 31 Jan 2001 23:39:12 -0600 (CST) Received: from localhost by eceultra3 (8.8.8+Sun/ECESolaris-Client) id FAA07364; Thu, 1 Feb 2001 05:34:43 GMT To: f-cpu@yahoogroups.com In-Reply-To: <3A743C08.C043173C@f-cpu.org> Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 23:34:43 -0600 (CST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1ae1aac0bcedf978d9204d3d1c438617 Status: R X-Status: N Hi.

On Sun, 28 Jan 2001, Yann Guidon wrote:

> hello,
>
> David Sullins wrote:
> > I can find no source that definitively explains what each execution unit
> > looks like externally.  Part 3 of the manual shows several useful
> > diagrams, but it lacks a diagram showing the actual bits entering/exiting
> > an execution unit.  A simple VHDL entity declaration for each EU would be
> > helpful.
>
> <snip>
>
> you're right, the manual is "under rework". it was not touched during
> almost a year and now, some updated parts are not coherent with the old
> parts. Since the time when Olicier disclosed his LaTeX version of the manual
> (november IIRC), i have updated the parts 1 to 4 and you can find them on
> the seul.org site. However, you understand that the 6th part is the most difficult,
> so it will require a lot of work. It was even incomplete in v0.2.
<snip>

I'm disappointed this is the only response I got.  I'm just asking for a
definitive specification of any of the components which need to be worked
on.  It's difficult to contribute without a little direction.

Dave
Yahoo! Groups Sponsor

www.  
From Nicolas Boulay Thu Feb 1 00:38:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00433 for ; Sat, 3 Feb 2001 02:26:09 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:09 +0100 (MET) Received: (qmail 31396 invoked by uid 0); 1 Feb 2001 06:39:39 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx18) with SMTP; 1 Feb 2001 06:39:39 -0000 X-eGroups-Return: sentto-1101623-2168-980983847-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 31 Jan 2001 23:33:25 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 23:30:47 -0000 Received: (qmail 31023 invoked from network); 31 Jan 2001 23:29:21 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 31 Jan 2001 23:29:21 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 31 Jan 2001 23:29:20 -0000 Received: from ifrance.com (nas20-203.vlt.club-internet.fr [195.36.170.203]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA12425 for ; Thu, 1 Feb 2001 00:29:16 +0100 (MET) Message-ID: <3A78A201.2FD1EF17@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A74573B.272D0B94@jetnet.ab.ca> <3A7884C3.E5B72B01@starpower.net> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Feb 2001 00:38:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 14c1d73178b295ff9ff6b4ab72e676f5 Status: R X-Status: N Nice introduction to the OS. Maybe you have to look to the thread about
TLB and MMU, and you will have your answer...

nicO

Alan Grimes a =E9crit :
>
> Ben Franchuk wrote:
>
> > You know by the time I figure out the 8086 segments the F-CPU wil= l be
> > out. :-).
>
> You know, one of the reasons that I have lost my sanity was back 'bout=
> five years ago when I was really hyped up about writing my own operati= ng
> system I actually forced myself to LEARN that shit... =3DP I succeded.= ..
> (total waste of neurons that I deeply regret now...) I will go ahead a= nd
> explain it here because I assume the F-CPU will be an
>
> OPERATING SYSTEM SUPPORTING PROCESSOR
>
> Better processors don't support OSes. ;)
>
> In so far as you are working in protected mode version 1, things can b= e
> pretty simple... Unfortunately they went ahead and built version 2
> without first clearing away the old shit... =3D(
>
> The system is very simple, in theory...
>
> You have five programs that you want to run concurrently...
>
> Each of those programs can't know anything about any of the other
> programs... So ideally you would want the programs to be *relocatable*= .
> That is, the programs would be written in such a way that they can be<= BR> > loaded into any part of memory... Unfortunately that would require mor= e
> pointer registers than the architecture would allow, and fixed locatio= n
> code runs faster anyway because the pointers can be taken directly fro= m
> the instruction stream without any additional arithmatic... This meath= od
> saves space and boosts performance.
>
> So you write non-relocatable code. But the problem of loading these > programs concurrently is still an issue!
>
> Well look at the 8086... Back in '78 the concept of SEGMENTS were
> popular... Your program loader will take your code and then set Reg CS=
> to the beginning of your code and then all of your refferances in your=
> nonrelocatable code can be automaticaly be calculated, in hardware, as=
> being relative to the segment register... That's how dos does it... Th= e
> simplest executable format, the Com file, is loaded at offset 100h by<= BR> > DOS
>
> With this method you get everything you want except memory protection.= ..
> But before I go on to that I would like to point out some other cool > things DOS does...
>
> Since the memory map of a .com file is fixed and standardized, you can=
> actually put operating system data structures and other services in th= is
> region of space. Here is a list of things yor .com program can find in=
> the first 256 bytes of its address space, also known as the Program > Segment Prefix:
>
> - Program exit. (excuting the code JMP 0 from within a com program wil= l
> cause a normal program termination. =3D)
>
> You can also terminate a .com program by executing a simple RET
> instruction, though you must be in the MAIN procedure and have properl= y
> exited all your subfunctions. =3D)
>
> - A vector to OS services (A callable function). (Int 21h would could = be
> completely replaced if only programmers were smart enough to use the > highly advanced dynamic services routines that DOS provides instead of=
> forcing DOS to support kludgy interfaces such as systems based on the<= BR> > processor's interrupt vector table...)
>
> - Varrious signal vectors. (You can trap these like you do a signal in=
> unix with the appropriate code).
>
> - A pointer to the parent process, This is what allows dos to find the=
> shell that spawned any given process. =3D)
>
> - Memory allocation information. (Dos doesn't have memory leaks.)
>
> - File handles, (up to twenty files can be opened by your program usin= g
> DOS, Unlimited files can be accessed using the primative FCB system...= .)
>
> I LOVE DOS!!!!
>
> The 386 type segments are a simple and direct extension to this system=
> that allows for memory protection and a FAST way to switch contexts wi= th
> the OS... (other than by reloading the page tables).
>
> The 386 allows you to specify small segments with byte sized granulari= ty
> and large segments with 4k granularity. You can move segments and adju= st
> permissions based on process rank (there are four). Highly ranked KERN= EL
> code can execute instructions that are forbidden to DRIVER or USER lev= el
> code.
>
> Hey, If you want to complain about kludge, complain elsewhere, this is=
> the basic fundamental shit that needs to be handled by ANY OS...
> I am nolonger a fan of OS technology but if you want to run an OS on > your CPU you need something that is functionaly equivalent to this! = =3DP
>
> Unfortunately, with segments alone you run into the problem of memory<= BR> > fragmentation where the memory you need is available but not all in on= e
> chunk... You COULD implement a memory-controller based paging system..= .
> but Intel chose to add it to the processor...
>
> --
> Perhaps I will upgrade my OS from Win 3.11...
> But It has to be more sophisticated than Win 3.11.
> As well as less complicated than Win 3.11.
> *AND* It must run on THE MACHINE!!!!
> http://users.erols.com/= alangrimes/  <my website.
> Any usage of this e-mail account is subject to the terms and condition= s
> specified on my website.
>

Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.  
=0D
3D""
From Jeff Davies Wed Jan 31 15:39:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00436 for ; Sat, 3 Feb 2001 02:26:11 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:11 +0100 (MET) Received: (qmail 17664 invoked by uid 0); 1 Feb 2001 06:55:45 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx02) with SMTP; 1 Feb 2001 06:55:45 -0000 X-eGroups-Return: sentto-1101623-2152-980953943-sloyment=gmx.net@returns.onelist.com Received: from [10.1.1.40] by f19.egroups.com with NNFMP; 01 Feb 2001 06:55:44 -0000 Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 31 Jan 2001 15:12:42 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 15:12:22 -0000 Received: (qmail 94622 invoked from network); 31 Jan 2001 14:50:12 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 31 Jan 2001 14:50:12 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta1 with SMTP; 31 Jan 2001 14:50:12 -0000 Received: from modem-85.tennessee.dialup.pol.co.uk ([62.137.93.85] helo=llandre.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14NyaG-0000Rm-00 for f-cpu@egroups.com; Wed, 31 Jan 2001 14:50:09 +0000 Message-ID: <3A7823BF.46752B33@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@yahoogroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 14:39:59 +0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bdf7f42a1b9e8edf06997e4609c3a686 Status: R X-Status: N I've just been doing some asm level optimisation on x86, and, having had
f-cpu architecture in my
mind a bit, it is quite frankly startling how crap the x86 architecture
is.
It is also startling how crap Visual C++ compiler is at optimising [in
an absolute sense - it might be
reasonable compared to other C++ compilers, but compared to manual
coding in assembly, it's
crap].

It seems even today you can't move a floating point value directly to a
register from the fp unit, you
have to move it via memory. Amazing. And the total lack of usable
registers makes the C/C++ "register"
directive totally pointless.

I was (about a year ago) of the opinion that a 32 bit cpu would be
possibly of more general interest than
a 64 bit one, but in retrospect, I think 32 bit address space will
probably be ok for PDAs etc for the next 10
years, but it is already commonplace for servers to have 2 gig of ram.
[i'm not even going to consider the comments of anyone talking about
segmentation or paging to keep
32 bit cpus in there].

I was also musing to myself about the possibility of someday testing a
harvard architecture modified
f-cpu. Obviously the TLB would become two seperate TLBs but not much
else would change.
Software would have to be fixed although how much is anyone's guess.
Net effect of course would be to double memory bandwidth (at maximum).

yikes this is pretty grimesey kind of mulling of wierd stuff

Jeff Davies
Yahoo! Groups Sponsor

www.  
From Yann GUIDON Wed Jan 31 19:24:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00439 for ; Sat, 3 Feb 2001 02:26:12 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:12 +0100 (MET) Received: (qmail 17682 invoked by uid 0); 1 Feb 2001 06:56:41 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx08) with SMTP; 1 Feb 2001 06:56:41 -0000 X-eGroups-Return: sentto-1101623-2161-980968936-sloyment=gmx.net@returns.onelist.com Received: from [10.1.1.40] by hi.egroups.com with NNFMP; 01 Feb 2001 06:56:31 -0000 Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 31 Jan 2001 19:22:23 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 19:22:16 -0000 Received: (qmail 32531 invoked from network); 31 Jan 2001 18:30:29 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 31 Jan 2001 18:30:29 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 31 Jan 2001 18:30:29 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA25715; Wed, 31 Jan 2001 10:30:25 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWMC7; Wed, 31 Jan 2001 18:35:18 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A785844.86D07951@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0056890020401331000002L912*@MHS> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 19:24:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f1c449a0a3f23db3463ead781c44096 Status: R X-Status: N pascal.van.leeuwen@philips.com wrote:
> > BTW: 8 gates would mean 8*5=40 transistors in the critical path.
>
> Correction: 8*3 = 24 of course since the transistors are not
> all in series ...

thank you for the details :-)
this confirms that the pipeline latches
are not 40 transistors of CDP ;-)

(of course i remember of setup & hold etc...)

but remember that FPGA/ASIC are also a target
and we must have a rough (+/- 70%) estimation of the
gate count ... [just trying to defend my point of view ;-)]

> Pascal van Leeuwen
YG

speaking for himself
Yahoo! Groups Sponsor
www. .com
From pascal.van.leeuwen@philips.com Wed Jan 31 15:09:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00442 for ; Sat, 3 Feb 2001 02:26:13 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:13 +0100 (MET) Received: (qmail 27807 invoked by uid 0); 1 Feb 2001 06:59:32 -0000 Received: from mx11.rz2.gmx.net (HELO fh.egroups.com) (10.1.72.111) by mxi1.gmx.net (mxi1) with SMTP; 1 Feb 2001 06:59:32 -0000 X-eGroups-Return: sentto-1101623-2151-980951171-sloyment=gmx.net@returns.onelist.com Received: from [10.1.1.40] by fh.egroups.com with NNFMP; 01 Feb 2001 06:57:36 -0000 Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 31 Jan 2001 14:26:31 -0000 X-Sender: pascal.van.leeuwen@philips.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 31 Jan 2001 14:26:10 -0000 Received: (qmail 25527 invoked from network); 31 Jan 2001 14:07:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 31 Jan 2001 14:07:57 -0000 Received: from unknown (HELO gw-nl4.philips.com) (212.153.190.6) by mta2 with SMTP; 31 Jan 2001 14:07:57 -0000 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA05152 for ; Wed, 31 Jan 2001 15:07:55 +0100 (MET) (envelope-from pascal.van.leeuwen@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma005149; Wed, 31 Jan 01 15:07:55 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA16278 for ; Wed, 31 Jan 2001 15:07:54 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA20383 for ; Wed, 31 Jan 2001 15:07:54 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890020401331; Wed, 31 Jan 2001 15:09:32 +0100 To: Message-ID: <0056890020401331000002L912*@MHS> From: pascal.van.leeuwen@philips.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 31 Jan 2001 15:09:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64cf8ab56881933755fbc0a5f4884b2b Status: R X-Status: N > BTW: 8 gates would mean 8*5=40 transistors in the critical path.

Correction: 8*3 = 24 of course since the transistors are not
all in series ...


Pascal van Leeuwen
Microcontroller Design Engineer
Philips Semiconductors B.V./ReUse Technology Group-
Interconnectivity & Processor Peripherals

Address: Prof. Holstlaan 4, WAY02/WAY229,
         5656 AA Eindhoven, The Netherlands
Phone  : +31 (40) 44361                         Fax    : +31 (40) 44115
Email  : pascal.van.leeuwen@philips.com         Seri   : pleeuwen@nlwayhp
****  Please visit our IPP web at http://pww.rtg.sc.philips.com/ipp  ****
Yahoo! Groups Sponsor

www.  
From Yann GUIDON Thu Feb 1 12:00:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00460 for ; Sat, 3 Feb 2001 02:26:20 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:20 +0100 (MET) Received: (qmail 10061 invoked by uid 0); 1 Feb 2001 11:06:56 -0000 Received: from hj.egroups.com (208.50.99.212) by 10.1.4.106 (mx06) with SMTP; 1 Feb 2001 11:06:56 -0000 X-eGroups-Return: sentto-1101623-2176-981025609-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 01 Feb 2001 11:06:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 11:06:48 -0000 Received: (qmail 1827 invoked from network); 1 Feb 2001 11:06:47 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 1 Feb 2001 11:06:47 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 1 Feb 2001 11:06:47 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA02892; Thu, 1 Feb 2001 03:06:43 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWM77; Thu, 1 Feb 2001 11:11:37 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7941C5.2DDB2385@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Feb 2001 12:00:21 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7c8357ee263898191eff78d87c39bb02 Status: R X-Status: N hi,

>De: David Sullins
>Hi.
>
>On Sun, 28 Jan 2001, Yann Guidon wrote:
>> hello,
>> David Sullins wrote:
<snip>
>> you're right, the manual is "under rework". it was not touched during
>> almost a year and now, some updated parts are not coherent with the old
>> parts. Since the time when Olicier disclosed his LaTeX version of the manual
>> (november IIRC), i have updated the parts 1 to 4 and you can find them on
>> the seul.org site. However, you understand that the 6th part is the most difficult,
>> so it will require a lot of work. It was even incomplete in v0.2.
><snip>
>
>I'm disappointed this is the only response I got.  I'm just asking for a
>definitive specification of any of the components which need to be worked
>on.  It's difficult to contribute without a little direction.

I understand that you are disapointed.
However, you can maybe understand that the manual is
a huge undertaking (3 people are working on it) and the
technical specifications are slowly refined and enhanced.
the old v0.2 was a step towards the specs, but we have hundreds
of other details to keep coherent.

We can't be too restrictive either : the argument about
the gates and the FF is already an example that too many
restrictions are not benefic (In this case, we speak much
more than we program ;-))
For example the real implementation of certain units
is still undetermined : SHL and IDU. The first implementations
will certainly influence the manual. ROP2 is already
programmed and it works. the latest LaTeX manual update
(see f-cpu.seul.org/manual) is synchronized with this
implementation.

If you come up with a good SHL or IDU, the manual will
take it into account (whenever we find time to update it).
The directions are rather obvious : scalability
(taking the global CONSTANTs into account), simplicity
(documentation helps), coherency with the other units
(you have 2 or 3 input ports and possibly several output
ports). You can even provide a configurable pipelining
option (the IMU is a good example because one can
tune the size of the slices).
you can have a look at the other units at
f-cpu.de/design.

keep faith (but not in compilers ;-P)
>Dave
YG

speaking for himself
Yahoo! Groups Sponsor

www.  
From Yann GUIDON Thu Feb 1 11:32:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00466 for ; Sat, 3 Feb 2001 02:26:21 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:21 +0100 (MET) Received: (qmail 432 invoked by uid 0); 1 Feb 2001 11:34:28 -0000 Received: from hl.egroups.com (208.50.99.197) by 10.1.4.106 (mx06) with SMTP; 1 Feb 2001 11:34:28 -0000 X-eGroups-Return: sentto-1101623-2175-981023919-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 01 Feb 2001 10:38:44 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 10:38:38 -0000 Received: (qmail 57024 invoked from network); 1 Feb 2001 10:38:38 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 1 Feb 2001 10:38:38 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 1 Feb 2001 10:38:38 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA00149; Thu, 1 Feb 2001 02:38:30 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWM57; Thu, 1 Feb 2001 10:43:24 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A793B28.A0FFA765@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Feb 2001 11:32:08 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 9f4e28e93349b2aa164c9090cbe4a7d2 Status: R X-Status: N Nicolas Boulay wrote:
> Salut,
coucou !

> Yann GUIDON a =E9crit :
> > > - a flip-flop could have 40 transistors (at least ~10). So 1= 0
> > > transistors between to flip-flop is.. euh.. funny :)
> > the example you gave (i think i remember your toy-CPU project) > > is very specific. FF in SRAM cells are 4 or 6 transistors,
> > FF for pipelines can be 6-transistors.
> > I think that some of the transistors that were added on your exam= ple
> > (correct me if i'm wrong) were used for compensation (of whatever= ),
> > boundary scan, testability ... only a few transistor are really n= eeded
> > to "latch" data.
> I realy ask myself, if you have soon forget the part "me" fr= om your
> "mime" courses. 10 transistors is the absolute minimum. I ho= pe you could
> believe that you could make some mistakes, some times.
Of course i make mistakes (even more often that i wish).
But my eyes wouldn't lie to me. i've clearly seen a pipeline FF made of aro= und 6
transistors (Alpha 21064) in a paper.

Even though you are probably more right than me on that matter,
don't forget another recurring point in our "art" : if the stages= are not
"balanced" or "matched" correctly from the start, we ha= ve bad big surprises later.
Don't forget too that, for a FPGA, a FF is not much to worry.
So please, think more about the stages than the details between them... ok = ? ;-)

> > > - a 0.18 =B5m technology have around 20 ps of delay propagat= ion thought
> > > nand gates. So why usual design don't run at 8 Ghz ?...
> > don't ask me that question.
> > Even though i know that some DSP in InP worked at 1Ghz in 1993. > I speak about CMOS process !!!!!!!!!!!!
he ok ok ok, i was just remembering old souvenirs...

> Give the name of only one
> million gates circuit made by an other technology than CMOS (or BiCMOS= )
> using other materials than Si (or SOI or SiGe, which always use silico= n) !!
dunno...
it's not my current focus now.
btw, this DSP was a 4-bit DSP.

> > it's probably a price/application ratio, 10 GHz is possible on > > small and specific designs and not on general-purpose consumer pr= oducts.
> > industrial scale is not prototyping.
> With a big fridge on it, maybe !
that too, but as you figured out, the InP DSP was so small (gate count)
that it probably dissipated a few watts only...
not bad at a time when the 286 was as common as PII today.

> > > - an simple full adder need 3 gates at least. So a 2 bits ad= der have 6
> > > levels of gates, usualy in carry lookhead adder you use bloc= k of 4 bits
> > > ripple carry adder on which you add the cost of the multiple= xer.
> > ?... there's something that i don't catch here...
> > are you saying that a half adder ("2 bits adder") takes= 6 levels of gates ???
> YES ! (ripple adder since the lsb bit to the last carry)

ok we need some drawings here :

1/2 adder is :
            &nb= sp;   ___
A ------o-----\\   \
        |      = ||   >--- S0
    ----+-----//___/
    |   |
    |   |      _____
    |   ------|     \
    |         | = ;     )--- S1
B --o---------|_____/

I count 2 gates, and one gate of CDP.
I let you count the transistors.


> > > The problem with such argument, is that your are going to ki= ll the
> > > credibility of the fcpu team because it's a no sense.
> > Although the means (that is : the "specification" of 6 = gates) is not
> > excellent, remember that we must make a compromise at one point o= r another.
>
> A good way is to see our goal. 20 pipelines stages, more, less ? Then<= BR> > after making some synthese you could say which unit need to be pipelin= ed
> more or not.
you took the problem with the wrong end. This way you end up with a MIPS. Each unit has a different nature and complexity, so you can't arbitrarily decide that ROP2 will be 20 stages (1 FF per transistor ???) etc.

The pipelining is decided unit per unit, with the goal to make very
short and simple stages. It is not decided at the higher level.
To keep the stages coherent, the guideline is to express the complexity
with 4-in gates, and roughly 6 gates in the CDP. Now this can change with t= he
implementation, but it was known from the start.

> > First, we have to give a rough estimation of the core's complexit= y, and it is
> > often expressed in "gates". Second, when the complexity= estimation started,
> > we had a 4-input multiplexor gate FPGA architecture in mind ; it = was the
> > technology used by ChipExpress and seemed to be a good compromise= for portability
> > and efficiency.
> Yes, but it's change with the fpga used.
it doesn't change very dramatically ... all FPGA work with "gates"= ;. Some
are still with 3-in gates but that's all... there is no bad impact when 6-i= n gates
are used.

> So believe in compiler !
are you kidding ? i deal with compilers all the day (both C compilers and V= HDL !)
and i'm also subscribed (i don't know how it happened though) to the ESNUG = mailing
list (take a look at http://deepchip.com/<= /a> ).
HAving faith in a compiler is like having faith in a washing machine,
if it does the work correctly for you, you don't care. however when you hav= e
higher standards, or higher constraints (this is the case most of the time)=
you can't simply "believe in compiler".

> > So i agree that the specification is not perfect, but now what do= you want to do ?
> > unbalanced or unmatched pipeline stages ? do you know ANY UNIVERS= AL metrics
> > for calibrating pipeline stages ?
>
> There isn't.
thank you for reassuring me :-)

> But you could not say in a word : 6 gates per stages, and
> make a one stage decoder. You have to be constant.

ok ok ok i'll pipeline the decoder.
you wanted it, you'll have it !

> > now, another question : are there any remarks on the presentation= synopsys
> > i submitted ? did i spell something wrong or is something too unc= lear ?
> Just one thing to add about the OOOC. That's what is made in fact by t= he
> C6000 DSP family from texas (vliw with 8 instructions used), 3 types o= f
> units but different latency (3 for mul, 1 for an add) BUT each single<= BR> > unit have access to the register bank. So you have 8 write ports and 8=
> read ports !!!! (and 32 registers !). I had some question like "H= ow is
> it possible to write on a register without waiting or killing the
> pipeline with different depth of pipelined unit ?". The only answ= er
> found (by me, and one of my collegue, a specialist in DSP and computer=
> architecture) is to have for each unit, an access to the register bank= .

stop swearing by the only thing you know :-)
This kind of scheduling has existed LOOOOONG before the C6x. fortunately. look at some computers of the 60's... Tomasulo and scoreboarding techniques=
were already well known. go to your favorite loval library and read some old books :-)

> > read you soon,
> You just do it ! ;p
looks true ... :-)

> > > nicO
> > YG
> nicO
YG again

speaking for himself
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
=
www.
From Ben Franchuk Mon Jan 29 03:38:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00585 for ; Sat, 3 Feb 2001 02:26:57 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:26:57 +0100 (MET) Received: (qmail 16936 invoked by uid 0); 1 Feb 2001 17:07:09 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx14) with SMTP; 1 Feb 2001 17:07:09 -0000 X-eGroups-Return: sentto-1101623-2177-981047219-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 01 Feb 2001 17:07:07 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 17:06:59 -0000 Received: (qmail 16894 invoked from network); 1 Feb 2001 17:00:36 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 1 Feb 2001 17:00:36 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 1 Feb 2001 18:01:40 -0000 Received: from jetnet.ab.ca (dialin52.jetnet.ab.ca [207.153.6.52]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA01607 for ; Thu, 1 Feb 2001 09:52:33 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A74D7A7.6ABCE92E@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <3A793B28.A0FFA765@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 28 Jan 2001 19:38:31 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7958d1ce9736e2289b7fffbf2eeac756 Status: R X-Status: N Yann GUIDON wrote:
> > Yes, but it's change with the fpga used.
> it doesn't change very dramatically ... all FPGA work with "gates". Some
> are still with 3-in gates but that's all... there is no bad impact when 6-in gates
> are used.

The safest assumsion is 4 input gates and 2 input multiplexers.

> HAving faith in a compiler is like having faith in a washing machine,
> if it does the work correctly for you, you don't care. however when you have
> higher standards, or higher constraints (this is the case most of the time)
> you can't simply "believe in compiler".
The only C compiler I trust is Small C ... you get what you see.
Lousy code but it is small enoufgh that you can find bugs. :-)

> This kind of scheduling has existed LOOOOONG before the C6x. fortunately.
> look at some computers of the 60's... Tomasulo and scoreboarding techniques
> were already well known. go to your favorite loval library and read some
> old books :-)

Darn My library is closed...
Here is a few links I found on the Old machines.

A Tribute to Seymour Cray http://www.cgl.ucsf.edu/home/tef/cray/tribute.html
and few quotes from that page
----------
Seymour liked to work with fundamental and simple tools. Generally only a piece
of paper and a pencil. But he admitted
that some of his work required more sophisticated tools. Once when told that
Apple Computer bought a CRAY to
simulate their next Apple computer design, Seymour remarked, "Funny, I am using
an Apple to simulate the CRAY-3."
His selection of people for his projects also reflected fundamentals. Once asked
why he often hires new graduates to
help him with early R&D work, he replied, "Because they don't know that what I'm
asking them to do is impossible, so
they try."
---------
CDC 6600  (1st super computer)
http://ed-thelen.org/comp-hist/cdc6600.html
---------
(ebook)Computer_Structures__Readings_and_Examples
http://www.research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examples/
---------
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Yann GUIDON Thu Feb 1 19:05:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00603 for ; Sat, 3 Feb 2001 02:27:01 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:01 +0100 (MET) Received: (qmail 19589 invoked by uid 0); 1 Feb 2001 18:22:26 -0000 Received: from mx25.rz2.gmx.net (HELO jj.egroups.com) (10.1.72.125) by mxi1.gmx.net (mxi1) with SMTP; 1 Feb 2001 18:22:26 -0000 X-eGroups-Return: sentto-1101623-2178-981051658-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 01 Feb 2001 18:21:28 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 18:20:58 -0000 Received: (qmail 27482 invoked from network); 1 Feb 2001 18:12:12 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 1 Feb 2001 18:12:12 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 1 Feb 2001 18:12:11 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA25386; Thu, 1 Feb 2001 10:12:07 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWNYC; Thu, 1 Feb 2001 18:17:00 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A79A578.3B774BBC@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102011101.GAA28644@world.std.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Feb 2001 19:05:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1173040aab3693bd2521cb7238bb977c Status: R X-Status: N Ben Franchuk wrote:
> Yann GUIDON wrote:
> > HAving faith in a compiler is like having faith in a washing machine,
> > if it does the work correctly for you, you don't care. however when you have
> > higher standards, or higher constraints (this is the case most of the time)
> > you can't simply "believe in compiler".
> The only C compiler I trust is Small C ... you get what you see.
> Lousy code but it is small enoufgh that you can find bugs. :-)
exactly like with Turbo Pascal :-) there, you know that it blindly
does what you write (even the bugs ;-))
it all changed when they switched to Delphi :-(

> > This kind of scheduling has existed LOOOOONG before the C6x. fortunately.
> > look at some computers of the 60's... Tomasulo and scoreboarding techniques
> > were already well known. go to your favorite loval library and read some
> > old books :-)
> Darn My library is closed...
> Here is a few links I found on the Old machines.
<snip famous quote>
> CDC 6600  (1st super computer)
> http://ed-thelen.org/comp-hist/cdc6600.html
go to http://ed-thelen.org/comp-hist/ it has a LOT of other stuffs !!!

> ---------
> (ebook)Computer_Structures__Readings_and_Examples
> http://www.research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examples/
> ---------

how did you know i was refering to that ? :-))

> Ben.
YG

speaking for himself
Yahoo! Groups Sponsor
www.
From Nicolas Boulay Fri Feb 2 00:25:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00636 for ; Sat, 3 Feb 2001 02:27:10 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:10 +0100 (MET) Received: (qmail 29103 invoked by uid 0); 1 Feb 2001 23:23:18 -0000 Received: from jj.egroups.com (208.50.144.82) by 10.1.4.111 (mx11) with SMTP; 1 Feb 2001 23:23:18 -0000 X-eGroups-Return: sentto-1101623-2179-981069792-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 01 Feb 2001 23:23:17 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 23:23:11 -0000 Received: (qmail 18872 invoked from network); 1 Feb 2001 23:16:18 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 1 Feb 2001 23:16:18 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 1 Feb 2001 23:16:18 -0000 Received: from ifrance.com (nas20-36.vlt.club-internet.fr [195.36.170.36]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13584 for ; Fri, 2 Feb 2001 00:16:11 +0100 (MET) Message-ID: <3A79F076.2BD26DF7@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 00:25:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 42d054590c50ced04550a9ee06c487d1 Status: R X-Status: N coucou,

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > > > - an simple full adder need 3 gates at least. So a 2 bi= ts adder have 6
> > > > levels of gates, usualy in carry lookhead adder you use= block of 4 bits
> > > > ripple carry adder on which you add the cost of the mul= tiplexer.
> > > ?... there's something that i don't catch here...
> > > are you saying that a half adder ("2 bits adder") = takes 6 levels of gates
> ???
> > >
> >
> > YES ! (ripple adder since the lsb bit to the last carry)
>
> But who would use a ripple adder in a high end processor? CLA can do i= t in 2n
> gate delay's, redundant arithmetic much faster of course.
>
> The most you are likely to find in the basic standard cell library fro= m the
> foundry is probably a full adder though, you brought it up before but = I never
> saw an answer... F-CPU really needs some semi-custom parts, how is tha= t going to
> be handled?
>

Most of the time a "big" adder is composed by 4 bits ripple adder= .

> > Just one thing to add about the OOOC. That's what is made in fact= by the
> > C6000 DSP family from texas (vliw with 8 instructions used), 3 ty= pes of
> > units but different latency (3 for mul, 1 for an add) BUT each si= ngle
> > unit have access to the register bank. So you have 8 write ports = and 8
> > read ports !!!! (and 32 registers !). I had some question like &q= uot;How is
> > it possible to write on a register without waiting or killing the=
> > pipeline with different depth of pipelined unit ?".
>
> They dont just expose the pipeline latencies to the programmer anymore= ? Bah,
> thats what makes DSP programming so much fun.

You have to composed with it. An adder need 1 cycle, a mul 3. So if you
make thing like that :

1 mul r4 r2 r3
2 add r3 r1 r1
3 add r2 r1 r1
4 add r4 r1 r1

You will have very big probleme between 1) and 4) instruction because of the 2 write on the register r4. TI said that mul will be written (so the 4th will be lost).

>
> Marco
>
nicO
Yahoo! Groups Spons= or
3D""3D""=
ww= w. .com 
3D""
From Nicolas Boulay Fri Feb 2 00:47:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00639 for ; Sat, 3 Feb 2001 02:27:11 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:11 +0100 (MET) Received: (qmail 853 invoked by uid 0); 2 Feb 2001 00:06:12 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.111 (mx11) with SMTP; 2 Feb 2001 00:06:12 -0000 X-eGroups-Return: sentto-1101623-2180-981071071-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fg.egroups.com with NNFMP; 01 Feb 2001 23:44:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 1 Feb 2001 23:44:31 -0000 Received: (qmail 81094 invoked from network); 1 Feb 2001 23:38:16 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 1 Feb 2001 23:38:16 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 2 Feb 2001 00:39:20 -0000 Received: from ifrance.com (nas20-36.vlt.club-internet.fr [195.36.170.36]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA24423 for ; Fri, 2 Feb 2001 00:33:24 +0100 (MET) Message-ID: <3A79F59D.1CEDC286@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <3A793B28.A0FFA765@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 00:47:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: multipart/mixed; boundary="------------46949BC09FAA987AF553E574" X-UIDL: 390cb244256cc25eb9b9adc326e6f62a Status: R X-Status: N --------------46949BC09FAA987AF553E574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Yann GUIDON a =E9crit :
>
> Nicolas Boulay wrote:
> > Salut,
> coucou !
>
> > Yann GUIDON a =E9crit :
> > > > - a flip-flop could have 40 transistors (at least ~10).= So 10
> > > > transistors between to flip-flop is.. euh.. funny :) > > > the example you gave (i think i remember your toy-CPU projec= t)
> > > is very specific. FF in SRAM cells are 4 or 6 transistors, > > > FF for pipelines can be 6-transistors.
> > > I think that some of the transistors that were added on your= example
> > > (correct me if i'm wrong) were used for compensation (of wha= tever),
> > > boundary scan, testability ... only a few transistor are rea= lly needed
> > > to "latch" data.
> > I realy ask myself, if you have soon forget the part "me&quo= t; from your
> > "mime" courses. 10 transistors is the absolute minimum.= I hope you could
> > believe that you could make some mistakes, some times.
> Of course i make mistakes (even more often that i wish).
> But my eyes wouldn't lie to me. i've clearly seen a pipeline FF made o= f around 6
> transistors (Alpha 21064) in a paper.
>
> Even though you are probably more right than me on that matter,
> don't forget another recurring point in our "art" : if the s= tages are not
> "balanced" or "matched" correctly from the start, = we have bad big surprises later.
> Don't forget too that, for a FPGA, a FF is not much to worry.
> So please, think more about the stages than the details between them..= . ok ? ;-)
>
> > > > - a 0.18 =B5m technology have around 20 ps of delay pro= pagation thought
> > > > nand gates. So why usual design don't run at 8 Ghz ?...=
> > > don't ask me that question.
> > > Even though i know that some DSP in InP worked at 1Ghz in 19= 93.
> > I speak about CMOS process !!!!!!!!!!!!
> he ok ok ok, i was just remembering old souvenirs...
>
> > Give the name of only one
> > million gates circuit made by an other technology than CMOS (or B= iCMOS)
> > using other materials than Si (or SOI or SiGe, which always use s= ilicon) !!
> dunno...
> it's not my current focus now.
> btw, this DSP was a 4-bit DSP.
>
> > > it's probably a price/application ratio, 10 GHz is possible = on
> > > small and specific designs and not on general-purpose consum= er products.
> > > industrial scale is not prototyping.
> > With a big fridge on it, maybe !
> that too, but as you figured out, the InP DSP was so small (gate count= )
> that it probably dissipated a few watts only...
> not bad at a time when the 286 was as common as PII today.
>
> > > > - an simple full adder need 3 gates at least. So a 2 bi= ts adder have 6
> > > > levels of gates, usualy in carry lookhead adder you use= block of 4 bits
> > > > ripple carry adder on which you add the cost of the mul= tiplexer.
> > > ?... there's something that i don't catch here...
> > > are you saying that a half adder ("2 bits adder") = takes 6 levels of gates ???
> > YES ! (ripple adder since the lsb bit to the last carry)
>
> ok we need some drawings here :
>
> 1/2 adder is :
>            = ;     ___
> A ------o-----\\   \
>         |   &nb= sp;  ||   >--- S0
>     ----+-----//___/
>     |   |
>     |   |      = _____
>     |   ------|     = \
>     |       &nb= sp; |      )--- S1
> B --o---------|_____/
>
> I count 2 gates, and one gate of CDP.
> I let you count the transistors.

I send you a full adder (imagine cascading the carry with one of the
entrance on a 4 byte adder) and a "big" design for a flip-flop. I= have
some design about it but on paper (flip-flop used in K6, Strong ARM and
power pc). I could scan it if you want.

<snip>
> YG again
>
> speaking for himself

nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
--------------46949BC09FAA987AF553E574 Content-Type: image/gif; name="fadder.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fadder.gif" R0lGODlh3gHxAPcAAAAAAAAA/wB7AAD//3sAAHt7e73Wvb3evf////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////ywAAAAA3gHxAAAI/gARCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0BhEhhKtKjRo0aDKl3KtKnTlQQIDr1Y9KnVq1izapUadWBXjFO3ih1LtmzMr18zhjXLtm3B AiXhkgxAt67du3jz6t3Lt6/fv3URIB1MVG5atQTljlQsknFIxyAhf5TslmWAyoi9dlyLubNn n5c/V0T78bDo06hfhk4NMa3pzKxjyy65ejZD0qVt696tsTbvg7hzmyVM/PXv4wh9I9fM3KNx p4c5N0y6vPpA5daDOxcr/fltotaR/mOvrn07d6lqvYc/PX55+c1jo2uUvj51e+TvORY3Cri/ /8D7HYXefPXJdt9x+W2kHnQDzrdggWYd+FuCsMVX0IOtQciehhRS1ZZr5mnYmYS7deghWyCG KKJbJOpm4mhuyaciTgDUaOOKFLVo24sTYXhVivDtBMABBhB5AAAJCaBkQQII1KST6+koG48S +fhjg0HmBIABXHJ5JJJMDtTkk2SKGWWBVD5EH4pYZnnTll3GCSZBT0KJQJl31jnif3z26eef fAYooGBuYgbkdoIC6p+NNsbp6JxiLomnpHpiJqVAl6KW5nRWanXoZp2iBKejBkB6p5mTSipa ppmetqlC/msa2qaCQpJa6kFKkpkrnad+xmp2XcWqJnisfUqgkETKKeKv7jU3LHVTznqsTqNy aWpMjNaIE7MIaiYotLwZW6GW2b5pZJHXxsQtjiuKeyJvS0KJp0HVomvTuuxC6K5FoVY2aa+V DlSvtTVJOcDBA+Qr4r499utWwGOOidDABM9kMMIK6ystjMhBfGq89NpqLaOKlvwfwglnvK3J fgn2LXgOAxezvwZJDHJBFN9qMUQoq7xtTQwPu16u8/ZKb7JdaksTvj7vLNNawnIatcr1pgsT 07MFV5VAW7s8M0etCsd1leA2PXG5N2GdNaFjM0faqyCF7WZULxNrtlZqr+1s/rDOsq3a3YBn lHe0e3Ntd9tXB654RYMX63eKfPftktyLA964pm4PiNvXHVFeOVOUdRR6QpdnNLpGp0ckY9dv dx1R6hCNBztGs19Uu0W3V5S7bqV/LpLnvqvce/AfAU98vsMfD/ZLWtvN+tTK65R89IIL9bjm 3kpOPU/Tb2+R8WBhGbnfiHvfU/fmTwT+u+QHezj56e+EfvyxW69d5EHT73T9+sfNfOYAZBvn +kcbiayPgAQ5YJUuZDioect1CFyaASPYOQpaboIW7E0GzTa/DRZEgR60DwZDyDgSZqyDJgSh CX01whVGRIUutFQLY+gQGNKwLSgkoQ1vGKEZ8lAh/jv8IfdYRsQiGvGISExif4SImu4FkYlQ bIoTo0hF3vmQIU+soha5d8WFZHGLYGRItqxWwRd2MYxopEidAna0ItlrJFNMoxwxIjExOupI cDwj6ebIR4uw8SAUI2P1HtIz/vXxkBC5WUJyJsiLXOxgZkSkJBlSx4XkrFQkU2JfCvmQL04y hGu0o60a+T2eYcyQn0wlRYb0KFKWMpKoVKUsH1K1uegxObPMJS3RlkdYdrIkdSOOLhEZx5EM 0GXD5GMxRXJMwyUzjcnjZEiaqb1nQjGap2Sm2Kz5ud2p75YFQdl/vPYykHzFmxJB5+viwk6S qBMi73xIPLOCTUgac5rc/qTiMvFpznxGcZ/95Kc/fwjQbc5ooDEs6EH1g1CCgtMgWaQmcBp6 Q4UWaqEU9aBFGarNjLpwo7TqqEdT+NAPAtOYwSRAX0aqOJBOK6Ab8SRLPePScWG0hDO9W03D J9CY5lSnJU3gSXuqwZ82bafsuylOjSq8oF5nqAYtKlNPaEp7/pIkEt2YI6faVEJms4ZQvahU ucquRw5Ak3Qh57ei6lOyIq+qKbvqPcXaVrfiCKn80k9WTWrXuzoVU2Hl114h2le/+hKsWBUs 9OpaWAjhdTQpfZ9JZKpWQam1ser6KwIoCxqVLDYhEMTsSR5bGc6WD7KiTQlpWcSSZn42tRhZ /i0OW0LNwcJWqIdtiGmHyLLKBkivtw2JbBeXVdvCdrjEVWpwc6RZEALJfa557YfYutylyvW6 iEEL/toGN7Ls1biYRe5EtcvdvoEXKN+t7lgRG8t38Y1uiMtfZwZ7XruK90Jbc198q4k56qq3 vVjULKwAGJbx1Tcotj0wGuep2+aGNHtwga5XQivPdi4GfnpN6UoPwmCGdHghH1ZIiJ1y38Al 2CO7haaDKUjf4oV3xRFMr4sbW+K7tXjGaBxjAXMb4Bj7N7Zy3NK5XLlVHnuRxcot8gpDaUmk VUy4MO5fcXvpwkoqJJAgkWaDjWy+2p43xTiy8iJFRuSIaLnHAO4y/kdtScM/hozMmSzZmY/M ZfsQ0bf7Sc9ob+hmnJEZynXGJW92O0DpDjKGfSbIwJTmv0AfBMw54ayh8TvpQ4eRlUljc5qB +BvKhmpQLYF05XSsaexuGaWRLdvvUEK3uhXsxY4mbGL1XOrwiHqLNV6Il6l8JhpHmag2XV6B bq3FXA84yda1Naw3TTo+4bk4MC1jfYhdxRwC+8HCnvayTf20awN52NtmL9BEylhUaxdqlZ5s uE89bm+/ctblHVt3d1xYa0cb2bGukIEZmLZ1o7nd7mZuWKEro377Ot+enWu5e7pd/mb24Mx2 CXgl+kXIBfBnEOf2Wcz9sg0D03kPlKxM/qitTwEHFt8t9TedbTLx9JH8nyaH972j9/Jrxlzh Pw5ezZlo75wnlXo7F2LPUd6j+AXdoQhPyYmNXtg5c/omS3d507/KbprcmOmHHLFBxIlWP6V0 m1rnsIUbk+23jP0xZxeN0/cIdaJ/7ug8HDpdKZLulGdc3FZ3EAXhXtGbk5tsdX+7yp/O8lQr uKylMXzgpZ70uytoZhTeoNxnusNCH/6tja/33wWrQ79PtU/PFmawETj5/zpk1xksvelv4/bj qX6BzZHwhC9Pwynv3fPhI68A441ha8qY9Lj3kO73rdVhXn0lpI7N69WUOfhez+HJ/D3y3Uik Mvcw86Ailn6f/t/7fB4/JZjONGuWf3oCN7z73g+4SLBMJz0p8mNEk2Lw6c7AzaFb5L5Xf0gY aSaA2WleicZF2Ld6PJV4GsYnYyQyt1Ip7ud/diJ/A0iAeTVzJsF/RvOAH/OAASg/8yeB5edz +zdK/TeCGWg0Gyg9HeiBrNd6HBF+T+Yku5In8RJ/GLgU5KeCxTeBLFFLypeCOIgQ0od8vDR+ PviDBmF7EXSDP4iESViERgh9qkN74BaBn9R1LfN1o0dASlhtP+FaUqghW1hyPmF5KxSGMMcT gRd5qeeEYcR36AdaqlaGbEgViod/K8J3reZqZxhxtKV3VPWEbMeHrQVcmAeIjzaH/jqIbcti iIImiFABguLBVGEna7FjhaFHGDA1iWbnTvRGdpz4iRdmIFkRdY7FiIeIFaQ4haaIW1eif52m E89zf204ipunbDhhcfIGhTTkhsznioOWE7gIP1+4OLz4gb5oRbeoOe8zjMRIi7VYHUeHi/LV d6iIc73WdgE0PmBUjNPBcd9iheD4J7AIcvKmhkjXise4ipFYjc+ojtrGjunojr8Ij5Aoj8fB jStIgfZ4jVZhXMy4jyTmjPUIkLuBj7oWjwQ5GwZ5bCyYkMoXjuOEhXPnkIfEhBSZSqh3kbJ0 TIunkVEEeXbokZKkeCJZkiZ5kiiZkiq5kizZki75kmoWW3sNxBX/CJPK43zItHs6+YY2qUU4 WWD7lYM9+ZHNt5PTOJRCRB3bpzVIyUeb40xG2ZRzJB/2d24dKZUvoYmJkXaTAYqeGIpg+ZVi iXZeiZVmeZZomZZqqZEBAQAAOw== --------------46949BC09FAA987AF553E574 Content-Type: image/gif; name="dff_da.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dff_da.gif" R0lGODdhrgNWAfEAAAAAAP///wD///8A/ywAAAAArgNWAQAC/oSPqcvtD6OctNqLs968+w+G 4kiW5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH 5LL5jE6r1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ 6fkJGio6SlpqeoqaqrrK2ur6ChsrO0tba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHS09 TV1tfY2drb3N3e39DR4uPk5ebn6Onq6+zt7uzhEQLz9PX29/j0//ms/f7/8PMCC+dwQ1BaBx 0FVCMgsLOpzUEEZEVRPBVHyIcdFF/hYbTXXk8jGjyEEhUZQUdRJLypEs96wk8dJTTCozW9qc UxNEToNmdt78ycZnB6GXiDYxCjQpQ4T7eip9qgdpBqkQnUK9WofqBa2RuB7xijWsFLATyDYy OwSt2LVK1D4Q0LQMXLZ007h1MLfV3R956/ods5dB31WBewz+i7hLYQWHUy3e0Tix5CuPEUQ+ VTnH5cmco0gVsFmwBdCbMpMgXSH0AtTjWHdW8xm0assUZM92ZHqE7dq1ZZfz/Ro2iLnAIdwG fvusFOKu8UpA/ttA85HJY0zX8dny9QSqiwOornG59u7GXYOn1ne7Q+862GMfzlj9d7zTzyfK LeKwe9oN/tzbl6bff+QwxwOBPGS32naR7TcfT1EsqKBgEQ4ooUjpCVjChTsgKKF+8W2GYSH4 hQBifR86R2F/IXYzmHwvBJgDhyqmN55xpYn3lnk1vhUdfStq05iLLAT54wcy+iiddEIm6SAU x6HG3HE95ljQZUuiYGWR8MA3gW0MitbkE9V5eSWTrXWpJXr00RBamSUcGcGX/d344GhumikO eHdy012ao8XpZwVwIiknY3Q62RtchXI3ZW/rPAkDpBJxWV6LVwaaIZmabsrpoi6MSGmOlkop RKemnoqpXBnsec2YqaL43KsODMqdeovKSmKmuFIA6gd9ZkleqboGgqGntaAa/qKeuzKa2rII 0KrkbHI628GurIrQqwclSisftRxY6+0VK16LA7Jf6GOoqKteQO6f7FJLq7EHMBiuBs62OxSO JyYKZhD31jtFkfjO8Cuv8bR1wMHMVsruqkTKC6udKsAJca0eCrsCwAnrOy+5/g3hrcaI+iry Bk/OtlC2vD4bkat62mtpx9+a/LAHMlbcIX/+tiCyyjN3/KN3JafG8x6BDuyCy7Mm4HMEEbVs Z3LjGiizvdXSiOdUXOKsboPw1JNf0pPGYE+10ZIIpc3o5lp0HqkinXHUDDyNBN06Nyutttcl S7LXWW81HNexwl022223kFnhNMOdIOFrhxo3HrIy/n7Cf+7ZbQTmfyd6KuTRIrtp4KN2KpA9 oO+G5ekClM66qZF++jXrAalO+Yygyy6Q6y9+hbs8tGta+am9D09Psa5pTgTyli8p8N4m993i liTXPl6RivtqHeLSbwX2t4ID6vg8umVfRG6TD90lBpczXTf7dw+ePs1K1vq89zr/iGDFbaY9 VPeeR74CoeTkeuv6jpsK5jcN+O9/KkCfBcx3GgfGj18LQF5a3DcvCk7wXfSbX/0c1jibhQpi EMJa7MRnuN0FcHsPXGABz/acGb1vKo/DHvkuSLD8SJA3aNqMBYWgPPi5i4MfQpqAqDc3zxkr QBcTYYZk4C0BsvBnO7KR/sXS5cTTQLF8bAocEk4GgYSIsX0Jg1rXGiYxDAxgADxMowXWKCgG Fkd3BlzQBOC4tCducWJTBJwN91XH0MEQiw/AYx61uEcgdvFqEjDkDRAYRjE2zWk1DGSnPhgr DbARAJuMkxvfaIBOOo2Bg1xNKQnpgE2KUgFkGRq8+vhAUtZRRadcWCpD+YBW5hCHiQRhI3FZ LlQJCoWSc1QHVhmx8ngAmYc02xlpc6sKMHNjeryhSWAZxz/KkFnRvGMuTeDK5C1Sfaya5jIk dcw2UmmZ2dSWEIEWQ282M2y7vOYGpKhNJFWRR7/8ZjWt+QMIklONalonCMyJygoddGX5VBcJ /qU5zxS+bpYwwSZD3dlDisaznw3Q5S6/lwKBNmsDCE1GiUKwRkfyk5YfSGlJMehMDW4wlSmN qCwb6LVU4VOBNw0h0SDgUn8icot52SHLiCk2Y6qxpgBiaT3jYwNohfChRgInm6KHLYuWpac1 omoWx0cwrOLAhUNC0zuI9MgEjZWrGq1lv/L1z0iNzjbEqytcMcqwfSbznlYNq8W8VNfAKkyF BnVHzMoF1bU29ETR6+ZX6QlFseqkBlI9W2OFlCaPRtaWUa0kAHNWJe20R7TvWSw8s1bUbk02 rrsrakWZYtpBinVaqx1q9lyLHc/i1KmhNaAKVMpPJC4AuEKN6RUX/sbEtxaypJolH0iLSzY5 muhv9GrkS5s70ee+SbcpgBAJiNsM7crzpadNgSovaly3qretmxsuMJPI2qTacwYUs5V9m3hL TkJXooQFgkirNoLzNvUF5PVgCwpsgJthNq/tbQBCsSvf+cpAwcHSZ4Pda9PY7laRTxWuAhBM EBDDQMT5u5QQq8PcvgLUBPgpManympzrqniiHN6jhz8MFRETGL3eOyDnINrRGfd3uKrU8bMo K7ox/VieQY5vWWkaSiPX1jo3ZoCU0xFUHmRZArEZ4kxpCt4EC/lwVoajgP1IXy/+VJ1gTrGT N1xmNp75Bebz1paDc6BxRvfN3Y2AnN8b/kvY9nJsto2wg/WLaELjORP/VTRkDX1oOV+5xXp2 NH8/e0tJT3jRh1ox7PhcuV/OuZ2bfqql2QpWoCL6ynfldFEEvV3B3oOOZPZzmEcJ61Nrb1b9 oPWT73jrkLqa0bkewUcg3OdPp3nZpW6y+obMy2FXIjdoOfaYsaTrXTd7z85G468zJ+1XM/tN +0U1Xq0bZZ4WW9nchu+zv23rdG873JKgtoQreG1Qf9jMgCZ1u7O9wgxvNNnA/nOi6Uzvaa87 BNbWt94IOmoeA5yP48b3C4MH8X5rO+FdWfiULV5o3WDoz8EWOEc8HvBuezmCmtRvyVnM8apU 3Njl1vDiOGDw/kkjeebsBrm3dbiinM875srhOcNrrrffhQ51LX25yicubKNTk5xKBx7Tl+l0 cvuV6F6w9wkazgdKSz3l7kZEnY3K9agPPasmp4PY175xnx9CoFVO+w28DvO242TncD+53v/w 37rbfewUz/vT8fD2fyP8735otG8HPwW8a/3wd0g892SNecEywvGPhzwUJP9aytvB8oFWd99x U2nSev4oKH8sKxvPdwzsVPEdN3ViV48wwrda7nkgvb/RTHtIcP72uAe37rUKgElysfVhRL7a KTF84hc/2lBHvvLFyXykb/X4ioi+WqdP/cUbvuxRiT3wZZ/97qdemQ8Spl9AT3PG/sPB9xIv ffAf4f01iYnBlGyIZyfCXdEAf2wnellhfvaHftx3H+uXSU4ARs0nZhEogVNHgdcnE+lneuTX ewf4ewgoftDHgGZ1XBjzTnI3Rke2MchjgZyQOAHIV/JnbGQVBATkd1rzgqdXdJeHVGw2UGaC dnvFfyhITZpzECqIDS24gx/3emQjg/7VhM93flHYc/VGQy44J0nHWYZBdUs4hDBVhDCVfL+Q eWNIhmVohmeIhmmohmvIhm1YOj2Bhu6HhUBDOm5oOjDTF3bjf+xDhMAwe59ihTZYgCbxhD5A g2QnhR0Ydx+IeIUIhFs4QwUCiUIYgTWUMkc1WL7wh4gT/ogJOIhf54gHEoqT54mCeH+IWHmj aEr244MgIzcmOIF7GIsrOHfOx2KdmIgUCIi4OFaqGH+mWIrV93Vh54tZOFIjuDMZpXInOHWP U4S0SAibGHnah4qId4PAyIjZuIFW04NN8IB5dIKYc4lDCI2CII1jQY2F5xLXGIzauIjbeHFK JU2sFnKAlEuSVIHMKIGyqIm2yARgh4N7l4HtOIUFaY3cKI9ARo9A52uRJA9lREzliH/+uAQA eYpux465WI3veJDxWFgtB34wqIHTKJKht44DqZHqKIxx4BPohHMhmY4QSBkxeW/wSJCKWIMX iZEIqX8tBZOfKJNWYJEr+QY+/nGOOUmURYlJ34d1Wbd6R/l5NDmMfWCUFEmKSekGLclbP6mS KekEQwltHXmT9ceR8FZ+PAlgXImUXsl6JZlqJ4mNHmiQZmmTP2dgarmWcomObvloZxmXOLmR dCmWPyd4eMl7eukZUplvo5eRiBmYmOaX71aYTvmUVpkEYAlpg+mYXIaBDicHLVmYq2aYlDiW UcmXW+lJCQkZVdc5I0mWr/mYRPRl7GcYrNmah6ma5jWausiW/6iY4KNkg/OD5dWXpLmZuBaQ eCM1S9YeN3YZEqlxeAmVT4CZBVQmkjKcdfecjQmYXVk/JtaAPyh423kEC8lx0/mVv2lFd3mF PZlA/lcFZ2B4nEGJlSvVee3pnkYVmuQ5BHdmmOjZlkDJgy5yUsboaW9WldyZl2h5nwnVQZFI Y/FpnLu5fChJkgI6mw0KoRNSA+HCn6XJmQo4cKpnoBp6YYK5mNBJoRPanel5msr1oDOkWh2a mRPYmy/qeksZo5szo7ZHcFy4osZnoXuJoSPKlHiyYCGYogq6fcnJg8R3WI+IoqHmmkHqXydk h7JGjVSBTlRjnxE6JJximbi5oB6pUKllpLUWpoJkpUIKGFt6abTkVWA6pUwaok6aoTnjYwcq oW2ae0vRdlz6SWlap4s5pkBan1KKmusZlpDpp5dpFYMoqCK4p3RaqH8J/pveyaD6V6k16qiP +hWRWqU2SkUfaaKraKmfuns3epWl6p7siZ9qKqug6qZiUJ2kqqPSt6Oo6ql9mqMtWpO5uqsk CqO+eqm0GlCiSqa4uqlp+aolim2DpoTzOZUadikgkqrHiqw9oKK/OKphKF2DmkHZaqyHKp9z +W66SpvQaqjluq1XWga3Cq4N1S7TlTq+gT6vAqDVem6wqpoA40DD+a53+qaBmkJwoyOpQ5zk aqfIqZNrdqqfRC34SqMDG6rxCqdbczTEobDE2qirSq3j50zUwz/RGrHaarGKBaiSijbCdXX1 mK+tGrIyi4dvI16M+p4fm7LcqqyIykq9Rjv3/no6QEsmvMqwQ5qpIcUPSie0yOIPVseu7rqz pbWy38qQEaSdRquzDUuf3nizRfSjOdurU0u1BVukI7uxJ8pIHju2SNuk+3eyPXgvznq0ZHt3 PXuuM2Yr8rgsrPG1ZvqrSWsEGlKsvDWxpBGwdltjZmu1/OU8gJIuzrkbMWuSIHoEMBK1dOul VOqjilu2tqqe+5ah5iGmdMskioKyb3l0XEsDWeddn1O0bNsgqCu1Juu5PIuxOBpxhWtgBSoa f5uafGquLIoDu6u1pNUt2Aq8X7q1t9uZQhm6GIazR6quyIVzRca8swqywGoDBdYnz4pFQYe9 sdq8zounM4mj0cm7/rsKnsfEbwd3vKo6vLypZXnKvi92vUJHvtprvs9bBfLKZNnLUp2aTsY7 rnVruV3bA95rTAT8kgYstvLbv+cLvbrLVNO7roSaAST3UiKDKYfosFp2wQIMviScccFWMgLb v91KgI1rbrGrwRkHv/EbtmrDi8SbBC4zpwWsvgdcvhOMriARvYALVamFv03HwC/CKZiXwEXw jYpyxE0ZvEmzxP0AxJUbBgAcp8jLKEnauZyrE8WIw1+kTFjlxcLbrul7xcsqxGr8pGk5W9ha sanLZWJMv0vgu5LVo9Jaw2+7xoGrGEN8AK6rUO8TpZkLbPJmv6prw0lIsAuMYK/rw+/J/qHu q8hTXLsu/Md+nMWCLJqYHLG4pataUlMQTMOM3D83fMfF28NZyKFZ4qBLpb8xjMqPvMmsqxKe PMgDh1kEakLsZMrU65msqsmty8v7872T/MCtLMzD7LO3jKmBrMaR7K/ry8ULpWmy6czc68Yo QM1xq8wDjFIuZ2TjGc3QLLhZoMV+Jpxv3Dh+Msvv8ir6Or8H1s60/FfjHMzbVI+2jM7E/L+e 7J+LasKnrEmUaTu2CTxYPLMjNsIlvL8FvcEI/c4KvdAA/c/PfC663McTictWoMJEmtFNnMvd nMbq99FVENKJOdLnvAXr/MU56NJZsNKm2dIYfaHFjMbhkdJU/lDT1HnTJI2+Z5uo5ljPLrqA Qd3QAW3SNIt6PZ3TtajU3DzUOl3UgbCvVS3VU83JFsHRwerRbvvSPM3V/rzRTc3QYT3TJZ3U ahmaQl3BRO2OTy3WWsDCtQqTL6uyjMvGUWUJWR3XZmeYm3u3wlqhVj3XMg3XNEHWXEm4ez2J ZCTXQdzYix3VhnDXj1K9V326P/2tK5jZQA3VIr3Vjl3IIvpWb11VaO2tVDjaLN3Wpk3QZTpT qr29qwzZtVfX6lzZeZ3BZTmbti3WoP3XRx2ggo2XLknbGizcKUncCvfaNo3cbp2b/Jquzfy5 Gh0jxR3doh3bP3keby0UyYy7kw3c/ptn3L6J0tStzSJrl7Pdes8Ngt2N1NMt293o1Is8rPE9 g9y922xt360hh1ooP/mNz/uNg/Itc/+t1Zi9DA95xx8BSZDxcK393pBb2Oa93L291JctIsow jvPqhbFsj4jVN6vbrBj+V84C0xT84fR93KVdDHrobhWhNJqhQ9MKsYPqt8vS4g/73TgN2wFO DBdh5Mwa3s1tzb6kQKoczsfYHB4GwsoHwhxeFk7u3UQ+DEeObxuxPBI0z+1ix0/+ioisgxCu 3ZQ15oCwE2te3zJe5K6ZiSQeJ3Vl0biCKnZ+m+kFu5qSpX8O6IEu6INO6GyI3sjA5Wkewc/E xycue1i+/ugyReZYOue4jRBuDntViObnENpYLecdkeT6yXL3BOlTw55S3oRUjulU2eSOPA6d zuZynnwXceMmrmaUTsQq3ruyMuWGuOph1+qbbg6wDnjuw+WVHukLm1aObuviakl+PQ3EvgvS TpUhnugirrbLa24QnQAUneLcvlznnQzUngvkToxo7ovmwhesyM4zfNKy20/m2dXNYO63UO/h YDz2Ie8HbroXsO8h/Az3XgsC/w1H9B//DsqnTVLijuhrQfDeYB/4gvASTT0Tz9oD7/CDfYyy bPERXc0T7e2WHQwPLwskzyciOLjwjX3SYPKw0PJAouspv9kXy/IZn9yMLvP9/v6nAmjz7K3w ZKzzOw8NL68QGo/d19s2k9nxGt6PYkH02IC5AcbMLbsC+7zaNe/0Rv/x4yzBJbD0fd3wWX/z 4OyTWPD1YH8MT88Kam8N2l5IWXD2ecsMbE8Rg21nDx0FA+3ezkD3jlHWRh3tPf/3mY71YdH3 g9/CQy/4iA+XPC/2jA/sgf/4kB+Zij/5lK+ZfL/4mM+Ykm/4nF/5Ab/5oC+QhY8Vh0/6a20M qO8RWr/21MD6pRD7z+D2ii36l+/bZH+Bnn/6rq/kkW/6VzH7znDIpDD88zf64IdWsg/7yT99 sDwKx6+UuB+SvgsK0p+Vzl985L37wQ8V2K8Myh0m/pb/+WPfgJ1G/r1vDuruA8rCgs1P/UWe if5DVhM+Ws6+4I5f/mE/r5j5jThOAPAxU0SBoZOTVntx1hsF/sFQHMnSpLxTXdnWfeErjena vtEknSUeaTIR3AUIYiyKx+GS2Ws+oVGTT1q1XrEHapbbXW0BYK2kGFRay0bg2cD2vjdi+Jwu ktfxefxd33+D78DSzAabCj+EFvwWwxgdHxshJSeH+Cgva7YCyUQEAj5BQ0VHSUsDIFBT3UYK VVVNYWNlZ2lrbW9xc3V3eXt9f4FvMYeJVSyLkU9AO5YdBENWDU0Sf5Kzjq2ztbe5X7C7wS1m Nh0OK6KfzM3a0tDDM9/j/uXn6Z3r78UNyBXUy/uZ/p0rc8Ydvi8GESZU6OjbwmI+dlR4to5L QDKtUDn0ppFjR49PGn6U9ElLxBzlMBSMYhFJiAEDRHIIGZNmTZtjbmYTVTJUEAsqpbA8AHQC TABGc06YmZRpU3xLnYJzpaqOUKIXkEbFqZVrV4RQvYZtwfKqhaxdwYpVu1ZPWrZvERERilWs W7h38Uaxm5cvSgplsb48q3VvX8OHWRRGzFcd4MVbH0eWbEPxZLaHHE+ubJlz582dvWIEjeHz aNOGS59u2m6uZ9WvYTuJbTlJ6w8v1aaevZswb8lrbHMwOjiqbt/HbxpHzpGaDeJOlS+X3jH6 /vSEwUc8h26de9/q3R9rZ/odfPl45M3jFSw+Kfr073XCl193fv329vE3dZ+fv5/9/QFc5L8A CfRiwAIR/CPBBeU5kMEHpXAQwgnhodDCbSS8UENjNuyQmAw9DPEDEEUsEQQSTUxRKRVZ3KPF F7FAEcYZ9aHRxiZkvLHFHHX0kMceTfwRyAuFHPIE7Ewr0kgIlVySlcxOa9LJBKWcMq4HkLSs SisD3JJLn4bKMjIvv8yPzDLPaUm6M9Gcj802/VLzuDfhTI/OOoeaAMrH7sSzuz7xbExMvgD1 c7pC4fxnT9QMbbRGR/2waNG8EIWUt0rRtGrQtTC1NLZOTZuKqjnm/pr0LVA9VQ3V4kiCjJlm FBFoUxdsMzW3VOtcVb+tAOmAn5RspRUajJqDS1dcXdMQokcVWLYaQirqhLUwCUW2zWNz6tUe X5/VoFgoxFTCjWA9GsVaLrFNTrZmdYiVg28BmiaaWTky99wp07VJW3ZdfaCTYGARNRUViBUV 4IMRTljhhRlu2OGHIY5Y4okprriXDvfVoadfESGXhE2/pVcje+8tGb6MmfnrXY9LCBc4Odki 2eSZwUN5jFY5BlbklqWVk+V6d6JZaO6c1RbnbmX1Art5Mxra6aevwHmcdSNB+qKdCe7YJfag 7tprEoIOI+yfBIYXi1KRHO7rtdleS1MTs7huW+65PZJ01rjpzltvgxTdGe+9AQ+8G0FXWE/w wxGXx5yfE2/ccan8eVzyyWOalvLLMV9oIKwTwC3zz0FXmp0a1A7d9NPBZdws1Flv3QbOK/jb 9dlpp0P22nHPHQrDde/d99+BD1744Ykv3vjjkU9e+eWZb97556GPXvrpqa/e+uuxz1777bnv 3vvvwQ9f/PHJL9/889FPX/312W/f/ffhj1/++emv3/778c9f//35h74AADs= --------------46949BC09FAA987AF553E574-- From "Marco Al" Fri Feb 2 01:34:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00642 for ; Sat, 3 Feb 2001 02:27:15 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:15 +0100 (MET) Received: (qmail 26012 invoked by uid 0); 2 Feb 2001 00:27:49 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx09) with SMTP; 2 Feb 2001 00:27:49 -0000 X-eGroups-Return: sentto-1101623-2181-981073664-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 02 Feb 2001 00:27:48 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 00:27:44 -0000 Received: (qmail 24769 invoked from network); 2 Feb 2001 00:26:08 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 2 Feb 2001 00:26:08 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 2 Feb 2001 00:26:07 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 0F9E32933 for ; Fri, 2 Feb 2001 01:26:07 +0100 (CET) Message-ID: <001a01c08caf$f150be60$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 01:34:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 30c2b0071cb092f85e4975022594df34 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> > The most you are likely to find in the basic standard cell library from the
> > foundry is probably a full adder though, you brought it up before but I
never
> > saw an answer... F-CPU really needs some semi-custom parts, how is that
going to
> > be handled?
> >
>
> Most of the time a "big" adder is composed by 4 bits ripple adder.

With that I assume you mean they compose it from 4 bits adders with ripple carry
propogation used for the carries from those 4 bit adders? Is using 4 standard
cell full adders and yet more cell's for the carry lookahead  a good way of
building those 4 bit adders though?

I have been able to find only one company offering foundry services which gives
specs on their standard cell libraries, samsung, and all they had was a full
adder. Is that the common case, or can you expect to find speed optimized 4 bit
CLA's in libraries?

Also Im not so sure that redundant arithmetic isnt used, take Intel's double
clocked ALU for instance. And mr. Glew's case for sum-addressing using redundant
arithmetic is convincing.

> > They dont just expose the pipeline latencies to the programmer anymore? Bah,
> > thats what makes DSP programming so much fun.
>
> You have to composed with it. An adder need 1 cycle, a mul 3. So if you
> make thing like that :
>
> 1 mul r4 r2 r3
> 2 add r3 r1 r1
> 3 add r2 r1 r1
> 4 add r4 r1 r1
>
> You will have very big probleme between 1) and 4) instruction because of
> the 2 write on the register r4. TI said that mul will be written (so the
> 4th will be lost).

Why a very big problem? Its bogus code, it doesnt matter if it gives bogus
results in r4 IMO... unless you get a short circuit I dont see a problem,
depends on the physical implementation, it only becomes a problem if you dont
want to expose pipeline latencies. (personally I like binary translation for
backwards compatibility)

Marco
Yahoo! Groups Sponsor
From Michael Riepe Thu Feb 1 14:25:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00645 for ; Sat, 3 Feb 2001 02:27:16 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:16 +0100 (MET) Received: (qmail 3907 invoked by uid 0); 2 Feb 2001 00:36:42 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx03) with SMTP; 2 Feb 2001 00:36:42 -0000 X-eGroups-Return: sentto-1101623-2183-981074196-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jj.egroups.com with NNFMP; 02 Feb 2001 00:36:41 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 00:36:36 -0000 Received: (qmail 81734 invoked from network); 2 Feb 2001 00:35:56 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 00:35:56 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.91) by mta1 with SMTP; 2 Feb 2001 00:35:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00546; Thu, 1 Feb 2001 14:25:16 +0100 Message-ID: <20010201142516.14977@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A7941C5.2DDB2385@mentor.com>; from Yann GUIDON on Thu, Feb 01, 2001 at 12:00:21PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Feb 2001 14:25:16 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a8a5e14123ddee130ed4f9bcd65b2561 Status: R X-Status: N On Thu, Feb 01, 2001 at 12:00:21PM +0100, Yann GUIDON wrote:
[...]
> For example the real implementation of certain units
> is still undetermined : SHL and IDU. The first implementations
> will certainly influence the manual. ROP2 is already
> programmed and it works. the latest LaTeX manual update
> (see f-cpu.seul.org/manual) is synchronized with this
> implementation.

I'm working on the IDU... the SIMD stuff is pretty hard to get right.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www. .com 
From Michael Riepe Thu Feb 1 14:08:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00648 for ; Sat, 3 Feb 2001 02:27:17 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:17 +0100 (MET) Received: (qmail 882 invoked by uid 0); 2 Feb 2001 00:41:09 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx17) with SMTP; 2 Feb 2001 00:41:09 -0000 X-eGroups-Return: sentto-1101623-2184-981074216-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 02 Feb 2001 00:38:04 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 00:36:55 -0000 Received: (qmail 82362 invoked from network); 2 Feb 2001 00:36:10 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 00:36:10 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.91) by mta1 with SMTP; 2 Feb 2001 00:36:08 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00501; Thu, 1 Feb 2001 14:08:50 +0100 Message-ID: <20010201140849.37177@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7823BF.46752B33@llandre.freeserve.co.uk> <3A741D69.3AEBEFBF@jetnet.ab.ca> <3A785EA8.C7EA653B@mentor.com> <3A7474D8.D154D3FC@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A7474D8.D154D3FC@jetnet.ab.ca>; from Ben Franchuk on Sun, Jan 28, 2001 at 12:36:56PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Feb 2001 14:08:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] intel x86 etc. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b40d3137c80fb466cb744660b0ff196c Status: R X-Status: N On Sun, Jan 28, 2001 at 12:36:56PM -0700, Ben Franchuk wrote:
[...]
> I was thinking also of a real sticky problem with the current crop
> of software - Heap fragmentation. That is where your heap of free
> memory has so many holes in it that it becomes useless. You can't
> move stuff around to get the space back because the OS has no track
> of what POINTERS in memory need to be modified. Have there been any
> new ideas in computer science how Software,OS's and Cpu hardware needs
> to work together to handle lost and moved pointers?

Just a very old idea -- garbage collection.

ftp://ftp.cs.utexas.edu/pub/garbage/ has some papers about memory
allocation strategies, different kinds of GC mechanisms, and so on.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.
From Ben Franchuk Mon Jan 29 10:04:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00678 for ; Sat, 3 Feb 2001 02:27:23 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:23 +0100 (MET) Received: (qmail 26165 invoked by uid 0); 2 Feb 2001 03:41:00 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx21) with SMTP; 2 Feb 2001 03:41:00 -0000 X-eGroups-Return: sentto-1101623-2186-981085244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 02 Feb 2001 03:40:57 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 03:40:43 -0000 Received: (qmail 76338 invoked from network); 2 Feb 2001 03:40:42 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 03:40:42 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 2 Feb 2001 03:40:41 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA04759 for ; Thu, 1 Feb 2001 20:32:36 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A753205.3E9B5419@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 02:04:05 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Custom Logic Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d81166ccb6c877096a66a5c841b7ee49 Status: R X-Status: N Taking a look at what little free logic libraries there is out there
I noticed a lack of updated software. (1998?). The logic cells
are simple gates and Flip/Flops and latches. Any adders are ripple
Carry. Libraries are .5 micron and 1 ns - 2 ns delays. (.2 micron
is now standard) Off hand it looks like if one needs custiom logic for the F-CPU
one is going to have to find/create better Free libraries.
Ben.
Note The delays given here are ball park.
Wanted "CMOS transistor design for DUMMIES" :-)

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From "Marco Al" Fri Feb 2 05:33:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00693 for ; Sat, 3 Feb 2001 02:27:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:27 +0100 (MET) Received: (qmail 18670 invoked by uid 0); 2 Feb 2001 04:24:53 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx02) with SMTP; 2 Feb 2001 04:24:53 -0000 X-eGroups-Return: sentto-1101623-2187-981087887-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mr.egroups.com with NNFMP; 02 Feb 2001 04:24:51 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 04:24:47 -0000 Received: (qmail 32471 invoked from network); 2 Feb 2001 04:24:46 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 2 Feb 2001 04:24:46 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 2 Feb 2001 04:24:46 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 27F9E29A0 for ; Fri, 2 Feb 2001 05:24:45 +0100 (CET) Message-ID: <002f01c08cd1$47c39f30$29e65982@student.utwente.nl> To: References: <3A753205.3E9B5419@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 05:33:24 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Custom Logic Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d66e1d9aaddee0bed63185c6b80f0017 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>


> Off hand it looks like if one needs custiom logic for the F-CPU
> one is going to have to find/create better Free libraries.

With what though? The free tools for mask design arent up to spec anymore
either, important for .18u and critical for anything below, or software for
physical simulation of resulting devices for that matter AFAICS.

And at a little higher level... what about timing tools? Is there anything
recent? (as has been said, wiring delay is a big factor nowadays... and
interconnect coupling has become much more important too lately)

IMO you need a lot more very expensive software in the tool chain than just for
synthesis.

Marco
Yahoo! Groups Sponsor

www.

From "Marco Al" Fri Feb 2 01:42:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00702 for ; Sat, 3 Feb 2001 02:27:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:30 +0100 (MET) Received: (qmail 11707 invoked by uid 0); 2 Feb 2001 04:31:20 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx13) with SMTP; 2 Feb 2001 04:31:20 -0000 X-eGroups-Return: sentto-1101623-2182-981074091-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 02 Feb 2001 00:35:56 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 00:34:50 -0000 Received: (qmail 75826 invoked from network); 2 Feb 2001 00:33:52 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Feb 2001 00:33:52 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 2 Feb 2001 01:34:56 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id F3C5F2933 for ; Fri, 2 Feb 2001 01:33:50 +0100 (CET) Message-ID: <002401c08cb1$05dc7d50$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <3A793B28.A0FFA765@mentor.com> <3A79F59D.1CEDC286@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 01:42:29 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8b9d22ba8017e9c02389b1826434377e Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> I send you a full adder (imagine cascading the carry with one of the
> entrance on a 4 byte adder) and a "big" design for a flip-flop. I have
> some design about it but on paper (flip-flop used in K6, Strong ARM and
> power pc). I could scan it if you want.

IBM has some schematics for the design of the latches used in the G4 (PowerPC)
online at http://www.research.ibm.com/journal/rd/414/sigal.html

The actual schematics is http://www.research.ibm.com/journal/rd/414/sigal8.gif
not really a flip-flop, but still interesting I hope.

Marco
Yahoo! Groups Sponsor

www.  
From Ben Franchuk Mon Jan 29 11:31:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00705 for ; Sat, 3 Feb 2001 02:27:31 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:31 +0100 (MET) Received: (qmail 4712 invoked by uid 0); 2 Feb 2001 05:10:09 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx05) with SMTP; 2 Feb 2001 05:10:09 -0000 X-eGroups-Return: sentto-1101623-2188-981090457-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 02 Feb 2001 05:07:43 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 05:07:36 -0000 Received: (qmail 78769 invoked from network); 2 Feb 2001 05:07:36 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Feb 2001 05:07:36 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 2 Feb 2001 06:08:40 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA09455 for ; Thu, 1 Feb 2001 21:59:29 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A754664.92ECFC3@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A753205.3E9B5419@jetnet.ab.ca> <002f01c08cd1$47c39f30$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 03:31:00 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Custom Logic Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 02a4facf19e51005659141b5a2db9029 Status: R X-Status: N Marco Al wrote:
>
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
>
> > Off hand it looks like if one needs custiom logic for the F-CPU
> > one is going to have to find/create better Free libraries.

Most of the stuff is the FREE or DEMO stuff out there.
For example the Alliance package I down loaded to play with.
Right now I am designing a 24 bit CPU in a FPGA ( If you follow
my URL) . While I don't have the resources to do a TTL or Custom
design (got $10k free for 25 chips?) I would like to compare the FPGA
speeds with both designs. A timing spec to 10% is ample for
a autorouted/macro cell design here.

> With what though? The free tools for mask design arent up to spec anymore
> either, important for .18u and critical for anything below, or software for
> physical simulation of resulting devices for that matter AFAICS.
>

This really depends how far you want to push the envelope.
To me 999 MHZ and 1001 MHZ is the same speed.
I'll design for the best speed I can get and not lose sleep
over a .1% speed difference.

> And at a little higher level... what about timing tools? Is there anything
> recent? (as has been said, wiring delay is a big factor nowadays... and
> interconnect coupling has become much more important too lately)
>
> IMO you need a lot more very expensive software in the tool chain than just for
> synthesis.

I know of a FREE tool that any designer can use. It is called a <drum role>
...... a Brain.

> Marco
>
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From "Marco Al" Fri Feb 2 07:00:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00708 for ; Sat, 3 Feb 2001 02:27:32 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:32 +0100 (MET) Received: (qmail 30582 invoked by uid 0); 2 Feb 2001 05:51:43 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx10) with SMTP; 2 Feb 2001 05:51:43 -0000 X-eGroups-Return: sentto-1101623-2189-981093097-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 02 Feb 2001 05:51:41 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 05:51:36 -0000 Received: (qmail 57958 invoked from network); 2 Feb 2001 05:51:36 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 2 Feb 2001 05:51:36 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 2 Feb 2001 05:51:35 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 70BB529C0 for ; Fri, 2 Feb 2001 06:51:34 +0100 (CET) Message-ID: <000501c08cdd$68d207f0$29e65982@student.utwente.nl> To: References: <3A753205.3E9B5419@jetnet.ab.ca> <002f01c08cd1$47c39f30$29e65982@student.utwente.nl> <3A754664.92ECFC3@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 07:00:13 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Custom Logic Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 495016b55775df598d935970bd60e41a Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> Most of the stuff is the FREE or DEMO stuff out there.
> For example the Alliance package I down loaded to play with.
> Right now I am designing a 24 bit CPU in a FPGA ( If you follow
> my URL) . While I don't have the resources to do a TTL or Custom
> design (got $10k free for 25 chips?) I would like to compare the FPGA
> speeds with both designs. A timing spec to 10% is ample for
> a autorouted/macro cell design here.

When you said "for F-CPU" I assumed you meant for VLSI.

> This really depends how far you want to push the envelope.
> To me 999 MHZ and 1001 MHZ is the same speed.
> I'll design for the best speed I can get and not lose sleep
> over a .1% speed difference.

You will simply not be able to go below .18u. I doubt F-CPU will be able to be
finished fast enough for that 2 MHz difference to be realistic.

> I know of a FREE tool that any designer can use. It is called a <drum role>
> ...... a Brain.

Intuition is not always a usefull guide, and I cant do the needed numerical
simulations in my head.

Marco
Yahoo! Groups Sponsor
www. .com 
From Ben Franchuk Mon Jan 29 12:31:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00711 for ; Sat, 3 Feb 2001 02:27:33 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:33 +0100 (MET) Received: (qmail 19107 invoked by uid 0); 2 Feb 2001 06:08:00 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx07) with SMTP; 2 Feb 2001 06:08:00 -0000 X-eGroups-Return: sentto-1101623-2190-981094076-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 02 Feb 2001 06:07:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 06:07:55 -0000 Received: (qmail 90476 invoked from network); 2 Feb 2001 06:07:55 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 2 Feb 2001 06:07:55 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 2 Feb 2001 06:07:54 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA11976 for ; Thu, 1 Feb 2001 22:59:46 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A755485.F1583C8@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A753205.3E9B5419@jetnet.ab.ca> <002f01c08cd1$47c39f30$29e65982@student.utwente.nl> <3A754664.92ECFC3@jetnet.ab.ca> <000501c08cdd$68d207f0$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 04:31:17 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Custom Logic Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fa4b45c038a26eb3c350a9697b40182d Status: R X-Status: N Marco Al wrote:
>
> When you said "for F-CPU" I assumed you meant for VLSI.
I did mean VLSI. I am not that foolish to go with TTL for the F-CPU.
It just I am not looking the best available stuff but what I can get off the
web in  a few hours leisure time.
 
> > This really depends how far you want to push the envelope.
> > To me 999 MHZ and 1001 MHZ is the same speed.
> > I'll design for the best speed I can get and not lose sleep
> > over a .1% speed difference.
>
> You will simply not be able to go below .18u. I doubt F-CPU will be able to be
> finished fast enough for that 2 MHz difference to be realistic.

Right now I think .18u the limit for the next 2 years.

> > I know of a FREE tool that any designer can use. It is called a <drum role>
> > ...... a Brain.
>
> Intuition is not always a usefull guide, and I cant do the needed numerical
> simulations in my head.

I got extra slide rule if you need one, Only $1.00. :-).

> Marco
>
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.
From Michael Riepe Thu Feb 1 14:21:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00714 for ; Sat, 3 Feb 2001 02:27:34 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:34 +0100 (MET) Received: (qmail 26439 invoked by uid 0); 2 Feb 2001 06:10:51 -0000 Received: from c9.egroups.com (208.50.99.230) by 10.1.4.119 (mx19) with SMTP; 2 Feb 2001 06:10:51 -0000 X-eGroups-Return: sentto-1101623-2185-981074223-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 02 Feb 2001 00:37:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 00:37:03 -0000 Received: (qmail 82567 invoked from network); 2 Feb 2001 00:36:13 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 00:36:13 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.91) by mta1 with SMTP; 2 Feb 2001 00:36:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00533; Thu, 1 Feb 2001 14:21:10 +0100 Message-ID: <20010201142110.08218@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200101292253.f0TMrWL01167@PrintServer.LedCom> <3A765693.E55577AB@free.fr> <3A7687D8.95036886@mentor.com> <20010130163347.13961@thrai.stud.uni-hannover.de> <3A77FAF8.CBAA6ED4@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A77FAF8.CBAA6ED4@mentor.com>; from Yann GUIDON on Wed, Jan 31, 2001 at 12:46:00PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Feb 2001 14:21:10 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 580872596c55ed5ca6b9aa6e61e19d6e Status: R X-Status: N On Wed, Jan 31, 2001 at 12:46:00PM +0100, Yann GUIDON wrote:
> Michael Riepe wrote:
> > I'm willing to play the `CVS master' if nobody else volunteers, but
> > first we'll have to talk about some things:
> >
> >         - will/can we use the existing repository at seul,
> >           or should we create a `private' one?
> i don't know how it works at seul.
> whatever simplest and handiest (so we can move the tree around the net).

You can always move the repository to another place, but then you'll
have to tell everybody who checked out a copy.  You can not easily
keep two or more repositories in sync, however.

> >         - directory structure and areas of responsibility
> structure : as it exists now, because it seems to be ok as of today.

Yes.

> responsibility : the last people that modified the file.

No.  Remember the playground principle ;)

> a readme.txt per directory is not too much either.

Yes.

> >         f-cpu/doc/      # probably with subdirectories tex/, html/ and so on
>
> /doc/common  (LaTeX classes, pictures, etc)
> /doc/en
> /doc/fr
> /doc/de
> .....
> but i don't know how simlinks work woth CVS and latex.

Not at all.  CVS ignores symlinks.

> >         f-cpu/vhdl/compile/<EDAtool>/   # batch files for <EDAtool> go here
>
> on the root directory of /vhdl/compile
> we can put a set of little batch files :
>  * set_simili.bat
>  * set_modelsim
>  * set_whatever... etc.
> So they define the compile command and the directories of the libraries etc.
> then we can simply type a unique command for compiling and testing.

Hmm.  We definitely gotta work on the build environment.

> <does and don't>
> fine, copy and paste them in a file that will be located at the tree root :-)

NP ;)

> >         - Never check in files that are created automatically; instead,
> >           check in the files they're created from (e.g. check in the
> >           .tex sources, but not the resulting .ps files).
> but where will we put them for those who don't have the necessary compilers etc ?
> we can make a /result directory that contains the .exe, .ps, etc...

People using the CVS version are supposed to have these tools.  On the
software side, they're also supposed to have gcc, make, autoconf/automake,
sometimes even TeX or SGML-tools.

For regular releases, we can build these files and tar them together.
Just like the software people do.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www. .com 
From wibowo@computer.org Fri Feb 2 09:33:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00738 for ; Sat, 3 Feb 2001 02:27:40 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:40 +0100 (MET) Received: (qmail 6713 invoked by uid 0); 2 Feb 2001 08:33:57 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx05) with SMTP; 2 Feb 2001 08:33:57 -0000 X-eGroups-Return: sentto-1101623-2191-981102827-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 02 Feb 2001 08:33:48 -0000 X-Sender: wibowo@computer.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 08:33:46 -0000 Received: (qmail 96460 invoked from network); 2 Feb 2001 08:33:46 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 2 Feb 2001 08:33:46 -0000 Received: from unknown (HELO jk.egroups.com) (10.1.10.92) by mta1 with SMTP; 2 Feb 2001 08:33:46 -0000 X-eGroups-Return: wibowo@computer.org Received: from [10.1.10.117] by jk.egroups.com with NNFMP; 02 Feb 2001 08:33:46 -0000 To: f-cpu@yahoogroups.com Message-ID: <95drd9+88ni@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 194.138.242.130 From: wibowo@computer.org MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 08:33:45 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] GNU VHDL tools ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e3588b5a04413c4989d2c8b6d103decb Status: R X-Status: N Hi,

I may have missed this, but why aren't there any activities in
developing GNU tools for chip design ? Just like s/w development we
have gcc, gdb etc. Why can't we have VHDL compiler, simulator, P&R
tools etc ?

I'm just comparing when LINUX developed, all the s/w development
suite
is already available. So it really shows a "free" environment for
development without any "commercial" smell ? ;)
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Fri Feb 2 10:25:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00744 for ; Sat, 3 Feb 2001 02:27:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:42 +0100 (MET) Received: (qmail 26777 invoked by uid 0); 2 Feb 2001 09:32:36 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx08) with SMTP; 2 Feb 2001 09:32:36 -0000 X-eGroups-Return: sentto-1101623-2192-981106341-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 02 Feb 2001 09:32:24 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 09:32:20 -0000 Received: (qmail 86241 invoked from network); 2 Feb 2001 09:32:19 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 2 Feb 2001 09:32:19 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 2 Feb 2001 09:32:19 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA23886; Fri, 2 Feb 2001 01:32:17 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW3GF; Fri, 2 Feb 2001 09:36:59 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7A7D15.2705D60B@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <95drd9+88ni@eGroups.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 10:25:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] GNU VHDL tools ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 153826df9b57ce994bc9182b4dac714a Status: R X-Status: N wibowo@computer.org wrote:
> Hi,
>
> I may have missed this, but why aren't there any activities in
> developing GNU tools for chip design ? Just like s/w development we
> have gcc, gdb etc. Why can't we have VHDL compiler, simulator, P&R
> tools etc ?
do you know about Alliance ?

> I'm just comparing when LINUX developed, all the s/w development suite
> is already available. So it really shows a "free" environment for
> development without any "commercial" smell ? ;)

hello,

look at http://www.opencollector.org
it has a lot of links (it's the most complete database)
for "free" projects.

Unfortunately, 6 months ago, when we did try the available tools,
none was "good enough" (simple, efficient, GNU, easy to learn...)
That's why some of us use Simili (a gratis tool) under win32.
I (like a lot of people) hope that good free tools will emerge but
we don't want to wait... hence some partial/temporary compromises.

hope this helps,

YG

speaking for himself
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Fri Feb 2 11:08:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00747 for ; Sat, 3 Feb 2001 02:27:43 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:43 +0100 (MET) Received: (qmail 7806 invoked by uid 0); 2 Feb 2001 10:15:12 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx21) with SMTP; 2 Feb 2001 10:15:12 -0000 X-eGroups-Return: sentto-1101623-2193-981108903-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mo.egroups.com with NNFMP; 02 Feb 2001 10:15:07 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 10:15:02 -0000 Received: (qmail 98321 invoked from network); 2 Feb 2001 10:15:01 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 10:15:01 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 2 Feb 2001 10:15:01 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA27124; Fri, 2 Feb 2001 02:14:59 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW3KL; Fri, 2 Feb 2001 10:19:54 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7A8724.C75F360C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 11:08:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4a35e4926befeb59294d7c89b6d8ea79 Status: R X-Status: N hallo,

Nicolas Boulay wrote:
> coucou,
> Marco Al a =E9crit :
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > > Just one thing to add about the OOOC. That's what is made in= fact by the
> > > C6000 DSP family from texas (vliw with 8 instructions used),= 3 types of
> > > units but different latency (3 for mul, 1 for an add) BUT ea= ch single
> > > unit have access to the register bank. So you have 8 write p= orts and 8
> > > read ports !!!! (and 32 registers !). I had some question li= ke "How is
> > > it possible to write on a register without waiting or killin= g the
> > > pipeline with different depth of pipelined unit ?".
> > They dont just expose the pipeline latencies to the programmer an= ymore? Bah,
> > thats what makes DSP programming so much fun.
> You have to composed with it. An adder need 1 cycle, a mul 3. So if yo= u
> make thing like that :
>
> 1 mul r4 r2 r3
> 2 add r3 r1 r1
> 3 add r2 r1 r1
> 4 add r4 r1 r1
>
> You will have very big probleme between 1) and 4) instruction because = of
> the 2 write on the register r4. TI said that mul will be written (so t= he
> 4th will be lost).

that's ok for a special-purpose CPU running "trusted" software. binary compatibility is garanteed to remain in the defined margins.
However it is not possible for GP CPU. What would you do if
your SW runs on some machines but not on the others, simply because
there are not the same number of execution units ? Certain TI did
wipe away a lot of his previous DSP's drawbacks (TI is called "the Intel of DSPs"). But their technique can't be applied in our case.
Our goal of compatibility and scalability is even more critical
that TI's.

> > Marco
> nicO
YG

speaking for himself
Yahoo! Groups Spons= or
3D""3D""
www..com
3D""
From Yann GUIDON Fri Feb 2 11:14:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00750 for ; Sat, 3 Feb 2001 02:27:44 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:44 +0100 (MET) Received: (qmail 2161 invoked by uid 0); 2 Feb 2001 10:20:58 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx13) with SMTP; 2 Feb 2001 10:20:58 -0000 X-eGroups-Return: sentto-1101623-2194-981109242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jj.egroups.com with NNFMP; 02 Feb 2001 10:20:51 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 10:20:42 -0000 Received: (qmail 7257 invoked from network); 2 Feb 2001 10:20:42 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 10:20:42 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 2 Feb 2001 10:20:42 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA27604; Fri, 2 Feb 2001 02:20:37 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW3KX; Fri, 2 Feb 2001 10:25:29 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7A8873.B03D8F75@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <3A793B28.A0FFA765@mentor.com> <3A79F59D.1CEDC286@ifrance.com> <002401c08cb1$05dc7d50$29e65982@student.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 11:14:11 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bf354ad762a28d6141872946f648339e Status: R X-Status: N Marco Al wrote:
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
> > I send you a full adder (imagine cascading the carry with one of the
> > entrance on a 4 byte adder)
sorry but here, the CDP is 2 gates.
There is even a way to optimise the FA design and remove the XOR.

> > and a "big" design for a flip-flop.
It is not as big as you infered in your previous mails :-)

So if the CDP of the logic is roughly as long
as the FF CDP, i don't see the problem.
There would be a problem otherwise if the logic CDP was
3 or 4 gates only over all the chip... because the FF would
use 75% of the die.

> > I have
> > some design about it but on paper (flip-flop used in K6, Strong ARM and
> > power pc). I could scan it if you want.
>
> IBM has some schematics for the design of the latches used in the G4 (PowerPC)
> online at http://www.research.ibm.com/journal/rd/414/sigal.html
>
> The actual schematics is http://www.research.ibm.com/journal/rd/414/sigal8.gif
> not really a flip-flop, but still interesting I hope.

nice link !!!

maybe i'll try to make a collection of similar papers on f-cpu.de...


> Marco
YG

speaking for himself
Yahoo! Groups Sponsor

www.   
From Yann GUIDON Fri Feb 2 11:33:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00753 for ; Sat, 3 Feb 2001 02:27:45 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:45 +0100 (MET) Received: (qmail 26644 invoked by uid 0); 2 Feb 2001 10:40:07 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx23) with SMTP; 2 Feb 2001 10:40:07 -0000 X-eGroups-Return: sentto-1101623-2195-981110401-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 02 Feb 2001 10:40:05 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 10:40:00 -0000 Received: (qmail 95246 invoked from network); 2 Feb 2001 10:39:59 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 2 Feb 2001 10:39:59 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 2 Feb 2001 11:41:04 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA29147; Fri, 2 Feb 2001 02:39:57 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW3LQ; Fri, 2 Feb 2001 10:44:51 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7A8CFD.A1A9D006@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> <20010201142516.14977@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 11:33:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3e2b65327649ebc025d3f7ad269a1f4f Status: R X-Status: N Michael Riepe wrote:
>
> On Thu, Feb 01, 2001 at 12:00:21PM +0100, Yann GUIDON wrote:
> [...]
> > For example the real implementation of certain units
> > is still undetermined : SHL and IDU. The first implementations
> > will certainly influence the manual. ROP2 is already
> > programmed and it works. the latest LaTeX manual update
> > (see f-cpu.seul.org/manual) is synchronized with this
> > implementation.
>
> I'm working on the IDU... the SIMD stuff is pretty hard to get right.

hello,

can you give more information about the problems you encounter,
and the expected scheuling behaviour ?

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

have fun,

YG

speaking for himself
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Fri Feb 2 12:03:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00756 for ; Sat, 3 Feb 2001 02:27:46 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:46 +0100 (MET) Received: (qmail 26216 invoked by uid 0); 2 Feb 2001 11:10:23 -0000 Received: from mk.egroups.com (208.50.144.76) by 10.1.4.111 (mx11) with SMTP; 2 Feb 2001 11:10:23 -0000 X-eGroups-Return: sentto-1101623-2196-981112217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 02 Feb 2001 11:10:20 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 11:10:10 -0000 Received: (qmail 84422 invoked from network); 2 Feb 2001 11:10:09 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 2 Feb 2001 11:10:09 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 2 Feb 2001 11:10:09 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA01582; Fri, 2 Feb 2001 03:10:07 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW3MZ; Fri, 2 Feb 2001 11:15:02 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7A9410.AF9B4091@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> <20010201142516.14977@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 12:03:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db1a708a3887da3443cb88f2024a5592 Status: R X-Status: N Michael Riepe wrote:

> I'm working on the IDU... the SIMD stuff is pretty hard to get right.

btw, about the SHL, the IBM articles has an interesting point :
http://www.research.ibm.com/journal/rd/414/sigal12.gif

I also found something about efficient IMUL at the ASIME page :
"A family of redundant multipliers dedicated to fast computation for signal processing"
Dumonteix Yannick, Mehrez Habib
IEEE International Symposium on Circuits and Systems (ISCAS 2000), Geneva, Switzerland, May 2000
ftp://asim.lip6.fr/pub/reports/2000/ar.dum.iscas00.ps.gz

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

have fun !

YG

speaking for himself
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Mon Jan 29 13:37:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00783 for ; Sat, 3 Feb 2001 02:27:55 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:27:55 +0100 (MET) Received: (qmail 26883 invoked by uid 0); 2 Feb 2001 13:22:30 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx15) with SMTP; 2 Feb 2001 13:22:30 -0000 X-eGroups-Return: sentto-1101623-2199-981120040-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 02 Feb 2001 13:21:12 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 13:20:40 -0000 Received: (qmail 96478 invoked from network); 2 Feb 2001 13:20:37 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 2 Feb 2001 13:20:37 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 2 Feb 2001 13:20:36 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id GAA15443 for ; Fri, 2 Feb 2001 06:12:29 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7563FA.CE5E3503@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102021144.MAA07168@rai16.informatik.uni-stuttgart.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 05:37:14 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] GNU VHDL tools ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3eb86d80545059e20c8a0009e39897f5 Status: R X-Status: N Rainer Dorsch wrote:
>
> i think alliance is currently most suitable (e.g. for DLX synthesis), but
> still many things are missing (especially, if it comes to backends for silicon
> processes or FPGAs): http://www-asim.lip6.fr/alliance/

Alliance is a strange system. The major problem is that in version
#4 some of the critial programs programs have gone commercial. Version #3
does not have the modern libraries. Also with a "educational" development
documentation always seems last to written.
Ben. 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.

From Ben Franchuk Mon Jan 29 13:44:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00795 for ; Sat, 3 Feb 2001 02:28:00 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:28:00 +0100 (MET) Received: (qmail 19297 invoked by uid 0); 2 Feb 2001 13:28:11 -0000 Received: from jk.egroups.com (208.50.144.83) by 10.1.4.111 (mx11) with SMTP; 2 Feb 2001 13:28:11 -0000 X-eGroups-Return: sentto-1101623-2200-981120473-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 02 Feb 2001 13:28:10 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 13:27:53 -0000 Received: (qmail 13935 invoked from network); 2 Feb 2001 13:27:52 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 2 Feb 2001 13:27:52 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 2 Feb 2001 13:27:51 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id GAA15829 for ; Fri, 2 Feb 2001 06:19:44 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7565AD.1AEF635D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A753205.3E9B5419@jetnet.ab.ca> <000501c08d13$cccc25c0$8f041f42@ne.mediaone.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 05:44:29 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Off topic but this bugs me. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5f29045bb78f368fb436c92c68160186 Status: R X-Status: N Nathaniel Downes wrote:
>
>    Part 1.1    Type: Plain Text (text/plain)
>            Encoding: quoted-printable
How come the body of email does not come sent "Inline" rather
as file to be opened in my browser? I am curious how this done
in sending rather than grumbling at opening the link.
Ben. 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www. .com 
From Ben Franchuk Mon Jan 29 13:52:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00798 for ; Sat, 3 Feb 2001 02:28:01 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:28:01 +0100 (MET) Received: (qmail 28166 invoked by uid 0); 2 Feb 2001 13:36:20 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx24) with SMTP; 2 Feb 2001 13:36:20 -0000 X-eGroups-Return: sentto-1101623-2201-981120935-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 02 Feb 2001 13:36:18 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 13:35:34 -0000 Received: (qmail 98532 invoked from network); 2 Feb 2001 13:35:33 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 2 Feb 2001 13:35:33 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 2 Feb 2001 14:36:37 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id GAA16253 for ; Fri, 2 Feb 2001 06:27:26 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A75677B.C8B0611@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 05:52:11 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] news blurb on open cores Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d82f1e9c73fc2d1de4af3e4f32b827ba Status: R X-Status: N http://www.eet.com/story/OEG20010201S0050
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www. 
From Carsten899@aol.com Fri Feb 2 18:24:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00918 for ; Sat, 3 Feb 2001 02:28:31 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:28:31 +0100 (MET) Received: (qmail 14748 invoked by uid 0); 2 Feb 2001 17:38:17 -0000 Received: from jk.egroups.com (208.50.144.83) by 10.1.4.111 (mx11) with SMTP; 2 Feb 2001 17:38:17 -0000 X-eGroups-Return: sentto-1101623-2202-981135353-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 02 Feb 2001 17:36:36 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 17:35:52 -0000 Received: (qmail 39525 invoked from network); 2 Feb 2001 17:25:01 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 2 Feb 2001 17:25:01 -0000 Received: from unknown (HELO imo-r14.mx.aol.com) (152.163.225.68) by mta2 with SMTP; 2 Feb 2001 17:25:01 -0000 Received: from Carsten899@aol.com by imo-r14.mx.aol.com (mail_out_v29.5.) id r.a4.f7968da (3896) for ; Fri, 2 Feb 2001 12:24:53 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 12:24:53 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] A hello from new "face" Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: abce9386141c9e15186016fbf5a0a7c5 Status: R X-Status: N Hi i am new to this mailing list. i am interested in th f-cpu-project.
perhaps i can contribute something too.

when i surfed the forums about the f-cpu i found somebody asking about a
f-cpu-emulator in c and the answer was: dont ask, start coding.

my question now: did anybody start coding? does anybody know?

carsten
Yahoo! Groups Sponsor
From Yann GUIDON Fri Feb 2 19:04:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00921 for ; Sat, 3 Feb 2001 02:28:32 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:28:32 +0100 (MET) Received: (qmail 29719 invoked by uid 0); 2 Feb 2001 18:20:47 -0000 Received: from mr.egroups.com (208.50.144.80) by 10.1.4.119 (mx19) with SMTP; 2 Feb 2001 18:20:47 -0000 X-eGroups-Return: sentto-1101623-2203-981138037-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 02 Feb 2001 18:20:43 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 18:20:36 -0000 Received: (qmail 52415 invoked from network); 2 Feb 2001 18:11:16 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 18:11:16 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 2 Feb 2001 18:11:16 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA16797; Fri, 2 Feb 2001 10:11:12 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW37R; Fri, 2 Feb 2001 18:16:07 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7AF6C1.1B89E98@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 19:04:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A hello from new "face" Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a1112584142c53e5703876a2b8d3ab49 Status: R X-Status: N Carsten899@aol.com wrote:
> Hi i am new to this mailing list. i am interested in th f-cpu-project.
> perhaps i can contribute something too.
>
> when i surfed the forums about the f-cpu i found somebody asking about a
> f-cpu-emulator in c and the answer was: dont ask, start coding.
>
> my question now: did anybody start coding? does anybody know?
>
> carsten

Hi !

AFAIK no emulator is available. some were started but never gave anything.
The strategy today is to define the critical things in VHDL. a VHDL emulator
will give you an acurate F-CPU.

If you want to start a f-cpu emulator, here's the advice :
start with what is already coded in VHDL. If you don't know this langage,
it's something like ADA and you'll learn interesting things.
read the manual (look at f-cpu.seul.org/manual for the latest versions)
and translate "at a higher level" the VHDL to C.

pitfalls and fallacies :
beware of the byte ordering !!!
the SW should run indifferently on SUN or x86 (big/little endian,
whatever the int size is).

If you follow the code that is already in VHDL, your work will be valuable.
you can even try to translate the testbenches (they'll help you foolproof
your translation).
I'm still studying the scheduler, therefore you can start to concentrate
on simulating the execution units .
Don't hesitate to ask for comments or submit remarks.

Viel Spass,

YG

speaking for himself
Yahoo! Groups Sponsor
From Yann GUIDON Fri Feb 2 20:49:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00945 for ; Sat, 3 Feb 2001 02:29:08 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:08 +0100 (MET) Received: (qmail 26291 invoked by uid 0); 2 Feb 2001 20:06:18 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx03) with SMTP; 2 Feb 2001 20:06:18 -0000 X-eGroups-Return: sentto-1101623-2204-981144325-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 02 Feb 2001 20:06:11 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 20:05:25 -0000 Received: (qmail 54182 invoked from network); 2 Feb 2001 19:55:47 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Feb 2001 19:55:47 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 2 Feb 2001 20:56:52 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA29016; Fri, 2 Feb 2001 11:55:45 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW386; Fri, 2 Feb 2001 20:00:39 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7B0F40.731F914D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 20:49:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] http://www.f-cpu.de/epf2001/cfp.html Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 68556495e4f392384c52be2aa4879a4d Status: R X-Status: N hello,
i have setup a new zone for the EPF.
i have also dusted off some index.html...
YG
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Nicolas Boulay Fri Feb 2 23:25:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00984 for ; Sat, 3 Feb 2001 02:29:18 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:18 +0100 (MET) Received: (qmail 3976 invoked by uid 0); 2 Feb 2001 22:25:50 -0000 Received: from fh.egroups.com (208.50.144.71) by 10.1.4.112 (mx12) with SMTP; 2 Feb 2001 22:25:50 -0000 X-eGroups-Return: sentto-1101623-2205-981152446-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 02 Feb 2001 22:21:15 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 22:20:45 -0000 Received: (qmail 59685 invoked from network); 2 Feb 2001 22:16:22 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 22:16:22 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta1 with SMTP; 2 Feb 2001 22:16:22 -0000 Received: from ifrance.com (nas14-252.vlt.club-internet.fr [195.36.164.252]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA14117 for ; Fri, 2 Feb 2001 23:16:19 +0100 (MET) Message-ID: <3A7B33F3.3BA966E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 23:25:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2a0f0a5d076406d96553b21b581c60c2 Status: R X-Status: N Hello,

Marco Al a =E9crit :
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com> >
> > > The most you are likely to find in the basic standard cell l= ibrary from the
> > > foundry is probably a full adder though, you brought it up b= efore but I
> never
> > > saw an answer... F-CPU really needs some semi-custom parts, = how is that
> going to
> > > be handled?
> > >
> >
> > Most of the time a "big" adder is composed by 4 bits ri= pple adder.
>
> With that I assume you mean they compose it from 4 bits adders with ri= pple carry
> propogation used for the carries from those 4 bit adders? Is using 4 s= tandard
> cell full adders and yet more cell's for the carry lookahead  a g= ood way of
> building those 4 bit adders though?
>
> I have been able to find only one company offering foundry services wh= ich gives
> specs on their standard cell libraries, samsung, and all they had was = a full
> adder. Is that the common case, or can you expect to find speed optimi= zed 4 bit
> CLA's in libraries?
>

I work with the process of ST (HCMOS7) 0.25 =B5m. My lab have sign a NDA so i can't give anything about it. There is a half adder, a full adder
and a 2 bit full adder. Synopsys use this basic cell to produice ripple
adder or others.

> Also Im not so sure that redundant arithmetic isnt used, take Intel's = double
> clocked ALU for instance. And mr. Glew's case for sum-addressing using= redundant
> arithmetic is convincing.
>
> > > They dont just expose the pipeline latencies to the programm= er anymore? Bah,
> > > thats what makes DSP programming so much fun.
> >
> > You have to composed with it. An adder need 1 cycle, a mul 3. So = if you
> > make thing like that :
> >
> > 1 mul r4 r2 r3
> > 2 add r3 r1 r1
> > 3 add r2 r1 r1
> > 4 add r4 r1 r1
> >
> > You will have very big probleme between 1) and 4) instruction bec= ause of
> > the 2 write on the register r4. TI said that mul will be written = (so the
> > 4th will be lost).
>
> Why a very big problem? Its bogus code, it doesnt matter if it gives b= ogus
> results in r4 IMO... unless you get a short circuit I dont see a probl= em,
> depends on the physical implementation, it only becomes a problem if y= ou dont
> want to expose pipeline latencies. (personally I like binary translati= on for
> backwards compatibility)

Of course ! But I don't understand "binary translation".

>
> Marco
>
nicO
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www.   
=0D=
3D""
From Nicolas Boulay Fri Feb 2 23:34:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00987 for ; Sat, 3 Feb 2001 02:29:20 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:20 +0100 (MET) Received: (qmail 21476 invoked by uid 0); 2 Feb 2001 22:33:16 -0000 Received: from fg.egroups.com (208.50.144.70) by 10.1.4.119 (mx19) with SMTP; 2 Feb 2001 22:33:16 -0000 X-eGroups-Return: sentto-1101623-2206-981152905-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 02 Feb 2001 22:28:29 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 22:28:24 -0000 Received: (qmail 84935 invoked from network); 2 Feb 2001 22:24:42 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Feb 2001 22:24:42 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 2 Feb 2001 23:25:47 -0000 Received: from ifrance.com (nas14-252.vlt.club-internet.fr [195.36.164.252]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA22516 for ; Fri, 2 Feb 2001 23:24:39 +0100 (MET) Message-ID: <3A7B35E2.93058C4B@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <3A793B28.A0FFA765@mentor.com> <3A79F59D.1CEDC286@ifrance.com> <002401c08cb1$05dc7d50$29e65982@student.utwente.nl> <3A7A8873.B03D8F75@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 23:34:10 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 98b4c9383d85c743791413b1cd71bfbf Status: R X-Status: N hello,

Yann GUIDON a =E9crit :
>
> Marco Al wrote:
> > From: "Nicolas Boulay" <nicolas.boulay@ifrance.com&g= t;
> > > I send you a full adder (imagine cascading the carry with on= e of the
> > > entrance on a 4 byte adder)
> sorry but here, the CDP is 2 gates.
> There is even a way to optimise the FA design and remove the XOR.
>
> > > and a "big" design for a flip-flop.
> It is not as big as you infered in your previous mails :-)
>
> So if the CDP of the logic is roughly as long
> as the FF CDP, i don't see the problem.
> There would be a problem otherwise if the logic CDP was
> 3 or 4 gates only over all the chip... because the FF would
> use 75% of the die.
>

You never heard about setup and hold timing problem ?

> > Marco
> YG
nicO
Yahoo! Groups Spons= or
www.
3D""
From Nicolas Boulay Fri Feb 2 23:41:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00990 for ; Sat, 3 Feb 2001 02:29:21 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:21 +0100 (MET) Received: (qmail 25102 invoked by uid 0); 2 Feb 2001 22:42:55 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 2 Feb 2001 22:42:55 -0000 X-eGroups-Return: sentto-1101623-2207-981153312-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 02 Feb 2001 22:35:48 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 22:35:07 -0000 Received: (qmail 10740 invoked from network); 2 Feb 2001 22:32:17 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 22:32:17 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 2 Feb 2001 22:32:17 -0000 Received: from ifrance.com (nas14-252.vlt.club-internet.fr [195.36.164.252]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA28278 for ; Fri, 2 Feb 2001 23:32:12 +0100 (MET) Message-ID: <3A7B37AC.8229AAF5@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A7AF6C1.1B89E98@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 23:41:48 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] A hello from new "face" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4335db8434ade2f777f38b5c8d582afc Status: R X-Status: N Hello,

If VHDL sound too strange to you, you can try to write a C emulator. You are not as accurate as VHDL simulation. You can't manage depencies
problem and all thing as pipeline lengh,...

BUT a C simulator could be very useful to test a compiler, and some
crazy idea like changing size of the SIMD register could be tested. With that emulator coding rules will be much more easy to defined. That's a
very good idea. And normaly, the first thing to do when you want develop a ( big ) system.

nicO

Yann GUIDON a =E9crit :
>
> Carsten899@aol.com wrote:
> > Hi i am new to this mailing list. i am interested in th f-cpu-pro= ject.
> > perhaps i can contribute something too.
> >
> > when i surfed the forums about the f-cpu i found somebody asking = about a
> > f-cpu-emulator in c and the answer was: dont ask, start coding. > >
> > my question now: did anybody start coding? does anybody know?
> >
> > carsten
>
> Hi !
>
> AFAIK no emulator is available. some were started but never gave anyth= ing.
> The strategy today is to define the critical things in VHDL. a VHDL em= ulator
> will give you an acurate F-CPU.
>
> If you want to start a f-cpu emulator, here's the advice :
> start with what is already coded in VHDL. If you don't know this langa= ge,
> it's something like ADA and you'll learn interesting things.
> read the manual (look at f-cpu.seul.org/manual for the latest versions= )
> and translate "at a higher level" the VHDL to C.
>
> pitfalls and fallacies :
> beware of the byte ordering !!!
> the SW should run indifferently on SUN or x86 (big/little endian,
> whatever the int size is).
>
> If you follow the code that is already in VHDL, your work will be valu= able.
> you can even try to translate the testbenches (they'll help you foolpr= oof
> your translation).
> I'm still studying the scheduler, therefore you can start to concentra= te
> on simulating the execution units .
> Don't hesitate to ask for comments or submit remarks.
>
> Viel Spass,
>
> YG
>
> speaking for himself
>

Yahoo! Groups Spons= or
3D""
3D""
From Michael Riepe Fri Feb 2 15:30:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00993 for ; Sat, 3 Feb 2001 02:29:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:21 +0100 (MET) Received: (qmail 21319 invoked by uid 0); 2 Feb 2001 23:04:12 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx14) with SMTP; 2 Feb 2001 23:04:12 -0000 X-eGroups-Return: sentto-1101623-2208-981153566-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 02 Feb 2001 22:39:50 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 22:39:25 -0000 Received: (qmail 12965 invoked from network); 2 Feb 2001 22:38:35 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 2 Feb 2001 22:38:35 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.53) by mta2 with SMTP; 2 Feb 2001 22:38:33 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00567; Fri, 2 Feb 2001 15:30:29 +0100 Message-ID: <20010202153029.15442@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> <20010201142516.14977@thrai.stud.uni-hannover.de> <3A7A8CFD.A1A9D006@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A7A8CFD.A1A9D006@mentor.com>; from Yann GUIDON on Fri, Feb 02, 2001 at 11:33:33AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Feb 2001 15:30:29 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 36a27de3a415e77af9a2ddafdfc14710 Status: R X-Status: N On Fri, Feb 02, 2001 at 11:33:33AM +0100, Yann GUIDON wrote:
[...]
> > I'm working on the IDU... the SIMD stuff is pretty hard to get right.
>
> can you give more information about the problems you encounter,
> and the expected scheuling behaviour ?

Slow, real slow... something like CHUNK_SIZE + n, where n is a small
constant (probably 0...3); e.g. the unit will calculate 1 result bit per
pipeline stage (SRT divider).  Throughput depends on the size of the array
and can be anywhere between 1 op/cycle and 1/n op/cycles (n = chunk size).

The problem is (as usual) to get both SIMD and signed/unsigned mode
working, and to fit each row into a single pipeline stage.  The adder
row is pretty simple, but the decision logic (add, subtract or do nothing)
can become rather complex, and slow.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.  
From Ben Franchuk Mon Jan 29 16:51:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00996 for ; Sat, 3 Feb 2001 02:29:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:23 +0100 (MET) Received: (qmail 9542 invoked by uid 0); 3 Feb 2001 00:05:47 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx15) with SMTP; 3 Feb 2001 00:05:47 -0000 X-eGroups-Return: sentto-1101623-2209-981153871-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 02 Feb 2001 22:44:38 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 2 Feb 2001 22:44:31 -0000 Received: (qmail 47356 invoked from network); 2 Feb 2001 22:43:26 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 2 Feb 2001 22:43:26 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 2 Feb 2001 22:43:25 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA13681 for ; Fri, 2 Feb 2001 15:35:14 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A75917C.9114DF0F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 29 Jan 2001 08:51:25 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 118dc19d4cd782f1694d4bdda5d1a11c Status: R X-Status: N Nicolas Boulay wrote:
>
> Hello,
> I work with the process of ST (HCMOS7) 0.25 =B5m. My lab have sign a N= DA
> so i can't give anything about it. There is a half adder, a full adder=
> and a 2 bit full adder. Synopsys use this basic cell to produice rippl= e
> adder or others.

The problem is a ripple adder is not the best building block as
most complex ALU's needs to have more on the gating. I have seen
lots of adder designs but few ALU designs out.
>
> Of course ! But I don't understand "binary translation".
>
What ever happened to the idea of "Generic Opcodes" that you woul= d compile
a program and the loader would translate this to real opcodes?
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Spons= or
3D""3D""
www.= .c= om
3D""
From "Gordon F. Cichon" Sat Feb 3 01:53:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00999 for ; Sat, 3 Feb 2001 02:29:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:24 +0100 (MET) Received: (qmail 19648 invoked by uid 0); 3 Feb 2001 00:54:58 -0000 Received: from hi.egroups.com (208.50.99.211) by 10.1.4.106 (mx06) with SMTP; 3 Feb 2001 00:54:58 -0000 X-eGroups-Return: sentto-1101623-2210-981161668-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 03 Feb 2001 00:54:35 -0000 X-Sender: gordon@cichon.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 00:54:27 -0000 Received: (qmail 85300 invoked from network); 3 Feb 2001 00:54:26 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 3 Feb 2001 00:54:26 -0000 Received: from unknown (HELO sh.cichon.com) (63.125.155.228) by mta1 with SMTP; 3 Feb 2001 00:54:26 -0000 Received: from cichon.de (localhost [127.0.0.1]) by sh.cichon.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA11004; Fri, 2 Feb 2001 16:54:24 -0800 Sender: gordon@cichon.de Message-ID: <3A7B5692.B8AC3666@cichon.de> X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com, f-admin@egroups.com, f-mainboard@egroups.com, f-comm@egroups.com, t-fools@egroups.com From: "Gordon F. Cichon" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 01:53:38 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: add69519101f704b41b4833cec7e2c9a Status: R X-Status: N UNSUBSCRIBE
Yahoo! Groups Sponsor
From "Gordon F. Cichon" Sat Feb 3 02:07:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01002 for ; Sat, 3 Feb 2001 02:29:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Feb 2001 02:29:24 +0100 (MET) Received: (qmail 27683 invoked by uid 0); 3 Feb 2001 01:15:31 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx23) with SMTP; 3 Feb 2001 01:15:31 -0000 X-eGroups-Return: sentto-1101623-2211-981162492-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 03 Feb 2001 01:09:23 -0000 X-Sender: gordon@cichon.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 01:08:12 -0000 Received: (qmail 15778 invoked from network); 3 Feb 2001 01:08:11 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 3 Feb 2001 01:08:11 -0000 Received: from unknown (HELO sh.cichon.com) (63.125.155.228) by mta1 with SMTP; 3 Feb 2001 01:08:11 -0000 Received: from cichon.com (localhost [127.0.0.1]) by sh.cichon.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA11080; Fri, 2 Feb 2001 17:08:10 -0800 Sender: gordon@cichon.de Message-ID: <3A7B59CB.F610388E@cichon.com> X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com, self-interest@egroups.com From: "Gordon F. Cichon" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 02:07:23 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c1b5d28f02b065f9443d4ffc701bae59 Status: R X-Status: N UNSUBSCRIBE
Yahoo! Groups Sponsor
From Alan Grimes Sat Feb 3 04:12:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00599 for ; Wed, 7 Feb 2001 00:50:56 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:50:56 +0100 (MET) Received: (qmail 20809 invoked by uid 0); 3 Feb 2001 03:12:00 -0000 Received: from ch.egroups.com (208.50.99.226) by 10.1.4.106 (mx06) with SMTP; 3 Feb 2001 03:12:00 -0000 X-eGroups-Return: sentto-1101623-2212-981169914-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 03 Feb 2001 03:11:57 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 03:11:53 -0000 Received: (qmail 81634 invoked from network); 3 Feb 2001 03:11:52 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 3 Feb 2001 03:11:52 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 3 Feb 2001 03:11:52 -0000 Received: from 66-44-56-187.s187.tnt2.lnhva.md.dialup.rcn.com ([66.44.56.187] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14Ot78-000195-00 for f-cpu@yahoogroups.com; Fri, 02 Feb 2001 22:11:50 -0500 Message-ID: <3A7B7734.F2E63C52@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <3A7B5692.B8AC3666@cichon.de> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 22:12:52 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c986fdce63052877592ccb71ad4e2c89 Status: R X-Status: N YAY!!!
ANOTHER MORON!!!!
THIS IS FUN! =P

Gordon F. Cichon wrote:
>
> UNSUBSCRIBE
>

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.
From "Marco Al" Sat Feb 3 12:56:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00623 for ; Wed, 7 Feb 2001 00:51:02 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:02 +0100 (MET) Received: (qmail 11027 invoked by uid 0); 3 Feb 2001 11:48:20 -0000 Received: from f19.egroups.com (64.211.240.234) by 10.1.4.111 (mx11) with SMTP; 3 Feb 2001 11:48:20 -0000 X-eGroups-Return: sentto-1101623-2213-981200887-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 03 Feb 2001 11:48:10 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 11:48:06 -0000 Received: (qmail 29976 invoked from network); 3 Feb 2001 11:48:06 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 3 Feb 2001 11:48:06 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 3 Feb 2001 12:49:10 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 813ED2B1E for ; Sat, 3 Feb 2001 12:48:04 +0100 (CET) Message-ID: <002001c08dd8$6283efc0$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Feb 2001 12:56:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b4aecc807d94c83a30e41332f5ef5943 Status: R X-Status: N From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>

> The problem is a ripple adder is not the best building block as
> most complex ALU's needs to have more on the gating. I have seen
> lots of adder designs but few ALU designs out.

Be carefull, you might wake up mr. Hartney ;) (seriously though, I think he
pointed out a couple)

> > Of course ! But I don't understand "binary translation".
> >
> What ever happened to the idea of "Generic Opcodes" that you would compile
> a program and the loader would translate this to real opcodes?

Thats what I meant, sorta.

As long as wrong code sequences cant harm the processor and not compromise
security the single biggest problem with exposing pipeline latency is that they
make backward compatibility complex. It also makes assembly programming a barrel
of laughs, but hell thats for masochists anyway's so they dont mind... once the
compiler backend is finished for most people it doesnt matter. Binary
translation is an alternative to hiding the pipeline structure for backwards
compatibility.

Marco
Yahoo! Groups Sponsor

www.  
From Ben Franchuk Sat Feb 3 04:37:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00641 for ; Wed, 7 Feb 2001 00:51:06 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:06 +0100 (MET) Received: (qmail 4826 invoked by uid 0); 3 Feb 2001 15:51:59 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx16) with SMTP; 3 Feb 2001 15:51:59 -0000 X-eGroups-Return: sentto-1101623-2214-981214593-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 03 Feb 2001 15:36:41 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 15:36:33 -0000 Received: (qmail 80220 invoked from network); 3 Feb 2001 15:36:32 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 3 Feb 2001 15:36:32 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 3 Feb 2001 16:37:36 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA13512 for ; Sat, 3 Feb 2001 08:28:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7B7CF4.D428D96D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Feb 2001 20:37:24 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 29760a8a78b3cb0aa619b1590856c4fc Status: R X-Status: N Marco Al wrote:

> Be carefull, you might wake up mr. Hartney ;) (seriously though, I think he
> pointed out a couple)

Well I could use a good link or two on that.

> As long as wrong code sequences cant harm the processor and not compromise
> security the single biggest problem with exposing pipeline latency is that they
> make backward compatibility complex. It also makes assembly programming a barrel
> of laughs, but hell thats for masochists anyway's so they dont mind... once the
> compiler backend is finished for most people it doesnt matter. Binary
> translation is an alternative to hiding the pipeline structure for backwards
> compatibility.

If I remember right this was from the DAYS of ALGOL.Algol is large multi-pass
compiler (large in those days) that you only wanted to compile your program
once or twice.The main problem with Binary Translation is #$&! programs that
write into the code segment. OH well you can't expect <your favorite big
company>
to know not to do that.
>
> Marco
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From rvsicam@aol.com Sat Feb 3 16:48:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00644 for ; Wed, 7 Feb 2001 00:51:07 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:07 +0100 (MET) Received: (qmail 10871 invoked by uid 0); 3 Feb 2001 15:54:21 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx09) with SMTP; 3 Feb 2001 15:54:21 -0000 X-eGroups-Return: sentto-1101623-2215-981215339-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 03 Feb 2001 15:49:05 -0000 X-Sender: RVSICAM@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 15:48:59 -0000 Received: (qmail 81561 invoked from network); 3 Feb 2001 15:48:58 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 Feb 2001 15:48:58 -0000 Received: from unknown (HELO imo-r19.mx.aol.com) (152.163.225.73) by mta1 with SMTP; 3 Feb 2001 15:48:58 -0000 Received: from RVSICAM@aol.com by imo-r19.mx.aol.com (mail_out_v29.5.) id r.72.7866291 (4255) for ; Sat, 3 Feb 2001 10:48:51 -0500 (EST) Message-ID: <72.7866291.27ad8263@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 47 From: rvsicam@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Feb 2001 10:48:51 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 64b90ff2b929f8b4eee2033fc71e3989 Status: R X-Status: N PLEASE UNSUBSCRIBE ME...
Yahoo! Groups Sponsor

www.   
From Alan Grimes Sat Feb 3 16:55:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00647 for ; Wed, 7 Feb 2001 00:51:08 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:08 +0100 (MET) Received: (qmail 9730 invoked by uid 0); 3 Feb 2001 15:54:59 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 3 Feb 2001 15:54:59 -0000 X-eGroups-Return: sentto-1101623-2216-981215692-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 03 Feb 2001 15:54:54 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 15:54:48 -0000 Received: (qmail 93523 invoked from network); 3 Feb 2001 15:54:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 3 Feb 2001 15:54:47 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 3 Feb 2001 15:54:47 -0000 Received: from 66-44-91-129.s510.tnt5.lnhva.md.dialup.rcn.com ([66.44.91.129] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14P51R-0001pd-00 for f-cpu@yahoogroups.com; Sat, 03 Feb 2001 10:54:45 -0500 Message-ID: <3A7C2A04.ACB28D03@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <72.7866291.27ad8263@aol.com> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 10:55:48 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 340bc3f5b53205dea1aeff3eaf05bc83 Status: R X-Status: N This is a headless list.
Total anarchy.
Every man for himself.
Although I havn't *tried* to get off, I believe I could at a whim...
I don't even want to know why you can't. =P

rvsicam@aol.com wrote:
>
> PLEASE UNSUBSCRIBE ME...
>

--
Perhaps I will upgrade my OS from Win 3.11...
But It has to be more sophisticated than Win 3.11.
As well as less complicated than Win 3.11.
*AND* It must run on THE MACHINE!!!!
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Sat Feb 3 20:38:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00674 for ; Wed, 7 Feb 2001 00:51:13 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:13 +0100 (MET) Received: (qmail 27523 invoked by uid 0); 3 Feb 2001 20:05:05 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx13) with SMTP; 3 Feb 2001 20:05:05 -0000 X-eGroups-Return: sentto-1101623-2217-981228553-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 03 Feb 2001 19:29:18 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 19:29:12 -0000 Received: (qmail 26956 invoked from network); 3 Feb 2001 19:29:11 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 3 Feb 2001 19:29:11 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 3 Feb 2001 20:30:15 -0000 Received: from ifrance.com (nas7-247.vlt.club-internet.fr [194.158.109.247]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA15713 for ; Sat, 3 Feb 2001 20:24:18 +0100 (MET) Message-ID: <3A7C5E4A.78BAE839@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 20:38:50 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 589d6a8c344276c3ff9ebbb31d3cf202 Status: R X-Status: N hello,

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> >
> > Hello,
> > I work with the process of ST (HCMOS7) 0.25 =B5m. My lab have sig= n a NDA
> > so i can't give anything about it. There is a half adder, a full = adder
> > and a 2 bit full adder. Synopsys use this basic cell to produice = ripple
> > adder or others.
>
> The problem is a ripple adder is not the best building block as
> most complex ALU's needs to have more on the gating. I have seen
> lots of adder designs but few ALU designs out.

Others means : carry lookhead, it's depend on the timing constraint.

> >
> > Of course ! But I don't understand "binary translation"= .
> >
> What ever happened to the idea of "Generic Opcodes" that you= would compile
> a program and the loader would translate this to real opcodes?

Whygee hate layer. Layer is very good to abstract system and hide
complexity. BUT it's slower. One guy ask to write a simulator in C, so
you could try to simulate the performance of your system.

> Ben.
nicO
Yahoo! Groups Spons= or
=0D<= /tr>
3D""3D""
w= ww. .com 
3D""
From Yann Guidon Sat Feb 3 21:56:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00683 for ; Wed, 7 Feb 2001 00:51:15 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:15 +0100 (MET) Received: (qmail 26715 invoked by uid 0); 3 Feb 2001 21:09:24 -0000 Received: from mx04.rz2.gmx.net (HELO mk.egroups.com) (10.1.72.104) by mxi1.gmx.net (mxi1) with SMTP; 3 Feb 2001 21:09:24 -0000 X-eGroups-Return: sentto-1101623-2218-981233448-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 03 Feb 2001 20:50:49 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 20:50:47 -0000 Received: (qmail 54806 invoked from network); 3 Feb 2001 20:50:22 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 3 Feb 2001 20:50:22 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 3 Feb 2001 20:50:21 -0000 Received: from f-cpu.org (nas4-82.ras.club-internet.fr [195.36.203.82]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA04888 for ; Sat, 3 Feb 2001 21:50:17 +0100 (MET) Message-ID: <3A7C7081.FE3638CC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 21:56:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ccf93fea962a0259f84f9c6c5a21265e Status: R X-Status: N hi,

Marco Al wrote:
> From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
> > > Of course ! But I don't understand "binary translation".
> > >
> > What ever happened to the idea of "Generic Opcodes" that you would compile
> > a program and the loader would translate this to real opcodes?
>
> Thats what I meant, sorta.

as long as it's "only" about a lookup table, it's ok.
however, the latency/scheduling issue is more difficult to solve.

> As long as wrong code sequences cant harm the processor and not compromise
> security the single biggest problem with exposing pipeline latency is that they
> make backward compatibility complex.
and that's a big issue because it's our #1 goal.
what's the point of having a very efficient CPU if the binaries can't be reuse elsewhere ???

> It also makes assembly programming a barrel
> of laughs, but hell thats for masochists anyway's so they dont mind...
... until they realise no compiler can do the work they expect ...

> once the compiler backend is finished for most people it doesnt matter.


> Binary translation is an alternative to hiding the pipeline structure for backwards
> compatibility.

binary translation looks fine ... but how ?
if it's SW (others are looking at transmeta) no way for me.
sure, f-cpu isa is much easier than x86 to translate. however, the
SW is still diffucult to write and it's going to take years ...

if it's HW, it's the best solution for me. there is no compatibility and
less performance issue. it's probably one of the ways to use if we want to
go beyond 4 IPC. Here, we benefit from the ISA simplicity and we would
get much performance than on a P4. all we want to check is the dependency
between the instructions during a certain window (as large as the pipeline
depth) so all we have to store in the cache (on top of the instructions themselves)
is the "boundary" between the packets (just like on the old good pentiums).

but of course, we have enough time to discuss about that. we gotta make the
single-issue version work first :-)

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.  
From "Marco Al" Sat Feb 3 22:41:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00689 for ; Wed, 7 Feb 2001 00:51:17 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:17 +0100 (MET) Received: (qmail 15503 invoked by uid 0); 3 Feb 2001 21:33:46 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx13) with SMTP; 3 Feb 2001 21:33:46 -0000 X-eGroups-Return: sentto-1101623-2219-981235948-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 03 Feb 2001 21:32:48 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 21:32:27 -0000 Received: (qmail 33093 invoked from network); 3 Feb 2001 21:32:26 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 Feb 2001 21:32:26 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 3 Feb 2001 21:32:25 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 1B058284C for ; Sat, 3 Feb 2001 22:32:24 +0100 (CET) Message-ID: <000b01c08e2a$04250700$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Feb 2001 22:41:07 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dbf9fe0eb67b24f04d2925e750e4217f Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> as long as it's "only" about a lookup table, it's ok.
> however, the latency/scheduling issue is more difficult to solve.

Id like to see it done in cooperation with the OS (cache results and do it at
program loading, including the OS via a bootstrap in BIOS the first time).

> > It also makes assembly programming a barrel
> > of laughs, but hell thats for masochists anyway's so they dont mind...
> ... until they realise no compiler can do the work they expect ...

Software pipelining doesnt port either performance wise, wether you expose the
pipeline or not. Making assembly programming a little more challenging by always
having to consider the structure instead of just in the performance critical
parts while doing assembly programming is hardly a big loss IMO.

> binary translation looks fine ... but how ?
> if it's SW (others are looking at transmeta) no way for me.
> sure, f-cpu isa is much easier than x86 to translate. however, the
> SW is still diffucult to write and it's going to take years ...

Man hour wise I doubt for a real company it would make much impact if they could
find the talent... here we are dependant on what people can/want to do of
course.

> if it's HW, it's the best solution for me. there is no compatibility and
> less performance issue.

Some things are really only feasible with software (huge windows), some only
with hardware (runtime dependency checks) and some with a combination of both
(runtime profile guided optimization with binary translation).

> it's probably one of the ways to use if we want to
> go beyond 4 IPC. Here, we benefit from the ISA simplicity and we would
> get much performance than on a P4. all we want to check is the dependency
> between the instructions during a certain window (as large as the pipeline
> depth) so all we have to store in the cache (on top of the instructions
themselves)
> is the "boundary" between the packets (just like on the old good pentiums).

Or you could put 3*X bits (X being 2 or 3) in the instructions to encode
dependencies directly, or for a non performance portable method (because it
makes assumptions about the pipeline) just encode execution delay's in the
instructions directly (someone pointed a nice ICCD paper about that out to me,
http://www.ai.mit.edu/~jpg/pub.html top paper... there's more interesting stuff
there).

Marco
Yahoo! Groups Sponsor
www. .com 
From Yann Guidon Sat Feb 3 22:40:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00692 for ; Wed, 7 Feb 2001 00:51:18 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:18 +0100 (MET) Received: (qmail 3665 invoked by uid 0); 3 Feb 2001 21:34:39 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx27) with SMTP; 3 Feb 2001 21:34:39 -0000 X-eGroups-Return: sentto-1101623-2220-981236068-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 03 Feb 2001 21:34:33 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 21:34:27 -0000 Received: (qmail 78761 invoked from network); 3 Feb 2001 21:34:19 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 3 Feb 2001 21:34:19 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta1 with SMTP; 3 Feb 2001 21:34:18 -0000 Received: from f-cpu.org (nas4-102.ras.club-internet.fr [195.36.203.102]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA21599 for ; Sat, 3 Feb 2001 22:34:14 +0100 (MET) Message-ID: <3A7C7AD0.82AED76D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 22:40:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] decoder/issue pipelining Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee8c3924e3c9cd9a931f339a6d2d2821 Status: R X-Status: N
Yahoo! Groups Sponsor
www. .com 
From Yann Guidon Sat Feb 3 22:56:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00695 for ; Wed, 7 Feb 2001 00:51:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:19 +0100 (MET) Received: (qmail 23575 invoked by uid 0); 3 Feb 2001 21:51:01 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx10) with SMTP; 3 Feb 2001 21:51:01 -0000 X-eGroups-Return: sentto-1101623-2221-981237056-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 03 Feb 2001 21:50:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 21:50:55 -0000 Received: (qmail 19031 invoked from network); 3 Feb 2001 21:50:31 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 3 Feb 2001 21:50:31 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 3 Feb 2001 21:50:30 -0000 Received: from f-cpu.org (nas4-102.ras.club-internet.fr [195.36.203.102]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA00800 for ; Sat, 3 Feb 2001 22:50:25 +0100 (MET) Message-ID: <3A7C7E96.5970CC19@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <000b01c08e2a$04250700$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 22:56:38 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5d48d483e99e606ed5f9d0108d5d4f3a Status: R X-Status: N hi !

Marco Al wrote:
> From: "Yann Guidon" <whygee@f-cpu.org>
> > as long as it's "only" about a lookup table, it's ok.
> > however, the latency/scheduling issue is more difficult to solve.
> Id like to see it done in cooperation with the OS (cache results and do it at
> program loading, including the OS via a bootstrap in BIOS the first time).
hmmm that limits the portability of the F-architecture, or increases the amount
of code to rewrite...

> > > It also makes assembly programming a barrel
> > > of laughs, but hell thats for masochists anyway's so they dont mind...
> > ... until they realise no compiler can do the work they expect ...
> Software pipelining doesnt port either performance wise, wether you expose the
> pipeline or not. Making assembly programming a little more challenging by always
> having to consider the structure instead of just in the performance critical
> parts while doing assembly programming is hardly a big loss IMO.

asm is one solution for simple cases.
however, when you have enough "work" to do (that is : several parallel operations
all the time) GNL methodology (tree balancing etc) can do a very good job.
i know it, i did it ;-)

> > binary translation looks fine ... but how ?
> > if it's SW (others are looking at transmeta) no way for me.
> > sure, f-cpu isa is much easier than x86 to translate. however, the
> > SW is still diffucult to write and it's going to take years ...
> Man hour wise I doubt for a real company it would make much impact if they could
> find the talent... here we are dependant on what people can/want to do of
> course.
yup. But it's even more critical : people judge on what is done, not on what
should be done. FC0 is the main priority.

> > if it's HW, it's the best solution for me. there is no compatibility and
> > less performance issue.
> Some things are really only feasible with software (huge windows), some only
> with hardware (runtime dependency checks) and some with a combination of both
> (runtime profile guided optimization with binary translation).
yup but what is worth what ?...

the tiny gap between the F-ISA and a normal CPU execution core is not worth
the huge amount of technology spent for the x86 emulation.

When i mentioned the "binary translation" it was about the allocation of the opcodes,
that is : a 8-bit field in the instructions. this is still undefined and the
existing #defines are temporary. We'll "compile" the opcode values later.
that's why we'd need an interim translation before the definitive map is decided.

> > it's probably one of the ways to use if we want to
> > go beyond 4 IPC. Here, we benefit from the ISA simplicity and we would
> > get much performance than on a P4. all we want to check is the dependency
> > between the instructions during a certain window (as large as the pipeline
> > depth) so all we have to store in the cache (on top of the instructions themselves)
> > is the "boundary" between the packets (just like on the old good pentiums).
> Or you could put 3*X bits (X being 2 or 3) in the instructions to encode
> dependencies directly, or for a non performance portable method (because it
> makes assumptions about the pipeline) just encode execution delay's in the
> instructions directly
no and no.
1) the instruction word is already defined and there's no room for such additional bits.
In the discussion with NicO, i pointed out however that a special instruction could
pack these bits externally for a whole cache line (1 instruction each 8, so 3 bits per
instruction). It has the advantage that when compacity is required, the compiler could
turn the pack instruction generation to gain 1/8 of room/bandwidth.
2) encoding the delay/latency in the instruction is another mistake because the
new platforms could have radically different scheduling rules. it is not portable.
it could however be coded in the "pack" instruction because this instruction can be
interpreted as a NOP on the architectures that don't support or comply this.

> (someone pointed a nice ICCD paper about that out to me,
> http://www.ai.mit.edu/~jpg/pub.html top paper... there's more interesting stuff
> there).
thanks ! i'm currently downloading these files.

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click Here
From "Marco Al" Sun Feb 4 00:01:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00701 for ; Wed, 7 Feb 2001 00:51:20 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:20 +0100 (MET) Received: (qmail 20082 invoked by uid 0); 3 Feb 2001 22:53:29 -0000 Received: from fh.egroups.com (208.50.144.71) by 10.1.4.112 (mx12) with SMTP; 3 Feb 2001 22:53:29 -0000 X-eGroups-Return: sentto-1101623-2222-981240788-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 03 Feb 2001 22:53:24 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 22:53:06 -0000 Received: (qmail 43683 invoked from network); 3 Feb 2001 22:53:05 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 3 Feb 2001 22:53:05 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta1 with SMTP; 3 Feb 2001 22:53:04 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id B49F52B80 for ; Sat, 3 Feb 2001 23:53:02 +0100 (CET) Message-ID: <000801c08e35$4841da20$29e65982@student.utwente.nl> To: References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <000b01c08e2a$04250700$29e65982@student.utwente.nl> <3A7C7E96.5970CC19@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 00:01:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c4d3bc1c38ff26c1522f42128d784d38 Status: R X-Status: N From: "Yann Guidon" <whygee@f-cpu.org>

> asm is one solution for simple cases.
> however, when you have enough "work" to do (that is : several parallel
operations
> all the time) GNL methodology (tree balancing etc) can do a very good job.
> i know it, i did it ;-)

If you have enough work to do and that work can be parallelized in a fixed
instruction stream... AFAICS the usual terminology for this kind of stuff is
software-pipelining BTW.

Anyway's it looks like it and it smells like it to me, so Ill just call it
assembly.

Marco
Yahoo! Groups Sponsor
www. .com 
From Gordon Cichon Sun Feb 4 00:20:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00710 for ; Wed, 7 Feb 2001 00:51:22 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:22 +0100 (MET) Received: (qmail 22250 invoked by uid 0); 3 Feb 2001 23:22:08 -0000 Received: from hm.egroups.com (208.50.99.198) by 10.1.4.112 (mx12) with SMTP; 3 Feb 2001 23:22:08 -0000 X-eGroups-Return: sentto-1101623-2223-981242517-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 03 Feb 2001 23:22:00 -0000 X-Sender: gordon@cichon.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 3 Feb 2001 23:21:56 -0000 Received: (qmail 52761 invoked from network); 3 Feb 2001 23:20:46 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 3 Feb 2001 23:20:46 -0000 Received: from unknown (HELO sh.cichon.com) (63.125.155.228) by mta3 with SMTP; 4 Feb 2001 00:21:51 -0000 Received: from cichon.com (localhost [127.0.0.1]) by sh.cichon.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA14662 for ; Sat, 3 Feb 2001 15:20:46 -0800 Sender: gordon@cichon.com Message-ID: <3A7C922F.E4330650@cichon.com> X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com From: Gordon Cichon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 00:20:15 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] UNSUBSCRIBE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5fd0d0fcd9d7f718e92acc74ed9d6787 Status: R X-Status: N UNSUBSCRIBE
Yahoo! Groups Sponsor
www. .com 
From Carsten899@aol.com Sun Feb 4 06:31:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00737 for ; Wed, 7 Feb 2001 00:51:33 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:33 +0100 (MET) Received: (qmail 18609 invoked by uid 0); 4 Feb 2001 05:31:13 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx13) with SMTP; 4 Feb 2001 05:31:13 -0000 X-eGroups-Return: sentto-1101623-2224-981264669-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 04 Feb 2001 05:31:11 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 05:31:08 -0000 Received: (qmail 17522 invoked from network); 4 Feb 2001 05:31:08 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 4 Feb 2001 05:31:08 -0000 Received: from unknown (HELO imo-d01.mx.aol.com) (205.188.157.33) by mta3 with SMTP; 4 Feb 2001 06:32:13 -0000 Received: from Carsten899@aol.com by imo-d01.mx.aol.com (mail_out_v29.5.) id r.a3.1163ca20 (4412) for ; Sun, 4 Feb 2001 00:31:05 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 00:31:04 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 74d1a4d4bd8118a5e09ac3a894e5048c Status: R X-Status: N Hi,

I concentrated on reading part 6 of the manual. Perhaps i have overseen something in the other parts, but i hope a newbie will not be punished for =
not knowing everything about the f-cpu.

Open questions:


** Assembler available? Anywhere. I fear, its not.



** Reset behaviour

- Where does the F-CPU start execution from after RESET ( from adress 0 ?)<= BR>
- How will the TLB=B4s be initialized on RESET

** Exception behaviour

- Where does the F-CPU branch to, if an exception occurs?

- Does an exception inside an excepion handler means RESET

** Paging

- Which special registers connect to the TLB=B4s ( Maunal 2.12 only says th= at,
this is a special register).

- Which datastructure stores the information of a page ( like size, base address, status )

** CMB=B4s

- Is this a OS defined datastructure? Needs any instruction of the cpu know=
about?

** Instructions:

- Does the F-CPU fetch the opcode as little or big endian?

- Endianness of LOADM and STOREM?

- What does SYSCALL do? Does it alter the PC? Branch the control flow to anywhere else? Where?

- Which instructions are supervisor mode only? How does the CPU leave
supervisormode?

- During execution of instructions using the PC points to the current
instruction!? ( i think so ). I think there are other cpu=B4s where it poin= ts
to the next instruction after fetch.

- Any information available about logarithmic integers? i know nothing abou= t.

- DIV, DIVI and MOD, MODI instructions. The manual says, that DIV computes<= BR>
r1 =3D r3 / r2

and DIVI computes

r1 =3D r2 / imm

This is not symmetrical in my eyes. is there any reason for this? why isnt =
the instruction redefined and r3 replaced by imm, so the computation is always:

r1 =3D r2 / r3 (DIV)

r1 =3D r2 / imm (DIVI)


- JMPA and MOVE: Does condition type "LSB" mean, that the LSB of = the register
is checked?



Best Regards,
Carsten
Yahoo! Groups Spons= or
3D""=
Personalize your company´s name. Choose the domain n= ame below and press SEARCH!
www.
3D"Y=
3D""
From Jamil Khatib Sun Feb 4 08:10:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00740 for ; Wed, 7 Feb 2001 00:51:34 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:34 +0100 (MET) Received: (qmail 30228 invoked by uid 0); 4 Feb 2001 07:10:53 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx09) with SMTP; 4 Feb 2001 07:10:53 -0000 X-eGroups-Return: sentto-1101623-2225-981270650-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 04 Feb 2001 07:10:51 -0000 X-Sender: jamilkhatib75@yahoo.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 07:10:49 -0000 Received: (qmail 86958 invoked from network); 4 Feb 2001 07:10:48 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 07:10:48 -0000 Received: from unknown (HELO web10407.mail.yahoo.com) (216.136.130.99) by mta2 with SMTP; 4 Feb 2001 07:10:48 -0000 Message-ID: <20010204071048.33534.qmail@web10407.mail.yahoo.com> Received: from [199.203.4.26] by web10407.mail.yahoo.com; Sat, 03 Feb 2001 23:10:48 PST To: f-cpu@yahoogroups.com In-Reply-To: <95drd9+88ni@eGroups.com> X-eGroups-From: Jamil Khatib From: Jamil Khatib MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Feb 2001 23:10:48 -0800 (PST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] GNU VHDL tools ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ee1798914d9518baff3aeae3997247a4 Status: R X-Status: N You can also check the tools on OpenTech cdrom at
www.opencores.org/OIPC/projects/OpenTech

Regards
Jamil Khatib

--- wibowo@computer.org wrote:
> Hi,
>
> I may have missed this, but why aren't there any
> activities in
> developing GNU tools for chip design ? Just like s/w
> development we
> have gcc, gdb etc. Why can't we have VHDL compiler,
> simulator, P&R
> tools etc ?
>
> I'm just comparing when LINUX developed, all the s/w
> development
> suite
> is already available. So it really shows a "free"
> environment for
> development without any "commercial" smell ? ;)
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
>


__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/
Yahoo! Groups Sponsor
www..com
From Yann Guidon Sun Feb 4 13:59:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00758 for ; Wed, 7 Feb 2001 00:51:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:38 +0100 (MET) Received: (qmail 28603 invoked by uid 0); 4 Feb 2001 13:23:29 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx17) with SMTP; 4 Feb 2001 13:23:29 -0000 X-eGroups-Return: sentto-1101623-2226-981291193-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 04 Feb 2001 12:53:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 12:53:12 -0000 Received: (qmail 90691 invoked from network); 4 Feb 2001 12:53:11 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 4 Feb 2001 12:53:11 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 4 Feb 2001 13:54:16 -0000 Received: from f-cpu.org (nas4-118.ras.club-internet.fr [195.36.203.118]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA04466 for ; Sun, 4 Feb 2001 13:53:08 +0100 (MET) Message-ID: <3A7D522E.F6B0FF19@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 13:59:26 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2ca5106a0176aea15a1de76fa567d7b1 Status: R X-Status: N hello !

Carsten899@aol.com wrote:
> Hi,
>
> I concentrated on reading part 6 of the manual. Perhaps i have oversee= n
> something in the other parts, but i hope a newbie will not be punished= for
> not knowing everything about the f-cpu.

<slap> on myself for not finding the time in the past to answer them.=
nobody will "punish" you for asking good question.

> Open questions:
>
> ** Assembler available? Anywhere. I fear, its not.
in the past there was a little "fight" between me and Mathias
(i think it was him) because of the syntax that was used.
I wanted a pure f-cpu syntax asm while he did a at&t asm
(which looks and read horrible but worked more).

making a nice assembler is not difficult though, i have made my own
toolkit for Flex&Bison. very nice. Now the probem is that a lot of opco= des
are undefined for the exact behaviour, and the binary values of the opcodes=
is left for definition/compilation in the future.

> ** Reset behaviour
>
> - Where does the F-CPU start execution from after RESET ( from adress = 0 ?)
good question :-)
I think it will do like in the ALPHA : it can somehow d/l some bootstrap code from an external EPROM into the internal cache and start to execute. The exact address is not defined (and it's just a value that can be changed=
in the VHDL source...).

> - How will the TLB=B4s be initialized on RESET
the entries will be all invalid and the address check is bypassed :
it will run in "kernel" mode with all capability bits on and seei= ng the whole
addressable physical memory.

> ** Exception behaviour
> - Where does the F-CPU branch to, if an exception occurs?
when an exception is detected, the core will start to fetch instructions >from a 16-instruction block located at [SR_TRAP | (trap_nr << 4)]. The SRB mechanism is triggered and execution of the block prepares a jump to the location of the real handler when more than 16 instructions are need= ed.

> - Does an exception inside an excepion handler means RESET
not yet defined. i think it can even be configured with playing with the tr= ap tables.

> ** Paging
>
> - Which special registers connect to the TLB=B4s ( Maunal 2.12 only sa= ys that,
> this is a special register).

not defined yet. We'll certainly define this when we'll program the TLB in = VHDL.


> - Which datastructure stores the information of a page ( like size, ba= se
> address, status )

not defined yet : the specifications move a lot currently.
we even added 2 counters.

> ** CMB=B4s
>
> - Is this a OS defined datastructure? Needs any instruction of the cpu= know
> about?
the is a HWed structure. it requires no special instruction because the str= ucture
is stored in memory.

> ** Instructions:
> - Does the F-CPU fetch the opcode as little or big endian?
that's an old issue... iirc we decided that endianness was not an issue
so we said that we'd code the instructions in the most practical ordering.<= BR> "practical" means : easy to decode and easy to read in a hexdump.=
So i think it is close to BE but "endianness doesn't matter here"= ,
because instructions are word-addressed, not byte-addressed.

> - Endianness of LOADM and STOREM?
"the same as for the CMB". but it's also the same problem as for = the
instructions : it's a structure with fixed-size elements so it should
be no issue. However, since they can be accessed by Load/Store instructions= ,
i think that little endian is preferrable.

> - What does SYSCALL do? Does it alter the PC? Branch the control flow = to
> anywhere else? Where?

on syscall, PC+4 is saved, and we jump to [SR_SYSCALL | (call_nr << 4= )].
kernel mode (linear adressing, access rights etc) is on and SRB is triggere= d.
linear adressing is important because it avoids some TLB misses :-)

> - Which instructions are supervisor mode only? How does the CPU leave<= BR> > supervisormode?

"supervisor mode" is when all the capability bits are set (ie aft= er reset).
the kernel can access and write all the SR, bypass the TLB etc.
IIRC there is no particular "supervisor instruction" because all = the sensitive
things are done with the SR. it frees a lot of opcodes and makes the design= easier :-)

> - During execution of instructions using the PC points to the current<= BR> > instruction!? ( i think so ). I think there are other cpu=B4s where it= points
> to the next instruction after fetch.
in fact, for FC0, there is no "real" PC :-)
the current address and PC+4 can be read from the fetcher.
it is made of 3 fields (+ the 2 cleared LSB) : the current position in the = cache line
(3 bits), the lower part of the address tag of the cache line, and the high= part
is a "shadow" (copy) of currently running TLB entry (so the user = doesn't see at
which physical address it is running). when the TLB is off, the copy is not= used
and the whole contents of the address tag is available on the Xbar for any = use.

> - Any information available about logarithmic integers? i know nothing= about.
i don't have the URL in my head but a search on google will give you what y= ou want
(i did it and it worked recently). I have a contact with an english researc= h team
(Napier laboratory or something like that, in an english university). Howev= er,
due to the current legal constraints (most designs are secret) we can leave= it
quiet until Michael makes his own version ;-) LNS is not abandonned because=
some applications might use the few opcodes it takes.

> - DIV, DIVI and MOD, MODI instructions. The manual says, that DIV comp= utes
>
> r1 =3D r3 / r2
>
> and DIVI computes
>
> r1 =3D r2 / imm
>
> This is not symmetrical in my eyes. is there any reason for this? why = isnt
> the instruction redefined and r3 replaced by imm, so the computation i= s
> always:
>
> r1 =3D r2 / r3 (DIV)
>
> r1 =3D r2 / imm (DIVI)

hmmmm i think that it's interesting :-)
however i'll have to look more closely.

> - JMPA and MOVE: Does condition type "LSB" mean, that the LS= B of the register
> is checked?

yep, the condition is the value of the LSB of the condition register.

> Best Regards,
thank you for the questions,
i simply hope that i'll find some time
to integrate the answers in the manual......

> Carsten
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www.   
=0D=
3D""
From Nicolas Boulay Sun Feb 4 16:32:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00773 for ; Wed, 7 Feb 2001 00:51:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:42 +0100 (MET) Received: (qmail 31923 invoked by uid 0); 4 Feb 2001 15:23:33 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx07) with SMTP; 4 Feb 2001 15:23:33 -0000 X-eGroups-Return: sentto-1101623-2227-981300160-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 04 Feb 2001 15:22:43 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 15:22:39 -0000 Received: (qmail 50432 invoked from network); 4 Feb 2001 15:22:38 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 4 Feb 2001 15:22:38 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 4 Feb 2001 16:23:43 -0000 Received: from ifrance.com (nas21-56.vlt.club-internet.fr [195.36.171.56]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA18413 for ; Sun, 4 Feb 2001 16:22:35 +0100 (MET) Message-ID: <3A7D7606.FF8AFAC@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 16:32:22 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 40dca172ee3f602aa1798871afda0859 Status: R X-Status: N Hello,

Yann Guidon a =E9crit :
>
> hi,
>
> Marco Al wrote:
> > From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>
> > > > Of course ! But I don't understand "binary transla= tion".
> > > >
> > > What ever happened to the idea of "Generic Opcodes"= ; that you would compile
> > > a program and the loader would translate this to real opcode= s?
> >
> > Thats what I meant, sorta.
>
> as long as it's "only" about a lookup table, it's ok.
> however, the latency/scheduling issue is more difficult to solve.
>
In Pentuim, all the unit have the same pipelined unit.

> > As long as wrong code sequences cant harm the processor and not c= ompromise
> > security the single biggest problem with exposing pipeline latenc= y is that they
> > make backward compatibility complex.
> and that's a big issue because it's our #1 goal.
> what's the point of having a very efficient CPU if the binaries can't = be reuse elsewhere ???
>

That's a very strong point. But when you see intel problem with IA64
(they said that you will have to recompile your program for the next
generation), we can't try to use the popularity of opensoftware and the
openess of the source code. Maybe an standard install will be a
./configure and not rpm-something ;p

So maybe a total binary compatibility isn't so interresting to have.

> > It also makes assembly programming a barrel
> > of laughs, but hell thats for masochists anyway's so they dont mi= nd...
> ... until they realise no compiler can do the work they expect ...
>
> > once the compiler backend is finished for most people it doesnt m= atter.
>
> > Binary translation is an alternative to hiding the pipeline struc= ture for backwards
> > compatibility.
>
> binary translation looks fine ... but how ?
> if it's SW (others are looking at transmeta) no way for me.
> sure, f-cpu isa is much easier than x86 to translate. however, the
> SW is still diffucult to write and it's going to take years ...
>
> if it's HW, it's the best solution for me. there is no compatibility a= nd

Best solution ? Translation is always translation, HW or SW you have the same thing to do. But HW is much more complicated to write !

> less performance issue. it's probably one of the ways to use if we wan= t to
> go beyond 4 IPC. Here, we benefit from the ISA simplicity and we would=
> get much performance than on a P4. all we want to check is the depende= ncy
> between the instructions during a certain window (as large as the pipe= line
> depth) so all we have to store in the cache (on top of the instruction= s themselves)
> is the "boundary" between the packets (just like on the old = good pentiums).
>
> but of course, we have enough time to discuss about that. we gotta mak= e the
> single-issue version work first :-)
>
> > Marco
> WHYGEE
nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.   
=0D
3D""
From Nicolas Boulay Sun Feb 4 16:40:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00779 for ; Wed, 7 Feb 2001 00:51:44 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:44 +0100 (MET) Received: (qmail 13492 invoked by uid 0); 4 Feb 2001 15:34:46 -0000 Received: from hk.egroups.com (208.50.99.220) by 10.1.4.106 (mx06) with SMTP; 4 Feb 2001 15:34:46 -0000 X-eGroups-Return: sentto-1101623-2228-981300643-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 Feb 2001 15:30:58 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 15:30:42 -0000 Received: (qmail 80163 invoked from network); 4 Feb 2001 15:30:42 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 Feb 2001 15:30:42 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 4 Feb 2001 15:30:41 -0000 Received: from ifrance.com (nas21-56.vlt.club-internet.fr [195.36.171.56]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA17352 for ; Sun, 4 Feb 2001 16:30:38 +0100 (MET) Message-ID: <3A7D77EA.EAD3CDB8@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <000b01c08e2a$04250700$29e65982@student.utwente.nl> <3A7C7E96.5970CC19@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 16:40:26 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 79ff333b143919cf6f4e9070b9b1a288 Status: R X-Status: N re,

Yann Guidon a =E9crit :
>
> hi !
>
<snip>
> > > it's probably one of the ways to use if we want to
> > > go beyond 4 IPC. Here, we benefit from the ISA simplicity an= d we would
> > > get much performance than on a P4. all we want to check is t= he dependency
> > > between the instructions during a certain window (as large a= s the pipeline
> > > depth) so all we have to store in the cache (on top of the i= nstructions themselves)
> > > is the "boundary" between the packets (just like o= n the old good pentiums).
> > Or you could put 3*X bits (X being 2 or 3) in the instructions to= encode
> > dependencies directly, or for a non performance portable method (= because it
> > makes assumptions about the pipeline) just encode execution delay= 's in the
> > instructions directly
> no and no.
> 1) the instruction word is already defined and there's no room for suc= h additional bits.
> In the discussion with NicO, i pointed out however that a special inst= ruction could
> pack these bits externally for a whole cache line (1 instruction each = 8, so 3 bits per
> instruction). It has the advantage that when compacity is required, th= e compiler could
> turn the pack instruction generation to gain 1/8 of room/bandwidth. > 2) encoding the delay/latency in the instruction is another mistake be= cause the
> new platforms could have radically different scheduling rules. it is n= ot portable.
> it could however be coded in the "pack" instruction because = this instruction can be
> interpreted as a NOP on the architectures that don't support or comply= this.
>

This encoding will be portable ! The one dependancie bit is portable
(same value could be execute in the same cycle). If this bit is false
you will have registers mismatch and it will be the user faults
(compiler or asm writer).

> > (someone pointed a nice ICCD paper about that out to me,
> > http://www.ai.mit= .edu/~jpg/pub.html top paper... there's more interesting stuff
> > there).
> thanks ! i'm currently downloading these files.
>
me too.
> > Marco
> WHYGEE
nicO
Yahoo! Groups Spons= or
3D""3D""<= /a>
www. .com&nbs= p;
3D""
From Carsten899@aol.com Sun Feb 4 19:07:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00794 for ; Wed, 7 Feb 2001 00:51:48 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:48 +0100 (MET) Received: (qmail 8419 invoked by uid 0); 4 Feb 2001 18:31:52 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx24) with SMTP; 4 Feb 2001 18:31:52 -0000 X-eGroups-Return: sentto-1101623-2229-981310037-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 04 Feb 2001 18:07:20 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 18:07:16 -0000 Received: (qmail 66776 invoked from network); 4 Feb 2001 18:07:16 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 4 Feb 2001 18:07:16 -0000 Received: from unknown (HELO imo-r09.mx.aol.com) (152.163.225.9) by mta3 with SMTP; 4 Feb 2001 19:08:21 -0000 Received: from Carsten899@aol.com by imo-r09.mx.aol.com (mail_out_v29.5.) id r.78.101734ae (4422) for ; Sun, 4 Feb 2001 13:07:05 -0500 (EST) Message-ID: <78.101734ae.27aef448@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 13:07:04 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1de0481185a85378db2d240c560467b1 Status: R X-Status: N Hi,

thank you for the answers. I think i have to have a deeper look at the SR
mechanism.

The non defined topics are a little problem for writing an instruction-level
emulator, but can all be worked around. What is your opinion about an
instruction-level emulator in general? I think for serious
software-development it must  have pageing / trap - emulation - so the need
for defining would arise, as early as someone wants to start such a
development - if ever.

As i had a lot of time this weekend i already did a lot of coding - not
testing :-) - of the "instruction level emulator". It has about 80% of the
instructions implemented. Also implemented is a simple assembler which uses
the instruction code syntax from the manual. I did some assumptions on
non-defined topics ( Syntax of JMPA and MOVE - Instruction )

The following code was successfully run before i wrote this message :-)))

00000000    loadcons.0    FFFF,r1
00000004    loadcons.1    1234,r1
00000008    loadcons.2    6634,r1
0000000C    loadcons.3    5534,r1
00000010    loadconsx.2   8000,r2
00000014    loadconsx.2   0,r3
00000018    load.b        r0,r3,r4
0000001C    load.d        r0,r3,r5
00000020    load.q        r0,r3,r6
00000024    load          r0,r3,r7
00000028    saddc.b       r4,r5,r8
0000002C    halt

The sourcecode should be endian independent, but needs an compiler with an
native signed 64 Bit datatype ( like __int64 on msvc ).

Is there anybody who wants to play with the early emulator and write small
assembler-programs which can be used "testvectors" for the many, many
instructions? i would really appreciate this, because i will not have as much
time in the future as i had this weekend. I am sure there are many bugs still
in the code, because i heavily used copy and paste of sourceode.

Is it possible to post attachments on the mailing list?

Best regards,
Carsten
Yahoo! Groups Sponsor

www.   
From Gordon Cichon Sun Feb 4 19:49:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00807 for ; Wed, 7 Feb 2001 00:51:50 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:50 +0100 (MET) Received: (qmail 11177 invoked by uid 0); 4 Feb 2001 18:54:12 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx17) with SMTP; 4 Feb 2001 18:54:12 -0000 X-eGroups-Return: sentto-1101623-2230-981312601-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 04 Feb 2001 18:54:05 -0000 X-Sender: gordon@cichon.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 18:50:01 -0000 Received: (qmail 53019 invoked from network); 4 Feb 2001 18:50:00 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 18:50:00 -0000 Received: from unknown (HELO sh.cichon.com) (63.125.155.228) by mta2 with SMTP; 4 Feb 2001 18:50:00 -0000 Received: from cichon.com (localhost [127.0.0.1]) by sh.cichon.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA17104 for ; Sun, 4 Feb 2001 10:49:59 -0800 Sender: gordon@cichon.com Message-ID: <3A7DA448.616D024C@cichon.com> X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> From: Gordon Cichon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 19:49:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Unsubscribe?!? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1bf12ff42e1294cb02cf42d3016edbc9 Status: R X-Status: N Hi Guys,

is there any way to unsubscribe this mailing list without exposing my CV
to yahoo? I can't believe my eyes! I mean, this can't be true!

Gordon.
Yahoo! Groups Sponsor

www.   
From rafar@lcc.uma.es Sun Feb 4 22:39:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00812 for ; Wed, 7 Feb 2001 00:51:51 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:51 +0100 (MET) Received: (qmail 500 invoked by uid 0); 4 Feb 2001 20:36:06 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx05) with SMTP; 4 Feb 2001 20:36:06 -0000 X-eGroups-Return: sentto-1101623-2231-981318744-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 04 Feb 2001 20:32:35 -0000 X-Sender: rafar@lcc.uma.es X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 20:32:23 -0000 Received: (qmail 54477 invoked from network); 4 Feb 2001 20:32:23 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 Feb 2001 20:32:23 -0000 Received: from unknown (HELO rh20.eresmas.com) (62.81.160.170) by mta1 with SMTP; 4 Feb 2001 20:32:22 -0000 Received: from tu@eresmas ([62.83.105.82]) by rh20.eresmas.com (Netscape Messaging Server 4.15) with ESMTP id G88G3J00.UTT for ; Sun, 4 Feb 2001 13:30:55 +0100 To: f-cpu@yahoogroups.com Message-ID: <3A7DCC24.12559.C1074@localhost> Priority: normal In-reply-to: <3A7DA448.616D024C@cichon.com> X-mailer: Pegasus Mail for Win32 (v3.12c) From: rafar@lcc.uma.es MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 21:39:48 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Unsubscribe?!? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: db73fff6347dccf4740307f9d69356be Status: R X-Status: N Please, I want to Unsubscribe from free cpu list
Yahoo! Groups Sponsor

www.
From Yann Guidon Sun Feb 4 22:42:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00820 for ; Wed, 7 Feb 2001 00:51:51 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:51 +0100 (MET) Received: (qmail 15068 invoked by uid 0); 4 Feb 2001 21:36:46 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx17) with SMTP; 4 Feb 2001 21:36:46 -0000 X-eGroups-Return: sentto-1101623-2232-981322603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 04 Feb 2001 21:36:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 21:36:43 -0000 Received: (qmail 37434 invoked from network); 4 Feb 2001 21:36:42 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 21:36:42 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 4 Feb 2001 21:36:41 -0000 Received: from f-cpu.org (nas3-100.aub.club-internet.fr [195.36.145.100]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA21094 for ; Sun, 4 Feb 2001 22:36:28 +0100 (MET) Message-ID: <3A7DCCD2.30BAB1EB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 22:42:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] epf2001 slides Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c6748a72b32c9a917f8e614555fcd1be Status: R X-Status: N hello,
i have started to put the slides into HTML.
5 slides are ready.

it is located at http://www.f-cpu.de/epf2001/

the reasons why i do it :
- it is a good way to present the CPU
- it complements/summarizes the manual
- it's a short introduction that is useful
    for the forum and the f-cpu newcomers.
- plus, it helps me cristalize the fundamentals
    of the design :-) the manual is simply
    getting too huge...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www..com
From Michael Riepe Sun Feb 4 14:21:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00825 for ; Wed, 7 Feb 2001 00:51:52 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:52 +0100 (MET) Received: (qmail 32746 invoked by uid 0); 4 Feb 2001 22:34:11 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 4 Feb 2001 22:34:11 -0000 X-eGroups-Return: sentto-1101623-2233-981326026-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 04 Feb 2001 22:33:49 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 22:33:38 -0000 Received: (qmail 66256 invoked from network); 4 Feb 2001 22:33:38 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 4 Feb 2001 22:33:38 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.105) by mta1 with SMTP; 4 Feb 2001 22:33:36 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00452; Sun, 4 Feb 2001 14:21:22 +0100 Message-ID: <20010204142122.40302@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7D522E.F6B0FF19@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A7D522E.F6B0FF19@f-cpu.org>; from Yann Guidon on Sun, Feb 04, 2001 at 01:59:26PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 14:21:22 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ef62e12d3d7fb430cf7323de790657f6 Status: R X-Status: N On Sun, Feb 04, 2001 at 01:59:26PM +0100, Yann Guidon wrote:
[...]
> > - Any information available about logarithmic integers? i know nothing about.
> i don't have the URL in my head but a search on google will give you what you want
> (i did it and it worked recently). I have a contact with an english research team
> (Napier laboratory or something like that, in an english university). However,
> due to the current legal constraints (most designs are secret) we can leave it
> quiet until Michael makes his own version ;-) LNS is not abandonned because
> some applications might use the few opcodes it takes.

I'm not so sure that LNS was a good idea in the first place.  Operations
on LNS operands seem to be quite expensive, much more than in IEEE format.

> > - DIV, DIVI and MOD, MODI instructions. The manual says, that DIV computes
> >
> > r1 = r3 / r2
> >
> > and DIVI computes
> >
> > r1 = r2 / imm
> >
> > This is not symmetrical in my eyes. is there any reason for this? why isnt
> > the instruction redefined and r3 replaced by imm, so the computation is
> > always:
> >
> > r1 = r2 / r3 (DIV)
> >
> > r1 = r2 / imm (DIVI)
>
> hmmmm i think that it's interesting :-)
> however i'll have to look more closely.

The ISA should be consistent in that point, i.e. the SUB instruction
should also calculate `r1 = r2 - r3' then, and so on.  I like the idea,
though -- the registers are nicely numbered from left to right (or right
to left, in the asm instruction), and the operands are always placed in
the same 6-bit slots of the instruction word.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.
From Lee Salzman Sun Feb 4 23:51:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00829 for ; Wed, 7 Feb 2001 00:51:53 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:53 +0100 (MET) Received: (qmail 29087 invoked by uid 0); 4 Feb 2001 22:56:05 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx15) with SMTP; 4 Feb 2001 22:56:05 -0000 X-eGroups-Return: sentto-1101623-2234-981327357-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 04 Feb 2001 22:56:02 -0000 X-Sender: lee.salzman@lvdi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 22:55:56 -0000 Received: (qmail 80951 invoked from network); 4 Feb 2001 22:55:55 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 4 Feb 2001 22:55:55 -0000 Received: from unknown (HELO lvdi.net) (216.24.138.2) by mta2 with SMTP; 4 Feb 2001 22:55:54 -0000 Received: from lvdi.net ([128.2.166.156]) by lvdi.net ; Sun, 04 Feb 2001 14:55:51 2000 PDT Sender: lee@pop.gmx.net Message-ID: <3A7DDCF2.3C7B48A0@lvdi.net> X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.4.0 i686) X-Accept-Language: en To: f-cpu@yahoogroups.com From: Lee Salzman MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 17:51:30 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c47c2b30ad1d2a986550557be4d30f04 Status: R X-Status: N Carsten wrote:
>Is there anybody who wants to play with the early emulator and
>write small assembler-programs which can be used "testvectors"
>for the many, many instructions? i would really appreciate this,
>because i will not have as much time in the future as i had this
>weekend.

   If you're looking for a good source of test programs, I urge
you to take a look at the GCC port to F-CPU (more information at
http://www.f-cpu.de/gcc/). It would be nice if you could take
some simple C programs, compile them, and test they actually
do what they're supposed to do in the emulator. The generated
code should be correct but some if depends on esoteric features
of the F-CPU so it should be a good way to test the correctness
of your emulator as well.

                        Lee Salzman
Yahoo! Groups Sponsor

www.   
From Michael Riepe Mon Feb 5 00:03:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00836 for ; Wed, 7 Feb 2001 00:51:54 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:54 +0100 (MET) Received: (qmail 29824 invoked by uid 0); 4 Feb 2001 23:03:30 -0000 Received: from hm.egroups.com (208.50.99.198) by 10.1.4.112 (mx12) with SMTP; 4 Feb 2001 23:03:30 -0000 X-eGroups-Return: sentto-1101623-2235-981327805-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 04 Feb 2001 23:03:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:03:23 -0000 Received: (qmail 35597 invoked from network); 4 Feb 2001 23:03:22 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 23:03:22 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.105) by mta2 with SMTP; 4 Feb 2001 23:03:20 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02065; Mon, 5 Feb 2001 00:03:17 +0100 Message-ID: <20010205000316.29241@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> X-Mailer: Mutt 0.84e In-Reply-To: <78.101734ae.27aef448@aol.com>; from Carsten899@aol.com on Sun, Feb 04, 2001 at 01:07:04PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 00:03:16 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5b02c7cc40a8627eb0830e0821242b57 Status: R X-Status: N On Sun, Feb 04, 2001 at 01:07:04PM -0500, Carsten899@aol.com wrote:
[...]
> As i had a lot of time this weekend i already did a lot of coding - not
> testing :-) - of the "instruction level emulator". It has about 80% of the
> instructions implemented. Also implemented is a simple assembler which uses
> the instruction code syntax from the manual. I did some assumptions on
> non-defined topics ( Syntax of JMPA and MOVE - Instruction )

Well... where's the source? ;)

> The sourcecode should be endian independent, but needs an compiler with an
> native signed 64 Bit datatype ( like __int64 on msvc ).

No problem with gcc (use `long long' on intel boxen).

> Is there anybody who wants to play with the early emulator and write small
> assembler-programs which can be used "testvectors" for the many, many
> instructions? i would really appreciate this, because i will not have as much
> time in the future as i had this weekend. I am sure there are many bugs still
> in the code, because i heavily used copy and paste of sourceode.
>
> Is it possible to post attachments on the mailing list?

Yes, of course.  If they aren't too big...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
From Rares Marian Mon Feb 5 00:19:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00842 for ; Wed, 7 Feb 2001 00:51:55 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:55 +0100 (MET) Received: (qmail 29574 invoked by uid 0); 4 Feb 2001 23:14:02 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx17) with SMTP; 4 Feb 2001 23:14:02 -0000 X-eGroups-Return: sentto-1101623-2236-981328430-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 04 Feb 2001 23:13:53 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:13:48 -0000 Received: (qmail 20285 invoked from network); 4 Feb 2001 23:13:47 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 4 Feb 2001 23:13:47 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 4 Feb 2001 23:13:47 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 272FD46016; Sun, 4 Feb 2001 18:19:17 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204181916.A30499@moonbase.res.wpi.net> X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 18:19:16 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a15f274a2921d428f192b3e19d4d33dc Status: R X-Status: N The line r1 = r2 - r3 made me blink for a second.

Why?

Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
defined I don't know exactly what a fact would look like in code). 

The idea is that rather than constantly feeding the cpu instructions, you
feed it facts, goals, and a vector to call when it gets an answer.  You
would free up the bandwidth considerably because you no long need to
spoonfeed every little detail.  You could even use the bandwidth to take
care of nasty critical things like cache coherence.

Rares
Yahoo! Groups Sponsor

www.

From Yann Guidon Mon Feb 5 00:29:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00845 for ; Wed, 7 Feb 2001 00:51:55 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:51:55 +0100 (MET) Received: (qmail 2474 invoked by uid 0); 4 Feb 2001 23:25:30 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx13) with SMTP; 4 Feb 2001 23:25:30 -0000 X-eGroups-Return: sentto-1101623-2238-981329012-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 Feb 2001 23:23:39 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:23:31 -0000 Received: (qmail 57785 invoked from network); 4 Feb 2001 23:23:30 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 4 Feb 2001 23:23:30 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 4 Feb 2001 23:23:29 -0000 Received: from f-cpu.org (nas4-132.aub.club-internet.fr [195.36.145.132]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA21185 for ; Mon, 5 Feb 2001 00:23:23 +0100 (MET) Message-ID: <3A7DE5E6.F1AD85A9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 00:29:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: multipart/mixed; boundary="------------7382E48C2BC27384503DB2A5" X-UIDL: 055ced2f8d9eb728431531f4c908df16 Status: R X-Status: N --------------7382E48C2BC27384503DB2A5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello !

Carsten899@aol.com wrote:
> Hi,
>
> thank you for the answers. I think i have to have a deeper look at the SR
> mechanism.

it's basicly rather simple.
it looks like the MSR in the Pentium, except that almost everything
is managed with the SR. these special registers can be selectively
protected and have no impact on the pipeline because their
access stalls the pipeline.

In short : anything that can't be done with the usual pipeline
(with the rules of atomicity, simplicity and determinism)
should be done with the SR, ie memory management, implementation-dependent
features and even semaphores !

there are some SR defined, i have enclosed a definition file
to help you. This can be translated to a .h file.
I have also enclosed another file with the opcodes
in a "clean" organisation (even though everything is temporary).
it can help you.

> The non defined topics are a little problem for writing an instruction-level
> emulator, but can all be worked around.
well two solutions to use at the same time :
- common sense (you know, brain :-D)
- speak about them.

> What is your opinion about an
> instruction-level emulator in general? I think for serious
> software-development it must  have pageing / trap - emulation - so the need
> for defining would arise, as early as someone wants to start such a
> development - if ever.

the memory protection issue can give you serious troubles.
and please keep the widths as configurable as possible,
read the .vhdl file for more information.

> As i had a lot of time this weekend i already did a lot of coding - not
> testing :-) - of the "instruction level emulator". It has about 80% of the
> instructions implemented. Also implemented is a simple assembler which uses
> the instruction code syntax from the manual. I did some assumptions on
> non-defined topics ( Syntax of JMPA and MOVE - Instruction )

if you made assumptions, please at least say it in your comments in the source
file :-)

> The following code was successfully run before i wrote this message :-)))
<snip>

wow :-)

> The sourcecode should be endian independent, but needs an compiler with an
> native signed 64 Bit datatype ( like __int64 on msvc ).
hmmm grumble grumble... that's a problem.
years ago, i had overcome this problem : using only arrays of bytes.
that's all. Every operation was performed with bytes. hyper-portable,
at the cost of some serious speed, but highly SIMD :-) plus,
a 512-bit version could be done for example.

> Is there anybody who wants to play with the early emulator and write small
> assembler-programs which can be used "testvectors" for the many, many
> instructions? i would really appreciate this, because i will not have as much
> time in the future as i had this weekend. I am sure there are many bugs still
> in the code, because i heavily used copy and paste of sourceode.

yeah, peer review rocks :-)
setup a website with your sources and upload the files there,
so anybody can see and try.

> Is it possible to post attachments on the mailing list?
yup, if it's reasonable. compress (zip/gz) if possible.

> Best regards,
> Carsten
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.
--------------7382E48C2BC27384503DB2A5 Content-Type: text/plain; charset=us-ascii; name="f-cpu_config.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f-cpu_config.vhdl" -- File F-CPU_config.vhdl -- (c) Yann GUIDON, oct. 21, 2000 -- whygee@f-cpu.org / f-cpu@egroups.com -- -- v0.2 : Michael Riepe changed F_RANGE -- v0.3 : YG specified the user-modifiable constants + GPL -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants. -- v0.5 : nov. 17, 2000, YG added SR_IRQ_BASE, SR_TRAP_BASE, -- SR_SYSCALL_BASE, SR_URL etc. -- v0.6 : nov. 26, 2000, YG moved some SR stuff to /VHDL/EU_sr -- v0.7 : dec. 31, 2000, YG added SR_MAX_CHUNK_SIZE and SR_TLBMISS_BASE -- -- current release : dec. 31, 2000 -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. -- -- * LOGMAXSIZE : Log2 of the Size of the registers in bytes. -- Can be any integer above or equal to 2. 2 corresponds to -- a 32-bit implementation, 3 correspods to a 64-bit version. -- This is the most important parameter, the first with -- which one can play. Be careful anyway. The 32-bit version will -- not work yet. -- -- * L1LogLines : Log2 of the NumBer of cache Lines (MUST be EVEN) -- This parameter determines how many L1 cache lines are implemented. -- It must be >=4 and _even_ because of the particular LRU mechanism -- used for this prototype. Allowed values are 4, 6 or 8 (that is : -- 16, 64 or 256 lines, or 512 bytes, 2KB or 8KB). More would correspond -- to a L2 cache... but are possible if you have enough ressources. -- -- * L1ABwidth :Address Bus width, in 32-byte chuncks (32+5=128GB) -- This determines the width of the address comparator of every L1 -- cache line. Be careful, too many bits might require a LOT of ressources. -- A reasonable value for a small design would be 16 (2MB of adressable -- physical memory), adapt as required. Warning : this parameter -- also determines how many address bits are physically implemented. -- -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ -- Number >=2, 3 corresponds to 64-bit registers constant LOGMAXSIZE : natural := 3; -- Size of the registers in bytes constant MAXSIZE : natural := 2**LOGMAXSIZE; -- Size of the registers in bits. constant UMAX : natural := MAXSIZE * 8; -- Range of a register width declaration. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- shortcut for a very common declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; -- MAX_CHUNK_SIZE in bits constant MAX_CHUNK_SIZE : natural := 64 ; ------------------------------------------------------ -- Some architectural constants, bound to FC0 only : ------------------------------------------------------ ------------------------------------------------------ -- L1 Caches (split instructions and data) ------------------------------------------------------ -- Data Bus width, or width of each cache line (32 bytes) constant L1DBwidth : natural := 256 ; -- Address Bus width, in 32-byte chuncks (32+5=128GB) constant L1ABwidth : natural := 32 ; -- Log2 of the NumBer of cache Lines (MUST be EVEN) -- (small number for the first attempts) constant L1LogLines : natural := 6 ; -- NumBer of cache Lines (2**L1LogLines) constant L1NBlines : natural := 2**L1LogLines ; ------------------------------------------------------ -- The Special Registers : (adapted from SR.h) -- -- What the user should modify when implementing the core : -- * SR_NUMBERS_val should be updated when the -- number of implemented SR changes. -- * SR_FAMILY_val specifies the type of core (FC0, FC1 etc). -- This is meant to be used for selecting particular code -- sections that are optimized for certain cores. -- * SR_STEPPING_val specifies the mask revision, for example. -- * SR_URL_val contains the Internet URL where the source, -- software and documentation are stored (64 char max.) -- -- DO NOT MODIFY the other constants unless the specifications -- change. New SRs will appear soon. Stay tuned. ------------------------------------------------------ -- number of SRs that are implemented in this model constant SR_NUMBERS : natural := 0; constant SR_NUMBERS_val : natural := SR_LAST_SR; -- F-CPU core number. remark : 0xFC0 = 4032d :-) constant SR_FAMILY : natural := 1; constant SR_FAMILY_val : natural := 4032; -- revision/implementation constant SR_STEPPING : natural := 2; constant SR_STEPPING_val : natural := 1; -- in bytes, a power of two >= 4 constant SR_MAX_SIZE : natural := 3; constant SR_MAX_SIZE_val : natural := MAXSIZE; -- Size attribute 1, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_1 : natural := 4; constant SR_SIZE_1_val : natural := 1; -- Size attribute 2, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_2 : natural := 5; constant SR_SIZE_2_val : natural := 2; -- Size attribute 3, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_3 : natural := 6; constant SR_SIZE_3_val : natural := 4; -- Size attribute 4, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_4 : natural := 7; constant SR_SIZE_4_val : natural := 8; -- SIMD chunck size, hardwired. constant SR_MAX_CHUNK_SIZE : natural := 8; constant SR_MAX_CHUNK_SIZE_val : natural := MAX_CHUNK_SIZE*8; -- R/W, Value is dynamic, incremented every cycle. constant SR_CYCLE : natural := 9; -- Protected, R/W, Controls the paged memory. constant SR_PAGING : natural := 10; -- IRQ, TRAP and SYSCALL jump tables : all are R/W in protected mode - only. constant SR_IRQ_BASE : natural := 11; -- For the hardware interrupt requests constant SR_IRQ_SIZE : natural := 12; constant SR_TRAP_BASE : natural := 13; -- faults and system errors constant SR_TRAP_SIZE : natural := 14; constant SR_SYSCALL_BASE : natural := 15; -- OS system call constant SR_SYSCALL_SIZE : natural := 16; constant SR_TLBMISS_BASE : natural := 17; -- TLB miss trap -- The URL registers must be modified to point to the manual, sources, patches etc. -- The registers are hardwired, format is ASCII and padded with 0s. constant SR_URL : natural := 18; -- 64 characters max. for a 64-bit version, 32 chars for a 32-bit version... constant SR_URL_size : natural := 8; constant SR_URL_val : string := "http://www.f-cpu.de/design/"; -- last SR : constant SR_LAST_SR : natural := 26; ------------------------------------------------------- -- The ROP2 unit : these constants specify the -- correspondance between the binary code and the actual -- operation. These data are copied here for convenience -- only, for example if you want to make an assembler in -- VHDL. Check the file ROP2.vhdl for more informations. -------------------------------------------------------- constant ROP2_AND : natural := 0; constant ROP2_ANDN : natural := 1; constant ROP2_XOR : natural := 2; constant ROP2_OR : natural := 3; constant ROP2_NOR : natural := 4; constant ROP2_XNOR : natural := 5; constant ROP2_ORN : natural := 6; constant ROP2_NAND : natural := 7; end FCPU_config; package body FCPU_config is -- The use of the ilog functions is not recommended inside -- the synthesisable processes, they are provided for -- convenience only. -- integer logarithm (rounded up) [MR version] function ilog (x : natural; base : natural := 2) return natural is variable y : natural := 1; begin while x > base ** y loop y := y + 1; end loop; return y; end ilog; -- integer logarithm (rounded up) [YG version] -- i wonder if there is an off-by-1 error... ? function ilog2 (x : natural) return natural is variable y : natural := 1; variable z : natural := 1; begin while x > z loop y := y + 1; z := z + z; -- you can notice the "little" enhancement :o) end loop; return y; end ilog2; ------------------------------------------------------ -- Some useful wrappers or functions could be included -- here if they are necessary for rest of the project. ------------------------------------------------------ end FCPU_config; --------------7382E48C2BC27384503DB2A5 Content-Type: application/x-unknown-content-type-H_auto_file; name="f-cpu_map.h" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f-cpu_map.h" I2lmbmRlZiBfX0ZDUFVfTUFQX18NCiNkZWZpbmUgX19GQ1BVX01BUF9fDQoNCi8qDQogICAg Ri1DUFUgT1BDT0RFIE1BUCwgUFJFTElNSU5BUlkgVkVSU0lPTg0KICAgIChDKSBZYW5uIEd1 aWRvbiB2ZW4gbWFyIDMxIDE3OjA2OjQyIENFU1QgMjAwMA0KDQpXYXJuaW5nIDogYSAuaCBm aWxlIGlzIG1lYW50IHRvIGNvbnRhaW4gY29uc3RhbnRzIHRoYXQgbWF5DQpjaGFuZ2UgaW4g dGhlIGZ1dHVyZSwgYW5kIHRoaXMgZmlsZSBpcyBubyBleGNlcHRpb24gIQ0KVGhlIGRlZmlu ZWQgdmFsdWVzIFdJTEwgY2hhbmdlIGFmdGVyIHRoZSBvcGNvZGVzIGFyZQ0KYWxsIGFuYWx5 c2VkLCBzbyBpdCdsbCB0YWtlIGxlc3MgbG9naWMgZ2F0ZXMgdG8gZGVjb2RlIHRoZQ0KaW5z dHJ1Y3Rpb25zLg0KDQoNClRoaXMgZG9jdW1lbnQgaXMgZGVyaXZlZCBmcm9tIHRoZSBidWdn eSBGLUNQVSBtYW51YWwgcmV2LiAwLjENCmFuZCB3aWxsIGNoYW5nZSBxdWlja2x5LiBCZSBz dXJlIHRvIGRvd25sb2FkIHRoZSBtb3N0IHJlY2VudA0KdmVyc2lvbiBhbmQgaW5jbHVkZSBp dCBhcyAiZi1jcHVfbWFwLmgiIGluIHlvdXIgZmlsZXMuDQoNClRoaXMgaXMgZnJlZSBzb2Z0 d2FyZSA7IHNlZSB0aGUgR1BMIGZvciBjb3B5aW5nIGNvbmRprQ0KdGlvbnMuIFRoZXJlIGlz IE5PIHdhcnJhbnR5IDsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWQ0Kb3IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCmNvbnRhY3RzIDogd2h5Z2VlQGYtY3B1 Lm9yZyBvciBmLWNwdUBlR3JvdXBzLmNvbQ0KDQogIE9yZ2FuaXphdGlvbiBvZiB0aGUgb3Bj b2RlcyA6DQpUaGUgZGVmaW5lZCBudW1iZXJzIHJlZmVyIHRvIGEgYnl0ZSBsb2NhdGVkIGlu IGJpdHMgMCB0byA3IGluIHRoZSBpbnN0cnVjdGlvbiB3b3JkLg0KVGhlICItSSIgc3VmZml4 IGlzIG9kZCwgbWVhbmluZyBpOHJyIGZvcm1hdCAodGhpcyBjb3VsZCBiZSBjaGFuZ2VkLCB0 byBhIE1TQiBmb3IgZXhhbXBsZSkuDQpUaGUgaW5zdHJ1Y3Rpb24gImJsb2NrcyIgYXJlIG5v dCBtdWNoIG1vcmUgdGhhbiAzMiBvcGNvZGVzIHNvIHRoZXkgY2FuIGJlIHBhY2tlZA0KIHdp dGggdGhpcyBncmFudWxhcml0eS4NCkFsbCB0aGVzZSBudW1iZXJzIHdpbGwgYmUgcmVvcmdh bml6ZWQgbGF0ZXIgZm9yIHRoZSBWTElXIGJvdW5kYXJ5IHRyaWNrLg0KDQogdG90YWwgY291 bnQgOiAxMDQsIHdpdGhvdXQgY291bnRpbmcgbXVsdGlwbGUgb2NjdXJlbmNlIG9mIEJJVE9Q KEkpLA0KQ09NQklORSh4eCkgYW5kIExPQURDT05TKFgpIA0KDQpJZiBpIGhhdmUgdGltZSBh bmQgZW5lcmd5LCBpJ2xsIG1ha2UgYSBuaWNlIGNvbG9yZWQgSFRNTCB0YWJsZSBvbmUgZGF5 Lg0KKi8NCg0KDQovKg0KdXBkYXRlIDogWUcsIDgvMTkvMjAwMA0KVGhpcyBpcyB0aGUgd29y a2luZyB2ZXJzaW9uIGZvciB0aGUgZmluYWwgbWFudWFsIHYwLjIuDQp2MC4yIHdpbGwgaGF2 ZSB0byBiZSB1cGRhdGVkIHdpdGggdGhlIGRhdGEgaW5jbHVkZWQgaW4gdGhpcyBmaWxlLg0K YWRkZWQgOiA4IG9wY29kZXMgOiBWTElXeCwgU0NBVFRFUiwgR0FUSEVSLCBQRVJNVVRFLg0K cmVkdWNlZCA6IElOQywgREVDLCBBQlMsIE5FRy4NCnRvdGFsIGNvdW50IDoNCiAoUlJSPTQ2 K1JSPTE1K0k4UlI9MjcrSTE2Uj0xMitJMjRSPTEwK05PUCtWTElXKT0xMTIgZGVmaW5lcywN CiBvcGNvZGVzIDogMTE2DQp0aGVyZSdzIGEgIndob2xlIiBhdCBuZWFyIHRoZSBJTkMgYW5k IHNvbWV3aGVyZSBlbHNlLg0Kd2UgYmVnaW4gdG8gYWRkIHNvbWUgYWxpYXNlcyAoX09QX05P UCAuLi4pIGFuZCBvdGhlciBzdHVmZnMuDQoqLw0KDQojZGVmaW5lIF9PUF9MQVNUX09QQ09E RSAgICBfT1BfR0FUSEVSDQovKiAxMjggKi8NCg0KLyoNCiBGb3JtYXQgemVybyA6IFJSUg0K IC0tLS0tLS0tLS0tLS0tLS0tDQogY291bnQ9NDYNCg0KdGhpcyB0YWtlcyBvbmUgaGFsZiBv ZiB0aGUgd2hvbGUgb3Bjb2RlIHRhYmxlICgyNTYgaW5zdHJ1Y3Rpb25zKQ0KDQoqLw0KDQov KiBub3QgYSByZWFsICJvcGVyYXRpb24iIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBkYXRhIGFy ZSBub3QgbW9kaWZpZWQgKi8NCiNkZWZpbmUgX09QX01PVkUgICAgICAgICAwDQovKiBzbyBO T1AgaXMgZGV0ZWN0ZWQgd2l0aCBhbiBpbnN0cnVjdGlvbiBlcXVhbCB0byB6ZXJvICovDQoN CiNkZWZpbmUgX09QX05PUCAwDQovKiBmb2xsb3dlZCBieSAzIGVtcHR5IGJ5dGVzLCBidXQg dGhlIDYgbGFzdCBiaXRzIChkZXN0IHJlZykgY2FuIGJlIHRlc3RlZCBub3cgdG8gc2ltcGxp ZnkgdGhpbmdzLiAqLw0KDQovKiBJbnRlZ2VyIGFyaXRobWV0aWNzICovDQojZGVmaW5lIF9P UF9BREQgICAgICAgICAgMg0KI2RlZmluZSBfT1BfU1VCICAgICAgICAgIDQNCiNkZWZpbmUg X09QX01VTCAgICAgICAgICA2DQojZGVmaW5lIF9PUF9ESVYgICAgICAgICAgOA0KI2RlZmlu ZSBfT1BfTU9EICAgICAgICAgIDEwDQojZGVmaW5lIF9PUF9BRERTVUIgICAgICAgMTINCiNk ZWZpbmUgX09QX01BQyAgICAgICAgICAxMw0KDQovKiBub3QgcmVhbGx5IGFyaXRobWV0aWMu Li4gKi8NCiNkZWZpbmUgX09QX1BPUENPVU5UICAgICAxNA0KDQovKiBJTkMtYmFzZWQgaW5z dHJ1Y3Rpb25zICovDQojZGVmaW5lIF9PUF9DTVBMICAgICAgICAgMjQNCiNkZWZpbmUgX09Q X0NNUExFICAgICAgICAyNg0KI2RlZmluZSBfT1BfTUFYICAgICAgICAgIDI4DQojZGVmaW5l IF9PUF9NSU4gICAgICAgICAgMzANCiNkZWZpbmUgX09QX1NPUlQgICAgICAgICAyMQ0KDQov KiBMTlMgb3BlcmF0aW9ucyAqLw0KI2RlZmluZSBfT1BfTEFERCAgICAgICAgIDMyDQojZGVm aW5lIF9PUF9MU1VCICAgICAgICAgMzMNCg0KLyogU0hMICgic2h1ZmZsZXIiKSBvcGVyYXRp b25zICovDQojZGVmaW5lIF9PUF9TSElGVEwgICAgICAgMzYNCiNkZWZpbmUgX09QX1NISUZU UiAgICAgICAzOA0KI2RlZmluZSBfT1BfU0hJRlRSQSAgICAgIDQwDQojZGVmaW5lIF9PUF9S T1RMICAgICAgICAgNDINCiNkZWZpbmUgX09QX1JPVFIgICAgICAgICA0NA0KI2RlZmluZSBf T1BfQklUT1AgICAgICAgIDQ2DQojZGVmaW5lIF9PUF9CSVRSRVYgICAgICAgNDgNCi8qIFNJ TUQgYW5kIGJ5dGUtc2h1ZmZsaW5nICovDQojZGVmaW5lIF9PUF9NSVggICAgICAgICAgNTIN CiNkZWZpbmUgX09QX0VYUEFORCAgICAgICA1Mw0KI2RlZmluZSBfT1BfU0RVUCAgICAgICAg IDU0DQojZGVmaW5lIF9PUF9QRVJNVVRFICAgICAgMTI2DQoNCi8qIFJPUDIgdW5pdCAobm90 IGNvbXBsZXRlIDogY29tYmluZSBpcyBuZXcpICovDQojZGVmaW5lIF9PUF9MT0dJQyAgICAg ICAgNTYNCiNkZWZpbmUgX09QX0NPTUJJTkVfT1IgICA1OA0KI2RlZmluZSBfT1BfQ09NQklO RV9BTkQgIDU5DQoNCi8qIEZQIChub3QgY29tcGxldGUpICovDQojZGVmaW5lIF9PUF9GQURE ICAgICAgICAgNjQNCiNkZWZpbmUgX09QX0ZTVUIgICAgICAgICA2NQ0KI2RlZmluZSBfT1Bf Rk1VTCAgICAgICAgIDY2DQojZGVmaW5lIF9PUF9GRElWICAgICAgICAgNzENCiNkZWZpbmUg X09QX0ZNQUMgICAgICAgICA3NQ0KI2RlZmluZSBfT1BfRkFERFNVQiAgICAgIDc2DQoNCi8q IExTVSwgZG9tZSBmb3JtcyBhciBhbHNvIGluIGludGVybWVkaWFyeSBmb3JtYXQgKi8NCiNk ZWZpbmUgX09QX0xPQUQgICAgICAgICA4MA0KI2RlZmluZSBfT1BfTE9BREYgICAgICAgIDgy DQojZGVmaW5lIF9PUF9TVE9SRSAgICAgICAgODQNCiNkZWZpbmUgX09QX1NUT1JFRiAgICAg ICA4Ng0KI2RlZmluZSBfT1BfQ0FDSEVNTSAgICAgIDg4DQoNCiNkZWZpbmUgX09QX1NDQVRU RVIgICAgICAxMjcNCiNkZWZpbmUgX09QX0dBVEhFUiAgICAgICAxMjgNCg0KLyogTUlTQyA6 ICovDQovKiBTUkIgOiAqLw0KI2RlZmluZSBfT1BfTE9BRE0gICAgICAgIDEwOA0KI2RlZmlu ZSBfT1BfU1RPUkVNICAgICAgIDExMA0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZp bmUgX09QX0pNUEEgICAgICAgICAxMTYNCg0KDQovKg0KIGludGVybWVkaWFyeSBmb3JtYXQg OiBSUg0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIGNhbiBiZWxvbmcgdG8gZWl0aGVy IFJSUiBvciBJOFJSIChSUlIgc2VlbXMgYmV0dGVyKQ0KIGNvdW50PTE1DQoqLw0KDQovKiBJ TkMtYmFzZWQgaW5zdHJ1Y3Rpb25zICovDQojZGVmaW5lIF9PUF9JTkMgICAgICAgICAgMTYN Ci8qDQogICB0aGUgZm9sbG93aW5nIGZ1bmN0aW9ucyBjYW4gYmUgZW5jb2RlZCBpbiB0aGUg Yml0cyAxMiBhbmQgMTMgIQ0KICAgI2RlZmluZSBfT1BfREVDDQogICAjZGVmaW5lIF9PUF9O RUcNCiAgICNkZWZpbmUgX09QX0FCUw0KKi8NCg0KDQovKiBob2xlIGhlcmUuICovDQoNCiNk ZWZpbmUgX09QX1NDQU4gICAgICAgICAyMA0KDQovKiBMTlMgb3BlcmF0aW9ucyAqLw0KI2Rl ZmluZSBfT1BfTDJJTlQgICAgICAgIDM0DQojZGVmaW5lIF9PUF9JTlQyTCAgICAgICAgMzUN Cg0KLyogU0lNRCBhbmQgYnl0ZS1zaHVmZmxpbmcgKi8NCiNkZWZpbmUgX09QX0JZVEVSRVYg ICAgICA1MA0KDQovKiBGUCwgbm90IGNvbXBsZXRlICovDQojZGVmaW5lIF9PUF9GMklOVCAg ICAgICAgNjcNCiNkZWZpbmUgX09QX0lOVDJGICAgICAgICA2OA0KI2RlZmluZSBfT1BfRklB UFJYICAgICAgIDY5DQojZGVmaW5lIF9PUF9GU1FSVElBUFJYICAgNzANCiNkZWZpbmUgX09Q X0ZTUVJUICAgICAgICA3Mg0KI2RlZmluZSBfT1BfRkxPRyAgICAgICAgIDczDQojZGVmaW5l IF9PUF9GRVhQICAgICAgICAgNzQNCg0KLyogTUlTQyA6ICovDQovKiBTUFIgOiAqLw0KI2Rl ZmluZSBfT1BfR0VUICAgICAgICAgIDEwNA0KI2RlZmluZSBfT1BfUFVUICAgICAgICAgIDEw Ng0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZpbmUgX09QX0xPT1AgICAgICAgICAx MTcgICAgLyogdGhpcyBpc24ndCBnb2luZyB0byBiZSBSUiBvbmx5IGluIHNvbWUgdGltZS4u LiAqLw0KDQovKg0KIEZvcm1hdCBvbmUgOiBJOFJSDQogLS0tLS0tLS0tLS0tLS0tLS0NCiAo cGx1cyBzaWduIGJpdCBpbiBhIDl0aCBiaXQpDQogY291bnQ9MjcNCg0KIGNoYWxsZW5nZSA6 IG1hcCBpdCBzbyBpdCBjb3JyZXNwb25kcyB0byB0aGUgUlJSIGZvcm1hdCB3aGVuZXZlciBw b3NzaWJsZSwNCnNvIHRoZSBkaWZmZXJlbmNlIGlzICJvbmx5IiBvbmUgYml0IGluIG1vc3Qg Y2FzZXMgLT4gZWFzaWVyIGRlY29kaW5nLg0KDQoqLw0KDQovKiBJbnRlZ2VyIGFyaXRobWV0 aWNzICovDQoNCiNkZWZpbmUgX09QX0FEREkgICAgICAgICAzDQojZGVmaW5lIF9PUF9TVUJJ ICAgICAgICAgNQ0KI2RlZmluZSBfT1BfTVVMSSAgICAgICAgIDcNCiNkZWZpbmUgX09QX0RJ VkkgICAgICAgICA5DQojZGVmaW5lIF9PUF9NT0RJICAgICAgICAgMTENCg0KLyogSU5DLWJh c2VkIGluc3RydWN0aW9ucyAqLw0KDQojZGVmaW5lIF9PUF9DTVBMSSAgICAgICAgMjUNCiNk ZWZpbmUgX09QX0NNUExFSSAgICAgICAyNw0KI2RlZmluZSBfT1BfTUFYSSAgICAgICAgIDI5 DQojZGVmaW5lIF9PUF9NSU5JICAgICAgICAgMzENCg0KLyogbm90IHJlYWxseSBhcml0aG1l dGljICovDQojZGVmaW5lIF9PUF9QT1BDT1VOVEkgICAgMTUNCg0KLyogU0hMICgic2h1ZmZs ZXIiKSBvcGVyYXRpb25zICovDQojZGVmaW5lIF9PUF9TSElGVExJICAgICAgMzcNCiNkZWZp bmUgX09QX1NISUZUUkkgICAgICAzOQ0KI2RlZmluZSBfT1BfU0hJRlRSQUkgICAgIDQxDQoj ZGVmaW5lIF9PUF9ST1RMSSAgICAgICAgNDMNCiNkZWZpbmUgX09QX1JPVFJJICAgICAgICA0 NQ0KI2RlZmluZSBfT1BfQklUT1BJICAgICAgIDQ3DQojZGVmaW5lIF9PUF9CSVRSRVZJICAg ICAgNDkNCi8qIFNJTUQgYW5kIGJ5dGUtc2h1ZmZsaW5nICovDQojZGVmaW5lIF9PUF9TRFVQ SSAgICAgICAgNTUNCg0KLyogUk9QMiB1bml0IChub3QgY29tcGxldGUgOiBjb21iaW5lIGlz IG5ldykgKi8NCiNkZWZpbmUgX09QX0xPR0lDSSAgICAgICA1Nw0KI2RlZmluZSBfT1BfQ09N QklORV9PUkkgIDYwDQojZGVmaW5lIF9PUF9DT01CSU5FX0FOREkgNjENCg0KLyogTFNVICov DQojZGVmaW5lIF9PUF9MT0FESSAgICAgICAgODENCiNkZWZpbmUgX09QX0xPQURJRiAgICAg ICA4Mw0KI2RlZmluZSBfT1BfU1RPUkVJICAgICAgIDg1DQojZGVmaW5lIF9PUF9TVE9SRUlG ICAgICAgODcNCiNkZWZpbmUgX09QX0NBQ0hFTU1JICAgICA4OA0KDQovKiBTUkIgOiAqLw0K I2RlZmluZSBfT1BfTE9BRE1JICAgICAgIDEwOQ0KI2RlZmluZSBfT1BfU1RPUkVNSSAgICAg IDExMQ0KDQovKg0KIEZvcm1hdCB0d28gOiBJMTZSDQogLS0tLS0tLS0tLS0tLS0tLS0NCiBj b3VudD0xMg0KICovDQoNCi8qIE1JU0MgOiAqLw0KLyogY2xvc2UgdG8gX09QX01PVkUgKi8N CiNkZWZpbmUgX09QX0xPQURDT05TICAgICA5NiAgIC8qIDQtb3Bjb2RlIHJhbmdlIHNvIHdl IGNhbiBjcmVhdGUgMjU2LWJpdCBpbW1lZGlhdGVzICovDQojZGVmaW5lIF9PUF9MT0FEQ09O U1ggICAgMTAwICAvKiBpZGVtICovDQovKiB0b3RhbCA6IDggb3Bjb2RlcyAqLw0KDQovKiBT UFIgOiAqLw0KI2RlZmluZSBfT1BfR0VUSSAgICAgICAgIDEwNQ0KI2RlZmluZSBfT1BfUFVU SSAgICAgICAgIDEwNw0KDQovKiBjb250cm9sLXJlbGF0ZWQgKi8NCiNkZWZpbmUgX09QX0xP QURBRERSICAgICAxMTQNCiNkZWZpbmUgX09QX0xPQURBRERSSSAgICAxMTUNCg0KLyoNCiBG b3JtYXQgdGhyZWUgOiBJMjQNCiAtLS0tLS0tLS0tLS0tLS0tLS0NCiBjb3VudD0xMA0KKi8N Cg0KLyogU1JCIDogKi8NCiNkZWZpbmUgX09QX1NSQl9TQVZFICAgICAxMTINCiNkZWZpbmUg X09QX1NSQl9SRVNUT1JFICAxMTMNCi8qIGNvbnRyb2wtcmVsYXRlZCAqLw0KI2RlZmluZSBf T1BfU1lTQ0FMTCAgICAgIDExOA0KI2RlZmluZSBfT1BfUkZFICAgICAgICAgIDExOQ0KI2Rl ZmluZSBfT1BfSEFMVCAgICAgICAgIDEyMA0KI2RlZmluZSBfT1BfU0VSSUFMSVpFICAgIDEy MQ0KDQojZGVmaW5lIF9PUF9WTElXICAgICAgICAgMTIyDQojZGVmaW5lIF9PUF9WTElXMCAg ICAgICAgMTIyICAgLyogc2hvdWxkIGJlIHJvdW5kZWQgb24gYSAyLWJpdCBib3VuZGFyeSAh ICovDQojZGVmaW5lIF9PUF9WTElXMSAgICAgICAgMTIzICAgLyogdWx0aW1hdGVseSwgd291 bGQgYmUgb3Bjb2RlICMyNTItMjU1ICovDQojZGVmaW5lIF9PUF9WTElXMiAgICAgICAgMTI0 DQojZGVmaW5lIF9PUF9WTElXMyAgICAgICAgMTI1DQoNCg0KLyogRkMwIEV4ZWN1dGlvbiBV bml0cyAgKi8NCg0KLyogQWRkL1N1YiBVbml0ICovDQojZGVmaW5lIEZDMF9FVV9BU1UgICAg ICAgICAgMQ0KLyogSW50ZWdlciBNdWx0aXBseSBVbml0ICovIA0KI2RlZmluZSBGQzBfRVVf SU1VICAgICAgICAgIDINCi8qIEludGVnZXIgRGl2aWRlIFVuaXQgKi8NCiNkZWZpbmUgRkMw X0VVX0lEVSAgICAgICAgICAzDQovKiBiaXQgIlNodWZmbGVyIiAqLw0KI2RlZmluZSBGQzBf RVVfU0hMICAgICAgICAgIDQNCi8qICJJbmNyZW1lbnRlciIgKi8NCiNkZWZpbmUgRkMwX0VV X0lOQyAgICAgICAgICA1DQovKiBib29sZWFuIG9wZXJhdGlvbnMgKi8NCiNkZWZpbmUgRkMw X0VVX1JPUDIgICAgICAgICA2DQovKiBMb2FkL1N0b3JlIFVuaXQgKi8NCiNkZWZpbmUgRkMw X0VVX0xTVSAgICAgICAgICA3DQovKiBTcGVjaWFsIFJlZ2lzdGVyIFVuaXQgKi8NCiNkZWZp bmUgRkMwX0VVX1NSVSAgICAgICAgICA4DQovKiBQT1B1bGF0aW9uIGNvdW50ICovDQojZGVm aW5lIEZDMF9FVV9QT1AgICAgICAgICAgOQ0KDQojZGVmaW5lIE1BWF9GQzBfRVUgICAgICAg ICAgMTANCi8qIHdpbGwgY2hhbmdlIGxhdGVyICovDQoNCg0KDQoNCiNlbmRpZg0K --------------7382E48C2BC27384503DB2A5-- From Alan Grimes Mon Feb 5 00:24:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00849 for ; Wed, 7 Feb 2001 00:52:00 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:00 +0100 (MET) Received: (qmail 15056 invoked by uid 0); 4 Feb 2001 23:26:47 -0000 Received: from ch.egroups.com (208.50.99.226) by 10.1.4.119 (mx19) with SMTP; 4 Feb 2001 23:26:47 -0000 X-eGroups-Return: sentto-1101623-2237-981329010-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 04 Feb 2001 23:23:35 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:23:29 -0000 Received: (qmail 79563 invoked from network); 4 Feb 2001 23:23:28 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 23:23:28 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta2 with SMTP; 4 Feb 2001 23:23:28 -0000 Received: from 66-44-67-186.s440.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.186] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PYVC-0007TZ-00 for f-cpu@yahoogroups.com; Sun, 04 Feb 2001 18:23:26 -0500 Message-ID: <3A7DE4AE.4BAB534B@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> <3A7DA448.616D024C@cichon.com> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 18:24:30 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Unsubscribe?!? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac8eb7cc8fdfc4b588736320dd4a0182 Status: R X-Status: N Gordon Cichon wrote:
>
> Hi Guys,
>
> is there any way to unsubscribe this mailing list without exposing my
> CV to yahoo?

Try and see if this address works:

f-cpu-unsubscribe@yahoogroups.com

--
I am not massochistic enough to linux.
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor
www..com
From Alan Grimes Mon Feb 5 00:51:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00856 for ; Wed, 7 Feb 2001 00:52:02 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:02 +0100 (MET) Received: (qmail 6568 invoked by uid 0); 4 Feb 2001 23:51:45 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx14) with SMTP; 4 Feb 2001 23:51:45 -0000 X-eGroups-Return: sentto-1101623-2240-981330612-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 04 Feb 2001 23:50:15 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:50:11 -0000 Received: (qmail 5903 invoked from network); 4 Feb 2001 23:50:10 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 4 Feb 2001 23:50:10 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta2 with SMTP; 4 Feb 2001 23:50:10 -0000 Received: from 66-44-67-186.s440.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.186] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PYv2-0003pR-00 for f-cpu@yahoogroups.com; Sun, 04 Feb 2001 18:50:09 -0500 Message-ID: <3A7DEAF1.4C169117@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <20010204181916.A30499@moonbase.res.wpi.net> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 18:51:13 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 31598b9fe2e9e489e4867390fa651670 Status: R X-Status: N > The line r1 = r2 - r3 made me blink for a second.
>
> Why?
>
> Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
> defined I don't know exactly what a fact would look like in code).

uh, I think you're confused.

> The idea is that rather than constantly feeding the cpu instructions,

The CPU isn't fead instructions, it seeks them, and then processes them.

> you feed it facts, goals, and a vector to call when it gets an answer.

It sounds like something I heard about Prolog, unfortunately I havn't
yet gotten a chance to study that language.

If you wanted to design a machine where R1 always contained the
difference of R2 and 3, I would suggest implementing this system using
an FPGA...

> You would free up the bandwidth considerably because you no long need
> to spoonfeed every little detail.

Isn't that what the cache is for? So the machine doesn't have to go back
to main memory all the time...

--
I am not massochistic enough to linux.
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.  
From Yann Guidon Mon Feb 5 01:01:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00861 for ; Wed, 7 Feb 2001 00:52:03 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:03 +0100 (MET) Received: (qmail 29767 invoked by uid 0); 4 Feb 2001 23:55:14 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx09) with SMTP; 4 Feb 2001 23:55:14 -0000 X-eGroups-Return: sentto-1101623-2241-981330909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hl.egroups.com with NNFMP; 04 Feb 2001 23:55:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:06 -0000 Received: (qmail 17847 invoked from network); 4 Feb 2001 23:55:06 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 4 Feb 2001 23:55:06 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 4 Feb 2001 23:55:05 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA09169 for ; Mon, 5 Feb 2001 00:55:02 +0100 (MET) Message-ID: <3A7DED51.D36BB2CC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <000b01c08e2a$04250700$29e65982@student.utwente.nl> <3A7C7E96.5970CC19@f-cpu.org> <3A7D77EA.EAD3CDB8@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 01:01:21 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8f344e7544b6427d88cc27932861bafe Status: R X-Status: N hi !

Nicolas Boulay wrote:
> re,
reuh aussi,
> Yann Guidon a =E9crit :
> <snip>
> > 2) encoding the delay/latency in the instruction is another mista= ke because the
> > new platforms could have radically different scheduling rules. it= is not portable.
> > it could however be coded in the "pack" instruction bec= ause this instruction can be
> > interpreted as a NOP on the architectures that don't support or c= omply this.
> This encoding will be portable ! The one dependancie bit is portable > (same value could be execute in the same cycle). If this bit is false<= BR> > you will have registers mismatch and it will be the user faults
> (compiler or asm writer).

i would like to see some case studies.
ie a superscalar CPU, with cases for 2- and 3-ways issue.

> > > (someone pointed a nice ICCD paper about that out to me,
> > > http://www.a= i.mit.edu/~jpg/pub.html top paper... there's more interesting stuff
> > > there).
> > thanks ! i'm currently downloading these files.
> me too.
hmm i gotta read it, though ;-) downloading is fine but useless otherwise..= . heh !

> > > Marco
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""
3D""
From Rares Marian Mon Feb 5 01:00:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00864 for ; Wed, 7 Feb 2001 00:52:04 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:04 +0100 (MET) Received: (qmail 23571 invoked by uid 0); 4 Feb 2001 23:55:14 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx16) with SMTP; 4 Feb 2001 23:55:14 -0000 X-eGroups-Return: sentto-1101623-2242-981330909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fg.egroups.com with NNFMP; 04 Feb 2001 23:55:14 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:04 -0000 Received: (qmail 33348 invoked from network); 4 Feb 2001 23:55:02 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 Feb 2001 23:55:02 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 4 Feb 2001 23:55:02 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 8981C46017; Sun, 4 Feb 2001 19:00:32 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204190032.D30499@moonbase.res.wpi.net> References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DEAF1.4C169117@starpower.net> In-Reply-To: <3A7DEAF1.4C169117@starpower.net>; from alangrimes@starpower.net on Sun, Feb 04, 2001 at 18:51:13 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 19:00:32 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9f198ceac01100e182d3dc8ae8534515 Status: R X-Status: N
On Sun, 04 Feb 2001 18:51:13 Alan Grimes wrote:
> > The line r1 = r2 - r3 made me blink for a second.
> >
> > Why?
> >
> > Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
> > defined I don't know exactly what a fact would look like in code).
>
> uh, I think you're confused.
> 
> > The idea is that rather than constantly feeding the cpu instructions,
>
> The CPU isn't fead instructions, it seeks them, and then processes them.

True but it seeks them in a linear manner which is practically equivalent
to feeding it.

> > you feed it facts, goals, and a vector to call when it gets an answer.
>
> It sounds like something I heard about Prolog, unfortunately I havn't
> yet gotten a chance to study that language.
>
> If you wanted to design a machine where R1 always contained the
> difference of R2 and 3, I would suggest implementing this system using
> an FPGA...

No not to contain the difference, but have r1, r2, and r3 have some
mathematical relationship.

> > You would free up the bandwidth considerably because you no long need
> > to spoonfeed every little detail.
>
> Isn't that what the cache is for? So the machine doesn't have to go back
> to main memory all the time...

Right.  The problem is that for multiprocessor machines the cache of each
cpu needs to be made sane with each other.  No conflicts.  You would free
up band width to accomplish that too.

> --
> I am not massochistic enough to linux.
> http://users.erols.com/alangrimes/  <my website.
> Any usage of this e-mail account is subject to the terms and conditions
> specified on my website.
>
>
>
>


Yahoo! Groups Sponsor

www.

From Yann Guidon Mon Feb 5 01:01:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00867 for ; Wed, 7 Feb 2001 00:52:05 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:05 +0100 (MET) Received: (qmail 23600 invoked by uid 0); 4 Feb 2001 23:55:15 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx16) with SMTP; 4 Feb 2001 23:55:15 -0000 X-eGroups-Return: sentto-1101623-2246-981330912-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 04 Feb 2001 23:55:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:12 -0000 Received: (qmail 75095 invoked from network); 4 Feb 2001 23:55:12 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 4 Feb 2001 23:55:12 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 4 Feb 2001 23:55:11 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08454 for ; Mon, 5 Feb 2001 00:55:08 +0100 (MET) Message-ID: <3A7DED57.26F7696D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7D522E.F6B0FF19@f-cpu.org> <20010204142122.40302@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 01:01:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 228939f634ba7cf789ee3e176013e270 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Sun, Feb 04, 2001 at 01:59:26PM +0100, Yann Guidon wrote:
> [...]
> I'm not so sure that LNS was a good idea in the first place.  Operations
> on LNS operands seem to be quite expensive, much more than in IEEE format.

whatever the outcome is,
at least the opcodes don't cost us anything...

> > > - DIV, DIVI and MOD, MODI instructions. The manual says, that DIV computes
> > > r1 = r3 / r2
> > > and DIVI computes
> > > r1 = r2 / imm
> > > This is not symmetrical in my eyes. is there any reason for this? why isnt
> > > the instruction redefined and r3 replaced by imm, so the computation is
> > > always:
> > > r1 = r2 / r3 (DIV)
> > > r1 = r2 / imm (DIVI)
> > hmmmm i think that it's interesting :-)
> > however i'll have to look more closely.
> The ISA should be consistent in that point, i.e. the SUB instruction
> should also calculate `r1 = r2 - r3' then, and so on.  I like the idea,
> though -- the registers are nicely numbered from left to right (or right
> to left, in the asm instruction), and the operands are always placed in
> the same 6-bit slots of the instruction word.

hmmm so what do we do ?...
was it simply a typing error i made in the manual ?
is it too late to add the computation of reciprocal ?
it would solve the problem because this would become a 1r1w instruction ,-P

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.   
From Yann Guidon Mon Feb 5 01:01:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00870 for ; Wed, 7 Feb 2001 00:52:06 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:06 +0100 (MET) Received: (qmail 29816 invoked by uid 0); 4 Feb 2001 23:55:17 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx09) with SMTP; 4 Feb 2001 23:55:17 -0000 X-eGroups-Return: sentto-1101623-2243-981330909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hl.egroups.com with NNFMP; 04 Feb 2001 23:55:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:09 -0000 Received: (qmail 17927 invoked from network); 4 Feb 2001 23:55:08 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 4 Feb 2001 23:55:08 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta1 with SMTP; 4 Feb 2001 23:55:07 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA12780 for ; Mon, 5 Feb 2001 00:55:04 +0100 (MET) Message-ID: <3A7DED53.9D0B5FF0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <3A7D7606.FF8AFAC@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 01:01:23 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 86377803225bc504d61b56de6b7cae45 Status: R X-Status: N hello,
quick&dirty answers,

Nicolas Boulay wrote:
> Yann Guidon a =E9crit :
> > Marco Al wrote:
> > > From: "Ben Franchuk" <bfranchuk@jetnet.ab.ca>= ;
> > > > > Of course ! But I don't understand "binary tr= anslation".
> > > > What ever happened to the idea of "Generic Opcodes= " that you would compile
> > > > a program and the loader would translate this to real o= pcodes?
> > > Thats what I meant, sorta.
> > as long as it's "only" about a lookup table, it's ok. > > however, the latency/scheduling issue is more difficult to solve.=
> In Pentuim, all the unit have the same pipelined unit.

???

could you be more precise ?

and what's the point ?

> > > As long as wrong code sequences cant harm the processor and = not compromise
> > > security the single biggest problem with exposing pipeline l= atency is that they
> > > make backward compatibility complex.
> > and that's a big issue because it's our #1 goal.
> > what's the point of having a very efficient CPU if the binaries c= an't be reuse elsewhere ???
> That's a very strong point. But when you see intel problem with IA64 > (they said that you will have to recompile your program for the next > generation),
you forget the last part of their declaration : "if you want to run at= full speed".
my goal is to maintain a relatively decent performance on as wide a range of applications as possible, with a minimal amount of rewriting.

> we can't try to use the popularity of opensoftware and the
> openess of the source code. Maybe an standard install will be a
> /configure and not rpm-something ;p
? i don't understand...

> So maybe a total binary compatibility isn't so interresting to have. total is impossible. But i mentioned a "minimal" compatibility. the F-CPU ISA has "core" instructions. however the scheduling was= not the issue
because the strict rules of dependency that we find in usual code
(instructions are executed in order etc) is preserved.
a scheme with "lost values" (like the example of the C6x) would be a catastrophe.

> > if it's HW, it's the best solution for me. there is no compatibil= ity and
> Best solution ? Translation is always translation, HW or SW you have t= he
> same thing to do. But HW is much more complicated to write !
not really...
it depends on the extent of the translation.

until now, there were 2 issues : the change in the opcode value,
and the pipeline latency/instruction packing. there's nothing worth
a big change now. translation exists for CISC machines, whereas RISC
doesn't need much change.

> > > Marco
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""3D""<= /a>
www. .com&nbs= p;
3D""
From Yann Guidon Mon Feb 5 01:01:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00873 for ; Wed, 7 Feb 2001 00:52:07 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:07 +0100 (MET) Received: (qmail 25904 invoked by uid 0); 4 Feb 2001 23:55:28 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx24) with SMTP; 4 Feb 2001 23:55:28 -0000 X-eGroups-Return: sentto-1101623-2245-981330911-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 04 Feb 2001 23:55:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:11 -0000 Received: (qmail 75043 invoked from network); 4 Feb 2001 23:55:10 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 4 Feb 2001 23:55:10 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 4 Feb 2001 23:55:10 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08448 for ; Mon, 5 Feb 2001 00:55:07 +0100 (MET) Message-ID: <3A7DED56.19B1EA2F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20010204181916.A30499@moonbase.res.wpi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 01:01:26 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d931a2286aeb83f307c555d1a328b286 Status: R X-Status: N hi !

Rares Marian wrote:
>
> The line r1 = r2 - r3 made me blink for a second.
>
> Why?
>
> Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
> defined I don't know exactly what a fact would look like in code).
>
> The idea is that rather than constantly feeding the cpu instructions, you
> feed it facts, goals, and a vector to call when it gets an answer.  You
> would free up the bandwidth considerably because you no long need to
> spoonfeed every little detail.  You could even use the bandwidth to take
> care of nasty critical things like cache coherence.

hmmm, you mean : a PROLOG CPU ? :-)
</jk>

> Rares
WHYGEE, back in the good old days when the f-cpu was the funniest vapourware ever ;-)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
From Rares Marian Mon Feb 5 00:51:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00876 for ; Wed, 7 Feb 2001 00:52:08 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:08 +0100 (MET) Received: (qmail 22563 invoked by uid 0); 4 Feb 2001 23:57:07 -0000 Received: from ch.egroups.com (208.50.99.226) by 10.1.4.119 (mx19) with SMTP; 4 Feb 2001 23:57:07 -0000 X-eGroups-Return: sentto-1101623-2239-981330359-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 04 Feb 2001 23:46:02 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:45:58 -0000 Received: (qmail 34327 invoked from network); 4 Feb 2001 23:45:57 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 Feb 2001 23:45:57 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 4 Feb 2001 23:45:57 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 484C946017; Sun, 4 Feb 2001 18:51:27 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204185126.C30499@moonbase.res.wpi.net> References: <20010204181916.A30499@moonbase.res.wpi.net> In-Reply-To: <20010204181916.A30499@moonbase.res.wpi.net>; from rares@moonbase.res.wpi.net on Sun, Feb 04, 2001 at 18:19:16 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 18:51:26 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7fea484503dd77cda80c468b325ff5a1 Status: R X-Status: N
On Sun, 04 Feb 2001 18:19:16 Rares Marian wrote:
> The line r1 = r2 - r3 made me blink for a second.
>
> Why?
>
> Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
> defined I don't know exactly what a fact would look like in code). 

Not necessarily in this order:
You load r1 and r3.
You validate r1 and r3 (simple flag)
You bind r1 as equaling r2 - r3 (I don't know how this would work but let's
say it works)
You set r2 to be unkown (flag)
You read r2

The CPU finds the unknown flag on R2 and it makes the decision about what
op to perform.
It then branches to whatever instruction it needs to.

> The idea is that rather than constantly feeding the cpu instructions, you
> feed it facts, goals, and a vector to call when it gets an answer.  You
> would free up the bandwidth considerably because you no long need to
> spoonfeed every little detail.  You could even use the bandwidth to take
> care of nasty critical things like cache coherence.
>
> Rares
>
>
>
>


Yahoo! Groups Sponsor
From Rares Marian Mon Feb 5 01:07:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00879 for ; Wed, 7 Feb 2001 00:52:08 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:08 +0100 (MET) Received: (qmail 11862 invoked by uid 0); 5 Feb 2001 00:02:43 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx18) with SMTP; 5 Feb 2001 00:02:43 -0000 X-eGroups-Return: sentto-1101623-2247-981331349-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 05 Feb 2001 00:02:41 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 00:02:29 -0000 Received: (qmail 50595 invoked from network); 5 Feb 2001 00:02:28 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 5 Feb 2001 00:02:28 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 5 Feb 2001 00:02:27 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 1968146017; Sun, 4 Feb 2001 19:07:58 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204190757.E30499@moonbase.res.wpi.net> References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DED56.19B1EA2F@f-cpu.org> In-Reply-To: <3A7DED56.19B1EA2F@f-cpu.org>; from whygee@f-cpu.org on Sun, Feb 04, 2001 at 19:01:26 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 19:07:57 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f6fb4cf07395b419cc9b6fcc306932d6 Status: R X-Status: N
On Sun, 04 Feb 2001 19:01:26 Yann Guidon wrote:
> hi !
>
> Rares Marian wrote:
> >
> > The line r1 = r2 - r3 made me blink for a second.
> >
> > Why?
> >
> > Well say you knew r1 and r3.  You loaded r1=r2-r3 as a fact (loosely
> > defined I don't know exactly what a fact would look like in code).
> >
> > The idea is that rather than constantly feeding the cpu instructions,
> you
> > feed it facts, goals, and a vector to call when it gets an answer.  You
> > would free up the bandwidth considerably because you no long need to
> > spoonfeed every little detail.  You could even use the bandwidth to
> take
> > care of nasty critical things like cache coherence.
>
> hmmm, you mean : a PROLOG CPU ? :-)
> </jk>

I know it's easy to do it wrong and create a bloody disaster worse than
x86, but if it's done right you could have a gem.

I'm thinking you could easily get the thing to perform new operations
simply by changing the relationship between the regs.  Rather than sending
a new stream of data and instructions.  The weird thing is that with some
work you could still keep it fixed length and reasonably RISC style.

> > Rares
> WHYGEE, back in the good old days when the f-cpu was the funniest
> vapourware ever ;-)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>


Yahoo! Groups Sponsor
From Alan Grimes Mon Feb 5 01:19:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00888 for ; Wed, 7 Feb 2001 00:52:11 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:11 +0100 (MET) Received: (qmail 19205 invoked by uid 0); 5 Feb 2001 00:21:39 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx17) with SMTP; 5 Feb 2001 00:21:39 -0000 X-eGroups-Return: sentto-1101623-2248-981332331-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 05 Feb 2001 00:19:04 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 00:18:50 -0000 Received: (qmail 72909 invoked from network); 5 Feb 2001 00:18:49 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 5 Feb 2001 00:18:49 -0000 Received: from unknown (HELO smtp02.mrf.mail.rcn.net) (207.172.4.61) by mta2 with SMTP; 5 Feb 2001 00:18:49 -0000 Received: from 66-44-67-186.s440.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.186] helo=starpower.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14PZMl-0007Xd-00 for f-cpu@yahoogroups.com; Sun, 04 Feb 2001 19:18:48 -0500 Message-ID: <3A7DF1A8.EBBEBFBA@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DED56.19B1EA2F@f-cpu.org> <20010204190757.E30499@moonbase.res.wpi.net> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 19:19:52 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ff7d0fff5bdbff0cd5efac8215e6189 Status: R X-Status: N Rares Marian wrote:
> I know it's easy to do it wrong and create a bloody disaster worse than
> x86, but if it's done right you could have a gem.
>
> I'm thinking you could easily get the thing to perform new operations
> simply by changing the relationship between the regs.  Rather than
> sending a new stream of data and instructions.  The weird thing is that
> with some work you could still keep it fixed length and reasonably RISC
> style.

Dude, you're gonna have to explain that a hell of a lot better before
even I'm gonna buy it...

With my FPGA suggestion, I was talking about a situation where the gates
were aligned such that any read to R1 returned the current difference
between 2 and 3.

--
I am not massochistic enough to linux.
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.   
From Rares Marian Mon Feb 5 01:49:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00903 for ; Wed, 7 Feb 2001 00:52:14 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:14 +0100 (MET) Received: (qmail 29828 invoked by uid 0); 5 Feb 2001 00:43:57 -0000 Received: from jj.egroups.com (208.50.144.82) by 10.1.4.112 (mx12) with SMTP; 5 Feb 2001 00:43:57 -0000 X-eGroups-Return: sentto-1101623-2249-981333835-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jj.egroups.com with NNFMP; 05 Feb 2001 00:43:56 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 00:43:54 -0000 Received: (qmail 69750 invoked from network); 5 Feb 2001 00:43:54 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Feb 2001 00:43:54 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 5 Feb 2001 00:43:53 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id ED0BE46017; Sun, 4 Feb 2001 19:49:23 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204194923.F30499@moonbase.res.wpi.net> References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DED56.19B1EA2F@f-cpu.org> <20010204190757.E30499@moonbase.res.wpi.net> <3A7DF1A8.EBBEBFBA@starpower.net> In-Reply-To: <3A7DF1A8.EBBEBFBA@starpower.net>; from alangrimes@starpower.net on Sun, Feb 04, 2001 at 19:19:52 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 19:49:23 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7924020dea9ec4e38bbd916217001827 Status: R X-Status: N
On Sun, 04 Feb 2001 19:19:52 Alan Grimes wrote:
> Rares Marian wrote:
> > I know it's easy to do it wrong and create a bloody disaster worse than
> > x86, but if it's done right you could have a gem.
> >
> > I'm thinking you could easily get the thing to perform new operations
> > simply by changing the relationship between the regs.  Rather than
> > sending a new stream of data and instructions.  The weird thing is that
>
> > with some work you could still keep it fixed length and reasonably RISC
>
> > style.
>
> Dude, you're gonna have to explain that a hell of a lot better before
> even I'm gonna buy it...
>
> With my FPGA suggestion, I was talking about a situation where the gates
> were aligned such that any read to R1 returned the current difference
> between 2 and 3.

That's a beginning... Thanks.  I just intend to have it software
programmable to do that.
I'll do an 8 bit 16 register model soon.

> --
> I am not massochistic enough to linux.
> http://users.erols.com/alangrimes/  <my website.
> Any usage of this e-mail account is subject to the terms and conditions
> specified on my website.
>
>
>
>


Yahoo! Groups Sponsor

www.   
From "Marco Al" Mon Feb 5 01:54:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00906 for ; Wed, 7 Feb 2001 00:52:15 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:15 +0100 (MET) Received: (qmail 16110 invoked by uid 0); 5 Feb 2001 00:46:11 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx27) with SMTP; 5 Feb 2001 00:46:11 -0000 X-eGroups-Return: sentto-1101623-2250-981333964-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 05 Feb 2001 00:46:08 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 00:46:04 -0000 Received: (qmail 32979 invoked from network); 5 Feb 2001 00:46:03 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 5 Feb 2001 00:46:03 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 5 Feb 2001 01:47:07 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id D220729F0 for ; Mon, 5 Feb 2001 01:46:01 +0100 (CET) Message-ID: <004201c08f0e$3c2314a0$29e65982@student.utwente.nl> To: References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DED56.19B1EA2F@f-cpu.org> <20010204190757.E30499@moonbase.res.wpi.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 01:54:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit From: ""Rares Marian" <rares@moonbase.res.wpi.net>" X-UIDL: 3b2d0f4586440083c585a4f6aad533b7 Status: R X-Status: N
Yahoo! Groups Sponsor

www.   
From Yann Guidon Mon Feb 5 01:01:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00912 for ; Wed, 7 Feb 2001 00:52:16 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:16 +0100 (MET) Received: (qmail 9596 invoked by uid 0); 5 Feb 2001 01:12:40 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx27) with SMTP; 5 Feb 2001 01:12:40 -0000 X-eGroups-Return: sentto-1101623-2244-981330909-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 04 Feb 2001 23:55:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 4 Feb 2001 23:55:09 -0000 Received: (qmail 74973 invoked from network); 4 Feb 2001 23:55:09 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 4 Feb 2001 23:55:09 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta1 with SMTP; 4 Feb 2001 23:55:08 -0000 Received: from f-cpu.org (nas4-139.aub.club-internet.fr [195.36.145.139]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA09180 for ; Mon, 5 Feb 2001 00:55:05 +0100 (MET) Message-ID: <3A7DED54.94D65E04@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7DCC24.12559.C1074@localhost> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 01:01:24 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Unsubscribe?!? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Unsubscribe: <mailto:f-cpu-unsubscribe@yahoogroups.com>
X-UIDL: 644b87f579521d06fb87bf21521e1ad1 Status: R X-Status: N
Yahoo! Groups Sponsor

www.

From Rares Marian Mon Feb 5 04:06:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00918 for ; Wed, 7 Feb 2001 00:52:17 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:17 +0100 (MET) Received: (qmail 21749 invoked by uid 0); 5 Feb 2001 03:01:12 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx04) with SMTP; 5 Feb 2001 03:01:12 -0000 X-eGroups-Return: sentto-1101623-2251-981342060-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fg.egroups.com with NNFMP; 05 Feb 2001 03:01:08 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 03:01:00 -0000 Received: (qmail 89893 invoked from network); 5 Feb 2001 03:00:56 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 5 Feb 2001 03:00:56 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 5 Feb 2001 03:00:56 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id A177645107; Sun, 4 Feb 2001 22:06:27 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010204220627.H30499@moonbase.res.wpi.net> References: <20010204181916.A30499@moonbase.res.wpi.net> <3A7DED56.19B1EA2F@f-cpu.org> <20010204190757.E30499@moonbase.res.wpi.net> <004201c08f0e$3c2314a0$29e65982@student.utwente.nl> In-Reply-To: <004201c08f0e$3c2314a0$29e65982@student.utwente.nl>; from marco@simplex.nl on Sun, Feb 04, 2001 at 19:54:46 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Feb 2001 22:06:27 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Equation solver version 0.2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 24526351a4a80b8ff5ee760ebe9b9a73 Status: R X-Status: N
On Sun, 04 Feb 2001 19:54:46 Marco Al wrote:
> From: "Rares Marian" <rares@moonbase.res.wpi.net>
>
> You could give each function unit its own input buffer (that creates some
> problems on how to identify which inputs should be put where in the
> buffer, but
> nothing insurmountable) so you dont need a high throughput register file.
> Its a
> pity traditional ISA's dont use mostly destructive instructions, the
> incessant
> writeback to the register file is such a drag even with bypass.

Kick ass!  That's it!  Add an output buffer.
Okay version 0.2:

The missing register is set as read from equation (rather than unkown).  In
it we load information about the relationship between registers as well as
the target.  This way we avoid the following psuedo code:

load r1,imm : load immediate to r1
load r3,imm : load imm to r3
add r2,r1,r3 : r1 = r2 - r3 therefore r2 = r1 + r3
load mem,r2 : send r2 to RAM

The add instruction takes up useful bandwidth because it implies:
load adder,r1
load adder,r3
add
load r2, adder

With my approach
load r1,imm
load r3,imm
load r2,imm (contains the equation)
load mem,r2 (executes the equation. Note load should just execute
            it should not read the actual value of r2 for
            security reasons. Also this would make it very easy to
create cascading
               equations, compilers could be based on mathematics, and
infinite loops
            and other attacks could be detected easily)
Now the last part implies:
load solver,r2
which is really
load adder,r1
load adder,r3
add
load mem,adder

the old instructions:
load r1; load r3; load add; load add; add; load r2; load mem)
become:
load r1; load r3; load r2; load solver; load add; load add; add; load mem;

Halfway through r2 is freed as long as it never points to itself.
This means r2 becomes writable much earlier.  In fact it's abailable before
the add is performed.

All we need is the solver which choeses the proper operation.  Not at all
difficult.
I'm guessing a two barreled modified LSU would suffice.

I think I hit the jackpot here.  And resolved a lot write hazards as well
:)
In fact I may have made many of them unnecessary :)

Rares Marian

Copyright 2000 Rares Marian

> Marco
>
>
>
>
>


Yahoo! Groups Sponsor

www.

From Carsten899@aol.com Mon Feb 5 06:36:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00924 for ; Wed, 7 Feb 2001 00:52:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:19 +0100 (MET) Received: (qmail 17329 invoked by uid 0); 5 Feb 2001 05:36:54 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx21) with SMTP; 5 Feb 2001 05:36:54 -0000 X-eGroups-Return: sentto-1101623-2252-981351405-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 05 Feb 2001 05:36:53 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 05:36:45 -0000 Received: (qmail 43827 invoked from network); 5 Feb 2001 05:36:43 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 5 Feb 2001 05:36:43 -0000 Received: from unknown (HELO imo-d02.mx.aol.com) (205.188.157.34) by mta2 with SMTP; 5 Feb 2001 05:36:43 -0000 Received: from Carsten899@aol.com by imo-d02.mx.aol.com (mail_out_v29.5.) id r.45.1f16095 (4359) for ; Mon, 5 Feb 2001 00:36:38 -0500 (EST) Message-ID: <45.1f16095.27af95e5@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 00:36:37 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f2db8b202d52ce02e9297125dff2c3ef Status: R X-Status: N
>I have also enclosed another file with the opcodes
>in a "clean" organisation (even though everything is temporary).
>it can help you.

The opcode map is already included in the virtual FCPU. The result of my
long-weekend-hack (sourcefiles) are found at:
ftp://members.aol.com/carsten899/f-cpu
There are three sourcefiles:

fcpu.h  - interface definition to virtual f-cpu
fcpu.c  - virtual fcpu and fcpu assembler (i like big files :-) )
fcpudbg.c   - simple command line shell

I make these early versions public, because i hope someone out there is
interested in doing some testing. I am sure there are many bugs.

Some instructions are new (not mentioned in V0.2 manual) like OP_SCATTER,
OP_GATHER or OP_LOADMI so they are not implemented.

>>the memory protection issue can give you serious troubles.

which troubles do you think of?

>years ago, i had overcome this problem : using only arrays of bytes.
>that's all. Every operation was performed with bytes. hyper-portable,

all register an memory access is abstracted by functions calls like "give me
word x from reg y" ( fcpu_reg_get_doublebyte ), the problem arises in the
arithmetics routines in the current implementation.

>at the cost of some serious speed

until stable definition (which i think will be manual 1.0) i would like to
concentrate on correct implementation, not speed.

Best regards
Carsten
Yahoo! Groups Sponsor
www. .com 
From Andreas Romeyke Mon Feb 5 10:32:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00933 for ; Wed, 7 Feb 2001 00:52:21 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:21 +0100 (MET) Received: (qmail 19406 invoked by uid 0); 5 Feb 2001 09:27:11 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 5 Feb 2001 09:27:11 -0000 X-eGroups-Return: sentto-1101623-2253-981365218-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 05 Feb 2001 09:27:02 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 09:26:58 -0000 Received: (qmail 47587 invoked from network); 5 Feb 2001 09:26:57 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 Feb 2001 09:26:57 -0000 Received: from unknown (HELO mail.it-netservice.de) (213.179.64.4) by mta3 with SMTP; 5 Feb 2001 10:28:01 -0000 Received: from it-netservice.de (dev-gate.intern.itns.de [192.168.2.2] (may be forged)) by mail.it-netservice.de (8.9.3/8.9.3) with ESMTP id KAA17168 for ; Mon, 5 Feb 2001 10:29:35 +0100 Sender: art1@mail.it-netservice.de Message-ID: <3A7E734B.D969AB85@it-netservice.de> Organization: free member of GAOS X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: de, de-DE, en To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> <20010201142516.14977@thrai.stud.uni-hannover.de> <3A7A8CFD.A1A9D006@mentor.com> <20010202153029.15442@thrai.stud.uni-hannover.de> From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 10:32:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7817fd75696108214e2f898203682b57 Status: R X-Status: N Hello,

> The problem is (as usual) to get both SIMD and signed/unsigned mode
> working, and to fit each row into a single pipeline stage.  The adder

I am right that the problems in usage of signed/unsigned operations?

If so, why you cannot operate in unsigned mode. In division we can
handle the signs separately. We can build a unit which can do this for
division, adder, multiplier, shiifter and so on, or not? I think the
units were simpler, is not it?

Bye Andreas
Yahoo! Groups Sponsor

www.

From Hans Summers Mon Feb 5 10:32:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00936 for ; Wed, 7 Feb 2001 00:52:22 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:22 +0100 (MET) Received: (qmail 25295 invoked by uid 0); 5 Feb 2001 09:32:57 -0000 Received: from hj.egroups.com (208.50.99.212) by 10.1.4.111 (mx11) with SMTP; 5 Feb 2001 09:32:56 -0000 X-eGroups-Return: sentto-1101623-2254-981365573-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 05 Feb 2001 09:32:55 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 09:32:52 -0000 Received: (qmail 81621 invoked from network); 5 Feb 2001 09:32:51 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 5 Feb 2001 09:32:51 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 5 Feb 2001 09:32:50 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA03082 for ; Mon, 5 Feb 2001 04:30:48 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA21715 for ; Mon, 5 Feb 2001 04:32:45 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Feb 2001 09:32:44 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 09:32:41 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 871c11a974a5109be78a99006273266e Status: R X-Status: N
Hello.

I read the F-CPU manual. The architecture looks good, OOOC is nice and I
particularly liked the SRB. Eventually on seul.org I came across draft
0.2.2, and read about the scheduler (Part IV chapter 3) document p.ps dated
14-Jan-01. This I didn't like so here I propose an alternative solution. It
also enables a precise definition of the external view of any execution unit
(see recent mail list thread). There are some diagrams which together with
this text I have placed on this page:
http://www.HansSummers.com/computers/fcpu/scheduler.htm

-------------------
Hans Summers
http://www.HansSummers.com

___________________________________________

CONTENTS

1.      WHAT'S WRONG WITH THE CURRENT SCHEDULER
1.1      HIGH COMPLEXITY
1.2      BREAKS MODULARITY
1.3      HARD TO MAINTAIN
1.4      FIXED LATENCY
1.5 BAD PERFORMANCE

2 NEW PROPOSAL
2.1      INTRODUCTION
2.2      DECODER AND INSTRUCTION ISSUE
2.3      EXECUTION UNIT PIPELINE
2.4 XBAR WRITE CONFLICTS

3      EXECUTION UNIT PIPELINE DESIGNS
3.1 INTRODUCTION
3.2      STANDARD EXECUTION UNIT EXTERNAL VIEW
3.3      A PIPELINED EXECUTION UNIT
3.4      COMPRESSIBLE PIPELINE
3.5      FORKED PIPELINE
3.6      EARLY COMPLETION PORT
3.7      NON-PIPELINED EXECUTION UNIT
3.8 DUAL OUTPUT PIPELINED MULTIPLIER UNIT

4 CONCLUSION
___________________________________________


1.      WHAT'S WRONG WITH THE CURRENT SCHEDULER

Here is a copy of the text of the current scheduler
http://www.HansSummers.com/computers/fcpu/scheduler.txt


1.1      HIGH COMPLEXITY

The scheduler text does not mention that 2 FIFO's would be required, one for
each write port of the Xbar. The design of these FIFO's is also not simple
since their slots are allocated at different levels, so data must be
writeable by the scheduler to any stage of the FIFO not just the top.

Then we come to the LUT which specifies the precise information about the
latency of each instruction. Because we are SIMD the latency can vary if
different sized fields are used so the LUT must store latency for all
permutations of execution unit and word size. Straight away it starts to
look like a large LUT.


1.2      BREAKS MODULARITY

Elsewhere in the manual (v0.2 section 3.3) it says "For ease of development
and scalability, to name a few reasons, the Execution Units (EUs) are like
LEGO bricks that add new computational capabilities to the processor".
Ideally therefore each execution unit should be independent, each execution
unit should have a standard set of input and output busses and signals,
regardless of its function. Incorporation of a particular optional execution
unit should require minimal changes elsewhere in the core.

But the current scheduler breaks this modularity: already we have problems
with the divide unit and the load/store unit.

The divide unit has (in its simple iterative shift-subtract implementation)
a 64-cycle latency and we arrange for this by putting a 6-bit counter on top
of the FIFO so it doesn't have to be 64 bits long. At some point as the end
of the 64 cycle computation approaches, though, the 6-bit counter will
somehow have to reserve a slot in the FIFO for the result of the division
unit. How this will be done is not explained, but assuming that someone has
a solution in mind or that one is found, it doesn't alter the main point: we
have now forced extra complications on the scheduler because of the
particular requirements of a certain execution unit.

Similarly with the Load/Store unit: It isn't clear how the current scheduler
avoids problems caused by the non-deterministic latency of the out-of-buffer
memory access, but obviously the asynchronous Xbar write access must in the
case of conflict with existing FIFO slots, stall the execution unit
pipelines. More special cases: now the special requirements of one execution
unit are not just impacting on the scheduler, but all the other execution
units as well, which must now be stallable in the case of asynchronous vs.
FIFO conflict.

That's two problems before we even consider other execution units which will
also cause problems. For example, what about the integer multiply unit? The
mulh instruction stores the 128-bit result of the multiplication of two
64-bit registers in two result registers, r1 and r1 + 1. So it will require
a slot in both of the FIFO's, simultaneously writing two output results on
the two Xbar write ports. Yet more complication for a specific execution
unit - in fact the special cases almost start to look like the rule rather
than the exception. This is even before the more complex units have even
been considered, e.g. floating point units. The current scheduler will
handicap future more complex F-CPU implementations.

Execution Units like LEGO bricks but the bricks will only fit in certain
places and putting each brick in is liable to disturb all the other bricks.
I built a lot of LEGO as a youngster and it's unlike any LEGO I remember!


1.3      HARD TO MAINTAIN

The F-CPU development is a distributed and collaborative project. Different
people design the various execution units, and the other parts of the core
e.g. scheduler. The designer of each unit must precisely specify to the
scheduler person how many cycles of latency his unit requires, under the
various circumstances. The scheduler person must ensure the latency LUT
accurately reflects this. Then the designer of a particular execution unit
improves his design, and shaves one cycle off the latency. He'd better make
sure he talks well and often to the LUT person, or the whole processor isn't
going to work.

That's just when the latency of a simple unit changes. What happens when
there is a more major improvement? The division unit, which currently uses
the simple iterative shift-subtract method gets redesigned and becomes a
more efficient pipelined unit. Now we don't just have to update a LUT entry.
We have to alter the design of the whole scheduler, removing that special
case 6-bit counter which we sat on top of the FIFO.

Wouldn't it be nicer if each execution unit was truly a black-box unit as
far as the rest of the core was concerned? And the entire design of a
particular unit could be altered without affecting any of the rest of the
processor core? This would be conceptually simpler, less likely to go wrong
and far, far easier to develop and maintain in an internet environment.


1.4      FIXED LATENCY

The current scheduler strictly requires fixed deterministic latency. This is
a pity. There are many cases when an execution unit may be able to complete
its computation in less than its maximum latency, and the flexibility to do
this would improve performance.

For example, consider floating point addition. The lesser of the two
operands must first be shifted towards its least significant end by the
amount of bits equivalent to the difference in exponents of the two numbers.
Then the addition takes place, followed by a possible normalisation (shift)
of the result. Several possibilities for optimisation exist here.

First, no addition is necessary at all if the difference in exponents is
more than 53. This is because the shift of the lesser operand will make it
zero. In this case we just output the larger operand as the result. This is
similar to the decimal addition of 640 and 0.03, when I am only considering
a 3-digit precision. We don't need to do the addition: the result is 640.
The addition unit can potentially therefore complete in only once cycle, as
soon as it recognises this condition.

Second, the post addition normalisation may not even be necessary. This
corresponds to the decimal case 83 + 4 = 87. No shifting is required,
resulting in reduction of the latency by one cycle.

Other examples would include multiplication where one of the operands is
zero (0 * x = 0), or division where the dividend is zero (0 / x = 0). Of
course, the decoder could include extra logic to detect these simpler cases,
and bypass the execution unit altogether. But that's more
execution-unit-specific logic to go in the decoder, and even then I don't
see how it could do all the optimisations including things like the floating
point addition example above.

This is data dependent latency: wouldn't it be nice if the execution units
could themselves recognise where they could optimise, and complete early
under such circumstances? Execution units do not have to be designed to
optimise like this. Particularly in early days, we may wish to keep things
simple. But a better design would allow the black box execution units to be
internally redesigned without requiring any change elsewhere in the
processor, and invisibly to the instruction set or end user; just
functionally equivalent but higher performance. Even if optimisation is not
included in the first F-CPU implementation it is wise to design the
architecture such that it will be easy to extend in future versions.


1.5      BAD PERFORMANCE

The fixed-latency restriction above potentially impacts performance by
removing the possibility of data-dependent execution unit optimisation. The
current scheduler is OOOC (Out Of Order Completion) but the OOOC is based on
the differing latencies of the instructions in the instruction stream, not
reordering based on dependencies between the instructions themselves. My
proposed alternative solution would perform OOOC based on both the different
latency and certain automatic reordering of the completion order when
results are required by pending instructions.


2      NEW PROPOSAL


2.1      INTRODUCTION

My new proposal solves all of the above problems. It should also result in a
more precise definition of what constitutes an execution unit. All execution
units have the same external structure.


2.2      DECODER AND INSTRUCTION ISSUE

The decoder becomes much more simple, it can probably be done in one cycle.
I abandon the FIFO completion queues altogether (I'll speak about completion
conflicts later). The decoder simply checks to see if the execution unit,
source and destination registers applicable to the instruction are
available. If they are, the instruction is issued to the appropriate
execution unit on the next clock pulse, and the scoreboard "computing" bit
of the destination register is set to indicate to subsequent instructions
that the register is unavailable as a source register.

This scheme is easily extensible. The instruction decode is so much simpler
that it will be easy to construct multiple decoders and issue more than one
instruction per cycle in future.

We could even implement OOO (Out Of Order execution) on top of OOOC with a
little more thought, if we wanted to. Then we'd need an instruction buffer
and instructions which could not yet execute would have to set some
scoreboard flag anyway for their destination register, indicating that
subsequent dependent instructions could not be performed OOO. Provided
dependency was not violated subsequent instructions could be issued OOO.
Maybe.


2.3      EXECUTION UNIT PIPELINE

Crucial to this design is that each execution unit should have its own
destination register pipeline. These replace the original scheduler FIFO's.
Each pipelined execution unit has a 6-bit destination register input. The
destination value gets loaded into this input when the instruction is
issued. That destination value moves along the execution unit pipeline to
the output of the execution unit. However many cycles later when the
execution unit completes, the destination register number appears at the
output along with the result of the computation carried out by that
execution unit.

The output register number and result word appear on the execution unit's
output, at its Xbar write port. The Xbar then reads the result word and
writes it to the specified register. A 7th bit in the pipeline FIFO contains
a '1' when the pipeline stage contains a partial computation. The '1' is
loaded in when the instruction is issued to the unit, and propagates to the
output where it is used as the signal to inform Xbar that the unit is ready
to complete.

The latency of the execution unit is not stored elsewhere in the processor
core, and it can vary in a data dependent way, or from one F-CPU
implementation to the next.

For example, in an application requiring a lot of integer multiplication,
the application designer may wish to use an F-CPU core having an efficient
pipelined parallel multiplier. This takes a lot of silicon area, but he may
need the performance and decide to replace the standard shift-add iterative
multiplier which might be provided in the base F-CPU implementation. Easy:
he can just replace the inefficient serial multiplier unit with the parallel
one. No questions asked by the rest of the CPU or the software, just better
performance from a higher throughput and lower latency.

The only disadvantage to the per-execution-unit destination register
pipeline is that it requires higher complexity in the execution units and
greater silicon area. However the addition of a 7-bit pipeline is hardly
likely to be a significant complication, and given the 64-bit pipeline which
will already exist in the execution unit, let alone the execution pipeline
stages themselves, proportionally the 7 extra bits won't hurt the area too
much. The advantages though are so numerous that I feel this can be
tolerated.

An execution unit can even be non-pipelined and use the same mechanism. In
this case it can latch the destination register and output it to the
destination register output when the execution unit is complete. The simple
non-pipelined division unit can still have its 6-bit counter, but it will
now be inside the execution unit not the scheduler. At the end of the count,
the unit will output the completion bit and the 6-bit destination register
number.


2.4      XBAR WRITE CONFLICTS

Now I hear you all wailing about what happens when too many execution units
complete at exactly the same moment, and the Xbar has only two write ports.
The answer is that the Xbar selects only two of the execution units to read
from, any other execution units are stalled and wait for a space in the next
cycle. A mechanism must therefore exist to stall the pipeline of execution
units which have a result ready but the Xbar isn't ready to read it yet. I
consider this in more detail a little later on.

How does the Xbar decide which execution register output to read, when more
than one is available? Using the same progressive selection "find first"
binary tree mechanism described in the SRB chapter (manual v0.2 section
4.3). In this case the inputs to the tree are the 7th bit completion outputs
of the execution units.

If there are two write ports in the Xbar, an easy way to select two
different waiting execution units is to reverse the order of the execution
unit inputs to the find first binary tree. One tree can search from the
first execution unit moving forwards, the other effectively moves backwards
>from the last execution unit.

This also raises the possibility of re-ordering the completion according to
priority. Similar to the SRB mechanism, each execution unit can have a
"express request" bit output, set to '1' when it urgently needs to complete.
I can think of various methods for setting the express request bit.

The express request output of an execution unit could be set when the
instruction issue unit is stalled because it is waiting for the execution
unit to become available. This could occur often when using long latency
non-pipelined units like the divide unit.

A second alternative would be to set the express request bit when the
destination register is required by another pending instruction. This though
could get more complicated, since the pipeline of an execution stage could
contain several destination register computations, how would we detect that
one of those is required by the instruction issue unit? In the simple case
though, just the completing result could be checked against the dependency
of waiting instruction operands.

Thirdly, if the execution unit pipeline is compressible (another idea of
mine see later), the express request bit could be set if the penultimate
pipeline stage is computing a result. This would indicate that by not
selecting the result of that execution unit the Xbar would delay more than
one instruction.

Whichever way, it is clear that the Xbar can simply use this method to
ensure that there is no conflict on the Xbar's write ports due to multiple
simultaneous execution unit completions. At the same time, execution units
are free to complete early if they contain the necessary optimisation logic
and the operands allow it, and the OOOC does not just reorder instruction
execution based on execution unit latency, but also based on dependencies
between the instructions. This should all improve performance, modularity
and scalability of the design. More execution units can easily be added or
replaced with more/less efficient ones depending on the requirements of a
particular F-CPU implementation.


3      EXECUTION UNIT PIPELINE DESIGNS


3.1      INTRODUCTION

In this section I discuss some ideas for the design of the execution unit
pipelines, and black box representation of the execution units.

In my examples I don't consider the logic necessary to implement the
execution unit's function, just the logic to control the input and output
control signals and pipeline. I also don't consider at all the use of the
opcode bits that determine which instruction the execution unit will
process.

I aim to show that the proposed structure is flexible enough to generically
satisfy the requirements of all execution units, and present exciting
possibilities for improving the performance of execution units by data
dependent optimisation and compressible pipelines. All of which do not alter
the external appearance or function of an execution unit, as far as the rest
of the processor or software is concerned.

Important note: these ideas are really just "technical cartoons". The actual
execution unit input/output signals will have to depend on the precise
nature of the Xbar and instruction decoder. The general principle I am
proposing is the dropping of the instruction scheduler FIFO and replacement
with execution unit FIFO's so that execution units are made more modular and
performance is increased.


3.2      STANDARD EXECUTION UNIT EXTERNAL VIEW

Under this new proposal, there are no special cases for execution units. All
units are treated the same way by the instruction decode and result write.
This allows for the precise definition of what inputs and outputs every
execution unit must have.

Inputs:

--Instruction Load: Signal is set to '1' by the instruction decode/issue to
indicate that on the next clock pulse, the execution unit should load
supplied operands and start processing

--[0:5] Destination Register [Optional]: 6-bits indicating the destination
register of the computation result. This is optional since a Store operation
for example does not generate any output

--[0:n] Opcodes [Optional]: Whatever sub-bits of the instruction opcode are
required by the execution unit to determine which flavour of operation to
perform

--[0:63] Operands [0, 1 or 2]: Input data from the Xbar registers. Some
execution units require no operands (e.g. Load), some 1 (e.g. bit shuffler),
some 2 (e.g. arithmetic)

--Acknowledge: The Xbar sets this input to '1' to indicate to the execution
unit that on the next clock pulse it is going to read the result from the
result bus. The execution unit uses this signal to stall its personal
pipeline when the Xbar cannot take the result due to a conflict (too many
units completing at the same time)

--Clock pulse

Outputs:

--Complete [0, 1 or 2]: Signal is set to '1' indicating to the Xbar that the
execution unit will be ready on the next clock pulse, i.e. its output bus
will contain valid result data. For the Store unit which never completes as
such (requiring an Xbar write) this signal does not exist. Units having two
result busses must supply two independent complete signals

--Express Request [0, 1 or 2]: Signal is set to '1' to indicate to the Xbar
that the unit wishes to complete as a matter of urgency. In executions units
where this is not implemented, the signal can be hardwired to '0'. Units
having two result busses must supply two corresponding express request
signals

--[0:5] Destination Register [0, 1 or 2]: The register number of where the
execution unit wants the Xbar to write its result data. Optional because a
Store for example has no output. The 0, 1 or 2 corresponds one-to-one with
the Result set (see below)

--[0:63] Result [0, 1 or 2]. One or more result busses may be presented to
the Xbar. They can all be considered independently by the Xbar. Data must be
valid at the next clock pulse on the result bus when its corresponding
"Complete" signal is '1'

--Ready: A '1' on this output indicates to the instruction decode/issue unit
that this execution unit is ready to receive another instruction for
processing

http://www.HansSummers.com/computers/fcpu/scheduler.htm
A typical unit having two input busses and one result bus is drawn
diagramatically in Fig 1.

It is important to realise that the execution unit is now a black box. It
can determine its own latency, be pipelined or not, and implement its
function however it wishes. Externally the function is identical and the
rest of the processor core knows nothing about the internal implementation.
Execution units are then truly like LEGO bricks.


3.3      A PIPELINED EXECUTION UNIT

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 2 shows a possible implementation of the internal pipeline logic of an
execution unit having one input operand and one result word.

The pipeline latch registers must have a clock enable input to permit easy
stalling of the pipeline. The data at the input of the latch is clocked in
on the positive-going edge of the global clock only if the clock enable
input is high at this time.

It shows how the 3-stage pipeline is stalled when the Xbar cannot take the
result operand. The enable inputs of the pipeline flip flops is '1' when
there is either no result pending (Complete = '0') or the Xbar takes the
result (Acknowledge = '1'). Therefore when a result is pending and refused
by Xbar, the entire execution unit pipeline is stalled. The Ready output
comes simply from this enable signal, so that when the pipeline is stalled,
the execution unit signals the instruction issue that it cannot accept data
on the next clock pulse (Ready = '0').


3.4      COMPRESSIBLE PIPELINE

An interesting idea I had is the "compressible pipeline". As the number of
execution units is large relative to the number of instructions issued per
cycle, it is unlikely that the pipeline of a given execution unit will be
fully populated. In this case it is possible to partially stall the
pipeline. Imagine the final stage of the pipeline stalls because the Xbar
cannot take the result data. If the penultimate stage is empty, there is no
need to stall the whole pipeline. Data earlier in the pipeline can still
move to the next processing stage, without colliding with the waiting
result.

I call it a compressible pipeline because I imagine an industrial pipeline
transferring some substance, containing bubbles. If the gas of the bubbles
is sufficiently compressible you can imagine that even blocking the output
end of the pipe does not stop the movement of the substance further back in
the pipe, the bubbles just get squeezed out.

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 3 illustrates the principle of a compressible pipeline.

a) The Xbar is not ready to accept the result which resides in the last
pipeline stage
b) A bubble exists in the pipeline, enabling subsequent used stages to move
to their next stage on the next clock pulse
c) On the following clock pulse the result is accepted by the Xbar, and the
pipeline moves on as normal

This also leads to an implementation of the express request signal, such
that express request is signaled when an execution unit's pipeline is full
and cannot be further compressed. It indicates that a delay in the Xbar will
delay more instructions in that particular execution unit's pipeline, so the
request should be considered high priority. This is an implementation of my
third suggestion above (section 2.4).

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 4 illustrates the logic of a compressible pipeline unit

Here the latch of each pipeline stage is enabled when the following stage is
empty, or the Xbar is taking the result data (Acknowledge = '1'). Again the
Ready signal comes from the enable of the first stage flip flops. I take the
Express Request output from the complete bit of the penultimate stage
pipeline: this means that when the penultimate stage is full, the Express
Request bit will be '1' giving priority to the Completion request on the
Xbar.

Of course an execution unit does not HAVE to contain a compressible
pipeline, it is merely an idea which could be useful in some circumstances
and I mention it to show its usefulness and that the proposed architecture
is flexible enough to permit it.


3.5      FORKED PIPELINE

Another interesting idea in an execution unit where the execution pipeline
can be forked when early completion is possible. This reduces the latency of
the execution unit. For example the previously given floating point addition
example. If the unit notices that the addition will simply result in the
larger of the two operands, and no addition needs to be performed, and if
the final stage of the execution pipeline is empty, the unit can route the
operand directly to the final stage and alert the Xbar.

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 5 illustrates the logic of a forked pipeline (simplified) floating point
addition unit

How does this operate? The first stage produces an early completion result,
if it can do so, which is equivalent to Operand A or Operand B. In this
instance, it also sets its Early Completion Signal output to '1'. The final
output stage is fitted with multiplexers. Provided the final stage is empty,
the early completion result is routed directly to the output. The
destination register number is also routed from pipeline stage 1 direct to
the output stage. The 7th bit (Pipeline Stage Full) at the top of the
pipeline register in stage 1 is not passed on to stage 2, which becomes an
empty stage. (I pass the data on anyway, but the result from it gets
ignored). If early completion is not possible, the execution unit operates
as normal.

Note that I am aware that each of my 3 stages may well take more than one
stage in the F-CPU, this is just for illustration. The point is that the
execution unit can depending on the operand data cut its latency from 3
cycles to 1. Again this is just an optional extra idea, which the
architecture is flexible enough to allow should it be needed.


3.6      EARLY COMPLETION PORT

Another idea for early completion is to have a separate output port for the
early completion result. Such a scheme could be useful if the execution unit
was likely to be heavily used and early completion was possible often. In
this case the execution unit would have two output ports. They could be
activated simultaneously depending on the contents of the execution unit's
pipeline. It is the responsibility of the prioritisation activities of the
Xbar write mechanism described earlier to handle these outputs.

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 6 illustrates a floating point addition unit which forks the pipeline to
an additional early completion port, rather than recombining at the final
stage.

In this case the first stage 'Early Completion Signal' forms the 'Complete'
output for the 2nd Xbar port. If the Xbar accepts (Acknowledge = '1') then
the data exits the pipeline. If the Xbar does not accept, or indeed if early
completion is not possible, then the execution unit operates as usual. The
execution takes 3 cycles or 1 cycle if early execution is taken and the Xbar
does not stall the result.


3.7      NON-PIPELINED EXECUTION UNIT

Here I consider the design of a non pipelined execution unit (such as the
shift-subtract division unit). The destination register is simply latched,
and the latency cycles counted by a 6-bit 64 counter. When the count reaches
64, the complete signal is triggered (of course, any required latency could
be obtained by decoding a different count)

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 7 illustrates a non-pipelined divide unit

This one is particularly simple. The synchronous 7-bit binary counter
initially holds a value of zero. When the execution unit is operating, the
output of the top flip flop in the single flip flop stack will be a '1',
enabling the counter. When the count reaches 64, the 'Complete' signal
becomes '1', which also suspends further counting. The Xbar acknowledge
signal is used as to Reset Enable the counter, so that on the next clock
pulse its count returns to zero. Acknowledge also enables the Ready signal
so that the instruction issue unit can send another divide instruction if it
has one pending.


3.8      DUAL OUTPUT PIPELINED MULTIPLIER UNIT

The integer multiplier generates a 128-bit result (e.g. mulh instruction).
This unit can just have two output ports! It is made very simple in this
proposed architecture. The destination register output of the high word is
just generated by adding one to the supplied destination register. For
multiply instructions which don't generate a high word, the second port is
simply not used! Again the Xbar will handle prioritisation of reading the
results etc. My example design here is only for the mulh case (128-bit
result to two registers), in reality one would put extra logic in to decode
the opcode bits, since the high word may not be required.

http://www.HansSummers.com/computers/fcpu/scheduler.htm
Fig 8 illustrates a design for the multiplier unit

The complication here is in the final stage of the pipeline. The destination
register number for the high word is created at the final stage by adding 1
to the supplied destination register. The flip flop stack for the final
stage contains two special flip flops in place of the usual one (top). Both
have the same input, and their outputs form the respective 'Complete'
signals for the two Xbar ports. I assume that the usual enable input to the
flip flop is a clock enable, and that a separate Reset enable is available
(this shouldn't be a problem, I don't think these flip flops are in the
critical data path anyway). The Acknowledge signal returning from the Xbar
is used to enable a reset of the corresponding flip flop on the following
clock pulse. The execution unit pipeline remains stalled until both output
ports have been acknowledged by the Xbar (not necessarily in the same cycle)


4      CONCLUSION

My proposed replacement for the current scheduler unit is conceptually
simpler. The decoder/instruction issue unit is made more simple since all it
does is check availability and then issue.

It will be easier to develop among a distributed group since the execution
units are externally precisely defined. Unit designers can enhance execution
units without affecting the rest of the design or requiring any changes
elsewhere (no latency LUT!).

Performance is improved by improving the OOOC (result prioritisation) and
permitting interesting optimisation variants of the execution units
(non-deterministic latency).

The execution units may truly be considered like LEGO bricks. Different
F-CPU implementations for different target users may be built with different
execution units, or different variants of execution units depending on the
particular performance vs. cost needs of the implementation.

The architecture is easily extensible. It is easy to see how more ports
could be added to the Xbar, or the processor made superscalar by issuing
more than one instruction per cycle. It is even possible to duplicate
execution units if necessary. The complexity of the decoder will remain
manageable.

The architecture is innovative. Its principle of operation fits well with
the goals of the F-CPU project. The instructions are free. The data is free.
The instructions and data flow between the execution units which can adjust
their latency at will, and the Xbar dynamically schedules the instruction
completion according to priority.
Yahoo! Groups Sponsor

www.

From Yann GUIDON Mon Feb 5 12:01:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00942 for ; Wed, 7 Feb 2001 00:52:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:28 +0100 (MET) Received: (qmail 19758 invoked by uid 0); 5 Feb 2001 11:08:28 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx14) with SMTP; 5 Feb 2001 11:08:28 -0000 X-eGroups-Return: sentto-1101623-2256-981371303-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 05 Feb 2001 11:08:25 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 11:08:22 -0000 Received: (qmail 58207 invoked from network); 5 Feb 2001 11:08:22 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 5 Feb 2001 11:08:22 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 5 Feb 2001 11:08:21 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA28666; Mon, 5 Feb 2001 03:08:18 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWP6N; Mon, 5 Feb 2001 11:13:16 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7E8821.C49A9B5D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <45.1f16095.27af95e5@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 12:01:53 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2da3760791481d81da6ca41f24fd0339 Status: R X-Status: N hi !

ok, the answers, now :

Carsten899@aol.com wrote:
> >I have also enclosed another file with the opcodes
> >in a "clean" organisation (even though everything is temporary).
> >it can help you.
>
> The opcode map is already included in the virtual FCPU.

well now at least you can compare :-)

> The result of my long-weekend-hack (sourcefiles) are found at:
> ftp://members.aol.com/carsten899/f-cpu
> There are three sourcefiles:
> fcpu.h  - interface definition to virtual f-cpu
> fcpu.c  - virtual fcpu and fcpu assembler (i like big files :-) )
> fcpudbg.c   - simple command line shell

mmm i gotta read and compile that ...

> I make these early versions public, because i hope someone out there is
> interested in doing some testing. I am sure there are many bugs.

is it under GPL ?

> Some instructions are new (not mentioned in V0.2 manual) like OP_SCATTER,
> OP_GATHER or OP_LOADMI so they are not implemented.

yup. well we better find a solution/discuss about it before v1

> >>the memory protection issue can give you serious troubles.
>
> which troubles do you think of?

simply about the goal of an emulator :
it should ease the development of SW, incl. the kernel.
how do you simulate a whole system (not only a user task) ?

> >years ago, i had overcome this problem : using only arrays of bytes.
> >that's all. Every operation was performed with bytes. hyper-portable,
>
> all register an memory access is abstracted by functions calls like "give me
> word x from reg y" ( fcpu_reg_get_doublebyte ), the problem arises in the
> arithmetics routines in the current implementation.

heh.

> >at the cost of some serious speed
>
> until stable definition (which i think will be manual 1.0) i would like to
> concentrate on correct implementation, not speed.

i'll try to check the behaviour on a SUN.
OTOH you can try to see if the compiler output is suitable to your emulator.

> Best regards
have fun,
> Carsten

YG

speaking for himself
Yahoo! Groups Sponsor
www. .com 
From Yann GUIDON Mon Feb 5 11:54:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00945 for ; Wed, 7 Feb 2001 00:52:29 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:29 +0100 (MET) Received: (qmail 24065 invoked by uid 0); 5 Feb 2001 11:14:22 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx24) with SMTP; 5 Feb 2001 11:14:22 -0000 X-eGroups-Return: sentto-1101623-2255-981370875-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 05 Feb 2001 11:01:20 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 11:01:14 -0000 Received: (qmail 46199 invoked from network); 5 Feb 2001 11:01:14 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 5 Feb 2001 11:01:14 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 5 Feb 2001 11:01:13 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA28169; Mon, 5 Feb 2001 03:01:09 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWP56; Mon, 5 Feb 2001 11:06:07 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7E8674.DEE8F2C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 11:54:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] http://www.f-cpu.de/emu/ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 22210f52e4a32572d8057aff75b52ccc Status: R X-Status: N hi,
i have created a new directory for the simulator.
later it will link to the other sites and files related to this side
of the project (i'll simply put links and you'll have to make the rest
of the work ;-P)

i still have to digest the recent submission from our new friend Hans Summers ...
this day is going to be very interesting :-)

YG

speaking for himself
Yahoo! Groups Sponsor
Personalize your company´s name. Choose the domain name below and press SEARCH!
www.
Yahoo! Domains
From Rares Marian Mon Feb 5 16:50:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01032 for ; Wed, 7 Feb 2001 00:52:53 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:52:53 +0100 (MET) Received: (qmail 25076 invoked by uid 0); 5 Feb 2001 15:45:21 -0000 Received: from hj.egroups.com (208.50.99.212) by 10.1.4.111 (mx11) with SMTP; 5 Feb 2001 15:45:21 -0000 X-eGroups-Return: sentto-1101623-2257-981387876-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 05 Feb 2001 15:44:43 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 15:44:35 -0000 Received: (qmail 4292 invoked from network); 5 Feb 2001 15:44:34 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 5 Feb 2001 15:44:34 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 5 Feb 2001 16:45:39 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 6785C4525B; Mon, 5 Feb 2001 10:50:10 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010205105009.B691@moonbase.res.wpi.net> X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 10:50:09 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Equsolver .2 Format thoughts (I'll need to modify my previous examples) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4ec50f65c6a9dd4c23442a31610ded06 Status: R X-Status: N The registers need to have a few things

3 outside flags
0 - ready or busy flag
1 - here or equation flag
2 - value or address flag

The basic form is
6 bits
Target register
6 bit groups
0 hold row/col
1-3 register
4,5 add/sub,mult/div
1st register is the equals reg. All the rest are sources. Parentheses are
expressed by referencing other equation registers. The hold flag allows the
register to be addressed by taking the current row or column and pairing it
with its counterpart specified in bits 1-3. Since the equals sign (used to
solve equtions) is understood the first 2(t) op bits correspond to how T is
written overwrite,and,xor,or.

6 13   2  132 132 132 132 132 132 132 132 13 ( T = target, @ reg, + op, t
op against T)

T @ =  t  @ + @ + @ + @ + @ + @ + @ + @ + @

result: one register capable of holding an equation of 9 terms.  Or a 3x3
matrix using the cascading I mentioned before.  I'll need to work just a
bit more but I might seriously create a CPU capable of calculating row
reduction of matrices.  I think I've just found what will justify 256bit
and 512bit register files in the future.  I'm dying to model this.
GPLd of course.

Alternatively we could skip the hold flag trick and pump up the number of
inversible operations checked for.  This would be the simpler but more kick
ass model.

Then the form is
6 bits
Target register
6 bits per register
6 bits per operation (probably too much)
overwrite only for target (t)
4 bits not sure what to do.
6 6   6 6 6 6 6 6 6 6 4
T @ = @ + @ + @ + @ +

I'll fix that later ignore for now.

Rares

Copyright 2000 Rares Marian
Yahoo! Groups Sponsor

www.   
From Carsten899@aol.com Mon Feb 5 18:19:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01080 for ; Wed, 7 Feb 2001 00:53:04 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:04 +0100 (MET) Received: (qmail 11266 invoked by uid 0); 5 Feb 2001 17:20:20 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx14) with SMTP; 5 Feb 2001 17:20:20 -0000 X-eGroups-Return: sentto-1101623-2259-981393603-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 05 Feb 2001 17:20:17 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 17:20:02 -0000 Received: (qmail 50148 invoked from network); 5 Feb 2001 17:20:01 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 5 Feb 2001 17:20:01 -0000 Received: from unknown (HELO imo-d07.mx.aol.com) (205.188.157.39) by mta2 with SMTP; 5 Feb 2001 17:20:01 -0000 Received: from Carsten899@aol.com by imo-d07.mx.aol.com (mail_out_v29.5.) id r.68.bc68e9d (1883) for ; Mon, 5 Feb 2001 12:19:56 -0500 (EST) Message-ID: <68.bc68e9d.27b03abb@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 12:19:55 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: multipart/mixed; boundary="part1_68.bc68e9d.27b03abb_boundary" X-UIDL: a0a1faedd012b158d1d666d9cc7b574c Status: R X-Status: N --part1_68.bc68e9d.27b03abb_boundary Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

i think the ftp isnt accessible for anonymous persons, so i=B4ll zip the co= de
and attach to this mail. (i will also setup a homepage at
http:\\members.aol.com\carsten899\f-cpu).

>>is it under GPL ?

i have to include appropiate headers. It will be under GPL.

>>simply about the goal of an emulator :
>>it should ease the development of SW, incl. the kernel.
>>how do you simulate a whole system (not only a user task) ?

first i thought about thousands of lines of code emulating scsi-, uart-, pci-bridges and so on in software at the I/O level, but this isnt necessary= .
My idea is as follows:

* Include the Virtual-FCPU in the linux kernel of your host system.
* Include an appropriate linux kernel compiled for FCPU in the kernel.
* Right at the start of the host system kernel_init() (dont know the exact =
name
of the linux function) let the Virtual FCPU start working:

fcpu_reset();
while( 1L )
   fcpu_clock() // execute fcpu instructions.

* "Map" host system I/O into FCPU memory space:

void fcpu_mem_put_quadword( int64 address, int data )
{
   if( FCPU_IOBASE_IDE_CONTROLLER =3D=3D address )
     *HOSTCPU_IOBASE_IDE_CONTROLL =3D data;

  //....
}

Now the Virtual FCPU executes a kernel dealing with physical I/O on the hos= t
machine. Okay - there are open issues, like interrupts, speed. but i think =
all will be solvable.

Best Regards
Yahoo! Groups Spons= or
3D""3D""=

www.

3D""
--part1_68.bc68e9d.27b03abb_boundary Content-Type: application/zip; name="fcpu.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu.zip" UEsDBBQAAgAIADEwRSpm4blTsAMAAHUNAAATAAAAd29yay9GQ1BVL2ZjcHVkYmcuY61XbU/b MBD+Xqn/4egETWmBtkwTWtdOEwWBxABNDCExVIXUSa2lcZYXYIP+990laerESdpJs1QlOd+d z8/dc3YPDuq1gwM4Pb7+DmP2GFoW80hSr9Vr77hj2OGUQcMPplzszxqyzDTcMBLVa0+CT4G+ J0/zyYzZttAgkrXqtdd6DXC4HncCU4PGbuX44TSgNcibQMUoMzndoy3dci8IdRu+6saMOwxu e/td+H+r/PtelsKFgts0nLsTfNfgmrJB0bsSgMZM9+SIHkPTZN499PpH8JCsEjo+txw2BVs4 Fn3bF+K5dO6MW7OSST6g8CBVgyFoGZ2WBhq4eyPu+IE3cQMPRiM47EMLdqD7cpqMdPtRILCZ F+iWeaERv/lLPGMUOtC4PoaPsN09uqNfo5PE3UlWzqchNlOzA1CRslhsCk8DjlvpDvDxCT4c 4rPdpkzR9Osq1DXQecy6Rw9t6MFDNXobIJh3tgmIxUB+2+727zJQaonjVhmqFcgWorua4qYW ud+GQ4x3OIT+EkfFWGbToog/ttCnE92fy/zpRLTZBd2zniQunZ5fnBDdXZPbbJDllzHLCWzs G0izbv99yrPl1Iy9COOeMrecSfgTEYiewggefwcMRO5bT2GIYsC8msJljhZFilnwVpsljGIl tcTiOlx9P89QT4Mtk4mVlQzpaxZdg8rTtFhgpNqDrAatjlpbQ+gd5nOTcyapYyZ73bx6iYna f0J7nKkSecTZ4Fjl8c6LtaKaiGoBS4BMOrAj8Kd3oHeh7FGlRSY2e6zSTpQunTIqKg5MZdqQ xqULZ0zWamW6VJkSbXq9p2xrU5KZq67lWKgiZvts42zLOUzpVlRJ1F818PmfqJzjLcEetaKi 2kot2+31QUuf0qtp2MJneS4sUq5ucIrTHWrdMW7Mp6vzhAw95rNAI8VUjjoITxOaSRAJtUmM ZGz+aha0A/Uq4ebSm+5glE/8VCjNIYqAmgPGrMm1tFhGE8czjJsDvL1JAjqAStZWqy5qG7Fh 83OzomEVHgfKpId3gQhSMPcQhkpdH3V97liYbz9gLggssug+EhoBF06lrYW2lsDuFXAbzr5c 3IDwgL0YzF1rmp9clMHhNfO1rlaM2sBkD36xByx14+dmHqyqlKiFU71EpoDw6pLiRUsRZSYn d8cn1zfnV5eTy6vLkzxMygVgrnM8OBFXOjwN+ci/f5AP/YSNGFiWfOl/llVN0ubJGYyo2agE W901dlDSiRfrPcjXRLUfkGrcNf4CUEsDBBQAAgAIAHUwRSrNR2AYFycAAGJxAQAQAAAAd29y ay9GQ1BVL2ZjcHUuY+w9a3PbOJLfU5X/gGRqcnJiO3xIshLHmZJtOdEWbXllOZeZrRsXJcE2 7yRSS1Kxs4nnV90PPAB8AWSDL0lJ7i6qyVgim92NRqNfePDlS/R8jZ/Hj14ShMH/0QfL9Zfm DJ0cnV+iRruJDi0fWfPFDM+x7Zu+5dhb6IOyq/FPrZWZx49+sezJbDnF6On1ZLHcvX3KLk7x tWVjxtjVae90MPz96qL/R+/q8PdR7wLFnwZSDdIOVdGayd8tiuHlywyes8vTq2HvHfd4/Gk3 jRTwsHfRG12dHwHAipElcNgfNdA92go4evMGBb9krBj90cjoXfXOjvvdM5iCAH/YfycFJh/V yFCg0joaHAcSK0Ehhj8eXB4avfRTqhT+75fd4ywNTQo/OBoBLOmxTH+xrpHKfjxHtuMjE7mY qOhTZ4FdppFPkWUj/xYjD9seJt9Mn/2cmr6JTBezp+bO1Lq28BQ9f5liZHB+dTr4kNBXGCXP QWeDc2R5aIp9PPHJk3eWf4tMm1DzfHc5oaQR/icdLr6D/oVdh+HOYqd4AqTXzmzm3BFU489I R3i+8D+Trz72ttF4GTDdRjPT89HY8j3UmGLy1cU3W2hC6I5J28gF8rjt3FGaHh2Z1vVn8qBl 33i7IX1CqG/7+Aa7pPWE5zn2rYkHNrx7fMx1Ufb+xeVhcr8JCO7S4MZM9v5x/0NyvwMJnqOv KiCDCQ8qwOFplxuRqs7pCdWS2WdOBLu7u6AQzgfnR4PLs1GAohmJ8OxoZ2x6RNpcf8NSPDo9 T8SgNWGAWMG0NtSKj1w/QILqcwNdBwR1MRiOEgzReDHOLlA8TmDmDV4HdEDCBq8EeiThi/cG ajz1bpfX1zPsPt0qInPxvn8yiqSktyUAwwigIwPohroIiGA4GCXd0NRAgGECAPQTMdpkrEYA bRBg2ItUutkJJNE/PSZmYcpG8k4gETIcYUPT5/q5BbDY+3jePYv6o6UDUji+PE8wAG047w1P LyNzqlJlY1wOB+caWtrEnTfo4Jg41Kn7GL2mX8cUATF1Nr7bgpVk8K4fj7MWIJijwelh/4wY cyrgVkcOwFrXehVydXIusgNTP+FVtA20+YRX0XYLAOANVRvg/4S3VHsqhIEzNHstmMmYjb1I 7GTwbKOpM8fE9rtzj1gjZM6Ib7GoG/GxO8dTy3Q/s7vEbcGy7yat7ygwwEkMAFnx0WAYm59O UwIQoehA3ds9et87PQ0BOpCXuzjqjka9YaR3e1mId93R+wiAQHRCEZ32L46IGtKm09E0PAx/ QM08TXxFR9KMCESl7oShnDi27zqzHRfPTF8SAfzt9LybuBGVdR99+PEjsJ9eo+GQ3NqRfMit wGHPHGIIiKfGxAcRdzwcDpHjon6H/G3QHx7GRCnG2CcktuhTztL2D1SiXokrL++HCCjnC9sh /4jFFUHoQe3S9dIOcYRBBbYnzpThZ5As9FA1ZtJUHT1hKDKOvXcEXj/rvQOvdw8vojaxVt06 M4yISPCuJGgi6pR4PE2p4M+0/lnsCfUmJKWRFhsDvRX5swpWnIarsRtoKbEt20aCaQVNGc9d ew/mLh7MbUDJT/rd82HkRdqvIGP49+EoAtpTJACxKQPsxQkx94mtA5zQCXFTCUATHsjnQ8lA ftcb8UEf5MMuBYh2hYFsDBIPTgbyHv1DHiURskc8nP1vPrpxrGBQEtWn49EmQSJRfY8aad+a 4yhMDIfPSTDiHZv6SjpyoXFPrjUWs6VHQvIbm44gitFEr0jCQH4kI5uaRfrjloSm2L6hKOfm AhF46hOo7rgu9haOPfUoh3Q4UjMRWp27W2zjT8SOLBzPs8YzvP34kRdAkeTmmowme8L8+FPa qKeM55CXuUMyiQkxIx7aeYuw6VkEzRSTgU+EsUuZKswdwOC8n0SGYPaQ3G+B2UNyfw/MHpL7 r8Dsoc/1dbHBhCPzGIfWkoTuEQTk1UjonjChvQJDd05Kal6GkpueMCRqa6X4O2RE35OF1xHA K2n8HUA0VTj+jlva1OH4OwFoSeLvCKK5J4u/Q4jmq8qWm0bPMQet1vpi4whpay8vNiZQbSU3 Nu6jtpqEjtI4KG5DR5UAxNGcLomTIhSdlgwgRNHZk8aDfS4eLI7d+rFBfyWL3frRWFbT9te/ c6j9Vdsy+xuGTsSdJWUQ0SNNZg4tDzli2UfG7tHgLCgMvmoHLqS54yxooIRck1puYnjvMAuh JmQcE23RWu0dZm3nLFj0sZeL+2MgCoXhtqZ4HrHpO745I1x3UEDPS9qT61M5U6i0QJ/KQ+xV 8qndY2Lrh2HfNOUQgY2KjBTXe7cuZv6TVkfQTk7/KZwnkusTuXN10Q2LdipUF6IQw16Y+ai0 MFSysRe/k9DTMCJFBCKw4QlXrFRVQJnfd40kgFE1qFzTG/a7Rv+PXgChQr7pg9H/dw6LBkMo HESgqN6ts5xNaXjjEpnSyN6hwYjGtHNML9FM5gnYeopRTTDqAcbljARGRGKzz9voLkIejoZf tJa2o7VaUnRagq4JQ+gJRKA5L9GTJ0/QICBAA6QgvPHQtevMyQWbFl1ZusJ5e2fx3178bNdD LPcyPYTnS9LbJO2iRpya91s6fqcxKAmfPByPNVovDlicsvwEiHoOuQkDTQE6lyRHPARgokma xENorPvxzMOSMEta5M8t2OaV39PF21TpPbeQy32aRoGAuE/LKKhr8vMvRkGRlPvsGQWpMPfp GAXdxX1eGWBiyhcy+d5QjIKiJg+sGgUFTh4Y6jyh2MkD60ZB4ZMHhrpPKILywC1QHkJpkNc4 SB5CrMQDg/LgS508sCZhpAuOEx3sGL4kxgOrRkHExQNrRkFwxQPrRkHpjgduGgVVOh64ZRQE gTxw2yiI93jgPVDSwnQZP8AVoyCW4oFVoyA44oEhSQt1BB4YkrRQUuCBm0ZBNMUDt4yCwIoH bhsFRUweeM8oqGfywJAVE0q0PDBsxoSCJ29MZX0YB4A8sGoUxII8sGYUlGt4YN0orDjwZl0x CsoPPLBqFNQieGDNKChM8MCQ5glznDxw0ygoafDAoPPsSpwcpHnCLCcPvGcU1Bx4YEjzhDla HhjWPCH24d0t1IfC1CoPrBoF06w8MGin+QlTHlg3CspEPHDTKCgZ8cBQHwp1bh64nRN99IHo Qx5+QNA58Uc/Cy0LQCCRqIosAoGhpSFIH4KGYxChBieEWYpRUJAToFVY5nxGyMchYGQh5H4C NCRzIZcUoEGd5dNeAVo3ClJgARqMLviMVIAOZY5tkoUly5f8zwtMUKBPjjVFjefnRxdHw5PL s6OtBjqnOMl/28iZ+LQqx31ZZL6hrf0Ia/SP4aSrv66whRsBia3Hj76wqSVE8rYkp6OTczbJ BrHrOm6wVgdPnzx+9JDgRKd47pCMtzuZYM+L+HdszKjP8fwfsmVl/8E4S7ghsFc32L+iDybN RIu4fShpKjK5Ji6cBWsAClrwnP4+QI3w9hbjwUS/5vHxkGVlsSzPSvQ1ZCTgo5AuYzIQ1Jaz gLmgArEZH14VRmxAPAFXCavjffGKFf4WpKgY4dVrx20gi17ZJ3/eIJv8efGCIqZ3Q+Txg2/e HJBskHVwdN27s/zJbQPh6JnUc/RD51CAJXuvRSjGTlZjiFCIMEz0AjWQjXaQSv5ZaGsbPSNt ZeMgjWTsYvO/BCZFJpJ1gFU5sCpTJaPdXM58GSE6VPOQRb8feLysK74ecH39IFX1ekoGKn6+ ilVUJypF2gL0DCn3Jyf7/B309u23UrPEGgidvFnNgoimdPt7KRmvTKJTiYbE1FmOZ7i2MQ/V BLSDoTS2kWZsBw/ITXg1NkB9hseJwATPAyyOfy7N6WaF0SwWRhUm6oiiWUoUIebNSaJTLIkK PNQRRKeUIDzrX3i6ghgiW7fYectm46+uZzcUJ2BGmelRjdTIl/uwRID5VoXh1XLx8iOwDvZm LvZEpevg7uTijpWkFOp8/1q6r0F1W19PZ3xKrKgrdXTa1NZA3sxFDvTzOrpZsAVlMKcdH8mA hvjG8kimlM6Bwo5ktJihwtbN7dhZulcuvrmyiDZEIC7X1S72l65N/LxLvL2KtqIEItpPk7Vp FFt+4uQmX8dSa2JdN5CCDg4CboQYksumlFAGwXxaGooqKGHnHwRHim2S7rx9SwA6dOfQmG7W YRGdInxYfAe0Lj8XE1sHjp+gbU+4tgkhJnp2EEWXyeW8phD4vxoA+8FepKSN++XQkRidPJb+ sDwKQvcgVYGiaOcHUgS1LdeEk5M8TajWyFX0YUWNoAiCLuQauxaVyOKT60R+0PcDaYSuwRpx En7kGlGliavpw0o6ESEI+pBr7lp0IotPrhO54a+7ST3g29duQsW3qFOLeCzZkWmhUqKsoiB3 pCxWuzL9QtLehkNz0bMTHghtbw2hOeQu6mBv5mIXQrbKuDu5uPmYza0Tlwt9XXUcSLQl4EWR Jp+RZlfRrw2mA2JkFffROpQLSAeqIm/mIgd0ax2qlU4H3NK5gKSXq1kviZbEepUuKUT/ePJ0 k8QVvvexPb1yFg1BhTnNArTJK60+1Moye07ddEfhTW269py4zeCjKClhil5CeJx5XSBDqKOa KZaVCkxTuiswHYYMeQXVZNpFrv6ZBiilGxFxUrMRXNxTZ3CRDDmeMcB4SteJsp08TEc9y7Gr DC7fXdqTjel10vbaesajWEu/iwjX3A9MnGxjS+lqR3tXRd1kU02f2wYUw5w4LqJ7qYTtN/Ee Groo2GXbPkw0Nj1yK9o1ie5urcltCIk9FMAylJOl62LbF86HYHD2FFFLuYtGdHuliM6i2zBn M3YmBMMSTHPc46v7K4YoJHhLsMwwPfJhil4SudjB14Xr0IJOsIlLLOEyQlfmVGLgnYXO/9DE SEIVfyrg3Jm6n76ixJ1M7rIQVkMvKKn9NUUFlBWaqVH0JCPrRHmYWnMspPCp7YoImwUIda0i wo4cocY4JPhesJ96+HM/a4QD6GcM+NmzEDr4CVhjQuHFCwALpcxbciXHogdcAs2ELXgMruTH LUnGJGiM6QMKE7H8FmU4DJQx7edjMxUTooYsUNuoGc8XAauBaqcsfTDCvOX4O4+wHW6EhZJd 13iLtEkNJ7fFoIPoE8ljqylElWgIphzo4NooN8tRTrR/bZQzY32z2p8axspatH++nH0X7c9I hW68zooFzDeeBexkxsR+8XN6znOxINfg5YJ+0NFzKrp9yCNEHrC24ytNQm3X9oWlaehajSHz JRM9+s7U4RaB7MMjqpaiT61PPxUdME2s2Eq9UJYnggDfT/CCBboHQa249/Godz7qD87YIvoL 8uXw9z96wwHHUjC9mKaVKNPLUJlg+cydKW8Ao37V0a+cDopRSeIzVzGEzmYD7Z/aAGvDr4I2 yLuOLRMFe84ce2vruThbrtoDiQip9N6IXpxeOkA7cEO1dEOlGmrZ629nwLFOOOZ6XWRQl062 JA0o2wTzfs2DLOL/7Tfhn2Tj608XOE6EZDsxWkmKAHJl2ZONslR+KE7xJjnZqcCJjW/WzEk9 ixDxvwMMdCnzk/litpFxorFxrkPjRJpdw8NGmo5UaSPeVCMPfpRWeo7rb6iRb/k2fpEZNv6q IpjDh3TDv+QZz5RBklbPg2aPLZ+OjrW2G8rKGB1ZWqYYr2lOMRhmq92RRfmKGsmiApUucmAy LZfLqAH+7tnxmZzCM7o+ozYJLSDxMa8Nf67SBj1uQ14TqhDIZGqCQ40r/NquihpHjou32Bnl F/GxT9lqf2ZM3VrX/myDfiZoYWlrzfhxN8RPXDhmMmcVrT3YgpVl1Pyh/GLSutLNcJ219360 mTDaoBb9tmN+bX4rXSPMXMKFk9lmxqMjzqls3hvFOREnwWTasVB2pXc2FRWyZBuXqGVLfaBq qcY24anAdp7IR1F1VeEZhwjFVxgDexqcJi3Y/JSplFXkdVVuq/LbXJnfdfBcne8OxDfPW5lp py9yrhlrElNXRVwFUnjIXoKnvIroyHew1U74iaFzfxq6727oEqVWK+ow3TxaoJN0nKyilitQ l5vXh9Ut7saFpnxnsa1BcM3vJDjlBxDeWgTY+bYCrOqSBIErP4DgS/D+sGHPhu8xSUSmy0Ww Oop3b+DUieg7UkuqF5z3cDV2IALnPdYwjUu7sBFuf6CLlfbzAOjio1wAupio9nTvhig18ymV RwQtBpyYto9IX0f9WaJiIF0nnXS0Cq1SRu1dPSkpGM4NuHAwpYczClZSEbNzvFrmir6fjbJK aq/KtDdZDlZS3bU8fSfNk1fHVFb4IQaJDt1M/YeGfVH1J2l7gQq0A5SqSsd+pmaVoPyzPMq9 CCXlUo7xa3mMHYaRJk7k2TMY5V+NBGvpamAzQBy0/kwi0b8aiVBLYE5O04CQKdJ1vlDwLI3h haA6x9UkjjVdD7TghYkSdxXgUcvjycEVGprrhrqtbslBhGl3MqoIbfaCP1WXU+RlzSxihleJ u32AL8vTyuK2KXXapn6btq0avWxEHZR66qD971CHWm1Tvos6PFT1+ZCvo8WOcMoBCieZG7dW 8uMrO92U0OmyOyVaOq5LZ6gkC+6o64nRWfN5yUWCqhTdszroNCm6P+ug03O4a6C/BIzlZpfK 6Y0KhIotEirSSFE8WhDeadJAM8ecbiPPpw+wl4guHHZuIbLsyS4yl74zN31rwl4G4y0XC8el LyfwHYf2e3rzXKix5nTNcSegwXD4zOtwyUd09oieWuhUxspAhxER1KkTyraDGqYQAIv2MQ+P cMJaGlVJTVETTYkWqGnoxQEsW3lqom2jSLRg3ktV6Efo9xV6vlImU1NZxF6ClaWErgBoIF35 Bh1Px7v143R8kD5ANrxsMBlGCuDW258WYkUL8f9MU35alDKKEscu7Sh2OabvRz91PmEgbsko 1pzAlVQrPaNE81Rda7KaC5mgoFad25equiXZJgUBa1s5U32sLAPtj9RLT1RHLBdncJNUYYZL gMQHACYVOZMpHtVN8Ji3IrCu4BUV/fbbb8BZGOmTYCvIiXSRvZzNLP9zVl7hBgYdbUhA5e1P SniMsQm5nZrHojwZ+7LGx8wY0G6NiWzrSHEOO+fGY6ZF4avBJEWybIfc3Zo+mjo4fH9qfOwC mmPTJt0fvPeLVRt9h9oVklSZszvzs4d+S3cULXHw0PQQBzS2bugrTek1QZvKKk057z5HW/Ij iIGIbkLMbU1XbUuPrWbrL4ByQrJXXvzQznnzBjUjBbGik9AkxYjssSGlLXnWD7O6Xc6xdHYK lgQCFrsuLKMuO+ej5sbXtDfuf3ZH3e5IrIqV4Sx9mE34bAPa2B2TgfbpJezlP7dOvZiX1AlN HvZEWjHGN1ZGVbA9lWpPbPg5jovWR1UN0QOuEB+mu1EIR5mjf4V76AXPDhfOM+i3qTMBOW7Z /YPMWbGptVqhlNicExOOZM2W9BzkvJRNNNHkKjv5AvB+aZWxRAP/kJN+/VSYH1hhoMZaYEQj PYA5J22D1StHYSgr5J88Y4ceogyRfwUPxQnfXpTwcWkeOpk5d+Qqex9umfzvP+cLU0Ivtrer LXZYR1Jo/MwKf2aFP7PCDWeF5eaFxBUlwWxdDL3wXfFE4fhyakt19TiuIOkyp1N33VO95auh aSEQ19hkm7a1/aor2PKjVtrM/DpwOToAs3w1N1xJCHPhLL6NoOH6Lr3Cn9S0ujaDalpr9aHK XpAkk9ytOfNzJZd/lAZ9A2Gq6st7/mM8caZ0pyQ9lzCKAF6iHqG8DI5ZBAMAIDXeRvFb/9A1 sEnE3pdsGhGOuVllTiJ7HMpcOP0ltRmlY5CGSg8yEW2kLcYTpbeSyA9eFpTLAvSrzKN69Kie DlcZYLCxJ5qfYv9XoLgWPMFXUFIrPQ0RyVuU+OQzcT5fvyLgEJ60s5QTznn/iJDHhFwpRXb+ npqm76mv/5e0M61iwmTeJpXtm+iLNQ11Js/eZlZGhwXurHyp6eRiyvauGiVf0gNpoUeT1/AF 71eGDgMXrTKRyjPxoJmyC4+512VXJuMtx1XJnF4alcnMl7PcFV3ZcFMgedz/UJnk1PpUtWXd w4vq/TT2Kguwf1ZdgJZdmUz3Y3Uy5n1VMv2zo8pkLHtSlcxxrzqZKZ7U6Jt+Hp3EK62lg2rS qt5LZ713lcVnkwS2Ihn65vTKdOhBQHUI9WpRwpW7aVDderPwqaL1HgxH1c234/qVrdzxcT21 q+eS6tGq55dqDqeVnVM9ujU8FFX7esRqD7L65OqMtJo9WGq4ZUI7br/gBT0ZB3VJQj10fNPH VUO8i/f9k1F10xecZFR5VFFiw3rE3HrEujWpmauMrOGghkjp4UArEh3WIVpZsIf90eC8MqXw wLMafVjTcKyioitQrKunq5BcWVnrEV+HxtamXE9t65Grp7vHl/JRwp8jsKjrAlh2D20YL7T6 xuBdX56WCJvLF6v0MKPTzydk1aWUkUkrcYt5u6NKSKfLR86Zeyc5DUp2R1VXmNFg2Hudd1NO WNifU5kybVQ/r8X9TTa5n9vm/hobndGYdqIxsjXphdpyOvggT+j4xeu1uuVocHaRK3t+KWdt Ch8LSdzXpvGuN3otvyU3DukFKpUJn19KCZNbcsLpRS61pHqaK9H5aiPmNH9I1Md+1D163zs9 zZ6HErwUzXfQ1EG249/SWTyLvYAsfvkYJumoScijT9iVv7kuZzBWXS1UODL/dnouD//5ZUW1 erh7fDzM7WR+vr82hX4hiVX0NCeO5yfRq9tW8buE/v+Ud7W9beNI+PsB9x90C9ymzfoKy+7d pQ1awI7lVIBjZx2nSO+LodhyI5xteSW7mwLtfz9Sr6RMSUOJMSlcgC3WtkjNw2c4nCGHJF4u zn0/uRRd7hnkqhW+r+6wXSKV3LtueIHdXvvTXq/xCSXO1l6Sl+aBAuYvd1e9Ud79SXme7tDg K3A37c/vep8rlJoaWT8CUtCYmr2R+Z/yYkU0H5/9QtZVnDpgjj8jAQbm+G42vb/CX3HdK7vY r+d4v0VZ8gKZRfHqKMVkFOW2Zw4bu7pkLt6t7P3iqTzRJU4Upm7lZWVyktKg+IPKx3rNFmGJ MypsGOho5TDMkWVsC0gT+5Pj1cglzfiPVbaTXF7Y7h6X7RSXbReV7RaW1d8WlA1OYygo2ynA G+YX5ZdtE4qSLRueXVVeFu9uyJaNl+rDsukCfXE1afZZ9rY2SEWdsooW3zVQRd1SifAWKxES 4WlTIRKFgT2XRF3QESrpJpvcI1QCE3CHbO7VZGDM+19mxrHBpBMyMpmVZXY9qXswue+PDNgb OpXe8Pt9bwCr/22l+idXM1j1FyOOk8kKc3jZY0x4Ge48GcjK0zbSMa9ID9KBcDwZG++hzg6r AuQAGLO8lgpHvqBE8Nz89uqSZ5jG0nEQmBZEg/v1+MYYz+bD3v2R2werg76pq1IVt71ro7oA x04Kl48TpUfyv5fhKFfW6yJ/KszZPE7D9Gzf3sOcKpZqFbdK8PCxe7NYu4v/FvlV7O64y+Ti MvQ32qRU1DHZPt6OlSZ27IblPkZmezEfynqxu6P0MRTRnIv8C2sM/9VwiqLW831787i2vSBL d2b7exTQL1Bc75PPipXhr3+JEx+DZrD8zdzx50/283zpfHWQ5i2eLC/cHUBcJYT3C3z8oJ21 z+LLphf4/qSzd2d0Bmi48yy7RScubWVKr7hK9zKlh6Wlo2/SS0KOoCe453t3vj1sHm1PTAsQ Ps5C+0dYrE6bZOtDxX4LHNM6TZWttHdUaXkLLja7sMXOw+i+FX3w7BW+YCB6fHdgZOIeiHte DtTdnAdiD82fTw6+AuyVdh7UHwM7Ry/I3TATPfq3D9FjtDkmQaW/HKjr0YMKqG9QReQ+v+RV +AUf2DsQQkoiYdAzZ2/OgjxqWhzqCa3siTB4zN83FTbl4ZIJmfJpsxuTjrhOBwhM9M7yrE2G 6uQCCewSEh9xAnv6gbx4wiOvnUChH3mZUeRXMt3R+MzwIEpNleM8iHjJzzr9Gb+C+EypVKxQ RSoUs5bb3seKkqmh/Mjc2INlFyg47DPwX84ez94X/dzP+zm/zYkGZ/2xz9qn37osFmrAL1Qa WQFEY/1WJM8fxeL+zi9uHKa9gLBusbATfmHpTsYja/5Brj9JBUmMOMvY0V+2GF/iCD+2+/Eo 8DqvHxJXEXr4XDJkI8jrCb1O8J1OfafH+yRpI5DjIrFkyHTRnFGrtEKAuQhsGr5g6O1lzo8/ PpR4OPH7GBUwTvRmWrifudtvj4e9KYtn76ywAfPtKgcpeS3o6bXaCJf/+/GJBdwNJxZRrkoo gvZn0UZluvRPpgfSwWFasgUrvdoqOAUv8S8IjwJ19RzB8yFFfoMbHXGN68Bzi91heGRPp505 foZ4UqefZG6axTi6eTi6EExdsORdSh48gU/vt43bFImAX+fpeQKnCQkMqd1F+v+rdegIkp83 S+qztSc/Lr5zwkfwyEAhResuAj0KVwpCxBoZyaRPhkImM8bErS2sJzfL8Ek9asV8/gNwGv10 J6feYJ6ferLLYqcbsdMFMERk1NVkCVXVbCYCp5+WQO+wjo2C9gB6fyk7BHKJ/7daSZCLteKb zdgQ72VP0PSye6C97LZThCvzDW6/y7yoGh+S53oba/9e06ylp0WrkkEgt3b8+KYd9Jj9bOFc /Pdaco5JnIv0pq0Nh923uG0SVqzy6Bzs55DXSVtHQxj6imfkygvfE1c0K22eE3pBD7pZ3zKj +qgBP41m6ZQAPTcS6ckvOMnil5b264EN3o2d8ihZIys6egnOsSFne9jvwck2+e9B1Vhrx/Kx Zmg4Y+7N9rB+s9W8dst7bnnfM7OkROAfNs5v2gHVHdqPX4MDeoJDFILTGYJw/jIHExae/i06 Gy441E3XsyXRr8mxKJcMqSLT2KZ6bmZuJr+B5s4K4c5vJpngS6w/D8a1/ygfY/dlMW5UwNh5 WYxbZZUV3lPrwFdWj08DX1kVrws/GdriFEzSQ8tvlzgd82SNEovHAnjsP4K4jTEsZYIg+Ltg 05eLjqBucmuMZ9MvUO7cnb3de9+VIC/1ItqlumlCKXVODs0soK5dTS+dpVQUqWZevH4BcL4i 4N69BLilryJ1VUFThgZuY07YBJPbqqYF72cqj+hwmKZgRIeFVyOiC3d+nTSi4wIvwheMMJ7S E87F2P0/wNh5WYxbZZX1ZUOaGL6yenwa+BtVVVxoRIe3u8IjunC6+aSuCxaQ0TR4vQI1zYXG aJpwdYFef6DKBiux8eof2HELwOtqgNelgO+oAb4jBXxXDfBdseCPjMEDnzV4lmAOHtSxB88S DMKDOhbhWYJJeFDHJjxLMAoPJ7UK18ashf8xW9rt/Sz4xyyPhr/a+5O1y7UxEzjli0/YOKXo Zg5f8W7aOI9ilMPcr9jwEflMIyjQ3eF0FCGlEUgRPovklKK/IEXU4HvT0sLTTCDWZ3NSu3Mj OMQKj2U5GYSwWevFSRBSXhLQcaKf26I4akUbPNoj+r8qi162Ekj0UiQUQ6C1H+dUyNJUvww6 kyQqSOOrwpBjqwNEzweSEBR0QZBZkKZ6gYiielEARREsHP0oPGIOBE5uTwoFrd2VQiS2QlAg nSk4dBFiJVZS7fhQ5JC0stXAwjsogXhyVvKt+VDMuLSyFYICHpmGIEOxkmvPh0IHp5WtCBru 4QlGluQ+FYkqaIRa2SqBgXSr6OjMMngLa/Fkb04XCkZiVUqjS7BBL5NKz3pEhXqDQfnEmbWU F0QiAVkGpkp8j2D4quDQ6+FYqMSHXhGHr4he6TX1yldFsfSaiuWroll6qWalg+99X8MnEJRb Mf/wKM+3uO+LsmIIhq8KDr0ejoVKfFS2YoroVW0rpopi1bZiqmgWhxW7uR8BsnlfNvGvEBYS UJQBQzB8VXDo9XA8qcRHZQOmiF7VNmCqKFZtA6aKZnEYsIH5udyALZ1v0mAhAUUZMATDVwWH Xg/HRiU+KhswRfSqtgFTRbFqGzBVNAtuwKhZtI42Cc4cttZ8M2kmaCpN7hIlFrP+9K9SMEDr Kfd9EzRFIHkBGYlZnx2lYEDYwZcrg+IfubCwmPXZUQoGhB18oj/IuZMLC4tZnx2lYID6zmQA 2Qgsb6YdCShs6sCVONGewVEvwlODj/ohtyKElHusZH8xQR1GspGeiPDTlIIBsWbIr0POA8iP ljnvHoopbElHKTTlRiFhyxxflVPlbOXNxiMBhZGkCA4OegYGgJ6lLQ8WElAYPYrg4KBnbFyX 07O1v0qDhQQURo8iODjoubq5BSzKoQ/yVk+wiMIYUgYJJ0cGjCRbKjZDKE2KYOEkyoQRJddh DQSt73grBgSUG4upBXJky8dmCGJJKSigEKl/B4iPJObyIAHFRUZq4OCwdDe9B8D0gvUsb9qk 9yCMHkVw8NBjjgH0OFt5sMyxOHrUwMHXe0xQ95E8rYXEFDA7pxIM0FqDOTZBvUcyLCSmAHZU ggFa455MZ4A1btfby8uORSIKs27KIOGwb3efzOEMMK3gPzmrvbxwPBRTHFMqoeFlawpky5OL byqWLVXQcLPVg9JlSUbYE0yYMng4KJtOIMbQcyUaDyyiMKaUQcLH0RTEkScT2VQkR2og4XYr TKhfITk7MBRWQJ6jemBAfnpgLqFkeQrgm4oiSy0wcLJ6YLYsFRD2hPGlGBwIY3iYM2FOhVxw gaD1iVIMCJCiKYwiTzqyqRiKVAICoah/ZwAmkx59W94UTN+cTW6Bbl/m9pK29vEjebNzOYXq INXrIk05vhoBPPvHxdprIsc6P8fKINXrIiU4/nQN4fjpaxM57lTgWBWkel2kKcezO4it3vuN tNVdfo6VQarXRUqNxyZsQJbraQT4S30mIeOxSkD1ykCp4diEjccNpLjacNxAistGYxM2HDeQ 4mqjcQMpLhuMTdho3ECKqw3GDaS4aCy+G9zfAuYDl4ed3MkzJGbW5So8GPzaBOwXWrtfncWb NvqTePQ5krRO4N9m6W8p4PRONe3Hj7T23BTcLd7jG/1F5ZrUVHp+UxU3lN5IzehUhqs3EW63 Ily9mf3+bWW4jWT3n5XNnE70XpCZe3a9Rpu5f9VoKs4RgWypJjbVv6s2lU56C6Cm2jZcqy6q 2Ru93Ux78666ZujcmrFvtGb0qmpGM/2MfkW4DfUzrirDbSS7g8r9ntvP2FLxVBN7vlFVN5rZ 84fHcJO5hsm09Do/15N9KyZCXm0dA2PGKJfOamV79nav7VzfwQeHapaPZNUenb27cxhbe8fl 94WibtDAhtHrNcwDQGGeG6kxndoaM4aozLaBTdOt1TTUTObat77ZMfRE4o2NMB/28z8O1vLx +95+pe0ikUfmbDYy5gbqj71xSzu3WlgwLCd6w/8AUEsDBBQAAgAIAFstRSo2FK+HhQEAAKYE AAAQAAAAd29yay9GQ1BVL2ZjcHUuaH1UW2+CMBR+X+J/OIkvmyFxXmaW+MQUlYQhUTS7ZCFY CmsGlEA1c8v++4pWQUbXkPTkuxxOOYc2iR972AfHcSYja+XMeNC4anKIxLiCFjhFbLNnGLiA xGzQL5jkRIm9dWGL8dG2jTMSxNgD9O6mZbMQiP3CfChEexpplq3PTcecmxpU160h1S+0pWZX 9R25XjX0qfmombYzUVeGcHbl+rG+1pc8eHh+0RZzkb8n11vqVCtlPq6+XK+ba17SWDeX9mI1 yiGuv5PrZ6rx57gwMPIvyvYJznuesXSLGBxazB/4blzlolMHUxy8wqAPb8NLnMTc6CQsrcW5 qxanCaIerrd06uFuPdyrhUkU3cuIzqCWCWlAk1rGD4OMfJ2rFVNZcC6TUWgvNfGJl3ER9eS2 SMptCCsOIEj8iXDCCM3f9QOitQq0LBEO8wnYUeKBj5Itb1eG2TWcWEjgpqJAIUUf/yrcLCrz yuGvbkHIp1IpXQil2FXO9fph5u6wyNnEsUd8aLcrN88vUEsBAhQAFAACAAgAMTBFKmbhuVOw AwAAdQ0AABMAAAAAAAAAAQAgALaBAAAAAHdvcmsvRkNQVS9mY3B1ZGJnLmNQSwECFAAUAAIA CAB1MEUqzUdgGBcnAABicQEAEAAAAAAAAAABACAAtoHhAwAAd29yay9GQ1BVL2ZjcHUuY1BL AQIUABQAAgAIAFstRSo2FK+HhQEAAKYEAAAQAAAAAAAAAAEAIAC2gSYrAAB3b3JrL0ZDUFUv ZmNwdS5oUEsFBgAAAAADAAMAvQAAANksAAAAAA== --part1_68.bc68e9d.27b03abb_boundary-- From Mon Feb 5 18:47:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01083 for ; Wed, 7 Feb 2001 00:53:07 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:07 +0100 (MET) Received: (qmail 17091 invoked by uid 0); 5 Feb 2001 17:43:29 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx22) with SMTP; 5 Feb 2001 17:43:29 -0000 X-eGroups-Return: sentto-1101623-2260-981394888-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 05 Feb 2001 17:41:32 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 17:41:28 -0000 Received: (qmail 54303 invoked from network); 5 Feb 2001 17:41:27 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 5 Feb 2001 17:41:27 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 5 Feb 2001 17:41:27 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id AC47E45225 for ; Mon, 5 Feb 2001 12:47:03 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 12:47:03 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CPU capable of solving simple equations. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7ec2254fe1c10ff30f730797c27df423 Status: R X-Status: N

On Mon, 5 Feb 2001 polz@writeme.com wrote:

>
> > The idea is that rather than constantly feeding the cpu instructions, you
> > feed it facts, goals, and a vector to call when it gets an answer.
> The only way this could reduce the needed bandwidth would be to have complex
> descriptions of your goals and facts. This would make the CPU much more
> complicated (and probably slower).
>
> I also don't know how you intend to implement pipelines and parallel execution
> in a design like this. I therefore think it would be much better to concentrate
> on completing an FC0 before doing something as radical as a PROLOG processor.
>
> Prove me wrong!

Will do

> (re-lurk)
>
>
>
>
>


Yahoo! Groups Sponsor
www. .com 
From Yann GUIDON Mon Feb 5 19:21:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01095 for ; Wed, 7 Feb 2001 00:53:11 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:11 +0100 (MET) Received: (qmail 31554 invoked by uid 0); 5 Feb 2001 18:28:39 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx04) with SMTP; 5 Feb 2001 18:28:39 -0000 X-eGroups-Return: sentto-1101623-2261-981397668-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 05 Feb 2001 18:27:53 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 18:27:48 -0000 Received: (qmail 21472 invoked from network); 5 Feb 2001 18:27:47 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 Feb 2001 18:27:47 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 5 Feb 2001 19:28:51 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA16081; Mon, 5 Feb 2001 10:27:42 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWQRH; Mon, 5 Feb 2001 18:32:38 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7EEF1B.5DC8F4E7@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <68.bc68e9d.27b03abb@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 19:21:15 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b084e016d36b44042bc47dae35ec128c Status: R X-Status: N hi !

Carsten899@aol.com wrote:
> hi,
>
> i think the ftp isnt accessible for anonymous persons, so i=B4ll zip t= he code
> and attach to this mail. (i will also setup a homepage at
> http:\\members.aol.com\carsten899\f-cpu).

i had figured it out alone when i made http://www.f-cpu.de/emu/ :-)

> >>is it under GPL ?
>
> i have to include appropiate headers. It will be under GPL.

ok :-)

> >>simply about the goal of an emulator :
> >>it should ease the development of SW, incl. the kernel.
> >>how do you simulate a whole system (not only a user task) ? >
> first i thought about thousands of lines of code emulating scsi-, uart= -,
> pci-bridges and so on in software at the I/O level, but this isnt nece= ssary

no that's not what i meant. it was about : managing the protection from a user and the kernel, manage the pages/TLB etc... you're not forced to
simulate SRB but at least a trap or an IRQ...

> My idea is as follows:
>
> * Include the Virtual-FCPU in the linux kernel of your host system. > * Include an appropriate linux kernel compiled for FCPU in the kernel.=
> * Right at the start of the host system kernel_init() (dont know the e= xact
> name
> of the linux function) let the Virtual FCPU start working:
>
> fcpu_reset();
> while( 1L )
>    fcpu_clock() // execute fcpu instructions.
>
> * "Map" host system I/O into FCPU memory space:
>
> void fcpu_mem_put_quadword( int64 address, int data )
> {
>    if( FCPU_IOBASE_IDE_CONTROLLER =3D=3D address )
>      *HOSTCPU_IOBASE_IDE_CONTROLL =3D data; >
>   //....
> }
>
> Now the Virtual FCPU executes a kernel dealing with physical I/O on th= e host
> machine. Okay - there are open issues, like interrupts, speed. but i t= hink
> all will be solvable.

i'm not sure to understand completely, but it looks as an interesting hack,=
except that i don't know how to do it :-) especially for the first line : "* Include the Virtual-FCPU in the linux kernel of your host system.&q= uot;
to my great shame i have never recompiled my kernel... I have enough troubl= es
with GCC :-)

> Best Regards

YG

speaking for himself
Yahoo! Groups Spons= or
3D""3D""
= www.
3D""
From Carsten899@aol.com Mon Feb 5 20:35:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01104 for ; Wed, 7 Feb 2001 00:53:14 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:14 +0100 (MET) Received: (qmail 23887 invoked by uid 0); 5 Feb 2001 19:36:13 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx09) with SMTP; 5 Feb 2001 19:36:13 -0000 X-eGroups-Return: sentto-1101623-2262-981401750-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 05 Feb 2001 19:35:58 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 19:35:50 -0000 Received: (qmail 90420 invoked from network); 5 Feb 2001 19:35:49 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 5 Feb 2001 19:35:49 -0000 Received: from unknown (HELO imo-r13.mx.aol.com) (152.163.225.67) by mta2 with SMTP; 5 Feb 2001 19:35:49 -0000 Received: from Carsten899@aol.com by imo-r13.mx.aol.com (mail_out_v29.5.) id r.23.70478ef (1883) for ; Mon, 5 Feb 2001 14:35:29 -0500 (EST) Message-ID: <23.70478ef.27b05a81@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 14:35:29 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4ba6353798ba3f90f686563181469ed4 Status: R X-Status: N >>you're not forced to simulate SRB but at least a trap or an IRQ...

Yes. The emulator has to. but where is the problem? IRQ is just setting the
PC (where? It must be this mysterious SRB mechanism which handles this???) to
a new address. The problem of catching the interrupt is, that the emulator
has to enable and catch all interrupts on the host system (see below).

In the case of pagefaults i dont see any problem too:

All memory access of the emulator is going through one function (actually
this called: fcpu_mem_put_byte( adress, data ) ). thats the point where the
protection will be implemented ( although its aweful slow! ). For example:

fcpu_mem_put_byte( address, data )
{
  foundValidEntry = 0xFFFFFFFF; // means: no valid entry.
  for( i = 0; i < NumOfTLBEntries; i++ )
  {
     // Search all entries of the TLB.
     // .lin_mem_area_base is the linear address
    // .lin_mem_area_end is the linear end.
    if( ( address >= TLBEntry[i].lin_mem_area_base ) &&
         ( address <= TLBEntry.lin_mem_area_end ) )
        foundValidEntry = i;
  }

  if( 0xFFFFFFFF == foundValidEntry )
  {
     // pagefault. memory area accessed is not inside actually mapped pages.
    fcpu->exception = FCPU_EXCEPTION_PAGEFAULT;
  }

  // okay. validEntry found. now map the linear address into physical address
space. The physical address is used as offset to the memory array. mem[].

   mem[ TLBEntry[ foundValidEntry ].physbase + ( address - TLBEntry[
foundValidEntry ].lin_mem_area_base ) ] = data;
}

>>"* Include the Virtual-FCPU in the linux kernel of your host system."
>>to my great shame i have never recompiled my kernel... I have
>>enough troubles with GCC :-)

i did never compile it too - i didnt ever install it :-)))), but i had a look
at the sourceode startupcode a few weeks ago it and have colleagues who are
working on linux kernel, so i can ask them something about it.

At all: i dont think you even need the kernel. perhaps you just need the
loader, which loads the Virtual-FCPU and the Linux-FCPU kernel.

Okay - There are some assumptions. For example on X86 PC i assume, that the
processor is in protected mode and has setup descriptor tables for 4GB of
linear memory. All I/O is unprotected. And all interrupt vectors are pointing
to a service handle inside the FCPU emulator. This is necessary
initialization for the FCPU emulator.

*************************************************************************
Perhaps some linux expert is reading and can comment on this.
*************************************************************************

At all, you dont need to think of a linux kernel, just think of plain old DOS
(leaving the real mode of X86 and the 640k limit beside).  Imagine the
Virtual-FCPU running on DOS. There is no protection of any I/O. The
Virtual-FCPU may write everywhere. It may access I/O of RS232 directly, it
may access hard disc controller I/O directly, just as any good old DOS
application could do.

Best Regards,
Carsten
Yahoo! Groups Sponsor
www.
From Yann GUIDON Mon Feb 5 21:35:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01148 for ; Wed, 7 Feb 2001 00:53:25 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:25 +0100 (MET) Received: (qmail 5867 invoked by uid 0); 5 Feb 2001 20:42:24 -0000 Received: from ej.egroups.com (64.211.240.230) by 10.1.4.111 (mx11) with SMTP; 5 Feb 2001 20:42:24 -0000 X-eGroups-Return: sentto-1101623-2263-981405737-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 05 Feb 2001 20:42:22 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 20:42:14 -0000 Received: (qmail 97986 invoked from network); 5 Feb 2001 20:42:13 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 5 Feb 2001 20:42:13 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 5 Feb 2001 20:42:12 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA04883; Mon, 5 Feb 2001 12:42:08 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWQ4A; Mon, 5 Feb 2001 20:47:05 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A7F0E9D.FCBAF6C0@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <23.70478ef.27b05a81@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 21:35:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a99ffc564c67b23ff03b70c7f370d619 Status: R X-Status: N hi !

i was compiling something and had started to read the sources you made :-)
i have a lot remarks on details but nothing severe :-) it may be
the subject of another mail.

Carsten899@aol.com wrote:
> >>you're not forced to simulate SRB but at least a trap or an IRQ...
> Yes. The emulator has to. but where is the problem? IRQ is just setting the
> PC (where? It must be this mysterious SRB mechanism which handles this???) to
> a new address.

IRQ/TRAP/FAULT/SYSCALL/whatever is "pointing the PC to somewhere else"
and saving the PC or PC+4 (depending on the case) to the CMB.
SRB is only a way to avoid to write the backup code (writing 64
registers takes 256 bytes of instructions and 512B of data...).
The jump address is another story i've told previously.
the vhdl file contained some of the major SR, like SR_TRAP etc.
They contain the size and base address of the jump tables
(warning : it is a binary OR on the pointer so if you have 1KB of
code in the table, the base pointer must be aligned on a 1KB boundary !)
The jump address is "SR_something_BASE | (vector << 6)"
and "vector" must be checked for inferiority with SR_something_SIZE
(there's a major trouble if this happens).

> The problem of catching the interrupt is, that the emulator
> has to enable and catch all interrupts on the host system (see below).

not necessarily as of today...
the goal of developping the kernel requires that we can singlestep
the trap handlers etc... now if you want to make the equivalent
of a VMware, have fun but let's have something work first :-)

> In the case of pagefaults i dont see any problem too:
if so, it's fine :-)

> All memory access of the emulator is going through one function (actually
> this called: fcpu_mem_put_byte( adress, data ) ). thats the point where the
> protection will be implemented ( although its aweful slow! ). For example:
>
> fcpu_mem_put_byte( address, data )
> {
>   foundValidEntry = 0xFFFFFFFF; // means: no valid entry.
>   for( i = 0; i < NumOfTLBEntries; i++ )
>   {
>      // Search all entries of the TLB.
>      // .lin_mem_area_base is the linear address
>     // .lin_mem_area_end is the linear end.
>     if( ( address >= TLBEntry[i].lin_mem_area_base ) &&
>          ( address <= TLBEntry.lin_mem_area_end ) )
hmmm that's not exactly how i'd write it but i'm such an optimisation freak ;-)

>         foundValidEntry = i;
>   }
>
>   if( 0xFFFFFFFF == foundValidEntry )
>   {
>      // pagefault. memory area accessed is not inside actually mapped pages.
>     fcpu->exception = FCPU_EXCEPTION_PAGEFAULT;
>   }
>
>   // okay. validEntry found. now map the linear address into physical address
> space. The physical address is used as offset to the memory array. mem[].
>
>    mem[ TLBEntry[ foundValidEntry ].physbase + ( address - TLBEntry[
> foundValidEntry ].lin_mem_area_base ) ] = data;
> }

mmm i'll try to recode this (warning !!! not tested)
#define LOG_TBL_ENTRY_NUMBER 5  /* this differs from FC0 */
#define TBL_ENTRY_NUMBER  (1<<LOG_TBL_ENTRY_NUMBER)
typedef struct TLB_entry {
  u64 log_addr;
  u64 phy_addr;
  u64 hit_counter;             /* incremented whenever the address matches. */
  unsigned int valid_entry:1,  /* updated when there's a task switch and with VMID */
               VMID:2,         /* not directly used ... */
               LRU:LOG_TBL_ENTRY_NUMBER,
               access_right:2, /* r=0, w=1, rw=2, x=3*/
               cachable:1;     /* if 0, don't seek in the cache */
  int page_size;               /*  */
} TLB[TBL_ENTRY_NUMBER];
/* the TLB should be initialised with the right page_size : 1/4 of the
entries contain 12, 15, 18, 21 (4K, 32K, 256K and 2M)  */

check_tlb:
  i=0;
  do {
    addr_log2=addr_log ^ TLB[i].log_addr;
    if ((addr_phys2 >> TLB[i].page_size)==0) {

      page_hit !

      TLB[i].hit_counter++;
      mask = (-1UL)<<TLB[i].page_size;
      phys_addr= (mask & TLB[i].phy_addr) | (~mask & addr_log);

/* update the LRU here */

      goto ok;
    }

    i++;
  } while (i<TBL_ENTRY_NUMBER);

>      // pagefault. memory area accessed is not inside actually mapped pages.
>     fcpu->exception = FCPU_EXCEPTION_PAGEFAULT;

ok:


I agree that it's a very very descriptive, very close to the VHDL high-level
description.


> >>"* Include the Virtual-FCPU in the linux kernel of your host system."
> >>to my great shame i have never recompiled my kernel... I have
> >>enough troubles with GCC :-)
>
> i did never compile it too - i didnt ever install it :-)))), but i had a look
> at the sourceode startupcode a few weeks ago it and have colleagues who are
> working on linux kernel, so i can ask them something about it.
>
> At all: i dont think you even need the kernel. perhaps you just need the
> loader, which loads the Virtual-FCPU and the Linux-FCPU kernel.

in fact all i want is to emulate the CPU, the rest is more difficult
because there is no reference platform yet. it would be sad to tie the
F-CPU to the PC platform because "it's what we have". At least we need
a POSIX compliant interface, that's all.

> Okay - There are some assumptions. For example on X86 PC i assume, that the
> processor is in protected mode and has setup descriptor tables for 4GB of
> linear memory. All I/O is unprotected. And all interrupt vectors are pointing
> to a service handle inside the FCPU emulator. This is necessary
> initialization for the FCPU emulator.

if you want to substitute the F-CPU to a PC, it's going to be a REAL PAIN.
however you can interface the CPU with the help of SYSCALL. it will bring
you access to POSIX stuffs done in C by the x86.

> *************************************************************************
> Perhaps some linux expert is reading and can comment on this.
> *************************************************************************
>
> At all, you dont need to think of a linux kernel, just think of plain old DOS
> (leaving the real mode of X86 and the 640k limit beside).  Imagine the
> Virtual-FCPU running on DOS. There is no protection of any I/O. The
> Virtual-FCPU may write everywhere. It may access I/O of RS232 directly, it
> may access hard disc controller I/O directly, just as any good old DOS
> application could do.

very, very utopic :-) i've done enough x86 low level hardware hack.
i know it's a dead end. however a simple syscall can plug the F-world to a printf
on the console and you can simulate a video framebuffer at a certain address.
the rest is best done with SYSCALL.

ok i have to read Hans' proposal more seriously.
read you tomorrow,

> Best Regards,
> Carsten

YG

speaking for himself
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Mon Feb 5 22:43:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01160 for ; Wed, 7 Feb 2001 00:53:29 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:29 +0100 (MET) Received: (qmail 11597 invoked by uid 0); 5 Feb 2001 21:35:01 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx22) with SMTP; 5 Feb 2001 21:35:01 -0000 X-eGroups-Return: sentto-1101623-2264-981408842-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 05 Feb 2001 21:34:35 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 21:34:02 -0000 Received: (qmail 7715 invoked from network); 5 Feb 2001 21:33:27 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 5 Feb 2001 21:33:27 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 5 Feb 2001 21:33:26 -0000 Received: from ifrance.com (nas22-10.vlt.club-internet.fr [195.36.172.10]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA26597 for ; Mon, 5 Feb 2001 22:33:23 +0100 (MET) Message-ID: <3A7F1E76.33AFB582@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> <20010205000316.29241@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 22:43:18 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2088e4baa41886add49698810564e13a Status: R X-Status: N Hello,

Michael Riepe a =E9crit :
>
> On Sun, Feb 04, 2001 at 01:07:04PM -0500, Carsten899@aol.com wrote: > [...]
> > As i had a lot of time this weekend i already did a lot of coding= - not
> > testing :-) - of the "instruction level emulator". It h= as about 80% of the
> > instructions implemented. Also implemented is a simple assembler = which uses
> > the instruction code syntax from the manual. I did some assumptio= ns on
> > non-defined topics ( Syntax of JMPA and MOVE - Instruction )
>
> Well... where's the source? ;)
>
?? ;p
> > The sourcecode should be endian independent, but needs an compile= r with an
> > native signed 64 Bit datatype ( like __int64 on msvc ).
>
> No problem with gcc (use `long long' on intel boxen).
>
long long is for gcc, no ?
I think that compaq use 64 bits for long (and for pointers).
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
nicO
Yahoo! Groups Spons= or
3D""
3D""
From Roger Dingledine Mon Feb 5 23:01:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01163 for ; Wed, 7 Feb 2001 00:53:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:30 +0100 (MET) Received: (qmail 17060 invoked by uid 0); 5 Feb 2001 22:02:52 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx14) with SMTP; 5 Feb 2001 22:02:52 -0000 X-eGroups-Return: sentto-1101623-2265-981410481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 05 Feb 2001 22:01:29 -0000 X-Sender: arma@belegost.mit.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 22:01:20 -0000 Received: (qmail 49052 invoked from network); 5 Feb 2001 22:01:03 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 5 Feb 2001 22:01:03 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 5 Feb 2001 22:01:02 -0000 Received: (from arma@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA01042; Mon, 5 Feb 2001 17:01:01 -0500 To: f-cpu@yahoogroups.com Cc: seul@seul.org Message-ID: <20010205170101.J958@belegost.mit.edu> References: <200101301037.f0UAbcH01175@PrintServer.LedCom> <3A76B6B2.88756D66@mentor.com> X-Mailer: Mutt 1.0.1i In-Reply-To: <3A76B6B2.88756D66@mentor.com>; from yann_guidon@mentorg.com on Tue, Jan 30, 2001 at 01:42:26PM +0100 From: Roger Dingledine MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 17:01:01 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 596e709de50f526bd0e57df2c171ae30 Status: R X-Status: N Sorry for the delay in responding here; we've been at LinuxWorldExpo in
NYC for the week.

On Tue, Jan 30, 2001 at 01:42:26PM +0100, Yann GUIDON wrote:
> Anyway, nothing keeps us from using sourceforge as a second "backup" repository.

As was said earlier, I think you want to avoid having multiple cvs
repositories. Pick one and plan to stick with it.

> But the experience with egroups tells me not to trust 100% a private company.

Yep. We're entirely non-commercial non-corporate.

> > >CVS at seul is interesting but we need somebody who watches over it.
> > >I don't remember who proposed/volunteered but it was not followed by acts.
> > >If someone else wants to manage the CVS tree, don't hesitate !
> >   Anywhere it is (sourceforge or seul.org), I'm ready to try to
> > do it.  I'm not a CVS guru at all, but I should be able to do
> > it.  Just give me the name of the person to contact.
> His name is Roger Dingledine but i don't have his address at work.
> I think that the managers can be reached at seul@seul.org.
> Ask them to open an account for you in the F-CPU project,
> give your email address and your wanted login name.

Yep. Let YG know if you need an account on one of the seul servers,
and he'll bounce that to me if he's ok with it.

As for just maintaining the cvs repository, we would presumably set
it up with pserver, so you simply need a cvs account, not a full-blown
shell account.

I notice that we haven't set up an f-cpu module in the cvs repository
yet. I believe we are blocking on "somebody at f-cpu telling us to".

Let me know,
--Roger
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Mon Feb 5 23:22:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01166 for ; Wed, 7 Feb 2001 00:53:31 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:31 +0100 (MET) Received: (qmail 30032 invoked by uid 0); 5 Feb 2001 22:13:11 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx02) with SMTP; 5 Feb 2001 22:13:11 -0000 X-eGroups-Return: sentto-1101623-2266-981411166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 05 Feb 2001 22:12:55 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 22:12:46 -0000 Received: (qmail 24048 invoked from network); 5 Feb 2001 22:12:44 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 5 Feb 2001 22:12:44 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 5 Feb 2001 22:12:44 -0000 Received: from ifrance.com (nas22-10.vlt.club-internet.fr [195.36.172.10]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA21244 for ; Mon, 5 Feb 2001 23:12:40 +0100 (MET) Message-ID: <3A7F27AA.7AD574A1@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <3A7D7606.FF8AFAC@ifrance.com> <3A7DED53.9D0B5FF0@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 23:22:34 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e3dbc81945455adefc51582f8e37e6c6 Status: R X-Status: N

Yann Guidon a =E9crit :
>
> hello,
> quick&dirty answers,
>
> Nicolas Boulay wrote:
> > Yann Guidon a =E9crit :
> > > Marco Al wrote:
> > > > From: "Ben Franchuk" <bfranchuk@jetnet.ab.= ca>
> > > > > > Of course ! But I don't understand "bina= ry translation".
> > > > > What ever happened to the idea of "Generic Op= codes" that you would compile
> > > > > a program and the loader would translate this to r= eal opcodes?
> > > > Thats what I meant, sorta.
> > > as long as it's "only" about a lookup table, it's = ok.
> > > however, the latency/scheduling issue is more difficult to s= olve.
> > In Pentuim, all the unit have the same pipelined unit.
>
> ???
> could you be more precise ?
> and what's the point ?
>
Latency and scheduling is much more difficult in fcpu because you have
different latency units. For pentuim is easier, each unit are equal.

> > > > As long as wrong code sequences cant harm the processor= and not compromise
> > > > security the single biggest problem with exposing pipel= ine latency is that they
> > > > make backward compatibility complex.
> > > and that's a big issue because it's our #1 goal.
> > > what's the point of having a very efficient CPU if the binar= ies can't be reuse elsewhere ???
> > That's a very strong point. But when you see intel problem with I= A64
> > (they said that you will have to recompile your program for the n= ext
> > generation),
> you forget the last part of their declaration : "if you want to r= un at full speed".
> my goal is to maintain a relatively decent performance on as wide a ra= nge
> of applications as possible, with a minimal amount of rewriting.
>

Look at what is written on emulator.com, the guy said that optimising
PIII code could run 50% faster. There is no optimised PIII compiler. So
to speed up code, recompiling is the best (+50 % for PIII !!).

Imagine you use the rules :
- interlaced instructions of differents units (with or without vliw
bit).

So you could (with a lot of decoder) try to launch as many instruction
as possible (vliw bit avoid to compare each Read After Write
dependancies, i believe that PowerPc use more than 3000 5 bits
comparator to do it...).

You optimise your code and use it. Then you add to your core some units
(1 add and one 1 mul, for example). Your code could speed up but a C
compiler could unroll more loops to speed up even more the execution. So to really increase speed, you must recompile.

> > we can't try to use the popularity of opensoftware and the
> > openess of the source code. Maybe an standard install will be a > > /configure and not rpm-something ;p
> ? i don't understand...
>

Easy : the standart way to put a program on a fcpu will be to recompile
it each time. (specific architecture SR could write the size of the
register, of the cache memory, the number of each unit,... and the
compiler could read them). So no need of (strong) binary compatibility.

> > So maybe a total binary compatibility isn't so interresting to ha= ve.
> total is impossible. But i mentioned a "minimal" compatibili= ty.

You could make a total compatibility, but it's possible not to increase
the speed (for the same clock speed). Imagine that your core (fc1) has 3 adds units and 2 muls. If you use it without ooo, no speed up will
occure (for the same clock speed). But after a recompiling, you could
gain around 200 % speed up. If you try to produice code for fc0 as big
as for fc1, your code footprint will be much bigger, without any speed
improvement (for fc0).

For closed source program, maybe we can use intermediat code (could RTL
in gcc, no ?)

> the F-CPU ISA has "core" instructions. however the schedulin= g was not the issue
> because the strict rules of dependency that we find in usual code
> (instructions are executed in order etc) is preserved.
> a scheme with "lost values" (like the example of the C6x) wo= uld
> be a catastrophe.

Yes, but maybe "class" of unit could defined latencies. (2 or 3 t= ypes
with a fixed rules). If you want different depth pipelined unit, how
would you keep the coherency ?

If you have in fcn, 3 types of unit (1 clock latency (ex add), 3 (mul)
and 8 (fmul)).
then in fc(n+1), your 3 types reach 2,7, and 20,  how would you manage=
it ?

I repeat myself but with recompiling (C/C++ or GNL ;p ) no problem !!!
(and don't forget that with java, you only recompile the JVM)

>
> > > if it's HW, it's the best solution for me. there is no compa= tibility and
> > Best solution ? Translation is always translation, HW or SW you h= ave the
> > same thing to do. But HW is much more complicated to write !
> not really...
> it depends on the extent of the translation.
>
> until now, there were 2 issues : the change in the opcode value,
> and the pipeline latency/instruction packing. there's nothing worth > a big change now. translation exists for CISC machines, whereas RISC > doesn't need much change.
>

It's always easier in SW !

> > > > Marco
> > > WHYGEE
> > nicO
> WHYGEE
nicO
Yahoo! Groups Spons= or
3D"Click
3D""
From Michael Riepe Mon Feb 5 19:39:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01172 for ; Wed, 7 Feb 2001 00:53:33 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:33 +0100 (MET) Received: (qmail 12573 invoked by uid 0); 5 Feb 2001 23:35:12 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx16) with SMTP; 5 Feb 2001 23:35:12 -0000 X-eGroups-Return: sentto-1101623-2267-981416100-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 05 Feb 2001 23:35:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 23:34:59 -0000 Received: (qmail 9061 invoked from network); 5 Feb 2001 23:34:58 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 5 Feb 2001 23:34:58 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.67) by mta2 with SMTP; 5 Feb 2001 23:34:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00481; Mon, 5 Feb 2001 19:39:39 +0100 Message-ID: <20010205193939.47886@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com>; from Hans Summers on Mon, Feb 05, 2001 at 09:32:41AM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 19:39:39 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8549a7a13e2526d1497efceeada90c20 Status: R X-Status: N On Mon, Feb 05, 2001 at 09:32:41AM -0000, Hans Summers wrote:
[...]
> 2.2      DECODER AND INSTRUCTION ISSUE
>
> The decoder becomes much more simple, it can probably be done in one cycle.
> I abandon the FIFO completion queues altogether (I'll speak about completion
> conflicts later). The decoder simply checks to see if the execution unit,
> source and destination registers applicable to the instruction are
> available. If they are, the instruction is issued to the appropriate
> execution unit on the next clock pulse, and the scoreboard "computing" bit
> of the destination register is set to indicate to subsequent instructions
> that the register is unavailable as a source register.
>
> This scheme is easily extensible. The instruction decode is so much simpler
> that it will be easy to construct multiple decoders and issue more than one
> instruction per cycle in future.

What about bypassing results from one EU to another?

[...]
> 2.3      EXECUTION UNIT PIPELINE
>
> Crucial to this design is that each execution unit should have its own
> destination register pipeline. These replace the original scheduler FIFO's.
> Each pipelined execution unit has a 6-bit destination register input. The
> destination value gets loaded into this input when the instruction is
> issued. That destination value moves along the execution unit pipeline to
> the output of the execution unit. However many cycles later when the
> execution unit completes, the destination register number appears at the
> output along with the result of the computation carried out by that
> execution unit.

I've been playing with a similar idea (with a generic `transaction id'
instead of a register number).  The only problem was that operations
could not be chained that way, but that seems not to be necessary with
your approach.

> The output register number and result word appear on the execution unit's
> output, at its Xbar write port. The Xbar then reads the result word and
> writes it to the specified register. A 7th bit in the pipeline FIFO contains
> a '1' when the pipeline stage contains a partial computation. The '1' is
> loaded in when the instruction is issued to the unit, and propagates to the
> output where it is used as the signal to inform Xbar that the unit is ready
> to complete.

Simply said, a `data valid' status bit?

> The latency of the execution unit is not stored elsewhere in the processor
> core, and it can vary in a data dependent way, or from one F-CPU
> implementation to the next.
>
> For example, in an application requiring a lot of integer multiplication,
> the application designer may wish to use an F-CPU core having an efficient
> pipelined parallel multiplier. This takes a lot of silicon area, but he may
> need the performance and decide to replace the standard shift-add iterative
> multiplier which might be provided in the base F-CPU implementation. Easy:
> he can just replace the inefficient serial multiplier unit with the parallel
> one. No questions asked by the rest of the CPU or the software, just better
> performance from a higher throughput and lower latency.
>
> The only disadvantage to the per-execution-unit destination register
> pipeline is that it requires higher complexity in the execution units and
> greater silicon area. However the addition of a 7-bit pipeline is hardly
> likely to be a significant complication, and given the 64-bit pipeline which
> will already exist in the execution unit, let alone the execution pipeline
> stages themselves, proportionally the 7 extra bits won't hurt the area too
> much. The advantages though are so numerous that I feel this can be
> tolerated.

Agreed, 7 bits isn't much, and there's almost no logic between the
flip-flops (no slowdown).

> An execution unit can even be non-pipelined and use the same mechanism. In
> this case it can latch the destination register and output it to the
> destination register output when the execution unit is complete. The simple
> non-pipelined division unit can still have its 6-bit counter, but it will
> now be inside the execution unit not the scheduler. At the end of the count,
> the unit will output the completion bit and the 6-bit destination register
> number.

IMHO an EU will always be `pipelined' -- there's at least one register at
the input and one at the output, and n (>= 0) between them.

> 2.4      XBAR WRITE CONFLICTS
>
> Now I hear you all wailing about what happens when too many execution units
> complete at exactly the same moment, and the Xbar has only two write ports.
> The answer is that the Xbar selects only two of the execution units to read
> from, any other execution units are stalled and wait for a space in the next
> cycle. A mechanism must therefore exist to stall the pipeline of execution
> units which have a result ready but the Xbar isn't ready to read it yet. I
> consider this in more detail a little later on.

Stalling complicates the pipelines, and also the instruction decoder
(because it has to check if a particular EU is stalled).  The necessary
clock enable lines may also affect the critical datapath.

> How does the Xbar decide which execution register output to read, when more
> than one is available? Using the same progressive selection "find first"
> binary tree mechanism described in the SRB chapter (manual v0.2 section
> 4.3). In this case the inputs to the tree are the 7th bit completion outputs
> of the execution units.
>
> If there are two write ports in the Xbar, an easy way to select two
> different waiting execution units is to reverse the order of the execution
> unit inputs to the find first binary tree. One tree can search from the
> first execution unit moving forwards, the other effectively moves backwards
> from the last execution unit.

We could play with different algorithms here -- round-robin, priority
based, ...

> This also raises the possibility of re-ordering the completion according to
> priority. Similar to the SRB mechanism, each execution unit can have a
> "express request" bit output, set to '1' when it urgently needs to complete.
> I can think of various methods for setting the express request bit.
>
> The express request output of an execution unit could be set when the
> instruction issue unit is stalled because it is waiting for the execution
> unit to become available. This could occur often when using long latency
> non-pipelined units like the divide unit.
>
> A second alternative would be to set the express request bit when the
> destination register is required by another pending instruction. This though
> could get more complicated, since the pipeline of an execution stage could
> contain several destination register computations, how would we detect that
> one of those is required by the instruction issue unit? In the simple case
> though, just the completing result could be checked against the dependency
> of waiting instruction operands.
>
> Thirdly, if the execution unit pipeline is compressible (another idea of
> mine see later), the express request bit could be set if the penultimate
> pipeline stage is computing a result. This would indicate that by not
> selecting the result of that execution unit the Xbar would delay more than
> one instruction.
>
> Whichever way, it is clear that the Xbar can simply use this method to
> ensure that there is no conflict on the Xbar's write ports due to multiple
> simultaneous execution unit completions. At the same time, execution units
> are free to complete early if they contain the necessary optimisation logic
> and the operands allow it, and the OOOC does not just reorder instruction
> execution based on execution unit latency, but also based on dependencies
> between the instructions. This should all improve performance, modularity
> and scalability of the design. More execution units can easily be added or
> replaced with more/less efficient ones depending on the requirements of a
> particular F-CPU implementation.

This sounds very nice, but a known latency has its advances, too.
If you know the latency of an instruction a priori, you can *statically*
schedule instructions (in the compiler) in order to optimize your code.
If EU latency is unknown, this becomes impossible (unless you issue
instructions out-of-order, which we currently don't).

[...]
> 3.4      COMPRESSIBLE PIPELINE
>
> An interesting idea I had is the "compressible pipeline". As the number of
> execution units is large relative to the number of instructions issued per
> cycle, it is unlikely that the pipeline of a given execution unit will be
> fully populated. In this case it is possible to partially stall the
> pipeline. Imagine the final stage of the pipeline stalls because the Xbar
> cannot take the result data. If the penultimate stage is empty, there is no
> need to stall the whole pipeline. Data earlier in the pipeline can still
> move to the next processing stage, without colliding with the waiting
> result.

Yep.  I've seen something similar in papers about TTA machines.

[...]
> 3.5      FORKED PIPELINE
>
> Another interesting idea in an execution unit where the execution pipeline
> can be forked when early completion is possible. This reduces the latency of
> the execution unit. For example the previously given floating point addition
> example. If the unit notices that the addition will simply result in the
> larger of the two operands, and no addition needs to be performed, and if
> the final stage of the execution pipeline is empty, the unit can route the
> operand directly to the final stage and alert the Xbar.

I'm afraid that there's no room for the multiplexers you need for
bypassing the later stages of the pipeline.  The pipeline stages of the
F-CPU are *very* short (6 gates / 10 transistors), and adding another
stage is not an option in most cases (most EUs are short, even IMUL
ist only 6 stages).

[...]
> 3.6      EARLY COMPLETION PORT
>
> Another idea for early completion is to have a separate output port for the
> early completion result. Such a scheme could be useful if the execution unit
> was likely to be heavily used and early completion was possible often. In
> this case the execution unit would have two output ports. They could be
> activated simultaneously depending on the contents of the execution unit's
> pipeline. It is the responsibility of the prioritisation activities of the
> Xbar write mechanism described earlier to handle these outputs.

That's what I did for the faster SIMD operations (the IMUL EU currently
has 4 output ports, ASU has 2).  But it has nothing to do with early
completion, the latency for all ports is well-known.

[...]
> 3.7      NON-PIPELINED EXECUTION UNIT
>
> Here I consider the design of a non pipelined execution unit (such as the
> shift-subtract division unit). The destination register is simply latched,
> and the latency cycles counted by a 6-bit 64 counter. When the count reaches
> 64, the complete signal is triggered (of course, any required latency could
> be obtained by decoding a different count)

Could also be a shift register (one-hot encoding).

[...]
> 3.8      DUAL OUTPUT PIPELINED MULTIPLIER UNIT
>
> The integer multiplier generates a 128-bit result (e.g. mulh instruction).
> This unit can just have two output ports! It is made very simple in this
> proposed architecture. The destination register output of the high word is
> just generated by adding one to the supplied destination register. For
> multiply instructions which don't generate a high word, the second port is
> simply not used! Again the Xbar will handle prioritisation of reading the
> results etc. My example design here is only for the mulh case (128-bit
> result to two registers), in reality one would put extra logic in to decode
> the opcode bits, since the high word may not be required.

The IMUL EU already has this port -- and if it's not needed, it is
simply ignored by the Xbar.

> 4      CONCLUSION
>
> My proposed replacement for the current scheduler unit is conceptually
> simpler. The decoder/instruction issue unit is made more simple since all it
> does is check availability and then issue.

The availability check may become more complex when we want to bypass
results.

> It will be easier to develop among a distributed group since the execution
> units are externally precisely defined. Unit designers can enhance execution
> units without affecting the rest of the design or requiring any changes
> elsewhere (no latency LUT!).

Yep, that's the biggest advance, IMHO.

> Performance is improved by improving the OOOC (result prioritisation) and
> permitting interesting optimisation variants of the execution units
> (non-deterministic latency).

Affects compile-time optimization.  And I just *hate* unpredictable
behaviour.

> The execution units may truly be considered like LEGO bricks. Different
> F-CPU implementations for different target users may be built with different
> execution units, or different variants of execution units depending on the
> particular performance vs. cost needs of the implementation.

True.

> The architecture is easily extensible. It is easy to see how more ports
> could be added to the Xbar, or the processor made superscalar by issuing
> more than one instruction per cycle. It is even possible to duplicate
> execution units if necessary. The complexity of the decoder will remain
> manageable.

You still have to prove that...

My conclusion: putting the `latency knowledge' into the EUs themselves is
a *very* good idea because it improves modularity and maintainability.
Tagging partial (and final) results with a register number (or a
transaction id) is also a good idea.  Variable latencies, on the other
hand, have their drawbacks, missing predictability beeing the worst
of them.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www..com
From Michael Riepe Mon Feb 5 14:32:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01175 for ; Wed, 7 Feb 2001 00:53:36 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:36 +0100 (MET) Received: (qmail 6083 invoked by uid 0); 5 Feb 2001 23:37:11 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx02) with SMTP; 5 Feb 2001 23:37:11 -0000 X-eGroups-Return: sentto-1101623-2268-981416103-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 05 Feb 2001 23:35:13 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 5 Feb 2001 23:35:03 -0000 Received: (qmail 9274 invoked from network); 5 Feb 2001 23:35:03 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 5 Feb 2001 23:35:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.67) by mta2 with SMTP; 5 Feb 2001 23:35:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00513; Mon, 5 Feb 2001 14:32:26 +0100 Message-ID: <20010205143226.34622@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A7941C5.2DDB2385@mentor.com> <20010201142516.14977@thrai.stud.uni-hannover.de> <3A7A8CFD.A1A9D006@mentor.com> <20010202153029.15442@thrai.stud.uni-hannover.de> <3A7E734B.D969AB85@it-netservice.de> X-Mailer: Mutt 0.84e In-Reply-To: <3A7E734B.D969AB85@it-netservice.de>; from Andreas Romeyke on Mon, Feb 05, 2001 at 10:32:59AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 14:32:26 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] execution unit confusion Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1750e429355fc5af76d8c20607c57057 Status: R X-Status: N On Mon, Feb 05, 2001 at 10:32:59AM +0100, Andreas Romeyke wrote:
[...]
> I am right that the problems in usage of signed/unsigned operations?

Together with SIMD chunk-splitting...

> If so, why you cannot operate in unsigned mode. In division we can
> handle the signs separately. We can build a unit which can do this for
> division, adder, multiplier, shiifter and so on, or not? I think the
> units were simpler, is not it?

We could, yes.  In case of the divider, we have to take the absolute
value of both operands, remember the signs, and negate the quotient
and/or remainder afterwards.  That means latency += 2 if we do it in the
unit itself, and latency += 4 if we use a separate unit (2 extra cycles
and some extra ports for the Xbar, and a lot of scheduler overhead).
If there's absolutely no other way, I'll use an internal abs/neg circuit.
But I got to get the SIMD stuff right first -- it's a little more
complicated than in the multiplier...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www. .com 
From Michael Riepe Tue Feb 6 01:34:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01178 for ; Wed, 7 Feb 2001 00:53:37 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:37 +0100 (MET) Received: (qmail 21036 invoked by uid 0); 6 Feb 2001 00:35:06 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 6 Feb 2001 00:35:06 -0000 X-eGroups-Return: sentto-1101623-2269-981419699-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 06 Feb 2001 00:35:04 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 00:34:59 -0000 Received: (qmail 17130 invoked from network); 6 Feb 2001 00:34:57 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 6 Feb 2001 00:34:57 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.67) by mta1 with SMTP; 6 Feb 2001 00:34:55 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01588; Tue, 6 Feb 2001 01:34:52 +0100 Message-ID: <20010206013446.42215@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <78.101734ae.27aef448@aol.com> <20010205000316.29241@thrai.stud.uni-hannover.de> <3A7F1E76.33AFB582@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A7F1E76.33AFB582@ifrance.com>; from Nicolas Boulay on Mon, Feb 05, 2001 at 10:43:18PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 01:34:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a4617e94f4f295f034bae17ac39a5716 Status: R X-Status: N On Mon, Feb 05, 2001 at 10:43:18PM +0100, Nicolas Boulay wrote:
[...]
> > No problem with gcc (use `long long' on intel boxen).
> >
> long long is for gcc, no ?
> I think that compaq use 64 bits for long (and for pointers).

I was referring to intel (or other 32-bit) machines.  On an Alpha,
UltraSPARC or Power3 in 64-bit mode it's simply a `long' (but `int'
is 32 bit wide, in all cases).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www..com
From Ben Franchuk Sat Feb 3 18:24:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01181 for ; Wed, 7 Feb 2001 00:53:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:38 +0100 (MET) Received: (qmail 18260 invoked by uid 0); 6 Feb 2001 00:40:14 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx01) with SMTP; 6 Feb 2001 00:40:14 -0000 X-eGroups-Return: sentto-1101623-2270-981420003-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 06 Feb 2001 00:40:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 00:40:02 -0000 Received: (qmail 70600 invoked from network); 6 Feb 2001 00:40:02 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 6 Feb 2001 00:40:02 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 6 Feb 2001 00:40:00 -0000 Received: from jetnet.ab.ca (dialin56.jetnet.ab.ca [207.153.6.56]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA15269 for ; Mon, 5 Feb 2001 17:31:27 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7C3EBE.7376271F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> <20010205193939.47886@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 10:24:14 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 88262bd8b4e345621b56b3c720c45b9d Status: R X-Status: N Michael Riepe wrote:
> If there are two write ports in the Xbar, an easy way to select two
> > different waiting execution units is to reverse the order of the execution
> > unit inputs to the find first binary tree. One tree can search from the
> > first execution unit moving forwards, the other effectively moves backwards
> > from the last execution unit.
>
> We could play with different algorithms here -- round-robin, priority
> based, ...
I guess the real algorithm to use is "Data-Flow Analysis". See
any good book on compiler design. In some cases data may never need
to be written to memory.
Take the while(a++=b++);  simple string copy.
the pipeline may need never write a++ or b++.
[a+1+...][b+1+...] could circulate in the pipeline until your block of
data is moved or a trap happens.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www. .com 
From Michael Riepe Tue Feb 6 01:40:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01184 for ; Wed, 7 Feb 2001 00:53:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:38 +0100 (MET) Received: (qmail 30440 invoked by uid 0); 6 Feb 2001 00:41:15 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx24) with SMTP; 6 Feb 2001 00:41:15 -0000 X-eGroups-Return: sentto-1101623-2271-981420068-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 06 Feb 2001 00:41:14 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 00:41:07 -0000 Received: (qmail 34379 invoked from network); 6 Feb 2001 00:41:07 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 6 Feb 2001 00:41:07 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.67) by mta2 with SMTP; 6 Feb 2001 00:41:05 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01618; Tue, 6 Feb 2001 01:41:01 +0100 Message-ID: <20010206014055.18548@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com Cc: seul@seul.org References: <200101301037.f0UAbcH01175@PrintServer.LedCom> <3A76B6B2.88756D66@mentor.com> <20010205170101.J958@belegost.mit.edu> X-Mailer: Mutt 0.84e In-Reply-To: <20010205170101.J958@belegost.mit.edu>; from Roger Dingledine on Mon, Feb 05, 2001 at 05:01:01PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 01:40:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cvs at sourceforge Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dfde2dd9978529fe30512a1dd914f4e3 Status: R X-Status: N On Mon, Feb 05, 2001 at 05:01:01PM -0500, Roger Dingledine wrote:
[...]
> I notice that we haven't set up an f-cpu module in the cvs repository
> yet. I believe we are blocking on "somebody at f-cpu telling us to".

Ok... please do so now :)

The top-level directory should be owned by f-cpu (group f-cpu) and have
permissions 2775 (i.e. group writable and sticky bit set).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.  
From Carsten899@aol.com Tue Feb 6 04:32:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01205 for ; Wed, 7 Feb 2001 00:53:43 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:43 +0100 (MET) Received: (qmail 31976 invoked by uid 0); 6 Feb 2001 03:33:24 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx22) with SMTP; 6 Feb 2001 03:33:24 -0000 X-eGroups-Return: sentto-1101623-2272-981430392-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 06 Feb 2001 03:33:23 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 03:33:11 -0000 Received: (qmail 32042 invoked from network); 6 Feb 2001 03:33:11 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 6 Feb 2001 03:33:11 -0000 Received: from unknown (HELO imo-r13.mx.aol.com) (152.163.225.67) by mta3 with SMTP; 6 Feb 2001 04:34:15 -0000 Received: from Carsten899@aol.com by imo-r13.mx.aol.com (mail_out_v29.5.) id r.45.1f8cfe9 (4357) for ; Mon, 5 Feb 2001 22:32:58 -0500 (EST) Message-ID: <45.1f8cfe9.27b0ca6a@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 5 Feb 2001 22:32:58 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 58b05f34ca858532701039666a66a778 Status: R X-Status: N >>i have a lot remarks on details but nothing severe :-) it may be
just write your comments into the code if possible and i can read it direct= ly
where you found problems?

>>the goal of developping the kernel requires that we can singlestep<= BR> >>the trap handlers etc.

the emulator has already a single step mode, so all you have to code is something like

// run cpu as long as a trap occurrs
while( !p->trapflag )
   fcpu_clock( p );

// fcpu runs into trap =3D> debug out

while( SingleStepTrapMode )
{
    WaitForKey();
    fcpu_clock( p );
     fcpu_dump_regs( p );
}

>>IRQ/TRAP/FAULT/SYSCALL/whatever is "pointing the PC to somewhe= re else"
>>and saving the PC or PC+4 (depending on the case) to the CMB.

So the FCPU stores one or more of this CMB=B4s somewhere inside? What if th= e
CPU stores "PC+4" into R63 or an SR on trapping or interrupt? ( r= equires
interrupts to be masked on trapping too ).
In case of CMB i am sure you knew when you wrote it, that i=B4d ask for a <= BR> structure definition. :-)

>>SRB is only a way to avoid to write the backup code (writing 64
>>registers takes 256 bytes of instructions and 512B of data...).

I think until now i mixed up SR ( Special Register ) with SRB ( Smooth
Register Backup )!?

>> hmmm that's not exactly how i'd write it but i'm such an optimisat= ion
freak ;-)

im in doubt about doing optimizations before having something like a
reference, which is hopefully readable code doing whats intended.

>>  addr_log2=3Daddr_log ^ TLB[i].log_addr;
>>    if ((addr_phys2 >> TLB[i].page_size)=3D=3D= 0) {

isnt it: if ( ( addr_log2 >> TLB[i].page_size ) =3D=3D 0 )?

>>typedef struct TLB_entry {
>>  u64 log_addr;
>> [...]

at least we have an definition - :-). i think, every element should use a <= BR> type describing the size, so "unsigned int" and "int" i= s replaced by u32 ?

>>POSIX compliant interface, that's all.

So the mulator has to do some of the syscalls in native code!? Its like the=
Java VM having native methods!?

Best Regards,
Carsten
Yahoo! Groups Spons= or
3D""
Do you know the name you want? Enter the domain name be= low and press GO!
www.
3D"Yahoo!
3D""
From Hans Summers Tue Feb 6 10:45:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01214 for ; Wed, 7 Feb 2001 00:53:46 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:46 +0100 (MET) Received: (qmail 13107 invoked by uid 0); 6 Feb 2001 09:46:09 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx24) with SMTP; 6 Feb 2001 09:46:09 -0000 X-eGroups-Return: sentto-1101623-2273-981452764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 06 Feb 2001 09:46:07 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 09:46:03 -0000 Received: (qmail 9797 invoked from network); 6 Feb 2001 09:46:03 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 6 Feb 2001 09:46:03 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta3 with SMTP; 6 Feb 2001 10:47:08 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA20039 for ; Tue, 6 Feb 2001 04:44:00 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA00451 for ; Tue, 6 Feb 2001 04:46:00 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Feb 2001 09:45:59 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 09:45:57 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: be4343e0a4d9dd82e6040b0dbdfe4dcc Status: R X-Status: N
> -----Original Message-----
> From: Michael Riepe [mailto:michael@stud.uni-hannover.de]
> Sent: 05 February 2001 18:40
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> On Mon, Feb 05, 2001 at 09:32:41AM -0000, Hans Summers wrote:
> [...]
> > 2.2      DECODER AND INSTRUCTION ISSUE
> >
> > The decoder becomes much more simple, it can probably be done in one
cycle.
> > I abandon the FIFO completion queues altogether (I'll speak about
completion
> > conflicts later). The decoder simply checks to see if the execution
unit,
> > source and destination registers applicable to the instruction are
> > available. If they are, the instruction is issued to the appropriate
> > execution unit on the next clock pulse, and the scoreboard "computing"
bit
> > of the destination register is set to indicate to subsequent
instructions
> > that the register is unavailable as a source register.
> >
> > This scheme is easily extensible. The instruction decode is so much
simpler
> > that it will be easy to construct multiple decoders and issue more than
one
> > instruction per cycle in future.
>
> What about bypassing results from one EU to another?

I thought about this a bit. But I don't know how bypassing is going to be
arranged with the current scheme? I assume that whatever problems and
solutions apply at the moment will apply to my scheme too. In the current
design does bypassing eliminate the need for writing to a register at all,
or is it just a way for a pending instruction to get at the data more
quickly if it appears on the Xbar during result write? Overall I concluded
that whatever problems would be faced in register bypassing would be the
same in my design and the current one. My design doesn't address that issue,
and I didn't think it makes it harder to solve.

>
> [...]
> > 2.3      EXECUTION UNIT PIPELINE
> >
> > Crucial to this design is that each execution unit should have its own
> > destination register pipeline. These replace the original scheduler
FIFO's.
> > Each pipelined execution unit has a 6-bit destination register input.
The
> > destination value gets loaded into this input when the instruction is
> > issued. That destination value moves along the execution unit pipeline
to
> > the output of the execution unit. However many cycles later when the
> > execution unit completes, the destination register number appears at the
> > output along with the result of the computation carried out by that
> > execution unit.
>
> I've been playing with a similar idea (with a generic `transaction id'
> instead of a register number).  The only problem was that operations
> could not be chained that way, but that seems not to be necessary with
> your approach.
>
> > The output register number and result word appear on the execution
unit's
> > output, at its Xbar write port. The Xbar then reads the result word and
> > writes it to the specified register. A 7th bit in the pipeline FIFO
contains
> > a '1' when the pipeline stage contains a partial computation. The '1' is
> > loaded in when the instruction is issued to the unit, and propagates to
the
> > output where it is used as the signal to inform Xbar that the unit is
ready
> > to complete.
>
> Simply said, a `data valid' status bit?
>

Yes. Internally within the execution unit pipeline this bit also shows if
the pipeline stage is full (useful for compressing the pipeline).

> > The latency of the execution unit is not stored elsewhere in the
processor
> > core, and it can vary in a data dependent way, or from one F-CPU
> > implementation to the next.
> >
> > For example, in an application requiring a lot of integer
multiplication,
> > the application designer may wish to use an F-CPU core having an
efficient
> > pipelined parallel multiplier. This takes a lot of silicon area, but he
may
> > need the performance and decide to replace the standard shift-add
iterative
> > multiplier which might be provided in the base F-CPU implementation.
Easy:
> > he can just replace the inefficient serial multiplier unit with the
parallel
> > one. No questions asked by the rest of the CPU or the software, just
better
> > performance from a higher throughput and lower latency.
> >
> > The only disadvantage to the per-execution-unit destination register
> > pipeline is that it requires higher complexity in the execution units
and
> > greater silicon area. However the addition of a 7-bit pipeline is hardly
> > likely to be a significant complication, and given the 64-bit pipeline
which
> > will already exist in the execution unit, let alone the execution
pipeline
> > stages themselves, proportionally the 7 extra bits won't hurt the area
too
> > much. The advantages though are so numerous that I feel this can be
> > tolerated.
>
> Agreed, 7 bits isn't much, and there's almost no logic between the
> flip-flops (no slowdown).
>
> > An execution unit can even be non-pipelined and use the same mechanism.
In
> > this case it can latch the destination register and output it to the
> > destination register output when the execution unit is complete. The
simple
> > non-pipelined division unit can still have its 6-bit counter, but it
will
> > now be inside the execution unit not the scheduler. At the end of the
count,
> > the unit will output the completion bit and the 6-bit destination
register
> > number.
>
> IMHO an EU will always be `pipelined' -- there's at least one register at
> the input and one at the output, and n (>= 0) between them.

There doesn't necessisarily need to be a register at the output. If the
final stage of the EU is considered to be latching the data into the Xbar
for result write, the final pipeline register can (should) be omitted or it
just wastes a cycle...

By non-pipelined in this sense I mean an EU which is only capable of
processing one instruction at a time. An iterative shift-add multiplier can
only multiply two numbers at a time (one instruction). However many cycles
of latency that takes can be counted with a binary counter, and the "data
valid" bit enabled when the count is completed. In contrast a high
performance (but large) parallel multiplier can be pipelined and be
processing several consecutive instructions (multiplies) at a time in its
pipeline. With my proposal a shift-add iterative multiplier could be
replaced with a parallel multiplier transparently. Throughput would increase
and latency may change, but elsewhere the processor would require no change.


>
> > 2.4      XBAR WRITE CONFLICTS
> >
> > Now I hear you all wailing about what happens when too many execution
units
> > complete at exactly the same moment, and the Xbar has only two write
ports.
> > The answer is that the Xbar selects only two of the execution units to
read
> > from, any other execution units are stalled and wait for a space in the
next
> > cycle. A mechanism must therefore exist to stall the pipeline of
execution
> > units which have a result ready but the Xbar isn't ready to read it yet.
I
> > consider this in more detail a little later on.
>
> Stalling complicates the pipelines, and also the instruction decoder
> (because it has to check if a particular EU is stalled).  The necessary
> clock enable lines may also affect the critical datapath.

Stalling is going to be necessary even in the current design. It occurs
anyway if the source registers for the instruction are not available (they
are awaiting result write from a previous computing instruction). The
instruction decoder checking if a particular execution unit is stalled is no
different from checking if the source registers are available, and it will
be done in parallel therefore not lengthening the critical datapath. As the
current pipeline must also be stallable it will also require clock enable
lines, so no change here.

>
> > How does the Xbar decide which execution register output to read, when
more
> > than one is available? Using the same progressive selection "find first"
> > binary tree mechanism described in the SRB chapter (manual v0.2 section
> > 4.3). In this case the inputs to the tree are the 7th bit completion
outputs
> > of the execution units.
> >
> > If there are two write ports in the Xbar, an easy way to select two
> > different waiting execution units is to reverse the order of the
execution
> > unit inputs to the find first binary tree. One tree can search from the
> > first execution unit moving forwards, the other effectively moves
backwards
> > from the last execution unit.
>
> We could play with different algorithms here -- round-robin, priority
> based, ...
>
> > This also raises the possibility of re-ordering the completion according
to
> > priority. Similar to the SRB mechanism, each execution unit can have a
> > "express request" bit output, set to '1' when it urgently needs to
complete.
> > I can think of various methods for setting the express request bit.
> >
> > The express request output of an execution unit could be set when the
> > instruction issue unit is stalled because it is waiting for the
execution
> > unit to become available. This could occur often when using long latency
> > non-pipelined units like the divide unit.
> >
> > A second alternative would be to set the express request bit when the
> > destination register is required by another pending instruction. This
though
> > could get more complicated, since the pipeline of an execution stage
could
> > contain several destination register computations, how would we detect
that
> > one of those is required by the instruction issue unit? In the simple
case
> > though, just the completing result could be checked against the
dependency
> > of waiting instruction operands.
> >
> > Thirdly, if the execution unit pipeline is compressible (another idea of
> > mine see later), the express request bit could be set if the penultimate
> > pipeline stage is computing a result. This would indicate that by not
> > selecting the result of that execution unit the Xbar would delay more
than
> > one instruction.
> >
> > Whichever way, it is clear that the Xbar can simply use this method to
> > ensure that there is no conflict on the Xbar's write ports due to
multiple
> > simultaneous execution unit completions. At the same time, execution
units
> > are free to complete early if they contain the necessary optimisation
logic
> > and the operands allow it, and the OOOC does not just reorder
instruction
> > execution based on execution unit latency, but also based on
dependencies
> > between the instructions. This should all improve performance,
modularity
> > and scalability of the design. More execution units can easily be added
or
> > replaced with more/less efficient ones depending on the requirements of
a
> > particular F-CPU implementation.
>
> This sounds very nice, but a known latency has its advances, too.
> If you know the latency of an instruction a priori, you can *statically*
> schedule instructions (in the compiler) in order to optimize your code.
> If EU latency is unknown, this becomes impossible (unless you issue
> instructions out-of-order, which we currently don't).

I agree that in an ideal world the compiler should know the instruction
latency so it can optimise static scheduling. If code is run on different
versions of the F-CPU having different execution units, it would need
recompiling to get optimum scheduling, which is no problem. My proposal is
not intended to replace compile-time optimisation, rather to augment it. In
cases where code is not recompiled there would be some performance gain.
There could also be data-dependent performance gain which is impossible to
predict when the compiler does its instruction scheduling. In any event the
maximum latency of an execution unit will still be known to the compiler.
Just in some cases the processor may improve on the completion scheduling
done by the compiler, or if the code was compiled for a different version,
or if the data and pipeline contents allow lower latency. I believe this new
design cannot have a LOWER performance than the current design, but can have
HIGHER performance under some circumstances. I view it as a useful side
effect rather than the main advantage of better modularity and simpler
decoder/scheduler (no special cases e.g. Load/Store, divide; no large LUT to
be maintained etc.).

>
> [...]
> > 3.4      COMPRESSIBLE PIPELINE
> >
> > An interesting idea I had is the "compressible pipeline". As the number
of
> > execution units is large relative to the number of instructions issued
per
> > cycle, it is unlikely that the pipeline of a given execution unit will
be
> > fully populated. In this case it is possible to partially stall the
> > pipeline. Imagine the final stage of the pipeline stalls because the
Xbar
> > cannot take the result data. If the penultimate stage is empty, there is
no
> > need to stall the whole pipeline. Data earlier in the pipeline can still
> > move to the next processing stage, without colliding with the waiting
> > result.
>
> Yep.  I've seen something similar in papers about TTA machines.

Interesting. When I have time I am going to read some more about TTA. Again
the compressible pipeline can only increase performance, never decrease it.
The extra gates in the EU pipeline clock-enable are not in the CDP.

>
> [...]
> > 3.5      FORKED PIPELINE
> >
> > Another interesting idea in an execution unit where the execution
pipeline
> > can be forked when early completion is possible. This reduces the
latency of
> > the execution unit. For example the previously given floating point
addition
> > example. If the unit notices that the addition will simply result in the
> > larger of the two operands, and no addition needs to be performed, and
if
> > the final stage of the execution pipeline is empty, the unit can route
the
> > operand directly to the final stage and alert the Xbar.
>
> I'm afraid that there's no room for the multiplexers you need for
> bypassing the later stages of the pipeline.  The pipeline stages of the
> F-CPU are *very* short (6 gates / 10 transistors), and adding another
> stage is not an option in most cases (most EUs are short, even IMUL
> ist only 6 stages).
>

I worry a little about making a pipeline state SO short it can do too little
useful work. I wouldn't suggest adding an extra stage just for the sake of a
multiplexer. But the multiplexer should only take 1 gate in the CDP. In some
circumstances depending on the design and function of the EU it may be
possible if the pipeline stage has room. It's again a side-effect of the
main design, a posibility which can possibly be incorporated if desired. It
would be invisible outside the "black box" execution unit.

> [...]
> > 3.6      EARLY COMPLETION PORT
> >
> > Another idea for early completion is to have a separate output port for
the
> > early completion result. Such a scheme could be useful if the execution
unit
> > was likely to be heavily used and early completion was possible often.
In
> > this case the execution unit would have two output ports. They could be
> > activated simultaneously depending on the contents of the execution
unit's
> > pipeline. It is the responsibility of the prioritisation activities of
the
> > Xbar write mechanism described earlier to handle these outputs.
>
> That's what I did for the faster SIMD operations (the IMUL EU currently
> has 4 output ports, ASU has 2).  But it has nothing to do with early
> completion, the latency for all ports is well-known.
>
> [...]
> > 3.7      NON-PIPELINED EXECUTION UNIT
> >
> > Here I consider the design of a non pipelined execution unit (such as
the
> > shift-subtract division unit). The destination register is simply
latched,
> > and the latency cycles counted by a 6-bit 64 counter. When the count
reaches
> > 64, the complete signal is triggered (of course, any required latency
could
> > be obtained by decoding a different count)
>
> Could also be a shift register (one-hot encoding).

Yes. Whatever the EU designer wishes. The rest of the design is ignorant of
what goes on inside the "black box" EU.

>
> [...]
> > 3.8      DUAL OUTPUT PIPELINED MULTIPLIER UNIT
> >
> > The integer multiplier generates a 128-bit result (e.g. mulh
instruction).
> > This unit can just have two output ports! It is made very simple in this
> > proposed architecture. The destination register output of the high word
is
> > just generated by adding one to the supplied destination register. For
> > multiply instructions which don't generate a high word, the second port
is
> > simply not used! Again the Xbar will handle prioritisation of reading
the
> > results etc. My example design here is only for the mulh case (128-bit
> > result to two registers), in reality one would put extra logic in to
decode
> > the opcode bits, since the high word may not be required.
>
> The IMUL EU already has this port -- and if it's not needed, it is
> simply ignored by the Xbar.

Good, I haven't the seen IMUL EU design.

>
> > 4      CONCLUSION
> >
> > My proposed replacement for the current scheduler unit is conceptually
> > simpler. The decoder/instruction issue unit is made more simple since
all it
> > does is check availability and then issue.
>
> The availability check may become more complex when we want to bypass
> results.

Agreed, but presumably the same issues affect the current design.

>
> > It will be easier to develop among a distributed group since the
execution
> > units are externally precisely defined. Unit designers can enhance
execution
> > units without affecting the rest of the design or requiring any changes
> > elsewhere (no latency LUT!).
>
> Yep, that's the biggest advance, IMHO.
>
> > Performance is improved by improving the OOOC (result prioritisation)
and
> > permitting interesting optimisation variants of the execution units
> > (non-deterministic latency).
>
> Affects compile-time optimization.  And I just *hate* unpredictable
> behaviour.

As above. I don't think performance can be degraded, possibly it can be
improved in some circumstances. Personally I rather like unpredictable
behaviour! The whole F-CPU project is somewhat anarchistic and having a
matching architecture seems to suit (unless it degrades performance,
obviously). It's also somewhat novel. If I am in a minority then
data-dependent optimisation could be discarded.

>
> > The execution units may truly be considered like LEGO bricks. Different
> > F-CPU implementations for different target users may be built with
different
> > execution units, or different variants of execution units depending on
the
> > particular performance vs. cost needs of the implementation.
>
> True.
>
> > The architecture is easily extensible. It is easy to see how more ports
> > could be added to the Xbar, or the processor made superscalar by issuing
> > more than one instruction per cycle. It is even possible to duplicate
> > execution units if necessary. The complexity of the decoder will remain
> > manageable.
>
> You still have to prove that...

True. Many issues remain there. Nevertheless the same issues exist with the
current design. By the simplications in my proposal and the improved
modularity etc at least we have the best chance of solving the challenges
when the time comes to consider them.

>
> My conclusion: putting the `latency knowledge' into the EUs themselves is
> a *very* good idea because it improves modularity and maintainability.
> Tagging partial (and final) results with a register number (or a
> transaction id) is also a good idea.  Variable latencies, on the other
> hand, have their drawbacks, missing predictability beeing the worst
> of them.

My main objective in this proposal was to tidy up the scheduler design to
get better modularity and maintainability. It's going to be hard enough
anyway to complete the F-CPU without those problems. The variable latency is
a possibility with the new proposal which doesn't exist with the existing
design. It could be interesting and novel but if we don't like it we can
leave it out. Personally I like the unpredictability, as long as it doesn't
degrade performance (I believe it can only improve it here).

>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
www..com
From Michael Riepe Tue Feb 6 02:45:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01238 for ; Wed, 7 Feb 2001 00:53:54 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:53:54 +0100 (MET) Received: (qmail 19721 invoked by uid 0); 6 Feb 2001 12:55:09 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx10) with SMTP; 6 Feb 2001 12:55:09 -0000 X-eGroups-Return: sentto-1101623-2274-981464092-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 06 Feb 2001 12:55:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 12:54:51 -0000 Received: (qmail 58716 invoked from network); 6 Feb 2001 12:54:51 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 6 Feb 2001 12:54:51 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.64) by mta1 with SMTP; 6 Feb 2001 12:54:50 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01839; Tue, 6 Feb 2001 02:45:47 +0100 Message-ID: <20010206024547.30412@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> <20010205193939.47886@thrai.stud.uni-hannover.de> <3A7C3EBE.7376271F@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A7C3EBE.7376271F@jetnet.ab.ca>; from Ben Franchuk on Sat, Feb 03, 2001 at 10:24:14AM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 02:45:47 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8450c7e0612fac023de929f1bd3850f7 Status: R X-Status: N On Sat, Feb 03, 2001 at 10:24:14AM -0700, Ben Franchuk wrote:
> Michael Riepe wrote:
>  > If there are two write ports in the Xbar, an easy way to select two
> > > different waiting execution units is to reverse the order of the execution
> > > unit inputs to the find first binary tree. One tree can search from the
> > > first execution unit moving forwards, the other effectively moves backwards
> > > from the last execution unit.
> >
> > We could play with different algorithms here -- round-robin, priority
> > based, ...
> I guess the real algorithm to use is "Data-Flow Analysis". See
> any good book on compiler design. In some cases data may never need
> to be written to memory.

We're on the hardware side here... there is no compiler.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
From Yann GUIDON Tue Feb 6 17:21:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01271 for ; Wed, 7 Feb 2001 00:54:32 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:32 +0100 (MET) Received: (qmail 31657 invoked by uid 0); 6 Feb 2001 16:28:01 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx23) with SMTP; 6 Feb 2001 16:28:01 -0000 X-eGroups-Return: sentto-1101623-2276-981476868-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 06 Feb 2001 16:27:52 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 16:27:47 -0000 Received: (qmail 24196 invoked from network); 6 Feb 2001 16:27:44 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 6 Feb 2001 16:27:44 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 6 Feb 2001 16:27:43 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA07196; Tue, 6 Feb 2001 08:27:38 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWR81; Tue, 6 Feb 2001 16:32:37 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A802478.EF68109E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Feb 2001 17:21:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4d58d46451676f1a5f7f767efa9aa7cd Status: R X-Status: N hi,

Hans Summers wrote:
> From: Michael Riepe :
> > What about bypassing results from one EU to another?
good point :-)

bypassing would require to compare the reg flags of every unit in parallel,
while less comparisons are needed with the "old" FIFO :-)

> I thought about this a bit. But I don't know how bypassing is going to be
> arranged with the current scheme?
rather easy.
As the FIFO shifts down, we can see that the fore-to-last stage contains the
numbers of the registers that will be issued in the next cycle. they are compared
with the currently needed registers and we can therefore issue an instruction
1 cycle in advance compared to a non-bypassing scheme.

> I assume that whatever problems and
> solutions apply at the moment will apply to my scheme too.
your scheme requires a more "brute force" approach, due to the
"spreading/dissemination" of the information. comparators everywhere.

In fact your approach is completely the opposite of the FC0's :
you take the POV of the issue stage. you hope that the execution unit
will do all the scheduling for you.
>From the FC0's POV, we start from the END : from the write ports of the
R7.

You issue an instruction when the data is ready,
i issue if the data can be written (that's an illustration, of course).
This means that all the mechanism that decides what EU will write its
result, is brought somewhere else. This has to be done somewhere anyway.
As Michael pointed, it allows a compiler to statically schedule the CPU.
it has an invaluable advantage when high performance is at stake because
you can GARANTEE the execution time. It is impossible to predict the
execution time of any piece of SW on OOO cores.

> In the current
> design does bypassing eliminate the need for writing to a register at all,
> or is it just a way for a pending instruction to get at the data more
> quickly if it appears on the Xbar during result write?
you got it :-) it shadows one of the Xbar cycle, and it's also one of the Xbar's
purposes.

> Overall I concluded
> that whatever problems would be faced in register bypassing would be the
> same in my design and the current one. My design doesn't address that issue,
> and I didn't think it makes it harder to solve.
mmm you should think a bit more :-)


> > > The only disadvantage to the per-execution-unit destination register
> > > pipeline is that it requires higher complexity in the execution units and
> > > greater silicon area. However the addition of a 7-bit pipeline is hardly
> > > likely to be a significant complication, and given the 64-bit pipeline which
> > > will already exist in the execution unit, let alone the execution pipeline
> > > stages themselves, proportionally the 7 extra bits won't hurt the area too
> > > much. The advantages though are so numerous that I feel this can be
> > > tolerated.
> > Agreed, 7 bits isn't much, and there's almost no logic between the
> > flip-flops (no slowdown).
maybe. however, the information is disseminated and spread all around the chip.
if it is not available somewhere else, you'll require long wires and lotsa comparators !

> > > An execution unit can even be non-pipelined and use the same mechanism. In
> > > this case it can latch the destination register and output it to the
> > > destination register output when the execution unit is complete. The simple
> > > non-pipelined division unit can still have its 6-bit counter, but it will
> > > now be inside the execution unit not the scheduler. At the end of the count,
> > > the unit will output the completion bit and the 6-bit destination register
> > > number.
> >
> > IMHO an EU will always be `pipelined' -- there's at least one register at
> > the input and one at the output, and n (>= 0) between them.
>
> There doesn't necessisarily need to be a register at the output. If the
> final stage of the EU is considered to be latching the data into the Xbar
> for result write, the final pipeline register can (should) be omitted or it
> just wastes a cycle...

nope. we have "very thin stages" and we consider the pipeline as an alternance of
logic and flip flops. the Xbar is considered as a "logic" layer and the FF have
to buffer the data while it is propagating.

> By non-pipelined in this sense I mean an EU which is only capable of
> processing one instruction at a time. An iterative shift-add multiplier can
> only multiply two numbers at a time (one instruction). However many cycles
> of latency that takes can be counted with a binary counter, and the "data
> valid" bit enabled when the count is completed. In contrast a high
> performance (but large) parallel multiplier can be pipelined and be
> processing several consecutive instructions (multiplies) at a time in its
> pipeline. With my proposal a shift-add iterative multiplier could be
> replaced with a parallel multiplier transparently. Throughput would increase
> and latency may change, but elsewhere the processor would require no change.
Michael has already done a SIMD 64-bit multiplier with 6 stages.
I don't know the conditions for early exit (with 8, 16 and 32 bit data)
however but it can be easily encoded into the "Latency LUT".

> >
> > > 2.4 XBAR WRITE CONFLICTS
> > >
> > > Now I hear you all wailing about what happens when too many execution
> units
> > > complete at exactly the same moment, and the Xbar has only two write
> ports.
> > > The answer is that the Xbar selects only two of the execution units to
> read
> > > from, any other execution units are stalled and wait for a space in the
> next
> > > cycle. A mechanism must therefore exist to stall the pipeline of
> execution
> > > units which have a result ready but the Xbar isn't ready to read it yet.
> I
> > > consider this in more detail a little later on.
> >
> > Stalling complicates the pipelines, and also the instruction decoder
> > (because it has to check if a particular EU is stalled).  The necessary
> > clock enable lines may also affect the critical datapath.
Because of their nature, stall can also be caused by
- memory not ready (or more precisely : LSU line absent)
- DIV unit busy
therefore, DIV, LOAD and STORE are impacted (as well as derivated uses).

> Stalling is going to be necessary even in the current design. It occurs
> anyway if the source registers for the instruction are not available (they
> are awaiting result write from a previous computing instruction). The
> instruction decoder checking if a particular execution unit is stalled is no
> different from checking if the source registers are available, and it will
> be done in parallel therefore not lengthening the critical datapath.
right.

> As the current pipeline must also be stallable it will also require clock enable
> lines, so no change here.
wrong. "stall" means "the current instruction in the decoder is not ready",
while the rest of the execution pipeline flows its way normally...
there's a little difference now :-)
If the whole pipeline was stalled because a source register is not ready,
it would deadlock the CPU ;-P


> > > If there are two write ports in the Xbar, an easy way to select two
> > > different waiting execution units is to reverse the order of the execution
> > > unit inputs to the find first binary tree. One tree can search from the
> > > first execution unit moving forwards, the other effectively moves backwards
> > > from the last execution unit.
> > We could play with different algorithms here -- round-robin, priority
> > based, ...
yep we can play a LOT but it doesn't solve the problem : this lengthens and
complicates the scheduling (from my point of view). scheduling has two sides :
HW and SW. Currently the FC0 can achieve good sustained performance because
it is predictive, it's almost an ALPHA. Hans' propositions look like we're going
to make a PowerPC. he has not yet studied how he'll unwind the instruction flow
when there's a trouble...

> > > Whichever way, it is clear that the Xbar can simply use this method to
> > > ensure that there is no conflict on the Xbar's write ports due to multiple
> > > simultaneous execution unit completions. At the same time, execution units
> > > are free to complete early if they contain the necessary optimisation logic
> > > and the operands allow it, and the OOOC does not just reorder instruction
> > > execution based on execution unit latency, but also based on dependencies
> > > between the instructions.
there is probably a mistake here : there is NO execution "reordering" in FC0.
only write back is OOO while the scheduler and the scoreboard issue
"safe" instructions. From the programming point of view, it is crucial...

> > > This should all improve performance, modularity
> > > and scalability of the design. More execution units can easily be added or
> > > replaced with more/less efficient ones depending on the requirements of a
> > > particular F-CPU implementation.
> >
> > This sounds very nice, but a known latency has its advances, too.
> > If you know the latency of an instruction a priori, you can *statically*
> > schedule instructions (in the compiler) in order to optimize your code.
> > If EU latency is unknown, this becomes impossible (unless you issue
> > instructions out-of-order, which we currently don't).
>
> I agree that in an ideal world the compiler should know the instruction
> latency so it can optimise static scheduling. If code is run on different
> versions of the F-CPU having different execution units, it would need
> recompiling to get optimum scheduling, which is no problem. My proposal is
> not intended to replace compile-time optimisation, rather to augment it. In
> cases where code is not recompiled there would be some performance gain.
> There could also be data-dependent performance gain which is impossible to
> predict when the compiler does its instruction scheduling. In any event the
> maximum latency of an execution unit will still be known to the compiler.
> Just in some cases the processor may improve on the completion scheduling
> done by the compiler, or if the code was compiled for a different version,
> or if the data and pipeline contents allow lower latency. I believe this new
> design cannot have a LOWER performance than the current design, but can have
> HIGHER performance under some circumstances.
however, on a given case, FC0's price/complexity/speed can win ;-)

> I view it as a useful side
> effect rather than the main advantage of better modularity and simpler
> decoder/scheduler (no special cases e.g. Load/Store, divide; no large LUT to
> be maintained etc.).

we are probably going to need in the future the techniques you described :
scheduling completely changes when more than one instruction is issued
per cycle, and compilers don't often keep up. even the current GCC port
is not good at all at scheduling anything. One cycle or two that can be won
is not negligible.

> > [...]
> > > 3.4 COMPRESSIBLE PIPELINE
> > >
> > > An interesting idea I had is the "compressible pipeline". As the number of
> > > execution units is large relative to the number of instructions issued per
> > > cycle, it is unlikely that the pipeline of a given execution unit will be
> > > fully populated. In this case it is possible to partially stall the
> > > pipeline. Imagine the final stage of the pipeline stalls because the Xbar
> > > cannot take the result data. If the penultimate stage is empty, there is no
> > > need to stall the whole pipeline. Data earlier in the pipeline can still
> > > move to the next processing stage, without colliding with the waiting
> > > result.
> >
> > Yep.  I've seen something similar in papers about TTA machines.
>
> Interesting. When I have time I am going to read some more about TTA. Again
> the compressible pipeline can only increase performance, never decrease it.
> The extra gates in the EU pipeline clock-enable are not in the CDP.
well the idea is good and seducing, however this means that we must use clock gating.
it might make the implementation difficult....... ask the specialists.

> >
> > [...]
> > > 3.5 FORKED PIPELINE
> > >
> > > Another interesting idea in an execution unit where the execution pipeline
> > > can be forked when early completion is possible. This reduces the latency of
> > > the execution unit. For example the previously given floating point addition
> > > example. If the unit notices that the addition will simply result in the
> > > larger of the two operands, and no addition needs to be performed, and if
> > > the final stage of the execution pipeline is empty, the unit can route the
> > > operand directly to the final stage and alert the Xbar.
> >
> > I'm afraid that there's no room for the multiplexers you need for
> > bypassing the later stages of the pipeline.  The pipeline stages of the
> > F-CPU are *very* short (6 gates / 10 transistors), and adding another
> > stage is not an option in most cases (most EUs are short, even IMUL
> > ist only 6 stages).
> >
> I worry a little about making a pipeline state SO short it can do too little
> useful work. I wouldn't suggest adding an extra stage just for the sake of a
> multiplexer. But the multiplexer should only take 1 gate in the CDP. In some
> circumstances depending on the design and function of the EU it may be
> possible if the pipeline stage has room. It's again a side-effect of the
> main design, a posibility which can possibly be incorporated if desired. It
> would be invisible outside the "black box" execution unit.

the "6 gates goal" is here to remember the designers that it is easy to get trapped
when one adds a gate here and there. If it is necessary, we can add a gate
for a very important special case. However, "the shortest the simplest"
(and speed is not the only issue). When we add depth, we have more chances
to make buggy designs. It forces us to think about the necessity of each part.

> > [...]
> > > 3.6 EARLY COMPLETION PORT
> > That's what I did for the faster SIMD operations (the IMUL EU currently
> > has 4 output ports, ASU has 2).  But it has nothing to do with early
> > completion, the latency for all ports is well-known.
:-) you see, we also worry about executing as fast as possible :-)


> > [...]
> > > 3.8 DUAL OUTPUT PIPELINED MULTIPLIER UNIT
> > [...]
> > > My example design here is only for the mulh case (128-bit
> > > result to two registers), in reality one would put extra logic in to decode
> > > the opcode bits, since the high word may not be required.
> > The IMUL EU already has this port -- and if it's not needed, it is
> > simply ignored by the Xbar.
> Good, I haven't the seen IMUL EU design.
look at f-cpu.de/design

> > > 4   CONCLUSION
> > >
> > > My proposed replacement for the current scheduler unit is conceptually
> > > simpler.
however it makes the compiler much difficult to write.

> > > The decoder/instruction issue unit is made more simple since all it
> > > does is check availability and then issue.
However how do you check for the availability ?
you have to read the scoreboard bits,
they are set when the Xbar write ports are in use,
this means a lot of wires, comparators, latency.
with the FIFO approach, we can perform bypass etc.
more easily than you'd think :-)

> > The availability check may become more complex when we want to bypass
> > results.
> Agreed, but presumably the same issues affect the current design.
"presumably".
i think that his approach leads us to a completely different style of CPU,
more suited to pure OOO.

> > > It will be easier to develop among a distributed group since the execution
> > > units are externally precisely defined. Unit designers can enhance execution
> > > units without affecting the rest of the design or requiring any changes
> > > elsewhere (no latency LUT!).
> > Yep, that's the biggest advance, IMHO.
i don't think it's such a problem however...
it's a matter of good coding practice and reading the readme.txt files...

> > > Performance is improved by improving the OOOC (result prioritisation) and
> > > permitting interesting optimisation variants of the execution units
> > > (non-deterministic latency).
> > Affects compile-time optimization.  And I just *hate* unpredictable
> > behaviour.
me too ...
if you had programmed as much MMX asm as me, you'd understand ;-)

> As above. I don't think performance can be degraded, possibly it can be
> improved in some circumstances.
however performance is related to the compiler's quality,
which is proportional to the simplicity of the cpu.

> Personally I rather like unpredictable
> behaviour! The whole F-CPU project is somewhat anarchistic and having a
> matching architecture seems to suit (unless it degrades performance,
> obviously). It's also somewhat novel. If I am in a minority then
> data-dependent optimisation could be discarded.
well as of today your ideas are not needed but don't abandon them.
it's already a lot of work...
data-dependent in itself is not "bad", it simply does not fit for the FC0,
but it might easily be the base for another new F-CPU core.

BTW we can detect div by zero at decode time, just like we "could"
transform y=x+0 into y=x, it must simply be integrated in the decoder's
compiler-generated tables.


> > > The architecture is easily extensible. It is easy to see how more ports
> > > could be added to the Xbar, or the processor made superscalar by issuing
> > > more than one instruction per cycle. It is even possible to duplicate
> > > execution units if necessary. The complexity of the decoder will remain
> > > manageable.
> >
> > You still have to prove that...
>
> True. Many issues remain there.
i'd say : IRQ for example :-)
maybe you know a simple turnaround...

> Nevertheless the same issues exist with the
> current design. By the simplications in my proposal and the improved
> modularity etc at least we have the best chance of solving the challenges
> when the time comes to consider them.
time will come. but we have something to finish first ;-)

> > My conclusion: putting the `latency knowledge' into the EUs themselves is
> > a *very* good idea because it improves modularity and maintainability.
> > Tagging partial (and final) results with a register number (or a
> > transaction id) is also a good idea.  Variable latencies, on the other
> > hand, have their drawbacks, missing predictability beeing the worst
> > of them.
it's not the only one. we have to know what register is needed by what
and belongs to which task etc... Otherwise the apparent speedup might
become a huge pain to develop, program and debug ! don't forget the poor,
poor compiler writers and asm programers...

> My main objective in this proposal was to tidy up the scheduler design to
> get better modularity and maintainability.
nothing comes from free :-)
you "solve" problems, or more precisely you move them around,
it's an endless game. this explains the large variety of core types today.
FC0 starts from one POV, you start from another and we get different
behaviours that can be good or bad depending on the situation.

> It's going to be hard enough
> anyway to complete the F-CPU without those problems.
:-)

> The variable latency is
> a possibility with the new proposal which doesn't exist with the existing
> design.
notice that some of the "execution time enhancements" are often simple
enough to be integrated into the decoder, with the help of some speculative
flags. Look at how the memory is accessed and disambiguified.

> It could be interesting and novel but if we don't like it we can
> leave it out. Personally I like the unpredictability, as long as it doesn't
> degrade performance (I believe it can only improve it here).
it "could" but it depends on the cases.

> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> Hans Summers

YG

speaking for himself
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Sat Feb 3 23:59:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01274 for ; Wed, 7 Feb 2001 00:54:35 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:35 +0100 (MET) Received: (qmail 21434 invoked by uid 0); 6 Feb 2001 16:30:53 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx24) with SMTP; 6 Feb 2001 16:30:52 -0000 X-eGroups-Return: sentto-1101623-2277-981477036-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 06 Feb 2001 16:30:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 16:30:36 -0000 Received: (qmail 34359 invoked from network); 6 Feb 2001 16:30:35 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 6 Feb 2001 16:30:35 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 6 Feb 2001 16:30:33 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA14108 for ; Tue, 6 Feb 2001 09:21:56 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7C8D43.70B7145B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> <20010205193939.47886@thrai.stud.uni-hannover.de> <3A7C3EBE.7376271F@jetnet.ab.ca> <20010206024547.30412@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 15:59:15 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 437c05bac77fde0a2c6cb3985f25f7ae Status: R X-Status: N Michael Riepe wrote:
> We're on the hardware side here... there is no compiler.
What is done is to re-map from a register-control flow
information set to a pipeline/alu's flow in real time.
Score boards and other tricks can't look ahead several
instructions to tell if a variable is live or dead, to tell
if address calculated needs to be saved or not after being used.
While this information the compiler has it is not passed down
to the hardware so it can make good scheduling decisions in the
pipeline.
For example in case of a tie for xbar writes give the
write to address calculations if the address is not used
in the next cycle in the pipeline.(ie it can forwarded).
But you need to flag this a 'address' some how before you
are knee-deep in the pipline.hints here from the compiler
would be nice rather than decoding the information yourself.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Yann GUIDON Tue Feb 6 17:47:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01286 for ; Wed, 7 Feb 2001 00:54:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:38 +0100 (MET) Received: (qmail 18015 invoked by uid 0); 6 Feb 2001 16:55:08 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx07) with SMTP; 6 Feb 2001 16:55:08 -0000 X-eGroups-Return: sentto-1101623-2278-981478438-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ci.egroups.com with NNFMP; 06 Feb 2001 16:54:12 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 16:53:56 -0000 Received: (qmail 4212 invoked from network); 6 Feb 2001 16:53:56 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 6 Feb 2001 16:53:56 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 6 Feb 2001 16:53:55 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA11357; Tue, 6 Feb 2001 08:53:50 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWR9R; Tue, 6 Feb 2001 16:58:45 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A802A97.2EDFC4EA@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <45.1f8cfe9.27b0ca6a@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Feb 2001 17:47:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 563f59fbc1fccd676d1249dce8e88c1e Status: R X-Status: N Carsten899@aol.com wrote:
> >>i have a lot remarks on details but nothing severe :-)
> just write your comments into the code if possible and i can read it d= irectly
> where you found problems?

in fact it's not at a specific location.
more about the implementation choices.
it looks like you have already written emus, but the f-cpu is
not really a classical machine, specifically when it comes to
the SIMD side...

one things is to write more generic functions that depend on the
size of the data, instead of making a 8-, 16-, 32- and 64-bit version.
when someone wants to play with other sizes (128, 256, 512, whatever)
not only it keeps the code portable (endian-free) but there's only
ONE function for every size. you could halve your code size and reduce
the possible bugs :-)

> >>the goal of developping the kernel requires that we can single= step
> >>the trap handlers etc.
>
> the emulator has already a single step mode, so all you have to code i= s
> something like
<snip>

nice, nice :-)

> >>IRQ/TRAP/FAULT/SYSCALL/whatever is "pointing the PC to so= mewhere else"
> >>and saving the PC or PC+4 (depending on the case) to the CMB.<= BR> >
> So the FCPU stores one or more of this CMB=B4s somewhere inside? What = if the
> CPU stores "PC+4" into R63 or an SR on trapping or interrupt= ? ( requires
> interrupts to be masked on trapping too ).
> In case of CMB i am sure you knew when you wrote it, that i=B4d ask fo= r a
> structure definition. :-)

i have none at hand.
i'll quote the manual 0.2.2 beta :
(p2.tex)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~

\section{The F-CPU stores the state of a task in Context MemoryBlocks (CMB)= }

These are very important structures for the OS because the SRB
mechanism keeps the handlers from seeing the interrupted tasks for coherenc= y
reasons. The OS will deal with these blocks in order to set or modify the properties and access rights of a task, read its registers, or interpret a<= BR> system call. A context memory block must store all the data that are privat= e
to a task in order to fully store and restore it. The endianness of the CMB=
is not defined.

The CMB holds the state of any task in such a way that it can be stopped and restarted. It is used for debugging as well as multi-tasking. Every F-C= PU
instruction is \textit{atomic} and can't be split, so we don't store any pa= rtial
result or temporary pipeline state into the CMB.

            A Contex= t Memory Block is divided into a variable number of
"slots" that are as wide as the CPU can support (ie, 64 bits for = a 64-bit
CPU). Each slot contains an individual global or special register.

The first 64 slots hold the contents of the normal "general"
registers. They are stored and restored by the Smooth Register Backup
mechanism. Since R0 is hardwired to 0, the corresponding slot (the first one) contains the instruction pointer.

The CMB holds the access rights and the most important protection
flags. The OS modifies the access rights of a task in the CMB because it can't do it directly in the special registers (which at this time store the=
OS's properties...). The most important flags are stored in the Machine Sta= tus Register
("MSR") : the size flags, the VMID, the capability flags...

The CMB holds the pointer to the task's page table (when paging
is enabled). This page table can be stored at the end of the CMB if the OS<= BR> decides to do so.

Two last slots are used for multitasking and debugging, in
conjunction with the SRB mechanism : the "next" and "time sl= ice" slots. The
"next" slot is a pointer to another CMB ; the task stored in the = CMB can
switch automatically to a new task, whose CMB is pointed to by the "ne= xt"
field. The "time slice" stores the number of clock cycles that th= e task can
execute before automatically switching to the "next" task.

This description is not exhaustive and the number of CMB slots
will increase in the future, as the needs and the architectures evolve. A certain number of Special Registers are dedicated to the CMB management.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~

It is a big structure of elements with MAX_SIZE bytes each.
the allocation the problem today but it should be straight-forward.
don't hesitate to ask. no time now, they shutdown the server...

> >>SRB is only a way to avoid to write the backup code (writing 6= 4
> >>registers takes 256 bytes of instructions and 512B of data...)= .
>
> I think until now i mixed up SR ( Special Register ) with SRB ( Smooth=
> Register Backup )!?
i have not remarked it yet.

> >> hmmm that's not exactly how i'd write it but i'm such an opti= misation freak ;-)
>
> im in doubt about doing optimizations before having something like a > reference, which is hopefully readable code doing whats intended.

well i try to think of reference code as also efficient code.
people tend to copy slow algorithms...

> >>  addr_log2=3Daddr_log ^ TLB[i].log_addr;
> >>    if ((addr_phys2 >> TLB[i].page_size)= =3D=3D0) {
>
> isnt it: if ( ( addr_log2 >> TLB[i].page_size ) =3D=3D 0 )?

ooops !

Carsten : 1 point.

> >>typedef struct TLB_entry {
> >>  u64 log_addr;
> >> [...]
>
> at least we have an definition - :-). i think, every element should us= e a
> type describing the size, so "unsigned int" and "int&qu= ot; is replaced by u32 ?
i had a file with definitions such as :

#define u8 unsigned char
#define i8   signed char
usw...

> >>POSIX compliant interface, that's all.
> So the mulator has to do some of the syscalls in native code!? Its lik= e the
> Java VM having native methods!?
it's a matter of interface.
it is simply how the emulator communicates with the HW.
if you start to access low-level features, it's already the end...
particularly on the PC HW.
it's just an advice : don't access the PC HW with the F-CPU !!

have fun,

> Best Regards,
> Carsten
YG

speaking for himself
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
=
www.
From Ben Franchuk Sun Feb 4 01:01:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01289 for ; Wed, 7 Feb 2001 00:54:40 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:40 +0100 (MET) Received: (qmail 6676 invoked by uid 0); 6 Feb 2001 17:32:57 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx21) with SMTP; 6 Feb 2001 17:32:57 -0000 X-eGroups-Return: sentto-1101623-2279-981480767-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 06 Feb 2001 17:32:52 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 17:32:46 -0000 Received: (qmail 40340 invoked from network); 6 Feb 2001 17:32:45 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 6 Feb 2001 17:32:45 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 6 Feb 2001 17:32:45 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA17131 for ; Tue, 6 Feb 2001 10:23:59 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7C9BCE.30196531@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <45.1f8cfe9.27b0ca6a@aol.com> <3A802A97.2EDFC4EA@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 17:01:18 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4f6f8bd61a61f9804333a3bc7aeda966 Status: R X-Status: N Yann GUIDON wrote:
> it is simply how the emulator communicates with the HW.
> if you start to access low-level features, it's already the end...
> particularly on the PC HW.
> it's just an advice : don't access the PC HW with the F-CPU !!

Anybody care to design high quality virtual I/O. :-)
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From Nicolas Boulay Tue Feb 6 21:44:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01331 for ; Wed, 7 Feb 2001 00:54:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:52 +0100 (MET) Received: (qmail 25451 invoked by uid 0); 6 Feb 2001 20:35:43 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx01) with SMTP; 6 Feb 2001 20:35:43 -0000 X-eGroups-Return: sentto-1101623-2280-981491691-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 06 Feb 2001 20:35:22 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 20:34:51 -0000 Received: (qmail 76912 invoked from network); 6 Feb 2001 20:34:50 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 Feb 2001 20:34:50 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 6 Feb 2001 21:35:55 -0000 Received: from ifrance.com (nas21-148.vlt.club-internet.fr [195.36.171.148]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA16185 for ; Tue, 6 Feb 2001 21:34:46 +0100 (MET) Message-ID: <3A80623D.1B2ECB6E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Feb 2001 21:44:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ae386d3ba9648cb0fac56b68ad4e838f Status: R X-Status: N Hello, some comment about the decoder.


"The current scheduler strictly requires fixed deterministic latency.
This is a pity. There are many cases when an execution unit may be able
to complete its computation in less than its maximum latency, and the
flexibility to do this would improve performance. "

- It's not true in the general case. Imagine your 4 times pipelined mul
unit. With your proposal you want to cut to 1 cycles if one of the
operande are zero. BUT how do you handle the value just befor and just
after. Most of the time, the pipeline will be full, so it's impossible
to shortcut it, because the others stage compute previous data. If could
never shortcut a pipeline, but you can split it, and you waste even more
area for a quite unusual cases and you need one more access to the
register bank.

As Whygee said, it could be useful to raise exeption here (like divide
by zero).

"Whichever way, it is clear that the Xbar can simply use this method to
ensure that there is no conflict on the Xbar's write ports due to
multiple simultaneous execution unit completions. At the same time,
execution units are free to complete early if they contain the necessary
optimisation logic and the operands allow it, and the OOOC does not just
reorder instruction execution based on execution unit latency, but also
based on dependencies between the instructions. This should all improve
performance, modularity and scalability of the design. More execution
units can easily be added or replaced with more/less efficient ones
depending on the
requirements of a particular F-CPU implementation."

- If you have write register conflict in your program, it's an horrible
scheduling problem create by the user (the program writter). And the
performance will suffer a lot. That's means that some instructions
finish in the same times. To quipe the coherency, you propose solutions,
but it doesn't speed up anything, it just try to be not too bad with
such poor designed program with a greate waste of area.

- Never forget that Out of order execution exist only to speed up OLD
binary in a new version of the core. It's made to use (for example) your
all new second mul unit for a program design for only one unit. But for
that you need to detect read-after-write depencies, and it cost a lot in
area !

- We design a all new core, why do you thinking of ooo like intel who
want to speed up 8088 code ?

- I propose to make design rules as :
        - How many decoder you wich
        - try to execute in the same times how many instructions is
possible (by using in the same times the differents units) so it will be
possible to add very easly new unit (but old code is not suppose to use
it very efficiently)
        - A tag system decide wich unit are used to distribute the
instruction to be executed.
        - A vliw bit could avoid using 6 bit comparator to detect RAW
depencies, that will be in the critical path, so here you can gain a
pipeline stage.
        - There is no ooo nether register renaming, 64 registers will be
fine.
        - direct memory access (like add [r1++] r2) could even decrease
pressure on the register bank, if the pipeline detect the ++ and didn't
wait that the register r1 will be write at the end of the instruction.
       
"The scoreboard"

- In fact i don't like it so much. It used only to prevent false
scheduling. Ok, but if you make your own scheduling, it could be much
more efficient to read the old valure rather than wait or duplicate the
value (more pressure on the register bank).

-imagine :
        mul r1 r2 r3 (write on r3 as usual, 3 ticks latency)
        add r4 r1 r1 (r1 is the old value, not update by the previous
instruction)
        add r5 r3 r2
        add r5 r1 r2  (here is the new r1 valure compute by the mul)
       
- So you can try to better hide some latency. But binary compatibility
will became horrible that's sure. And // execution will be even worse.
But maybe a "rescheduler" program could translate old binaries ? I know
that it will be difficult to avoid scoreboard.

- But With such scoreboard and without vliw bit, you can't really read
the register if it's modified by a previous instruction. So you will
decrease the efficiency of a // execution if you haven't the vliw bit,
which clearly said which packet could be run in the same time.


"3.2 STANDARD EXECUTION UNIT EXTERNAL VIEW"
"--[0:n] Opcodes [Optional]: Whatever sub-bits of the instruction opcode
are required by the execution unit to determine which flavour of
operation to perform"

- Hum, as it's written on the top of your page, you speak about the
decoder, so decoder send much more control bit DECODED from the opcode.
Unit should only compute, and decoding is made in the decode stage...

"It is important to realise that the execution unit is now a black box.
It can determine its own latency, be pipelined or not, and implement its
function however it wishes.
Externally the function is identical and the rest of the processor core
knows nothing about the internal implementation. Execution units are
then truly like LEGO bricks."

- Hum, you forget r2w2 instruction and all that kind of stuff. But you
add it at the end so you make an other possible unit interface.

"COMPRESSIBLE PIPELINE"
- A very good idea, if the pipeline have to make a lot of bubble. But we
don't have to forget that's not the usual case (and the use of the unit
are poor if the pipeline as a lot of bubble).

"3.5 FORKED PIPELINE"

- So you need,
        - an empty pipeline
        - a 2 to 1 64 bit multiplexer (big and slow)
       
- I think it uninterresting because if the programer have choosen not to
use this unit maybe some others units will be used to write to the
register bank. So your early completion port have to wait the end of
others cycles. And i think that most of the time it will be the normal
latency time of the unit ;p (as a program writer could imagine it in the
general case). So your bypass port will be useless.

- And never forget that an empty pipeline isn't a usual thing at all. If
it happenss, it's because other unit are intensely used and use every
write port on the register bank.

- Or as for TI DSP, use many port to the register bank (8 w 8 r for the
C6000), so you can't have stall anymore in the pipeline of your unit and
early completion have a sense.

"latches"

- In VHDL design, we never, never use latches !! Very few synthiser
could handles this very well (nether verfication program,...). You can
only use it for clock gating, that's all.

I think i should try to read the decoder version of Whygee, i think, i
could find lot of surprise, too.

nicO
Yahoo! Groups Sponsor

www.

From Carsten899@aol.com Tue Feb 6 21:35:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01334 for ; Wed, 7 Feb 2001 00:54:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:54 +0100 (MET) Received: (qmail 13440 invoked by uid 0); 6 Feb 2001 20:37:40 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx05) with SMTP; 6 Feb 2001 20:37:40 -0000 X-eGroups-Return: sentto-1101623-2281-981491745-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 06 Feb 2001 20:35:54 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 20:35:45 -0000 Received: (qmail 41308 invoked from network); 6 Feb 2001 20:35:43 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 6 Feb 2001 20:35:43 -0000 Received: from unknown (HELO imo-r11.mx.aol.com) (152.163.225.65) by mta3 with SMTP; 6 Feb 2001 21:36:47 -0000 Received: from Carsten899@aol.com by imo-r11.mx.aol.com (mail_out_v29.5.) id r.cc.105a6768 (4575) for ; Tue, 6 Feb 2001 15:35:19 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 15:35:19 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 38d6f7fc2aab15b146d3256be635c646 Status: R X-Status: N Today only one question:

>>IRQ/TRAP/FAULT/SYSCALL/whatever is "pointing the PC to somewhere else"
>>and saving the PC or PC+4 (depending on the case) to the CMB.

Does the F-CPU switch to the "next task" in the case of interrupt?
Yahoo! Groups Sponsor

www.  
From Ben Franchuk Sun Feb 4 04:24:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01343 for ; Wed, 7 Feb 2001 00:54:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:54:56 +0100 (MET) Received: (qmail 11649 invoked by uid 0); 6 Feb 2001 20:56:29 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx22) with SMTP; 6 Feb 2001 20:56:29 -0000 X-eGroups-Return: sentto-1101623-2282-981492967-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 06 Feb 2001 20:56:24 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 20:56:06 -0000 Received: (qmail 38323 invoked from network); 6 Feb 2001 20:56:05 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 Feb 2001 20:56:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 6 Feb 2001 21:57:09 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA27532 for ; Tue, 6 Feb 2001 13:47:29 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7CCB84.2311B0A@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <3A80623D.1B2ECB6E@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 20:24:52 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4f63bcbf5d4f14fac00d9360c0eea722 Status: R X-Status: N Nicolas Boulay wrote:
>
> Hello, some comment about the decoder.
>
> "The current scheduler strictly requires fixed deterministic latency.
> This is a pity. There are many cases when an execution unit may be able
> to complete its computation in less than its maximum latency, and the
> flexibility to do this would improve performance. "

Can one reorder the entire instruction
que around for the best scheduling before the decoder
as part of pre-fetching data?

Instruction pre-fetch-Que
[1]
[2]
[3]
...
[32?]
Instuction que
[2]
[4]
[1]
[3]
...
[19]
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.
From Michael Riepe Tue Feb 6 14:33:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01373 for ; Wed, 7 Feb 2001 00:55:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 00:55:09 +0100 (MET) Received: (qmail 6760 invoked by uid 0); 6 Feb 2001 23:46:30 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx18) with SMTP; 6 Feb 2001 23:46:30 -0000 X-eGroups-Return: sentto-1101623-2283-981502869-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 06 Feb 2001 23:41:14 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 23:41:08 -0000 Received: (qmail 12133 invoked from network); 6 Feb 2001 23:40:49 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 6 Feb 2001 23:40:49 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta1 with SMTP; 6 Feb 2001 23:40:39 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00522; Tue, 6 Feb 2001 14:33:55 +0100 Message-ID: <20010206143354.30859@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com>; from Hans Summers on Tue, Feb 06, 2001 at 09:45:57AM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 14:33:54 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 956402ed77e1fce6f28d209bd5aa358a Status: R X-Status: N On Tue, Feb 06, 2001 at 09:45:57AM -0000, Hans Summers wrote:
[...]
> > What about bypassing results from one EU to another?
>
> I thought about this a bit. But I don't know how bypassing is going to be
> arranged with the current scheme? I assume that whatever problems and
> solutions apply at the moment will apply to my scheme too. In the current
> design does bypassing eliminate the need for writing to a register at all,
> or is it just a way for a pending instruction to get at the data more
> quickly if it appears on the Xbar during result write? Overall I concluded
> that whatever problems would be faced in register bypassing would be the
> same in my design and the current one. My design doesn't address that issue,
> and I didn't think it makes it harder to solve.

Bypassing can do both -- forward data to another EU early, and write
to a register -- or skip the register write.  But it will not skip the
register write if the instruction explicitly says "write to register <n>"
-- because the CPU is unable to determine if the value in that register
is used afterwards.

[...]
> > IMHO an EU will always be `pipelined' -- there's at least one register at
> > the input and one at the output, and n (>= 0) between them.
>
> There doesn't necessisarily need to be a register at the output. If the
> final stage of the EU is considered to be latching the data into the Xbar
> for result write, the final pipeline register can (should) be omitted or it
> just wastes a cycle...

The input and output registers are not part of the EUs, but they
should be always there.

> By non-pipelined in this sense I mean an EU which is only capable of
> processing one instruction at a time. An iterative shift-add multiplier can
> only multiply two numbers at a time (one instruction). However many cycles
> of latency that takes can be counted with a binary counter, and the "data
> valid" bit enabled when the count is completed. In contrast a high
> performance (but large) parallel multiplier can be pipelined and be
> processing several consecutive instructions (multiplies) at a time in its
> pipeline. With my proposal a shift-add iterative multiplier could be
> replaced with a parallel multiplier transparently. Throughput would increase
> and latency may change, but elsewhere the processor would require no change.

Yep.  Full modularity is a Very Good Thing(tm).

[...]
> > Stalling complicates the pipelines, and also the instruction decoder
> > (because it has to check if a particular EU is stalled).  The necessary
> > clock enable lines may also affect the critical datapath.
>
> Stalling is going to be necessary even in the current design. It occurs
> anyway if the source registers for the instruction are not available (they
> are awaiting result write from a previous computing instruction). The
> instruction decoder checking if a particular execution unit is stalled is no
> different from checking if the source registers are available, and it will
> be done in parallel therefore not lengthening the critical datapath. As the
> current pipeline must also be stallable it will also require clock enable
> lines, so no change here.

In that case (source not available), the pipeline will NOT stall, it will
contain a `bubble', i.e. meaningless data that is ignored at the output.
With well-known latencies and a sufficiently smart instruction decoder,
there well be no collisions at the EU outputs either (i.e. the Xbar
will never have to delay the result write because there are too many
results available), so there's no reason to halt the pipelines at all.
Only the IF/ID unit will pause if the EUs aren't ready.

[...]
> > This sounds very nice, but a known latency has its advances, too.
> > If you know the latency of an instruction a priori, you can *statically*
> > schedule instructions (in the compiler) in order to optimize your code.
> > If EU latency is unknown, this becomes impossible (unless you issue
> > instructions out-of-order, which we currently don't).
>
> I agree that in an ideal world the compiler should know the instruction
> latency so it can optimise static scheduling. If code is run on different
> versions of the F-CPU having different execution units, it would need
> recompiling to get optimum scheduling, which is no problem. My proposal is
> not intended to replace compile-time optimisation, rather to augment it. In
> cases where code is not recompiled there would be some performance gain.

And performance loss in other cases.  I'd rather put the optimization
burden on the compiler, not the hardware.  After all, the F-CPU is a
RISC chip...

> There could also be data-dependent performance gain which is impossible to
> predict when the compiler does its instruction scheduling. In any event the
> maximum latency of an execution unit will still be known to the compiler.
> Just in some cases the processor may improve on the completion scheduling
> done by the compiler, or if the code was compiled for a different version,
> or if the data and pipeline contents allow lower latency. I believe this new
> design cannot have a LOWER performance than the current design, but can have
> HIGHER performance under some circumstances. I view it as a useful side
> effect rather than the main advantage of better modularity and simpler
> decoder/scheduler (no special cases e.g. Load/Store, divide; no large LUT to
> be maintained etc.).

Hmm... if an unexpected `early' result results (no pun) in a collision
at the Xbar, this is not a win, IMHO.

[compressible pipe]
> > Yep.  I've seen something similar in papers about TTA machines.
>
> Interesting. When I have time I am going to read some more about TTA. Again
> the compressible pipeline can only increase performance, never decrease it.
> The extra gates in the EU pipeline clock-enable are not in the CDP.

You're not proposing a `clock gate', are you?  That won't work
reliably (timing is too critical).

[...]
> > I'm afraid that there's no room for the multiplexers you need for
> > bypassing the later stages of the pipeline.  The pipeline stages of the
> > F-CPU are *very* short (6 gates / 10 transistors), and adding another
> > stage is not an option in most cases (most EUs are short, even IMUL
> > ist only 6 stages).
>
> I worry a little about making a pipeline state SO short it can do too little
> useful work. I wouldn't suggest adding an extra stage just for the sake of a
> multiplexer. But the multiplexer should only take 1 gate in the CDP. In some
> circumstances depending on the design and function of the EU it may be
> possible if the pipeline stage has room. It's again a side-effect of the
> main design, a posibility which can possibly be incorporated if desired. It
> would be invisible outside the "black box" execution unit.

In most EUs there will be no room in the pipeline.  At least not in the
units I wrote so far (ASU and IMU).

[...]
> > > Performance is improved by improving the OOOC (result prioritisation)
> and
> > > permitting interesting optimisation variants of the execution units
> > > (non-deterministic latency).
> >
> > Affects compile-time optimization.  And I just *hate* unpredictable
> > behaviour.
>
> As above. I don't think performance can be degraded, possibly it can be
> improved in some circumstances. Personally I rather like unpredictable
> behaviour! The whole F-CPU project is somewhat anarchistic and having a
> matching architecture seems to suit (unless it degrades performance,
> obviously). It's also somewhat novel. If I am in a minority then
> data-dependent optimisation could be discarded.

It's not novel at all -- unpredictable behaviour is Intel Style (tm).
Ever wondered why they didn't document the instruction timings for
Pentiums and later processors?  Because they couldn't calculate them
any longer.

Anarchy means freedom, but freedom is for people, not for machines.
Free Software developers may be anarchists, but their code is usually
well-organized, well-structured and not chaotic or unpredictable at all.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.
From Yann Guidon Wed Feb 7 01:00:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01874 for ; Wed, 7 Feb 2001 05:26:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:09 +0100 (MET) Received: (qmail 21874 invoked by uid 0); 6 Feb 2001 23:55:04 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx03) with SMTP; 6 Feb 2001 23:55:04 -0000 X-eGroups-Return: sentto-1101623-2286-981503696-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 06 Feb 2001 23:55:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 23:54:56 -0000 Received: (qmail 14366 invoked from network); 6 Feb 2001 23:54:55 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 6 Feb 2001 23:54:55 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 7 Feb 2001 00:56:00 -0000 Received: from f-cpu.org (nas2-233.ras.club-internet.fr [195.36.192.233]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA23745 for ; Wed, 7 Feb 2001 00:54:44 +0100 (MET) Message-ID: <3A80903B.32D629F4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <3A7D7606.FF8AFAC@ifrance.com> <3A7DED53.9D0B5FF0@f-cpu.org> <3A7F27AA.7AD574A1@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 01:00:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2698a79faed8c3ff3578dee260b63384 Status: R X-Status: N ooops i had not answered to this rant war :-P

Nicolas Boulay wrote:
> Yann Guidon a =E9crit :
> > hello,
> > quick&dirty answers,
> >
> > Nicolas Boulay wrote:
> > > Yann Guidon a =E9crit :
> > > > Marco Al wrote:
> > > > > From: "Ben Franchuk" <bfranchuk@jetne= t.ab.ca>
> > > > as long as it's "only" about a lookup table, = it's ok.
> > > > however, the latency/scheduling issue is more difficult= to solve.
> > > In Pentuim, all the unit have the same pipelined unit.
> > ???
> > could you be more precise ?
> > and what's the point ?
> Latency and scheduling is much more difficult in fcpu because you have=
> different latency units. For pentuim is easier, each unit are equal.
:-P that is the effect of using compilers ...

it is ONLY in the case when you use logic operations and add/shub/shift. load/store is presumably 1 cycle when there's a cache hit.

otherwise, ciao : you can't schedule ANYTHING at all. all you can do is
pack the instructions this way or another, depending on the CPU you use.
even though scheduling FC0 looks difficult for you, at least (tada !) you C= AN !

> > > > what's the point of having a very efficient CPU if the = binaries can't be reuse elsewhere ???
> > > That's a very strong point. But when you see intel problem w= ith IA64
> > > (they said that you will have to recompile your program for = the next
> > > generation),
> > you forget the last part of their declaration : "if you want= to run at full speed".
> > my goal is to maintain a relatively decent performance on as wide= a range
> > of applications as possible, with a minimal amount of rewriting.<= BR> > Look at what is written on emulator.com, the guy said that optimising<= BR> > PIII code could run 50% faster. There is no optimised PIII compiler. S= o
> to speed up code, recompiling is the best (+50 % for PIII !!).

hey you half-read what i wrote !

there are two cases :
- run the software at full speed : your raytracer, your DSP or MP3 decoder= , your MPEG player ...
- run untrusted SW compiled for another CPU version ...

get the point ?
in 1) you will certainly recompiler, in 2) you don't want to pray all the t= ime that
the SW won't execute a wrongly scheduled instruction that will cause the de= struction
of the CPU/the data/ etc... If you don't have the sources, you can't recomp= ile
and a "minimum" compatibility, even at the cost of emulation for = some "funky instructions",
will help.

> Imagine you use the rules :
> - interlaced instructions of differents units (with or without vliw bi= t).
>
> So you could (with a lot of decoder) try to launch as many instruction=
> as possible (vliw bit avoid to compare each Read After Write
> dependancies, i believe that PowerPc use more than 3000 5 bits
> comparator to do it...).

i'll try to show that your vliw bit is useless... using the model of the execution window. it should be generated internally by the CPU.

the OS could even replace the unsupported instructions with calls
to dynamically-generated routines that emulate the instruction.
it's halfway the TRANSMETA way :-)

> You optimise your code and use it. Then you add to your core some unit= s
> (1 add and one 1 mul, for example). Your code could speed up but a C > compiler could unroll more loops to speed up even more the execution. = So
> to really increase speed, you must recompile.

that is not the point. Provided the compiler can do a decent job,
recompiling an adapted code [i understand myself] with the right
flags can give decent speedups. sure.

one silly idea i had : to use the additional byte provided by ECC SDRAM
modules to store the dynamically-generated "vliw bits".


> > > we can't try to use the popularity of opensoftware and the > > > openess of the source code. Maybe an standard install will b= e a
> > > /configure and not rpm-something ;p
> > ? i don't understand...
>
> Easy : the standart way to put a program on a fcpu will be to recompil= e
> it each time. (specific architecture SR could write the size of the > register, of the cache memory, the number of each unit,... and the
> compiler could read them). So no need of (strong) binary compatibility= .

yup, but a "core" set of rules is necessary.

> > > So maybe a total binary compatibility isn't so interresting = to have.
> > total is impossible. But i mentioned a "minimal" compat= ibility.
> You could make a total compatibility, but it's possible not to increas= e
> the speed (for the same clock speed). Imagine that your core (fc1) has= 3
> adds units and 2 muls. If you use it without ooo, no speed up will
> occure (for the same clock speed). But after a recompiling, you could<= BR> > gain around 200 % speed up. If you try to produice code for fc0 as big=
> as for fc1, your code footprint will be much bigger, without any speed=
> improvement (for fc0).
>
> For closed source program, maybe we can use intermediat code (could RT= L
> in gcc, no ?)

i think that we speak about the same thing but on different topics ... ding= ue.
so we agree that a "core" of rules and instructions are necessary= .
we do platform-specific optimisations at wish as long as it is isolated
(the binary doesn't get out of the box).

> > the F-CPU ISA has "core" instructions. however the sche= duling was not the issue
> > because the strict rules of dependency that we find in usual code=
> > (instructions are executed in order etc) is preserved.
> > a scheme with "lost values" (like the example of the C6= x) would
> > be a catastrophe.
>
> Yes, but maybe "class" of unit could defined latencies. (2 o= r 3 types
> with a fixed rules). If you want different depth pipelined unit, how > would you keep the coherency ?

i don't see how this can help scheduling. the "class" you just de= fined
can be gotten with a table lookup... and more acurately.
i don't see how this can help the decoding since this table lookup can
be performed when the instruction is loaded into the Icache.

> If you have in fcn, 3 types of unit (1 clock latency (ex add), 3 (mul)= and 8 (fmul)).
> then in fc(n+1), your 3 types reach 2,7, and 20,  how would you m= anage it ?

? i hardly understand what you mean ... it is rather obscure to me ...
can you rephrase ? how would i manage what ?

> I repeat myself but with recompiling (C/C++ or GNL ;p ) no problem !!!=
> (and don't forget that with java, you only recompile the JVM)
sure but that was not the point.

any "complex" cpu can have a "failsafe" mode that execu= tes single-issue
scheduled code. if you want to enable the other pipelines, it's a matter of recompiling but the same binary must do the SAME THING on ANY CPU.
performance is another issue.

> > > > if it's HW, it's the best solution for me. there is no = compatibility and
> > > Best solution ? Translation is always translation, HW or SW = you have the
> > > same thing to do. But HW is much more complicated to write !=
> > not really...
> > it depends on the extent of the translation.
> >
> > until now, there were 2 issues : the change in the opcode value,<= BR> > > and the pipeline latency/instruction packing. there's nothing wor= th
> > a big change now. translation exists for CISC machines, whereas R= ISC
> > doesn't need much change.
>
> It's always easier in SW !

easier for what ?
if you spend 100K transistors to perform the translation
in the core, it can sometimes be better than using
10M transistors that store a translation SW in EEPROM or RAM.

and HW always runs faster.

> > > > > Marco
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
WHYGEE
Yahoo! Groups Spons= or
3D""3D""
www.= .c= om
3D""
From Yann Guidon Wed Feb 7 01:01:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01877 for ; Wed, 7 Feb 2001 05:26:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:12 +0100 (MET) Received: (qmail 21901 invoked by uid 0); 6 Feb 2001 23:55:17 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx01) with SMTP; 6 Feb 2001 23:55:17 -0000 X-eGroups-Return: sentto-1101623-2284-981503696-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 06 Feb 2001 23:55:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 23:54:55 -0000 Received: (qmail 49728 invoked from network); 6 Feb 2001 23:54:54 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 Feb 2001 23:54:54 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 7 Feb 2001 00:55:59 -0000 Received: from f-cpu.org (nas2-233.ras.club-internet.fr [195.36.192.233]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08306 for ; Wed, 7 Feb 2001 00:54:50 +0100 (MET) Message-ID: <3A809040.8A1CA7D6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 01:01:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c8db0538b0391ee629a0c4e4bf807d9b Status: R X-Status: N hi,

Carsten899@aol.com wrote:
> Today only one question:
> >>IRQ/TRAP/FAULT/SYSCALL/whatever is "pointing the PC to somewhere else"
> >>and saving the PC or PC+4 (depending on the case) to the CMB.
>
> Does the F-CPU switch to the "next task" in the case of interrupt?

depends.
"next task" is only when the core can do automatic switching between CMBs.

when there is a IRQ, a trap or a syscall, it is however to ask the OS
to do something. It enters in kernel mode, which can then switch
to another CMB if it wants to execute "unsecure stuff".

as said earlier, going to kernel mode avoids to trigger a
useless page fault and thrash the TLB at the same time (the L1 cache
is often thrashed a bit already).

going to "next task" is in the special case of the core being
able to switch from one task to another when a very specific signal
is triggered (by a counter).


off topic :
mmmm by the way, your data structure that holds the register set
etc in you emulator is almost close to the CMB. you need to store
different informations, backup some particular SRs etc but i don't
remember the details.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www..com
From Yann Guidon Wed Feb 7 01:01:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01880 for ; Wed, 7 Feb 2001 05:26:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:13 +0100 (MET) Received: (qmail 31733 invoked by uid 0); 6 Feb 2001 23:57:49 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx15) with SMTP; 6 Feb 2001 23:57:49 -0000 X-eGroups-Return: sentto-1101623-2285-981503696-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 06 Feb 2001 23:55:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 23:54:56 -0000 Received: (qmail 23957 invoked from network); 6 Feb 2001 23:54:55 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 6 Feb 2001 23:54:55 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 7 Feb 2001 00:55:59 -0000 Received: from f-cpu.org (nas2-233.ras.club-internet.fr [195.36.192.233]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA28719 for ; Wed, 7 Feb 2001 00:54:50 +0100 (MET) Message-ID: <3A809043.7E56E316@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <3A80623D.1B2ECB6E@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 01:01:07 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 26bc7b36440d8c8f5974ef85f0e50ef8 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Hello, some comment about the decoder.
<snip>

> I think i should try to read the decoder version of Whygee, i think, i
> could find lot of surprise, too.
there is no such unverifiable thing as an unfinished thing ;-)

in fact i'm now laying as much as i can on paper but that takes some time.
i hope to finish as soon as possible because i have to make the drawings
for the EPF presentation. i am making the VHDL version, available online at
http://www.f-cpu.de/epf2001/
there you can find my most recent (though very generic !) writing
about the scheduler.

About the scoreboard :
i was considering to drop it for the first version of the FC0 but...
i forgot that the SRB needed the specifically encoded (bitfield) version.

i have started to compare the cost of usual scoreboard (big decoder and
big OR) and the "comparator everywhere" solution (more usual : each FIFO stage
compares its value with those from the current instruction ; this makes
9*2*3=54 6-bit comparators). unfortunately i can't compare the cost
because i can't evaluate this of the old good scoreboard. it is mixed with
the register decoding and the condition decoding....

scoreboard/condition/register read :
there are 3 * 6->64 decoders.
i had started long ago to see what decoder organisation to use :
2*3 or 3*2 decoders. 2*3 : it makes 2 * 8 wires, 3*2 makes 3 * 4 wires.
If we want to simplify/speedup the decoder (and reduce the fanout)
we have to double this number with negated values.
This makes 24 wires with a fanout of 32. Multiplied by 3 (3 registers).
72 wires, each feeding 32 * 3-input and (nand ...) gates.

<!--
Hey NicO, take a look at your dear books and seek a good memory line decoder ...
i'm sure that you can give us a good lesson :-D
-->

The output of the gate enable the selection of an individual register (line)
on an individual port. It also sends a lot of informations that are ORed
with big 63-input OR gates :
* register is busy
* MSB
* LSB
* zero (itself the result of a 8 * 8 or, with 8 /latched/ partial results)

this constitutes the "decoder" part.
some other parts are forgotten in the description :
- BUSY flag for the div unit
- the "express" request for the late load instructions
- the optional programmable LUT for the size (in 128+ bit systems)
- the "cache" that associates a register number to a fetcher/LSU line (16 * 6-b compare)
   with the "present/absent" output bit
- und ich vergesse noch andere dinge....

i hope that a clean version will be ready. this design is getting old,
it dates from more than one year :-) however it is being very slowly defined.

i hope this helps. please ask questions.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.
From Ben Franchuk Sun Feb 4 05:08:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01886 for ; Wed, 7 Feb 2001 05:26:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:15 +0100 (MET) Received: (qmail 22357 invoked by uid 0); 7 Feb 2001 00:29:55 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx05) with SMTP; 7 Feb 2001 00:29:55 -0000 X-eGroups-Return: sentto-1101623-2287-981505777-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hi.egroups.com with NNFMP; 07 Feb 2001 00:29:40 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 7 Feb 2001 00:29:36 -0000 Received: (qmail 35883 invoked from network); 7 Feb 2001 00:29:36 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 Feb 2001 00:29:36 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 7 Feb 2001 00:29:32 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA07934 for ; Tue, 6 Feb 2001 17:20:53 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7CD5AE.F8D349F6@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <3A7D7606.FF8AFAC@ifrance.com> <3A7DED53.9D0B5FF0@f-cpu.org> <3A7F27AA.7AD574A1@ifrance.com> <3A80903B.32D629F4@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 21:08:14 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d0714e49812544743cd10f7ce3adea06 Status: R X-Status: N Yann Guidon wrote:
> there are two cases :
>  - run the software at full speed : your raytracer, your DSP or MP3 decoder, your MPEG player ...
>  - run untrusted SW compiled for another CPU version ...

Hey I run Linux-X under F-CPU... You mean I have to recompile
to run the G-CPU or H-CPU.
Does it really matter what code the compiler generates,
as the Unit that pre-processes the pre-fetch cache for out of order execution
is going to shuffle things around anyhow for the best execution.
As long as the opcodes are correct things will allways run at full speed.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From Michael Riepe Wed Feb 7 01:42:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01889 for ; Wed, 7 Feb 2001 05:26:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:16 +0100 (MET) Received: (qmail 20893 invoked by uid 0); 7 Feb 2001 00:43:06 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx22) with SMTP; 7 Feb 2001 00:43:06 -0000 X-eGroups-Return: sentto-1101623-2288-981506576-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 07 Feb 2001 00:43:03 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 7 Feb 2001 00:42:55 -0000 Received: (qmail 33860 invoked from network); 7 Feb 2001 00:42:54 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 7 Feb 2001 00:42:54 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.200) by mta1 with SMTP; 7 Feb 2001 00:42:52 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03745; Wed, 7 Feb 2001 01:42:48 +0100 Message-ID: <20010207014248.61669@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C1@po1-exch.lon.tudor.com> <20010205193939.47886@thrai.stud.uni-hannover.de> <3A7C3EBE.7376271F@jetnet.ab.ca> <20010206024547.30412@thrai.stud.uni-hannover.de> <3A7C8D43.70B7145B@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A7C8D43.70B7145B@jetnet.ab.ca>; from Ben Franchuk on Sat, Feb 03, 2001 at 03:59:15PM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Feb 2001 01:42:48 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6f4e6e278753582df3d3b9918700e36f Status: R X-Status: N On Sat, Feb 03, 2001 at 03:59:15PM -0700, Ben Franchuk wrote:
> Michael Riepe wrote:
> > We're on the hardware side here... there is no compiler.
> What is done is to re-map from a register-control flow
> information set to a pipeline/alu's flow in real time.
> Score boards and other tricks can't look ahead several
> instructions to tell if a variable is live or dead, to tell
> if address calculated needs to be saved or not after being used.

That's done during compilation (dataflow analysis).
Doing it in hardware would be a mess...

In general, a program should not calculate values it doesn't need
(unless it wants to spend some time twiddling thumbs, e.g. in a delay
loop).  Every value is at least used once, and even if it is bypassed,
it is also stored in the destination register (at the same time).  The
CPU just has to find out whether bypassing is possible, and do it.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Sun Feb 4 05:33:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01892 for ; Wed, 7 Feb 2001 05:26:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:17 +0100 (MET) Received: (qmail 5555 invoked by uid 0); 7 Feb 2001 00:55:21 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx01) with SMTP; 7 Feb 2001 00:55:21 -0000 X-eGroups-Return: sentto-1101623-2289-981507317-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 07 Feb 2001 00:55:19 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 7 Feb 2001 00:55:16 -0000 Received: (qmail 1683 invoked from network); 7 Feb 2001 00:55:15 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 Feb 2001 00:55:15 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 7 Feb 2001 00:55:14 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA09329 for ; Tue, 6 Feb 2001 17:46:20 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7CDBA6.48D17ECA@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <20010206143354.30859@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Feb 2001 21:33:42 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cbb28532dd3d2fd5fff03f48277d0ba0 Status: R X-Status: N Michael Riepe wrote:
> Bypassing can do both -- forward data to another EU early, and write
> to a register -- or skip the register write.  But it will not skip the
> register write if the instruction explicitly says "write to register <n>"
> -- because the CPU is unable to determine if the value in that register
> is used afterwards.

This is exactly why the compiler needs to pass data flow hints
to state if a variable is 'dead' or a address register is 'finished'
at that point in time to the cpu.


> And performance loss in other cases.  I'd rather put the optimization
> burden on the compiler, not the hardware.  After all, the F-CPU is a
> RISC chip...

Risk chip did you say :-).
With the massive amount of internal pipelining and muitiable processing units
the RISC view point is not valid from a internal view point. Steamlined
yes, RISC I don't know. ( Note I don't take computer science as gospel)


> It's not novel at all -- unpredictable behaviour is Intel Style (tm).
> Ever wondered why they didn't document the instruction timings for
> Pentiums and later processors?  Because they couldn't calculate them
> any longer.

I always thought it was because the timing is so bad they did
not want to admit them. Nobody ever told you how long it took to fetch
the pre-fetch que.

> Anarchy means freedom, but freedom is for people, not for machines.
> Free Software developers may be anarchists, but their code is usually
> well-organized, well-structured and not chaotic or unpredictable at all.

      ***** Long live INTERCAL ****


-:)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
So why are you here --- go find some Women instead :-)
Ben.
They comments here are made while waiting for supper so they
may represent hunger induced figments of my imagination
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
From EE Times Wed Feb 7 01:56:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01895 for ; Wed, 7 Feb 2001 05:26:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:18 +0100 (MET) Received: (qmail 24880 invoked by uid 0); 7 Feb 2001 00:56:41 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx05) with SMTP; 7 Feb 2001 00:56:41 -0000 X-eGroups-Return: sentto-1101623-2290-981507387-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 07 Feb 2001 00:56:31 -0000 X-Sender: webuser@cmpweb-mail.web.cerf.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 00:56:27 -0000 Received: (qmail 94087 invoked from network); 7 Feb 2001 00:56:26 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 7 Feb 2001 00:56:26 -0000 Received: from unknown (HELO cmpweb-dns0.web.cerf.net) (192.215.71.99) by mta2 with SMTP; 7 Feb 2001 00:56:26 -0000 Received: from cmpweb-prod1.web.cerf.net (cmpweb-prod1.web.cerf.net [192.215.71.72]) by cmpweb-dns0.web.cerf.net (8.9.3/8.9.3) with ESMTP id QAA27355 for ; Tue, 6 Feb 2001 16:56:25 -0800 (PST) Received: (from webuser@localhost) by cmpweb-prod1.web.cerf.net (8.8.8+Sun/8.8.8) id QAA22109 for f-cpu@egroups.com; Tue, 6 Feb 2001 16:56:24 -0800 (PST) Message-Id: <200102070056.QAA22109@cmpweb-prod1.web.cerf.net> To: f-cpu@yahoogroups.com X-eGroups-From: EE Times From: EE Times MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 16:56:24 -0800 (PST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] EE Times Article Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 149c614e61fa27cd2430c083ebde6d8d Status: R X-Status: N This article from http://www.eet.com was sent to you by allen@digitalharmony.com

allen@digitalharmony.com says: This weeks EE-Times has an interesting Article:

"Free Cores Marching into Market"

-Allen

Momentum builds for open-source processors
http://www.eet.com/story/OEG20010201S0050

LONDON &#151; Momentum is slowly building for freely available
open-source processors, the semiconductor equivalent of open-source
software movements like Linux.

A handful of commercial efforts are experimenting with open-source
CPU cores. Contract-manufacturing giant Flextronics, for example, is
laying plans to tap into open-source hardware for its ASICs. And both
Metaflow Technologies Inc. (La Jolla, Calif.) and IROC Technologies
SA (Grenoble, France) are building products using the Leon-1, a
Sparc-like open-source processor developed at the European Space
Agency's Technology Center.

Meanwhile, free cores for Bluetooth and the USB 2.0 interface could
become available later this year, open-source developers said.

But the movement has its detractors. "Licensees won't be able to go
back to the source" &#151; that is, the engineer who created the
design. "That was what killed IP [intellectual-property] core
brokerage in the 1990s," said Luke Collins, a principal semiconductor
analyst at market research firm Gartner Dataquest (Egham, England).

And even EDA companies like Cadence, which is enabling this
grass-roots movement by freely licensing tools such as NC-Sim to
enthusiasts, believe the free-cores effort is marginal at the moment.
"To be honest, there's little attention paid by the silicon vendors
to these [open-source] blocks," said Adam Sherer, director of system-
and functional-verification IP management at Cadence Design Systems
Inc. (San Jose, Calif.).

Nevertheless, say backers, open-source software has scored a dazzling
success in Linux, the open-source version of Unix that has swept into
the software industry like the Santa Ana winds. Why not open-source
cores?

"Open-source IP is a new idea," said Lior Shtram, an ASIC design
manager with Flextronics Semiconductor Inc. in Israel. "In the short
term, this concept will have to mature, in terms of studying how to
create reliable, well-documented and supported IP using this
approach. [But] open-source software has gone through a similar
process and nowadays offers remarkable results."

Indeed, Flextronics is intrigued enough to consider taking a chance
on turning selected cores into ASICs. Shtram said the company is
meeting with representatives from the OpenCores organization, a loose
but global affiliation of hobbyists, students and young professional
engineers, with an eye toward taking some of the hardware cores its
members design to silicon.

Indifferent collaborators

Enabled by the Internet revolution, OpenCores accomplishes much of
its work in e-mail reflectors, chat rooms and newsgroups and through
individuals using university or shareware EDA tools. Many of the
designers don't know or care where their collaborators are based.
Other open-source hardware projects exist as well, with home bases in
Europe, Japan and the United States, although the open-source
movement is probably strongest in Europe, where Linux too has its
roots.

A step-up in activity over the last year has sparked development of a
multitude of open-source cores and ignited industry buzz as the
concept wends its way to the world of commercial production.

Late last year Metaflow and IROC announced they were using the
European Space Agency's open-source processor Leon-1 in a
system-on-chip (SoC) platform and a demonstration vehicle,
respectively. Metaflow, a subsidiary of STMicroelectronics Inc., uses
Leon as the heart of an SoC development system called Implosion,
which it launched in December. And Leon-1 is the basis of IROC
Technologies' ROC-S81 32-bit RISC processor, designed to protect
space-borne electronics systems from soft errors.

Leon was designed for the space agency's ERC32 platform for space
electronics by Jiri Gaisler, who has just left his job at the
agency's Technology Center in Noordwijk, Netherlands. ERC32 is based
on a commercial Sparc 32-bit processor in packaged-chip form. But
because the agency knew it would need to embed Sparc RISC processors
in SoCs, it opted to develop its own hardware core.

To help increase the availability of development tools, operating
systems and application software &#151; and thereby reduce its own
costs &#151; the Technology Center, called Estec, decided to spread
the architecture widely by making it available under an open-source
agreement. The result is Leon-1, an implementation of the IEEE's
proposed P1754 standard for a Sparc V8 microprocessor. Leon-1 source
code is distributed under the GNU Lesser General Public License;
links to the source code, software and other developer's resources
can be found at the Estec Web site.

Leon-1 evolved throughout 2000 and has reportedly been implemented in
several FPGA projects by enthusiasts around the world. "Leon-1 2.2
now has Amba AHB and APB on-chip buses," said Gaisler, referring to
the ARM Ltd. microprocessor buses. "This makes it very much simpler
to add peripherals."

Gaisler, whose new company, Gaisler Research (Goteborg, Sweden), will
provide consulting services to the European Space Agency on the ERC32
project, said that "five or six FPGA versions [of Leon-1] have been
built already," emphasizing one of the advantages of open-source:
that multiple developers can share debugging costs and build
confidence in the functional integrity of the source code.

Moreover, said Gaisler, "We're expecting samples of the Leon 2.1-FT
in February." This fault-tolerant version is being built in a
0.35-micron CMOS process at Atmel Corp.'s foundry at Rousset, France.
Gaisler said the designation "FT" indicates the design has been
augmented with European Space Agency fault-tolerance structures
intended to make commercial CMOS fit to sustain radiation effects, in
order to allow SoC deployment in space.

As for the commercial uses of Leon-1, Gaisler described Metaflow's
implementation "as an ARM [processor-core] replacement. Rather than
paying a lot of money to ARM you get a core for free &#151; but you
have to be prepared to spend a lot of your own engineering time on
it," he cautioned.

IROC, meanwhile, is awaiting silicon for its Leon-based
implementation from an unidentified foundry in the next few weeks.
IROC adds protective circuitry for both logic and memories, a
strategy the company claimed is unique, to guard against
cosmic-radiation-induced soft errors, crosstalk effects and even
signal-timing errors, said Michael Nicolaidis, chief technology
officer.

Free demo

He said IROC picked the Leon as a demonstration vehicle because it
was freely available. The company now intends to apply the scheme to
other processors, he said, and has a contract to add its form of
robustness to a 16-bit microcontroller. IROC has also started
negotiations on licensing the ROC-S81, Nicolaidis said.

Perhaps a bigger coup for the open-source core movement is the
potential backing of Flextronics Semiconductor (Sunnyvale, Calif.).
That company is looking to mine some of the cores, working or in
development, generated by the OpenCores developers as the possible
basis for ASICs. The group's Web site lists everything from 32- and
8-bit RISC cores through cryptography devices to standard
peripherals, I/O controllers and memories. Usually the OpenCores
designers are restricted to blowing their designs into FPGAs, since
it's all they can afford.

"We've certainly taken a look at OpenCores," said Ralph Waggitt, vice
president of marketing at Flextronics Semiconductor, a company known
for its ability to retarget FPGAs to ASIC technology. Formerly called
Orbit Semiconductor, it is a subsidiary of Flextronics International
Ltd., a manufacturing-services company based in Singapore.

Open reservations

"We're not in the IP business," Waggitt said. "We're in the silicon
business and we have some reservations. We're trying to understand
how OpenCores works and what the responsibilities and liabilities
might be." 

Shtram said the OpenCores project would likely involve providing a
number of development tools to individual OpenCores designers, and
also supplying engineering time to prepare the cores for manufacture.


"We're talking about a one-year schedule," said Shtram. "We
understand that just taking [cores directly] from OpenCores will not
work; much hard work should be put in in order to enable the creation
of reliable, tested and supported IP within this framework. And we
are ready to put that effort and those resources into the project."

Flextronics intends to "identify interesting cores within the group,
and support the development process of these cores with funds, work
and a test ASIC," Shtram said. "In this way developers within
OpenCores could achieve working silicon that implements their IP, and
we achieve the experience needed to create a working ASIC using the
IP and a demonstration ASIC to show our customers."

Shtram would like to see more companies sign on to explore the
possibilities inherent in the open-core movement. "At this stage more
companies joining this game will add their experience and help the
speed of the maturing process," said Shtram. "It's a good place to
have cooperation. We wouldn't want to be the only player. It would be
good if other companies would get involved."

Barriers to success

But analyst Collins is among those who foresee business problems for
any companies setting foot in open-source terrain. "Building a
business model around a core which is not your own and from which you
are decoupled by one or more layers is going to raise the barriers to
success," Collins said.

Though the idea of obtaining a core for free might be appealing,
Collins pointed out that the cost of a major SoC project usually far
exceeds the cost of licensing intellectual property, once you figure
in engineering time and mask sets that cost up to half a million
dollars for deep-submicron silicon. In his view, it is not worth
jeopardizing a project for the small amount saved on a free core that
comes with no reliable warranties and nobody to sue if things go
wrong.

Indeed, one open-source developer, Rudolf Usselmann, adds heavy
disclaimers to the designs he posts on the OpenCores site, along the
lines of "I have no idea if implementing this core will or will not
violate patents, copyrights or cause any other type of lawsuits. I
provide this core as is, without any warranties."

Of course, if all one needs is a processor and a C compiler &#151;
perhaps to build a system in an FPGA &#151; then an open-source core
might be just the ticket, argued Usselmann, who spent 15 years
working in Silicon Valley before entering semiretirement in his
mid-30s. Usselmann has developed an 8-bit data, 12-bit instruction
word microcontroller compatible with the PIC16C57 from Microchip
Technologies Inc. (Chandler, Ariz.) and several crypto-processor
cores. Usselmann makes the source code available for the PIC-like
device.

A former Sun Microsystems Inc. designer, Usselmann said he developed
his PIC core "as an exercise for myself &#151; I did the whole thing
in about one night." He said he is now working on a USB 2.0-compliant
interface core.

Usselmann praised the OpenCores group for its freewheeling
atmosphere. "Being an open organization, we don't have marketing and
management people forcing their ideas on us," he said. "We can let
our imaginations fly and do some neat things."

Another designer tinkering with open cores is Jamil Khatib, by day an
electronics designer for Siemens ICT (Rammala, Palestine) but on his
own time active in the open-source community. Khatib said he began
looking for free hardware cores on the Internet while still a
university student in the mid-1990s and, when he couldn't find any,
started writing and publishing his own.

"My first project was a FIFO," he said. "Why shouldn't we have
generic hardware, not just for CPUs but all sorts of hardware?"

Khatib later worked on the Freedom-CPU, a 64-bit superpipelined RISC
microprocessor that is being developed by a team united in a
coalition that describes itself as "a bunch of people that speak
about CPU design on a mailing list where the owner has disappeared."
The University of Paris is one hot spot of Freedom-CPU activity, and
much of the impetus for the ambitious 64-bit processor design comes
>from European engineers.

F-CPU has just released VHDL and support files for the ROP2 execution
unit that is at the heart of this single-instruction, multiple-data
(SIMD) device. But there are still many more building blocks to be
designed, and therefore a great deal of testing to be done.

Far to close

"This is a problem. It is very hard to get a group to close [a
design]," said Khatib. "Sometimes it's just easier for one person to
work at something, make the decisions and get it done. I've just
started work on a Bluetooth baseband core like that."

Whether lone wolf or part of a design team, core developers need EDA
tools to bring their designs to fruition. Sherer at Cadence confirmed
that his company has made a limited number of NC-Sim licenses
available at no cost or at heavily discounted charges to OpenCores
and made a similar offer to the Freedom-CPU group.

"Cadence has been operating as an IP facilitator in the market for
some time," Sherer said. "OpenCores is an interesting case. It's an
open-source environment that was looking to move to a more
sophisticated tool set. So we've provided NC-Sim and VHDL packaging
tools."

Sherer said Cadence viewed these groups as similar to educational
establishments, and not as competitors to its mainstream customers.

"There's a big gap between developing and delivering a complete
virtual component and developing a simulation model," he said. "To
get an IP core into the market is not that large an effort. You get
hold of a specification for something and develop the core. But it's
a very large gap to get from there to providing a tier-one company
with a core, which is where the revenue is."

In Sherer's view, there's good reason to provide such groups with EDA
tools for a company like Cadence that wants to keep its finger on the
pulse of the industry. Even if the particular cores an open-source
group is working on today do not prove to be significant, he said,
the individuals involved could move on to bigger things. Like Linux
developers before them, they could turn into next-generation
entrepreneurs with an impact in setting standards in the IP-cores
community.

Sherer wants these maverick engineers to be familiar with Cadence and
to help make Cadence EDA tools the standard in the IP community.



For more technology news, visit http://www.eet.com
Yahoo! Groups Sponsor
www..com
From "Allen Goldstein" Wed Feb 7 02:02:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01898 for ; Wed, 7 Feb 2001 05:26:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 05:26:21 +0100 (MET) Received: (qmail 30448 invoked by uid 0); 7 Feb 2001 00:59:39 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx02) with SMTP; 7 Feb 2001 00:59:39 -0000 X-eGroups-Return: sentto-1101623-2291-981507572-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fg.egroups.com with NNFMP; 07 Feb 2001 00:59:34 -0000 X-Sender: allen@digitalharmony.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_2_1); 7 Feb 2001 00:59:32 -0000 Received: (qmail 68899 invoked from network); 7 Feb 2001 00:59:30 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 7 Feb 2001 00:59:30 -0000 Received: from unknown (HELO pulse.digitalharmony.com) (216.39.145.40) by mta2 with SMTP; 7 Feb 2001 00:59:30 -0000 Received: (qmail 5926 invoked by uid 504); 7 Feb 2001 00:59:29 -0000 Received: from allen@digitalharmony.com by pulse.digitalharmony.com with qmail-scanner-0.93 (. Clean. Processed in 4.0396 secs); 06/02/2001 16:59:25 Received: from unknown (HELO allen) (216.39.145.40) by 192.168.0.139 with SMTP; 7 Feb 2001 00:59:24 -0000 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200102070056.QAA22109@cmpweb-prod1.web.cerf.net> From: "Allen Goldstein" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Feb 2001 17:02:16 -0800 Reply-To: f-cpu@yahoogroups.com Subject: Sorry RE: [f-cpu] EE Times Article Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: aaaabb1eb7e5b690df2ed3834f1cb46c Status: R X-Status: N Guys:

Sorry for the long message, I thought the web page was going
to just send a link, not the whole bleeding article!

-Allen

> -----Original Message-----
> From: EE Times [mailto:webuser@cmpweb-mail.web.cerf.net]
> Sent: Tuesday, February 06, 2001 4:56 PM
> To: f-cpu@yahoogroups.com
> Subject: [f-cpu] EE Times Article
>
>
> This article from http://www.eet.com was sent to
> you by allen@digitalharmony.com
>
> allen@digitalharmony.com says: This weeks
> EE-Times has an interesting Article:
>
> "Free Cores Marching into Market"
>
> -Allen
>
> Momentum builds for open-source processors
> http://www.eet.com/story/OEG20010201S0050
> >
Yahoo! Groups Sponsor
www..com
From Carsten899@aol.com Wed Feb 7 06:10:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00315 for ; Wed, 7 Feb 2001 17:46:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 17:46:54 +0100 (MET) Received: (qmail 17054 invoked by uid 0); 7 Feb 2001 05:10:38 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx15) with SMTP; 7 Feb 2001 05:10:38 -0000 X-eGroups-Return: sentto-1101623-2292-981522636-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 07 Feb 2001 05:10:37 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 05:10:35 -0000 Received: (qmail 18130 invoked from network); 7 Feb 2001 05:10:34 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 7 Feb 2001 05:10:34 -0000 Received: from unknown (HELO imo-d07.mx.aol.com) (205.188.157.39) by mta2 with SMTP; 7 Feb 2001 05:10:34 -0000 Received: from Carsten899@aol.com by imo-d07.mx.aol.com (mail_out_v29.5.) id r.8f.691b5c7 (4357) for ; Wed, 7 Feb 2001 00:10:29 -0500 (EST) Message-ID: <8f.691b5c7.27b232c4@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Feb 2001 00:10:28 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b42773d8d36839e3d728cd4883abd9b0 Status: R X-Status: N Am right with the following descriptions of my view in my own words?

In the case of interrupt/syscall/fault and "forgetting" about SRB the FCPU
simply saves its PC, R1-R63 into the CMB. Now its in the state "execption"
and cant process further syscalls/faults or interrupts. On RTE execution it
restores the registers to the contents of the CMB and continues operation.

With SRB the change is as following: In "non-exception"-state the SRB is off.
The FCPU simply marks written registers during "non-exception"-mode "dirty",
nothing else happens.
In the case of interrupt/syscall/fault the SRB is "activated".  While in 
"exception-state" the FCPU checks every register write operation. If it tries
to write a "dirty" register i does not overwrite the content, but holds the
execution of the write operation until the current content of the dirty
register is stored into the current CMB. Now the new contents are written.
Somewhere is a bit "Reg-Is-Saved-In-CMB" which remembers that this register
is stored in the CMB. On RTE the "Reg-Is-Saved-In-CMB bits are checked and
the registers restored. The dirty bit is set again ( because the register was
dirty before exception the bit has to remain dirty )

When will it every be cleared? The chapter 4.3. describes SRB in the case of
a task switch,. In the case of a task switch the dirty bit will be cleared
after transferring the dirty bit into "must write"-bit. is this same
behaviour in the case of interrupt/fault/syscall?

Doesnt the following happen, if the SRB operates on tasks as in chapter 4.3
described. We have the tasks A, B, C, D

old_task = A
current_task = B

taskswitch occurrs -> transfer dirty into "must-save" (example: all registers
are dirty)

[[does the FCPU load register content from task C now from CMB( task_C) ? ]]

old_task = B
current_task = C

loadcons.x FFFF,r1      ; SRB stores contents of  R1( task_b ) into old_task
cmb
                        ; dirty( R1) set
loadcons.x FFFF,r2      ; SRB stores contents of  R2( task_b ) into old_task
cmb
                        ; dirty( R2) set

interrupt -> transfer dirty into "must-save" (example: all registers are
dirty)
. attention! "must save bits" from task_b would be lost(!) if intterupt does
not block!

interrupt handler starts executing.

carsten
Yahoo! Groups Sponsor

www.   
From Yann GUIDON Wed Feb 7 12:29:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00372 for ; Wed, 7 Feb 2001 17:47:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 17:47:08 +0100 (MET) Received: (qmail 12221 invoked by uid 0); 7 Feb 2001 11:36:20 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx18) with SMTP; 7 Feb 2001 11:36:20 -0000 X-eGroups-Return: sentto-1101623-2293-981545778-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 07 Feb 2001 11:36:19 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 11:36:17 -0000 Received: (qmail 10474 invoked from network); 7 Feb 2001 11:36:15 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 7 Feb 2001 11:36:15 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 7 Feb 2001 11:36:15 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA03172; Wed, 7 Feb 2001 03:36:13 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWSZV; Wed, 7 Feb 2001 11:41:13 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A8131AB.1897F9BA@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 12:29:47 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 14f4e2e65324dfa1592c33b6316fa518 Status: R X-Status: N hello !

i don't have much time to answer extensively :-(

> Am right with the following descriptions of my view in my own words?
>
> In the case of interrupt/syscall/fault and "forgetting" about SRB the FCPU
> simply saves its PC, R1-R63 into the CMB.
R0 is not saved, but i don't remember what was saved in this slot.
should it be the PC or the Machine Status Register ?

> Now its in the state "execption"
> and cant process further syscalls/faults or interrupts. On RTE execution it
> restores the registers to the contents of the CMB and continues operation.

well IRQs are off if it's not a syscall,
and a TRAP can be triggered in case of a major fault
(ECC or whatever goes wrong...).

> With SRB the change is as following: In "non-exception"-state the SRB is off.
"SRB is off" ? what do you mean ?

> The FCPU simply marks written registers during "non-exception"-mode "dirty",
> nothing else happens.
yup.

> In the case of interrupt/syscall/fault the SRB is "activated".
ok i get it now. "off"...

>  While in 
> "exception-state" the FCPU checks every register write operation. If it tries
> to write a "dirty" register i does not overwrite the content, but holds the
> execution of the write operation until the current content of the dirty
> register is stored into the current CMB. Now the new contents are written.
> Somewhere is a bit "Reg-Is-Saved-In-CMB" which remembers that this register
> is stored in the CMB. On RTE the "Reg-Is-Saved-In-CMB bits are checked and
> the registers restored. The dirty bit is set again ( because the register was
> dirty before exception the bit has to remain dirty )
wow :-) you understood the description of the SRB :-)

however at your level, it doesn't have much impact.

> When will it every be cleared?
what ? the dirty bit ?

> The chapter 4.3. describes SRB in the case of
> a task switch,. In the case of a task switch the dirty bit will be cleared
> after transferring the dirty bit into "must write"-bit. is this same
> behaviour in the case of interrupt/fault/syscall?
well i have to remember the whole context but IIRC it's quite similar.

> Doesnt the following happen, if the SRB operates on tasks as in chapter 4.3
> described. We have the tasks A, B, C, D
>
> old_task = A
> current_task = B
>
> taskswitch occurrs -> transfer dirty into "must-save" (example: all registers
> are dirty)
>
> [[does the FCPU load register content from task C now from CMB( task_C) ? ]]
what you write is not very clear for me.
i interpret it as : the current_task SR is loaded with the address of the next CMB,
stored in CMB[B].next_task. this should be OK IIRC.

however, "old" and "current" are from the SRB point of view :
"old" is being flushed away while "current" starts to be executed.
SRB was first meant to reduce IRQ latency, not task switch,
however nothing keeps us from using it (at your own risks :-D)

> old_task = B
> current_task = C

that is during a switch.

> loadcons.x FFFF,r1      ; SRB stores contents of  R1( task_b ) into old_task cmb
>                         ; dirty( R1) set
> loadcons.x FFFF,r2      ; SRB stores contents of  R2( task_b ) into old_task cmb
>                         ; dirty( R2) set
>
> interrupt -> transfer dirty into "must-save" (example: all registers are dirty)
>  attention! "must save bits" from task_b would be lost(!) if intterupt does not block!

SRB doesn't end before all "dirty" registers are saved.
if an IRQ occurs, it is blocked?delayed until SRB is finished.
SRB will restart with new "dirty bits" and the IRQ handler will start
as soon as some registers are ready.

> interrupt handler starts executing.
>
> carsten

maybe i'm not awake, or i can't read, but i don't get the sense of your questions ...

all in all, it's mostly a lot of good sense,
in the end it never goes against the benefit of performance unless it is specified
and justified. have fun :-)

YG

speaking for himself
Yahoo! Groups Sponsor

www.
From Carsten899@aol.com Wed Feb 7 18:19:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00528 for ; Wed, 7 Feb 2001 18:25:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 18:25:16 +0100 (MET) Received: (qmail 29712 invoked by uid 0); 7 Feb 2001 17:21:34 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx18) with SMTP; 7 Feb 2001 17:21:34 -0000 X-eGroups-Return: sentto-1101623-2294-981566443-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 07 Feb 2001 17:20:45 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 17:20:42 -0000 Received: (qmail 5446 invoked from network); 7 Feb 2001 17:19:55 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 7 Feb 2001 17:19:55 -0000 Received: from unknown (HELO imo-r18.mx.aol.com) (152.163.225.72) by mta3 with SMTP; 7 Feb 2001 18:21:00 -0000 Received: from Carsten899@aol.com by imo-r18.mx.aol.com (mail_out_v29.5.) id r.a2.fcaa55a (4229) for ; Wed, 7 Feb 2001 12:19:44 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Feb 2001 12:19:43 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f90bea148f752567480693e568daf68d Status: R X-Status: N
>> In the case of interrupt/syscall/fault and "forgetting" about SRB the FCPU
>> simply saves its PC, R1-R63 into the CMB.
>R0 is not saved, but i don't remember what was saved in this slot.
>should it be the PC or the Machine Status Register ?

okay. lets write it down. Its PC and R1 to R63.

>>well IRQs are off if it's not a syscall,

okay. does this mean IRQs are enabled during execution of a syscall?

am i right with the following point of view: If there is a IRQ or a syscall
or a fault, the FCPU stores the PC to the CMB? Executing the RTE instruction
loads the PC from the CMB and execution of the interrupted task continues?

>SRB doesn't end before all "dirty" registers are saved.
>if an IRQ occurs, it is blocked?delayed until SRB is finished.
>SRB will restart with new "dirty bits" and the IRQ handler will start
>as soon as some registers are ready.

okay. lets write it down.

>>maybe i'm not awake, or i can't read, but i don't get the sense of your
questions

i try to figuring out,

- what the FCPU does in detail (so it can be coded) if an IRQ occurrs

- what the SYSCALL instructions does in detail (so it can be coded).

- what a fault, like pagefault, invalidinstruction, does in detail ( so it
can be coded ).

I am describing my current point of view and want the people here to comment
on it, tell me if my point of view is right or wrong,  because they thought
about the FCPU much longer.

Carsten
Yahoo! Groups Sponsor
From Yann GUIDON Wed Feb 7 19:42:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00883 for ; Wed, 7 Feb 2001 21:21:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 21:21:58 +0100 (MET) Received: (qmail 24467 invoked by uid 0); 7 Feb 2001 18:49:59 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx03) with SMTP; 7 Feb 2001 18:49:59 -0000 X-eGroups-Return: sentto-1101623-2295-981571795-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 07 Feb 2001 18:49:57 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 18:49:55 -0000 Received: (qmail 11663 invoked from network); 7 Feb 2001 18:48:51 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 Feb 2001 18:48:51 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 7 Feb 2001 18:48:51 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA27449; Wed, 7 Feb 2001 10:48:45 -0800 (PST) Received: from mentor.com (137.202.46.19 [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWTPS; Wed, 7 Feb 2001 18:53:42 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A819703.99B9CA28@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 19:42:11 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ac0c71de2ec6eb7127a27d6614d0d603 Status: R X-Status: N hello,

Carsten899@aol.com wrote:
> >> In the case of interrupt/syscall/fault and "forgetting" about SRB the FCPU
> >> simply saves its PC, R1-R63 into the CMB.
> >R0 is not saved, but i don't remember what was saved in this slot.
> >should it be the PC or the Machine Status Register ?
> okay. lets write it down. Its PC and R1 to R63.

well ... i don't want to break the CMB structure but it "would" be
preferrable to have : PC, MSR and finally r1 to 63.
the problem is the "+1" when accessing a register.
however, when the CMB is read, it doesn't fragment the memory access pattern
anymore. i think that the memory fetch issue can be more important than
a INC here and there...

> >>well IRQs are off if it's not a syscall,
> okay. does this mean IRQs are enabled during execution of a syscall?
only.

> am i right with the following point of view: If there is a IRQ or a syscall
> or a fault, the FCPU stores the PC to the CMB? Executing the RTE instruction
> loads the PC from the CMB and execution of the interrupted task continues?
this sounds logical to me :-)

> >>maybe i'm not awake, or i can't read, but i don't get the sense of your
> questions
>
> i try to figuring out,
>
> - what the FCPU does in detail (so it can be coded) if an IRQ occurrs
that could be useful, indeed... :-)

> - what the SYSCALL instructions does in detail (so it can be coded).
it's like a TRAP (error) : go to kernel (at a location determined by the
call number + current content of SR_SYSCALL_BASE) but :
- IRQs are still on (so the user doesn't cripple the OS with repeated
   system calls, the IRQs from keyboard still pass to type CTRL+ALT+SUPPR :P)
- the time counter for the current task is still counting (same as above :
   system + user time ... not overlaoding the system etc).
looks like a user task will need 2 CMB : 1 for user and another for kernel mode :-/
there should be a solution, like : not saving the registers at all, so if
an IRQ occurs, it is still stored in the user's CMB. Since the CMBs should
all be stored in a protected region of memory, there is no security issue
(the user task shouldn't tweak its own CMB ...)

> - what a fault, like pagefault, invalidinstruction, does in detail ( so it
> can be coded ).

current PC is saved to CMB (not PC+4) and the usual string of events :
* SRB
* fetch of instructions
etc...


> I am describing my current point of view and want the people here to comment
> on it, tell me if my point of view is right or wrong,  because they thought
> about the FCPU much longer.

well you seem to have got the good POV until now, anybody having coded
some protected CPU should understand how the F-CPU behaves. Unless noted,
there should be no black magic :-)

> Carsten

YG

speaking for himself
Yahoo! Groups Sponsor
www. .com 
From Nicolas Boulay Wed Feb 7 21:28:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00898 for ; Wed, 7 Feb 2001 21:22:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 21:22:01 +0100 (MET) Received: (qmail 7390 invoked by uid 0); 7 Feb 2001 20:19:04 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx01) with SMTP; 7 Feb 2001 20:19:04 -0000 X-eGroups-Return: sentto-1101623-2296-981577139-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 07 Feb 2001 20:19:03 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 20:18:59 -0000 Received: (qmail 94070 invoked from network); 7 Feb 2001 20:18:58 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 Feb 2001 20:18:58 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 7 Feb 2001 20:18:58 -0000 Received: from ifrance.com (nas20-159.vlt.club-internet.fr [195.36.170.159]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA11453 for ; Wed, 7 Feb 2001 21:18:46 +0100 (MET) Message-ID: <3A81B00A.EAAE75F4@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A76C749.7F001803@mentor.com> <3A75FD95.DDF206F5@ifrance.com> <3A77F549.43B444C9@mentor.com> <3A78A112.5875648@ifrance.com> <003101c08be6$d820a190$29e65982@student.utwente.nl> <3A79F076.2BD26DF7@ifrance.com> <001a01c08caf$f150be60$29e65982@student.utwente.nl> <3A7B33F3.3BA966E@ifrance.com> <3A75917C.9114DF0F@jetnet.ab.ca> <002001c08dd8$6283efc0$29e65982@student.utwente.nl> <3A7C7081.FE3638CC@f-cpu.org> <3A7D7606.FF8AFAC@ifrance.com> <3A7DED53.9D0B5FF0@f-cpu.org> <3A7F27AA.7AD574A1@ifrance.com> <3A80903B.32D629F4@f-cpu.org> <3A7CD5AE.F8D349F6@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 21:28:58 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Submission update : last but not least Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 0c6f9e77426523193672f4171c478c9e Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> Yann Guidon wrote:
> > there are two cases :
> >  - run the software at full speed : your raytracer, your DSP= or MP3 decoder, your MPEG player ...
> >  - run untrusted SW compiled for another CPU version ...
>
> Hey I run Linux-X under F-CPU... You mean I have to recompile
> to run the G-CPU or H-CPU.
> Does it really matter what code the compiler generates,
> as the Unit that pre-processes the pre-fetch cache for out of order ex= ecution
> is going to shuffle things around anyhow for the best execution.
> As long as the opcodes are correct things will allways run at full spe= ed.

Absolutely not !
Imagine having 2 mul unit for your new core but your old code only pack
1 mul per instructions...

nicO

> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>

=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www. =
=0D
3D""
From Nicolas Boulay Wed Feb 7 21:29:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00901 for ; Wed, 7 Feb 2001 21:22:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Feb 2001 21:22:02 +0100 (MET) Received: (qmail 24768 invoked by uid 0); 7 Feb 2001 20:19:41 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx13) with SMTP; 7 Feb 2001 20:19:41 -0000 X-eGroups-Return: sentto-1101623-2297-981577169-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mw.egroups.com with NNFMP; 07 Feb 2001 20:19:30 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 20:19:29 -0000 Received: (qmail 76273 invoked from network); 7 Feb 2001 20:19:28 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 7 Feb 2001 20:19:28 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 7 Feb 2001 20:19:28 -0000 Received: from ifrance.com (nas20-159.vlt.club-internet.fr [195.36.170.159]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA18488 for ; Wed, 7 Feb 2001 21:19:22 +0100 (MET) Message-ID: <3A81B025.8C54AD4B@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <3A80623D.1B2ECB6E@ifrance.com> <3A7CCB84.2311B0A@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 21:29:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal and // code Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a3e537581771d7088d78270cda741db4 Status: R X-Status: N Hello,

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> >
> > Hello, some comment about the decoder.
> >
> > "The current scheduler strictly requires fixed deterministic= latency.
> > This is a pity. There are many cases when an execution unit may b= e able
> > to complete its computation in less than its maximum latency, and= the
> > flexibility to do this would improve performance. "
>

this is quoted from the scheduler paper...

> Can one reorder the entire instruction
> que around for the best scheduling before the decoder
> as part of pre-fetching data?
>
> Instruction pre-fetch-Que
> [1]
> [2]
> [3]
> ...
> [32?]
> Instuction que
> [2]
> [4]
> [1]
> [3]
> ...
> [19]
But why do you want to do that !!!!!!! You think that the compiler is so stupid to scramble the instructions ;p

OOO is only to speed up old binary !

The problem are // execution (it's almost the same thing as OOO).

You need to detect depencies and not only RAW (read after write) but WAR and WAW !
imagine such code :
a =3D 1
b =3D a + 2
a =3D 3
c =3D a + e
There is a depencies on the a register. It's a false one because, it's
WAW (write after write) so you could use an other register instead :
a =3D 1
b =3D a + 2
a' =3D 3
c  =3D a' + e
So you have to have to do register renaming... or serialise the
execution (so no speed up).
And then you could execute :
a =3D 1 || a'=3D 3
b =3D a + 2  || c =3D a' + e
And have to change the order of the code...
Fcpu use 64 registers, to make such change we need a udge windows code.
And 64 register are suppose to be enought to avoid such case. But if you run your code in //, you have to verify if some ASM beginner hasn't
write a stupid code. What a waste of silicon for a so rare cases !

It try to find a way to code this kind of dependancies inside the
instruction. It could be a way to avoid using hundred of comparator to
do it. But you have to write depencies for all following instruction :
it's much too big !!

So the best way is to explicit write what could be //, no need to find
the // inside the code.

Look at current processor they could compute 4 sometimes 6 instructions
in the time (9 for Merced) that not so much. And think that kind of udge beast have around 100 millions transistors ! Most of the time only to
find what could be speed up ! Sound stupid, no ?

So i came back to the vliw bit (a following instruction with an equal
vliw bit COULD be execute in the same time). I know that theoreticaly
it's a redondant information but it's so hard to calcul (~50 millions
transistors in last beast ?).

a =3D 1 || a'=3D 3
b =3D a + 2  || c =3D a' + e
became :
            vliw bit
loadi a 1       (0)
loadi a2 3       (0)
addi b a 2       (1)
add c a2 e       (1)

Easy for compute code ! but what happen to test code ?

a =3D 1
if (a < 0)
{ b =3D a + 2
a =3D 3}
c =3D a + e

It could be see as a distributive operation so you could write :

a =3D 1
if (a < 0) { b =3D a + 2 }
if (a < 0) { a =3D 3 }
c =3D a + e

So, p is a boolean :
a =3D 1
p =3D a < 0
if (p) { b =3D a + 2 }
if (p) { a =3D 3 }
c =3D a + e

and in //
a =3D 1 || p =3D a < 0
if (p) { b =3D a + 2 } || if (p) { a =3D 3 }
c =3D a + e

Nice stuff, no ? We just rediscover the use of binary predicat.

Vliw studies find an other way :
a =3D 1
if (a < 0)
{ b =3D a + 2
f =3D 3}
c =3D a + e

became :
a =3D 1
if (a < 0)
{ b =3D a + 2
f =3D 3
c =3D a + e
}
else
{ c =3D a + e }

in //
a =3D 1
if (a < 0)
{ b =3D a + 2 || f =3D 3 || c =3D a + e
}else
{ c =3D a + e }

You extand the if clause to fill all the slot of the vliw processor, and you can combine it with predicat.


So how to make a good processor exectuting // code :

- use the vliw bit to simply know what could be run in //
      -> no register renaming, no ooo, no compa= rator but same speed...

- More decoder than the number of unit (that could be launch in //) so
each unit need a true access to the register bank (usualy a write and 2
read) (so the access to the register bank is a part of the unit like in
every others processors). So there is a lot of decoder, so keep it
simple...
- We has to decide if you could detect or not wrong vliw bit (using in
// the same unit not duplicated ).
If the detecte is made you could run your code in every fcxx, if not you save a pipeline stage (and raise an exception when it occure)...
- you use a scoreboard to keep a the binary compatibility, to avoid
scheduling problem if the latency changes. The scoreboard will be 64*1
bit register bank with 1 write + 2 read (or more) access port, to put a
flag about the use. It is accessed before the launch of the compute
unit. So here, the unpredictable latency of a read is handel.
A part : this scoreboard seems to me to put more constraint on the use
the register bank but i couldn't find any example, about that.
- so the coding rules is "to pack" instructions according to the = unit
used in the core. Each core have some SR to describe this (for the
compiler ;p)
- The bank of 8 decoders eats 8 instructions at a time.
imagine 8 decoders, i just write the vliw bit and the adress of the
instruction (+ the offset)
@0 +      1  2  3  4  5  = 6  7  8
vliw      0  0  0  0  0  = 1  1  1
so the 5 first instructions are decoded in //
Then you keep the last 3 instructions :
@8 +       1  2  3  4  5 (@0 += ) 6  7  8
      1  0  0  1  1  = ;      1  1  1
So here you can execute 4 instructions (@0 + 6, +7, +8 and @8 +1)
@16 +       1 (@8 +)  2  3  4 = 5 (@8 +) 6  7  8
      1       &= nbsp; 0  0  1  1        1=   1  1
So 2 3 could be run.
@16 +       1 (@16 +)  2  3 (@8 +) = 4  5 (@8 +) 6  7  8
      1       &= nbsp;  1  0         1&nbs= p; 1        1  1  1
here 1 2 4 5 6 7 8  could be executed in //
@24 +       1   2  (@16 + ) 3 (@16 = +)  4  5  6  7  8
      1   1     = ;      0       =    0  0  0  0  0
here 3 4 5 6 7 8
USW ! (etc...)

So you need 8 registers to store 8 instructions (worst case when all
instruction could not be run in //).

Adding new unit is very easy to this kind of decoder but // must be
explicit. I think that a specific "pack" instruction cost too muc= h (and
introduice microcode inside the decoder to save states). What is a vliw
bit : 1 bit compare to 32-48 bits (1/32 in worst case, 1/48 in the
best). A pack instruction is needed for each 8 instructions so 1/8 of
the code is lost. And don't forget that the pack instruction could add
one more cycle to be understood (i don't imagine to pack "a pack"=
instruction : what happen in case of jump ? )

I just have to better describe how to manage jump, and i think it's
complete.

nicO

> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>

Yahoo! Groups Spons= or
=
3D""3D""
= www. .com <= input type=3D"submit" name=3D"Submit" value=3D"Go!">
3D""
From Michael Riepe Wed Feb 7 14:53:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00321 for ; Thu, 8 Feb 2001 18:55:51 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:55:51 +0100 (MET) Received: (qmail 17221 invoked by uid 0); 7 Feb 2001 22:23:06 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx18) with SMTP; 7 Feb 2001 22:23:06 -0000 X-eGroups-Return: sentto-1101623-2298-981584583-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 07 Feb 2001 22:23:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 22:23:03 -0000 Received: (qmail 39060 invoked from network); 7 Feb 2001 22:23:01 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 7 Feb 2001 22:23:01 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.63) by mta3 with SMTP; 7 Feb 2001 23:24:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00622; Wed, 7 Feb 2001 14:53:53 +0100 Message-ID: <20010207145352.64109@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A8131AB.1897F9BA@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A8131AB.1897F9BA@mentor.com>; from Yann GUIDON on Wed, Feb 07, 2001 at 12:29:47PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Feb 2001 14:53:52 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 051d972370137d1ec1ae4e949cd2c4d3 Status: R X-Status: N On Wed, Feb 07, 2001 at 12:29:47PM +0100, Yann GUIDON wrote:
[CMB]
> > Am right with the following descriptions of my view in my own words?
> >
> > In the case of interrupt/syscall/fault and "forgetting" about SRB the FCPU
> > simply saves its PC, R1-R63 into the CMB.
> R0 is not saved, but i don't remember what was saved in this slot.
> should it be the PC or the Machine Status Register ?

It's reserved for the OS implementor, according to the manual.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.
From Michael Riepe Wed Feb 7 14:48:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAB00324 for ; Thu, 8 Feb 2001 18:55:52 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:55:52 +0100 (MET) Received: (qmail 25093 invoked by uid 0); 7 Feb 2001 22:26:04 -0000 Received: from mw.egroups.com (208.50.144.94) by 10.1.4.112 (mx12) with SMTP; 7 Feb 2001 22:26:04 -0000 X-eGroups-Return: sentto-1101623-2299-981584602-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 07 Feb 2001 22:23:25 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 22:23:22 -0000 Received: (qmail 30599 invoked from network); 7 Feb 2001 22:23:19 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 7 Feb 2001 22:23:19 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.63) by mta3 with SMTP; 7 Feb 2001 23:24:16 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00602; Wed, 7 Feb 2001 14:48:13 +0100 Message-ID: <20010207144813.49564@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <8f.691b5c7.27b232c4@aol.com> X-Mailer: Mutt 0.84e In-Reply-To: <8f.691b5c7.27b232c4@aol.com>; from Carsten899@aol.com on Wed, Feb 07, 2001 at 12:10:28AM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 7 Feb 2001 14:48:13 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ba809999e4728c49378967ea9291f89b Status: R X-Status: N On Wed, Feb 07, 2001 at 12:10:28AM -0500, Carsten899@aol.com wrote:
[...]
> In the case of interrupt/syscall/fault the SRB is "activated".  While in 
> "exception-state" the FCPU checks every register write operation. If it tries
> to write a "dirty" register i does not overwrite the content, but holds the
> execution of the write operation until the current content of the dirty
> register is stored into the current CMB. Now the new contents are written.
> Somewhere is a bit "Reg-Is-Saved-In-CMB" which remembers that this register
> is stored in the CMB. On RTE the "Reg-Is-Saved-In-CMB bits are checked and
> the registers restored. The dirty bit is set again ( because the register was
> dirty before exception the bit has to remain dirty )

The register is saved in the CMB of the old execution context (the one
the CPU just left) -- that means it isn't dirty any longer when the SRB
restores it after RTE.  It also means that the register doesn't have to
be saved again when another exception occurs (unless it has been changed
again after RTE).

> Doesnt the following happen, if the SRB operates on tasks as in chapter 4.3
> described. We have the tasks A, B, C, D
>
> old_task = A
> current_task = B
>
> taskswitch occurrs -> transfer dirty into "must-save" (example: all registers
> are dirty)
>
> [[does the FCPU load register content from task C now from CMB( task_C) ? ]]
>
> old_task = B
> current_task = C
>
> loadcons.x FFFF,r1      ; SRB stores contents of  R1( task_b ) into old_task
> cmb
>                         ; dirty( R1) set
> loadcons.x FFFF,r2      ; SRB stores contents of  R2( task_b ) into old_task
> cmb
>                         ; dirty( R2) set
>
> interrupt -> transfer dirty into "must-save" (example: all registers are
> dirty)
> . attention! "must save bits" from task_b would be lost(!) if intterupt does
> not block!

Difficult case.  I'd say, R1 and R2 are dirty in task C and need to be
saved in C's CMB, while some of the other registers may still have to
be saved to B's CMB (if there is still an SRB in progress from the last
task switch).

That is, the `dirty' bits should be ORed with the `must-save' bits,
and there should be an indication which CMB the register has to be
written to.  This also means that several instances of SRB may be active
at the same time?!

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.
From Yann Guidon Thu Feb 8 00:57:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00348 for ; Thu, 8 Feb 2001 18:55:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:55:58 +0100 (MET) Received: (qmail 26700 invoked by uid 0); 7 Feb 2001 23:51:35 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx15) with SMTP; 7 Feb 2001 23:51:34 -0000 X-eGroups-Return: sentto-1101623-2300-981589889-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 07 Feb 2001 23:51:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 7 Feb 2001 23:51:28 -0000 Received: (qmail 7579 invoked from network); 7 Feb 2001 23:51:27 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 7 Feb 2001 23:51:27 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 8 Feb 2001 00:52:32 -0000 Received: from f-cpu.org (nas2-211.ras.club-internet.fr [195.36.192.211]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29054 for ; Thu, 8 Feb 2001 00:51:24 +0100 (MET) Message-ID: <3A81E0F9.CD03A9BE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A8131AB.1897F9BA@mentor.com> <20010207145352.64109@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 00:57:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b4905c374928cd56425471f1fae857de Status: R X-Status: N hi !

Michael Riepe wrote:
> On Wed, Feb 07, 2001 at 12:29:47PM +0100, Yann GUIDON wrote:
> [CMB]
> > > Am right with the following descriptions of my view in my ow= n words?
> > >
> > > In the case of interrupt/syscall/fault and "forgetting&= quot; about SRB the FCPU
> > > simply saves its PC, R1-R63 into the CMB.
> > R0 is not saved, but i don't remember what was saved in this slot= .
> > should it be the PC or the Machine Status Register ?
>
> It's reserved for the OS implementor, according to the manual.

it was an old rant of mine, i want"ed" to store linked list data = there...

Now, i am more concerned by the memory problems (access order etc) and
i think that PC should be first, followed by the Machine Status Register that indicates the most important access rights for the executing code.
Then come the registers.

In the case where ie PC is in slot 0 and MSR@64, the memory interface
to the SDRAM (most likely to store the data in the most critical case)
will have to issue 2 addresses. However, if they are packed together,
the PC, MSR and Regs will be contained in a single long burst.

As for the alignment... Maybe we can specify that the CMB is not aligned on a 64*8 byte boundary, but 8 bytes below, so the registers appear
at a "normal/natural" address... old hack... i'm such a freak ;-)=

At one point or another, the kernel will have to deal with page alignment in regard to the SDRAM structure and line width, so another RAS
(Raw Address Strobe) is not needed. Correct alignment is important because<= BR> the SRB will access the registers potentially out of order (depending on the needs of the newly created task) and we can't recompute all the address=
for each register. If the value is available at a given address, aligned to 512 bytes, bits 3 to 8 will directly indicate the register number...


<in another mail :>
> Difficult case.  I'd say, R1 and R2 are dirty in task C and need = to be
> saved in C's CMB, while some of the other registers may still have to<= BR> > be saved to B's CMB (if there is still an SRB in progress from the las= t
> task switch).
>
> That is, the `dirty' bits should be ORed with the `must-save' bits, > and there should be an indication which CMB the register has to be
> written to.  This also means that several instances of SRB may be= active
> at the same time?!

n=F6 :-/

"SRB is atomic" : it terminates completely before it restarts. it can't be interrupted or be reentering, otherwise you see the troubles it creates... i think that i spoke about that in the manual.
just like in the rest of the pipeline i have tried to avoid potentially
"dangerous" situations, whether it is dangerous for the chip or f= or its
scalability.


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS only good news of the day :
now i don't work on fridays and i have more time to do other things,
like finally cut my hair, find a new appartment or maybe one day ...
update the manual ? write GNL ? update the VHDL code base ? ...
... clean my mail archive ? ...
Yahoo! Groups Spons= or
3D""
Grab the opportunity to market your company. Choose the dom= ain name below and press GO!
www.
3D"Y=
3D""
From Ben Franchuk Sun Feb 4 15:05:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00354 for ; Thu, 8 Feb 2001 18:55:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:00 +0100 (MET) Received: (qmail 1875 invoked by uid 0); 8 Feb 2001 00:24:59 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx21) with SMTP; 8 Feb 2001 00:24:59 -0000 X-eGroups-Return: sentto-1101623-2301-981591864-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 08 Feb 2001 00:24:28 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 00:24:22 -0000 Received: (qmail 66659 invoked from network); 8 Feb 2001 00:24:21 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 8 Feb 2001 00:24:21 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 8 Feb 2001 01:25:22 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA03210 for ; Wed, 7 Feb 2001 17:15:26 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7D61A5.E075F043@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <3A80623D.1B2ECB6E@ifrance.com> <3A7CCB84.2311B0A@jetnet.ab.ca> <3A81B025.8C54AD4B@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 07:05:25 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal and // code Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3bb492f46f61b3489ca9e1e9b6fab26f Status: R X-Status: N Nicolas Boulay wrote:
>
> Hello,
>
> Ben Franchuk a =E9crit :
> But why do you want to do that !!!!!!! You think that the compiler is = so
> stupid to scramble the instructions ;p

Yes  ... Not scrambled just not optimized. 
Now what is '//'

> OOO is only to speed up old binary !
>
> The problem are // execution (it's almost the same thing as OOO).
>
> You need to detect depencies and not only RAW (read after write) but W= AR
> and WAW !
> imagine such code :

> a =3D 1
> b =3D a + 2
> a =3D 3
> c =3D a + e
<cut>
In many cases like that example often a register 'a' holds a short
term variable. This variable is dead. That to a scheduler is very important= .

> It try to find a way to code this kind of dependancies inside the
> instruction. It could be a way to avoid using hundred of comparator to=
> do it. But you have to write depencies for all following instruction :=
> it's much too big !!

Funny I only need to look at the few opcodes held in the pipeline.

> So the best way is to explicit write what could be //, no need to find=
> the // inside the code.
>
> Look at current processor they could compute 4 sometimes 6 instruction= s
> in the time (9 for Merced) that not so much. And think that kind of ud= ge
> beast have around 100 millions transistors ! Most of the time only to<= BR> > find what could be speed up ! Sound stupid, no ?

yes because 99% of the time computer programs are SERIAL.
"if(a<2) Foobar()" can't be speeded up by adding more processo= rs.

Having more processors to run more threads is a better idea
providing you don't use up all the memory bandwidth.

> So i came back to the vliw bit (a following instruction with an equal<= BR> > vliw bit COULD be execute in the same time). I know that theoreticaly<= BR> > it's a redondant information but it's so hard to calcul (~50 millions<= BR> > transistors in last beast ?).

<cut>
> A pack instruction is needed for each 8 instructions so 1/8 of
> the code is lost. And don't forget that the pack instruction could add=
> one more cycle to be understood (i don't imagine to pack "a pack&= quot;
> instruction : what happen in case of jump ? )
Good luck with the pack bit.
Ben.

-----
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
=
www.
From Hans Summers Thu Feb 8 09:17:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00366 for ; Thu, 8 Feb 2001 18:56:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:02 +0100 (MET) Received: (qmail 22075 invoked by uid 0); 8 Feb 2001 08:17:28 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx22) with SMTP; 8 Feb 2001 08:17:28 -0000 X-eGroups-Return: sentto-1101623-2302-981620245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 08 Feb 2001 08:17:26 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 08:17:24 -0000 Received: (qmail 19018 invoked from network); 8 Feb 2001 08:17:24 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 8 Feb 2001 08:17:24 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 8 Feb 2001 08:17:24 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id DAA23555 for ; Thu, 8 Feb 2001 03:15:19 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id DAA16566 for ; Thu, 8 Feb 2001 03:17:22 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Feb 2001 08:17:22 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5DC@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 08:17:14 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 280409c2c3b40d10cce1ed834e76f2f1 Status: R X-Status: N
Hello

> -----Original Message-----
> From: Yann GUIDON [mailto:whygee@f-cpu.org]
> Sent: 06 February 2001 15:11
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> Hans Summers wrote:
> >
> > Hello.
> >
> > I read the F-CPU manual. The architecture looks good, OOOC
> is nice and I
> > particularly liked the SRB. Eventually on seul.org I came
> across draft
> > 0.2.2, and read about the scheduler (Part IV chapter 3)
> document p.ps dated
> > 14-Jan-01. This I didn't like so here I propose an
> alternative solution. It
> > also enables a precise definition of the external view of
> any execution unit
> > (see recent mail list thread). There are some diagrams
> which together with
> > this text I have placed on this page:
> > http://www.HansSummers.com/computers/fcpu/scheduler.htm
> >
> > -------------------
> > Hans Summers
> > http://www.HansSummers.com
> >
>
> Hi !
>
> like promised, i have carefully read this document and i
> regret that Hans
> didn't join the project two years ago :-) Some of his ideas
> could have made
> it in the current core. maybe he will help for FC1 ?
>
> However, despite a lot of interesting ideas, his proposal is
> incomplete
> and has some major flaws (to my eyes, because i don't know if
> others saw them).
>
> first, there is the "efficiency" of the method that remembers where to
> write the registers. let's take the theoretical case :
> we have 64 registers (well, 63, but that's not an issue) so
> AT ANY TIME
> we can't have more than 64 instructions in the pipeline. that's
> the maximum : we therefore don't need more than 6*64 bits (384 FF).
> Any method requiring more is under-efficient.
> The "FIFO" idea is a compromise and to me it appears to be efficient
> (to my eyes). The design of a scheduler and particularly for FC0
> asks questions of the way data are encoded. should it be bit fields
> or binary encoded ? where to put the data ? Is the data
> available differently
> somewhere else ? FIFO is efficient because all the needed
> data is available
> at the same place and time. no duplication is necessary and
> no overhead.
> We can make several comparisons on on signle data.
> This is what makes the register bypass easy for FC0 :-)

If you currently have ROP2, SCRAMBLE, INCREMENT EU's taking one cycle, and
ADD/SUB taking 1 or 2 cycles (1 for the 8-bit), Multiply taking 6 cycles and
Div EU handled with a counter, then by my proposal the EU private pipelines
for the FC0 will contain a total of 11 pipeline stages in their FIFO's. Your
dual global FIFO version has 16 stages (2 * 8). You also have a large LUT.
My proposal uses less area, right? Your FIFO construction is also more
complex (extra OR, AND etc) than my simple one, so each stage is bigger. I
agree that scaleability will mean my total EU pipeline stages will overtake
your 16 FIFO stages when loads more EU's are added. But you LUT will also
get bigger and when you add Xbar write ports so will your FIFO. It is
therefore not at all clear to me that your scheduler will be more efficient
even in general, and certainly not for the FC0 with that set of EU's (16 >
11). I'll speak about register bypass later.


>
> Read http://www.f-cpu.de/epf2001/cfp.html
> (look also at http://www.f-cpu.de/epf2001/epf-slide00.html)
> where i go further in the description of the scheduler.
> (the drawings are not yet ready). The chapter that you quoted
> in your text is incomplete (that's why it is so short) and
> i had no time to go further.

I had already read that and my understanding remained the same.


>
> There are a lot of little flaws or misunderstanding in your text,
> most of them are probably caused by the lack of good documentation.
>
> For example, when i say "FIFO", it's an illustration. you say that
> it is "difficult" to write a specific slot of a FIFO, but it is
> not impossible. FIFO is simply a way to describe the device in
> a genereic way, you imagine easily that it is a custom design.
> A FIFO is made of flip-flops and we are able to wire the FF at wish.
> so we can easily put a OR gate between each FF in the FIFO.
>
> here is an illustration of one bit. the FIFO requires 14 (6+1 *2)
> such "columns" with 8 stages. that makes 112 bits, out of which
> 16 of them are "busy" bits. It is a synchronous design, the
> clocks are not shown.
>
>         precedent stage
>          (0 if first)
>                |
>                v
>                FF
>                |
>                v
>       issue--->OR
>                |
> scoreboard<----*
>                |
>                v
>            Next stage
>
> the output of each FF is available for comparison with the
> register number
> (comparison not shown) and when it is issued, the value is
> brought back to
> the OR (the AND is not shown either).
>
> The FIFO is fed with 0s so we only need a OR (and not a mux) so the
> additional gate is not critical for the latency.

I understand it is a custom FIFO. I speak more of the fact that you must
insert your register value at any of the 8 stages. But Ok you will use AND
gates on each stage and at each insert only switch on one bank of AND gates
to control which stage there register is inserted at. Fine.


>
> Another flaw (or lack of documentation on the facts) :
> given the 8-stage FIFO and a 16-bit division, the additional counter
> for the divider will be loaded with 16-7=9 (not 8 because of
> the additional Xbar cycle).
> When the counter elapses, the number of the registers
> (result+remainder)
> replace the 0 that the beginning of the FIFO. There is no conflict,
> no slot to find inside the pipeline :-) IIRC you seemed to
> suggest that
> it was a counter loaded with a value equal to the number of bits.
> Now, you know it's not that dumb :-)

Ok. But it is still a special case. The scheduler has been modified for the
particular needs of the IMPLEMENTATION of a particular execution unit. It is
un-modular. So you will send that register value in at the beginning of the
FIFO no problem. But what if you have multiple non-pipelined high latency
EU's: what then? Your FIFO only has ONE beginning. If two long latency EU's
both want that slot you have a problem. Ok so you can have special circuits
in the decoder to get around this, but that is yet more special case
handling, rather unmodular.


>
> Another point that should be made clear : the LUT that describes the
> latency of the instructions is "compiled" and not maintained
> by hand :-)
> Of course each module should include the specification of the latency
> so that it can be automatically handled when it is compiled.
> we're not masochistic ;-)

Good!


> In fact, i think that it is not a high price compared to the
> relative simplicity
> of the rest of the FC0, and it doesn't impact much the ISA.
> other F-CPU
> implementations will certainly use different approaches.
>

The LUT s "compiled" fine, but you still need actual alterations to the
scheduler for particular EU implementations, e.g. special cases like the
long latency divide unit. In my proposal this would not require any special
modifications. A pipelined divide unit could be "plugged in" instead of the
serial shift-subtract version without ANY scheduler modifications.


> Ok i think that the scheduling of division is rather clear.
> The multiplier is hardwired and pipelined, Michael has designed
> several such units. Now i'll try to explain how the load
> instruction works.
>
> The Store instruction is not a problem because it simply stalls if
> no LSU line is available. IT is 2 cycles of latency by itself,
> without counting the (parallel and optional) post-increment latency.
> no problemo.
>
> The Load instruction is also a 2 cycles instruction in the ideal case.
> Therefore "in the ideal case" (the data is already present in
> the LSU buffer)
> there is no scheduling problem, it's the usual way.
>
> Now when there is a LSU miss, the memory system will search
> in the rest of
> the available ressources with an unpredicted time. If there
> is a L1 hit,
> there is a delay of a few cycles and the latency will be
> around 5 or 6 cycles
> (very roughly). That is still "static" and can be optimised
> on a case-per-case
> basis. If there is L1 hit ...
>
> The memory system will seek the data where it is and this is
> unpredictible.
> when the data is brought back to the core, we fall back to
> the predictable
> latency case : 2 cycles. So we stall the current instruction
> and reserve
> the Xbar slot in priority. In most case, the pipeline will
> even be already
> stalled because the fetch took so much time it stopped the
> execution of the
> rest of the software.

So you do stall your pipeline. This is more than just stopping the issue of
the next instruction, right? This is stopping all execution so that the
returning loaded data can go into the Xbar at the end slot immediately.
Whatever else would have gone there must be stopped. How do you stall your
pipeline? I agree clock enable is not necessarily pretty but how do you
stall a pipeline without it?


>
> In fact it is even more refined (there are some bypass ways,
> the endian story,
> the TLB, the automatic prefetch...) but i have no time to
> explain everything
> right now (maybe tonight).
>
> The second major flaw of your text is that it is almost an OOO system
> (it made me think about PowerPC) and it would work well with
> renamed registers.
> However we have fixed/physical registers and it creates a new
> bunch of problems
> when a trap/IRQ/fault etc occurs. It is a dificult problem to
> solve elegantly.
> In the FC0 it is solved by not sending (potentially) faulty
> instructions.
> the scheduler and scoreboard know the latency of each instruction and
> they work around this problem.
> You did not mention the behaviour of your units in the case
> of a context switch
> or trap. maybe your solution will be more complex or heavy
> than really necessary :
> additional buffers, new flags ...

My proposal is most definitely not OOO, I will speak more of this later. In
my proposal too I do not send potentially faulty instructions. I handle
context switches and traps the same way you do now. I have not recommended
altering the whole F-CPU design! Just improving the scheduler to improve
modularity and maintainability and possibly performance.


>
>
>
> Well, as a conclusion i would say that Hans' text is completely crazy,
> but far from insanity. It's simply too late for the FC0 and i
> hope that
> he will help us for the next generations. I also understand how a good
> documentation can help us not lose time discussing old stuff.
> the CVS at seul will probably be setup soon.
>
> YG
>
> speaking for himself
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor

www.  
From Hans Summers Thu Feb 8 10:03:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00372 for ; Thu, 8 Feb 2001 18:56:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:06 +0100 (MET) Received: (qmail 11886 invoked by uid 0); 8 Feb 2001 09:03:43 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx04) with SMTP; 8 Feb 2001 09:03:43 -0000 X-eGroups-Return: sentto-1101623-2303-981623018-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 08 Feb 2001 09:03:40 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 09:03:37 -0000 Received: (qmail 19691 invoked from network); 8 Feb 2001 09:03:36 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 8 Feb 2001 09:03:36 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta3 with SMTP; 8 Feb 2001 10:04:41 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA24961 for ; Thu, 8 Feb 2001 04:01:31 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA17698 for ; Thu, 8 Feb 2001 04:03:34 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Feb 2001 09:03:33 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5DD@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 09:03:31 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ddda8b79586aae9467efe71748d924f8 Status: R X-Status: N
> -----Original Message-----
> From: Yann GUIDON [mailto:whygee@f-cpu.org]
> Sent: 06 February 2001 16:21
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> hi,
>
> Hans Summers wrote:
> > From: Michael Riepe :
> > > What about bypassing results from one EU to another?
> good point :-)
>
> bypassing would require to compare the reg flags of every
> unit in parallel,
> while less comparisons are needed with the "old" FIFO :-)
>
> > I thought about this a bit. But I don't know how bypassing
> is going to be
> > arranged with the current scheme?
> rather easy.
> As the FIFO shifts down, we can see that the fore-to-last
> stage contains the
> numbers of the registers that will be issued in the next
> cycle. they are compared
> with the currently needed registers and we can therefore
> issue an instruction
> 1 cycle in advance compared to a non-bypassing scheme.
>
> > I assume that whatever problems and
> > solutions apply at the moment will apply to my scheme too.
> your scheme requires a more "brute force" approach, due to the
> "spreading/dissemination" of the information. comparators everywhere.

No. Let the Xbar contain 6 extra bits specifying which register the data on
it currently represents. This 6 bits will be clocked into the Xbar at the
same time as the result data. The instruction issue simply checks these 6
bits with the register it needs. If it matches, it takes the data on the
next clock pulse. The comparison need only be done in ONE place not all over
the place.


>
> In fact your approach is completely the opposite of the FC0's :
> you take the POV of the issue stage. you hope that the execution unit
> will do all the scheduling for you.
> From the FC0's POV, we start from the END : from the write
> ports of the
> R7.
>
> You issue an instruction when the data is ready,
> i issue if the data can be written (that's an illustration,
> of course).
> This means that all the mechanism that decides what EU will write its
> result, is brought somewhere else. This has to be done
> somewhere anyway.

You also issue an instruction when data is ready. You stall instruction
issue when the source register data is not ready. The difference is that you
check if an execution unit can write the data before issuing it, I check at
the end of execution. That's the only difference. By doing this and moving
the FIFO into the EU's I make the system very modular and eliminate the LUT.
Elsewhere in other threads I have read about the instruction decode taking 2
cycles. With my method you may be able to to it in one, as you have less
checking to do. I don't know. Taking one cycle off the latency of every
instruction would be a major performance enhancement.


> As Michael pointed, it allows a compiler to statically
> schedule the CPU.
> it has an invaluable advantage when high performance is at
> stake because
> you can GARANTEE the execution time. It is impossible to predict the
> execution time of any piece of SW on OOO cores.

My proposal is NOT, definitely not, OOO. I don't really fully understand all
the objections to OOO but I appreciate that it is at any rate a lot more
complex etc and undesirable. But why is my proposal OOO? It is OOOC just
like yours! Let me make two assumptions:

1) I abandon variable data-dependent latency. Most of the comments against
my proposal argue against the unpredictability of this approach. Whilst it
is an interesting intellectual exercise and fun to consider, Ok I can see
that you don't want to complicate the compiler optimisation. Doubtless you
have all spent a lot of time considering the various trade-offs and decided
that guaranteed execution times will be beneficial. I accept that, so shelve
the compressible pipeline, early completion etc etc (at least temporarily).

2) Prioritise the completion find-first tree such that the EU's with the
longest latency always have the highest priority if they complete at a
simultaneous time to a shorter EU. This is very easy, since it just means
ordering the inputs to the find-first tree such that the long latency EU's
are first.

Can you not see that if you do this, you get IDENTICAL results to your
current scheduler? Instructions are issued in the same order as yours, the
results are written in exactly the same order as yours, and all the
instructions complete in a precise deterministic number of cycles. The
latency between the instruction arriving at the decoder and the result being
written is identical. Correct me if I am wrong! Now you're not seriously
going to tell me that by abandoning early completion optimisations etc and
choosing a particular prioritisation scheme for my completion, I am changing
the whole processor from OOOC to OOO!

Therefore, with my proposal the same beloved guarantees exist, the compiler
can be identical, everything the same, except that the design becomes tidy
and modular, and probably uses less area too.


>
> > In the current
> > design does bypassing eliminate the need for writing to a
> register at all,
> > or is it just a way for a pending instruction to get at the
> data more
> > quickly if it appears on the Xbar during result write?
> you got it :-) it shadows one of the Xbar cycle, and it's
> also one of the Xbar's
> purposes.
>
> > Overall I concluded
> > that whatever problems would be faced in register bypassing
> would be the
> > same in my design and the current one. My design doesn't
> address that issue,
> > and I didn't think it makes it harder to solve.
> mmm you should think a bit more :-)

See above. 6 extra bits in the Xbar, the comparison takes place in only one
place and the register bypass remains the same.


>
>
> > > > The only disadvantage to the per-execution-unit
> destination register
> > > > pipeline is that it requires higher complexity in the
> execution units and
> > > > greater silicon area. However the addition of a 7-bit
> pipeline is hardly
> > > > likely to be a significant complication, and given the
> 64-bit pipeline which
> > > > will already exist in the execution unit, let alone the
> execution pipeline
> > > > stages themselves, proportionally the 7 extra bits
> won't hurt the area too
> > > > much. The advantages though are so numerous that I feel
> this can be
> > > > tolerated.
> > > Agreed, 7 bits isn't much, and there's almost no logic between the
> > > flip-flops (no slowdown).
> maybe. however, the information is disseminated and spread
> all around the chip.
> if it is not available somewhere else, you'll require long
> wires and lotsa comparators !
>
> > > > An execution unit can even be non-pipelined and use the
> same mechanism. In
> > > > this case it can latch the destination register and
> output it to the
> > > > destination register output when the execution unit is
> complete. The simple
> > > > non-pipelined division unit can still have its 6-bit
> counter, but it will
> > > > now be inside the execution unit not the scheduler. At
> the end of the count,
> > > > the unit will output the completion bit and the 6-bit
> destination register
> > > > number.
> > >
> > > IMHO an EU will always be `pipelined' -- there's at least
> one register at
> > > the input and one at the output, and n (>= 0) between them.
> >
> > There doesn't necessisarily need to be a register at the
> output. If the
> > final stage of the EU is considered to be latching the data
> into the Xbar
> > for result write, the final pipeline register can (should)
> be omitted or it
> > just wastes a cycle...
>
> nope. we have "very thin stages" and we consider the pipeline
> as an alternance of
> logic and flip flops. the Xbar is considered as a "logic"
> layer and the FF have
> to buffer the data while it is propagating.

Of course, and so do I (consider pipeline = alternate logic and flip flops).
One pipeline stage consists of a logic layer and a FF layer. If each EU has
a FF at the start and end, and the Xbar just a logic layer, then really the
EU's are 2.5 stages long for example and the Xbar 0.5 stages long. But
really all you have done is move the Xbar's FF onto the end of each EU so
it's the same thing. Fine whatever. I did say I wasn't aware of all the
details of the Xbar design and that variation to the inputs and outputs of
my EU's may be required. It is the principle of my proposal which is
important and remains the same.


>
> > By non-pipelined in this sense I mean an EU which is only capable of
> > processing one instruction at a time. An iterative
> shift-add multiplier can
> > only multiply two numbers at a time (one instruction).
> However many cycles
> > of latency that takes can be counted with a binary counter,
> and the "data
> > valid" bit enabled when the count is completed. In contrast a high
> > performance (but large) parallel multiplier can be pipelined and be
> > processing several consecutive instructions (multiplies) at
> a time in its
> > pipeline. With my proposal a shift-add iterative multiplier could be
> > replaced with a parallel multiplier transparently.
> Throughput would increase
> > and latency may change, but elsewhere the processor would
> require no change.
> Michael has already done a SIMD 64-bit multiplier with 6 stages.
> I don't know the conditions for early exit (with 8, 16 and 32
> bit data)
> however but it can be easily encoded into the "Latency LUT".
>

Agreed. And you will "compile" your LUT so it will be easy. But you will
still have to make changes to the scheduler circuit when you change special
case units like Div, or add more. My proposal never requires such changes
and requires no LUT.


> > >
> > > > 2.4 XBAR WRITE CONFLICTS
> > > >
> > > > Now I hear you all wailing about what happens when too
> many execution
> > units
> > > > complete at exactly the same moment, and the Xbar has
> only two write
> > ports.
> > > > The answer is that the Xbar selects only two of the
> execution units to
> > read
> > > > from, any other execution units are stalled and wait
> for a space in the
> > next
> > > > cycle. A mechanism must therefore exist to stall the pipeline of
> > execution
> > > > units which have a result ready but the Xbar isn't
> ready to read it yet.
> > I
> > > > consider this in more detail a little later on.
> > >
> > > Stalling complicates the pipelines, and also the
> instruction decoder
> > > (because it has to check if a particular EU is stalled). 
> The necessary
> > > clock enable lines may also affect the critical datapath.
> Because of their nature, stall can also be caused by
>  - memory not ready (or more precisely : LSU line absent)
>  - DIV unit busy
> therefore, DIV, LOAD and STORE are impacted (as well as
> derivated uses).
>
> > Stalling is going to be necessary even in the current
> design. It occurs
> > anyway if the source registers for the instruction are not
> available (they
> > are awaiting result write from a previous computing
> instruction). The
> > instruction decoder checking if a particular execution unit
> is stalled is no
> > different from checking if the source registers are
> available, and it will
> > be done in parallel therefore not lengthening the critical datapath.
> right.
>
> > As the current pipeline must also be stallable it will also
> require clock enable
> > lines, so no change here.
> wrong. "stall" means "the current instruction in the decoder
> is not ready",
> while the rest of the execution pipeline flows its way normally...
> there's a little difference now :-)
> If the whole pipeline was stalled because a source register
> is not ready,
> it would deadlock the CPU ;-P

Yeah I do realise that. But it seems to me that you do have to stall your
FIFO when the results of a non-deterministic load operation arrive back. How
do you do this without clock enable?


>
>
> > > > If there are two write ports in the Xbar, an easy way
> to select two
> > > > different waiting execution units is to reverse the
> order of the execution
> > > > unit inputs to the find first binary tree. One tree can
> search from the
> > > > first execution unit moving forwards, the other
> effectively moves backwards
> > > > from the last execution unit.
> > > We could play with different algorithms here --
> round-robin, priority
> > > based, ...
> yep we can play a LOT but it doesn't solve the problem : this
> lengthens and
> complicates the scheduling (from my point of view).
> scheduling has two sides :
> HW and SW. Currently the FC0 can achieve good sustained
> performance because
> it is predictive, it's almost an ALPHA. Hans' propositions
> look like we're going
> to make a PowerPC. he has not yet studied how he'll unwind
> the instruction flow
> when there's a trouble...

I haven't studied the PowerPC or ALPHA or any other. My proposal is purely
based on what I would consider to be an optimal way of building a CPU. I
come to this with a fresh mind, no pollution from previous processor
designs. In fact, I once went some way to designing a whole CPU which was
intended to be made from TTL logic chips. Of course, the existing 24 hours
in a day are less than half what would be required to construct such a
monstrosity in parallel with a a job and a family, so it remained destined
to lie for ever in the figments of my imagination. But of prime importance
are "silicon area" (equivalent to how many hundreds of TTL chips I would
have had to solder up) and simplicity (same reason). I also wanted high
performance therefore the superscalar type architecture.

I don't plan to unwind instruction flow any more than you do therefore i
don't need to stufy it. Trouble won't occur (like your current design I
won't allow it). In fact as I showed earlier, my proposition can yield
identical execution order to yours, and deterministic latency. It is merely
a different way of acheiving it, a way which I believe will be more modular,
and easier to maintain and implement. Additionally it will allow all the
non-deterministic latency stuff if that was required. You could in fact even
have a global flag to switch this on or off, then we could really experiment
with some real world programs and see if it made anything any faster! Just a
fun idea.


>
> > > > Whichever way, it is clear that the Xbar can simply use
> this method to
> > > > ensure that there is no conflict on the Xbar's write
> ports due to multiple
> > > > simultaneous execution unit completions. At the same
> time, execution units
> > > > are free to complete early if they contain the
> necessary optimisation logic
> > > > and the operands allow it, and the OOOC does not just
> reorder instruction
> > > > execution based on execution unit latency, but also
> based on dependencies
> > > > between the instructions.
> there is probably a mistake here : there is NO execution
> "reordering" in FC0.
> only write back is OOO while the scheduler and the scoreboard issue
> "safe" instructions. From the programming point of view, it
> is crucial...

Same with my proposal. Issue is in order, only write back is OOO.


>
> > > > This should all improve performance, modularity
> > > > and scalability of the design. More execution units can
> easily be added or
> > > > replaced with more/less efficient ones depending on the
> requirements of a
> > > > particular F-CPU implementation.
> > >
> > > This sounds very nice, but a known latency has its advances, too.
> > > If you know the latency of an instruction a priori, you
> can *statically*
> > > schedule instructions (in the compiler) in order to
> optimize your code.
> > > If EU latency is unknown, this becomes impossible (unless
> you issue
> > > instructions out-of-order, which we currently don't).
> >
> > I agree that in an ideal world the compiler should know the
> instruction
> > latency so it can optimise static scheduling. If code is
> run on different
> > versions of the F-CPU having different execution units, it
> would need
> > recompiling to get optimum scheduling, which is no problem.
> My proposal is
> > not intended to replace compile-time optimisation, rather
> to augment it. In
> > cases where code is not recompiled there would be some
> performance gain.
> > There could also be data-dependent performance gain which
> is impossible to
> > predict when the compiler does its instruction scheduling.
> In any event the
> > maximum latency of an execution unit will still be known to
> the compiler.
> > Just in some cases the processor may improve on the
> completion scheduling
> > done by the compiler, or if the code was compiled for a
> different version,
> > or if the data and pipeline contents allow lower latency. I
> believe this new
> > design cannot have a LOWER performance than the current
> design, but can have
> > HIGHER performance under some circumstances.
> however, on a given case, FC0's price/complexity/speed can win ;-)
>
> > I view it as a useful side
> > effect rather than the main advantage of better modularity
> and simpler
> > decoder/scheduler (no special cases e.g. Load/Store,
> divide; no large LUT to
> > be maintained etc.).
>
> we are probably going to need in the future the techniques
> you described :
> scheduling completely changes when more than one instruction is issued
> per cycle, and compilers don't often keep up. even the
> current GCC port
> is not good at all at scheduling anything. One cycle or two
> that can be won
> is not negligible.

So why not do it now! Enforce strict deterministic latency on the units and
prioritise in favour of long-latency units. The results become identical.
But the modularity is great, and the potential for other things is very
high. The design becomes cleaner, less cluttered. No LUT. Simpler. And for
future, you will have less redesign to do when you want to issue more than
one instruction per cycle!


>
> > > [...]
> > > > 3.4 COMPRESSIBLE PIPELINE
> > > >
> > > > An interesting idea I had is the "compressible
> pipeline". As the number of
> > > > execution units is large relative to the number of
> instructions issued per
> > > > cycle, it is unlikely that the pipeline of a given
> execution unit will be
> > > > fully populated. In this case it is possible to
> partially stall the
> > > > pipeline. Imagine the final stage of the pipeline
> stalls because the Xbar
> > > > cannot take the result data. If the penultimate stage
> is empty, there is no
> > > > need to stall the whole pipeline. Data earlier in the
> pipeline can still
> > > > move to the next processing stage, without colliding
> with the waiting
> > > > result.
> > >
> > > Yep.  I've seen something similar in papers about TTA machines.
> >
> > Interesting. When I have time I am going to read some more
> about TTA. Again
> > the compressible pipeline can only increase performance,
> never decrease it.
> > The extra gates in the EU pipeline clock-enable are not in the CDP.
> well the idea is good and seducing, however this means that
> we must use clock gating.
> it might make the implementation difficult....... ask the specialists.

As above. Do you really not need clock enable in your design? Not clock
gating. By clock gating I assume you mean an AND gate at the clock input of
each FF, with one AND input going to the global clock and the other the
enable. No, this would be a timing disaster. It would be necessary for the
enable input to only change state when the clock was low. No chance. I speak
of an enable input which must be stable some small period before the arrival
of the positive edge of the clock pulse, and which causes the positive edge
to be actioned/ignored accordingly. I do not know how difficult this is to
implement but it seems quite crucial to a synchronous design and I am
surprised if you do not need it. As I asked before, how do you stall your
pipeline on Load data results?


>
> > >
> > > [...]
> > > > 3.5 FORKED PIPELINE
> > > >
> > > > Another interesting idea in an execution unit where the
> execution pipeline
> > > > can be forked when early completion is possible. This
> reduces the latency of
> > > > the execution unit. For example the previously given
> floating point addition
> > > > example. If the unit notices that the addition will
> simply result in the
> > > > larger of the two operands, and no addition needs to be
> performed, and if
> > > > the final stage of the execution pipeline is empty, the
> unit can route the
> > > > operand directly to the final stage and alert the Xbar.
> > >
> > > I'm afraid that there's no room for the multiplexers you need for
> > > bypassing the later stages of the pipeline.  The pipeline
> stages of the
> > > F-CPU are *very* short (6 gates / 10 transistors), and
> adding another
> > > stage is not an option in most cases (most EUs are short,
> even IMUL
> > > ist only 6 stages).
> > >
> > I worry a little about making a pipeline state SO short it
> can do too little
> > useful work. I wouldn't suggest adding an extra stage just
> for the sake of a
> > multiplexer. But the multiplexer should only take 1 gate in
> the CDP. In some
> > circumstances depending on the design and function of the
> EU it may be
> > possible if the pipeline stage has room. It's again a
> side-effect of the
> > main design, a posibility which can possibly be
> incorporated if desired. It
> > would be invisible outside the "black box" execution unit.
>
> the "6 gates goal" is here to remember the designers that it
> is easy to get trapped
> when one adds a gate here and there. If it is necessary, we
> can add a gate
> for a very important special case. However, "the shortest the
> simplest"
> (and speed is not the only issue). When we add depth, we have
> more chances
> to make buggy designs. It forces us to think about the
> necessity of each part.

Fine.


>
> > > [...]
> > > > 3.6 EARLY COMPLETION PORT
> > > That's what I did for the faster SIMD operations (the
> IMUL EU currently
> > > has 4 output ports, ASU has 2).  But it has nothing to do
> with early
> > > completion, the latency for all ports is well-known.
> :-) you see, we also worry about executing as fast as possible :-)
>
>
> > > [...]
> > > > 3.8 DUAL OUTPUT PIPELINED MULTIPLIER UNIT
> > > [...]
> > > > My example design here is only for the mulh case (128-bit
> > > > result to two registers), in reality one would put
> extra logic in to decode
> > > > the opcode bits, since the high word may not be required.
> > > The IMUL EU already has this port -- and if it's not needed, it is
> > > simply ignored by the Xbar.
> > Good, I haven't the seen IMUL EU design.
> look at f-cpu.de/design
>
> > > > 4   CONCLUSION
> > > >
> > > > My proposed replacement for the current scheduler unit
> is conceptually
> > > > simpler.
> however it makes the compiler much difficult to write.

As I said above. If you enforce fixed latency and prioritise long latency
instructions then the issue, completion and latency are identical to your
current design, therefore the compiler is the same.

>
> > > > The decoder/instruction issue unit is made more simple
> since all it
> > > > does is check availability and then issue.
> However how do you check for the availability ?
> you have to read the scoreboard bits,
> they are set when the Xbar write ports are in use,
> this means a lot of wires, comparators, latency.
> with the FIFO approach, we can perform bypass etc.
> more easily than you'd think :-)

See above. I check data availability from the scoreboard at the same time as
you. For bypass 6 extra bits on the Xbar enable the comparison to occur in
one place.


>
> > > The availability check may become more complex when we
> want to bypass
> > > results.
> > Agreed, but presumably the same issues affect the current design.
> "presumably".
> i think that his approach leads us to a completely different
> style of CPU,
> more suited to pure OOO.

As above. No OOO, mine is also OOOC and identical to yours when applying
specific contraints and priority choices.


>
> > > > It will be easier to develop among a distributed group
> since the execution
> > > > units are externally precisely defined. Unit designers
> can enhance execution
> > > > units without affecting the rest of the design or
> requiring any changes
> > > > elsewhere (no latency LUT!).
> > > Yep, that's the biggest advance, IMHO.
> i don't think it's such a problem however...
> it's a matter of good coding practice and reading the
> readme.txt files...

So you can compile in the latency. But you can't alter the fact that your
current scheduler has extra circuits for special case execution units. The
scheduler is intimately tied up with the choice of EU's in the
implementation and the specific implementation of the EU's. My proposal does
away with all that. It's not just the latency LUT which dissapears.

>
> > > > Performance is improved by improving the OOOC (result
> prioritisation) and
> > > > permitting interesting optimisation variants of the
> execution units
> > > > (non-deterministic latency).
> > > Affects compile-time optimization.  And I just *hate*
> unpredictable
> > > behaviour.
> me too ...
> if you had programmed as much MMX asm as me, you'd understand ;-)
>
> > As above. I don't think performance can be degraded,
> possibly it can be
> > improved in some circumstances.
> however performance is related to the compiler's quality,
> which is proportional to the simplicity of the cpu.
>
> > Personally I rather like unpredictable
> > behaviour! The whole F-CPU project is somewhat anarchistic
> and having a
> > matching architecture seems to suit (unless it degrades performance,
> > obviously). It's also somewhat novel. If I am in a minority then
> > data-dependent optimisation could be discarded.
> well as of today your ideas are not needed but don't abandon them.
> it's already a lot of work...
> data-dependent in itself is not "bad", it simply does not fit
> for the FC0,
> but it might easily be the base for another new F-CPU core.
>
> BTW we can detect div by zero at decode time, just like we "could"
> transform y=x+0 into y=x, it must simply be integrated in the
> decoder's
> compiler-generated tables.
>
>
> > > > The architecture is easily extensible. It is easy to
> see how more ports
> > > > could be added to the Xbar, or the processor made
> superscalar by issuing
> > > > more than one instruction per cycle. It is even
> possible to duplicate
> > > > execution units if necessary. The complexity of the
> decoder will remain
> > > > manageable.
> > >
> > > You still have to prove that...
> >
> > True. Many issues remain there.
> i'd say : IRQ for example :-)
> maybe you know a simple turnaround...

Same as yours!


>
> > Nevertheless the same issues exist with the
> > current design. By the simplications in my proposal and the improved
> > modularity etc at least we have the best chance of solving
> the challenges
> > when the time comes to consider them.
> time will come. but we have something to finish first ;-)

Precisely my point. Surely the improved modularity will help us to finish
FCO more easily.


>
> > > My conclusion: putting the `latency knowledge' into the
> EUs themselves is
> > > a *very* good idea because it improves modularity and
> maintainability.
> > > Tagging partial (and final) results with a register number (or a
> > > transaction id) is also a good idea.  Variable latencies,
> on the other
> > > hand, have their drawbacks, missing predictability beeing
> the worst
> > > of them.
> it's not the only one. we have to know what register is needed by what
> and belongs to which task etc... Otherwise the apparent speedup might
> become a huge pain to develop, program and debug ! don't
> forget the poor,
> poor compiler writers and asm programers...
>
> > My main objective in this proposal was to tidy up the
> scheduler design to
> > get better modularity and maintainability.
> nothing comes from free :-)
> you "solve" problems, or more precisely you move them around,
> it's an endless game. this explains the large variety of core
> types today.
> FC0 starts from one POV, you start from another and we get different
> behaviours that can be good or bad depending on the situation.

This does come for free. As I said, enforce fixed latency and prioritise the
right way and you have the same behaviour but a neater more modular design.


>
> > It's going to be hard enough
> > anyway to complete the F-CPU without those problems.
> :-)
>
> > The variable latency is
> > a possibility with the new proposal which doesn't exist
> with the existing
> > design.
> notice that some of the "execution time enhancements" are often simple
> enough to be integrated into the decoder, with the help of
> some speculative
> flags. Look at how the memory is accessed and disambiguified.
>
> > It could be interesting and novel but if we don't like it we can
> > leave it out. Personally I like the unpredictability, as
> long as it doesn't
> > degrade performance (I believe it can only improve it here).
> it "could" but it depends on the cases.
>

In conclusion: if you don't like variable latency fine. Fix it, prioritise
long latency EU's and you have identical results to your current scheduler
design. Most objections are against the unpredictability. So this way there
will be none. But there will be all the modularity and maintainability
advantages and the the new structure looks forward to future implementations
when we will be considering multiple issue.


> > >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> > Hans Summers
>
> YG
>
> speaking for himself
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
www..com
From Hans Summers Thu Feb 8 10:16:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00375 for ; Thu, 8 Feb 2001 18:56:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:11 +0100 (MET) Received: (qmail 15597 invoked by uid 0); 8 Feb 2001 09:17:00 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx18) with SMTP; 8 Feb 2001 09:17:00 -0000 X-eGroups-Return: sentto-1101623-2304-981623818-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 08 Feb 2001 09:16:59 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 09:16:57 -0000 Received: (qmail 40141 invoked from network); 8 Feb 2001 09:16:57 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 8 Feb 2001 09:16:57 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 8 Feb 2001 09:16:57 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA25451 for ; Thu, 8 Feb 2001 04:14:52 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA18107 for ; Thu, 8 Feb 2001 04:16:55 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Feb 2001 09:16:55 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 09:16:47 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fe4c7282241e6a5c30d0359b70fa6564 Status: R X-Status: N
Hello

> -----Original Message-----
> From: Nicolas Boulay [mailto:nicolas.boulay@ifrance.com]
> Sent: 06 February 2001 20:45
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> Hello, some comment about the decoder.
>
>
> "The current scheduler strictly requires fixed deterministic latency.
> This is a pity. There are many cases when an execution unit
> may be able
> to complete its computation in less than its maximum latency, and the
> flexibility to do this would improve performance. "
>
> - It's not true in the general case. Imagine your 4 times
> pipelined mul
> unit. With your proposal you want to cut to 1 cycles if one of the
> operande are zero. BUT how do you handle the value just befor and just
> after. Most of the time, the pipeline will be full, so it's impossible
> to shortcut it, because the others stage compute previous
> data. If could
> never shortcut a pipeline, but you can split it, and you
> waste even more
> area for a quite unusual cases and you need one more access to the
> register bank.

Most of the time the pipeline will not be full. Not the pipeline of an
individual EU, at least (hopefully as a whole the execution will be full,
i.e. the instruction issue will not stall often). We have one instruction
issued per cycle. We have many execution units. Therefore on average most of
the execution units will remain empty most of the time. Unless, that is, a
particular program carries out a whole series of sequential multiplies. If
an EU pipeline is full no shortcuts are possible (unless there is an extra
port). Execution would continue as normal. But I am not sure that the
unusual case is for space to be available. I think it far more likely
because the number of EU's is large relative to instructions per cycle that
it will be unusual for the pipeline of a particular EU to be full.


>
> As Whygee said, it could be useful to raise exeption here (like divide
> by zero).
>
> "Whichever way, it is clear that the Xbar can simply use this
> method to
> ensure that there is no conflict on the Xbar's write ports due to
> multiple simultaneous execution unit completions. At the same time,
> execution units are free to complete early if they contain
> the necessary
> optimisation logic and the operands allow it, and the OOOC
> does not just
> reorder instruction execution based on execution unit
> latency, but also
> based on dependencies between the instructions. This should
> all improve
> performance, modularity and scalability of the design. More execution
> units can easily be added or replaced with more/less efficient ones
> depending on the
> requirements of a particular F-CPU implementation."
>
> - If you have write register conflict in your program, it's
> an horrible
> scheduling problem create by the user (the program writter). And the
> performance will suffer a lot. That's means that some instructions
> finish in the same times. To quipe the coherency, you propose
> solutions,
> but it doesn't speed up anything, it just try to be not too bad with
> such poor designed program with a greate waste of area.

So like I said in my other posting, take out the variable latency if you
don't like it. You get identical results to the current scheduler but have
the advantage of a simpler more modular design that will be more easily
extensible in future to multiple issue per cycle etc.


>
> - Never forget that Out of order execution exist only to speed up OLD
> binary in a new version of the core. It's made to use (for
> example) your
> all new second mul unit for a program design for only one
> unit. But for
> that you need to detect read-after-write depencies, and it
> cost a lot in
> area !
>
> - We design a all new core, why do you thinking of ooo like intel who
> want to speed up 8088 code ?

I do not want OOO. Just a better way of doing the OOOC.


>
> - I propose to make design rules as :
>         - How many decoder you wich
>         - try to execute in the same times how many instructions is
> possible (by using in the same times the differents units) so
> it will be
> possible to add very easly new unit (but old code is not
> suppose to use
> it very efficiently)
>         - A tag system decide wich unit are used to distribute the
> instruction to be executed.
>         - A vliw bit could avoid using 6 bit comparator to detect RAW
> depencies, that will be in the critical path, so here you can gain a
> pipeline stage.
>         - There is no ooo nether register renaming, 64
> registers will be
> fine.
>         - direct memory access (like add [r1++] r2) could
> even decrease
> pressure on the register bank, if the pipeline detect the ++
> and didn't
> wait that the register r1 will be write at the end of the instruction.
>        
> "The scoreboard"
>
> - In fact i don't like it so much. It used only to prevent false
> scheduling. Ok, but if you make your own scheduling, it could be much
> more efficient to read the old valure rather than wait or
> duplicate the
> value (more pressure on the register bank).
>
> -imagine :
>         mul r1 r2 r3 (write on r3 as usual, 3 ticks latency)
>         add r4 r1 r1 (r1 is the old value, not update by the previous
> instruction)
>         add r5 r3 r2
>         add r5 r1 r2  (here is the new r1 valure compute by the mul)
>        
> - So you can try to better hide some latency. But binary compatibility
> will became horrible that's sure. And // execution will be even worse.
> But maybe a "rescheduler" program could translate old
> binaries ? I know
> that it will be difficult to avoid scoreboard.
>
> - But With such scoreboard and without vliw bit, you can't really read
> the register if it's modified by a previous instruction. So you will
> decrease the efficiency of a // execution if you haven't the vliw bit,
> which clearly said which packet could be run in the same time.
>
>
> "3.2 STANDARD EXECUTION UNIT EXTERNAL VIEW"
> "--[0:n] Opcodes [Optional]: Whatever sub-bits of the
> instruction opcode
> are required by the execution unit to determine which flavour of
> operation to perform"
>
> - Hum, as it's written on the top of your page, you speak about the
> decoder, so decoder send much more control bit DECODED from
> the opcode.
> Unit should only compute, and decoding is made in the decode stage...

Whether the opcode bits are direct from the instruction bits or decoded from
the opcode in the decoder is unimportant to the principle of my design. If
you want decoding in the decoder fine. I did think however that letting an
EU decode bits which were specific to it would be better from the point of
view of modularity. Add a new EU, it does its own specific opcode bits
decode, this makes it more modular. The decoder remains simple and doesn't
need modification. I prefer this but it isn't important to the principle of
my proposal.


>
> "It is important to realise that the execution unit is now a
> black box.
> It can determine its own latency, be pipelined or not, and
> implement its
> function however it wishes.
> Externally the function is identical and the rest of the
> processor core
> knows nothing about the internal implementation. Execution units are
> then truly like LEGO bricks."
>
> - Hum, you forget r2w2 instruction and all that kind of stuff. But you
> add it at the end so you make an other possible unit interface.
>
> "COMPRESSIBLE PIPELINE"
> - A very good idea, if the pipeline have to make a lot of
> bubble. But we
> don't have to forget that's not the usual case (and the use
> of the unit
> are poor if the pipeline as a lot of bubble).

As I said, the number of units is large compared to the instructions issued
per cycle and is likely to always remain so. Therefore it is likely that
bubbles will be common. THe compressible pipeline could give a good
performance gain but of course the results become less deterministic and
that doesn't seem popular.


>
> "3.5 FORKED PIPELINE"
>
> - So you need,
>         - an empty pipeline
>         - a 2 to 1 64 bit multiplexer (big and slow)
>        
> - I think it uninterresting because if the programer have
> choosen not to
> use this unit maybe some others units will be used to write to the
> register bank. So your early completion port have to wait the end of
> others cycles. And i think that most of the time it will be the normal
> latency time of the unit ;p (as a program writer could
> imagine it in the
> general case). So your bypass port will be useless.
>
> - And never forget that an empty pipeline isn't a usual thing
> at all. If
> it happenss, it's because other unit are intensely used and use every
> write port on the register bank.

One instruction issue per cycle. EU's aren't heavily used unless a
particular computation e.g. vector multiplication is concentrating all the
computation in one particular unit.


>
> - Or as for TI DSP, use many port to the register bank (8 w 8
> r for the
> C6000), so you can't have stall anymore in the pipeline of
> your unit and
> early completion have a sense.
>
> "latches"
>
> - In VHDL design, we never, never use latches !! Very few synthiser
> could handles this very well (nether verfication program,...). You can
> only use it for clock gating, that's all.

Latches... I mean FF, whatever. FF are everywhere.


>
> I think i should try to read the decoder version of Whygee, i think, i
> could find lot of surprise, too.
>
> nicO
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
From Hans Summers Thu Feb 8 10:28:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00378 for ; Thu, 8 Feb 2001 18:56:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:13 +0100 (MET) Received: (qmail 14748 invoked by uid 0); 8 Feb 2001 09:28:28 -0000 Received: from f19.egroups.com (64.211.240.234) by 10.1.4.112 (mx12) with SMTP; 8 Feb 2001 09:28:28 -0000 X-eGroups-Return: sentto-1101623-2305-981624504-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 08 Feb 2001 09:28:25 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 09:28:24 -0000 Received: (qmail 24310 invoked from network); 8 Feb 2001 09:28:23 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Feb 2001 09:28:23 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 8 Feb 2001 09:28:23 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA25734 for ; Thu, 8 Feb 2001 04:26:18 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA18340 for ; Thu, 8 Feb 2001 04:28:21 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Feb 2001 09:28:20 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F98A5E0@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 09:28:16 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c1453a28a260c507060399ac3069ba47 Status: R X-Status: N
> -----Original Message-----
> From: Michael Riepe [mailto:michael@stud.uni-hannover.de]
> Sent: 06 February 2001 13:34
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> On Tue, Feb 06, 2001 at 09:45:57AM -0000, Hans Summers wrote:
> [...]
> > > What about bypassing results from one EU to another?
> >
> > I thought about this a bit. But I don't know how bypassing
> is going to be
> > arranged with the current scheme? I assume that whatever
> problems and
> > solutions apply at the moment will apply to my scheme too.
> In the current
> > design does bypassing eliminate the need for writing to a
> register at all,
> > or is it just a way for a pending instruction to get at the
> data more
> > quickly if it appears on the Xbar during result write?
> Overall I concluded
> > that whatever problems would be faced in register bypassing
> would be the
> > same in my design and the current one. My design doesn't
> address that issue,
> > and I didn't think it makes it harder to solve.
>
> Bypassing can do both -- forward data to another EU early, and write
> to a register -- or skip the register write.  But it will not skip the
> register write if the instruction explicitly says "write to
> register <n>"
> -- because the CPU is unable to determine if the value in
> that register
> is used afterwards.

The register write must always occur. If the compiler knows that the result
is only used by a single later instruction, which will take the result
directly from the Xbar, you might consider that the register write is no
longer required. However this depends on having the later instruction ready
and waiting for the result by the time the result is ready. This is very
dangerous for binary compatibility, it seems to me. Because in a different
implementation the result might be ready more quickly or for some other
reason the later instruction could be delayed and the result would
dissappear for ever from the Xbar. I'm not necessarily saying enforcement of
binary compatibility between F-CPU implementations is mandatory, just that
if we do want it then skipping the register write will break it.


>
> [...]
> > > IMHO an EU will always be `pipelined' -- there's at least
> one register at
> > > the input and one at the output, and n (>= 0) between them.
> >
> > There doesn't necessisarily need to be a register at the
> output. If the
> > final stage of the EU is considered to be latching the data
> into the Xbar
> > for result write, the final pipeline register can (should)
> be omitted or it
> > just wastes a cycle...
>
> The input and output registers are not part of the EUs, but they
> should be always there.

Ok. It's just a matter of where you consider the boundary of the EU to be or
the boundary of a "pipeline stage". It's a conceptual issue but the circuit
doesn't care where these boundaries are.


>
> > By non-pipelined in this sense I mean an EU which is only capable of
> > processing one instruction at a time. An iterative
> shift-add multiplier can
> > only multiply two numbers at a time (one instruction).
> However many cycles
> > of latency that takes can be counted with a binary counter,
> and the "data
> > valid" bit enabled when the count is completed. In contrast a high
> > performance (but large) parallel multiplier can be pipelined and be
> > processing several consecutive instructions (multiplies) at
> a time in its
> > pipeline. With my proposal a shift-add iterative multiplier could be
> > replaced with a parallel multiplier transparently.
> Throughput would increase
> > and latency may change, but elsewhere the processor would
> require no change.
>
> Yep.  Full modularity is a Very Good Thing(tm).
>
> [...]
> > > Stalling complicates the pipelines, and also the
> instruction decoder
> > > (because it has to check if a particular EU is stalled). 
> The necessary
> > > clock enable lines may also affect the critical datapath.
> >
> > Stalling is going to be necessary even in the current
> design. It occurs
> > anyway if the source registers for the instruction are not
> available (they
> > are awaiting result write from a previous computing
> instruction). The
> > instruction decoder checking if a particular execution unit
> is stalled is no
> > different from checking if the source registers are
> available, and it will
> > be done in parallel therefore not lengthening the critical
> datapath. As the
> > current pipeline must also be stallable it will also
> require clock enable
> > lines, so no change here.
>
> In that case (source not available), the pipeline will NOT
> stall, it will
> contain a `bubble', i.e. meaningless data that is ignored at
> the output.
> With well-known latencies and a sufficiently smart
> instruction decoder,
> there well be no collisions at the EU outputs either (i.e. the Xbar
> will never have to delay the result write because there are too many
> results available), so there's no reason to halt the pipelines at all.
> Only the IF/ID unit will pause if the EUs aren't ready.

Agreed but for sure the pipeline must stall when a non deterministic load
completes, surely.


>
> [...]
> > > This sounds very nice, but a known latency has its advances, too.
> > > If you know the latency of an instruction a priori, you
> can *statically*
> > > schedule instructions (in the compiler) in order to
> optimize your code.
> > > If EU latency is unknown, this becomes impossible (unless
> you issue
> > > instructions out-of-order, which we currently don't).
> >
> > I agree that in an ideal world the compiler should know the
> instruction
> > latency so it can optimise static scheduling. If code is
> run on different
> > versions of the F-CPU having different execution units, it
> would need
> > recompiling to get optimum scheduling, which is no problem.
> My proposal is
> > not intended to replace compile-time optimisation, rather
> to augment it. In
> > cases where code is not recompiled there would be some
> performance gain.
>
> And performance loss in other cases.  I'd rather put the optimization
> burden on the compiler, not the hardware.  After all, the F-CPU is a
> RISC chip...

I don't see where a performance loss can occur through my design. Unless it
becomes too hard to write an optimising compiler. But fine, I have said that
if this is a concern, abandon the fixed latency, prioritise long latency
EU's, and you obtain exactly the same results as currently. But you still
gain all the modularity and maintainability improvements.


>
> > There could also be data-dependent performance gain which
> is impossible to
> > predict when the compiler does its instruction scheduling.
> In any event the
> > maximum latency of an execution unit will still be known to
> the compiler.
> > Just in some cases the processor may improve on the
> completion scheduling
> > done by the compiler, or if the code was compiled for a
> different version,
> > or if the data and pipeline contents allow lower latency. I
> believe this new
> > design cannot have a LOWER performance than the current
> design, but can have
> > HIGHER performance under some circumstances. I view it as a
> useful side
> > effect rather than the main advantage of better modularity
> and simpler
> > decoder/scheduler (no special cases e.g. Load/Store,
> divide; no large LUT to
> > be maintained etc.).
>
> Hmm... if an unexpected `early' result results (no pun) in a collision
> at the Xbar, this is not a win, IMHO.

It is not a win, but nor is it a loss. The collision does not delay anything
relative to where we would have been in the current scheduler proposal. In
the current scheduler, that instruction would have been delayed before
issue. We have no loss, but we have the possibility of a win if there is no
collision.


>
> [compressible pipe]
> > > Yep.  I've seen something similar in papers about TTA machines.
> >
> > Interesting. When I have time I am going to read some more
> about TTA. Again
> > the compressible pipeline can only increase performance,
> never decrease it.
> > The extra gates in the EU pipeline clock-enable are not in the CDP.
>
> You're not proposing a `clock gate', are you?  That won't work
> reliably (timing is too critical).

Not clock gate as in AND of the clock signal. A proper sychronous enable of
the positive edge of the clock.


>
> [...]
> > > I'm afraid that there's no room for the multiplexers you need for
> > > bypassing the later stages of the pipeline.  The pipeline
> stages of the
> > > F-CPU are *very* short (6 gates / 10 transistors), and
> adding another
> > > stage is not an option in most cases (most EUs are short,
> even IMUL
> > > ist only 6 stages).
> >
> > I worry a little about making a pipeline state SO short it
> can do too little
> > useful work. I wouldn't suggest adding an extra stage just
> for the sake of a
> > multiplexer. But the multiplexer should only take 1 gate in
> the CDP. In some
> > circumstances depending on the design and function of the
> EU it may be
> > possible if the pipeline stage has room. It's again a
> side-effect of the
> > main design, a posibility which can possibly be
> incorporated if desired. It
> > would be invisible outside the "black box" execution unit.
>
> In most EUs there will be no room in the pipeline.  At least
> not in the
> units I wrote so far (ASU and IMU).

Ok fine so let's abandon that idea. With my proposal we still get all the
modularity gains and everything becomes more tidy and maintainable.


>
> [...]
> > > > Performance is improved by improving the OOOC (result
> prioritisation)
> > and
> > > > permitting interesting optimisation variants of the
> execution units
> > > > (non-deterministic latency).
> > >
> > > Affects compile-time optimization.  And I just *hate*
> unpredictable
> > > behaviour.
> >
> > As above. I don't think performance can be degraded,
> possibly it can be
> > improved in some circumstances. Personally I rather like
> unpredictable
> > behaviour! The whole F-CPU project is somewhat anarchistic
> and having a
> > matching architecture seems to suit (unless it degrades performance,
> > obviously). It's also somewhat novel. If I am in a minority then
> > data-dependent optimisation could be discarded.
>
> It's not novel at all -- unpredictable behaviour is Intel Style (tm).
> Ever wondered why they didn't document the instruction timings for
> Pentiums and later processors?  Because they couldn't calculate them
> any longer.
>
> Anarchy means freedom, but freedom is for people, not for machines.
> Free Software developers may be anarchists, but their code is usually
> well-organized, well-structured and not chaotic or
> unpredictable at all.

Ok OK ok. No more unpredictability (though I still think it fun to
experiment with). The princible of my proposal still applies. It still
becomes more modular though it remains precisely deterministic and compilers
can remain the same.

>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
www..com
From Jeff Davies Thu Feb 8 12:17:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00384 for ; Thu, 8 Feb 2001 18:56:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:17 +0100 (MET) Received: (qmail 25300 invoked by uid 0); 8 Feb 2001 11:11:47 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx21) with SMTP; 8 Feb 2001 11:11:47 -0000 X-eGroups-Return: sentto-1101623-2306-981630704-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 08 Feb 2001 11:11:45 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 11:11:44 -0000 Received: (qmail 31213 invoked from network); 8 Feb 2001 11:11:42 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 8 Feb 2001 11:11:42 -0000 Received: from unknown (HELO mail12.svr.pol.co.uk) (195.92.193.215) by mta2 with SMTP; 8 Feb 2001 11:11:42 -0000 Received: from modem-187.sodium.dialup.pol.co.uk ([62.136.10.187] helo=llandre.freeserve.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14QozE-0001QS-00 for f-cpu@egroups.com; Thu, 08 Feb 2001 11:11:41 +0000 Message-ID: <3A82804C.BF4E279C@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@yahoogroups.com From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 11:17:32 +0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] sony chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7d9d0682758c3a85786726e8d4d3ec1d Status: R X-Status: N Did you guys see the slashdot article about Sony's new graphics
controller?
It is rumoured to be for the PS/3. They've started getting some test
chips off the
production line, and yield is apparently good.
This is a development of their existing graphics chip (in the PS/2).

The existing one has 4 meg DRAM on chip with a 2500 bit bus.
The new one appears to be not too different, except it has 32 MEG on
chip!!!

(and still, the 2500 bit bus).

What about one of these babies on FCPU motherboard ???

Jeff Davies
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Thu Feb 8 13:48:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00411 for ; Thu, 8 Feb 2001 18:56:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:24 +0100 (MET) Received: (qmail 15768 invoked by uid 0); 8 Feb 2001 12:54:57 -0000 Received: from mr.egroups.com (208.50.144.80) by 10.1.4.112 (mx12) with SMTP; 8 Feb 2001 12:54:57 -0000 X-eGroups-Return: sentto-1101623-2307-981636895-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mr.egroups.com with NNFMP; 08 Feb 2001 12:54:56 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 12:54:53 -0000 Received: (qmail 90746 invoked from network); 8 Feb 2001 12:54:52 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 8 Feb 2001 12:54:52 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 8 Feb 2001 12:54:52 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA10857; Thu, 8 Feb 2001 04:54:49 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXW4M2; Thu, 8 Feb 2001 12:59:49 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A829594.F4483C93@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A82804C.BF4E279C@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 13:48:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] sony chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b13d5a1fc8d81ac69157c19adf10cf41 Status: R X-Status: N Jeff Davies wrote:
> Did you guys see the slashdot article about Sony's new graphics controller?
> It is rumoured to be for the PS/3. They've started getting some test chips off the
> production line, and yield is apparently good.
> This is a development of their existing graphics chip (in the PS/2).
> The existing one has 4 meg DRAM on chip with a 2500 bit bus.
> The new one appears to be not too different, except it has 32 MEG on chip!!!
wow, and what do you have to store on that ? a 4MB frame buffer is hardly used...
Z-buffer + RGB, on a TV resolution, is not that much silicon today.
> (and still, the 2500 bit bus).
"only" ? :-)

> What about one of these babies on FCPU motherboard ???

yeah i wouldn't refuse but :
- sony keeps his baby for him
- i'm not going to sign any NDA and the F-CPU project
    is not the good place either for that
- what about a "free" version ? :-)

> Jeff Davies

YG

speaking for himself
Yahoo! Groups Sponsor
www..com
From Ben Franchuk Sun Feb 4 20:58:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00459 for ; Thu, 8 Feb 2001 18:56:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:34 +0100 (MET) Received: (qmail 1060 invoked by uid 0); 8 Feb 2001 15:49:26 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx05) with SMTP; 8 Feb 2001 15:49:26 -0000 X-eGroups-Return: sentto-1101623-2308-981647346-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 08 Feb 2001 15:49:09 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 15:49:05 -0000 Received: (qmail 33609 invoked from network); 8 Feb 2001 15:48:25 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Feb 2001 15:48:25 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 8 Feb 2001 15:48:24 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA02355 for ; Thu, 8 Feb 2001 08:39:37 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7DB45E.B33B6195@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DC@po1-exch.lon.tudor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 12:58:22 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b6a5e949a914a0815d7a7969a7cd7e85 Status: R X-Status: N Hans Summers wrote:
> So you do stall your pipeline. This is more than just stopping the issue of
> the next instruction, right? This is stopping all execution so that the
> returning loaded data can go into the Xbar at the end slot immediately.
> Whatever else would have gone there must be stopped. How do you stall your
> pipeline? I agree clock enable is not necessarily pretty but how do you
> stall a pipeline without it?

For all you massive 'pipleline' people don't forget you may have to
handle 'hardware' wait states,non cached memory like i/o and critical
system variables.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.

From Ben Franchuk Sun Feb 4 21:13:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00462 for ; Thu, 8 Feb 2001 18:56:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:35 +0100 (MET) Received: (qmail 826 invoked by uid 0); 8 Feb 2001 16:04:44 -0000 Received: from ck.egroups.com (208.50.144.69) by 10.1.4.106 (mx06) with SMTP; 8 Feb 2001 16:04:44 -0000 X-eGroups-Return: sentto-1101623-2309-981648281-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 08 Feb 2001 16:04:43 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 16:04:40 -0000 Received: (qmail 1156 invoked from network); 8 Feb 2001 16:03:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 8 Feb 2001 16:03:47 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 8 Feb 2001 16:03:46 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA02972 for ; Thu, 8 Feb 2001 08:54:57 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7DB7F6.E83B5E2B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 13:13:42 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 16222ab764cc5e13b8dfb6271772b6fe Status: R X-Status: N >
> > - In VHDL design, we never, never use latches !! Very few synthiser
> > could handles this very well (nether verfication program,...). You can
> > only use it for clock gating, that's all.
>
> Latches... I mean FF, whatever. FF are everywhere.
>

I never use VHDL so I can use latches.Gated latches that is.
D latches are 1/2 the size FF's. Often Master/Slave FF's are
used instead of the standard D FF in cell libraries. FF's
are only FREE in FPGA's. RAM on FPGA's is often simple
latches or master/slave design internally too.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Thu Feb 8 17:03:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00471 for ; Thu, 8 Feb 2001 18:56:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:38 +0100 (MET) Received: (qmail 26195 invoked by uid 0); 8 Feb 2001 16:11:35 -0000 Received: from fl.egroups.com (64.211.240.233) by 10.1.4.119 (mx19) with SMTP; 8 Feb 2001 16:11:35 -0000 X-eGroups-Return: sentto-1101623-2310-981648693-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 08 Feb 2001 16:11:34 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 16:11:32 -0000 Received: (qmail 33106 invoked from network); 8 Feb 2001 16:10:32 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 Feb 2001 16:10:32 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 8 Feb 2001 16:10:31 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA05056; Thu, 8 Feb 2001 08:10:25 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVAJ; Thu, 8 Feb 2001 16:15:24 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82C36C.84959794@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DC@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 17:03:56 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1218fcb95440d4a2e400540b967e092c Status: R X-Status: N Hans Summers wrote:
> Hello

hello !
This discussion is getting interesting and while a big
make all is running for the nth time, i try to take some
time to reply in this thread.


> > first, there is the "efficiency" of the method that remembers where to
> > write the registers. let's take the theoretical case :
> > we have 64 registers (well, 63, but that's not an issue) so AT ANY TIME
> > we can't have more than 64 instructions in the pipeline. that's
> > the maximum : we therefore don't need more than 6*64 bits (384 FF).
> > Any method requiring more is under-efficient.
> > The "FIFO" idea is a compromise and to me it appears to be efficient
> > (to my eyes). The design of a scheduler and particularly for FC0
> > asks questions of the way data are encoded. should it be bit fields
> > or binary encoded ? where to put the data ? Is the data available differently
> > somewhere else ? FIFO is efficient because all the needed data is available
> > at the same place and time. no duplication is necessary and no overhead.
> > We can make several comparisons on on signle data.
> > This is what makes the register bypass easy for FC0 :-)
>
> If you currently have ROP2, SCRAMBLE, INCREMENT EU's taking one cycle, and
> ADD/SUB taking 1 or 2 cycles (1 for the 8-bit), Multiply taking 6 cycles and
> Div EU handled with a counter, then by my proposal the EU private pipelines
> for the FC0 will contain a total of 11 pipeline stages in their FIFO's. Your
> dual global FIFO version has 16 stages (2 * 8).
I agree that the current case (single issue) is possibly "underefficient"
when compared to your solution.
However, the way the data are grouped is not an issue :

What is the difference between your scheme and the "old" FIFO ?
the FIFO is a "local" grouping while your scheme spreads the data.
I had chosen the little (5*7 FFs) overhead because it keeps things
handy : it helps foresee the write conflicts.

However that's all : FIFO or register pipeline are the same things !
it's a bunch of 6-bit numbers (plus another one that indicates that the data is valid)
that hop from flip-flops to flip-flops.

Now the difference that strikes me is the write stage : we have to prioritize
the outputs. it might take some additional time and gates (to my eyes),
it makes the compiler (the scheduling part) more complex and can do bad choices
>from time to time. Not only it could be data-dependent (you seem to have accepted
to use that feature in the future only) but it can also become program-dependent !
the scheduling could be influenced by a code that the task did not execute
(and not control) because of a task switch that could affect the scheduling
of another code. i know, it's some science fiction but it illustrates the worries
that could arise, and i hate them :-)

> You also have a large LUT.
you can't do without that. if you're bothered by the latency LUT,
remember that it's a part of the larger problem of the instruction LUT :-P
and with 110 possible opcodes, you understand that it's not a big worry compared
to the huge task of maintaining the instruction set tables...

> My proposal uses less area, right?
not necessarily. i showed that it's similar to the FIFO, with the
lack of predictibility on top of that :-)

> Your FIFO construction is also more
> complex (extra OR, AND etc) than my simple one, so each stage is bigger.
this apparent simplicity in your design is only "moved" at the end of the pipeline.
the decision at the Xbar level will take gates, i think.
"nothing comes for free"...

> I agree that scaleability will mean my total EU pipeline stages will overtake
> your 16 FIFO stages when loads more EU's are added. But you LUT will also
> get bigger and when you add Xbar write ports so will your FIFO.
The FIFO can't have much more than 64 slots, it's the limit set by the number
of physical registers.

> It is
> therefore not at all clear to me that your scheduler will be more efficient
> even in general, and certainly not for the FC0 with that set of EU's (16 >
> 11). I'll speak about register bypass later.

the fronteers are blurring, right ? :-)

that is the magic of computer design : there are not millions of tricks,
only slight changes in flavour.

However, be reassured that your prioritizing mechanism will not come for free,
it will take a whole stage of its own. Your optimism is maybe due to the incomplete
analysis of the architecture as a whole. FC0 has started almost 2 years ago and
it was not my first attempt, so i had enough time to balance things. It often takes
around 18 months to design a CPU and i'm sure that all the questions about your
proposed architecture have not been asked. But the sooner you speak about the architecture,
the faster it will take shape and become coherent :-)


> > Read http://www.f-cpu.de/epf2001/cfp.html
> > (look also at http://www.f-cpu.de/epf2001/epf-slide00.html)
<>
> I had already read that and my understanding remained the same.
well i still have to draw the illustrations ;-)

> > There are a lot of little flaws or misunderstanding in your text,
> > most of them are probably caused by the lack of good documentation.
<>
> > The FIFO is fed with 0s so we only need a OR (and not a mux) so the
> > additional gate is not critical for the latency.
>
> I understand it is a custom FIFO. I speak more of the fact that you must
> insert your register value at any of the 8 stages. But Ok you will use AND
> gates on each stage and at each insert only switch on one bank of AND gates
> to control which stage there register is inserted at. Fine.

maybe a drawing would help me understand what you meant, but you understand
that there is no magic :-) as soon as the "conceptual problem" is solved,
the rest is school-level engineering.

> > Another flaw (or lack of documentation on the facts) :
> > given the 8-stage FIFO and a 16-bit division, the additional counter
> > for the divider will be loaded with 16-7=9 (not 8 because of the additional Xbar cycle).
> > When the counter elapses, the number of the registers (result+remainder)
> > replace the 0 that the beginning of the FIFO. There is no conflict,
> > no slot to find inside the pipeline :-) IIRC you seemed to suggest that
> > it was a counter loaded with a value equal to the number of bits.
> > Now, you know it's not that dumb :-)
> Ok. But it is still a special case.
so what ? look at your own design for the divider and tell me the difference :
there is the counter, the register number. they are simply placed closer to
the rest of the scheduling machine. the register value has less travel to do,
and we can compare things quickly, in advance of the execution rather than after.

> The scheduler has been modified for the
> particular needs of the IMPLEMENTATION of a particular execution unit.
this is an exception, but if you don't want that, you can maybe implement
a pipelined Newton/Raphson reciprocal seed computation.

> It is un-modular.
it is the "adaptation" of the core to the function it has to perform.
One of the design strategy is to use the information as soon as it is available.
Why wait until the end of a pipeline when you can know the time it will take,
BEFORE you get the result ?


> So you will send that register value in at the beginning of the
> FIFO no problem. But what if you have multiple non-pipelined high latency
> EU's: what then? Your FIFO only has ONE beginning.
good question ;-)
the answer, as far as i am concerned, is simple : only short units are favored.
In the current case, the long div unit is a tradeoff between functionality
and complexity/die space. The recommended way to perform division or square root
is using the Newton-Raphson method. this uses several additions and multiplies, which
are pipelined now. What is missing is the lookup table but we don't have one handy.
So the overall latency is not much improved, but the operations are pipelined !
and the scheduler doesn't change.

As said earlier, the non-pipelined division is an exception.
And an exception is not meant to be repeated.
In the ALPHA, there is not even a real divider IIRC.
Everything is newton-raphson, and multiplication is pipelined too.
BTW how many 32 or 64 cycle unit types do you know ?

> If two long latency EU's both want that slot you have a problem.
it's not the problem of "both want that slot" :
it is detected the old way.

however if more than 2 instructions are decoded at the same time,
the FIFO idea will be dropped. scheduling will be either checked
during instruction fetch (and stored along with the instructions
in the Icache) or a new approach (FSM in the scoreboard) will be used.

> Ok so you can have special circuits in the decoder to get around
> this, but that is yet more special case handling, rather unmodular.
modularity is fine, but integrating them as efficiently as possible
is another issue !
your approach would be fine if the units changed all the time, at run time.
However, the units are hardwired, completely under control, and known
in advance, so FC0 simply needs a scoreboard and a scheduler FIFO.

> > Another point that should be made clear : the LUT that describes the
> > latency of the instructions is "compiled" and not maintained
> > by hand :-)
> > Of course each module should include the specification of the latency
> > so that it can be automatically handled when it is compiled.
> > we're not masochistic ;-)
> Good!
again, compare the cost of "updating" this LUT and this of managing the
instruction set decoder as a whole : the latency is probably only 10%
of the workload. When a new unit is added, new instructions are also decoded
and this is another worry.

> > In fact, i think that it is not a high price compared to the relative simplicity
> > of the rest of the FC0, and it doesn't impact much the ISA. other F-CPU
> > implementations will certainly use different approaches.
> The LUT s "compiled" fine, but you still need actual alterations to the
> scheduler for particular EU implementations, e.g. special cases like the
> long latency divide unit.
there is no real impact of the divider on the FC0.
just an opcode in the map, a Xbar port, a counter in the scheduler.
Other units, if pipelined, only need the opcode and the Xbar port.
if not pipelined, a "busy" flag is also required. is it enough ? :-)

> In my proposal this would not require any special
> modifications. A pipelined divide unit could be "plugged in" instead of the
> serial shift-subtract version without ANY scheduler modifications.
this would be perfect for hotswappable CPU units, ie in the CDC era computers :-)
but since we know the latency in advance, it is not necessary :-)

<>
> > The memory system will seek the data where it is and this is unpredictible.
> > when the data is brought back to the core, we fall back to the predictable
> > latency case : 2 cycles. So we stall the current instruction and reserve
> > the Xbar slot in priority. In most case, the pipeline will even be already
> > stalled because the fetch took so much time it stopped the execution of the
> > rest of the software.
> So you do stall your pipeline.
or more exactly, bubbles are inserted. the following instructions are not issued.
but the execution is stopped only when there is a data dependency
issue : ie you request a data and you use it in the following instruction.

OTOH, as long as you don't request the use of the destination register of a load
instruction, you can execute as many instructions as you want without "stalling".

> This is more than just stopping the issue of the next instruction, right?
no. it's "only" that.

> This is stopping all execution so that the
> returning loaded data can go into the Xbar at the end slot immediately.
> Whatever else would have gone there must be stopped. How do you stall your
> pipeline? I agree clock enable is not necessarily pretty but how do you
> stall a pipeline without it?
simply by not sending a "next instruction, please" signal to the fetcher :-)
well it must be refined but it's the idea.

> > The second major flaw of your text is that it is almost an OOO system
> > (it made me think about PowerPC) and it would work well with renamed registers.
> > However we have fixed/physical registers and it creates a new bunch of problems
> > when a trap/IRQ/fault etc occurs. It is a dificult problem to solve elegantly.
> > In the FC0 it is solved by not sending (potentially) faulty instructions.
> > the scheduler and scoreboard know the latency of each instruction and
> > they work around this problem.
> > You did not mention the behaviour of your units in the case of a context switch
> > or trap. maybe your solution will be more complex or heavy than really necessary :
> > additional buffers, new flags ...
>
> My proposal is most definitely not OOO, I will speak more of this later. In
> my proposal too I do not send potentially faulty instructions. I handle
> context switches and traps the same way you do now. I have not recommended
> altering the whole F-CPU design!
well, there is F-CPU (the ISA etc) and the FC0 (the currently designed core).
> Just improving the scheduler to improve
> modularity and maintainability and possibly performance.
as soon as the scheduler is impacted, it changes a lot of things.

However, you only described the execution units. You should now work on the
"write prioritizer" and the scheduler will be derived from it.
Currently the FC0's scheduler is derived from the Xbar and the execution unit's
characteristics. funny how the methods are often the same.

have fun,

> Hans Summers
> http://www.HansSummers.Com

YG

speaking for himself
Yahoo! Groups Sponsor

www.  
From Carsten899@aol.com Thu Feb 8 18:20:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00498 for ; Thu, 8 Feb 2001 18:56:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 18:56:49 +0100 (MET) Received: (qmail 24795 invoked by uid 0); 8 Feb 2001 17:20:45 -0000 Received: from mu.egroups.com (64.211.240.238) by 10.1.4.112 (mx12) with SMTP; 8 Feb 2001 17:20:45 -0000 X-eGroups-Return: sentto-1101623-2311-981652842-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 08 Feb 2001 17:20:43 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 17:20:41 -0000 Received: (qmail 49432 invoked from network); 8 Feb 2001 17:20:41 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Feb 2001 17:20:41 -0000 Received: from unknown (HELO imo-r03.mx.aol.com) (152.163.225.3) by mta1 with SMTP; 8 Feb 2001 17:20:41 -0000 Received: from Carsten899@aol.com by imo-r03.mx.aol.com (mail_out_v29.5.) id r.b1.6dcdcbc (17385) for ; Thu, 8 Feb 2001 12:20:36 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 12:20:36 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e7c0b81eb833148bad65368f1183245d Status: R X-Status: N >>well ... i don't want to break the CMB structure but it "would" be
>>preferrable to have : PC, MSR and finally r1 to 63.

No problem, as long as its known.

Q: Interrupt Enable flag is actually the only flag inside the MSR?

>>looks like a user task will need 2 CMB : 1 for user and another for kernel
mode
>>:-/

I think so. If interrupts are allowed during SYSCALL, there has to be some
memory area to "store" the content of the registerfile during interrupt. at
least the whole thing looks a bit like a two-level-stack to me.

Having the following cases:

(1) IRQ interrupts user code:

    User code ---- IRQ / User Register file save ----> IRQ code

(2) User code calls xystem code:

    User code ---- SYSCALL / User Register file save ----> System code

(3) User code calls System code, IRQ interrupts system code:

    User code ---- SYSCALL / User Register file save ----> System code ---
IRQ / System Register file save ----> IRQ code

i dont see any other cases.

carsten
Yahoo! Groups Sponsor

www.   
From Jeff Davies Thu Feb 8 18:57:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00603 for ; Thu, 8 Feb 2001 19:08:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 08 Feb 2001 19:08:20 +0100 (MET) Received: (qmail 13922 invoked by uid 0); 8 Feb 2001 17:51:50 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx10) with SMTP; 8 Feb 2001 17:51:50 -0000 X-eGroups-Return: sentto-1101623-2314-981654700-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 08 Feb 2001 17:51:42 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 17:51:39 -0000 Received: (qmail 36617 invoked from network); 8 Feb 2001 17:51:39 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 8 Feb 2001 17:51:39 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta2 with SMTP; 8 Feb 2001 17:51:38 -0000 Received: from modem-122.kansas.dialup.pol.co.uk ([62.137.67.122] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14QvEF-0007UB-00 for f-cpu@yahoogroups.com; Thu, 08 Feb 2001 17:51:36 +0000 Message-ID: <3A82DE03.A384CA61@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@yahoogroups.com References: From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 17:57:23 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d5a02ce67426e211e4c705642a1a89ef Status: R X-Status: N >
> I think so. If interrupts are allowed during SYSCALL, there has to be some
> memory area to "store" the content of the registerfile during interrupt. at
> least the whole thing looks a bit like a two-level-stack to me.
>

I think in dicussions on this list about 1.5 years ago, we decided that SYSCALL
would
disable interrupts, set supervisor mode, SRB just like any other interrupt.
The handler would reenable interrupts at the appropriate time (new value loaded
into pointer
to backup area). Obviously with an interrupt controller of some sort, the IRQ
line will continue
to be held low until the relevant bit is cleared in the controller's registers.
I imagine that the Interrupt controller will be designed later, or an off the
shelf one put in place.
This really depends where the core is going. (ie what hardware is attached).

Jeff Davies
Yahoo! Groups Sponsor
www..com
From Yann GUIDON Thu Feb 8 19:22:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00311 for ; Fri, 9 Feb 2001 00:03:05 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:05 +0100 (MET) Received: (qmail 15784 invoked by uid 0); 8 Feb 2001 18:29:08 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx03) with SMTP; 8 Feb 2001 18:29:08 -0000 X-eGroups-Return: sentto-1101623-2315-981656922-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 08 Feb 2001 18:28:45 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:28:41 -0000 Received: (qmail 24337 invoked from network); 8 Feb 2001 18:28:40 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 8 Feb 2001 18:28:40 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 8 Feb 2001 18:28:40 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA27313; Thu, 8 Feb 2001 10:28:34 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVFC; Thu, 8 Feb 2001 18:33:35 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82E3CF.98B62EF9@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DD@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 19:22:07 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: fcca6d709228d7b1629b3594ec58b256 Status: R X-Status: N hi !
this is the following of the thread.
some very interesting points in here.

Hans Summers wrote:
> > You issue an instruction when the data is ready,
> > i issue if the data can be written (that's an illustration, of course).
> > This means that all the mechanism that decides what EU will write its
> > result, is brought somewhere else. This has to be done
> > somewhere anyway.
>
> You also issue an instruction when data is ready. You stall instruction
> issue when the source register data is not ready.
yeah, i was only illustrating the concept.
what you can see is that it can be done early with no overhead because
it is in parallel with the instruction decoding, register reading,
and several other verifications.

> The difference is that you
> check if an execution unit can write the data before issuing it, I check at
> the end of execution. That's the only difference.
but it makes a big difference in practice.

> By doing this and moving
> the FIFO into the EU's I make the system very modular and eliminate the LUT.
1) no need to eliminate the LUT : it takes a limited room and the instruction
decoder takes more room (the "LUT" is only one of the many outputs of the
instruction opcode decoder). It can be determined and it doesn't change often
enough to justify the redesign. I don't know if you can program in VHDL
but making a LUT is really not difficult. VHDL has support for constant declaration
with very flexible stuffs (hey, you can even define a constant with the contents
of a file that is loaded at runtime :-D)
2) modularity is not yet the principal issue in the project.
The first issue was to perform any operation as fast as possible
(with a compromise for the IDU), so we had to separate the execution units.
Now if modularity becomes critical (ie, hundreds of EU are added every month)
it is our responsibility to write the manual and the shell scripts that
help add a new unit (advices, checklist etc.)

> Elsewhere in other threads I have read about the instruction decode taking 2
> cycles. With my method you may be able to to it in one, as you have less
> checking to do. I don't know. Taking one cycle off the latency of every
> instruction would be a major performance enhancement.
reducing the decoding time sure helps but your scheme would not help.
you have not read everything either because i propose to make the "issue"
in parallel with the Xbar cycle :-) The "decoder" is simply a lot of
tables and flag checks that are sent to the "issue" stage, which validates
or not the current instruction.
My problem was that the "issue" part would not fit in the allowed stage depth,
but i am working now on performing this operation in parallel with the Xbar cycle.

> > As Michael pointed, it allows a compiler to statically schedule the CPU.
> > it has an invaluable advantage when high performance is at stake because
> > you can GARANTEE the execution time. It is impossible to predict the
> > execution time of any piece of SW on OOO cores.
>
> My proposal is NOT, definitely not, OOO. I don't really fully understand all
> the objections to OOO but I appreciate that it is at any rate a lot more
> complex etc and undesirable. But why is my proposal OOO? It is OOOC just
> like yours!
no because you moved the Xbar write control at the end of the pipeline.

> Let me make two assumptions:
>
> 1) I abandon variable data-dependent latency. Most of the comments against
> my proposal argue against the unpredictability of this approach. Whilst it
> is an interesting intellectual exercise and fun to consider,
(i agree :-))
> Ok I can see
> that you don't want to complicate the compiler optimisation. Doubtless you
> have all spent a lot of time considering the various trade-offs and decided
> that guaranteed execution times will be beneficial. I accept that, so shelve
> the compressible pipeline, early completion etc etc (at least temporarily).
the incompatibility is only with FC0. the whole F-CPU is general enough
to not care... so maybe when FC0 will start to work, the designs you proposed
could be mature enough for FC1. Variable latency can be used for TTA for example ;-)

> 2) Prioritise the completion find-first tree such that the EU's with the
> longest latency always have the highest priority if they complete at a
> simultaneous time to a shorter EU. This is very easy, since it just means
> ordering the inputs to the find-first tree such that the long latency EU's
> are first.
just one question : While your value is waiting to be written back
to the register set, where/how is it temporarily stored ?
- if you stall the pipeline stage, it is similar to a gated clock.
-  if you use a FIFO or new temporary registers, it is similar to what
the PowerPC does : it is called "temporary registers" and the FC0 tries
its best to avoid that. This is why i have spoken about your proposition
as "looking like OOO units". frankly no pun, it's only a cultural/architectural
shortcut/evocation. However it acts on me as a warning signal that it is
not compatible with the design of the FC0.
Even though the current scheme seems to be uselessly complex for you,
it indirectly avoids the need to insert "temporary registers" where
stalling the pipeline would have done almost the same thing (at a higher
clock speed).

> Can you not see that if you do this, you get IDENTICAL results to your
> current scheduler?
almost.
> Instructions are issued in the same order as yours, the
> results are written in exactly the same order as yours,
not necessarily : it will depend on your last selection stage.
that's why you are encouraged to refine it.
as long as there's an uncertainty, i won't leave you comfortable
with your idea ;-)

> and all the
> instructions complete in a precise deterministic number of cycles. The
> latency between the instruction arriving at the decoder and the result being
> written is identical. Correct me if I am wrong! Now you're not seriously
> going to tell me that by abandoning early completion optimisations etc and
> choosing a particular prioritisation scheme for my completion, I am changing
> the whole processor from OOOC to OOO!
i didn't say that, i was saying that your execution units were more
adapted to OOO cores, look at a PowerPC book/manual.

> Therefore, with my proposal the same beloved guarantees exist,
not all. the prioritizer is still blurred ...

> the compiler
> can be identical, everything the same, except that the design becomes tidy
> and modular, and probably uses less area too.
this is not certain. As you said, it's almost the same thing,
there are very similar features, except that FC0 was created long ago,
enough to solve the conceptual problems :-)

> > > Overall I concluded
> > > that whatever problems would be faced in register bypassing would be the
> > > same in my design and the current one. My design doesn't address that issue,
> > > and I didn't think it makes it harder to solve.
> > mmm you should think a bit more :-)
> See above. 6 extra bits in the Xbar, the comparison takes place in only one
> place and the register bypass remains the same.
what bothers me here is a probable underestimation of the propagation times.
it is still a bit unclear for me, whether you can perform all those
operations in one cycle. if not, you are forced to compare 1 stage before,
therefore in the EU themselves. in this case, the bypass idea can be forgotten
(sadly enough, the Xbar's purpose was also to allow bypassing).

> > > > > An execution unit can even be non-pipelined and use the same mechanism. In
> > > > > this case it can latch the destination register and output it to the
> > > > > destination register output when the execution unit is complete. The simple
> > > > > non-pipelined division unit can still have its 6-bit counter, but it will
> > > > > now be inside the execution unit not the scheduler. At the end of the count,
> > > > > the unit will output the completion bit and the 6-bit destination register
> > > > > number.
> > > > IMHO an EU will always be `pipelined' -- there's at least one register at
> > > > the input and one at the output, and n (>= 0) between them.
> > > There doesn't necessisarily need to be a register at the output. If the
> > > final stage of the EU is considered to be latching the data into the Xbar
> > > for result write, the final pipeline register can (should) be omitted or it
> > > just wastes a cycle...
> > nope. we have "very thin stages" and we consider the pipeline as an alternance of
> > logic and flip flops. the Xbar is considered as a "logic" layer and the FF have
> > to buffer the data while it is propagating.
>
> Of course, and so do I (consider pipeline = alternate logic and flip flops).
> One pipeline stage consists of a logic layer and a FF layer. If each EU has
> a FF at the start and end, and the Xbar just a logic layer, then really the
> EU's are 2.5 stages long for example and the Xbar 0.5 stages long.
don't worry, the Xbar is large enough to fill a stage :-)
otherwise, it's too early to start "time-budgetting" the FC0 in the absence
of a stable core.
> But really all you have done is move the Xbar's FF onto the end of each EU so
> it's the same thing. Fine whatever. I did say I wasn't aware of all the
> details of the Xbar design and that variation to the inputs and outputs of
> my EU's may be required. It is the principle of my proposal which is
> important and remains the same.
<>
> > > With my proposal a shift-add iterative multiplier could be
> > > replaced with a parallel multiplier transparently. Throughput would increase
> > > and latency may change, but elsewhere the processor would require no change.
> > Michael has already done a SIMD 64-bit multiplier with 6 stages.
> > I don't know the conditions for early exit (with 8, 16 and 32 bit data)
> > however but it can be easily encoded into the "Latency LUT".
> Agreed. And you will "compile" your LUT so it will be easy. But you will
> still have to make changes to the scheduler circuit when you change special
> case units like Div, or add more. My proposal never requires such changes
> and requires no LUT.

however, as noted before, adding any execution unit requires much more changes than
you tell us : updating the manual, the instruction map, the compiler etc.,
so a LUT more or less is not much worry at my level.

> > > > > 2.4 XBAR WRITE CONFLICTS
> > > As the current pipeline must also be stallable it will also require clock enable
> > > lines, so no change here.
> > wrong. "stall" means "the current instruction in the decoder is not ready",
> > while the rest of the execution pipeline flows its way normally...
> > there's a little difference now :-)
> > If the whole pipeline was stalled because a source register
> > is not ready, it would deadlock the CPU ;-P
> Yeah I do realise that. But it seems to me that you do have to stall your
> FIFO when the results of a non-deterministic load operation arrive back. How
> do you do this without clock enable?
"bubbles" :-) read P&H's books about basic pipelined architectures.
the clock is not stopped, the result of the pipeline is garbage and
it's simply discarded (not used).


> > yep we can play a LOT but it doesn't solve the problem : this lengthens and
> > complicates the scheduling (from my point of view). scheduling has two sides :
> > HW and SW. Currently the FC0 can achieve good sustained performance because
> > it is predictive, it's almost an ALPHA. Hans' propositions look like we're going
> > to make a PowerPC. he has not yet studied how he'll unwind
> > the instruction flow when there's a trouble...
> I haven't studied the PowerPC or ALPHA or any other.
they could give you interesting ideas :-)

> My proposal is purely
> based on what I would consider to be an optimal way of building a CPU.
i think that you're experienced enough to know that there is no "perfect"
CPU, we would know it otherwise :-)
there are only compromises and tradeoffs depending on the constraints.
Anyway, compared to the other precedent ideas that floated on this list,
you're not too far from something realistic :-)

> I come to this with a fresh mind, no pollution from previous processor
> designs.
although this can help, learning from others architectures can give you
a good feeling of what works, what fails, what is possible and how.
Sometimes we even discover that what we invented already existed :-)
One day, i found out that Seymour Cray had invented things i thought about,
but Seymour was in advance with 30 years... so i started to study "crayism",
maybe i could forecast what would happen in 30 years ? :-)

> In fact, I once went some way to designing a whole CPU which was
> intended to be made from TTL logic chips. Of course, the existing 24 hours
> in a day are less than half what would be required to construct such a
> monstrosity in parallel with a a job and a family, so it remained destined
> to lie for ever in the figments of my imagination. But of prime importance
> are "silicon area" (equivalent to how many hundreds of TTL chips I would
> have had to solder up) and simplicity (same reason). I also wanted high
> performance therefore the superscalar type architecture.
today there are FPGAs and that's a solution,
there are also "picogates" (ECL SMT devices with 2 inputs and several outputs
corresponding to different logic functions). the last are able to run at 2.5GHz,
so a CDP of 10 gates is more or less 250Mhz.
the PCB however is not the easiest thing to do ;-)

> I don't plan to unwind instruction flow any more than you do therefore i
> don't need to stufy it. Trouble won't occur (like your current design I
> won't allow it). In fact as I showed earlier, my proposition can yield
> identical execution order to yours, and deterministic latency.
ok now i get it. i was mislead by my first impression.

> It is merely a different way of acheiving it, a way which I believe
> will be more modular, and easier to maintain and implement.
don't worry too much about modularity : the FC0 is a core, not a "system",
therefore all the subpart are closely linked and dependent.
the current "SoC" trend is not directly appliable here because FC0 is
not a real "black box" in the industrial sense (all the sources can
be modified if needed).

> Additionally it will allow all the
> non-deterministic latency stuff if that was required.

on that point, the basic philosophy for the FC0 is clear :
if the operation is possibly undetermined, split it in several instructions
or use the Special Registers (ie: semaphores...)

only load, store and integer division were identified as critical.

> You could in fact even
> have a global flag to switch this on or off, then we could really experiment
> with some real world programs and see if it made anything any faster! Just a
> fun idea.
hehe :-) if you have a home computer, you can already start to play with
the existing VHDL sources.


> > > I view it as a useful side effect rather than the
> > > main advantage of better modularity and simpler
> > > decoder/scheduler (no special cases e.g. Load/Store,
> > > divide; no large LUT to be maintained etc.).
> > we are probably going to need in the future the techniques you described :
> > scheduling completely changes when more than one instruction is issued
> > per cycle, and compilers don't often keep up. even the current GCC port
> > is not good at all at scheduling anything. One cycle or two
> > that can be won is not negligible.
> So why not do it now!
1) we have a FC0 to finish, and the EU are almost written :-)
2) the idea is too new
> Enforce strict deterministic latency on the units and
> prioritise in favour of long-latency units. The results become identical.
not necessarily.
> But the modularity is great, and the potential for other things is very
> high. The design becomes cleaner, less cluttered. No LUT. Simpler.
no : the latency LUT is not significant compared to the more complex
instruction decoder. without LUT, how do you determine what the opcode does ?
it's as if you asked to remove the LUT that determines which unit is used.

> And for future, you will have less redesign to do when you want to issue more than
> one instruction per cycle!
it's not certain.

> > > > [...]
> > > > > 3.4 COMPRESSIBLE PIPELINE
> I do not know how difficult this is to
> implement but it seems quite crucial to a synchronous design and I am
> surprised if you do not need it. As I asked before, how do you stall your
> pipeline on Load data results?
we would normally need it, but there are some tricks and workaround.

the dirty one is to put a mux at the input of the FF, which output is sent
to one mux input. the clock still samples the input of the FF but depending
on the MUX command, the precedent or current data is sampled.

This is more or less what is done to delay the issuance of the instructions,
the rest of the pipeline only contains repeated data (the garbage will propagate
through the pipeline but the result won't be used or latched by the register set).

> > > > > 4   CONCLUSION
> > > > >
> > > > > My proposed replacement for the current
> > > > > scheduler unit is conceptually simpler.
> > however it makes the compiler much difficult to write.
> As I said above. If you enforce fixed latency and prioritise long latency
> instructions then the issue, completion and latency are identical to your
> current design, therefore the compiler is the same.
so if it's identical, why change what already exists ? :-D

> > > > > The decoder/instruction issue unit is made more simple since all it
> > > > > does is check availability and then issue.
> > However how do you check for the availability ?
> > you have to read the scoreboard bits,
> > they are set when the Xbar write ports are in use,
> > this means a lot of wires, comparators, latency.
> > with the FIFO approach, we can perform bypass etc.
> > more easily than you'd think :-)
>
> See above. I check data availability from the
> scoreboard at the same time as you.
this is the dark spot : it has not been extensively studied,
i can't speak about inexisting things ;-)
> For bypass 6 extra bits on the Xbar enable the comparison
> to occur in one place.
and what place ? do you imagine the wire length (and therefore
surface because 6 wires * 3 read buses * several millimeters
uses some surface) it requires ?


> > > > The availability check may become more complex when we
> > > > want to bypass results.
> > > Agreed, but presumably the same issues affect the current design.
> > "presumably". i think that his approach leads us to a completely different
> > style of CPU, more suited to pure OOO.
> As above. No OOO, mine is also OOOC and identical to yours when applying
> specific contraints and priority choices.
yep i know but the best way to use your technique is when the instructions
are completely decoupled from execution, and OOO seems to be the best place.
some of the managing mechanisms are already part of the usual OOO cores,
and adding a variable latency unit won't require much modifications.

> > > > > It will be easier to develop among a distributed group since the execution
> > > > > units are externally precisely defined. Unit designers can enhance execution
> > > > > units without affecting the rest of the design or requiring any changes
> > > > > elsewhere (no latency LUT!).
> > > > Yep, that's the biggest advance, IMHO.
> > i don't think it's such a problem however...
> > it's a matter of good coding practice and reading the
> > readme.txt files...
>
> So you can compile in the latency.
that's the purpose of a compiler :-)
the VHDL langage allows a lot of flexibility for this purpose.

> But you can't alter the fact that your
> current scheduler has extra circuits for special case execution units.
either you make us a pipelined SIMD division unit, or you make a die space/latency
compromise. Considering that division is often non critical for usual applications,
it looks harmless to "arrange" the scheduler this way. If you remove the IDU,
there will be no special change to do.

> The scheduler is intimately tied up with the choice of EU's in the
> implementation and the specific implementation of the EU's. My proposal does
> away with all that. It's not just the latency LUT which dissapears.
what's the point if a similar amount of HW is needed at the end of the EUs to
select 2 results among the available ones ?

> > > > > The architecture is easily extensible. It is easy to see how more ports
> > > > > could be added to the Xbar, or the processor made superscalar by issuing
> > > > > more than one instruction per cycle. It is even possible to duplicate
> > > > > execution units if necessary. The complexity of the decoder will remain
> > > > > manageable.
> > > > You still have to prove that...
> > > True. Many issues remain there.
> > i'd say : IRQ for example :-)
> > maybe you know a simple turnaround...
> Same as yours!
so you can maybe write another paper explaining the rest of the core architecture ?
the first one is well written (even though some facts are inacurate).

> > > Nevertheless the same issues exist with the
> > > current design. By the simplications in my proposal and the improved
> > > modularity etc at least we have the best chance of solving the challenges
> > > when the time comes to consider them.
> > time will come. but we have something to finish first ;-)
> Precisely my point. Surely the improved modularity will help
> us to finish FCO more easily.
most of the critical EUs are written or already studied.
INC will be rewritten in a month or two, SHL should appear a bit later.
I am now able to spend one more day out of work and i'll maybe restart
some heavy contribution.
well please remember me, when the decoder will be designed, to
include the functionality that transforms Rm=Rn+0 into Rm=Rm ?
(add/sub -> move, mul->clear, div -> zero or trap if divisor)

> > > My main objective in this proposal was to tidy up the scheduler design to
> > > get better modularity and maintainability.
> > nothing comes from free :-)
> > you "solve" problems, or more precisely you move them around,
> > it's an endless game. this explains the large variety of core
> > types today.
> > FC0 starts from one POV, you start from another and we get different
> > behaviours that can be good or bad depending on the situation.
> This does come for free. As I said, enforce fixed latency and prioritise the
> right way and you have the same behaviour but a neater more modular design.
as said earlier, modularity is not the principal issue.


> > > It could be interesting and novel but if we don't like it we can
> > > leave it out. Personally I like the unpredictability, as long as it doesn't
> > > degrade performance (I believe it can only improve it here).
> > it "could" but it depends on the cases.
> In conclusion: if you don't like variable latency fine. Fix it, prioritise
> long latency EU's and you have identical results to your current scheduler
> design. Most objections are against the unpredictability. So this way there
> will be none. But there will be all the modularity and maintainability
> advantages and the the new structure looks forward to future implementations
> when we will be considering multiple issue.
of course the ideas are not buried. they simply come too late to influence the FC0.
a newer core could probably benefit from this.

ok, there's another email to answer...

> > > >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> > > Hans Summers
> > YG
> Hans Summers
YG
Yahoo! Groups Sponsor

www.  
From Yann GUIDON Thu Feb 8 19:35:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00331 for ; Fri, 9 Feb 2001 00:03:13 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:13 +0100 (MET) Received: (qmail 4941 invoked by uid 0); 8 Feb 2001 18:42:19 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx18) with SMTP; 8 Feb 2001 18:42:19 -0000 X-eGroups-Return: sentto-1101623-2317-981657725-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 08 Feb 2001 18:42:07 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:42:04 -0000 Received: (qmail 81281 invoked from network); 8 Feb 2001 18:42:03 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 8 Feb 2001 18:42:03 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 8 Feb 2001 18:42:03 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA29334; Thu, 8 Feb 2001 10:41:59 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVFL; Thu, 8 Feb 2001 18:46:59 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82E6F3.6187765D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A82804C.BF4E279C@llandre.freeserve.co.uk> <3A829594.F4483C93@mentor.com> <3A82D7A3.C6376C44@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 19:35:31 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] sony chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b1f862a541316344d6e92f2d7209b72d Status: R X-Status: N hi !

Jeff Davies wrote:
> Yann GUIDON wrote:
> > Jeff Davies wrote:
> > > Did you guys see the slashdot article about Sony's new graphics controller?
> > > It is rumoured to be for the PS/3. They've started getting some test chips off the
> > > production line, and yield is apparently good.
> > > This is a development of their existing graphics chip (in the PS/2).
> > > The existing one has 4 meg DRAM on chip with a 2500 bit bus.
> > > The new one appears to be not too different, except it has 32 MEG on chip!!!
> > wow, and what do you have to store on that ? a 4MB frame buffer is hardly used...
> > Z-buffer + RGB, on a TV resolution, is not that much silicon today.
> > > (and still, the 2500 bit bus).
> > "only" ? :-)
> >
> > > What about one of these babies on FCPU motherboard ???
> >
> > yeah i wouldn't refuse but :
> >  - sony keeps his baby for him
> Maybe not, perhaps they will sell them as parts.
"> ah dream, dream." you wrote :-)

> >  - i'm not going to sign any NDA and the F-CPU project
> >     is not the good place either for that
> >  - what about a "free" version ? :-)
>           ^-- one step at a time.
> What about 32 meg on chip loading 2500 bit cache lines and instead of graphics
> processor, a FCPU on chip... (in my linux wristwatch), with 3d iGlasses type of thing.
> ah dream, dream.

dunno, maybe you'll need the embedded 15W power regulator and the fan ?
maybe you can hold the batteries in your pocket ? :-)

> Jeff Davies

YG

speaking for himself
Yahoo! Groups Sponsor
www..com
From Ben Franchuk Mon Feb 5 00:00:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00334 for ; Fri, 9 Feb 2001 00:03:13 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:13 +0100 (MET) Received: (qmail 2564 invoked by uid 0); 8 Feb 2001 18:50:44 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx08) with SMTP; 8 Feb 2001 18:50:44 -0000 X-eGroups-Return: sentto-1101623-2319-981658241-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ci.egroups.com with NNFMP; 08 Feb 2001 18:50:43 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:50:40 -0000 Received: (qmail 71279 invoked from network); 8 Feb 2001 18:50:40 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 8 Feb 2001 18:50:40 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 8 Feb 2001 19:51:44 -0000 Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA11429 for ; Thu, 8 Feb 2001 11:41:52 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7DDF18.A410CBE1@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A82E5C9.CE46E5D3@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 16:00:40 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3403be50e63b123fd0d6123f84d70193 Status: R X-Status: N Yann GUIDON wrote:

> > Having the following cases:
> >
> > (1) IRQ interrupts user code:
> >
> >     User code ---- IRQ / User Register file save ----> IRQ code
> >
> > (2) User code calls xystem code:
> >
> >     User code ---- SYSCALL / User Register file save ----> System code
> >
> > (3) User code calls System code, IRQ interrupts system code:
> >
> >     User code ---- SYSCALL / User Register file save ----> System code ---
> > IRQ / System Register file save ----> IRQ code
    (4)  IRQ interrupts and then calls system code to task swap.
         Modern OS's after interrupts reschedule the current running
         task.
 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www. 
From Yann GUIDON Thu Feb 8 19:41:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00337 for ; Fri, 9 Feb 2001 00:03:14 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:14 +0100 (MET) Received: (qmail 23741 invoked by uid 0); 8 Feb 2001 18:50:43 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx10) with SMTP; 8 Feb 2001 18:50:43 -0000 X-eGroups-Return: sentto-1101623-2318-981658079-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 08 Feb 2001 18:48:02 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:47:58 -0000 Received: (qmail 79534 invoked from network); 8 Feb 2001 18:47:57 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 8 Feb 2001 18:47:57 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 8 Feb 2001 19:49:02 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA00372; Thu, 8 Feb 2001 10:47:54 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVFQ; Thu, 8 Feb 2001 18:52:55 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82E857.9512B635@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A82DE03.A384CA61@llandre.freeserve.co.uk> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 19:41:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0fec9a843ab66ffcf06092981ffe0996 Status: R X-Status: N hi again !

Jeff Davies wrote:

> > I think so. If interrupts are allowed during SYSCALL, there has to be some
> > memory area to "store" the content of the registerfile during interrupt. at
> > least the whole thing looks a bit like a two-level-stack to me.
>
> I think in dicussions on this list about 1.5 years ago, we decided that SYSCALL would
> disable interrupts, set supervisor mode, SRB just like any other interrupt.
was it syscall or trap ?

> The handler would reenable interrupts at the appropriate time
> (new value loaded into pointer to backup area).
i have the vague souvenir of a piece of code i had written to illustrate that.
unfortunately i have to dig deep in the archives to find that thread...
Eiserloh was still here IIRC.

However now things are different : we have split the library function calls
(syscall) and the error handlers (trap). trap would still work like you described.

> Obviously with an interrupt controller of some sort, the IRQ line will continue
> to be held low until the relevant bit is cleared in the controller's registers.
> I imagine that the Interrupt controller will be designed later, or an off the
> shelf one put in place.
> This really depends where the core is going. (ie what hardware is attached).
well i don't think that an IRQ controller would be an issue : i've designed one
years ago and the principle is rather simple and efficient.

> Jeff Davies

YG

speaking for himself
Yahoo! Groups Sponsor
From brendaahowell@yahoo.com Thu Feb 8 22:54:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00340 for ; Fri, 9 Feb 2001 00:03:16 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:16 +0100 (MET) Received: (qmail 27609 invoked by uid 0); 8 Feb 2001 18:59:15 -0000 Received: from hn.egroups.com (208.50.99.199) by 10.1.4.119 (mx19) with SMTP; 8 Feb 2001 18:59:15 -0000 X-eGroups-Return: sentto-1101623-2320-981658726-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 08 Feb 2001 18:58:47 -0000 X-Sender: grl40-276opp462@address.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:58:45 -0000 Received: (qmail 30571 invoked from network); 8 Feb 2001 18:58:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 8 Feb 2001 18:58:45 -0000 Received: from unknown (HELO mail.oflc.gov.au) (203.41.245.33) by mta1 with SMTP; 8 Feb 2001 18:58:44 -0000 Received: from 216.3.181.185 (04-185.031.popsite.net [216.3.181.185]) by mail.oflc.gov.au (AIX4.3/8.9.3/8.8.8) with SMTP id FAA10300; Fri, 9 Feb 2001 05:45:07 +1100 Message-ID: <000004491eb8$000029e0$0000627b@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: grl40-276opp462@address.com From: brendaahowell@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 13:54:05 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Start the new year out right! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: b09158831506a0e07a28bb478726d5e1 Status: R X-Status: N jkjhggbgg Renting or Selling your TimeShare has never been easier!
                   Let us do it for you!

      To learn more about this unique program
       Click Reply with your name, complete
       telephone number(including area code)
      and the Resort and we will be in touch
                  with you shortly!



****************************************************
To be removed from future mailing please
reply with "remove" in the subject.










jkjhggbgg Renting or Selling your TimeShare has never been easier!
                   Let us do it for you!
Yahoo! Groups Sponsor

www.   
From Carsten899@aol.com Thu Feb 8 20:04:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00348 for ; Fri, 9 Feb 2001 00:03:17 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:17 +0100 (MET) Received: (qmail 14776 invoked by uid 0); 8 Feb 2001 19:05:14 -0000 Received: from ci.egroups.com (64.211.240.235) by 10.1.4.119 (mx19) with SMTP; 8 Feb 2001 19:05:14 -0000 X-eGroups-Return: sentto-1101623-2321-981659110-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 08 Feb 2001 19:05:12 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 19:05:10 -0000 Received: (qmail 38097 invoked from network); 8 Feb 2001 19:05:08 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 8 Feb 2001 19:05:08 -0000 Received: from unknown (HELO imo-r17.mx.aol.com) (152.163.225.71) by mta2 with SMTP; 8 Feb 2001 19:05:07 -0000 Received: from Carsten899@aol.com by imo-r17.mx.aol.com (mail_out_v29.5.) id r.27.112cbfb2 (4412) for ; Thu, 8 Feb 2001 14:04:56 -0500 (EST) Message-ID: <27.112cbfb2.27b447d7@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 14:04:55 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: eb0bff7ab20c75e623fe5771df9aba4e Status: R X-Status: N >> The handler would reenable interrupts at the appropriate time
>> (new value loaded into pointer to backup area).
>i have the vague souvenir of a piece of code i had written to illustrate
that.
>unfortunately i have to dig deep in the archives to find that thread...

Did you think of a code as this:

* On entering the syscall interrupts are disabled.
* The syscall code builds a new CMB ( or uses an already setup SYSCALL task
CMB)
* Copyies the content of the register file of the user code CMB into the new
CMB.
* Sets up MSR an PC to appropriate values.
* Sets the "builded"/SSYCALL-Task- CMB into "next CMB"
* Executes RTE.
* Now it can enable interrupts, they will not disturb the user code CMB
anymore.

carsten
Yahoo! Groups Sponsor

www.
From Yann GUIDON Thu Feb 8 19:30:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00354 for ; Fri, 9 Feb 2001 00:03:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:19 +0100 (MET) Received: (qmail 520 invoked by uid 0); 8 Feb 2001 19:16:35 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx22) with SMTP; 8 Feb 2001 19:16:35 -0000 X-eGroups-Return: sentto-1101623-2316-981657426-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 08 Feb 2001 18:38:13 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 18:37:05 -0000 Received: (qmail 54503 invoked from network); 8 Feb 2001 18:37:04 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 8 Feb 2001 18:37:04 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 8 Feb 2001 19:38:09 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA28534; Thu, 8 Feb 2001 10:37:01 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVFG; Thu, 8 Feb 2001 18:42:01 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82E5C9.CE46E5D3@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 19:30:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5619374bbc273b9e01e5b02c9aad4bed Status: R X-Status: N greets from the f-cpu hotline :-)

Carsten899@aol.com wrote:
> >>well ... i don't want to break the CMB structure but it "would" be
> >>preferrable to have : PC, MSR and finally r1 to 63.
> No problem, as long as its known.
> Q: Interrupt Enable flag is actually the only flag inside the MSR?
oh no :
there are all the capability bits (TLB on, TLB SRs modifiable, and others),
the 4*4 reserved bits for the size attributes, and i forget a lot...
single-step flag, too.

> >>looks like a user task will need 2 CMB : 1 for user and another for kernel mode
> >>:-/
> I think so. If interrupts are allowed during SYSCALL, there has to be some
> memory area to "store" the content of the registerfile during interrupt. at
> least the whole thing looks a bit like a two-level-stack to me.
>
> Having the following cases:
>
> (1) IRQ interrupts user code:
>
>     User code ---- IRQ / User Register file save ----> IRQ code
>
> (2) User code calls xystem code:
>
>     User code ---- SYSCALL / User Register file save ----> System code
>
> (3) User code calls System code, IRQ interrupts system code:
>
>     User code ---- SYSCALL / User Register file save ----> System code ---
> IRQ / System Register file save ----> IRQ code
>
> i dont see any other cases.
>
> carsten

however, as i wrote later, maybe that it can be avoided if the SYSCALL
did not trigger SRB. since syscall is meant to provide services through
protected libraries, the SRB overhead migh not be justified.
This means that we need another RET function (SYSRET ?) that gets back
to the initial CPU (user) state.

Well, it means that there are not 2 CMB but 1 CMB with 2 MSR slots.
ouch. it gets crazy here.

YG

speaking for himself
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Carsten899@aol.com Thu Feb 8 20:28:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00363 for ; Fri, 9 Feb 2001 00:03:21 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:21 +0100 (MET) Received: (qmail 24060 invoked by uid 0); 8 Feb 2001 19:43:11 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx04) with SMTP; 8 Feb 2001 19:43:11 -0000 X-eGroups-Return: sentto-1101623-2322-981660494-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 08 Feb 2001 19:28:17 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 19:28:14 -0000 Received: (qmail 5437 invoked from network); 8 Feb 2001 19:28:12 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 8 Feb 2001 19:28:12 -0000 Received: from unknown (HELO imo-r04.mx.aol.com) (152.163.225.4) by mta2 with SMTP; 8 Feb 2001 19:28:11 -0000 Received: from Carsten899@aol.com by imo-r04.mx.aol.com (mail_out_v29.5.) id r.b8.1198282b (4412) for ; Thu, 8 Feb 2001 14:28:08 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 14:28:08 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 37a44f666a25b93ab679fb8ff3240c30 Status: R X-Status: N
>>here are all the capability bits (TLB on, TLB SRs modifiable, and others),
>>the 4*4 reserved bits for the size attributes, and i forget a lot...
>>single-step flag, too.

is there a chapter in the manual showing all the bits?

>>Well, it means that there are not 2 CMB but 1 CMB with 2 MSR slots.
>>ouch. it gets crazy here.

It would be CMB with 2 PC and 2 MSR, i think.  1 PC / MSR storing the return
address to user code, 1 PC / MSR storing the return address to system code in
the case of IRQ. Now we have the 2 level stack i mentioned above.

By the way: IMHO the CMB looks like a TSS on X86.

carsten
Yahoo! Groups Sponsor
www. .com 
From Yann GUIDON Thu Feb 8 20:50:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00369 for ; Fri, 9 Feb 2001 00:03:23 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:23 +0100 (MET) Received: (qmail 2434 invoked by uid 0); 8 Feb 2001 20:04:01 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx17) with SMTP; 8 Feb 2001 20:04:01 -0000 X-eGroups-Return: sentto-1101623-2323-981662444-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 08 Feb 2001 20:00:47 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 20:00:44 -0000 Received: (qmail 85356 invoked from network); 8 Feb 2001 19:57:12 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 Feb 2001 19:57:12 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 8 Feb 2001 19:57:12 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA10796; Thu, 8 Feb 2001 11:57:08 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWVG0; Thu, 8 Feb 2001 20:02:09 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A82F88F.9A167DF5@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA52@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 20:50:39 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 38a1fdf64ec67d658b5173d9773244db Status: R X-Status: N hi,
Hans Summers wrote:
> > From: Yann GUIDON
> > Hans Summers wrote:
> > > Hello
> > hello !
> The difference is that my FIFO is distributed between the execution units.
> Each EU has its own FIFO which specifies the latency of the unit. The
> latency information is therefore completely contained in the distribution of
> the FIFO stages, there is no need for a LUT.
as i said earlier, the latency LUT is not an important issue.


> > Now the difference that strikes me is the write stage : we have to prioritize
> > the outputs. it might take some additional time and gates (to my eyes),
> > it makes the compiler (the scheduling part) more complex and can do bad choices
> > from time to time. Not only it could be data-dependent (you seem to have accepted
> > to use that feature in the future only) but it can also become program-dependent !
> > the scheduling could be influenced by a code that the task did not execute
> > (and not control) because of a task switch that could affect the scheduling
> > of another code. i know, it's some science fiction but it illustrates the worries
> > that could arise, and i hate them :-)
>
> The additional time taken to prioritise the outputs is to be done in
> parallel with the last stage of the EU.
that sounds logical.

> The method used is the same as your
> SRB mechanism to decide which register to backup next (by your "dirty" and
> "express request" bits IIRC). As I have pointed out, if you insist on fixed
> latency and prioritise the longer latency instructions, the scheduling
> becomes logically equivalent to your current scheduler. The compiler is
> identical, there is no data dependency or any other potential problem that
> you envisage here, since the order of execution and completion is precisely
> the same as yours, as is the latency.

flaw : the execution is not exaclty the same because i can detect write hazards
in advance. you don't. therefore you would send instructions that wouldn't  be
sent otherwise and the result is not exactly the same, depending on the kind of
instructions you issue.

> The only difference is that in my
> proposal the scheduling becomes implicitly a feature of the collection of
> EU's rather than being done explicitly by a global FIFO and large LUT.
this LUT is not "large". it is a few gates deep, not more.
if you want a "large" LUT, speak about the instruction decoder :-)

> The designer no longer has to think carefully about the scheduling needs of a
> particular EU, since the scheduling falls automatically out as a consequence
> of the distributed architecture. I think it's rather neat, that.
in FC0 too : it will block anyway, but at a difference place.

> > > You also have a large LUT.
> > you can't do without that. if you're bothered by the latency LUT,
> > remember that it's a part of the larger problem of the instruction LUT :-P
> > and with 110 possible opcodes, you understand that it's not a big worry compared
> > to the huge task of maintaining the instruction set tables...
>
> You don't have to do it that way, either. You could do an absolute minimum
> of opcode decoding in the instruction decoder, just enough to determine
> which EU was required for the instruction. The remaining opcode bits which
> specify exactly which flavour of instruction the EU will perform could be
> sent directly to the EU and decoded locally there e.g. multiply: mul, mulh,
> muls, mulsh, smul, smulh, smuls, smulsh; most of these are just a single bit
> whose value determines whether for example the multiplier will save the high
> byte. The EU doesn't really have to do any further decoding. Forgive me for
> being a modularity freak, but I like everything that is concerned with a
> particular EU to be done inside that EU, as far as possible.
that's what is done already.

> Imagine some time in the future. A large number of EU's have been designed
> and the F-CPU is well known. A designer wants an F-CPU implementation for a
> particular purpose. I think he should be able to say, well I want this
> multiplier unit, such and such Floating point addition unit, etc etc. He
> should be able to compile them all together easily. He can only do that if
> the highest modularity is maintained. Otherwise, there might be various
> exceptions which require alterations elsewhere in his core, for example in
> the scheduler. Why should he have to worry about that? Isn't it better if he
> can take these EU's off-the-shelf and use them, without having to worry
> about scheduling issues?

look at the existing VHDL files : they are organised in a logical way,
and we only need to make a EU_template directory with template files,
a few configuration modifications in the VHDL "architecture" file,
and there you are.

Or maybe you don't know (yet) how to program in VHDL,
but i guess you'll learn soon :-)

> > > My proposal uses less area, right?
> > not necessarily. i showed that it's similar to the FIFO, with the
> > lack of predictibility on top of that :-)
> No lack of predictability. I have said several times that by abandoning
> indeterminate latency EU's and prioritising the long latency EU's we obtain
> identical scheduling to your current design. But we make the whole thing
> more modular and maintainable and extensible in the future.
if you say so :-)
the FC0 was thought from start as an extensible frame,
but there is a trap anyway : it is a digital design aimed at speed,
and a minimum of customization is necessary.
Your proposition would fit the vision of companies like ARCcores
because they work in the "true balck box" world.
In contrast, we can modify our sources and optimize on a case by case basis.
this is important when one wants to win the last 10% of performance...

> > > Your FIFO construction is also more
> > > complex (extra OR, AND etc) than my simple one, so each stage is bigger.
> > this apparent simplicity in your design is only "moved" at
> > the end of the pipeline.
> > the decision at the Xbar level will take gates, i think.
> > "nothing comes for free"...
> True, it will. I didn't really make my proposal to reduce the area, but to
> inprove the modularity. And possibly performance if variable latency was
> allowed. But the extra gates work in parallel with the final EU pipeline
> stages so don't increase latency.
the current design also has its share of parallelism :-)

> > However, be reassured that your prioritizing mechanism will
> > not come for free,
> > it will take a whole stage of its own. Your optimism is maybe
> > due to the incomplete
> > analysis of the architecture as a whole. FC0 has started
> > almost 2 years ago and
> > it was not my first attempt, so i had enough time to balance
> > things. It often takes
> > around 18 months to design a CPU and i'm sure that all the
> > questions about your
> > proposed architecture have not been asked. But the sooner you
> > speak about the architecture,
> > the faster it will take shape and become coherent :-)
> The prioritising mechanism will take place during the final stage of the EU
> pipeline, in parallel with that stage. It shouldn't therefore increase the
> latency. I don't propose a change to the whole FCO architecture, only one
> small part of it (the instruction scheduling).
well, i think that you will accept to stand the comparison ?
the only way to know is to implement both versions in VHDL.
so everybody will be happy :-)

> > > Ok. But it is still a special case.
> > so what ? look at your own design for the divider and tell me
> > the difference :
> > there is the counter, the register number. they are simply
> > placed closer to
> > the rest of the scheduling machine. the register value has
> > less travel to do,
> > and we can compare things quickly, in advance of the
> > execution rather than after.
>
> I don't care how much travelling the register number has to do, it's not
> like it takes PETROL or anything.
it takes TIME. the propagation time increases (approx) as the square of
the distance, and that's worrying enough for me.

> I realise your point is that moving
> information from one side of the chip to the other slows things down, but
> don't forget you are FORCED to move the 64-bit data bus to and from the EU
> anyway.
the funny thing with it is that it is not necessary :-)

question :
what would be the functional change IF the register number wasn't close
to the associated pipe stage ?

answer :
nothing.

so if you grouped all the register pipelines at one single point,
you'd have the same behaviour. But now, you can do more things
and compare more conditions.

Compress that and you get my FIFO :-)

> It doesn't matter how quickly you move register numbers around if
> the data bus has to go all that way.
it matters ! example : if you draw a 64-bit bus on 1mm with .5u wires,
it takes .064 mm2 or 64000 u2. it is not negligible !
the shortest the bus, the least surface, the faster, the cheaper...

> > > It is un-modular.
> > it is the "adaptation" of the core to the function it has to perform.
> The adaption is easier the more modular the units are. If the units can be
> added or removed, or changed without impacting the rest of the core it
> becomes easier, right?
yup but at what price ?
as you remark, designing a CPU is not something done in a few minutes.
A lot of manipulations, verifications etc must be performed. it is often
the occasion to optimise some stuff here or there.

> > One of the design strategy is to use the information as soon
> > as it is available.
> > Why wait until the end of a pipeline when you can know the
> > time it will take, BEFORE you get the result ?
> Why not?
you avoid the prioritizer.

> I have the information I need in time to make use of it. I don't
> need it any earlier. Do you agree that the instruction issue order,
> completion order, and latency are IDENTICAL in my case if I enforce fixed
> latency and prioritise high latency EU's?
no because you don't detect the write hazards and you will issue instructions
that i wouldn't.

> This implies that by my proposal,
> without bothering to use the information as soon as it is available, I
> achieve the same result. The scheduling becomes a consequence of the
> architecture. Out of interest what is this "design strategy", is this an
> F-CPU adopted strategy or Comp Arch theory? (the latter I am not familiar
> with).
it is common sense that is unfortunately not used in all existing designs :-)

> > As said earlier, the non-pipelined division is an exception.
> > And an exception is not meant to be repeated.
> > In the ALPHA, there is not even a real divider IIRC.
> > Everything is newton-raphson, and multiplication is pipelined too.
> > BTW how many 32 or 64 cycle unit types do you know ?
> Not many.
pfiuh, that's a good news :-)

> But why IMPOSE that?
because that's the simplest that can be done in the existing frame.

> My point was exactly that it is an exception,
> an exception requiring special treatment in the scheduler. If you already
> have an exception to the rule at such an early stage, it does not bode well
> for the future.
Computer history is full of such examples.
except that here, this exception is local to the FC0, it is independent
>from the instruction set or behaviour. you can make a FC1 and forget about
this "exception".

> I think it is best to try to keep the architecture as
> squeaky clean for as long as possible. Sure, eventually exceptions may be
> inevitable but not so soon! My proposal has no exceptional cases for long
> latency units.
sure, however this is the difference between the "theorical design"
and an "implementation" (mm well, huh). Reality requires some serious
compromises and i don't think that i have reduced the performance or
the evolutivity. remember that Idiv is not the most used operation.

> > > If two long latency EU's both want that slot you have a problem.
> > it's not the problem of "both want that slot" :
> > it is detected the old way.
>
> How is that? So suppose you have one EU that has a latency of 64 cycles and
> one with a latency of 32. They could even be multiple copies of identical
> EU's operating on different word sizes. The 64 cycle one has been processing
> for a number of cycles. An instruction requires the 32 cycle one. Now before
> you can issue the 32 cycle one, you insist on knowing whether it will be
> able to write in 32 cycle's time. So you have to do your subtraction of 8,
> and check the 64-cycle EU's scheduler counter, and work out if the
> number-of-cycles-to-go will conflict with the requirements of your new
> instruction. It's a mess which will get even worse if there are more EU's.
no : if you want more power, you'll have to use N-R algos, they can be pipelined
and interleaved, they have more throughput.
And you confirmed that no other kind of unit was as slow as this one,
so this division exception is REALLY an exception.

> To increase the size of your processor (e.g. multiple instruction issue etc)
> you will have to radically redesign your scheduling.
it will be done anyway. whatever happens, the decoder must be redesigned.
it's the consequence of evolution.

> Why not have a simple
> scheduler now, and not have to redesign later! My scheduler almost doesn't
> exist, it is a consequence of the EU architecture.
if you want to use this type of scheduling, you can start programming now,
there are some VHDL code already available. There is no reason to refuse help,
but if you want to prove your affirmations, the best way is to do it :-)


> > > Ok so you can have special circuits in the decoder to get around
> > > this, but that is yet more special case handling, rather unmodular.
> > modularity is fine, but integrating them as efficiently as possible
> > is another issue !
> > your approach would be fine if the units changed all the
> > time, at run time.
> > However, the units are hardwired, completely under control, and known
> > in advance, so FC0 simply needs a scoreboard and a scheduler FIFO.
> >
> The results from my scheduling will be the same. You agreed it may even take
> less area.
did i agre on that ???
> There should be no damage to the compiler, no damage to the die
> area, and no other negative consequences. Just advantages of more modularity
> and maintainability, and we can look forward to more advanced processors
> (multiple issue) using the same ideas.
if you are so confident, the best thing to do is to start coding :-)

> > > > In fact, i think that it is not a high price compared to the relative simplicity
> > > > of the rest of the FC0, and it doesn't impact much the ISA. other F-CPU
> > > > implementations will certainly use different approaches.
> > > The LUT s "compiled" fine, but you still need actual alterations to the
> > > scheduler for particular EU implementations, e.g. special cases like the
> > > long latency divide unit.
> > there is no real impact of the divider on the FC0.
> > just an opcode in the map, a Xbar port, a counter in the scheduler.
> > Other units, if pipelined, only need the opcode and the Xbar port.
> > if not pipelined, a "busy" flag is also required. is it enough ? :-)
> It will work, true enough. But it doesn't seem to me the most elegant and
> modular, or extensible later.
my "crayist" side tells me to look for all possible tiny optimisations...


> > OTOH, as long as you don't request the use of the destination
> > register of a load
> > instruction, you can execute as many instructions as you want
> > without "stalling".
>
> Clearly when you request the data, you can execute other things while
> waiting, if they don't need that data. But my question is what happens when
> that data arives. It "reserves an Xbar slot in priority". By insereting a
> bubble. Inserting a bubble at a point in the pipeline is equivalent to
> stalling the part of the pipeline after that point for once cycle, otherwise
> how do you insert the bubble?

i think that you mixed two things : insertion in priority, and bubbles.

bubbles are when the pipeline contains useless data that is discarded.

however when the waited data comes from a cache miss,
it inserts the slot request in priority in the scheduler.

The signal is triggered when the first chunck of data (ie : 64-bit word
>from one SDRAM port, or 32 bits from the F-BUS) is available in the LSU buffer.
the chuncks of data pile up, while a request is sent to the scheduler.
This behaves like a superscalar CPU where 2 instructions compete for a single
ressource : as soon as a slot is avaialble, it is allocated in priority to
the LSU (a mini-version of the prioritizer ;-D).
notice that the latency is known and short (2 cycles).
then the data goes its usual way through the pipeline,
just like a load instruction.

> > > This is more than just stopping the issue of the next
> > instruction, right?
> > no. it's "only" that.
> I don't get it still. Even if you stop the issue of the next instruction, if
> you don't stop the pipeline you can't stop the result write of the currently
> executing instructions. So what do you do?
I let all the units work their way.
i simply "hold" the current instruction, wait until a free slot appears,
and allocate it.
If i stopped all the pipeline, then the parallelism brought by the multiple
EU wouldn't be worth bothering...

> > > This is stopping all execution so that the
> > > returning loaded data can go into the Xbar at the end slot
> > immediately.
> > > Whatever else would have gone there must be stopped. How do
> > you stall your
> > > pipeline? I agree clock enable is not necessarily pretty
> > but how do you
> > > stall a pipeline without it?
> > simply by not sending a "next instruction, please" signal to
> > the fetcher :-)
> > well it must be refined but it's the idea.
>
> As above, what about the currently executing instructios which own the FIFO
> completion slots?
they have ultimate priority. they are sent, so they must complete.
maybe it wasn't clear enough.
Of course it would be disastrous to send data when another unit completes...

> > However, you only described the execution units. You should
> > now work on the
> > "write prioritizer" and the scheduler will be derived from it.
> > Currently the FC0's scheduler is derived from the Xbar and
> > the execution unit's
> > characteristics. funny how the methods are often the same.
> The write prioritiser uses the same find-first mechanism you describe in
> your SRB text in the manual. Forget about the "express request" signals, if
> variable latency is not required. Simply connect the inputs to the
> find-first tree in order, with the highest latency unit at the beginning and
> the lowest latency unit at the end. The instruction issue, completion and
> latency is then the same as your existing scheduler. But no LUT, more
> modular etc.

forget about the LUT and the modules, make something that works smoothly instead :-)
your ideas are not bad and you should work on them ! maybe you already have seen the
existing VHDL designs and want to contribute.


> > > Hans Summers
> > YG
> Hans Summers
YG

speaking for himself
Yahoo! Groups Sponsor

www.

From Nicolas Boulay Thu Feb 8 22:39:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00414 for ; Fri, 9 Feb 2001 00:03:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:51 +0100 (MET) Received: (qmail 29882 invoked by uid 0); 8 Feb 2001 21:30:06 -0000 Received: from ei.egroups.com (64.211.240.237) by 10.1.4.106 (mx06) with SMTP; 8 Feb 2001 21:30:06 -0000 X-eGroups-Return: sentto-1101623-2326-981667798-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 08 Feb 2001 21:30:01 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 21:29:57 -0000 Received: (qmail 8229 invoked from network); 8 Feb 2001 21:29:51 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Feb 2001 21:29:51 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 8 Feb 2001 21:29:51 -0000 Received: from ifrance.com (nas25-189.vlt.club-internet.fr [195.36.224.189]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA13303 for ; Thu, 8 Feb 2001 22:29:49 +0100 (MET) Message-ID: <3A83122F.2A630CD1@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 22:39:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b0af4e675b8f77f270b140bca2e92cad Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> >
> > > - In VHDL design, we never, never use latches !! Very few sy= nthiser
> > > could handles this very well (nether verfication program,...= ). You can
> > > only use it for clock gating, that's all.
> >
> > Latches... I mean FF, whatever. FF are everywhere.
> >
>
> I never use VHDL so I can use latches.Gated latches that is.
> D latches are 1/2 the size FF's. Often Master/Slave FF's are
> used instead of the standard D FF in cell libraries. FF's
> are only FREE in FPGA's. RAM on FPGA's is often simple
> latches or master/slave design internally too.

On fpga, it's a particular ff that could be used as FF (with rs) or
latches. And memories are SRAM block about 2 or 4 kbits. Even the little lut or PAL are little SRAM memory.

nicO

> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>

Yahoo! Groups Spons= or
3D""3D""
www..com
3D""
From Nicolas Boulay Thu Feb 8 22:39:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00417 for ; Fri, 9 Feb 2001 00:03:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:52 +0100 (MET) Received: (qmail 2718 invoked by uid 0); 8 Feb 2001 21:29:58 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx21) with SMTP; 8 Feb 2001 21:29:58 -0000 X-eGroups-Return: sentto-1101623-2325-981667794-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 08 Feb 2001 21:29:56 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 21:29:53 -0000 Received: (qmail 8023 invoked from network); 8 Feb 2001 21:29:48 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 8 Feb 2001 21:29:48 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta3 with SMTP; 8 Feb 2001 22:30:53 -0000 Received: from ifrance.com (nas25-189.vlt.club-internet.fr [195.36.224.189]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA13272 for ; Thu, 8 Feb 2001 22:29:45 +0100 (MET) Message-ID: <3A83122B.533A3C62@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5C9@po1-exch.lon.tudor.com> <3A80623D.1B2ECB6E@ifrance.com> <3A7CCB84.2311B0A@jetnet.ab.ca> <3A81B025.8C54AD4B@ifrance.com> <3A7D61A5.E075F043@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 22:39:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal and // code Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d8bfcb4019b3d4f08bd2e5d33c2b2e8e Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> >
> > Hello,
> >
> > Ben Franchuk a =E9crit :
> > But why do you want to do that !!!!!!! You think that the compile= r is so
> > stupid to scramble the instructions ;p
>
> Yes  ... Not scrambled just not optimized.
> Now what is '//'

// is for parallelism wich is too long to write (and too many chance to
miss spell it)
>
> > OOO is only to speed up old binary !
> >
> > The problem are // execution (it's almost the same thing as OOO).=
> >
> > You need to detect depencies and not only RAW (read after write) = but WAR
> > and WAW !
> > imagine such code :
>
> > a =3D 1
> > b =3D a + 2
> > a =3D 3
> > c =3D a + e
> <cut>
> In many cases like that example often a register 'a' holds a short
> term variable. This variable is dead. That to a scheduler is very impo= rtant.
>

I understand that's the goal of the compiler. I just want to show that
it isn't so easy to run the code in parrallel. And how it would become
difficult to run it in // without specific instruction field.

> > It try to find a way to code this kind of dependancies inside the=
> > instruction. It could be a way to avoid using hundred of comparat= or to
> > do it. But you have to write depencies for all following instruct= ion :
> > it's much too big !!
>
> Funny I only need to look at the few opcodes held in the pipeline.
>

How could do you run your code in parallel if the opcode are inside the
pipeline ;p
 
> > So the best way is to explicit write what could be //, no need to= find
> > the // inside the code.
> >
> > Look at current processor they could compute 4 sometimes 6 instru= ctions
> > in the time (9 for Merced) that not so much. And think that kind = of udge
> > beast have around 100 millions transistors ! Most of the time onl= y to
> > find what could be speed up ! Sound stupid, no ?
>
> yes because 99% of the time computer programs are SERIAL.
> "if(a<2) Foobar()" can't be speeded up by adding more pro= cessors.

You should read some recent computer guide. First pentuim could execute
2 instructions at a time, PIII 3, even more in the futur. I have soon
give some results of compiler studies. 3 is the worst case ILP. Without
the stack register depencies the worst ILP became 100... So you could
execute a lot of things in //.

>
> Having more processors to run more threads is a better idea
> providing you don't use up all the memory bandwidth.

Sure it's a fine grain parallelism compare to instruction level
parrallelism (ILP). But both thing could be use to speed up code.

>
> > So i came back to the vliw bit (a following instruction with an e= qual
> > vliw bit COULD be execute in the same time). I know that theoreti= caly
> > it's a redondant information but it's so hard to calcul (~50 mill= ions
> > transistors in last beast ?).
>
> <cut>
> > A pack instruction is needed for each 8 instructions so 1/8 of > > the code is lost. And don't forget that the pack instruction coul= d add
> > one more cycle to be understood (i don't imagine to pack "a = pack"
> > instruction : what happen in case of jump ? )
> Good luck with the pack bit.

To run code in parallel it the easiest way : Check the scoreboard,
verify the vliw (or pack) bit and if there is enough unit, run all
possible instructions. So it's not so hard compare to verify all
register dependancies.

Why are you ironic ? It's the easiest way !

> Ben.
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
From Nicolas Boulay Thu Feb 8 22:39:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00420 for ; Fri, 9 Feb 2001 00:03:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:03:53 +0100 (MET) Received: (qmail 7940 invoked by uid 0); 8 Feb 2001 21:33:05 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx24) with SMTP; 8 Feb 2001 21:33:04 -0000 X-eGroups-Return: sentto-1101623-2324-981667787-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 08 Feb 2001 21:32:36 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 21:29:46 -0000 Received: (qmail 26502 invoked from network); 8 Feb 2001 21:29:45 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 8 Feb 2001 21:29:45 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 8 Feb 2001 21:29:44 -0000 Received: from ifrance.com (nas25-189.vlt.club-internet.fr [195.36.224.189]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA09390 for ; Thu, 8 Feb 2001 22:29:40 +0100 (MET) Message-ID: <3A831226.FA68ED9E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DC@po1-exch.lon.tudor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 08 Feb 2001 22:39:50 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] vhdl code of imu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 01311449c08ea7dc826633677fd88421 Status: R X-Status: N I ad little time to test the imu vhdl code here are the result under
vsim (mentor graphic). Simulation are ok. But not the code, there are
some multiple source errors.

The worst thing is the files cold mc3.vhdl and mc2.vhdl. The behavior
isn't defined for all the input. So a synthetiser will put a latch to
keep the last computed value ! (should add a "when others" clauses)

nicO

the compile script :

vcom and2.vhdl and3.vhdl and4.vhdl not1.vhdl or2.vhdl or3.vhdl or4.vhdl
xor2.vhdl xor3.vhdl vlut.vhdl
vcom maj23.vhdl maj24.vhdl maj34.vhdl
vcom reduce_tree.vhdl preg.vhdl prtree.vhdl
vcom ciainc.vhdl ciacore.vhdl ciarow.vhdl ciadds.vhdl ciadd2.vhdl
vcom pciainc.vhdl pciarow.vhdl pciadd2.vhdl
vcom imul64.vhdl


the result :

Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity and2
-- Compiling architecture behave_1 of and2
-- Compiling entity and3
-- Compiling architecture behave_1 of and3
-- Compiling entity and4
-- Compiling architecture behave_1 of and4
-- Compiling entity not1
-- Compiling architecture behave_1 of not1
-- Compiling entity or2
-- Compiling architecture behave_1 of or2
-- Compiling entity or3
-- Compiling architecture behave_1 of or3
-- Compiling entity or4
-- Compiling architecture behave_1 of or4
-- Compiling entity xor2
-- Compiling architecture behave_1 of xor2
-- Compiling entity xor3
-- Compiling architecture behave_1 of xor3
-- Compiling entity vlut
-- Compiling architecture behave_1 of vlut
Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity maj23
-- Compiling architecture behave_1 of maj23
-- Compiling entity maj24
-- Compiling architecture behave_1 of maj24
-- Compiling entity maj34
-- Compiling architecture behave_1 of maj34
Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity reducetree
-- Compiling architecture struct_1 of reducetree
-- Loading entity xor3
-- Loading entity maj23
-- Compiling architecture behave_1 of reducetree
-- Loading entity reducetree
WARNING[5]: reduce_tree.vhdl(176): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(178): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(179): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(181): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(196): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(198): Nonresolved signal y may have
multiple sources.
WARNING[5]: reduce_tree.vhdl(200): Nonresolved signal y may have
multiple sources.
-- Compiling entity pipereg
-- Compiling architecture behave_1 of pipereg
WARNING[5]: preg.vhdl(44): Nonresolved signal q may have multiple
sources.
WARNING[5]: preg.vhdl(46): Nonresolved signal q may have multiple
sources.
WARNING[10]: preg.vhdl(46): Synthesis Warning: Signal d is read by the
process
but is NOT in the sensitivity list
-- Compiling entity piped_reducetree
-- Compiling architecture struct_1 of piped_reducetree
-- Loading entity pipereg
-- Loading entity reducetree
Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity cia_inc
-- Compiling architecture struct_1 of cia_inc
-- Loading entity and2
-- Loading entity xor2
-- Compiling architecture behave_1 of cia_inc
-- Loading entity cia_inc
-- Compiling entity cia_core
-- Compiling architecture behave_1 of cia_core
WARNING[5]: ciacore.vhdl(76): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(79): Nonresolved signal po may have multiple
sources.
WARNING[5]: ciacore.vhdl(89): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(91): Nonresolved signal po may have multiple
sources.
WARNING[5]: ciacore.vhdl(99): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(100): Nonresolved signal po may have multiple
sources.
-- Compiling architecture struct_1 of cia_core
-- Loading entity cia_core
-- Loading entity or2
-- Loading entity and3
-- Loading entity or3
-- Loading entity and4
-- Loading entity or4
WARNING[5]: ciacore.vhdl(160): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(161): Nonresolved signal po may have multiple
sources.
WARNING[5]: ciacore.vhdl(173): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(174): Nonresolved signal po may have multiple
sources.
WARNING[5]: ciacore.vhdl(180): Nonresolved signal go may have multiple
sources.
WARNING[5]: ciacore.vhdl(181): Nonresolved signal po may have multiple
sources.
-- Compiling entity cia_row
-- Compiling architecture struct_1 of cia_row
-- Loading entity cia_core
-- Compiling entity ciaddsmall
-- Compiling architecture struct_1 of ciaddsmall
-- Loading entity cia_row
-- Compiling entity ciadd
-- Compiling architecture struct_1 of ciadd
-- Loading entity cia_inc
Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity piped_cia_inc
-- Compiling architecture struct_1 of piped_cia_inc
-- Loading entity pipereg
-- Loading entity cia_inc
-- Compiling entity piped_cia_row
-- Compiling architecture struct_1 of piped_cia_row
-- Loading entity cia_row
-- Compiling entity piped_ciadd
-- Compiling architecture struct_1 of piped_ciadd
-- Loading entity xor2
-- Loading entity and2
-- Loading entity piped_cia_row
-- Loading entity piped_cia_inc
Model Technology ModelSim EE vcom 5.3d Compiler 2000.02 Feb  4 2000
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity imul64
-- Compiling architecture struct_1 of imul64
-- Loading entity and3
-- Loading entity pipereg
-- Loading entity reducetree
-- Loading entity not1
-- Loading entity and2
-- Loading entity and4
-- Loading entity xor2
-- Loading entity xor3
-- Loading entity maj23
-- Loading entity or2
-- Loading entity or3
-- Loading entity or4
-- Loading entity piped_cia_row
-- Loading entity piped_cia_inc
-- Loading entity piped_ciadd
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Mon Feb 5 00:28:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00444 for ; Fri, 9 Feb 2001 00:04:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Feb 2001 00:04:00 +0100 (MET) Received: (qmail 9133 invoked by uid 0); 8 Feb 2001 22:51:17 -0000 Received: from ef.egroups.com (64.211.240.229) by 10.1.4.119 (mx19) with SMTP; 8 Feb 2001 22:51:17 -0000 X-eGroups-Return: sentto-1101623-2327-981672655-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 08 Feb 2001 22:51:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 22:50:51 -0000 Received: (qmail 68132 invoked from network); 8 Feb 2001 22:50:50 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 8 Feb 2001 22:50:50 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 8 Feb 2001 22:50:49 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA23810 for ; Thu, 8 Feb 2001 15:42:01 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7DE5AE.ED1E26BD@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Feb 2001 16:28:46 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2824820e1803100820b0dbeac82393d8 Status: R X-Status: N Nicolas Boulay wrote:
> On fpga, it's a particular ff that could be used as FF (with rs) or
> latches. And memories are SRAM block about 2 or 4 kbits. Even the little
> lut or PAL are little SRAM memory.

One FPGA architecture (quick logic) a gated latch takes up whole logic cell.
Xilinx is not the only game in town for FPGA's. I think the F-CPU stage
in FPGA's will not be that long because large FPGA's would cost
more than a Custom R&D chip run if over 25 chips are needed.
Ben.
PS. I like anti-fuse chips better because you program the
chip once not load from ram every time.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From Michael Riepe Thu Feb 8 23:59:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01077 for ; Sat, 10 Feb 2001 03:38:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:23 +0100 (MET) Received: (qmail 13762 invoked by uid 0); 8 Feb 2001 23:21:53 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx13) with SMTP; 8 Feb 2001 23:21:53 -0000 X-eGroups-Return: sentto-1101623-2328-981674508-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 08 Feb 2001 23:21:51 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 8 Feb 2001 23:21:47 -0000 Received: (qmail 49808 invoked from network); 8 Feb 2001 23:21:47 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 8 Feb 2001 23:21:47 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.243) by mta1 with SMTP; 8 Feb 2001 23:21:39 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01956; Thu, 8 Feb 2001 23:59:47 +0100 Message-ID: <20010208235947.65481@thrai.stud.uni-hannover.de> To: F-CPU Mailing List References: <20010206031040.63950@thrai.stud.uni-hannover.de> <200102080321.WAA32306@moria.mit.edu> X-Mailer: Mutt 0.84e In-Reply-To: <200102080321.WAA32306@moria.mit.edu>; from Ales Hvezda on Wed, Feb 07, 2001 at 10:21:06PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 8 Feb 2001 23:59:47 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] CVS on seul.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2b2ab9ac3e6ad527f9aa0de74d38e02 Status: R X-Status: N Hi!

We need separate passwords for CVS.  Can anybody with an account on seul
-- whygee, down, olivier & nico -- please send me an encrypted password?
There's a perl script that encrypts plain text passwords (please do
NOT send unencrypted passwords); just save it to a file and run `perl
savedfile password' with the password you want, and send me the output.

------- perl script -------
#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65: 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";
------- perl script -------

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

www.   
From Michael Riepe Fri Feb 9 01:20:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01080 for ; Sat, 10 Feb 2001 03:38:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:24 +0100 (MET) Received: (qmail 20616 invoked by uid 0); 9 Feb 2001 00:21:02 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx14) with SMTP; 9 Feb 2001 00:21:02 -0000 X-eGroups-Return: sentto-1101623-2329-981678059-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 09 Feb 2001 00:21:00 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 00:20:59 -0000 Received: (qmail 86323 invoked from network); 9 Feb 2001 00:20:58 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 9 Feb 2001 00:20:58 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.243) by mta2 with SMTP; 9 Feb 2001 00:20:56 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02409; Fri, 9 Feb 2001 01:20:59 +0100 Message-ID: <20010209012058.01262@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DC@po1-exch.lon.tudor.com> <3A831226.FA68ED9E@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A831226.FA68ED9E@ifrance.com>; from Nicolas Boulay on Thu, Feb 08, 2001 at 10:39:50PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 01:20:58 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] vhdl code of imu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d06ce3b7d19e4597dd7d5b434000fa56 Status: R X-Status: N On Thu, Feb 08, 2001 at 10:39:50PM +0100, Nicolas Boulay wrote:
> I ad little time to test the imu vhdl code here are the result under
> vsim (mentor graphic). Simulation are ok. But not the code, there are
> some multiple source errors.

See the end of my mail for a possible explanation...

> The worst thing is the files cold mc3.vhdl and mc2.vhdl. The behavior
> isn't defined for all the input. So a synthetiser will put a latch to
> keep the last computed value ! (should add a "when others" clauses)

mc2/mc3 are so-called `Muller C Gates' -- they're another kind of
RS-flip-flop, and they're supposed to have latches or something like
that inside (their output is set when all inputs are '1', and cleared
when all inputs are '0', and unchanged in all other cases).  These gates
are used a lot in asynchronous logic but aren't used in the F-CPU at all,
so don't worry.

[...]
> -- Loading entity reducetree
> WARNING[5]: reduce_tree.vhdl(176): Nonresolved signal y may have
> multiple sources.

*ouch* that didn't happen here.

[...]
> -- Compiling architecture behave_1 of pipereg
> WARNING[5]: preg.vhdl(44): Nonresolved signal q may have multiple
> sources.

Same.

[...]
> WARNING[10]: preg.vhdl(46): Synthesis Warning: Signal d is read by the
> process
> but is NOT in the sensitivity list

My fault... will be corrected in next version.

[...]
> -- Compiling architecture behave_1 of cia_core
> WARNING[5]: ciacore.vhdl(76): Nonresolved signal go may have multiple
> sources.

Huh?  It's becoming strange now.

Could this be a problem with multiple `if ... generate' statements
that are mutually exclusive?  I used them in all of these files, and
both Simili and Vanilla VHDL groked it :(

Any idea how I could avoid that error?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.
From Yann Guidon Fri Feb 9 02:42:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01089 for ; Sat, 10 Feb 2001 03:38:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:26 +0100 (MET) Received: (qmail 10582 invoked by uid 0); 9 Feb 2001 01:36:31 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 9 Feb 2001 01:36:31 -0000 X-eGroups-Return: sentto-1101623-2330-981682588-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 09 Feb 2001 01:36:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 01:36:28 -0000 Received: (qmail 93718 invoked from network); 9 Feb 2001 01:36:27 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 9 Feb 2001 01:36:27 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta2 with SMTP; 9 Feb 2001 01:36:27 -0000 Received: from f-cpu.org (nas2-200.ras.club-internet.fr [195.36.192.200]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA19118 for ; Fri, 9 Feb 2001 02:36:24 +0100 (MET) Message-ID: <3A834B1B.3983A90D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 02:42:51 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] on top of that,... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2bf68cdc77b1f190fdc1ab059ced54c6 Status: R X-Status: N Hi,

while going back home this evening i realised that in the absence
of possibility of gated clock, Hans' pipelines are not possible.
when more than 2 simultaneous writes must be performed, the data
can't be hold in the long pipelines (the "bubble" can't be
"compressed"). What is sad is that the only remedy is with the
help of renamed register in which the pipelines spill when the result
can't be written directly in the register set, and that's exactly
what the FC0 is meant never to do.

well i suppose that more comments on that will soon appear,
i'm eager to read them :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.
From Hans Summers Fri Feb 9 12:48:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01176 for ; Sat, 10 Feb 2001 03:38:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:52 +0100 (MET) Received: (qmail 9294 invoked by uid 0); 9 Feb 2001 11:48:28 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx23) with SMTP; 9 Feb 2001 11:48:28 -0000 X-eGroups-Return: sentto-1101623-2334-981719306-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hl.egroups.com with NNFMP; 09 Feb 2001 11:48:27 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 11:48:25 -0000 Received: (qmail 32046 invoked from network); 9 Feb 2001 11:48:25 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 9 Feb 2001 11:48:25 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 9 Feb 2001 11:48:24 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id GAA19656 for ; Fri, 9 Feb 2001 06:46:16 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id GAA02713 for ; Fri, 9 Feb 2001 06:48:20 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Feb 2001 11:48:20 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 11:48:13 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dafacece8781c56fd90b06faca2f60e8 Status: R X-Status: N
> -----Original Message-----
> From: Yann GUIDON [mailto:whygee@f-cpu.org]
> Sent: 08 February 2001 18:22
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> hi !
> this is the following of the thread.
> some very interesting points in here.
>
> > The difference is that you
> > check if an execution unit can write the data before
> > issuing it, I check at
> > the end of execution. That's the only difference.
> but it makes a big difference in practice.
No, the results are the same (or, can be if the right prioritisation scheme
is chosen: long latency units have highest priority).

>
> > Elsewhere in other threads I have read about the
> > instruction decode taking 2
> > cycles. With my method you may be able to to it in one, as
> > you have less
> > checking to do. I don't know. Taking one cycle off the
> > latency of every
> > instruction would be a major performance enhancement.
> > reducing the decoding time sure helps but your scheme would not help.
> you have not read everything either because i propose to make
> the "issue"
> in parallel with the Xbar cycle :-) The "decoder" is simply a lot of
> tables and flag checks that are sent to the "issue" stage,
> which validates
> or not the current instruction.
> My problem was that the "issue" part would not fit in the
> allowed stage depth,
> but i am working now on performing this operation in parallel
> with the Xbar cycle.
What about when you do a register bypass? If you want to be able to do this,
the decoding cannot use that cycle where the register bank is being
accessed, because at register bypass times the value will come direct from
the Xbar without that cycle of latency. Good luck with it though I hope
there is a way

>
> > > As Michael pointed, it allows a compiler to statically
> > > schedule the CPU.
> > > it has an invaluable advantage when high performance is
> > > at stake because
> > > you can GARANTEE the execution time. It is impossible to
> > > predict the
> > > execution time of any piece of SW on OOO cores.
> >
> > My proposal is NOT, definitely not, OOO. I don't really
> > fully understand all
> > the objections to OOO but I appreciate that it is at any
> > rate a lot more
> > complex etc and undesirable. But why is my proposal OOO? It
> > is OOOC just
> > like yours!
> no because you moved the Xbar write control at the end of the
> pipeline.
I did. But the result is the same. The order of issue is the same, so is the
order of execution, so is the latency. The fact that I choose to make the
decision at the end of the pipeline rather than the beginning does not
suddenly change it from OOO to OOOC...

> > 2) Prioritise the completion find-first tree such that the
> > EU's with the
> > longest latency always have the highest priority if they
> > complete at a
> > simultaneous time to a shorter EU. This is very easy, since
> > it just means
> > ordering the inputs to the find-first tree such that the
> > long latency EU's
> > are first.
> just one question : While your value is waiting to be written back
> to the register set, where/how is it temporarily stored ?
> - if you stall the pipeline stage, it is similar to a gated clock.
> -  if you use a FIFO or new temporary registers, it is similar to what
> the PowerPC does : it is called "temporary registers" and the
> FC0 tries
> its best to avoid that. This is why i have spoken about your
> proposition
> as "looking like OOO units". frankly no pun, it's only a
> cultural/architectural
> shortcut/evocation. However it acts on me as a warning signal
> that it is
> not compatible with the design of the FC0.
> Even though the current scheme seems to be uselessly complex for you,
> it indirectly avoids the need to insert "temporary registers" where
> stalling the pipeline would have done almost the same thing
> (at a higher clock speed).
I stall my execution unit's private internal pipeline when it is waiting to
write its result to the Xbar. Gated clock is exactly what I proposed, or
rather "enabled" clock. Just AND-gating the clock is dangerous design, it
must be fully synchrously enabled. If that is an implementation problem, I
will mention this a little later. But the point is, there are no temporary
registers, just stalling of the EU's internal pipeline. This doesn't
increase the latency compared to your current design, because I issued my
instruction immediately without checking if it could write its result. In
the case of a write conflict, your design would have predicted it and
delayed issue until there was no conflict. The total number of cycles in my
design and yours remains the same for a given instruction stream. My
instructions wait to complete, yours wait to issue, but the amount of
waiting is the same.

>
> > Can you not see that if you do this, you get IDENTICAL
> results to your
> > current scheduler?
> almost.
Why only "almost"? It was not immediately apparent to me, but when I thought
about it carefully it became clear. Effectively in your design you
prioritise the longer latency instructions because you reserve for them a
slot far along the FIFO. A shorter latency EU which would need to complete
at the same time cannot do so because the slot is used already, therefore
the long latency EU has been prioritised. The result is the same, but with
any necessary waiting moved from the time of issue in your case to the time
of result write in mine. The waiting time is the same, and if I priortise
longer latency EU's first, the order of completion is also the same.

> > Instructions are issued in the same order as yours, the
> > results are written in exactly the same order as yours,
> not necessarily : it will depend on your last selection stage.
> that's why you are encouraged to refine it.
> as long as there's an uncertainty, i won't leave you comfortable
> with your idea ;-)
My last selection stage prioritises all the EU's having long latency. I use
a "find-first" tree just the same as you propose for the SRB mechanism. The
beginning of the tree, which will be the first EU's to be selected if they
have their "Complete" bit set to 1, are the longest latency EU's. Note: the
order of EU's having the same latency, e.g. 2 cycles, is unimportant: they
cannot complete at identical times since they cannot be issued
simultaneously (1 issue/cycle in FC0). I can't see the uncertainty. The
"find-first" tree will correctly prioritise and has one whole cycle in which
to do so, in parallel with the last cycle of the EU's.

> > Therefore, with my proposal the same beloved guarantees exist,
> not all. the prioritizer is still blurred ...
See above, does it clarify? I believe that this prioritisation will ensure
that the order of issue and completion is the same as yours, and the total
latency will also be the same but with waiting at the completion end of the
pipeline not the issue end.

>
> > the compiler
> > can be identical, everything the same, except that the
> > design becomes tidy
> > and modular, and probably uses less area too.
> this is not certain. As you said, it's almost the same thing,
> there are very similar features, except that FC0 was created long ago,
> enough to solve the conceptual problems :-)
>
> > > > Overall I concluded
> > > > that whatever problems would be faced in register
> > > > bypassing would be the
> > > > same in my design and the current one. My design
> > > > doesn't address that issue,
> > > > and I didn't think it makes it harder to solve.
> > > mmm you should think a bit more :-)
> > See above. 6 extra bits in the Xbar, the comparison takes
> > place in only one
> > place and the register bypass remains the same.
> what bothers me here is a probable underestimation of the
> propagation times.
> it is still a bit unclear for me, whether you can perform all those
> operations in one cycle. if not, you are forced to compare 1
> stage before,
> therefore in the EU themselves. in this case, the bypass idea
> can be forgotten
> (sadly enough, the Xbar's purpose was also to allow bypassing).
I agree propagation is an issue, but the 64-bit result must propagate along
the Xbar from the EU where it is computed, to wherever the register bank is,
and also the instruction issue so that bypass is possible. Then it must be
routed. If there is enough time in the cycle, then surely there is enough
time to route the register number bits and compare them. How many gates deep
is a compare?

> > > > > > 2.4 XBAR WRITE CONFLICTS
> > > > As the current pipeline must also be stallable it will
> > > > also require clock enable
> > > > lines, so no change here.
> > > wrong. "stall" means "the current instruction in the
> > > decoder is not ready",
> > > while the rest of the execution pipeline flows its way normally...
> > > there's a little difference now :-)
> > > If the whole pipeline was stalled because a source register
> > > is not ready, it would deadlock the CPU ;-P
> > Yeah I do realise that. But it seems to me that you do have
> > to stall your
> > FIFO when the results of a non-deterministic load operation
> > arrive back. How
> > do you do this without clock enable?
> "bubbles" :-) read P&H's books about basic pipelined architectures.
> the clock is not stopped, the result of the pipeline is garbage and
> it's simply discarded (not used).
Who is P&H?

> > In fact, I once went some way to designing a whole CPU which was
> > intended to be made from TTL logic chips. Of course, the
> > existing 24 hours
> > in a day are less than half what would be required to
> > construct such a
> > monstrosity in parallel with a a job and a family, so it
> > remained destined
> > to lie for ever in the figments of my imagination. But of
> > prime importance
> > are "silicon area" (equivalent to how many hundreds of TTL
> > chips I would
> > have had to solder up) and simplicity (same reason). I also
> > wanted high
> > performance therefore the superscalar type architecture.
> today there are FPGAs and that's a solution,
> there are also "picogates" (ECL SMT devices with 2 inputs and
> several outputs
> corresponding to different logic functions). the last are
> able to run at 2.5GHz,
> so a CDP of 10 gates is more or less 250Mhz.
> the PCB however is not the easiest thing to do ;-)
The FPGA would be the way to go for me.

> > Enforce strict deterministic latency on the units and
> > prioritise in favour of long-latency units. The results
> > become identical.
> not necessarily.
I think so. I think the results are identical but internally any possible
waiting is moved from the start of the pipeline to the end. Why "not
necessarily"?

> > But the modularity is great, and the potential for other
> > things is very
> > high. The design becomes cleaner, less cluttered. No LUT. Simpler.
> no : the latency LUT is not significant compared to the more complex
> instruction decoder. without LUT, how do you determine what
> the opcode does ?
> it's as if you asked to remove the LUT that determines which
> unit is used.
How about the first few bits of the opcode specifying the EU which would be
used to process it. Then instruction decode simply becomes a matter of
decoding those binary bits. Perhaps not even that: just send the whole
opcode to ALL the EU's, and let them perform a comparison of the
EU-specifying opcode bits with their own hardwired EU number, and ignore
anything that doesn't match?

> > > > > [...]
> > > > > > 3.4 COMPRESSIBLE PIPELINE
> > I do not know how difficult this is to
> > implement but it seems quite crucial to a synchronous
> > design and I am
> > surprised if you do not need it. As I asked before, how do
> > you stall your
> > pipeline on Load data results?
> we would normally need it, but there are some tricks and workaround.
>
> the dirty one is to put a mux at the input of the FF, which
> output is sent
> to one mux input. the clock still samples the input of the FF
> but depending
> on the MUX command, the precedent or current data is sampled.
>
> This is more or less what is done to delay the issuance of
> the instructions,
> the rest of the pipeline only contains repeated data (the
> garbage will propagate
> through the pipeline but the result won't be used or latched
> by the register set).
Now this is interesting. So, gated clocks are not well liked because of
implementation difficulties (rather, safe synchronous "enabled" clocks).
Your use of a MUX to circumvent this difficulty is merely a matterr of
implementation. The effect is to stall the pipeline: in your case you stop
the current data by reapplying it to the same FF. The result is the same as
if you had stalled the pipeline by not applying the clock signal. This is a
matter of implementation. What are the non-dirty workarounds?

>
> > > > > > 4   CONCLUSION
> > > > > >
> > > > > > My proposed replacement for the current
> > > > > > scheduler unit is conceptually simpler.
> > > however it makes the compiler much difficult to write.
> > As I said above. If you enforce fixed latency and
> > prioritise long latency
> > instructions then the issue, completion and latency are
> > identical to your
> > current design, therefore the compiler is the same.
> so if it's identical, why change what already exists ? :-D
Elegance. Modularity, though you have said you don't care about that.

>
> > > > > > The decoder/instruction issue unit is made more
> simple since all it
> > > > > > does is check availability and then issue.
> > > However how do you check for the availability ?
> > > you have to read the scoreboard bits,
> > > they are set when the Xbar write ports are in use,
> > > this means a lot of wires, comparators, latency.
> > > with the FIFO approach, we can perform bypass etc.
> > > more easily than you'd think :-)
> >
> > See above. I check data availability from the
> > scoreboard at the same time as you.
> > this is the dark spot : it has not been extensively studied,
> i can't speak about inexisting things ;-)
> > For bypass 6 extra bits on the Xbar enable the comparison
> > to occur in one place.
> and what place ? do you imagine the wire length (and therefore
> surface because 6 wires * 3 read buses * several millimeters
> uses some surface) it requires ?
3 read buses? The wire length will be no more than that required to tranfer
the 64-bit results around. Nor will the propagation delay.

> > But you can't alter the fact that your
> > current scheduler has extra circuits for special case
> execution units.
> either you make us a pipelined SIMD division unit, or you
> make a die space/latency
> compromise. Considering that division is often non critical
> for usual applications,
> it looks harmless to "arrange" the scheduler this way. If you
> remove the IDU,
> there will be no special change to do.
I am not critising the IDU, it is indeed rarely critical in most apps and it
is fine to make compromises. My critism is that change to the IDU
implementation requires change to the scheduler: removal/addition of the
down counter special handling. Which breaks modularity.

> > > > My main objective in this proposal was to tidy up the
> > > > scheduler design to
> > > > get better modularity and maintainability.
> > > nothing comes from free :-)
> > > you "solve" problems, or more precisely you move them around,
> > > it's an endless game. this explains the large variety of core
> > > types today.
> > > FC0 starts from one POV, you start from another and we
> > > get different
> > > behaviours that can be good or bad depending on the situation.
> > This does come for free. As I said, enforce fixed latency
> > and prioritise the
> > right way and you have the same behaviour but a neater more
> > modular design.
> as said earlier, modularity is not the principal issue.
If modularity and maintainability are not issues, then fine

> > The method used is the same as your
> > SRB mechanism to decide which register to backup next (by
> > your "dirty" and
> > "express request" bits IIRC). As I have pointed out, if you
> > insist on fixed
> > latency and prioritise the longer latency instructions, the
> > scheduling
> > becomes logically equivalent to your current scheduler. The
> > compiler is
> > identical, there is no data dependency or any other
> > potential problem that
> > you envisage here, since the order of execution and
> > completion is precisely
> > the same as yours, as is the latency.
>
> flaw : the execution is not exaclty the same because i can
> detect write hazards
> in advance. you don't. therefore you would send instructions
> that wouldn't  be
> sent otherwise and the result is not exactly the same,
> depending on the kind of
> instructions you issue.
I believe it IS the same. When you predict a write hazard, you wait until it
clears before issueing. I don't check and issue regardless. I then check at
the end, and if I detect a hazard I wait then. The amount of waiting for the
hazard to clear is identical, as long as
1) the order of instruction issue is the same (it is, neither of us are OOO)
2) the order of completion is also the same (it is, I said I'd prioritise
long latency EU's which gives that result)
3) latency of EU's is the same (it is, I temporarily abandoned my fun
variable latency ideas).
Where is the flaw?

> > > > Your FIFO construction is also more
> > > > complex (extra OR, AND etc) than my simple one, so each
> > > > stage is bigger.
> > > this apparent simplicity in your design is only "moved" at
> > > the end of the pipeline.
> > > the decision at the Xbar level will take gates, i think.
> > > "nothing comes for free"...
> > True, it will. I didn't really make my proposal to reduce
> > the area, but to
> > inprove the modularity. And possibly performance if
> > variable latency was
> > allowed. But the extra gates work in parallel with the
> > final EU pipeline
> > stages so don't increase latency.
> the current design also has its share of parallelism :-)
Of course, so it should

> > > > Ok. But it is still a special case.
> > > so what ? look at your own design for the divider and tell me
> > > the difference :
> > > there is the counter, the register number. they are simply
> > > placed closer to
> > > the rest of the scheduling machine. the register value has
> > > less travel to do,
> > > and we can compare things quickly, in advance of the
> > > execution rather than after.
> >
> > I don't care how much travelling the register number has to
> > do, it's not
> > like it takes PETROL or anything.
> it takes TIME. the propagation time increases (approx) as the
> square of the distance, and that's worrying enough for me.
The propagation time is the same as the time taken for the 64-bit result
data to propagate, no more.

> > I realise your point is that moving
> > information from one side of the chip to the other slows
> > things down, but
> > don't forget you are FORCED to move the 64-bit data bus to
> > and from the EU anyway.
> the funny thing with it is that it is not necessary :-)
??? If the EU is physically located in one part of the chip, and the
register bank in another, then you have to draw a wire between the register
bank and the EU to read/write data to it. How can it not be necessary?

> question :
>  what would be the functional change IF the register number
> wasn't close
> to the associated pipe stage ?
>
> answer :
>  nothing.
>
> so if you grouped all the register pipelines at one single point,
> you'd have the same behaviour. But now, you can do more things
> and compare more conditions.
>
> Compress that and you get my FIFO :-)
When latency is fixed (no data dependent optimisation) the EU internal
pipelines could be located all in one place, it is true. But compressing it
is not really your FIFO... I have a collection of FIFO's, one for every EU.
I always issue, and detect conflicts at the end of the pipeline. Therefore I
don't need the latency LUT, but I do need a "find-first" tree. But you say
you don't mind the latency LUT anyway, it is part of instruction decode. The
two solutions are not really so different, but in my case I can extend more
easily to features such as variable latency and multiple issue, and it
appears more modular and maintainable.

> > It doesn't matter how quickly you move register numbers around if
> > the data bus has to go all that way.
> it matters ! example : if you draw a 64-bit bus on 1mm with .5u wires,
> it takes .064 mm2 or 64000 u2. it is not negligible !
> the shortest the bus, the least surface, the faster, the cheaper...
Of course, but my point is that if you have to move data on a 64-bit bus,
and you have no choice, then moving another 6 bits (reg number) isn't
harming the CDP. As you say, in any case the register pipelines could be
physically relocated in one place.

> > > > It is un-modular.
> > > it is the "adaptation" of the core to the function it has
> > > to perform.
> > The adaption is easier the more modular the units are. If
> > the units can be
> > added or removed, or changed without impacting the rest of
> > the core it
> > becomes easier, right?
> yup but at what price ?
> as you remark, designing a CPU is not something done in a few minutes.
> A lot of manipulations, verifications etc must be performed.
> it is often the occasion to optimise some stuff here or there.
My point is that it becomes easier. Lower price! Of course there is still
plenty of other stuff to do.

> > > One of the design strategy is to use the information as soon
> > > as it is available.
> > > Why wait until the end of a pipeline when you can know the
> > > time it will take, BEFORE you get the result ?
> > Why not?
> you avoid the prioritizer.
No. You just replace it with a latency LUT and global FIFO. The effect is
identical, but of course it no longer looks like or can be called a
prioritiser.

> > I have the information I need in time to make use of it. I don't
> > need it any earlier. Do you agree that the instruction issue order,
> > completion order, and latency are IDENTICAL in my case if I
> > enforce fixed latency and prioritise high latency EU's?
> no because you don't detect the write hazards and you will
> issue instructions that i wouldn't.
I wait later if there is a write hazard. By prioritising long latency EU's
this results in the same order of issue and completion, and the same
latency. The wait is just in a different place.

> > But why IMPOSE that?
> because that's the simplest that can be done in the existing frame.
I find my proposal simpler... but anyway

> > > > If two long latency EU's both want that slot you have a problem.
> > > it's not the problem of "both want that slot" :
> > > it is detected the old way.
> >
> > How is that? So suppose you have one EU that has a latency
> > of 64 cycles and
> > one with a latency of 32. They could even be multiple
> > copies of identical
> > EU's operating on different word sizes. The 64 cycle one
> > has been processing
> > for a number of cycles. An instruction requires the 32
> > cycle one. Now before
> > you can issue the 32 cycle one, you insist on knowing
> > whether it will be
> > able to write in 32 cycle's time. So you have to do your
> > subtraction of 8,
> > and check the 64-cycle EU's scheduler counter, and work out if the
> > number-of-cycles-to-go will conflict with the requirements
> > of your new
> > instruction. It's a mess which will get even worse if there
> are more EU's.
> no : if you want more power, you'll have to use N-R algos,
> they can be pipelined
> and interleaved, they have more throughput.
> And you confirmed that no other kind of unit was as slow as this one,
> so this division exception is REALLY an exception.
It is not a question of more power in a particular EU type, more the
principle of modularity.

> > To increase the size of your processor (e.g. multiple
> > instruction issue etc)
> > you will have to radically redesign your scheduling.
> it will be done anyway. whatever happens, the decoder must be
> redesigned.
> it's the consequence of evolution.
Evolution as small species changes or extinctions?

> > > > > In fact, i think that it is not a high price compared
> > > > > to the relative simplicity
> > > > > of the rest of the FC0, and it doesn't impact much
> > > > > the ISA. other F-CPU
> > > > > implementations will certainly use different approaches.
> > > > The LUT s "compiled" fine, but you still need actual
> > > > alterations to the
> > > > scheduler for particular EU implementations, e.g.
> > > > special cases like the
> > > > long latency divide unit.
> > > there is no real impact of the divider on the FC0.
> > > just an opcode in the map, a Xbar port, a counter in the
> > > scheduler.
> > > Other units, if pipelined, only need the opcode and the Xbar port.
> > > if not pipelined, a "busy" flag is also required. is it
> > enough ? :-)
> > It will work, true enough. But it doesn't seem to me the
> > most elegant and
> > modular, or extensible later.
> my "crayist" side tells me to look for all possible tiny
> optimisations...
But not variable latency optimisations...

> > > However, you only described the execution units. You should
> > > now work on the
> > > "write prioritizer" and the scheduler will be derived from it.
> > > Currently the FC0's scheduler is derived from the Xbar and
> > > the execution unit's
> > > characteristics. funny how the methods are often the same.
> > The write prioritiser uses the same find-first mechanism
> > you describe in
> > your SRB text in the manual. Forget about the "express
> > request" signals, if
> > variable latency is not required. Simply connect the inputs to the
> > find-first tree in order, with the highest latency unit at
> > the beginning and
> > the lowest latency unit at the end. The instruction issue,
> > completion and
> > latency is then the same as your existing scheduler. But no
> > LUT, more
> > modular etc.
>
> forget about the LUT and the modules, make something that
> works smoothly instead :-)
> your ideas are not bad and you should work on them ! maybe
> you already have seen the
> existing VHDL designs and want to contribute.
I have very little time unfortunately

> while going back home this evening i realised that in the absence
> of possibility of gated clock, Hans' pipelines are not possible.
> when more than 2 simultaneous writes must be performed, the data
> can't be hold in the long pipelines (the "bubble" can't be
> "compressed"). What is sad is that the only remedy is with the
> help of renamed register in which the pipelines spill when the result
> can't be written directly in the register set, and that's exactly
> what the FC0 is meant never to do.
I see how your bubbles work, the data load returning etc. (previous posting
that I did not bother to copy all of here). My pipelines are indeed
impossible without gated clock, this is crucial to the whole idea. I
emphasis again, not simple AND-gated clock, but a synchronous clock enable.
If this is indeed a tricky thing to implement in reality on actual silicon,
then your workaround e.g. the current/previous FF MUX at the input to each
stage, effects the same result. Whether you use an enabled clock or a MUX,
you acheive the same thing: stalling of the EU pipeline. The implementation
doesn't change the principle.

> > > > >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> > > > Hans Summers
> > > YG
> > Hans Summers
> YG

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor

www.   
From earn10k@firstnight.co.uk Wed Feb 7 14:46:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01182 for ; Sat, 10 Feb 2001 03:38:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:57 +0100 (MET) Received: (qmail 19130 invoked by uid 0); 9 Feb 2001 12:17:40 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx03) with SMTP; 9 Feb 2001 12:17:40 -0000 X-eGroups-Return: sentto-1101623-2335-981720919-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 09 Feb 2001 12:15:21 -0000 X-Sender: earn10k@firstnight.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 12:15:18 -0000 Received: (qmail 20217 invoked from network); 9 Feb 2001 12:15:18 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 9 Feb 2001 12:15:18 -0000 Received: from unknown (HELO acs-exchange.gunteracs.com.hk) (202.77.36.227) by mta3 with SMTP; 9 Feb 2001 13:16:20 -0000 Received: by ACS-EXCHANGE with Internet Mail Service (5.5.2653.19) id <1B3A3W08>; Wed, 7 Feb 2001 23:25:06 +0800 Received: from virus_wall.gunteracs.com.hk (VIRUS_WALL [202.77.36.242]) by acs-exchange.gunteracs.com.hk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1B3A3W07; Wed, 7 Feb 2001 23:25:02 +0800 Received: from 63.14.193.190 by virus_wall.gunteracs.com.hk (InterScan E-Mail VirusWall NT); Wed, 07 Feb 2001 23:18:38 +0800 X-Priority: 3 X-MSMail-Priority: Normal From: earn10k@firstnight.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Feb 2001 06:46:15 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] WANT TO BECOME TAX EXEMPT? Content-Type: multipart/mixed; boundary="----=_NextPart_000_2ED3_00005543.00001F48" To: sloyment@gmx.net Message-ID: <20010209121741.19179gmx1@mx03.gmx.net> X-UIDL: 69186f3f6ce7c0ff8a3791d9bc3d9b9d Status: R X-Status: N ------=_NextPart_000_2ED3_00005543.00001F48 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit IRS TROUBLES PAST OR PRESENT?


IF you have had troubles with the IRS either past or present
we may be able to help you.

We can help you with leins, levies, and garnishments and taxes
they claim you owe.

I would like to provide you with the information you need
and let you speak to the professionals who can help you
with your problems.

 No problems? How would you like to get out of the tax system
legally and lawfully? This works for the W2 earner, business person,
or anyone who is tired of paying too much in taxes.

Would you like to liberate your IRA without taxes or penalties?
We can do that too.

If your problem is before the year 1997 bankruptcy may be an option
that your "tax attorney" failed to mention to you.

We may be able to help you be uncollectable without bankruptcy.

We may be able to stop all forms of collection.

 This is not any traditional information you have heard of, in fact
most attorneys urge you to negotiate with the IRS...that is clearly
not what we are about. Our goal is to stop all activity against you period.
There is no obligation for this information. You can speak with
our professionals at no cost....
so what have you got to lose?


CALL NOW

RECORDED MESSAGE 24 hours a day, 7 days a week.

CALL 1-800-320-9895 EXT 7000
OUR PURPOSE: TO EDUCATE YOU ABOUT YOUR RIGHTS AND THE TRUTH!

 TO BE REMOVED PLEASE REPLY TO: list2322@looksmart.com.au




Yahoo! Groups Sponsor
www.
------=_NextPart_000_2ED3_00005543.00001F48-- From Michael Riepe Fri Feb 9 06:43:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01185 for ; Sat, 10 Feb 2001 03:38:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:38:59 +0100 (MET) Received: (qmail 9910 invoked by uid 0); 9 Feb 2001 12:56:11 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx08) with SMTP; 9 Feb 2001 12:56:11 -0000 X-eGroups-Return: sentto-1101623-2337-981723370-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 09 Feb 2001 12:56:10 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 12:56:09 -0000 Received: (qmail 64954 invoked from network); 9 Feb 2001 12:56:08 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 9 Feb 2001 12:56:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.71) by mta2 with SMTP; 9 Feb 2001 12:56:05 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA03240; Fri, 9 Feb 2001 06:43:39 +0100 Message-ID: <20010209064339.25320@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA52@po1-exch.lon.tudor.com> X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152EA52@po1-exch.lon.tudor.com>; from Hans Summers on Thu, Feb 08, 2001 at 05:24:48PM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 06:43:39 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cf7e5840819db63694ab4da1a940ee4e Status: R X-Status: N On Thu, Feb 08, 2001 at 05:24:48PM -0000, Hans Summers wrote:
[...]
> > > You also have a large LUT.
> > you can't do without that. if you're bothered by the latency LUT,
> > remember that it's a part of the larger problem of the
> > instruction LUT :-P
> > and with 110 possible opcodes, you understand that it's not a
> > big worry compared
> > to the huge task of maintaining the instruction set tables...
>
> You don't have to do it that way, either. You could do an absolute minimum
> of opcode decoding in the instruction decoder, just enough to determine
> which EU was required for the instruction. The remaining opcode bits which
> specify exactly which flavour of instruction the EU will perform could be
> sent directly to the EU and decoded locally there e.g. multiply: mul, mulh,
> muls, mulsh, smul, smulh, smuls, smulsh; most of these are just a single bit
> whose value determines whether for example the multiplier will save the high
> byte. The EU doesn't really have to do any further decoding. Forgive me for
> being a modularity freak, but I like everything that is concerned with a
> particular EU to be done inside that EU, as far as possible.

It's already done that way (mostly).  The `flags' part of the instruction
word is sent to the EU, and the EU looks at the flags (as far as that's
possible -- e.g. mulh has do be handled outside the EU).

[...]
> No lack of predictability. I have said several times that by abandoning
> indeterminate latency EU's and prioritising the long latency EU's we obtain
> identical scheduling to your current design. But we make the whole thing
> more modular and maintainable and extensible in the future.

There is, however, one big difference: with the current approach, the
scheduler knows how long a computation takes when the instruction is
issued -- not when it completes.  Instead of waiting for a `dinner is
ready' signal, it knows that dinner will be at 6pm, and can plan ahead.
This way, it can avoid write conflicts altogether -- I suppose you all
know the basic engineering rule: it's better to avoid something that is
hard to handle (and never try to handle something you can avoid).

[...]
> I don't care how much travelling the register number has to do, it's not
> like it takes PETROL or anything. I realise your point is that moving
> information from one side of the chip to the other slows things down, but
> don't forget you are FORCED to move the 64-bit data bus to and from the EU
> anyway. It doesn't matter how quickly you move register numbers around if
> the data bus has to go all that way. I have the same counter etc, yes, but
> they are now moved to be inside the division EU. The units become more
> modular, that is the aim. I can still compare everything in the time I need
> to, and without damaging the latency.

Just for the record: the divider won't need an extra counter at all.
You can (ab)use the result shift register for this purpose (initialize
to 000...01 and stop when the 1 is shifted out at the left side).  Voila!

[...]
> How is that? So suppose you have one EU that has a latency of 64 cycles and
> one with a latency of 32. They could even be multiple copies of identical
> EU's operating on different word sizes. The 64 cycle one has been processing
> for a number of cycles. An instruction requires the 32 cycle one. Now before
> you can issue the 32 cycle one, you insist on knowing whether it will be
> able to write in 32 cycle's time. So you have to do your subtraction of 8,
> and check the 64-cycle EU's scheduler counter, and work out if the
> number-of-cycles-to-go will conflict with the requirements of your new
> instruction. It's a mess which will get even worse if there are more EU's.
> To increase the size of your processor (e.g. multiple instruction issue etc)
> you will have to radically redesign your scheduling. Why not have a simple
> scheduler now, and not have to redesign later! My scheduler almost doesn't
> exist, it is a consequence of the EU architecture.

`Keep it simple' is another basic engineering rule...
In fact, a very important one.

I didn't think much about the scheduler so far, but the basic idea I
had was that the basic element should be a table that looks like a train
schedule.  In this table, each column represents a clock cycle, and each
row represents a resource (an EU or a register write port, for example).
Before an instruction is issued, the corresponding fields in the table
are checked; if they are in use, the instruction is delayed, otherwise,
the fields are marked and the instruction is issued.  After each clock
cycle, the first column (which is now obsolete) is thrown away and a new
(empty) column is added at the end.

In case of a pipelined EU, the scheduler will only mark the EU busy for
the current cycle (since a new calculation may start in the next cycle).
For a slow EU (non-pipelined divider), it can mark the EU busy for the
next <n> cycles -- assuming the latency is known when the instruction
is decoded.  The only weak point is that the L/S unit has undetermined
latency, and has to be handled separately (which is, in fact, an argument
for your approach).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www..com
From Michael Riepe Fri Feb 9 06:50:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01188 for ; Sat, 10 Feb 2001 03:39:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 03:39:00 +0100 (MET) Received: (qmail 11731 invoked by uid 0); 9 Feb 2001 12:56:06 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx13) with SMTP; 9 Feb 2001 12:56:06 -0000 X-eGroups-Return: sentto-1101623-2336-981723364-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 09 Feb 2001 12:56:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 12:56:04 -0000 Received: (qmail 84807 invoked from network); 9 Feb 2001 12:56:03 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 9 Feb 2001 12:56:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.71) by mta2 with SMTP; 9 Feb 2001 12:56:02 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA03259; Fri, 9 Feb 2001 06:50:21 +0100 Message-ID: <20010209065020.25849@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: X-Mailer: Mutt 0.84e In-Reply-To: ; from Carsten899@aol.com on Thu, Feb 08, 2001 at 02:28:08PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 06:50:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 910c7f99e9041a3af9b2674d93cba502 Status: R X-Status: N On Thu, Feb 08, 2001 at 02:28:08PM -0500, Carsten899@aol.com wrote:
[...]
> By the way: IMHO the CMB looks like a TSS on X86.

I knew somebody would notice that ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www..com
From Yann Guidon Fri Feb 9 14:58:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01400 for ; Sat, 10 Feb 2001 05:43:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:43:44 +0100 (MET) Received: (qmail 23580 invoked by uid 0); 9 Feb 2001 13:51:58 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx24) with SMTP; 9 Feb 2001 13:51:58 -0000 X-eGroups-Return: sentto-1101623-2339-981726717-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 09 Feb 2001 13:51:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 13:51:56 -0000 Received: (qmail 11019 invoked from network); 9 Feb 2001 13:51:56 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 9 Feb 2001 13:51:56 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 9 Feb 2001 14:53:00 -0000 Received: from f-cpu.org (nas3-23.ras.club-internet.fr [195.36.203.23]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA16888 for ; Fri, 9 Feb 2001 14:51:39 +0100 (MET) Message-ID: <3A83F779.D12110D7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 14:58:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Would my hold row/column flag simplify the internal decoding? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 7187cab40520db9c263746a57d7f789c Status: R X-Status: N hi,

rares@moonbase.res.wpi.net wrote:
> Bit 0 hold row/col
> Bits 1-3 address
>
> 4 bits instead of 6 for 64 regs
> 5 bits instead of 8 for 256 regs
>
> Might save some heat by using less space and wire.
>
> That way registers get loaded either on the same row or the same column as
> needed.  Might confuse the SRB mechanism.

what is it about ?...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click Here
From Yann Guidon Fri Feb 9 14:58:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01403 for ; Sat, 10 Feb 2001 05:43:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:43:45 +0100 (MET) Received: (qmail 27642 invoked by uid 0); 9 Feb 2001 13:52:18 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx05) with SMTP; 9 Feb 2001 13:52:18 -0000 X-eGroups-Return: sentto-1101623-2338-981726717-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 09 Feb 2001 13:51:58 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 13:51:56 -0000 Received: (qmail 11011 invoked from network); 9 Feb 2001 13:51:56 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 9 Feb 2001 13:51:56 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta1 with SMTP; 9 Feb 2001 13:51:55 -0000 Received: from f-cpu.org (nas3-23.ras.club-internet.fr [195.36.203.23]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA01947 for ; Fri, 9 Feb 2001 14:51:52 +0100 (MET) Message-ID: <3A83F77B.749DB5ED@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20010209065020.25849@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 14:58:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ddcfc0c0ef808fa461b7269b002ac8e9 Status: R X-Status: N hi !

Michael Riepe wrote:
> On Thu, Feb 08, 2001 at 02:28:08PM -0500, Carsten wrote:
> [...]
> > By the way: IMHO the CMB looks like a TSS on X86.
> I knew somebody would notice that ;)
it's the proof that there are not million ways to do something :-D
and the IRQ/TRAP/SYSCALL scheme is adapted from what is done
in the SHARC, except that it is not located at a fixed address.
i prefer this scheme because it benefits more from bursted caches
and memories : the old x86 way also requires 2 main memory accesses
but the first one only fetches 1 word... a lot of lost latency
for nothing.

To let you understand better some basic concepts about the FC0
scheduling, read the description of the CDC6600 (ie the ones
written by Gordon Bell & al.), with only the main processor
in mind (the Peripheral Processors are a good idea but
let's forget them).

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
and i believe you've had your share ;-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.  
From Jeff Davies Fri Feb 9 16:58:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01448 for ; Sat, 10 Feb 2001 05:43:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:43:56 +0100 (MET) Received: (qmail 23048 invoked by uid 0); 9 Feb 2001 16:14:03 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 9 Feb 2001 16:14:03 -0000 X-eGroups-Return: sentto-1101623-2340-981735241-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 09 Feb 2001 16:14:02 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 16:14:01 -0000 Received: (qmail 81572 invoked from network); 9 Feb 2001 16:14:00 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 Feb 2001 16:14:00 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta3 with SMTP; 9 Feb 2001 17:15:04 -0000 Received: from modem-107.meitnerium.dialup.pol.co.uk ([62.136.74.235] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14RGBG-000298-00 for f-cpu@yahoogroups.com; Fri, 09 Feb 2001 16:13:55 +0000 Message-ID: <3A8413AF.66128213@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@yahoogroups.com References: <3A82804C.BF4E279C@llandre.freeserve.co.uk> <3A829594.F4483C93@mentor.com> <3A82D7A3.C6376C44@llandre.freeserve.co.uk> <3A82E6F3.6187765D@mentor.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 15:58:40 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] sony chip Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dce8ac040fcfecda426f22b0c890315c Status: R X-Status: N > > What about 32 meg on chip loading 2500 bit cache lines and instead of graphics
> > processor, a FCPU on chip... (in my linux wristwatch), with 3d iGlasses type of thing.
> > ah dream, dream.
>
> dunno, maybe you'll need the embedded 15W power regulator and the fan ?
> maybe you can hold the batteries in your pocket ? :-)
>

Or a photovoltaic or piezo-electric suit, or a micro steam turbine combusting methane from
....
ok one would have to eat beaucoup brie.
Jeff Davies

> > Jeff Davies
>
> YG
>
> speaking for himself
>
Yahoo! Groups Sponsor
www. .com 
From Jeff Davies Fri Feb 9 17:10:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01451 for ; Sat, 10 Feb 2001 05:43:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:43:57 +0100 (MET) Received: (qmail 5847 invoked by uid 0); 9 Feb 2001 16:14:05 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx23) with SMTP; 9 Feb 2001 16:14:05 -0000 X-eGroups-Return: sentto-1101623-2341-981735242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 09 Feb 2001 16:14:03 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 16:14:02 -0000 Received: (qmail 52037 invoked from network); 9 Feb 2001 16:14:01 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 9 Feb 2001 16:14:01 -0000 Received: from unknown (HELO mail6.svr.pol.co.uk) (195.92.193.212) by mta1 with SMTP; 9 Feb 2001 16:14:00 -0000 Received: from modem-107.meitnerium.dialup.pol.co.uk ([62.136.74.235] helo=llandre.freeserve.co.uk) by mail6.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14RGBJ-00029p-00 for f-cpu@yahoogroups.com; Fri, 09 Feb 2001 16:13:58 +0000 Message-ID: <3A841683.D9069D19@llandre.freeserve.co.uk> Organization: Netscape Online member X-Mailer: Mozilla 4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (WinNT; I) X-Accept-Language: en-GB,en To: f-cpu@yahoogroups.com References: <3A82DE03.A384CA61@llandre.freeserve.co.uk> <3A82E857.9512B635@mentor.com> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 16:10:43 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 03fa48a9f6a5004e6b6aae9e63045201 Status: R X-Status: N
Yann GUIDON wrote:

> hi again !
>
> Jeff Davies wrote:
>
>
> However now things are different : we have split the library function calls
> (syscall) and the error handlers (trap). trap would still work like you described.

Ah yes, in that case, in syscall, all that is stored is the program counter. Supervisor
mode is
called, interrupts must still be disabled, but in syscall handler, after pushing PC on
stack, they are
immediately reenabled.
[note on this RISC type CPU stacking PC is not done automatically as on x86, but is done
using a set of
instructions as per the ABI (binary interface)].
No SRB. Registers required are stacked "manually".
It will probably be more efficient to have two supervisor mode only registers holding
vectors for
SYSCALL and INTERRUPT (including TRAP), but the alternative is to have a bit in the Status
Reg
which is tested immediately on entering joint routine. Either will work.

>
> > Obviously with an interrupt controller of some sort, the IRQ line will continue
> > to be held low until the relevant bit is cleared in the controller's registers.
> > I imagine that the Interrupt controller will be designed later, or an off the
> > shelf one put in place.
> > This really depends where the core is going. (ie what hardware is attached).
> well i don't think that an IRQ controller would be an issue : i've designed one
> years ago and the principle is rather simple and efficient.

The 8080 had a scheme whereby the Interrupt controller fed a jump instruction to the CPU.
The Z80 had a scheme whereby A9 to A15 were used to transfer a interrupt number to the CPU
which was an offset into a table of vectors.
Both of theses are food for thought. Personally, I think CPU is so fast these days, that
both the above is
wasted hardware, and also requires peripherals tailored to the CPU. I quite like the idea
of polling peripherals
to determine the source of the interrupt. Drivers could have an Interrogate CALLBACK
function which returns
BOOL if peripheral interrupt has fired. Then OS can implement very complex interrupt scheme
based on this.
[fixed priority, and subset rotating priorities eg if you had 4 UARTs, you'd want each to
get a equal bite at the
apple]. Could be cool.
More flexible when not in hardware.

Jeff Davies.

>
>
> > Jeff Davies
>
> YG
>
> speaking for himself
>
Yahoo! Groups Sponsor
From Hans Summers Fri Feb 9 18:40:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01481 for ; Sat, 10 Feb 2001 05:44:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:04 +0100 (MET) Received: (qmail 4428 invoked by uid 0); 9 Feb 2001 17:40:43 -0000 Received: from ej.egroups.com (64.211.240.230) by 10.1.4.111 (mx11) with SMTP; 9 Feb 2001 17:40:43 -0000 X-eGroups-Return: sentto-1101623-2342-981740436-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 09 Feb 2001 17:40:41 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 17:40:35 -0000 Received: (qmail 44238 invoked from network); 9 Feb 2001 17:40:35 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 9 Feb 2001 17:40:35 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 9 Feb 2001 17:40:34 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id MAA10131 for ; Fri, 9 Feb 2001 12:38:26 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id MAA19333 for ; Fri, 9 Feb 2001 12:40:32 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Feb 2001 17:40:32 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EA62@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 17:40:31 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 057152da1b94c288e4a010a1a44ed54c Status: R X-Status: N
> > > > You also have a large LUT.
> > > you can't do without that. if you're bothered by the latency LUT,
> > > remember that it's a part of the larger problem of the
> > > instruction LUT :-P
> > > and with 110 possible opcodes, you understand that it's not a
> > > big worry compared
> > > to the huge task of maintaining the instruction set tables...
> >
> > You don't have to do it that way, either. You could do an
> > absolute minimum
> > of opcode decoding in the instruction decoder, just enough
> > to determine
> > which EU was required for the instruction. The remaining
> > opcode bits which
> > specify exactly which flavour of instruction the EU will
> > perform could be
> > sent directly to the EU and decoded locally there e.g.
> > multiply: mul, mulh,
> > muls, mulsh, smul, smulh, smuls, smulsh; most of these are
> > just a single bit
> > whose value determines whether for example the multiplier
> > will save the high
> > byte. The EU doesn't really have to do any further
> > decoding. Forgive me for
> > being a modularity freak, but I like everything that is
> > concerned with a
> > particular EU to be done inside that EU, as far as possible.
>
> It's already done that way (mostly).  The `flags' part of the
> instruction
> word is sent to the EU, and the EU looks at the flags (as far
> as that's
> possible -- e.g. mulh has do be handled outside the EU).

Good!


>
> [...]
> > No lack of predictability. I have said several times that
> > by abandoning
> > indeterminate latency EU's and prioritising the long
> > latency EU's we obtain
> > identical scheduling to your current design. But we make
> > the whole thing
> > more modular and maintainable and extensible in the future.
>
> There is, however, one big difference: with the current approach, the
> scheduler knows how long a computation takes when the instruction is
> issued -- not when it completes.  Instead of waiting for a `dinner is
> ready' signal, it knows that dinner will be at 6pm, and can
> plan ahead.
> This way, it can avoid write conflicts altogether -- I suppose you all
> know the basic engineering rule: it's better to avoid
> something that is
> hard to handle (and never try to handle something you can avoid).

This rule cannot always be followed to blindly. Knowledge of something
before you need it requires remembering it until you need it. It is of
little use to me now to know that dinner on July 15th is at 6pm: I'd have to
remember that and remember everything I plan. In my proposal I know all the
information as soon as I need to - you don't really need to know about
conflicts before issueing the instruction. By leaving it until later, all
you are doing is moving the temporal position of the waiting for potential
conflicts to dissappear.


>
> [...]
> > I don't care how much travelling the register number has to
> > do, it's not
> > like it takes PETROL or anything. I realise your point is
> > that moving
> > information from one side of the chip to the other slows
> > things down, but
> > don't forget you are FORCED to move the 64-bit data bus to
> > and from the EU
> > anyway. It doesn't matter how quickly you move register
> > numbers around if
> > the data bus has to go all that way. I have the same
> > counter etc, yes, but
> > they are now moved to be inside the division EU. The units
> > become more
> > modular, that is the aim. I can still compare everything in
> > the time I need
> > to, and without damaging the latency.
>
> Just for the record: the divider won't need an extra counter at all.
> You can (ab)use the result shift register for this purpose (initialize
> to 000...01 and stop when the 1 is shifted out at the left
> side).  Voila!

Even better. Surely another reason to put everything to do with an EU in the
hands of the EU designer, not the scheduler designer: that way the EU
designer can if he wishes optimise the hardware, since he knows everything
about it and has control over everything it impacts.

>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
www. .com 
From Ben Franchuk Mon Feb 5 08:41:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01502 for ; Sat, 10 Feb 2001 05:44:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:09 +0100 (MET) Received: (qmail 14270 invoked by uid 0); 9 Feb 2001 18:30:51 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx02) with SMTP; 9 Feb 2001 18:30:51 -0000 X-eGroups-Return: sentto-1101623-2343-981743449-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 09 Feb 2001 18:30:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 18:30:48 -0000 Received: (qmail 32164 invoked from network); 9 Feb 2001 18:30:46 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Feb 2001 18:30:46 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 9 Feb 2001 18:30:45 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA04852; Fri, 9 Feb 2001 11:21:44 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7E5934.DE7A53B5@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: "'fpga-cpu@egroups.com'" , Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 00:41:40 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Print you own PC. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3a89d3ff74f6ad076eda1ead44d5abcb Status: R X-Status: N http://www.technologyreview.com/magazine/nov00/mihm.asp
Anybody for dumping silicon chips and just using a CPU printed on your
inkjet printer?

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.  
From Alan Grimes Fri Feb 9 19:36:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01508 for ; Sat, 10 Feb 2001 05:44:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:10 +0100 (MET) Received: (qmail 11893 invoked by uid 0); 9 Feb 2001 18:35:11 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx10) with SMTP; 9 Feb 2001 18:35:11 -0000 X-eGroups-Return: sentto-1101623-2344-981743708-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 09 Feb 2001 18:35:11 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 18:35:08 -0000 Received: (qmail 44217 invoked from network); 9 Feb 2001 18:35:07 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 9 Feb 2001 18:35:07 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta2 with SMTP; 9 Feb 2001 18:35:06 -0000 Received: from 66-44-57-125.s379.tnt2.lnhva.md.dialup.rcn.com ([66.44.57.125] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14RINt-0005IW-00 for f-cpu@yahoogroups.com; Fri, 09 Feb 2001 13:35:05 -0500 Message-ID: <3A8438A7.B9ED2EF3@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <3A7E5934.DE7A53B5@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 13:36:23 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Print you own PC. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 41cb81c37ca765579e6a712d9d426217 Status: R X-Status: N Ben Franchuk wrote:
>
> http://www.technologyreview.com/magazine/nov00/mihm.asp
> Anybody for dumping silicon chips and just using a CPU printed on your
> inkjet printer?

Hey, If you can interface it with the internet, it would close the
digital divide in nanoseconds =P

--
I am not massochistic enough to linux.
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Mon Feb 5 08:56:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01511 for ; Sat, 10 Feb 2001 05:44:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:11 +0100 (MET) Received: (qmail 4224 invoked by uid 0); 9 Feb 2001 18:45:14 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx01) with SMTP; 9 Feb 2001 18:45:14 -0000 X-eGroups-Return: sentto-1101623-2345-981744309-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 09 Feb 2001 18:45:10 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 18:45:08 -0000 Received: (qmail 43559 invoked from network); 9 Feb 2001 18:45:08 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 9 Feb 2001 18:45:08 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 9 Feb 2001 18:45:07 -0000 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA05489 for ; Fri, 9 Feb 2001 11:36:08 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A7E5C96.37477F9D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A7E5934.DE7A53B5@jetnet.ab.ca> <3A8438A7.B9ED2EF3@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Feb 2001 00:56:06 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Print you own PC. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 83803278b620b32eef1243fbe95d8802 Status: R X-Status: N Alan Grimes wrote:
>
> Ben Franchuk wrote:
> >
> > http://www.technologyreview.com/magazine/nov00/mihm.asp
> > Anybody for dumping silicon chips and just using a CPU printed on your
> > inkjet printer?
>
> Hey, If you can interface it with the internet, it would close the
> digital divide in nanoseconds =P

Hey I am waiting for analog... printed tubes :-)
Scotty -- Captain the Main Computers are down again.
Kirk   -- Can you make it the the MAIN XEROX before the next phasor attack?


--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Fri Feb 9 22:35:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01556 for ; Sat, 10 Feb 2001 05:44:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:24 +0100 (MET) Received: (qmail 951 invoked by uid 0); 9 Feb 2001 21:25:46 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx03) with SMTP; 9 Feb 2001 21:25:46 -0000 X-eGroups-Return: sentto-1101623-2346-981753942-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 09 Feb 2001 21:25:45 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 21:25:41 -0000 Received: (qmail 88081 invoked from network); 9 Feb 2001 21:25:40 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 9 Feb 2001 21:25:40 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 9 Feb 2001 22:26:45 -0000 Received: from ifrance.com (nas12-200.vlt.club-internet.fr [195.36.162.200]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA04199 for ; Fri, 9 Feb 2001 22:25:35 +0100 (MET) Message-ID: <3A8462B5.1C2FF7AD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A834B1B.3983A90D@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 22:35:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] on top of that,... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d09e3a0aa19df35b91fccb405b314a60 Status: R X-Status: N Hello,

Yann Guidon a =E9crit :
>
> Hi,
>
> while going back home this evening i realised that in the absence
> of possibility of gated clock, Hans' pipelines are not possible.
> when more than 2 simultaneous writes must be performed, the data

;p ;p ;p, i think have said that a long time ago...
Remember, TI use 8 Write ports and 8 read ports to there register
bank...

But gated clock is possible, synopsys could manage this relatively well. It's more and more used to reduice power consumption.

> can't be hold in the long pipelines (the "bubble" can't be > "compressed"). What is sad is that the only remedy is with t= he
> help of renamed register in which the pipelines spill when the result<= BR> > can't be written directly in the register set, and that's exactly
> what the FC0 is meant never to do.
>
> well i suppose that more comments on that will soon appear,
> i'm eager to read them :-)
>
Done ;p
> WHYGEE
nicO
>

Yahoo! Groups Spons= or
3D""
3D""
From Nicolas Boulay Fri Feb 9 22:36:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01559 for ; Sat, 10 Feb 2001 05:44:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:25 +0100 (MET) Received: (qmail 23239 invoked by uid 0); 9 Feb 2001 21:36:25 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx07) with SMTP; 9 Feb 2001 21:36:25 -0000 X-eGroups-Return: sentto-1101623-2347-981753968-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ei.egroups.com with NNFMP; 09 Feb 2001 21:26:13 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 21:26:08 -0000 Received: (qmail 22153 invoked from network); 9 Feb 2001 21:26:07 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 9 Feb 2001 21:26:07 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 9 Feb 2001 21:26:06 -0000 Received: from ifrance.com (nas12-200.vlt.club-internet.fr [195.36.162.200]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA19636 for ; Fri, 9 Feb 2001 22:25:48 +0100 (MET) Message-ID: <3A8462D2.402E91C9@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 22:36:18 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e6c3df7022a09d35c200b91238c42b53 Status: R X-Status: N

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> > On fpga, it's a particular ff that could be used as FF (with rs) = or
> > latches. And memories are SRAM block about 2 or 4 kbits. Even the= little
> > lut or PAL are little SRAM memory.
>
> One FPGA architecture (quick logic) a gated latch takes up whole logic= cell.
> Xilinx is not the only game in town for FPGA's. I think the F-CPU stag= e
> in FPGA's will not be that long because large FPGA's would cost
> more than a Custom R&D chip run if over 25 chips are needed.

Funny ;p I have read (in Electronics International, a famous french
professional electronics newspaper) that a compagny would produice 25
000 chips and the guy from the foundry answer that he didn't move under
500 000 chips... So, you're funny...

> Ben.
nicO
> PS. I like anti-fuse chips better because you program the
> chip once not load from ram every time.
PS.Saving few 100 milliseconds at the power up, that's a big deal ;p
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
=
www.
From Michael Riepe Fri Feb 9 14:41:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01571 for ; Sat, 10 Feb 2001 05:44:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:27 +0100 (MET) Received: (qmail 13578 invoked by uid 0); 9 Feb 2001 22:28:10 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx23) with SMTP; 9 Feb 2001 22:28:10 -0000 X-eGroups-Return: sentto-1101623-2348-981757689-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 09 Feb 2001 22:28:09 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 22:28:08 -0000 Received: (qmail 91922 invoked from network); 9 Feb 2001 22:28:08 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 9 Feb 2001 22:28:08 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.126) by mta2 with SMTP; 9 Feb 2001 22:28:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00567; Fri, 9 Feb 2001 14:41:14 +0100 Message-ID: <20010209144114.53820@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com>; from Hans Summers on Fri, Feb 09, 2001 at 11:48:13AM -0000 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 9 Feb 2001 14:41:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 817e040da4505dd4ea272ae5b1f906d0 Status: R X-Status: N On Fri, Feb 09, 2001 at 11:48:13AM -0000, Hans Summers wrote:
[...]
> How about the first few bits of the opcode specifying the EU which would be
> used to process it. Then instruction decode simply becomes a matter of
> decoding those binary bits. Perhaps not even that: just send the whole
> opcode to ALL the EU's, and let them perform a comparison of the
> EU-specifying opcode bits with their own hardwired EU number, and ignore
> anything that doesn't match?

Put the decoder into the EUs?  Distributed associative read-only memory?

[...]
> Now this is interesting. So, gated clocks are not well liked because of
> implementation difficulties (rather, safe synchronous "enabled" clocks).

How exactly will you implement them?  I'm particularly interested in
the `safe' part...

> Your use of a MUX to circumvent this difficulty is merely a matterr of
> implementation. The effect is to stall the pipeline: in your case you stop
> the current data by reapplying it to the same FF. The result is the same as
> if you had stalled the pipeline by not applying the clock signal. This is a
> matter of implementation. What are the non-dirty workarounds?

A mux will affect the CDP, and is way too heavy -- some pipeline
registers are much wider than the operand size (expecially in the
multiplier).  So, again: how can you enable/disable the clock safely
without affecting the CDP (and without using too much area)?

[...]
> I believe it IS the same. When you predict a write hazard, you wait until it
> clears before issueing. I don't check and issue regardless. I then check at
> the end, and if I detect a hazard I wait then. The amount of waiting for the
> hazard to clear is identical, as long as
> 1) the order of instruction issue is the same (it is, neither of us are OOO)
> 2) the order of completion is also the same (it is, I said I'd prioritise
> long latency EU's which gives that result)
> 3) latency of EU's is the same (it is, I temporarily abandoned my fun
> variable latency ideas).
> Where is the flaw?

- we need to stall the pipelines (not just the IF/ID unit)
- we need a fast priority encoder / decision logic

[...]
> I see how your bubbles work, the data load returning etc. (previous posting
> that I did not bother to copy all of here). My pipelines are indeed
> impossible without gated clock, this is crucial to the whole idea. I
> emphasis again, not simple AND-gated clock, but a synchronous clock enable.
> If this is indeed a tricky thing to implement in reality on actual silicon,
> then your workaround e.g. the current/previous FF MUX at the input to each
> stage, effects the same result. Whether you use an enabled clock or a MUX,
> you acheive the same thing: stalling of the EU pipeline. The implementation
> doesn't change the principle.

See above -- a mux takes too much area, and increases the stages' delay,
while bubbles cost nothing (in terms of silicon real estate, or delay).

I really like clean, modular designs like yours (some of the ideas
sound quite familiar ;), but they must be easy to implement, too.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www. .com 
From Ben Franchuk Fri Feb 9 22:59:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01583 for ; Sat, 10 Feb 2001 05:44:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 05:44:30 +0100 (MET) Received: (qmail 1104 invoked by uid 0); 9 Feb 2001 23:05:02 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx01) with SMTP; 9 Feb 2001 23:05:02 -0000 X-eGroups-Return: sentto-1101623-2349-981759898-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 09 Feb 2001 23:05:01 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 9 Feb 2001 23:04:57 -0000 Received: (qmail 91785 invoked from network); 9 Feb 2001 23:04:57 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 9 Feb 2001 23:04:57 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 9 Feb 2001 23:04:55 -0000 Received: from jetnet.ab.ca (dialin44.jetnet.ab.ca [207.153.6.44]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA18356 for ; Fri, 9 Feb 2001 15:55:57 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A84682A.24A84CA7@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 09 Feb 2001 14:59:06 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a27afea5b116dfad9052ca2f8b7698ef Status: R X-Status: N Nicolas Boulay wrote:
>

> Funny ;p I have read (in Electronics International, a famous french
> professional electronics newspaper) that a compagny would produice 25
> 000 chips and the guy from the foundry answer that he didn't move under
> 500 000 chips... So, you're funny...

Quick Sell 499 999 more chips.
Here is the supplier I was thinking of.
http://www.mosis.org/Aboutmosis/menu-aboutmosis.html

> PS.Saving few 100 milliseconds at the power up, that's a big deal ;p

No. I don't like EPROMS going brain dead after 10 years.
The first computer I used was a PDP-8 -- Core memory and switches --.
It breaks you can fix it.Barring things like bad filter caps and corroded
connections; you power it up 30 years later and it still works. While
I don't expect people to go back to paper tape I don't like this
Throw away computer market we are in today.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Sat Feb 10 16:00:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00769 for ; Sat, 10 Feb 2001 19:55:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 19:55:44 +0100 (MET) Received: (qmail 16037 invoked by uid 0); 10 Feb 2001 15:26:33 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx15) with SMTP; 10 Feb 2001 15:26:33 -0000 X-eGroups-Return: sentto-1101623-2350-981816620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 10 Feb 2001 14:50:22 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 10 Feb 2001 14:50:19 -0000 Received: (qmail 83704 invoked from network); 10 Feb 2001 14:50:18 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 10 Feb 2001 14:50:18 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta2 with SMTP; 10 Feb 2001 14:50:17 -0000 Received: from ifrance.com (nas15-82.vlt.club-internet.fr [195.36.165.82]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA06948 for ; Sat, 10 Feb 2001 15:50:14 +0100 (MET) Message-ID: <3A855790.2243B8C5@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Feb 2001 16:00:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 5e47fdbf246857ad03db0ca7bf82d666 Status: R X-Status: N Hello,

Michael Riepe a =E9crit :
>
> On Fri, Feb 09, 2001 at 11:48:13AM -0000, Hans Summers wrote:
> [...]
> > Now this is interesting. So, gated clocks are not well liked beca= use of
> > implementation difficulties (rather, safe synchronous "enabl= ed" clocks).
>
> How exactly will you implement them?  I'm particularly interested= in
> the `safe' part...
>

In fact you simply put an enable signal inside a process :

process
if enable_process =3D '1' then
      ...
end if;
end process;

In every case, that's work. Power compiler from sysnopsys could use this structure to produice gated clock. (a specific design with ff and a
latch on the clock and a "and" gate.)

In the general case, i believe that you're considering the design much
too close to the silicium. It's could became much too hard to manage
multi million transistor chips that way. The best exemple, is the use of entity wich describe only AND or OR gate. Why don't you use directly
"and" and "or" operator in your code? It will produice = the same result
but the code will become (much) shorter and clearer.

Never forget that silicon compiler have to manage with fan-in and
fan-out, hold and setup timing. So it could add several inversors for
it.

In the other hand, the library used could have very different cells and
propose choice of implementation (compromise between speed, area and
power consumption). According to the constraint, the compiler could
create very different design. I could use a "8-and" gates, slow b= ut
narow, for a better speed it will use only some "2-and" gate.

For exemple, i have synthetise a little register banks to test clock
gating. My clock period goal was 20 ns, the compiler produice very
quickly a design which could run at 4 ns ! But after setting a
constraint on the power consumption, it reach the 20 ns delay with more
than the 1/4 of the previous consumptions (at the same clock speed).

I don't think it's usefull to try to be so close to the silicium. The
code became much longer and complicated for (i think) a little gain on a so udge chips.

nicO
Yahoo! Groups Spons= or
3D""3D""
www..com
3D""
From Nicolas Boulay Sat Feb 10 16:00:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00772 for ; Sat, 10 Feb 2001 19:55:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 10 Feb 2001 19:55:45 +0100 (MET) Received: (qmail 7258 invoked by uid 0); 10 Feb 2001 15:28:49 -0000 Received: from mx19.rz2.gmx.net (HELO ho.egroups.com) (10.1.72.119) by mxi1.gmx.net (mxi1) with SMTP; 10 Feb 2001 15:28:49 -0000 X-eGroups-Return: sentto-1101623-2351-981816626-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 10 Feb 2001 14:50:27 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 10 Feb 2001 14:50:26 -0000 Received: (qmail 18172 invoked from network); 10 Feb 2001 14:50:26 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 10 Feb 2001 14:50:26 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 10 Feb 2001 15:51:30 -0000 Received: from ifrance.com (nas15-82.vlt.club-internet.fr [195.36.165.82]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA27478 for ; Sat, 10 Feb 2001 15:50:23 +0100 (MET) Message-ID: <3A85579A.677A70E@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A84682A.24A84CA7@jetnet.ab.ca> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Feb 2001 16:00:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: da978c10d7f1f78c7737697a91feae73 Status: R X-Status: N Mosis are like Europractice and CMP in France. It's for prototyping and
educationnal purpose (or research).

Ben Franchuk a =E9crit :
>
> Nicolas Boulay wrote:
> >
>
> > Funny ;p I have read (in Electronics International, a famous fren= ch
> > professional electronics newspaper) that a compagny would produic= e 25
> > 000 chips and the guy from the foundry answer that he didn't move= under
> > 500 000 chips... So, you're funny...
>
> Quick Sell 499 999 more chips.
> Here is the supplier I was thinking of.
> http:= //www.mosis.org/Aboutmosis/menu-aboutmosis.html
>
> > PS.Saving few 100 milliseconds at the power up, that's a big deal= ;p
>
> No. I don't like EPROMS going brain dead after 10 years.
> The first computer I used was a PDP-8 -- Core memory and switches --.<= BR>
That's true ;) Cars could became funny with predictable problem with
flash memory.

> It breaks you can fix it.Barring things like bad filter caps and corro= ded
> connections; you power it up 30 years later and it still works. While<= BR> > I don't expect people to go back to paper tape I don't like this
> Throw away computer market we are in today.
> Ben.
nicO
Yahoo! Groups Spons= or
3D""3D""<= /a>
www. .com&nbs= p;
3D""
From Michael Riepe Sun Feb 11 00:01:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00314 for ; Sun, 11 Feb 2001 18:22:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:04 +0100 (MET) Received: (qmail 9969 invoked by uid 0); 10 Feb 2001 23:01:08 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx03) with SMTP; 10 Feb 2001 23:01:08 -0000 X-eGroups-Return: sentto-1101623-2352-981846066-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 10 Feb 2001 23:01:06 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 10 Feb 2001 23:01:05 -0000 Received: (qmail 4127 invoked from network); 10 Feb 2001 23:01:05 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 10 Feb 2001 23:01:05 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.136) by mta1 with SMTP; 10 Feb 2001 23:01:03 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00553; Sun, 11 Feb 2001 00:01:05 +0100 Message-ID: <20010211000104.65025@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> <3A855790.2243B8C5@ifrance.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A855790.2243B8C5@ifrance.com>; from Nicolas Boulay on Sat, Feb 10, 2001 at 04:00:33PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 00:01:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 8ea88aff01d4e8d2aabe206ebe6ca1c2 Status: R X-Status: N On Sat, Feb 10, 2001 at 04:00:33PM +0100, Nicolas Boulay wrote:
[...]
> In fact you simply put an enable signal inside a process :
>
> process
> if enable_process = '1' then
>       ...
> end if;
> end process;
> 
> In every case, that's work. Power compiler from sysnopsys could use this
> structure to produice gated clock. (a specific design with ff and a
> latch on the clock and a "and" gate.)

I know how to do that in VHDL... I just wondered how a `safe' (i.e.
not timing-critical) clock gate looks like in CMOS (or any other
technology).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Click Here
From Ben Franchuk Sat Feb 10 15:47:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00317 for ; Sun, 11 Feb 2001 18:22:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:04 +0100 (MET) Received: (qmail 12410 invoked by uid 0); 10 Feb 2001 23:14:37 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx17) with SMTP; 10 Feb 2001 23:14:37 -0000 X-eGroups-Return: sentto-1101623-2353-981846875-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 10 Feb 2001 23:14:36 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 10 Feb 2001 23:14:35 -0000 Received: (qmail 49445 invoked from network); 10 Feb 2001 23:14:34 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 10 Feb 2001 23:14:34 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 10 Feb 2001 23:14:34 -0000 Received: from jetnet.ab.ca (dialin39.jetnet.ab.ca [207.153.6.39]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA10005 for ; Sat, 10 Feb 2001 16:05:33 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A855464.57E8667@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> <3A855790.2243B8C5@ifrance.com> <20010211000104.65025@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Feb 2001 07:47:00 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 254be5d2043c01bf2b73c3a20342c15f Status: R X-Status: N Michael Riepe wrote:
> I know how to do that in VHDL... I just wondered how a `safe' (i.e.
> not timing-critical) clock gate looks like in CMOS (or any other
> technology).
I guess it would depend on the techology used.
It may just have a real gate on the enable,or multiplex
the D input with the Q output.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
From Michael Riepe Sun Feb 11 00:29:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00320 for ; Sun, 11 Feb 2001 18:22:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:05 +0100 (MET) Received: (qmail 24597 invoked by uid 0); 10 Feb 2001 23:29:44 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx18) with SMTP; 10 Feb 2001 23:29:44 -0000 X-eGroups-Return: sentto-1101623-2354-981847782-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 10 Feb 2001 23:29:43 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 10 Feb 2001 23:29:41 -0000 Received: (qmail 97521 invoked from network); 10 Feb 2001 23:29:41 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 10 Feb 2001 23:29:41 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.136) by mta3 with SMTP; 11 Feb 2001 00:30:44 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00656; Sun, 11 Feb 2001 00:29:37 +0100 Message-ID: <20010211002936.02230@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> <3A855790.2243B8C5@ifrance.com> <20010211000104.65025@thrai.stud.uni-hannover.de> <3A855464.57E8667@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3A855464.57E8667@jetnet.ab.ca>; from Ben Franchuk on Sat, Feb 10, 2001 at 07:47:00AM -0700 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 00:29:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 345391b959a5db25fa3ab206803c3225 Status: R X-Status: N On Sat, Feb 10, 2001 at 07:47:00AM -0700, Ben Franchuk wrote:
> Michael Riepe wrote:
> > I know how to do that in VHDL... I just wondered how a `safe' (i.e.
> > not timing-critical) clock gate looks like in CMOS (or any other
> > technology).
> I guess it would depend on the techology used.
> It may just have a real gate on the enable,or multiplex
> the D input with the Q output.

The solution shall not affect the CDP (like a multiplexer does), and it
shall not be timing-critical either -- an AND gate in the clock line
may be fine for power-saving mode, but it is not useful for stalling a
pipeline for one or two cycles.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www. .com 
From Ben Franchuk Sat Feb 10 16:57:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00329 for ; Sun, 11 Feb 2001 18:22:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:07 +0100 (MET) Received: (qmail 4729 invoked by uid 0); 11 Feb 2001 00:24:52 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx21) with SMTP; 11 Feb 2001 00:24:52 -0000 X-eGroups-Return: sentto-1101623-2355-981851088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 11 Feb 2001 00:24:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 00:24:48 -0000 Received: (qmail 69132 invoked from network); 11 Feb 2001 00:24:47 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 11 Feb 2001 00:24:47 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 11 Feb 2001 01:25:52 -0000 Received: from jetnet.ab.ca (dialin39.jetnet.ab.ca [207.153.6.39]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA13274 for ; Sat, 10 Feb 2001 17:15:46 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8564D9.EF9FF100@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> <3A855790.2243B8C5@ifrance.com> <20010211000104.65025@thrai.stud.uni-hannover.de> <3A855464.57E8667@jetnet.ab.ca> <20010211002936.02230@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Feb 2001 08:57:13 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: c06c2827247eb33e798f1174cb48d827 Status: R X-Status: N Michael Riepe wrote:

> The solution shall not affect the CDP (like a multiplexer does), and it
> shall not be timing-critical either -- an AND gate in the clock line
> may be fine for power-saving mode, but it is not useful for stalling a
> pipeline for one or two cycles.

That is now harder because you need to know your logic at the
transistor level. I have just been reading a bit on CMOS logic
and a TRUE CMOS Flip Flip can have over 38 transistors.Other
techologies can have fewer transistors but you have power/speed
tradeoffs.I have been hitting the 'transistor' level of gate
design and have been finding that 'custom' logic compared to
simple logic cells can have a 2 x factor in size and power.

Also faster adders are posible than carry lookahead adders
ie spanning tree adders. Here they give 5 units of delay for a 64 bit adder
but the adders are large.
http://www-device.eecs.berkeley.edu/~stang/cs252/node3.html



--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Personalize your company´s name. Choose the domain name below and press SEARCH!
www.
Yahoo! Domains
From Yann Guidon Sun Feb 11 03:17:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00332 for ; Sun, 11 Feb 2001 18:22:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:08 +0100 (MET) Received: (qmail 24873 invoked by uid 0); 11 Feb 2001 02:11:11 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx21) with SMTP; 11 Feb 2001 02:11:11 -0000 X-eGroups-Return: sentto-1101623-2356-981857470-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 11 Feb 2001 02:11:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 02:11:08 -0000 Received: (qmail 88459 invoked from network); 11 Feb 2001 02:11:08 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 11 Feb 2001 02:11:08 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 11 Feb 2001 02:11:07 -0000 Received: from f-cpu.org (nas3-58.ras.club-internet.fr [195.36.203.58]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA07567 for ; Sun, 11 Feb 2001 03:11:00 +0100 (MET) Message-ID: <3A85F626.442F9597@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <41.7273ccd.27b4ea90@aol.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 03:17:10 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 011e88c1aac979872282962451526360 Status: R X-Status: N hi !
late tired answer...

Carsten899@aol.com wrote:
> typedef struct _TLBE {
>   UL64 log_addr;
>   UL64 phy_addr;
>   UL64 hit_counter;             /* incremented whenever the address matches.
> */
>   UL32 page_size;       /* size of page in bytes = 2 ^ page_size = 1 <<
> page_size */
>
>   UL32 valid:1;
>   UL32 access_rights:2;     /* r=0, w=1, rw=2, x=3*/
>   UL32 cachable:1;      /* if 0, don't seek in the cache */
>   UL32 lru:FCPU_LOG_NUM_TLB_ENTRIES;
> //  UL32 vimd:2 // whats that???
> } TLBE, *PTLBE;

VIMD ?

some code to let you understand ....

#define LOG_VMID_CACHE_SIZE   2
#define VMID_CACHE_SIZE       ( 1 << LOG_VMID_CACHE_SIZE )
/* hence 4 entries */

typedef UL16 t_vmid;

typedef struct t_vmid_table_entry {
t_vmid vmid;
int lru: LOG_VMID_CACHE_SIZE;
} VMID_cache[VMID_CACHE_SIZE];

On task switch :
  load MSR,
  extract VMID
  compare this VMID to each of the ones in the VMID cache.
    on identity : assign VMID handle = # of line which matches
    on miss : assign VMID handle = # of line with lowest LRU
  update LRU
  validate all TLB entries which have the same 2-bit VMID handle

[this is all done in HW, not by machine code]

the 2-bit VMID flags in the TLB is the "compression" of the larger
VMID which can be 16-bit or larger.


> ***************
> * MSR Register
> ***************
>
> typedef struct _MSR {
>   UL64  interrupt_enable:1; /* 1 = IRQ enabled. 0 = ignore IRQ */
>   UL64  itlb_enable:1;      /* 1 = use itlb. 0 = map phys to log address */
>   UL64  dtlb_enable:1;      /* 1 = use dtlb. 0 = map phys to log address */
no distinction is necessary between I and D TLB.
>   UL64  op_size_00:4;       /* size of operand in bytes, if op-flags in instruction = 00 */
>   UL64  op_size_01:4;       /* size of operand in bytes, if op-flags in instruction = 01 */
>   UL64  op_size_10:4;       /* size of operand in bytes, if op-flags in instruction = 10 */
>   UL64  op_size_11:4;       /* size of operand in bytes, if op-flags in instruction = 11 */
add to that : debug R/W SR, single-step enable bit, the 16-bit VMID, and a few others i forgot

> } MSR, *PMSR;

i wonder if it is necessary to repeat UL64 in front of every field.
The purpose of this kind of syntax is that we want to pack all the bits in
a single word, instead of wasting a full word for each field...

>
> ***************
> * CMB Structure (current. 02/09/2001)
> ***************
>
> //!!!
> //!!! CMB is supicious to change its structure
> //!!!
>
> typedef _CMB {
>     UL64    instr_ptr;
>     MSR msr;
>     UL64    reg[ 64 ];
several SRs are stored here :
- pointer to the SYSCAL handler (base + size)
- private cycle counter
- debug registers and event counters + counter configuration
- "next" CMB
- time slice limit
- current time slice value
and others i also forgot.

> } CMB, *PCMB;


not bad for a first file :-)
however there are a lot of things to fix.
good luck !

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.
From Yann Guidon Sun Feb 11 03:17:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00335 for ; Sun, 11 Feb 2001 18:22:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:10 +0100 (MET) Received: (qmail 32528 invoked by uid 0); 11 Feb 2001 02:11:21 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx24) with SMTP; 11 Feb 2001 02:11:21 -0000 X-eGroups-Return: sentto-1101623-2357-981857479-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 11 Feb 2001 02:11:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 02:11:19 -0000 Received: (qmail 44541 invoked from network); 11 Feb 2001 02:11:18 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 11 Feb 2001 02:11:18 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 11 Feb 2001 02:11:18 -0000 Received: from f-cpu.org (nas3-58.ras.club-internet.fr [195.36.203.58]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA26379 for ; Sun, 11 Feb 2001 03:11:07 +0100 (MET) Message-ID: <3A85F62A.2934D6AF@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm X-Priority: 2 (High) From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 03:17:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] jump latency Content-Type: multipart/mixed; boundary="------------699A4BA61EE2DA5C7521E787" X-UIDL: d52019719e3915f60b1dcfa2505a3883 Status: R X-Status: N --------------699A4BA61EE2DA5C7521E787 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit hello,

i have no time to answer the pile of mails i got recently.

however i have started to refine the design of the decode/issue
stages and it appeared that there is a "little" problem.

the "issue" stage is now in parallel with the Xbar cycle.
it increases the number of bits to "hold" when there is a pipeline
stall, but that's not a big problem. the trouble comes when there
is a branch : there is a latency of one cycle.
Look at the GIF i sent to see why.

This is not critical for loops which should be written with the
"loop" instruction, the 1-cycle penalty will only appear at the end
or exit of the loop. the "loop" instruction gives an explicit
indication that the fetcher should jump and go back to the loop start.
the decoder can send the signal in advance to the fetcher
so it "jumps" to the target, and the issue stage will "validate"
the jump or not.

Now the problems are plain jumps and calls. one cycle of delay.
argh. branch prediction is out of question today.
Fortunately enough, the jmpa instruction has a "static branch
prediction hint" that can be used to send an early signal
to the fetcher. no hardware is necessary yet, we get the
two bits directly from the instruction word.

Then the problem is to "repair" the wrong branches.
That is : when a false branch is taken, go back to the real destination
* It is not possible to decode two instructions at once
(even though the fetcher could give several concurrent
instructions) because the pipeline was not made for this,
it was assumed that the branches were costless.
If two instructions were to be decoded at the same time,
the register set would need 6 read ports instead of 3 :
it's not a good solution.
* The new instruction has to go through the first decode stage
again, hence the 1 cycle penalty that i can't compress.
But if that can consolate you, given the "state of the art
in compiler technology" (read : the cranky GCC port that
provides no adapted optimisation) the "compression" will come
>from the bad scheduling of the code [the time to restart the
pipeline will be faster than the completion of the instruction].
Silly but true.

I have also re-studied the load and store instructions.
the store instruction is almost straight-forward.
However i must correct some affirmations i made about the
load instruction. At the first approach, it doesn't
behave like i thought it would. It simplifies some parts
and makes some others a bit annoying.
When the memory is not ready (or more precisely : if the pointer
register is not tagged as present in the LSU) the instruction
is stalled. It is the same for load and store.
This means that we don't have to "insert" a pseudo-instruction in
the pipeline, we just have to care that the write slot is ready.
This is because "if" we had continued until the destination register
was needed, the TLB would be in use in parallel with the other
instructions in the program. And if the TLB result was "negative",
we would have to stop instructions that have nothing to do with the
fault. This is the same thing that happens in the current
architectures and that i wanted to avoid. So we are forced to wait.
However if the SW is well programmed, it should be no problem.
When the data is ready in the LSU buffer,there is no latency at all.
And this case can be true if the SW waits at least 7 cycles before
it reuses a previously modified pointer. Hence the technique called
"pointer duplication" (Man. part 7).


The real issue now is that i have not yet analysed the "issue" stage.
if the complexity is low enough, i'll try to keep the issue
in the decode stage, as "yet another exception to the rules".
If this can be done, the jump will remain costless.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www..com
--------------699A4BA61EE2DA5C7521E787 Content-Type: image/gif; name="sched_load.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sched_load.gif" R0lGODlhHQLHAfAAAAAAAP///yH+OlNvZnR3YXJlOjpYViBWZXJzaW9uIDMuMTBhICBSZXY6 IDEyLzI5Lzk0IChQTkcgcGF0Y2ggMS4yKQoALAAAAAAdAscBAAL+hI+py+0Po5y02ouz3rz7 D4biSJZgMAXqyrbu26YpTNexhJr6zvf+DwwKPblI8STDjY4P5vAJjUqn1OrH2cBytAuuwpsB I8TWsvmMTquTxiUbQrbEAfO1/Y7P64f199W9Fyg4SFjY06ckgthm2Oj4CBlpsAgHGEIpmam5 yXlpiaSo4cKz4qDieFqVylD6sxrZ2snoGVorinnx+oWrynsJprsT/Dgs2/X5ZxvmS1FMwjyb x+RsBa1D/bVpPYZMtLUNB24q3kVuoos9la4+ty5IDt8tZ85KnxBbgm+n7/6kj+buHzF5Wwg2 I8OinMBSzmK1WpiQzqiHKPD9u/FCopP+iAcoeuEYMaHHkDkEjjllkuOkVR5P3lj5iqJClx1R FmM4DeSomv3MxFOW7FaTVBZLxiRK7ahGdEZP3quI9KlTmDWl8qRa9WU5qyures2qcqZGmmO/ Slyak6vSlGmvlsVaFGvXqWffGRR1FwewI0rn+q1bj+zbmHSpRi3cFvDfvnJNKlbMN/LTIo4h SzZ7lDLjSWptBkZ8eXHozXS46vlJK/Wycbs+P04a2i9b038Bw+7cuvZtzKBp7/YajGVsy4Vt i2Fa/LBZ06R7XvPjLVG0oJW2ZtmIXTht5onfJseO+3p4usjF88bc/bHvpuNfx6ax3Dp6q+Un v4ehCnqHdvr+C0rfXpxlUC33m3su1VebgQl+F592AZJXV3cIqsegeg7qdh9rQ3FHX3o49ZYG f0CZ0t8GIubm2lcXTshhgCqxWF+BxqHIIn0RtkjgR20Fp1mFomkI5I9TIXghcSGWiNd/TeTF jXxOzsVYjfM9OFh6ClKYY4M9UpkVlDhiGGSE4Ak55YLxoUgmlIltRhohqIGiGgY3WciebFaC eKad28XY0JpjXhkYZaV9CSiaYtI4HJt9hkOocnqW6Z2bTOYy6YbHGGlchuaByRl5VjqUWZOA KgrgZG7hyWmKpEKKqVyDYilYXJCu2BxhgbTDUhaVVuDLMEgZpdmHblVWq4qX1Xn+4IA8vViS aMD6eF2waBKVqlhFPctqX8Aya4RIkWELl3DCeomWc/kx+ioXb1I3jw0H7rLlsliSJO62WIxk LVM8bmtfvzAddw+83/4rb6A38YMvwacqzPA44NqkhbenhvruIAh1JGrAI+5nTMeFmGuxPZwA jHHJ2Wzsn8cqnyZyLyuze2mnMmscZ3Qv36wGyO+0rAnJM0e8azM4Dw0Qz+wQnSSJJr9KM5xO Iw21P5URM3XUMeu6NNAom2h1115/TcXFMqu7q0NYg4122mo/022nDU1K7cxNr0133XSfGM7U eC9ZHdNaT2d34IJrg2QYhWfMSsZ/9z14446jcjilSir+TbnfiU/+eOaa37G3zYzzXTlflwMu ddx5X9GTrPmAU/VB0e6n8+ZJS35yzbVbfjXnweJ6Qh9t/qLINjKuJrsrsyPu+ei4377Pn+gS 4bvRccaeCzTUFy+HQjbMubWogirffO5hmhj9rXeuDj32Pty73tlPf4bs3Gv4OkPvvEoP/fnP WI9/8ewjzzT5cUwvemMZQrgVqYKZSlyCydSwDqaVWP3KYSRxVcXqkR067UtKybJPdjY4OJ8x b2kwG6A0HMPArkSwSC3J0qygcpH4TQuG2EDOCuPlpBY+Sk3D6cyWZBWl/kkKdCOUW/KOqDv6 eUpaJGRhojTVmFWpKoUpqpL+6LgkxQDSiktajBcLEXc9j4lQgAFEYsr2oBUZFelQqGpVsVjV KB21r1rtmRGVfmcm+UCkVGAbIwDLaML3GRCHhqoXRiSEyDZmcYZ8LJQhw+IpH+7kgrBaB7M+ GEG1+ZGEnAxk9sRnPhn6aFGKhOKoeljKMPHJdamqoWfyBCvDfAuPdhMbGQF5RgziB5Tmy+OV SJktU07IUTnUnyMJaalfyjFNjVzjUmBZtwPycV2g/Mhp4LdMY22KmVkcJiQZyUVvQhNRdUQV MMEJL1/erHPRqmHkjFhEXMoznsazDgr9FLFEmvOJjYyjKvFZv1YerI0NJChwwggJduayckT8 JD3+H3oI51nEha7CIcW8s0haFrOZHhpYJ9N00UFRMZYTdaDcRirEc5Fuoe5rKK/Ax1Ah6MSD b/zXtSwYg24iMpP+NE/8MvNN9ICrXLtTli8zYlM7CiioYnznSzEHU6Hxcqrra5i/GBaWb0qM LAmj1+6SxZZfffV1z7QqU8sqL33l5Id6Qxhbw5pSi82ggN373EfVdw7n4XWvx6vi2+oa07vy FXhUHaxhA1tEsgEWPi09bPCe5NjINpaeiyvhLScrWdiNNLOcvSw8P0tNiBa2s3LiKWk7u0nQ Bs2pp22taw3n0o+GlqWvra1t04nYP+IyesBY7W1/K1nTzrOTip3rX23+B9zkthapnqWjbnW5 kNNZsLnKre7mtrfLz2pvL9jF7nNN9r3RWne8jesuY+Fh3u5qN2t/zC553xu49LorePJVL+im AV2twne/XqvvTtDr3/P2Db/iUyJ/D0w0SNJwksOVkwxq8N10kVGv60WwhUd2EaKKl6r8YW6E w6taAMX1wiSWKVyL204s3g+F3SJwgUdc4hhDIah0jS2KWxxbHL9YxjxW2VntStmo0pZr/eyx kRvx4xzrtrJmJDIXjwxlN7UOs0sWspPfh9AoazlsU7byXZnsySNmectkLh0uUrtb3wJuzGVu syu6LN7/bfipNWPzld2MZ+319UnHFaSppov+PDvvOc+ETnJuBdZbwEpYuxTWSwLdWhYPExrP hqbyoO98tSuOMHa5Ai/NXDzpUFfay7BFrvcmbCipjm1uFRFtqLWsYNY6VaGnbm+qG7w8SQMS xq9GbYahimlLNxfEaRZxNIidjY30WtS/XqlY5Elr0RKbyQYOneJqzd5llznWwB7Sl2et428b eyhDvWSkRq3tC6Pb1SAG85DJDVNBp3veLT4z4zRNXYdimdf0Zjb1RIjvCNNu3/0uOCngLO1r z1nVBDe4w/f373vbWtH6VufDL94uexMx4IItdcMxDnLyRXzA4jZ1X+Udcnqvm7px67NlG0xt W6Z85lalc97cubX+1Dba1d2muYxXLvCKH0TOCd9xPX0Oa4Tn2+YrRoewi/3kGD7aqzdVOtKX a/WOOxjR8mW0d41u43Yr3DX8vrommw3khQaYwcOON9F3PfaHIqLsPa+GNKrLbWcv68eNXitG nh7z3BHd75ed+93xQHe9Yz04SBqo2wWfVcA/nnmDd581mZ6zw3MO72hX8jxvTKG1TlXntwZ1 tn8Wd2i/PfOI1zxwgV5yzO5c1pODzUt0mMlLSt3syYU9o9M++7oP3OK8n7nvoQ38WzMcZigv fp6PD/p4Bl/xW3+y81MOfcmDvfofvz7vs09qqI8z7Zhuvve3nfXf53j65D954s+/X/D+b5ex m+YFNc0P/6SPfLSBv7T782928td9wydm7weA4yWAzGd/3YB/B2hkCViAwaZ2BuiAypV37edx CxJtGRh6rjc/Hsh6vdd5h8aB1eZ5Jbh6R9J6K7h5FjiCT0eAJkiC3KeBIKiCLYiDr/eC4ReD KciDQieDN7gPNggQnLd/Ayh0YdaAFfhz6YdrQLiAI7KETFhiEKiEUVhnFEiFt2WFEyiB5aeF W1hbXQiGX/h/YohxZHiGHHiFaJiGTnh/WIiEbqhycMiAcqiAdPhwaoiCZtiHemhwfEiDsUR9 PQiIgWiHUoiHEXiI/SaIhuh/f9iI83aB5LZ29HcmuHKJmFj+gyw4hJ74gS7IeGUQhFFQimcQ hgtnikT4WpV4NDz3Zqo4Y6zoE7S4eMpGij44Y7pYi6AYgp8oglNIPoiXipPoWMe3PsVofcbY ZsgYUcTIjOnmjAcHjdG4bNMoDMo4fta4Zdh4DdpIfNwYZd6YV9UojpNGjuijO+fob+AojMPI joXmhMlojvHoZum4P/Voj/y1if3oj/8IkP24jwgWkAVpkAeJkLLoD7Zod76oPs7his/2jXH2 jgrJBwypUsDIVxC5gwVVjtJWkRYpUxgZNiTpOBw5imT1jBA1j03WizkYijCJVyjJW0BgLi05 kPfIW3WAk/ezYjkZcu5FQXNlYkP+B5TYx3YpdjY9OQ/3FZJHyY9JqUuswZRNSZVPCZVR2WVM JZX02E5YmZXxN2pciY8++ZVhaXxwRmNduZLzB45oSVpqeWJVaZZu+ZZwmVlyCUF0aZXzh5fY 13R69ooC85c0t5OQtYtVVJg6eZBXpXV7F5ClZ1wFOWsIaZmNKXw2FZmZSVT/SHvrhAwR+YOY d4qwuHwz+JjnsIqcOVtz1pqmOTTrIpoiGVOluXSnCYMVJgyrWYi6SYC5+YSYB5wJFpodCZu1 x4u3CW6cyTazyJpl85kYGHRII5uJmIV+OIhh9jKvyYbv1p2aU51HmIeRmJ3eaQzcWZ7Y+ZvX VZziyYj+30me6+ljaiad8hmfIdSeGned9ymc5ikL6Gmf8CmgJ5mf/Fl4yhedJ5ieTUVx/ame HLaRBSqg7mZE1wOgSbgyF+qgkUihwRlfErqgyDd5AxqgIXqe9KmgARp9vomfQMGHK1pGFoqi qNkJGoqb3gmjdymTnvSiVMZ+KYqhDzoyMzqchZOjEeqi1mlloCejDXqj8+mkCUqCR7pX4amf QnZ5y0ijG0qiNUqko/mkIQamtQSiv/l1jdWkJtelQxqlzKkfZzqm0VSmLDpci9B3UgqcG7ib ztmbHrqcimeneNoxVgqLiUaayTmdYbp0vMaof+pnrgmki0qmSZqS9QmFkNr+oHr6HHxqqX76 nG76qXczp8EZh5iqptPZqJwaqRqqqUF6nKBJqVc6nmuqqCb6n19Km0UKqqIaqwYKHWn6qL6a CTYqqLkap7w6PUrqMIL1o1taqyV6q23ap886GM46qcnqnrmBbIG2iNrpn14qrZ1aq6aTpQ85 quN6evUnpNTKpScarpGKrqh3rGtDqBOaety6rsX6qrCAq/t6gvgGo5lTryEKsGjard/artF6 qtDqqssjojN5rkZ6r5wErC8nrJJArLuKgQU7r5q0oIRnr+kqPxXrkrTaM/2qnD3Hscb6NZRQ rmilohNboQebrxqbUCibqBIrsjkrp5YoXF2UrZ/+xqwIarPWWrSQ865GS33h9bL+s34MJYgt 17Qk6601i7E4m5rtKrVKS6+59bKzyXM/O7OmGqySqqpB0Kqe2qetKrakeq0WCbKoeodka7Fm u5Bnm6fQebSjqaMXqasnZZwpu2aImrXsmrbNebdrq7fT6qge+7dAi4uMi5x0W7Jyi7dH16ms qq9227WI9bXK+p622rCiy6YLO7oMm7AtGlifG7Rl6H8ui7W3chewm7SP67iQCWEt1YW651JU S6f+yrUdm7iPigmzxbvBmzamZ2lxK5+2sl7N6qPClrHIO3T3crglErBqS37O+3lImpqsK6tg dEvQu6TSi7M8w3Fum3P+5ru+4iu8aDOw66m8TEqz4seywIu/ShK54tp4pGa8I2u7yRuxUDW/ BmuGHaq9QGpee8pqm/tcCPy/gRbA8DvAK1XAI0qwhXWhMoe4TXO9KqvBBHHB99s1htdQuwvA GNy8uTvBfMu/zZu1rTlfLcxLI5y/LTuU48S8QYpsU0uz2au58PqdzbK3o8e+ptbD1NtHNnbC oOtp4US0zgbEi0vD7ddqRRxk/msQ09a0stPFz+uYrupW9Gu1hlq2RbNNQryrZmyxY1zFJey1 UBu4PDu4lFu1hcqbfqu4merAMfy2WQw+YCu4dmWbdJy5fXy6qhmqZ+zHfNyz5au7c1y4v0r+ uL/buEpstYxMp0EsuXuMrEYcyZWqxnWMx47cyZqcD5d8x5xbt4acoUwsx627hqT7XZycxwjL rrUcuwkswP/UxLIsibTccaw6w9nIwlgsuGxcuaj7oTfHwY94qRwqlDdcym/8r7lspNM8yKP8 wp/MLtB8qAf8xJhczdasfafseUzbzevMzbf7NOB8mr7rsMq8yqnLwOwcxzu7zeS8zxTcqyY7 uZe2su9L0K5surwcvfps0OZsyY/8zk7shQIts5OMzAjdyhQtxRPd0OjMz1YTvx7ZzyoM0lWm 0JNcY/V8CLJ20h6sy0bZ0RjduVy6w3vH0DGqLlxJOembs8Klp+j+e8jVG7BiZ608vcvEKXu/ nE88Var5xYuaRs8UFF0gTArwupNRrTzbutNSOb0xDcpMvXYL7dUBlqhVs5mbXMzfeMz1JpCF S9YACdYk7NH5HNZfbdF2eYkb7cz+uMkliTqbCWBuXdfUDMcJPdebuAQJSV8Gectoi9i/gJkH 3bcjSdh2Tdd/7ZmBTVNrnapmdtmWrdeYbbnejGqxrGzHvNQBY9rO/JypfblVpQSsDdX6m2Gw jcqRjbZcp2uUN9taPbfJxttpnA4d9tvDK9ltkNvZZHEzvWCFjLq2bZNcO9NJVdDqCl3Ly39N l72UVJZTqUBuStSTNUZryWK1u8SPG93+CRTS2/dnk+1ZNems3Cs98I3NK03SoZzU7fzSUPPR 9hzPP3zEqKxF6T0dylvTVGrfF4vP/oyt4Rtu1D3E/33RJyXYUFvOLzfFlJTI6z3hUbPf2Axo YyvRWmzKFTrVElzRsdfeYczfCyPgg73gFzveWsreLQ3ZKbypFIvID8uSKu7h6I3X7qySbAzP lCzORVfjJn7jJH7iYGzkNdfjCV7ePjXMPJ7j5MthxvTj743jKa3kS/55WA65CI7fCj46Og24 wDyIwJpeYw6mXOzaXfTkG7fApC3m+U2d1ja0GL7iAe1xcfDU+erGEXXecF3SKa7ncW7nRn3V D0zlXm7lt+P+52xO6LKrDJFO5wDN0WQO6Yx+6FUexVA+6aBtF+QNeWjOzH/M0nne3XutiHaM sB980B28qqMK6z8t2nEHvhX+qndaexurygBty7Pedpce2sda66+c01Ou5xsYqOO2Zr6+yLdg wn396wUG7auuvn977FAq5YSo3Nl81iDOyiT157r+k57KP0TsyYSM3KW+v/+6Pa6Ow6r9OVHr JyO7iEbVJXbusiX1Ztwr6ZtGJ3Xa6Et772/dXxUsnZWHryenIsoe69VqYlgN6gIvGxDv5IfD 8DAN5MnTo4tOsfXLGTxZNu9OjYOMnlcs28CMYmYusAp/zSAv7rbqO1TM8WxIuwv+W/OdLtWZ hvAu/tAsb3kNP6Aqn+l8a/LZuK8p76GDDqhDf/OanvH1DtGxx3Ek60UYH+GlYTbP3fUZHs8P X2FOf+2bHvVRvtBkH/M+H/LlN/Dlvqaz9POh4+8VD8A8QvA8//QyL+r6natqP4Nvd/X53u4b zup/5tO4te0GnMa6jeaCP/cc/vcFv/DG9Og2DuHL3OB80A/3V/YwO7oc1Pd3XjtpROwM27aX j+SZj9I53twM+PnQnPre676cju2IzviYbveRT+kRv/IMjsuoHuAHqve73/Z1XuB+T+qOD/yZ 3PHDb/s1t/gine217frXH+38ruLTL+8Jj9u53USSzKL+X6/eh2/9Xo77r+7py/5O5G/uaK91 uT7u2qrqmbj+617cemzrQZ/04UeuW0oAwTF1uc1fk5NWx6LMawe/AVCrokw8QA+zUNZt2XN9 aUuu8dC9FT7vPpwdCWEaxXI91exi+6RUj2BoWfPhgFUsxVg8JrTb5HcsLJ/R46s13VOGabwu jNm2iZFmqpePt2fXmsjm9IoCBf/s+hQZG+kSGQHVuMAqEeOWpqjgdN44ol5E5gjjGiWT5Cwf 3ZTKDociHWVjaRVPfygXZV5Z6Ug7C4E5yRZVgdlqUTT96n6L9yaT23hnqy/TqInAlpEHjXv9 TlIQO0IhtJzzbN+yVwvTj5X+XU3pre1R69e3h9XJv/9LxXsyrhk4be6EAew3jV20CSWe/eO3 EFu+exdh6dOobOLBLxCJISNE8J3BXDBGKbwj7YlDDVLkhezokaE0jDdDomn3sCE+LjChXbNS LqZCokFXogR5rN1OYi19koDKs5XLmhtxZg1WkSW3gFK9bh36yUCVgfvQRbkycErZMFOZcTU0 kypWpHF1WtS6F+EZp5fgdoPEl7DdvGityjU0z+bhwnv/1rnKcWdksY8xC568qbLeu5oVb858 0bJJx5QTnx69OuNg1FFBP6Nb17Vo1tVKq7Qa+GvsvreBm/bbU7fwpFs5BcodUWhz0oSVt97M Ozr+LueXg2ddvoq6dOKLryX3rpr2Sa3be5tXH7o7RcRVJZfPDllv++PgSqSCX5w/3uvG70HP HPf+s24ukmgyJr/1crqtIwHRu4W5+Nwp677P4pGPvAYpxEjA8QqccDevqkMuww5RHBC39SKL 8DvfoKBoNg5TG26+FRuz8cAaY7wQxx9BTI+9sEBEkEWnXMzxRtt0rI03FU0qcRq3TIArk7+o 9AStzrqasUMj5fMyRdiYXDK0M1V7skjs2ERlqRN1AMpN2dokkLEdyaRTpR7z3LBJMw37c0gx hTNyl/qYI9SbKP288zUDGd3zE0fLrBFQQRsdUdFEgzmUJU4nA7PF+oj+JJCtUz3dhlI0Mb20 1VXTLNVHzlDlJ8k+xHFN1EzJVNPUBGVD0jNeXfUP1j99ndWHVP9401ldTfwNWGRlnXZZmYRV 0tJiIa2012oZhFPSWEhMa1MtNTlrn22/PVfcxNx9t89XuTWW3W6TnfbYfesNUlMu7Yr31tr6 nZffdgEmmNiCNaTW3YGL6pbVgxmelWJm8g33Ykzi5RbijBteVeBh6a3Y4nsxBjdklE0OsNaX YX6LxB1irvnUSes80Oad/WVn55+BDlpoVHvecmii3+uPsqORPrllM+3LTDyoAf1QW+1mploq qK2WJWrMpl6ya4WBG5tjMIO7Qd20QWbt68f+wr7R7IndXu3ttM9RGbK1XW0burmfDvxSv8Vu erRa6yV8b8EZbxwLvatmi22++4acr44dzzxxy7lW/CbJN8fcGtE1L71zwEmj3G7VIyd9FtdN j71szuVmXWrbTy9c9t0d9zy7tlDnOOJifccJdt6R//v4vYP/YfnzaMc6+ekrLt7t523BHmvt p6Te+9CbN4V7bMb/PHrjw/9efTfLx619V95PPf45169/PuvBnt/59N3X/3H7ATg7/02Jf6EY 4OiydjhRVI2BWrsdHApowAjG4IAIhOD1xnS4BoptdRes3QSdAEKvJfB2GZTaBuXWQbSp8IOl u9vfTAg2FN6PhQD+ghsofldBl+mQggH0oQJ5KLwWmg5/qfvhEQtTRPOJ8CdM7J8TX4JEKUIv iBSE4jl2p0R7VHGK9dPiFrn4kDBa8IoYKGMXp/fF/hXujCMcIwTQGEcyDvF+b5xj7eSYR0eo cY92JEsaz2c+PQ6yWX7kCBupx8cREpKRfgmkBRGZyEcasZGVfJwfJ7nD7ymyj5b0pATLmEkw tnGHpATPJ1EpxjeKEpLqe6EZmYa4/YjIZ7HEXc6WZku/KUeXN7MTFVcIy17eUmm0GqYhPURC jcFrgb80GC7lJTEa2VCaIUqmB51WzRhG0168eyU0oTQ8aVGzm8WE2MrI6ZttlhKa55z+ZjHD 6b1vplNIcVvmM+npTmtyU53gHGUw/elMc5Isefg758iupk2WCWlhAkyYtxSKzyw+8qDZCtTG GFqyiObwYQRdaDwl2VGbIPSiHy1aOVHqUJMKNKUZLShFPUNSsmEUpBpt6fVEWlKJ3lRzBo2p RWe60mzyVESmVOVD6bbTfnoTpiMFKkSJOtSl5uqdk0NqQ10q1Mb51Kk0PelSN9pNZtETp1e1 KVijutWmBuypSQ0rWqfKIaO+JKdBVWpWmVpX0cgUqnDFa0THCs8avvWvab3nRPV6Jr661bDo BKxc+8VVnRK2pi9NLHkWi9XKavWeVN1nWTnr2MZWNXaSLST+6O662dR+laE1O6xVQ0vawvrV hcoU7VB8mU+P6jahtCwONaR0Q2zqa6HBZWxpbStb1Q60t+MULEudS0vgspadvJ2sb7FL254m 97OsNS5Wv3tWfo53udmVH0DJ6l3qrjdz83yuVMerz23Kt527fe/ruLtO9UJ3tkRcq10py174 lle7/AXtag0sYOLm1axeTfCDB6zg1xb4gQ2ObXchrNbLipfA/e3wh7+arts66L999bCEBWda E4M4wxM+sUAzUdTIlvi4L45we2msWRQrd8cYzuazfJy/DTv4xkXWsIURbGQXs1jJ6BwJj4GI 5AC3eMS1HfKF9UtlKDd5mk8OsnD+pTzaL1d5u1dO8oKnzOUxd1lBWxZymCmMZjG3TMU1ZrKc 47zknnk5yxXGckDV3Ocj/zm9Wl7zoQXd2TYjGpiEvq+eDU3nHHO4x4kmc6TrtBS1zdjMacaz jQd9ZkgHGtCfvvNhY4wh8x7Y06M2daVN5t5V75fU1n01f8NLlpnkutG2NjGvRZ3i/JbaxcAm rLFbimy/QlHW0V02rAvdu2FH+9PK7q+1O4xtWr+5vs2Nr31l12zybtvVxYY2c2uNbm77usba xnT1Jk3kW6d71u9+9KX9HGw3lxvfoW51v/m975Vlg776vly8HV1venMazqAOOKON0xSSWala c81bwp3+7XCAC7vTcyb2xiH7H/miQzcWFybGx21vhfvb49R+uKVDPqaRGySwrWv4qUEOcYbV Wccqz/hmPatzUOkJ5gfveJ5zXnRJH13jAnf6dYKu9MscZUIm1zXKC/7vwPGc0j5PudOa+fQv RUrq27v5uSPS1pCe3etZNxbMXj51sn9ceWxf+IliNm+Wx0btXbfdzEVO0DdJy+ov+mu6SuVO /Yg91jnOe9wjnnih/6bm9445EJLe68e2IB2KJ27h3XjVxU9eXNcq+3tHXylu+Ar0eFIo1RHi 9hS1XnzDZZDp95lr3LOb8bwnvbuf2G3AiMXaBM88vG3f703j+p1RH7Hsv+3+bWZPu+RzNy/w 30X7SFB/5cuHb6r45nzZQh/75o6y8CWDtuK/3n7iNv74gwR7OK1f+mjP+PSTTyP5h73aGfS+ KxFu4ATP+lZu1FLPzuzvvLZl/04v7RTNixzv8wZQIn5PrMAN6epuAQnw64Dl8Y5v5yLQyQTP tRpwnGSp9yyP9Krr9UjQ5TSk7yxL9OAO8salYehL0/SOBgswiRBu93YQBX/waXgOBi3FB4MQ RfisAr2N1ezFCDlQB3+uzOwuBz/wCLEjCUvwCavwmqYQCrUQCBkO6y6w6ZwDC+lOCT0mALUO DQFwGCpuDA9pC8ftDf1BuoQIDL/Q6MThQeBwE27+bxkyRvuyxw1Zrw9xB/qWRv90Qc8OsQ/P T5gqr4nsCSxsBY4WUQ7TkBBZRxQAEVxeIbcAgulyif9KwgTPJiwQcbBqiRT57hQnkTsARBBP K2iMwgxX8Wj2hOCGCZ48cRet0AXrjhZ/kBN7KRQ38BdBkGn6AvbU5pjkxBJBqRjzEBJ1KQq9 rpSGxhpNwxmfsRgAShYJyJbSj024UWW8pByXBx3JT4ViCVbUcRxjEYDaEe+OcRTnkZesyBcj xBm1sf/YURj/Tyi4MfbqcRpdyJisBB6rDwleRrB2bQga0reI6foQEhDH0OSoBBQDkkKiIyKX kehUcOsQkiMLsiNRC/X+NnIEQLGoMM/cVrIfzY+DXjL7OhAiT3LoWhIPj6zyBk9ePrEQnae7 GjEnnPCoIhHl3uwobUa/hhKWDC8Fw40PmSAnhVIq6cchrfIKGTErV6xyDpA/WLGJvBAcNQiL kiYLU9FOjtIggTEkaYY+mg8tHXGK0vLuAE/m5lLy9FASSSclt3EuqfCH6jIw2TDixvKSdBIW mnFBes4uAROJBvMwlWQt61Ivk8gsVaXrHJNmZIUsT2gJ489aPCos21Iu4QYaSzMylQ8TEyka 5XAt5280qbIwEdBrzEhnVA3oCIcXbrIf/bKR3o82T+k2TdMeDac4AWyUcAZ0sGQ1Y9Es0Ev+ EVOJA3+zCD8Dh86wIMDuMVlTguDjSmBSxm5v6iBI/n7JM2WoCScwKHoyPBdlwVQzMd+yJaHT PWlyPAsl6khzIVMpOJGTEtaCO/EwPnXCQjITPHPTX5ywSlYvP4KA5DKtO+lsPIry/qhrDejv uiy0/rYvYhA01ebLKE9QFUAhLXLpEfZTPOmSQiWQ+Rjy+7yjQjd0O5+tQ1ECGtTCLeAvLs0g 1a5ECoAURanxOEvzIN1DRjNUD8xi6PwRLGMSPpPNRl/jR/1wRwukmXwUSHU0JpwBSdHou5bS SvVlS1VF/HIPZ1AzRJ2pBdWNfL5zus6zJnGUS9WCTo1xmdDzNCP+dECjqE+z00TK0yftS2aG ky07yTbdLEg74UMV1Ty9dDpTlPDWs0EO6pTaEyr3FD+KFL+qhG4m0hKy1E4f1Dw1U4oi9T4v qiizzkDbTmNskcTU6FZKtFP9kPsw0IcI9D8Z6xN3i1ngIdwsgnJmJFflUUCFU6NYdTNjjilc KabSlE8h1Vh1FbMs1Q6vxlcxNbKcFTOvU1qLFTRbdaSuM1mntQaZdZO2la5Q0Vvbj12z9V2D RYwk8wU1FV3FVd68UJ7cFRn5tUKgNKEIVT45CFyVFZWIdVPh1V8fUEMnMk9bLmENtV/tVUPJ sFzx9TWblWAJMwv1VWPnNTlv1WKB1WP+MbaLyu/5EjBJfy1lE3CPWNZFKbZjC/ZJVzZcYTSE VHRjA+RlbzZmW9NmmxRko49ijQ1EqxNhgeRjabY2C4png7ZmZxZlTwIeTvZznHZpG9NU99U+ Rdbg8PISOXaGmFZnkTZjfRZouxJtS5HyzFZocU5gkedgIVZuJXb0qLZt0zZqLYluufZPyzZi TRFs/TZxthZwDVdm3fZqx1Zp17b08HZxS7Y/C5dvDXdVcUVCU4hkoVVyNfdYL3Zz+1RR3XJg z1ZvK4lyUXdy81FGS0t1OzeAUvd1B7duC3dwXLd0tVZ2/zZ2cTdfxTZrGXdvbzdx1RZ4MZeG dHdup7Nyhzf+b8n20WDTSHs3cnPXdNWUaBVXTF2qaj0ke880eXvHe69XaLl3fPG0XLT3d8QX /ZzXm9bX9zCqfNk3ZEbhK0eXfC/yfb1IfymSQ613fv01QK8xf/33eSUWcduXehMYdCUCQx/X eBnYk3iXeP93XqLzgH+3VIP3dJsXciPYTy64b7UVfEUYYhHYgz1XDHPEUOAWeaf3gzmYhJlX hvWJhe/XhSnYgEt4fSZ4gVPYgtn0b22Xhmv3Z1/4h9ewXCvUYUN2dnf4iSc2hzf4c491iR9Y gxVYgjsYgpH4YTHYgaQ4i4WXiMn4iLuWiLYYiwUzjan4jL0YiofYjJ34cI04jGFUuI3nmHLj 2I67+IqHVBq/Dx29S5BxjZDvzmVX95gGuRy/NIMdxJHrBoxxeHn5+DkkWX0vGW8ymZLVuHs3 +ZE/OZJJl5NJuZRN+ZRROZVVeZVpoAAAADs= --------------699A4BA61EE2DA5C7521E787-- From Carsten899@aol.com Sun Feb 11 09:00:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00341 for ; Sun, 11 Feb 2001 18:22:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:13 +0100 (MET) Received: (qmail 19755 invoked by uid 0); 11 Feb 2001 08:00:50 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx13) with SMTP; 11 Feb 2001 08:00:50 -0000 X-eGroups-Return: sentto-1101623-2358-981878448-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 11 Feb 2001 08:00:49 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 08:00:47 -0000 Received: (qmail 28507 invoked from network); 11 Feb 2001 08:00:47 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 11 Feb 2001 08:00:47 -0000 Received: from unknown (HELO imo-d02.mx.aol.com) (205.188.157.34) by mta1 with SMTP; 11 Feb 2001 08:00:47 -0000 Received: from Carsten899@aol.com by imo-d02.mx.aol.com (mail_out_v29.5.) id r.37.1090e75c (3871) for ; Sun, 11 Feb 2001 03:00:41 -0500 (EST) Message-ID: <37.1090e75c.27b7a0a9@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 03:00:41 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 596dc0507f8d326349953427e1916f15 Status: R X-Status: N some early tired questions:

Does VMID stand for something? Is it an abbrevation?

>>[this is all done in HW, not by machine code]

is there a reason for doing it in hardware? speed?

>>the 2-bit VMID flags in the TLB is the "compression" of the larger
>>VMID which can be 16-bit or larger.

how does this compression compute?

>>add to that : debug R/W SR, single-step enable bit, the 16-bit VMID, and a
few >>others i forgot

* What does the R/W SR bit mean? does it enable something?

* What happens if the single step enable bit is set? does the cpu halt after
very instruction? when will it perform the next instruction?

VIMD is clear so far, except how it is compressed.

* Which are the few others? They are most wanted bits for a definition.

>>i wonder if it is necessary to repeat UL64 in front of every field.
>>The purpose of this kind of syntax is that we want to pack all the bits in
>>a single word, instead of wasting a full word for each field...

This is C-syntax. The compiler compresses all into one UL64 if possible. You
cant remove the type in front of the element. this causes compiler errors.

>>- pointer to the SYSCAL handler (base + size)

okay this is SR_SYSCALL_BASE and SR_SYSCALL_SIZE. Both 64 Bit?

>>- private cycle counter

a 64 bit counter counting what? the overall cycles of the task? in contrast
to "current time slice value" which start counting from 0 when the task is
enabled and counts up to "time slice limit"?

>>- debug registers and event counters + counter configuration

which debug registers[...]? its no problem to say: up to definition.

>>- "next" CMB

okay. a 64 bit pointer value.

>>- time slice limit

okay. a 64 bit value. max. cycles for the current task.

>>- current time slice value

okay. a 64 bit value. it counts cycles!?

>>and others i also forgot.

lets say: undefined spare areas.


carsten
Yahoo! Groups Sponsor
Personalize your company´s name. Choose the domain name below and press SEARCH!
www.
Yahoo! Domains
From Nicolas Boulay Sun Feb 11 11:39:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00347 for ; Sun, 11 Feb 2001 18:22:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:15 +0100 (MET) Received: (qmail 8361 invoked by uid 0); 11 Feb 2001 10:29:07 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx01) with SMTP; 11 Feb 2001 10:29:07 -0000 X-eGroups-Return: sentto-1101623-2359-981887337-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 11 Feb 2001 10:28:58 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 10:28:57 -0000 Received: (qmail 57433 invoked from network); 11 Feb 2001 10:28:56 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Feb 2001 10:28:56 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta1 with SMTP; 11 Feb 2001 10:28:56 -0000 Received: from ifrance.com (nas13-215.vlt.club-internet.fr [195.36.163.215]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA03803 for ; Sun, 11 Feb 2001 11:28:53 +0100 (MET) Message-ID: <3A866BD5.342B65CB@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA5C@po1-exch.lon.tudor.com> <20010209144114.53820@thrai.stud.uni-hannover.de> <3A855790.2243B8C5@ifrance.com> <20010211000104.65025@thrai.stud.uni-hannover.de> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 11:39:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4358ff796cb86c0da3c47a4bf0803790 Status: R X-Status: N hello,

Michael Riepe a =E9crit :
>
> On Sat, Feb 10, 2001 at 04:00:33PM +0100, Nicolas Boulay wrote:
> [...]
> > In fact you simply put an enable signal inside a process :
> >
> > process
> > if enable_process =3D '1' then
> >       ...
> > end if;
> > end process;
> >
> > In every case, that's work. Power compiler from sysnopsys could u= se this
> > structure to produice gated clock. (a specific design with ff and= a
> > latch on the clock and a "and" gate.)
>
> I know how to do that in VHDL... I just wondered how a `safe' (i.e. > not timing-critical) clock gate looks like in CMOS (or any other
> technology).
>

It could be safe. Before entering the clk signal of the ff, the clock
signal go throught a latches and a and gates (with the enable signal).
So you can toggle the clock only when the signal is zero. (you must
absolutely avoid spike)

And without clock gating, such vhdl code use multplexor and that work,
too.

nicO
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>

Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.  =
=0D
3D""
From Nicolas Boulay Sun Feb 11 11:41:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00350 for ; Sun, 11 Feb 2001 18:22:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:16 +0100 (MET) Received: (qmail 16306 invoked by uid 0); 11 Feb 2001 10:30:54 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx02) with SMTP; 11 Feb 2001 10:30:54 -0000 X-eGroups-Return: sentto-1101623-2360-981887452-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 11 Feb 2001 10:30:52 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 10:30:51 -0000 Received: (qmail 59437 invoked from network); 11 Feb 2001 10:30:51 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 11 Feb 2001 10:30:51 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 11 Feb 2001 10:30:51 -0000 Received: from ifrance.com (nas13-215.vlt.club-internet.fr [195.36.163.215]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA09133 for ; Sun, 11 Feb 2001 11:30:48 +0100 (MET) Message-ID: <3A866C48.1B7DF88@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 11:41:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 60d3babd19ca56520f2ff3ca1741b4fb Status: R X-Status: N Hello,

Yann Guidon a =E9crit :
>
> hello,
>
> i have no time to answer the pile of mails i got recently.
>
> however i have started to refine the design of the decode/issue
> stages and it appeared that there is a "little" problem.
>
> the "issue" stage is now in parallel with the Xbar cycle. > it increases the number of bits to "hold" when there is a pi= peline
> stall, but that's not a big problem. the trouble comes when there
> is a branch : there is a latency of one cycle.
> Look at the GIF i sent to see why.
>
> This is not critical for loops which should be written with the
> "loop" instruction, the 1-cycle penalty will only appear at = the end
> or exit of the loop. the "loop" instruction gives an explici= t
> indication that the fetcher should jump and go back to the loop start.=
> the decoder can send the signal in advance to the fetcher
> so it "jumps" to the target, and the issue stage will "= validate"
> the jump or not.
>
> Now the problems are plain jumps and calls. one cycle of delay.
> argh. branch prediction is out of question today.
> Fortunately enough, the jmpa instruction has a "static branch
> prediction hint" that can be used to send an early signal
> to the fetcher. no hardware is necessary yet, we get the
> two bits directly from the instruction word.
>
> Then the problem is to "repair" the wrong branches.
> That is : when a false branch is taken, go back to the real destinatio= n

You now understand the goal of predicat ;p The instruction is validate
only at the far end of the pipeline. But you can simulate that by a
"validate" signal at the end. It's just some more silicium.

<...>
> WHYGEE
nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.   
=0D
=
3D""
From Yann Guidon Sun Feb 11 16:42:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00383 for ; Sun, 11 Feb 2001 18:22:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:23 +0100 (MET) Received: (qmail 32545 invoked by uid 0); 11 Feb 2001 15:36:15 -0000 Received: from hm.egroups.com (208.50.99.198) by 10.1.4.112 (mx12) with SMTP; 11 Feb 2001 15:36:15 -0000 X-eGroups-Return: sentto-1101623-2361-981905772-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 11 Feb 2001 15:36:14 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 15:36:11 -0000 Received: (qmail 4980 invoked from network); 11 Feb 2001 15:36:10 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 11 Feb 2001 15:36:10 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 11 Feb 2001 15:36:09 -0000 Received: from f-cpu.org (nas3-50.ras.club-internet.fr [195.36.203.50]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA29866 for ; Sun, 11 Feb 2001 16:36:07 +0100 (MET) Message-ID: <3A86B2D7.99EEDF04@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> <3A866C48.1B7DF88@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 16:42:15 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 144c99a6512fe70efbcd004e0192ff70 Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Hello,
> Yann Guidon a =E9crit :
> > Then the problem is to "repair" the wrong branches.
> > That is : when a false branch is taken, go back to the real desti= nation
>
> You now understand the goal of predicat ;p
the purpose of predicates is different.
predicates don't help with delay slots.
the problem with delay slots is that it
changes with the architecture while SW
doesn't evolve as well. your predicates bring
more troubles than they solve.

> The instruction is validate
> only at the far end of the pipeline. But you can simulate that by a > "validate" signal at the end. It's just some more silicium.<= BR> i know more or less how it works but this doesn't solve the
jump latency problem at all ! your shameless plug failed.
you execute more instructions than necessary and you don't
win anything.

there should be another solution.

> <...>
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""3D""
www..com
3D""
From Yann Guidon Sun Feb 11 16:42:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00386 for ; Sun, 11 Feb 2001 18:22:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:24 +0100 (MET) Received: (qmail 11712 invoked by uid 0); 11 Feb 2001 15:36:16 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx24) with SMTP; 11 Feb 2001 15:36:16 -0000 X-eGroups-Return: sentto-1101623-2362-981905775-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 11 Feb 2001 15:36:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 15:36:14 -0000 Received: (qmail 71544 invoked from network); 11 Feb 2001 15:36:13 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 11 Feb 2001 15:36:13 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 11 Feb 2001 15:36:13 -0000 Received: from f-cpu.org (nas3-50.ras.club-internet.fr [195.36.203.50]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA29879 for ; Sun, 11 Feb 2001 16:36:10 +0100 (MET) Message-ID: <3A86B2D9.DAEA74B6@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <37.1090e75c.27b7a0a9@aol.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 16:42:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f5afe8cd1903f71495b34e357894ebdc Status: R X-Status: N hi !

Carsten899@aol.com wrote:
> some early tired questions:
>
> Does VMID stand for something? Is it an abbrevation?

it stands for VM and ID :-)
it's an identifier for a Virtual Memory environment.
it is unused in "kernel mode" (when TLB is off) otherwise
it is similar (but not identical) to a PID. It can be shared among
several processes/tasks. for example PID x and y can have
the same VMID z and therefore share the same TLB entries.

> >>[this is all done in HW, not by machine code]
> is there a reason for doing it in hardware? speed?
speed and ease.
it's very easy to make in HW (well, it's no black magic)
and it spares some amount of cycles when switching from a task
to another. This is what would be done in the end (hence,
that's how it should work in the simulator) but if we can't fit it
in the prototypes, a bit of SW will be necessary.

> >>the 2-bit VMID flags in the TLB is the "compression" of the larger
> >>VMID which can be 16-bit or larger.
> how does this compression compute?
"cache effect" : the VMID table can remember of the 4 most recently used VMIDs.
so we can associate a 2-bit number to any entry.
we imagined that 1 year ago with Sven in Berlin.

> >>add to that : debug R/W SR, single-step enable bit, the 16-bit VMID, and a few
> >>others i forgot
> * What does the R/W SR bit mean? does it enable something?
it allows a task to write and read SR that are not available otherwise,
ie those that touch the protected memory (the TLB management SR).
only a few SR are usually available to the user tasks : those who define
the configuration (hardwired) and the basic parameters of the task.


> * What happens if the single step enable bit is set? does the cpu halt after
> very instruction? when will it perform the next instruction?
it executes an instruction and triggers a single-step trap.

> VIMD is clear so far, except how it is compressed.
it works the same as a cache memory : a buffer stores the 4 last used
VMIDs and the entry number is encoded in 2 bits (but this number depends
on the aarchitecture, it should not be fixed, it is an internal signal
that is not available to the user).

> * Which are the few others? They are most wanted bits for a definition.
i said i forgot :-) i haven't looked at the archives since a long time.

> >>- pointer to the SYSCAL handler (base + size)
> okay this is SR_SYSCALL_BASE and SR_SYSCALL_SIZE. Both 64 Bit?
"normally" but i don't like the use of UL64.
what if someone wants a 32-bit version, a 128-bit or a larger one ?

> >>- private cycle counter
> a 64 bit counter counting what? the overall cycles of the task? in contrast
> to "current time slice value" which start counting from 0 when the task is
> enabled and counts up to "time slice limit"?
that's it :-)

well usually it's the reverse : the counter decrements until it reaches zero,
it makes the HW a bit simpler. but OTOH the task cycle counter increments
at every cycle.

> >>- debug registers and event counters + counter configuration
> which debug registers[...]? its no problem to say: up to definition.
they are still undefined. a handful of slots should be reserved ;
they often work by couples : one value register and one configuration register.
4 or 8 such couples can give a decent picture of what's going on in the CPU :
count and duration of issue stalls, memory stalls, hazards ...

> >>- "next" CMB
> okay. a 64 bit pointer value.
as again : what if someone wants to play with another size ?

> >>- time slice limit
> okay. a 64 bit value. max. cycles for the current task.
yup :-)

> >>- current time slice value
> okay. a 64 bit value. it counts cycles!?
it decrements.

> >>and others i also forgot.
> lets say: undefined spare areas.
the CMB by definition is undetermined.
it's the same as the SIMD size : you don't know until you read the
hardwired configuration SR. to each "family" of implementation
will correspond a specific CMB structure. However there should be
a minimum of compatibility between every CMB, principally the structure
of the first entries.


> carsten
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.   
From Nicolas Boulay Sun Feb 11 18:27:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00395 for ; Sun, 11 Feb 2001 18:22:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 18:22:26 +0100 (MET) Received: (qmail 14823 invoked by uid 0); 11 Feb 2001 17:16:43 -0000 Received: from fh.egroups.com (208.50.144.71) by 10.1.4.112 (mx12) with SMTP; 11 Feb 2001 17:16:43 -0000 X-eGroups-Return: sentto-1101623-2363-981911800-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 11 Feb 2001 17:16:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 17:16:39 -0000 Received: (qmail 21915 invoked from network); 11 Feb 2001 17:16:38 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 11 Feb 2001 17:16:38 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 11 Feb 2001 18:17:42 -0000 Received: from ifrance.com (nas22-186.vlt.club-internet.fr [195.36.172.186]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA02719 for ; Sun, 11 Feb 2001 18:16:35 +0100 (MET) Message-ID: <3A86CB64.F910CD9D@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> <3A866C48.1B7DF88@ifrance.com> <3A86B2D7.99EEDF04@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 18:27:01 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a6ce376c9e16976b88590ef41be94928 Status: R X-Status: N

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > Hello,
> > Yann Guidon a =E9crit :
> > > Then the problem is to "repair" the wrong branches= .
> > > That is : when a false branch is taken, go back to the real = destination
> >
> > You now understand the goal of predicat ;p
> the purpose of predicates is different.
> predicates don't help with delay slots.
> the problem with delay slots is that it
> changes with the architecture while SW
> doesn't evolve as well. your predicates bring
> more troubles than they solve.

So rethink of it ! Predicat was created to limit at the maximum the
bubble in the pipeline.

>
> > The instruction is validate
> > only at the far end of the pipeline. But you can simulate that by= a
> > "validate" signal at the end. It's just some more silic= ium.
> i know more or less how it works but this doesn't solve the
> jump latency problem at all ! your shameless plug failed.
> you execute more instructions than necessary and you don't
> win anything.
>
> there should be another solution.

With a big pipeline, you always have bubbles or pipeline to flush when
you jump. Predicat try to avoid the need to jump (for if clause,
mainly). Most of the time, when you want to jump, there is some "times= "
between a fetch and the instruction jump is decoded, so you have a
bubble, it's an obligation.

>
> > <...>
> > > WHYGEE
> > nicO
> WHYGEE
nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.   
=0D
=
3D""
From Carsten899@aol.com Sun Feb 11 20:47:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01182 for ; Sun, 11 Feb 2001 22:08:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 22:08:45 +0100 (MET) Received: (qmail 28084 invoked by uid 0); 11 Feb 2001 19:47:14 -0000 Received: from fh.egroups.com (208.50.144.71) by 10.1.4.111 (mx11) with SMTP; 11 Feb 2001 19:47:14 -0000 X-eGroups-Return: sentto-1101623-2364-981920833-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 11 Feb 2001 19:47:14 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 19:47:12 -0000 Received: (qmail 83630 invoked from network); 11 Feb 2001 19:47:12 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 11 Feb 2001 19:47:12 -0000 Received: from unknown (HELO imo-r09.mx.aol.com) (152.163.225.9) by mta2 with SMTP; 11 Feb 2001 19:47:12 -0000 Received: from Carsten899@aol.com by imo-r09.mx.aol.com (mail_out_v29.5.) id r.41.7434d27 (4573) for ; Sun, 11 Feb 2001 14:47:01 -0500 (EST) Message-ID: <41.7434d27.27b84635@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 14:47:01 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: c0ebd0ec31ebf19f57406ac5d59a1e41 Status: R X-Status: N validate all TLB entries which have the same 2-bit VMID handle

so i=B4ll call the 2 bits inside the page table entry "vmid_handle&quo= t; in contrast
to vmid, which is the 16 bit "original id" inside the MSR.

>>typedef struct t_vmid_table_entry {
>> t_vmid vmid;
>> int lru: LOG_VMID_CACHE_SIZE;
>>} VMID_cache[VMID_CACHE_SIZE];

>>On task switch :
>>  load MSR,
>>  extract VMID
>>  compare this VMID to each of the ones in the VMID cache.
>>    on identity : assign VMID handle =3D # of line w= hich matches
>>    on miss : assign VMID handle =3D # of line with = lowest LRU
>>  update LRU
>>  validate all TLB entries which have the same 2-bit VMID hand= le

So we have a new structure. Hows it=B4s state on RESET? I think there is th= e
need for valid bits for each VIMD-Cache Entry!? On RESET all are invalid. <= BR> Perhaps it can be done by LRU member of the VMID cache entry?

>> >>- pointer to the SYSCAL handler (base + size)
>> okay this is SR_SYSCALL_BASE and SR_SYSCALL_SIZE. Both 64 Bit?

thinking about it again - is there really a need for storing these SR=B4s i= nto
a CMB? i think, SR_SYSCALL_BASE and SR_SYSCALL_SIZE are system global set b= y
operating system. (like SR_EXCEPTION_BASE / _SIZE ) ?

>>as again : what if someone wants to play with another size ?

hes has to write a different emulator. to me all those CMB and VMIDCache an= d
other structures falling from the sky is complicated enough. lets say: if <= BR> there is really a need for the emulator, it will grow step by step. but i <= BR> have to make the first step at first.

Here is the updated definition list ( The SR list contains my
assumption/proposion about handling the ITLB, DTLB access ):

#define FCPU_MAX_REGS         =       64
#define FCPU_MAX_OPCODES        &nb= sp;   256

#define BIT( x )    ( (UL64)1 << ( x ) )

#define FCPU_LOG_NUM_TLB_ENTRIES    5
#define FCPU_NUM_TLB_ENTRIES        ( 1 = << FCPU_LOG_NUM_TLB_ENTRIES )

#define FCPU_NUM_VMID_BITS        &= nbsp; 16
#define FCPU_LOG_NUM_VMIDC_ENTRIES  2
#define FCPU_NUM_VMIDC_ENTRIES      ( 1 << F= CPU_LOG_NUM_VMIDC_ENTRIES )

#define FCPU_EXCEPTION_RESET        = ;        BIT( 0 )
#define FCPU_EXCEPTION_INTERRUPT       &= nbsp;    BIT( 1 )
#define FCPU_EXCEPTION_INVALID_INSTRUCTION  BIT( 2 )
#define FCPU_EXCEPTION_PAGEFAULT       &= nbsp;    BIT( 3 )
#define FCPU_EXCEPTION_PROTECTIONFAULT      BIT( 4= )
#define FCPU_EXCEPTION_ALIGNMENTFAULT       B= IT( 5 )
#define FCPU_EXCEPTION_DIVISION_BY_ZERO     BIT( 6 ) #define FCPU_EXCEPTION_TIMER_COUNT_ZERO     BIT( 7 )
// Exception Vectors
//
// The FCPU jumps to ( content of( FCPU_SR_EXCEPTION_BASE ) || ( vector <= ;< 6
) )
// on fault/exception/interrupt
//
#define FCPU_EXCEPTION_VECTOR_RESET      &nbs= p;          0
#define FCPU_EXCEPTION_VECTOR_INTERRUPT      =        1
#define FCPU_EXCEPTION_VECTOR_INVALID_INSTRUCTION   2
#define FCPU_EXCEPTION_VECTOR_PAGEFAULT      =        3
#define FCPU_EXCEPTION_VECTOR_PROTECTIONFAULT     =   4
#define FCPU_EXCEPTION_VECTOR_ALIGNMENTFAULT     &= nbsp;  5
#define FCPU_EXCEPTION_VECTOR_DIVISION_BY_ZERO     = ; 6
#define FCPU_EXCEPTION_VECTOR_TIMER_COUNT_ZERO     = ; 7

// FCPU Special Registers
//
// The following registers are protected. This means, that FCPU executes // an FCPU_EXCEPTION_PROTECTIONFAULT if the are written if msr.rwsr =3D 0.<= BR> //
// There are also a few bits inside of FCPU_SR_MSR which are protected.
// The FCPU executes FCPU_EXCEPTION_PROTECTIONFAULT if the user mode
application
// tries to change them.
//
#define FCPU_SR_MSR         &n= bsp;       0x0000
#define FCPU_SR_SYSCALL_BASE        0x00= 01
#define FCPU_SR_SYSCALL_LIMIT       0x0002 #define FCPU_SR_EXCEPTION_BASE      0x0003
#define FCPU_SR_EXCEPTION_LIMIT     0x0004
#define FCPU_SR_ITLB_BASE        &n= bsp;  0x1000  /* first ITLB entry. next entry
at 0x1008 [...] */
#define FCPU_SR_DTLB_BASE        &n= bsp;  0x2000  /* first DTLB entry. next entry
at 0x2008 [...] */

// VM-ID Cache Entry
typedef struct _VMIDCE {
    UL64    vmid:FCPU_NUM_VMID_BITS;
    UL64    lru:FCPU_LOG_NUM_VMIDC_ENTRIES; } VMIDCE, *PVMIDCE;

// TLB Entry
typedef struct _TLBE {
    UL64 log_addr;
    UL64 phy_addr;
    UL64 page_size;       = ;            &n= bsp; /* size of page in bytes =3D 2 ^
page_size =3D 1 << page_size */
    UL64 hit_counter;      &nb= sp;            /* in= cremented whenever the address
matches. */
    UL64 valid:1;       &= nbsp;           &nbs= p;   /* tlb entry contains valid adress
translation data */
    UL64 access_rights:2;      = ;         /* r=3D0, w=3D1, rw=3D2, = x=3D3*/
    UL64 cachable:1;      &nbs= p;             = /* if 0, don't seek in the cache */
    UL64 lru:FCPU_LOG_NUM_TLB_ENTRIES;
    UL64 vmid_handle:2;
} TLBE, *PTLBE;

// Machine Status Register
typedef struct _MSR {
    UL64    interrupt_enable:1;  &n= bsp;  /* 1 =3D IRQ enabled. 0 =3D ignore IRQ */
    UL64    itlb_enable:1;   &= nbsp;      /* 1 =3D use itlb. 0 =3D map phys to lo= g
address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT */
    UL64    dtlb_enable:1;   &= nbsp;      /* 1 =3D use dtlb. 0 =3D map phys to lo= g
address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT */
    UL64    op_size_00:4;   &n= bsp;       /* size of operand in bytes, if op= -flags
in instruction =3D 00 */
    UL64    op_size_01:4;   &n= bsp;       /* size of operand in bytes, if op= -flags
in instruction =3D 01 */
    UL64    op_size_10:4;   &n= bsp;       /* size of operand in bytes, if op= -flags
in instruction =3D 10 */
    UL64    op_size_11:4;   &n= bsp;       /* size of operand in bytes, if op= -flags
in instruction =3D 11 */
    UL64    op_size_max:4;   &= nbsp;      /* max size of operand in bytes */
    UL64    vmid:FCPU_NUM_VMID_BITS;/* VM-Ide= ntifier. writing if rwsr=3D0
causes FCPU_EXCEPTION_PROTECTIONFAULT */
    UL64    rwsr:1;    &n= bsp;            /* 1= =3D Read/Write protected SR=B4s, 0 =3D
Read only protected SR=B4s. writing if rwsr=3D0 causes
FCPU_EXCEPTION_PROTECTIONFAULT */
} MSR, *PMSR;

// CMB
typedef struct _CMB {
    UL64    instr_ptr;
    MSR     msr;
    UL64    reg[ FCPU_MAX_REGS ];
    UL64    cycle_counter;   &= nbsp;      /* counts all cycles this task executed= */
    UL64    time_slice_limit;  &nbs= p;    /* value to be loaded into
time_slice_counter on task switch */
    UL64    time_slice_counter;  &n= bsp;  /* is loaded with time_slice_limit on
task switch. */
            &nb= sp;            =            /* counting fr= om 1->0 causes
FCPU_EXCEPTION_TIMER_COUNT_ZERO exception */
    UL64    next_cmb_ptr;   &n= bsp;       /* pointer to next CMB in list */<= BR>     UL64    sr_syscall_base;
    UL64    sr_syscall_limit;
} CMB, *PCMB;

// FCPU Registers
typedef struct _FCPU {
    MSR     msr;
    UL64    exception;
    UL64    instr_ptr; 
    UL64    instr_reg;
    VMIDCE  vmidc[ FCPU_NUM_VMIDC_ENTRIES ];
    TLBE    itlb[ FCPU_NUM_TLB_ENTRIES ];
    TLBE    dtlb[ FCPU_NUM_TLB_ENTRIES ];
    UL64    reg[ FCPU_MAX_REGS ];
    // Emulator specific
    UL64    opcode;
    PXF     pxf[ FCPU_MAX_OPCODES ];
    PSF     psf[ FCPU_MAX_OPCODES ];
} FCPU, *PFCPU;


carsten
Yahoo! Groups Spons= or
3D""=
Personalize your company´s name. Choose the domain n= ame below and press SEARCH!
www.
3D"Y=
3D""
From Michael Riepe Sun Feb 11 15:50:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01194 for ; Sun, 11 Feb 2001 22:08:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 11 Feb 2001 22:08:51 +0100 (MET) Received: (qmail 10813 invoked by uid 0); 11 Feb 2001 20:46:04 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx04) with SMTP; 11 Feb 2001 20:46:04 -0000 X-eGroups-Return: sentto-1101623-2365-981923911-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 11 Feb 2001 20:38:32 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 20:38:30 -0000 Received: (qmail 3400 invoked from network); 11 Feb 2001 20:38:27 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 11 Feb 2001 20:38:27 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.109) by mta3 with SMTP; 11 Feb 2001 21:39:30 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00510; Sun, 11 Feb 2001 15:50:37 +0100 Message-ID: <20010211155037.05804@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <41.7273ccd.27b4ea90@aol.com> <3A85F626.442F9597@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A85F626.442F9597@f-cpu.org>; from Yann Guidon on Sun, Feb 11, 2001 at 03:17:10AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 15:50:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1dbef55cd6e27c351062522f757fc666 Status: R X-Status: N On Sun, Feb 11, 2001 at 03:17:10AM +0100, Yann Guidon wrote:
> hi !
> late tired answer...
>
> Carsten899@aol.com wrote:
> > typedef struct _TLBE {
> >   UL64 log_addr;
> >   UL64 phy_addr;
> >   UL64 hit_counter;             /* incremented whenever the address matches.
> > */
> >   UL32 page_size;       /* size of page in bytes = 2 ^ page_size = 1 <<
> > page_size */
> >
> >   UL32 valid:1;
> >   UL32 access_rights:2;     /* r=0, w=1, rw=2, x=3*/

Should better be 3 individual bits (r, w and x).  Maybe even 6 bits
for different permissions in user/supervisor mode (Unix-like).

> >   UL32 cachable:1;      /* if 0, don't seek in the cache */
> >   UL32 lru:FCPU_LOG_NUM_TLB_ENTRIES;
> > //  UL32 vimd:2 // whats that???
> > } TLBE, *PTLBE;

I'd prefer a more compact format -- four 64-bit words is too much.
When the CPU writes a TLB entry, it should not have to write more than
two words (that's enough for addresses, page size and flags).

[...bit fields...]
> i wonder if it is necessary to repeat UL64 in front of every field.
> The purpose of this kind of syntax is that we want to pack all the bits in
> a single word, instead of wasting a full word for each field...

Don't worry, the C compiler will pack the bit fields unless you tell
it explicitly to start a new word (by inserting a 0-bit bit field).

> > ***************
> > * CMB Structure (current. 02/09/2001)
> > ***************
> >
> > //!!!
> > //!!! CMB is supicious to change its structure
> > //!!!
> >
> > typedef _CMB {
> >     UL64    instr_ptr;
> >     MSR msr;
> >     UL64    reg[ 64 ];
> several SRs are stored here :
> - pointer to the SYSCAL handler (base + size)
> - private cycle counter
> - debug registers and event counters + counter configuration
> - "next" CMB

We also need pointers to the current and last CMB.

> - time slice limit
> - current time slice value
> and others i also forgot.
>
> > } CMB, *PCMB;

In fact, ALL writable special registers should be saved in the CMB.
The OS may want to change their user mode values, and the only way to
do this is to change them in the CMB before returning to user mode.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
From Yann Guidon Mon Feb 12 00:18:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02120 for ; Mon, 12 Feb 2001 00:30:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 00:30:45 +0100 (MET) Received: (qmail 22422 invoked by uid 0); 11 Feb 2001 23:12:42 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx24) with SMTP; 11 Feb 2001 23:12:42 -0000 X-eGroups-Return: sentto-1101623-2366-981933153-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 11 Feb 2001 23:12:37 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 23:12:32 -0000 Received: (qmail 65117 invoked from network); 11 Feb 2001 23:12:31 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 11 Feb 2001 23:12:31 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 12 Feb 2001 00:13:36 -0000 Received: from f-cpu.org (nas2-218.ras.club-internet.fr [195.36.192.218]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA16567 for ; Mon, 12 Feb 2001 00:12:29 +0100 (MET) Message-ID: <3A871DD9.50C0FBDE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> <3A866C48.1B7DF88@ifrance.com> <3A86B2D7.99EEDF04@f-cpu.org> <3A86CB64.F910CD9D@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 00:18:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 6bdfbc65e65dea3d4f6022b19bdab54d Status: R X-Status: N hi,

Nicolas Boulay wrote:
> Yann Guidon a =E9crit :
> > Nicolas Boulay wrote:
> > > Yann Guidon a =E9crit :
> > > > Then the problem is to "repair" the wrong bra= nches.
> > > > That is : when a false branch is taken, go back to the = real destination
> > > You now understand the goal of predicat ;p
> > the purpose of predicates is different.
> > predicates don't help with delay slots.
> > the problem with delay slots is that it
> > changes with the architecture while SW
> > doesn't evolve as well. your predicates bring
> > more troubles than they solve.
> So rethink of it ! Predicat was created to limit at the maximum the > bubble in the pipeline.

the problem here is to solve the cause of the bubble,
not to hide it.

> > > The instruction is validate
> > > only at the far end of the pipeline. But you can simulate th= at by a
> > > "validate" signal at the end. It's just some more = silicium.
> > i know more or less how it works but this doesn't solve the
> > jump latency problem at all ! your shameless plug failed.
> > you execute more instructions than necessary and you don't
> > win anything.
> >
> > there should be another solution.
>
> With a big pipeline, you always have bubbles or pipeline to flush when=
> you jump. Predicat try to avoid the need to jump (for if clause,
> mainly). Most of the time, when you want to jump, there is some "= times"
> between a fetch and the instruction jump is decoded, so you have a
> bubble, it's an obligation.

F-CPU has conditional moves, which have most of the effects of predicates with less code and bandwidth bloat :-)
there should also be a way to make a conditional load/store one day.


here is a small review of the techniques commonly used to help here :
- branch predictor : it's based on a history. There's no provision to
     store this history yet. static prediction ("h= ints") is already done
     in the instruction with a 2-bit field.
- branch target buffer : that's the equivalent of the Fetcher buffer.
     it can hold and cache 8 targets (today). "jum= ping" from one line
     to another is already very fast and i doubt one ca= n do faster.
- delay slots : out of question : remember the MIPS and other architecture= s
     that scaled so much that legacy SW couldn't keep u= p.

In the present case, we can't decode two instructions at once and the
cycle is lost. clean programming is absolutely necessary (and it has always=
helped).

> > > <...>
> > > > WHYGEE
> > > nicO
> > WHYGEE
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www.   
=0D
3D""
From Ben Franchuk Sun Feb 11 05:10:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02251 for ; Mon, 12 Feb 2001 01:21:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 01:21:34 +0100 (MET) Received: (qmail 9370 invoked by uid 0); 11 Feb 2001 23:51:07 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx10) with SMTP; 11 Feb 2001 23:51:07 -0000 X-eGroups-Return: sentto-1101623-2367-981935463-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 11 Feb 2001 23:51:04 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 23:51:02 -0000 Received: (qmail 70788 invoked from network); 11 Feb 2001 23:51:01 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 11 Feb 2001 23:51:01 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 11 Feb 2001 23:51:00 -0000 Received: from jetnet.ab.ca (dialin46.jetnet.ab.ca [207.153.6.46]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA28952 for ; Sun, 11 Feb 2001 16:41:43 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8610C0.7BB1915F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> <3A866C48.1B7DF88@ifrance.com> <3A86B2D7.99EEDF04@f-cpu.org> <3A86CB64.F910CD9D@ifrance.com> <3A871DD9.50C0FBDE@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Feb 2001 21:10:40 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 32dedce18eca7563c6a801bd49536a60 Status: R X-Status: N Yann Guidon wrote:

> F-CPU has conditional moves, which have most of the effects of predicates
> with less code and bandwidth bloat :-)
> there should also be a way to make a conditional load/store one day.
Here is a instruction Want-a-be.
A conditional clear register #n. You may be able to get this mostly
free if you have asynchronous reset on all your registers.
Just a random thought while I cook supper.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Mon Feb 12 01:01:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02254 for ; Mon, 12 Feb 2001 01:21:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 01:21:35 +0100 (MET) Received: (qmail 7607 invoked by uid 0); 11 Feb 2001 23:55:34 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx17) with SMTP; 11 Feb 2001 23:55:34 -0000 X-eGroups-Return: sentto-1101623-2368-981935731-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 11 Feb 2001 23:55:32 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 11 Feb 2001 23:55:30 -0000 Received: (qmail 44220 invoked from network); 11 Feb 2001 23:55:30 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 11 Feb 2001 23:55:30 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 11 Feb 2001 23:55:30 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id AC7A4450D8 for ; Sun, 11 Feb 2001 19:01:55 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <3A8610C0.7BB1915F@jetnet.ab.ca> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 19:01:55 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 83cc83ca575d61400bf54d4fc0ddb0a7 Status: R X-Status: N On Sat, 10 Feb 2001, Ben Franchuk wrote:

> Yann Guidon wrote:
>
> > F-CPU has conditional moves, which have most of the effects of predicates
> > with less code and bandwidth bloat :-)
> > there should also be a way to make a conditional load/store one day.
> Here is a instruction Want-a-be.
> A conditional clear register #n. You may be able to get this mostly
> free if you have asynchronous reset on all your registers.
> Just a random thought while I cook supper.

cmov r#, r0;

translate that to internal reset.

> Ben.
>
rares
Yahoo! Groups Sponsor

www.   
From Yann Guidon Mon Feb 12 03:20:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA02824 for ; Mon, 12 Feb 2001 03:49:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 03:49:38 +0100 (MET) Received: (qmail 9350 invoked by uid 0); 12 Feb 2001 02:13:59 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx13) with SMTP; 12 Feb 2001 02:13:59 -0000 X-eGroups-Return: sentto-1101623-2369-981944035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 12 Feb 2001 02:13:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 02:13:55 -0000 Received: (qmail 39517 invoked from network); 12 Feb 2001 02:13:54 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Feb 2001 02:13:54 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta2 with SMTP; 12 Feb 2001 02:13:53 -0000 Received: from f-cpu.org (nas3-41.ras.club-internet.fr [195.36.203.41]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA01952 for ; Mon, 12 Feb 2001 03:13:48 +0100 (MET) Message-ID: <3A874863.206C60A4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <41.7434d27.27b84635@aol.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 03:20:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] (i) VF-CPU : structures + defines Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 2acd99362fef51360c308ebdc448c72d Status: R X-Status: N hi again !

Carsten899@aol.com wrote:
> > validate all TLB entries which have the same 2-bit VMID handle > so i=B4ll call the 2 bits inside the page table entry "vmid_handl= e" in contrast
> to vmid, which is the 16 bit "original id" inside the MSR. i finally found the right way to explain it :-)

> >>typedef struct t_vmid_table_entry {
> >> t_vmid vmid;
> >> int lru: LOG_VMID_CACHE_SIZE;
> >>} VMID_cache[VMID_CACHE_SIZE];
>
> >>On task switch :
> >>  load MSR,
> >>  extract VMID
> >>  compare this VMID to each of the ones in the VMID cache= .
> >>    on identity : assign VMID handle =3D # of l= ine which matches
> >>    on miss : assign VMID handle =3D # of line = with lowest LRU
> >>  update LRU
> >>  validate all TLB entries which have the same 2-bit VMID= handle
>
> So we have a new structure. Hows it=B4s state on RESET?
empty, of course, and bypassed anyway in kernel mode.

> I think there is the
> need for valid bits for each VIMD-Cache Entry!? On RESET all are inval= id.
> Perhaps it can be done by LRU member of the VMID cache entry?
it's obvious that there is an invalid bit but i don't get how you do it wit= h LRU.

> >> >>- pointer to the SYSCAL handler (base + size)
> >> okay this is SR_SYSCALL_BASE and SR_SYSCALL_SIZE. Both 64 Bit= ?
> thinking about it again - is there really a need for storing these SR= =B4s into
> a CMB? i think, SR_SYSCALL_BASE and SR_SYSCALL_SIZE are system global = set by
> operating system. (like SR_EXCEPTION_BASE / _SIZE ) ?

one of the best use of syscall is library calls, so the table
can be reconstructed each time a new service is desired. this varies from task to task so it is best kept in the CMB.

OTOH traps and IRQs are global and need not be stored in the CMB.

> >>as again : what if someone wants to play with another size ? >
> hes has to write a different emulator. to me all those CMB and VMIDCac= he and
> other structures falling from the sky is complicated enough. lets say:= if
> there is really a need for the emulator, it will grow step by step. bu= t i
> have to make the first step at first.

ok, let's say that it's a first "working" attempt :-)
it's less interesting to play with it but it's better than the
nothing that existed before :-)

> Here is the updated definition list ( The SR list contains my
> assumption/proposion about handling the ITLB, DTLB access ):
<...>
> #define FCPU_EXCEPTION_RESET       =          BIT( 0 )
> #define FCPU_EXCEPTION_INTERRUPT      &n= bsp;     BIT( 1 )
not needed : there is a separate table for IRQs.

BTW we'll have to decide about the exact glossary :
do we say "trap" or "exception" ? i started to write &q= uot;trap"
(5 letters shorter :-P) in the existing files, but i never cared
to make a distinction.

> #define FCPU_EXCEPTION_INVALID_INSTRUCTION  BIT( 2 )
> #define FCPU_EXCEPTION_PAGEFAULT      &n= bsp;     BIT( 3 )
> #define FCPU_EXCEPTION_PROTECTIONFAULT      B= IT( 4 )
> #define FCPU_EXCEPTION_ALIGNMENTFAULT     &nb= sp; BIT( 5 )
> #define FCPU_EXCEPTION_DIVISION_BY_ZERO     BIT( 6= )
> #define FCPU_EXCEPTION_TIMER_COUNT_ZERO     BIT( 7= )

on top of that : i found an entry that was missing :-)
#define FCPU_EXCEPTION_DEBUG     BIT( 8 )

> // FCPU Special Registers
> //
> // The following registers are protected. This means, that FCPU execut= es
> // an FCPU_EXCEPTION_PROTECTIONFAULT if the are written if msr.rwsr = =3D 0.
> //
> // There are also a few bits inside of FCPU_SR_MSR which are protected= .
> // The FCPU executes FCPU_EXCEPTION_PROTECTIONFAULT if the user mode > application
> // tries to change them.
> //
> #define FCPU_SR_MSR        &nb= sp;        0x0000
> #define FCPU_SR_SYSCALL_BASE       = 0x0001
> #define FCPU_SR_SYSCALL_LIMIT       0x00= 02
> #define FCPU_SR_EXCEPTION_BASE      0x0003 > #define FCPU_SR_EXCEPTION_LIMIT     0x0004
> #define FCPU_SR_ITLB_BASE       &nb= sp;   0x1000  /* first ITLB entry. next entry
> at 0x1008 [...] */
> #define FCPU_SR_DTLB_BASE       &nb= sp;   0x2000  /* first DTLB entry. next entry
> at 0x2008 [...] */
>

the VHDL file defined something different.
first, the MSR is not accessible through the SR.
it is a "compressed" form for several task-specific features.
OTOH the SRs contain the current state of the CPU as well as
hardwired registers that give informations about the implementation.

Extract from the file f-cpu_config.vhdl :
i guess that you can figure out the meaning of the code, it's the equivalen= t of
the #defines.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- number of SRs that are implemented in this model
  constant SR_NUMBERS      : natural :=3D 0;<= BR>   constant SR_NUMBERS_val  : natural :=3D SR_LAST_SR;
* this line says that the SR #0 gives the number of implemented
SRs in the machine. It also helps to know the SR "map".

-- F-CPU core number. remark : 0xFC0 =3D 4032d :-)
  constant SR_FAMILY       : natural := =3D 1;
  constant SR_FAMILY_val   : natural :=3D 4032;
* this must be changed for the emulator.

-- revision/implementation
  constant SR_STEPPING     : natural :=3D 2;
  constant SR_STEPPING_val : natural :=3D 1;
* ok : emulator rev.=3D1

-- in bytes, a power of two >=3D 4
  constant SR_MAX_SIZE     : natural :=3D 3;
  constant SR_MAX_SIZE_val : natural :=3D MAXSIZE;
* in our case : set to 8 (8*8=3D64bits)

-- Size attribute 1, hardwired if SR_MAX_SIZE <=3D 8
  constant SR_SIZE_1       : natural := =3D 4;
  constant SR_SIZE_1_val   : natural :=3D 1;

-- Size attribute 2, hardwired if SR_MAX_SIZE <=3D 8
  constant SR_SIZE_2       : natural := =3D 5;
  constant SR_SIZE_2_val   : natural :=3D 2;

-- Size attribute 3, hardwired if SR_MAX_SIZE <=3D 8
  constant SR_SIZE_3       : natural := =3D 6;
  constant SR_SIZE_3_val   : natural :=3D 4;

-- Size attribute 4, hardwired if SR_MAX_SIZE <=3D 8
  constant SR_SIZE_4       : natural := =3D 7;
  constant SR_SIZE_4_val   : natural :=3D 8;
*nothing funky here.

-- SIMD chunck size, hardwired.
  constant SR_MAX_CHUNK_SIZE       : nat= ural :=3D 8;
  constant SR_MAX_CHUNK_SIZE_val   : natural :=3D MAX_CHUNK_= SIZE*8;
*in our case : it's 8 bytes.

-- R/W, Value is dynamic, incremented every cycle.
  constant SR_CYCLE        : natura= l :=3D 9;
* you figured it yourself.

-- Protected, R/W, Controls the paged memory.
  constant SR_PAGING       : natural := =3D 10;
* if the LSB is set, the TLB is in service.

-- IRQ, TRAP and SYSCALL jump tables : all are R/W in protected mode - only= .
  constant SR_IRQ_BASE     : natural :=3D 11; = ; -- For the hardware interrupt requests
  constant SR_IRQ_SIZE     : natural :=3D 12;
  constant SR_TRAP_BASE    : natural :=3D 13;  -- = faults and system errors
  constant SR_TRAP_SIZE    : natural :=3D 14;
  constant SR_SYSCALL_BASE : natural :=3D 15;  -- OS system call<= BR>   constant SR_SYSCALL_SIZE : natural :=3D 16;
  constant SR_TLBMISS_BASE : natural :=3D 17;  -- TLB miss trap * Since TLB misses occur most often, it is good practice to separate the ha= ndler
>from the others. this conflicts a bit with Carsten's previous definition ho= wever.

-- The URL registers must be modified to point to the manual, sources, patc= hes etc.
-- The registers are hardwired, format is ASCII and padded with 0s.
  constant SR_URL         = ; : natural :=3D 18;
-- 64 characters max. for a 64-bit version, 32 chars for a 32-bit version..= .
  constant SR_URL_size     : natural :=3D 8;
  constant SR_URL_val      : string :=3D &quo= t;http://www.f-cpu.de/design/&q= uot;;
* in this case, the url is different : "http://www.f-cpu.de/emu/"

-- last SR :
  constant SR_LAST_SR      : natural :=3D 26;=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

this gives :

#define MAXSIZE 8

/* number of SRs that are implemented in this model */
#define FCPU_SR_NUMBERS       0
#define FCPU_SR_NUMBERS_val   SR_LAST_SR  /* hardwired */ #define FCPU_SR_FAMILY        1
#define FCPU_SR_FAMILY_val    0x454D554C41544F52 /* "EM= ULATOR" (big endian, hardwired) */
#define FCPU_SR_STEPPING      2
#define FCPU_SR_STEPPING_val  1  /* hardwired */
#define FCPU_SR_MAX_SIZE      3
#define FCPU_SR_MAX_SIZE_val  MAXSIZE  /* hardwired */
#define FCPU_SR_SIZE_1        4
#define FCPU_SR_SIZE_1_val    1 /* R/W */
#define FCPU_SR_SIZE_2        5
#define FCPU_SR_SIZE_2_val    2 /* R/W */
#define FCPU_SR_SIZE_3        6
#define FCPU_SR_SIZE_3_val    4 /* R/W */
#define FCPU_SR_SIZE_4        7
#define FCPU_SR_SIZE_4_val    8 /* R/W */
#define FCPU_SR_MAX_CHUNK_SIZE       8
#define FCPU_SR_MAX_CHUNK_SIZE_val   8 /* hardwired */
#define FCPU_SR_CYCLE         9 /* = R/W, Value is dynamic, incremented every cycle. */
#define FCPU_SR_PAGING        10 /* Prot= ected, R/W, Controls the paged memory. */
/* IRQ, TRAP and SYSCALL jump tables : all are R/W in protected mode - only= . */
#define FCPU_SR_IRQ_BASE      11 /* For the hardwa= re interrupt requests */
#define FCPU_SR_IRQ_SIZE      12
#define FCPU_SR_TRAP_BASE     13 /* faults and system e= rrors */
#define FCPU_SR_TRAP_SIZE     14
#define FCPU_SR_SYSCALL_BASE  15 /* OS system call */
#define FCPU_SR_SYSCALL_SIZE  16
#define FCPU_SR_TLBMISS_BASE  17 /* TLB miss trap */

/* The 8 URL registers must be modified to point to the manual, sources, pa= tches etc.
   64 characters max. for a 64-bit version, 32 chars for a 32-bit= version...
   These registers are hardwired, format is ASCII and padded with= 0s. */
#define FCPU_SR_URL         &n= bsp; 18
#define FCPU_SR_URL_size      8
#define FCPU_SR_URL_val       "http://www.f-cpu.de/emu/" /* or wher= ever your version is located */

/* these ones are freshly added : */
#define FCPU_SR_TIME_SLICE_COUNTER  26
#define FCPU_SR_TIME_SLICE_LIMIT    27
#define FCPU_SR_NEXT_CMB        &nb= sp;   28
#define FCPU_SR_EVENT_COUNTER_0_CFG 29
#define FCPU_SR_EVENT_COUNTER_0     30
#define FCPU_SR_EVENT_COUNTER_1_CFG 31
#define FCPU_SR_EVENT_COUNTER_1     32
#define FCPU_SR_EVENT_COUNTER_2_CFG 33
#define FCPU_SR_EVENT_COUNTER_2     34
#define FCPU_SR_EVENT_COUNTER_3_CFG 35
#define FCPU_SR_EVENT_COUNTER_3     36
#define FCPU_SR_EVENT_COUNTER_4_CFG 37
#define FCPU_SR_EVENT_COUNTER_4     38
#define FCPU_SR_EVENT_COUNTER_5_CFG 39
#define FCPU_SR_EVENT_COUNTER_5     40
#define FCPU_SR_EVENT_COUNTER_6_CFG 41
#define FCPU_SR_EVENT_COUNTER_6     42
#define FCPU_SR_EVENT_COUNTER_7_CFG 43
#define FCPU_SR_EVENT_COUNTER_7     44

#define FCPU_SR_LAST_SR       44


> // TLB Entry
> typedef struct _TLBE {
>     UL64 log_addr;
>     UL64 phy_addr;
>     UL64 page_size;     &= nbsp;           &nbs= p;   /* size of page in bytes =3D 2 ^
> page_size =3D 1 << page_size */
>     UL64 hit_counter;     = ;            &n= bsp; /* incremented whenever the address
> matches. */

something useful would be to add 8 subfields so we can analyse the
real use of the page. we would have something like UL16 hitcount[8],
but i guess that it takes some room.... let's keep it for another version..= .

> // Machine Status Register
> typedef struct _MSR {
>     UL64    interrupt_enable:1;&nbs= p;    /* 1 =3D IRQ enabled. 0 =3D ignore IRQ */
however, traps and timeslice_elapsed (and similar internal events)
are still possible.

this bit can be set only if rwsr=3D1

>     UL64    itlb_enable:1; &nb= sp;        /* 1 =3D use itlb. 0 =3D map = phys to log
> address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT */<= BR> >     UL64    dtlb_enable:1; &nb= sp;        /* 1 =3D use dtlb. 0 =3D map = phys to log
> address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT */<= BR>
i wonder why i and d tlb enables are separated. it has no logical meaning for me.

>     UL64    op_size_00:4; &nbs= p;         /* size of operand in by= tes, if op-flags
> in instruction =3D 00 */
>     UL64    op_size_01:4; &nbs= p;         /* size of operand in by= tes, if op-flags
> in instruction =3D 01 */
>     UL64    op_size_10:4; &nbs= p;         /* size of operand in by= tes, if op-flags
> in instruction =3D 10 */
>     UL64    op_size_11:4; &nbs= p;         /* size of operand in by= tes, if op-flags
> in instruction =3D 11 */

encoding : 0000 : 8 bits
           0001 : 16 bits=
           0010 : 32 bits=
           0011 : 64 bits=
           0100 : 128 bit= s etc. ...

>     UL64    op_size_max:4; &nb= sp;        /* max size of operand in byt= es */
no, this is hardwired and depends on the platform.
here you mixed with the SRs.

> // CMB
> typedef struct _CMB {
<..>
> } CMB, *PCMB;

looks rather good :-)
however it is only a first version.
the further versions will be discerned
with the help of a set of hardwired special registers.

> // FCPU Registers
> typedef struct _FCPU {
>     MSR     msr;
>     UL64    exception;
?

>     TLBE    itlb[ FCPU_NUM_TLB_ENTR= IES ];
>     TLBE    dtlb[ FCPU_NUM_TLB_ENTR= IES ];
no need of separate tables, we have the r/w/rw/x flag in the entries.

it's really cool to see the emulator slowly emerging :-)
ok this coming week will be very heavy. good luck everyone !

> carsten
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"Click
3D""
From Nicolas Matringe Mon Feb 12 09:38:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00306 for ; Mon, 12 Feb 2001 15:34:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 15:34:56 +0100 (MET) Received: (qmail 14102 invoked by uid 0); 12 Feb 2001 08:36:38 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx07) with SMTP; 12 Feb 2001 08:36:38 -0000 X-eGroups-Return: sentto-1101623-2370-981966993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 12 Feb 2001 08:36:35 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 08:36:32 -0000 Received: (qmail 71365 invoked from network); 12 Feb 2001 08:36:32 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Feb 2001 08:36:32 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 12 Feb 2001 08:36:32 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA10267 for ; Mon, 12 Feb 2001 08:36:30 GMT X-To: Message-ID: <3A87A101.3C99B0D5@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 09:38:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ff416ecf4b1ba56d5224c0fc8ca8c81 Status: R X-Status: N Nicolas Boulay wrote:
>
> Funny ;p I have read (in Electronics International, a famous
> french professional electronics newspaper) that a compagny would
> produice 25 000 chips and the guy from the foundry answer that
> he didn't move under 500 000 chips... So, you're funny...

Ever heard of CMP? Go and have a look there http://cmp.imag.fr/
(Thanks to YG for telling me about it more than 1 year ago)

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor

www.

From Hans Summers Mon Feb 12 10:20:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00310 for ; Mon, 12 Feb 2001 15:34:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 15:34:57 +0100 (MET) Received: (qmail 11265 invoked by uid 0); 12 Feb 2001 09:20:25 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx15) with SMTP; 12 Feb 2001 09:20:25 -0000 X-eGroups-Return: sentto-1101623-2371-981969622-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 12 Feb 2001 09:20:23 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 09:20:22 -0000 Received: (qmail 68301 invoked from network); 12 Feb 2001 09:20:22 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 12 Feb 2001 09:20:22 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 12 Feb 2001 09:20:21 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA12916 for ; Mon, 12 Feb 2001 04:18:12 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA16706 for ; Mon, 12 Feb 2001 04:20:20 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Feb 2001 09:20:20 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EA68@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 09:20:10 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 85c25828733c889829bfc09a102f8b2b Status: R X-Status: N
> -----Original Message-----
> From: Michael Riepe [mailto:michael@stud.uni-hannover.de]
> Sent: 09 February 2001 13:41
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> On Fri, Feb 09, 2001 at 11:48:13AM -0000, Hans Summers wrote:
> > [...]
> > How about the first few bits of the opcode specifying the
> > EU which would be
> > used to process it. Then instruction decode simply becomes
> > a matter of
> > decoding those binary bits. Perhaps not even that: just
> > send the whole
> > opcode to ALL the EU's, and let them perform a comparison of the
> > EU-specifying opcode bits with their own hardwired EU
> > number, and ignore anything that doesn't match?
>
> Put the decoder into the EUs?  Distributed associative
> read-only memory?

Why not? (though I'm not sure about the posh name for it). Seems to me that
the more EU-specific tasks that can be performed inside the EU itself, the
better. This modularity helps development since the EU designer has control
over everything which affects his EU.


>
> [...]
> > Now this is interesting. So, gated clocks are not well
> > liked because of implementation difficulties (rather, safe synchronous
> > "enabled" clocks).
>
> How exactly will you implement them?  I'm particularly interested in
> the `safe' part...

By "safe", I mean it is very easy to imagine a simple AND gate on the clock
line. But that isn't a "safe" method, since changes in state of the enable
input can only occur while the clock input is low, otherwise spikes will be
caused. This creates dangerous timing hazards. A "safe" method must ensure
that only the positive-going edge of the clock is propagated, the enable
input can change at any time as long as it is valid at the time of the
positive edge of the clock (and presumably a little before so everything is
stable).

>
> > Your use of a MUX to circumvent this difficulty is merely a
> > matterr of implementation. The effect is to stall the pipeline: in
> > your case you stop
> > the current data by reapplying it to the same FF. The
> > result is the same as
> > if you had stalled the pipeline by not applying the clock
> > signal. This is a
> > matter of implementation. What are the non-dirty workarounds?
>
> A mux will affect the CDP, and is way too heavy -- some pipeline
> registers are much wider than the operand size (expecially in the
> multiplier).  So, again: how can you enable/disable the clock safely
> without affecting the CDP (and without using too much area)?

I am not thinking at the transistor level here. I agree my proposal depends
on stalling the data pipeline, which depends on gating the clock in a safe
synchronous way, and is in the CDP. Can this be done or not, and how? I
don't know. You can imagine how it can be done using a large number of
discrete gates, but we need something compact and fast. At the transistor
level it may be possible, but can't speculate on this.


>
> [...]
> > I believe it IS the same. When you predict a write hazard,
> > you wait until it
> > clears before issueing. I don't check and issue regardless.
> > I then check at
> > the end, and if I detect a hazard I wait then. The amount
> > of waiting for the hazard to clear is identical, as long as
> > 1) the order of instruction issue is the same (it is,
> > neither of us are OOO)
> > 2) the order of completion is also the same (it is, I said
> > I'd prioritise
> > long latency EU's which gives that result)
> > 3) latency of EU's is the same (it is, I temporarily
> > abandoned my fun
> > variable latency ideas).
> > Where is the flaw?
>
> - we need to stall the pipelines (not just the IF/ID unit)
> - we need a fast priority encoder / decision logic

Assuming pipeline stalling (equivalently bubble insertion) can be done in
the CDP pipelines, the priority encoder is similar to that proposed in the
manual for the SRB, to decide which of the 64 registers to backup first.
That encoder has to decide on the basis of several inputs, i.e. the "dirty"
flag, and "Express Request" bit. My encoder has less inputs. AFAIK the SRB
decision stage is supposed to take place in one cycle. Is this correct? If
so, the decision logic for result register write should also easily fit in
one cycle.


>
> [...]
> > I see how your bubbles work, the data load returning etc.
> > (previous posting
> > that I did not bother to copy all of here). My pipelines are indeed
> > impossible without gated clock, this is crucial to the whole idea. I
> > emphasis again, not simple AND-gated clock, but a
> > synchronous clock enable.
> > If this is indeed a tricky thing to implement in reality on
> > actual silicon,
> > then your workaround e.g. the current/previous FF MUX at
> > the input to each
> > stage, effects the same result. Whether you use an enabled
> > clock or a MUX,
> > you acheive the same thing: stalling of the EU pipeline.
> > The implementation doesn't change the principle.
>
> See above -- a mux takes too much area, and increases the
> stages' delay, while bubbles cost nothing (in terms of silicon
> real estate, or delay).

Creating the bubble is the same as stalling the pipeline, it's just a
different way of implementing the same result. The cost in silicon area and
delay is the same. The difference is that stalling/bubbling the scheduler
FIFO pipeline is not in the CDP, (presumably) whereas the EU pipelines are
in the CDP.

>
> I really like clean, modular designs like yours (some of the ideas
> sound quite familiar ;), but they must be easy to implement, too.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor

www.   
From Hans Summers Mon Feb 12 10:24:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00313 for ; Mon, 12 Feb 2001 15:34:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 15:34:58 +0100 (MET) Received: (qmail 23954 invoked by uid 0); 12 Feb 2001 09:24:55 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx13) with SMTP; 12 Feb 2001 09:24:55 -0000 X-eGroups-Return: sentto-1101623-2372-981969893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 12 Feb 2001 09:24:53 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 09:24:52 -0000 Received: (qmail 95880 invoked from network); 12 Feb 2001 09:24:52 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 12 Feb 2001 09:24:52 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta3 with SMTP; 12 Feb 2001 10:25:57 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA13065 for ; Mon, 12 Feb 2001 04:22:42 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA16823 for ; Mon, 12 Feb 2001 04:24:51 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Feb 2001 09:24:50 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EA69@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 09:24:43 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6af8dd1169f184e09e6cab1972c1f60d Status: R X-Status: N
Hello

> -----Original Message-----
> From: Ben Franchuk [mailto:bfranchuk@jetnet.ab.ca]
> Sent: 09 February 2001 21:59
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Scheduler Proposal
>
>
> Nicolas Boulay wrote:
> >
>
> > Funny ;p I have read (in Electronics International, a famous french
> > professional electronics newspaper) that a compagny would
> > produice 25 000 chips and the guy from the foundry answer that he
> > didn't move under 500 000 chips... So, you're funny...
>
> Quick Sell 499 999 more chips.
> Here is the supplier I was thinking of.
> http://www.mosis.org/Aboutmosis/menu-aboutmosis.html
> 
> > PS.Saving few 100 milliseconds at the power up, that's a big deal ;p
>
> No. I don't like EPROMS going brain dead after 10 years.
> The first computer I used was a PDP-8 -- Core memory and switches --.
> It breaks you can fix it.Barring things like bad filter caps
> and corroded
> connections; you power it up 30 years later and it still works. While
> I don't expect people to go back to paper tape I don't like this
> Throw away computer market we are in today.

Agreed. I want any computer I build to last more than 10 years. Chances are
I'll still be building/extending the damn thing in 10 years time anyway.
However, I am not sure the EPROM problem is insurmountable. I use EEPROM
(electrically erasable) so that I can more easily rewrite the ROM when
making changes. I am not certain if modern EEPROM's are as forgetful, but my
understanding is that even the old EPROM's didn't go "brain dead", they just
"forgot". So, couldn't they just be reprogrammed every few years and last
for much much longer? If EEPROM's are used then this can even take place in
system, by running a certain reminder program every year or two.

> Ben.
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers"
> http://www.jetnet.ab.ca/users/bfranchuk
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor

www.  
From Yann GUIDON Mon Feb 12 11:28:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00325 for ; Mon, 12 Feb 2001 15:35:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 15:35:01 +0100 (MET) Received: (qmail 16990 invoked by uid 0); 12 Feb 2001 10:35:40 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx16) with SMTP; 12 Feb 2001 10:35:40 -0000 X-eGroups-Return: sentto-1101623-2373-981974137-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 12 Feb 2001 10:35:38 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 10:35:37 -0000 Received: (qmail 72035 invoked from network); 12 Feb 2001 10:35:36 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 12 Feb 2001 10:35:36 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 12 Feb 2001 10:35:36 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA02644; Mon, 12 Feb 2001 02:35:33 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWXZB; Mon, 12 Feb 2001 10:40:35 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A87BAEB.49DB1229@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 11:28:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 2e09ba08718eca0e62e5e0b363555e7a Status: R X-Status: N Nicolas Matringe wrote:
> Nicolas Boulay wrote:
> > Funny ;p I have read (in Electronics International, a famous
> > french professional electronics newspaper)
wow, you read that, too ? :-)
> > that a compagny would
> > produice 25 000 chips and the guy from the foundry answer that
> > he didn't move under 500 000 chips... So, you're funny...
looks like you didn't read the whole article : they speak about
Mosis, SMP and Europractice :-P

> Ever heard of CMP? Go and have a look there http://cmp.imag.fr/
> (Thanks to YG for telling me about it more than 1 year ago)
in return, thanks for the logo :-) I hope that you like the
raytraced pictures i made for the slides, located at
http://www.f-cpu.de/epf2001/epf-slide00.html ? :-)
i have redrawn them this week-end and added a few stuffs.

> Nicolas MATRINGE
YG

speaking for himself
Yahoo! Groups Sponsor
www.
From Nicolas Matringe Mon Feb 12 11:47:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00328 for ; Mon, 12 Feb 2001 15:35:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 15:35:02 +0100 (MET) Received: (qmail 30328 invoked by uid 0); 12 Feb 2001 10:45:46 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx13) with SMTP; 12 Feb 2001 10:45:46 -0000 X-eGroups-Return: sentto-1101623-2374-981974744-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 12 Feb 2001 10:45:45 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 10:45:44 -0000 Received: (qmail 25912 invoked from network); 12 Feb 2001 10:45:44 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 12 Feb 2001 10:45:44 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 12 Feb 2001 10:45:43 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id KAA12795 for ; Mon, 12 Feb 2001 10:45:42 GMT X-To: Message-ID: <3A87BF49.E3747355@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> <3A87BAEB.49DB1229@mentor.com> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 11:47:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6cff2ddd91936da0c711861566be51e1 Status: R X-Status: N Yann GUIDON wrote:

> > (Thanks to YG for telling me about it more than 1 year ago)
> in return, thanks for the logo :-)

That'll be my only participation in the F-CPU adventure I'm afraid. I
really don't know a thing about uP design.
About CMP, we (my company) might work with them. I went to their annual
users' meeting 3 weeks ago, it was very interesting.


> I hope that you like the raytraced pictures i made for the
> slides, located at http://www.f-cpu.de/epf2001/epf-slide00.html
> ? :-) i have redrawn them this week-end and added a few stuffs.

I haven't looked yet but I won't wait any longer ;o)


--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Ben Franchuk Sun Feb 11 11:50:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00311 for ; Mon, 12 Feb 2001 22:33:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 22:33:18 +0100 (MET) Received: (qmail 28662 invoked by uid 0); 12 Feb 2001 15:33:54 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx02) with SMTP; 12 Feb 2001 15:33:54 -0000 X-eGroups-Return: sentto-1101623-2375-981992033-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 12 Feb 2001 15:33:54 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 15:33:52 -0000 Received: (qmail 49339 invoked from network); 12 Feb 2001 15:33:52 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 12 Feb 2001 15:33:52 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 12 Feb 2001 16:34:56 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA28090 for ; Mon, 12 Feb 2001 08:24:33 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A866E8B.D7D07632@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 03:50:51 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] raytraced slides. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4861900958b7359203c07bbee3c0a8de Status: R X-Status: N The page is taking too long to load - about 10 minutes for it load with
my 28k modem. I have done this email before it loads and type slow.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.   
From Yann GUIDON Mon Feb 12 16:56:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00323 for ; Mon, 12 Feb 2001 22:33:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 22:33:20 +0100 (MET) Received: (qmail 32253 invoked by uid 0); 12 Feb 2001 16:02:45 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx05) with SMTP; 12 Feb 2001 16:02:45 -0000 X-eGroups-Return: sentto-1101623-2376-981993760-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 12 Feb 2001 16:02:42 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 16:02:40 -0000 Received: (qmail 72706 invoked from network); 12 Feb 2001 16:02:39 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Feb 2001 16:02:39 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 12 Feb 2001 17:03:44 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA11002; Mon, 12 Feb 2001 08:02:35 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DQDXWY2W; Mon, 12 Feb 2001 16:07:39 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A880792.742D4757@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A866E8B.D7D07632@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 16:56:03 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] raytraced slides. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 1a6dce2fe721fa4f0dd221423de46950 Status: R X-Status: N hi !

Ben Franchuk wrote:
> The page is taking too long to load - about 10 minutes for it load with
> my 28k modem. I have done this email before it loads and type slow.

yeah, i know, i'm a freak, it took 10 min. to upload it with my own 28K modem.
However it is meant to be used "locally" with all the files on the HDD.
And i won't speak about the time it took to find the correct light parameters
and compute that stuff :-)

however the following slides are faster to d/l. i use the same bg for the rest.
thank you for trying anyway :-)

> Ben.
YG

speaking for himself
Yahoo! Groups Sponsor

www.

From Ben Franchuk Sun Feb 11 12:25:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00326 for ; Mon, 12 Feb 2001 22:33:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 22:33:21 +0100 (MET) Received: (qmail 10860 invoked by uid 0); 12 Feb 2001 16:08:24 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx13) with SMTP; 12 Feb 2001 16:08:23 -0000 X-eGroups-Return: sentto-1101623-2377-981994101-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 12 Feb 2001 16:08:22 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 16:08:21 -0000 Received: (qmail 87091 invoked from network); 12 Feb 2001 16:08:20 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 12 Feb 2001 16:08:20 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 12 Feb 2001 16:08:16 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA29698 for ; Mon, 12 Feb 2001 08:58:39 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A867693.2E226F3C@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A866E8B.D7D07632@jetnet.ab.ca> <3A880792.742D4757@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 04:25:07 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] raytraced slides. Content-Type: multipart/mixed; boundary="------------69FADC9DE151F968E8097F86" X-UIDL: 0851ce0d04bb6e3cc577c0502677e003 Status: R X-Status: N --------------69FADC9DE151F968E8097F86 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Yann GUIDON wrote:
>
> hi !
>
> Ben Franchuk wrote:
> > The page is taking too long to load - about 10 minutes for it load with
> > my 28k modem. I have done this email before it loads and type slow.
>
> yeah, i know, i'm a freak, it took 10 min. to upload it with my own 28K modem.
> However it is meant to be used "locally" with all the files on the HDD.
> And i won't speak about the time it took to find the correct light parameters
> and compute that stuff :-)

Well here is a smaller background for use with web pages.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.  
--------------69FADC9DE151F968E8097F86 Content-Type: image/jpeg; name="l5.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="l5.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD//gBZQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAgUmV2 OiAxMi8yOS85NCAoUE5HIHBhdGNoIDEuMikgIFF1YWxpdHkgPSA3NSwgU21vb3RoaW5nID0g MTgK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3 KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgB4AKAAwEiAAIRAQMRAf/E AB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQEC AwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4 OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8A8LooooAKKKKACiiigAooooAKKKKACiigAnoM0AFFSJC7EcYHvUsdupzk 96TkkOxWAz0qQQvnBG361ZVAmDgKQOnrTjlkAYZXt25qHPsOxAlsCuSc+1SCMIcoCD7U7BIx yD6UoBBwT19eaTkwsPCswJ7c59ajJO4dcnr6UpJLY6DoeetBwG4BHHrUjAbs529vwpxJYDGB k54pGBxtKj8elGQGPTPrQA0DcD2HOSB1FN2lS2Nw47DrTycLzgg9xTSMjpgHnmmIcGC9yMet NKlju43AU4jAwTk4/SgkgjmgYfeBHPB9aUAZIY4x/P8ArTT94kcA9c04ctnGR7UgEI5w3Ppz gGkKgLwueOpOaU5PIHtzSKSOMjPU4FMBTuJOCADz1o6jORgDgdaQAEHI69RSsABjHzD9PSkA pOWZhuxSBCT9fXmkAO046DtmlbPUjGKAF53HJz6nPWmk7T6jHpRjYo+XPuKATk8EDPTNMQhy 2DTiS2dvAPXPelwvXpnjNRoSM4yp9KAH8A4x+JoIABUfpRs6YHJpAAGBGQ3qBQMUkBRkEjGK TkEMTgjjOf0pCxGN2Dn1oGCehAFAhxwPusM9DTTnJ5P9BS5xjBH0IpO4Iz+dAByAM4wvY04n cCuCBntxSHBxnNGQB1zxxQAhI5wT+WaAwJLDil9RwD1HBoACDqSP5UAHzN7kd+9GMNzg+g4w aQAAADueeaRWAOGJx780AO27QRg+vNNHB6kdjzSscr93JHTjrS5O35efX2oAQYXO3OO9IuQM kEHvg4pT8w+bnA9KaFPfp2FMBwzgNnmlOQeSc/1pAMDJ6+wobkjaMnvikApJDH5jntzTAMNz +HWlO30pQF5/XNMBOM4z83egEsxPPSlHAIIyM9aTIH0J/GgBRjd75zkUgPLHg55JxR6gnHsT TsgDII47ikA08rwOAen+FJvz65FO3dTu+lGWJ+XjjOKYCYwQO/1zSFdo4GT7UnQ9QeM8UoYl O+T6UAGAfUYOeKCT3JwKUNzgFsHHNIBz69uO/vQArIOMZOaQfeA4z6UvI5AO4+lGRkZXI9jQ AxkjJ+70pPs8Z5A4z61Jg9sUdjt4zxx3ouBC1sv+0KYLYk4DVPkk4I5PXinYPGCc/pTuxFX7 M+Tgg4pDbyeg/OrZG0ex4oxluM9MkU+ZhYotGy9RTavnoQB9MUjKpOMZNHMFijRVkxITwCT6 Cm+TkkCquhDKKKKYBRRRQAUUUUAFFKAScCpUt2LDflQenvSbSAhp6xO/QcVaEKIOoB7EingF cBsgdOBUOfYdiD7OqZLktj0qUALkKu0Y7d6eqADk8mm4JwMYXqKm9x2FKnBIOTjk+tMAaMgg kD0HSnnjcQMHqBmmqCVySwx6UDHc9x849ulBA4baOT1Hb8aRiRIGVcjHPBo44LHrzgCkAoUn kgccZ9KQnP8AFnnnn9KDyxLZ2+uaNx2nb0HO4daAEJK5bt79KBt4zjFP6gBd35UmNxOGzjnp QA0Eg5ByT+lKvrnIH4gUAkEYAJJ+lL8q5Q5IB5zTATBYHJGP4uOtOKAYUMMEdqYRhsjpnIp3 GRjOKQAATkg7iOtMPDbhk9KdxkEjAJ79qPXYSf5UALg5JHX0x0pCQ+M/Lnn6fWhlY8jPXkil CnYVzkH1oATcM4HGPbr70oKtk5PcEYoDEMAW4PoKQg7ieuOQTQAq5Y/LkHHIx1pnBJBUDPQG nfeUckYPc0hyyDnp19/xpgLk9SCQDxxSEbmOSOnOaUYVuvA96TPTcTg88jigBMEJgk+3NO4L DDDeeKCM/dySO47UmepyenTHSgQfNkljzmlYjIwMEUbiRkEHA9M0bRj2647UDEXqPmGT2zzS gEnnJHfNABzleQD6UgBIOMgjsBxQAoGD0yM49qQ8c4yPT0oB6AjPqfSl4OM8duP60AIW6Acj HpRjLYGAOpApSoU5Jx2I9aQkAAEk5PPFACfKpxj8RSgjksp/ClC/Pgg4pDlTgjr0FAg5Lbga XBXOQWwcnmgEEHgcc8Uhxn1z0OaBhkMfusB7UKQeDgZ70KDnBHBycU0f3OC3rmgQvTjk46Zx SnuOce1IQF4Q7etK2F+UnPv60AAIU52g4puOQDnJ46dKOmCeMjpjpSnGRgD3oAUjLct93nFN BJOeF7elLjnBx0pT8oByeOMYoAao9MEUZXHYnuRxS/eIIyQO4owemMD9cUwGkDI45x1FAG7A ySOop2OMZwO+Rzilb06eoouAnO7kZI6nrmk7g8DnpSlDuPXj0H60d8rnjrmkABGz834A0DPG ScjpRuzng/QUDIOQOR2NACEgtyD0xjP86PukkGgDgg5yaDgkAE4HvTANwJXAOKARuyPxoPOO 9A7g8+hNAChcA88mmYyCcfTNLjJPGewoA4JI4/PNACkHt178UEbSSQDjg5owdvf86QEEAY+t ACkjABPbpjgUA45Gcdc+tJu9eQeKCewwTQAbvYMOlKcD5dvHpSEDbQMAYznPqKAFGSpIJyOl ID+PcA0q/N6jnsKTB3kDJ9qAEPGPlAP1oIxypJI9KXPrxjtSEn6c+tMCrRRRWhIUU5UZz8oq eO3ByW5x26Um0gsVwpboKnW3x94/rVhUCk44A64o3YY/eK47dKhzb2KsIgCKoCjBwetBcuw6 YHQ4wBQQ4OcHb78mjBdeCSuM1HmMTIKkZ/Wng5Ayw56YP60wFVx2H50YJJLEn3FADguw8AZ9 DzQhO4EH5eoz0ppA6k5HsMUvUjGAxPAoATIGDzgfypc4O3gg85/+vSsNzEHgU4NjC468896A Gvwv3h04xzS56dAe3NM5YAjG0D1oUqznP5E0WACA7YIwT6etKWCkgDgc7j1pRyvPGOQB1pBt ZjzknjigBAu45yQfY0p4YMO9IScnnBHQdBSlm7kAeqjgfjTAUDg4GOM5IoEgDDqc8/dzzShc 4IyTzxnNMXGS2Ae3SkArvyGByfYYpQAQRv4+8femsrBs9AeuKUY3FuduOOKYBt285zz2NLuy f9oHHWhTtTcOcdRSKvy5YAnPBpAKVVXYKTnPf1phA2Ece2KkG1gQBxjIJNIUJG4DGBnrRcBF 64AGW7elGOTk9OetKwIUAEenA/Wm7dxPTgUAGSRgAHnPBp5lYcc0wZbqQM/nS4BXncGHPFAA CdxGANvXI6UEnGcbh0x60nTpkDsTTtxPybgB25xQADnPZsdT0pMle+TntQOFA4KnqaAQOOxP pQAOTnbgetOUkkgg/wCNJtyPvcj3phXpknryP6UAObuCM88nNOUnBXoT69qYzg44PA5460q8 84JGMYo6ABwFHXP04pQN2SMYAzzxSbCApyKRuRkgg44IPFAAMZ5GWHTBoLAjHP1HrSq/yZIH 4Ck4Q8Zzjv8AypgKAAvvjqabuO3GCF6cDml4wcDnjgnNNGN2GBJoELy2PU9aROMdQT1BpRtP Y8+9LuwMEHJOOKAFLZUfN7DmmgDOD83NKRh1ROc+tG35uc9eOaBiE7gefwoJLdgAe+KaCeMY 45+tPBJUDk8Z69aBBtBGGYDsMGm5AzlcCl4DYYnGfWjPoeP7vegAwC2OTSKflPOCD1NKVUjc pwf1oZcAnPH+e1ACEknkn8KcoP4UNtfp+Ax0pEYcZDAD3oAQkqufT+dIASwJHP1pepHYe5pS Bg5yT6GmADnODjHfNBCg7Tn/AHhQSP4VwOmKaOvKnPrSAGIHTtx0p3JBIxS53MoH05pqn5+M Y9utABjDdOPag4Ug9Rn1p2fmweg7jvTeMjtTAVuQSRk+3amqAfUgehpTkfN1GOvajIAyM5PJ z0oATClhngetA5/vH9aXIPJHJpCcLjjn2oAB9eKdxleCcdD3NN5YAH9O9B+7gGgBSW3+/Tbm kAORk4Hcikw2OowRwacRgcfhQAgXqDwBQV9f0oOAcgdqMjOf6daADblSR0x/nmkBzjI5P604 53nHQ8c00kgYGAQKAFxk80hJJxTguADjP1PFJxzx/jQBVClugzU6wbSC4yD6VME2qCqnGeoF Kfp2+XI/lTcrhYVVVRnAz2APWm4AYZC89DilOWAyp6d+9KXyQrHOOxqBiE7lLBeM9j1owxwG CjnPFIVUEjAHGeRTvu9cHt+NACsuGJB5zjGccU3BClduMdB1zRsYtuXr7dRxTeGwACwPWgB+ SuNuR1/CmNuU5GDzjFPAKtz1A6c96D9CT3B60AI534RcFQOOKdhSACMDp83NISwHYYzz6U0q BkF9znuOh5oAe+WU5PfqR1pnVhk/KBzRtxw+Nw6g09clcjGO31oAAeBknPbnNJgtgDBHvTRy cA9+c+tOUbQMDg9eaADjcASffIo3Egk8qSfSlYEHILEMfrzTcqpOFxz1zj60AAIYZAzgYJBz QqKCdx27qdhRhgwHfr1pGXBAbn8KAEHLBSCeOtK5DAckZ7noKMEAgnoOB/SlDZzuHPfcc/hQ AEqF3Hk4yMUgwpGOMdDSHdGBg/QChQdnKlueSKAD5Rz+QoGNpGOT15oXl85ycfkKXII25Gc/ e6ZFABlsBlO0k4wO1GOf7xPUijkFtpI4xnPQ0gYnuQc8+5oAVWwOScdeRSBQxx8pGac+eoBz jjHTpSAArweB1OfagACFmOM4x/8AqpAxK7SM5x1NJu2nOMepB7GhWG8EAcjFMB3zYGcc9c5N IMu2eOOOe1J85OFA4GfqKM7uA+Rjp6UAIwGVAJ574zThgjhTnpRg87M5weR/n60YABxkfpmg BCBnBI+po3bQGXHHU460LtA4IPsP50Adw2f9qgQvAU5649KXnGcjpSEnGMFcjp1zQyljkZ5H NIYDLEBuPqMUmTjg5HckU5lwOGwKMgDIOcfkaAEcr90jgdKRs9+e4ak2/Jzkg9hzSjAbG7Hf J7UwEw4Yd+Oc03bnIDZ/Cns21SAQAOTil245OcY460XENPAz3PbvQrEY5xgUmDjjNIRkNu4Y 9eaYDhgkEhvzpMnaAM89qcSAqk549eho4ydwxnkdqQAfvADA/nQGw3TjGDijgE9MjqKFyTjk 9TQMTIzgjBP5ignLfMCcenpTuuVGN2KbuGMg8fy/GgQMAeo7ZGTQUAAIbB70qnGeBj07UhGe 3/AcUALkDqOTxgHmkHDEk89hSlCccZbrSLuRdx4wOhOKAAHOF5/Gm5JXnpmlLHGdpUd6QAkA DpwegpgLgAYGetLgdRx9R+lKxwvDAemKQNlsnnikAMQw46Z/Ol+ULjdg9scUhXII5HvQTkg4 JyOBQAhAwQOSBxzQvGM9RQByAF+tGAWIP1B60wAs2455GaMBgT0470YBIweKU/M3HA7GgBo2 7cFefWlwdvzdz0peVBB5HXnrTRgng49BQAvAAOD6daUYUgbf16UmAB26dfWj5imcH2xQAFgC CD07ZpB8yD+8PXpSY3YwACQMAUpOTk9R0oAUKSg+6PbNIeexP1pEyvYgCnBs8A4HXHp60AN6 YHr3pcntz2oxsyCfwNIADtyD+FMBzZ47kdKQ9Pu5/ClAC8g/WkPJwevYGkBKqEZwWGORmlU7 h1+Y9scU1+SGAHPbPSjhUJyeetSMGOD8rE46gjGKeBjHyKT2FNYKVO04Ppijcdy78ZI9MCgA RgFKk5+vY00ncd4Ax2o2bzyOc8dqcBhPlwCP1oATLNjnnGSaRcZUZweMDFLuJ5wNvfApT8nQ rg55B60AINwPLdec96GO1AR1P8qYQVB6H8eakCsU/ng0wAFmPTt600ZCkADPc9KcSWXI6jGQ OaGK8kYOO3tSAVsKSx6Y9KT720DnPUjtQ2GTv75GKM56jj6UAGBliRzjpQSAvAxjrQoK7uNx 757UmC2OPrQA7DBs4wD045pGBwDhQc9cHmkLIDt4xngYpyPlvvYHGOM4/OgAIDHaxx6g9qQn j5SMZ4z60hbOMcgH601lJI3D8jQA4tnHO4+1CnHByPY9fpR90jkZ7Y5+lLx3ABOOhoAQ8LwR tPFObCHDZGT6cmggp8wyTnikHUKc++B/nNAAy8kjk9iDSDcqYDgn0pM91OAOueKXD5GAvOe5 pgDbiMYHTt/nmgJhehGB1NADbCGG7n60rNhiOM9CKQACFGCcj0PFKOrA5Ax2ppZTnGBjjJ/z zRghsZBPqOlACqWU7doOOoNJu4AIQc/nQGIBD8dulIxyoI65OOaADGCQCvPHWj7hKjPXqB0q TcwVskEelMc5X5ug9AKAEJ3E7T7cUZZfvDOTwD3pduV7gD04peSuMnd9RQAHcpYMoHGcgU1Q CSc5z09qXaRjBzj260hJGAMjj8KYCgbRgYHIIOaaDu2jv2p+7dgZ5J70B8Hnr7UgDIB27uMZ 5pp6YGfrjoKTdyTgYA/OnknheAB1wOlADOVAIPHfB6UpGWwTz7UfKFbBz9aTkYGMD+dMQ4DO 4cZPI9qGX5Rx0pW459ucUwdGXqOh70DD5d6gck+velPIxnB6ewpSMqAGzxSZ2lgigHvzigQK hOMAkmheR3z6Udcfw89uaTd1yOPWgBW3DAxuAHXvTckNnOeKduyMg9PT1pMdTuPXtQAh3EFs Z9u1OBBCk/hTNx2H5Rz+VPOcjYwBJ5xxQAbWAJxzx0HalwucE8d6bl+QCM5oLKwJ4yeBQArY VtwycfSm4Aw55x1FAHy4I6frSjjJJOTx9KAFYkqCqgdyaaSMsMYOOaVcE7QTx0P9KQggggZ5 6CgBSQep468UjEbsc8dT6UFs+3tikGSQRkccccUwDhQG7Gjjd26dR3pQMEknA9MUvA+UEZ68 igBFPy5PJ6DikBHXbhqUk44zx39aN3cDOfWgBejBcDjmhsM3B69OKQElcnp34pBgN6CkADcT jAx04pQpO7AAHtRjaDzyeopOCAMgdqYAOmDgDpmnfKRkfTpTRkDpgfXrRj+E5H04oABgD5s4 9hRkHkYwPWkPGMZ6/hTgQR2Hc8UAA+Y5FH8ONuee1A4Tn8OKT+LBwfpQAZZsA9R2oBI6Y+gp CSCGwM/Wkx07+tMBxyvOM8c0Fdyg4OT2pCDxnAx3o4BB6CkBJsfaOVAzwO9KRsXJ/DnNJ5Yw vBC+mcGlGMnJVsD0x+VIYKwB5BGeaXPy7gPm7kU3liTg8dTkcU/ClSTjpg0gEyGyBtBFGGKh Tgd8AU0bAQvH4mncZUL16mgBpx2HOeM/yoZQx43deuMZp4VtzdgehpGIJ5BI/kKdwEwUG7ns TzkGhRtJzgg+2aDgsSvGOM5pSfkB5GDnGaQCuN20qB16g9adyFw4AA5Oe1R4JxiTA7HFJxu+ Ybh7DFFgFf5zkZA9fX/GgLu5OMEdqU55QdBwAKCDwTjIPAxQAiknjAKj1obLPknnpgcU5gPL xjOeTjt+dIWAJKk5x160AIucMccjkZFIdzR7hkDsPagcA/LkYxTztbkbgfegBcjyRjgAc0xg egU5B496dvBPBO0e+MUmQW2noOjZ6UAIAOoGR0NGfm2rwQcjdz+tL8wXjB54OOKCCPnJzk80 AI4YDk8nn/8AXSbQQoPTqcc//qpWOGwTx/OkXkHDD5+wHSmAr43gqc44xS53ZwpB7cdqRccd gAefWlHIGOw6Dt60gEONzHjOOwoCsxPQY4/zjrSJkKVOSe2eKUlVcdvU0xDWAB2Dp0xmnLnO TjJGDnFDE5znK5BIBzSs+SWBwcdT1oGC5Ibvjnp0oILEY5x1pCWUEHO3OeBTyScOD8p9aQEb MwK9SR2xSvtHG0nPIpFOOcnI6UuMMAQSfU+lMARScZzx7ZpO5759qcW53DPAxwMUdFJ7+uaA GtllUbskDt0oxubqSB1pRkgE856be1HIUeXxnkjFACHuo9cZ9KCyqwUZ+oqTgKSwGf5/WmhV BwQAB7UADIUHJOW7ZzSSL8xGcZ60hJxzjGOD15oz3PAzkEetACKu8YOBnHtinZAOME9uB2pO DhunpnilALOC/XP60CGDHOD+BGRTuCASpGeMU4jGQ3yqDxSGQMjAA5oARcEEYOccYFJ/EDyR n6UoZsk54PvzS5wPrxyeT9aBjMgAkdevNO5I6YHqKVQpGRk47Dik2ADapO3I6nvQITC55+72 GeaCcE8EjHGKNueVGDj0pSAECAEkc+1ACbDxzj3zSHCdOooG7ocnPOMUrHAJz34oAAecnnj1 5poI2g4O48HjjFOUA5PT6cUgUL94ewPvTACNvAI5HfmnMox8/B96Fxj5s8dKQcEgdxSATGeQ OfX096HzxlvyNOI4PfJyaBgHcVBH9KAEyjIB/wDWoTHAI4PNNxwdvAJpx4OMEc+vSgAIx1GO wNJnDdMHP4Ghl3kDGe5pSOPmxn+VACF8rj3oJVce/eg5PLD9KOTgnP48UwDt0H+FNbG8ZyKU Hbx0B9KUcrnOCD69KAAMN3I4/U0mccgcHtTsDuTyOO9NJxwD05zmgAOc8Y9j6UDIOGyeKTnd 1PHpS5bAG047/SgA4OBzgetC/wB0jJ+tL3PTIoIC44wcdqAADGcYx3//AFUjEFRwc+tJjHG3 GPSk+YjmmA4jbgtnAPSlAB/zik3ZBPXIx9aUNkDkgjqM0gGnjg5NOA7H04xSA4k5yvagsM4G QD6GgCQKAvygY55HSggqgJBGQQQBjNCg7wCAOvFKe3oecetSMQBSQVBCnrjjFLlsEHIGelBZ uNoJxwMD8/pR3BYn8eaAFUAjJOcDIx2pvUn5RtA5yOv404bWbGMAdjzTDu35yAM9zQA7KjBO Oe/pQHzwRuPoeMUnQgknHrjrTVHUkEgng5oAdtDDA5yc57UFvnZQ3A4pQqjJztxx60j/AHhk emPegAJYAEnvQxDfeIUj2xQwUKWXJ9eKXcNpxjHrQABcrkHb3B9KQA5D4ZiTzxj8KVsjJyG5 4x/Ok52E5JHrk8UAO5Jzk+jUmcfwBgfehWKkBQpHOTStjvjn0oAajB5eDgEZxinYKgHGRnAz xQrbTgA4x3zxSDIUE9R3z39aAGNkk/LjPHSngblychfQ0hdlJyM9/pQT1LE9PrTAXICrlsEH 0xQfvgbsntn9KaWAUgjIGDxSlv3YGR6gnqBSAAflODtI9OtNHqeew4p5GWAJ3Uki84XB+nem A0bQoPAPYZpxQscD+LvS5AOSMH360ArjkYz/ACoAftI+UgYHJOOaFVWDfdOO+M01l2qrKGB4 /OkHAxk4PXHGfpSATOewKjqp/lTyy4GWJOOfakAJUkkkdyvUUsgBYZyq4+UYoAGJDcnd9elI oZWxkEA560OP3a84Y0oU/KTknoAMntTAYSC3XI9yKczHbhWyvUjPBpdxBw/HPOR3oJTnbgAn nHJoAI12wthRjOM55/nxTcErjeD74/xpxJPyMSvQr70FGAckE9vagBgBXADcE5xinjIOAdnH bgn2pQvlghjggcgDpQi7iSRgEHJznmgBcsFXLYHTNMCgoQvDY5GeopdpKnjIyBuxTpEZDllw e+aAIicgAMc8nrk/TrS7NyrlOAeAadtfyx+Y9MUD5VAHOenegBhUhQW+Uds9xTt3KqV4U4J+ tKDgBvmUgYOeoph+8BI+Vxxk8UwHrw2N+8/1puCOAnJ/SnhQADgEk9D0xUYxgjIX0759qQC5 +cRlRkHnmkUgghlw2Ojf0pwjAbc3THIoBbdjacgdf60AMVfmB5PHPHSlLAgjcMdwp60q5I3d u465pwUFTu5YHjPagBqrhTgjPpnt600kEs/BBA7/AK07JO44HpS4wxBXd9ev1oAafmwzE47Z pHGSuWI7ZPalA3A4zyPwpFVcYY5PtzQAY4wBz9cgCmPgnOQcdwKmwXGVUDHtUZzycHrxzQhC IxJznkdqCCWGG+tDYBU579z2pxbDDC49KYEeNjAAginkl+Ccn3NKqY55wTyaQgHI68/nRcAA 25HTePWkxxtzjrmlJwpPJajnHI5xSATdjLEHHXFH8ODleetK20LgHnvxSDIBLD26/pTAMAHA 47cUrjpuBJ746U72PB65NMORjDZP4UgDBxuIPHAz1NHbCgYPcd6TcxAUNkY/KlzwMdPTNMBQ oyPmGfYUhJzx0XtSANkYXOe+aXoykYA6UAGcjBBA9u9HO7dksTxnNJyBgE9T7UKpIA5yKAF4 x94fXNICcg8kfSlH3sKPm/PNO2kDJX6YoAToo6880bsLgfkKYQc7QAPpTsnbhu59KLAJkMdv T8aMkHjnHAowu3k4INDDrz170AJ2HQ+vtQxyQM8fpRnIOMAe1LnA7A+lAD245PDd+DRykSlD 1PWnKUBAUMW65JNKwXhVJ5JxzUjDeWBBbkYzgcU07wQDyOtIu3PPAHTOQaXJB4IKj060AHBX JPHcighVOQuePXvRs3YDfMPWkZSV+VuCcY96YABu4HJPr1pWIBDIufUE0uwjPUbeOO1A/u4w QMHnrSAFHBDbR6880oTBbb0PQmmtgrnqD2ApcjHQZx07f/roAbucElT9felJ6KSfXmnI23OS RkcY/wAaBgsdoAYetADSGOR3B607nOAflbnBGKb1Y8kHvxSvEuFIPBzxnmgAzsJDZHbIGaGy p65XtxQNgTBXtkHpTD8zALnjigB+5h8x5x2JoPyqvzHjtikbkHnjpSgAKe/p25oAXB8z73GO oPFNVAOC49Pf9aWTI++2MDHPekALFSCMgYwaAHKBt4yfYnFN2BgTwMDkYpekO7dwDgY9aaG5 6fQA4pgOCkx55PcDP+fenbOSw/4Ec5//AFUMPn+X0zQrDcABgg9T3pAI3LMWY5HHA64pFGH8 wnd7ZyDS4JbAOM89T/OlxhvuqD94UwDID7R8ue2KG2nAYsTjjHekbGSMADoRjvT0G5yFzk8j mgBoI5Q8Lzux1/ClXuqk49T3p52jAHfgcc/X/OKbGCDknIyS34UgAKz4OVz68fpSuSzhGxx0 KgcfpTBuQAMyjvnrx70qgGQsM9O+On0pgNLM55BOeuO9KVG1flOO+3qKCcAscgZzweCPrSks ZQvIBxweeOKAEUjcDkBuw5NP+YllJwB82FGf1pC2IsArhiCQMfy65pc/KC68YAXb/WgBvG4/ KPvY5PNDDbhfLwG469u9PJXCt8xCkfKTTwQznJHPTbxigCHduUYA3A44HIpfkK7iMAcEdSf5 U8YwWCbtx+Zc8j8aaxBUL95ucddwoAWMAsBkdOTtzTDtdRk5X+8DyfwqT5TEc4Xk4UcNx/Oo sRIqghy5Xt/hQAuFIJJXIPGOwpWbaPn+VMYBUdfrSsUJC4AX9aVgGC/NgH5Tk/40ANfMbAAl eOMc5pByVBGMdQOuPwpVZQdq8rnBHp+NDFGG4EfJ3BA/D3oAUIBkZPPbPOc0xwd3zfKF4IGM ilYhVUcnPOT3pzoCqkDFADMsBgkBf4T/APWpB8+ASQT2Gadt6MwyCcDmnMWUYxx3Cjn9KAIz HmTDOMkcYpAq7sbzt9aeqgEA4cd/T6j3ox5mSQfbJxgUARjcQxyCQc+tKuPunOevXBpVwu7n PHUE8Urbc4ySM44NADDuK8BeOeeKAONww2fypynee4ODwTTRzuAP0KnpQAhYtwSuc+lDckk5 ApwUkgkUPhjkgDB4GP8A61ADBtU8ZJ+lIV7nGT2pQOT+Ax0o53Ac+vemIP8AaznHFIcl8nn0 Oadkndx06dqYR17ZPbtQA47Sctke57UhLAdgD+NKRkDpx+v1pBkZB44646UgFPAzk4IyMUgA K59xQchfvZ9Pal3FjnB+uKYCbgzDoMgcYpeWfOOnPHSk4zjPqaQn5Tjdk+tADwTjtwetNUDa WXoT3o3HJ4A20AnG3GTjrSAUEg/dAA74pucMAOSTk9qC3VgD6cHFGeO2T1pgKN209AfekGB3 zxS5xkHnjjim5xgHJz14xQAuFx1PsO1AYn2/CkOMAjP09qeOuW7elADcr3Bz9KQsMDHr+dLn +IHjvmhmGe3brQA3cRn37+lKp5yTgkdKc3B9B/SjJ3gN6ZxQApJGMjnpwKMHgEZJH1p+cEsW wemTSEfNk8ejcUrjEC4YbT82PTgfSjdl/mwfQetKpOCwz8voc0qlvKIx83bGBigBoUdSOCOw /wAilUElsgBf7w4NMJwODjHGAcUpJBOcnHAxzQIFII+YD1B96cTuOOeOQcUu4tknO4Yy3qaQ 4UBdyt7g0DGj7wJIY/w045Zc43HkkmnBcLycrnqO5pORhR39vzpAIobI6E4wM54pcAnJQDjJ 5oxg84zg5J70g4PAyPUdBQAoKjPzEoO3tRtyQchgB07H2pFAz0BBOcZzmljyrcA+vHagBD97 aT19+BSqQr9cDqaUDbksPzNACoAvC/U9fagBvBOcZHag/ePykfrT14XZ6c5ApoUDOBkDPbFA D0UMeflB6mosNnjt3z+VPOWXa2cf3dvSnZOAAFc98dfSgBozuUbQTzxjilyyyAg7uMHB9aXB Rcc5+9heuKRizKSvHfj+VAA4Z1ZW6DoCaVOI9xIJHPHakBcNy3HfI4pVwgY7QHJG32pgIA25 Wdhn07mkVi6BWBwvPI706NUUEsRjqaaem0fKAMkcUAKxJYY69uMinYZnIBIzgHvRlg4cBiCR 1PfvTxvP3lGB2PSgBmwoWwhw3cdMUb96jGNnBwRnJp3JwxyG7c80YCElkG0Hccj9KAI8bWLF ctjpjpx7U8ncCH6n1PT/ABpyyEkgkbOcYPB+lRBVEmwMT26YoAeihj1+7xnrx68UvlhygBGB 1Bwec96dnawJOMvwew9uM/lTGQhw8ZYMV6DHtQMexXcWV8E/KAOaYArNtcg4yc9efWlKkIZJ Sqc5XjjOaUt5hV9gHOMDgf596AEyzAZOc9QeppCHXc4wMdHB7U9dxO5h5eW479T/AProjjGA JMNzwSwwRigBDkny1dRwCOTxS7MRgpwcdz1J75pVjXljkZGQQA3GcYxUbMFkClA3HKn/AAoA G3n5gFZhweuMUg5AXdwhyOOgpyMZPmyAFHfHf0yP8mnGKSSVBlgfu/N2FAgidiDhgmeOe/vU Sr+8RTJkbsEHj/Ip8myNAqKvXg4zn396FQhgc4xxx1NAEewu20BSmc8dffNOCI6tgENzlm6H inqkyLgRjG3JIAwDz196Qlfl3AKPuqDz/M4oAQgkli4IBJHHP0pm3bhyAc4GMHI9qm8wbWDF C2c9qRSGk3MBnoGPr/WgCLBkkO5c/NnnnFP+VWxk8n05BpVQ5+ZCu4nkjp1prDYmQWIz16Y/ z/SgAZmJVhnvz0/H9KGZnGfmDMctk9f8aP8AVApuJUj145//AF0KDHGDsG1iQQO1ACEkg4YM Cv5/WkPzOoYkjO0g8VIPLzhVzleSKjPIOX3FW6E9TQAMFznccZznkYPvQowucEZPJzzRhmyC xX69f89KaqZ4LMOc80wFJGzIJye2fy/rTUO3lvvEcHipGAII/hI647UxuUBIyDz15xQA0jOe wI7jvQGO3AT5s9KUASDKjOD0H9KDuMgySDjknrQIUfvCB0UDuc0jOM5YMTx9KbvzwpC89KU/ MTuUH0//AF0rDBmKt149ulIDnIGcU8HGWwB/s7qbkBsgDd0JB70CEzuJDN+BPWkJwx2tu56U uflLEng9CKTA67O3c0wBQTx3Pbv+VJ0BA654470vKljnB75pVwAB1IHUHoKAE3EAYHP8qXJP UnpScAYwDjuaUkLgHkAUAIQoY4z9e1NJ4XHze9KQQMknjtSkdQSR6ZoATc2RnJ9PpSDG48cU /wB+pHfvmmE5bOBjpzQA7cSDg9Oue9NGTy2Mn1FDPuGOnPT3py4A4x+NAADhSCDz1560Kdo4 xwckHjNIDnoeD0HelUHHyk/X0oAQhuOck849KVXGM4Oab8xcH+L19aCrZ59elAEijhflAbua UkFAW78ntTWYbflPsPpRkqcc7ehOOaQDvvdVwp+6T1obG7AyDjjmpAFyBwRnOelNAyxAX+op XGIcAZ3BsdxTRzxuzj0PX60pGTt78DB9KecAD1z0oAh371CqADjuetOHCqDhuMHNBACk46cc HPNIR8wOM7eMZNMQuVLjjA7AGlVmbAI+brgChRtQOcnB/ipwZjnGDxzgc0hiL1zjJ7+1Nwen Qlqdkbsg/N69qQvlzlep7ZoAGRwcgZHYikBIUZPyexoKAuMYzjscU4JlTg4Xjce9MQ3tuBBH Q55o+YJyCD34pQGb5gQeeMf/AKqcAvPGB6ZoGIcbQCAGPelX1Xll9TigruJUPkdh60pGDuPz MDkZ5oATAZssQnsB+Z605mAXIHPTOc804khyWwCeRgZx7U3bhlUD5ep9vxpACJ8o27i/bPFD qxGMANnkdPrQB5bBQ/JB4HI/CljRVXYV9wSeaYCIgJKscfNzz3/CgtnhwCf4Rnt6UsaKj5wS QemRUjlCxIGSOWzxigCJlAGE3KB6d/x/SnSIowwB3HqB0H+efypWLSZUx/PyTuPP/wCqmqHP ysuc4AOeg+lACFH3gg4GcDJ/WpUUMhBYggDGBkY9/wDPalwCzRq4IxkZH6D1/wDrUwsifKhx nksaNwHFn8zHCsMrTDvPyg8A4LetKcDEjyAbiScpnp9Kcj7kIG0Hafu9R/nNAxsce9flIYDq T2/Ck/eM20ODjluf5VMArookD47gcdvfgCoyS0i7dwXsh7/WgDb8O+ENZ8UvKdItfPFvgSMz KqKSOOp5p2u+FNd8OSBdWsZYYmbCS5BRj6bhkfh9a2Phx45/4Q3U3S4UyadcqvnhfvIQThgP YE8V9EXVrpnifQzFOkd3YXcYI7hlPII9D3rz8RiqlGpZr3RpXR8incyFNpI9duPyo2bEDEEc AZ46fWul8eeE5PB3iN7VZHmtnjEtvJJ1KE4IPqQRj8jxmubwhVeq54AHTP1zXbCanFSjsxEY kKqzkKVbjJ6/lS7HDgBcJjPOAR/TrTg/lM2GBcNxnB7UMWCnK7kBxndnntkVYDWbMZAXgkYH PX/PSp9Psxf6na2azsjzTJEGx0LEA8/jVbzBuDPkkNgD0H17VoaMufENiIfm/wBJQKAec7hj 9aUtIsD3DV/groM2kuNOe5h1BEykrSbt7AdGB4GT6YrwR4zbTSRStJGyMVYN1BB5BHrkV9lD 7o+lfJXi6VJPGOsy25Vo2vpsDPB+c8/4V5mX1pzbjJ3KkjF2khynyjHP8uc80RgK+GOWbpzT gESX95vVSAc8k4601srGSE/dvkjnJr1CCVhKh2hBk9efXvTGCKAsh+f+71wKcZSsOd3zYzkD pUZChyOCSPveoNCGK6qCAka+hyPal3Ykb5VcchiDyR/n0o2OHO6NdmcgnFPC5CkIGDL0/wAP 1oAjUCVlB6dcAYAJP86RSvmfwg5+6Dz1/WnbQHB25C55PHOf17UsiBwJAQo5AUHBP/1qAB0j V2BC9ckFiBUW0BAqlSg9+Sfb2p52qi8qTg4AHPP4/WmYzIUJwp5BPHNAhoJYHgqFHHf9fanR hgDu5Y4IPOTTo0VQN75w2QRj/PSh1y2Tt2H0wM/iKYDGVQT/AHSRyRg5/pQCD/vZ5Of89KUl TtAZiR1FOjBDg42k8kE4z9M/hSARijuDjAB5bP8Anj6VEVUnKnKnkEkDipf4SwCDnB5wfw9a aWIHBJOOQB19qAGENtPygY6E8035jICuVHv1p2CRnkg9OOn50oXOVQkHjOaYhjEKxw3boO1K GGMttx3JH6UMg5GcsecZpduH3Hkeh70AG1tm5VH4ZFNwytuADZHPtQCT6A4weKQoQzHOenJP FABzt+6cH05NJnDYwCfelKHfkEgk84NIFIOCMgd/SgAwQxyTz260AHBznIGcgUvOAxIx6elI B/e9eooANxLcc8dM0KeTn19eKOrZByAOlIWAzjn3IoAMg4AwR6UqgcqxwffrSfICQQfb607g Bupz7ZoAZxzxkGlzuGFxkelOBO7JHOe1MOTjjBFADsgkdjTfnU4OM+lKO7Ec9OOaGAxnIY/l igBPmzilDbeF5Hehi2c+nXFKVUsGGOenNACBju65PtQcBctkfhQF+YE8Z55PFKSQcDaRzigB wBDdOg5xjrTj8zZYNu7ge9N6c5zn+7xSqWzwSBjuetIYdAy4I+v9KMfkR24OKdJubGzIwDjr zTR8re4HUcfnSAUBd/3eg5BFIQT8gzj3PSkBYlixxnrTmPz7SBtx60ANwRnA6/rShmJzvOOm M8n/AAprDCAnnB6U5tjkMp5x3waYCjgAbSQPWhmG/HzYAzwuMUwDI2jnI7DrT27/AChsdccU gBfmBAIJNOVAoZQeT+AxSBvlbYWx2x0pFJzuOSCMZB/nQAsoO8HAA4zz1pNxHGOO/Gf/ANVL tXcMhQO+OaCyD7wYjvjp+tAChQwIYENnBOccUxdxcckggdKeHUqvcA5G7HHtQvG1s+3ApgPZ cABTgDplsk0JgNtwd6nnJyP1FIqKD82Se4BpmCTuyd/UFuSaQDiuTjPQcnGMUvBbcMHpkgY+ tIqsrEsu7cTnj8qXoBu9eOBj/GmArIVkB4B6+35/Skbh1cZKk/LngfrUgJ2B+QT8pB5x+FIX JUZZQwYjbgn8aQEZfCjdnBPzDHrig7dpdcLg4AI5xT+U4QdfvMOc4/lSlS6lscdADyRTAQj5 12cIeCc5H51KEDOCFb3z9KiIEaDHHOQAc9K7/wCGdv4UvdYu18RyoSUX7MtzLiMnndk8c9MZ 96zqz5IOVr2Gjg49qZYLnjIOO4oQecSHblenIx9K+m5fhp4Mv4VeLTIkBX5ZLeVl4/A4P45r gvEvwRmtw914eujcBRkW1wQHz/st0P0IH1NcsMfSk7PQfKzyJ8HIXtgbSuST/nNNKgErtIyA oywzn61dvrK+0e4lt76CS3nU8xSxlTj1+lUS7vHtdcL0wVz/AJ712p3V0IVTtfaxLNtJC49f wP8An0pCUIwUY9MjoelImwSneDux8vPIP+e1SCPlUwo2jnIB/X04pgV2KM/ynGOqjgfhXs3w R8YZml8M3TOQ2ZbQsc4wPmUfz4968bfZ5AAJXAxnrmreh6tPofiG01ODO+2mDgZ+8M8gn3GR +NY4iiqtNx+4E7M+lfiV4VHifwvIIVT7baHzoGI5OPvL+I/UCvmJY2SQnPH55/rX2RZ3UV/Y QXcLBop41kQjuCMivlnxtoS6J4z1CxDKFWZpIhk/KjfMuPwOPqK4MtqvWm/UqSOeLHYIwVPG cgZPp1pyHy1UMxI6lj8w+maZlowPmYr13j0/WnuBL8gJIB4Qk4r1SSLaoRjtJGcDnr0wa7n4 WaNHq/j2z3w5ish9pJXou37oz/vFTXFqGA/iKA7Scj+WPfpXv/wV0X7H4Yn1SX5pr2UhW6/u 04A/763Vy4yryUX56DS1O78Q6nHo3h6/1CRgoggZwT3bHA+pOBXx8Wd5Gb5j9eSf8mvdfjn4 kig0e38Pwyg3Fw4mmUH7sa9M/VsH/gNeEgnaUJHzZ4zzWOW0nGm5vqEmSqzltrsyNnBAHAPr ntTWR1Ks7Abj94ZpVby9uz5ffNPUKgV/vHjK44+leiSM2HKrIMgDt1P5/h+FOaInkjOTw2Ti mucMAAu1uPl55rR0nQ77XryKy061kuJ2P3VBwgzgEnsB71LaSuxkGl6dPrGqWul2as1xK/lK AcjJ7kjoK+o/CXg3TfCuiR2UMMckzLm4nZcmRu/Xt6Cs7wJ8PrLwhZiaUJPq0g/fXAzgeyg9 B79T+lZHxK+JkPh22fTNImjl1STKvIrAi29yP73XA7dT6Hx8RWlipqnS2/rUpKx5F49Fj/wn OrRWEax2wn2hY0AUMAA2MD+9urmUdVO0RsDgdTx/KmNIz3DTSTMzuTlupbP1pX5ACqg/LJHv 7cV68I8sVHsTcdtyC+QAhwFPH86RQSdzAkH7pPAH6UrjPHAGOAeQD/nFNiKsqRyZAI+Ve4qg HIcMqOgG0juMH86jckuFB6jsT8w9vxp+H8veWwgwQGPanuzZDKu8Acnjkf0oAj3g4+XgHOfQ U0hQxKjPy/xdqEClcgsD0B9PpTskxBTjrnpxTER/L12sc55xSkx7cYY8Yx2zQowrEMp6AEcc fSjGGT5iVwcd8UABf5RleR1AAxTN2ORkA9gP8KkQ7RjaCuD+dM/eFDmTAyOD1oADwNr7sAA0 pwvzAjA4GDSKWZ8Y3MBg8UpbIPyllByMUARsm1M5Ow+vPNOKsynB4C554yaQhgwOQCe4PSje cksMkehzQAhIbK8Aj14ow2CQMH2oHQ4A9h/OkOABzjpkHmgQ4qWBB5PrimdRgdM0vLBlwCBz yKVQpAyDg80ANPXqRx2oOGIxjjnHSnHLEgnAHQdabgKdw5560AL1ADKMD0pq8jnjPSnjOTlq QlmHB+oNIBg+V8ZyOnApxBxuHTPrzRwu0ryx9e1DYOPl9+uaYCDKqRnryaA33jj86THTjHvT +2epzzzQA3aCoHy89fWjb0HQikGNoFOAyRn9RQAm7aBlSc0hyMn+lKOhGDgelLyWFAEoZfLJ KDOOxPP05poZkPO4E+hodSGAGQPQ96XJUDaPmY/nUjE5DY6n2HQU4E7VwxJ9Of8AOaauQxHO G/E0pbbGCe3bHWgBoBwd208il+Rdx6kDI5xTmBzn7uR2FNTd0I3e4649aABivBbDE9BTUOPv c7hjGMVKchSqgDPfNMVsKCc5PAp9ABc5OR83alOc5POeOKcSCM59CAO3rTUwMk4bP4c0gHfM p4fnHIB5pAGDE7j0/E800qyOA2ff29qk7BQQSCSRg8UAMBUs20L+HelYK2QeM9Se1SFCAFUM SV54pFUsCMklf4gMmi4DMbVwO3GT/SlwoLAbi/0xn3pe53Bhn07+9OwflQKcjnPf8qABd/3Q CO2e9O2JGApB3Ywc9aHUHBOdp53d80jR/JhiAMZ5Pb1NADRglV4yp5AFSqEyMqijGCcGiRRt RgBgAEtnrRIoD7OdpGcbcUbjG7guZVYneuCAcUjlY8bgq5HI96kyol3MVGAe3UfjTs7z9DjD dAaAGBCrRl2ZVHJ3DGM+lK8SSKihsnGTx/WnKUUqPvg9Qf4fwo8tzG7MSoY+nTPTt6UXAiQq P3ityMjnk01pGPLdehHbr7H2/SnCOUFIlUnC5+QkUbBIAzfL1yPTHrQI3dF8Ua1oBb+zNSuI kUbvLBzGTx/D0/OvWPC/xrs7147bX4FtZH4FxEcpn/aHVf1rwMkpyq/IR1pwc4zvHQfKDxWF XC06vxLXuPmPrvV9C0XxbpiJewRXULLuhmQ8rn+JWH4exrwvxv8ADPU/CyG6sFN7pWN0sgXD xYP8Y5yOvI9+lYvhLx9rHhO6RreUz2P/AC0tHclO/wB3rtPfI9K+hPDfjLRfFlqRaTqJ9v72 1l4dfXjuPccV5zjWwbutY/19xWjPlSPDLlc7snJA6inqXzIWXORgktwCa9J+LXgqw8O3cOq6 cyQ212xVrReNjAdV56fy/HjzfylSIHduLZ2kDOcV6lKrGrBTj1JsMeMzNsAXzIxzjr9MH61B LEY2AwP8K7jwv8MfEevtFcLbLZ2Tci4uONynuB1Pt0HvXsWh/Cfw5pQD3cB1G47vccqPovT8 81jWxtOk7b+g+W5w/wAMfiY9lpCaFd6XqN9JBuMDWcXmtt67SM8YPf8Aliq3ibwV4p8deLbj VYdEOn28gVEN7KoICjGSBk/oa9ztLG0sIRDZ2sNvGOiRIFH5CrFeX9aUajnTjZsq3c8KtPgX q4UfadVtAeNwTe39BmrB+AMjuWbxCq7h8wFrnP8A49XttFDx1f8Am/BBZHh0nwBuNj7PEMbM WLDdann6/NXe+HNI8T+FvDMWkwppt+YAwiked4iASTgjY2cZ9RXaUVnUxNSorTdwSSPmjxL4 D8bXeo3Wqalp1zc3ErFi8JEn0ACknGOg+lcPPDLBLLHPC8Uy8FZFIYfhX2fVDUNF0vVkKahp 9tdAjH72IMR9CelddLMZRVpR08hOJ8dKrBicHA5Zsfrz/nmpSfMkYRdNvGfU1794k+Culah5 k+i3D6fOVOIiS0TH8eR+v0ryDXfBmveF586lZSR25O1ZoxvjY/Uew6Hn2r0KWLpVdnqTaxqe CPh3qfjFXlJNppitj7S4zuOeQg79eegr6A0Hw3ovg/S2isYY4I1TM1w5+Z8D7zMfx9h7V5No vxoh0fwxbacuiZu7eMRoEcLGwHG44BIJ6n+dcT4n8d694mlb7ddlLZj8ttD8sS8emeT9c1x1 aOIxE2paRKukehePfjFtafSPDYDsRta+DdPXYP8A2b8vWvEnkd33sxZickk85pGk6gE4HGfX 2pUXKgs+fyJrvoUIUY2iiG7jwGVsAfN6fX2p0bkHYMlMdP5dO1J+7bBHGcHggk/nTgVV8kjb 1IGOP1rYB6QttBKgMeNhH6+5phUeeNxJKjknr+NKjZG5SxZQScDr+FKkS5DBSc8naeAKQwaI N94OCvQNSR/vJSC245BCc4H/ANalUOxI2/IRwMZGOmeKiIKqzKuF+6dx6e9MRM4Kt5jZzk5w BjPvUYEeADJhh6+uKVYj5qqBgsNxGc/5xTpEf7ucH34/KkMaGIzGoIBGdvP1NN3/ALokkYAx knlvp+dSFCyuQCUPQgVAR2XcxHOff3poQ9o9pQ4YsTyMd/UfpSZeMbwjIdvU/wA6kLEvtWMg 9P8AIpADncq4ABxyf0oAiyQCSV+ZecdaUZ27AxXC8ihdpGMnJ5GBn8qeQrTOrge2eCKAIV2b TwD6DFPwwcsOuORnk/nSnarDcFZR0zjp60x2Ro2O0DAwDQA3OFwSoLfNk9KU48wkHPGc9aVl QRFg7dOm3HNN3Buu4/gKBDWTDABiC3WnhsHrx7ChuMYJJ6c8Umc9gzZxnrQAgYF8Hj39KazY G0H3FOClv4hnOAQaaVA4YEHkCgAzknNBwT1PHalxkZRcjHQmmYIIJK89s5oAXqAc8A5z6U4N g8j8f8KGxgc5Xp060w4xz26H1o3AVNwwASD69KUkk7sdaXluBx6kUfeOPXpQAhJOSQPbBzR8 qKPlBB96UDIIOR7+9AxgHJGecjvQAd/kB/DpSDn5ec/z96HxwD1AxgUmMHlc5/nQBIQAQoG7 HTjFK547g9+KRjtboBjtj/Cg7cFlJAPfHWkAm1ScAUoOEGBSkKykAFePXPP1oABKorYGD+NA wz8oAzigsWOfwGD/AIUB2PORtH8Pf607KlR3Ht/hQAmQFzg5IxtJyKN52llJBycjOaVQ0iHG MAfjRyMHcMdMYpAKAVIY9++M03YMsOSeuegNG3bk84I7U9ZMryegxmgBGGF25JAI3d8cUuXL qQuABkHpScHKc9OuOtPAIA6KOuOtADRk9CW29PenxDbkHnd3HPNMHyheRn6VIB8p3nHAIAHQ UmA0LtkIOOOfanhfMGedwzximK6IMgM/fnnPNSH7meRkHJz+VDAZGpUkl+McDOR+NISx5Azu GcninjMiggHI5BwB+dPdVEaj5lJGML1zTAjVlY8gqv8AEOc8UoXKBApIBJ6c4z9akVCpJ2E5 B2k9qauOM/oOf1pALhVcYHysPx/PNAG5yqldg4zx7d+KcR8o3FiuTwGAxxSQq/zFMZbBOeuP zoGMCFQZGbYGyQc7jTjtZgpJ5wOTil3qr7GXcpyBn19/allDSybGYKwHzA9D/n0oAVFaNyPM QBSDnIPHpz9aaVWUEYTjkNjgj0pI2YlgRvUAgKR1J704IPP+RVAHBDc4A/8A10AVwsQGckkD GMcZ9c1A6hc9Mjr7VrmKN3UjkHkgDio7izTIMD4yRknHJoU0KxmLIVOSTjsOvNWLeeWFg6Pt kHI25B/A8U2WApJhkHOc5qzpOk3Wr6hDZWUXmzTuERAP5/TvVNq12BoWUWseJdQSyie4vrib 5VV2LkD3JPA/lXuXgr4S6ZoKQ3mqAXmojDbGOYoj7Dueep/IVveCPBFj4O0sRxqst9Ko+0XG OWPoPRRXU14eJxjn7tPSJokGMdKKKK4RhRRRQAUUUUAFFFFABRRRQAVFc2tve27291BHPC4w 0cihlYe4NS0UAeJePvg+0ccmp+HA0iKpMlkxyQB3jPf6H8PSvFXUqPKydw5IPUV9r15N8U/h yl/DJr+jwBbuNS11Cgx5qgfeH+0P1+vX1MJjWnyVH8yXE8Egg/eAEhjjPrjirvlRgENwDzyK sQQsWWKGMtMeAqrlicenWuisfhx4r1eDdDpU0ak/enIhH/fLc4/CvRnVividiUjiyAZTHGwI z9OP89qaVwzKp3D1PA656V6nYfAzxBI4e8v7GFSMbAzSED0xgD9a6/SPgdoFmqvqN1c3s2ed p8pPpgZP61lPH0I9bhys8CSGW4mVYA8mWwEj69cYwO9eh+H/AIN69rcEE9/L/ZtswziVT5v/ AHx2/Eg17lZ6T4f8MW+63trKwjAwZDtUn6seT+JrmNe+Lvh7STLBZGTUrlBwIMCMn/fPB/DN cksdVq+7RiVyrqeWePvh+/gsWdwt79rtZiVYlArqQM4688ZrhhgKCSAh+7kdq2fFHi7UPGGo C51OUFUBEUUQwkannGOeenJ9PYVheYYXC4JAHvx+NehRjUUEqjuyWxzRK2CpDNjkgdP/AK9N BZ1wT909ue3b1pPm5TkDIYBeN3FLnyiVIGQASGJrYQqbRKwONp65Oc//AF/8aU+YrBdoyOMd cduabt/5ahjg4OD6/wBKUKCVOACMlwfX9BQMbHtViHLbyc8DOTScA+WrNuJz82Vp7ZJ3ggED rv8A8O1JtaI72yMj16/T60CBuGXCZyOg7/h/Wodnlud+Mnn6VIsisuAMYHU9vYf401hwm7gD oAMZ/H/GgBCrPnk564/z/KgA7QeGPONwpYyGIJJB646UpjPIbOOcc5IoAjQHd8y44/CnElW5 AOcgHP8ASmO5A2nbwc9c05RtYDqPY9f8KBDG2gqQOM885zSktgFSAccUMnzsMNj88UKQhAyT xn7tAByE+XB7nnnim8kEkAk9B0xTioVfMwox2pqj5SQrDPv0oATI5x9KBztU457DvS4+UHbz 1NNzlgoYfWgBZB2B47jNKOB8y8e1KMgA4BHcGggbQMdD60ANyQwycHt3oGfmyw/ACl3BSNoy QfShmXAwR0496AAElcL68cUE7sAgD8aFGCcZO2kHTd/CaAArn8sYpASo2gZzzSqdvODnPFIN wJb8ehoAkUbR94YzShQo4+bmnZBY4zkdCabtKqMg5HOR2NIY9TgYyG5OBmkaNl+YknA4x2FJ 98g55xjPU0AZ5zkD8aQCMPmUkjp2HWiMlScDGewOKXGcg5DMf0pxGCDgY7MOaAIyAGYg5DdB ilJJZTtwQce9L8pY5A5ODTm/1gJJUcknntQAg++MdT14pyH73ygjp1oOXYEEevSlcKSgyOee DxQAbdr43HGMA9BmlBPzA/NjuBgUKSgVv4jxjuakc7owCTyOmaQEG0cf3vTuKlGEGEPL85B7 ijYAqsAcEDLAdKeE2hdwXaRkZ7ihsBPmXB3Blxxng0/CjAClR1BP86CFVhkqO+OoHek3BgSP mGcZ7H2pDFjIVjvdiVGeOM5pW/1uAWVcHPuKXaY2YlSF25zj/OKcCpILbSoGN3NACYc5JcHd 1YjOaRGUE4GcjByAKezLhkYAHOemQPrRGyxvwAwPQLj+dIBEG4FBIExkg+lN3jaS6qWAxuHa je20HDqq+vT1FLwu8I7EsOo7fXtTA9U+GXgPRPEWlS6hqsvnNv8ALW1jlKbVHdwDnJ9P8j0q P4e+D4FAGjWpA7yEv+ZJOa+Y/NkVW2MxPHPqf84p0txJIwaV3mkHAYsTj29q4amFqTk3z6f1 5jufTT+APB8xH/Els8jps4x9MGqk/wAKfB0+SNLMbH+JJnz+pxXzbFJLHKHWVkc9HOQR+Vbd r4w8RWsW6LXb6PHADTswP0U5Has3g6y+Gp+Y7o9fvPgpoUiMbG+vrSQggZcOv5EZ/UVzF58F 9btlLWd/Z3YUH5SpiZvp1GfqawdL+Lfi2yZTNcx3UZ4C3EIx9crg/rXT2vx0uVJW60SKfH8V vOV/Qg/zpcmMhs7/ANeYaHB6r4Y1bR2d9T0q4iQcb26E+zDg16v8IPCKabpJ1u7tyLy5yIC/ VIvUem48/TFZF38SD46uLfwtb6V9mXUJVjlmeXcyIGy2FwOcA969ighjt7eOCJQscahFUdgB gVlia9XkUJqzf5DSJKKKK4BhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR1GKKKAPGtYltvhh 8QH1I6Ms+mahH+4aIKGgk/iAz/LjhuOhq+3x10fpHpV6xJwNxUD8eTit/wCK2ix6v4EvZNuZ 7IfaYmHbH3v/AB3NfMLSExAsvK/d44FethqNPEw5p7rQlux7Pf8Ax4uJFZNO0aKJxzvuJi3/ AI6AP51y158W/F95uA1CG3ToRBEowfQEgmuBL/uwc7mwOM9/ahpC6tnHzHOcV2RwlGO0SeZm jqOr3urXRlvry4nnVeJJpC+f9kelUDLuTGTnJOSc8fTpURLPyCSB0/z+VHljqRgc5roUUlZC uOZhnA24HBx3qZDn72eTjlug/nUEY3dOVyOlTjMBUg5/u4H/AOo96dgQ6MsoK7X3dSOvrTWA JztU7uMenfPSlcL5gw285yWP/wBf6f8A16a6szqxLk/ln6UANVEChWO3n8SPfFPEikFd25Af mDHkil3lWJyDnqx6nvQgRBIAqAlTuAzzQAkWSC3O0cHHT3696Y7/ADEOrbSSQM5Ge3enAP8A MHJRWBY+hApysVG9nRmHChhg4/ligBrInl/fUAn73+f/ANdC+UM8fKM7egIp25ZyHyMgfMWO MH0pFULnKkem0fnSAadu5WGPMGDjnIow0xzgkf3j2/GjaRIVQFnz8w/z/nilc7GxgDnqOn40 wInYLj5VweCD2oU7CwCfMePQc9aeA4Y7zltvYdRUe3YpA+bPt/jQAMP3hAC4xwc0fM7N8xB7 7qVht6gIT2BNDOeQSWPtxj6UAMI2Jlcjjk0Lyu1lwaUYHQFs+3f6UrMoOcjK8fT2oENLEpyv PIPvSbQvUAE8ZpxUbhk7s9gKY5JbGM+g7GgBSwJGeO2KMgtyMnHQUg+ZskjOM/h6UZwpwoPc YNAC5TjaBn3oYAEHGRngCkwSPlVs+9KGOcg/QUANyCSRnr1Jp2cEllznuKU4ycEDJ96aASx5 AAPc9KAGnrgsMnrStlsnjr3ofGOm3vxTsMEY4yuM0ASbNrDAOR1BHb1pOY8gqueucnIpA53l cAqPXpS+ZngkcnqBk0hgpxuGWz1BxQp+bG0Nk9AcUuDnncT27U4SF5Fzj5hnJpAMGCzc8Yzx 0oKk9PmBPTFIQQdgHfrTt2FIJwR+tMQu4BFw20nOT2pck4B78kj/ABpcA5MhzkcY5oUrg9Rg ccf0qRgcszKoPpT1wNy7BtHc9aaMhR1xngdc0rEBj15PTHQ0AKABuOdo9QcflTkIG0guTzlT zn8aUrnc4HAPHWkALADuBnNIBcKBtdivcEdTTkZeG69uRS+WuxX7E4IHb6UGNMbWYnjOeDzQ McBkEEgA9CTnNDZBID8ZI6H8qc0JAH3cjtkdTSDcFACkDkdaQChfkDMxAORg809YVAOwHYOu 3HNIVaSIcZIPZqcisPmJ+THJ7/l60gGNG24LtO4HgE4PNL5bMFGXHYj+tPVVEmcBnbseRn3F K8bjOQMA54PBH4UXAibeu2NYyOckgf54qNucqqlTjjJ5qfa+/ICqQeNuKQRgvhXYBRnPIx7e 9MCFgyoAc7u3PemeY4kABPHHSrbRbT8rLyOuOf8A61RPnG3PGc4/xFCArqyrvPHHpQZyMA49 +xp7EOoCAAkZPam/xgkbR0PNVYQ4TsRwvydj60C4xGMEBsYzn+QFNVMFg2QCNwHrTN2Ex3J/ L86LAd/8IlWf4g2QYZMMUj5PXO0j/wBmr6Rr5o+D84i+I9mr4zNFIgx7IT/SvpevEzD+L8i4 7BRRRXEUFFFFABRRRQAVS1bVbPRNMm1G/l8q1hALvgnGSAOB7kVdryf46as9vomn6XG+PtUr SSAd1QDAPtlgfwrSjT9pUUO4m7I6u2+Jng+6xs1uFc/89EZP5gVuWOvaRqZxY6pZ3J7iKZWI /AGvkClBI6EivSll0fsyI5z7OyD0Ipa+P7fXdXtDm21S9hP/AEznZf5GugsPih4v0+NY01eS VF7ToshP1YjP61jLLprZofOj6gor55tvjd4nhwJYNPnHctEwP6MK2LX49XCkC70OJxnkxTlc D6EGsngay6D5ke3UV5pafG/w1Mo+0W9/bt3zGrD8wf6Vt2fxR8HXrBV1mOFj/wA90aMD8WGP 1rGVCrHeLHdG94hiWfw1qkTAFXtJVIPoVNfHioJHABbbx93vX1dr/iXR5PCWrT2mp2Vzts5W URTq247DwMGvlOESMVwCe+T6V6eWJqMrkyI9pU7DtO3JPODSjYjKAd24Y4xwf84q2IpmD7gh x1+XP696kFqrEYbJx/EdoNek5ImxVC52xphyOmRzU4tOBkEHuT1PPc1OuAxAAUgde+Khe5Ag BVi/zZPHNLmb2AryIYW8tzu2clc/1/GmsFYAR4wB3Pc1JlmfdI5+c46YHt9KJIdsasSPvYyD 6VVwE2FUQvGFYn3oDIQxJJQDHzUsSMUG4c9MjgAH/wCtTVVWIAXOBxjjIoAXYvlsGBBHJPUc fWhwSp2javQMRz/KntsTC/KoUnBHPv3prFGkwpA5OGAxn346fhQA1XRcK24nHA3f59adtDRe ZsI78c4H1qNQASJW3N024PIx2NOdPlySv3SOOp/CgBAp+UPwnPIHU06XgsGA4GMeg9KIx5ju hxwfvA4/SowFWMMDzk/Ngg9qAHuSSvBDEcYPT/6/5VF5qnOOSR0BP/16eQ2cD5SOvqPalCog bAbcSDx3/wAKAIsEELu5zx6n2+lPIwd3Gzjb/n8qQPuVwcg+w/zinNlEDEg5HQkYoAPLJcnn GOo5qMjqUzwMEjqDSbmwec55PHH509MqTgIVxzznmgCPI+X5QMDJNBChcFupzn+lSAnzgSB8 w7c1GwCDI55xj1oEAGDnbnA43d6XJAAJxn1pOB0wT701lGd2ePpQA5tuRg49OKaG4xn8MdaE O0f/AF6cCwOMHI9D/WgBCMMD3280AnOSDj+dIV3knJ2jsaUAthg3HYZoACmBuZSCegoKnJJI 5Hem7D06fQ/yo4HBJz6GgBQSBk9e2PSgj5uMnIzyaQg4yRkjgUoBKqR+VADtoHXoR3pwB4AA XjqeKApz9Owp20H1OD16UmwEQ5I4BA4zgYP4UoyucAZ7E0HhzsJHeheWwD8nVgRkCkMEOMkt 0/Gk2gndk9M9eM0qlScbMcEZpQRnGeBzyKAHKNyuc/d9e9ImFOCTgcgYpByvU8fpT8qyjHBI 5J/nSARTtB4yQeo5qUgsoKAZx2H+FMYE9xkdD608EnHBJAwMH/69JgIMtnBbGOopw4VQDk9j nqaAW3DCDgdRUijLbgMAUmAANtUq3bvjn+poXJAUp37Db+tNGUZWGRn3608HLZHyAdQBzQMV mDHYBkDknoTQqkg8E5Hfjk0+LDqWbp7ikQD7rZCgkqemD+NIBNjYXAIBzxj86kx84bcR2GRn /JpwVgCpP7vIBxx1pSg3o/z7VIzg8+2KVwGsxClFLBD/ABbev40qncN25XAHG4/p7UFY3JJB JGQc/wAX+FOXzAFKjacY9j7UAIV/dZTDHORt5AoB2lXUKX3YDf8A1qkdSchs7OgHv/nFNWID 5XBGOCwUfl/9ei4xFVnYpuGzPJPOD/n0qwlskWC/zbs5APAFbvhTwRqnie7P2ePyrZOJLh8h V/xPsPxr2LRvhb4c0yGM3Nub+4AG6Sc/KT3wo4x9c1y1sVCm7X1GkeD2WjXWozEWVlNMzAqq xxlsfkK6mz+D/iW7UF4obQkDBmmB49wua9tudX0Dw7EtvPeWViqj5YQyqceyjn9K5PVfjFoN mStjDcX7Dug2Kfz5/Sub61Xn/DiFkc3afAh22/btaXH8QihJJ9cEnj8q34vgl4YjUb59QkbG MmVR/Ja5PUPjRrlxKfsFlaWsJIHz5kcfjkD9K569+JXi243CXVnVf4fJCx49uBmr5MZPeVv6 8g0Oq8UeFvDvw3vdJ13Tryf7VDdoXtZJA7SRc7iBgEcd+nNez29xHdW0VxCwaKVA6MO4IyDX yHeX8l1PJPcPJNNIctJI25ifcmvcPg74qF5o39hXtxm6tubcOeWi/uj12/yx6VniqE1TUpO7 QJ6nqNFFFecUFFFFMAooooAK+bfi7rJ1bxxPAv8AqrFBAvuerH8zj8K+h9TvU03Sru+kxst4 XlOfYE18j3VzNe3s13cMZZp5Gkdu5YnJNejl1O83PsTMqbaNpxmrARmXGF4HtRsx14/3j1r1 7mdittIpKuPEC+1AR6U0QhowQwGPU4pXCxVoqw0QxwPbPrTTCAuc0wsQ0hAYYPSpfKJ7U3YT 0oFYpxstvIyNnnvVpbyNVP3t2DiobqIsqn061FGm5dnOPUVokpK7A0PtDsm+OPAzjH9Ka5mJ xuHlnrt4Gfeo1D4VMheMNmpCvzFTK3AB3DgfTHr0pWSKGjzCqhnbAO0FQP50jqAcNzkbQVyM e9INsijzM4JzlsjJ/DPNTOu9gFGOOjDj8h+FAEXzeZGWbJ7sB6fzNXo9M1C7t3nttMuJbcHH mxwllJHUEjgHnpVBgwAypZ1xzn2/lX1J8NNPXTvh7pKBApkiM7YHUuS2fyIppXBs+XJYWVmj fzI2AyyknI+oNC7ZAFkLI3bjH+eK0vE96dR8U6heby3n3LsOQcDccfpgfhWbsKuAdpIOdyjr 7UgHsSrfKN4Lbsg5Pv7/AIVGzsC3yrsBzjA+Wkf/AFTMpPPVCPel2EEkKpzwB0I9KAEBA+ZS eTnBPt9KVg/DgJyemBn8hTyqMEwoZsZHOScf/rpmYw4XO4DI3Yxzn8aAFKoDvZi6swB2nP0p 3lqzbhjAz827pz0xSHGQrKSTnr6de9IxVSWVAST0oAYqtHIckFieAwyKcWwnzMVYE8gfpSrK xYIqHaOvOKjkIChsEsOhH1/n9KADJYkSDJHpxSlSQzM6HnpxzTz85OWdmOPm4xjHQ1G2QACS fQj8zQAjESLjaoweM0wkq33VwRzxSBh5jEqxOMemakeQhSNxORtxknPtQIjDbSAv3Qeuc4pB hpScbvocZpy7gwYIAhOcDrTm+Zj5aY+nH4UAMZ90fB+XgEY5B9aQcLgnr/F608AkDJIG3qRT SvIBOT9KAGAnJyRn0A6UpYZUKTg805gNoAHIPBpqj5xuO5f5UAKMHJHXPB64poI3j+Z4p33Q Svr0poCkDnv09TQAFySeen6045YrgEACkK/Q+lNJ46YoAUjg889D70vLP83OKbhmJ/iBPelD DcOmOmKAJuWTJJC9gelBCI4HGR3pvVickcdBTo14bJ6jvSAXOSWQ8DrimlACSPxHelBO3aw5 zxz/AEpA2SAeB/ntSAc5z/F14GP5UoHrge3PFKFUg4k/D1poHPXnPagY9kOxTjv1xTh82crh fT1pAAp5OPUEYzQRnnkr7D+VICRUwwx06jJpQR1UbCevP86aVP3ct15HcU8xYKn58AjJOKkB Q2WG7btAxgmnBBjIAbNIo3HK44GTUoViBtJH+zjqPWkxjEDArgkN2A61KqgEnI3Y5+b+dMWN iXV3II9s08Da5z94jr3FDAecnIwzFlHU9KFTeo+XG3v0z701lO0AEBt3PFTpGp+8xVV+bcR/ SpAiGfmVcjjDAdKkZHi2BHyi9WHbP1oCsGIww7jg4p5UEgbOCMegNFwEUZCsqhSB2HJ9TSDc Suwkqq/wngH1qV9q7RnJUcgngmmsVi3MEDDvyep7ClcYEjJUIwboT07dv501UU8K4cjIUE4H 0/zipN2WOUHA7fz4pjEAA/KGU8gcUAemeFvirZ6B4at9Nm0qRntwVQxuAG5J5z0PNZ+v/FrW tVjaCyjGnQnq0T5kxn+92/DFefmVfmIAweAB2pCzcc7R7dDWCw1Lm5rahcluJGnkaZ5meRhk ySE9T1qBZAOFYhh37moy+G4A5PakAfG9TnnbziuhIVxwdvNJXYCOpx0/+vTGlUr/ADOe9Nwc 5yd3/wBagZkPyHI7k1dgISQxA3AH+daFne3Gm3sN7aStFcQsHSRTgg1RkAR8KOM5zVpIZbiR YoY3kdyAqqMliewHepna2oj6V8EeOrLxhY4G2DUIl/fW2f8Ax5fVf5fz6yvmaHwV420OD+27 awubXyBv3xyKJFXvlQc49RivSPBnxf0/UoY7PX5Fs74EKJiMRS+5P8J+vHv2rxq2G3lSd1+R afc9RopFZXUMpBUjII70tcZQUUUUwOB+L2tDSvBMtsozLfuIBz0Xqx/IY/GvnVflw3brzXpX xr1h7zxTb6Wr/urKIFh6O/J/Tb+teYTuPKUKADnG4n2r3cDT5aS8zOT1LKFZJcK27kAhT2qU oCSgdSRztB/XFZauyYCyKo7d6sB4ghQrlt2eeCMe9djgBbG5BlmcbTj2z6fWnHG5gWKtjgAf zqqjOEZy556Y9fT+VNikwG/eAMpzk845/wA/lU8oHS+ENIj1nxfp2nTRh4ZZQZEz95V5P6A1 7XqPwl8JXSBUhmsiTgGGc8n6NkVw/wAEbL7X4i1PUnWNltoVjQryAznqPwU/nVv436uV1DSt LDsAqm4ZF7knAP4YP51aVo3ZL3NK6+B2nSDFrrE8fp5kQf8APBFZNz8DdQC7bbV7Zh6PGy5/ nXm1v4g1S0Dm2v76MKcBkmde3Xg1tJ8QfEtoVkh167wc/LMQ30+9mpuuw7Mtar8IPFdtvWKy hu4+zW8y9fo2DXL3HgbxTp43S6HqAC/xCAsB75HSu4tvjN4msowtytneY6tJFtY/98kAflWp Z/HqUuFu9DRxuwTDcYP4Ajn860i1bQR4yYJbeUxyRPGwPKuMEfX0NOw8jEhAckKFIwTivf8A /hcHgq/VU1GxnQkAsJrdHA/ImnjX/hPqaszx6ahBwxezMWPx2inYD5/Uuw+TPy5xtGceuPWo gcyHlUOBklgBmvoYeCPhn4gJj064tUnxj/Q735wP90kj9KpXXwK0p0K2ms3cWe8iI/8ALFKw 7nh1vG00yR28I3E7d4PJzx06+1fVGsTN4a+H1w0HD2dh5cQH94JtX9cV57pnwWvtK8Sabff2 nbXdpbTrJIJIyrMAc9ORn8a6j4w3n2X4eXUY63MscQ5xn5tx/RTTSsJnzXvZRuD7A+eQ2Kkm dI0V2RT8wOWXknv9aiEnlsdo49fSmB2B+bnkYHAzipGS/PIhKO0ik9Bx3/xp5CIxAT/lmc8b SKbK2242hDuJ+6ON3tijJwNoxI2SFA6HPGD/APWoAbCAWQLkbCT64H1pWYZIdMKfmAxx9fen JhG3Pnd1fHPH0pgLmPZtOTkA46Ae3rQAoIUtnhsk/MO+ccCnEgKN2XyS3XIFMjUxyABN59fX 170GNy4DLz/HjG7r+lAAm4vgyY53BgMgelNR25PmhTwBzzUrAI5WOIrt55Y9fTFRtISnKgno Sxx/KgBivhCSct94Z4wKaI1fLM4zjpjmpEIdchBuxjYKRlZGDRlQx6qOc0AN+YAZ4HsMc/hS bXbjAyO+aWR1kcbFwfbqaMkgfdIXt1GKYho5BdmJxx2/yKaG+8VHU4PHSnuN3IGF28D3pMhS oLY9c0ABG3liRigggYPXPQ0HG7K4yD1FEmS5JUfXNIBrfvO5Ht1oUMV5zz3NBQg7cE56A0pC 4bBOR2oAYWJB3crnJzQo29V+U5wc4oBxjPH45o28jJxz1JpgKF2qG7fWkG1iQ2OeSRzRu6/L xnqKXIXG3J9D0pAHBG4KRz1H9KM9dpAHeldhkZJGevFNUZbr+dAEpckBiFz+VOUHOeFX2PWm unzqE5GPXNOcEHaAOakYcEse+e1JglgxPBHHpSuGGVOBxj1oGByB06kmgBMk5+Ug59KkG+QZ PG0/SkYDO4LjB6YxmjODznHQgCkA9htY8kjtk04OGB3A5PX60gJ4AwM+ooIHOSRjg+1IAUK3 zZb+QqwkZD5yPoT1phA2gLnjjO7t/SneWy5IPbrmk2AZxuUMpB46VIisF/g2g9zSCMhM7g2e +acqtsBJAIPXPWpGG4s6suD6jkCpFUkMuO2PcU3aucMuAMng8iplG1D04OMjkkUmwGx5BwST gEdaUqwYnHHYd6cqFRvXrkZHXipA2ELfxE4A4NK4CO37kNzk+nHNOVUIUbgGPDYP659aaQSQ XAI6kLzTkjYLwMFjwCcZpDAKquTnPPPXp3pZEwWychsYz3oA3yMpAXB4DdKeB94BT9cjFIBj IHRQSRjjGcnpVdlBkIPXt/8Arq2yY/1jDA5J9aGRSdxGR1OBii4FMEqm7BAH600gjA5HvnnH tVjYW+XPH0/lT/IYLywOed2D2+tVdIRUIAkIAOFz1HX8qEhf76KGQ45bGB+FXiigAAH/AGmP f2pPNVRxhgece30o5uwFL7Mxk6Lg/wCeKctsM5YlR6Y61YknYYITcGPyDFeneBfhtLqSR6lr sTRWbKDFa5w0nu3oPbqf5xVrKnHmkNI5Pwp8OtQ8VzB/nttPDYkuHGfwQHqf5fpXufhrwbo3 hW28uxgzKfv3EuGkb8ew9hxWnfX1hoWlvc3Lx21pAvYYAHYAD+QrxDxl8S7zxCz2Wm+bZ6cR g54eb6kdB7D8a81yrYp2WiK0R1PxF+JlpZWVxo+jSpcXkgMU0y/MkSkYIB7t/KvBHGDWhLEV 7YPoOaqumBnFejh6UaUbRM5anReGviF4g8LDyrO5E1tx/o9wC6D6c5H4EV6roPxt0W9jWPWI JbCfoXUGSM+/HI+mD9a8CI5ptOrhaVTVrUFJo+wrDWdM1SMSWF/bXKkZzFKGx+VXHdURnYgK oyT6CvjNJHjYMjsrDkEHBFbFr4s8Q20UkMWsXvlSIY2jaUsu0jB4OR+NcUstf2ZFc4/xLqo1 7xRqOqchJpiyA9dvRR+QFYVw3zBePl7etWUXAOCM4z61XmXL7l4Ldc161OKikl0JHRgOEQbV D8kkjp/SnIEkljB6jJLY7HpzUIZUDKDjHHIz+lSjy9hTaSzHGQQP89atgOQRCdcBkAAxwcKe 5/nSfu1DCNSxzgEgE5/wpoxJ8gyucEnGOB+P/wCqhwuC6bmDdCTkn8/T1pDPof4MaR9g8Fm+ c/PfzGUD0UfKB+YJ/GvHPiLq39p+PdYdnLJHP5K4PACDbx+INej6B8YPDmj+G7LTvsWoK1tb LGvyqQxAxyd3GT7d68QupnuriW4l5eRi7EdyTknH41T2sSJJORjaN3PUjr9RTkfO3eFG3k45 z6ZqMQyZPG/0xzx7VFtZlZvn2qOf8miwyyxJclyxZuB14/lQsalpWThQeD0+p6/1qBWAYc5B BGcdDQQcliTgjqOM0rATENNIWl5DAfN0x6cf5609fJSJmMjsWbA+Xj+fFVlPlnIIBYYAB7U5 pDgZ3Ed+SefzoC5MkbL8yoMPyAD1x/hV6PV9SsnfyL+6hIUY8mZlC9+uetZgkKjnO3BwAQxp BIiIQN2WII6H86AOwsfib4x09WEOsTzRj/n4CyE/99DP61H4s8da94o062sdTkjMccm8NFHt y2COfoCfzrl0lZ5lxtYE/d2/5xWtqDIbRyeCcAZ4K09QMJUZfl4BIzn1qaNQSxYYB445x9ag 3jzBjBye/NTxjK8fNz3HBoEOkG5SwIJbuRwOf1/SmnBRWGQoJLYGMdPxIpo5+dVf5Tkk5Ix/ WnNnB2YVWIIxxz/QUhkjfKV2AAMOdw49voKj2ABiXJOMkdf1pXPz/fJVwMDP60jSKgCoTweh XI+tAEksjsgDgZxhR7e1R4ZGBJZVHOAMfTmlVhG+X9sbhuyfX0pkh+frzjBUEgde9ADpSDIz 4HBwfmx0pCgljJfChWzgUhk3qAMLznIX/PrRlSdyqAqjc3HU0AISEZQuOMkkjP4UE7myDgew xipGWMkZUBwOccAfWmp8wz8v16D8u9AEZ3quTxxgjIx+FJIQ20nJ7HBp7Mm5o+Pmx+FNAwc7 wTnjqD78UCExyfpwDxmhnAGF+9joeaUfKxk3EDoDjPNJtbeG6NjOMdRTAVgOGyRwPzphUFSN o47g9aMgsDnp68UPkDG8ADqFFIA2gAY+7j8abtPXGR6ZwTTwFHQg4pDl8EEc+/8AKgBow2dv BpTtz83Iz34pc7D14xj3NNLY5OCfUigAcZPQegA6UH5eNwB9BQN2cA89elB4Oe596YC5DDlt uBilwRgHBGO3JpuR93p+tBOAOnpwKQEw3Ak5OQPpQQD8zDc/GfakG5XIUgt2GBinbdqnPyt1 I9akBMHGenHSnqoPtSqNxw/PoKcw27fUjsORilcZGRggHB98U9tpYbB9c96UMw7bjxn2oGd2 e5680gAABh/dJx9aeFDsSTnFJHyCpO1venYUjaADk9hzSAB94Hjrwcc08Mxblu3BNOClUBbc ccCnIFKkY5HQGlcB6NkgkkZ6jpSqwVD8px0IHamoF8xh8pyB82TxUi4YsMrgHIIyM/hUsY5A ow3ftz/nFKARHtwAR0BHJNAXL5O3BPIPUe9KnynqCV5HFIB6vlcMPl6Zz0p0KuGYhgp6jjmm oVVcMevbHWpAjxrywI6qaljAAIT8wI9PWl37iXxl8ZIJ6+lKi88A7+QS3TFOLgsCo+YjPXmk AoBYg7uo6AYzSuu8lmLY6njk8cUBiWASEhwOu7rmpcjcseFX+EoQTjntSuBAQ8nDM2COuM8d aUhGG1Q27sx54z6dqcygvtJP48kn/GlGQo+Un5vXO30p3AbGih3Ln5hg7m9f50pkALMEVeAM twf/AK1OaMEyIQVYcnrk59aRkVVU5CN0IYfypAVljkcjaQhyeSf8+9HlbQdmGRj93vn1qVlb lAThTzs7Y70qsrtkDag4BHf+dVcD034Y+CEux/bepAyQI222jYY3FT94+oB4A9Qa9S1nWbLQ dMlvr2QJFGOFH3nPZVHcmsPw94k8PWfhKyK6jbQxW9uqvG7hXQgDIK9c59OvbNeQfEHxrL4q 1CNII2isLcnyg3VieNx9+n0rylCeIqvm2K2Rn+MfGOoeKrpnlldbVSfKt1OFUe/qfc/pXMb+ MhwCvX6UjkyfxE9qQDOCuBt44GM/X+devCCjHlRF7lpLkSRFZSTyCM55/wAioZEOG7ZPcUwB +xIkxyBUsdxkbZW5zhgc9eOpquW2wFUx54FRMpHatQwK21htKnuvYetV2gwSDkn1IoTFYoYp 8Y564qdoG6gcURx7VJYYHY+tXcVhruY4TsI59T1qspJBIbDdyDgmrF0p2rtO1VPY1Ai4EeFB DZ+8P61pHYYqqdjOeQOnA/WnEuoDFQrEckL39sU5lCqTuJIBHHUfWlc7ldEyXzycYz70rgMj DhxjHORtU849KamN3mY+bJIIbGP5g05XYR7lB3HIYCnypIqLuyFACjJ6n/PFABGPtTxoQ2wd efSra6dCzk5ZewBNQ6cmCzAnauPlPek1OQiZNsmwgc59etNASyaaeBHPlCRlSO38sUz+zZHc khVXG7BOdx/yarxzTxn5HYZ+b0zVlb24jIDDegXp2/CmBDJZSlX+X5ieg9PSoWhlX5mjJxkb SpOB61eGoyZI2Hg5yvHtk/rUsOoDLyDg9Ac8n0pAYjREAFs5A9Bx9cGh1bIK8AdK2RcWsvDL F5ucNuHOacttahiuVz0GDgj6frTuFiHRPD+q+IrqS30mxa7miTzHVSqYXOO59T0pdZ8NavoE scWpWU1sZAxXzOQ+PT17V7V8EtEW2stS1LBAldYVz7DJ/mv5VyvxkaXUPHHkJJ8trbIm33OW /XcPyp20EeZacpe5DDKgc5qfVNywojEE5yRjPFWrSxlic72TJGByc+tU9QlX7Suc/d7r+Rz/ AJ6UgKCALltvGeDnpTzJLhVLHcFzx71LtAQhpPl78HBPU5qNldyh3EbzwO2M+tAx0huFz83B OflOOMVKq/KcrliMEZ445HPamNsjDAsXk5U56D6etNV1aNQTtUjCkfSkBIG3KEV9uBt55GKY rYDZUqejN1J+gphiZj+6AIzhRnrUssRG4uVRi2eOoH+RQA0M0ic7mA5POf0pzF/KyFCbcnGO 31pGw6qHds/eOOhPTj9Pypsn7pt2SCxwCD39AaAAbWbIdUXOQpxjHfpTWABzg8c5Pp0xmnRo UTl2BORnpzTc7HAVijHnaCcH3oAHBBJC/KRyp5z/APXpCWYKr/eHqOnoKkDCVCAxBbgqD6fW oQNxb5xj7oHSgBXGZSQu9SfSkcbnbdtABwCDxS4IXGckZJYZNIWXyD8vOB14yaAI8Pv9s+mO KlUDBwSCO+D0phwQFMfJGM5zTwwLDJI45yfShiIz1BUbR79qVyCgGc/N2z0+lOZhIFJ4X+dN bcWIxg9SfQdaAE6EAjB29BR82eOh6D0pNuPvADucjmgFlVvT/eoAQLtwuRzzSnLHGMDqKACF H8Wf0pc444yOwHSgBmfkwRyRkmnLkHjAB6YpPlzlSeB1Hanb+AvPzdfemAjEHaGyeM80EgNk cfU9KUp8vBx6U3JduMjHGKQEqggE88Y5NKSOMZY+pFGCq5wCfanDBC56VIChcZO7AA4FAOHB Ixn1NNHzAgDLHvmnkDhuemMYpDDOCMHJIyOKfsBXIz+FNH3gFzyfSpCNpyCQKTAFVDli2Kfy fujOfamDABYg56inqPl9B1GaTAUEgdAcn161LlQwOCFHvjNRqQTgnHrUgGGx2z19algLGrAZ VQQeRjvTgoD7iMDninbSQGIPHTJp4TcNwxxznmpuMF3E5Ckg+vpUhQ8bSTk9qQBm5TgAYwTS rwvHLe4wfwpAO2gqAzHHX2pyqpwVGcAZHrSr87AAdf0pwBJ67s9Tn/69TcY8xgAAP8+OV9KE UoT8uV45x0oA28k/K2Op70/YHcbmxkdsY70rgG3D5diOOgGTSMpBDHpnja3P8vpQg8tvlyQf Uc1Lhgd7+nCjHOfpSuBH5gKFWfAzgBR/nNKFbcWcEKBhsDOPr+lOhXy48ZxzkHNNQhQx7tx1 ycfjQA5gzEbB8xGDt5BBqMLuBO0knkk8D/69SKud2/Bcj5SW71ErLGCc5ycE4zTAaPkZk6gn 86GJUhmJOQRgdqfKgVSg2r33AZJ/WoJXcJtXG0c7j1pgRPuBAXr1PHNV3w38WP55qY4fcWPI 5FJEjSMAoAzz9KtCIo4myFVd/PTGKtR28caNk5kbpjotOVRHHu2FmTruzjH+FV3n5OwHJ744 xTu3sBLJII8YOdvUp1qtNnkugQkYxjb7496ZjDB25XOMYwakKK+CwO8cBepPrnvVJWAQuY1Z VwFXpnncOKlScJKBMmFJwQp6VG8GwBn+5jB2ndigDLHfu2hvmCkDA78UaMCd03oQWAweCew/ wqNY2X5sZ2jp0qJo8sfJyOchS2CaassqSBSA5IyF4wPx9frRygRXEmZmDtk56ds/gacIZNwL fcBzg84FG1DtDs3JBA/+vSucYJVt27v1rQCOZBAjeWxx3LDHPr3oidw5/eD7vJByBmpRKxZE 2DecEs+DTGQZ2liGPTAzn86fqA2Tb5xQIVHXDHn+le5eBfhx4e1nwNZXeraaHurjfIHWRlKr uIGMH05/GvFoIHu7qCFPmlllCZIzkk4Hf36e9fUt55XhfwVMIOEsLIiPPfanH4k1URM5R/gz oIRxZ3t5CW/vFXx+gP61zWqfAy7O9rDVreZi2Qs8RTHtkFv5V59a+JJ7OH9xe3ducADy5WU/ jzV+w+J3i6wBEerSTJ/CJwr/AJkgn9aLoC/c/BzxbbwsI7a1uHwOIplH6tism8+Hviq3IMuh 3hC/dWLEn8s10Nr8bPE0WFmisJ/9poWXP5Nx+Vbll8dZd2L3QgV4+aKbBx9CP60aBqeP3Wl3 unF4r61mgm2/cmjK47d6iXcEYPn5BwSM5/8Arda+hYvjD4UvF2XUF1HkfMssKsB+AJz+VTQ6 18MvEP7tjpQcn/lvAIWJ9mYDP4Gi1wPnQmLCqp3sDkY6t9fYelNKtKC0hKgDLApzx6V9DN8L vh/qgzZbRnnNteFvyyTVS6+B2jSkm21a+jJ/vhGH6AUcrC50Hwq0yTS/h5pyzjEs4a4bPoxy v/ju2vB/G+rPqHjnWZ45GdBcMibTkEKdoPX2r6WvWj0DwpO6H93Y2bFSfRE4/lXyKZmHzIcb 2y3fj3BpyEiZtQnjj5LMnq3AGaiZ3nkaVlDZwNzcDjikyC5IZmOeVHy5PuO9K6sis27gAZ+b of51IxCRlgpViBwDwfwxSNKyLudAynKgnvj6U52UooCHOcjjj+dMZnTBIOH7Z7+gxx+VACuA qEYBUgDIPAPr/wDrqMEKMM37z+Hrnd/SlhOWGCsQYHjPP6mlAygRycc8AjjryKYCD7jySOc9 BxgjvxQSfLOMEADLN0PPrUpEZCtkg9S3f8u/aoR8oxuJU8NvXt9KQBskmUbMgdTg/rSFQTtI CqDxk08FkYszqzFcDb+lKq4A3Funrkfh60ANbaqFcZON2T/EPekCEjKHGeMDoKTefOHQ47ke lJn9225d3Prjn/CgB5cAEg8c8E9fx/pTFOQ6sNzYySakVcxucJtJyd1MZ0iXgMWPyk+lADVY qFGcoR1Hf2pMFsEfdzwAaViAdoxuPQCnHB+Ugk9flNAhgQA8nHJz60pId9yr8ij1pgz5nOQS eoNKoD5UEjvQA0AnIY4A5oPr3HXNSsSr4/A/LnI+tRtznJ+buKLgIchuSSe2euaAVyCOD/Ol JKkE7cUnykHqF6UAIMjI5AJ4pc4BwAT9eD70L2T27UhwCQCeB2OaAFIGT798dKNgyApDZ6nv Qc4B9Dx0pG5JDAZx+VACAHacjPOetKoGMr1pedgBx17npQWbaMHn+dMCZRksOMDnmlUhVGD9 D2JpGwuMtn1p3TBcAgHpUDAbSuB+OacFOVyRj29KaEDHt/WpBuZdu7J6c9qlgBHXd69fX8ac uBzknI6DimgZJXuOhHanEBhkDrSAUBiQT09qkCEjj6A9jTUG1vun3HQU5GJB5xjpSYDwuWI+ UZ/HH404BTgDcSOncU1UIfnkkHBqQKT0IPfI7VLGOUBmLHnr0pwLKACCB3GaUNhAuByccmn7 lPIzu96kAC5Poev4VIE2sTztPQHmmIWL56qR0J6+1THPfJUfN9DUsAVehOcA8YqQkcFtuOnB 5puAeSM+4I4FPUABipAB6Eg9fSkxjVAB45PringMrbjkDPFOB2qOcqT2pyFm+6RzwBycj0pX AXa+ScgLxgbuTQ/JJXJUnnGR+FIxIPQhfY0MqhSuc85wp6mkA4krIS6g5GOBz7UgyrHgZx3H f2pMcKxYEn0pxb5dyybmzyOvPrQAwQkSLu656DgihwgZnbluOFPH40MxbORgnk04qpUD+Lpt zmmBExJYk7AW74z/APqqCSMdd2fXmrBQhl34B7cA0w7VIyQW6Zx0/wA800BCsO9TtO4d6skM iAcBj39KekkeGXaQMZGe9V7mQ7cAlucHIyR+NPVuwFWWYszKv3iRyR3qJIVyckjB6e/4dalE QVSrDI3DIBIGKciiQ4DFQehI44rXYQxB8rhQAA2fm/wpfmRAmQTjAHQ/41IkezJaM9cDBAqO Us2Wds5bB560AIzBZSxVCC3RRnbSASOVVEGMht23qR0/DilQSOVBK7M5BOPypzp8o8pSx6dO nsc9aYEUq+aGIXBXgseM59qbGEUkNg4BzgdOOtKEKgghSDnr29e/+cUu1SyuzIeTlee1UA0D fEDuyinGQMkH1x9KjnC+bwB2APangMzBiGUKeAp6H60chhkknoOOuP5U0Awna24AluvAOATT 1SQRtIGQ59eTmnSH5ugypHykjp6UiqCnTGTjnn8AP0pgdf8AC7R49T8c2e4lo7fNw6nvtHyn 2+YrXqPxi1kaZ4La2Gd97KsXHUKPmJ/QD8a534HaY4bVdTYZQbbdH/vH7zD8PlrF+OettL4i s9LRh5dpDvOOu9/X8Av51a2Je55r5yHa7BiUGACMfjTAGRJTuGw8gHqM+lQR3LgH5/rjv7/5 9KaZZNpDENkcc/dFKw7lnMSfKFHzAHdnj/8AXxTFklESjcMF8EEZIP1qLzGfCuxIHTJP509X VkYfN8oI5agBxkBDLgKD3RcmmxjZ8ykHHUMMk57deaTeNowg44G49PpUeQijAA6ZWnYCdo2h kLRllx8wCnPPbjFWYNc1qzCtbarewjIz5c7qevsargBVyBhi3Ayee2eaY3ybcAHn7oHI/Ht9 BSTA6W68c+K9U0SfTZ9SmmspkAfzUTLAcnDYz29a5R/lbbt+ZT16fpW1ABHbgnkle/vWJPJ5 ly/bJwCDTEPiDAglAeMc45pASCVyDkcAEc/0pDtCmJg2wHPpg+9LwQAo2Z4Ht74/z1oGKQSZ N3zHd/D0A+tJGIwUADE9GYtyOf5Um9tnl+YQGIJwe39elKiMD8zAE8egx7nvQBMGXzGUKAxJ JYnOMe9Rh5FIdJFA57Z/SmspY/MVx/eI/A8UqqkTNIuSCDkdMUgBHZjtUEdVVsc59aTy5GCs mQp6bu4FOT7ueHy33d2KapxhTkY4XrgUAEe7ILbhgZPH6U3DIzMMjGThex9qQ/IVOVK7uSBg mpXYZx0Y9cevvQBHltodVOc8gr396btO7I3ZI+uKCWG/LbgeeGx/OguWbbsJ49cimIapKOcZ 6YFOMew5IyxGeOgozuI8zcxB785/ClYsQcsFPt/nrQAYb7zDORzgc/lQpwwDBcFs/L2pCd+B vxxnr3pFXczZ4756CkApzuyQMdQccUKRtLYO09j1pp+Vgdm7dxSPhyCGOfQigBUbtkc5x7Uf MI+nPQ008ggk/SjGec/QnmgBoJzt5GPUUuQDkA49qflwQQQARz7U0H5SSSSe1ACLlcEnIJyP WlJO/hsr0I7UhXgMck9KXjkZAX0oAMngcbc9qaeDgE88g0oLbMA4WhVGFIJz1FMB2cD5+eeP 8aYVOfx6UowMBsA+pHWmktknPOaEBYKANkfMo9aecu2D/wDWpq5AAz+Hen8DIRSSB1J6VAxV O0HHI9cUvJ/iO7t7UgySOD6sacgPDEEjPpUgBJVsg5zxinqAR/epv8eDzx1NPOSNoApMB456 N07elOwMkA/iOKjUbjUgIA2jjtk1IC5C47E9cVMAFX7vBHYVGmOd2D7etSoduWbp2HpUsY8D KkkEgcDjpTht5AwB1z1pEBORjAHU5pVxwAOAOTUgOQeWwLEjPUA1IoJDFcgA8+hpB8y5zg4z T07sCCB2qWA6ML3YEH9Pen5WTIzsA5ANNCkHJbBB4FPU7TuKqcc5xSYx+xWUKxxjjk0H5T8n r94HihcMWL/p60pAAUk9fXn+fWpAdHyGUgAsM49aRX8vgKSBwe4FGVJwBuB55GDSLnnK5GDx jigB6KHOflXjb3pANo4KtzwPehgcgbAB7jFBcBB2JP3v89aBjCMuykBeMAsMUoGXCk7hnOQC QKbkeZkJ07DnFKH+UqAowBuJNMQ2VE2MQR1z9KAoBDsGLHgsx4xg88U9vLK5GQMdcZNRb02/ fAzw2B2poBoOCyhgCTtJPOPU1FsO7c48wHk479uKmaMKFYyDOc/NjBFOZkZMqBljwQCB+pqk wKzpG6HeNuTxnHH4UhVQCpCg5JyxznrwKl2AR5MhGeR8vB/GhFLAu/IxjGCc/wCcVVwIAgMZ YgkkjBY80nz4XggYXJboPfjrUjRgBgM7uM7zjg96buIA3Mdx6AnP4+1UhEcgEmdz8g7Rxw3v zSs5KsgQYJ5GaR3J+XaAc9G5J4qTAmKR7B36A54+lUBFKikIEVmJ49+n8hTtjPkoWOOhTpu/ LrQGAJO4hhwNx6ijbtDOCQ5HQjjGaYEO9tm0HgEFgM/1pwQgBw/lsTxycDp39KHkdl2EnZ1J 65p67EhTf93POVzVAIzLt3YbI6HPNMbyzs8w7ccnuc1LI2MEbhHxhsYqWxtTe6haW0DAyTOs ak9SWOP600B9E/DbSP7G8C6fE335lNw3GPv8j9MV4b42eHXfGWqXqtvDTmNWVuCqfKP5V9C6 /exaB4RvblW8tba2Ij9mxhR+eBXzGT5UJbcSQvf1rRkkH9jxgKRLjcOnt7VDLo7ruVWDsPYi l89/J3IzqoG3OcdfU5qQXUqSgs28YzgjNIZXk0mYMmfn7gqP6+lV5LOSMbgjNGO4Hv8ApWm1 /JJIHKLsGAWBzxUq6jEWETx9DyRz/WkBzzxsH2uCBx8rdaVYzhmboOgP6Ct5rq3OY2j3beWJ HAFMQ2MsxchG/wBnJGPamBiB2XkfK2fxpEAMqrjBOAMmtz+zbeWF5AdpyMMnp/nNRnTYo5A0 bEjdn5lAJ9uvNAWFuXaOBmfLEDgnqaw2CkA4wASeDW1qkmyAKdpLkDAP86xzFMAHXIz+QoES x43gdMngqDwfXmlVFWT5CQBwGHb3HrTFEgUqpCnGd2cD8MUzLSQ5fBROMjHf60DJ1CY27A7L 831GO4pdhljIH8XcDjA5qI7TjYhTK7vyp8JLH5SSVUt92kwBnHk54TAOFOcHHp+tRpIrLlQw P+znP+e1KCX+XOWGD1/zxTQquM4KAZ/i7+n+fSgB5L+XGASdv8BOce//AOqmrIyqXI+cY69R +tO6bskttAOD0PSojIzTAEggnhR+VADkXYw3IFbHAbg/WhzklnwM+nPNOyu0qG+Y9tuf1oBV o8lsknIGf6UAKVKr1xgY+YcY/lUe4nC5AA5Kk4xQpDABu38WOtN+TecsNq9ye1ADyNy4BwGw evSo9xHILZHvwfxpWwOM4Qj72MZoKqAckjHQ460xCBcqRnDE9AOvtiiQ5YA5JHvjmnMDngcg 9uvvQylsYJY9xg80rgNLEn92OccY70zcAxyOemaUFdzAjLdvb/P0pQgYk5PpwKYCjZn5TgHn Poe9NKqTlSMepHWndELY49cd6THy5PH06UgEOMgK31GOKXBB4G5T19aRgyncMhe5HY0o+62N 3rnFADVHXc+CPWnbixAGB6U1l4BBHrg0qsQSWdenagBOc7WGOOmaRQSTzg+uP8KfyzFscD3p rYD8k57ZOKaAQEBsYyAeeKDnbjBwDTiCARgYoBwemeOlAE2NrHr9COtPU5VieCR34oD84HJA xmnA44HLenas2MVW+QnJUkce9Kv97ggHHPem7fvAHAA/i/pTlByAeBntSAXq3BzgDoM0/rks f17U1SRkDqe2Kfycc4HpipAeDjHGc/hingKMt0z2HNRAY49OvvU4YZzjGalgHBfOO9SIqMRu OMnsKahJ6AcHrinrjcQSSB14qWMcuT0wOeKcudpB4z0FNVtuNoI+op6g4ByMnuaQEse4IcZO MZpUGT1OAcc8Um7oBz68U8ANnb1HqKgY9AFbO7t19KeAOWJOCecCouSoAGMnHtT+W74x0pAO AXPUnPqMU7q207sdeB0oJ+XJ5Pfmnb8Ku0EY9Dn86QDQMvnJO3vmnAkucAY7Z4oLM+ATgngU hBUA559TyKAEcMck849BQuOTt5x36fgKeqsW5PGTzimMuwEKflP50APyN4yAe4wM5pAVaTDZ JIz2/LFIMErg9sAGmMNxzleeMDtTGDSuH7k49PwpNmEBGcgHOeP/ANdGcYUkgEZwP501wIwQ qtuz37UxCyIZAGBYjd1bofwquAWztDEHjgdalLbVKDcyn2/lS7w7jByp7EdPrVICPCkEMoAA zgcYp7lQuN20gZAx7e1NxHkqM8joWPX/AApgKRjgM2fvduaoBoVpH3s4Jxkk0gLq6snKHjIP b8f8KkVQzqq454xjO0fjSMWY7PukEkn1HaqQgkkVnUct7Yx346dK9b8M+DPBmq+HLJ7y8hbU JE3y+VeAMCTnG3PGAcdK8iG5MOu35l5B6/8A16e8kihWOMYx0xzVxdgZ7TP8GdBmG611G8jy O7K4/kKxdR+Ct+ozp2rwSk9ROhj4+ozXmkF5c2zqIbmWAZJHlMRzx1xW3Y+OPE2nFVt9auSe /nt5o+mHzj8Ku8ewtTSu/hR4piBKWkNxjvHMucY98ZrnLvwtrthIUn0m+j6ZcxMVPtnGK7C3 +LviaFQXjspgDlvMTBI9sEc10Nt8aYdifbdHKscZMU4P6EDH50/dDU8ceCWHCFWVskEkfMK7 L4U6cmoeNYDIhZLRGnHORkcDP4kEV6EvxV8K3yFLyzuVUdfNgVx+hP8AKtTR/FXgVZWm0+50 6yllGHJjEBbvySBmqSQjN+MF6YPCsFqv3rm5UMM4+VQWP6ha8JvJDsRBnLnpjPFekfFPXYtT 1+1tbW4jmtbaHcHjYMpdjzyODwF/WvM73MlxsXeHHJyeB3oe4IiJBBO7bt6IRx+VNgKtISSV yM5xgVIsfyDcp3deST+lCqOQuBu4BJ7/AFFAyKdQuG3bQT0NRDLjGQo65J5qV0ZfnkPIGASM jrQWHVl6KcEevr/9akAxkXavlkOcbiD/APX/AMKYNgfGcFvmO1QePp+VK2SF3ctk9sUxVIwz R/d5HGfz5oAA0oRmDkIGxgnBY9qlFzKoIWVmA+YZOPamyMWlyhAB6A8BaiEXmzlg4Zs54O3m gB89004RZdpwxx2/OoHVjhZSo2EgbT1NSPJIyKGTIBxjOP1/rSMcFyFViOOOdv8AOgCNflIA I246lccD6fzpNzsjAKfKJCjB5J96cCZGAyXwOgGAB7Gk2qRkkqEIwSeg/Dr2pgI5VW8wN2wR j14qMtvAUcqAPlHBpz527mY4JxwMf5FDsAMOcEYIOOv4igAJ6nPP3Rzye9EiiUkqdynnJ60R uqqQ2SGYAj0oaUByFAVe3AP40AGflYvyE6e9MkVQqgHGegH9aCfMPzJuwOCBj60rsGYbkXno P/rCgQbiTzhi3U85H41G24PgfNjvkipAoDEIBux/+qjBLgEfUHjBoAamem70560FCwC4yQcd KViSRzhB2PU/40gKq2dvOT+FACM7MPmCkDuKUg56nHY9aOpLYKr39zRvaNQv3cDoRQAibwpR QMn8eKRgABzxjk4zijO5fbORkUrKec85zjFIAXIGCMDsc/zoL5bgfUZ60mML95T9eMUZJwwI BxzQAmNyn35xikwqHO3IpCSQPu9elKSC2OOenHemAMRszglTyOelLuywyeKaCduFPHbOetOy R68c80ANwCSOMjmkzjJA+b6dBSk4TcvHPWnFVHyrjpzk0AN+Ypk9M9AMc0E5G335NKAcnnd+ NJuX0YZoAVhhwOCOwNIRxuXqPSnhScAkfnTB8pI6CgC4quBjHPqfSlXaGwe3cd6ASc5AJK9R RkHjpnr1P4VkMcBvA5GB3pQBjaMnvikH8W0Dj07U9DkAt0HUHvSAcMBcqvJPSnggj73zeh7U 3K4HHQcntSgkIPTtk81IAqBT+hOKkXqSB9DSbSAcgkHpTlUY5AJ7UmwJc5xz0xSKRjGM5NGM LuY59Pan7QTwoI/vdqkY88tz0H4VLnaSN35d6h3ZCjGMH60/5cYKgdwalgOzn5jj8etSgnrt 79aZGct1A69afj5PmOMe3WpYC5xndz3GKcOQo7etJvwRxx6GjIxhCGHpikMkzvYLnAHXJ7U5 Dg5HfqQabgDDNg9sHtS4PQA9x0wBSAdlMe5GfWlKqwBQDnrnnFMjyz7lHTqc8UhA37WyvOQf SgB4AAH3Rjv1ppI2g4GQMcCnZ3BRhe+D6+9JkKcghuOfpQA0MFHIHA4yKOcktJyOnX9Kb1+V TwfUcU7sxyOT1NMBQvmDJIUHrio8YJXAIB5BpTloQqpkZ6+lIRmMqCeDkqaaAR3UwhFJK9Rk 9D6VHKAuHwCCfxpznhWYDZ0Hpx3p22NgBkFm79/x9qpAQk5kQ5JHAJXjinGUhyq7z260E4LK /Cg8dh+VIFdcueh6MT0qhCBtrEqNpFNVgIzvHJHp0pzMgXauMnBPtTRsEYCgfd7n9apAOLAy L5XyhQcdyaeY1WI5cFjt6cfoariYsoUA5HBxxx9KWMgjIzuH4mqAkVQ4KEnrlQDjA70/YsXA Ybh1x3qCOZCMcYPct3+lOQgsu7I28gEZqgFCqMAAFu4FKFDk7+nPzN60ruW3ElgSORjjHbFI HDqFLYA7DvTEPGCSI9yk9wf/ANVQXRXaAeD/ALRBqYgFm+Yrxnk9/SqssiyAJ8qnOBnqR/Km BbtY9iDcxGck98elVnLTzu/Dc/eH9fWrYbyomcNghcZ61SjLeW24YPQkjPP+NUAOHGTuy2ep Xj60nI4KkY9MEZqYl4eoYk9QeDio5SHQ7XI77cdaAGmONGJkO5yfu8giondiChiKhsZB5z9a l+cKQzEBerAZOPSmOuUyHbg/Lkjr2oAiCnkbwrr254psjncyh2aM8Mc9cflUjDBGRliccjnP v61GE4cM2zaADnkUAJ8hR3XJKtxz97/GoCc7PkKhjkE9KsF5I4uuEJwCeeKhWNMDcygg5B5y fwoQCFiwwS288c9T+HXFNlbAIj3IAMHJzn2pzhiQu5MHncMjNM8pWIRjtwO/SgBqAhTuUFsZ +Y45/wAmnRgHnlGI6nsfWlbKDy0ICnuVOGprLhQ7sF4yMfxUAN3FlG4sXB6tnj/OKayfKQ/U Yx6VIUVydjHBHp1PqKbkKQQw+YEHK8896AGbsM24k8YGOn5UFmkTJHfKkjp60eYCTuw2epcd f8/1o8sK3JADc4weKYgSQBmwc7vlJBxk00sSwHXHXPXNOXMj9WKk4GOpoJCjbznPAPGaAEOB 85cHjGAKRvvdRjr/AJxQuSvy5JKkEA004BztJRhgY60AOULlGAGe3agnL47YP+f/AK9LGC7D zBwOAKaFO7G4bR70gBQwBDAEgev9KbjcFAByDzkU/avzZA3Y69jTEbnBxu78ZJpgP+XGTnj9 KRlIUkEEEYyabnkKTj0PrQoAGB1I+b2pAJhgm1huGOMCjqMAY9zzSkZwB94nnPekTdtKkfnx TATb82Cy8egoK5IBIyKASJOvbrntTwMZUdcc49KAE6gYb8u1PVRj7wLEgADiosKqnufXHNAU nDdR7dqVgHFRk5wF6AHvSfKx5XH9aM5YgkkUMuTkDOe1MABUYPO7644oZVQ+qnkg0Bjyfu4H Y0hAZPvdKAFLEZxknoBmlLbRwcHHApMZXG4gcAgClXJznOR7UAWVyMA5A7k8UoQ5yOV6Z9aU EEkhgM8YB4FOA3Z2ldueBWTYwHB9vTtT+mDjryRTB8wwMAjjNOAO084HQ+tJgS8cZBz+lJt7 sSSe1NI4GcY7HOaep29xhe3rUgSnGSMYHXjtQFYlSOecUwA9D09jmpQSAQQKlgKqt1IOB3PQ U9ThhycdhUaZJAOOD2qQAnnt7UmMkCkcFdpAzzzUmQJCXGR1qMMQVBYHHtTyozgE4H8qlgPy o3eh9CaeB8oBwBjODUWMyZOeenvT8Mo4wB0qQHkkdAScZ57U5W/dnJx7Ui5PBG49qB0wDSGO ztAGTinAhjkLjjHHNN6le4x1HrTlyc9SOx680gFDbRyfwoG0fKD26+tN5dxuweeaUgBmHO7G QM8UACnDMM5wM03DMBgE8Z59KUk+gHegH5jgZXpkDFACjjOMMcf5NISqjqT6/WmkhQRjP05o ZicAHgf55pgGBgheSemeDTC2SOgwMYJ696kJPmg/Kdvr/npTCwBztBwcYJpoB2FdAWByxPAI NRE9Adqj0x270rH96Rj8ulDr82Qp6dzgVSAZnLbRnJ9etOULgqCrN6d6YNg5wdynn/AU5FHm EfLkj16GqENQpswflbk7gM/hQrK0QJAZugyDzmnMqgnzCVGONn6d6blSgyMNk4z3qkAxkZgN ibcH5iMGp7eOIp85XLHAHORTB8wQbtuRwOwFNYPh8kbT1we9UgJvsERGQzZzjr05/nUb6eyq VQ85xTU2MAMsOfU809rh0IKu23g/MCe1UIg+x3UecjK4/vd6iLTx7fkKkcACrgu5zHztIzkE 9aV7suMtGp9+eT+VUBUNyY8B049waihzNcAMRgc9a0TPE3yFSQeMsuaeiW6nKso7E4x/+umI juN3lqBnP0qBs7jkgYwSMdakvAJJ1UEY6/LURV9xZsMVPXtTGKI8xsFO5sf3uRTHeLgqDgDl cUo2KwC4OT0P+NDM8bbVHTsGyfwoAR1w+0YyBnnOTUKplScsuc9BwKl5w2T2xxz/APqqB5d+ FJyOnp3oQDnIdRtKYJwTnkj6VG0RU/P8ozkL1OPwqSVxGdpz8oBGOAc1AWLSDzB1HQkDigBH DAAM5xnPXPFRyNgl9nAOMnNKwV5Ci7iD19qGxGNgKuP9oCmBGCsinO0MBxg8YzRsUJyCTjqO 9OC7twIUAHjJNNJJA2kEA4460gG7VyQZcjoNwxx7U0kEDAYk8gZp4xjC4IPTjGf6Uwv82Cih gMdeKYCqXH3hyTkYpoLMwHTAz9KVpIymxclhzlv8RSKNy5DHJPOTSAMsSXDDOemODQjBslz3 4BH6UjZIDnGeCSeKjYmQ4PC5446mmIWQ4IIwOcjJ6e1GdyEjnA5AJ5pSAACud3v0+tR5ABXP IHG3oaAJgGZSoC568fypjELINytkc0rADDNjcRxhqChABYY/hA3Z5pAB2gFvmK/XgUwklCcg ntz0/CnoxZVDMTgYA4prhmOT13Y4oATIHTH4GnZD55I4/GkwB67elKcAnHGM8jmgBrAF1Azm jPbOKQthvvYJ6/Sk2AkNkke9MB23EnTIPQZoIx1BOeMY705QCflJPGelNYeoODzkHpSACU6E nOOmOlIzDYoyTSnk5VievakBIHc8jmmADA6EnPA70u0DIy3I6ZpHJCgjn2oz8+QOe/FAAuWG GfGPQUE8c7h2oABA9T2IpxJLcHHy4wKAGE/ODyM+tOClc559Pek3sz7sYx1zQcOTuwffvQAg Jxgg/hzShGOcZ4GQCKQZDcDGRTzgsMnCqOpNDAsqrAj5s/7wxTwducAAg007STt3YHSkON5K 8HHNZDJ0JGMhTjspppDb8ZGR1x2pqnByf0pQzDoc++KVgJEXIwBz3FOwc9SQD64puQCSMEel O+8On59KkB4O3jgj6U9eEJIPPemBs8EAqKcozz3B7HGKTAkxllIPUflSjgkdDTUZhxnqc80/ DFT/ABfQVIx4xkfN+OOtSE5UZ65qNTtXnuPTpSqAF+9g9/epYEjKMcdjj0NPHyZIwcdM81EG zhexHJ705Rg5OBnvSAlAy+fT15pUY8nOB29qYGbHzZ47mgD8AD3pAPHzYwentTxj7rIQR3zU QI5IOTn8KceDnOe2PWkMXOAQOn509SB97p0AFRndkjPHv0oII6H5vagB5YY+YE596TO4/U9M UFjuyQG46A00MfUr260AOHlkleR6HNNbjpgfQ9aF+U9wPTNLvPmAnG30PYUwEYZIydp7/Wo9 rLjoe55pTu8xiATjgcUhO1W6eh96aEODr5RUFmJ9RxSZZiTxlemBikIBA4wB/ePB+lNXO9iz ZHc5zTAdjajNgsM/Nx1prIzHqvJwO2KapA3fMxB7A4zTlOA2cMB03Hke1UBFI7H7/IU444zT gvyxkHG7k89KRygVt3ttyKQlHjXs46VSAcTuQljuz04pEYKjZ5GemOtAwpwCAx5wB0pUdY2y DgDsT3qgFQgL8q54xyQfqaZvBG05wPbvRkDB2Fj79hQDtY4VsE8YqkIeWDYQjaeg4xSM7ktn 7x4pSdu4DjOQcnnFNyEQqp5Pp600AgDFuNuf9qlcgOAcZxzjtTcYyFHWgAJ8ox65qgHKfukj GD36/lTTtZQgO09SWoDYwcH5c4Xg80wsQNvy54PNADtxAxgY78daWbO1BtIP97H5VCWOd2N3 rjn8vSml3ZflDA8cnmmA6SUvuDkYGBjFR8Y2jAA/Mf5xTlYIwZmBPX0NMJzI28HDdCe1ADsf IC+Q3Iz7VEqswOSc546jHvSsVVQAGOe4OKbI5GQwxnIzQA0ANIApbnvmms4O5W3E54LGhkXc nCkY+bFJuaMZK5UrjjNACAjhcAY6nHH40jkgEAA4wTjOKThQJA3HoPl4olALbtwIzzz0oAam GBJJz6duf8moycE45POMnP60+M8uTjB4JAPGKbvDDOCcHp6imIJADGONr59T09qRCH+Ubioy cY70gO1CVz83GcYNO3AIQGJH90HpQAbhk4LDnPIxzTT8rkNjkg5FIvPBPBPU85pFClgvIJOe KAHfxBsnv3/yKjx9Ccdd1P2smfmznjHYUMqEAkHdnknAxQAOW/ukN6jp1pM5YY4wec9/pSMr Mpx7dulIdpwF69y1AApVYzjIPTPUU4ZLEsDjoD0FIvykk84HGeKTqD1J756UAGSM5+7igEqc jBx7Zpd2FKhcHr60nzKegAAwTigBADgt1zQMgFcHHfJp3yN04A7E03J5bgDPAPp9KAFUAnjO c8Eev+FGSCSOmD0pQ67chcH0zSq2CSSSPftSAYCozgde9LklifyBpQcAkMcE444pMY5U+59q YASSMsOfQcUYDLnnPoKQAngjO4dfSlwq44Ge+DQAnHHXjqeopedwAHJ6ilb7oXIx9aYh5Jx/ 9egB2Ez83T+dHDAsCAAO4pNpz6nGaUJuODkUAIoy4xwPzpD8zEJwfcU5SVXA7dxxQeHyBxnk 47UAWxkArggmhVVHAbg+hFB7NuPPqeKcpQjBJ+nashi/KCccA+9PXBIGB+PamHCsMH3waVep OevpSAm2hRxkE9qFbaOD9aQccJk/XpSbTty2akCQE4ODjPYU5cDgsRzyPWo1XG35sZ44p5HT PfoSaGBIPv7Dz2Az0p5YnqM4HGRjNRoR8xOefanfeO3IHfmpYDySwAyCP7uacu3B4P5dKjA3 dM4PWpFICBiCRnvUsY9X4AAyR1p5ztGTxjOKYGXJ9Pb/AOtS71xjP51IAu4Dg575HapCH+9n nqRTVwVyPvYzxSu3oDj60APXBXJzn36UH73PXvTcgZHII680Elhnr+NICQMQOWINJuyMg4b1 pofk9Dn9KTAK5JAP86LAPBYLtVSPXFBxuJAJApjMQuMjA7etGOCOpHagB24g8DIA/KgldoJA 9PxpC20t+WKbjPPPbAHNMY9vMClhn5hyTTMPuAIK4HX1pTtYlskDoBio2OOMZ9MmhCJNu4FW +bnrUeQEyCcDHQ9PejqDwT7+lISOcHO3pxxVAJuwwLPgY4OMimg7uS3PXnvSl/l5UbW7dKaX Vcng8cd6pAK7rgrjGOgx1oYoqq2QW7Y7UhD7/lAHA3Y9aU/Kvv7ntTQCS7WZcsEPc4wTTWYM mDyQeD1p0mwJjJJH96gvsZW4AxjNUmIaCyKUOcnpj86kZkKgoox0OTjmoQMksoG4c07Ix8xB J9KoBwYhQefm4G40uUGYz0J5NRqQmeBjocU4+Xu6sVzjpmmA/IUBVBYHrgd6YcbScBUPG7nr TS5C/ePXI75pHbkKF25HTrTQD/lYhc/QKaQtzkbnP3QpNMIL5GSTx0Hb8KTAA3FwWHYHjFMB Q2xeQR260wSbVGeR15pwd3XIwO3ymojv52kZAxxTAWYFWPofSml1yMscY57fhSgbgcZPrUL5 Vt+3jpk//WoQhfMC4fLHn5SP1pJSJDkKDjjPrT1LMmR3OPXJqMId5G3GTwO4ouMQu5ATPygc DFMxuJGAWyPmzSllXAOTk9cdKTeIxgnPPT3oELJtXHIYkc5z1qLkBS2CG6YHSpAwLFiSH29B UbtmL5eO/wBaEAAHbkZwrdBRuIchRnAxyev1pu4k7izA9sDP50u9txPRTn8PpTAH4fHC7wOB 1/CmsFPCgZPUY5pU4VnLdKcrBojxnqeOAKQEQIJ3bcE9RTiwyd2046Z9KVsB8kYB60xWY8EE Y6be9AClmSTzGU8fxUnDnIwxI/Ghl3HcFwue5oBKnAx83cHpTAOoO4E44wKQkcYGNvp0pvJY tuGTweaX7xHGfagBSHKglgQfXtTGK87uQD0zSsV2/e+gpeCmDkk84xQAqEZ4x1/Shmycbj7Z pGyOB0PYnrSBgF6ndjmkAijqCRgeo5p5BYDnAB4NCH5cn5j1GPWkDHgleB1pgKAOSBknuRkU wr8vb35FPJIUZG3v04NNbOepJoQDzn5W28Z6UhPzFmHB9PWkDFnyq849af8AMF6YB4/GkAmR kAHPHJXNMJXuxYjpjilwWU8HjnH9aReFY5weppgLg5PA9Mg+tG8Y6Ck+XZgNk9+KXIAUA980 AJuY/MFzxj3oYNlsk5Pr3pc9WYcHjHvTVy7cfmORQA7qm77ozz6YpHznoBTsAgd/wpEwVIxn 1oAuYOByfxFGc/McZOcU3gDIGfYc8VIACu4DkevSshiBsICTyTjFSDGQAQM+h6VHxjOQcfpT lO7KgH8KTAcVKjLdT70qrg8Hg+g5oC4Xp9SO9O2jHHUc8mkAuRk8HHrjFOBwO4Uj1zio9w3H PSngNjI7980gH7S/XjuOP508ruGVYfe6ZqJc43HOB6U8YwWK85pMCRgyttJBPrmlGOSeD6Gm EjOcjHWlUKVzk57YNSBIrAEcAYpyEGQ8DFMDAHGMHqacG3H27jHSkxkkb5Q/Nj6ilQAyck/j TM+WBzzmgEHCnk+1KwD9x6A89OacBtUZB+mKjwRlueOOtLnPXt2FIBxZRuIHP8NJxt5POe9N IGOnOKXJyeu7HNADhlSMjqfrStgJkE/Ke9MyB8wI/KgHIPB3dfSgB55Gevrj0poGFDDvxgUi qMHOeei0MScEDAHbHWgBSd3TgDk0wt82Txx2FHUn26im8qeDz9e1UAFyFwSR7UnJRSQx9McU oIyMA5A780jHI649yKYBxgBS2O+elDbTlFPHpxmmn7gC4A75OaZhkZgBn1wOKYD2ByOCeB09 aQ7d2Dk4/OlyAxUk4xg81HkKDzz2poBd4DYUkru6Dihm5yRjAyOc0wDKkZC4HcYyaCSCemPS qELgZ4I5HHWgHCgMeMdPemhhjkDJ9uaJGGcAEkDjHQVQDjkxjPAz27igOqZCg9Mc01W/dkHJ B4x3oLkkDgAj+7yKYAPmfGMjpjd1p7ybWxht2MHNRFwsZXk55PtRk4HJOeR6UwDeFOSCeOAf WlBDKWxwoyBjv/WmL94sdpAGAKRWIXdvOG6g96Yhw3ZBAX5euelIzsQAeOcelMX7zHOM/wAI 7UFhggqQ46elABuCKAAM+5zSM3zhOSB0INMMjBQpPQelK75JGeRx070wFBIVmP69qZvyw3gF R6CjapQfKeBknOaFORj5TkYz6UAN3hl2KCSBSbVZ8ZGF4IJxSE5Q+hzkgdKaX+XLAZxgUAEo wf4WHoDTd7Z3BevJOKczAgszZI4x0NGc8My/QHimAxQcBCcEHOR2pdoYqfm3dsnt9KHeM4IG SeCBx+VALIFOcADjsaAGEjcMoDnnANC4554PY0oAwoyTnnHFG4+WcYAz2FADckyEcj0zSg5O w5PoRxTm+dM8j2poOWzknHt0pAB2gjBYA5Oc80AY6nJFC4fjPTuTTQM5Ixt9M0AOKE5LNn6n Ao6scHp79qRkIXIIoBGwsADjt0pgLhGIHQ+3rTcAEjksfyFKCzxlmYYHSjKbST2HIx3oAQBt g+YAE+tKPkxj5gaTOAFI57HsKcFfc3v6igBGwPutwD6UYJIVic9uM0Ecbs8Hjk0rkYCr/D2J oAcFTGM9R7U0MDllP1B703DYG0D8M80ozwQBj0yKQCLhiDyPanE43YXDA0EcZ4BB7dKRtqqV 7noKYAc4xgHHvTiQRhM7vr0prEq+cgAccelG0nBAyScZGOaQDioDfMw5/nSEKB0z+FGMdv1p Osnf6E0AIWBX7uCep60KvOD1z9adxt3GjK7BxnnHB60wEO9ecH24pMFnHXGPWhuvQ59M0KMA evfPWgC1kk4Zc/jThjAHI9BTVywPBGD2p2QAcZ5H5VmMXsAx4PQ4pwzt6Y9aYW3tgAYNPyeQ Dt9hSAXJ+XnPfA5p6jdISysaiUDIwDzxUuNjYbjHXPakwFU9RnJIp5AwVVugzUZPGFPK+gpd xOMqCTSAkDOE2cEHnApVzu4yB9ab1TIIHP5Uo9c9fyqQJFJZicdKUHj7v/1qYTgjnp6U/Pyk Dt6mkwHgcdiOuBS5xznJHYim7/UBs9h2oXCtn+H6daQx4Y4AY4Bp+WDZySB1xxUTFSRjGfXr UgIK5LY56etIB+c52r15z0oZiowecdB60wnsD19DxSAgA5z6jmlYB/RgecCgv3GM0jMF7Aj3 70ny7lBPHcigBy5I+7nH50hbJG3r6+lA+YnHJ7GkU4yMEetAC8AAZ56/SgcnPJbFMBb+Hk/S nZ+UgpigBMgjqRntSD7/AFxx1HehuT1ycdD6UGRlHzBh6AmmAwnJJOfp6UoYYIx14wO9NLKD 0yfQGmnsRwRVCHqf7xJIOFANNkyG4OAeuKTaVPfn1prEbQABQA/hSRu7dCMUnBHUDnv2pjDk YyfT2pNxx6E8ZJpgPZgflB4GaZkncw5Xp/k0gXGVAPI4I6GkMjZ2j7x9O1UgHYIIyBnqcjpT GDI2cDpngUhyOA3601s8nJPuD0poBykoM85496XGMNt69T1poICcsQ390Ux5BnA5B9KYEpPl r8pGSf0/Gm7ycY3ZHqajB+bDH6DihWOMg4GMGqAerIHJweR1xzTTnBPQjimZDN/nrQUIy2AT 7UxCsxI68L0BpUIUgk5PbHao/MUY2lQf93pRtIBbbjntQA/CnOCAfQ80gYGUEkA5qMqCPl6n rkfypocjACnGevSmBKzs42g/LnOM+/Wm7mzgnHUE5pmeOmBu5J6mk6jJ4yOtAAOjHAP403oc Z+btzSxSFPkHUc49aO57HrnrTABsYk7WGc59M0RthfuZJ44HSkC7UIZvwzTWOBycZ75pAOfA HP3en3aTJmOSwVfekPCqM5ye/ekH3cdO/A70ALj7oQqPrRtGNq5I9Dj86a3X0PGac3yghv8A vmmAgOTj06ZoCgYBYgjsep9hQDxkZDZ60chQXPPUZoAfkZwqsPr3ppcEYI46UnLnHX6UFhkD qD6fpSsAbVzgMc5x0oULwDgNz1oAJG05P8gaPlRcjB+lMBSBvboB602TlcY9PalPzKMnb2NC r8pOGxntQA/O5gp5GOeaZu2jO3kZABpxJzgbs4GeaYpbdu/UGkAgJP3hx29BUrcnr0/lTflO AAQe3vTQAnDEUwFcHGA5JH6UjD92GIHB+tOB6Lxk88fXvSb2RM4+XPBoAQ55BJH16GnMQT/s jpSckgABlIzg0DEbY6igBPukAnH408FjtBB2nrnpTSADyQM9zxj2oK9NxPOccUAIwAHTn35p QAjAKeeeTSn5iBuAxxjOc00KwKnHQ85FADgSD1PHvTVBJ3Y79OmaUNngYGOvsKTfhiQDuz0I 6UAJ0bpjnoadliQABiglQAcjP060g28g9vyzQBZ27DgHJz6inMMAlWZh1NIrkLkAdec9qXhy wAIHHTjNZjHg4Ax973pFK7iDgenemrgtheCBmnHIJDfnSAcTwcKAMf5NPBDKoAJPpSFWVRzw w6kjpTTuOAxxjoaQD8EtkYwOKUElQMZHdsU1FwNxGM1JjAAztHpSAXjOBz6ZpwbgjgY5PFNA y2F4PfDYpQpJznqepOaQEigMuD0pysCdu0fUVFnJxzt7e9KOOByc/lSsA87ScLknpnFSDA7Y 9qi3ncSADkdqVcFfmJHp3pNAPVWHXIz1GOaCQF4/UU0buScj0zwKVTtxgd/rSAeQMA9jwKAN mcnoemaYTjjqc5p2SycAZ6k0AKTzxwKU8E8ZFNU88g5NEhPHTGOlADlOMhiBj0peSOM/1FMI G0kgfhQvJC4HPvQMcGIJIBJ64zSAHO4HHPPH9KRiMhR+PNISMdcnvQA7PBUYz6k80wn+82T0 xSEcg5py5GMAfU0CEDAYYc+1ISSM5xj0pytheF4zzxUbN1x+PFMAJLAIDnHc00qV5I6e/Wlw rDAYjHtSB+TuXdmmA1jjHBHrg9aQMCBx07etKx98D1NNYkHk7h3ApgPckt8q4yfSomX5iuME dqdy5449ewFR4I6Hnt7U0ApZgpBY/lTd20ZIHvmnYZWxx7c00nIBPJ6etMBGBIDdPem7l9Qf c0pUH5lzt96arA4BzwaYDlIKkcdOPQmmliFO4U18qOxzz9aVSeTt4HOKYCbhsGDz70m7acck +hpSoOADnnkCmZPzbR378ZpiFL714OFB54GaCzE4D5z+WKQMduOSSfemAnOABwc8cGmA5ju/ LjGaXKgn5jtI4yOM01OGJPQjnmkLAnkfKPzoAVnPKkcZzmm8ABgMfypxICjOM9qRSd/Tvxn/ AOtTARAfNIPXsKTkH5QMjqetAYktkZOe3egH5wACCOnrQAuCOvccHFI3GATkk8cdKcxO4jAx jOBxUe3LDIJ7/jQgJG+UEDovOfWmjszDj0FODDKr823qwxzTTtTBKgj37UAOVQ5yDt9R1psh IGPX2xSnkZ4/CmEnkkfie9CAeMYJTqeuD+tMBP48c5pyFW5II9eM0inKFePm74pgB3L98/hR gsRsJYE85xxRk98ZXjmkIXO0eueKAHFWZjnIJGKCmO2fcc5pCcrkEE57elNOcYznntmgBQQ6 5wOvWjuBj34oY5TIzwPWhDkfJnHfNABuUluQMdvWkwAOD9OKUYK+g9aXDSDjGeuRxQAiLyT1 9h2pyg7c4xnuaaMMxDMOBxTxsUEqSFI696GA0EENuGB60AFPlbjv/wDXpAQCcnp2zml+6wAI /HpQA3GAQAAD70rAKdoOQexoYhgDg4PX2oQADPGVPSgAY/MBwfX0oIbd64H+eKQdB8vBHGKN 2QMHGKBAPlABII68VIuSxAUewFRhyuTjd+OcU8H5ydv3h64oYxoKqxxg/h3pOATkihGw3cNS tkY+YE+/agQu7jaxHHv2puPk3DHvSk7QoY9+oFGSQBwW6fhQM//Z --------------69FADC9DE151F968E8097F86-- From Drew Daniels Mon Feb 12 21:12:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00356 for ; Mon, 12 Feb 2001 22:33:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 22:33:39 +0100 (MET) Received: (qmail 22044 invoked by uid 0); 12 Feb 2001 20:12:20 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx10) with SMTP; 12 Feb 2001 20:12:20 -0000 X-eGroups-Return: sentto-1101623-2378-982008739-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 12 Feb 2001 20:12:19 -0000 X-Sender: Drew_Daniels@Videon.wave.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 20:12:18 -0000 Received: (qmail 77632 invoked from network); 12 Feb 2001 20:12:17 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Feb 2001 20:12:17 -0000 Received: from unknown (HELO access.mbnet.mb.ca) (204.112.54.11) by mta3 with SMTP; 12 Feb 2001 21:13:22 -0000 Received: from access.mbnet.mb.ca (drdaniel@access.mbnet.mb.ca [204.112.54.11]) by access.mbnet.mb.ca (8.9.1a/8.9.1) with ESMTP id OAA14644 for ; Mon, 12 Feb 2001 14:12:16 -0600 (CST) To: f-cpu@yahoogroups.com Message-ID: From: Drew Daniels MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 14:12:15 -0600 (CST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] IRC channel Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 9e825b31892c83c33a36a6751279b345 Status: R X-Status: N Hi,
      I've re-registered the #f-cpu channel on the irc.openprojects.net
irc network. Feel free to drop by. I'll probably be the idle op there by
the nick of MLOTS.

     Drew Daniels
Yahoo! Groups Sponsor
www. .com 
From Paul Marques Mota Mon Feb 12 21:25:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00359 for ; Mon, 12 Feb 2001 22:33:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Feb 2001 22:33:39 +0100 (MET) Received: (qmail 6926 invoked by uid 0); 12 Feb 2001 20:25:24 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx13) with SMTP; 12 Feb 2001 20:25:24 -0000 X-eGroups-Return: sentto-1101623-2379-982009522-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 12 Feb 2001 20:25:23 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 20:25:22 -0000 Received: (qmail 15708 invoked from network); 12 Feb 2001 20:25:21 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 12 Feb 2001 20:25:21 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta3 with SMTP; 12 Feb 2001 21:26:26 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14SPXC-0003bF-00; Mon, 12 Feb 2001 21:25:18 +0100 Received: from alpha15.bocal.cs.univ-paris8.fr ([192.168.3.19] ident=mail) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14SPXC-0002uX-00; Mon, 12 Feb 2001 21:25:18 +0100 Received: from mota by alpha15.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 14SPXB-0005P9-00; Mon, 12 Feb 2001 21:25:17 +0100 To: f-cpu@yahoogroups.com Cc: Drew Daniels Message-ID: <20010212212517.D1655@bocal.cs.univ-paris8.fr> References: User-Agent: Mutt/1.0.1i In-Reply-To: ; from Drew_Daniels@Videon.wave.ca on Mon, Feb 12, 2001 at 02:12:15PM -0600 Sender: Paul MARQUES MOTA From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 21:25:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] IRC channel Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d45bf4b655eb157b5650751bca621dbe Status: R X-Status: N On Mon, Feb 12, 2001 at 02:12:15PM -0600, Drew Daniels wrote:
> Hi,
>       I've re-registered the #f-cpu channel on the irc.openprojects.net
> irc network. Feel free to drop by. I'll probably be the idle op there by
> the nick of MLOTS.
>

That's true ;) And I am the idle user with the Comte0 nick...

>      Drew Daniels

--
      Paul
Yahoo! Groups Sponsor
www..com
From Nicolas Boulay Mon Feb 12 22:13:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00310 for ; Tue, 13 Feb 2001 16:18:26 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:26 +0100 (MET) Received: (qmail 6606 invoked by uid 0); 12 Feb 2001 21:02:47 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx02) with SMTP; 12 Feb 2001 21:02:47 -0000 X-eGroups-Return: sentto-1101623-2380-982011765-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 12 Feb 2001 21:02:46 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 21:02:45 -0000 Received: (qmail 45638 invoked from network); 12 Feb 2001 21:02:44 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 12 Feb 2001 21:02:44 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 12 Feb 2001 22:03:49 -0000 Received: from ifrance.com (nas14-239.vlt.club-internet.fr [195.36.164.239]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA07098 for ; Mon, 12 Feb 2001 22:02:41 +0100 (MET) Message-ID: <3A8851E8.5D641C15@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A85F62A.2934D6AF@f-cpu.org> <3A866C48.1B7DF88@ifrance.com> <3A86B2D7.99EEDF04@f-cpu.org> <3A86CB64.F910CD9D@ifrance.com> <3A871DD9.50C0FBDE@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 22:13:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] jump latency Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 8d0fa9072e178a36005dd41a54753d44 Status: R X-Status: N Rehello,

Yann Guidon a =E9crit :
>
> hi,
>
> Nicolas Boulay wrote:
> > Yann Guidon a =E9crit :
> > > Nicolas Boulay wrote:
> > > > Yann Guidon a =E9crit :
> > > > > Then the problem is to "repair" the wron= g branches.
> > > > > That is : when a false branch is taken, go back to= the real destination
> > > > You now understand the goal of predicat ;p
> > > the purpose of predicates is different.
> > > predicates don't help with delay slots.
> > > the problem with delay slots is that it
> > > changes with the architecture while SW
> > > doesn't evolve as well. your predicates bring
> > > more troubles than they solve.
> > So rethink of it ! Predicat was created to limit at the maximum t= he
> > bubble in the pipeline.
>
> the problem here is to solve the cause of the bubble,
> not to hide it.
>

But you can't avoid it ! PC is a register and it's write is usualy made
in the write back stage in the far end of the pipeline. You can try to
put it earlier but you will have always bubble (around 7 in "modern&qu= ot;
proc). So A solution is to reduice the number of this kind of bubble !

> > > > The instruction is validate
> > > > only at the far end of the pipeline. But you can simula= te that by a
> > > > "validate" signal at the end. It's just some = more silicium.
> > > i know more or less how it works but this doesn't solve the<= BR> > > > jump latency problem at all ! your shameless plug failed. > > > you execute more instructions than necessary and you don't > > > win anything.
> > >
> > > there should be another solution.
> >
> > With a big pipeline, you always have bubbles or pipeline to flush= when
> > you jump. Predicat try to avoid the need to jump (for if clause,<= BR> > > mainly). Most of the time, when you want to jump, there is some &= quot;times"
> > between a fetch and the instruction jump is decoded, so you have = a
> > bubble, it's an obligation.
>
> F-CPU has conditional moves, which have most of the effects of predica= tes
> with less code and bandwidth bloat :-)

Not a all ! It's work only for the jump instruction not the following
one!

imagine the code :
a =3D 1
if (e =3D=3D 1) {e =3D a + 1 ; c =3D d;...}
e =3D a

became for you :
      a =3D 1
      p =3D (e =3D=3D 1)
      if !p jump to end:
      e =3D a + 1
      c =3D d
      ...
end:      e =3D a

So you have to flush the pipeline if the jump occure (so you can lost
several cycle, almost 80 % of the size of the pipeline !)

But with predicat :
      a =3D 1
      p =3D (e =3D=3D 1)
      !p e =3D a + 1
      !p c =3D d
      !p ...
end:      e =3D a

You don't have any flush !! You could save, maybe 10 cycles !!!!

> there should also be a way to make a conditional load/store one day. >
> here is a small review of the techniques commonly used to help here :<= BR> >  - branch predictor : it's based on a history. There's no provisi= on to
>      store this history yet. static predictio= n ("hints") is already done
>      in the instruction with a 2-bit field.
You need to store "some" pointers and make an history but you alw= ays
have bubble on not taken branch. And you could add one more pipeline
stage...

>  - branch target buffer : that's the equivalent of the Fetcher bu= ffer.
>      it can hold and cache 8 targets (today).= "jumping" from one line
>      to another is already very fast and i do= ubt one can do faster.

And so ? Where is the gain if you can fetch your data in one cycle ?

>  - delay slots : out of question : remember the MIPS and other ar= chitectures
>      that scaled so much that legacy SW could= n't keep up.
>

That's how work all pipelined RISC arch : scenix, ARM, PowerPC,... To
keep simple, there is always bubble on taken jump.

> In the present case, we can't decode two instructions at once and the<= BR> > cycle is lost. clean programming is absolutely necessary (and it has a= lways
> helped).
>

Why ? Flushing the pipeline means : finish the calcul but no write back
is made.

> > > > <...>
> > > > > WHYGEE
> > > > nicO
> > > WHYGEE
> > nicO
> WHYGEE
nicO
Yahoo! Groups Spons= or
=0D =0D=0D
3D""=0D3D""
=
www..com
3D""
From Nicolas Boulay Mon Feb 12 22:17:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00316 for ; Tue, 13 Feb 2001 16:18:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:27 +0100 (MET) Received: (qmail 31317 invoked by uid 0); 12 Feb 2001 21:06:38 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx14) with SMTP; 12 Feb 2001 21:06:38 -0000 X-eGroups-Return: sentto-1101623-2381-982011996-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 12 Feb 2001 21:06:37 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 21:06:36 -0000 Received: (qmail 57290 invoked from network); 12 Feb 2001 21:06:35 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 12 Feb 2001 21:06:35 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta3 with SMTP; 12 Feb 2001 22:07:40 -0000 Received: from ifrance.com (nas14-239.vlt.club-internet.fr [195.36.164.239]) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA15820 for ; Mon, 12 Feb 2001 22:06:33 +0100 (MET) Message-ID: <3A8852CF.5F66CEDA@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 22:17:03 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: a9963e6bb33265091b9b005c55bcd347 Status: R X-Status: N

Nicolas Matringe a =E9crit :
>
> Nicolas Boulay wrote:
> >
> > Funny ;p I have read (in Electronics International, a famous
> > french professional electronics newspaper) that a compagny would<= BR> > > produice 25 000 chips and the guy from the foundry answer that > > he didn't move under 500 000 chips... So, you're funny...
>
> Ever heard of CMP? Go and have a look there http://cmp.imag.fr/
> (Thanks to YG for telling me about it more than 1 year ago)
>

He work with them, i use every days a ST 0.25 library (HCMOS7) which
come from the CMP... But cmp and Europractice are for EDUCATIONNAL
purpose or PROTOTYPING for the industrie !!!! Not for a production at
all !!!

nicO

> --
> Nicolas MATRINGE         =   IPricot European Headquarters
> Conception electronique    10-12 Avenue de Verdun
> Tel +33 1 46 52 53 11      F-92250 LA GARENNE= -COLOMBES - FRANCE
> Fax +33 1 46 52 53 01      http://www.IPricot.com/
>

Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
www. =
=0D
3D""
From Nicolas Boulay Mon Feb 12 22:22:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00319 for ; Tue, 13 Feb 2001 16:18:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:28 +0100 (MET) Received: (qmail 22050 invoked by uid 0); 12 Feb 2001 21:13:35 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx16) with SMTP; 12 Feb 2001 21:13:35 -0000 X-eGroups-Return: sentto-1101623-2382-982012329-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 12 Feb 2001 21:13:35 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 21:12:09 -0000 Received: (qmail 24846 invoked from network); 12 Feb 2001 21:12:08 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 12 Feb 2001 21:12:08 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 12 Feb 2001 22:13:12 -0000 Received: from ifrance.com (nas14-239.vlt.club-internet.fr [195.36.164.239]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10944 for ; Mon, 12 Feb 2001 22:12:00 +0100 (MET) Message-ID: <3A885411.B85541DD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA68@po1-exch.lon.tudor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 22:22:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Scheduler Proposal a link for distributed memory and mmu. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: dc94f52e9026492152ed997109d9468d Status: R X-Status: N
Crazy link :

http://citeseer.nj.nec.com/cs?profile=0%2C221036%2C1%2C0.25%2CDownload&rd=http%3A//citeseer.nj.nec.com/papers/cs/6578/ftp%253A%2523@S@%2523%2523@S@%2523cva.stanford.edu%2523@S@%2523pub%2523@S@%2523publications%2523@S@%2523npcarter_phd_thesis.pdf

nicO
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Nicolas Boulay Mon Feb 12 22:22:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00322 for ; Tue, 13 Feb 2001 16:18:29 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:29 +0100 (MET) Received: (qmail 15872 invoked by uid 0); 12 Feb 2001 21:18:22 -0000 Received: from mx01.rz2.gmx.net (HELO mo.egroups.com) (10.1.72.101) by mxi1.gmx.net (mxi1) with SMTP; 12 Feb 2001 21:18:22 -0000 X-eGroups-Return: sentto-1101623-2382-982012329-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 12 Feb 2001 21:13:15 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 21:12:09 -0000 Received: (qmail 24846 invoked from network); 12 Feb 2001 21:12:08 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 12 Feb 2001 21:12:08 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 12 Feb 2001 22:13:12 -0000 Received: from ifrance.com (nas14-239.vlt.club-internet.fr [195.36.164.239]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA10944 for ; Mon, 12 Feb 2001 22:12:00 +0100 (MET) Message-ID: <3A885411.B85541DD@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EA68@po1-exch.lon.tudor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 22:22:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Scheduler Proposal a link for distributed memory and mmu. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d50c5546b538740fc1896f9047e264c8 Status: R X-Status: N
Crazy link :

http://citeseer.nj.nec.com/cs?profile=0%2C221036%2C1%2C0.25%2CDownload&rd=http%3A//citeseer.nj.nec.com/papers/cs/6578/ftp%253A%2523@S@%2523%2523@S@%2523cva.stanford.edu%2523@S@%2523pub%2523@S@%2523publications%2523@S@%2523npcarter_phd_thesis.pdf

nicO
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Ben Franchuk Sun Feb 11 17:40:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00328 for ; Tue, 13 Feb 2001 16:18:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:30 +0100 (MET) Received: (qmail 2084 invoked by uid 0); 12 Feb 2001 21:22:58 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx14) with SMTP; 12 Feb 2001 21:22:58 -0000 X-eGroups-Return: sentto-1101623-2383-982012977-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 12 Feb 2001 21:22:57 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 12 Feb 2001 21:22:56 -0000 Received: (qmail 55294 invoked from network); 12 Feb 2001 21:22:56 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 12 Feb 2001 21:22:56 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 12 Feb 2001 21:22:56 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA21111 for ; Mon, 12 Feb 2001 14:13:43 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A86C06F.E8F8EB61@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> <3A8852CF.5F66CEDA@ifrance.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 09:40:15 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a58add43b19458fd4d74d8f4b31c8ea9 Status: R X-Status: N Nicolas Boulay wrote:
> He work with them, i use every days a ST 0.25 library (HCMOS7) which
> come from the CMP... But cmp and Europractice are for EDUCATIONNAL
> purpose or PROTOTYPING for the industrie !!!! Not for a production at
> all !!!
I would say the F-CPU is the early Prototyping stage.
Real Early that is.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.

From "Marco Al" Tue Feb 13 04:11:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00352 for ; Tue, 13 Feb 2001 16:18:36 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:36 +0100 (MET) Received: (qmail 11339 invoked by uid 0); 13 Feb 2001 03:02:48 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx16) with SMTP; 13 Feb 2001 03:02:47 -0000 X-eGroups-Return: sentto-1101623-2384-982033365-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 13 Feb 2001 03:02:46 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 03:02:45 -0000 Received: (qmail 1934 invoked from network); 13 Feb 2001 03:02:44 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 13 Feb 2001 03:02:44 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 13 Feb 2001 03:02:44 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 2599D2998 for ; Tue, 13 Feb 2001 04:02:43 +0100 (CET) Message-ID: <006101c0956a$b19f8f30$29e65982@student.utwente.nl> To: References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> <3A8852CF.5F66CEDA@ifrance.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 04:11:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0ec433a0b8f766fae5faab11d4dd5ad0 Status: R X-Status: N From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>

> He work with them, i use every days a ST 0.25 library (HCMOS7) which
> come from the CMP... But cmp and Europractice are for EDUCATIONNAL
> purpose or PROTOTYPING for the industrie !!!! Not for a production at
> all !!!

Thats just playing with words, point is that you can have small batches made
(BTW EUROPRACTICE doesnt even agree with your word play, if they call one of the
their plans "low volume" production Id say they offer low volume production).
Sure its expensive, million gate FPGA's are bloody expensive too.

Marco
Yahoo! Groups Sponsor

www.

From Ben Franchuk Sun Feb 11 23:22:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00355 for ; Tue, 13 Feb 2001 16:18:37 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:37 +0100 (MET) Received: (qmail 23390 invoked by uid 0); 13 Feb 2001 03:22:11 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx10) with SMTP; 13 Feb 2001 03:22:11 -0000 X-eGroups-Return: sentto-1101623-2385-982034530-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 13 Feb 2001 03:22:10 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 03:22:06 -0000 Received: (qmail 30608 invoked from network); 13 Feb 2001 03:22:06 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 13 Feb 2001 03:22:06 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 13 Feb 2001 03:22:05 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA12806 for ; Mon, 12 Feb 2001 20:12:50 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8710BB.4B15C067@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> <3A8852CF.5F66CEDA@ifrance.com> <006101c0956a$b19f8f30$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Feb 2001 15:22:51 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d161fefb7b4e15e642a51be0bb83f61e Status: R X-Status: N Marco Al wrote:
>
> From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
>
> > He work with them, i use every days a ST 0.25 library (HCMOS7) which
> > come from the CMP... But cmp and Europractice are for EDUCATIONNAL
> > purpose or PROTOTYPING for the industrie !!!! Not for a production at
> > all !!!
>
> Thats just playing with words, point is that you can have small batches made
> (BTW EUROPRACTICE doesnt even agree with your word play, if they call one of the
> their plans "low volume" production Id say they offer low volume production).
> Sure its expensive, million gate FPGA's are bloody expensive too.
>
> Marco
Searching for low cost FPGA's ( $30 US )a few months ago on the net
I got several hits of all prices. They ranged in prices around $15,
$30, $100, $500, $1K  ,$2K and $5k. Don't forget the latest FPGA software
is about $4K and VHDL and Verlog compilers are extra $$$. And don't forget
you have pay $$$ every year for your license.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www..com
From David Sullins Tue Feb 13 04:33:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00358 for ; Tue, 13 Feb 2001 16:18:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:38 +0100 (MET) Received: (qmail 19497 invoked by uid 0); 13 Feb 2001 03:40:10 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx08) with SMTP; 13 Feb 2001 03:40:10 -0000 X-eGroups-Return: sentto-1101623-2386-982035607-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 13 Feb 2001 03:40:09 -0000 X-Sender: dsulli@ece.umr.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 03:40:07 -0000 Received: (qmail 77018 invoked from network); 13 Feb 2001 03:40:06 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 13 Feb 2001 03:40:06 -0000 Received: from unknown (HELO smtp.umr.edu) (131.151.1.89) by mta2 with SMTP; 13 Feb 2001 03:40:05 -0000 Received: from ece.umr.edu (ece.umr.edu [131.151.100.20]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id VAA23543; Mon, 12 Feb 2001 21:40:04 -0600 Received: from eceultra17 by ece.umr.edu (8.8.8+Sun/SMI-SVR4) id VAA02710; Mon, 12 Feb 2001 21:40:03 -0600 (CST) Received: from localhost by eceultra17 (8.8.8+Sun/ECESolaris-Client) id DAA08753; Tue, 13 Feb 2001 03:33:01 GMT To: f-cpu@yahoogroups.com In-Reply-To: <20010209012058.01262@thrai.stud.uni-hannover.de> Message-ID: From: David Sullins MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Feb 2001 21:33:01 -0600 (CST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] vhdl code of imu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d68d2876b7d6a153309dc81ecbf72a7e Status: R X-Status: N On Fri, 9 Feb 2001, Michael Riepe wrote:

> [...]
> > -- Compiling architecture behave_1 of cia_core
> > WARNING[5]: ciacore.vhdl(76): Nonresolved signal go may have multiple
> > sources.
>
> Huh?  It's becoming strange now.
>
> Could this be a problem with multiple `if ... generate' statements
> that are mutually exclusive?  I used them in all of these files, and
> both Simili and Vanilla VHDL groked it :(

That is exactly right.  Modelsim does not check if the if...generate
statements are mutually exclusive.  So you Modelsim will always give you a
warning for this kind of code.  It is safe to ignore the warning.

Dave
Yahoo! Groups Sponsor

www.  
From Nicolas Matringe Tue Feb 13 10:13:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00370 for ; Tue, 13 Feb 2001 16:18:43 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 16:18:43 +0100 (MET) Received: (qmail 4790 invoked by uid 0); 13 Feb 2001 09:11:57 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx07) with SMTP; 13 Feb 2001 09:11:57 -0000 X-eGroups-Return: sentto-1101623-2387-982055515-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 13 Feb 2001 09:11:56 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 09:11:55 -0000 Received: (qmail 82231 invoked from network); 13 Feb 2001 09:11:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Feb 2001 09:11:54 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 13 Feb 2001 09:11:54 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id JAA02682 for ; Tue, 13 Feb 2001 09:11:52 GMT X-To: Message-ID: <3A88FACE.E728B481@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F98A5DF@po1-exch.lon.tudor.com> <3A7DB7F6.E83B5E2B@jetnet.ab.ca> <3A83122F.2A630CD1@ifrance.com> <3A7DE5AE.ED1E26BD@jetnet.ab.ca> <3A8462D2.402E91C9@ifrance.com> <3A87A101.3C99B0D5@IPricot.com> <3A8852CF.5F66CEDA@ifrance.com> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 10:13:50 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Scheduler Proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 212b5f7eb8c6d84345062e027f3c57c5 Status: R X-Status: N Nicolas Boulay wrote:
> cmp and Europractice are for EDUCATIONNAL purpose or PROTOTYPING
> for the industrie !!!! Not for a production at all !!!

Well yes, I know. They don't go for more than 300 pieces.

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor

www.   
From Carsten899@aol.com Tue Feb 13 19:14:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00755 for ; Tue, 13 Feb 2001 19:29:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 19:29:50 +0100 (MET) Received: (qmail 25809 invoked by uid 0); 13 Feb 2001 18:14:25 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx09) with SMTP; 13 Feb 2001 18:14:25 -0000 X-eGroups-Return: sentto-1101623-2388-982088055-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 13 Feb 2001 18:14:16 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 18:14:15 -0000 Received: (qmail 87116 invoked from network); 13 Feb 2001 18:14:14 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 13 Feb 2001 18:14:14 -0000 Received: from unknown (HELO imo-d04.mx.aol.com) (205.188.157.36) by mta2 with SMTP; 13 Feb 2001 18:14:14 -0000 Received: from Carsten899@aol.com by imo-d04.mx.aol.com (mail_out_v29.5.) id r.74.7bec142 (17232) for ; Tue, 13 Feb 2001 13:14:12 -0500 (EST) Message-ID: <74.7bec142.27bad373@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 13:14:11 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] (i) VF-CPU : structures + defines Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: d808e71a6690dfa6c6f462dece24f915 Status: R X-Status: N [ VIMD-Cache ]
>> So we have a new structure. Hows it=B4s state on RESET?
>empty, of course, and bypassed anyway in kernel mode.
>> Perhaps it can be done by LRU member of the VMID cache entry?
>it's obvious that there is an invalid bit but i don't get how you do it= with
LRU.


okay - so the VIMD-Cache structure is:

// VM-ID Cache Entry
typedef struct _VMIDCE {
    UL64    vmid:FCPU_NUM_VMID_BITS;
    UL64    lru:FCPU_LOG_NUM_VMIDC_ENTRIES;     UL64    valid:1;
} VMIDCE, *PVMIDCE;

or:

// VM-ID Cache Entry
typedef struct _VMIDCE {
    UL64    vmid:FCPU_NUM_VMID_BITS;
    UL64    lru:FCPU_LOG_NUM_VMIDC_ENTRIES;     UL64    invalid:1;
} VMIDCE, *PVMIDCE;

who likes "invalid" bit better than "valid" or vice ver= sa? Are there
"invalid" bits used mostly all over FCPU or valid bits? I think t= here should
be the same "meaning" everywhere.

>>one of the best use of syscall is library calls, so the table
>>can be reconstructed each time a new service is desired. this varie= s from
>>task to task so it is best kept in the CMB.

if its purpose is library calls, its okay, but if its use is calling of kernel-services i dont think so.

>> #define FCPU_EXCEPTION_RESET      &n= bsp;         BIT( 0 )
>> #define FCPU_EXCEPTION_INTERRUPT     &nbs= p;      BIT( 1 )
>not needed : there is a separate table for IRQs.


the exception bits are a little bit emulator specific. the idea is as follo= ws.

while( 1 )
{
      if( User wants to emulate reset pin active )=
        cpu.exception |=3D FCPU_EXCEPTIO= N_RESET;
      if( User wants to emulatr interrupt pin acti= ve )
        cpu.exception |=3D FCPU_EXCEPTIO= N_INTERRUPT;

    // exception handler in fcpu_clock prioritizes all activ= e exceptions
    // and selects the most important and executes whatever = has to be
    // executed.
    fcpu_clock( &cpu );
}

>>something useful would be to add 8 subfields so we can analyse the<= BR> >>real use of the page. we would have something like UL16 hitcount[8]= ,
>>but i guess that it takes some room.... let's keep it for another v= ersion...

room is no problem in the emulator. do you want to measure which area of th= e
page is accessed mostly?

>>do we say "trap" or "exception" ? i started to = write "trap"
>>(5 letters shorter :-P) in the existing files, but i never cared >>to make a distinction.


no problem with trap instead of exception.

>>     UL64    interrupt_enable:1;=      /* 1 =3D IRQ enabled. 0 =3D ignore IRQ */
>however, traps and timeslice_elapsed (and similar internal events)
>are still possible.


yeah. its just dsableing the "interrupt pin" of the fcpu.

>>     TLBE    itlb[ FCPU_NUM_TLB_= ENTRIES ];
>>     TLBE    dtlb[ FCPU_NUM_TLB_= ENTRIES ];
>no need of separate tables, we have the r/w/rw/x flag in the entries. >
>>     UL64    itlb_enable:1; = ;         /* 1 =3D use itlb. 0 =3D = map phys to log
>> address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT= */
>>     UL64    dtlb_enable:1; = ;         /* 1 =3D use dtlb. 0 =3D = map phys to log
>> address. writing if rwsr=3D0 causes FCPU_EXCEPTION_PROTECTIONFAULT= */
>i wonder why i and d tlb enables are separated. it has no logical meani= ng
>for me.


manual V0.2 / chapter 3 / figure 4 shows seperate tlb=B4s for data and
instructions. this is why there are seperate tlbs here.

>encoding : 0000 : 8 bits
>           0001 : 16 = bits
>           0010 : 32 = bits
>           0011 : 64 = bits
>           0100 : 128= bits etc. ...

So some defines like as follows will be necessary:

#define FCPU_OPERAND_SIZE_8BITS  0
//...

will be defined.

>>it's really cool to see the emulator slowly emerging :-)
>>ok this coming week will be very heavy. good luck everyone !


i think i=B4ll be able to spend some days on coding the whole thing end of = Feb.

>>#define FCPU_SR_LAST_SR       44

i took a short look at, but i think FCPU_SR_INTERRUPT_ENABLE. Its a
"one-bit-SR" like FCPU_SR_PAGING.

By the way: Perhaps we shouldt say

( FCPU_SR_TLB_ENABLE  and FCPU_SR_TLBEMISS_BASE )

or

( FCPU_SR_PAGEING_ENABLE and FCPU_SR_PAGEMISS_BASE )


carsten
Yahoo! Groups Spons= or
3D""3D""
www..com
3D""
From Carsten899@aol.com Tue Feb 13 20:30:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00302 for ; Tue, 13 Feb 2001 23:10:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 23:10:07 +0100 (MET) Received: (qmail 21019 invoked by uid 0); 13 Feb 2001 19:30:12 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx08) with SMTP; 13 Feb 2001 19:30:12 -0000 X-eGroups-Return: sentto-1101623-2389-982092609-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 13 Feb 2001 19:30:10 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 19:30:09 -0000 Received: (qmail 23387 invoked from network); 13 Feb 2001 19:30:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 13 Feb 2001 19:30:08 -0000 Received: from unknown (HELO imo-r10.mx.aol.com) (152.163.225.10) by mta1 with SMTP; 13 Feb 2001 19:30:08 -0000 Received: from Carsten899@aol.com by imo-r10.mx.aol.com (mail_out_v29.5.) id r.cc.10a5d178 (16337) for ; Tue, 13 Feb 2001 14:30:00 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 14:30:00 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Virtual FCPU (64Bit) V0.2 - was: Some open questions Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 787776950c2bf68ad68f2dc8eeb58281 Status: R X-Status: N >>Should better be 3 individual bits (r, w and x).

This would permit read/writable, executable pages. i have no problem with <= BR> both alternatives for "access_rights".

>>Maybe even 6 bits
>>for different permissions in user/supervisor mode (Unix-like).

Mhh.... Actually i remember that entering supervisor mode means disabling <= BR> TLB=B4s. Am i wrong with that?

>>I'd prefer a more compact format -- four 64-bit words is too much.<= BR> >>When the CPU writes a TLB entry, it should not have to write more t= han
>>two words (that's enough for addresses, page size and flags).

At least we need three if physical and logical address space is 64 bit. Somewhere in the manual i read about FC0 physical address space being
somewhat below 32 bit? dont know exactly. so its possible to move phys_addr=
into the bitfield.

some con=B4s against:

- this TLBE structure shouldnt change for different implementations of FCPU=
with different phys. address spaces.

- if this structure contains bitfields the software has to spend more
instructions of combining all values into one 64 bit register and then
writing to TLB-SR=B4s by PUT, instead of multiple PUT=B4s.

This would be the structure with two 64 bit entries.

typedef struct _TLBE {
    UL64 log_addr;
    UL64 phy_addr:32;   /* 32 bit physical address= space. i think this is too
low. */
    UL64 page_size:6;      &nb= sp;            =   /* 6 bits allows a page to cover
whole physical 32 bit address space. size of page in bytes =3D 2 ^ page_siz= e =3D
1 << page_size */
    UL64 hit_counter:16;   /* i think there are 16= bits left in the UL64 */  
             /*= incremented whenever the address matches. */
    UL64 valid:1;       &= nbsp;           &nbs= p;   /* tlb entry contains valid adress
translation data */
    UL64 access_rights:2;      = ;         /* r=3D0, w=3D1, rw=3D2, = x=3D3*/
    UL64 cachable:1;      &nbs= p;             = /* if 0, don't seek in the cache */
    UL64 lru:FCPU_LOG_NUM_TLB_ENTRIES;
    UL64 vmid_handle:2;
} TLBE, *PTLBE;

>>In fact, ALL writable special registers should be saved in the CMB.=
>>The OS may want to change their user mode values, and the only way = to
>>do this is to change them in the CMB before returning to user mode.=

I have a different opinion. Looking at the list, i think the most are syste= m
global and dont change with user tasks.  (at least this depends on the= OS
philosophy, i think)
For example:

FCPU_SR_TRAP_BASE
FCPU_SR_PAGEING_ENABLE
[...]

carsten
Yahoo! Groups Spons= or
3D""3D"=

www.

3D""
From Nicolas Boulay Tue Feb 13 21:59:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA00317 for ; Tue, 13 Feb 2001 23:10:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Feb 2001 23:10:11 +0100 (MET) Received: (qmail 24957 invoked by uid 0); 13 Feb 2001 20:49:41 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx14) with SMTP; 13 Feb 2001 20:49:41 -0000 X-eGroups-Return: sentto-1101623-2390-982097353-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 13 Feb 2001 20:49:16 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 20:49:12 -0000 Received: (qmail 27227 invoked from network); 13 Feb 2001 20:49:11 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 13 Feb 2001 20:49:11 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta3 with SMTP; 13 Feb 2001 21:50:15 -0000 Received: from ifrance.com (nas7-188.vlt.club-internet.fr [194.158.109.188]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA25043 for ; Tue, 13 Feb 2001 21:49:08 +0100 (MET) Message-ID: <3A89A040.3B227256@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 21:59:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] vhdl code of imu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: be7e71f8dc42ad2b93ed33716d3f2dbc Status: R X-Status: N Maybe you can use constant instead of generate ?

nicO

David Sullins a =E9crit :
>
> On Fri, 9 Feb 2001, Michael Riepe wrote:
>
> > [...]
> > > -- Compiling architecture behave_1 of cia_core
> > > WARNING[5]: ciacore.vhdl(76): Nonresolved signal go may have= multiple
> > > sources.
> >
> > Huh?  It's becoming strange now.
> >
> > Could this be a problem with multiple `if ... generate' statement= s
> > that are mutually exclusive?  I used them in all of these fi= les, and
> > both Simili and Vanilla VHDL groked it :(
>
> That is exactly right.  Modelsim does not check if the if...gener= ate
> statements are mutually exclusive.  So you Modelsim will always g= ive you a
> warning for this kind of code.  It is safe to ignore the warning.=
>
> Dave
>

=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www. =
=0D
3D""
From Michael Riepe Tue Feb 13 19:34:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00905 for ; Wed, 14 Feb 2001 01:59:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 14 Feb 2001 01:59:49 +0100 (MET) Received: (qmail 26934 invoked by uid 0); 13 Feb 2001 23:13:06 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx09) with SMTP; 13 Feb 2001 23:13:06 -0000 X-eGroups-Return: sentto-1101623-2391-982105984-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by b05.egroups.com with NNFMP; 13 Feb 2001 23:13:05 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 13 Feb 2001 23:13:03 -0000 Received: (qmail 67366 invoked from network); 13 Feb 2001 23:13:03 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 13 Feb 2001 23:13:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.192) by mta3 with SMTP; 14 Feb 2001 00:14:03 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00498; Tue, 13 Feb 2001 19:34:49 +0100 Message-ID: <20010213193448.42448@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <74.7bec142.27bad373@aol.com> X-Mailer: Mutt 0.84e In-Reply-To: <74.7bec142.27bad373@aol.com>; from Carsten899@aol.com on Tue, Feb 13, 2001 at 01:14:11PM -0500 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Feb 2001 19:34:48 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] (i) VF-CPU : structures + defines Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: d2975e2fc208b83034301da886a6daae Status: R X-Status: N On Tue, Feb 13, 2001 at 01:14:11PM -0500, Carsten899@aol.com wrote:
[...]
> who likes "invalid" bit better than "valid" or vice versa? Are there
> "invalid" bits used mostly all over FCPU or valid bits? I think there should
> be the same "meaning" everywhere.

As a rule of thumb, choose the meaning so that the state is
`0' after reset.  If in doubt...  think positive, use `valid' ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Grab the opportunity to market your company. Choose the domain name below and press GO!
www.
Yahoo! Domains
From Yann GUIDON Thu Feb 15 14:27:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00357 for ; Thu, 15 Feb 2001 14:45:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 15 Feb 2001 14:45:02 +0100 (MET) Received: (qmail 13430 invoked by uid 0); 15 Feb 2001 13:35:09 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx15) with SMTP; 15 Feb 2001 13:35:09 -0000 X-eGroups-Return: sentto-1101623-2392-982244108-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 15 Feb 2001 13:35:09 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 15 Feb 2001 13:35:07 -0000 Received: (qmail 81427 invoked from network); 15 Feb 2001 13:35:07 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 15 Feb 2001 13:35:07 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 15 Feb 2001 13:35:07 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA24455; Thu, 15 Feb 2001 05:34:41 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 163PPKTS; Thu, 15 Feb 2001 13:39:37 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A8BD95D.EE4972D7@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102131129.MAA20718@or.mime.univ-paris8.fr> <3A89A044.16466949@ifrance.com> <3A8A80FE.5305EC91@mentor.com> <3A8B1DE0.439CA819@ifrance.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 15 Feb 2001 14:27:57 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] pipe depths ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 913c22733f1376422e694c51d360884c Status: R X-Status: N rerehello, nico, btw why did you send the last post
to the french mailing list ?...

Nicolas Boulay wrote:
> rehello,
> Yann GUIDON a =E9crit :
> > hi !
> > Nicolas Boulay wrote:
> > > Hello,
> > > Yann Guidon a =E9crit :
> > > > hi !
> > > > > Rehello,
> > > > > Yann Guidon a =E9crit :
> > > > > > hi,
> > > > > > Nicolas Boulay wrote:
> > > > > > > Yann Guidon a =E9crit :
> > > > > > > > Nicolas Boulay wrote:
> > > > > > > > > Yann Guidon a =E9crit :
> > <snip cascade>
> > > > I know no pipelined computer that does what you describ= e.
> > > > do you have examples ?
> > > DLX ;p
> > hmmm yeah ... you speak about such a wonderful architecture... > ;p
>
> Now i'm sure that sparc and ARM used delayed slot. For sparc, the jump= s
> are delayed by only one cycle, so it's definitely fixed.
yeah but why don't others use them ?
i know that for example the SHARC DSP has a 2 instruction
delay slot but a bit in the jump/call/ret instructions enables them.
SHARC is a recent architecture and it seems that the designers were
aware of the troubles it creates.
When you go superscalar, delay slots are even more difficult to
manage, and superpipeline doesn't help, as i explained for the ALPHA.

OTOH if you know that you will keep a single instruction issue
with a rather "decent" pipeline depth (3 to 5 stages) delayed bra= nches
are reasonable but you have to ensure that the processor is protected :
IRQs and faults during the slots are disabled and you can't EVEN
debug inside the slot.

> > > Pic. Most of the time, every modification must use an alu, t= he
> > > biggest unit in a not too much big RISC processor. So you av= oid to
> > > duplicate the ALU. Because most of the time, the jump are al= ways compare
> > > to the PC.
> > in F-CPU we can afford a duplicated unit...
> Sure, but i will have it's owne latency, too... Maybe that's why 32 bi= t
> alu are most of the time in a single pipeline stage.
in our case, the adder can be optimised and could fit in the stage
because we spare 2 bits from the LSB (instructions are aligned)
and we don't need to compute more than 10 bits if the pages are 4KB.
an overflow will trigger a page fault :-)
However in the FC0, it's a bit more complex.
We spare the 2 LSB plus 3 others because the cache lines can hold 8 instruc= tions.
Pages can be up to 2MB so we need 21-5=3D16 bits for the adder, which could= fit
inside a single pipeline stage with some luck (since we do adds only).

> > > The principle goal is make movable code (that will not
> > > possible for fc0 ?).
> > ???
> > of course movable code IS possible.
> > that's why there are the loadaddr instructions : they compute the=
> > new address (PC+imm/reg), check the TLB and prefetch the data. > So you can't really use : move pc, rn as is.
the instruction in itself doesn't exist because the PC is not a register. however you could define a macro for this :-) what you wrote is the same (plus some other things) as loadaddr r0,rn (PC+R0->RN). On top of that, = it
will check the TLB :-)

> > > > propagating the PC through the whole pipeline is also a= pure waste
> > > > of HW. what would be the purpose anyway, since we issue= in-order ?
> > > > all we want to know is the PC of the instruction curren= tly being decoded,
> > > > and it is provided by the fetcher unit. the rest of the= execution pipeline
> > > > doesn't care a fuck about the PC. PC+4 and PC are provi= ded "for free"
> > > > to the Xbar at the same time the register values are kn= own, and
> > > > that's well enough.
> > > ??? And the jump ? Thats true for pc <- pc + 4 but a Pc += Imm ?
> > jump requires prefetch. use loadaddr to prepare the jump target.<= BR> > >
> > example for a C code :
> > void function1 (void) {
> >   ...
> >   ...
> >   ...
> >  return;
> > }
> >
> > void function2 (void) {
> >   ...
> >   function1 ();
> >   ...
> >   function1 ();
> >   ...
> > }
> >
> > This translates to :
> >
> > function1:
> >   loadaddri function2-@, r2 ; load r2 with the entry ad= dress of function2
> >   ...
> >   jump r2, link r1 ; PC=3Dr2, r1=3DPC
> >   ...
> >   jump r2, link r1
> >   ...
> >   jump rX ; rX contains the return address for this fun= ction
> >
> > function2:
> >   ...
> >   ...
> >   ...
> >   jump r1
> >
>
> And ? It change absolutely nothing !(almost : you hide the calcul)
that's one of the points, the other point is that it is "safe" fr= om
all points of view. it's fast and not potentially dangerous for the system,=
you can still debug the instructions between the time you execute
the prefetch and the branch.
> But you always have to fetch the data from your multiple PC and if you= have
> a buffer you just take way for few cycle the bubbles (your buffer are<= BR> > always limited!).
i don;t understand what you mean.
"But you always have to fetch the data from your multiple PC" it is not "fetched", it is speculatively provided on the Xbar dur= ing every cycle.
this value is read by loadaddr(i) and an addition can be performed with the= ASU.
the result is written back to the register set and also checked by the TLB,=
just as with load/store with pointer update.
When the register and the allocated instruction buffer are ready, you simpl= y jump
by invocating the register number. there is NO address computation during t= he jump
itself (in return, you avoid multiple useless address computations, for exa= mple
during loops).

"and if you have a buffer you just take way for few cycle the bubbles&= quot;
" (your buffer are always limited!)."
that's very unclear here (your english is worse than mine ;-P)
- the 8 instruction buffers in the fetcher ( i think you speak about them)=
    are limited to 8 instructions each, sure they are limite= d. that's why a simple
    LRU mechanism is not enough, they work by pairs and shou= ld implement a
    "double buffering" scheme : when one line star= ts to be used, the second
    starts to fetch the next line. so when the first line is= executed,
    the second line is ready. When the second line starts to= be executed, you just
    restart from the beginning : prefetch another line but i= f possible the
    one that you just used. This way, you can store 3 levels= of function calls
    and avoid return penalties without even a hidden call st= ack as in the Pentium :-)
- the 1-cycle latency occurs when the branch is not correctly done.
    in theory, a branch costs almost nothing and can be take= n speculatively.
    the latency comes because of the decision which takes so= me more time.

> > > > > So you have to flush the pipeline if the jump occu= re (so you can lost
> > > > > several cycle, almost 80 % of the size of the pipe= line !)
> > > > "flush" ???? do you really take me for a fool= or what ? :-P
> > > > reread the FC0 description : no instruction is issued i= f it is not valid.
> > > > FC0 doesn't know about pipeline flush. it can stall dec= oding, but not flush.
> > > So how do you handel a simple jump on a 20 pipelines stages = cpu ?????
> > shown above.
> > the pipeline depth is not related to the branch latency.
> ????
> When i read that it seems to me that you make confusion between the > concept of pipelining and the execution unit. It seems to me that for<= BR> > you pipeline =3D execution unit, and decoder are a magic black box tha= t
> feed the units. Am i wrong ? I hope ! Because when you finish to decod= e
> a current instruction, an other one is being fetch. That's the main > latency of jumps. Then it's time to calculate the new PC and the cycle=
> after is used  for the fetch. Buffer, or not you need to make all= that
> operation !
> All your design could be in a one cycle stage, you choose just to put<= BR> > some time barrer to speed up the clock by cuting the cdp, so the
> depencies problem in execution unit are the same for the fetch/decode<= BR> > unit.

let me repeat it (and i mean it) :
   "the pipeline depth is not related to the branch latency.= "
to be more precise : the branch latency is almost equivalent to the
   memory latency, or the time it takes to fetch new instructions= plus
   the time it takes to make a decision.

in F-CPU, this is very short because we branch on registers. it does not recompute an address all the time so it can be performed in advance. As soo= n
as the register number is known in the instruction, the fetch unit can look= up
if the corresponding target is ready in the instruction buffer. This way yo= u
can cut away most of the existing problems found in today's CPU.

> > however, if you run a division and wait for the result to know wh= ether you branch,
> > it will wait a lot of cycles but it's only a proof that your prog= ramming standards
> > are very low.
> I don't understand what you mean.
pipeline depth is also related to the execution unit latency.

> > > > btw, a study (that you resent to the list recently) ind= icates
> > > > that this kind of optimisation does not improve perform= ance on SMT machines,
> > > > simply because you overload the pipeline with useless i= nstructions
> > > > (operations which result gets discarded). This is also = the plague for ia64 :
> > > > you have to extract a lot of parallelism and in the end= , maybe 40% of the
> > > > operations you issued are useful. that's why you get so= much
> > > > "apparent instruction-level parellelism".
> > > That's not the same when you finaly discard the save of a ca= lcul by your
> > > conditionnal move ? That's the same problem, no ?
> > yup BUT at least you can change the coding style with F-CPU.
> > if you want to use FC0 to its fullest, this is highly recommended= to transform
> > the control dependencies into data dependencies.
> I have soon understood that.
>
> > However, when F-CPU will have a SMT core, the compiler can have a= new flag that
> > says to not do that. the "predicates" will not waste ba= ndwidth
> > and the CPU will be much more efficient on several simultaneous t= asks.
> That doesn't change anything for smt or not smt ! Or i don't get your<= BR> > point. Smt is just a way to make a single processor look like (for the=
> user) as a n ways SMP system.

yep but the efficiency of SMT depends on the executed code, too
(that was the point). if you feed a SMT core with lots of branches and
no speculative operations, the core can schedule more threads and
the overall performance increases, while the performance on FC0 decreases.<= BR> If you do a lot of "speculative operations", the SMT core will be= loaded
with a lot of useless operations while FC0 will be happy.

> > It's the same problem with non optimized code : the ILP is artifi= cially too high.
> > by applying some simple optimisations (constant and other computa= tional propagations
> > outside loops, dead code removal ...) the "realistic ILP&quo= t; is lower.
> Ok but your code with cmove does exactly the same work ! It's just an<= BR> > other type of coding ! I always make more or less usefull instruction,=
> discard or not by the condition.
yup but SMT makes more "work" even though the execution time for = all threads
is longer. doing the same work faster or more work with more latency, that'= s
the compromise to do. one has to adjust the coding style in consequence.
> > > Taken is always costly because when you see that you should = change the
> > > pc you aren't in the same pipeline stage. So a static predic= tion scheme
> > > must say always not taken ;p
> > in the FC0, there are in fact ... 8 "pseudo-PC" so in f= act
> > you switch from one to another when you jump.
> Always the fetch/decod to do. So ?
only decode. the fetcher is just a big multiplexor.

> > as for the "bubble", this is not difficult to handle it= .
> > the problem is simply to avoid it.
> Fixed delayed branches ? (1 cycle)
no way. stall is safer. this way it is possible to trace into
any code and interrupt ANY software at ANY location.
today, the MIPS CPU have no DS today, they had one at the beginning though.=
when the ISA evolved, it was harder and harder to keep up with older
binaries because the architecture had evolved too, in different directions<= BR> (deep OOO etc.). DS are fine only if you are absolutely certain that
the core doesn't evolve, for example the ARM which has kept his overall sha= pe
during the last 20 years. OTOH the latest MIPS (ie R12K) have a completely<= BR> different scale (performance, transistor count, parallelism...) and the ori= ginal
ISA is not adapted.


> > > Sure but if you must predicte the next address it add some t= hings in the
> > > cdp and finaly you could add a pipeline stage.
> > never. this is at least a pure waste and lack of imagination when= it comes to
> > the FC0. On top of that, adding a BP stage to win maybe 50% of bu= bbles
> > will not increase performance if you have only 1 cycle of branch = penaly.
> > BP becomes interesting with 4+ cycles.
> It's called time budgeting ! One more stage or 10% lower clock, it's t= he
> choice ! But only if the BT are on the cdp.
that's the point : branch prediction can be performed speculatively
and "validated" a bit later. a stage where only BP is performed l= ooks silly
(and i don's understand why Intel does that in its latest CPUs).

> I don't understand one point. Modern cpu have between 10 to 20 pipelin= es
> stage. Fcpu could have more.
this depends.
the removal of the address computation for the jumps helps a lot because jumping becomes so much easier in a superpipeline.
OTOH the x86 has a lot of jump modes and it takes several pipeline stages to a P6 to decode the jump address. restarting the pipeline is slow, too.
As you may have read, a part of the FC0 and the F-CPU 's philosophy can be<= BR> understood by looking at the CDC6600 computer. It was probably the first computer that "isolated" the "execution path" from the = memory with a
pure load-store architecture. controlling the units was so much simpler
than on other computers. That's what is done also with the control logic.
http://www.research.microsoft.com/~gbell/= Computer_Structures__Readings_and_Examples/00000512.htm

"
In a sense, just as the whole central processor is hidden behind central memory from the peripheral processors, so, too, the ten functional units are hidden behind the central registers from central memory. As a conseque= nce,
a considerable instruction efficiency is obtained and an interesting form<= BR> of concurrency is feasible and practical. The fact that a small number
of bits can give meaningful definition to any function makes it possible to develop forms of operand and unit reservations needed for a general
scheme of concurrent arithmetic.
"

now if you apply the same principle for the load/store of data AND instruct= ions,
you end up with a very simplified and efficient HW. you can forget about pipeline flushes and all the usual mess.

> Modern processor have 80 %, in average, of
> the pipeline cycles penalties when a wrong branch prediction occur or = 2
> or 3 cycle when it take the branch. So i don't understand that you thi= nk
> it's easy to made zero jump latency on more pipelined cpu as the fcpu.=
as long as you can keep the decoder+issue inside one pipeline cycle,
you can avoid the penalty because no address check is necessary.
that's rudimentary but efficient.

> > variable latency execution + lack of write back buffer/register r= enaming + atomic
> > instruction =3D whole mess when an exception occurs.
> > Finally a simple scoreboard is so simple.
> "as written in the manual."  it is, but nothing is expl= ain ! What do the
> scorebord here ?
the scoreboard remembers which register is currently being computed.
if the decoder sees that you want to write or read a register that is "= ;not ready"
(result is not known) it will wait until everything is ready and then issue= your
instruction. This way, you may loose some time compared to your C6x referen= ce,
but you don't have to remember the latency of every execution unit when you=
create a program. If the core changes, you don't have to recompile everythi= ng,
it can still be executed safely (even if it can be slower).

history :
scoreboards were invented in the 50s or 60s, somebody will have to check. the name is a reference to the boards that display the score of the teams on a playground, it is updated every time a point is won.

scoreboards are used in computers as a natural way to block the execution of software when a unit hazard can occur. If you read P&H, you'll learn=
that MIPS (the CPU family) comes from "Machine without Interlocked Pip= eline Stage" :
they didn't have enough transistors on the chip to fit the scoreboard and t= hey
relied on the compiler to generate "legal code".

Otherwise, a scoreboard is the minimal system to implement when no suitable=
compiler is available. Currently, for example, the GCC port does generate ugly code and can't deal with delay slots adapted to the F-CPU scheduling,<= BR> stalling the issue is "safe" even though it loses some cycles her= e or there...

Ok i stop here ;-)

> > > > > > > > > <...>
> > > > > > > > > > WHYGEE
> > > > > > > > > nicO
> > > > > > > > WHYGEE
> > > > > > > nicO
> > > > > > WHYGEE
> > > > > nicO
> > > > YG
> > > nicO which take a little more time before answering but one = hour per
> > > days is enought ;p
> > YG who restarted to play with Xlib and GNL interface :-)))
> > yeah ! i discovered how to handle colormaps ! :-D
> nicO
YG

speaking for himself
=0D=0D
Yahoo! Groups Spons= or
=0D=0D=0D
3D""3D""
www.  
=0D
3D""
From Nicolas Boulay Fri Feb 16 00:30:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01169 for ; Fri, 16 Feb 2001 00:59:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 00:59:53 +0100 (MET) Received: (qmail 18579 invoked by uid 0); 15 Feb 2001 23:20:12 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx22) with SMTP; 15 Feb 2001 23:20:12 -0000 X-eGroups-Return: sentto-1101623-2394-982279174-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 15 Feb 2001 23:19:36 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 15 Feb 2001 23:19:34 -0000 Received: (qmail 61032 invoked from network); 15 Feb 2001 23:19:33 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 15 Feb 2001 23:19:33 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 15 Feb 2001 23:19:32 -0000 Received: from ifrance.com (nas21-39.vlt.club-internet.fr [195.36.171.39]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13422 for ; Fri, 16 Feb 2001 00:19:30 +0100 (MET) Message-ID: <3A8C668B.664CC413@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <200102131129.MAA20718@or.mime.univ-paris8.fr> <3A89A044.16466949@ifrance.com> <3A8A80FE.5305EC91@mentor.com> <3A8B1DE0.439CA819@ifrance.com> <3A8BD95D.EE4972D7@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 00:30:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] ARM and data/instruction dependancies Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4fa0c3d62cc3ed30536f9a8d42fa05e3 Status: R X-Status: N ARM asm gcd exemple :

the C code
int gcd(int a, int b)
{
        while (a!=b)
        {
        if( a>b )
            a = a - b;
        else
            b = b -a ;
        }
        return a;
}

with a usual jump, it's became :

gcd  cmp  r0, r1
     beq  end
     blt  less
     sub  r0, r0, r1
     b    gcd
less
     sub  r1, r1, r0
     b    gcd
end

With alu predicat, so you could set an alu bit, and condition the
execution to this bit :

gcd
    cmp     r0, r1
    subgt   r0, r0, r1
    sublt   r1, r1, r0
    bne     gcd


7 versus 4 instructions. For r0 = 1 and r1 = 2, 13 versus 10 cycles.
Nice work no ?

So how is it translate in fcpu asm ? To compare it.

nicO
Yahoo! Groups Sponsor
www. .com 
From Nicolas Boulay Fri Feb 16 00:30:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01172 for ; Fri, 16 Feb 2001 00:59:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 00:59:53 +0100 (MET) Received: (qmail 5723 invoked by uid 0); 15 Feb 2001 23:23:56 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx05) with SMTP; 15 Feb 2001 23:23:56 -0000 X-eGroups-Return: sentto-1101623-2393-982279171-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 15 Feb 2001 23:19:33 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 15 Feb 2001 23:19:30 -0000 Received: (qmail 61756 invoked from network); 15 Feb 2001 23:19:29 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 15 Feb 2001 23:19:29 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 15 Feb 2001 23:19:29 -0000 Received: from ifrance.com (nas21-39.vlt.club-internet.fr [195.36.171.39]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA00318 for ; Fri, 16 Feb 2001 00:18:50 +0100 (MET) Message-ID: <3A8C6682.C3439720@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <200102131129.MAA20718@or.mime.univ-paris8.fr> <3A89A044.16466949@ifrance.com> <3A8A80FE.5305EC91@mentor.com> <3A8B1DE0.439CA819@ifrance.com> <3A8BD95D.EE4972D7@mentor.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 00:30:10 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] pipe depths ... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 4b2eb535632212400bcb6b4132d1d5a9 Status: R X-Status: N Hello,

Yann GUIDON a =E9crit :
>
> rerehello, nico, btw why did you send the last post
> to the french mailing list ?...
>

An error !

> Nicolas Boulay wrote:
> > rehello,
> > Yann GUIDON a =E9crit :
> > > hi !
> > > Nicolas Boulay wrote:
> > > > Hello,
> > > > Yann Guidon a =E9crit :
> > > > > hi !
> > > > > > Rehello,
> > > > > > Yann Guidon a =E9crit :
> > > > > > > hi,
> > > > > > > Nicolas Boulay wrote:
> > > > > > > > Yann Guidon a =E9crit :
> > > > > > > > > Nicolas Boulay wrote:
> > > > > > > > > > Yann Guidon a =E9crit : > > > <snip cascade>
> > > > > I know no pipelined computer that does what you de= scribe.
> > > > > do you have examples ?
> > > > DLX ;p
> > > hmmm yeah ... you speak about such a wonderful architecture.= ..
> > ;p
> >
> > Now i'm sure that sparc and ARM used delayed slot. For sparc, the= jumps
> > are delayed by only one cycle, so it's definitely fixed.
> yeah but why don't others use them ?
> i know that for example the SHARC DSP has a 2 instruction
> delay slot but a bit in the jump/call/ret instructions enables them. > SHARC is a recent architecture and it seems that the designers were > aware of the troubles it creates.
> When you go superscalar, delay slots are even more difficult to
> manage, and superpipeline doesn't help, as i explained for the ALPHA.<= BR> >

I don't understand why ?

> OTOH if you know that you will keep a single instruction issue
> with a rather "decent" pipeline depth (3 to 5 stages) delaye= d branches
> are reasonable but you have to ensure that the processor is protected = :
> IRQs and faults during the slots are disabled and you can't EVEN
> debug inside the slot.
>
Why can't you wait that your instruction is finish ?

> > > > Pic. Most of the time, every modification must use an a= lu, the
> > > > biggest unit in a not too much big RISC processor. So y= ou avoid to
> > > > duplicate the ALU. Because most of the time, the jump a= re always compare
> > > > to the PC.
> > > in F-CPU we can afford a duplicated unit...
> > Sure, but i will have it's owne latency, too... Maybe that's why = 32 bit
> > alu are most of the time in a single pipeline stage.
> in our case, the adder can be optimised and could fit in the stage
> because we spare 2 bits from the LSB (instructions are aligned)
> and we don't need to compute more than 10 bits if the pages are 4KB. > an overflow will trigger a page fault :-)
> However in the FC0, it's a bit more complex.
> We spare the 2 LSB plus 3 others because the cache lines can hold 8 in= structions.
> Pages can be up to 2MB so we need 21-5=3D16 bits for the adder, which = could fit
> inside a single pipeline stage with some luck (since we do adds only).=
>
No luck ! It's a choice ! So you defined how many gates you could cross.
> > > > The principle goal is make movable code (that will not<= BR> > > > > possible for fc0 ?).
> > > ???
> > > of course movable code IS possible.
> > > that's why there are the loadaddr instructions : they comput= e the
> > > new address (PC+imm/reg), check the TLB and prefetch the dat= a.
> > So you can't really use : move pc, rn as is.
> the instruction in itself doesn't exist because the PC is not a regist= er.

That's what could be made to to make the design easier.

> however you could define a macro for this :-) what you wrote is the sa= me
> (plus some other things) as loadaddr r0,rn (PC+R0->RN). On top of t= hat, it
> will check the TLB :-)
>
Macro ;p !! no, that's a stupid hide of complexity.

> > > > > propagating the PC through the whole pipeline is a= lso a pure waste
> > > > > of HW. what would be the purpose anyway, since we = issue in-order ?
> > > > > all we want to know is the PC of the instruction c= urrently being decoded,
> > > > > and it is provided by the fetcher unit. the rest o= f the execution pipeline
> > > > > doesn't care a fuck about the PC. PC+4 and PC are = provided "for free"
> > > > > to the Xbar at the same time the register values a= re known, and
> > > > > that's well enough.
> > > > ??? And the jump ? Thats true for pc <- pc + 4 but a= Pc + Imm ?
> > > jump requires prefetch. use loadaddr to prepare the jump tar= get.
> > >
> > > example for a C code :
> > > void function1 (void) {
> > >   ...
> > >   ...
> > >   ...
> > >  return;
> > > }
> > >
> > > void function2 (void) {
> > >   ...
> > >   function1 ();
> > >   ...
> > >   function1 ();
> > >   ...
> > > }
> > >
> > > This translates to :
> > >
> > > function1:
> > >   loadaddri function2-@, r2 ; load r2 with the ent= ry address of function2
> > >   ...
> > >   jump r2, link r1 ; PC=3Dr2, r1=3DPC
> > >   ...
> > >   jump r2, link r1
> > >   ...
> > >   jump rX ; rX contains the return address for thi= s function
> > >
> > > function2:
> > >   ...
> > >   ...
> > >   ...
> > >   jump r1
> > >
> >
> > And ? It change absolutely nothing !(almost : you hide the calcul= )
> that's one of the points, the other point is that it is "safe&quo= t; from
> all points of view. it's fast and not potentially dangerous for the sy= stem,
> you can still debug the instructions between the time you execute
> the prefetch and the branch.
> > But you always have to fetch the data from your multiple PC and i= f you have
> > a buffer you just take way for few cycle the bubbles (your buffer= are
> > always limited!).
> i don;t understand what you mean.
>  "But you always have to fetch the data from your multiple P= C"
> it is not "fetched", it is speculatively provided on the Xba= r during every cycle.
> this value is read by loadaddr(i) and an addition can be performed wit= h the ASU.
> the result is written back to the register set and also checked by the= TLB,
> just as with load/store with pointer update.
> When the register and the allocated instruction buffer are ready, you = simply jump
> by invocating the register number. there is NO address computation dur= ing the jump
> itself (in return, you avoid multiple useless address computations, fo= r example
> during loops).
>

Yes, but you manipulate a pointer not the instruction it-self.

> "and if you have a buffer you just take way for few cycle the bub= bles"
> " (your buffer are always limited!)."
> that's very unclear here (your english is worse than mine ;-P)
>  - the 8 instruction buffers in the fetcher ( i think you speak a= bout them)
>     are limited to 8 instructions each, sure they = are limited. that's why a simple

A 8 stage pipeline for the fetcher ...

>     LRU mechanism is not enough, they work by pair= s and should implement a
>     "double buffering" scheme : when one= line starts to be used, the second
>     starts to fetch the next line. so when the fir= st line is executed,

or 2 times 4 instructions ?

>     the second line is ready. When the second line= starts to be executed, you just
>     restart from the beginning : prefetch another = line but if possible the
>     one that you just used. This way, you can stor= e 3 levels of function calls

function call ? not consecutive instruction ?

>     and avoid return penalties without even a hidd= en call stack as in the Pentium :-)
>  - the 1-cycle latency occurs when the branch is not correctly do= ne.
>     in theory, a branch costs almost nothing and c= an be taken speculatively.
>     the latency comes because of the decision whic= h takes some more time.
>
> > > > > > So you have to flush the pipeline if the jump= occure (so you can lost
> > > > > > several cycle, almost 80 % of the size of the= pipeline !)
> > > > > "flush" ???? do you really take me for a= fool or what ? :-P
> > > > > reread the FC0 description : no instruction is iss= ued if it is not valid.
> > > > > FC0 doesn't know about pipeline flush. it can stal= l decoding, but not flush.
> > > > So how do you handel a simple jump on a 20 pipelines st= ages cpu ?????
> > > shown above.
> > > the pipeline depth is not related to the branch latency.
> > ????
> > When i read that it seems to me that you make confusion between t= he
> > concept of pipelining and the execution unit. It seems to me that= for
> > you pipeline =3D execution unit, and decoder are a magic black bo= x that
> > feed the units. Am i wrong ? I hope ! Because when you finish to = decode
> > a current instruction, an other one is being fetch. That's the ma= in
> > latency of jumps. Then it's time to calculate the new PC and the = cycle
> > after is used  for the fetch. Buffer, or not you need to mak= e all that
> > operation !
> > All your design could be in a one cycle stage, you choose just to= put
> > some time barrer to speed up the clock by cuting the cdp, so the<= BR> > > depencies problem in execution unit are the same for the fetch/de= code
> > unit.
>
> let me repeat it (and i mean it) :
>    "the pipeline depth is not related to the branc= h latency."
> to be more precise : the branch latency is almost equivalent to the >    memory latency, or the time it takes to fetch new in= structions plus
>    the time it takes to make a decision.
>

So it's clearly linked to the depth of pipeline (indirectly).

> in F-CPU, this is very short because we branch on registers. it does n= ot
> recompute an address all the time so it can be performed in advance. A= s soon
> as the register number is known in the instruction, the fetch unit can= lookup
> if the corresponding target is ready in the instruction buffer. This w= ay you
> can cut away most of the existing problems found in today's CPU.
>

yes but you always have to make the fetch and decod it ! How do you want to avoid this ?

> > > however, if you run a division and wait for the result to kn= ow whether you branch,
> > > it will wait a lot of cycles but it's only a proof that your= programming standards
> > > are very low.
> > I don't understand what you mean.
> pipeline depth is also related to the execution unit latency.
>

No it's the opposite. You have a unit, you decide your time budget and
then you cut the unit in little piece. So your choice of the size of the pipeline (in nanosecond) you determine the latency of the units.

> > > > > btw, a study (that you resent to the list recently= ) indicates
> > > > > that this kind of optimisation does not improve pe= rformance on SMT machines,
> > > > > simply because you overload the pipeline with usel= ess instructions
> > > > > (operations which result gets discarded). This is = also the plague for ia64 :
> > > > > you have to extract a lot of parallelism and in th= e end, maybe 40% of the
> > > > > operations you issued are useful. that's why you g= et so much
> > > > > "apparent instruction-level parellelism"= .
> > > > That's not the same when you finaly discard the save of= a calcul by your
> > > > conditionnal move ? That's the same problem, no ?
> > > yup BUT at least you can change the coding style with F-CPU.=
> > > if you want to use FC0 to its fullest, this is highly recomm= ended to transform
> > > the control dependencies into data dependencies.
> > I have soon understood that.
> >
> > > However, when F-CPU will have a SMT core, the compiler can h= ave a new flag that
> > > says to not do that. the "predicates" will not was= te bandwidth
> > > and the CPU will be much more efficient on several simultane= ous tasks.
> > That doesn't change anything for smt or not smt ! Or i don't get = your
> > point. Smt is just a way to make a single processor look like (fo= r the
> > user) as a n ways SMP system.
>
> yep but the efficiency of SMT depends on the executed code, too
> (that was the point). if you feed a SMT core with lots of branches and=
> no speculative operations, the core can schedule more threads and
> the overall performance increases, while the performance on FC0 decrea= ses.
> If you do a lot of "speculative operations", the SMT core wi= ll be loaded
> with a lot of useless operations while FC0 will be happy.
>

Understand that your smt version of the fc0 have a different latency so
different special register for a better compilation. Too complicate to
try to optimse speed of old binaries.

> > > It's the same problem with non optimized code : the ILP is a= rtificially too high.
> > > by applying some simple optimisations (constant and other co= mputational propagations
> > > outside loops, dead code removal ...) the "realistic IL= P" is lower.
> > Ok but your code with cmove does exactly the same work ! It's jus= t an
> > other type of coding ! I always make more or less usefull instruc= tion,
> > discard or not by the condition.
> yup but SMT makes more "work" even though the execution time= for all threads
> is longer. doing the same work faster or more work with more latency, = that's
> the compromise to do. one has to adjust the coding style in consequenc= e.
>

Sur, a good recompilation !

> > > > Taken is always costly because when you see that you sh= ould change the
> > > > pc you aren't in the same pipeline stage. So a static p= rediction scheme
> > > > must say always not taken ;p
> > > in the FC0, there are in fact ... 8 "pseudo-PC" so= in fact
> > > you switch from one to another when you jump.
> > Always the fetch/decod to do. So ?
> only decode. the fetcher is just a big multiplexor.
>

NO, you have to search the data to the memory, so it's much longer than
a simple multiplexer.

> > > as for the "bubble", this is not difficult to hand= le it.
> > > the problem is simply to avoid it.
> > Fixed delayed branches ? (1 cycle)
> no way. stall is safer. this way it is possible to trace into
> any code and interrupt ANY software at ANY location.
> today, the MIPS CPU have no DS today, they had one at the beginning th= ough.
> when the ISA evolved, it was harder and harder to keep up with older > binaries because the architecture had evolved too, in different direct= ions
> (deep OOO etc.). DS are fine only if you are absolutely certain that > the core doesn't evolve, for example the ARM which has kept his overal= l shape
> during the last 20 years. OTOH the latest MIPS (ie R12K) have a comple= tely
> different scale (performance, transistor count, parallelism...) and th= e original
> ISA is not adapted.
>

So ok ! What are your proposal ?

> > > > Sure but if you must predicte the next address it add s= ome things in the
> > > > cdp and finaly you could add a pipeline stage.
> > > never. this is at least a pure waste and lack of imagination= when it comes to
> > > the FC0. On top of that, adding a BP stage to win maybe 50% = of bubbles
> > > will not increase performance if you have only 1 cycle of br= anch penaly.
> > > BP becomes interesting with 4+ cycles.
> > It's called time budgeting ! One more stage or 10% lower clock, i= t's the
> > choice ! But only if the BT are on the cdp.
> that's the point : branch prediction can be performed speculatively > and "validated" a bit later. a stage where only BP is perfor= med looks silly
> (and i don's understand why Intel does that in its latest CPUs).
>

It's not silly ! You have to cut you unit into piece and you give a name to your pipeline stage. That's all.

> > I don't understand one point. Modern cpu have between 10 to 20 pi= pelines
> > stage. Fcpu could have more.
> this depends.
> the removal of the address computation for the jumps helps a lot becau= se
> jumping becomes so much easier in a superpipeline.
> OTOH the x86 has a lot of jump modes and it takes several pipeline sta= ges
> to a P6 to decode the jump address. restarting the pipeline is slow, t= oo.
>
> As you may have read, a part of the FC0 and the F-CPU 's philosophy ca= n be
> understood by looking at the CDC6600 computer. It was probably the fir= st
> computer that "isolated" the "execution path" from= the memory with a
> pure load-store architecture. controlling the units was so much simple= r
> than on other computers. That's what is done also with the control log= ic.
>
> http://www.research.microsoft.com/~g= bell/Computer_Structures__Readings_and_Examples/00000512.htm
>
> "
>  In a sense, just as the whole central processor is hidden behind= central
>  memory from the peripheral processors, so, too, the ten function= al units
>  are hidden behind the central registers from central memory. As = a consequence,
>  a considerable instruction efficiency is obtained and an interes= ting form
>  of concurrency is feasible and practical. The fact that a small = number
>  of bits can give meaningful definition to any function makes it = possible
>  to develop forms of operand and unit reservations needed for a g= eneral
>  scheme of concurrent arithmetic.
> "
>
> now if you apply the same principle for the load/store of data AND ins= tructions,
> you end up with a very simplified and efficient HW. you can forget abo= ut
> pipeline flushes and all the usual mess.
>
> > Modern processor have 80 %, in average, of
> > the pipeline cycles penalties when a wrong branch prediction occu= r or 2
> > or 3 cycle when it take the branch. So i don't understand that yo= u think
> > it's easy to made zero jump latency on more pipelined cpu as the = fcpu.
> as long as you can keep the decoder+issue inside one pipeline cycle, > you can avoid the penalty because no address check is necessary.
> that's rudimentary but efficient.
>

Sure in a 3 pipelines stages cpu not on 30 one.

> > > variable latency execution + lack of write back buffer/regis= ter renaming + atomic
> > > instruction =3D whole mess when an exception occurs.
> > > Finally a simple scoreboard is so simple.
> > "as written in the manual."  it is, but nothing is= explain ! What do the
> > scorebord here ?
> the scoreboard remembers which register is currently being computed. > if the decoder sees that you want to write or read a register that is = "not ready"
> (result is not known) it will wait until everything is ready and then = issue your
> instruction. This way, you may loose some time compared to your C6x re= ference,
> but you don't have to remember the latency of every execution unit whe= n you
> create a program. If the core changes, you don't have to recompile eve= rything,
> it can still be executed safely (even if it can be slower).
>

ok ok but what happen to the execution when a exeption happen.

> history :
> scoreboards were invented in the 50s or 60s, somebody will have to che= ck.
> the name is a reference to the boards that display the score of the te= ams
> on a playground, it is updated every time a point is won.
>
> scoreboards are used in computers as a natural way to block the execut= ion
> of software when a unit hazard can occur. If you read P&H, you'll = learn
> that MIPS (the CPU family) comes from "Machine without Interlocke= d Pipeline Stage" :
> they didn't have enough transistors on the chip to fit the scoreboard = and they
> relied on the compiler to generate "legal code".
>
> Otherwise, a scoreboard is the minimal system to implement when no sui= table
> compiler is available. Currently, for example, the GCC port does gener= ate
> ugly code and can't deal with delay slots adapted to the F-CPU schedul= ing,
> stalling the issue is "safe" even though it loses some cycle= s here or there...
>
> Ok i stop here ;-)
>

OKOKOK i understand scoreboard but what happen to the exeption !!

> > > > > > > > > > <...>
> > > > > > > > > > > WHYGEE
> > > > > > > > > > nicO
> > > > > > > > > WHYGEE
> > > > > > > > nicO
> > > > > > > WHYGEE
> > > > > > nicO
> > > > > YG
> > > > nicO which take a little more time before answering but= one hour per
> > > > days is enought ;p
> > > YG who restarted to play with Xlib and GNL interface :-))) > > > yeah ! i discovered how to handle colormaps ! :-D
> > nicO
> YG
nicO
Yahoo! Groups Spons= or
=0D=0D=0D=0D=0D
3D""3D""
=
www.  
=0D
3D""
From Yann Guidon Fri Feb 16 00:49:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01175 for ; Fri, 16 Feb 2001 00:59:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 00:59:57 +0100 (MET) Received: (qmail 2774 invoked by uid 0); 15 Feb 2001 23:42:48 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx16) with SMTP; 15 Feb 2001 23:42:48 -0000 X-eGroups-Return: sentto-1101623-2395-982280570-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 15 Feb 2001 23:42:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 15 Feb 2001 23:42:49 -0000 Received: (qmail 29750 invoked from network); 15 Feb 2001 23:42:48 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 Feb 2001 23:42:48 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 16 Feb 2001 00:43:53 -0000 Received: from f-cpu.org (nas2-38.bdx.club-internet.fr [195.36.133.38]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA07583 for ; Fri, 16 Feb 2001 00:42:12 +0100 (MET) Message-ID: <3A8C6B00.E033B828@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <001001c09269$f4f01510$29e65982@student.utwente.nl> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 00:49:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] The Role of Custom Design in ASIC Chips Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f6b83e17e540e641eeb550a9bd7c461e Status: R X-Status: N late answer,

Marco Al wrote:
> I found the following paper a nice read... the performance ratio's were
> especially interesting, of course not universally applicable but still
> interesting.
>
> ftp://cva.stanford.edu/pub/publications/dac00.pdf

yeah :-) NicO, have you read it ?

> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www. 
From Nicolas Boulay Fri Feb 16 20:29:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01116 for ; Fri, 16 Feb 2001 23:44:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 23:44:19 +0100 (MET) Received: (qmail 1637 invoked by uid 0); 16 Feb 2001 19:19:08 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx08) with SMTP; 16 Feb 2001 19:19:08 -0000 X-eGroups-Return: sentto-1101623-2396-982351110-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hi.egroups.com with NNFMP; 16 Feb 2001 19:18:31 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 16 Feb 2001 19:18:29 -0000 Received: (qmail 4644 invoked from network); 16 Feb 2001 19:18:28 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 16 Feb 2001 19:18:28 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 16 Feb 2001 19:18:28 -0000 Received: from ifrance.com (nas21-86.vlt.club-internet.fr [195.36.171.86]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA08788 for ; Fri, 16 Feb 2001 20:18:24 +0100 (MET) Message-ID: <3A8D7F8E.126784BB@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <001001c09269$f4f01510$29e65982@student.utwente.nl> <3A8C6B00.E033B828@f-cpu.org> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 20:29:18 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] to read ;p Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 83e869cf9f93ea197d4f0ec96144bf91 Status: R X-Status: N An extract from a manual ...

A-4 December, 2000 Developers Manual

Out Of Order Completion

Sequential consistency of instruction execution relates to two aspects:
first, to the order in which the instructions are completed; and second, to the order in which memory is accessed due to load and store
instructions. The Intel=AE XScale" core preserves a weak processor
consistency because instructions may complete out of order, provided
that no data dependencies exist. While instructions are issued in-order, the main execution pipeline, memory, and MAC pipelines are not
lock-stepped, and, therefore, have different execution times. This means that instructions may finish out of program order. Short =18younger=19
instructions may be finished earlier than long =18older=19 ones. (The term<= BR> =18to finish=19 is used here to indicate that the
operation has been completed and the result has been written back to the register file.)

A.2.1.4. Register Scoreboarding

In certain situations, the pipeline may need to be stalled because of
register dependencies between instructions. A register dependency occurs when a previous MAC or load instruction is about to modify a register
value that has not been returned to the register file and the current
instruction needs access to the same register. Only the destination of
MAC operations and memory loads are scoreboarded. The destinations of
ALU instructions are not scoreboarded.
If no register dependencies exist, the pipeline will not be stalled. For example, if a load operation
has missed the data cache, subsequent instructions that do not depend on the load may complete independently.

A.2.1.5. Use of Bypassing

The Intel=AE XScale" core pipeline makes extensive use of bypassing to=
minimize data hazards. Bypassing allows results forwarding from multiple sources, eliminating the need to stall the pipeline.
---------------------------------------------------------------------------= ----

But it's not the fcpu manual ! But a document from the Xscale
architecture from intel compatible with the StrongARM but run at 300-400 Mhz with 7 pipelines stages (compare to 5 for the StrongArm).

cf. ht= tp://developer.intel.com/design/intelxscale/273473.htm

---------------------------------------------------------------------------= ----

I have found a link to this tools, somebody have soon test it ? (It
supposed to compile and simulate VHDL, so ?)
http://www.g= nu.org/software/electric/electric.html

---------------------------------------------------------------------------= ----

http:/= /www.cynapps.com/CynApps/products/cynpp/index.html
Could be interresting, too. It's a big set of macro for C/C++ compiler
to produice "hardware code". It's not free but to test some featu= res,
why not ?

---------------------------------------------------------------------------= ----
Yahoo! Groups Spons= or
3D""3D"=
www.
3D""
From Yann Guidon Fri Feb 16 22:05:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01119 for ; Fri, 16 Feb 2001 23:44:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 23:44:20 +0100 (MET) Received: (qmail 25277 invoked by uid 0); 16 Feb 2001 20:59:11 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx18) with SMTP; 16 Feb 2001 20:59:11 -0000 X-eGroups-Return: sentto-1101623-2397-982357166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fj.egroups.com with NNFMP; 16 Feb 2001 20:59:27 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 16 Feb 2001 20:59:25 -0000 Received: (qmail 47093 invoked from network); 16 Feb 2001 20:59:24 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 16 Feb 2001 20:59:24 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta3 with SMTP; 16 Feb 2001 22:00:28 -0000 Received: from f-cpu.org (nas2-106.bdx.club-internet.fr [195.36.133.106]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA24116 for ; Fri, 16 Feb 2001 21:59:13 +0100 (MET) Message-ID: <3A8D9626.D708E4FB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <001001c09269$f4f01510$29e65982@student.utwente.nl> <3A8C6B00.E033B828@f-cpu.org> <3A8D7F8E.126784BB@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 22:05:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] to read ;p Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 233610799ba35ae9c6e84a4389ad9c46 Status: R X-Status: N hi !

Nicolas Boulay wrote:
> An extract from a manual ...
>
> A-4 December, 2000 Developers Manual
<...>

> -------------------------------------------------------------------------------
> But it's not the fcpu manual ! But a document from the Xscale
> architecture from intel compatible with the StrongARM but run at 300-400
> Mhz with 7 pipelines stages (compare to 5 for the StrongArm).
>
> cf. http://developer.intel.com/design/intelxscale/273473.htm

"compatible with the StrongARM" :
i think that we are safe here :-P

remember that the CDC6600 did what is described here,
30 years ago !

> -------------------------------------------------------------------------------
>
> I have found a link to this tools, somebody have soon test it ? (It
> supposed to compile and simulate VHDL, so ?)
> http://www.gnu.org/software/electric/electric.html

i have tested it (and some others IIRC)
and it is "no" for the early design phase.
it can't compile VHDL that it has not generated itself. berk.

ok i have to play with other stuffs.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www..com
From Yann Guidon Fri Feb 16 23:33:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01140 for ; Fri, 16 Feb 2001 23:44:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 16 Feb 2001 23:44:26 +0100 (MET) Received: (qmail 3580 invoked by uid 0); 16 Feb 2001 22:33:20 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx16) with SMTP; 16 Feb 2001 22:33:20 -0000 X-eGroups-Return: sentto-1101623-2398-982362394-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 16 Feb 2001 22:26:36 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 16 Feb 2001 22:26:33 -0000 Received: (qmail 5560 invoked from network); 16 Feb 2001 22:26:33 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 16 Feb 2001 22:26:33 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 16 Feb 2001 22:26:32 -0000 Received: from f-cpu.org (nas2-197.ras.club-internet.fr [195.36.192.197]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA23936 for ; Fri, 16 Feb 2001 23:26:29 +0100 (MET) Message-ID: <3A8DAAA0.963DBECE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <001001c09269$f4f01510$29e65982@student.utwente.nl> <3A8C6B00.E033B828@f-cpu.org> <3A8D7F8E.126784BB@ifrance.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 23:33:04 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] to read ;p Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 727f5507cc8aa77b87234d366387eae7 Status: R X-Status: N hi again !

Nicolas Boulay wrote:
> An extract from a manual ...
>
> A-4 December, 2000 Developers Manual
<...>

> But it's not the fcpu manual ! But a document from the Xscale
> architecture from intel compatible with the StrongARM but run at 300-400
> Mhz with 7 pipelines stages (compare to 5 for the StrongArm).
>
> cf. http://developer.intel.com/design/intelxscale/273473.htm
>

i have downloaded it and read it (well, partially : only the interesting parts).
there's nothing really new : most of the explained techniques are known for 10 years
and the Xscale is "only" a "enhancement" of the ARM core. Well, it looks like
a good direction and it's a shame we have to struggle with the x86.

However, even though the target "looks" like a FC0, it employs no new
groundbreaking technique. ARM in fact is a 16-bit core that has been extended
to handle a 32-bit model. OTOH the F-CPU is a very different core that competes
with a different class of CPUs. Xscale or SH-x do not scare me, Alpha and ia64
are more interesting targets :-P

Thank you anyway for the interesting reading.
i'll try to answer about the ARM comparison "ASAP" :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Fri Feb 16 18:49:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01786 for ; Sat, 17 Feb 2001 03:11:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Feb 2001 03:11:25 +0100 (MET) Received: (qmail 12248 invoked by uid 0); 17 Feb 2001 01:28:49 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx10) with SMTP; 17 Feb 2001 01:28:49 -0000 X-eGroups-Return: sentto-1101623-2399-982373347-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 17 Feb 2001 01:29:08 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 17 Feb 2001 01:29:06 -0000 Received: (qmail 49122 invoked from network); 17 Feb 2001 01:29:05 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 Feb 2001 01:29:05 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 17 Feb 2001 01:29:04 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA17776 for ; Fri, 16 Feb 2001 18:19:16 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8D6833.2BC12B03@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <001001c09269$f4f01510$29e65982@student.utwente.nl> <3A8C6B00.E033B828@f-cpu.org> <3A8D7F8E.126784BB@ifrance.com> <3A8D9626.D708E4FB@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 10:49:39 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] VDHL and other design entries Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 013ff797e9b0f43be80d1a0c8ab59c7b Status: R X-Status: N Yann Guidon wrote:

> > I have found a link to this tools, somebody have soon test it ? (It
> > supposed to compile and simulate VHDL, so ?)
> > http://www.gnu.org/software/electric/electric.html
>
> i have tested it (and some others IIRC)
> and it is "no" for the early design phase.
> it can't compile VHDL that it has not generated itself. berk.

I tried to use it but I could not figure out the GUI.
The main limitation is that there is no GOOD free libraries
for the VHDL compiler.The VHDL compiler also is a older design
that does not do multi-layers of routing.

Looking for a design entry program for my own use, I have not
found any thing in high level languages that lets you do a
hierarchical design on at the routing level.The Alliance package may
come close but the lack of documentation and the incomplete design
package hinders its use.

Having found a free manual design entry packing for Windows
I discovered it was not so free as it has $100 US book to go with
it. CMOS circuit design Layout and simulation. A very good book for both
analog & digital transistor / circuit design (1998)
but almost already out of date as the technologies keep getting
smaller and smaller. http://cmosedu.com/cmos1/book.htm
Since I am sick in bed I have time now to read the book.

Some things I have noticed is that I/O delay from the chip to the real
world is about the same for all technologies used.This bottleneck
needs to kept in mind as this can limit speed.Also one example
they give a 3.5x size difference between and standard cell and
custom layout. Here smaller is faster.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
.com
    
From David Cary Sat Feb 17 19:06:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08019 for ; Sun, 18 Feb 2001 09:10:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:22 +0100 (MET) Received: (qmail 19295 invoked by uid 0); 17 Feb 2001 19:07:43 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx04) with SMTP; 17 Feb 2001 19:07:43 -0000 X-eGroups-Return: sentto-1101623-2400-982436894-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 17 Feb 2001 19:08:16 -0000 X-Sender: d.cary@ieee.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 17 Feb 2001 19:08:13 -0000 Received: (qmail 71073 invoked from network); 17 Feb 2001 19:08:12 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 Feb 2001 19:08:12 -0000 Received: from unknown (HELO mail4.primary.net) (216.87.38.199) by mta3 with SMTP; 17 Feb 2001 20:09:17 -0000 Received: from [192.168.1.40] (ip51-tc2.Busprod.Com [207.150.72.51]) by mail4.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id f1HJ8Rl11984 for ; Sat, 17 Feb 2001 13:08:27 -0600 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: In-Reply-To: References: <20000919013055.06244@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Feb 2001 13:06:06 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f4e5c45f6b51d896a83912cad585484e Status: R X-Status: N
Dear open CPU designers,

I agree with Yann Guidon that the initially we should just stick with a
simple algorithm for the first implementation.
The LRU algorithm described by Michael Riepe <michael@stud.uni-hannover.de>
on 2000-09-19 looks nice and simple.

I've been wondering about how to recognize when LRU is not the best
algorithm. Sometimes a piece of data is read from some input port, scanned
once, sent out some output port, and never used again. For example,
routers. A really smart cache would avoid wasting more than 1 cache lines
on this never-used-again data, to avoid flushing data that really will be
used again.

Is there any way to recognize common patterns in hardware, so that one
doesn't have to write special software to control the cache ?

We already have hardware that recognizes the difference between
"instructions" and "data", and (almost always) stores them only in their
own cache.

It is pretty simple (at least on the f-cpu) for hardware to recognize the
beginning and end of subroutines and loops. I think that if you can't cache
an entire subroutine (or an entire loop), it's much more important to cache
the first part of the subroutine (in other words, the program addresses to
which jump instructions point) than the last part, even though the last
part is the Least Recently Used. If the first instruction is flushed, then
a call to that subroutine (or a loop back to the next iteration) stalls
until that instruction is fetched, no matter how much of the rest of the
subroutine is sitting in cache. But if the first few instructions are
cached, then it might be possible to pre-fetch the rest while those
instructions are being executed.

Then there is the "read-ahead" concept -- in a piece of code that calls the
subroutine, the instructions after the call instruction are more important
to keep in the cache than the call instruction itself or the previous
instructions. Even though these previous instructions have been used more
recently than the following instructions (and in fact the following
instructions may never have been used yet).

I think it's pretty simple for hardware to recognize "data addresses" (
memory locations that are loaded and then used as the address to load other
memory locations) vs "other data". I suspect that addresses are re-used
more than other data.

Please don't allow this tangential speculation on ways to improve cache get
in the way of the critical path of the first f-cpu implementation (with a
simple cache).

>From: Steve Van der Hoeven <vanderho@essi.fr>
>Date: Mon, 18 Sep 2000 18:49:19 -0500 (CDT)
>Subject: [f-cpu] caching technics...
...
>If it has not been yet discussed, we could try to think about all the
>solutions we have or might imagine.
>
>  First how big do we want the caches to be.

As big as possible. Duh. :-)
...
> So we should also try to see the relation between memory caching
>algorithms and the software we would like to see on the f-cpu.

Of course, sometimes bigger caches run slightly slower, so there is a
trade-off that is heavily dependent on the actual program being executed.
We will benchmark different proposals against (relatively) realistic
programs.

...
>--Steve

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://rdrop.com/~cary/
"icbmto:N36.1560 W95.7945"
Yahoo! Groups Sponsor

www.

From Ben Franchuk Sat Feb 17 00:05:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08022 for ; Sun, 18 Feb 2001 09:10:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:23 +0100 (MET) Received: (qmail 25605 invoked by uid 0); 17 Feb 2001 19:33:53 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx11) with SMTP; 17 Feb 2001 19:33:53 -0000 X-eGroups-Return: sentto-1101623-2401-982438458-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 17 Feb 2001 19:34:19 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 17 Feb 2001 19:34:18 -0000 Received: (qmail 28747 invoked from network); 17 Feb 2001 19:34:17 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 Feb 2001 19:34:17 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 17 Feb 2001 19:34:17 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA22725 for ; Sat, 17 Feb 2001 12:24:26 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8DB24A.E69D1AFC@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20000919013055.06244@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Feb 2001 16:05:46 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: bc7b9d425213beb8ef25ae995827b66b Status: R X-Status: N David Cary wrote:
> We already have hardware that recognizes the difference between
> "instructions" and "data", and (almost always) stores them only in their
> own cache.
Would it be possible to reserve some external cache memory
for critical OS kernel and I/O handling calls, that need
to start/stop I?O quickly like DMA or Task Semphores.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
From Rares Marian Sun Feb 18 00:17:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08052 for ; Sun, 18 Feb 2001 09:10:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:31 +0100 (MET) Received: (qmail 5469 invoked by uid 0); 17 Feb 2001 23:21:39 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx05) with SMTP; 17 Feb 2001 23:21:39 -0000 X-eGroups-Return: sentto-1101623-2402-982451474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 17 Feb 2001 23:11:16 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 17 Feb 2001 23:11:14 -0000 Received: (qmail 15866 invoked from network); 17 Feb 2001 23:11:13 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 17 Feb 2001 23:11:13 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 18 Feb 2001 00:12:18 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 8AF353BD02B; Sat, 17 Feb 2001 18:17:36 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010217181735.A15452@moonbase.res.wpi.net> References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> In-Reply-To: <3A8DB24A.E69D1AFC@jetnet.ab.ca>; from bfranchuk@jetnet.ab.ca on Fri, Feb 16, 2001 at 18:05:46 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Feb 2001 18:17:35 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: cbdc2d79ee30618324ac2aeeddccd2e0 Status: R X-Status: N
On Fri, 16 Feb 2001 18:05:46 Ben Franchuk wrote:
> David Cary wrote:
> > We already have hardware that recognizes the difference between
> > "instructions" and "data", and (almost always) stores them only in
> their
> > own cache.
> Would it be possible to reserve some external cache memory
> for critical OS kernel and I/O handling calls, that need
> to start/stop I?O quickly like DMA or Task Semphores.

MIPS seems to do that in its registers.

> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
>
>


Yahoo! Groups Sponsor
 .com 
From Yann Guidon Sun Feb 18 00:56:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08064 for ; Sun, 18 Feb 2001 09:10:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:34 +0100 (MET) Received: (qmail 13447 invoked by uid 0); 17 Feb 2001 23:50:25 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx16) with SMTP; 17 Feb 2001 23:50:25 -0000 X-eGroups-Return: sentto-1101623-2403-982453858-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by b05.egroups.com with NNFMP; 17 Feb 2001 23:50:59 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 17 Feb 2001 23:50:58 -0000 Received: (qmail 46611 invoked from network); 17 Feb 2001 23:50:57 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 17 Feb 2001 23:50:57 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 17 Feb 2001 23:50:57 -0000 Received: from f-cpu.org (nas1-180.ras.club-internet.fr [195.36.192.180]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA16112 for ; Sun, 18 Feb 2001 00:50:53 +0100 (MET) Message-ID: <3A8F0FC7.64C2EF11@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> <20010217181735.A15452@moonbase.res.wpi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 00:56:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 81c7f3cbff46bf4bd02708e8831d11b8 Status: R X-Status: N Hi there !

OT :
i'm trying to install a new PCI modem that does sustain 45K compared to
my old 28K one :-) it it rather simple under W$, execept that the driver
causes the system to hang... but i never bothered about Linux and now i
have to read (at last) the HOWTOs. that's pretty crazy because it sits
on IRQ 12 at base IO address 0xe800. Guess why F-CPU will be so good ?
because i'm REALLY PISSED OFF WITH PC SHIT :-P This is the engineering
level #0. Now we gotta stay at higher engineering levels because
instinctive reactions might let us do more fucked up things.

Rares Marian wrote:
> On Fri, 16 Feb 2001 18:05:46 Ben Franchuk wrote:
> > David Cary wrote:
> > > We already have hardware that recognizes the difference between
> > > "instructions" and "data", and (almost always) stores them only in their
> > > own cache.
> > Would it be possible to reserve some external cache memory
> > for critical OS kernel and I/O handling calls, that need
> > to start/stop I?O quickly like DMA or Task Semphores.
> MIPS seems to do that in its registers.

F-CPU/FC0 provide several mechanisms :
- memory streams (3 bits in the instructions) that should be set
by the programer. This is a serious hint and can do wonders (i wish i had
them before). It separates the real streams from the "casual" access
in a "portable" way (no matter how it is implemented). A "stream" is
a "predictible" access pattern to memory (linear is simplest and should
be used as much as possible, butterflies and variable strides could appear
however). Load/store instructions also have a "cachability" bit !
- cache locking (see cachemm instructions). if i can do what i have
in mind, 1/4 of the cache memory could be locked.
- Semaphores should be done with Special Registers. This separates
the HW from the SW and avoids all pipeline hazards.

Dave spoke about HW that would recognize "common patterns" :
this is what is done in the LSU. When a load/store+update is decoded,
the sign of the immediate value or the register is used as a preliminary
"hint" about the direction of the pointer update, so it can help the
HW to pre-load new consecutive cache lines.

In the T3D (Cray with Alpha Inside), each Cnode has an advanced memory
controller that detects "streams" : when two consecutive L3 cache misses
are detected with consecutive addresses, the controller triggers a
big memory "dump" of the large DRAM. The LSU works a bit like that
but it has to play with only 8 lines so it adds double-buffering on top
of that (as to avoid too much thrashing). The Fetcher is similar but
its job simpler for the stream prediction :-) branches are difficult however.


If you have good ideas (objective additions to the existing model)
it will be interesting to speak about it. Memory and bad instruction
scheduling are the two main reasons for the SW bad performance...

have fun,

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www. .com 
From Rares Marian Sun Feb 18 02:36:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08082 for ; Sun, 18 Feb 2001 09:10:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:38 +0100 (MET) Received: (qmail 9362 invoked by uid 0); 18 Feb 2001 01:29:43 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx18) with SMTP; 18 Feb 2001 01:29:43 -0000 X-eGroups-Return: sentto-1101623-2404-982459818-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 18 Feb 2001 01:30:19 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 18 Feb 2001 01:30:16 -0000 Received: (qmail 30881 invoked from network); 18 Feb 2001 01:30:16 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Feb 2001 01:30:16 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 18 Feb 2001 01:30:15 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 529BD3BD02B; Sat, 17 Feb 2001 20:36:39 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010217203639.C15452@moonbase.res.wpi.net> References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> <20010217181735.A15452@moonbase.res.wpi.net> <3A8F0FC7.64C2EF11@f-cpu.org> In-Reply-To: <3A8F0FC7.64C2EF11@f-cpu.org>; from whygee@f-cpu.org on Sat, Feb 17, 2001 at 18:56:55 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Feb 2001 20:36:39 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 72cad05b42b1900c86b584d3558fcd61 Status: R X-Status: N Ha!

I lost my faith in centralized hardware (amiga rules).

On Sat, 17 Feb 2001 18:56:55 Yann Guidon wrote:
> Hi there !
>
> OT :
> i'm trying to install a new PCI modem that does sustain 45K compared to
> my old 28K one :-) it it rather simple under W$, execept that the driver
> causes the system to hang... but i never bothered about Linux and now i
> have to read (at last) the HOWTOs. that's pretty crazy because it sits
> on IRQ 12 at base IO address 0xe800. Guess why F-CPU will be so good ?
> because i'm REALLY PISSED OFF WITH PC SHIT :-P This is the engineering
> level #0. Now we gotta stay at higher engineering levels because
> instinctive reactions might let us do more fucked up things.
>

Linux PnP blows Windows PnP nowadays.  Which version you got?
Yahoo! Groups Sponsor

www.   
From Ben Franchuk Sat Feb 17 21:59:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA08085 for ; Sun, 18 Feb 2001 09:10:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 09:10:39 +0100 (MET) Received: (qmail 6080 invoked by uid 0); 18 Feb 2001 02:25:30 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx25) with SMTP; 18 Feb 2001 02:25:30 -0000 X-eGroups-Return: sentto-1101623-2405-982463132-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 18 Feb 2001 02:25:33 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 18 Feb 2001 02:25:31 -0000 Received: (qmail 30384 invoked from network); 18 Feb 2001 02:25:30 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 18 Feb 2001 02:25:30 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 18 Feb 2001 02:25:29 -0000 Received: from jetnet.ab.ca (dialin57.jetnet.ab.ca [207.153.6.57]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA14106 for ; Sat, 17 Feb 2001 19:15:43 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8EE62A.FCA49B2F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> <20010217181735.A15452@moonbase.res.wpi.net> <3A8F0FC7.64C2EF11@f-cpu.org> <20010217203639.C15452@moonbase.res.wpi.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Feb 2001 13:59:22 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ac520a70e073b474758c9bc24dd9e00 Status: R X-Status: N Rares Marian wrote:
>
Boy am I glad I got a external modem. :)
Linux while faster than M$ is harder to set a modem
up for internet access.Be careful as many linux's
claim to be internet upgradeable are only with
a specific network card to the net.
Ben.
Linix  - 2 months to set up ... No crashing
Window - 30 minutes to set up ... cashing every 30 minutes
there after.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.
From Yann Guidon Sun Feb 18 17:34:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA09702 for ; Sun, 18 Feb 2001 18:07:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 18:07:00 +0100 (MET) Received: (qmail 15425 invoked by uid 0); 18 Feb 2001 16:27:46 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx07) with SMTP; 18 Feb 2001 16:27:46 -0000 X-eGroups-Return: sentto-1101623-2406-982513708-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 18 Feb 2001 16:28:30 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 18 Feb 2001 16:28:27 -0000 Received: (qmail 96026 invoked from network); 18 Feb 2001 16:28:27 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 18 Feb 2001 16:28:27 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 18 Feb 2001 16:28:26 -0000 Received: from f-cpu.org (nas4-159.pau.club-internet.fr [195.36.133.159]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA14438 for ; Sun, 18 Feb 2001 17:28:23 +0100 (MET) Message-ID: <3A8FF991.3D7C3968@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> <20010217181735.A15452@moonbase.res.wpi.net> <3A8F0FC7.64C2EF11@f-cpu.org> <20010217203639.C15452@moonbase.res.wpi.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 17:34:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 037bbdb70d1748c5eb0cc1cc91c20f0c Status: R X-Status: N hi !

Rares Marian wrote:
> Ha!
>
> I lost my faith in centralized hardware (amiga rules).
and f-cpu will blast'em ;-P

> On Sat, 17 Feb 2001 18:56:55 Yann Guidon wrote:
> > Hi there !
> >
> > OT :
<snip modem story>
> Linux PnP blows Windows PnP nowadays.  Which version you got?
SuSE 6.3.

But it's interesting to see how the discussion switched to
PC bashing, it has become uninteresting.


WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.
From Ben Franchuk Sun Feb 18 03:25:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA09705 for ; Sun, 18 Feb 2001 18:07:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 18 Feb 2001 18:07:01 +0100 (MET) Received: (qmail 28394 invoked by uid 0); 18 Feb 2001 16:55:53 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx22) with SMTP; 18 Feb 2001 16:55:53 -0000 X-eGroups-Return: sentto-1101623-2407-982515395-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 18 Feb 2001 16:56:36 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 18 Feb 2001 16:56:34 -0000 Received: (qmail 57784 invoked from network); 18 Feb 2001 16:56:33 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 18 Feb 2001 16:56:33 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 18 Feb 2001 16:56:31 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA04628 for ; Sun, 18 Feb 2001 09:46:38 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A8F3294.33510EDA@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20000919013055.06244@thrai.stud.uni-hannover.de> <3A8DB24A.E69D1AFC@jetnet.ab.ca> <20010217181735.A15452@moonbase.res.wpi.net> <3A8F0FC7.64C2EF11@f-cpu.org> <20010217203639.C15452@moonbase.res.wpi.net> <3A8FF991.3D7C3968@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 17 Feb 2001 19:25:24 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 76c9bb344335a75acdbd84f0f9b06381 Status: R X-Status: N Yann Guidon wrote:
> But it's interesting to see how the discussion switched to
> PC bashing, it has become uninteresting.
Its more fun anyhow to drop it out the window of a high building
instead. Bashing is not that much fun, unless you have nice hefty
club.
The problem with the PC and other Computers of that
era is that they were making 300% profit at that time.
http://www.hypermall.com/History/ah05.html
While some designs where innovative to save costs
most designs used the cheapest parts ( 6502 , 8086 )
and scrimped on things like address decoding and
usable I/O. Your $2K PC from IBM had floppy disk and monitor
and >64K memory extra you know.
So rather than BASHING PC's lets just bash GREED instead
cause the is where the problem is.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

www.

From Mon Feb 19 01:00:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12206 for ; Mon, 19 Feb 2001 09:28:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:30 +0100 (MET) Received: (qmail 32619 invoked by uid 0); 19 Feb 2001 00:13:23 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx17) with SMTP; 19 Feb 2001 00:13:23 -0000 X-eGroups-Return: sentto-1101623-2408-982541647-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 19 Feb 2001 00:14:08 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 00:14:06 -0000 Received: (qmail 50862 invoked from network); 18 Feb 2001 23:53:56 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Feb 2001 23:53:56 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 18 Feb 2001 23:53:56 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 257AA3BD028 for ; Sun, 18 Feb 2001 19:00:28 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <3A8FF991.3D7C3968@f-cpu.org> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 19:00:27 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3836d202177531e10f74d08666da07ad Status: R X-Status: N On Sun, 18 Feb 2001, Yann Guidon wrote:

> hi !
>
> Rares Marian wrote:
> > Ha!
> >
> > I lost my faith in centralized hardware (amiga rules).
> and f-cpu will blast'em ;-P

Nate's gonna be tough to beat.  Using MIPS core.

> > On Sat, 17 Feb 2001 18:56:55 Yann Guidon wrote:
> > > Hi there !
> > >
> > > OT :
> <snip modem story>
> > Linux PnP blows Windows PnP nowadays.  Which version you got?
> SuSE 6.3.
>
> But it's interesting to see how the discussion switched to
> PC bashing, it has become uninteresting.
>
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>


Yahoo! Groups Sponsor
3 DVDs for ONLY 49 cents each!
3 DVDs for ONLY 49 cents each!
From Mon Feb 19 01:01:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12209 for ; Mon, 19 Feb 2001 09:28:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:30 +0100 (MET) Received: (qmail 3097 invoked by uid 0); 19 Feb 2001 00:20:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx08) with SMTP; 19 Feb 2001 00:20:06 -0000 X-eGroups-Return: sentto-1101623-2409-982541869-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 19 Feb 2001 00:17:55 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 00:17:49 -0000 Received: (qmail 82335 invoked from network); 18 Feb 2001 23:55:24 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 18 Feb 2001 23:55:24 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 18 Feb 2001 23:55:23 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 16C2F3BD028 for ; Sun, 18 Feb 2001 19:01:56 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <3A8F3294.33510EDA@jetnet.ab.ca> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 19:01:56 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e09eac0dbcbfc4edab31d6b0d490408f Status: R X-Status: N On Sat, 17 Feb 2001, Ben Franchuk wrote:

> Yann Guidon wrote:
> > But it's interesting to see how the discussion switched to
> > PC bashing, it has become uninteresting.
> Its more fun anyhow to drop it out the window of a high building
> instead. Bashing is not that much fun, unless you have nice hefty
> club.
> The problem with the PC and other Computers of that
> era is that they were making 300% profit at that time.
> http://www.hypermall.com/History/ah05.html
> While some designs where innovative to save costs
> most designs used the cheapest parts ( 6502 , 8086 )
> and scrimped on things like address decoding and
> usable I/O. Your $2K PC from IBM had floppy disk and monitor
> and >64K memory extra you know.
> So rather than BASHING PC's lets just bash GREED instead
> cause the is where the problem is.

Nah bash the PC.  GREED goes bith ways.

>


Yahoo! Groups Sponsor
Click Here
From jeff@llandre.freeserve.co.uk Mon Feb 19 02:07:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12212 for ; Mon, 19 Feb 2001 09:28:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:31 +0100 (MET) Received: (qmail 14227 invoked by uid 0); 19 Feb 2001 01:07:36 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx11) with SMTP; 19 Feb 2001 01:07:36 -0000 X-eGroups-Return: sentto-1101623-2410-982544899-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by cj.egroups.com with NNFMP; 19 Feb 2001 01:08:20 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 01:08:18 -0000 Received: (qmail 10729 invoked from network); 19 Feb 2001 01:08:15 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 19 Feb 2001 01:08:15 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 19 Feb 2001 02:09:19 -0000 Received: from modem-12.fermium.dialup.pol.co.uk ([62.136.69.140] helo=62.136.69.140) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14Ueck-0002eD-00 for f-cpu@egroups.com; Mon, 19 Feb 2001 00:56:19 +0000 To: f-cpu@yahoogroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Feb 2001 1:07 +0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90967e9fec419c77a10b579bdc68b145 Status: R X-Status: N --------------Replied message--------------
Date: Sun, 18 Feb 2001 19:00:27 -0500 (EST)
From: rares@moonbase.res.wpi.net
To: f-cpu@yahoogroups.com
Subject: Re: [f-cpu] cache techniques

On Sun, 18 Feb 2001, Yann Guidon wrote:

> hi !
>
> Rares Marian wrote:
> > Ha!
Nate's gonna be tough to beat.  Using MIPS core.
** Mips architecture isnt free ip. fcpu architecture is free.
** Just that there arent any implementations yet. But there
** will be. Happily free software will run on your chip
** whether its all or partially free, or even completely
** proprietary.

> But it's interesting to see how the discussion switched to
> PC bashing, it has become uninteresting.

The x86 is amazingly crap tho, and as a result someone did
a study that showed that growth in greenhouse gases could
be eliminated if all pcs had risc as opposed to x86 in them.
Figures seemed to add up.

Certainly the same crappiness has infected visual c++
and mfc that I work with.
The whole industry reminds me very much of british
motorbikes in the 70s. Promising everything, delivering close
to nothing, just overbored and less reliable versions
of the old tat. This industry is ripe for a takeover.

Gimme unix/linux on a risc anyday (oh and make it a laptop).
Jeff Davies.
Yahoo! Groups Sponsor

www.   
From Mon Feb 19 03:20:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12215 for ; Mon, 19 Feb 2001 09:28:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:32 +0100 (MET) Received: (qmail 15964 invoked by uid 0); 19 Feb 2001 02:21:45 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx09) with SMTP; 19 Feb 2001 02:21:45 -0000 X-eGroups-Return: sentto-1101623-2411-982549307-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 19 Feb 2001 02:21:48 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 02:21:46 -0000 Received: (qmail 69270 invoked from network); 19 Feb 2001 02:14:19 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 19 Feb 2001 02:14:19 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 19 Feb 2001 02:14:19 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 38EE43BD028 for ; Sun, 18 Feb 2001 21:20:50 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 21:20:50 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: RE: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: acfb3be38354298fceb5984356d3eef8 Status: R X-Status: N On Mon, 19 Feb 2001 jeff@llandre.freeserve.co.uk wrote:

> --------------Replied message--------------
> Date: Sun, 18 Feb 2001 19:00:27 -0500 (EST)
> From: rares@moonbase.res.wpi.net
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] cache techniques
>
> On Sun, 18 Feb 2001, Yann Guidon wrote:
>
> > hi !
> >
> > Rares Marian wrote:
> > > Ha!
> Nate's gonna be tough to beat.  Using MIPS core.
> ** Mips architecture isnt free ip. fcpu architecture is free.
> ** Just that there arent any implementations yet. But there
> ** will be. Happily free software will run on your chip
> ** whether its all or partially free, or even completely
> ** proprietary.

He's not reinventing MIPS.  He's using an available chip.

> > But it's interesting to see how the discussion switched to
> > PC bashing, it has become uninteresting.
>
> The x86 is amazingly crap tho, and as a result someone did
> a study that showed that growth in greenhouse gases could
> be eliminated if all pcs had risc as opposed to x86 in them.
> Figures seemed to add up.
>
> Certainly the same crappiness has infected visual c++
> and mfc that I work with.
> The whole industry reminds me very much of british
> motorbikes in the 70s. Promising everything, delivering close
> to nothing, just overbored and less reliable versions
> of the old tat. This industry is ripe for a takeover.
>
> Gimme unix/linux on a risc anyday (oh and make it a laptop).
> Jeff Davies.
>
>
>
>
>


Yahoo! Groups Sponsor
Click Here!
From Ben Franchuk Mon Feb 19 02:09:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12218 for ; Mon, 19 Feb 2001 09:28:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:32 +0100 (MET) Received: (qmail 10935 invoked by uid 0); 19 Feb 2001 03:06:37 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx05) with SMTP; 19 Feb 2001 03:06:37 -0000 X-eGroups-Return: sentto-1101623-2412-982551155-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 19 Feb 2001 02:52:36 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 02:52:34 -0000 Received: (qmail 50238 invoked from network); 19 Feb 2001 02:52:00 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 19 Feb 2001 02:52:00 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 19 Feb 2001 02:51:59 -0000 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA01230 for ; Sun, 18 Feb 2001 19:41:57 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A907231.236AA0C2@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 18:09:05 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 79568a889d196ff17b093eb473bee563 Status: R X-Status: N rares@moonbase.res.wpi.net wrote:

> He's not reinventing MIPS.  He's using an available chip.
>> Promising everything, delivering close
> > to nothing, just overbored and less reliable versions
> > of the old tat. This industry is ripe for a takeover.
*******  GET RID OF SLOW POWER HUNGERY TRANSISTORS **********
While surfing a page I found this claim made:
"Vacuum Microelectronics Links
Vacuum microelectronics has been one of the most obscure niches of electronic
research,and one with some of the most amazing potential.
Imagine flat panel CRT's as large as you want, and vacuum tube integrated
circuits with 10,000 microtubes in a circular millimeter,than can run at up to
one terahertz. Not megahertz, not gigahertz,but terahertz, one trillion Hertz!
Makes a Pentium look pretty lame by comparison, huh?
"
Most of the links however are broken, but THZ is fast.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Thousands of FREE Products after Rebate!
From David Cary Mon Feb 19 04:25:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12221 for ; Mon, 19 Feb 2001 09:28:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:33 +0100 (MET) Received: (qmail 9706 invoked by uid 0); 19 Feb 2001 04:26:35 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx13) with SMTP; 19 Feb 2001 04:26:35 -0000 X-eGroups-Return: sentto-1101623-2413-982556843-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 19 Feb 2001 04:27:25 -0000 X-Sender: d.cary@ieee.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 04:27:22 -0000 Received: (qmail 58452 invoked from network); 19 Feb 2001 04:27:18 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 19 Feb 2001 04:27:18 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta3 with SMTP; 19 Feb 2001 05:28:22 -0000 Received: from [192.168.1.40] (ip30-tc1.Busprod.Com [207.150.72.30]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id f1J4Qvk07519; Sun, 18 Feb 2001 22:26:57 -0600 X-Sender: cary@www.rdrop.com (Unverified) Message-Id: In-Reply-To: <200006211542.MAA04861@pisa.rockefeller.edu> To: MISC@pisa.rockefeller.edu Cc: f-cpu@yahoogroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 22:25:43 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] CPUs on FPGAs Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 648dd4d5bd46c3458aff7bcbb3763634 Status: R X-Status: N
Dear CPU connoisseurs,

Many moons ago John Griessen asked:
>Any one else ... using FPGA's to make custom processors/glue logic?

I've been collecting a list at
  http://rdrop.com/~cary/html/computer_architecture.html#FPGA
.

I suspect that
  http://www.fpgacpu.org/
updates their web pages far more frequently than I do. If only they had
been online when I started ...

--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://rdrop.com/~cary/
"icbmto:N36.1560 W95.7945"
Yahoo! Groups Sponsor
From joel_rosefield@yahoo.com Sat Feb 19 10:02:21 2005 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA12233 for ; Mon, 19 Feb 2001 09:28:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 09:28:36 +0100 (MET) Received: (qmail 12141 invoked by uid 0); 19 Feb 2001 06:41:00 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx08) with SMTP; 19 Feb 2001 06:41:00 -0000 X-eGroups-Return: sentto-1101623-2414-982564906-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 19 Feb 2001 06:41:47 -0000 X-Sender: grl672money5120@address.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 06:41:45 -0000 Received: (qmail 13195 invoked from network); 19 Feb 2001 06:41:44 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 19 Feb 2001 06:41:44 -0000 Received: from unknown (HELO ychat.pe.kr) (203.232.190.47) by mta1 with SMTP; 19 Feb 2001 06:41:44 -0000 Received: from 216.3.181.32 (01-032.031.popsite.net [216.3.181.32]) by ychat.pe.kr (8.9.3/8.9.3) with SMTP id PAA32025; Mon, 19 Feb 2001 15:13:17 +0900 Message-ID: <0000466a0391$000012f8$000057b1@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: grl672money5120@address.com From: joel_rosefield@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 19 Feb 2005 01:02:21 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] We'll Teach You! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 0d8ec531c845ca34f57f300715982da2 Status: R X-Status: N TIRED OF WORKING FOR SOMEONE ELSE?


Enjoy the Benefits of Working from Home!
Build a Financial Future For You and Your Family!
Learn How to Make Money the way banks and millionaires do!

The Money is NOT in working for someone else,
it is IN letting your money work for you.

Earn 16-36% or more on your money in safe
government securities.
The rich have been doing it for decades!


This is NOT rocket science.

If you can read, you can do this!

(Click Reply) with Name, Address,
Phone # and the Best Time to Reach You!
Please give brief description of why you
are looking for a money making opportunity.
How long you have been looking,
What type of  investing have you done before. (if any).


To be removed from future mailings please reply
with the word "remove" in the subject field.



















TIRED OF WORKING FOR SOMEONE ELSE?


Enjoy the Benefits of Working from Home!
Build a Financial Future For You and Your Family!
Learn How to Make Money the way banks and millionaires do!
Yahoo! Groups Sponsor
www.
From "Marco Al" Mon Feb 19 11:54:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12840 for ; Mon, 19 Feb 2001 14:17:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 14:17:07 +0100 (MET) Received: (qmail 31171 invoked by uid 0); 19 Feb 2001 10:44:52 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx04) with SMTP; 19 Feb 2001 10:44:52 -0000 X-eGroups-Return: sentto-1101623-2415-982579543-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 19 Feb 2001 10:45:44 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 10:45:42 -0000 Received: (qmail 14008 invoked from network); 19 Feb 2001 10:45:19 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Feb 2001 10:45:19 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 19 Feb 2001 11:46:23 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 7E03B2935 for ; Mon, 19 Feb 2001 11:45:18 +0100 (CET) Message-ID: <001301c09a62$5778c920$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Feb 2001 11:54:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6d60e54b60ca86395377ef34198cf732 Status: R X-Status: N From: <jeff@llandre.freeserve.co.uk>

> The x86 is amazingly crap tho

Is x86 much worse MIPS/Watt wise than say Alpha? I kinda doubt it.

Marco
Yahoo! Groups Sponsor
www. .com 
From Mon Feb 19 12:50:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12843 for ; Mon, 19 Feb 2001 14:17:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 14:17:08 +0100 (MET) Received: (qmail 29161 invoked by uid 0); 19 Feb 2001 11:43:12 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx24) with SMTP; 19 Feb 2001 11:43:12 -0000 X-eGroups-Return: sentto-1101623-2416-982583052-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 19 Feb 2001 11:44:12 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 11:44:11 -0000 Received: (qmail 88657 invoked from network); 19 Feb 2001 11:43:40 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 19 Feb 2001 11:43:40 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 19 Feb 2001 11:43:40 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 52C843BD028 for ; Mon, 19 Feb 2001 06:50:16 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <001301c09a62$5778c920$29e65982@student.utwente.nl> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Feb 2001 06:50:15 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f6b3b90b590fcd133634a60d8cea4c64 Status: R X-Status: N On Mon, 19 Feb 2001, Marco Al wrote:

> From: <jeff@llandre.freeserve.co.uk>
>
> > The x86 is amazingly crap tho
>
> Is x86 much worse MIPS/Watt wise than say Alpha? I kinda doubt it.
>
> Marco

Watts don't cost me the same amount of pain and nausea as coding in x86,
and coding for APIs built on the PC. 

Give me RISC and hell give me amiga.

rares

>
>
>
>


Yahoo! Groups Sponsor
www.
From Yann GUIDON Mon Feb 19 14:36:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA12973 for ; Mon, 19 Feb 2001 14:53:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 19 Feb 2001 14:53:43 +0100 (MET) Received: (qmail 17460 invoked by uid 0); 19 Feb 2001 13:42:21 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx13) with SMTP; 19 Feb 2001 13:42:21 -0000 X-eGroups-Return: sentto-1101623-2418-982590195-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 19 Feb 2001 13:43:16 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 13:43:14 -0000 Received: (qmail 89439 invoked from network); 19 Feb 2001 13:43:08 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 19 Feb 2001 13:43:08 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 19 Feb 2001 13:43:08 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA28327; Mon, 19 Feb 2001 05:43:02 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 163PPNJQ; Mon, 19 Feb 2001 13:48:10 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A912157.AC11B97E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Feb 2001 14:36:23 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ecee3d9c45bfb59a510068601024ec2b Status: R X-Status: N jeff@llandre.freeserve.co.uk wrote:
> > > The x86 is amazingly crap tho
> > Is x86 much worse MIPS/Watt wise than say Alpha? I kinda doubt it.
it's also a matter of market target :-) the Alphas i know require a dedicated
fan and a HUGE heat exchanger (it often gets very dusty). But it can get
so much more "good" work done at the same core speed...

> > Marco
>
> Actually, x86 is much worse than powerpc.
good news ;-)

> I know since
> I was (professionally) working using an elan400 (486)
> module, and by moving to a MUCH MUCH faster
> powerpc, the watts would reduced to 20% of previous amount.
new silicon technologies helps, however...

> So yes, x86 really is really crap (try writing asm for it),
> which is why intel is trying to get ia64 operational.
And Intel is crap, since they can't make both work ;-)

> Also, why is the asm keyword MOV used for an operation
> that is actually a COPY???
good point of the day...
that has bothered me when I was young and started to
learn the 6809 asm...

> Jeff Davies
> on his nokia9110i (486).
running a linux ? :-)

YG

speaking for himself
Yahoo! Groups Sponsor
www.
From "Marco Al" Mon Feb 19 15:31:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA14672 for ; Tue, 20 Feb 2001 05:35:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Feb 2001 05:35:37 +0100 (MET) Received: (qmail 23144 invoked by uid 0); 19 Feb 2001 14:22:51 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx02) with SMTP; 19 Feb 2001 14:22:51 -0000 X-eGroups-Return: sentto-1101623-2419-982592625-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 19 Feb 2001 14:23:46 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 14:23:45 -0000 Received: (qmail 91667 invoked from network); 19 Feb 2001 14:22:46 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 19 Feb 2001 14:22:46 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta3 with SMTP; 19 Feb 2001 15:23:50 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id 1DFBB2939 for ; Mon, 19 Feb 2001 15:22:45 +0100 (CET) Message-ID: <001201c09a80$b807e370$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Feb 2001 15:31:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 979ed5681580fe53999d6f4cac7e4aaf Status: R X-Status: N From: <jeff@llandre.freeserve.co.uk>

> Actually, x86 is much worse than powerpc. I know since
> I was (professionally) working using an elan400 (486)
> module, and by moving to a MUCH MUCH faster
> powerpc, the watts would reduced to 20% of previous
> amount.

Low power has its own considerations, and RISC isnt the best suited for it for
that matter... not without instruction compression. Anyway IDT's or Rise's chips
would be more fair to compare to PowerPC.

IMO ISA's are essentially becoming VM's at the high end, with
out-of-order/speculation/clustering etc,even the RISC one's... which is the main
reason x86 could come so close so fast IMO, because they can roll that overhead
into the translation they have to do anyway. RISC might be better, but as a VM
its only moderately so. Once processors go really wide and try to optimize
MIPS/die-space the tables might even get turned, a CISC instruction set with a
small register set would be better suited for that IMO.

Marco
Yahoo! Groups Sponsor
www.
From Ben Franchuk Mon Feb 19 07:12:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA14675 for ; Tue, 20 Feb 2001 05:35:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Feb 2001 05:35:38 +0100 (MET) Received: (qmail 19940 invoked by uid 0); 19 Feb 2001 15:37:45 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx01) with SMTP; 19 Feb 2001 15:37:45 -0000 X-eGroups-Return: sentto-1101623-2420-982597122-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 19 Feb 2001 15:38:44 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_3); 19 Feb 2001 15:38:41 -0000 Received: (qmail 18569 invoked from network); 19 Feb 2001 15:37:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 19 Feb 2001 15:37:54 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 19 Feb 2001 15:37:54 -0000 Received: from jetnet.ab.ca (dialin44.jetnet.ab.ca [207.153.6.44]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA17998 for ; Mon, 19 Feb 2001 08:27:55 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A90B948.6A90F8FC@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A912157.AC11B97E@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Feb 2001 23:12:24 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] cache techniques Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 92aecae5cf1e49591c0c7eea16618246 Status: R X-Status: N Yann GUIDON wrote:

> > So yes, x86 really is really crap (try writing asm for it),
> > which is why intel is trying to get ia64 operational.
> And Intel is crap, since they can't make both work ;-)

I still think it was designed for 'Pascal' style languages.
Small teaching programs with no memory and limited data sizes
(unsigned byte,int).With one AC, one index register,8086 assembly
language is still better than the old 8080A.(usable registers
that is).

> > Also, why is the asm keyword MOV used for an operation
> > that is actually a COPY???
I don't mind MOV,but LD is nicer. Now the 8080 mnemonics are really
bad.My homebrew cpu has memomics similar to the early machines
thus are really strange.

> good point of the day...
> that has bothered me when I was young and started to
> learn the 6809 asm...
That was a nice machine,but 64k addressing really limited its
use.The 68000 was the 16 bitter in that family thus the 6809
days were numbered as we all know.

-- 8008  60 KHZ 3500 transistors 10um tech 1972
-- 8080 2MHZ 6000 transistors 6um tech. 1974
-- 8085 5Mhz 6500 transistors 3um tech  1976  .33 mps
-- Z80  2.5Mhz 1976
-- 8086 5Mhz 29000 transistors 3um tech 1978  .33 mps (16 bit bus) $360
-- 8088 5Mhz 29000 transistors 3um tech 1979  .33 mps (8 bit bus)
-- 68000 4Mhz 68000 transistors 1979.
-- 80286 6Mhz 13400 transistors 1982 1.5um tech $360
http://www.islandnet.com/~kpolsson/comphist/

The days of high prices and low transitor count.
Now we still have high prices.:(


"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here
From Ben Franchuk Wed Feb 21 22:28:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00293 for ; Thu, 22 Feb 2001 13:46:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Feb 2001 13:46:52 +0100 (MET) Received: (qmail 23175 invoked by uid 0); 22 Feb 2001 01:46:02 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx19) with SMTP; 22 Feb 2001 01:46:02 -0000 X-eGroups-Return: sentto-1101623-2421-982806357-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 22 Feb 2001 01:45:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Feb 2001 01:45:57 -0000 Received: (qmail 34159 invoked from network); 22 Feb 2001 01:45:55 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 22 Feb 2001 01:45:55 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 22 Feb 2001 01:45:53 -0000 Received: from jetnet.ab.ca (dialin42.jetnet.ab.ca [207.153.6.42]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA04413 for ; Wed, 21 Feb 2001 18:35:39 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A9432FC.A7C64E7A@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Feb 2001 14:28:28 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Saving Bell's books Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6e696f677ea34f6ecd133857150d6926 Status: R X-Status: N I found another one of Bell's book online. Chapter #37 is the intel
processers 8008 to 8086. This gives a good insight why we got such
a crummy 16bit Cpu.
http://www.ul.cs.cmu.edu/webRoot/Books/Saving_Bell_Books/SBN%20Computer%20Strucutre/contents.html
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Feb 22 18:35:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01077 for ; Thu, 22 Feb 2001 20:45:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Feb 2001 20:45:39 +0100 (MET) Received: (qmail 24538 invoked by uid 0); 22 Feb 2001 17:43:44 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx01) with SMTP; 22 Feb 2001 17:43:44 -0000 X-eGroups-Return: sentto-1101623-2422-982863803-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 22 Feb 2001 17:43:27 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 22 Feb 2001 17:43:22 -0000 Received: (qmail 5127 invoked from network); 22 Feb 2001 17:42:38 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 22 Feb 2001 17:42:38 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 22 Feb 2001 17:42:38 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA08987; Thu, 22 Feb 2001 09:42:35 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 163PPRH8; Thu, 22 Feb 2001 17:47:49 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A954DFC.DB376EDE@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Feb 2001 18:35:56 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] [Fwd: EPF 2001 PRESENTATION PROPOSAL] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ebf611bf9519b5cd1673a064a1ce790c Status: R X-Status: N Maybe they'll make an "open/free design booth" one day ?

-------- Original Message --------
From: "Rumpf, Terri (Cahners MDR)" <trumpf@mdr.cahners.com>

Re: Your Presentation Proposal : Instruction scheduling and the memory
interface of the F-CPU Core #0

Dear Yann,

Thank you very much for submitting a proposal to present at this year's
Embedded Processor Forum. We received an unprecedented number of excellent
presentation proposals, far more than we can present even with this year's
extended three-day conference format. Unfortunately, we do not have room in
our EPF 2001 schedule for the presentation you have proposed. We truly
regret that we cannot accept all of the proposed presentations.

Regards,

Steve Leibson
VP, MicroDesign Resources
Program Director, EPF 2001
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From jeff@llandre.freeserve.co.uk Fri Feb 23 00:34:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02143 for ; Fri, 23 Feb 2001 01:09:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Feb 2001 01:09:48 +0100 (MET) Received: (qmail 1773 invoked by uid 0); 22 Feb 2001 23:35:31 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx22) with SMTP; 22 Feb 2001 23:35:31 -0000 X-eGroups-Return: sentto-1101623-2423-982884929-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 22 Feb 2001 23:35:30 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 22 Feb 2001 23:35:29 -0000 Received: (qmail 63189 invoked from network); 22 Feb 2001 23:35:28 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 22 Feb 2001 23:35:28 -0000 Received: from unknown (HELO cmailg5.svr.pol.co.uk) (195.92.195.175) by mta2 with SMTP; 22 Feb 2001 23:35:28 -0000 Received: from modem-240.eglarest.dialup.pol.co.uk ([62.136.175.240] helo=62.136.175.240) by cmailg5.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14W52Y-0005NR-00 for f-cpu@egroups.com; Thu, 22 Feb 2001 23:20:51 +0000 To: f-cpu@yahoogroups.com Message-Id: From: jeff@llandre.freeserve.co.uk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Feb 2001 23:34 +0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 375c5a6db22ac5903e7b14e181215b85 Status: R X-Status: N It occurred to me this evening that I am a bit surprised
that Intel have failed to licence hp-pa risc technoogy.
Using basic benchmarks, it seems the pa risc performs
far more work per cycle than any other cpu. If they
coupled this with the (compaq dec) alpha high-mhz
technology that they licence, youd have a pretty awesome
cpu.

In future years could (for example) intel combine fcpu
arch with proprietary (alpha high mhz) technology
bearing in mind the fcpu licence proposals?
//here's hoping intel are unlike microsoft who demonize
//the gpl licence.

If intel were to make a binary compatible fcpu would fcpuers
shun it if it used some proprietary tech?

Jeff Davies
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Rares Marian Fri Feb 23 00:57:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02146 for ; Fri, 23 Feb 2001 01:09:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Feb 2001 01:09:49 +0100 (MET) Received: (qmail 15453 invoked by uid 0); 22 Feb 2001 23:50:44 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx05) with SMTP; 22 Feb 2001 23:50:44 -0000 X-eGroups-Return: sentto-1101623-2424-982885820-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 22 Feb 2001 23:50:21 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Feb 2001 23:50:20 -0000 Received: (qmail 45592 invoked from network); 22 Feb 2001 23:50:18 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 22 Feb 2001 23:50:18 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 23 Feb 2001 00:51:23 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id F226F3BD041; Thu, 22 Feb 2001 18:57:21 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010222185721.C28463@moonbase.res.wpi.net> References: In-Reply-To: ; from jeff@llandre.freeserve.co.uk on Thu, Feb 22, 2001 at 18:34:00 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Feb 2001 18:57:21 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 40487b75c392ebb39bf092e58456092f Status: R X-Status: N
On Thu, 22 Feb 2001 18:34:00 jeff@llandre.freeserve.co.uk wrote:
> It occurred to me this evening that I am a bit surprised
> that Intel have failed to licence hp-pa risc technoogy.
> Using basic benchmarks, it seems the pa risc performs
> far more work per cycle than any other cpu. If they
> coupled this with the (compaq dec) alpha high-mhz
> technology that they licence, youd have a pretty awesome
> cpu.
>
> In future years could (for example) intel combine fcpu
> arch with proprietary (alpha high mhz) technology
> bearing in mind the fcpu licence proposals?
> //here's hoping intel are unlike microsoft who demonize
> //the gpl licence.
>
> If intel were to make a binary compatible fcpu would fcpuers
> shun it if it used some proprietary tech?
>
> Jeff Davies
>
>
>

>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Yahoo you put me here so go fuck off.  Thanks.

>
>


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Feb 24 02:18:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00852 for ; Sat, 24 Feb 2001 19:30:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 24 Feb 2001 19:30:56 +0100 (MET) Received: (qmail 9229 invoked by uid 0); 24 Feb 2001 01:12:07 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx04) with SMTP; 24 Feb 2001 01:12:07 -0000 X-eGroups-Return: sentto-1101623-2425-982977124-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 24 Feb 2001 01:12:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 01:12:03 -0000 Received: (qmail 18768 invoked from network); 24 Feb 2001 01:12:02 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 24 Feb 2001 01:12:02 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 24 Feb 2001 01:12:01 -0000 Received: from f-cpu.org (nas3-59.tls.club-internet.fr [195.36.202.59]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA21186 for ; Sat, 24 Feb 2001 02:11:55 +0100 (MET) Message-ID: <3A970BC9.D043DD8D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 02:18:01 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: ab2c66bdce6d2aa21828784cb8389ce4 Status: R X-Status: N hi !

Although this mailing list looks a bit mute,
the french side is completely boiling now...

jeff@llandre.freeserve.co.uk wrote:
> It occurred to me this evening that I am a bit surprised
> that Intel have failed to licence hp-pa risc technoogy.
?
what is this story ? do you have an url ?

> Using basic benchmarks, it seems the pa risc performs
> far more work per cycle than any other cpu. If they
> coupled this with the (compaq dec) alpha high-mhz
> technology that they licence, youd have a pretty awesome
> cpu.
if ... if ...
"if they had ia64 working" ... ;-)

> In future years could (for example) intel combine fcpu
> arch with proprietary (alpha high mhz) technology
> bearing in mind the fcpu licence proposals?
> //here's hoping intel are unlike microsoft who demonize
> //the gpl licence.
>
> If intel were to make a binary compatible fcpu would fcpuers
> shun it if it used some proprietary tech?

do you remember the name of the project ? "freedom CPU" ?
i see no reason (others could) to keep Intel from using the
f-cpu ISA. it would even be a good stuff, but it makes no
difference who does it. The first priorities were to create
a good and free alternative to the existing "proprietary"
architecture. if Intel decides to clock it with its own
fundries, it's even better. However, of course, like any
others, they have to respect the spirit of the project
and let the market decide.

but frankly, i don't see Intel or any other do that within
the next 5 years ;-)

> Jeff Davies
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Sat Feb 24 11:52:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00904 for ; Sat, 24 Feb 2001 19:31:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 24 Feb 2001 19:31:10 +0100 (MET) Received: (qmail 3541 invoked by uid 0); 24 Feb 2001 10:45:02 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx24) with SMTP; 24 Feb 2001 10:45:02 -0000 X-eGroups-Return: sentto-1101623-2427-983011501-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 24 Feb 2001 10:45:01 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 10:45:01 -0000 Received: (qmail 46769 invoked from network); 24 Feb 2001 10:45:01 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 24 Feb 2001 10:45:01 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 24 Feb 2001 10:45:00 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 2950C3BD041 for ; Sat, 24 Feb 2001 05:52:15 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 05:52:15 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: =?ISO-8859-1?Q?Re=A0:_Re:_=5Bf-cpu=5D_thoughts?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 75029d13475963e02b309af17fdedd70 Status: R X-Status: N On -1 xxx -1, hodys wrote:

Actually the consensus here is:  Intel design is lazy.

> Sorry !!!! I am new in your group but say me WHY?????? are so focused about
> Intel :
> I currently work on MIPS procs with IDT & NEC (mostly with IDT) & these
> guys subscribe to the MIPS
> std. I have always the choose to work with either IDT or NEC.
>
> :-)
> Bye
> Edgar
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat Feb 24 14:38:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00937 for ; Sat, 24 Feb 2001 19:31:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 24 Feb 2001 19:31:17 +0100 (MET) Received: (qmail 30730 invoked by uid 0); 24 Feb 2001 13:27:41 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx10) with SMTP; 24 Feb 2001 13:27:41 -0000 X-eGroups-Return: sentto-1101623-2428-983021260-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 24 Feb 2001 13:27:40 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 13:27:39 -0000 Received: (qmail 10165 invoked from network); 24 Feb 2001 13:27:39 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 24 Feb 2001 13:27:39 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.170.57) by mta3 with SMTP; 24 Feb 2001 14:28:39 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 63AD29E66 for ; Sat, 24 Feb 2001 14:38:46 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A97B966.F8F934E1@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 14:38:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: da2ececc1ad586bb23d1359440d2cd25 Status: R X-Status: N Yann Guidon a =E9crit :
<...>
> > In future years could (for example) intel combine fcpu
> > arch with proprietary (alpha high mhz) technology
> > bearing in mind the fcpu licence proposals?
> > //here's hoping intel are unlike microsoft who demonize
> > //the gpl licence.
> >
> > If intel were to make a binary compatible fcpu would fcpuers
> > shun it if it used some proprietary tech?
>
> do you remember the name of the project ? "freedom CPU" ? > i see no reason (others could) to keep Intel from using the
> f-cpu ISA. it would even be a good stuff, but it makes no
> difference who does it. The first priorities were to create
> a good and free alternative to the existing "proprietary" > architecture. if Intel decides to clock it with its own
> fundries, it's even better. However, of course, like any
> others, they have to respect the spirit of the project
> and let the market decide.
>
> but frankly, i don't see Intel or any other do that within
> the next 5 years ;-)
>

I think there is 2 points : the design (the VHDL files) ans the ISA.
Never forget the strategie of microsoft : they use public domain
technologie, produice a product and after a moment, make some
proprietary change(cf. Kerebos).

For the fcpu, imagine intel make this own core using the fcpu ISA but
add some feature (very usefull ones) so other fcpu maker couldn't add
those feature to their core. And they could lost their client !

So we should protect fcpu design with the LGPL (as LEON) to prevent the
steal of the code and Lgpl because in SOC (system on chip) design, some
people would like to use the fcpu with other proprietary core (MPEG,
DSP, io controler...) and if the code are GPL, they can't do that !

But the isa definition should be protect by the gpl, too. Whygee want a
total freedom but if the different core are to much different, it will
never survive with the time.

To make it simple, we could defined the basic ISA, the FPU ISA, and some reserved opcode for external coprocessor and maybe an extended ISA (but
i could be never used if it is too rare). It could be a problem if you
say : implement what ever unit you want. But we could allow to do this,
if there is a trap and a code to simulate the beavior of the missing
unit.

> > Jeff Davies
> WHYGEE
nicO
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Marco Al" Sat Feb 24 17:47:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00961 for ; Sat, 24 Feb 2001 19:31:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 24 Feb 2001 19:31:22 +0100 (MET) Received: (qmail 3819 invoked by uid 0); 24 Feb 2001 16:38:10 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx25) with SMTP; 24 Feb 2001 16:38:10 -0000 X-eGroups-Return: sentto-1101623-2429-983032688-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 24 Feb 2001 16:38:08 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 16:38:07 -0000 Received: (qmail 93933 invoked from network); 24 Feb 2001 16:38:07 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 24 Feb 2001 16:38:07 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 24 Feb 2001 16:38:06 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id A42DA2982 for ; Sat, 24 Feb 2001 17:38:05 +0100 (CET) Message-ID: <000701c09e81$7a505a30$29e65982@student.utwente.nl> To: References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 17:47:30 +0100 Reply-To: f-cpu@yahoogroups.com Subject: =?iso-8859-1?Q?Re:_Re=A0:_Re:_=5Bf-cpu=5D_thoughts?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5778a564adc35392c0ac9decdcac07c3 Status: R X-Status: N From: <rares@moonbase.res.wpi.net>

> Actually the consensus here is:  Intel design is lazy.

If Intel is lazy the rest of the industry is lethargic.

Marco
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "hodys" Thu Jan 1 01:00:00 1970 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00979 for ; Sat, 24 Feb 2001 19:31:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 24 Feb 2001 19:31:26 +0100 (MET) Received: (qmail 12232 invoked by uid 0); 24 Feb 2001 10:51:38 -0000 Received: from mx01.rz2.gmx.net (HELO f19.egroups.com) (10.1.72.101) by mxi1.gmx.net (mxi1) with SMTP; 24 Feb 2001 10:51:38 -0000 X-eGroups-Return: sentto-1101623-2426-983011081-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by f19.egroups.com with NNFMP; 24 Feb 2001 10:38:02 -0000 X-Sender: hodys@wanadoo.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 10:38:01 -0000 Received: (qmail 7182 invoked from network); 24 Feb 2001 10:38:00 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 24 Feb 2001 10:38:00 -0000 Received: from unknown (HELO embelia.wanadoo.fr) (193.252.19.161) by mta3 with SMTP; 24 Feb 2001 11:39:05 -0000 Received: from mahonia.wanadoo.fr (193.252.19.58) by embelia.wanadoo.fr; 24 Feb 2001 11:37:59 +0100 Received: from inconnu (193.252.147.140) by mahonia.wanadoo.fr; 24 Feb 2001 11:37:33 +0100 Message-ID: In-Reply-To: <3A970BC9.D043DD8D@f-cpu.org> References: Conversation with last message <3A970BC9.D043DD8D@f-cpu.org> Priority: Normal X-MSMail-Priority: Normal X-Priority: 3 To: f-cpu@yahoogroups.com From: "hodys" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: (Date invalide.) Reply-To: f-cpu@yahoogroups.com Subject: =?ISO-8859-1?Q?Re=A0:_Re:_=5Bf-cpu=5D_thoughts?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 528d38ffecf502c9de66ed32103a9d2c Status: R X-Status: N Sorry !!!! I am new in your group but say me WHY?????? are so focused about
Intel :
I currently work on MIPS procs with IDT & NEC (mostly with IDT) & these
guys subscribe to the MIPS
std. I have always the choose to work with either IDT or NEC.

:-)
Bye
Edgar
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Sat Feb 24 15:07:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00322 for ; Sun, 25 Feb 2001 15:58:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Feb 2001 15:58:49 +0100 (MET) Received: (qmail 28287 invoked by uid 0); 24 Feb 2001 23:21:58 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx12) with SMTP; 24 Feb 2001 23:21:58 -0000 X-eGroups-Return: sentto-1101623-2430-983056891-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 24 Feb 2001 23:21:33 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Feb 2001 23:21:22 -0000 Received: (qmail 11432 invoked from network); 24 Feb 2001 23:21:21 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 24 Feb 2001 23:21:21 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.129) by mta3 with SMTP; 25 Feb 2001 00:22:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00471; Sat, 24 Feb 2001 15:07:17 +0100 Message-ID: <20010224150717.26870@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A97B966.F8F934E1@seul.org>; from Nicolas on Sat, Feb 24, 2001 at 02:38:46PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 15:07:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a0eaca2314f7f8d69fb2a25f03251efb Status: R X-Status: N On Sat, Feb 24, 2001 at 02:38:46PM +0100, Nicolas wrote:

> I think there is 2 points : the design (the VHDL files) ans the ISA.
> Never forget the strategie of microsoft : they use public domain
> technologie, produice a product and after a moment, make some
> proprietary change(cf. Kerebos).

That's why they hate the GPL so much :)

> For the fcpu, imagine intel make this own core using the fcpu ISA but
> add some feature (very usefull ones) so other fcpu maker couldn't add
> those feature to their core. And they could lost their client !

Everybody can reimplement the F-CPU as he likes, also as a proprietary
MS-style `embrace and extend' system, as long as the ISA is not protected
against that somehow.  Protecting only the code does not stop people from
reimplementing the whole sucker, and a reimplementation ist definitely
not covered by a license (otherwise, Linux wouldn't have been possible).

> So we should protect fcpu design with the LGPL (as LEON) to prevent the
> steal of the code and Lgpl because in SOC (system on chip) design, some
> people would like to use the fcpu with other proprietary core (MPEG,
> DSP, io controler...) and if the code are GPL, they can't do that !

If they add their own intellectual property and release the combination
of their IP and the F-CPU under the terms of the GPL, they can.  We
want free hardware, don't we?  We want the `General Public Virus' to
infect the hardware world.  Why should we allow people to use our work
without giving anything back in turn?  If they really want the F-CPU
code, they can as well pay for it (one way or another).

> But the isa definition should be protect by the gpl, too. Whygee want a
> total freedom but if the different core are to much different, it will
> never survive with the time.

I agree with that.  The ISA must not be in the public domain.

> To make it simple, we could defined the basic ISA, the FPU ISA, and some
> reserved opcode for external coprocessor and maybe an extended ISA (but
> i could be never used if it is too rare). It could be a problem if you
> say : implement what ever unit you want. But we could allow to do this,
> if there is a trap and a code to simulate the beavior of the missing
> unit.

A while ago, I wrote some rules about modifications to the instruction set.
Please refer to the mailing list archive (or your local copy, if you
have one).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Rares Marian Sun Feb 25 03:48:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00340 for ; Sun, 25 Feb 2001 15:58:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Feb 2001 15:58:54 +0100 (MET) Received: (qmail 15962 invoked by uid 0); 25 Feb 2001 02:41:16 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx17) with SMTP; 25 Feb 2001 02:41:16 -0000 X-eGroups-Return: sentto-1101623-2431-983068871-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mu.egroups.com with NNFMP; 25 Feb 2001 02:41:13 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Feb 2001 02:41:10 -0000 Received: (qmail 57133 invoked from network); 25 Feb 2001 02:41:10 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 25 Feb 2001 02:41:10 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 25 Feb 2001 03:42:15 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id AAC8A3BD041; Sat, 24 Feb 2001 21:48:29 -0500 (EST) To: f-cpu@yahoogroups.com Message-ID: <20010224214829.A19825@moonbase.res.wpi.net> References: <000701c09e81$7a505a30$29e65982@student.utwente.nl> In-Reply-To: <000701c09e81$7a505a30$29e65982@student.utwente.nl>; from marco@simplex.nl on Sat, Feb 24, 2001 at 11:47:30 -0500 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 21:48:29 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: =?ISO-8859-1?Q?Re=A0:_Re:_=5Bf-cpu=5D_thoughts?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4b9707569bea2699dbacf4c65736583e Status: R X-Status: N
On Sat, 24 Feb 2001 11:47:30 Marco Al wrote:
> From: <rares@moonbase.res.wpi.net>
>
> > Actually the consensus here is:  Intel design is lazy.
>
> If Intel is lazy the rest of the industry is lethargic.

No contest.

> Marco
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sun Feb 25 15:37:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00376 for ; Sun, 25 Feb 2001 15:59:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Feb 2001 15:59:02 +0100 (MET) Received: (qmail 24407 invoked by uid 0); 25 Feb 2001 14:26:14 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx12) with SMTP; 25 Feb 2001 14:26:14 -0000 X-eGroups-Return: sentto-1101623-2432-983111172-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 25 Feb 2001 14:26:13 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Feb 2001 14:26:11 -0000 Received: (qmail 86631 invoked from network); 25 Feb 2001 14:26:11 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 25 Feb 2001 14:26:11 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.103) by mta3 with SMTP; 25 Feb 2001 15:27:12 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 9A8F19E68 for ; Sun, 25 Feb 2001 15:37:36 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9918B0.E2D8B715@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Feb 2001 15:37:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 3ad4e699669f0e1edbc3b39328c0ee1e Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Sat, Feb 24, 2001 at 02:38:46PM +0100, Nicolas wrote:
>
> > I think there is 2 points : the design (the VHDL files) ans the I= SA.
> > Never forget the strategie of microsoft : they use public domain<= BR> > > technologie, produice a product and after a moment, make some
> > proprietary change(cf. Kerebos).
>
> That's why they hate the GPL so much :)
;-p

>
> > For the fcpu, imagine intel make this own core using the fcpu ISA= but
> > add some feature (very usefull ones) so other fcpu maker couldn't= add
> > those feature to their core. And they could lost their client ! >
> Everybody can reimplement the F-CPU as he likes, also as a proprietary=
> MS-style `embrace and extend' system, as long as the ISA is not protec= ted
> against that somehow.  Protecting only the code does not stop peo= ple from
> reimplementing the whole sucker, and a reimplementation ist definitely=
> not covered by a license (otherwise, Linux wouldn't have been possible= ).
>
That's my opinion, too.

> > So we should protect fcpu design with the LGPL (as LEON) to preve= nt the
> > steal of the code and Lgpl because in SOC (system on chip) design= , some
> > people would like to use the fcpu with other proprietary core (MP= EG,
> > DSP, io controler...) and if the code are GPL, they can't do that= !
>
> If they add their own intellectual property and release the combinatio= n
> of their IP and the F-CPU under the terms of the GPL, they can.  = We
> want free hardware, don't we?  We want the `General Public Virus'= to
> infect the hardware world.  Why should we allow people to use our= work
> without giving anything back in turn?  If they really want the F-= CPU
> code, they can as well pay for it (one way or another).
>

If we do that we could lost many "client". I follow the Leon proj= ect. It
was design for SOC. So a compagny which make a SOC buy or use lots of
3rd part core. (leon, fcpu, or proprietary quick io,...). SOC try to
reuse a maximum of different core (to manage its complexity). It's the
step behind the standart cell(nec new 0.15 =B5m technology, beside
standart cell, introduice MPEG decoder, viterbi encoder, ethernet
transeiver,...). SOC are so complex (multiplion transistor chip) that
you can't made all core by ourself (that what SOC means !).

So our goal is to develop a free powerfull cpu. So having a too much
restrictive licence can limite the use of the fcpu (never forget that
GPL work well because you can sell GPL product). We want a well
developped one. If our "client" can't use fcpu, they will use Spa= rc,
Mips or Arm core (or more specific core as ARC...).

> > But the isa definition should be protect by the gpl, too. Whygee = want a
> > total freedom but if the different core are to much different, it= will
> > never survive with the time.
>
> I agree with that.  The ISA must not be in the public domain.
>
2 agree ! Some more ?
> > To make it simple, we could defined the basic ISA, the FPU ISA, a= nd some
> > reserved opcode for external coprocessor and maybe an extended IS= A (but
> > i could be never used if it is too rare). It could be a problem i= f you
> > say : implement what ever unit you want. But we could allow to do= this,
> > if there is a trap and a code to simulate the beavior of the miss= ing
> > unit.
>
> A while ago, I wrote some rules about modifications to the instruction= set.
> Please refer to the mailing list archive (or your local copy, if you > have one).
>

I remember that it was very strict. You would like to restrain the
modification to the ISA but it's far more restrictive than GPL (no rules of how the next version should work are describe !). If the licence is
to restrictive, you will limit the use of the core.

> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
nicO
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Feb 25 20:00:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01983 for ; Sun, 25 Feb 2001 20:19:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Feb 2001 20:19:58 +0100 (MET) Received: (qmail 16722 invoked by uid 0); 25 Feb 2001 18:56:32 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx16) with SMTP; 25 Feb 2001 18:56:32 -0000 X-eGroups-Return: sentto-1101623-2433-983127317-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by b05.egroups.com with NNFMP; 25 Feb 2001 18:55:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Feb 2001 18:55:15 -0000 Received: (qmail 54205 invoked from network); 25 Feb 2001 18:54:41 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 25 Feb 2001 18:54:41 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 25 Feb 2001 19:55:45 -0000 Received: from f-cpu.org (nas2-232.ras.club-internet.fr [195.36.192.232]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA11431 for ; Sun, 25 Feb 2001 19:54:35 +0100 (MET) Message-ID: <3A995654.994BDDBD@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Feb 2001 20:00:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: f183a6bee8dca7241f4b1be4ffc88897 Status: R X-Status: N hello,

Nicolas wrote:
> Michael Riepe a =E9crit :
> > On Sat, Feb 24, 2001 at 02:38:46PM +0100, Nicolas wrote:
> > > So we should protect fcpu design with the LGPL (as LEON) to = prevent the
> > > steal of the code and Lgpl because in SOC (system on chip) d= esign, some
> > > people would like to use the fcpu with other proprietary cor= e (MPEG,
> > > DSP, io controler...) and if the code are GPL, they can't do= that !
> > If they add their own intellectual property and release the combi= nation
> > of their IP and the F-CPU under the terms of the GPL, they can.&n= bsp; We
> > want free hardware, don't we?  We want the `General Public V= irus' to
> > infect the hardware world.  Why should we allow people to us= e our work
> > without giving anything back in turn?  If they really want t= he F-CPU
> > code, they can as well pay for it (one way or another).
> If we do that we could lost many "client".
We are not a company. We don't have "clients". it's probably a bi= ased point of
view, but it's not a matter of "commerce" (i think you know it).<= BR> maybe a better word would be "adopter".

> I follow the Leon project. It was design for SOC.
f-cpu is not designed for "SoC" because this term has not
even reached the "conumer" audience.
However f-cpu is not incompatible with "SoC" in spirit.
it was simply not the primary intent : it is not even mentioned
in the f-cpu goals.

> So a compagny which make a SOC buy or use lots of
> 3rd part core. (leon, fcpu, or proprietary quick io,...). SOC try to > reuse a maximum of different core (to manage its complexity). It's the=
> step behind the standart cell(nec new 0.15 =B5m technology, beside
> standart cell, introduice MPEG decoder, viterbi encoder, ethernet
> transeiver,...). SOC are so complex (multiplion transistor chip) that<= BR> > you can't made all core by ourself (that what SOC means !).
there's nobody left to convince here :-)

> So our goal is to develop a free powerfull cpu.
that's "all".

> So having a too much
> restrictive licence can limite the use of the fcpu (never forget that<= BR> > GPL work well because you can sell GPL product). We want a well
> developped one. If our "client" can't use fcpu, they will us= e Sparc,
> Mips or Arm core (or more specific core as ARC...).

i think that you undersee the problem. It's not a matter of licence.
What would be the problem if a company integrates a free f-cpu core
in a "SoC" ? i see none. there are Emacs versions running under W= indows,
and RMS doesn't complain (afaik). Similarly, what are the troubles
and what is the difference if the "core" is on the same chip and = not on the
same "system" (out of the chip, ie on the PCB). to the user, ther= e is
no difference, and there is no problem if you interface a "free" = SW
with Windows, or if you interface a "free" core with a unknown I/= O or
CPU (ie: who cares if the SRAM design for the cache is proprietary ?
only the implementor cares).

The problem is with the F-CPU sources : what you have to and can do
with them. and there is no ambiguity. what you do with the
result of the compilation is up to you : paperwall or chairs, if you like.<= BR>
> > > But the isa definition should be protect by the gpl, too. Wh= ygee want a
> > > total freedom but if the different core are to much differen= t, it will
> > > never survive with the time.
> > I agree with that.  The ISA must not be in the public domain= .
> 2 agree ! Some more ?
the ISA is not public domain. it is covered by our author's rights.
however the specialists can always find ways to bypass some parts.

> > > To make it simple, we could defined the basic ISA, the FPU I= SA, and some
> > > reserved opcode for external coprocessor and maybe an extend= ed ISA (but
> > > i could be never used if it is too rare). It could be a prob= lem if you
> > > say : implement what ever unit you want. But we could allow = to do this,
> > > if there is a trap and a code to simulate the beavior of the= missing
> > > unit.
> > A while ago, I wrote some rules about modifications to the instru= ction set.
> > Please refer to the mailing list archive (or your local copy, if = you have one).
>
> I remember that it was very strict.
it is our right... look at the industry licences ;-)

> You would like to restrain the
> modification to the ISA but it's far more restrictive than GPL (no rul= es
> of how the next version should work are describe !). If the licence is=
> to restrictive, you will limit the use of the core.
not necessarily.
a lot of people use existing cores and don't want to modify the ISA.
however, we leave to possibility to "adapt" it, under certain con= ditions
that are meant to keep the implemented cores coherent. if someone breaks the coherency of the architecture, he will be banned (that's all).


> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"3
Click for Details=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Sun Feb 25 20:58:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA02367 for ; Sun, 25 Feb 2001 21:04:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 25 Feb 2001 21:04:30 +0100 (MET) Received: (qmail 21949 invoked by uid 0); 25 Feb 2001 19:52:12 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx10) with SMTP; 25 Feb 2001 19:52:12 -0000 X-eGroups-Return: sentto-1101623-2434-983130725-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 25 Feb 2001 19:52:10 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Feb 2001 19:52:04 -0000 Received: (qmail 22499 invoked from network); 25 Feb 2001 19:51:34 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 25 Feb 2001 19:51:34 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 25 Feb 2001 19:51:34 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 6F8153BD027 for ; Sun, 25 Feb 2001 14:58:59 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <3A9918B0.E2D8B715@seul.org> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Feb 2001 14:58:59 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f9b69ad318d49decae95cc54cbbd458a Status: R X-Status: N On Sun, 25 Feb 2001, Nicolas wrote:


> > A while ago, I wrote some rules about modifications to the instruction set.
> > Please refer to the mailing list archive (or your local copy, if you
> > have one).
> >
>
> I remember that it was very strict. You would like to restrain the
> modification to the ISA but it's far more restrictive than GPL (no rules
> of how the next version should work are describe !). If the licence is
> to restrictive, you will limit the use of the core.
>
> > --
> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
> nicO

Why not just allow forks of the project?


>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Feb 25 02:08:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA03304 for ; Mon, 26 Feb 2001 03:08:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Feb 2001 03:08:54 +0100 (MET) Received: (qmail 27655 invoked by uid 0); 25 Feb 2001 20:42:49 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx14) with SMTP; 25 Feb 2001 20:42:49 -0000 X-eGroups-Return: sentto-1101623-2435-983133767-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 25 Feb 2001 20:42:48 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Feb 2001 20:42:46 -0000 Received: (qmail 94464 invoked from network); 25 Feb 2001 20:42:40 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 25 Feb 2001 20:42:40 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 25 Feb 2001 20:42:38 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA27900 for ; Sun, 25 Feb 2001 13:42:22 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A985B01.4CFAE51B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Feb 2001 18:08:17 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 160a6e56b7eb391da3fd39301a6bbb6d Status: R X-Status: N rares@moonbase.res.wpi.net wrote:
>
> Why not just allow forks of the project?
  Next year it will be spoons.
  The year after then knifes
  Soon you will have a whole drawer of CPU's, and nothing
  works.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Feb 26 16:00:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00399 for ; Mon, 26 Feb 2001 16:13:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Feb 2001 16:13:50 +0100 (MET) Received: (qmail 22665 invoked by uid 0); 26 Feb 2001 15:07:29 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx22) with SMTP; 26 Feb 2001 15:07:29 -0000 X-eGroups-Return: sentto-1101623-2436-983200046-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 26 Feb 2001 15:07:26 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 26 Feb 2001 15:07:25 -0000 Received: (qmail 68517 invoked from network); 26 Feb 2001 15:07:24 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 26 Feb 2001 15:07:24 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 26 Feb 2001 15:07:24 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA18344; Mon, 26 Feb 2001 07:07:21 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR70CH; Mon, 26 Feb 2001 15:12:37 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9A6F95.551C8625@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Feb 2001 16:00:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] bougez avec la Poste Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: e0e1813694310dbd6e7308061a8757f2 Status: R X-Status: N salut,
j'ai depose l'enveloppe dans une boite aux lettres ce
matin pour Khalid.


YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Mon Feb 26 20:51:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01617 for ; Mon, 26 Feb 2001 20:50:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Feb 2001 20:50:38 +0100 (MET) Received: (qmail 30531 invoked by uid 0); 26 Feb 2001 19:40:31 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx07) with SMTP; 26 Feb 2001 19:40:31 -0000 X-eGroups-Return: sentto-1101623-2437-983216429-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jj.egroups.com with NNFMP; 26 Feb 2001 19:40:30 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 26 Feb 2001 19:40:28 -0000 Received: (qmail 73262 invoked from network); 26 Feb 2001 19:40:28 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 26 Feb 2001 19:40:28 -0000 Received: from unknown (HELO localhost.localdomain) (194.158.109.77) by mta2 with SMTP; 26 Feb 2001 19:40:26 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BB6DF9E6B for ; Mon, 26 Feb 2001 20:51:37 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9AB3C9.7DFB1FC6@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Feb 2001 20:51:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 1af2284246fe5f438b4eba001cd71b33 Status: R X-Status: N Yann Guidon a =E9crit :
>
> hello,
>
> Nicolas wrote:
> > Michael Riepe a =E9crit :
> > > On Sat, Feb 24, 2001 at 02:38:46PM +0100, Nicolas wrote:
> > > > So we should protect fcpu design with the LGPL (as LEON= ) to prevent the
> > > > steal of the code and Lgpl because in SOC (system on ch= ip) design, some
> > > > people would like to use the fcpu with other proprietar= y core (MPEG,
> > > > DSP, io controler...) and if the code are GPL, they can= 't do that !
> > > If they add their own intellectual property and release the = combination
> > > of their IP and the F-CPU under the terms of the GPL, they c= an.  We
> > > want free hardware, don't we?  We want the `General Pub= lic Virus' to
> > > infect the hardware world.  Why should we allow people = to use our work
> > > without giving anything back in turn?  If they really w= ant the F-CPU
> > > code, they can as well pay for it (one way or another).
> > If we do that we could lost many "client".
> We are not a company. We don't have "clients". it's probably= a biased point of
> view, but it's not a matter of "commerce" (i think you know = it).
> maybe a better word would be "adopter".
>
You play apon words ! Our client "are" the user of our design whi= ch take
market part as usual product !

> > I follow the Leon project. It was design for SOC.
> f-cpu is not designed for "SoC" because this term has not > even reached the "conumer" audience.
> However f-cpu is not incompatible with "SoC" in spirit.
> it was simply not the primary intent : it is not even mentioned
> in the f-cpu goals.
>

Never Mind ! It will be 90% of the use of the chip !

> > So a compagny which make a SOC buy or use lots of
> > 3rd part core. (leon, fcpu, or proprietary quick io,...). SOC try= to
> > reuse a maximum of different core (to manage its complexity). It'= s the
> > step behind the standart cell(nec new 0.15 =B5m technology, besid= e
> > standart cell, introduice MPEG decoder, viterbi encoder, ethernet=
> > transeiver,...). SOC are so complex (multiplion transistor chip) = that
> > you can't made all core by ourself (that what SOC means !).
> there's nobody left to convince here :-)
>
> > So our goal is to develop a free powerfull cpu.
> that's "all".
>
> > So having a too much
> > restrictive licence can limite the use of the fcpu (never forget = that
> > GPL work well because you can sell GPL product). We want a well > > developped one. If our "client" can't use fcpu, they wi= ll use Sparc,
> > Mips or Arm core (or more specific core as ARC...).
>
> i think that you undersee the problem. It's not a matter of licence. > What would be the problem if a company integrates a free f-cpu core > in a "SoC" ? i see none. there are Emacs versions running un= der Windows,
> and RMS doesn't complain (afaik). Similarly, what are the troubles
> and what is the difference if the "core" is on the same chip= and not on the
> same "system" (out of the chip, ie on the PCB). to the user,= there is
> no difference, and there is no problem if you interface a "free&q= uot; SW
> with Windows, or if you interface a "free" core with a unkno= wn I/O or
> CPU (ie: who cares if the SRAM design for the cache is proprietary ? > only the implementor cares).
>
> The problem is with the F-CPU sources : what you have to and can do > with them. and there is no ambiguity. what you do with the
> result of the compilation is up to you : paperwall or chairs, if you l= ike.
>

In the opposite, i see a very big problem. ESA lawyer choose LGPL
because of that. And RMS created the LGPL because of that ;p There is a
very (very) big difference between 2 binaries running on the same system and "2 parts" that should be compiled in the same time. LGPL was = created
to permit the use of library on propritary application. But you always
could run proprietary program on GPL Linux !

So you could NOT mixed our GPL vhdl code and proprietary VHDL code. We
should use LGPL to permit that (and protecte the fcpu code itself).

> > > > But the isa definition should be protect by the gpl, to= o. Whygee want a
> > > > total freedom but if the different core are to much dif= ferent, it will
> > > > never survive with the time.
> > > I agree with that.  The ISA must not be in the public d= omain.
> > 2 agree ! Some more ?
> the ISA is not public domain. it is covered by our author's rights. > however the specialists can always find ways to bypass some parts.
>

The GPL is a copyright.

> > > > To make it simple, we could defined the basic ISA, the = FPU ISA, and some
> > > > reserved opcode for external coprocessor and maybe an e= xtended ISA (but
> > > > i could be never used if it is too rare). It could be a= problem if you
> > > > say : implement what ever unit you want. But we could a= llow to do this,
> > > > if there is a trap and a code to simulate the beavior o= f the missing
> > > > unit.
> > > A while ago, I wrote some rules about modifications to the i= nstruction set.
> > > Please refer to the mailing list archive (or your local copy= , if you have one).
> >
> > I remember that it was very strict.
> it is our right... look at the industry licences ;-)
>

I know we could make what we want. But i think that we want that fcpu
should be used by few people...

> > You would like to restrain the
> > modification to the ISA but it's far more restrictive than GPL (n= o rules
> > of how the next version should work are describe !). If the licen= ce is
> > to restrictive, you will limit the use of the core.
> not necessarily.
> a lot of people use existing cores and don't want to modify the ISA. > however, we leave to possibility to "adapt" it, under certai= n conditions
> that are meant to keep the implemented cores coherent. if someone brea= ks
> the coherency of the architecture, he will be banned (that's all).
>

???? If intel take the fcpu ISA and make it's owne core with few key
proprietary feature. Then because of its marketing power and this
specific feature, it will kill all other concurent (other chip maker).
So usual fcpu ISA will be "owne" by intel. That's a very big risk= !

> > >  Michael "Tired" Riepe <Michael.Riepe@stud= .uni-hannover.de>
> > nicO
> WHYGEE

rares@moonbase.res.wpi.net a =E9crit :
> Why not just allow forks of the project?
>
More often a fork just kill a project. And our project is big and
complex, so very fragile. And here the problem is to stole our work.

nicO

PS: Whygee, have you lost my little exercise about a piece of asm arm
code ?
Yahoo! Groups Spons= or
3D"Beco=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carsten899@aol.com Tue Feb 27 08:05:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00299 for ; Tue, 27 Feb 2001 16:19:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:14 +0100 (MET) Received: (qmail 11024 invoked by uid 0); 27 Feb 2001 07:05:14 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx24) with SMTP; 27 Feb 2001 07:05:14 -0000 X-eGroups-Return: sentto-1101623-2438-983257512-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 27 Feb 2001 07:05:13 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 07:05:11 -0000 Received: (qmail 7177 invoked from network); 27 Feb 2001 07:05:11 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 27 Feb 2001 07:05:11 -0000 Received: from unknown (HELO imo-m10.mx.aol.com) (64.12.136.165) by mta3 with SMTP; 27 Feb 2001 08:06:15 -0000 Received: from Carsten899@aol.com by imo-m10.mx.aol.com (mail_out_v29.5.) id r.23.7f7fac1 (4417) for ; Tue, 27 Feb 2001 02:05:02 -0500 (EST) Message-ID: <23.7f7fac1.27ccab9d@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 02:05:01 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] New FCPU (64Bit) Emulator version 2.0 Content-Type: multipart/mixed; boundary="part1_23.7f7fac1.27ccab9d_boundary" X-UIDL: 64afb039c1b7dd65d3c2c3e2f689c1da Status: R X-Status: N --part1_23.7f7fac1.27ccab9d_boundary Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FCPU - Emulator V2.0
--------------------

(1) General

The emulator instruction set and emulation is based on the manual V0.2.
Please note:

    * Logarithmic integers are not implemented
    * OP_DIV computes r1 =3D r2 / r3 instead of r1 =3D r3 / = r2.
    * SR_URL is not implememted. Access causes a PROTECTIONF= AULT
    * OP_FIAPRX, OP_FSQRTAPRX, OP_FLOG, OP_FEXP are not supp= orted.

The commandline syntax is:

    fcpu [ <filename> ]

For example

    fcpu test.asm

or

    fcpu

If there is a filename defined in the commandline, the emulator loads
this file, assembles it and then executes a "go" command. This ca= uses
the assembled file to be executed until a HALT instruction is reached.
On HALT the emulator terminates.

If there is no commandline, the emu enters debugging mode and there
are several commands available:


help, h, ?    ... print help

go, g         ... run program until= halt instruction

step, s       ... single step one instruction=

reset, r      ... reset cpu

quit, q       ... quit emulator

dumpcpu, dc   ... dump cpu state

loadasm, la   ... load and assemble file:

            &nb= sp;     la "test.asm"

drui          ... dump registe= rs as unsigned hex. integer.
            &nb= sp;     See drfd for an example.

drfs          ... dump registe= rs as single precision float:
            &nb= sp;     See drfd for an example.

drfd          ... dump registe= rs as double precision float:

            &nb= sp;     drdf       &= nbsp;  dump all registers
            &nb= sp;     drfd r12-r16  dumps registers r12 to r16             &nb= sp;     drfd r2       dum= p register r2


(2) Native SYSCALL=B4s

The emulator supports the following "native" syscalls. Native
means, that these syscalls are processed by native code on the
host machine. These SYSCALL=B4s do not jump to a FCPU-coded
SYSCALL handler.



0xFFFF - prints the character in the LSB of R63 th stdout

The following code prints 'hello' to stdout:

PRINTHELLO:
    loadcons.0  "h", r63
    syscall     0xFFFF, r0
    loadcons.0  "e", r63
    syscall     0xFFFF, r0
    loadcons.0  "l", r63
    syscall     0xFFFF, r0
    loadcons.0  "l", r63
    syscall     0xFFFF, r0
    loadcons.0  "o", r63
    syscall     0xFFFF, r0
    halt



0xFFFE - reads a character from stdin into LSB of R63




(3) The symbolic assembler

The emulator contains a symbolic assembler.



The assembler supports labels. Labels are always the first element
of a line and end with ":". For example:

JumpHere: loadcons.0 1, r2



The assembler supports the following directives:



EQU - defines a symbol. For example

symbol EQU 0x1000

The "symbol" is defined to be 0x1000. If "symbol" is us= ed in an
instruction it is replaced by its value 0x1000.



ORG - defines into which absolute address the following opcodes are
assembled to. For example:

ORG 0x1AF0
loadcons.0 symbol, r1

The "loadcons.0" instruction is put into memory at address 0x1AF0=



ALIGN - aligns the absolute address. For example

ORG 0x1111
ALIGN 4
loadcons.0 symbol, r2

The "loadcons.0" instruction is put into memory at address 0x1114=



DB - defines a byte or a string (sequence of bytes). For example

db 0x99
db "This is a string"

DD - defines a double byte in little endian order.
DDLE - same as DD.
DDBE - defines a double byte in big endian order.

DQ - defines a quad byte in little endian order.
DQLE - same as DQ.
DQBE - defines a quad byte in big endian order.

DO - defines a oct byte in little endian order.
DOLE - same as DO.
DOBE - defines a oct byte in big endian order.


The assembler accepts the following constants
(see function fcpu_utl_convert_string_to_constant for details)

    signed decimal:

        -3
        55

    unsigned hexadecimal ( leading "0x" ):

        0xFF

        0x00000777

    single float ( trailing "f" )

        1.778E2f

    double float ( trailing "d" )

        1.223d


Registers are coded with a leading "r" or "R". The regi= ster number
is expected to be a decimal number, for example:

    r1
    r33
    r63
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--part1_23.7f7fac1.27ccab9d_boundary Content-Type: application/zip; name="fcemu20.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcemu20.zip" UEsDBBQAAgAIAHI7Wyo9t312khEAAMg+AAAbAAAAd29yay9mY3B1L3ppcHNyYy9mY3B1ZGVm cy5orVt7c9s4kv97p2q+A5L54+yUbIvU0/Fmq2SZcnSj11KSJ9mpOxZFQRYvfA1BRfbc7re6 D3jdAN8EJafunEpkAb9uNBqNfgDIL/bO29IdMYzRcLF+0EZL47Px80+/QJvt0XJz1rGedNsE fg4es589ugWk7UXddoYYC0C1Yz1pqQVSx/eec3Sit9S6njT7BSJrb4ZcoHgCo8FkqWV4/hXw zQm0UW9r7/Lglb7OYfEb8lak2Nl6Msmw+I1U+N7cZH8z7P14dUFeyCW5wD+osUsFvv31r0Q0 X9aTotaN+cJYz36dzX+bcYWQ5stoxEk+EM+PiElCajrkvR/Q0Ixs33tPbI9Ee0oY9RiF38yI f92akUnMkHIq1weZbVDgh5vqcNP5k0aSnyYfiflkNl8Qm5EtjagVAeXRjvbE9GA0FoUHC4cm 9I8DyBL55E8a+px3lTvyEUx3vuP4R2C1eSUtQt0geoVfI8oaZHMQQneJY7KIbOyIkYsthV9D +nxJLBh3A3ODBiD3/COOyWw3cOzdKxDa3jO7jseHgcZeRJ9pCLMHmV0a2RaTTnzw8JDOm6jV /uX6PutvSxS3nmT93Wr/w/gp6+/LFJ8bX2lKBcxkUCQSTgfDHIdWzk7QSpzXnAqur6+lSljM F8P5erYSLNqJCmfDq43JQNu59ZZrcThdZGpQ23JAamBqVzaLL7l1kClqPMsALYmilnN9lXFQ 4klMZkuS7hO58JO8DbQkGp7kjaCVaHj5eUIu3rP9YbdzaPj+8twwy8/j0SrRUqtbA9ATQL8O MIhtUaICfb7KlqGtSgF6BpCsE3gu2KsJoCsF6Fpi0u2+0MR4+gBuYct38pXQCGxHuaMZ59a5 IxFR+7IYzJL16LQkWnhYLzIOkjksNH26XmnJjunG66XPFypEETsiF7g5LB9cBzg28hF/3SAD cHUePV7KjWT+OE73WUeimOF8ej+eacYcFdzp1wP47Dq3sVSjRVEc+eijvIl2JXMe5U2025EA 8o6qK5F/lPdUPUXGIedoeh25kKkYvUTtsHkaZOu7FHx/6DLwRsR0ILbYGEYiGrp0a5vhK++F sCXX/SCbfb8pB4xSgMyLr+Z66n767RpAwqIvW97B8LM2ncaAvizKLYeD1UrTE7vrVRGPg9Xn BACIfqyi6Xg5BDPEqeNu0u/jL7JpTrNY0a+ZRgJRMJxwlpbvRaHvXIXUMaOaDODfp4tBFkYU vnxI/PNP0nX6SHQduq5qfqBLBGxM5jBSU4hBEI51XSd+SMZ9+LzAL4xSMIoNjWCIS6TyD170 SQHzykL52+MQQHOxsBvLT3heIVIP9Eu7gxfziJMK6ln+lvPnSJ56KCp3aUqLvOMsKoFdG0rb Z9qjtH1wv0zmxGe19x1KQCX0uiZpAnPKIp7a/IF4po5naSRstWVaWqmpM2h1knj2A178/isY ehIGOs3UlzVIwbVKXVleum5PLl26mbsSIx+NBws9iSLdW5kz/Lu+SkC9Zg0gdWUSfzECd5/5 OkkQGkGYygBt+UZe6DUb+VFb5ZM+WQxbFxDdH9jIk3kWwWEj9/ADSCFDZhDhvH+LyLNvi00J po/70YMkEUyfoZOObJcmaWK8fUZix/sexkrcubJ9D20XgXNgBKs03EHI0SS3UDDAl2xno1vE L3tITan3jCxdMyCAx5iAthOGlAW+t2UoIW5HdBOx1znuqUe/gx8JfMbsjUMbP//EBAqKmx3s Js/icfw9Tuo9lzmWxfWhkrDAjTBy9TdCTWYDmy2FjQ/KuEahztYO0uR8nGWG0uoh6+9Iq4es vyetHrL+W2n1MM6t9XmHKc/MUx5qpyZ1TxCyqAapeyaEeitN3XNaUk5VKCfLE85E6fyf8u9Y kFavLr1OALe1+bdAtBV5/p3OtN2S598ZoFOTfyeIdq8u/44R7dsf9tyYPacSdDr/f7lxwrTT O5UbA6rbPJkbj0lXyVLH2jwonUNfqQGk2VyrJk9KWPQ7dYCYRb9Xmw+Oc/ng+dxtnDr027rc bZzsZaXsf6Ojj/5X6db53zh1gnCWHYMUI5Ll+Hg85BePferEHc4h1+COpytCSPvKDzBRIqGJ nhsc75HyFMqCfQzWona6V9zbujxZjCg7yfuLUEWT87a31E3EjPzIdEDqPhHjsWw+J2NqzhU2 O9KYmkf0fiimDh7A1+vx2rTrEcJHJU4qt3r7kPL4iacj5OrE+jVzkajenqDHWA7iQztFdi6E CF2LKx8FD4beONnlV0g9J5PEECUZmD7SctmJIjHmz4NJlsAoquy4RtPHg8n4H+IAVpzXlDFP k/FvOS6qHNHMIYShsr1/cLaY3oSgU8zsfUxGVG6dG2zCSuaddPbIUck4tgTHgwOJEWjMeW2Q Y8I83g2/qB31Su10atmpGbu2HNHKEMJybsi7d+/IXAyACZJIbxjZhb4LDR4euvJyJRft/eB/ WEo7YPwgnZiMUPcAqw1lFzpxdO973L/bFArpE6PpXsPzYiHiltcnkqznfpk7q2tKFheKozxC 4qKhTMojyksLOQUY72NuHPnRB+IwO3jQClC1ckKz1I3JYLmCzwLDSgwGhsvYKPM/1YIfgp4x W0+N1eTe0GYQ1rXlX8rMyv1/uSAK3gLUMRAXAxUWT9PxAwb+ZbG2lYqD2GHKr3KiLYHgj0yu IqwqmfZlqC1W4/kMvUy+oBE//A6kiXQ1VAUXUaBSTlCNZ0/gNR7gc7nS10Nsi6nUE1SLwaM2 GqyLA3Kq1ikqSNc0PkSOllO1T1CBeI+zKegtPyCn6pygwkx/ib/cfzX+oenzjKp7gmo1nmq6 wZPjElUvuWQi2otFA35V80Qt8AIsuXYiq71gSP7r4Aa83LrgAYJ6UO3tLtKNAzkvJJ6DpUYu yT//CaDvnBFaTFfcZgEz4L8zwU3e0GS8G35uFB6CSIxYmAPn+QTanevyNeXXULUk0qWBbXGC RLou1R2SJ5EuSrXQy5NIV4TfHHEtcXUvA2rZ4L91+mwzUFFxRbJzqjDp5z45CH1xDXcNMPDk LjU91hCXfZwtfaHWAZIuzgmysjPWbO943Yysj1B/wapjk8vC6/DIQvKJNK/zcoUCys9uTbKj R3FMBhUmpG5gLqm1TMHFHve2tS9JXTS5RNg3SnlgUI+7GAzNIHBsi9d5nGMU2pTbrohqiHav k1tVLDMP7gZoQcClzoS2UC68OKQuWHpy7IcaBf5ONYrDnMAf3mt6MRo1a2EGmHMKq0QfPPsz w+3RDmX5FyBHg+l48rXoF5U6WGEs0nxpd9oPnU572FY67faoo+Jw77XpejIA63xPLjb2M8Hb a9NrZGJcSuVYrrTFYjx7LATWelheEuUN08TQXQ61rXpYnn0xUp8diZMrRYW262BFhSrIXb/5 rZ6vWuTbqYMV+apn+bZKmU8drMi3fZZvu8i3Vwcr8u2f4otLNPy8nv2aW8/+OZjg3z+/esOv w0k5H7uNxWmQJ9M58NOJ7atnurbVgN0M5Wi8s/Gs8JVYr5ZDr6XMITEoWTiWhsh9kTiuhhho KConxt1RYEL+DB7Y9cPX66RsHet/bxCMBfwsJqmiMLaSyNw44KU+gvt0uPtBVYLbSb2j8G1X /CxWLilwFzE4Lyk3T6gwuVBcjdy3JXEXIsgfB8oiVsuxvAEVyQbPwn/+nQGOzAM+49NlrxCp XALjQoYhHY6zKY2nyLahUFxhRKWDw82XyTAW6lFq4jFxfhxFsncg6Z6Ol8viID0cBHqIazNY 5xDKrrQSx8DVJ2t9kovK7gHfqdDsZQ1EocAH7Scn16JOaxDmH0IL37gEZmRBsUVoZF3zW6Ju m79nMi3B0Hy5xqNuCLDdNi9WwX4ZRLoGaakcyOLulprvvr4W3Fa8kCumDenmaiSH6LBZBsvh eMzXLTC32+RlT5PJTQ9nnVuzvhRxeu8jIHMo7/dRFHy8uTkej9e7Kys4XG/pDVSpN+9xBWCC R8w38Jz/FTSXzBIFd3wrPbcQZ0WidvXiwnUXUrbHE2U+q49yQ4QUzVhOxkNN5Gl4I6t2T+Im 4+l4JT3/Rgc1va/sTFWiA+0Jks9kSKNpDEePRL0lZ4HyFy8VnMIZtpSzOPk7lwpOFfxaZ3Hy e8YKriX4dc7i5A9kKri24Nc7i5O/p6ngOoLf7Vmc/PlNBdfl/Npn16Mrf61TwfUEv7Pr0Usf 90hyxsmgcqbS7siQeCpRNurmS79Z/CkXQvFRxtein2++xC8R6l88TrUp/p1npBfgtyfkA0Rj tZ19Vl5OFrjw6fGDi2Km/pKXeTTCx5QSul81faZNpvMHTUanSOYr6Maodn29WGmzwT2mKgU6 VdBJNDUYDjUIQTigoctrijLst5oyt8ztN3lpW4J9SZPuok6j14DiA9jvvr0lFx8WX0aXF/zL B3J5V+1ept0N/jo4/2/cVCTkT4iRUENK/k3W/ahLGUtlWOgnhOAUvFh8ml6BbQxNCMJEg3zu NeMkLkqJOPbSyH/zgJq+dv7u2tuP1QO5uyLKCQ8f68/QSuDvpgM8FWj9FxGDNsiHhfgtkReT kRo5oasopeM/GxD2wvwwwf612ga5q8HsP+kdkf3g8Tl0YsGMSMxS+QNd8gmKlv/MqOE7PzPM GjDWpqPs7cjgFxo0vJOPks/T03t9fiIBAlOG2RBPlq6LjBO1EVInfuRsoMSNMPGHnN20PSaI gDHnC4mdxxx+giBeSBf4mxZkaswI7ed9xD6qd1X+4admgxw/KQ0SHj+pDfLyqVXgYIF5Yb5f IyROfUea+CgOH2MwSr8lD48sbpgFZhWTyh0X51cVDdTYQ0YH46rcptBA0KLwM7EnSFWqlgSN ZXPn7waMIApLNgup5e+lA/r/KEF4sSVZen75BI2M10AcxcSxS2Syb8l50LY4e3y6ZbtgX45t UcOxXTu6y/h957WfeMfi+KZ4wYWpd0YSy4Gnk3wYBomutT81SEFyXCuW8OY5clmcEufMWM/9 JPrgD9LwUke5+lsTLODAqodilUPF9Iy1MhOPvsDGczd88YrD8dIE95jPUWgMaHgOFAsVNiw0 oNTCMsvAu6W72l6xJmhvwA7NDT7u8oeduUPOsuHx/pLlpTO7q7NIQmQ9YJkxRezA+Y6wfq+7 9kjMlrtRtABn87v00qZi4G/YA6AfbuDVZvCWsODVdjv8o0bR2MO9daUHC9QaIt4lp3rbstaM 6GwMrI3rRq3uolOYxHTKmgPjlfOHCOGlUQUKKGv3fBZ0DqC8hYtyDqC+hYt6DtB6C5fWOUD7 LVza5wCdt3DpnAN038Klew7QewuXXhWwc8xnFjfjRVhyDc7w/mVnW6kjEf/DTFyA3xUbcSPs nOdSa9gqN6jlhrLN2K6rdKtt/WpTNxW5NCPwUO2Kr4HtKGveyZtdCFXSdrYpd2F6jp8Bo7tC O+TlvN1+Dosdi6QjCOUUuzqKXZnii3h6Fbzsfq9e9GcSxigmRSUM/8X7MDbh511W7fD2wXIK QSfww4gllSketJGdFRwMk7nwl1EX0jljZzv0gp/CfUgripSNuNMqsOG1CWeDfyH1pNEF4TLE 5EWA5fjWtyIgxx+K4zJ/vnac3KWu8UwjwzN4qm6gnCKZjQsgL2ZYT7KpI8mERJLgcGqU+HN7 lnRzjjQ38/Vqkp85KXI+RI6xCymNiz/IcnKDf8gwLkQ134pH5eVKWUaOoi5fJUEcNPhqk20s HItpMvtAmkMQgPvBl8XCOOCfirYRh8+do73h7wzIVyAJSEwpYH++CW9sDvgEqEpWnAKkHWZY HSKegiudgs0M/l8xayUrDmHCjL2tgSAj8gtE8E+jdtCSoH4gGTDRtbvN8ZErHmol61uiHHEP nXwzIyPwmWHnGDdz/JR4EMD8KOdalnJGvhuYYULMzlIXLQDKV6iJI2NrP0M1DZqGBhaZXhTr mrfHU8GMKWVIw/Akw3guFY7xolW4lPYS9xtYZ1BxhY426tjeN7o1sJhIt88p44GxqyRAE4S+ D3OKOXj0GDMR/+Uaw3jpf6b/L1BLAwQUAAIACADqMVsq3RNRa7seAABtqQEAGgAAAHdvcmsv ZmNwdS96aXBzcmMvZmNwdWFzbS5j7V37c9s4kv59quZ/QLRVju0oiUjlstnzOHWyLc/oTn6c H7Oevb1SURRk80KRHJLOyJPx/34A+AJJkCJAkRZGq6rEMolH99cfGo0GSP/FsHTzcQZBx/Nn hv3uofP9d99/95f46lx30M+5F91A3w0LgtPjy9vJ4PpsMjo5uj29Hv1jCICifhrjMv6TA1Ex 4Pnuo+4DXOz6l7OT4Sn49v13AH2+2sZsHzgWXPoHwRX9QXPRFe93L3tBRxeeQdxEF+xfxr8c FPQ2PhrnegOM/gDuwAwv3Y4/fsA/tdnMjfoMGgr7DH4p6nN0fl29T9vJX3MUxjWVca1fInAg RShw8EuRwCeDmwH4huoHrT1annFvwVnU1cI5wJfB+/fAsQ3Lhy7wbbCAC9t9wt9cqEPjKwT+ AwSa58HF1MSV7RlMSxd9Fl7c3kJbAs/4HQJ7jqobXtTqrqtZ94Z1D+auvQA90p8H9tjtQdc9 YN8J8cBfE6oEtxzvaUHdCnkS3DKnJnUrNGdwy7C8CGCMWggv/krAxcYGeJxMNG8xQYLZ7i6I SgCnG0iIrmNdQoIY813gRLqRTt5+xiUOQ8WCG46LkEclOxHCgLT+T6sD9rBEuBy2V9L7PfQn +MouOB2Nh/tgTvdp+ci6ceP6A+ptjirou7hYfB2Lhu8dguHFKS2iC/1H1wK7uP29HqO80i8s rvSz5X8AfZVR/DV4nS35GXmWv64omuqMKMkAx/Amvz0YPvQcTYe7hOm4/bRVAlVQ24welXG2 w964sCtjBi3fmBvQDS3C7i9QEfU4QD2CnZ3gwg/owj/whVIhUvW1bP3f+er3svX/Vql+iNcE F65Y9t3rys3+R20zQNssgh7xFfURXK7Xxbyoi966ejAntlvWEUPlKtZjqLGqWk7atP/zvhhO IEHogbrRZJ6SGc0Df4/HYnAJjU0TDctXRYrvO1nhyJVDlvejHdqqUkVK0L5CUJcK2qAhlyiE Prug0GHFVTggYCiHiyTOiaVbN4m/wtlrQalbWTfyWaVgzk1mtfwWVUxaIfUffXOiOQ60ZqTi xLcnKLxB8UPQRDeQfkFQqIoWLvNcCJqjudoC+iKYkUHrxZT0kBC9gxScSom+jAFeMirwZ+pC 7UvcXdTGK48u9y1dBRd43X2NHda+k3ZZxa2ypGNRlqet1weVhIh+f85qGRgZTR6d1yvU9Vjt E9uMD9I3oOlBdlFlXCQLN0vXxVMTrdAiiiIxunnBo0+8rkCSrC5lalNolpSLInEU4OP4frKq fNSu7eB1A0fDKyvEekUjVuFovVKlXA+qSA8qTw99kR76lBOKCambEFEx4mFgpnCZRpsudOAH oLR6aAyQN1BYvbQ2BTbDAJVrq4zaauXa/S4TuHhIogk+AMR2Q3WpdpnxApoZiPuKmyicfYOS 3RjGDISMFlZ3lvKC/x57QcoDIo3wjYXmfvFC3Q4/hzKAuW2a9m8eQEt/F87QQt/zkOK/aWFJ po/Tbecpy6i0HwA5jSqQqhCN6uEfJ3brMVblTlOzhiifqMAkkrAyt0Vp1X3NH4k3oV/xyP9z 6FfsF8X7TNZoVBnCwvfvk3/BOnQ/qeZCzza/won3tJjiynSOK8ngZqLe/SjBFeRyWZctRrrO SYJlXARhf347HtMe+fgB6l+Qr3LBowfdIC89A4FsXlIX/XeIs2tU7i9ewKC7YcrjFelkj+Ep 4+g28HILZAQYuim0eMFt4LZ/97qh8tmQMpQ+LKZTwWI+pnRwQLmbwLAXd4xZgnPJE2jCBfJH E3uOw7wvcIZ+eH6gStadkCQj0SunFYGdJnTWtk43rJpbRARVi7RMrPmcSRhEyfx8zBrYbgWt qO86RTGKMxRl8ISN0AnZADRrBhZQs3By2XpcTKGLk6F2OPFhAHEu2qFIU2CGhYZmRn2XpK/x 4ivpfC+Gnyy0HI8BejZHjPRTUsvTAKkEv9QEuYALDxJLd0GvWyhCpELASqwIwS2vQ3zBhNa9 /4AZFdB6Mn2cz7EvigidVixsuEA93ODchXh4kU2Q/b2dkJrrxyEaeAgNLmVSEOl1IdILINK5 IIpQPXhpPPXqeOopPNmhYGKlqiaKHOlBhWb16pLm/Fl2eY5W5imPmuAdTB7dyMcyPBgOXq3Q gYXVEy9W4q1y16yDlBNizluOx88svSKzKBrSk4VVd14SYHUAgJebTkJMkoiAEbiQ5XBubiPu vmB+MePv6Y06ep/QMQ9YF+dUWFO+PRluTQY3cD+ARCdxtgnfpy6F+ppRBJNsUaJOE/3TIY2Z hDSokFBEYxIWmGTEmIyIhnQeg1EQypgRZQKgeChjFoQy5pwWhYCF5Zi//Uzt+aZFCfZUM5se kYkZuFB3ktCfaqRY4ahYbMxs/BPt0+c3eHQcyeLMaSlBs9lkeqO4iOpBFIcsuUMUS6GQUZXe 1knJrYxLo7YVg4rQn5iKOaYIi9IxWxCU4ZAN5zErxWuFXGPEa2HH2TnbbC5eM7PxWkqESIVg zNUNRsy8YmHDHFOGmZ8s1oBC5FSqRhdmCiDs10vCgbj1qk1Hzi1lgdClpNx0ruMq4QLy1N3I jxWGC4TNq6KFFXOPdZAaBOlZIooX+Iwf8SU9GZtWXX9emXh0r8TBM0MApGZpCMB0VoYVnIAy bAsbMDpWg0xBki+5QzuYCZQ/s2nn5ij0Lyr9Sz9jxOg0kWMwggIzPg2WuhqfB0tfVZlXk9M1 jhHZKei01BeGcmVdhtGcLzSyvjAlQnrEIWCiDMWqAY1KRrLQSQ6DcJk0U+RVTaoqhUBUsXj/ sJDERqq9Stjl8KMwLMAxFJDASevwnEPRUaqi6CglKJJmClF0lEIUHUUIxdgCB5uHOx76GHdK awbuamXc1TLc1VLc1WLc1ZZwj628iZZSQ0upZZbqV7ZUv8xS/VJL9Yst1d9YS8VM2kTb9kPb 9vO2xUVY0VxB+Ji4U9MO1kwhrhVqYWdg4v8SbKvUUgkru9T4r1KrT/TtUlwUiE5RFNQFoaUK o9PSUGlV1JoLeNIXrXS4EsqUiVoNnqiVORj4BgLfIFhVup8NZQ2rKDBbHUAbVQNoI9crhtdg BtAIcY4cGvyqmY/I9BO4dFzoeYgWBYt+WJBJiyLWZSaCRerPpvnnHPRMVo1OdwSpMyrXQtrA +OJG994q+TOuZESRPEvo1ZH6xizKe000f+LY4X4e1qCDW5z1Jh3kYtIZsKirHpVvqtmNUtKN sr5u1JJu1PV10y/ppk+tM4JrrxKjsbcpIXhzCP5Kjbw41Vl85hDX2ovyoD3cR3wtt20J37zJ jY5gV2jF3ihMrZoKNnyWdGSh29ZX6PoRfMiroiuer1l+UJ9K01FTYJJq/FZwIjSbP4zly6q7 ZGmVrpSRIcUJfKDyMMYy3/T+bmiwzASfT5bywALzsGRJ9ANiFi0Qbn4X/f/5M4iK7APlY8AJ 0Fueos8GZISXkeMtcLUuvEf+H822xkzQ17p8flWE+K9o5qePAsCDCicRgmdQ9oNah+D1FX6Q 5I8/UtfczJMomRDZ5RlkmJ0Mkj+XWTJj7ucN32lwWRN6OsaLwzkVs8zbJYxBNLLDxBc+VhV8 USha7Ts2+AMPrV1UgIykPk7d/PADUHsxmvmiSrrox6LAMxaqXyBUv7J0/VSXygfWKagcBrgj 3HR4vqpMQtVVfqND5Jysth5+mZs420X9spglv2h+/F1/qq5lEH3ktLZ1wo/AwwWag17qQZi4 aCAVKdrrh0U/FRddzIKiSohnibWJViBdXC1qWX8CmaL9Ukv1aUv1+aw1N/36FoNLvZqZqlAG d417jY2hdOP+euPgX0ZLBoZIpDSEq/FQiCiLRV08UBNScxXJnxVCUTPF67iLeCa3kcvWrJlX MI2XbSV0I7u41Fc1+arEX7E2mRDATT0s7qY2D9zUBgOqfFCwuYycKR0UsMMTpxuJm5pasUzJ Wikz79EzIilXvtos6KJgQs3GCESJXibtlBaPmtuTKVWtrLua1Z2xya6mxoOrVG5cqdC4kmqc xB9uP32K2cU5SrefKaRmCmEpCVnoQkqmEO7NTa+0IwompQKAA3IxQl2c+gjOzheMDLv6MCkN hImjw/1kkg/Ys2QuudYseyW7Fedmd+Hc7EsZMsMpdSIouuIt5qxXQ1AWjIQGNHeJMww/yYoa SQ2Sq1FZZCTWVZV5tc+6GrrIzNXo7FJwNYIHKZQpGy8rkFp1jzbg5F5u5YHbZcfXTlmAXS2+ TqXSovMxBTucmdOJWLBudb3yKeeqORgj6a3zbtoBZPHEerymYhNzr1O3Ca/XYZ47I8RNe1vE GDr9wp2BSvU7y2kvCMGss5Z2PKUUB6UpHH5dEw6eWiq/2pT89rrk75fK3y+Wv8YQdAvIj/1z g9x3lbJuG6Oaq5Z12xhD3H5Zt5UMi+eqfANU3NGDmdPI5FqQ2MKzzpti7x6JmgpRw7Q17vcz 6K14MH0/7i73uhRKs7dvc8/PJxVzsW54h1Qqinbfvwe35/91fvH3c/A2fq2TBzQLPFpfLPs3 C1ArRoAmLOo5bFSXegkTfoIUP24zvDseXt6MLs4nYcOj8+ubq9tjfAn4NqPqFALCAzh7xxqH rCewQl6EMrK5kQRTh8Hbyy4uI5EOslm8Xv6oAPhpfMMpzoNm+tVl+WkwvqkkyH+eXQ7YLqpE lv9Dt9iyoBY109A88iTdwv4K31mP5jsLuL2uu+y6T6wjYPllbbJKCUPzaKXmkv/w0givVHfI AuGgHAmsILMIWbWjlT2V5WAWOhrd7NLr/vJc0k5clxwnoFb0hbbghv6dMUeosg2wybBWQy2T o1orbKY33WzY+hsJ22LTYVM3EjZLylG6JufXKLBSjmMZgJVypLcMbBw7jS8GJ4OTkys6wV8Z cdPWZvgw4cvCHalQCpZaCNYaGRjhMds4QPL0+rSCXaKAUcy6uBye31z9IkgthI3lu08ScKsg bsahc59zGI4EGWdsBkyjYreHm4lOGkX7kNwE7DU0YI2Z7PjlBvinvc1B1/vTofu3DUJ35v25 ydsS+KmJS3jOemlTXFw2PVWdXfw85M624TSaLNk2rOCfKNtGMN2AbJsIrC+4mgxhe/FV+irY +v+CTQQ2dSNhs6QcpZucFIqAlXIcywDsQsaR/pLZtuOL82vhbBt+cuNd7+XjfaxEMej44DIC /RMoBj1YE6RPI7NaclXqCYn1LZwIjsrm46jIgKO6+TiqMuDY33wc++3imHOcd7U853JTXOed 7L5zuSnO805277ncFPd5J7v/XG6KA73bRA/64/Cmi/8bdcHl7Q35b8SdxruH/stCjBTg37Vc 99IHoWC8OAyc2fZxGZPw48gg9UDyeG1gOY8vTBlE9JenDELBeHEYXpAyqUDurAuuby6uhmcC jn7x8i7+bDMSMJ5vu/CF4QjM2E7eRIAs7YFT5eF2GgGaT8HbP5MH3NMPuq85UIJyYaIIYJJi jciBGuMlMWK/iaAIpxFNHvLygbX7GYIIlBAShQeSmDTEpYm44s0fWES11rwNAUU2VGr5G9LS SAQmSTxOoGDzLifABMoIipjTwX7rVMAvz+WYzU9bDXHmUDJU6gc5Itwx5hLN6actxTlzKCMo NSKdUxHXPJdkVj9tN9iZQ9lwWUO4I0QgWXxPqGJbEc8cSgmLmPs5Hhz/NDzjzQHqmv4AFy+c 9gpFbyStnP5LDAinj++Udwo4RvwAA9fwHxbQN3QwSmzkJVXiSoOTE+7NHW0mQcIMKcZy6o1k WBEgnnSIKA0jokvJEaUpRDzZRo3S9KjxpBs2StPDxpNu3CgC4yYJDG+PwNEvN/xPCXmPUwki 6Nuj1mYgBIgnHSJKw4joUnKkuRlItlHT/Awk3bBpfgaSbtzUmoHObsf8j6i2+eiVKEBIsdYm HwSIJx0iSsOIPEjJEaVJjjwUvx95BZZy0qu5mVw2F9T8TC6dD2p+JpfOCSmNR8DiXsiTzw0p Am4oDoxORj9zB0Yz4+vmA4QUay0wQoB40iGiNIzIQkqOKE1yZCHkkjCWctKrOQcvmwtqPjCS zgc1HxhJ54SaD4zEvZAnnxuqExildttVcOHgHjWTb8d9JLLlLsnRX6xeC8dg5ARE8Pzd7dFI ZItMlsPiSL0WGCMnIGKMQavAkUheWxKAsHotMEZOQMQYg6bHkciCXxKAsHotMEZOQAR9zMWJ wNtdJTgDhRRrb+vMluEIVAaRhtPWknGkhb0N2UgisoRP/MrgmHcQaRKcWEBqtedVNN2TDhGl YUQepOSI0iQicpKkwe1ByRxJC1OPbJ6khW112VxJC9vq0vmSWnvjKNIZiSx9ZEkmXLSSwZUT ELG18uDk5Pr2SCTrL8WZ7UC99h52kBMXkdk6ZtDlxeXxxe35DTeHHNvR7UfL33y0IhXb45G8 2NTi0uj8mJtGhiVBaIwUa+9FDrIhUusVDidDfsrMoAQAIcXao4xsiNSizPnwR27KWPB+8wFC irVHGdkQqfeimOPBeQJQVYh0zSIQpc4uVX2XkzcN/j7Bpj/vhpDhIF32bxuR9zRX5CUH7LVw 7/35cVcawt0Vxn2xFXxXm+J7LeC3gPD9JoCv5eA9GT28shkevp6L92T08cpm+Ph6Tt5bbAXn 1cY4Xw/6LSB9JT+fvMDv7HLM+/a+hSPBE85YsfaylfJhUitLiRsaCtAGyoHRsF3iyIZKberw 79BimCTZkSQKtrBHKyskgi+axQQU4w2UCKVhW8yRExTBHf6ja/7tfRlePoYUay/bLRsitbLd Z4M7/lNE2lKGc1Z37QU3siFSK7A5G53zU8awJABodN4iZSRDpB5lBncjETcjy9k8pF4bhxWl BETwwb7R+UjEy8gCEFKvDcZICYjgCwourvgPJnq2K8HBO6xaezOTfJjUmpuufxqd3vC/gNd7 MOa+BKnQQL0W2SMlLvUZdCXGIFcSpK5aZpB0uKyBQQNBCmmyYDVom0TyIVOLRlcXAhOZa8vg rrFq7bFHPkzq8uZKhDeuFBhdtcobyTBZQ+g8EoydZXkRWqBkGy+HkxgWwTU7mfwECeTKhNRV awSSFJY6BBqIMkiTCqtBexySFRgxFuFAaiQUOEsCE1GwBfLICokwba6EaOPKg9FVS7SREhIx 2hxdD/k3KqYelCApfzS6ubjkWG5lHyBZ9nrg8+fK5+mrsUtC6JTGoEtYeDzmX/NPddPdBhYq DbBQPuiUxqCjWPjTjwIsfLjfBhaqTbBQOuiUxqBLWHhzLTAj+95WzMj9BlgoH3RKY9Cl4sKR UGAoSexMAK20nmgtLpQSOWX9yKXCwpFQXLgFJGwoLNwCEvJHhSOhsHALSNhQVLgFJOQPCkdC UeEWkLChoHALSMgZEw5vroY/83LQ8F34VYoAGynX2umMABZbNlxqndAI+DMSQkqewYhVbH6b IkTFlhIWhReWhEK/3AwFfNCTD+VwQoF64o8XJ2BxzHWSoqMIokM91nXH/UzX0pThQckaTxsL MAih8iAVKoogKjFzhneXg/MTTpjg0kGaS8CfQLtWKRRg8yAbNrWJdH1ye8l/XGz26EhyIgqp l+UR1xshxhc/jvjfs27a94b+roc+m08oouEaTin01vrWvxhBRfjFfwjOTlRlbwvMoPCYgcsI ylbQWG0OP2Ub8Os3hZ+yHW70Q3P4bQX//q25aUgJPaDINLS03a2ahj42aQbxaICywlaY4a+N mUGJwloRM1hbNho+NeTUld52OPW/NUhjpQ6N/a2i8aAxGm9HbHzUFH5bEhsfN4ffVvDvpDk3 Wic2tqgczTa40WFjNN4ON3paBb84d3txxbvVb8ty+pBAWevwMAYRgzQz5nPoQssHju0ZuEeg eagWmBq+7RiVXrR9fsILNEJuC5BW1o30HT+ll1vBabUBTp8LkNraAqz768b6dHDCu5U912az F5/w5qa/GmmsHHsHct3PjcuJidIkJhiSpZw8URrlyVJOovCCkriY69sjXu54j1NJUELKteRi pMSkWReDIFnKyROlUZ4s5SSKuIs5u+X9k4rzxaMpCUpIuZZcjJSYNOtiECRLOXmiNMqTpZxE EXcx6uj8hpc8qmH5kuCE1SvOD5YtS11rBnZAH6lJ/gruGmkmKXzKRsBH0FtKyj5lQ9i3lJR+ jeEX+0PUoXrKiSkCVJ3LgShRr6I/rEk0WVFRmkSFgLKUlCtKs1xZSkoWXliS2Gs0uLzifVxv bmiOK4v/Jgq2tMiTFpdmF3oEFmn5ojTMF2kJUyNt/d9XN0KOx/vV9WUaZLGibSWyZcen4aR2 BI/U/FFa4I/UBBJ3TCcj3ndgzGfGV0mwQsq15IakxKRZ14MgWcrJE6VRnizlJEq92Edk3pLI IbcY7EiISvMhzlJSrjQc2CwlJYu4rxlf/MjLH9O+lwQmpFxLjkZKTJp1MwiSpZw8URrlyVJO ooi7mOHdJS934NKRBCWkXEsuRkpMmnUxCJKlnDxRGuXJUk6i1DiBODjmPlqm6bIcohoct3UC UUZMGj6BqOlLOXmiNMqTpZxEEXcxg5MTgUcptNlMnicHAhXbe2ZLVmQaf3JLoocI8pxRmubM UlrSKNzv7q8OzpOna2aLDxAkJxkPk5fO/nJ9PBiPwR8Av0sD19gBveUp+oQnHHv4bRnkJlIf 3+uHd9SP5A5+SL/XWxtjfFdz5EdEWSMi7hyyAWEJf3U6XCNDdU1/gItF9e6PB8c/Dc/O1vj3 pacTT/vKAcD11dHkevDzcK0iuNDzbZdTiqvh9c3F1RoFga6hmcgxcYgxvBoNxqN/VOSEg+8x Wka3qDvRZ98JmlLGdOumB9nFeuNsl7HWcxdCNJy+2sZsf39vJ9CYjNOgoAv9R9dKNEQ3SCP6 g+YmbsHwkEPAt3fB5eD67GRwM8B+ARfaD1DEGoR6kapIsIOUMLiZe+jH7QRuxUY/Op3k3w4B 44BGLgNPKDBROaUCwYrI/v598u/777DqiQiIAh6cQGtGa0IJHxfUTahZE+9pMbXNiWl4/i4u d8AsZWpTuLIQNUNOfDuZQk3kbt1U5ecisafw3rBygkdhufP288JBPw/B+e04YgS+6JGLES3j 6xjY8Hp8DYUUbvaag0DINeqYUzN/EemYXCxUY26YiAABefB3S1ugiIBpjtPReLiPsTyguEV+ Zi4QE/xPMDpRQ5PRydHt6TUanuB/MyUDAlYqisRFoiHzKHzFVb7i/cLiIZEQpnM0ISPTJ3B1 XLxaOKAcHcO96A+4Kj38cOekLOVYfnsIDQJeIdPTg+1b2t+kWjINC1Wad9NFGJ8d/aFCodCA PfC/qwvjENJGKpM6YK9C65HRuZoPKlVqn2YKVx9JRb5+VNF+VL5++qL94Kd4EkcefbBLpn/H xH0VT1ZomoELx38K5+hdmhXJxFxAzhRBZ3CO6Bk4ZjLX0PyKHR09CFLTZ5m4ZQFFDjfQgb8+ dhiyZyVfrUswFQXK0HTOkYKlFv0rjiNWa5LqomNYuvk4gx0+K9DuPjdEqJlyjYLa7n01IW/H Hz8AVPogfysXwNAfVIX2qfGCCS4dFMp6ZP3rdBlMiEObbItkDDCCwALB0zM1W4Pn/KV89Jhf /Lmu7RLplSZMgwLse4vDOKQ8r3lIpZc3EK4SiPI5PaMWWxIveqPf3oSV32JLgPfhb3tgvxCU chNXNvPGkmc2FfOiRmpOCvzj4SF43XnNYU1CR4PJN9IHXqkV2CSMrdJCGEiIINQCOzvse0TA IuJ8W2HlBUS+99GfWBP8J/W8CZYgpBYyTxfs4iG0l+1172AlTd+8KSljFN59rkGyMpNMC/or 9RD4M12zh1jlJdZhtGktAz236TKKxjvfiCdvBM6+UDj14WzPhJ21tjcN26s4n81457LZZsxj CSYPUP8SIoLTGcYMxr/l4JmygsWVpJ/SpFe7CII98cmudETFjZdHWG8OgfqicyQfJ39d85j5 dc1j5td/jZlmx8yHJsfMh8pj5oNEY8Ze85ix1zxm7H+NmWbHzKcmx8ynymPmE2vMgHYXY5nN nkyuafUKjE2GZGEbvN3n8JC9KP62Qq0wE1a6k4KFXpmtrPKJLLiWxvgS0JVa5E4587WqNtJq n52h3LgZpLp/xp9Oh6zkC7CqljCOsqLraEtdY1t9uq3yGYgBZvVc8aolpoNk85Fl0GTdKS2Q 2jMobWhFOynHV6ehjI3X1Ji6zsb6FRr7p/VPq1M2glLbJ3PdtD1IbzWGJdO0KLQ/Y/c4dvTU BOAV7OPji6Pz65PhKdLACCUg4VGUx3fC4w70lmx4iCPZ/capvXBjOywaJvTQnWi7NTf1hfuG h8UHHwy8q04OP4RfyfGq8KuafO0zoizGmYiibdqyMUVUo09SPRedNGG1zgx5DGqdEO2d5gIf 0u9uYp692A1hkCy49CfQhAtoIcTmeJP5C5yFpyOCUyx7GPq83M/MgysxZegzBwjZOUWViD6o /EzztfyxldThi52wWCxDsgP/Krz1LmMe5n4YFqKbbq2oJZpbqwYDo0HW2ZdK/eYO3SjZMzeY P8//D1BLAwQUAAIACAA8PVsqlqg2gH0jAAAqVwEAGgAAAHdvcmsvZmNwdS96aXBzcmMvZmNw dWNwdS5j7T1rc+I4tt+nav6DZ29NiiT9wIbQuZ1Jqggh3dwlJAukt3umZl0GTPBtsIntZNK3 O/PbryS/JFmy5VegH+xOB+yjo/PS0dHz/JdhTpd3M136x0pzFy8W//j5p/8KHznuzLCoZ/Pp GvydO+gxeAG+G6YunXeurtVR7+JMPe+330jh57Q3rklyXdqlQMHzYfedejmM4HmgF9f9s967 Ue/NIIT1QJUY6Kg9vh62x12MCB5o58PF5dnbHk6uB9qAoD//9PJl9N/PP91bxkyCrKvwP8N0 ddvUlqpu25Zdk64gRmkNC37++adHuvh0odlR4bVtufrUNSxzrt0tXdWYq6YF/pjqR4BUX66s mU6jhNQZ85q0fn7i2Op8qd040o7HB6R/pP6zOxx0+4CjLiwRCN/W3TvblOpHkCL4AJTXH6b6 GtYufTn2MHTfd7pX497lQL0aXo67Hfj1vH3dH4fFfDzykc/c1bh/2o04AkKdqe5yEpH9TLru t5rS0rpRtdnMxri47tcPJSPEPIfiM6RjQCP485tH0OD6QgU1qN3BeNjrjsCb/f2Arc8BbxGX vmAAAX8AHH++uNeWQFmYGD5HXwP4WkTbf4jCEcnSyQnxZq3d6Kpj/J+Oo6YkvUNQIu0eRZCP 3tdHSqaD634/ECtpZNOFPv0IxcqTqvdzT1qvF5+wB9IKE7enqTVUzlGgAAAirTTnY6iEHJa1 F1YKdBcQ5NegLx3dV1ZUAJEAYFlGAxiLxH5EKvYXryBfm2km3X7TDYw5rjBSP9EP5y/DnS5q nig5FU81x3cl0FbbnU53NFKhnNTh67iBeEaHmHl+ok2nuuOotnGzcB3p+JiN5t/ABr98iaOC n4yo3gNUDKv9zEae2UuwkMQETDUE/DOxdS0yx3QB/7scAQ9/CJgj4PccATNl8gtfJl+bRECA APtkBvcvX0pBry/pq7ul5lq2hLr/OCw3TlgT7o0mhemJfIkvDFedWncQ3/4+QTb05MCvAuOH nn1XBob4229BsbDPIooQzjtUavhsx8MJ2gbeTe5If3uPj8KOjNFpLTRzttRVF0B6PpTVgd0b qxk/JACSBnwaS8lYrZf6SjddDVmFNZfeXfTOAHEgnjINZyW5C8OR5ncmCqaksLRhoghAc3VH 0pZLCQpBAmhsQ3de5A48fCulooxjFFw9xgNGxGgoFlu/UW90V7Wm7uSTq6uaW5Og4PZCmQSd t0lFfHXocuzEoM5/ACwAiXkXWNnzE1DjH6DcnwF1bHpu77RZlQQxSYKBVU1qKNIeRA7+tyPV H+r+59z/JNM9s+4mS31DlMstJuUB9cmUb4hm6ZBLM6SaHYFCmtd3Qlbr/8WbNYecY2mWXJuI TYpXt3Ms/V1j2Bd0krgRHiVi+QL95IxpqJ6/jVAlMydmuPnZCyjzaIosNTN7IaJdElUye9Uy BinyqDksxBfCs0tgYjda2GBN/cGF/NV8VjDSsZZnS/uS7DeuxnmEj+wUyIkAb4AXhj0JY/4o NIo7gvHwukv7gvN2f9QV6Zcc48YEFLg6GItNfA4tmgDwALJ1WGfUjt4CMdcfzolPvR7qJhoO 0uV2jpmKYesCJ3WWSmpdnNh6PR+xXutIJ/ZWgNi6KMH1EDgbwZG3SifYYhHsY7bWpFlJrRfy C1nqWLYutW3DXax015gCMN1GUZvDnkDTH/QpDCvVyezWAmGy49p0kGitG+E3JZzqsNYy9r1O RJEIVD4ifkbdJHiFol2ADbRVgB21VtC4YFT7B5r/AHHyfHmDYqZISzVU8jdUDg4XsQeNaND3 OTYdhZiCjiOYTiHnJqmhEUQJFJ1MjgdYl5Bi5SgOj9tBCBXxv7f2JBCJaG/tgXlSeuRoybmb fAVagpAnno7KUwjsg7ZQI2D0qU6eRh080dFT8nGh+4pEY1LQiHrgD6/X8VrWXhpQA+vvI4lG xD8mzD7iZrWD3KlXI0IbPEjGTdunDAPrut/lowg6KlhDf8H7Q/x9ca3PvhWtz0S0Pitf6wy9 59Q8pnqe8kHITIAU1//tt6L/WxH931ahf44NlGMHfFtoKHGw4vZQZqfsNHBzcBTSOBpL6veC /K1Q75UFXV6JYYg9WcZKLegnFdis05CQsBtENB58MJNwFA9QSQOEuI6l534DCIKY+sMrcox0 ThRRiCJKchHMGhtLjHrGLJoPtcCg6MEERkcArywxVrlYlQUGxcAa0ejjA8Tu4dbimYH3auG9 WhxhpRZEqQVeasEsFfGQzyAe+Q1uZtw/YSAcTv4h84kvpyavlwAOeyP45fSD+nt3eHlEDxFJ 71mB2weI1o4+J+PmwOu/TIFhO31x/L9mwC/egTCHAh43ftPiQMQ5ScH4a4AxGeFjpj4EG7Ar 0iWyHG2ZZ9BulNgMAspFR3w4bymj1urIfF4amaATr47MvdLIBK6vOjJflidNq6IJpe/AJT+t y/xV0GUKeLhEg9CmVRqERxIirbSxE/x3f2N682vfEu1ZFXY1v5bmdUCPWO4caZE+UbSD4jED 0KBtJiW2GAMPcc2woZi+WFmbMWrSYR90X5DmScy26E0Z3vQvtNeaJMNFPSO+F8vENs1E08XE chpODzl1C9+Ynkxjo3aTZyhYtNWIoq2eObXRlpbnE83RZ2Ihl2FOK7QuuZwIQZ9WGG6VQ6Op 31RC49+JDrosCTtTzayyVYY/JrEmyu3Zwr31eEPypjL+Bn/Si7JX0CagvBwtz7PcALIJLIQq 5EEY+8MDhzKBk3cMh8LYxmgiY0gkGPxrQIMQ2ARIbVt8TO/BqxIBz6dyRFCYQap5oUjIzNBQ pqv1ssR2HojiNzzsxylMathkRxKUIJcARfjRvyWGtIlTATueh3UmrHg0TnEQYD8XibF3Obst orBWySSAlfZQugCo5W+SvEa55BtmBeT/9lTkO5btVmB/J5xpgTgb5PycIjA4I1mN42hQe7LD 4FMJ9uaMFsbclTRzJg0tV3N1scjTgaWWFQRNyP/8hlEupDhIjV0RNScnuajRKokosUWgzHTZ VqkaC4NF3kjNmwhICDa8yIcMOT6zhm8i/jsKMGuBEcnopAIecpB+gl3kKHW9BwjS/joFKSdJ DG5MQBLjiVtYkB4mvuvBVhlODTenC5oYrrUu2V1nGIqIDnpodxIGzqhTOELnUmRZag/Onkmn 49E4ScY4nv+w8NSl95dDgKfz9k1631GEg7/xyoPq64iNAay/PxTl4wuDj3pdQmyMumNG8M+e TVHw2RTPqu7m86Vh3gibk63fVzWOnhwlzhQH00sTScJGuP2UIW7BKbLP2WbK/I2o0ciXtf/l 5OQ4mXJPy2lz4tQdALHY78sxIcR8s8jwSAJU+aT0mCEHEWVu4Jv8oUQbUYEK6uhwTeiaY1sT AYhMgiTsTqwFGIGVQDDqlGwtwAZe1zFNZ5HFbamyaCbJQkQYpDR8GIWEwXb0RTANEkZpikkV wSWIFdXFeq9477lqafjv8+rFKlUvh9upFx+mScJgu/QimAMSpsmiuUXBsGh+RcIctMTs5KCV bCfNw2Q7QfQm2AnimfW+mWKnByl22kqx01c57XRlPFSyBUt8lhvrUkFQctF7/5Y8D0BOieH3 SWDdZMrFEvXXEPeLSXwiNeyha5ExoeOH+1572o12uPviRdFXzR9iJELX4MN9pDLWSfWkqg9j yDzLYFd9yKgawOeqGtVDIvOMmlk1A9p/k6Nq1DhIZF57ZFbNgK5BeH7VCfc2yJ6BzPIbSFYT oYzEE2QBVWVVFqUubv0JQlM8od0WEVoewcWEh3jOSHzDI95iE0/PDibcLpE2ZPScWn/zTg2J Stip8aBzOTUPmahT40HncmpY6xJwajzoXE4NIRN2ajzop3NqcZVnNZFiTi0u/KzK2oBTYwkh j+C20qkVmSrQH9aaWcIQnbtkMLtblz0PUaNPNYYqpENuBtyhGBw7xI/DsYcKcTj2kCMO1xTk A3qnbEuAUBGzKhUhrgpxIYuLr5hgbqsVTDbhkGxnZ8Z6smm/cI66ESy69q0b0WMVSwhKkRof qjaoQ3YJZ+MM/PiVt6ljbdzYsR0OQCDggQ2kEd0p4S3ypJRQnhEj9yAYpEbPcHImmDCpnzMG 0Fi3X6/XoYjbg7P4lHSwJkGuorP7FoSy5aGUZaij95dDHsr/iKN8FaCEZfkYv4hjPHztrefU IZEDNsq/axHWWOfKwSs3PcQe9wOORP+uRUIVwBzdjcdCVqfKk7/4qxeG46RuTuPsNsOXM4LL 79iLGgkXDwbbT8SQJCDyB07zmvxM3uWDiKw/8j5ROEcQyrkN8ZH9OL5OJ85YPQ9j8hMwxnjE 5vPJrKCezwqUr8AKcjFWf3oreGR7NGKggDq5NbeTA+FA/RkibJfRzWMbHLJ29UZqX6/w15Kr 6Z0bvN65/prf1UF0q9WhYLf0mt+xZ0KkvOZ355kQNRIo8jb2Q1zczrEsU2qCiLGv3+tLSZbO lxYwIfNGurIM0xUzqTm8SssBhZZ6OeHuHBKB+u0wlMEeKfFHMjMyD7YuoAh0D5gfKrG3u4NH HHPPoMnXCrH1AWll7p1XmbOO4QTbefeQ82goAAcqtcu7sDASm3cjYzli83ARYsMeKfFHbLGx t1ZjYvQw8OWIvS8kSMCimCDhAbjvwv6el2p/UGzfqf09L9X+4GU434X97ZVqf+hOse/T/vZy 2x95caYnSAV01apt3ZmzWsDenJGNI5ZWgj0R4lp/afbMkerxQ1lzCe3s4iYg8egHdgQH3PNY 4MIO+4myU91YsopyQzGc4ueGOTdMw/3ESrbBIi4Wj+HY9gWw0eQ+YtfIm7pm644bbewgpEdt jIzIglc8hL/2pfqLg/jYJV3ccVGn0Z24hTeEh9QFP54LEMfSZwptMX4Sdsl7pl++753jx3pS XWTQfBOa5RzVzhgAeXu+Ij8iMrXsYa7AdfLY5ni0p+Yb4FXmVfW0Mu2oPWXv1noNZZc+5ZXe 62XjqaJuMM6T93I3OOKTsQdKXnlovlD8caSSbxwJ7zj7LuKol6XGUVBs32kc9TJ3HIVZbcO3 2kY+q3VubfebN1vfGUJePafO6AbyDkOh/L4/+80gSvGBqDYt1RK9bH0StrpbwDZZ91Xlt05M kuRrmekqZG/KKecQVjgwgwoo05TjCihg3CkKyGzOlAqw92XoQCj24EyrbsWEIPWo4hlp/0W9 0FQhcZcXE1IRmNTeinlF6lHlE9m55J9k42xIhRnDHAR7fi70lWV/ktooQ2IsfsHgscXD5DKc RURtlmsNMfyprXOuKJJbL3LchNnu994MLrqDMZ3Lkb4H09cpIyHu+plnuTsa+MbL7YnRys+5 tCanT0IScMl4ZuYtBsqtI8EFP8Vf8FOST8Iyl8exUf1KX3l5qNABPUeFCXM1rwrGyV926hEu smUKsrwrm6zdeC5oHj9MtkKTJe5vL9Vsw3uhkqQtk1sORE09tEuYP07AyCNLi1s6E9dSBNdj gp/l22wgW3wGjpXqk7XJMsGfr9Mb0lPQRLbYdaqcVmXuX0VtnbmbVRHkbAOtH2+BjawKwJua SEGqvdFbLKE8OfdA8N0TPLUDN2YaYn4qs6/i+CuCKFbW0fWz5K1j2PZxA7sxF+ZiFC15KAqY 2JEektctJ7bhH+3l+2gv/66uvXD6OgFLFjL3NLEyWpt3Riy9BUw1wPsqoQmAYVKYZ732C7w6 1bSisRE9/moF468zzdWkC+te54+9WvjYiw8fS9dqrYCodXUFgNX/Xa018AQusNFDa4wHhGAa mtyUmMdM2JMpZ96TGeYm8NOK8q5uZ+wcgFTJ+fZdhllMRa9uy1hfg1efnBUxEZ6LhKb08jtd 4ZQ68xBfUsfJIXydv9Y+Tbz6/l7P0zvkOfGTf1cx6co4zQM5Supwg+CAUkkNOUEVTqqcZP4F 9CirdURD8V4lSBvKy8ltUrBezlcvYIevCTefEhJlGHwHsnr41oRFNmj0hs72TSeDDo8ZMNJA h5WyZ1ECYpPLla08IMy0eROvAR/xliyCJwYNgf3eg+0ShDZ6kdCRTJusSCd+bDgaoqjotD3q wq5tJxKrfycnA24/iqZAKDn8oI56v3eBBaKng+uL8E2vO8L8dvwAGuGm1rbl6lPYzaPTbKox V00LprtQP+q2qS9X1kxPDsMwxFiKAgabL1kM4LnAkov/yimOuVGormCiem93BzUC8OwPQNmf 1PY61HVCOTdZN/6h2XYPHYjnUvaKkQf+4hvXcNkHQQ51tzPrcpBABEC1p93h6DXvRgAKTn3X 7me7ciBAcN6+6PU/pNbjgeWvZjTuXl31Bm9SKwoAU6qKn64kqrtov0eWklpdAFiAM1haTucL gRWsRhGrRilYTUOsmkbBappi1TTzVwO123l7PfinuDFE4Pmr7Xzo9Fm1leODmUPiOFMwRrHV 6afpUs/HxVX7DbvBboCNtXZjmDf5+OgN/4V6k+3gxLBvVZj2KD8vHFPeEC8wDs7vp8fD9tUW Kce1tXUB7SButkc9iJsU/ST56A+jTrvf3yL1OJ+cqbZcFtBQwNP2KCngSaAdpbWl/ulFbzTa pua0nKgrw3GKNKneRVcd9Xudrtq5vB6Mu8MtYc1Y6aqzNKa6ilIF6nZh/vq9i95467hbGivD zRkGXZxukTFOV5MCdth9B4afgQmqdbVzviWRkX6vm25gg4Cw6fymFA63krsyOJO3VXdyWbqT t5K7MjhTtlV3Slm6U7aSuzI4a2yr7hpl6a6xldyVwVlzW3XXLEt3za3krgzODrZVdwdl6e5g K7krg7PWtuquVZbuWlvJXRmcvdpW3b0qS3evtpK7nMtg/fab0XbwM19qN44wF9GFpDR8yv7E q+HluNuBX+kNilxqHxn7eEpd4c+3ods7H5VhTze+lyB5RzdgaCO7DoqbHfMMT+YdsLl3tWzb 7odvYpMCuT2BuNn/CTcgFNlUUGynQPHF/yLr+UUW6YusvBdZTi9jjbzAgje2Bk1Ya1kr0fji cJEKEpaIyVXbopVwREwup6ZWUmBRlVrnLMJP0montQBZpJqUZcj4ymAZlSWyhS/ZCemq2MId Yy2tkNpEVtR4i1wlVcxb6mKvPhWpNGENilwWKlKJ2OIQd72mxKpFqy2vSjkDt3K53Mqi1ZZX pZKBW6VcbhXRasurspGB20a53DZEqy2vymYGbpvlctsUrba8Kg8ycHtQLrcHotWWV2UrA7et crltiVZbXpWvMnD7qlxuX4lWW6RK3mQdNn+WEX2Fs2j8LH0Jk05PNBGGT2+tGRf6vAoOlPYg zB2ag4K3E/4FnpqubS0lI3rBOzGKTvcuNHO21FVTc417PYigWfyhwpO7+Vy3UfbuI+oQKZoh MV3wz3SRcqY0FBXv+Cg6wvSaOx8SUOHna4ck7MZkjku7RYiaRuOldKf3sKxtwM28Ju3gtdEo 6EOdj0e8w6KIpy6fJyA1gAsQDrmp0fXAqScEcSx1L89Zs9he+TrjRu2w8ImkHBzwyzaUWOuL zSHHhPosvIcKIgnTHu6yZeK3L5GDpo4GzBF+AVqw4GCAPsqsxSZ8o2sFEk6fo0Shz6TDZ4RT gmm9YF7h0VAIwWGAwDuku3ZtH8FVJ3aAX/YO8LeascRhyZX4qXn30DH25/BMcVApUAY9PZmM 6kCp02zHhnIS6YnScB2ycQWjUcZhwxSMcgthrPuCHHTfj+EYMQuDShMjiph4yMJaQ2FgQTMK nPUIdAkP/DK3rVVWSyWMMPEarECDITOE+aUWPQyKsu+XYJgnbmlp6JnGSt7RxTY6KZ1rzHpx 3tmGJ47vkEUhYTXhRwwjMj+KQsJ+MuJDhpi4CIbOsRe/paXAcfnP+AnknOdxw6UV8kIXRh+Z 92IX3popfQkd3qKOiIaANzT8LoN8C60pYSZ0KNpsZhdNwpZ5UZG6Ti1iep9gutyD/5BTQ+jg f3jzSkCbpC1BYDH7JK3hddyO5FqSqT+4Xuwr1a46+83d5Ds1/pt1sSHFehSSGDcmoNvVzZk6 w6PYhHsNKVyx6+7KlKW1LmIxmdeTcYspcBQf1vzLMZk2JqHFhZnTYTdTgRgDj5108w8aOQHi JXdhOBL4vyZ54yfJLy15oypp8km6N2z3TltKK226MExdmhm2PnWXn15w71LkjMiStxEQd0yc HDPDl6wXZfGH0Cn3SjJi9/Uzelqf6HpxbTN64i9SjbhboxXruL0IKuABzUOo/+wOB90+vOTq KA4KL8vAYHtwkmR4fTXuDtqn/W6CgdjzhLtvkoJCtgiAOeHlfOW7mvPRGy2H93l5Ze+N1SzR fhfaMnmSIknjb9tIzdy2YU883Ra7FouDGSZDSrw7Mjdy3Ta0JWgC5aO+Mz+a1l9mboH3Bu9A 1HIG/o7Gw2vU1si5noRLlmEWndVCbdjyXyl+36BvzckUHmI/60n3p3qTgL2LM9SkcF9l+h0h nUyb2W+a/pQKe5xi8m7BE71VikzZS4ev6TdMwfJ+UUZfn3IDLbMwLOZ4haz11Jrp0p8MDOhS dO+KXnQT+g66A72Um/uy3HxloB7U5yKQ32Ni+iJopAoy0tXq2zXU0P789L6ZzfeH+VVpfsoP H7lhH/n12xm1c5Wj3c4HEHG+7cUUnFJxyBOaEQKjTIiz5tEDZ9MQRXVPsJnM/uGH4f8w/DIN /8mN+Ed8+8OEq48RZBQj/AhRqwlRC1pQdv2XeKv5V9fvyz9GWz9MmTdXK2g7re/DeFo/jCez 8aTOTM6XX9nM5PxpIrd5wchtXmRqaP7VTw3NxcxdNO7zrVT5YaUbt9LvxNC+ntmYH6a2paYm VDrLmCJuwXj3TlrzTJ9DQ+Yk7YXCfCbBEnvS+mEefnXm9Tr+Q8Z+yPgbWSYXTgGSP6RASeHW udrV+/Nd8Cpa00f6jJQJ92kjuBGAg5VzIWUKUuZCKiSkzMfZoCBl9no6FKUfcT+JODk6RKbu 1YTq8LH7eH2MPq5kRpwcjOSij/oniS7NtVbGVJAuHjGklmiCBtf9fvzfJKL83qCo1vORG9Nv +Is+ZEKTbuuO7ibdtWJgO/TimyqctT415sZUQngiOHbXgfoneP/B5VXn8qw74vUkgZMwQv8Q eoidhI0aR/HuwAg9R9h6oSJ5kLIwpCIM2eBBPuJbnSbBsRe5f0Q89U6xKNRTBT1tUk8b6Olh n9iCBbv8evQCfyzHsKDHSqxK9LhB0he+nEc14GXmUQ0y/VhhQ2M1hC+89G4eejLFEkzZdETB yQw4eOiIhlMouCCvEg3X8OHOqQ9BYZCDjk3kIdaphKAsOmHKKAYoTeqh/5cBGlB7SFJQJ7Iw O/o8PGJ1NeriTQrfCTs5oorIqUVmdBEltcgtXaSRWsQiuPFCxYCdN0O8VLBh9fZOm/m7Ro/o knJiyWi7aaygkrvKhniVWNE1zudVrCjcHMupdI3zyS7J5nON85m9yoZ4lViOcAF9xis0BHRJ HNaMlc2jTiO/Og0BdTIqFFAll83c2jTyaRMLF1ov5OBga9s23MVKd0HIgKc+peIGfhQqkGYW RRmXV2r77CwdeCdlY1FmDNoM+M7ZreUVp8/yFWZqdH26Aaacu4kgU6s8TF1c9zfAFIhh1UmB srMCZW8LlK3KtM567zaghZlxzzYtyn9g2ZOf1of08gtFLuBEjIq9yCbYAm6kUraAH9kEW6BR VsoWaJibYAu0zGq1dXm2CWVZs4qZ6m2Gq2p11e7k5apRgCttWiVTwLkXDace8jt48ZgqF3NX cI7tejDegDGu4dzknelWzFnudkbuoyqPPSpiaUQRS8+c2vpKN93n8IDgrPKwpTfobEDvhllp cz3rboKpmV4pU4Pumw0wZYJhe5XhZac92ER4OdXMijjqXFz1N8DRdLVeVqkoyFZ3Q3zpVTO2 qf7hSZT2rTLXPh1tYrw9caqNnt9vYkygPVTKVG8TPn5lmBVralMtq3p1bYyzanU2uhyONzKI cyzbFZi7VIK1j9HCmLuSZs6koeVqrl75MGD0tnc+3kTc4kBOK+0nEGvDTbFmV89ae2O8aVUy N7zciEHaVrXmCNgaboYtW8gDYasnp4a7KU+0qQ7oqdzRRvl7Cp+0WQYrd0ybYu8pvNMGeavU Mk9748urDbjeieFa68oZK6y1VvnsUV1Lg+5a7ubzJcwPlqFPybVr5PTDuDvsbmLPAtzqZOv3 uXePBOVnBcvfFixfoekWUEyjUKOEfFXJVcHV3dx+VIQ18mBEpsmB9zlG9Q8VUdN9f9UeZN8b oD+sQURb0Ra10dn1JnoZZ3a3zu1mUOFZkcK3RQqn9ByNYFqkb92I7+SijUoS1mD/8k0v+wLi EhKXxgg2unpKZnr5uDGS2WkCvfT1e30pyTD1DGAD9OVX8CZuUbbIo1AZGtl5ni27sfPe2THA PbsOYHOpF8Hg7bxO9j/5RZNnp0oJooG7VIqJBmKoVjR5tg+XIBq4F7eYaNAu4kpFo/Ry7AAq QTYKirIKCQehqFQ6QDbK+QakAxhT5sWk46HgSIdy54rvzpUnd+d5dpSXYHxwS3kx24MYxITb 8IXbeHLhjv41HH9z0i0vjijUXxZYFJz7WzsLxxNP0G/m2NQbuwMqR6+nTYv2mwCDSPM8CIYY F/rKsj9J7elUdxxm02SUxaL69PJljn/7l+2zHKG9NqtoPD4aXw6z7xLDsj6UThGUUC+XiIwq ZdTLJ6SqaOq0O2+7FxfZ93hp04UeTFTx2lYraFtnmqtJF9a9Xnm7uLh8181xMuK+SivsXA5G uQxxCsRUMV3vcxOGz+xBsDKpu7rOHraEGXpLl9WbbnZq4Llulnyo9oH1H0/XRoB0e3nEa1Qn 314eAadMUmVNlFyFqP/n4ir7Jp0ot2MlzR4EvsNcrT5KTFgZXb3chBmVUZZj6ThKyFd+EPFh 1Gn3s09mEcntSqdqeJ691w2zqZVODcxllpmcKHta+Tobnqqjdo7AhMy6Vgldw27O0J1O21Y+ dd1hr93v/Z6DNjLrG7ODoP19SrY2IKbuWDg/m2tra/qCN/hMvden8Eq06Ao1eJkk/uYkyG8M n+XL3RiQGoCXlbExCmKYWRsRxWHKRpynzWVt9FMqYtdzJty9SlyZGgl4hylfhloCm/IDEEgE fuUdDUIIkfocS/U+fV9olCs8BpwkwpjBiFU1/TRd6hIHmARdazdwSlME1LBvqfzaiaBk6uwQ FApyT0IvYfLYla6ZDojlXN2279auI80MR5ss9Zm095LGGhlpKgFRC0wF5aUOTwCls4KzCFhO 1JXhOCRaNignGzrzUjpuUSIxu0DR0DukS0i/1003oE2tq9P5jSCoOFZZHKssjlURx6qIY22I Y22IY22KY22KYz0Qx3ogjrUljrUljvWVONZXPAcIfPe7i96ZhKa4gF8xMAfOvK10cH2hwhId tTsYD3vUnaVUL+GTc78yZlN0++eLexCqzGiKHymKgDMQJWXcP81ACEAsSgbZLQbdMTvweIwu DRfoUq/ab7oo0TSjW80XqETBigjlYf1H3ETkDJ/M7aG/CHXJ4pFNdoEykgunBZIMsbBTFMcU g4W8QCEIx3jYvlLfdTtgaMGmJZ+ZkFnJc3DEz2suyk2MhlycAIG8GVyAVpqXERJBDj5oCnKx AW+dGsEvpx/U37vDyxyM0ChysBKnIhcz495Fd6iia2PyMkOjyMFMnIrE/E1zHSaKT04soa3Z CSGgY9uRGtlHmFzjSxlqeskSsKz2IR3PpB0tlAbov9qdTnc0gjdlddX3oQgyZV6gsi4QaTCO PTQrfeXlSUC73R11qdckSEaTf4k7vFA9MeW7nw4giC1q1/364W5NovJwnJxIYOSyC8QPL20+ P8eTvGE5HdKRHIZI6o1QTiiJBhGS8zHIzRBD45zAoAhiUOo8DLIohhYHAzycgmNIpp4od5hc TsGET5STW4nlAl79ARE/oxrfQtC19VgOEmS5bFwogUcSLjxCibXs2BCuA4jfl5rsuu7WM80N x48Oq0IQh46Ab/rQ6Xfx+Rk0V7C/j02yQTDoyNRRv9fpet6sO4wacV365Zg/dI37I1hGlo7T y7Bj3CRfluCyE8fXMO4m4uTgK5knJwUH99VzSU70+9OlNf3I0lHC3NeaNUUbU/u6FHfL7qBK xo03j5JRk56+ZOS4iyiO+vH/AVBLAwQUAAIACACSkVoq1tQrnQwJAACoLAAAGgAAAHdvcmsv ZmNwdS96aXBzcmMvZmNwdWVtdS5j1Vp9b9tGD/8/QL4D6wdzbMdxbbcLumbJkLbOFjxtEqRJ 0T1ZIMjS2VYrS6pesqytv/tDnk7S6eXk2HWxzUBi+V7IH3kkj8fT48fbW48fw8nLi2sYzSNb D10fhr0+tW5vbW/9x3IMOzIZNILQtNzerCG3TQwPvycBb8YOfLYcBm+O32svLkfH/704Pz27 egs/UWf4l8ewH4LQj4wQtNGLi1fwZXsL8GPMdJ++73TbMg/ituvX+0/pm90bzAst15nrwUfs WwDN7ELngr4PqkifjFLKF1wyAA+RCsKcMX7GnnlTgnp7kEf0KbJCzhRpEk/84izvXMsEEl9j 80gzo7mnRXb/WQth95/BPbS3t2TZxtFkwvwbGAyfcRZxV+D5lhNOWqK7C40f+sP3jS7NFzjy I3jzooa/ZjJjAxii9THsP23FS1fiL32KUKgtcgJr6jATbNeZ0m/7tfunsu83azpLZYh/wiG0 cgPbLWghjKMjeDKENjShf38iPqlsnAvUTIW+aip91Dp89p7+UI8xuK7gtIZOJ7arhy0w3Whs s5XUqkQ32B+tu8L0w2fTQJuxe5zUAnIJ8Lrxovvj5IFJOHmLJfv1hxTdB9R9X3RNXL8FFjb4 4wP8/hkfGD7s7hItGvAl03wCuXHZyK2Iyida5BRtKzc2pQH1NMimvb0jiiF7Ryj8DYK7VVAS pLIua0K29AF+gCdoSYeHMEykKU3+w8nj+LC7K34t6hckjZHJckjKJ/4p+HQgPDoky66QQDdC 645lYTd4LsNSUGvyHUQbvX85urg6PT/TLkdvR1eV9OmHzwIWrkP2t+PXaqoz3V6L6OnZu+PX p6/w++3V5fVLalPysBy+R1lOvNcgvXU4Xhz/Ojo5vq6RxdOnbKJH6wl0cXl+NeJyLGHiuyHj QqzNChX369mb0dlVPSfU2dSZM2xYl9Gr03enb+nhxe/a/0aX50pWJruzAiQx/usz8911WF2d vhldai/Pr8+u6lmF1pz5hhs5ocyqxlEr3HNJdMXA2u/C/pNUiFrn9zIAfG9IBxszZnzUxj7T P3ouEtZiL6/Ak99qrTSUpbG5z0NzMXFShWmhc55rYdDsce+RFfolHwuVayQTyaWExWgax5cw 8h0YSLF0kQbS+EEM6dfpi35RUGHmw+Pq0pAlYatGkjcdds8Mbepqhjuf604VkD9nls1oj3m0 fLlxHqUzzZzKyjNlwWmK+LRlOfgU/me7xsdUF9LuV2H+nspDuJhByLwaQes4ZsnYylz5ZvQQ tnzgxtjSOE65nvEqJDFRNDWkpelBwOaYLRaJd3nK2AEv+DwpMtKDeTZvwk0qHpYw5IlbynCK OsNIZeGa+ZpVxcEvZoBGX04BjYF81GK+n9oNeRbnE4W2ZjNnGs40d4LWgbF32hKkMQQNK9yq n6PSgg4fjcnOzuUOt/xcm7+Tt+kSEYQl5adGH3+kyAzXuWN+qJnW1Aq1kFwUswKdonZHoNyF AbS7MMAQ3iRS8k7Ef2esOe08+ozKMIMpxcs8OE5ksDLAYSVABciURz+X4iYhrQ8dkmM3W1sR dZkdsNJwQxHxyLI83dfnZF/aGG3M0VilDYtTBz4n5w56ZBUnJJR1fPO0eLjHVha3Sn5Ampuz OXf1Jp+HifIt34YD6zNzUSvUSityUAjAZFieyKwzU+MtO3s75bbuTuW6pjB0z0PBNYJLy5c4 QCcWXQanQMYzFhwsnyOK3uHRmSSG8vVrrm2v4B0ppRptsUptsX+GtlhZW2wFbaX6Ju2koFO6 SWsZYgfts+CpHbLTQ0zsyo5S4vZoLW7qSJ2zHVHdeHJyUEZHlFSOvAGGJX5LKbBKCov6TTZO qDELYlPmV0WR4j5FIWpcqEL6rJzWKAMVUhdGR3GpSUamTopK+T7NEVOWi8WLQ1qAlm6zJbLx oTyT9wrClRqqxZcbrE2p428u+WQ9Lga9cpVHZsNH4M7Z4prsUI0wPS1xjbebOGQXnhZiSmU5 rxXX89pENQ8kg/i8UJf6J4ONT785oIuHG3BMf4kBiwrov9eAV1+1plrh373uKdY+WfP1V5z0 ylc9CjCcq887PC0T3Tcw2M9fxvCVYWH+0gCh4D8juwpI0R3J/o06p4ucXOJaTl9S1sUMRnRI nlKenMIrThYdYrKAbdBtBeqFJGuVMiPqxk1/dH6SbPuiZecPZ6fYBOulRS1qaCORblHwKqml 0FONfbGuCIeJCFXFo4ewWsbp21STX9aqNX2IauQsUjqezZEOE2wxQymZYGPGbK/BSzZfv2Zs VqTREKWbb6DxywZoNJISUt3Ort/plq1TlBez87cPtbclaQdprQu4er9Qc6/Xi7uA2pWTpm4X pukhlyb5kUMV8ikuNUROaNn8ggEUpf8cMSpkobVIxOIMDagDXIc9iAqvN2EuKEGiFkClK+dQ mOvCJ4kzD3xMXO0r54lqVBdMQ8yjFmKFmPWQKSdSzUkP5l2wdTGRWoACR1JNAqom9YDd63PP Zs9p5M/U5KAPHakR+ZEFuQXhiJJjQYDks2I1ps89ECn+czB98H/c8wc/1hCfBMuIiyXDo4nB LxTiBJqo41y/v+cP+3X0zWX0RTpTRd8EfzBEAfZlBuUj4iruN3XLgWQNL542VD6srlh7GxKB nGcjQgQNdSiqq0hvShDuxhuRxK+LqrVl7k3JQuFlI6J8qlmULH8bbAS0iHYbwW0aDXjwIpSK /ptaBhGGNyKRra8gUc2dg1fIn5SirqRu3BYaD9R0ofLznfBMgtXw5Es23wuUuQ6o5BheB6pw zkp2KPVZXz71BRXHvvzhTErtHyU97Qr8ikOl8oIMkz/bbQFvlHgnYnRqP/I2nE2Bmo9qyske vY/4zvLDSLfhjW7M6IXJd8NeHzbHZXVZat5dsBwrfcuLmV3xRmV8A7r0rQGcIW5LD5NXML/p dQJOr/AyQWY3ixxbyagysea65bR42UD3p0ZSaMLnu5tbSR7x1ihkb42S/NwfzXLhKLatihpv rLsmqa2puDKWLpab+etzcnoCCUd0i6g+M+E5xcFAANWpKBdtcKs6QmXuK1/7qS6EU2LFS0F1 8ofCV4U0VUQqBItk9uL/UEsDBBQAAgAIAJaRWipt5vBmIwEAAJAEAAAaAAAAd29yay9mY3B1 L3ppcHNyYy9mY3B1bWVtLmPdklFLwzAQx98L/Q5/JkJLpyiICGv3IhMEh6LsQUVC26RbYEtH 2gpD+91Nsq5r3abOF8HAcdyFu9/9LzngIp4WlKGTxHPlk+x40rEt2ypExseCUcSTUEJfkhmb aUvl4hlXl3cjMhwMtd3eP5KH66cBXnpfVI5ZTqJFzhyMbs7PEMK1rTfbgjqS5YUUm5AQh7tB pWa9ppyu6+ZFG9FFexbaYO4BQwC6AprGLU3CIDMybWCNFw2aSegmdcDNrnRIVf+TOkpS6YCb lHI+hHKep1vp26rdssz3A1z0mpn3ANsWHsJT0xzhVBmHW5WUK2S1/h9ojP6Nxs2Ps/sdK08/ a+UVZE9RW76rHp534bS+q0trGUvl/f56F+W3OqI/0lE/wq/0fABQSwMEFAACAAgAmZFaKvBz aU4kBgAAAh0AABoAAAB3b3JrL2ZjcHUvemlwc3JjL2ZjcHV1dGwuY91ZS2/jNhC+B/B/YLJt LMlxIqdBgMKrADn05vayyKUXQZEom4gsCZK86yZIf3uHL5mkKFkOspca2HU0IufxzcfhkP5C 8jjbJRhd1E2SkefrzcXk7EsrTOMSvtOaiSdnNzeHf5Oz7wVJEB0R7posTCuMHURlnodK5E7O 3iZnCD4kdZDHBEh8+FAqW1I9VAQPAfrrabUCybtU7h20b6MsK2IHPa3u71BNXrFhgIke0MK/ vVshz/hWTFe42VW5tMTlQiZNOLu8JuscJygr8rXLjaluKV7hbY0bETUqr1C8iSqUXAk3FR9b nXSEh1C5i1v78DcE7+hD3HLJ3/7YkAzQqiE6X0bydgjI47OTVpvQOJstD8/1fL6Uf3Ppu4hH zyhzv41uV5a4CuOoBvPsTbwxUKdy9BCgaTRFLrq85IKvIHilgq63Nzfo8du3pz//YFMe0PRx 2smNQ225Qvlc6J7RoSwNwnstdfFG5ocB30aQ4XzdbMIiDeumIvnaEfCX9asSCZtDWgAJwOm3 TwJ+T0wx4gGpBjRpn0wXyTgPw+ddmuLK7qhQNRAeGw9gLex8jTMcVV0sBF+3iikR9tbKODCi QmQDYguM05mmc4vUId6WzT+DiaEU81EQaOgrQCw6a9hf2QOPgMp5ElIjYVNoRuG/q0EoTHqk FBZwyu961B20GAawM50hxlapTkaTiueBtRqM4CN1jaCviDo4p/7ZPORMmlEb4ABbXp13C/bO N9JsEK4oLSmWBXKbKMjXRyBPRmGeDIGeDKI+ADkHvRao80InMEwkiAM22WRzuSRaouiI/swd 6rYahmVZxRscv8hSQmBDSbB8ipqwLOqQKHnwFfgXIicwxkxEJtHgT4slUgiawQI9UpH8tm5n i6ODF0pTQDMKUx6oke7q91faQOo4bEXHhjJ/ZgEdbtZ4nmVfy7LHXBKSboapYet+yTW5dGbv e2Xt9fsrfTbZsrCvbK7XvlIG6+VoHvUSqH/9pkXliGXFls1xulD6H4N7FNe5k5zfpBdvBoxt 1+7Fp9iWUSXt1aNA+R+xTFoOOjEEWgwjuac3oXqDFBf5d1w1YULWpKF7NwjqJsobsXszuahd zxB0Cz6uKpORe71giBGHak0FgVlXHG6Ctbl+2+ZyGe10f7d3unva0lOrrhw85/P1qo6zGnfM PFrM/H2CGZgP27M/ylZksfV6gq2o35aVxybqKvILnZAqTzoU3FPvacJ71stn2BEv9vbWXTKT 5A1eY9lWdykq+sp+WlJol/pzbDzTQIWIsR4+OV4bElDdxsWQgQ8EK3dvmIC4yB+3DpbmxqLt K5+Kt0ZPrcM87zfpGH2qtkD1NhVe7ad6XXrTfWWAgav3S13OlAToVhG/W/oyFaLpL1OLxzYD arv+bkN7+uuAqtuTNM2GnPJPUjUfq4pRLmCn0UHtSuHlhQbpdVjbOmWGzxnjeuoU88ZTKj5b KGr3ObCxeGzB8t3kkllZ6tr3wKu49/yrgaYsi59UCSnIrlGl0b/79h7AXsuG+r06TLMCeihL HTNO5yMbRobnxfXFyZ2BveJy7z5Sb5Ni95xBYUwTgSRTRb9ro+KmxBBkxjNRqq8n2iejINOr Q3Z2Fqefo4eflmjs5AOd8t1HuaPf9g1yiHtJj6myZGb8TLtUmyAxCsrxNG2LrCJMpr2t62cR /fzDbPsJDvH+l19Wem7nnjrT4ONtuvClmxrzfOS0GVDPQfoFDBxi2YFGSRvR6tRhmFDWubNL 6UVC1BSpckpX3uoX+w6/2XcvtQN9p9tr9frXB2NpTZFiS81NE62tkOQTtFKUEKXbhFjgz99u wTzoclvzht3ulPs7OiURU/RbVDJcZD7czu3VKqD2ZHvb9tNfy5gZbfvp30+sqoca065yiwFV u7/s6XrK/h1uaJkpVvUsmi3oYEfe/UFK+c1ojZswx/smxBne4ryhxTYj+QtO4Ks+/GzDEtjG JEx4kvDl4I0ygNpVCTrLqijgWCos5PiHbkTItaVw7vFZ1otE/iZgqkactEp268gmKUCLNqoc aIOpI/THMboixwNZdu8YDL28IklI9UC0NrzC0Yshf1fLkozuJOeszTtTOzn7D1BLAwQUAAIA CABkP1sqxF8hqEcAAABHAQAAGQAAAHdvcmsvZmNwdS96aXBzcmMvdGVzdC5hc23jzMlPTEnO zyvWM+DkVMpQ0lEoMjPm5eIsrixOTszJ4eTkNKhwAwKguAFQGEV1Kkmqc2ioOp8U1YbGpCg2 IKA4IzGnhJcLAFBLAwQUAAIACABhkFoqXOI0nzAGAACyDwAAGwAAAHdvcmsvZmNwdS96aXBz cmMvcmVhZG1lLnR4dLVX627bNhT+bQN5hwP9aTM4mu20zRrsgrR20gxGnDhu0WEYAlqibQ2S 6JBULu+1B9x3SMmWbG/BNkxBUYk81+9cff7x+jMd0TArUmGVpi/9sHvQPtrzHLQP2q97h3Qh c6lFyp/TpSRZcSa5sbqIbKJyMtKSyOPykk8SQzNhZEx4t2DLRF6IlL50w3540L5OJS4pV1ae smDC8w2N1ELoxC6zJIJ0KxdSGxLa0VGSrVKZSRzHFf34+m5w+YUila0KKw3pHv1Auk/fkj52 5kkB/fPy/JjPWblnvp3cfZ6M2M6a9AzSQzqLImkMRaIwkCroejKeDj9OL8dX52efR9ODdsvp Pr88u5587bjX25vJdPM1Gl/4l+HX67UDplitlGYFFZQwHLDEaZJLMs+5FU8wZ43HPFoV9Ct9 P09SmYtM/ki/8dU5oJdPgu1tUAIAGwqT8aHS9St+v5xzFGBJwg5VIimWcyiPAZYLUs2gjjtY BztVIjYHbbsEP3N3SBgjs1kKgBIfe9DnsExGLhaCgoUKKokhTZnTI8pi5Jo/dvLIKprJij2m IrdJCiGfzkbTRqZBipYiWjoYx7knaJhqpc6SXMCIcNvzXO11kTirkGqxnBWLRZIvKFOxrJzS wJljaOQD10ElAS4+iCQVcMGF7KC9lOmqQ8sO/cTIh2FIK400Jj7n+4Xq0IKqh+91kYNGLbTI So+XIrV1f5kPeQy5psZnYCMw4wvUl9xm0BL12CFdU8QnVObCfZHg9r4mj0/WADJJXGQrUHco jkoSPmEBUApomYZTAvnWoVSUNHziUKti60K7TujmA66gytnA6dRFQg14nE4tF4lx4REGIJlk wQm7lE9h1SPCfeJvJbJbz5FdSAmRVyUTek1z85KmEuKVllFiOPHm8M6e/gtV8UuqYlXM9qra pyzW8bz2xcJEmm4E7ueBEbrXP9K9dy1mMTUDcM7Fhyv0NTwVeb+uoiLHsc/11/1DukKnf5B0 +8vtx7PR6A+zMyHKjmdcnc1VmqpHLq4gd4wBep6JYLwJS1EH7UyK3HBdCstMRq5pXBtFrXBn Rvxnz+SloBxRqn7IoASVsRg10RLlzT2HJaztA9CuEf/OHsFlQecYhkcsACOlJEMFoju4pPJ/ 3adzPBiZrpi9L9FSaBExHmXjHN1+4EEzeXeMT5QIQmorODaOO1NLMa/QFVL1iu3w5C7e15PL q+mn4Wg0xmeL6ylSuQm7rWAZoKDfHeO0RKTV8pbhuLtFK/8Bbfo/0aoXaLnRNSAeAmJ0du6r NXznWmUMEHAGbKoGdMWMXDw+5FAjVbKZSrE7VO1H72QkrLMC3RI6dqnXIZ/WxlMti9HrJSfr yP3vElKkj+K5zO9EI/ek31EwgufQ4Sa724vw7xGbDQWnQUi1Ee6i/jMS8hPmzCltEKReZ11s f2lRs67iBB2Ea8KcVnzDG172/JTfON2wwE0Yd0xM3X3qdbvdSmfgbwIentWu4Ce1pwsJ47VO VBi/TQgMosbYtn5yr1IR+fJNYP+DSIu1qMrm8eSiZrOL+uMyiZYkZkal2A5IxLHmBa3pvlpx fbm4YGCvtwurdgFnFdB6dt71Y6yE3PsB3Htr/ze3wfYagp3TW4e1UelnQsuqDKtk+7+z0eXF FVwSKWaXt3rblZ2IlBbiqfjf7De1/99N7fXeVKYOPjTSZfYME3mooQQ1Y/zayPtC5pHkIuRb c7hjejyD0Pfv3Uvg1j63c3oJbtIPBg0t5fxzypA6aWItPlEyCYap0rGrzMFgxB3C8NaKmTkY uLMPw7+TNEsW22LAdNNguS9E/JLqm6bqG3e2pbohZ7/icYNBRfYlveOm3rE729JbF7NX7Xbz EPhxs9rpHZw4VmAwoZ0a7DPzIvfZwz8g7gqb3oEC+6+983G8s+qu4nF7TyzRWFNzyApb5ZIW Y6HJROpKrtU64mHQevvWfdUXOVHS0WvCz8LYrQjdp4AOS0YeD9Vbl5+Tk5NSjdvR3LoEZqth geOeg9lz9MKTk++G/bn7KtNjlz6u0ff7x7HHbbJZ0rTfM8omLjZ26oDrI5gEbtvY7El5kc14 /iD15dMKbXndOEUFS0nTcfDVu1OL+09LHzNeGKF/AlBLAQIUABQAAgAIAHI7Wyo9t312khEA AMg+AAAbAAAAAAAAAAEAIAC2gQAAAAB3b3JrL2ZjcHUvemlwc3JjL2ZjcHVkZWZzLmhQSwEC FAAUAAIACADqMVsq3RNRa7seAABtqQEAGgAAAAAAAAABACAAtoHLEQAAd29yay9mY3B1L3pp cHNyYy9mY3B1YXNtLmNQSwECFAAUAAIACAA8PVsqlqg2gH0jAAAqVwEAGgAAAAAAAAABACAA toG+MAAAd29yay9mY3B1L3ppcHNyYy9mY3B1Y3B1LmNQSwECFAAUAAIACACSkVoq1tQrnQwJ AACoLAAAGgAAAAAAAAABACAAtoFzVAAAd29yay9mY3B1L3ppcHNyYy9mY3B1ZW11LmNQSwEC FAAUAAIACACWkVoqbebwZiMBAACQBAAAGgAAAAAAAAABACAAtoG3XQAAd29yay9mY3B1L3pp cHNyYy9mY3B1bWVtLmNQSwECFAAUAAIACACZkVoq8HNpTiQGAAACHQAAGgAAAAAAAAABACAA toESXwAAd29yay9mY3B1L3ppcHNyYy9mY3B1dXRsLmNQSwECFAAUAAIACABkP1sqxF8hqEcA AABHAQAAGQAAAAAAAAABACAAtoFuZQAAd29yay9mY3B1L3ppcHNyYy90ZXN0LmFzbVBLAQIU ABQAAgAIAGGQWipc4jSfMAYAALIPAAAbAAAAAAAAAAEAIAC2gexlAAB3b3JrL2ZjcHUvemlw c3JjL3JlYWRtZS50eHRQSwUGAAAAAAgACABBAgAAVWwAAAAA --part1_23.7f7fac1.27ccab9d_boundary-- From Carsten899@aol.com Tue Feb 27 08:25:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00302 for ; Tue, 27 Feb 2001 16:19:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:20 +0100 (MET) Received: (qmail 23519 invoked by uid 0); 27 Feb 2001 07:25:25 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx16) with SMTP; 27 Feb 2001 07:25:25 -0000 X-eGroups-Return: sentto-1101623-2439-983258724-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 27 Feb 2001 07:25:24 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 07:25:24 -0000 Received: (qmail 36374 invoked from network); 27 Feb 2001 07:25:23 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 27 Feb 2001 07:25:23 -0000 Received: from unknown (HELO imo-d06.mx.aol.com) (205.188.157.38) by mta1 with SMTP; 27 Feb 2001 07:25:23 -0000 Received: from Carsten899@aol.com by imo-d06.mx.aol.com (mail_out_v29.5.) id r.7c.1227736f (1813) for ; Tue, 27 Feb 2001 02:25:16 -0500 (EST) Message-ID: <7c.1227736f.27ccb05c@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 02:25:16 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] New FCPU (64Bit) Emulator version 2.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f27eaf8613c01cf44ba431bd50f3c6ba Status: R X-Status: N The sourcecode is also available at:

http://members.aol.com/carsten899/f-cpu/index.htm

Hopefully anybody out there starts programming F-CPU assembler someday :-)
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carsten899@aol.com Tue Feb 27 12:43:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00341 for ; Tue, 27 Feb 2001 16:19:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:34 +0100 (MET) Received: (qmail 17978 invoked by uid 0); 27 Feb 2001 11:43:14 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx22) with SMTP; 27 Feb 2001 11:43:14 -0000 X-eGroups-Return: sentto-1101623-2440-983274192-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 27 Feb 2001 11:43:13 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 11:43:12 -0000 Received: (qmail 17982 invoked from network); 27 Feb 2001 11:43:12 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 27 Feb 2001 11:43:12 -0000 Received: from unknown (HELO imo-m06.mx.aol.com) (64.12.136.161) by mta1 with SMTP; 27 Feb 2001 11:43:11 -0000 Received: from Carsten899@aol.com by imo-m06.mx.aol.com (mail_out_v29.5.) id r.92.10e6c381 (18253) for ; Tue, 27 Feb 2001 06:43:08 -0500 (EST) Message-ID: <92.10e6c381.27cceccb@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 06:43:07 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: ARM and data/instruction dependancies Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 3ad27c78d60a5916cea4eefcb63e3a2c Status: R X-Status: N This is my version of "GCD" in F-CPU assembler. ( it requires an updated
version of the emulator to run, because the current version assembles JMPA
wrong - new version coming soon).

I see two ways to code it:

* The jump method (which is shown here).
* A method based on CMPL and AND of compare result. Need to think about.

;int gcd(int a, int b)
;{
;        while (a!=b)
;        {
;        if( a>b )
;            a = a - b;
;        else
;            b = b -a ;
;        }
;        return a;
;}
;
;gcd  cmp  r0, r1
;     beq  end
;     blt  less
;     sub  r0, r0, r1
;     b    gcd
;less
;     sub  r1, r1, r0
;     b    gcd
;end
;
; r1 = a
; r2 = b
;
    loadconsx.0 1, r1
    loadconsx.0 2, r2

    loadcons.0  getdd0_GCD_EXIT, r63
    loadcons.1  getdd1_GCD_EXIT, r63
    loadcons.2  getdd2_GCD_EXIT, r63
    loadcons.3  getdd3_GCD_EXIT, r63

    loadcons.0  getdd0_GCD_LESS, r62
    loadcons.1  getdd1_GCD_LESS, r62
    loadcons.2  getdd2_GCD_LESS, r62
    loadcons.3  getdd3_GCD_LESS, r62

    loadcons.0  getdd0_GCD, r61
    loadcons.1  getdd1_GCD, r61
    loadcons.2  getdd2_GCD, r61
    loadcons.3  getdd3_GCD, r61
GCD:
    jmpa        r61

    xor         r1, r2, r3
    cmpl        r1, r2, r4
    jmpa.ifnnul r3, r63, r0
    jmpa.ifnnul r4, r62, r0
    sub         r2, r1, r1
    jmpa        r61
GCD_LESS:
    sub         r1, r2, r2
    jmpa        r61
GCD_EXIT:
    halt
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Feb 27 12:49:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00344 for ; Tue, 27 Feb 2001 16:19:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:35 +0100 (MET) Received: (qmail 27128 invoked by uid 0); 27 Feb 2001 11:55:53 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx08) with SMTP; 27 Feb 2001 11:55:53 -0000 X-eGroups-Return: sentto-1101623-2441-983274952-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c9.egroups.com with NNFMP; 27 Feb 2001 11:55:52 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 11:55:52 -0000 Received: (qmail 42267 invoked from network); 27 Feb 2001 11:55:51 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Feb 2001 11:55:51 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 27 Feb 2001 12:56:56 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA05462; Tue, 27 Feb 2001 03:55:49 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR707W; Tue, 27 Feb 2001 12:01:07 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9B9431.913A2443@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 12:49:05 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e06a65a8b9c0579badbbb40f41cd8d67 Status: R X-Status: N hello,

Nicolas wrote:
> Yann Guidon a =E9crit :
> > Nicolas wrote:
> > > Michael Riepe a =E9crit :
> > > > On Sat, Feb 24, 2001 at 02:38:46PM +0100, Nicolas wrote= :
> > > > > So we should protect fcpu design with the LGPL (as= LEON) to prevent the
> > > > > steal of the code and Lgpl because in SOC (system = on chip) design, some
> > > > > people would like to use the fcpu with other propr= ietary core (MPEG,
> > > > > DSP, io controler...) and if the code are GPL, the= y can't do that !
> > > > If they add their own intellectual property and release= the combination
> > > > of their IP and the F-CPU under the terms of the GPL, t= hey can.  We
> > > > want free hardware, don't we?  We want the `Genera= l Public Virus' to
> > > > infect the hardware world.  Why should we allow pe= ople to use our work
> > > > without giving anything back in turn?  If they rea= lly want the F-CPU
> > > > code, they can as well pay for it (one way or another).=
> > > If we do that we could lost many "client".
> > We are not a company. We don't have "clients". it's pro= bably a biased point of
> > view, but it's not a matter of "commerce" (i think you = know it).
> > maybe a better word would be "adopter".
> You play apon words ! Our client "are" the user of our desig= n which take
> market part as usual product !
so what ? what is the pertinence ?
All the files are already under GPL. it's too late if you want to change the licence. i don't think that the people who have contributed would
like to change the licence.

Because the ESA uses LGPL doesn't mean that we must do the same.
LGPL is called by the FSF "Lesser GPL", or "weak" GPL.<= BR> this should ring a bell.

> > > I follow the Leon project. It was design for SOC.
> > f-cpu is not designed for "SoC" because this term has n= ot
> > even reached the "conumer" audience.
> > However f-cpu is not incompatible with "SoC" in spirit.=
> > it was simply not the primary intent : it is not even mentioned > > in the f-cpu goals.
> Never Mind !
if you don't mind... so what ?

> It will be 90% of the use of the chip !
90% of what ? "market share" ? "designs" ? users ? deve= lopment efforts ?
i don't have time to play on the words currently but you know that there is a difference between the success of an architecture, the number of
fabbed chips, the number of implementors, the number of end users...

best example is of course Intel : 1 shitty arch, 1 fab, millions of buyers.=
that's why i think that this discussion doesn't get to an interesting point= ...
On one side, you say : "lighten the licence otherwise nobody will foll= ow us",
OTOH you're scared by the idea that the architecture gets vampirized by a big iron company. it sounds like you want to go both directions at once.
let's forget a bit about the others and concentrate on the "real thing= "...
F-CPU is reinterpreted by everybody who discovers it, best example is
the latest emulator update. is it bad or is it good ? it's (simply) life. F-CPU is alive simply because some people work on it.

> > > So having a too much
> > > restrictive licence can limite the use of the fcpu (never fo= rget that
> > > GPL work well because you can sell GPL product). We want a w= ell
> > > developped one. If our "client" can't use fcpu, th= ey will use Sparc,
> > > Mips or Arm core (or more specific core as ARC...).
> >
> > i think that you undersee the problem. It's not a matter of licen= ce.
> > What would be the problem if a company integrates a free f-cpu co= re
> > in a "SoC" ? i see none. there are Emacs versions runni= ng under Windows,
> > and RMS doesn't complain (afaik). Similarly, what are the trouble= s
> > and what is the difference if the "core" is on the same= chip and not on the
> > same "system" (out of the chip, ie on the PCB). to the = user, there is
> > no difference, and there is no problem if you interface a "f= ree" SW
> > with Windows, or if you interface a "free" core with a = unknown I/O or
> > CPU (ie: who cares if the SRAM design for the cache is proprietar= y ?
> > only the implementor cares).
> >
> > The problem is with the F-CPU sources : what you have to and can = do
> > with them. and there is no ambiguity. what you do with the
> > result of the compilation is up to you : paperwall or chairs, if = you like.
>
> In the opposite, i see a very big problem. ESA lawyer choose LGPL
> because of that.
lawyers are lawyers, not technicians and they don't have the same point of = view.

ESA's stakes are not the same as ours. For the ESA, the LEON is a "mea= ns",
a way to cut costs. For us, and for me particularly, the f-cpu is a "g= oal".
Hence the difference of point of view. Forget your SoC hype for a while
and start to learn Alpha asm...

> And RMS created the LGPL because of that ;p
if he's listening to us (or spying, or whatever), maybe he should
jump in the discussion and dissipate this trouble. thanks in advance.

> There is a
> very (very) big difference between 2 binaries running on the same syst= em
> and "2 parts" that should be compiled in the same time.
what is a "system" ? what is "compilation" ? You know t= hat today, the tools
allow a very wide range of operations from the simple cut'n'paste of "= IP obscure blocks"
to the resynthesis of the whole chip. what matters most at our level is
the preservation of the ISA coherency and transparency.
The source code and the manuals are our current means to achieve that.
it's under GPL, that's ok. That's all what matters for us and for the
people who will implement it.

we have touched the difference between HW and SW. the notions of "libr= ary"
and "compiler", "derived work" and "work that uses= the F-CPU" are
very different and few in common.

> LGPL was created
> to permit the use of library on propritary application. But you always=
> could run proprietary program on GPL Linux !
so the notion of "system" and compilation is rather fuzzy, partic= ularly in
our present case. what is a "system" ? a chip ? a zone on the chi= p ?
a software bundle ? a PCB ? what ?

> So you could NOT mixed our GPL vhdl code and proprietary VHDL code. We=
> should use LGPL to permit that (and protecte the fcpu code itself).
when you insert a f-cpu core into a "system" (whatever it is), it= 's always a "mix".
what matters today is the integrity of the core, whatever is connected
around it. I think it would be very difficult to stand a case with this
problem, while it is clear that the f-cpu sources can be protected.

> > > > > But the isa definition should be protect by the gp= l, too. Whygee want a
> > > > > total freedom but if the different core are to muc= h different, it will
> > > > > never survive with the time.
> > > > I agree with that.  The ISA must not be in the pub= lic domain.
> > > 2 agree ! Some more ?
> > the ISA is not public domain. it is covered by our author's right= s.
> > however the specialists can always find ways to bypass some parts= .
> The GPL is a copyright.
as such, it does only protect the "form" and not the "backgr= ound",
it protects the expression and not the idea. the ISA is an "idea"= ,
otherwise AMD and others wouldn't be allowed to make clones...
go browse at the GNU site.
That is why we have no means to kee people from reusing
the F-CPU ISA. it's a risk but life is risky too...

> > > > A while ago, I wrote some rules about modifications to = the instruction set.
> > > > Please refer to the mailing list archive (or your local= copy, if you have one).
> > > I remember that it was very strict.
> > it is our right... look at the industry licences ;-)
> I know we could make what we want. But i think that we want that fcpu<= BR> > should be used by few people...
but what do you want in the end ? both quantity and quality ?
please start with quality. if you want to attract too many people
with a "gratis core", the project will suffer from a sudden growt= h and it
will explode/blow away. Long ago, we were concerned by the patent problems,=
we didn't care in the end because we would loose a lot of time and
do nothing at all. Now the licence problem arises again but it's a bit late= ...
the GPL was chosen from the start and i doubt it will change,
now the real question is its interpretation in the frame of the electronics= world.
If we can't use the GPL, then the LGPL is void too.

> > > You would like to restrain the
> > > modification to the ISA but it's far more restrictive than G= PL (no rules
> > > of how the next version should work are describe !). If the = licence is
> > > to restrictive, you will limit the use of the core.
> > not necessarily.
> > a lot of people use existing cores and don't want to modify the I= SA.
> > however, we leave to possibility to "adapt" it, under c= ertain conditions
> > that are meant to keep the implemented cores coherent. if someone= breaks
> > the coherency of the architecture, he will be banned (that's all)= .
> ???? If intel take the fcpu ISA and make it's owne core with few key > proprietary feature. Then because of its marketing power and this
> specific feature, it will kill all other concurent (other chip maker).=
> So usual fcpu ISA will be "owne" by intel. That's a very big= risk !
this risk is even higher if you use the LGPL.
http://www.gnu.= org/philosophy/license-list.html says :
  The GNU Lesser General Public License, or GNU LGPL for short.
      This is a free software license, but not a s= trong copyleft license,
      because it permits linking with non-free mod= ules. It is compatible
      with the GNU GPL. We recommend it for specia= l circumstances only.
These circumstances are explained at http://www.gnu.org/philosophy/why-not-lgpl.html but only apply in the frame of software.

The F-CPU is not a "library". it should be considered as a "= program".
a library would be an execution unit. in this case, yes, you'll have to mak= e
you new execution unit available under GPL. that's all.

F-CPU core is a "program" that communicates to the outside with t= he memory
interface, therefore there is no risk for the inside of the core when it is=
respectfully integrated in another product.

> > > >  Michael "Tired" Riepe <Michael.Riepe= @stud.uni-hannover.de>
> > > nicO
> > WHYGEE
>
> rares@moonbase.res.wpi.net a =E9crit :
> > Why not just allow forks of the project?
> More often a fork just kill a project. And our project is big and
> complex, so very fragile. And here the problem is to stole our work. Sure the project is fragile. however it is called "freedom" and i= f
someone has a very brilliant idea, he should not be kept from trying
it. Al has even tried to start a new project. whether is succeeds
or not is another story, but forks can't be avoided at one point
or another.

however when it comes to "steal the work", i wonder how it could = happen.
this work is "free" in itself so if a problem arises, it's FSF's = lawyers' problem.

"design and let design".

> nicO
>
> PS: Whygee, have you lost my little exercise about a piece of asm arm<= BR> > code ?
i haven't lost it, it is at home and i'm at work (though i could
easily browse to the online archive). on top of that, it's a rather heavy t= ask
to perform and i don't have time yet to do this exercise. i'm lame, i know.= ..

however i should practice more asm, or i'll forget the old tricks soon...
have fun,
YG

speaking for himself
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Tue Feb 27 13:01:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00347 for ; Tue, 27 Feb 2001 16:19:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:37 +0100 (MET) Received: (qmail 7081 invoked by uid 0); 27 Feb 2001 12:01:44 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx08) with SMTP; 27 Feb 2001 12:01:44 -0000 X-eGroups-Return: sentto-1101623-2442-983275303-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 27 Feb 2001 12:01:43 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 12:01:42 -0000 Received: (qmail 75192 invoked from network); 27 Feb 2001 12:01:42 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 27 Feb 2001 12:01:42 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta3 with SMTP; 27 Feb 2001 13:02:46 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id GAA00903 for ; Tue, 27 Feb 2001 06:59:13 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id HAA23174 for ; Tue, 27 Feb 2001 07:01:40 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Tue, 27 Feb 2001 12:01:40 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EB03@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 12:01:39 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Asynchronous 40-bit TTL CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 676a799edca8ae6c26b734b9730a8d4e Status: R X-Status: N
Hi

I mentioned before about my design for a CPU made in TTL, I've now scanned
my notes. See http://www.hanssummers.com/computers/ttlcpu/intro.htm for
amusement...

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Feb 27 13:03:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00350 for ; Tue, 27 Feb 2001 16:19:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:38 +0100 (MET) Received: (qmail 14068 invoked by uid 0); 27 Feb 2001 12:10:23 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx14) with SMTP; 27 Feb 2001 12:10:23 -0000 X-eGroups-Return: sentto-1101623-2443-983275822-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fk.egroups.com with NNFMP; 27 Feb 2001 12:10:22 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 12:10:21 -0000 Received: (qmail 45315 invoked from network); 27 Feb 2001 12:10:21 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 27 Feb 2001 12:10:21 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 27 Feb 2001 13:11:25 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA06792; Tue, 27 Feb 2001 04:10:18 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR708F; Tue, 27 Feb 2001 12:15:36 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9B9796.CAB058DB@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <7c.1227736f.27ccb05c@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 13:03:34 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] New FCPU (64Bit) Emulator version 2.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4b0cd795ff056e9bfb622e90b124f49c Status: R X-Status: N Carsten899@aol.com wrote:
> The sourcecode is also available at:
> http://members.aol.com/carsten899/f-cpu/index.htm
> Hopefully anybody out there starts programming F-CPU assembler someday :-)

i'd say : "wow ...."

i'll try to update the http://www.f-cpu.de/emu/ page.

YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Feb 25 17:58:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00359 for ; Tue, 27 Feb 2001 16:19:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:40 +0100 (MET) Received: (qmail 24611 invoked by uid 0); 27 Feb 2001 14:42:15 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx12) with SMTP; 27 Feb 2001 14:42:15 -0000 X-eGroups-Return: sentto-1101623-2444-983284933-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 27 Feb 2001 14:42:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 14:42:12 -0000 Received: (qmail 88945 invoked from network); 27 Feb 2001 14:42:12 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 27 Feb 2001 14:42:12 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 27 Feb 2001 14:42:11 -0000 Received: from jetnet.ab.ca (dialin53.jetnet.ab.ca [207.153.6.53]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA27688 for ; Tue, 27 Feb 2001 07:42:09 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3A9939AB.BC612990@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EB03@po1-exch.lon.tudor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Feb 2001 09:58:19 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Asynchronous 40-bit TTL CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 543d8a69fe43952ee39c6a818286a753 Status: R X-Status: N Hans Summers wrote:

> I mentioned before about my design for a CPU made in TTL, I've now scanned
> my notes. See http://www.hanssummers.com/computers/ttlcpu/intro.htm for
> amusement...

Arg another TTL computer on the market...I better get my PCB's laid out soon.
Find a source for Nixie Tubes and paper tape...
Still I think TTL designs while not practical today (Altera has a nice ttl
fpga library). The 40 bit Cpu design while rough does look good.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Feb 27 15:40:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00365 for ; Tue, 27 Feb 2001 16:19:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 16:19:42 +0100 (MET) Received: (qmail 24342 invoked by uid 0); 27 Feb 2001 14:47:08 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx21) with SMTP; 27 Feb 2001 14:47:08 -0000 X-eGroups-Return: sentto-1101623-2445-983285226-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 27 Feb 2001 14:47:07 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 14:47:05 -0000 Received: (qmail 24966 invoked from network); 27 Feb 2001 14:47:05 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 27 Feb 2001 14:47:05 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 27 Feb 2001 14:47:05 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA22750; Tue, 27 Feb 2001 06:47:03 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8A1V; Tue, 27 Feb 2001 14:52:21 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9BBC52.32E3A5F2@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EB03@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 15:40:18 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Asynchronous 40-bit TTL CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 6ff3d4b8d9c3016c88ee85a621555f12 Status: R X-Status: N Hans Summers wrote:
> Hi
>
> I mentioned before about my design for a CPU made in TTL, I've now scanned
> my notes. See http://www.hanssummers.com/computers/ttlcpu/intro.htm for
> amusement...
>
> ------------------
> Hans Summers
> http://www.HansSummers.Com

nice :-) would you like to link it with the Utopia Computing Webring ?
http://opencollector.org/cgi-bin/utopia/index

YG

speaking for himself
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Feb 27 16:09:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00869 for ; Tue, 27 Feb 2001 20:25:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 20:25:19 +0100 (MET) Received: (qmail 7293 invoked by uid 0); 27 Feb 2001 15:21:32 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx05) with SMTP; 27 Feb 2001 15:21:32 -0000 X-eGroups-Return: sentto-1101623-2446-983286986-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 27 Feb 2001 15:16:26 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 15:16:25 -0000 Received: (qmail 85718 invoked from network); 27 Feb 2001 15:16:24 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Feb 2001 15:16:24 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 27 Feb 2001 16:17:29 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA26536; Tue, 27 Feb 2001 07:16:22 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8AF9; Tue, 27 Feb 2001 15:21:40 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9BC332.BD2001F5@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <92.10e6c381.27cceccb@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 16:09:38 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: ARM and data/instruction dependancies Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5ebbbebbe7648955dec2264d03563dbe Status: R X-Status: N Carsten899@aol.com wrote:
>
> This is my version of "GCD" in F-CPU assembler. ( it requires an updated
> version of the emulator to run, because the current version assembles JMPA
> wrong - new version coming soon).
>
> I see two ways to code it:
>
> * The jump method (which is shown here).
> * A method based on CMPL and AND of compare result. Need to think about.
>     loadconsx.0 1, r1
>     loadconsx.0 2, r2
>
>     loadcons.0  getdd0_GCD_EXIT, r63
>     loadcons.1  getdd1_GCD_EXIT, r63
>     loadcons.2  getdd2_GCD_EXIT, r63
>     loadcons.3  getdd3_GCD_EXIT, r63
>
>     loadcons.0  getdd0_GCD_LESS, r62
>     loadcons.1  getdd1_GCD_LESS, r62
>     loadcons.2  getdd2_GCD_LESS, r62
>     loadcons.3  getdd3_GCD_LESS, r62
>
>     loadcons.0  getdd0_GCD, r61
>     loadcons.1  getdd1_GCD, r61
>     loadcons.2  getdd2_GCD, r61
>     loadcons.3  getdd3_GCD, r61

stooooooop ! .... :-)
there is a much faster way to do that,
provided you have a '@' symbol in your assembler,
which indicates the value of the current PC. look at
http://www.f-cpu.de/man/i7/part6.html#loadaddri
this makes "loadaddri label-@,rx"

> GCD:
>     jmpa        r61
>
>     xor         r1, r2, r3
>     cmpl        r1, r2, r4
>     jmpa.ifnnul r3, r63, r0
>     jmpa.ifnnul r4, r62, r0
>     sub         r2, r1, r1
>     jmpa        r61
> GCD_LESS:
>     sub         r1, r2, r2
>     jmpa        r61
> GCD_EXIT:
>     halt

sorry, no time to analyse the rest.

have fun,

YG

speaking for himself
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carsten899@aol.com Tue Feb 27 18:30:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00968 for ; Tue, 27 Feb 2001 20:25:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 27 Feb 2001 20:25:42 +0100 (MET) Received: (qmail 21985 invoked by uid 0); 27 Feb 2001 17:33:02 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx12) with SMTP; 27 Feb 2001 17:33:02 -0000 X-eGroups-Return: sentto-1101623-2447-983295038-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 27 Feb 2001 17:30:39 -0000 X-Sender: Carsten899@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 17:30:37 -0000 Received: (qmail 98656 invoked from network); 27 Feb 2001 17:30:34 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 27 Feb 2001 17:30:34 -0000 Received: from unknown (HELO imo-d09.mx.aol.com) (205.188.157.41) by mta3 with SMTP; 27 Feb 2001 18:31:38 -0000 Received: from Carsten899@aol.com by imo-d09.mx.aol.com (mail_out_v29.5.) id r.3d.7fde445 (18710) for ; Tue, 27 Feb 2001 12:30:18 -0500 (EST) Message-ID: <3d.7fde445.27cd3e28@aol.com> To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 114 From: Carsten899@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 12:30:16 EST Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: ARM and data/instruction dependancies Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 92b27645deb79dd63b994f2f8f831887 Status: R X-Status: N loadaddri - Thats better for sure.:-). But still it would be interesting how
to code this with at least as less jumps as the ARM version.

The current version of the assembler does not support this relative PC
computation, because it does not support expressions, just symbols, but its a
must have indeed.
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue Feb 27 21:47:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA00336 for ; Wed, 28 Feb 2001 00:48:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 00:48:48 +0100 (MET) Received: (qmail 14067 invoked by uid 0); 27 Feb 2001 20:36:17 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx08) with SMTP; 27 Feb 2001 20:36:17 -0000 X-eGroups-Return: sentto-1101623-2448-983306174-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 27 Feb 2001 20:36:16 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 20:36:14 -0000 Received: (qmail 14216 invoked from network); 27 Feb 2001 20:36:05 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 27 Feb 2001 20:36:05 -0000 Received: from unknown (HELO localhost.localdomain) (194.158.109.235) by mta3 with SMTP; 27 Feb 2001 21:37:07 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1D12A9E6B for ; Tue, 27 Feb 2001 21:47:53 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9C1278.B018C3CF@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 21:47:52 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: b155fa06fc2fc9aeb39c5a1b24047d09 Status: R X-Status: N Yann GUIDON a =E9crit :
>
> hello,
>
> Nicolas wrote:
> > Yann Guidon a =E9crit :
> > > Nicolas wrote:
> > > > Michael Riepe a =E9crit :
<...>
> > > > I follow the Leon project. It was design for SOC.
> > > f-cpu is not designed for "SoC" because this term = has not
> > > even reached the "conumer" audience.
> > > However f-cpu is not incompatible with "SoC" in sp= irit.
> > > it was simply not the primary intent : it is not even mentio= ned
> > > in the f-cpu goals.
> > Never Mind !
> if you don't mind... so what ?
>
> > It will be 90% of the use of the chip !
> 90% of what ? "market share" ? "designs" ? users ?= development efforts ?

People which want use it to make a chip.

> i don't have time to play on the words currently but you know that the= re
> is a difference between the success of an architecture, the number of<= BR> > fabbed chips, the number of implementors, the number of end users... >
> best example is of course Intel : 1 shitty arch, 1 fab, millions of bu= yers.

They were the first, they had the best fab technology, they have plenty
of money,...

> that's why i think that this discussion doesn't get to an interesting = point...
> On one side, you say : "lighten the licence otherwise nobody will= follow us",
> OTOH you're scared by the idea that the architecture gets vampirized b= y a
> big iron company. it sounds like you want to go both directions at onc= e.
>

I have to read more precisely LGPL licence but it make to protect the
design, too.

> let's forget a bit about the others and concentrate on the "real = thing"...
> F-CPU is reinterpreted by everybody who discovers it, best example is<= BR> > the latest emulator update. is it bad or is it good ? it's (simply) li= fe.
> F-CPU is alive simply because some people work on it.
>
...
> > > > So having a too much
> > > > restrictive licence can limite the use of the fcpu (nev= er forget that
> > > > GPL work well because you can sell GPL product). We wan= t a well
> > > > developped one. If our "client" can't use fcp= u, they will use Sparc,
> > > > Mips or Arm core (or more specific core as ARC...).
> > >
> > > i think that you undersee the problem. It's not a matter of = licence.
> > > What would be the problem if a company integrates a free f-c= pu core
> > > in a "SoC" ? i see none. there are Emacs versions = running under Windows,
> > > and RMS doesn't complain (afaik). Similarly, what are the tr= oubles
> > > and what is the difference if the "core" is on the= same chip and not on the
> > > same "system" (out of the chip, ie on the PCB). to= the user, there is
> > > no difference, and there is no problem if you interface a &q= uot;free" SW
> > > with Windows, or if you interface a "free" core wi= th a unknown I/O or
> > > CPU (ie: who cares if the SRAM design for the cache is propr= ietary ?
> > > only the implementor cares).
> > >
> > > The problem is with the F-CPU sources : what you have to and= can do
> > > with them. and there is no ambiguity. what you do with the > > > result of the compilation is up to you : paperwall or chairs= , if you like.
> >
> > In the opposite, i see a very big problem. ESA lawyer choose LGPL=
> > because of that.
> lawyers are lawyers, not technicians and they don't have the same poin= t of view.
>

Technicians can't work if lawyers say no.

> ESA's stakes are not the same as ours. For the ESA, the LEON is a &quo= t;means",
> a way to cut costs. For us, and for me particularly, the f-cpu is a &q= uot;goal".
> Hence the difference of point of view. Forget your SoC hype for a whil= e
> and start to learn Alpha asm...
>

Not really, they choose Sparc because there isn't any licence fee.

> > And RMS created the LGPL because of that ;p
> if he's listening to us (or spying, or whatever), maybe he should
> jump in the discussion and dissipate this trouble. thanks in advance.<= BR> >
> > There is a
> > very (very) big difference between 2 binaries running on the same= system
> > and "2 parts" that should be compiled in the same time.=
> what is a "system" ? what is "compilation" ? You k= now that today, the tools

System for SW is the computer. For HW, your source code are VHDL (or
verilog) then all others "underproduct" are compiled result(gate = level,
physical level,... you could compare to asm and binaries of the SW
world). So it could have a problem when you compile 2 vhdl code in the
same times, if one is gpl and the other not.

> allow a very wide range of operations from the simple cut'n'paste of &= quot;IP obscure blocks"

In fact, not really ! Try to recompile a hard macrocell just to see...

> to the resynthesis of the whole chip. what matters most at our level i= s
> the preservation of the ISA coherency and transparency.
> The source code and the manuals are our current means to achieve that.=
> it's under GPL, that's ok. That's all what matters for us and for the<= BR> > people who will implement it.
>

What means GPL for a document ?

> we have touched the difference between HW and SW. the notions of "= ;library"
> and "compiler", "derived work" and "work that= uses the F-CPU" are
> very different and few in common.

I don't think it is so different.

>
> > LGPL was created
> > to permit the use of library on propritary application. But you a= lways
> > could run proprietary program on GPL Linux !
> so the notion of "system" and compilation is rather fuzzy, p= articularly in
> our present case. what is a "system" ? a chip ? a zone on th= e chip ?
> a software bundle ? a PCB ? what ?
>

If you absolutely want to use GPL maybe the "outside" world shoul= d be
defined and there isn't any more a problem.

> > So you could NOT mixed our GPL vhdl code and proprietary VHDL cod= e. We
> > should use LGPL to permit that (and protecte the fcpu code itself= ).
>
> when you insert a f-cpu core into a "system" (whatever it is= ), it's always a "mix".

Yes, but lawyers make a difference, that's why LGPL was created to
permit the link between GPL library and proprietary code. And in a
library, the interface is well defined.

> what matters today is the integrity of the core, whatever is connected=
> around it. I think it would be very difficult to stand a case with thi= s
> problem, while it is clear that the f-cpu sources can be protected. >
> > > > > > But the isa definition should be protect by t= he gpl, too. Whygee want a
> > > > > > total freedom but if the different core are t= o much different, it will
> > > > > > never survive with the time.
> > > > > I agree with that.  The ISA must not be in th= e public domain.
> > > > 2 agree ! Some more ?
> > > the ISA is not public domain. it is covered by our author's = rights.
> > > however the specialists can always find ways to bypass some = parts.
> > The GPL is a copyright.
> as such, it does only protect the "form" and not the "b= ackground",
> it protects the expression and not the idea. the ISA is an "idea&= quot;,
> otherwise AMD and others wouldn't be allowed to make clones...
> go browse at the GNU site.
> That is why we have no means to kee people from reusing
> the F-CPU ISA. it's a risk but life is risky too...
>
> > > > > A while ago, I wrote some rules about modification= s to the instruction set.
> > > > > Please refer to the mailing list archive (or your = local copy, if you have one).
> > > > I remember that it was very strict.
> > > it is our right... look at the industry licences ;-)
> > I know we could make what we want. But i think that we want that = fcpu
> > should be used by few people...
> but what do you want in the end ? both quantity and quality ?
> please start with quality. if you want to attract too many people
> with a "gratis core", the project will suffer from a sudden = growth and it
> will explode/blow away. Long ago, we were concerned by the patent prob= lems,
> we didn't care in the end because we would loose a lot of time and
> do nothing at all. Now the licence problem arises again but it's a bit= late...
> the GPL was chosen from the start and i doubt it will change,
> now the real question is its interpretation in the frame of the electr= onics world.
> If we can't use the GPL, then the LGPL is void too.
>
> > > > You would like to restrain the
> > > > modification to the ISA but it's far more restrictive t= han GPL (no rules
> > > > of how the next version should work are describe !). If= the licence is
> > > > to restrictive, you will limit the use of the core.
> > > not necessarily.
> > > a lot of people use existing cores and don't want to modify = the ISA.
> > > however, we leave to possibility to "adapt" it, un= der certain conditions
> > > that are meant to keep the implemented cores coherent. if so= meone breaks
> > > the coherency of the architecture, he will be banned (that's= all).
> > ???? If intel take the fcpu ISA and make it's owne core with few = key
> > proprietary feature. Then because of its marketing power and this=
> > specific feature, it will kill all other concurent (other chip ma= ker).
> > So usual fcpu ISA will be "owne" by intel. That's a ver= y big risk !
> this risk is even higher if you use the LGPL.
> http://www= .gnu.org/philosophy/license-list.html says :
>   The GNU Lesser General Public License, or GNU LGPL for sho= rt.
>       This is a free software license, b= ut not a strong copyleft license,
>       because it permits linking with no= n-free modules. It is compatible
>       with the GNU GPL. We recommend it = for special circumstances only.
> These circumstances are explained at http://www.gnu.org/philosophy/why-not-lgpl.html<= /a>
> but only apply in the frame of software.
>
> The F-CPU is not a "library". it should be considered as a &= quot;program".

Why ? You could use it in a SOC (your "system") and call it libra= ry
because you only use its interface and don't need to manage with
internal stuff.

> a library would be an execution unit. in this case, yes, you'll have t= o make
> you new execution unit available under GPL. that's all.
>

It's just an other level of hierarchy, it's the same problem exactly.

> F-CPU core is a "program" that communicates to the outside w= ith the memory
> interface, therefore there is no risk for the inside of the core when = it is
> respectfully integrated in another product.
>

This is the (library API)interface, no ?

> > > > >  Michael "Tired" Riepe <Michael.= Riepe@stud.uni-hannover.de>
> > > > nicO
> > > WHYGEE
> >
> > rares@moonbase.res.wpi.net a =E9crit :
> > > Why not just allow forks of the project?
> > More often a fork just kill a project. And our project is big and=
> > complex, so very fragile. And here the problem is to stole our wo= rk.
> Sure the project is fragile. however it is called "freedom" = and if
> someone has a very brilliant idea, he should not be kept from trying > it. Al has even tried to start a new project. whether is succeeds
> or not is another story, but forks can't be avoided at one point
> or another.
>
> however when it comes to "steal the work", i wonder how it c= ould happen.
> this work is "free" in itself so if a problem arises, it's F= SF's lawyers' problem.
>
> "design and let design".
>
> > nicO
> >
> > PS: Whygee, have you lost my little exercise about a piece of asm= arm
> > code ?
> i haven't lost it, it is at home and i'm at work (though i could
> easily browse to the online archive). on top of that, it's a rather he= avy task
> to perform and i don't have time yet to do this exercise. i'm lame, i = know...
>
> however i should practice more asm, or i'll forget the old tricks soon= ...
>
I should play with the simulator. I ask myself how we could deal data
where you never mind of SIMD.
> have fun,
> YG
>
> speaking for himself
nicO
Yahoo! Groups Spons= or
3D"Beco=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Feb 27 14:19:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA00859 for ; Wed, 28 Feb 2001 03:28:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 03:28:38 +0100 (MET) Received: (qmail 28409 invoked by uid 0); 27 Feb 2001 23:46:46 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx01) with SMTP; 27 Feb 2001 23:46:46 -0000 X-eGroups-Return: sentto-1101623-2449-983317605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 27 Feb 2001 23:46:45 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 23:46:44 -0000 Received: (qmail 84138 invoked from network); 27 Feb 2001 23:46:42 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 27 Feb 2001 23:46:42 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.108) by mta1 with SMTP; 27 Feb 2001 23:46:38 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00532; Tue, 27 Feb 2001 14:19:16 +0100 Message-ID: <20010227141916.36328@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A9B9431.913A2443@mentor.com>; from Yann GUIDON on Tue, Feb 27, 2001 at 12:49:05PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 14:19:16 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 48e919abb7794ac9c056319b021ec37e Status: R X-Status: N On Tue, Feb 27, 2001 at 12:49:05PM +0100, Yann GUIDON wrote:
[...]
> All the files are already under GPL. it's too late if you want to change
> the licence. i don't think that the people who have contributed would
> like to change the licence.

If there is a good reason to do so, I won't refuse to change the license
to something different (for the files I wrote -- I can't speak for
anybody else).

On the other hand -- those who contribute code decide under which license
they release it.  That's freedom, and I like it.  And it means that you
(not Yann, who seems to share my opinion, but everybody who tries) will
have a *very* hard time convincing me that LGPL is better for *my* code.

> Because the ESA uses LGPL doesn't mean that we must do the same.
> LGPL is called by the FSF "Lesser GPL", or "weak" GPL.
> this should ring a bell.

"Lesser General" is the keyword here, not "Lesser GPL", IMHO.

[...]
> > And RMS created the LGPL because of that ;p
> if he's listening to us (or spying, or whatever), maybe he should
> jump in the discussion and dissipate this trouble. thanks in advance.

RMS always encouraged people NOT to use LGPL for their projects.
It's appropriate for rewrites of proprietary libraries (like lesstif,
Mesa, glibc, or my own libelf library) that can be used in place of the
commercial ones, but not for something entirely new.

[...]
> we have touched the difference between HW and SW. the notions of "library"
> and "compiler", "derived work" and "work that uses the F-CPU" are
> very different and few in common.

That means we're lucky and can define them ourselves, for this special case.

[...]
> The F-CPU is not a "library". it should be considered as a "program".
> a library would be an execution unit. in this case, yes, you'll have to make
> you new execution unit available under GPL. that's all.

Yep, and it's perfect the way it is.

> F-CPU core is a "program" that communicates to the outside with the memory
> interface, therefore there is no risk for the inside of the core when it is
> respectfully integrated in another product.

Yep again.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Feb 27 13:57:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA00862 for ; Wed, 28 Feb 2001 03:28:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 03:28:38 +0100 (MET) Received: (qmail 14456 invoked by uid 0); 27 Feb 2001 23:46:53 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx10) with SMTP; 27 Feb 2001 23:46:53 -0000 X-eGroups-Return: sentto-1101623-2450-983317612-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 27 Feb 2001 23:46:52 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Feb 2001 23:46:51 -0000 Received: (qmail 40793 invoked from network); 27 Feb 2001 23:46:45 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 27 Feb 2001 23:46:45 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.108) by mta1 with SMTP; 27 Feb 2001 23:46:43 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00471; Tue, 27 Feb 2001 13:57:01 +0100 Message-ID: <20010227135701.17555@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> X-Mailer: Mutt 0.84e In-Reply-To: <3A9AB3C9.7DFB1FC6@seul.org>; from Nicolas on Mon, Feb 26, 2001 at 08:51:37PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Feb 2001 13:57:01 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4599914f02acc7e9019945a4a1e17685 Status: R X-Status: N On Mon, Feb 26, 2001 at 08:51:37PM +0100, Nicolas wrote:
[...]
> In the opposite, i see a very big problem. ESA lawyer choose LGPL
> because of that. And RMS created the LGPL because of that ;p There is a
> very (very) big difference between 2 binaries running on the same system
> and "2 parts" that should be compiled in the same time. LGPL was created
> to permit the use of library on propritary application. But you always
> could run proprietary program on GPL Linux !
>
> So you could NOT mixed our GPL vhdl code and proprietary VHDL code. We
> should use LGPL to permit that (and protecte the fcpu code itself).

As far as I understand the LGPL, you can't do that either ("mix" the
code -- that would be a derived work).

[...]
> The GPL is a copyright.

No, it's a license.  BIG difference.

The GPL (or LGPL) is just like the shrink-wrap licenses most commercial
software vendors use ("when you open this package, you agree to ..."),
it just grants you much more rights.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Feb 28 10:41:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00364 for ; Wed, 28 Feb 2001 14:45:26 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 14:45:26 +0100 (MET) Received: (qmail 12840 invoked by uid 0); 28 Feb 2001 09:48:49 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx13) with SMTP; 28 Feb 2001 09:48:49 -0000 X-eGroups-Return: sentto-1101623-2451-983353727-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 28 Feb 2001 09:48:48 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 09:48:46 -0000 Received: (qmail 21939 invoked from network); 28 Feb 2001 09:48:46 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 28 Feb 2001 09:48:46 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 28 Feb 2001 10:49:50 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA10700; Wed, 28 Feb 2001 01:48:43 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8A93; Wed, 28 Feb 2001 09:54:01 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9CC7E5.DE0D65F7@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <20010227141916.36328@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 10:41:57 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 4caebffee075184e3d3ecc807e351d83 Status: R X-Status: N hello everybody,

i BCCed my last mail to RMS and i think i caught his attention
however we'll have to make a little cleanup in the mails, and define
precise questions (he's almost as overbooked as me ;-P).

This means that we're going to somewhere, fine :-)
it would be sad if these discussions were useless.

> On Mon, Feb 26, 2001 at 08:51:37PM +0100, Nicolas wrote:
> [...]
> > The GPL is a copyright.
>
> No, it's a license.  BIG difference.

hence the L in GPL :-)


Michael Riepe wrote:
> On Tue, Feb 27, 2001 at 12:49:05PM +0100, Yann GUIDON wrote:
> > Because the ESA uses LGPL doesn't mean that we must do the same.
> > LGPL is called by the FSF "Lesser GPL", or "weak" GPL.
> > this should ring a bell.
> "Lesser General" is the keyword here, not "Lesser GPL", IMHO.
well, huh, ok... less anyway :-)

> [...]
> > > And RMS created the LGPL because of that ;p
> > if he's listening to us (or spying, or whatever), maybe he should
> > jump in the discussion and dissipate this trouble. thanks in advance.
> RMS always encouraged people NOT to use LGPL for their projects.
> It's appropriate for rewrites of proprietary libraries (like lesstif,
> Mesa, glibc, or my own libelf library) that can be used in place of the
> commercial ones, but not for something entirely new.
and the f-cpu is "something really new".

> [...]
> > we have touched the difference between HW and SW. the notions of "library"
> > and "compiler", "derived work" and "work that uses the F-CPU" are
> > very different and few in common.
> That means we're lucky and can define them ourselves, for this special case.
i believe that the F-CPU charter is the best place to define this.
we might add some paragraphs soon.

> [...]
> > The F-CPU is not a "library". it should be considered as a "program".
> > a library would be an execution unit. in this case, yes, you'll have to make
> > you new execution unit available under GPL. that's all.
> Yep, and it's perfect the way it is.
> > F-CPU core is a "program" that communicates to the outside with the memory
> > interface, therefore there is no risk for the inside of the core when it is
> > respectfully integrated in another product.
> Yep again.

It's cool that we're apparently on the same wavelength,
and now i'm waiting to read the comments from the other list members.
it's going to be very interesting.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

YG, having a flu...

speaking for himself

PS: what is going on with the CVS ? any news ?
Yahoo! Groups Sponsor
Thousands of FREE Products after Rebate!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Feb 28 10:46:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00367 for ; Wed, 28 Feb 2001 14:45:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 14:45:27 +0100 (MET) Received: (qmail 26450 invoked by uid 0); 28 Feb 2001 09:56:24 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx03) with SMTP; 28 Feb 2001 09:56:24 -0000 X-eGroups-Return: sentto-1101623-2452-983353974-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 28 Feb 2001 09:52:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 09:52:54 -0000 Received: (qmail 88437 invoked from network); 28 Feb 2001 09:52:53 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 28 Feb 2001 09:52:53 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 28 Feb 2001 10:53:57 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA11034; Wed, 28 Feb 2001 01:52:50 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8A95; Wed, 28 Feb 2001 09:58:09 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9CC8DD.C67B2DC9@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3d.7fde445.27cd3e28@aol.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 10:46:05 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: ARM and data/instruction dependancies Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f0bd8b2fdfdbca79c480bdd1c3bf2295 Status: R X-Status: N hi !

Carsten899@aol.com wrote:
> loadaddri - Thats better for sure.:-). But still it would be interesting how
> to code this with at least as less jumps as the ARM version.
that's another problem... i'll try to have  a closer look soon.

> The current version of the assembler does not support this relative PC
> computation, because it does not support expressions, just symbols, but its a
> must have indeed.

with FLEX+BISON it's fairly easy (once you got the trick).
i did an assemler for the SHARC (not complete though) and
it managed expressions easily, i had simply cut&pasted the
expression evaluator of a C compiler example :-)

however if you don't stand BISON, there's still the old
good stack machine solution...

YG

speaking for himself
Yahoo! Groups Sponsor
Thousands of FREE Products after Rebate!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Feb 28 11:14:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00370 for ; Wed, 28 Feb 2001 14:45:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 14:45:27 +0100 (MET) Received: (qmail 25634 invoked by uid 0); 28 Feb 2001 10:34:59 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx07) with SMTP; 28 Feb 2001 10:34:59 -0000 X-eGroups-Return: sentto-1101623-2453-983356498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 28 Feb 2001 10:34:58 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 10:34:57 -0000 Received: (qmail 74385 invoked from network); 28 Feb 2001 10:34:57 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 28 Feb 2001 10:34:57 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 28 Feb 2001 10:34:57 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA14313; Wed, 28 Feb 2001 02:21:50 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8BAV; Wed, 28 Feb 2001 10:26:56 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9CCF9C.2A2F1B76@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <3A9C1278.B018C3CF@seul.org> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 11:14:52 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 92dbc4ba3c568a2360ab31cf2655e9f3 Status: R X-Status: N hi,

Nicolas wrote:
> Yann GUIDON a =E9crit :
> > hello,
> > Nicolas wrote:
> > > Yann Guidon a =E9crit :
> > > > Nicolas wrote:
> > > > > Michael Riepe a =E9crit :
> <...>

> > ESA's stakes are not the same as ours. For the ESA, the LEON is a= "means",
> > a way to cut costs. For us, and for me particularly, the f-cpu is= a "goal".
> > Hence the difference of point of view. Forget your SoC hype for a= while
> > and start to learn Alpha asm...
>
> Not really, they choose Sparc because there isn't any licence fee.
>
i only spoke about ALPHA because there is a lot to learn from it.
SPARC is better than x86, sure, but ALPHA class CPU bring new techniques that might be useful for you. read alpha docs, programming manuals etc...
> > > There is a
> > > very (very) big difference between 2 binaries running on the= same system
> > > and "2 parts" that should be compiled in the same = time.
> > what is a "system" ? what is "compilation" ? = You know that today, the tools
>
> System for SW is the computer. For HW, your source code are VHDL (or > verilog) then all others "underproduct" are compiled result(= gate level,
> physical level,... you could compare to asm and binaries of the SW
> world). So it could have a problem when you compile 2 vhdl code in the=
> same times, if one is gpl and the other not.

no, as long as they don't get interdependent (that's where the trap is).
> > allow a very wide range of operations from the simple cut'n'paste= of
> > "IP obscure blocks"
> In fact, not really ! Try to recompile a hard macrocell just to see...=
i wasn't speaking about recompiling hard cells, but inserting them in
a design.

> > to the resynthesis of the whole chip. what matters most at our le= vel is
> > the preservation of the ISA coherency and transparency.
> > The source code and the manuals are our current means to achieve = that.
> > it's under GPL, that's ok. That's all what matters for us and for= the
> > people who will implement it.
> What means GPL for a document ?

that you hold the copyright and that you apply certain restrictions and all= ow
other things. i think that you probably read it once...

> > we have touched the difference between HW and SW. the notions of = "library"
> > and "compiler", "derived work" and "work= that uses the F-CPU" are
> > very different and few in common.
> I don't think it is so different.
>
it depends on your point of view.
you are the "SoC generation", the system is the chip for you and = the
CPU is a library. For me, and some other people, the CPU is the most
important thing (hence the C in CPU) because this is what you program.
The Freedom project started because of the hegemony in that domain,
not because we wanted a cool replacement for ARM, embedded MIPS or SPARC. if you want it, use a LEON (you already do it).
The "SoC" trend will certainly be smoother in a few year, new cor= es
will appear. F-CPU will remain because it is not meant to be
a "disposable" core.


> > > LGPL was created
> > > to permit the use of library on propritary application. But = you always
> > > could run proprietary program on GPL Linux !
> > so the notion of "system" and compilation is rather fuz= zy, particularly in
> > our present case. what is a "system" ? a chip ? a zone = on the chip ?
> > a software bundle ? a PCB ? what ?
> If you absolutely want to use GPL maybe the "outside" world = should be
> defined and there isn't any more a problem.
that's what we have to discuss now, so we can update the F-CPU charter.

> > > So you could NOT mixed our GPL vhdl code and proprietary VHD= L code. We
> > > should use LGPL to permit that (and protecte the fcpu code i= tself).
> > when you insert a f-cpu core into a "system" (whatever = it is), it's always a "mix".
> Yes, but lawyers make a difference, that's why LGPL was created to
> permit the link between GPL library and proprietary code. And in a
> library, the interface is well defined.
it is clear for some people, maybe it wasn't clearly written down.


> > > > > You would like to restrain the
> > > > > modification to the ISA but it's far more restrict= ive than GPL (no rules
> > > > > of how the next version should work are describe != ). If the licence is
> > > > > to restrictive, you will limit the use of the core= .
> > > > not necessarily.
> > > > a lot of people use existing cores and don't want to mo= dify the ISA.
> > > > however, we leave to possibility to "adapt" i= t, under certain conditions
> > > > that are meant to keep the implemented cores coherent. = if someone breaks
> > > > the coherency of the architecture, he will be banned (t= hat's all).
> > > ???? If intel take the fcpu ISA and make it's owne core with= few key
> > > proprietary feature. Then because of its marketing power and= this
> > > specific feature, it will kill all other concurent (other ch= ip maker).
> > > So usual fcpu ISA will be "owne" by intel. That's = a very big risk !
> > this risk is even higher if you use the LGPL.
> > http:= //www.gnu.org/philosophy/license-list.html says :
> >   The GNU Lesser General Public License, or GNU LGPL fo= r short.
> >       This is a free software licen= se, but not a strong copyleft license,
> >       because it permits linking wi= th non-free modules. It is compatible
> >       with the GNU GPL. We recommen= d it for special circumstances only.
> > These circumstances are explained at http://www.gnu.org/philosophy/why-not-lgpl.= html
> > but only apply in the frame of software.
> >
> > The F-CPU is not a "library". it should be considered a= s a "program".
>
> Why ? You could use it in a SOC (your "system") and call it = library
> because you only use its interface and don't need to manage with
> internal stuff.

same as Netscape, a CPU, GCC, your window manager, Xfree86...
you use them with a specific interface,
and you usually don't care about how it's implemented.
However, a library is meant to provide "functions" only,
while Xfree or a Window Manager has control features,
with some kind of sequencing and a particular, specific
behaviour, ie the main event loop of a SW that uses the Xlib.
Netscape has to loop and call a library function to fetch the
event and communicate with the outside, but the library itself
does not provide the particular behaviour of the whole software.

The CPU core has a specific behaviour. it has a specific
sequencing and control mechanism and can use "generic" execution = units
and interfaces. however, the way interfaces are accessed and used
depends on the core and can't be exchanged, or it makes a new core.

> > a library would be an execution unit. in this case, yes, you'll h= ave to make
> > you new execution unit available under GPL. that's all.
> It's just an other level of hierarchy, it's the same problem exactly.<= BR> it's not the same stakes. hierarchy at the design level is not the same
for the programer/compiler. what the user sees is instructions and their behaviour (temporal and scheduling), not the units or the way it is impleme= nted.
it doesn't make the difference between onchip and offchip memory or I/O.
> > F-CPU core is a "program" that communicates to the outs= ide with the memory
> > interface, therefore there is no risk for the inside of the core = when it is
> > respectfully integrated in another product.
> This is the (library API)interface, no ?
or the command line for the program.
as you noted, we can "play" with hierarchies,
but the end user usually doesn't like it...

> > > nicO
> > >
> > > PS: Whygee, have you lost my little exercise about a piece o= f asm arm code ?
> > i haven't lost it, it is at home and i'm at work (though i could<= BR> > > easily browse to the online archive). on top of that, it's a rath= er heavy task
> > to perform and i don't have time yet to do this exercise. i'm lam= e, i know...
> >
> > however i should practice more asm, or i'll forget the old tricks= soon...
> >
>  I should play with the simulator. I ask myself how we could deal= data
> where you never mind of SIMD.
i wish i had enough time to take a close look at the emulator code...

> > have fun,
> > YG
> >
> > speaking for himself
> nicO
YG

speaking for himself
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Wed Feb 28 12:25:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00382 for ; Wed, 28 Feb 2001 14:45:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 14:45:32 +0100 (MET) Received: (qmail 18023 invoked by uid 0); 28 Feb 2001 11:26:08 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx09) with SMTP; 28 Feb 2001 11:26:08 -0000 X-eGroups-Return: sentto-1101623-2454-983359546-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 28 Feb 2001 11:25:46 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 11:25:45 -0000 Received: (qmail 49457 invoked from network); 28 Feb 2001 11:25:45 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 28 Feb 2001 11:25:45 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 28 Feb 2001 11:25:40 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id GAA18436 for ; Wed, 28 Feb 2001 06:23:10 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id GAA01289 for ; Wed, 28 Feb 2001 06:25:38 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Feb 2001 11:25:38 -0000 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EB0D@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 11:25:37 -0000 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] Asynchronous 40-bit TTL CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 5131ba167e312b038e1c7007002fdfbe Status: R X-Status: N
> -----Original Message-----
> From: Yann GUIDON [mailto:whygee@f-cpu.org]
> Sent: 27 February 2001 14:40
> To: f-cpu@yahoogroups.com
> Subject: Re: [f-cpu] Asynchronous 40-bit TTL CPU
>
>
> Hans Summers wrote:
> > Hi
> >
> > I mentioned before about my design for a CPU made in TTL,
> I've now scanned
> > my notes. See
> http://www.hanssummers.com/computers/ttlcpu/int> ro.htm for
> >
> amusement...
> >
> > ------------------
> > Hans
> Summers
> > http://www.HansSummers.Com
>
> nice :-) would you like to link it with the Utopia Computing Webring ?
> http://opencollector.org/cgi-bin/utopia/index

Yes, as long as I won't be kicked out later, if I decide to include a link
to my heretical scheduler proposal ;-)

>
> YG
>
> speaking for himself
>
------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
At Egghead.com...We Mean Business!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Feb 28 15:57:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01671 for ; Wed, 28 Feb 2001 22:30:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 22:30:53 +0100 (MET) Received: (qmail 4797 invoked by uid 0); 28 Feb 2001 15:06:14 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx10) with SMTP; 28 Feb 2001 15:06:14 -0000 X-eGroups-Return: sentto-1101623-2455-983372650-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 28 Feb 2001 15:04:12 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 15:04:09 -0000 Received: (qmail 22298 invoked from network); 28 Feb 2001 15:04:08 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 28 Feb 2001 15:04:08 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 28 Feb 2001 15:04:07 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA13265; Wed, 28 Feb 2001 07:04:05 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8BPZ; Wed, 28 Feb 2001 15:09:24 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9D11D0.C26AE1ED@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EB0D@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 15:57:20 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Asynchronous 40-bit TTL CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 44f8bcee0443d9881b599f4cc92c5bbc Status: R X-Status: N Hans Summers wrote:
> > From: Yann GUIDON
> > Hans Summers wrote:
> > > Hi
> > > I mentioned before about my design for a CPU made in TTL,
> > > I've now scanned my notes. See
> > > http://www.hanssummers.com/computers/ttlcpu/int> ro.htm for
> > > amusement...
> > > Hans Summers
> > > http://www.HansSummers.Com
> >
> > nice :-) would you like to link it with the Utopia Computing Webring ?
> > http://opencollector.org/cgi-bin/utopia/index
>
> Yes, as long as I won't be kicked out later, if I decide to include a link
> to my heretical scheduler proposal ;-)
look at the other subscribed sites and tell me who's the most heretic ;-)
i've enabled your inscription, take time to look around the ring.
it has a lot of "utopic" desings, hence the name. But what still
matters is the imagination and the knowledge that the user or developer
gets and shares.

have fun,

YG

speaking for himself
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Feb 28 16:22:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01677 for ; Wed, 28 Feb 2001 22:30:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 28 Feb 2001 22:30:54 +0100 (MET) Received: (qmail 31432 invoked by uid 0); 28 Feb 2001 15:35:07 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx17) with SMTP; 28 Feb 2001 15:35:07 -0000 X-eGroups-Return: sentto-1101623-2456-983374131-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 28 Feb 2001 15:28:52 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 15:28:50 -0000 Received: (qmail 53892 invoked from network); 28 Feb 2001 15:28:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 28 Feb 2001 15:28:49 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 28 Feb 2001 16:29:53 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA16467; Wed, 28 Feb 2001 07:28:44 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8BRB; Wed, 28 Feb 2001 15:34:03 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9D1798.8E121E0D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: rms@gnu.org Cc: "f-cpu@egroups.com" References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <200102280433.VAA16362@aztec.santafe.edu> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 16:22:00 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: a7ed020235733e0673f4fc4f1b7f156b Status: R X-Status: N Richard Stallman wrote:
>
> That message is long and full of nested responses.
> To read it all would be hard work, and to understand
> it would be a struggle.
>
> Is there a specific question that I should look at?

Let me sum up (possibly too much quickly) :

First note that i'll use the terms "SoC" and "IP blocks"
only for the reason that it is the only thing that
some people understand. i'll be more general later.

The discussion fired when the issue GPL vs LGPL
was brought. the ESA/LEON uses LGPL because they
want to use the LEON as a "IP core" that would be like
a library block in "SoC" designs. LEON has been
implemented in several other chips since then
and is the first widely successful "free hardware design".

Nicolas says that the use of the GPL keeps the implementors
>from using the F-CPU core(s) inside a "SoC", a chip that uses
"IP blocks" as LEGO bricks. I disagree (Michael too).

For us, the "design" is the microprocessor, "libraries" would be
the individual execution units for example. There is no
reason to use the LGPL from this point of view because the
program (the CPU) has to remain integral and coherent.
It communicates with the outside with the memory interface
and that's enough, whatever it communicates with.

By playing with the scale/hierarchy, everything in a computer
seems to be a "library" or a "building" block for the higher
level. For Nicolas, the "design" is the chip, hence the "CPU core"
is a "library". However, there are other kinds of libraries,
having a similar interface : gate-level libraries (and/or/etc.),
adder/multipler (a set of gates), etc... As the integration
level increases (LSI, VLSI, ULSI...), the hierarchy in the chips
have more levels and a library can embrace several levels.


Question/problem : the distinction between GPL and LGPL,
library and program, seems to be unadapted in the microelectronics world.
The parallels between HW and SW seem to stop here.

The choice of the GPL was early and it seems to be too late,
but what do we tell to people who want to integrate the F-CPU
in their chip, among other (proprietary) blocks ?


regards,

YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Wed Feb 28 23:41:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02612 for ; Thu, 1 Mar 2001 01:45:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:53 +0100 (MET) Received: (qmail 853 invoked by uid 0); 28 Feb 2001 22:32:01 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx03) with SMTP; 28 Feb 2001 22:32:01 -0000 X-eGroups-Return: sentto-1101623-2457-983399516-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 28 Feb 2001 22:31:59 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 22:31:55 -0000 Received: (qmail 11770 invoked from network); 28 Feb 2001 22:29:51 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 28 Feb 2001 22:29:51 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.137) by mta2 with SMTP; 28 Feb 2001 22:29:49 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2E5AD9E68 for ; Wed, 28 Feb 2001 23:41:45 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9D7EA8.1AB86EF2@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <20010227135701.17555@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 23:41:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: e338ec79056054a93a9195bc4f5931d1 Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Mon, Feb 26, 2001 at 08:51:37PM +0100, Nicolas wrote:
> [...]
> > In the opposite, i see a very big problem. ESA lawyer choose LGPL=
> > because of that. And RMS created the LGPL because of that ;p Ther= e is a
> > very (very) big difference between 2 binaries running on the same= system
> > and "2 parts" that should be compiled in the same time.= LGPL was created
> > to permit the use of library on propritary application. But you a= lways
> > could run proprietary program on GPL Linux !
> >
> > So you could NOT mixed our GPL vhdl code and proprietary VHDL cod= e. We
> > should use LGPL to permit that (and protecte the fcpu code itself= ).
>
> As far as I understand the LGPL, you can't do that either ("mix&q= uot; the
> code -- that would be a derived work).
>
> [...]
> > The GPL is a copyright.
>
> No, it's a license.  BIG difference.

The legal stuff used is the law about copyright ! I insist.

>
> The GPL (or LGPL) is just like the shrink-wrap licenses most commercia= l
> software vendors use ("when you open this package, you agree to .= .."),
> it just grants you much more rights.

"Using the ordinary GPL is not advantageous for every library. There a= re
reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily
available for proprietary software through other alternative libraries.
In that case, the library cannot give free software any particular
advantage, so it is better to use the Library GPL for that library. "<= BR> >from http://www= .gnu.org/philosophy/why-not-lgpl.html

So it's clear. If you want make a chip (compile VHDL to produice a chip, very different that using a chip in a system (there's no more vhdl
sources), the chip is owned by the chip maker), you can't use mixed
code. It could be a choice but there is very few other hardware core to
use with.

That could be our choice. To launch the mouvement. Hard choice !

nicO
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Become=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Wed Feb 28 23:58:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02615 for ; Thu, 1 Mar 2001 01:45:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:54 +0100 (MET) Received: (qmail 10725 invoked by uid 0); 28 Feb 2001 22:51:35 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx11) with SMTP; 28 Feb 2001 22:51:35 -0000 X-eGroups-Return: sentto-1101623-2458-983400690-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 28 Feb 2001 22:51:31 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 22:51:30 -0000 Received: (qmail 67747 invoked from network); 28 Feb 2001 22:51:27 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 28 Feb 2001 22:51:27 -0000 Received: from unknown (HELO relay01.cablecom.net) (62.2.33.101) by mta3 with SMTP; 28 Feb 2001 23:52:32 -0000 Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay01.cablecom.net (8.11.1/8.11.0/SOL/MXRELAY-1.03) with ESMTP id f1SMpQZ05145 for ; Wed, 28 Feb 2001 23:51:26 +0100 (CET) Received: from bureau (sol-91-227.swissonline.ch [195.24.91.227]) by mail.swissonline.ch (8.11.1/8.11.0/MSOL-2.17) with SMTP id f1SMpOF20156 for ; Wed, 28 Feb 2001 23:51:24 +0100 (MET) Message-Id: <200102282251.f1SMpOF20156@mail.swissonline.ch> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.67109975) From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 23:58:57 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 90b759c1e4d2cace44e0b93664e415c5 Status: R X-Status: N >Nicolas says that the use of the GPL keeps the implementors
>from using the F-CPU core(s) inside a "SoC", a chip that uses
>"IP blocks" as LEGO bricks. I disagree (Michael too).

  I have been reading and not writing much for some
time, but let me react on this one.  I think one
question has not been asked.  Do we want to help
implementors to mix F-CPU and proprietary work ?  To
my understanding, the goal of the GNU project and the
GPL is there to promote free software.  I think it is
well explained on the gnu website
(www.gnu.org/philosophy/why-not-lgpl.html) :


-- begin from
"www.gnu.org/philosophy/why-not-lgpl.html" --

Proprietary software developers have the advantage of
money; free
software developers need to make advantages for each
other.  Using the
ordinary GPL for a library gives free software
developers an advantage
over proprietary developers: a library that they can
use, while
proprietary developers cannot use it.

[...]

However, when a library provides a significant unique
capability, like
GNU Readline, that's a horse of a different color.
The Readline
library implements input editing and history for
interactive programs,
and that's a facility not generally available
elsewhere.  Releasing it
under the GPL and limiting its use to free programs
gives our
community a real boost.  At least one application
program is free
software today specifically because that was necessary
for using
Readline.

-- end from "www.gnu.org/philosophy/why-not-lgpl.html"
--

  So I dont think the question should be "which
lisence do we choose so implementors could mix our
work with proprietary work" but "do we want to make it
easy for implementors to mix our work with proprietary
work".  That is too : do we want to have a F-CPU
widely used, or do we want a F-CPU that promote free
hardware ?

  Sorry, I might have been a little long ...

      Guillaume





* * * * * * * * * * * * * * * * * * * *

One can search the brain with a microscope and
not find the mind, and can search the stars with
a telescope and not find God.

            -- J. Gustav White
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Thu Mar 1 00:10:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02618 for ; Thu, 1 Mar 2001 01:45:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:55 +0100 (MET) Received: (qmail 1467 invoked by uid 0); 28 Feb 2001 22:59:12 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx24) with SMTP; 28 Feb 2001 22:59:12 -0000 X-eGroups-Return: sentto-1101623-2459-983401147-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 28 Feb 2001 22:59:09 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 22:59:06 -0000 Received: (qmail 70894 invoked from network); 28 Feb 2001 22:59:04 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 28 Feb 2001 22:59:04 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.137) by mta2 with SMTP; 28 Feb 2001 22:59:02 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2AFEF9E68 for ; Thu, 1 Mar 2001 00:10:58 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9D8582.B91AB5B5@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <200102280433.VAA16362@aztec.santafe.edu> <3A9D1798.8E121E0D@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 00:10:58 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 548499a49d0111b9e17248c0656fce10 Status: R X-Status: N Yann GUIDON a =E9crit :
>
> Richard Stallman wrote:
> >
> > That message is long and full of nested responses.
> > To read it all would be hard work, and to understand
> > it would be a struggle.
> >
> > Is there a specific question that I should look at?
>
> Let me sum up (possibly too much quickly) :
>
> First note that i'll use the terms "SoC" and "IP blocks= "
> only for the reason that it is the only thing that
> some people understand. i'll be more general later.
>
> The discussion fired when the issue GPL vs LGPL
> was brought. the ESA/LEON uses LGPL because they
> want to use the LEON as a "IP core" that would be like
> a library block in "SoC" designs. LEON has been
> implemented in several other chips since then
> and is the first widely successful "free hardware design". >
> Nicolas says that the use of the GPL keeps the implementors
> from using the F-CPU core(s) inside a "SoC", a chip that use= s
> "IP blocks" as LEGO bricks. I disagree (Michael too).
>
> For us, the "design" is the microprocessor, "libraries&= quot; would be
> the individual execution units for example. There is no
> reason to use the LGPL from this point of view because the
> program (the CPU) has to remain integral and coherent.
> It communicates with the outside with the memory interface
> and that's enough, whatever it communicates with.
>
> By playing with the scale/hierarchy, everything in a computer
> seems to be a "library" or a "building" block for = the higher
> level. For Nicolas, the "design" is the chip, hence the &quo= t;CPU core"
> is a "library". However, there are other kinds of libraries,=
> having a similar interface : gate-level libraries (and/or/etc.),
> adder/multipler (a set of gates), etc... As the integration
> level increases (LSI, VLSI, ULSI...), the hierarchy in the chips
> have more levels and a library can embrace several levels.
>

Nice resume ! But here there is a little problem. You mixe very
different things. gate-level library are used by the synthetiser to
produice gate-level design (then floor-planning, then masks...). It's
bound to a specific technology, and could be free. But it's a no sense
because it's strongly link to the founder.

Library unit could be interchanged BUT look at the LEON code and try to
change the ALU just to loose some hours on it. Internal stuff are
strongly linked together. You could easly interchanged this unit IF you
made it easy, previously.

Our work is at the VHDL/Verilog level. Not under, it's too dangerous (if the cells library owned by the founder should be free, maybe, you could
never produice a fcpu). Sade, no ?

"Upper level code" are always wrote in hdl, so : no problem.

> Question/problem : the distinction between GPL and LGPL,
> library and program, seems to be unadapted in the microelectronics wor= ld.
> The parallels between HW and SW seem to stop here.
>

Maybe, with the idea of interface you could bypass that limit ?

A part, do you think that Amba licence are really free ?
cf :
http://www.arm.com/sitearchitek/armtech.ns4/h= tml/amba?OpenDocument&style=3DSoC_Customization
(after fill up the formular, you will see the licence)
http://www.opencores.org/wis= hbone/ (cf. link about a patent on it but i
don't see a problem if the licence is clear)

The bus seems to became very popular (and used by the leon). So if we
could use it, it will be great for the acceptance of the project.

> The choice of the GPL was early and it seems to be too late,
> but what do we tell to people who want to integrate the F-CPU
> in their chip, among other (proprietary) blocks ?
>
> regards,
>
> YG
>
> speaking for himself
>
nicO
Yahoo! Groups Spons= or
3D"Be=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Thu Mar 1 00:29:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02621 for ; Thu, 1 Mar 2001 01:45:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:56 +0100 (MET) Received: (qmail 28302 invoked by uid 0); 28 Feb 2001 23:18:13 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx25) with SMTP; 28 Feb 2001 23:18:13 -0000 X-eGroups-Return: sentto-1101623-2460-983402285-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 28 Feb 2001 23:18:06 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 23:18:04 -0000 Received: (qmail 21306 invoked from network); 28 Feb 2001 23:18:03 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 28 Feb 2001 23:18:03 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.137) by mta1 with SMTP; 28 Feb 2001 23:18:00 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C888E9E68 for ; Thu, 1 Mar 2001 00:29:56 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9D89F4.BF69838B@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 00:29:56 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-UIDL: 544736de7cf6ff7df0070da58a8974ce Status: R X-Status: N Guillaume Lederrey a =E9crit :
>
> >Nicolas says that the use of the GPL keeps the implementors
> >from using the F-CPU core(s) inside a "SoC", a chip that= uses
> >"IP blocks" as LEGO bricks. I disagree (Michael too). >
>   I have been reading and not writing much for some
> time, but let me react on this one.  I think one
> question has not been asked.  Do we want to help
> implementors to mix F-CPU and proprietary work ?  To
> my understanding, the goal of the GNU project and the
> GPL is there to promote free software.  I think it is
> well explained on the gnu website
<...>

That's the only good question. Linux could launch proprietary program,
that's allowed. SOC by definition is a complete system. A compagny will
make it by adding some core together (in the futur, by using very high
level description langage where core could be see as actual standart
cells). I work on a system with memories, DSP, LEON, serial link, sram
controler.

If a compagny should always put their core under the GPL licence,
competitor could in few month create the same chip. And the first
compagny will never made any money.

In the other hand, we could see that HW technology run faster than
software technology (a 5 years programmes aren't (so)obsolete), so 4
month lates on the market should be enought for the first comer to win
money.

Beside that compagny as NEC offer technology with lot of macrocells as
MPEG decoder, ethernet transceiver,... It is isn't free but it's hard
macro and strongly linked to their library. So to add a specific
feature, it could be nice to use this proprietary bloc. The best example could be seen in all mixed numeric/analog part (network transceiver,
CAN/CNA, radio transmeter (bluetooth), ...and don't forget the most
critical part : memories). Analog design are (mainly) bound to a
specific technology.

Memory are the best example. Leon have specific entity to describe what
memories bloc to use (virtex bank for fpga, macrocell of the atmel 0.35
um used by the esa). So you could put your owne memory block but, in
fact, it's the block from the founder.

So how can we deal with that ?

nicO
Yahoo! Groups Spons= or
3D"Become=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Thu Mar 1 00:32:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02624 for ; Thu, 1 Mar 2001 01:45:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:57 +0100 (MET) Received: (qmail 28858 invoked by uid 0); 28 Feb 2001 23:20:47 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx11) with SMTP; 28 Feb 2001 23:20:47 -0000 X-eGroups-Return: sentto-1101623-2461-983402443-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 28 Feb 2001 23:20:43 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Feb 2001 23:20:42 -0000 Received: (qmail 22234 invoked from network); 28 Feb 2001 23:20:41 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 28 Feb 2001 23:20:41 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.137) by mta3 with SMTP; 1 Mar 2001 00:21:45 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C64F49E68 for ; Thu, 1 Mar 2001 00:32:36 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9D8A94.44ED09D@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <3A9D89F4.BF69838B@seul.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 00:32:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Amba licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 78efb2aa1ced88f6f0245614ff91f938 Status: R X-Status: N Amba licence :

-------------------------------------
ARM AMBA Specification License

AMBA Specification License

1.Subject to the provisions of Clauses 2 and 3, ARM hereby grants to
LICENSEE a perpetual, non-exclusive, nontransferable, royalty free,
worldwide licence to use and copy the AMBA Specification for the purpose
of developing, having developed, manufacturing, having manufactured,
offering to sell, selling, supplying or otherwise distributing products
which comply with the AMBA Specification.

2.THE AMBA SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES EXPRESS,
IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF
SATISFACTORY QUALITY, MERCHANTABILITY, NONINFRINGEMENT OR FITNESS FOR A
PARTICULAR PURPOSE.

3. No licence, express, implied or otherwise, is granted to LICENSEE,
under the provisions of Clause 1, to use the ARM tradename, or AMBA
trademark in connection with the AMBA Specification or any products
based thereon. Nothing in Clause 1 shall be construed as authority for
LICENSEE to make any representations on behalf of ARM in respect of the
AMBA Specification.
Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Thu Mar 1 01:32:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02630 for ; Thu, 1 Mar 2001 01:45:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:58 +0100 (MET) Received: (qmail 5799 invoked by uid 0); 1 Mar 2001 00:25:35 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx01) with SMTP; 1 Mar 2001 00:25:35 -0000 X-eGroups-Return: sentto-1101623-2462-983406334-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 01 Mar 2001 00:25:34 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 00:25:33 -0000 Received: (qmail 19816 invoked from network); 1 Mar 2001 00:25:33 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 1 Mar 2001 00:25:33 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 1 Mar 2001 01:26:37 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id 3203E3BD009 for ; Wed, 28 Feb 2001 19:32:04 -0500 (EST) To: "f-cpu@yahoogroups.com" In-Reply-To: <200102282251.f1SMpOF20156@mail.swissonline.ch> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Feb 2001 19:32:03 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: f24dc1178aaaa4da6a95a38e63e82723 Status: R X-Status: N
>   So I dont think the question should be "which
> lisence do we choose so implementors could mix our
> work with proprietary work" but "do we want to make it
> easy for implementors to mix our work with proprietary
> work".  That is too : do we want to have a F-CPU
> widely used, or do we want a F-CPU that promote free
> hardware ?
>
>   Sorry, I might have been a little long ...
>
>       Guillaume

I believe people should be allowed to own software and hardware.  VHDL and
source code are the only ways to get that.  They're not the most
convenient, but they are the most complete.  As a result I can't agree
with using the LGPL, though I do have problems with the GPL as well.

> * * * * * * * * * * * * * * * * * * * *
>
> One can search the brain with a microscope and
> not find the mind, and can search the stars with
> a telescope and not find God.
>
>             -- J. Gustav White
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Yahoo! Groups Sponsor
Become a Better Trader!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Thu Mar 1 01:26:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02633 for ; Thu, 1 Mar 2001 01:45:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 01:45:59 +0100 (MET) Received: (qmail 30085 invoked by uid 0); 1 Mar 2001 00:28:22 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx03) with SMTP; 1 Mar 2001 00:28:22 -0000 X-eGroups-Return: sentto-1101623-2463-983406480-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 01 Mar 2001 00:28:01 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 00:27:59 -0000 Received: (qmail 25907 invoked from network); 1 Mar 2001 00:27:59 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 1 Mar 2001 00:27:59 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.130) by mta1 with SMTP; 1 Mar 2001 00:27:58 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01790; Thu, 1 Mar 2001 01:27:55 +0100 Message-ID: <20010301012634.54515@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> X-Mailer: Mutt 0.84e In-Reply-To: <200102282251.f1SMpOF20156@mail.swissonline.ch>; from Guillaume Lederrey on Wed, Feb 28, 2001 at 11:58:57PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 01:26:34 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UIDL: 54b2e6bde57d5e21ec36d59389122572 Status: R X-Status: N On Wed, Feb 28, 2001 at 11:58:57PM +0100, Guillaume Lederrey wrote:
> >Nicolas says that the use of the GPL keeps the implementors
> >from using the F-CPU core(s) inside a "SoC", a chip that uses
> >"IP blocks" as LEGO bricks. I disagree (Michael too).

No, wait - that's not true.  It *does* keep implementors from using
the F-CPU core(s) inside a "SoC", together with proprietary IP.

>   I have been reading and not writing much for some
> time, but let me react on this one.  I think one
> question has not been asked.  Do we want to help
> implementors to mix F-CPU and proprietary work ?  [...]

At least I don't want to. And that's the reason why I prefer the GPL.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Go to TravelWorm

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Richard Stallman Thu Mar 1 11:57:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00293 for ; Thu, 1 Mar 2001 16:26:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:26:56 +0100 (MET) Received: (qmail 29942 invoked by uid 0); 1 Mar 2001 10:57:06 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx01) with SMTP; 1 Mar 2001 10:57:06 -0000 X-eGroups-Return: sentto-1101623-2464-983444224-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 01 Mar 2001 10:57:05 -0000 X-Sender: rms@santafe.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 10:57:04 -0000 Received: (qmail 86526 invoked from network); 1 Mar 2001 10:57:03 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 1 Mar 2001 10:57:03 -0000 Received: from unknown (HELO pele.santafe.edu) (192.12.12.119) by mta2 with SMTP; 1 Mar 2001 10:57:03 -0000 Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.9.3/8.9.1) with ESMTP id DAA22348; Thu, 1 Mar 2001 03:57:02 -0700 (MST) Received: (from rms@localhost) by aztec.santafe.edu (8.9.3+Sun/8.9.1) id DAA20094; Thu, 1 Mar 2001 03:57:02 -0700 (MST) Message-Id: <200103011057.DAA20094@aztec.santafe.edu> X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec.santafe.edu using -f To: whygee@f-cpu.org Cc: f-cpu@yahoogroups.com In-reply-to: <3A9D1798.8E121E0D@mentor.com> (message from Yann GUIDON on Wed, 28 Feb 2001 16:22:00 +0100) References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <200102280433.VAA16362@aztec.santafe.edu> <3A9D1798.8E121E0D@mentor.com> From: Richard Stallman MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 03:57:02 -0700 (MST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N     The discussion fired when the issue GPL vs LGPL
    was brought. the ESA/LEON uses LGPL because they

Ok, so ESA/LEON uses the LGPL.

]
    Nicolas says that the use of the GPL keeps the implementors

You say "the use of the GPL", but there isn't any use of the GPL in
this scenario.  You have only told me about one package, ESA/LEON, and
it does NOT use the GPL.

Because of this apparent contradiction, which I was unable to
reconcile, I was not able to understand the rest of your message.
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Thu Mar 1 12:25:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00299 for ; Thu, 1 Mar 2001 16:26:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:26:58 +0100 (MET) Received: (qmail 10768 invoked by uid 0); 1 Mar 2001 11:19:25 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx18) with SMTP; 1 Mar 2001 11:19:25 -0000 X-eGroups-Return: sentto-1101623-2465-983445563-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 01 Mar 2001 11:19:23 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 11:19:22 -0000 Received: (qmail 54299 invoked from network); 1 Mar 2001 11:19:22 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 1 Mar 2001 11:19:22 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta3 with SMTP; 1 Mar 2001 12:20:26 -0000 Received: from moonbase.res.wpi.net (moonbase.res.wpi.net [130.215.231.27]) by moonbase.res.wpi.net (Postfix) with ESMTP id C7EC210002D; Thu, 1 Mar 2001 06:25:56 -0500 (EST) To: f-cpu@yahoogroups.com Cc: whygee@f-cpu.org In-Reply-To: <200103011057.DAA20094@aztec.santafe.edu> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 06:25:56 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 1 Mar 2001, Richard Stallman wrote:

>     The discussion fired when the issue GPL vs LGPL
>     was brought. the ESA/LEON uses LGPL because they
>
> Ok, so ESA/LEON uses the LGPL.
>
> ]
>     Nicolas says that the use of the GPL keeps the implementors
>
> You say "the use of the GPL", but there isn't any use of the GPL in
> this scenario.  You have only told me about one package, ESA/LEON, and
> it does NOT use the GPL.

He switches between specific and general contexts like that.

> Because of this apparent contradiction, which I was unable to
> reconcile, I was not able to understand the rest of your message.
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 1 13:37:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00308 for ; Thu, 1 Mar 2001 16:27:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:27:00 +0100 (MET) Received: (qmail 5004 invoked by uid 0); 1 Mar 2001 12:44:42 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx08) with SMTP; 1 Mar 2001 12:44:42 -0000 X-eGroups-Return: sentto-1101623-2466-983450679-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 01 Mar 2001 12:44:40 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 12:44:38 -0000 Received: (qmail 67617 invoked from network); 1 Mar 2001 12:44:37 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 1 Mar 2001 12:44:37 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 1 Mar 2001 12:44:36 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA25472; Thu, 1 Mar 2001 04:44:32 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8CPS; Thu, 1 Mar 2001 12:49:51 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9E4298.766295A6@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: rms@gnu.org Cc: "f-cpu@egroups.com" References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <200102280433.VAA16362@aztec.santafe.edu> <3A9D1798.8E121E0D@mentor.com> <200103011057.DAA20094@aztec.santafe.edu> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 13:37:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Richard Stallman wrote:
>
>     The discussion fired when the issue GPL vs LGPL
>     was brought. the ESA/LEON uses LGPL because they
>
> Ok, so ESA/LEON uses the LGPL.
>
> ]
>     Nicolas says that the use of the GPL keeps the implementors
>
> You say "the use of the GPL", but there isn't any use of the GPL in
> this scenario.  You have only told me about one package, ESA/LEON, and
> it does NOT use the GPL.
>
> Because of this apparent contradiction, which I was unable to
> reconcile, I was not able to understand the rest of your message.


Sorry if this was unclear ...

ESA/LEON -> LGPL
F-CPU -> GPL

Unfortunately, the situation is more complex than the facts.
We have reached the limits of the SW/HW similarities
and we need help to clear the situation : what happens
to a "HW design" distributed with the sources released under GPL.
what are the differences with a HW design with the sources
released under LGPL ?

What is, in our situation, a "library", what does differentiate
a "program" from a "library", how much can we play with the
hierarchies ?

regards,

YG

speaking for himself
Yahoo! Groups Sponsor
3 DVDs for ONLY 49 cents each!
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 1 13:43:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00311 for ; Thu, 1 Mar 2001 16:27:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:27:01 +0100 (MET) Received: (qmail 27138 invoked by uid 0); 1 Mar 2001 12:50:17 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx13) with SMTP; 1 Mar 2001 12:50:17 -0000 X-eGroups-Return: sentto-1101623-2467-983451014-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 01 Mar 2001 12:50:16 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 12:50:14 -0000 Received: (qmail 80274 invoked from network); 1 Mar 2001 12:50:13 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 1 Mar 2001 12:50:13 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 1 Mar 2001 13:51:16 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA26072; Thu, 1 Mar 2001 04:50:09 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8CQF; Thu, 1 Mar 2001 12:55:29 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9E43EA.151D2940@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <3A9D89F4.BF69838B@seul.org> <3A9D8A94.44ED09D@seul.org> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 13:43:22 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Amba licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nicolas wrote:
>
> Amba licence :
>
> -------------------------------------
> ARM AMBA Specification License
>
> AMBA Specification License
>
> 1.Subject to the provisions of Clauses 2 and 3, ARM hereby grants to
> LICENSEE a perpetual, non-exclusive, nontransferable, royalty free,
> worldwide licence to use and copy the AMBA Specification for the purpose
> of developing, having developed, manufacturing, having manufactured,
> offering to sell, selling, supplying or otherwise distributing products
> which comply with the AMBA Specification.
>
> 2.THE AMBA SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES EXPRESS,
> IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF
> SATISFACTORY QUALITY, MERCHANTABILITY, NONINFRINGEMENT OR FITNESS FOR A
> PARTICULAR PURPOSE.
>
> 3. No licence, express, implied or otherwise, is granted to LICENSEE,
> under the provisions of Clause 1, to use the ARM tradename, or AMBA
> trademark in connection with the AMBA Specification or any products
> based thereon. Nothing in Clause 1 shall be construed as authority for
> LICENSEE to make any representations on behalf of ARM in respect of the
> AMBA Specification.
>

wow, THAT is a short licence.
however it is probably TOO short, it may miss some points,
specifically about redistribution etc.
Maybe i'm too used to the usual "long" GPL.

Question : is this licence compatible with the GPL ?

YG

speaking for himself
Yahoo! Groups Sponsor
3 DVDs for ONLY 49 cents each!
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 1 14:17:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00323 for ; Thu, 1 Mar 2001 16:27:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:27:04 +0100 (MET) Received: (qmail 32064 invoked by uid 0); 1 Mar 2001 13:25:22 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx08) with SMTP; 1 Mar 2001 13:25:22 -0000 X-eGroups-Return: sentto-1101623-2468-983453109-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ci.egroups.com with NNFMP; 01 Mar 2001 13:25:09 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 13:25:08 -0000 Received: (qmail 90446 invoked from network); 1 Mar 2001 13:24:49 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 1 Mar 2001 13:24:49 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 1 Mar 2001 13:24:49 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA29341; Thu, 1 Mar 2001 05:24:46 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8CR7; Thu, 1 Mar 2001 13:30:06 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9E4C07.412264E9@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 14:17:59 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

As i had forecast it, this discussion is indeed getting very interesting :-)

Michael Riepe wrote:
> On Wed, Feb 28, 2001 at 11:58:57PM +0100, Guillaume Lederrey wrote:
> > >Nicolas says that the use of the GPL keeps the implementors
> > >from using the F-CPU core(s) inside a "SoC", a chip that uses
> > >"IP blocks" as LEGO bricks. I disagree (Michael too).
> No, wait - that's not true.  It *does* keep implementors from using
> the F-CPU core(s) inside a "SoC", together with proprietary IP.

however i don't see "how".
As long as the implementor complies with the GPL and the charter,
mainly for the source redistribution/modification etc,
i see no reason to keep anyone from integrating the core,
even in a washing machine. remember the word ? "freedom"...

I think that now we have to ask these questions :
- do we want to keep people from using F-CPU in a SoC ?
- do we want to discriminate against "proprietary SoC" implementors ?

let's not misunderstand the "goals" and the "means".
The goal is pretty clear : we want to design a very good (the best !) CPU.
The means depends on the side effects. We want to promote Free Software,
not "only" providing gratis IP. Does that mean that we must forbid
the connexion to proprietary HW ?

At one point or another, proprietary stuff must speak to free stuff and
vice versa. If we are too much "integrist", nothing will be able
to communicate with the F-CPU and it will die. Imagine that we
couldn't even connect the core to RAM ...
If we are too lax OTOH, the situation will get out of hand.

My point of view is that the inside of the CPU core is GPL,
the outside is up to the end user. "The system is the core".
If the end user wants to support a proprietary interface,
the necessary modifications to the core must be redistributed as well.
it looks simple for me.

If we make a truely  "free"  f-cpu chip, will we be allowed
to attach it to SDRAM (proprietary) ??? I see no distinction
between off-chip and on-chip connexion. Since "SoC" is a matter
of hierarchy and scale (larger scale integration that allows
several "cores" to cohabit in the same chip), i see no more reason
to prohibit F-CPU-based SoCs than to prohibit F-CPU chips from
communicating with IDE HDD or SDRAM or FLASH or Ethernet or PCMCIA or....

For me it's not a matter of hierarchy or scale, but a matter of what
is connected to what, and the conditions under which the core is modified.
Does that sound reasonable ?

> >   I have been reading and not writing much for some
> > time, but let me react on this one.  I think one
> > question has not been asked.  Do we want to help
> > implementors to mix F-CPU and proprietary work ?  [...]
the question can be reversed : "Do we want to forbid
implementors to mix F-CPU and proprietary work ?"
the "freedom" word says no. however, this comes under restricted
conditions that we can fine-tune now.

> At least I don't want to. And that's the reason why I prefer the GPL.
I still am an utopist : i hope that the F-CPU can help the industry
understand the advantages of openness and cooperation/collaboration.
Whatever you want, or hope, i doubt that a real "free computer" will
ever exist : proprietary techniques and patented functions will
always remain at one point or another. Even a "free" f-cpu chip
will use proprietary silicon manufacturing techniques.
However i don't want to send any signal saying : "rip us off !"
like the LEON does. LEON looks like a "give-away design" to me.
hence the GPL on my designs.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"

YG

speaking for himself
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 1 14:21:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00326 for ; Thu, 1 Mar 2001 16:27:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:27:05 +0100 (MET) Received: (qmail 13703 invoked by uid 0); 1 Mar 2001 13:28:42 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx18) with SMTP; 1 Mar 2001 13:28:42 -0000 X-eGroups-Return: sentto-1101623-2469-983453320-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 01 Mar 2001 13:28:41 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 13:28:40 -0000 Received: (qmail 99473 invoked from network); 1 Mar 2001 13:28:20 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 1 Mar 2001 13:28:20 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 1 Mar 2001 13:28:20 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA29711; Thu, 1 Mar 2001 05:28:18 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8CSJ; Thu, 1 Mar 2001 13:33:38 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9E4CDB.B951F57F@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 14:21:31 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] new mailing list proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

I propose to open a new mailing list that will deal with
the compiler. It will be certainly hosted by seul.org.

- who is interested and wants to subscribe ?
- who would like to administrate the list ?
- any remark/suggestion ?

i have not yet asked seul.org, this mail is
a simple "request for comments".

YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 1 15:31:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00347 for ; Thu, 1 Mar 2001 16:27:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 16:27:10 +0100 (MET) Received: (qmail 10414 invoked by uid 0); 1 Mar 2001 14:40:49 -0000 Received: from mx18.rz2.gmx.net (HELO b05.egroups.com) (10.1.72.118) by mxi1.gmx.net (mxi1) with SMTP; 1 Mar 2001 14:40:49 -0000 X-eGroups-Return: sentto-1101623-2470-983457629-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by b05.egroups.com with NNFMP; 01 Mar 2001 14:40:30 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 14:40:28 -0000 Received: (qmail 75760 invoked from network); 1 Mar 2001 14:40:26 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 1 Mar 2001 14:40:26 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 1 Mar 2001 15:41:30 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA07163; Thu, 1 Mar 2001 06:40:18 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8CVG; Thu, 1 Mar 2001 14:43:33 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3A9E5D3F.32437AFE@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <3A9D89F4.BF69838B@seul.org> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 15:31:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

maybe i'll leave Netscape and start writing some code....
but before that ... :-)

Nicolas wrote:
> Guillaume Lederrey a =E9crit :
> > >Nicolas says that the use of the GPL keeps the implementors > > >from using the F-CPU core(s) inside a "SoC", a chip= that uses
> > >"IP blocks" as LEGO bricks. I disagree (Michael too= ).
> >
> >   I have been reading and not writing much for some
> > time, but let me react on this one.  I think one
> > question has not been asked.  Do we want to help
> > implementors to mix F-CPU and proprietary work ?  To
> > my understanding, the goal of the GNU project and the
> > GPL is there to promote free software.  I think it is
> > well explained on the gnu website
> <...>
>
> That's the only good question. Linux could launch proprietary program,=
> that's allowed. SOC by definition is a complete system.
no, it's a "marketing" term. it won't stand a minute before a cou= rt.

> A compagny will
> make it by adding some core together (in the futur, by using very high=
> level description langage where core could be see as actual standart > cells). I work on a system with memories, DSP, LEON, serial link, sram=
> controler.
congratulations. but can you tell me what is wrong with the GPL, can you quote the terms which prohibit the integration in another system ?

> If a compagny should always put their core under the GPL licence,
> competitor could in few month create the same chip. And the first
> compagny will never made any money.
that is a "short-sighted" comment. i've heard it many time and i = learnt
to deal with it, but i guess that you know my pointof view (reciprocity) :<= BR> if you can copy your competitor, he can copy you and vice versa, so
"And the first compagny will never made any money." is bogus : RedHat would never succeed otherwise ! I leave the rest of the demonstratio= n
to the APRIL/FSF  integrists ;-)

> In the other hand, we could see that HW technology run faster than
> software technology (a 5 years programmes aren't (so)obsolete), so 4 > month lates on the market should be enought for the first comer to win=
> money.
that's what i always bring to the foreground when i speak to industrial
people. this is a very critical argument : "time to market" is on= e
of their most important preoccupations.

> Beside that compagny as NEC offer technology with lot of macrocells as=
> MPEG decoder, ethernet transceiver,... It is isn't free but it's hard<= BR> > macro and strongly linked to their library. So to add a specific
> feature, it could be nice to use this proprietary bloc.
or stuff from OpenCores (if that works).

> The best example
> could be seen in all mixed numeric/analog part (network transceiver, > CAN/CNA, radio transmeter (bluetooth), ...and don't forget the most > critical part : memories). Analog design are (mainly) bound to a
> specific technology.

just a matter of good sense : how do you put a CAN/CNA on a chip with a CPU=
that runs at x00 MHz ? don't you fear some ... noise ? interferences ?...
> Memory are the best example. Leon have specific entity to describe wha= t
> memories bloc to use (virtex bank for fpga, macrocell of the atmel 0.3= 5
> um used by the esa). So you could put your owne memory block but, in > fact, it's the block from the founder.
>
> So how can we deal with that ?

what do you want to deal with ?
you want memory, take it. it's your freedom.
you want to modify the F-CPU core ? redistribute the sources. it's your dut= y.

what more do you want ? a doctorate thesis from a lawyer ???

have fun, and probably : see you this evening at the sous-bock
(http://linuxfr.org/bouff= e/mensuelle/)

> nicO

YG

speaking for himself
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Thu Mar 1 17:50:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01579 for ; Thu, 1 Mar 2001 18:09:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 18:09:29 +0100 (MET) Received: (qmail 23575 invoked by uid 0); 1 Mar 2001 16:50:30 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx16) with SMTP; 1 Mar 2001 16:50:30 -0000 X-eGroups-Return: sentto-1101623-2471-983465428-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mq.egroups.com with NNFMP; 01 Mar 2001 16:50:29 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 16:50:27 -0000 Received: (qmail 92050 invoked from network); 1 Mar 2001 16:50:24 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 1 Mar 2001 16:50:24 -0000 Received: from unknown (HELO postfix2-2.free.fr) (213.228.0.140) by mta3 with SMTP; 1 Mar 2001 17:51:28 -0000 Received: from free.fr (nas-cbv-1-6-110.dial.proxad.net [213.228.6.110]) by postfix2-2.free.fr (Postfix) with ESMTP id 8A76D6B7BF for ; Thu, 1 Mar 2001 17:50:21 +0100 (CET) Message-ID: <3A9E7DE2.2070607@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3A9E4CDB.B951F57F@mentor.com> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 01 Mar 2001 17:50:42 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] new mailing list proposal Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

Yann GUIDON wrote:

> Hello,
>
> I propose to open a new mailing list that will deal with
> the compiler. It will be certainly hosted by seul.org.
>
> - who is interested and wants to subscribe ?
I will be interrested

> - who would like to administrate the list ?
> - any remark/suggestion ?
>
> i have not yet asked seul.org, this mail is
> a simple "request for comments".
>
> YG
>
> speaking for himself
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From boucli27@altavista.net Thu Mar 1 18:13:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01852 for ; Thu, 1 Mar 2001 20:42:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 01 Mar 2001 20:42:21 +0100 (MET) Received: (qmail 23450 invoked by uid 0); 1 Mar 2001 17:14:33 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx16) with SMTP; 1 Mar 2001 17:14:33 -0000 X-eGroups-Return: sentto-1101623-2472-983466840-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 01 Mar 2001 17:14:01 -0000 X-Sender: boucli27@altavista.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 17:13:59 -0000 Received: (qmail 80932 invoked from network); 1 Mar 2001 17:13:58 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 1 Mar 2001 17:13:58 -0000 Received: from unknown (HELO rmx614-mta.mail.com) (165.251.48.52) by mta1 with SMTP; 1 Mar 2001 17:13:58 -0000 Received: from weba7.iname.net (weba07.mail.com [165.251.4.17]) by rmx614-mta.mail.com (8.9.3/8.9.3) with ESMTP id MAA17701 for ; Thu, 1 Mar 2001 12:13:56 -0500 (EST) Received: (from root@localhost) by weba7.iname.net (8.9.1a/8.9.2.Alpha2) id MAA26300; Thu, 1 Mar 2001 12:13:52 -0500 (EST) Message-Id: <010301121352G5.09977@weba7.iname.net> To: f-cpu@yahoogroups.com From: boucli27@altavista.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 12:13:52 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Amba licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >Question : is this licence compatible with the GPL ?
Answer: This word: "nontransferable" says it all.

IMHO this is incompatible with the GPL licence.


#########################################

Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
boucli27@altavista.net
http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html
http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html
06 68 99 65 89
----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Thu Mar 1 19:45:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00345 for ; Fri, 2 Mar 2001 20:37:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:31 +0100 (MET) Received: (qmail 14305 invoked by uid 0); 1 Mar 2001 22:56:00 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx19) with SMTP; 1 Mar 2001 22:56:00 -0000 X-eGroups-Return: sentto-1101623-2473-983487358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fj.egroups.com with NNFMP; 01 Mar 2001 22:55:59 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 22:55:56 -0000 Received: (qmail 62261 invoked from network); 1 Mar 2001 22:55:53 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 1 Mar 2001 22:55:53 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.208) by mta2 with SMTP; 1 Mar 2001 22:55:51 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00477; Thu, 1 Mar 2001 19:45:46 +0100 Message-ID: <20010301194546.13488@thrai.stud.uni-hannover.de> To: F-CPU Mailing List References: <20010206031040.63950@thrai.stud.uni-hannover.de> <200102080321.WAA32306@moria.mit.edu> <20010208235947.65481@thrai.stud.uni-hannover.de> X-Mailer: Mutt 0.84e In-Reply-To: <20010208235947.65481@thrai.stud.uni-hannover.de>; from Michael Riepe on Thu, Feb 08, 2001 at 11:59:47PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 19:45:46 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Reminder: CVS passwords for seul.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, Feb 08, 2001 at 11:59:47PM +0100, I asked everybody who needs
write access to the CVS on seul.org do send me an encrypted password.
So far, I received only a single one (from Yann).  Please use the
attached perl script to encrypt your password and send it to me --
just copy it to a file, run the command: "perl name-of-file password"
and mail the output to <michael@stud.uni-hannover.de>.

------- perl script -------
#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65: 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";
------- perl script -------

Thank you for your attention,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Mar 2 00:51:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00351 for ; Fri, 2 Mar 2001 20:37:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:33 +0100 (MET) Received: (qmail 7696 invoked by uid 0); 1 Mar 2001 23:41:20 -0000 Received: from mx14.rz2.gmx.net (HELO c3.egroups.com) (10.1.72.114) by mxi1.gmx.net (mxi1) with SMTP; 1 Mar 2001 23:41:20 -0000 X-eGroups-Return: sentto-1101623-2474-983489945-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 01 Mar 2001 23:39:06 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 23:39:05 -0000 Received: (qmail 89527 invoked from network); 1 Mar 2001 23:39:05 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 1 Mar 2001 23:39:05 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.171.4) by mta2 with SMTP; 1 Mar 2001 23:39:04 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C98089E68 for ; Fri, 2 Mar 2001 00:51:05 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9EE069.376B8451@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <3A9D89F4.BF69838B@seul.org> <3A9D8A94.44ED09D@seul.org> <3A9E43EA.151D2940@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Mar 2001 00:51:05 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Amba licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann GUIDON a =E9crit :
>
> Nicolas wrote:
> >
> > Amba licence :
> >
> > -------------------------------------
> > ARM AMBA Specification License
> >
> > AMBA Specification License
> >
> > 1.Subject to the provisions of Clauses 2 and 3, ARM hereby grants= to
> > LICENSEE a perpetual, non-exclusive, nontransferable, royalty fre= e,
> > worldwide licence to use and copy the AMBA Specification for the = purpose
> > of developing, having developed, manufacturing, having manufactur= ed,
> > offering to sell, selling, supplying or otherwise distributing pr= oducts
> > which comply with the AMBA Specification.
> >
> > 2.THE AMBA SPECIFICATION IS PROVIDED "AS IS" WITH NO WA= RRANTIES EXPRESS,
> > IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY O= F
> > SATISFACTORY QUALITY, MERCHANTABILITY, NONINFRINGEMENT OR FITNESS= FOR A
> > PARTICULAR PURPOSE.
> >
> > 3. No licence, express, implied or otherwise, is granted to LICEN= SEE,
> > under the provisions of Clause 1, to use the ARM tradename, or AM= BA
> > trademark in connection with the AMBA Specification or any produc= ts
> > based thereon. Nothing in Clause 1 shall be construed as authorit= y for
> > LICENSEE to make any representations on behalf of ARM in respect = of the
> > AMBA Specification.
> >
>
> wow, THAT is a short licence.
> however it is probably TOO short, it may miss some points,
> specifically about redistribution etc.
> Maybe i'm too used to the usual "long" GPL.
>
> Question : is this licence compatible with the GPL ?

That's my question ! Amba will be nice for the f-cpu.

>
> YG
nicO
>
> speaking for himself
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Choose
Click for Detai= ls
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Mar 2 00:59:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00354 for ; Fri, 2 Mar 2001 20:37:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:34 +0100 (MET) Received: (qmail 27680 invoked by uid 0); 1 Mar 2001 23:49:52 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx09) with SMTP; 1 Mar 2001 23:49:52 -0000 X-eGroups-Return: sentto-1101623-2475-983490454-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hh.egroups.com with NNFMP; 01 Mar 2001 23:47:35 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 23:47:34 -0000 Received: (qmail 65601 invoked from network); 1 Mar 2001 23:47:33 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 1 Mar 2001 23:47:33 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.171.4) by mta3 with SMTP; 2 Mar 2001 00:48:37 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 343319E68 for ; Fri, 2 Mar 2001 00:59:34 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9EE266.F703CCC0@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Mar 2001 00:59:34 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann GUIDON a =E9crit :
>
> hi !
>
> As i had forecast it, this discussion is indeed getting very interesti= ng :-)
>
> Michael Riepe wrote:
<...>
> If we make a truely  "free"  f-cpu chip, will we b= e allowed
> to attach it to SDRAM (proprietary) ??? I see no distinction
> between off-chip and on-chip connexion. Since "SoC" is a mat= ter
> of hierarchy and scale (larger scale integration that allows
> several "cores" to cohabit in the same chip), i see no more = reason
> to prohibit F-CPU-based SoCs than to prohibit F-CPU chips from
> communicating with IDE HDD or SDRAM or FLASH or Ethernet or PCMCIA or.= ...
>

There's ONE big difference. In a board system, you manipulate object
that cost somethings (to the producer). Then In SOC, you could have HARD IP (a layout of soon compiled and placed&routed design) that could be seen as the "object" but it's always only datas (with no cost of<= BR> duplication)! If you add some proprietary code you mixed 2 HDL code. And link GPL code with none compatible GPL is forbbiden.


> >  Michael "Tired" Riepe <Michael.Riepe@stud.uni-= hannover.de>
> >  "All I wanna do is have a little fun before I die"= ;
>
> YG
nicO
Yahoo! Groups Spons= or
3D"3
Click for Det= ails
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Mar 2 01:12:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00369 for ; Fri, 2 Mar 2001 20:37:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:38 +0100 (MET) Received: (qmail 21958 invoked by uid 0); 2 Mar 2001 00:01:06 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx10) with SMTP; 2 Mar 2001 00:01:06 -0000 X-eGroups-Return: sentto-1101623-2477-983491225-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 02 Mar 2001 00:00:26 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 2 Mar 2001 00:00:25 -0000 Received: (qmail 28981 invoked from network); 2 Mar 2001 00:00:24 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 2 Mar 2001 00:00:24 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.171.4) by mta2 with SMTP; 2 Mar 2001 00:00:23 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 51FA39E68 for ; Fri, 2 Mar 2001 01:12:25 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9EE569.EDF408BB@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <010301121352G5.09977@weba7.iname.net> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Mar 2001 01:12:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Amba licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N boucli27@altavista.net a =E9crit :
>
> >Question : is this licence compatible with the GPL ?
> Answer: This word: "nontransferable" says it all.
>
> IMHO this is incompatible with the GPL licence.

Snif, some lobbying to do ?

nicO
>
> #########################################
>
> Lionel, trollhunter Bouchpan-Lerust-Juery
> trollhunter@linuxfr.org
> boucli27@altavista.net
> http://infonomade.linuxfr.org/wearables/doc/Wearabl= e-HOWTO/en/Wearable-HOWTO.html
> http://www.= linuxdoc.org/HOWTO/SPARC-HOWTO.html
> 06 68 99 65 89
> ----------------------------------------------------------------
> Get your free email from AltaVista at http://altavista.iname.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Click
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Mar 2 01:08:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00372 for ; Fri, 2 Mar 2001 20:37:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:38 +0100 (MET) Received: (qmail 23568 invoked by uid 0); 1 Mar 2001 23:58:02 -0000 Received: from mx19.rz2.gmx.net (HELO ml.egroups.com) (10.1.72.119) by mxi1.gmx.net (mxi1) with SMTP; 1 Mar 2001 23:58:02 -0000 X-eGroups-Return: sentto-1101623-2476-983490985-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 01 Mar 2001 23:56:26 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 1 Mar 2001 23:56:25 -0000 Received: (qmail 19568 invoked from network); 1 Mar 2001 23:56:24 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 1 Mar 2001 23:56:24 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.171.4) by mta3 with SMTP; 2 Mar 2001 00:57:28 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 42F149E68 for ; Fri, 2 Mar 2001 01:08:25 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3A9EE479.D290434D@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <3A9D89F4.BF69838B@seul.org> <3A9E5D3F.32437AFE@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 02 Mar 2001 01:08:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann GUIDON a =E9crit :
>
> hi !
>
> maybe i'll leave Netscape and start writing some code....
> but before that ... :-)
>
> Nicolas wrote:
> > Guillaume Lederrey a =E9crit :
> > > >Nicolas says that the use of the GPL keeps the implement= ors
> > > >from using the F-CPU core(s) inside a "SoC", a= chip that uses
> > > >"IP blocks" as LEGO bricks. I disagree (Michae= l too).
> > >
> > >   I have been reading and not writing much for som= e
> > > time, but let me react on this one.  I think one
> > > question has not been asked.  Do we want to help
> > > implementors to mix F-CPU and proprietary work ?  To > > > my understanding, the goal of the GNU project and the
> > > GPL is there to promote free software.  I think it is > > > well explained on the gnu website
> > <...>
> >
> > That's the only good question. Linux could launch proprietary pro= gram,
> > that's allowed. SOC by definition is a complete system.
> no, it's a "marketing" term. it won't stand a minute before = a court.
>
> > A compagny will
> > make it by adding some core together (in the futur, by using very= high
> > level description langage where core could be see as actual stand= art
> > cells). I work on a system with memories, DSP, LEON, serial link,= sram
> > controler.
> congratulations. but can you tell me what is wrong with the GPL, can y= ou
> quote the terms which prohibit the integration in another system ?
>
> > If a compagny should always put their core under the GPL licence,=
> > competitor could in few month create the same chip. And the first=
> > compagny will never made any money.
> that is a "short-sighted" comment. i've heard it many time a= nd i learnt
> to deal with it, but i guess that you know my pointof view (reciprocit= y) :
> if you can copy your competitor, he can copy you and vice versa, so > "And the first compagny will never made any money." is bogus= :
> RedHat would never succeed otherwise ! I leave the rest of the demonst= ration
> to the APRIL/FSF  integrists ;-)
>

Not really, if the first one really develop a new GPL core (MPEG4 for
example). What happen if it's simply copied by an other compagny (with a better fab) ?

> > In the other hand, we could see that HW technology run faster tha= n
> > software technology (a 5 years programmes aren't (so)obsolete), s= o 4
> > month lates on the market should be enought for the first comer t= o win
> > money.
> that's what i always bring to the foreground when i speak to industria= l
> people. this is a very critical argument : "time to market" = is one
> of their most important preoccupations.
>
> > Beside that compagny as NEC offer technology with lot of macrocel= ls as
> > MPEG decoder, ethernet transceiver,... It is isn't free but it's = hard
> > macro and strongly linked to their library. So to add a specific<= BR> > > feature, it could be nice to use this proprietary bloc.
> or stuff from OpenCores (if that works).
>

If that works ;p (and finished !)

> > The best example
> > could be seen in all mixed numeric/analog part (network transceiv= er,
> > CAN/CNA, radio transmeter (bluetooth), ...and don't forget the mo= st
> > critical part : memories). Analog design are (mainly) bound to a<= BR> > > specific technology.
>
> just a matter of good sense : how do you put a CAN/CNA on a chip with = a CPU
> that runs at x00 MHz ? don't you fear some ... noise ? interferences ?= ...
>

Yes that the problem but have you never heard about gsm in a single chip or bluetooth with a microcontroleur or in a simple microcontroler the
CNA(HC11, DSP).

There are lot of technique to do it.

> > Memory are the best example. Leon have specific entity to describ= e what
> > memories bloc to use (virtex bank for fpga, macrocell of the atme= l 0.35
> > um used by the esa). So you could put your owne memory block but,= in
> > fact, it's the block from the founder.
> >
> > So how can we deal with that ?
>
> what do you want to deal with ?
> you want memory, take it. it's your freedom.
> you want to modify the F-CPU core ? redistribute the sources. it's you= r duty.
>
> what more do you want ? a doctorate thesis from a lawyer ???

Always the same : mixed Proprietary IP and the fcpu is are not
possible/a problem/wanted...

>
> have fun, and probably : see you this evening at the sous-bock
> (http://linuxfr.org/= bouffe/mensuelle/)
>
> > nicO
>
> YG
nicO
Yahoo! Groups Spons= or
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Richard Stallman Fri Mar 2 04:12:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00399 for ; Fri, 2 Mar 2001 20:37:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 02 Mar 2001 20:37:51 +0100 (MET) Received: (qmail 15725 invoked by uid 0); 2 Mar 2001 03:12:35 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx21) with SMTP; 2 Mar 2001 03:12:35 -0000 X-eGroups-Return: sentto-1101623-2478-983502749-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 02 Mar 2001 03:12:30 -0000 X-Sender: rms@santafe.edu X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 2 Mar 2001 03:12:28 -0000 Received: (qmail 60081 invoked from network); 2 Mar 2001 03:12:26 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 2 Mar 2001 03:12:26 -0000 Received: from unknown (HELO pele.santafe.edu) (192.12.12.119) by mta1 with SMTP; 2 Mar 2001 03:12:26 -0000 Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.9.3/8.9.1) with ESMTP id UAA24927; Thu, 1 Mar 2001 20:12:24 -0700 (MST) Received: (from rms@localhost) by aztec.santafe.edu (8.9.3+Sun/8.9.1) id UAA25092; Thu, 1 Mar 2001 20:12:24 -0700 (MST) Message-Id: <200103020312.UAA25092@aztec.santafe.edu> X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec.santafe.edu using -f To: whygee@f-cpu.org Cc: f-cpu@yahoogroups.com In-reply-to: <3A9E4298.766295A6@mentor.com> (message from Yann GUIDON on Thu, 01 Mar 2001 13:37:44 +0100) References: <3A970BC9.D043DD8D@f-cpu.org> <3A97B966.F8F934E1@seul.org> <20010224150717.26870@thrai.stud.uni-hannover.de> <3A9918B0.E2D8B715@seul.org> <3A995654.994BDDBD@f-cpu.org> <3A9AB3C9.7DFB1FC6@seul.org> <3A9B9431.913A2443@mentor.com> <200102280433.VAA16362@aztec.santafe.edu> <3A9D1798.8E121E0D@mentor.com> <200103011057.DAA20094@aztec.santafe.edu> <3A9E4298.766295A6@mentor.com> From: Richard Stallman MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 1 Mar 2001 20:12:24 -0700 (MST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N     Unfortunately, the situation is more complex than the facts.
    We have reached the limits of the SW/HW similarities
    and we need help to clear the situation : what happens
    to a "HW design" distributed with the sources released under GPL.

I think you need a lawyer's help for that.  My conclusion, based on my
discussions with lawyers about US law, is if these are really HARDWARE
designs--used to make gates, etc.--then the hardware is not covered by
copyright.  So anyone can use these designs to make hardware, and need
not pay attention to any license conditions you have put on the design.

If so, it follows that they can combine a GPL-covered design portion
with a design portion that uses some other license, and even with a
proprietary design portion.  There is simply no way you can stop them.

However, it is worth verifying that the products made from these
designs are really hardware.  Do they consist of gates and wires?  Or
are they programs in an FPGA?  The latter is software.

I can't help you any more than that.
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Fri Mar 2 16:25:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04390 for ; Sat, 3 Mar 2001 08:19:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Mar 2001 08:19:49 +0100 (MET) Received: (qmail 656 invoked by uid 0); 2 Mar 2001 23:31:27 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx18) with SMTP; 2 Mar 2001 23:31:27 -0000 X-eGroups-Return: sentto-1101623-2479-983575885-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ck.egroups.com with NNFMP; 02 Mar 2001 23:31:26 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 2 Mar 2001 23:31:24 -0000 Received: (qmail 6223 invoked from network); 2 Mar 2001 23:31:23 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 Mar 2001 23:31:23 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.246) by mta3 with SMTP; 3 Mar 2001 00:32:11 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00957; Fri, 2 Mar 2001 16:25:02 +0100 Message-ID: <20010302162502.24372@thrai.stud.uni-hannover.de> To: F-CPU Mailing List X-Mailer: Mutt 0.84e From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Mar 2001 16:25:02 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Divider News Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Status: R X-Status: N --AhhlLboLdkugWU4S Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Moin, moin!

I've been a little quiet for a while, but here we go again :)

I played with several variants of the SRT divider, and the most
appropriate one seems to be the ordinary radix-2 one.  It calculates
a single result bit per stage, and the stages fit (no more than 6
gates deep).  It still has some drawbacks, however -- the operands
must be normalized (i.e. left-shifted by a variable amount of bits),
the remainder (if needed) must be denormalized, and there is no room
for the input mux or SIMD slicing (it could be done in 2 stages, but
then a 64-bit divide would take more than 128 cycles).

My best solution so far is to use an SRT array.  Not a full array, only
8 rows.  That way, an 8-bit result can be calculated in approximately
12 cycles (8 + normalize/denormalize and other output post-processing).
For larger chunks, the output of the array can be fed back to the input,
losing only one additional cycle every 8 bits -- that means 76...80
cycles for a 64-bit result.

The second problem, SIMD handling, can be solved by using multiple
dividers in parallel -- a 64-bit one for full words (which is also reused
for the "highest" chunk in SIMD operations), a 32-bit one (highest
chunk of lower half), two 16-bit ones (first and third quarter) and
four 8-bit ones.  There will be a space overhead of 150% compared to a
"straight" divider, but I think we don't have a better choice.

Oh by the way: of course the unit will be able to calculate both
signed and unsigned quotients, remainders, and also be able to perform
a "narrowing" divide that mirrors the "widening" multiply instruction.

I'll attach the source for the SRT core for reference.

Whadd'ya think?
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="blah2.vhdl" -- blah2.vhdl -- Scalable SRT Divider Row -- Copyright (C) 2000, 2001 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -- $Id$ library IEEE; use IEEE.std_logic_1164.all; entity Blah2 is generic ( WIDTH : natural := 64 ); port ( -- partial remainder high part (a0-a1) A0 : in std_ulogic_vector(WIDTH+1 downto 0); A1 : in std_ulogic_vector(WIDTH+1 downto 0); -- partial remainder low part AV : in std_ulogic_vector(WIDTH-1 downto 0); -- divisor BV : in std_ulogic_vector(WIDTH+1 downto 0); -- -- partial remainder high part (r0-r1) R0 : out std_ulogic_vector(WIDTH+1 downto 0); R1 : out std_ulogic_vector(WIDTH+1 downto 0); -- partial remainder low part RV : out std_ulogic_vector(WIDTH-1 downto 0); -- 1-bit quotient QP : out std_ulogic; QN : out std_ulogic ; -- test pads TestP : out std_ulogic; TestD : out std_ulogic ); end Blah2; architecture Behave_1 of Blah2 is begin process (A0, A1, AV, BV) variable t0, t1, bb : std_ulogic_vector(WIDTH+1 downto 0); variable tv : std_ulogic_vector(WIDTH-1 downto 0); variable gg, pp : std_ulogic_vector(3 downto 0); variable d, p : std_ulogic; variable t, u, v : std_ulogic_vector(WIDTH+1 downto 0); begin -- input values -- d=0 tv := AV; bb := BV; -- d=1 t0 := A0 xor not A1; -- (not A1) calculated somewhere else t1 := A0 and not A1; -- (not A1) calculated somewhere else -- decision logic -- d=1 pp := t0(WIDTH+1 downto WIDTH-2); gg := t1(WIDTH+1 downto WIDTH-2); -- p = '1' when remainder is not zero (approximately) -- d=2 p := not (pp(3) and pp(2) and pp(1) and pp(0)); -- d = '1' when remainder/divisor signs equal (=> subtract) -- d=4 d := ((not bb(WIDTH+1)) xor pp(3)) xor (gg(2) or (pp(2) and gg(1)) or (pp(2) and pp(1) and gg(0))); -- test pads TestP <= p; TestD <= d; -- 1-bit quotient outputs -- d=6 QN <= p and not d; QP <= p and d; -- A0/A1/AV left shift -- d=1 t0 := t0(WIDTH downto 0) & (not tv(WIDTH-1)); t1 := t1(WIDTH downto 0) & tv(WIDTH-1); -- d=0 tv := tv(WIDTH-2 downto 0) & '0'; -- add/subtract/no-op depending on p and d: -- when p = '1', add/subtract bb, else add/subtract zero. -- subtract when d = '1', otherwise add. -- d=1 t := t0; u := t1; -- d=3 v := bb and (WIDTH+1 downto 0 => p); -- d=5 t0 := (t xor v) xor (WIDTH+1 downto 0 => d); -- d=6 t1 := (u xor (t and v)) xor (t and (WIDTH+1 downto 0 => d)); t1 := t1(WIDTH downto 0) & d; -- outputs R0 <= t0; R1 <= not t1; -- calculated somewhere else RV <= tv; end process; end Behave_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --AhhlLboLdkugWU4S-- From Michael Riepe Fri Mar 2 03:10:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04393 for ; Sat, 3 Mar 2001 08:19:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Mar 2001 08:19:50 +0100 (MET) Received: (qmail 32713 invoked by uid 0); 2 Mar 2001 23:31:36 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 2 Mar 2001 23:31:36 -0000 X-eGroups-Return: sentto-1101623-2480-983575893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 02 Mar 2001 23:31:34 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 2 Mar 2001 23:31:33 -0000 Received: (qmail 73390 invoked from network); 2 Mar 2001 23:31:32 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 2 Mar 2001 23:31:32 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.246) by mta3 with SMTP; 3 Mar 2001 00:32:31 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA01902; Fri, 2 Mar 2001 03:10:12 +0100 Message-ID: <20010302031012.35083@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3A9E4C07.412264E9@mentor.com>; from Yann GUIDON on Thu, Mar 01, 2001 at 02:17:59PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 2 Mar 2001 03:10:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, Mar 01, 2001 at 02:17:59PM +0100, Yann GUIDON wrote:
[...]
> > No, wait - that's not true.  It *does* keep implementors from using
> > the F-CPU core(s) inside a "SoC", together with proprietary IP.
>
> however i don't see "how".
> As long as the implementor complies with the GPL and the charter,
> mainly for the source redistribution/modification etc,
> i see no reason to keep anyone from integrating the core,
> even in a washing machine. remember the word ? "freedom"...

IMHO, a chip that contains the F-CPU plus something else is a "derived
work" and has to be released under the terms of the GPL *as a whole*.
That's not possible if part of the "something else" is proprietary.

> I think that now we have to ask these questions :
> - do we want to keep people from using F-CPU in a SoC ?

No.

> - do we want to discriminate against "proprietary SoC" implementors ?

Yes (at least I do).

> let's not misunderstand the "goals" and the "means".
> The goal is pretty clear : we want to design a very good (the best !) CPU.
> The means depends on the side effects. We want to promote Free Software,
> not "only" providing gratis IP. Does that mean that we must forbid
> the connexion to proprietary HW ?

IMHO, yes.

> At one point or another, proprietary stuff must speak to free stuff and
> vice versa. If we are too much "integrist", nothing will be able
> to communicate with the F-CPU and it will die. Imagine that we
> couldn't even connect the core to RAM ...
> If we are too lax OTOH, the situation will get out of hand.

If there is a proprietary chipset, RAM, SCSI controller or whatever
connected to the F-CPU (i.e. another chip on the same board), I don't
really mind.  But if they're on the same chip, I *do* mind.  IMHO, the
chip is the analogon to a `binary' od `executable program' in GPL-speak.
You take the (VHDL) sources, "compile" them and the result is a piece
of structured silicon.  If you modify the sources (perhaps by addding
something), the result is a derived work, that means everything you add
*on the same chip* must be free as well.

> My point of view is that the inside of the CPU core is GPL,
> the outside is up to the end user. "The system is the core".
> If the end user wants to support a proprietary interface,
> the necessary modifications to the core must be redistributed as well.
> it looks simple for me.

That's a more relaxed point of view.  Maybe I could live with it, but
at the moment I like my definition better :)

[...]
> the question can be reversed : "Do we want to forbid
> implementors to mix F-CPU and proprietary work ?"
> the "freedom" word says no. however, this comes under restricted
> conditions that we can fine-tune now.

Freedom must have its limits.  Freedom does not mean that anybody can
do anything (s)he wants -- (s)he has to take into account the freedom
of others.  In this case, the freedom to copy and redistribute a work
based on the F-CPU must IMHO be protected, and that's not possible if an
F-CPU core is directly and atomically(!) coupled with proprietary stuff.

> > At least I don't want to. And that's the reason why I prefer the GPL.
> I still am an utopist : i hope that the F-CPU can help the industry
> understand the advantages of openness and cooperation/collaboration.

Fine, I'm still following you on that.  But please let's force them to
be really *open*, and not just pretend to be (like many other so-called
"open source" projects -- *blech*).

> Whatever you want, or hope, i doubt that a real "free computer" will
> ever exist : proprietary techniques and patented functions will
> always remain at one point or another. Even a "free" f-cpu chip
> will use proprietary silicon manufacturing techniques.
> However i don't want to send any signal saying : "rip us off !"
> like the LEON does. LEON looks like a "give-away design" to me.
> hence the GPL on my designs.

Amen.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 3 03:20:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04405 for ; Sat, 3 Mar 2001 08:19:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Mar 2001 08:19:54 +0100 (MET) Received: (qmail 32751 invoked by uid 0); 3 Mar 2001 02:14:00 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx21) with SMTP; 3 Mar 2001 02:14:00 -0000 X-eGroups-Return: sentto-1101623-2481-983585639-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 03 Mar 2001 02:13:59 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 3 Mar 2001 02:13:58 -0000 Received: (qmail 48498 invoked from network); 3 Mar 2001 02:13:52 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 3 Mar 2001 02:13:52 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 3 Mar 2001 02:13:51 -0000 Received: from f-cpu.org (nas4-137.pau.club-internet.fr [195.36.133.137]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA01533 for ; Sat, 3 Mar 2001 03:13:47 +0100 (MET) Message-ID: <3AA054D5.CF15309@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <20010302162502.24372@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Mar 2001 03:20:05 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Divider News Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:
> Moin, moin!
glou, glou :-)

> I've been a little quiet for a while, but here we go again :)
yeah !

> I played with several variants of the SRT divider,
<snip>
> Whadd'ya think?

wow/geeze; that's "crayzee" as usual :-)

but no time to test it at home :-(


I'm also waiting for a presentation of NicO's
results about the scoreboard... one day ;-)

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 3 03:20:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04408 for ; Sat, 3 Mar 2001 08:19:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 03 Mar 2001 08:19:54 +0100 (MET) Received: (qmail 14266 invoked by uid 0); 3 Mar 2001 02:14:07 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx23) with SMTP; 3 Mar 2001 02:14:07 -0000 X-eGroups-Return: sentto-1101623-2482-983585645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 03 Mar 2001 02:14:06 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 3 Mar 2001 02:14:04 -0000 Received: (qmail 48919 invoked from network); 3 Mar 2001 02:14:03 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 3 Mar 2001 02:14:03 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 3 Mar 2001 02:14:03 -0000 Received: from f-cpu.org (nas4-137.pau.club-internet.fr [195.36.133.137]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA27733; Sat, 3 Mar 2001 03:13:54 +0100 (MET) Message-ID: <3AA054DB.35ADF665@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com Cc: hardlicense-discuss@seul.org References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Mar 2001 03:20:11 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

FYI, the discussion should be switched to the
hardlicense-discuss@seul.org... it's a nicer place
and we could speak paralelly on different matters
on the different lists.

Graham just posted a link to the current replacement for the old
Semiconductor Chip Portection Act
http://www.wipo.int/academy/en/events/2000/acad_e/pdf/2i.pdf

Michael Riepe wrote:
> On Thu, Mar 01, 2001 at 02:17:59PM +0100, Yann GUIDON wrote:
> [...]
> > > No, wait - that's not true.  It *does* keep implementors from using
> > > the F-CPU core(s) inside a "SoC", together with proprietary IP.
> > however i don't see "how".
> > As long as the implementor complies with the GPL and the charter,
> > mainly for the source redistribution/modification etc,
> > i see no reason to keep anyone from integrating the core,
> > even in a washing machine. remember the word ? "freedom"...
> IMHO, a chip that contains the F-CPU plus something else is a "derived
> work" and has to be released under the terms of the GPL *as a whole*.
> That's not possible if part of the "something else" is proprietary.

let's remember the time when "SoC" was not brought by the marketing teams.
F-CPU was to compete with ia64. In this context, your comment makes sense.

Now, Nicolas wants to convince us that there is no life outside of the
"SoC" hype. However he pointed himself that the f-cpu core would be
rather large. So if someone wants a small core, he uses the LEON.
Does anyone want to contest that ? :-)

> > I think that now we have to ask these questions :
> > - do we want to keep people from using F-CPU in a SoC ?
> No.
>
> > - do we want to discriminate against "proprietary SoC" implementors ?
> Yes (at least I do).

remembering that "SoC" is not the goal for the f-cpu project,
these answers make sense to me.

Let's let the Leon (and other teams) create GPL'd peripherals.
then we'll speak about "free" SoCs. Before that, there are a LOT
of things to do ! :-)

> > let's not misunderstand the "goals" and the "means".
> > The goal is pretty clear : we want to design a very good (the best !) CPU.
> > The means depends on the side effects. We want to promote Free Software,
> > not "only" providing gratis IP. Does that mean that we must forbid
> > the connexion to proprietary HW ?
>
> IMHO, yes.

at what level ?

> > At one point or another, proprietary stuff must speak to free stuff and
> > vice versa. If we are too much "integrist", nothing will be able
> > to communicate with the F-CPU and it will die. Imagine that we
> > couldn't even connect the core to RAM ...
> > If we are too lax OTOH, the situation will get out of hand.
>
> If there is a proprietary chipset, RAM, SCSI controller or whatever
> connected to the F-CPU (i.e. another chip on the same board), I don't
> really mind.  But if they're on the same chip, I *do* mind.  IMHO, the
> chip is the analogon to a `binary' od `executable program' in GPL-speak.
> You take the (VHDL) sources, "compile" them and the result is a piece
> of structured silicon.  If you modify the sources (perhaps by addding
> something), the result is a derived work, that means everything you add
> *on the same chip* must be free as well.

ok so let's stick with that.

> > My point of view is that the inside of the CPU core is GPL,
> > the outside is up to the end user. "The system is the core".
> > If the end user wants to support a proprietary interface,
> > the necessary modifications to the core must be redistributed as well.
> > it looks simple for me.
>
> That's a more relaxed point of view.  Maybe I could live with it, but
> at the moment I like my definition better :)

this makes 2:1. i follow Nico and Michael.

> [...]
> > the question can be reversed : "Do we want to forbid
> > implementors to mix F-CPU and proprietary work ?"
> > the "freedom" word says no. however, this comes under restricted
> > conditions that we can fine-tune now.
>
> Freedom must have its limits.  Freedom does not mean that anybody can
> do anything (s)he wants -- (s)he has to take into account the freedom
> of others.  In this case, the freedom to copy and redistribute a work
> based on the F-CPU must IMHO be protected, and that's not possible if an
> F-CPU core is directly and atomically(!) coupled with proprietary stuff.

"directly and atomically(!) coupled with proprietary stuff." should be more defined...

> > > At least I don't want to. And that's the reason why I prefer the GPL.
> > I still am an utopist : i hope that the F-CPU can help the industry
> > understand the advantages of openness and cooperation/collaboration.
>
> Fine, I'm still following you on that.  But please let's force them to
> be really *open*, and not just pretend to be (like many other so-called
> "open source" projects -- *blech*).
i #know# what you mean ...

> > Whatever you want, or hope, i doubt that a real "free computer" will
> > ever exist : proprietary techniques and patented functions will
> > always remain at one point or another. Even a "free" f-cpu chip
> > will use proprietary silicon manufacturing techniques.
> > However i don't want to send any signal saying : "rip us off !"
> > like the LEON does. LEON looks like a "give-away design" to me.
> > hence the GPL on my designs.
>
> Amen.

so let's kick'em all. yeah.

warning everybody : we are dangerous integrist utopists.
if we /ever/ succeed, watch your butt because we'll be
even crazier than the FSF guys ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat Mar 3 18:56:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00638 for ; Sun, 4 Mar 2001 02:04:24 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Mar 2001 02:04:24 +0100 (MET) Received: (qmail 20927 invoked by uid 0); 3 Mar 2001 17:45:44 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx25) with SMTP; 3 Mar 2001 17:45:44 -0000 X-eGroups-Return: sentto-1101623-2483-983641453-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 03 Mar 2001 17:44:14 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 3 Mar 2001 17:44:12 -0000 Received: (qmail 85867 invoked from network); 3 Mar 2001 17:44:11 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 3 Mar 2001 17:44:11 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.157) by mta1 with SMTP; 3 Mar 2001 17:44:10 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8D7809E4C for ; Sat, 3 Mar 2001 18:56:21 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3AA13043.44791806@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 03 Mar 2001 18:56:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Sorry Michael, but you are much too strict !

Would you one day use cache memory with the fcpu ? You only could use
SRAM generator to do it. So no internal cache for the fcpu ?

And in the other hand, to make a chip you used proprietary technical
library.

So you can't avoid proprietary stuff.

nicO

Michael Riepe a =E9crit :
>
> On Thu, Mar 01, 2001 at 02:17:59PM +0100, Yann GUIDON wrote:
> [...]
> > > No, wait - that's not true.  It *does* keep implementor= s from using
> > > the F-CPU core(s) inside a "SoC", together with pr= oprietary IP.
> >
> > however i don't see "how".
> > As long as the implementor complies with the GPL and the charter,=
> > mainly for the source redistribution/modification etc,
> > i see no reason to keep anyone from integrating the core,
> > even in a washing machine. remember the word ? "freedom"= ;...
>
> IMHO, a chip that contains the F-CPU plus something else is a "de= rived
> work" and has to be released under the terms of the GPL *as a who= le*.
> That's not possible if part of the "something else" is propr= ietary.
>
> > I think that now we have to ask these questions :
> > - do we want to keep people from using F-CPU in a SoC ?
>
> No.
>
> > - do we want to discriminate against "proprietary SoC" = implementors ?
>
> Yes (at least I do).
>
> > let's not misunderstand the "goals" and the "means= ".
> > The goal is pretty clear : we want to design a very good (the bes= t !) CPU.
> > The means depends on the side effects. We want to promote Free So= ftware,
> > not "only" providing gratis IP. Does that mean that we = must forbid
> > the connexion to proprietary HW ?
>
> IMHO, yes.
>
> > At one point or another, proprietary stuff must speak to free stu= ff and
> > vice versa. If we are too much "integrist", nothing wil= l be able
> > to communicate with the F-CPU and it will die. Imagine that we > > couldn't even connect the core to RAM ...
> > If we are too lax OTOH, the situation will get out of hand.
>
> If there is a proprietary chipset, RAM, SCSI controller or whatever > connected to the F-CPU (i.e. another chip on the same board), I don't<= BR> > really mind.  But if they're on the same chip, I *do* mind. = IMHO, the
> chip is the analogon to a `binary' od `executable program' in GPL-spea= k.
> You take the (VHDL) sources, "compile" them and the result i= s a piece
> of structured silicon.  If you modify the sources (perhaps by add= ding
> something), the result is a derived work, that means everything you ad= d
> *on the same chip* must be free as well.
>
> > My point of view is that the inside of the CPU core is GPL,
> > the outside is up to the end user. "The system is the core&q= uot;.
> > If the end user wants to support a proprietary interface,
> > the necessary modifications to the core must be redistributed as = well.
> > it looks simple for me.
>
> That's a more relaxed point of view.  Maybe I could live with it,= but
> at the moment I like my definition better :)
>
> [...]
> > the question can be reversed : "Do we want to forbid
> > implementors to mix F-CPU and proprietary work ?"
> > the "freedom" word says no. however, this comes under r= estricted
> > conditions that we can fine-tune now.
>
> Freedom must have its limits.  Freedom does not mean that anybody= can
> do anything (s)he wants -- (s)he has to take into account the freedom<= BR> > of others.  In this case, the freedom to copy and redistribute a = work
> based on the F-CPU must IMHO be protected, and that's not possible if = an
> F-CPU core is directly and atomically(!) coupled with proprietary stuf= f.
>
> > > At least I don't want to. And that's the reason why I prefer= the GPL.
> > I still am an utopist : i hope that the F-CPU can help the indust= ry
> > understand the advantages of openness and cooperation/collaborati= on.
>
> Fine, I'm still following you on that.  But please let's force th= em to
> be really *open*, and not just pretend to be (like many other so-calle= d
> "open source" projects -- *blech*).
>
> > Whatever you want, or hope, i doubt that a real "free comput= er" will
> > ever exist : proprietary techniques and patented functions will > > always remain at one point or another. Even a "free" f-= cpu chip
> > will use proprietary silicon manufacturing techniques.
> > However i don't want to send any signal saying : "rip us off= !"
> > like the LEON does. LEON looks like a "give-away design"= ; to me.
> > hence the GPL on my designs.
>
> Amen.
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
=3D"3
Click for Details
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Sat Mar 3 14:47:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA00680 for ; Sun, 4 Mar 2001 02:04:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Mar 2001 02:04:43 +0100 (MET) Received: (qmail 2554 invoked by uid 0); 3 Mar 2001 23:18:26 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx25) with SMTP; 3 Mar 2001 23:18:26 -0000 X-eGroups-Return: sentto-1101623-2484-983661503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 03 Mar 2001 23:18:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 3 Mar 2001 23:18:23 -0000 Received: (qmail 8091 invoked from network); 3 Mar 2001 23:18:21 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 Mar 2001 23:18:21 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.197) by mta1 with SMTP; 3 Mar 2001 23:18:19 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00491; Sat, 3 Mar 2001 14:47:57 +0100 Message-ID: <20010303144757.22343@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> <3AA054DB.35ADF665@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3AA054DB.35ADF665@f-cpu.org>; from Yann Guidon on Sat, Mar 03, 2001 at 03:20:11AM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 3 Mar 2001 14:47:57 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sat, Mar 03, 2001 at 03:20:11AM +0100, Yann Guidon wrote:
[...]
> > > The goal is pretty clear : we want to design a very good (the best !) CPU.
> > > The means depends on the side effects. We want to promote Free Software,
> > > not "only" providing gratis IP. Does that mean that we must forbid
> > > the connexion to proprietary HW ?
> >
> > IMHO, yes.
>
> at what level ?

At least chip level, maybe board level, that depends (see my next comment).

[...]
> > Freedom must have its limits.  Freedom does not mean that anybody can
> > do anything (s)he wants -- (s)he has to take into account the freedom
> > of others.  In this case, the freedom to copy and redistribute a work
> > based on the F-CPU must IMHO be protected, and that's not possible if an
> > F-CPU core is directly and atomically(!) coupled with proprietary stuff.
>
> "directly and atomically(!) coupled with proprietary stuff." should be more defined...

Maybe I should have said "unseparatable".  If you can remove the
proprietary stuff and replace it with something that's free, everything's
fine.  A free chip in some kind of socket, or a free chip+board in some
kind of slot is ok.  If you need a soldering iron, a chainsaw or a bottle
of H2SO4/HCL/HF to remove the proprietary part, it's not.

[...]
> so let's kick'em all. yeah.
>
> warning everybody : we are dangerous integrist utopists.
> if we /ever/ succeed, watch your butt because we'll be
> even crazier than the FSF guys ;-)

See my broad evil grin? ;)

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
3 DVDs for ONLY 49 cents each!
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Mar 4 05:31:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA01410 for ; Sun, 4 Mar 2001 06:32:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 04 Mar 2001 06:32:21 +0100 (MET) Received: (qmail 30567 invoked by uid 0); 4 Mar 2001 04:25:14 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx10) with SMTP; 4 Mar 2001 04:25:14 -0000 X-eGroups-Return: sentto-1101623-2485-983679912-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 04 Mar 2001 04:25:13 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 4 Mar 2001 04:25:12 -0000 Received: (qmail 47954 invoked from network); 4 Mar 2001 04:25:11 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 4 Mar 2001 04:25:11 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 4 Mar 2001 04:25:11 -0000 Received: from f-cpu.org (nas2-41.bdx.club-internet.fr [195.36.133.41]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA16557 for ; Sun, 4 Mar 2001 05:25:00 +0100 (MET) Message-ID: <3AA1C504.13C869E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> <3AA054DB.35ADF665@f-cpu.org> <20010303144757.22343@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Mar 2001 05:31:00 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi,

Michael Riepe wrote:
> On Sat, Mar 03, 2001 at 03:20:11AM +0100, Yann Guidon wrote:
> [...]
> > > > The goal is pretty clear : we want to design a very good (the best !) CPU.
> > > > The means depends on the side effects. We want to promote Free Software,
> > > > not "only" providing gratis IP. Does that mean that we must forbid
> > > > the connexion to proprietary HW ?
> > > IMHO, yes.
> > at what level ?
> At least chip level, maybe board level, that depends (see my next comment).
IIRC RMS's recent post says that we have no legal mean to forbid that.
the GPL applies at the SW source level only.

>
> [...]
> > > Freedom must have its limits.  Freedom does not mean that anybody can
> > > do anything (s)he wants -- (s)he has to take into account the freedom
> > > of others.  In this case, the freedom to copy and redistribute a work
> > > based on the F-CPU must IMHO be protected, and that's not possible if an
> > > F-CPU core is directly and atomically(!) coupled with proprietary stuff.
> > "directly and atomically(!) coupled with proprietary stuff." should be more defined...
> Maybe I should have said "unseparatable".  If you can remove the
> proprietary stuff and replace it with something that's free, everything's
> fine.  A free chip in some kind of socket, or a free chip+board in some
> kind of slot is ok.  If you need a soldering iron, a chainsaw or a bottle
> of H2SO4/HCL/HF to remove the proprietary part, it's not.

in other words, "easily (un)pluggable by the end user".

> [...]
> > so let's kick'em all. yeah.
> >
> > warning everybody : we are dangerous integrist utopists.
> > if we /ever/ succeed, watch your butt because we'll be
> > even crazier than the FSF guys ;-)
> See my broad evil grin? ;)

yup, i'm worried ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
hey, these footers are getting boring.

i have just switched the french mailing list to a new server.
it was rather easy because i was the creator and maintainer.
it will be more difficult to switch the english list ...

what "free" ("as a gnu") services are there (except seul) ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Choose 3 DVDs for $0.49 each!
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Sun Mar 4 03:28:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA04026 for ; Mon, 5 Mar 2001 07:57:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Mar 2001 07:57:17 +0100 (MET) Received: (qmail 18307 invoked by uid 0); 4 Mar 2001 12:37:28 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx15) with SMTP; 4 Mar 2001 12:37:28 -0000 X-eGroups-Return: sentto-1101623-2486-983709447-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 04 Mar 2001 12:37:28 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 4 Mar 2001 12:37:26 -0000 Received: (qmail 89141 invoked from network); 4 Mar 2001 12:37:26 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 4 Mar 2001 12:37:26 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.182) by mta1 with SMTP; 4 Mar 2001 12:37:23 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02984; Sun, 4 Mar 2001 03:28:43 +0100 Message-ID: <20010304032843.04655@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> <3AA13043.44791806@seul.org> X-Mailer: Mutt 0.84e In-Reply-To: <3AA13043.44791806@seul.org>; from Nicolas on Sat, Mar 03, 2001 at 06:56:19PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 4 Mar 2001 03:28:43 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sat, Mar 03, 2001 at 06:56:19PM +0100, Nicolas wrote:
> Sorry Michael, but you are much too strict !
>
> Would you one day use cache memory with the fcpu ? You only could use
> SRAM generator to do it. So no internal cache for the fcpu ?
>
> And in the other hand, to make a chip you used proprietary technical
> library.

That's something different, IMHO.  You are permitted to link GPLed
programs with libc (even with OSF/Motif libraries, if they need them)
coming from the system they're going to run on.  The same should be true
for VHDL and technical libraries that contain gates, SRAM cells and so on.
In other words: that's ok.  It's not ok, however, to integrate the F-CPU
with a proprietary graphics controller on a single chip (or use it as the
workhorse in an otherwise proprietary graphics controller, or whatever).

> So you can't avoid proprietary stuff.

Not fully, but to a certain degree.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
3 DVDs for ONLY 49 cents each!
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sun Mar 4 19:26:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA04062 for ; Mon, 5 Mar 2001 07:57:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Mar 2001 07:57:25 +0100 (MET) Received: (qmail 14968 invoked by uid 0); 4 Mar 2001 18:14:55 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx18) with SMTP; 4 Mar 2001 18:14:55 -0000 X-eGroups-Return: sentto-1101623-2487-983729686-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 04 Mar 2001 18:14:49 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 4 Mar 2001 18:14:46 -0000 Received: (qmail 56077 invoked from network); 4 Mar 2001 18:14:44 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 4 Mar 2001 18:14:44 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.163.178) by mta3 with SMTP; 4 Mar 2001 19:15:47 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 835BB9E6E for ; Sun, 4 Mar 2001 19:26:58 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3AA288F2.5717335B@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> <3AA13043.44791806@seul.org> <20010304032843.04655@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 04 Mar 2001 19:26:58 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Sat, Mar 03, 2001 at 06:56:19PM +0100, Nicolas wrote:
> > Sorry Michael, but you are much too strict !
> >
> > Would you one day use cache memory with the fcpu ? You only could= use
> > SRAM generator to do it. So no internal cache for the fcpu ?
> >
> > And in the other hand, to make a chip you used proprietary techni= cal
> > library.
>
> That's something different, IMHO.  You are permitted to link GPLe= d
> programs with libc (even with OSF/Motif libraries, if they need them)<= BR> > coming from the system they're going to run on.  The same should = be true
> for VHDL and technical libraries that contain gates, SRAM cells and so= on.
> In other words: that's ok.  It's not ok, however, to integrate th= e F-CPU
> with a proprietary graphics controller on a single chip (or use it as = the
> workhorse in an otherwise proprietary graphics controller, or whatever= ).
>
> > So you can't avoid proprietary stuff.
>
> Not fully, but to a certain degree.

And that the very big problem ! Where is the border ? How can we make
simple rules to trace it ? How to decide, this is an abuse, this not ?
You say ok for the all analog part, fine. But what happen for strange
memory (CAM), is it always an acceptable proprietary core or not ?

In the other hand, a startup want to create a geoforce killer, make
there owne C code but needs cores, they want to use the MPEG decoder
given by the chip maker and they need a quick cpu. They don't have time
and money to develop a new MPEG core, so they use chip maker's one. So
they can't use Fcpu and will choose a Mips or Arm core. Sound stupid, no ? They could create real stuff for the fcpu (like debugging the compiler or other SW related stuff).

In the other hand, GPL is a copyright. So you could use it, only at VHDL level. So you could add what ever hard ip (soon place&routed ) to the design without law problem (according to RMS post). So the fcpu will be
protected (no internal change possible, only possible at the gate level
for crazy men). But you could add some other proprietary stuff around in hard macro style. The only change to the fcpu they have to do is to
adapte the interface to their core. But most of the time it will be the
same (Amba or CoreConnect). If we want more protection, we should ask
some lawyer about IP laws (we should ask M.Breese ;p(french jok : it's a lawyer which want absolutely patented softwares)).

By reading specialise news paper, i could see that soc will be the add
of "some" differents kinds of cpu (microcontroler + DSP+ 8bits co= ntroler
for DMA, IO,...) plus a thing that look like fpga. The routing will be
made by the last 2 wires mask. That to decrease the cost of a change for an error at the mask level and to make easy to change between 2 IO
protocoles without making a complete new set of mask. This fpga style
cells will be proprietary stuff, too.

nicO
>
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
Yahoo! Groups Spons= or
3D=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon Mar 5 02:58:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA04140 for ; Mon, 5 Mar 2001 07:57:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 05 Mar 2001 07:57:46 +0100 (MET) Received: (qmail 24753 invoked by uid 0); 5 Mar 2001 01:51:52 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx23) with SMTP; 5 Mar 2001 01:51:52 -0000 X-eGroups-Return: sentto-1101623-2488-983757110-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 05 Mar 2001 01:51:51 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 5 Mar 2001 01:51:49 -0000 Received: (qmail 92498 invoked from network); 5 Mar 2001 01:51:48 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Mar 2001 01:51:48 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 5 Mar 2001 01:51:48 -0000 Received: from f-cpu.org (nas1-129.ras.club-internet.fr [195.36.192.129]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA02960 for ; Mon, 5 Mar 2001 02:51:40 +0100 (MET) Message-ID: <3AA2F2A8.EF2C95E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200102282251.f1SMpOF20156@mail.swissonline.ch> <20010301012634.54515@thrai.stud.uni-hannover.de> <3A9E4C07.412264E9@mentor.com> <20010302031012.35083@thrai.stud.uni-hannover.de> <3AA13043.44791806@seul.org> <20010304032843.04655@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 05 Mar 2001 02:58:00 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] thoughts licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:
> On Sat, Mar 03, 2001 at 06:56:19PM +0100, Nicolas wrote:
> > Sorry Michael, but you are much too strict !
> >
> > Would you one day use cache memory with the fcpu ? You only could use
> > SRAM generator to do it. So no internal cache for the fcpu ?
> >
> > And in the other hand, to make a chip you used proprietary technical
> > library.
>
> That's something different, IMHO.  You are permitted to link GPLed
> programs with libc (even with OSF/Motif libraries, if they need them)
> coming from the system they're going to run on.  The same should be true
> for VHDL and technical libraries that contain gates, SRAM cells and so on.
> In other words: that's ok.  It's not ok, however, to integrate the F-CPU
> with a proprietary graphics controller on a single chip (or use it as the
> workhorse in an otherwise proprietary graphics controller, or whatever).

hmm ok it's becoming clearer now...

> > So you can't avoid proprietary stuff.
> Not fully, but to a certain degree.

and this degree is still imprecise ... :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 6 11:45:39 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA05758 for ; Wed, 7 Mar 2001 05:14:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 05:14:47 +0100 (MET) Received: (qmail 26250 invoked by uid 0); 6 Mar 2001 11:16:32 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx13) with SMTP; 6 Mar 2001 11:16:32 -0000 X-eGroups-Return: sentto-1101623-2490-983877390-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 06 Mar 2001 11:16:30 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 6 Mar 2001 11:16:30 -0000 Received: (qmail 45907 invoked from network); 6 Mar 2001 11:16:29 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 6 Mar 2001 11:16:29 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 6 Mar 2001 11:16:29 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA16327; Tue, 6 Mar 2001 02:52:29 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8FY8; Tue, 6 Mar 2001 10:57:53 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AA4BFD3.2793DF78@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Mar 2001 11:45:39 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] VHDL for ECC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

i would like to know where to find commented/explained
VHDL source code for a 64+8 ECC encoder and decoder.
i have forgotten the basic principles...

thanks,

YG

speaking for himself
Yahoo! Groups Sponsor
Corbis - The Place for Pictures Online

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 6 11:50:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA05761 for ; Wed, 7 Mar 2001 05:14:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 05:14:47 +0100 (MET) Received: (qmail 23506 invoked by uid 0); 6 Mar 2001 11:16:34 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx07) with SMTP; 6 Mar 2001 11:16:34 -0000 X-eGroups-Return: sentto-1101623-2489-983877389-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 06 Mar 2001 11:16:31 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 6 Mar 2001 11:16:29 -0000 Received: (qmail 64654 invoked from network); 6 Mar 2001 11:16:28 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 6 Mar 2001 11:16:28 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 6 Mar 2001 11:16:28 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id CAA16722; Tue, 6 Mar 2001 02:57:40 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8FZB; Tue, 6 Mar 2001 11:03:03 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AA4C109.1F07B75C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Mar 2001 11:50:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] ooops... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www.ece.umn.edu/users/jchen/ecc.html
that's here...

YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue Mar 6 12:23:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA05764 for ; Wed, 7 Mar 2001 05:14:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 05:14:48 +0100 (MET) Received: (qmail 5322 invoked by uid 0); 6 Mar 2001 11:23:48 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx17) with SMTP; 6 Mar 2001 11:23:48 -0000 X-eGroups-Return: sentto-1101623-2491-983877825-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 06 Mar 2001 11:23:47 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 6 Mar 2001 11:23:44 -0000 Received: (qmail 74478 invoked from network); 6 Mar 2001 11:23:43 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 6 Mar 2001 11:23:43 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 6 Mar 2001 11:23:43 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id NAA19148 for ; Tue, 6 Mar 2001 13:23:41 +0200 (EET) X-Sender: kenkovaa@gamma.hut.fi To: "f-cpu@egroups.com" In-Reply-To: <3AA4BFD3.2793DF78@mentor.com> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Mar 2001 13:23:40 +0200 (EET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] VHDL for ECC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 6 Mar 2001, Yann GUIDON wrote:

> i would like to know where to find commented/explained
> VHDL source code for a 64+8 ECC encoder and decoder.
> i have forgotten the basic principles...

At least you can find the algorithms etc. from "The Error Correcting (ECC)
Page" http://imailab-www.iis.u-tokyo.ac.jp/~robert/codes.html.

Or try

http://www.ee.ualberta.ca/~akwong/eccram/

There is some implementation of ECC in VHDL.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 6 12:33:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA05773 for ; Wed, 7 Mar 2001 05:14:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 05:14:50 +0100 (MET) Received: (qmail 3948 invoked by uid 0); 6 Mar 2001 11:40:19 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx12) with SMTP; 6 Mar 2001 11:40:19 -0000 X-eGroups-Return: sentto-1101623-2492-983878812-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 06 Mar 2001 11:40:12 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 6 Mar 2001 11:40:11 -0000 Received: (qmail 4116 invoked from network); 6 Mar 2001 11:40:11 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 6 Mar 2001 11:40:11 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 6 Mar 2001 11:40:11 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA20745; Tue, 6 Mar 2001 03:40:09 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8F5A; Tue, 6 Mar 2001 11:45:34 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AA4CB01.9C607734@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 06 Mar 2001 12:33:21 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] VHDL for ECC Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
> On Tue, 6 Mar 2001, Yann GUIDON wrote:
> > i would like to know where to find commented/explained
> > VHDL source code for a 64+8 ECC encoder and decoder.
> > i have forgotten the basic principles...
>
> At least you can find the algorithms etc. from "The Error Correcting (ECC)
> Page" http://imailab-www.iis.u-tokyo.ac.jp/~robert/codes.html.
i found it some minutes after i posted the message ...

> Or try
> http://www.ee.ualberta.ca/~akwong/eccram/
>
> There is some implementation of ECC in VHDL.
>
> =============================================================================
> Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
> Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
> 02630 Espoo         |                      | write-only file system
>

cool, thanks Kim :-)

YG

speaking for himself
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "vince" Tue Mar 6 22:30:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA05907 for ; Wed, 7 Mar 2001 05:15:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 05:15:19 +0100 (MET) Received: (qmail 10264 invoked by uid 0); 7 Mar 2001 02:30:30 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx17) with SMTP; 7 Mar 2001 02:30:30 -0000 X-eGroups-Return: sentto-1101623-2493-983932229-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 07 Mar 2001 02:30:30 -0000 X-Sender: needinkus@yahoo.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 7 Mar 2001 02:30:28 -0000 Received: (qmail 7068 invoked from network); 7 Mar 2001 02:30:28 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 7 Mar 2001 02:30:28 -0000 Received: from unknown (HELO inkjets) (209.151.143.40) by mta3 with SMTP; 7 Mar 2001 03:31:31 -0000 To: From: "vince" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 6 Mar 2001 21:30:02 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] epson 4 black +3 colors $30.00-Canon-HP-Lexmark Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20010307023031.10397gmx1@mx17.gmx.net> Status: R X-Status: N These are compatible cartridges NOT refill

$5.00 shipping per order worldwide -same day shipping-
1000,s in stock.

EPSON 1 BLACK $3.00

EPSON 1 COLOR AND 1 BLACK  $9.00

EPSON 4 BLACK 3 COLORS $30.00

EPSON 777/880 -email for availability

EPSON 480/580 -4 BLACK 3 COLORS $35.00

EPSON 900/980/G--4 BLACK + 3 COLORS  $45.00

EPSON 3000/5000 ALL 4 COLORS $50.00 

CANON BCI-21 -6 BLACK 6 COLOR $30.00

CANON 3000/6000/6100 ALL 4 COLORS $20.00

HP & LEXMARK ALSO AVAILABLE
$20.00 for Black
$25.00 for Color

100% COMPATIBLE FOR THE FOLLOWING MODELS:
EPSON COLOR STYLUS, MODEL II, PRO, PRO XL, 400, 440, 480, 500, 580, 600, 640,
660, 670,
700, 740, 760, 800, 850, 860

TO ORDER ASAP SEND NAME- ADDRESS -PHONE NUMBER
AND MODEL OF MACHINE AND QUANTITY TO    needinkus@yahoo.com

EMAIL WILL ONLY BE SENT ONCE, PLEASE SEND BACK REMOVE IN SUBJECT.
OR PLEASE BLOCK ADDRESS
This mail has been sent in accordance with the pending Anti-Spam law Unsolicited
Electronic Mail
Act of 2000 (H.R. 3113). Should you wish to be removed from this mailing list please send
an e-mail
with Remove in the subject line to



Yahoo! Groups Sponsor
Air, Car & Hotel Travel Deals
Car Rental Discounts And Free Upgrades!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Mar 7 15:07:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA09672 for ; Wed, 7 Mar 2001 18:43:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 07 Mar 2001 18:43:08 +0100 (MET) Received: (qmail 8663 invoked by uid 0); 7 Mar 2001 14:13:56 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx24) with SMTP; 7 Mar 2001 14:13:56 -0000 X-eGroups-Return: sentto-1101623-2494-983974434-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 07 Mar 2001 14:13:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 7 Mar 2001 14:13:52 -0000 Received: (qmail 86694 invoked from network); 7 Mar 2001 14:13:52 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 7 Mar 2001 14:13:52 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 7 Mar 2001 15:14:57 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA04406; Wed, 7 Mar 2001 06:13:50 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8GVB; Wed, 7 Mar 2001 14:19:16 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AA64084.F1D29670@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 07 Mar 2001 15:07:00 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] HAL 2001 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

The f-cpu contributors are invited to present our work
at the HAL2001 by the LINUXFR site (www.linuxfr.org).
I will do my best to prepare and attend this huge event,
that is larger than the 17C3, in Holland.
If other people could come, they are welcome and awaited :-)

YG

speaking for himself


PS: from http://www.hal2001.org/ :

                                 press release 01:03:01

   Party is on...

   It is with great pride and hollow insane laughter that we announce to you that HAL 2001 will
   happen. At the time of writing this, we're still working on closing some sizeable remaining
   budgetary gaps. But most of our budget is now covered by sponsorships, so we feel it's time to
   announce the good news.

   Some of us have tried substitutes, and boy, did they taste swell. But nothing, absolutely nothing, can
   stop this once-every-four-year itch. After 1989, 1993 and 1997, it is time for a megalomaniac,
   life-changing, hacker extravaganza event in The Netherlands again.

   So, this is the time to re-schedule your wedding. Cancel that cruise to the Caribbean. Do whatever
   else is necessary to make sure that you are on the Campus of the University of Twente, (in the east
   of The Netherlands) between August 10th and 12th of this year, 2001.

   Ticket sales will start relatively soon, and early information on many aspects of the event will be this
   website shortly. Expect announcements from different corners of the HAL organization to increase
                                as the entire machine picks up speed over the next months.
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From platup@apexmail.com Fri Feb 23 00:13:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA16258 for ; Fri, 9 Mar 2001 06:09:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 09 Mar 2001 06:09:11 +0100 (MET) Received: (qmail 24037 invoked by uid 0); 8 Mar 2001 13:57:52 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx25) with SMTP; 8 Mar 2001 13:57:52 -0000 X-eGroups-Return: sentto-1101623-2495-984059869-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 08 Mar 2001 13:57:49 -0000 X-Sender: firebart@dragoncon.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 8 Mar 2001 13:57:48 -0000 Received: (qmail 30351 invoked from network); 8 Mar 2001 13:57:47 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 8 Mar 2001 13:57:47 -0000 Received: from unknown (HELO mail.hitc.com.tw) (203.74.20.131) by mta3 with SMTP; 8 Mar 2001 14:58:51 -0000 Received: from yahoo.com [63.233.24.61] by mail.hitc.com.tw (SMTPD32-5.04) id A6EE9701A6; Fri, 23 Feb 2001 19:13:50 PST Message-Id: <5p4gye05157aq27.280v8fh26g4n7gyx1@yahoo.com> To: personalite@i-email.to X-Mailer: Microsoft Outlook Express 4.71.1712.3 From: platup@apexmail.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Feb 2001 15:13:58 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Investigate Anyone or Anything with this program! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
INTERNET INVESTIGATOR ™

All NEW for 2001
 Internet Software Program for Online Investigation

Find out Anything about Anyone Online

Become an "Internet Investigator" and explore a whole new world of
valuable information.

Uncover Information about:
 Neighbors, Friends, Enemies, Debtors, Employees, Your Boss, Yourself...
even a New Love Interest

 You can Investigate ANYTHING and ANYONE:
Locate people and their - credit - social security - military - school - driving - or criminal records - age - employment history - addresses - phone numbers (some unlisted) - locate hidden assets - car they drive - value of home
check family trees - and much, much more...

For more information Click Here!

All requests to be taken off our mailing list are honored Immediately and AUTOMATICALLY upon receipt.

Click here to be taken off our mailing list.

PLEASE know that efforts to disrupt, close or block this Link to our "Removal List" can ONLY result in difficulties and prevention of others who desire removal from our mailing list.

ARE YOU AWARE THAT... each year, over 400 million trees are cut down in order to provide the paper for the "postal" bulk mail industry in the United States? By using e-mail instead, we can significantly reduce this unessary consumption as well as decrease the billions of tons of resulting waste material that clogs our landfills. SAVE THE TREES, SAVE THE PLANET, USE E-MAIL INSTEAD!


Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 10 00:54:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00374 for ; Mon, 12 Mar 2001 16:03:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Mar 2001 16:03:27 +0100 (MET) Received: (qmail 4846 invoked by uid 0); 9 Mar 2001 23:47:49 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx21) with SMTP; 9 Mar 2001 23:47:49 -0000 X-eGroups-Return: sentto-1101623-2496-984181667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 09 Mar 2001 23:47:48 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 9 Mar 2001 23:47:47 -0000 Received: (qmail 55152 invoked from network); 9 Mar 2001 23:47:46 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 Mar 2001 23:47:46 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta3 with SMTP; 10 Mar 2001 00:48:50 -0000 Received: from f-cpu.org (nas3-53.ras.club-internet.fr [195.36.203.53]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA21517 for ; Sat, 10 Mar 2001 00:47:40 +0100 (MET) Message-ID: <3AA96D1E.23D2F1EC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 10 Mar 2001 00:54:06 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] a week in Munich Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

for the DATE event, and because i like the town,
want to meet some friends, have fun out of France etc...
i'll be absent during a week. I don't know if i'll be able
to read the mails. I'll try to meet Fabian Sturm,
an english reporter, and i'll speak german.
read you anytime soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@club-internet.fr Mon Mar 12 16:34:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01804 for ; Mon, 12 Mar 2001 22:37:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Mar 2001 22:37:41 +0100 (MET) Received: (qmail 26891 invoked by uid 0); 12 Mar 2001 15:34:48 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx10) with SMTP; 12 Mar 2001 15:34:48 -0000 X-eGroups-Return: sentto-1101623-2497-984411286-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 12 Mar 2001 15:34:47 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 12 Mar 2001 15:34:46 -0000 Received: (qmail 27813 invoked from network); 12 Mar 2001 15:34:43 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 12 Mar 2001 15:34:43 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta2 with SMTP; 12 Mar 2001 15:34:43 -0000 Received: (from mnet@localhost) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA08227 for f-cpu@egroups.com; Mon, 12 Mar 2001 16:34:41 +0100 (MET) To: f-cpu@yahoogroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 12 Mar 2001 16:34:41 +0100 (MET) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] =?iso-8859-1?Q?=D6konux_conference?= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www.opentheory.org/ox_event.phtml?eid=4
The time slot and date is determined.

look also at :
http://www.opentheory.org/ox_abstr.phtml
Graham is scheduled the day after me :-)

Ok, DATE starts tomorrow, please don't
flood my mailbox while i'm away ;-)

read you soon,
YG
Yahoo! Groups Sponsor
  

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Mar 11 23:15:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA01810 for ; Mon, 12 Mar 2001 22:37:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 12 Mar 2001 22:37:42 +0100 (MET) Received: (qmail 31819 invoked by uid 0); 12 Mar 2001 15:59:57 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx23) with SMTP; 12 Mar 2001 15:59:57 -0000 X-eGroups-Return: sentto-1101623-2498-984412795-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 12 Mar 2001 15:59:56 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 12 Mar 2001 15:59:54 -0000 Received: (qmail 92111 invoked from network); 12 Mar 2001 15:59:52 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 12 Mar 2001 15:59:52 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 12 Mar 2001 15:59:52 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA26272 for ; Mon, 12 Mar 2001 08:59:49 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AABF8EF.BA491C05@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 11 Mar 2001 15:15:11 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] =?iso-8859-1?Q?=D6konux?= conference Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N whygee@club-internet.fr wrote:
> Ok, DATE starts tomorrow, please don't
> flood my mailbox while i'm away ;-)

Hire a computer sitter to watch the mail. :)
Anyhow have a successful trip.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Get your Credit Report online!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Pablo Escribano Tue Mar 13 09:42:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00319 for ; Tue, 13 Mar 2001 16:58:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 16:58:28 +0100 (MET) Received: (qmail 18618 invoked by uid 0); 13 Mar 2001 08:42:45 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx14) with SMTP; 13 Mar 2001 08:42:45 -0000 X-eGroups-Return: sentto-1101623-2499-984472960-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 13 Mar 2001 08:42:40 -0000 X-Sender: peloza@LatinMail.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 08:42:39 -0000 Received: (qmail 35125 invoked from network); 13 Mar 2001 08:42:39 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 13 Mar 2001 08:42:39 -0000 Received: from unknown (HELO web1363.dn.net) (216.167.63.81) by mta1 with SMTP; 13 Mar 2001 08:42:38 -0000 Received: from latinmail.com [216.167.63.176] by web1363.dn.net (SMTPD32-6.00) id AD7C98A00B2; Tue, 13 Mar 2001 03:42:36 -0500 To: f-cpu@yahoogroups.com X-Mailer: LatinMail v3.0 -- http://www.latinmail.com Message-Id: <200103130342186.SM00200@latinmail.com> From: Pablo Escribano MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 03:42:38 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] I want work in this project Content-Type: text/plain Content-Transfer-Encoding: 8bit Status: R X-Status: N Hello i am a student of I.T. Informática de Sistemas (hardware),I want work in your project, what can i do? bye AuTHoR NoNes _________________________________________________________ http://www.latinmail.com. Gratuito, latino y en español. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Make good on the promise you made at graduation to keep in touch. Classmates.com has over 14 million registered high school alumni--chances are you'll find your friends! http://us.click.yahoo.com/l3joGB/DMUCAA/4ihDAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From whygee@club-internet.fr Tue Mar 13 16:23:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00352 for ; Tue, 13 Mar 2001 16:58:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 16:58:39 +0100 (MET) Received: (qmail 27263 invoked by uid 0); 13 Mar 2001 15:33:09 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx18) with SMTP; 13 Mar 2001 15:33:09 -0000 X-eGroups-Return: sentto-1101623-2500-984496993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 13 Mar 2001 15:23:14 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 15:23:12 -0000 Received: (qmail 23954 invoked from network); 13 Mar 2001 15:23:11 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 13 Mar 2001 15:23:11 -0000 Received: from unknown (HELO front9.grolier.fr) (194.158.96.59) by mta2 with SMTP; 13 Mar 2001 15:23:11 -0000 Received: (from mnet@localhost) by front9.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id QAA11511 for f-cpu@yahoogroups.com; Tue, 13 Mar 2001 16:23:09 +0100 (MET) To: f-cpu@yahoogroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 16:23:09 +0100 (MET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] I want work in this project Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hello,

>Hello
>i am a student of I.T. Inform=E1tica de Sistemas (hardware),I want work= in your project, what can i do?

a lot :-)

- spread the word around you that there is a free CPU project
- translate the manual to your langage
- writing some VHDL, or C code for the emulator or the compiler ...

but if something is sure, it is : it's not easy.
now you're warned ;-) if you understand that, it's ok.

>bye
>
>AuTHoR NoNes

regards, YG
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Carlos De Urresti Hannoh" Tue Mar 13 16:27:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00392 for ; Tue, 13 Mar 2001 20:10:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 20:10:33 +0100 (MET) Received: (qmail 21100 invoked by uid 0); 13 Mar 2001 15:37:43 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx02) with SMTP; 13 Mar 2001 15:37:43 -0000 X-eGroups-Return: sentto-1101623-2501-984497628-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jj.egroups.com with NNFMP; 13 Mar 2001 15:33:48 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 15:33:47 -0000 Received: (qmail 51827 invoked from network); 13 Mar 2001 15:33:39 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 13 Mar 2001 15:33:39 -0000 Received: from unknown (HELO mail.gmx.net) (194.221.183.20) by mta3 with SMTP; 13 Mar 2001 16:34:43 -0000 Received: (qmail 27143 invoked by uid 0); 13 Mar 2001 15:26:57 -0000 Received: from x.triara.com (HELO oemcomputer) (200.57.128.65) by mail.gmx.net (mp003-rz3) with SMTP; 13 Mar 2001 15:26:57 -0000 Message-ID: <003b01c0abd2$0e9e2160$750114ac@triara.apodaca> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Carlos De Urresti Hannoh" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 09:27:02 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Becoming an member. Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C0AB9F.C2FEC480" Status: R X-Status: N ------=_NextPart_000_0038_01C0AB9F.C2FEC480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable F-CPU's mailinglist: My name is Carlos Uresti and as Pablo Escribano stays, I would also like to= become a member of your team work. I just ended HS and started to look ove= r your manual; which far the most of it is uncomprensible to me at this act= ual stage. One of things that life has come to teach me is that noone is so low or hig= h in knowledge and still claim that if you're in the low side can't help ot= hers. I'm sure that my help could be fowarded to another area or somewhere where = my skill are usuable. I could get in contact with one of you to talk about = the areas where I could help out. Thanks for reading this email, Carlos Uresti. ------=_NextPart_000_0038_01C0AB9F.C2FEC480 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
F-CPU's mailinglist:
 
My name is Carlos Uresti and as Pablo Escribano stays, I would also like to become a member of your team work. I just ended HS and started to look over your manual; which far the most of it is uncomprensible to me at this actual stage.
 
One of things that life has come to teach me is that noone is so low or high in knowledge and still claim that if you're in the low side can't help others.
 
I'm sure that my help could be fowarded to another area or somewhere where my skill are usuable. I could get in contact with one of you to talk about the areas where I could help out.
 
Thanks for reading this email,
Carlos Uresti.

Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_000_0038_01C0AB9F.C2FEC480-- From Nicolas Matringe Tue Mar 13 16:39:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00410 for ; Tue, 13 Mar 2001 20:10:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 20:10:39 +0100 (MET) Received: (qmail 11591 invoked by uid 0); 13 Mar 2001 15:38:12 -0000 Received: from mx21.rz2.gmx.net (HELO hp.egroups.com) (10.1.72.121) by mxi1.gmx.net (mxi1) with SMTP; 13 Mar 2001 15:38:12 -0000 X-eGroups-Return: sentto-1101623-2502-984497883-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 13 Mar 2001 15:38:07 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 15:38:03 -0000 Received: (qmail 62015 invoked from network); 13 Mar 2001 15:38:01 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 13 Mar 2001 15:38:01 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 13 Mar 2001 15:38:01 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id PAA09617 for ; Tue, 13 Mar 2001 15:37:59 GMT X-To: Message-ID: <3AAE3F39.445A6E1E@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <003b01c0abd2$0e9e2160$750114ac@triara.apodaca> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 16:39:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Becoming an member. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > Carlos De Urresti Hannoh wrote:

> One of things that life has come to teach me is that noone is so
> low or high in knowledge and still claim that if you're in the
> low side can't help others.

One thing is sure with this project: noone will ever turn down anyone
:o)
If you know, come and teach; if you don't, come and learn.
--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Tue Mar 13 18:40:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00422 for ; Tue, 13 Mar 2001 20:10:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 20:10:43 +0100 (MET) Received: (qmail 6967 invoked by uid 0); 13 Mar 2001 17:42:32 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx24) with SMTP; 13 Mar 2001 17:42:32 -0000 X-eGroups-Return: sentto-1101623-2503-984505344-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 13 Mar 2001 17:42:25 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 17:42:23 -0000 Received: (qmail 61604 invoked from network); 13 Mar 2001 17:42:17 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Mar 2001 17:42:17 -0000 Received: from unknown (HELO orion.uk.insnet.net) (194.177.174.244) by mta2 with SMTP; 13 Mar 2001 17:42:16 -0000 Received: from ws133.warminsterschool.org.uk ([195.59.6.116]) by orion.uk.insnet.net (8.9.3/8.9.3) with SMTP id RAA21823; Tue, 13 Mar 2001 17:42:14 GMT Message-Id: <3.0.6.32.20010313174010.007bac30@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com, f-cpu@yahoogroups.com In-Reply-To: From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 17:40:10 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] I want work in this project Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Hi I'm also new in the project,
where can I get the publications and data for the actual one,
greetings Kris
At 16:23 13/03/01 +0100, whygee@club-internet.fr wrote:
>hello,
>
>>Hello
>>i am a student of I.T. Inform=E1tica de Sistemas (hardware),I want = work in
your project, what can i do?
>
>a lot :-)
>
>- spread the word around you that there is a free CPU project
>- translate the manual to your langage
>- writing some VHDL, or C code for the emulator or the compiler ...
>
>but if something is sure, it is : it's not easy.
>now you're warned ;-) if you understand that, it's ok.
>
>>bye
>>
>>AuTHoR NoNes
>
>regards, YG
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From orage@newmail.net Tue Mar 13 19:21:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00428 for ; Tue, 13 Mar 2001 20:10:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 13 Mar 2001 20:10:45 +0100 (MET) Received: (qmail 10840 invoked by uid 0); 13 Mar 2001 18:22:57 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx01) with SMTP; 13 Mar 2001 18:22:57 -0000 X-eGroups-Return: sentto-1101623-2504-984507773-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 13 Mar 2001 18:22:56 -0000 X-Sender: orage@newmail.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 18:22:52 -0000 Received: (qmail 19784 invoked from network); 13 Mar 2001 18:21:25 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 13 Mar 2001 18:21:25 -0000 Received: from unknown (HELO mu.egroups.com) (10.1.1.40) by mta1 with SMTP; 13 Mar 2001 18:21:25 -0000 X-eGroups-Return: orage@newmail.net Received: from [10.1.10.99] by mu.egroups.com with NNFMP; 13 Mar 2001 18:21:22 -0000 To: f-cpu@yahoogroups.com Message-ID: <98loet+u54s@eGroups.com> In-Reply-To: <3AAE3F39.445A6E1E@IPricot.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 200.57.128.65 From: orage@newmail.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 18:21:17 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Becoming an member. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N --- In f-cpu@y..., Nicolas Matringe <nicolas@D...> wrote:
> > Carlos De Urresti Hannoh wrote:
>
> > One of things that life has come to teach me is that noone is so
> > low or high in knowledge and still claim that if you're in the
> > low side can't help others.
>
> One thing is sure with this project: noone will ever turn down
anyone
> :o)
> If you know, come and teach; if you don't, come and learn.
Thanks for the message, I'll do my best to first learn and then help
out.
> --
> Nicolas MATRINGE           IPricot European Headquarters
> Conception electronique    10-12 Avenue de Verdun
> Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
> Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Boulay Tue Mar 13 23:21:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA01501 for ; Wed, 14 Mar 2001 04:16:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 14 Mar 2001 04:16:43 +0100 (MET) Received: (qmail 1145 invoked by uid 0); 13 Mar 2001 22:08:42 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx02) with SMTP; 13 Mar 2001 22:08:42 -0000 X-eGroups-Return: sentto-1101623-2505-984521321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fj.egroups.com with NNFMP; 13 Mar 2001 22:08:41 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 13 Mar 2001 22:08:39 -0000 Received: (qmail 22010 invoked from network); 13 Mar 2001 22:08:39 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 13 Mar 2001 22:08:39 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta1 with SMTP; 13 Mar 2001 22:08:38 -0000 Received: from ifrance.com (nas7-34.vlt.club-internet.fr [194.158.109.34]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA09496 for ; Tue, 13 Mar 2001 23:08:36 +0100 (MET) Message-ID: <3AAE9D79.5E1F4349@ifrance.com> X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <003b01c0abd2$0e9e2160$750114ac@triara.apodaca> <3AAE3F39.445A6E1E@IPricot.com> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 13 Mar 2001 23:21:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] TODO... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N After trying to understand the manual you should try to find the lack
inside it. (main site : www.f-cpu.de) Then you could try to help to code the emulator (soon begin)(add unit latency ).
You could use it to try to code some usual algorithme to see how we
could handel variable size registers and SIMD stuff.
Then try to code some unit in vhdl.
Begin to see how to build a "good" C compiler (to optimise the us= e of
SIMD, ILP, and specific instructions).
See what could be done for the internal architecture of the decoder and
all the control stuff. (we should see if a bypass network is needed).
Resume the main point of the fcpu to write a general article for the HAL conference. (SIMD, large registre bank, no predicat by using
conditionnal move, out of order completion, scoreboard, in the futur :
SMT, superscalar, long pipeline,...)

nicO

Nicolas Matringe a =E9crit :
>
> > Carlos De Urresti Hannoh wrote:
>
> > One of things that life has come to teach me is that noone is so<= BR> > > low or high in knowledge and still claim that if you're in the > > low side can't help others.
>
> One thing is sure with this project: noone will ever turn down anyone<= BR> > :o)
> If you know, come and teach; if you don't, come and learn.
> --
> Nicolas MATRINGE         =   IPricot European Headquarters
> Conception electronique    10-12 Avenue de Verdun
> Tel +33 1 46 52 53 11      F-92250 LA GARENNE= -COLOMBES - FRANCE
> Fax +33 1 46 52 53 01      http://www.IPricot.com/
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Cla=
Click here for Classmates.com
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From lN37piH1w@smtp.plusnet.ch Sun Apr 19 14:02:53 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA03250 for ; Thu, 15 Mar 2001 10:25:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 15 Mar 2001 10:25:56 +0100 (MET) Received: (qmail 1038 invoked by uid 0); 15 Mar 2001 00:31:36 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx17) with SMTP; 15 Mar 2001 00:31:36 -0000 X-eGroups-Return: sentto-1101623-2506-984616294-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 15 Mar 2001 00:31:35 -0000 X-Sender: lN37piH1w@smtp.plusnet.ch X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 15 Mar 2001 00:31:33 -0000 Received: (qmail 68295 invoked from network); 15 Mar 2001 00:31:32 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 15 Mar 2001 00:31:32 -0000 Received: from unknown (HELO mail.layana.com.tw) (210.244.66.66) by mta1 with SMTP; 15 Mar 2001 00:31:30 -0000 Received: from E9zP4qtbt (ts010d14.hou-tx.concentric.net [216.112.141.218]) by mail.layana.com.tw (8.9.3/8.8.7) with SMTP id IAA05366; Thu, 15 Mar 2001 08:21:55 +0800 Message-ID: <45H7p@QTm99VJ9Ir> From: lN37piH1w@smtp.plusnet.ch MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: 14 Mar 01 8:34:37 PM Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Make the right decision 919 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Status: R X-Status: N Look, we don't want to waste your time.... or ours

You must be determined to earn a bare minimum of 10,000 in the next
30-45 days and to develop a net worth of over 1 million dollars cash
in the next 24-36 months. My mission is to help other people develop their life long dreams. And part of what I'm looking for are those people who are committed to that big of a picture and are not afraid to work for it.
                 We can help you.
       
                  REGARDLESS OF YOUR CURRENT AGE
                              OR YOUR DEBT LOAD!

                              NOT MLM or FRANCHISE

                      Don't bother to call unless you are serious.
             Learn the facts CALL 1-800-694-5128

                              EASY $10,000 in 30-45 DAYS

**********************************************************************************
ALL REMOVE requests AUTOMATICALLY honored upon receipt.
mailto:stop008@excite.com?subject=remove
Please understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction is not received.
**********************************************************************************
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed Mar 14 08:46:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00410 for ; Sat, 17 Mar 2001 15:55:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Mar 2001 15:55:38 +0100 (MET) Received: (qmail 30565 invoked by uid 0); 16 Mar 2001 19:00:10 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx11) with SMTP; 16 Mar 2001 19:00:10 -0000 X-eGroups-Return: sentto-1101623-2507-984768922-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 16 Mar 2001 18:55:22 -0000 X-Sender: biotechstox6@earthlink.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 16 Mar 2001 18:55:21 -0000 Received: (qmail 52551 invoked from network); 16 Mar 2001 18:55:21 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 16 Mar 2001 18:55:21 -0000 Received: from unknown (HELO mail.2500sz.com) (211.95.85.36) by mta3 with SMTP; 16 Mar 2001 19:56:25 -0000 Received: (qmail 13592 invoked by uid 0); 14 Mar 2001 12:49:37 -0000 Received: from unknown (HELO earthlink.net) (unknown) by unknown with SMTP; 14 Mar 2001 12:49:36 -0000 To: f-cpu@yahoogroups.com Message-Id: <8.78605.783387@earthlink.net> X-eGroups-From: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 14 Mar 2001 07:46:58 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] FREE Biotech Stock Info! 847 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Do you want to capitalize on the Biotech Revolution

Do you want to capitalize on the Biotech Revolution? Would you like to add groundbreaking biotech, pharmaceutical and medical device companies to your portfolio mix? Does hearing about exciting IPO and private placement offerings >from life sciences companies interest you?

The exclusive Ruddy-Carlisle Biotech Infoline service keeps you abreast of investment opportunities in the life sciences space. Just sign up for it once and get important information instantly delivered to study at your leisure. Our service is 100% FREE! Sign up!

Ruddy-Carlisle Biotech Infoline:

  • Instantly delivers key life sciences investment information directly to you!
  • Learn about biotech, pharmaceutical & medical device investment opportunities before others!
  • Includes IPO & private placement information!
  • 100% FREE!

For the entire last decade there were only three profitable biotech companies. At the end of this year, ten are projected. At the end of 2003, over forty are projected! The genomic promise is about to be delivered and investors know it. The Ruddy-Carlisle Biotech Infoline provides you with critical, decision-making, information that aids the chance of investment success in this lucrative space. Sign up!

Please Note- Your information will only be shared with companies that are in the life sciences space and pass our rigorous inspection. Only the best opportunities will come to you. Ruddy-Carlisle respects your privacy. Sign up!

 

 

List Removal Instructions- Simply click here: remove to be instantly and permanently removed from our list. Send the blank email to the address specified. Please do not try to reply to this message.
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Fri Mar 16 23:10:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00453 for ; Sat, 17 Mar 2001 15:55:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 17 Mar 2001 15:55:49 +0100 (MET) Received: (qmail 9507 invoked by uid 0); 16 Mar 2001 22:04:04 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx11) with SMTP; 16 Mar 2001 22:04:04 -0000 X-eGroups-Return: sentto-1101623-2508-984780242-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 16 Mar 2001 22:04:03 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 16 Mar 2001 22:04:01 -0000 Received: (qmail 27129 invoked from network); 16 Mar 2001 22:04:01 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 Mar 2001 22:04:01 -0000 Received: from unknown (HELO front3m.grolier.fr) (195.36.216.53) by mta1 with SMTP; 16 Mar 2001 22:04:00 -0000 Received: from f-cpu.org (nas1-172.ras.club-internet.fr [195.36.192.172]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA17874 for ; Fri, 16 Mar 2001 23:03:56 +0100 (MET) Message-ID: <3AB28F55.95AD7CA8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 16 Mar 2001 23:10:29 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] hi ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello !

i'm back home. there are hundreds of mails piling up in
my mailbox. i wish i never went home, to avoid that heavy
task, it was so nice in Munich. I'll need a few days to be
"completely" back online, enough time to test if the electric
fans i bought are working correctly.

I was unable to meet Fabian at the ICM/DATE place,
but i could see Peter Clarke (EDTN) a few minutes.
and i also got some numerous business card from
a lot of different people.

Next year, DATE2002 will be held in Paris. I hope that
other F-cpuers will be part of the party :-)

i have a lot of other news, but no time ;
i'll keep you informed !

read you,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Classmates.com
Click here for Classmates.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From naomi_bernsteinus@yahoo.com Sun Mar 18 21:15:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00449 for ; Tue, 20 Mar 2001 18:46:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:08 +0100 (MET) Received: (qmail 26495 invoked by uid 0); 18 Mar 2001 20:17:38 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx03) with SMTP; 18 Mar 2001 20:17:38 -0000 X-eGroups-Return: sentto-1101623-2509-984946656-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 18 Mar 2001 20:17:36 -0000 X-Sender: bafesfcu@altavista.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 18 Mar 2001 20:17:35 -0000 Received: (qmail 3533 invoked from network); 18 Mar 2001 20:17:35 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 18 Mar 2001 20:17:35 -0000 Received: from unknown (HELO home.mfec.co.th) (203.144.251.252) by mta1 with SMTP; 18 Mar 2001 20:17:34 -0000 Received: from [216.3.181.170] by home.mfec.co.th (Netscape Messaging Server 3.6) with SMTP id AAD592; Mon, 19 Mar 2001 03:05:53 +0700 Message-ID: <00002ed01455$000008de$0000300b@> To: Undisclosed.Recipients@home.mfec.co.th X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: bafesfcu@altavista.net From: naomi_bernsteinus@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Mar 2001 12:15:34 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Free consultation Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Status: R X-Status: N Interested in Renting or Selling your Timeshare or Vacation Membership? We can help! For a FREE consultation simply reply with your name and telephone number. Also include the name of your resort. We will be in touch with you shortly! Have a great Day! Removal instructions: ************************************* To be removed from this list please reply with "remove" in the subject. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Make good on the promise you made at graduation to keep in touch. Classmates.com has over 14 million registered high school alumni--chances are you'll find your friends! http://us.click.yahoo.com/l3joGB/DMUCAA/4ihDAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Nathan Clark Mon Mar 19 04:10:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00464 for ; Tue, 20 Mar 2001 18:46:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:11 +0100 (MET) Received: (qmail 24853 invoked by uid 0); 19 Mar 2001 03:10:08 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx07) with SMTP; 19 Mar 2001 03:10:08 -0000 X-eGroups-Return: sentto-1101623-2510-984971405-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 19 Mar 2001 03:10:06 -0000 X-Sender: ntclark@engin.umich.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 03:10:05 -0000 Received: (qmail 39416 invoked from network); 19 Mar 2001 03:10:04 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Mar 2001 03:10:04 -0000 Received: from unknown (HELO srvr22.engin.umich.edu) (141.213.75.21) by mta2 with SMTP; 19 Mar 2001 03:10:04 -0000 Received: from azure.engin.umich.edu (root@azure.engin.umich.edu [141.213.74.24]) by srvr22.engin.umich.edu (8.9.3/8.9.1) with ESMTP id WAA16381 for ; Sun, 18 Mar 2001 22:10:03 -0500 (EST) Received: from localhost (ntclark@localhost [127.0.0.1]) by azure.engin.umich.edu (8.9.3/8.9.1) with SMTP id WAA11983 for ; Sun, 18 Mar 2001 22:10:02 -0500 (EST) To: f-cpu@yahoogroups.com In-Reply-To: <00002ed01455$000008de$0000300b@> Message-ID: From: Nathan Clark MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Mar 2001 22:10:02 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Free consultation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
is there anything that can be done about all the unsolicited spam on this
e-mail group? sometimes it seems like we get more spam than cpu
information...

-nate


On Sun, 18 Mar 2001 naomi_bernsteinus@yahoo.com wrote:

>
>
> Interested in Renting or Selling your
> Timeshare or Vacation Membership?
>
>            We can help!
>
>
> For a FREE consultation simply reply
> with your name and telephone number.
> Also include the name of your resort.
> We will be in touch with you shortly!
>
>
>         Have a great Day!
>
>
>
>
>
> Removal instructions:
> *************************************
> To be removed from this list please
> reply with "remove" in the subject.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon Mar 19 04:44:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00467 for ; Tue, 20 Mar 2001 18:46:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:14 +0100 (MET) Received: (qmail 2662 invoked by uid 0); 19 Mar 2001 03:54:47 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx07) with SMTP; 19 Mar 2001 03:54:47 -0000 X-eGroups-Return: sentto-1101623-2511-984974086-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 19 Mar 2001 03:54:46 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 03:54:45 -0000 Received: (qmail 41435 invoked from network); 19 Mar 2001 03:54:44 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 19 Mar 2001 03:54:44 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 19 Mar 2001 03:54:44 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA26287 for ; Sun, 18 Mar 2001 20:54:40 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AB5809D.82C18B8C@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 18 Mar 2001 20:44:29 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Free consultation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nathan Clark wrote:
>
> is there anything that can be done about all the unsolicited spam on this
> e-mail group? sometimes it seems like we get more spam than cpu
> information...

What and have Yahoo not make money.
While it has been quiet I expect now that
Whygee is back things will pick up.
Ben.
PS. Why have a 64 bit cpu... go 72 and bring back 9 bit bytes. :-)

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Craig Strickland Mon Mar 19 06:36:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00473 for ; Tue, 20 Mar 2001 18:46:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:15 +0100 (MET) Received: (qmail 5873 invoked by uid 0); 19 Mar 2001 05:48:20 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx05) with SMTP; 19 Mar 2001 05:48:20 -0000 X-eGroups-Return: sentto-1101623-2512-984980893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 19 Mar 2001 05:48:14 -0000 X-Sender: tgi@pobox.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 05:48:12 -0000 Received: (qmail 82748 invoked from network); 19 Mar 2001 05:48:12 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Mar 2001 05:48:12 -0000 Received: from unknown (HELO scribe.pobox.com) (208.210.124.35) by mta3 with SMTP; 19 Mar 2001 06:49:16 -0000 Received: from tgi600 (adsl-61-124-62.cha.bellsouth.net [208.61.124.62]) by scribe.pobox.com (Postfix) with SMTP id 118A3325FE for ; Mon, 19 Mar 2001 00:48:11 -0500 (EST) Message-Id: <4.1.20010319003320.05586430@mail.lig.bellsouth.net> X-Sender: tgi@pobox.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: F-CPU Mailing List In-Reply-To: References: <00002ed01455$000008de$0000300b@> From: Craig Strickland MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 00:36:21 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Free consultation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N At 22:10 03/18/2001 -0500, Nathan Clark wrote:
>is there anything that can be done about all the unsolicited spam on this
>e-mail group? sometimes it seems like we get more spam than cpu
>information...
>
>-nate

One very simple solution is for the list owner to set the "posting
permission" to "list member only".  This won't eliminate spam, but will
greatly reduce it, since this will require a potential spammer to subscribe
to the list.

It's worked well on the lists that I manage.
--
Internet:  tgi@pobox.com                  Physical:  26 19'06"N  80 13'29"W
Web:       http://pobox.com/~tgi/         Amateur:   KE4QJN        [EL96VH]
ICQ Pager: http://www.icq.com/6866658     eFax:      +1 781 240-0321
PGP Key:   0x45678F65 available from server: pgp-public-keys@pgp.mit.edu
           Fingerprint: 66 14 7F 90 E4 7C 9D 60  53 72 09 96 6C 4D 4A 8B
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Mar 19 12:31:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00482 for ; Tue, 20 Mar 2001 18:46:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:19 +0100 (MET) Received: (qmail 29480 invoked by uid 0); 19 Mar 2001 11:42:29 -0000 Received: from mx21.rz2.gmx.net (HELO ch.egroups.com) (10.1.72.121) by mxi1.gmx.net (mxi1) with SMTP; 19 Mar 2001 11:42:29 -0000 X-eGroups-Return: sentto-1101623-2513-985001901-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ch.egroups.com with NNFMP; 19 Mar 2001 11:38:22 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 11:38:20 -0000 Received: (qmail 97625 invoked from network); 19 Mar 2001 11:38:20 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Mar 2001 11:38:20 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 19 Mar 2001 11:38:20 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA06489; Mon, 19 Mar 2001 03:38:16 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8P6Q; Mon, 19 Mar 2001 11:43:51 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB5EE02.77B57003@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <00002ed01455$000008de$0000300b@> <4.1.20010319003320.05586430@mail.lig.bellsouth.net> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 12:31:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Free consultation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Craig Strickland wrote:
> At 22:10 03/18/2001 -0500, Nathan Clark wrote:
> >is there anything that can be done about all the unsolicited spam on this
> >e-mail group? sometimes it seems like we get more spam than cpu
> >information...
> >
> >-nate
>
> One very simple solution is for the list owner to set the "posting
> permission" to "list member only".  This won't eliminate spam, but will
> greatly reduce it, since this will require a potential spammer to subscribe
> to the list.
>
> It's worked well on the lists that I manage.

hello ! (i'm back to "work")

for those people who don't know,
the mailing list is in "automatic pilot",
the real "pilot" has jumped out of the cockpit
for more than two years.

it means that the person who created the list
(and is meant to manage it) no longer "exists",
and nobody manages this list.

however i manage (with co-pilots) a french list
which i successfully moved away from yahoo_groups :
i have access to the subscriber list and could copy-paste
it to a more stable server. This can't be done on this list
because nobody has management permission.

we'll try to use seul.org's new server to setup a parallel
list to this list. however the move will be difficult
and long since it is not automated.

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Mar 19 15:44:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00491 for ; Tue, 20 Mar 2001 18:46:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:21 +0100 (MET) Received: (qmail 31851 invoked by uid 0); 19 Mar 2001 14:52:04 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx19) with SMTP; 19 Mar 2001 14:52:04 -0000 X-eGroups-Return: sentto-1101623-2515-985013521-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ci.egroups.com with NNFMP; 19 Mar 2001 14:52:02 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 14:52:00 -0000 Received: (qmail 50390 invoked from network); 19 Mar 2001 14:52:00 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 19 Mar 2001 14:52:00 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 19 Mar 2001 14:52:00 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA15863; Mon, 19 Mar 2001 06:51:57 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8QF6; Mon, 19 Mar 2001 14:57:33 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB61B67.4575A32A@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" Cc: Roger Dingledine References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 15:44:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N "Tore" wrote:
> Yann,
>         could you add me to the new mailing server or provide info about the
> new listserver so that I can unsubscribe from the yahoo f-cpu list?  Are
> messages crossposted?

hello,

unfortunately the new list is not (yet) open.
it will be a long process and we'll need everybody's combined efforts,
so let's not do it too quickly.

First, i think that the seul.org site is best suited for hosting
the f-cpu list : it is commited to the open and independent community,
it is seriously managed and it works. This means that if a little
thing goes wrong, everybody will not be harmed (like it happened
with this list). If others have a better proposition, please speak out.

Second, we need a team of 3 persons, one will be the manager of the list
and 2 others are here to backup, in case of vacation or simply absence
of the list owner. This ensures that we don't have to call the seul.org
maintainers everytime something goes wrong. So we need three serious
managers, and i don't volunteer because i have enough workload already ;-)
Who volunteers ?

When the list is open and the managers will be voted, the migration will start.

> Cheers,
> Tore

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Mar 19 14:57:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00500 for ; Tue, 20 Mar 2001 18:46:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:26 +0100 (MET) Received: (qmail 19646 invoked by uid 0); 19 Mar 2001 14:04:29 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx02) with SMTP; 19 Mar 2001 14:04:29 -0000 X-eGroups-Return: sentto-1101623-2514-985010666-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 19 Mar 2001 14:04:27 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 14:04:26 -0000 Received: (qmail 16344 invoked from network); 19 Mar 2001 14:04:25 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 19 Mar 2001 14:04:25 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 19 Mar 2001 14:04:25 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA12677; Mon, 19 Mar 2001 06:04:10 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8QD7; Mon, 19 Mar 2001 14:09:47 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB61034.1F48D90@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: Gerrit Hiddink Cc: "f-cpu@egroups.com" References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 14:57:08 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: F-CPU participation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Gerrit Hiddink wrote:
> > > Can you please elaborate a bit more on F-CPU?
> > well, a simple search on Google will give you most of the informations ;-)
> Uh /me is ashamed... I should have thought of that myself :/
;-)

> I like the project! Open Source hardware :)
there are others like that at the opencollector.org website :-)

> You're more than welcome to do some presentations or workshops on F-CPU
> during HAL 2001. Please send me details about who's going to tell what
> once you have clarity on this ;)

This participation was proposed by Trollhunter,
member of linuxfr.org, who will come to the HAL with his team.
Trollhunter has offered some support to the f-cpu team.
I hope that several french and german people will come.
we will try to make a "f-cpu lounge" or something like that,
where we can make workshops, discuss endlessly without worrying
about the schedule... hmm, we'll have to make a nice flag so
everybody can see were we are ;-)

not everything is organised yet, it has just started.
we'll keep you informed.

> Regards, Grit
"Dank you well" :-)
YG

speaking for himself
Yahoo! Groups Sponsor
Click here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Mon Mar 19 21:49:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00593 for ; Tue, 20 Mar 2001 18:46:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:46:56 +0100 (MET) Received: (qmail 14123 invoked by uid 0); 19 Mar 2001 20:20:55 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx12) with SMTP; 19 Mar 2001 20:20:55 -0000 X-eGroups-Return: sentto-1101623-2516-985033188-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mv.egroups.com with NNFMP; 19 Mar 2001 20:19:49 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 20:19:47 -0000 Received: (qmail 7159 invoked from network); 19 Mar 2001 20:19:46 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Mar 2001 20:19:46 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta2 with SMTP; 19 Mar 2001 20:19:37 -0000 Received: from art1.none.de (dialin129.pg1-nt.berlin.nikoma.de [213.54.64.129]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f2JKJeb29113 for ; Mon, 19 Mar 2001 21:19:40 +0100 X-Authentication-Warning: host-2.server.itns.de: Host dialin129.pg1-nt.berlin.nikoma.de [213.54.64.129] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14f6ab-0005KQ-00; Mon, 19 Mar 2001 21:49:17 +0100 To: "f-cpu@egroups.com" Cc: Roger Dingledine In-Reply-To: <3AB61B67.4575A32A@mentor.com> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 21:49:17 +0100 (CET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> thing goes wrong, everybody will not be harmed (like it happened
> with this list). If others have a better proposition, please speak out.

GAOS offers an access to a mailman-based mailinglist, if you like. GAOS is
an organization to support open and free technologies and projects.

More infos about us under http://gaos.org

If you interested in our offer please do not hesitate to contact me via
eMail: andreas.romeyke@web.de


Bye Andreas
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Paul Marques Mota Mon Mar 19 22:17:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00608 for ; Tue, 20 Mar 2001 18:47:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:47:01 +0100 (MET) Received: (qmail 8570 invoked by uid 0); 19 Mar 2001 21:19:34 -0000 Received: from mx26.rz2.gmx.net (HELO fj.egroups.com) (10.1.72.126) by mxi1.gmx.net (mxi1) with SMTP; 19 Mar 2001 21:19:34 -0000 X-eGroups-Return: sentto-1101623-2517-985036675-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 19 Mar 2001 21:17:56 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 21:17:55 -0000 Received: (qmail 64948 invoked from network); 19 Mar 2001 21:17:20 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 19 Mar 2001 21:17:20 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 19 Mar 2001 21:17:19 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14f71i-00003S-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 22:17:18 +0100 Received: from alpha4.bocal.cs.univ-paris8.fr ([192.168.3.7]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14f71h-0002Do-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 22:17:17 +0100 Received: from mota by alpha4.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 14f71h-0004Uk-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 22:17:17 +0100 To: f-cpu@yahoogroups.com Message-ID: <20010319221717.A13651@bocal.cs.univ-paris8.fr> References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> <3AB61B67.4575A32A@mentor.com> User-Agent: Mutt/1.0.1i In-Reply-To: <3AB61B67.4575A32A@mentor.com>; from whygee@f-cpu.org on Mon, Mar 19, 2001 at 03:44:55PM +0100 Sender: Paul MARQUES MOTA From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 22:17:17 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Mar 19, 2001 at 03:44:55PM +0100, Yann GUIDON wrote:
> hello,
>

Bonsoir :)

>
> First, i think that the seul.org site is best suited for hosting
> the f-cpu list :

I do think that too.

>
> Second, we need a team of 3 persons, one will be the manager of the list

The french mailing-list has only two maintainers, (Yann Guidon and myself)
and it seems to be running nicely for now...

> and 2 others are here to backup, in case of vacation or simply absence
> of the list owner. This ensures that we don't have to call the seul.org
> maintainers everytime something goes wrong. So we need three serious
> managers, and i don't volunteer because i have enough workload already ;-)
> Who volunteers ?
>
> When the list is open and the managers will be voted, the migration will start.

On a related note, I also think that we need a german mailing-list. What do
you think of that?

>
> YG
>

--
      Paul
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Mon Mar 19 22:39:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00620 for ; Tue, 20 Mar 2001 18:47:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:47:04 +0100 (MET) Received: (qmail 21214 invoked by uid 0); 19 Mar 2001 21:41:55 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx04) with SMTP; 19 Mar 2001 21:41:55 -0000 X-eGroups-Return: sentto-1101623-2518-985038050-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mr.egroups.com with NNFMP; 19 Mar 2001 21:41:53 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 21:40:50 -0000 Received: (qmail 44140 invoked from network); 19 Mar 2001 21:40:12 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 19 Mar 2001 21:40:12 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.115) by mta2 with SMTP; 19 Mar 2001 21:40:11 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f2JLdSN01132 for ; Mon, 19 Mar 2001 22:39:40 +0100 Message-Id: <200103192139.f2JLdSN01132@PrintServer.LedCom> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <20010319221717.A13651@bocal.cs.univ-paris8.fr> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 22:39:32 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >> Second, we need a team of 3 persons, one will be the manager of the list
>
>The french mailing-list has only two maintainers, (Yann Guidon and myself)
>and it seems to be running nicely for now...
>
>> and 2 others are here to backup, in case of vacation or simply absence
>> of the list owner. This ensures that we don't have to call the seul.org
>> maintainers everytime something goes wrong. So we need three serious
>> managers, and i don't volunteer because i have enough workload already ;-)
>> Who volunteers ?

  What are exactly the tasks of the maintainers ?  I might be
interested, but I don't have a lot of time, and I have a
"response time" of about 1 to 2 days.  But if the workload is
not too heavy ...

      Guillaume Lederrey


Laws of computer programming
============================

1) any given program, when running,
   is obselete
2) any given program costs more and
   takes longer
3) if a program is useful, it will
   have to be changed
4) if a program is useless, it will
   have to be documented
5) any given program will expand
   to fill all available memory
6) the value of a program is proportional
   the weight of its output
7) program complexity grows until
   it exceeds the capability of
   the programmer who must maintain it
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon Mar 19 12:06:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00626 for ; Tue, 20 Mar 2001 18:48:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:03 +0100 (MET) Received: (qmail 6546 invoked by uid 0); 19 Mar 2001 21:53:48 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx10) with SMTP; 19 Mar 2001 21:53:48 -0000 X-eGroups-Return: sentto-1101623-2519-985038829-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 19 Mar 2001 21:53:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 21:53:49 -0000 Received: (qmail 63028 invoked from network); 19 Mar 2001 21:53:49 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 19 Mar 2001 21:53:49 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 19 Mar 2001 22:54:51 -0000 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA00143 for ; Mon, 19 Mar 2001 14:53:38 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AB5E84A.20B205F0@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103192139.f2JLdSN01132@PrintServer.LedCom> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 04:06:50 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >
> Laws of computer programming
> ============================

What ever happened to the rule of thumb" 90% of the time for the first 90% of
code
and the other 90% of the time for the remaining 10% after management decides it
is needed yesterday"
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Paul Marques Mota Mon Mar 19 23:29:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00644 for ; Tue, 20 Mar 2001 18:48:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:10 +0100 (MET) Received: (qmail 12742 invoked by uid 0); 19 Mar 2001 22:29:56 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx02) with SMTP; 19 Mar 2001 22:29:56 -0000 X-eGroups-Return: sentto-1101623-2520-985040996-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 19 Mar 2001 22:29:58 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 19 Mar 2001 22:29:56 -0000 Received: (qmail 58531 invoked from network); 19 Mar 2001 22:29:55 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 19 Mar 2001 22:29:55 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 19 Mar 2001 22:29:54 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14f89x-0000II-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 23:29:53 +0100 Received: from alpha4.bocal.cs.univ-paris8.fr ([192.168.3.7]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14f89w-0002TQ-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 23:29:52 +0100 Received: from mota by alpha4.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 14f89w-0005DQ-00 for f-cpu@yahoogroups.com; Mon, 19 Mar 2001 23:29:52 +0100 To: f-cpu@yahoogroups.com Message-ID: <20010319232952.A19330@bocal.cs.univ-paris8.fr> References: <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> User-Agent: Mutt/1.0.1i In-Reply-To: <200103192139.f2JLdSN01132@PrintServer.LedCom>; from GLederrey@SwissOnline.ch on Mon, Mar 19, 2001 at 10:39:32PM +0100 Sender: Paul MARQUES MOTA From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 23:29:52 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Mar 19, 2001 at 10:39:32PM +0100, Guillaume Lederrey wrote:
>
>   What are exactly the tasks of the maintainers ?

It is mainly to unsubscribe and subscribe people that do not know how to. You
will also have to yell at the spam-senders _and_ at their management, admin,
postmaster, etc... so that they stop bothering us.

> I might be
> interested, but I don't have a lot of time, and I have a
> "response time" of about 1 to 2 days.  But if the workload is
> not too heavy ...
>

It's very light, actually...

>       Guillaume Lederrey
>

--
      Paul
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Tue Mar 20 05:54:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00659 for ; Tue, 20 Mar 2001 18:48:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:24 +0100 (MET) Received: (qmail 6115 invoked by uid 0); 20 Mar 2001 04:53:59 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx14) with SMTP; 20 Mar 2001 04:53:59 -0000 X-eGroups-Return: sentto-1101623-2522-985064045-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 20 Mar 2001 04:54:07 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 04:54:04 -0000 Received: (qmail 76768 invoked from network); 20 Mar 2001 04:54:04 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 Mar 2001 04:54:04 -0000 Received: from unknown (HELO postfix2-1.free.fr) (213.228.0.9) by mta2 with SMTP; 20 Mar 2001 04:54:04 -0000 Received: from free.fr (nas-cbv-1-7-51.dial.proxad.net [213.228.7.51]) by postfix2-1.free.fr (Postfix) with ESMTP id 8555FC0B3 for ; Tue, 20 Mar 2001 05:54:02 +0100 (CET) Message-ID: <3AB6E284.4060303@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> <3AB61B67.4575A32A@mentor.com> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 05:54:28 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

Yann GUIDON wrote:

> "Tore" wrote:
>
>> Yann,
>>         could you add me to the new mailing server or provide info about the
>> new listserver so that I can unsubscribe from the yahoo f-cpu list?  Are
>> messages crossposted?
>
>
> hello,
>
> unfortunately the new list is not (yet) open.
> it will be a long process and we'll need everybody's combined efforts,
> so let's not do it too quickly.
>
> First, i think that the seul.org site is best suited for hosting
> the f-cpu list : it is commited to the open and independent community,
> it is seriously managed and it works. This means that if a little
> thing goes wrong, everybody will not be harmed (like it happened
> with this list). If others have a better proposition, please speak out.
>
> Second, we need a team of 3 persons, one will be the manager of the list
> and 2 others are here to backup, in case of vacation or simply absence
> of the list owner. This ensures that we don't have to call the seul.org
> maintainers everytime something goes wrong. So we need three serious
> managers, and i don't volunteer because i have enough workload already ;-)
> Who volunteers ?
What will I have to do if I volunteer?

>
> When the list is open and the managers will be voted, the migration will start.
>
>
>> Cheers,
>> Tore
>
>
> YG
>
> speaking for himself
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Tue Mar 20 05:54:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00664 for ; Tue, 20 Mar 2001 18:48:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:25 +0100 (MET) Received: (qmail 2766 invoked by uid 0); 20 Mar 2001 04:54:02 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx18) with SMTP; 20 Mar 2001 04:54:02 -0000 X-eGroups-Return: sentto-1101623-2521-985064044-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 20 Mar 2001 04:54:05 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 04:54:02 -0000 Received: (qmail 82716 invoked from network); 20 Mar 2001 04:54:02 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 20 Mar 2001 04:54:02 -0000 Received: from unknown (HELO postfix1-2.free.fr) (213.228.0.130) by mta2 with SMTP; 20 Mar 2001 04:54:01 -0000 Received: from free.fr (nas-cbv-1-7-51.dial.proxad.net [213.228.7.51]) by postfix1-2.free.fr (Postfix) with ESMTP id 7A5F71028AC for ; Tue, 20 Mar 2001 05:53:59 +0100 (CET) Message-ID: <3AB6E281.3090906@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319232952.A19330@bocal.cs.univ-paris8.fr> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 05:54:25 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

Paul Marques Mota wrote:

> On Mon, Mar 19, 2001 at 10:39:32PM +0100, Guillaume Lederrey wrote:
>
>>   What are exactly the tasks of the maintainers ?
>
>
> It is mainly to unsubscribe and subscribe people that do not know how to. You
> will also have to yell at the spam-senders _and_ at their management, admin,
> postmaster, etc... so that they stop bothering us.
If you teach me, I will be volunteer if needed!

>
>
>> I might be
>> interested, but I don't have a lot of time, and I have a
>> "response time" of about 1 to 2 days.  But if the workload is
>> not too heavy ...
>>
>
>
> It's very light, actually...
>
>
>>       Guillaume Lederrey
>>


Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Carlos De Urresti Hannoh" Tue Mar 20 07:49:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00688 for ; Tue, 20 Mar 2001 18:48:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:27 +0100 (MET) Received: (qmail 22834 invoked by uid 0); 20 Mar 2001 06:43:31 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 20 Mar 2001 06:43:31 -0000 X-eGroups-Return: sentto-1101623-2523-985070617-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 20 Mar 2001 06:43:39 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 06:43:37 -0000 Received: (qmail 88382 invoked from network); 20 Mar 2001 06:43:36 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 20 Mar 2001 06:43:36 -0000 Received: from unknown (HELO mail.gmx.net) (194.221.183.20) by mta2 with SMTP; 20 Mar 2001 06:43:36 -0000 Received: (qmail 22277 invoked by uid 0); 20 Mar 2001 06:43:30 -0000 Received: from du-148-221-7-112.prodigy.net.mx (HELO default) (148.221.7.112) by mail.gmx.net (mp005-rz3) with SMTP; 20 Mar 2001 06:43:30 -0000 Message-ID: <004301c0b109$f8627d00$7007dd94@default> To: References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> <3AB61B67.4575A32A@mentor.com> <3AB6E284.4060303@free.fr> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Carlos De Urresti Hannoh" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 06:49:50 -0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N From: "philippe.trbich" <>
Sent: Tuesday, March 20, 2001 4:54 AM
Subject: Re: [f-cpu] listservers


>
>
> Yann GUIDON wrote:
>
> > "Tore" wrote:
> >
> >> Yann,
> >>         could you add me to the new mailing server or provide info
about the
> >> new listserver so that I can unsubscribe from the yahoo f-cpu list?
Are
> >> messages crossposted?
> >
> >
> > hello,
> >
> > unfortunately the new list is not (yet) open.
> > it will be a long process and we'll need everybody's combined efforts,
> > so let's not do it too quickly.
> >
> > First, i think that the seul.org site is best suited for hosting
> > the f-cpu list : it is commited to the open and independent community,
> > it is seriously managed and it works. This means that if a little
> > thing goes wrong, everybody will not be harmed (like it happened
> > with this list). If others have a better proposition, please speak out.
> >
> > Second, we need a team of 3 persons, one will be the manager of the list
> > and 2 others are here to backup, in case of vacation or simply absence
> > of the list owner. This ensures that we don't have to call the seul.org
> > maintainers everytime something goes wrong. So we need three serious
> > managers, and i don't volunteer because i have enough workload already
;-)
> > Who volunteers ?
> What will I have to do if I volunteer?
>
I do. As 2nd. contact.
> >
> > When the list is open and the managers will be voted, the migration will
start.
> >
> >
> >> Cheers,
> >> Tore
> >
> >
> > YG
> >
> > speaking for himself
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 20 10:50:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00869 for ; Tue, 20 Mar 2001 18:48:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 20 Mar 2001 18:48:42 +0100 (MET) Received: (qmail 28876 invoked by uid 0); 20 Mar 2001 10:10:02 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx13) with SMTP; 20 Mar 2001 10:10:02 -0000 X-eGroups-Return: sentto-1101623-2524-985082279-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 20 Mar 2001 09:58:00 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 09:57:58 -0000 Received: (qmail 81142 invoked from network); 20 Mar 2001 09:57:57 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 20 Mar 2001 09:57:57 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 20 Mar 2001 09:57:56 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA02486; Tue, 20 Mar 2001 01:57:54 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8Q90; Tue, 20 Mar 2001 10:03:31 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB727FC.71A87C98@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> <3AB61B67.4575A32A@mentor.com> <3AB6E284.4060303@free.fr> <004301c0b109$f8627d00$7007dd94@default> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 10:50:52 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Carlos De Urresti Hannoh wrote:
> From: "philippe.trbich"
> > Yann GUIDON wrote:
> > > "Tore" wrote:
...
> > > Who volunteers ?
> > What will I have to do if I volunteer?
> I do. As 2nd. contact.

nice, thank you everybody !

so we have Philippe, Carlos and Guillaume.
Since i know that Philippe is already involved with
the manual's translation, i think that Guillaume is
arithmetically the first contact. We'll arrange the details now.


Andreas wrote :
> If you interested in our offer please do not hesitate to contact me via
> eMail: andreas.romeyke@web.de

Roger Dingledine has started the f-cpu@seul.org list, we're trying to configure
it correctly. Thank you for your offer, i think that it will be useful soon
(read further in this mail).

Paul Marques Mota wrote:
> > First, i think that the seul.org site is best suited for hosting
> > the f-cpu list :
> I do think that too.
this way, everybody participates a bit. it's like in a parallel computer :
fault-tolerance and load sharing :-)

> > Second, we need a team of 3 persons, one will be the manager of the list
> The french mailing-list has only two maintainers, (Yann Guidon and myself)
> and it seems to be running nicely for now...
yup but the number of subscribers is lower, and we can understand ourselves.
better more managers than too few, right ? it's just for stability.

> On a related note, I also think that we need a german mailing-list. What do
> you think of that?
well, i think it's up to them. i don't remember who has opened the german list,
and it seems quite quiet these time. they will probably prefer GAOS to host them
since it's in germany. and we better not put all the eggs in the same basket :-)


hey, maybe it will be finished in one or two weeks ?

:-)


YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Mon Mar 19 23:22:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00330 for ; Wed, 21 Mar 2001 20:45:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:40 +0100 (MET) Received: (qmail 1468 invoked by uid 0); 20 Mar 2001 18:31:26 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx26) with SMTP; 20 Mar 2001 18:31:26 -0000 X-eGroups-Return: sentto-1101623-2525-985113083-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 20 Mar 2001 18:31:24 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 18:31:22 -0000 Received: (qmail 87475 invoked from network); 20 Mar 2001 18:31:21 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 20 Mar 2001 18:31:21 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.168) by mta1 with SMTP; 20 Mar 2001 18:31:20 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 9B7FF9E58 for ; Mon, 19 Mar 2001 23:22:54 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3AB686BE.3576A306@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 23:22:54 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: F-CPU participation Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N I will try to come.
nicO

Yann GUIDON a =E9crit :
>
> Gerrit Hiddink wrote:
> > > > Can you please elaborate a bit more on F-CPU?
> > > well, a simple search on Google will give you most of the in= formations ;-)
> > Uh /me is ashamed... I should have thought of that myself :/
> ;-)
>
> > I like the project! Open Source hardware :)
> there are others like that at the opencollector.org website :-)
>
> > You're more than welcome to do some presentations or workshops on= F-CPU
> > during HAL 2001. Please send me details about who's going to tell= what
> > once you have clarity on this ;)
>
> This participation was proposed by Trollhunter,
> member of linuxfr.org, who will come to the HAL with his team.
> Trollhunter has offered some support to the f-cpu team.
> I hope that several french and german people will come.
> we will try to make a "f-cpu lounge" or something like that,=
> where we can make workshops, discuss endlessly without worrying
> about the schedule... hmm, we'll have to make a nice flag so
> everybody can see were we are ;-)
>
> not everything is organised yet, it has just started.
> we'll keep you informed.
>
> > Regards, Grit
> "Dank you well" :-)
> YG
>
> speaking for himself
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Tue Mar 20 19:51:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00339 for ; Wed, 21 Mar 2001 20:45:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:42 +0100 (MET) Received: (qmail 7550 invoked by uid 0); 20 Mar 2001 18:53:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx03) with SMTP; 20 Mar 2001 18:53:11 -0000 X-eGroups-Return: sentto-1101623-2526-985114403-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 20 Mar 2001 18:53:25 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 18:53:23 -0000 Received: (qmail 4377 invoked from network); 20 Mar 2001 18:53:22 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 20 Mar 2001 18:53:22 -0000 Received: from unknown (HELO orion.uk.insnet.net) (194.177.174.244) by mta1 with SMTP; 20 Mar 2001 18:53:21 -0000 Received: from ws133.warminsterschool.org.uk ([195.59.6.116]) by orion.uk.insnet.net (8.9.3/8.9.3) with SMTP id SAA12993; Tue, 20 Mar 2001 18:53:19 GMT Message-Id: <3.0.6.32.20010320185111.007c2450@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com, f-cpu@yahoogroups.com In-Reply-To: <20010319232952.A19330@bocal.cs.univ-paris8.fr> References: <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 18:51:11 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi people,
I'm not too long listening to the conversation on this newsletter, but I
have heard hardly anything about the real project or ideas how to improve
the old ideas.
So my question is: will this mailinglist work at some point or is there
another in that I'm not a member where all the important and interesting
stuff is written and talked about in.
K. Riehn     
P.S. If you still need volunteers for managing the List, I would voluntaer
if you want a newbie in this list and not someone that was in here from the
beginning
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Alan Grimes Tue Mar 20 20:23:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00345 for ; Wed, 21 Mar 2001 20:45:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:44 +0100 (MET) Received: (qmail 19582 invoked by uid 0); 20 Mar 2001 19:22:52 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx21) with SMTP; 20 Mar 2001 19:22:52 -0000 X-eGroups-Return: sentto-1101623-2527-985116166-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 20 Mar 2001 19:22:47 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 19:22:45 -0000 Received: (qmail 86197 invoked from network); 20 Mar 2001 19:22:45 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 20 Mar 2001 19:22:45 -0000 Received: from unknown (HELO smtp03.mrf.mail.rcn.net) (207.172.4.62) by mta1 with SMTP; 20 Mar 2001 19:22:45 -0000 Received: from 66-44-55-170.s424.tnt1.lnhva.md.dialup.rcn.com ([66.44.55.170] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14fRiM-00035W-00 for f-cpu@yahoogroups.com; Tue, 20 Mar 2001 14:22:43 -0500 Message-ID: <3AB7AE30.410B59A1@starpower.net> Organization: Nanosoft: software that thinks. X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> <3.0.6.32.20010320185111.007c2450@pop1.edex.net.uk> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 14:23:28 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kristian-Ole Riehn wrote:
> I'm not too long listening to the conversation on this newsletter, but
> I have heard hardly anything about the real project or ideas how to
> improve the old ideas.

:)

> So my question is: will this mailinglist work at some point or is there
> another in that I'm not a member where all the important and
> interesting stuff is written and talked about in.

I doubt it ever will... I've been here since '98. Two months ago I tried
to re-create the list over at sourceforge by applying the best project
managment techniques I am familiar with. I was violently rejected by the
people on this list who appearently have made some half-assed attempts
to apply some of my suggestions in a CVS archive. I have since
discontinued that attempt.

This project's biggest problem is that there are very few people on this
list who are qualified to actually work on the stuff. More importantly
these people seem completely unwilling to even consider providing a
"lader" or "primer" for people such as myself who wish to contribute
more.

The lack of managment and orgainization is secondary to this.

Its as if the exclusive F-CPU development club (located somewhere in
europe) will grace uppon us a Processor and that we should all rejoyce.
That is no better than how Intel does it.

The Linux development team is little better. I, here at home, am running
windows 3.11 as my primary OS.

The Linux morons think that just because their software has all the
functions they know how to code into it people will automaticaly get a
value from their unholy abomination. ITS THE USER, YOU DUMBFUCKS!!! YOU
ARE ENGINEERING A COMPUTER *SYSTEM* THAT IS A COMPUTER (CPU+MEMORY),
SOME OTHER HARDWARE, AND THE >>>> *USER* <<<< WHO MUST OPERATE IT. Your
computer may be the fastest and most functional in the world but the
*SYSTEM* is totally, irevocably, fucked!!

I wish I could destroy every OS kernel made since 1990 and all UNIX
software ever written and tell people to Try Again!

Heck I wish I could go back in time to 1974 and help the authors of the
classic book "Algorithms + Data structures = programs" understand the
structure of modern software... A corected version of that book could
have changed all of history...

--
People who work on computers use linux; People who work on life use
Macintosh =)
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 20 21:13:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00360 for ; Wed, 21 Mar 2001 20:45:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:48 +0100 (MET) Received: (qmail 13734 invoked by uid 0); 20 Mar 2001 20:20:47 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx24) with SMTP; 20 Mar 2001 20:20:47 -0000 X-eGroups-Return: sentto-1101623-2528-985119663-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fk.egroups.com with NNFMP; 20 Mar 2001 20:21:04 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 20:21:02 -0000 Received: (qmail 38631 invoked from network); 20 Mar 2001 20:21:01 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 20 Mar 2001 20:21:01 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 20 Mar 2001 21:22:06 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA17919; Tue, 20 Mar 2001 12:20:59 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8R7R; Tue, 20 Mar 2001 20:26:36 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB7BA04.E45E18AC@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> <3.0.6.32.20010320185111.007c2450@pop1.edex.net.uk> <3AB7AE30.410B59A1@starpower.net> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 21:13:56 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Alan Grimes wrote:
> Kristian-Ole Riehn wrote:
> > I'm not too long listening to the conversation on this newsletter, but
> > I have heard hardly anything about the real project or ideas how to
> > improve the old ideas.
> :)

yup, we're doing organisational changes currently,
following the buying of egroups by yahoo. some parts are moved to seul.org (MIT).
the french mailing list is already moved to a french server.

> > So my question is: will this mailinglist work at some point or is there
> > another in that I'm not a member where all the important and
> > interesting stuff is written and talked about in.
this list is where the technical stuff is discussed (sorry for the word ;-P) about.
otherwise, it takes too long to synchronize people in different mailing lists.
The technical background has not changed, it is explained in the manual.
well, the manual is 1 year old now, at least for the oldest part : the
instruction set census which takes a LOT of work to update. it's so heavy that
we can't work seriously on it now, we're going to do it during the HAL2001
this summer.

> I doubt it ever will... I've been here since '98. Two months ago I tried
> to re-create the list over at sourceforge by applying the best project
> managment techniques I am familiar with.
that's where i think the error is. you don't create such a project with
"templates" or moulds. the tools help, they do not have to direct.

Yes you are right that the management tools are important, we have just reached
a critical mass where the organisation part takes more effort than the "desing".
We are currently addressing this point : Michael is in charge of CVS (Ey, Michael,
what is going on now ?), we have the authorisation to use a management tool from
APRIL (called mantis) and we move the mailing lists to more friendly and
manageable places. plus, i'm not a student currently, which sucks a lot of time out
of the project.

> I was violently rejected by the
> people on this list who appearently have made some half-assed attempts
> to apply some of my suggestions in a CVS archive. I have since
> discontinued that attempt.

i don't think anyone was bashed, at least physically.
You wanted changes, that's ok, but you wanted them YOUR way, quickly
and without following the other people. you felt misunderstood and
eventually angry.

you have also experienced that management alone is not enough :
you opened a sourceforge account and told people : design me a CPU.
whereas people usually design for themselves.

if you want to help, noone will refuse. but if you force people,
or expect from them what you wouldn't do, it can't work. if you want
to manage the CVS at seul.org, ok : Michael seems to be busy with exams
or VHDL. but don't waste the bandwidth with your disapointment rants.
please...

> This project's biggest problem is that there are very few people on this
> list who are qualified to actually work on the stuff.
well, it has always been a problem with the F-CPU, if you look at the first
attempts (M2M + TTA...). At least, now, we're stable, we have secured
the domain names (com, net, org, de), we are securing the trade mark,
we are moving the mailing list to more reliable and friendly servers,
we have a rather good RISC architecture and we are translating a BIG manual
to LATEX in english and french (anybody wants a german version ?).
We have won international exposure in the press and the EDA/micro world, btw.

> More importantly
> these people seem completely unwilling to even consider providing a
> "lader" or "primer" for people such as myself who wish to contribute
> more.
what about the manual ? is english unreadable ?
or your browser doesn't understand HTML ?

> The lack of managment and orgainization is secondary to this.
even though it is now taking most of our time.

> Its as if the exclusive F-CPU development club (located somewhere in
> europe) will grace uppon us a Processor and that we should all rejoyce.
> That is no better than how Intel does it.
if it's how you feel it, nice. nobody forces you to stay here,
unless you can't find a way to unsub, in this case it is not our fault.

> The Linux development team is little better. I, here at home, am running
> windows 3.11 as my primary OS.
pafff... the old Linux rant.
here, it is a matter of freedom (FSF sense) and design, not of "orthodoxy" to
your personal tastes.

<snip>

> People who work on computers use linux; People who work on life use
> Macintosh =)
AFAIK, Apple is not FSF-compliant ;-)


YG
PS : it was not a flame or anything like that.
Al's post are simply not constructive, i just wish that
we push in the same direction or else we won't go anywhere, ever.

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 20 21:15:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00363 for ; Wed, 21 Mar 2001 20:45:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:49 +0100 (MET) Received: (qmail 7254 invoked by uid 0); 20 Mar 2001 20:22:37 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx16) with SMTP; 20 Mar 2001 20:22:37 -0000 X-eGroups-Return: sentto-1101623-2529-985119764-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 20 Mar 2001 20:22:45 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 20:22:43 -0000 Received: (qmail 43797 invoked from network); 20 Mar 2001 20:22:42 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 20 Mar 2001 20:22:42 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 20 Mar 2001 20:22:42 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA18016; Tue, 20 Mar 2001 12:22:39 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8R74; Tue, 20 Mar 2001 20:28:17 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB7BA69.EAD1C376@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB686BE.3576A306@seul.org> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 21:15:37 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: F-CPU participation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nicolas wrote:
>
> I will try to come.
> nicO

Yo, that makes two people.
I know that Jadis (we met her in Berlin, you know)
will also be there. Is anybody else willing to come ?
We have enough time to organise this until august.



YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Antonio Díaz Zamora" Tue Mar 20 22:26:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00381 for ; Wed, 21 Mar 2001 20:45:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:53 +0100 (MET) Received: (qmail 392 invoked by uid 0); 20 Mar 2001 21:28:01 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx24) with SMTP; 20 Mar 2001 21:28:01 -0000 X-eGroups-Return: sentto-1101623-2530-985123698-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 20 Mar 2001 21:28:19 -0000 X-Sender: tony@jm.lib.cult.cu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 21:28:18 -0000 Received: (qmail 24481 invoked from network); 20 Mar 2001 21:28:17 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 20 Mar 2001 21:28:17 -0000 Received: from unknown (HELO zeus.lib.cult.cu) (169.158.120.134) by mta3 with SMTP; 20 Mar 2001 22:29:20 -0000 Received: (from daemon@localhost) by zeus.lib.cult.cu (8.9.3/8.9.3) id RAA32100 for ; Tue, 20 Mar 2001 17:33:55 -0500 Received: from UNKNOWN(169.158.120.131), claiming to be "jm.lib.cult.cu" via SMTP by zeus.lib.cult.cu, id smtpdIV4nb7; Tue Mar 20 17:33:48 2001 Received: from JM/SpoolDir by jm.lib.cult.cu (Mercury 1.48); 20 Mar 01 16:27:06 -0500 Received: from SpoolDir by JM (Mercury 1.48); 20 Mar 01 16:26:49 -0500 Received: from pc-tony (169.158.120.136) by jm.lib.cult.cu (Mercury 1.48); 20 Mar 01 16:26:40 -0500 Message-ID: <001201c0b184$74613160$88789ea9@pc-tony.lib.cult.cu> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 From: "=?iso-8859-1?Q?Antonio_D=EDaz_Zamora?=" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 16:26:40 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Manual translation to spanish Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello everybody

I want to know if there is any effort to translate the manual to spanish,
and if there is no such a thing, I will start it myself. Comments ?
Sugestions ?

Antonio Diaz Zamora
Yahoo! Groups Sponsor
Click here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Tue Mar 20 23:12:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00393 for ; Wed, 21 Mar 2001 20:45:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:45:55 +0100 (MET) Received: (qmail 6389 invoked by uid 0); 20 Mar 2001 22:15:36 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx11) with SMTP; 20 Mar 2001 22:15:36 -0000 X-eGroups-Return: sentto-1101623-2531-985126549-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 20 Mar 2001 22:15:52 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 20 Mar 2001 22:15:48 -0000 Received: (qmail 64414 invoked from network); 20 Mar 2001 22:14:53 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 20 Mar 2001 22:14:53 -0000 Received: from unknown (HELO orion.uk.insnet.net) (194.177.174.244) by mta3 with SMTP; 20 Mar 2001 23:15:57 -0000 Received: from ws131.warminsterschool.org.uk ([195.59.6.120]) by orion.uk.insnet.net (8.9.3/8.9.3) with SMTP id WAA07199; Tue, 20 Mar 2001 22:14:51 GMT Message-Id: <3.0.6.32.20010320221242.007bf210@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com, f-cpu@yahoogroups.com In-Reply-To: <3AB7BA04.E45E18AC@mentor.com> References: <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> <3.0.6.32.20010320185111.007c2450@pop1.edex.net.uk> <3AB7AE30.410B59A1@starpower.net> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 22:12:42 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Do you still need someone that can translate the manual into german?
I would volunteer, if I'm provided with an english version. I think I can
manage this, first I'm German and on an english school for years, so if I
can help, sent the manual to me.
kristian Riehn
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Mar 20 05:05:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00449 for ; Wed, 21 Mar 2001 20:48:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:03 +0100 (MET) Received: (qmail 31722 invoked by uid 0); 21 Mar 2001 00:27:16 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx04) with SMTP; 21 Mar 2001 00:27:16 -0000 X-eGroups-Return: sentto-1101623-2532-985134455-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 21 Mar 2001 00:27:35 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 00:27:34 -0000 Received: (qmail 5434 invoked from network); 21 Mar 2001 00:27:34 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 21 Mar 2001 00:27:34 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.193) by mta2 with SMTP; 21 Mar 2001 00:27:30 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA03390; Tue, 20 Mar 2001 05:05:02 +0100 Message-ID: <20010320050502.09943@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200103191258.NAA23716@ringbreak.dnd.utwente.nl> <3AB61034.1F48D90@mentor.com> <3AB6135E.E251B308@sgi.com> <3AB61B67.4575A32A@mentor.com> <20010319221717.A13651@bocal.cs.univ-paris8.fr> X-Mailer: Mutt 0.84e In-Reply-To: <20010319221717.A13651@bocal.cs.univ-paris8.fr>; from Paul Marques Mota on Mon, Mar 19, 2001 at 10:17:17PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 20 Mar 2001 05:05:02 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Mar 19, 2001 at 10:17:17PM +0100, Paul Marques Mota wrote:
[...]
> On a related note, I also think that we need a german mailing-list. What do
> you think of that?

No, thank you.  There are too many mailing lists already.  I guess there
even was a german one at egroups, but I never joined it.  We might want
to have mailing lists for different topics, but please not for different
native languages.  It tends to `hide' important/interesting discussions
>from other project members, and I consider that a Bad Thing (tm).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon Mar 19 22:47:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00461 for ; Wed, 21 Mar 2001 20:48:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:06 +0100 (MET) Received: (qmail 22963 invoked by uid 0); 21 Mar 2001 05:05:53 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx04) with SMTP; 21 Mar 2001 05:05:53 -0000 X-eGroups-Return: sentto-1101623-2533-985151173-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 21 Mar 2001 05:06:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 05:06:13 -0000 Received: (qmail 40035 invoked from network); 21 Mar 2001 05:06:13 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Mar 2001 05:06:13 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 21 Mar 2001 05:06:12 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA16855 for ; Tue, 20 Mar 2001 22:06:04 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AB67E76.98938994@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103192139.f2JLdSN01132@PrintServer.LedCom> <20010319221717.A13651@bocal.cs.univ-paris8.fr> <200103192139.f2JLdSN01132@PrintServer.LedCom> <3.0.6.32.20010320185111.007c2450@pop1.edex.net.uk> <3AB7AE30.410B59A1@starpower.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 19 Mar 2001 14:47:34 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] listservers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Alan Grimes wrote:
>
> I wish I could destroy every OS kernel made since 1990 and all UNIX
> software ever written and tell people to Try Again!

I don't think UNIX is wrong directly, but is just the wrong OS for
the job. Ironically Windows is closer model  of what a general computer
is expected to do. BTW I need a OS for my CPU... free feel to help me write
something once I figure out I/O. :)

>
> Heck I wish I could go back in time to 1974 and help the authors of the
> classic book "Algorithms + Data structures = programs" understand the
> structure of modern software... A corected version of that book could
> have changed all of history...

If that was the book I am thinking about, written in PASCAL
the Algorithms were ok but the language sucks.

>
> --
> People who work on computers use linux; People who work on life use
> Macintosh =)

I use windows for GAMES :-)
Also FPGA software is still windows based. I use what I have ** DOS **.
(Ok I do linux for anything but GAMES and FPGA software).

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Paul Marques Mota Wed Mar 21 17:18:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00608 for ; Wed, 21 Mar 2001 20:48:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:40 +0100 (MET) Received: (qmail 9438 invoked by uid 0); 21 Mar 2001 16:18:41 -0000 Received: from mx17.rz2.gmx.net (HELO hi.egroups.com) (10.1.72.117) by mxi1.gmx.net (mxi1) with SMTP; 21 Mar 2001 16:18:41 -0000 X-eGroups-Return: sentto-1101623-2534-985191498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 21 Mar 2001 16:18:20 -0000 X-Sender: mota@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 16:18:17 -0000 Received: (qmail 4697 invoked from network); 21 Mar 2001 16:18:11 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 21 Mar 2001 16:18:11 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta3 with SMTP; 21 Mar 2001 17:19:16 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14flJJ-0001A8-00 for f-cpu@yahoogroups.com; Wed, 21 Mar 2001 17:18:09 +0100 Received: from alpha4.bocal.cs.univ-paris8.fr ([192.168.3.7]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 14flJJ-0003JZ-00 for f-cpu@yahoogroups.com; Wed, 21 Mar 2001 17:18:09 +0100 Received: from mota by alpha4.bocal.cs.univ-paris8.fr with local (Exim 3.12 #1) id 14flJp-0002wB-00 for f-cpu@yahoogroups.com; Wed, 21 Mar 2001 17:18:41 +0100 To: f-cpu@yahoogroups.com Message-ID: <20010321171841.A570@bocal.cs.univ-paris8.fr> References: <001201c0b184$74613160$88789ea9@pc-tony.lib.cult.cu> User-Agent: Mutt/1.0.1i In-Reply-To: <001201c0b184$74613160$88789ea9@pc-tony.lib.cult.cu>; from tony@jm.lib.cult.cu on Tue, Mar 20, 2001 at 04:26:40PM -0500 Sender: Paul MARQUES MOTA From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 17:18:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Manual translation to spanish Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N On Tue, Mar 20, 2001 at 04:26:40PM -0500, Antonio D=EDaz Zamora wrote:
> hello everybody
>

Hello

> I want to know if there is any effort to translate the manual to spani= sh,

No, there is no such thing at the moment.

> and if there is no such a thing, I will start it myself. Comments ?
That would be a great thing!

> Antonio Diaz Zamora
>

--
      Paul
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From lphalt@gmx.de Wed Mar 21 17:48:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00623 for ; Wed, 21 Mar 2001 20:48:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:45 +0100 (MET) Received: (qmail 31759 invoked by uid 0); 21 Mar 2001 16:49:06 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx12) with SMTP; 21 Mar 2001 16:49:06 -0000 X-eGroups-Return: sentto-1101623-2535-985193338-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 21 Mar 2001 16:48:59 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 16:48:57 -0000 Received: (qmail 78627 invoked from network); 21 Mar 2001 16:48:55 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Mar 2001 16:48:55 -0000 Received: from unknown (HELO ei.egroups.com) (10.1.2.114) by mta1 with SMTP; 21 Mar 2001 16:48:55 -0000 X-eGroups-Return: lphalt@gmx.de Received: from [10.1.10.104] by ei.egroups.com with NNFMP; 21 Mar 2001 16:48:55 -0000 To: f-cpu@yahoogroups.com Message-ID: <99am1m+aece@eGroups.com> In-Reply-To: <3AB7BA69.EAD1C376@mentor.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 200.57.128.65 From: lphalt@gmx.de MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 16:48:54 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: F-CPU participation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > Nicolas wrote:
> >
> > I will try to come.
> > nicO
>
> Yo, that makes two people.
> I know that Jadis (we met her in Berlin, you know)
> will also be there. Is anybody else willing to come ?
> We have enough time to organise this until august.
I think it would be possible from my part to join you there. And
since we still have time to sort things out.. May I ask some
questions to the list about hotel matters :)

Orage. >
>
> YG
>
> speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Mar 21 18:32:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00653 for ; Wed, 21 Mar 2001 20:48:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:51 +0100 (MET) Received: (qmail 4727 invoked by uid 0); 21 Mar 2001 17:42:05 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx22) with SMTP; 21 Mar 2001 17:42:05 -0000 X-eGroups-Return: sentto-1101623-2536-985196522-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 21 Mar 2001 17:42:04 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 17:42:01 -0000 Received: (qmail 84094 invoked from network); 21 Mar 2001 17:40:03 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 21 Mar 2001 17:40:03 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 21 Mar 2001 17:40:03 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA16686; Wed, 21 Mar 2001 09:40:00 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8TBQ; Wed, 21 Mar 2001 17:45:39 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB8E5C9.B86815DF@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 18:32:57 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Index of /leunga/www/MLRISC Content-Type: multipart/mixed; boundary="------------476E1EE8E23E190F0945AE23" Status: R X-Status: N --------------476E1EE8E23E190F0945AE23 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit http://www.cs.nyu.edu/leunga/www/MLRISC/

wow...


YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--------------476E1EE8E23E190F0945AE23 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Base: "http://www.cs.nyu.edu/leunga/www/MLRIS C/" Content-Location: "http://www.cs.nyu.edu/leunga/www/MLRIS C/" Index of /leunga/www/MLRISC

Index of /leunga/www/MLRISC

      Name                    Last modified       Size  Description


[DIR] Parent Directory        29-May-2000 20:03      -  
[TXT] 00README_FIRST          07-Dec-2000 22:51     1k  
[DIR] C6/                     13-Dec-1999 23:12      -  
[DIR] Doc/                    07-Dec-2000 22:51      -  
[DIR] Glue/                   18-Dec-2000 23:42      -  
[DIR] IR/                     08-Mar-2001 21:25      -  
[DIR] MD-2.0/                 24-Nov-2000 23:17      -  
[TXT] Makefile                12-May-2000 18:45     1k  
[DIR] SMLNJ/                  23-Nov-2000 21:07      -  
[DIR] SSA.old/                01-May-2000 22:48      -  
[DIR] SSA.old2/               14-Dec-2000 23:36      -  
[DIR] SSA/                    08-Mar-2001 21:25      -  
[   ] This                    30-Oct-2000 15:47     1k  
[DIR] Tools/                  14-Dec-2000 23:36      -  
[DIR] aliasing/               07-Dec-2000 22:52      -  
[DIR] alpha/                  08-Mar-2001 21:25      -  
[TXT] autoload.sml            28-Nov-2000 00:27     1k  
[DIR] backpatch/              03-Dec-2000 01:19      -  
[DIR] c-calls/                08-Mar-2001 21:25      -  
[DIR] cluster/                08-Mar-2001 21:25      -  
[DIR] cm/                     15-Mar-2001 20:52      -  
[DIR] control/                24-Nov-2000 00:25      -  
[DIR] demo/                   08-Mar-2001 21:25      -  
[DIR] emit/                   08-Mar-2001 21:25      -  
[DIR] extensions/             23-Jan-2000 22:06      -  
[TXT] fifo-sig.sml            21-Dec-2000 23:30     1k  
[DIR] gc-safety/              08-Mar-2001 21:25      -  
[DIR] graphs/                 24-Nov-2000 00:25      -  
[DIR] hppa/                   08-Mar-2001 21:25      -  
[DIR] hyperblock-scheduling/  21-Feb-2000 19:53      -  
[DIR] hyperblock/             26-May-2000 14:56      -  
[DIR] instructions/           08-Mar-2001 21:25      -  
[DIR] ir/                     07-Dec-2000 22:52      -  
[DIR] library/                21-Dec-2000 23:41      -  
[   ] loop                    11-Apr-2000 15:52     2k  
[   ] make.sml                08-Mar-2001 21:25     1k  
[   ] makeall-110.0.6.sml     25-Nov-2000 23:35     1k  
[TXT] makeall-110.25.sml      25-Nov-2000 23:35     1k  
[TXT] makeall-new.sml         08-Mar-2001 21:25     1k  
[   ] makeall.sml             08-Mar-2001 21:25     1k  
[TXT] makecm                  12-May-2000 18:32     2k  
[DIR] mips/                   11-Mar-2001 20:14      -  
[DIR] mltree/                 09-Mar-2001 17:01      -  
[DIR] modulo-scheduling/      01-May-2000 17:42      -  
[   ] newest-ra.tar.gz.uu     20-Sep-2000 14:37   138k  
[   ] popl-review             25-Sep-2000 12:32    13k  
[DIR] ppc/                    08-Mar-2001 21:25      -  
[TXT] priority-queue-sig.sml  21-Dec-2000 23:45     1k  
[TXT] queue-sig.sml           21-Dec-2000 23:30     1k  
[CMP] ra.tar.Z                20-Sep-2000 14:38    99k  
[DIR] ra/                     08-Mar-2001 21:25      -  
[DIR] scheduling.old/         08-Jun-2000 19:43      -  
[DIR] scheduling/             18-Dec-2000 23:42      -  
[DIR] sparc/                  08-Mar-2001 21:25      -  
[TXT] test.sml                11-Mar-2000 00:55     1k  
[DIR] tmp/                    20-Sep-2000 14:39      -  
[DIR] visualization/          24-Nov-2000 00:25      -  
[DIR] x86/                    16-Mar-2001 18:37      -
Apache/1.3.6 Server at www.cs.nyu.edu Port 80
--------------476E1EE8E23E190F0945AE23-- From Yann GUIDON Wed Mar 21 18:40:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00656 for ; Wed, 21 Mar 2001 20:48:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:55 +0100 (MET) Received: (qmail 27881 invoked by uid 0); 21 Mar 2001 17:49:20 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx02) with SMTP; 21 Mar 2001 17:49:20 -0000 X-eGroups-Return: sentto-1101623-2537-985196958-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 21 Mar 2001 17:49:19 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 17:49:17 -0000 Received: (qmail 10765 invoked from network); 21 Mar 2001 17:47:57 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 21 Mar 2001 17:47:57 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 21 Mar 2001 18:49:01 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA17626; Wed, 21 Mar 2001 09:47:52 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8TB7; Wed, 21 Mar 2001 17:53:31 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB8E7A1.CA05D7D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <99am1m+aece@eGroups.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 18:40:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: F-CPU participation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N lphalt@gmx.de wrote:
> > Nicolas wrote:
> > > I will try to come.
> > > nicO
> > Yo, that makes two people.
> > I know that Jadis (we met her in Berlin, you know)
> > will also be there. Is anybody else willing to come ?
> > We have enough time to organise this until august.
> I think it would be possible from my part to join you there.
great !

> And since we still have time to sort things out.. May I ask some
> questions to the list about hotel matters :)

no hostel, only tents :-P

http://www.hal2001.org/ is where all the informations are stored.

> Orage

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Mar 21 19:05:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00668 for ; Wed, 21 Mar 2001 20:48:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:48:59 +0100 (MET) Received: (qmail 3970 invoked by uid 0); 21 Mar 2001 18:13:46 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx08) with SMTP; 21 Mar 2001 18:13:46 -0000 X-eGroups-Return: sentto-1101623-2538-985198420-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 21 Mar 2001 18:13:41 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 18:13:37 -0000 Received: (qmail 12814 invoked from network); 21 Mar 2001 18:13:01 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 21 Mar 2001 18:13:01 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 21 Mar 2001 18:13:00 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA20535; Wed, 21 Mar 2001 10:12:56 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8TC9; Wed, 21 Mar 2001 18:18:35 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB8ED82.1CB361E2@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com Cc: Kristian-Ole Riehn , "Antonio =?iso-8859-1?Q?D=EDaz?= Zamora" References: <001201c0b184$74613160$88789ea9@pc-tony.lib.cult.cu> <20010321171841.A570@bocal.cs.univ-paris8.fr> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 19:05:54 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Manual translations Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Paul Marques Mota wrote:
> On Tue, Mar 20, 2001 at 04:26:40PM -0500, Antonio D=EDaz Zamora wrote:=
> > hello everybody
> Hello
> > I want to know if there is any effort to translate the manual to = spanish,
> No, there is no such thing at the moment.

right : this is one desirable thing :-)
That, and the german translation, are two interesting efforts.

Philippe Trbich is currently doing the french translation,
the original LaTeX files are available from http://f-cpu.seul.org/manual/
(incomplete). Philippe has done 4 parts (from the 7 ones), they give the important backgrounds. i don't remember the url where he has put his files.=
plus, since i don't speak spanish and am not perfect in german, i'll have troubles if i want to verify the translation, but that's not the worst
problem :-)

we'll have to revamp all the web sites and files in order to have a clean distribution, but that will come in the next months.

> > and if there is no such a thing, I will start it myself. Comments= ?
> That would be a great thing!
indeed !

> > Antonio Diaz Zamora
>         Paul
YG

speaking for himself
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Wed Mar 21 21:03:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00698 for ; Wed, 21 Mar 2001 20:49:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 20:49:06 +0100 (MET) Received: (qmail 17806 invoked by uid 0); 21 Mar 2001 18:55:26 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx02) with SMTP; 21 Mar 2001 18:55:26 -0000 X-eGroups-Return: sentto-1101623-2539-985200924-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ei.egroups.com with NNFMP; 21 Mar 2001 18:55:24 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 18:55:23 -0000 Received: (qmail 43503 invoked from network); 21 Mar 2001 18:54:44 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 21 Mar 2001 18:54:44 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 21 Mar 2001 19:55:48 -0000 Received: from art1.none.de (dialin179.pg4-nt.berlin.nikoma.de [213.54.67.179]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f2LIslb25208 for ; Wed, 21 Mar 2001 19:54:47 +0100 X-Authentication-Warning: host-2.server.itns.de: Host dialin179.pg4-nt.berlin.nikoma.de [213.54.67.179] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14foou-0000BV-00 for ; Wed, 21 Mar 2001 21:03:00 +0100 To: f-cpu@yahoogroups.com In-Reply-To: <3AB8ED82.1CB361E2@mentor.com> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 21:03:00 +0100 (CET) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> That, and the german translation, are two interesting efforts.

I want to translate to the german manual in next two weeks, if you want.
Thats quite simpler than my last try.

In past two months I tried to find out a way to build a SIMD-shifter. But
my knowledge about hardware design is too small to get a result of the
specification :). IMHO the shifter will be have logical gates with more
than 8 inputs, or more than 2 clocks, or with too long data path or such
complex as multiplier is.

I did not find any way to build small versions of the shifter and build a
higher set of this like a look-a-head adder or lego-bricks. One source of
the problems is IMHO that a shift of a 64 bit register must have 31 shifts
left or right and a 8x8 bit register has 3 shifts left or right, another
source is the handling of signed and unsigned registers. IMHO it would
make all arithmetic and logical operations and units quite simpler if we
operate only with unsigned and have a special unit to combine 2 or more
registers to handle signed operations, because the compiler can delegate
tasks to the normal arithmetic units and a special task to a signed unit
in parallel.  

Bye Andreas
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Mar 21 20:54:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00312 for ; Wed, 21 Mar 2001 22:14:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 21 Mar 2001 22:14:56 +0100 (MET) Received: (qmail 3967 invoked by uid 0); 21 Mar 2001 20:02:08 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx23) with SMTP; 21 Mar 2001 20:02:08 -0000 X-eGroups-Return: sentto-1101623-2540-985204925-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 21 Mar 2001 20:02:06 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 20:02:02 -0000 Received: (qmail 82016 invoked from network); 21 Mar 2001 20:01:56 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 21 Mar 2001 20:01:56 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 21 Mar 2001 20:01:56 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA00275; Wed, 21 Mar 2001 12:01:53 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8T17; Wed, 21 Mar 2001 20:07:31 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB90709.9E4FE10F@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 20:54:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andreas Romeyke wrote:
> Hello,
> > That, and the german translation, are two interesting efforts.
> I want to translate to the german manual in next two weeks, if you want.
it's you who decide :-) i'm just trying to avoid collisions.

> Thats quite simpler than my last try.
at least you tried ! and we learnt how difficult the design is.

> In past two months I tried to find out a way to build a SIMD-shifter. But
> my knowledge about hardware design is too small to get a result of the
> specification :).
iirc, Michael had found a "track", an idea for the shifter.
i have that somewhere, it was sent to the list.
Maybe i was a bit too optimistic about the design,
but i know that the problem is "shifted" to other
issues when it comes to full-custom design.

> IMHO the shifter will be have logical gates with more
> than 8 inputs, or more than 2 clocks, or with too long data path or such
> complex as multiplier is.
if the specification for the FC0's shifter must be modified because
it is infeasible, then it's ok. however the functionality must remain
convenient, that is : no complex behaviour or restriction for the software.

> I did not find any way to build small versions of the shifter and build a
> higher set of this like a look-a-head adder or lego-bricks.
i thought Michael had found a way... or was it only a pre-study ?

> One source of
> the problems is IMHO that a shift of a 64 bit register must have 31 shifts
> left or right and a 8x8 bit register has 3 shifts left or right, another
> source is the handling of signed and unsigned registers. IMHO it would
> make all arithmetic and logical operations and units quite simpler if we
> operate only with unsigned and have a special unit to combine 2 or more
> registers to handle signed operations, because the compiler can delegate
> tasks to the normal arithmetic units and a special task to a signed unit
> in parallel.
and maybe this can be done at HW level ? at first glance,
the arithmetic shift problem comes from the propagation of the sign.
maybe there could be two parallel units that would OR their result ?


help, i have too many things to do.
i'll try to buy a laptop in 2 weeks or 3, so i'll be able to work anywhere
and keep my files up to date. be tolerant, in the meanwhile, please ;-)

> Bye Andreas

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Wed Mar 21 22:34:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02581 for ; Thu, 22 Mar 2001 05:11:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 05:11:34 +0100 (MET) Received: (qmail 11386 invoked by uid 0); 21 Mar 2001 21:22:16 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx25) with SMTP; 21 Mar 2001 21:22:16 -0000 X-eGroups-Return: sentto-1101623-2541-985209734-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 21 Mar 2001 21:22:15 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 21:22:12 -0000 Received: (qmail 97644 invoked from network); 21 Mar 2001 21:20:56 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 21 Mar 2001 21:20:56 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.119) by mta1 with SMTP; 21 Mar 2001 21:20:54 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 3868B9E58 for ; Wed, 21 Mar 2001 22:34:45 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3AB91E74.455897CD@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: "f-cpu@yahoogroups.com" From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 22:34:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N I send you my log from a tentative to compile imul64. And sorry for
Michael, there's many warnings and errors. I didn't look at the code.
And please remove all the stupid .vhd file like or2, or3, that's so
heavy to manage(look at the number of analyze lines for a single unit !)
and have absolutely no sense !(compile flatten all hierarchy)

Add for none synthetising things.
-- pragma translate_off
...
-- pragma translate_on

nicO
-----------------------------------------------------------------------
                        DC Professional (TM)
                           DC Expert (TM)
                       FloorPlan Manager (TM)
                         FPGA Compiler (TM)
                         VHDL Compiler (TM)
                          HDL Compiler (TM)
                        Library Compiler (TM)
                         Power Compiler (TM)
                         Test Compiler (TM)
                       Test Compiler Plus (TM)
                            CTV-Interface
                      DesignWare Developer (TM)
                          DesignPower (TM)

                   Version 1999.10 -- Sep 02, 1999
              Copyright (c) 1988-1999 by Synopsys, Inc.
                         ALL RIGHTS RESERVED

This program is proprietary and confidential information of Synopsys,
Inc.
and may be used and disclosed only as authorized in a license agreement
controlling such use and disclosure.

Initializing...
sh "rm -rf WORK;
mkdir WORK"
0
define_design_lib WORK -path WORK
1
analyze -f VHDL -library WORK and2.vhdl
Loading db file '/opt/soft/synopsys/libraries/syn/standard.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw01.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw02.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw03.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw04.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw05.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/dw07.sldb'
Loading db file '/opt/soft/synopsys/libraries/syn/gtech.db'
Loading db file '/home/profelec/nboulay/st_lib/nom_1.80V_25C/CORELIB.db'
Reading in the Synopsys vhdl primitives.
/home/profelec/nboulay/fcpu/eu_imu/and2.vhdl:
1
analyze -f VHDL -library WORK and3.vhdl
/home/profelec/nboulay/fcpu/eu_imu/and3.vhdl:
1
analyze -f VHDL -library WORK and4.vhdl
/home/profelec/nboulay/fcpu/eu_imu/and4.vhdl:
1
analyze -f VHDL -library WORK not1.vhdl
/home/profelec/nboulay/fcpu/eu_imu/not1.vhdl:
1
analyze -f VHDL -library WORK or2.vhdl
/home/profelec/nboulay/fcpu/eu_imu/or2.vhdl:
1
analyze -f VHDL -library WORK or3.vhdl
/home/profelec/nboulay/fcpu/eu_imu/or3.vhdl:
1
analyze -f VHDL -library WORK or4.vhdl
/home/profelec/nboulay/fcpu/eu_imu/or4.vhdl:
1
analyze -f VHDL -library WORK xor2.vhdl
/home/profelec/nboulay/fcpu/eu_imu/xor2.vhdl:
1
analyze -f VHDL -library WORK xor3.vhdl
/home/profelec/nboulay/fcpu/eu_imu/xor3.vhdl:
1
analyze -f VHDL -library WORK vlut.vhdl
/home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
                        when '0' => null;
                        ^
**Error: /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl  line 43
      'U' not covered by choices. (VSS-834)
                        when '0' => null;
                        ^
**Error: /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl  line 43
      Range 'Z' to '-' not covered by choices. (VSS-838)
1
analyze -f VHDL -library WORK maj23.vhdl
/home/profelec/nboulay/fcpu/eu_imu/maj23.vhdl:
1
analyze -f VHDL -library WORK maj24.vhdl
/home/profelec/nboulay/fcpu/eu_imu/maj24.vhdl:
1
analyze -f VHDL -library WORK maj34.vhdl
/home/profelec/nboulay/fcpu/eu_imu/maj34.vhdl:
1
analyze -f VHDL -library WORK reduce_tree.vhdl
/home/profelec/nboulay/fcpu/eu_imu/reduce_tree.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 27  (VHDL-2023)
Warning: Statements in an entity declaration are not supported for
synthesis. They are ignored in entity ReduceTree  on line 23
(VHDL-2001)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 54  (VHDL-2099)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 87  (VHDL-2099)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 110  (VHDL-2099)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 142  (VHDL-2099)
Warning: Initial values for signals are not supported for synthesis.
They are ignored  on line 148  (VHDL-2022)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 169  (VHDL-2099)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 189  (VHDL-2099)
1
analyze -f VHDL -library WORK preg.vhdl
/home/profelec/nboulay/fcpu/eu_imu/preg.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 26
(VHDL-2024)
Warning: Can't find the entity 'PipeReg'
      in the library 'WORK'. (LBR-1)
Error: Cannot find entity PipeReg  on line 35  (VHDL-2203)
0
analyze -f VHDL -library WORK prtree.vhdl
/home/profelec/nboulay/fcpu/eu_imu/prtree.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 27  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 28
(VHDL-2024)
Warning: Can't find the entity 'Piped_ReduceTree'
      in the library 'WORK'. (LBR-1)
Error: Cannot find entity Piped_ReduceTree  on line 49  (VHDL-2203)
0
analyze -f VHDL -library WORK ciainc.vhdl
/home/profelec/nboulay/fcpu/eu_imu/ciainc.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Warning: Initial values for signals are not supported for synthesis.
They are ignored  on line 65  (VHDL-2022)
1
analyze -f VHDL -library WORK ciacore.vhdl
/home/profelec/nboulay/fcpu/eu_imu/ciacore.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
1
analyze -f VHDL -library WORK ciarow.vhdl
/home/profelec/nboulay/fcpu/eu_imu/ciarow.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 39  (VHDL-2023)
1
analyze -f VHDL -library WORK ciadds.vhdl
/home/profelec/nboulay/fcpu/eu_imu/ciadds.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 56  (VHDL-2023)
1
analyze -f VHDL -library WORK ciadd2.vhdl
/home/profelec/nboulay/fcpu/eu_imu/ciadd2.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 61  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 72  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 72  (VHDL-2023)
Warning: Initial values for signals are not supported for synthesis.
They are ignored  on line 85  (VHDL-2022)
Warning: Assert and report statements are not supported for synthesis.
They are ignored  on line 102  (VHDL-2099)
1
analyze -f VHDL -library WORK pciainc.vhdl
/home/profelec/nboulay/fcpu/eu_imu/pciainc.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 27
(VHDL-2024)
Warning: Can't find the entity 'Piped_CIA_Inc'
      in the library 'WORK'. (LBR-1)
Error: Cannot find entity Piped_CIA_Inc  on line 47  (VHDL-2203)
0
analyze -f VHDL -library WORK pciarow.vhdl
/home/profelec/nboulay/fcpu/eu_imu/pciarow.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 26
(VHDL-2024)
Warning: Can't find the entity 'Piped_CIA_Row'
      in the library 'WORK'. (LBR-1)
Error: Cannot find entity Piped_CIA_Row  on line 45  (VHDL-2203)
0
analyze -f VHDL -library WORK pciadd2.vhdl
/home/profelec/nboulay/fcpu/eu_imu/pciadd2.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 27  (VHDL-2023)
Warning: Statements in an entity declaration are not supported for
synthesis. They are ignored in entity Piped_CIAdd  on line 23
(VHDL-2001)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 78  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 78
(VHDL-2024)
1
analyze -f VHDL -library WORK imul64.vhdl
/home/profelec/nboulay/fcpu/eu_imu/imul64.vhdl:
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 25  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 26  (VHDL-2023)
Warning: Statements in an entity declaration are not supported for
synthesis. They are ignored in entity IMul64  on line 23  (VHDL-2001)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 102  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 103  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 104  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 113  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 114  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 115  (VHDL-2023)
Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
line 129  (VHDL-2023)
Error: Only generics of type INTEGER are supported for synthesis. -  on
line 129
(VHDL-2024)
1
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Wed Mar 21 22:54:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02593 for ; Thu, 22 Mar 2001 05:11:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 05:11:38 +0100 (MET) Received: (qmail 30561 invoked by uid 0); 21 Mar 2001 21:57:38 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx09) with SMTP; 21 Mar 2001 21:57:38 -0000 X-eGroups-Return: sentto-1101623-2542-985211819-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 21 Mar 2001 21:57:01 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 21 Mar 2001 21:56:59 -0000 Received: (qmail 10083 invoked from network); 21 Mar 2001 21:56:28 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 21 Mar 2001 21:56:28 -0000 Received: from unknown (HELO orion.uk.insnet.net) (194.177.174.244) by mta2 with SMTP; 21 Mar 2001 21:56:28 -0000 Received: from ws131.warminsterschool.org.uk ([195.59.6.120]) by orion.uk.insnet.net (8.9.3/8.9.3) with SMTP id VAA09317; Wed, 21 Mar 2001 21:56:26 GMT Message-Id: <3.0.6.32.20010321215417.007bec20@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com, f-cpu@yahoogroups.com In-Reply-To: References: <3AB8ED82.1CB361E2@mentor.com> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 21 Mar 2001 21:54:17 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andi, perhaps it is possible to work together with the translation of the
manual, so not everyone has to translate 65 pages, or at least to check
each other translations
Kristian

At 21:03 21/03/01 +0100, Andreas Romeyke wrote:
>Hello,
>
>> That, and the german translation, are two interesting efforts.
>
>I want to translate to the german manual in next two weeks, if you want.
>Thats quite simpler than my last try.
>
>In past two months I tried to find out a way to build a SIMD-shifter. But
>my knowledge about hardware design is too small to get a result of the
>specification :). IMHO the shifter will be have logical gates with more
>than 8 inputs, or more than 2 clocks, or with too long data path or such
>complex as multiplier is.
>
>I did not find any way to build small versions of the shifter and build a
>higher set of this like a look-a-head adder or lego-bricks. One source of
>the problems is IMHO that a shift of a 64 bit register must have 31 shifts
>left or right and a 8x8 bit register has 3 shifts left or right, another
>source is the handling of signed and unsigned registers. IMHO it would
>make all arithmetic and logical operations and units quite simpler if we
>operate only with unsigned and have a special unit to combine 2 or more
>registers to handle signed operations, because the compiler can delegate
>tasks to the normal arithmetic units and a special task to a signed unit
>in parallel.  
>
>Bye Andreas
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Thu Mar 22 01:33:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02653 for ; Thu, 22 Mar 2001 05:11:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 05:11:53 +0100 (MET) Received: (qmail 349 invoked by uid 0); 22 Mar 2001 00:32:53 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx02) with SMTP; 22 Mar 2001 00:32:53 -0000 X-eGroups-Return: sentto-1101623-2544-985221172-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fg.egroups.com with NNFMP; 22 Mar 2001 00:32:53 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 00:32:51 -0000 Received: (qmail 98788 invoked from network); 22 Mar 2001 00:32:49 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 22 Mar 2001 00:32:49 -0000 Received: from unknown (HELO postfix2-2.free.fr) (213.228.0.140) by mta1 with SMTP; 22 Mar 2001 00:32:48 -0000 Received: from free.fr (nas-cbv-2-23-102.dial.proxad.net [213.228.23.102]) by postfix2-2.free.fr (Postfix) with ESMTP id B133D6B701; Thu, 22 Mar 2001 01:32:44 +0100 (CET) Message-ID: <3AB94844.4060805@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com Cc: Kristian-Ole Riehn , Antonio =?ISO-8859-1?Q?D=EDaz?= Zamora References: <001201c0b184$74613160$88789ea9@pc-tony.lib.cult.cu> <20010321171841.A570@bocal.cs.univ-paris8.fr> <3AB8ED82.1CB361E2@mentor.com> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 01:33:08 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Manual translations Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N

Yann GUIDON wrote:

> Paul Marques Mota wrote:
>
>> On Tue, Mar 20, 2001 at 04:26:40PM -0500, Antonio D=EDaz Zamora wr= ote:
>>
>>> hello everybody
>>
>> Hello
>>
>>> I want to know if there is any effort to translate the manual = to spanish,
>>
>> No, there is no such thing at the moment.
>
>
> right : this is one desirable thing :-)
> That, and the german translation, are two interesting efforts.
>
> Philippe Trbich is currently doing the french translation,
> the original LaTeX files are available from http://f-cpu.seul.org/manual/
> (incomplete). Philippe has done 4 parts (from the 7 ones), they give t= he
> important backgrounds. i don't remember the url where he has put his f= iles.
the files in french are on http://philippe.trbich.free.fr/pub/fcpu/manuel/
for the parts updated from the old manual in english. The last 3 parts
aren't updated and I want to avoid waste of time : I will translate it
when this will be done. If someone could reread the translation it will be great since some terms are let in english (I haven't found a good
translation!)

> plus, since i don't speak spanish and am not perfect in german, i'll h= ave
> troubles if i want to verify the translation, but that's not the worst=
> problem :-)
>
> we'll have to revamp all the web sites and files in order to have a cl= ean
> distribution, but that will come in the next months.
>
>
>>> and if there is no such a thing, I will start it myself. Comme= nts ?
>>
>> That would be a great thing!
>
> indeed !
>
>
>>> Antonio Diaz Zamora
>>
>>         Paul
>
> YG
>
> speaking for himself
A+

>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From VoiceOfTibet@aol.com Thu Mar 22 06:48:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00302 for ; Thu, 22 Mar 2001 16:38:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 16:38:13 +0100 (MET) Received: (qmail 24143 invoked by uid 0); 22 Mar 2001 05:48:56 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx11) with SMTP; 22 Mar 2001 05:48:56 -0000 X-eGroups-Return: sentto-1101623-2545-985240134-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 22 Mar 2001 05:48:55 -0000 X-Sender: VoiceOfTibet@aol.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 05:48:54 -0000 Received: (qmail 17072 invoked from network); 22 Mar 2001 05:48:53 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 22 Mar 2001 05:48:53 -0000 Received: from unknown (HELO imo-m01.mx.aol.com) (64.12.136.4) by mta1 with SMTP; 22 Mar 2001 05:48:53 -0000 Received: from VoiceOfTibet@aol.com by imo-m01.mx.aol.com (mail_out_v29.5.) id r.f6.8540a60 (4587) for ; Thu, 22 Mar 2001 00:48:43 -0500 (EST) Message-ID: To: f-cpu@yahoogroups.com X-Mailer: AOL 5.0 for Windows sub 116 From: VoiceOfTibet@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 00:48:42 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Designing a CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello.

I recently joined this e-mail list.

At what stage is the CPU design?  Where can I obtain a block diagram
of the proposed design?

Thanks,
-Dwight
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu Mar 22 07:43:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00308 for ; Thu, 22 Mar 2001 16:38:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 16:38:14 +0100 (MET) Received: (qmail 16023 invoked by uid 0); 22 Mar 2001 06:43:35 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx11) with SMTP; 22 Mar 2001 06:43:35 -0000 X-eGroups-Return: sentto-1101623-2546-985243413-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 22 Mar 2001 06:43:33 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 06:43:32 -0000 Received: (qmail 39994 invoked from network); 22 Mar 2001 06:43:31 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 22 Mar 2001 06:43:31 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta3 with SMTP; 22 Mar 2001 07:44:35 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA30688 for ; Thu, 22 Mar 2001 08:43:30 +0200 (EET) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <20010322011444.30361@thrai.stud.uni-hannover.de> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 08:43:29 +0200 (EET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 22 Mar 2001, Michael Riepe wrote:

> > heavy to manage(look at the number of analyze lines for a single unit !)
> > and have absolutely no sense !(compile flatten all hierarchy)
>
> What exactly do you propose instead?  What's best for synthesis?

Depens what is the target. For ASICs Synopsys DC is the best synthesis
tool currently. In the physical synthesis area there are other
competitors, but I guess now more important is to see that the stuff
compiles and get some timing reports.

For FPGAs simple answer is Synplicity Synplify. Synplify is even very
simple to use. Just load files and press run. And it is lightning fast
compared to DC. And the results Synplify make for FPGAs are amazing.
Leonardo is the only tool which can even get near the results.

> > Add for none synthetising things.
> > -- pragma translate_off
> > ...
> > -- pragma translate_on
>
> Do all synthesis tools support that?

At least all the major ones should support those.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 22 10:27:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00323 for ; Thu, 22 Mar 2001 16:38:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 16:38:17 +0100 (MET) Received: (qmail 8909 invoked by uid 0); 22 Mar 2001 09:35:02 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx09) with SMTP; 22 Mar 2001 09:35:02 -0000 X-eGroups-Return: sentto-1101623-2547-985253658-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 22 Mar 2001 09:34:57 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 09:34:17 -0000 Received: (qmail 75845 invoked from network); 22 Mar 2001 09:34:17 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 22 Mar 2001 09:34:17 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 22 Mar 2001 09:34:17 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA19287; Thu, 22 Mar 2001 01:34:13 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8TR9; Thu, 22 Mar 2001 09:39:53 -0000 Sender: yanng@relay1.mentorg.com Message-ID: <3AB9C56D.992FEE00@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: Allen Leung Cc: "f-cpu@egroups.com" References: <200103212229.RAA16993@slinky.cs.nyu.edu> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 10:27:09 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: f-cpu Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Allen Leung wrote:
> > hello,
> >
> > i just discovered MLRISC and wonder if a port to the F-CPU is possible.
> > the F-CPU is a new RISC model that is developped in an open community
> > and wants to provide a free (FSF sense) alternative to ia64 and other
> > architectures. it should'nt be extremely difficult to make a new
> > backend, a preliminary GCC backend has been done but it does not exploit
> > all the power of the F-CPU (wide SIMD registers, specific instructions ect).
> > I hope that MLRISC will help generate more efficient code from "legacy" software,
> > before we have an ultimate software generator.
> >
> > YG
> >
> > speaking for himself
> >
>
> Hi,
>    Sounds interesting.
>    I'm not familiar with F-CPU, but if it is not too different from
> traditional RISC (MIPS, Alpha, etc) then making a backend should be easy.
> If only assembly output is needed, then usually it takes a few days for
> me to get a prototype running.  More time for others who aren't familiar
> with MLRISC and/or SML, of course.
>
> However, MLRISC currently doesn't have phases that deal with SIMD instructions,
> so those won't be taken advantage of.

good morning,

the F-CPU is described in a manual, an old version (1 year old) is available
online from http://www.f-cpu.de/man/i7/summary.html and we are currently working
on updating it. it has not changed a lot in the last year anyway : here is a
copy-n-paste of the description of the model...

Part 2 : General description of the F-CPU
      2.1 The main chacteristics
      2.2 The instructions are 32-bit wide
      2.3 Register 0 is "read-as-zero/unmodifiable"
      2.4 The F-CPU has 64 registers
      2.5 The F-CPU is a variable-size processor
      2.6 The F-CPU is SIMD-oriented
      2.7 The F-CPU has generalized registers
      2.8 The F-CPU has special registers
      2.9 The F-CPU has no stack pointer
      2.10 The F-CPU has no condition code register
      2.11 The F-CPU is endianless
      2.12 The F-CPU uses paged memory
      2.13 The F-CPU stores the state of a task in Context Memory Blocks
      2.14 The F-CPU can use the CMBs to single-step tasks
      2.15 The F-CPU uses a simple protection mechanism

>From the start, it looks like a ALPHA-wannabe but with some major
changes, mainly 64 SIMD regs of "undetermined size".
however a lot of details make a big difference, such as the addressing modes
and the control flow.

I don't know if anyone in the f-cpu group has learnt ML, but a back-end
can certainly be derived from the ALPHA back-end. However, when it comes
to optimize for the FC0 (F-CPU Core #0, under development), it gets "interesting"...

Since there is no SIMD HLL today, i don't expect a utilization of the SIMD
capabilities. However i am working on a tool that should let us use SIMD
in the future.

if you want to see an existing back-end, look at http://www.f-cpu.de/gcc/
and then see how much of the existing instruction set is actually implemented
for a classical back-end...


thank you for your answer, and ask around you if other people are interested
by this project,

> cheers,
> allen
YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Matringe Thu Mar 22 10:39:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00326 for ; Thu, 22 Mar 2001 16:38:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 16:38:18 +0100 (MET) Received: (qmail 30215 invoked by uid 0); 22 Mar 2001 09:38:06 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx18) with SMTP; 22 Mar 2001 09:38:06 -0000 X-eGroups-Return: sentto-1101623-2548-985253884-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 22 Mar 2001 09:38:05 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 09:38:04 -0000 Received: (qmail 64056 invoked from network); 22 Mar 2001 09:38:03 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 22 Mar 2001 09:38:03 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 22 Mar 2001 10:39:07 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id JAA18852 for ; Thu, 22 Mar 2001 09:37:56 GMT X-To: Message-ID: <3AB9C853.6B02AD43@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <3AB91E74.455897CD@seul.org> <20010322011444.30361@thrai.stud.uni-hannover.de> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 10:39:31 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:

> > Add for none synthetising things.
> > -- pragma translate_off
> > ...
> > -- pragma translate_on
>
> Do all synthesis tools support that?

Many do. It's Synopsys's way but it became some kind of standard. I know
Leonardo supports it.


[...]
> > **Error: /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl  line 43
> >       Range 'Z' to '-' not covered by choices. (VSS-838)
> > 1
>
> That's just plain stupid.  The result of to_X01() can be either
> 'X', or '0', or '1', and I handle all these cases.

The tool is a bit stupid and doesn't care about the actual possible
values returned by the function. The signal is std_logic therefore it
can have any of the 7 or 9 (I don't remember) different values defined
for std_logic.


> Sigh -- I guess I gotta convert the result explicitly, or
> replace the last clause with `when others =>'.  Or remove
> vlut.vhdl.

Just add a "when others => null;" clause and the tool will be happy
(that's the only use for such a clause, IMHO)

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 22 10:45:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00329 for ; Thu, 22 Mar 2001 16:38:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 16:38:19 +0100 (MET) Received: (qmail 805 invoked by uid 0); 22 Mar 2001 09:53:53 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx12) with SMTP; 22 Mar 2001 09:53:53 -0000 X-eGroups-Return: sentto-1101623-2549-985254832-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 22 Mar 2001 09:53:53 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 09:53:51 -0000 Received: (qmail 26212 invoked from network); 22 Mar 2001 09:53:51 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 22 Mar 2001 09:53:51 -0000 Received: from unknown (HELO ns1.mentorg.com) (192.94.38.65) by mta1 with SMTP; 22 Mar 2001 09:53:50 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by ns1.mentorg.com (8.8.8/CF5.40F) id BAA07646; Thu, 22 Mar 2001 01:53:48 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8TS6; Thu, 22 Mar 2001 09:58:38 -0000 Sender: yanng@ns1.mentorg.com Message-ID: <3AB9C9D3.2D8312DC@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 10:45:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Designing a CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N VoiceOfTibet@aol.com wrote:
> Hello.
>
> I recently joined this e-mail list.
welcome !

> At what stage is the CPU design?
there's no milestone or precise development rule, however :
* we have :
    - a stable basic RISC architecture
    - a manual (in english) that explains the background and general stuffs
    - several websites
    - several articles + participation to exhibitions/events
    - several people working in the informal team, which grows

* we are doing :
    - manual update (one of my numerous tasks that i procrastinate)
    - manual translation to french (advanced), to spanish and to german (announced)
    - VHDL coding (started, see http://www.f-cpu.de/design/ (not updated yet))
    - mailing list move to seul.org (still trying to configure the server)
    - a lot of babbling, as usual since the beginning, years ago...

* what gotta be done : (short term)
    - finish manual update to v0.2.3
    - website update
    - CVS setup
    - agree on a distribution charter
    => file cleaning/synchronisation
    => make a first (partial) distro

>  Where can I obtain a block diagram of the proposed design?
in the manual, but you can look at an old version (1 year old) at
http://www.f-cpu.de/design/

> Thanks,
> -Dwight
you're welcome,

YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Thu Mar 22 21:57:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01160 for ; Thu, 22 Mar 2001 21:31:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 21:31:32 +0100 (MET) Received: (qmail 7796 invoked by uid 0); 22 Mar 2001 20:23:11 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx15) with SMTP; 22 Mar 2001 20:23:11 -0000 X-eGroups-Return: sentto-1101623-2550-985292590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 22 Mar 2001 20:23:11 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 20:23:09 -0000 Received: (qmail 36308 invoked from network); 22 Mar 2001 20:23:07 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 22 Mar 2001 20:23:07 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 22 Mar 2001 21:24:11 -0000 Received: from art1.none.de (dialin176.pg2-nt.berlin.nikoma.de [213.54.65.176]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f2MKNBb15369 for ; Thu, 22 Mar 2001 21:23:11 +0100 X-Authentication-Warning: host-2.server.itns.de: Host dialin176.pg2-nt.berlin.nikoma.de [213.54.65.176] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14gC9Z-0001Iv-00 for ; Thu, 22 Mar 2001 21:57:53 +0100 To: f-cpu@yahoogroups.com In-Reply-To: <3.0.6.32.20010321215417.007bec20@pop1.edex.net.uk> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 21:57:53 +0100 (CET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello Kristian Ole,

> Andi, perhaps it is possible to work together with the translation of the

I hate Andi, I like Andreas ;-)

> manual, so not everyone has to translate 65 pages, or at least to check
> each other translations

Jup. My pattern are the manual as TeX-files. I want to translate p1 to p3
and you can have p4 to p6, is this right?

At the end we can read crossover our translations.

Bye Andreas

PS.:
to all tahae fans:
I suggest to forget the ugly tahae scheme at this
mailing-list. Tahae is superfluidous, you cite in letters and articles
never whole books, is not it? (tahae means text at the head, fullquote at
the end.)


Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Thu Mar 22 21:37:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01163 for ; Thu, 22 Mar 2001 21:31:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 22 Mar 2001 21:31:32 +0100 (MET) Received: (qmail 12642 invoked by uid 0); 22 Mar 2001 20:23:42 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx27) with SMTP; 22 Mar 2001 20:23:42 -0000 X-eGroups-Return: sentto-1101623-2551-985292620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 22 Mar 2001 20:23:41 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 20:23:40 -0000 Received: (qmail 37515 invoked from network); 22 Mar 2001 20:23:39 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Mar 2001 20:23:39 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.57) by mta1 with SMTP; 22 Mar 2001 20:23:38 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 003119E61 for ; Thu, 22 Mar 2001 21:37:34 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3ABA628E.468CFF99@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AB91E74.455897CD@seul.org> <20010322011444.30361@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 21:37:34 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Wed, Mar 21, 2001 at 10:34:44PM +0100, Nicolas wrote:
> > I send you my log from a tentative to compile imul64. And sorry f= or
> > Michael, there's many warnings and errors. I didn't look at the c= ode.
> > And please remove all the stupid .vhd file like or2, or3, that's = so
> > heavy to manage(look at the number of analyze lines for a single = unit !)
> > and have absolutely no sense !(compile flatten all hierarchy)
>
> What exactly do you propose instead?  What's best for synthesis?<= BR> >

Most of the time, try to imagine what kind of hardware could be
synthetise. DC compiler aren't stupid if it see toto <=3D t1 or t2 ot t3= ,
it will use a 3-or gate or 2 2-or gates if the gate are quicker.

> > Add for none synthetising things.
> > -- pragma translate_off
> > ...
> > -- pragma translate_on
>
> Do all synthesis tools support that?
>

I suppose... It is used by Leon, which is synthetize by dc compiler
(synopsys) and Altera & Xilinx tools...

> [...]
> > /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl:
> > Warning: Type of the generic is assumed to be 'Integer' in synthe= sis  on
> > line 25  (VHDL-2023)
> >           =             &nb= sp;       when '0' =3D> null;
> >           =             &nb= sp;       ^
> > **Error: /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl  line = 43
> >       'U' not covered by choices. (= VSS-834)
> >           =             &nb= sp;       when '0' =3D> null;
> >           =             &nb= sp;       ^
> > **Error: /home/profelec/nboulay/fcpu/eu_imu/vlut.vhdl  line = 43
> >       Range 'Z' to '-' not covered = by choices. (VSS-838)
> > 1
>
> That's just plain stupid.  The result of to_X01() can be either '= X',
> or '0', or '1', and I handle all these cases.  Sigh -- I guess I = gotta
> convert the result explicitly, or replace the last clause with `when > others =3D>'.  Or remove vlut.vhdl.
>

Yes, always use when others... in switch statement.

> [...]
> > /home/profelec/nboulay/fcpu/eu_imu/reduce_tree.vhdl:
> > Warning: Type of the generic is assumed to be 'Integer' in synthe= sis  on
> > line 25  (VHDL-2023)
> > Warning: Type of the generic is assumed to be 'Integer' in synthe= sis  on
> > line 26  (VHDL-2023)
> > Warning: Type of the generic is assumed to be 'Integer' in synthe= sis  on
> > line 27  (VHDL-2023)
>
> Last time I looked, `natural' was a subtype of `integer'.  So wha= t?
>

Natural and Positive are suppose to be integer.

> > Warning: Statements in an entity declaration are not supported fo= r
> > synthesis. They are ignored in entity ReduceTree  on line 23=
> > (VHDL-2001)
>
> Can be ignored (or masked out with --pragma).
>
> > /home/profelec/nboulay/fcpu/eu_imu/preg.vhdl:
> > Warning: Type of the generic is assumed to be 'Integer' in synthe= sis  on
> > line 25  (VHDL-2023)
> > Error: Only generics of type INTEGER are supported for synthesis.= -  on
> > line 26
> >  (VHDL-2024)
>
> No boolean generics?  Now what does THAT mean?  Do I have to= convert
> them to integer and use 0/1 to switch them on and off?  That suck= s.
>

Boolean are very strange in VHDL...
Never forget that front end of vhdl compiler aren't so cool. Remenber
that i always insit to use VHDL 87 and 93, you understand why...

> > Warning: Can't find the entity 'PipeReg'
> >       in the library 'WORK'. (LBR-1= )
> > Error: Cannot find entity PipeReg  on line 35  (VHDL-22= 03)
> > 0
>
> Probably due to earlier errors, like all the other errors that follow.=
>

Yep !

I hope you could send me a correct file to retry very soon!

nicO


> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Thu Mar 22 22:22:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02750 for ; Fri, 23 Mar 2001 05:12:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 05:12:53 +0100 (MET) Received: (qmail 21713 invoked by uid 0); 22 Mar 2001 21:24:33 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx03) with SMTP; 22 Mar 2001 21:24:33 -0000 X-eGroups-Return: sentto-1101623-2552-985296261-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 22 Mar 2001 21:24:22 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 21:24:19 -0000 Received: (qmail 6896 invoked from network); 22 Mar 2001 21:24:18 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Mar 2001 21:24:18 -0000 Received: from unknown (HELO orion.uk.insnet.net) (194.177.174.244) by mta1 with SMTP; 22 Mar 2001 21:24:18 -0000 Received: from ws132.warminsterschool.org.uk ([195.59.6.114]) by orion.uk.insnet.net (8.9.3/8.9.3) with SMTP id VAA28876; Thu, 22 Mar 2001 21:24:16 GMT Message-Id: <3.0.6.32.20010322212206.007bdd00@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com, f-cpu@yahoogroups.com In-Reply-To: References: <3.0.6.32.20010321215417.007bec20@pop1.edex.net.uk> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 21:22:06 +0000 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N OK Andreas, thats alright for me!
Just one question before I start: Do I have an actual version with Ver.
0.2.2 Beta ?
K> Riehn

At 21:57 22/03/01 +0100, Andreas Romeyke wrote:
>Hello Kristian Ole,
>
>> Andi, perhaps it is possible to work together with the translation of the
>
>I hate Andi, I like Andreas ;-)
>
>> manual, so not everyone has to translate 65 pages, or at least to check
>> each other translations
>
>Jup. My pattern are the manual as TeX-files. I want to translate p1 to p3
>and you can have p4 to p6, is this right?
>
>At the end we can read crossover our translations.
>
>Bye Andreas
>
>PS.:
>to all tahae fans:
>I suggest to forget the ugly tahae scheme at this
>mailing-list. Tahae is superfluidous, you cite in letters and articles
>never whole books, is not it? (tahae means text at the head, fullquote at
>the end.)
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Thu Mar 22 22:47:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02753 for ; Fri, 23 Mar 2001 05:12:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 05:12:54 +0100 (MET) Received: (qmail 12198 invoked by uid 0); 22 Mar 2001 21:33:32 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx11) with SMTP; 22 Mar 2001 21:33:32 -0000 X-eGroups-Return: sentto-1101623-2553-985296807-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 22 Mar 2001 21:33:31 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 21:33:24 -0000 Received: (qmail 11610 invoked from network); 22 Mar 2001 21:33:19 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 22 Mar 2001 21:33:19 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.173.111) by mta3 with SMTP; 22 Mar 2001 22:34:22 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C02299E61 for ; Thu, 22 Mar 2001 22:47:14 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3ABA72E2.5E5E3AF0@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103212229.RAA16993@slinky.cs.nyu.edu> <3AB9C56D.992FEE00@mentor.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 22:47:14 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: f-cpu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann GUIDON a =E9crit :
>
> Allen Leung wrote:
> > > hello,
> > >
> > > i just discovered MLRISC and wonder if a port to the F-CPU i= s possible.
> > > the F-CPU is a new RISC model that is developped in an open = community
> > > and wants to provide a free (FSF sense) alternative to ia64 = and other
> > > architectures. it should'nt be extremely difficult to make a= new
> > > backend, a preliminary GCC backend has been done but it does= not exploit
> > > all the power of the F-CPU (wide SIMD registers, specific in= structions ect).
> > > I hope that MLRISC will help generate more efficient code fr= om "legacy" software,
> > > before we have an ultimate software generator.
> > >
> > > YG
> > >
> > > speaking for himself
> > >
> >
> > Hi,
> >    Sounds interesting.
> >    I'm not familiar with F-CPU, but if it is not t= oo different from
> > traditional RISC (MIPS, Alpha, etc) then making a backend should = be easy.
> > If only assembly output is needed, then usually it takes a few da= ys for
> > me to get a prototype running.  More time for others who are= n't familiar
> > with MLRISC and/or SML, of course.
> >
> > However, MLRISC currently doesn't have phases that deal with SIMD= instructions,
> > so those won't be taken advantage of.
>
> good morning,
>
> the F-CPU is described in a manual, an old version (1 year old) is ava= ilable
> online from http:/= /www.f-cpu.de/man/i7/summary.html and we are currently working
> on updating it. it has not changed a lot in the last year anyway : her= e is a
> copy-n-paste of the description of the model...
>
> Part 2 : General description of the F-CPU

Could add conditionnal move, not so current, no ?

>       2.1 The main chacteristics
>       2.2 The instructions are 32-bit wi= de
>       2.3 Register 0 is "read-as-ze= ro/unmodifiable"
>       2.4 The F-CPU has 64 registers
>       2.5 The F-CPU is a variable-size p= rocessor
>       2.6 The F-CPU is SIMD-oriented
>       2.7 The F-CPU has generalized regi= sters

Multiple of 64 bits of power of 2 (64*2^n). The main goal is to produice binary compatible sofware. Funny, no ?

>       2.8 The F-CPU has special register= s
>       2.9 The F-CPU has no stack pointer=
>       2.10 The F-CPU has no condition co= de register
>       2.11 The F-CPU is endianless

I think it's just an add of a mux in the critical path.

>       2.12 The F-CPU uses paged memory
As opposed to segmented memory ?(just for my knowledge)

>       2.13 The F-CPU stores the state of= a task in Context Memory Blocks
A no comprendo, l=E0.
>       2.14 The F-CPU can use the CMBs to= single-step tasks

Non, plus.


>       2.15 The F-CPU uses a simple prote= ction mechanism
>
> >From the start, it looks like a ALPHA-wannabe but with some major<= BR> > changes, mainly 64 SIMD regs of "undetermined size".
> however a lot of details make a big difference, such as the addressing= modes
> and the control flow.
>
> I don't know if anyone in the f-cpu group has learnt ML, but a back-en= d
> can certainly be derived from the ALPHA back-end. However, when it com= es
> to optimize for the FC0 (F-CPU Core #0, under development), it gets &q= uot;interesting"...
>
> Since there is no SIMD HLL today, i don't expect a utilization of the = SIMD
> capabilities. However i am working on a tool that should let us use SI= MD
> in the future.
>
> if you want to see an existing back-end, look at http://www.f-cpu.de/gcc/
> and then see how much of the existing instruction set is actually impl= emented
> for a classical back-end...
>
> thank you for your answer, and ask around you if other people are inte= rested
> by this project,
>
> > cheers,
> > allen
> YG
>
> speaking for himself
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Fri Mar 23 00:29:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02777 for ; Fri, 23 Mar 2001 05:13:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 05:13:01 +0100 (MET) Received: (qmail 13579 invoked by uid 0); 22 Mar 2001 22:19:48 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx09) with SMTP; 22 Mar 2001 22:19:48 -0000 X-eGroups-Return: sentto-1101623-2554-985299585-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 22 Mar 2001 22:19:46 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 22 Mar 2001 22:19:44 -0000 Received: (qmail 50660 invoked from network); 22 Mar 2001 22:19:43 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 22 Mar 2001 22:19:43 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta1 with SMTP; 22 Mar 2001 22:19:43 -0000 Received: from art1.none.de (dialin31.pg4-nt.berlin.nikoma.de [213.54.67.31]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f2MMJlb24024 for ; Thu, 22 Mar 2001 23:19:48 +0100 X-Authentication-Warning: host-2.server.itns.de: Host dialin31.pg4-nt.berlin.nikoma.de [213.54.67.31] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14gEW4-000092-00 for ; Fri, 23 Mar 2001 00:29:16 +0100 To: f-cpu@yahoogroups.com In-Reply-To: <3.0.6.32.20010322212206.007bdd00@pop1.edex.net.uk> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 00:29:16 +0100 (CET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello Kristian-Ole,

> OK Andreas, thats alright for me!
> Just one question before I start: Do I have an actual version with Ver.
> 0.2.2 Beta ?


Jep. Thats Yann Guideons version at fcpu.seul.org.


Bye Andreas
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Fri Mar 23 02:59:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA02795 for ; Fri, 23 Mar 2001 05:13:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 05:13:06 +0100 (MET) Received: (qmail 14727 invoked by uid 0); 23 Mar 2001 01:53:46 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx14) with SMTP; 23 Mar 2001 01:53:46 -0000 X-eGroups-Return: sentto-1101623-2555-985312399-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 23 Mar 2001 01:53:23 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 23 Mar 2001 01:53:18 -0000 Received: (qmail 46674 invoked from network); 23 Mar 2001 01:53:18 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 Mar 2001 01:53:18 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta3 with SMTP; 23 Mar 2001 02:54:22 -0000 Received: from f-cpu.org (nas4-106.ras.club-internet.fr [195.36.203.106]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA14495 for ; Fri, 23 Mar 2001 02:53:11 +0100 (MET) Message-ID: <3ABAAE10.D1C19AC7@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103212229.RAA16993@slinky.cs.nyu.edu> <3AB9C56D.992FEE00@mentor.com> <3ABA72E2.5E5E3AF0@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 02:59:44 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: f-cpu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

Nicolas wrote:
> Yann GUIDON a =E9crit :
> > Allen Leung wrote:
> > > > hello,

<snip>

> > Part 2 : General description of the F-CPU
> Could add conditionnal move, not so current, no ?
well, it's not a very particular instruction either.
look at the ALPHA or similar CPUs. What is more striking is
that the CMOVE and CJMP have a similar structure, but that's
not worth mentioning in the headlines.

> >       2.1 The main chacteristics > >       2.2 The instructions are 32-b= it wide
> >       2.3 Register 0 is "read-= as-zero/unmodifiable"
> >       2.4 The F-CPU has 64 register= s
> >       2.5 The F-CPU is a variable-s= ize processor
> >       2.6 The F-CPU is SIMD-oriente= d
> >       2.7 The F-CPU has generalized= registers
> Multiple of 64 bits of power of 2 (64*2^n). The main goal is to produi= ce
> binary compatible sofware. Funny, no ?
well it should be able to support 32-bit registers one day, but not much, better use a LEON in that case. However, i never thought of the 64*2^N stuf= f :
i wrote until now : "any power of two, above 5" which is easily u= nderstood.

> >       2.11 The F-CPU is endianless<= BR> > I think it's just an add of a mux in the critical path.
well, not exactly : a rough estimation shows that it requires
some kind of specific local Xbar which takes some large data, and
a full clock cycle, but it's handy though.

> >       2.12 The F-CPU uses paged mem= ory
> As opposed to segmented memory ?(just for my knowledge)
well, the virtual memory is split into pages, that's all.
there is no notion of segment, here : we're not copying the x86 ;-)

> >       2.13 The F-CPU stores the sta= te of a task in Context Memory Blocks
> A no comprendo, l=E0.
RTFM ;-)

> >       2.14 The F-CPU can use the CM= Bs to single-step tasks
> Non, plus.
idem ;-)

the CMB (Context Memory Blocks) are not yet worth worrying,
though later they can give us some troubles if we don't manage them
correctly : they can be simply added on top of a RISC core.

ok, gotta sleep,...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"WeddingChannel.com,
WeddingChannel.com, Click Here!
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Fri Mar 23 07:47:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00296 for ; Fri, 23 Mar 2001 20:10:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 20:10:37 +0100 (MET) Received: (qmail 32104 invoked by uid 0); 23 Mar 2001 06:47:56 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx18) with SMTP; 23 Mar 2001 06:47:56 -0000 X-eGroups-Return: sentto-1101623-2556-985330075-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 23 Mar 2001 06:47:55 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 23 Mar 2001 06:47:54 -0000 Received: (qmail 59786 invoked from network); 23 Mar 2001 06:47:54 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 23 Mar 2001 06:47:54 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 23 Mar 2001 06:47:53 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA30110 for ; Fri, 23 Mar 2001 08:47:51 +0200 (EET) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3ABA628E.468CFF99@seul.org> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 08:47:50 +0200 (EET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 22 Mar 2001, Nicolas wrote:

> I hope you could send me a correct file to retry very soon!

If someone needs quick synthesis runs with Synplify Pro or Lenorado 2000 I
can do them if you send me the files. I have also access to DC Ultra, but
my favorite hobby is not Synopsys synthesis scripts :)

Has anyone tought how f-cpu synthesis will be done in the future. As far
as I know there are no good free synthesizers available. And after
synthesis we need test structures, test vectors etc. Possibly ECO
compiler for the small changes during layout etc. And then the actual
layout unless the vendor does that. I don't know free tools for this flow,
Alliance can do something but it is very restricted in every aspect. Also
the ASIC libraries are distributer under strict NDAs etc.

And how about top level and block level verification etc. Top level
verification of CPU is not a trivial task. For example Sun uses about 1000
servers in their simulation cluster to simulate CPUs. Also the creation of
test streams (directed and random) and checking them with behavioral
models needs quite big amount of work. It is not enough to write the RTL.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Mar 23 19:54:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA00326 for ; Fri, 23 Mar 2001 20:10:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 23 Mar 2001 20:10:44 +0100 (MET) Received: (qmail 12115 invoked by uid 0); 23 Mar 2001 18:40:39 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx26) with SMTP; 23 Mar 2001 18:40:39 -0000 X-eGroups-Return: sentto-1101623-2557-985372837-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 23 Mar 2001 18:40:37 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 23 Mar 2001 18:40:36 -0000 Received: (qmail 85043 invoked from network); 23 Mar 2001 18:40:36 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 Mar 2001 18:40:36 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.65) by mta2 with SMTP; 23 Mar 2001 18:40:35 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 980AA9E46 for ; Fri, 23 Mar 2001 19:54:35 +0100 (CET) Sender: nico@localhost.localdomain Message-ID: <3ABB9BEB.424D752@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103212229.RAA16993@slinky.cs.nyu.edu> <3AB9C56D.992FEE00@mentor.com> <3ABA72E2.5E5E3AF0@seul.org> <3ABAAE10.D1C19AC7@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 19:54:35 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: f-cpu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :

> > >       2.12 The F-CPU uses page= d memory
> > As opposed to segmented memory ?(just for my knowledge)
> well, the virtual memory is split into pages, that's all.
> there is no notion of segment, here : we're not copying the x86 ;-) >

In fact, segmented memory are a great improvement for protection. The
real time lab of the university where i work, try to implement an mmu
design to keep the encapsulation of the object (data protection between
objects). And they think to use data segment to separate object. The
idea to have linear adressing in each segment aren't a so bad !

nicO

>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 24 00:29:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05923 for ; Mon, 26 Mar 2001 01:10:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:08 +0200 (MEST) Received: (qmail 26342 invoked by uid 0); 23 Mar 2001 23:23:19 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx07) with SMTP; 23 Mar 2001 23:23:19 -0000 X-eGroups-Return: sentto-1101623-2558-985389795-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 23 Mar 2001 23:23:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 23 Mar 2001 23:23:14 -0000 Received: (qmail 60356 invoked from network); 23 Mar 2001 23:23:14 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 23 Mar 2001 23:23:14 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 23 Mar 2001 23:23:13 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29654; Sat, 24 Mar 2001 00:23:08 +0100 (MET) Message-ID: <3ABBDC6F.1B74BA95@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm Cc: Roger Dingledine From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 00:29:51 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

Roger has opened the mailing list "f-cpu at seul dot org".
he needs the confirmation from the three volunteers
that they accept to manage the list. By default, Roger
has set myself as maintainer but i'll be removed when the
others will take their function.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 24 00:29:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05926 for ; Mon, 26 Mar 2001 01:10:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:09 +0200 (MEST) Received: (qmail 21433 invoked by uid 0); 23 Mar 2001 23:23:23 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx19) with SMTP; 23 Mar 2001 23:23:23 -0000 X-eGroups-Return: sentto-1101623-2559-985389801-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 23 Mar 2001 23:23:21 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 23 Mar 2001 23:23:19 -0000 Received: (qmail 54930 invoked from network); 23 Mar 2001 23:23:18 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 Mar 2001 23:23:18 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 23 Mar 2001 23:23:17 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA27011 for ; Sat, 24 Mar 2001 00:23:13 +0100 (MET) Message-ID: <3ABBDC74.D5CD9C55@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 00:29:56 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kim Enkovaara wrote:
> On Thu, 22 Mar 2001, Nicolas wrote:
> > I hope you could send me a correct file to retry very soon!
> If someone needs quick synthesis runs with Synplify Pro or Lenorado 2000 I
> can do them if you send me the files. I have also access to DC Ultra, but
> my favorite hobby is not Synopsys synthesis scripts :)
let's hope that the CVS problem will be solved soon.

> Has anyone tought how f-cpu synthesis will be done in the future.
before synthesis, we need sources files ....

> As far as I know there are no good free synthesizers available.
that's sad, but we can't have everything for free, at least currently.

> And after synthesis we need test structures, test vectors etc.
that is another problem. I hope that the contributors feel concerned
about it.

> Possibly ECO
> compiler for the small changes during layout etc. And then the actual
> layout unless the vendor does that. I don't know free tools for this flow,
> Alliance can do something but it is very restricted in every aspect. Also
> the ASIC libraries are distributer under strict NDAs etc.
i think that some libs are not under NDA, but that is not critical at my
level at the moment. synthesis seems to be unnecessary now, even though
we need to have some hints about what to do and what to avoid.
For example, do we have to write code that is to be compiled/simulated
or should it be for synthesis ? Simulation and validation of the CPU model
is more critical now.

> And how about top level and block level verification etc. Top level
> verification of CPU is not a trivial task. For example Sun uses about 1000
> servers in their simulation cluster to simulate CPUs. Also the creation of
> test streams (directed and random) and checking them with behavioral
> models needs quite big amount of work. It is not enough to write the RTL.
yep.
However, i have the chance to work in a company that makes the "supercomputers"
of verification engines :-) i need the RTL files and i can run the
verification at a few MHz ... on million gates designs :-)

> =============================================================================
> Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
> Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
> 02630 Espoo         |                      | write-only file system

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Sat Mar 24 00:58:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05929 for ; Mon, 26 Mar 2001 01:10:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:10 +0200 (MEST) Received: (qmail 11862 invoked by uid 0); 24 Mar 2001 00:00:37 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx21) with SMTP; 24 Mar 2001 00:00:37 -0000 X-eGroups-Return: sentto-1101623-2560-985392035-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 24 Mar 2001 00:00:35 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 00:00:34 -0000 Received: (qmail 45871 invoked from network); 24 Mar 2001 00:00:34 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 24 Mar 2001 00:00:34 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta2 with SMTP; 24 Mar 2001 00:00:33 -0000 Received: from violin.ocn.ne.jp (p0444-ip04osakakita.osaka.ocn.ne.jp [211.123.241.190]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id JAA07813 for ; Sat, 24 Mar 2001 09:00:30 +0900 (JST) Sender: root@violin.ocn.ne.jp Message-ID: <3ABBE326.56F4ED64@violin.ocn.ne.jp> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 08:58:30 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:

> hi !
>
> Kim Enkovaara wrote:
> > On Thu, 22 Mar 2001, Nicolas wrote:
> > > I hope you could send me a correct file to retry very soon!
> > If someone needs quick synthesis runs with Synplify Pro or Lenorado 2000 I
> > can do them if you send me the files. I have also access to DC Ultra, but
> > my favorite hobby is not Synopsys synthesis scripts :)
> let's hope that the CVS problem will be solved soon.
>
> > Has anyone tought how f-cpu synthesis will be done in the future.
> before synthesis, we need sources files ....
>
> > As far as I know there are no good free synthesizers available.
> that's sad, but we can't have everything for free, at least currently.
>
> > And after synthesis we need test structures, test vectors etc.
> that is another problem. I hope that the contributors feel concerned
> about it.
>
> > Possibly ECO
> > compiler for the small changes during layout etc. And then the actual
> > layout unless the vendor does that. I don't know free tools for this flow,
> > Alliance can do something but it is very restricted in every aspect. Also
> > the ASIC libraries are distributer under strict NDAs etc.
> i think that some libs are not under NDA, but that is not critical at my
> level at the moment. synthesis seems to be unnecessary now, even though
> we need to have some hints about what to do and what to avoid.
> For example, do we have to write code that is to be compiled/simulated
> or should it be for synthesis ? Simulation and validation of the CPU model
> is more critical now.
>
> > And how about top level and block level verification etc. Top level
> > verification of CPU is not a trivial task. For example Sun uses about 1000
> > servers in their simulation cluster to simulate CPUs. Also the creation of
> > test streams (directed and random) and checking them with behavioral
> > models needs quite big amount of work. It is not enough to write the RTL.
> yep.
> However, i have the chance to work in a company that makes the "supercomputers"
> of verification engines :-) i need the RTL files and i can run the
> verification at a few MHz ... on million gates designs :-)
>
> > =============================================================================
> > Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
> > Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
> > 02630 Espoo         |                      | write-only file system
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Actually, yes! I was wondering, who was gonna tell who, to F-cpu. Truth is...if
you got it you just might want it too. I'm sure there isn't much of a secret to
which methodology is free. I was actually interested in a reasonable product.
Perhaps someone might explain that to someone. Anyway, how's the project
coming?!!! anyway,

Chris
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Thu Mar 22 22:06:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05932 for ; Mon, 26 Mar 2001 01:10:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:11 +0200 (MEST) Received: (qmail 25207 invoked by uid 0); 24 Mar 2001 00:37:44 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx11) with SMTP; 24 Mar 2001 00:37:44 -0000 X-eGroups-Return: sentto-1101623-2561-985394263-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 24 Mar 2001 00:37:43 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 00:37:42 -0000 Received: (qmail 11923 invoked from network); 24 Mar 2001 00:37:42 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 24 Mar 2001 00:37:42 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 24 Mar 2001 00:37:39 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA13165 for ; Fri, 23 Mar 2001 17:37:35 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ABA694A.F02FAEB7@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 14:06:18 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:
> > And how about top level and block level verification etc. Top level
> > verification of CPU is not a trivial task. For example Sun uses about 1000
> > servers in their simulation cluster to simulate CPUs. Also the creation of
> > test streams (directed and random) and checking them with behavioral
> > models needs quite big amount of work. It is not enough to write the RTL.
> yep.
> However, i have the chance to work in a company that makes the "supercomputers"
> of verification engines :-) i need the RTL files and i can run the
> verification at a few MHz ... on million gates designs :-)

Confused. Why this over computing. Since the initial design could be a FPGA
design, come up with a limited CPU design for initial testing like no floating
point and/or virtual memory and do minimal software testing. Then burn a FPGA
and test on a real system.Then slowly add features.

Also why is several models needed , one design
for both testing and layout must be used other wise you could have too many
problems with version control.

Also how about a auto-boot on reset, where you load from a serial device
on bootup into main memory. You could even have the uart on board the FPGA.
Ben/
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Fri Mar 23 11:47:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05935 for ; Mon, 26 Mar 2001 01:10:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:14 +0200 (MEST) Received: (qmail 27602 invoked by uid 0); 24 Mar 2001 00:49:47 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx05) with SMTP; 24 Mar 2001 00:49:47 -0000 X-eGroups-Return: sentto-1101623-2562-985394977-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 24 Mar 2001 00:49:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 00:49:37 -0000 Received: (qmail 35265 invoked from network); 24 Mar 2001 00:49:36 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 24 Mar 2001 00:49:36 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.68) by mta2 with SMTP; 24 Mar 2001 00:49:28 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00498; Fri, 23 Mar 2001 11:47:53 +0100 Message-ID: <20010323114753.26114@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AB91E74.455897CD@seul.org> <20010322011444.30361@thrai.stud.uni-hannover.de> <3ABA628E.468CFF99@seul.org> X-Mailer: Mutt 0.84e In-Reply-To: <3ABA628E.468CFF99@seul.org>; from Nicolas on Thu, Mar 22, 2001 at 09:37:34PM +0100 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 11:47:53 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi *,

On Thu, Mar 22, 2001 at 09:37:34PM +0100, Nicolas wrote:
[...]
> > > /home/profelec/nboulay/fcpu/eu_imu/reduce_tree.vhdl:
> > > Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
> > > line 25  (VHDL-2023)
> > > Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
> > > line 26  (VHDL-2023)
> > > Warning: Type of the generic is assumed to be 'Integer' in synthesis  on
> > > line 27  (VHDL-2023)
> >
> > Last time I looked, `natural' was a subtype of `integer'.  So what?
> >
>
> Natural and Positive are suppose to be integer.

I guess that warning means that the synthesizer ignores the range
constraints of natural/positive, right?  Otherwise it wouldn't make
sense to print a warning message at all.  Anyway -- I'll not re-type my
`natural' generics to `integer' just to make a stubborn tool happy (and
it's only a warning anyway -- we'll have to live with these messages).

[...]
> > No boolean generics?  Now what does THAT mean?  Do I have to convert
> > them to integer and use 0/1 to switch them on and off?  That sucks.
> >
>
> Boolean are very strange in VHDL...
> Never forget that front end of vhdl compiler aren't so cool. Remenber
> that i always insit to use VHDL 87 and 93, you understand why...

*sigh*  That's like a C compiler that doesn't understand `void' :(

I'll "correct" the code and re-release it ASAP (that is, when the CeBIT
fair is over, in a week or something like that).

CU,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 24 02:01:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05938 for ; Mon, 26 Mar 2001 01:10:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:15 +0200 (MEST) Received: (qmail 15819 invoked by uid 0); 24 Mar 2001 00:55:07 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx09) with SMTP; 24 Mar 2001 00:55:07 -0000 X-eGroups-Return: sentto-1101623-2563-985395304-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 24 Mar 2001 00:55:05 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 00:55:04 -0000 Received: (qmail 52256 invoked from network); 24 Mar 2001 00:55:04 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 24 Mar 2001 00:55:04 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 24 Mar 2001 00:55:03 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA20977 for ; Sat, 24 Mar 2001 01:54:59 +0100 (MET) Message-ID: <3ABBF1F5.71A0F584@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> <3ABA694A.F02FAEB7@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 02:01:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann Guidon wrote:
> > However, i have the chance to work in a company that makes the "supercomputers"
> > of verification engines :-) i need the RTL files and i can run the
> > verification at a few MHz ... on million gates designs :-)
>
> Confused. Why this over computing.
ask our company's customers ;-) the biggest CPU and video companies'
chips require so many verfication that the race (for more gates) has only started...
but if we can do more, we can do less ;-)

> Since the initial design could be a FPGA
> design, come up with a limited CPU design for initial testing like no floating
> point and/or virtual memory and do minimal software testing. Then burn a FPGA
> and test on a real system.Then slowly add features.
that's certainly how it is going to be done. However, access to a big emulator
avoids the need of a FPGA.

> Also why is several models needed , one design
> for both testing and layout must be used other wise you could have too many
> problems with version control.
that is going to be an important problem, as important as this of
the several developpers having different styles. a lot of work awaits us ...

> Also how about a auto-boot on reset, where you load from a serial device
> on bootup into main memory. You could even have the uart on board the FPGA.
this is certainly going to be implemented in production designs, whether using
serial or parallel PROM.

> Ben/
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 24 02:06:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05941 for ; Mon, 26 Mar 2001 01:10:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:16 +0200 (MEST) Received: (qmail 29160 invoked by uid 0); 24 Mar 2001 01:00:06 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx23) with SMTP; 24 Mar 2001 01:00:06 -0000 X-eGroups-Return: sentto-1101623-2564-985395604-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 24 Mar 2001 01:00:05 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 01:00:02 -0000 Received: (qmail 55005 invoked from network); 24 Mar 2001 01:00:02 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 24 Mar 2001 01:00:02 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta1 with SMTP; 24 Mar 2001 01:00:01 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA23741 for ; Sat, 24 Mar 2001 01:59:57 +0100 (MET) Message-ID: <3ABBF320.1BFEC5C4@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> <3ABBE326.56F4ED64@violin.ocn.ne.jp> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 02:06:40 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

"C.M. Herkert" wrote:
> Yann Guidon wrote:
> Actually, yes! I was wondering, who was gonna tell who, to F-cpu. Truth is...if
> you got it you just might want it too. I'm sure there isn't much of a secret to
> which methodology is free. I was actually interested in a reasonable product.
> Perhaps someone might explain that to someone. Anyway, how's the project
> coming?!!! anyway,

i'm not sure about what you are speaking about in the first part of your message.
As for how the f-cpu is going, it's rather well :-) but i doubt it is any
"reasonable project" ;-) whether it will success, i'm convinced. how ? when ?
that's the real question but i don't care anymore :-) we all have to do
our work everyday to advance things. there's no secret :-)

have fun,

> Chris
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Thu Mar 22 22:32:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05944 for ; Mon, 26 Mar 2001 01:10:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:17 +0200 (MEST) Received: (qmail 21464 invoked by uid 0); 24 Mar 2001 01:04:14 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx19) with SMTP; 24 Mar 2001 01:04:14 -0000 X-eGroups-Return: sentto-1101623-2565-985395852-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 24 Mar 2001 01:04:12 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 01:04:11 -0000 Received: (qmail 70425 invoked from network); 24 Mar 2001 01:04:11 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 24 Mar 2001 01:04:11 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 24 Mar 2001 02:05:15 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA14637 for ; Fri, 23 Mar 2001 18:04:08 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ABA6F82.8ED07C35@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> <3ABA694A.F02FAEB7@jetnet.ab.ca> <3ABBF1F5.71A0F584@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 22 Mar 2001 14:32:50 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:
> Ben Franchuk wrote:
> > Confused. Why this over computing.
> ask our company's customers ;-) the biggest CPU and video companies'
> chips require so many verfication that the race (for more gates) has only started...
> but if we can do more, we can do less ;-)
I have no problem with that if it gate layout for a new chip, you don't want
the latest and fastest chip to have any flaws.
It just that I see with the F-Cpu we have a chance to do incremental
development and fix the bugs slowly rather than put it all together
and hope it works.
>
Ben.
BTW will you hint that the next time your company upgrades to buy F-cpu's.:-)
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Mar 24 02:22:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05947 for ; Mon, 26 Mar 2001 01:10:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:17 +0200 (MEST) Received: (qmail 20501 invoked by uid 0); 24 Mar 2001 01:15:56 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx08) with SMTP; 24 Mar 2001 01:15:56 -0000 X-eGroups-Return: sentto-1101623-2566-985396554-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mk.egroups.com with NNFMP; 24 Mar 2001 01:15:55 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 01:15:53 -0000 Received: (qmail 99913 invoked from network); 24 Mar 2001 01:15:50 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 24 Mar 2001 01:15:50 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta2 with SMTP; 24 Mar 2001 01:15:50 -0000 Received: from f-cpu.org (nas3-1.ras.club-internet.fr [195.36.203.1]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA16385 for ; Sat, 24 Mar 2001 02:15:46 +0100 (MET) Message-ID: <3ABBF6CB.90697110@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABBDC74.D5CD9C55@f-cpu.org> <3ABA694A.F02FAEB7@jetnet.ab.ca> <3ABBF1F5.71A0F584@f-cpu.org> <3ABA6F82.8ED07C35@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 02:22:19 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann Guidon wrote:
> > Ben Franchuk wrote:
> > > Confused. Why this over computing.
> > ask our company's customers ;-) the biggest CPU and video companies'
> > chips require so many verfication that the race (for more gates) has only started...
> > but if we can do more, we can do less ;-)
> I have no problem with that if it gate layout for a new chip, you don't want
> the latest and fastest chip to have any flaws.
> It just that I see with the F-Cpu we have a chance to do incremental
> development and fix the bugs slowly rather than put it all together
> and hope it works.
that is one of the many reasons i try to promote this project :-)

> Ben.
> BTW will you hint that the next time your company upgrades to buy F-cpu's.:-)
i have already made my little rant/lobbying in the corridors ...
but they don't seem to move... too bad for them.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Sat Mar 24 03:37:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05950 for ; Mon, 26 Mar 2001 01:10:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:19 +0200 (MEST) Received: (qmail 10907 invoked by uid 0); 24 Mar 2001 02:44:13 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx21) with SMTP; 24 Mar 2001 02:44:13 -0000 X-eGroups-Return: sentto-1101623-2567-985401441-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 24 Mar 2001 02:37:21 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 02:37:20 -0000 Received: (qmail 51130 invoked from network); 24 Mar 2001 02:37:20 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 24 Mar 2001 02:37:20 -0000 Received: from unknown (HELO postfix2-2.free.fr) (213.228.0.140) by mta3 with SMTP; 24 Mar 2001 03:38:24 -0000 Received: from free.fr (unknown [213.228.56.103]) by postfix2-2.free.fr (Postfix) with ESMTP id B3CA76B65B for ; Sat, 24 Mar 2001 03:37:17 +0100 (CET) Message-ID: <3ABC0872.5000303@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3ABBDC6F.1B74BA95@f-cpu.org> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 03:37:38 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

Yann Guidon wrote:

> hello,
>
> Roger has opened the mailing list "f-cpu at seul dot org".
> he needs the confirmation from the three volunteers
> that they accept to manage the list.
One time again if you explain me what to do and how, I will be volunteer!

By default, Roger
> has set myself as maintainer but i'll be removed when the
> others will take their function.
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Sat Mar 24 08:30:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05956 for ; Mon, 26 Mar 2001 01:10:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:20 +0200 (MEST) Received: (qmail 4233 invoked by uid 0); 24 Mar 2001 07:30:27 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx04) with SMTP; 24 Mar 2001 07:30:27 -0000 X-eGroups-Return: sentto-1101623-2568-985419026-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mo.egroups.com with NNFMP; 24 Mar 2001 07:30:26 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 07:30:25 -0000 Received: (qmail 21070 invoked from network); 24 Mar 2001 07:30:23 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 24 Mar 2001 07:30:23 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 24 Mar 2001 07:30:23 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA24792 for ; Sat, 24 Mar 2001 09:30:22 +0200 (EET) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3ABA694A.F02FAEB7@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 09:30:21 +0200 (EET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 22 Mar 2001, Ben Franchuk wrote:

> Confused. Why this over computing. Since the initial design could be a FPGA
> design, come up with a limited CPU design for initial testing like no floating
> point and/or virtual memory and do minimal software testing. Then burn a FPGA
> and test on a real system.Then slowly add features.

That sounds good, but is not wise thing to do at the beginning. It is
extremely difficult to debug the chip problems when it is in the FPGA.
There are tools to embed simple logic analyzers inside the chip, but they
have quite small memories and are limited. In RTL simulations there is
visibility to all signals during the simulation and the problem is much
easier to debug. Also breakpoints inside the code work etc.

Think for example that you see a problem in the FPGA, how do you find what
went wrong in the chip? You might have to recreate the situation with RTL
simulator and you spent double the time to find the problem.

I think FPGA verification is beneficial when the chip is debugged and
works with RTL simulations perfectly. FPGA models can be then used for
additional burn-in testing to be more certain that there are no bugs.

Even block level testing is really needed. It is very difficult to verify
individual blocks from toplevel testbench. And even more difficult to do
that when you see only the external signals of the chip.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Sat Mar 24 08:36:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05959 for ; Mon, 26 Mar 2001 01:10:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:21 +0200 (MEST) Received: (qmail 25341 invoked by uid 0); 24 Mar 2001 07:36:23 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx24) with SMTP; 24 Mar 2001 07:36:23 -0000 X-eGroups-Return: sentto-1101623-2569-985419382-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 24 Mar 2001 07:36:22 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 24 Mar 2001 07:36:21 -0000 Received: (qmail 40388 invoked from network); 24 Mar 2001 07:36:21 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 24 Mar 2001 07:36:21 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 24 Mar 2001 07:36:20 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA03673 for ; Sat, 24 Mar 2001 09:36:19 +0200 (EET) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3ABBF1F5.71A0F584@f-cpu.org> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 09:36:17 +0200 (EET) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > > Also why is several models needed , one design
> > for both testing and layout must be used other wise you could have too many
> > problems with version control.
> that is going to be an important problem, as important as this of
> the several developpers having different styles. a lot of work awaits us ...

I think this is an important point. It frustrating to debug a design where
each block has little different coding style. For example usage and naming
of delayed signals in pipelines should be consistent. I was in one project
where we had 270 phase pipeline and there were many coders doing that with
different styles. The code was quite a mess, it took quite a while to
understand how each coder named delayed signals etc. And if each coder has
own style of making state machines etc. the mess is ready :)

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Mar 25 03:22:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06040 for ; Mon, 26 Mar 2001 01:10:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:40 +0200 (MEST) Received: (qmail 28877 invoked by uid 0); 25 Mar 2001 01:15:29 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx12) with SMTP; 25 Mar 2001 01:15:29 -0000 X-eGroups-Return: sentto-1101623-2574-985482927-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 25 Mar 2001 01:15:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 01:15:27 -0000 Received: (qmail 58910 invoked from network); 25 Mar 2001 01:15:27 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 25 Mar 2001 01:15:27 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 25 Mar 2001 02:16:30 -0000 Received: from f-cpu.org (nas1-172.ras.club-internet.fr [195.36.192.172]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA26434 for ; Sun, 25 Mar 2001 03:15:23 +0200 (MET DST) Message-ID: <3ABD4840.B9AF1341@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Mar 2001 03:22:08 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] who's who Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi,

on a lighter note,
i have got the pictures taken at 17C3.
i'll try to scan them and make a nice page
with other pictures that people want to have
displayed on the f-cpu web. if i ever get that
smartasspad running a bash...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "philippe.trbich" Sun Mar 25 06:22:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06043 for ; Mon, 26 Mar 2001 01:10:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:41 +0200 (MEST) Received: (qmail 9494 invoked by uid 0); 25 Mar 2001 04:21:45 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx11) with SMTP; 25 Mar 2001 04:21:45 -0000 X-eGroups-Return: sentto-1101623-2575-985494104-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 25 Mar 2001 04:21:44 -0000 X-Sender: philippe.trbich@free.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 04:21:43 -0000 Received: (qmail 61216 invoked from network); 25 Mar 2001 04:21:42 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 25 Mar 2001 04:21:42 -0000 Received: from unknown (HELO postfix2-1.free.fr) (213.228.0.9) by mta1 with SMTP; 25 Mar 2001 04:21:42 -0000 Received: from free.fr (nas-cbv-1-7-94.dial.proxad.net [213.228.7.94]) by postfix2-1.free.fr (Postfix) with ESMTP id A6DA7C0E4 for ; Sun, 25 Mar 2001 06:21:40 +0200 (CEST) Message-ID: <3ABD7268.20402@free.fr> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; fr-FR; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: fr To: f-cpu@yahoogroups.com References: <3ABD4833.A792C2B7@f-cpu.org> From: "philippe.trbich" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Mar 2001 06:22:00 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] linux on thinkpad/WinMe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N

Yann Guidon wrote:

> hi !
>
> i think i made something silly today.
> I found a thinkpad with Celeron 550 for an acceptable price.
> it runs with the newest OS from M$ quite fast. It lacks
> some accessories such as spare batteries and diskette
> drive, but it's not critical.
>
> However, i can't boot with the SuSE 6.3 CD.
> Usually, i bypass that with a nice MSDOS shell
> in native mode, then i run loadlin. Now, how the
> hell do i get into native mode ? WinMe impresses
> me with its ability to stick to the HDD and i
> can't get a "clean" shell access. On top of that,
> the integrated modem is a "soft modem" so i won't
> be able to use it with Linux.
>
> i'm sure one of you must know a solution. i have no
> diskette drive (not before 1 week, and it's a USB one)
> so i can't boot with my old good clean dos diskettes.
> what file must i tweak if i want to remove winsuck
> from the HDD ?
je vais peut =EAtre dire une connerie mais si tu veux installer une Suse 6.3, il me semble que le premier CD est bootable : dans le setup, tu
peux rendre le cdrom bootable. Et hop!
A+

>
> I hope to have it solved ASAP so i can start to clean
> the files for the f-cpu project.
> thanks for the hints,
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kgoldbloom@yahoo.com Sun Mar 25 06:51:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06049 for ; Mon, 26 Mar 2001 01:10:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:42 +0200 (MEST) Received: (qmail 25541 invoked by uid 0); 25 Mar 2001 05:33:16 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx14) with SMTP; 25 Mar 2001 05:33:16 -0000 X-eGroups-Return: sentto-1101623-2576-985498394-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mv.egroups.com with NNFMP; 25 Mar 2001 05:33:14 -0000 X-Sender: bceshadow@altavista.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 05:33:14 -0000 Received: (qmail 77936 invoked from network); 25 Mar 2001 05:33:13 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 25 Mar 2001 05:33:13 -0000 Received: from unknown (HELO ytm.com.tr) (212.98.253.75) by mta3 with SMTP; 25 Mar 2001 06:34:16 -0000 Received: from 216.3.181.53 (01-053.031.popsite.net [216.3.181.53]) by ytm.com.tr (8.9.3/8.8.7) with SMTP id HAA04859; Sun, 25 Mar 2001 07:34:40 +0300 Message-ID: <0000482b2c9d$00002761$00000f9b@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: bceshadow@altavista.net From: kgoldbloom@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 20:51:03 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Become Wealthy! Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 8bit Status: R X-Status: N THE NEXT INTERNATIONAL GIANT!! Did you know that THOUSANDS of people are becoming MILLIONAIRES every week with internet-based businesses? Did you know there are 76 MILLION Baby Boomers in the U.S. today - RECORD HIGH! These people are shifting from conventional health care to a natural alternative because their physical and emotional needs are not simply not being fulfilled. Marketing 101 says, "find a large group of people with a large need…fulfill that need… become wealthy!" We sure have the need, and now we are the ONLY ones Who offering products GUARANTEED to make you biologically younger and we have in-home tests to PROVE IT! BOTTOM LINE - These 76 MILLION Baby Boomers Are Looking For ANSWERS AND WE HAVE THEM! This is your OPPORTUNITY to CAPITALIZE on this Phenomenal MEGA-TREND! Tfind out more, click reply with your Name and Phone Number, you will be contacted shortly! To be removed from future mailings please reply with "REMOVE" in the subject. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From kgoldbloom@yahoo.com Sun Mar 25 07:56:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06052 for ; Mon, 26 Mar 2001 01:10:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:43 +0200 (MEST) Received: (qmail 4822 invoked by uid 0); 25 Mar 2001 06:08:37 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx13) with SMTP; 25 Mar 2001 06:08:37 -0000 X-eGroups-Return: sentto-1101623-2577-985500515-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 25 Mar 2001 06:08:35 -0000 X-Sender: b_duong@altavista.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 06:08:34 -0000 Received: (qmail 41412 invoked from network); 25 Mar 2001 06:08:34 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 25 Mar 2001 06:08:34 -0000 Received: from unknown (HELO npa.gov.tw) (210.69.154.130) by mta1 with SMTP; 25 Mar 2001 06:08:33 -0000 Received: from npant3.interscan (interscan [172.16.1.3]) by npa.gov.tw (8.9.3/8.9.3-NPA-'99.03.10) with SMTP id NAA01456; Sun, 25 Mar 2001 13:55:11 +0800 (CST) Received: from 216.3.181.99 by npant3.interscan (InterScan E-Mail VirusWall NT); Sun, 25 Mar 2001 13:57:30 +0800 Message-ID: <00004b98064a$00002a01$000041ee@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: b_duong@altavista.net From: kgoldbloom@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 24 Mar 2001 21:56:47 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Become Wealthy! Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 8bit Status: R X-Status: N THE NEXT INTERNATIONAL GIANT!! Did you know that THOUSANDS of people are becoming MILLIONAIRES every week with internet-based businesses? Did you know there are 76 MILLION Baby Boomers in the U.S. today - RECORD HIGH! These people are shifting from conventional health care to a natural alternative because their physical and emotional needs are not simply not being fulfilled. Marketing 101 says, "find a large group of people with a large need…fulfill that need… become wealthy!" We sure have the need, and now we are the ONLY ones Who offering products GUARANTEED to make you biologically younger and we have in-home tests to PROVE IT! BOTTOM LINE - These 76 MILLION Baby Boomers Are Looking For ANSWERS AND WE HAVE THEM! This is your OPPORTUNITY to CAPITALIZE on this Phenomenal MEGA-TREND! Tfind out more, click reply with your Name and Phone Number, you will be contacted shortly! To be removed from future mailings please reply with "REMOVE" in the subject. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From boucli27@altavista.net Sun Mar 25 15:08:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06070 for ; Mon, 26 Mar 2001 01:10:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:53 +0200 (MEST) Received: (qmail 9475 invoked by uid 0); 25 Mar 2001 13:08:23 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx15) with SMTP; 25 Mar 2001 13:08:23 -0000 X-eGroups-Return: sentto-1101623-2578-985525701-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 25 Mar 2001 13:08:22 -0000 X-Sender: boucli27@altavista.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 13:08:20 -0000 Received: (qmail 31171 invoked from network); 25 Mar 2001 13:08:19 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 25 Mar 2001 13:08:19 -0000 Received: from unknown (HELO rmx441-mta.mail.com) (165.251.48.44) by mta1 with SMTP; 25 Mar 2001 13:08:19 -0000 Received: from weba8.iname.net (weba8.iname.net [165.251.4.18]) by rmx441-mta.mail.com (8.9.3/8.9.3) with ESMTP id IAA19853 for ; Sun, 25 Mar 2001 08:08:18 -0500 (EST) Received: (from root@localhost) by weba8.iname.net (8.9.1a/8.9.2.Alpha2) id IAA25451; Sun, 25 Mar 2001 08:08:18 -0500 (EST) Message-Id: <010325080803LA.20857@weba8.iname.net> To: f-cpu@yahoogroups.com From: boucli27@altavista.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 25 Mar 2001 08:08:03 -0500 (EST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] linux on thinkpad/WinMe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N According to the CPU clock it does not seems to be
an IBM's designed thinkpad but rather an Acer one.

First : the CDROM should be bootable, perhaps
you should declare it in the BIOS's bootsequence.

Second: If this helps you can remove the HDD, purchase
a 2"1/2 --> 3"1/2 converter and plug it to a desktop
computer in order to install Linux ( beware don't
install a Linux distribution that autodetects your hardware at instalation time )

Third: as it seems you have permanent Internet acces,
why don't you run Debian GNU/Linux on it ?

For more informations you may read the :
http://www.linuxdoc.org/HOWTO/Laptop-HOWTO.html

A+
Lionel

#########################################

Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
boucli27@altavista.net
http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html
http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html
06 68 99 65 89
----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Fri Mar 23 23:16:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06091 for ; Mon, 26 Mar 2001 01:10:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:10:58 +0200 (MEST) Received: (qmail 25912 invoked by uid 0); 25 Mar 2001 20:22:56 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx05) with SMTP; 25 Mar 2001 20:22:55 -0000 X-eGroups-Return: sentto-1101623-2580-985551769-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 25 Mar 2001 20:22:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 20:22:49 -0000 Received: (qmail 48973 invoked from network); 25 Mar 2001 20:22:48 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 25 Mar 2001 20:22:48 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 25 Mar 2001 21:23:51 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA07749 for ; Sun, 25 Mar 2001 13:22:42 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ABBCB41.9D5B1C06@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ABE50BB.4B17BA3B@club-internet.fr> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 23 Mar 2001 15:16:33 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] little computer troubles... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N whygee@club-internet.fr wrote:
>
> hi,
> i finally managed to smash winme out of my smartasspad
> with the help of my sister's computer, which has a diskette
> driver : i just plugged the HDD in it and installed the base.
> however it didn't support the travel back, linux didn't
> adapt the HW configuration properly, it blocks at INIT=2.
> i have partitionned the HDD and installed a basic MSDOS
> so i can still do stuffs, but almost nothing however.
>
> on top of that, my main computer ... hangs. The power supply
> is out of order and halts in the middle of anything, i'll
> have to find a new box probably. call that unluck. fortunately,
> i didn't destroy my sister's computer, which i use now to type
> this mail.
>
> wish me luck and wisdom,
> whygee who damns all PCs in the known universe.
if you have a good modem connection to the 'CussPad' (because you cuss
the smartpad) try downloading DEBIAN linux to it. Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@club-internet.fr Mon Mar 26 00:05:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA06103 for ; Mon, 26 Mar 2001 01:11:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 26 Mar 2001 01:11:02 +0200 (MEST) Received: (qmail 6452 invoked by uid 0); 25 Mar 2001 22:10:53 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx23) with SMTP; 25 Mar 2001 22:10:53 -0000 X-eGroups-Return: sentto-1101623-2581-985558213-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fl.egroups.com with NNFMP; 25 Mar 2001 22:10:15 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 25 Mar 2001 22:10:12 -0000 Received: (qmail 54970 invoked from network); 25 Mar 2001 22:10:11 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 25 Mar 2001 22:10:11 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 25 Mar 2001 22:10:11 -0000 Received: from club-internet.fr (nas4-102.ras.club-internet.fr [195.36.203.102]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA02222 for ; Mon, 26 Mar 2001 00:10:07 +0200 (MET DST) Message-ID: <3ABE6B9A.B8088D84@club-internet.fr> X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <3ABD4833.A792C2B7@f-cpu.org> <3ABD7268.20402@free.fr> From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Mar 2001 00:05:14 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] linux on thinkpad/WinMe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi!

i'm REALLY sorry to bring these off-topic mails on the list.
i gathered the messages in one single mail to reduce
the inconvenience.

"philippe.trbich" wrote:
> Yann Guidon wrote:
> > hi !
<...>
> > i'm sure one of you must know a solution. i have no
> > diskette drive (not before 1 week, and it's a USB one)
> > so i can't boot with my old good clean dos diskettes.
> > what file must i tweak if i want to remove winsuck
> > from the HDD ?
> je vais peut =EAtre dire une connerie mais si tu veux installer une Su= se
> 6.3, il me semble que le premier CD est bootable : dans le setup, tu > peux rendre le cdrom bootable. Et hop!
> A+
et paff !
the CD #1 should be bootable : i used it on another laptop
and it worked fine. but on this one, it writes "boot failed".
but the CD is in good condition and the laptop is rather recent.
what went wrong ? retour case d=E9part ...


boucli27@altavista.net wrote:
> According to the CPU clock it does not seems to be
> an IBM's designed thinkpad but rather an Acer one.
?
it's 550 MHz celeron and i didn't remark any ACER mark.
but what would be the difference ?

> First : the CDROM should be bootable, perhaps
> you should declare it in the BIOS's bootsequence.
no problem at that stage, except the "boot failed" message/hang.<= BR> it probably fails to find a suitable track on the CD.

> Second: If this helps you can remove the HDD, purchase
> a 2"1/2 --> 3"1/2 converter and plug it to a desktop
> computer in order to install Linux
good idea, however i need to also buy a good power supply unit
because my other computer is in deep shit too...
maybe i should simply buy a new ATX box with a redundant PSU ? :-/

> ( beware don't  install a Linux distribution that
> autodetects your hardware at instalation time )
now, Linux boots but fails at INIT=3D2, segfaults i can't explain.
it tries to install the modules (PCMCIA, daeomons etc...)
and no one runs. maybe i messed badly with the different partitions ?
i have one separate 50M space for /boot.

> Third: as it seems you have permanent Internet acces,
> why don't you run Debian GNU/Linux on it ?
i have no "permanent" access in the usual sense of the term,
at work i'm on a TX with no interface. it is also usually
forbidden to move files on mass storages, for legal and
security reasons.
OTOH if you have a fresh debian distro that supports the rpm
format (i have already installed the packages) maybe we could
meet in Orsay or les Ulis ?

> For more informations you may read the :
> http://www= .linuxdoc.org/HOWTO/Laptop-HOWTO.html
i'll try.


> A+
> Lionel
YG
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Mon Mar 26 18:58:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00341 for ; Sat, 31 Mar 2001 12:01:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:01:52 +0200 (MEST) Received: (qmail 6249 invoked by uid 0); 26 Mar 2001 22:39:21 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx02) with SMTP; 26 Mar 2001 22:39:21 -0000 X-eGroups-Return: sentto-1101623-2583-985646357-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 26 Mar 2001 22:39:18 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 26 Mar 2001 22:39:16 -0000 Received: (qmail 56384 invoked from network); 26 Mar 2001 22:39:16 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 26 Mar 2001 22:39:16 -0000 Received: from unknown (HELO mail.span.ch) (144.85.10.50) by mta1 with SMTP; 26 Mar 2001 22:39:15 -0000 Received: from athlon ([195.15.65.48]) by mail.span.ch (8.11.2/8.11.2) with SMTP id f2QMcoJ12062 for ; Tue, 27 Mar 2001 00:38:59 +0200 (MEST) Message-Id: <200103262238.f2QMcoJ12062@mail.span.ch> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <3ABBDC6F.1B74BA95@f-cpu.org> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Mar 2001 18:58:40 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >Roger has opened the mailing list "f-cpu at seul dot org".
>he needs the confirmation from the three volunteers
>that they accept to manage the list. By default, Roger
>has set myself as maintainer but i'll be removed when the
>others will take their function.

  No problem for me, I'll be one of the maintainers if you need
it !

      Guillaume



* * * * * * * * * * * * * *

God loves fools, otherwise
why would He have made so
many ?
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Mon Mar 26 19:03:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00344 for ; Sat, 31 Mar 2001 12:01:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:01:52 +0200 (MEST) Received: (qmail 16061 invoked by uid 0); 26 Mar 2001 22:39:44 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx12) with SMTP; 26 Mar 2001 22:39:44 -0000 X-eGroups-Return: sentto-1101623-2582-985646355-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 26 Mar 2001 22:39:16 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 26 Mar 2001 22:39:14 -0000 Received: (qmail 62515 invoked from network); 26 Mar 2001 22:39:13 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 26 Mar 2001 22:39:13 -0000 Received: from unknown (HELO mail.span.ch) (144.85.10.50) by mta3 with SMTP; 26 Mar 2001 23:40:17 -0000 Received: from athlon ([195.15.65.48]) by mail.span.ch (8.11.2/8.11.2) with SMTP id f2QMd8J12091 for ; Tue, 27 Mar 2001 00:39:08 +0200 (MEST) Message-Id: <200103262239.f2QMd8J12091@mail.span.ch> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 26 Mar 2001 19:03:56 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] CVS Access Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N   Just a question, I remember someone propose to take care of
the opening of a CVS tree on seul.org (do I remember right ?).
Where is it now ?  Do you need someone to take care of that ?
I'll be happy to help !


            Guillaume


Laws of computer programming
============================

1) any given program, when running,
   is obselete
2) any given program costs more and
   takes longer
3) if a program is useful, it will
   have to be changed
4) if a program is useless, it will
   have to be documented
5) any given program will expand
   to fill all available memory
6) the value of a program is proportional
   the weight of its output
7) program complexity grows until
   it exceeds the capability of
   the programmer who must maintain it
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Mar 27 02:03:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00350 for ; Sat, 31 Mar 2001 12:01:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:01:54 +0200 (MEST) Received: (qmail 20395 invoked by uid 0); 27 Mar 2001 00:05:04 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx16) with SMTP; 27 Mar 2001 00:05:04 -0000 X-eGroups-Return: sentto-1101623-2584-985651501-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 27 Mar 2001 00:05:02 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 00:05:00 -0000 Received: (qmail 64275 invoked from network); 27 Mar 2001 00:04:58 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 27 Mar 2001 00:04:58 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.88) by mta3 with SMTP; 27 Mar 2001 01:06:00 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02485; Tue, 27 Mar 2001 02:03:29 +0200 Message-ID: <20010327020329.27606@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200103262239.f2QMd8J12091@mail.span.ch> X-Mailer: Mutt 0.84e In-Reply-To: <200103262239.f2QMd8J12091@mail.span.ch>; from Guillaume Lederrey on Mon, Mar 26, 2001 at 07:03:56PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 02:03:29 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CVS Access Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Mar 26, 2001 at 07:03:56PM +0200, Guillaume Lederrey wrote:
>   Just a question, I remember someone propose to take care of
> the opening of a CVS tree on seul.org (do I remember right ?).

You do.  I've simply been too busy (and I'm still waiting for your CVS
passwords, guys! -- I only got 2 so far).

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 11:18:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00368 for ; Sat, 31 Mar 2001 12:02:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:03 +0200 (MEST) Received: (qmail 12053 invoked by uid 0); 27 Mar 2001 09:25:22 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx25) with SMTP; 27 Mar 2001 09:25:22 -0000 X-eGroups-Return: sentto-1101623-2585-985685119-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hn.egroups.com with NNFMP; 27 Mar 2001 09:25:20 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 09:25:18 -0000 Received: (qmail 20193 invoked from network); 27 Mar 2001 09:25:18 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 27 Mar 2001 09:25:18 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 27 Mar 2001 10:26:22 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA06250; Tue, 27 Mar 2001 01:25:15 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8X4L; Tue, 27 Mar 2001 10:30:58 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC05ACF.11B3676B@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103262239.f2QMd8J12091@mail.span.ch> <20010327020329.27606@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 11:18:07 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CVS Access Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:
> On Mon, Mar 26, 2001 at 07:03:56PM +0200, Guillaume Lederrey wrote:
> >   Just a question, I remember someone propose to take care of
> > the opening of a CVS tree on seul.org (do I remember right ?).
> You do.  I've simply been too busy (and I'm still waiting for your CVS
> passwords, guys! -- I only got 2 so far).
which means yours and mine... :-)
wow...

anyway, it's cool to see that you're still alive :-)

OT1: how is it at the CeBit ? i've read about a CCC award to Siemens ...
OT2: i finally found the way to boot the thinkpad cleanly. now, i have
to find a suitable X server and a way to export/import files.....
at least the CD drive works :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 11:35:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00371 for ; Sat, 31 Mar 2001 12:02:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:04 +0200 (MEST) Received: (qmail 24536 invoked by uid 0); 27 Mar 2001 09:43:07 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx05) with SMTP; 27 Mar 2001 09:43:07 -0000 X-eGroups-Return: sentto-1101623-2586-985686175-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 27 Mar 2001 09:42:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 09:42:54 -0000 Received: (qmail 39714 invoked from network); 27 Mar 2001 09:42:54 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 27 Mar 2001 09:42:54 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 27 Mar 2001 09:42:54 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA07420; Tue, 27 Mar 2001 01:42:51 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8XVT; Tue, 27 Mar 2001 10:48:34 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC05EEF.6031A6D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com Cc: "philippe.trbich" References: <200103262238.f2QMcoJ12062@mail.span.ch> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 11:35:43 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Guillaume Lederrey wrote:
> >Roger has opened the mailing list "f-cpu at seul dot org".
> >he needs the confirmation from the three volunteers
> >that they accept to manage the list. By default, Roger
> >has set myself as maintainer but i'll be removed when the
> >others will take their function.
>
>   No problem for me, I'll be one of the maintainers if you need it !
too late, you're registered ;-)

ok, here are some hints :
* the maintainers' email address is stored in a file at seul.org,
which is used to send the error or activity emails from the majordomo.
ie, when someone wants to post but is not subscribed, or when someone
subscribed or unsubs from the list. that's the "passive" part.
* you have a password that you use to confirm actions or configuration
parameters, or subscriptions. Since there are 3 people, first come first do.
this way, if someone is in vacations, there are still people that will
be there. that's the "active" part.
* you have to know some of the majordomo basics, you can understand
them with a few emails sent to the mail server.
For example, i have sent a mail to majordomo@seul.org with a blank subject
and the following body :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lists
info f-cpu
which f-cpu
who f-cpu
index f-cpu
intro f-cpu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
it gave the following out :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> lists
majordomo@seul.org serves the following lists:

  admtg                   SEUL/edu Admin software task group
  advotg                  SEUL/edu Advocacy task group
  august-l                XArchon project development mailing list
  carmen-dev              Carmen Sandiego clone development list
  core-layers            
  croxlinux-discuss       croxlinux discussion list
  docutg                  SEUL/edu Documentation task group
  dragonspeace-dev        Dragonspeace development list
  drgenius-dev            Dr Genius project development mailing list
  eduttg                  SEUL/edu Edutainment task group
  f-cpu                   f-cpu mailing list
  freecase-devel          FreeCASE project development mailing list
  freehaven-cvs           FreeHaven development list
  freehaven-dev           FreeHaven development list
  freehdl-dev             FreeHDL project development mailing list
  geda-dev                gEDA project development mailing list
  geda-user               gEDA project development mailing list
  gftp-announce           gFTP announcements list
  gftp-i18n               gFTP i18n list
  gtc-cvs                 Game ToolChest CVS mailing list
  gtc-dev                 Game ToolChest project development mailing list
  hardlicense-discuss     Hardlicense discussion list
  independence-l          Independence project development mailing list
  iptraf-announce         IPTraf Announcements List
  iptraf-users            IPTraf Users discussion list
  kidsui                  Kids UI discussion list
  langtg                  SEUL/edu Language software task group
  linuxkb-announce        LinuxKB Announcements List
  linuxkb-discuss         Linux knowledge-base general discussion list
  linuxkb-list            Linux knowledge-base developer-only mailing list
  lu-admin                Linux United admin mailing list
  lu-announce             Linux United announcements list
  lu-core-devel           Linux United Core Development mailing list
  lu-db                   Linux United Database mailing list
  lu-general              Linux United general mailing list
  lu-news                 Linux News Project mailing list
  lu-news-empty          
  lu-private              Linux United private mailing list
  lu-projects             Linux United projects mailing list
  make-seul-dev          
  mathtg                  SEUL/edu Mathematics software task group
  nightfall-l             Nightfall (Eclipsing binary star program) announcements/
  oods-discuss            OODS discussion list
  oods-discuss-world     
  oses-admin              oses.org admin mailing list
  oses-announce           oses.org announcements list
  oses-discuss            oses.org discussion mailing list
  parsely-users           Parsely users mailing list
  pygame-users            Pygame users mailing list
  quiztg                  SEUL/edu Quiz software task group
  school                  Kevin Forge's tech school list
  scitg                   SEUL/edu Scientific task group
  seul-announce           SEUL Announcements List
  seul-commits           
  seul-dev               
  seul-dev-admin         
  seul-dev-apps          
  seul-dev-distrib       
  seul-dev-help          
  seul-dev-install       
  seul-dev-ui            
  seul-discuss            SEUL general discussion list
  seul-edu                SEUL Education discussion list
  seul-edu-digest         SEUL Education discussion digest list
  seul-edu-world         
  seul-leaders           
  seul-project            SEUL project general mailing list
  seul-pub                SEUL Publicity mailing list
  seul-pub-www            SEUL Website mailing list
  seul-research          
  seul-sci                SEUL Education discussion list
  seul-seg               
  svpn                   
  test                   
  tiny-announce           TINY Distrib Announcements List
  tiny-dev                TINY distrib development/discussion mailing list
  tiny-users              TINY distrib user discussion mailing list
  tpm-dev                 The Penguin Machine development mailing list
  trent                   IAFS Trent list
  wwwtg                   SEUL/edu www task group
  wxftp                   WXftp List
  wxftp-announce          WXftp Announcements List
  xarchon-l               XArchon project development mailing list

Use the 'info <list>' command to get more information
about a specific list.
>>>> info f-cpu
#### No info available for f-cpu.
>>>> which f-cpu
The string 'f-cpu' appears in the following
entries in lists served by majordomo@seul.org:

List                    Address
====                    =======
hardlicense-discuss     whygee@f-cpu.org

>>>> who f-cpu
Members of list 'f-cpu':

seul@majordomo.seul.org
arma@mit.edu

2 subscribers

>>>> index f-cpu
#### No files available for f-cpu.
>>>> intro f-cpu
#### No intro available for f-cpu.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want a summary of all the commands, just send a mail to majordomo@seul.org
with no subject and "help" in the body (and nothing else, otherwise it will think
that these are commands...). This closes our little introduction. I hope that you
have enough details to do the necessary actions. In case of trouble,
Roger Dingledine <arma@mit.edu> and seul@seul.org can help you.

>         Guillaume
>
> * * * * * * * * * * * * * *
>
> God loves fools, otherwise why would He have made so many ?

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Tue Mar 27 12:55:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00380 for ; Sat, 31 Mar 2001 12:02:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:07 +0200 (MEST) Received: (qmail 6020 invoked by uid 0); 27 Mar 2001 10:57:15 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx12) with SMTP; 27 Mar 2001 10:57:15 -0000 X-eGroups-Return: sentto-1101623-2587-985690576-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 27 Mar 2001 10:56:16 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 10:56:15 -0000 Received: (qmail 56103 invoked from network); 27 Mar 2001 10:56:15 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 27 Mar 2001 10:56:15 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.227) by mta1 with SMTP; 27 Mar 2001 10:56:12 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f2RAtVP01241 for ; Tue, 27 Mar 2001 12:55:48 +0200 Message-Id: <200103271055.f2RAtVP01241@PrintServer.LedCom> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <3AC05EEF.6031A6D@mentor.com> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 12:55:36 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >* you have a password that you use to confirm actions or configuration
>parameters, or subscriptions.

  Where will I get this password ?  Should I send you one
encrypted ?

      Guillaume




* * * * * * * * * * * * * * *

Be unique, like everyone else.
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 14:16:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00383 for ; Sat, 31 Mar 2001 12:02:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:08 +0200 (MEST) Received: (qmail 25680 invoked by uid 0); 27 Mar 2001 12:23:45 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx23) with SMTP; 27 Mar 2001 12:23:45 -0000 X-eGroups-Return: sentto-1101623-2588-985695824-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 27 Mar 2001 12:23:44 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 12:23:43 -0000 Received: (qmail 92046 invoked from network); 27 Mar 2001 12:23:43 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 27 Mar 2001 12:23:43 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 27 Mar 2001 13:24:47 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA15699; Tue, 27 Mar 2001 04:23:41 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8X81; Tue, 27 Mar 2001 13:29:23 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC084A0.509C8E3E@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103271055.f2RAtVP01241@PrintServer.LedCom> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 14:16:32 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Guillaume Lederrey wrote:
>   Where will I get this ?  Should I send you one ?
nan, c'est Roger qui l'a donne : f-cp-pass

@+
>         Guillaume
YG

speaking for himself
Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Mar 27 13:57:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00410 for ; Sat, 31 Mar 2001 12:02:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:14 +0200 (MEST) Received: (qmail 24730 invoked by uid 0); 27 Mar 2001 16:16:22 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx03) with SMTP; 27 Mar 2001 16:16:22 -0000 X-eGroups-Return: sentto-1101623-2589-985709779-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fg.egroups.com with NNFMP; 27 Mar 2001 16:16:20 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 16:16:17 -0000 Received: (qmail 1620 invoked from network); 27 Mar 2001 16:16:14 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 27 Mar 2001 16:16:14 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.153) by mta2 with SMTP; 27 Mar 2001 16:16:10 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00506; Tue, 27 Mar 2001 13:57:49 +0200 Message-ID: <20010327135749.47835@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200103262238.f2QMcoJ12062@mail.span.ch> <3AC05EEF.6031A6D@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3AC05EEF.6031A6D@mentor.com>; from Yann GUIDON on Tue, Mar 27, 2001 at 11:35:43AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 13:57:49 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, Mar 27, 2001 at 11:35:43AM +0200, Yann GUIDON wrote:
> Guillaume Lederrey wrote:
> > >Roger has opened the mailing list "f-cpu at seul dot org".
> > >he needs the confirmation from the three volunteers
> > >that they accept to manage the list. By default, Roger
> > >has set myself as maintainer but i'll be removed when the
> > >others will take their function.
> >
> >   No problem for me, I'll be one of the maintainers if you need it !
> too late, you're registered ;-)

Does that mean we can now subscribe there, unsubscribe here (if possible)
and continue on the new list?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue Mar 27 13:51:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00413 for ; Sat, 31 Mar 2001 12:02:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:15 +0200 (MEST) Received: (qmail 30709 invoked by uid 0); 27 Mar 2001 16:16:41 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx15) with SMTP; 27 Mar 2001 16:16:41 -0000 X-eGroups-Return: sentto-1101623-2590-985709800-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 27 Mar 2001 16:16:41 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 16:16:39 -0000 Received: (qmail 2776 invoked from network); 27 Mar 2001 16:16:39 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 27 Mar 2001 16:16:39 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.153) by mta2 with SMTP; 27 Mar 2001 16:16:24 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00485; Tue, 27 Mar 2001 13:51:44 +0200 Message-ID: <20010327135144.09822@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200103262239.f2QMd8J12091@mail.span.ch> <20010327020329.27606@thrai.stud.uni-hannover.de> <3AC05ACF.11B3676B@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3AC05ACF.11B3676B@mentor.com>; from Yann GUIDON on Tue, Mar 27, 2001 at 11:18:07AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 13:51:44 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] CVS Access Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, Mar 27, 2001 at 11:18:07AM +0200, Yann GUIDON wrote:
> Michael Riepe wrote:
> > On Mon, Mar 26, 2001 at 07:03:56PM +0200, Guillaume Lederrey wrote:
> > >   Just a question, I remember someone propose to take care of
> > > the opening of a CVS tree on seul.org (do I remember right ?).
> > You do.  I've simply been too busy (and I'm still waiting for your CVS
> > passwords, guys! -- I only got 2 so far).
> which means yours and mine... :-)

Plus Guillaume's (I didn't count my one).

> OT1: how is it at the CeBit ? i've read about a CCC award to Siemens ...

As usual :)  I'm always glad when this monster fair is over and I can
concentrate on important things again.

> OT2: i finally found the way to boot the thinkpad cleanly. now, i have
> to find a suitable X server and a way to export/import files.....
> at least the CD drive works :-)

No ethernet?  Serial port, maybe?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 18:24:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00419 for ; Sat, 31 Mar 2001 12:02:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:16 +0200 (MEST) Received: (qmail 1935 invoked by uid 0); 27 Mar 2001 16:31:27 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx16) with SMTP; 27 Mar 2001 16:31:27 -0000 X-eGroups-Return: sentto-1101623-2591-985710674-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 27 Mar 2001 16:31:14 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 16:31:13 -0000 Received: (qmail 43344 invoked from network); 27 Mar 2001 16:31:12 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 27 Mar 2001 16:31:12 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 27 Mar 2001 16:31:11 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA03214; Tue, 27 Mar 2001 08:31:10 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8YLM; Tue, 27 Mar 2001 17:36:54 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC0BEA3.FA9DA684@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200103262238.f2QMcoJ12062@mail.span.ch> <3AC05EEF.6031A6D@mentor.com> <20010327135749.47835@thrai.stud.uni-hannover.de> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 18:24:03 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:
> On Tue, Mar 27, 2001 at 11:35:43AM +0200, Yann GUIDON wrote:
> > Guillaume Lederrey wrote:
> > >   No problem for me, I'll be one of the maintainers if you need it !
> > too late, you're registered ;-)
> Does that mean we can now subscribe there, unsubscribe here (if possible)
> and continue on the new list?
i have seen some subscriptions but i don't receive any message.
technically, it is /possible/ to subscribe and unsub,
however it is not yet stable (at least from my part).
therefore :
- either you are impatient and subscribe now
   -> you risk to endure some early possible troubles
- either you are lazy or patient and you wait until
  the list is stable and correctly configured (and with 3 or
  4 people to manage it, it may take a while) and until
  a thread starts.

AFAIK no discussion has started yet, as shown at
http://www.seul.org/archives/f-cpu/f-cpu/ so no need to hurry now.
it seems that it is even not yet possible to post...

the choice is yours.

@+

YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 18:47:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00446 for ; Sat, 31 Mar 2001 12:02:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:22 +0200 (MEST) Received: (qmail 2306 invoked by uid 0); 27 Mar 2001 16:54:46 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx08) with SMTP; 27 Mar 2001 16:54:46 -0000 X-eGroups-Return: sentto-1101623-2592-985712072-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 27 Mar 2001 16:54:33 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 16:54:29 -0000 Received: (qmail 99777 invoked from network); 27 Mar 2001 16:54:26 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 27 Mar 2001 16:54:26 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 27 Mar 2001 16:54:26 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA05057; Tue, 27 Mar 2001 08:54:18 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8YMC; Tue, 27 Mar 2001 18:00:03 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC0C410.7F827BF9@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 18:47:12 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Oekonux-Konferenz: alle_tage@oxkonferenz Content-Type: multipart/mixed; boundary="------------78C24815706A779F46025D75" Status: R X-Status: N --------------78C24815706A779F46025D75 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit http://www.opentheory.org/ox_slot.phtml

we see that most of the conferences are in german but
they seem to be mostly high-quility. A little room is reserved
to "open Hardware". I hope that a lot
of people will come and share their point of view.

I count on you to relay the information, ie on
linuxfr, the opencollector site, etc.

see you there,

YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--------------78C24815706A779F46025D75 Content-Type: text/html; charset=iso-8859-1; name="ox_slot.phtml" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ox_slot.phtml" Content-Base: "http://www.opentheory.org/ox_slot.phtm l" Content-Location: "http://www.opentheory.org/ox_slot.phtm l" Oekonux-Konferenz: alle_tage@oxkonferenz
alle_referentinnen   alle_abstracts   alle_events   der_erste_tag   der_zweite_tag   der_dritte_tag  

alle_tage@oxkonferenz

Achtung: Die Termine sind vorläufig!

28.4.

Beginn Raum A Raum B Raum C
12:00   Vortrag - Oekonux:
Begr=FC=DFung und Einf=FChrung 		 
13:00 Projekt - Torsten W=F6llert:
Das Encyclopaedia Aperta Projekt<= /a>		 Vortrag - Kim Veltman:
=DCber die Verbindung von Open Source und Kul= tur		 Projekt - Georg C. F. Greve:
Geschichte und Philosophie des GNU-Proj= ekts
14:00      
15:00 Workshop - Helmut Dunkhase, Wolf G=F6hring, Norbert Trenkle:
Pro= duktivkraftentwicklung		 Vortrag - Stefan Merten:
Keynote: GPL-Gesellschaft - Vergangenheit, = Gegenwart, Zukunft		 Projekt - Yann Guidon:
The F-CPU project
16:00      
17:00   Vortrag - Thomas Uwe Gr=FCttm=FCller= :
Der =DCbergang in die GPL-Wirts= chaft		 Vortrag - H. J. Krysmanski:
Cyber-Cooperatives
18:00      

29.4.

=
Beginn Raum A Raum B Raum C
10:00 Vortrag - Holger Blasum:
Linksliberale Utopie zum gewerblichen Recht= sschutz		 Vortrag - Franz Nahrada:
Globale D=F6rfer und Freie Software		 Workshop - J=F6rg Bergstedt, Stefan Meretz, Annette Schlemm, Christoph Spe= hr, Heinz Weinhausen:
Reibung erzeugt W=E4rme
11:00      
12:00 Vortrag - Ursula Holtgrewe:
Open Source: Soziale Bewegung, profession= elle Community oder ausgesourcte Technikentwicklung? 		Vortrag - Andy M=FCller-Maguhn:
<= a href=3D'/ox_event.phtml?eid=3D20'>Die Freiheit des Internets (noch off= en)		  
13:00      
14:00 Vortrag - Werner Winzerling:
LINUX: Durchbruch f=FCr die Open Sourc= e Entwicklung ?		 Workshop - Ralf Kr=E4mer, Sabine Nuss, Michael Heinrich, Hans-Gert Gr=E4b= e:
Informationsgesellschaft<= /b>		 Projekt - Markus Merz:
Das OSCar-Projekt
15:00      
16:00 Projekt - Christoph Heinemann, Christoph Schmidt:
divercity feat. modell O=B4Brien 		  Projekt - Graham Seaman:
Free hardware design - past, present, futur= e
17:00      
18:00   Workshop - Oekonux:
Projekt Oekonux: Wie weiter?		 Vortrag - Robert Gehring:
Rechtliche Situation Freier Software (noch= offen)
19:00      

30.4.

Beginn Raum A Raum B Raum C
10:00 Vortrag - Martin 'Joey' Schulze:
= Wie Freie Software entsteht...<= /a>		 Workshop - Petra Haarmann:
Gew=E4hrt die Lizenz Deckungsschutz im b= =FCrgerlichen Rechtssystem?		 Vortrag - Stefan Meretz:
Wem geh=F6rt das Wissen?
11:00      
12:00 Vortrag - Wolf-Andreas Liebert:
<= a href=3D'/ox_event.phtml?eid=3D26'>Demokratisierung wissenschaftlicher = Information		 Vortrag - Florian Schneider:
New Actonomy		 Workshop - Brigitte Streicher:
"Der New Economy die Z=E4hne zeigen..= ."
13:00      
14:00      
15:00      


Quelle: htt= p://www.opentheory.org/ox_slot.phtml
Kontakt: stefan.meretz@opentheory.org
(Last Update: 09.03.2001, 10:19)
 --------------78C24815706A779F46025D75-- From lphalt@gmx.de Tue Mar 27 19:46:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00455 for ; Sat, 31 Mar 2001 12:02:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:26 +0200 (MEST) Received: (qmail 29139 invoked by uid 0); 27 Mar 2001 17:54:29 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx18) with SMTP; 27 Mar 2001 17:54:29 -0000 X-eGroups-Return: sentto-1101623-2593-985715654-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 27 Mar 2001 17:54:18 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 17:54:13 -0000 Received: (qmail 63431 invoked from network); 27 Mar 2001 17:52:05 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 27 Mar 2001 17:52:05 -0000 Received: from unknown (HELO mw.egroups.com) (10.1.2.2) by mta1 with SMTP; 27 Mar 2001 17:52:04 -0000 X-eGroups-Return: lphalt@gmx.de Received: from [10.1.2.208] by mw.egroups.com with NNFMP; 27 Mar 2001 17:46:33 -0000 To: f-cpu@yahoogroups.com Message-ID: <99qjln+m1fe@eGroups.com> In-Reply-To: <3ABE50BB.4B17BA3B@club-internet.fr> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 200.57.128.65 From: lphalt@gmx.de MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 17:46:31 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: little computer troubles... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N --- In f-cpu@y..., whygee@c... wrote:
> hi,
> i finally managed to smash winme out of my smartasspad
> with the help of my sister's computer, which has a diskette
> driver : i just plugged the HDD in it and installed the base.
> however it didn't support the travel back, linux didn't
> adapt the HW configuration properly, it blocks at INIT=2.
> i have partitionned the HDD and installed a basic MSDOS
> so i can still do stuffs, but almost nothing however.
This come out of time of the search of a possible solution but it
might help someone else in the future with WinME and that would like
to do a LOADLIN:
http://www.geocities.com/mfd4life_2000/
>
> on top of that, my main computer ... hangs. The power supply
> is out of order and halts in the middle of anything, i'll
> have to find a new box probably. call that unluck. fortunately,
> i didn't destroy my sister's computer, which i use now to type
> this mail.
>
> wish me luck and wisdom,
> whygee who damns all PCs in the known universe.
Orage.
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carlos De Urresti Hannoh Tue Mar 27 20:16:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00461 for ; Sat, 31 Mar 2001 12:02:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:27 +0200 (MEST) Received: (qmail 20257 invoked by uid 0); 27 Mar 2001 18:16:45 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx16) with SMTP; 27 Mar 2001 18:16:45 -0000 X-eGroups-Return: sentto-1101623-2594-985717001-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 27 Mar 2001 18:16:43 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 18:16:39 -0000 Received: (qmail 17049 invoked from network); 27 Mar 2001 18:16:39 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 27 Mar 2001 18:16:39 -0000 Received: from unknown (HELO mx0.gmx.net) (213.165.64.100) by mta2 with SMTP; 27 Mar 2001 18:16:38 -0000 Received: (qmail 24372 invoked by uid 0); 27 Mar 2001 18:16:37 -0000 To: f-cpu@yahoogroups.com References: <3AC0BEA3.FA9DA684@mentor.com> Message-ID: <7460.985716992@www43.gmx.net> X-Authenticated-Sender: #0006153040@gmx.net X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Authenticated-IP: [200.57.128.65] From: Carlos De Urresti Hannoh MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 20:16:32 +0200 (MEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > Michael Riepe wrote:
> > On Tue, Mar 27, 2001 at 11:35:43AM +0200, Yann GUIDON wrote:
> > > Guillaume Lederrey wrote:
> > > >   No problem for me, I'll be one of the maintainers if you need it !
> > > too late, you're registered ;-)
> > Does that mean we can now subscribe there, unsubscribe here (if
> possible)
> > and continue on the new list?
> i have seen some subscriptions but i don't receive any message.
> technically, it is /possible/ to subscribe and unsub,
> however it is not yet stable (at least from my part).
> therefore :
> - either you are impatient and subscribe now
>    -> you risk to endure some early possible troubles
> - either you are lazy or patient and you wait until
>   the list is stable and correctly configured (and with 3 or
>   4 people to manage it, it may take a while) and until
>   a thread starts.
>
> AFAIK no discussion has started yet, as shown at
> http://www.seul.org/archives/f-cpu/f-cpu/ so no need to hurry now.
> it seems that it is even not yet possible to post...
Posting does work for maintainers(at least on my side). Maybe some people
could try out. Also sub & unsub works.
>
> the choice is yours.
>
> @+
>
> YG
>
> speaking for himself
Orage

--
Sent through GMX FreeMail - http://www.gmx.net
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Tue Mar 27 21:15:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00473 for ; Sat, 31 Mar 2001 12:02:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:30 +0200 (MEST) Received: (qmail 15130 invoked by uid 0); 27 Mar 2001 19:25:31 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx04) with SMTP; 27 Mar 2001 19:25:31 -0000 X-eGroups-Return: sentto-1101623-2595-985720966-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 27 Mar 2001 19:22:47 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 19:22:45 -0000 Received: (qmail 19559 invoked from network); 27 Mar 2001 19:22:44 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 27 Mar 2001 19:22:44 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 27 Mar 2001 19:22:43 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA18507; Tue, 27 Mar 2001 11:22:41 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR8YPA; Tue, 27 Mar 2001 20:28:25 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC0E6D5.A9BD2BA3@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AC0BEA3.FA9DA684@mentor.com> <7460.985716992@www43.gmx.net> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 21:15:33 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Carlos De Urresti Hannoh wrote:
> > Michael Riepe wrote:

> > AFAIK no discussion has started yet, as shown at
> > http://www.seul.org/archives/f-cpu/f-cpu/ so no need to hurry now.
> > it seems that it is even not yet possible to post...
> Posting does work for maintainers(at least on my side). Maybe some people
> could try out. Also sub & unsub works.
right. i just saw the mails reporting your actions ;-)
One problem (from my side) is that i have several mail configs and
zillions of different addresses and forwards....


              . .
            -o-O-o-

On another subject, thanks for the link ;-)

i solved some troubles with the help of my sister's computer,
which has a diskette driver. the configuration is still painful
but i have a working DOS, a rather "clean" (hum) SuSE 6.3
and root/user access.

nice ?
well, i made the mistake to buy a thinkpad...
with a very "exotic" video chip (linux reports 64KB RAM...)
and no access to the outside. i'll need a "fresh" release,
that i'll find this week-end, plus RAM, batteries...

the worst is (i hope) in the past. the best is to come.
i'm proud of the protection bag that i crafted with some foam,
an antistatic bag and a large amount of sticky tape.
the laptop was not even sold with a bag...

The conclusion is : i swear it's the last PC i buy
(nb : i say that everytime).

> > YG
> Orage
YG

speaking OT to himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue Mar 27 12:52:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00476 for ; Sat, 31 Mar 2001 12:02:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:31 +0200 (MEST) Received: (qmail 14970 invoked by uid 0); 27 Mar 2001 19:31:09 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx11) with SMTP; 27 Mar 2001 19:31:09 -0000 X-eGroups-Return: sentto-1101623-2596-985721231-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 27 Mar 2001 19:27:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 19:27:09 -0000 Received: (qmail 31166 invoked from network); 27 Mar 2001 19:27:06 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 27 Mar 2001 19:27:06 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 27 Mar 2001 20:28:10 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA15591 for ; Tue, 27 Mar 2001 12:27:04 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC07108.18BAE685@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AC0BEA3.FA9DA684@mentor.com> <7460.985716992@www43.gmx.net> <3AC0E6D5.A9BD2BA3@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 03:52:56 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:
> The conclusion is : i swear it's the last PC i buy
> (nb : i say that everytime).

Could be, since the next PC you get will be a FREE-CPU. :-)
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue Mar 27 13:24:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00485 for ; Sat, 31 Mar 2001 12:02:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:33 +0200 (MEST) Received: (qmail 14291 invoked by uid 0); 27 Mar 2001 19:59:27 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx22) with SMTP; 27 Mar 2001 19:59:27 -0000 X-eGroups-Return: sentto-1101623-2597-985723152-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ej.egroups.com with NNFMP; 27 Mar 2001 19:59:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 27 Mar 2001 19:59:11 -0000 Received: (qmail 11897 invoked from network); 27 Mar 2001 19:59:10 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 27 Mar 2001 19:59:10 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 27 Mar 2001 19:59:09 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA17184 for ; Tue, 27 Mar 2001 12:59:06 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC0788B.A4B68294@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 27 Mar 2001 04:24:59 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] the P take over Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N After F comes P? http://neil.franklin.ch/Jokes_and_Fun/Acronym_Penguins
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Wed Mar 28 09:44:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00521 for ; Sat, 31 Mar 2001 12:02:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:02:42 +0200 (MEST) Received: (qmail 23251 invoked by uid 0); 28 Mar 2001 06:37:08 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx13) with SMTP; 28 Mar 2001 06:37:08 -0000 X-eGroups-Return: sentto-1101623-2598-985761436-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ck.egroups.com with NNFMP; 28 Mar 2001 06:37:16 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Mar 2001 06:37:15 -0000 Received: (qmail 33057 invoked from network); 28 Mar 2001 06:37:15 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 28 Mar 2001 06:37:15 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta1 with SMTP; 28 Mar 2001 06:37:14 -0000 Received: from art1.none.de (dialin101.pg2-nt.berlin.nikoma.de [213.54.65.101]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f2S6bFb19701 for ; Wed, 28 Mar 2001 08:37:15 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin101.pg2-nt.berlin.nikoma.de [213.54.65.101] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14iAdG-0002VN-00 for ; Wed, 28 Mar 2001 09:44:42 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <3.0.6.32.20010322212206.007bdd00@pop1.edex.net.uk> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Mar 2001 09:44:42 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] German Manual and no success to build shifting unit Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Hello Kristian-Ole,

Ich benutze f=FCr die =DCbersetzung die "Du"-Form von "you&q= uot;.

Ist mir gerade aufgefallen.

Bye Andreas
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From lphalt@gmx.de Thu Mar 29 05:41:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00620 for ; Sat, 31 Mar 2001 12:03:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:14 +0200 (MEST) Received: (qmail 30672 invoked by uid 0); 29 Mar 2001 03:41:23 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx07) with SMTP; 29 Mar 2001 03:41:23 -0000 X-eGroups-Return: sentto-1101623-2599-985837303-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 29 Mar 2001 03:41:45 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 03:41:43 -0000 Received: (qmail 23847 invoked from network); 29 Mar 2001 03:41:42 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Mar 2001 03:41:42 -0000 Received: from unknown (HELO fh.egroups.com) (10.1.2.135) by mta1 with SMTP; 29 Mar 2001 03:41:42 -0000 X-eGroups-Return: lphalt@gmx.de Received: from [10.1.10.132] by fh.egroups.com with NNFMP; 29 Mar 2001 03:41:41 -0000 To: f-cpu@yahoogroups.com Message-ID: <99uath+p75b@eGroups.com> In-Reply-To: <3AC0E6D5.A9BD2BA3@mentor.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 200.57.128.65 From: lphalt@gmx.de MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 03:41:37 -0000 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N --- In f-cpu@y..., Yann GUIDON <whygee@f...> wrote:
> Carlos De Urresti Hannoh wrote:
> > > Michael Riepe wrote:
>
> > > AFAIK no discussion has started yet, as shown at
> > > http://www.seul.org/archives/f-cpu/f-cpu/ so no need to hurry
now.
> > > it seems that it is even not yet possible to post...
> > Posting does work for maintainers(at least on my side). Maybe
some people
> > could try out. Also sub & unsub works.
> right. i just saw the mails reporting your actions ;-)
> One problem (from my side) is that i have several mail configs and
> zillions of different addresses and forwards....
Ohm... lets try to foward everything to one account:>
>
>
>               . .
>             -o-O-o-
>
> On another subject, thanks for the link ;-)
>
> i solved some troubles with the help of my sister's computer,
> which has a diskette driver. the configuration is still painful
> but i have a working DOS, a rather "clean" (hum) SuSE 6.3
> and root/user access.
>
> nice ?
"rather clean"? clean = the last release?
> well, i made the mistake to buy a thinkpad...
> with a very "exotic" video chip (linux reports 64KB RAM...)
weird.. ibm tends to go with neomagic ;)
but they tend to support a lot of crazy things also...
> and no access to the outside. i'll need a "fresh" release,
> that i'll find this week-end, plus RAM, batteries...
external modem? :0
>
> the worst is (i hope) in the past. the best is to come.
the best is to come = As Ben Franchuk said: "since the next PC you
get will be a FREE-CPU. :-)"
> i'm proud of the protection bag that i crafted with some foam,
> an antistatic bag and a large amount of sticky tape.
those are the best.. home made ;) at least they're cheap and you can
design anything that you want over it and you won't regreit later..
since you can easily switch to a "semi"brand new antistatic bag :)
> the laptop was not even sold with a bag...
>
> The conclusion is : i swear it's the last PC i buy
> (nb : i say that everytime).
0=)
>
> > > YG
> > Orage
> YG
>
> speaking OT to himself
Orage
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Mar 28 10:23:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00623 for ; Sat, 31 Mar 2001 12:03:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:14 +0200 (MEST) Received: (qmail 23819 invoked by uid 0); 29 Mar 2001 05:15:42 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx07) with SMTP; 29 Mar 2001 05:15:42 -0000 X-eGroups-Return: sentto-1101623-2600-985842965-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 29 Mar 2001 05:16:06 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 05:16:03 -0000 Received: (qmail 33425 invoked from network); 29 Mar 2001 05:16:03 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 29 Mar 2001 05:16:03 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 29 Mar 2001 05:16:00 -0000 Received: from jetnet.ab.ca (dialin59.jetnet.ab.ca [207.153.6.59]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA07665 for ; Wed, 28 Mar 2001 22:15:53 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC19F8C.774B42CB@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Mar 2001 01:23:40 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Any thoughts on hardware debugging and development? Since a Front Panel is too
large with over 128 switches and light bulbs, and Octal NIXIE tube display only
works for 36 bit cpu's I was thinking of a serial port for minimal hardware
diagnostics for state and bus logic for single stepping thru a program
or unusual fault conditions like reading from write only memory.
Ben.
PS. The nice HEXADECIMAL LED's are too hard to find as well.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu Mar 29 08:02:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00626 for ; Sat, 31 Mar 2001 12:03:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:15 +0200 (MEST) Received: (qmail 10975 invoked by uid 0); 29 Mar 2001 06:01:50 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx15) with SMTP; 29 Mar 2001 06:01:50 -0000 X-eGroups-Return: sentto-1101623-2601-985845732-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mo.egroups.com with NNFMP; 29 Mar 2001 06:02:13 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 06:02:11 -0000 Received: (qmail 23482 invoked from network); 29 Mar 2001 06:02:10 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 29 Mar 2001 06:02:10 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta3 with SMTP; 29 Mar 2001 07:03:14 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA18024 for ; Thu, 29 Mar 2001 09:02:08 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: Freedom CPU In-Reply-To: <3AC19F8C.774B42CB@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 09:02:07 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 28 Mar 2001, Ben Franchuk wrote:

> Any thoughts on hardware debugging and development? Since a Front Panel is too
> large with over 128 switches and light bulbs, and Octal NIXIE tube display only
> works for 36 bit cpu's I was thinking of a serial port for minimal hardware
> diagnostics for state and bus logic for single stepping thru a program
> or unusual fault conditions like reading from write only memory.

For external connections good logic analyzer and pattern generator
are the easiest tools for debugging. For example new Tektronics logic
analyzers can after some configurations disassemble commands from memory
busses, correlate that code to the actual binaries and their source code
etc (reads ELF binaries with debug information).

Also if FPGAs are used Altera and Xilinx offer embeddable logic analyzers
that work inside the chip. There is no dynamic binding of signals inside
the chip. But those extensions are not in the normal tools usually.

The debugging channel to the processor could be trough JTAG or some I2C
bus. It could be used to halt the processor, single step, read the
registers, modify memory etc. There is such bus in all new Intel processor
but it is not very well documented. The debugging channel has to be tought
quite carefully. For example how single step really works, how the
pipeline is emptied when single step mode is entered etc.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 29 10:26:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00638 for ; Sat, 31 Mar 2001 12:03:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:18 +0200 (MEST) Received: (qmail 7823 invoked by uid 0); 29 Mar 2001 08:37:08 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx15) with SMTP; 29 Mar 2001 08:37:08 -0000 X-eGroups-Return: sentto-1101623-2602-985854814-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 29 Mar 2001 08:33:35 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 08:33:34 -0000 Received: (qmail 87579 invoked from network); 29 Mar 2001 08:33:33 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Mar 2001 08:33:33 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 29 Mar 2001 09:34:37 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id AAA09884; Thu, 29 Mar 2001 00:33:29 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR85CG; Thu, 29 Mar 2001 09:39:13 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC2F1AA.52D0880@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AC19F8C.774B42CB@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 10:26:18 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Ben Franchuk wrote:
>
> Any thoughts on hardware debugging and development? Since a Front Panel is too
> large with over 128 switches and light bulbs, and Octal NIXIE tube display only
> works for 36 bit cpu's I was thinking of a serial port for minimal hardware
> diagnostics for state and bus logic for single stepping thru a program
> or unusual fault conditions like reading from write only memory.
> Ben.
> PS. The nice HEXADECIMAL LED's are too hard to find as well.

For debugging purpose, i have found a "cheap" ($25 ?) ISA 16bit
prototyping board at Conrad when i was in Munich.
Load it with tristate buffers and a correctly programmed PAL
and it gives you access to buses etc.
I did this about 3 years ago : provided you have the
necessary HW (soldering iron, buffers, board, PAL and PAL
burner, patience, methodology and a valid plan), you can do
cheap and easy HW debug, load SW and step/trace it. it can run
on i286+ and downloads faster than JTAG, while contempting
itself with a small DOS system :-)

OTherwise, there is the possibility to use the parallel printer port.
i didn't have enough time to explore that, but it's even cheaper,
but can lead to some new interesting problems.

These solutions are what i will certainly try from my side.
Others may find solutions that better suit their needs.
Nothing keeps you from using hex LEDs for example, but
i won't be able to help for the driver ;-)


YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 29 10:39:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00641 for ; Sat, 31 Mar 2001 12:03:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:19 +0200 (MEST) Received: (qmail 18047 invoked by uid 0); 29 Mar 2001 08:46:48 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx03) with SMTP; 29 Mar 2001 08:46:48 -0000 X-eGroups-Return: sentto-1101623-2603-985855631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 29 Mar 2001 08:47:12 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 08:47:10 -0000 Received: (qmail 98475 invoked from network); 29 Mar 2001 08:47:09 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 29 Mar 2001 08:47:09 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 29 Mar 2001 08:47:08 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id AAA10894; Thu, 29 Mar 2001 00:47:04 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR85DA; Thu, 29 Mar 2001 09:52:50 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC2F4DB.9DF3D792@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 10:39:55 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kim Enkovaara wrote:
> On Wed, 28 Mar 2001, Ben Franchuk wrote:
> > Any thoughts on hardware debugging and development?
> For external connections good logic analyzer and pattern generator
> are the easiest tools for debugging. For example new Tektronics logic
> analyzers can after some configurations disassemble commands from memory
> busses, correlate that code to the actual binaries and their source code
> etc (reads ELF binaries with debug information).
funny :-)
i'd be happy to have one for Xmas ;-)

> Also if FPGAs are used Altera and Xilinx offer embeddable logic analyzers
> that work inside the chip. There is no dynamic binding of signals inside
> the chip. But those extensions are not in the normal tools usually.
???
URL ? more information ?

> The debugging channel to the processor could be trough JTAG or some I2C
> bus. It could be used to halt the processor, single step, read the
> registers, modify memory etc. There is such bus in all new Intel processor
> but it is not very well documented.
i thought it was in the Intel Manuals that are available online,not the programmer's
reference but the HW implementation guides... or maybe i dreamt ? i know
it exists since the Pentium.

> The debugging channel has to be tought quite carefully.
like everything :-)

> For example how single step really works, how the
> pipeline is emptied when single step mode is entered etc.
i think that there should be no real problem for the F-CPU
(at first glance).
But it poses the question whether we allow a static or dynamic logic
CPU : do we want to work at a particular speed only, or allow it
to slow down at will ?
I think that for the prototype, since we're going to use a technology
similar to FPGAs, a static CPU will be made at the beginning :
this will ease debugging and building, at the cost of more transistors
but it's only a proto...

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Thu Mar 29 10:57:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00644 for ; Sat, 31 Mar 2001 12:03:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:20 +0200 (MEST) Received: (qmail 21959 invoked by uid 0); 29 Mar 2001 08:57:15 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx23) with SMTP; 29 Mar 2001 08:57:15 -0000 X-eGroups-Return: sentto-1101623-2604-985856258-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 29 Mar 2001 08:57:40 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 08:57:38 -0000 Received: (qmail 27472 invoked from network); 29 Mar 2001 08:57:37 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 29 Mar 2001 08:57:37 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 29 Mar 2001 08:57:36 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id DAA05000 for ; Thu, 29 Mar 2001 03:54:25 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id DAA22047 for ; Thu, 29 Mar 2001 03:57:28 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 29 Mar 2001 09:57:28 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EBEC@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 09:57:21 +0100 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
[YG wrote...]
[...]
> > For example how single step really works, how the
> > pipeline is emptied when single step mode is entered etc.
> i think that there should be no real problem for the F-CPU
> (at first glance).
> But it poses the question whether we allow a static or dynamic logic
> CPU : do we want to work at a particular speed only, or allow it
> to slow down at will ?
> I think that for the prototype, since we're going to use a technology
> similar to FPGAs, a static CPU will be made at the beginning :
> this will ease debugging and building, at the cost of more transistors
> but it's only a proto...

I wonder, are there any advantages to dynamic logic in a CPU? What do you do
differently in the design to cause it to be a dynamic rather than static
device? Why not always have a static logic? Personally when I have built
computers using the Z80 (which is static), I have found it invaluable to be
able to connect LED's on all the address and data lines, and be able to stop
the clock and single step it. I recall I could not get my viscometer project
(http://www.hanssummers.com/electronics/viscometer/visc.htm) to work, and
only by this method was I able to debug it.

>
> YG
>
> speaking for himself

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
[]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 29 10:56:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00647 for ; Sat, 31 Mar 2001 12:03:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:20 +0200 (MEST) Received: (qmail 18545 invoked by uid 0); 29 Mar 2001 09:03:16 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx19) with SMTP; 29 Mar 2001 09:03:16 -0000 X-eGroups-Return: sentto-1101623-2605-985856613-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 29 Mar 2001 09:03:34 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 09:03:32 -0000 Received: (qmail 38167 invoked from network); 29 Mar 2001 09:03:32 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Mar 2001 09:03:32 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 29 Mar 2001 10:04:36 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA11776; Thu, 29 Mar 2001 01:03:28 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR851V; Thu, 29 Mar 2001 10:09:12 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC2F8B2.5C72E51C@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <99uath+p75b@eGroups.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 10:56:18 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: mailing list transition Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N lphalt@gmx.de wrote:
> >               . .
> >             -o-O-o-
> >
> > On another subject, thanks for the link ;-)
> >
> > i solved some troubles with the help of my sister's computer,
> > which has a diskette driver. the configuration is still painful
> > but i have a working DOS, a rather "clean" (hum) SuSE 6.3
> > and root/user access.
> >
> > nice ?
> "rather clean"? clean = the last release?
"SuSE 6.3"
This is not the newest, more than 1 year old.

> > well, i made the mistake to buy a thinkpad...
> > with a very "exotic" video chip (linux reports 64KB RAM...)
> weird.. ibm tends to go with neomagic ;)
> but they tend to support a lot of crazy things also...
> > and no access to the outside. i'll need a "fresh" release,
> > that i'll find this week-end, plus RAM, batteries...
> external modem? :0
yup, but there's no serial port ... i hope that the USB ports work,
otherwise a PCMCIA one will be needed :-( i still have to setup PCMCIA.

a colleague has lent me the most recent Mandrake : only to discover that
the SMI driver (video chip in the laptop) was in XF86 3.3.6...
at least there's a recent kernel anf hopefully working PCMCIA and USB,
i'll have to test them. i first have to finish the configuration of
the X server : the accelerated one doesn't work well, and the "safe" one
is slow. But i prefer that than being bound to M$ ...

> > the worst is (i hope) in the past. the best is to come.
> the best is to come = As Ben Franchuk said: "since the next PC you
> get will be a FREE-CPU. :-)"
hum, let's hope so :-) but let's be patient too...

> > i'm proud of the protection bag that i crafted with some foam,
> > an antistatic bag and a large amount of sticky tape.
> those are the best.. home made ;) at least they're cheap and you can
> design anything that you want over it and you won't regreit later..
> since you can easily switch to a "semi"brand new antistatic bag :)
yup.

> > The conclusion is : i swear it's the last PC i buy
> > (nb : i say that everytime).
> 0=)
hey, the next one is certainly going to be an ALPHA,
if i have enough money one day ;-)

> > > > YG
> > > Orage
> > YG
> > speaking OT to himself
> Orage
YG
speaking again for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 29 11:12:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00650 for ; Sat, 31 Mar 2001 12:03:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:21 +0200 (MEST) Received: (qmail 21149 invoked by uid 0); 29 Mar 2001 09:19:26 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx01) with SMTP; 29 Mar 2001 09:19:26 -0000 X-eGroups-Return: sentto-1101623-2606-985857589-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 29 Mar 2001 09:19:51 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 09:19:48 -0000 Received: (qmail 67430 invoked from network); 29 Mar 2001 09:19:48 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Mar 2001 09:19:48 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 29 Mar 2001 10:20:52 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA12830; Thu, 29 Mar 2001 01:19:44 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR85F5; Thu, 29 Mar 2001 10:25:29 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC2FC83.3A017532@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EBEC@po1-exch.lon.tudor.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 11:12:35 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hans Summers wrote:
> [YG wrote...]
> [...]
> I wonder, are there any advantages to dynamic logic in a CPU? What do you do
> differently in the design to cause it to be a dynamic rather than static
> device? Why not always have a static logic? Personally when I have built
> computers using the Z80 (which is static), I have found it invaluable to be
> able to connect LED's on all the address and data lines, and be able to stop
> the clock and single step it. I recall I could not get my viscometer project
> (http://www.hanssummers.com/electronics/viscometer/visc.htm) to work, and
> only by this method was I able to debug it.

That is completely true but past 10 or 20 MHz, this doesn't hold well,
the pipe buffers have to change... i'll have to find some good microelectronics
references, maybe that my numbers are old, but the highest speed full-custom
chips require different clocking systems and buffering strategies.
This doesn't impact us at the current level, however (AFAIK).


> > YG
> > speaking for himself
YG
speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu Mar 29 15:23:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00674 for ; Sat, 31 Mar 2001 12:03:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:27 +0200 (MEST) Received: (qmail 2174 invoked by uid 0); 29 Mar 2001 13:23:38 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx26) with SMTP; 29 Mar 2001 13:23:38 -0000 X-eGroups-Return: sentto-1101623-2607-985872217-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ef.egroups.com with NNFMP; 29 Mar 2001 13:23:38 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 13:23:37 -0000 Received: (qmail 65413 invoked from network); 29 Mar 2001 13:23:31 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 29 Mar 2001 13:23:31 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 29 Mar 2001 13:23:31 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA24519 for ; Thu, 29 Mar 2001 16:23:29 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3AC2F4DB.9DF3D792@mentor.com> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 16:23:28 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 29 Mar 2001, Yann GUIDON wrote:

> > Also if FPGAs are used Altera and Xilinx offer embeddable logic analyzers
> > that work inside the chip. There is no dynamic binding of signals inside
> > the chip. But those extensions are not in the normal tools usually.
> ???
> URL ? more information ?

The name of the product with Xilinx is ChipScope ILA, you can read more
>from Xilinx web. Just choose Products/Design Tools/Chipscope ILA.
I know that Altera has similar one, but I didn't find where in their web
they have it.

> > pipeline is emptied when single step mode is entered etc.
> i think that there should be no real problem for the F-CPU
> (at first glance).

When you halt the chip possibly the pipeline has to be emptied after the
halted command. Single step has to run the whole command trough the whole
pipeline etc. to make the debugging easier. But also pipeline single step
is needed for pipeline debugging etc.

> But it poses the question whether we allow a static or dynamic logic
> CPU : do we want to work at a particular speed only, or allow it
> to slow down at will ?

In synchronous logic changing the speed is not so difficult. The problem
will be DRAM interfaces etc. which need to adapt the speed of refresh
logic to the clock speed etc. This is easy with VirtexII where the DCM
clock manager has programmable DLL with multiplier and divisor. That can
be used to create clocks to the DRAM controller that change frequency
dynamically.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu Mar 29 15:30:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00677 for ; Sat, 31 Mar 2001 12:03:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:28 +0200 (MEST) Received: (qmail 29522 invoked by uid 0); 29 Mar 2001 13:30:10 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx10) with SMTP; 29 Mar 2001 13:30:10 -0000 X-eGroups-Return: sentto-1101623-2608-985872636-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 29 Mar 2001 13:30:37 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 13:30:35 -0000 Received: (qmail 22176 invoked from network); 29 Mar 2001 13:30:34 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 29 Mar 2001 13:30:34 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta1 with SMTP; 29 Mar 2001 13:30:34 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA23266 for ; Thu, 29 Mar 2001 16:30:32 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 16:30:31 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 29 Mar 2001, Kim Enkovaara wrote:

> I know that Altera has similar one, but I didn't find where in their web
> they have it.

OK, I found it:

http://www.altera.com/products/software/quartus2/qts-signaltap1.html

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Mar 28 12:30:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00680 for ; Sat, 31 Mar 2001 12:03:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:28 +0200 (MEST) Received: (qmail 2417 invoked by uid 0); 29 Mar 2001 15:17:31 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx15) with SMTP; 29 Mar 2001 15:17:31 -0000 X-eGroups-Return: sentto-1101623-2609-985879076-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 29 Mar 2001 15:17:58 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 15:17:54 -0000 Received: (qmail 6134 invoked from network); 29 Mar 2001 15:16:35 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 29 Mar 2001 15:16:35 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 29 Mar 2001 16:17:39 -0000 Received: from jetnet.ab.ca (dialin52.jetnet.ab.ca [207.153.6.52]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA17641 for ; Thu, 29 Mar 2001 08:16:32 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC1BD5F.1E030389@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EBEC@po1-exch.lon.tudor.com> <3AC2FC83.3A017532@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Mar 2001 03:30:55 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:

> That is completely true but past 10 or 20 MHz, this doesn't hold well,
> the pipe buffers have to change... i'll have to find some good microelectronics
> references, maybe that my numbers are old, but the highest speed full-custom
> chips require different clocking systems and buffering strategies.
> This doesn't impact us at the current level, however (AFAIK).

Speed wise - static or dynamic circuits are about the same.
The advantage a dynamic circuit has is fewer transistors and
some power savings as well. The disadvantage with dynamic logic
is a refresh or pre-charge time is needed.
One other problem once the CPU is designed also is finding simple
I/O hardware. Looking at the what few I/O chip information for floppy
disk controllers and the like,you have very few chips as every thing
nowadays is multi-function and need a lot of CPU programing.
Has anybody thought of the I/O yet.
Ben.
PS. I like the old fashioned idea that mass-storage loads
sector 0 track 0 in to core memory on reset. Right now since the
logic design of my CPU is almost done I am looking for I/O devices
to breadboard with the fpga I have.The one thing I can't do
however is program a rom, and that limits what chips I can use.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Thu Mar 29 17:51:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00683 for ; Sat, 31 Mar 2001 12:03:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:29 +0200 (MEST) Received: (qmail 31946 invoked by uid 0); 29 Mar 2001 15:51:50 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx09) with SMTP; 29 Mar 2001 15:51:50 -0000 X-eGroups-Return: sentto-1101623-2610-985881109-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ej.egroups.com with NNFMP; 29 Mar 2001 15:51:50 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 15:51:48 -0000 Received: (qmail 91768 invoked from network); 29 Mar 2001 15:51:21 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 29 Mar 2001 15:51:21 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 29 Mar 2001 15:51:21 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id KAA23860 for ; Thu, 29 Mar 2001 10:48:16 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id KAA07677 for ; Thu, 29 Mar 2001 10:51:19 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Thu, 29 Mar 2001 16:51:19 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EBF5@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 16:51:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> From: Ben Franchuk [mailto:bfranchuk@jetnet.ab.ca]
>
> Yann GUIDON wrote:
>

[...]

> One other problem once the CPU is designed also is finding simple
> I/O hardware. Looking at the what few I/O chip information for floppy
> disk controllers and the like,you have very few chips as every thing
> nowadays is multi-function and need a lot of CPU programing.
> Has anybody thought of the I/O yet.
> Ben.
> PS. I like the old fashioned idea that mass-storage loads
> sector 0 track 0 in to core memory on reset. Right now since the
> logic design of my CPU is almost done I am looking for I/O devices
> to breadboard with the fpga I have.The one thing I can't do
> however is program a rom, and that limits what chips I can use.

The IDE hard disk interface is relatively simple compared to floppy disk
drives. You can build an IDE controller with a small handful of TTL chips.
In fact for a 16-bit or more databus, the IDE interface is almost trivial.
The following links are about IDE interfaces:

http://www.students.tut.fi/~leinone3/ide.html
http://blkbox.com/~jdbaker/SmallSys/8bitIDE.html
http://www.z88forever.org.uk/zxplus3e/interface.html
http://home.freeuk.net/c.ward/6502/index.html
http://8bs.aussie.nu/subide.htm

Why can't you program a ROM? You do not need a ROM programmer. I programmed
mine with a set of switches
http://www.hanssummers.com/computers/newz80/intro.htm#SwitchBoard, including
the character set
http://www.hanssummers.com/computers/newz80/intro.htm#CharacterSet (1024
bytes).

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Mar 28 13:58:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00695 for ; Sat, 31 Mar 2001 12:03:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:45 +0200 (MEST) Received: (qmail 963 invoked by uid 0); 29 Mar 2001 16:45:03 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx26) with SMTP; 29 Mar 2001 16:45:03 -0000 X-eGroups-Return: sentto-1101623-2611-985884301-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 29 Mar 2001 16:45:04 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 16:45:00 -0000 Received: (qmail 30906 invoked from network); 29 Mar 2001 16:43:51 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Mar 2001 16:43:51 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 29 Mar 2001 17:44:55 -0000 Received: from jetnet.ab.ca (dialin52.jetnet.ab.ca [207.153.6.52]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA21881 for ; Thu, 29 Mar 2001 09:43:47 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC1D1D3.3CC9FB0F@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EBF5@po1-exch.lon.tudor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Mar 2001 04:58:11 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hans Summers wrote:

> The IDE hard disk interface is relatively simple compared to floppy disk
> drives. You can build an IDE controller with a small handful of TTL chips.
> In fact for a 16-bit or more databus, the IDE interface is almost trivial.
> The following links are about IDE interfaces:

True but have only one spare IDE drive that may be flakey, but about 3
3 1/2 inch floppy drives. What I use will all boil down to what I parts
I can get.

> http://www.students.tut.fi/~leinone3/ide.html
> http://blkbox.com/~jdbaker/SmallSys/8bitIDE.html
> http://www.z88forever.org.uk/zxplus3e/interface.html
> http://home.freeuk.net/c.ward/6502/index.html
> http://8bs.aussie.nu/subide.htm

Thanks for the links.I had planned on checking out IDE interfacing
after I checked out what I can find on floppies, in a day or so.
I was thinking of a PDP-8 IDE interface here for idea.

http://surfin.spies.com/~dgc/pdp8x/
>
> Why can't you program a ROM? You do not need a ROM programmer. I programmed
> mine with a set of switches
> http://www.hanssummers.com/computers/newz80/intro.htm#SwitchBoard, including
> the character set
> http://www.hanssummers.com/computers/newz80/intro.htm#CharacterSet (1024
> bytes).

This is a HARDWARE challenged project here. At the moment I have
a FPGA, two memory chips ( 32kb total ) and RS232 level converter.
I plan to bootstrap of the serial input. Extra hardware here is no
problem because I have exactly the room left for a 1200 baud uart
on my FPGA. Even the the FPGA board I have is no longer being manufactured.
While I can later add a ROM , I would like to be able to use the
Auto-boot feature with the mass-storage device.
Once I get the core cpu working I hope be able to get a PCB made
for larger computer - 128 Kb memory - video display/keyboard - hard
disk and removable media. One other option for I/O is the parallel port
ZIP disk I have here.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Mar 29 19:19:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00701 for ; Sat, 31 Mar 2001 12:03:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:03:47 +0200 (MEST) Received: (qmail 7679 invoked by uid 0); 29 Mar 2001 17:28:12 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx21) with SMTP; 29 Mar 2001 17:28:12 -0000 X-eGroups-Return: sentto-1101623-2612-985886782-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hl.egroups.com with NNFMP; 29 Mar 2001 17:26:25 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 17:26:21 -0000 Received: (qmail 42034 invoked from network); 29 Mar 2001 17:26:16 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 29 Mar 2001 17:26:16 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 29 Mar 2001 17:26:14 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA15020; Thu, 29 Mar 2001 09:26:11 -0800 (PST) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR858H; Thu, 29 Mar 2001 18:31:56 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC36E86.E611255A@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 19:19:02 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] pictures Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

i have developped some photos, including those from the 17C3 :

http://www.f-cpu.de/17C3/17C3_1.jpg
http://www.f-cpu.de/17C3/17C3_2.jpg
(that's all i could scan, but i have some others).

i don't know if it will be as joyful at the HAL but
i'm firmly crossing my fingers :-)

CU there,
YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Thu Mar 29 13:53:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00794 for ; Sat, 31 Mar 2001 12:04:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:04:16 +0200 (MEST) Received: (qmail 25073 invoked by uid 0); 29 Mar 2001 23:26:32 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx18) with SMTP; 29 Mar 2001 23:26:32 -0000 X-eGroups-Return: sentto-1101623-2613-985908386-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 29 Mar 2001 23:26:27 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 29 Mar 2001 23:26:25 -0000 Received: (qmail 85775 invoked from network); 29 Mar 2001 23:26:25 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 29 Mar 2001 23:26:25 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.98) by mta3 with SMTP; 30 Mar 2001 00:27:28 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00435; Thu, 29 Mar 2001 13:53:38 +0200 Message-ID: <20010329135337.19708@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AC2F4DB.9DF3D792@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3AC2F4DB.9DF3D792@mentor.com>; from Yann GUIDON on Thu, Mar 29, 2001 at 10:39:55AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 29 Mar 2001 13:53:37 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, Mar 29, 2001 at 10:39:55AM +0200, Yann GUIDON wrote:
[...]
> > For example how single step really works, how the
> > pipeline is emptied when single step mode is entered etc.
> i think that there should be no real problem for the F-CPU
> (at first glance).
> But it poses the question whether we allow a static or dynamic logic
> CPU : do we want to work at a particular speed only, or allow it
> to slow down at will ?

Hmm... at least it should work within a reasonable range of clock
frequencies (power saving mode for your next notebook ;).

> I think that for the prototype, since we're going to use a technology
> similar to FPGAs, a static CPU will be made at the beginning :
> this will ease debugging and building, at the cost of more transistors
> but it's only a proto...

Yep...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Fri Mar 30 16:32:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00890 for ; Sat, 31 Mar 2001 12:04:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:04:41 +0200 (MEST) Received: (qmail 28316 invoked by uid 0); 30 Mar 2001 14:58:48 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx16) with SMTP; 30 Mar 2001 14:58:48 -0000 X-eGroups-Return: sentto-1101623-2614-985962844-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 30 Mar 2001 14:34:07 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 30 Mar 2001 14:34:03 -0000 Received: (qmail 14279 invoked from network); 30 Mar 2001 14:32:41 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 30 Mar 2001 14:32:41 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta1 with SMTP; 30 Mar 2001 14:32:40 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id JAA07584 for ; Fri, 30 Mar 2001 09:29:34 -0500 (EST) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id JAA13025 for ; Fri, 30 Mar 2001 09:32:38 -0500 (EST) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Mar 2001 15:32:38 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EC03@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 30 Mar 2001 15:32:30 +0100 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > From: Ben Franchuk [mailto:bfranchuk@jetnet.ab.ca]
>
> Hans Summers wrote:
>
> > The IDE hard disk interface is relatively simple compared
> > to floppy disk drives. You can build an IDE controller with
> > a small handful of TTL chips. In fact for a 16-bit or more
> > databus, the IDE interface is almost trivial.
> > The following links are about IDE interfaces:
>
> True but have only one spare IDE drive that may be flakey, but about 3
> 3 1/2 inch floppy drives. What I use will all boil down to
> what I parts I can get.
> 
> > http://www.students.tut.fi/~leinone3/ide.html
> > http://blkbox.com/~jdbaker/SmallSys/8bitIDE.html
> > http://www.z88forever.org.uk/zxplus3e/interface.html
> > http://home.freeuk.net/c.ward/6502/index.html
> > http://8bs.aussie.nu/subide.htm
>
> Thanks for the links.I had planned on checking out IDE interfacing
> after I checked out what I can find on floppies, in a day or so.
> I was thinking of a PDP-8 IDE interface here for idea.
>
>  http://surfin.spies.com/~dgc/pdp8x/

Interesting link, I added it to my collection. I had previously thought
interfacing to floppies was much easier than hard disks, once I even bought
some Western Digital FDC chip, though never got round to using it. In
reality it seems easier to interface to IDE drives as seen in those links.
As you say though, just depends what you have available. I once built a freq
counter which used four 74100 TTL, because I happened to have them
(http://www.hanssummers.com/electronics/equipment/counter/intro.htm). The
other day I was looking on the net for a datasheet for it to put on my new
database links page
(http://www.hanssummers.com/electronics/datasheets/index.htm). The thing is
so long obsolete that there aren't any. At the time I had some and it suited
me.

[...]

Ben.

------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Mar 28 22:27:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00896 for ; Sat, 31 Mar 2001 12:04:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 31 Mar 2001 12:04:42 +0200 (MEST) Received: (qmail 13019 invoked by uid 0); 30 Mar 2001 15:10:00 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx03) with SMTP; 30 Mar 2001 15:10:00 -0000 X-eGroups-Return: sentto-1101623-2615-985964573-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 30 Mar 2001 15:02:55 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_0_4); 30 Mar 2001 15:02:51 -0000 Received: (qmail 97915 invoked from network); 30 Mar 2001 15:01:52 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 30 Mar 2001 15:01:52 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 30 Mar 2001 15:01:52 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA09733 for ; Fri, 30 Mar 2001 08:01:49 -0700 (MST) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AC24930.D5AF43FD@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <0CFA3081B86BD311B37A00902762718F0152EC03@po1-exch.lon.tudor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 28 Mar 2001 13:27:28 -0700 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] hardware debugging Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hans Summers wrote:

> Interesting link, I added it to my collection. I had previously thought
> interfacing to floppies was much easier than hard disks, once I even bought
> some Western Digital FDC chip, though never got round to using it. In
> reality it seems easier to interface to IDE drives as seen in those links.
> As you say though, just depends what you have available. I once built a freq
> counter which used four 74100 TTL, because I happened to have them
> (http://www.hanssummers.com/electronics/equipment/counter/intro.htm). The
> other day I was looking on the net for a datasheet for it to put on my new
> database links page
> (http://www.hanssummers.com/electronics/datasheets/index.htm). The thing is
> so long obsolete that there aren't any. At the time I had some and it suited
> me.

The only problem with the new floppy disk chips is that they all are in
the 'flat pack' packaging which is not great for bread boarding and of
course you still need DMA and old data sheets for the floppy disk format.
Still all this looking old data sheets has reminded me how slow old I/O
devices are thus I need now to add wait states and a Dram refresh counter
to my cpu.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat Mar 31 22:41:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01279 for ; Tue, 3 Apr 2001 01:56:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 03 Apr 2001 01:56:07 +0200 (MEST) Received: (qmail 16491 invoked by uid 0); 31 Mar 2001 21:27:08 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx11) with SMTP; 31 Mar 2001 21:27:08 -0000 X-eGroups-Return: sentto-1101623-2616-986074023-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 31 Mar 2001 21:27:04 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_0_1); 31 Mar 2001 21:27:02 -0000 Received: (qmail 66495 invoked from network); 31 Mar 2001 21:27:01 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 31 Mar 2001 21:27:01 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.163.225) by mta3 with SMTP; 31 Mar 2001 22:28:04 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 87C619DFE for ; Sat, 31 Mar 2001 22:41:46 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AC6410A.39A429BA@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AB91E74.455897CD@seul.org> <20010322011444.30361@thrai.stud.uni-hannover.de> <3ABA628E.468CFF99@seul.org> <20010323114753.26114@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 31 Mar 2001 22:41:46 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Michael Riepe a =E9crit :
>
> Hi *,
>
> On Thu, Mar 22, 2001 at 09:37:34PM +0100, Nicolas wrote:
> [...]
> > > > /home/profelec/nboulay/fcpu/eu_imu/reduce_tree.vhdl: > > > > Warning: Type of the generic is assumed to be 'Integer'= in synthesis  on
> > > > line 25  (VHDL-2023)
> > > > Warning: Type of the generic is assumed to be 'Integer'= in synthesis  on
> > > > line 26  (VHDL-2023)
> > > > Warning: Type of the generic is assumed to be 'Integer'= in synthesis  on
> > > > line 27  (VHDL-2023)
> > >
> > > Last time I looked, `natural' was a subtype of `integer'.&nb= sp; So what?
> > >
> >
> > Natural and Positive are suppose to be integer.
>
> I guess that warning means that the synthesizer ignores the range
> constraints of natural/positive, right?  Otherwise it wouldn't ma= ke
> sense to print a warning message at all.  Anyway -- I'll not re-t= ype my
> `natural' generics to `integer' just to make a stubborn tool happy (an= d
> it's only a warning anyway -- we'll have to live with these messages).=
>

I think realy you don't ! How could you refind an error in the middle og 200 warning ? And just to remember one little thing. Synopsys is used by 90 % of the compagny working on the world most important industry, the
microelectronic. So if the fcpu could be easy used with synopsys...

> [...]
> > > No boolean generics?  Now what does THAT mean?  Do= I have to convert
> > > them to integer and use 0/1 to switch them on and off? = That sucks.
> > >
> >
> > Boolean are very strange in VHDL...
> > Never forget that front end of vhdl compiler aren't so cool. Reme= nber
> > that i always insit to use VHDL 87 and 93, you understand why...<= BR> >
> *sigh*  That's like a C compiler that doesn't understand `void' := (
>

No ! The basic is std_logic... ;p


> I'll "correct" the code and re-release it ASAP (that is, whe= n the CeBIT
> fair is over, in a week or something like that).
>
> CU,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Matringe Mon Apr 2 09:39:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01422 for ; Tue, 3 Apr 2001 01:57:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 03 Apr 2001 01:57:16 +0200 (MEST) Received: (qmail 15608 invoked by uid 0); 2 Apr 2001 07:37:19 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx07) with SMTP; 2 Apr 2001 07:37:19 -0000 X-eGroups-Return: sentto-1101623-2618-986197038-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mq.egroups.com with NNFMP; 02 Apr 2001 07:37:18 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_0_1); 2 Apr 2001 07:37:17 -0000 Received: (qmail 68043 invoked from network); 2 Apr 2001 07:37:17 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 2 Apr 2001 07:37:17 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 2 Apr 2001 07:37:16 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA03312 for ; Mon, 2 Apr 2001 07:37:15 GMT X-To: Message-ID: <3AC82C9E.D1D585D0@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <3AB91E74.455897CD@seul.org> <20010322011444.30361@thrai.stud.uni-hannover.de> <3ABA628E.468CFF99@seul.org> <20010323114753.26114@thrai.stud.uni-hannover.de> <3AC6410A.39A429BA@seul.org> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Apr 2001 09:39:10 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: compile imul64] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nicolas wrote:

>
> I think realy you don't ! How could you refind an error in the
> middle og 200 warning ?

Just edit the log file and search for "error".
I ain't afraid of 100's of warnings (I get them on every p&r run. Mostly
unused outputs)

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "ilovedomain" Tue Feb 1 18:29:31 2000 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01497 for ; Tue, 3 Apr 2001 01:57:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 03 Apr 2001 01:57:35 +0200 (MEST) Received: (qmail 15035 invoked by uid 0); 2 Apr 2001 17:34:04 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx17) with SMTP; 2 Apr 2001 17:34:04 -0000 X-eGroups-Return: sentto-1101623-2619-986232431-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by b05.egroups.com with NNFMP; 02 Apr 2001 17:27:11 -0000 X-Sender: info@ilovedomain.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_0_1); 2 Apr 2001 17:27:10 -0000 Received: (qmail 87284 invoked from network); 2 Apr 2001 17:27:09 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 2 Apr 2001 17:27:09 -0000 Received: from unknown (HELO edigitals.com) (211.175.164.170) by mta1 with SMTP; 2 Apr 2001 17:27:08 -0000 Received: from choani ([211.186.113.209]) by edigitals.com (8.10.1/8.10.1) with SMTP id f32HLqX30107 for ; Tue, 3 Apr 2001 02:21:53 +0900 Message-Id: <200104021721.f32HLqX30107@edigitals.com> To: f-cpu@yahoogroups.com X-AD2000-Serial: 1057 X-AD2000-Register: "ÃÖȸ¼º" From: "ilovedomain" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 Feb 2000 02:29:31 +0900 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Áß±¹/½Å±Ô µµ¸ÞÀÎ ¾È³» Content-Type: text/html Content-Transfer-Encoding: base64 Status: R X-Status: N PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj4NCjxESVYgYWxpZ249Y2VudGVyPg0K PFRBQkxFIGJvcmRlcj0xIGJvcmRlckNvbG9yPSMzNzhkYmIgY2VsbFBhZGRpbmc9MCBjZWxs U3BhY2luZz0wIGhlaWdodD0iMTAwJSIgDQp3aWR0aD0xMDA+DQogIDxUQk9EWT4NCiAgPFRS Pg0KICAgIDxURCBiZ0NvbG9yPSNmY2ZjZmMgdkFsaWduPXRvcD4NCiAgICAgIDxESVYgYWxp Z249bGVmdD48L0RJVj4NCiAgICAgIDxUQUJMRSBib3JkZXI9MCBjZWxsUGFkZGluZz0wIGNl bGxTcGFjaW5nPTAgd2lkdGg9NTgwPg0KICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUj4N CiAgICAgICAgICA8VEQgYmdDb2xvcj0jMzc4ZGJiIGNvbFNwYW49NT4mbmJzcDs8L1REPjwv VFI+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8VEQgY29sU3Bhbj01Pg0KICAgICAgICAg ICAgPERJViBhbGlnbj1sZWZ0PjwvRElWPg0KICAgICAgICAgICAgPFRBQkxFIGJvcmRlcj0w IGNlbGxQYWRkaW5nPTAgY2VsbFNwYWNpbmc9MCB3aWR0aD01ODA+DQogICAgICAgICAgICAg IDxUQk9EWT4NCiAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0 aD0zOT48QSBocmVmPSJodHRwOi8vaWxvdmVkb21haW4uY29tLyIgDQogICAgICAgICAgICAg ICAgICB0YXJnZXQ9X2JsYW5rPjxJTUcgYm9yZGVyPTAgDQogICAgICAgICAgICAgICAgICBz cmM9Imh0dHA6Ly93d3cuaWxvdmVkb21haW4uY29tL2ltYWdlcy9sb2dvLmdpZiI+PC9BPjwv VEQ+DQogICAgICAgICAgICAgICAgPFREIHJvd1NwYW49MiB3aWR0aD0xNDI+PEk+PEZPTlQg DQogICAgICAgICAgICAgICAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJp ZiI+PEI+PEZPTlQgY29sb3I9I2MwYzBjMCANCiAgICAgICAgICAgICAgICAgIHNpemU9NT48 L0ZPTlQ+PC9CPjwvRk9OVD48L0k+PC9URD4NCiAgICAgICAgICAgICAgICA8VEQgcm93U3Bh bj0yIHdpZHRoPTM5OT4NCiAgICAgICAgICAgICAgICAgIDxIUiBhbGlnbj1sZWZ0IFNJWkU9 MSB3aWR0aD0iOTglIj4NCiAgICAgICAgICAgICAgICA8L1REPjwvVFI+DQogICAgICAgICAg ICAgIDxUUj4NCiAgICAgICAgICAgICAgICA8VEQgd2lkdGg9Mzk+Jm5ic3A7PC9URD48L1RS PjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8 VEQgd2lkdGg9MTA+Jm5ic3A7PC9URD4NCiAgICAgICAgICA8VEQgY29sU3Bhbj00Pg0KICAg ICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+vsiz58fPvLy/5C4gvsbAzLevuuq1tbjewM4g wNS0z7TZICE8L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8RElWPjxGT05UIHNpemU9Mj48 QlI+Jm5ic3A7PC9ESVY+PC9GT05UPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+ x/bA5yC+xsDMt6+66rW1uN7Azr+hvK20wiA8Qj48Rk9OVCBjb2xvcj0jMDAwMGZmPsHfsbkg DQogICAgICAgICAgICC1tbjewM4oY29tLmNuKTwvRk9OVD48L0I+te63z7D6IDxCPjxGT05U IGNvbG9yPSMwMDAwZmY+vcWx1CCxucGmIA0KICAgICAgICAgICAgtbW43sDOKC5iaXovLmlu Zm8vLnByby8ubmFtZSk8L0ZPTlQ+PC9CPiC17rfPIL+5vuAgvK268b26uKYgwaaw+MfPsO0g DQogICAgICAgICAgICDA1r3AtM+02S48L0ZPTlQ+PC9ESVY+DQogICAgICAgICAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgc2l6 ZT0yPjxTVFJPTkc+sc2758DHILvzyKM8L1NUUk9ORz64piZuYnNwO7z2vu/AxyANCiAgICAg ICAgICAgIMHfsbkmbmJzcDux4r73Jm5ic3A7udcgx9GxuSCx4r73wMc8U1RST05HPiC1v8G+ ILvzyKO3zrrOxc0gDQogICAgICAgICAgICC6uMijPC9TVFJPTkc+x8+9yr3Dv+QhISE8L0ZP TlQ+PC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNp emU9Mj48U1RST05HPri5wLogx9GxuSCx4r73w7zAxyDIuLvnuO3AzCDAzLnMIMW4wM6/oSDA x8fYIA0KICAgICAgICAgICAgte63z7XHvu7B+CC788XCwNS0z7TZLjwvU1RST05HPjwvRk9O VD48L0RJVj4NCiAgICAgICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgICA8 RElWPiZuYnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IKHhJm5ic3A7IDxGT05UIA0KICAgICAgICAgICAgY29sb3I9 IzAwODA4MD48U1RST05HPsioxuTAzMH2IMGmwNsmbmJzcDsgudcgwd+5riDIqMbkwMzB9iDB psDbIA0KICAgICAgICAgICAgvsizuzwvU1RST05HPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQog ICAgICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCAN CiAgICAgICAgICAgIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiANCiAgICAgICAgICAgICdJTE9WRURPTUFJTi5DT00n wLogyKjG5MDMwfYgwabA2yC51yDB37muIMioxuTAzMH2uKYgwabA28fPsO0gwNa9wLTPtNku PC9GT05UPjwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48Rk9OVCANCiAgICAgICAgICAgIHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAgICAgICDGr8j3LCDB37muIMioxuTAzMH2 tMIgx/bB9iDD4r3FwMcgwPy5riDAzrfCILnXIMHfsbkgx9HBtyDAzrfCwLsgxevH2CDBpsDb tcew7SDA1jwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgIDxESVY+PEZPTlQgDQogICAgICAg ICAgICBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICAgICAgvu4gPC9GT05U PjxGT05UIHNpemU9Mj6wocDlIMHfsbnA+8DOJm5ic3A7yKjG5MDMwfawoSC1ySANCiAgICAg ICAgICAgILDNwNS0z7TZLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0RJVj4N CiAgICAgICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgICA8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgICA8RElWPjxGT05UIHNp emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgoeE8Rk9OVCANCiAgICAgICAgICAgIGNv bG9yPSMwMDgwMDA+PFNUUk9ORz4mbmJzcDsgPEZPTlQgY29sb3I9IzAwODA4MD7B37G5ILW1 uN7AziANCiAgICAgICAgICAgIL7Is7smbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L0ZP TlQ+PC9TVFJPTkc+PC9GT05UPjwvRk9OVD48L0RJVj48L1REPjwvVFI+DQogICAgICAgIDxU Uj4NCiAgICAgICAgICA8VEQgd2lkdGg9MTA+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48 L1REPg0KICAgICAgICAgIDxURCB3aWR0aD0xNj48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05U PjwvVEQ+DQogICAgICAgICAgPFREIHdpZHRoPTEzPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZP TlQ+PC9URD4NCiAgICAgICAgICA8VEQgY29sU3Bhbj0yIHdpZHRoPTU0MT48Rk9OVCBzaXpl PTI+Jm5ic3A7PC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgPFRSPg0KICAgICAgICAgIDxU RCB3aWR0aD0xMD48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+DQogICAgICAgICAg PFREIHdpZHRoPTE2PjxGT05UIHNpemU9Mj4tPC9GT05UPjwvVEQ+DQogICAgICAgICAgPFRE IGNvbFNwYW49Mz48Rk9OVCBjb2xvcj0jMDAzMzY2IHNpemU9Mj48Qj5DTlvB37G5XbW1uN7A zsDMtvU/IA0KICAgICAgICAgIDwvQj48L0ZPTlQ+PC9URD48L1RSPg0KICAgICAgICA8VFI+ DQogICAgICAgICAgPFREIGhlaWdodD00NiB3aWR0aD0xMD48Rk9OVCBzaXplPTI+Jm5ic3A7 PC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIGhlaWdodD00NiB3aWR0aD0xNj48Rk9OVCBz aXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIGhlaWdodD00NiB3aWR0 aD0xMz48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIGNv bFNwYW49MiBoZWlnaHQ9NDYgd2lkdGg9NTQxPg0KICAgICAgICAgICAgPFRBQkxFIGJvcmRl cj0wIGNlbGxQYWRkaW5nPTUgY2VsbFNwYWNpbmc9MCB3aWR0aD0iMTAwJSI+DQogICAgICAg ICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgIDxU RD48Rk9OVCBzaXplPTI+x9GxucC7ILTrx6XHz7TCILG5sKEgtbW43sDOwLogY28ua3IgwMy4 5yDB37G5wLsgtOvHpcfPtMIgsbmwoSC1tbjewM7AuiANCiAgICAgICAgICAgICAgICAgIGNv bS5jbiDA1LTPtNkuIENOwLogQ0hJTkHAxyC/tbmuIA0KICAgICAgICDAzLTPvMjA1LTPtNku PC9GT05UPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9URD48L1RSPg0KICAgICAgICA8 VFI+DQogICAgICAgICAgPFREIHdpZHRoPTEwPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+ PC9URD4NCiAgICAgICAgICA8VEQgd2lkdGg9MTY+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9O VD48L1REPg0KICAgICAgICAgIDxURCB3aWR0aD0xMz48Rk9OVCBzaXplPTI+Jm5ic3A7PC9G T05UPjwvVEQ+DQogICAgICAgICAgPFREIGNvbFNwYW49MiB3aWR0aD01NDE+PEZPTlQgc2l6 ZT0yPiZuYnNwOzwvRk9OVD48L1REPjwvVFI+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8 VEQgd2lkdGg9MTA+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1REPg0KICAgICAgICAg IDxURCB3aWR0aD0xNj48Rk9OVCBzaXplPTI+LTwvRk9OVD48L1REPg0KICAgICAgICAgIDxU RCBjb2xTcGFuPTM+PEZPTlQgY29sb3I9IzAwMzM2NiBzaXplPTI+PEI+Q05bwd+xuV21tbje wM7AxyANCiAgICAgICAgICDHyr/kvLo8L0I+PC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAg PFRSPg0KICAgICAgICAgIDxURCB3aWR0aD0xMD48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05U PjwvVEQ+DQogICAgICAgICAgPFREIHdpZHRoPTE2PjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZP TlQ+PC9URD4NCiAgICAgICAgICA8VEQgd2lkdGg9MTM+PEZPTlQgc2l6ZT0yPiZuYnNwOzwv Rk9OVD48L1REPg0KICAgICAgICAgIDxURCBjb2xTcGFuPTIgd2lkdGg9NTQxPg0KICAgICAg ICAgICAgPFRBQkxFIGJvcmRlcj0wIGNlbGxQYWRkaW5nPTUgY2VsbFNwYWNpbmc9MCB3aWR0 aD0iOTklIj4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQog ICAgICAgICAgICAgICAgPFREPg0KICAgICAgICAgICAgICAgICAgPERJViBzdHlsZT0iVEVY VC1BTElHTjoganVzdGlmeSI+PEZPTlQgc2l6ZT0yPjxCPjEuPC9CPiC1tbjewM4gDQogICAg ICAgICAgICAgICAgICC17rfPwLogwM7FzbPdILrxwe60z726wMcgw7kgvcPA28DUtM+02S48 Qj4gJ8HBwLogtbW43sDOwMcgyK66uLTCIMDOxc2z3SC68cHutM+9usDHIMWrILnYw7UnPC9C PsDMtvO0wiANCiAgICAgICAgICAgICAgICAgILi7wMwgwNa17cDMILW1uN7AziDIrrq4tMIg wM7FzbPdILvnvvfAxyDDyrHiv6EgwNa+7rytIMWrILrxwd/AuyDC98H2x9W0z7TZLiA8Rk9O VCANCiAgICAgICAgICAgICAgICAgIGNvbG9yPSMwMDMzNjY+tfu287ytIMHfsbkgwfjD4sC7 IL+wtc6/oSC10CCx4r73ILbHtMIgsLPAzsDMtvO46SDHyrz2wPvAuLfOIMfYtOcgtbW43sDO wLsgyK66uMfPv6m+3yANCiAgICAgICAgICAgICAgICAgIMfVtM+02S48L0ZPTlQ+IMHBwLog tbW43sDOwLsgucy4riDIrrq4x8+wxbOqLCDD38jEv6Egu/2x5iC89iDA1rTCILmuwabAxyC8 0sH2uKYgu+fA/L+hILnmwfbHz7+pvt8gDQogICAgICAgICAgICAgICAgICDH1bTPtNkuIDxC Uj48L0ZPTlQ+PEI+PEJSPjxGT05UIHNpemU9Mj4yLjwvRk9OVD48L0I+PEZPTlQgc2l6ZT0y PiANCiAgICAgICAgICAgICAgICAgIMHfsbkgvcPA5cC6IDxCPifH9sDnILOyvsYgwNa0wiDA r8DPx9EgsMW06yC9w8DlJzwvQj7AzLbzILrSuLO0z7TZLiDB37G5wMcgwM7FzbPdIMDOsbiw oSDB9rOtx9gguLu/obTCIA0KICAgICAgICAgICAgICAgICAgMsO1MjUwuLi47cC4t84gsd7B 9cfftNmw7SDHz7jnPEZPTlQgY29sb3I9IzAwMzM2Nj4gMjAwNLPisrK0wiAxvu8yw7W4uLjt PC9GT05UPr+hIA0KICAgICAgICAgICAgICAgICAgtbW03sfSILDNwMy28yDH1bTPtNkuPC9G T05UPjwvRElWPg0KICAgICAgICAgICAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+DQogICAgICAgICAgICAgICAgICA8 RElWIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5Ij4mbmJzcDs8L0RJVj4NCiAgICAgICAg ICAgICAgICAgIDxESVYgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiPjxGT05UIHNpemU9 Mj48Rk9OVCANCiAgICAgICAgICAgICAgICAgIGNvbG9yPSMwMDMzNjY+PEI+PEZPTlQgY29s b3I9IzAwNjY2Nj4qILHNu+fAxyDB37G5tbW43sDOwLsgPEEgDQogICAgICAgICAgICAgICAg ICBocmVmPSJodHRwOi8vaWxvdmVkb21haW4uY29tLyI+PEZPTlQgDQogICAgICAgICAgICAg ICAgICBjb2xvcj0jMDA2NjY2Pr7GwMy3r7rqtbW43sDOPC9GT05UPjwvQT6/obytIMH2sd0g DQogICAgICAgICAgICAgICAgICDIrrq4x8+9yr3Dv+QhPC9GT05UPjwvQj48L0ZPTlQ+PEJS PjxCUj48Rk9OVCBjb2xvcj0jODYyNDMxPjxCPsHfsbm/obytwMcgDQogICAgICAgICAgICAg ICAgICDAzsXNs90gxsS/9rTCIENPTS5DTiDA1LTPtNkuIDwvQj48L0ZPTlQ+PC9GT05UPjwv RElWPg0KICAgICAgICAgICAgICAgICAgPFRBQkxFIGJvcmRlcj0wIGNlbGxQYWRkaW5nPTAg Y2VsbFNwYWNpbmc9MCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgICAgICAgICAgIDxUQk9E WT4NCiAgICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgICAgICAgIDxU RCB3aWR0aD0iNjklIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249cmln aHQ+PEZPTlQgc2l6ZT0yPi08L0ZPTlQ+PC9ESVY+PC9URD4NCiAgICAgICAgICAgICAgICAg ICAgICA8VEQgd2lkdGg9IjMxJSI+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48QSANCiAg ICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHA6Ly93d3cuaWxvdmVkb21haW4uY29t L21lbnUyL2luZGV4Lmh0bWwiIA0KICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PV9i bGFuaz48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj7B37G5IA0KICAgICAgICAgICAgICAg ICAgICAgICAgtbW43sDOte63z8fPseI8L0ZPTlQ+PC9BPjwvVEQ+PC9UUj48L1RCT0RZPjwv VEFCTEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQogICAgICAgIDxU Uj4NCiAgICAgICAgICA8VEQgd2lkdGg9MTA+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48 L1REPg0KICAgICAgICAgIDxURCBjb2xTcGFuPTQ+PEZPTlQgc2l6ZT0yPg0KICAgICAgICAg ICAgPEhSIGNvbG9yPSMzNzhkYmIgU0laRT0xIHdpZHRoPSI5OCUiPg0KICAgICAgICAgICAg PC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgPFRSPg0KICAgICAgICAgIDxURCB3aWR0aD0x MD48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIHdpZHRo PTE2PjxCUj48Rk9OVCBzaXplPTI+LTwvRk9OVD48L1REPg0KICAgICAgICAgIDxURCBjb2xT cGFuPTM+PEZPTlQgY29sb3I9IzgzNGIyMz48Qj48QlI+PEZPTlQgc2l6ZT0yPr3FsdQgsbnB piC1tbjewM4gte63zyANCiAgICAgICAgICAgIL+5vuC9xcO7ILTru/Mgs9fA0zwvRk9OVD48 L0I+PC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgPFRSPg0KICAgICAgICAgIDxURCB3aWR0 aD0xMD48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+DQogICAgICAgICAgPFREIHdp ZHRoPTE2PjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9URD4NCiAgICAgICAgICA8VEQg d2lkdGg9MTM+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1REPg0KICAgICAgICAgIDxU RCBjb2xTcGFuPTIgd2lkdGg9NTQxPg0KICAgICAgICAgICAgPFRBQkxFIGJvcmRlcj0wIGNl bGxQYWRkaW5nPTUgY2VsbFNwYWNpbmc9MCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgICAg IDxUQk9EWT4NCiAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgIDxURD48Rk9O VCBzaXplPTI+LmJpei8uaW5mby8ucHJvLy5uYW1lIA0KICAgICAgICAgICAgPC9GT05UPjwv VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9URD48L1RSPg0KICAgICAgICA8VFI+DQogICAg ICAgICAgPFREIHdpZHRoPTEwPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9URD4NCiAg ICAgICAgICA8VEQgd2lkdGg9MTY+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1REPg0K ICAgICAgICAgIDxURCB3aWR0aD0xMz48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+ DQogICAgICAgICAgPFREIGNvbFNwYW49MiB3aWR0aD01NDE+PEZPTlQgc2l6ZT0yPiZuYnNw OzwvRk9OVD48L1REPjwvVFI+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8VEQgd2lkdGg9 MTA+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1REPg0KICAgICAgICAgIDxURCB3aWR0 aD0xNj48Rk9OVCBzaXplPTI+LTwvRk9OVD48L1REPg0KICAgICAgICAgIDxURCBjb2xTcGFu PTM+PEZPTlQgY29sb3I9IzgzNGIyMyBzaXplPTI+PEI+vcWx1CC1tbjewM4gte63zyCws73D wM8gDQogICAgICAgICAgPC9CPjwvRk9OVD48L1REPjwvVFI+DQogICAgICAgIDxUUj4NCiAg ICAgICAgICA8VEQgd2lkdGg9MTA+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1REPg0K ICAgICAgICAgIDxURCB3aWR0aD0xNj48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvVEQ+ DQogICAgICAgICAgPFREIHdpZHRoPTEzPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9U RD4NCiAgICAgICAgICA8VEQgY29sU3Bhbj0yIHdpZHRoPTU0MT4NCiAgICAgICAgICAgIDxU QUJMRSBib3JkZXI9MCBjZWxsUGFkZGluZz01IGNlbGxTcGFjaW5nPTAgd2lkdGg9IjEwMCUi Pg0KICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUj4NCiAgICAgICAg ICAgICAgICA8VEQ+PEZPTlQgc2l6ZT0yPjIwMDGz4iC787ndseIgPEJSPjxCUj48Qj48Rk9O VCBjb2xvcj0jMDA4MDgwPiogDQogICAgICAgICAgICAgICAgICCxzbvnwMcgvcWx1CCxucGm ILW1uN7AzsC7IDwvRk9OVD48QSBocmVmPSJodHRwOi8vaWxvdmVkb21haW4uY29tLyI+PEZP TlQgDQogICAgICAgICAgICAgICAgICBjb2xvcj0jMDA4MDgwPr7GwMy3r7rqtbW43sDOPC9G T05UPjwvQT48Rk9OVCBjb2xvcj0jMDA4MDgwPr+hvK0gwfax3SANCiAgICAgICAgICAgICAg ICAgIMiuurjHz73KvcO/5CE8L0ZPTlQ+PC9CPiA8L0ZPTlQ+PC9URD48L1RSPjwvVEJPRFk+ PC9UQUJMRT4NCiAgICAgICAgICAgIDxUQUJMRSBib3JkZXI9MCBjZWxsUGFkZGluZz0wIGNl bGxTcGFjaW5nPTAgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgICAgICA8VEJPRFk+DQogICAg ICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjY5JSI+DQogICAg ICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIHNpemU9Mj4tPEJSPjwvRk9O VD48L0RJVj48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMzElIj48Rk9OVCBz aXplPTI+Jm5ic3A7PC9GT05UPjxBIA0KICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cDov L3d3dy5pbG92ZWRvbWFpbi5jb20vbWVudTIvaW5kZXguaHRtbCIgDQogICAgICAgICAgICAg ICAgICB0YXJnZXQ9X2JsYW5rPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPr3FsdQmbmJz cDu1tbjewM4gDQogICAgICAgICAgICAgICAgICC/ub7gx8+x4jwvRk9OVD48L0E+PEJSPjwv VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1RE PjwvVFI+DQogIDxUUj4NCiAgICA8VEQgYmdDb2xvcj0jMzc4ZGJiIGhlaWdodD00MCB2QWxp Z249Y2VudGVyPg0KICAgICAgPERJViBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9I2Y1ZjNl Nz48Rk9OVCBzaXplPTI+Y29udGFjdCB1cyBhdCA8L0ZPTlQ+PEEgDQogICAgICBocmVmPSJt YWlsdG86d2VibWFzdGVyQGlsb3ZlZG9tYWluLmNvbSI+PEZPTlQgY29sb3I9I2ZmZmZmZiAN CiAgICAgIHNpemU9Mj53ZWJtYXN0ZXJAaWxvdmVkb21haW4uY29tPC9GT05UPjwvQT48L0ZP TlQ+PC9ESVY+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0RJVj48L0ZPTlQ+DQoKPGJy PgoKPCEtLSB8Kip8YmVnaW4gZWdwIGh0bWwgYmFubmVyfCoqfCAtLT4KCjx0YWJsZSBib3Jk ZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTI+Cjx0ciBiZ2NvbG9yPSNGRkZGQ0M+ Cjx0ZCBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0iLTEiIGNvbG9yPSMwMDMzOTk+PGI+WWFo b28hIEdyb3VwcyBTcG9uc29yPC9iPjwvZm9udD48L3RkPgo8L3RyPgo8dHIgYmdjb2xvcj0j RkZGRkZGPgo8dGQgd2lkdGg9NDcwPjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vTT0x NjgzODEuMTM3Njc4Ny4yOTY1Mjg1LjIvRD1lZ3JvdXBtYWlsL1M9MTcwMDAwNTM3ODpOL0E9 NjE4OTg1Lz9odHRwOi8vc3Vic2NyaWJlLndzai5jb20veWFob28yIiB0YXJnZXQ9Il90b3Ai PjxpbWcgd2lkdGg9NDY4IGhlaWdodD02MCBzcmM9Imh0dHA6Ly91cy5hMS55aW1nLmNvbS91 cy55aW1nLmNvbS9hLy9kby9kb3dqb25lcy8xMDIuZ2lmIiBhbHQ9IkNsaWNrIGhlcmUgdG8g c3Vic2NyaWJlLiIgYm9yZGVyPTA+PGJyPkNsaWNrIGhlcmUgdG8gc3Vic2NyaWJlLjwvYT48 L3RkPgo8L3RyPgo8dHI+PHRkPjxpbWcgYWx0PSIiIHdpZHRoPTEgaGVpZ2h0PTEgc3JjPSJo dHRwOi8vdXMuYWRzZXJ2ZXIueWFob28uY29tL2w/TT0xNjgzODEuMTM3Njc4Ny4yOTY1Mjg1 LjIvRD1lZ3JvdXBtYWlsL1M9MTcwMDAwNTM3ODpOL0E9NjE4OTg1L3JhbmQ9NTA5NjMyODg5 Ij48L3RkPjwvdHI+CjwvdGFibGU+Cgo8IS0tIHwqKnxlbmQgZWdwIGh0bWwgYmFubmVyfCoq fCAtLT4KCgoKPGJyPgo8dHQ+WW91ciB1c2Ugb2YgWWFob28hIEdyb3VwcyBpcyBzdWJqZWN0 IHRvIHRoZSA8YSBocmVmPSJodHRwOi8vZG9jcy55YWhvby5jb20vaW5mby90ZXJtcy8iPllh aG9vISBUZXJtcyBvZiBTZXJ2aWNlPC9hPi48L3R0Pgo8L2JyPgoKPC9CT0RZPg0KPC9IVE1M Pg0K From Yann GUIDON Mon Apr 2 20:47:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA01539 for ; Tue, 3 Apr 2001 01:57:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 03 Apr 2001 01:57:49 +0200 (MEST) Received: (qmail 7966 invoked by uid 0); 2 Apr 2001 18:57:05 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx04) with SMTP; 2 Apr 2001 18:57:05 -0000 X-eGroups-Return: sentto-1101623-2620-986237826-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 02 Apr 2001 18:57:08 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_0_1); 2 Apr 2001 18:57:06 -0000 Received: (qmail 79696 invoked from network); 2 Apr 2001 18:55:11 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 2 Apr 2001 18:55:11 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 2 Apr 2001 19:56:15 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA25987; Mon, 2 Apr 2001 11:54:58 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR89B8; Mon, 2 Apr 2001 20:00:46 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AC8C950.E9D30E95@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: rmaniwa@cmp.com References: <85256A22.00612DAC.00@NotesSMTP-01.cmp.com> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 02 Apr 2001 20:47:44 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: F-CPU Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N rmaniwa@cmp.com wrote:

> posted
>
> tets

Thank you very much !

> Yann GUIDON <yann_guidon@mentorg.com> on 04/02/2001 05:40:47 AM
>
> Please respond to whygee@f-cpu.org
>
> To:   tmaniwa@cmp.com
> cc:
> bcc:
> Subject:  F-CPU
>
> hello,
>
> Concerning http://www.eedesign.com/resources/opensourcelinks.html
> I would like to let you know about the F-CPU project, aiming
> at developing the first fully SIMD superpipelined, GPL'd CPU
> for 64-bit and larger platforms. The official site is located
> at http://www.f-cpu.org, can you add this link to your page ?
> thanks and have a nice day,
>
> YG
>
> speaking for himself
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Apr 4 06:12:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00320 for ; Wed, 4 Apr 2001 19:19:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 04 Apr 2001 19:19:52 +0200 (MEST) Received: (qmail 31209 invoked by uid 0); 4 Apr 2001 04:36:37 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx10) with SMTP; 4 Apr 2001 04:36:37 -0000 X-eGroups-Return: sentto-1101623-2621-986358995-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 04 Apr 2001 04:36:36 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 4 Apr 2001 04:36:35 -0000 Received: (qmail 528 invoked from network); 4 Apr 2001 04:36:34 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 4 Apr 2001 04:36:34 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 4 Apr 2001 05:37:38 -0000 Received: from jetnet.ab.ca (dialin56.jetnet.ab.ca [207.153.6.56]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA25543 for ; Tue, 3 Apr 2001 22:36:32 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACA9F1A.A8C6460B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Apr 2001 22:12:10 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] April humor Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www.anime.net/~goemon/rhl.html.
The irony is lunix most likely could be ported to a 1802 since it
runs on 6502's. Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Wed Apr 4 23:30:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA01663 for ; Thu, 5 Apr 2001 03:07:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 05 Apr 2001 03:07:00 +0200 (MEST) Received: (qmail 10762 invoked by uid 0); 4 Apr 2001 22:16:08 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx14) with SMTP; 4 Apr 2001 22:16:08 -0000 X-eGroups-Return: sentto-1101623-2622-986422550-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 04 Apr 2001 22:15:52 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 4 Apr 2001 22:15:48 -0000 Received: (qmail 78070 invoked from network); 4 Apr 2001 22:15:43 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 4 Apr 2001 22:15:43 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.173.46) by mta3 with SMTP; 4 Apr 2001 23:16:46 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id A0B1A9E5A for ; Wed, 4 Apr 2001 23:30:50 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3ACB928A.A69C75EC@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: "f-cpu@yahoogroups.com" From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 04 Apr 2001 23:30:50 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

-------- Original Message --------
Subject: Re: About the F-cpu project
Date: Wed, 4 Apr 2001 14:46:05 -0700 (PDT)
From: Kanoj Sarcar <>
To:
CC:  (Kanoj Sarcar)

>
> Hello Kanoj,
>
> I just read a resume of the last kernel metting on Linuxcare. I see that
> you try to defend the use of the NUMA architecture but some participant
> aren't so happy about. I would to know where to find there argument. And
> what is your's.

Hi Nicolas,

I don't think as Linux kernel developers, it is our place to defend,
or attack, use of NUMA architecture. As Linux developers and proponents,
we need to decide one thing: vendors are coming out with NUMA machines,
should Linux support these NUMA machines, alongwith the extra set of
features needed to optimize performance on them, or not?

Of course, different people had different opinions about that in the
kernel meeting.

I don't think many people deny that NUMA (more specifically, ccNUMA)
is needed to solve a class of problems, because, as you said, the
single bus typical in SMP systems soon get to be a bottleneck. The
other option is to go to clusters, and people have had long discussions
on which is a better programming paradigm. And which is the easier one
to build in support for the kernel. Cluster based sharing needs
distributed locking schemes, which are costly and complex.

>
> The fcpu project (www.f-cpu.org) is a utopic project to create a GPL
> cpu. The first version will be a simple one-way RISC processor but with
> long pipeline, 64 bits registers and based on SIMD concept. In the
> future, we could extand the design to 2 or 4 ways but there are some
> idea to make multicpu system.

Good, I was wondering just the other day why no one had started a
open source processor project. I might even look at what you guys
are up to, but of course, I have no hardware design experience, and
have almost forgotten how verilog works after getting out of school.

>
> SMP are the easiest way but memory bottleneck became worst and worst. So
> NUMA or NORMA design seems to be a good answers to this problem. But the

Do you mean non-ordered memory access by NORMA? Whereas it is a nice
concept, I think many people will find programming in this model quite
hard. Just my opinion, of course. If you are curious, the SGI ccNUMA
machines can actually be put in loose consistency mode, but after
experimenting with that a little, SGI decided putting the systems in
stronger consistency modes is much easier.

Basically, I keep hearing that a lot of research is happening on
the benefits of NUMA and into future architectures. CMP (chip
multiprocessor, with multiple chips on a die, possibly sharing
caches), and nested NUMA (multiple cpu/memory groupings on a
single board) seem to be the next wave.

> task are udge, and i don't see so many details. For me, all things as
> memory management, garbage collector, scheduler, task communication
> (implemantation of SystemV shared memory) are a so udge problem that i
> believe as Tannenbaum that it's very easy to make a 12 node computer
> slower than a 1 node machine. What do think ?
>
> In the other hand we create a new design, so, there isn't any historical
> background to keep. I would like to know what kind of typical algorythme
> are often used in kernel developpement. The idea is to see what could be
> down to improve the efficiency of the cpu (special instructions...).
> Have you never thought "If they did that, it will be so simple !" ? If a
> multicpu system could be more efficient than usual one, maybe we could
> avoid trying to make 20 ways cpu, so the system will more easly
> expendable and the cpu cheaper.

Right. Building in too much feature is costly, too less is bad too.
Examples: the hardware updated dirty/accessed bits in i386 are quite
complicated to program in SMP environment. Much better to go with
MIPS like software managed dirty/accessed bits. On the other hand,
keeping the icache coherent with the dcache is probably overkill - the
os can easily make sure that things are coherent whenever it writes
to certain pages that it expects to execute out of soon (MIPS does
not keep dcache coherent with icache). Being able to do fast
translations
using TLBs is good ... ia64 has this, i386 did have tlbs, but software
did not have much transparency into it.

The tradeoff seems to be that more hardware features that you make
visible to software, the more complicated the software needs to be.
Finally, it becomes a tradeoff between hardwiring something complicated,
vs having the software deal with it.

Kanoj

>
> Regards,
> Nicolas Boulay
>
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Apr 6 00:30:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05512 for ; Fri, 6 Apr 2001 01:55:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 01:55:10 +0200 (MEST) Received: (qmail 7830 invoked by uid 0); 5 Apr 2001 23:15:00 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx10) with SMTP; 5 Apr 2001 23:15:00 -0000 X-eGroups-Return: sentto-1101623-2623-986512497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hn.egroups.com with NNFMP; 05 Apr 2001 23:14:58 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 5 Apr 2001 23:14:56 -0000 Received: (qmail 283 invoked from network); 5 Apr 2001 23:14:55 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 5 Apr 2001 23:14:55 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.162.218) by mta2 with SMTP; 5 Apr 2001 23:14:53 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 3177B9E5D for ; Fri, 6 Apr 2001 00:30:05 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3ACCF1ED.A3C2ACC3@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Apr 2001 00:30:05 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www-dsg.stanford.edu/papers/cachekernel/main.html

It's a paper about cache kernel it speak about that microkernel failed
to be as fast as monolithic kernel as linux. The microkernel work by
sending message. We could imagine that read and write on the same memory
location could make some memory protection problem(that's the goal of
microkernel).
In the same time, the director of the real time lab where i work (a
little one:) launch the idea to make the usual object encapsulation in
hardware by using the MMU. The idea is to protect data between objects.
I think it could "easy" to do that by having a specific "call"
instruction for methode which said which object we use. And we can made
a specific linear adressing for data segment for each object(you want to
protect, because one page per object could became heavy!).
The specific call object could change for exemple some MSB byte of the
physical adress. It's indicate a particular object (it's number). The
parameters are in a common area used for the stack (otherwise you will
have a problem to read it).

I don't think it complicate to much the MMU. But it seems to be a great
concept to implement in hardware : the object as imagined in software.

nicO
Yahoo! Groups Sponsor
E*TRADE. It's your money.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jecel Assumpcao Jr Fri Apr 6 03:01:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA06218 for ; Fri, 6 Apr 2001 06:34:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 06:34:01 +0200 (MEST) Received: (qmail 29656 invoked by uid 0); 5 Apr 2001 23:58:48 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx10) with SMTP; 5 Apr 2001 23:58:48 -0000 X-eGroups-Return: sentto-1101623-2624-986515127-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 05 Apr 2001 23:58:47 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 5 Apr 2001 23:58:45 -0000 Received: (qmail 93610 invoked from network); 5 Apr 2001 23:58:45 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 5 Apr 2001 23:58:45 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta1 with SMTP; 5 Apr 2001 23:58:44 -0000 Received: from gandalf.merlintec.com (gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id WAA27269 for ; Thu, 5 Apr 2001 22:07:10 -0300 Organization: Merlintec Computers X-Mailer: KMail [version 1.1.99] To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> In-Reply-To: <3ACCF1ED.A3C2ACC3@seul.org> Message-Id: <01040521010404.00861@gandalf.merlintec.com> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 5 Apr 2001 21:01:04 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thursday 05 April 2001 18:30, Nicolas wrote:
> It's a paper about cache kernel it speak about that microkernel
> failed to be as fast as monolithic kernel as linux.

My experience with QNX and a microkernel OS I designed myself was that
both performed much better than Linux. Mach isn't the only microkernel
ever created....

> I don't think it complicate to much the MMU. But it seems to be a
> great concept to implement in hardware : the object as imagined in
> software.

It is a great idea, which is why Intel put it in their iAPX432
processor (and a simplified version made it into the 286). I think that
Mushroom's implementation was much nicer:

  http://www.wolczko.com/mushroom/index.html

There was also the Rekursive and the IBM AS/400. And my own design, as
always ;-)

-- Jecel
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Fri Apr 6 00:40:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA06224 for ; Fri, 6 Apr 2001 06:34:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 06:34:02 +0200 (MEST) Received: (qmail 26455 invoked by uid 0); 6 Apr 2001 01:27:13 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx24) with SMTP; 6 Apr 2001 01:27:13 -0000 X-eGroups-Return: sentto-1101623-2625-986520430-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 06 Apr 2001 01:27:11 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 01:27:09 -0000 Received: (qmail 89830 invoked from network); 6 Apr 2001 01:27:08 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 Apr 2001 01:27:08 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 6 Apr 2001 02:28:12 -0000 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA00451 for ; Thu, 5 Apr 2001 19:27:06 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACCF451.2FBFC74@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Apr 2001 16:40:17 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Jecel Assumpcao Jr wrote:
>
> It is a great idea, which is why Intel put it in their iAPX432
> processor (and a simplified version made it into the 286). I think that
> Mushroom's implementation was much nicer:

I think good communication between the hardware, software and OS designers
is very important. Blindly putting features here and there is not the
best way to go, or cutting corners. The DOS serial port comes to mind
as poorly designed hardware (tri-state on the IRQ line) and stupid NON -
INTERRUPT
driven I/O. Adding OS features is sometimes useful for CPU hardware, and
other times adding buffered I/O is better.

>   http://www.wolczko.com/mushroom/index.html
>
> There was also the Rekursive and the IBM AS/400. And my own design, as
> always ;-)


Feel creative with lots of free time. I have (in development) a
24 bit CPU that needs a Free OS and has a whopping 8192 bytes for it.
:-)

> -- Jecel
Ben.
PS. No rush  for the OS as I still have to find a low cost paper tape
reader and punch for MASS STORAGE and a glass TTY for display (with lowercase).

-
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Fri Apr 6 11:33:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA07383 for ; Fri, 6 Apr 2001 18:35:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 18:35:54 +0200 (MEST) Received: (qmail 1817 invoked by uid 0); 6 Apr 2001 09:33:27 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx14) with SMTP; 6 Apr 2001 09:33:27 -0000 X-eGroups-Return: sentto-1101623-2626-986549605-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 06 Apr 2001 09:33:26 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 09:33:25 -0000 Received: (qmail 64575 invoked from network); 6 Apr 2001 09:33:24 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 Apr 2001 09:33:24 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 6 Apr 2001 10:34:28 -0000 Received: from localhost (graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA28880 for ; Fri, 6 Apr 2001 05:33:23 -0400 To: f-cpu@yahoogroups.com In-Reply-To: <3ACCF451.2FBFC74@jetnet.ab.ca> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 6 Apr 2001 05:33:22 -0400 (EDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

On Thu, 5 Apr 2001, Ben Franchuk wrote:

> PS. No rush  for the OS as I still have to find a low cost paper tape
> reader and punch for MASS STORAGE and a glass TTY for display (with lowercase).
>
> -
Whats wrong with a bunch of neons on the front panel and a spo? I miss the
clatter of typewriter-style output... glass TTY, pah :-)

graham
Yahoo! Groups Sponsor
Click here for Business information
Click here for Business information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Fri Apr 6 06:03:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA07440 for ; Fri, 6 Apr 2001 18:36:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 18:36:10 +0200 (MEST) Received: (qmail 4642 invoked by uid 0); 6 Apr 2001 13:45:13 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx05) with SMTP; 6 Apr 2001 13:45:13 -0000 X-eGroups-Return: sentto-1101623-2627-986564701-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 06 Apr 2001 13:45:02 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 13:45:00 -0000 Received: (qmail 67262 invoked from network); 6 Apr 2001 13:44:59 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 6 Apr 2001 13:44:59 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 6 Apr 2001 13:44:58 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA19366 for ; Fri, 6 Apr 2001 07:44:56 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACD400A.9488CA79@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 05 Apr 2001 22:03:22 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N graham@belegost.mit.edu wrote:
>
> On Thu, 5 Apr 2001, Ben Franchuk wrote:
>
> > PS. No rush  for the OS as I still have to find a low cost paper tape
> > reader and punch for MASS STORAGE and a glass TTY for display (with lowercase).
> >
> > -
> Whats wrong with a bunch of neons on the front panel and a spo? I miss the
> clatter of typewriter-style output... glass TTY, pah :-)
>
> graham

Nothing is wrong with a front panel just in my case I have
0001) FPGA card
0002) Download cable
0003) 2 32k x 8 Ram
0004) Maxim RS232 serial i/o buffer
0005) Old 486 for a terminal
0006) Small board to mount things on.
0007) IDE HD for later expansion
0010) Power supply
 
Neons,switches,Nixie tubes,and other nice stuff
just are not kicking around here.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri Apr 6 19:06:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA08132 for ; Fri, 6 Apr 2001 23:03:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 23:03:11 +0200 (MEST) Received: (qmail 27595 invoked by uid 0); 6 Apr 2001 17:51:38 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx07) with SMTP; 6 Apr 2001 17:51:38 -0000 X-eGroups-Return: sentto-1101623-2628-986579497-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 06 Apr 2001 17:51:37 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 17:51:36 -0000 Received: (qmail 13801 invoked from network); 6 Apr 2001 17:51:36 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 6 Apr 2001 17:51:36 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.189) by mta1 with SMTP; 6 Apr 2001 17:51:34 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 80CD29E63 for ; Fri, 6 Apr 2001 19:06:51 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3ACDF7AB.1C41B426@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Apr 2001 19:06:51 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Jecel Assumpcao Jr a =E9crit :
>
> On Thursday 05 April 2001 18:30, Nicolas wrote:
> > It's a paper about cache kernel it speak about that microkernel > > failed to be as fast as monolithic kernel as linux.
>
> My experience with QNX and a microkernel OS I designed myself was that=
> both performed much better than Linux. Mach isn't the only microkernel=
> ever created....
>

Sur but those microkernel have exactly the same feature ?

> > I don't think it complicate to much the MMU. But it seems to be a=
> > great concept to implement in hardware : the object as imagined i= n
> > software.
>
> It is a great idea, which is why Intel put it in their iAPX432
> processor (and a simplified version made it into the 286). I think tha= t
> Mushroom's implementation was much nicer:
>
>   htt= p://www.wolczko.com/mushroom/index.html
>
> There was also the Rekursive and the IBM AS/400. And my own design, as=
> always ;-)
>

Where can we found that ?

> -- Jecel
nicO
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Click
Click here to subscribe.
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Rares Marian Fri Apr 6 21:04:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA08138 for ; Fri, 6 Apr 2001 23:03:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 06 Apr 2001 23:03:12 +0200 (MEST) Received: (qmail 18466 invoked by uid 0); 6 Apr 2001 18:57:26 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx26) with SMTP; 6 Apr 2001 18:57:26 -0000 X-eGroups-Return: sentto-1101623-2629-986583441-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c3.egroups.com with NNFMP; 06 Apr 2001 18:57:22 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 18:57:19 -0000 Received: (qmail 59773 invoked from network); 6 Apr 2001 18:57:15 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 6 Apr 2001 18:57:15 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta2 with SMTP; 6 Apr 2001 18:57:15 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id 061B73B71; Fri, 6 Apr 2001 15:04:13 -0400 (EDT) To: f-cpu@yahoogroups.com Message-ID: <20010406150413.B19004@moonbase.res.wpi.net> References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> <3ACDF7AB.1C41B426@seul.org> In-Reply-To: <3ACDF7AB.1C41B426@seul.org>; from nico@seul.org on Fri, Apr 06, 2001 at 13:06:51 -0400 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 6 Apr 2001 15:04:13 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> Sur but those microkernel have exactly the same feature ?
> 

Not really.  Mach is to Emacs as QNX is to Jed.
Jed and Emacs are similar in function but the former is elegant while the
latter is a behemoth.
Emacs and Mach have sections of code that are as silly as drawing lines in
pencil one dot at a time.

Having said that, I find Emacs easier to use than Jed...  I'm glued to the
mouse.  If I weren't I might use vi.

Rares
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sat Apr 7 00:34:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00562 for ; Sat, 7 Apr 2001 17:47:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:02 +0200 (MEST) Received: (qmail 28016 invoked by uid 0); 6 Apr 2001 23:15:25 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx29) with SMTP; 6 Apr 2001 23:15:25 -0000 X-eGroups-Return: sentto-1101623-2630-986598913-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 06 Apr 2001 23:15:13 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 23:15:11 -0000 Received: (qmail 67860 invoked from network); 6 Apr 2001 23:15:11 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 6 Apr 2001 23:15:11 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 6 Apr 2001 23:15:10 -0000 Received: from jetnet.ab.ca (dialin46.jetnet.ab.ca [207.153.6.46]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA17333 for ; Fri, 6 Apr 2001 17:15:08 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACE4477.78D57C2E@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> <3ACDF7AB.1C41B426@seul.org> <20010406150413.B19004@moonbase.res.wpi.net> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Apr 2001 16:34:31 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> Having said that, I find Emacs easier to use than Jed...  I'm glued to the
> mouse.  If I weren't I might use vi.

Both I think need to be scrapped. I use NONE OF THE ABOVE as the text default
editing is still Gasp !!! TTY style I/O for most of LINUX.

--- WANTED A FREE (GNU) WINDOWS STYLE OS ---
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Alan Grimes Sat Apr 7 01:19:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00565 for ; Sat, 7 Apr 2001 17:47:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:03 +0200 (MEST) Received: (qmail 8046 invoked by uid 0); 6 Apr 2001 23:18:33 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx07) with SMTP; 6 Apr 2001 23:18:33 -0000 X-eGroups-Return: sentto-1101623-2631-986599105-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 06 Apr 2001 23:18:27 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 6 Apr 2001 23:18:25 -0000 Received: (qmail 77006 invoked from network); 6 Apr 2001 23:18:24 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 6 Apr 2001 23:18:24 -0000 Received: from unknown (HELO smtp01.mrf.mail.rcn.net) (207.172.4.60) by mta1 with SMTP; 6 Apr 2001 23:18:24 -0000 Received: from 66-44-66-226.s226.tnt7.lnhva.md.dialup.rcn.com ([66.44.66.226] helo=starpower.net) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14lfUl-0002I4-00 for f-cpu@yahoogroups.com; Fri, 06 Apr 2001 19:18:23 -0400 Message-ID: <3ACE4F12.43F49E77@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> <3ACDF7AB.1C41B426@seul.org> <20010406150413.B19004@moonbase.res.wpi.net> <3ACE4477.78D57C2E@jetnet.ab.ca> From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Apr 2001 19:19:46 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > --- WANTED A FREE (GNU) WINDOWS STYLE OS ---

I'm writing a paper which I will release in the next few weeks. I will
add Ben to my preview list (the list of people who will get to see it
first).

--
I hope you will excuse me but I don't really want to use an operating
system that was developed before I was born. (Unix)
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Apr 7 04:09:40 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00569 for ; Sat, 7 Apr 2001 17:47:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:03 +0200 (MEST) Received: (qmail 17431 invoked by uid 0); 7 Apr 2001 02:12:05 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx07) with SMTP; 7 Apr 2001 02:12:05 -0000 X-eGroups-Return: sentto-1101623-2632-986609523-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hj.egroups.com with NNFMP; 07 Apr 2001 02:12:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 7 Apr 2001 02:12:01 -0000 Received: (qmail 23555 invoked from network); 7 Apr 2001 02:12:01 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 7 Apr 2001 02:12:01 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 7 Apr 2001 02:12:01 -0000 Received: from f-cpu.org (nas4-181.pau.club-internet.fr [195.36.133.181]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA24529 for ; Sat, 7 Apr 2001 04:11:53 +0200 (MET DST) Message-ID: <3ACE76E4.2E290384@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Apr 2001 04:09:40 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] two cents ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi,

unfortunately in the last months i haven't been
much "active". with the laptop, it will starte
to evolve a bit, my todo list is growing exponentially.

Two f-cpu points that i'm investigating :

- the 4th condition : available conditions until now
    are zero, LSB and MSB (each being invertible).
    the missing code (in the two-bit field of the
    instructions that use it) is reserved.
   There are some possible usages for it, but one appears
    more important (the others have a limited usage) :
    floating point status or result. The condition
    returns true if the FP number in the register is
    OK, false otherwise : denormal, div by zero, NaN etc...

    I would like to know your opinions.

- Shuffling : This unit is still in the specification
    phase, as far as i remember. The question was asked
    by several people, whether a SIMD shifts a register
    with one count or if several shift counts were used.
    On top of that, i'm trying to figure out how the KNI
    (SSE) shuffle instruction works (i got a PIII laptop,
    so let's use it).

    Now it's a matter of feasibility and instruction set.
    A new version of the shift instructions (with one
    more S prefix, to say it's really, really SIMD) would
    be fine but how can it be implemented ? what would
    be the real use, at what cost ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Apr 7 04:09:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00573 for ; Sat, 7 Apr 2001 17:47:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:04 +0200 (MEST) Received: (qmail 3431 invoked by uid 0); 7 Apr 2001 02:12:08 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx23) with SMTP; 7 Apr 2001 02:12:08 -0000 X-eGroups-Return: sentto-1101623-2633-986609525-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by b05.egroups.com with NNFMP; 07 Apr 2001 02:12:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 7 Apr 2001 02:12:04 -0000 Received: (qmail 11231 invoked from network); 7 Apr 2001 02:12:04 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 7 Apr 2001 02:12:04 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta2 with SMTP; 7 Apr 2001 02:12:03 -0000 Received: from f-cpu.org (nas4-181.pau.club-internet.fr [195.36.133.181]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA24553 for ; Sat, 7 Apr 2001 04:11:58 +0200 (MET DST) Message-ID: <3ACE76E7.90E1C6E5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Apr 2001 04:09:43 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] [Fwd: Industry Gadfly "Sun's Linux Threat In EDA"] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N for those who might feel interested.
Free Software and hardware considerations in a mail
about EDA tools : that's interesting :-)

-------- Original Message --------
From: jcooley@world.std.com ( John Cooley )
To: esnug@world.std.com
Subject: Industry Gadfly  "Sun's Linux Threat In EDA"

    !!!     "It's not a BUG,                        jcooley@world.std.com
   /o o\  /  it's a FEATURE!"                              (508) 429-4357
  (  >  )
   \ - /        INDUSTRY GADFLY: "Sun's Linux Threat In EDA"
   _] [_        
                   by John Cooley, EE Times Columnist

      Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222

Last month I wrote about the customer disgust when Sun required customers
to sign non-disclosure agreements to get the caches fixed on their broken
Sun Ultra servers.  I received 26 e-mails in response to that column.

Four letters were of the I-Don't-See-What-You're-Talking-About variety.
"At my previous employer we had many Sun Ultra-30, Ultra-60, and E-450
machines for doing ASIC design.  We never had any trouble like is being
described.  They would stay up for hundreds of days doing ASIC simulation
and synthesis," wrote Tom Loftus of Intrinsix.  "At my current job, we
continue to use dual-CPU Ultra-60's and Ultra-80's with 2 - 4 GB memory
without any trouble."

Seven letters detailed Sun workstation bugs or gripes.  "At my last company
we bought an E4500 with 8 CPUs.  During the first 3 months, we had 7 CPU
replacements (involving 3 slots on 2 trays) due to cache parity errors.
The fix was to replace the trays, NOT the CPUs," wrote Ray Livingston of
Creative Labs.  "Sun was, however, always responsive, and never asked us
to keep it quiet."

Three letters came from Sun employees, with the most interesting being:
"John, I'll loan you a Sun workstation, you try to break it (with EDA SW
exercises, not a ball peen hammer)," wrote Dennis Kelly of Sun.  "Put it
side by side to an Intel box, or your favorite HP-UX box, and report the
results back in 4 months."

Workstation offer aside, what caught my eye were the five Linux letters.

"I've been using VCS, Finsim and Signalscan under Linux for a few years.
Lately I've also been using Cadence Verilog-XL under Linux.  I have to
say that I'm very happy with the performance of these tools under Linux,"
wrote one anon user.  "I can also buy ten 1 GHz Athlon systems for the
price of a single SunBlade."

"Chris Malachowsky's presentation at SNUG this week indicates that what
Sun does may be irrelevant," wrote Ross Smith of Theseus Logic.  "The
number of Suns in their compute farm has remained constant over the past
few years, while the number of Linux-based PCs has grown exponentially."

I called Chris and got a copy of his slides.  Sure enough, 20 months ago
NVidia had 10 Linux boxes, 150 Suns, and 100 NT boxes.  Last month, NVidia
had 640 Linux boxes, 270 Suns, and only 70 NT boxes.  "We get 2 to 3X
performance of our Linux boxes over our UNIX workstations and Linux boxes
are much cheaper, too," Chris said on the phone.  "We use Suns only for the
big jobs because of the current 2 Gig limit in Red Hat."

Looks like Sun isn't just having quality and customer support problems.
In these last two months both Synopsys and Cadence announced they were
porting many of their more popular EDA tools to Linux.  It's damn hard
to beat cheaper and faster.  Damn hard.

-----

    John Cooley runs the E-mail Synopsys Users Group (ESNUG), is a
    contract ASIC designer, and loves hearing from engineers at
    "jcooley@world.std.com" or (508) 429-4357.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Apr 7 04:10:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00576 for ; Sat, 7 Apr 2001 17:47:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:05 +0200 (MEST) Received: (qmail 16302 invoked by uid 0); 7 Apr 2001 02:12:27 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx06) with SMTP; 7 Apr 2001 02:12:27 -0000 X-eGroups-Return: sentto-1101623-2634-986609546-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 07 Apr 2001 02:12:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 7 Apr 2001 02:12:25 -0000 Received: (qmail 14582 invoked from network); 7 Apr 2001 02:12:25 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 7 Apr 2001 02:12:25 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 7 Apr 2001 02:12:24 -0000 Received: from f-cpu.org (nas4-181.pau.club-internet.fr [195.36.133.181]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA27824 for ; Sat, 7 Apr 2001 04:12:20 +0200 (MET DST) Message-ID: <3ACE7700.3190D96F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACB928A.A69C75EC@seul.org> <3ACCF1ED.A3C2ACC3@seul.org> <01040521010404.00861@gandalf.merlintec.com> <3ACDF7AB.1C41B426@seul.org> <20010406150413.B19004@moonbase.res.wpi.net> <3ACE4477.78D57C2E@jetnet.ab.ca> <3ACE4F12.43F49E77@starpower.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Apr 2001 04:10:08 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] [Fwd: Re: About the F-cpu project] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

Alan Grimes wrote:
> Ben wrote :
> > --- WANTED A FREE (GNU) WINDOWS STYLE OS ---
> I'm writing a paper which I will release in the next few weeks. I will
> add Ben to my preview list (the list of people who will get to see it
> first).

nice, but to those who might feel concerned : there are better
places in the Net to fight/discuss which text editor is best :-)

have fun, and use your preferred mailer with your preferred
keyboard, best coffee/tea/chocolate and your nicest seat,
the best things are still to come ;-) (f-cpu is one of them,
of course)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sat Apr 7 03:09:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00585 for ; Sat, 7 Apr 2001 17:47:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:08 +0200 (MEST) Received: (qmail 14806 invoked by uid 0); 7 Apr 2001 04:35:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx07) with SMTP; 7 Apr 2001 04:35:11 -0000 X-eGroups-Return: sentto-1101623-2635-986618109-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 07 Apr 2001 04:35:10 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 7 Apr 2001 04:35:08 -0000 Received: (qmail 62932 invoked from network); 7 Apr 2001 04:35:07 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 7 Apr 2001 04:35:07 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 7 Apr 2001 05:36:11 -0000 Received: from jetnet.ab.ca (dialin52.jetnet.ab.ca [207.153.6.52]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA02509 for ; Fri, 6 Apr 2001 22:35:05 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACE68C7.5054B90E@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 06 Apr 2001 19:09:27 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Slow I/O on the F-cpu. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N And I like PDP-8's better than IBM 1130's....
OH ... WG is back, forget I said any of that.
Most of my off-topic ramblings have been because I am in the
process of finalizing my ISA for the FPGA hardware.I hope to have
a working CPU by Easter.
Most of my redesign was so I could handle slow I/O, like
the IDE interface, and have lots of margin on data setup and hold
times. This meant going to a  E&Q clock like the 6809 and running at
1 MHZ.  For the F-CPU  how will Slow I/O and short timing delays ( up to 10
us) be handled? I can see stream hits being useful for I/O but fixed timing
delays have not been well addressed in cpu design. Timing loops change
too often because of hardware, yet most kernel operations do simple bit
fiddling and timing loops that seem a waste of processing time,for
device driver housekeeping? Could one add instructions that have fixed
delays rather than depend on timing loops?
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click here for Business information
Click here for Business information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From emily_grzyboski@yahoo.com Tue Apr 3 22:04:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00624 for ; Sat, 7 Apr 2001 17:47:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 07 Apr 2001 17:47:19 +0200 (MEST) Received: (qmail 10916 invoked by uid 0); 7 Apr 2001 11:23:00 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx27) with SMTP; 7 Apr 2001 11:23:00 -0000 X-eGroups-Return: sentto-1101623-2636-986642577-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 07 Apr 2001 11:22:57 -0000 X-Sender: ca_l_lein@altavista.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 7 Apr 2001 11:22:57 -0000 Received: (qmail 78226 invoked from network); 7 Apr 2001 11:22:56 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 7 Apr 2001 11:22:56 -0000 Received: from unknown (HELO wztc.edu.cn) (210.33.68.1) by mta2 with SMTP; 7 Apr 2001 11:22:55 -0000 Received: from 38.37.124.232 by wztc.edu.cn (SMI-8.6/SMI-SVR4) id MAA03468; Wed, 4 Apr 2001 12:00:37 +0800 Message-ID: <000004517fd6$000022ae$00005c43@> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: ca_l_lein@altavista.net From: emily_grzyboski@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 03 Apr 2001 12:04:45 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] TRUE STORY... 23619 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Status: R X-Status: N Leads... Leads... Leads... Every one Needs Them ... And We supply the Best LEADS EVER!!! A Salespersons DREAM Fresh Hot Leads Delivered to YOUR email Box DAILY !!! Campaigns Custom tailored to your specific needs. Hot Fresh LEADS - 24 hrs YOUNG or LESS. If you have the product or service Then we have the leads. For more information on how bulk email can help you Simply call 1-(904)-441-3331 (904 is not a 900# it a florida area code) To be removed from our list reply with the word "remove" in the subject line. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide, "Securing Your Web site for Business." Get it now! http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Yann Guidon Sun Apr 8 04:38:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA03095 for ; Sun, 8 Apr 2001 05:50:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Apr 2001 05:50:47 +0200 (MEST) Received: (qmail 8409 invoked by uid 0); 8 Apr 2001 02:40:47 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx07) with SMTP; 8 Apr 2001 02:40:47 -0000 X-eGroups-Return: sentto-1101623-2637-986697646-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 08 Apr 2001 02:40:46 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 8 Apr 2001 02:40:45 -0000 Received: (qmail 13302 invoked from network); 8 Apr 2001 02:40:45 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 8 Apr 2001 02:40:45 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta2 with SMTP; 8 Apr 2001 02:40:45 -0000 Received: from f-cpu.org (nas4-239.tls.club-internet.fr [195.36.202.239]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA00575 for ; Sun, 8 Apr 2001 04:37:33 +0200 (MET DST) Message-ID: <3ACFCF24.66439B4A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACE68C7.5054B90E@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 08 Apr 2001 04:38:28 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Slow I/O on the F-cpu. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> And I like PDP-8's better than IBM 1130's....
:-D
IBM was not very dear to my heart.
now, due to the laptop, i like it even less.

> OH ... WG is back, forget I said any of that.
ooops ....

> Most of my off-topic ramblings have been because I am in the
> process of finalizing my ISA for the FPGA hardware.I hope to have
> a working CPU by Easter.
cool :-)

> Most of my redesign was so I could handle slow I/O, like
> the IDE interface,
hmmm IDE = slow interface ? ...

> and have lots of margin on data setup and hold
> times. This meant going to a  E&Q clock like the 6809 and running at
> 1 MHZ.  For the F-CPU  how will Slow I/O and short timing delays ( up to 10
> us) be handled? I can see stream hits being useful for I/O but fixed timing
> delays have not been well addressed in cpu design. Timing loops change
> too often because of hardware, yet most kernel operations do simple bit
> fiddling and timing loops that seem a waste of processing time,for
> device driver housekeeping? Could one add instructions that have fixed
> delays rather than depend on timing loops?
i don't think so, there are better ways to do that.
* first, when a "specific" behaviour is required, in the sense that
it breaks with the pipeline scheduling etc, the Special Registers
are here for that. Their use is not dangerous for the scheduling and
their allocation/use can strech and evolve much more easily than the
instruction set.
* if you want 10us delays, you can use the internal counters. Remark that
this goes through the use of Special Registers. depending on the implementation,
you can even think about scheduling a short-range interrupt, the CPU and thread
state can be restored in a few hundreds of nanoseconds at worst.

At this point, when we have such a difference between the core speed and
the I/O devices, it's no use to add instructions : as Ben noted, the core
and the I/O devices evolve differently and the instruction map would suffer.
On top of that, the I/Os creates such problems that it's wise to avoid
any interference with the smooth pipeline scheduling of a clean RISC machine.
The core is so fast that there's no real latency difference between a
dedicated instruction and the use of Special Registers that map the desired
(custom) functions (or even implement them).

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sat Apr 7 13:58:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA03098 for ; Sun, 8 Apr 2001 05:50:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Apr 2001 05:50:48 +0200 (MEST) Received: (qmail 31667 invoked by uid 0); 8 Apr 2001 03:28:57 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx21) with SMTP; 8 Apr 2001 03:28:57 -0000 X-eGroups-Return: sentto-1101623-2638-986700535-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 08 Apr 2001 03:28:56 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 8 Apr 2001 03:28:55 -0000 Received: (qmail 92852 invoked from network); 8 Apr 2001 03:28:54 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 8 Apr 2001 03:28:54 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 8 Apr 2001 03:28:54 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA17837 for ; Sat, 7 Apr 2001 21:28:52 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACF00FD.AFB24270@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Apr 2001 05:58:53 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Another licence model. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Browsing thru a news group (alt.sys.pdp10) the topic of licenses came up.
Here is some ideas for GNU style licenses that may be useful.
http://www.freeworldlicence.org/
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Paolo Mortillaro" Sun Apr 8 07:01:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03360 for ; Sun, 8 Apr 2001 07:36:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 08 Apr 2001 07:36:19 +0200 (MEST) Received: (qmail 28380 invoked by uid 0); 8 Apr 2001 04:59:53 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx06) with SMTP; 8 Apr 2001 04:59:53 -0000 X-eGroups-Return: sentto-1101623-2639-986705991-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 08 Apr 2001 04:59:52 -0000 X-Sender: mc2789@mclink.it X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 8 Apr 2001 04:59:51 -0000 Received: (qmail 31101 invoked from network); 8 Apr 2001 04:59:51 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 8 Apr 2001 04:59:51 -0000 Received: from unknown (HELO mail.mclink.it) (195.110.128.7) by mta1 with SMTP; 8 Apr 2001 04:59:50 -0000 Received: from paolone (net156-163.mclink.it [195.110.156.163]) by mail.mclink.it (8.11.0/8.11.0) with SMTP id f384xk416165 for ; Sun, 8 Apr 2001 06:59:46 +0200 (CEST) Message-ID: <001001c0bfe8$f9b85920$0100000a@paolone> To: References: <000004517fd6$000022ae$00005c43@> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Paolo Mortillaro" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Apr 2001 07:01:30 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] remove Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Status: R X-Status: N ----- Original Message ----- From: To: Sent: Tuesday, April 03, 2001 10:04 PM Subject: [f-cpu] TRUE STORY... 23619 > > Leads... Leads... Leads... > > Every one Needs Them ... > > And We supply the Best LEADS EVER!!! > > A Salespersons DREAM > > Fresh Hot Leads Delivered to YOUR email Box DAILY !!! > > Campaigns Custom tailored to your specific needs. > > Hot Fresh LEADS - 24 hrs YOUNG or LESS. > > If you have the product or service > Then we have the leads. > > For more information on how bulk email can help you > > Simply call 1-(904)-441-3331 > > (904 is not a 900# it a florida area code) > > > > To be removed from our list reply with > the word "remove" in the subject line. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From David Cary Mon Apr 9 04:05:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA06380 for ; Mon, 9 Apr 2001 07:57:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 09 Apr 2001 07:57:23 +0200 (MEST) Received: (qmail 28407 invoked by uid 0); 9 Apr 2001 05:40:45 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx23) with SMTP; 9 Apr 2001 05:40:45 -0000 X-eGroups-Return: sentto-1101623-2640-986794841-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mr.egroups.com with NNFMP; 09 Apr 2001 05:40:45 -0000 X-Sender: d.cary@ieee.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 05:40:41 -0000 Received: (qmail 94613 invoked from network); 9 Apr 2001 05:40:41 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 9 Apr 2001 05:40:41 -0000 Received: from unknown (HELO mail3.primary.net) (216.87.38.220) by mta2 with SMTP; 9 Apr 2001 05:40:40 -0000 Received: from [192.168.1.40] (ip32-tc1.busprod.com [207.150.72.32]) by mail3.primary.net (8.10.0.1+jb/8.10.0/8.10-0+tht) with ESMTP id f395eV206873 for ; Mon, 9 Apr 2001 00:40:35 -0500 X-Sender: cary@www.rdrop.com Message-Id: To: f-cpu@yahoogroups.com From: David Cary MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 8 Apr 2001 21:05:23 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] [long] preliminary "design flow" Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
Dear f-cpu friends,

Do we have a (preliminary, tentative) "design flow", a plan for all the
steps between our idea for a chip and eventually getting physical chips in
our hands ?

Perhaps this conversation would help us make sure we haven't left anything out.

--- begin quote
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
...
( ESNUG 352 Item 5 ) --------------------------------------------- [5/17/00]

Subject: Muddling From A 3-Pass To A 2-Pass Hierarchical Layout Methodology
...
From: Tom Ayers <tomayers@believe.com>
To: Nancy Nettleton <nancy.nettleton@eng.sun.com>

Hi, Nancy,

I've done quite a bit of hierarchical layout, but the tool support for this
technique is spotty.  Typically the process involves the following:

  1) Project lead determines hierarchical breakdown of chip into
     "subsystems" which are place and route blocks.  Hierarchical
     equivalence is maintained between RTL and layout.  Subsystems have
     additional requirements from modules, usually WRT reset, interrupt,
     etc., resynchronization for synchronous distribution across the chip
     and clock tree components if clock tree synthesis is not being used.

  2) At RTL code complete, first pass floorplan is done.  Blocks are 90%
     accurate for cell area and margin is added for late maturing blocks.
     Manual global routing (Synopsys has new tool optimized for this, but
     I don't know how good it is) and megacell memory placement is done and
     timing data extracted for subsystems (PrimeTime or Ambit would be best
     for this since they have time budgeting).  Some global buses may be
     SPICEd.

  3) Representative subsystem is selected for full trial P&R closure to
     iron out tool flow issues.

  4) Final RTL synthesis is done after validation complete and subsystem
     areas compared to allow floorplan to be "jiggled" to correct sizes.

  5) P&R closure for each subsystem with IPO runs.

  6) Full chip parasitic extraction and static timing.

  7) LVS/DRC/tapeout
...
    - Tom Ayers
      Believe.com

         ----    ----    ----    ----    ----    ----   ----

From: Nancy Nettleton <nancy.nettleton@eng.sun.com>
To: Tom Ayers <tomayers@believe.com>

Hey Tom,
...
     Our 3-layout model works something like this:

       Layout 1:   80-90% gates synthesized
                   All memories, hard macs, clocks, & DFT implemented
                   Pre-layout Timing and verification level irrelevant
                   Layout Goals:
                     . Confirm die size
                     . Structure clocks, top-level busses, and critical
                          I/O paths
                     . Identify any architecturally or floorplan
                          limited critical paths.
                     . Work the kinks out of the hand-off model (esp.
                          for timing constraints)
                     . Work the kinks out of the methodology
                     . Set timing budgets

       Layout 2:   All gates synthesized
                   Sufficient verification to assure that top-level
                          will not change in final layout.
                   Timing met in synthesis with parasitics and budgets
                          from layout 1.
                   Layout Goals:
                     . Layout and freeze top-level routing.
                     . Close timing to synthesis timing.

       Layout 3:   This is basically the layout that goes to mask.
                   Logic is fully verified.
                   Because the top-level is frozen (small # ECO's allowed),
                       this layout is just a block-level re-spin,
                       making it much faster than layout 2.
...
...
    - Nancy Nettleton
      Sun Microsystems                           Silicon Valley, CA

         ----    ----    ----    ----    ----    ----   ----

From: Tom Ayers <tomayers@believe.com>
To: Nancy Nettleton <nancy.nettleton@eng.sun.com>
...
Hi, Nancy,
...
I have had pretty good luck with two layout model.  The important point is
in not kidding yourself about when you are ready for the first layout,
otherwise you are sure to do three.  Checklists can help here.  Try the
following:

        Layout 1:   All gates synthesized.
                    All memories, hard macs, clocks, & DFT implemented
                    Sufficient verification to assure that top-level
                        will not change significantly in final layout.
                    Timing goals not necessarily closed, but not way off.
                    Reasonable compile strategy (-map_effort med)
                        minimum.
                    All false, multicycle, etc paths worked out.
                    No timing arcs.
                    DFT not debugged
                    Layout Goals:
                       . Confirm die size
                       . Structure clocks, top-level busses, and critical
                              I/O paths
                       . Identify any architecturally or floorplan
                              limited critical paths.
                       . Work the kinks out of the hand-off model (esp.
                              for timing constraints)
                       . Work the kinks out of the methodology
                       . Set timing budgets
                       . Layout and freeze top-level routing.
                       . Close timing on one P&R block to iron out
                         tool flow.

        Layout 2:   Top level netlist released 1 week in advance of
                        validation closure.
                    Subsystems released as validation complete
                        and signoff checklists completed.
                    This is basically the layout that goes to mask.
                    Logic is fully verified.


> What I've been telling my projects is that we could cut out the first
> layout if we could take another 2-4 weeks on the 2nd and 3rd layout OR
> if they could leave more area/timing margin to take care of last minute
> problems.  So far I haven't had a project want to take the additional
> time or margin.  My feel is that management is willing to pay more
> up-front NRE for an add'l layout in order to minimize the time it takes
> to get from fully verified RTL to mask.

This depends on your market really.  For performance oriented designs such
as microprocessors and 3D graphics parts, speed is everyting.  For designs
where the clock rate is not the key driving issue, doing an extra layout
actually slows the team down and you are better off adding some additional
margin to your design (order of 5-10% of clock period makes a big
difference).

It also pays to have good predictive wireload models.


>>  1) Project lead determines hierarchical breakdown of chip into
>>     "subsystems" which are place and route blocks.  Hierarchical
>>     equivalence is maintained between RTL and layout.  Subsystems have
>>     additional requirements from modules, usually WRT reset, interrupt,
>>     etc., resynchronization for synchronous distribution across the chip
>>     and clock tree components if clock tree synthesis is not being used.
>
> We break out the hierarchy with our suppliers (because they look at the
> physical side while Sun ASIC managers look at the logical).  If we were
> in a COT environment, or our design managers had more experience with
> hierarchical layout, I would do what you describe above.

We tend to make this easy to do by wrapping modules in "subsystem wrappers".
These wrappers also include some o fthe things I've listed above as well as
bus interfaces for internal high speed chip buses.  We went as far as
standardizing the backside interface to the bus interface so that all
modules would have consistant host interfaces that were not tied to the
current internal bus implementation.


...
Sure.  The problem above is because you are doing netlist #1 too early.
It is mostly a wasted effort at that point.  We use spreadsheets that list
modules down the left side and module specific data along the top such as
current area, method of determining area, DFT % coverage, number of flops
per domain, and milestones with expected completion dates.

As the project matures, information fills in left to right giving a quick
glance at project progress as well as a wealth of information about the
project data.

...
The real advantage that I hope to get, however, is to follow a synthesis to
placed gates methodology.  99% of timing closure problems are due to gate
placement, not routing.  Chip Architect allows running synthesis to
placement and iterating on it in one tool and the forward annotating the
LEF/DEF files to the final router.  This should be legal placement at this
point which means timing closure should be quick.

    - Tom Ayers
      Believe.com

         ----    ----    ----    ----    ----    ----   ----

From: Nancy Nettleton <nancy.nettleton@eng.sun.com>
To: Tom Ayers <tomayers@believe.com>

> Yes, I usually use a "layout checklist" which needs to be filled out
> before you are ready.  If you can fill it out, then you are probably ready
> (all clock, reset, cell type restrictions, layout instructions, checks on
> synthesis and static timing results, etc).

Hi, Tom,

Most of our designers want to go to layout before they could complete
such a checklist.  One of my biggest pushes in the past year has been
to get the projects embedding checklist items in their project plans so
we aren't scrambling at the last minute trying to put in place something
we need but neglected.


> I like keeping basic floorplanning in house and detailed (LVS/DRC clean)
> floorplanning at the backend, or at least floorplan specification.  There
> is too much that can be done to impair timing closure without designer
> guidance.  That is why I find Chip Architect promising.

We've been providing designer guidance to floorplanning via an extensive
design review process as well as face2face, @the-workstation sessions
to tune it.

I've been finding that even with alot of designer interaction, there are
data flow and timing detail we miss until we get timing constraints,
particularly wrt DFT.  Too many whacked out half-cycle paths and things
that are just hard to identify and handle without detailed specs.


I'm getting ready to try a hybrid kind of hierarchical flow that may give
me the best of both worlds (famous last words :-)

We used to do this back on UltraSparc II, but until we had good hierarchy,
there was no sense trying it on ASICs.

We're going to do one netlist release to stabilize the top-level.  The
block-level netlists will need to have all memories instantiated with
most of their gates and good estimates of how many gates are still
coming.  We'll stabilize the top-level and block-level floorplans, then
set the block-level layout flows up so that they can be executed as a
back-end to the synthesis flow so that my logic designers can check
physical timing for a synthesis run (instead of just checking synthesis
timing with WLM's).  The trick will be stabilizing the floorplans enough
that the blocks can spin inside that floorplan for a while.  I expect
we'll want to spin the block layout down through placement and rough
layout timing closure, but not through routing.  This way, designers
can see their physical timing without going through all the work of
releasing a netlist to physical design.

The only things I haven't worked out yet are how often do we need to
integrate the whole chip to make sure it'll work (guessing twice), who
writes/maintains the rough PD flows (us or our supplier), and does the
rough PD flow produce just timing or something useful to layout as well.
I don't have a chip to try this on yet.  It could be a few months before
I can really work the kinks out of this.


> This depends on your market really.  For performance oriented designs
> such as microprocessors and 3D graphics parts, speed is everyting.  For
> designs where the clock rate is not the key driving issue, doing an extra
> layout actually slows the team down and you are better off adding some
> additional margin to your design (order of 5-10% of clock period makes a
> big difference).
>
> It also pays to have good predictive wireload models.

In alot of ways I agree with you, but when I think back over the last few
projects I worked on, we could not have done it without that first layout.
Of the last 5 ASICs I've worked on, 2 had the wrong physical design strategy
going in.  This was due to alot of things like immature architectures and
inexperience with the process technology.  If we hadn't done 1 trial
layout to find out we had the wrong strategy, we would've spent all our time
in the final trial layout focusing on methodology and not on the design.

On the last 3 ASICs, we did not have the wrong physical strategy going in.
I could possibly have lived without 2 trial layouts, but it would've taken
longer because the physical team had never owned layout timing closure and
never done hierarchy.

Its possible Sun needs 3 layout spins because our business people insist
on contracting high performance, high complexity silicon with suppliers
who really don't do high performance, high complexity.  I hadn't thought
about that alot.


>  - What is your cross-capacitance issue?

I worked with our microprocessor design group to review their 0.18 um
simulation results, and it was a big wake-up call.  When we started
simulating our ASIC 0.18 um technologies/libraries, we found that with
as little as 1 mm of adjacent routing, we could see >50% increase in
delay.  We also found that with about 1 mm of adjacent routing, we could
get noise glitches better than .8V.  So we started our 0.18 um suppliers
working on xcap noise/delay check & repair.  What an odyssey...

We've got flows in place now that are finding and fixing coupling
topologies that would've caused us to violate set-up or clock in an
incorrect logic value.  All of our xcap checking is static, so it all
assumes worst-case phase relationships.

The only silicon data I have on xcap is test chip data.  I haven't had
a chip fail on xcap yet.  I've heard of a couple in 0.25um, but we
skipped 0.25um for the most part.


> Maybe your wireload models are not so good?  I have not really had much
> difficulty identifying limited paths in synthesis.

Our largest hierarchical ASIC was partitioned into 19 sub-modules, so it's
way over-partitioned.  Consequently, there are many long, skinny blocks for
which WLM's just don't work very well.

I also think we had alot of young engineers really hoping against hope that
marginal paths would make it.  It was a real struggle to institute a logic
level budget of 30 levels of logic for 200MHz design.  The custom wireload
models helped, but it was still a struggle getting some of the paths down.
I think it was acerbated by late changes to the architecture, but I really
don't see that end of things.


> We use spreadsheets that list modules down the left side and module
> specific data along the top such as current area, method of determining
> area, DFT % coverage, number of flops per domain, and milestones with
> expected completion dates.  As the project matures, information fills in
> left to right giving a quick glance at project progress as well as a
> wealth of information about the project data.

I agree that the spreadsheet data is absolutely necessary, but I'm still
not convinced we could live without netlist #1 on all designs.  Without a
stable methodology, the risk is just too great that we wouldn't be able
to freeze the top-level before final layout.  I can't tell you how many
hours I've spent in meetings with managers trying to scrub 3 days out of
the final layout schedule.


> I have not yet met a project manager who did not want to draw up the basic
> floorplan yet.  I do not mean jiggle every memory into the exact location,
> but draw the rough boundaries and cell placements.  This would be forward
> annotated to the backend team who would make the real floorplan.  For
> instance your Layout #1 could be done completely in Chip Architect and
> done quickly to get subsystem timing budgets.  Little time would be wasted
> in doing a detailed layout for something that is not yet ready for this.
> Some full ASIC houses such as LSI, IBM, VLSI, etc provide the tools and
> expect you to do this step anyways.

I, also, have not met a design manager who didn't want to draw the basic
boundaries and module placements.

Don't know about Chip Architect.  Last time I looked at it, it couldn't
structure real clocks, which is a must-have out of the first integration
for us.

Agreed on ASIC house expectations.  Like I said, I think sun often gets
a different ride on the same merri-go-round.


> The real advantage that I hope to get, however, is to follow a synthesis
> to placed gates methodology.  99% of timing closure problems are due to
> gate placement, not routing.

Couldn't agree more.  That's what I'm hoping to get out of my hybrid flow
I outlined above.

The only gotch here is if cross-capacitance increases dramatically in
0.15um technologies.  I really hope the guys working on xcap avoidance
are coming up with something good, because the processor data I'm
looking at is not very encouraging.  As their clock rates approached
500MHz, their cross-cap shot up because of increased slew rate.  They
were finding 10-100x more xcap violations than I'm getting for the same
metallization scheme.  That kind of increase in xcap violations could
mean we'll have to go to routing to know our timing.  Man that would
suck.  I've really got my fingers crossed for xcap avoidance.


> Chip Architect allows running synthesis to placement and iterating on it
> in one tool and the forward annotating the LEF/DEF files to the final
> router.  This should be legal placement at this point which means timing
> closure should be quick.

That might be really slick.  I'll be interested to see how it works out.

    - Nancy Nettleton
      Sun Microsystems                           Silicon Valley, CA


( ESNUG 352 Item 6 ) --------------------------------------------- [5/17/00]
--- end quote




--
David Cary "mailto:d.cary@ieee.org" ><> <*> O-
  http://rdrop.com/~cary/
"icbmto:N36.1560 W95.7945"
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Apr 9 15:18:17 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09363 for ; Tue, 10 Apr 2001 06:32:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:32:51 +0200 (MEST) Received: (qmail 23124 invoked by uid 0); 9 Apr 2001 13:25:45 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx07) with SMTP; 9 Apr 2001 13:25:45 -0000 X-eGroups-Return: sentto-1101623-2641-986822739-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 09 Apr 2001 13:25:40 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 13:25:39 -0000 Received: (qmail 32709 invoked from network); 9 Apr 2001 13:25:37 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 Apr 2001 13:25:37 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 9 Apr 2001 14:26:41 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA23268; Mon, 9 Apr 2001 06:25:35 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9F1V; Mon, 9 Apr 2001 14:31:31 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AD1B699.81897EB@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Apr 2001 15:18:17 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi there,

i just wanted to share the news ASAP with you.
i won't be part of Mentor in mid-may.
On one side, it means that i won't earn as much
money, on the other side it means that i can
do whatever i want again, like i want, where and when !!!

so the F-CPU manual, websites and presentations will
probably be ready for the HAL. i'll be able to play
music whenever i want with my friends, go to any
cheap concert around...

The only "real" drawback is that i won't have
any (direct) access to a HW emulator ...

I promise that next time, i won't sell mysielf
like that to any company. at least not under
a certain salary ;-P

YG
Yahoo! Groups Sponsor
Click here - You're ready

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Bambang Sutanto Mon Apr 9 17:33:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09384 for ; Tue, 10 Apr 2001 06:32:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:32:57 +0200 (MEST) Received: (qmail 21046 invoked by uid 0); 9 Apr 2001 15:33:57 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx13) with SMTP; 9 Apr 2001 15:33:57 -0000 X-eGroups-Return: sentto-1101623-2642-986830434-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 09 Apr 2001 15:33:56 -0000 X-Sender: bsutanto.geo@yahoo.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 15:33:54 -0000 Received: (qmail 91722 invoked from network); 9 Apr 2001 15:33:53 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 Apr 2001 15:33:53 -0000 Received: from unknown (HELO web3905.mail.yahoo.com) (204.71.203.201) by mta3 with SMTP; 9 Apr 2001 16:34:57 -0000 Message-ID: <20010409153353.22135.qmail@web3905.mail.yahoo.com> Received: from [63.30.47.173] by web3905.mail.yahoo.com; Mon, 09 Apr 2001 08:33:53 PDT To: f-cpu@yahoogroups.com In-Reply-To: <3AD1B699.81897EB@mentor.com> X-eGroups-From: Bambang Sutanto From: Bambang Sutanto MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Apr 2001 08:33:53 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N dude,

what happens ?
what kind of position do u got overthere ?
anyway, hopefully soon u will get a new position
that suitable for u. good luck

--- Yann GUIDON <whygee@f-cpu.org> wrote:
> hi there,
>
> i just wanted to share the news ASAP with you.
> i won't be part of Mentor in mid-may.
> On one side, it means that i won't earn as much
> money, on the other side it means that i can
> do whatever i want again, like i want, where and
> when !!!
>
> so the F-CPU manual, websites and presentations will
> probably be ready for the HAL. i'll be able to play
> music whenever i want with my friends, go to any
> cheap concert around...
>
> The only "real" drawback is that i won't have
> any (direct) access to a HW emulator ...
>
> I promise that next time, i won't sell mysielf
> like that to any company. at least not under
> a certain salary ;-P
>
> YG
>
> ------------------------ Yahoo! Groups Sponsor
>
> 
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Yahoo! Groups Sponsor
>>
Enter Business Search Term above

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon Apr 9 19:13:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09417 for ; Tue, 10 Apr 2001 06:33:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:33:06 +0200 (MEST) Received: (qmail 27144 invoked by uid 0); 9 Apr 2001 17:21:11 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx06) with SMTP; 9 Apr 2001 17:21:11 -0000 X-eGroups-Return: sentto-1101623-2645-986836867-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fg.egroups.com with NNFMP; 09 Apr 2001 17:21:07 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 17:21:06 -0000 Received: (qmail 75923 invoked from network); 9 Apr 2001 17:21:06 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 9 Apr 2001 17:21:06 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 9 Apr 2001 17:21:06 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA13351; Mon, 9 Apr 2001 10:21:03 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9FN8; Mon, 9 Apr 2001 18:27:00 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AD1EDC9.E756412D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD1B699.81897EB@mentor.com> <3ACFC7AC.FA7C61E1@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Apr 2001 19:13:45 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi all !

thank you for the feedback, but don't worry for me.
the next months will be a bit hectic but i'm used to this ;-)
lack comfort is sometimes a creativity booster.

Ben Franchuk wrote:
> Yann GUIDON wrote:
> > On one side, it means that i won't earn as much
> > money, on the other side it means that i can
> > do whatever i want again, like i want, where and when !!!
> Free -- ha! We all know you are a slave to the computer...
how did you know ?.........

> > The only "real" drawback is that i won't have
> > any (direct) access to a HW emulator ...
> FPGA compiling can be fast for prototyping work.
> why have a emulator, when you can get a large FPGA board
> at low cost.
well, better use professional tools "for free" than pay
even a cheap FPGA. At least, i /know/ how the emulator works.
but if you have the FPGA, no problem.

> The real problem I see at the moment with VHDL is that there
> are no free compilers for that language. This may make fpga tools
> costly since to have to buy a compiler.
yup. What has happened to the idea of a "free FPGA" ?
There are already some (well, hum, not so good) free VHDL compilers.
a free architecture would help make a good compiler.

unfortunately, i am well placed to know that the patent issue
will be extremely difficult to solve : there are thousands, if not
much more, patents on this subject.
At least we have more chances with the F-CPU.

> > I promise that next time, i won't sell mysielf
> > like that to any company. at least not under
> > a certain salary ;-P
> Salary above $.03 after taxes,the wife and kids and the F-cpu,
;-D

ok, gotta cleanup my account ...
YG

speaking for himself
Yahoo! Groups Sponsor
Apply now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Mon Apr 9 19:26:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09420 for ; Tue, 10 Apr 2001 06:33:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:33:07 +0200 (MEST) Received: (qmail 24727 invoked by uid 0); 9 Apr 2001 17:26:28 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx22) with SMTP; 9 Apr 2001 17:26:28 -0000 X-eGroups-Return: sentto-1101623-2646-986837185-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 09 Apr 2001 17:26:26 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 17:26:25 -0000 Received: (qmail 90210 invoked from network); 9 Apr 2001 17:26:24 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 9 Apr 2001 17:26:24 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta3 with SMTP; 9 Apr 2001 18:27:28 -0000 Received: from localhost (graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA20235 for ; Mon, 9 Apr 2001 13:26:10 -0400 To: f-cpu@yahoogroups.com In-Reply-To: <3AD1EDC9.E756412D@mentor.com> Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Apr 2001 13:26:10 -0400 (EDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

On Mon, 9 Apr 2001, Yann GUIDON wrote:

>
> > The real problem I see at the moment with VHDL is that there
> > are no free compilers for that language. This may make fpga tools
> > costly since to have to buy a compiler.
> yup. What has happened to the idea of a "free FPGA" ?
Opencores are doing one - but as one part of their soc.
Don't know how they're going to get them made tho'.

take care of yourself,
Graham
Yahoo! Groups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Mon Apr 9 20:02:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09438 for ; Tue, 10 Apr 2001 06:33:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:33:11 +0200 (MEST) Received: (qmail 28708 invoked by uid 0); 9 Apr 2001 18:02:55 -0000 Received: from mx05.rz2.gmx.net (HELO hk.egroups.com) (10.1.72.105) by mxi1.gmx.net (mxi1) with SMTP; 9 Apr 2001 18:02:54 -0000 X-eGroups-Return: sentto-1101623-2647-986839359-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 09 Apr 2001 18:02:39 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 18:02:38 -0000 Received: (qmail 87294 invoked from network); 9 Apr 2001 18:02:37 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 9 Apr 2001 18:02:37 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta3 with SMTP; 9 Apr 2001 19:03:41 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id VAA04717 for ; Mon, 9 Apr 2001 21:02:36 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3ACFC7AC.FA7C61E1@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 9 Apr 2001 21:02:35 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sat, 7 Apr 2001, Ben Franchuk wrote:

> FPGA compiling can be fast for prototyping work.
> why have a emulator, when you can get a large FPGA board
> at low cost.

Try emulating state of the art chip with FPGA emulation. It sounds easy,
but it is not. Think that you have to support about 10-20Mbit of internal
SRAM/eDRAM/1TSRAM and few million gates. Dividing that even to the biggest
possible VirtexII chips is challenging (they have about 3-4Mbit of SRAM).
Then add gigabit speed links etc. to the picture (not a problem with
VirtexII pro). One big problem is for example very wide (128-512 bit) and
fast internal busses, you ran out of pins quite quickly. I think biggest
available FPGA chips have about 1000 I/O pins which is not so much.

Then you have to deveop your own interfaces to simulators to run the test
bench against the FPGA board (software is always late :)). And the biggest
problem is in the debugging with FPGA emulation. In HW accelerators all
internal signals are usually visible in the simulator. That makes
debugging of the chip much easier.

> The real problem I see at the moment with VHDL is that there
> are no free compilers for that language. This may make fpga tools
> costly since to have to buy a compiler.

And compiler alone is not sufficient. You want also good waveform
viewers, debugging capabilities etc. I fancy Modelsim altough it has some
bugs and leaks memory in some versions. But it has the best user interface
and is fast enough. For verilog gate level simulations I might use other
faster simulators. I hope nobody suggests VHDL gate level simulations,
they are horribly slow :)

I think many in this list have access to commercial tools at universities
or at work. For example there are no good free tools for synthesis so that
phase has to be done with commercial tools.

============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Apr 8 05:57:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA09495 for ; Tue, 10 Apr 2001 06:33:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 06:33:25 +0200 (MEST) Received: (qmail 6036 invoked by uid 0); 9 Apr 2001 23:37:57 -0000 Received: from hh.egroups.com (208.50.99.210) by mx0.gmx.net (mx18) with SMTP; 9 Apr 2001 23:37:57 -0000 X-eGroups-Return: sentto-1101623-2648-986859475-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 09 Apr 2001 23:37:55 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 9 Apr 2001 23:37:54 -0000 Received: (qmail 72362 invoked from network); 9 Apr 2001 23:37:53 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 9 Apr 2001 23:37:53 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 10 Apr 2001 00:38:57 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA13264 for ; Mon, 9 Apr 2001 17:37:46 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ACFE1AF.A783D6D9@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 07 Apr 2001 21:57:35 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> On Sat, 7 Apr 2001, Ben Franchuk wrote:
>
> > FPGA compiling can be fast for prototyping work.
> > why have a emulator, when you can get a large FPGA board
> > at low cost.
>
> Try emulating state of the art chip with FPGA emulation. It sounds easy,
> but it is not. Think that you have to support about 10-20Mbit of internal
> SRAM/eDRAM/1TSRAM and few million gates. Dividing that even to the biggest
> possible VirtexII chips is challenging (they have about 3-4Mbit of SRAM).
> Then add gigabit speed links etc. to the picture (not a problem with
> VirtexII pro). One big problem is for example very wide (128-512 bit) and
> fast internal busses, you ran out of pins quite quickly. I think biggest
> available FPGA chips have about 1000 I/O pins which is not so much.

True, but while the F-cpu is the state of the art,a full scale/full featured
model need not be developed on a FPGA, only subsystems that need testing.

BTW - refuse to use a FPGA that will not fit in a 84 PLCC package.If it
breaks -- repair it, don't throw it way.

> Then you have to deveop your own interfaces to simulators to run the test
> bench against the FPGA board (software is always late :)). And the biggest
> problem is in the debugging with FPGA emulation. In HW accelerators all
> internal signals are usually visible in the simulator. That makes
> debugging of the chip much easier.

Hmmm what is VHDL if it not software, thus software and VHDL code
would develop at the same speed. Designing for testing has to be done
regardless for what development platform is used. What happened to the
vacuum tube design era of computers, they were all built by hand.
Only back then you did not have the 'need it yesterday' view point
of management, they just needed it 'tomorrow'.

> > The real problem I see at the moment with VHDL is that there
> > are no free compilers for that language. This may make fpga tools
> > costly since to have to buy a compiler.
>
> And compiler alone is not sufficient. You want also good waveform
> viewers, debugging capabilities etc. I fancy Modelsim altough it has some
> bugs and leaks memory in some versions. But it has the best user interface
> and is fast enough. For verilog gate level simulations I might use other
> faster simulators. I hope nobody suggests VHDL gate level simulations,
> they are horribly slow :)

Yes I do want VHDL gate simulations as well as other simulations of the
cpu ISA. I may only use the gate simulation a few times,but I want to
be control of the final layout,not the VHDL writer. I have used a C
emulator for my ISA and only now that I am happy with the simulation
will I start drawing the schematics. I use schematics for four reasons
A) The logic is visible. B) HDL's don't simplify the logic.
I can't write a:cin + b -> cout:overflow:c for a adder with carry in,out
sum and overflow. C) I don't have $$$ to pay for a compiler. D) VHDL Software
reuse
is not possible because every brand of fpga has one or two features that mess up
software.

BOOTSTRAP ! BOOTSTRAP ! BOOTSTRAP. keep that in mind when your fancy
software crashes and you have to debug a bare machine.

> I think many in this list have access to commercial tools at universities
> or at work. For example there are no good free tools for synthesis so that
> phase has to be done with commercial tools.

The problem with what tools are out is that libraries are out of date.
If one updated the libraries some of the older software could be used.
Ben.
PS. Since I am doing schematics soon ( after I quit linux and write this email )
does anybody have a good way of making ( free I hope ) the schematics and/or
data files as free (gnu) information.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue Apr 10 08:00:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA10142 for ; Tue, 10 Apr 2001 11:10:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 11:10:15 +0200 (MEST) Received: (qmail 10560 invoked by uid 0); 10 Apr 2001 06:00:41 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx04) with SMTP; 10 Apr 2001 06:00:41 -0000 X-eGroups-Return: sentto-1101623-2649-986882433-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 10 Apr 2001 06:00:33 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 10 Apr 2001 06:00:32 -0000 Received: (qmail 28817 invoked from network); 10 Apr 2001 06:00:32 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 10 Apr 2001 06:00:32 -0000 Received: from unknown (HELO tiku.hut.fi) (130.233.228.86) by mta3 with SMTP; 10 Apr 2001 07:01:35 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA18254 for ; Tue, 10 Apr 2001 09:00:30 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3ACFE1AF.A783D6D9@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Apr 2001 09:00:29 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i am ... free ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sat, 7 Apr 2001, Ben Franchuk wrote:

> True, but while the F-cpu is the state of the art,a full scale/full featured
> model need not be developed on a FPGA, only subsystems that need testing.

Problem can be to connect those subsystems together. f-cpu has quite wide
busses and when you want 84 pin package you can bring one 64-bit bus out
:) I'm starting to get worried when the amount of pins goes over 1000 :)

> Hmmm what is VHDL if it not software, thus software and VHDL code
> would develop at the same speed. Designing for testing has to be done
> regardless for what development platform is used. What happened to the

Problem in the commercial sector at least is that ASIC development starts
way before the other project. Only systems people and ASIC people are in
the beginning doing things. SW people are coming in much later stages to
the project. ASIC just takes long time to develop and usually emulation
etc. can oly little help things.

>  Yes I do want VHDL gate simulations as well as other simulations of the
> cpu ISA. I may only use the gate simulation a few times,but I want to

I'd prefer Verilog gate simulations :) VHDL gate level simulations are
horribly slow. You can write verilog netlist even is the design itself is
in VHDL. Also gate level simulations are only for synthesis result
checking, static timing analysis takes care of the timing checks.

> will I start drawing the schematics. I use schematics for four reasons
> A) The logic is visible.

I guess you have been drawing schematics for a long time. I know what
structures I'm creating with HDL language, but I woudln't be able to
produce as good schematics as good synthesizer. Where I work the older
designers think "schematics way" and the HDL might look like that, and new
designers think directly in HDL. Usually the HDL results are better when
you think the entirety. Few gates won't matter when usually the problem is
to create enough gates to fill minimum sized silicon :)

> B) HDL's don't simplify the logic.

No but they make doing the logic much easier and faster. We are not coding
SW with assembler anymore either. Many designers think that HDL languages
are also too low level and are seeking for higher level tools.

> I can't write a:cin + b -> cout:overflow:c for a adder with carry in,out
> sum and overflow.

You can always instantiate adder from Synopsys DW for example and get
those signals. Or you can write a+b+cin={cout,d}. Good synthesizer
produces normal adder from that.

C) I don't have $$$ to pay for a compiler. D) VHDL Software
> reuse
> is not possible because every brand of fpga has one or two features that mess up
> software.

How can you reuse the schematics? You instantiate FPGA architecture
dependant blocks to the schematics etc. I think that reuse of schematics
is almost impossible. I have seen those 10cm thick piles of schematics for
old ASICs which no one wants to touch. You have to keep your doors locked
to prevent someone slipping one of those folders to your shelf :)

If the VHDL is propely written it just needs new run with synthesizer that
supports the new FPGA architecture and it uses all the new tricks
in that architecture. There are for example quite many tricks in Virtex
chips to create wide multiplexers (and the tricks are different in
different Virtex families).

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
Paid Net2phone Advertisement - Click Here!
Paid Net2phone Advertisement - Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue Apr 10 07:06:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00568 for ; Tue, 10 Apr 2001 19:27:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 10 Apr 2001 19:27:06 +0200 (MEST) Received: (qmail 3132 invoked by uid 0); 10 Apr 2001 16:28:37 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx12) with SMTP; 10 Apr 2001 16:28:37 -0000 X-eGroups-Return: sentto-1101623-2650-986920112-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by b05.egroups.com with NNFMP; 10 Apr 2001 16:28:34 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 10 Apr 2001 16:28:31 -0000 Received: (qmail 49434 invoked from network); 10 Apr 2001 16:27:44 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 10 Apr 2001 16:27:44 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 10 Apr 2001 16:27:44 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA14242; Tue, 10 Apr 2001 10:27:41 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD294C8.7F4A397C@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: fpga-cpu@yahoogroups.com, Freedom CPU References: <200104100727.JAA12494@haddock.cd.chalmers.se> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 09 Apr 2001 23:06:16 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: [fpga-cpu] raw speed and benchmarks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Johan Klockars wrote:
>
> > I'd say for sure the main reason MicroBlaze runs 125 MHz is
> >
> >    ******** Pipelining **********
>
> Very likely.
>
> > The MicroBlaze ISA must allow for lots and lots of pipeline stages.
>
> It would surprise me if it was much different from the 'canonical'
> 4/5-stage pipelined RISC (IF, ID, EX/MEM, WB).
>
> Hmm.
> I just took a look at the architecture graph and it does not really look
> like a pipelined design.
> Until I hear different I'll assume it is, though, since that makes the
> most sense (IMHO) for a RISC.
> I'm aiming for 100 MHz in one of those (Burch Electronics kit) with my own
> (16 bit at the moment) RISC. Unfortunately, the result MUX (selecting
> which EX unit result should go to the register file and the EX forwarding
> MUX) is taking so much time (yes, I've tried TBUFs, but that doesn't seem
> to help much, if anything) that I might need to pipeline it.
> Even now, I'm close to the 100 MHz target, but there's quite a bit to do
> yet (not even the pipeline itself is near finished).

Xilinx FPGA's do map well to RISC cpu designs. Dual port memory,fast carry
and tristate lines. Other or older FPGA's are not so lucky. But now we
get into a gray area, how much of the logic is device specific for
Xilinx and while they make a fast RISC cpu how are the FPGA's at other logic
styles
and random logic?

> There is intended to be hardware support for multiplication (getting one
> result bit per cycle) and I'll probably add zero cycle overhead looping.
>

What is needed is a 'loop r'/'loop #k'  instruction that just repeats the next
instruction in the pipeline here.

My question to all the people with knowledge is what studies on dynamic
code have been done to find the length of basic blocks in typical
programs? if 75% of  repeated code is 4 instructions of less (including a
branch)
having a pipeline >6 may be unwise. Ok f-cpu and Fpga guys any thoughts.

Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue Apr 10 22:22:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA02980 for ; Wed, 11 Apr 2001 14:33:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 14:33:40 +0200 (MEST) Received: (qmail 31535 invoked by uid 0); 10 Apr 2001 20:25:31 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx05) with SMTP; 10 Apr 2001 20:25:31 -0000 X-eGroups-Return: sentto-1101623-2651-986934320-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 10 Apr 2001 20:25:23 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 10 Apr 2001 20:25:20 -0000 Received: (qmail 67018 invoked from network); 10 Apr 2001 20:24:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 10 Apr 2001 20:24:47 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.173.76) by mta2 with SMTP; 10 Apr 2001 20:24:45 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 485699E70 for ; Tue, 10 Apr 2001 22:22:15 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AD36B77.2443D321@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104100727.JAA12494@haddock.cd.chalmers.se> <3AD294C8.7F4A397C@jetnet.ab.ca> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Apr 2001 22:22:15 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: [fpga-cpu] raw speed and benchmarks Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Johan Klockars wrote:
> >
> > > I'd say for sure the main reason MicroBlaze runs 125 MHz is<= BR> > > >
> > >    ******** Pipelining **********
> >
> > Very likely.
> >
> > > The MicroBlaze ISA must allow for lots and lots of pipeline = stages.
> >
> > It would surprise me if it was much different from the 'canonical= '
> > 4/5-stage pipelined RISC (IF, ID, EX/MEM, WB).
> >
> > Hmm.
> > I just took a look at the architecture graph and it does not real= ly look
> > like a pipelined design.
> > Until I hear different I'll assume it is, though, since that make= s the
> > most sense (IMHO) for a RISC.
> > I'm aiming for 100 MHz in one of those (Burch Electronics kit) wi= th my own
> > (16 bit at the moment) RISC. Unfortunately, the result MUX (selec= ting
> > which EX unit result should go to the register file and the EX fo= rwarding
> > MUX) is taking so much time (yes, I've tried TBUFs, but that does= n't seem
> > to help much, if anything) that I might need to pipeline it.
> > Even now, I'm close to the 100 MHz target, but there's quite a bi= t to do
> > yet (not even the pipeline itself is near finished).
>
> Xilinx FPGA's do map well to RISC cpu designs. Dual port memory,fast c= arry
> and tristate lines. Other or older FPGA's are not so lucky. But now we=
> get into a gray area, how much of the logic is device specific for
> Xilinx and while they make a fast RISC cpu how are the FPGA's at other= logic
> styles
> and random logic?
>
> > There is intended to be hardware support for multiplication (gett= ing one
> > result bit per cycle) and I'll probably add zero cycle overhead l= ooping.
> >
>
> What is needed is a 'loop r'/'loop #k'  instruction that just rep= eats the next
> instruction in the pipeline here.
>
> My question to all the people with knowledge is what studies on dynami= c
> code have been done to find the length of basic blocks in typical
> programs? if 75% of  repeated code is 4 instructions of less (inc= luding a
> branch)
> having a pipeline >6 may be unwise. Ok f-cpu and Fpga guys any thou= ghts.
>

You should unroll the loop ! And you couldn't use repeat instructions
instruction because it's ininterruptable.

I think that fcpu could have around 10-15 pipelines stages. You could
juste add some pipelines stage in the usual alu stage.

For informations, i have synthetise the leon to run at 180 Mhz on a
0.18=B5m ST lib (5 pipelines stages).

nicO

> Ben.
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Apr 11 13:51:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA03145 for ; Wed, 11 Apr 2001 14:34:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 14:34:21 +0200 (MEST) Received: (qmail 9917 invoked by uid 0); 11 Apr 2001 12:00:23 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx17) with SMTP; 11 Apr 2001 12:00:23 -0000 X-eGroups-Return: sentto-1101623-2652-986990358-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 11 Apr 2001 12:00:22 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 11:59:18 -0000 Received: (qmail 70367 invoked from network); 11 Apr 2001 11:59:17 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 11 Apr 2001 11:59:17 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 11 Apr 2001 13:00:21 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id EAA14191; Wed, 11 Apr 2001 04:59:15 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9HLV; Wed, 11 Apr 2001 13:05:13 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AD4455C.22EFD067@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104100727.JAA12494@haddock.cd.chalmers.se> <3AD294C8.7F4A397C@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 13:51:56 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: [fpga-cpu] raw speed and benchmarks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Ben Franchuk wrote:
> Johan Klockars wrote:
<...>

> > There is intended to be hardware support for multiplication (getting one
> > result bit per cycle) and I'll probably add zero cycle overhead looping.
>
> What is needed is a 'loop r'/'loop #k'  instruction that just repeats the next
> instruction in the pipeline here.
>
> My question to all the people with knowledge is what studies on dynamic
> code have been done to find the length of basic blocks in typical
> programs? if 75% of  repeated code is 4 instructions of less (including a
> branch) having a pipeline >6 may be unwise. Ok f-cpu and Fpga guys any thoughts.

I second Nicolas' answer to that :
- Repeat instructions are not "interruptible". on top of that, they
often require a "loop count register" which breaks with the monolithic register bank.
This makes context switching a real mess. And i'll conclude on top of that that
F-CPU and RISC instructions in general are not worth "repeating" : we have no
"movsx"-like instruction, thus repeating one instruction only is not desired.
And i know NO compiler today that uses REP MOVSB-like instructions.
- loop unrolling : with short loops, FC0 needs between 2 and 4 interlaced loops.
this is not difficult to do : we have enough registers to do that. the principle is
simple : the loop body is duplicated as many times as needed by the "critical
datapath" of the code, and the registers are statically renamed by the compiler/programmer.
this gives at least 16 registers per loop iteration (when unrolled 4x) which is
much enough for a "short loop" code.

In the beginning, looping instructions were analysed for the f-cpu. The solution
that is useed today is the best compromise between latency, scalability, security etc.
It is easy to implement on a variety of CPU cores without compromising performance and
the scheduler. hardwired loop instructions such as "0 latency jumps" as can be found
on DSP or CISC cores implies that the scheduler is much more constrained and has to figure
out a lot of things, for example when there is a page fault in the middle of the
instruction pair. Do you see what i mean ?

> Ben.
YG

speaking for himself

PS: mmm i gotta cut and paste that into the manual ;-)
Yahoo! Groups Sponsor
Click here for Business information
Click here for Business information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed Apr 11 05:13:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA04047 for ; Wed, 11 Apr 2001 22:20:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 22:20:52 +0200 (MEST) Received: (qmail 9641 invoked by uid 0); 11 Apr 2001 14:58:10 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx11) with SMTP; 11 Apr 2001 14:58:10 -0000 X-eGroups-Return: sentto-1101623-2653-987001088-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 11 Apr 2001 14:58:09 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 14:58:07 -0000 Received: (qmail 41352 invoked from network); 11 Apr 2001 14:56:59 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 11 Apr 2001 14:56:59 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 11 Apr 2001 15:58:03 -0000 Received: from jetnet.ab.ca (dialin54.jetnet.ab.ca [207.153.6.54]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA02817 for ; Wed, 11 Apr 2001 08:56:57 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD3CBF2.843361F2@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104100727.JAA12494@haddock.cd.chalmers.se> <3AD294C8.7F4A397C@jetnet.ab.ca> <3AD4455C.22EFD067@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 10 Apr 2001 21:13:54 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: [fpga-cpu] raw speed and benchmarks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:

> I second Nicolas' answer to that :
>  - Repeat instructions are not "interruptible". on top of that, they
>  often require a "loop count register" which breaks with the monolithic register bank.
    More difficult to interrupt true but I don't see it impossible.
    The loop counter (1 only?) would be a special register.
    
>  This makes context switching a real mess. And i'll conclude on top of that that
>  F-CPU and RISC instructions in general are not worth "repeating" : we have no
>  "movsx"-like instruction, thus repeating one instruction only is not desired.
>  And i know NO compiler today that uses REP MOVSB-like instructions.
>  - loop unrolling : with short loops, FC0 needs between 2 and 4 interlaced loops.
>  this is not difficult to do : we have enough registers to do that. the principle is
>  simple : the loop body is duplicated as many times as needed by the "critical
>  datapath" of the code, and the registers are statically renamed by the compiler/programmer.
>  this gives at least 16 registers per loop iteration (when unrolled 4x) which is
>  much enough for a "short loop" code.

    I have never believed in large amounts of loop unrolling.I guess it must
be because my first computer I used had 4K of core memory, and programs
had too be memory efficient.


> In the beginning, looping instructions were analysed for the f-cpu. The solution
> that is useed today is the best compromise between latency, scalability, security etc.
> It is easy to implement on a variety of CPU cores without compromising performance and
> the scheduler. hardwired loop instructions such as "0 latency jumps" as can be found
> on DSP or CISC cores implies that the scheduler is much more constrained and has to figure
> out a lot of things, for example when there is a page fault in the middle of the
> instruction pair. Do you see what i mean ?

True a loop instruction does kill the single instruction/single operation
of a risc machine. But my real question to the F-cpu people, what is
best pipeline depth? Ben.
PS. can it handle a Forth program well?



> > Ben.
> YG
>
> speaking for himself
>
> PS: mmm i gotta cut and paste that into the manual ;-)
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Apr 11 18:00:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA04071 for ; Wed, 11 Apr 2001 22:20:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 22:20:57 +0200 (MEST) Received: (qmail 32705 invoked by uid 0); 11 Apr 2001 16:08:57 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx18) with SMTP; 11 Apr 2001 16:08:57 -0000 X-eGroups-Return: sentto-1101623-2654-987005333-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 11 Apr 2001 16:08:55 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 16:08:52 -0000 Received: (qmail 50571 invoked from network); 11 Apr 2001 16:07:55 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 11 Apr 2001 16:07:55 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 11 Apr 2001 16:07:54 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA07886; Wed, 11 Apr 2001 09:07:51 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9HYS; Wed, 11 Apr 2001 17:13:49 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AD47F9D.518B971@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104100727.JAA12494@haddock.cd.chalmers.se> <3AD294C8.7F4A397C@jetnet.ab.ca> <3AD4455C.22EFD067@mentor.com> <3AD3CBF2.843361F2@jetnet.ab.ca> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 18:00:29 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: [fpga-cpu] raw speed and benchmarks Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Yann GUIDON wrote:
> > I second Nicolas' answer to that :
> >  - Repeat instructions are not "interruptible". on top of that, they
> >  often require a "loop count register" which breaks with the monolithic register bank.
>     More difficult to interrupt true but I don't see it impossible.
i didn't say it's impossible : look at the latest Intel titanics, they do that all day long.
however the point i'd like to explain is that it is damageable for a potentially
superscalar superpipelined CPU. It's what i would call "local optimum", the performance
advantage disappears when the conditions change significantly. it would have been still
valid 15 years ago. However, when a F-CPU can decode and execute (for example) 4 instructions
per cycle, the single instruction repeat "trick" is not the best solution if you want
higher performance.

>     The loop counter (1 only?) would be a special register.
could be. however, this doesn't solve, but moves the problem.

> >  This makes context switching a real mess. And i'll conclude on top of that that
> >  F-CPU and RISC instructions in general are not worth "repeating" : we have no
> >  "movsx"-like instruction, thus repeating one instruction only is not desired.
> >  And i know NO compiler today that uses REP MOVSB-like instructions.
> >  - loop unrolling : with short loops, FC0 needs between 2 and 4 interlaced loops.
> >  this is not difficult to do : we have enough registers to do that. the principle is
> >  simple : the loop body is duplicated as many times as needed by the "critical
> >  datapath" of the code, and the registers are statically renamed by the compiler/programmer.
> >  this gives at least 16 registers per loop iteration (when unrolled 4x) which is
> >  much enough for a "short loop" code.
>     I have never believed in large amounts of loop unrolling.I guess it must
> be because my first computer I used had 4K of core memory, and programs
> had too be memory efficient.
I understand your point of view, and a common case short loop could be around 10
instructions long in FC0. This makes the loop instruction overhead = 10% while
giving enough time for pointer computation and TLB lookup (since we certainly
access memory in most loops). I think that 10 instructions is not a insane amount
of unrolling, and you can always use shorter loops if you're more memory-savvy,
at the cost of less efficiency (more execution time).

> > In the beginning, looping instructions were analysed for the f-cpu. The solution
> > that is useed today is the best compromise between latency, scalability, security etc.
> > It is easy to implement on a variety of CPU cores without compromising performance and
> > the scheduler. hardwired loop instructions such as "0 latency jumps" as can be found
> > on DSP or CISC cores implies that the scheduler is much more constrained and has to figure
> > out a lot of things, for example when there is a page fault in the middle of the
> > instruction pair. Do you see what i mean ?
>
> True a loop instruction does kill the single instruction/single operation
> of a risc machine. But my real question to the F-cpu people, what is
> best pipeline depth? Ben.
if there was something close to a "best depth", everybody would have been using
it for a long while ;-)

You will remark that there is a wide variety of different pipeline structures and depths
around the world. Each architecture is matched for a certain performance/cost/ease ratio
wich also depends on the available technology, the goal, the budget, the constraints...
but i believe that you know that well.

For the FC0, the choice is to "match" the pipe depth to the execution unit,
hence the variable latency. if you're doing a simple OR, you have 1 cycle of latency
plus one for the Xbar. If you want something more complex, like 64x64 multiply,
you have to wait longer. In a sense, it is the "best depth" when someone wants to
climb in the clock frequency range, but this comes at a certain cost.

> PS. can it handle a Forth program well?

well, not as good as a P21 ... but ...
If you can do a recompile, either static or JIT, it will give you some
interesting boost through a more efficient utilisation of the large register
set that will map the stack (thus avoiding a large number of expensive
memory load/stores).

However, a "dumb" Forth will do quite good but will not burn your ass.

some advices :
- allocate register rS and rR for the data and return stacks
    (just #define rS and rR to whatever register you decide)
- allocate some (1 or 2) "phantom" registers to perform some
   pointer duplication, because pointer management is rather slow.
   see why below, how many AGI it creates.
- each push and pop is a memory fetch with post-inc/decrement.
- call-return is rather expensive, unless you find a good
   way to prefetch the jump addresses.
- etc....

here's how "+" would be computed (dumb, not optimised version) :
:+
asm load +4, rS, r1 ;
asm load +4, rS, r2 ;
asm add.32 r1, r2, r1 ;
asm store -4, rS, r1 ;
;

But due to the superpipelined nature of the FC0, it will be dead slow.
The 4 instructions will require around 5 cycles each to complete.
it will work, however. These 4 instructions are computed with a single
"CISC" instruction such as in the x86. the RISC CPU breaks everything up
and has less stack (-management) overhead/problems.

You see that a "true load/store" CPU is not best suited for stack-based
langages, because of the overhead of the memory (stack) references.
F-CPU is clearly under-efficient for FORTH. however,
it's a very nice number-cruncher ;-) you'll need a good
re-compiler if you want to get some good performance with Forth sources.
If your re-compiler can do register/stack mapping + scheduling, you'll have
something clearly more interesting.

> Ben.
YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Richard E.Hartney" Wed Apr 11 19:03:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA04098 for ; Wed, 11 Apr 2001 22:21:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 22:21:06 +0200 (MEST) Received: (qmail 17066 invoked by uid 0); 11 Apr 2001 16:58:41 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx21) with SMTP; 11 Apr 2001 16:58:41 -0000 X-eGroups-Return: sentto-1101623-2655-987008318-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 11 Apr 2001 16:58:39 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 16:58:38 -0000 Received: (qmail 65427 invoked from network); 11 Apr 2001 16:58:37 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Apr 2001 16:58:37 -0000 Received: from unknown (HELO mail0.lig.bellsouth.net) (207.203.120.39) by mta3 with SMTP; 11 Apr 2001 17:59:41 -0000 Received: from 0018728164 (host-209-215-11-33.bix.bellsouth.net [209.215.11.33]) by mail0.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id MAA18926; Wed, 11 Apr 2001 12:58:24 -0400 (EDT) Message-ID: <000a01c0c2a9$60162720$210bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 12:03:36 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Pipeline Depth Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0C27F.706869A0" Status: R X-Status: N ------=_NextPart_000_0007_01C0C27F.706869A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some time ago I sent the Instruction mix percentages - which I found right = on the money. One out of 8 instructions will be an Unconditional/Condition= al/or Jump and Store Return. Anything above 8 register pipeline depth in m= y opinion is wasted hardware in real world useage - not Game Playing machin= es. Unfortunately; in my current design - the best I can do is a depth of = 4 - due to pin limitations. I also had to go to two FPGA devices - where o= ne is essentially a DATA processor and the other is a MMU (Memory Managemen= t Unit). The MMU processes Addressing, both Read/write (Source and Destination) and Memory Control pins. I also F= etch four Instructions and potential Address data. I will provide a more d= escriptive summary at a future date. Right now I am experiencing Developmen= t Software problems. I am a BETA sight for the Eclipse SPDE 9.0 and have b= een using it since early Jan. 2001. I hope this is satisfactory for you BE= N' Dont hesitate to ask questions pro or con. Regards Dick Hartney ------=_NextPart_000_0007_01C0C27F.706869A0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some time ago I sent the Instruction mix=20 percentages - which I found right on the money.  One out of 8 instruct= ions=20 will be an Unconditional/Conditional/or Jump and Store Return.  Anythi= ng=20 above 8 register pipeline depth in my opinion is wasted hardware in real wo= rld=20 useage - not Game Playing machines.  Unfortunately; in my current desi= gn -=20 the best I can do is a depth of 4 - due to pin limitations.  I also ha= d to=20 go to two FPGA devices - where one is essentially a DATA processor and the = other=20 is a MMU (Memory Management Unit).  The MMU processes=20 Addressing,
both Read/write (Source and Destination) a= nd Memory=20 Control pins.  I also Fetch four Instructions and potential Address=20 data.  I will provide a more descriptive summary at a future date. Rig= ht=20 now I am experiencing Development Software problems.  I am a BETA sigh= t for=20 the Eclipse SPDE 9.0 and have been using it since early Jan. 2001.  I = hope=20 this is satisfactory for you BEN'
 
Dont hesitate to ask questions pro or=20 con.
 
Regards
Dick Hartney
 

Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_000_0007_01C0C27F.706869A0-- From ANTIGEN_MDMNT03 Wed Apr 11 18:56:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA04122 for ; Wed, 11 Apr 2001 22:21:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 22:21:16 +0200 (MEST) Received: (qmail 14505 invoked by uid 0); 11 Apr 2001 17:49:52 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx01) with SMTP; 11 Apr 2001 17:49:52 -0000 X-eGroups-Return: sentto-1101623-2656-987011390-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 11 Apr 2001 17:49:51 -0000 X-Sender: ANTIGEN_MDMNT03@mdm.mdemag.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 17:49:49 -0000 Received: (qmail 3164 invoked from network); 11 Apr 2001 17:49:48 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 11 Apr 2001 17:49:48 -0000 Received: from unknown (HELO sms?hi?02) (195.213.54.216) by mta3 with SMTP; 11 Apr 2001 18:50:52 -0000 Received: from mdmnt03.MDEMAG ([145.230.178.12]) by sms_hi_02 (Lotus Domino Release 5.0.2c (Intl)) with ESMTP id 2001041118591464:281 ; Wed, 11 Apr 2001 18:59:14 +0200 Received: by MDMNT03 with Internet Mail Service (5.5.2653.19) id <2K0W2PF1>; Wed, 11 Apr 2001 18:56:27 +0200 Message-ID: To: "'f-cpu@yahoogroups.com'" , "'rhartney@bellsouth.net'" X-Mailer: Internet Mail Service (5.5.2653.19) X-MIMETrack: Itemize by SMTP Server on SMS_Hi_02/SMS(Release 5.0.2c (Intl)|2 February 2000) at 11.04.2001 18:59:14, Serialize by Router on SMS_Hi_02/SMS(Release 5.0.2c (Intl)|2 February 2000) at 11.04.2001 19:49:30, Serialize complete at 11.04.2001 19:49:30 From: ANTIGEN_MDMNT03 MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 18:56:16 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Antigen found Mid/Kakworm virus Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Antigen for Exchange found Unknown infected with Mid/Kakworm virus.
The file is currently Deleted.  The message, "[f-cpu] Re: Pipeline Depth",
was
sent from Richard E.Hartney  and was discovered in IMC Queues\Inbound
located at MDemag/MDMCS/MDMNT03.
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Wed Apr 11 21:53:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA04158 for ; Wed, 11 Apr 2001 22:21:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 11 Apr 2001 22:21:28 +0200 (MEST) Received: (qmail 32468 invoked by uid 0); 11 Apr 2001 19:55:36 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx29) with SMTP; 11 Apr 2001 19:55:36 -0000 X-eGroups-Return: sentto-1101623-2658-987018933-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mk.egroups.com with NNFMP; 11 Apr 2001 19:55:34 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 11 Apr 2001 19:55:33 -0000 Received: (qmail 60232 invoked from network); 11 Apr 2001 19:55:32 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 11 Apr 2001 19:55:32 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.170.79) by mta3 with SMTP; 11 Apr 2001 20:56:34 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E498B9E70 for ; Wed, 11 Apr 2001 21:53:01 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AD4B61D.3142D0DC@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <000a01c0c2a9$60162720$210bd7d1@0018728164> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 21:53:01 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Pipeline Depth Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N "Some time ago I sent the Instruction mix percentages - which I found<= BR> right on the money.  One out of 8 instructions will be an
Unconditional/Conditional/or Jump and
Store Return.  Anything above 8 register pipeline depth in my opinion = is
wasted hardware in real world useage - not Game Playing machines.
Unfortunately; in my current
design - the best I can do is a depth of 4 - due to pin limitations.  = I
also had to go to two FPGA devices - where one is essentially a DATA
processor and the other is a
MMU (Memory Management Unit).  The MMU processes Addressing,
both Read/write (Source and Destination) and Memory Control pins.  I also Fetch four Instructions and potential Address data.  I will provi= de
a more descriptive summary
at a future date. Right now I am experiencing Development Software
problems.  I am a BETA sight for the Eclipse SPDE 9.0 and have been using it since early Jan. 2001.  I
hope this is satisfactory for you BEN'

Dont hesitate to ask questions pro or con.

Regards
Dick Hartney"

I think you couldn't say "in a typical 386 program you could find x instructions bevore a jump, so we should do that or that" that's stupi= d
because you adapt you're way of coding to your cpu (unroll, software
pipelining...) or the compiler. In the other hand conditionnal move and
conditionnal jump are very interresting because it don't break the
pipeline (no bubble) if the condtionnal register is computed early.

So very long pipeline are very usufull for high frequency design. 16
stages aren't so crazy. There's no renaming register stage nor
scheduler. So maybe the design could reach more than the pentuim4 !

Maybe around 10 stages could be used for the execution unit and 6 for
the decoder. With variable EU latency we add the problem of the number
of register port (the C62 have 8 writes port and 8 read port !)(Even in
one way cpu, if a 3 clock latency EU begin just bevore a 2 clock latency unit, the work will finish in the same clock cycle : big problem ?).
Somebody give the idea to delay the write with a priority to the long
latency unit, i don't find an exemple where the system don't work.

Pipelining is the key to the performance without having to pay much for
the area. But it's a kind of parralelism. So we should find good
instructions (as cmove, cjump and loop entry(?)) to insert no bubble in
the pipeline. That's the challenge. Register bank should be large, 64
regiters aren't big at all (think of a 2 or 4 way cpu (=3D cpu with 2 or 4<= BR> pipelines working in parralel (=3D an ILP of 2 of 4;):)=B0). Maybe in the future 32 bits instructions word will be too narrow and we should extent it to have 256 registers...

In the other hand we should add short-cut data path to avoid obligatory
writing to the register bank before a read. Sun say that in there
utlrasparc 3, 50% of the data come from the shortcut data path (we could gain at least 1 cycle, or one bubble in the pipeline in average).

Plus, we should define more precisely what we called the cross-bar. In
fact it could only be a few pair of buses. For a long time now, i don't
like to show it as a black magic box.

2 ported register bank are very common (1 read, 1 write). All other are
not very common. It's simulated by using in parallel 2 registers bank to add the missing read port. But it became very big for a large number of
ports. Usualy the register is hand-maid (full custom !, you know drawing the transistor by hand...).

My last score with the Leon is now 220 Mhz (less than 1 ns by stages).
So it say around 600 Mhz for a 16 stages pipelined cpu...Without to much effort.

nicO
Yahoo! Groups Spons= or
3D"Paid
Paid Net2phone Advertisement - Click Here!<= /td>
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Richard E.Hartney" Thu Apr 12 02:48:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00372 for ; Sun, 15 Apr 2001 21:49:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:49:08 +0200 (MEST) Received: (qmail 2806 invoked by uid 0); 12 Apr 2001 00:43:22 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx21) with SMTP; 12 Apr 2001 00:43:22 -0000 X-eGroups-Return: sentto-1101623-2659-987036200-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c9.egroups.com with NNFMP; 12 Apr 2001 00:43:21 -0000 X-Sender: rhartny@bellsouth.net X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 12 Apr 2001 00:43:19 -0000 Received: (qmail 33832 invoked from network); 12 Apr 2001 00:43:18 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 12 Apr 2001 00:43:18 -0000 Received: from unknown (HELO mail6.lig.bellsouth.net) (207.203.120.45) by mta3 with SMTP; 12 Apr 2001 01:44:22 -0000 Received: from 0018728164 (host-209-215-11-66.bix.bellsouth.net [209.215.11.66]) by mail6.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id UAA16684; Wed, 11 Apr 2001 20:43:13 -0400 (EDT) Message-ID: <000d01c0c2ea$4a199420$420bd7d1@0018728164> To: Cc: Organization: Erin Greene & Associates X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "Richard E.Hartney" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 19:48:26 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Instruction Mix Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C0C2C0.602F5D00" Status: R X-Status: N ------=_NextPart_000_000A_01C0C2C0.602F5D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To fully define the hardware requirements of the Erin32; the following = Instruction Mix is used: BRANCH 16% STORE 9% ARITH/LOGIC 45% LOAD 26% SHIFT 4% An analysis of the 9,967 Instructions are used in the Language I intend= to capture and used in the ERIN32; shows they are approximately correct. = A further analysis was accomplished resulting in: BRANCH 500 JUMP 1318 JST 764 (JUMP AND STORE RETURN) LDA/STA 390 These two inst are treated as one in m= y design and is essentially an IMA (Interchange memory and Accumulator) whi= ch is one of the standard Instructions. I also have a Source and Destinatio= n field in the Instruction format. LDA/ARITH 294 These are also treated as one Inst. LDA/LOGICAL 184 Same as above LDA/SHIFT 37 Same as above LDA/CAS 74 LDA/LDX 114 Same as above There are other random useage to arrive at 9,967. I have also incorpora= ted 128 hardware Index Registers - one for each of 128 users. The design fe= tches 4 instructions and 4 operands at the same time, and the memory clocks= to the next group of 4 inst/operands. Instruction decode is distributed = and has only one gate delay. In most cases the decode occurs at the end of= the execution phase. Unconditional Jumps are fully transparent. A NOP occ= upies memory space but has zero execution time.=20 The design uses one Phase Lock Loop and 9 Global clock networks in the = Memory Management Unit and one PLL in the Data Processor with 7 Global Cloc= k Networks. The clock source is tentively 50 MHZ.applied to PLLx4 of both = processors. There are Timing Control bits in MMU inst for tweeking the des= ign, which will reduce run time of Simulation. The Data processor essentia= lly has ONE bit to define the inst class and 4 bits to define inst in that = class. I will now include MUL/DIV as standa= rd instructions. Multiply is accomplished in a time sequence manner 4 - bi= ts at a time with nibble skip of zero's to give the best execution time. Di= vide is accomplished skipping strings of ones and zero's. I have included 8 Priority Vectored Interrupts which are treated as an = Indirect Jump and Store Return Instruction. Timing is derived from Shift Registers of variable length defined by th= e execution of the inst Class. Execution varies from 15 to 25 NS (excludin= g Mul/Div). It is possible that all four inst may execute at the same time= . If an inst requires data from the previous inst, a DDP (Data Dependent B= it) is inserted in the instruction at assembly time. An attempt was made to have 8 Pipeline Registers,however I ran out of p= ins in the MMU. The target device is the Quicklogic QL6600 having 506 I/O = pins. I started this last December and had change two weeks ago. The Data P= rocessor is complete and the MMU will be complete shortly. Then I will inc= orporate Mul/Div in both Processors to see which gives the best execution which is Place & R= oute dependent. There is more than adequate logic space in both chips. Several new inst have been added such as Set Bit/Clear Bit/Test Bit, Lo= ad selected Byte in least position with Bit 8 stripped. In our system desi= gn Bit 8 defines a Cursor Character. Also included a Normalize Inst which a= lso registers a shift count. A SCA is used for access to the register. Sin= ce Bit Reversal was required for all Shift Right Ins; I included the BRV in= struction. This sums my effort to date. Regards Dick Hartney ------=_NextPart_000_000A_01C0C2C0.602F5D00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    To fully define the har= dware=20 requirements of the Erin32; the following Instruction Mix is used:
       =20     BRANCH        16%
       =20     STORE          &= nbsp;=20 9%
       =20     ARITH/LOGIC   45%
       =20    =20 LOAD            = ;  26%
       =20     SHIFT        =20        4%
 
    An analysis of the 9,96= 7=20 Instructions are used in the Language I intend to capture and used in the=20 ERIN32; shows they are approximately correct.  A further analysis was= =20 accomplished resulting in:
 
 
       =20        =20 BRANCH        500
       =20         JUMP      &n= bsp;=20     1318
       =20         JST      &nb= sp;=20         764  (JUMP AND STORE=20 RETURN)
 
       =20         LDA/STA   =20     390   These two inst are treated as one in my= =20 design and is essentially an IMA (Interchange memory and Accumulator) which= is=20 one of the standard Instructions. I also have a Source and Destination fiel= d in=20 the Instruction format.
       =20         LDA/ARITH   =20     294  These are also treated as one Inst.
       =20         LDA/LOGICAL   =20 184  Same as above
       =20        =20 LDA/SHIFT           37&nb= sp;=20 Same as above
       =20        =20 LDA/CAS           &n= bsp; 74
       =20         LDA/LDX   =20         114  Same as above
    There are other random = useage to=20 arrive at 9,967. I have also incorporated 128 hardware Index Registers - on= e for=20 each of 128 users. The design fetches 4 instructions and 4 operands at the = same=20 time, and the memory clocks to the next group of 4 inst/operands. &nbs= p;=20 Instruction decode is distributed and has only one gate delay.  In mos= t=20 cases the decode occurs at the end of the execution phase. Unconditional Ju= mps=20 are fully transparent.  A NOP occupies memory space but has zero execu= tion=20 time.
    The design uses one Pha= se Lock=20 Loop and 9 Global clock networks in the Memory Management Unit and one PLL = in=20 the Data Processor with 7 Global Clock Networks.  The clock source is= =20 tentively 50 MHZ.applied to PLLx4 of both processors.  There are Timin= g=20 Control bits in MMU inst for tweeking the design, which will reduce run tim= e of=20 Simulation.  The Data processor essentially has ONE bit to define the = inst=20 class and 4 bits to define inst in that class.    =20                = =20             I will now include= =20 MUL/DIV as standard instructions.  Multiply is accomplished in a time= =20 sequence manner 4 - bits at a time with nibble skip of zero's to give the b= est=20 execution time. Divide is accomplished skipping strings of ones and=20 zero's.
    I have included 8 Prior= ity=20 Vectored Interrupts which are treated as an Indirect
Jump and Store Return Instruction.<= /DIV>
    Timing is derived from = Shift=20 Registers of variable length defined by the execution of the inst Class.&nb= sp;=20 Execution varies from 15 to 25 NS (excluding Mul/Div).  It is possible= that=20 all four inst may execute at the same time.  If an inst requires data = from=20 the previous inst, a DDP (Data Dependent Bit) is inserted in the instructio= n at=20 assembly time.
    An attempt was made to = have 8=20 Pipeline Registers,however I ran out of pins in the MMU.  The target d= evice=20 is the Quicklogic QL6600 having 506 I/O pins. I started this last December = and=20 had change two weeks ago. The Data Processor is complete and the MMU will b= e=20 complete shortly.  Then I will incorporate Mul/Div
in both Processors to see which gives the = best=20 execution which is Place & Route dependent. There is more than adequate= =20 logic space in both chips.
    Several new inst have b= een added=20 such as Set Bit/Clear Bit/Test Bit, Load selected Byte in least position wi= th=20 Bit 8 stripped.  In our system design Bit 8 defines a Cursor Character= .=20 Also included a Normalize Inst which also registers a shift count.  A = SCA=20 is used for access to the register. Since Bit Reversal was required for all= =20 Shift Right Ins; I included the BRV instruction.
 
    This sums my effort to= =20 date.
 
 
Regards
Dick Hartney

Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_000_000A_01C0C2C0.602F5D00-- From ANTIGEN_MDMNT03 Thu Apr 12 02:41:35 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00375 for ; Sun, 15 Apr 2001 21:49:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:49:11 +0200 (MEST) Received: (qmail 32462 invoked by uid 0); 12 Apr 2001 00:44:48 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx06) with SMTP; 12 Apr 2001 00:44:48 -0000 X-eGroups-Return: sentto-1101623-2660-987036286-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 12 Apr 2001 00:44:47 -0000 X-Sender: ANTIGEN_MDMNT03@mdm.mdemag.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 12 Apr 2001 00:44:46 -0000 Received: (qmail 60334 invoked from network); 12 Apr 2001 00:44:46 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 12 Apr 2001 00:44:46 -0000 Received: from unknown (HELO sms?hi?02) (195.213.54.216) by mta1 with SMTP; 12 Apr 2001 00:44:45 -0000 Received: from mdmnt03.MDEMAG ([145.230.178.12]) by sms_hi_02 (Lotus Domino Release 5.0.2c (Intl)) with ESMTP id 2001041202442470:910 ; Thu, 12 Apr 2001 02:44:24 +0200 Received: by MDMNT03 with Internet Mail Service (5.5.2653.19) id <2K0W2PMS>; Thu, 12 Apr 2001 02:41:37 +0200 Message-ID: To: "'f-cpu@yahoogroups.com'" , "'rhartney@bellsouth.net'" X-Mailer: Internet Mail Service (5.5.2653.19) X-MIMETrack: Itemize by SMTP Server on SMS_Hi_02/SMS(Release 5.0.2c (Intl)|2 February 2000) at 12.04.2001 02:44:24, Serialize by Router on SMS_Hi_02/SMS(Release 5.0.2c (Intl)|2 February 2000) at 12.04.2001 02:44:27, Serialize complete at 12.04.2001 02:44:27 From: ANTIGEN_MDMNT03 MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Apr 2001 02:41:35 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Antigen found Mid/Kakworm virus Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Antigen for Exchange found Unknown infected with Mid/Kakworm virus.
The file is currently Deleted.  The message, "[f-cpu] Re: Instruction Mix",
was
sent from Richard E.Hartney  and was discovered in IMC Queues\Inbound
located at MDemag/MDMCS/MDMNT03.
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Thu Apr 12 02:56:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00384 for ; Sun, 15 Apr 2001 21:49:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:49:13 +0200 (MEST) Received: (qmail 2756 invoked by uid 0); 12 Apr 2001 05:16:05 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx22) with SMTP; 12 Apr 2001 05:16:05 -0000 X-eGroups-Return: sentto-1101623-2661-987052562-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 12 Apr 2001 05:16:03 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 12 Apr 2001 05:16:01 -0000 Received: (qmail 36719 invoked from network); 12 Apr 2001 05:16:00 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 12 Apr 2001 05:16:00 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 12 Apr 2001 05:16:00 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id XAA17284 for ; Wed, 11 Apr 2001 23:15:57 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD4FD27.6B4E1E3D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <000d01c0c2ea$4a199420$420bd7d1@0018728164> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 11 Apr 2001 18:56:07 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Instruction Mix Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N That looks good there. Sigh 50 Mhz... I am lucky to get 7 Mhz with quicklogic's
smaller QL2007 but then I don't have use of fast ripple carry or register files
but I do have +5 volt logic and 84 plcc packaging. And the FPGA brand I have by
my computer states 180 ns is needed.
Since I am running at 1 us I don't have a worry about my speed,
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From quy78@di.fcen.uba.ar Mon May 18 14:52:12 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00393 for ; Sun, 15 Apr 2001 21:49:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:49:15 +0200 (MEST) Received: (qmail 26664 invoked by uid 0); 12 Apr 2001 06:23:55 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx29) with SMTP; 12 Apr 2001 06:23:55 -0000 X-eGroups-Return: sentto-1101623-2662-987056633-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 12 Apr 2001 06:23:54 -0000 X-Sender: quy78@di.fcen.uba.ar X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_1); 12 Apr 2001 06:23:52 -0000 Received: (qmail 21180 invoked from network); 12 Apr 2001 06:23:51 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 12 Apr 2001 06:23:51 -0000 Received: from unknown (HELO serva.cluj.osf.ro) (193.226.99.178) by mta2 with SMTP; 12 Apr 2001 06:23:50 -0000 Received: from 789yj7896j8 (d82.as0.wlgh.oh.voyager.net [207.90.75.82]) by serva.cluj.osf.ro with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2VSGKQBF; Thu, 12 Apr 2001 09:21:58 +0300 To: quy78@di.fcen.uba.ar Comments: Authenticated sender is Message-Id: <200104121159TAA29825@vfgbhnjm3a.osf.ro> X-eGroups-From: quy78@di.fcen.uba.ar (CINDY) From: quy78@di.fcen.uba.ar MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] GO ANYWHERE Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Thu, 12 Apr 01 06:23:56 GMT Status: R X-Status: N INTERNATIONAL DRIVER'S LICENSE

Need a new driver's license?

Too many points or other trouble?

Want a license that can never be suspended
or revoked?

Want ID for nightclubs or hotel check-in?

Avoid tickets, fines, and mandatory driver's
education.

Protect your privacy, and hide your identity.

The United Nations gave you the privilege to
drive freely throughout the world! (Convention
on International Road Traffic of September 19,
1949 & World Court Decision, The Hague,
Netherlands, January 21, 1958)

Take advantage of your rights.  Order a valid
International Driver's License that can never
be suspended or revoked.

Confidentiality assured.

CALL NOW!!!

1-713-866-4056






================================
rem -  techmail229@yahoo.com
================================

5876991495899714883096
(
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From François GRAND Thu Apr 12 08:28:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA00396 for ; Sun, 15 Apr 2001 21:49:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:49:16 +0200 (MEST) Received: (qmail 27680 invoked by uid 0); 12 Apr 2001 06:32:08 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx14) with SMTP; 12 Apr 2001 06:32:08 -0000 X-eGroups-Return: sentto-1101623-2663-987057127-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 12 Apr 2001 06:32:07 -0000 X-Sender: francois.grand@exascan.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_1); 12 Apr 2001 06:32:07 -0000 Received: (qmail 58449 invoked from network); 12 Apr 2001 06:32:06 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 12 Apr 2001 06:32:06 -0000 Received: from unknown (HELO serveur.mnet.fr) (194.206.136.227) by mta2 with SMTP; 12 Apr 2001 06:32:06 -0000 Received: by SERVEUR with Internet Mail Service (5.0.1457.3) id <2YP6DSYH>; Thu, 12 Apr 2001 08:28:44 +0200 Message-ID: <500FBD3650AED411B6160050BAF2CC44028B82@SERVEUR> To: "'f-cpu@yahoogroups.com'" X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) From: =?iso-8859-1?Q?Fran=E7ois_GRAND?= MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 12 Apr 2001 08:28:43 +0200 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] GO ANYWHERE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Who's that guy ?

What is this ad doing here ?!!??

> -----Message d'origine-----
> De : quy78@di.fcen.uba.ar [mailto:quy78@di.fcen.uba.ar]
> Envoy=E9 : Aucune
> =C0 : quy78@di.fcen.uba.ar
> Objet : [f-cpu] GO ANYWHERE
>
>
> INTERNATIONAL DRIVER'S LICENSE
>
> Need a new driver's license?
>
> Too many points or other trouble?
>
> Want a license that can never be suspended
> or revoked?
>
> Want ID for nightclubs or hotel check-in?
>
> Avoid tickets, fines, and mandatory driver's
> education.
>
> Protect your privacy, and hide your identity.
>
> The United Nations gave you the privilege to
> drive freely throughout the world! (Convention
> on International Road Traffic of September 19,
> 1949 & World Court Decision, The Hague,
> Netherlands, January 21, 1958)
>
> Take advantage of your rights.  Order a valid
> International Driver's License that can never
> be suspended or revoked.
>
> Confidentiality assured.
>
> CALL NOW!!!
>
> 1-713-866-4056
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
>  rem -  techmail229@yahoo.com
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 5876991495899714883096
> (
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> Do you have 128-bit SSL encryption server security?
> Get VeriSign's FREE Guide, "Securing Your
> Web Site for Business." Get it now!
> h= ttp://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/CYAVlB/TM
> --------------------------------------------------------------
> -------_->
>
> 
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/te= rms/


Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Apr 15 04:13:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01059 for ; Sun, 15 Apr 2001 21:52:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:32 +0200 (MEST) Received: (qmail 18033 invoked by uid 0); 15 Apr 2001 02:15:42 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx14) with SMTP; 15 Apr 2001 02:15:42 -0000 X-eGroups-Return: sentto-1101623-2664-987300941-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 15 Apr 2001 02:15:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 02:15:40 -0000 Received: (qmail 18210 invoked from network); 15 Apr 2001 02:15:40 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 15 Apr 2001 02:15:40 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta3 with SMTP; 15 Apr 2001 02:15:39 -0000 Received: from f-cpu.org (nas4-74.ras.club-internet.fr [195.36.203.74]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA07859 for ; Sun, 15 Apr 2001 04:15:30 +0200 (MET DST) Message-ID: <3AD903C8.234E40BE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 04:13:28 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,
this is to re-launch an idea i had.

i would like to setup a page with a gallery of short portraits
of the contributors. a kind of "who's who" and "who does/did what".

Often people ask me first "when will the f-cpu be ready",
then "how many people are working on it ?". There is still
no plan for the first, but we can do something to give an
answer to the second question.

Well, this is as simple as : name, pseudo, (optional small picture),
charge/achievement, date of first participation, optional age.
Not something exhaustive, but to give a rough idea of
the variety of people that take part in the project.

You know, it's difficult for me to say that besides
me and a few people i have met, the rest is difficult to
define. I would like to give a place to everyone who deserves
it, thanks to their work.

You have here the possibility to say "i'm alive",
"i did this" etc... so please send your own entry and
propositions.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Apr 15 04:18:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01071 for ; Sun, 15 Apr 2001 21:52:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:35 +0200 (MEST) Received: (qmail 31371 invoked by uid 0); 15 Apr 2001 02:52:01 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx30) with SMTP; 15 Apr 2001 02:52:01 -0000 X-eGroups-Return: sentto-1101623-2665-987303093-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 15 Apr 2001 02:51:34 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 02:51:33 -0000 Received: (qmail 73703 invoked from network); 15 Apr 2001 02:51:32 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 15 Apr 2001 02:51:32 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 15 Apr 2001 02:51:32 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA16569 for ; Sat, 14 Apr 2001 20:51:28 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD9050B.BECCEC67@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Apr 2001 20:18:51 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Ann Guide wrote:
>
> hello,
> this is to re-launch an idea i had.
>
> i would like to setup a page with a gallery of short portraits
> of the contributors. a kind of "who's who" and "who does/did what".
>
> Often people ask me first "when will the f-cpu be ready",
> then "how many people are working on it ?". There is still
> no plan for the first, but we can do something to give an
> answer to the second question.

Sounds like a good plan, but you need both a serious and
funny page for F-cpu people. Ben.


--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Ulna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Apr 15 05:04:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01074 for ; Sun, 15 Apr 2001 21:52:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:36 +0200 (MEST) Received: (qmail 19302 invoked by uid 0); 15 Apr 2001 03:06:39 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx08) with SMTP; 15 Apr 2001 03:06:39 -0000 X-eGroups-Return: sentto-1101623-2666-987303993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mw.egroups.com with NNFMP; 15 Apr 2001 03:06:33 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 03:06:32 -0000 Received: (qmail 5750 invoked from network); 15 Apr 2001 03:06:32 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Apr 2001 03:06:32 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta3 with SMTP; 15 Apr 2001 03:06:31 -0000 Received: from f-cpu.org (nas3-39.ras.club-internet.fr [195.36.203.39]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA20480 for ; Sun, 15 Apr 2001 05:02:52 +0200 (MET DST) Message-ID: <3AD90FB2.93A62D84@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ACE76E4.2E290384@f-cpu.org> <20010409153327.27751@thrai.stud.uni-hannover.de> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 05:04:18 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] two cents ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N late answer :-(
seems like my fetchmail@work has some hickups
and i miss some posts.

Michael Riepe wrote:
> On Sat, Apr 07, 2001 at 04:09:40AM +0200, Yann Guidon wrote:
> > unfortunately in the last months i haven't been
> > much "active". with the laptop, it will starte
> > to evolve a bit, my todo list is growing exponentially.
> o( that does sound familiar, doesn't it? )

latest update : Trollhunter (one of the new french guys)
has "installed" a "new" Linux version on my laptop,
a debian now. did i need that ?... well now still it's a
pain to operate, at least i came to a rather functioning
config with Mandrake. i'm a bit ... tired of computers.

> > Two f-cpu points that i'm investigating :
> >
> >  - the 4th condition : available conditions until now
> >     are zero, LSB and MSB (each being invertible).
> >     the missing code (in the two-bit field of the
> >     instructions that use it) is reserved.
> >    There are some possible usages for it, but one appears
> >     more important (the others have a limited usage) :
> >     floating point status or result. The condition
> >     returns true if the FP number in the register is
> >     OK, false otherwise : denormal, div by zero, NaN etc...
> >
> >     I would like to know your opinions.
>
> In the integer domain, `all 1's' would be a logical complement to
> `all 0's', but we can also test that via an INC or NOT instruction.
> For floating-point numbers, the distinction `number/NaN' would probably
> be most useful (where +/- infinity may or may not count as a NaN), and
> that's hard to do in software (too many cases to handle).  Make it so ;)

it sounds sane :-) N/NaN is a useful distinction, however
i don't know how to extract/get this from the numbers, and
particularly through a "hidden dynamic" flag.

i should get a fix with IEEE FP ...

> >  - Shuffling : This unit is still in the specification
> >     phase, as far as i remember. The question was asked
> >     by several people, whether a SIMD shifts a register
> >     with one count or if several shift counts were used.
> >     On top of that, i'm trying to figure out how the KNI
> >     (SSE) shuffle instruction works (i got a PIII laptop,
> >     so let's use it).
> >
> >     Now it's a matter of feasibility and instruction set.
> >     A new version of the shift instructions (with one
> >     more S prefix, to say it's really, really SIMD) would
> >     be fine but how can it be implemented ? what would
> >     be the real use, at what cost ?
>
> I guess the `single shift count for all chunks' version is more useful
> (e.g. for software pipelining) -- and it's much easier to implement.
> On the other hand, the `both operands are SIMD' approach is more logical,
> and we could emulate the `single shift count' instruction by expanding
> the right operand via the `sdup' instruction.  But it requires lots of
> extra circuitry (input muxes for the second operand, or a number of extra
> 8-bit shifters) that makes the unit either slower (muxes) or much bigger
> (additional shifters).  Since the shuffling unit is rather slow already
> (I guess we'll need 2 pipeline stages), I vote for the simplified,
> single-shift-count version.  We can add the `full SIMD' variant later
> (if there is any use for it).

At least, SSS instructions should be reserved and defined in the instruction
map and ISA. however, i don't know yet how it will behave exactly (always
because of the scalability issue) and how it will be implemented...

As for expanding a byte/word to all the operand bits, it's done
with the Xbar. This kind of functionality is required by a certain
number of other instructions already.


> CU,
ASAP
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Apr 15 05:05:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01077 for ; Sun, 15 Apr 2001 21:52:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:37 +0200 (MEST) Received: (qmail 19842 invoked by uid 0); 15 Apr 2001 03:08:01 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx25) with SMTP; 15 Apr 2001 03:08:01 -0000 X-eGroups-Return: sentto-1101623-2667-987304071-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 15 Apr 2001 03:07:52 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 03:07:51 -0000 Received: (qmail 24198 invoked from network); 15 Apr 2001 03:07:51 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 15 Apr 2001 03:07:51 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta3 with SMTP; 15 Apr 2001 03:07:51 -0000 Received: from f-cpu.org (nas3-39.ras.club-internet.fr [195.36.203.39]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA21660 for ; Sun, 15 Apr 2001 05:07:45 +0200 (MET DST) Message-ID: <3AD91008.8601375@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <3AD9050B.BECCEC67@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 05:05:44 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Sounds like a good plan, but you need both a serious and
> funny page for F-cpu people. Ben.

yep but does that mean that we need 2 pages ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Apr 15 04:47:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01080 for ; Sun, 15 Apr 2001 21:52:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:38 +0200 (MEST) Received: (qmail 9160 invoked by uid 0); 15 Apr 2001 03:20:36 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx12) with SMTP; 15 Apr 2001 03:20:36 -0000 X-eGroups-Return: sentto-1101623-2668-987304825-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hl.egroups.com with NNFMP; 15 Apr 2001 03:20:25 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 03:20:24 -0000 Received: (qmail 15947 invoked from network); 15 Apr 2001 03:20:24 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 15 Apr 2001 03:20:24 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 15 Apr 2001 03:20:24 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA19068 for ; Sat, 14 Apr 2001 21:20:17 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD90BCA.F3D81ACC@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <3AD9050B.BECCEC67@jetnet.ab.ca> <3AD91008.8601375@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 14 Apr 2001 20:47:38 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Ann Guide wrote:
>
> hi !
>
> Ben Franchuk wrote:
> > Sounds like a good plan, but you need both a serious and
> > funny page for F-cpu people. Ben.
>
> yep but does that mean that we need 2 pages ?
I guess it would depend on the context of the pictures.
All the 'Fred Flintstones' , Einstein's and 'Frankenstien's'
could have their own page. :-)
Ben.
-
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Apr 15 05:31:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01083 for ; Sun, 15 Apr 2001 21:52:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 15 Apr 2001 21:52:39 +0200 (MEST) Received: (qmail 23067 invoked by uid 0); 15 Apr 2001 03:33:59 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx14) with SMTP; 15 Apr 2001 03:33:59 -0000 X-eGroups-Return: sentto-1101623-2669-987305633-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mw.egroups.com with NNFMP; 15 Apr 2001 03:33:54 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 03:33:53 -0000 Received: (qmail 11447 invoked from network); 15 Apr 2001 03:33:53 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 15 Apr 2001 03:33:52 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta2 with SMTP; 15 Apr 2001 03:33:52 -0000 Received: from f-cpu.org (nas3-39.ras.club-internet.fr [195.36.203.39]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA10610 for ; Sun, 15 Apr 2001 05:33:46 +0200 (MET DST) Message-ID: <3AD91620.57F68D30@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <3AD9050B.BECCEC67@jetnet.ab.ca> <3AD91008.8601375@f-cpu.org> <3AD90BCA.F3D81ACC@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 05:31:44 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Ann Guide wrote:
(?)

> > yep but does that mean that we need 2 pages ?
> I guess it would depend on the context of the pictures.
> All the 'Fred Flintstones' , Einstein's and 'Frankenstien's'
> could have their own page. :-)

of course, context matters and humour is always welcome
because it gives the sign that we are aware of the
seriousness and ambitiousness of the project.

however, we need a way to know who contributes and how.
this must be objective. For the rest, a few links will
do the trick.

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sun Apr 15 22:15:51 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02430 for ; Mon, 16 Apr 2001 04:25:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 04:25:34 +0200 (MEST) Received: (qmail 13603 invoked by uid 0); 15 Apr 2001 20:17:58 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 15 Apr 2001 20:17:58 -0000 X-eGroups-Return: sentto-1101623-2671-987365877-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c9.egroups.com with NNFMP; 15 Apr 2001 20:17:57 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 20:17:57 -0000 Received: (qmail 8005 invoked from network); 15 Apr 2001 20:17:56 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 Apr 2001 20:17:56 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.173.223) by mta2 with SMTP; 15 Apr 2001 20:17:55 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8B6669E45 for ; Sun, 15 Apr 2001 22:15:51 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3ADA0177.ECF5CAE6@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <3AD9050B.BECCEC67@jetnet.ab.ca> <3AD91008.8601375@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 22:15:51 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N
Nice idea !

nicO

Yann Guidon a =E9crit :
>
> hi !
>
> Ben Franchuk wrote:
> > Sounds like a good plan, but you need both a serious and
> > funny page for F-cpu people. Ben.
>
> yep but does that mean that we need 2 pages ?
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"" 3D""
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From boucli27@altavista.net Mon Apr 16 00:30:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02451 for ; Mon, 16 Apr 2001 04:25:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 04:25:42 +0200 (MEST) Received: (qmail 7641 invoked by uid 0); 15 Apr 2001 22:40:22 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx22) with SMTP; 15 Apr 2001 22:40:22 -0000 X-eGroups-Return: sentto-1101623-2672-987373850-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by f19.egroups.com with NNFMP; 15 Apr 2001 22:30:50 -0000 X-Sender: boucli27@altavista.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 15 Apr 2001 22:30:32 -0000 Received: (qmail 21344 invoked from network); 15 Apr 2001 22:30:27 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 Apr 2001 22:30:26 -0000 Received: from unknown (HELO rmx614-mta.mail.com) (165.251.48.52) by mta3 with SMTP; 15 Apr 2001 22:30:26 -0000 Received: from weba6.iname.net (weba6.iname.net [165.251.4.16]) by rmx614-mta.mail.com (8.9.3/8.9.3) with ESMTP id SAA12297 for ; Sun, 15 Apr 2001 18:30:25 -0400 (EDT) Received: (from root@localhost) by weba6.iname.net (8.9.1a/8.9.2.Alpha2) id SAA25679; Sun, 15 Apr 2001 18:30:25 -0400 (EDT) Message-Id: <010415183025C2.20559@weba6.iname.net> To: f-cpu@yahoogroups.com From: boucli27@altavista.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 18:30:25 -0400 (EDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/plain Content-Transfer-Encoding: 8bit Status: R X-Status: N Name: Lionel, trollhunter Bouchpan-Lerust-Juéry Picture: TagesPiegel Dec 29 Page 29 hack^H^H^H^H exploring a CISCO at 17C3 Joined: At 17C3 December 2000 while inteviewing whygee for LinuxFR Contributions: ( unsorted ) Preparation for the HAL presentation, Archiving the project at LinuxFR's Website. INPI co-dépositaire Author at the LDP ( 2 documents ) Still learning how a processor works. Unix system and Network programmer ( I miss Stevens ) Unsolicited Advisor Doing interviews and writting articles. Book reviewer Age: Born in 1967 Location: Paris France (in a "coin mal paumé", Auteuil, Neuilly, Passy ... ;-) e-mail: trollhunter@linuxfr.org / boucli27@altavista.net Phone : 06 68 99 65 89 ######################################### Lionel, trollhunter Bouchpan-Lerust-Juery trollhunter@linuxfr.org boucli27@altavista.net http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html 06 68 99 65 89 ---------------------------------------------------------------- Get your free email from AltaVista at http://altavista.iname.com ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Michael Riepe Mon Apr 16 04:06:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA02466 for ; Mon, 16 Apr 2001 04:25:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 04:25:48 +0200 (MEST) Received: (qmail 508 invoked by uid 0); 16 Apr 2001 02:07:55 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx23) with SMTP; 16 Apr 2001 02:07:54 -0000 X-eGroups-Return: sentto-1101623-2675-987386824-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fj.egroups.com with NNFMP; 16 Apr 2001 02:07:54 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 02:07:04 -0000 Received: (qmail 11940 invoked from network); 16 Apr 2001 02:07:03 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 16 Apr 2001 02:07:03 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.172) by mta1 with SMTP; 16 Apr 2001 02:07:01 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA03080; Mon, 16 Apr 2001 04:06:58 +0200 Message-ID: <20010416040658.07928@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> X-Mailer: Mutt 0.84e In-Reply-To: <3ADA3A5D.316DE9D7@f-cpu.org>; from Yann Guidon on Mon, Apr 16, 2001 at 02:18:37AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 04:06:58 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Apr 16, 2001 at 02:18:37AM +0200, Yann Guidon wrote:

> > Ok, let's build `The F-CPU Hall Of Bla^H^H^HFame' :)
> you name it, you'll suffer from it ;-)
> it'll be copy/pasted in the title ;-P

No problem :)

> > > Not something exhaustive, but to give a rough idea of
> > > the variety of people that take part in the project.
> >
> > Hmm... like this?
> >
> >         Name: Michael "Tired" Riepe
> >         Picture: n/a
> u'r 2 shy ;-P

No... there are almost no pictures of me, and I don't have a scanner
either ;)

[...]
> however there's something missing here (to my eyes) :
> the responsibilities you have taken and what you have "objectively"
> contributed to the project. facts often speak enough clearly.
> AFAIK you're one of the VHDL gurus here, you have written some
> of the corner stone units and it counts more than your
> "Chief Procrastinator". A mention of your design of the ASU,
> IMU, IDU etc. are desired :-)

Do we really have to be SO serious? ;)

I think we can add that later... or do you want to change the page
every week? ;)

CU,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carlos De Urresti Hannoh Mon Apr 16 07:47:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA04043 for ; Mon, 16 Apr 2001 19:27:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 19:27:34 +0200 (MEST) Received: (qmail 12744 invoked by uid 0); 16 Apr 2001 05:47:27 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx02) with SMTP; 16 Apr 2001 05:47:27 -0000 X-eGroups-Return: sentto-1101623-2676-987400045-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 16 Apr 2001 05:47:26 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 05:47:25 -0000 Received: (qmail 1464 invoked from network); 16 Apr 2001 05:47:25 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 16 Apr 2001 05:47:25 -0000 Received: from unknown (HELO mx0.gmx.net) (213.165.64.100) by mta2 with SMTP; 16 Apr 2001 05:47:24 -0000 Received: (qmail 11960 invoked by uid 0); 16 Apr 2001 05:47:23 -0000 To: f-cpu@yahoogroups.com References: <010415183025C2.20559@weba6.iname.net> Message-ID: <6688.987400043@www15.gmx.net> X-Authenticated-Sender: #0006153040@gmx.net X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Authenticated-IP: [200.57.128.65] From: Carlos De Urresti Hannoh MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 07:47:23 +0200 (MEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Name: Carlos D'Urresti "Orage"
Picture: coming :>
Joined: March 13, 2001 (so late). Hopefully going to HAL, in that way I'll
able to share time with other F-CPU members :>
Contributions:
Raised hand as second contact for mailinglist maintainer.
Reading over the manual :)
Born: Nov, 1981
Location: Monterrey, Mexico.

Not a big archive on my side..

Orage.

--
Sent through GMX FreeMail - http://www.gmx.net
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Mon Apr 16 11:00:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA04052 for ; Mon, 16 Apr 2001 19:27:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 19:27:36 +0200 (MEST) Received: (qmail 30879 invoked by uid 0); 16 Apr 2001 09:02:28 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx30) with SMTP; 16 Apr 2001 09:02:28 -0000 X-eGroups-Return: sentto-1101623-2677-987411746-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 16 Apr 2001 09:02:27 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 09:02:25 -0000 Received: (qmail 42600 invoked from network); 16 Apr 2001 09:02:25 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 Apr 2001 09:02:25 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.224.20) by mta2 with SMTP; 16 Apr 2001 09:02:24 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 5E8FB9E71 for ; Mon, 16 Apr 2001 11:00:25 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3ADAB4A8.AC74EA55@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 11:00:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Michael Riepe a =E9crit :
>
> On Mon, Apr 16, 2001 at 02:18:37AM +0200, Yann Guidon wrote:
>
> > > Ok, let's build `The F-CPU Hall Of Bla^H^H^HFame' :)
> > you name it, you'll suffer from it ;-)
> > it'll be copy/pasted in the title ;-P
>
> No problem :)
>
> > > > Not something exhaustive, but to give a rough idea of > > > > the variety of people that take part in the project. > > >
> > > Hmm... like this?
> > >
> > >         Name: Michae= l "Tired" Riepe
> > >         Picture: n/a=
> > u'r 2 shy ;-P
>
> No... there are almost no pictures of me, and I don't have a scanner > either ;)
>
> [...]
> > however there's something missing here (to my eyes) :
> > the responsibilities you have taken and what you have "objec= tively"
> > contributed to the project. facts often speak enough clearly.
> > AFAIK you're one of the VHDL gurus here, you have written some > > of the corner stone units and it counts more than your
> > "Chief Procrastinator". A mention of your design of the= ASU,
> > IMU, IDU etc. are desired :-)
>
> Do we really have to be SO serious? ;)
>
> I think we can add that later... or do you want to change the page
> every week? ;)
>

Should we add what we do the "real life" to look a "little&q= uot; serious for
those who want to now if the project are serious or not ?

nicO
PS: Is there in new version of the multiplier unit ?
Does the CVS work ?
> CU,
> --
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hanno= ver.de>
>  "All I wanna do is have a little fun before I die"
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Apr 15 15:54:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA04094 for ; Mon, 16 Apr 2001 19:27:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 19:27:54 +0200 (MEST) Received: (qmail 26619 invoked by uid 0); 16 Apr 2001 13:42:32 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx03) with SMTP; 16 Apr 2001 13:42:32 -0000 X-eGroups-Return: sentto-1101623-2678-987428550-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by b05.egroups.com with NNFMP; 16 Apr 2001 13:42:31 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 13:42:30 -0000 Received: (qmail 93577 invoked from network); 16 Apr 2001 13:42:30 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 Apr 2001 13:42:30 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 16 Apr 2001 13:42:29 -0000 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA00318 for ; Mon, 16 Apr 2001 07:42:28 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AD9A812.AB0406B3@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> <3ADAB4A8.AC74EA55@seul.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 15 Apr 2001 07:54:26 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nicolas wrote:
> PS: Is there in new version of the multiplier unit ?
>  Does the CVS work ?

This brings up another point, chief VHDL coder,
I have seen a VHDL to VERLOG translator on Open Collector.
Is the VHDL code translatable thru such a converter?
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Mon Apr 16 19:14:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA04112 for ; Mon, 16 Apr 2001 19:27:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 19:27:59 +0200 (MEST) Received: (qmail 23553 invoked by uid 0); 16 Apr 2001 17:14:53 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx10) with SMTP; 16 Apr 2001 17:14:53 -0000 X-eGroups-Return: sentto-1101623-2679-987441291-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 16 Apr 2001 17:14:52 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 17:14:51 -0000 Received: (qmail 15683 invoked from network); 16 Apr 2001 17:14:50 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 Apr 2001 17:14:50 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta2 with SMTP; 16 Apr 2001 17:14:49 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id UAA31946 for ; Mon, 16 Apr 2001 20:14:47 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3AD9A812.AB0406B3@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 20:14:42 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sun, 15 Apr 2001, Ben Franchuk wrote:

> This brings up another point, chief VHDL coder,
> I have seen a VHDL to VERLOG translator on Open Collector.
> Is the VHDL code translatable thru such a converter?

May I suggest that you don't use such tools, unless someone forces to do
that. Those tools can create very hard to find bugs. The concurrency model
between VHDL and Verilog is little different and it's easy to create race
conditions etc. with automatic converters. The Verilog standard even has
few contradictions in the text (one piece is written for the standard and
other is from the original Verilog simulator manual, the bug should be
fixed in Verilog2000).

Also multiplier units, ALU etc. usually have generate statements
which can't be presented with current Verilog. Verilog2000 is not yet
supported in the toolchains.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
Click here

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon Apr 16 21:02:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA04380 for ; Mon, 16 Apr 2001 21:33:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 21:33:00 +0200 (MEST) Received: (qmail 7317 invoked by uid 0); 16 Apr 2001 19:04:23 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx22) with SMTP; 16 Apr 2001 19:04:23 -0000 X-eGroups-Return: sentto-1101623-2680-987447857-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 16 Apr 2001 19:04:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 19:04:16 -0000 Received: (qmail 16468 invoked from network); 16 Apr 2001 19:04:15 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 16 Apr 2001 19:04:15 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta2 with SMTP; 16 Apr 2001 19:04:15 -0000 Received: from f-cpu.org (nas1-169.ras.club-internet.fr [195.36.192.169]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA25630 for ; Mon, 16 Apr 2001 21:04:09 +0200 (MET DST) Message-ID: <3ADB41B1.B3C4A2BE@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> <3ADAB4A8.AC74EA55@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 21:02:09 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

Nicolas wrote:
<snip full-quote>
> Michael Riepe a =E9crit :
> > On Mon, Apr 16, 2001 at 02:18:37AM +0200, Yann Guidon wrote:
> Should we add what we do the "real life" to look a "lit= tle" serious for
> those who want to now if the project are serious or not ?

that could be interesting, right. At least, knowing if you're a student
or a professional procrastinator can give a hint. But if you belong
to a company, it can give some (shallow) credibility as well :-)

> nicO
> PS: Is there in new version of the multiplier unit ?
i don't know. I need to refresh all my files !

>  Does the CVS work ?
i don't know either. i'm also waiting for it.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Mon Apr 16 14:27:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA04383 for ; Mon, 16 Apr 2001 21:33:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 16 Apr 2001 21:33:01 +0200 (MEST) Received: (qmail 7708 invoked by uid 0); 16 Apr 2001 19:06:25 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx24) with SMTP; 16 Apr 2001 19:06:25 -0000 X-eGroups-Return: sentto-1101623-2681-987447982-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 16 Apr 2001 19:06:24 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 19:06:22 -0000 Received: (qmail 50212 invoked from network); 16 Apr 2001 19:06:21 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 16 Apr 2001 19:06:21 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.33) by mta1 with SMTP; 16 Apr 2001 19:06:13 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00473; Mon, 16 Apr 2001 14:27:33 +0200 Message-ID: <20010416142733.24759@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> <3ADAB4A8.AC74EA55@seul.org> X-Mailer: Mutt 0.84e In-Reply-To: <3ADAB4A8.AC74EA55@seul.org>; from Nicolas on Mon, Apr 16, 2001 at 11:00:24AM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 14:27:33 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, Apr 16, 2001 at 11:00:24AM +0200, Nicolas wrote:
[...]
> Should we add what we do the "real life" to look a "little" serious for
> those who want to now if the project are serious or not ?

My real life isn't serious at all.

> PS: Is there in new version of the multiplier unit ?

Not yet.  I gotta read some megabytes of docs first ;)

>  Does the CVS work ?

Not yet.  Did you send me a username and an encrypted password?

CU,
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Nathaniel Downes" Mon Apr 16 22:38:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA04924 for ; Tue, 17 Apr 2001 00:02:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Apr 2001 00:02:11 +0200 (MEST) Received: (qmail 14065 invoked by uid 0); 16 Apr 2001 20:35:51 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx08) with SMTP; 16 Apr 2001 20:35:51 -0000 X-eGroups-Return: sentto-1101623-2682-987453349-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 16 Apr 2001 20:35:49 -0000 X-Sender: down@ici.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 20:35:49 -0000 Received: (qmail 74270 invoked from network); 16 Apr 2001 20:35:47 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 16 Apr 2001 20:35:47 -0000 Received: from unknown (HELO bajor.ici.net) (207.180.0.58) by mta1 with SMTP; 16 Apr 2001 20:35:47 -0000 Received: from kenny (h00105ac6ea34.ne.mediaone.net [66.31.4.143]) by bajor.ici.net (8.8.8/8.8.8) with SMTP id QAA05034 for ; Mon, 16 Apr 2001 16:37:07 -0400 (EDT) Message-ID: <009801c0c6b5$299cdc60$8f041f42@ne.mediaone.net> To: References: <3AD903C8.234E40BE@f-cpu.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Nathaniel Downes" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 16:38:14 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01C0C693.A20C9680" Status: R X-Status: N ------=_NextPart_000_0095_01C0C693.A20C9680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm alive, just nose-deep with Eddas. ----- Original Message -----=20 From: Yann Guidon=20 To: fm=20 Sent: Saturday, April 14, 2001 10:13 PM Subject: [f-cpu] "how's who" @f-cpu.org hello, this is to re-launch an idea i had. i would like to setup a page with a gallery of short portraits of the contributors. a kind of "who's who" and "who does/did what". Often people ask me first "when will the f-cpu be ready", then "how many people are working on it ?". There is still no plan for the first, but we can do something to give an answer to the second question. Well, this is as simple as : name, pseudo, (optional small picture), charge/achievement, date of first participation, optional age. Not something exhaustive, but to give a rough idea of the variety of people that take part in the project. You know, it's difficult for me to say that besides me and a few people i have met, the rest is difficult to define. I would like to give a place to everyone who deserves it, thanks to their work. You have here the possibility to say "i'm alive", "i did this" etc... so please send your own entry and propositions. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yahoo! Groups Sponsor=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20 =20=20=20=20=20=20=20 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.=20 ------=_NextPart_000_0095_01C0C693.A20C9680 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
I'm alive, just nose-deep with Eddas.
----- Original Message -----
To: fm
Sent: Saturday, April 14, 2001 10:13 PM
Subject: [f-cpu] "how's who" @f-cpu.org

hello,
this is to re-launch an idea i had.

i would like to setup a page with a gallery of short portraits
of the contributors. a kind of "who's who" and "who does/did what".

Often people ask me first "when will the f-cpu be ready",
then "how many people are working on it ?". There is still
no plan for the first, but we can do something to give an
answer to the second question.

Well, this is as simple as : name, pseudo, (optional small picture),
charge/achievement, date of first participation, optional age.
Not something exhaustive, but to give a rough idea of
the variety of people that take part in the project.

You know, it's difficult for me to say that besides
me and a few people i have met, the rest is difficult to
define. I would like to give a place to everyone who deserves
it, thanks to their work.

You have here the possibility to say "i'm alive",
"i did this" etc... so please send your own entry and
propositions.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_000_0095_01C0C693.A20C9680-- From Michael Riepe Mon Apr 16 21:10:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA06137 for ; Tue, 17 Apr 2001 03:53:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Apr 2001 03:53:37 +0200 (MEST) Received: (qmail 25786 invoked by uid 0); 17 Apr 2001 00:10:01 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx19) with SMTP; 17 Apr 2001 00:10:01 -0000 X-eGroups-Return: sentto-1101623-2683-987465509-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 16 Apr 2001 23:58:30 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 16 Apr 2001 23:58:28 -0000 Received: (qmail 26179 invoked from network); 16 Apr 2001 23:58:28 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 16 Apr 2001 23:58:28 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.86) by mta1 with SMTP; 16 Apr 2001 23:58:26 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01917; Mon, 16 Apr 2001 21:10:11 +0200 Message-ID: <20010416211011.22079@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> <3ADAB4A8.AC74EA55@seul.org> <3AD9A812.AB0406B3@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3AD9A812.AB0406B3@jetnet.ab.ca>; from Ben Franchuk on Sun, Apr 15, 2001 at 07:54:26AM -0600 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 21:10:11 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Sun, Apr 15, 2001 at 07:54:26AM -0600, Ben Franchuk wrote:

> I have seen a VHDL to VERLOG translator on Open Collector.
> Is the VHDL code translatable thru such a converter?

I don't know.  Why don't you grab a copy and try it yourself?

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue Apr 17 01:32:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA06140 for ; Tue, 17 Apr 2001 03:53:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Apr 2001 03:53:38 +0200 (MEST) Received: (qmail 10597 invoked by uid 0); 17 Apr 2001 00:14:38 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx01) with SMTP; 17 Apr 2001 00:14:38 -0000 X-eGroups-Return: sentto-1101623-2684-987466474-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mk.egroups.com with NNFMP; 17 Apr 2001 00:14:35 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 17 Apr 2001 00:14:32 -0000 Received: (qmail 59641 invoked from network); 17 Apr 2001 00:14:32 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 17 Apr 2001 00:14:32 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 17 Apr 2001 00:14:32 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA18214 for ; Mon, 16 Apr 2001 18:14:30 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ADB810E.88A5D1D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> <20010415143905.16630@thrai.stud.uni-hannover.de> <3ADA3A5D.316DE9D7@f-cpu.org> <20010416040658.07928@thrai.stud.uni-hannover.de> <3ADAB4A8.AC74EA55@seul.org> <3AD9A812.AB0406B3@jetnet.ab.ca> <20010416211011.22079@thrai.stud.uni-hannover.de> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 16 Apr 2001 17:32:30 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Michael Riepe wrote:
>
> On Sun, Apr 15, 2001 at 07:54:26AM -0600, Ben Franchuk wrote:
>
> > I have seen a VHDL to VERLOG translator on Open Collector.
> > Is the VHDL code translatable thru such a converter?
>
> I don't know.  Why don't you grab a copy and try it yourself?
>
At the moment I have not had the experience with VHDL and VERLOG to
tell if what is comes out is good code.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Matringe Tue Apr 17 09:59:21 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA07925 for ; Tue, 17 Apr 2001 19:13:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Apr 2001 19:13:36 +0200 (MEST) Received: (qmail 21265 invoked by uid 0); 17 Apr 2001 07:57:26 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx18) with SMTP; 17 Apr 2001 07:57:26 -0000 X-eGroups-Return: sentto-1101623-2685-987494244-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 17 Apr 2001 07:57:25 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 17 Apr 2001 07:57:23 -0000 Received: (qmail 48568 invoked from network); 17 Apr 2001 07:57:23 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 Apr 2001 07:57:23 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta2 with SMTP; 17 Apr 2001 07:57:22 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id HAA24205 for ; Tue, 17 Apr 2001 07:57:20 GMT X-To: Message-ID: <3ADBF7D9.FD4FF86D@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <3AD903C8.234E40BE@f-cpu.org> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Apr 2001 09:59:21 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Name : Nicolas Matringe
Picture: once, maybe...
Joined: February 2000 (first post to YG)
Contributions:
   The official F-CPU logo
   Some VHDL advices
Age : born in '72
Location: near Paris (see my sig. for details)
Professionnal occupation: VHDL grinder
Other info on demand

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Hans Summers Tue Apr 17 11:12:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA07931 for ; Tue, 17 Apr 2001 19:13:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 17 Apr 2001 19:13:38 +0200 (MEST) Received: (qmail 29171 invoked by uid 0); 17 Apr 2001 09:12:58 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx22) with SMTP; 17 Apr 2001 09:12:58 -0000 X-eGroups-Return: sentto-1101623-2686-987498775-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 17 Apr 2001 09:12:56 -0000 X-Sender: Hans.Summers@tudor.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 17 Apr 2001 09:12:54 -0000 Received: (qmail 65440 invoked from network); 17 Apr 2001 09:12:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 Apr 2001 09:12:54 -0000 Received: from unknown (HELO ns2.tudor.com) (63.93.49.196) by mta2 with SMTP; 17 Apr 2001 09:12:53 -0000 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id FAA05079 for ; Tue, 17 Apr 2001 05:09:25 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id FAA04579 for ; Tue, 17 Apr 2001 05:12:51 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2448.0) id <2VSX18QF>; Tue, 17 Apr 2001 10:12:51 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152EC79@po1-exch.lon.tudor.com> To: "'f-cpu@yahoogroups.com'" X-Mailer: Internet Mail Service (5.5.2448.0) From: Hans Summers MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 17 Apr 2001 10:12:41 +0100 Reply-To: f-cpu@yahoogroups.com Subject: RE: [f-cpu] "how's who" @f-cpu.org Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
Name: Hans Summers
Picture:  :)
Joined: Jan 2001
Contributions:
   Mailing list lurker
   The heretical scheduler proposal
(http://www.hanssummers.com/computers/fcpu/scheduler.htm)
Born: 1971
Location: Near London, UK
Virtual location: http://www.HansSummers.com



------------------
Hans Summers
http://www.HansSummers.Com

Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed Apr 18 10:16:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00377 for ; Wed, 18 Apr 2001 17:21:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:21:50 +0200 (MEST) Received: (qmail 26982 invoked by uid 0); 18 Apr 2001 08:11:49 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx09) with SMTP; 18 Apr 2001 08:11:49 -0000 X-eGroups-Return: sentto-1101623-2687-987581503-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 18 Apr 2001 08:11:44 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 08:11:42 -0000 Received: (qmail 19120 invoked from network); 18 Apr 2001 08:11:42 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 18 Apr 2001 08:11:42 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 18 Apr 2001 08:11:42 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 18 Apr 2001 08:16:06 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200104180816.06cf@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 08:16:06 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] SH-5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Maybe have you heard about the SH-5. It's the last 64
bits beast from Hitachi and ST-microelectronics.
Whygee said that was not so good, few weeks ago.

To make your opinion cf. :
http://semiconductor.hitachi.com/superh/index.cfm?men
uselection=search3&p_line=SH-5

Personnaly, the SH-5 is almost exactly what the fcpu
will look like : Single issue, long pipeline (7),
"native" SIMD (64 bit equal in fact 2*32,4*16 or 2*8
for them), variable latency execution unit (1 to 3),
trick to accelerate the context switch (see the dirty
bit trick, very nice !), interrupt handling, 64
registers, cache management,...

Amazing ! They copy us before the RTL code was finish
;p

nicO


______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed Apr 18 10:20:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00380 for ; Wed, 18 Apr 2001 17:21:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:21:51 +0200 (MEST) Received: (qmail 23213 invoked by uid 0); 18 Apr 2001 08:17:26 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx26) with SMTP; 18 Apr 2001 08:17:26 -0000 X-eGroups-Return: sentto-1101623-2688-987581758-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 18 Apr 2001 08:15:59 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 08:15:58 -0000 Received: (qmail 39925 invoked from network); 18 Apr 2001 08:15:57 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Apr 2001 08:15:57 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 18 Apr 2001 08:15:57 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 18 Apr 2001 08:20:19 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200104180820.1336@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 08:20:19 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Article about the reusability of the VHDL code Content-Type: multipart/mixed; boundary="----=_NextPart_987582016_7661891117861363" Status: R X-Status: N ------=_NextPart_987582016_7661891117861363 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Some rules to respect to "compact" our code. Maybe
the use of the constant could avoid the use of
generate.

And never forget that the speed of the synthese, the
time to debug, the speed of the simulations are
totally proportional to the size of the code.
Reusability is a good way to reduice that size.

nicO


______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_987582016_7661891117861363 Content-Type: text/html; name="feature_full_syn.html" Content-Disposition: attachment; filename="feature_full_syn.html" Content-Transfer-Encoding: quoted-printable Synopsys - SolvNet - Featured Articles =09
=20 =09=20 =20
Synopsys - SolvNet - Featured Articles
=20=20=20
=20=20=20=20=20=20=09=20 VHDL Coding Styles for Reusable, Synthesizable Designs, or Create Kil= ler Code, Crush the Competition!
By: Subbu Meiyappan, Ken Jaramillo, and Peter Chambers
=20=20=20=20=20
Summary:
Behavioral (RTL) VHDL has features that can = greatly enhance the process of reusing a design. High-level languages provi= de ways to optimize and modify reusable designs without compromising the in= tegrity of the underlying design. In this paper, we explore several methods= of coding designs that allow user-customizable features and optimal synthe= sis (performance and gate count), using the native language features of VHD= L.

We also presents real-life examples of such reusable constructs and t= he results of synthesis. Designers can apply any or all of these ideas to = make their designs more feature-rich, efficient, and reusable to create mul= ti-million gate system-on-chip designs.=20=20=20=20=20

=09

1. Introduction

Design Reuse is the process of migrating or leveraging test= ed, high quality IP from one ASIC design to another. With the tremendous ad= vances in semiconductor technology, it is becoming increasingly difficult t= o bridge the gap between what technology offers and what productivity allow= s. An internal source illustrates that by the year 2001, VLSI Technology wi= ll be able to produce 64 million transistors on a chip using 0.18 micron te= chnology, which is approximately 16 million gates. Designing full-custom AS= ICs to occupy as much silicon area as possible is increasingly challenging.= To achieve the highest level of silicon efficiency, designing semi-custom = ASICs with highly reusable design entities has become the order of the day.= Design reuse, the use of pre-designed and pre-verified design blocks, is t= he most promising opportunity to bridge the gap between available gate-coun= t and designer productivity.

The design reuse movement is gaining momentum throughout the industry. One = example of this is shown by groups such as Virtual Socket Interface Allianc= e (VSIA) who are working towards setting standards for tool interfaces and = design practices for effective design reuse. Another is the large number of= conferences and user forums related to design reuse.

2. The Design Reuse Challenge

Design for reuse poses new and innovative challenges to a designer. Before = being reusable, a design must be usable, which necessitates the use of good= design practices. In order for a design to be reusable, the design must be= :
  • designed with the mindset of solving a general problem
  • well coded, commented, and documented
  • verified to a high level of confidence
  • technology independent
  • synthesis tool independent
  • simulator independent
  • application independent

Owing to the mounting pressures in schedules, some or all of these guidelin= es are usually bypassed rendering a design virtually non-reusable. However,= if these guidelines are followed, they speed the design, verification, and= debug processes of a project by reducing iterations throughout the coding = and verification loop. Thus, the efficient use and reuse of designs plays a= vital role in the creation of large ASICs with aggressive time-to-market s= chedules.

3. Hardware Description Languages

The days of schematic entry for huge designs are long gone and the design c= ommunity now understands the need for Hardware Description Languages like V= HDL and Verilog. Although HDLs have been used for some time, most designs t= oday do not use the built in "design-reuse" features of the languages thems= elves. In other words, the purpose of the HDLs has not been thoroughly unde= rstood, and their features have been misused or underused. On an average, o= nly 20% of the designs in the industry are considered reusable to any exten= t. With an increasing need for design reuse, the emphasis on coding techniq= ues for design reuse is on the rise. VLSI fully understands the need for de= sign reuse and has a plethora of reusable IP in the form of Functional Syst= em Blocks (FSBTM) delivered through HDLiTM, a design = delivery mechanism proprietary to VLSI. This paper attempts to focus on dev= eloping reusable designs using the native language features of VHDL. Becaus= e we are attempting to reuse designs for silicon efficiency, this paper con= centrates on design reuse techniques pertaining to synthesizable VHDL.

We assume the reader has a basic understanding of VHDL and its constructs. = Unless stated otherwise the VHDL in this paper complies with the VHDL-87 st= andard.

4. Features of VHDL which Promote Reusability

VHDL has been in use in the design community for over a decade. One of the = primary intents of developing designs in VHDL was reusability, although thi= s has not been the employed effectively until recently. VHDL is a feature-r= ich language that can be exploited well for reuse techniques, as is discuss= ed in the following sections. The features of VHDL that facilitate reuse ar= e:
  • Generics
  • Packages of constants
  • Generate statements
  • Unconstrained arrays
  • VHDL attributes
  • Block statements for in-line design partitioning
  • Record data types for data bundling
  • Configuration specifications
  • Tying ports off to known constants
  • Leaving unused output ports open and unconnected
  • Array aggregates
  • Functions and procedures

5. Reuse Tip #1: Generics

Generics have been used for writing parameterized models since the early da= ys of VHDL. Generics can be used to write models of varying structure and b= ehavior[2]. Presented here is a simple example of a synchronous counter wit= h modifiable structure and behavior. The modification is accomplished by th= e use of VHDL generics.

1 library ieee;

2 use ieee.std_logic_1164.all;

3 use ieee.std_logic_unsigned.all;

4

5 entity up_counter_en is

6 generic (

7 BIT_WIDTH : INTEGER :=3D 2; -- Structure

8 COUNT_ENABLE: BOOLEAN :=3D True; -- Structure

9 DOWN_COUNT : INTEGER :=3D 0; -- Behavior

10 OutDelay : TIME :=3D 3 ns -- Behavior

12 );

13 port (

14 clk : in std_logic;

15 reset_n : in std_logic;

16 en : in std_logic;

17 count : out std_logic_vector(BIT_WIDTH-1 downto 0)

18 );

19 end up_counter_en;

20

21 architecture behav of up_counter_en is

22

23 signal count_s : std_logic_vector(BIT_WIDTH-1 downto 0);

24

25 begin

26 process (clk, reset_n)

27 begin

28 if(reset_n =3D '0') then

29 count_s <=3D (others =3D> '0');

30 elsif (clk'event and clk =3D '1') then

31 if (COUNT_ENABLE =3D 1)

32 if (en =3D '1') then

33 if (DOWN_COUNT =3D 0) then

34 count_s <=3D count_s + 1;

35 else

36 count_s <=3D count_s - 1;

37 end if;

38 end if;

39 else

40 if (DOWN_COUNT =3D 0) then

41 count_s <=3D count_s + 1;

42 else

43 count_s <=3D count_s - 1;

44 end if;

45 end if;

46 end if;

47 end process;

48

49 count <=3D count_s after OutDelay;

50

51 end behav;
The example shown above illustrates the use of generics for modifying struc= ture and behavior using the language features for simulation and synthesis.= Selective features can be enabled and disabled by turning generics on and = off. For example, if the COUNT_ENABLE generic is set to FALSE in line 8, th= en none of the logic described in lines 32-38 is ever elaborated or synthes= ized, but the parent design still has the ability to have a count enable. = Using different values for OutDelay and DOWN_COUNT changes the behavior (al= though the OutDelay is ignored during synthesis) and changing BIT_WIDTH and= /or COUNT_ENABLE modifies the structure of the design. Creating designs wit= h generics enables the reuse of the design in various circumstances where d= ifferent structure or behavior is needed. For example, a design may require= two counters: one that counts up to 1024 and the other that counts up to 8= . Designing two separate counters, one that is 10-bits wide and the other 3= -bits wide, respectively has the following drawbacks:
  • Unnecessary investment in time taken to design the counters
  • Waste of resources
  • Requires more verification time and more synthesis time

On the other hand, if a counter were designed with reuse in mind using the = generic approach, a great deal of effort in terms of design, synthesis, and= verification would have been averted. Although, the use of a counter as an= example may not substantiate the use of generics, it is used as an illustr= ative example. From the authors=C6 design experiences, the use of generics = for parameterizing the structure and behavior is essential for design reuse= applications. The following examples illustrate the instantiation of the c= ounter shown above in an application that requires a 10-bit up counter and = a 3-bit down counter

1 -- Named Association:

2

3 TenBit: counter

4 generic map (

5 BIT_WIDTH =3D> 10,

6 COUNT_ENABLE =3D> true,

7 DOWN_COUNT =3D> false

8 )

9 port map (

10 clk =3D> my_clk,

11 reset_n =3D> my_reset_n,

12 en =3D> TenBit_en,

13 count =3D> TenBit_cnt

14 );

15

16 -- Positional Association:

17

18 ThreeBit: counter

19 generic map (

20 3,

21 false,

22 true,

23 4 ns

24 )

25 port map (

26 my_clk,

27 my_reset_n,

28 gnd,

29 ThreeBit_cnt

30 );
The example above illustrates the following points:

  • Lines 3-14 instantiate the counter to be used as a 10-bit up counter wi= th the count-enable logic turned on.
  • The TenBit counter instantiation uses named association for its generic= s and ports.
  • The generics whose values are not mapped in the instantiation assume de= fault values.
  • Lines 18-30 instantiate the same counter to be used as a 3-bit down cou= nter with count-enable logic turned off.
  • The ThreeBit counter instantiation uses positional association for its = generics and ports. In general however, the authors strongly discourage the= used of positional association, because changing a parameter or a port in = the reusable design requires the same modification in all of the instances.=
  • The use of generics can be of great help in terms of resources and time= when multiple instances of the same design is required.

The Effect of Generics on Synthesis

The use of generics to parameterize designs not only helps create reusable = design blocks, but also helps in removing unnecessary logic or modifying us= eful logic during synthesis. Some synthesis tools help create macros and te= mplates when designs are parameterized through generics, that can be used a= s a library element in subsequent designs for simulations and/or synthesis.= Parameterizing bus/register widths through generics is a simple example of= the use of generics.

Consider the example of the counter shown above with the following values f= or the generics:

BIT_WIDTH =3D> 2

COUNT_ENABLE =3D> true

DOWN_COUNT =3D> true

OutDelay =3D> 3 ns


When this design is elaborated during synthesis, the generic for OutDelay i= s ignored because the synthesis tools cannot handle time-delay elements in = mapping logic. The synthesis tool creates a 2-bit down-counter with the cou= nt_enable logic, as illustrated in the examples that follow.

Consider another case of the same counter with the following generics:

BIT_WIDTH =3D> 8

COUNT_ENABLE =3D> false

DOWN_COUNT =3D> false
This creates an 8-bit up-counter without the count_enable logic. In cases w= here the gate count is an important factor, unused logic can be very effici= ently optimized using this methodology. Thus the structure (changing the BI= T_WIDTH) and/or the behavior (up-counter or down-counter, count_enable disa= bled or enabled) can be modified during design, synthesis, and simulation u= sing this elegant approach to parameterization.

Generics: Summary

As we=C6ve seen from the sections above, generics can be used to add reusab= ility to a design in a very readable manner. They are excellent for specify= ing widths of counters, buses, shift registers, etc., but can be used for m= uch more. As in the example, generics can be used to turn various features = on and off. This allows a designer to use only the features which apply to = the current project. Some more examples of the types of features that gener= ics can be used to specify are as follows:
  • FIFO depths
  • Choosing between various bus interfaces (PCI, Arm System Bus, etc.)
  • Choosing a specific architecture of a particular design (up/down counte= r, counter with enable, flip flop based register vs. latched based register= , whether a register is read, write, or both, fixed arbitration scheme or r= ound robin arbitration scheme for a bus arbiter, ripple carry adder vs. car= ry look ahead adder, etc.)
  • Address of a register
  • Power-on (reset) value for a register
  • Which bits in a register are supported and which are reserved
  • Clock divide ratio for a clock divider circuit
  • Number of buffers in a clock tree

This is just a small list of the types of things that can be made parameter= izable in a design. But it can be seen that by making the design somewhat g= eneric, it becomes easier for others to reuse.

One drawback to the approach of using generics can be seen when the generic= s are used in a hierarchy. In order to apply the generics to the lowest-lev= el, the generics must pass down through the hierarchy. This may involve pas= sing generics through the blocks that do not use the value of the generics.= Another drawback to using generics is that as the list of generics grows i= t becomes more cumbersome to carry them around at each point in the hierarc= hy. Yet another drawback to using generics is that some synthesis tools ten= d to have limited support for generics (for example, requiring all generics= to be integer type). An efficient way to avoid these problems is the use o= f a package of constants, discussed in the next section.

6. Reuse Tip #2: Package of Constants

A VHDL package is a simple way of grouping a collection of related declarat= ions that serve a common purpose. The package could be made visible to the = appropriate blocks in the design by the use of library statements. This app= roach has added benefits:

  • If a new parameter is to be added or changed, there is only one central= package file that will be modified.
  • Some synthesis tools do not allow the use of Boolean, string, enumerate= d, or array types for generics. In such cases, a constant in a package coul= d be used. Most synthesis tools tend to allow most data types.
  • Packages can use TYPE statements for enumerated data types
  • When translating from VHDL to Verilog, constants map easily as define s= tatements.
  • A package used for design can also be used for simulation for "design-a= ware" test-benches.

As an example for the use of a package of constants, we will change the pr= evious counter example to use such a package. For illustrative purposes, we= will assume that the package resides in a VHDL library, referred to as pkg= s.

=FB- parameters package par_pkg.vhd

package par_pkg is

constant BIT_WIDTH : integer :=3D 10;

subtype CNT_WIDTH is integer range BIT_WIDTH-1 downto 0;

constant COUNT_ENABLE: BOOLEAN :=3D true; -- Structure

constant DOWN_COUNT : BOOLEAN :=3D false; -- Behavior

constant OutDelay : TIME :=3D 3 ns -=FB Behavior

end par_pkg;

-- reusable counter design counter.vhd

library pkgs;

use pkgs.par_pkg.all;

entity counter is

port (

clk : in std_logic

reset_n : in std_logic;

en : in std_logic;

count : out std_logic_vector(CNT_WIDTH)

)

end counter;

architecture behav of counter is

signal count_s : std_logic_vector(CNT_WIDTH);

begin

process (clk, reset_n)

begin

if (reset_n =3D =E60=C6) then

count_s <=3D (others =3D> =E60=C6);

elsif (clk=C6event and clk =3D =E61=C6) then

if (COUNT_ENABLE =3D true)

if (en =3D =E61=C6) then

if (not DOWN_COUNT) then

count_s <=3D count_s + 1;

else

count_s <=3D count_s - 1;

end if;

end if;

else

if (not DOWN_COUNT) then

count_s <=3D count_s + 1;

else

count_s <=3D count_s - 1;

end if;

end if;

end if;

end process;

count <=3D count_s after OutDelay;

end behav;
As shown in the above example, use of a package of constants is very simila= r to the use of generics for parameterization. In addition, it has the foll= owing advantages:

  • The parameters in the package can be referenced by any design entity th= at needs the information without any overhead.
  • In order to change the structure of the design, all that is necessary i= s to change the value in the package and the change is reflected in all the= units the parameter is referenced.
  • A package of constants can use subtypes and enumerated data types to re= ference the parameters for reusability and readability.
  • A central package can serve as a package of parameters to parameterize = the entire design.
  • It is relatively simple to use arrays and other composite data types fo= r parameterization using a package.
  • A package can be worked on separately as a design unit. It may be creat= ed independent of the design and reused in different parts of a model.
  • Some non-synthesizable constructs in generic definitions are usually sy= nthesizable when used in a package, such as enumerated data types.
  • The package may also contain other constants and information that may o= r may not be used for parameterization, yet may be used in the design. The = package serves as a common placeholder for this type of shared information.=
  • A package of parameters provides better code structure, provides effici= ent organization, and is self-documenting.


Examples of Synthesized Counters with Different Parameters

Example 1: Enable Logic is Disabled and the Counter Mo= de is Set=20 to Count Up

In Example 1, the Counter design was parameterized for different values of = generics and constants and synthesized to VLSI Technology Inc.=C6s 0.2 micr= on standard cell library. Synopsys was used for synthesis. We present the s= chematics for illustrative purposes; in all the example synthesis tests, th= e BIT_WIDTH parameter was maintained at 2.

In Example 1:

  • COUNT_ENABLE is false (hence the unconnected en enable signal)
  • BIT_WIDTH is 2
  • DOWN_COUNT is false (so we have a conventional up-counter)

Example 2: An Up Counter with Count Enable

  • COUNT_ENABLE is true (hence the connected en enable signal)
  • BIT_WIDTH is 2
  • DOWN_COUNT is false

Example 3: A Down Counter with No Enable

  • COUNT_ENABLE is false (hence the unconnected en enable signal)
  • BIT_WIDTH is 2
  • DOWN_COUNT is true

It is evident from the examples that structure and behavior is modified cle= anly by the values of the generics and constants. Unnecessary gates are eli= minated.

Deferred Constants

A deferred constant is one in which the constants are declared in a = package, but are not initialized in the package. Instead, the deferred cons= tants are initialized in the design that uses the constants. In other words= , the binding of the constants to a value is "deferred". Such deferred cons= tants have to be bound before they are referenced.

=FB- Deferred Constants Parameters Package pa= r_def_pkg.vhd

package par_def_pkg is

constant BIT_WIDTH : integer :=3D 10; -- Not deferred

subtype CNT_WIDTH is integer range BIT_WIDTH-1 downto 0;

constant COUNT_ENABLE: BOOLEAN; -- Deferred

constant DOWN_COUNT : BOOLEAN; -- Deferred

constant OutDelay : TIME :=3D 3 ns =FB- Behavior

end par_pkg;

-- Reusable Counter Design counter.vhd

library pkgs;

use pkgs.par_pkg.all;

entity counter is

port (

clk : in std_logic

reset_n : in std_logic;

en : in std_logic;

count : out std_logic_vector(CNT_WIDTH)

)

end counter;

architecture behav of counter is

constant COUNT_ENABLE: BOOLEAN :=3D false; -- Deferred

-- binding

constant DOWN_COUNT : BOOLEAN :=3D false; -- Deferred

-- binding

signal count_s : std_logic_vector(CNT_WIDTH);

begin

=E0

=E0

=E0

end behav;
This way, any change to the package will not require recompilation or resyn= thesis of the design counter.

The Effect of a Package of Constants on Synthesis

The package of constants has the same effect as the use of generics in modi= fying structure and/or behavior during synthesis. The package of constants = has an added advantage that composite data types can be used very effective= ly for the purposes of readability, and yet preserving the synthesizability= . And it is easier to synthesize a design which uses a package of constants= than one which uses generics. By easier we don=C6t mean it=C6s easier for = the synthesis tool, but rather that it is generally easier for an engineer = to learn how to get the synthesis tool to use the package of constants than= to use a design which uses generics. But this last fact shouldn=C6t be con= sidered as a major defect in the use of generics. It should also be borne i= n mind that some synthesis tools take longer run times when composite data = types are used.

Package Of Constants: Summary

We=C6ve seen that a package of constants can be used much the same way as g= enerics. Packages of constants tend to be easier to use than generics if th= ere are many parameters involved. Packages tend to be a better supported by= the synthesis tools than generics.

However, the use of a package of constants has the following drawbacks:
  • Multiple instances of the design with different parameters cannot be us= ed easily in a single design unit. A unique entity and a unique package nee= d to exist for each recurring design unit.
  • A change in a package that uses non-deferred constants will cause the d= esigns referring the package to be recompiled and/or resynthesized even if = a design is not affected by a parameter.
  • Needs a separate file/library to be maintained.

The use of a package of constants should be compared against the use of gen= erics for parameterization after considering the intended scope of the appl= ication. As a general practice, it is recommended to use a package of const= ants for designs that have many parameters and will not be instantiated mul= tiple times within a large design. For example, a memory controller design = (that translates host/CPU cycles into memory cycles) is very unlikely to be= instantiated multiple times in a design. Such designs should use a package= of constants. Designs such as bus interfaces, counters, adders, LFSRs etc,= should use generics for parameterization.

7. Reuse Tip #3: Generate Statements

Many digital systems can be implemented as regular iterative compositions o= f subsystems. Memories are a good example: they are composed of a rectangul= ar array of storage cells. Indeed, designers prefer to find such implementa= tions, as they make it easier to produce compact, proven, area-efficient la= yout, thus reducing cost. If a design can be expressed as a repetition of s= ome subsystem, we should be able to describe the subsystem once then descri= be how it is to be repeatedly instantiated, rather than describe each insta= ntiation individually [2].

Generate statements can be used very effectively to produce iterative struc= tures of a design. Generate statements are concurrent VHDL constructs that = may contain further concurrent statements that are to be replicated. Genera= te statements when used in conjunction with the generics or constants can b= e used to generate repetitive structures in an efficient way. Consider an e= xample where a 32-bit on-chip data-bus has to be driven off-chip using 8 o= utput enables through an output pad (IO).

entity chip is

port (

data : inout std_logic_vector (31 downto 0);

.

.

.

);

architecture pads of chip is

signal dataout : std_logic_vector (data=C6range); -- output

signal datain : std_logic_vector (data=C6range); -- input

signal dataoe : std_logic_vector (data=C6length/4-1

downto 0);

component pad is

Port (

Pad_di : out std_logic; -- input data

-- from the pad

Pad_do : in std_logic; -- driven off-chip

Pad_oe : in std_logic; -- output enable

Pad : inout std_logic -- pad itself

);

end pad;

begin

data_pad : for i in data=C6range generate

u_datapad : pad

port map (

pad_di =3D> dataint(i),

pad_do =3D> dataout(i),

pad_oe =3D> dataoe(i/4),

pad =3D> data(I)

);

end generate;
This code will instantiate 32 pad cells for the data bus. Note the use of t= he =E6range and =E6length attributes. These also promote reus= e in that they use the previously defined bus widths for the data bus. Also= note the use of the "i/4" in the assignment of the output enable signals t= o the pad cell. The synthesis tool should be intelligent enough to truncate= the division to an integer value to give to proper assignment of dataoe(3)= to data(31:24), dataoe(2) to data(23:16), and so on.

The next example illustrates the use of generate statements with iterative = structures of concurrent statements to create a register from a flip-flop.<= BR>

Reg:

For I in 0 to REG_WIDTH generate

BitFlop: process (reset_n, clk)

Begin

If (reset_n =3D =E60=C6) then

Q(I) <=3D =E60=C6;

Elsif (clk=C6event and clk =3D =E61=C6) then

If (write_en =3D =E61=C6) then

Q(I) <=3D D(I);

End if;

End if;

End process;

End generate;

 Generate statements can also be used to conditionally create, modify or rem= ove structures. This involves code level optimization, where unwanted struc= tures are removed during elaboration time. With the use of generics and/or = package of constants this technique can be very useful in creating a reusab= le design.

With the use of conditional generate statements, logic that implements a ce= rtain feature-set can be enabled or disabled, instead of hand-removing the = code or optimizing via synthesis. As an example of conditional code inclusi= on/exclusion, an output can be synchronous to the clock or combinatorial as= set by the constant :

CONSTANT SYNC_OUTPUTS : BOOLEAN : TRUE;

Then a synchronous or a combinatorial output can be generated as shown b= elow:

sync:

if (SYNC_OUTPUTS) generate

process(clk)

if (clk=C6event and clk =3D =E61=C6) then

if(rd =3D =E61=C6) then

q <=3D d;

end if;

end if;

end process;

end generate;

comb:

if (not SYNC_OUTPUTS) generate

process(rd)

if (rd =3D =E61=C6) then

q <=3D d;

end if;

end process;

end generate;

Generate Statements : Summary

The generate statement is a powerful tool to control the inclusion or exclu= sion of logic. It is very useful for designs which have blocks of logic whi= ch are used repeatedly in an iterative structure such as flip flops which t= ogether form registers, pad cells, and many other structures. Many designer= s use generate statements to instantiate cells as illustrated in the pads e= xample. But generate statements can be used to conditionally create, modify= , or remove sections of VHDL code as well. Generate statements are powerfu= l tools in promoting design reuse.

Here are a few more examples of the application of generate statements:

  • Choosing implementation of a register (latch or flip-flop based)
  • Including one or more arbitration schemes in a bus arbiter design (fixe= d arbitration, round robin, etc=E0)
  • Only including bits of an interrupt controller that we know we=C6re go= ing to use. Consider the case where interrupts coming into the interrupt co= ntroller are registered. If these inputs go through a substantial amount of= combinatorial logic before being routed to other registers, then the use o= f generate statements to only include the necessary flip flops will help th= e synthesis tools reduce the gate count significantly.

    Be aware that some synthesis tools cannot optimize across flip flops. So ev= en if we know that an input is always tied high (for example, an unused int= errupt) the synthesis tool can=C6t use this information to reduce the gate = count of the synthesized design.

8. Reuse Tip #4: Tying off Ports


In many instances logic can be selectively disabled by tying off certain po= rts to default values. When synthesized with a top-down approach, the synth= esis tool will optimize that path, taking that tied-off value into consider= ation. This technique is referred to as optimization by constant propagatio= n. The tied-off ports can later be removed from the entity. For example, in= a design which has a series of AND gates, as shown below:


If one of the inputs is tied to a =E60=C6 as shown below then the resulting= logic will eliminate all the three AND gates and the output (zo) will be a= t logic =E60=C6 always.

a1: and3

port map (

a =3D> a,

b =3D> =E60=C6, -- Valid VHDL 93, Tied off to

-- VSS <=3D =E60=C6 in 87

c =3D> c,

zo =3D> zo

);
The same is true for port outputs. By leaving unused port outputs open (zo = =3D> open) we can optimize away the logic which creates them.

9. Reuse Tip #5: Unconstrained Arrays

Use of unconstrained arrays is a great way to reuse designs for variable-wi= dth implementations. Care should be taken while using attributes like =E6ra= nge, =E6length etc. inside the design to avoid run-time and elaboration-tim= e errors. Unconstrained arrays are particularly suitable for address, data,= and register widths. They may be used for formal parameters in functions = and procedures as well as entity ports.

VHDL allows the use of unconstrained array types that let us indicate the = type of index values without specifying the bounds. Unconstrained arrays co= me in handy to make reusable designs that may be reused in various applicat= ions, by just modifying their bit-widths. As an example, our counter exampl= e can be designed using unconstrained arrays for the count output as shown = below:

entity counter is

port (

clk : in std_logic

reset_n : in std_logic;

count : out std_logic_vector -- Unconstrained array

)

end counter;

architecture behav of counter is

signal count_s : std_logic_vector(count=C6range) -- Same as count

begin

process (clk, reset_n)

begin

if(reset_n =3D =E60=C6) then

count_s <=3D (count=C6range =3D> =E60=C6);

elsif (clk=C6event and clk =3D =E61=C6) then

count_s <=3D count_s + 1;

end if;

end process;

count <=3D count_s;

end behav;

This lets us connect the counter entity to array signals of any size or wit= h any range of index values. Note the use of the VHDL attribute =E6range to= create a signal of the same width and range specification as the port coun= t itself. Note that this design is not synthesizable by itself and has to = be instantiated in a top level entity to bind the array values to a finite= range as in the following example:

architecture inst of top is

begin

signal my_count : std_logic_vector(7 downto 0);

signal clk, reset_n : std_logic;

cnt: counter

port map

( clk =3D> clk,

reset_n =3D> reset_n,

count =3D> my_count

);

..

..

..

end inst;


The code above must be synthesized in a top-down manner so that the counter= is synthesized along with the rest of the design.
Another use of unconstrained arrays is in functions and procedures. Functio= ns and procedures that are intended to be synthesizable should be written a= s general as possible, independent of bit widths.


Consider an example of a binary code to gray code converter. In order t= o create a gray code from a given binary code we use the algorithm shown in= the figure below:


Here is an example where we convert binary 100 to its gray code equivalent = of 110:


The following table shows the gray codes for three-bit binary values:

Binary

Gray

000

000

001

001

010

011

011

010

100

110

101

111

110

101

111

100


If this algorithm were hard coded and optimized for a 3-bit case, then when= the design has to accommodate more counts, this function has to change, an= d hence the entire logic has to be revalidated. By writing a generic functi= on independent of the bit-vector lengths, efficient reuse is possible. A bi= t-width independent implementation for the binary code to gray code convert= er is shown below.

As another example, consider the functions and procedures in the IEEE std_l= ogic libraries. Most of these functions and procedures are implemented usin= g unconstrained arrays to support efficient reuse.

function Bin2Gray( x : std_logic_vector ) return std_logic_vector = is

variable y : std_logic_vector( x'range );

begin

for j in x'range loop

if j =3D x'left then

y(j) :=3D x(j);

else

y(j) :=3D x(j) xor x(j+1);

end if;

end loop;

return y;

end;

10. Reuse Tip #6: Configuration Specifications

Configuration specifications are used to bind the component instances to de= sign entities. Configurations can be used for a variety of purposes:

  • For passing parameters as generics at the top-most level in a test benc= h;
  • For choosing between architectures for a particular entity;
  • For overriding port mappings in an instantiation.

Note that some synthesis tools do not support configuration specifications.=

Consider the previous counter example that illustrated the use of generics = for parameterization. The following example illustrates the same counter wi= th another architecture (buffered) that buffers the counter outputs with a = generate statement.

library ieee;

use ieee.std_logic_1164.all;

architecture buffered of counter is

signal count_s : std_logic_vector(BIT_WIDTH-1 downto 0);

component non_inv_buffer

port (i : in std_logic;

z : out std_logic);

end component;

begin

process (clk, reset_n)

begin

if(reset_n =3D '0') then

count_s <=3D (others =3D> '0');

elsif (clk'event and clk =3D '1') then

if (COUNT_ENABLE =3D 1)

if (en =3D '1') then

if (DOWN_COUNT =3D 0) then

count_s <=3D count_s + 1;

else

count_s <=3D count_s - 1;

end if;

end if;

else

if (DOWN_COUNT =3D 0) then

count_s <=3D count_s + 1;

else

count_s <=3D count_s - 1;

end if;

end if;

end if;

end process;

bufG : for index in BIT_WIDTH-1 downto 0 generate

nib_i : non_inv_buffer port map (

i =3D> count_s(index),

z =3D> count(index)

);

end generate bufG;

end buffered;
The above counter is now instantiated in a top-level design where two insta= nces of the counter are used:

library ieee;

use ieee.std_logic_1164.all;

entity top is

end top;

-- Some top level that uses different counters

architecture inst of top is

constant BIT_WIDTH : integer :=3D 8;

signal clk : std_logic;

signal gp_count, wd_count : std_logic_vector ( bit_width - 1 downto 0 = );

signal en : std_logic;

signal reset_n : std_logic;

component counter

port (

clk : in std_logic;

reset_n : in std_logic;

en : in std_logic;

count : out std_logic_vector(BIT_WIDTH-1 downto 0)

);

end component;

begin

gpcntr: counter port map (

clk =3D> clk,

reset_n =3D> reset_n,

en =3D> en,

count =3D> gp_count

);

wdcntr: counter port map (

clk =3D> clk,

reset_n =3D> reset_n,

en =3D> en,

count =3D> wd_count

);

-- Other stuff

end inst;
The counter in the entity top is configured by a configuration specificatio= n, as shown below. Configuration specifications permit various levels of th= e design=C6s hierarchy to be configured:

library cntr_lib, vlsi_lib;

configuration cntr_cfg of top is

for inst

for gpcntr : counter use entity cntr_lib.counter(behav)

generic map (COUNT_ENABLE =3D> 1,

DOWN_COUNT =3D> 1);

end for;

for wdcntr : counter use entity cntr_lib.counter(buffered)

generic map (COUNT_ENABLE =3D> 1,

DOWN_COUNT =3D> 0);

for buffered

for bufG -- Configure the generate statement

for nib_i : non_inv_buffer use entity vlsi_lib.ni01d2(rtl);<= /P>

end for;

end for; -- End bufG

end for; -- End buffered

end for; -- End wdcntr

end for; -- End inst

end cntr_cfg;

11. Reuse Tip #7: VHDL attributes that aid Reuse and are Synthesizable=

A few attributes of composite types are very useful in creating reusable de= signs. The attributes

  • 'left
  • 'right
  • 'range
  • 'length
  • 'low
  • 'high

are synthesizable and make the code independent of the data type. Refer to = the example of the unconstrained arrays where the function Gray2bin and the= entity counter use the 'range attribute, thus promoting reusability.

12. Reuse Tip #8: Use of Block Statements for Design Reuse

Block statements are VHDL constructs that allow inline design partitioning.= For example, if a design has been partitioned such that the data path exis= ts in a separate VHDL entity, then the architecture for that entity, can in= turn be partitioned using block statements. Block statements are a great w= ay to group related logic together. Block statements also provide the facil= ity to declare signals within the blocks and hence if that block is removed= , unnecessary signals will not dangle (remain unconnected) in the code. A g= enerate statement can be combined with the block statement to selectively i= nclude/exclude blocks.

14. Reuse Tip #9: Use of a Preprocessor for Enhancing VHDL Features There are number of situations when the designer is not able to accomplish = what they want using the available features. And in some cases, it is desir= able to see only the code that is relevant to the design. In such cases, a = preprocessor can be used to add, eliminate, or modify code for a specific a= pplication, through the use of preprocessor directives.

For example, VLSI developed a tool referred to as HDLi. It is used as a ve= hicle for reusable IP delivery. HDLi uses a subset of its own commands to m= odify VHDL/Verilog code for a specific application. The desired design feat= ures are specified through an interactive GUI. This solution has few limita= tions in terms of maintainability, testability and the numerous combination= s of logic that can possibly be produced.

15. References

The following documents provide a variety of useful references for writing = synthesizable VHDL:
  1. Meiyappan, S, Chambers, P, "Design Reuse Using Scripting Methodologies,= " DesignCon 98, On-Chip System Design Conference, Santa Clara, CA, Jan 1998= , PP 629-643
  2. Ashenden, P.J, The Designer=C6s Guide to VHDL, Morgan Kaufmann Publishe= rs, San Francisco, CA, 1996.
  3. Smith, Douglas J., "HDL Chip Design," Doone Publications, 1996.
  4. http://www.vlsi.com/products/design.shtml
=20 =09=20=20 =20 =09=20
SOLVNET HOME | MY PROFILE | FEEDBACK | HELP | LO= GOUT
(C) Copyright 2001. Synopsys, Inc. All Rights Re= served. - Privacy Policy
/=19 ------=_NextPart_987582016_7661891117861363-- From Wed Apr 18 10:37:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00383 for ; Wed, 18 Apr 2001 17:21:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:21:59 +0200 (MEST) Received: (qmail 2717 invoked by uid 0); 18 Apr 2001 08:32:59 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx16) with SMTP; 18 Apr 2001 08:32:59 -0000 X-eGroups-Return: sentto-1101623-2689-987582776-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hn.egroups.com with NNFMP; 18 Apr 2001 08:32:56 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 08:32:55 -0000 Received: (qmail 89973 invoked from network); 18 Apr 2001 08:32:55 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 18 Apr 2001 08:32:55 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 18 Apr 2001 08:32:55 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 18 Apr 2001 08:37:20 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200104180837.14df@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 08:37:20 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Simputer and its gpl like licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N cf http://simputer.org/license/sgplv1.html
The think stupid is that they use the terme of
Simputer every 2 lines. Maybe we could see if such
licence could be a based to a hardware GPL.

nicO


______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Apr 18 10:37:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00386 for ; Wed, 18 Apr 2001 17:22:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:22:00 +0200 (MEST) Received: (qmail 16443 invoked by uid 0); 18 Apr 2001 08:44:46 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx03) with SMTP; 18 Apr 2001 08:44:46 -0000 X-eGroups-Return: sentto-1101623-2690-987583481-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 18 Apr 2001 08:44:42 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 08:44:41 -0000 Received: (qmail 81470 invoked from network); 18 Apr 2001 08:44:41 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Apr 2001 08:44:40 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 18 Apr 2001 08:44:40 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id BAA04939; Wed, 18 Apr 2001 01:44:38 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9MD7; Wed, 18 Apr 2001 09:50:43 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3ADD5239.F419D842@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104180816.06cf@lh00.opsion.fr> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 10:37:13 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] SH-5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N nicolas.boulay@ifrance.com wrote:
> Maybe have you heard about the SH-5. It's the last 64
> bits beast from Hitachi and ST-microelectronics.
> Whygee said that was not so good, few weeks ago.
<snip>
> Amazing ! They copy us before the RTL code was finish
> ;p

I said that i wasn't afraid because the F-CPU and FC0
are still differing a lot. The instruction set, the scheduling,
the memory interface...

Remember : F-CPU has only register adressing mode, which
completely changes how the CPU is programmed and designed.
SH5 has some mechanisms for branches but that doesn't work
as in the F-CPU : there are 8 branch target buffers, while
F-CPU can have any of its 64 register pointing to branch
targets (from the programming point of view). This decouples
the HW from the SW, while SH5 is more like a "throw away
instruction set".
SH5 is nice for embedded graphics and stuffs like that.
Now if you want "real" scalability and orthogonality,
F-CPU is the winner. F-CPU is not "only" a game console CPU ;-)

ok, i gotta work.... grrrr.... 2 weeks left....

> nicO
YG

speaking for himself
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Wed Apr 18 11:03:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00389 for ; Wed, 18 Apr 2001 17:22:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:22:00 +0200 (MEST) Received: (qmail 14747 invoked by uid 0); 18 Apr 2001 09:03:48 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx22) with SMTP; 18 Apr 2001 09:03:48 -0000 X-eGroups-Return: sentto-1101623-2691-987584626-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 18 Apr 2001 09:03:46 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 09:03:46 -0000 Received: (qmail 9253 invoked from network); 18 Apr 2001 09:03:45 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Apr 2001 09:03:45 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 18 Apr 2001 09:03:45 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id MAA01236 for ; Wed, 18 Apr 2001 12:03:43 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <200104180820.1336@lh00.opsion.fr> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 12:03:41 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Article about the reusability of the VHDL code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 18 Apr 2001 nicolas.boulay@ifrance.com wrote:

> And never forget that the speed of the synthese, the
> time to debug, the speed of the simulations are
> totally proportional to the size of the code.
> Reusability is a good way to reduice that size.

In simulations that is not the whole truth. If you instantiate same
generic block many times with different parameters, the simulation time
will be roughly the same as if you would copy it as a code. In simulations
the amount of signals and events is the critical thing and each
instantiated block has its own state.

But coding style can have big effect to the simulation speed. For example
usage of integer/unsigned instead of wide bit vectors reduces the
simulation size and is much faster (roughly faster by the amount of bits
in the vector). Also extra events should be avoided because they slow down
the simulation. There are also many other tricks to speed up the
simulations which I have somewhere written down :)

In synthesis the tools have more effect to the time it takes. For example
in FPGA synthesis Synopsys FPGA compiler II can take 10x more time to do
the same chip than Synplify (and the Synopsys chip is slower and bigger
:)) Leonardo is not so bad, but sometimes take 2-5x more time to
synthesize the design.

Synopsys is just slow synthesizer. Hopefully someone can break into their
ASIC monopoly with faster and easier to use tool :)

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Rares Marian Wed Apr 18 12:01:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00401 for ; Wed, 18 Apr 2001 17:22:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:22:04 +0200 (MEST) Received: (qmail 24964 invoked by uid 0); 18 Apr 2001 09:55:01 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx15) with SMTP; 18 Apr 2001 09:55:01 -0000 X-eGroups-Return: sentto-1101623-2692-987587657-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 18 Apr 2001 09:54:20 -0000 X-Sender: rares@moonbase.res.wpi.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 09:54:17 -0000 Received: (qmail 8764 invoked from network); 18 Apr 2001 09:54:16 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 18 Apr 2001 09:54:16 -0000 Received: from unknown (HELO moonbase.res.wpi.net) (130.215.231.27) by mta1 with SMTP; 18 Apr 2001 09:54:16 -0000 Received: by moonbase.res.wpi.net (Postfix, from userid 1000) id A217E3AFF; Wed, 18 Apr 2001 06:01:18 -0400 (EDT) To: f-cpu@yahoogroups.com Message-ID: <20010418060118.A9066@moonbase.res.wpi.net> References: <200104180837.14df@lh00.opsion.fr> In-Reply-To: <200104180837.14df@lh00.opsion.fr>; from nicolas.boulay@ifrance.com on Wed, Apr 18, 2001 at 04:37:20 -0400 X-Mailer: Balsa 1.0.pre5 From: Rares Marian MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 06:01:18 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Simputer and its gpl like licence Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N I've thought about the F-CPU licensing and have come to the following
conclusion:

Documentation Licenses have no bearing on the machine.  So if I got an
F-CPU from IBM labs and I wanted to change it I wouldn't have any right to
do so.

We'll have to to be clear on what we really want.




On Wed, 18 Apr 2001 04:37:20 nicolas.boulay@ifrance.com wrote:
> cf http://simputer.org/license/sgplv1.html
> The think stupid is that they use the terme of
> Simputer every 2 lines. Maybe we could see if such
> licence could be a based to a hardware GPL.
>
> nicO
>
> 
> ______________________________________________________________________________
> ifrance.com, l'email gratuit le plus complet de l'Internet !
> vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--


Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed Apr 18 14:52:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00428 for ; Wed, 18 Apr 2001 17:22:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:22:11 +0200 (MEST) Received: (qmail 30421 invoked by uid 0); 18 Apr 2001 12:48:09 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx05) with SMTP; 18 Apr 2001 12:48:09 -0000 X-eGroups-Return: sentto-1101623-2693-987598074-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 18 Apr 2001 12:47:55 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 12:47:54 -0000 Received: (qmail 87297 invoked from network); 18 Apr 2001 12:47:53 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 Apr 2001 12:47:53 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 18 Apr 2001 12:47:52 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 18 Apr 2001 12:52:13 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200104181252.0d6e@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 12:52:13 GMT Reply-To: f-cpu@yahoogroups.com Subject: Rep:Re: [f-cpu] Article about the reusability of the VHDL code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Up to date simulator try to make hierarchical
simulation, and avoid to inctanciate each time the
same block. So it's depend on the simulator but for
the "future" it could be a nice habit to take.

nicO

-----Message d'origine-----
De: Kim Enkovaara <kenkovaa@cc.hut.fi>
A: f-cpu@yahoogroups.com
Date: 18/04/01
Objet: Re: [f-cpu] Article about the reusability of
the VHDL code

On Wed, 18 Apr 2001 nicolas.boulay@ifrance.com wrote:

> And never forget that the speed of the synthese,
the
> time to debug, the speed of the simulations are
> totally proportional to the size of the code.
> Reusability is a good way to reduice that size.

In simulations that is not the whole truth. If you
instantiate same
generic block many times with different parameters,
the simulation time
will be roughly the same as if you would copy it as a
code. In simulations
the amount of signals and events is the critical
thing and each
instantiated block has its own state.

But coding style can have big effect to the
simulation speed. For example
usage of integer/unsigned instead of wide bit vectors
reduces the
simulation size and is much faster (roughly faster by
the amount of bits
in the vector). Also extra events should be avoided
because they slow down
the simulation. There are also many other tricks to
speed up the
simulations which I have somewhere written down :)

In synthesis the tools have more effect to the time
it takes. For example
in FPGA synthesis Synopsys FPGA compiler II can take
10x more time to do
the same chip than Synplify (and the Synopsys chip is
slower and bigger
:)) Leonardo is not so bad, but sometimes take 2-5x
more time to
synthesize the design.

Synopsys is just slow synthesizer. Hopefully someone
can break into their
ASIC monopoly with faster and easier to use tool :)

=====================================================
========================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi |
Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            |
curved-space fault in
02630 Espoo         |                      |
write-only file system


------------------------ Yahoo! Groups Sponsor



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Wed Apr 18 15:12:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00437 for ; Wed, 18 Apr 2001 17:22:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 17:22:14 +0200 (MEST) Received: (qmail 21517 invoked by uid 0); 18 Apr 2001 13:12:46 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx04) with SMTP; 18 Apr 2001 13:12:46 -0000 X-eGroups-Return: sentto-1101623-2694-987599563-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 18 Apr 2001 13:12:45 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 13:12:42 -0000 Received: (qmail 33570 invoked from network); 18 Apr 2001 13:12:41 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 18 Apr 2001 13:12:41 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta2 with SMTP; 18 Apr 2001 13:12:41 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA05136 for ; Wed, 18 Apr 2001 16:12:39 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <200104181252.0d6e@lh00.opsion.fr> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 16:12:37 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: Rep:Re: [f-cpu] Article about the reusability of the VHDL code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 18 Apr 2001 nicolas.boulay@ifrance.com wrote:

> Up to date simulator try to make hierarchical
> simulation, and avoid to inctanciate each time the
> same block. So it's depend on the simulator but for
> the "future" it could be a nice habit to take.

Do you know what simulators actually support this? I coudn't find any data
that Modelsim, Scirocco, VCS or NC-Sim supports this. I can't either think
how you can maintain state information of the blocks without instantiating
their events and signals.


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Wed Apr 18 17:36:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA01169 for ; Wed, 18 Apr 2001 23:20:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 18 Apr 2001 23:20:40 +0200 (MEST) Received: (qmail 28270 invoked by uid 0); 18 Apr 2001 20:14:47 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx08) with SMTP; 18 Apr 2001 20:14:47 -0000 X-eGroups-Return: sentto-1101623-2695-987624879-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c9.egroups.com with NNFMP; 18 Apr 2001 20:14:40 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 18 Apr 2001 20:14:38 -0000 Received: (qmail 49562 invoked from network); 18 Apr 2001 20:14:37 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 Apr 2001 20:14:37 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.208) by mta2 with SMTP; 18 Apr 2001 20:14:35 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01349; Wed, 18 Apr 2001 17:36:53 +0200 Message-ID: <20010418173653.56580@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200104180820.1336@lh00.opsion.fr> X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Wed, Apr 18, 2001 at 12:03:41PM +0300 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Apr 2001 17:36:53 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Article about the reusability of the VHDL code Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, Apr 18, 2001 at 12:03:41PM +0300, Kim Enkovaara wrote:

[...]
> But coding style can have big effect to the simulation speed. For example
> usage of integer/unsigned instead of wide bit vectors reduces the
> simulation size and is much faster (roughly faster by the amount of bits
> in the vector). Also extra events should be avoided because they slow down
> the simulation. There are also many other tricks to speed up the
> simulations which I have somewhere written down :)

The problem with integers is that they're limited to 32 bits in
most tools.  Thus, we cannot use them to represent registers, ports,
addresses and so on (which are alle 64-bit quantities in the F-CPU).

It is helpful, however, to reduce the number of processes (including
stand-alone concurrent signal assignments) and events, at least for
simulation.  But I don't know how it affects synthesis, and I heard
(or rather, read) very different opinions so far.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Fri Apr 20 00:12:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00693 for ; Thu, 19 Apr 2001 22:39:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Apr 2001 22:39:13 +0200 (MEST) Received: (qmail 4361 invoked by uid 0); 19 Apr 2001 20:19:59 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx27) with SMTP; 19 Apr 2001 20:19:59 -0000 X-eGroups-Return: sentto-1101623-2696-987711597-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 19 Apr 2001 20:19:58 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 19 Apr 2001 20:19:56 -0000 Received: (qmail 85449 invoked from network); 19 Apr 2001 20:19:55 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 19 Apr 2001 20:19:55 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 19 Apr 2001 20:19:54 -0000 Received: from art1.none.de (dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f3JKJx630397 for ; Thu, 19 Apr 2001 22:19:59 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14qMfL-00006I-00 for ; Fri, 20 Apr 2001 00:12:43 +0200 To: f-cpu@yahoogroups.com Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Apr 2001 00:12:43 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] FCPU-Manual Translation into German Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

I 've created a cvs-repository for german translations of the
F-CPU-Manual. If anybody interested in translating (Kristian-Ole!) please
don't hesitate to contact me for writeaccess.

The CVS is available via http://gaos.org/cgi-bin/cvsweb.cgi

In CVS there are also some notes how I translated something.

Kristian-Ole:
      Please contact me via eMail.

Thnx.

Bye Andreas
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Fri Apr 20 00:18:18 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00696 for ; Thu, 19 Apr 2001 22:39:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Apr 2001 22:39:14 +0200 (MEST) Received: (qmail 31055 invoked by uid 0); 19 Apr 2001 20:20:02 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx10) with SMTP; 19 Apr 2001 20:20:02 -0000 X-eGroups-Return: sentto-1101623-2697-987711600-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 19 Apr 2001 20:20:01 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 19 Apr 2001 20:20:00 -0000 Received: (qmail 86826 invoked from network); 19 Apr 2001 20:19:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 19 Apr 2001 20:19:57 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta2 with SMTP; 19 Apr 2001 20:19:56 -0000 Received: from art1.none.de (dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f3JKJv630213 for ; Thu, 19 Apr 2001 22:20:01 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14qMkk-00006U-00 for ; Fri, 20 Apr 2001 00:18:18 +0200 To: f-cpu@yahoogroups.com Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Apr 2001 00:18:18 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

This mail is a notify message only.

I want to tell something about F-CPU-Project on a lecture in may 2001 in
Leipzig. Also at http://gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository
with upcoming lecture (today only some ideas in a Readme-file, nothing
foils yet). The lecture is in German.

Bye Andreas
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From AlterCom - Mobile Thu Apr 19 22:34:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA00699 for ; Thu, 19 Apr 2001 22:39:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 19 Apr 2001 22:39:15 +0200 (MEST) Received: (qmail 24095 invoked by uid 0); 19 Apr 2001 20:34:26 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx16) with SMTP; 19 Apr 2001 20:34:26 -0000 X-eGroups-Return: sentto-1101623-2698-987712464-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 19 Apr 2001 20:34:25 -0000 X-Sender: admin@altercom.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 19 Apr 2001 20:34:23 -0000 Received: (qmail 21811 invoked from network); 19 Apr 2001 20:34:23 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 19 Apr 2001 20:34:23 -0000 Received: from unknown (HELO femail2.sdc1.sfba.home.com) (24.0.95.82) by mta1 with SMTP; 19 Apr 2001 20:34:23 -0000 Received: from altercom.com ([24.181.102.252]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010419203354.BANI28160.femail2.sdc1.sfba.home.com@altercom.com> for ; Thu, 19 Apr 2001 13:33:54 -0700 Message-ID: <3ADF4BF2.22AB7B98@altercom.com> X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: AlterCom - Mobile MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Apr 2001 15:34:59 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi!,

You guys need to stop now, do not pass go, do not
collect 200 packets and contact Donald Knuth. He
puts his chip designs into public domain. One of his
colleagues, John Hennessey, designed the MIPS
chip and one of his students, Dick Sites designed
the Alpha chip

MMIX, A RISC Computer for the New Millennium

http://technetcast.ddj.com/tnc_catalog.html?item_id=421

J :-)

Andreas Romeyke wrote:

> Hello,
>
> This mail is a notify message only.
>
> I want to tell something about F-CPU-Project on a lecture in may 2001 in
> Leipzig. Also at http://gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository
> with upcoming lecture (today only some ideas in a Readme-file, nothing
> foils yet). The lecture is in German.
>
> Bye Andreas
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Thu Apr 19 15:02:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA01930 for ; Fri, 20 Apr 2001 05:53:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 20 Apr 2001 05:53:56 +0200 (MEST) Received: (qmail 29366 invoked by uid 0); 20 Apr 2001 00:46:35 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx01) with SMTP; 20 Apr 2001 00:46:35 -0000 X-eGroups-Return: sentto-1101623-2699-987727467-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 20 Apr 2001 00:46:15 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 20 Apr 2001 00:44:26 -0000 Received: (qmail 88260 invoked from network); 20 Apr 2001 00:44:26 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 20 Apr 2001 00:44:26 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 20 Apr 2001 00:44:25 -0000 Received: from jetnet.ab.ca (dialin57.jetnet.ab.ca [207.153.6.57]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA09336 for ; Thu, 19 Apr 2001 18:44:23 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3ADEE1CF.84FA5086@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Apr 2001 07:02:07 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N AlterCom - Mobile wrote:
>
> Hi!,
>
> You guys need to stop now, do not pass go, do not
> collect 200 packets and contact Donald Knuth. He
> puts his chip designs into public domain. One of his
> colleagues, John Hennessey, designed the MIPS
> chip and one of his students, Dick Sites designed
> the Alpha chip
>
> MMIX, A RISC Computer for the New Millennium
>
> http://technetcast.ddj.com/tnc_catalog.html?item_id=421

'take a ride on the Reading railroad....'
Hmm nice work, but I don't find the architecture
of MMIX that usable of a design.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Apr 21 03:31:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id FAA04848 for ; Sat, 21 Apr 2001 05:54:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 21 Apr 2001 05:54:26 +0200 (MEST) Received: (qmail 32113 invoked by uid 0); 21 Apr 2001 01:33:48 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx10) with SMTP; 21 Apr 2001 01:33:48 -0000 X-eGroups-Return: sentto-1101623-2700-987816826-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 21 Apr 2001 01:33:47 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 01:33:46 -0000 Received: (qmail 80626 invoked from network); 21 Apr 2001 01:33:45 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 21 Apr 2001 01:33:45 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta3 with SMTP; 21 Apr 2001 01:33:45 -0000 Received: from f-cpu.org (nas4-103.ras.club-internet.fr [195.36.203.103]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22551 for ; Sat, 21 Apr 2001 03:33:37 +0200 (MET DST) Message-ID: <3AE0E301.3DDDBE2B@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 03:31:45 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

> Hello,
>
> This mail is a notify message only.
>
> I want to tell something about F-CPU-Project on a lecture in may 2001 in
> Leipzig. Also at http://gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository
> with upcoming lecture (today only some ideas in a Readme-file, nothing
> foils yet). The lecture is in German.
>
> Bye Andreas

i'll be interested to read that :-)
I have not checked the site yet however.
keep us informed :-)


Ben Franchuk wrote:
> AlterCom - Mobile wrote:
> >
> > Hi!,
> >
> > You guys need to stop now, do not pass go, do not
> > collect 200 packets and contact Donald Knuth.
is he "really" reachable ? :*)

> > He puts his chip designs into public domain.
nice, but the f-cpu works with more legal control
and with the GNU Public Licence.

> > One of his
> > colleagues, John Hennessey, designed the MIPS
> > chip and one of his students, Dick Sites designed
> > the Alpha chip
yeah, but the MMIX is not even as good as the ALPHA :-P

> > MMIX, A RISC Computer for the New Millennium
> > http://technetcast.ddj.com/tnc_catalog.html?item_id=421
>
> 'take a ride on the Reading railroad....'
> Hmm nice work, but I don't find the architecture
> of MMIX that usable of a design.

indeed.
but more importantly, the goals differ.
F-CPU is designed to be an alternative
that must be industrially viable.
MMIX is "only" a "toy CPU" designed only for the
sake of illustrating examples in the AOCP series.
I respect Knuth and his goals, but anybody
can look back at the F-CPU archive and read
why the F-CPU group didn't chose to design either
a MMIX, a DLX, a MIPS, etc...

On top of that, the MMIX is not scaleable as F-CPU can be.
sure, there are some SIMD instructions, but there is
no way to provide future CLEAN extensions.
And there are some F-CPU characteristics that
i have tasted and don't want to give away :-)
All the existing designs look sadly oldfashioned
to me since FC0 appeared :-)

OK, i'll be in Dortmund next week.
it's gonna be exciting.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From AlterCom - Mobile Sat Apr 21 14:45:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00314 for ; Sun, 22 Apr 2001 01:55:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:24 +0200 (MEST) Received: (qmail 14538 invoked by uid 0); 21 Apr 2001 12:45:11 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx24) with SMTP; 21 Apr 2001 12:45:11 -0000 X-eGroups-Return: sentto-1101623-2701-987857109-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mr.egroups.com with NNFMP; 21 Apr 2001 12:45:09 -0000 X-Sender: admin@altercom.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 12:45:08 -0000 Received: (qmail 64035 invoked from network); 21 Apr 2001 12:45:08 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 21 Apr 2001 12:45:08 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta2 with SMTP; 21 Apr 2001 12:45:08 -0000 Received: from altercom.com ([24.181.102.252]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010421124440.CEOP24191.femail1.sdc1.sfba.home.com@altercom.com> for ; Sat, 21 Apr 2001 05:44:40 -0700 Message-ID: <3AE180FE.8F6FE0C7@altercom.com> X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> <3AE0E301.3DDDBE2B@f-cpu.org> From: AlterCom - Mobile MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 07:45:50 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi! I mentioned Donald E. Knuth mostly due to his genius in chip designs. Reinventing the wheel is may not be a good idea if one wants quick time to market. Just because his designs are public domain don't mean they can't be used in GPL. Heck, he claims the Intel MMX technology is based o n his MMIX. I feel if was told about the Freedom CPU project he would be excited to join in helping. This does not mean all his designs if any at all need to be used. However, his designs are what he has been interested in and not what the Freedom CPU team is. I think getting with him and his colleagues or if nothing else reviewing his chip designs would be very beneficial. He has a new chip design now and if you read his site its all about volunteer team worker Another project for which I'll soon be seeking volunteers is the job of converting MIX programs to a new RISC computer; see the MMIX page. . Yeah,..the Alpha is a better chip but he designed the MMIX processor 30 years ago. :-) Jim :-) Yann Guidon wrote: > hi ! > > > Hello, > > > > This mail is a notify message only. > > > > I want to tell something about F-CPU-Project on a lecture in may 2001 in > > Leipzig. Also at http://gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository > > with upcoming lecture (today only some ideas in a Readme-file, nothing > > foils yet). The lecture is in German. > > > > Bye Andreas > > i'll be interested to read that :-) > I have not checked the site yet however. > keep us informed :-) > > Ben Franchuk wrote: > > AlterCom - Mobile wrote: > > > > > > Hi!, > > > > > > You guys need to stop now, do not pass go, do not > > > collect 200 packets and contact Donald Knuth. > is he "really" reachable ? :*) > > > > He puts his chip designs into public domain. > nice, but the f-cpu works with more legal control > and with the GNU Public Licence. > > > > One of his > > > colleagues, John Hennessey, designed the MIPS > > > chip and one of his students, Dick Sites designed > > > the Alpha chip > yeah, but the MMIX is not even as good as the ALPHA :-P > > > > MMIX, A RISC Computer for the New Millennium > > > http://technetcast.ddj.com/tnc_catalog.html?item_id=421 > > > > 'take a ride on the Reading railroad....' > > Hmm nice work, but I don't find the architecture > > of MMIX that usable of a design. > > indeed. > but more importantly, the goals differ. > F-CPU is designed to be an alternative > that must be industrially viable. > MMIX is "only" a "toy CPU" designed only for the > sake of illustrating examples in the AOCP series. > I respect Knuth and his goals, but anybody > can look back at the F-CPU archive and read > why the F-CPU group didn't chose to design either > a MMIX, a DLX, a MIPS, etc... > > On top of that, the MMIX is not scaleable as F-CPU can be. > sure, there are some SIMD instructions, but there is > no way to provide future CLEAN extensions. > And there are some F-CPU characteristics that > i have tasted and don't want to give away :-) > All the existing designs look sadly oldfashioned > to me since FC0 appeared :-) > > OK, i'll be in Dortmund next week. > it's gonna be exciting. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From AlterCom - Mobile Sat Apr 21 14:56:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00317 for ; Sun, 22 Apr 2001 01:55:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:25 +0200 (MEST) Received: (qmail 23112 invoked by uid 0); 21 Apr 2001 12:56:54 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx27) with SMTP; 21 Apr 2001 12:56:54 -0000 X-eGroups-Return: sentto-1101623-2702-987857746-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 21 Apr 2001 12:55:46 -0000 X-Sender: admin@altercom.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 12:55:45 -0000 Received: (qmail 90920 invoked from network); 21 Apr 2001 12:55:45 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 21 Apr 2001 12:55:45 -0000 Received: from unknown (HELO femail1.sdc1.sfba.home.com) (24.0.95.81) by mta3 with SMTP; 21 Apr 2001 12:55:45 -0000 Received: from altercom.com ([24.181.102.252]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010421125517.CJLL24191.femail1.sdc1.sfba.home.com@altercom.com> for ; Sat, 21 Apr 2001 05:55:17 -0700 Message-ID: <3AE1837A.C480A93C@altercom.com> X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> <3AE0E301.3DDDBE2B@f-cpu.org> From: AlterCom - Mobile MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 07:56:28 -0500 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi! Correction,. The MIX processor is 30 years old. "The designers of important real-world processor chips (e.g., MIPS and ALPHA) have helped me with the design of MMIX. So I'm excited about the prospects." Jim :-) Yann Guidon wrote: > hi ! > > > Hello, > > > > This mail is a notify message only. > > > > I want to tell something about F-CPU-Project on a lecture in may 2001 in > > Leipzig. Also at http://gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository > > with upcoming lecture (today only some ideas in a Readme-file, nothing > > foils yet). The lecture is in German. > > > > Bye Andreas > > i'll be interested to read that :-) > I have not checked the site yet however. > keep us informed :-) > > Ben Franchuk wrote: > > AlterCom - Mobile wrote: > > > > > > Hi!, > > > > > > You guys need to stop now, do not pass go, do not > > > collect 200 packets and contact Donald Knuth. > is he "really" reachable ? :*) > > > > He puts his chip designs into public domain. > nice, but the f-cpu works with more legal control > and with the GNU Public Licence. > > > > One of his > > > colleagues, John Hennessey, designed the MIPS > > > chip and one of his students, Dick Sites designed > > > the Alpha chip > yeah, but the MMIX is not even as good as the ALPHA :-P > > > > MMIX, A RISC Computer for the New Millennium > > > http://technetcast.ddj.com/tnc_catalog.html?item_id=421 > > > > 'take a ride on the Reading railroad....' > > Hmm nice work, but I don't find the architecture > > of MMIX that usable of a design. > > indeed. > but more importantly, the goals differ. > F-CPU is designed to be an alternative > that must be industrially viable. > MMIX is "only" a "toy CPU" designed only for the > sake of illustrating examples in the AOCP series. > I respect Knuth and his goals, but anybody > can look back at the F-CPU archive and read > why the F-CPU group didn't chose to design either > a MMIX, a DLX, a MIPS, etc... > > On top of that, the MMIX is not scaleable as F-CPU can be. > sure, there are some SIMD instructions, but there is > no way to provide future CLEAN extensions. > And there are some F-CPU characteristics that > i have tasted and don't want to give away :-) > All the existing designs look sadly oldfashioned > to me since FC0 appeared :-) > > OK, i'll be in Dortmund next week. > it's gonna be exciting. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From "Marco Al" Sat Apr 21 18:08:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00347 for ; Sun, 22 Apr 2001 01:55:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:34 +0200 (MEST) Received: (qmail 14864 invoked by uid 0); 21 Apr 2001 15:57:07 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx06) with SMTP; 21 Apr 2001 15:57:07 -0000 X-eGroups-Return: sentto-1101623-2704-987868621-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 21 Apr 2001 15:57:03 -0000 X-Sender: marco@simplex.nl X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 15:57:00 -0000 Received: (qmail 31480 invoked from network); 21 Apr 2001 15:57:00 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 21 Apr 2001 15:57:00 -0000 Received: from unknown (HELO schuimpje.snt.utwente.nl) (130.89.238.4) by mta2 with SMTP; 21 Apr 2001 15:56:59 -0000 Received: from cal046201 (cal046201.student.utwente.nl [130.89.230.41]) by schuimpje.snt.utwente.nl (Postfix) with SMTP id C9C1F295B for ; Sat, 21 Apr 2001 17:56:58 +0200 (CEST) Message-ID: <000b01c0ca7d$457df7e0$29e65982@student.utwente.nl> To: References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> <3AE0E301.3DDDBE2B@f-cpu.org> <3AE180FE.8F6FE0C7@altercom.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 From: "Marco Al" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 18:08:15 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Status: R X-Status: N From: "AlterCom - Mobile" > I mentioned Donald E. Knuth mostly due to his genius in chip > designs. I doubt he would agree. > I feel if was told about the Freedom CPU project he would > be excited to join in helping. >From reading interviews and his webpage he seems to be extremely reclusive so he can devote all his time to his writing. > However, his designs are what > he has been interested in and not what the Freedom CPU team > is. I think getting with him and his colleagues or if nothing else > reviewing his chip designs would be very beneficial. The odd's against F-CPU ever getting anywhere are so huge I doubt you would find him and his colleagues willing to dedicate any time towards it. In mr. Knuth's case especially, as he say's: "My full-time writing schedule means that I have to be pretty much a hermit. The only way to gain enough efficiency to complete The Art of Computer Programming is to operate in batch mode, concentrating intensively and uninterruptedly on one subject at a time, rather than swapping a number of topics in and out of my head. I'm unable to schedule appointments with visitors, travel to conferences or accept speaking engagements, or undertake any new responsibilities of any kind." Marco ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Yann Guidon Sat Apr 21 17:45:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00350 for ; Sun, 22 Apr 2001 01:55:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:35 +0200 (MEST) Received: (qmail 20660 invoked by uid 0); 21 Apr 2001 16:01:21 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx06) with SMTP; 21 Apr 2001 16:01:21 -0000 X-eGroups-Return: sentto-1101623-2703-987868061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fj.egroups.com with NNFMP; 21 Apr 2001 15:47:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 15:47:41 -0000 Received: (qmail 2305 invoked from network); 21 Apr 2001 15:47:40 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 21 Apr 2001 15:47:40 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 21 Apr 2001 15:47:39 -0000 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA25055 for ; Sat, 21 Apr 2001 17:47:30 +0200 (MET DST) Message-ID: <3AE1AB20.E882B22F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> <3AE0E301.3DDDBE2B@f-cpu.org> <3AE180FE.8F6FE0C7@altercom.com> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 17:45:36 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N AlterCom - Mobile wrote:
> Hi!

hi too !
it's cool, it seems we have a new face in f-cpu land :-)
welcome in the family !

> I mentioned Donald E. Knuth mostly due to his genius in chip
> designs.
?
i don't think he's dumb, but except MIX and MMIX (which are
not everyday-use CPUs), what other "genius" chip has he designed ?

> Reinventing the wheel is may not be a good  idea if
> one wants quick time to market.
what do you prefer ? quick "time to market" or "qualtiy" ?
I don't think that we reinvented much wheels in the F-CPU.
it is not a rip-off of DLX (like OpenCores, but that is a
personal opinion) and F-CPU brings some important new concepts.

On top of that, as you can remark, F-CPU is more a "hacker's CPU"
rather than an industrial one (even if it is meant to be come one).
Time to market in the current design phase is not #1 priority :
do you prefer to quickly make a CPU that you'll have to change
in a few years, or do you think it's better to work seriously
and invest for the next decades ?

>  Just because his designs are
> public domain don't mean they can't be used in GPL.

>  Heck, he claims the Intel MMX technology is based o n his MMIX.
nope. he simply made the remark that the data format was similar.
There are MMX things that you won't find in the MMIX, such as some
shuffling instructions.
In the CPU world, we all end up one day or another to the same
conclusions. There's not much left to invent...

However, MMX is not the only SIMD instruction set out there,
some other big companies came before intel in that kind of game.
And if you stretch the SIMD concept a bit, you'll end up considering
SIMD as a modified "vector" computer model. Vector computers are
not new...

> I feel if was told about the Freedom CPU project he would
> be excited to join in helping.
probably.

> This does not mean all his designs
> if any at all need to be used. However, his designs are what
> he has been interested in and not what the Freedom CPU team
> is. I think getting with him and his colleagues or if nothing else
> reviewing his chip designs would be very beneficial.

sure : more eyeballs is not useless.

However the CVS is not yet well organised ...
it will take some time to sort that out,

> He has a new chip design now and if you read his site its all
> about volunteer team worker
yup. but all the work is about translating to MMIX and finding typing errors.
not about building new architectures and enhancing the ISA and programming
model (as in F-CPU).

> Another project for which I'll soon be seeking volunteers is
> the job of converting MIX programs to a new RISC computer;
> see the MMIX page.  <http://www-cs-faculty.stanford.edu/~knuth/help.html>.

it is certainly highly instructive to participate. However, F-CPU is already
so take-consuming that i can't volunteer :-/

> Yeah,..the Alpha is a better chip but he designed the MMIX processor
> 30 years ago. :-)
> <http://www-cs-faculty.stanford.edu/~knuth/mmix.html>

then

> Hi!
> Correction,. The MIX processor is 30 years old.

yeah, everyone knows that ;-)

> <http://www-cs-faculty.stanford.edu/~knuth/mmix.html>
> "The designers of important real-world processor
> chips (e.g., MIPS and ALPHA) have helped me
> with the design of MMIX. So I'm excited about
> the prospects."

i'm simply curious.
As noted, his 30 years of work did not learn him how important
it is to have a _scalable_ design.
Imagine if the F-CPU was similar to MMIX : after 5 or 10 years
of use, we would have to modify its programming model so it would
enhance its capabilities. F-CPU is already 2 years old and is designed
to live several decades without modifying its ISA. i don't want another x86.

DK decided to fill the opcode map, as well as not support larger
data sizes. However it's nice to see a 256-register CPU, even if
it is meant to support windowed (?) sets. If it was only my choice,
F-CPU would have 128 regs :-)

There are a lot of different CPU architectures out there, each with something
interesting or new. it is not a static world and nobody can know everything.
that's why it's so interesting :-)

> Jim :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sat Apr 21 07:15:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00353 for ; Sun, 22 Apr 2001 01:55:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:37 +0200 (MEST) Received: (qmail 12789 invoked by uid 0); 21 Apr 2001 16:39:15 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx02) with SMTP; 21 Apr 2001 16:39:15 -0000 X-eGroups-Return: sentto-1101623-2705-987871153-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 21 Apr 2001 16:39:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 16:39:13 -0000 Received: (qmail 9853 invoked from network); 21 Apr 2001 16:39:12 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 21 Apr 2001 16:39:12 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 21 Apr 2001 16:39:11 -0000 Received: from jetnet.ab.ca (dialin55.jetnet.ab.ca [207.153.6.55]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA25478 for ; Sat, 21 Apr 2001 10:39:08 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AE11772.5EEC1664@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3ADF4BF2.22AB7B98@altercom.com> <3ADEE1CF.84FA5086@jetnet.ab.ca> <3AE0E301.3DDDBE2B@f-cpu.org> <3AE180FE.8F6FE0C7@altercom.com> <000b01c0ca7d$457df7e0$29e65982@student.utwente.nl> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 20 Apr 2001 23:15:30 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Marco Al wrote:
> The odd's against F-CPU ever getting anywhere are so huge I doubt you would find
> him and his colleagues willing to dedicate any time towards it. In mr. Knuth's
> case especially, as he say's:
>
> "My full-time writing schedule means that I have to be pretty much a hermit. The
> only way to gain enough efficiency to complete The Art of Computer Programming
> is to operate in batch mode, concentrating intensively and uninterruptedly on
> one subject at a time, rather than swapping a number of topics in and out of my
> head. I'm unable to schedule appointments with visitors, travel to conferences
> or accept speaking engagements, or undertake any new responsibilities of any
> kind."

As a educational product I expect the NEW MIX will have a big impact as
they are used for teaching in the "The Art of Computer Programming",but
not a Commercial CPU design. (In fact I wish I had the books here, as I need
to write my math and floating point routines for my octal computers).
Knuth has made a very large impact with his open source text formatting software
and that is where I expect he will continue updating the programs.
 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat Apr 21 20:31:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00371 for ; Sun, 22 Apr 2001 01:55:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:42 +0200 (MEST) Received: (qmail 14937 invoked by uid 0); 21 Apr 2001 18:33:46 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx07) with SMTP; 21 Apr 2001 18:33:46 -0000 X-eGroups-Return: sentto-1101623-2706-987878024-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 21 Apr 2001 18:33:45 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 18:33:44 -0000 Received: (qmail 95307 invoked from network); 21 Apr 2001 18:33:43 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 21 Apr 2001 18:33:43 -0000 Received: from unknown (HELO front7.grolier.fr) (194.158.96.57) by mta1 with SMTP; 21 Apr 2001 18:33:42 -0000 Received: from f-cpu.org (nas3-79.tls.club-internet.fr [195.36.202.79]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA09946 for ; Sat, 21 Apr 2001 20:33:34 +0200 (MET DST) Message-ID: <3AE1D206.819CDD6D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 20:31:34 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

Andreas Romeyke wrote:
> Hello,
>
> This mail is a notify message only.
>
> I want to tell something about F-CPU-Project on a lecture in may 2001 = in
> Leipzig. Also at http:/= /gaos.org/cgi-bin/cvsweb.cgi is a cvs-repository
> with upcoming lecture (today only some ideas in a Readme-file, nothing=
> foils yet). The lecture is in German.
>
> Bye Andreas

In the f-cpu_folien directory, i found that :

----------------------------------------------------------
Folien zum Vortrag F-CPU im Rahmen der Vortragsreihe des GAOS e.V.,
benutzbar unter Anerkennung der Lizenz des F-CPU-Teams unter
http://f-cpu.de.

*--> add the www in front of the URL,
it seems that the web server is not fully configured.

Autoren:
      Andreas Romeyke
      Michael Riepe

Die Folien ben=F6tigen die TeX-Pakete foils, ngerman, etc. sh. Files

#################################################################
Gliederung: (50)
1      Freie CPU, wozu? (5)
2      Technische Daten, sinnvolle Techniken (20)<= BR> 3      technische Umsetzung (10)
4      Beiwerk (IO, Compiler, BS) (10)
5      Zukunft (5)
#################################################################
Ziel:
      Publikum soll begreifen, da=DF auch freie Ha= rdware notwendig ist
      Publikum soll erahnen, da=DF freie Hardware = gut sein kann
      Publikum soll mitbekommen, da=DF das Projekt= machbar ist
      Publikum soll erfahren, da=DF es mithelfen k= ann
      Publikum soll sich freuen
*--> sieht gut aus ;-)

#################################################################
zu 1
      -> C64, gut dokumentiert, gute Programme,= hoch ausgereizt
*--> what is C64 ?

      -> freie Software bedingt Treiber etc. -&= gt; freie Hardware
      -> schnellere Anpassung an Bed=FCrfnisse<= BR>       -> durchbrechen von Monopolen und Denkbar= rieren
      -> Schaffung von Alternative  &= nbsp;  
*--> that's a good introduction

zu 2
      -> RISC
      -> SIMD
      -> Instruktionset
      -> ALU
      -> Crossbar
      -> Steuerwerk
      -> Leitwerk
      -> Idee der Logarithmiereinheit

      -> erwartete Leistung
      -> erwartete Kosten
*--> wer weisst ? :-)
except "you get what you pay for",
we can't say or garantee anything.
This is not an industrial project,
there is no schedule, no budget
(there's no money).


zu 3
      -> Logik
      -> VHDL
      -> analogon zur Softwareentwicklung
      -> FPGA
      -> Skalierung (n*64Bit)

it's more "64 * 2^n bits", otherwise it is
too complex to manage ;-)

zu 4
      -> ben=F6tigt CPU-Emulator (Software oder= als Hardware)
      -> ben=F6tigt Sockel, Schnittstellen, Mot= herboard
      -> ben=F6tigt Compiler
      -> ben=F6tigt Betriebssystem

*--> ben=F6tigt viel Zeit, Erfahrung and Lust auch :-)

zu 5
      -> aktueller Stand
      -> Zukunftsaussichten
      -> Unterst=FCtzung
*--> F-CPU rules :-)
and never forget : "design and let design"

----------------------------------------------------------

have fun,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jeff Davies Sun Apr 22 01:41:33 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA00416 for ; Sun, 22 Apr 2001 01:55:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 01:55:56 +0200 (MEST) Received: (qmail 12411 invoked by uid 0); 21 Apr 2001 22:41:16 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx22) with SMTP; 21 Apr 2001 22:41:16 -0000 X-eGroups-Return: sentto-1101623-2707-987892874-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mq.egroups.com with NNFMP; 21 Apr 2001 22:41:14 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 21 Apr 2001 22:41:13 -0000 Received: (qmail 16706 invoked from network); 21 Apr 2001 22:41:11 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 21 Apr 2001 22:41:11 -0000 Received: from unknown (HELO mail3.svr.pol.co.uk) (195.92.193.19) by mta1 with SMTP; 21 Apr 2001 22:41:11 -0000 Received: from modem-36.berkelium.dialup.pol.co.uk ([62.136.68.36] helo=localhost.localdomain) by mail3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14r63w-0005yX-00 for f-cpu@yahoogroups.com; Sat, 21 Apr 2001 23:41:09 +0100 Organization: Hipparchus Systems Ltd To: f-cpu@yahoogroups.com X-Mailer: KMail [version 1.2] References: <3AE180FE.8F6FE0C7@altercom.com> <000b01c0ca7d$457df7e0$29e65982@student.utwente.nl> In-Reply-To: <000b01c0ca7d$457df7e0$29e65982@student.utwente.nl> Message-Id: <01042200413300.01205@localhost.localdomain> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Apr 2001 00:41:33 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Status: R X-Status: N On Saturday 21 April 2001 5:08 pm, you wrote: > > The odd's against F-CPU ever getting anywhere are so huge I doubt you would > find him and his colleagues willing to dedicate any time towards it. In mr. > Knuth's case especially, as he say's: > Actually this is a silly statement, the GPL and in general communication of ideas (and the internet helps here), is a bit like a charge pump with no leakage. [a charge pump is a set of diodes that allow current flow in one direction (the charge is stored on capacitors) for very high voltage dc power supplies]. What I'm saying here is .. peope fire in ideas to FCPU, and occaisionally get off their butts and do something (not me so far, so I'm not accusing anyone beyond the closest target which is me). Whenever someone does even the slightest thing, because of GPL, and freedom of info, this accumulates. Consider GNU-HURD. Much longer gestation period than Linux kernel, and more esoteric, coupled with lower single-CPU performance, and yet, a proto distribution is available from Debian now after all this time. The laws of economics and market forces would see VHS win, but in the world of free software, Betamax would not die, but grow independantly. You can actually see this happen by looking around at people (on the web) who are still writing CP/M software, etc etc. (Atari,...). Collectively the handful of people interested in this activity can network over the web, and achieve things they might never do on their own. Therefore I predict FCPU will make a working chip design, it might take a small amount of time, or a large amount of time, it might end up being significantly different from it's current design. There is no need to be negative in this way. (especially when it has a good logo and a good name) Jeff Davies > > Marco > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Do you have 128-bit SSL encryption server security? Get VeriSign's FREE Guide, "Securing Your Web Site for Business." Get it now! http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/CYAVlB/TM ---------------------------------------------------------------------_-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Andreas Romeyke Sun Apr 22 10:52:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA02172 for ; Sun, 22 Apr 2001 14:57:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 14:57:53 +0200 (MEST) Received: (qmail 5036 invoked by uid 0); 22 Apr 2001 07:12:12 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx08) with SMTP; 22 Apr 2001 07:12:12 -0000 X-eGroups-Return: sentto-1101623-2708-987923530-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 22 Apr 2001 07:12:10 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 22 Apr 2001 07:12:09 -0000 Received: (qmail 52335 invoked from network); 22 Apr 2001 07:12:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 22 Apr 2001 07:12:09 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 22 Apr 2001 07:12:08 -0000 Received: from art1.none.de (dialin61.pg2-nt.berlin.nikoma.de [213.54.65.61]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f3M7C9615972 for ; Sun, 22 Apr 2001 09:12:10 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin61.pg2-nt.berlin.nikoma.de [213.54.65.61] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14rFbn-0007Lt-00 for ; Sun, 22 Apr 2001 10:52:43 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <3AE1D206.819CDD6D@f-cpu.org> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Apr 2001 10:52:43 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello YG,

> http://f-cpu.de.
>
> *--> add the www in front of the URL,

Ok.

>       -> C64, gut dokumentiert, gute Programme, hoch ausgereizt
> *--> what is C64 ?

The Commodore C64 was/is an 8bit-Homecomputer. After a few years there
were every bits and registers well known, and programmers used the full
possible power of this computer.

>       -> erwartete Kosten
> *--> wer weisst ? :-)
> except "you get what you pay for",
> we can't say or garantee anything.
> This is not an industrial project,
> there is no schedule, no budget
> (there's no money).

Ok. I add this.

>       -> Skalierung (n*64Bit)
>
> it's more "64 * 2^n bits", otherwise it is
> too complex to manage ;-)

You have right. :)

I want to take some ideas from previous lectures. Next week I want
to generate first foils.

Bye Andreas
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sun Apr 22 14:36:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA02220 for ; Sun, 22 Apr 2001 14:58:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 22 Apr 2001 14:58:05 +0200 (MEST) Received: (qmail 11210 invoked by uid 0); 22 Apr 2001 12:41:11 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx01) with SMTP; 22 Apr 2001 12:41:11 -0000 X-eGroups-Return: sentto-1101623-2709-987943137-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 22 Apr 2001 12:41:08 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 22 Apr 2001 12:38:55 -0000 Received: (qmail 72007 invoked from network); 22 Apr 2001 12:38:54 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 22 Apr 2001 12:38:54 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 22 Apr 2001 12:38:54 -0000 Received: from f-cpu.org (nas4-181.pau.club-internet.fr [195.36.133.181]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA22418 for ; Sun, 22 Apr 2001 14:38:45 +0200 (MET DST) Message-ID: <3AE2D065.B66BD60A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Apr 2001 14:36:53 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Andreas Romeyke wrote:
> Hello YG,
> >       -> C64, gut dokumentiert, gute Programme, hoch ausgereizt
> > *--> what is C64 ?
>
> The Commodore C64 was/is an 8bit-Homecomputer. After a few years there
> were every bits and registers well known, and programmers used the full
> possible power of this computer.

in France, i used a MO5 (6809-based cheap computer) but never had
the opportunity do go further. i directly entered in the PC world
and i do all i can to escape from it. My commitment to Free Software
and the F-CPU project are the only ways i know to gain freedom
to compute.

I have programmed PCs for years and i know quite a bit about it.
and i don't want to program a crap like that anymore. I have seen
the industry's behaviour, its fashion to play with and tweak the
standards down. I have also seen how other CPUs and DSP were
crippled by their own designers, and as a user and designer i
don't want to go that way. i don't care about "job security"
and i don't want the wheel to be repatented millions of times.
let's move forward, even if we're only a bunch of dreamers.

> I want to take some ideas from previous lectures. Next week I want
> to generate first foils.
i think that you have checked the f-cpu sites ?
i have put some past stuff online. feel free to spread the copyright :-)

look at http://www.F-CPU.de/epf2001/cfp.html
for some stuff. some stuff from the CCC should be online somewhere
but i don't remember where.

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sat Apr 21 13:54:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA04234 for ; Mon, 23 Apr 2001 03:08:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 23 Apr 2001 03:08:27 +0200 (MEST) Received: (qmail 12135 invoked by uid 0); 22 Apr 2001 13:15:31 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx15) with SMTP; 22 Apr 2001 13:15:31 -0000 X-eGroups-Return: sentto-1101623-2710-987945326-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 22 Apr 2001 13:15:27 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 22 Apr 2001 13:15:25 -0000 Received: (qmail 49501 invoked from network); 22 Apr 2001 13:15:25 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 22 Apr 2001 13:15:25 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 22 Apr 2001 13:15:24 -0000 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA01777 for ; Sun, 22 Apr 2001 07:15:23 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AE17513.A5E57876@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 21 Apr 2001 05:54:59 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] F-CPU lecture by GAOS e.V. in Leipzig/Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andreas Romeyke wrote:
>
> Hello YG,
> The Commodore C64 was/is an 8bit-Homecomputer. After a few years there
> were every bits and registers well known, and programmers used the full
> possible power of this computer.

Yes and they still are writing code too. The 6502 looks to be a
popular FPGA architecture and somebody wrote a small multitasking
OS called lunix of all things. ( Darn I hoping to use that name for my OS).
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed Apr 25 17:09:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13349 for ; Wed, 25 Apr 2001 21:52:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:24 +0200 (MEST) Received: (qmail 27893 invoked by uid 0); 25 Apr 2001 15:21:52 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx28) with SMTP; 25 Apr 2001 15:21:52 -0000 X-eGroups-Return: sentto-1101623-2711-988211899-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 25 Apr 2001 15:18:20 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 15:18:18 -0000 Received: (qmail 77005 invoked from network); 25 Apr 2001 15:17:07 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 25 Apr 2001 15:17:07 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 25 Apr 2001 15:17:06 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA20427; Wed, 25 Apr 2001 08:17:03 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9TCP; Wed, 25 Apr 2001 16:23:12 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AE6E8AA.E19BEC5D@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: "f-cpu@egroups.com" X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 17:09:30 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N i know that i should be writing the conference text for this saturday
in Dortmund. but you know the odds of developping stuff...

i have started to write a new document from scratch,
a preliminary F-BUS specification sheet. it's a bottom-up
layered description of the signaling, pinout and protocols.
it will be online as soon as i can finish it.

BTW, I am going to update the f-cpu.de page soon,
please mail me your suggestions !

and finally, for the ISA update, i am trying to investigate
the viability of including a CRC opcode (CRC is often used,
ie for network and file transfers/storage, on large streams,
so it's probably worth including an optional instruction to
speed that up).
I had a reference for generating a CRC lookup table but i lost
it. It would be cool if it was synthesizable, instead of using
a dumb ROM array...

Some of the expected new opcodes are : scatter, gather,
sssh (SIMD SIMD SHift and rotation, optional), and a modified
LOOP instruction (more similar to the jmp instruction, ie
with the 4 condition codes), some others are recorded on a
todo list at home...

have fun,

YG (still alive and crazy)
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Matringe Wed Apr 25 17:44:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13352 for ; Wed, 25 Apr 2001 21:52:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:25 +0200 (MEST) Received: (qmail 19173 invoked by uid 0); 25 Apr 2001 15:42:57 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx12) with SMTP; 25 Apr 2001 15:42:57 -0000 X-eGroups-Return: sentto-1101623-2713-988213351-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 25 Apr 2001 15:42:32 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 15:42:30 -0000 Received: (qmail 83761 invoked from network); 25 Apr 2001 15:41:39 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 25 Apr 2001 15:41:39 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta3 with SMTP; 25 Apr 2001 15:41:38 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id PAA10924 for ; Wed, 25 Apr 2001 15:41:37 GMT X-To: Message-ID: <3AE6F0C3.3EAAA378@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <3AE6E8AA.E19BEC5D@mentor.com> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 17:44:03 +0200 Reply-To: f-cpu@yahoogroups.com Subject: CRC (was Re: [f-cpu] i know, i know..) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:

> I had a reference for generating a CRC lookup table but i lost
> it. It would be cool if it was synthesizable, instead of using
> a dumb ROM array...

It's your lucky day: I'm nose-deep in CRC calculation :o)

CRC16 (X25 : 1 + x^5 + x^12 + x^16) for 8 bits data bus :

    NewCRC(0) := D(4) xor D(0) xor C(8) xor C(12);
    NewCRC(1) := D(5) xor D(1) xor C(9) xor C(13);
    NewCRC(2) := D(6) xor D(2) xor C(10) xor C(14);
    NewCRC(3) := D(7) xor D(3) xor C(11) xor C(15);
    NewCRC(4) := D(4) xor C(12);
    NewCRC(5) := D(5) xor D(4) xor D(0) xor C(8)
                  xor C(12) xor C(13);
    NewCRC(6) := D(6) xor D(5) xor D(1) xor C(9)
                  xor C(13) xor C(14);
    NewCRC(7) := D(7) xor D(6) xor D(2) xor C(10)
                  xor C(14) xor C(15);
    NewCRC(8) := D(7) xor D(3) xor C(0) xor C(11) xor C(15);
    NewCRC(9) := D(4) xor C(1) xor C(12);
    NewCRC(10) := D(5) xor C(2) xor C(13);
    NewCRC(11) := D(6) xor C(3) xor C(14);
    NewCRC(12) := D(7) xor D(4) xor D(0) xor C(4)
                   xor C(8) xor C(12) xor C(15);
    NewCRC(13) := D(5) xor D(1) xor C(5) xor C(9) xor C(13);
    NewCRC(14) := D(6) xor D(2) xor C(6) xor C(10) xor C(14);
    NewCRC(15) := D(7) xor D(3) xor C(7) xor C(11) xor C(15);

Any other: see http://www.easics.com/webtools/crctool

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Sun Apr 22 21:51:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13355 for ; Wed, 25 Apr 2001 21:52:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:26 +0200 (MEST) Received: (qmail 7083 invoked by uid 0); 25 Apr 2001 15:45:11 -0000 Received: from hj.egroups.com (208.50.99.212) by mx0.gmx.net (mx24) with SMTP; 25 Apr 2001 15:45:11 -0000 X-eGroups-Return: sentto-1101623-2712-988213043-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 25 Apr 2001 15:39:35 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 15:37:21 -0000 Received: (qmail 39144 invoked from network); 25 Apr 2001 15:36:39 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 25 Apr 2001 15:36:39 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 25 Apr 2001 15:36:39 -0000 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA15631 for ; Wed, 25 Apr 2001 09:36:36 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AE3362A.181F0141@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AE6E8AA.E19BEC5D@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 22 Apr 2001 13:51:06 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:
> I had a reference for generating a CRC lookup table but i lost
> it. It would be cool if it was synthesizable, instead of using
> a dumb ROM array...
I remember BYTE magazine doing a CRC lookup algorithm ,years ago.
The main loop was I believe something like
checksum ^= table [ *byte_ptr ++ ];
I don't see the need for it because anybody needing really fast
CRC stuff would be using a custom chip for the data processing.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed Apr 25 18:22:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13361 for ; Wed, 25 Apr 2001 21:52:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:28 +0200 (MEST) Received: (qmail 25992 invoked by uid 0); 25 Apr 2001 16:19:44 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx22) with SMTP; 25 Apr 2001 16:19:44 -0000 X-eGroups-Return: sentto-1101623-2714-988215580-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 25 Apr 2001 16:19:42 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 16:19:40 -0000 Received: (qmail 74597 invoked from network); 25 Apr 2001 16:18:52 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 25 Apr 2001 16:18:52 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 25 Apr 2001 16:18:52 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 25 Apr 2001 16:22:05 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200104251622.0534@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 16:22:05 GMT Reply-To: f-cpu@yahoogroups.com Subject: Rep:[f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Sorry but we don't need a bus to get of the fcpu to
go to the real world. It's too early. We need an
internel bus as the wishbones bus of the opencores
site. It's used to connect the cpu core, the mmu, and
all the rapid peripherals (external bus).

In VHDL, a ROM array is always converted to gate...

The documentation we need is to explain our choice
(whygee choice ?). Something as : what is currently
used and what we are going to do and why. It could be
usefull to update the manual.

nicO

-----Message d'origine-----
De: Yann GUIDON <whygee@f-cpu.org>
A: "f-cpu@egroups.com" <f-cpu@yahoogroups.com>
Date: 25/04/01
Objet: [f-cpu] i know, i know..

i know that i should be writing the conference text
for this saturday
in Dortmund. but you know the odds of developping
stuff...

i have started to write a new document from scratch,
a preliminary F-BUS specification sheet. it's a
bottom-up
layered description of the signaling, pinout and
protocols.
it will be online as soon as i can finish it.

BTW, I am going to update the f-cpu.de page soon,
please mail me your suggestions !

and finally, for the ISA update, i am trying to
investigate
the viability of including a CRC opcode (CRC is often
used,
ie for network and file transfers/storage, on large
streams,
so it's probably worth including an optional
instruction to
speed that up).
I had a reference for generating a CRC lookup table
but i lost
it. It would be cool if it was synthesizable, instead
of using
a dumb ROM array...

Some of the expected new opcodes are : scatter,
gather,
sssh (SIMD SIMD SHift and rotation, optional), and a
modified
LOOP instruction (more similar to the jmp
instruction, ie
with the 4 condition codes), some others are recorded
on a
todo list at home...

have fun,

YG (still alive and crazy)



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Wed Apr 25 19:33:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13370 for ; Wed, 25 Apr 2001 21:52:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:31 +0200 (MEST) Received: (qmail 16385 invoked by uid 0); 25 Apr 2001 17:40:35 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx12) with SMTP; 25 Apr 2001 17:40:35 -0000 X-eGroups-Return: sentto-1101623-2715-988219990-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 25 Apr 2001 17:33:12 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 17:33:09 -0000 Received: (qmail 47714 invoked from network); 25 Apr 2001 17:33:09 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 25 Apr 2001 17:33:09 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 25 Apr 2001 17:33:08 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id UAA12752 for ; Wed, 25 Apr 2001 20:33:06 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: "f-cpu@egroups.com" In-Reply-To: <3AE6E8AA.E19BEC5D@mentor.com> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 20:33:05 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 25 Apr 2001, Yann GUIDON wrote:

> and finally, for the ISA update, i am trying to investigate
> the viability of including a CRC opcode (CRC is often used,
> ie for network and file transfers/storage, on large streams,
> so it's probably worth including an optional instruction to
> speed that up).

I don't think that CRC opcode is very beneficial. Usually the CRC
calculation can be done without extra cost in data copy etc. And if zero
copy schemes are used the dedicated hardware has programmable CRC
checkers. There are too many different CRC schemes to support.

I could see some use of CRC in network processors, but not in multipurpose
CPU. The layout of the chip will be very difficult if the ALU becomes too
complex. I think you should be very careful with the amount of
opcodes.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Wed Apr 25 22:45:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA13391 for ; Wed, 25 Apr 2001 21:52:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 25 Apr 2001 21:52:37 +0200 (MEST) Received: (qmail 13389 invoked by uid 0); 25 Apr 2001 18:44:23 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx05) with SMTP; 25 Apr 2001 18:44:23 -0000 X-eGroups-Return: sentto-1101623-2716-988224239-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 25 Apr 2001 18:44:00 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 18:43:58 -0000 Received: (qmail 93114 invoked from network); 25 Apr 2001 18:43:58 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 25 Apr 2001 18:43:58 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta1 with SMTP; 25 Apr 2001 18:43:57 -0000 Received: from art1.none.de (dialin105.pg1-nt.berlin.nikoma.de [213.54.64.105]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f3PIhx621610 for ; Wed, 25 Apr 2001 20:44:00 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin105.pg1-nt.berlin.nikoma.de [213.54.64.105] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14sWA4-0001kE-00 for ; Wed, 25 Apr 2001 22:45:20 +0200 To: "f-cpu@egroups.com" In-Reply-To: <3AE6E8AA.E19BEC5D@mentor.com> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 22:45:20 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> and finally, for the ISA update, i am trying to investigate
> the viability of including a CRC opcode (CRC is often used,
> ie for network and file transfers/storage, on large streams,

I don't think so. There are many CRC analogous algorithm. The better way
is to analyze CRC, md5, sha1 and so on to have equal code to speed up
these.

> Some of the expected new opcodes are : scatter, gather,
> sssh (SIMD SIMD SHift and rotation, optional), and a modified
> LOOP instruction (more similar to the jmp instruction, ie
> with the 4 condition codes), some others are recorded on a
> todo list at home...

I haven't seen yet, have we atomic operations to build semaphores etc.,
that's will be very important for a good operating systems support?

Also an idea-particle has hit me: If we switch between tasks (processes),
we lost caching-performance. Why we couldn't have two cache or TLB units,
one for supermode, one for usermode. If an OS has to do Kerneltasks, the
usermode cache/tlb/pipeline could be synchonized or updated. By switching
>from kerneltasks to usertasks, we would not lost the locality in
kernelcode.

Bye Andreas
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Wed Apr 25 19:59:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA15272 for ; Thu, 26 Apr 2001 11:22:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 11:22:41 +0200 (MEST) Received: (qmail 1770 invoked by uid 0); 25 Apr 2001 23:52:41 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx07) with SMTP; 25 Apr 2001 23:52:41 -0000 X-eGroups-Return: sentto-1101623-2717-988242759-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 25 Apr 2001 23:52:40 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 25 Apr 2001 23:52:38 -0000 Received: (qmail 7300 invoked from network); 25 Apr 2001 23:52:38 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 25 Apr 2001 23:52:38 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.185) by mta1 with SMTP; 25 Apr 2001 23:52:36 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA02407; Wed, 25 Apr 2001 19:59:49 +0200 Message-ID: <20010425195949.37151@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3AE6E8AA.E19BEC5D@mentor.com> X-Mailer: Mutt 0.84e In-Reply-To: <3AE6E8AA.E19BEC5D@mentor.com>; from Yann GUIDON on Wed, Apr 25, 2001 at 05:09:30PM +0200 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 19:59:49 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, Apr 25, 2001 at 05:09:30PM +0200, Yann GUIDON wrote:
[...]
> and finally, for the ISA update, i am trying to investigate
> the viability of including a CRC opcode (CRC is often used,
> ie for network and file transfers/storage, on large streams,
> so it's probably worth including an optional instruction to
> speed that up).
> I had a reference for generating a CRC lookup table but i lost
> it. It would be cool if it was synthesizable, instead of using
> a dumb ROM array...

Since CRC is basically a serial, bitwise-shift-and-xor algorithm, a
ROM array is not needed -- it just helps performance by processing 8
(or more) bits at once.  The basic algorithm for a single-bit CRC is:

      /* initialize crc */
      crc = START_VALUE;      /* usually all 1's (but not always) */
      /* process data */
      while ((b = getbit()) != EOF) {
            /* b is either 0 or 1 */
            if ((crc ^ b) & 1) {
                  crc = (crc >> 1) ^ POLY;
            }
            else {
                  crc = (crc >> 1);
            }
      }
      /* return result */
      return crc;

(both START_VALUE and POLY may vary).  The loop can be unrolled and
pipelined.  A very simple VHDL version (data-flow style) would be:

      tmp <= crc_in(0) xor bit_in;
      tmp_poly <= poly_in and (poly_in'range => tmp);
      crc_out <= shift_right(unsigned(crc_in), 1) xor tmp_poly;

This is more versatile than a table-based CRC (where POLY is fixed,
unless you have multiple tables), and it allows the creation of CRCs
with arbitrary sizes (crc16 and crc32 being the most common), by changing
the widths of crc_in, poly_in and crc_out.  It's slower than a ROM-based
version, but still much faster than a software CRC.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Apr 26 12:01:23 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00337 for ; Thu, 26 Apr 2001 14:42:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 14:42:12 +0200 (MEST) Received: (qmail 1316 invoked by uid 0); 26 Apr 2001 10:08:57 -0000 Received: from hi.egroups.com (208.50.99.211) by mx0.gmx.net (mx08) with SMTP; 26 Apr 2001 10:08:57 -0000 X-eGroups-Return: sentto-1101623-2719-988279736-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 26 Apr 2001 10:08:56 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 26 Apr 2001 10:08:55 -0000 Received: (qmail 99442 invoked from network); 26 Apr 2001 10:08:54 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 26 Apr 2001 10:08:54 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 26 Apr 2001 10:08:54 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA02572; Thu, 26 Apr 2001 03:08:52 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9TYP; Thu, 26 Apr 2001 11:15:05 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AE7F1F3.642219C5@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Apr 2001 12:01:23 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Andreas Romeyke wrote:
> Hello,
>
> > and finally, for the ISA update, i am trying to investigate
> > the viability of including a CRC opcode (CRC is often used,
> > ie for network and file transfers/storage, on large streams,
> I don't think so. There are many CRC analogous algorithm. The better way
> is to analyze CRC, md5, sha1 and so on to have equal code to speed up
> these.
OK i promise to reopen my crypto book.
Bruce Scneier's bible has some good insights in the algos.

However my intention is not only "security" but also "integrity".
It would be nice if the file system had a builtin CRC capability,
so each HDD sector would be checked, and a file would have
the CRC of all the CRC. very good to know if a file is damaged or
its contents is modified.

Try to apply a CRC to a whole HDD : it still takes a lot of time today.
However if it was implemented in the kernel, it would introduce a very
low overhead (some cycles here and there) and it would be always up to date.

CRC is also good for communication controllers, hubs, routers, protocols...

> > Some of the expected new opcodes are : scatter, gather,
> > sssh (SIMD SIMD SHift and rotation, optional), and a modified
> > LOOP instruction (more similar to the jmp instruction, ie
> > with the 4 condition codes), some others are recorded on a
> > todo list at home...
> I haven't seen yet, have we atomic operations to build semaphores etc.,
> that's will be very important for a good operating systems support?

<soapbox mode = on>
we have already spoken quite extensively about that in the past
(just look at the mailing list archive)

Semaphores are a different kind of memory I/O than the usual
load/store. the ordering etc. is uselessly complex that way.

semaphores are done through Special Registers because their access
is secure and in-order, and doesn't disturb the memory hierarchy
with atomic small accesses.

SRs also allow special, dedicated HW to be implemented and speed things up.
otherwise, you end up sending a lot of "memory barriers" in the instruction flow.
that;s a useless code bloat and slowdown.
<soapbox mode = off>

> Also an idea-particle has hit me: If we switch between tasks (processes),
> we lost caching-performance. Why we couldn't have two cache or TLB units,
> one for supermode, one for usermode. If an OS has to do Kerneltasks, the
> usermode cache/tlb/pipeline could be synchonized or updated. By switching
> from kerneltasks to usertasks, we would not lost the locality in
> kernelcode.

1) L1 cache can freeze about 1/4 of its contents
2) TLB entries are associated to a VMid, so if there's a short
interrupt, the TLB won't be completely thrashed.
wow, that's more than 1 year old :-)

ah, nostalgia.......

> Bye Andreas

YG

speaking for himself
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu Apr 26 12:25:48 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00349 for ; Thu, 26 Apr 2001 14:42:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 14:42:15 +0200 (MEST) Received: (qmail 25510 invoked by uid 0); 26 Apr 2001 10:26:01 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx05) with SMTP; 26 Apr 2001 10:26:01 -0000 X-eGroups-Return: sentto-1101623-2720-988280752-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 26 Apr 2001 10:25:53 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 26 Apr 2001 10:25:51 -0000 Received: (qmail 21771 invoked from network); 26 Apr 2001 10:25:50 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 26 Apr 2001 10:25:50 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 26 Apr 2001 10:25:50 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id NAA27121 for ; Thu, 26 Apr 2001 13:25:49 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3AE7F1F3.642219C5@mentor.com> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Apr 2001 13:25:48 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 26 Apr 2001, Yann GUIDON wrote:

> However my intention is not only "security" but also "integrity".
> It would be nice if the file system had a builtin CRC capability,
> so each HDD sector would be checked, and a file would have
> the CRC of all the CRC. very good to know if a file is damaged or
> its contents is modified.

The disks themselves have CRC protection at HW level. They report errors
to the upper levels if they detect integrity problems. This is not the job
of main CPU, but the HD controller and HD. Modern drives have automatic
data correction, spare sectors to correct data etc. And if needed RAID
contollers add one extra layer of protection to this.

> CRC is also good for communication controllers, hubs, routers, protocols...

Also in those products the CRC is done at HW level (ASIC/FPGA) and only
errors are reported to upper levels (you dont want to do any extra
operations with 1Gbit/s speeds). And for upper level protocols new NICs
have programmable HW to check CRC etc. And if you look for example IP
packet copy in Linux the checksum is calculated almost without extra cost
during the copy.

I just fear that fcpu will have every possible bell and whistle and it
never finishes because coding each feature and testing it requires work.
Also the core should be as small as possible in the first versions, it's
easy to extend it later on. So I think you should define MVP (minimum
viable product) and first generate that. "You have to first learn to walk
before running" fits here.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Thu Apr 26 14:24:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00370 for ; Thu, 26 Apr 2001 14:42:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 14:42:21 +0200 (MEST) Received: (qmail 2003 invoked by uid 0); 26 Apr 2001 12:35:42 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx17) with SMTP; 26 Apr 2001 12:35:42 -0000 X-eGroups-Return: sentto-1101623-2721-988288310-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ml.egroups.com with NNFMP; 26 Apr 2001 12:32:36 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 26 Apr 2001 12:31:49 -0000 Received: (qmail 77238 invoked from network); 26 Apr 2001 12:31:48 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 26 Apr 2001 12:31:48 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta2 with SMTP; 26 Apr 2001 12:31:48 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id FAA08548; Thu, 26 Apr 2001 05:31:45 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FWMR9T91; Thu, 26 Apr 2001 13:37:58 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AE8136F.24507708@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Apr 2001 14:24:15 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi all !

Kim Enkovaara wrote:
> On Thu, 26 Apr 2001, Yann GUIDON wrote:
> > However my intention is not only "security" but also "integrity".
> > It would be nice if the file system had a builtin CRC capability,
> > so each HDD sector would be checked, and a file would have
> > the CRC of all the CRC. very good to know if a file is damaged or
> > its contents is modified.
> The disks themselves have CRC protection at HW level. They report errors
> to the upper levels if they detect integrity problems. This is not the job
> of main CPU, but the HD controller and HD. Modern drives have automatic
> data correction, spare sectors to correct data etc. And if needed RAID
> contollers add one extra layer of protection to this.

right. However, the POSIX and ATA API, AFAIK, don't provide the user with the
CRC of a data block that is being transferred. the ECC are internal to the
disk controller.

well of course the CRC engine can be located in a block transfer circuitry,
for example on the front side bus interface.

> > CRC is also good for communication controllers, hubs, routers, protocols...
> Also in those products the CRC is done at HW level (ASIC/FPGA) and only
> errors are reported to upper levels (you dont want to do any extra
> operations with 1Gbit/s speeds). And for upper level protocols new NICs
> have programmable HW to check CRC etc. And if you look for example IP
> packet copy in Linux the checksum is calculated almost without extra cost
> during the copy.
what i see is that a CRC LUT uses 1K bytes of random access memory,
this thrashes 32 cache lines. a simple instruction implemented in the
_optional_ POPC unit would save 8 kilobits of RAM.

> I just fear that fcpu will have every possible bell and whistle and it
> never finishes because coding each feature and testing it requires work.
> Also the core should be as small as possible in the first versions, it's
> easy to extend it later on. So I think you should define MVP (minimum
> viable product) and first generate that. "You have to first learn to walk
> before running" fits here.

you are right.
however, now, i know that it's possible to add a CRC HW and instruction ;-)

YG

speaking for himself
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Thu Apr 26 03:50:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA00718 for ; Thu, 26 Apr 2001 16:20:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 16:20:46 +0200 (MEST) Received: (qmail 25637 invoked by uid 0); 26 Apr 2001 13:21:20 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx002-rz3) with SMTP; 26 Apr 2001 13:21:20 -0000 X-eGroups-Return: sentto-1101623-2722-988291278-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 26 Apr 2001 13:21:18 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 26 Apr 2001 13:21:17 -0000 Received: (qmail 1754 invoked from network); 26 Apr 2001 13:20:58 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 26 Apr 2001 13:20:58 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 26 Apr 2001 13:20:58 -0000 Received: from jetnet.ab.ca (dialin44.jetnet.ab.ca [207.153.6.44]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA27533 for ; Thu, 26 Apr 2001 07:20:55 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AE77EC9.A3420159@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200104251622.0534@lh00.opsion.fr> <3AE7DD01.F8DA3E26@mentor.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Apr 2001 19:50:01 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: Rep:[f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann GUIDON wrote:
> so you communicat with telepathy ? :-)
Yes the F-CPU is the CPU of the future.
I am sure Yann has grown pointy ears by now, with all
the time he has spent working on this project.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Thu Apr 26 20:54:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA01371 for ; Thu, 26 Apr 2001 21:19:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 26 Apr 2001 21:19:58 +0200 (MEST) Received: (qmail 11792 invoked by uid 0); 26 Apr 2001 18:51:03 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx14) with SMTP; 26 Apr 2001 18:51:03 -0000 X-eGroups-Return: sentto-1101623-2723-988311062-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 26 Apr 2001 18:51:03 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 26 Apr 2001 18:51:01 -0000 Received: (qmail 67298 invoked from network); 26 Apr 2001 18:50:58 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 26 Apr 2001 18:50:58 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 26 Apr 2001 18:50:58 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Thu, 26 Apr 2001 18:54:08 GMT Send-By: 194.117.207.166 with Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) To: Message-id: <200104261854.08f7@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Apr 2001 18:54:08 GMT Reply-To: f-cpu@yahoogroups.com Subject: Rep:Re: Rep:[f-cpu] i know, i know.. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -----Message d'origine-----
De: Yann GUIDON <whygee@f-cpu.org>
A: f-cpu@yahoogroups.com
Date: 26/04/01
Objet: Re: Rep:[f-cpu] i know, i know..

hi !

nicolas.boulay@ifrance.com wrote:
> Sorry but we don't need a bus to get of the fcpu to
> go to the real world.
so you communicat with telepathy ? :-)

-> Any standard bus could be used even stupid SRAM
buses.

> It's too early.
everything is too early... and we do nothing in the
end.

> We need an
> internel bus as the wishbones bus of the opencores
> site. It's used to connect the cpu core, the mmu,
and
> all the rapid peripherals (external bus).

grrr.... The TLB is integrated in the F-CPU core.

-> Grrre.. toi-meme. That's so strange to read that.
There is no really difference between board and chip
but you continue to imagine those difference. We need
something to connect the core+cache, the DMA, the
MMU+SDRAM controler and the io buses... That's so
simple.

no need for a special "fancy" bus for that.
i guess that you remember that there is a special,
dedicated Xbar port that goes to the TLB and then
it validates the internal buffers.

-> Your Xbar is only a black magic box that has no
reality, you need a packet of one-way buses to
replace it. That so simple to put eu to a big switch
! But the real world, it didn't work...

On top of that, a dedicated wide SDRAM (DDR/whatever
you find fancy)
external bus is necessary. Add any eDRAM you want,
but without
enough (i mean around 128MB) external private RAM,
your CPU will cough all the time. Unless you want to
use a F-CPU to
replace a LEON, but in that case it's just an
overkill...

-> This isn't related at all ! eDRAM could be used as
L2.

However, a "fishbone" bus can be used to interface
internal
peripherals, but in that case it is desirable to
access
them through Special Registers (when bandwidth is not
an issue)

This is because physical memory accesses are not
garantied
to be ordered. I know, there are some forms of the
L/S instructions
that do that, but the GET/PUT are safe when it comes
to the ordering.

> In VHDL, a ROM array is always converted to gate...
i'd like to see that :-)

This remembers me when i wanted to use a VHDL
compiler to
"crunch" a lookup table. The result was worse than a
LUT.
What do you prefer ? a clean LUT or using the
original
formula ? Well, it seems that  the formula
is really simple, it might be a nice and cheap
addition to
the POPCOUNT unit.

-> Any VHDL file to test it ? Never forget that often
you optimise for speed not area...

> The documentation we need is to explain our choice
> (whygee choice ?).
sure : dox lag.

> Something as : what is currently
> used and what we are going to do and why. It could
be
> usefull to update the manual.
i agree...
if at least i had enough time :-)

it seems however that the manual will be soon on CVS.
if Michael does not activate the seul.org server
soon,
i'll certainly be using the gaos site for a while.
It's a huge work, as large as making the first
version
>from scratch.

ok, read you soon.

> nicO

YG

speaking for himself

-> nicO

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
E*TRADE. It's your money.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From netbiz.info@usa.com Tue Jun 2 10:24:42 2037 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA02750 for ; Fri, 27 Apr 2001 08:41:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Fri, 27 Apr 2001 08:41:41 +0200 (MEST) Received: (qmail 31640 invoked by uid 0); 27 Apr 2001 04:14:23 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx006-rz3) with SMTP; 27 Apr 2001 04:14:23 -0000 X-eGroups-Return: sentto-1101623-2724-988344860-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 27 Apr 2001 04:14:22 -0000 X-Sender: netbiz.info@usa.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 27 Apr 2001 04:14:20 -0000 Received: (qmail 70225 invoked from network); 27 Apr 2001 04:14:20 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 27 Apr 2001 04:14:20 -0000 Received: from unknown (HELO mail.163bj.com) (202.106.196.67) by mta3 with SMTP; 27 Apr 2001 04:14:19 -0000 Received: from [202.106.196.67] ([209.52.196.23]) by mail.163bj.com (InterMail vK.4.02.00.00 201-232-116 license 0e49056eb76635631ccae874ca309299) with SMTP id <20010427041414.JHYL4733.mail.163bj.com@[209.52.196.23]> for ; Fri, 27 Apr 2001 12:14:14 +0800 Received: from nobody@localhost by (8.8.5/8.6.5) with SMTP id GAA00811 for ; Thu, 26 Apr 2001 20:56:26 -0600 (EST) To: f-cpu@yahoogroups.com Message-ID: <199912112040.MAA94626@addr6.addr.com> From: netbiz.info@usa.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 26 Apr 01 20:56:26 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Make Money While You SLEEP! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Tired of the 40 X 40 X 40 Plan? You know:..

Work 40 hours per week for someone else for 40 years, then receive a 40%
reduction in pay!

Is working for a "boss" too demeaning and unrewarding?

Are you sick of depending on a job with too little pay and too many
hours
with no personal reward and even less future?

If you're determined to retire in the next 2 - 5 years with enough
income
to have REAL Financial Independence and Freedom, and are not afraid to
work
for it, I can help you.

I am looking for people with a Good Work Ethic and extraordinary Desire
to
Earn at Least $10,000 per Month Working From Home!

NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the
training and personal support you will need to ensure your success!

This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in
Control
of your Time, Your Finances, and Your Life!

If you've tried other opportunities in the past that have failed to live
up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN!

THIS IS NOT A GET-RICH-QUICK SCHEME!

YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!

Reply:  ONLY IF YOU ARE SERIOUS!

Send email to: wealth_4u@bigfoot.com

Type the word "Interested" in the subject field.

DON'T GO TO SLEEP TONIGHT BEFORE SENDING FOR INFORMATION!

"All our dreams can come true - if we have the courage to pursue them" -
Walt Disney



I have purchased your e-mail in a bulk list as someone interested in
Internet Business Opportunities. If I received your e-mail in error, or
you are no longer interested, simply reply to this letter to  be automatically removed.
Be sure REMOVE is in the Subject Title and you will not be contacted again.
I do respect and honour remove requests!



****************************************************************
Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
****************************************************************
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@club-internet.fr Sun Apr 29 10:55:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00687 for ; Thu, 3 May 2001 12:30:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:30:38 +0200 (MEST) Received: (qmail 19729 invoked by uid 0); 29 Apr 2001 08:55:57 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx005-rz3) with SMTP; 29 Apr 2001 08:55:57 -0000 X-eGroups-Return: sentto-1101623-2725-988534555-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mo.egroups.com with NNFMP; 29 Apr 2001 08:55:56 -0000 X-Sender: whygee@club-internet.fr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 29 Apr 2001 08:55:53 -0000 Received: (qmail 29720 invoked from network); 29 Apr 2001 08:55:53 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 29 Apr 2001 08:55:53 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 29 Apr 2001 08:55:52 -0000 Received: (from mnet@localhost) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) id KAA12182 for f-cpu@egroups.com; Sun, 29 Apr 2001 10:55:44 +0200 (MET DST) To: f-cpu@yahoogroups.com X-Mailer: Medianet/v1.14 Message-Id: From: whygee@club-internet.fr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Apr 2001 10:55:44 +0200 (MET DST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] hi from Dortmund Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi !

Here i am, at the Fachhochschule with Lionel and Graham Seaman.
Things are really cool, here, it's a bit like at the 16C3.
The F-CPU workshop was yesterday and it went rather well, despite
the few people who attended, that's the main difference with the
CCC meetings :-)

Read you soon,
YG
Yahoo! Groups Sponsor
The Business Search Engine The Business Search Engine
FIND IN-DEPTH INDUSTRY INFORMATION
Find Business Information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Wed May 2 03:11:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01414 for ; Thu, 3 May 2001 12:34:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:34:40 +0200 (MEST) Received: (qmail 7683 invoked by uid 0); 2 May 2001 14:55:39 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx006-rz3) with SMTP; 2 May 2001 14:55:39 -0000 X-eGroups-Return: sentto-1101623-2726-988775731-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 02 May 2001 03:55:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 2 May 2001 03:55:30 -0000 Received: (qmail 9649 invoked from network); 2 May 2001 01:13:11 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 2 May 2001 01:13:11 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta2 with SMTP; 2 May 2001 01:13:10 -0000 Received: from f-cpu.org (nas2-18.aub.club-internet.fr [195.36.133.18]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA15582 for ; Wed, 2 May 2001 03:12:59 +0200 (MET DST) Message-ID: <3AEF5EBA.A9C01B52@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 May 2001 03:11:22 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] back from Dortmund Content-Type: multipart/mixed; boundary="------------167B1B597ABBB1B9CE0E144D" Status: R X-Status: N --------------167B1B597ABBB1B9CE0E144D Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello everybody,

Graham, Lionel and I were in Dortmund.
We made the conferences and discussed a lot.

We consider to setup a web server for online
digital design. Loaded with necessary sofware,
accessed through ssh and running batch queues
for the heavy tasks (ie : compiling large designs),
it will equiped with an external emulator for
simulation acceleration.

More than two years ago, we tried to see if we could
put a PC on the net, connected to a FPGA board. It
appears impossible for practical reasons but i have learnt
a lot about emulators, they solve all the problems.

Now, it's only the beginning of a new "project" because
we need to federate other Free HW projects, in order to
get sufficient sponsoring, for the server, the emulator
and everything around (Net connexion, electric power,
climatised room, sysadmin, compiler, everything else...)

This is going to be a large endeavour, and as the enclosed
file (that will be published on the f-cpu site) shows, there
is already a lot to do for the f-cpu project alone.

If you have a spare UltraSparc somewhere, tell us ;-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
The Business Search Engine
Find Business Information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--------------167B1B597ABBB1B9CE0E144D Content-Type: text/html; charset=iso-8859-1; name="todo_5.2001.html" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="todo_5.2001.html"
Freedom for the devices
Copyright 2001 Yann Guidon (whygee@f-cpu.org)
Verbatim copying and distribution of this entire article are permitted in any medium without royalty provided the copyright notice and this notice are preserved.
filename : todo_5.2001.html
file created : Tue May 1 13:53:52 2001
version : init
 

List of things to do, for the period of may-aug. 2001 :

mid-term top aim/goal :
- man v0.3
   - add new instructions, correct flaws, add new parts + illustrations
   - check fr & de translations
   - update the links to the most recent version,
      make PS, HTML and PDF versions for convenience

short-term papers/publications :
- sort all the files from the F-CPU archives in a convenient way
- cleanup the Ökonux conference files,
   submit them before June and publish them
- prepare the HAL2001 presentations
- misc. articles
- misc spec sheet RFC (F-BUS, F0 ...)

long-term programming/development :
- cleanup the VHDL files, ie remake the INC unit etc. (yg ++ ?)
- make a better and reference C simulator for the F-CPU model
   (Must be compliant with man v0.3)
   --> dedicate a few weeks with trollhunter, nicO, etc...)
- advance the GNL development (yghash, ygtk, ygui,...) (yg)
- check TRIMARAN and other high performance compilers
   --> being able to start coding the kernel

website :
- find webmaster(s)
- miror "external files" (nicO's etc.)
- Setup the CVS accounts in a stable and working state (Michael ????)
- update all the websites (with new and revised contents) (yg++)
- setup who'swho database, track down "who did what" and
   "who is responsible for what" ("who is in charge to maintain what, etc"). 
  (Graham + Lionel)

on top of that :
- Federate the Free HardWare developers in a OSDN-like way (press + news + etc...)
- prepare biz plan for the FWH server + find Celaro (yg)
- solve the licence problem once for all (?)
--------------167B1B597ABBB1B9CE0E144D-- From Kim Enkovaara Wed May 2 14:04:26 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01543 for ; Thu, 3 May 2001 12:35:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:23 +0200 (MEST) Received: (qmail 14789 invoked by uid 0); 2 May 2001 20:56:01 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx007-rz3) with SMTP; 2 May 2001 20:56:01 -0000 X-eGroups-Return: sentto-1101623-2728-988805072-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 02 May 2001 12:04:33 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 2 May 2001 12:04:31 -0000 Received: (qmail 91045 invoked from network); 2 May 2001 12:04:29 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 2 May 2001 12:04:29 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta3 with SMTP; 2 May 2001 12:04:29 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id PAA24085 for ; Wed, 2 May 2001 15:04:27 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <200105021112.0859@lh00.opsion.fr> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 2 May 2001 15:04:26 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 2 May 2001 nicolas.boulay@ifrance.com wrote:

> Where i work i try to puch to use linux on the eda
> tools. Most of the main Synopsys tools work under
> Linux. So a big beast as Athlon 1.3 with 2Go of Ram

I recommend that you should test P3/1GHz machines. In my Modelsim tests
they were much faster than Athlon/1GHz machines. For example in quite big
(750Mbytes) gate level simulation Athlon/1G took 3.5h and P3/1G 2.5h
simulation time. I haven't figuered out why this happens, propably cache
structure of Athlon is different from P3.

> So PC is the best choice. Maybe gays from PlaceNet
> could accept to host the PC ? We should ask them.
> (it's an 'association' that want to create adsl
> access for free software user)

PC is cheap platform in RTL simulations and in small gate level
simulations. In RTL the difference between PC and Sun is quite small. The
big caches in UII processor for example compensate quite much of the
CPU speed difference. And in big gate level simulations 3GB is not enough
to fit the netlist into memory. Going over 700M with linux needs usually
some tricks with glibc malloc tuning.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 1 19:36:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01561 for ; Thu, 3 May 2001 12:35:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:28 +0200 (MEST) Received: (qmail 4266 invoked by uid 0); 2 May 2001 21:06:48 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx03) with SMTP; 2 May 2001 21:06:48 -0000 X-eGroups-Return: sentto-1101623-2729-988820892-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 02 May 2001 16:30:28 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 2 May 2001 16:28:11 -0000 Received: (qmail 89384 invoked from network); 2 May 2001 15:58:00 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 2 May 2001 15:58:00 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 2 May 2001 15:58:00 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA21984 for ; Wed, 2 May 2001 09:57:58 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AEEF42F.BC089E3@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 01 May 2001 11:36:47 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> On Wed, 2 May 2001 nicolas.boulay@ifrance.com wrote:
>
> > Where i work i try to puch to use linux on the eda
> > tools. Most of the main Synopsys tools work under
> > Linux. So a big beast as Athlon 1.3 with 2Go of Ram
>
> I recommend that you should test P3/1GHz machines. In my Modelsim tests
> they were much faster than Athlon/1GHz machines. For example in quite big
> (750Mbytes) gate level simulation Athlon/1G took 3.5h and P3/1G 2.5h
> simulation time. I haven't figuered out why this happens, propably cache
> structure of Athlon is different from P3.

I recommend a bargain bin $500 computer, with lots of memory.
This way you can dedicate the machine for just simulation.
While I have not done much design most time spend designing is not
in simulation.While simulation takes a long time that is what nights
are for, assuming you have the time needed develop your product.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed May 2 19:14:53 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01594 for ; Thu, 3 May 2001 12:35:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:38 +0200 (MEST) Received: (qmail 9117 invoked by uid 0); 2 May 2001 22:36:51 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx24) with SMTP; 2 May 2001 22:36:51 -0000 X-eGroups-Return: sentto-1101623-2731-988826897-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hk.egroups.com with NNFMP; 02 May 2001 18:09:31 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 2 May 2001 18:08:17 -0000 Received: (qmail 50729 invoked from network); 2 May 2001 17:23:18 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 2 May 2001 17:23:18 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta3 with SMTP; 2 May 2001 17:23:18 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA03518; Wed, 2 May 2001 10:22:33 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K1SY4H11; Wed, 2 May 2001 18:28:51 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AF0408D.CF46E831@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: Andreas Romeyke Cc: "f-cpu@egroups.com" References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 May 2001 19:14:53 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: FCPU-Manual Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andreas Romeyke wrote:
> Hello YG,

hello !

btw, please don't use that address, use whygee@f-cpu.org instead.
i won't be at Mentor in a few days.

> There are some problems with F-CPU-Manual. As you can see in my past
> mails, the basis of my translation work was the original manual at
> http://www.f-cpu.de. Your "patch" is more useful and more actual as this.
I am aware of this trouble but unfortunately i require some long concentrated
time to do a good job. Here at work, i can't start anything, writing mails
is the only thing i can. Give me a few weeks, and let's organize a
"webmaster party" in order to work together. I leave Mentor in 2 weeks
and the manual is priority #1.

> Please, can you a) update the manual at http://www.f-cpu.de b) can you
> discuss/make your "patch" to the official document? c) can you add a file
> "TRANSLATION" with following points?
i will do them as soon as i come to a sufficient point.
If i fail, don't forget to flame me :-)

> Bye Andreas
>
> PS.: You can forward this message (also in parts) to the mailinglist. I am
> here at my university and I have not the right address in my mind  to
> forward this mail to the list.
ok, done.

> file TRANSLATION:
>
> There are many translations of the F-CPU-Manual:
> german - at http://gaos.org/cgi-bin/cvsweb.cgi/fcpu-manual-de, manitained
> by Andreas Romeyke (andreas.romeyke@web.de)
> french - at ...
>
> If you want to translate it in your favorite language, please send an
> email to the f-cpu mailinglist at... and follow the rules:
>
> - use the direct form of "you"
> - make translation of a paragraph in "switching style", one paragraph in
> english, one in new language
> - after translation, do not delete the english original text, plese mark
> it only via "%$-##", where "##" is your language-abbreviation. This method
> makes it easier to change something if the english original manual is
> updated.
> - if a file was translated, red over, correct it if necessary, proove the
> build of TeX-files and check resulting DVI-Document.
> - After then go to the next file
> - if you can, use the technolgy of cvs. That makes your life easier,
> believe it.

not bad.
it will have to be updated, though, when all the files will have found
a definitive home... The other translators will maybe add things, too.

YG

speaking for himself
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From boucli27@altavista.net Wed May 2 22:16:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01639 for ; Thu, 3 May 2001 12:35:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:54 +0200 (MEST) Received: (qmail 15890 invoked by uid 0); 3 May 2001 01:35:53 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx12) with SMTP; 3 May 2001 01:35:53 -0000 X-eGroups-Return: sentto-1101623-2732-988841296-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by f19.egroups.com with NNFMP; 02 May 2001 22:08:54 -0000 X-Sender: boucli27@altavista.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 2 May 2001 22:08:15 -0000 Received: (qmail 86073 invoked from network); 2 May 2001 20:16:18 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 2 May 2001 20:16:18 -0000 Received: from unknown (HELO rmx614-mta.mail.com) (165.251.48.52) by mta1 with SMTP; 2 May 2001 20:16:17 -0000 Received: from weba1.iname.net (weba1.iname.net [165.251.4.11]) by rmx614-mta.mail.com (8.9.3/8.9.3) with ESMTP id QAA12227 for ; Wed, 2 May 2001 16:16:13 -0400 (EDT) Received: (from root@localhost) by weba1.iname.net (8.9.1a/8.9.2.Alpha2) id QAA13269; Wed, 2 May 2001 16:16:13 -0400 (EDT) Message-Id: <010502161612DL.16109@weba1.iname.net> To: f-cpu@yahoogroups.com From: boucli27@altavista.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 2 May 2001 16:16:12 -0400 (EDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Well, it seems that some of the software that will be
run are solaris SPARC only binaries; thus we will have
to go for Sun | Tatung | Fujitsu hardware.

The problem with the *Blade series is that first you pay
a premium price, second they are still not reliable :
a lot of them are DOA ( dead on arrival ), thus I think
it should be wyser to stick to 'old' USII based servers.

It seems an Enterprise 4xx will do the job. We could spare a lot of money if we buy some refurbished hardware.

This kind of Hardware is sold directly by Sun or one of its subsidiaries.
http://www.sun.com/ibb/remanufactured/availability/workgroupservers.html

If we wait until October we will have a lot of bang for the bucks.

I think we may have a premium class server for ~$15.000 --> $20.000 thus we will have to launch a subscribtion
in order to get one of theses babies.

I think I will be able to find $1.000 for this project.

Who's next ?

Cheers,
Lionel
#########################################

Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
boucli27@altavista.net
http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html
http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html
06 68 99 65 89
----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed May 2 13:12:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01651 for ; Thu, 3 May 2001 12:35:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:58 +0200 (MEST) Received: (qmail 10863 invoked by uid 0); 3 May 2001 03:11:25 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx09) with SMTP; 3 May 2001 03:11:25 -0000 X-eGroups-Return: sentto-1101623-2727-988801795-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mq.egroups.com with NNFMP; 02 May 2001 11:09:56 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 2 May 2001 11:09:54 -0000 Received: (qmail 66591 invoked from network); 2 May 2001 11:09:53 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 2 May 2001 11:09:53 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 2 May 2001 11:09:53 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 2 May 2001 11:12:08 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105021112.0859@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 2 May 2001 11:12:08 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
Where i work i try to puch to use linux on the eda
tools. Most of the main Synopsys tools work under
Linux. So a big beast as Athlon 1.3 with 2Go of Ram
will be great (and not so expensive) and enought for
the beginning. (Nvidia use 600 'Linux box'). If the
project became bigger, we could just add more PC.

Count the number of time that the word Linux is
written on this page :
http://www.synopsys.com/products/sw_platform.html

And cf :
http://www.synopsys.com/news/announce/press2000/linux
_pr.html

And i try to prove that PC are faster than
ultraSparc. I think that Sun Blade 1000 are faster
but at 14000 $(for only 1 Go of memory) it could be !
( cf
http://store.sun.com/webconfig/BuildConfig.jhtml;$ses
sionid$HF53H5YAAAJEHAMTA1ESRUT5AAAACJ1K )

So PC is the best choice. Maybe gays from PlaceNet
could accept to host the PC ? We should ask them.
(it's an 'association' that want to create adsl
access for free software user)

nicO

-----Message d'origine-----
De: Yann Guidon <whygee@f-cpu.org>
A: fm <f-cpu@yahoogroups.com>
Date: 02/05/01
Objet: [f-cpu] back from Dortmund

Hello everybody,

Graham, Lionel and I were in Dortmund.
We made the conferences and discussed a lot.

We consider to setup a web server for online
digital design. Loaded with necessary sofware,
accessed through ssh and running batch queues
for the heavy tasks (ie : compiling large designs),
it will equiped with an external emulator for
simulation acceleration.

More than two years ago, we tried to see if we could
put a PC on the net, connected to a FPGA board. It
appears impossible for practical reasons but i have
learnt
a lot about emulators, they solve all the problems.

Now, it's only the beginning of a new "project"
because
we need to federate other Free HW projects, in order
to
get sufficient sponsoring, for the server, the
emulator
and everything around (Net connexion, electric power,
climatised room, sysadmin, compiler, everything
else...)

This is going to be a large endeavour, and as the
enclosed
file (that will be published on the f-cpu site)
shows, there
is already a lot to do for the f-cpu project alone.

If you have a spare UltraSparc somewhere, tell us ;-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~


Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



_____________________________________________________
_________________________
ifrance.com, l'email gratuit le plus complet de
l'Internet !
vos emails depuis un navigateur, en POP3, sur
Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Wed May 2 18:54:58 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01654 for ; Thu, 3 May 2001 12:35:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:35:59 +0200 (MEST) Received: (qmail 27422 invoked by uid 0); 3 May 2001 04:22:23 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx27) with SMTP; 3 May 2001 04:22:23 -0000 X-eGroups-Return: sentto-1101623-2730-988825223-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 02 May 2001 17:40:32 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 2 May 2001 17:40:22 -0000 Received: (qmail 75609 invoked from network); 2 May 2001 16:52:44 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 2 May 2001 16:52:44 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 2 May 2001 16:52:43 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 2 May 2001 16:54:58 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105021654.3a8b@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 2 May 2001 16:54:58 GMT Reply-To: f-cpu@yahoogroups.com Subject: Rep:Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -----Message d'origine-----
De: Kim Enkovaara <kenkovaa@cc.hut.fi>
A: f-cpu@yahoogroups.com
Date: 02/05/01
Objet: Re: [f-cpu] Which machine to use ?

On Wed, 2 May 2001 nicolas.boulay@ifrance.com wrote:

> Where i work i try to puch to use linux on the eda
> tools. Most of the main Synopsys tools work under
> Linux. So a big beast as Athlon 1.3 with 2Go of Ram

I recommend that you should test P3/1GHz machines. In
my Modelsim tests
they were much faster than Athlon/1GHz machines. For
example in quite big
(750Mbytes) gate level simulation Athlon/1G took 3.5h
and P3/1G 2.5h
simulation time. I haven't figuered out why this
happens, propably cache
structure of Athlon is different from P3.

-> I think that use 'old' athlon, the thunderbird use
1/1 clock frequency ratio to access the cache memory,
i remenber that old athlon use 1/3 of the clock.

> So PC is the best choice. Maybe gays from PlaceNet
> could accept to host the PC ? We should ask them.
> (it's an 'association' that want to create adsl
> access for free software user)

PC is cheap platform in RTL simulations and in small
gate level
simulations. In RTL the difference between PC and Sun
is quite small. The
big caches in UII processor for example compensate
quite much of the
CPU speed difference. And in big gate level
simulations 3GB is not enough
to fit the netlist into memory. Going over 700M with
linux needs usually
some tricks with glibc malloc tuning.

-> That's strange. Nvidia use redhat 6.2 with 2Go of
RAM. I have read that Linux could manage 64 Go of
memory. And 1Go server should be common (with ~100$
for 256 Mo of DIMM).

nicO

=====================================================
========================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi |
Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            |
curved-space fault in
02630 Espoo         |                      |
write-only file system




Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
FIND: 
Business-Only Search Results
Find Business Information

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From beucecase@aol.com Thu May 3 04:34:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01657 for ; Thu, 3 May 2001 12:36:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:36:01 +0200 (MEST) Received: (qmail 15482 invoked by uid 0); 3 May 2001 06:06:03 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx23) with SMTP; 3 May 2001 06:06:03 -0000 X-eGroups-Return: sentto-1101623-2734-988852058-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 03 May 2001 01:07:43 -0000 X-Sender: beucecase@aol.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 3 May 2001 01:07:37 -0000 Received: (qmail 46497 invoked from network); 2 May 2001 23:35:50 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 2 May 2001 23:35:50 -0000 Received: from unknown (HELO shine.micron.net) (204.229.122.198) by mta3 with SMTP; 2 May 2001 23:35:50 -0000 Received: from 10.224.0.198 ([10.224.0.198]) by shine.micron.net (Netscape Messaging Server 4.1) with SMTP id GCQET300.GEG; Wed, 2 May 2001 17:34:15 -0600 Received: from z-galaxy.com (1Cust186.tnt22.atl2.da.uu.net [63.36.158.186]) by with SMTP (MailShield v1.5); Wed, 02 May 2001 17:34:10 -0600 To: <> X-Sender: beucecase@aol.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: z-galaxy.com X-SMTP-MAIL-FROM: beucecase@aol.com X-SMTP-PEER-INFO: 1Cust186.tnt22.atl2.da.uu.net [63.36.158.186] From: beucecase@aol.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 02 May 2001 19:34:54 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Wow This Is Easy !! 135905 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20010503060605.15569gmx1@mx23.gmx.net> Status: R X-Status: N Dear Friends & Future Millionaire:

AS SEEN ON NATIONAL TV:
Making over half million dollars every 4 to 5 months from your home for
an investment of only $25 U.S. Dollars expense one time
THANK'S TO THE COMPUTER AGE AND THE INTERNET!
==================================================
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!
Before you say "bull", please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''.
DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER.
This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the
minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in."
Pam Hedland, Fort Lee, New Jersey.
===================================================
Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple
instructions and walaa... 3 weeks later the money started to come in.  First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the
program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first,
===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ======
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months easily and
comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS:
=====Order all 5 reports shown on the list below =====
For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose
name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN
ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems.
=== When you place your order, make sure you order each of the 5 reports. ===
You will need all 5 reports so that you can save them on your computer and resell them.
YOUR TOTAL COST $5 X 5=$25.00.
Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer.
IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!!  People have tried to put their friends/relatives names on all five thinking they could get all the money.
But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!!
1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune.
2.... Move the name & address in REPORT # 4 down TO REPORT # 5.
3.... Move the name & address in REPORT # 3 down TO REPORT # 4.
4.... Move the name & address in REPORT # 2 down TO REPORT # 3.
5.... Move the name & address in REPORT # 1 down TO REPORT # 2
6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE
SURE you copy every name & address ACCURATELY!
==========================================================
**** Take this entire letter, with the modified list of names, and save it on your computer. ****
DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information that includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more.
There are 2 Primary methods to get this venture going:
METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
==========================================================
Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each).  Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2.  Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails.

The 0.2% response to that is 1000 orders for Report # 3.  Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report

# 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million).  Your total income in this example is: 1... $50 + 2... $500 + 3... $5,000 + 4... $50,000 + 5... $500,000 ... Grand Total=$555,550.00
NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT
THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY!
=========================================================
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO.  Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more!
METHOD # 2: BY PLACING FREE ADS ON THE INTERNET
=======================================================
Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders.  This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report.
====================AVAILABLE REPORTS ====================
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report.  Checks NOT accepted.  Make sure the cash is concealed by wrapping it in at least 2 sheets of paper.  On one of those sheets of paper, write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW:
====================================================
REPORT # 1: "The Insider's Guide to Advertising for Free on the Net"
Order Report #1 from:

Brenda Goedike
23123 Cheyenne Dr.
Valencia, Ca.91354
USA
___________________________________________________________
REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net"
Order Report # 2 from:

M & E Atkins
18515 20th Dr. S.E.
Bothell, WA. 98012-6986
USA
___________________________________________________________
REPORT # 3: "Secret to Multilevel Marketing on the Net"
Order Report # 3 from:

B.Case
217 Cherrywood Dr.
Woodstock, Ga.30188
USA
__________________________________________________________
REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net"
Order Report # 4 from:

A. Ozirny
Box 7103
Bonnyville, Alberta
T9N 2H4, Canada
____________________________________________________________
REPORT #5: "How to Send Out 0ne Million e-mails for Free"
Order Report # 5 from:

C.J. Kalata
P.O. Box 130157
Roseville, MN 55113-0002
USA


___________________________________________________________
$$$$$$$$$$$$$$$$$$$$YOUR SUCCESS GUIDELINES$$$$$$$$$$$$$$$$$$$$
Follow these guidelines to guarantee your success:
If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do.
After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2.  If you did not, continue advertising or sending e-mails until you do.
Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in!
THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in front of a Different report.
You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you.
IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN.
There is NO LIMIT to the income you can generate from this business!!! ======================================================
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now.  Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...#3...#4...and # 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them.  Remember though, the more you send out the more potential customers
you will reach.  So my friend, I have given you the ideas, information, materials and opportunity to become financially independent.  IT IS UP TO YOU NOW!
==================== MORE TESTIMONIALS ====================
"My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money.  When I received this program I grumbled to Jody about receiving ''junk mail''.  I made fun of the whole thing, spouting my knowledge of the population
and percentages involved.  I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet.  I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''.
Mitchell Wolf M.D., Chicago, Illinois
======================================================
''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I
wouldn't get enough orders to at least get my money back''.  '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about
this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big."
Dan Sondstrom, Alberta, Canada
=======================================================
''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks."
Susan De Suza, New York, N.Y.
=======================================================
''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was
$362,840.00. Life is beautiful, Thanx to Internet."
Fred Dellaca, Westport, New Zealand
=======================================================
ORDER YOUR REPORTS TODAY AND GET STARTED ON
'YOUR' ROAD TO FINANCIAL FREEDOM!
=======================================================
If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.
=======================================================
Under Bill s.1618 TITLE III passed by the 105th US Congress, This letter cannot be considered spam as long as the sender includes contact information and a method of removal.
This is a one-time e-mail transmission. No request for removal is necessary.
===========================================================
Under Bill s.1618 TITLE III passed by the 105th US
Congress this letter cannot be considered spam as long as the sender
includes contact information and a method of removal.
This is a one time e-mail transmission. No request for
removal is necessary.
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed May 2 07:33:46 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA01678 for ; Thu, 3 May 2001 12:36:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 03 May 2001 12:36:09 +0200 (MEST) Received: (qmail 22817 invoked by uid 0); 3 May 2001 08:00:45 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx26) with SMTP; 3 May 2001 08:00:45 -0000 X-eGroups-Return: sentto-1101623-2738-988870708-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 03 May 2001 06:26:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 3 May 2001 06:18:27 -0000 Received: (qmail 38918 invoked from network); 3 May 2001 06:18:26 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 3 May 2001 06:18:26 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 3 May 2001 06:18:26 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id AAA13408 for ; Thu, 3 May 2001 00:18:24 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AEF9C3A.E367DE35@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 01 May 2001 23:33:46 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
> In current big ASICs verification effort can be 50-70% of the whole design
> time. And most of that time is spend burning CPU cycles. I see simulation
> as the bottleneck of design. RTL design is quite small part nowadays from
> the total design effort.

Simulation can be a bottle neck, but the real issue is the resources allotted
for a given project. What machine to use is like asking "what is the best
automobile to drive". Both have to matched to the project at hand. Every
project too has a critical path and that study can be difficult to make.
Also architectural factors could have a big impact too.
On a FPGA project I am doing I have passed a critical point for routing,
where routing is 100x longer than a easier design to route using the same #
of logic cells.Since any factor can have major impact on design, it best
to stay as close the hardware as practical.
Ben. 
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Wed May 2 18:29:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01661 for ; Sat, 5 May 2001 00:45:22 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:45:22 +0200 (MEST) Received: (qmail 31364 invoked by uid 0); 3 May 2001 11:16:11 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx10) with SMTP; 3 May 2001 11:16:11 -0000 X-eGroups-Return: sentto-1101623-2735-988854036-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 03 May 2001 01:40:38 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 3 May 2001 01:40:35 -0000 Received: (qmail 10704 invoked from network); 3 May 2001 00:41:17 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 3 May 2001 00:41:17 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.51) by mta1 with SMTP; 3 May 2001 00:41:15 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01513; Wed, 2 May 2001 18:29:06 +0200 Message-ID: <20010502182906.65446@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <200105021112.0859@lh00.opsion.fr> X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Wed, May 02, 2001 at 03:04:26PM +0300 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 2 May 2001 18:29:06 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, May 02, 2001 at 03:04:26PM +0300, Kim Enkovaara wrote:

> I recommend that you should test P3/1GHz machines. In my Modelsim tests
> they were much faster than Athlon/1GHz machines. For example in quite big
> (750Mbytes) gate level simulation Athlon/1G took 3.5h and P3/1G 2.5h
> simulation time. I haven't figuered out why this happens, propably cache
> structure of Athlon is different from P3.

It might also be the memory subsystem.  I've recently seen one 800 MHz
P3 outperform another, as well as one of its 933 MHz cousins(!), just
because the chipset on that machine supported interleaved RAM banks.
All systems had "GenuineIntel" P3 CPUs with Coppermine cores and 256 KByte
L2 cache.  The 933 MHz CPU does, of course, calculate things faster when
the program fits into the cache -- but that's not true in this case,
and it also wasn't true for the benchmark (SPEC CPU2000).

So, for big simulations, look for the machine with the fastest memory
interface you can get (and 2...4 GByte of RAM :).

If you're interested in the memory and cache characteristics of P3
and Athlon, run lmbench on both machines.  I think you can find it at
http://www.bitmover.com/lmbench/.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "Guillaume Lederrey" Thu May 3 00:26:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01714 for ; Sat, 5 May 2001 00:45:38 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:45:38 +0200 (MEST) Received: (qmail 25733 invoked by uid 0); 3 May 2001 13:29:45 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx18) with SMTP; 3 May 2001 13:29:45 -0000 X-eGroups-Return: sentto-1101623-2733-988849298-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mo.egroups.com with NNFMP; 03 May 2001 00:21:39 -0000 X-Sender: GLederrey@SwissOnline.ch X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 3 May 2001 00:21:36 -0000 Received: (qmail 70250 invoked from network); 2 May 2001 22:29:48 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 2 May 2001 22:29:48 -0000 Received: from unknown (HELO PrintServer.LedCom) (195.15.65.105) by mta2 with SMTP; 2 May 2001 22:29:46 -0000 Received: from athlon (Athlon.LedCom [192.168.0.2]) by PrintServer.LedCom (8.11.0/8.11.0) with SMTP id f42MTNw01440 for ; Thu, 3 May 2001 00:29:38 +0200 Message-Id: <200105022229.f42MTNw01440@PrintServer.LedCom> To: "f-cpu@yahoogroups.com" Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <200105021112.0859@lh00.opsion.fr> From: "Guillaume Lederrey" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 03 May 2001 00:26:29 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N >So PC is the best choice. Maybe gays from PlaceNet
>could accept to host the PC ? We should ask them.
>(it's an 'association' that want to create adsl
>access for free software user)

  That's just "word in the air" but I might be able to find a
place to host a PC (or sparc, or whatever ;-) at my university
(Swiss Institute of Technology - EPFL).  I'll have to check if
it is a long term solution, if it is alawed, ...  But if it
works, we could have a PC right on the Swiss Internet Backbone.

  Let me know if that sounds good !

      Guillaume
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu May 3 07:07:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01798 for ; Sat, 5 May 2001 00:46:05 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:46:05 +0200 (MEST) Received: (qmail 15142 invoked by uid 0); 3 May 2001 17:23:33 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx03) with SMTP; 3 May 2001 17:23:33 -0000 X-eGroups-Return: sentto-1101623-2736-988866787-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ch.egroups.com with NNFMP; 03 May 2001 05:13:08 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 3 May 2001 05:13:06 -0000 Received: (qmail 54550 invoked from network); 3 May 2001 05:07:27 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 May 2001 05:07:27 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 3 May 2001 05:07:27 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA24260 for ; Thu, 3 May 2001 08:07:25 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3AEEF42F.BC089E3@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 3 May 2001 08:07:25 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 1 May 2001, Ben Franchuk wrote:

> I recommend a bargain bin $500 computer, with lots of memory.
> This way you can dedicate the machine for just simulation.
> While I have not done much design most time spend designing is not
> in simulation.While simulation takes a long time that is what nights
> are for, assuming you have the time needed develop your product.

In current big ASICs verification effort can be 50-70% of the whole design
time. And most of that time is spend burning CPU cycles. I see simulation
as the bottleneck of design. RTL design is quite small part nowadays from
the total design effort.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu May 3 07:12:04 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01900 for ; Sat, 5 May 2001 00:46:41 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:46:41 +0200 (MEST) Received: (qmail 7855 invoked by uid 0); 3 May 2001 21:40:07 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx04) with SMTP; 3 May 2001 21:40:07 -0000 X-eGroups-Return: sentto-1101623-2737-988866888-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jk.egroups.com with NNFMP; 03 May 2001 05:14:50 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 3 May 2001 05:14:48 -0000 Received: (qmail 41723 invoked from network); 3 May 2001 05:12:06 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 3 May 2001 05:12:06 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta3 with SMTP; 3 May 2001 05:12:06 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA00196 for ; Thu, 3 May 2001 08:12:04 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <200105021654.3a8b@lh00.opsion.fr> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 3 May 2001 08:12:04 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: Rep:Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 2 May 2001 nicolas.boulay@ifrance.com wrote:

> -> That's strange. Nvidia use redhat 6.2 with 2Go of
> RAM. I have read that Linux could manage 64 Go of
> memory. And 1Go server should be common (with ~100$
> for 256 Mo of DIMM).

In IA32 PAE mode (I hope this was the right three letter acronym :)) one
process can only use 4 gigs of memory. Usually simulators use just one
process. The whole machine can have more memory, but that must be shared
to many processes.

As a hint if you encounter problems in linux simualtions these almost
undocumented environment variables usually help if the programs say that
there is not enough memory altough there is:

export MALLOC_MMAP_MAX_=1000000
export MALLOC_MMAP_THRESHOLD_=0

Those are hints for the glibc memory allocator.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Fri May 4 03:14:13 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01921 for ; Sat, 5 May 2001 00:46:48 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:46:48 +0200 (MEST) Received: (qmail 301 invoked by uid 0); 4 May 2001 01:16:34 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx05) with SMTP; 4 May 2001 01:16:34 -0000 X-eGroups-Return: sentto-1101623-2739-988938963-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 04 May 2001 01:16:04 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 4 May 2001 01:16:02 -0000 Received: (qmail 23157 invoked from network); 4 May 2001 01:16:00 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 01:16:00 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 4 May 2001 01:15:59 -0000 Received: from f-cpu.org (nas4-96.ras.club-internet.fr [195.36.203.96]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA00339 for ; Fri, 4 May 2001 03:15:47 +0200 (MET DST) Message-ID: <3AF20265.DD0589B0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 04 May 2001 03:14:13 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello everybody,

were present Lionel, nicO, Nicole and myself,
we discussed during some hours.

I have got some informations and data about
the Celaro machines but give me some weeks to find
a deal with the company (i'm a R&D guy, i have never
dealt with the ones with ties ... so be patient)

There are a few possibilities :
- refurbished or R&D HW/protos
- single-slot Celaro (around 20-40K gates)
- old SimExpress (a bit larger, maybe cheaper,
      but not supported anymore)
- stripped-down Celaro (24-slot capable, but
    populated with a minimum of boards to decrease
    the price, since each logic board costs a huge
    amount of $$$$)
- competitors

I have not yet done much things. However the single-slot solution
could maybe be affordable and we'll go larger later. SS is usually
used for demonstrations is is capable of running the same SW as
the larger ones, with the possibility of connecting it to external
devices, so we can plug that to an existing device. It is already
certainly capable of verifying the IMU for example, i guess it can
reach 6MHz of real clock. Plus it works on a normal wall plug for
its electricity.

But that is for the Phase 1.

Phase 0 will be to find a location, a network, a legal and official
arrangement for the costs (electricity, climatisation...), putting
a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
the account management, the job queue...

At that stage we can already put some other SW such as physical synthesis etc.


Phase 2 would be the larger scale emulation. 12 Celaro slots should
work for a mid-scale design (ie FC0).

Phase 3 would be a prototype tape-out...

But before we do that, we all have a lot of work.
Lionel (trollhunter) is preparing the who'swho database, which will
also serve as a task management tool. Not only we will know who did
what, but also what projects are going on and what project needs help.

More than that has happened, but i have to sleep now.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Fri May 4 11:58:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01990 for ; Sat, 5 May 2001 00:47:09 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:47:09 +0200 (MEST) Received: (qmail 22270 invoked by uid 0); 4 May 2001 09:57:45 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx22) with SMTP; 4 May 2001 09:57:45 -0000 X-eGroups-Return: sentto-1101623-2740-988970191-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 04 May 2001 09:56:32 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 09:56:29 -0000 Received: (qmail 23607 invoked from network); 4 May 2001 09:56:29 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 4 May 2001 09:56:29 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 4 May 2001 09:56:29 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Fri, 4 May 2001 09:58:16 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105040958.10b0@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 4 May 2001 09:58:16 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] French meeting (in Paris) in english Content-Type: multipart/mixed; boundary="----=_NextPart_988970295_1841070896003658" Status: R X-Status: N ------=_NextPart_988970295_1841070896003658 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit May 29th, Professor Vojin Oklobdzija will give two
lectures
respectively on "Modern Microprocessor Architectures:
Evolution of RISC into Super Scalar" and "Timing
Elements and Timing issues in High Performance
Processors". This Event is sponsored by CAS
Distinguished Lecturer Program and by IEEE French
Section and will take place in ISEP, 28 rue Notre
Dame-Des-Champs, Paris 6?me at 2:0 pm. The conference
will be followed by a CAS meeting.



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
Ebates: Click here for cash back at 400+ stores!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------=_NextPart_988970295_1841070896003658 Content-Type: application/pdf; name="vojin.pdf" Content-Disposition: attachment; filename="vojin.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjExIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0v TyAxMyANL0ggWyAxMTIyIDIwMSBdIA0vTCAxNDE3OSANL0UgMTI3MDkgDS9O IDEgDS9UIDEzODQxIA0+PiANZW5kb2JqDSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4cmVmDTEx IDMyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA5ODYgMDAwMDAgbg0K MDAwMDAwMTMyMyAwMDAwMCBuDQowMDAwMDAxNTMwIDAwMDAwIG4NCjAwMDAw MDE3NTMgMDAwMDAgbg0KMDAwMDAwMTk0NCAwMDAwMCBuDQowMDAwMDAyNDI1 IDAwMDAwIG4NCjAwMDAwMDI2MjMgMDAwMDAgbg0KMDAwMDAwMzEyNyAwMDAw MCBuDQowMDAwMDAzMTc2IDAwMDAwIG4NCjAwMDAwMDMzNTYgMDAwMDAgbg0K MDAwMDAwMzM3OCAwMDAwMCBuDQowMDAwMDA0NTM5IDAwMDAwIG4NCjAwMDAw MDQ1NjAgMDAwMDAgbg0KMDAwMDAwNTQ3NyAwMDAwMCBuDQowMDAwMDA1NDk4 IDAwMDAwIG4NCjAwMDAwMDY0NjggMDAwMDAgbg0KMDAwMDAwNjQ5MCAwMDAw MCBuDQowMDAwMDA3NjAzIDAwMDAwIG4NCjAwMDAwMDc2MjQgMDAwMDAgbg0K MDAwMDAwODU5NSAwMDAwMCBuDQowMDAwMDA4NjE2IDAwMDAwIG4NCjAwMDAw MDk2MzEgMDAwMDAgbg0KMDAwMDAwOTY1MiAwMDAwMCBuDQowMDAwMDEwNzI4 IDAwMDAwIG4NCjAwMDAwMTA3NDkgMDAwMDAgbg0KMDAwMDAxMTIxOSAwMDAw MCBuDQowMDAwMDExMzEzIDAwMDAwIG4NCjAwMDAwMTE2OTMgMDAwMDAgbg0K MDAwMDAxMjU3MSAwMDAwMCBuDQowMDAwMDAxMTIyIDAwMDAwIG4NCjAwMDAw MDEzMDMgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA0Mw0vSW5mbyA5IDAg UiANL1Jvb3QgMTIgMCBSIA0vUHJldiAxMzgzMSANL0lEWzw0MWMzYmEwMTVh YzIwMmU5OTkzMjk1YTI1OTFmMjc3MT48NDFjM2JhMDE1YWMyMDJlOTk5MzI5 NWEyNTkxZjI3NzE+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgIA0xMiAw IG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAxMCAwIFIgDS9PdXRs aW5lcyAxIDAgUiANL09wZW5BY3Rpb24gWyAxMyAwIFIgL1hZWiBudWxsIG51 bGwgbnVsbCBdIA0vUGFnZU1vZGUgL1VzZU5vbmUgDT4+IA1lbmRvYmoNNDEg MCBvYmoNPDwgL1MgMzYgL08gMTAzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M ZW5ndGggNDIgMCBSID4+IA1zdHJlYW0NCkiJYmBgkGNgYEliAAIdOwZsgANK CwCxDBQzMIgycIs7a4TKHEyqOPBgPoPhBQYLBoa3DjwuDHw3GOwUGNkPMB7k VJ27pnkCVLsGA4PBAohxzLsBAgwAj8UP+A1lbmRzdHJlYW0NZW5kb2JqDTQy IDAgb2JqDTkwIA1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDEwIDAgUiANL1Jlc291cmNlcyAxNCAwIFIgDS9Db250ZW50cyBb IDIyIDAgUiAyNCAwIFIgMjYgMCBSIDI4IDAgUiAzMCAwIFIgMzIgMCBSIDM0 IDAgUiAzNiAwIFIgXSANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Ny b3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN MTQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9J bWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE2IDAgUiAvVFQ0IDE4 IDAgUiA+PiANL1hPYmplY3QgPDwgL0ltMSAzOCAwIFIgL0ltMiAzOSAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MCAwIFIgPj4gDS9Db2xvclNwYWNl IDw8IC9DczUgMjAgMCBSIC9DczkgMTkgMCBSID4+IA0+PiANZW5kb2JqDTE1 IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODkx IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0Zv bnRCQm94IFsgLTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL1Rp bWVzTmV3Um9tYW5QU01UIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDT4+ IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAv VHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjIgDS9XaWR0 aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMzMgMjUwIDAg NTAwIDUwMCA1MDAgMCAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDMzMyAwIDAg MCAwIDAgMCA3MjIgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDc3OCAzODkgMCAw IDY2NyANOTQ0IDcyMiA3NzggNjExIDAgNzIyIDU1NiA2NjcgMCA3MjIgMCAw IDAgMCAwIDAgMCAwIDAgMCA1MDAgNTU2IA00NDQgNTU2IDQ0NCAzMzMgNTAw IDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4 OSANMzMzIDU1NiA1MDAgNzIyIDAgNTAwIDQ0NCBdIA0vRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuUFMtQm9s ZE1UIA0vRm9udERlc2NyaXB0b3IgMTcgMCBSIA0+PiANZW5kb2JqDTE3IDAg b2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0v Q2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0ZvbnRC Qm94IFsgLTU1OCAtMzA3IDIwMzQgMTAyNiBdIA0vRm9udE5hbWUgL1RpbWVz TmV3Um9tYW5QUy1Cb2xkTVQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMz IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5 cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIyIA0v V2lkdGhzIFsgMjUwIDAgNDA4IDAgMCAwIDc3OCAwIDMzMyAzMzMgMCAwIDI1 MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDI3OCAwIDAgMCAwIDAgMCA3MjIgNjY3IDY2NyA3MjIgNjEx IDU1NiANNzIyIDcyMiAzMzMgMzg5IDAgNjExIDg4OSA3MjIgNzIyIDU1NiAw IDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IA0wIDcyMiAwIDAgMCAwIDAgMCAw IDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAg DTI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAg NzIyIDUwMCA1MDAgNDQ0IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5n IA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW5QU01UIA0vRm9udERlc2NyaXB0 b3IgMTUgMCBSIA0+PiANZW5kb2JqDTE5IDAgb2JqDVsgDS9JbmRleGVkIDIw IDAgUiAyNTUgMzcgMCBSIA1dDWVuZG9iag0yMCAwIG9iag1bIA0vQ2FsUkdC IDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAy LjIyMjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAu MjEyNiAwLjAxOTMgMC4zNTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3 MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0yMSAwIG9iag0xMDgzIA1lbmRv YmoNMjIgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAy MSAwIFIgPj4gDXN0cmVhbQ0KSImMVdtu4zYQfddXzCMJRIxI3fOWOt42RXeb xkZfFvugyPQldSyvKCeb/foOOSNvFKDoIkAkzu2cmTOiL39daNi46GtUaUjw LzaZKg1kRhUZlFmptIH2Kbq8fdJw00V/RZczl0PrQIc/10ZZmShTQImJhQGd JCrLwBj/v7fR+uzPcqWz0R/rWuUFBSQBGCt9jbwXzYEIRhQVhOyQPPIwxOOX ZXS5XCIgLNeRzlVNafSma+2Ti6pSta5rWD5FiUqSxMCyjWL/ajDvJfosPtzP P81+k6kqBNzO5/N4dr0ANlzfLef38svy90hnKsmofnirClUbKEqNYFqP5fW5 ehqqi8WxO7iutyt4eIVha8EXX3Ttzg6vcDqsbA+7wcHNzg27w+a0c1sM/cO2 w6lH113fbfrmSS4fI21UVeoK1VFpju3cBLwsPQOiWKEdU8NHWYnmFQzyCdwx RaMwsVa6rPOQG8g1g6+M5iSvq4l7bOWzuFU4CC0W9JjT4y6UjXOVG529TQxM dHEmleRMSmJwLSp6wP3JwqeODkNv4aah9yepE3xYiV0aATfWeTvqMttOI46O GyuRwXvm6Q8VckP4ZY4DgjuJyyywksbq/c5dyNzDfAjmXhqVi+bQWtLbkNjj h5BnWmW44V5pai2gjG8eZMny/peYnnqJOCn+79Yy9qjW4XbA393j7gB//rPv Hlbfd4/NBbx4dy12+z1sds8WBjZ0sKd67irQrAPLeiRpECEsBZNMi5FkURPJ QEf6UeLcNY4iUam4knHqdfko/TdXiS6ovAphtj+E59m580pUou27I9WR+H2K rqVWrvt2G8wcNlDpN6juCubP3Z7cZOQgTiF0Ru3WcH+78M1nYuaVywRwHEUM HbCbah2ZdczWNtBrGK/paXPw4sjo4kjC+mR1et7flGeWpqwr7kcltjKuUbiA bQQuJt5TAo5k7X0DKappD2QYKKxB8Go8cGpHERwILZ+fbe+AIxnLwuY0QV1N Tlxh847E1NvykWP2dLIOGHaNWykAP6ssTD7YGMYG8v1IlGO4HspP9phQpxzY F3aCHYDieVfjF+RtG9wzbgi9nKYjVTIu8Dmm33LUuRzTa7izV6lL8R37Y//7 ibL5gbNCi24UdfROZsO2sIUFRs/87VSK/+0nlMam/LrleONo3KdkvKOK85KV tGSnXhaYg5+jFtDQ87ACJyu/e92LNNozDUf/Q8I3MNcNN2D6Y4XxRyCUN0nB N2Bvw4B0aLkmkpooa+q3oJXB23aYWEn4eoxl4QsS3pz7L8YAzmY9NelZkJ44 FmgYZsXlj5NsPtnAcj9hyXlYwUEDD3SidhyHOFjT6JhjD1NuGz7GI0z/Lp57 HTm2FjiTHZzHxCxbLYcPPzvisNS4xP5qqcV2bOzwtvlvXADcOFEGv+Bkx5Od jKyPXdtMpO5/rgX55V8BBgDOkU5VDWVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBv YmoNODM5IA1lbmRvYmoNMjQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAyMyAwIFIgPj4gDXN0cmVhbQ0KSImMVU1v2zAMvedX6GgB s2f52z1vwFr00IOxHYYeXEdJjLp2IDnttl8/iqSS2EWHXWLTJB8fHymludvk WZRkIhbNl00cxXGWiKaDN1XXSjRvm5/BOLeyilQw99NoZRGVgeitfGzuNiHl hipSZZp6hLRgBFWXhKBlGWXBL6niKA2OQ4tmLxX8juTbCqlScL5JVUOpfj7w B0N+e6Rnh78zpnLEPAl2mp1URVQEk3mRiYugQiMlUYzgb1ux7TmcH8SHYk8y TIHGMPdcXkwcJXrGPg7kYtMZeTBS3kxFnGCRaKTKwDiQi1nYk+ccWipJKYO8 8DbStSeOPYcOPYsF8gtKmsbZULCdWUgqI0CV+dBeq3Xu4JXmoHGEeRKpqigv 86/88PKUhtdJpaIKUHL4nQxAlk5F/Agyfr+XqoLXW3T84L1g1KvNCHE1ckQn 4BcnTBq0HUgDjBKYQJgDxsimthGifW6aRMAu7iAxTKK0jMszYJIS3TjOC0K9 1918Ai4JrI5IZFgHNxKyoO8GRpfGUADqZDgsF7V3IeLroNmp6fNsRUtvW/z9 Z/attVRSW9GTQ3zr0Xcg60GbnVtLRGilWwiK67R4MFOnrZ2M9e1m53ZBv6x+ px+8FRW12wBKGqwUtGDCCpDRSjftgYxn2Cmg002c8KoNUOYsaMIrL3zATtbQ rMfiSJ7cal77G7JFx8U8RocMntfhSOWTDAvYno9yxHbVGRMxbD+x2zNf8vRg vqQbKb152P9rTGhmpzlAj8t6JPgqTcAzpZN/3cLe2+HRy21IZU/X+JPhkWBJ GMv+doc4P+vgCcFRIR05brkW5/QPVNbbFWWAx8tBRXEOxze+LGDJC5jEGS0g QbnbKoSLa69Zq5qpKa9VRlrVqBXOwmi+LLjK+rJI+CqK8zqnWg7BNeXE0sI6 QZ3aznTbVOOWw8UGs4DiKGjtxaLhO7PFKBDSnb8/rndcce/2Nj8d2hMnwuvs K/iwDlmY7kQ2WlSPyhp2dGixYfjPgM6e72FB+qq8WfgxozMcdlwA8ke8TthB mwGKNLI6a0ecqTiCMsy0QEPGrunRw1IGTNCtzZL7cjY7ifvUUtcLZ/v+k+Zh 0Pqll6Ye/wowANWx+aoNZW5kc3RyZWFtDWVuZG9iag0yNSAwIG9iag04OTIg DWVuZG9iag0yNiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDI1IDAgUiA+PiANc3RyZWFtDQpIiYxWTXObMBC9+1fs9IRmagbxaffc U86+dXLAQGJNCDggN/W/r/ZDWMbNTC9IWu2+fSs9Fg5Pm0LHeZFlkMDh5yaJ k6TM4NDgrMwqOHxufkXjb6WzyLSd0kmsI6hxTCM4jpehrdk4qTK6qufD02br Ebc61pUbBTevEHeLU50z8LFTu7iI7KdKEZBX/BzU1mWwJ14BD46HwxaPSeVu vqXnrCoXf2KTGd7Yz6gUkV55BWdz5sjeDDxpKQkHW3Kuyf4a5uHtGA5KF255 whhh1fL4rtJb7NDCi9JVXEUjejIlOBnBpHAmfb4hsddj3D0y2pvgjGCVmEcb 0vYULe+ZXgoHd3NhajkDj2SWQxuFFFgj2W57hqP4eblVI6lrkkORxvk+1Ffu 9aVTkYE7Mr5oF2QGOxksUlNZmu5FO2CWloCtpFUIYqFFsWagG95RdY68068j TDIr8Hy1M/IWSaXyRS2uWPbOL6T03YMX5+gV7vFcHHkxcCKL51E4BXEQ6WiH QsBN9gTLY0PP02A+LmzgUBCWwyglDFAH2z/gG0KnN6KCehy5SH5K3QJhiLUv SAC+K6pOVoze1wE1IQLnMD8//wkIwsBDMspVpYVMe6HKGDY4Ss7QmzViHVys rzNkw7YWxgHsosCyrG4KLNJFLwXrxalvH+F7ixqs3bxRe9Jehj0IDTINdIiQ gQ6psWWlIKdJxsjdH6u2BRHeZvE+qkHWhod3pXNsfYBiSeIs6rrWz/wEmlFm Fxl7Dl4cjj5EUWNepXwE/MQj3XsO4n7yu6t19xXlWmjI4EkKOHNZUr64E80X n+kxyXBXgz82aK5Kly6ykSxdrLalg3f9mHq+RHngGUWub5y7xnt4fKniY3Wk nHaGeupAXHxEM3X1vLK9Ch1hB5dV/qXu2ke0Xx2vh3CZWa86Tu/0mi4dM5eO iW0S3/WE2mRJn6+E2iTOe5pfsRW4dBMaNb7GOFhetcunOl3pmGS8NNQs5YR2 9L3QvQIVwvKSGm1FF+p7rN7jZeCrOr3xjwK9wnS67ieBviglNjWqQOON+H1g rF5puhCciwsvBsa1M32Nc2c5scXM4L5dFCs5gYiYvoc6wJxHOE+MhVzuUcUT hoskPfrSFspNgDXyQvKxawuzHSfGeQ03/rsyuMwCxRZ30yCeY4s7eTQtFkNw zGNS6D6q578CDADy8jx0DWVuZHN0cmVhbQ1lbmRvYmoNMjcgMCBvYmoNMTAz NSANZW5kb2JqDTI4IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M ZW5ndGggMjcgMCBSID4+IA1zdHJlYW0NCkiJnFVLb9tGEL7rV8xxNxC33OVL 7C2x3cJG3QYx2yJocpCpdcRapgSSitH++szszCqUESBFeeC+Zr755rGzzc2i cKYoIYXmcpGaNC0raFqaFdA8L/5Sh0GXJlf7VtvUFMrTUKpR18bJf69TxUK8 hjWL9ri/0R+bm0XCNhJrbJVl0ZJbiaU02tp0Y4tApTqOI0xbH+YwdU/akdGu /4QGCgXdOB75cNSFycgiLfoNbGS7Y8leJ5mpFfDqyKtOhHZdPwcxgeoPTePA QvOwsA6DkgIOLs/MagVZUZhV5nJonhZJcKCODtCMHLjTSWkq1eoU7Wx54cNi w4sjDzudFMYqD/sHndTEcIrS8Aud1cq3kwgPfozUcqZWB2Y1EstNCVmWGuvS jHiFDBIrJlgxLZtv0zRBLytli22Wwo+AZmxpVsiuxn8b/pNGP9VxCIJ8ADaY TiFxJsupNi4Jj0AEr0RowrvAUGZYC2i4Ug/a1vxjGAG7n0Ovw/8x4DevCLX8 yrIS1P/I0kUU8jo/+Z9G/wlOJzYva6qW8AXKOS5fI00sjjtZYh4cAq91hcAH Xkw+rAa0XCm45RX/JyrK88JJnDN5DlhrBQ4YsMClclIsFc2I1VtKPaaXqhIv GFZChTwM8qTbA3/oVQxoof7mw45UctXDzyex3x61Laia+Ujk7zf/MqxoiP76 RSFZaxycSoWvZR4bQFlkTHQJ+/tpjXSIgKNr5cNiA+iCpQ0KmjKXWAK1MtD1 GMuCqDiFV5cEDseJdQYMcq7grmU43ux5xQvAuqlCXEhyLwChHYTj34OVnsC7 zxo9yNUcesS04Mn0j3Y5ZWsvcIESO7HrZG/PKn3H+0tNYFRzhRH6jAavqQE5 NvppbnPHg4ih47ZeuSXcin/Uj2gUHTbn586iCsYww0zbulpxt+SsnDXLbFVy LpgpdjoONufjsDNwza7MGBp254MKJ7ea6kJ4XV190JyI7wT7ShxktSlYY1m2 zPsS1rADV73YP6uVeYq6KCFO8NlhPRNhS0JHimRa/u/cv9ERZXeWCjYpSVrC +wB/nMVwVgTsHmuIbakbzntlDfz0Io5UDTDtcaxDagt8f7711malpNfC1vPr Cc+E4ZQ8pudP6yTPaoCbVcrpKrfxJSDQSSc5v0fUCjxcv7mllwVfnQb5W2o5 pboJ/z9DU0MruC1qI3UUeuW59fAA7/zo10MrmHDh5UCU/AAdz6LCr/5ZY6/A Zv1eoIZHkK3IbPAQp4FBPD8p+I2gvWCzmWt99js2LUIHHp7oWuObe040Ij1Q YPFteHcd3vBCXVDrR+ivTopD0cNWJkchh/0WY7sW+Ej0MDsVU60fx+jRyLcf K/GFnmyPxzMfyEGnhmRssZN/EWAAFa4tSg1lbmRzdHJlYW0NZW5kb2JqDTI5 IDAgb2JqDTg5MyANZW5kb2JqDTMwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMjkgMCBSID4+IA1zdHJlYW0NCkiJjFZNb9s4EL3n V8xpIQKxVtSHJR2bFIumaNBF7J6aPSi2W7NVRK8sJ2h/fYfzhoma3UMuJmc4 bz4fKa/fn1VlWpfLmjJavz3L0iyzltabsLPVktaPZ5+TvjNVMtLN1ery3Pyz fn+2iKCFTW1dFBFaKbK1NZBXhg2TC1OlRXJNN7KujE3z5M9llmV0m4jB32Zh c1b6R5NnaZXsTJM2yfjb2aWAb40oyQ106GZWk9uIdOrn2nPyA6nPPfthldrt aY8gBNnjdCGwve+3R1MziOAtxpqAGabgF9VA89VYcW5yFgCdZD+vBM7nsAFR 4fze5AHhBnWWmvBLa2OrkLCmr3lpJlrM4P49aTn/4/gOQo+jLbFYcApT7IDK QWojcnLIGcpoopmp5U64UFXMFKbAE3+qEiywWan8Gblky8m0PMbJcev8F6WR Yl/QqFQG2qZq4eFolukyOR12XH2bjAvIG5E6+e25W3E/mkKGNnpYAAUMfnnc OS8jJAJs2JJTxQkrgFsYB85B8WBsJrN9DvbD5CXXSHv3FYd7gBaHudUXY2u2 itF54s9JD1DOM35NBTT5LRxoCqkJ4emv0at7sm3TLNosMF68PhrbMrSb+SQt yUkXoXOTUFG8aeKAIKUTEuinWDoOJ/FAUwz2iX0VsTj38ESZ5fzJyVsMPOfZ Y+A7hoV7E1BHF2LkwducOMv/vj9loX5srn4uwxWwSe+kgiLx4+CgIsOULpOL nUjjd6Z2gn3PUeNeiiu0ZzrVMnE9TsMzoFs4fXj2QhqR71Hi5W6z7uriOqWV GzZiooa2bS3hmWthrtCUPnIbqkRy6/3d9qcA3DetYI/1KL3Cg8Z2W5IscDY6 f9JzxPQDxFOP8Vq8cTawX3pb8unTfV7IByGPXa31Onabji+FEPPeWCHLhg7Q eCxH5kEROKTyMFen9G4XWhpa23G3a9bLXGPwF3ON/MiqokEGGy6iDsVwHZ3s +VHGRCevm9Vp0N21gz345I9KpyO/S2V41MPZffhM1KpT3IewhGc0GNz5EZvJ BEM/OgCP52r9xtiGlzVAfzD/nwS6gG3f02t9vnNaGFJn5oUXxNGNWmDpZnX9 ZvjqOCvXu9hNWsXOvGgKXQ2wSQ1TogyckZ5vGY4rzQ0oZ5zJ48Aa/ScQiBK+ YzsmQiMuLz124wFrqldbPD0T4JcAAwC9Xf3eDWVuZHN0cmVhbQ1lbmRvYmoN MzEgMCBvYmoNOTM3IA1lbmRvYmoNMzIgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAzMSAwIFIgPj4gDXN0cmVhbQ0KSIlsVUtvnDAQ vu+v8NE+gLCBBY5pokitqrZSkkpVlQP7aNYpwSvWJGp/fefFwqo5rLHHM998 8/DsKkuzrHTqfruCnStqdf+2+qnfjMvSSh9MYtNS702jB1OkDe2UsXma68Ni L+otSE6mgp3Ij2zl+y3ceAMCVOnktj3D4rX48hFxURBBXzR/GVunTgdWYRu5 iksePe6FjHoy1grlfo4AnUYfehUEVOHdi3G53uBut4M1tXqnuiAISBwJKbTt d4qUz1YXpP4YVyKmBB7QbH/OCq8XBixK1bUpQTYur+aM97GbgDlaL1lGQju2 eZ25vuNGxaDuvoK80F/M4/2nVZmnmc1zlan7G6x85uqpByrHPfAD4NcABBHf js8+nkayTCZTgLcVfAWgtAxgs6JhgM/GlpTxGtZNQCa1nKJxmB4W+T3JkPZa p8aCSH0D9g7KwBpcKwt5whhy/RuDrXUXNru/ZOufGVcd2gWWIsK2SKHBKdAE ieYSqXWVZaLttsUsZtjqL8YWkMVkDSXPMMMIAQjrOVXFFKltJFXHY/B9hHbg hqtSrJl6M7YBFj4eFHYpStUDpBT61CQOb6BoGcTBd4PJYX8CBbSBghcQMbVp hZvrlrQ6L4Iw9J5Fij9QJ8Hj8+DDyGiT3BtLuWEPvn9iMdjXEG1FtcJ1x/Sg LFpi8tulp3fDZdjUEOIVhy7uOYkJiLL6sm1stuYM3o7dZvBEiMaOg088TxFK AnniBJWyBlYc5pGEGuehBA5LCmmykpuO9ba0Rmq4cZB0nGdXu7hdzJqFg7Hn Ak7MBnYCmd3/79P3srkLIzQE76+YImWynlCgDSpOeC0kMKnA62OvbNNYNbFg /CPngGX9lLnoL0AVuMcnlcMMETejYnBomw+hmyLxLJRCSwQioxrx9HBpXSwe RDk9/bLkcnoanU4forzkil6y09zO+JdSpzSp6Ed1dHqQAUPoiz6hZ+saGVCV k/kCbdpQm2ZA9XXfmaTEd8HSI388C3s+PdETU/zeyRafO41NUtsSlBLbwSQ5 /+vMtkMrFicDrApI7IUDdQeTg4cvHkf+RNY5iA5UHZ+XAO2HyXmbojEM+Rux G95lT0ly+WUFcknOuqw4OdAp66SpsVlwcqrY0nfEwmBZtnQMIzVtrVmL99gs cbK7850XXejghNr2O/LkwW5117EmDSz8x07krQxBnM0iwZTzA3UXtWxBs9AK DWgVoSJzcIbl/pnP10LCi5yn4uM/AQYA+E8Kxg1lbmRzdHJlYW0NZW5kb2Jq DTMzIDAgb2JqDTk5OCANZW5kb2JqDTM0IDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMzMgMCBSID4+IA1zdHJlYW0NCkiJjFZLb9s4 EL7nV/BILiJBJCU/jt3UbRN00QJ2dw9FD35tza0qGhLdbPvrOy8qioECPcQi 5/HNcOYbMpuHm8L5clGrwpZ27r3avLypyqpq1GaPC2vnavN481H/aZrS66NZ lAvdm7qc6y/GWviwqDUOfnn93bhGq9X/rE8s7AYzLxsdYqe2LDioNyBy4vRo XAX6KU5KBQV6bwrrwJD99vQrwbeTfA6lypYsiP8au9ClekdhxKONu8MP8gr/ sbc6xfbA2SnyCJTDt+nx1AfCKA2K1uXtrw1XFwl+ZoEcFhID4a2KndiBwENB HyguG53FNuvGOsn+2ndjbDNGCFLAZ/GypSDnViQ57STOchLnaD5tHm4aX1YL VWVC1JkRrmmYEeEzHtzpU1IxnRDaU+EdVmuGdSKcgoGu+OWWmWB+wXCQ44zp gh/IURnIpoZ+4/5iCo+d7rO6BZY5SFusziI/hO6zWZYzaDsr3rBCdmFQHEa9 YnnbxkdoJagU0qVBxPvVaiVmUBSx/4rlxS7jTjY7ToplPZBhNkF5wbDP/Ngm 8JEkAmNk82GIrA2mGm0STs0IjLWmlD504RuddQo+hJQrg9NQU1NQkf3ZGOL0 Q6lydQaBeMJb6AEmHsrCZHBl7WbzCR187p+ruX+QIrMA+o8fqw+mcFjzFPuw JUkrjBC0K074GWO6xlvG3MUtMLXW/SGzAU8xwzpjLFSph3jpOzZr1aj+2xRz +L41UIFar+/VGulaQTWo4FaLBwx0zZXyYN4bmrM96Rh/GJBR5KnYBzhBDNkw NvuIirEH3jHM2Lxf5AXdwtBD4njAF0xpeArGiwF6YnMK6txHSarfTt0Ux4yc hwjlE5KEkMKJ+Eh3gWx27MgyPpl6VnLs3+YPbpdQAFooFLjvKILV3BBLZ+dV q9axDYdinUTDhuou9HtaXQJM/F3sKJjXgmPyiirLJbUiKk2lkcCEQ0O80AzO xQPpa5YKhGDmhO5OvArAARDLOX2mFrhbn07SIM8Vsvoch3CRNdzmkHJWXNJT 0vkqfcEJoCikk1gepTZ8mNtsS9RYSjpPB3Uj2HXCPJlAixnPZUFdkYvVLnGF XdkmUxB35HsCuIqmnIeRAK5GMd/2ts63PfWWrvhuS1/uLa5a6RtyZvoM8LrD W8DRs+1FNNbN4dt0Sc/ejpd0E7EI3il6ZL2Wt0bA4B3tRcIpdOHHBF+QouSk XFVZ9VfYT5QRJmiaEkbCv8gB+t9KIzfmH7hZR88vbII+p3ievrF+8sbyAKNh zyqpRtZjbnXGFJ18aI4nxRQP0R6naDv2PxKYVCX/M5GLI/tkPv0UYAButVId DWVuZHN0cmVhbQ1lbmRvYmoNMzUgMCBvYmoNMzkyIA1lbmRvYmoNMzYgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNSAwIFIgPj4g DXN0cmVhbQ0KSIl0UsFOwzAMvfcrcoylNUrSpt2OCCbBxG2FC+IwtokGSlut KYi/x4nT0SFxSeKX954dO9UmMaUomGTVTSKFlEXJqn2C4VfC6yNUb0kaCKkS qsyyiWZMoAlplPbcJ34HRmjeAhI1d0dYiYyf5tguQM52LZ0aBioTOd9+gzbC 8A/QGcJ9N8CS2zGGkdS18fB4D6pAfEv5IloRSFn3Ya3bruleQWlkxQwC9K/k FkpRRkWEairM549IP7401sc1EQ+s+yTL+QOZ0pL1JO7nF8GJ8PbA5vaxMAv+ jReW7T8ppGS2jTfWTeW42Mt3urhMGArvyMAxaktHwxjhucLR5yLzQz1PXxfT WHNFYz0NRyiwEwO6KI4lMIe98OJ0Uv/5GnnwSP1RZWTygBZLvgWJ6xVoiU4L UL7x6/EEuS8L+7bENAuG8zV42IXQYb4owP+gESEaiew+BESNhpE9QqpxG3DI ijvQZw2RGxtF7BrRFa+JbluCGW3Ywk0woLCPqAjPX1fJjwADABmJu4cNZW5k c3RyZWFtDWVuZG9iag0zNyAwIG9iag08PCAvTGVuZ3RoIDIxIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+v//P8MoGAUjFQAEGAD3ewL+ CmVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDcgL0hlaWdodCAzMyAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOSAwIFIgL0xlbmd0aCAyMTMg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInk1tEOgzAIBVD4 /59eolQK3KndAB/kZU1TewZtUKI3BDP3Uh0e82b1SKiELP9ABnMsTXoJlC+f 2kq3J1ZM7cVDVjYlEsrLb4ByvjPpJAJ5/UydSfNPUVbmnIKVSalgBn9TJ5J9 9ljqKQ1ampzunXaLI8FUykpgmJvV2LQ4K7VYTs1LGdQDN9DewSAlNyatIehM uZRasqSuBy519inQJH2bDHkFaZW69xaGUgFFckahxgXU6BTxGMdauAHc9EIa F70lGinqk6jjG7o+PgIMAJFFBXwKZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDk4 MCAvSGVpZ2h0IDIwMiAvQml0c1BlckNvbXBvbmVudCAxIA0vSW1hZ2VNYXNr IHRydWUgL0xlbmd0aCA2NzIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0Rl Y29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1bW5zIDk4MCA+PiA+PiANc3RyZWFt DQoyUkXRXClMwMErRdHYgGtOGCBEM+xyCtIedqatZSwKCaBoclIaCVgX9Age +GF8koHk0712gg/p+5CkCDa3+1EP6/3W/2mG+1/trf7TINZd11/ZBQKN5BaH /2pDOWupDPt7X9kHVG9Nf2oQecdYtf2E2x7/aaeuv9Nvtfaaev+L79ffHf/4 /H//9f//C/wv8JfzITRHDUkY8gn8ygDzi/52aAeLHfO1sDw/IHs3HwXkDxDZ LwguHwvB8JcPoLvoLvwpBlH30FHfkDxdpW+iB/J/5DMcw5XFeVJOQzlmQz8V xVRUyofRAvIET0VINHgsf8L3/7+vv///f5M/1+vv20//d+vsLf9sImO/a8ME L8L2GC526/shljb117INQgod4TyCAo7EccfDfX+uG+uGQPCR67BD1wYLrZ2a AUVU+ggwYK4VsygG1UQPCGyWZFYNASQKZKaMIjsyFkeRmiFOTHINQ5BQ5jey bieIiMf//lmmq3/uvp+v36f9P+n/6dd/13679d+nLMC0iGrJLLMLAKJZgmB4 JLMAgPDMI/LMGZH0QPDbkGWYGHkDwJ5DlmUBeQyFtYLOZj5DIB9lZZyUMXIZ AF9jZZ1INmyGQGnsQWcoQV5DIBl3xZxoL8hkAVjlLZZ1YEPchkmOcK72QyQ0 CZZ6Ce8hkg0KCzwGG35DJBtDLQlIjhs+2DoX3yGSDUXLQaBo95DJDYNlnOI7 3IZIQsLPVX7IZAMw51QXvkMgDc0LONgm3IZAbe6FnKC+QyAatiBfZDIDPsbL OsBn5DIE2VlnMgS5DIW1Msz55A8DfZmLsgeDbKhZhcJIHg0SEFmAXIHhnkNC GQPGOVIoLMBANxlmKgaZHVkMtfKtf6v9X9r++r/V/q/tf2v9X99e8AEAEApl bmRzdHJlYW0NZW5kb2JqDTQwIDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRl IA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiANZW5k b2JqDTEgMCBvYmoNPDwgDS9Db3VudCA3IA0vRmlyc3QgMiAwIFIgDS9MYXN0 IDMgMCBSIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9UaXRsZSAoRlJFTkNI IElFRUUtQ0FTIENIQVBURVIpDS9EZXN0IFsgMTMgMCBSIC9GaXRCIF0gDS9Q YXJlbnQgMSAwIFIgDS9OZXh0IDMgMCBSIA0vRmlyc3QgNyAwIFIgDS9MYXN0 IDcgMCBSIA0vQ291bnQgMiANPj4gDWVuZG9iag0zIDAgb2JqDTw8IA0vVGl0 bGUgKDI5IE1heSAyMDAxKQ0vRGVzdCBbIDEzIDAgUiAvRml0QiBdIA0vUGFy ZW50IDEgMCBSIA0vUHJldiAyIDAgUiANL0ZpcnN0IDQgMCBSIA0vTGFzdCA0 IDAgUiANL0NvdW50IDMgDT4+IA1lbmRvYmoNNCAwIG9iag08PCANL1RpdGxl ICgpDS9EZXN0IFsgMTMgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMyAwIFIgDS9G aXJzdCA1IDAgUiANL0xhc3QgNSAwIFIgDS9Db3VudCAyIA0+PiANZW5kb2Jq DTUgMCBvYmoNPDwgDS9UaXRsZSAoKQ0vRGVzdCBbIDEzIDAgUiAvRml0QiBd IA0vUGFyZW50IDQgMCBSIA0vRmlyc3QgNiAwIFIgDS9MYXN0IDYgMCBSIA0v Q291bnQgMSANPj4gDWVuZG9iag02IDAgb2JqDTw8IA0vVGl0bGUgKExlY3R1 cmUgMjogVGltaW5nIEVsZW1lbnRzIGFuZCBUaW1pbmcgSXNzdWVzIGluIEhp Z2ggUGVyZm9ybWFuY2UgUHJvY2Vzc1wNb3JzKQ0vRGVzdCBbIDEzIDAgUiAv Rml0QiBdIA0vUGFyZW50IDUgMCBSIA0+PiANZW5kb2JqDTcgMCBvYmoNPDwg DS9UaXRsZSAoKQ0vRGVzdCBbIDEzIDAgUiAvRml0QiBdIA0vUGFyZW50IDIg MCBSIA0vRmlyc3QgOCAwIFIgDS9MYXN0IDggMCBSIA0vQ291bnQgMSANPj4g DWVuZG9iag04IDAgb2JqDTw8IA0vVGl0bGUgKFNwb25zb3JlZCBieSB0aGUg Q0FTIFNvY2lldHkgdW5kZXIgaXRzIERpc3Rpbmd1aXNoZWQgTGVjdHVyZXIg UHJvZ3JhbSkNL0Rlc3QgWyAxMyAwIFIgL0ZpdEIgXSANL1BhcmVudCA3IDAg UiANPj4gDWVuZG9iag05IDAgb2JqDTw8IA0vUHJvZHVjZXIgKEFjcm9iYXQg RGlzdGlsbGVyIDQuMCBmb3IgV2luZG93cykNL0NyZWF0b3IgKCkNL01vZERh dGUgKEQ6MjAwMTA0MjcxMDEwMjErMDInMDAnKQ0vVGl0bGUgKFxuKQ0vQ3Jl YXRpb25EYXRlIChEOjIwMDEwNDI3MTAwOTU5KQ0+PiANZW5kb2JqDTEwIDAg b2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMTMgMCBSIF0gDS9Db3Vu dCAxIA0+PiANZW5kb2JqDXhyZWYNMCAxMSANMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDEyNjQ5IDAwMDAwIG4NCjAwMDAwMTI3MDkgMDAwMDAgbg0KMDAw MDAxMjg1NCAwMDAwMCBuDQowMDAwMDEyOTg3IDAwMDAwIG4NCjAwMDAwMTMw OTYgMDAwMDAgbg0KMDAwMDAxMzIwNSAwMDAwMCBuDQowMDAwMDEzMzU0IDAw MDAwIG4NCjAwMDAwMTM0NjMgMDAwMDAgbg0KMDAwMDAxMzYwNCAwMDAwMCBu DQowMDAwMDEzNzY1IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMTENL0lE Wzw0MWMzYmEwMTVhYzIwMmU5OTkzMjk1YTI1OTFmMjc3MT48NDFjM2JhMDE1 YWMyMDJlOTk5MzI5NWEyNTkxZjI3NzE+XQ0+Pg1zdGFydHhyZWYNMTczDSUl RU9GDQ== ------=_NextPart_988970295_1841070896003658-- From Fri May 4 12:03:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA01996 for ; Sat, 5 May 2001 00:47:13 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:47:13 +0200 (MEST) Received: (qmail 9765 invoked by uid 0); 4 May 2001 10:02:06 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx14) with SMTP; 4 May 2001 10:02:06 -0000 X-eGroups-Return: sentto-1101623-2741-988970523-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by jk.egroups.com with NNFMP; 04 May 2001 10:02:04 -0000 X-Sender: nicolas.boulay@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 10:02:03 -0000 Received: (qmail 85387 invoked from network); 4 May 2001 10:02:03 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 May 2001 10:02:03 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta2 with SMTP; 4 May 2001 10:02:03 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Fri, 4 May 2001 10:03:47 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105041003.2f48@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 4 May 2001 10:03:47 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www-frec.bull.com/servers/index.htm

nicO


______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carlos De Urresti Hannoh Fri May 4 16:19:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02093 for ; Sat, 5 May 2001 00:47:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:47:41 +0200 (MEST) Received: (qmail 30216 invoked by uid 0); 4 May 2001 14:31:13 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx007-rz3) with SMTP; 4 May 2001 14:31:13 -0000 X-eGroups-Return: sentto-1101623-2742-988985973-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by cj.egroups.com with NNFMP; 04 May 2001 14:19:34 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 14:19:32 -0000 Received: (qmail 55330 invoked from network); 4 May 2001 14:19:09 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 4 May 2001 14:19:09 -0000 Received: from unknown (HELO mx0.gmx.net) (213.165.64.100) by mta3 with SMTP; 4 May 2001 14:19:08 -0000 Received: (qmail 23959 invoked by uid 0); 4 May 2001 14:19:07 -0000 To: f-cpu@yahoogroups.com Cc: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> X-Priority: 3 (Normal) X-Authenticated-Sender: #0006153040@gmx.net X-Authenticated-IP: [200.57.128.65] Message-ID: <11346.988985947@www46.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) From: Carlos De Urresti Hannoh MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 4 May 2001 16:19:07 +0200 (MEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > hello everybody,
>
> were present Lionel, nicO, Nicole and myself,
> we discussed during some hours.
>
> I have got some informations and data about
> the Celaro machines but give me some weeks to find
> a deal with the company (i'm a R&D guy, i have never
> dealt with the ones with ties ... so be patient)
>
> There are a few possibilities :
>  - refurbished or R&D HW/protos
>  - single-slot Celaro (around 20-40K gates)
>  - old SimExpress (a bit larger, maybe cheaper,
>       but not supported anymore)
>  - stripped-down Celaro (24-slot capable, but
>     populated with a minimum of boards to decrease
>     the price, since each logic board costs a huge
>     amount of $$$$)
>  - competitors
>
> I have not yet done much things. However the single-slot solution
> could maybe be affordable and we'll go larger later. SS is usually
> used for demonstrations is is capable of running the same SW as
> the larger ones, with the possibility of connecting it to external
> devices, so we can plug that to an existing device. It is already
> certainly capable of verifying the IMU for example, i guess it can
> reach 6MHz of real clock. Plus it works on a normal wall plug for
> its electricity.
>
> But that is for the Phase 1.
>
> Phase 0 will be to find a location, a network, a legal and official
> arrangement for the costs (electricity, climatisation...), putting
This might help a little bit :) I work on the first IDC (Internet Data
Center) in LatinAmerica. Giving a brief resume of the capabilities out of it are:
(pretty fancy)
Area of the Site: More than 7,000 km^2.
Aprox 1.2 Gbit :) uplink without the emergency link. (And we can buy only
the needed bandwith since if we choose here it most be at the collocation
area).
6 Electric Generators (Each one backing up all the site) + normal elect.
climatisation = less than 20 C (brrrrrr :>) just don't walk up the holes
were the air runs under -5 C :/
etc etc
> a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
> the account management, the job queue...
First off: I'm a Solaris user :> but situations make you change.
This company is 85% Telmex(Huge Monopolic Telco) and 15% HP so we might get
a good price over a new HP machine if we sign the arrangement.
The good hint about this is that all the parts that would fail or broke
would be replaced by me:) and I can be pretty alert over the equipments; of
course if the equipment is new we get all the warranties : ) and this a cron if we
buy refurbished machines :/ we couldn't apply for them and in the long term
this could hit us really bad :/

If you want me to start looking for prices just pass me down a line.
>
> At that stage we can already put some other SW such as physical synthesis
> etc.
>
>
> Phase 2 would be the larger scale emulation. 12 Celaro slots should
> work for a mid-scale design (ie FC0).
>
> Phase 3 would be a prototype tape-out...
>
> But before we do that, we all have a lot of work.
> Lionel (trollhunter) is preparing the who'swho database, which will
> also serve as a task management tool. Not only we will know who did
> what, but also what projects are going on and what project needs help.
>
> More than that has happened, but i have to sleep now.
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: nicolas.boulay at ifrance dot com
Subject: Re: [f-cpu] Which machine to use ?
>
> Where i work i try to puch to use linux on the eda
> tools. Most of the main Synopsys tools work under
> Linux. So a big beast as Athlon 1.3 with 2Go of Ram
> will be great (and not so expensive) and enought for
> the beginning. (Nvidia use 600 'Linux box'). If the
> project became bigger, we could just add more PC.
>
> Count the number of time that the word Linux is
> written on this page :
> http://www.synopsys.com/products/sw_platform.html
>
> And cf :
> http://www.synopsys.com/news/announce/press2000/linux
> _pr.html
>
> And i try to prove that PC are faster than
> ultraSparc. I think that Sun Blade 1000 are faster
> but at 14000 $(for only 1 Go of memory) it could be !
8 MB of cache :) May I see that Xeon? :P
> ( cf
> http://store.sun.com/webconfig/BuildConfig.jhtml;$ses
> sionid$HF53H5YAAAJEHAMTA1ESRUT5AAAACJ1K )
>
> So PC is the best choice. Maybe gays from PlaceNet
> could accept to host the PC ? We should ask them.
> (it's an 'association' that want to create adsl
> access for free software user)
>
> nicO
>
> -----Message d'origine-----
> De: Yann Guidon <whygee@f-cpu.org>
> A: fm <f-cpu@yahoogroups.com>
> Date: 02/05/01
> Objet: [f-cpu] back from Dortmund
>
> Hello everybody,
>
> Graham, Lionel and I were in Dortmund.
> We made the conferences and discussed a lot.
>
> We consider to setup a web server for online
> digital design. Loaded with necessary sofware,
> accessed through ssh and running batch queues
> for the heavy tasks (ie : compiling large designs),
> it will equiped with an external emulator for
> simulation acceleration.
>
> More than two years ago, we tried to see if we could
> put a PC on the net, connected to a FPGA board. It
> appears impossible for practical reasons but i have
> learnt
> a lot about emulators, they solve all the problems.
>
> Now, it's only the beginning of a new "project"
> because
> we need to federate other Free HW projects, in order
> to
For a starting place of the Free HW website I could offer a 256 k/bit
line(not a lot.. but for starting web server is more than enough. At least I think
so. But not enough hardware :/ unless I run the web server on a P200 with 72
MB RAM.
> get sufficient sponsoring, for the server, the
> emulator
> and everything around (Net connexion, electric power,
> climatised room, sysadmin, compiler, everything
> else...)
>
> This is going to be a large endeavour, and as the
> enclosed
> file (that will be published on the f-cpu site)
> shows, there
> is already a lot to do for the f-cpu project alone.
>
> If you have a spare UltraSparc somewhere, tell us ;-)
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
> 
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
> 
> _____________________________________________________
> _________________________
> ifrance.com, l'email gratuit le plus complet de
> l'Internet !
> vos emails depuis un navigateur, en POP3, sur
> Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
> 
>
______________________________________________________________________________
> ifrance.com, l'email gratuit le plus complet de l'Internet !
> vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: boucli27 at altavista dot net
Subject: Re: [f-cpu] Which machine to use
> Well, it seems that some of the software that will be
> run are solaris SPARC only binaries; thus we will have
> to go for Sun | Tatung | Fujitsu hardware.
>
> The problem with the *Blade series is that first you pay
> a premium price, second they are still not reliable :
> a lot of them are DOA ( dead on arrival ), thus I think
> it should be wyser to stick to 'old' USII based servers.
Blade are doing fine now; no more than a week for delivery
>
> It seems an Enterprise 4xx will do the job. We could spare a lot of money
> if we buy some refurbished hardware.
>
> This kind of Hardware is sold directly by Sun or one of its subsidiaries.
> http://www.sun.com/ibb/remanufactured/availability/workgroupservers.html
>
> If we wait until October we will have a lot of bang for the bucks.
>
> I think we may have a premium class server for ~$15.000 --> $20.000 thus
> we will have to launch a subscribtion
> in order to get one of theses babies.
>
> I think I will be able to find $1.000 for this project.
>
> Who's next ?
>
May I? :)
I can give $750.
> Cheers,
> Lionel
> #########################################
>
> Lionel, trollhunter Bouchpan-Lerust-Juery
> trollhunter@linuxfr.org
> boucli27@altavista.net
>
http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html
> http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html
> 06 68 99 65 89
> ----------------------------------------------------------------
> Get your free email from AltaVista at http://altavista.iname.com
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Carlos De Urresti Hannoh Fri May 4 16:19:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02120 for ; Sat, 5 May 2001 00:47:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:47:49 +0200 (MEST) Received: (qmail 16099 invoked by uid 0); 4 May 2001 15:28:01 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx05) with SMTP; 4 May 2001 15:28:01 -0000 X-eGroups-Return: sentto-1101623-2743-988985974-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ml.egroups.com with NNFMP; 04 May 2001 14:19:35 -0000 X-Sender: lphalt@gmx.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 14:19:33 -0000 Received: (qmail 72478 invoked from network); 4 May 2001 14:19:09 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 4 May 2001 14:19:09 -0000 Received: from unknown (HELO mx0.gmx.net) (213.165.64.100) by mta1 with SMTP; 4 May 2001 14:19:08 -0000 Received: (qmail 23959 invoked by uid 0); 4 May 2001 14:19:07 -0000 To: f-cpu@yahoogroups.com Cc: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> X-Priority: 3 (Normal) X-Authenticated-Sender: #0006153040@gmx.net X-Authenticated-IP: [200.57.128.65] Message-ID: <11346.988985947@www46.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) From: Carlos De Urresti Hannoh MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 4 May 2001 16:19:07 +0200 (MEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > hello everybody,
>
> were present Lionel, nicO, Nicole and myself,
> we discussed during some hours.
>
> I have got some informations and data about
> the Celaro machines but give me some weeks to find
> a deal with the company (i'm a R&D guy, i have never
> dealt with the ones with ties ... so be patient)
>
> There are a few possibilities :
>  - refurbished or R&D HW/protos
>  - single-slot Celaro (around 20-40K gates)
>  - old SimExpress (a bit larger, maybe cheaper,
>       but not supported anymore)
>  - stripped-down Celaro (24-slot capable, but
>     populated with a minimum of boards to decrease
>     the price, since each logic board costs a huge
>     amount of $$$$)
>  - competitors
>
> I have not yet done much things. However the single-slot solution
> could maybe be affordable and we'll go larger later. SS is usually
> used for demonstrations is is capable of running the same SW as
> the larger ones, with the possibility of connecting it to external
> devices, so we can plug that to an existing device. It is already
> certainly capable of verifying the IMU for example, i guess it can
> reach 6MHz of real clock. Plus it works on a normal wall plug for
> its electricity.
>
> But that is for the Phase 1.
>
> Phase 0 will be to find a location, a network, a legal and official
> arrangement for the costs (electricity, climatisation...), putting
This might help a little bit :) I work on the first IDC (Internet Data
Center) in LatinAmerica. Giving a brief resume of the capabilities out of it are:
(pretty fancy)
Area of the Site: More than 7,000 km^2.
Aprox 1.2 Gbit :) uplink without the emergency link. (And we can buy only
the needed bandwith since if we choose here it most be at the collocation
area).
6 Electric Generators (Each one backing up all the site) + normal elect.
climatisation = less than 20 C (brrrrrr :>) just don't walk up the holes
were the air runs under -5 C :/
etc etc
> a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
> the account management, the job queue...
First off: I'm a Solaris user :> but situations make you change.
This company is 85% Telmex(Huge Monopolic Telco) and 15% HP so we might get
a good price over a new HP machine if we sign the arrangement.
The good hint about this is that all the parts that would fail or broke
would be replaced by me:) and I can be pretty alert over the equipments; of
course if the equipment is new we get all the warranties : ) and this a cron if we
buy refurbished machines :/ we couldn't apply for them and in the long term
this could hit us really bad :/

If you want me to start looking for prices just pass me down a line.
>
> At that stage we can already put some other SW such as physical synthesis
> etc.
>
>
> Phase 2 would be the larger scale emulation. 12 Celaro slots should
> work for a mid-scale design (ie FC0).
>
> Phase 3 would be a prototype tape-out...
>
> But before we do that, we all have a lot of work.
> Lionel (trollhunter) is preparing the who'swho database, which will
> also serve as a task management tool. Not only we will know who did
> what, but also what projects are going on and what project needs help.
>
> More than that has happened, but i have to sleep now.
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: nicolas.boulay at ifrance dot com
Subject: Re: [f-cpu] Which machine to use ?
>
> Where i work i try to puch to use linux on the eda
> tools. Most of the main Synopsys tools work under
> Linux. So a big beast as Athlon 1.3 with 2Go of Ram
> will be great (and not so expensive) and enought for
> the beginning. (Nvidia use 600 'Linux box'). If the
> project became bigger, we could just add more PC.
>
> Count the number of time that the word Linux is
> written on this page :
> http://www.synopsys.com/products/sw_platform.html
>
> And cf :
> http://www.synopsys.com/news/announce/press2000/linux
> _pr.html
>
> And i try to prove that PC are faster than
> ultraSparc. I think that Sun Blade 1000 are faster
> but at 14000 $(for only 1 Go of memory) it could be !
8 MB of cache :) May I see that Xeon? :P
> ( cf
> http://store.sun.com/webconfig/BuildConfig.jhtml;$ses
> sionid$HF53H5YAAAJEHAMTA1ESRUT5AAAACJ1K )
>
> So PC is the best choice. Maybe gays from PlaceNet
> could accept to host the PC ? We should ask them.
> (it's an 'association' that want to create adsl
> access for free software user)
>
> nicO
>
> -----Message d'origine-----
> De: Yann Guidon <whygee@f-cpu.org>
> A: fm <f-cpu@yahoogroups.com>
> Date: 02/05/01
> Objet: [f-cpu] back from Dortmund
>
> Hello everybody,
>
> Graham, Lionel and I were in Dortmund.
> We made the conferences and discussed a lot.
>
> We consider to setup a web server for online
> digital design. Loaded with necessary sofware,
> accessed through ssh and running batch queues
> for the heavy tasks (ie : compiling large designs),
> it will equiped with an external emulator for
> simulation acceleration.
>
> More than two years ago, we tried to see if we could
> put a PC on the net, connected to a FPGA board. It
> appears impossible for practical reasons but i have
> learnt
> a lot about emulators, they solve all the problems.
>
> Now, it's only the beginning of a new "project"
> because
> we need to federate other Free HW projects, in order
> to
For a starting place of the Free HW website I could offer a 256 k/bit
line(not a lot.. but for starting web server is more than enough. At least I think
so. But not enough hardware :/ unless I run the web server on a P200 with 72
MB RAM.
> get sufficient sponsoring, for the server, the
> emulator
> and everything around (Net connexion, electric power,
> climatised room, sysadmin, compiler, everything
> else...)
>
> This is going to be a large endeavour, and as the
> enclosed
> file (that will be published on the f-cpu site)
> shows, there
> is already a lot to do for the f-cpu project alone.
>
> If you have a spare UltraSparc somewhere, tell us ;-)
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
> 
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
> 
> _____________________________________________________
> _________________________
> ifrance.com, l'email gratuit le plus complet de
> l'Internet !
> vos emails depuis un navigateur, en POP3, sur
> Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
> 
>
______________________________________________________________________________
> ifrance.com, l'email gratuit le plus complet de l'Internet !
> vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: boucli27 at altavista dot net
Subject: Re: [f-cpu] Which machine to use
> Well, it seems that some of the software that will be
> run are solaris SPARC only binaries; thus we will have
> to go for Sun | Tatung | Fujitsu hardware.
>
> The problem with the *Blade series is that first you pay
> a premium price, second they are still not reliable :
> a lot of them are DOA ( dead on arrival ), thus I think
> it should be wyser to stick to 'old' USII based servers.
Blade are doing fine now; no more than a week for delivery
>
> It seems an Enterprise 4xx will do the job. We could spare a lot of money
> if we buy some refurbished hardware.
>
> This kind of Hardware is sold directly by Sun or one of its subsidiaries.
> http://www.sun.com/ibb/remanufactured/availability/workgroupservers.html
>
> If we wait until October we will have a lot of bang for the bucks.
>
> I think we may have a premium class server for ~$15.000 --> $20.000 thus
> we will have to launch a subscribtion
> in order to get one of theses babies.
>
> I think I will be able to find $1.000 for this project.
>
> Who's next ?
>
May I? :)
I can give $750.
> Cheers,
> Lionel
> #########################################
>
> Lionel, trollhunter Bouchpan-Lerust-Juery
> trollhunter@linuxfr.org
> boucli27@altavista.net
>
http://infonomade.linuxfr.org/wearables/doc/Wearable-HOWTO/en/Wearable-HOWTO.html
> http://www.linuxdoc.org/HOWTO/SPARC-HOWTO.html
> 06 68 99 65 89
> ----------------------------------------------------------------
> Get your free email from AltaVista at http://altavista.iname.com
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Alan Grimes Fri May 4 19:16:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02144 for ; Sat, 5 May 2001 00:47:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:47:57 +0200 (MEST) Received: (qmail 8778 invoked by uid 0); 4 May 2001 17:15:16 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx010-rz3) with SMTP; 4 May 2001 17:15:16 -0000 X-eGroups-Return: sentto-1101623-2744-988996508-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 04 May 2001 17:15:13 -0000 X-Sender: alangrimes@starpower.net X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 17:15:05 -0000 Received: (qmail 88369 invoked from network); 4 May 2001 17:14:53 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 May 2001 17:14:53 -0000 Received: from unknown (HELO smtp-hub.mrf.mail.rcn.net) (207.172.4.107) by mta2 with SMTP; 4 May 2001 17:14:53 -0000 Received: from smtp03.mrf.mail.rcn.net ([207.172.4.62]) by smtp-hub.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14vjAK-0004N5-00 for f-cpu@yahoogroups.com; Fri, 04 May 2001 13:14:52 -0400 Received: from 66-44-58-151.s151.tnt3.lnhva.md.dialup.rcn.com ([66.44.58.151] helo=starpower.net) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14vjAJ-0001yY-00 ; Fri, 04 May 2001 13:14:52 -0400 Message-ID: <3AF2E3DC.54C670A5@starpower.net> X-Mailer: Mozilla 4.08 [en] (Win16; U) To: f-cpu@yahoogroups.com, cores@opencores.org From: Alan Grimes MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 04 May 2001 13:16:12 -0400 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] RFR: FPGA Programming: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N This is a request for refferences.

Hey, I'm needing a good book on concepts and techniques for FPGA
programming. Any reccomendations?

--
Cybernetic Intelligence: The gateway to the future! =)
http://users.erols.com/alangrimes/  <my website.
Any usage of this e-mail account is subject to the terms and conditions
specified on my website.
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Fri May 4 22:12:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA02183 for ; Sat, 5 May 2001 00:48:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 00:48:09 +0200 (MEST) Received: (qmail 26467 invoked by uid 0); 4 May 2001 20:15:05 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx05) with SMTP; 4 May 2001 20:15:05 -0000 X-eGroups-Return: sentto-1101623-2745-989007150-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mo.egroups.com with NNFMP; 04 May 2001 20:12:31 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 20:12:29 -0000 Received: (qmail 51970 invoked from network); 4 May 2001 20:12:20 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 20:12:20 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.224.224) by mta1 with SMTP; 4 May 2001 20:12:19 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C31819E64 for ; Fri, 4 May 2001 22:12:01 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF30D11.2A72E43@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 04 May 2001 22:12:01 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N http://www.cs.man.ac.uk/async/index.html

I think that asynchronous trick could be used. Micropipeline could be a
great thing. And we can avoid the critical insertion of the clock tree
(and all the associated skew problem).

Maybe a mixed design could be used.

nicO
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 00:39:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03085 for ; Sat, 5 May 2001 04:25:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 04:25:56 +0200 (MEST) Received: (qmail 7564 invoked by uid 0); 4 May 2001 22:41:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx07) with SMTP; 4 May 2001 22:41:15 -0000 X-eGroups-Return: sentto-1101623-2747-989016070-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 May 2001 22:41:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:41:09 -0000 Received: (qmail 58479 invoked from network); 4 May 2001 22:41:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 22:41:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 4 May 2001 22:41:08 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03826 for ; Sat, 5 May 2001 00:40:55 +0200 (MET DST) Message-ID: <3AF32F9C.C35544E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:39:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
>  http://www.cs.man.ac.uk/async/index.html
sorry, no time yet to check...

> I think that asynchronous trick could be used. Micropipeline could be a
> great thing. And we can avoid the critical insertion of the clock tree
> (and all the associated skew problem).
>
> Maybe a mixed design could be used.

I don't think that it is critical at our level.
the ISA and architecture are not concerned by the clocking issue.

On top of that, discussions on comp.arch and with Andy Glew (Intel)
showed that no tool can do automatic asynch clocking designs, and i know
that you're a fervent silicon synthesis fan. so if you want asynch,
you'll have to do it all by yourself :-)

well, today the problem is still to design the VHDL model.

i d/l the DSP files that you pointed to, btw.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 00:59:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03088 for ; Sat, 5 May 2001 04:25:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 04:25:56 +0200 (MEST) Received: (qmail 20920 invoked by uid 0); 4 May 2001 23:00:17 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx25) with SMTP; 4 May 2001 23:00:17 -0000 X-eGroups-Return: sentto-1101623-2748-989017167-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 04 May 2001 23:00:12 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:59:26 -0000 Received: (qmail 93078 invoked from network); 4 May 2001 22:59:26 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 4 May 2001 22:59:26 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta3 with SMTP; 4 May 2001 22:59:24 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D54B09E69 for ; Sat, 5 May 2001 00:59:06 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF3343A.82DB98E8@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> <3AF32F9C.C35544E9@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:59:06 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas wrote:
> >  http:/= /www.cs.man.ac.uk/async/index.html
> sorry, no time yet to check...
>
> > I think that asynchronous trick could be used. Micropipeline coul= d be a
> > great thing. And we can avoid the critical insertion of the clock= tree
> > (and all the associated skew problem).
> >
> > Maybe a mixed design could be used.
>
> I don't think that it is critical at our level.
> the ISA and architecture are not concerned by the clocking issue.
>
> On top of that, discussions on comp.arch and with Andy Glew (Intel) > showed that no tool can do automatic asynch clocking designs, and i kn= ow

http://www.cs.ma= n.ac.uk/async/tools/index.html ;p

But i better prefer VHDL, it's clear ! I try to find a way to replace
clk by request and acknoledge, if i could...

> that you're a fervent silicon synthesis fan. so if you want asynch, > you'll have to do it all by yourself :-)
>
> well, today the problem is still to design the VHDL model.
>
> i d/l the DSP files that you pointed to, btw.
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 01:14:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA03097 for ; Sat, 5 May 2001 04:25:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 04:25:58 +0200 (MEST) Received: (qmail 7825 invoked by uid 0); 4 May 2001 23:14:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx01) with SMTP; 4 May 2001 23:14:40 -0000 X-eGroups-Return: sentto-1101623-2749-989018061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 04 May 2001 23:14:22 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 23:14:19 -0000 Received: (qmail 23305 invoked from network); 4 May 2001 23:14:19 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 May 2001 23:14:19 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta2 with SMTP; 4 May 2001 23:14:19 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id AF3019E69 for ; Sat, 5 May 2001 01:14:01 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF337B9.CE8F5E52@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AEF5EBA.A9C01B52@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 01:14:01 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] back from Dortmund Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :

> - check TRIMARAN and other high performance compilers

Funny, it's the EPIC compiler, you know the grand brother of the...
merced ( or IA64 ).

No comment, Whygee ! ;p

http://www.trimaran.org/

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 00:39:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA03590 for ; Sat, 5 May 2001 07:26:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 07:26:03 +0200 (MEST) Received: (qmail 7564 invoked by uid 0); 4 May 2001 22:41:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx07) with SMTP; 4 May 2001 22:41:15 -0000 X-eGroups-Return: sentto-1101623-2747-989016070-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 May 2001 22:41:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:41:09 -0000 Received: (qmail 58479 invoked from network); 4 May 2001 22:41:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 22:41:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 4 May 2001 22:41:08 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03826 for ; Sat, 5 May 2001 00:40:55 +0200 (MET DST) Message-ID: <3AF32F9C.C35544E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:39:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
>  http://www.cs.man.ac.uk/async/index.html
sorry, no time yet to check...

> I think that asynchronous trick could be used. Micropipeline could be a
> great thing. And we can avoid the critical insertion of the clock tree
> (and all the associated skew problem).
>
> Maybe a mixed design could be used.

I don't think that it is critical at our level.
the ISA and architecture are not concerned by the clocking issue.

On top of that, discussions on comp.arch and with Andy Glew (Intel)
showed that no tool can do automatic asynch clocking designs, and i know
that you're a fervent silicon synthesis fan. so if you want asynch,
you'll have to do it all by yourself :-)

well, today the problem is still to design the VHDL model.

i d/l the DSP files that you pointed to, btw.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 00:39:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03834 for ; Sat, 5 May 2001 08:26:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:26:13 +0200 (MEST) Received: (qmail 7564 invoked by uid 0); 4 May 2001 22:41:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx07) with SMTP; 4 May 2001 22:41:15 -0000 X-eGroups-Return: sentto-1101623-2747-989016070-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 May 2001 22:41:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:41:09 -0000 Received: (qmail 58479 invoked from network); 4 May 2001 22:41:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 22:41:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 4 May 2001 22:41:08 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03826 for ; Sat, 5 May 2001 00:40:55 +0200 (MET DST) Message-ID: <3AF32F9C.C35544E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:39:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
>  http://www.cs.man.ac.uk/async/index.html
sorry, no time yet to check...

> I think that asynchronous trick could be used. Micropipeline could be a
> great thing. And we can avoid the critical insertion of the clock tree
> (and all the associated skew problem).
>
> Maybe a mixed design could be used.

I don't think that it is critical at our level.
the ISA and architecture are not concerned by the clocking issue.

On top of that, discussions on comp.arch and with Andy Glew (Intel)
showed that no tool can do automatic asynch clocking designs, and i know
that you're a fervent silicon synthesis fan. so if you want asynch,
you'll have to do it all by yourself :-)

well, today the problem is still to design the VHDL model.

i d/l the DSP files that you pointed to, btw.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 00:59:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03837 for ; Sat, 5 May 2001 08:26:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:26:14 +0200 (MEST) Received: (qmail 20920 invoked by uid 0); 4 May 2001 23:00:17 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx25) with SMTP; 4 May 2001 23:00:17 -0000 X-eGroups-Return: sentto-1101623-2748-989017167-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 04 May 2001 23:00:12 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:59:26 -0000 Received: (qmail 93078 invoked from network); 4 May 2001 22:59:26 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 4 May 2001 22:59:26 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta3 with SMTP; 4 May 2001 22:59:24 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D54B09E69 for ; Sat, 5 May 2001 00:59:06 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF3343A.82DB98E8@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> <3AF32F9C.C35544E9@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:59:06 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas wrote:
> >  http:/= /www.cs.man.ac.uk/async/index.html
> sorry, no time yet to check...
>
> > I think that asynchronous trick could be used. Micropipeline coul= d be a
> > great thing. And we can avoid the critical insertion of the clock= tree
> > (and all the associated skew problem).
> >
> > Maybe a mixed design could be used.
>
> I don't think that it is critical at our level.
> the ISA and architecture are not concerned by the clocking issue.
>
> On top of that, discussions on comp.arch and with Andy Glew (Intel) > showed that no tool can do automatic asynch clocking designs, and i kn= ow

http://www.cs.ma= n.ac.uk/async/tools/index.html ;p

But i better prefer VHDL, it's clear ! I try to find a way to replace
clk by request and acknoledge, if i could...

> that you're a fervent silicon synthesis fan. so if you want asynch, > you'll have to do it all by yourself :-)
>
> well, today the problem is still to design the VHDL model.
>
> i d/l the DSP files that you pointed to, btw.
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 01:14:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03846 for ; Sat, 5 May 2001 08:26:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:26:16 +0200 (MEST) Received: (qmail 7825 invoked by uid 0); 4 May 2001 23:14:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx01) with SMTP; 4 May 2001 23:14:40 -0000 X-eGroups-Return: sentto-1101623-2749-989018061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 04 May 2001 23:14:22 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 23:14:19 -0000 Received: (qmail 23305 invoked from network); 4 May 2001 23:14:19 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 May 2001 23:14:19 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta2 with SMTP; 4 May 2001 23:14:19 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id AF3019E69 for ; Sat, 5 May 2001 01:14:01 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF337B9.CE8F5E52@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AEF5EBA.A9C01B52@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 01:14:01 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] back from Dortmund Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :

> - check TRIMARAN and other high performance compilers

Funny, it's the EPIC compiler, you know the grand brother of the...
merced ( or IA64 ).

No comment, Whygee ! ;p

http://www.trimaran.org/

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 02:05:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03852 for ; Sat, 5 May 2001 08:26:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:26:18 +0200 (MEST) Received: (qmail 2379 invoked by uid 0); 5 May 2001 00:07:19 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx27) with SMTP; 5 May 2001 00:07:19 -0000 X-eGroups-Return: sentto-1101623-2750-989021235-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 05 May 2001 00:07:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 00:07:14 -0000 Received: (qmail 17675 invoked from network); 5 May 2001 00:07:14 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 5 May 2001 00:07:14 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 5 May 2001 00:07:13 -0000 Received: from f-cpu.org (nas2-195.aub.club-internet.fr [195.36.133.195]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA18455 for ; Sat, 5 May 2001 02:06:58 +0200 (MET DST) Message-ID: <3AF343C4.A7AB7D5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 02:05:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

The discussions about the server(s) are going on on both french
and english mailing lists (curiously, the german one is mute...).
i wish there was no langage barreer...

Carlos De Urresti Hannoh wrote:
> > hello everybody,
>...
> > Phase 0 will be to find a location, a network, a legal and official
> > arrangement for the costs (electricity, climatisation...), putting
> This might help a little bit :) I work on the first IDC (Internet Data
> Center) in LatinAmerica. Giving a brief resume of the capabilities out of it are:
> (pretty fancy) Area of the Site: More than 7,000 km^2.
hmmm i think you mean : "7,000 m^2." :-)

> Aprox 1.2 Gbit :) uplink without the emergency link. (And we can buy only
> the needed bandwith since if we choose here it most be at the collocation
> area).
> 6 Electric Generators (Each one backing up all the site) + normal elect.
> climatisation = less than 20 C (brrrrrr :>) just don't walk up the holes
> were the air runs under -5 C :/
> etc etc
ok ok ok :-)

however, if we use Celaro hardware, we'll have to check if the exportation
is allowed to Mexico. The patent struggle with Quickturn makes selling Celaros
to US impossible. i'll ask the people at Meta Systems.
People that know guys from Synopsys, Cadence, Axis, Ikos or Quickturn
can already ask if they're ready to collaborate/sponsor the project.

> > a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
> > the account management, the job queue...
> First off: I'm a Solaris user :> but situations make you change.
> This company is 85% Telmex(Huge Monopolic Telco) and 15% HP so we might get
> a good price over a new HP machine if we sign the arrangement.
> The good hint about this is that all the parts that would fail or broke
> would be replaced by me:) and I can be pretty alert over the equipments; of
> course if the equipment is new we get all the warranties : ) and this a cron if we
> buy refurbished machines :/ we couldn't apply for them and in the long term
> this could hit us really bad :/
>
> If you want me to start looking for prices just pass me down a line.

if you can ask the prices for a "decent" SUN (min 1G RAM and 20G HDD),
then just go ahead, it will be helpful in any case.



> > -----Message d'origine-----
> > De: Yann Guidon <whygee@f-cpu.org>
> > More than two years ago, we tried to see if we could
> > put a PC on the net, connected to a FPGA board. It
> > appears impossible for practical reasons but i have learnt
> > a lot about emulators, they solve all the problems.
> >
> > Now, it's only the beginning of a new "project" because
> > we need to federate other Free HW projects, in order to
> For a starting place of the Free HW website I could offer a 256 k/bit
> line(not a lot.. but for starting web server is more than enough. At least I think
> so. But not enough hardware :/ unless I run the web server on a P200 with 72
> MB RAM.

It is nice and useful, but now :
- a root team must be carefully chosen
- we need a separate domain name. we can setup a subdomain of
f-cpu.xxx (such as eda.f-cpu.org) but if this evolves as a trans-project
server (if we receive help from other Open Hardware and Free Hardware projects)
a separate and neutral DN is desired in the future.


> From: boucli27 at altavista dot net
> Subject: Re: [f-cpu] Which machine to use
> > The problem with the *Blade series is that first you pay
> > a premium price, second they are still not reliable :
> > a lot of them are DOA ( dead on arrival ), thus I think
> > it should be wyser to stick to 'old' USII based servers.
> Blade are doing fine now; no more than a week for delivery
wow :-)

> > I think we may have a premium class server for ~$15.000 --> $20.000 thus
> > we will have to launch a subscribtion
> > in order to get one of theses babies.
> >
> > I think I will be able to find $1.000 for this project.
> > Who's next ?
> May I? :)
yeah :-) [i can't, unfortunately]

who is in charge of collecting the funds ?

I think that before we do everything, we have to :
- make a press release on slashdot, usenet etc...
- wait for new contribution proposals (so we can spread the workload)
- ask for price lists and call for sponsors
Let's set a milestone in two week. Maybe we'll be sure in one month.
i count on you all to spread the word.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Ebates: Click here for cash back at 400+ stores!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 00:39:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03977 for ; Sat, 5 May 2001 08:58:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:25 +0200 (MEST) Received: (qmail 7564 invoked by uid 0); 4 May 2001 22:41:15 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx07) with SMTP; 4 May 2001 22:41:15 -0000 X-eGroups-Return: sentto-1101623-2747-989016070-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 04 May 2001 22:41:12 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:41:09 -0000 Received: (qmail 58479 invoked from network); 4 May 2001 22:41:08 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 4 May 2001 22:41:08 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta1 with SMTP; 4 May 2001 22:41:08 -0000 Received: from f-cpu.org (nas4-84.ras.club-internet.fr [195.36.203.84]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03826 for ; Sat, 5 May 2001 00:40:55 +0200 (MET DST) Message-ID: <3AF32F9C.C35544E9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:39:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
>  http://www.cs.man.ac.uk/async/index.html
sorry, no time yet to check...

> I think that asynchronous trick could be used. Micropipeline could be a
> great thing. And we can avoid the critical insertion of the clock tree
> (and all the associated skew problem).
>
> Maybe a mixed design could be used.

I don't think that it is critical at our level.
the ISA and architecture are not concerned by the clocking issue.

On top of that, discussions on comp.arch and with Andy Glew (Intel)
showed that no tool can do automatic asynch clocking designs, and i know
that you're a fervent silicon synthesis fan. so if you want asynch,
you'll have to do it all by yourself :-)

well, today the problem is still to design the VHDL model.

i d/l the DSP files that you pointed to, btw.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 00:59:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03980 for ; Sat, 5 May 2001 08:58:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:26 +0200 (MEST) Received: (qmail 20920 invoked by uid 0); 4 May 2001 23:00:17 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx25) with SMTP; 4 May 2001 23:00:17 -0000 X-eGroups-Return: sentto-1101623-2748-989017167-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fk.egroups.com with NNFMP; 04 May 2001 23:00:12 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 22:59:26 -0000 Received: (qmail 93078 invoked from network); 4 May 2001 22:59:26 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 4 May 2001 22:59:26 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta3 with SMTP; 4 May 2001 22:59:24 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D54B09E69 for ; Sat, 5 May 2001 00:59:06 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF3343A.82DB98E8@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> <3AF32F9C.C35544E9@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 00:59:06 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas wrote:
> >  http:/= /www.cs.man.ac.uk/async/index.html
> sorry, no time yet to check...
>
> > I think that asynchronous trick could be used. Micropipeline coul= d be a
> > great thing. And we can avoid the critical insertion of the clock= tree
> > (and all the associated skew problem).
> >
> > Maybe a mixed design could be used.
>
> I don't think that it is critical at our level.
> the ISA and architecture are not concerned by the clocking issue.
>
> On top of that, discussions on comp.arch and with Andy Glew (Intel) > showed that no tool can do automatic asynch clocking designs, and i kn= ow

http://www.cs.ma= n.ac.uk/async/tools/index.html ;p

But i better prefer VHDL, it's clear ! I try to find a way to replace
clk by request and acknoledge, if i could...

> that you're a fervent silicon synthesis fan. so if you want asynch, > you'll have to do it all by yourself :-)
>
> well, today the problem is still to design the VHDL model.
>
> i d/l the DSP files that you pointed to, btw.
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 01:14:01 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03989 for ; Sat, 5 May 2001 08:58:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:28 +0200 (MEST) Received: (qmail 7825 invoked by uid 0); 4 May 2001 23:14:40 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx01) with SMTP; 4 May 2001 23:14:40 -0000 X-eGroups-Return: sentto-1101623-2749-989018061-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 04 May 2001 23:14:22 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 4 May 2001 23:14:19 -0000 Received: (qmail 23305 invoked from network); 4 May 2001 23:14:19 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 4 May 2001 23:14:19 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.223.146) by mta2 with SMTP; 4 May 2001 23:14:19 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id AF3019E69 for ; Sat, 5 May 2001 01:14:01 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF337B9.CE8F5E52@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AEF5EBA.A9C01B52@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 01:14:01 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] back from Dortmund Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :

> - check TRIMARAN and other high performance compilers

Funny, it's the EPIC compiler, you know the grand brother of the...
merced ( or IA64 ).

No comment, Whygee ! ;p

http://www.trimaran.org/

nicO
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 02:05:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03995 for ; Sat, 5 May 2001 08:58:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:29 +0200 (MEST) Received: (qmail 2379 invoked by uid 0); 5 May 2001 00:07:19 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx27) with SMTP; 5 May 2001 00:07:19 -0000 X-eGroups-Return: sentto-1101623-2750-989021235-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 05 May 2001 00:07:16 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 00:07:14 -0000 Received: (qmail 17675 invoked from network); 5 May 2001 00:07:14 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 5 May 2001 00:07:14 -0000 Received: from unknown (HELO front4.grolier.fr) (194.158.96.54) by mta1 with SMTP; 5 May 2001 00:07:13 -0000 Received: from f-cpu.org (nas2-195.aub.club-internet.fr [195.36.133.195]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA18455 for ; Sat, 5 May 2001 02:06:58 +0200 (MET DST) Message-ID: <3AF343C4.A7AB7D5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 02:05:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

The discussions about the server(s) are going on on both french
and english mailing lists (curiously, the german one is mute...).
i wish there was no langage barreer...

Carlos De Urresti Hannoh wrote:
> > hello everybody,
>...
> > Phase 0 will be to find a location, a network, a legal and official
> > arrangement for the costs (electricity, climatisation...), putting
> This might help a little bit :) I work on the first IDC (Internet Data
> Center) in LatinAmerica. Giving a brief resume of the capabilities out of it are:
> (pretty fancy) Area of the Site: More than 7,000 km^2.
hmmm i think you mean : "7,000 m^2." :-)

> Aprox 1.2 Gbit :) uplink without the emergency link. (And we can buy only
> the needed bandwith since if we choose here it most be at the collocation
> area).
> 6 Electric Generators (Each one backing up all the site) + normal elect.
> climatisation = less than 20 C (brrrrrr :>) just don't walk up the holes
> were the air runs under -5 C :/
> etc etc
ok ok ok :-)

however, if we use Celaro hardware, we'll have to check if the exportation
is allowed to Mexico. The patent struggle with Quickturn makes selling Celaros
to US impossible. i'll ask the people at Meta Systems.
People that know guys from Synopsys, Cadence, Axis, Ikos or Quickturn
can already ask if they're ready to collaborate/sponsor the project.

> > a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
> > the account management, the job queue...
> First off: I'm a Solaris user :> but situations make you change.
> This company is 85% Telmex(Huge Monopolic Telco) and 15% HP so we might get
> a good price over a new HP machine if we sign the arrangement.
> The good hint about this is that all the parts that would fail or broke
> would be replaced by me:) and I can be pretty alert over the equipments; of
> course if the equipment is new we get all the warranties : ) and this a cron if we
> buy refurbished machines :/ we couldn't apply for them and in the long term
> this could hit us really bad :/
>
> If you want me to start looking for prices just pass me down a line.

if you can ask the prices for a "decent" SUN (min 1G RAM and 20G HDD),
then just go ahead, it will be helpful in any case.



> > -----Message d'origine-----
> > De: Yann Guidon <whygee@f-cpu.org>
> > More than two years ago, we tried to see if we could
> > put a PC on the net, connected to a FPGA board. It
> > appears impossible for practical reasons but i have learnt
> > a lot about emulators, they solve all the problems.
> >
> > Now, it's only the beginning of a new "project" because
> > we need to federate other Free HW projects, in order to
> For a starting place of the Free HW website I could offer a 256 k/bit
> line(not a lot.. but for starting web server is more than enough. At least I think
> so. But not enough hardware :/ unless I run the web server on a P200 with 72
> MB RAM.

It is nice and useful, but now :
- a root team must be carefully chosen
- we need a separate domain name. we can setup a subdomain of
f-cpu.xxx (such as eda.f-cpu.org) but if this evolves as a trans-project
server (if we receive help from other Open Hardware and Free Hardware projects)
a separate and neutral DN is desired in the future.


> From: boucli27 at altavista dot net
> Subject: Re: [f-cpu] Which machine to use
> > The problem with the *Blade series is that first you pay
> > a premium price, second they are still not reliable :
> > a lot of them are DOA ( dead on arrival ), thus I think
> > it should be wyser to stick to 'old' USII based servers.
> Blade are doing fine now; no more than a week for delivery
wow :-)

> > I think we may have a premium class server for ~$15.000 --> $20.000 thus
> > we will have to launch a subscribtion
> > in order to get one of theses babies.
> >
> > I think I will be able to find $1.000 for this project.
> > Who's next ?
> May I? :)
yeah :-) [i can't, unfortunately]

who is in charge of collecting the funds ?

I think that before we do everything, we have to :
- make a press release on slashdot, usenet etc...
- wait for new contribution proposals (so we can spread the workload)
- ask for price lists and call for sponsors
Let's set a milestone in two week. Maybe we'll be sure in one month.
i count on you all to spread the word.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Ebates: Click here for cash back at 400+ stores!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 02:15:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA03998 for ; Sat, 5 May 2001 08:58:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:31 +0200 (MEST) Received: (qmail 19073 invoked by uid 0); 5 May 2001 00:17:36 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx30) with SMTP; 5 May 2001 00:17:36 -0000 X-eGroups-Return: sentto-1101623-2751-989021854-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 05 May 2001 00:17:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 00:17:33 -0000 Received: (qmail 33769 invoked from network); 5 May 2001 00:17:33 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 5 May 2001 00:17:33 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 5 May 2001 00:17:32 -0000 Received: from f-cpu.org (nas2-195.aub.club-internet.fr [195.36.133.195]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA07270 for ; Sat, 5 May 2001 02:17:21 +0200 (MET DST) Message-ID: <3AF34636.F848B788@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AEF5EBA.A9C01B52@f-cpu.org> <3AF337B9.CE8F5E52@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 02:15:50 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] back from Dortmund Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

Nicolas wrote:
> Yann Guidon a =E9crit :
> > - check TRIMARAN and other high performance compilers
> Funny, it's the EPIC compiler, you know the grand brother of the... > merced ( or IA64 ).
>
> No comment, Whygee ! ;p
>
> http://www.trimaran.org/

you seem to ignore some "facts" and history of IA64.
HP had acquired a company that made VLIW design based on a company that
was done by another smaller one, and HP asked Intel to collaborate.
Intel gave the name and horsepower, but the theory behing IA64 was
started more than 15 years ago. No comment, check your history books.

Trimaran is not designed by Intel. a lot of it comes from university
students. The pre-trimaran (i don't remember the name) retargetable
compiler could be adapted to F-CPU ISA.

BTW, what do you think about the few "booklets" i lent you ?

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 02:18:44 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04001 for ; Sat, 5 May 2001 08:58:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:31 +0200 (MEST) Received: (qmail 19973 invoked by uid 0); 5 May 2001 00:20:36 -0000 Received: from hk.egroups.com (208.50.99.220) by mx0.gmx.net (mx06) with SMTP; 5 May 2001 00:20:36 -0000 X-eGroups-Return: sentto-1101623-2752-989022030-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 05 May 2001 00:20:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 00:20:30 -0000 Received: (qmail 33623 invoked from network); 5 May 2001 00:20:29 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 May 2001 00:20:29 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta3 with SMTP; 5 May 2001 00:20:29 -0000 Received: from f-cpu.org (nas2-195.aub.club-internet.fr [195.36.133.195]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA25510 for ; Sat, 5 May 2001 02:20:15 +0200 (MET DST) Message-ID: <3AF346E4.A788D18D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <3AF30D11.2A72E43@seul.org> <3AF32F9C.C35544E9@f-cpu.org> <3AF3343A.82DB98E8@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 02:18:44 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi,

Nicolas wrote:
> Yann Guidon a =E9crit :
> > On top of that, discussions on comp.arch and with Andy Glew (Inte= l)
> > showed that no tool can do automatic asynch clocking designs, and= i know
> http://www.= cs.man.ac.uk/async/tools/index.html ;p

sorry, i have no time to check anyone of them...

> But i better prefer VHDL, it's clear ! I try to find a way to replace<= BR> > clk by request and acknoledge, if i could...
that's a way to do that...

g'night,
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"www.newaydirect.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Sat May 5 04:03:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA04019 for ; Sat, 5 May 2001 08:58:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 08:58:36 +0200 (MEST) Received: (qmail 13786 invoked by uid 0); 5 May 2001 02:03:42 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx22) with SMTP; 5 May 2001 02:03:42 -0000 X-eGroups-Return: sentto-1101623-2753-989028219-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 05 May 2001 02:03:40 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 02:03:38 -0000 Received: (qmail 5601 invoked from network); 5 May 2001 02:03:37 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 May 2001 02:03:37 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta3 with SMTP; 5 May 2001 02:03:37 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id FAA19066 for ; Sat, 5 May 2001 05:03:35 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3AF30D11.2A72E43@seul.org> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 5 May 2001 05:03:34 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] asynchronous design Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Fri, 4 May 2001, Nicolas wrote:

> I think that asynchronous trick could be used. Micropipeline could be a
> great thing. And we can avoid the critical insertion of the clock tree
> (and all the associated skew problem).

You are only looking for trouble with asynchronous designs. They are
extremely difficult to get to work correctly and none of the current
commercial tools support asynchronous designs propely.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
Ebates: Click here for cash back at 400+ stores!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Sat May 5 13:15:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA04718 for ; Sat, 5 May 2001 14:14:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sat, 05 May 2001 14:14:09 +0200 (MEST) Received: (qmail 7941 invoked by uid 0); 5 May 2001 11:18:21 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx28) with SMTP; 5 May 2001 11:18:21 -0000 X-eGroups-Return: sentto-1101623-2754-989061499-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 05 May 2001 11:18:20 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 11:18:19 -0000 Received: (qmail 1155 invoked from network); 5 May 2001 11:18:18 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 5 May 2001 11:18:18 -0000 Received: from unknown (HELO relay.mail.insnet.cw.net) (213.38.238.97) by mta3 with SMTP; 5 May 2001 11:18:18 -0000 Received: from ws133.warminsterschool.org.uk ([195.59.6.116]) by relay.mail.insnet.cw.net (8.11.2/8.11.2) with SMTP id f45BIcn00848 for ; Sat, 5 May 2001 12:18:38 +0100 (BST) Message-Id: <3.0.6.32.20010505121536.007e4ba0@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com In-Reply-To: <3AF343C4.A7AB7D5@f-cpu.org> References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 12:15:36 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N The German mailinglist isn't so mute, it is just waiting what the other are
deciding and then copying the best ideas
Cu
Kris
At 02:05 05/05/01 +0200, you wrote:
>hi !
>
>The discussions about the server(s) are going on on both french
>and english mailing lists (curiously, the german one is mute...).
>i wish there was no langage barreer...
>
>Carlos De Urresti Hannoh wrote:
>> > hello everybody,
>>...
>> > Phase 0 will be to find a location, a network, a legal and official
>> > arrangement for the costs (electricity, climatisation...), putting
>> This might help a little bit :) I work on the first IDC (Internet Data
>> Center) in LatinAmerica. Giving a brief resume of the capabilities out
of it are:
>> (pretty fancy) Area of the Site: More than 7,000 km^2.
>hmmm i think you mean : "7,000 m^2." :-)
>
>> Aprox 1.2 Gbit :) uplink without the emergency link. (And we can buy only
>> the needed bandwith since if we choose here it most be at the collocation
>> area).
>> 6 Electric Generators (Each one backing up all the site) + normal elect.
>> climatisation = less than 20 C (brrrrrr :>) just don't walk up the holes
>> were the air runs under -5 C :/
>> etc etc
>ok ok ok :-)
>
>however, if we use Celaro hardware, we'll have to check if the exportation
>is allowed to Mexico. The patent struggle with Quickturn makes selling
Celaros
>to US impossible. i'll ask the people at Meta Systems.
>People that know guys from Synopsys, Cadence, Axis, Ikos or Quickturn
>can already ask if they're ready to collaborate/sponsor the project.
>
>> > a decent SUN (Solaris) (or a HP-UX) server that can do the compilation,
>> > the account management, the job queue...
>> First off: I'm a Solaris user :> but situations make you change.
>> This company is 85% Telmex(Huge Monopolic Telco) and 15% HP so we might get
>> a good price over a new HP machine if we sign the arrangement.
>> The good hint about this is that all the parts that would fail or broke
>> would be replaced by me:) and I can be pretty alert over the equipments; of
>> course if the equipment is new we get all the warranties : ) and this a
cron if we
>> buy refurbished machines :/ we couldn't apply for them and in the long term
>> this could hit us really bad :/
>>
>> If you want me to start looking for prices just pass me down a line.
>
>if you can ask the prices for a "decent" SUN (min 1G RAM and 20G HDD),
>then just go ahead, it will be helpful in any case.
>
>
>
>> > -----Message d'origine-----
>> > De: Yann Guidon <whygee@f-cpu.org>
>> > More than two years ago, we tried to see if we could
>> > put a PC on the net, connected to a FPGA board. It
>> > appears impossible for practical reasons but i have learnt
>> > a lot about emulators, they solve all the problems.
>> >
>> > Now, it's only the beginning of a new "project" because
>> > we need to federate other Free HW projects, in order to
>> For a starting place of the Free HW website I could offer a 256 k/bit
>> line(not a lot.. but for starting web server is more than enough. At
least I think
>> so. But not enough hardware :/ unless I run the web server on a P200
with 72
>> MB RAM.
>
>It is nice and useful, but now :
> - a root team must be carefully chosen
> - we need a separate domain name. we can setup a subdomain of
>f-cpu.xxx (such as eda.f-cpu.org) but if this evolves as a trans-project
>server (if we receive help from other Open Hardware and Free Hardware
projects)
>a separate and neutral DN is desired in the future.
>
>
>> From: boucli27 at altavista dot net
>> Subject: Re: [f-cpu] Which machine to use
>> > The problem with the *Blade series is that first you pay
>> > a premium price, second they are still not reliable :
>> > a lot of them are DOA ( dead on arrival ), thus I think
>> > it should be wyser to stick to 'old' USII based servers.
>> Blade are doing fine now; no more than a week for delivery
>wow :-)
>
>> > I think we may have a premium class server for ~$15.000 --> $20.000 thus
>> > we will have to launch a subscribtion
>> > in order to get one of theses babies.
>> >
>> > I think I will be able to find $1.000 for this project.
>> > Who's next ?
>> May I? :)
>yeah :-) [i can't, unfortunately]
>
>who is in charge of collecting the funds ?
>
>I think that before we do everything, we have to :
> - make a press release on slashdot, usenet etc...
> - wait for new contribution proposals (so we can spread the workload)
> - ask for price lists and call for sponsors
>Let's set a milestone in two week. Maybe we'll be sure in one month.
>i count on you all to spread the word.
>
>WHYGEE
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
www.newaydirect.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 17:47:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00310 for ; Sun, 6 May 2001 14:10:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:10:56 +0200 (MEST) Received: (qmail 4831 invoked by uid 0); 5 May 2001 15:48:58 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx02) with SMTP; 5 May 2001 15:48:58 -0000 X-eGroups-Return: sentto-1101623-2755-989077736-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 05 May 2001 15:48:57 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 15:48:55 -0000 Received: (qmail 52924 invoked from network); 5 May 2001 15:48:55 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 5 May 2001 15:48:55 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 5 May 2001 15:48:54 -0000 Received: from f-cpu.org (nas2-222.ras.club-internet.fr [195.36.192.222]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA10492 for ; Sat, 5 May 2001 17:48:41 +0200 (MET DST) Message-ID: <3AF4207E.4DB671D8@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 17:47:10 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

nicolas.boulay@ifrance.com wrote:
> http://www-frec.bull.com/servers/index.htm
hmmm what do you mean by "easy" ?
it just roughly describes the HW.
No architecture, only marketing.
Or maybe i missed something ?

However, i'll do my best to attend the
conference in Paris.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Ebates: Click here for cash back at 400+ stores!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Sat May 5 18:05:38 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00316 for ; Sun, 6 May 2001 14:10:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:10:57 +0200 (MEST) Received: (qmail 14294 invoked by uid 0); 5 May 2001 16:08:01 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx009-rz3) with SMTP; 5 May 2001 16:08:01 -0000 X-eGroups-Return: sentto-1101623-2756-989078847-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hm.egroups.com with NNFMP; 05 May 2001 16:07:28 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 16:07:26 -0000 Received: (qmail 95349 invoked from network); 5 May 2001 16:07:26 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 5 May 2001 16:07:26 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 5 May 2001 16:07:26 -0000 Received: from f-cpu.org (nas1-135.ras.club-internet.fr [195.36.192.135]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA13012 for ; Sat, 5 May 2001 18:07:11 +0200 (MET DST) Message-ID: <3AF424D2.DCEC62D0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> <3.0.6.32.20010505121536.007e4ba0@pop1.edex.net.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 18:05:38 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kristian-Ole Riehn wrote:
> The German mailinglist isn't so mute,
well, i didn't get a message for a few months...

> it is just waiting what the other are
> deciding and then copying the best ideas
now, if you want some action, it would be a good idea to
organise german people. We have (almost) succeeded
in registering the F-CPU brand and logo in France.
It would be good that Germans do that in Germany,
and why not Americans in the USA...

Oh, there is also the EDA server story.
There are plenty of things to do, and i know
that we do never have enough free time.

have fun and CU@HAL
> Cu
> Kris
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sat May 5 18:15:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00325 for ; Sun, 6 May 2001 14:11:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:11:00 +0200 (MEST) Received: (qmail 9609 invoked by uid 0); 5 May 2001 16:16:12 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx06) with SMTP; 5 May 2001 16:16:12 -0000 X-eGroups-Return: sentto-1101623-2757-989079369-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 05 May 2001 16:16:11 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 5 May 2001 16:16:08 -0000 Received: (qmail 2641 invoked from network); 5 May 2001 16:16:06 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 5 May 2001 16:16:06 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.224.41) by mta3 with SMTP; 5 May 2001 16:16:06 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 138F69E50 for ; Sat, 5 May 2001 18:15:53 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF42738.270C0C33@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 18:15:52 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N HUm, sorry : stupid Frame !

cf. http://www-fre= c.bull.com/docs/white_home.htm

It's the 'white paper' link.

nicO

Yann Guidon a =E9crit :
>
> hi !
>
> nicolas.boulay@ifrance.com wrote:
> > http://www= -frec.bull.com/servers/index.htm
> hmmm what do you mean by "easy" ?
> it just roughly describes the HW.
> No architecture, only marketing.
> Or maybe i missed something ?
>
> However, i'll do my best to attend the
> conference in Paris.
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Ebates:
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From tyler_palko@yahoo.com Sat May 5 22:30:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00397 for ; Sun, 6 May 2001 14:11:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:11:18 +0200 (MEST) Received: (qmail 12836 invoked by uid 0); 5 May 2001 21:01:16 -0000 Received: from ci.egroups.com (64.211.240.235) by mx0.gmx.net (mx06) with SMTP; 5 May 2001 21:01:16 -0000 X-eGroups-Return: sentto-1101623-2758-989096341-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ci.egroups.com with NNFMP; 05 May 2001 20:59:01 -0000 X-Sender: smartb4ubbadab@angelfire.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 5 May 2001 20:59:00 -0000 Received: (qmail 10863 invoked from network); 5 May 2001 20:59:00 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 5 May 2001 20:59:00 -0000 Received: from unknown (HELO Globalshop.pt) (195.245.191.250) by mta3 with SMTP; 5 May 2001 20:59:00 -0000 Received: from 63.49.73.43 ([63.49.73.43]) by Globalshop.pt with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 5 May 2001 21:48:10 +0100 Message-ID: <00005f261c14$000074e3$000060d6@63.49.73.43> To: X-Priority: 3 X-MSMail-Priority: Normal X-eGroups-From: smartb4ubbadab@angelfire.com From: tyler_palko@yahoo.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 05 May 2001 16:30:25 -0400 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] One On One Assistance Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Status: R X-Status: N EXCITING new program that can save you big money on your taxes EVERY year! Stop paying the government every April, and let the IRS write YOU a check for a change. We help you take advantage of deductions that you could NEVER take advantage of before. This program is perfectly LEGAL, and you can start taking home more of YOUR $ IMMEDIATELY! Reply today with your name, address, phone number, as well as the best day of the week and time of day to reach you. ***************************************************** To be removed from this mailing, reply with "REMOVE" in the subject line. ***************************************************** Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From Yann Guidon Sun May 6 03:10:22 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00424 for ; Sun, 6 May 2001 14:11:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:11:25 +0200 (MEST) Received: (qmail 13472 invoked by uid 0); 6 May 2001 01:12:22 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx28) with SMTP; 6 May 2001 01:12:22 -0000 X-eGroups-Return: sentto-1101623-2759-989111536-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 06 May 2001 01:12:17 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 01:12:15 -0000 Received: (qmail 74739 invoked from network); 6 May 2001 01:12:14 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 6 May 2001 01:12:14 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta2 with SMTP; 6 May 2001 01:12:14 -0000 Received: from f-cpu.org (nas1-27.aub.club-internet.fr [195.36.202.27]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA04176 for ; Sun, 6 May 2001 03:12:00 +0200 (MET DST) Message-ID: <3AF4A47E.58295800@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 06 May 2001 03:10:22 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
> HUm, sorry : stupid Frame !
> cf. http://www-frec.bull.com/docs/white_home.htm
> It's the 'white paper' link.
hmmm right, it's a bit better ;-)
but still definitely "information manager speak" ;-P

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Sun May 6 12:43:57 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00454 for ; Sun, 6 May 2001 14:11:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 14:11:32 +0200 (MEST) Received: (qmail 25458 invoked by uid 0); 6 May 2001 10:44:55 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx07) with SMTP; 6 May 2001 10:44:55 -0000 X-eGroups-Return: sentto-1101623-2760-989145894-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 06 May 2001 10:44:55 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 10:44:53 -0000 Received: (qmail 85610 invoked from network); 6 May 2001 10:44:52 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 6 May 2001 10:44:52 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.150) by mta2 with SMTP; 6 May 2001 10:44:52 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 351229E5A for ; Sun, 6 May 2001 12:43:58 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3AF52AED.2B44A58F@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 06 May 2001 12:43:57 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon a =E9crit :
>
> hi !
>
> Nicolas wrote:
> > HUm, sorry : stupid Frame !
> > cf. http= ://www-frec.bull.com/docs/white_home.htm
> > It's the 'white paper' link.
> hmmm right, it's a bit better ;-)
> but still definitely "information manager speak" ;-P

It's a little bit true, that's why i said "easy" !

Read,
about cluster :
http://www-frec.b= ull.com/docs/wp_clustmgt.htm
about multicpu :
http://www-frec.bull.c= om/docs/wp_hep.htm

nicO
>
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Sun May 6 16:27:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01462 for ; Sun, 6 May 2001 20:56:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 20:56:08 +0200 (MEST) Received: (qmail 19477 invoked by uid 0); 6 May 2001 14:30:36 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx18) with SMTP; 6 May 2001 14:30:36 -0000 X-eGroups-Return: sentto-1101623-2761-989159434-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 06 May 2001 14:30:35 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 14:30:33 -0000 Received: (qmail 1827 invoked from network); 6 May 2001 14:30:33 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 6 May 2001 14:30:33 -0000 Received: from unknown (HELO relay.mail.insnet.cw.net) (213.38.238.97) by mta2 with SMTP; 6 May 2001 14:30:32 -0000 Received: from ws131.warminsterschool.org.uk ([195.59.6.120]) by relay.mail.insnet.cw.net (8.11.2/8.11.2) with SMTP id f46EUsn28107 for ; Sun, 6 May 2001 15:30:54 +0100 (BST) Message-Id: <3.0.6.32.20010506152749.007e7380@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com In-Reply-To: <3AF424D2.DCEC62D0@f-cpu.org> References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> <3.0.6.32.20010505121536.007e4ba0@pop1.edex.net.uk> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 06 May 2001 15:27:49 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello German people in this list,
I think it would be usefull to know how many there are, and how we can
organise, and support f-cpu better in Germany, I know Andreas and me are
bgoth from germany, so if there are any more, would u please mail me (not
necessary over the list, because this might be not useful infoormations for
everyone, and there is already enough junk e-mail like "test")

Cu
kris
At 18:05 05/05/01 +0200, you wrote:
>hi !
>
>Kristian-Ole Riehn wrote:
>> The German mailinglist isn't so mute,
>well, i didn't get a message for a few months...
>
>> it is just waiting what the other are
>> deciding and then copying the best ideas
>now, if you want some action, it would be a good idea to
>organise german people. We have (almost) succeeded
>in registering the F-CPU brand and logo in France.
>It would be good that Germans do that in Germany,
>and why not Americans in the USA...
>
>Oh, there is also the EDA server story.
>There are plenty of things to do, and i know
>that we do never have enough free time.
>
>have fun and CU@HAL
>> Cu
>> Kris
>WHYGEE
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Sun May 6 17:16:52 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA01465 for ; Sun, 6 May 2001 20:56:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 20:56:09 +0200 (MEST) Received: (qmail 22162 invoked by uid 0); 6 May 2001 15:22:44 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx19) with SMTP; 6 May 2001 15:22:44 -0000 X-eGroups-Return: sentto-1101623-2762-989162562-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 06 May 2001 15:22:43 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 15:22:41 -0000 Received: (qmail 97358 invoked from network); 6 May 2001 15:22:41 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 6 May 2001 15:22:41 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 6 May 2001 15:22:41 -0000 Received: from violin.ocn.ne.jp (p0243-ip07osakakita.osaka.ocn.ne.jp [61.119.175.243]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA11130 for ; Mon, 7 May 2001 00:22:39 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF56AE4.4A369CB0@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 00:16:52 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Nicolas wrote:
>
> Yann Guidon a =E9crit :
> >
> > hi !
> >
> > Nicolas wrote:
> > > HUm, sorry : stupid Frame !
> > > cf. http://www-frec.bull.com/docs/white_home.htm
> > > It's the 'white paper' link.
> > hmmm right, it's a bit better ;-)
> > but still definitely "information manager speak" ;-P >
> It's a little bit true, that's why i said "easy" !
>
> Read,
> about cluster :
> http://www-f= rec.bull.com/docs/wp_clustmgt.htm
> about multicpu :
> http://www-frec.b= ull.com/docs/wp_hep.htm
>
> nicO
> >
> > > nicO
> > WHYGEE
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/































If you can muster up the talent to engineer then I could provide some
wopping designs(I think). Who is the best engineer?

Chris
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Sun May 6 23:05:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA02195 for ; Sun, 6 May 2001 23:22:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Sun, 06 May 2001 23:22:09 +0200 (MEST) Received: (qmail 14425 invoked by uid 0); 6 May 2001 21:08:14 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx10) with SMTP; 6 May 2001 21:08:14 -0000 X-eGroups-Return: sentto-1101623-2764-989183289-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 06 May 2001 21:08:13 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 21:08:08 -0000 Received: (qmail 25354 invoked from network); 6 May 2001 21:08:08 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 6 May 2001 21:08:08 -0000 Received: from unknown (HELO relay.mail.insnet.cw.net) (213.38.238.97) by mta3 with SMTP; 6 May 2001 21:08:07 -0000 Received: from ws131.warminsterschool.org.uk ([195.59.6.120]) by relay.mail.insnet.cw.net (8.11.2/8.11.2) with SMTP id f46L8Tn26267 for ; Sun, 6 May 2001 22:08:29 +0100 (BST) Message-Id: <3.0.6.32.20010506220524.007e52e0@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com In-Reply-To: <3AF424D2.DCEC62D0@f-cpu.org> References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> <3.0.6.32.20010505121536.007e4ba0@pop1.edex.net.uk> From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 06 May 2001 22:05:24 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Brandname in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello everyone,
For the Brandname and logo registration, I think we have to pay fees or
something like this, is their a budget for the project or do we have to
find sponsors on our own and I think even more important on what name
should these things be registered? Fabian brought in the idea that there
should be a club for FCPU so that we can register it on this name, but we
need more (German) people, at least another 5 so that it can be founded. At
the moment I know from at least  germans so it might work, if there would
be other volunteers that could please write a short message to the list.
Thanks
Kris
At 18:05 05/05/01 +0200, you wrote:
>hi !
>
>Kristian-Ole Riehn wrote:
>> The German mailinglist isn't so mute,
>well, i didn't get a message for a few months...
>
>> it is just waiting what the other are
>> deciding and then copying the best ideas
>now, if you want some action, it would be a good idea to
>organise german people. We have (almost) succeeded
>in registering the F-CPU brand and logo in France.
>It would be good that Germans do that in Germany,
>and why not Americans in the USA...
>
>Oh, there is also the EDA server story.
>There are plenty of things to do, and i know
>that we do never have enough free time.
>
>have fun and CU@HAL
>> Cu
>> Kris
>WHYGEE
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Mon May 7 01:34:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA02885 for ; Mon, 7 May 2001 01:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 01:49:07 +0200 (MEST) Received: (qmail 14500 invoked by uid 0); 6 May 2001 21:38:09 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx22) with SMTP; 6 May 2001 21:38:09 -0000 X-eGroups-Return: sentto-1101623-2765-989185087-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 06 May 2001 21:38:08 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 21:38:07 -0000 Received: (qmail 81101 invoked from network); 6 May 2001 21:38:06 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 6 May 2001 21:38:06 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta2 with SMTP; 6 May 2001 21:38:06 -0000 Received: from art1.none.de (dialin69.pg2-nt.berlin.nikoma.de [213.54.65.69]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f46LcBg10175 for ; Sun, 6 May 2001 23:38:11 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin69.pg2-nt.berlin.nikoma.de [213.54.65.69] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14wY2R-0003EE-00 for ; Mon, 07 May 2001 01:34:07 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <3.0.6.32.20010506220524.007e52e0@pop1.edex.net.uk> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 7 May 2001 01:34:07 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Brandname in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> For the Brandname and logo registration, I think we have to pay fees or
> something like this, is their a budget for the project or do we have to
> find sponsors on our own and I think even more important on what name

GAOS e.V. is discussed about this registration.

> need more (German) people, at least another 5 so that it can be founded. At

To found a foundation in Germany you need a lot of power, believe me.

IMHO it is not necessary, because GAOS e.V. could the work do.

Bye Andreas
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Mon May 7 01:34:07 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03029 for ; Mon, 7 May 2001 02:00:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 02:00:31 +0200 (MEST) Received: (qmail 14500 invoked by uid 0); 6 May 2001 21:38:09 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx22) with SMTP; 6 May 2001 21:38:09 -0000 X-eGroups-Return: sentto-1101623-2765-989185087-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 06 May 2001 21:38:08 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 6 May 2001 21:38:07 -0000 Received: (qmail 81101 invoked from network); 6 May 2001 21:38:06 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 6 May 2001 21:38:06 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta2 with SMTP; 6 May 2001 21:38:06 -0000 Received: from art1.none.de (dialin69.pg2-nt.berlin.nikoma.de [213.54.65.69]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f46LcBg10175 for ; Sun, 6 May 2001 23:38:11 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin69.pg2-nt.berlin.nikoma.de [213.54.65.69] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14wY2R-0003EE-00 for ; Mon, 07 May 2001 01:34:07 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <3.0.6.32.20010506220524.007e52e0@pop1.edex.net.uk> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 7 May 2001 01:34:07 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Brandname in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> For the Brandname and logo registration, I think we have to pay fees or
> something like this, is their a budget for the project or do we have to
> find sponsors on our own and I think even more important on what name

GAOS e.V. is discussed about this registration.

> need more (German) people, at least another 5 so that it can be founded. At

To found a foundation in Germany you need a lot of power, believe me.

IMHO it is not necessary, because GAOS e.V. could the work do.

Bye Andreas
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon May 7 02:42:28 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03234 for ; Mon, 7 May 2001 02:53:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 02:53:25 +0200 (MEST) Received: (qmail 18427 invoked by uid 0); 7 May 2001 00:44:19 -0000 Received: from unknown.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx002-rz3) with SMTP; 7 May 2001 00:44:19 -0000 X-eGroups-Return: sentto-1101623-2767-989196257-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hh.egroups.com with NNFMP; 07 May 2001 00:44:18 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 00:44:17 -0000 Received: (qmail 27446 invoked from network); 7 May 2001 00:44:17 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 7 May 2001 00:44:17 -0000 Received: from unknown (HELO front6m.grolier.fr) (195.36.216.56) by mta1 with SMTP; 7 May 2001 00:44:16 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA05443 for ; Mon, 7 May 2001 02:44:00 +0200 (MET DST) Message-ID: <3AF5EF74.68AA8F5F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 02:42:28 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

"C.M. Herkert" wrote:
> Nicolas wrote:
> > Yann Guidon a =E9crit :
> > > Nicolas wrote:

> If you can muster up the talent to engineer then I could provide some<= BR> > wopping designs(I think). Who is the best engineer?
hmmm we have not made any contest yet ;-)

concerning your designs, is there an URL that we can look at ?

have fun,
> Chris
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon May 7 02:42:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03236 for ; Mon, 7 May 2001 02:53:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 02:53:26 +0200 (MEST) Received: (qmail 2874 invoked by uid 0); 7 May 2001 00:44:23 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx13) with SMTP; 7 May 2001 00:44:23 -0000 X-eGroups-Return: sentto-1101623-2768-989196261-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 07 May 2001 00:44:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 00:44:21 -0000 Received: (qmail 12230 invoked from network); 7 May 2001 00:44:21 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 7 May 2001 00:44:21 -0000 Received: from unknown (HELO front1m.grolier.fr) (195.36.216.51) by mta2 with SMTP; 7 May 2001 00:44:20 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA12021 for ; Mon, 7 May 2001 02:44:00 +0200 (MET DST) Message-ID: <3AF5EF71.76022E9F@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 02:42:25 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Brandname in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi,

Andreas Romeyke wrote:
> Hello,
> > For the Brandname and logo registration, I think we have to pay fees or
> > something like this, is their a budget for the project or do we have to
> > find sponsors on our own and I think even more important on what name
> GAOS e.V. is discussed about this registration.
>
> > need more (German) people, at least another 5 so that it can be founded. At
> To found a foundation in Germany you need a lot of power, believe me.
> IMHO it is not necessary, because GAOS e.V. could the work do.

nice.

but i don't think all that is necessary for the brand registration.
of course it is useful.

However in France, it is possible to co-own the brand. You could
check if it is the same in other countries. Here is how we did :
- logo was voted (apr. 2000) (i have it in vector format if somebody wants)
- call for participation on the french mailing list
- gathering of the money by one person who is legally in charge of the file
- every participant signs a forms, saying that he transfers his rights to
    the one person in charge (this paper is available from the brand office)

Several people participated and the cost was shared easily, according to
everyone's financial possibilities. I believe that the same can be done
in other countries. Maybe the GAOS e.V. can be in charge ? This way there
is no problem : there is a stable address, and non-members can send their
money in confidence. I hope that the recipe will work again !

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon May 7 02:42:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03239 for ; Mon, 7 May 2001 02:53:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 02:53:27 +0200 (MEST) Received: (qmail 27569 invoked by uid 0); 7 May 2001 00:44:23 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx03) with SMTP; 7 May 2001 00:44:23 -0000 X-eGroups-Return: sentto-1101623-2769-989196262-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 07 May 2001 00:44:22 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 00:44:21 -0000 Received: (qmail 30231 invoked from network); 7 May 2001 00:44:21 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 7 May 2001 00:44:21 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 7 May 2001 00:44:21 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA25487 for ; Mon, 7 May 2001 02:39:34 +0200 (MET DST) Message-ID: <3AF5EF77.6D630254@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AF20265.DD0589B0@f-cpu.org> <11346.988985947@www46.gmx.net> <3.0.6.32.20010505121536.007e4ba0@pop1.edex.net.uk> <3.0.6.32.20010506152749.007e7380@pop1.edex.net.uk> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 02:42:31 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] meeting in Paris this evening Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello !

Kristian-Ole Riehn wrote:
> Hello German people in this list,
> I think it would be usefull to know how many there are, and how we can
> organise, and support f-cpu better in Germany, I know Andreas and me are
> bgoth from germany, so if there are any more, would u please mail me (not
> necessary over the list, because this might be not useful infoormations for
> everyone, and there is already enough junk e-mail like "test")
> Cu
> kris

FYI, there is a german mailing list where some of the discussions took place
earlier. are you subscribed there ?

I only manage the french list. The german one (look at f-cpu.de)
is managed by Sven (i'm not sure). i guess that there are a few tens
of members.

I can't do much for the german "side" of the project : i think it's
good that the f-cpu guys there take their responsibilities. Maybe
(and i hope so) they can be even more successful.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon May 7 02:42:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA03242 for ; Mon, 7 May 2001 02:53:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 02:53:29 +0200 (MEST) Received: (qmail 18593 invoked by uid 0); 7 May 2001 00:44:37 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx002-rz3) with SMTP; 7 May 2001 00:44:37 -0000 X-eGroups-Return: sentto-1101623-2766-989196257-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 07 May 2001 00:44:19 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 00:44:16 -0000 Received: (qmail 27430 invoked from network); 7 May 2001 00:44:15 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 7 May 2001 00:44:15 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta1 with SMTP; 7 May 2001 00:44:15 -0000 Received: from f-cpu.org (nas1-175.ras.club-internet.fr [195.36.192.175]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA00025 for ; Mon, 7 May 2001 02:43:59 +0200 (MET DST) Message-ID: <3AF5EF73.946BB787@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AEEF42F.BC089E3@jetnet.ab.ca> <3AF56B75.E457938@violin.ocn.ne.jp> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 02:42:27 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Which machine to use ? Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi again,

"C.M. Herkert" wrote:
> Ben Franchuk wrote:
> > Kim Enkovaara wrote:
snip


> Hey Kim, where did you purge your memory from?
<dumb>
mmmm ferrite torus ?
</dumb>
> Chris
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 07:18:54 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA04514 for ; Mon, 7 May 2001 15:09:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 15:09:13 +0200 (MEST) Received: (qmail 26286 invoked by uid 0); 7 May 2001 05:24:46 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx002-rz3) with SMTP; 7 May 2001 05:24:46 -0000 X-eGroups-Return: sentto-1101623-2770-989213085-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 07 May 2001 05:24:45 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 05:24:44 -0000 Received: (qmail 47267 invoked from network); 7 May 2001 05:24:43 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 7 May 2001 05:24:43 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta2 with SMTP; 7 May 2001 05:24:43 -0000 Received: from violin.ocn.ne.jp (p0471-ip07osakakita.osaka.ocn.ne.jp [61.119.176.217]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id OAA04628 for ; Mon, 7 May 2001 14:24:41 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF6303E.82D102AC@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 14:18:54 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann Guidon wrote:
>
> hi !
>
> "C.M. Herkert" wrote:
> > Nicolas wrote:
> > > Yann Guidon a =E9crit :
> > > > Nicolas wrote:
>
> > If you can muster up the talent to engineer then I could provide = some
> > wopping designs(I think). Who is the best engineer?
> hmmm we have not made any contest yet ;-)
>
> concerning your designs, is there an URL that we can look at ?
>
> have fun,
> > Chris
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yes, joy joy, I meant a real engineer, someone who can make something in detail.
Yahoo! Groups Spons= or
3D"Click
Click for Det= ails
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Mon May 7 12:05:32 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA04553 for ; Mon, 7 May 2001 15:09:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 15:09:32 +0200 (MEST) Received: (qmail 16749 invoked by uid 0); 7 May 2001 10:14:10 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx25) with SMTP; 7 May 2001 10:14:10 -0000 X-eGroups-Return: sentto-1101623-2771-989230399-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fk.egroups.com with NNFMP; 07 May 2001 10:13:19 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 10:13:18 -0000 Received: (qmail 17916 invoked from network); 7 May 2001 10:13:18 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 7 May 2001 10:13:18 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 7 May 2001 10:13:17 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id DAA26388; Mon, 7 May 2001 03:13:16 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2HN0MH4; Mon, 7 May 2001 11:13:18 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AF6736C.41FB6B2@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 12:05:32 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N "C.M. Herkert" wrote:
> Yann Guidon wrote:
> > hi !
> > "C.M. Herkert" wrote:
> > > Nicolas wrote:
> > > > Yann Guidon a =E9crit :
> > > > > Nicolas wrote:
> > > If you can muster up the talent to engineer then I could pro= vide some
> > > wopping designs(I think). Who is the best engineer?
> > hmmm we have not made any contest yet ;-)
> > concerning your designs, is there an URL that we can look at ? > > have fun,
> > > Chris
> > WHYGEE
> Yes, joy joy, I meant a real engineer, someone who can make something = in
> detail.

well, there are some engineers, most are lurkers.
if you want details, read the F-CPU manual but people are usually
afraid of reading all the 170 pages :-)

f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz

and now, i'd like to see your design :-)

readU
YG
Yahoo! Groups Spons= or
3D"Click

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 16:56:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA05089 for ; Mon, 7 May 2001 17:10:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 17:10:38 +0200 (MEST) Received: (qmail 9019 invoked by uid 0); 7 May 2001 15:03:43 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx19) with SMTP; 7 May 2001 15:03:43 -0000 X-eGroups-Return: sentto-1101623-2772-989247821-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 07 May 2001 15:03:42 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 15:03:40 -0000 Received: (qmail 47346 invoked from network); 7 May 2001 15:02:40 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 7 May 2001 15:02:40 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta1 with SMTP; 7 May 2001 15:02:30 -0000 Received: from violin.ocn.ne.jp (p0737-ip07osakakita.osaka.ocn.ne.jp [61.119.177.229]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA21760 for ; Tue, 8 May 2001 00:02:28 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 23:56:41 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Yann GUIDON wrote:
>
> "C.M. Herkert" wrote:
> > Yann Guidon wrote:
> > > hi !
> > > "C.M. Herkert" wrote:
> > > > Nicolas wrote:
> > > > > Yann Guidon a =E9crit :
> > > > > > Nicolas wrote:
> > > > If you can muster up the talent to engineer then I coul= d provide some
> > > > wopping designs(I think). Who is the best engineer?
> > > hmmm we have not made any contest yet ;-)
> > > concerning your designs, is there an URL that we can look at= ?
> > > have fun,
> > > > Chris
> > > WHYGEE
> > Yes, joy joy, I meant a real engineer, someone who can make somet= hing in
> > detail.
>
> well, there are some engineers, most are lurkers.
> if you want details, read the F-CPU manual but people are usually
> afraid of reading all the 170 pages :-)
>
> f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
>
> and now, i'd like to see your design :-)

I will read the manual and I will also look into it in more detail, I
truly believe it's a feasible design(s). The actual design skills are
higher than present engineering, hence my comments. I can assess the
practicality, however I do have a life to lead and have a project all
ready underway, looking at the board gave me some ideas I might want to
pursue later.

Chris
> readU
> YG
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"Click
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon May 7 08:20:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA05432 for ; Mon, 7 May 2001 18:51:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Mon, 07 May 2001 18:51:41 +0200 (MEST) Received: (qmail 17236 invoked by uid 0); 7 May 2001 15:39:39 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx05) with SMTP; 7 May 2001 15:39:39 -0000 X-eGroups-Return: sentto-1101623-2773-989249962-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 07 May 2001 15:39:23 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 15:39:21 -0000 Received: (qmail 50324 invoked from network); 7 May 2001 15:39:21 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 7 May 2001 15:39:21 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 7 May 2001 15:39:21 -0000 Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA21892 for ; Mon, 7 May 2001 09:39:19 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AF63EB4.9A4A73A1@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 07 May 2001 00:20:36 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > If you can muster up the talent to engineer then I could provide some
> wopping designs(I think).

Q) Who is the best engineer?
A) We all ARE!

Q) Who is the best engineer?
A) The one in Locomotive.

Q) Who is the best engineer?
A) The one that gets JOB done with the parts on hand.

Ben.
-----
We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA07071 for ; Tue, 8 May 2001 00:52:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 00:52:37 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA09047 for ; Tue, 8 May 2001 02:39:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 02:39:23 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA09064 for ; Tue, 8 May 2001 02:40:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 02:40:06 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA09074 for ; Tue, 8 May 2001 02:40:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 02:40:32 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA09151 for ; Tue, 8 May 2001 02:44:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 02:44:12 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Mon May 7 23:30:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA09315 for ; Tue, 8 May 2001 02:49:30 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 08 May 2001 02:49:30 +0200 (MEST) Received: (qmail 5212 invoked by uid 0); 7 May 2001 21:36:06 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx004-rz3) with SMTP; 7 May 2001 21:36:06 -0000 X-eGroups-Return: sentto-1101623-2774-989271361-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fl.egroups.com with NNFMP; 07 May 2001 21:36:05 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 7 May 2001 21:36:00 -0000 Received: (qmail 75653 invoked from network); 7 May 2001 21:36:00 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 7 May 2001 21:36:00 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 7 May 2001 21:36:00 -0000 Received: from violin.ocn.ne.jp (p0257-ip06osakakita.osaka.ocn.ne.jp [61.119.172.3]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA09058 for ; Tue, 8 May 2001 06:35:58 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF713E3.93CED7A9@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 06:30:11 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
> > well, there are some engineers, most are lurkers.
> > if you want details, read the F-CPU manual but people are usually
> > afraid of reading all the 170 pages :-)
> >
> > f-cpu manual @ http://f-cpu.seul.org/manual/en/patch_YG_p1-4.tgz
> >
> > and now, i'd like to see your design :-)
>
> I will read the manual and I will also look into it in more detail, I
> truly believe it's a feasible design(s). The actual design skills are
> higher than present engineering, hence my comments. I can assess the
> practicality, however I do have a life to lead and have a project all
> ready underway, looking at the board gave me some ideas I might want to
> pursue later.
>
> Chris
> > readU
> > YG




Patent all ready owned by Lockheed Martin. Better luck next time.... I
wonder if they would be so kind.
Yahoo! Groups Sponsor
Click for Details
Click for Details

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Tue May 8 00:31:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA01926 for ; Wed, 9 May 2001 02:20:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 02:20:42 +0200 (MEST) Received: (qmail 20844 invoked by uid 0); 8 May 2001 10:52:04 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx30) with SMTP; 8 May 2001 10:52:04 -0000 X-eGroups-Return: sentto-1101623-2775-989319119-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 08 May 2001 10:52:02 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 8 May 2001 10:51:58 -0000 Received: (qmail 95317 invoked from network); 8 May 2001 09:40:40 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 May 2001 09:40:40 -0000 Received: from unknown (HELO delay-1v.clubint.net) (194.158.96.105) by mta1 with SMTP; 8 May 2001 09:40:39 -0000 Received: from f-cpu.org (nas1-150.aub.club-internet.fr [195.36.202.150]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13112 for ; Tue, 8 May 2001 00:32:43 +0200 (MET DST) Message-ID: <3AF7222E.7CAD3E18@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> <3AF713E3.93CED7A9@violin.ocn.ne.jp> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 08 May 2001 00:31:10 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hello,

"C.M. Herkert" wrote:
> > > and now, i'd like to see your design :-)
> >
> > I will read the manual and I will also look into it in more detai= l, I
> > truly believe it's a feasible design(s). The actual design skills= are
> > higher than present engineering, hence my comments. I can assess = the
> > practicality, however I do have a life to lead and have a project= all
> > ready underway, looking at the board gave me some ideas I might w= ant to
> > pursue later.
>
> Patent all ready owned by Lockheed Martin. Better luck next time.... I=
> wonder if they would be so kind.

sorry but what you wrote is not clear to me. what patent is owned by LM ?
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D"Make=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Tue May 8 19:40:50 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02061 for ; Wed, 9 May 2001 02:21:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 02:21:20 +0200 (MEST) Received: (qmail 14389 invoked by uid 0); 8 May 2001 18:46:10 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx004-rz3) with SMTP; 8 May 2001 18:46:10 -0000 X-eGroups-Return: sentto-1101623-2776-989347495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mv.egroups.com with NNFMP; 08 May 2001 18:44:56 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 8 May 2001 18:44:54 -0000 Received: (qmail 87695 invoked from network); 8 May 2001 17:46:39 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 May 2001 17:46:39 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta1 with SMTP; 8 May 2001 17:46:39 -0000 Received: from violin.ocn.ne.jp (p0831-ip02osakakita.osaka.ocn.ne.jp [211.6.35.73]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id CAA21904 for ; Wed, 9 May 2001 02:46:37 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF82FA2.1D8EA515@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> <3AF713E3.93CED7A9@violin.ocn.ne.jp> <3AF7222E.7CAD3E18@f-cpu.org> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 May 2001 02:40:50 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:
>
> hello,
>
> "C.M. Herkert" wrote:
> > > > and now, i'd like to see your design :-)
> > >
> > > I will read the manual and I will also look into it in more detail, I
> > > truly believe it's a feasible design(s). The actual design skills are
> > > higher than present engineering, hence my comments. I can assess the
> > > practicality, however I do have a life to lead and have a project all
> > > ready underway, looking at the board gave me some ideas I might want to
> > > pursue later.
> >
> > Patent all ready owned by Lockheed Martin. Better luck next time.... I
> > wonder if they would be so kind.
>
> sorry but what you wrote is not clear to me. what patent is owned by LM ?
>
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Well after thinking about it for some time looking at the pages and the things you were doing, I thought that about optical processing. However, I also found that LM own the patent.

Chris
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Wed May 9 00:31:47 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA02148 for ; Wed, 9 May 2001 02:21:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 02:21:50 +0200 (MEST) Received: (qmail 32445 invoked by uid 0); 8 May 2001 22:56:30 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx006-rz3) with SMTP; 8 May 2001 22:56:30 -0000 X-eGroups-Return: sentto-1101623-2777-989361221-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 08 May 2001 22:33:42 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 8 May 2001 22:33:40 -0000 Received: (qmail 15909 invoked from network); 8 May 2001 22:33:34 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 8 May 2001 22:33:34 -0000 Received: from unknown (HELO front7m.grolier.fr) (195.36.216.57) by mta1 with SMTP; 8 May 2001 22:33:33 -0000 Received: from f-cpu.org (nas2-96.aub.club-internet.fr [195.36.133.96]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA29559 for ; Wed, 9 May 2001 00:33:16 +0200 (MET DST) Message-ID: <3AF873D3.E8FBFD28@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> <3AF713E3.93CED7A9@violin.ocn.ne.jp> <3AF7222E.7CAD3E18@f-cpu.org> <3AF82FA2.1D8EA515@violin.ocn.ne.jp> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 May 2001 00:31:47 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

"C.M. Herkert" wrote:
> Yann Guidon wrote:
> > hello,
> > "C.M. Herkert" wrote:
> > > Patent all ready owned by Lockheed Martin. Better luck next time.... I
> > > wonder if they would be so kind.
> > sorry but what you wrote is not clear to me. what patent is owned by LM ?
> Well after thinking about it for some time looking at the pages and
> the things you were doing, I thought that about optical processing.
hmmm what makes you think about optical processing when you look at the F-CPU ?
and more exactly, what kind of optical technology are you thinking about ?

> However, I also found that LM own the patent.
there are millions of patents, a lot are active.
there is at least hundreds of patents on a specific subject.
If you start to look at the patent, you will be discouraged,
like anyone. However, you shouldn't think about them, otherwise
you'll do nothing. That's what we do and it works, and in the end
we get something so strange that no patent would exist on the FC0's
architectural features.

and now, i'm still waiting to see what you are doing :-)
is there a URL ?

have fun,
> Chris
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From "C.M. Herkert" Wed May 9 08:06:49 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA03673 for ; Wed, 9 May 2001 19:31:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 19:31:13 +0200 (MEST) Received: (qmail 22557 invoked by uid 0); 9 May 2001 06:13:36 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx24) with SMTP; 9 May 2001 06:13:36 -0000 X-eGroups-Return: sentto-1101623-2778-989388814-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hh.egroups.com with NNFMP; 09 May 2001 06:13:35 -0000 X-Sender: put@violin.ocn.ne.jp X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 9 May 2001 06:13:33 -0000 Received: (qmail 63102 invoked from network); 9 May 2001 06:12:39 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 9 May 2001 06:12:39 -0000 Received: from unknown (HELO violin.ocn.ne.jp) (210.190.142.41) by mta3 with SMTP; 9 May 2001 06:12:38 -0000 Received: from violin.ocn.ne.jp (p0659-ip05osakakita.osaka.ocn.ne.jp [211.130.250.151]) by violin.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id PAA13408 for ; Wed, 9 May 2001 15:12:36 +0900 (JST) Sender: put@violin.ocn.ne.jp Message-ID: <3AF8DE79.E95150EE@violin.ocn.ne.jp> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdksecure i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <200105041003.2f48@lh00.opsion.fr> <3AF4207E.4DB671D8@f-cpu.org> <3AF42738.270C0C33@seul.org> <3AF4A47E.58295800@f-cpu.org> <3AF52AED.2B44A58F@seul.org> <3AF56AE4.4A369CB0@violin.ocn.ne.jp> <3AF5EF74.68AA8F5F@f-cpu.org> <3AF6303E.82D102AC@violin.ocn.ne.jp> <3AF6736C.41FB6B2@mentor.com> <3AF6B7A9.B1FDE536@violin.ocn.ne.jp> <3AF713E3.93CED7A9@violin.ocn.ne.jp> <3AF7222E.7CAD3E18@f-cpu.org> <3AF82FA2.1D8EA515@violin.ocn.ne.jp> <3AF873D3.E8FBFD28@f-cpu.org> From: "C.M. Herkert" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 May 2001 15:06:49 +0900 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Easy paper about multicpu machine (french and english) Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:
>
> hi !
>
> "C.M. Herkert" wrote:
> > Yann Guidon wrote:
> > > hello,
> > > "C.M. Herkert" wrote:
> > > > Patent all ready owned by Lockheed Martin. Better luck next time.... I
> > > > wonder if they would be so kind.
> > > sorry but what you wrote is not clear to me. what patent is owned by LM ?
> > Well after thinking about it for some time looking at the pages and
> > the things you were doing, I thought that about optical processing.
> hmmm what makes you think about optical processing when you look at the F-CPU ?
> and more exactly, what kind of optical technology are you thinking about ?
>
> > However, I also found that LM own the patent.
> there are millions of patents, a lot are active.
> there is at least hundreds of patents on a specific subject.

Unfortunatly it was the same. Still There are definate calls for the
processor. PO

> If you start to look at the patent, you will be discouraged,
> like anyone. However, you shouldn't think about them, otherwise
> you'll do nothing. That's what we do and it works, and in the end
> we get something so strange that no patent would exist on the FC0's
> architectural features.
>
> and now, i'm still waiting to see what you are doing :-)
> is there a URL ?
> have fun,
> > Chris
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No, as I was saying before logic and code aren't my bag, that's why I
was interested to know who was good.
I do electronics and physics, still I'm no one man engineering team. I'm
into yet another area now, so. I'll check in later after some manual.

Chris 
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Wed May 9 10:34:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA03727 for ; Wed, 9 May 2001 19:31:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 19:31:31 +0200 (MEST) Received: (qmail 11488 invoked by uid 0); 9 May 2001 12:31:26 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx22) with SMTP; 9 May 2001 12:31:26 -0000 X-eGroups-Return: sentto-1101623-2779-989411469-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 09 May 2001 12:31:11 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_2); 9 May 2001 12:31:07 -0000 Received: (qmail 11437 invoked from network); 9 May 2001 12:30:53 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 9 May 2001 12:30:53 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 9 May 2001 12:30:51 -0000 Received: from art1.none.de (dialin177.pg1-nt.berlin.nikoma.de [213.54.64.177]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f49CUsg08954 for ; Wed, 9 May 2001 14:30:54 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin177.pg1-nt.berlin.nikoma.de [213.54.64.177] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14xPQK-0000Qz-00 for ; Wed, 09 May 2001 10:34:20 +0200 To: f-cpu@yahoogroups.com Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 9 May 2001 10:34:20 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Branding in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

The registration costs about 575,- DM (nearly 250 $) per brand. In GAOS is
a discussion now, a decision is expected up to 13-th june.

We are getting some information about branding (law, conditions, success
etc.)

Bye Andreas
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kristian-Ole Riehn Wed May 9 18:33:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA03760 for ; Wed, 9 May 2001 19:31:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 09 May 2001 19:31:40 +0200 (MEST) Received: (qmail 12206 invoked by uid 0); 9 May 2001 16:36:43 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx010-rz3) with SMTP; 9 May 2001 16:36:43 -0000 X-eGroups-Return: sentto-1101623-2781-989426180-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ef.egroups.com with NNFMP; 09 May 2001 16:36:22 -0000 X-Sender: kriehn@warminsterschool.org.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 9 May 2001 16:36:19 -0000 Received: (qmail 27841 invoked from network); 9 May 2001 16:36:13 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 9 May 2001 16:36:13 -0000 Received: from unknown (HELO relay.mail.insnet.cw.net) (213.38.238.97) by mta3 with SMTP; 9 May 2001 16:36:12 -0000 Received: from ws132.warminsterschool.org.uk ([195.59.6.114]) by relay.mail.insnet.cw.net (8.11.2/8.11.2) with SMTP id f49GaYH02624 for ; Wed, 9 May 2001 17:36:34 +0100 (BST) Message-Id: <3.0.6.32.20010509173324.007e77b0@pop1.edex.net.uk> X-Sender: d0455-kriehn@pop1.edex.net.uk X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) To: f-cpu@yahoogroups.com In-Reply-To: <3AF96FAC.96189E5F@mentor.com> References: From: Kristian-Ole Riehn MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 May 2001 17:33:24 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Branding in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andreas, are you doing the Branding now?
Bye
Kriss
At 18:26 09/05/01 +0200, you wrote:
>Andreas Romeyke wrote:
>> Hello,
>>
>> The registration costs about 575,- DM (nearly 250 $) per brand. In GAOS is
>> a discussion now, a decision is expected up to 13-th june.
>>
>> We are getting some information about branding (law, conditions, success
>> etc.)
>
>nice !
>
>whenever you need to fill in the papers, use the vectorized logo version,
>not the bitmap one, it is more acurate. It is available in PS format or in
DXF.
>
>> Bye Andreas
>
>YG
>
>speaking for himself
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann GUIDON Wed May 9 18:26:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA04570 for ; Thu, 10 May 2001 00:05:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 10 May 2001 00:05:07 +0200 (MEST) Received: (qmail 7842 invoked by uid 0); 9 May 2001 18:10:34 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx18) with SMTP; 9 May 2001 18:10:34 -0000 X-eGroups-Return: sentto-1101623-2780-989426055-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fj.egroups.com with NNFMP; 09 May 2001 16:34:17 -0000 X-Sender: yann_guidon@mentorg.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_2); 9 May 2001 16:34:15 -0000 Received: (qmail 36881 invoked from network); 9 May 2001 16:34:11 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 9 May 2001 16:34:11 -0000 Received: from unknown (HELO relay1.wv.mentorg.com) (192.94.38.42) by mta1 with SMTP; 9 May 2001 16:34:11 -0000 Received: from svr-frs-exc-01.metafr.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA05753; Wed, 9 May 2001 09:34:08 -0700 (PDT) Received: from mentor.com (zeus-46.metafr.mentorg.com [137.202.46.19]) by svr-frs-exc-01.metafr.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2HN0N50; Wed, 9 May 2001 17:34:10 +0100 Sender: yanng@relay1.mentorg.com Message-ID: <3AF96FAC.96189E5F@mentor.com> Organization: MENTOR GRAPHICS - Meta Systems Division X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en To: f-cpu@yahoogroups.com References: X-eGroups-From: Yann GUIDON From: Yann GUIDON MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 09 May 2001 18:26:20 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Branding in Germany Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Andreas Romeyke wrote:
> Hello,
>
> The registration costs about 575,- DM (nearly 250 $) per brand. In GAOS is
> a discussion now, a decision is expected up to 13-th june.
>
> We are getting some information about branding (law, conditions, success
> etc.)

nice !

whenever you need to fill in the papers, use the vectorized logo version,
not the bitmap one, it is more acurate. It is available in PS format or in DXF.

> Bye Andreas

YG

speaking for himself
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Mon May 14 03:47:24 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00728 for ; Tue, 15 May 2001 18:06:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:07 +0200 (MEST) Received: (qmail 17578 invoked by uid 0); 14 May 2001 01:49:32 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx12) with SMTP; 14 May 2001 01:49:32 -0000 X-eGroups-Return: sentto-1101623-2783-989804971-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 14 May 2001 01:49:31 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 14 May 2001 01:49:29 -0000 Received: (qmail 17557 invoked from network); 14 May 2001 01:49:22 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 14 May 2001 01:49:22 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta2 with SMTP; 14 May 2001 01:49:17 -0000 Received: from f-cpu.org (nas3-44.ras.club-internet.fr [195.36.203.44]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA22447; Mon, 14 May 2001 03:48:49 +0200 (MET DST) Message-ID: <3AFF392C.C94B2F3A@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 14 May 2001 03:47:24 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

i think that it's time to make a little summary
about the project of setting one or several servers up,
dedicated to EDA accounts for Free Hardware projects.
I will mainly focus on EDA SW because HW emulation
is one step beyond, we have to get the first step done first.


A) project organisation :

It clearly appears that this project is out of
the scope of the core F-CPU project, which (i remember
to the newbies) is to design a CPU core, that's all.

I feel that it is a good thing to separate the different
sides of the F-CPU project, at least when the necessary
means and knowleges differ from what is needed to the core goal.
For example, the chipset and motherboard projects are necessary but
the goal of F-CPU is not to design a motherboard. OTOH
the different sides are closely bound together, mainly
through ml communication.

Since the server(s) requires real HW with material presence
etc, plus certainly monetary and legal conditions,
it is natural to split the organisation at that point.

New project name, domain name + ml + CVS + etc. are necessary,
as well as a core team, admins, a central server, and legal existence.

I don't think that it should remain F-CPU specific and other
projects would benefit from that. As a rule of thumb, several
projects listed in the OpenCollector database can apply and
participate. It is, on one hand, a matter of usefulness :
if what we do is useful, i don't see why we shouldn't prevent
other projects from benefitting from our efforts, as long
as they are not "passive users" (they have to help). On the other
hand, i am not sure that we would attain a necessary critical mass,
with only F-CPU team members. We certainly need others' help to make
the project successful. I can think of the LEON and OpenCores
projects, with which we could team up in a project-neutral
organisation.


B) Goal of the new organisation

It must be defined when all the team members are present.
It requires a clear, short and precise description of what
the organisation is, and is not.
The F-CPU project certainly suffers from the same problems
as other projects, so here's a first proposition :

"
The goal of this project and organisation is to provide Free
Hardware developers with free online design tools, without
contraining him to buying anything or learn complex books.

The purpose of this project is to promote Free Hardware projects
and lower the entry effort for contributors. We want to
allow people to contribute without discrimination (either
monetary or expertise). The only constraint is that the
server users comply with usage restrictions and rules,
related to security and licencing (all the developped files
must be protected by the GPL).
"

The discussion is open, this draft will certainly evolve.


C) Users

As written above, the goal of this project is to remove
technological discrimination. A lot of F-CPU lurkers can't
access the necessary SW and HW to develop, play with or
enhance the designs. Most existing GNU tools are not yet
ready or satisfying (hard to learn, setup and maintain),
and the F-CPU project can't rely on "manually unlocked"
EDA software (rumors of so-called "piracy" would doom
the project and would play against the goal of becoming
an industry standard)

The servers managers allocate ressources to the users if :
- their design complies with some basic rules, such as the
  distribution under GPL
- they accept to respect the necessary security rules (ie password,
  access rights and UNIX restrictions, reverse engineering of
  the provided tools...)

Concerning the F-CPU, the amount of allocate ressources will
depend on the users themselves. All projects and users would have
access to the same ressources. A batch queue and quota will balance
the server load.


D) Sponsors

Individual contributors in form of money or HW are welcome,
but the EDA industry is sized for a larger scale.
Usually, NO EDA company will sell HW or SW to individuals,
even if they represent a group. The negociations will be tough.

Cadence had made a licence proposal on an individual basis,
which is a first step. Upcoming articles in the press could
help catch others' attention, we could get other proposals.
However we should be cautious : cooperation is fine as long
as we don't become marketing toys. Cadence's proposal is one
of the many examples of a company wanting to enhance its
corporate image and it is only mar/com babbling as long as we
don't get the SW and licences up and running !
"Advertising" on the servers is not good. Mention of the
sponsors is alright but we are engineers, not a marketing
medium. Right ?


E) Contributors

this project needs a root team and probably a surveillance commity,
besides the legal stuff. This means that it is a fully serious project
and responsible people are necessary. One will not be able to leave
the project on a whim.

I can't take the responsibility of this project : the F-CPU and
other things are already taking all my time. I could however help
on punctual cases, such as setting up a HW emulator (i have a rough
experience in this era).


F) Routes

There are several and non-exclusive ways to achieve the project's goal.
These routes will probably be explored parallelly, it is a good way to
have at least something working if everything else fails.

All propositions are welcome. Lightweight solutions are most likely
to succeed but will yield small results. EDA SW today is extremely
expensive and the "lightweight" servers (no legal backing) will probably
only have educational, freeware, GPL or public domain software, which
won't be enough.

"heavier" servers will be much more difficult to setup but will be able to
host proprietary software and hardware. their benefit and usefulness
are higher, as well as the risks. Today's industry is very prone to
suing ("Suing is human", cf EEtimes) and this eventuality is likely to
ruin our efforts. If excessive prudence is necessary for this project,
it is because a legal failure could doom the emergence of the Free Hardware
as a valid alternative in the industry.


G) PR

I have started to write a call for contributors, that will be sent
to the press, specialized websites and to the EDA companies.
I will publish it on this site and request for enhancements.
This text will require the F-CPU team's adhesion before it is sent.

I hope that with the help of universities, companies and individuals,
we can have a first idea of what to do. We will have a first deadline
in a few weeks.


H) Existing possibilities

1) We can start to setup individual servers. There have been some
proposals on the list. These "lightweight" solutions can be enhanced
if CADENCE holds its promise to provide us with some of its SW.
We'll have to be again in contact and get the licences for good.

2) setup a legal, non-profit organisation. The idea of the SUN server
has been studied, it will cost a lot and it is not realistic if few
people participate. I have started to negociate with my ex-employer
(Mentor) but it will be impossible without a minimal serious organisation.
I try to find a way to get a second-hand HW emulator.
This machine could be located at the EPITA (french engineeer school)
or with the help of GOAS or CCC (in Germany), where we can setup an
independent legal non-profit entity.

3) i have heard about a project that is being studied at Jussieu
(University of Paris). They want to setup a server with Alliance SW
(GPL). This is a cooperation between the microelectronics department
(where it is written) and another one where it will be hosted.
i'll do my best to keep you informaed and to participate
in this project.


If you have other means or ideas, please drop a message
on the list.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon May 14 11:25:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00842 for ; Tue, 15 May 2001 18:06:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:37 +0200 (MEST) Received: (qmail 10026 invoked by uid 0); 14 May 2001 18:38:46 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx26) with SMTP; 14 May 2001 18:38:46 -0000 X-eGroups-Return: sentto-1101623-2784-989865524-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 14 May 2001 18:38:44 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 18:38:43 -0000 Received: (qmail 37582 invoked from network); 14 May 2001 18:37:30 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 14 May 2001 18:37:30 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 14 May 2001 18:37:30 -0000 Received: from jetnet.ab.ca (dialin57.jetnet.ab.ca [207.153.6.57]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA23767 for ; Mon, 14 May 2001 12:37:04 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AFFA497.57103444@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 14 May 2001 03:25:43 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:
>
> hello,
>
> i think that it's time to make a little summary
> about the project of setting one or several servers up,
> dedicated to EDA accounts for Free Hardware projects.
> I will mainly focus on EDA SW because HW emulation
> is one step beyond, we have to get the first step done first.

Free Software & Hardware is one of free ideas and design,
that is EASILY accessible. This does not always mean FREE
cost, thus some items may have a reasonable profit margin.
For example a CD-ROM or a printed hardware manual could $10 - $15 above cost
and help support the similar free information over the web.

One place I would like to see more FREE software is with the
centers of higher learning. Most hoard any new ideas.

Also what is the demand of information for the F-CPU. I guess 75% would
simple documentation and other information as well as stable hardware
designs. This could be multiple servers world wide as this gets updated
infrequently.The other 25% would be people doing design work.

The hardware while a team effort still needs a project
manager ( clerical stuff ) and a project engineers ( software & hardware).
Since all ( I still like schematics ) design is in VHDL ( compressed text files)
E-mail and other simple information transfers could still work.

(Never forget the BANDWIDTH of 747 full of CD-ROMS)
A web site is need for FREE information to the world, but a server is
not needed for creative engineers.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Mon May 14 23:47:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00878 for ; Tue, 15 May 2001 18:06:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:45 +0200 (MEST) Received: (qmail 21283 invoked by uid 0); 14 May 2001 21:46:53 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx21) with SMTP; 14 May 2001 21:46:53 -0000 X-eGroups-Return: sentto-1101623-2785-989876810-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 14 May 2001 21:46:52 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 21:46:49 -0000 Received: (qmail 66967 invoked from network); 14 May 2001 21:46:44 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 14 May 2001 21:46:44 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.170.203) by mta2 with SMTP; 14 May 2001 21:46:44 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 9D3589E48 for ; Mon, 14 May 2001 23:47:20 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B005268.C3F5119D@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> <3AFFA497.57103444@jetnet.ab.ca> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 14 May 2001 23:47:20 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Yann Guidon wrote:
> >
> > hello,
> >
> > i think that it's time to make a little summary
> > about the project of setting one or several servers up,
> > dedicated to EDA accounts for Free Hardware projects.
> > I will mainly focus on EDA SW because HW emulation
> > is one step beyond, we have to get the first step done first.
>
> Free Software & Hardware is one of free ideas and design,
> that is EASILY accessible. This does not always mean FREE
> cost, thus some items may have a reasonable profit margin.
> For example a CD-ROM or a printed hardware manual could $10 - $15 abov= e cost
> and help support the similar free information over the web.
>
> One place I would like to see more FREE software is with the
> centers of higher learning. Most hoard any new ideas.
>
> Also what is the demand of information for the F-CPU. I guess 75% woul= d
> simple documentation and other information as well as stable hardware<= BR> > designs. This could be multiple servers world wide as this gets update= d
> infrequently.The other 25% would be people doing design work.
>
> The hardware while a team effort still needs a project
> manager ( clerical stuff ) and a project engineers ( software & ha= rdware).
> Since all ( I still like schematics ) design is in VHDL ( compressed t= ext files)
> E-mail and other simple information transfers could still work.
>
> (Never forget the BANDWIDTH of 747 full of CD-ROMS)
> A web site is need for FREE information to the world, but a server is<= BR> > not needed for creative engineers.

But we need rtl & gates simulator and a synthetiser, so how do you do that ?

Alliance is big and [in part] GPL but never forget that it didn't manage process in vhdl...

nicO

> Ben.
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Tue May 15 00:12:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00884 for ; Tue, 15 May 2001 18:06:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:47 +0200 (MEST) Received: (qmail 21385 invoked by uid 0); 14 May 2001 22:14:55 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx21) with SMTP; 14 May 2001 22:14:55 -0000 X-eGroups-Return: sentto-1101623-2786-989878493-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 14 May 2001 22:14:54 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 22:14:52 -0000 Received: (qmail 62330 invoked from network); 14 May 2001 22:14:32 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 14 May 2001 22:14:32 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 14 May 2001 22:14:26 -0000 Received: from f-cpu.org (nas2-92.aub.club-internet.fr [195.36.133.92]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13082 for ; Tue, 15 May 2001 00:14:12 +0200 (MET DST) Message-ID: <3B00585D.9672EEC0@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> <3AFFA497.57103444@jetnet.ab.ca> <3B005268.C3F5119D@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 00:12:45 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hi !

At last some reaction to the text :-)

Nicolas wrote:
> Ben Franchuk a =E9crit :
> > Yann Guidon wrote:
> > (Never forget the BANDWIDTH of 747 full of CD-ROMS)
> > A web site is need for FREE information to the world, but a serve= r is
> > not needed for creative engineers.
> But we need rtl & gates simulator and a synthetiser, so how do you= do
> that ?
> Alliance is big and [in part] GPL but never forget that it didn't mana= ge
> process in vhdl...

That is the node of the problem.
I can do stuff, incl. manual, SW and documentation, but
- i can't do everything alone,
- other people need a common ground on which we can communicate.

the EDA server, as written before, is a mean brought to contributors
so they can participate with the lowest possible access cost.
Since the VHDL (or verilog or whatever, it's not the point) files
are what matters, whatever we may write in the manual, we have to solve
the EDA problem once for all.

my short term todo list includes : cleanup of the Oekonux conference
files and preparation of files for HAL. I meet Lionel this week-end
and i hope that the f-cpu database will be setup.
We have a few weeks to reorganise all the project.
I hope that at least some lurkers will wake up...

read you soon,
> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Mon May 14 15:04:11 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00890 for ; Tue, 15 May 2001 18:06:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:49 +0200 (MEST) Received: (qmail 31495 invoked by uid 0); 14 May 2001 22:16:51 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx004-rz3) with SMTP; 14 May 2001 22:16:51 -0000 X-eGroups-Return: sentto-1101623-2787-989878608-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 14 May 2001 22:16:50 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 22:16:48 -0000 Received: (qmail 44325 invoked from network); 14 May 2001 22:15:12 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 May 2001 22:15:12 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 14 May 2001 22:15:12 -0000 Received: from jetnet.ab.ca (dialin58.jetnet.ab.ca [207.153.6.58]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA29162 for ; Mon, 14 May 2001 16:15:10 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3AFFD7CB.1AF1E4CC@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> <3AFFA497.57103444@jetnet.ab.ca> <3B005268.C3F5119D@seul.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 14 May 2001 07:04:11 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Nicolas wrote:
>
> Ben Franchuk a =E9crit :
>
> But we need rtl & gates simulator and a synthetiser, so how do you= do
> that ?

That is not a server problem.Electric is looking to be a better FREE
tool but you are right there are no GOOD FREE tools out there.

> Alliance is big and [in part] GPL but never forget that it didn't mana= ge
> process in vhdl...
>

What tools out there are really poor. I have a FPGA design software (W95) and every so often it can't meet set/hold times because of clock skew.
This is the MAIN global clock that runs to all the macro cells, that
I have no control over. With the same software I can't even get a report of delays in a useable format that I can use. This is a real problem
because I have 2 phase clock ( 6809 style ) delay calculations all expect a single phase clock.

Ben.


--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Andreas Romeyke Tue May 15 00:30:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00899 for ; Tue, 15 May 2001 18:06:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:51 +0200 (MEST) Received: (qmail 24623 invoked by uid 0); 14 May 2001 22:32:14 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx27) with SMTP; 14 May 2001 22:32:14 -0000 X-eGroups-Return: sentto-1101623-2788-989879532-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 14 May 2001 22:32:13 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 22:32:11 -0000 Received: (qmail 90723 invoked from network); 14 May 2001 22:32:07 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 14 May 2001 22:32:07 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta3 with SMTP; 14 May 2001 22:32:06 -0000 Received: from art1.none.de (dialin19.pg4-nt.berlin.nikoma.de [213.54.67.19]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f4EMW0Y12371 for ; Tue, 15 May 2001 00:32:03 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin19.pg4-nt.berlin.nikoma.de [213.54.67.19] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 14zQrT-0004WX-00 for ; Tue, 15 May 2001 00:30:43 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <3B00585D.9672EEC0@f-cpu.org> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 00:30:43 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello YG,

> That is the node of the problem.
> I can do stuff, incl. manual, SW and documentation, but
>  - i can't do everything alone,
>  - other people need a common ground on which we can communicate.

The main communication should be transfered via a mailinglist. We need
one(!) server to store files and documents.

> my short term todo list includes : cleanup of the Oekonux conference
> files and preparation of files for HAL. I meet Lionel this week-end
> and i hope that the f-cpu database will be setup.
> We have a few weeks to reorganise all the project.
> I hope that at least some lurkers will wake up...


My short TODO:

- closing translation of YG-Patches of Manual (YG-patch should be an
official manual)
- sending questions/bugreports generated from YG-Manual to YG
- find a solution for branding and sponsoring f-cpu via GAOS
e.V. (end of discussion is coming soon (to 16 july)
- a German lecture about f-cpu-project in Leipzig
- thinking about shifter again

YG-Manual todo:

- adding list of abbreviations
- fixing bugs

Bye Andreas
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Tue May 15 00:56:08 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00905 for ; Tue, 15 May 2001 18:06:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:57 +0200 (MEST) Received: (qmail 30271 invoked by uid 0); 14 May 2001 22:58:12 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx12) with SMTP; 14 May 2001 22:58:12 -0000 X-eGroups-Return: sentto-1101623-2789-989881089-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hi.egroups.com with NNFMP; 14 May 2001 22:58:10 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 22:58:08 -0000 Received: (qmail 33989 invoked from network); 14 May 2001 22:57:43 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 14 May 2001 22:57:43 -0000 Received: from unknown (HELO front5m.grolier.fr) (195.36.216.55) by mta1 with SMTP; 14 May 2001 22:57:43 -0000 Received: from f-cpu.org (nas2-92.aub.club-internet.fr [195.36.133.92]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA04823 for ; Tue, 15 May 2001 00:57:28 +0200 (MET DST) Message-ID: <3B006288.7EC6ED84@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 00:56:08 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Andreas Romeyke wrote:
> Hello YG,
>
> > That is the node of the problem.
> > I can do stuff, incl. manual, SW and documentation, but
> >  - i can't do everything alone,
> >  - other people need a common ground on which we can communicate.
>
> The main communication should be transfered via a mailinglist. We need
> one(!) server to store files and documents.

yup, storage is ok, even though i don't have time to update everything.
The problem (the "common ground") is the RTL coding tool. If i used
Alliance and you used Electric, we wouldn't be able to "communicate",
that means : debug and enhance each other's code.

> > my short term todo list includes : cleanup of the Oekonux conference
> > files and preparation of files for HAL. I meet Lionel this week-end
> > and i hope that the f-cpu database will be setup.
> > We have a few weeks to reorganise all the project.
> > I hope that at least some lurkers will wake up...
>
> My short TODO:
>
> - closing translation of YG-Patches of Manual (YG-patch should be an
> official manual)
> - sending questions/bugreports generated from YG-Manual to YG
> - find a solution for branding and sponsoring f-cpu via GAOS
> e.V. (end of discussion is coming soon (to 16 july)
> - a German lecture about f-cpu-project in Leipzig
> - thinking about shifter again
good luck !

> YG-Manual todo:
>
> - adding list of abbreviations
> - fixing bugs

i should also add a few FAQ items.

Damn ! i wish i was paid for doing all that stuff !!!
i'd be happy to do everything but i have to find some
money for the coming year.

something else to do : i have to setup a better "todo" system.

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
The Public Record Portal!
 First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 01:07:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00911 for ; Tue, 15 May 2001 18:06:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:06:59 +0200 (MEST) Received: (qmail 31549 invoked by uid 0); 14 May 2001 23:18:34 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx06) with SMTP; 14 May 2001 23:18:34 -0000 X-eGroups-Return: sentto-1101623-2790-989882313-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by jk.egroups.com with NNFMP; 14 May 2001 23:18:33 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 14 May 2001 23:18:32 -0000 Received: (qmail 5217 invoked from network); 14 May 2001 23:18:29 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 14 May 2001 23:18:29 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 14 May 2001 23:18:29 -0000 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA00775 for ; Mon, 14 May 2001 17:18:26 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B006524.B9E0BFDA@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3B006288.7EC6ED84@f-cpu.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 14 May 2001 17:07:16 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Yann Guidon wrote:

> yup, storage is ok, even though i don't have time to update everything.
> The problem (the "common ground") is the RTL coding tool. If i used
> Alliance and you used Electric, we wouldn't be able to "communicate",
> that means : debug and enhance each other's code.

Funny I thought VHDL was a standard.  I guess it is like C compilers:
Standard C until you change to another brand of CPU..
Big USERS like INTEL most likely have there own In-House design
software.The Reason I said electric looks better is that it has got
a new macro library for it.( I have not used it ) All the other Free design
software have outdated libraries. With the standard CMOS gate model your
software is only good for about .2u ( the latest technology ). With CMOS gates
smaller than that
soon this crop Free Software will be outdated.

> > > my short term todo list includes : cleanup of the Oekonux conference
> > > files and preparation of files for HAL. I meet Lionel this week-end
> > > and i hope that the f-cpu database will be setup.
> > > We have a few weeks to reorganise all the project.
> > > I hope that at least some lurkers will wake up...
Good luck.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Michael Riepe Tue May 15 02:54:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00920 for ; Tue, 15 May 2001 18:07:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:02 +0200 (MEST) Received: (qmail 29955 invoked by uid 0); 15 May 2001 00:55:20 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx15) with SMTP; 15 May 2001 00:55:20 -0000 X-eGroups-Return: sentto-1101623-2791-989888116-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ej.egroups.com with NNFMP; 15 May 2001 00:55:17 -0000 X-Sender: michael@stud.uni-hannover.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 00:55:15 -0000 Received: (qmail 23724 invoked from network); 15 May 2001 00:54:35 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 15 May 2001 00:54:35 -0000 Received: from unknown (HELO tribble.stud.uni-hannover.de) (130.75.232.90) by mta1 with SMTP; 15 May 2001 00:54:34 -0000 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02985; Tue, 15 May 2001 02:54:42 +0200 Message-ID: <20010515025442.35818@thrai.stud.uni-hannover.de> To: f-cpu@yahoogroups.com References: <3B006288.7EC6ED84@f-cpu.org> <3B006524.B9E0BFDA@jetnet.ab.ca> X-Mailer: Mutt 0.84e In-Reply-To: <3B006524.B9E0BFDA@jetnet.ab.ca>; from Ben Franchuk on Mon, May 14, 2001 at 05:07:16PM -0600 From: Michael Riepe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 02:54:42 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, May 14, 2001 at 05:07:16PM -0600, Ben Franchuk wrote:
[...]
> Funny I thought VHDL was a standard.  I guess it is like C compilers:
> Standard C until you change to another brand of CPU..

Worse.  You should have seen what Synopsys did with my VHDL code...

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 07:36:34 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00923 for ; Tue, 15 May 2001 18:07:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:03 +0200 (MEST) Received: (qmail 3961 invoked by uid 0); 15 May 2001 05:36:44 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx006-rz3) with SMTP; 15 May 2001 05:36:44 -0000 X-eGroups-Return: sentto-1101623-2792-989905001-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by c9.egroups.com with NNFMP; 15 May 2001 05:36:41 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 05:36:40 -0000 Received: (qmail 96775 invoked from network); 15 May 2001 05:36:39 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 15 May 2001 05:36:39 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta3 with SMTP; 15 May 2001 05:36:37 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA18388 for ; Tue, 15 May 2001 08:36:36 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B006524.B9E0BFDA@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 08:36:34 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, 14 May 2001, Ben Franchuk wrote:

> Funny I thought VHDL was a standard.  I guess it is like C compilers:
> Standard C until you change to another brand of CPU..

VHDL is standard, but only subset of it is supported in the
synthesizers. Usually the good (and expensive) synthesizer support quite
big parts of the VHDL standard. The cheaper ones cut some corners. I have
seen at least drafts of a standard that specified what is synthesizable
VHDL (you can't expect pointers to work in HW etc.). Usually this is not a
problem if the VHDL coders have some experience, they can avoid the
dangerous areas. If you know what Synopsys DC can do, usually all other
commercial (that have some market share) synthesizers can do the same.

> software.The Reason I said electric looks better is that it has got
> a new macro library for it.( I have not used it ) All the other Free design
> software have outdated libraries. With the standard CMOS gate model your
> software is only good for about .2u ( the latest technology ). With CMOS gates
> smaller than that
> soon this crop Free Software will be outdated.

Electric is just a schematics and layout tool. I hope no one hopes to make
whole f-cpu with schematics (maybe it will be ready 2100 :)). Probably
some ALU stuff, datapath etc. must be manually layouted but all the other
stuff can be synthesizable.

The Free software is already outdated :) Current ASIC designs that are
under design are targeted for 0.10-0.18u processes. Those are deep
submicron technology and require signal integrity simulations, power
simulations and other quite exotic things. The layout is far from trivial
nowadays.

As I see it the layout job is going more and more to the vendors. It is
just becoming too difficult to manage if the company does couple of
designs a year. And the tools are astronomically expensive.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 07:43:42 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00926 for ; Tue, 15 May 2001 18:07:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:04 +0200 (MEST) Received: (qmail 24058 invoked by uid 0); 15 May 2001 05:44:01 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx010-rz3) with SMTP; 15 May 2001 05:44:01 -0000 X-eGroups-Return: sentto-1101623-2793-989905439-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 15 May 2001 05:43:59 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 05:43:58 -0000 Received: (qmail 62277 invoked from network); 15 May 2001 05:43:44 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 May 2001 05:43:44 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 15 May 2001 05:43:44 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA20237 for ; Tue, 15 May 2001 08:43:43 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <20010515025442.35818@thrai.stud.uni-hannover.de> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 08:43:42 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Michael Riepe wrote:

> > Funny I thought VHDL was a standard.  I guess it is like C compilers:
> > Standard C until you change to another brand of CPU..
>
> Worse.  You should have seen what Synopsys did with my VHDL code...

Usually if the results are really bad the coder should look in to the
mirror :) Synopsys DC at least creates very consistently the code the user
coded and wanted. Synthesizable code has to be coded quite carefully, you
just can't throw miscallenious code to the synthesizer. It will either
refuse to synthesize it or it can create hughe blocks out of simple
functionality.

There is still long way to really working behavioral synthesis :)

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Tue May 15 10:31:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00950 for ; Tue, 15 May 2001 18:07:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:10 +0200 (MEST) Received: (qmail 22401 invoked by uid 0); 15 May 2001 08:31:12 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx10) with SMTP; 15 May 2001 08:31:12 -0000 X-eGroups-Return: sentto-1101623-2794-989915471-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 15 May 2001 08:31:11 -0000 X-Sender: NICOLAS.BOULAY@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 08:31:10 -0000 Received: (qmail 65425 invoked from network); 15 May 2001 08:31:09 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 15 May 2001 08:31:09 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta3 with SMTP; 15 May 2001 08:31:09 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Tue, 15 May 2001 08:31:20 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105150831.147e@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 08:31:20 GMT Reply-To: f-cpu@yahoogroups.com Subject: Rep:Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
[...]
> Funny I thought VHDL was a standard.  I guess it is
like C compilers:
> Standard C until you change to another brand of
CPU..

Worse.  You should have seen what Synopsys did with
my VHDL code...


-> ;p
We should write a report on what is not supported by
synopsys.

nicO

--
Michael "Tired" Riepe
<Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Matringe Tue May 15 10:40:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00953 for ; Tue, 15 May 2001 18:07:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:11 +0200 (MEST) Received: (qmail 21305 invoked by uid 0); 15 May 2001 08:38:14 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx010-rz3) with SMTP; 15 May 2001 08:38:14 -0000 X-eGroups-Return: sentto-1101623-2795-989915891-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 15 May 2001 08:38:12 -0000 X-Sender: nicolas.matringe@IPricot.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 08:38:09 -0000 Received: (qmail 59193 invoked from network); 15 May 2001 08:38:08 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 May 2001 08:38:08 -0000 Received: from unknown (HELO excalibur.dotcom.fr) (195.154.74.11) by mta1 with SMTP; 15 May 2001 08:38:08 -0000 Received: from IPricot.com (pc116.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id IAA10468 for ; Tue, 15 May 2001 08:38:06 GMT X-To: Message-ID: <3B00EB6E.BB2E6C79@IPricot.com> Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: fr,en To: f-cpu@yahoogroups.com References: <200105150831.147e@lh00.opsion.fr> X-eGroups-From: Nicolas Matringe From: Nicolas Matringe MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 10:40:14 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: Rep:Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N nicolas.boulay@ifrance.com wrote:
>

> > Worse.  You should have seen what Synopsys did with
> > my VHDL code...
>
> We should write a report on what is not supported by
> synopsys.

Never heard "It's not a bug, it's a feature" ?
Common saying about DC though...

--
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Tue May 15 10:44:25 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00959 for ; Tue, 15 May 2001 18:07:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Tue, 15 May 2001 18:07:13 +0200 (MEST) Received: (qmail 9202 invoked by uid 0); 15 May 2001 08:44:17 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx14) with SMTP; 15 May 2001 08:44:17 -0000 X-eGroups-Return: sentto-1101623-2796-989916256-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 15 May 2001 08:44:16 -0000 X-Sender: NICOLAS.BOULAY@ifrance.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 08:44:15 -0000 Received: (qmail 8941 invoked from network); 15 May 2001 08:44:14 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 15 May 2001 08:44:14 -0000 Received: from unknown (HELO lh00.opsion.fr) (212.73.208.226) by mta1 with SMTP; 15 May 2001 08:44:14 -0000 Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Tue, 15 May 2001 08:44:25 GMT Send-By: 194.3.122.154 with Mozilla/4.5 [en] (X11; I; SunOS 5.7 sun4u) To: Message-id: <200105150844.19ee@lh00.opsion.fr> From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 08:44:25 GMT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Rep: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -----Message d'origine-----
De: Kim Enkovaara <kenkovaa@cc.hut.fi>
A: f-cpu@yahoogroups.com
Date: 15/05/01
Objet:

Subject: Re: [f-cpu] about the EDA server(s) [quite
longuish]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 15 May 2001, Michael Riepe wrote:

> > Funny I thought VHDL was a standard.  I guess it
is like C compilers:
> > Standard C until you change to another brand of
CPU..
>
> Worse.  You should have seen what Synopsys did with
my VHDL code...

Usually if the results are really bad the coder
should look in to the
mirror :) Synopsys DC at least creates very
consistently the code the user
coded and wanted. Synthesizable code has to be coded
quite carefully, you
just can't throw miscallenious code to the
synthesizer. It will either
refuse to synthesize it or it can create hughe blocks
out of simple
functionality.

There is still long way to really working behavioral
synthesis :)

-> Most of the time, it's the fauls of stupid front
end compiler. I don't understand why generate are so
badly supported.
- no generate while loop
- only integer type in generate, so no boolean !.
- Don't supporte multiarray vector !
- ...

nicO

=====================================================
========================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi |
Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            |
curved-space fault in
02630 Espoo         |                      |
write-only file system


------------------------ Yahoo! Groups Sponsor
---------------------~-~>
Become a member FREE at
http://www.searchdatabase.com?Offer=yahoo5 today.
Save time finding the best Database Development and
Management information available on the Internet.
Our targeted search engine and dedicated editorial
staff "cut out the clutter" by aggregating the best
links and the most relevant database news for you
every day.
http://us.click.yahoo.com/_w3RtC/rGiCAA/bT0EAA/CYAVlB
/TM
-----------------------------------------------------
----------------_->



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 17:45:00 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00293 for ; Wed, 16 May 2001 17:34:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:34:46 +0200 (MEST) Received: (qmail 7566 invoked by uid 0); 15 May 2001 16:04:09 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx009-rz3) with SMTP; 15 May 2001 16:04:09 -0000 X-eGroups-Return: sentto-1101623-2797-989942645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 15 May 2001 16:04:08 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 16:04:04 -0000 Received: (qmail 66328 invoked from network); 15 May 2001 16:02:16 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 May 2001 16:02:16 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 15 May 2001 16:02:15 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA04130 for ; Tue, 15 May 2001 10:02:13 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B014EFC.6A2D5BD9@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 09:45:00 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> On Mon, 14 May 2001, Ben Franchuk wrote:
>
> > Funny I thought VHDL was a standard.  I guess it is like C compilers:
> > Standard C until you change to another brand of CPU..
>
> VHDL is standard, but only subset of it is supported in the
> synthesizers. Usually the good (and expensive) synthesizer support quite
> big parts of the VHDL standard. The cheaper ones cut some corners. I have
> seen at least drafts of a standard that specified what is synthesizable
> VHDL (you can't expect pointers to work in HW etc.). Usually this is not a
> problem if the VHDL coders have some experience, they can avoid the
> dangerous areas. If you know what Synopsys DC can do, usually all other
> commercial (that have some market share) synthesizers can do the same.

Is there a VHDL subset that everybody compiles?
What I don't like about High Level Hardware Languages is that you often
don't have a good mapping to the final hardware, or be able to use features
of the hardware with out non-standard features.

> > software.The Reason I said electric looks better is that it has got
> > a new macro library for it.( I have not used it ) All the other Free design
> > software have outdated libraries. With the standard CMOS gate model your
> > software is only good for about .2u ( the latest technology ). With CMOS gates
> > smaller than that
> > soon this crop Free Software will be outdated.
>
> Electric is just a schematics and layout tool. I hope no one hopes to make
> whole f-cpu with schematics (maybe it will be ready 2100 :)).

No it does have VHDL as well.
What is wrong with schematics ( other than a pain to revise )?
With schematics you see what you get, one feature I like.

> Probably
> some ALU stuff, datapath etc. must be manually layouted but all the other
> stuff can be synthesizable.
That sounds like 50% manual work.

> The Free software is already outdated :) Current ASIC designs that are
> under design are targeted for 0.10-0.18u processes. Those are deep
> submicron technology and require signal integrity simulations, power
> simulations and other quite exotic things. The layout is far from trivial
> nowadays.

While layout is "black magic" remember the this is the first hardware
draft.Get the F-cpu to run then tweak it for speed.


> As I see it the layout job is going more and more to the vendors. It is
> just becoming too difficult to manage if the company does couple of
> designs a year. And the tools are astronomically expensive.

But then not many people are building real CPU's on a small budget. I can count
them
all on one hand. I have my toes for the people with FPGA's too.:-)

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jeff Davies Tue May 15 19:38:03 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00317 for ; Wed, 16 May 2001 17:34:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:34:52 +0200 (MEST) Received: (qmail 28425 invoked by uid 0); 15 May 2001 17:41:39 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx04) with SMTP; 15 May 2001 17:41:39 -0000 X-eGroups-Return: sentto-1101623-2798-989948484-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 15 May 2001 17:41:24 -0000 X-Sender: jeff.davies@chrystal.co.uk X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 15 May 2001 17:41:23 -0000 Received: (qmail 9506 invoked from network); 15 May 2001 17:41:00 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 15 May 2001 17:41:00 -0000 Received: from unknown (HELO xne-ntsvr2.chrystal.co.uk) (213.235.29.33) by mta2 with SMTP; 15 May 2001 17:41:00 -0000 Received: by xne-ntsvr2.chrystal.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 18:38:04 +0100 Message-ID: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> To: "'f-cpu@egroups.com'" X-Mailer: Internet Mail Service (5.5.2653.19) From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 18:38:03 +0100 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N I agree with whygee regarding the re-organisation of the project.
Integrating with something like opencores, could produce a decent library.

So far, we have been talking of VHDL only. Perhaps we ought to consider
creating an XML superlanguage which can be transformed into VHDL or
ABEL etc. I'm sure there is cruft in VHDL that can be removed.

This XML language could be called something like EDA-XML
eg:   <MODULE NAME="4-INPUT-NAND">
              <EXTERNAL-NODE-LIST>
                      <NODE NAME="D0"/>
                      <NODE NAME="D1"/>
                      <NODE NAME="D2"/>
                      <NODE NAME="D3"/>
                      <NODE NAME="OUT"/>
              </EXTERNAL-NODE-LIST>
        <INTERNAL-NODE-LIST>
            <NODE NAME="I0">
            <NODE NAME="I1">     
        </INTERNAL-NODE-LIST>
        <COMPONENT-LIST>
              <COMPONENT NAME="2-INPUT-AND">
                    <NODE STDNAME="IN0" CONNECT-TO="D0">
                    <NODE STDNAME="IN1" CONNECT-TO="D1">
                    <NODE STDNAME="OUT0" CONNECT-TO="I0">
            </COMPONENT>
              <COMPONENT NAME="2-INPUT-AND">
                    <NODE STDNAME="IN2" CONNECT-TO="D2">
                    <NODE STDNAME="IN3" CONNECT-TO="D3">
                    <NODE STDNAME="OUT0" CONNECT-TO="I1">
            </COMPONENT>
              <COMPONENT NAME="2-INPUT-AND">
                    <NODE STDNAME="IN0" CONNECT-TO="I0">
                    <NODE STDNAME="IN1" CONNECT-TO="I1">
                    <NODE STDNAME="OUT0" CONNECT-TO="OUT">
            </COMPONENT>
        </COMPONENT-LIST>
       </MODULE>

I'd like to keep the language to the bare minimum, just a node-connection
language.
For behaviour, a seperate language (accessed through XML Namespaces) would
be
embedded in EDA-XML component definitions. Note the above assumes that all
programs at least
understand the basic 2-INPUT-AND as a starting point.

NOTE: there is no distinction between in and out and tristate, since
electrically an output
impendance != 0 and input impedance != infinity.


Personally, these are the tools I think would get the job done: (note the
tools listed below might be
adapter/warped from existing tools. Working in XML with transformation would
allow simultaneous use
of VHDL and other hardware languages. (simulate using a VHDL tool, compile
using ABEL tool).

0. XML repository/database. <working on it - mine's called GNU-DART
(document atom repository and transformation),
as are so many others> This is just very much like CVS.

1. Schematic Layout tool.
(could be a modified gEDA).
Outputs EDA-XML.

Note: EDA-XML can be transformed into VHDL, ABEL, SVG (xml vector graphics
format), HTML, PDF and so forth.

2. Library of standard parts - eg: 8 INPUT AND.
This library is in EDA-XML, and facilitates the conversion of the macro
cells used in your design into primitives.
(either AND, OR, or NAND I guess, NAND, I imagine is most used.

3. Macro expansion tool. Takes 1, replaces each macro cell with primitives.
(in fact GNU-DART does this)
just like a macro preprocessor when you're compiling c++.

4. Logical empirical reduction engine. Or whatever you want to call it. This
takes the Logical net (after macro
expansion) , and performs boolean optimisations using karnaugh map algorithm
etc etc.

5. Circuit simulation.
Take whatever free software is out there, review all, try to integrate bits
into a decent simulator.
a. Binary only
b. More detailed. (analog).

6. Conversion to Physical layout:
For bare sea of gates this is pretty easy, a bit more difficult for FPGA or
eg. TTL.
Since (in the more difficult case) you have to use standard hardware cells
and try to fit the
circuit optimally using fixed resources in the case of FPGA, or unlimited
resources in the case of TTL.
Also contains Circuit board/FPGA/Sea-of-gates autoroute. This tries to
connect the hardware blobs.
Often might need manual intervention to intelligently place components.

7. Verification.
The circuit as laid out in 6. is converted into a more detailed model
including track/wire capacitance and all that
stuff, perhaps with component tolerances built in. The enhanced model is fed
back into simulation (5), and the test
vectors re-run.


ANCILLIARY PROJECTS:
1. State machine design tool. I'm not convinced drawing a diagram is the
best way (eg Xilinx foundation), and certainly the
ABEL state machine language is not great, personally I'd just prefer to look
at a schematic, and have a table of 1s
and 0s on the screen (inputs, outputs, and next step number). Hell stick the
table output in a "Rom" and then
run it through <4. Logical Empirical Reduction Engine).

2. A free FPGA design.  wasn't it michael who had some thoughts on this.
Might as well stick the initial files (even docs)
in CVS, and let someone else build on it.

3. Free SVGA controller etc etc etc.

Well if no-one else is interested, I'll start work on these after GNU-DART
etc.

Jeff Davies
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 20:51:20 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00362 for ; Wed, 16 May 2001 17:35:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:16 +0200 (MEST) Received: (qmail 19325 invoked by uid 0); 15 May 2001 18:51:56 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx14) with SMTP; 15 May 2001 18:51:56 -0000 X-eGroups-Return: sentto-1101623-2799-989952714-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hj.egroups.com with NNFMP; 15 May 2001 18:51:55 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 18:51:54 -0000 Received: (qmail 662 invoked from network); 15 May 2001 18:51:22 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 15 May 2001 18:51:22 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 15 May 2001 18:51:22 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id VAA20208 for ; Tue, 15 May 2001 21:51:21 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B014EFC.6A2D5BD9@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 21:51:20 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Ben Franchuk wrote:

> Is there a VHDL subset that everybody compiles?

If I remember correctyly this standard definies syntesizable
subset of VHDL "1076.6-1999 IEEE Standard for VHDL Register Transfer Level
(RTL) Synthesis 1999". Some tools support bigger subset, but the standard
defines the common ground. The standard was done by the EDA vendors so it
reflects the reality quite well.

> What I don't like about High Level Hardware Languages is that you often
> don't have a good mapping to the final hardware, or be able to use features
> of the hardware with out non-standard features.

I know quite well what the RTL code will look like in the HW. You
can't just code randomly and check what happens. There are recommeded
structures how to code state machines etc. and if you code with those
guidlines the tools regognize the state machines and can add additional
optimizations to them etc. Also memories are automatically inferred is
proper coding style is used etc. There are some suprises when the
synthesizer optimizes better than I could even guess. For example Synplify
uses shift registers in Xilinx Virtex parts in quite exotic places.

> > Electric is just a schematics and layout tool. I hope no one hopes to make
> > whole f-cpu with schematics (maybe it will be ready 2100 :)).
>
> No it does have VHDL as well.

As far as i understood it only can use VHDL netlist import/export. I might
be wrong, I have just browsed the website. Netlist is schematics :)

> What is wrong with schematics ( other than a pain to revise )?
> With schematics you see what you get, one feature I like.

They are just too difficult to manage in big projects and very time
consuming to produce. 30 kgate chips already are something like 5cm pile
on schematics in A4 format. Just think what 1M gate design would look
like, few meters of paper. I have seen how all people try to vanish when
someone starts to talk about the old schematics designs and digging out
some information out of them. Also current designers are not anymore
familiar with schematics, it just black magic for us. We can see the
structures in HDL, but won't notice that some exotic tricks in the
schematics that do some nice functions.

Well to be honest also HDL code can be huge mess, as bad as the
schematics. Usually worst HDL codes are from the beginning of 90s when
coders tried to do HDL like they did schematics and draw schematics in
just other format.

> > Probably
> > some ALU stuff, datapath etc. must be manually layouted but all the other
> > stuff can be synthesizable.
> That sounds like 50% manual work.

ALU is not so big part of the chip timewise (well if it is done full
custom then it consumed much time :)). It consumes much gates, but
is very straightforward thing. Control logic is the hard part. And it
might be wise to use ALU related hard macros from the vendor also, those
are usually instantiated to the HDL code directly and then placed only in
the layout process.

> While layout is "black magic" remember the this is the first hardware
> draft.Get the F-cpu to run then tweak it for speed.

With deep submicron even working chips require black magic :) But I guess
these thing are quite far in the future. FPGA version is much easier in
the beginning.


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 21:22:36 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00381 for ; Wed, 16 May 2001 17:35:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:19 +0200 (MEST) Received: (qmail 23019 invoked by uid 0); 15 May 2001 19:23:49 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx18) with SMTP; 15 May 2001 19:23:49 -0000 X-eGroups-Return: sentto-1101623-2800-989954620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 15 May 2001 19:23:42 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 19:23:39 -0000 Received: (qmail 20890 invoked from network); 15 May 2001 19:22:42 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 May 2001 19:22:42 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta3 with SMTP; 15 May 2001 19:22:41 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id WAA30874 for ; Tue, 15 May 2001 22:22:37 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: "'f-cpu@egroups.com'" In-Reply-To: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 22:22:36 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Jeff Davies wrote:

> So far, we have been talking of VHDL only. Perhaps we ought to consider
> creating an XML superlanguage which can be transformed into VHDL or
> ABEL etc. I'm sure there is cruft in VHDL that can be removed.
....
> I'd like to keep the language to the bare minimum, just a node-connection
> language.
> For behaviour, a seperate language (accessed through XML Namespaces) would
> be
> embedded in EDA-XML component definitions. Note the above assumes that all
> programs at least
> understand the basic 2-INPUT-AND as a starting point.

Are you really going to do the whole CPU with schematics. It was the way
chips were done in the 80s. VHDL netlists are just one way to present the
information at the lowest possible level. And I even prefer verilog in the
netlists because it is much faster to simulate at netlist level.

The real power of Verilog/VHDL is in the higer level RTL descriptions that
are not describing the actual physical implementation but the
functionality in readable format. The synthesizer then creates "optimal"
implementation for the selected platform.

You can maybe get some speed more with schematics (or loose if you can't
create optimal structures), but I don't think it is worth it. In 0.13u
processes you can build something like 60 levels of logic and that still
runs with 600-700MHz frequency without big effort.


> 2. Library of standard parts - eg: 8 INPUT AND.
> This library is in EDA-XML, and facilitates the conversion of the macro
> cells used in your design into primitives.
> (either AND, OR, or NAND I guess, NAND, I imagine is most used.

If the first phase is FPGA how do you plan to present all different
configurable LUTs in the netlist.

> 4. Logical empirical reduction engine. Or whatever you want to call it. This
> takes the Logical net (after macro
> expansion) , and performs boolean optimisations using karnaugh map algorithm
> etc etc.
....>
> 6. Conversion to Physical layout:
> For bare sea of gates this is pretty easy, a bit more difficult for FPGA or
> eg. TTL.
> Since (in the more difficult case) you have to use standard hardware cells
> and try to fit the
> circuit optimally using fixed resources in the case of FPGA, or unlimited
> resources in the case of TTL.
> Also contains Circuit board/FPGA/Sea-of-gates autoroute. This tries to
> connect the hardware blobs.
> Often might need manual intervention to intelligently place components.

OK, fcpu project is also trying to create synthesis, routing and layout
tools. Maybe we should focus to do the CPU not the tools. Only few
firms have managed to do good synthesizers so it is not a trivial task.
Propably fcpu is a small project compared to good optimizing synthesizer.

New synthesizer are not even doing the big optimization at the gate level.
Older tools usually converted first everything to gates and then started
to optimize that mess. New tools first try to find behavioral functions
>from the RTL and then do first optimization rounds at that level. Only
after that hey start converting everything to gates. This is especially
important with FPGAs that have quite complex primary elements.

> stuff, perhaps with component tolerances built in. The enhanced model is fed
> back into simulation (5), and the test
> vectors re-run.

> ANCILLIARY PROJECTS:
> 1. State machine design tool. I'm not convinced drawing a diagram is the
> best way (eg Xilinx foundation), and certainly the
> ABEL state machine language is not great, personally I'd just prefer to look
> at a schematic, and have a table of 1s
> and 0s on the screen (inputs, outputs, and next step number). Hell stick the
> table output in a "Rom" and then
> run it through <4. Logical Empirical Reduction Engine).

Well there are also good state machine tools that output high level VHDL
or Verilog that synthesizes well. I think designing state machine with
schematics is stupidity, but that is my opinion. How long does it take to
change for example normal state machine to one hot encoded with
schematics. I can do that in few minutes with high level description. I
just add hint for the synthesizer how to synthesize the state machine and
press run button. Or just let it to select the optimal implementation to
satisfy the constraints.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 20:38:10 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00390 for ; Wed, 16 May 2001 17:35:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:22 +0200 (MEST) Received: (qmail 16288 invoked by uid 0); 15 May 2001 19:46:15 -0000 Received: from mr.egroups.com (208.50.144.80) by mx0.gmx.net (mx17) with SMTP; 15 May 2001 19:46:15 -0000 X-eGroups-Return: sentto-1101623-2801-989955972-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mr.egroups.com with NNFMP; 15 May 2001 19:46:15 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 19:46:11 -0000 Received: (qmail 75456 invoked from network); 15 May 2001 19:44:22 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 15 May 2001 19:44:22 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 15 May 2001 19:44:22 -0000 Received: from jetnet.ab.ca (dialin41.jetnet.ab.ca [207.153.6.41]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA09670 for ; Tue, 15 May 2001 13:44:19 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B017792.41DA852D@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 12:38:10 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> I know quite well what the RTL code will look like in the HW. You
> can't just code randomly and check what happens. There are recommeded
> structures how to code state machines etc. and if you code with those
> guidlines the tools regognize the state machines and can add additional
> optimizations to them etc. Also memories are automatically inferred is
> proper coding style is used etc. There are some suprises when the
> synthesizer optimizes better than I could even guess. For example Synplify
> uses shift registers in Xilinx Virtex parts in quite exotic places.

I never use STATE machines!!!! ( Other than counters )
I never use Xilinix !!!! ( I use the Other BRAND )
I never use VHDL!! ( mostly do to the fact I don't have a free compiler)

Often the problem the person writing the hardware, does not
know the hardware details of the hardware to write optimized
code. While in many cases the compiler can do a good job,It can't guess
at the over all picture.
In order to get a current compiling FPGA design to run at a reasonable
speed I enabled the fast ripple carry for the data path. It also
enabled fast carry logic for all my counters used for a on-chip
uart. Now to get it to route I have write my own ripple counter
for all the small counters used. While this has nothing to do
with VHDL it does show you need to know the quirks of the hardware.

> They are just too difficult to manage in big projects and very time
> consuming to produce. 30 kgate chips already are something like 5cm pile
> on schematics in A4 format. Just think what 1M gate design would look
> like, few meters of paper. I have seen how all people try to vanish when
> someone starts to talk about the old schematics designs and digging out
> some information out of them.

I am talking about hierarchical schematic design here.
A flattened netlist can be very large.

> Also current designers are not anymore
> familiar with schematics, it just black magic for us. We can see the
> structures in HDL, but won't notice that some exotic tricks in the
> schematics that do some nice functions.

You mean like short circuiting the output discrete flip/flop to reset it,
>
> Well to be honest also HDL code can be huge mess, as bad as the
> schematics. Usually worst HDL codes are from the beginning of 90s when
> coders tried to do HDL like they did schematics and draw schematics in
> just other format.

> ALU is not so big part of the chip timewise (well if it is done full
> custom then it consumed much time :)). It consumes much gates, but
> is very straightforward thing. Control logic is the hard part. And it
> might be wise to use ALU related hard macros from the vendor also, those
> are usually instantiated to the HDL code directly and then placed only in
> the layout process.

Now days most designs ( other than Intel clones )
are RISC thus have simple decoding or can use a ROM macro, but still
you need to know the final hardware used.

> > While layout is "black magic" remember the this is the first hardware
> > draft.Get the F-cpu to run then tweak it for speed.
>
> With deep submicron even working chips require black magic :) But I guess
> these thing are quite far in the future. FPGA version is much easier in
> the beginning.

Unless the FPGA needed is over $2K. Then a semi-custom gate array
design may look better.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 21:03:43 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00393 for ; Wed, 16 May 2001 17:35:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:23 +0200 (MEST) Received: (qmail 2394 invoked by uid 0); 15 May 2001 20:11:13 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx27) with SMTP; 15 May 2001 20:11:13 -0000 X-eGroups-Return: sentto-1101623-2802-989957464-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 15 May 2001 20:11:08 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 20:11:02 -0000 Received: (qmail 31704 invoked from network); 15 May 2001 20:09:54 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 15 May 2001 20:09:54 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 15 May 2001 20:09:54 -0000 Received: from jetnet.ab.ca (dialin41.jetnet.ab.ca [207.153.6.41]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA10252 for ; Tue, 15 May 2001 14:09:52 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B017D8F.B68A2D42@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 13:03:43 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:

> You can maybe get some speed more with schematics (or loose if you can't
> create optimal structures), but I don't think it is worth it. In 0.13u
> processes you can build something like 60 levels of logic and that still
> runs with 600-700MHz frequency without big effort.

Schematics are just a coding style. Any speed or lack there of can be do to
a lot of factors. For a 24 bit cpu I am designing I expect if I went full
custom that would be 12 gate delays for the 24 bit adder and 12 gate delays in
misc. logic. Assuming that in .13 u logic you have 150 ps for a gate delay ( I
have
no idea what the real delay is) that is 3.6 ns or 280 MHZ.

> New synthesizer are not even doing the big optimization at the gate level.
> Older tools usually converted first everything to gates and then started
> to optimize that mess. New tools first try to find behavioral functions
> from the RTL and then do first optimization rounds at that level. Only
> after that hey start converting everything to gates. This is especially
> important with FPGAs that have quite complex primary elements.

I expect the wave of the future is small FPGA blocks of logic
in custom designs as interconnect is becoming the the problem
rather than gate count. Ripple adder here, counter there, glue logic around.

> Well there are also good state machine tools that output high level VHDL
> or Verilog that synthesizes well. I think designing state machine with
> schematics is stupidity, but that is my opinion. How long does it take to
> change for example normal state machine to one hot encoded with
> schematics.

A good bit of work with schematics, but even VHDL needs to be updated too
as your state vector changes size from [n] to [n^2].

> I can do that in few minutes with high level description. I
> just add hint for the synthesizer how to synthesize the state machine and
> press run button. Or just let it to select the optimal implementation to
> satisfy the constraints.

I have problems getting things to run with out optimal optimization.
You need 25% more for optimization in FPGA's.
Ben
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 22:16:56 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00399 for ; Wed, 16 May 2001 17:35:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:24 +0200 (MEST) Received: (qmail 3121 invoked by uid 0); 15 May 2001 20:18:01 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx010-rz3) with SMTP; 15 May 2001 20:18:01 -0000 X-eGroups-Return: sentto-1101623-2803-989957878-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 15 May 2001 20:18:00 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 20:17:57 -0000 Received: (qmail 57033 invoked from network); 15 May 2001 20:16:59 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 May 2001 20:16:59 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 15 May 2001 20:16:58 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id XAA17676 for ; Tue, 15 May 2001 23:16:57 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B017792.41DA852D@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:16:56 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Ben Franchuk wrote:

> I never use STATE machines!!!! ( Other than counters )

I wonder what you designing :) State machines are the basic building
block of chips.

> I never use Xilinix !!!! ( I use the Other BRAND )

Altera? Xilinx seems to be the tecnology leader currently. Especially
their toolchain is much faster. It not trivial and fast process to
place&route 1M gate design to the biggest available FPGA.

> Often the problem the person writing the hardware, does not
> know the hardware details of the hardware to write optimized
> code. While in many cases the compiler can do a good job,It can't guess
> at the over all picture.

The synthesizer are actually quite good nowadays. They can create quite
good view what the design is doing at high level.

> In order to get a current compiling FPGA design to run at a reasonable
> speed I enabled the fast ripple carry for the data path. It also
> enabled fast carry logic for all my counters used for a on-chip
> uart. Now to get it to route I have write my own ripple counter
> for all the small counters used. While this has nothing to do
> with VHDL it does show you need to know the quirks of the hardware.

I would just write (in pseudo code)
if i=7 then i=0 else i=i+1;

For example synplify will in the RTL view show that I wrote a counter and
then uses the best possible techniques to implement that in the target
platform. I don't want to know the dirty details of the architecture
and twiddle with the carry chains etc. if the synthesizer does that
automatically. Also the design can be cganged to new platform wihtout any
problems and if it has counter hard macros they are automatically used.

> > They are just too difficult to manage in big projects and very time
> > consuming to produce. 30 kgate chips already are something like 5cm pile
> > on schematics in A4 format. Just think what 1M gate design would look
> > like, few meters of paper. I have seen how all people try to vanish when
> > someone starts to talk about the old schematics designs and digging out
> > some information out of them.
>
> I am talking about hierarchical schematic design here.
> A flattened netlist can be very large.

I was also talking about hierarchical netlists, flattened netlist not
usually readable even :). Those chips were state of the art and biggest
one could create on silicon and done by experienced designers. They are
not just hacks.

> > familiar with schematics, it just black magic for us. We can see the
> > structures in HDL, but won't notice that some exotic tricks in the
> > schematics that do some nice functions.
>
> You mean like short circuiting the output discrete flip/flop to reset it,

Usually the tricks are related to clocking. For example all the exotic
ways to do different kind of edge detectors that also did some tricks at
the same time etc. I'm not very familiar with those I have succesfully
avoided the old schematics.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Tue May 15 22:28:14 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00405 for ; Wed, 16 May 2001 17:35:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:26 +0200 (MEST) Received: (qmail 3679 invoked by uid 0); 15 May 2001 20:29:23 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx08) with SMTP; 15 May 2001 20:29:23 -0000 X-eGroups-Return: sentto-1101623-2804-989958562-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 15 May 2001 20:29:22 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 20:29:21 -0000 Received: (qmail 59697 invoked from network); 15 May 2001 20:28:17 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 15 May 2001 20:28:17 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 15 May 2001 20:28:17 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id XAA21477 for ; Tue, 15 May 2001 23:28:15 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B017D8F.B68A2D42@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:28:14 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Ben Franchuk wrote:

> custom that would be 12 gate delays for the 24 bit adder and 12 gate delays in
> misc. logic. Assuming that in .13 u logic you have 150 ps for a gate delay ( I
> have no idea what the real delay is) that is 3.6 ns or 280 MHZ.

150ps for 0.13u sounds too big. I think it is in the ballpark of 10-30ps.
Well the gate delay is not the big factor, routing delays are the biggest
factor in deep submicron.

> I expect the wave of the future is small FPGA blocks of logic
> in custom designs as interconnect is becoming the the problem
> rather than gate count. Ripple adder here, counter there, glue logic around.

Already few vendors are selling small embedded FPGA blocks inside the
ASIC. But the usage for those is usually interfaces etc. that might need
changes when the standards are still evolving. It's easy to fix the
things with FPGA blocks inside the logic. The problem is that the FPGA
blocks are not very fast compared to the other logic so they are not
suitable for all the jobs. Also it's difficult to figure out where to put
those blocks.

> > schematics is stupidity, but that is my opinion. How long does it take to
> > change for example normal state machine to one hot encoded with
> > schematics.
>
> A good bit of work with schematics, but even VHDL needs to be updated too
> as your state vector changes size from [n] to [n^2].

Nope. In VHDL just create a type that has all the states named and use the
names directly for the states. The synthesizer creates the real
implementation of the state vector structures. Some tools might require
hints to tell what are the state variables created from the type.


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
Find your next Apartment HERE!
Looking for Apartments? Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 21:44:06 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00417 for ; Wed, 16 May 2001 17:35:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:29 +0200 (MEST) Received: (qmail 6889 invoked by uid 0); 15 May 2001 20:51:00 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx002-rz3) with SMTP; 15 May 2001 20:51:00 -0000 X-eGroups-Return: sentto-1101623-2805-989959858-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ef.egroups.com with NNFMP; 15 May 2001 20:50:59 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 20:50:57 -0000 Received: (qmail 23603 invoked from network); 15 May 2001 20:50:18 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 15 May 2001 20:50:18 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 15 May 2001 20:50:17 -0000 Received: from jetnet.ab.ca (dialin41.jetnet.ab.ca [207.153.6.41]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA11344 for ; Tue, 15 May 2001 14:50:14 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B018706.38CA2F65@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 13:44:06 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> On Tue, 15 May 2001, Ben Franchuk wrote:
>
> > custom that would be 12 gate delays for the 24 bit adder and 12 gate delays in
> > misc. logic. Assuming that in .13 u logic you have 150 ps for a gate delay ( I
> > have no idea what the real delay is) that is 3.6 ns or 280 MHZ.
>
> 150ps for 0.13u sounds too big. I think it is in the ballpark of 10-30ps.
> Well the gate delay is not the big factor, routing delays are the biggest
> factor in deep submicron.

True, don't forget small gates have very little drive
so you have to have a lot of buffering for I/O. What good
is a 5 GHZ clock if your I/O pins are at .5 GHZ?

> Nope. In VHDL just create a type that has all the states named and use the
> names directly for the states. The synthesizer creates the real
> implementation of the state vector structures. Some tools might require
> hints to tell what are the state variables created from the type.

My cpu design has about 50 states. I tend to write st[n]
a lot. While my cpu has a lot of states,most states have rather
random logic thus I don't think of in terms of  a regular
state machine.
Ben.

PS. This a one Hot state machine if you need to know.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 22:04:05 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00426 for ; Wed, 16 May 2001 17:35:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:31 +0200 (MEST) Received: (qmail 14176 invoked by uid 0); 15 May 2001 21:11:34 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx24) with SMTP; 15 May 2001 21:11:34 -0000 X-eGroups-Return: sentto-1101623-2806-989961093-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c9.egroups.com with NNFMP; 15 May 2001 21:11:33 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 21:11:32 -0000 Received: (qmail 90024 invoked from network); 15 May 2001 21:10:15 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 15 May 2001 21:10:15 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 15 May 2001 21:10:15 -0000 Received: from jetnet.ab.ca (dialin41.jetnet.ab.ca [207.153.6.41]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA11820 for ; Tue, 15 May 2001 15:10:12 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B018BB5.CE4447C1@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 14:04:05 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> > I never use Xilinix !!!! ( I use the Other BRAND )
>
> Altera? Xilinx seems to be the tecnology leader currently. Especially
> their toolchain is much faster. It not trivial and fast process to
> place&route 1M gate design to the biggest available FPGA.

  At the time I got my FPGA kit (last fall)  Xilinx did not have
free development software, or could I find a Xilinx FPGA kit that could
afford and use a 84 pin PLCC. If I were designing from scratch I would use a
QuickLogic anti-fuse FPGA as a PROM programmed for this kit is about the
same price as FPGA. ($100?)
>
> I would just write (in pseudo code)
> if i=7 then i=0 else i=i+1;

  I can't use '+' as that would use fast carry.
  I used a setable Polynomial counter as I only needed a freq divider
  not a binary counter.
 
>
> I was also talking about hierarchical netlists, flattened netlist not
> usually readable even :). Those chips were state of the art and biggest
> one could create on silicon and done by experienced designers. They are
> not just hacks.


They would be smaller if designers sold computer chips not the
PR people. :-)  Marketing wants another bell and whistle.

> Usually the tricks are related to clocking. For example all the exotic
> ways to do different kind of edge detectors that also did some tricks at
> the same time etc. I'm not very familiar with those I have succesfully
> avoided the old schematics.

Other than a few gated resets I tend to have synchronous designs. Why
take chances.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue May 15 23:17:09 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00432 for ; Wed, 16 May 2001 17:35:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:32 +0200 (MEST) Received: (qmail 13636 invoked by uid 0); 15 May 2001 21:17:10 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx09) with SMTP; 15 May 2001 21:17:10 -0000 X-eGroups-Return: sentto-1101623-2807-989961428-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by cj.egroups.com with NNFMP; 15 May 2001 21:17:09 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 21:17:07 -0000 Received: (qmail 13519 invoked from network); 15 May 2001 21:16:29 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 15 May 2001 21:16:29 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.155) by mta1 with SMTP; 15 May 2001 21:16:27 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D02949E4C for ; Tue, 15 May 2001 23:17:09 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B019CD5.A433E42F@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:17:09 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Jeff Davies a =E9crit :
>
> I agree with whygee regarding the re-organisation of the project.
> Integrating with something like opencores, could produce a decent libr= ary.
>
> So far, we have been talking of VHDL only. Perhaps we ought to conside= r
> creating an XML superlanguage which can be transformed into VHDL or > ABEL etc. I'm sure there is cruft in VHDL that can be removed.
>
> This XML language could be called something like EDA-XML
> eg:   <MODULE NAME=3D"4-INPUT-NAND">
>            = ;   <EXTERNAL-NODE-LIST>
>            = ;           <NODE NAME= =3D"D0"/>
>            = ;           <NODE NAME= =3D"D1"/>
>            = ;           <NODE NAME= =3D"D2"/>
>            = ;           <NODE NAME= =3D"D3"/>
>            = ;           <NODE NAME= =3D"OUT"/>
>            = ;   </EXTERNAL-NODE-LIST>
>           <INTERN= AL-NODE-LIST>
>            = ;     <NODE NAME=3D"I0">
>            = ;     <NODE NAME=3D"I1">
>           </INTER= NAL-NODE-LIST>
>           <COMPON= ENT-LIST>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN0" CONNECT-TO=3D"D0">
>            = ;             &= lt;NODE STDNAME=3D"IN1" CONNECT-TO=3D"D1">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"I0">
>            = ;     </COMPONENT>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN2" CONNECT-TO=3D"D2">
>            = ;             &= lt;NODE STDNAME=3D"IN3" CONNECT-TO=3D"D3">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"I1">
>            = ;     </COMPONENT>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN0" CONNECT-TO=3D"I0">
>            = ;             &= lt;NODE STDNAME=3D"IN1" CONNECT-TO=3D"I1">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"OUT">
>            = ;     </COMPONENT>
>           </COMPO= NENT-LIST>
>        </MODULE>
>
> I'd like to keep the language to the bare minimum, just a node-connect= ion
> language.
> For behaviour, a seperate language (accessed through XML Namespaces) w= ould
> be
> embedded in EDA-XML component definitions. Note the above assumes that= all
> programs at least
> understand the basic 2-INPUT-AND as a starting point.
>
> NOTE: there is no distinction between in and out and tristate, since > electrically an output
> impendance !=3D 0 and input impedance !=3D infinity.
>
> Personally, these are the tools I think would get the job done: (note = the
> tools listed below might be
> adapter/warped from existing tools. Working in XML with transformation= would
> allow simultaneous use
> of VHDL and other hardware languages. (simulate using a VHDL tool, com= pile
> using ABEL tool).
>
> 0. XML repository/database. <working on it - mine's called GNU-DART=
> (document atom repository and transformation),
> as are so many others> This is just very much like CVS.
>
> 1. Schematic Layout tool.
> (could be a modified gEDA).
> Outputs EDA-XML.
>
> Note: EDA-XML can be transformed into VHDL, ABEL, SVG (xml vector grap= hics
> format), HTML, PDF and so forth.
>
> 2. Library of standard parts - eg: 8 INPUT AND.
> This library is in EDA-XML, and facilitates the conversion of the macr= o
> cells used in your design into primitives.
> (either AND, OR, or NAND I guess, NAND, I imagine is most used.
>
> 3. Macro expansion tool. Takes 1, replaces each macro cell with primit= ives.
> (in fact GNU-DART does this)
> just like a macro preprocessor when you're compiling c++.
>
> 4. Logical empirical reduction engine. Or whatever you want to call it= . This
> takes the Logical net (after macro
> expansion) , and performs boolean optimisations using karnaugh map alg= orithm
> etc etc.
>
> 5. Circuit simulation.
> Take whatever free software is out there, review all, try to integrate= bits
> into a decent simulator.
> a. Binary only
> b. More detailed. (analog).
>
> 6. Conversion to Physical layout:
> For bare sea of gates this is pretty easy, a bit more difficult for FP= GA or
> eg. TTL.
> Since (in the more difficult case) you have to use standard hardware c= ells
> and try to fit the
> circuit optimally using fixed resources in the case of FPGA, or unlimi= ted
> resources in the case of TTL.
> Also contains Circuit board/FPGA/Sea-of-gates autoroute. This tries to=
> connect the hardware blobs.
> Often might need manual intervention to intelligently place components= .
>
> 7. Verification.
> The circuit as laid out in 6. is converted into a more detailed model<= BR> > including track/wire capacitance and all that
> stuff, perhaps with component tolerances built in. The enhanced model = is fed
> back into simulation (5), and the test
> vectors re-run.
>
> ANCILLIARY PROJECTS:
> 1. State machine design tool. I'm not convinced drawing a diagram is t= he
> best way (eg Xilinx foundation), and certainly the
> ABEL state machine language is not great, personally I'd just prefer t= o look
> at a schematic, and have a table of 1s
> and 0s on the screen (inputs, outputs, and next step number). Hell sti= ck the
> table output in a "Rom" and then
> run it through <4. Logical Empirical Reduction Engine).
>
> 2. A free FPGA design.  wasn't it michael who had some thoughts o= n this.
> Might as well stick the initial files (even docs)
> in CVS, and let someone else build on it.
>
> 3. Free SVGA controller etc etc etc.
>
> Well if no-one else is interested, I'll start work on these after GNU-= DART
> etc.
>
> Jeff Davies
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue May 15 23:18:31 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00435 for ; Wed, 16 May 2001 17:35:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:34 +0200 (MEST) Received: (qmail 14866 invoked by uid 0); 15 May 2001 21:18:16 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx009-rz3) with SMTP; 15 May 2001 21:18:16 -0000 X-eGroups-Return: sentto-1101623-2808-989961495-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 15 May 2001 21:18:15 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 21:18:14 -0000 Received: (qmail 96772 invoked from network); 15 May 2001 21:17:51 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 15 May 2001 21:17:51 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.155) by mta1 with SMTP; 15 May 2001 21:17:49 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id CE1789E4C for ; Tue, 15 May 2001 23:18:31 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B019D27.D0859C79@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:18:31 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Why creating a new language which look like thousand of other and much
more low level than usual HDL ?

nicO


Jeff Davies a =E9crit :
>
> I agree with whygee regarding the re-organisation of the project.
> Integrating with something like opencores, could produce a decent libr= ary.
>
> So far, we have been talking of VHDL only. Perhaps we ought to conside= r
> creating an XML superlanguage which can be transformed into VHDL or > ABEL etc. I'm sure there is cruft in VHDL that can be removed.
>
> This XML language could be called something like EDA-XML
> eg:   <MODULE NAME=3D"4-INPUT-NAND">
>            = ;   <EXTERNAL-NODE-LIST>
>            = ;           <NODE NAME= =3D"D0"/>
>            = ;           <NODE NAME= =3D"D1"/>
>            = ;           <NODE NAME= =3D"D2"/>
>            = ;           <NODE NAME= =3D"D3"/>
>            = ;           <NODE NAME= =3D"OUT"/>
>            = ;   </EXTERNAL-NODE-LIST>
>           <INTERN= AL-NODE-LIST>
>            = ;     <NODE NAME=3D"I0">
>            = ;     <NODE NAME=3D"I1">
>           </INTER= NAL-NODE-LIST>
>           <COMPON= ENT-LIST>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN0" CONNECT-TO=3D"D0">
>            = ;             &= lt;NODE STDNAME=3D"IN1" CONNECT-TO=3D"D1">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"I0">
>            = ;     </COMPONENT>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN2" CONNECT-TO=3D"D2">
>            = ;             &= lt;NODE STDNAME=3D"IN3" CONNECT-TO=3D"D3">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"I1">
>            = ;     </COMPONENT>
>            = ;       <COMPONENT NAME=3D"2-INPUT-AN= D">
>            = ;             &= lt;NODE STDNAME=3D"IN0" CONNECT-TO=3D"I0">
>            = ;             &= lt;NODE STDNAME=3D"IN1" CONNECT-TO=3D"I1">
>            = ;             &= lt;NODE STDNAME=3D"OUT0" CONNECT-TO=3D"OUT">
>            = ;     </COMPONENT>
>           </COMPO= NENT-LIST>
>        </MODULE>
>
> I'd like to keep the language to the bare minimum, just a node-connect= ion
> language.
> For behaviour, a seperate language (accessed through XML Namespaces) w= ould
> be
> embedded in EDA-XML component definitions. Note the above assumes that= all
> programs at least
> understand the basic 2-INPUT-AND as a starting point.
>
> NOTE: there is no distinction between in and out and tristate, since > electrically an output
> impendance !=3D 0 and input impedance !=3D infinity.
>
> Personally, these are the tools I think would get the job done: (note = the
> tools listed below might be
> adapter/warped from existing tools. Working in XML with transformation= would
> allow simultaneous use
> of VHDL and other hardware languages. (simulate using a VHDL tool, com= pile
> using ABEL tool).
>
> 0. XML repository/database. <working on it - mine's called GNU-DART=
> (document atom repository and transformation),
> as are so many others> This is just very much like CVS.
>
> 1. Schematic Layout tool.
> (could be a modified gEDA).
> Outputs EDA-XML.
>
> Note: EDA-XML can be transformed into VHDL, ABEL, SVG (xml vector grap= hics
> format), HTML, PDF and so forth.
>
> 2. Library of standard parts - eg: 8 INPUT AND.
> This library is in EDA-XML, and facilitates the conversion of the macr= o
> cells used in your design into primitives.
> (either AND, OR, or NAND I guess, NAND, I imagine is most used.
>
> 3. Macro expansion tool. Takes 1, replaces each macro cell with primit= ives.
> (in fact GNU-DART does this)
> just like a macro preprocessor when you're compiling c++.
>
> 4. Logical empirical reduction engine. Or whatever you want to call it= . This
> takes the Logical net (after macro
> expansion) , and performs boolean optimisations using karnaugh map alg= orithm
> etc etc.
>
> 5. Circuit simulation.
> Take whatever free software is out there, review all, try to integrate= bits
> into a decent simulator.
> a. Binary only
> b. More detailed. (analog).
>
> 6. Conversion to Physical layout:
> For bare sea of gates this is pretty easy, a bit more difficult for FP= GA or
> eg. TTL.
> Since (in the more difficult case) you have to use standard hardware c= ells
> and try to fit the
> circuit optimally using fixed resources in the case of FPGA, or unlimi= ted
> resources in the case of TTL.
> Also contains Circuit board/FPGA/Sea-of-gates autoroute. This tries to=
> connect the hardware blobs.
> Often might need manual intervention to intelligently place components= .
>
> 7. Verification.
> The circuit as laid out in 6. is converted into a more detailed model<= BR> > including track/wire capacitance and all that
> stuff, perhaps with component tolerances built in. The enhanced model = is fed
> back into simulation (5), and the test
> vectors re-run.
>
> ANCILLIARY PROJECTS:
> 1. State machine design tool. I'm not convinced drawing a diagram is t= he
> best way (eg Xilinx foundation), and certainly the
> ABEL state machine language is not great, personally I'd just prefer t= o look
> at a schematic, and have a table of 1s
> and 0s on the screen (inputs, outputs, and next step number). Hell sti= ck the
> table output in a "Rom" and then
> run it through <4. Logical Empirical Reduction Engine).
>
> 2. A free FPGA design.  wasn't it michael who had some thoughts o= n this.
> Might as well stick the initial files (even docs)
> in CVS, and let someone else build on it.
>
> 3. Free SVGA controller etc etc etc.
>
> Well if no-one else is interested, I'll start work on these after GNU-= DART
> etc.
>
> Jeff Davies
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue May 15 23:34:45 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00444 for ; Wed, 16 May 2001 17:35:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:37 +0200 (MEST) Received: (qmail 29589 invoked by uid 0); 15 May 2001 21:34:09 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx25) with SMTP; 15 May 2001 21:34:09 -0000 X-eGroups-Return: sentto-1101623-2809-989962447-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 15 May 2001 21:34:08 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 21:34:06 -0000 Received: (qmail 56939 invoked from network); 15 May 2001 21:34:05 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 15 May 2001 21:34:05 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.155) by mta2 with SMTP; 15 May 2001 21:34:03 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BD83A9E4C for ; Tue, 15 May 2001 23:34:45 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B01A0F5.67F07C78@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3B018706.38CA2F65@jetnet.ab.ca> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:34:45 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Kim Enkovaara wrote:
> >
> > On Tue, 15 May 2001, Ben Franchuk wrote:
> >
> > > custom that would be 12 gate delays for the 24 bit adder and= 12 gate delays in
> > > misc. logic. Assuming that in .13 u logic you have 150 ps fo= r a gate delay ( I
> > > have no idea what the real delay is) that is 3.6 ns or 280 M= HZ.
> >
> > 150ps for 0.13u sounds too big. I think it is in the ballpark of = 10-30ps.
> > Well the gate delay is not the big factor, routing delays are the= biggest
> > factor in deep submicron.
>
> True, don't forget small gates have very little drive
> so you have to have a lot of buffering for I/O. What good
> is a 5 GHZ clock if your I/O pins are at .5 GHZ?
>

There is nothing in common between a 'usual gate' and a io transistor.
usualy W/L are around 1 to 10 for buffer to go outside, it's over 150
with a larger L to supporte 3.3 V compare to the 1.5 V in the core. But
a io pad is much more than an inverter. There is something as a schmit
trigger plus a static discharge protection and so one.

I think that a nand gate from a .15=B5m technology need 15 ps.

nicO
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Nicolas Tue May 15 23:37:30 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00447 for ; Wed, 16 May 2001 17:35:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:38 +0200 (MEST) Received: (qmail 30101 invoked by uid 0); 15 May 2001 21:37:13 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx02) with SMTP; 15 May 2001 21:37:13 -0000 X-eGroups-Return: sentto-1101623-2810-989962631-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 15 May 2001 21:37:12 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 21:37:10 -0000 Received: (qmail 44463 invoked from network); 15 May 2001 21:36:49 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 15 May 2001 21:36:49 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.155) by mta3 with SMTP; 15 May 2001 21:36:48 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8A8EC9E4C for ; Tue, 15 May 2001 23:37:30 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B01A19A.1C5257E5@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> <3AFFA497.57103444@jetnet.ab.ca> <3B005268.C3F5119D@seul.org> <3AFFD7CB.1AF1E4CC@jetnet.ab.ca> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 23:37:30 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N Ben Franchuk a =E9crit :
>
> Nicolas wrote:
> >
> > Ben Franchuk a =E9crit :
> >
> > But we need rtl & gates simulator and a synthetiser, so how d= o you do
> > that ?
>
> That is not a server problem.Electric is looking to be a better FREE > tool but you are right there are no GOOD FREE tools out there.
>
> > Alliance is big and [in part] GPL but never forget that it didn't= manage
> > process in vhdl...
> >
>
> What tools out there are really poor. I have a FPGA design software (W= 95)
> and every so often it can't meet set/hold times because of clock skew.=
> This is the MAIN global clock that runs to all the macro cells, that > I have no control over. With the same software I can't even get a repo= rt
> of delays in a useable format that I can use. This is a real problem > because I have 2 phase clock ( 6809 style ) delay calculations all exp= ect
> a single phase clock.
>

Synthetiser try too create your gate between  2 time barrer (flip-flop= ).
But there is always a limit ! So youre probleme isn't at all a
limitation in VHDL.


> I never use STATE machines!!!! ( Other than counters )
> I never use Xilinix !!!! ( I use the Other BRAND )
> I never use VHDL!! ( mostly do to the fact I don't have a free compile= r)
>
> Often the problem the person writing the hardware, does not
> know the hardware details of the hardware to write optimized
> code. While in many cases the compiler can do a good job,It can't gues= s
> at the over all picture.

Yes, can ! Most of the time you guess what could generate a synthetiser
with your code it's a kind of habit. With new submicronic technology you can't create by hand a netlist, there is so many timing rules ! I don't
even speak about layout rules.

> In order to get a current compiling FPGA design to run at a reasonable=
> speed I enabled the fast ripple carry for the data path. It also
> enabled fast carry logic for all my counters used for a on-chip
> uart. Now to get it to route I have write my own ripple counter
> for all the small counters used. While this has nothing to do
> with VHDL it does show you need to know the quirks of the hardware. >

That basic feature is, in all case, used by common vhdl compiler !

> Ben.
>
>
> --
> "We do not inherit our time on this planet from our parents... >  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
3D"www.debticated.com"
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Tue May 15 23:53:02 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00471 for ; Wed, 16 May 2001 17:35:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:44 +0200 (MEST) Received: (qmail 26102 invoked by uid 0); 15 May 2001 22:59:18 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx10) with SMTP; 15 May 2001 22:59:18 -0000 X-eGroups-Return: sentto-1101623-2811-989967557-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by b05.egroups.com with NNFMP; 15 May 2001 22:59:18 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 15 May 2001 22:59:16 -0000 Received: (qmail 51274 invoked from network); 15 May 2001 22:59:14 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 15 May 2001 22:59:14 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 15 May 2001 22:59:13 -0000 Received: from jetnet.ab.ca (dialin41.jetnet.ab.ca [207.153.6.41]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA14478 for ; Tue, 15 May 2001 16:59:11 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B01A53E.7722E189@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3AFF392C.C94B2F3A@f-cpu.org> <3AFFA497.57103444@jetnet.ab.ca> <3B005268.C3F5119D@seul.org> <3AFFD7CB.1AF1E4CC@jetnet.ab.ca> <3B01A19A.1C5257E5@seul.org> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 15:53:02 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Nicolas wrote:

> Yes, can ! Most of the time you guess what could generate a synthetiser
> with your code it's a kind of habit. With new submicronic technology you
> can't create by hand a netlist, there is so many timing rules ! I don't
> even speak about layout rules.

You can do anything by hand, mind you I would use a calculator
as I hate math. :-)  It is not that I would want to do things by hand
but it is un-wise to forget how to do things by hand.

>
> > In order to get a current compiling FPGA design to run at a reasonable
> > speed I enabled the fast ripple carry for the data path. It also
> > enabled fast carry logic for all my counters used for a on-chip
> > uart. Now to get it to route I have write my own ripple counter
> > for all the small counters used. While this has nothing to do
> > with VHDL it does show you need to know the quirks of the hardware.
> >
>
> That basic feature is, in all case, used by common vhdl compiler !

Sorry but as the DESIGNER I wanted that feature off at that time.
I have a very small margin on the FPGA chip I have and I needed to try
several things to get the logic to fit. A SLOW design here is better
than NO design.

Ben.
I have 0.75 cm of schematics for my CPU, umm how many gates
is that? :-)

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Wed May 16 07:58:59 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00504 for ; Wed, 16 May 2001 17:35:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Wed, 16 May 2001 17:35:52 +0200 (MEST) Received: (qmail 21921 invoked by uid 0); 16 May 2001 05:59:07 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx23) with SMTP; 16 May 2001 05:59:07 -0000 X-eGroups-Return: sentto-1101623-2812-989992743-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hk.egroups.com with NNFMP; 16 May 2001 05:59:04 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 05:59:02 -0000 Received: (qmail 35579 invoked from network); 16 May 2001 05:59:02 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 16 May 2001 05:59:02 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 16 May 2001 05:59:01 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA27376 for ; Wed, 16 May 2001 08:59:00 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B01A53E.7722E189@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 08:58:59 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tue, 15 May 2001, Ben Franchuk wrote:

> > with your code it's a kind of habit. With new submicronic technology you
> > can't create by hand a netlist, there is so many timing rules ! I don't
> > even speak about layout rules.
>
> You can do anything by hand, mind you I would use a calculator
> as I hate math. :-)  It is not that I would want to do things by hand
> but it is un-wise to forget how to do things by hand.

In theory you could create the netlist by hand. But the netlist for P&R
during layout would be completely different. The layout tools take the
nelist and start to optimize it by rearranging things, by adding extra
logic to create required delay to meet hold times etc. This is a
netlist you can't create by hand and it will be the netlist to use for
the layout. Then there are formal methods to check the netlist equality
etc. The layout process is nowadays very difficult and involves big amount
of steps. Fortunately I don't have to do that.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed May 16 06:09:29 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01176 for ; Thu, 17 May 2001 11:36:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:05 +0200 (MEST) Received: (qmail 23474 invoked by uid 0); 16 May 2001 15:47:35 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx010-rz3) with SMTP; 16 May 2001 15:47:35 -0000 X-eGroups-Return: sentto-1101623-2813-990028049-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 16 May 2001 15:47:32 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 15:47:27 -0000 Received: (qmail 757 invoked from network); 16 May 2001 15:46:04 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 16 May 2001 15:46:04 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 16 May 2001 15:46:03 -0000 Received: from jetnet.ab.ca (dialin34.jetnet.ab.ca [207.153.6.34]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA20468 for ; Wed, 16 May 2001 09:46:02 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B01FD79.FA10CA3A@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 15 May 2001 22:09:29 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] about the EDA server(s) [quite longuish] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N > In theory you could create the netlist by hand. But the netlist for P&R
> during layout would be completely different. The layout tools take the
> nelist and start to optimize it by rearranging things, by adding extra
> logic to create required delay to meet hold times etc. This is a
> netlist you can't create by hand and it will be the netlist to use for
> the layout. Then there are formal methods to check the netlist equality
> etc. The layout process is nowadays very difficult and involves big amount
> of steps. Fortunately I don't have to do that.

However with FPGA's you have a lot of information hidden from the designer.
Other hardware  is a little better. If one can't view or adjust easily
data output how can one check or find errors in the compilation process?

>
> =============================================================================
> Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
> Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
> 02630 Espoo         |                      | write-only file system
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jecel Assumpcao Jr Thu May 17 00:38:37 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01222 for ; Thu, 17 May 2001 11:36:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:22 +0200 (MEST) Received: (qmail 29708 invoked by uid 0); 16 May 2001 21:38:57 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx03) with SMTP; 16 May 2001 21:38:57 -0000 X-eGroups-Return: sentto-1101623-2814-990049134-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hi.egroups.com with NNFMP; 16 May 2001 21:38:55 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 21:38:53 -0000 Received: (qmail 21525 invoked from network); 16 May 2001 21:38:29 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 16 May 2001 21:38:29 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta2 with SMTP; 16 May 2001 21:38:28 -0000 Received: from gandalf.merlintec.com (gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA31910 for ; Wed, 16 May 2001 19:49:00 -0300 Organization: Merlintec Computers X-Mailer: KMail [version 1.1.99] To: f-cpu@yahoogroups.com Message-Id: <01051618383702.00922@gandalf.merlintec.com> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 18:38:37 -0400 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N I have just tested 3 different free ($0) vhdl compilers for FPGAs with
a simple design I downloaded from the web:

   http://www.ultratechnology.com/p16vhdl.htm

I was surprised that it compiled directly with no more than a few
warning. The first compiler I used was XST in the Xilinx WebPACK
software suite. It estimated that the design would run at 42 MHz on a
-6 Spartan 2 chip. It needed 838 "blocks" and 359 flipflops. I was
unable to actually do the placement due to some kind of problem in the
"place related phase" (an illegal instruction error in msvcrt.dll).

With Leonardo Spectrum from Examplar I got a 49 MHz design on a -3 EP1K
chip using 781 logic cells and 305 flipflops.

With FPGA Express from Synopsys I got an 18 MHz design on a -1 EP1K
chip (ooops.... I hadn't noticed that this run didn't use the same chip
speed as the previous one - I'll fix this and try again later) using
849 LUTs and 347 flipflops.

The first software is from the Xilinx web site and the other two from
Altera. They all have limitations on the chip sizes they handle (so you
have to get the expensive versions for real jobs) but seemed very
reasonable otherwise. Not that I intend to let a compiler design chips
for me :-) and I prefer free in the GNU sense to no cost.

Chuck Moore has moved to 0.18 microns for his latest designs. He no
longer draws rectangles directly but instead is using Forth as his HDL
(symbolic layout rather than silicon compilation, however). If you have
a fast connection, you can see him tell all about it:

   http://www.ultratechnology.com/rmvideo.htm

-- Jecel
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jeff Davies Thu May 17 02:18:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01229 for ; Thu, 17 May 2001 11:36:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:24 +0200 (MEST) Received: (qmail 11443 invoked by uid 0); 16 May 2001 23:15:10 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx24) with SMTP; 16 May 2001 23:15:10 -0000 X-eGroups-Return: sentto-1101623-2815-990054908-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 16 May 2001 23:15:09 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 23:15:07 -0000 Received: (qmail 75873 invoked from network); 16 May 2001 23:15:04 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 16 May 2001 23:15:04 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta1 with SMTP; 16 May 2001 23:15:03 -0000 Received: from modem-105.oxygen.dialup.pol.co.uk ([62.136.7.105] helo=tara.tyrone) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 150AVS-0007lE-00 for f-cpu@yahoogroups.com; Thu, 17 May 2001 00:15:02 +0100 Organization: Hipparchus Systems Ltd To: f-cpu@yahoogroups.com X-Mailer: KMail [version 1.2] References: In-Reply-To: Message-Id: <01051701182702.01583@tara.tyrone> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 01:18:27 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tuesday 15 May 2001  8:22 pm, you wrote:
> On Tue, 15 May 2001, Jeff Davies wrote:
> > So far, we have been talking of VHDL only. Perhaps we ought to consider
> > creating an XML superlanguage which can be transformed into VHDL or
> > ABEL etc. I'm sure there is cruft in VHDL that can be removed.
>
> ....
> Are you really going to do the whole CPU with schematics. It was the way
> chips were done in the 80s. VHDL netlists are just one way to present the
> information at the lowest possible level. And I even prefer verilog in the
> netlists because it is much faster to simulate at netlist level.
>

I can't see why a hierchical schematic diagram is harder to understand than
VHDL netlists?  
Where as in VHDL you have subcomponents defined like subroutines in C,
in hierarchical schematic, your top level looks like your average diagram of
a cpu, but each Execution Unit black box can be designed as a seperate
schematic.. you can do this on xilinx alliance, so there is evidence of this
technique in the commercial world also.

>
> ===========================================================================
>== Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
> Vasamatie 1 C 16    | IRC: embo            | curved-space fault in 02630
> Espoo         |                      | write-only file system
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Sponsor

www.   

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jeff Davies Thu May 17 02:21:15 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01232 for ; Thu, 17 May 2001 11:36:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:25 +0200 (MEST) Received: (qmail 28231 invoked by uid 0); 16 May 2001 23:18:29 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx01) with SMTP; 16 May 2001 23:18:29 -0000 X-eGroups-Return: sentto-1101623-2816-990055086-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hp.egroups.com with NNFMP; 16 May 2001 23:18:10 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 23:18:06 -0000 Received: (qmail 89285 invoked from network); 16 May 2001 23:17:51 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 16 May 2001 23:17:51 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta2 with SMTP; 16 May 2001 23:17:51 -0000 Received: from modem-105.oxygen.dialup.pol.co.uk ([62.136.7.105] helo=tara.tyrone) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 150AY9-00088T-00 for f-cpu@yahoogroups.com; Thu, 17 May 2001 00:17:50 +0100 Organization: Hipparchus Systems Ltd To: f-cpu@yahoogroups.com X-Mailer: KMail [version 1.2] References: <3B017D8F.B68A2D42@jetnet.ab.ca> In-Reply-To: <3B017D8F.B68A2D42@jetnet.ab.ca> Message-Id: <01051701211503.01583@tara.tyrone> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 01:21:15 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tuesday 15 May 2001  8:03 pm, you wrote:
> Kim Enkovaara wrote:

>
>
> > Well there are also good state machine tools that output high level VHDL
> > or Verilog that synthesizes well. I think designing state machine with
> > schematics is stupidity, but that is my opinion. How long does it take to
> > change for example normal state machine to one hot encoded with
> > schematics.
>
Errm I think I said looking at a circuit diagram for the rest of the stuff,
and entering 1s and 0s in a table for signals, rather than the crappy way you
have to do it in ABEL etc.

Jeff Davies
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Jeff Davies Thu May 17 02:34:55 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01235 for ; Thu, 17 May 2001 11:36:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:26 +0200 (MEST) Received: (qmail 12442 invoked by uid 0); 16 May 2001 23:31:35 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx10) with SMTP; 16 May 2001 23:31:35 -0000 X-eGroups-Return: sentto-1101623-2817-990055893-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mo.egroups.com with NNFMP; 16 May 2001 23:31:34 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 16 May 2001 23:31:32 -0000 Received: (qmail 10135 invoked from network); 16 May 2001 23:31:32 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 16 May 2001 23:31:32 -0000 Received: from unknown (HELO cmailg1.svr.pol.co.uk) (195.92.195.171) by mta3 with SMTP; 16 May 2001 23:31:32 -0000 Received: from modem-105.oxygen.dialup.pol.co.uk ([62.136.7.105] helo=tara.tyrone) by cmailg1.svr.pol.co.uk with smtp (Exim 3.13 #0) id 150AlO-0001IG-00 for f-cpu@yahoogroups.com; Thu, 17 May 2001 00:31:30 +0100 Organization: Hipparchus Systems Ltd To: f-cpu@yahoogroups.com X-Mailer: KMail [version 1.2] References: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> <3B019D27.D0859C79@seul.org> In-Reply-To: <3B019D27.D0859C79@seul.org> Message-Id: <01051701345504.01583@tara.tyrone> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 01:34:55 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Tuesday 15 May 2001 10:18 pm, you wrote:
> Why creating a new language which look like thousand of other and much
> more low level than usual HDL ?
>
> nicO
>

EDA-XML itself is merely a node-list language, however you can embed other
behavioural XML derivates within it  (of various levels) using XML-namespaces.

XML has the  advantage of  a standard parsing method and structure control
(DTDs). This means you can edit using a tree editor (see Xeena or merlot),
both of which (and many many many others) sort of auto-generate forms for you
on the fly. So no longer are you programming your hardware using free format
text that then has to be parsed using a very specialised parser. This means
that compiler bugs are a thing of the past, and parsing is much much easier.
So instead of working on that shit, you can work on eg: making the sim
software actually work well, or the route work well.

I've also published an early Class-Programming XML language DTD with XSL to
convert to Java (very very rough and not much to it right now, but enough to
see how it will work).

Everything is going XML for exactly the reasons above, EDA will too. This is
my open source contribution. (also will fit in with DART very well).


Jeff Davies
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Yann Guidon Thu May 17 02:02:12 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01238 for ; Thu, 17 May 2001 11:36:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:27 +0200 (MEST) Received: (qmail 31759 invoked by uid 0); 17 May 2001 00:04:37 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx18) with SMTP; 17 May 2001 00:04:37 -0000 X-eGroups-Return: sentto-1101623-2818-990057874-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ei.egroups.com with NNFMP; 17 May 2001 00:04:35 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 00:04:33 -0000 Received: (qmail 98780 invoked from network); 17 May 2001 00:03:46 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 May 2001 00:03:46 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 17 May 2001 00:03:45 -0000 Received: from f-cpu.org (nas1-150.ras.club-internet.fr [195.36.192.150]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA02242 for ; Thu, 17 May 2001 02:03:30 +0200 (MET DST) Message-ID: <3B031504.39A52C10@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <813EC338FFF6D41185C000E018C5D2750D0340@xne-ntsvr2.chrystal.co.uk> <3B019D27.D0859C79@seul.org> <01051701345504.01583@tara.tyrone> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 02:02:12 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Jeff Davies wrote:
>
> On Tuesday 15 May 2001 10:18 pm, you wrote:
> > Why creating a new language which look like thousand of other and much
> > more low level than usual HDL ?
> >
> > nicO
>
> EDA-XML itself is merely a node-list language, however you can embed other
> behavioural XML derivates within it  (of various levels) using XML-namespaces.
<snip>
> Everything is going XML for exactly the reasons above, EDA will too. This is
> my open source contribution. (also will fit in with DART very well).

I was pleased to see some interesting activity on this list after the last mail
i sent. However, it seemed that it derived to a church fight, "i know" vs "why not"...

This mail is a good surprise and a good example : even though there are some
relatively good points against jeff's idea, mostly "yet another langage that
does what others do for decades", Jeff has stopped to speak and started to code.
I don't know what will happen, but that's better than nothing and if more people
did the same, one day, we would maybe get a decent alternative. We know that
we can't "compete" against existing SW, the solution is simply to write our own
rules for the game, no ?

> Jeff Davies
WHYGEE who's gotta code something before he becomes rotten...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Ben Franchuk Wed May 16 11:20:19 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01241 for ; Thu, 17 May 2001 11:36:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:28 +0200 (MEST) Received: (qmail 3362 invoked by uid 0); 17 May 2001 00:28:23 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx04) with SMTP; 17 May 2001 00:28:23 -0000 X-eGroups-Return: sentto-1101623-2819-990059287-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ej.egroups.com with NNFMP; 17 May 2001 00:28:08 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 00:28:06 -0000 Received: (qmail 28180 invoked from network); 17 May 2001 00:27:59 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 00:27:59 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 17 May 2001 00:27:58 -0000 Received: from jetnet.ab.ca (dialin49.jetnet.ab.ca [207.153.6.49]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA03244 for ; Wed, 16 May 2001 18:27:56 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B024653.C2EAC9DD@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <01051618383702.00922@gandalf.merlintec.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 03:20:19 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Jecel Assumpcao Jr wrote:
>
> I have just tested 3 different free ($0) vhdl compilers for FPGAs with
> a simple design I downloaded from the web:
>
>    http://www.ultratechnology.com/p16vhdl.htm
>
> -6 Spartan 2 chip. It needed 838 "blocks" and 359 flipflops. I was
> chip using 781 logic cells and 305 flipflops.
> 849 LUTs and 347 flipflops.

I got a regular CPU design 24 bits and a uart to fit into 539 logic cells
with creative SCHEMATICS!

> Chuck Moore has moved to 0.18 microns for his latest designs. He no
> longer draws rectangles directly but instead is using Forth as his HDL
> (symbolic layout rather than silicon compilation, however). If you have
> a fast connection, you can see him tell all about it:

I say quit YAPPING how good your product is if NOBODY can use it!
As long as Moore is making $$$ will he keep his product closed.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu May 17 08:37:41 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01250 for ; Thu, 17 May 2001 11:36:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:30 +0200 (MEST) Received: (qmail 26640 invoked by uid 0); 17 May 2001 06:40:28 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx010-rz3) with SMTP; 17 May 2001 06:40:28 -0000 X-eGroups-Return: sentto-1101623-2820-990081569-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fl.egroups.com with NNFMP; 17 May 2001 06:39:30 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 06:37:44 -0000 Received: (qmail 67966 invoked from network); 17 May 2001 06:37:43 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 06:37:43 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 06:37:43 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA23774 for ; Thu, 17 May 2001 09:37:42 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B024653.C2EAC9DD@jetnet.ab.ca> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 09:37:41 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 16 May 2001, Ben Franchuk wrote:

> > -6 Spartan 2 chip. It needed 838 "blocks" and 359 flipflops. I was
> > chip using 781 logic cells and 305 flipflops.
> > 849 LUTs and 347 flipflops.
>
> I got a regular CPU design 24 bits and a uart to fit into 539 logic cells
> with creative SCHEMATICS!

You have to remeber that each FPGA architecture has different architecture
in the basic element and they can't be compared directly. Even the gate
counts FPGA makers announce are quite different thing what usually is
understood with ASIC gates.


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu May 17 08:23:16 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01253 for ; Thu, 17 May 2001 11:36:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:31 +0200 (MEST) Received: (qmail 18109 invoked by uid 0); 17 May 2001 06:40:29 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx004-rz3) with SMTP; 17 May 2001 06:40:29 -0000 X-eGroups-Return: sentto-1101623-2822-990081627-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 17 May 2001 06:40:28 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 06:40:27 -0000 Received: (qmail 59667 invoked from network); 17 May 2001 06:23:19 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 17 May 2001 06:23:19 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 06:23:18 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA13198 for ; Thu, 17 May 2001 09:23:17 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <01051618383702.00922@gandalf.merlintec.com> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 09:23:16 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Wed, 16 May 2001, Jecel Assumpcao Jr wrote:

> I was surprised that it compiled directly with no more than a few
> warning. The first compiler I used was XST in the Xilinx WebPACK
> software suite. It estimated that the design would run at 42 MHz on a
> -6 Spartan 2 chip. It needed 838 "blocks" and 359 flipflops. I was
> unable to actually do the placement due to some kind of problem in the
> "place related phase" (an illegal instruction error in msvcrt.dll).

I ran the same source trough Synplify Pro (no P&R results, but the
eastimates are usually very good) . Here are the results (pipelining and
retiming enabled) I didn't consume many minutes to optimize the results.
But I tried to get speed with minor overconstraining.

Spartan2 XC2S30-6-CS144   77.8 MHz, 607 LUT (50MHz, 461LUT )
Altera   EP1K100-1-TC100  59.9 MHz, 576 LC
Altera   EP1K100-3-TC100  39.4 MHz, 576 LC

So there are some differences between the tools :)

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From Kim Enkovaara Thu May 17 08:30:27 2001 Return-Path: Received: from localhost (thomas@localhost [127.0.0.1]) by WintelPC.Potential (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA01256 for ; Thu, 17 May 2001 11:36:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.1.2) for thomas@localhost (single-drop); Thu, 17 May 2001 11:36:32 +0200 (MEST) Received: (qmail 21218 invoked by uid 0); 17 May 2001 06:41:14 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx08) with SMTP; 17 May 2001 06:41:14 -0000 X-eGroups-Return: sentto-1101623-2821-990081574-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ei.egroups.com with NNFMP; 17 May 2001 06:39:35 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 06:38:34 -0000 Received: (qmail 58543 invoked from network); 17 May 2001 06:30:30 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 May 2001 06:30:30 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 06:30:29 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA08571 for ; Thu, 17 May 2001 09:30:28 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <01051701182702.01583@tara.tyrone> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 09:30:27 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 17 May 2001, Jeff Davies wrote:

> I can't see why a hierchical schematic diagram is harder to understand than
> VHDL netlists?  
> Where as in VHDL you have subcomponents defined like subroutines in C,
> in hierarchical schematic, your top level looks like your average diagram of
> a cpu, but each Execution Unit black box can be designed as a seperate
> schematic.. you can do this on xilinx alliance, so there is evidence of this
> technique in the commercial world also.

I don't even look into the VHDL/EDIF netlists if there are no major
problems that lead me to think that the synthesizer is doing something
wrong. Netlists (EDIF, VHDL etc.) are just a way to transfer information
>from the synthesizer to P&R tools. I'm not doing those netlists by hand.
They are generated from high level VHDL descriptions by the synthesizer.

You are right that there are no major differences between schematics and
VHDL _netlists_. But when I talk VHDL as a design language I'm not talking
about netlists but high level descriptions (if a=1 then b=2 style).

Well I have seen Xilinx people quite often and they don't even talk about
the schematics design :) It's just a feature in the tools for those that
still want to do schematics. The big chips are done with higer level
tools. Only place where schematics are quite nice are HW based DSP
filters. It's quite easy to visualize the structure from the schematics,
but this is quite special field.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kenkovaa@cc.hut.fi Thu May 17 12:18:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KvW-0002Lf-00 for ; Wed, 23 May 2001 00:46:54 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:46:54 +0200 (CEST) Received: (qmail 15596 invoked by uid 0); 17 May 2001 10:18:43 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx01) with SMTP; 17 May 2001 10:18:43 -0000 X-eGroups-Return: sentto-1101623-2823-990094719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 17 May 2001 10:18:40 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 10:18:39 -0000 Received: (qmail 33599 invoked from network); 17 May 2001 10:18:38 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 10:18:38 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 10:18:38 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id NAA17468 for ; Thu, 17 May 2001 13:18:33 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <01051701211503.01583@tara.tyrone> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 13:18:30 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 17 May 2001, Jeff Davies wrote:

> > > schematics is stupidity, but that is my opinion. How long does it take to
> > > change for example normal state machine to one hot encoded with
> > > schematics.
> >
> Errm I think I said looking at a circuit diagram for the rest of the stuff,
> and entering 1s and 0s in a table for signals, rather than the crappy way you
> have to do it in ABEL etc.

I tought ABEL was dead :) Below is a example of automatically generated
state machine (Renoir 2000). The encoding of the states can be selected
during synthesis or with one pragma line to the code. I think the code is
quite readable and easy to understand. I removed all the comments the
tools does to fit the state machine into smaller space. The synthesis
tools show this as a state machine in their RTL view and even show the
normal bubble diagram. They start the optimization from that level.

The reason I'm talking about this is that the whole f-cpu must be designed
with same methodology. Mixed schematics and high level description only
makes the problem worse (with schematics I mean blocks made from
elementary components). My strong belief is that high level HDL
description is the way to go, it is the method big chips are done today.
There are even strong aspirations to go higher level languages than
Verilog/VHDL. Gates are almost free, you can make some extra gates if the
work gets done faster.


LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;

ENTITY Control IS
   PORT(
      clk   : IN     std_logic;
      d     : IN     unsigned (9 DOWNTO 0);
      reset : IN     std_logic;
      start : IN     std_logic;
      stop  : IN     std_logic;
      zero  : IN     std_logic;
      beep  : OUT    std_logic;
      clear : OUT    std_logic;
      hold  : OUT    std_logic;
      load  : OUT    std_logic
   );
END Control;

ARCHITECTURE fsm OF Control IS
   Constant ZEROS:unsigned:="0000000000";

   TYPE state_type IS
(flush,getkey,load_t,load_u,standby,alarm,counting,suspended,end_count);

   ATTRIBUTE state_vector : string;
   ATTRIBUTE state_vector OF fsm : architecture IS "current_state";

   SIGNAL current_state, next_state : state_type;
   SIGNAL beep_int : std_logic;

BEGIN
   clocked : PROCESS (clk,reset)
   BEGIN
      IF (reset = '1') THEN
         current_state <= flush;
         beep <= '0';
      ELSIF (clk'EVENT AND clk = '0') THEN
         current_state <= next_state;
         beep <= beep_int;
      END IF;

   END PROCESS clocked;

   nextstate : PROCESS (current_state,d,start,stop,zero)
   BEGIN
      CASE current_state IS
      WHEN flush =>
            next_state <= load_u;
      WHEN getkey =>
         IF (start='1') THEN
            next_state <= standby;
         ELSIF (d/=ZEROS) THEN
            next_state <= load_u;
         ELSIF (stop='1') THEN
            next_state <= flush;
         ELSE
            next_state <= getkey;
         END IF;
      WHEN load_t =>
         IF (d/=ZEROS) THEN
            next_state <= getkey;
         ELSE
            next_state <= load_t;
         END IF;
      WHEN load_u =>
            next_state <= load_t;
      WHEN standby =>
         IF (zero='1') THEN
            next_state <= alarm;
         ELSIF (start='1') THEN
            next_state <= counting;
         ELSE
            next_state <= standby;
         END IF;
      WHEN alarm =>
         IF (stop='1') THEN
            next_state <= end_count;
         ELSE
            next_state <= alarm;
         END IF;
      WHEN counting =>
         IF (zero='1') THEN
            next_state <= alarm;
         ELSIF (stop='1') THEN
            next_state <= suspended;
         ELSE
            next_state <= counting;
         END IF;
      WHEN suspended =>
         IF (stop='0') THEN
            next_state <= counting;
         ELSE
            next_state <= suspended;
         END IF;
      WHEN end_count =>
         IF (stop='1') THEN
            next_state <= flush;
         ELSE
            next_state <= end_count;
         END IF;
      WHEN OTHERS =>
         next_state <= flush;
      END CASE;

   END PROCESS nextstate;

   output : PROCESS (current_state)
   BEGIN
      beep_int <= '0';
      clear <= '0';
      hold <= '0';
      load <= '0';

      CASE current_state IS
      WHEN flush =>
         hold<='1';
         clear<='1';
         beep_int<='0';
      WHEN getkey =>
         hold<='1';
      WHEN load_t =>
         hold<='1';
      WHEN load_u =>
         hold<='1';
         load<='0';
      WHEN standby =>
         hold<='1';
      WHEN alarm =>
         hold<='1';
         clear<='1';
         beep_int<='1';
      WHEN suspended =>
         hold<='1';
      WHEN end_count =>
         hold<='1';
         clear<='1';
      WHEN OTHERS =>
         NULL;
      END CASE;
   END PROCESS output;
END fsm;


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kenkovaa@cc.hut.fi Thu May 17 12:18:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kvo-0002M1-00 for ; Wed, 23 May 2001 00:47:12 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:12 +0200 (CEST) Received: (qmail 15596 invoked by uid 0); 17 May 2001 10:18:43 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx01) with SMTP; 17 May 2001 10:18:43 -0000 X-eGroups-Return: sentto-1101623-2823-990094719-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 17 May 2001 10:18:40 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 10:18:39 -0000 Received: (qmail 33599 invoked from network); 17 May 2001 10:18:38 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 10:18:38 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 10:18:38 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id NAA17468 for ; Thu, 17 May 2001 13:18:33 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <01051701211503.01583@tara.tyrone> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 13:18:30 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 17 May 2001, Jeff Davies wrote:

> > > schematics is stupidity, but that is my opinion. How long does it take to
> > > change for example normal state machine to one hot encoded with
> > > schematics.
> >
> Errm I think I said looking at a circuit diagram for the rest of the stuff,
> and entering 1s and 0s in a table for signals, rather than the crappy way you
> have to do it in ABEL etc.

I tought ABEL was dead :) Below is a example of automatically generated
state machine (Renoir 2000). The encoding of the states can be selected
during synthesis or with one pragma line to the code. I think the code is
quite readable and easy to understand. I removed all the comments the
tools does to fit the state machine into smaller space. The synthesis
tools show this as a state machine in their RTL view and even show the
normal bubble diagram. They start the optimization from that level.

The reason I'm talking about this is that the whole f-cpu must be designed
with same methodology. Mixed schematics and high level description only
makes the problem worse (with schematics I mean blocks made from
elementary components). My strong belief is that high level HDL
description is the way to go, it is the method big chips are done today.
There are even strong aspirations to go higher level languages than
Verilog/VHDL. Gates are almost free, you can make some extra gates if the
work gets done faster.


LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;

ENTITY Control IS
   PORT(
      clk   : IN     std_logic;
      d     : IN     unsigned (9 DOWNTO 0);
      reset : IN     std_logic;
      start : IN     std_logic;
      stop  : IN     std_logic;
      zero  : IN     std_logic;
      beep  : OUT    std_logic;
      clear : OUT    std_logic;
      hold  : OUT    std_logic;
      load  : OUT    std_logic
   );
END Control;

ARCHITECTURE fsm OF Control IS
   Constant ZEROS:unsigned:="0000000000";

   TYPE state_type IS
(flush,getkey,load_t,load_u,standby,alarm,counting,suspended,end_count);

   ATTRIBUTE state_vector : string;
   ATTRIBUTE state_vector OF fsm : architecture IS "current_state";

   SIGNAL current_state, next_state : state_type;
   SIGNAL beep_int : std_logic;

BEGIN
   clocked : PROCESS (clk,reset)
   BEGIN
      IF (reset = '1') THEN
         current_state <= flush;
         beep <= '0';
      ELSIF (clk'EVENT AND clk = '0') THEN
         current_state <= next_state;
         beep <= beep_int;
      END IF;

   END PROCESS clocked;

   nextstate : PROCESS (current_state,d,start,stop,zero)
   BEGIN
      CASE current_state IS
      WHEN flush =>
            next_state <= load_u;
      WHEN getkey =>
         IF (start='1') THEN
            next_state <= standby;
         ELSIF (d/=ZEROS) THEN
            next_state <= load_u;
         ELSIF (stop='1') THEN
            next_state <= flush;
         ELSE
            next_state <= getkey;
         END IF;
      WHEN load_t =>
         IF (d/=ZEROS) THEN
            next_state <= getkey;
         ELSE
            next_state <= load_t;
         END IF;
      WHEN load_u =>
            next_state <= load_t;
      WHEN standby =>
         IF (zero='1') THEN
            next_state <= alarm;
         ELSIF (start='1') THEN
            next_state <= counting;
         ELSE
            next_state <= standby;
         END IF;
      WHEN alarm =>
         IF (stop='1') THEN
            next_state <= end_count;
         ELSE
            next_state <= alarm;
         END IF;
      WHEN counting =>
         IF (zero='1') THEN
            next_state <= alarm;
         ELSIF (stop='1') THEN
            next_state <= suspended;
         ELSE
            next_state <= counting;
         END IF;
      WHEN suspended =>
         IF (stop='0') THEN
            next_state <= counting;
         ELSE
            next_state <= suspended;
         END IF;
      WHEN end_count =>
         IF (stop='1') THEN
            next_state <= flush;
         ELSE
            next_state <= end_count;
         END IF;
      WHEN OTHERS =>
         next_state <= flush;
      END CASE;

   END PROCESS nextstate;

   output : PROCESS (current_state)
   BEGIN
      beep_int <= '0';
      clear <= '0';
      hold <= '0';
      load <= '0';

      CASE current_state IS
      WHEN flush =>
         hold<='1';
         clear<='1';
         beep_int<='0';
      WHEN getkey =>
         hold<='1';
      WHEN load_t =>
         hold<='1';
      WHEN load_u =>
         hold<='1';
         load<='0';
      WHEN standby =>
         hold<='1';
      WHEN alarm =>
         hold<='1';
         clear<='1';
         beep_int<='1';
      WHEN suspended =>
         hold<='1';
      WHEN end_count =>
         hold<='1';
         clear<='1';
      WHEN OTHERS =>
         NULL;
      END CASE;
   END PROCESS output;
END fsm;


=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Thu May 17 15:51:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kw2-0002M1-00 for ; Wed, 23 May 2001 00:47:26 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:26 +0200 (CEST) Received: (qmail 27849 invoked by uid 0); 17 May 2001 13:53:54 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx22) with SMTP; 17 May 2001 13:53:54 -0000 X-eGroups-Return: sentto-1101623-2824-990107561-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 17 May 2001 13:53:53 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 13:52:40 -0000 Received: (qmail 50235 invoked from network); 17 May 2001 13:52:39 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 17 May 2001 13:52:39 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta2 with SMTP; 17 May 2001 13:52:38 -0000 Received: from f-cpu.org (nas1-165.aub.club-internet.fr [195.36.202.165]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA12989 for ; Thu, 17 May 2001 15:52:21 +0200 (MET DST) Message-ID: <3B03D747.3DDB40B9@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 15:51:03 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kim Enkovaara wrote:
<snip>
> The reason I'm talking about this is that the whole f-cpu must be designed
> with same methodology. Mixed schematics and high level description only
> makes the problem worse (with schematics I mean blocks made from
> elementary components).
i think that you mix hierarchical and schematic representation : hierarchy
is easily transposed in HDL...

> My strong belief is that high level HDL
> description is the way to go, it is the method big chips are done today.

maybe. I don't think that the F-CPU will be "made" with schematics entry,
however no law or rule keeps anyone from doing it.
Despite some difficult sides, i like VHDL and i think i'll go on this
way, however my biggest concern is to make clear what i code. A drawing
speaks more than lines of text and it has a crucial place in the project :
it is an explanation of the text and a part of the documentation.

Maybe i have the bad habit of going from the schematic drawings and
try to code what i see in VHDL. it probably makes my code hairy.
but i let the compilers and the VHDL gurus correct me and teach me the
good manners :-)

In fact, the real problem for me is that the langage should not dictate
the implementation. I think that VHDL is flexible enough to accomodate
for the little bad habits. And then, when it works (in behaviour),
it can be recoded for synthesis.

> There are even strong aspirations to go higher level languages than
> Verilog/VHDL. Gates are almost free, you can make some extra gates if the
> work gets done faster.

you are almost correct but gates are not "free". more gates, less yield.
However i have a book that studies a theorem (i don't remember exactly
the name) saying that optimal circuits are in t*s^2 (time * surface^2).
there are some demonstrations around a barrel shifter but the book is
lost in the middle of others in a big pile...


read you soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor

www.   

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From jeff@llandre.freeserve.co.uk Thu May 17 17:37:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kw6-0002M1-00 for ; Wed, 23 May 2001 00:47:30 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:30 +0200 (CEST) Received: (qmail 7055 invoked by uid 0); 17 May 2001 14:35:08 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx001-rz3) with SMTP; 17 May 2001 14:35:08 -0000 X-eGroups-Return: sentto-1101623-2825-990110105-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 17 May 2001 14:35:07 -0000 X-Sender: jeff@llandre.freeserve.co.uk X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 14:35:05 -0000 Received: (qmail 93316 invoked from network); 17 May 2001 14:35:03 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 17 May 2001 14:35:03 -0000 Received: from unknown (HELO mail11.svr.pol.co.uk) (195.92.193.23) by mta3 with SMTP; 17 May 2001 14:35:02 -0000 Received: from modem-79.argon.dialup.pol.co.uk ([62.136.17.79] helo=tara.tyrone) by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0) id 150Orf-0007w2-00 for f-cpu@yahoogroups.com; Thu, 17 May 2001 15:34:55 +0100 Organization: Hipparchus Systems Ltd To: f-cpu@yahoogroups.com X-Mailer: KMail [version 1.2] References: In-Reply-To: Message-Id: <01051716374500.01402@tara.tyrone> From: Jeff Davies MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 16:37:45 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thursday 17 May 2001 11:18 am, you wrote:
> On Thu, 17 May 2001, Jeff Davies wrote:
> > > > schematics is stupidity, but that is my opinion. How long does it
> > > > take to change for example normal state machine to one hot encoded
> > > > with schematics.
> >
> > Errm I think I said looking at a circuit diagram for the rest of the
> > stuff, and entering 1s and 0s in a table for signals, rather than the
> > crappy way you have to do it in ABEL etc.
>
> I tought ABEL was dead :) Below is a example of automatically generated
> state machine (Renoir 2000). The encoding of the states can be selected

>    nextstate : PROCESS (current_state,d,start,stop,zero)
>    BEGIN
>       CASE current_state IS
>       WHEN flush =>
>             next_state <= load_u;
>       WHEN getkey =>
>          IF (start='1') THEN
>             next_state <= standby;
>          ELSIF (d/=ZEROS) THEN
>             next_state <= load_u;

You think the above is easier to understand than a table of 1s and 0s.
Myself,I do not.
Happily, with the XML ideas I have, both sorts of entry will
be legal, and interchangeable.    :)

There isn't necessarily  a"best" way to do anything, otherwise there would be
no point in having any freedoms at all.

Jeff Davies
Yahoo! Groups Sponsor

www.   

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Wed May 16 17:56:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwC-0002M1-00 for ; Wed, 23 May 2001 00:47:36 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:36 +0200 (CEST) Received: (qmail 20951 invoked by uid 0); 17 May 2001 16:13:23 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx26) with SMTP; 17 May 2001 16:13:23 -0000 X-eGroups-Return: sentto-1101623-2826-990115993-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fl.egroups.com with NNFMP; 17 May 2001 16:13:14 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 16:13:12 -0000 Received: (qmail 21113 invoked from network); 17 May 2001 16:12:30 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 May 2001 16:12:30 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 17 May 2001 16:12:30 -0000 Received: from jetnet.ab.ca (dialin35.jetnet.ab.ca [207.153.6.35]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA05509 for ; Thu, 17 May 2001 10:12:27 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B02A33D.BAF06768@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 09:56:45 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
> Spartan2 XC2S30-6-CS144   77.8 MHz, 607 LUT (50MHz, 461LUT )
> Altera   EP1K100-1-TC100  59.9 MHz, 576 LC
> Altera   EP1K100-3-TC100  39.4 MHz, 576 LC
>
> So there are some differences between the tools :)

Can you check if it fits on a Altera 10K10 as it has exactly 576
LC's.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Wed May 16 18:21:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwD-0002M1-00 for ; Wed, 23 May 2001 00:47:37 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:37 +0200 (CEST) Received: (qmail 5624 invoked by uid 0); 17 May 2001 16:37:31 -0000 Received: from ej.egroups.com (64.211.240.230) by mx0.gmx.net (mx26) with SMTP; 17 May 2001 16:37:31 -0000 X-eGroups-Return: sentto-1101623-2827-990117442-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ej.egroups.com with NNFMP; 17 May 2001 16:37:24 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 16:37:21 -0000 Received: (qmail 23229 invoked from network); 17 May 2001 16:36:44 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 17 May 2001 16:36:44 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 17 May 2001 16:36:44 -0000 Received: from jetnet.ab.ca (dialin35.jetnet.ab.ca [207.153.6.35]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA06094 for ; Thu, 17 May 2001 10:36:42 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B02A8EC.3F5B7C4B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 10:21:00 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
>
> On Wed, 16 May 2001, Ben Franchuk wrote:

> You have to remeber that each FPGA architecture has different architecture
> in the basic element and they can't be compared directly. Even the gate
> counts FPGA makers announce are quite different thing what usually is
> understood with ASIC gates.

Ok, 539 Altera 10K10 gates then and about 450 Quick logic LC's.
I use a lot of multiplexers and that takes up a lot of cells.
Ben.
PS. The schematics will be finished REAL soon now.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From nicolas.boulay@isep.fr Thu May 17 19:43:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwE-0002M1-00 for ; Wed, 23 May 2001 00:47:38 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:38 +0200 (CEST) Received: (qmail 19735 invoked by uid 0); 17 May 2001 16:47:18 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx13) with SMTP; 17 May 2001 16:47:18 -0000 X-eGroups-Return: sentto-1101623-2828-990117974-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ho.egroups.com with NNFMP; 17 May 2001 16:46:14 -0000 X-Sender: nicolas.boulay@isep.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 16:46:13 -0000 Received: (qmail 48061 invoked from network); 17 May 2001 16:46:09 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 17 May 2001 16:46:09 -0000 Received: from unknown (HELO herabis.isep.fr) (194.2.232.252) by mta2 with SMTP; 17 May 2001 16:46:08 -0000 Received: from snefon.isep.fr ([194.3.122.154]) by herabis.isep.fr (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0GDH007GIQJAPK@herabis.isep.fr> for f-cpu@yahoogroups.com; Thu, 17 May 2001 18:42:46 +0100 (WET DST) Received: from isep.fr (localhost [127.0.0.1]) by snefon.isep.fr (8.9.3+Sun/8.9.1) with ESMTP id SAA02737 for ; Thu, 17 May 2001 18:43:12 +0100 (WET DST) Sender: nboulay@snefon.isep.fr To: f-cpu@yahoogroups.com Message-id: <3B040DB0.10C3786D@isep.fr> Organization: ISEP X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en References: <200105171637.3491@lh00.opsion.fr> From: Nicolas Boulay MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 18:43:12 +0100 Reply-To: f-cpu@yahoogroups.com Subject: Re: Tr:Re: [f-cpu] eda tools problem Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Status: R X-Status: N Nice vhdl code ! But what is the beep signal ? nicO > > -----Message d'origine----- > De: Kim Enkovaara > A: f-cpu@yahoogroups.com > Date: 17/05/01 > Objet: Re: [f-cpu] eda tools problem > > On Thu, 17 May 2001, Jeff Davies wrote: > > > > > schematics is stupidity, but that is my > opinion. How long does it take to > > > > change for example normal state machine to one > hot encoded with > > > > schematics. > > > > > Errm I think I said looking at a circuit diagram > for the rest of the stuff, > > and entering 1s and 0s in a table for signals, > rather than the crappy way you > > have to do it in ABEL etc. > > I tought ABEL was dead :) Below is a example of > automatically generated > state machine (Renoir 2000). The encoding of the > states can be selected > during synthesis or with one pragma line to the code. > I think the code is > quite readable and easy to understand. I removed all > the comments the > tools does to fit the state machine into smaller > space. The synthesis > tools show this as a state machine in their RTL view > and even show the > normal bubble diagram. They start the optimization > from that level. > > The reason I'm talking about this is that the whole > f-cpu must be designed > with same methodology. Mixed schematics and high > level description only > makes the problem worse (with schematics I mean > blocks made from > elementary components). My strong belief is that high > level HDL > description is the way to go, it is the method big > chips are done today. > There are even strong aspirations to go higher level > languages than > Verilog/VHDL. Gates are almost free, you can make > some extra gates if the > work gets done faster. > > LIBRARY ieee; > USE ieee.std_logic_1164.all; > USE ieee.numeric_std.all; > > ENTITY Control IS > PORT( > clk : IN std_logic; > d : IN unsigned (9 DOWNTO 0); > reset : IN std_logic; > start : IN std_logic; > stop : IN std_logic; > zero : IN std_logic; > beep : OUT std_logic; > clear : OUT std_logic; > hold : OUT std_logic; > load : OUT std_logic > ); > END Control; > > ARCHITECTURE fsm OF Control IS > Constant ZEROS:unsigned:="0000000000"; > > TYPE state_type IS > (flush,getkey,load_t,load_u,standby,alarm,counting,su > spended,end_count); > > ATTRIBUTE state_vector : string; > ATTRIBUTE state_vector OF fsm : architecture IS > "current_state"; > > SIGNAL current_state, next_state : state_type; > SIGNAL beep_int : std_logic; > > BEGIN > clocked : PROCESS (clk,reset) > BEGIN > IF (reset = '1') THEN > current_state <= flush; > beep <= '0'; > ELSIF (clk'EVENT AND clk = '0') THEN > current_state <= next_state; > beep <= beep_int; > END IF; > > END PROCESS clocked; > > nextstate : PROCESS > (current_state,d,start,stop,zero) > BEGIN > CASE current_state IS > WHEN flush => > next_state <= load_u; > WHEN getkey => > IF (start='1') THEN > next_state <= standby; > ELSIF (d/=ZEROS) THEN > next_state <= load_u; > ELSIF (stop='1') THEN > next_state <= flush; > ELSE > next_state <= getkey; > END IF; > WHEN load_t => > IF (d/=ZEROS) THEN > next_state <= getkey; > ELSE > next_state <= load_t; > END IF; > WHEN load_u => > next_state <= load_t; > WHEN standby => > IF (zero='1') THEN > next_state <= alarm; > ELSIF (start='1') THEN > next_state <= counting; > ELSE > next_state <= standby; > END IF; > WHEN alarm => > IF (stop='1') THEN > next_state <= end_count; > ELSE > next_state <= alarm; > END IF; > WHEN counting => > IF (zero='1') THEN > next_state <= alarm; > ELSIF (stop='1') THEN > next_state <= suspended; > ELSE > next_state <= counting; > END IF; > WHEN suspended => > IF (stop='0') THEN > next_state <= counting; > ELSE > next_state <= suspended; > END IF; > WHEN end_count => > IF (stop='1') THEN > next_state <= flush; > ELSE > next_state <= end_count; > END IF; > WHEN OTHERS => > next_state <= flush; > END CASE; > > END PROCESS nextstate; > > output : PROCESS (current_state) > BEGIN > beep_int <= '0'; > clear <= '0'; > hold <= '0'; > load <= '0'; > > CASE current_state IS > WHEN flush => > hold<='1'; > clear<='1'; > beep_int<='0'; > WHEN getkey => > hold<='1'; > WHEN load_t => > hold<='1'; > WHEN load_u => > hold<='1'; > load<='0'; > WHEN standby => > hold<='1'; > WHEN alarm => > hold<='1'; > clear<='1'; > beep_int<='1'; > WHEN suspended => > hold<='1'; > WHEN end_count => > hold<='1'; > clear<='1'; > WHEN OTHERS => > NULL; > END CASE; > END PROCESS output; > END fsm; > > ===================================================== > ======================== > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | > Microelectronic Riemannian > Vasamatie 1 C 16 | IRC: embo | > curved-space fault in > 02630 Espoo | | > write-only file system > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > ______________________________________________________________________________ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From jecel@merlintec.com Thu May 17 22:58:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwK-0002M1-01 for ; Wed, 23 May 2001 00:47:44 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:44 +0200 (CEST) Received: (qmail 23088 invoked by uid 0); 17 May 2001 19:58:10 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx001-rz3) with SMTP; 17 May 2001 19:58:10 -0000 X-eGroups-Return: sentto-1101623-2829-990129487-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 17 May 2001 19:58:09 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 19:58:07 -0000 Received: (qmail 28640 invoked from network); 17 May 2001 19:57:58 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 17 May 2001 19:57:58 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta2 with SMTP; 17 May 2001 19:57:57 -0000 Received: from gandalf.merlintec.com (gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id SAA01653 for ; Thu, 17 May 2001 18:09:10 -0300 Organization: Merlintec Computers X-Mailer: KMail [version 1.1.99] To: f-cpu@yahoogroups.com References: In-Reply-To: Message-Id: <01051716581000.00891@gandalf.merlintec.com> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 16:58:10 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thursday 17 May 2001 02:23, Kim Enkovaara wrote:
> I ran the same source trough Synplify Pro [....]
> So there are some differences between the tools :)

There are indeed, but my point was that there are some freely
downloadable VHDL tools out there that are good enough for us to get
started, at least.

Thanks for making the comparison. It would be interesting to try to
hand optimize this design to see if the result would be better or
worse. Though of course, this is tiny compared to the F-CPU.

Ben Franchuk wrote:
> I say quit YAPPING how good your product is if NOBODY can use it!
> As long as Moore is making $$$ will he keep his product closed.

It is very frustrating not to be able to get to the tools, specially
since he always talks about how he would like others to use them. From
the video in the URL I gave it seems that he is not currently making
any money at all (he has left iTV and is on his own).

-- Jecel
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Wed May 16 22:13:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwM-0002M1-00 for ; Wed, 23 May 2001 00:47:46 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:46 +0200 (CEST) Received: (qmail 29433 invoked by uid 0); 17 May 2001 20:29:27 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx12) with SMTP; 17 May 2001 20:29:27 -0000 X-eGroups-Return: sentto-1101623-2830-990131364-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jj.egroups.com with NNFMP; 17 May 2001 20:29:26 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 20:29:24 -0000 Received: (qmail 96387 invoked from network); 17 May 2001 20:29:16 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 20:29:16 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta1 with SMTP; 17 May 2001 20:29:15 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA11657 for ; Thu, 17 May 2001 14:29:13 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B02DF6D.9FD27D79@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <01051716581000.00891@gandalf.merlintec.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 14:13:33 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Jecel Assumpcao Jr wrote:

> There are indeed, but my point was that there are some freely
> downloadable VHDL tools out there that are good enough for us to get
> started, at least.

However most people would like Open source for the tools.

> Thanks for making the comparison. It would be interesting to try to
> hand optimize this design to see if the result would be better or
> worse. Though of course, this is tiny compared to the F-CPU.
>
> Ben Franchuk wrote:
> > I say quit YAPPING how good your product is if NOBODY can use it!
> > As long as Moore is making $$$ will he keep his product closed.
>
> It is very frustrating not to be able to get to the tools, specially
> since he always talks about how he would like others to use them. From
> the video in the URL I gave it seems that he is not currently making
> any money at all (he has left iTV and is on his own).

I never watch the videos for two reasons: 1) 28K modem, 2) No Video software
for Linux.
I think I would be the only one using Moore's tools as it looks to
be all manual layout.

> -- Jecel
>
Ben.
PS:I can see the motto now -- just like cars --
"FCPU - fine hand crafted Computers from European designers"
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
The Public Record Portal!
   First Name Last Name 
FIND ANYONE Right Now!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From tony@jm.lib.cult.cu Thu May 17 22:38:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwN-0002M1-01 for ; Wed, 23 May 2001 00:47:47 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:47 +0200 (CEST) Received: (qmail 10685 invoked by uid 0); 17 May 2001 20:42:46 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx23) with SMTP; 17 May 2001 20:42:46 -0000 X-eGroups-Return: sentto-1101623-2831-990132163-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fh.egroups.com with NNFMP; 17 May 2001 20:42:45 -0000 X-Sender: tony@jm.lib.cult.cu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 20:42:43 -0000 Received: (qmail 31877 invoked from network); 17 May 2001 20:42:42 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 May 2001 20:42:42 -0000 Received: from unknown (HELO zeus.lib.cult.cu) (169.158.120.134) by mta2 with SMTP; 17 May 2001 20:41:45 -0000 Received: (from daemon@localhost) by zeus.lib.cult.cu (8.9.3/8.9.3) id QAA10055 for ; Thu, 17 May 2001 16:48:54 -0400 Received: from UNKNOWN(169.158.120.131), claiming to be "jm.lib.cult.cu" via SMTP by zeus.lib.cult.cu, id smtpdLU9pt0; Thu May 17 20:48:48 2001 Received: from JM/SpoolDir by jm.lib.cult.cu (Mercury 1.48); 17 May 01 16:39:24 -0500 Received: from SpoolDir by JM (Mercury 1.48); 17 May 01 16:39:19 -0500 Received: from pc-tony (169.158.120.136) by jm.lib.cult.cu (Mercury 1.48); 17 May 01 16:39:18 -0500 Message-ID: <002001c0df11$5ebf3040$88789ea9@pc-tony.lib.cult.cu> To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 From: "=?iso-8859-1?Q?Antonio_D=EDaz_Zamora?=" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 16:38:44 -0400 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] how to keep manual in other languages updated Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi

I am translating the current manual to spanish. I started from the HTML
version.
I worry about updates obsoleting the translation I am doing... Any
suggestion ?

Antonio Diaz Zamora
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kenkovaa@cc.hut.fi Thu May 17 23:01:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwX-0002M1-00 for ; Wed, 23 May 2001 00:47:57 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:57 +0200 (CEST) Received: (qmail 7655 invoked by uid 0); 17 May 2001 21:02:49 -0000 Received: from fk.egroups.com (64.211.240.232) by mx0.gmx.net (mx002-rz3) with SMTP; 17 May 2001 21:02:49 -0000 X-eGroups-Return: sentto-1101623-2832-990133363-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fk.egroups.com with NNFMP; 17 May 2001 21:02:45 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 21:02:42 -0000 Received: (qmail 94162 invoked from network); 17 May 2001 21:01:57 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 17 May 2001 21:01:57 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta2 with SMTP; 17 May 2001 21:01:57 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id AAA31384 for ; Fri, 18 May 2001 00:01:56 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B03D747.3DDB40B9@f-cpu.org> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 00:01:55 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 17 May 2001, Yann Guidon wrote:

> you are almost correct but gates are not "free". more gates, less yield.
> However i have a book that studies a theorem (i don't remember exactly
> the name) saying that optimal circuits are in t*s^2 (time * surface^2).

Today it's difficult to procude enough gates to fill out minimum sized
silicon :) If I rememeber correctly you can fit about 200-300 kgate/mm^2
at 0.13u. You can count from the normal sized chip (10x10mm) how much
gates that is. Well the reality is that most of the silicon area goes to
memories, but still gates are almost free.

If I trust Mentor guys also ATPG is not a problem :) I have listened whole
afternoon about Mentor ATPG tools. And morning about Seamless, Celaro
etc.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kenkovaa@cc.hut.fi Thu May 17 23:08:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KwY-0002M1-00 for ; Wed, 23 May 2001 00:47:58 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:47:58 +0200 (CEST) Received: (qmail 18226 invoked by uid 0); 17 May 2001 21:08:33 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx27) with SMTP; 17 May 2001 21:08:33 -0000 X-eGroups-Return: sentto-1101623-2833-990133712-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fh.egroups.com with NNFMP; 17 May 2001 21:08:32 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 21:08:31 -0000 Received: (qmail 98928 invoked from network); 17 May 2001 21:08:05 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 17 May 2001 21:08:05 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta1 with SMTP; 17 May 2001 21:08:04 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id AAA29453 for ; Fri, 18 May 2001 00:08:03 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B040DB0.10C3786D@isep.fr> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 00:08:02 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: Tr:Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Thu, 17 May 2001, Nicolas Boulay wrote:

> Nice vhdl code !

Well it was totally automatically generated in Renoir 2000. I cleaned out
the comments that made the code even clearer.

> But what is the beep signal ?

That was a file from the Renoir tutorial. It was some kind of state
machine, I didn't look so closely what the beep signal was doing. I think
this was not the UART design. I think it was some kind of clock etc. It
was just a example of VHDL state machine and how readable it can be.

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Wed May 16 23:19:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwb-0002M1-01 for ; Wed, 23 May 2001 00:48:01 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:01 +0200 (CEST) Received: (qmail 8899 invoked by uid 0); 17 May 2001 21:36:40 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx01) with SMTP; 17 May 2001 21:36:40 -0000 X-eGroups-Return: sentto-1101623-2834-990135396-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mv.egroups.com with NNFMP; 17 May 2001 21:36:38 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 21:36:35 -0000 Received: (qmail 76531 invoked from network); 17 May 2001 21:35:40 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 17 May 2001 21:35:40 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta2 with SMTP; 17 May 2001 21:35:40 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA13178 for ; Thu, 17 May 2001 15:35:30 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B02EEE3.90C317AF@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 15:19:31 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Kim Enkovaara wrote:
> Today it's difficult to procude enough gates to fill out minimum sized
> silicon :) If I rememeber correctly you can fit about 200-300 kgate/mm^2
> at 0.13u. You can count from the normal sized chip (10x10mm) how much
> gates that is. Well the reality is that most of the silicon area goes to
> memories, but still gates are almost free.

Hmm protyping costs are about $2,500 (US) for 1mm^2 for 0.18u.
( 7mm^2 minimum order )
I shutter to think what the 0.13 prototyping costs will be.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From jecel@merlintec.com Fri May 18 00:37:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwc-0002M1-00 for ; Wed, 23 May 2001 00:48:02 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:02 +0200 (CEST) Received: (qmail 22334 invoked by uid 0); 17 May 2001 21:37:18 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx25) with SMTP; 17 May 2001 21:37:18 -0000 X-eGroups-Return: sentto-1101623-2835-990135435-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 17 May 2001 21:37:17 -0000 X-Sender: jecel@merlintec.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 21:37:15 -0000 Received: (qmail 88767 invoked from network); 17 May 2001 21:36:49 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 17 May 2001 21:36:49 -0000 Received: from unknown (HELO morannon.merlintec.com) (200.206.134.137) by mta2 with SMTP; 17 May 2001 21:36:49 -0000 Received: from gandalf.merlintec.com (gandalf.merlintec.com [10.0.0.1]) by morannon.merlintec.com (8.9.3/8.8.7) with SMTP id TAA01835 for ; Thu, 17 May 2001 19:48:06 -0300 Organization: Merlintec Computers X-Mailer: KMail [version 1.1.99] To: f-cpu@yahoogroups.com References: <01051716581000.00891@gandalf.merlintec.com> <3B02DF6D.9FD27D79@jetnet.ab.ca> In-Reply-To: <3B02DF6D.9FD27D79@jetnet.ab.ca> Message-Id: <01051718370302.00891@gandalf.merlintec.com> From: Jecel Assumpcao Jr MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 17 May 2001 18:37:03 -0400 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Ben,

> However most people would like Open source for the tools.

Me too. And I would like not to have to reboot my computer into a silly
OS just to compile a design :-(

I prefer to write my own tools and will release them as open source,
but I don't like VHDL and so don't expect anybody to be happy with them.

> I never watch the videos for two reasons: 1) 28K modem,

Young man, in my day I used to run X Window sessions over a 1200 bps
modem! Uphill... both ways! Ahh... the fun of holding down a mouse
button for three full minutes while the pop up menu was being redrawn...

2) No Video
> software for Linux.

I watched the video using Linux - though the free RealPlayer 8 download
is hard to find in Real's site, it is there. While I did get some
previous videos with a 33K modem, even my current 256K DSL isn't up to
the task of grabbing over 100MB.

> I think I would be the only one using Moore's tools as it looks to
> be all manual layout.

As I had mentioned, he has moved from directly drawing rectangles to a
more symbolic layout. I like to use the PPL "textual layout" that I
explained on this list a while ago. It nice to be able to grab some
text over the internet and have the tools automatically do something
reasonable with it. But anyone can do that - I won't have a competitive
chip unless I am willing to put in a lot more effort.

-- Jecel
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Wed May 16 23:39:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwc-0002M1-01 for ; Wed, 23 May 2001 00:48:03 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:02 +0200 (CEST) Received: (qmail 26233 invoked by uid 0); 17 May 2001 21:55:01 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx07) with SMTP; 17 May 2001 21:55:01 -0000 X-eGroups-Return: sentto-1101623-2836-990136500-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ch.egroups.com with NNFMP; 17 May 2001 21:55:01 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 17 May 2001 21:54:59 -0000 Received: (qmail 53719 invoked from network); 17 May 2001 21:54:42 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 17 May 2001 21:54:42 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 17 May 2001 21:54:41 -0000 Received: from jetnet.ab.ca (dialin45.jetnet.ab.ca [207.153.6.45]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA13640 for ; Thu, 17 May 2001 15:54:39 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B02F374.DC73983B@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <01051716581000.00891@gandalf.merlintec.com> <3B02DF6D.9FD27D79@jetnet.ab.ca> <01051718370302.00891@gandalf.merlintec.com> From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 16 May 2001 15:39:00 -0600 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] fpga and vhdl compilers Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Jecel Assumpcao Jr wrote:

> Me too. And I would like not to have to reboot my computer into a silly
> OS just to compile a design :-(

Don't forget all the GAMES out there too!

> Young man, in my day I used to run X Window sessions over a 1200 bps
> modem! Uphill... both ways! Ahh... the fun of holding down a mouse
> button for three full minutes while the pop up menu was being redrawn...

You got me Drooling over my PUNCHED CARDS here.:-)

>
> I watched the video using Linux - though the free RealPlayer 8 download
> is hard to find in Real's site, it is there. While I did get some
> previous videos with a 33K modem, even my current 256K DSL isn't up to
> the task of grabbing over 100MB.

Most of videos I want to grab are in Quick-Time or GASP! windows media.
Ben.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Fri May 18 02:17:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwf-0002M1-01 for ; Wed, 23 May 2001 00:48:05 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:05 +0200 (CEST) Received: (qmail 23658 invoked by uid 0); 18 May 2001 00:18:35 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx10) with SMTP; 18 May 2001 00:18:35 -0000 X-eGroups-Return: sentto-1101623-2837-990145113-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c9.egroups.com with NNFMP; 18 May 2001 00:18:34 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 18 May 2001 00:18:32 -0000 Received: (qmail 48120 invoked from network); 18 May 2001 00:18:32 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 18 May 2001 00:18:32 -0000 Received: from unknown (HELO front6.grolier.fr) (194.158.96.56) by mta2 with SMTP; 18 May 2001 00:18:31 -0000 Received: from f-cpu.org (nas2-60.aub.club-internet.fr [195.36.133.60]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA27834 for ; Fri, 18 May 2001 02:18:12 +0200 (MET DST) Message-ID: <3B0469FC.FB00C960@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 02:17:00 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kim Enkovaara wrote:
> On Thu, 17 May 2001, Yann Guidon wrote:
> > you are almost correct but gates are not "free". more gates, less yield.
> > However i have a book that studies a theorem (i don't remember exactly
> > the name) saying that optimal circuits are in t*s^2 (time * surface^2).
>
> Today it's difficult to procude enough gates to fill out minimum sized
> silicon :) If I rememeber correctly you can fit about 200-300 kgate/mm^2
> at 0.13u. You can count from the normal sized chip (10x10mm) how much
> gates that is. Well the reality is that most of the silicon area goes to
> memories, but still gates are almost free.
if surface "came for free", the natural solution would be to put some
cores in parallel. However, the surface of the pads is another issue.
if we want 2x 64-bit SDRAM interface + FSB, this requires more than 300 pins
(400 is getting comfortable) and this already sucks "some surface".

> If I trust Mentor guys also ATPG is not a problem :) I have listened whole
> afternoon about Mentor ATPG tools. And morning about Seamless, Celaro
> etc.

ah Celaro.... :-)) <little love/hate feeling in the voice>

but if you listen too seriously to the marketing guys, whatever the company,
you soon forget that you have :
- to deal with the "features" of the tools
- do your work anyway, because the tools won't do everything alone
- compare with other tools anyway...

have fun comparing,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Fri May 18 02:17:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwg-0002M1-00 for ; Wed, 23 May 2001 00:48:06 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:06 +0200 (CEST) Received: (qmail 14648 invoked by uid 0); 18 May 2001 00:22:03 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx06) with SMTP; 18 May 2001 00:22:03 -0000 X-eGroups-Return: sentto-1101623-2838-990145117-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by b05.egroups.com with NNFMP; 18 May 2001 00:18:38 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 18 May 2001 00:18:36 -0000 Received: (qmail 68644 invoked from network); 18 May 2001 00:18:36 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 18 May 2001 00:18:36 -0000 Received: from unknown (HELO front2.grolier.fr) (194.158.96.52) by mta1 with SMTP; 18 May 2001 00:18:36 -0000 Received: from f-cpu.org (nas2-60.aub.club-internet.fr [195.36.133.60]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA16777 for ; Fri, 18 May 2001 02:18:14 +0200 (MET DST) Message-ID: <3B0469FE.80284229@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <002001c0df11$5ebf3040$88789ea9@pc-tony.lib.cult.cu> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 02:17:03 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] how to keep manual in other languages updated Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N hello !

Antonio D=EDaz Zamora wrote:
> hi
>
> I am translating the current manual to spanish. I started from the HTM= L version.
> I worry about updates obsoleting the translation I am doing... Any sug= gestion ?

wow great !

however, the most up to date version is in LATEX
(you'll see, it's only a text file in fact, a bit like HTML)
and is stored at http://f-cpu.= seul.org/manual/en/
it's patch_yg_something.tgz (i don't remember all the filenames,
sorry :-)) and it's several months old.
If you have already started, you will see that the contents is
almost the same. However i won't be as helpful as for the french
and german versions, because i don't speak spanish :-/


I think that _now_ is a good time to start a mailing list dedicated
to the manual... Maybe i'll finally end up using the CVS at GOAS
because i don't know what happens with the CVS@seul.org.
I'm sure that the maintainers will be happy to open a CVS project
for the other translations and the VHDL.

salutations, and keep us informed !!!

> Antonio Diaz Zamora
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Spons= or
3D""
www.
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From kenkovaa@cc.hut.fi Fri May 18 09:50:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kwn-0002M1-00 for ; Wed, 23 May 2001 00:48:13 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:13 +0200 (CEST) Received: (qmail 25899 invoked by uid 0); 18 May 2001 07:50:47 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx21) with SMTP; 18 May 2001 07:50:47 -0000 X-eGroups-Return: sentto-1101623-2839-990172245-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 18 May 2001 07:50:46 -0000 X-Sender: kenkovaa@cc.hut.fi X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 18 May 2001 07:50:44 -0000 Received: (qmail 98772 invoked from network); 18 May 2001 07:50:43 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 18 May 2001 07:50:43 -0000 Received: from unknown (HELO taku.hut.fi) (130.233.228.87) by mta2 with SMTP; 18 May 2001 07:50:43 -0000 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA07615 for ; Fri, 18 May 2001 10:50:42 +0300 (EET DST) X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@yahoogroups.com In-Reply-To: <3B0469FC.FB00C960@f-cpu.org> Message-ID: From: Kim Enkovaara MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 10:50:40 +0300 (EET DST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Fri, 18 May 2001, Yann Guidon wrote:

> > Today it's difficult to procude enough gates to fill out minimum sized
> > silicon :) If I rememeber correctly you can fit about 200-300 kgate/mm^2
...
> if surface "came for free", the natural solution would be to put some
> cores in parallel. However, the surface of the pads is another issue.
> if we want 2x 64-bit SDRAM interface + FSB, this requires more than 300 pins
> (400 is getting comfortable) and this already sucks "some surface".

Usually the ASIC vendors have minimum sized silicon that they can still
package. With pure logic filling the minimum sized chip will be a big
challenge, fortunately the chip can be filled with memory :)

Pads take surface but not so much. I'm working with a chip that will have
about 1000 I/O pins, and the pad area will not be a problem.

> ah Celaro.... :-)) <little love/hate feeling in the voice>

At least the boxes are expensive :)

> but if you listen too seriously to the marketing guys, whatever the company,
> you soon forget that you have :
>  - to deal with the "features" of the tools
>  - do your work anyway, because the tools won't do everything alone
>  - compare with other tools anyway...

It quite easy to learn how to listen marketing people. Each vendor has the
best product, fastest product and the product is the market leader :)

=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16    | IRC: embo            | curved-space fault in
02630 Espoo         |                      | write-only file system
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Fri May 18 15:46:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KxN-0002M1-00 for ; Wed, 23 May 2001 00:48:49 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:48:49 +0200 (CEST) Received: (qmail 10947 invoked by uid 0); 18 May 2001 13:48:30 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx14) with SMTP; 18 May 2001 13:48:30 -0000 X-eGroups-Return: sentto-1101623-2840-990193708-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ck.egroups.com with NNFMP; 18 May 2001 13:48:29 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 18 May 2001 13:48:28 -0000 Received: (qmail 52888 invoked from network); 18 May 2001 13:48:27 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 18 May 2001 13:48:27 -0000 Received: from unknown (HELO front4m.grolier.fr) (195.36.216.54) by mta1 with SMTP; 18 May 2001 13:48:27 -0000 Received: from f-cpu.org (nas2-232.ras.club-internet.fr [195.36.192.232]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA26890 for ; Fri, 18 May 2001 15:48:09 +0200 (MET DST) Message-ID: <3B0527D1.B543593@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 15:46:57 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] eda tools problem Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Kim Enkovaara wrote:
> On Fri, 18 May 2001, Yann Guidon wrote:
> > > Today it's difficult to procude enough gates to fill out minimum sized
> > > silicon :) If I rememeber correctly you can fit about 200-300 kgate/mm^2
> ..
> > if surface "came for free", the natural solution would be to put some
> > cores in parallel. However, the surface of the pads is another issue.
> > if we want 2x 64-bit SDRAM interface + FSB, this requires more than 300 pins
> > (400 is getting comfortable) and this already sucks "some surface".
>
> Usually the ASIC vendors have minimum sized silicon that they can still
> package. With pure logic filling the minimum sized chip will be a big
> challenge, fortunately the chip can be filled with memory :)
i can give you an example of silicon filling with logic : FPGA ;-)


> Pads take surface but not so much. I'm working with a chip that will have
> about 1000 I/O pins, and the pad area will not be a problem.
that is ? what surface ?

> > ah Celaro.... :-)) <little love/hate feeling in the voice>
> At least the boxes are expensive :)
with one fully populated and working engine, you have enough money to
buy a large house in the middle of New York... or even buy ten Ferrari :-)
But i still live with my mother and i don't have any driving licence ;-P

however i'm sure that there are means to get the functionality at a fraction
of the cost (and a fraction of the performance too...). I guess that some
companies that upgrade to the larger systems can give away or rent for
a small fee the older or smaller generation machines. These are largely enough
to fully debug the FC0.

> > but if you listen too seriously to the marketing guys, whatever the company,
> > you soon forget that you have :
> >  - to deal with the "features" of the tools
> >  - do your work anyway, because the tools won't do everything alone
> >  - compare with other tools anyway...
> It quite easy to learn how to listen marketing people. Each vendor has the
> best product, fastest product and the product is the market leader :)

btw, speaking about marketing babbling, i try to get into contact with the
person at Cadence who proposed free licences. i'll keep you informed.

> Mr. Kim EnkovaaraWHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From mota@april.org Mon May 21 12:37:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kza-0002M1-00 for ; Wed, 23 May 2001 00:51:06 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:51:06 +0200 (CEST) Received: (qmail 20373 invoked by uid 0); 21 May 2001 10:48:00 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx09) with SMTP; 21 May 2001 10:48:00 -0000 X-eGroups-Return: sentto-1101623-2850-990442072-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ch.egroups.com with NNFMP; 21 May 2001 10:47:53 -0000 X-Sender: mota@april.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 21 May 2001 10:47:52 -0000 Received: (qmail 64240 invoked from network); 21 May 2001 10:47:49 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 21 May 2001 10:47:49 -0000 Received: from unknown (HELO ns1.april.org) (213.228.61.225) by mta3 with SMTP; 21 May 2001 10:47:47 -0000 Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 151n3g-0005HJ-00 for ; Mon, 21 May 2001 12:37:04 +0200 To: f-cpu@yahoogroups.com Message-ID: <20010521123704.A17897@opium.april.org> References: <3B07994A.29C710B1@jetnet.ab.ca> <3B085AA5.6F433F28@f-cpu.org> User-Agent: Mutt/1.2.5i In-Reply-To: <3B085AA5.6F433F28@f-cpu.org>; from whygee@f-cpu.org on Mon, May 21, 2001 at 02:00:37AM +0200 From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 May 2001 12:37:04 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] archive Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N On Mon, May 21, 2001 at 02:00:37AM +0200, Yann Guidon wrote:
> hi !
>

Hello !

> Ben Franchuk wrote:
> > Is the F-cpu messages archived some where?
> it is, at least at yahoogroups.
>

Actually http://groups.yahoo.com/group/f-cpu

> > I wanted to do search for something in the past,but not online.
> > Download all the messages and do my own sorting.
> i've thought about something like that for some time.
> i already have my own archive at home, but it may be
> mixed with personal stuff. It would take years to sort
> the thousands of messages :-)
>
> however, someone has proposed to make a little Unix script
> with wget so that the whole archive at yahoogroups could
> be downloaded, from the first to the last message.

That was me. Unfortunately I cannot do it now :(

> I don't know what will happen with the attachments.
> but if someone does that, i'll miror it on the f-cpu websites.
>
> > Ben.
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
      Paul
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Mon May 21 02:00:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KzO-0002M1-00 for ; Wed, 23 May 2001 00:50:54 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:54 +0200 (CEST) Received: (qmail 13756 invoked by uid 0); 21 May 2001 00:02:18 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx006-rz3) with SMTP; 21 May 2001 00:02:18 -0000 X-eGroups-Return: sentto-1101623-2847-990403330-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by mu.egroups.com with NNFMP; 21 May 2001 00:02:11 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 21 May 2001 00:02:09 -0000 Received: (qmail 5268 invoked from network); 21 May 2001 00:02:06 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 21 May 2001 00:02:06 -0000 Received: from unknown (HELO front1.grolier.fr) (194.158.96.51) by mta1 with SMTP; 21 May 2001 00:02:06 -0000 Received: from f-cpu.org (nas1-234.aub.club-internet.fr [195.36.202.234]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA10183 for ; Mon, 21 May 2001 02:01:44 +0200 (MET DST) Message-ID: <3B085AA0.3143511D@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 May 2001 02:00:32 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] who's who database : submissions please ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello !

it seems that the desired database is going to exist,
thanks to Lionel's countless efforts.

it is a good time to submit your personal info.
The database will be probably located at seul.org,
and the page will be a static dump at the beginning,
until all the forms work in safety.

Remember : the goal of this database is to
know who does or did what, in the most objective
way possible. That means that even though we accept
lurkdom, it is much more interesting to know
that you have written a document or a file, you see,
something useful for the project.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From art1@it-netservice.de Fri May 18 07:41:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kxj-0002M1-00 for ; Wed, 23 May 2001 00:49:11 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:49:11 +0200 (CEST) Received: (qmail 9230 invoked by uid 0); 18 May 2001 18:01:31 -0000 Received: from ei.egroups.com (64.211.240.237) by mx0.gmx.net (mx16) with SMTP; 18 May 2001 18:01:31 -0000 X-eGroups-Return: sentto-1101623-2841-990208889-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ei.egroups.com with NNFMP; 18 May 2001 18:01:30 -0000 X-Sender: art1@it-netservice.de X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 18 May 2001 18:01:28 -0000 Received: (qmail 15237 invoked from network); 18 May 2001 18:01:28 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 18 May 2001 18:01:28 -0000 Received: from unknown (HELO host-2.server.itns.de) (213.179.64.8) by mta1 with SMTP; 18 May 2001 18:01:27 -0000 Received: from art1.none.de (dialin178.pg4-nt.berlin.nikoma.de [213.54.67.178]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f4II1WY10589 for ; Fri, 18 May 2001 20:01:32 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin178.pg4-nt.berlin.nikoma.de [213.54.67.178] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.12 #1 (Debian)) id 150d1P-0002QF-00 for ; Fri, 18 May 2001 07:41:55 +0200 To: f-cpu@yahoogroups.com In-Reply-To: <002001c0df11$5ebf3040$88789ea9@pc-tony.lib.cult.cu> Message-ID: From: Andreas Romeyke MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 18 May 2001 07:41:55 +0200 (CEST) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] how to keep manual in other languages updated Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

> I am translating the current manual to spanish. I started from the HTML
> version.
> I worry about updates obsoleting the translation I am doing... Any
> suggestion ?

Use the YG-Patch at fcpu.seul.org and take a look at the german
translation at http://gaos.org/cgi-bin/cvsweb.cgi/fcpu-manual-de
to have some ideas about technolgy of translating...

Bye Andreas
Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Sun May 20 01:46:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kyf-0002M1-00 for ; Wed, 23 May 2001 00:50:09 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:09 +0200 (CEST) Received: (qmail 20177 invoked by uid 0); 19 May 2001 23:48:42 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx23) with SMTP; 19 May 2001 23:48:42 -0000 X-eGroups-Return: sentto-1101623-2842-990316120-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hp.egroups.com with NNFMP; 19 May 2001 23:48:41 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 19 May 2001 23:48:40 -0000 Received: (qmail 95845 invoked from network); 19 May 2001 23:48:39 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 19 May 2001 23:48:39 -0000 Received: from unknown (HELO front2m.grolier.fr) (195.36.216.52) by mta3 with SMTP; 19 May 2001 23:48:39 -0000 Received: from f-cpu.org (nas2-227.aub.club-internet.fr [195.36.133.227]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA02391 for ; Sun, 20 May 2001 01:48:20 +0200 (MET DST) Message-ID: <3B0705F2.D98928A5@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 May 2001 01:46:58 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] i should be sleeping instead of writing weird stuff, but... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi,

i have come into contact with "Martyn Pollard" <mjp@cadence.com>
and Cadence is still willing to provide the f-cpu developers with
_individual_ licences for VHDL/verilog compilers and SW simulators.
This is a first crucial step, but we have to solve at least two problems :
- what about a synthesiser ?
- what about running the software on a large online server ?

Those who want to start "small" and have a linux/win98/NT/2000 box
can ask for a licence directly from mjp@cadence.com but otherwise,
the others will have to wait until we find a solution to the server
problem.

It appears that the "first phase" of the EDA farm project could be
easily reached : we require a good athlon or P3 box with a large amount
of RAM, connected with a fast link to the net. A secure kernel with
all quotas enabled would run the compilations and simulations in a batch
queue. Of course, the licence for this server is not easy to get,
i need your help to convince Cadence and the others.

YG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From nico@seul.org Sun May 20 14:08:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kyr-0002M1-00 for ; Wed, 23 May 2001 00:50:21 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:21 +0200 (CEST) Received: (qmail 12711 invoked by uid 0); 20 May 2001 12:07:48 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx008-rz3) with SMTP; 20 May 2001 12:07:48 -0000 X-eGroups-Return: sentto-1101623-2843-990360465-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 20 May 2001 12:07:47 -0000 X-Sender: nico@seul.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 20 May 2001 12:07:43 -0000 Received: (qmail 69544 invoked from network); 20 May 2001 12:07:43 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 20 May 2001 12:07:43 -0000 Received: from unknown (HELO localhost.localdomain) (195.36.172.34) by mta2 with SMTP; 20 May 2001 12:07:41 -0000 Received: from seul.org (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 3C4469E3A for ; Sun, 20 May 2001 14:08:46 +0200 (CEST) Sender: nico@localhost.localdomain Message-ID: <3B07B3CE.7499F8D0@seul.org> X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3B0705F2.D98928A5@f-cpu.org> From: Nicolas MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 May 2001 14:08:46 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i should be sleeping instead of writing weird stuff, but... Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Status: R X-Status: N I think i will ask a licence but you work inside mentor and i like very
much vsim (from modeltech). Could you have some licence from that tools
?

nicO

Yann Guidon a =E9crit :
>
> hi,
>
> i have come into contact with "Martyn Pollard" <mjp@caden= ce.com>
> and Cadence is still willing to provide the f-cpu developers with
> _individual_ licences for VHDL/verilog compilers and SW simulators. > This is a first crucial step, but we have to solve at least two proble= ms :
>  - what about a synthesiser ?
>  - what about running the software on a large online server ?
>
> Those who want to start "small" and have a linux/win98/NT/20= 00 box
> can ask for a licence directly from mjp@cadence.com but otherwise,
> the others will have to wait until we find a solution to the server > problem.
>
> It appears that the "first phase" of the EDA farm project co= uld be
> easily reached : we require a good athlon or P3 box with a large amoun= t
> of RAM, connected with a fast link to the net. A secure kernel with > all quotas enabled would run the compilations and simulations in a bat= ch
> queue. Of course, the licence for this server is not easy to get,
> i need your help to convince Cadence and the others.
>
> YG
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Yahoo! Groups Spons= or
= 3D"Yahoo!= = 3D"Yahoo!=
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Sun May 20 19:20:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kz0-0002M1-00 for ; Wed, 23 May 2001 00:50:30 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:30 +0200 (CEST) Received: (qmail 3484 invoked by uid 0); 20 May 2001 17:22:08 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx011-rz3) with SMTP; 20 May 2001 17:22:08 -0000 X-eGroups-Return: sentto-1101623-2844-990379327-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by mu.egroups.com with NNFMP; 20 May 2001 17:22:07 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 20 May 2001 17:22:06 -0000 Received: (qmail 91540 invoked from network); 20 May 2001 17:22:06 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 20 May 2001 17:22:06 -0000 Received: from unknown (HELO front5.grolier.fr) (194.158.96.55) by mta3 with SMTP; 20 May 2001 17:22:05 -0000 Received: from f-cpu.org (nas3-38.ras.club-internet.fr [195.36.203.38]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA22264 for ; Sun, 20 May 2001 19:21:37 +0200 (MET DST) Message-ID: <3B07FCD7.833E23CC@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3B0705F2.D98928A5@f-cpu.org> <3B07B3CE.7499F8D0@seul.org> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 May 2001 19:20:23 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] i should be sleeping instead of writing weird stuff, but... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Nicolas wrote:
> I think i will ask a licence but you work inside mentor and i like very
> much vsim (from modeltech). Could you have some licence from that tools ?

i am not at mentor anymore since 10 days :-/
i was not even in contact with the modelsim team. i don't know where they are.
however, of course, having access to modelsim etc. would be really cool
and i'll do whatever i can to have access to it. i'll keep you informed.

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From bfranchuk@jetnet.ab.ca Sun May 20 12:15:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152Kz2-0002M1-00 for ; Wed, 23 May 2001 00:50:32 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:32 +0200 (CEST) Received: (qmail 916 invoked by uid 0); 20 May 2001 17:37:03 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx08) with SMTP; 20 May 2001 17:37:03 -0000 X-eGroups-Return: sentto-1101623-2845-990380222-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ml.egroups.com with NNFMP; 20 May 2001 17:37:02 -0000 X-Sender: bfranchuk@jetnet.ab.ca X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 20 May 2001 17:37:01 -0000 Received: (qmail 89451 invoked from network); 20 May 2001 17:36:29 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 20 May 2001 17:36:29 -0000 Received: from unknown (HELO main.jetnet.ab.ca) (207.153.11.66) by mta3 with SMTP; 20 May 2001 17:36:29 -0000 Received: from jetnet.ab.ca (dialin62.jetnet.ab.ca [207.153.6.62]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA09638 for ; Sun, 20 May 2001 11:36:27 -0600 (MDT) Sender: bfranchuk@main.jetnet.ab.ca Message-ID: <3B07994A.29C710B1@jetnet.ab.ca> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: Freedom CPU From: Ben Franchuk MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 May 2001 04:15:38 -0600 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] archive Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Is the F-cpu messages archived some where?
I wanted to do search for something in the past,but not online.
Download all the messages and do my own sorting.
Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From FreeCash4u2@expressmail1.net Sun May 20 19:35:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KzH-0002M1-00 for ; Wed, 23 May 2001 00:50:47 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:47 +0200 (CEST) Received: (qmail 4602 invoked by uid 0); 20 May 2001 20:57:43 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx18) with SMTP; 20 May 2001 20:57:43 -0000 X-eGroups-Return: sentto-1101623-2846-990392246-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by f19.egroups.com with NNFMP; 20 May 2001 20:57:27 -0000 X-Sender: 65410937@14191.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 20 May 2001 20:57:25 -0000 Received: (qmail 55052 invoked from network); 20 May 2001 20:57:25 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 20 May 2001 20:57:25 -0000 Received: from unknown (HELO mail.brother.com.sg) (203.123.4.162) by mta1 with SMTP; 20 May 2001 20:57:23 -0000 Received: from 203.123.4.162 (localhost.localdomain [127.0.0.1]) by mail.brother.com.sg (8.9.3/8.9.3) with SMTP id EAA22136; Mon, 21 May 2001 04:46:11 +0800 Received: from mailhost.expressmail1.net{alt1.expressmail1.net{204.1.76.48} by expressmail1.net (8.8.5/8.6.5) with SMTP id GAA09560 for ; Sun, 20 May 2001 12:35:50 -0600 (EST) To: Members@mail.brother.com.sg Message-ID: <814230741239.GAA30148@expressmail1.net> X-PMFLAGS: 34078848 0 X-UIDL: 9340182387e82dfe63254cbf816a4b7e Comments: Authenticated sender is X-eGroups-From: 65410937@14191.com From: FreeCash4u2@expressmail1.net MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 20 May 01 12:35:50 EST Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] "CHAIN-LETTER"? It's LEGAL, It's EASY..Make A TON OF CASH ! ! ! 15 yr.old gets $71,000 cash. Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N                      "CHAIN-LETTER"? It's LEGAL ,It WORKS, It's EASY ! ! !

EVERYONE on this list gets PAID EVERY TIME ! ! ! Invest $15 and get your name on the list,you will not regret it ! ($5 to each person)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Parents of 15 yr.old Find $71,000 cash hidden in his closet.
.
             "CASH JUST KEEPS COMING IN MY MAIL" ! !

Dear Friend,
It Works, Its Legal, Its Easy, so Why Not?
Parents of 15-year-old find $71,000 cash hidden in his closet.

Does this headline look familiar? Of course it does.
You most likely have just seen this story recently featured on a major nightly news program (USA).

His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old sons closet.
Nothing could have prepared her for the shock she got when she opened the bag and
found it was full of cash.
Five-dollar bills, twenties, fifties and hundreds - all neatly rubber-banded in labeled piles.

"My first thought was that he had robbed a bank", says the 41-year-old woman, "There was over $71,000 dollars in that bag -- thats more than my husband earns in a year". The woman immediately called her husband at the car-dealership where he worked to tell him what she had discovered. He came home right away and they drove together to the boys school and picked him up. Little did they suspect that where the money came from was more shocking than actually finding it in the closet.

As it turns out, the boy had been sending out, via E-mail, a type of "chain-letter" to E-mail addresses that he obtained off of the Internet. Everyday after school for the past 2 months, he had been doing this right on his computer in his bedroom."I just got the E-mail one day and I figured what the heck, I put my name on it like the instructions said and I started sending it out", says the clever 15-year-old.

The E-mail letter listed 3 addresses and contained instructions to send one $5 dollar bill to each person on the list, then delete the address at the top and move the other 2 addresses up, and finally to add your name to the bottom of the list.

The letter goes on to state that you would receive several thousand dollars in five-dollar bills within 2 weeks if you sent out the letter with your name at the bottom of the 3-address list. "I get junk E-mail all the time, and I really did not think it was going to work", the boy continues.
Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with not magazines, but envelopes containing $5 bills.

"About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelops stuffed in it.
There was also a yellow slip that said I had to go up to the [post office] counter. I thought I was in trouble or something (laughs)". He goes on, "I went up to the counter and they had a whole box of more mail for me. I had to ride back home and empty out my backpack because I could not carry it all".

Over the next few weeks, the boy continued sending out the E-mail. "The money just kept coming in and I just kept sorting it and stashing it in the closet, I barely had time for my homework". He had also been riding his bike to several of the banks in his area and exchanging the $5 bills for twenties, fifties and hundreds.

"I didnt want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack.I would usually tell the lady at the bank counter that my dad had sent me in [to exchange the money] and he was outside waiting for me. One time the lady gave me a really strange look and told me that she would not be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs)."

Surprisingly, the boy did not have any reason to be afraid. The reporting news team examined and investigated the so-called "chain-letter" the boy was sending out and found that it was not a chain-letter at all. In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received.

Every five-dollar bill that he received contained a little note that read, "Please add me to your mailing list". This simple note made the letter legal because he was exchanging a service (adding the purchasers name to his mailing list) for a five-dollar fee.

Here is the letter that the 15-year-old was sending out by E-mail, you can do the exact same thing he was doing, simply by following the instructions in this letter.
------------------------------------------------------------------------------
Here are instructions on how to make $10,000 US cash in the next 2 weeks:
("to help you with your mailing list")

There are 3 addresses listed below.

Send EACH PERSON on the list a $5 bill wrapped in 2 pieces of paper (to securely hide it), along with a note that says: "Please add me to your mailing list".

Then delete the name at the top, move the other 2 up and put your name at the bottom.

Now start sending this ENTIRE e-mail back out to people. When 20 people receive it, those 20 people will move your name up to the middle position and they will each send out 20. That totals 400 people that will receive this letter with your name in the middle.

Then, those 400 people will move your name up to the top and they will each send out 20 E-mails. That totals 8,000 people that will receive this E-mail with your name on it and they will each send you a $5 bill,
("to help you with your mailing list")

8,000 people each sending you a $5 bill = $40,000 cash,
("to help you with your mailing list") Thats if everyone responds to this E-mail, but not everyone will,so you can expect more realistically to receive about $10,000 cash $5 bills in your mailbox,
("to help you with your mailing list")

This will work for anyone, anywhere in the world in any country, but send only
US CASH $5 bill.

The more E-mails you send out, the more cash you will receive,("to help you with your mailing list") If each person sends out 100 E-mails, there will be 1,000,000  people that receive this letter with your name on it.
If only 1% of those people respond, you will still get $50,000 cash,
("to help you with your mailing list")

Here is the list: (Send US $5 bill to EACH PERSON on the list.Total= $15)
-----------------------------------------------------------------
#1. John Gariss
     7119 196th St S.W.
     Lynnwood,Wa. 98036

# 2. Margaret Vines
      9792 Edmonds Way
      # 218
     Edmonds, Wash. 98020

# 3. KayDee Const.
     13619 Mukilteo Speedway
     Suite D-5 #142
     Lynnwood, Wa. 98037-1606
---------------------------------------------
THERES NOTHING MORE TO DO. When you start sending this out within a few days, you will start receiving $5 bills from other people just like yourself, who are willing to invest three $5 bills to receive $10,000 cash,
("to help with mailing list")

EVERYONE on this list gets Paid EVERY TIME invest $15 & get your name on the list, you will not regret it !

>>Just Think...If every person who got this did it the Results would be PHENOMENAL ! ! ! Try it, all you have to loose is $15 & the chances of you loosing the $15 are VERY,VERY,Slim.<<<

If you dont try it- you will never know.

** Remember to send a $5 bill to EVERY PERSON on the list,=$15.SENDING THE MONEY is what makes this work.


NOTICE: This is NOT a lottery,illegal chain-letter,or scheme.You are BUYING A SERVICE.(US Postal and Lottery Laws,Title 18,Section 1302 and 1341,or Title 18,Section 3005in the US code,also in the code of federal regulations,Volume16,Sections 255 and 436,which state a product or service must be exchanged for money received.)
You are paying $15 to be added to 3 mailing lists($5 per list)
The $15 is not refundable.

                                 
              "God  Is  Always  On  Line  Never  Busy"
=================================================================
I received your e-mail as someone interested in Internet Business Opportunities.
If I received your e-mail in error, or you are no longer interested,
Simply go to "Message"& click on "Block Sender" this will END YOU FROM
RECEIVING ANY FUTURE MAILINGS INSTANTLY.

We apologize if this message has reached you in error.
Save the Planet, Save the Trees! Advertise via E mail.
No wasted paper! Delete with one simple keystroke!
Less refuse in our Dumps!
This is the new way of the new millennium!
God Bless You.
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Mon May 21 02:00:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KzN-0002M1-01 for ; Wed, 23 May 2001 00:50:53 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:53 +0200 (CEST) Received: (qmail 5574 invoked by uid 0); 21 May 2001 00:02:16 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx19) with SMTP; 21 May 2001 00:02:16 -0000 X-eGroups-Return: sentto-1101623-2848-990403332-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hm.egroups.com with NNFMP; 21 May 2001 00:02:15 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 21 May 2001 00:02:12 -0000 Received: (qmail 98949 invoked from network); 21 May 2001 00:02:06 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 21 May 2001 00:02:06 -0000 Received: from unknown (HELO front8.grolier.fr) (194.158.96.58) by mta3 with SMTP; 21 May 2001 00:02:06 -0000 Received: from f-cpu.org (nas1-234.aub.club-internet.fr [195.36.202.234]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA23155 for ; Mon, 21 May 2001 02:01:45 +0200 (MET DST) Message-ID: <3B085AA5.6F433F28@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: f-cpu@yahoogroups.com References: <3B07994A.29C710B1@jetnet.ab.ca> From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 May 2001 02:00:37 +0200 Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] archive Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hi !

Ben Franchuk wrote:
> Is the F-cpu messages archived some where?
it is, at least at yahoogroups.

> I wanted to do search for something in the past,but not online.
> Download all the messages and do my own sorting.
i've thought about something like that for some time.
i already have my own archive at home, but it may be
mixed with personal stuff. It would take years to sort
the thousands of messages :-)

however, someone has proposed to make a little Unix script
with wget so that the whole archive at yahoogroups could
be downloaded, from the first to the last message.
I don't know what will happen with the attachments.
but if someone does that, i'll miror it on the f-cpu websites.

> Ben.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Mon May 21 02:00:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 152KzP-0002M1-00 for ; Wed, 23 May 2001 00:50:55 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 23 May 2001 00:50:55 +0200 (CEST) Received: (qmail 12001 invoked by uid 0); 21 May 2001 00:02:36 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx06) with SMTP; 21 May 2001 00:02:36 -0000 X-eGroups-Return: sentto-1101623-2849-990403344-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c3.egroups.com with NNFMP; 21 May 2001 00:02:26 -0000 X-Sender: whygee@f-cpu.org X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_1_3); 21 May 2001 00:02:24 -0000 Received: (qmail 14006 invoked from network); 21 May 2001 00:02:18 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 21 May 2001 00:02:18 -0000 Received: from unknown (HELO front3.grolier.fr) (194.158.96.53) by mta3 with SMTP; 21 May 2001 00:02:18 -0000 Received: from f-cpu.org (nas1-234.aub.club-internet.fr [195.36.202.234]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA25869 for ; Mon, 21 May 2001 02:01:51 +0200 (MET DST) Message-ID: <3B085AA7.4B4DECB@f-cpu.org> Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en To: fm From: Yann Guidon MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 21 May 2001 02:00:39 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] MPF Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N hello,

the Cahner's website at http://www.mdronline.com/mpf/
has a call for submissions for the coming MicroProcessor Forum
in the US next fall.
The deadline is in a few weeks, do we attempt to get there ?
After the failure for the EPF, i think that i am not
ready for this year, unless i magicly find something.
We have already several problems to solve and the HAL2001
meeting will suck some ressources. So the question can be :
is somebody wanting to submit something for the MPF ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PS: look at the f-cpu plug on news:comp.arch :-D
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:28:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A8y-0000ME-00 for ; Mon, 28 May 2001 01:40:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:20 +0200 (CEST) Received: (qmail 30839 invoked by uid 0); 23 May 2001 14:38:07 -0000 Received: from mo.egroups.com (208.50.144.78) by mx0.gmx.net (mx13) with SMTP; 23 May 2001 14:38:07 -0000 X-eGroups-Return: sentto-1101623-2853-990628507-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mo.egroups.com with NNFMP; 23 May 2001 14:35:07 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:35:06 -0000 Received: (qmail 35811 invoked from network); 23 May 2001 14:28:25 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 14:28:25 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 14:28:25 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NESOh21110 for ; Wed, 23 May 2001 07:28:24 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NESOr21106 for ; Wed, 23 May 2001 07:28:24 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NES8F19671 for ; Wed, 23 May 2001 07:28:08 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21553; Wed, 23 May 2001 07:28:18 -0700 (PDT) Message-Id: <200105231428.HAA21553@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231422.HAA21528@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:28:18 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> Subject: Re: [f-cpu] utopia webring
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > Subject: [f-cpu] utopia webring
> >
> > Hi,
> >
> > Apologies to any users of the utopia web-ring - open collector moved hosts
> > yesterday, and there are some hiccups with getting everything working on
> > the new machine. It should be back up by tomorrow.
> >
> > Graham
> >
> >
> >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:50:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A8z-0000ME-00 for ; Mon, 28 May 2001 01:40:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:21 +0200 (CEST) Received: (qmail 32412 invoked by uid 0); 23 May 2001 14:58:01 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx23) with SMTP; 23 May 2001 14:58:01 -0000 X-eGroups-Return: sentto-1101623-2856-990629879-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 23 May 2001 14:58:00 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:57:57 -0000 Received: (qmail 56698 invoked from network); 23 May 2001 14:50:38 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 23 May 2001 14:50:38 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 14:50:38 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEoch23777 for ; Wed, 23 May 2001 07:50:38 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEocr23773 for ; Wed, 23 May 2001 07:50:38 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEoMF21285 for ; Wed, 23 May 2001 07:50:22 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21633; Wed, 23 May 2001 07:50:32 -0700 (PDT) Message-Id: <200105231450.HAA21633@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231442.HAA21598@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:50:32 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> Subject: Re: Re: Re: Re: [f-cpu] utopia webring
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > Subject: Re: Re: Re: [f-cpu] utopia webring
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > Subject: Re: Re: [f-cpu] utopia webring
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > Subject: Re: [f-cpu] utopia webring
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > Subject: [f-cpu] utopia webring
> > > > >
> > > > > Hi,
> > > > >
> > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > the new machine. It should be back up by tomorrow.
> > > > >
> > > > > Graham
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor

www

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:33:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A92-0000ME-00 for ; Mon, 28 May 2001 01:40:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:24 +0200 (CEST) Received: (qmail 5089 invoked by uid 0); 23 May 2001 15:46:01 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx16) with SMTP; 23 May 2001 15:46:01 -0000 X-eGroups-Return: sentto-1101623-2861-990632758-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 23 May 2001 15:46:00 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:45:57 -0000 Received: (qmail 93549 invoked from network); 23 May 2001 15:34:00 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 23 May 2001 15:34:00 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 15:34:00 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFXxh29340 for ; Wed, 23 May 2001 08:33:59 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFXxr29335 for ; Wed, 23 May 2001 08:33:59 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFXhF24767 for ; Wed, 23 May 2001 08:33:43 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA21773; Wed, 23 May 2001 08:33:53 -0700 (PDT) Message-Id: <200105231533.IAA21773@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231524.IAA21747@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:33:53 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > >
> > > > > > > > > > Graham
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From graham@belegost.mit.edu Wed May 23 16:16:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A96-0000ME-00 for ; Mon, 28 May 2001 01:40:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:28 +0200 (CEST) Received: (qmail 14021 invoked by uid 0); 23 May 2001 15:51:05 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 15:51:05 -0000 X-eGroups-Return: sentto-1101623-2851-990627721-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by c3.egroups.com with NNFMP; 23 May 2001 14:22:02 -0000 X-Sender: graham@belegost.mit.edu X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:22:00 -0000 Received: (qmail 60154 invoked from network); 23 May 2001 14:17:00 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 May 2001 14:17:00 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by mta2 with SMTP; 23 May 2001 14:17:00 -0000 Received: from localhost (graham@localhost) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA01268 for ; Wed, 23 May 2001 10:16:56 -0400 To: f-cpu@yahoogroups.com Message-ID: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:16:55 -0400 (EDT) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hi,

Apologies to any users of the utopia web-ring - open collector moved hosts
yesterday, and there are some hiccups with getting everything working on
the new machine. It should be back up by tomorrow.

Graham
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:46:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A98-0000ME-00 for ; Mon, 28 May 2001 01:40:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:30 +0200 (CEST) Received: (qmail 10015 invoked by uid 0); 23 May 2001 15:56:07 -0000 Received: from mw.egroups.com (208.50.144.94) by mx0.gmx.net (mx24) with SMTP; 23 May 2001 15:56:07 -0000 X-eGroups-Return: sentto-1101623-2862-990633352-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mw.egroups.com with NNFMP; 23 May 2001 15:55:54 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:55:51 -0000 Received: (qmail 71239 invoked from network); 23 May 2001 15:46:47 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 15:46:47 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 15:46:47 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFkkM01368 for ; Wed, 23 May 2001 08:46:46 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFkkr01364 for ; Wed, 23 May 2001 08:46:46 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFkUF26073 for ; Wed, 23 May 2001 08:46:30 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA23272; Wed, 23 May 2001 08:46:40 -0700 (PDT) Message-Id: <200105231546.IAA23272@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231533.IAA21773@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:46:40 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > >
> > > > > > > > > > > Graham
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:04:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9D-0000ME-00 for ; Mon, 28 May 2001 01:40:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:35 +0200 (CEST) Received: (qmail 15858 invoked by uid 0); 23 May 2001 16:12:39 -0000 Received: from fg.egroups.com (208.50.144.70) by mx0.gmx.net (mx21) with SMTP; 23 May 2001 16:12:39 -0000 X-eGroups-Return: sentto-1101623-2864-990634356-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by fg.egroups.com with NNFMP; 23 May 2001 16:12:38 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:12:35 -0000 Received: (qmail 86246 invoked from network); 23 May 2001 16:04:37 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 23 May 2001 16:04:37 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 16:04:37 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NG4bF04359 for ; Wed, 23 May 2001 09:04:37 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NG4ar04355 for ; Wed, 23 May 2001 09:04:36 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NG4KF28221 for ; Wed, 23 May 2001 09:04:20 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23328; Wed, 23 May 2001 09:04:30 -0700 (PDT) Message-Id: <200105231604.JAA23328@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231556.IAA23307@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:04:30 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Graham
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:58:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9J-0000ME-00 for ; Mon, 28 May 2001 01:40:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:41 +0200 (CEST) Received: (qmail 23552 invoked by uid 0); 23 May 2001 16:15:37 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 16:15:37 -0000 X-eGroups-Return: sentto-1101623-2857-990630364-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 23 May 2001 15:06:06 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:06:03 -0000 Received: (qmail 92246 invoked from network); 23 May 2001 14:58:41 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 23 May 2001 14:58:41 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 14:58:41 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEwea25076 for ; Wed, 23 May 2001 07:58:40 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEwer25072 for ; Wed, 23 May 2001 07:58:40 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEwOF21856 for ; Wed, 23 May 2001 07:58:24 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21666; Wed, 23 May 2001 07:58:34 -0700 (PDT) Message-Id: <200105231458.HAA21666@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231450.HAA21633@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:58:34 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] utopia webring
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] utopia webring
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > Subject: [f-cpu] utopia webring
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > the new machine. It should be back up by tomorrow.
> > > > > >
> > > > > > Graham
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:06:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9L-0000ME-00 for ; Mon, 28 May 2001 01:40:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:43 +0200 (CEST) Received: (qmail 28812 invoked by uid 0); 23 May 2001 16:18:51 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 16:18:51 -0000 X-eGroups-Return: sentto-1101623-2858-990630890-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 23 May 2001 15:14:51 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:14:49 -0000 Received: (qmail 60145 invoked from network); 23 May 2001 15:06:48 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 May 2001 15:06:48 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 15:06:48 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NF6m026114 for ; Wed, 23 May 2001 08:06:48 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NF6lr26107 for ; Wed, 23 May 2001 08:06:47 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NF6WF22530 for ; Wed, 23 May 2001 08:06:32 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA21694; Wed, 23 May 2001 08:06:42 -0700 (PDT) Message-Id: <200105231506.IAA21694@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231458.HAA21666@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:06:42 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > Subject: [f-cpu] utopia webring
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > >
> > > > > > > Graham
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:42:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9P-0000ME-00 for ; Mon, 28 May 2001 01:40:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:47 +0200 (CEST) Received: (qmail 19326 invoked by uid 0); 23 May 2001 16:25:11 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx006-rz3) with SMTP; 23 May 2001 16:25:11 -0000 X-eGroups-Return: sentto-1101623-2855-990629396-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hp.egroups.com with NNFMP; 23 May 2001 14:49:58 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:49:55 -0000 Received: (qmail 86278 invoked from network); 23 May 2001 14:42:47 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 May 2001 14:42:47 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 14:42:47 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEglB22580 for ; Wed, 23 May 2001 07:42:47 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEgkr22576 for ; Wed, 23 May 2001 07:42:46 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEgVF20626 for ; Wed, 23 May 2001 07:42:31 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21598; Wed, 23 May 2001 07:42:41 -0700 (PDT) Message-Id: <200105231442.HAA21598@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231435.HAA21569@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:42:41 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] utopia webring
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] utopia webring
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > Subject: Re: [f-cpu] utopia webring
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > Subject: [f-cpu] utopia webring
> > > >
> > > > Hi,
> > > >
> > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > yesterday, and there are some hiccups with getting everything working on
> > > > the new machine. It should be back up by tomorrow.
> > > >
> > > > Graham
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:22:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9R-0000ME-00 for ; Mon, 28 May 2001 01:40:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:49 +0200 (CEST) Received: (qmail 4310 invoked by uid 0); 23 May 2001 16:26:28 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx26) with SMTP; 23 May 2001 16:26:28 -0000 X-eGroups-Return: sentto-1101623-2852-990628056-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by mu.egroups.com with NNFMP; 23 May 2001 14:27:43 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:27:35 -0000 Received: (qmail 76029 invoked from network); 23 May 2001 14:22:42 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 23 May 2001 14:22:42 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 14:22:42 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEMgC20602 for ; Wed, 23 May 2001 07:22:42 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEMfr20596 for ; Wed, 23 May 2001 07:22:41 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEMRF19334 for ; Wed, 23 May 2001 07:22:27 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21528; Wed, 23 May 2001 07:22:36 -0700 (PDT) Message-Id: <200105231422.HAA21528@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: , from X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:22:36 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> Subject: [f-cpu] utopia webring
>
> Hi,
>
> Apologies to any users of the utopia web-ring - open collector moved hosts
> yesterday, and there are some hiccups with getting everything working on
> the new machine. It should be back up by tomorrow.
>
> Graham
>
>
>
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:15:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9T-0000ME-00 for ; Mon, 28 May 2001 01:40:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:51 +0200 (CEST) Received: (qmail 16390 invoked by uid 0); 23 May 2001 16:30:51 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 16:30:51 -0000 X-eGroups-Return: sentto-1101623-2859-990631431-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by c3.egroups.com with NNFMP; 23 May 2001 15:23:53 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:23:50 -0000 Received: (qmail 42984 invoked from network); 23 May 2001 15:15:34 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 May 2001 15:15:34 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 15:15:34 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFFYU27342 for ; Wed, 23 May 2001 08:15:34 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFFXr27337 for ; Wed, 23 May 2001 08:15:33 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFFIF23219 for ; Wed, 23 May 2001 08:15:18 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA21739; Wed, 23 May 2001 08:15:28 -0700 (PDT) Message-Id: <200105231515.IAA21739@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231506.IAA21694@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:15:28 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > >
> > > > > > > > Graham
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 16:35:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9W-0000ME-00 for ; Mon, 28 May 2001 01:40:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:54 +0200 (CEST) Received: (qmail 15412 invoked by uid 0); 23 May 2001 16:32:08 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx25) with SMTP; 23 May 2001 16:32:08 -0000 X-eGroups-Return: sentto-1101623-2854-990628940-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ho.egroups.com with NNFMP; 23 May 2001 14:42:21 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 14:42:18 -0000 Received: (qmail 17430 invoked from network); 23 May 2001 14:35:47 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 23 May 2001 14:35:47 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 14:35:47 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEZlC21740 for ; Wed, 23 May 2001 07:35:47 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEZkr21733 for ; Wed, 23 May 2001 07:35:47 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NEZVF20078 for ; Wed, 23 May 2001 07:35:31 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id HAA21569; Wed, 23 May 2001 07:35:41 -0700 (PDT) Message-Id: <200105231435.HAA21569@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231428.HAA21553@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 07:35:41 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] utopia webring Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> Subject: Re: Re: [f-cpu] utopia webring
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > Subject: Re: [f-cpu] utopia webring
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > Subject: [f-cpu] utopia webring
> > >
> > > Hi,
> > >
> > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > yesterday, and there are some hiccups with getting everything working on
> > > the new machine. It should be back up by tomorrow.
> > >
> > > Graham
> > >
> > >
> > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:13:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9X-0000ME-00 for ; Mon, 28 May 2001 01:40:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:40:55 +0200 (CEST) Received: (qmail 14007 invoked by uid 0); 23 May 2001 16:49:35 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 16:49:35 -0000 X-eGroups-Return: sentto-1101623-2865-990634894-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hm.egroups.com with NNFMP; 23 May 2001 16:21:35 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:21:33 -0000 Received: (qmail 66032 invoked from network); 23 May 2001 16:13:40 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 May 2001 16:13:40 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 16:13:40 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGDTa05926 for ; Wed, 23 May 2001 09:13:29 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGDTr05922 for ; Wed, 23 May 2001 09:13:29 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGDDF29528 for ; Wed, 23 May 2001 09:13:13 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23390; Wed, 23 May 2001 09:13:23 -0700 (PDT) Message-Id: <200105231613.JAA23390@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231604.JAA23328@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:13:23 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:57:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9f-0000ME-00 for ; Mon, 28 May 2001 01:41:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:03 +0200 (CEST) Received: (qmail 4234 invoked by uid 0); 23 May 2001 17:05:11 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx06) with SMTP; 23 May 2001 17:05:11 -0000 X-eGroups-Return: sentto-1101623-2870-990637505-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ml.egroups.com with NNFMP; 23 May 2001 17:05:10 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:05:02 -0000 Received: (qmail 15541 invoked from network); 23 May 2001 16:57:24 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 23 May 2001 16:57:24 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 16:57:24 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGvNU17586 for ; Wed, 23 May 2001 09:57:23 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGvNr17578 for ; Wed, 23 May 2001 09:57:23 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGv7F07254 for ; Wed, 23 May 2001 09:57:07 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23737; Wed, 23 May 2001 09:57:17 -0700 (PDT) Message-Id: <200105231657.JAA23737@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231649.JAA23705@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:57:17 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:49:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9q-0000ME-00 for ; Mon, 28 May 2001 01:41:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:14 +0200 (CEST) Received: (qmail 12028 invoked by uid 0); 23 May 2001 17:07:26 -0000 Received: from hm.egroups.com (208.50.99.198) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 17:07:26 -0000 X-eGroups-Return: sentto-1101623-2869-990637000-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hm.egroups.com with NNFMP; 23 May 2001 16:56:43 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:56:37 -0000 Received: (qmail 71572 invoked from network); 23 May 2001 16:49:58 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 16:49:58 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 16:49:58 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGnvR15980 for ; Wed, 23 May 2001 09:49:57 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGnvr15974 for ; Wed, 23 May 2001 09:49:57 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGnfF06155 for ; Wed, 23 May 2001 09:49:41 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23705; Wed, 23 May 2001 09:49:51 -0700 (PDT) Message-Id: <200105231649.JAA23705@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231640.JAA23628@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:49:51 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:22:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154A9z-0000ME-00 for ; Mon, 28 May 2001 01:41:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:23 +0200 (CEST) Received: (qmail 5268 invoked by uid 0); 23 May 2001 17:11:22 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx003-rz3) with SMTP; 23 May 2001 17:11:22 -0000 X-eGroups-Return: sentto-1101623-2866-990635482-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ef.egroups.com with NNFMP; 23 May 2001 16:31:24 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:31:21 -0000 Received: (qmail 13563 invoked from network); 23 May 2001 16:22:16 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 23 May 2001 16:22:16 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 16:22:16 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGMFg08025 for ; Wed, 23 May 2001 09:22:15 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGMEr08021 for ; Wed, 23 May 2001 09:22:14 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGLxF00967 for ; Wed, 23 May 2001 09:21:59 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23446; Wed, 23 May 2001 09:22:09 -0700 (PDT) Message-Id: <200105231622.JAA23446@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231613.JAA23390@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:22:09 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:05:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AA7-0000ME-00 for ; Mon, 28 May 2001 01:41:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:31 +0200 (CEST) Received: (qmail 12149 invoked by uid 0); 23 May 2001 17:12:06 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx007-rz3) with SMTP; 23 May 2001 17:12:06 -0000 X-eGroups-Return: sentto-1101623-2871-990637923-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 23 May 2001 17:12:05 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:12:02 -0000 Received: (qmail 41277 invoked from network); 23 May 2001 17:05:59 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 May 2001 17:05:59 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 17:05:59 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NH5vL19959 for ; Wed, 23 May 2001 10:05:57 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NH5vr19952 for ; Wed, 23 May 2001 10:05:57 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NH5fF08793 for ; Wed, 23 May 2001 10:05:41 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA23773; Wed, 23 May 2001 10:05:51 -0700 (PDT) Message-Id: <200105231705.KAA23773@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231657.JAA23737@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:05:51 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:12:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AAH-0000ME-00 for ; Mon, 28 May 2001 01:41:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:41 +0200 (CEST) Received: (qmail 18573 invoked by uid 0); 23 May 2001 17:18:56 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx21) with SMTP; 23 May 2001 17:18:56 -0000 X-eGroups-Return: sentto-1101623-2872-990638331-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by fh.egroups.com with NNFMP; 23 May 2001 17:18:55 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:18:48 -0000 Received: (qmail 61081 invoked from network); 23 May 2001 17:12:45 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 23 May 2001 17:12:45 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 17:12:45 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHCib21624 for ; Wed, 23 May 2001 10:12:44 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHCir21616 for ; Wed, 23 May 2001 10:12:44 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHCSF09881 for ; Wed, 23 May 2001 10:12:28 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA23818; Wed, 23 May 2001 10:12:38 -0700 (PDT) Message-Id: <200105231712.KAA23818@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231705.KAA23773@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:12:38 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:56:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AAT-0000ME-00 for ; Mon, 28 May 2001 01:41:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:53 +0200 (CEST) Received: (qmail 8832 invoked by uid 0); 23 May 2001 17:23:36 -0000 Received: from hp.egroups.com (208.50.99.201) by mx0.gmx.net (mx01) with SMTP; 23 May 2001 17:23:36 -0000 X-eGroups-Return: sentto-1101623-2863-990633828-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hp.egroups.com with NNFMP; 23 May 2001 16:03:52 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:03:47 -0000 Received: (qmail 4028 invoked from network); 23 May 2001 15:56:34 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 15:56:34 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 15:56:34 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFuXg02936 for ; Wed, 23 May 2001 08:56:33 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFuWr02930 for ; Wed, 23 May 2001 08:56:33 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFuHF27199 for ; Wed, 23 May 2001 08:56:17 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA23307; Wed, 23 May 2001 08:56:27 -0700 (PDT) Message-Id: <200105231556.IAA23307@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231546.IAA23272@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:56:27 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > >
> > > > > > > > > > > > Graham
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:26:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AAZ-0000ME-00 for ; Mon, 28 May 2001 01:41:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:41:59 +0200 (CEST) Received: (qmail 6781 invoked by uid 0); 23 May 2001 17:31:36 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx08) with SMTP; 23 May 2001 17:31:36 -0000 X-eGroups-Return: sentto-1101623-2874-990639089-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 23 May 2001 17:31:34 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:31:28 -0000 Received: (qmail 88173 invoked from network); 23 May 2001 17:26:22 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 17:26:22 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 17:26:22 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHQL124615 for ; Wed, 23 May 2001 10:26:21 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHQKr24611 for ; Wed, 23 May 2001 10:26:20 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHQ5F11879 for ; Wed, 23 May 2001 10:26:05 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA23922; Wed, 23 May 2001 10:26:15 -0700 (PDT) Message-Id: <200105231726.KAA23922@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231719.KAA23842@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:26:15 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:32:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AAm-0000ME-00 for ; Mon, 28 May 2001 01:42:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:42:12 +0200 (CEST) Received: (qmail 14826 invoked by uid 0); 23 May 2001 17:36:41 -0000 Received: from ch.egroups.com (208.50.99.226) by mx0.gmx.net (mx18) with SMTP; 23 May 2001 17:36:41 -0000 X-eGroups-Return: sentto-1101623-2875-990639393-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ch.egroups.com with NNFMP; 23 May 2001 17:36:38 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:36:29 -0000 Received: (qmail 9090 invoked from network); 23 May 2001 17:32:19 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 17:32:19 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 17:32:19 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHWIi25762 for ; Wed, 23 May 2001 10:32:18 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHWHr25758 for ; Wed, 23 May 2001 10:32:17 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHW2F12757 for ; Wed, 23 May 2001 10:32:02 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA23948; Wed, 23 May 2001 10:32:12 -0700 (PDT) Message-Id: <200105231732.KAA23948@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231726.KAA23922@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:32:12 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:31:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AB1-0000ME-00 for ; Mon, 28 May 2001 01:42:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:42:27 +0200 (CEST) Received: (qmail 16503 invoked by uid 0); 23 May 2001 17:40:21 -0000 Received: from c9.egroups.com (208.50.99.230) by mx0.gmx.net (mx04) with SMTP; 23 May 2001 17:40:21 -0000 X-eGroups-Return: sentto-1101623-2867-990635980-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by c9.egroups.com with NNFMP; 23 May 2001 16:39:41 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:39:39 -0000 Received: (qmail 71044 invoked from network); 23 May 2001 16:32:04 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 23 May 2001 16:32:04 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 16:32:03 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGW3K10514 for ; Wed, 23 May 2001 09:32:03 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGW2r10510 for ; Wed, 23 May 2001 09:32:02 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGVlF02630 for ; Wed, 23 May 2001 09:31:47 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23540; Wed, 23 May 2001 09:31:57 -0700 (PDT) Message-Id: <200105231631.JAA23540@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231622.JAA23446@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:31:57 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 17:24:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ABB-0000ME-00 for ; Mon, 28 May 2001 01:42:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:42:37 +0200 (CEST) Received: (qmail 22147 invoked by uid 0); 23 May 2001 17:41:38 -0000 Received: from mu.egroups.com (64.211.240.238) by mx0.gmx.net (mx18) with SMTP; 23 May 2001 17:41:38 -0000 X-eGroups-Return: sentto-1101623-2860-990631995-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mu.egroups.com with NNFMP; 23 May 2001 15:33:16 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 15:33:15 -0000 Received: (qmail 70256 invoked from network); 23 May 2001 15:24:36 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 May 2001 15:24:36 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 15:24:36 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFOZo28337 for ; Wed, 23 May 2001 08:24:36 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFOZr28333 for ; Wed, 23 May 2001 08:24:35 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NFOJF23970 for ; Wed, 23 May 2001 08:24:20 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id IAA21747; Wed, 23 May 2001 08:24:29 -0700 (PDT) Message-Id: <200105231524.IAA21747@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231515.IAA21739@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 08:24:29 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > >
> > > > > > > > > Graham
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:19:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ABF-0000ME-00 for ; Mon, 28 May 2001 01:42:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:42:41 +0200 (CEST) Received: (qmail 13806 invoked by uid 0); 23 May 2001 17:42:50 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx15) with SMTP; 23 May 2001 17:42:50 -0000 X-eGroups-Return: sentto-1101623-2873-990638739-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ho.egroups.com with NNFMP; 23 May 2001 17:25:40 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:25:38 -0000 Received: (qmail 81496 invoked from network); 23 May 2001 17:19:40 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 23 May 2001 17:19:40 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 17:19:40 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHJdN23144 for ; Wed, 23 May 2001 10:19:39 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHJcr23139 for ; Wed, 23 May 2001 10:19:38 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHJMF10883 for ; Wed, 23 May 2001 10:19:23 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA23842; Wed, 23 May 2001 10:19:32 -0700 (PDT) Message-Id: <200105231719.KAA23842@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231712.KAA23818@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:19:32 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:52:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ABR-0000ME-00 for ; Mon, 28 May 2001 01:42:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:42:53 +0200 (CEST) Received: (qmail 4611 invoked by uid 0); 23 May 2001 17:55:10 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx19) with SMTP; 23 May 2001 17:55:10 -0000 X-eGroups-Return: sentto-1101623-2879-990640498-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hh.egroups.com with NNFMP; 23 May 2001 17:55:00 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:54:57 -0000 Received: (qmail 80532 invoked from network); 23 May 2001 17:52:48 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 May 2001 17:52:48 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 17:52:48 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHqjn00433 for ; Wed, 23 May 2001 10:52:45 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHqjr00428 for ; Wed, 23 May 2001 10:52:45 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHqTF15933 for ; Wed, 23 May 2001 10:52:29 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA24120; Wed, 23 May 2001 10:52:39 -0700 (PDT) Message-Id: <200105231752.KAA24120@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231747.KAA24040@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:52:39 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
YAHOO! DOMAINS YAHOO! DOMAINS

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:55:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ABk-0000ME-00 for ; Mon, 28 May 2001 01:43:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:43:12 +0200 (CEST) Received: (qmail 13142 invoked by uid 0); 23 May 2001 17:59:41 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx24) with SMTP; 23 May 2001 17:59:41 -0000 X-eGroups-Return: sentto-1101623-2880-990640697-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hn.egroups.com with NNFMP; 23 May 2001 17:58:23 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:58:16 -0000 Received: (qmail 91550 invoked from network); 23 May 2001 17:55:51 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 May 2001 17:55:51 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 17:55:51 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHtoo01572 for ; Wed, 23 May 2001 10:55:50 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHtnr01568 for ; Wed, 23 May 2001 10:55:49 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHtYF16424 for ; Wed, 23 May 2001 10:55:34 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA24169; Wed, 23 May 2001 10:55:43 -0700 (PDT) Message-Id: <200105231755.KAA24169@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231752.KAA24120@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:55:43 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:01:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AC4-0000ME-00 for ; Mon, 28 May 2001 01:43:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:43:32 +0200 (CEST) Received: (qmail 32621 invoked by uid 0); 23 May 2001 18:02:59 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx09) with SMTP; 23 May 2001 18:02:59 -0000 X-eGroups-Return: sentto-1101623-2882-990640960-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by jk.egroups.com with NNFMP; 23 May 2001 18:02:43 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:02:40 -0000 Received: (qmail 1806 invoked from network); 23 May 2001 18:01:19 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 23 May 2001 18:01:19 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:01:19 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI1HW02663 for ; Wed, 23 May 2001 11:01:17 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI1Gr02656 for ; Wed, 23 May 2001 11:01:16 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI10F17308 for ; Wed, 23 May 2001 11:01:01 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24254; Wed, 23 May 2001 11:01:11 -0700 (PDT) Message-Id: <200105231801.LAA24254@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231759.KAA24226@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:01:11 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:06:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ACQ-0000ME-00 for ; Mon, 28 May 2001 01:43:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:43:54 +0200 (CEST) Received: (qmail 1365 invoked by uid 0); 23 May 2001 18:07:28 -0000 Received: from mq.egroups.com (208.50.144.79) by mx0.gmx.net (mx16) with SMTP; 23 May 2001 18:07:28 -0000 X-eGroups-Return: sentto-1101623-2885-990641241-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mq.egroups.com with NNFMP; 23 May 2001 18:07:26 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:07:20 -0000 Received: (qmail 79957 invoked from network); 23 May 2001 18:06:51 -0000 Received: from unknown (10.1.10.142) by l10.egroups.com with QMQP; 23 May 2001 18:06:51 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:06:49 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI6md04068 for ; Wed, 23 May 2001 11:06:48 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI6mr04060 for ; Wed, 23 May 2001 11:06:48 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI6WF18332 for ; Wed, 23 May 2001 11:06:32 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24320; Wed, 23 May 2001 11:06:42 -0700 (PDT) Message-Id: <200105231806.LAA24320@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231804.LAA24305@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:06:42 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:42:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ACp-0000ME-00 for ; Mon, 28 May 2001 01:44:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:44:19 +0200 (CEST) Received: (qmail 20372 invoked by uid 0); 23 May 2001 18:09:22 -0000 Received: from ef.egroups.com (64.211.240.229) by mx0.gmx.net (mx001-rz3) with SMTP; 23 May 2001 18:09:22 -0000 X-eGroups-Return: sentto-1101623-2877-990640014-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ef.egroups.com with NNFMP; 23 May 2001 17:46:58 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 17:46:53 -0000 Received: (qmail 39520 invoked from network); 23 May 2001 17:42:21 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 17:42:21 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 17:42:21 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHgKP27547 for ; Wed, 23 May 2001 10:42:20 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHgJr27543 for ; Wed, 23 May 2001 10:42:19 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHg3F14070 for ; Wed, 23 May 2001 10:42:03 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA24015; Wed, 23 May 2001 10:42:13 -0700 (PDT) Message-Id: <200105231742.KAA24015@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231737.KAA23979@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:42:13 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.debticated.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:10:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AD6-0000ME-00 for ; Mon, 28 May 2001 01:44:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:44:36 +0200 (CEST) Received: (qmail 15428 invoked by uid 0); 23 May 2001 18:11:36 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx22) with SMTP; 23 May 2001 18:11:36 -0000 X-eGroups-Return: sentto-1101623-2888-990641491-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 23 May 2001 18:11:35 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:11:30 -0000 Received: (qmail 36681 invoked from network); 23 May 2001 18:10:53 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 May 2001 18:10:53 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:10:53 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIAqE05027 for ; Wed, 23 May 2001 11:10:52 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIApr05023 for ; Wed, 23 May 2001 11:10:51 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIAZF18983 for ; Wed, 23 May 2001 11:10:35 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24378; Wed, 23 May 2001 11:10:45 -0700 (PDT) Message-Id: <200105231810.LAA24378@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231808.LAA24336@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:10:45 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 19:59:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ADa-0000ME-00 for ; Mon, 28 May 2001 01:45:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:45:06 +0200 (CEST) Received: (qmail 10221 invoked by uid 0); 23 May 2001 18:13:25 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx06) with SMTP; 23 May 2001 18:13:25 -0000 X-eGroups-Return: sentto-1101623-2881-990640836-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 23 May 2001 18:00:38 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:00:36 -0000 Received: (qmail 96968 invoked from network); 23 May 2001 17:59:26 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 17:59:26 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 17:59:26 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHxP302291 for ; Wed, 23 May 2001 10:59:25 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHxPr02285 for ; Wed, 23 May 2001 10:59:25 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NHx9F16978 for ; Wed, 23 May 2001 10:59:09 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id KAA24226; Wed, 23 May 2001 10:59:19 -0700 (PDT) Message-Id: <200105231759.KAA24226@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231755.KAA24169@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 10:59:19 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:03:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ADv-0000ME-00 for ; Mon, 28 May 2001 01:45:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:45:27 +0200 (CEST) Received: (qmail 30335 invoked by uid 0); 23 May 2001 18:14:19 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx14) with SMTP; 23 May 2001 18:14:19 -0000 X-eGroups-Return: sentto-1101623-2883-990641047-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 23 May 2001 18:04:09 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:04:07 -0000 Received: (qmail 64867 invoked from network); 23 May 2001 18:03:39 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 May 2001 18:03:39 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:03:39 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI3cw03091 for ; Wed, 23 May 2001 11:03:38 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI3br03084 for ; Wed, 23 May 2001 11:03:37 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI3LF17660 for ; Wed, 23 May 2001 11:03:21 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24288; Wed, 23 May 2001 11:03:31 -0700 (PDT) Message-Id: <200105231803.LAA24288@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231801.LAA24254@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:03:31 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:08:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AEI-0000ME-00 for ; Mon, 28 May 2001 01:45:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:45:50 +0200 (CEST) Received: (qmail 15569 invoked by uid 0); 23 May 2001 18:15:37 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 23 May 2001 18:15:37 -0000 X-eGroups-Return: sentto-1101623-2887-990641406-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 23 May 2001 18:10:07 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:10:05 -0000 Received: (qmail 23837 invoked from network); 23 May 2001 18:09:03 -0000 Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 23 May 2001 18:09:03 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:09:03 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI92R04620 for ; Wed, 23 May 2001 11:09:02 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI91r04616 for ; Wed, 23 May 2001 11:09:01 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI8jF18695 for ; Wed, 23 May 2001 11:08:45 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24336; Wed, 23 May 2001 11:08:55 -0700 (PDT) Message-Id: <200105231808.LAA24336@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231808.LAA24328@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:08:55 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:17:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AEk-0000ME-00 for ; Mon, 28 May 2001 01:46:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:46:18 +0200 (CEST) Received: (qmail 12505 invoked by uid 0); 23 May 2001 18:21:15 -0000 Received: from b05.egroups.com (208.50.144.96) by mx0.gmx.net (mx19) with SMTP; 23 May 2001 18:21:15 -0000 X-eGroups-Return: sentto-1101623-2891-990642065-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by b05.egroups.com with NNFMP; 23 May 2001 18:21:11 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:21:00 -0000 Received: (qmail 6765 invoked from network); 23 May 2001 18:17:54 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 23 May 2001 18:17:54 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:17:53 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIHpi06674 for ; Wed, 23 May 2001 11:17:52 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIHpr06670 for ; Wed, 23 May 2001 11:17:51 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIHZF20058 for ; Wed, 23 May 2001 11:17:35 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24454; Wed, 23 May 2001 11:17:45 -0700 (PDT) Message-Id: <200105231817.LAA24454@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231814.LAA24437@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:17:45 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:21:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AFI-0000ME-00 for ; Mon, 28 May 2001 01:46:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:46:52 +0200 (CEST) Received: (qmail 13070 invoked by uid 0); 23 May 2001 18:22:50 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx08) with SMTP; 23 May 2001 18:22:50 -0000 X-eGroups-Return: sentto-1101623-2892-990642162-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 23 May 2001 18:22:49 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:22:40 -0000 Received: (qmail 21695 invoked from network); 23 May 2001 18:21:53 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 23 May 2001 18:21:53 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:21:53 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NILqI07542 for ; Wed, 23 May 2001 11:21:52 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NILpr07538 for ; Wed, 23 May 2001 11:21:51 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NILZF20658 for ; Wed, 23 May 2001 11:21:35 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24493; Wed, 23 May 2001 11:21:45 -0700 (PDT) Message-Id: <200105231821.LAA24493@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231817.LAA24454@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:21:45 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:23:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AFq-0000ME-00 for ; Mon, 28 May 2001 01:47:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:47:26 +0200 (CEST) Received: (qmail 15914 invoked by uid 0); 23 May 2001 18:26:52 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx14) with SMTP; 23 May 2001 18:26:52 -0000 X-eGroups-Return: sentto-1101623-2893-990642259-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 23 May 2001 18:24:24 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:24:17 -0000 Received: (qmail 27504 invoked from network); 23 May 2001 18:23:50 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 May 2001 18:23:50 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:23:50 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NINcB08114 for ; Wed, 23 May 2001 11:23:38 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NINbr08084 for ; Wed, 23 May 2001 11:23:37 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NINKF21015 for ; Wed, 23 May 2001 11:23:20 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24514; Wed, 23 May 2001 11:23:30 -0700 (PDT) Message-Id: <200105231823.LAA24514@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231821.LAA24493@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:23:30 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:25:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AGR-0000ME-00 for ; Mon, 28 May 2001 01:48:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:48:03 +0200 (CEST) Received: (qmail 25940 invoked by uid 0); 23 May 2001 18:32:13 -0000 Received: from jj.egroups.com (208.50.144.82) by mx0.gmx.net (mx14) with SMTP; 23 May 2001 18:32:13 -0000 X-eGroups-Return: sentto-1101623-2894-990642321-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by jj.egroups.com with NNFMP; 23 May 2001 18:25:23 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:25:21 -0000 Received: (qmail 30465 invoked from network); 23 May 2001 18:25:10 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 23 May 2001 18:25:10 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:25:10 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIP8o08645 for ; Wed, 23 May 2001 11:25:08 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIP7r08638 for ; Wed, 23 May 2001 11:25:08 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIOpF21280 for ; Wed, 23 May 2001 11:24:51 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24522; Wed, 23 May 2001 11:25:01 -0700 (PDT) Message-Id: <200105231825.LAA24522@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231823.LAA24514@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:25:01 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:12:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AH3-0000ME-00 for ; Mon, 28 May 2001 01:48:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:48:41 +0200 (CEST) Received: (qmail 30468 invoked by uid 0); 23 May 2001 18:34:43 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx27) with SMTP; 23 May 2001 18:34:43 -0000 X-eGroups-Return: sentto-1101623-2889-990641645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 23 May 2001 18:14:07 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:14:02 -0000 Received: (qmail 34611 invoked from network); 23 May 2001 18:12:21 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 18:12:21 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:12:21 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NICIJ05454 for ; Wed, 23 May 2001 11:12:18 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NICHr05442 for ; Wed, 23 May 2001 11:12:17 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIC1F19232 for ; Wed, 23 May 2001 11:12:01 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24413; Wed, 23 May 2001 11:12:11 -0700 (PDT) Message-Id: <200105231812.LAA24413@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231810.LAA24378@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:12:11 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:28:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AHX-0000ME-00 for ; Mon, 28 May 2001 01:49:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:49:11 +0200 (CEST) Received: (qmail 16567 invoked by uid 0); 23 May 2001 18:34:25 -0000 Received: from cj.egroups.com (208.50.144.68) by mx0.gmx.net (mx23) with SMTP; 23 May 2001 18:34:25 -0000 X-eGroups-Return: sentto-1101623-2897-990642645-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by cj.egroups.com with NNFMP; 23 May 2001 18:30:52 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:30:42 -0000 Received: (qmail 38471 invoked from network); 23 May 2001 18:28:55 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 23 May 2001 18:28:55 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:28:55 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NISsf09446 for ; Wed, 23 May 2001 11:28:54 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NISrr09442 for ; Wed, 23 May 2001 11:28:53 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NISbF21864 for ; Wed, 23 May 2001 11:28:37 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24571; Wed, 23 May 2001 11:28:47 -0700 (PDT) Message-Id: <200105231828.LAA24571@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231827.LAA24546@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:28:47 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:35:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AIE-0000ME-00 for ; Mon, 28 May 2001 01:49:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:49:54 +0200 (CEST) Received: (qmail 29140 invoked by uid 0); 23 May 2001 18:36:45 -0000 Received: from n2.groups.yahoo.com (HELO hi.egroups.com) (216.115.96.52) by mx0.gmx.net (mx15) with SMTP; 23 May 2001 18:36:45 -0000 X-eGroups-Return: sentto-1101623-2900-990643000-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hi.egroups.com with NNFMP; 23 May 2001 18:36:44 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:36:40 -0000 Received: (qmail 62823 invoked from network); 23 May 2001 18:35:55 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 23 May 2001 18:35:55 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:35:55 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIZrK10877 for ; Wed, 23 May 2001 11:35:53 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIZqr10873 for ; Wed, 23 May 2001 11:35:52 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIZaF22842 for ; Wed, 23 May 2001 11:35:36 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24619; Wed, 23 May 2001 11:35:46 -0700 (PDT) Message-Id: <200105231835.LAA24619@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231833.LAA24600@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:35:46 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:39:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AIz-0000ME-00 for ; Mon, 28 May 2001 01:50:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:50:41 +0200 (CEST) Received: (qmail 16169 invoked by uid 0); 23 May 2001 18:40:24 -0000 Received: from ml.egroups.com (208.50.144.77) by mx0.gmx.net (mx18) with SMTP; 23 May 2001 18:40:24 -0000 X-eGroups-Return: sentto-1101623-2902-990643222-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ml.egroups.com with NNFMP; 23 May 2001 18:40:23 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:40:21 -0000 Received: (qmail 71471 invoked from network); 23 May 2001 18:39:47 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 May 2001 18:39:47 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:39:46 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIdjp11975 for ; Wed, 23 May 2001 11:39:45 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIdir11967 for ; Wed, 23 May 2001 11:39:44 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIdRF23432 for ; Wed, 23 May 2001 11:39:28 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24667; Wed, 23 May 2001 11:39:37 -0700 (PDT) Message-Id: <200105231839.LAA24667@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231837.LAA24628@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:39:37 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:40:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AJp-0000ME-00 for ; Mon, 28 May 2001 01:51:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:51:33 +0200 (CEST) Received: (qmail 9082 invoked by uid 0); 23 May 2001 18:41:14 -0000 Received: from jk.egroups.com (208.50.144.83) by mx0.gmx.net (mx12) with SMTP; 23 May 2001 18:41:14 -0000 X-eGroups-Return: sentto-1101623-2903-990643271-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by jk.egroups.com with NNFMP; 23 May 2001 18:41:14 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:41:11 -0000 Received: (qmail 27480 invoked from network); 23 May 2001 18:41:06 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 23 May 2001 18:41:06 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:41:06 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIf4R12221 for ; Wed, 23 May 2001 11:41:04 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIf3r12217 for ; Wed, 23 May 2001 11:41:03 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIelF23666 for ; Wed, 23 May 2001 11:40:47 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24676; Wed, 23 May 2001 11:40:57 -0700 (PDT) Message-Id: <200105231840.LAA24676@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231839.LAA24667@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:40:57 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:42:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AKg-0000ME-00 for ; Mon, 28 May 2001 01:52:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:52:26 +0200 (CEST) Received: (qmail 22772 invoked by uid 0); 23 May 2001 18:43:32 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx16) with SMTP; 23 May 2001 18:43:32 -0000 X-eGroups-Return: sentto-1101623-2905-990643401-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hk.egroups.com with NNFMP; 23 May 2001 18:43:30 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:43:20 -0000 Received: (qmail 81883 invoked from network); 23 May 2001 18:42:52 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 May 2001 18:42:52 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 18:42:51 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIgoc12667 for ; Wed, 23 May 2001 11:42:50 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIgnr12658 for ; Wed, 23 May 2001 11:42:49 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIgXF23923 for ; Wed, 23 May 2001 11:42:33 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24734; Wed, 23 May 2001 11:42:42 -0700 (PDT) Message-Id: <200105231842.LAA24734@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231841.LAA24712@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:42:42 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:45:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ALa-0000ME-00 for ; Mon, 28 May 2001 01:53:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:53:22 +0200 (CEST) Received: (qmail 9708 invoked by uid 0); 23 May 2001 18:46:40 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx001-rz3) with SMTP; 23 May 2001 18:46:40 -0000 X-eGroups-Return: sentto-1101623-2907-990643590-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hj.egroups.com with NNFMP; 23 May 2001 18:46:40 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:46:26 -0000 Received: (qmail 23525 invoked from network); 23 May 2001 18:45:13 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 May 2001 18:45:13 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:45:12 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIjBY13165 for ; Wed, 23 May 2001 11:45:11 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIjAr13161 for ; Wed, 23 May 2001 11:45:10 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIisF24230 for ; Wed, 23 May 2001 11:44:54 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24767; Wed, 23 May 2001 11:45:04 -0700 (PDT) Message-Id: <200105231845.LAA24767@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231844.LAA24745@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:45:04 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:47:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AMZ-0000ME-00 for ; Mon, 28 May 2001 01:54:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:54:23 +0200 (CEST) Received: (qmail 27263 invoked by uid 0); 23 May 2001 18:48:03 -0000 Received: from fh.egroups.com (208.50.144.71) by mx0.gmx.net (mx007-rz3) with SMTP; 23 May 2001 18:48:03 -0000 X-eGroups-Return: sentto-1101623-2908-990643667-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fh.egroups.com with NNFMP; 23 May 2001 18:47:52 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:47:47 -0000 Received: (qmail 45992 invoked from network); 23 May 2001 18:47:20 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 23 May 2001 18:47:20 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:47:19 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIlHh13759 for ; Wed, 23 May 2001 11:47:17 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIlGr13752 for ; Wed, 23 May 2001 11:47:16 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIl0F24610 for ; Wed, 23 May 2001 11:47:00 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24811; Wed, 23 May 2001 11:47:10 -0700 (PDT) Message-Id: <200105231847.LAA24811@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231845.LAA24767@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:47:10 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:50:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ANa-0000ME-00 for ; Mon, 28 May 2001 01:55:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:55:26 +0200 (CEST) Received: (qmail 23011 invoked by uid 0); 23 May 2001 18:51:33 -0000 Received: from n1.groups.yahoo.com (HELO hh.egroups.com) (216.115.96.51) by mx0.gmx.net (mx19) with SMTP; 23 May 2001 18:51:33 -0000 X-eGroups-Return: sentto-1101623-2910-990643880-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by hh.egroups.com with NNFMP; 23 May 2001 18:51:32 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:51:16 -0000 Received: (qmail 45592 invoked from network); 23 May 2001 18:50:50 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 18:50:50 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:50:50 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIom915051 for ; Wed, 23 May 2001 11:50:48 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIolr15047 for ; Wed, 23 May 2001 11:50:47 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIoVF25208 for ; Wed, 23 May 2001 11:50:31 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24850; Wed, 23 May 2001 11:50:41 -0700 (PDT) Message-Id: <200105231850.LAA24850@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231848.LAA24827@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:50:41 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:48:30 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:47:10 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Say you love them
with a DOMAIN NAME!

www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:27:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AOe-0000ME-00 for ; Mon, 28 May 2001 01:56:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:56:32 +0200 (CEST) Received: (qmail 19793 invoked by uid 0); 23 May 2001 18:51:04 -0000 Received: from hn.egroups.com (208.50.99.199) by mx0.gmx.net (mx13) with SMTP; 23 May 2001 18:51:04 -0000 X-eGroups-Return: sentto-1101623-2896-990642491-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hn.egroups.com with NNFMP; 23 May 2001 18:28:14 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:28:09 -0000 Received: (qmail 76902 invoked from network); 23 May 2001 18:27:17 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 23 May 2001 18:27:17 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 18:27:16 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIRFa09065 for ; Wed, 23 May 2001 11:27:15 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIRFr09061 for ; Wed, 23 May 2001 11:27:15 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIQxF21634 for ; Wed, 23 May 2001 11:26:59 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24546; Wed, 23 May 2001 11:27:09 -0700 (PDT) Message-Id: <200105231827.LAA24546@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231826.LAA24531@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:27:09 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 21:01:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154APK-0000ME-00 for ; Mon, 28 May 2001 01:57:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:57:14 +0200 (CEST) Received: (qmail 3692 invoked by uid 0); 23 May 2001 19:01:52 -0000 Received: from n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by mx0.gmx.net (mx30) with SMTP; 23 May 2001 19:01:52 -0000 X-eGroups-Return: sentto-1101623-2914-990644505-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 23 May 2001 19:01:50 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:01:44 -0000 Received: (qmail 32208 invoked from network); 23 May 2001 19:01:19 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 May 2001 19:01:19 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 19:01:19 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ1HB17042 for ; Wed, 23 May 2001 12:01:17 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ1Gr17036 for ; Wed, 23 May 2001 12:01:16 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ10F26592 for ; Wed, 23 May 2001 12:01:00 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id MAA24943; Wed, 23 May 2001 12:01:10 -0700 (PDT) Message-Id: <200105231901.MAA24943@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231858.LAA24916@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 12:01:10 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:58:55 -0700 (PDT)
> Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:54:34 -0700 (PDT)
> > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:52:17 -0700 (PDT)
> > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:50:41 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:48:30 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:47:10 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 21:02:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AQW-0000ME-00 for ; Mon, 28 May 2001 01:58:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:58:28 +0200 (CEST) Received: (qmail 10920 invoked by uid 0); 23 May 2001 19:04:17 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx13) with SMTP; 23 May 2001 19:04:17 -0000 X-eGroups-Return: sentto-1101623-2915-990644649-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hj.egroups.com with NNFMP; 23 May 2001 19:04:16 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:04:08 -0000 Received: (qmail 35620 invoked from network); 23 May 2001 19:02:36 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 23 May 2001 19:02:36 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 19:02:36 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ2ZP17209 for ; Wed, 23 May 2001 12:02:35 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ2Yr17205 for ; Wed, 23 May 2001 12:02:34 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ2HF26748 for ; Wed, 23 May 2001 12:02:17 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id MAA24951; Wed, 23 May 2001 12:02:27 -0700 (PDT) Message-Id: <200105231902.MAA24951@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231901.MAA24943@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 12:02:27 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 12:01:10 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:58:55 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:54:34 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:52:17 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:50:41 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:48:30 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:47:10 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From mota@april.org Wed May 23 20:53:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ARk-0000ME-00 for ; Mon, 28 May 2001 01:59:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:59:44 +0200 (CEST) Received: (qmail 6548 invoked by uid 0); 23 May 2001 19:05:37 -0000 Received: from mv.egroups.com (208.50.144.81) by mx0.gmx.net (mx27) with SMTP; 23 May 2001 19:05:37 -0000 X-eGroups-Return: sentto-1101623-2916-990644735-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mv.egroups.com with NNFMP; 23 May 2001 19:05:35 -0000 X-Sender: mota@april.org X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:05:34 -0000 Received: (qmail 84072 invoked from network); 23 May 2001 19:04:22 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 19:04:22 -0000 Received: from unknown (HELO ns1.april.org) (213.228.61.225) by mta2 with SMTP; 23 May 2001 19:04:22 -0000 Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 152dlD-0001Ch-00 for ; Wed, 23 May 2001 20:53:31 +0200 To: f-cpu@yahoogroups.com Message-ID: <20010523205331.E24571@opium.april.org> References: <200105231845.LAA24767@majordomo.svd.avanticorp.com> <200105231847.LAA24811@majordomo.svd.avanticorp.com> User-Agent: Mutt/1.2.5i In-Reply-To: <200105231847.LAA24811@majordomo.svd.avanticorp.com>; from swchen@avanticorp.com on Wed, May 23, 2001 at 11:47:10AM -0700 From: Paul Marques Mota MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 20:53:31 +0200 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The mailing-list loop has been handled at the Avant! Corporation Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Hello,

I just mailed the avanticorp.com staff about this and their statement about
this whole affair is that the auto-reply is part of their company policy; the
email alias will last for a couple of month...

I therefore strongly advise anyone that is willing to act upon this to not
contact this company: they are well aware of this problem now. Instead, please
contact the yahoo group administrator, <f-cpu-owner@makelist.com>

Thank you for your attention.
--
      Paul
Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:48:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ARl-0000ME-00 for ; Mon, 28 May 2001 01:59:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 01:59:45 +0200 (CEST) Received: (qmail 12761 invoked by uid 0); 23 May 2001 19:11:32 -0000 Received: from hl.egroups.com (208.50.99.197) by mx0.gmx.net (mx14) with SMTP; 23 May 2001 19:11:32 -0000 X-eGroups-Return: sentto-1101623-2909-990643766-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by hl.egroups.com with NNFMP; 23 May 2001 18:49:42 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:49:21 -0000 Received: (qmail 96724 invoked from network); 23 May 2001 18:48:39 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 23 May 2001 18:48:39 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:48:38 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NImbM14082 for ; Wed, 23 May 2001 11:48:37 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NImar14073 for ; Wed, 23 May 2001 11:48:36 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NImKF24793 for ; Wed, 23 May 2001 11:48:20 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24827; Wed, 23 May 2001 11:48:30 -0700 (PDT) Message-Id: <200105231848.LAA24827@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231847.LAA24811@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:48:30 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:47:10 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:08:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ASn-0000ME-00 for ; Mon, 28 May 2001 02:00:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:00:49 +0200 (CEST) Received: (qmail 32056 invoked by uid 0); 23 May 2001 19:07:40 -0000 Received: from f19.egroups.com (64.211.240.234) by mx0.gmx.net (mx009-rz3) with SMTP; 23 May 2001 19:07:40 -0000 X-eGroups-Return: sentto-1101623-2886-990641296-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 23 May 2001 18:08:20 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:08:15 -0000 Received: (qmail 29661 invoked from network); 23 May 2001 18:08:10 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 May 2001 18:08:10 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:08:10 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI88B04388 for ; Wed, 23 May 2001 11:08:08 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI88r04381 for ; Wed, 23 May 2001 11:08:08 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NI7qF18537 for ; Wed, 23 May 2001 11:07:52 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24328; Wed, 23 May 2001 11:08:02 -0700 (PDT) Message-Id: <200105231808.LAA24328@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231806.LAA24320@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:08:02 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Website Services- Click Here!
Yahoo! Website Services- Click Here!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 21:07:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154ATE-0000ME-00 for ; Mon, 28 May 2001 02:01:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:01:16 +0200 (CEST) Received: (qmail 3704 invoked by uid 0); 23 May 2001 19:11:54 -0000 Received: from ck.egroups.com (208.50.144.69) by mx0.gmx.net (mx009-rz3) with SMTP; 23 May 2001 19:11:54 -0000 X-eGroups-Return: sentto-1101623-2920-990644911-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ck.egroups.com with NNFMP; 23 May 2001 19:08:41 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:08:30 -0000 Received: (qmail 93768 invoked from network); 23 May 2001 19:07:20 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 23 May 2001 19:07:20 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta2 with SMTP; 23 May 2001 19:07:19 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ7H917893 for ; Wed, 23 May 2001 12:07:17 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ7Gr17886 for ; Wed, 23 May 2001 12:07:16 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ70F27318 for ; Wed, 23 May 2001 12:07:00 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id MAA24977; Wed, 23 May 2001 12:07:10 -0700 (PDT) Message-Id: <200105231907.MAA24977@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231905.MAA24959@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 12:07:10 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 12:05:07 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 12:02:27 -0700 (PDT)
> > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 12:01:10 -0700 (PDT)
> > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:58:55 -0700 (PDT)
> > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:54:34 -0700 (PDT)
> > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:52:17 -0700 (PDT)
> > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:50:41 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:48:30 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:47:10 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:45:04 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:44:03 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:42:42 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:41:55 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:40:57 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:39:37 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:37:22 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:35:46 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:33:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:31:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:28:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:27:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:26:00 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 21:10:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AUX-0000ME-00 for ; Mon, 28 May 2001 02:02:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:02:37 +0200 (CEST) Received: (qmail 16698 invoked by uid 0); 23 May 2001 19:12:10 -0000 Received: from mk.egroups.com (208.50.144.76) by mx0.gmx.net (mx30) with SMTP; 23 May 2001 19:12:10 -0000 X-eGroups-Return: sentto-1101623-2923-990645128-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mk.egroups.com with NNFMP; 23 May 2001 19:12:09 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:12:08 -0000 Received: (qmail 62076 invoked from network); 23 May 2001 19:10:40 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 23 May 2001 19:10:40 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 19:10:40 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJAeM18568 for ; Wed, 23 May 2001 12:10:40 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJAdr18563 for ; Wed, 23 May 2001 12:10:39 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJANF27757 for ; Wed, 23 May 2001 12:10:23 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id MAA25025; Wed, 23 May 2001 12:10:33 -0700 (PDT) Message-Id: <200105231910.MAA25025@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231908.MAA24991@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 12:10:33 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] The mailing-list loo Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 12:08:56 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] The mailing-list loop ha
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 12:07:10 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] The mailing-list loop has be
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 12:06:13 -0700 (PDT)
> > > Subject: Re: [f-cpu] The mailing-list loop has been h
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 20:53:31 +0200
> > > > Subject: [f-cpu] The mailing-list loop has been handled at the Avant! Corporation
> > > >
> > > > Hello,
> > > >
> > > > I just mailed the avanticorp.com staff about this and their statement about
> > > > this whole affair is that the auto-reply is part of their company policy; the
> > > > email alias will last for a couple of month...
> > > >
> > > > I therefore strongly advise anyone that is willing to act upon this to not
> > > > contact this company: they are well aware of this problem now. Instead, please
> > > > contact the yahoo group administrator, <f-cpu-owner@makelist.com>
> > > >
> > > > Thank you for your attention.
> > > > --
> > > >       Paul
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 18:40:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AUZ-0000ME-00 for ; Mon, 28 May 2001 02:02:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:02:39 +0200 (CEST) Received: (qmail 8453 invoked by uid 0); 23 May 2001 19:12:25 -0000 Received: from fl.egroups.com (64.211.240.233) by mx0.gmx.net (mx10) with SMTP; 23 May 2001 19:12:25 -0000 X-eGroups-Return: sentto-1101623-2868-990636557-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by fl.egroups.com with NNFMP; 23 May 2001 16:49:18 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 16:49:17 -0000 Received: (qmail 47049 invoked from network); 23 May 2001 16:40:20 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 23 May 2001 16:40:20 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 16:40:20 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGeJb13175 for ; Wed, 23 May 2001 09:40:19 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGeJr13166 for ; Wed, 23 May 2001 09:40:19 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NGe3F04149 for ; Wed, 23 May 2001 09:40:03 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id JAA23628; Wed, 23 May 2001 09:40:13 -0700 (PDT) Message-Id: <200105231640.JAA23628@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231631.JAA23540@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 09:40:13 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 20:26:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AUh-0000ME-00 for ; Mon, 28 May 2001 02:02:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:02:47 +0200 (CEST) Received: (qmail 6567 invoked by uid 0); 23 May 2001 19:12:45 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx22) with SMTP; 23 May 2001 19:12:45 -0000 X-eGroups-Return: sentto-1101623-2895-990642382-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ho.egroups.com with NNFMP; 23 May 2001 18:26:25 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 18:26:21 -0000 Received: (qmail 82980 invoked from network); 23 May 2001 18:26:09 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 May 2001 18:26:09 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta3 with SMTP; 23 May 2001 18:26:08 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIQ7a08821 for ; Wed, 23 May 2001 11:26:07 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIQ6r08814 for ; Wed, 23 May 2001 11:26:06 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NIPoF21407 for ; Wed, 23 May 2001 11:25:50 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id LAA24531; Wed, 23 May 2001 11:26:00 -0700 (PDT) Message-Id: <200105231826.LAA24531@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231825.LAA24522@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 11:26:00 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 11:25:01 -0700 (PDT)
> Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 11:23:30 -0700 (PDT)
> > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 11:21:45 -0700 (PDT)
> > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > >
> > > -- Auto Reply ---------------------------------------------
> > >
> > > Message Delivery Failed .. Address is no longer valid
> > >
> > >    swchen@avanticorp.com
> > >
> > > -----------------------------------------------------------
> > >
> > > If you need help contacting someone else within Avant! please contact:
> > >
> > >   sales@avanticorp.com
> > >     - if you do not know your regional representative
> > >
> > >   license@avanticorp.com
> > >     - for license renewals
> > >
> > >   support@avanticorp.com
> > >     - for product support issues
> > >
> > >   compasssupport@avanticorp.com
> > >     - for Compass tools products support issues
> > >
> > >   jobs@avanticorp.com
> > >     - for Employment Opportunities
> > >
> > >   info@avanticorp.com
> > >     - for anything else
> > >
> > >   Avant! Corporation
> > >   46871 Bayside Pkwy
> > >   Fremont, CA 94550
> > >   (510) 413-8000
> > >   (510) 413-8080 (fax)
> > >
> > > -- Your Message -------------------------------------------
> > > >
> > > > To: f-cpu@yahoogroups.com
> > > > Cc:
> > > > Date: Wed, 23 May 2001 11:17:45 -0700 (PDT)
> > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > >
> > > > -- Auto Reply ---------------------------------------------
> > > >
> > > > Message Delivery Failed .. Address is no longer valid
> > > >
> > > >    swchen@avanticorp.com
> > > >
> > > > -----------------------------------------------------------
> > > >
> > > > If you need help contacting someone else within Avant! please contact:
> > > >
> > > >   sales@avanticorp.com
> > > >     - if you do not know your regional representative
> > > >
> > > >   license@avanticorp.com
> > > >     - for license renewals
> > > >
> > > >   support@avanticorp.com
> > > >     - for product support issues
> > > >
> > > >   compasssupport@avanticorp.com
> > > >     - for Compass tools products support issues
> > > >
> > > >   jobs@avanticorp.com
> > > >     - for Employment Opportunities
> > > >
> > > >   info@avanticorp.com
> > > >     - for anything else
> > > >
> > > >   Avant! Corporation
> > > >   46871 Bayside Pkwy
> > > >   Fremont, CA 94550
> > > >   (510) 413-8000
> > > >   (510) 413-8080 (fax)
> > > >
> > > > -- Your Message -------------------------------------------
> > > > >
> > > > > To: f-cpu@yahoogroups.com
> > > > > Cc:
> > > > > Date: Wed, 23 May 2001 11:14:49 -0700 (PDT)
> > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > >
> > > > > -- Auto Reply ---------------------------------------------
> > > > >
> > > > > Message Delivery Failed .. Address is no longer valid
> > > > >
> > > > >    swchen@avanticorp.com
> > > > >
> > > > > -----------------------------------------------------------
> > > > >
> > > > > If you need help contacting someone else within Avant! please contact:
> > > > >
> > > > >   sales@avanticorp.com
> > > > >     - if you do not know your regional representative
> > > > >
> > > > >   license@avanticorp.com
> > > > >     - for license renewals
> > > > >
> > > > >   support@avanticorp.com
> > > > >     - for product support issues
> > > > >
> > > > >   compasssupport@avanticorp.com
> > > > >     - for Compass tools products support issues
> > > > >
> > > > >   jobs@avanticorp.com
> > > > >     - for Employment Opportunities
> > > > >
> > > > >   info@avanticorp.com
> > > > >     - for anything else
> > > > >
> > > > >   Avant! Corporation
> > > > >   46871 Bayside Pkwy
> > > > >   Fremont, CA 94550
> > > > >   (510) 413-8000
> > > > >   (510) 413-8080 (fax)
> > > > >
> > > > > -- Your Message -------------------------------------------
> > > > > >
> > > > > > To: f-cpu@yahoogroups.com
> > > > > > Cc:
> > > > > > Date: Wed, 23 May 2001 11:12:11 -0700 (PDT)
> > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > >
> > > > > > -- Auto Reply ---------------------------------------------
> > > > > >
> > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > >
> > > > > >    swchen@avanticorp.com
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > >
> > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > >
> > > > > >   sales@avanticorp.com
> > > > > >     - if you do not know your regional representative
> > > > > >
> > > > > >   license@avanticorp.com
> > > > > >     - for license renewals
> > > > > >
> > > > > >   support@avanticorp.com
> > > > > >     - for product support issues
> > > > > >
> > > > > >   compasssupport@avanticorp.com
> > > > > >     - for Compass tools products support issues
> > > > > >
> > > > > >   jobs@avanticorp.com
> > > > > >     - for Employment Opportunities
> > > > > >
> > > > > >   info@avanticorp.com
> > > > > >     - for anything else
> > > > > >
> > > > > >   Avant! Corporation
> > > > > >   46871 Bayside Pkwy
> > > > > >   Fremont, CA 94550
> > > > > >   (510) 413-8000
> > > > > >   (510) 413-8080 (fax)
> > > > > >
> > > > > > -- Your Message -------------------------------------------
> > > > > > >
> > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > Cc:
> > > > > > > Date: Wed, 23 May 2001 11:10:45 -0700 (PDT)
> > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > >
> > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > >
> > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > >
> > > > > > >    swchen@avanticorp.com
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > >
> > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > >
> > > > > > >   sales@avanticorp.com
> > > > > > >     - if you do not know your regional representative
> > > > > > >
> > > > > > >   license@avanticorp.com
> > > > > > >     - for license renewals
> > > > > > >
> > > > > > >   support@avanticorp.com
> > > > > > >     - for product support issues
> > > > > > >
> > > > > > >   compasssupport@avanticorp.com
> > > > > > >     - for Compass tools products support issues
> > > > > > >
> > > > > > >   jobs@avanticorp.com
> > > > > > >     - for Employment Opportunities
> > > > > > >
> > > > > > >   info@avanticorp.com
> > > > > > >     - for anything else
> > > > > > >
> > > > > > >   Avant! Corporation
> > > > > > >   46871 Bayside Pkwy
> > > > > > >   Fremont, CA 94550
> > > > > > >   (510) 413-8000
> > > > > > >   (510) 413-8080 (fax)
> > > > > > >
> > > > > > > -- Your Message -------------------------------------------
> > > > > > > >
> > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > Cc:
> > > > > > > > Date: Wed, 23 May 2001 11:08:55 -0700 (PDT)
> > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > >
> > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > >
> > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > >
> > > > > > > >    swchen@avanticorp.com
> > > > > > > >
> > > > > > > > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > >
> > > > > > > >   sales@avanticorp.com
> > > > > > > >     - if you do not know your regional representative
> > > > > > > >
> > > > > > > >   license@avanticorp.com
> > > > > > > >     - for license renewals
> > > > > > > >
> > > > > > > >   support@avanticorp.com
> > > > > > > >     - for product support issues
> > > > > > > >
> > > > > > > >   compasssupport@avanticorp.com
> > > > > > > >     - for Compass tools products support issues
> > > > > > > >
> > > > > > > >   jobs@avanticorp.com
> > > > > > > >     - for Employment Opportunities
> > > > > > > >
> > > > > > > >   info@avanticorp.com
> > > > > > > >     - for anything else
> > > > > > > >
> > > > > > > >   Avant! Corporation
> > > > > > > >   46871 Bayside Pkwy
> > > > > > > >   Fremont, CA 94550
> > > > > > > >   (510) 413-8000
> > > > > > > >   (510) 413-8080 (fax)
> > > > > > > >
> > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > >
> > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > Cc:
> > > > > > > > > Date: Wed, 23 May 2001 11:08:02 -0700 (PDT)
> > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > >
> > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > >
> > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > >
> > > > > > > > >    swchen@avanticorp.com
> > > > > > > > >
> > > > > > > > > -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > >
> > > > > > > > >   sales@avanticorp.com
> > > > > > > > >     - if you do not know your regional representative
> > > > > > > > >
> > > > > > > > >   license@avanticorp.com
> > > > > > > > >     - for license renewals
> > > > > > > > >
> > > > > > > > >   support@avanticorp.com
> > > > > > > > >     - for product support issues
> > > > > > > > >
> > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > >     - for Compass tools products support issues
> > > > > > > > >
> > > > > > > > >   jobs@avanticorp.com
> > > > > > > > >     - for Employment Opportunities
> > > > > > > > >
> > > > > > > > >   info@avanticorp.com
> > > > > > > > >     - for anything else
> > > > > > > > >
> > > > > > > > >   Avant! Corporation
> > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > >   Fremont, CA 94550
> > > > > > > > >   (510) 413-8000
> > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > >
> > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > >
> > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > Cc:
> > > > > > > > > > Date: Wed, 23 May 2001 11:06:42 -0700 (PDT)
> > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > >
> > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > >
> > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > >
> > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > >
> > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > >
> > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > >
> > > > > > > > > >   license@avanticorp.com
> > > > > > > > > >     - for license renewals
> > > > > > > > > >
> > > > > > > > > >   support@avanticorp.com
> > > > > > > > > >     - for product support issues
> > > > > > > > > >
> > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > >
> > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > >
> > > > > > > > > >   info@avanticorp.com
> > > > > > > > > >     - for anything else
> > > > > > > > > >
> > > > > > > > > >   Avant! Corporation
> > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > >   (510) 413-8000
> > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > >
> > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > Cc:
> > > > > > > > > > > Date: Wed, 23 May 2001 11:04:47 -0700 (PDT)
> > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > >
> > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > >
> > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > >
> > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > >
> > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > >
> > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > >     - for license renewals
> > > > > > > > > > >
> > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > >     - for product support issues
> > > > > > > > > > >
> > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > >
> > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > >
> > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > >     - for anything else
> > > > > > > > > > >
> > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > >
> > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > Cc:
> > > > > > > > > > > > Date: Wed, 23 May 2001 11:03:31 -0700 (PDT)
> > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > >
> > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > >
> > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > >
> > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > >
> > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > >
> > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > >
> > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > >
> > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > >
> > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > >     - for anything else
> > > > > > > > > > > >
> > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > >
> > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > Date: Wed, 23 May 2001 11:01:11 -0700 (PDT)
> > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > >
> > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > >
> > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > >
> > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > >
> > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > >
> > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > >
> > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > >
> > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:59:19 -0700 (PDT)
> > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:55:43 -0700 (PDT)
> > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:52:39 -0700 (PDT)
> > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:47:33 -0700 (PDT)
> > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:42:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:37:08 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:32:12 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:26:15 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:19:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:12:38 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:05:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:57:17 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:49:51 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:40:13 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:31:57 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:22:09 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:13:23 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 09:04:30 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:56:27 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:46:40 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:33:53 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-c
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:24:29 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu]
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:15:28 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utop
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 08:06:42 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: Re: [f-cpu] utopia w
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:58:34 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: Re: [f-cpu] utopia webri
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:50:32 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:42:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:35:41 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:28:18 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 07:22:36 -0700 (PDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Auto Reply ---------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Message Delivery Failed .. Address is no longer valid
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >    swchen@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you need help contacting someone else within Avant! please contact:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   sales@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - if you do not know your regional representative
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   license@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for license renewals
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   support@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for product support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   compasssupport@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Compass tools products support issues
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   jobs@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for Employment Opportunities
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   info@avanticorp.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     - for anything else
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Avant! Corporation
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   46871 Bayside Pkwy
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   Fremont, CA 94550
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8000
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   (510) 413-8080 (fax)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Your Message -------------------------------------------
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: f-cpu@yahoogroups.com
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 23 May 2001 10:16:55 -0400 (EDT)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: [f-cpu] utopia webring
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies to any users of the utopia web-ring - open collector moved hosts
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yesterday, and there are some hiccups with getting everything working on
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the new machine. It should be back up by tomorrow.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Graham
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > >
> > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > >
> > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > > 
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
www.

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From swchen@avanticorp.com Wed May 23 21:08:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 154AVL-0000ME-00 for ; Mon, 28 May 2001 02:03:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 28 May 2001 02:03:27 +0200 (CEST) Received: (qmail 3610 invoked by uid 0); 23 May 2001 19:17:31 -0000 Received: from c3.egroups.com (208.50.99.225) by mx0.gmx.net (mx004-rz3) with SMTP; 23 May 2001 19:17:31 -0000 X-eGroups-Return: sentto-1101623-2921-990644997-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by c3.egroups.com with NNFMP; 23 May 2001 19:09:59 -0000 X-Sender: swchen@avanticorp.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_1_3); 23 May 2001 19:09:57 -0000 Received: (qmail 11544 invoked from network); 23 May 2001 19:09:02 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 23 May 2001 19:09:02 -0000 Received: from unknown (HELO mailhost.avanticorp.com) (63.167.1.13) by mta1 with SMTP; 23 May 2001 19:09:02 -0000 Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ92018340 for ; Wed, 23 May 2001 12:09:02 -0700 (PDT) Received: from arcs100.svd.avanticorp.com (nat-20.avanticorp.com [63.167.1.20]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ91r18336 for ; Wed, 23 May 2001 12:09:01 -0700 (PDT) Received: from majordomo.svd.avanticorp.com (majordomo.svd.avanticorp.com [172.16.2.158]) by arcs100.svd.avanticorp.com (8.10.1/8.10.1) with ESMTP id f4NJ8kF27547 for ; Wed, 23 May 2001 12:08:46 -0700 (PDT) Received: (from majordomo@localhost) by majordomo.svd.avanticorp.com (8.9.3/8.9.3) id MAA24991; Wed, 23 May 2001 12:08:56 -0700 (PDT) Message-Id: <200105231908.MAA24991@majordomo.svd.avanticorp.com> X-Authentication-Warning: majordomo.svd.avanticorp.com: majordomo set sender to swchen@majordomo.svd.avanticorp.com using -f To: f-cpu@yahoogroups.com In-Reply-To: <200105231907.MAA24981@majordomo.svd.avanticorp.com>, from swchen@avanticorp.com X-Loop: postmaster@avanticorp.com X-eGroups-From: MAILER-DAEMON@avanticorp.com From: swchen@avanticorp.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 23 May 2001 12:08:56 -0700 (PDT) Reply-To: f-cpu@yahoogroups.com Subject: Re: Re: Re: [f-cpu] The mailing-list loop ha Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N -- Auto Reply ---------------------------------------------

Message Delivery Failed .. Address is no longer valid

   swchen@avanticorp.com

-----------------------------------------------------------

If you need help contacting someone else within Avant! please contact:

  sales@avanticorp.com
    - if you do not know your regional representative

  license@avanticorp.com
    - for license renewals

  support@avanticorp.com
    - for product support issues

  compasssupport@avanticorp.com
    - for Compass tools products support issues

  jobs@avanticorp.com
    - for Employment Opportunities

  info@avanticorp.com
    - for anything else

  Avant! Corporation
  46871 Bayside Pkwy
  Fremont, CA 94550
  (510) 413-8000
  (510) 413-8080 (fax)

-- Your Message -------------------------------------------
>
> To: f-cpu@yahoogroups.com
> Cc:
> Date: Wed, 23 May 2001 12:07:10 -0700 (PDT)
> Subject: Re: Re: [f-cpu] The mailing-list loop has be
>
> -- Auto Reply ---------------------------------------------
>
> Message Delivery Failed .. Address is no longer valid
>
>    swchen@avanticorp.com
>
> -----------------------------------------------------------
>
> If you need help contacting someone else within Avant! please contact:
>
>   sales@avanticorp.com
>     - if you do not know your regional representative
>
>   license@avanticorp.com
>     - for license renewals
>
>   support@avanticorp.com
>     - for product support issues
>
>   compasssupport@avanticorp.com
>     - for Compass tools products support issues
>
>   jobs@avanticorp.com
>     - for Employment Opportunities
>
>   info@avanticorp.com
>     - for anything else
>
>   Avant! Corporation
>   46871 Bayside Pkwy
>   Fremont, CA 94550
>   (510) 413-8000
>   (510) 413-8080 (fax)
>
> -- Your Message -------------------------------------------
> >
> > To: f-cpu@yahoogroups.com
> > Cc:
> > Date: Wed, 23 May 2001 12:06:13 -0700 (PDT)
> > Subject: Re: [f-cpu] The mailing-list loop has been h
> >
> > -- Auto Reply ---------------------------------------------
> >
> > Message Delivery Failed .. Address is no longer valid
> >
> >    swchen@avanticorp.com
> >
> > -----------------------------------------------------------
> >
> > If you need help contacting someone else within Avant! please contact:
> >
> >   sales@avanticorp.com
> >     - if you do not know your regional representative
> >
> >   license@avanticorp.com
> >     - for license renewals
> >
> >   support@avanticorp.com
> >     - for product support issues
> >
> >   compasssupport@avanticorp.com
> >     - for Compass tools products support issues
> >
> >   jobs@avanticorp.com
> >     - for Employment Opportunities
> >
> >   info@avanticorp.com
> >     - for anything else
> >
> >   Avant! Corporation
> >   46871 Bayside Pkwy
> >   Fremont, CA 94550
> >   (510) 413-8000
> >   (510) 413-8080 (fax)
> >
> > -- Your Message -------------------------------------------
> > >
> > > To: f-cpu@yahoogroups.com
> > > Cc:
> > > Date: Wed, 23 May 2001 20:53:31 +0200
> > > Subject: [f-cpu] The mailing-list loop has been handled at the Avant! Corporation
> > >
> > > Hello,
> > >
> > > I just mailed the avanticorp.com staff about this and their statement about
> > > this whole affair is that the auto-reply is part of their company policy; the
> > > email alias will last for a couple of month...
> > >
> > > I therefore strongly advise anyone that is willing to act upon this to not
> > > contact this company: they are well aware of this problem now. Instead, please
> > > contact the yahoo group administrator, <f-cpu-owner@makelist.com>
> > >
> > > Thank you for your attention.
> > > --
> > >       Paul
> > >
> > > 
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > 
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> 
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Yahoo! Groups Sponsor
Yahoo! Domains Yahoo! Domains

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Wed Jul 18 23:25:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15N4rW-0005Ht-00 for ; Thu, 19 Jul 2001 05:52:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 19 Jul 2001 05:52:30 +0200 (CEST) Received: (qmail 4178 invoked by uid 0); 18 Jul 2001 22:44:02 -0000 Received: from fj.egroups.com (64.211.240.231) by mx0.gmx.net (mx22) with SMTP; 18 Jul 2001 22:44:02 -0000 X-eGroups-Return: sentto-1101623-3077-995496218-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by fj.egroups.com with NNFMP; 18 Jul 2001 22:43:39 -0000 X-Sender: whygee@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_2_0); 18 Jul 2001 22:43:37 -0000 Received: (qmail 76923 invoked from network); 18 Jul 2001 21:25:12 -0000 Received: from unknown (10.1.10.27) by l8.egroups.com with QMQP; 18 Jul 2001 21:25:12 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 18 Jul 2001 21:25:11 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15Myof-0006pS-00 for f-cpu@yahoogroups.com; Wed, 18 Jul 2001 23:25:09 +0200 Received: from aqua.bocal.cs.univ-paris8.fr ([192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15Myof-0007zr-00 for f-cpu@yahoogroups.com; Wed, 18 Jul 2001 23:25:09 +0200 Received: (from whygee@localhost) by aqua.bocal.cs.univ-paris8.fr (8.8.8+Sun/8.8.8) id XAA12037 for f-cpu@yahoogroups.com; Wed, 18 Jul 2001 23:25:01 +0200 (MET DST) Message-Id: <200107182125.XAA12037@aqua.bocal.cs.univ-paris8.fr> From: Whygee MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Jul 2001 23:25:01 +0200 (MET DST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The list has moved ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Status: R X-Status: N Hello,

This message is sent automatically every week to remember you that
the main f-cpu mailing has moved to
http://www.seul.org/archives/f-cpu/f-cpu/

To join the f-cpu mailing list, send an e-mail message to
majordomo@seul.org with no subject and a body of "subscribe f-cpu".

Due to the lack of manager (He disapeared 2 years ago !) and the
impossibility to administrate this YahooGroups list, we are forced
to move to a more friendly server.

Read you there,

whygee
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From easymoneyforu@home.com Wed Jul 18 22:39:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15N4ra-0005Ht-00 for ; Thu, 19 Jul 2001 05:52:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 19 Jul 2001 05:52:34 +0200 (CEST) Received: (qmail 21485 invoked by uid 0); 19 Jul 2001 02:17:46 -0000 Received: from n3.groups.yahoo.com (HELO hj.egroups.com) (216.115.96.53) by mx0.gmx.net (mx25) with SMTP; 19 Jul 2001 02:17:46 -0000 X-eGroups-Return: sentto-1101623-3078-995506941-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by hj.egroups.com with NNFMP; 19 Jul 2001 01:42:23 -0000 X-Sender: easymoneyforu@home.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 19 Jul 2001 01:42:20 -0000 Received: (qmail 93024 invoked from network); 19 Jul 2001 01:42:11 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 19 Jul 2001 01:42:11 -0000 Received: from unknown (HELO c787744-a) (24.254.130.237) by mta1 with SMTP; 19 Jul 2001 01:42:02 -0000 To: From: MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 18 Jul 2001 20:39:05 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Easy Money Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20010719021747.21491gmx1@mx25.gmx.net> Status: R X-Status: N
Hello Friend,

I want to show you what I do for fun, which will make me an ADDITIONAL
$250,000
THIS YEAR ALONE....and it takes only a fraction of the time that you and
I spend
at our regular jobs. Basically, I send out as many of these emails as I can,
then people send me cash in the mail for information that I just email back
to
them. Every day, I make a three minute drive to my P.O. Box knowing that
there
are at least a few hundred dollars waiting for me. And the best part, IT IS
COMPLETELY
LEGAL. Just read the next few pages and see what you think. If you like
what
you read, great....If you don't, read it again because you must have
missed something!

------------------------------------------------------------

DEAR FRIENDS AND FUTURE MILLIONAIRES: AS SEEN ON
NATIONAL TV: Making
over half
million dollars every 4 to 5 months from your home for an investment of
only
$25 US Dollars expense one time.

THANKS TO THE COMPUTER AGE AND THE INTERNET! BE A
MILLIONAIRE LIKE
OTHERS WITHIN
A YEAR!!! Before you say Bull, please read the following. This is the letter
you have been hearing about on the news lately. Due to the popularity of
this
letter on the Internet, a national weekly news program recently devoted an
entire
show to the investigation of this program described below, to see if it really
can make people money. The show also investigated whether or not the
program
was legal.

Their findings proved once and for all that there are absolutely NO laws
prohibiting
the participation in the program and if people can follow the simple
instructions,
they are bound to make some mega bucks with only $25 out of pocket
cost. DUE
TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS
ATTAINED, IT
IS CURRENTLY WORKING BETTER THAN EVER. This is what one
had to say: "Thanks
to
this profitable opportunity. I was approached many times before but each
time
I passed on it. I am so glad I finally joined just to see what one could
expect
in return for the minimal effort and money required. To my astonishment, I
received
a total $610,470.00 in 21 weeks, with money still coming in." Pam
Hedland, Fort
Lee, New Jersey. PRINT THIS NOW FOR YOUR FUTURE
REFERENCE (Or have it
emailed
to you-See Submit Button below)

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$
If you would like to make at least $500,000 every 4 to 5 months easily and
comfortably,
please read the following, THEN READ IT AGAIN AND AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR
FINANCIAL DREAMS
WILL COME TRUE,
GUARANTEED!

INSTRUCTIONS:

===========Order all 5 reports shown on the list below=====

For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE
ORDERING
AND YOUR E-MAIL ADDRESS to the person whose name appears ON
THAT LIST next to
the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR
ENVELOPE TOP
LEFT CORNER
in case of any mail problems. When you place your order, make sure you
order
each of the 5 reports. You will need all 5 reports so that you can save
them
on your computer and resell them. YOUR TOTAL COST... $ 5 X 5 = $
25.00. Within
a few days you will receive, via e-mail, each of the 5 reports from these 5
different
individuals. Save them on your computer so they will be accessible for you
to
send to the 1,000's of people who will order them from you. Also make a
floppy
of these reports and keep it on your desk in case something happens to
your computer.

IMPORTANT: DO NOT alter the names of the people who are listed next
to each report,
or their sequence on the list, in any way other than what is instructed
below
in each step 1 through 6 or you will lose out on majority of your profits.
Once
you understand the way this works, you will also see how it does not work
if
you change it. Remember, this method has been tested, and if you alter it,
it
will NOT work!! People have tried to put their friends/relatives names on
all
five thinking they could get all the money. But it does not work this way.
Believe
us, we all have tried to be greedy and then nothing happened. So Do Not
try to
change anything other than what is instructed, because if you do, it will
not
work for you.

Remember, honesty reaps the reward!!!

1. After you have ordered all 5 reports, take this advertisement and
REMOVE the
name & address of the person in REPORT # 5. This person has made it
through the
cycle and is no doubt counting their fortune.
2. Move the name & address in REPORT # 4 down to report # 5.
3. Move the name & address in REPORT # 3 down to report # 4.
4. Move the name & address in REPORT # 2 down to report # 3.
5. Move the name & address in REPORT # 1 down to report # 2.
6. Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!

***Take this entire letter, with the modified list of names, and save it on
your
computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk
as well just in
case if you lose any data. To assist you with marketing your business on
the
internet, the 5 reports you purchase will provide you with invaluable
marketing
information which includes how to send bulk e-mails legally, where to find
thousands
of free classified ads and much more. There are 2 Primary methods to get
this
venture going:

METHOD #1: BY SENDING BULK E-MAIL LEGALLY

Let's say that you decide to start small, just to see how it goes, and we will
assume you and those involved send out only 5,000 e-mails each. Let's
also assume
that the mailing receive only a 0.2% response (the response could be
much better
but lets just say it is only 0.2%. Also, many people will send out hundreds
of
thousands of e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails. With a
0.2% response,
that is only 10 orders for report # 1. Those 10 people responded by
sending out
5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails, only
0.2%
responded with orders. That's 100 people responding to and ordering
Report #
2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-
mails.
The 0.2% response to that is 1000 orders for Report # 3. Those 1000
people send
out 5,000 e-mails each for a total of 5 million e-mails.
The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000
people
send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails.
The
0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000
ORDERS
TIMES $ 5 EACH = $ 500,000.00 (half million).

Your total income in this example is: 1...$ 50 + 2...$ 500 + 3..$ 5,000 4...
$ 50,000 + 5... $ 500,000... GRAND TOTAL = $ 555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT
THE WORST
POSSIBLE RESPONSES
AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE
A LOT OF
MONEY! REMEMBER
FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF
5,000 YOU
MAILED TO.
Dare to think for a moment what would happen if everyone or half or even
one
4th of those people mailed 100,000 e-mails each or more? There are over
150 million
people on the Internet worldwide and counting. Believe me, many people
will do
just that, and more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET

Advertising on the net is very, very inexpensive and there are hundreds of
FREE
places to advertise. Placing a lot of free ads on the internet will easily get
a larger response.

We strongly suggest you start with Method # 1 and add METHOD # 2 as
you go along.

For every $ 5 you receive, all you must do is e-mail them the Report they
ordered.
That's it. Always provide same day service on all orders. This will
guarantee
that the e-mail they send out, with your name and address on it, will be
prompt
because they can not advertise until they receive the report.

AVAILABLE REPORTS
=========================================

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes:
Always send $ 5 cash
(US
CURRENCY) for each report. Checks NOT accepted. Make sure the
cash is concealed
by wrapping it in at least 2 sheets of paper. On one of those sheets of
paper,
write the NUMBER & NAME of the Report you are ordering., YOUR E-
MAIL ADDRESS
and your name and postal address.

******************

PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT # 1: The Insider's Guide To Advertising For Free On The Net

Order Report # 1 from:

Scott Lyons
P.O. Box 2368
Frisco, Tx 75034

Report #2: The Insider's Guide To Sending Bulk E-Mail On The Net

Order Report #2 from:

David Oualline
14307 Brook Hollow Blvd
San Antonio, TX 78232


Report # 3: The Secret To Multilevel Marketing On The Net

Order Report # 3 from:

Tony Diodato
4730 Levick Street
Philadelphia PA, 19135


Report # 4: How To Become A Millionaire Utilizing MLM & The Net

Order Report # 4 from:

Robert Youngblood
P.O. Box 425384
San Francisco, CA 94142


Report # 5: How To Send 1 Million E-Mails For Free

Order Report # 5 from:

Geoffrey Gimbel
160 East 38th Street, Apt 22A
New York, NY 10016


$$$$$YOUR SUCCESS GUIDE$$$$$$$$$$$$$

Follow these guidelines to guarantee your success: If you do not receive
at least
10 orders for Report # 1 within 2 weeks, continue sending e-mails until
you do.
After you have received 10 orders, 2 to 3 weeks after that you should
receive
100 orders or more for Report # 2. If you did not, continue advertising or
sending
e-mails until you do.

Once you have received 100 or more orders for Report # 2, YOU CAN
RELAX, because
the system is already working for you, and the cash will continue to roll in!

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved
down on the list,
you are placed in front of a different report. You can KEEP TRACK of your
PROGRESS
by watching which report people are ordering from you. IF YOU WANT
TO GENERATE
MORE INCOME, SEND ANOTHER BATCH OF E-MAILS AND START
THE WHOLE
PROCESS AGAIN.
There is no limit to the income you can generate from this business!!!

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM: You have just
received
information that can give you financial freedom for the rest of your life, with
NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more
money in the next
few weeks and months than you have ever imagined. Follow the program
EXACTLY
AS INSTRUCTED. Do not change it in any way. It works exceedingly well
as it is
now. Remember to e-mail a copy of this exciting report after you have put
your
name and address in Report # 1 and moved others to # 2...# 5 as
instructed above.
One of the people you send this to may send out 100,000 or more e-mails
and your
name will be on every one of them. Remember though, the more you send
out the
more potential customers you will reach. So my friend, I have given you
the ideas,
information, materials and opportunity to become financially independent.

IT IS UP TO YOU NOW!
=====================================================

If you believe this message has reached you in error, or if you wish to
unsubscribe
to this mailing list, please reply to the above email address with the word
"unsubscribe"
in the subject line.
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From jaz@itvc.com Thu Jul 19 16:43:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15NFpp-0002xG-00 for ; Thu, 19 Jul 2001 17:35:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 19 Jul 2001 17:35:29 +0200 (CEST) Received: (qmail 28487 invoked by uid 0); 19 Jul 2001 14:52:09 -0000 Received: from ho.egroups.com (64.211.240.236) by mx0.gmx.net (mx01) with SMTP; 19 Jul 2001 14:52:09 -0000 X-eGroups-Return: sentto-1101623-3079-995553828-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by ho.egroups.com with NNFMP; 19 Jul 2001 14:47:00 -0000 X-Sender: jaz@itvc.com X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_2_0); 19 Jul 2001 14:43:47 -0000 Received: (qmail 76848 invoked from network); 19 Jul 2001 14:42:52 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 19 Jul 2001 14:42:52 -0000 Received: from unknown (HELO red.itvcorp.com) (216.36.67.143) by mta3 with SMTP; 19 Jul 2001 14:42:50 -0000 Received: from oz (sdsl-216-36-67-143.dsl.sjc.megapath.net [216.36.67.143]) by red.itvcorp.com (Post.Office MTA v3.5.3 release 223 ID# 0-71578U100L100S0V35) with SMTP id com for ; Thu, 19 Jul 2001 07:53:53 -0700 To: Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <995537230.123.57733.l10@yahoogroups.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-eGroups-From: "Joe Zott" From: "Joe Zott" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Jul 2001 07:43:47 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] unsubscribe Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

-----Original Message-----
From: f-cpu@yahoogroups.com [mailto:f-cpu@yahoogroups.com]
Sent: Thursday, July 19, 2001 3:07 AM
To: f-cpu@yahoogroups.com
Subject: [f-cpu] Digest Number 397


There are 2 messages in this issue.

Topics in this digest:

      1. The list has moved ...
           From: Whygee <whygee@f-cpu.org>
      2. Easy Money
           From: <easymoneyforu@home.com>


________________________________________________________________________
________________________________________________________________________

Message: 1
   Date: Wed, 18 Jul 2001 23:25:01 +0200 (MET DST)
   From: Whygee <whygee@f-cpu.org>
Subject: The list has moved ...

Hello,

This message is sent automatically every week to remember you that
the main f-cpu mailing has moved to
http://www.seul.org/archives/f-cpu/f-cpu/

To join the f-cpu mailing list, send an e-mail message to
majordomo@seul.org with no subject and a body of "subscribe f-cpu".

Due to the lack of manager (He disapeared 2 years ago !) and the
impossibility to administrate this YahooGroups list, we are forced
to move to a more friendly server.

Read you there,

whygee


________________________________________________________________________
________________________________________________________________________

Message: 2
   Date: Wed, 18 Jul 2001 20:39:05
   From: <easymoneyforu@home.com>
Subject: Easy Money


Hello Friend,

I want to show you what I do for fun, which will make me an ADDITIONAL
$250,000
THIS YEAR ALONE....and it takes only a fraction of the time that you and
I spend
at our regular jobs. Basically, I send out as many of these emails as I can,
then people send me cash in the mail for information that I just email back
to
them. Every day, I make a three minute drive to my P.O. Box knowing that
there
are at least a few hundred dollars waiting for me. And the best part, IT IS
COMPLETELY
LEGAL. Just read the next few pages and see what you think. If you like
what
you read, great....If you don't, read it again because you must have
missed something!

------------------------------------------------------------

DEAR FRIENDS AND FUTURE MILLIONAIRES: AS SEEN ON
NATIONAL TV: Making
over half
million dollars every 4 to 5 months from your home for an investment of
only
$25 US Dollars expense one time.

THANKS TO THE COMPUTER AGE AND THE INTERNET! BE A
MILLIONAIRE LIKE
OTHERS WITHIN
A YEAR!!! Before you say Bull, please read the following. This is the letter
you have been hearing about on the news lately. Due to the popularity of
this
letter on the Internet, a national weekly news program recently devoted an
entire
show to the investigation of this program described below, to see if it
really
can make people money. The show also investigated whether or not the
program
was legal.

Their findings proved once and for all that there are absolutely NO laws
prohibiting
the participation in the program and if people can follow the simple
instructions,
they are bound to make some mega bucks with only $25 out of pocket
cost. DUE
TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS
PROGRAM HAS
ATTAINED, IT
IS CURRENTLY WORKING BETTER THAN EVER. This is what one
had to say: "Thanks
to
this profitable opportunity. I was approached many times before but each
time
I passed on it. I am so glad I finally joined just to see what one could
expect
in return for the minimal effort and money required. To my astonishment, I
received
a total $610,470.00 in 21 weeks, with money still coming in." Pam
Hedland, Fort
Lee, New Jersey. PRINT THIS NOW FOR YOUR FUTURE
REFERENCE (Or have it
emailed
to you-See Submit Button below)

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$
If you would like to make at least $500,000 every 4 to 5 months easily and
comfortably,
please read the following, THEN READ IT AGAIN AND AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR
FINANCIAL DREAMS
WILL COME TRUE,
GUARANTEED!

INSTRUCTIONS:

===========Order all 5 reports shown on the list below=====

For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE
ORDERING
AND YOUR E-MAIL ADDRESS to the person whose name appears ON
THAT LIST next to
the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR
ENVELOPE TOP
LEFT CORNER
in case of any mail problems. When you place your order, make sure you
order
each of the 5 reports. You will need all 5 reports so that you can save
them
on your computer and resell them. YOUR TOTAL COST... $ 5 X 5 = $
25.00. Within
a few days you will receive, via e-mail, each of the 5 reports from these 5
different
individuals. Save them on your computer so they will be accessible for you
to
send to the 1,000's of people who will order them from you. Also make a
floppy
of these reports and keep it on your desk in case something happens to
your computer.

IMPORTANT: DO NOT alter the names of the people who are listed next
to each report,
or their sequence on the list, in any way other than what is instructed
below
in each step 1 through 6 or you will lose out on majority of your profits.
Once
you understand the way this works, you will also see how it does not work
if
you change it. Remember, this method has been tested, and if you alter it,
it
will NOT work!! People have tried to put their friends/relatives names on
all
five thinking they could get all the money. But it does not work this way.
Believe
us, we all have tried to be greedy and then nothing happened. So Do Not
try to
change anything other than what is instructed, because if you do, it will
not
work for you.

Remember, honesty reaps the reward!!!

1. After you have ordered all 5 reports, take this advertisement and
REMOVE the
name & address of the person in REPORT # 5. This person has made it
through the
cycle and is no doubt counting their fortune.
2. Move the name & address in REPORT # 4 down to report # 5.
3. Move the name & address in REPORT # 3 down to report # 4.
4. Move the name & address in REPORT # 2 down to report # 3.
5. Move the name & address in REPORT # 1 down to report # 2.
6. Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!

***Take this entire letter, with the modified list of names, and save it on
your
computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk
as well just in
case if you lose any data. To assist you with marketing your business on
the
internet, the 5 reports you purchase will provide you with invaluable
marketing
information which includes how to send bulk e-mails legally, where to find
thousands
of free classified ads and much more. There are 2 Primary methods to get
this
venture going:

METHOD #1: BY SENDING BULK E-MAIL LEGALLY

Let's say that you decide to start small, just to see how it goes, and we
will
assume you and those involved send out only 5,000 e-mails each. Let's
also assume
that the mailing receive only a 0.2% response (the response could be
much better
but lets just say it is only 0.2%. Also, many people will send out hundreds
of
thousands of e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails. With a
0.2% response,
that is only 10 orders for report # 1. Those 10 people responded by
sending out
5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails, only
0.2%
responded with orders. That's 100 people responding to and ordering
Report #
2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-
mails.
The 0.2% response to that is 1000 orders for Report # 3. Those 1000
people send
out 5,000 e-mails each for a total of 5 million e-mails.
The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000
people
send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails.
The
0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000
ORDERS
TIMES $ 5 EACH = $ 500,000.00 (half million).

Your total income in this example is: 1...$ 50 + 2...$ 500 + 3..$ 5,000 4...
$ 50,000 + 5... $ 500,000... GRAND TOTAL = $ 555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT
THE WORST
POSSIBLE RESPONSES
AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE
A LOT OF
MONEY! REMEMBER
FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF
5,000 YOU
MAILED TO.
Dare to think for a moment what would happen if everyone or half or even
one
4th of those people mailed 100,000 e-mails each or more? There are over
150 million
people on the Internet worldwide and counting. Believe me, many people
will do
just that, and more!

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET

Advertising on the net is very, very inexpensive and there are hundreds of
FREE
places to advertise. Placing a lot of free ads on the internet will easily
get
a larger response.

We strongly suggest you start with Method # 1 and add METHOD # 2 as
you go along.

For every $ 5 you receive, all you must do is e-mail them the Report they
ordered.
That's it. Always provide same day service on all orders. This will
guarantee
that the e-mail they send out, with your name and address on it, will be
prompt
because they can not advertise until they receive the report.

AVAILABLE REPORTS
=========================================

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes:
Always send $ 5 cash
(US
CURRENCY) for each report. Checks NOT accepted. Make sure the
cash is concealed
by wrapping it in at least 2 sheets of paper. On one of those sheets of
paper,
write the NUMBER & NAME of the Report you are ordering., YOUR E-
MAIL ADDRESS
and your name and postal address.

******************

PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT # 1: The Insider's Guide To Advertising For Free On The Net

Order Report # 1 from:

Scott Lyons
P.O. Box 2368
Frisco, Tx 75034

Report #2: The Insider's Guide To Sending Bulk E-Mail On The Net

Order Report #2 from:

David Oualline
14307 Brook Hollow Blvd
San Antonio, TX 78232


Report # 3: The Secret To Multilevel Marketing On The Net

Order Report # 3 from:

Tony Diodato
4730 Levick Street
Philadelphia PA, 19135


Report # 4: How To Become A Millionaire Utilizing MLM & The Net

Order Report # 4 from:

Robert Youngblood
P.O. Box 425384
San Francisco, CA 94142


Report # 5: How To Send 1 Million E-Mails For Free

Order Report # 5 from:

Geoffrey Gimbel
160 East 38th Street, Apt 22A
New York, NY 10016


$$$$$YOUR SUCCESS GUIDE$$$$$$$$$$$$$

Follow these guidelines to guarantee your success: If you do not receive
at least
10 orders for Report # 1 within 2 weeks, continue sending e-mails until
you do.
After you have received 10 orders, 2 to 3 weeks after that you should
receive
100 orders or more for Report # 2. If you did not, continue advertising or
sending
e-mails until you do.

Once you have received 100 or more orders for Report # 2, YOU CAN
RELAX, because
the system is already working for you, and the cash will continue to roll
in!

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved
down on the list,
you are placed in front of a different report. You can KEEP TRACK of your
PROGRESS
by watching which report people are ordering from you. IF YOU WANT
TO GENERATE
MORE INCOME, SEND ANOTHER BATCH OF E-MAILS AND START
THE WHOLE
PROCESS AGAIN.
There is no limit to the income you can generate from this business!!!

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM: You have just
received
information that can give you financial freedom for the rest of your life,
with
NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more
money in the next
few weeks and months than you have ever imagined. Follow the program
EXACTLY
AS INSTRUCTED. Do not change it in any way. It works exceedingly well
as it is
now. Remember to e-mail a copy of this exciting report after you have put
your
name and address in Report # 1 and moved others to # 2...# 5 as
instructed above.
One of the people you send this to may send out 100,000 or more e-mails
and your
name will be on every one of them. Remember though, the more you send
out the
more potential customers you will reach. So my friend, I have given you
the ideas,
information, materials and opportunity to become financially independent.

IT IS UP TO YOU NOW!
=====================================================

If you believe this message has reached you in error, or if you wish to
unsubscribe
to this mailing list, please reply to the above email address with the word
"unsubscribe"
in the subject line.



________________________________________________________________________
________________________________________________________________________



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From handy@nyc.com Fri Jul 20 02:22:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15O17L-0002CC-00 for ; Sat, 21 Jul 2001 20:04:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Sat, 21 Jul 2001 20:04:43 +0200 (CEST) Received: (qmail 31658 invoked by uid 0); 20 Jul 2001 18:01:42 -0000 Received: from n33.groups.yahoo.com (216.115.96.83) by mx0.gmx.net (mx23) with SMTP; 20 Jul 2001 18:01:42 -0000 X-eGroups-Return: sentto-1101623-3080-995652100-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ei.egroups.com with NNFMP; 20 Jul 2001 18:01:40 -0000 X-Sender: handy@nyc.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 20 Jul 2001 18:01:39 -0000 Received: (qmail 88692 invoked from network); 20 Jul 2001 18:00:55 -0000 Received: from unknown (10.1.10.142) by l7.egroups.com with QMQP; 20 Jul 2001 18:00:55 -0000 Received: from unknown (HELO congreso.gob.mx) (200.4.123.2) by mta3 with SMTP; 20 Jul 2001 18:00:54 -0000 Received: from excite.ccom ([195.2.71.2]) by congreso.gob.mx (Post.Office MTA v3.5.3 release 223 ID# 0-67493U100L2S100V35) with SMTP id mx; Thu, 19 Jul 2001 18:10:26 -0600 To: borneo7521@altavista.com Message-Id: <1gcw5u.053jslsfyg@excite.ccom> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) X-eGroups-From: jessica6582@altavista.com From: handy@nyc.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Thu, 19 Jul 2001 16:22:19 -0800 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Check Your Employees or Boss's Background ! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N

Find out how to get your hands on essentially any information:

Locate hidden e-mails, phone numbers, or addresses.
Find debtors and locate hidden assets.
Check criminal, drug and driving records.
 Look up someone's employment history.
and even get your FBI file.

Click Here for More Information





Useful for your Special and Work investigation needs:

Check adoption records locate missing children or relatives.
Dig up information on your friends, neighbors, or boss!
Locate transcripts and court orders from all 50 states.
Cloak your email so your true address can't be discovered.
Use the Most Powerful DetectiveTool on the Net !


Click Here for More Information





click here to be removed from our mailing list.
Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From qjffjd6@lycos.co.kr Sun Jul 22 19:01:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15OTwy-000507-00 for ; Mon, 23 Jul 2001 02:51:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 23 Jul 2001 02:51:56 +0200 (CEST) Received: (qmail 9929 invoked by uid 0); 22 Jul 2001 17:37:30 -0000 Received: from n28.groups.yahoo.com (216.115.96.78) by mx0.gmx.net (mx22) with SMTP; 22 Jul 2001 17:37:30 -0000 X-eGroups-Return: sentto-1101623-3081-995823448-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by f19.egroups.com with NNFMP; 22 Jul 2001 17:37:29 -0000 X-Sender: qjffjd6@lycos.co.kr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 22 Jul 2001 17:37:27 -0000 Received: (qmail 53023 invoked from network); 22 Jul 2001 17:37:14 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 22 Jul 2001 17:37:14 -0000 Received: from unknown (HELO kr-outmail2.lycos.co.kr) (211.51.63.171) by mta2 with SMTP; 22 Jul 2001 17:37:02 -0000 To: famillypark@hanmail.net, Family@esper.com, family@familykorea.com, family@mail.ulsan-c.ac.kr, family0228@hanmail.net, family19991@korea.com, familycare@hanmail.net, familyguardian@familyguardian.co.kr, familyhong@hanmail.net, familyji@trilli.com, famiHlylove@hananet.net, familymo@hosanna.net, familyp@soback.kornet.nm.kr, familypcbang@yahoo.co.kr, familyq@familyq.or.kr, familysong@hanmail.net, familytime@indbazaar.com, famj05@edunet4u.net, famme@chollian.net, famos@inter-line.co.kr, famousdoc@hanmail.neHt, famtours@ldschurch.org, fan@booche.co.kr, fan@metin.co.kr, fan007@hanmail.net, fan79@unitel.co.kr, fanatic77@hanmail.net, fanatiker@com.ne.kr, fancherw@smtpgate.aviano.af.mil, fancier1@chollian.net, fancier830623@hanmail.net, fanclub@stoo.com, fancy@daHisy.yonsei.ac.kr, fancykr_2000@yahoo.co.kr, fanfilm@hotmail.com, f-angelone@onu.edu, fangj@binghamton.edu, fangod@sidus.net, fangod-hoi0326@hanmail.net, fangod-hy-hoi@hanmail.net, fangodsaranghae@hanmail.net, fan-kangta@hanmail.net, fanletter@lycos.co.kr, fanmail@christinamail.com, fanmail@madonnafanclub.com, fanmail@michaelwsmith.com, fann@hanmir.com, fanny@freeinternet.co.kr, fanny@hitel.co.kr, fanny@sdvision.kaist.ac.kr, fannybrian51017@hanmail.net, fannyzzanglove@hanmail.net, fanofses@hanmail.net, fanHs@ernestocortazar.com, fans@fanskorea.co.ke, fans@fanskorea.co.kr, fansungmo@yahoo.co.kr, Fant@Tornei.com, fanta@cgate.co.kr, fanta@oullim.co.kr, fanta@tbc.co.kr, fanta108@edunet4u.net, fanta512@orgio.net, fanta55@hanmail.net, fantaage@chollian.net, fantaHgi@chollian.net, fantagia21@hanmail.net, fantaorange@korea.com, fantaso@hanmail.net, fantast@joins.com, fantasy@bomymirror.com, fantasy@dic.co.kr, fantasy@hanmail.net, fantasy@paxnet.co.kr, fantasy@sbsmail.net, fantasy0@netsgo.com, fantasy2@hanmir.net, faHntasy55@lycos.co.kr, fantasylove10@hanmail.net, fantasym@dreamwiz.com, fantavii@hitel.net, fantaya@dreamwiz.com, fante1007@daum.net, fantic@edunet4u.net, fantom@unicode.net.au, fantsym@dreamwiz.com, fany@36.com, fany-2@hanmail.net, fanyjoa@kebi.com, fanziHc@lga.co.kr, fao@buaa.edu.cn, fao@mail.asnc.edu.cn, faoa@scut.edu.cn, faob@public.hr.hl.cn, faocju@public.cq.sc.cn, FAO-HQ@fao.org, faokdh@daegubank.co.kr, faq@choco.com, faq@koreamultinet.com, faq@myq.co.kr, faq-maintainers-request@consensus.com, fara@kpHaf.org, fara96@hanmail.net, faraasha1@hanmail.net, faracom@korea.com, farahd@compuserve.com, farallones@nms.noaa.gov, farandol1015@hanmail.net, faranfish@yahoo.co.kr, farang@samsung.co.kr, farangoo@chollian.net, farbe@farbe.co.kr, FARBE@hitel.net, Farc@arHc.co.kr, Farc@arc-academy.co.jp, fare2000@unitel.co.kr, fareana@hitel.net, Fareastex@aol.com, farer@shinbiro.com, farfalla@hihome.com Cc: farhip@washpost.com, fari123@hanmail.net, faricha@hanamil.net, faricha@hanmail.net, farlmer@yeozawa.com, farm@farmteens.com, farmer@leesmail.com, farmer@orangefarm.co.kr, farmer@rice2000.com, farmjh@jinhae.go.kr, farmnara@sorimachi.co.kr, farmountH@empal.com, farmskorea@nonghyup.com, farmtoyou@efarm.co.kr, farmviewcottages@xtra.co.nz, farmworld@daedong.co.kr, farnear@phya.yonsei.ac.kr, farr@arrahis.es, farrang@farrang.com, farrell@baltimore.ie, farrugia@magnet.mt, farsight@sgt.co.kr, fartmng@nifty.Hcom, fary0775@hanmail.net, fasa@www.automation.or.kr, fasanon@washpost.com, fashei@yeozawa.com, fashi@yeozawa.com, fashi@ynmail.com, fashion@fashionwide.com, fashion@glenford.edu, fashion@glrnford.edu, fashion@hiphoper.com, fashion@miclub.com, fashion@nmeHtro.com, fashion@nownuri.net, fashion@patzzi.com, fashion_info@century.co.kr, fashion2@hihome.com, fashley@earthlink.net, fashsc@kunja.sejong.ac.kr, fass@chollian.net, fass@wiz-net.co.kr, fast_ethernet@hotmail.com, fast2003@kornet.net, fast30@chollian.net, FASTH72@shinbiro.com, fastanti@hanmail.net, fastar@orgio.net, fastball21@daum.net, fastbird@shinbiro.com, fastener@lycos.co.kr, faster@hanmail.net, faster2000@orgio.net, fastgame@hihome.com, fastgogo@hanmail.net, fastlane-comments@nsf.gov, fastline@igreen.co.kHr, fastpeople@trendsetters.lv, fastwind@kali.com.cn, fatas@hanmail.net, fate1005@hanmail.net, fate7749@netian.com, fatest@netsgo.com, father@lovei.co.kr, father1@kumgokcatholic.or.kr, fatherna@hananet.net, fathers@kebi.com, fatiga@hanmail.net, FatSean@hotHmail.com, fatsoul@empal.com, fattykim@kmib.co.kr, fatwm@chollian.net, fatwomon@hanmail.net, faultline@adobe.com, faurai@hanmail.net, Faust@netian.com, faust2th@yahoo.co.kr, fausta@dreamwiz.com, fausta35@hotmail.com, faustdp@yahoo.com, faustet@yahoo.co.kr, fav9@juno.com, favhayek@hotmail.com, favian@hanmail.net, favile90@freeway.co.kr, favor@edunet.nmc.nm.kr, favorite@warp.or.jp, favre4@hanmail.net, Fawcett-Hodge@psychology.leeds.ac.uk, fawn@chollian.net, fawoo@fawoo.co.kr, fawoo@fawoo.com, fawwy@hanmail.nHet, fax12345@hanmail.net, faxsender@shell.cninfo.co.cn, fay_zjsfc@zhoujie.i-p.com, fay0719@hanmail.net, faye0623@hanmail.net, faye1224@hanmail.net, fayeblue1@netscape.net, faymoon@orgio.net, fazhan@hanmail.net, fazz4@hanmail.net, fb_lon@kma.go.kr, fb_man@Hkma.go.kr, fb_seoul@hilton.co.kr, fb0319@yahoo.co.kr, fb95004@pine.kangwon.ac.kr, fb990152@ccgwy2.hc.cc.keio.ac.jp, Fballboy@nsknet.or.jp, fbbc@csonline.net, fbbigeyes@hanmail.net, fbehdaks@hanmail.net, fbehdal@hanmail.net, fbghdyd327@hanmir.com, fbghrnjs@emHpa.com, fbh@linkware.co.kr, fbi@foodservice.co.kr, fbi@korea.com X-Mailer: SoftForum-WebMail 1.0 From: "³²Àç¼ö" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Jul 2001 02:01:41 +0900 (KST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] ¾È³çÇϼ¼¿ä Content-Type: multipart/mixed; boundary="==SoftForum-WebMail-1.0-32BF5B923B5B06F5==" Message-ID: <20010722173732.9952gmx1@mx22.gmx.net> Status: R X-Status: N --==SoftForum-WebMail-1.0-32BF5B923B5B06F5== Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable =BF=A9=B7=AF=BA=D0=BF=A1=B0=D4 =B0=A1=C0=E5 =C7=CA=BF=E4=C7=CF=B0=ED =C0=AF= =C0=CD=C7=D1 =C4=C4=C7=BB=C5=CD =B0=FC=B7=C3=C7=C1=B7=CE=B1=D7=B7=A5=C0=BB<= BR> =C6=C4=B0=DD=C0=FB=C0=B8=B7=CE =BD=D1 =B0=A1=B0=DD=BF=A1 =B0=F8=B1=DE=C7=D5= =B4=CF=B4=D9

=C3=D6=BD=C5=B0=D4=C0=D3. =C0=AF=C6=BF=B0=FC=B7=C3=C7=C1=B7=CE=B1=D7=B7=A5.= MP3. =BA=F1=B5=F0=BF=C0=BD=C3=B5=F0 =B5=EE=B5=EE
=B8=F0=B5=E7 =C7=C1=B7=CE=B1=D7=B7=A5=C0=BB =C6=C7=B8=C5=C7=D5=B4=CF=B4=D9.= 6=BF=F9 =C3=D6=BD=C5=B8=AE=BD=BA=C6=AE=C0=D4=B4=CF=B4=D9

=B9=B0=B7=D0 =BD=C5=BF=EB =B0=C6=C1=A4=C0=BB =C0=FC=C7=F4 =BD=C5=B0=E6=BE= =B2=C1=F6 =B8=B6=BD=CA=BD=C3=BF=E4
=C3=B7=BA=CE=B5=C8 cdlist.zip =BE=D0=C3=E0=C8=AD=C0=CF=BC=D3=C0=C7 =B3=BB= =BF=EB=C0=BB =BA=B8=BD=C5=C8=C4 =C0=FC=C8=AD=B3=AA =B8=DE=C0=CF=B7=CE =BF= =AC=B6=F4=C1=D6=BD=CA=BD=C3=BF=E4
=C0=CC =B8=DE=C0=CF=C0=BB =BA=B8=B3=BD =BE=C6=C0=CC=B5=F0=B7=CE=B4=C2 =BF= =AC=B6=F4=C0=CC =B5=C7=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.
=BE=D0=C3=E0=C8=AD=C0=CF=BC=D3=BF=A1 =BF=AC=B6=F4=C3=B3=B0=A1 =C0=D6=BD=C0= =B4=CF=B4=D9(=B8=DE=C0=CF.=C0=FC=C8=AD=B9=F8=C8=A3)

=3D=3D=3D =C6=AF=BA=B0 =BA=B8=B3=CA=BD=BA =BD=C3=B5=F0=B8=A6 =C1=F5=C1=A4= =C7=D5=B4=CF=B4=D9 =3D=3D=3D

=C8=AE=BD=C7=C7=CF=B0=D4 =C8=DE=B4=EB=C6=F9=C0=B8=B7=CE =BF=AC=B6=F4=C1=D6= =BD=CA=BD=C3=BF=E4
=B0=A8=BB=E7=C7=D5=B4=CF=B4=D9

=B3=A1=C0=B8=B7=CE =C7=E3=B6=F4=BE=F8=C0=CC =B8=DE=C0=CF=C0=BB =B5=E5=B8=B0= =B0=CD=C0=BB =BB=E7=B0=FA=B5=E5=B8=B3=B4=CF=B4=D9.=B1=D7=B8=AE=B0=ED =BF=A9= =B7=AF=BA=D0=C0=C7 =B8=DE=C0=CF=C1=D6=BC=D2=B4=C2
=B9=AB=C0=DB=C0=A7=B7=CE =B8=F0=BE=C6=C1=F8=B0=CD=C0=CC=B4=CF =B4=D9=B8=A5 = =B0=C6=C1=A4=C0=BA =C7=CF=C1=F6 =BE=CA=C0=B8=BC=C5=B5=B5 =B5=CB=B4=CF=B4=D9= . 



Next Entertainment, LYCOS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C1=F1=B0=CC=C1=F6 =BE=CA=C0=B8=B8=E9 =C0=CE=C5=CD=B3=DD=C0=CC =BE=C6=B4= =D5=B4=CF=B4=D9!!   http://www= .lycos.co.kr
=C0=CE=C5=CD=B3=DD =B8=B8=C8=AD=C0=C7 =C3=D6=B0=AD, =B6=F3=C0=CC=C4=DA=BD= =BA =B8=B8=C8=AD   (http:/= /comics.lycos.co.kr)
=BD=B1=B0=ED =BA=FC=B8=A5 =B9=AE=C0=DA=B8=DE=BC=BC=C1=F6, =B6=F3=C0=CC=C4= =DA=BD=BA =B9=AB=BC=B1=B8=DE=C0=CF  (http://m-mail.lycos.co.kr)
Yahoo! Groups Spons= or
3D""

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--==SoftForum-WebMail-1.0-32BF5B923B5B06F5== Content-Type: application/octet-stream; name="cdlist.zip" Content-Disposition: attachment; filename="cdlist.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAJIF6iplamK9KCMAAJVNAAAIAAAAsNTA0y5UWFStfPtzE1eW/++pyv9w2dR31mSR x3pYflTtd8rYBlwxj8UmmUwqSylBEG+MnbXNzM7+kP9FOJAAsdxCaqm79ehuS+o2jCyDIeYVMGFw HB42ZgzGEJjac063pNt6MFv1/ToxoL637z333PP4nHPPVWY2umLOp1Lq/d+9+052MZ1nwlXtihRO K0ZYuxqbj91ofvcdbTm2woSQcFtTmK+lpYWpW3YbqzQVZDNRZJ7uHqYVaRDo3N4MvUud330ntRC5 Kq2zzAvtZjaaiDL5Vf5MOiuuCwL01V5F7uCH2AxLrqiPzHl9k2UupjXrVWE1cocJW9hBkrSk1eUH i4Z338H/33uP6Yty2JxPm/FvYRB5a3YSCKJn1/XFdFZYZdKatqwV9U1RZDBngWX+ktD1RVz9u+/A EKcnT4f+n//7Bgc6aUwrQiqlzUfuCZP6ksUA9q//+n+ZeVneUkOsFQjBVaSz0gOWmlKephXmpmfi shTF3qdP4kCn/z9QdIoW99afT5gZljf1ado49im+8Anb3bW3l3k6/OxTxsx59TGQqGrKQyaeEpeZ h3FdWrGLXEgr+TmkP5KYrkwIAvFB8M+sk3X1d3tdvb59H7k83R97XZ6P+nu5IXw4hPQyL0gv2Sfm 5cgtw/yUa/Zis3ZF30rMM8+/sMN6PBXRTCbfFm4fZvxkH/R+DHP9N/y4nH9wg3lwsPx9rZCYhJUk ZK2QLrD3rUnftwbieruxd2pBfaI8lEQhX4+6FuzCJr4IsvHjJ8aOsuHgBDsGv8Ojo+PBCnVpRbpi 6qUJkdXNlcbsUuYJrEiSZqfsjs3NRs7INTfHL8YvatRfkr6V17VCM/eaVhAf4GtxLamGUlMsF5Wm QYqEp/ENeyJzHrSBJuNeE07qGZYxtEL+Frw9q8YuaBJoS+w501bkH1DjSotr76DFiev6WmweO6in jFuJaRZTWOSaFFYeVgbN3BUmQZMzaxIol/qoZtLYj6kt87JlHArSg9QU6CFMV4hO0TNYSBIELXoW fyOvsAPTXutb5nUWPSuE6qzCIiq5IrxOZK1hcRGR09lpTcGP3CraaRWxmyChoO8oy1JYfMmsXuUF EOVCiKki/PM0k39RH0fuMV0XRZA7YTUzK87WEBF9lAjBQpSiNAkmRj2TmBZCYLtwCGZeSmug7aKo /k007QVwRLURUd4edixwPMi+Cnz+ZWVYL44Ce+M9YvGLiQ8ya9oiGDxublWLP0ubMAP2EQRnY2Yt oatrNrtZelbIR8/SJ2VB+E5/zoQLkqBcIq5r39r7whFHes/UKfOFMDU7yQ5bYn+YNX2+nX1wcDcb Hz06AR2aPNrydu41sgWsa3h0JMiGRkgpegJjX/pYU/d21jdydPTYGCx2nDV5ne+RAWD7vwqOBSaG RkfYruHA+BdfjQ6NTNCM3aNHgscD4xPBsXH2HkM/kBfAIGhm6o12E4TjAnuPG4zMBdsZGD5yYuyf x9nuwESQ9fV1ssEvxpCu/UfZzi8CgWFGRAFVMOxXw4E/V3gnL8Weg4wASwpGGIzde2w2rC0blx2z kB1B1ZtPFGGnYo+kdfMXi1GH2c6hYyxw5I/BkYkTY0E2epTtHRoeZR+MjgUDI6z3yBAtElc2MDQ2 FOBGJXvDOtxusGO7huDd37CDwfHPTwSpd4WD3CuW/TkY+PPRgDXmoc+GBnB7tGVpsjOzJi4rp7I5 dhgNgmTuSD5PFGFPp8TZHWj0D1dGarOUXX2lr4F1kOLCDTHBPhodOz7OusaOB44FjxwBqtn77NAB 41Iu1Jw/kzjJjBfm1W3buEEsXcufkcK5eQ/iBdY9NvT5l8EJ60OtAW2zFEENgcoYL4ww9VOkxBsv Z4jb/Da7pXDGAOqM81IYJL/ecJYMqmLkG9iWmdemqc6wuh0tofsDcBoAj8pSoF5aIbMGq//kD51s YCIYHGYDo8NHhkDsPuW9QpslYWQLi2AnjPNAOBN/Yp/0HgcRHh3rBOmbmBgOsqOjY6znxEjwU/Kz Pm3504q/avH6/T6Py9Pqb/P6XB6fv63V52r1tPgsF1Tu1d7W3upq72ht7/C52nz4n6ujBQTE2csP Py6/n/8LfJ2bI9oSWHMhcYopqygM4P5iN/JnmDqpnyEUQBxiPIsscTTCsNHprJGy4EItJy0RNPVE yEhFLzPzgpLi2OW35Eo/nc6CVmlnYV7174gxWaIonlI125JzL1gyZPysn2a5hHFfK/ryL+PPmM/N ajrJ5/RNIYp6mGaz5yMSTx8r97VELH8fnNjsJCwZSC3CrucugA+c89R9xRI4QDW/gCiAElTMwz9l 1mYyYOR1HZHrPJjX5JvIz0yYYzaWjf6EAKkyFEqk/jC+Ad5EBRSrvfZYtufkEthe7SbwI7Vg6sCP ikVlPILq/biTHWoZaHXtbmn52PVvnp27W/jhUY7z68CB16koWKvqn+oRHT+l4Qfdrq6dO9sBmbV7 Pb5KOz8PSv3AiSNHgiPAkbGhL4NgCmyZeZ/W093zIUPL86cAGK5etKsTgaGR40G04jwRadO8C4xC +wHuJ/1TZslG883WMwXJysyCfmuLAHtWSk89QlQDiaGPAA6UIlPkJEQw6hkWuadLzMhp88IrJt84 fwOccWk26q0vsd/DT/Pvf+8B144EQKxwkf7BxL/YoU5lqRZIfA6ABHelyVrl9vKQ+BmQmmjCtuvf SEmYPnYD/O0M026Zgr4ElCOM0Reamfq9Kqezcg4fpiKAmiBCgrggVB4rY+iLLPossxDbstAF23vA C9IZfaylAXBArAMWnFQQYxbsLHwnFxJXrODIQTVqq9N39fWhdTsNEOSxBd8z89xymnzWppQHQD0G 23ASvM7sFA1Q7sx1a0V9Tuf1uPkyoXPDsZoBW1FHExFYWf6aFCdICrCO74CKqUiRW/jLvGj5bYmq yG25L2qkEY5vaAXlISzRA84zODYWYINjQ58BpvCw9/80Ovbl0Mix923XbrXzQ6AmJmRpGl6vtzDU pFyOwT4qkzDLU3txNdpjI5BO5oEfV+WPltZWNz8eakwqZZwHxOw7rH+TzgEGCbKBIPoGgDJ9Hzo1 rBXFLn1BXzts4Y1t22B+K/aCYCAFGxaRo8nsPYgbVzvTAOgAVFJDQ/pawFO4fO62Nm+b2+Vp8fva 2zwub6ubtx+tKDZAF4DQA4DVAGR83swajuhrbWlztcFGdYDv6vD73P6WDldra0sHPyLKUcZQn2GE 0LT/0GB/34e92xuO2e3v7/WB/fHu8vlbXeAHu+FDd2+bexdzudACS+qcJfmzq6Dul0H1E+dQp7gp fSiTqSnpSvQi2KjjxwHojdkihIMAys5cS5kscdnMghReA7im3eJfbyfZSoTMWcvRVYSa74XSCswP Z9ZgS5IvQcKCY0OjJ8bZQOC4BVTHRieCgeO/3d28v7mHfxNlN/l35SH+MqSIReTkw2b1vhTWQ83C z6qIC9phRyTl11BeByYCY+yjwNi4A1XsC3w2OuogDoXXeIVsz2eNNEq4t47ht3oAMgK+wuRgaLTX YOhw9n9xsEi41qxmzesEbeWb8AmC1Ky4jZ8RxdsE/zcLqI00Jq0oKYBvDu/nQ6HWT2vz6KOXCR/T +sFzKklc7w7bmvLvuGk7pLCZJWIKNChrsiQGpD5jyOcQ+7NcKJ2fzZGNB4OO+RTLmvNq7WshCqKP 1JBW0DcPw5C8ASjzqdTfS/btQu4mpTSaShZpO0+hFwVGXM8YYC6LaGbtTi4AJMlf9NP0z9qR24hj mZ8IrsgPAK7wrSgkksHUTZQw5quIrzU437WVJ5FvQCmIngVoc66UavA52nHPcqt5IXWKf4p7BJPI BIwyS0AXcJw3ZV43qbR0B2D9Of55C63I1NEsmzrLnVPXgCJEd/gkf4br6+mgfSB7lrtJQF4Niesp fmEe5Gvudv65kVM3mUOQPMg8FDXJ8QIyLS9B4J5XHwN0R7prXIcH2SWYzhfJ2L9EGpmXGRqsLiFH z/I9vERv5B7438wGLiezTn6H7+MhvoDpmEeRqp4XuaZqiG0rz5BjqCoIPaNFGI6kpO42u5Fj6snU VFrhn7bbSzaLlZwc346M0ubSCgh60bFmN0nYnXRee1VDqxt5pL4Ul4nvLPpImpR0cZ3vQUDzJYpV 7DlrrR0B+aUp4LFE9TmBUX/9VSHPxO/ykvEirXgZ5uFskec7Eeu2Un8HyBDXTOWpfIk0orvHMaXl aYidZ8Rl8RSYmeo+LcjEfCL2JrMeA7HCEM/qg8RlF4VVMHGU+eTfaa+I+xToJCD3zA1MjNeOjsze N8owszA89EfAIWCdg38E71OeQz0DhiorKZK6BRBOX9SKAv6j5JOEa/xwuEMZ0zhjmai2qslwj1IL qkZJmSZvVSvuT/JJRNY32xjqT+ZFXjDCfA+vDTCYXICZmxQhOpVKJTeITHyO6UCCHpRLk4XEJXv7 Sil/PCXgfUAL7qUQUh5COP5N9CxhRq9FGauz9S3uMomszcFw3Miu3/cNWJsSucG0aWkVfD1wKVFU VCYtGinLFzgY5u7A3ZUL5l1P9da4O3ATtWJ+LoGxpvUy39zGmXCPReulXIg19Y2MTwSGh5m8qb12 jId7s29nV5VtdFMGXFyOb4CoAPVlDUHkAuFhjXS5Kd+NaYN0xON47rXMMDoSKSytI9V6Qta/49Xf TRlsHDsdQciyYtxyNiOLTdPI1ZCJLJZvaAVVA6eNUaeXa6VMrz134nJiGl0LzI9mJvfE02mLBf8C cjcdM27NTqJf9XYy8wmoiROXuSnLadn8TgAA6K7IZKlZ6bx51kE45Rwz6/m5bE5Z5Z+3cpTJ4nJm IyF6qo2Pm1KI+/b0Vy2akoHGAtg7AAAXE+cdS/bYK0CmgBeofhUZmVrUw/yzFlIghIgUrBz6gGuk /BnKh1ZMrmB6hW+z8cKauZyf8/ENyKAahtfhN2XAUKtFGQwhLzaU8ZJvxF+AqEXuJVf4Jh85G/0N jOx2t/r5JuRM/vtEEbBCTl4De843klrn1Sfaa+0J4ujPj/DMprxQ9HF+vk5TS1nDs6K0yjxcm7+j zD0r1susS2G5YKSIVVU/A7/dhwGW2+N2tfhb8P/y3742L79RlAkqqU0cTVDmupTXX7D2MnV1x/7y 2BfBNh+Ag9bjY/xw5D6n8TwTaOQbcAc+kMIQw6PUkAoqFuDo7eL7EWrv7ernn+FGlP1ije90U3Il Ni8uo080TVDOVr7VU8bDth2rFlaK/fcOlFF4TXsLgafMGu53iUkMuQSKO7Cnq2f/R2z/LtbTO7iH e4sifQtN2mCyiiUU4Bu5+IaqlXLknShUIfgMkSlgQL4zMtbC4JYNOGV7Yw8ryXttUO6msJ//jNzF vCVQBGa7Cc8X2MHg0LER5qm/1Z3wZo/fNdi70+fqPnSgw3Wg64AfYlZPBz8sblBqLaJ05u/nk4CB Br4YPXZipHNwFHwBhl9l91KdQPsg+OdOZDDIZ0srhC6Vv/0+D6/qlA6QH1uLbvowcPyrobHg9k5w n9oyhA2iOCs1mMQW2INd3R7XQFe/x7W7a9DrOtjV43X5W328pFAKoeLULGhZh+gvkehyFKVdTczw g7gpTaIVAbI89kO/Nfk2IE3jFiVwTNwkGQGEY5tQwCSw3rAxRTxgy4vLMcTEvAGgKB3CSSH6fTob +Yba6lLm9bb7Pf4OT4fPz4sbhemcAXHZcQTfhYTsUeSe9jo94/BwvipBouC6ZJIBtOze39/DN1M8 /ULOJabZLjfLfocHCeByqzSAguCSy0cnh6sHawsxQcphvykOTqWAbwvJlYZ6SpGvqUtCKoVMvAPO QGX/VmMuKKTVFmBjNiUBYxSZa6T4VZjKxvF5J4s/A3CC64R+Ag/e3BTESov5MyoEC1oYXCA48UvJ N+ojvhMyVIhGJEB4P8TOgemp1wl5mzZzaiLJZk/FbpAkGC9yKixi9wHWpGr5++hlLSvCr4QiWYdB Yu15hey2TTbmuxxU++zwR5mEvZ9NRWp9JUW5WTGJGfdPINpZ1szMkqR/WgNI3RT5Wu7KT1gxetuK Set0dVd5L8xpVgewbgqIo4+dCcaqn1RUWgWt2swmo1OUDgbHja80N5d2yvZmtHRwG3IYs99YvtIo jy+eYspT8zq9qFnVJIjgcQAxDwPGnqurNBXPSQrIjfvSZDqbMdQfwBAA2i6nRWAL+L5k6SFW0kON FmRuait4DipRLQJOZodXzqyWmwJ5tLIYlJUM/+CeXtZ3cP8+dqC/a/eh3oZcm51Obmi/akUAyJkN kIIrlA20zrmLNCrGeqCJ5VBmRyOeYS62b2x0hB0YDhw7EYzNYBpJVme0QnwDPmivzWcMT0vVtR1M 2IrcU+cajRR7BC5tDjBY7IZ0Guy5vgUeKiXJWzMCk8PSKlb2iNpVc6kmae+m/AWFZP9IXjzqSzVk 7ahVh5D9uRS+Iq9hfiynaAYhkpKgpeZF9X5mqyHFVjmCHdY1OyhqLfv0f0RSPWcOYLuQzsY3pAdA iVag2g6RndeYeV2RrGqr+iQJq7FHNlal6gvhZxRh8zIMk72IGaXLeSn/PQUYDiEmOw1zR2H7QTcp Rq+L+iyaAdHegv2IXRBCVBxTUsOb2rQo7mCeHmCktweZ+kY+DQGoHp+dakBy7py+JhcYmJY42Lv7 koSxXjSlYL3Go+QCi/1V+JFpizAJFuZA5DNHqaJtDYZTzwIDMHeby7KDB3YDE2I/pn7FU7CftBV1 Dayk/Ab239x0LJ+SLlQb5Wm0ZHdeIZXkLA4MHrmXmDeXYltgt9NZYbKcVbdHa2hpLAvlySu2eeK2 dpsjLvFYgapxJrMGDlEKG+cbmkIqvdlhuRUyXMJUYqY64eymdJp+WkN8scvd3mg0qmQEa3gXV4Py 5xgD7fNHgHZl8HkIVWNcI+XbwG3NM2kDQ9XGMgSeXPgF7BDSGl8SVq1trp7MbeEV8hRGDo/aXwKy r3+mVBq7jgfY5hgTrad8Titi/VQhswRW1oYkdYeTC9G7IHfm1fPn7bdIFJJvdIkrrbpGC7FTLtit 4e6XJhVCZUmA2al8sNpRu6sAF2UY8wk7Z7mcCAlPmHGJcgB1SdeXUikWkbEia00VSfEtAGrxGR7o Ya8iAdrAsrXoNfW+05BRvlJ9YqSkOFNn4hvgH/6RQeOTXY6lUNr8ZuIRU3+EzW+A0q0xKqK7jWVP plIIRb2stAd47EP5INt040GUc389BL7lzegc5n8sMXirRXNIDG4kCAxRQUSUD750PNWpLK2+Rbsp SaKIimEjWrAT8GSFzUrJldh94apzNCylvUAHaXV/7MmAmnJIAmxQnkaiVA/nPJGjPXUwwjpyoKMM UNv/wz47MTYyNHKMHQ2OT7CjQyOB4cZCn1qI3hUfYDHAK1jGDDAHuJieUYA3yPLXduq17AIdE6OJ GPxD18GmmVPSZEO2I3dx7ywAUpFObiRKPXcfPDTQ1dN7cAAD7L19u/cMst+wvV27+7qrR3bgQksw 7JhdXyOlceBkcGJurZg7C2oQol3nJ0bD82HfwcFDXf3swP79/WxPYHi4MXDTpbI8rkSkKrxGKW6s vFK16G2Wyxm52HwFHtcdEfNfihS5Vn4NdkKRokncifnECv5+zTQhpSDbyqXmlRnRcuzq6+3vAVYN DB7s7drLBg/uP7DnY7aza2AAYWrvf30VGBnHMrr+wJfBcQgc37Y68vT2CjH2tOGiEQaAYSqTIPAw JLThGb199s6TQ2UDK9GzRlpMQKSIa3+rRmYvlo0AbuI28hYWKiaYASaNgv7oM8DqJQ1ooEUOmMai ocwWLEU9Y97dVs9V8FSj+fuoD3ho/dE7MPh2w6WKs1OIvG7kdXIH4ApK1YMcESxyjY7JEYh//TU/ H9rIXb/tcrnbe9nAia+CY2zP6NhIcKKh1zeMXC7EEj9gmmEHniQXYUVrINfg42/B7JIhitGbELtE buFxiBBqZGgslM52wdRsdjJ6G2ugQ/omuGWsg5GuiA+YsIKluDLEOVfJJDUaKm3qp+mCgb4EAiKf i9wjMxJNoC35KwUV6vdYLxuN3p95oRXEtUYjlXef55GHTwN6MZSm0+Do3bdvTS4kX4JJ09noWdQn sKIkOup8ShFF2Cqy2ems9oZJsqbYq9bMhlA7lFaRR9+JajqbuwYYsCSEtkeCpZeoBDCrncECIgr4 69t5lBbYgyvgH/IzmTWr0pj4jkj7RjqLFx9gKWggoY85L6w2HGvRipG+rs8/qlUJTowN7Q2MDAXY XioKbizQ6tbsC6a/ksJ0n8RGaADHMJeaVkAxQe0tebaKx/92/tdGhAHRV1k2KoXLVeDNTP459gi2 RTylFfKSg050Id39+wd6Wff+vTu7BpmvEZF7B8BYmiyiwF+lSJby8hASYmIeSzXysCPVbooOvg58 MRocGfqvtwtP2VGp8woginB5zaARekZPwB6lIvmseR3sU7qoPi6XqjfYoWVpkkY25wkGZhalfOk2 DtbiQShhuzBrFscO0pncR3t6e/vRGw72waO3036RVZlSCxamsxArUYxossy8+gRhq/WJfGLtcOjv qywYVe7pekRS739tfcAAWltEJGndkUD1V0N4IaJ6OIzFsAXM1moqA7ZBTwKwSetAh3JJ+zZyT9+U JDZbzGj8oE5WtNmJbIg0fv5fIVOmpVMKxNtb1aZfXpLyViAGelYOxrip0J8ODB1he4NDQayJ7xoe Co5gtdL4+NGhseA/kBzKYexgmb8YOZbK5MFagxas8UAFRIhgYjpb7ygHYUumJMiwhcpr0L8IS4FO ojPLZRMKgLEaGEDnqtxHn3XE0bdvsPfgvq7Bvv37ANzs2r9/cGdXf/9bg6C9A+R8o2fVGbyplMve jUh2sWVvF2gBpc7AfC6DcGfMxAzYvHg0U8ey65tA794BhDHXkhtM+kF7hRHui+wLy08nWTQZfR6b oVpgikjAVeclJFutlzezabIuwIAU0cU0WzylB0g0TNXbhQljjHNInuI3wMLWSUnYdgyk+Gb8V9BN CWcHj+Nj77M2f7u0LhaJC/K5hM78LXS0jOmzQnKDzsVrfETsAkizNVuJJnVS3yrP4MwhgShnsDgv HxFe1Y5mD9PVR3XXyDBAGrqeMUrDgLdQQ2hhQeRsa8JtPUILPP3CQwmWmFYevh1+XWYev4RYr5x3 8embEWkH87QLUUztLKcW0NxL4D5nmZIUbmNKsSEkcAaepfX61Zdg71JbxFS874AHa2klsoY3dxqN 5Rei6ku66BffkOJGmryK+n32HvFB/T6zyE9XqxKIH7qHAfk2gYsA3LqdNZVc9/b64UQp8krnrJjn 4IHdfNwDP7YeW1eFIgpYjhp0VK50s7YMrO8Mw9tDuGXwz9mnqYV0TivoC//+741epciPDGSJjFpQ qRXsS0roECVMpFWPJuXVx2izFRTuMlUeSmfFsELHooxEqWRbQa9iz5WFWn0mm08CtyBJQFiJJmJC c6OFgMuz77LRQrRv9UW7xgOs3Csg4gEDaXqD+BWcBE5OilGzO1MQ0OVe0mER3qUDsGrc0p9aRgAg 3ByBJ7xeA7bJ5gm6EkwLPjJqErvmPbBH6Wz+vDAHJsSYngnVCg+Cp90HWltamnaPBUaOsANjAB3g 43ZWOp+xawZLeay3nVtwsAnjaiCLRBhtPR4BYiEhIBjCNpiQa6AQeE6EwWL+ezupU8pbgKMoEYUN +pIVvqGJVSSNK62gsha8z2kVtNYmQSvBDd8N8/QwLjxEzLLDTkEqxfwc/vMUajGD3Sg0jMqYuZDa pKwfHyTxCaj2Dt59Ub2MOqfNV66/pJ5hLW5TJTwb2APebP+hwcYhmqy9ZvJmNp4TSFes6nDMDdC9 XJQcXqtAxmBjagcrJdfBUmr36M6jaGbWFCmdjfzsyKFR+Y66CRsawgsqHvtsrEmZNM5Hbze8VYLH 1RDb+P0dfpdncPeHrsFBv8/VvW/vh9zQfjoP1Yp0WIr7wrU5PT/V9sxOY7mFkQaVyP4EhHu05foG r3xCVLam9iVIDDtYei52A13j71CAo8y6WotSZV6vv5oaMNXurZPU5ZrRRHd0xFbTCv6CRimpxAqf FqLCIjsv2VF9tEsVRpWPVFOUv0bigj5DK8ibXBUPlRUJq9JkXmDuNu457ltKz8/FN3I3+fNxqiIq V702DezrZMfajvzn+NjE8BcBz2d/+tz7HxwxVFmEp6P5R9o8IxBKl1mahNWIlNB3yA/00zvS+fgG /46vXOVhZXrVrdhzrtnrXJ+HrynlqiWoxAhEG5Og3uqdiSbVR52VCgVEcK/1zVQhtqVc2oZXBV6I ov0yJjDXpUn6kgP7FHSl/kbLP2gS2u4V+YfMK30Tz9G2GH4TAar4RS1TFX9RoRO4/GfOEjGqcaou tKFjbW/lnLpmKTact2svC4gKr5InZtJNsjEYp8GasktCSDQI2jXbhrjeYrA4Q3wA+n3+Lyz7jbqJ 4AdfMIywcRmGkWTgUdQeRvtVfADPKIeyWW80PWrl1i34afXTt/hC0XKID9sQrtUYq0DLNHJ0tbMJ 8SwnMFRvtW9nV/1Gqnp7gXUkXJkEVVjJBXEZYpG1cqkJ1+7jKozxqKq+ANmCkrlIIVMBXTeskj/P 4oa07vIoj+nQ2sOaSsdl2+uP3dFhzsu3y0fg5dM1NLpliMuPj4ogiYhYWP8AE56ausUQp3mgOi+3 ByDma77Qj8q7jAU9bFU50jl+AwJLJ1j2YR+AuTwufEeJG5VRMKhbx+IAglRM+MX+ppBaCSkv1tuD ZcPntGWytSgW7Ox+rPO/WqM/VFuG36wgheVN7jEdmWXBS99KreXPcNVDVD7GVSUlipFrWCtHuK7U x1+/xMxDmV08paoi38bIRf7MvBTXAJz9nXV2yuhk2w5wKCkwBzSmorJQ15QgFhN+5RFSCbg9Z+ZS LSda7YLekpt1uZSHiRWsiuc6oUjv6sLaoLAM1FAZYhMGsts7e7uskIrr7a0akmvyWGF0WePsBBSd mkY3rOw/J3FUDIa3CYxbRtgMsyZvT+mMgO9VKvtkYLZE7bWnvm8uiR3mePlIAksuwPY6jpLREFu8 am5urm+ytVd0Hom0WD4AgnYLudtkUcGZsiqdZ+5mX6B048z6upN6amGC4NnfXQEkYr5s9gXL5cwk BJEY5uF90XQ2d1kn3LcI+oOD1w/3kKF0Llr6vgIr4LLeUECa1DX5jibRd9NgFxZdzKzF7sRhC+oN Z86jcyoIF6Bf+ZrTNtD8FumOEKIw3l4YJ1q+dketFEv/tan7N91oEbdjPRGLP8OasDp6UcKb9/W/ sVTEjBKgovohFj+VukLMELaE24T5tenYImyEuKYtYxYKt7D+ftn4EpTRxBgnd840MYE4K5rWPoKZ XBJNh92ler58knuAKi6chFCHf0g14hBy5O9jHTWd0nKtPute67T91TXl56gl4qnM+dw5Xnl8XLWt s9qPqvP27eoHg8c9JNt7Br+bpvKQavDEn5yvU72d+SS3RJUFpYd0umbYN2C4gkWrpg5vP25CIKWG TDO1AAtwcwvw2pZjztmFHwSXHtvSXucF45Zj8VQj5/uoh8lbQlSUy7Ef1wP5oP3CYvO52/ENuraF bolx+JNq4kp3z7nHVrWxuMIy1zE7XtRe4QEOd98D2ZNZguiL4xmVmGH9PM9dj+OGsKMF+ROdzhjx DarHViTHLajW8nVI540tHhrwF9kIUaQV5+0uHGMl9yPzNfM3Zt12rTZ+64Ndre24ZIerF0Vxnr98 gb6rKC4nItGLDnqoRCRyP3InIulxrEDha+nJ4eV+VU/xldx2nW3pNrVjMFKDKGAilwu/jYuvGK25 Gw5dWh1dCOGsCfzdC6pZLdIFZi+rHRQZEbkG1tUwYyvCak17C10OAmi7TnJZ3d5BVZr6ZvYkLN1q 5KO+2op2bhPa6t09repDsU6pokF2HM232jdwsORvBTCr16nnZAA0xGJWugCvEPOUe+1bf3SJ0VOz MGJbBgK8u/mkBQN0I1XLPug1Mx2RMGuyJSUTOu3l/wBQSwMEFAACAAgA4YXyKlBodMguBAAAwgcA AAwAAACxuMDUuea5/S5UWFStVV1PG1cQfY+U/zAvlRLEWuuPkuaBtP+FvrUSUfPUn2MgRq2KuRvv eu+u9+Out/Z1UsMG4hhcZNOkdXBEQFAq1w1E6ty7uza0fajULkjWzr0zc+bMmVmAG89i8gBolHXA emN9YB090nuzo8Xbt27fgjnwWpUjHjmO/8un6OiGxhnjQIqkT95L55lvBu8D0DPjSF7T60BOtAGQ iXijlNWgduQf830ISuwAf4whrSR+MpPb8I+ZDVlVhY/ApmzIX8pjCA9bq4YBjLtPeRSMgVYFHEAn /C+tlor/+W9NBFppbtrEcVikvSarwWFCyOLiA+A71sQvwsdsKItwQ/oWnA373EW00paWUloRgUr/ A6LHcXVzwANzW9szH2MWQTdHdMCuEI22Nztrg3dafQKEB+N5ybL1AYxTJFO2RHtt19glo+Y2eD+Q EyAjN9TrZAvdgsBlAnjSAtbR+tD6HvLzBRaJ43HlW2TeIoTjm2HUJ7IB3jPR3Df+O/yxehjW/676 W9AVXUmbOYXGUQy07F2ANWmt4n16bkZYS/0qqPLI/waCrvvMDX2WOgppxdRLAwDpsBdCQaAoUFBV 1Z9IM9ts+qkZJTOzux7/J7t9bpz57G8nMmfQtcpIVh572a5dUArWIKYlA9du8Mjl1XVRct8YuuG0 RGBtuu69xEpBFgmAjEiH/YSTuA3/8kkmU6b13zkH5itMyYbOGHtOrsjIm2ArYiKSuQNrpA8QPymy IbTKLuc70AitES0hNDFxMQG0UpuOHEYOHc3CRsgbEQo6WEO8E5Fp1y86G5IFVnPGwLrBGN9ERL0u Q1ltWpY9R38hyOq6VUZ0zRNMnPrPvBMqk3aKeRKhkC7/lL1A2AVlITT8SbBmGGlBxmX1AkPY24GJ IZN7QYkU0aT/HO+FabSYJFEsqjfRJ6NySK1D5yBeGZPUKea1aG5isMpGuqnipaNVWpvXFtNNdVj7 AjIWHVb8LaADFmGbZ0LRe8iRsNpU72HE4PdgBQe1tZGKIRJDB2LqJHLZp2TBGdwwzOj6batXncRn kPDWGujHzT9A7Gw1m1Xuf7JwX1nI51V56DVZG4UtDh8uP1z6PJv77Muvl5YfZZaWM198dW24hYaB 2fynGyPGd+xLYcTQC/cU9V4hn8sqak7JqVmAeQDf0vpBFxTQRmzbMdPVJIDiHDxhuFbMALXe8A6B 75It420aHiCbkYnZj+DYvIMfDaEL+7l8gzuEsJqcKYTwHAlMAuHQ3JVDk8tIVuRY3RGyQX5Icaq4 ZBJZ1zsVqSWd8zggNOk9tr1zN50+RXmQsIgrjRT1pzMd5TPxjqsJdBQpQgy74qCQSWlrgNb39mIq 58THKqxJayKgsOto6K73+D4K149sbDjp/PVTlyCxIrGFG2ZRiAKhUip1Tl6R9yhj71cBAYUSf4Aw m8j6J1BLAwQUAAIACACAcoUpevmGubYmAABmTwAADAAAALmuwabH2LDhLnR4dLV8e3MTV7bv/67y d9ihas61M26h7pZakutkbsmS/ADbGElgOyE1JWxBfGNsyjZJOH+cz3C/gsMjAwlGjiSrJevRQpbk ZIwdkgyvZEKSG4YQAkPCiSEMqbq/tXe3JD943HtzVTNB6u699trr8VuPvdvNTbHPjc+MFZZfTlYT F1jmk+RtI8PyldSsUWUXnsTuLt6qXjEWWUbPZgvf2ZrN5+NnWbWYWp2/kjqF54zr2Wz1EosvFu5g cPlOrqwXC7PZcyw3H/uc5X829Fw1u86MyzkjsZa4JogkC8snlnX9NIvNZvRcSb/NYmXQ0u8nbzG6 n6tWv07/Btbqw6wpizc49aV48iaLPUmVrOuc98SdzGrmE7bwX+B6/nHxcv5e/gYjYvhd/TS73txk EbRt5XvxAVio0RUsYq2xz3OlShUEjJXCneoa5zb5V8FUc9Mr23wYY+UzqXeZWAVjr2z/oeGMFb4r /sziZwsGNCDYBxe5UvI+X1DhUWaxMEsLWmGxj1JF4zIei/2j8GNslulpcylEBiLgQsfA/DJGEAPJ Zc5CZclYw/Dk7fw9Gp48BV3aaHLZxgo/ZueZsZrLlG+x6t9Mas1Nio2PzJU4QegpftnQFx5gbv2r XKm4jtkXbkAO8UW2tFRdLF+EnMq5xfX5bwsWF6lPWfLmwgNjJb3OiEFYmaGnVjkbsdlsOXuOXx2Z ioy8ybhR8a/RUcbnqTxO/IJ5SycMy/iam1QblsnvML5Gc2HVNQyu6ZVTpcfo5iLLzpdLbHmJ7cik Yc1r89/uYOn1SowlzugncqXY3Tb+fHUteRMEhSAgNpoDvBoryUJ1jXjF+GuFM/HLG8bXGAOFloxe vlNXYM1BMszXfmBgavLwVOQI6xwbj04faFiBKXlhTrZWk1bxdOIOZsfMK4lrZG0n8/dYPlP4J4td NFaL6ywdy9/L6KRKtqOQ3sEgKFonBlgcOWzMeK8UT8WZabGkTnMaur+94b5S8/qn2ewzLLlyfvkh a0CUXMnClKollxW2eKtwDw629H7yJpS2v8tL34wqhlvGAtOa19PrxhNjZeEBBM/9A8PucIxKXDNW UpnKHBtimk3mZuOy2VnsMYO3njdWQAhzk8Igfd00CVZI66eTt0kKJeOL6ppxXV8wrlu86ldLNyDf 9Lo+Z/oWDPBRcX2Dj7QJPviQDFP9fAVgNf8oVgYPwgnw21grngS3+VuwneqaJfcqdJb/OHGBaxc6 XLGAyvi80eWwuJwpoTbu0NXlmlig4sUfF95jRQKAQj5+vu5d+mLsLqdcupwr1662xN410RgQnfom VyVzM52kFdaVjS/NbkCzuovpc7G7zDiTTBZ+xLTzP4H7gpGaTVa4Nfp7e03Pw8Jx5RQrnEmdh2hh yl9YPpn/19Il08PFDcLylcUH1avFdVPKySQQzNATa8y4RcxwS6V7F3EnXyleZsUiZJ3+BwJBXUww bIEueKiYT/2KVSX/tfAA1pfNwN3L8AqEHT1d/BQe8Dj9ffYzYy27nlpjuY9q+Aam4HhLpp1iSXwV QoeEXyBdvZR+xKpXKThBFoUPFv6Lpa8tPKqx4bSxhSq3CdMkng3U+Ur2XJspjQaAbkBlyxo34pix lv678S/CzTYxIGMSgE9ZyFmDSxIFpzavcxSg2erwb7rg53Xi0jYfSzhApZblk0YmeyH/sI3bSitA 1OSRfpogWZhNXIttjTaLHLME7GfgP4AlE9sAS4WLsRiHbZK8BQzVq7FvLEO08WTA4/mDQKrmptmr Nmhk/gvTKHmMSaWL6zkggT7HMudj/+B28pLpsQ2hCOg7ODYxOvn29IFg9HB0dGzGFn0nCrMmXrnX de8ODP+5d4/P2/vnPq+vu6c/cCB0fHomeuSA79jUVHRixjc5MTM1OR6Kzhwwvx7oH58+0Ds5EhmP 0iQiAMx/m1mMnW1lO+z0ccjKDvbKn7Zctnt2wPmIY+5sxq3MaqX0VDz+v/w0N71M+HECSFst6udz GbWlayoyMcoGpsbeYWor22lFHkR49x+4oNRRm81WmIUn619lz9VDfPp9YMRphPAYfIklzuEBMRZK K55EzsSDehVeMjLKuGFyQ0XWyANu4QyXNFe2pV6BrC+zxX/OQ4nMxcBP7QdGmqmH8aSUZcvn9Nt8 ihoVfmWF0jtCkuo6WIDbrDU35e8BFcnlTDNhpXf5yMQ1ymNo+FXAZ+7j7D1wALxHkhCLzWcoG7I4 grTmstlcBjIwVpYKbC9JasWC/fj5C6cQnKuXyL5X849NTwWx4slqjPCsdOHX2KwIHQq0/WnClA7i i4EMCtz7/BQlvkgWQCO/bEISkTC+yD9k1VPIrq5BhgUDiHThY7g0AOh7/NPcpC8UfgRnlYfGavki NJI8RcgknmOJL0s3cI2rh9hMX6GBJ4oLxZOYCMnKKSRB8A2Px2MyRbcIcUGEoy/cmwuqgW/xSLaM lW1SXfZycQ5zZ34AO6UHXLgs/Zt5t3SJuRS7/hUWWjyZTFI2hPSKFe6k5sjRPyaBMyzIBLT8o7oc iRAYIYwrx3Qd6foNxMjUBa749DXTDCwujPO4QPyylsCxqUn+ledQve0HorhAv8nbraBEE4qv6SrP 7mIfmbbc3GQBKGCLEGtjVHyZdXa6rVUKjBEQA5EXPrDkotj0vxmPmc+MzJkfMEfsBL9Lvi70Z+oW KqM00tQNPUOhbZGSTl1P3p7/tpa4molw+QP9POwXfADxf6Grj+nJWyZ5p83nD+7p42oTczY3abbM Xf1DnmzCc+m7kIB5If9JyQJrH7gCZTPrpRtUL30gyLhstHgl/ehCjBk36WmaCbKKI2yJteMpt823 k54D4Y7enj5bYChggmz1ksmjx8YrMYq6LLlsSU22czbhrHC6BOL9NYHbfDlm/i5Cs7iGVC89hwzu NPufH5S+ESwCfl+jfIkMFbGWXBD5Fve3pSVcpAnwTwCLswbZbK9jbtkm8jM8WPi5+NBYMRM1Mv08 8qZKVciNc7ZUrMylyPeN67lyYZbSDMo1snF4yaVaxF5J6bhYxzy+ULBhJSrINU4U13XdZrM14M5a tUg2Uy0yieXvVR5eQHXzMJfhQVP8pp9YtLDXGq4STHKww9Iqf4l9SZVkiYMgsSMQmdvELM/0eFm6 pYBiTI3FCZYui1Uk3qcxkIISi7P0F4jxF0hnGZ3ko+sWvFpRli0+SHyJuzBakhPRpRkKH2Wpaoaj i9oEHPP6vqEw4xLC3GAwfrasx8+J+QHMxRuMTR49NDllGx0fx7LrAoKpHo5Gpg5OvmMtBFfw0LRV tMUv83Q4flb/DNrEEsD9G5HxQ9L42KFowzO8TOSp7vHJY1Mkqzejxxce4DdV4/pt0JiYwaWGfIHz G9rZT09CXvQcHud8bn4Qq00/Wj5BGvsXnyt2BWi2yCsQU+ldA04AVN+e/lDYyxX9WvGy/tPrMWq5 iOycBtbm9flrdbjg8YLpVxTq47gtRCGomv5HZExk4+H4KgggFtXcUjCCkFZ9TRkZfb2d9RAzSPBh V6FAeN+AJdQY+aS40jAwAVyvPHTsLH9XRuqdSvxmWiwyYFhyYX2ncREp2j8Sv2Tu7izMkvXwmFE4 BRtYAR/KTnp4+WH+Xmq1eE/dibRfX4h9nkyxnfr9+J3KY31OYTs7ezq9BOU7+zu8vT37A/y7fr+s 6yf4+OJpA8VySU+wpYL+dfLmzthd/UQ5JrtY8l7ynuljTATxxZoDQYbmFS6NT1NFS8Yl+CfTH9E6 ecMjm+XZELfQs6grBOIgelRJ6Om54mkqBCuJNXg3J1nlFy3tUALBf18QLTHKdKufMt4Ts+ALdCQG cNvkrlynlj/BJXxBr283ey3gf12EANP6TY+qXk3csha6MUdnhTJBQ031ZE75Svp9zhcCcAOrqfla SsWrkiuI0B73HwgdVkQttsir8QZws0AsPaffbWdLf2dlMLdUWBdip1jOahWPuWaBQ4LthhEMhV2m /B1SetEduSxK5pGZo3XMQtnFyzVcZJZ1lk4Q6FPjiUJ0rlT+sGaiuTJiVpXlb+jF9sK5atx40gZN 5jJL76OCyGRTt7JVwaewC9i9bLdT90Z0JKm6AV3qEfBCnyfIdZugDNkSnUiKF1nsHGSK0vQb1uKb mRpnf2Te8Zk/Mn90PDoTFX2n8vJSK3HJKMALNCUSAlDrKk+tikaZifTlmKjWl+uLy5R1iHK2isjU zpBw3KI8SwjeOONxFu6IPO40Es5ls3pbeEDZ12BPP9Raa9YRTH1Ss3q+IG5FVucAj1U+WRIBg6W/ 4pF1kwEJjig3BVdXjJXKnFtpY0u/GivlM0pb/Cxd0b+CBZbP6HOlpVzGlryfzVfmmGpDnf3T/Lf5 ewozPdbsjCbTc+ztsQnKGLh3gQuzNCWBtFL1vmz6qNmUFMgtFFIvELG64oLxRfVq8ev8DWatEM/8 O5+CVrpdSWkmq9VLPJ4WZm22P5n1ZfDYBApLnlqyFnDoce70uFuZDV8neH3Zwr+1Kphma3kpTfPy UqqVl2Z1KZnVpYTqUhLVpQoC4puVNVK/mjNLHFJBw5f0Ka+iM7Qs87nSu7FZ04XYDlGD7mAw6OQp KIQ6VfUy1axQRG/YZrOeNhabmwi5ReaJGSntKpyD090t/jb/rVUfmgTPAoMbKl+IvLHgbW5KX/vw GpSPCIchH9tYS/GfcBwxFZymkKQYYCYFvAlkfIb7yOaRDPC+mKiU22rNalG6AJBvYJm8csHE5LZ3 S0v5RM0gETMYBQ3m8XCVc7MWIJhYY7EzxnV4nPEEReVpRC3qe8GC43/nflP4IPaNuTPy0ksYW1xk yx8mEDtEFsQfZBTiqqXUaup86V2umGUohnLCNkqA2ogGGOQoQtOQLDhh6tq1sV5vf20qPFbKls9U Yem2FoSXz1nhUQpZ4/3KY7iJsZK41lqL9vn78Dt8m+cJnHE5/zi+BEaTd/ErdyOHqulGI1AkC/Nf Lf6mFL4sXGTJZC5DUuDimP8in6eO6+PinNiDwFJ5ZDPWMovQV+XXyhzPDPlOipXmUi/GLTuBhy0o 2k9XqkIprW39uwAsbdQ4aiQAYSX/hUXO6zDY+Z8pgyEqQHIjl6+2hCmqtXJojZ/l0jYybQgyuaoI ssRwiToKhXPQj0jYhYmsCHb6QpJ/T8g20NMZP9vGNfyf/0m/GA/m1HsDrqTWiicztOWU0UHF6s+3 xe7Of0XESStE3rsvvAe5k8/W4Q0zSMu3p7+zp8sWGg7xLjv02lI4M/8tSIpGLfWBRWLUyhXHFcSz ylrbgZBbv93GqvFsBmBCa6YGwm1K8+pJAKmpfF9fMJ5k41w1mZ+S9wsGzchk7eDYDN8R4EYvamDC eA7PbMAb9nVTp/ZnDsxiIBndk9j3+UdkERQWRbAWE2Xups4nbyqsLYQ48PJOgbe+faHwvr5aCmgV X1bLnTrudlbL3Iui8Vzzx3pWmM1WPkydV0XtUnnpJZYs42EzWebenfmkjccTznO+kiGDsFhDYncx lTZWsucUToF62KgwajEIYygAYYQISemvQJA3//ABUkNM7XXRSMLhJbYTwbLysPQQXwuzcKm5nTSa 8sds1qrVRbCN/XVx/bXe8OuNnFi7KDRGhJkLDVr7lZ5K/CJWbFwvZXlvyViNXWSxGC//fH5JlLMB vi9AiGv2CLhJcfOrXo2vw8dM2zZHihm842ORaTYYeSt6aAoxgvVFjkfYW6rNTrcp06Oyg7Y2rA73 yy+zkfbaHDAFUU8kLsBpRH6JmtV6mO4hD+kdG4lOTI9NHGaIRceOUkLJlbyQ+zhX4g1l8WBzE0/p fLz9bCVsVqiZPjwWeXu03nTBwkbaD0TePjAyeeRAdGbkQMMDZlHSkrxe/E1scP3cWt+EpEk2ziFm iLwt20YjM1b2SMGoNubfRSU3eeTosZno1J94UBTlOu3siiaCsaK/x2VgRaS/12RGm1+4IR7kz2WA FsUFCyyYfjeFwib1KeVb3CDfmJyemYgciRI21PpUzU35v8KxqRnQ2MzX9fzXInU9NB59Z/wIm45O vRWdmoY9cf8s3qDkDOOPTk7NMJfDwRpah4uxlRqhUCC4PxBk0O0qlsUG8Di1/ohy5WFlzmwv03b3 RgZoY79AhgVE2KwnM9033luaxfiByMwbhJQ8xagJiFYEZXoHD/j29G1SZnMT1HBps3LocXOxRBkK j7z9Z7Fskhp/lDfiIOpF0cZHkfzYuFnTaN14Do5NHBg/MjM5OT7dYF4ilFtP7xiZnDg0dvjYVGRm bHKCHePWTPPBtKd3iOh6iSy49mC04Xa5aoFbzTPOpddN5rh2xXXWUki3syPwQZUWhxylUbLFdWqa 8mKhccwLf3jBs0HK40cOT5lC9rUf6OwNDI0fObBFkE+/OT55mLVY+3KV4kPk6zxOFB8W32WNTGIl O45NN4iE4meOMhLqqFCdQiCDqDbzRpSNc7iImlZsAhCjHXakLRQNMMOO6ZkIbFk8wqDso5NvR6eO Hd3BeC+EaG8U+I4QMA74w+en6ak7Srv3w6Qg8fsvtWeJ+M7QzOTRncHoVDQySircSI86pJzbmras rXKYAWOCBJ8vOrWDNbRk/9LQ+9UXAMuKANt6B5WqtM2Qt3yO2yTkzL+ZTkXjG3AyeZL3pyxXMceI oFS9amZZlI7wKxhfSl+IFa9Zbk8Q92cL4v7Mwadl67XW2G/LJ+olNFUNiTvUtWSJW1vQcJEVTy7P LT9k898an/NNknqZaWUzyVXeAC5es5BesGcen9ksA3Pl1qr10xRnqU9qEa/G7toofeUF8GPeVuYt Ge78lyyhmNhRFx6lRXxbicK/Nb54On+vUrWSbDGmtouEIhuPkCNTsVwRrADUaktEnS+2CmnX+evY CbHrYZaKn4rdelEaIRZgEG/dUJy/TLU+OX2+whZ/S71vMyVVvGxUi7OUAYtO06cL7zE1/cjClqsN eTTH7OoV/ScekMznbxBd2sUyd4hFlWtj8SsIOg85JFmtBiJm0TJn58YqOlps4T19IXGtLpHlWDaz TAX/0iVaXr0QfnnvscjUmyzwztGp6PQ0cyDPa3O02ZV/E9eHxOWByPQ0j03cEWodSuraGjmIf+n9 apW3aklYbW147NhRWHiUEqbZ+FnauptDyOL+dQID977jsCvHjm5OIfjltw7xbW3TDjgbgAxr67m5 qWGQNS2thrNGCmhueumll3/HT3MTP9/z4aP8PUg0/gvf+hE72F+WvjZWjJWlL+l4Cwpjc2+pSOGO WDEV1JL+e/ImsNNil1T3eWvNtrm3UKGHwYD/o+aJoUP8xBBfv9BCc5OlhgO8JGxuqondEulbhyh2 k5tcYrGHhdmGBhIZvaimVnj1jltMr6avglXZ7m5uOnh8JsqORmZG3oiOmse9at1PSnlpG5J6+LRZ CRJQa9LQ+YI5i3WvizU2qgZCNh545u+JLVtUj+RUCDxk3h9Txmvmpfm/EgbUkxbSudhP+YYZD/KV wnfsv1NLIDUPd5y/QgcMK4k1Ou8gGHC8dagFd8/j2j3e2OKrL5yb/9bcQZynAyO0kUgnARMXeFQU RyIY0Y19RPsoosogDYG1XxYecPr8tuBStNKpB4PSCPFO9EIbH33l993Nfx5BUeRgwfpc/gF7IYK0 g0vNeNRE37DYTyhit//Qbkc76/cG3VKnd5cm7fL2OqTg8C6X5HBrLqTpH+VRYKu0Cbtv9zPSGkHH 6bTLkuJw2J2KLKmy5nbaQciheZqbqh8nb/4b77592M7IDarV6s1KybE9If9whyp1ebvcUq83qEmd +17VJI/LAYay65Uv0td419Ful5/HkOy02yWH4nY7FFVSPG7FIzuJMdRy/d297NkkthByqm7ZKXsk u0ORXXaPpDgVFLH+aPQoC0bGRpEDvQAhu2J32q2P3NwUKxf+aTwx/vlifHjHx1n2N+N6mwwzFCEv 9W4737szHrPCSX2uMse3FrcO9alqUAoOaR6pM+wblvo7ugcklxNQv/yXwq/80F5ZL3+gzxV/fhYD rMvbqUk+b4dDCgWGnNKrw72apGgkCIa0KfdR8V4L4sDNyqXWZ6/ErWmq5PBomktWJNXjcLo0tyR7 VAcFn3OZH/TP9BgrY13lTC7TEjp28EhkamwiysJjM5GJ6dY6oS7vcJ/X37FnWHKFA90U/kuonf6W K6WXqHBHFpS/nLxZuLA9G3ZVhT6hXLtHaAQft53Eos+V18QhCKzLWEW4TlO/lOmf5ea2kNnIBE/z Le2wpS+XfiXL3zC72OsxXbqdKQHZ3uHr7+7pcWv7Bpz7RaUQHOjiAeRiC4Fqpdr6LIHCmHdjAQMS LSNkt++ye12dPAsh1o1VhbX4KdwHo2OHJ5jSui2RLq9fk8IBaNe3b8AjDXgHNMnpVDx0gvN+vpKh ApoIjUUOjk9uJVKjs1sJhCV/uF+Tgru1VyVfH4EJS/9o7gyylv2RI0fHpqKt7UjrjJss/X4yuaxv IAEBKVLI26sACMKqFPT6VUlzOkg12XvzmXbalSyss9Abk4ePTbSHJ2ci42wwMrXV4zTSLiDJIdf/ 1RwKGVriTjoW/yBXmj+pPN/3VNWtKZpH8Tg0FAssjLojHBmbmImOPn+sQ5YGtXCvrzc4GO5wdyi9 /TynW3ggzsvyowfPpsDFESRx+LwhUxyq00F+l/soVzJBeuk6DKrSlr+vz6VXKtkNuG+aiQxstkMm XCzmvw6XKnMVw05vsReDIrvdLe0aAN7bPW5Srr5Ae0Asf5XpZVShbiYxYbXb2kdXd8DlUBSnsy/I iyE6BYHR/LhPJpv6jW2nkOmdE4SBCqxbdbk1p5u6/mzTaaWnfcTgg9EJRToYGXFJB4/9hyb9j8io SpGFxBin81fc01pfAMcVCpAIAW6HU5NkWVEcTvpl5/oo3ntxQna7x6VIHllVnLBL0HG4EWkUsvPQ 2JGRsZnjjFT7DHqCkMfT0Yn4q3rsg3sJBetnTp7PhEvTZMlN6gAOymQKdF6vfMdYe7HoiFlVt6Q6 uHfmMoWLtPH3QkM7yKw7vB2N/1FUp1KPSy9mjR3DvfCKXfu6VMnv7UKMG+5zQB8e8nKKIpkTcIxl lvtfLb5/8zGlnGl9qlnbXU5F2viPy8kjpTBx08Jd7DVh36+zFsW42bqdiWMlTk3lJi6OQdDZQ5MI 0VDrNDaMHez0dSluFWnL3g6M3bvPuzugsvZ8JZWOn32OJLpc/oFQMNzb7VU6Bn3qLt4D5y17Bjaf L0nkOHao0oX8RnW5JKfL5QZOUMpkbUinqUH6fHwgwakOu8uB8O7Rnpnm1jZs/k+y3IHI1MwY7wT2 RQ6PjbCBqUnmRG27LTcDdG4m0B/q9fkl2fyg6svyU7S+P/6RdRwbG6cUjigUTpQvCu8pijqjOpde L55nmizTuUfrrDN9CKviV4zP2tl+38BAhzOACTEfqEvm/2VmPb07MEyhIHrwHYjW/g41vMYmjh6b aaizGXWwFr8vnubF0Spi4wr446jYLo5h1yvjiUOTfMP+wpPiQosQ2x/re9x0i++jNzdR0KU3CvhW 7lO0FQr73Xa7AlUrgDW7ipTO5SLrhSeiuL9vnKKOEIY7NkvYhACHXbYjlbLLLu68z/r4/JAET1gU t535wvvs+Efp7OjrGPSwV8Pdvf0+BJQeKfRGZCrKVJtTmpl8e1s0VxU7ycZN8mF2D0U2tbMDUvd6 JGAxGOoJdXuDARivdzRydCY6wgKR6eN08sY3FY3MTFK6gBXJ4vx5I2lZtqOQUWWRpadvJ1cTd2In 6CQ4M57Mp1nsyfxJVlxPJlnrNoztCsmQhMeNoju0pzPM+rwD7AWRTJbr9nlobIIOB3jcLzjW7YES IBLoQXNomHy5kl4tnoRdcRN6PoHufXhQ8kKXEvJhJ4Rg18DH/BeJ91+EixqZLockOwAemlt2aQ7J H5Sh0cJ68mYpy19xIi9rKSTpPYzC2adB8aDPaR/qCL8KSTqoVXDhXoLOCNMbQS3m/jORbH1aYHW4 ZLJHj+R2elQnyq7mpr6Q0HTBqFZzGS4UOhSeXsmvM83Ymi11+bRdqETDezVF6hxwu1CGOjo7gpJf 9Q+56Uy6TpsCQsrLP1Ib+dly2U3iDUBHEuDIJbsUlJIoji8tLZkseVxsILjneeHa41IdTuSU8CA7 PM9dW1iNyPMLWqQtdsXj8TjJvD+ofsvAvfNF9TuMZEXGzPY6Sj3XwmhsOwv0d6Fy9Pk7e/v6JFnh XQZLAuv07gszwfbZdKgQhwg44sguQJXrOaCz3adBjnYSpZsYgXUM9vT79wyGWB/QvBSH91Bf0rhe uLMNIx1ax7BP0sIuH8rZgaHgoKQM7R7skLqG96sqL+OMM+Q56U9QP67BzIonc0uspW9sfDw6MTF2 7AgLjPIo1vpiJEEPpl9jEaQhzT39fhbw94R79vSzzn29vWx/IBiiH5xep0sdDEuD3X51l+TzO/YH JaVrcLdfCqvuYf+mJQuXoCt5VCbpH5CwUE+aquErlA0SvW4tPLhXCu/d2+eWuod2DXdJfs3T6ZKC bsf+PpPe2+KtnAZ6G8i0KD6/VcO3h13u8JA0NNTXtws1o39wSBruCLoHpWGHOrTrqfQoZah8ly3H V2tUTXqd2kBXl+QYHvbvktTOTjUsBVXFPSCpHUPhrq3ye67NdrrCXT7JPdg32CW5B3wd+6X93W6t T3J0drrDgDU6ZTbYyN9z6AU7/D6PtD8c9Lklv4uy/10e165haSC4v+//A3+N+v1voJfNLhXpICHi ebbKWujcVWw28VFrA70Xtheixw0aEXVbvyV6vmG/r1sa9Pn27pfCgwNhVPSaJzwsDQ07+rTN9Jxs TyioPBWLiB4wz+OU9gT6yG8VpwxQdrrcHpNSf1jkKIN7grtDYS/5RIvmclHi1roVRVDwyBpqSVeb Q3FKsoc6e/ImSmJrrkVz2rcQqVHygJJidyou2fF7v+zFeUl/H/84/Y8NyZfVlVCciiq5AV9Ypbl1 cpEHye1Cqn/QRXU/T8vtLrsHWb7dodrNWSrf8XcAxNtRms25u94mG8TygwioDqSGkpsKPXMm91Nn cvPGi4Kg6XBR3MNMVGgvfUTt28LDzSN9CHtUiiJeQ68qqmpAc50k8w0OeDnz/GPRQdTAfzwNpOjh V/7E6FHkMBISMScSsfo0IMM8Vgf26TnWUzKq31u7Vkayvye0z9uLejjU4+NHsVocBJG1ohRydLll zaPZHVRMYVhob6+1a/wUbTsgS8RHzU1ix4jMT8UfUFvtQrmjbSpzTOetJQc8tXB51DqD5mBUF2fo ABrktaFMMgm0lC4hj2p9bjDmE22Y5/d2GiQU82mkiIk7i7eMJ8/KZkjFilMz0wD8oOH6Vyx5v7he XgRexr5P36YXk8wQbmtxUFHYWk80FW4gDhlZkSrDSJKriz+wZCFf4YMTd/hwCg0tgQk2cvxgdKq1 NnuPf5cckna7AWKwfNnhkRULgDI/UGRLrMEZN9FhLSq1HMzeRzAMKHT5OpFPqS7J6+9wmCuoLOUy S3PmODHkKaky1VG0BI+quVVKt3lU254Bj6dGyzRPjUtOdSFB/r0VGRoIhUzvxmRyrT7aYGG4o7Sr qFcciAPw6d7IQbZ/LPp2PY+X7UOmv//O7E2Oj40OTk69aYb+/jBBhNWRwwWalLkAmsyhODSkg8FA l2+PP4D7fUG/BxcGuveE91iPy/XHnRo93hnwhvcF6XE7lsaA2RpzYZkASoWP7hno6e+i2zLSfqjR w6BNFYjtUnDb29/T5w3v4VqiahtgqOA/qHgROSEN6f/pQ8lK6jw1HMytFq6pFsoIWmtbVqjq7Tx0 KC5FkTSPg5LiXCl+RV9w+IeQq2qb0EuM02h3zq4pvD9tVxQK8H3RmcgIFe7Il6eZLzI1FZmKMJmP N9vknXZlsKNTIjuAN0je/m5WxzDkjJ9U5kSUs1I1Ma7P3znUjRzU1T0oaUMe1SENhR1uRVKHtG4/ dQ8mD0ZZz5HI4WgwGhk9zvbLNaYFgcBQH3Q3NKR6zA/8Gc7QORWNvkHvZr/leQr6dHaTfCSOPBQo XW7J7fbQXmfDpKGZ4+PRqYZZzbG7BmUhW9WFgKm6FXozWbEzf3Sadnn2O23yNs13vy+gqPBy6lbn K+UzqdXM2a2Nndrjg7tR6AWomEbNSoVrc1PlYfk7OtwQQ32gYiBp3Mr/rBYAsdYtRjklDxVoqVU6 woKsUwFbLb2ThydZ36RZ+1iBziE5ZTeg2OGmXrQTWKx/RV1HankZK0hYob1VWJqTJ4hmc88LpoLe VyFCp+pySl1dIcoNgRHBN8YmJukPesgmk+JwDRLsWv7kl2jXmlp1mkNCKUmbf0vXU9nkzdRq4Udu 0RuQ09yhDgKsNVXz2IOqk797oPpRMHqHGD+3W3tYdHSQhcAi7C5FE7eQLYtmYGhwwLNvv/W8iQuO EWUkMjJKreuX6S2V+h+bMd+9F6eM+EEc8dJWhr9EAWiOxeonQvkf/xF/TSO+WPuLEnS6Lb5oncZR R6ePRN6hk13mgUt6v43eObNeLKNtqu/4i8q4r9/FEzI9LQ7Y3hBHK6w/KbJindpUR0HUJMHPyTfQ sd7hitXeWKU/kyFexoa4sAYhHDoZx0vvC/mH9L5inL+vdpaOZq3QqxUkKzptYglnsYFymSYqpfnf EuBHRCLHZianxv5DnBsdmRyN8j0n8db1JfFuvJEzj07T6wSr1uvQtVf1Sdxfmm9Fg42GP1ni9e/p CDByiOwpbpWNvmAZ6OCgQ/ipBr+TVBUW0zkemX5jO69r9O9eGifJmgbbVGjLi0I8Jd9iVpG0W1Pb lU09721mFZgyMBU9Mhadim7ul5tYODRE/qTxD/m7xP1QTLkJ8N0bAQlg7+ZTyh5Zs0tu1+9eDXmh ytHo9JvMG/R1hwO+MGXNgLs3ZyaP8v5brYuq1Br9Vs+ZEoEhd/8+FNk+L7+AVCa49QgI705sk8Ly MoRRldLRT9GaUJv+J2/z7JvR42RoxMruPk0a0mRZCnbLHdLQq0P8feB8RZ9DdkZ/kIzS93bG+0T0 8qVxnQ5TcsM1D3BSMsbNk27wP4NSE4Nv8shR/uphVw9KgmNj+NaibmTfkohL8nhc1NJ21m5aYhlU te76CBOHfKq/U1UCnFt6ccYfCO2GP5S/40zzdLZ4MrNIJ9RaaW9pmynlhs2W2k3vTh/Zdqff6fA6 vVt4sVTUMCmCVKx8tbTEkqcA32fKeXFgd+t0ytb5NpP9fc3xfwNQSwMEFAACAAgAtXCFKULQgoup AAAAxQAAABIAAAC5wsH3uvG18L/AvcO18C5UWFQ1js0KgkAYRfeC73CfQCTc9Lju2gSaDo6D43wq afRjCVFERLRwEUToptwESdL63HO4Usw5u1OBME3eomWNIpmxBrwhmXxo72/9k65lFcZUEw9KuDwS rIifoIOkgeqaFzpeUPop8kXyQrwciNE7KKrZJOyUjXw1rN1LfCQBi3PVDX0DtHY2jCGailYKjHqN 1dz7MQO6FjrBDuoRnYMbLNM0oTpkV8f+3/sCUEsDBBQAAgAIAGqI0Co9RA1MNz4AAGa1AAAMAAAA vLrAzr+1yK0udHh0tFvfbxtHkn4XoP+hjQALO0gIy072kkU2huB4L4vLOcE6CZxb7MPhLg8H3FOS u8u++H+hacuWZEkzmhmy53cPyeHQNk1aikL9sC3ZimRakUVbq4RiJNm4qu6eISnv7T0sxSCyONPT 01Vd9dVXVa3XiLKlLhOl7RaM55Qym9gNfzNacCZIMMLuRQvEWKeaXtMXBwdeI2xdbxBK/Tabw0sp vBbUzcmo5kbZa3qemA+MdbdAzHY5k6uKWwtB3S0oW4Q22TqrBi3DIN7tXBDUHcdfGxwYHCAjmZH0 3/3fFZzocmnKUhyH1dRVJROsiFWS3/72fRLNmG0/Td6GNaCIboFuEGfC2nYtMsSvxWKOXMaJRvqw oqsoHExGXn/9dULMBUZBJcpVp5WrkUJdXfSN8oTUY3ki2GMWoc+NKtyyd9RlqV4iPkqmfIUEQdAi tB3NKHdgrGb7myBQdNUtRCsu44J2XrYRtHyDRJNmix0oeyRoB/XyNsE9VtKEzTktI/L2xFPHh945 +ebQO0MnkrcVHisPyLFjx4i6pi7jM/gAefNNQrNUpQrdATlKuzSjbfKpCMxw6oQQ9rXkQwjdztXk DpDXuj9ECKpt0udsiVXCUTEKn3/z7/8MDvzx87MfkCGz/SeQhf5iHpDjrGbZJwiJJXwvqOd32bqf diZSqRQpZ8Kl+Hd/lC2BhfqmvQQ2GywqIZ2E76wulJUihZWCwe6938+lnuJLVTWvwfbBHYNsvGCx 3vdYRTXZPjcf+4W6xteIa6Vh+QpcrxK25Dh4QUtrdlAHN3RD5jqzdBIverdpiz/rgEkMDkQ1uM/W 6QZIZTmURt8LuSwabhI0Sf8O0RdpRpmDf7xGNCOVABNYVM+zCh0hwbZSgfvo2oMDMB0+Bm9iFQAM xR8DAEAtRbPJ7P1RV6yv01xfzqz2kEXEsQpO9KRXY+S9gu2Ao/SOASdX56lCrG3juc9U6q/1aVnx ut7i6/ro47PnPvqCfHJu+OyHhzbSH9WZfD26lX8HdKczbYRVSGCj1q+LvcCHuFL1taDl3QJVhzdy 1aDp7cJItkKMaHDAa7I6ygB6L47T5eyO9z3aMDhm0IQtKmzCRrfRVKoptIJImA14v7JlNKO79gsJ Pak+b87bXAkQVDR/VNXsxisqwItgY3wJFcIXx1ximtmdqBa0+ruYX4vFZMqZVxYC1iGug32wmrHR ax1SOaQ8xZZAmzgyQiBTJpQMjNQbwo0q3oq6moqtTl9krp8h5atsCVySXYMH8SHQOU4DMqvzwUtm I8rEPoIO0+8d+AcudOmea5UmiTbGKvBPr+zcBGpKE0xCboNruRZ4eMFUHnNHiSCCEnYNwr/6GL2f m5Y2zZXBpspX4IYYK0XnjyQagXiTv9oxtIpqoZ32V8p3BL73dc53+ZxuWL4KinlIjkczqpkoLRgJ 6oYBITe5r6BS8s+YpYTZHRAexSQylIMtTSYRG+yaUoKzcT0ODmhjfl65Q4pp5RmZrvXgcN8dcuik gKVh4pXoZHZfiMWmcGvCUToJZuLRyRPHPxoW90+Q44ZvVAvGCW6hCSsYSgFAXQUIQkvWl0G8D4Y/ LUU8tAincWZdy6qGd8DgcahgDgm/KdJkKkJODdlPwfHi9xOYrTt+aavSaIj3EBwO1LnG1sFj6XOX dc1SfsyqwG7Q8oyrxGsVbBKO86tsCVQ+Quw0GKNbAC+T2gXGhWQvgD1R5rpm4oRXnc+psGEAxeg1 xobXtCisY9UwUh0qdiplVM12XoFVxqsH//EaoUKbdItVQMEwz1PHdS3h/3lO1WIiREiHhsBc1rZ2 y7W49XDQdyxW9ep6jS6zihMBmEdzMTnqZ6QaEuyoz5MKHqOkgysS45UJIBkdcd/DCNR9X5tGI+yg EKvzjcTHwIaK19gc3xdHtV/ANsthdrcGSX43dwtpNeAybOkWyUbkDfF5v1/i4euEgIJ4+GvBFYlz vawDBMRbkb2DcDgTB1xw9jIAo72kNzDWAVcDrQRrrALLxcGdb6W/2DuWCd8HB9i6NoF2VdJr2jzp M1EZEkwFCPg2cM6lw1JwS8TIBFhohRREMCB3I7EPEW6q4L2nc78ABLbym0BI9DwMs7xO2sIACKw1 kIVvi/nYuaeawMciBS7hdPwyCVb8NUhoolhXwRVqc11x7+cTTd/HrPENVMUcCUbxC6E/ZVFtHC8e dHg5Mk5UPK79SNxGkJviftDUN8v0EOfEb9pzYBKWWNhDxC8cy3GAbqAlW8qB8oSOpGJ5Ic8wcBgC JNpB4JW43H1dtWBBdsNuIR0k/+d2cyh/C/yzBZsLO79GJ3HvAQfBM5mLi1a2wAMjzm5I9JBdM5pI 4PhUBRNhkWOdBW6JQQCCBNp4nDslQwEgpzgvimZQD6CfMO8/xXzrBV+DcRUfBIBgDX/nrzz6s17j ZIQYMwCTE7AcZQuxg8jZaE4Cgp4X1CN+OoFur5mdllugj4O3Ktfh7cp1ewfiO3ukrvJlIxh1nsVH 8KXwiGOpqyqFFxkbMNBnfEHy3eVn1l23ECqHX4234cV4G0GNm7E6nqv6LfEF7kmrjpM3mEyzla1k BuWJ8518NegInv2uvHv4LY4jBZQrNXIgnONwceKRxw3DqGnPIXSGRFEwvHEfTaVO9Gq4S0cK/ANw h6bAYRs4QBqykkKdIm9WbiY7ArYhvP8ApLCJVzfHZRTsXac2L9cpX2A3lD3k2WgvXRmMNn9YhTh2 R2+Ud2F5VBESyJlh5fB6XEUxo1JWNbYACuwG6DDNH/Xv9MwEjloReIPVCIjNmPMnq5RigGvAO9At o5pb0PPWXUAnJDZYHzl2jAjY+T6x0X4BdeK7gsxj+hq0/CClacAZwbQPOzER/uCP5qaQhBBvR3WQ qgJ8h2gC3jQaKobfaAYG2MI/vhcQGU8BsdP+0fmOc9RspC9CjoI8Tlo2imfNunVIDSws3JH+Cir4 vN/+K1EVUpA0NxWOPsDOQAmcGFgKbLilBC9hnXF0Msddh7hR9CSqGaCJlNhsgARlNJFUjARxoxnp J+YSJIKxxWQxzdbGlDQ8p66WqRXAu6R79+BKFxHhmpmJSzN9M4NEPSI1QVbp33DZK9uv3vFH/aZI qoUYCPWgHWTMfEM5C0alIU3WJngJCHTp3yisHrIDNCIMAmB17JoM/omJo74AMPRN/T4Ygqg/9FvY UyJjce6ZD5QnhIawhuPl8eKjTqjFb0nEArqwg7nBRnD5+JkTIJNll4uEMrvBi83msrL1BsAE7CkO gVhn+LlHCGroRzAjJvO0QYL5uMSH8EEs08EMgufAzqzqYHac8UpIXzGZY6vRTyKgb5mTsiLAsRom TNAFiQxGNQSZYD6uKRg+kK4qJn8QctKuD2sMR/FZnijgNyu0pMJhNravLnTDTP9sK9G3yAZyVToZ 0lfqNYLDdjEt/ymd1MayO8R84j9Vl2OxaIuGaBkFjwlVxDEonA9H9bugDrl7QRArWiTLgMJZ9QHJ al4zeCHr2P2WUKQmrsWulSYhXh2yJ58R7ZY5nhBP2EGUDdZO7aRMxlN6RFGs3VhTYZ7ts0owy83P tXKqnMswVMo3H2g/i4sC04yoEXgR76bgJO4dGWni+gkPKlgO3KSU+yulRiOusvNMutpNRohIKgHo b+d3e0MrRAuNuQD+gnOLys2Yn5e4FldlREjEKI6lNyQInLALotqZC2vjYPrTbWWLlzsuXuyktJUk PCeKHFVXhdwcdBM23xvHT5W2yG/AevRlXBcpbbEowBAdeN6u30aA7+J23rOglSR48s3ibWin09eB j5gV1YRfINwVAQlqbmjdNTbiOH1UAbrLuE73sxTVO7VI1Fhl+ifrIP8j8VZyDf8pGFQM1jImVmRK 1VNsSJX+Yh7E2N7vhYlM6PS///lfvyZff/ltD2qwmn6fFFb9G0EbLRTLMthKIB1Mg4XfyN0svES8 wCYD5oIi4YArNPSfvvpAaQo4H9qXn+4ImyQkEmMsyBKDOsBKLuh9mwEgvURz0i3hbTLh4sPVvekX PaPRM9bOnDnDbTeYRaInauxAB8wX3YtOsEwwdIgNCOpPsLWJbiFKvP3XvsjovGdOC/JyUMJBb62S X/Jl6gYhJiLZaySosyha8FaIIlguCJej4P75Z+U9TKmf04xeU5tnxBQq5SXg8j6gkFKRwM9nhXQF aMVPuXSsk//nwxuq8EE4gjVpss7m5X4JViAz0MbiAKL/jFBKHI1ukegWGLnXDmbP/I0Zrap1F/9P wogNSOm383scc+EtadgqZ5atK+limuMgo9m1v7XGWEJAIO0hR3Fz3PtFFrdBSWwfAx/WDkFt0U8i Le7/9grSb9n6TbYPIGo3Em7GE5KbPQkJGD0W8LF9PwI0BAzCDQt2VEMbxBxF5NgYy7b99TDg4tkv Bwf8Fs/MejJdIMGV4hKSJSvJIDHn4xkuDpAsGPM6bh/dtdXBgdyU9WMwCmiNw8BKvH3jMm8YQkJu bVvbtIFzBJlpxquzfJYEmjEzTjQN391wcKArERbPKqG+CVzv4kV4iXcVFFATawIsQJ1gvGjm/WCR 2dygRdwBU4BHzcp0e3AAf2JPcwQ7mjijM5HjPLmFxDFZY3m6PBItxIsThA655DgYgewNh3YuA2Ri cMDWi7xvhzDBI556D7utmkjEysZtflNAjcyRE0oUzEPYW7S/A0aJpT7wpnB+cABvQsQrT0gC6qjI IDpdAp579p11iwzsf776j2++/Aq7/QK8Ookw71VBopPbBzdWDkCLXbFGlkh0Rtg9JS2qniw2KwGO bV5dUdJqEzIV9R7PSnm913ip7GGXVpTMufY8szNrUi1SHqkmGKbxEvPXSmijBWK9pgLI1f0mhAOh 7iAAJp8EFnUkv5fAdb999t1+k4C42X2yn6X6rnkF6WcH2R2/afjlbuLvtNxbdIuXXGvwxdzgpgw7 elN4utfM2gCB9Lk3i86KpStwNp4XJbmPfwuzokXzJbgKgA1/BQcc9EnIIYC3Xep8vO+OQEJB+svj ynVR5Hw/Do9/1MfROLUpYt6TBz8Ka+Jk0i1t7NKfiF9jB+Ts71QLnMBvKvf9ZyC9OQ7Gpq7qm4Ay nH3IOoj4GOs50wUonkMCEPrPEE6oKHJCnpwkD+tuhG/EIyVY4bdTXa0ltFvRAoORAFsCJUh8KaYT qf5T2NP9p7DxzILBnv+vr77+klz48t+++vKb//wzuTD8xTD58Pdnh/9p+NDhHBmr2BSVRYylmB5A 7u3dBgQUV2XOg7UKfugkznJ8WeXpPCe7/FUlbdkIEkRdCFb8tGBAQFSxN1+8pm8mLW5iVOkWthWT fkc8peMADWUVUQHrP4acFqTa0aKWv8VLUpLWJRbSdYsfawFGd5cUJ3NanKV2ijhowdpmYTU5qwW8 ZQHMTtnznovG0vfxI/0WQ7DT6ZvmY2LezbeBLBbHySGGCvFAY1V5qklJA2uhHjLWdeyE8kMRqWA3 uBy3CNmSG8KqebP9Dj7TLaqhPMGAM421cYAY60CecIIEdYwk553AId0oGOFti7gzC3PZyTyCzsIi 9B90huUNDPaYX4DJGVuRoCn915Yke1WrSk69qiXM5bGnTvwc2h8oS8dCn70T5uH3RGbzrtfU6rGk qFNkZgRZQlLVw6FgNYU538Ba2KQniCx+x9OAPecNbwdXSHYqC8ZOimmaRR4y1+mxIGGSl42NwgoW eyRb7NJ91w5J1mMshZtOC0dRVj2KIHz6nSOKlSK4i2wTAiLkMHZDiSR0JTmX7GJHM2wfTEZ9jAcN WlhH5izHN61t1bJMkt+l00iOS2zP8zrNldJl2MIxbHo9jbffrcL+eE11D4ySLvMajbpI3IxwAEQ/ +UrzQTTPi5iSLkMozgCQFfHUHhDIXzotcx5xyhn4oc6DFZWnZTSCXZ1idXidsVxMc5MSCTZfNK51 yfNkpaffIeItwXD6W0BJJhc05/TJoK6tkrdPmhXtISc9RN+EZPPQydC3TwLTiQgWB9/gbdHSLhYC gdBE2Bbc9nz45dtvxfnJjW5OxI8/8t7zOh4zPplMyakTP++q/6Dc72mG+gxTBn4PsSZOLpbj+2BI 6/lNnsFCsnczmZI3ivHI8pbskB1F6ektwZ6OK2m3eAKABMvQyD9gxVwzXVjBLLtFaGA3SrMlh/8i +04V5PQ3ZLjsOlp76HTz0G+GwE45/VEX7J1jRyGNIDiffniODJ8f/ogMf/D5ufOffvaHc+TCZ//y Bfz45NwfyIWPPvu0q6PWOcHBczlbJMtYGeCHUyRjMCvFDMFOE4kW9M2udi3/iNCLEBu1xIFj0F58 MpMDZsZY561Si2JViufAvVMktejiTdcqFYwIUBybEsp1Iwss5eJF3prrjIc8C4sADAIKePG0D0ly O+5LYQblZ+AZH5vYSluenILktwLz6Q3Kr4A4PTOqi3goh0+Ls0Jkxiy3vI/5a6BanbKA2c67SIRz BDJWDFdc4F+/Gx2gUEfi3oJelor0UXbHW9B/dh3yKxKumRU62dlKx+GRj/u+GErEWNCfGIsHHuJj fcEKnlM5EHQAARS4B0cAr57MGFyJHiqXMcP5ATJSQUnAAPz7YMQj7B6reHvBLGACgkI4z+Zwg++6 UVQDVBZvhA3FpXQWmd3B5JeGNFrRF2ETnFlzEgu7pjiAdjTqE4zz58qdOTJWvfVsjI6VSJeQsM28 6tB9pCaVinn3ujMrfxVZH7+TMsfpdbWJUIbtD69BOwwLKVgI+hLdeA6lGP/S3FztHWyoxL2MI5FW EFNzJbhSqHtlZ68j6j//apgUVpEzcRmimvcIMC37M9aJsJWyqNeUm8TadgPURcWs8DMylslPE2Kw F/1XzD7iM18yLgBTMB/zAh19WJq0Jrml0BwvHiID3cXQYU3y0jbbU1fBPb/5b445xTTQsiaeBasL WMGYzc+ziyMraZ5RfvstmA0vw9XiIoi+WZ7A2I0pgLfiaMTWi2nZGjgq1QoWe2H48+F/PEc+Gb5w 4fcfn4/xA3tasabl4Q22YpTRpC7J5Nn3DXsHvBHYhmZEYDzeLTwsg4WcTv8z+XuCS0fSbHmLs8e+ aieZWhDIhVEAp4rWU80FiwPxTYWXwM6cOYNEAvi+9gCrZbzWnlUMEyCcVXKqPGhrKiIytIMsz5WT CXO6CDGVYAR9r+QWvJIaxXSRlKd1/IMOMUmK/50P//sReaHvfpf8TYBgeGeHLwyf//jzYbncKMju Y8WElxVFvwGkcVW++4AS8r5yExKZuNkvH1UpHg2FmOlgy5m90DdJuVim5PzHly5dOhoR/pe2a+uJ 40zT95HyHz5uNlgiyGAnPmi1luOxN94kk5WdHXk0mgs0IQlajxlhMsrc5L+0wXZsBqiiqrqrqrvr 0KdqE4yxiSEQH7GB2ASC4zEQDtG+h68ODd67bo0yMt1V1e93eo/P8xb7kcXRyrD6AHY0BVdNRC0D n3BNWYDjpjyuBAlIxrThOlX41lkkwlb7fntCy8LgDsA/ROEymQBvuIxVXKNCybN4Y4wRW42IWlVl He5+F27CeyIdHAdXcKpZVSeK9K0MKZRkMgk+bsTBfwfdxIY8mD224lS+HJtmDJA/6O7p7Ngn3n6b BpgYc0OkYP+CoCL/JiobIEM+wLwMS9EALfQOm+TDVEzkxaWcQCtWuffFJato/YlWcE3ZpiwLoTfp UrqT/iScJfGNUvWO4CKh2bKiPmMUSXNbey4nKSL7wuxrLPWfKBPjPCwto7Us/IzZB72Q0yQGHEwt EQtDYmO02eMfQPSMtBAhjC+qxUJQZ90XIBd9O7kvLpYj/LycL5KiCQJr20JEBIKXa9EYoq09+5M3 htWYCUoKIw+AIi2qv93EiM6C/9PBQfS1GKosQhANKiWurkoBg7nsS/idGaqi/bnuCYp3DsWUuO2c 1tx2EGafRdm3O/dNQ9KG1RVhZtUVMAd0sWTK0brIQgzCYYM7hIBr3WW+wd1RMR0xlv0BcwMhEAR/ SOYT1O/tF+Q6UXqpKtgvjp5Ts/5gf6wJuhjze+hNR5ibkE4Tg4MaMHmHJRo+/codRa8OU3H/jsfq PxKV5ViCcCLxjIFhQrOUQ3/LmAcr/h3uDJugc5iKNN1r/pS52JLcglRtJFRbAj1Q7zGxw6Fa2eci Ug7t4ajCEbTnp0CYtv1kPq37Eh0B4nKa+7bwU7IQ7ExhuiMcRY4AmEJbljnT9MvcYIss/YAZIyhB gdK+yepgCFJFeJ3xTLsEERoWX8EUwlYCHbCCD8SbcD5bdjuMi9aYN0X7rBmdwX11n7J32UmhmTJX vbzI/pwDJyRwKtqSqEnEo2qFIBG/56+J4aHO+JcKW65BOThnw8vXu0D7LrsgxjyEihhX2s8TzgYs tIRpwKmxlMwEeX8UgybQMuHmewCbrzBpb/sbsGGxLBphqKMn0g4Ii/NkZERl/dy56GjKGiDpboRG 5MvqnMz0IOn4EXksoJjffMMw4Eczqj5dNr1JjPAEPw9ZcwisRTwdL2+YGguLQMiZuQWKSn8lL6hv 3SWcV850mavGN+IgedVXxFGSEHPWRmELPuW/E8l0ZTuxv+su0YFYogOvleiA/Fv8fyK1hppLqpi6 i3gwFrH9tSK2hyK+HcmI+ICQbC9POsQ+6nT6lWqaPxj8uSzyIAglL/Wvdl14+ZxNw4EPnUr0RITA CJuBX/miMsvYXIqfwLfOPBaIaKkwfZUQARDC3wbXSrkP1qZSlfwUeEaczrwJmi5KdNQZzv8uO3c0 LdYATFnid1N5FzMNQ1ToitgsyJSGsxuebXlwJPAaD5XgU8XVKnVBteMdwZDLmmngxhMp4RbTL91C goueiCvqOV7pFw6bQ6XZ5rMfibxdmchV9yV6P9T39w5FfijNb1SakVXdEFt6ALPyqKewOGxbNOHS hxGF54XnkjghjFl/B+ySo2ur1ASCsQxPzaHsIjpREuJCTBn0mooyZcywWhs9m/GyxaAmAlCJbCa4 5d9BaGF52huzl3FjooaUQKy8qNcKhBNyOMp7d134rLPnQrdopkAiJi5MYkJuVBal0tPpaRiEE5hp zmLdhNOk9HGxeUu486aPBdKl4JZ7LSR7B7dpZ775BkE04W7MsxLnJjMsgXQ0IeA93RP9bn+mhkJP tULhTKiBN4bV9pyaGYJnFA1EvXGObZZzbPKx2rSgIg0+mZ5r3M4M58dBHrU//coLKCHGT6d0GIQS 3DojZT578w3QA4abL8IgvvoKBudMaeMIStpQ7kuZYHfgD2HB5ztSG0q51EecLEzl3iSAp9+fLzuI bVXnYPHuYkeZn5HxJeL8HKiqVGFdmL9m7oKnhBgZEKauK3ukbrXOsG+ApF2s+fdxS2z4aVWLjpCI PoAlwKK0pJlQATIIbwou+/1R9ZmBb3Gcyix4iJ846ZQPMgWMvp45K5pWv/xEOBh2lnIreIqJzi6a SXaJ0SUFq875Jpor+l7ZFJURcyQuBtKWA2/F1rOLSoh2DUl/fA+VcZWU4xTHsB4HQ1E44sGZGTWv hlo1fKQz4oHiH8LyrO4JCWZU52gL2SZRRLGNB/jFxGqEXRdwgtcsmyYBraSFLV4KH6k9iqhv9KAx 8JiLObgltw6TXOwX+KRE3d5AOL9hodgiuO5iYllkQf3DjVF9MaB8s1CfmpNUGpG38oFA4rstBJlj bwceBodig71E9x4Ih1cqg0ikgqdGZWe4dlPLGgF3rgkW0qo3Zi7SuaK0L+lmmpeCzGiA9KShU6BU si+JU10cdX+tb6sMdv38KYj4YG/3K4N5Twgrq6TMPkyZIy46i85FtbwU7l+Tekep960F4XxrLCea CGC0skaMOaZHkLeKz6Z0QHYWrXZ9xWc/0U/nVD9Tuo+8llq8kLddHURGh9AfZHyqx+BVXMx6rs7J 7cnmkekWZB6ZIxiXz7hPlowGKO2GwMp6D+agZACymqEYzN+pb4OPQ+x/nensOC8+7D7f1dtRA+EQ 1PgBiaWUD0EgxUNtTpJKY92hvYi6bfH8ECcXFplbp8HmwYOcD/IeFrwiLnCdh8KuVfmpX9Aegast EXOUKB+juC828YoX2ErIk7MUJUB02/fZ55YCseFYkuDHwRgmucbqFzWEErNzZi0om9UScr40EPvs R5aSSGb7V8wXoMz0JSynTqgaU8+uw6QTDEySV5kfLrRBArsw+jomdy4Fl8FVufhXGGmIAax3q4tD 0q3q6L0YIkhgmk1QwPPWEBhDrACDP3mNtOgvI1sIAa2JriOOJWoK2woDbWXDHkegmZklbiA3yiA0 flhh/9H9SS/ENpXhP0Y/YnZCL5L9rhiaXW+n/tCRmoMapbbgb0EnlwKWG6KUKc3qrzKLwl/HFjkQ 0Mkp0ZZE6P03NYmzJ89ibX5GnwF/LF1VlCjZOxa2OyPYFSZZuIo15I0zvQHNw2DxYd3A8GFrof1x FFG+WVbKfmTG4o8klgMxW2FpVX5DxM+MqqyH1ex6+jWH2a+BI81oklqFjzE1NRVKz4Bggxw+h/jZ R0qfKC+Vl2SQkt5qPrC/OGrdx8D4npmGIDu36e9Q7kVB6sU+omWaabBnB/brS5ghJEUY9q+qydmg 63tDVPvUufwNJEo8NFxKrVOkWtcJYJPtzRaXwAJLuOTbNHIKd5ux+k1E2mfgzNX1l9naOpXSDTPt jOziYHPPNrlVZQ+C9Bb4iUpZNv+gKJFRf+jRmbChU3ge6ujCHz4Y5xckd3QXoJTcS2ZOEl5aVEsI u4WQVTpe8j7Zt6ZuBaNQQDbAp86cPP7BWfHxKfH744jCajYs9582ok3ROu2jsmrxtjgA4WHSjAnX y48qGp76TIHAaBDdDWNuIwM+8xpl3ll8dTr9MggwxX4FApHA2VSWW5RLcAQuZdcorEQ2LCH4kKcY POS8UVxhb+E/JInRFugIlycEWSKKfihWhcP+m4lQOKdqm+UCocM4xZpN38EiUfYr5ACI6rjjEccb u6ktC/0ekueJM50upahfVehh5Isl17wLT1QumS8o7M3hgvlPZPsGjAfg42OEXS5qGQ2xtLcgIDUM auJ4x/kWfrfaZ83Sl+UBoa22BJsWmEd9FkFeqUwqrdJ36oKzgoReMJhgKjBoO4eUnMuUUoO7xDni 8aBzKawB9ye6yUqX15D4s9pyDiLfccRwh9diuxeFhGwxVowVgSkC0DjUV5JyCDax/bCeVqWtV7e6 R7i32COi5h8Yl2lxp6gcImg9TOXIb0HPpYT1RMfeikjrB0HlCiRuxyDqjgKDfqAXSMXNmavaEmyf 7zxbpqitgaLOfdUu4RXyGchHMy4nH4UTeUmd4b66/dlF6nXCT40wQ8aqsQUBhPKCN1fhMuZGiCYt 4Jxqj3JDhr6kZdxjyCK5geFQv7tCmv2lmpM9S2kfZ3/G/QPhIpxifSl7VRS2ebtp15H5ILvDgLVF ATEMvJu/QQkd6WSE7tUydSuYN1WYK1jt+fRLb8xC4t5Ilah26rSyTph9s4/+1//WW29xHwBRmGyl jKbIXs1eBZO9HvjgquYD/I+NdmudXbLD7F06DyHkxUyvOanfgsWvDvgbygLl87xbXtxnaqo6YG9h 9y1sLGZlfxDmC+UGcRVDSiTmoqb8dew0A/NL59gdhaWCY33X2xQ6soHSP0o61AicAnySl+nDitUT j9AYeVKsInhgG7JxJ9Ibqn3Vwcy4u4Kl6ODNN1ysf+ZtYwl+Sb/mrlGwjm074JbKPaFt5uYQGMdb hcFlrGT8fmcafgf7YwlnEY4fFh+/w4as4VYUuRzBj+W6+mnOQ4lEczFa4n+hxZ4lMl2+6r/COiBH gqQhQUTWPLbpr8El2ZTSpywXH2KdsDqgL1oD+K/8DX/NWUHU0bdl0xwilYFn/XKubM2GO52ImkqZ NHBx1J9SvpX1d+MyXjsFOmZSncO5xoTFv9S58Da4HnNLMMVhdyQCz9iKdl12K6jrXpLNJe0Je8J3 cmvu01KYb3Eq9jaeVeQgGlsmsr3MLCI2jwpsmbRmpon2JTRdBQPfiheOYbeUp3yN6xFDAq9TUvKR mq7PoGlAmuMGI/hE6TFoavCcd5xqKzlapumn6gfdCMd5pL58ibCN5n7ZcEydE5Qj0yDEgdV15xPg KMqXezvYL0+YZUoFIq5SaOOweahB+IYoTimY6T3+Bwx7Qrb4OD24iCfK30HTi/kmCJXscUxsYSh7 m7NRxSzsE8ljwMQsajYuMWG8hIzhHX+K2uPS1/hBP1nzYBRcCmYmIbGC8vfmovA2kWSBGrZVNjfB xOdddYHsat5F62lgdngNFl4+FK44B5YyN0lPq5SUZThSlAJTHhMrkDPNYzkbzKM1oI1SgkGKIxPX lAfMJjpgjKDBCPN9WUGoA6MakhAgAMP7KTUOQtpCgZN7h4PIedPPTtYT5ReuuOwgM2w/x/qe2JVV YVyIMR5dQAUXDo4oXCUcQvilhD2imWyApBw+nDiFMcOq8c1rJcXIjtMpJ07hRV4g3cqmuqMOjnBQ 8YfTJ07uKswEQ958WAkED+MqxMcr5LegwhPGOM1ZyQ2K6DX/qCzA+uoP7K3wFutJA4Tl8OLsx2c+ PnP6kz9C6H5OfHD6k09O/v6saN8lfiSyew18kLBFCXYtBytkZtzUO/vda1TI4QsoKaldL+awnUgO 21bUZlbFLoh4/QfHocl//c/pE38UJ94/efLMhyeP/+7kmbM1A+Nm6OKoKKWcFXNIfwX6yH9OPrNs rAXiq/1NcYaHmkvDEm06K7IM1Ajh2fdtbxNBMWOBH/MA6727l4QFVJYxLYCmVC/fxO0dxUFIOq4O 0yyPi+qg+awJR0NuqG3Wog6x2zX5KcY3xOSEZdVnUB+uCEqbgoPKGrSyUiwxbqoRwz4UkdgFU8x3 nWdJXpc7C4sKcdBHHm/ES5cZOFhgfcYcAtUKMczuHUiI+uoVCOut37CxQKCxskiw20MoYaJbQ/1H ze6JvxbcKqYxlkWvo3bg1UXjGezOgryIpKz+Iss5HKW0tjqV0lWYCghLqBL7m2djsQIuqFlqaTOj Xh7OiD5jLO2lmgpkf2Fck/KuotV6CGtiru7Bq3om3Fpcssbq3sDiCHsz73d/ebFTfND5t7919uw2 RLJGz+4ChQHeuP4TtpK8rGDLCGoDL1sKY5vzJnlY6m+H2vazk6SaqmmNyVRSjIkIeUtSQUZNnlSN aKUQqphYPWO+CmXKpdXM7lSVr5FV0SxzUQhU1a5HSdrqPk7eYY0b07GsFK5jGIyvTEBMPcQahUTz dmq/rH+nbDbg/Lbtb0u0B/iw+++d4vhnn3V07Vk4LMaSmuHEp2zInxnGyJgJ/hgPcPtoW3cRPG8Y hQ064wlqHF1pW7RrqUGFctmpUMsG2ejfsOwsqIHs8/QC/GL1l4gEBI/fpQCdCcPwtpqIWI2IT5w+ DB2dKoafynL+JnXmQapQU30pCfHssTNz+tPu8+Jsb0ePeK/zYq848UV310Vxes8URhZJv1dZ5upa E3ZbSZmT1NyGIM0hcalhIh9IUKkxpnxhTeyRtDo4skZZ6kRzsyZhXcGq+iPDlV2CqJkD94RpbeVF b2091ii52fWp3iiWsM6zR2SEx4CkhBLeiIenP/Em+fxQvG2tQQR9kzIEMiksj3D8IC/A3A5icOhq 7NuEvbaKD5FUrjzGY9iwtXlHJri9sdIAaAhs9BhmuY/uUU6y3U/o5+XYyIRuTvhujFZRfqpdwmoq vjXA15e0kYaJzz7QyZ7u3q6/sDI529vd84/XHARvFiNKkKgdbWHeLgeSftUo0dhPea/jL/8rftfd 3SN6u8WZLy9e7OrYDceCKAhJW8J5mRkv3aBeDeNExw2/QHVDPkxctW3YhLKfcba3p+PC52BMO3pF 7xed8Sh2ix65/Bi61O6GAByuprA5UKL/FXbqk5y+Rg2CvIIT57u//PTInslmhC3lyGR0Eo0B3V/V JJRLZbiQ4ipao4Tkd3R81HW+U7zf9fkX4pMverrOn794VFlWNqRhz4Pa2SO//SJ4hGm7mqn+KfD1 6SaEWl5zVozVPGwXcG7UOW++ReQL1oC7QV3bG7Vr2pIm/ZOOrvN7pCbjLV2WWG5liIwTZgG4vULD BKx9T8VeQ9l2tC35lgp0gwgC6eXLSP8NJeQt0TAp47dcPXqFL7TbIyapX8xdS+4O+ENYV0DePTV2 0Z84dzwnZCH/5q5hHxlY+GPHBPKzGyX3QUmU9PLpVzCLmb1yIw7bW7Tuyrp5E2rhNhoCzjo3uhX5 cWpFaE94V6kdSUJ9Ry2rW+lFBNjQh/kNnr0dvZ+IsiTHjoEpvUXvpiAYVKKnwbRyg7qbGy65GGzZ nXrHqbVTw/Y1zCpbV8rFPZOjLwUTpQy+vAlObG4dNiAff9yEpDoxLRYbVw5PGrYH2aJq1ykIwZk6 +tE/xHtgYL/o7HnrovjPrp7zr3UzRWVZkJONGpRY7PJdcuQs1yCOWqkLDTamuqRcqom240cWrcqy hB4iQIj0BmbZIZgLhDpT6su+hAM6Rq/R4W5/4U9/W98AvHZ22Kj7/X5aX3rt6WwR8j10UccAp6os OHpYyKmZBlxIhtU1bgOyQSfX6NT5L7s+fb1OSWYeI6BJu6wZhl3ZglgPUmnLupJoUypwzb0p1j4N 250c7xf1ShUisfk/wXIbCOCsmn9+XfgIvpMwtsCyM2IXp9+QY6Na2bsELTNXnYr2CsK4Y8cY6H47 YbcGCdFnbUawXm0FuyfKPVfvvGTNYGVPfBnU73n7w4HKcnTemuR5wW7ii4aF/V85jpIujjJG2PXc eqYoqQq7jpu+Yw8SypnyzPJFHZFBJG7DoDde7MemhiZcE710pP1oe6OGz04FNvDftbYS5iJ75Bhl dS4zjuDjlNJHbE5ebdi4eC+/jg+HNW+sOisxGxXMa3kaX5gnk3hsgiAuoE4mhutuNGoXy9b0/93T 9feO3k4K4y/CEIczelKnVvVb1lreDrbzpWidW8PXfQRCNqnapVhhwX5oSYSoaxBMzIvge3sYS1UU YOBbxuiBGGk0bIjsyhy/0HEeHPGuv3Z8Jdr3OIXUhPu2ZK3FHncrdouPTUkF816t/A4FSY/KDfI/ E+c0JV/sQZ2RuMeupPc0aoTs9Jz48kKvONnR29t14XOIkD4XzbClnnrj0TCx0Qd649KOYw+geKTc ByTZy52xSP5DKoTm1vzvGzcAdk3e7+z4VJzq6rnYu2d9ZE4GxQ5fHbKBvfbBh3rW2ji55Bs8GWjV 3O7N79uNcRfWQPZH/4qoIEGBWy0jWRDh2DvZncZGyNypW9U8BdHee6xOuHURhNYUukAc+/ILR83s YpNoi5yb6ovgNqWnzWeOnkgJhb5CEzhJvoNvmEA3d8xFKKe1YO3IBi+NGuThCA7rXgu2rc34Xar4 8pN80RzyV9oTysqoDko1xQPPLloDiB3KF/Wl9NUQhCPfmzKTeYY3YGPLBxB8l3fZIrLFhkVq2Czj JUL7Vepnfr3EPUQDh7xjfJT6NOQaJfwafAmBUwl8odDLKL7+OpKK9KaUBuKmsna9ReTuIkSGANXk kNXKlGjE3agpPyIrPK7vBdY/88XMrT0H0r2m2hDXayMqMXG2vZ851iEfLpduogsq6xnsAocX8TgJ RKCa2CUntgvKN0aVH4Q0pOIo3kmXS5J38H+1XW1vE1cW/r7S/oebb3TXRa0DbVWpqiiwq11pW9Ts 21dUIjUSkFUS1N2/sf8gvG1DSxjHdjwzHntm4tjjssFAyvIOqSiQQhq2FEi8IaC9zznnjsd2KvUD k6oSie3x3Dv3nntenvM8i9akf1eHjbXcLWIiZM13r46JTGkKhPdar67Z4vPcI3s2zkUmDL3eDUqk 2Kj3wnAbCRG7a+FFkiPl/k792Lmm0q2bZcR6bghQqvyEGhCSV76q8itc20vrmRtC7vP5lfB4Ybl/ sO3yckwiCLKKajPYtEH6rwMKAR4iGyDHYvg4d6cwR/F1WjcseRTsk96bHczPEMNFeRle6M3ZZ1J1 8wGwDC6hwfMilCVY6ZNjS/IsEcPru08G6gqiydRH0+lxcF5aN8k0yD4FHQz2P/qdKbOQ6sClPb+z JNXP+unPoOs1x22wtTzhk2KMj1etnwvXtddpQsWY4VXoYKNIv73bLDUfMsX4WTKWc89yd8gIgiEp JnvEAtabQB/adnw7BERLZ6IEL/LZyKFDcIn2jY725wtQRWfXlIE3m840zYOzORi0iOAMXT9Vn9rX jMDjbFChx58MzqxjUsU3VVt/UsXKDYZ1dEC9cqbZxHjZi/rzyNjEEe3rDkEXp8dqg+qXNAzRi0VW xlmr/Vh9ND6MNk/etJIV40Gkm2UUru6hkXGIPgwd3v/Jp9ktThodHkucBdZRzj6ldkucVtk3fHh4 Ymz/xOhY/w0FC1ZdyPBjl0/vekk3qPo5ZyF/RS/tc1k9p40LpTPFHyAyS07DlpgO/6l1k1nEBowI Gy6Ipi29+hqryg1dmwRV0ho0+1gfjB74hw4Fh8ePjA33R0gzwb3meveyUNF/dZT6JfP+ac8qazgj KP4BhqWr7SyuwAgBEYF95Ep2I7wcvoDvqdxryN4ANnncWi3cLs35k0mX7FS8FYsPuKvrbnrlBOHe HtL24+CwZBx7JkYogkSTrZXofTMlJyIbks1FDvNCnCbfLgT/ady7MFvXKzk7eA5B0/4kfpbid9w6 tKCXRaqUQPilsHCNlCxx6F0lfuDYK+0yfXJOhi9fPU9sYizSeIZJ1h78vfB431jktdzV+UlQMNwm ABK5TKzwh2Z8YsimnGEv3CC5RBnkfg918MI1uOTGwSFwdGA3bw+Y/hK5KNgg0AiU2vCznZ5AYA26 BMATU8DYE3/O+JVlZVfJzIeQwkV3e6PtLNEy1Sbf+koNDGg/031YcfUgEksa7UlFlb8IRgFU05/r L2xjpw0gl4mvgZI04emrDd8RYELXsmCsqAoC7b6mGq0IuTbAVcqebqzXz22Vf+VXLHMmgzSD3Wwv 70yHs+XlcImUwURXGtHYf3pELegys8UfRGHK0FujpSBcjJGlxzAj4Lf2J4lfAdfuKiB1UHppTQj7 PcWWydduWb+zjqK/wT4hNoAqeZ497Tryqe2d3Ff+VGGGmbaKJzJIGARusmSUL+nxZoUVBfY/Q590 lfOtfoHp1bX1eyBpJr58MVkOS3SEwAl3WLIxtQWzUxj39MLtA9J8V16uVGjMJLjjnNaPmpQtJD6j 3FnN0395PzW8hjBFF33rPtXbtkD7tGyb9Llcu0PmLkoOpijZ0X1nlE9q00ke0+5df1G/37Vv14f9 wVh8xrAyE9qdcMdop+icNDLtzmm0nq8609iCyZ1HeN/k0SrQyLQGxR7R3Drgi3Xbf0R5vxuNqMuq 5G44a+EZphIxMl/w3IzC4yPSSrBWqfFOj5CkQTtStKRGi+4bvRmQz9Bv6uiFpva42KNxFry8tzj7 tL8GxzVCOfEEVQvort4N1YLenqxBJNp2XDaU9tBisSu2vC6KxKkMQ0idgzPNx7NPZ5/2LbpE2p6y 8Nz1GLYJm+BsBAuUpyPEZnNauzkXGVtvJbN2bcEvpDUE9mnmv5t9mv/mJ7O3GAFJIpL1aYHvCwiG WMdCL0MHPcKAtWjHoMNSLe4dH3Tks8XVtKatrYo/5T4mBsyYLT6tcWbFnDkW58eUHnhvjUkPap0y B8JcG6Jw3VOwgL0rB8/Bbommzmqz484lQFVOl1icXc5Y+YxveYscjugPVGracQOMg+vzqQ2b/ZKh vXv+tHuv+sPegb7IwblWuEddzoJ6ztZeitcUw5KG9v4Vy9e+Hrb14xP1D1oACRuCqYIDLiIh27l4 eJcc4EHAmvgMn9LXnFamLp7asHfEzVh8E7yyCfYrrDrJWJo8WloVNPDoPIAU6B6hFFEMIVLhkn8X UXQ3LLfbq2JhnKK0dxvHLD0TtLPvjMADfhfnAuR+kzkMJ9iEsg8qMJ33J4XQVPkZdeVyhw81KlW/ cTZBXtdbILfnqFxTuOl97dyS7RGt15+RncNaAIMyN+N9TocU+1930swgCAX3B/sPHkSqrW+lLxBv mN55j8M1EqSgnjE7aX3UYKLBWKh23MXSGVAUxkv9SnnZWYKEhV38XvzJ2O9G0R24w/Xa+vwX8CyK pRahKHpyddWGflNTaDllS8Xbhxym/CRzwm3vOhumuzLDKHorOs3fLP0vd9uoHLBMYqJ+mtqMvx23 4VQiMZC9Z0h+Ru85z3VOIiQ0MUubmkTxKXSsau+LlNXFvuJkpEOxLyKmkkZCHyqtYbHjte+jjz8c +uOuj/vzta79g5cjHbe4UM2uYIJOVCI0sOGd1WGpPjz1iKS9tuN5VRvJjikICoVhYBPlL+AnoEun 1RCvDRQAxMCmNXp2zip1/dTy32wZt3leg/xpUdFwHVTDKQURF2qTwBkKz8OT7uPyArApSZzNlETD elkDqaiiRZCftyykT8LjRtwrhtdwCrYrF0dcJITfoI42SssJFMZara9U3NIZHyKG0SVUSJT/JM2D Rxi0AfwM13L5vokDowtNnSwXSSnHQp0AAFJAHMNZmI4cEWyyZEcmNpZgS/gRhFbL+EEUVdwMCJGL j4SmSSV6MEmANr0igNB0D40cfn3X6x8cGTvcZ4thhBnDeCxYmPft6Vhtbyqm5RCSDmpJgoHQs1Be nn3eFZIRmEnZj/TwmvNGHTl3pfT9+++DPi3eWV39JULfBxNEJpUDJsOtntackAPqLaLXTa/fPsjo 6TntS3IrpXEuKnrJ6y1BYF6Qss5t6qXR7mwzxp51DS3ecs4XFU+F1VxeDA8VMCp1qjVuI98NvbvY DzoUTsLoisXwMpUh3YCMcRxlxUuXd31a0yQO60dDKrpaXc7ZjCztWT4AcNFcvUNxvXmn3+4gwDqH Xw8BPxoOa3eii8gvWhv62TNCGqnl69q4UqJc/7Vws+aVWsmXifqQyJNix1G2bSyQKDWFJLnIsy5t DEUrTQcPtv1ANc+4i5LgS2s22Q/+3aFDo2P7D6o9w+MjW1RVQCXVXO/4DIxeEdvUGSP114dLnhcs cKy9iWR9YuXQtOtdOj8flevn9C6cjJrWhjZqblniHu2l4OIq1oun9lOrjfpk0h+HM6PIYFmrGb2W 3QuuJT4lmm3ny08AbyFdEuObJw6nxUBHNPOT0g6pcBgPpOUBCZ15Wldnj7bRRrA9RaKGW3VyEcoA yoTKaifwvKieJ7PMs/+iHY/KMX5PAgzEueDTNvFZV7lPc3dsmzYAPq+XrQ2WL2cjvNzVTRCd8k6w Z0Jtpc7L3B2S8N4uSXiy5oB5Ibl6PthEtcoJq8ZEd0cXg2LF7HK1WfyuMIe7MUk6/yyQD3qIMhy+ ebCWb6bmEgmpuv9l0HqXokrPj0JmQ1bZXjBez+tMt9LCZ8GDc61SE/+I+QjhC3xLXCxuy4UuTU+g FVwmCEPMSeAHpRk6+KEJ4a+S1golE8pP/KISLyC1eXhHINj6WH7s36uHRDpoJiCdr2RvtHk6uFeJ Ol+XkW2QyncKDXj+FHgkmCCia6CdMjC/QQlDSowMdUmLQjQeSpNGtNuAXF0d9umV3POkIQAB0qwy UrCX9MOMlvKnVMoNOW93yDRVYtH2jlSVH7qL4WzlKyU9JtGUXQaLhHa+fYPMLD/0voZ/YPW2Piau gylKyxYLlXVaVxfuy2ZVP2NQC2y+ljGqbNvCk+HlYrEBrH3h0sBrtDoBx8n4N1Gr6kzADsmovrXz DZKgmfl37bi/mW6XiKGVZpE+LEh+yln1rnW/sV5YQQFBbRO3WECCbw3SDb6WipTgm8JCjQK5V6+4 qs8nSWI1GLpQVqDoI8KGYCN3hf8M75dV/kiVML2gWLim07r626lena127lYppFLez/vZFi6lZ9WF QDlsV2rNGVW9TExXCt+o91ACPW3bUBTgjHFlu7mlnjudW3cvIBzetPI6dIy737jJciXtXLNQJTsP wjVts3dA8imadtaCzaTZQ2UB/BJt1/YW0C+gwrXcLQMi9vwpWsWZ3J1cPoMCI/Riw1Imk9Y9vynT H15uPlbbsrv39MyqP1lqSRKF+cCUFeXPdpQd8IiM8FMXvhPMlxRasybnlVesDtUzjKxBoeZsy4ZQ teRTfo2884vGtPzec49lQ69O6q+GG7opsgaNH8svSEp1q/FRP8VF6ownUknt610g0KK1AJD41fCa OebTGvKgII7Dk966GW7XCcO6R+GPyrnv3dDhF0tB6SdI+oMt89FkbNz9Yb4oyyVRXIESXfzB2WeE zKHRU/q5sFLRj3w9PNp9leB6rUwlZyNt2R1PBmf+uUdPJOkuLRTO641eP61mAtKWyN1PzYy/s2OL 6cs2eqFkEJ8lxVp+IwmkUEoG4xS+5B4wQM864dnzH/nF4LpecaUW1BFBZEgJAurFEI1J5IAJ47Wq DFlW19NgGUJacWUWpLzKQEzV0yr8iieM/4uv/yv6AbtseTlsq45glnnp1T8xhW/CF4GQwGkrJFZZ 1wwviDiGfgF3GSsPoC2OCDLDtkHYBZdFLIzwEIiw5jZiVgB/pTQNXmZ9xCyk1XmcHEj2pwaS5YGY 7QrZJajCxyJ2+iZlVVlWtYE4vTEfnC8sq+wbb9Tz2lxfw4soXV3Ua+23v/sNroa3xGmqw0cODGcm Rv92cHh8PPPZ8IQa/3RkbCIz/tnIITV+ZGQic2j/YXoT/HlQKQL16p3WQQjNcCVch+V3vA2eXSMs wVKLS0QUwSrmUHu9NDPTYcbfvQcF/88bd7VZXqvM03KNu6PATW7eSLAiHqbeGtqq36eMAhFJkcZd /lbFRc9mxOoDtEDHRkcn1IGRseFPwHUTRCOHDwz/ffunE4fQMxFF30TnybCbDDndL+njRmGplbtS OiGCra6H+/LWVHzjPQ+kvjJnAa3n0gKTm/Tr1k3/Eu3f8gvrKDUHpVbUT66kwZ9aSYO8kqK18KR5 NXHLojC4QetJf4ZK3A3tioQnXYyOfnNrsdPE9fEMZdUzBKHKEDgqo1dJ51PBEmpb00R0QCJx+u1H o6Z7V/8eHq/MM0YJV7Ms2pLEvO4fg16EvoXClH2MYWI5pJ7tSkSPITXPLTmPO2ge0V+au83bLaKX BShgzHufLWRrCAzcFtZQv7itdnEnmjXfe09FiyhpWbfUoG37bbpWgma1vgK5KSWs18VlfVX0Cl0K vtbHN66PzDL+Ll2n+r5cw2Spr5TQLkzmPmv3yStO3Jq+RkvpW5I35x39z4iUIAlLCeERyjUBzKP9 BXo7yczz/qF7Z7LzvFkb4ZJ1DP/ThBkCNbjs8R7iafvlL/4PUEsDBBQAAgAIADAO6irG4zSmHj8A AHHtAAAOAAAAwK/Gv8euufbBry50eHS8W+lTW1eW/04V/8Nx5wuuQlj74qpMF2vM2GACxE5PV9eU ArKtspBoScRx1dT8LxgvMQnwFOmhp/U9IaSn2FgytIN3J6FNSEJMnKYCtJepOefepwXHSadq/EY2 IN3tnHvuWX7n3CeA6utteuHfxUU1VbgBwot4HtRcvBy5Hb8E0mwmWZxVbsUqsbvVsc1NzU1vgfAk 8giEvUxefCpJSgpSG/Kmeic9A7nLyn31DojrUpRm0VhlPbYBkiTv8YXaqC23mphVKxl1/kpsARIP xfVMHhJ7pal4mXfdya1m8sITkLaUdaWc2xFFyF6P53Kr6bT8mFiAy1OXJ//P/y7SQheKc0khnVYq kTVhKveltt233/43UJcTe/Ik2JAH2mImL30H6ZnkT5kkmFhbdZuXL9BCl98AR5doc7jYq6+3qi/6 oMwVZSDZgzqb2MnNNfa/9RZfwfBGX81Nf2ZELRZjYu8vAO/5PO5ROOEd9QRgKDwx6g3Ah7Y2436e W8ydXQeJl6FD/XAYTCaT0Wxw2oxGowF/TDZcTDc+zS7Gp6pG5+IJM1Jr6fH63T4P0PuDQFyFPEGv 24eMnezpHzSZzFY7soM96bTwLeRXhSeKCumIWFaeK2VILOR2Ib2i5tAeVLZIdA3ya5l8Ykd5oSk2 zlUyWRX1QrkvbKF651G5kzflSeEWvlGvpXdwqaXcyoEDsLArzYOUQnVXL6k76gqkdyC7h6Oam6Jb 89vyFkTWYp8rS1CcW5hUlqSNVlDKhRvRh9ieeIgcxO5mN9RlRqhVzUlCcRZHXFKeKetsZmQrt4Nr 5eOxB9WV2Lo/gvhc+rjKb89gdzfO0nSabOwLRSKeVkC4oSzNb0dvy48PHGhuIvNOvIR5FUkKU7EH akW+CvlrSUm5Fy8nkTFQXiRmhUnaKjDa0lOxDPkv86L6BaNFq8jTsU0ULBpXUZUKcRJko1hrQtRF H5wNetvnGfW6NbUdCKLq2lF1W0YOat1D50Nhz1gI6qoL2WLiE0i/VO5Fp0G5FV8AzUg1NUn+JD6V FSg+yb1MrxRn5f/JbtGGccCBAwfU5ch95Z4Uh9xu7kJuR96jRtYprRbTiSXxaXaL+80KejxRlsXU NluKfU58k74fSShL0Wk2RRZLM6xTuSd+h6cqYRf3vsuxu3RcbfRpS1xng1obl6t9WCznF0Hc0knQ DiZo8ePiInJGgkU/oKwf1M/S7Yxgn3ckGAgFToXh+KlT3hEPvD/AzvZoIOhx+6F71Bv2BvxAh1FU 0QI1pjRX1dllOOo5jyfd0+fq+RMM9/U43oWjnUc7h+GEa9jsguGOjo539NuDje1BmleWClfjZW4Q oFwVRfkH2khyqiCZkWWr3XxQ2wKQDunFjpWxIyuFx4tRVCV0d+aqKVjRe5vMFqvN7nA2N6HcznrO Hx62dnfZB/QyXQvjpvP4YPcx6BpsPwkuMlcSA48u/ciVzW4wmSxWg8nldLAT/S/2m/q6Bl39gwab y2ketFgcNhfNeWUxTaRa6He2GYVnEHskzULi7mc/kiskO0sKiI8EbmPNTQiQJtUSLFxjHpOZIUMo ewifpCmCT+Tq37A7axCKmWu9G7V+jNwZ9PjcoTNwAigMM73m52W0O61Wg9VhtjgNLovd6dLpkEyM n/bRwAceGDgTCAeGzgTGuWdlrpX3VF1rr3+krYHJgZMn7UbjoMNktFntDoPL6tRPtzmAsXRVccuJ 3v+AExYvtHQik+8NH+/qHjraCF/w3UjQPXIWsiXEguno4iT6ZAyGympG0fCsTqyaOIbpRA/mQ1/m 9YfhSGAixDCMkbsuLr5Xo5N+HPEoOjDhHzlzgNzrKU8ohG4VYdQRVEPo8oS8p/1vknydNI8rnWfc eBhhT7B6fBamXV3e0EjQ4wkzqSjlTLKwAaVFebIVDo2ELP/JDjAEGKkRl2DPjFJBlMYGV5Md7Bv3 TZw2eP0hEJ/Gk4XH0iyet3gRf2WT8g8M/IvX3+SJ1/dmb/BwJ48PdsFA92BPNwYfLZbRgYN+p8qj zxHEPj6v31MzDFPVk2hqdqTHaOrs7zTYXXZ8uQzdfzqqH088BL13rLu9Cy0g4COLRTttM9aTo3pa YTMYLVpaYXFZjXb92LJo3mMI+trf52ycsL6a+HDvUcMXxCdj1GiwYJ5hcrlcvANDJ3UMn3jH+e/H eBNudRSbzPaRUdeoYxRb9NuLudFlBz1jXk/QgwTJZzc3vdLMHPkQz5jeOgx9HVWHbXTYbQan01Sb Qb4fQuT8j3U3zBjq6rMZTR0Wp9lqMzoNZpOjuWnQ89cJL1Lw+MMhigJ4hq3oofs6YLC9rxWcNnx3 pKsVTvb2u5yH+roP9Q8fMh+l+J3dEsXkT3X2kDsl2SKKEUm6zLHzMuY9ykvMZCSpMMNidOxBeo9B amEGe3O72V2W2REkPohYJ5bHlFpZR3MXJjGLyl2I3FUrkTXIfIrZmPJc3qRF0jOAmcsCm5jaVgUt dyHAD8qVxUmkXppV1pGsKLN4gdmV8HBhF991ncDOyFryZi6HSZJciX+tpUbNTVTfYEviaC2VUF9w Z1XGScoVyvQYGMxtgZqPXyk+R4BCeDdkGPe5w6cCwTFIPFq8ElkTv6iSwll3IPVzvIzsU9aBM1pB /jRyBxcW9uRPIZ+IzilJyK0qV8jR7ZMdF0FOSXJ24uXM10x+pV2I3EZApIIv4D9tOOPxjTKpsc1n S0zO8tX4nDCJOSDlrkiV5Z8pyO3lN3GTNKKwqX5R27xe2m16FSB1YSIwds7j/hCDBzfZuivpOnmS gK0D0YfRYLZanS6DxeWyWH45wmKzYJ/DYbEYTBazy6gPnDJxlNLtDp3H3AQ6kfVwIMhrLAN44l7/ xBg07kBLYNDQBgyO4XfetRreMdo7+wz9tndMx3TCoEaXlrVguL2h3lmUoaXPHaLYfATDrSfI3B/v BeqOLdS1OHEblLnYzUyyqt/qnUIcMGesUFdhjxTmsrCnaQkoS9Ij7Mp/qTwndWqFTFKdLt5vhYIg 74jr2evZYjQVWWsFtaIsKRuFOJluK+qqNIsGH/uZ/hOEB+EGS5tpbS2Y86oGUUaamH1doMnIqjAT X8COV1jB1B1XBfkBxO4qGbQb9U5sg8bnLibJfhqZRt863Adj7pEzGFVDrTDuPj9+JsDe+gIjZw3j 3pGzXv/pVhhxf+DzYBiAUQ/CGPfYBz7WXONefrKPf/0SPyPDd739Q8Ptx44NHentPtbFscfA4HEK ASYjKzuqs6+pUELnqJZD9w51Dh1zGowYHAwY63D+cHffgH5MM2Q4dH7M7Q97Rtr6A8FwwN/Wix+C fk+4bcgzMhH0hs+3UdEOGvJGRHRfFdBFbqA3++1JWno42D3c7j1G9tgz4fNR4bVW0Ub3+hDPPssU O5NHlb8PSSlbqh1itlRMJ+4qS/G5TFJAb/sdBYxVVLPiTRByO/E/Ui4t8w7e/iz2MzIWkdJJPHbM crX9aaxClVWosgra/vYXPA7+cuaAJxhikL0HY+85t9fn41P/9cxfodnjHvP6ztdKLP96nXZ/2HvC G5wI/Rrhai0QlHvpNBphakO9jVI4Ew6PHz506Ny5c22h6nGPBNrOBgFtdOFFbl6tZK5l8jxBj22q l1hQJYeBRp9EBUSjlbfiZXEdz0iYwkmxB/mvmLVHLuIhLexq5VI+VLpEAVl+nF7B6SnW+ytjtWIA daAP+I2BiiJvNqYcWlE3ezudziTZUBq1+KQg1OdVr1dWYP4K71Luo1JUGcJAm72mZGhe8vv5bfkH 5RnksvF/kiZScXrfQog/UsI0C8LpSCGPaqneopnF69ldyF+oj0VlVpcZx5fIQpaKs0zANRZRw69K UWrFBrYeDiw+VpYQakymZ3Br1RGSVJukbaNa667KAdUeD2sZ0+rSTHIWIrcWL7At0hStLXtd+gyk R5k87paK3NQ16Dk94kO9EZ6xCmxpqjTH56h/lzfFksb2/LYoMgbEz7UWctq3pZ+ouL6r3hLV7DMU jPCN/AMfdq1RkrQX2gBtPbeaXqmeLtuEssrFTqJCesK3uYtsi8o9VgdHIFjWeEaLVy+h51QbDqvt tPcUD3jZ1VgFw9tSWuXyLy2y0TSINB5Bm/A1HenX7DyYxhBfVT+DsfEKpJ9HvtUrzLPsdGigu7sL k54B8n/Ki9IMXdcly3+m8LASc3xfAHtsEzVens7kERrLm39htblxj2e0zz2Ok/h4PPb0jPwjKWd9 PN2o2Iwo59R2aepQdjeXrVFgQAGxJYVXsFgkiS4NvmHqoryIJPBQ5McoiHQ0IQCNqTnc/GqmgKA2 XqZWlD8765I2CfG2dFlAAI7LsDsS5YVyjzU3bK3m3DV64iVlqUDQN/lCmkIK6S94alDlTrie2kEn lRDiN1sB9es5HnZ+NfZAKEizrBNbnypqblX9imOYxEPhm2gK2H6pH8Qt1MSSgEZC9ytclUC5RUkJ Hrd25YO6LZK5LVVtSVnFhkrNwjFg4PRYrThVnEPQLspIg/ZHQQbXyk9li8l0zRK59BsOpnaO1fPo 6pBv8E0ky8KkRgtx/B0QLmC3LGZ3S4Iot6a2I2ryZnqW5ROUdBHTFbQGZvuVjMo55tyhaOsiYOJj a6K/r65C+QtOxVQtRXnGfbUSzxE2Q2ttBaWCBof+ZppJEqJkxcqP2d18upUxhPq1jZ/+iGLFQ7tZ 3AVas8o3uUItj+PE0CEIk7HPNfTW8ks1JTxblwjx29y0/3N1bZI02gBJuqoe6DloRPXItOP5FSo1 7Zen62RebX1TxEhHoaak1F9V0+YmYVJ4otxjwYxrNF3uoTSret3K3lEwhcV7DMwnliRy11X1UlaF J61QmpG+01ismQDdEqp3qqNq6orbSewxRnjMpI9U03zNblmXWs27i4tZ9fdtOL0Tx+wgdwdd72EG b6Nr4JD/CVKKkRfF/Ff5GBVs8MfWymut5DfI7qQcdVgd1Hx0DDsIG8JJr380cC4ELhscApcTf/UP 4y8GnTsH3oPiN8V0difyCK02tY0s93b0AcUr5CILLby3t5f1QkRV1g9SAYRXQlhbi92qvW1uYv0t 0qPCZ4XHiHVQEHg4ZF3JFWGStoep4ODxPjBbE9+m/8bnH+nqApuxr4N9kJ7GKiwjS1FoNBnNVngf HHZnnTzEE5hFPaN7ZRzIWlqUSrJM7GoElXJ6Db0q0USTIbEjasN4eBAMGLUw4x53n/agqBog29nw qAbX3nQqoEvU40XRbDH2d9y8qt6kR2PYMxf5ZXC88QvNOl1e+ES3pmioskUjSJLNbkkC+in0bluR qCJUEZRevPBqZ/Kn3PfZbQR0xausNkWlQHkKU/7c/DYCvi0OM6HFqqNUeK0y+bi4q5QRdUpPxY8l EdIrmaReFHn9aPGT6PT8ti532HVSvNjTN2Cpy5gSI33ImV28bBPdLFQ0CCnvYvKhJ0V+baQuLy6C vCM+zZb0IsQviYqz8clYRbsm04cQv7Hp7hhCFJJMYTJfkkozehHjrugzmd1I0R+Ks5+gFyY/oBdR zQ/dlWazRYiXEzv53WpWhxno7ch9aTbzKfkkC0vHdOGB+x/huSxirE69RGiMGyaaZv1ock+TKUSn UcA2IQqRBNKUrxIc0oeiSXvaIp3MLP5/7ZK7nDTdFihrpV16CvOuiDLeKAk6kXRyt5NJzm/TT9Vu 8tcQFlX3Cr/5yn35u4ey51N1laCT+7T2nqP9wOyQXfrll/ULgmYn926JcjKWn4fCY+UG6EWJuzcl mRRILfZLOx2VnhyGZEVd5ij8snJfVKmciQfKK0s7+TWxJN7D5A9zyEgimtIKmzJp2f7FRMwNlb+x 1ZgG0qdq9Y8lfCvzVyA6LStUOEjKP6ALUpelefEpgs/szYh64FVN+AOefTwKmMImajmjcC8jR2/H 7v43/EEvgXEXTTtI/RhJ5Hb0osO9cvEf6WRkTd5rIYK6qRv3vtIj8avUBuhLijvdvKhW0jsIuF0O vQiZ9hNiGZq+W9PA3RAkvpMxj+BIywi/94UuxV5/UtHURkX4YGB0YoRK5VqruQ06PKcCQQ8MTvj9 Xv9pGPKEJ8a1Xkvba5utbfDe+Omge5Q6OtwjZ6vPmrR9pI2w/cqIoTG3zwcdEyG61grRHf+HnqA2 x95WS4YxBbbVHtdw7Gun69fj4+y2YADX1cY4+ebc7IYh7A6yp3y8YY/W7WpreMizdhXR/dG4D3fO rnRNfKTJ2Diy+6ORM24/JqONfJpMjUOG3j22v9fc2DsQDHx0fn8/irRBHp0+r8cf5sKl0SiyMW0g CnnI4z7tDuOo4PlQ2O1Dzk8FtF4U8EnPB9A+Oub1e0O483CgSsG+jz/tqbk+tx+z6jFOrIEdx77B /e21Xl002sEDOQLCf2BWKK5TEpj8nms1vx3UvpOw72W3O6VHwqRePPFo3GsYOuNGM7C02QzhwLn9 sSF0yA+H6QFA4tTJbNDoMpsMRktPh8FkancZbNhqMfQOHWkf7La8DmIUNjOF2rUFauuAsKfM1e9z bvGi5i/nmW322CaGLv4tG6rO4TxWFtXlMYi6WDhiQMg+i8A9BfFEcTe/Sw+4QkuX50OPLzDuCR58 9dAsNpOeR2WvFhVWUX0WPyk+htc+QLX/ZTK59OTJVn/cgq4C5FzxCfpam/athk3IXURobjJaiYcG JX8dMKInDLWvXMTu1u9z9y9Fk9tepymZy9kt1A96DoF9nyr7WWwB1SRbjNGTS5k8ZmPbVP1njzhS XfZ1ixAJdj1NaCz3kpJGBYTZ/Ia4mv1SXalvkWvsAb2katXS/sh9Xm1ovASvRUGTyfILqerDDscz iZvxRKyS3UEZCpPKEn+8fZ/naqG7I1lk3/6a1gsXODjk+V/ervW5iSvLf9+q/R8uXzYmIymS9bBE 1UwWP3gbHFvh8WVqPeDaYcICZZsNs//B/hkOIQkPiRZSW92tlrqFLLUgRsa8MRMgHmxDjL0kJMZQ uGrvOfe21LZbTE2VL1QlGLnV5z7PPefc3/mdwn3I4pqQZ+SX4FojaEB69wEGgxlC+48OHT3BBqAL TtSTg0eHBtZocWqBiAt+tbb564ukYuEOdOCd4Exvut1QoTNcZSjkDwb84gJYkZhtxNHj/S8Dh4fX rhlRcqO23AMnBr8Y+lBS22yp3SeOD/z1Q0ll58LOzv3UiAzTec38raQTgH2pj/WHVHE2oJZr1gHT uwC2wDAG1Xly1vYhzXHpKkIdeDqeviydIVUlNwdgzHuK4hpIkGt6WZZJscjvkehH/FZZSpssH5Df SRbvaz/XQSc+V41O/VEpA/fCDxD5mC8DKuCl3Lhebpj2hQrVRy+p/1xcQQyGl/R0MJtDup0v0e2R ma8m1FkiL6LnzR4HAN2UbICub4iHVzDTouEirH6X8w2K43lHH7zePxBjWUnChSsk/XFYm6aU5/k3 YUD1bI12TJJoF40EhJMcd3mOPwCaS0Bq5O3sFWtCeV5vdKMRpcel6XWNwEOxROXP0fOXKAqdAavR 8/XtDvoc48LRNfhvODWpSKJdql7iX/GtGbBJ/ijtxb937Ni3Z8/OrXt9e7viPjL6CqKtV3XLuWKK d2k3MNFxrSD1weW/q0t2CrTtbiHYo5TVao0UTZfBglFPqbmf6HjSxXvbvmKbKN78lKrJieISHSn6 C8t5Wd1w2AAGT5QFBKBoSjqXuSKfpTuJjp12gy5p6aqSRAzKarHU2yg+1lTZor2sz2x9gnLPit+U 0kqSTtscHah8WSprNXMKEDz0iFQUeTE7QWBOG50AcCSBfZsvOd5zjhR/YGuosFTKkfR5SKYif/wj kb4ra2TUwr8dER28LeUb2Voy5yAQdJ3B5hAOCgJS07Tp/FISUcuI2+Tz6xhWtEKUckajRufqod8k yv6J8KDQeHYELAkSBOz2JbixclFfuTnzHSwL6S0B04PAN7gZyZGo8End9/A10zYQFrSfohOOsJdK SjOeCutlyD4t+nbGu0hfV+/+rl66Df0kHPK/117mPe/uy82hNqKzC+ggdSmllJ44cHJ05yzQ1TeJ 2wwwZnmNribX3mfOpZT0eXwJ3f/5FKQj05d5pHdKktRRW4oy994AcmMJCRs0frNx27ylzmLjwGav Ey8EiwXXoYLnlUeZiWISzmQP0Rayc1TvBH2tHrK9l05Bqy8adu0ahzkgKuo9UlvA8YA1I8rcizCz tziqp/A0ys3RNvsBXiDW3I4EbDNTxUMwFvsIxwJwHZD5WVMWPKtANlRLO23f9XMRaWWrW7vBMtkR JOahL2bIMwCL4em2jPCM0deQILps5tz9NQCecUUXCIToyFQTxtPUD8RcKTyhGoG6f1fwHTmi32HL 2nX9l86YObbECyLDChFms3MANYMHoCMPu164oRi276+1b0n6Hk++qZNPiPVWwtGGbLpnXnDZraLE tXEQinJGHcc+2mGEFjWpJ8wa9fPvgW16GeBR94GtJVsDA0dY/5mRDjkXJR2IWbBRLaKd5XC4GWTh Q6y3RhgjSw8gKjdE/RPxYoOusbs2nx8UtiihTD2b41cWM+CvtDHdjDe1MOmbXY8leABPcOOFkkS8 TKGSHYEBo7pLAsBS4bI5DhY0fQW0Xtfpw67nFNeCvsY70ahj+fWXMaXeJ0qthQN1mAq7qYm1wTmB VlmimqhYouQydcpievlL8gzdVOFW8SssxBQp9QsBgY6qLObMr3XMMAQR6VwwROAYNUqp5VEjrRjU 1hPZGiZLsOi2dIZ+xrDS1ARzneTiXWlBfQTOY92lB+/skrJAjTxHcyBRZgbpUdzXyrlYFJoFxDXV 4tc8uZAlGeApSCXQDuGnQNUjypgLsUOBs3Yo1wjiTgFI6r5d2G+N85DY8UrX8R6g8L3dYviez7cJ ke3SO2lZT3jce69ZTzwQyZAX5UW6YYz7ikKHT/tVfgOxi6+raDEzbGzhe2r52lbBJtfXGcss6w1s jIDfvyXAvKRqMsOIvaSflZ/ZRylFT8J/TeZ2Sfk2NUtH/Py+QkUaAb6uTdhj6rZSA/+qSKs6xI7L rr6Ofb1xEsCTydZIEPOGofWgP2rdU1c2/yPHBBC/HmlBvwXAXxxjzB5gMGDQR5XiXZzAyfrb3Yf2 nPWE+sHp+UpSm4Bkl78XKnINYgdl4wVd9nS9MmeDGIvmOwh2NHmR7eRA0tJNh523qZ4VQkYlWQb3 OI3xf2hj5s5734VfD/rXemrCpogZEOpzuZaZl86QLWTdDImSHLb9VDCTlCTdqi3qOGA1mu1T+C3g y1kOGjxHhwgmvPoaRypLXdRJzBiHGS0mG9PhOuLwOrYUPERa1mp0SVw2iXXNeArBHXqs1T1hdIQh b52QJm7ub4jVhgRtbBeEbZbru1vM8IW4ZYB0ONgXuUCNBIQnA+hpVQNFNYLZRHvjO3ECIGlqzIDb 3nqO5tq7zDBb2aLaw80l7rwS9QH1C6gTtKX+EeZKSAuauall9FfIDi6LspFDAXt9Y6iLWTBoIdNT O6mOF5ZWI0rWrCw3F7fND7SN5MpZjBRYEqQX3cvMU+U+dsGyYMVKI1fO0k1hPC3+gjaa22qVVWnB vIu8ST7SGv30U/p9wGVhtBFfe9vtWOroJAFCtp04PtzT/58DngMnBo94uk4fHjjm6Tnx5cBgz4mj x4c9Ww8fHhga8uw7NXzsxIkvPDu7wv71r2kFxpo/HTs69Oc6TMXx2yBhnBWdg/1fEjqGNucKw1CQ rtPDA8eB42Zo/VdDzq/SpQBIkJP9g8PrnwzTJ4+dGgKwCz2TrupWZXKzNxDyYzQb54tqkimSeniZ KgewkvVEfqyFqmUpvdlVA1QeagtKUi/jc4FQlD7nMQr4Joiwp6ZbvqQDZsxv9mTPpa4XlyqTBE4w 3/qmRQjRJnTDKkIgRtTa9Dv92JBv9XUrBKG2GBNaMm9ZT9y7yxckPITmEjzJ8vc3EXUZU/rhpGMf NF9TqyOl57Jf2bm11PSRroMdye7ZjQnzHVXy8CJR+jQYW+tJhz6EJx1ktqqyYNZE4uODzBKrVtSa K+hNbJQmyIwMniwDjaDm8AuB6zsYdiQ4cNdRlCh2DqceZi7Y3BqxKGkJx5gFZyWFDSpPBsL8o4Q1 mXshguerNciO1PjWPbtJfB/p7iIE14oYYezMrLyhxmDlrZI0TMBGiRHFcaD9JwknSQFnYqPt3bo4 zn+bL1fP+sxb+bKvNJ37yVeopKZ96nPpLdw2iZEbtZksa8VFtO2LK/b1qDQiPdNqG70NG6KZzrF9 bztPXauJkcZ0TPo+bsHy03JOTwBe4SVm9wuQF65fYBhPqT1G9SnRU6KUaUMsUzfp83RANaXwRJ3K zYkRxFk+Owk1DzUFkQXSM1HCmJLJXAAqoCL13ZaovMwUnUi4/S4uihHKKTIHEVJMAlG/oH3ANA1n dLduZOZISTan1KQQaZykEqiMCecyRlNWqJbhPJTFx4VbXDKVRmIxMcLaGuHZMSBWfl1+Sv3gygw9 NAKCdBlnhMzNFZeRkg1uw9PSrE99Js1S2eo4hOYS5oQY4UzV7G7vI8Yb2mGzVnnN+UnE5Dg1JPOr lmIWbjzkl+YUNVMrT+H8gIumoBihTPMAARl4JWJkMIVjlbIj+YskKGrVBPi2SKnqBesNka6aD/WU GFFMyShKNQF4p2fGC+CseoibQlBGbF02552DTEmnLLy1UmfFiOQh/juaKWcRYyNGDFM1mQfaq7ER MRKYYtmxjxrWnV19O7fvJT29Xd07u3rFiGOqJD54aoD0new/PABerhhJTHXE/zxAPj86fPS/IOXG uq/VrBtixNlKQ0nmdQL8EHAEiRHFdEfu/3QNSqXI1Mpk6BJNjPrnzAdGMa9VXlP1b8iGTDLzwg5z Tn+ATPNgRxP9bnauftaIsmwDnAZhbCqryzPZmvGC+oFj5XNiZEXXybIsqyRGVpudX7NE3VmAZ4Dd knkgz4gRF1ktLkw2Gp7QEBVueOvgZ1HPskW9aE37qo+UO4IWSagR2FFXsleLK2LEcKxHNq9Z1+g2 EKQkA5zcANahzVlYmRQjiSkR8ywz4sTIcCiOvKVeEDQ5NnEBY4QAr9Q4n5sTrJ04vYD6LD2qlIFs jooVtK04rYCDhbDOQhOLipEY4VnY5pz8HOmos7Oijs8AT82vCzNrJV2csNAaYVPGRXHCgmuG8a04 KyRQT9Hnwlh0Rpw4boRAvSJdk2bFCOEsKIlqIjNHF0ZuxUrCHaYAUTxpGmuLcf997IespltipDHt sXfHbttBEqqs7DTjeUhR5bpDjCDOSzJeeJyaxliomABhgCcEGyUFsN0AsJUNMd5sgGfJGrfGHpGO 3/0OqAnEHP5tdh2l7vi+vXRnqUlhu5cnt+7ywq09+YT+EO8/9sXGMhI0hDFVUZaMkbEpMRKYnoDA n/pSkIvQSDFt37dvN+nb0bVnmxhBPJSRyI9t9Pw7hHAitjFjqfBAfSdICNMGewaG/2MIqiL8VZAY pguyc9pPyhmiTqmSJKpDIc64I42ULyrpQqWSFCQoyMPLWCkQi74yh0qQuFa+Q+UZq5rXhJwRDmkB 3jl6zi6hUQRwkWd5S5A4jt6eUsflmr4kRki4Eawg0mj2kiJoYfD8FvNSoWLMw2XcRt9nOkQxFaFU HPWGxQljqmJre4ft9+YzojYXT1YBSjNxCpYnpehm5TKYxxsdMXAICnLDVV0hFSt7TZSO4JknhbtW EcrJ4vWaIEm2fgAq5o0NDzuE2LQW6qxsmJamSN+JEcSTOIyvdCPWBsWzLyhnUtOCZDHtsL9rb/zz 3q3CgFwNeTwy8Vi9UFzmnowgSUw/yKP0sLCJKVXpqpknguTxgq9J7Y02QT7ASHL0NpZfopo9Ht+G YFOBKpdjta1J/S6K2lApgFe25fCr1YkCFMnYWPfd0RumNLDYASQqOYPQ7/3jRKAyEGvhRukJ5iQx bqjCIiRWJZXnSIqQThBjHhOKQYJkFwTi+bwuKf8Q+wbkkYeOdGEOvgR0+1KC/WQtZebhN3rCQ8pX WOqkh5S+MmsuSUXls1CQi2GQC3PmHP1/JV8qVDxEf6hrVfq3mizpWs1DsjVg9U9jwqkrEQGQftbH SfkGISHIXqy8LNy0O+NzFAgXBLMNcOSxmYIxwkkTnVYX4MheuJkA3pUwWSXyf8TIZJqZUSx+NNQg uUK2saZ5Tqxk1xbSHmk/1OGNxNs6gt5Qz8HeA97Wg7vbD3i3H9ofDIoapjYn8VO95YgTNq4bLxAb vgWNQw/wOXgK1FfRzuY1+Aex7mg5UQ2LNG/Y1iP/3X/88MARMsSyA2ymtSbjuiMSP/CZN/7ZZ91R 746Duw5t93ZGYtvavL3R0P5uUc0PN29+3+pWrwVju/Yh3haNH/QePNjdvcvbGe88cNB7qL03esB7 KBQ8uEtUH0LN+9CoOgyVRf/BBGyL9Gzf7g0dOtS5yxvcti0Y9/YGW6M93mD7wfh2UY0Prt6L/3yr e9s7O2Le/fHejqi3sy3W1urdFWvbdcjb07u/W1irW11avW6VixEdcBHdfKdtZBs+bW9v/9d/aRfU MQ7C3u1VkpnzeY1ERCUgBDjsuvD9lbMkq8oz1i9EvEyOi6TmMlTo7dx3oO+jWJT0dbXo+lhRnjFG 5Je6tVn8gcuh2O0D+/o+CDVDoIHFfujac8K7vqVFq1VKwNP1nlzjdM6Y34K57NToi8XS02HjDTWU kFa9ygv4orJmZGnV4te6Zo6T0QeFxfR5d7pZIi3IzyGnST7r8zGysMJrwAxVkhWLpUpNYnITpPFx 0nbmGri/bYSkfskWzbvIHFaoyDLRr9AXWpC1SkI8dxizBNPzYxV8syiShkBrnW6q5+jh4VODA2Tn 8Pu4hyORMEsAdeXcKi57ID4Ng11eZrmaCXNqE/IkNQp8ijJOOeYdy81fR1be5vzJyG3XFmnaF06U AC/hqd/p88ZtOyEZQNIcnQ0iyu68h3SBXIay0wt5K/dKq0FxPDYeovrPzpzPjw30H8nN2fDxOvoA TD8GYHLsHdfOQ4otFoHE7wFgWr/JeCU24S6lzkeWFF8Xv4JC2O5JgY4RgtWAhcJlA++fsSY2/Fud 1R+mVHM8fd49z1+uJvBhcwozEpG0BNMLJzMPMP/VjrjDQ+6sDg6RHvsfY7XSGJEXRU0CO307+r8Y +LJ/8AtgzHBZhu42IiFtUOOX/hfwB8KxaHTd7zsO9GyFCsD4R1QP/I7bjMprTKUM9wsSxvMdLCt9 KasyxYM+Fh8ueyMK5BsJ8OyH6nes3ipWwYKwrMvGqD8Dazpfggzcb6EGLoFEAg9fjYxAxJ3No4g0 lIBXMK6jIFzZ0og8K4yHJ8ATLvSbShJITpp2LDNRXIJ+edarN9BkvMtAsuGu7YB4Y7JBzH1g635k 6GRRHbGaP9DwMdVn6Wvq7JqkaNc+d8Z7PEQ6U7E8pPIa0s7kRRaQKk1TLwlv8epU9KvYYJ3MEcAU ASEn+KH6v43LF7MmlTHeAzyjpWtAgSis88x8+uwUqJuu0ycHoYoE7f+/sU8Osg96+oeGTp4YHIbf tLqOis0+9c6cghEwgR9XWaAHyc72bjqf6RPCOhCq4wHoYaWPGcg1I9zs5IkqhqnfrHPeiRfaWs/v 4jusvKxNULfiPcTcNn/OdFGhlmzhNT8PK9XMMme5Aoaib5BJgtdElhbcU/Ux0V/GpwrXoKT2vWyK OLhtGGci8AJwDdy8CINtaFFFlvlNu0l7AuuEFavmBoSjl4aZX1TkMm3wbfeXMcl0HCD/hQouAMMj FEKCOqzj6nLmEe07HANQYbpOtytmjhrUH9XSmHkHKTUbs8Mi5i3hAJYv2Ow+WUqONh/IaJCwEpho 6HiggcwvTOt6EmyTxp2t+7FBT0T0KiqWUkZeKadiQsYG6S39tHzhCh01aUQ0Y2WApyuZ1/P50Vcs gy/gC7SA7Y9HozFPZxq0cZPRsUmK6hWvoBDzhK7RpZn+FY5IqoPwZatrgfjchweNQulH6S0xz/Lz GeqdU69RrtOXQeFcu9J1AeaiyZLGTBA6gnAkw2UC/aGYhXkDmmigun1OlClegcKcItBIM9fkZYoi P3fSh/IAnFmTz2YeONh3aTPzF40lqEnN+Hab93IVT5WvGR1HKIyOTaO2N+OPozsV3kGsG3nTwWmc zpkzWHHM/XWN5tOh+JquaX3J5gPxkY8//hhvHeAHQWuNp6dhdIDNLucpivjCu8k/dZLZrXZszveO JJ8O2KpgLVATp4h3SFcb7G+idhjPkNP07BlqUgKQsf3U0WNHBgbxmFpVLtbhXUQCARePtv6Hvm0l fc+8tYXs7+jpaQ93NXuwby/7G6pBBLz8v0Czp3d3HeJPhwb+dNrbGvSfJso35Ojxk6eG0dFLJ5DA /DT9EMjPRQ1ZAySn/Zr5Dck2XQIA1PUKCuNKCfCEQPk7avuOr58rbAkP8Qi1M3imoGGOvipfpHqR FBatkpIErkndQkJv8bYOzyHkbYj6/M5YYksk7OfnpxjhQfsQZ4TKsIXWVVpmgUXxFDoBnnQIrO6f 7WHD3/YhzE2efNhQI7gzgFe645M+Ila03yl6V11wE90lphUxGwbMi27vclsFwhsRXUUlx5uinaHC X69vDXLIN1RWs0iRHaqbhKKsaAamFO1nucpIvSZJw3gXFVjgmZFc1YHDXb4IfSi8rCQ/+SAahidL NhSMeIm8BsUK9W9y648UAox35gxU25lXV4xlQPh5rInUI5K/WrGkHz3WjLpizlUs/Sai/zyQBAlf a+VfU5PWTIt1w/w2vUBtjuI3xt82e9iriKGm0HUK8kf19NiIZ9Xzmz3FpeLX5lT2RxbX5V+UZT0h vaNTpN80Z/A8RvsVMSXgqHkwPE+NJFbUQJYrFk/ORLMIrh+Aa+gH+oaIHykModQXgShs5gqUwhC2 wEK8qNbg8Kn+Y6Rv+NQRXj3JB8WISZvfQ/9hLNPhD4SBgvH3v/8D1a3az3mNWCvlErXu8vVqQJy/ JTVLl+h0nVmx1cdunVgtzVi0XvWmpwPqGqB/wuiWpO9zS8DXW68/g18EXjJeK4bzHNY/idif/H9v V/fcxJXl37dq/4fLy5Q82xb6sPyRl5SDnIQZG7zYk6Rqa6tW2I3RYiyXbSB5mf+FhZghgGkhy27J krqFLLX5iGwgwUDIMOMiMeDgsEvG9kCo2nPOvd1qi5aZh7mmKo7U6r59v8/vnHvO73BeOHuuEOfi cN1Fzrvovtjm/TQFgGy/hHinsmlW0b/TvlaoGL/MPnHf2O53KeOOGRM1FPRuFAlBBQFa52DisMqp GMePJkadLKDbfo4PD58QOTY5yZfIAxqOjjf3xD5HR53fsAPqKTY6fGIobtM9BkN2KT2xgbHEcXUw HmPR+Jg6AOUAoHcSgmIAav0hQnIl88ZJBOp+fkyNHT+lxk6qY2GnJhGoCU2ZeALe9Tk7pA6rsXGV SfK/ESHHXc0fJBLH+CR9j2/3/CQQr9CemEyZmisZi6TahFwEeqBr63MSGAdcr+MoI12de0YhebDx IIGQcYYHDdhchbBOI9IgVoftIaz/Of2iuFFectfE8d+Sm1K83aWqZp/pU+Xl6UVQVF0Vka+BiEhn zAhjfFucyVuziw3yIEvsB8GZ8AwVjvou6OhgzRQu97bwbMhTmjbSOHt5OnQoCsWW3GybIqaapnTa KFTqWrAbvJsi0ronNtEdOwwCJiwd3Yhw677evr4OngBG+huFltbZ/zH8t39fJ+HIyFv86Y3dgaXU im+f2O2fxEGEedfDG5nTjOUBUoQe0OJG1Mx4DUrKzM9mSAd3m3AbJCUwTFi+1Xx2/oFVZGlQV8/P XkYr3AY3PiZXkiv6JDMuan+1Fo3zwnipT3qmMsJkgPdSBZ6yi9vPJXVesH5IUesjVmJxWoEdKWvN cCnQ19nLU9EjePVmo4db6GzevLnA8wfT5tI1eGIgRonUQT1XDiRGhuMjKp3O8Fs8dynSvXJZP4wu 5s5j6UyhAtgY7fRtOI/JladwZTaTXIFJjZzIMy89C7KnRFBLUX5Gvgq008l186ZD722cnr5PSl5l af40JaST05UixB43g11RrUSQ/e/7kt9o3zPNyqWyVUdIvPuf5yCj/xcsE+RJzaC7PCin67AUNPQH K54FZVmrcj8wWKxruawJesNGcbORnRNThqWfUi5I7Ubxb6Bk06GD6wA4fc0ZQ0lySXADmK9BLjmH RiCQfHTawqYfaqf5NkBK3Z5/rJuSOuiooPixhdfppyBZ51aTK8YZlroOGBy0qVuS0aqgIdC2imd5 YkG7XaR6+rTndJTh7Jc3i7ffb5ItAgRjQW9f7/59Xbsz/1s89k1Jr3KkbjfsghF/iPUeOijpVcLw qU6AvsZ31n2xsbHYWIwO+WVjKEFmkC+llvUZ1hJln3WTxU36YHI5BHu1TQJkk4t3SH+3oD7QZwqP SPQWXmC+ikoOaZ1kv1pYOlVHN/9wTFWPxkYGG/jBCUfMiIdT6fjekffYhx9/iu5wmIs80NzSFmpr b25v72iRxAYvaBa4gcNcxOSylSmEazhwjevfEpGYFEWwMnz4GTukxoaPC5PGOM/pjv66dnL3oD8C P0JXx4YTI6pX/hGkatJfpP+kpxXXzFRY8kJGU1jm1WwGrj/UnphVMreYlpcgzJdBNmztYXoln1Vw jilo80XvUPNm9pnCs3ZxFzcFOm8VuvCxVzl48E2uckxD2yPUa5WFo84uz/OjlWYvJ5fNqpOIzKug GYuSK5dy250i8HZJMlgwWIgEZYJ+KOzvcMFbSS/eFsfjOU138HreIflqcSb5PZu+nnxsPRIJsYuT sHsALni0Q5IzDhsAM6ySYRiWwJ63A+Sk9EP47X5wzJVEmriT5rhTP5DrKXoRItrPElZP6pRphywW vEhC4NwfYWne87BdeFRtCzblRwPQuUnd/MZazJXRD+uGRB+C1pC7l2BxLFWmhN23sYN/JBB+eyu2 XeL1K+a5zIYCyzKTv1jz+wpPr233jHWDYA9V9HpWNx8ABp++PwtAE/PvPqcU7ujFVpSadktwmaS+ 0l8w80s8/YUl0/LOQAHWEmzYK5hb3ilLmKfwfxugby/SzjTzOp+dTcpWDARvCl8MIkXVet1akPNm QabCxQDjcqAOZHl2aqudS8zDew6ES21+gd71mvJbhqPlrfIMS56tzNMLRJDG3N9m72ieboXoLwhr t7YrManp+ATdSzjaB9j6MxAJQQXQmJ1JptYRO+xAANjQ/43ODGiZkiAEzTKD6R9xc4b2QMFwE9oA FjyV1YUzC5fF1uK3K6BPsis3SmeNdfe2bUcByuoPcUIsNo638lk32IAxFwf1GWblE+H7bm9Uv7Pb cJhCYTWSWtDqUl9Urr/0xuIjmHCmtT65K28C59fHESfafZ6CENpT1jH3sHEaMRchlNStwrp2Jv3c 7x0sYGSKk+hAT4nOnRyUCDcseFh41c8JaZIvJeVFEAgGnspmceotv3op7yOYw3ey/cdjQ2rfxBfD 0OEu56FQa5tE56GIB77oBJXmsEru88eYuZRcKVxBc970NQUzDsv257ITSV8GPEL+wwCegxF0ucuX 9KnCS9gOyIXAcPn+boc7ku0lggWoczgeGwcQGmFHQCU50L+DU7uzYFLrM7Ybpn8Pw0zk5WVcJAZl Q94opdHlgGyo4ahQXxrmoXMp3LVkyKxwA/oIREotAXLvPijdTmQsqUcCwntBPcUouyLrSQyqw/GR IdaXODE2AJpbVM6bBYeR683bHdh9wgHRWwBFxaE5ijDRSR+piaGx2OjRLxRmLWtbCqb8vbqpIN0T KZWe46FZpb/shUHQFCIk3juf0i+Xv4YvP5d+nP27wnLJzAPQN38q3t2bzM6t7kVmOc+CQERpGLyH fwvr+Ognew8Za4x1J04xdvDwf6sDEwqGOW6WNo01eJ9XIT0JYXsaRaUZtM5gByWLpBiGx8Slov0P m79QXtae61NZzTveJ/XV9PnCOmyDHNkDboWHwlc3jS2hBqafwkpMLgMafK1/yUL4i1c5V3+FR3Fz 9w3Fj1Q29RtNLv4amBegJaCw154DJE4u8zd45gIlv248VFifuYJkMKsgERwXH8o3bVat2+5Dn3pZ gz4zvuxj7kGCDrrkZc6K9yl6CeROdin9FOqTL5fmMvdntqgMSfuuIMQSO//IoDoeHxrxmVVOet70 DuyAkdTZZxRoQUnuMeYKA9IEZ3p5C/oYDwSsxcz3oHbgyvceZdtbAJq/Bj1SfA1D/spVDoAqEOfn Z6voalCo4Bu9inHUJBv/QFnpByi0oTsxDOFR/pr53R4pBEuC6osiM2CKayAuwu9G5ByVtzRC5XZo txPYzeQ6GAoWMWRHgrmds0L+IPN1J4YSYjW/a0JQMF84Ss+7BAO5829TU1FFgC6LyLPiCYKy7vjQ 0QnWNxAbVWE8QtKRlOApy0+aN9M/oHntPRvUwGcOJMpbXl1HGYitJWOL2+HgmdlqeoFx8YuuPU53 0rIyq8kVT11/5heWmSpO0i1oG8vOcasKBZrBMsj+WtzSvsZrWzVOLik9wSHdoaPxkQQ2Hg8fKKxK VMtTC02Jc+ElHnuOjA1QZ9dJNjUH9SnA3yt4euYZGisUMdxZsWD0IhSbvTjSlYbcBZnbodgX3EkO Wx7xBxrHGvYdQATQHAkEmzHmo7WlOdjWFoh4WpNvzuqYOjgJf8JRw8w+K57jEuRNLuuKU0quv1+7 tyFwg1+dYGr9ulVFOcbLmDZT82iDe5+fR5K1iD6hztegNNj4F5M6v41irsNRyeYXQWjnSkmDBwbv 2SFEMOVrQXsyA1FqFeLw84MxdCKFYW/xB3bFa0nQtdFO92nspArzrVUSeUC43VGKWE0ramGtLdzk gktL0pvb7PxzIOF3RScWLGpCFz0yoY51HTkCwHecO0y1djgt5iQ0kmoRqTGMsH2JxDBMrNButN5m 8nYbUVhv5/4D/V2HyMj5qXpYHYwTxpdeGS5K/tDd1RllPXjKKTQmTEMaamziElb0GiOJ0K4qlxc2 mf6LVUX/ZjuD+u2Zc45jicc2R64mFE3NVX3C/66YTu41zalfCusC1nuUYy2iF/iWtag/tQNHsCZ8 991irvhIKT0Z2mazns2Yd0Rs527YrQVP2jbbXhRJ0my3cekVaOAk0NEu/dWhms0++wz5z2uEK6gz IFW+r/fjg/0HWeeh/iYWLL5RQjVq1oYxSdu5oKxvc1mARYKHNbtEhlwRA69fAfldevRHSeJYELh5 tY9I33G31O7SD97O0RHRPt6amlhH5RLVCvtoWmG8GIUIZjn1Cz/MxhMtuDu1PvPSWK91FWjkP1Ru 0cLfViq/j56yVuZe7mFQA7h85cbVv9NsICCe+sow3fuB6yFYsrqeOiPZFCxI6rz6tScGQgnZGJHW Bua2CD0BYcw+B80+oLBgaw+bh36DZv2ut+sjF3MvRp+TOaV0C/Z6NMxYy/r/+pB/uPhK+5OS+ipz gZt18iX9L8jEm/w+d8fvb+Lee45ZBt8Kmj+eGxB/FeDR60xgA2FL324HwWRnxhrTy1YVq62wWtBI 7VotwoZl7uHUVZzQcnhWXKLiMPKgcsUmznJu5vnanSNS+7p9n/ldYRNj9cXlns7PeGl0pN13NDGq gKwdU4cBw8dOKWy/iLyJo9dHeh2mFAaUZH41zwECyFywbk2vzbxk1j0QA9qrwgsR6wQI9Lauly8B HpbKniHYA71mCLWnFpSUzfta2psU47x+jj5op805/uGh8TN9QJufL9QCVyz40BZpUjBHEeYU94VD TbyTkrp+zlqcLvmCrU3KlWu+tg64/ZW5SHfwkfeF4CO3z1Fpc88Km3Rf4ZH2Iz5HBWUupH/wtQTg zgfGRXoZ9/ekR5I/UnmZ+9P36Tu3NtI1c7G04hSSzjBztfiK7sG6mr+W13xtbU00g6mK2hNtHZ+T 1PuRd/R+0O79/6DtPdgcCP6nLxQJNDHKiK3k4I9v+kKTUtmqbCrYsTAus9XchmgyMx66Hg81B0L2 4/3xYfV4YlDFVCvUUUplPp2GIVHy5WyVOnP7w+HmQNh+2Lw/t5r8WsGhTT9VrHvZy0puqrCqZKq5 O6l186aiPYcllwfFe1sRLc2BFqcI+PXqJiwgWG7L+lRhnWYNDDZvBRQ7/Wd9BmqE45LbyFxcuESF /TOHwaFRF7SK+zprHk0wBPsANffExvHwcBf8AAUdYl0dOscGjg5APXbDC1IQEtbV4OAYXujwB3ch vsRm4+vscdcAjyaYPU1yXza0hTo451//xUfeO/SRBf0gfrRLzaV08Wzl//SnsNHiiQhyztTe8m90 DysWrG/xdeYDc/W/KDY05GdzPxs/wUJ7wpqpJukX5WVzEZ6ASZ5Nfsd8hll+TGk4gyGSZZzghs5r wn5WmjN+4tTzzYDT5kEqTT80z+Vy02vI3YcVsrO5dp6YSOCcGwS5gedOg7GJGDsC65Q3KbStSdmp uWfUJGpMdsm67TRGoR+Lk5aGASw/5i7xZnR/tHDJWmrOThU3fgMLHlroim/hIIXfgkysbakVhiUA TjFvElMcPmd8zfiTIMWLd8slbUs7g4SQbO5lYROkGn5H5MNLy1vFSXhC08wsmzZTk9x13xVSs5hO zy6C6CvedZlbeK+Zi/lycUZ/3szwr/aKCN7SC/QNQ6kzb3Dve5J5w7SU8RjZ+XLaE/NybgMRH4wS nj4lU7NT4nQpuwRbIujbxhYgQNgg0+sK1Pnq6YwGw3e6slou4JGUVS2fRwRhWTMvM98obDprADp5 YF52CIiM8/ny3EtCjQiO38y9gZ7hYguRcvopQDmoLLbFfJKz+MiKOrhSjOJ11sxyWXRGAoGUNRVm rGH0mraFVcS5aGTy8+YPCjaYGRdLK+ytUgC6aSmY3Mupa7ZbI9HgYUg59DTiDIIVZFLLbaXTnKyJ 3ykOlwXM0jNm3m/dg6alAZW0RQK/bQ0EfgsIkLDZHb8kq5fgrqzf82AdDKrjxwAElbXyPaT//BLW z/lygfT1cGuk57B8Lo4Or6qhzaBrZCg+ooJQQGgUl1+Rdk/Z1Nm/v3NXogwFH2X9GP2h/yBe6u48 EGXRrk+6ug/29nQd6IfPfb/vP9grv1qtO06dHnXg6Eh8APSbKHydSIyS4a3Ow0FKvSINoMQx9QtX KOo7ZZiUunnCHHKNtWXPDlzSkusW3nE89yWOjw6rEyr7aH8f6zsRh0/1dWsclgz/BgaDsOFicQOE 6kZZuN4fbNvdIdfd3RgQEVVPqsOJ0ePqyIQ9pXZ4PCwe53WPn4zTPIwPqSN4lBWSRQW8Yxf++4n4 wDGBJWURDXpVIHdXnwK1/VyxnkSJRSISz3CDgR0qs5nP0mJ0V8Y+SZdRGU9hUgcHAXcsJVPptP5U ERgTgQx+l5GeshaD6ynnOqN9rDdxCqRc774PWKiO71RGPdq8u0ifymcJXLftRBFsR6mc72gn9G0+ YLkUwD0ihLmpnwMYixEBnJEAfpDk1O3VBFr3I3RVuiemN1LoQR6aY+O7ocS2NKhBOBLYFcLe8DtB 28nQLijSXrXYPzKhDg/HSZluZ0fGEsfZJ/HxXTi38NyUcUmhoRQjkNA4jnlppdXj/wFQSwMEFAAC AAgAD3eKKvmvwwKmnAAAfrYBAAwAAABNUDMguPDAvS50eHS8Wv9TE+e6/90Z/4e305mKc5os2YQY 7txzZqhQpCLxktge6nSYtMSaIxIvQnv9Jf8Loli/EDckIbubTXaXfNmcFkMVq4JWW4+IrULxcBpo 1TP3ed7dzW7Aub9cLAwk+7yfffd53vf5/u7bhFtJ3CfcZq6QXuN5JUuyy/JT7Y40SdQJ5a52h6SX +GRqLrWwe9fbRFlKLROelzeVm0hyIk29JcS1uZw2fSE1Q4Tv00u5AhE2K+OZqj50R72VK3ArhF9V lpSqWkunSf6bjKrekiT50e5du3eRifGJsf/37zmc6Gz5qshJkjKXeMiNqw90Lsmf//wXol0XNuUx 0gI8oIi5Av8TkSbF5zmRuCjNFHPiLE40sQMcnYeJCP41/LxG2HPbQWfJocPEQdyE8PGcWI4TytYW 0MTrHom/b1s/MI/DTeRH+R9InYYQbkx+RMh/wLokBFLZKMff5Ve4VSLVMnNOp9Pxf/30+J3ERWKE uL3CJsHJyt9Id3EyuZBeKn9DZIWPq7Vkldin1J6Jz/n7pey7ZPpfpP4IUp+MdQmbOJcyJ2ZxLvop j6Xm+PvKrKSBLqkTMJvTSZJP+XhxETaxeFmZJcpLblV/hLVAH7f1ttsGnOSvjg/aDrf1wNd3yWtl svhoBZkIIfpC7t7l2NGf3buOwoa4+TUlp74idA/oIn5CnydXc6KLUa7mZtQ7lY30ck4sPeLjjDp9 uN3NgL3EXczMRmUcP4tq4Z98fEqekt3OFqa8odYkrYXZvUurlq5UNowbO3r62kCJ2kh76Az5KDJy PDo6QnpDkSGmi3RHvwiTvugoYdVXf4SULXUpxWqF28eIz8tx7rtcqsQrVft3HJhSV4m8yUh3FVGZ dTG5kiTKz7xM/kcXSPhY+5pzKrPCrHxFSnCr6iumzdPPkj9CBk9dhqP+0yOf8PfTa8WClC9dY9jm ZhdJPQUnU00ITILXNA+TeKIsVcpe+FSntevu3buSz7I1tZZ62sKk16Y1FyMsCrPc4xb41F5xj1n4 rMi5EnyulS72vxc+PfJHyOSmMlGhdMVrYcDcbkyvexhlXlkWXvYfiJweiQ6f6Y8e69cpjHY99VSq +ZjiSoljd+/q+JhtDw19Fh7uDw0N9OPV3/oDHf3+QJDpjA64mUNtf93HdA6HPguzDAkcIsHol0OE Zfq6ug6yf4SILIqIAuo7QrygM4knwkup1s/Sr1IiX+53qa/6Xa3sQbwW1VdwyeAdWk0952pmmw9F /oepbyCMpdeEBeKBL8JPak1OB06FP4uEBo+6/sR+wmR/LY4neFJMZq4z2X+XLk6v69/zld27suvG Y9HYCVj7bG6mUu5377gVktcthctcCm5Sq0k1lpFuJIsskwchK5PECyqontNqbvBBfDy7rix6DG/U NjjYHzweGulvAk1v3gsro8wXzqrn9jGKCOJvgkNalB+VbhM309nVGWBxz537mD72IGx0sPOo65Od k+51cjWbcqnTksivuXV2ZtCI+nHneno7kfHurg87+vf7e/Z39AYZMGFuTMmm5cok/f545kX5KreZ esqA5grf5x+AlPAtV5B/y99ChLrAx+ULipacUhYRQ3p72kA41xsVjW2tb1kycbt4T5osxxnuubCG nrE4VprSnqWXXIymaYXSxcwyy2AEcAPrB5x+Z7CF0W5AsHzlZgYHT4C2+R0sOMs3y7DPZFhYlOcS N0HHJoV4SWAZ+aL2Q04s/r045gO1Fxazy/3gQn/i4y6Hl1GW0jKnvWHW9pmsSZOlGRXVXwSnXYMQ I5YfgSWKpA0CraFC5Tz8FpVZ8Wf4XiwX8w9cTPmb4j30a9pc8pL4HMOR9o/UXPlb4Vs+zjIH/EEi pyuTiMCVBt0PfOxigh8cPqosab++WRtgvZab4x5XxlvQx1XVvNff0/En+GOmFLWGnCWfCgvSjdS3 LJNO83H8czHpKh/PVzAE8SvoFsAP1JSEh8FN1ObkRyiryOfLLgayPjCu5KWWNytMiykM8FX2QIoD 2vEVch/oCNDUENQpXQIXCuEqIX2nzYFGUQVicMMUjfBr6WXCXWMKtwpnhSoaRLEAaXT2l8L17LKH gfxouvQIJyw9VebAC/7ABIOH2limcpl7rFTfsE17TOk88m/AqzKbf5B4yLS390ZPj9Q51lM8gjke rDm4UpoR52YTd2Fn5U31jo8yqwtn7Bh5DyQyl0p8XkgLl/GbvlSlK5lUC80mCTpCgh4RLlE13W9W Xrcpb64EYQZM7EKJ41ZETskJ3wObKlgYt1IZxyRIj7huRojPbChz6Np0yUD/xkUB4tEsRiiWQRvG yMMyuR9LVyCELZeLoMdrULTOpmoYoTM/T6/vo1F8Z0U7CCk1a+QUOzfzgbbe7o7/irWYJcyB0PBg +L9HI0PwtD2tXiI+z67v3nWQhUQhtq9eAh5kCc0cAgf7IGGJtZr0wIkzxIUDiSeJczGXq34DXgtV HGsiai3By2PSpDxDyitqjexFuLoZc7ltcHVTO0/h8qR8DxDppUwm5qqzSfC6dJlA6j7LlRBIjpK+ cGiYRI+R4PEwCUY+Dw/jUok5+WLMZbEu5oh8kb9AMAYT7p78Cwj6XgdEVf/7JHigg35vAlvM5TV4 LCqJK+aqC4jXuoSYoMRYS0I9YSF6pCT5BeElZgXcyxhriYXX8jPSHYEaaE/rPhPQshVgZHWktZWE ByIjkejQ7l2YzsVYSw68Vm6T5LzOzhvQNddO65oeGOq6pl9iWmwmvHUN0y91HdPdSl3H8JJEsUhB o7PpmG6DhBqh4b9RpeCKYDcjXybgz3EI/ZNNlXR3RWekQddSFrzUecCs06YFehKqc44PZS1FoDzQ 2hb9qG3zrcpZn7K4BsxYe19cI5S5slSWbNuMl/z0zhbLti1u1quwtt7gu2R/t7/nXT2GE/meE/sa O/fENo9DfhrzEnTRVDD5qTSp3VEXMmNOIAGg+6O2vgCxADrBGOwNOmKuZmsw/4M0r93RB5FvGGXr g0gA4d4fHQJvFIwORT4/PtIA9WyFpoV8Wb7WgPFuxWSXp19wv2Oedd4A+v3dAPRZQCAAMHkJQquw kDnvPHmqDmObt8KEWZWzT8SyWxG5r7knTfiPX9mrI9t7O9oOEdsiUYI+1vFhh2N/jLX4BgJMsj96 Mkz8QxamI8b6tmA6vgg3tUeH9oyQQOgM6YxGBz49EzYeCbmlI+a2LT3N7+GmfBnTB13Gg6wjcTvm tiSA+OAgidvJH2Ap5CtKVR7jbjbp3SHSZcwMNylXY25P401YASqaJNbRXXV8VyBA7MIjQR/q9oMc 9iEkWEOurUMufazH/9E7PTGPxTYQyDukp+MjYART7bSWXzWgvZ2OmMdjTdPj7HV2Aoy/nyspv+vL gLk3oKwtoMk4gv4FpTj+0yczcL5tOGVRudqUXlRf5Vf32qEtzdugBQEV0gCxvY6uWIslBxAA0kUO DkW/xGabBYu12GTQYTP/1Id7/f49vbEWi3tKwEYetyL81IDxbcckHqbTdoy3eTvmUPSLyNDnOirQ 0XHEEfNaPAfC4SOAof3BADZ+TFzA8V7Ma2lJwNnhDGDMDg9GwoCFTAXv0XcA0d0xr3cbujsyMjIY Ju9FhgcsZF/M69uG7Bs9GY6Sg6HToaHwiG3a2D6bEZjgSz9e4i79fOnspYkfJ66N6xwH/X0AZi0w EAAqX1ReVjbAbPgLqQV5Va0ZaMj+AW7JF3QGnYfoap0h74U+NZYB0nBA2fwntjgcELsyBZ1FHeDb CtCe5VfVTVIpyoaf7evo7vbHfNbuUIKp8Aam8/22QzGftTd9zk4nkLq6qSDP+HhqRqeFTkYGDQ4x kY75bNqlZ9aoqkklB77i9/yq/EjHYqPSEfNZ24QEVLSbyjw6z1fFsw1A31ZgakF5kP474UrggXSg Bglkq22HkCBvAvRA6NSpM7jxI8cHQhgPLIPAYBdrte2UEf1wXdVzTfcv/XJ7rx3peQ2S7ucj7iaN D9ocLEzyagJ2tynxvVpLVyiZbZjF+5pZeqOfndgzBB+DgyY0LcdafXZoWs68xLjxJKPaMK7m5q2Y dwh2UhWRWqXywgQLVQCzNjDNvlBWebPp+7WfC3sbkJ7tSGlTqpmY7DpgbBsIBMjvHeTI0EhkUFdJ SOLzALJtHhCkSYxsmnzFnAgxrubtmG7qLOybpdUAaRdAq0koZC6nzRDxKr/SAPRsBypX1W8aMN4G DGR0kApoNBmYweSPawD7toNzWmZZvmBHsc3bUejVpUR+rQHXKEdhGg3rSv6WjklWlTuAsURIVoly R8lKNaLc4m7qy4v9FABZMpgNFlMrwcsQScoaQceA+14HL83kl8Hukpem6+B8GZLnZhsY8mewu8sC h7G8AcVuRaHOQ3El8sksv6xDU7+mfgWoJRESMEaN7Dlt7TE2twFliUS73RiA+HgDwrcVkVKmeFF9 Swdllvl5yPIs7pGQo6oilp7oGGEx8RAwFu9IkNOUez6DTijeAPRsB+YKyl0Tg+ZgC/xIoOYgXAbw RfBXuQKeBJtwRQS4zwZXxFzJVGUa2OkWY1scKpVmGxC7EJhR/KY+UKpNC/PPf3p2fa85LUWz29G0 zNZuTE2ZDhgPDwBqE4qeJqCNJ0pGRBHHlVnAWEIhQXwuCnQlD0YGB8PDBrKa+kdD+oUEY2gls5w+ DyVRfcggGMNQTkOubbFM62vwWxMzv+fLDRjPVkzqYoIX+dQCGgd1vkY9kF1WwXhsOQAS0LzSsrH+ aBTYgKgjTIL+QDybgCLQWnUkoKPklVlYx/zXyUuwjjr0Owl2cp/FPxIqaAMmU3Ow/0boxWYvgC1B zO4vRntJlDb0OVEHAGbxT5VCSgicMV4wasP6uLFhuZJIE21rwCCYwxqsiy2qI4E6ntQcN0bUzZnz mSqRNzGIwST8vBlbsXkGN9r4xm6aAzIVv/NwU/DLyNCJQXTV/mPkcGg4NBA5bRYPxp3erXf2Rd9q ymtpWeS5FWnSBENQaJQLowRlPX8rU2gYQoIx9CAFDqHVkgoJ6HRnhVm6claajK06gFpyIAHPqfcM DESiDRjvVgzWMvkK9ZEGENsVrlbLho2zLIctz6cY1hag65j3w6dHIl+EjGCPbVLAWTJYfVN0fiX1 33zWQArcVw0LgQR9IeRrW9QCClp9YBNcL2sLw0gQaukltIl88ioskKF5RkvL4tfoaYFMJXWDKNXS NV1hG+DsdjjV2OIFwQjyBtCzHShPqucaMN7tmMDx0RFy5JTxzATkC6wtFiOBuk7hifyrMdVs4i6U 0zYxgKCfqODSR4bDJk5MAc7GPxA0WBaMcsbjZsG+WVsgRgJ17LrHIfy0WuMzqB4066vfdQPu8trv ugEVIBQtg6NhbJKaDFCcrwFH8za3eovn4RmJa/lVUbWj3c3b0cpdM1XBU13A2EXKzejJhQI7mPw6 O69UQYf5iQa8pwFfuUoVPvUUkll+jf+KvnFlh3u3wyWJcGPgHKUbppNVZpUXgLULp7zAVDcUGTKX CYIQ67ELpNao88yvqRPT62ZBqcxqiLMLpeHbXBDXNrVkA8bTgJGfYRkVOX26IZFUZivPAWoXovJc xVIhdY++rgVWbjkNpbrFKyHB4B98e4y1RWckyILI0+o0NDoSOTY6SDojw4aZK/OoTLb4jAS6gYYW 0dRenxr7jawtPhsdR6M+bjt2LBQZNmelUO92qLAwvcH9TrSbU1Mo0Lpaq+/jPK6WrYxHgnGPyOMB vB1nK+XrOHv7QT2nLAPKkgsJ8gru4yofl+IgIk2mqWQG2NMA1rCwSWbzFXkMlBnwufGGqb3b0QUp aeQy6oUcLKutkkdCiaNZCna/Pg19dsJ49rQjxtrLeHWaPhein3JLyU5NGRNOH24HnE0ePLqC0iCT L+OfORlFebaiMK6Z6Q0e6QLGxj494zU9JPYSc8UGqG87NLteSBqYWupijLXV7kiQNJrAJ7QPDe51 ELsddCD6JWkPh0+RCE25h/W+iXFTGVymLcQjwVybemWLQTA1o99ROIexzRbakZCv0JQXfDrlt5BO goHYqnckKJqV3xZuQanJtloCIUGq6etTxPOZcXVDu44cbKSNFhQeU8I9rO0ePLe0+o3pRXkMmNVu Z9fNvQW9p8/DF/fgXktMJOBrjk3+QHAvNUQlp/CQBiVu0yYHLZ/0W2k335YY2Pr5DjDykyfDbxkf xg2FchxusIRHQjnOx7UCtQwpiRpwDt8EhdCdfTazBk9PZ2j32FoheurjtqUQ+rFPch6Zzabu83HT ViFbEABprQsSZAWZi0YHSDBy0tjrEqREALQWAQnKIgArfO7vnJGsYqAHlCUvElTcmvZwyHA9+PIH YCwRzbdBjC4RyIXOxwBXS1dibltygQQAfhSKjKB/fj86TH00FdsAs1vBjdWDgfJsRWGmr2vNi4Zn e7cClUUVRDYw18GNuG2ZBRKEn2maVBlPPAQcfSiefcfctuxCPwynxkKSU+C8jPJXuWBWJJVJXEtb ooGEchzft6PnBaBouVLiIVSpE1Bk5G+Y6mrc53n9fXrRQvKbKXvJuPOHRK7WnT4H7PS3s+or4xyw E5STHm99cKS9r63HOAL8YHTgDGkbGiCHQsNnsAFLz/8C/b315utR0tvRtv8A8R8JInd6z9I4Dezr JHprkuivM+otLXfDsSOOkLbBT0dPwlR4YvwpEqLHyInISXIyMkT+FgWt/ERvXTSZ54X0YgTQ8LdX P3mlJmqeGdZPZZv2D59Bte4ZHdlLdAH1t2XNgz168Ub2y7fT+4XvFr1jvSLwn+1dvX8xL3AMz8oJ 8w5JL02v89PoonMlfAHD2MsGPI7RtzPoi8evuVn7JVNVLhLxf2m7tucmjqz/ThX/w9mXRK5vsdHo Zu3LV2N5bCtIGpckA/pcrlSSYnezlYRULlu7L/k79tWBwAcsICPZHt1HyJYUYkMCgUAukCUQwnIJ JME4JKT2nO65q614q+JNLTXu8+tWX850nz63OcDcz4cM405SVUfpj0w8qabgGRiX0zA2lYJdSoKK 5XgaMlOTk4kc/ZWNZ+VUPAZD5O89OPj77dv2xFPJSWlnFJS9ZCjCK+urr+Ofg/v+to93l1kXJ7JJ Zw+BfEkG//zWq69syTJZTmH+t/7+91fJsyS2f/8rz5M39V/oL9PjCGWe2hJwv1Aqu3vv8+vM32b7 tsLRymdAPp/zt4e4i8TyMe4RQQ1wnQ494b1zrTpHbmPcl9B+Iio/KIynD4G8r5ZXy1poSzxY/Ja7 WGN26dPgkOkVEB4idQH5pEaG+NWg2yYqFz4oZGOQnJRIO3P6x+4lIqGUp+FpM9tpIqOobEIMoUka DLFGqjh+P3/Cm5LEG75UuMPL2CUC2Qr5aJflWUr9aK7XOvzHtmD8IYe7XAf7Gja8581O82tvkD22 DvL+lz6d+7hxjp5S6XFyu6p3mYQdMFgiYLFG0GzN4YcyxHZckNjImpfYg+E2S4/cNWLI2p+CWzNu y/csjOL88ifLRwp3hizX6KD9GGIr2279Lxs3cy6jgZO3FXuod5dmuyfDrELr3cUlVmjcpGgeuEsh K+2cIxYAPoPk885+x1Zjsok4tvD9NDLPzNaM2vJAI207MHW735xz6i3TZUoWx0+PDGYGWV+Ypsx4 d0lnRNPC7lXzrAFDuKNHeo/sekzLwRvErYPoXGhgQ08msmkbugXDtVzeyT0VuH8q6wSp6acb8zN+ 59C0B4U7OJACQ+A1pYzcJ9nvQMDckeiBGf7ogTnY+DnDT9+9N6OdKK3Wyvbf5KjIOaZc4BNEelvm 874lQ/bbbseMWQPcefWpsVCGYp09ktwWYhw4WC65l796vnugeIcvOGkcA+6Vb9zJz2onplXHKpOm iu9jTMPD9hHjer5FI91p71wUWeLtt63NZqMgNax/yDUtpnc/X8fDy3nGlOS9zM6cIxRytqwN8bs1 36+M/XyIy+dMHKc/KIaDtZ4bdzDZbz9mywl+8cdaq7HOfrv878WzBjsta5VfkM/ZXnMZ+XP5Uf7j 4iN7mVpVdif2G8OdloYCQ9EoOcEyz+9ql0D/uMqapSMXSh8ulorn6mtQvMd4mnudsgaMay7rwcP5 Bw39D4yNdowrWZiaBOu12TEdG5th+lqczE8ohG0rJsZytm+so8BxgfUwf7yKcgZEzQU03uojxlu9 9IAc8Ia4TwsjkmNEkM+Af8j0H2fYuW86T7VTELGkGsvR09hL+AtivimGyiu0FSNlYprD9hVoPv09 lG7rtzpr7JHzKj3Ndarn8bxuPv3t3eemR+SR3G51L7kOzsBOP8RT2bTKb5cemgScI4TEACTjmUw8 NQ45dUqICMKueCKhpIXEEJx6v3SsuALlh8v54jkhJmyoxk1To4ccgaSc2SUkDUPnXLFlaCxd93cP MIqyfjKpoMifVdM5EQSl+cYPtr+Jh+hnTmAgp0ZBiWWyckbchjmTvmTaMFFNk9cSieJsDZoHtYq+ Yk2DgybxH3B2z0ENMJGdGSDJN470Tb2gIEwmFDkzlVZ6aSFSGF8qa3PXe2lhGFPTym6cnLF0XEmN 9iIiXLm20jgC9W7h1ju/64UMC9jEQY5CaaWxxv7pIeLM22MHx9Txt4N5ascG1cHYIJtD9uiLTajx mEIe2LF4alRJK4mEPLAjrSTje/vUxvXBW+FIDm+HOfdoRegAJJ5N4ntjrP24HE/1QQehuVb53vfd u9fqA2yl8rP6Ta61Jd/TPjVDUL+/cAoaH7YeN2Yh/zMy8vxZZhtpXat/26diGOgM4UdIH1gU2icW by2e1Tq18sYwWoakPB5PKX0wfhwLdk97UNP7oKR+i2TUM4Vu480oVIAbS8+I6BLEcSUyWdxnaDHc bOZCBrgfrYAShNaZ4h0RJYS/ij996mr1AtPk+jIxOQsZNTUu7GyYWbqgftFh23UjIsLugi+eymTT U0kllZUTwqaH8RzQbosoUZi7XryinaLfnBUAcPVcgxBB/Bt0y37jeBwcW0xSvDfX6peMs2NMSafU vijJ0NU7N2ExMuB8IcSQILBeZlUWYJHGN29E3dO3hrGIZIjVK1yLX64Cc3+an18817cuHkCPFs82 7jO+dsyeGB2Bwqn85811KJw0LQwbIIfhu8tfPe0LiTJfr34QXFk5Na4k+mL8oKZI5ZVWIGsdIGKo ZPpunbpq4phoYgkK8ijuAiq5dzYXP1o8O/eJGOaUJ1wkiRvkHO+hixwwdvv4eEpOiAHMo0hACeJL mU7bjOCm5WdLa6ajo5sWgpG0uktJiWnM9UhACTNmElO6S6bjnZsSYX33MXf8jJwckfFY3DsgRjaO 6J8il1KMrnYIFvKFkwuHRchhGElMMX1mSkwuHNXPEaeXPjP9htyIKBuiL4P7TpxvPhBLTI0AnZYD 4gq1bvORgIK8OKLE5KmMIiYWUD75luVNsV1a3Bg/DkZhgoKIKjEPfTpy6bUfldO7BKh6u3Qsvzo/ Tz/RuCEZCC7ZG7zZ43vjJEsgPzsKo3G1lxSAGw+/Xvji4tWjvvolFN/Plx8O9KKC0NCLLU3rpeAm dLTyWefx8p1eWhja3zVO95ZHrOg2cn+sAR6vrYVe2DBoF6D0Af+3lxw1DqU23gWf4EFxm9TYXhSt 0NHyQ5yX8sPOl71kPzRuVJ/k15smb+srpRPV6gxKS46wEas0P7t4trqGv9uqtxex/9bJZQN0FHcb ei/h88a3eqe0Uj3vIcwd7B4vnWj807Qp2oTTpSv6ireQmW8bP+i16nntROVCD9k6751F5MtS1nr6 RKTGKhkCu4+9pHt6ufSVXimcrLerxz1Eaxs1CwrHDV9Eb3G93XysPdAO6F/U29Y9wyJXyJKMh3en cMb0tXEQG/riARquh1AqkU1PX1l4ZDpq2KSv9BXtAt69TucfN7zTWb6glwt39IqnmNkhV5prhaP5 2Z4JotBjb9ElPDZLp3/0FJPQK1jcWks7pB/ufFRreQiNukNmMAvJAYSHG/cQaMxQuVtv52eLVwRL qd8sHNfPNq+gyKvVP6ifN0NyLEBzobnQOa+f9RSfPnT6kL5SWy5d8xDaSws/VR55Cjvn8TJX6Zxr rmnrnWtN72iRkY95iy5hQyZzMS0A7nR4m0yPqknAC1gmrqZAGtzpOF95bNjC9/oFvPmhcHJzU7Ul 06dkM+AAjNHtb1PYIAo9oF+u35c2BaebjfYexX1tCh4mI92okiIEXtCScet61r9eBJaOVW6RvnxT cJSyZzt4bZm/6d8UPmr78WwCTpssn6NNtY6b7lhCTiqbwkowqo7TXrcpdACkKZhMyDkZJuSs/H+b qhSEzs/6TRbqX6ttqkbImn1IJ83bt6l7NA7kZBzr7lJERAmKt1qLIkrA4Z9zwOWdQ0ecqEYQRTby Afp/a6lc5BD3W2bHrGPHcWEisMcSMF2EYZRH8H4sHEMUtHlBObIC/QxzOW82USYmLY6Ba+u+LB6p A0D/0iKBv0esFmNQvl7Jr5o+nhuAAuxPtvq+ZhNPHvz/QN8aQSg96Qugl3n+Ad6P87OWWCVGRpCr /X0RwyzAoC8kipeWuZIZUyEG4QS3ri380BeCzIcCp71wnbXaaZ5XgM038mVORJGQZ2MTSiKhgK/x T2TC5U+0hQERMuCMqXWTcLtctRj3VmMWfKVj3X/1aywErTPabd8P65d/FtLDEJNTozkYj6cTInrE 1MOJiMO0q9qBrm4i0zDcEVCYaoHyLYpodPGEZ8C6mriIEp8Z8DG9nGg8uEfRAvRBmM+DL776Omn5 KZ0IubjPzt1np4pkWb12mAoeyWH6ofCUytPixwYSrw7z8/Vu6RwTCVhJrcWCM7ij2+qS0SZZIxnv Sb9laj3bRsBT6XEbkcSNAmS3Yo/cL9LPDATMwh3Cx56cis7MF/Xq8ciWGBEm1JSSAx7IaW9PpBuw kgmhcILXlxvgG0srpMTNKeYyeipLsHhorgB+bZG5iEWjVho65nMgrhSAu7fvXX304MoFn35Ov9n6 l/bjwA7QLjbXcCO3g6291fCKdnH+J5h/37qFegAhcvSxY1y95DA7evBaXv8gf6+2iqeNGBdh13cu ppLneA72WNuJBzoM8xfnL4ppUT41krYopOMb2KzPlfXD9W6Z3AYp3ByXIZHIkEVCTmUVcTU/7tin q7Q+YjqKiW2Ix8XEANR/Wl7F9e18WHkqhgQBZeUrC48ZN1CWLDEsxFw7IY/iPDisPJlJOaaAbMkI 5t859Xc+xmYDQqDEA59EpAA0HzV0ISkI1RoF1LH1EiJCKIflSCeaVSEjp8bScioWz8RUIZg0QF1N SIqQG+c3bmOUGzFMslWrVjbUlUJMlKszl2bLZ31rlS8qwrlAvjAc14RUPzQvdY/NfVav++K7c3gq xiZSKrh2WncFya5AJnZ2hJKrU65fpQBKx81/1y/8F1WCZpWNupUbHHduOrlxPNXwJE7Fp5IuAcmF k6w4c7NQhAoQeUSdSsUU33Px1FRGkVPCnw1yPSVKzgpMppXE1KgigoWgenz+o8WTvpycGh9XVXFj yC9f55+UbvusvglhEYhNxBOjE+S6mNkVz4owuI8s0n8+P2RzSWEzUdB/1r/NP4H2d93jfUeJHJQB XDbfpJJOC/uEXOTH3wE5m5Vjuzb+UWQeporoQOvLpqm/MAL6SQM9nlb30Ns1NcmW1P6zP5QkPEcy AIetYqO2JUH2gA3BAXKVXD792NIbbwQMOm0WG4FCMKnuUdJk8HJIWRuhw1D6prb8K6AIvh+JBCR/ rbFh0r0Wr1rH3Ua4KHQPWvoX03/O2IBJbcOCRnupuAxMv6hfIzdXEcAPG1Sl+8plXVs8iTIbRYR8 LcIEUEDG830FWgfqbYfC0AUKMustkPl21DplXYgQdDX90+ZB64LsooZZrJKIEmGR581Llq7JRR2G 0hfWZcVFiUJDb9+wJt2SxPh0WikLnARu7WbrIbQHOtuQHBk2PASzDQERNy5yQsjApJzO5gSAEA8g ELYcppvKxzgdjSPNLwV0nKkTguJhCAyHBeVR6BzV3it9pXcsNanpF4Wcqf3ou3JhgE2W4+0SAHDS jIA3O8eCsCGJBdv59sSzEyxiY6APNoAXTNywTlqWHBEoKPBrEOFQelCUBOIyfUBhV4oqISTiSAa1 MWqYh3htDIhyl5qPileKp/PvW2oc44oxM6amaTxpyKhTiR4q7V1k/e4hpOLjE9mknFZ6KGShzfHb XqaHmNmjIEOSp0wPCTvxTNw3JmeyA2JaTynnA4qb7CHVr1W+z9/vKe4er9y1cw05CNcaP7zno4k0 f9t0TTReYMoCK6AgM1bPN6+RLHlGVFFiuRuMDGFNUQvIerQ8LGQsf8/p5eFCBZnK3WmpdZFDrhwG blqYm+Lyq5qGcrfD3OBCRaBWLD+cvymiDRsuR0aeGr0CRb3wnmWhdGHJu6fetXpieqEa0+gwBboo UdPvSEBklqri8eoaxSo5BGkXhq4MOVHLkpETDG8KIjIpvDPZ+G7L/OyiBmHuRkPvLoloIWMbmrtu Cf8uepjEWBUlWpWE1AQ8A0mSzm2XLBcap7+8dGKxIaZlYpRnMysiDrPIV73jNHBZjrK4DYyQ2Do5 yYVntp84+H8DJM44Hr9MVVl8RNrKSnUd6uu2WWODH5CgMFuooMBJhhAgS0hxHbSKz4TgNXvgV5og PW/xPmha4agpJRRO/kqdoJ2qoj8wxLTxh+kzIbZJdCMwvjZneHhcvb10+FfAEXfOHPsivVGFYdNN sdbKH8BpY/lD+leJWolGbHcylJPKWJutlr5ihPLh+8mycKxaJidyAzaVnDt24v/8vSS6QNI9VxGQ /LB0TDugLQhIEsT55WivgBjgvyYJOiLB+F4IBKI7gjCdmISUGs8oUHmgfzwjAAdgJJ4eFRCCeDqe +kpACEFDNPywOfyQgIg3Lhkv0SiCQVKNCwDD0K4WjlarAlIUWl/nvzCPFTOEPGjMeUxNjuCNSUjG eU/Hx1V8vbMq+MgRhPJAL+i1ATGcezTkZwun5q7n7+UPOERtD1ISyCseSADMDF9eSpAJ+YtnQbvc uiWGhGhczwKNzKO09QDDpset6T/ZF43bHV4jDSdL8Kk4O/GULRR70MOg/VJ+2LjLVCgLd/s2TWoB yngipHFfJPcx5IEEofxQTAk5+4xd2OD3vRMhRkVA/h8xxTnYhbtiDOnu69/y5KjuyTBi7M2NYBJP JXV8ii5QiYyq7ooLYMhtFJAPPlIz7pFx6Qx7n6hNZDgONtQ4/aABT7vpfuidvGERJcD9ZUl6anwn AuBlvTu/LKKEqNEPRBTuhA4ujwMXIGJlbrEPfxcg6siZ6B74TqeTnxEVb24ThTNMxmpeQkGwtsoS Xzh64ASTTISXZHDIvi6yH8bSSio24chy6gZIxCVfiigBJoPiy8RLtUNQ+GjuupmJzd1liYXUQ+FO +4SIHICMnDPdrH2jUyj5s9sYRQB1Tw6IqgRRXrCERxcFD+9ZO1pdAAjjsWipM1wU3FHUpGLrCVzE YcoPt9D42aEhctGjUFgTlJvPg395/U9bYxbi3x4yQw/JAkTuWQFuCqKkfxFWxoRBlAV/c4OPko05 TUs8DhsLt28bQzEhMWWl2+aUsRdeg9grb7/Io9Xju3NJZdxKu80h0SiQlhcJzBdy+7bsVHpEtZNw c1T27Tde3A/TSUoR99prL7/9KrDv9EBy359egOTLf2MJ3ylxWsDdNSrUbvt2SQNMcprevf+lF155 +c23ZsysiSEvnmVOJGPZdP1+UWcp4ZDdHbdlvHyvLB1o/kLv4QwPHXIk+ObN8HgiasTu8QwPGXXk /OZYezF5+FHAzvzNAaYDnpn9C4e4M/y8TbYkf54h6Xk7AzgHUOH0m/tf2Q8vUG6C2YMwqsijoKRG Z3g4mCM5uFmjebCsG0nFeZYSN8D5QQfSK0y/hM2zRPmxCTmpJBQ1NbM1LwD/cBUFOTJTKOlw6MGY BAq0J1vhb873MRyS35uvgAp5woYJNcs5f0cibpFZWuvBHewDFcw7RlGnEpQierecUT1vQWr/X194 c/9rL7/E20upe0JZ7ztAqaRDb/0ZfDTK9gfI8mllLLjD5nkOS+/7IzETztUf97+x76/73uCRrgHv W8vDX1k6/C9rZcf3DAwWxkIjZcL2bfQBirC3ASrkCevZcnjZlgeimmyLi+Ou7Vkx8FE4XvtU/v4f mEJggDPzDhEzW/xbWmue3L6NfwDF07xRaDbPs+BrC343ysiFz+acsZJ3jDyMnshbwcz8i2UUkMzj /lhkIxnzedwlFfI4xNBWGO/VTLYx7+VplqrC+uqhmU2jfWLxXcqHwPJXsLhoyfHxDl6TsgXQXvAM 6Lfa5/nS5O81L+NvuHmdF5of9aCEw37vJsySDhsAR54VG8DyrbAtj2LVA+yDDA4AFRqfWaAkgF7e NqPBGYDS/3n3ZCMFYITvqdU5x1c5TDasznUfokzFESyHnRfB8tiFrW89SJ6ZNiNMGeBm52nvLoyF zXUO4Lm8PL00QplZH1iOroCnl0aoLGvB4DLPW8Ji4beKvVnoPuco/SxeTO8z9sk/oSyy6415YnTg kfRbEuFKLiTFO++49w+3XwnfvOOT6qTfw80TL7++/3VOf871PRqD/pzJniyRc68QgSvLtg0aag// 8vHzdaEJ6BFDzPwCbPd8sKz1cDAV0nbJxYaGvvyoh4epsP2Yt8EznPm9rzrzRGQASt7Rw8JGRg8O eBDkHMw/fmIAHpgfQJmmVXYsMp7+IDNzwDtm+isZ2N/WSQjTyyguG5od+A9t19rUxtGlv1PFf+it VNlk6x3KxoTgj0IIEAiJlcAOS6XYMYxhFiFRupgoH/xfiJ2LL+ARQjC6wIwAIZIQfEl8S94kDrGD ncROXN4Q3rWT2nO659IjOdkvxokx0/P0zHT36e5zTnefpy3ocfWctWJ5tcUkcYJ0xCSJ0N2lJgzU C3+nzcxBLz1kiEUEsECg2LfZnByUr6JNHJkgDczn/jrodr+XVe2JmYGuS9gEHe3w8sk4ZuuPJeED YGR7m4XCMpGtPJIMsZ5qPg1tG59Nz0FjpdEYi0O4UG6ifC74zybX8LmM/4fSXyszm7MWzNN/OGTz a/gkjG7tCoeJe1yMJKoLQjeonLUCerL9KkOh11zBviqIWYM+GlJqqPi+eR8pBV02h0YAtWzXmChH yBDO6CYsdNIb9J614nbSS9KwfFmdM0w4PKGDCPPLMR5WEAPUNmTvaR8akYKhJfJX9F3NqjvlfbV8 ttmKp4iX6R2QFDMGloVT9DzSbJg4uCTqCj2dObRwF3cSWchy6U+OZoOFvmUZqJvVIYVISzFs023g JajwwcYmC/BiFRRsK842XpKhTlD0LAlN316aQXYNA4GX2SyutuC653k9b+F2stkGm2EDL0Gzyxbw 5B16bqBqSucrd7TLdoaVXziuDebQ0e4TdiLFmdfIgsYxUmsYWQxbmR0UBdHZ3CgKmZ9A2bfkJzOb 2UaeDTPDLAad1vYrd8iQI2iChb+Su4qMGyb+CsGdk6V7DdBx4gmwzl6nxQbD3spRUGaQe8PMYUfK JA2lFX2rcg2ydAdsePEGkm9YcHNpDYtf3VfQ+4H8GxaYesIrd+AVi98t3MV+urao/WbBP1E/4Cg4 8NIIMA9Vv19M57Yt5HZhl+PfcATihr5DA3SbWORaQfINA8uoVxrQvwMFO9LUbOF+Le1x9Bt4Wb6G Pt7t7AMytJTLPqisLV1ZtuRFvZl/zrFxqDdJ/jmeBsIViSH9c2U2rZrQ/PPhrsBZK/RmHkQUDBRz CMNPR6IM4661AR0PMdFlYzqcnq/s/YNx5JpPZfla/y7fSzLYBBrMhAb9/Qp0Clx4ZL3V2f/xOcNn rVCc7LF57KzQ9MrMsqbNmFBc+OAINOgSS/o20T/Ep8Jr8jmrW6PMcCwZhghRf17V1FF8DuOKTZKB l+hHnCdr53AcYkaLCV7ZSN/m2DLwUv8KBhQa/NKsbugOH3AsGXiJK1mzZHlhYw0Dqqjw2F8XrmZu Y4DxbxWr+lYoF5kVVBMvMxfZrj/cKl6cJQ1GxbB6ed3O9xFHpIGX0AEwCjGZ19m/LxEv5JLhWDNq qGWc46Q2q65yzBl4ubbrkDI8j8ZRZuAlPCRzMXepeiDUbmm3OC4MvKStAhqSBflZneOIMOhuUcMb S5cjGrTLlQweCiRbVjWgoHGkGFTuuIFl9cowpcMwbq/CTaYPmQB0eHLkFngJYnWlbA0f61pljSO0 wEti+d1N0Ma13EOOfgIvcfEQh2FkmiFDyoz6WHlswjFaCcdFgZe0pTOFpZKmY6aHC/98+Vh8IPGZ qAKP1U2DF+ZvbK7jOtRj5QnjxHyV7zxy9I02gadzwwQadb/0EY0qwgSLwVprYHTh04qjzVBcZFgD Vb6Vf6aU1TmbmYHuj+ap3lyRUVCsJEGKx8UUw7R3twfcPMdb+3+PRkcE9fNKxaQWYuw0KlL68WQ8 kKD+Kmw+zVxU50wGG6WC+iNP2FMBjLVUbMe1poSXTTwBESQU54T0+ZVv7QIwVFMtCmb5pZK5vYSh mmtQdPE/85NJmcdgLTUwOnZ/W9pTVf6lrTU4fSv7JL+A6wSPzcj11IA/5iiFwf2D0k3YyWATCsbU MUdRKnvL60L+6VpmKYN+CPyXxzaTKs4bQb9a+EMv8JiWGkzlXj6nF0q36M6R33lsazV2mMXZF3Dd E3dU4NKGwZWDikwzVy5MwMP9levpH4RyTt/dNMJ6Zz7LzHO6KiAhQd9a2cisC55AyKTeATOQZ4Nj ipkwMh6T44lJMT5qSuPC3aKKKqrNewMJxZvKzOL/CIXf8nPpndXfeWTrS5HFPe2+fpWGtS7MgBqs P8htqR+wfOj6czDE0YTOwL+x/x2gJicIz07TnU35kgPW7ITlLpWc72px3rcDlBv3W533McgM3ajP YVqqvhcpWTH8uyldBqrqg9mWcIbAgxCcbkqMkyuCMlv4UZthGHVxaZtTSEERg4QFqEhh/XL5Nkif FTYZQxEKPB0cTch8ZszkJkj/0kEDhwn6VvmCoN3Uv9Q+I/mFwm72kcHdc6ly3UEDhwnpT7NZJp43 QRkF4d/CDTcXFdyKxeVqfkmu/FNoLHUVLSGMQoQGhN3BWLaWl2QrLaa/XvjNPGFlsAqldxxUcZiw eU6Y/zj9Q/b54jOzDShzbitX3PxyI7ZTI0YCaMRT/wLoeRUFg1Bvgor/hM/W9HfZWDx3KEr+CmU0 L/E5m/8uJ64Vg3ZAd9EZ3EObioNKjibQIfBGcc8MFcOOwmsXOE4glmDQ+OSr2OMwQftZQP1t5cf0 jtnXltf0bQdhHCYo/7u2pT8QcOkSNSaObIcnjGMmtICbCfNPlRkwXOYyt3lsSy12d7ms57Hdsdmd Dc7ytNbk0S6n7xQ/t/sRRkt1cMSx8Km0BUD45j+mVoExnxmTAB4MdVDFYUIxjQdF9QpMP+ezD5XH aAay1W4hANO1QTVzoXLPQR2HCcv59Y/XZwQ8/09K+wt3zWJrOcoz18Jx2eS2hcKPytPiDRp6iMq5 sYBuEM7ouw5COUyoXKUdCkZ0lEQe6CCysYDQTY2wEDy0qRoKko1beEC280/Xz6FBQ8Nk8Xmaq/OY diZZ/DA3V/UtLX8Ffgm2poClPTTur3AUODzRHPN/C6C1z+gvkInGpFdRFx1Ec5igL9P9rNoFSktl 4HJzDrI5FuBAoBEiTD6btINpjjnUhW6bXIp61Y86qGwwLKnAdlmwYMQ80kFjQ5H5p9pnVOIrjiZn 6KYqxhmB2v+VHYxeBmVyYKvJbAQjUH7hOmhY+7Tnq2p51pGnmtFGQN2Tf7KmO1jnMEHZVz4S5r+Z v4s8ESCxPNRBamNAK9dppytg0AzHo/cdPHSYUNoXkFwuW1lYxQiBMFQWKJuAkYOyx/HFRPNZQCeL ES6Mx7VU4/jtNiYPz3kHHR0mFOcOlRaVC8oPVFDxcNtPm7M8/o0jVXiB4zszcHTN3snbA7jKtbX3 oHh/mFQ3yJ3noLopPFvZYMou8lM5hwBce+FJ6Zg3VygrGKYKlVQD9wJG6qM8ww0kpCvsG6/TrT0G HY3yA1gBHKUKJGzOwttRtpe28QQUnkM2wEhq7yC6SZ8vrwrZrHa/8BsNxJO7ZkLLqw7SOkxY++4Q Mv1pJWzdbbZJsODAt/wFfu1a/obJE6OA6c+z3VDKeIEG4eEqiuE4EjsDt/CFnldv0iAyBm5hz8Fg hwm5h+aYqq5Az8k+WnmCx3j0vCNPc3We+W+qntpSjXh5o5YWK1cBzZepcjU3J1C/r2V48FieA4dh Fy5Rkzv3vQPWVA2zuGxQlXRAm6uhMF1hmCC2/5+SN/Lwlmp45Y7Jho2RfM8e5VhtMAF5PjB+Slp/ bukuBrDJCQzj6oMcb2xsJA5YsxOWmAZTg0wgoTKPanGibDrHCkzdDsI6TCgrmi4wZnPt59L5wq5F rYJonrrOQtNwQBa7eeV6VnNQ12FC6Q4VH3QWbxmDr34LtzMzN6KR807uLuTkyFsgAXT4HTbgWDgM swM4u1ws7g7yi25TWgDGJER3vFUtH5r74Kg/5N//3z/1dSGX390/cJajjxYjI4lknBYHi0CU39MW dbPyOLsIancrx3iMCeiOM74dR1kHbz0bdlV1+ba+ZepBbNG8yWlzQzXkHqVVHtFcg6CR+bTL6j4P a6mB0TglzG69uLnh8GdgAoy1+s7aJwZilrYKh5ilPGIY+sKmxcPwVg43Bot3RZT3FWwY/YZpC2R+ Wjvn8GRgQmG3yivCUC21KNBloBfSE4QcsLUGWNhVHnII3oFhIIq3Vjbwb+Wiek59H38zrO4LyozD i4EJILZsqkb6u3NGSAlmlmqVew42OEwwbj1K5xz+C0yAmcRwn2/R5RCLToqhW2vQalm/agQv44C8 58IAVu6VjGbPPgcjl/dYYMJiBZfVBMOfbCuFDNz8UnDlDl1v0n5ZeeIIDkMzLm2vaw5HBibgfiMB B+jCnjWoqZnlvMOPgQkby2T1nPIFiJJ6TnlsANXMvKMuMcG4tY8Rl/hbNMEwX+8u3HXQ2GNC4TeB /WOauLkt9FNwJi7u2xNyoEst5cjmBysrNNyEAQYN5A2HPVx4BtM6NPtnikLD7zHcw+xzbr0NcA/R XIYetrKRfwF2RfnCUm5j3aTHpCsqLVy7sHGWHuMWiucrdCq8b3KlFXa1fzncGZgAaE3X/iWgv8eA /aj94vBoYII6LyiZtKr/ojtQrTUoOqkvKuzA6BWChihGP1w1A/TRfLyDw8y3U8blH00v38fAfaB6 l1Uz8ALL01STh548pUN5nmQ+yV0iy9/xGZprM+BiCcYR5GG1Jc0u5h7xiNpSGgWkzqIvOGhrbcFy l0p7SoartNbagtjubIao/XLo3Omdwtf8q2q/e/VP/Z/8Y2q/e+293BwubH4OvW+pXJnHoW+FFP5Q 3sPR46LyZWnP3OBMH3G8tjybqjnAFP6slISznG5BE9A9wHxOs2Rz3eQwBjWdd1VgAlh30M4fsu3a RqcqfrX2nsNPgQnL6wIOEgswdfOo1hrUwve5hwpujsdAfysrHJh3T5hg6vpwYJqqMcW09qSw68A0 V2NYwO5n6SIp/YkH2gr08CSfpaU6C+9jNDCt1ZjVF1Tdr1xdcrz/aE052HRjme7FryrXCruErxtM MFw6HxedvPWYkNeh0y5+mL5tO7+X7+cUh0MBE4TcNWPRaWM9myUYVc7UxVduqb9WkServxq3djef OlwJmKDnhYV1XEnNUxuFrjfw6KZqdJUaol3ATVRNvBMIDDRT8yG86qNltayTsxgSTOMR9xo6HApZ TdtHg2i7uCdUdooW2W52u8qfkN2uPADxXfuTxWEtEFxFspwij6v8CerjzQ3BOCqVvr2k2i6N3Isq d0LuhfbTIbDeH+tpMHaqjOJytSOhvLp5TiA53BtmznnMzOMcCU4zD0cuemIy95DHNx/5C7xlzehb tiumtIg118ybPqCS7wulD/JP5z82MdTk522e0nno8yjYyNr4fXEP5rSnDLw6o3zqcCRgAkyLYHR9 Yb92o1j4xeFFwITlPNNomFpDF7lM7R/dJJwPARNs7T9Pct+gwQBjFQbBXXymPjKVRWx5h8zYorC5 C8YVfwsTXjUtIv732l/+oe9m661QA58WvyLkr8Gvvbrv4taCj7H3NrH14Aa3FA5HyUg0MiLFEtHX X/Er4Z2uSCIakUn7mWhMnDAvo+QEbh8blevr2qMR4kvKcdIWHRkZl2IRSPOMnhFjo6RLHJNiySnS GZOlMUydxlRPeEyM1dd1xMTIu6Q7GpemxgGZGpUi9XXd0XExEpHgYTFxfDJeX+dLjk7LY+SMGCFt kpQYB+MZYH2paCJGvOH/Sskj46R/ZFyUJ6Jn4hOp+rpg9BRUBAmNjCcn4VGvvj74NjjC2qBbfPfd A6j5NjkcJh4oOtSD552pMDRAQo7ilTeSSMr4O1RFNJaIiXKCIKUlfAdYucnIqJgiYgJJLMkZeAg0 A9bgWBKqv77upBhOvIvnEUi7dOpUCgW+M9hXX3f0SGKcQJXJZ6RYXIylQKjCYWkEX9NwbGQUCtgJ N8an4UUgbhF2BxJjUyQehXfiiZPDx5vr67qik/jGRJS0JyekA20BRl5KGvzSNHGNSQch/u1eT+9A CKo14O8MYbQg5kVwBQeh7J5AsNNDTmJsmIAfGsPngl/xCEqoy0sG8aerx4u7mns9Pa5er9Ad6EKC yx6XNzg4AOIe8JAub8jlBSC06uHJ+rreFPFF4wnilhPQND2eE15kwQzCw41A63hqEKPItRvxdyEL dAJxJEy6olNTUN0IGvB34Jf19+Oe0y6PK9gP6SANg/CrH9MEEoRWgkEjTiXBFYbW6ggnE5A/mErC A2USEifEyWgiSjdvt9TXxaehA5KYhJIEsBPeYKfXz17XAQXwBHs9fnIqBX05Eofne2LyBOkbl8Py VH3dYEAYDJBeF2kLtLUNkl53hycYhAIJpGsg1HWwItLKRKQJxfuAeqrbFfIG+jwuo5/AoIgncXsC /2n/JrAg+X63B8QGhAcpAoLwe5crCBfugN/vdff8ozsIbe4N9pCTXS7fQK9gxH452ApiFFgNyJh7 IPOHPCmyoQKqyec54fJ7XQ0rFXWxmKessOX3F5+9haMLjlvQA9yxaDwepWelXH7c4w1C4/b4fF6Q lhgK7bsi9MZoONrgGhXHZJzzQiJMFzBnyGPjCQAICXlSCktxGCkHB7p6vKRnIOjqDfQHkDGeTpRy BMRaoEfduz0nPT7szH0BGASxq3Rhh24nh0CssYWCjT3w9kHqPux3+V1CmyeEEXJ8Plc79HV2lhr5 jWlgPJe7PwCN2Bf09rp8JOTGPeoH23wsOmnD6WQcKpnOAQfQin3RZFiKSNAEfbIYiZr1yP2Cw0gT uxsngdiYiA1u3ITBYyqGe9vjSLoMY8NAJ4wVbq/bEwyQ/qAXqq9fCP0HDKpQ316MHQs/YhIObdiI fhH/JuCHNA2XQek0zvNxiYoB/JiCORCegOrJSfGM9Kp33/VZvK60xl8pVfaAP3QoaJ/7gj4QP4RF g2L2Ihl2m7fTvNcba2yTx/A8YrtroK3fOgPjj46KyVNQASDNQWR3M28EoA9NwPQPNeQOBPu4ky+h kWhsiqkSJzCGA/fnhChHMNXf5eEOupwQI10SHp5lhNuD/s6TXu6Qy2BkbFqWesXwZDwhSZEDaYDm A2kAlw+E0Gs1gCssj0jEG8ETHTJMY0OHj79Rnfg2aGZQy4Pd1iklVNRSoMpKYTKEFQQI92Bf0BOy Tiq5UyDO8TjpQpUOHnqMtIXxEAzT1QDv8Q+6hu3DS55ISkTcm6QPXsk0udBEikzLMImFEmIsbozX mBWa3Wc3rgdaPSyCBjF0uPVNcnJcTkSkFOmIguYdgi4Yp4c/2sJJCQvi87kDAfvEE8gOklSTbuPd 41IkOgl/IwD1e4MnXLZI+OUYKAL0I1tIB4zL9Lm9ydHRFGkTIxMwBpymSSfl+PgEjM4NPlAs8Xv7 Bjo62m3h6UuePk3aRcxnVl6o1xXqso9IhSbF+DiOHn3JyakJq1l60fKBRgEtVZYomTy+zhs5LUfk BFSXOAqGBBYy5A8E+uwDVaFINDpF2qNjYyn6k7UHuw4lUmEJswx42j32KcFQUhqVENeMONIL1gg2 wtsHIujHDkbQQ13Dh4/bI40rPo4FaiX+pOAOS2KMhFCJp9LtglnXZ0k3NOcoCUpheQznF9reWNGd MTAyguIIVlfbgLtHsI9Rk7bkyIQQEPxyRGKS1D8tRRIpwYMTNOlHQw77iA+b2T6w5waxxY968zio wJFRbFsR2jYyBth2mDA83AgG2i9MR8wgYt/kj4IZGhkZZz2iZZg7xwddgrSw0tJf30aLx+PxcwNc ZwzGLRDDlNnK0QkZS+YPdLw1jMLq855gg+3pd5j4eUmXhOYs1AXIDRS4sbERRRwyBTo6Qn3cEb/A 6dPG/Ad98rh9aUOPvQwKn+ualGLyCPQz7Dcev3+QO7naJ0UiqWk5Lhmj1KloEuoWNB+UX89bfV48 xDpsCLD0DkzN8UQ0jJ3nzTeJHw+jk17Z6DVt0ImiIxO4Kk07TMfAMHfCNRQ5nWQvQWwAGvX/aLuW 3caRJbtvoP+Bq7ILaBZsWZZVvaNeFm29LimXy9W4SKTElMQxxdTlwy7VQv8ymB+42xkMMH81mOWc SD5TVtfdtBtGl2yeIPMREXkiIpP6IhPhGWMKVEb+s4D3m0sahKUQHoVKXduqHYB15dLngdGjBkTV jJFvEpAnncg+Y0SLj/MIyvB3olegjIercoDmIHYvfpzdBB0Z8+gfqYDnkcpLvYM9Nt7FHkfTh96k 77rVyjuSqfJYWPn746ljVwaItV9sZeQjWMMqNH8xuiuw017EtxwrShKfI0Brg/RN+o9Dew4zHHf6 uZdGXAyE0f00Nsi5EvJavaygN6y91wP/OZjPoQQSEZuAbiGUjGKayodJr2Z3RuYm1tB8WuddFWDW /3PBrdcqKhzUVov8zOGAv8g0wvTGlCxw0ImOgjrTGpnIjydm4amK2LAIRtzLQltrXjMsBeVJJOh2 0Ji18PbvogOX76IDdw89C9Z/tKvBMO5Sj8fGjCY8yVEGAgqEHabREysRepgb6vKKgw9QKk2I140A /VikUajG/46/LujYLkVRDizb2JCvinwsYyugs2xADKcMFw2CqI7ELmhi4D1hg1th8MB/UQwbnzHI XmxwjPNahlj0I0mscqIsdwlAbHjyFeoA+33ZG15KqQutocRf8saa6p0yZv5uGfWWLef8+verq49k FN3efZ++vua8+fvl548qjvqSvdQb8bUzf8LfG+rvCBXUl+PdPtgqqj6/+r2hNHvavVfflIn4zLAc Ul+VNnmcOqMeQFc3AE0f5sX31nWn+HPr9wb9+dEe9bKD0e5vxnA6/9B1rG9P9P5iF8+9oufSe9MR lFOrqYkNZUvde/qaPPr9RkX/E3vStydHh9gVZwqJoCw3xoT7AVnX3LHmx68fUUaElU2+8MhP43fR 54t30eeLy/t+f1bbX/MsxI7WsnL6PwHUsDA+tW01IFN+GMollNGAzRPkyhpb9RNDHBeSRKiX2iR0 mpVAzY7VqR8WWvDF3lhHHEvauZeKxHg1iaIsofmBiD+SyPV8aNfPDiUbPzbwQ+2jnAFhWiMiBlUf EPSgC/A/dPHmsd871DbwvgrD873wLDFi8MGMp6/8SN2obd9OD7Ximw/joaSo+A6HBZshzGcL3rVW cqPGx9KAx15Lhbi8gJIeGvUmC2VsAhQfA3LGA/GdnxHy0h1ah9ou3njDsywIXWzAHA61chuIlcGJ MQSUvA2MczTJ/06DdHk1ehgdagW3IA0CDK0wztdSeiEZ/W/Gdm9QGjBQEk1qY63oRm2MKI1M8+Wp A/wEux5b94dawW0L92TsZWqsyHXhjrQ1joCtYf/pUKu1EcNa+1FA125G9u2hVmELlBPi2RzC5Ykf dAsVoNG+mvnXLFBeqBDt3xCimWs0CI4uMcAzYuNFBik8nG3bn5LvyXsY2+d3sbXW51G/961cO0ZY vr/Rog2+jM6U129OXv/1l5sLdfnzaXECXI5I1S9PAr7g+tVw+lARg6FMY1HGfEMZYAW4uZ4Nnyoa PtvsY3DZgCKH1cpPfCBaiJIrljBDjCyw6OPCZ3syrzgBsZ5NJNP1JmOgILpg6Fja2o3utFcRgq70 OJEKGcJHRAiwf/3l802n060INn4BGY7jLPnRo+8MqSg1COpSwtR3G7T+rj8YdKr3wNwJhKkdgZX0 j5trxM/y1ejs1b9EmOfW02NFmBEb7l+54sS0IiKwMMFO/IVKr//1CtZ+FwVrzKwuO6sCxgZY2DKL 5hzjgXgeXEgPnug//ieLGTvTJz1m7EhEU7eFtRFRRdygrO2Sor/pdGTXYkZKPPgyCzNu4VvgUM/i jPkhxqEQ0MnVEdGp+if6RO/8IImGUosuVCT0l4AOHm779WhxkK6FiKvYlfJf4m36Q89/wAMSwXa5 7xn3IXGoJ/gq6B6FhZaLsano7YTnd7cRv+DzI0huIlTaZDqfOjV2O5GIgXxYi9Hx11mw6YBdKWXp qZBzOnlCyFmLHsP99zxnxJceX6XLdAfY44M5t2qR42NqzjFsFEWH2TQVfxlkrx6DzNdvdseuhZBf f/ggfVmoCWeJ8PcHzAefFLX78S7x1M1//t9fr6wPDXbWviiVFWH2Banf3/Mr1QuFcOXSmC4TqhIX V69KJcTVK+OBWKthkW1LT8VFlHkr01dKpHKMSuSRR9WVq+pKU2nbQ7iS0VokCV8gtBr4SvVycK3F N1QM36QcrkLUELWWtw0HNCjIkl1D9RZDAn2u1AszeWlYy02SYt47WLVLSKNqMDTpG7yn3PHqatVo yvvJXXalngP7oydiNN04pyxiUAxFz65c5B/Kf2IdRkB+BIMJlN7xj2nkr/0QC4EKJZWfjpVLANC1 q7zBH9kt4ndRw9a7OM37qTMxs3Ry9tF1H/pu/vcspXYvHVoPRv4KrAMOTvAlLTcjezyDbdIgZR+/ 3dvzX38ZW12irDQk6uOkjxC4l+f6M10r0/4m3A4WKP/QKK9fa9ezy9AMkK7ICPHLZZFsVWr2JtEK L+30+3mydgm19EzQNPh8Yxf5MZX0ppZru5lySR77sblVvHQXUPnHHVlP/Uy34oDvRWRGwl+DTi/I tMo8LzUyzh+9y59sck9SAegRAbKZqdgrj3dmFpT+9epQlXeMf/77f//vf/3TyHf5jIyDMfuLEz+2 28+DpJFMsbiZEzBhL9vJpC6zPDxSl5kVbcFmZLg2Hzc8YZw9SnJRqzTApyioCxZB07HgiLMvvmD9 kFFxqRRg3SKAggDrquPtvjA7Yo8nMPguRoUCNsSK9UOGhRj0qQiiKG8QLeTeRENIsxg8HYMHYI9C PCP8L0XsMqaCiB+euTspQ/TAxJrD1Ju7NGj7FNRNt1sRMT9UT6ANErnMw+jBLCKtUYofk7KRfpSV S6iNBVAFU3mPU9wlYl8QclHBmX1gY8TbfMO6PBJ7sx96FDuxN9LNU9ImwdSATUPBwBPOIowBBbyZ 6NPkySlis9E+3Ecew6JC/5oubavAEG8FsxBngXJkMmOrN50UIdsY5hCG3OxGe+XW65A8VCsgPYlw lAGo5mKMu2LtoTyPdt88WiuEBpH8IUIN0NQAE/Bd+2wLLhGA8pKPQCfPdxTzXv5mND5qoi1NdMZ3 nKlWaSC9Y3NYADR7IV/roKbeNXoDnNJIDdM4GiH+I+s6Gljgxtbo0Cw6tOUB94TpiFW+uylmcsXG e0YuuZJwi1ePkUT8gXoRm10e+Lh36PO60ubw9hu4zaiCwcjdsgmi8QI+QaR+XfQthFEnPGTziIfx Ck4SxIWtIrllE/GKXkTPNV0fW073qXjTAxR2uTdmcK3riJZSk9L8xA26UMtKwLaKdz7UNRwKjwfF zPehJKFJeqtUsXy3RS7ZeiNpWgGim5gtBI1aXR2VQPutwFBEso5pXZzAyFBoN2o13oLKVrKe3sxW 8wR4J0LlAzXgif58UfUE0oLK2nP0ic6QWcs0oVmtoKPDTdWnYB/CmYSx3ObWnb3EsETfs8NN2bln huBiB12MTEs9n9me4Bq2eQJLvmYE1w6Hzr0SPbcPN2UHE/8ZNoMgLJaB54uoRD2xw03ZsT38Pt/B qaJ3GDAs3pguuDI/fI7ZUJxBf++F2OFjeQO3bx7aRXexfKllCebGHnlYGHnfmo8O+QHNMULAQK5M 23iUaeAhaoSW7hNFNRCcKA993kFQT4CQYnvwZp4UTqU/h/nmBzjHIqGa4JKbDfadNTVE6xjxVb/e Prpu+eQpSYX9pA7Mj3ZWwE4A5kOrW2nBGa5xhOumkQ44bnOfhpe5sE5KdNaRx20fwEWxRDK1TUBD HveCbItUl9bEynaBLQ9eVNh76kQo1chrwOOekBNjMSJfDdV8gyKuRw+fpbudSGINfdwl2K52/bgj M0ncgY69Ck8b6fLkRYV14Ot9HXLcBTIQlZVidxhC1kn9INEEmicEKCHKXzHwUahhWyewWVgHPqpD 22+guBkjJuJrwMZxnx4SP2B+wmJo204bysZx3x4x8Eof9wx2Uo1DvzyYAazIsJNsulk/wFCMVRq9 uLndHZbvfVCbSEWANSFIZAhv/Mr4lvksxsyCMnqkjES+VU9095fdpn3qNpQ8YbZya55akD99wkwk 9Ce/YLyZfMFidPnHDVw4J2eq7hGD8FaWk8k1NDmaawQmZofrd2+eRgn9Xq3TKModsztx9OD2aTAZ LIMmqzJ2XaB5cVKgD0e9Ya4sLTIDn+7WUPBA0cwa8c8FTvdwqGruew15upc2eXos6cRr9Xaf7uhd yX4U6vp076iSFa7hJGwsiTJelvwuEzrdSyw+MaOdDFi9iddoIs0/EYnoyx0iDXq6o7RQWaDnMAww bhlqnb3WOzsSPAI/hO5TEdVktCydQQu5NqKtiz8RikjIYp6/Aq/D2srio2luNX4qSVtnA81aW82f CdDer31tFchEWv9SJPMQPqOwPdTtstX+mXSeWmRY0WCmRw+++emw2Fumismkc/zNNN/8dGDGfO0v NfhPh6VwgeTCyvA3F2z9bL7V5jsVGlS8MBP76ajMYNLaSLR/OhJqq0PiL9mCB0sZ6pI/HQcqzmdd gzdm8YbYFXsOdSNr62Pjii2eIzGGiGK0QWxXYwE3Y2TPory0GovGNW0X8pNUlAp5j/WmYFX+s/hA FGQs8JjQX8aIEgL4+QmoE4M5w4n7EV8Goi5cMC0IIxzRxRXB9V+oc09oifbQgnmR3DTwVr4IPJN2 AKlqIHM3CAaLMZj2+uXbNcbSE1iM5zygZIVpYbHHwMfUvnyr2bk7dVX0SDNeENDp5L589cZYhs9C xJS3UJVNoyMCn2ygxM7L13AAS6uwcScjj4dm9r5wx/eKMZhS7aogaVJ6exXcxuShsH74gSfiRIsz aVdQ8TaOsYzQ7H5Ax53MgaDC3DoucfPy3RvAYSVlQ0QPIkEAS8VqiraN8d7o71XNbkV1uypcdqhG UNC3iOoUlE/p0FbOZFPHsTFweVcjzC+xQfN+H5XM7MFxDo2CvKVRxPcII7inwjhVYqBkTgcLxLPM Se7EoqJGTuYmHITHpx2ewtSS6Dm2/0h1kqybFCvPaV8KFE8dCygwX2nDUCvHfE/QFWl0KzcwsScm AFkv6JeZiFZiSeOerguI8+XQyPlavu/V7FA2VLve0K6rF91bsaoZWZHQkE0NaRtDcDhMRyyClQrf KYyiYpAm1NKERsQn062GaGsId0uqF8BEDNqTDc2jjYVJXeJK79LjsO/0jZ7dU/tn3FG/PzNGljvP tsRkJ9MnUwadzUnXRLKeTBeJ2SsXuJmQu3J+MmzzCKvyU+5O8OdzK4DGhDzxS1vLZVp/KqPB2jqs /31JfH+Mn6iOy5lXiRvy3W6P9f9VAx31aSj2VQophxx15S6NKR17S1sT6rCj1rs7mDwMWixiDXbU +mwvOFiS2sJVR14ftZ9cYzfwtwsNdNR+2g6HNYVCPk9uNWTzDRLRm0e2yEG8v2vYo74QeYIPwW/M LnTJfZoAmPfGcPfhkiJ90mFS/k4ZwFKt4NDIydJUVQsQ6dMGEFqyjFdwK8M2tiXPzvENDU+KMJIS AR3xbDTZInqZCwwGLgSy7pU7ac1bcDxmvRbkZDqyofs5K5oipvE5ZdrISd7JTWh+hS14+bxPxz14 h5wD0S/2SiU6RlTWzyEP88GhkXOdaZpkixG58FrmeWbd9gHKujLja0GpxIjD7JjLC3o+s2YEauag ncAd+FKo3LJRBQgzaw6XlhOXGQK6PXO3cAcZGwBrzpLWTGlnluPoh7R3ohSH18wJDMQx4xgf08JY Baze4gfaMHSRw9LgA/2PK7NQnzRYo4Rxptz1I0URWHReKKsdZAl7+bqghONtSblz4WYpzMZLDAsd WAAdeKQFzXRV8KU6VB8CJdg6IQijDJ81VLtCuf4WAUAvDZeFjmWYz1U32VMKlclYMUUgNNu3sqY+ M+sLVqjPRY9fwF2TxKfpTON80Zn1Lap35v0CeQEF4FvzlnIFxKcGwV4DtiogI+ATnWx4hZJ5C0Hx egF2ugDn3RHREvMeCG8t3kbJvB4nz/qY8KucZsxEQjxxx2gqEJpEsPtAPaRi77lA44RAR9D3mGmw 5glYVggWS64hWyeQfcrBR/6yTHDn2HaJdQlLmWrYMXxonNRxl6d6ZcMpZxlqtTeVcfwYcRpRzVJr +2XjxFNsCvA4VEUbvstT3aSEzFZGu42Eb9LQp7rq8iSNyMOrLXQs/0I4Tax9SozqIi++x1ne9vco fzb/rPw5Mw7G/K98IvXUHR5ODpAq91cDAtipAaHVD7P54r/IqDbqZe3zCC0ZaOkOSlDy7hx9Sr8f AKTv14Hn9BMN3TyhKmpqvtDU9Nn5fMMjaI5KzvCsmIS44qN2k9aJm6jkuXKUNlXJVNa3J2IRqYJi qVdDe9Qt6qJ0qjo79xTChimfi6WCzq7YYblhqhJjRWmUxFgplneTvPPU84rH2JN7VlRIZ374zAaB 3HvFQ1gHpqpW3aybkFU1QOb7RUfHrGcVRVL6hb+GGCc8x4v8VcKwyKqzDBTq+HHxVCzJ3aI8OpN0 3C5PZdBXTyUb5YQpZingztwpKqPF+w8oY2n0hNjRfl61vyGo1rKHweCpqJPSebM9UwfOPgxoTzJT r1g4XwmyTwo3Ly8bH7N0WEdQVBOrGLSggn97oJNDOQP+WwpqDTcKluWpKmKVmMhxzTouH0UKfzq0 2V4NYy8tfFou0qqJdPzlHkEzo4NWGqhdB8mN2Prw/s6G72JZlP4yZE5+M2RWHUXwkARZjWetAl8s AtXKn4vVO5jz7wQ6OxYVcc6R9S4OFKFIEjheTxHjWIPWuzag417a1Xqf6Ju6KLZnA9oYArvImhiR 0dSFruvds1UFStVN6PADo4MRGrjeqXuVMGTqFw1U748iHsfl4RxX7wzGhNlnW6qS6aB6n6hSq6b8 tqwFZ6hWvRMO7FcCgh8NU2+7S/5irN+j3mwXSwuopcDSN11BLfY6tN5yYo0Lyj3AUx4rQave+keh 0qYq+NjwrTo/XAffXOjgR4yvSqMd285NvSf5XgmqwlG2YxD55bYRx+rZ06L6qUaFzqFAh2HlBcKe dIqKpwOHtpCvKhj1l6lSA6rIBQV20nsq6p4Oj8TCp90X++0OHiZXqexYVM5m6yei/OJElJntDlRn 5iIf5KsQnMK/50xW/bITwnvla9BNlXJhA7Xoq8x2nqzRJFunJFXdVSpSp7mgXKZ9SkZtpPCVoyXS 7aS5bjuDkdUtSpvOp4EqU3xgs0+daK8S6DKjJTbrikAsIp4IPfHp2N2hVdQ8HUomRh5tmfmudJ8S wIM6o8nhzbdwRz2HDAXWmlQDYXex9ORc2KFlxlXhWxZP3dGebYH1tQq2HXtusaIe6vgJRR5YOxQh FqRTtLTVEvzOtNMpa6KOXCz8TEd9vo1N8hRlmAxkvyyKZi8U4kyNmHIaNBdjCkdWCUITqoexIaa1 Ck9y+eYJebKegR9B01V9o6+WfZfTPo80gq9bCu0Wrfot1B0+IExYyH89af9P29X0tm5m57/yzuY6 AUogcVzDs6QkWuI1JWpEyhpnQ9ASbTGWSJWSrqK78D9qOwUmmNtpgwlQBC3Qouiuuy6KLtsi/Qc9 z3k/aesGWSSL+MbWcySRfN9znvP5tktgJnEvMSnXSb0Qya44kOFGgs5Zi3EvM8lWQmUapehJWq8W 0v2lD9I+zCSOIpN+ndTy9pCpqApwk8fSXNBvA5N0ndRfw+cAUx/CS+X375A6cNebFLhsCdBCrzgT T1eJG6ihdx2TeZ3UR/QfLxHR4pZ0rJx8KfCo5fGTTH2MZGZSsSSZxc19ydmwqlW0oXDnr3DxMhs3 BXxwx+OaTEeZycTSDsx62TDresSXnqQGMPmj5E3fMylY/JLM8+a+5lYHWg2l2kyJP8xMijXJ12Te avAqMsgagLCzYjgJ2cBcBNt10eSrRa5ULMd7TbKnJXZuxTIrpmItxN2GhWJCe27o25FpbslfnJS3 mv31x058k22Vs1uG8yifL1d5JStmRLJvGm4fbElcWYnMTHshLeZXiMUTNZgj6e3x1iLtn5C5BY+4 1+ZPvs3FZ87b3OZ0q/NK1d6AweuhJVoEUw8u9C16h8lWfe5+RTna6ojCM/oJ5ql3hBK5cEQyJaII itmXSTeOTEY2mdcrtqrEZUmPmTXSRQOBIkdmcocuwoL5PtiUrQQrUmTB3K3xyo4o8PkL8EyRWZxq +mjfNzXJV4LuaFXMn4rqfUmbkp4BprnN4fUreOBHJgFLNGTljRsUALNWYtJ7tKsh6E5M4jUp5rSd 9O2CSpWlcOSQu68oyQGfFKsuFpykrump1HuTIiDEyGRZE84skdaRCpI1brIuHezMJFgJe+DZEnTH EJmtjqJLpE2gTlPD0WKiqFSyJOVFiz/fomrhWqreJkN+hdi+WRhS5OqECNraH4ypwjQtkz8lYHMk 1UVbnhT+mpwn+j/VwN8rdTZOiZxbEVgFyMAM0qqrUITZwl442JXE8k5FjCLcIv7GqtYWmCVhdGtS pkm5IjBG7zWefy/j7ho2jE2KlENu4g32zMO+eloVnuRNArtNqIcliAiYrc7SKvDI0rTBpTQtuJU3 bLb0le7JedUVyUri/KQEfSC3GWBB01dGe5mRGpvkKEnR9gXl80JOhQnWfuj7OZAFQauX8XqU4KUj mEGQx7JoyMimRpOyItqaxWeYmlc3JhtNtoh854KzuXZL3gQ2L5o8kSqkTdPL35Uy7hHIC9m1K0CS m7BnkqLJU7kgE3XgIiHV1uqiLgwqA+rzK7pZ1rVRoMs2KKQLXBdrYiHONx3GNybTmawxL8NT+Vrk 2bIel3PVGU/PUSJj2o064ZlsiDPm+6wD/3PHtb0ahWCAYl/JBrN32JHkzN2QLHsLdmFh0t/0zrP7 AoG/7PMW8PIVkDfFvf3UkclmJqiH7NXzXU2Mn8kJWA82B6mhQjFrQyJI1KY5SbSpH49N7sF57dT1 DhtJf0hKHFxnN2m9zItj9hsvPXABH8aJ6BI6Ak5MapMX1rLc6JVzxjF02s/skE+31iFXYpdtMRi6 1utX7dfJV+PquAzt0E6tcZIGgcl7EhUsVvI7eqQyztw4PgFtApSAdL9IBXJiGj5xKGkd18M760cK XThCQ+mRd2hhwAhh6VuSp/CXBl8WQjZCeCj1x6jJFvDKAaqOCS7MkMSbjb3G48lr7gSHxAuqx1W5 Xa65NR2p5WPdPLXQ5w6aiBXdCu7drknXO4EnBb5wwGRYNjqiwHdTIyd3Ju+Z7JrjBnW4INE7Yz3S u9+anGeyO37NOeYMDN5JT0iUpjhADRvoy9oQGgk4t4BkX8JvyBdk4Jzy+mTaiUzOMyE1TfcNtp4e S6nX0xQZK01f9vSddw1ZYUMdZZTCWZ8Sf/USPygXBaKK0iQvicS5eM1mLJ5j9NiA0DYOnVf485d4 WSz9iO5jx01LppNrkw0lwvmAZFuyrA8F900c1HJtHKdEiVxakYZWKj3QeL8ziFuTDU1UmNojIoBn npYmVylxmrtoHDen0qqYLxHGjO0anX5pU6HJ/n0pfrPPd01NhpW7dsg6NRh8mOz2a3pQ1dmqUqfL JLNbD2ESKYlfzN1K/eHQJELTfL0mJ+ZYST9rB4f+/iivf6gdm5TzVYrApKjKYUJ3jf/DndM3ATMR TU40LebLqt5xb66HzrJsumENaioI04Asqs6OpsV6s5ODbr0+ET7ujm3hLl7haC/ZuEAaoOpEsZS0 aIjdcOmfh3AYuj1UA1GiQyPpIBiYjKhsX6+K46IpZcRnW+SYY2B3NeEzkxrlJin08KmUwKomnYw8 ctZpoc8tumwWZMz2KETSP1rQCwOFLvb8Nd3gamsIkkJdGhRZWsQyyCdEdJnzXxw5gs0i79NWEyjJ K1eS8DJWGiOo39g8sQT/2l7ldflAG6JHWqBCu4Q3LMjxyfy/2POYkpaQvdhrrJ+03sheGGiFQbHa ZLLYpSVjr/omus5MNP5Ne2EiqV0+lMWCI04++RyFbjlQ72Pvy3glq509MHBreBTu6jUOLIbIQbHb GmUEBu+I6TQqxCZ1/QADjLQVpNm9l8GtsGrJ2NtBOolnf3gcIHGj7gpq78ItZ4DGpFxk0IiY4tJE GBTaXit9WVKF3LK8lYVmuA66848FFoWWIqKic6vpktYhrg+ZGDK4g/pAQrR2+jW0alrTstZi8dCk WtMl0VbaRll6KKWnumip+HQwCUxmlRZUgVX2KKu9PL86EdJ3NLISvjgp/LbmGPWL6mclcnlS5PWH KaHw+tqkW9Py4SGvjrRAuekl08FD5OLsZcWkK79QXAheGJQKkstvkMojcrHa/qQ3OP+xNxjWFep/ dAVoGo9CElF3g9QnbfH8a3iLMi1WuKZPgS9fg6cVT4J6QTgIf0f4K40/Gnwom/V0KkXDs/T5iy/0 9dOD8PwHjKZTL097Mb2srm6/4AJKRGIRE9bprXQ69gmkrme/yedws5/2aDharZr8fd20gJevgb2C pzti+hup5FzslvtHMfrVrx7zluTVa8nr/fxJkCss7s5yTS8kWnGlFjoUB2aMonzA8CvUbTzWO/rA /pLUUN0SPz8hfrYWqFUk8ji0bW0Kf+L6acNifs2afmDyBX1WS+LEjYhKHrD+VNJV6Uz1LzFkGMUB X3ysOCAVz+LuZx1SGU6Iwr0eiCYnVoYTQa+Oo7tP+pPATzGFeRCmCaZyBVEUz14P3JKjabiaBuMd 5fBaNDAPTwzdUkP43hUoxR3XG91gakY9tJG64ZTH6hEyEJ070Q2iJIwnn8qgxMgOg2jL8otv+v7k ejq6CSJzPZm6njRM/VHYFSeFd+UOcSwcr/JPf4mD2E+i9IuoF3nrj4LUnaf1NidrKkzvhDISbmAc TnPgTrr6uCOORdp1h1i1FiqaMHnmRQt8cRqsHFys7MhU6CqRy9Mik2IBIljqYJBCX51Gp9AXPOTV RTvDrlpoLmITixpjvh5rgUCksKFWJfuR627PyJES03OvF7oTsPAHOzPDgJLUnX6FP5Crzq7Ors1c p6NuFLjTsKYVigWSfG20OActWJWT1k4KGclwHvR01Asmz84RNJzgPMDAfpI2qBHZoL6tevzU66CR LVkRLVYKbToJ/cGzcxTNlNtkB0Q+iaitXtSyKvTFKbR1SqaJn10/O6fR4A9wMqS5QbAib4qXEbAp hzSd02mmW3pQ3ghrFhXVRMuVHb6lvZA8OyfT3OYYupnbVCDn1onpcj6aWwFybcFIuB88O0fe3vIQ tHLrdZf0hOodt5Lb1U74bPDsHH5L+GyQr1BS4WSXboPJtPvsnHpL3G8/z+k5rnZb77ZezfOqdqsp bmPsTuf429uarnRL3zrfcZey9/IPUm7mR9H1s3McLkp4HqAdmSUXXJ3PPRQaP+pnz86JuLSQHrPu 0pRIcuHAEjfsek+UUKYjtexkYvqypWzT0Dr05EgsCwqenXNxASKF0ad9/bhfmd7GWZDOgmfnWNwZ 6S/1n6yPJR8Y1t1tGJsN/KH37JyRO1vSxsDd4MkOs2W53WhqrLDnbWwrK6wgF20IUyp4gLsW6rKN whJS8zXW+baFvGojZ8jfE6EmH1kWW6oKVC0T9q+fr9xLKlWGvFM+OtEyDIINnq/c60GQJyp1UyVX 5C7L1aIxz0KKXLwQSSr6Rh6n60OuhLW6Q0lcvpBIkZuUPSw2JwrsSNcsaCwmk6NHF7TTDArjA3LB 7jRNm4VRFD47B+7yViVuTZwZKVhZjYY0RevLkVTinpDHCWBZKT2kJRZWwmmuVuiLU+g+M7kz8bbE iHBugtG17xAzRQtaDFHvMfaUh9kImZtumuVHXlSoPcngQGtuSG+UxM/O8b30RvCyxkTw6ONpAZG7 Gz9kn3/22WdZjw9uUYJ33ah1xN4M9WIP3K4qK99TfKURfQXE76XQnX8Tts7cu8ufykVORmObH+S4 CnyGUd13QeK1zt+7Ixc2PlSy+TuiT1m1nItfionKUczf/evf/Kf4x//+4/99+I/v/w4cB6duEjsF KxXf/sM3P/ys9arx2B1vLEmW+bRvfvjDH7//rw9/JX7C6cPi/M+zIR+2IO8i/brWi1X4SRbFdiqq v5XDHehfrreonXIv0QkmUWjpXKdoyIGXhT9DUzJpI8KET7kz3OB3CPeWC4yRuJbJVYzmzk1qDDQW U3j08+6iXon8aigPZBNpUbsBHA2/PAHn+ApHVFvTNQTOMOpbfilTzS+tOqHCrm9nqJK+muePdasJ oxV80ALnbQE0vy10QQAyEkndNEeOLjq3qRuOMM3MXDTSnyLKEUWmpcfWVyD8JDhvJJAWEteaiQny FM5Sy1JfdSyJa552b4gpVz/KnawAYZaQjTNcNBTbA8byw6pdCJNrEW+nw7FHxELB3u7XG+9Wa1l6 NUEl+YV5FZVGdFeRYyL1MVVaQ9AD6/mWZUZ0sTmp0IqWwWInY2t5Q/pnVOAAsUJF9JEOzSzzp3eJ Rw7/hHUpVhmqvcrCTFCygVOFN2SzjcfDwWPFv8MXEucnJWS4J+WWl5xomo4T81DpzFJNOVVlKwvC HIIgyG3rxZZskktHPl0OoouGrcjk7YQaNXRlgez7RTm97QqFJxU5ZS2sYZgGi+EJiJyY7IYYco2c oZM/1qErZCW3oZIna7lRj12bWm4hS/AMrfx4EV5pq/AEUte+pZYmed39ePLaTIIQSL2Fll+2k2+h 7EiS9cZaYBqlviWYyX5FaohrVhMMmSLvqCkSru/WF5X6N/RoDa1krRdXdsEgMjqxjFIygy1mmimt tzBTAkSKI6Esq0zrXY0KnVJWfiP7YqPGDM58o70Bznz12oy894llj1zNkD3QhXpp1NUYJkCGPr6k PygUguuL7c5nwEG71I1tt9VvcNl+g+wlf+L9Bm1r+JOWvPqIZKjLQ6CMZJZWFwWrN7iLp5PM0k6m MgUi49wTKvysH04s2cwzDGuW+bMcbWXaxvX8fhibO5jLNl31FuHElsHSa2XDk0dWR2+d82A5R4t0 /O5NP457CntPJO7RlKSJrg9FbNjinJMOOyyT9ZG/NN2bB2fNdgfToXOqKM6N1CodZ3dZTigHWXtz cmKISDWm8kb0o3hyZ0ng4wrtDfQAnK/cj7MZ4lUaUmcHExYVg+DOezvtBerFZXH0vtovjFm41gEn frXURvcmTBKHkz2VpGpVqVRjYicademg1LgADYhv4qF9KE/1U72utX4aDjtMf+Rr3337t+p8ajEk M2OKPoVYY2OzG3iP8gjnwuNekDmnHtdyqhE9iYd8XerMthj74A+GQGx47AKBnDca+5PQ1HgCQr5U WVTEMw756gmlcBoYzwLn0OMNyEc7f8eK0TnpuFGKcQ3FWKli5lZ7lpDFLoYbbDlR9Fhw//rR7Aat 00Z9svWJxpKzTLbe6K+BnzoHH+/kQJGDrkBn/eWcdwxGtIYXeKAb17wAnTsg7hyCt49JEM61mlCi hH7/4bt/+f7D7//NKDXUtRoasKuPmRoWRvuOB4gp4HTUmTgnG+9VTgEDiCztF9MxJkoa+77fZHN0 2vMNRS6VjOvKE3//pw+/+/133/zwp39WYrdhNxilZp29K3EWgFppM75fxpQf5P3ab8zLmNZvLPgB rm2YPXCFNW8Ju9K/jIedMDCf8r5e35eFfBt1bIQ/6rVovutjiJ/G91kbpn4UmFMQfFI+K/VsDvkW 2qixURLhB5M4GVriX9DmZa/z8y88f52/t5bZj2b+naX9sv6TuEr1tn5XtjHnLYytEfVMkafGj+J0 YIm+blC6121eWFkH2DHdC6YngpFTcY3i0UvjVHCsgpPKuY53ik48CIaW5b/qU/Kc5hsCJ6lzYEKn ZuM0lG+bo8G11Tih8ectfEb3jKissQUTlNUYSp+jGABs4QhPHKcRI/mowZM7VOsYL6Y5ktPvmQei jUJwTQ/X7N9e8RAVG9JGC29w3DqlMcohMBtZEui52cLSuJgtzOHAjE+zwSBA+RzMjEONvjiJDuXp GWS7MTVu0Ra5PCky3hPHQZTJlliL3nTijyyZ7+3J0PEPL24WZYVJga5v1mNPw+x1dLGh0ovTs8gn 3xCR06EuEYxJDVkaH2yILm+Wch5dtynXppZTBNNJPLbUPdg39aZA0M5MFeFjOQeWtSPcusSgN9Os lXNBo618xIktQWjpO5KS5WPFnFRSH3ZsuBNT+QrGNPuT1HJ5Wf4me0qk/sHIjNBSeBBq8twea8Ft pJ48y2pbmd5FMYijXmp5PPLnfHQFXGY5Y9xL67S26LBnKbyqC3+1jQdxGkSWtA/qHbkRdlapZhJn CFYZdt4a+MWBbqsr6b74I8vLQ5NBsH11rb1L3H6aWFYeZl9hOSxKOVWCLWRuBnESpcnuYsvRT7jz nvLctVdL/HNkifpbej+0+vsVjlkwkyfNRAqFN5FfjX8xEFTc+KPEt7Rdrljv5UrWZCjA4ATD3zHT khZL/uCFZwuMw9ATLVH66EY6pJNnaPuJOXv+Gj1Acs4ed+GVqlgSY/bA/+VSkwcwGhbfmvOSYc5L Jue8ZM6cFzGKO3HPMvdRDVa/va5rWh8lNj8J5wZ7S9ra0HgdMnQqXUXcDWhdmBhxPC/yqn/cbFEB XeVkb514RjyeYpC1vvB4s9/qrmin4FhgBkJmA8OYgtAegpAv7ouFVVPAR5bf26kJPsYTtkHnr0Bv 6YrXWqtOgjgZW4KPX9FIx313cSW7Jaz/JZsNDc1X7YbM/Dz1i0bGHLDWl/SyKWqbydK5Pm2noyPi hHFfiMg5ZOXOHQcqkmDsO0HcpCArhAawmeXCsprb+AgfK/rWuMuXuDBrdN234+QzF/7MRAiYC6t2 Q6eOXySk6Uw3Gc6NY14J/Uy6ZrevCm+BKrXNvsHEILnGk9QPHb8i2ZEjiC1Ou8JNG4nkDjX4hrfo Lk5P93VqehswzAQDijV9lD6PjCfhe6JpPTrJrA1j4ZottIhkg5xWbfGws2Vhn6CaeEtbN8vC8FOl u/2tUbcIGDiOCEcXJvUW9kbT5XPPd/wQ/Moz06Qy2zrBByQSHf/DphG5UBMrBRVZ9eZEcwB7/6bH 7McTQRgbrp5EJ+hljp9CWxDvDc9SL65uPB05nsq83le7hcl1C5wcMHb8atu1K3Bi7V3WmaiXCm71 v2/UJ8O8Oz7JgzbvGZP7kpwbPSxMDML+wPFKlsSrs8KZdUOGcRg4DskSBdN8jn22NI08gg8t+9yQ ExxaxndFnlim45CJ64asMOusUsGvpuUDRTEC24adrBDGf5RNaFsnPGk6ugR7phgM6X3/799++4e/ Nto4tWM1hVBTe7dqaOIWlYe66lKgr9o0cgmBAzGrbIE9KYF01ZXVTuxsGwaC9e/tkYpf2ieUDIIz 07+Fo8RQ8P9og9DJjD9QX4G8pXOsoqxGVqOwK3xmOrTIITz3OCpEFvLVGFm4coHp1WJXjsyk8kG2 T0fvK2nFf7khKPaQxw//87v/VUVOP2t5UxaFaep4his5iGFTFvMCxQo1/XK9Kgvl4qhyKOMblg2K 2hEUi3Dyalk5QQ0/ii5i1ztE1iCu0P3EtTrId0YOeuh/6fqJ5GmS8qwWx26TH0g/K+XhD4OJc2Ke Po42G5ecEsiG88iM6yLv2XeyQD65YdWu+LNc/uv59/e5Bo5Cp7bIxyjnM9k/7XHldK+oTOilE/io JbfJrpyuRZZa75sHugXTxNfIoB84/mBRiD4mNZIu1CHxTjRF7a++HD7c4l2xelfsyI++vz9mt2Rn tSvSoQ2YWX+wQxswwxCZLfYSzjZGwmS/3eoF3JmEvb71DGWbW8YzK3ayzY1c6R23q6BFDTER1RSn RxR0z4LEcRm7ZwjnRpj+U3jBmuMn2YpciTfjfLXWN6jrR+G1dSSdEwo4YMkNKjiSgD+QjyXQcpNx YF1KM/19S8wLjiz5GTGRueH/03atzU1cSfu7q/wfztZbZYcK4wIBxv44ksfW2JLGkWR7HYqaGlsD aJElr2TFMR/8XyCESkYhgeVOcDBvuAUTsyEkASpLltsmQDYsTm0Cb6Dq7eecmTMX2SYfyGarsGa6 z8ycS5/uPt1PS7wnl6GziQGK1ZhVsmasEGFXMyHtUMY22lMD21NCzalx34xMWDVrrERaJALrqlNF 2yShvr1Yli+dpx7a6H/slEgdKteUCRFrZO6gTx2rkk7iDmMiqb8x5BuUtNX9tV5EDJ2ixuPu1EkY NCV9izLB0cXdlFZl2Bq3/Pgyl7RrOVI3FVzAq/h1EWhZJHXfiOyxyigDb0q4NmzDI3a+Is/VUNA0 YFS6R/GmCyIj37pHy1E/S0HeYyOcxSpUFM1C2SSXSKcX9i1IHMqW7RGLlnHbNo61gcRC+NRg/Qr0 jZpatXu9WFyXvyvKPw0PEUxInogKyYLMdtI9AyEYwgXSGXKBwPjebk9xWFlXt6SRtrFSXaahTCJw JCTA2hRAs4ncTkGlpfJGxjc4NRhTQnZYNB4lj2hYz/l2plZ6q1hDjcGSPSOSEZCL0CuAX/WyLx1d vq7l+PhHxO1EtR5+ijQ2Q9RIVCJz1qhmfGeylulJab7VGSw0o/QULS5WarW20FGny8m9KNIEXdmL QkI7kfBtTo1Gm1bhBKzfUik+Ezy8xxxK+FalRnMIxbpLM55HQOlH1gy+u0L25tqBGYTepIvQsrzX InWuz7cxERi2vcpxiazqWBVpilW7SHpvIUQeayLP1YlI5Or4lKO+tckjznhCKweNhJOFbAMxNWaQ /xDi6gxyibBSnRnTInjefZVe2jU13/bEVKD3YCn4CWlpV2dwVsu10l4DaLfS6oSNj/MJqzCjBJB7 3VazRtr0jU83xKLghlgowfgLwYDDrLhvh7qQBQLlmVfBVoxdu2ZMozZGMs7t9L6s2jPkW6N9tPDr XExN+WDJPKzYt0PlCSH3cdFMUCIngYIryXP31wV8XgK/kceEKhE0dcmSDZiinpusxFwcUNQ2rKDa WRrAw/xsky5J8yap4RRCmqmAmOyvF9BT1pQUZEluTq4LuMJg9zAUvaeZyiz43ipwh9P6Z/kZ2blJ BBD45qrIqZzxQP0r3irW4cDyrVWdwYPFcIbr6VmuS4/UFRfL2GVsD+CfCK8asJLz3N8uCsfwujEe dVoPGK5IFHAVM4murPAdjbkZtB7bsBYwZPV2IgBeClNFnVHESwPp1IZwZXHU/WY5261v5DZhDCkB yxY/uT+c9LSspDETasBk5SlbPD7Aw/YBUKpCeqgp9FCPayRoxr7MWaibiF6K+b5C7ruCpHFljCQz AmarLs61cbpF62IaT5iAx3esEnoJ+XkgIVG6A/lJwkZDVnFoRhGLHjBgiYXmxLIksRCJhy7pvdDy y0jvVeK0/nqkkzMoeOABDdi4L/WA6mm1L2Do6hMW6US20JZTdrksH5oxewL2rl423VPrAGaNS5nl B2fyy8j6t6GqofTMhOuO0fMk83yjV6cubz7oVVxsHtFsv6EGz+P6K1Y5btm7kJk2zXdZaH/Sqdpv aImAIUyrMVEZp7nb1k/fVNxmV0nRoOVqDk3yUPwRO26XZLJYvzGqBAzk/sqMwnWo+ExAlUK0VOD0 HNFS3o1cPmAF88AueIWwnrC7IIiaywjmywiXpzMYXAWAd9jX3rErZiXSx6Ftky6ylg8RrZ4Cx8V1 V4w4lZdK1QAOKmkdBgFrFFkYrBbkkcrUgHuSb9E+XSm5K990pbPLkSHDwDeoB9CjCgDZpmUI0oAB /BmpRg1QU200Qn0izJuMPQ+hL6WacYl2wmiHNONQ+mGImliENY+sZ1QinICMdkaahIDH4NHPZNqZ 8Xp1u2wVHSpVJx4lPe5FSQMZ06sKCHjU9VJlAiaRjqDr8GJFTJuENXFj2kiVQkRbWwq5djrquE/4 x6FGfSrv53Ok9GFdopuAPYJlkXexLBQBdiGWSCrT42OdEFO5UCkzDiXKy85PFHjRVK+2odojkU0Q lWYVUHCIG2YoGa24e6pAd5JM+CipLZGYxxMEUi0q9AgkCEALRxL8hJOpKxQDx71MHFnaTEmoMZSj k3gmzC9Ih7K3OJVS1KQqi3plJKwJjkB4bgVHuKd/VdrjtzOUuUPp50pANqf1nowENcERiKgib46R zqRoLMWMEF1sWTpRKtOcqkNAeHUOEn5tB6KvjNsFi3pc0ZB06J6bpA24E6WiBHsW1cXKjPsFFO3t Kfi43QZHzRGJaUK0M27AtlXeiTRfa8oD0iDCPolkwgkR8qQEctIlXVpimXC6CVmlYgI4qEUej8R3 kTg/nUbQn0xWyeipnMQ4wZFPqYb54Z4NBdDp80mJcMJLTIdgQtzgWg8YzkUnUvpI10XgXMGmB9ZC LXWFWwKOcjDaTwlFBdoSa5+XY/CPmkKBNEow/NBFTk+apkRDYczYsTaEpda8ZxFDQqKigAGpLST8 MvQFZo7G3gtXIVXRlDgoRFgqcPE6glqrKolmk76GWqUemqxW/kJakpgqpCmaEh4FhbcBNMxrjpZF BnKxPL6jvsNqU8fcgAsjkxqVECngIJ0SHeSllHuQ4VlV4qMwCdGrDO6o2GPYdafsWhCOXOpGMG3U 8k4aQuC2RsHZpW4kybj5KNHCkxIFBSdgVcRciB2b3m68WACkP9xDlbYmp9ugrvqQKMRMzVYYhiS6 IwJZV6KhMI6ty22FCV57oFDlkJSDHMSIg6tjQqQl4P0bQ1pOwqMwAILWXDwHq7wNyOT0b7lmigpZ cWlAZmGgxKTylCUDBTgJ3gRDeT3uK3sta41VKhNrPLjIvqSET0E0LI0oz+ajLZ8HwHoNMH+GZvVh TYKpgOcteLFovY5ZYzMlJGLT/Kc1G8BsjEmVKgT8aHrAkTiACABHAnHHLwqVUzFvpcKVozU2btGm HXTo5NRMr8RcAU2ZSfA1hSOzMQ+ZzYNuA2iHVLICCIMMCINKrq1PTP+cppoSbQUHihY+lZ9t8Ggv ZbAi8d2S+qAEWiHSHcXJmhBgLCTAODRXTGpZPhiYcHsqWomNkxgm+23SqlnuawiezpV4gh+wDRCJ Qa6ulbiA61FD6DeO/2ouEFiA0w9aDgOWEWucFFzvKQawRfx4ZeQRmDXbnuCiUQRTmJhEMLPJYC4o 3DPFAUG8xFrajmJS48pNwigQFso0UHCm3aoHtZq3xnJ5LEapevETPwCS8RIT1NsKR8hgLkJGiKcr yGPGEVePmnemxsuCeKRDaYnVAlIXQYaMB8VDmqk2Q814uDSAkNnsx29zabnDDVNJlIokD9xl5cHR aH6NC2LgYI/UwYE6ZO3If0eGBYlGqxSIlUPotwR2CYZ+K6qZtCQwxqDEcuHnt4ynn6DCEfewieSU Hj9fOKn1SjAXwcCjB4WfSeeWf4F5m1iqWLMYKo6USvYy8C7iwFiEf3MEvYKtDJAeaJGcqGzbtgzK i+CorhChHoJ6EaQ1q8AnF+8qJW2X4O+kq9t2WsuAvAgenKBPI4QUNs2yPrkQ2Itg4h41k4cfLDOO eV3zq2AQQ9FWRcBGtjg2VilnsdKoFdp5DWtnvmrbryEssNdDdUGmqFGFkVRZE4DkiEldToJykICb ZsniBPNOullAZc8bqBAjdTu36veIV/VbSdVT9QD8RqzbD/XHkkEhFqZIlw1fUFGsUoGrsc4/xeeq AE2McQ9xl00IyC94oWjrD4j98s61HK3XFHC9XoN5VWLC8LAAq2Ta4yWSoLZ3fM9lruvLMgO+LB6u u0Hqg3lSkNywCoXX+/XgOIYyiaSEh+FZ4TusYpmXVS0h7JJvfnalXpOgQR5fryEBYsAXqLmliGpc 3Ix1s5D1TELiwjA2TNqRXebFmmgHKslzwREs2w3r/eSI5RNc6f8Bi29Ea89KJBik+wLBlif4IviO umYXNrLtXsWzES2VkCgwIC8BARATIj3D+GkTiilOWWzArlaZi9jjJaYCTn+9nxyB3FARLqlw9ZJM 7UIhSCvVvRERbcxL3EGjTtk8xUzmFOukTG+Qal+gbrSS5Lq+q8+71DD0NkjVTyTNbKsjm1Ron/Di m4mSNSldTKPphBpwbuCnl6+ZSklwF2Rr8lCqXH1sAjgCEbN5lB86SmVPnP4pcGmIv+DZmPGOBJVQ Tk+ogVioAdCGH2MMJST6C88hwVllielTYq0OoK/p5dhAtS5R0oipXSLBcKYwkrHUnFzCrhChCTg+ s8TTU5X+HlordR8MSXBsXBfmqHGgXDegXuGIsZaZn5ZHWi5XLMBFJlUfSom62PWKgPXJW6Qg+o8y JfALZ+IYBjVoDFZ9qkijrJBOTUtrpx1mCXy4KazG+iQ/eIArp8fGkTUv3+SftxGT1wkFft42DR0F e+kOSwI34MBhdoPU9NzwFMXPuvFc5yMgi8nomWlWWL7Cht6eHiVK7wuL7SQTQSEVBe6N2LCpMxDy ovyFlCJWCngvyVSn5SV1OH6iu73MkP/lUQyRwN8gdbWJeq04rvRmzYL1VlFiUvekjWHdy6ah/XKi 8lbR361pYUjtiwfeklI7UfH95EODeZKBUt2q03KbLm+X6HLDeg8OwbtkrkLBruxEimQBUwtFCmpT licAjCz1n1StprnDoTfLOJ5rcJylAoW1BlVtAnYqkEoTlcpkYE6kiXajT8uLpYn4KSaRUzxnBpK2 ckamzyevMt/UeHVRLfjvf17yPzZ/5eTHjOdRrEr36gN7aH/vRlzPK43jSQ9lkeIpkYkm6qQfZ6yJ os22tJOSsb5rfTftEq8BQmQNPTre/qbZ3i3xiVi8fZcgxB+8lgSADxRGipJVq1dtn6X7ZSyDJcmS UHO64cMVIZaiSLPHYlt6OcQHkfSlVJ7w45H0lawZNLuZrGhaJNNsljdLyjLuzHIOXolgk89B+o1g QbWCGoMzwa4RZapdzSZm18uPpN/V8Vm7PJso2iXx7tw96ZN2r0jayYAHvBVFRmdj/IMSSZ3vdNUO 5kUrgnAjU6cqE8Vx2XRuUNNQGlJCLSGiVzw9TSpBecoflbwSN1JkM3qk9LtCShvb4v7BSXJvDJE9 4ZPkgHdIHYC6QHwT0zlALP1Z3UkM9y7/9Jj0TIkXgN9Le768TW9AKrkuTvrA5jScB84V57hz2/nB 2Sdeiq1fs/VVz/9+miNdr3oBpNU/B0ERyAp9G97bnK4GLxZrRau1xeijxZL2J7KxHYslbe0swkmV 0ROBGTtol4vj3FHCEajybwaay00Wp3bRiGR7Q4+m33TRpJFUM/5FcwwDCGoOYyUfnicdiqT0VGWy 1tryZ6VfHQxwub9bW95Usz3BZ+D3HzEum1+5YEoYwfdWxysIIhxQR1Qpe9TiTmvaImFVtmo2AgGp g3Q5OnzTwYF3AgZDDdFTajYwqIA5shAUNKzm/Ks9xbcsok3qZGXpPu5aESuTLo/mAD/hvYCbJjXO o+9wrJU1sv5bDxSrlWoFJ0ODQ3n/wSlrsj5liSOeuJbt8y4XywWytrbzQww9lwxMyHKxtqO15cG1 qy8Cyxc/H7/TuNpoNB61tpzeffxWYK3i59Ffjtw/e2hujsVebeSnN+Kdr3rEeZZXzt2KBKaUKHIC +cm2eNI8emcrwmQ4mNVmWiwIkhFAVmS6bTE6ch35rW4cTcqdGiL2RkS2MV44TMhUgC/w8A64bsv8 6GMrDkp7Rtu8dd1fL8ywNnhVi+BBGXFeCBzThtrBdjCUUXPerpSqly34HoV0T3PzdCsv9pzPevsQ BK4o9gyqbuaV7GB91QpZVFtFiYNRb9IFKiiIzSVwYatY7qYnJN6EB5hvb/yvOOmnhdlcvdzGUzFm JbnYlST5Rmbs8PL2fZoNIRra1CoFVOmrsUDRvj9E4m961fPsk68PX0mvhMyIm4xrlQeeHthz8M6R 04f58jrxjwPXjn94+n9bW07cOPrr/IW5cwcWWlvOHj//Cfv4+7P/Pvpza8sh58i7c5+evQnyuZNn Gxc+PbZ46JvWloPfsEN/m7/J6N/T78/fnL9AHGf2EtU8O+TQr9Pvz507fO2P6LqNr7rr6BP/88n5 1paj/z1+tLXl2In5y5/8NHfyddElBxbmPmttOTd3Zu/Zm4f2t7bMnTt16uAdtn3y7Y+/n7984pfz v544e+yj18Odc/rpsc8OPD3zNfVl4/SPJ4/PX2Ynn5y4R+3cO3fv2OLrcyfPHT/3/rHdF86c//CP 6CIBCIo5Pv/8wE/s1C/HrnR0dLzKJ7FBNa2l1CQ9bN36DpYyjAGdLJleI4sMHdr0h/JJN10kQBnr YKjFoOebb23oEFkn+SS103x7YwfLjxjM6BUZnzmXgmuIpCGItyBl7UfnU+e0s/fek2YCerjz2PnA uUX/LTz9u7P/2UPnPSK+5DxoJqbX+Xnhi9vOEWfp9innY+eec4wI9zYT0oul1ayueneG4pr3NvP0 LueffUJvdTfI61LgdfY4J52DznnnMKmaP7PXblz64j3qAzISMmsi1PQ+OMrkhd+vfO1cpGYXf/y3 sxQho7f5+xekrz507kCXJZseHBGiTTQKQ+m0lhUpyJG7nR3s+Tu/vfDS99VMT877oDv0QRcX9jsf Pb3h7KcOuR3qPUlKX3Z73+fvPHngLN45w19mPxjZa08efPfOzeO/HaLNhhOviXLSV/7zqbOI3vr8 F2fx2cfOhSgJfeG9J87S/VvOIzR9ZY9zjrpwibT1x86csy9KTt/6+ZFrp5zrzmJezfZp+SgBfS5C kPRMO+tXEwMsboxGSTZ3cNQmpiJ1SKNBWIamq4ONGFkiSmT1tMZm1bgxBA4OW4CqHmwkaRB5jq7l RnREGGdno410d7Ab79Ko3nGO0Rh/sPgVTefzzp0I2fp1HSyOYomMtlw+xi4B14oxVGoHgwNJiY9q LD0q3lrPaLlclDDOO/PKvVv3bjuLNF4XIgQxlY/6vl8/pIXgT2F5m/idQ87PdGuB2jkWeFmPZAO1 8I+vbn39427ncxJB0bvUwO2LS2echfuPaC1ecj5yzkdINlID976gjqDH33/PWaKpt7eZiNrpgbaU NYZyDCcCfcl8hGYTNYQqC6NMzaZXJKKGnl0VfZHIjkbuduJjjtJ0o3dp6qvNdBOjRreae2oztXvr e5IIBy8fd87Swol+QVfcnWSQoP6S9W53023SiS81Hjb2hG+tX6d2iPV1fVH0UvQ+sT7/9rfvnQVv KowKGRqhw2TwJ7Z3lc8Ad4hpff3dWVj4llbeorMQIcRAkzy7RCJh6dJjknnnqSNON70NRhzHhIwW Sd7guEUhKeTRYUQRnDlKM/lPkXsYpLymZdQ+bVleDFPjSOMH6i6y4Eke3qEvWHxxnb/7LedEhBxj c+PzS+chzv5z0bkSud1Frd194SwtXG2eeOu76SZPouCCOadpLPqyGLkrL0i+X7575tI/l1tlsXVi 5ix8+4R32UfUidjEHkSXS2ydWK9Ld2+v1L8xrP1n+5wPfv3GeXjzN5qqjy4dda5Hiaidh/POXpK1 S3f20cKLfFYMo/79kYfz0cvEpwv8JpbS8jQ0EQJMApplcTVO48ZF1O79zmX6oju0CXzw4ACJCFrh u/dH2eIdYq/Sc9RmJiLPYhABd7+kNi7QRG+a4LGNcdYxrGfyNB0id7DkH+6+sddZbDxSGj82Pm1c fP4dxFSUDmLo8FWaJJefOAtf/cC7/zv0bnSaxzC37v6L2tjb+KyxZ/baFWr7auNW43HjYYRysyuF STAFF9XarDa8VojyNvbm6Gifu7l+/oJGlOsYN76U2/qKDLTFPnjkLDzajR0iQLwFQBqkQmA6bnVb pgVwwjnw/D6+5qvF1cmp3caVxt7GVaXx6Nf9zoe3vqG3WpWDtuzApdUoN4q95NpB52/UtQ/FxzqP v7vs7P3vz/C2rca86aXSpYmFdvYv3vvqXWfh/07R+t+3Gint8Hp7GttDZDttouz6HeKwianble1x 2oY1TPOXPgd7/LWb9IQHYuMNyYwtfHNnTbu7N+Av3ftXbSC2ik6wKiPNhH9dwCJ6cP3hvt/LRJPC SP6J9NE+UpEgN34vI02I+89JIjRNg9WYaEro+XboYOGdbgtyV2hL8npwVYUjREy9RTpuw/ngSyjH 551HKxFu8PekZXWdEPFGPtsXbx64fY7k0JK3s4fHIshAvfHbaS4df3D2OQsPPqP1BfG1uBJD5+oK U4h286paXogUanByNLAlpjR1mG/2aios2ENs3WLOXX+2ah9iUWDbIg15MWOQUp3qk3ZXEy2NYs6g LyOVP6llg1RGUsyMYTnc/pVV6Gik88YgQzFULb8KHQ30ivpYlNYVibcPO8cw4BfxR1hLjnJsWknw R+g6+ZgtUq/+f23X+tTEsu2/U8X/0H64daHqQjmZ8Po4wACzk8xw89gcPOeW/8n+XyLIxWlUvLo3 oCJwfICiAXy/TnTz2AIBUfG41aNV97d6EjIJ05NJ5FRttsms9Vsz3b1Wr7W613QW3/xmn/til6QS XgiaA5GpGNEoAq+YHuv07TUMtNEjRrjXQCrJEjEj6td7GOFHmfuXkNNd83sKGuL8PL+IqGm73LiT FrwphQniXDTKYLXBwijCCw8z/gh+fp/fDgQKHUTsM+X+R4pRD8WW8uhSLiWcD3h+gcrv2JfR2Md2 5tvH9Yf4DNW5m3dwvwQS1iJsWfytfX+6gabQWJ8PhIWe4BG2A/G2SQJhOQJa8vDeHw8D8XZQpELJ bxBu0hMvWiCsImabMXTyaLl9SjFQlULm5rgcpLMunAj6OqO6SaFfImUiVEtgVj2YYSThfWARuP3m RwxrjqKlwChVkpH6o8KyYfZFtQSJO3wltFbIz/3RbUFcpq+Edpkj8EVJJzY/FKlvhTjbF674ZZ3+ 0FCl6MYXrR4OBZpY3u26hbgXjQo24L0MdJg1JF1zOsyr+q4fHeYnh3vfXqBslOIlX96Wg8zGl621 ubCqQudpGZgzymLLQwhS1WHMJbxkreGvRQMv9Ji3yZfx0Zq6riUs04enZCJgDZ1NZavMXphwJXMs 43dlaCIUnbUv2Ld9+Fsla2nlfOgtOttJN2m9qFTLyjhhwGQPtOyAiKQB/0LT/JrYQSEPUutkeepa ykfWujO0s0I2XuAqJu7UsYWVDTQ+i5TNpbXFfF3Yy6/C4gpr51k7Wzje9uj3gJyf4riYmzx34/mV Nzf47F32b9sMMq24EbFYQotoBm79fnnv7otPu2fx8WUawzuCdp9jDa+ufT1Lw9HrnBadPK6wHnS+ RlUpDQjc0gjcZvgkH+KnGgHtMWg9XYt2pmJVA/5GI7PyLzvDLyJRv+MEksCc4jm+zF+z+jq+nD4D 6Bu+33iw21TdHWitZI+PIezMMj5BQSffhczXNYqjqdXevm4P81lI2eb7NcqB3fInwN/iQ4yv8C2e gZ85VaOwFhFW7/NVPsUg6jo/y4eK01u10lpdsXNG7NhsHyycVCsL08Lbv2N8C1wTfKhGSZg2tm/C F85jAM/y68dqFIPJZOPSm1GexeidtxdXl0SUd6E2aSJAyPJxvsjn+AYk3mb8Pt/FSNaoFiLofYt5 5yzG8g5/DZG5GiXR9t7CvSv2HaH088i3thhEDvOF2gQW+JpjaqqADrHelGZ2anH98BVh2074k6CM vFc3I4b71m5WMtIx3HuZb4nw4Lo9Z6+VDbKbH1b459LmZ+G9looNlLHD2D5OZm/amcy0jAUmpLTx B+jwBRkL7KLwBW6LOoXFjL80ytih+i/szPD3s2Lt+ZBSuFmh253o92H+pCTgOcTXQcsKT4fspa1l x5NJGEkvaU2hMKXK2Cgdf4UmL6XPSFgKH9yjrorQG5FU0ojpCejNFn+MCXubiSa85pcbg3MKLXG6 nWH0d8iG3I8SRAIpzwIIw0zr1QwzPXKsWgm0WjACpd+nKeGPz66Nv8AioGL9Vj+6fJhWse3NavEt nvFTYDh0cz/3bsLO/DGf5V+vsqbVM5ufW9bufnn+7F5TtcKguWIuwFxRdVdCleG+z5Nf448ZaVap QQWRATWnvXg6GR1x38/VdgZpv2I/p8DBzmipXoipVgKUUtlYheFO0XIVz7Gm/iiid93ZCRWraOjV +rqqpDoMbksKMzpJkVGhARDgT58pKOLtxkBMwn6+jOBJT+H7LP5KNLcCNpRf34rSL5vFqwCKTQQE B5Qt8SpwYSccoLWs73tV4GAd+Q2o8vXGIGjKYb4+X0QnjUEp5kvn4QrYNifNpb05O/Nm7U41T90u AilMKhQdYIC2q8DCBuCtCbdVGgL440j3xWY769Ki0SpwSt5FjsGt7Ngz8KbwV/xlqWPwl0E0Irk1 vIVS025di4MflpQeQvdTcFGJLvQ6qUf1/j4t2VcSycohoeKqNH9BMT4ig+v8fDAw+YDzCMjJ4qeY d0whR0OxE5gUzC5dlIa41qYqAKHZ9IPcMc2IBgNAmTVa/Hfl+RUQUGHl+PH/IN+wsxIM0u7YN9o/ wR8Gg3QIyALCjgzC4Q0xH00FgopKqahhRoJxK2KUt6GpC/aI42AOx21SeGyQrrpVtFWc7K2zXiMe BfcLZItwfEDQZJFrDMj2N6e+sli3g1Bg096lMI01iAIDUx9IMFrRoTPkzJKwsaLskKgrmuG0h7m1 8x1yR6rCU9Y6jVmM26vHaFVrWHyqSgQlrGVXq8LTwtMrsSZJty8ttgwmAZq/dX/vCWV/pZpVEXlg AVs5e2xx2q7uyWkan8W1deRkmOjSz/IzX8NPKQx2eQpQUVyHswRONSwv35d7skposhU6+yEpjmSv Cgn9/Dr18im6fd++Zb8QCYQo7ahGiqC6rafNeZz/NFmnQUEEQFPkEoRZnub7gD7gM+kzjVUDnNRg gq/xPbo3zef24t7Fb6fdz1uFtBC1374iQvQ5e9neX87Yw6/HapQGixLTS9kySxUSwmKPOLMy+uG0 PVejDBhVYStF7HtdsGdqlEQ70VP2JfydKzWPKmTAzELH31Iwuiy2d2fKc94qZLWL/flXdubd7tvh GmV0iDZdtCderq6M1iZDrPAM84925tF4jRKUfLnwU4zPTfs84rkp8EyAs8a+EXxuG2xH+NBrIOBj MUsU2LEuK9avmYPC+U3SW1pA0+Q1I1ZTN/CNIzpa4Ysuw/wxKcJabRs++Vx93bfT0AHPCOpHbwIj /sdm5rKdqa9bWhbvftI+1yIMeu8ob0P+kmN+nKiv45f4gv0Bs+Vmqc/90VuEKW/L/gmR9XVHJpQW ggW1vs6hH+UTtxZ2FevrsrP2vL26kROFQK9ENRO37xzlzTCX7N6iEqL6OlFvcMdVvXckN2gXbpjb +/V19rOjFEyzzjpE36uvO33hCAUXi27wxItOsiaKI3Jrc0d5G0VkJOmzCU2cQ0q1FYkjlJ8Hu+ev DkiMxaxkn5AgtjEa/WhirhHbCg/5Lcjexwy5y58gbWsoboN4bxx5i6OisZSeoKKSpFG6Su0NoGTx AeXH/4UkXfxDtJeVgWExSU6KEGTd3qcalgEt2UVvU7Hkz5XxhQrC2dIVRm/mVqGJv4pIj4oATomS 3uHKQBjf57mV0WPO/yvzt1NR0MaovUqZH/p9CkP+Arl0WfLtDYa9rG3Dui/a1z5csHNORmf/gWce rQgmm6BjDCsy5i+5tE45XlgsGHt6BaNxi27pR3M8nKgZFDOSOHjAdWMJKER58c4KLs9BYbkIjGZL llUkQJUqBross5v1xLWSWF8CCIuX2Si3eoP5+HF6pDKEynOdkoxh5IcLGIOFyqDW4pLYl2v22KNM ScAoAbUdrM1knPqGg016HxD06uAlilyJxksAHWIxdPHTkKium7G3KkJcpYyuy6wh1c8sU7wkGbes HlZWieEjD0oidmeGxUhfrgjQTC3p3lRTFOSqjA6cSbAGfOLTEDNenBGldEc/z0PwA3TWYvrUQe1b BRgtm93GeN4BjHZ7uVMb4SoMqSBAlPesP7Qz2TcH70RUgEBXc5tU0yTSUe6oREkM5wNuEUtNY7TD 9XIUD5xbzd15HQza6rwxg7RiIRgAevvuX7iH6JLn9kY2aAuhu7nzAO7Yt9IjVObiVCp6KZJcSMdB IZTI2rM3vmxDZOnCiRzu0u3Zki1uP4i46tbHEDMtTKkRnTXQKDfKrgv9+/p1dxPR8g37/IZ79vZg htYN6N3d5Pg69WiU2Rn29eqLcX8QNI1+KZYZTIuxJlKhs+TR1ubsJXy+IKa/YbjVJn8x0L4Xp+0P v5/B1Lfsz0oR9RYywOWS5S4PRmhW9rHYovhg/w4zzOHBfrcXmT8K6kWnbLnepfZkgzIVS3T8WaEy 35/Zw+srdubZPV9WUo+9hWff8q/4zPszY3CfkKPYElshi/bSP/fLFfEwKFQwN/EWzjyGrKiP9qLz qiX6yH+4TIu+uVVSpZq3hGkN9ERBSUguC4VUWn4fFRPTU/c9DnHiQf+8uvHIzuxs7ez6cqoHNkX1 3zP3PvlyQ9NCrWvk+Sf5/0KRJpp82emdb23QMrW45ssHZbv7ZW/aeQebVhd8uakS4SUcUpY/4lv+ D0BrnWdJ4UXxwNZhxTiEgL5t2yujyAenbF4sGvVkJo0z2AC9vNBjRaPWgKjoq4DBIPaAFfOmLxuV fr9DP9+G353y4zRM+pJXp2cPnl38usQOSuP69S5Di0oJpFIOJX8HGVsIbPTiu1N+W4FZbUafryFa nuN7TWjA2N6EvQ3zuuIyMBk23MwziLZ30kP2HfwN0xu36TPFlyxluJbmfKBNL49lnFq0ywdVcTJU azNUaIhv8hy/bWe+jFRgb2t2DiPg85DOac2rAqC9WWw7TYmlw5w/82AqVpgUtvf/yH787cmO6yON VOFzXk6RFGpe/7/1988nd1Y2Xh8iqvkRbnq/tbS8kT1EDzevv3/7cu373pNDpJZmWo0tvzw4+N/5 dPffUUDq/NqmOBdwJn1paTI7e/fqPJt7PDcy/pZdX5mc+23/iOtI/xo73vY/zDn3KIpY5iQ+oktF qz1pqg8t7ENr8aG1+tDafGjtPrQOOQ0zl5ym+NB8+kXx6RfFp+2KT9sVn7YrPm1XfNoe8ml7yKft IZ+2h3zaHjESekRONn1IzkdYRVc8pUeZuJCgLC5hJILAemhDTxx5QJlfzLLMBi2RimiNNYJjRkJL WoHQJzQzYkVSzNRYUjcTfQaFQUndOKEHQVMMwJ/KOZNNMsXIP/Vg8amb4rohZ47pSUtCHbQiWizl JvZo0S4rdvK44nUx5HVR9boY9rrY4nWx1etim9fFdq+LHR4XS02/cNGrRYpXixSvFileLVK8WqR4 tUjxapHi1SLFq0WlBt2TgrL1GmwwlcL/G8RJhV1JhFvsZ0us8uoxOF49QQXBmpG0hIqSbmoRjX5m vhY5RjyFyM9EGmckaEcZ32uSI16E9WnMgIU7HFwcsOLRblHXDLzZTT++UT22T+un4zYLGZsXFP3U lTSE+Wtlc0c5Y58WSSGqScVTDIQIvvlyW0mrD43348EIWTR70CmSzjDF8LgN9HPqjTXgErhf0hcY 1XvpLTSrR0wgidQJLWL58ffHrajVm6JTrDotK1IA9lBlZR+9h04HaPVa3Qk/IXHkhGbS6ArQxQnd MDCWsVQc7fFl7Eul4ppxzMHEcZnGhA7MxVf844sVzQ7Oj97VihUcEh4rYsT0iHAE3Ra8UEI3K4+j J6ryKA6QNSd1qIHWp53w1cIBwzQL1aJeHPkAvaHQiV2wdNrQhnytK0I2ZIpDNHr1JNMG6G3gWuXQ eSt63NcWy4TkZRRFFLTRLUFsUbGIeJWOxbVBKufqYw2deiIpFs2E3jayUq8WFBSqHlTqFD0xFRlO diY6aWJKpJhOqoG+iBhBUTQzxQ2KbCK03wfFoiCtD3pGehzTgsoxkhRMkRBtsGyq84NFDJglg7cw NdiwFvixo1oT/uscxMdBLaHRBJuiR4dJJPWgQgZTJ1LirtDa3iD39h5TK5FUIe3am8uT8/fZ1U/s 2udLf2dX7898bk7WIC/gYzgXDx4CM26JZjUn/5KsRQpcUK9hwhe7JP2gnBRcCEhdkR+SQ78qALed 6jYsfzmWYw2098J6NUaeDzrB4Ij1ZAB1zsMpdtGqsicH2KX3GHGL/dJz4pcgkKSKNJ9cBtwTbIAO h/bUpIaU2R9N9epB5IWo5FhscMX0BivehRQJPRr4cVQ2+W52evwtm/1285814MNsITt9Iyh3CzPM ZNzqTomwCo2ffzp9k129OjE1fTmojNZyGeOfIWP2zKW1oBLayiXMjEOCOIj2VvDnaGczO3PD7MKT yXPju2zh/eTc7OREpoYu7Ch/HHXyNzzP/KPrVwOKUI4zAZl9Pp6+uU4NSk9mJzK//hoUr3hqYdVN UUJIP2FLJjmZiE6LfE3s4pXZpZk0HVGcu7DaoHXBcyParyiNzKtbBLIws6jeE+gRCAQ7QGfqjLxa YNBP9NyWyN57tSTNA51WPJhry0soWmFgCAU2SNcTlkid4B07kUxVga7Sn1k/a+S6SdeCMkcMsz9Y JzjsyAUDP0hM+8kw43okBYce+A5VNTWhGYNVPH2CUjiREaPZVhKhErIm2ttI6rH+0rUfK05rJSdN 66RStiZSQglJKaqUEpZSWqSUVimlTUppl1I6ZBRF2lJF2lJF2lJF2lJF0tJQ2RJOCUWRUkIyiiXF WHKMKqWEpRRpe6xWKaVNSmmXUiQjp0p1VJXqqCrVUVWqo6pUR1WpjqpSHVWlOqpKdVSVaogq1RBV qiGqVHtVqfaqUu0NS0chLB2FsHQUwtJRCEtHISwdhbB0FMLSUQhLRyEsHYWw9yhM35yZnbgy9wkh ywYm4n88+jZGZcilR6qHCiBgYprX3OsmhGQEVUYIywgtnoSQ7OYh2c1DspuHZDcP+dy8VUZokxHa ZYQOCaF0FN0E75arsi5RZV2iyrpElXWJKusSVdYlqqxLVFmXhGXtCMvaEZa1IyxrR1jWjrCsHWFZ O8I+7cgP7f8DUEsBAhYLFAACAAgAkgXqKmVqYr0oIwAAlU0AAAgAAAAAAAAAAAAgAICBAAAAALDU wNMuVFhUUEsBAhYLFAACAAgA4YXyKlBodMguBAAAwgcAAAwAAAAAAAAAAAAgAICBTiMAALG4wNS5 5rn9LlRYVFBLAQIWCxQAAgAIAIByhSl6+Ya5tiYAAGZPAAAMAAAAAAAAAAAAIACAgaYnAAC5rsGm x9iw4S50eHRQSwECFgsUAAIACAC1cIUpQtCCi6kAAADFAAAAEgAAAAAAAAAAACAAgIGGTgAAucLB 97rxtfC/wL3DtfAuVFhUUEsBAhYLFAACAAgAaojQKj1EDUw3PgAAZrUAAAwAAAAAAAAAAAAgAICB X08AALy6wM6/tcitLnR4dFBLAQIWCxQAAgAIADAO6irG4zSmHj8AAHHtAAAOAAAAAAAAAAAAIACA gcCNAADAr8a/x6659sGvLnR4dFBLAQIWCxQAAgAIAA93iir5r8MCppwAAH62AQAMAAAAAAAAAAAA IACAgQrNAABNUDMguPDAvS50eHRQSwUGAAAAAAcABwCaAQAA2mkBAAAA --==SoftForum-WebMail-1.0-32BF5B923B5B06F5==-- From debt4u@hotmail.com Mon Jul 23 06:06:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15OezI-0000MX-00 for ; Mon, 23 Jul 2001 14:39:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 23 Jul 2001 14:39:04 +0200 (CEST) Received: (qmail 28920 invoked by uid 0); 23 Jul 2001 05:57:36 -0000 Received: from n5.groups.yahoo.com (216.115.96.55) by mx0.gmx.net (mx27) with SMTP; 23 Jul 2001 05:57:36 -0000 X-eGroups-Return: sentto-1101623-3082-995867853-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by hl.egroups.com with NNFMP; 23 Jul 2001 05:57:34 -0000 X-Sender: debt4u@hotmail.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 23 Jul 2001 05:57:32 -0000 Received: (qmail 55640 invoked from network); 23 Jul 2001 05:57:31 -0000 Received: from unknown (10.1.10.142) by l9.egroups.com with QMQP; 23 Jul 2001 05:57:31 -0000 Received: from unknown (HELO t2000) (24.48.146.50) by mta3 with SMTP; 23 Jul 2001 05:57:28 -0000 x-esmtp: 0 0 1 Message-ID: <6334200171234621203@hotmail.com> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 To: "classified" X-SMTPExp-Version: 1, 0, 2, 11 X-SMTPExp-Registration: 00B0320C107602006905 From: "Non-profit Credit Counseling Services" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 23 Jul 2001 00:06:21 -0400 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re. Help! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N We consolidate credit card bills, medical bills, IRS Taxes,
Student Loans, Utlity bills and much more ...

Vist us at:
http://63.161.214.102
we will show you how ...

If you are ready to take the advantage of our service
please go to the following url to apply a free quote:

http://63.161.214.102/quote.html


**********************************************************
This is not spamming. you subscribed to receive
this email from our online member services. Please
replay this email to remove your email from our listing.

Note: Our program is for someone who is serious
about consolidate their debt and willing to repay
them with our help !!!
*********************************************************
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Wed Jul 25 23:25:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15PXlZ-0002a0-00 for ; Thu, 26 Jul 2001 01:08:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 26 Jul 2001 01:08:33 +0200 (CEST) Received: (qmail 15651 invoked by uid 0); 25 Jul 2001 21:25:07 -0000 Received: from n24.groups.yahoo.com (216.115.96.74) by mx0.gmx.net (mx006-rz3) with SMTP; 25 Jul 2001 21:25:07 -0000 X-eGroups-Return: sentto-1101623-3083-996096304-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by ef.egroups.com with NNFMP; 25 Jul 2001 21:25:05 -0000 X-Sender: whygee@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_2_0); 25 Jul 2001 21:25:04 -0000 Received: (qmail 80413 invoked from network); 25 Jul 2001 21:25:03 -0000 Received: from unknown (10.1.10.26) by l10.egroups.com with QMQP; 25 Jul 2001 21:25:03 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta1 with SMTP; 25 Jul 2001 21:25:03 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15PW9N-00057c-00 for f-cpu@yahoogroups.com; Wed, 25 Jul 2001 23:25:01 +0200 Received: from aqua.bocal.cs.univ-paris8.fr ([192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15PW9N-0008Sa-00 for f-cpu@yahoogroups.com; Wed, 25 Jul 2001 23:25:01 +0200 Received: (from whygee@localhost) by aqua.bocal.cs.univ-paris8.fr (8.8.8+Sun/8.8.8) id XAA08962 for f-cpu@yahoogroups.com; Wed, 25 Jul 2001 23:25:00 +0200 (MET DST) Message-Id: <200107252125.XAA08962@aqua.bocal.cs.univ-paris8.fr> From: Whygee MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Jul 2001 23:25:00 +0200 (MET DST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The list has moved ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Status: R X-Status: N Hello,

This message is sent automatically every week to remember you that
the main f-cpu mailing has moved to
http://www.seul.org/archives/f-cpu/f-cpu/

To join the f-cpu mailing list, send an e-mail message to
majordomo@seul.org with no subject and a body of "subscribe f-cpu".

Due to the lack of manager (He disapeared 2 years ago !) and the
impossibility to administrate this YahooGroups list, we are forced
to move to a more friendly server.

Read you there,

whygee
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From hilton@jam.rr.com Wed Jul 25 21:34:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15PkLC-0006By-00 for ; Thu, 26 Jul 2001 14:34:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 26 Jul 2001 14:34:10 +0200 (CEST) Received: (qmail 15218 invoked by uid 0); 26 Jul 2001 00:45:40 -0000 Received: from n29.groups.yahoo.com (216.115.96.79) by mx0.gmx.net (mx22) with SMTP; 26 Jul 2001 00:45:40 -0000 X-eGroups-Return: sentto-1101623-3084-996108335-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by b05.egroups.com with NNFMP; 26 Jul 2001 00:45:36 -0000 X-Sender: hilton@jam.rr.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 26 Jul 2001 00:45:34 -0000 Received: (qmail 10407 invoked from network); 26 Jul 2001 00:45:26 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 26 Jul 2001 00:45:26 -0000 Received: from unknown (HELO gulf) (24.170.11.76) by mta2 with SMTP; 26 Jul 2001 00:45:24 -0000 To: From: "biggerharddrive.com" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 25 Jul 2001 19:45:28 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] LOTS OF DISK SPACE ON THE WEB Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20010726004540.15228gmx1@mx22.gmx.net> Status: R X-Status: N GAIN ACCESS TO WEB DISK SPACE - NO TRANSFER COSTS -

http://24.170.30.28   

you get:
1.  dedicated  I.P. number   ex.       201.201.201.13
2.  dedicated disk drive to house your data
3.  dedicated server to house your data
4.  no (zilch / none / zero ) data transfer costs
5.  free setup
6.  available in 24 hours

see cost details at:

http://24.170.30.28  

email us @ :
mailto:sales@biggerharddrive.com?subject=more-information
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From hilton@jam.rr.com Thu Jan 1 01:00:00 1970 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15RAnC-0000E6-00 for ; Mon, 30 Jul 2001 13:00:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Mon, 30 Jul 2001 13:00:58 +0200 (CEST) Received: (qmail 27467 invoked by uid 0); 30 Jul 2001 03:18:59 -0000 Received: from n34.groups.yahoo.com (216.115.96.84) by mx0.gmx.net (mx008-rz3) with SMTP; 30 Jul 2001 03:18:59 -0000 X-eGroups-Return: sentto-1101623-3085-996463137-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mk.egroups.com with NNFMP; 30 Jul 2001 03:18:58 -0000 X-Sender: hilton@jam.rr.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_2_0); 30 Jul 2001 03:18:56 -0000 Received: (qmail 75001 invoked from network); 30 Jul 2001 03:18:55 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 30 Jul 2001 03:18:55 -0000 Received: from unknown (HELO gulf) (24.170.11.76) by mta3 with SMTP; 30 Jul 2001 03:18:55 -0000 To: From: "biggerharddrive.com" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 29 Jul 2001 22:18:51 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] LOTS OF DISK SPACE ON THE WEB Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <20010730031859.27472gmx1@mx008-rz3.gmx.net> Status: R X-Status: N GAIN ACCESS TO WEB DISK SPACE - NO TRANSFER COSTS -

for details:         http://24.170.30.28   


you get:
1.  dedicated  I.P. number   ex.       201.201.201.13
2.  dedicated disk drive to house your data
3.  dedicated server to house your data
4.  no (zilch / none / zero ) data transfer costs
5.  free setup
6.  available in 24 hours

see cost details at:

http://24.170.30.28  

email us @ :
email us if you would like to try our test like
mailto:sales@biggerharddrive.com?subject=more-information
Yahoo! Groups Sponsor
ADVERTISEMENT
Lose 20 lbs by September 24th!

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Wed Aug 1 23:25:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15ST4y-0003dL-00 for ; Fri, 03 Aug 2001 02:44:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Fri, 03 Aug 2001 02:44:40 +0200 (CEST) Received: (qmail 25396 invoked by uid 0); 1 Aug 2001 22:43:33 -0000 Received: from n28.groups.yahoo.com (216.115.96.78) by mx0.gmx.net (mx02) with SMTP; 1 Aug 2001 22:43:33 -0000 X-eGroups-Return: sentto-1101623-3086-996705793-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by f19.egroups.com with NNFMP; 01 Aug 2001 22:43:14 -0000 X-Sender: whygee@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_2_0); 1 Aug 2001 22:43:13 -0000 Received: (qmail 63980 invoked from network); 1 Aug 2001 21:25:03 -0000 Received: from unknown (10.1.10.27) by l9.egroups.com with QMQP; 1 Aug 2001 21:25:03 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 1 Aug 2001 21:25:02 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15S3UD-0000X9-00 for f-cpu@yahoogroups.com; Wed, 01 Aug 2001 23:25:01 +0200 Received: from aqua.bocal.cs.univ-paris8.fr ([192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15S3UD-0002VH-00 for f-cpu@yahoogroups.com; Wed, 01 Aug 2001 23:25:01 +0200 Received: (from whygee@localhost) by aqua.bocal.cs.univ-paris8.fr (8.8.8+Sun/8.8.8) id XAA24345 for f-cpu@yahoogroups.com; Wed, 1 Aug 2001 23:25:00 +0200 (MET DST) Message-Id: <200108012125.XAA24345@aqua.bocal.cs.univ-paris8.fr> From: Whygee MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 1 Aug 2001 23:25:00 +0200 (MET DST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The list has moved ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Status: R X-Status: N Hello,

This message is sent automatically every week to remember you that
the main f-cpu mailing has moved to
http://www.seul.org/archives/f-cpu/f-cpu/

To join the f-cpu mailing list, send an e-mail message to
majordomo@seul.org with no subject and a body of "subscribe f-cpu".

Due to the lack of manager (He disapeared 2 years ago !) and the
impossibility to administrate this YahooGroups list, we are forced
to move to a more friendly server.

Read you there,

whygee
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From webinfo@msn.com Sat Aug 4 14:30:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15Uki9-0002lL-00 for ; Thu, 09 Aug 2001 09:58:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 09 Aug 2001 09:58:33 +0200 (CEST) Received: (qmail 3805 invoked by uid 0); 9 Aug 2001 02:38:07 -0000 Received: from n10.groups.yahoo.com (216.115.96.60) by mx0.gmx.net (mx005-rz3) with SMTP; 9 Aug 2001 02:38:07 -0000 X-eGroups-Return: sentto-1101623-3087-997324686-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.55] by ej.egroups.com with NNFMP; 09 Aug 2001 02:38:06 -0000 X-Sender: webinfo@msn.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 9 Aug 2001 02:38:05 -0000 Received: (qmail 75077 invoked from network); 9 Aug 2001 02:38:04 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 9 Aug 2001 02:38:04 -0000 Received: from unknown (HELO mail2.itri.org.tw) (210.68.176.130) by mta1 with SMTP; 9 Aug 2001 02:38:04 -0000 Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail2.itri.org.tw (8.8.8+Sun/8.8.8) with ESMTP id KAA11551; Thu, 9 Aug 2001 10:37:37 +0800 (CST) Received: from mirlns1.mirl.itri.org.tw (mirlns1.mirl.itri.org.tw [140.96.147.34]) by mail.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id BAA06232; Sun, 5 Aug 2001 01:04:57 +0800 (CST) Received: from plain ([161.58.176.124]) by mirlns1.mirl.itri.org.tw (Lotus Domino Release 5.0.6a) with SMTP id 2001080500222954:4762 ; Sun, 5 Aug 2001 00:22:29 +0800 To: f-cpu@yahoogroups.com X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on MIRLNS1/ITRI(Release 5.0.6a |January 17, 2001) at 2001/08/05 12:22:38 AM, Serialize by Router on MIRLNS1/ITRI(Release 5.0.6a |January 17, 2001) at 2001/08/05 01:05:01 AM, Serialize complete at 2001/08/05 01:05:01 AM Message-ID: X-eGroups-From: infocenter9441@yahoo.com From: webinfo@msn.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 4 Aug 2001 12:22:29 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Re: PLEASE TELL ME MORE! Content-Type: text/plain; charset=DEFAULT_CHARSET Content-Transfer-Encoding: 8bit Status: R X-Status: N STOP! URGENT MESSAGE! PLEASE READ COMPLETELY! It is important that you read this message as soon as possible. Again I urge you to read this message to its fullest! Last year 72% of bankruptcies could have been saved by an extra $200 a month. We are an International E-Commerce Mail Order Company looking for people with a Good Work Ethic and the Desire to Earn $500 - $1,500 per Month Part Time or $2,000 - $7,500+ per Month Full Time Working From Home or Office! The demand for our product line (over 150 different products) is so great we need to train more people to process the orders and service the growing customer base. To better assist you in the understanding E-Commerce and what the world is raving about with E-Commerce and the Internet, I URGE you to read this message for your own training and understanding on what it can do for you. Everyone is excited about E-Commerce. We recently opened our business in India and with that we are trying to help as many people start and generate foreign and local business in India as fast as possible. As the Economy in India is tested, this opportunity right now is the fastest growing industry in India, Panama, Cyprus, Korea, China and Japan. This is a U.S. Based Company so it is very exciting to be growing by doubling and tripling in over 50 Countries right now. Expected growth in the next three years is 80 % in each country with new countries opening every day. We are expected to reach the world in the next 4 years and with that you can imagine the internet and E-Commerce is currently growing by 200 % each Quarter. There will be a 2000 % increase in E-Commerce Business and revenues on the Internet in the next 18 Months. No special skills or experience is required. We will give you all the training and personal support you will need to ensure your success. You will be trained via Internet in the comfort of your own home and you will determine your work hours. A minimum commitment of 7-10 hours a week is required. The income you generate from your efforts can put you back in Control of your Time, Your Finances and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, this is different than anything else you are aware of! This is not a get rich scheme. You must work to earn income! Your financial past does not have to be your financial future. "There is no security on this earth. There is only opportunity." -Douglas Macarthur Do you feel like you are too busy earning a living to make any real money? Are you tired of living "paycheck to paycheck" like I was? Do you dream of a better lifestyle for yourself and your family? If so, then I urge you to take read on to better understand why I sent you this message. We provide the system, experience and hands on training. The only thing that we can not give you, but is required is that you, number one have the desire and number two, is that you are teachable. We know that you have some level of desire because you are reading this letter. Ask yourself if you are teachable. Everyone evolved in our business had three things in common when they got started: They saw an opportunity, they were teachable, and they applied what they learned. It's THAT simple. And it's THAT powerful. ************************************* Now imagine just for a moment that you had a home-based business that provided Spending more time with your family, Unlimited income based on YOUR efforts, Freedom from commuting, Not having your kids in day care, Affordable health care for your family, Significantly helping others with their lives, Loving what you do and doing what you love, Having your own business/being your own boss Sounds too good to be true? That's what we thought, but today our dreams are coming true and now we're here to help you, like others have helped us! ********************************************** We like to get right to the point...so here is what we have to offer you: A well established, financially stable company, 2 Billion dollar + sales / publicly traded, Patented, exclusive, high demand consumable products, Comprehensive, high-tech in home training, Phenomenal support system, Worldwide income opportunities (especially through E-Commerce), Exotic paid vacations and Minimal start up investment. ARE YOU GETTING A BIT CURIOUS? GREAT! That's fine... as long as you're serious! Because our business is bursting at the seams, we ONLY have time to work with serious, motivated people who are ready to make changes in their life NOW! And because of the time we spend with each of you as we help you get your business off the ground, we have limited number of openings available. Here is what you need to do... This business fell into my lap in September of 1997. I got started as a customer and woke up when my wife made an extra $500 in the first week. At the time I was an Active Duty Marine living paycheck to paycheck making less that $19,000 a year. I was attending college at a local University and had two children. $500 at that time would have been a dream come true. I got started and in our first month I earned $2700 profit, and in the first four months my wife and I made $19,000 profit. I had made more in 4 months than I made in an entire year as an active duty Marine just part time working 10 - 12 hrs a week. The average person can start earning any where from $25.00 - $75.00 an hour from their home or office computers without dedicating allot of time and effort. Most of us have been thinking it's about time we took advantage of this Internet Craze. Through out the Holidays and especially the last year, every thing that we have seen on Television and heard on the Radio has either started or ended with www. -----------. Com and the reason why is because the Internet has truly simplified shopping, convenience which frees up more time for all of us to turn that time into quality time. Security and convenience has been technologically advanced to give us all the piece of mind. E-Commerce is so rampant right now that most of the states in the U.S. are buying their groceries over the Internet This is your opportunity to take advantage of the E-commerce that is literally changing the way the world does business. Internet Marketing Group will show you how you can work at home using your very own e-commerce storefront. Our opportunity is the only business of its kind right now. It's growing by leaps and bounds and you can be a part of it while you work at home. The Work at Home Network with our company was reviewed and published Wall Street Journal, Business Week, Home PC, Forbes, Success, and Money, just to name a few. You can work at home and use the Internet to run your business. You can market our high demand consumable products that are geared and driven by the needs of over eighty- percent of the world's population. Our products sell them selves, so there is no selling or need for out right sales techniques. Also because they are high demand consumable products, return business, on going business, and referral business is generated. By working at home, you reduce overhead, set your own schedule, be your own boss, and achieve your own goals. Be an entrepreneur, WORK AT HOME! The Market Opportunity is colossal. Over 1/2 of American homes have a computer, and E-Commerce sales are increasing month on month. America is looking for a better way to buy our products and now with this opportunity you can. The Work at Home Network a brand of e-commerce that is enabled and energized. The five top industries in the world are Medical - Health - Nutrition, Computer, Personal Care, Communication and the Burial Businesses due to the Baby Boomers. The Work at Home Network put them all into a package except for the Burial Business. Our industries are guaranteed to be the fastest growing industries for the next 18 years and each year sales have doubled almost tripled. If your country is listed here, you are eligible to start doing business immediately. (Argentina, India, Cyprus, Greece, Poland, Australia, Hong Kong, Russia, Austria, Indonesia, Portugal, Belgium, Israel, South Africa, Botswana, Italy, Spain, Brazil, Jamaica, Swaziland, Canada, Japan, Sweden, Chile, Korea, Switzerland, Czech Republic, Lesotho, Taiwan, Denmark, Mexico, Thailand, Dominican Republic, Namibia, Turkey, Finland, The Netherlands, United Kingdom, France, New Zealand, United States, Germany, Norway, Venezuela, Philippines, Ireland, Panama, Morocco, and China) However, if your country is not listed here, it does not mean we won't be there very soon. Because our company is expanding into several countries a year, yours could be the next one to become available. This is an optimal position to be in, one that you will definitely want to take advantage of. Due to the fact that countries can "open" only once in our industry, if you are one of the first to receive this valuable information and one of the first to start softening your market, you will belong to an exclusive group of wealthy leaders. Our experience in 50 countries confirms this fact. One of the strongest aspects of our business is the on going training that is offered. We have International Training's on an ongoing basis in most major cities. Weekly conference calls are also available, as well as satellite television training programs, monthly magazine's and quarterly journals. Our company does over 1.5 billion US Dollars in business annually and you too can be a part of this growth. Maybe some of you have tried other businesses and failed. We welcome you with open arms. Here you will find success because we give you the blueprint to follow and support you need to develop your own profitable home-based business. All we ask of you is to be coachable and be willing to learn. We have no need for tire-kickers or window shoppers. Please do not request our "decision package" if you are not serious about changing the course in your life right now. By ordering your "decision package", you will receive all you need to get yourself moving towards financial independence. So, if you are tired of worrying about money and tired of choosing what you can live without, come join the thousands of us working from home, setting our own schedules, making a fortune and living out our dreams. We invite you to explore how the "Work From Home" Internet Program capitalizes on today's advancements in technology to help you build a successful home-based business. Have you noticed the surge of people looking to start home-based businesses? Did you know that 32 million households now have home-based businesses and that number grows every day? Have you asked yourself, "Why?" Why are so many people, including yourself, interested in working from home? Our parents never searched for a business to operate from home nor did their friends. So, why now and why is it suddenly so popular? Americans are "cocooning". We want to spend less time on the busy freeways commuting, and in over-crowded shopping malls and replace that with spending more time at home with our families where it is warm and safe. Apparently, we trust society less and want to protect ourselves and our families from the "cruel" outside world. This is the wave of the future and we are beginning to realize with the advancement in technology, we do not need to be in an office environment in order to access the marketplace and make money. In today's world, the quickest way to build a home-based business is to take advantage of the Internet craze that has hit the United States and is quickly spreading around the world. Like how the Gutenberg Press radically changed the communication world in 16th Century Europe, the Internet is revolutionizing how we communicate, distribute information and the manner in how and where we spend our money. It has been said that those who pursue electronic commerce (business over the Internet) have the opportunity to build an explosive business. While a conventional business can cost thousands to hundreds of thousands of dollars to set up and run successfully, an Internet business costs dramatically less and has the potential to attract international business for just a fraction of what the traditional company would spend. On average, 30% of all U.S. web traffic is already international and 5% to 20% of all web sales originate from outside the United States. Everyday, these percentages are radically increasing. Consumers worldwide are spending 6.6 billion U.S. dollars a year in transactions over the Internet. The awareness level and need for users, buyers, advertisers and merchants to get onto the Web, and to set-up shop, has dramatically changed even from one year ago. This medium of doing business is skyrocketing, and we are reaping the benefits, daily. If you combine the Internet craze with people's desire to work from home and set their own schedule, you have a powerful team, and here is why. Many people have heard of SOHO, and no, we don't mean that hip section of New York City, rather the S.O.H.O. which refers to "Small Office/Home Office." One of today's biggest explosions in the economy. The home-based business has been born out of necessity. In an era where large corporations can only think of downsizing, what are your options? There is no security in Corporate America any more! Not only are tens of thousands of workers and managers being downsized out of their companies, but also thousands of men and women are tired of the corporate "rat race" and want to retreat to a home-based business. If you decide to "stick it out" in Corporate America or the Corporate World, your choices could boil down to finding a lucrative niche in the small business world, standing in line at the unemployment office, or accepting a cut in pay and benefits. We were all raised to give 9 hours work for 8 hours pay, and we are not backing away from that. Today's large companies have no loyalty to the employees. Their only loyalty is to the bottom line. And the bottom line is exactly where most of us are when it's time to cut back. Your life is suddenly turned upside down because you have no control over your future. Someone who has no idea of the quality of your work makes these decisions behind closed doors or the extra time you gave the company without requesting overtime. They don't know about your family's life: they don't understand that you just put braces on your child's teeth and now have to pay for them. These "decision makers" job is to be impersonal and unbiased in all areas except for the company's "best interests." In other words: TO THEM, YOU REALLY DON'T MATTER. The Great American Dream is gone. Official U.S. government reports indicate that more than 3.5 million jobs have been eliminated in the past 10 years - including over 2000 jobs per day last year alone - and an estimated 55% of all jobs created in the next 10 years will be near minimum wage in stores, restaurants, and bars. 90% of all the people in North America earn less than $40,000 a year and today's two-income family are not living as well as their parents did. So what is the alternative to the to the Great American Job? Richard Poe, former senior editor for "Success Magazine," describes in his recent book that a shift in thinking has resulted in over 14 million people working from home full-time, and another 13 million part-time. This number is increasing by almost 600,000 per year. And the average work from home income is $50,250 per year, about twice the average income of wage earners working for someone else. By the end of the decade over 44% of us will be working from home. Home based business wage earner's success rate is over 85% compared with small businesses like retail shops and restaurants, at about 95% failure rate after 5 years. Couple that with the flexibility we have to change our schedules and set our hours and then those of us who are parents are now available when our children need us, plus we no longer have the need for the "foster homes" we call day cares, where the care-givers get to see all the "firsts" your child performs. There's no wonder the number of people looking to work from home has skyrocketed. This "New Era" of financial growth is largely due to the latest technologies that are now available to those who desire to work from home. Imagine what it would be like to run an international operation if you so choose, right from the comfort of your own home. Well, this is exactly what we offer! We offer a "freedom" that is available through a constant flow of income that does not depend on the whims of a boss, bonuses or the economy. Take a look at some of these statistics: At age 50, 75% of the population has less than $5,000 in the bank for retirement. At age 65, 45% of Americans depend on relatives, 30% depend on charities, 23% are still working (most can't afford to quit and work until they are no longer physically capable) and Only 2% are self-sustaining. At the present time, it is impossible to support a family of two working full time at minimum wage! For the first time in history, the current generation is averaging a lower standard of living then their parents! Automation is taking layoffs to record highs! The Bureau of Labor Statistics says that Out of 100 people that start working at the age of 25, by the age of 65... - 1 is wealthy - 4 have enough money to retire - 63 depend on social security or charity - 29 are deceased 95% of people, age 65 and over cannot afford to retire and work until they die!! What Happened to Safety & Security? Why we no longer put our trust & faith in "Big Business". In J. Paul Getty's book "How To Get Rich", his first rule for success is, "You must be in business for yourself. You will never get rich working for someone else." This partly explains why someone starts a new home-based business in the United States every 10 seconds. In the past 14 years alone, the numbers of home-based businesses have grown >from 6 million to 32 million with no slow - down in sight. In fact, an estimated 8,493 new home businesses open every day. The United States is now driven by an information and service economy. Over the past decade, Fortune 500 companies have laid off 4.4 million workers while smaller companies steadily continue to reduce their work forces. As companies continue to downsize and re-organize, many professionals will seek out and search for new ways to take control of their careers. Many of these individuals have forsworn traditional "nine to five" office jobs and are making their homes pay off in more ways than one. For the entrepreneur, home-based businesses have become the bridge between work- crazed big cities and easy- paced family-oriented small towns. Link Resources Corp. reports that market research shows more than 29 million people run either full-time or part-time businesses from their homes. People used to believe that their livelihood depended on living in big cities near big corporations. That is no longer true, thanks to personal computers, increased phone services, fax machines, and the Internet, it is no longer necessary to live in close proximity to "Big Business". You can now operate that "Big Business" right from your home office. Within the last five to seven years, technology has been brought to an affordable level so that almost everyone has an equal playing field in the work-from-home industry. Check out these Statistics: 11% of the US market is now on the Internet 1,092,000 new people get Internet access each week, while approximately 38% of the US adult population, or 68 million US citizens' currently use the Internet, according to the fall 1999 Cyber Status reports from Mediamark Research Inc. This is an increase of 49% from the prior quarter, and this study only counts people who have used the Internet in the last 30 days. Ziff-Davis's Technology User Profile reported that there are 60 million PC's connected to the Internet in the US, but home PC's still represent the lion's share of the market, with 68 million consumers hooked up to the Internet. They predict that up to $54 billion US dollars will change hands from business transactions online by year 2001. Most people are ready to do some sort of business online, they just don't know where to start. This is why we are so successful. We link-up our marketing techniques with something people need, and most of all, something people want. If you add strong work ethics, a powerful support system, along with personal business coaching, you can't help but be successful. We provide not only the vehicle that puts you on the road to success, but we also provide the road map. All you have to do is be teachable, have the desire for a better life and be willing to change what you're doing now. 94% of home-based business owners are happier running their own business versus working for someone else. 92% recommend working from home to others. 94% plan to still be running their own business in five years. 20% of home entrepreneurs reported that their businesses grossed between $100,000 and $500,000 last year. 23% paid themselves annual salaries of $65,000 to $350,000. 41% work at home with other family members. 71% think their businesses are doing as well or better than they expected. 79% expect their home-based business revenues to grow this year. Your search for the ideal work environment and for the ideal vehicle to wealth is over. You will be able to work more flexible hours while increasing your productivity, not to mention drastically cutting your commute time, and increasing your most precious commodity-quality of life. We have developed one of the most exciting, technologically advanced home-based businesses that will take you through the new millennium. We don't expect you to come to us with tremendous business knowledge or a successful track record. We have already figured out how to make this work; all you need to do is copy what we're already doing. Since you've gotten this far, we know you are serious about working from home. Your next step will help you make some changes and learn some new skills. So, let's go! As you know, this is not a lay-on-the-couch, get-rich-quick scheme. This is a REAL business and a real opportunity- one that has drawn so much interest from people that we had to put this screening process in place to help us determine who to work with. Our company has been in business for 20 years, is publicly held and traded on the NASDAQ. It is important that you realize that we can help you build a powerful and profitable business. We have an explosive, start to finish, proven Internet Marketing system. And we are offering you this simple easy method where you can make money working for yourself, over the Internet, from the comfort of your home or office. You can earn $1,000 to $7,000 per month working around your current job and your family's schedule. Our system works regardless of your background or computer knowledge. We provide the system, experience and hands on training. The only thing that we cannot give you, but is required is that you have the desire, and that you are teachable. We know that you have some level of desire because you got this far. Are you teachable? ARE YOU TIRED OF MAKING YOUR BOSS RICH? Start your own business NOW! I will help you! Become financially Independent using our proven system! Learn to TRULY succeed working from HOME with our TURN-KEY system I CAN SHOW YOU AN OPPORTUNITY THAT IS NOTHING SHORT OF A MIRACLE Does that sound like something you would be interested in? Are you.... Tired of working for someone else to make THEIR dream come true? Would you like to start Right Away with a SIMPLE system. Work with some of Americas TOP entrepreneurs! Use an advanced DUPLICATABLE system to quickly build your business. You must be at least 18 and have a serious desire for personal success Take a moment right now to take the next step below: STEP 1. You must call our toll free "International Internet Business hotline and listen to some of the members of our team talk about the success of their new home based businesses. EVEN IF YOU ARE CALLING THIS NUMBER FROM AN INTERNATIONAL COUTRY, I URGE YOU TO CALL RIGHT NOW. This is part of our job-to introduce you to many others who took a step of faith (like you're ready to), and whose lives have changed because of it. This call is for everyone. I.E. former Military Service Members, Executive Professionals and Laborers Doctors and Nurses 1-800-708-RICH and enter Access Code 7228. Also to Learn about our industry and company dial 1-800-555-1795 and enter Access Code 7228. This 10-minute calls is a 24-hour toll free for all that are in the United States; however if you are International I urge you to dial this number now and listen to this short message and take some notes. ********************************************** CAUTION! This Access Code expires on August 11th 2001 (So call right now!) ********************************************** IMPORTANT! DO NOT PROCEED TO STEP 2 UNTIL YOU HAVE LISTENED TO THE CALL MENTIONED IN STEP 1 ********************************************** If you are unsure and need more information, we have put together a "How to do business over the Internet" decision package that will help you determine whether our business is for you or not. This step is only for individuals who have the desire to control their own future and who want to work from their homes and earn the kind of income that will give you the life you deserve. This decision package contains approximately three hours of information about our explosive Internet business and it also begins your training. You will receive a manual that explains how, why and what we are doing, a video where you'll meet us and see exactly how our business works and an audiotape to further help you with your decision. Your package also contains the name and telephone number of your personal coach who will be working with you on a daily basis, helping you make money in your first week. In other words, you will receive all of the information you will need to make a decision to determine if this is for you. After you request your "International Decision Package", and go through all the materials, we will call you and your personal training program will begin. At that point, we will also be happy to locate the nearest training to you, which are available in numerous translations. We have training being conducted in over 27 different languages worldwide! This package acts only as a way for you to review information about our business and begins your training without risk. This step eliminates the people who are not serious and allows us to work with those of you who are. Please recognize the importance of this step. We simply do not have the time to spend with people who are merely curious, which is why we designed this package to provide you with all of the information you will need to make a decision and determine if this is for you. If we spent our time answering e-mail requests for additional information, we'd not only be duplicating the effort we put into developing the decision package, but we'd also be taking valuable time away from running our business and training new people. Once you start working with us, we're sure you will appreciate our spending time training you instead of responding to curious e-mails all day long. Since we don't spend countless hours answering the tireless questions of the curiosity-seekers, you benefit, because it frees us up in order to dedicate ourselves to your success. When we spend time with you, we know we are working with someone who, like us, is committed to a better lifestyle. What is Your Future Worth? Decide for yourself and for your family what it is you want and by when you want to achieve it. Only you can determine how dedicated you are to achieving your dreams. Hopefully, you won't find yourself relying on your friends and family for direction and salvation. They cannot provide that for you - only you can do that. You need to make a decision to either give this a shot or to continue down the path you're on. Most likely, if you have read this far, you have already made the decision to make some healthy changes in your life. When we were looking at this "Work From Home" Opportunity for the first time, just like you, we were nervous and thought that maybe this wouldn't work. Like you, we doubted we could really achieve our dreams. We went for it any way and now we are making incredible incomes, working from home, and for most of us- it's a dream come true. We don't have a boss to answer to or a clock to punch. All you need to do now is take action. Take action by ordering your "Decision Package" and we'll be there to help you through your questions and then to work with you to build your own "Work >From Home" Internet Business. But please don't request more information unless you are committed to improving your life. If you are ready to learn and you are serious about achieving a brighter future and a better life, then we are committed to you. We are ready to give you the same step-by-step plan we used to build our fortune. There will be no surprises. We know exactly what to do and how to coach others be successful within the same system. Our Program works. It's already happening for hundreds of people. Why not you? Right now, take the next step, and get started on your way to a brighter lifestyle. STEP 2: To get started or request your decision package only after you have completed STEP 1 please call our international 24 hour order hotline at 1-206-222-2826. International callers and for United States, Canada, and Mexico callers please also dial 1-206-222-2826. We are willing to train you and work with you, as others have done with us, to help secure your financial future. But, remember, we only work with those that truly have the desire and ambitions to work-we don't have time to work with couch potatoes! Successful people do what unsuccessful people won't. So develop a sense of urgency and give your desires value! Procrastination is the biggest killer of success and you can now break that cycle! REMEMBER, for things to change, you have to change and for things to get better, you have to get better. Order your materials today, and when they arrive, review everything thoroughly BEFORE calling your personal coach. Remember the importance of following directions- we are looking for people who are teachable and willing to work. We're very excited about our future and we know you will be, too!! Until we speak personally, thank you and have a great day! Again please follow STEP 2: To get started or request your decision package only after you have completed STEP 1 please call our international 24 hour order hotline at 1-206-222-2826. International callers and for United States, Canada, and Mexico callers please also dial 1-206-222-2826. © 2001 all rights reserved. This message is an advertisement sent to you with support and concent of an independent marketing company. (POSTMASTERDIRECT Inc.) ------------------------ Yahoo! Groups Sponsor ---------------------~--> Small business owners... Tell us what you think! http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/CFFolB/TM ---------------------------------------------------------------------~-> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From qkffkd5@lycos.co.kr Fri Aug 10 09:29:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15VFQA-0000Eh-00 for ; Fri, 10 Aug 2001 18:46:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Fri, 10 Aug 2001 18:46:02 +0200 (CEST) Received: (qmail 17770 invoked by uid 0); 10 Aug 2001 07:54:51 -0000 Received: from n27.groups.yahoo.com (216.115.96.77) by mx0.gmx.net (mx016-rz3) with SMTP; 10 Aug 2001 07:54:51 -0000 X-eGroups-Return: sentto-1101623-3088-997430087-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by fh.egroups.com with NNFMP; 10 Aug 2001 07:54:50 -0000 X-Sender: qkffkd5@lycos.co.kr X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 10 Aug 2001 07:54:47 -0000 Received: (qmail 16882 invoked from network); 10 Aug 2001 07:54:44 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 10 Aug 2001 07:54:44 -0000 Received: from unknown (HELO kr-outmail2.lycos.co.kr) (211.51.63.171) by mta2 with SMTP; 10 Aug 2001 07:53:58 -0000 To: faricha@hanmail.net, faris@orgio.net, faris620@cyberstreet.com, farmer@cyberuniv.co.kr, farmer@soback.kornet.net, farmers@iksan.ac.kr, farmers@mahan.iksan.ac.kr, farmers@mahan.iksan.co.kr, farmnara@sorimachi.co.kr, farnear@phya.yonsei.ac.kr, FascinatiHon@juno.com, fashi@yeozawa.com, fashion@fashionwide.com, fashion@marketingschool.com, fashion@nmetro.com, fashion@samhwi.com, fashion_info@century.co.kr, fashion7@hanmail.net, fashley@earthlink.net, fashsc@kunja.sejong.ac.kr, fast_ethernet@hotmail.com, fast30@cHhollian.net, fastar@orgio.net, fastcopy@fastcopy.co.kr, fastdeal@chollian.net, fastfunandfree@freestuff.at, fastgame@hihome.com, fastlovejj@hanmail.net, fastproto@yahoo.co.kr, fat001@chollian.net, fatale@mcsp.yonsei.ac.kr, fatale@intime.co.kr, fatalian@haHnmail.net, fatcat@4dcomm.com, fatduck@kicomsa.com, fate00000@hanmail.net, fateman2@unitel.co.kr, fate-y@hanmail.net, fatheroftwins@hanmail.net, fatsoul@empal.com, fattykim@dreamwiz.com, fattykim@kmib.co.kr, faunus@platsys.co.kr, fausta@dreamwiz.com, faustHa35@hotmail.com, fausto@kt.co.kr, favioson@yahoo.co.kr, favor@edunet.nmc.nm.kr, favOurs@chollian.net, fawn@chollian.net, fawoo@fawoo.co.kr, fax12345@hanmail.net, faxdir@nucleus.com, faxpress@unitel.co.kr, fay0719@hanmail.net, fayepark@nownuri.net, faysummHer@fayschool.org, fb_man@kma.go.kr, fb_num@kma.go.kr, fb_rem@kma.go.kr, fb_seoul@hilton.co.kr, fb3373@hanmail.net, fb370@hanmail.net, fbdidrb@hanmail.net, fbdpdms2000@hanmail.net, fbh@linkware.co.kr, fbi@korea.com, fbi210x@hanmail.net, fbi3800@me2u2.co.krH, fbird@hani.co.kr, fbird67@ihanyang.ac.kr, FBISKR@orgio.net, fbsmusic@hanmail.net, fbsystem@nownuri.net, fbt@chollian.net, fbtndks@hanmail.net, fbwkdgns@hanmail.net, fbwocjf@hanmail.net, fc107best@hanmail.net, FC1ZOLI@juno.com, fcaissy@quebectel.com, fcaHnty@iag.net, fcastro@apci.net, fcb56@hanmail.net, fcbfcb@hanmail.net, fcbfcb@netian.com, fccman@hanmail.net, fchaudha@lynx.neu.edu, fchou@mail.sdsu.edu, fckgolf@kornet.net, fcli@fcli.bc.ca, fcman15@hanmail.net, f-cpu@yahoogroups.com, fcs@y.net.ye, fcseongdk@yHahoo.com, fcsmwg@yahoo.co.kr, fcsogang@dreamwiz.com, fd1021@chollian.dacom.co.kr, FD835@chollian.net, fdc2003@freechal.com, fdcjbs@netsgo.com, fddd185@chollian.net, fddhdd@nownuri.net, fdf@gdgfg.co.kr, fdfds@hananet.net, fdhujhldg@ijdygrfj.dom, fdim@fdim.Hco.kr, f-disk@uniondigital.com, fdisk2@kornet.nm.kr, fdnutr@mm.ewha.ac.kr, fdopi@hanmail.net, fdsa@ez-i.co.kr, fdskgj@hanmail.net, fdspice@hanmai.net, fduck@kmail.com, fdxn@unitel.co.kr, fe123@dic.co.kr, fe-6999@hanmail.net, fe90001@pine.kangwon.ac.kr, feH98@dreamwiz.com Cc: feal@btinternet.com, fealling@hanmail.net, FEAR@unitel.co.kr, fearer@hanmir.com, feargod@orgio.net, FEARLESSGIRL@hanmail.net, feasoft@feasoft.com, feba@taeback.kornet.nm.kr, february14@sicc.co.kr, feceman@hanmail.net, feder@netian.com, fedungcu@cholliHan.net, fedungcu@hanmail.net, feedback@chosun.com, feedback@chosun.comfor, feedback@dadanet.co.kr, feedback@ec21.com, feedback@etnews.co.kr, feedback@exploresmart.com, feedback@getpounds.com, feedback@joongang.co.kr, feedback@knua.ac.kr, feedback@LNCsoft.Hco.kr, feedback@medipark.net, feedback@motorola.com, feedback@onlinenic.com, feedback@sdrc.com, Feedback@uq.edu.au, feedback@www.etnews.co.kr, feedback@www.joongang.co.kr, feedback@www.knua.ac.kr, feegon@dreamwiz.com, feekchoi@hk.co.kr, feel@asri.snu.ac.kHr, feel@cosmos.changwon.ac.kr, feel@designdite.net, feel@enischool.com, feel@infosave.co.kr, feel@kuic.kyonggi.ac.kr, feel@manna.ce.hallym.ac.kr, feel@manna.hallym.ac.kr, feel@neofeel.com, feel_hoya@hanmail.net, feel_jh@daum.net, feel0110@chollian.net, feHel1717h@hanmail.net, feel208@hanmail.net, feel21c@shinbiro.com, feel25@feel25-i-u.com, feel32@hanmail.net, feel5715@yahoo.co.kr, feel7203@chollian.net, feel7678@lycos.co.kr, feel936@hanmail.net, feelchoi@hk.co.kr, feelfree@nownuri.net, feelgame@hanmail.neHt, feelhistory@hanmail.net, feelhwan@donga.com, feeli@korea.com, feeling@todaykwangju.co.kr, feeling123@nosmoking.seez.com, feeling123@seez.com, feeling1981@hanmail.net, feeling521@hanmail.net, feeling76@korea.com, feeling80@hanmail.net, feeliya85@hanmailH.net, feeljoon@hanmail.net, feelkorea@feelkorea.co.kr, feeller@kornet.net, feelone@thrunet.com, feel-point@hanmail.net, feelpost@feelpost.com, feelsdj@hanmail.net, feelsk@shinbiro.com, feelspy@hanmail.net, feeltoy@dreamwiz.com, fefe@ailab.gsnu.ac.kr, fefeH@rtp.gsnu.ac.kr, feflora@singnet.com.sg, fei@fei.co.kr, fei2002@channeli.net, feic@thrunet.com, feinheit@hanmail.net, feistylamb@aol.com, Fejj99@hitel.net, fel@hanyang.ac.kr, felices@unitel.co.kr, felicia@chollian.net, felicita@unitel.co.kr, felipebs@zipmHail.com.br, felitia@hanmail.net, felix@spongy.net, felix73@hosanna.net, felixe@kitel.co.kr, felixgon@netsgo.com, felllow27@unitel.co.kr, felove77@hanmail.net, fem@femcritic.com, fema@sudosa.com, femaa@chollian.net, femaledoc@orgio.net, femi@kebi.com, Hfenapple@erols.com, fender-st@hanmail.net, fendi9@lycos.co.kr, fendre@hanmail.net, fengx@ihw.com.cn, fengyoulove@hanmail.net, fennec5@unitel.co.kr, fensing7756@hanmir.com, fenster@fenster.co.kr, fenus@iol.cz, feplo@bora.dacom.co.kr, fer@sfu.ca, ferain@kosHpace.com, ferialvalencia@feriavalencia.com, ferias@larural.es, feriavalladolid@feriavalladolid.com X-Mailer: SoftForum-WebMail 1.0 From: "Â÷È¿ÅÃ" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Aug 2001 16:29:04 +0900 (KST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] ÂüÁ¶Çϼ¼¿ä Content-Type: multipart/mixed; boundary="==SoftForum-WebMail-1.0-32BF5B923B738D40==" Message-ID: <20010810075453.17791gmx1@mx016-rz3.gmx.net> Status: R X-Status: N --==SoftForum-WebMail-1.0-32BF5B923B738D40== Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable =BF=A9=B7=AF=BA=D0=BF=A1=B0=D4 =B0=A1=C0=E5 =C7=CA=BF=E4=C7=CF=B0=ED =C0=AF= =C0=CD=C7=D1 =C4=C4=C7=BB=C5=CD =B0=FC=B7=C3=C7=C1=B7=CE=B1=D7=B7=A5=C0=BB<= BR> =C6=C4=B0=DD=C0=FB=C0=B8=B7=CE =BD=D1 =B0=A1=B0=DD=BF=A1 =B0=F8=B1=DE=C7=D5= =B4=CF=B4=D9

=C3=D6=BD=C5=B0=D4=C0=D3. =C0=AF=C6=BF=B0=FC=B7=C3=C7=C1=B7=CE=B1=D7=B7=A5.= MP3. =BA=F1=B5=F0=BF=C0=BD=C3=B5=F0 =B5=EE=B5=EE
=B8=F0=B5=E7 =C7=C1=B7=CE=B1=D7=B7=A5=C0=BB =C6=C7=B8=C5=C7=D5=B4=CF=B4=D9.= 8=BF=F9 =C3=D6=BD=C5=B8=AE=BD=BA=C6=AE=C0=D4=B4=CF=B4=D9

=B9=B0=B7=D0 =BD=C5=BF=EB =B0=C6=C1=A4=C0=BB =C0=FC=C7=F4 =BD=C5=B0=E6=BE= =B2=C1=F6 =B8=B6=BD=CA=BD=C3=BF=E4
=C3=B7=BA=CE=B5=C8 cdlist.zip =BE=D0=C3=E0=C8=AD=C0=CF=BC=D3=C0=C7 =B3=BB= =BF=EB=C0=BB =BA=B8=BD=C5=C8=C4 =C0=FC=C8=AD=B3=AA =B8=DE=C0=CF=B7=CE =BF= =AC=B6=F4=C1=D6=BD=CA=BD=C3=BF=E4
=C0=CC =B8=DE=C0=CF=C0=BB =BA=B8=B3=BD =BE=C6=C0=CC=B5=F0=B7=CE=B4=C2 =BF= =AC=B6=F4=C0=CC =B5=C7=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9.
=BE=D0=C3=E0=C8=AD=C0=CF=BC=D3=BF=A1 =BF=AC=B6=F4=C3=B3=B0=A1 =C0=D6=BD=C0= =B4=CF=B4=D9(=B8=DE=C0=CF.=C0=FC=C8=AD=B9=F8=C8=A3)

=3D=3D=3D =C6=AF=BA=B0 =BA=B8=B3=CA=BD=BA =BD=C3=B5=F0=B8=A6 =C1=F5=C1=A4= =C7=D5=B4=CF=B4=D9 =3D=3D=3D

=C8=AE=BD=C7=C7=CF=B0=D4 =C8=DE=B4=EB=C6=F9=C0=B8=B7=CE =BF=AC=B6=F4=C1=D6= =BD=CA=BD=C3=BF=E4
=B0=A8=BB=E7=C7=D5=B4=CF=B4=D9

=B3=A1=C0=B8=B7=CE =C7=E3=B6=F4=BE=F8=C0=CC =B8=DE=C0=CF=C0=BB =B5=E5=B8=B0= =B0=CD=C0=BB =BB=E7=B0=FA=B5=E5=B8=B3=B4=CF=B4=D9.=B1=D7=B8=AE=B0=ED =BF=A9= =B7=AF=BA=D0=C0=C7 =B8=DE=C0=CF=C1=D6=BC=D2=B4=C2
=B9=AB=C0=DB=C0=A7=B7=CE =B8=F0=BE=C6=C1=F8=B0=CD=C0=CC=B4=CF =B4=D9=B8=A5 = =B0=C6=C1=A4=C0=BA =C7=CF=C1=F6 =BE=CA=C0=B8=BC=C5=B5=B5 =B5=CB=B4=CF=B4=D9= . 






Next Entertainment, LYCOS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C1=F1=B0=CC=C1=F6 =BE=CA=C0=B8=B8=E9 =C0=CE=C5=CD=B3=DD=C0=CC =BE=C6=B4= =D5=B4=CF=B4=D9!!   http://www= .lycos.co.kr
=C5=E5=C5=E5=C6=A2=B4=C2 =BE=C6=B9=D9=C5=B8 =C3=B5=B1=B9 - =B6=F3=C0=CC=C4= =DA=BD=BA =C3=A4=C6=C3 (http://chat.ly= cos.co.kr)
=B3=AA=B8=B8=C0=C7 =B1=F4=C2=EF=C7=D1 =C0=BD=BE=C7=BB=F3=C0=DA - =B6=F3=C0= =CC=C4=DA=BD=BA =B6=F3=B5=F0=BF=C0 (h= ttp://radio.lycos.co.kr)
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--==SoftForum-WebMail-1.0-32BF5B923B738D40== Content-Type: application/octet-stream; name="cdlist.zip" Content-Disposition: attachment; filename="cdlist.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAJIF6iplamK9KCMAAJVNAAAIAAAAsNTA0y5UWFStfPtzE1eW/++pyv9w2dR31mSR x3pYflTtd8rYBlwxj8UmmUwqSylBEG+MnbXNzM7+kP9FOJAAsdxCaqm79ehuS+o2jCyDIeYVMGFw HB42ZgzGEJjac063pNt6MFv1/ToxoL637z333PP4nHPPVWY2umLOp1Lq/d+9+052MZ1nwlXtihRO K0ZYuxqbj91ofvcdbTm2woSQcFtTmK+lpYWpW3YbqzQVZDNRZJ7uHqYVaRDo3N4MvUud330ntRC5 Kq2zzAvtZjaaiDL5Vf5MOiuuCwL01V5F7uCH2AxLrqiPzHl9k2UupjXrVWE1cocJW9hBkrSk1eUH i4Z338H/33uP6Yty2JxPm/FvYRB5a3YSCKJn1/XFdFZYZdKatqwV9U1RZDBngWX+ktD1RVz9u+/A EKcnT4f+n//7Bgc6aUwrQiqlzUfuCZP6ksUA9q//+n+ZeVneUkOsFQjBVaSz0gOWmlKephXmpmfi shTF3qdP4kCn/z9QdIoW99afT5gZljf1ado49im+8Anb3bW3l3k6/OxTxsx59TGQqGrKQyaeEpeZ h3FdWrGLXEgr+TmkP5KYrkwIAvFB8M+sk3X1d3tdvb59H7k83R97XZ6P+nu5IXw4hPQyL0gv2Sfm 5cgtw/yUa/Zis3ZF30rMM8+/sMN6PBXRTCbfFm4fZvxkH/R+DHP9N/y4nH9wg3lwsPx9rZCYhJUk ZK2QLrD3rUnftwbieruxd2pBfaI8lEQhX4+6FuzCJr4IsvHjJ8aOsuHgBDsGv8Ojo+PBCnVpRbpi 6qUJkdXNlcbsUuYJrEiSZqfsjs3NRs7INTfHL8YvatRfkr6V17VCM/eaVhAf4GtxLamGUlMsF5Wm QYqEp/ENeyJzHrSBJuNeE07qGZYxtEL+Frw9q8YuaBJoS+w501bkH1DjSotr76DFiev6WmweO6in jFuJaRZTWOSaFFYeVgbN3BUmQZMzaxIol/qoZtLYj6kt87JlHArSg9QU6CFMV4hO0TNYSBIELXoW fyOvsAPTXutb5nUWPSuE6qzCIiq5IrxOZK1hcRGR09lpTcGP3CraaRWxmyChoO8oy1JYfMmsXuUF EOVCiKki/PM0k39RH0fuMV0XRZA7YTUzK87WEBF9lAjBQpSiNAkmRj2TmBZCYLtwCGZeSmug7aKo /k007QVwRLURUd4edixwPMi+Cnz+ZWVYL44Ce+M9YvGLiQ8ya9oiGDxublWLP0ubMAP2EQRnY2Yt oatrNrtZelbIR8/SJ2VB+E5/zoQLkqBcIq5r39r7whFHes/UKfOFMDU7yQ5bYn+YNX2+nX1wcDcb Hz06AR2aPNrydu41sgWsa3h0JMiGRkgpegJjX/pYU/d21jdydPTYGCx2nDV5ne+RAWD7vwqOBSaG RkfYruHA+BdfjQ6NTNCM3aNHgscD4xPBsXH2HkM/kBfAIGhm6o12E4TjAnuPG4zMBdsZGD5yYuyf x9nuwESQ9fV1ssEvxpCu/UfZzi8CgWFGRAFVMOxXw4E/V3gnL8Weg4wASwpGGIzde2w2rC0blx2z kB1B1ZtPFGGnYo+kdfMXi1GH2c6hYyxw5I/BkYkTY0E2epTtHRoeZR+MjgUDI6z3yBAtElc2MDQ2 FOBGJXvDOtxusGO7huDd37CDwfHPTwSpd4WD3CuW/TkY+PPRgDXmoc+GBnB7tGVpsjOzJi4rp7I5 dhgNgmTuSD5PFGFPp8TZHWj0D1dGarOUXX2lr4F1kOLCDTHBPhodOz7OusaOB44FjxwBqtn77NAB 41Iu1Jw/kzjJjBfm1W3buEEsXcufkcK5eQ/iBdY9NvT5l8EJ60OtAW2zFEENgcoYL4ww9VOkxBsv Z4jb/Da7pXDGAOqM81IYJL/ecJYMqmLkG9iWmdemqc6wuh0tofsDcBoAj8pSoF5aIbMGq//kD51s YCIYHGYDo8NHhkDsPuW9QpslYWQLi2AnjPNAOBN/Yp/0HgcRHh3rBOmbmBgOsqOjY6znxEjwU/Kz Pm3504q/avH6/T6Py9Pqb/P6XB6fv63V52r1tPgsF1Tu1d7W3upq72ht7/C52nz4n6ujBQTE2csP Py6/n/8LfJ2bI9oSWHMhcYopqygM4P5iN/JnmDqpnyEUQBxiPIsscTTCsNHprJGy4EItJy0RNPVE yEhFLzPzgpLi2OW35Eo/nc6CVmlnYV7174gxWaIonlI125JzL1gyZPysn2a5hHFfK/ryL+PPmM/N ajrJ5/RNIYp6mGaz5yMSTx8r97VELH8fnNjsJCwZSC3CrucugA+c89R9xRI4QDW/gCiAElTMwz9l 1mYyYOR1HZHrPJjX5JvIz0yYYzaWjf6EAKkyFEqk/jC+Ad5EBRSrvfZYtufkEthe7SbwI7Vg6sCP ikVlPILq/biTHWoZaHXtbmn52PVvnp27W/jhUY7z68CB16koWKvqn+oRHT+l4Qfdrq6dO9sBmbV7 Pb5KOz8PSv3AiSNHgiPAkbGhL4NgCmyZeZ/W093zIUPL86cAGK5etKsTgaGR40G04jwRadO8C4xC +wHuJ/1TZslG883WMwXJysyCfmuLAHtWSk89QlQDiaGPAA6UIlPkJEQw6hkWuadLzMhp88IrJt84 fwOccWk26q0vsd/DT/Pvf+8B144EQKxwkf7BxL/YoU5lqRZIfA6ABHelyVrl9vKQ+BmQmmjCtuvf SEmYPnYD/O0M026Zgr4ElCOM0Reamfq9Kqezcg4fpiKAmiBCgrggVB4rY+iLLPossxDbstAF23vA C9IZfaylAXBArAMWnFQQYxbsLHwnFxJXrODIQTVqq9N39fWhdTsNEOSxBd8z89xymnzWppQHQD0G 23ASvM7sFA1Q7sx1a0V9Tuf1uPkyoXPDsZoBW1FHExFYWf6aFCdICrCO74CKqUiRW/jLvGj5bYmq yG25L2qkEY5vaAXlISzRA84zODYWYINjQ58BpvCw9/80Ovbl0Mix923XbrXzQ6AmJmRpGl6vtzDU pFyOwT4qkzDLU3txNdpjI5BO5oEfV+WPltZWNz8eakwqZZwHxOw7rH+TzgEGCbKBIPoGgDJ9Hzo1 rBXFLn1BXzts4Y1t22B+K/aCYCAFGxaRo8nsPYgbVzvTAOgAVFJDQ/pawFO4fO62Nm+b2+Vp8fva 2zwub6ubtx+tKDZAF4DQA4DVAGR83swajuhrbWlztcFGdYDv6vD73P6WDldra0sHPyLKUcZQn2GE 0LT/0GB/34e92xuO2e3v7/WB/fHu8vlbXeAHu+FDd2+bexdzudACS+qcJfmzq6Dul0H1E+dQp7gp fSiTqSnpSvQi2KjjxwHojdkihIMAys5cS5kscdnMghReA7im3eJfbyfZSoTMWcvRVYSa74XSCswP Z9ZgS5IvQcKCY0OjJ8bZQOC4BVTHRieCgeO/3d28v7mHfxNlN/l35SH+MqSIReTkw2b1vhTWQ83C z6qIC9phRyTl11BeByYCY+yjwNi4A1XsC3w2OuogDoXXeIVsz2eNNEq4t47ht3oAMgK+wuRgaLTX YOhw9n9xsEi41qxmzesEbeWb8AmC1Ky4jZ8RxdsE/zcLqI00Jq0oKYBvDu/nQ6HWT2vz6KOXCR/T +sFzKklc7w7bmvLvuGk7pLCZJWIKNChrsiQGpD5jyOcQ+7NcKJ2fzZGNB4OO+RTLmvNq7WshCqKP 1JBW0DcPw5C8ASjzqdTfS/btQu4mpTSaShZpO0+hFwVGXM8YYC6LaGbtTi4AJMlf9NP0z9qR24hj mZ8IrsgPAK7wrSgkksHUTZQw5quIrzU437WVJ5FvQCmIngVoc66UavA52nHPcqt5IXWKf4p7BJPI BIwyS0AXcJw3ZV43qbR0B2D9Of55C63I1NEsmzrLnVPXgCJEd/gkf4br6+mgfSB7lrtJQF4Niesp fmEe5Gvudv65kVM3mUOQPMg8FDXJ8QIyLS9B4J5XHwN0R7prXIcH2SWYzhfJ2L9EGpmXGRqsLiFH z/I9vERv5B7438wGLiezTn6H7+MhvoDpmEeRqp4XuaZqiG0rz5BjqCoIPaNFGI6kpO42u5Fj6snU VFrhn7bbSzaLlZwc346M0ubSCgh60bFmN0nYnXRee1VDqxt5pL4Ul4nvLPpImpR0cZ3vQUDzJYpV 7DlrrR0B+aUp4LFE9TmBUX/9VSHPxO/ykvEirXgZ5uFskec7Eeu2Un8HyBDXTOWpfIk0orvHMaXl aYidZ8Rl8RSYmeo+LcjEfCL2JrMeA7HCEM/qg8RlF4VVMHGU+eTfaa+I+xToJCD3zA1MjNeOjsze N8owszA89EfAIWCdg38E71OeQz0DhiorKZK6BRBOX9SKAv6j5JOEa/xwuEMZ0zhjmai2qslwj1IL qkZJmSZvVSvuT/JJRNY32xjqT+ZFXjDCfA+vDTCYXICZmxQhOpVKJTeITHyO6UCCHpRLk4XEJXv7 Sil/PCXgfUAL7qUQUh5COP5N9CxhRq9FGauz9S3uMomszcFw3Miu3/cNWJsSucG0aWkVfD1wKVFU VCYtGinLFzgY5u7A3ZUL5l1P9da4O3ATtWJ+LoGxpvUy39zGmXCPReulXIg19Y2MTwSGh5m8qb12 jId7s29nV5VtdFMGXFyOb4CoAPVlDUHkAuFhjXS5Kd+NaYN0xON47rXMMDoSKSytI9V6Qta/49Xf TRlsHDsdQciyYtxyNiOLTdPI1ZCJLJZvaAVVA6eNUaeXa6VMrz134nJiGl0LzI9mJvfE02mLBf8C cjcdM27NTqJf9XYy8wmoiROXuSnLadn8TgAA6K7IZKlZ6bx51kE45Rwz6/m5bE5Z5Z+3cpTJ4nJm IyF6qo2Pm1KI+/b0Vy2akoHGAtg7AAAXE+cdS/bYK0CmgBeofhUZmVrUw/yzFlIghIgUrBz6gGuk /BnKh1ZMrmB6hW+z8cKauZyf8/ENyKAahtfhN2XAUKtFGQwhLzaU8ZJvxF+AqEXuJVf4Jh85G/0N jOx2t/r5JuRM/vtEEbBCTl4De843klrn1Sfaa+0J4ujPj/DMprxQ9HF+vk5TS1nDs6K0yjxcm7+j zD0r1susS2G5YKSIVVU/A7/dhwGW2+N2tfhb8P/y3742L79RlAkqqU0cTVDmupTXX7D2MnV1x/7y 2BfBNh+Ag9bjY/xw5D6n8TwTaOQbcAc+kMIQw6PUkAoqFuDo7eL7EWrv7ernn+FGlP1ije90U3Il Ni8uo080TVDOVr7VU8bDth2rFlaK/fcOlFF4TXsLgafMGu53iUkMuQSKO7Cnq2f/R2z/LtbTO7iH e4sifQtN2mCyiiUU4Bu5+IaqlXLknShUIfgMkSlgQL4zMtbC4JYNOGV7Yw8ryXttUO6msJ//jNzF vCVQBGa7Cc8X2MHg0LER5qm/1Z3wZo/fNdi70+fqPnSgw3Wg64AfYlZPBz8sblBqLaJ05u/nk4CB Br4YPXZipHNwFHwBhl9l91KdQPsg+OdOZDDIZ0srhC6Vv/0+D6/qlA6QH1uLbvowcPyrobHg9k5w n9oyhA2iOCs1mMQW2INd3R7XQFe/x7W7a9DrOtjV43X5W328pFAKoeLULGhZh+gvkehyFKVdTczw g7gpTaIVAbI89kO/Nfk2IE3jFiVwTNwkGQGEY5tQwCSw3rAxRTxgy4vLMcTEvAGgKB3CSSH6fTob +Yba6lLm9bb7Pf4OT4fPz4sbhemcAXHZcQTfhYTsUeSe9jo94/BwvipBouC6ZJIBtOze39/DN1M8 /ULOJabZLjfLfocHCeByqzSAguCSy0cnh6sHawsxQcphvykOTqWAbwvJlYZ6SpGvqUtCKoVMvAPO QGX/VmMuKKTVFmBjNiUBYxSZa6T4VZjKxvF5J4s/A3CC64R+Ag/e3BTESov5MyoEC1oYXCA48UvJ N+ojvhMyVIhGJEB4P8TOgemp1wl5mzZzaiLJZk/FbpAkGC9yKixi9wHWpGr5++hlLSvCr4QiWYdB Yu15hey2TTbmuxxU++zwR5mEvZ9NRWp9JUW5WTGJGfdPINpZ1szMkqR/WgNI3RT5Wu7KT1gxetuK Set0dVd5L8xpVgewbgqIo4+dCcaqn1RUWgWt2swmo1OUDgbHja80N5d2yvZmtHRwG3IYs99YvtIo jy+eYspT8zq9qFnVJIjgcQAxDwPGnqurNBXPSQrIjfvSZDqbMdQfwBAA2i6nRWAL+L5k6SFW0kON FmRuait4DipRLQJOZodXzqyWmwJ5tLIYlJUM/+CeXtZ3cP8+dqC/a/eh3oZcm51Obmi/akUAyJkN kIIrlA20zrmLNCrGeqCJ5VBmRyOeYS62b2x0hB0YDhw7EYzNYBpJVme0QnwDPmivzWcMT0vVtR1M 2IrcU+cajRR7BC5tDjBY7IZ0Guy5vgUeKiXJWzMCk8PSKlb2iNpVc6kmae+m/AWFZP9IXjzqSzVk 7ahVh5D9uRS+Iq9hfiynaAYhkpKgpeZF9X5mqyHFVjmCHdY1OyhqLfv0f0RSPWcOYLuQzsY3pAdA iVag2g6RndeYeV2RrGqr+iQJq7FHNlal6gvhZxRh8zIMk72IGaXLeSn/PQUYDiEmOw1zR2H7QTcp Rq+L+iyaAdHegv2IXRBCVBxTUsOb2rQo7mCeHmCktweZ+kY+DQGoHp+dakBy7py+JhcYmJY42Lv7 koSxXjSlYL3Go+QCi/1V+JFpizAJFuZA5DNHqaJtDYZTzwIDMHeby7KDB3YDE2I/pn7FU7CftBV1 Dayk/Ab239x0LJ+SLlQb5Wm0ZHdeIZXkLA4MHrmXmDeXYltgt9NZYbKcVbdHa2hpLAvlySu2eeK2 dpsjLvFYgapxJrMGDlEKG+cbmkIqvdlhuRUyXMJUYqY64eymdJp+WkN8scvd3mg0qmQEa3gXV4Py 5xgD7fNHgHZl8HkIVWNcI+XbwG3NM2kDQ9XGMgSeXPgF7BDSGl8SVq1trp7MbeEV8hRGDo/aXwKy r3+mVBq7jgfY5hgTrad8Titi/VQhswRW1oYkdYeTC9G7IHfm1fPn7bdIFJJvdIkrrbpGC7FTLtit 4e6XJhVCZUmA2al8sNpRu6sAF2UY8wk7Z7mcCAlPmHGJcgB1SdeXUikWkbEia00VSfEtAGrxGR7o Ya8iAdrAsrXoNfW+05BRvlJ9YqSkOFNn4hvgH/6RQeOTXY6lUNr8ZuIRU3+EzW+A0q0xKqK7jWVP plIIRb2stAd47EP5INt040GUc389BL7lzegc5n8sMXirRXNIDG4kCAxRQUSUD750PNWpLK2+Rbsp SaKIimEjWrAT8GSFzUrJldh94apzNCylvUAHaXV/7MmAmnJIAmxQnkaiVA/nPJGjPXUwwjpyoKMM UNv/wz47MTYyNHKMHQ2OT7CjQyOB4cZCn1qI3hUfYDHAK1jGDDAHuJieUYA3yPLXduq17AIdE6OJ GPxD18GmmVPSZEO2I3dx7ywAUpFObiRKPXcfPDTQ1dN7cAAD7L19u/cMst+wvV27+7qrR3bgQksw 7JhdXyOlceBkcGJurZg7C2oQol3nJ0bD82HfwcFDXf3swP79/WxPYHi4MXDTpbI8rkSkKrxGKW6s vFK16G2Wyxm52HwFHtcdEfNfihS5Vn4NdkKRokncifnECv5+zTQhpSDbyqXmlRnRcuzq6+3vAVYN DB7s7drLBg/uP7DnY7aza2AAYWrvf30VGBnHMrr+wJfBcQgc37Y68vT2CjH2tOGiEQaAYSqTIPAw JLThGb199s6TQ2UDK9GzRlpMQKSIa3+rRmYvlo0AbuI28hYWKiaYASaNgv7oM8DqJQ1ooEUOmMai ocwWLEU9Y97dVs9V8FSj+fuoD3ho/dE7MPh2w6WKs1OIvG7kdXIH4ApK1YMcESxyjY7JEYh//TU/ H9rIXb/tcrnbe9nAia+CY2zP6NhIcKKh1zeMXC7EEj9gmmEHniQXYUVrINfg42/B7JIhitGbELtE buFxiBBqZGgslM52wdRsdjJ6G2ugQ/omuGWsg5GuiA+YsIKluDLEOVfJJDUaKm3qp+mCgb4EAiKf i9wjMxJNoC35KwUV6vdYLxuN3p95oRXEtUYjlXef55GHTwN6MZSm0+Do3bdvTS4kX4JJ09noWdQn sKIkOup8ShFF2Cqy2ems9oZJsqbYq9bMhlA7lFaRR9+JajqbuwYYsCSEtkeCpZeoBDCrncECIgr4 69t5lBbYgyvgH/IzmTWr0pj4jkj7RjqLFx9gKWggoY85L6w2HGvRipG+rs8/qlUJTowN7Q2MDAXY XioKbizQ6tbsC6a/ksJ0n8RGaADHMJeaVkAxQe0tebaKx/92/tdGhAHRV1k2KoXLVeDNTP459gi2 RTylFfKSg050Id39+wd6Wff+vTu7BpmvEZF7B8BYmiyiwF+lSJby8hASYmIeSzXysCPVbooOvg58 MRocGfqvtwtP2VGp8woginB5zaARekZPwB6lIvmseR3sU7qoPi6XqjfYoWVpkkY25wkGZhalfOk2 DtbiQShhuzBrFscO0pncR3t6e/vRGw72waO3036RVZlSCxamsxArUYxossy8+gRhq/WJfGLtcOjv qywYVe7pekRS739tfcAAWltEJGndkUD1V0N4IaJ6OIzFsAXM1moqA7ZBTwKwSetAh3JJ+zZyT9+U JDZbzGj8oE5WtNmJbIg0fv5fIVOmpVMKxNtb1aZfXpLyViAGelYOxrip0J8ODB1he4NDQayJ7xoe Co5gtdL4+NGhseA/kBzKYexgmb8YOZbK5MFagxas8UAFRIhgYjpb7ygHYUumJMiwhcpr0L8IS4FO ojPLZRMKgLEaGEDnqtxHn3XE0bdvsPfgvq7Bvv37ANzs2r9/cGdXf/9bg6C9A+R8o2fVGbyplMve jUh2sWVvF2gBpc7AfC6DcGfMxAzYvHg0U8ey65tA794BhDHXkhtM+kF7hRHui+wLy08nWTQZfR6b oVpgikjAVeclJFutlzezabIuwIAU0cU0WzylB0g0TNXbhQljjHNInuI3wMLWSUnYdgyk+Gb8V9BN CWcHj+Nj77M2f7u0LhaJC/K5hM78LXS0jOmzQnKDzsVrfETsAkizNVuJJnVS3yrP4MwhgShnsDgv HxFe1Y5mD9PVR3XXyDBAGrqeMUrDgLdQQ2hhQeRsa8JtPUILPP3CQwmWmFYevh1+XWYev4RYr5x3 8embEWkH87QLUUztLKcW0NxL4D5nmZIUbmNKsSEkcAaepfX61Zdg71JbxFS874AHa2klsoY3dxqN 5Rei6ku66BffkOJGmryK+n32HvFB/T6zyE9XqxKIH7qHAfk2gYsA3LqdNZVc9/b64UQp8krnrJjn 4IHdfNwDP7YeW1eFIgpYjhp0VK50s7YMrO8Mw9tDuGXwz9mnqYV0TivoC//+741epciPDGSJjFpQ qRXsS0roECVMpFWPJuXVx2izFRTuMlUeSmfFsELHooxEqWRbQa9iz5WFWn0mm08CtyBJQFiJJmJC c6OFgMuz77LRQrRv9UW7xgOs3Csg4gEDaXqD+BWcBE5OilGzO1MQ0OVe0mER3qUDsGrc0p9aRgAg 3ByBJ7xeA7bJ5gm6EkwLPjJqErvmPbBH6Wz+vDAHJsSYngnVCg+Cp90HWltamnaPBUaOsANjAB3g 43ZWOp+xawZLeay3nVtwsAnjaiCLRBhtPR4BYiEhIBjCNpiQa6AQeE6EwWL+ezupU8pbgKMoEYUN +pIVvqGJVSSNK62gsha8z2kVtNYmQSvBDd8N8/QwLjxEzLLDTkEqxfwc/vMUajGD3Sg0jMqYuZDa pKwfHyTxCaj2Dt59Ub2MOqfNV66/pJ5hLW5TJTwb2APebP+hwcYhmqy9ZvJmNp4TSFes6nDMDdC9 XJQcXqtAxmBjagcrJdfBUmr36M6jaGbWFCmdjfzsyKFR+Y66CRsawgsqHvtsrEmZNM5Hbze8VYLH 1RDb+P0dfpdncPeHrsFBv8/VvW/vh9zQfjoP1Yp0WIr7wrU5PT/V9sxOY7mFkQaVyP4EhHu05foG r3xCVLam9iVIDDtYei52A13j71CAo8y6WotSZV6vv5oaMNXurZPU5ZrRRHd0xFbTCv6CRimpxAqf FqLCIjsv2VF9tEsVRpWPVFOUv0bigj5DK8ibXBUPlRUJq9JkXmDuNu457ltKz8/FN3I3+fNxqiIq V702DezrZMfajvzn+NjE8BcBz2d/+tz7HxwxVFmEp6P5R9o8IxBKl1mahNWIlNB3yA/00zvS+fgG /46vXOVhZXrVrdhzrtnrXJ+HrynlqiWoxAhEG5Og3uqdiSbVR52VCgVEcK/1zVQhtqVc2oZXBV6I ov0yJjDXpUn6kgP7FHSl/kbLP2gS2u4V+YfMK30Tz9G2GH4TAar4RS1TFX9RoRO4/GfOEjGqcaou tKFjbW/lnLpmKTact2svC4gKr5InZtJNsjEYp8GasktCSDQI2jXbhrjeYrA4Q3wA+n3+Lyz7jbqJ 4AdfMIywcRmGkWTgUdQeRvtVfADPKIeyWW80PWrl1i34afXTt/hC0XKID9sQrtUYq0DLNHJ0tbMJ 8SwnMFRvtW9nV/1Gqnp7gXUkXJkEVVjJBXEZYpG1cqkJ1+7jKozxqKq+ANmCkrlIIVMBXTeskj/P 4oa07vIoj+nQ2sOaSsdl2+uP3dFhzsu3y0fg5dM1NLpliMuPj4ogiYhYWP8AE56ausUQp3mgOi+3 ByDma77Qj8q7jAU9bFU50jl+AwJLJ1j2YR+AuTwufEeJG5VRMKhbx+IAglRM+MX+ppBaCSkv1tuD ZcPntGWytSgW7Ox+rPO/WqM/VFuG36wgheVN7jEdmWXBS99KreXPcNVDVD7GVSUlipFrWCtHuK7U x1+/xMxDmV08paoi38bIRf7MvBTXAJz9nXV2yuhk2w5wKCkwBzSmorJQ15QgFhN+5RFSCbg9Z+ZS LSda7YLekpt1uZSHiRWsiuc6oUjv6sLaoLAM1FAZYhMGsts7e7uskIrr7a0akmvyWGF0WePsBBSd mkY3rOw/J3FUDIa3CYxbRtgMsyZvT+mMgO9VKvtkYLZE7bWnvm8uiR3mePlIAksuwPY6jpLREFu8 am5urm+ytVd0Hom0WD4AgnYLudtkUcGZsiqdZ+5mX6B048z6upN6amGC4NnfXQEkYr5s9gXL5cwk BJEY5uF90XQ2d1kn3LcI+oOD1w/3kKF0Llr6vgIr4LLeUECa1DX5jibRd9NgFxZdzKzF7sRhC+oN Z86jcyoIF6Bf+ZrTNtD8FumOEKIw3l4YJ1q+dketFEv/tan7N91oEbdjPRGLP8OasDp6UcKb9/W/ sVTEjBKgovohFj+VukLMELaE24T5tenYImyEuKYtYxYKt7D+ftn4EpTRxBgnd840MYE4K5rWPoKZ XBJNh92ler58knuAKi6chFCHf0g14hBy5O9jHTWd0nKtPute67T91TXl56gl4qnM+dw5Xnl8XLWt s9qPqvP27eoHg8c9JNt7Br+bpvKQavDEn5yvU72d+SS3RJUFpYd0umbYN2C4gkWrpg5vP25CIKWG TDO1AAtwcwvw2pZjztmFHwSXHtvSXucF45Zj8VQj5/uoh8lbQlSUy7Ef1wP5oP3CYvO52/ENuraF bolx+JNq4kp3z7nHVrWxuMIy1zE7XtRe4QEOd98D2ZNZguiL4xmVmGH9PM9dj+OGsKMF+ROdzhjx DarHViTHLajW8nVI540tHhrwF9kIUaQV5+0uHGMl9yPzNfM3Zt12rTZ+64Ndre24ZIerF0Vxnr98 gb6rKC4nItGLDnqoRCRyP3InIulxrEDha+nJ4eV+VU/xldx2nW3pNrVjMFKDKGAilwu/jYuvGK25 Gw5dWh1dCOGsCfzdC6pZLdIFZi+rHRQZEbkG1tUwYyvCak17C10OAmi7TnJZ3d5BVZr6ZvYkLN1q 5KO+2op2bhPa6t09repDsU6pokF2HM232jdwsORvBTCr16nnZAA0xGJWugCvEPOUe+1bf3SJ0VOz MGJbBgK8u/mkBQN0I1XLPug1Mx2RMGuyJSUTOu3l/wBQSwMEFAACAAgA4YXyKlBodMguBAAAwgcA AAwAAACxuMDUuea5/S5UWFStVV1PG1cQfY+U/zAvlRLEWuuPkuaBtP+FvrUSUfPUn2MgRq2KuRvv eu+u9+Out/Z1UsMG4hhcZNOkdXBEQFAq1w1E6ty7uza0fajULkjWzr0zc+bMmVmAG89i8gBolHXA emN9YB090nuzo8Xbt27fgjnwWpUjHjmO/8un6OiGxhnjQIqkT95L55lvBu8D0DPjSF7T60BOtAGQ iXijlNWgduQf830ISuwAf4whrSR+MpPb8I+ZDVlVhY/ApmzIX8pjCA9bq4YBjLtPeRSMgVYFHEAn /C+tlor/+W9NBFppbtrEcVikvSarwWFCyOLiA+A71sQvwsdsKItwQ/oWnA373EW00paWUloRgUr/ A6LHcXVzwANzW9szH2MWQTdHdMCuEI22Nztrg3dafQKEB+N5ybL1AYxTJFO2RHtt19glo+Y2eD+Q EyAjN9TrZAvdgsBlAnjSAtbR+tD6HvLzBRaJ43HlW2TeIoTjm2HUJ7IB3jPR3Df+O/yxehjW/676 W9AVXUmbOYXGUQy07F2ANWmt4n16bkZYS/0qqPLI/waCrvvMDX2WOgppxdRLAwDpsBdCQaAoUFBV 1Z9IM9ts+qkZJTOzux7/J7t9bpz57G8nMmfQtcpIVh572a5dUArWIKYlA9du8Mjl1XVRct8YuuG0 RGBtuu69xEpBFgmAjEiH/YSTuA3/8kkmU6b13zkH5itMyYbOGHtOrsjIm2ArYiKSuQNrpA8QPymy IbTKLuc70AitES0hNDFxMQG0UpuOHEYOHc3CRsgbEQo6WEO8E5Fp1y86G5IFVnPGwLrBGN9ERL0u Q1ltWpY9R38hyOq6VUZ0zRNMnPrPvBMqk3aKeRKhkC7/lL1A2AVlITT8SbBmGGlBxmX1AkPY24GJ IZN7QYkU0aT/HO+FabSYJFEsqjfRJ6NySK1D5yBeGZPUKea1aG5isMpGuqnipaNVWpvXFtNNdVj7 AjIWHVb8LaADFmGbZ0LRe8iRsNpU72HE4PdgBQe1tZGKIRJDB2LqJHLZp2TBGdwwzOj6batXncRn kPDWGujHzT9A7Gw1m1Xuf7JwX1nI51V56DVZG4UtDh8uP1z6PJv77Muvl5YfZZaWM198dW24hYaB 2fynGyPGd+xLYcTQC/cU9V4hn8sqak7JqVmAeQDf0vpBFxTQRmzbMdPVJIDiHDxhuFbMALXe8A6B 75It420aHiCbkYnZj+DYvIMfDaEL+7l8gzuEsJqcKYTwHAlMAuHQ3JVDk8tIVuRY3RGyQX5Icaq4 ZBJZ1zsVqSWd8zggNOk9tr1zN50+RXmQsIgrjRT1pzMd5TPxjqsJdBQpQgy74qCQSWlrgNb39mIq 58THKqxJayKgsOto6K73+D4K149sbDjp/PVTlyCxIrGFG2ZRiAKhUip1Tl6R9yhj71cBAYUSf4Aw m8j6J1BLAwQUAAIACACAcoUpevmGubYmAABmTwAADAAAALmuwabH2LDhLnR4dLV8e3MTV7bv/67y d9ihas61M26h7pZakutkbsmS/ADbGElgOyE1JWxBfGNsyjZJOH+cz3C/gsMjAwlGjiSrJevRQpbk ZIwdkgyvZEKSG4YQAkPCiSEMqbq/tXe3JD943HtzVTNB6u699trr8VuPvdvNTbHPjc+MFZZfTlYT F1jmk+RtI8PyldSsUWUXnsTuLt6qXjEWWUbPZgvf2ZrN5+NnWbWYWp2/kjqF54zr2Wz1EosvFu5g cPlOrqwXC7PZcyw3H/uc5X829Fw1u86MyzkjsZa4JogkC8snlnX9NIvNZvRcSb/NYmXQ0u8nbzG6 n6tWv07/Btbqw6wpizc49aV48iaLPUmVrOuc98SdzGrmE7bwX+B6/nHxcv5e/gYjYvhd/TS73txk EbRt5XvxAVio0RUsYq2xz3OlShUEjJXCneoa5zb5V8FUc9Mr23wYY+UzqXeZWAVjr2z/oeGMFb4r /sziZwsGNCDYBxe5UvI+X1DhUWaxMEsLWmGxj1JF4zIei/2j8GNslulpcylEBiLgQsfA/DJGEAPJ Zc5CZclYw/Dk7fw9Gp48BV3aaHLZxgo/ZueZsZrLlG+x6t9Mas1Nio2PzJU4QegpftnQFx5gbv2r XKm4jtkXbkAO8UW2tFRdLF+EnMq5xfX5bwsWF6lPWfLmwgNjJb3OiEFYmaGnVjkbsdlsOXuOXx2Z ioy8ybhR8a/RUcbnqTxO/IJ5SycMy/iam1QblsnvML5Gc2HVNQyu6ZVTpcfo5iLLzpdLbHmJ7cik Yc1r89/uYOn1SowlzugncqXY3Tb+fHUteRMEhSAgNpoDvBoryUJ1jXjF+GuFM/HLG8bXGAOFloxe vlNXYM1BMszXfmBgavLwVOQI6xwbj04faFiBKXlhTrZWk1bxdOIOZsfMK4lrZG0n8/dYPlP4J4td NFaL6ywdy9/L6KRKtqOQ3sEgKFonBlgcOWzMeK8UT8WZabGkTnMaur+94b5S8/qn2ewzLLlyfvkh a0CUXMnClKollxW2eKtwDw629H7yJpS2v8tL34wqhlvGAtOa19PrxhNjZeEBBM/9A8PucIxKXDNW UpnKHBtimk3mZuOy2VnsMYO3njdWQAhzk8Igfd00CVZI66eTt0kKJeOL6ppxXV8wrlu86ldLNyDf 9Lo+Z/oWDPBRcX2Dj7QJPviQDFP9fAVgNf8oVgYPwgnw21grngS3+VuwneqaJfcqdJb/OHGBaxc6 XLGAyvi80eWwuJwpoTbu0NXlmlig4sUfF95jRQKAQj5+vu5d+mLsLqdcupwr1662xN410RgQnfom VyVzM52kFdaVjS/NbkCzuovpc7G7zDiTTBZ+xLTzP4H7gpGaTVa4Nfp7e03Pw8Jx5RQrnEmdh2hh yl9YPpn/19Il08PFDcLylcUH1avFdVPKySQQzNATa8y4RcxwS6V7F3EnXyleZsUiZJ3+BwJBXUww bIEueKiYT/2KVSX/tfAA1pfNwN3L8AqEHT1d/BQe8Dj9ffYzYy27nlpjuY9q+Aam4HhLpp1iSXwV QoeEXyBdvZR+xKpXKThBFoUPFv6Lpa8tPKqx4bSxhSq3CdMkng3U+Ur2XJspjQaAbkBlyxo34pix lv678S/CzTYxIGMSgE9ZyFmDSxIFpzavcxSg2erwb7rg53Xi0jYfSzhApZblk0YmeyH/sI3bSitA 1OSRfpogWZhNXIttjTaLHLME7GfgP4AlE9sAS4WLsRiHbZK8BQzVq7FvLEO08WTA4/mDQKrmptmr Nmhk/gvTKHmMSaWL6zkggT7HMudj/+B28pLpsQ2hCOg7ODYxOvn29IFg9HB0dGzGFn0nCrMmXrnX de8ODP+5d4/P2/vnPq+vu6c/cCB0fHomeuSA79jUVHRixjc5MTM1OR6Kzhwwvx7oH58+0Ds5EhmP 0iQiAMx/m1mMnW1lO+z0ccjKDvbKn7Zctnt2wPmIY+5sxq3MaqX0VDz+v/w0N71M+HECSFst6udz GbWlayoyMcoGpsbeYWor22lFHkR49x+4oNRRm81WmIUn619lz9VDfPp9YMRphPAYfIklzuEBMRZK K55EzsSDehVeMjLKuGFyQ0XWyANu4QyXNFe2pV6BrC+zxX/OQ4nMxcBP7QdGmqmH8aSUZcvn9Nt8 ihoVfmWF0jtCkuo6WIDbrDU35e8BFcnlTDNhpXf5yMQ1ymNo+FXAZ+7j7D1wALxHkhCLzWcoG7I4 grTmstlcBjIwVpYKbC9JasWC/fj5C6cQnKuXyL5X849NTwWx4slqjPCsdOHX2KwIHQq0/WnClA7i i4EMCtz7/BQlvkgWQCO/bEISkTC+yD9k1VPIrq5BhgUDiHThY7g0AOh7/NPcpC8UfgRnlYfGavki NJI8RcgknmOJL0s3cI2rh9hMX6GBJ4oLxZOYCMnKKSRB8A2Px2MyRbcIcUGEoy/cmwuqgW/xSLaM lW1SXfZycQ5zZ34AO6UHXLgs/Zt5t3SJuRS7/hUWWjyZTFI2hPSKFe6k5sjRPyaBMyzIBLT8o7oc iRAYIYwrx3Qd6foNxMjUBa749DXTDCwujPO4QPyylsCxqUn+ledQve0HorhAv8nbraBEE4qv6SrP 7mIfmbbc3GQBKGCLEGtjVHyZdXa6rVUKjBEQA5EXPrDkotj0vxmPmc+MzJkfMEfsBL9Lvi70Z+oW KqM00tQNPUOhbZGSTl1P3p7/tpa4molw+QP9POwXfADxf6Grj+nJWyZ5p83nD+7p42oTczY3abbM Xf1DnmzCc+m7kIB5If9JyQJrH7gCZTPrpRtUL30gyLhstHgl/ehCjBk36WmaCbKKI2yJteMpt823 k54D4Y7enj5bYChggmz1ksmjx8YrMYq6LLlsSU22czbhrHC6BOL9NYHbfDlm/i5Cs7iGVC89hwzu NPufH5S+ESwCfl+jfIkMFbGWXBD5Fve3pSVcpAnwTwCLswbZbK9jbtkm8jM8WPi5+NBYMRM1Mv08 8qZKVciNc7ZUrMylyPeN67lyYZbSDMo1snF4yaVaxF5J6bhYxzy+ULBhJSrINU4U13XdZrM14M5a tUg2Uy0yieXvVR5eQHXzMJfhQVP8pp9YtLDXGq4STHKww9Iqf4l9SZVkiYMgsSMQmdvELM/0eFm6 pYBiTI3FCZYui1Uk3qcxkIISi7P0F4jxF0hnGZ3ko+sWvFpRli0+SHyJuzBakhPRpRkKH2Wpaoaj i9oEHPP6vqEw4xLC3GAwfrasx8+J+QHMxRuMTR49NDllGx0fx7LrAoKpHo5Gpg5OvmMtBFfw0LRV tMUv83Q4flb/DNrEEsD9G5HxQ9L42KFowzO8TOSp7vHJY1Mkqzejxxce4DdV4/pt0JiYwaWGfIHz G9rZT09CXvQcHud8bn4Qq00/Wj5BGvsXnyt2BWi2yCsQU+ldA04AVN+e/lDYyxX9WvGy/tPrMWq5 iOycBtbm9flrdbjg8YLpVxTq47gtRCGomv5HZExk4+H4KgggFtXcUjCCkFZ9TRkZfb2d9RAzSPBh V6FAeN+AJdQY+aS40jAwAVyvPHTsLH9XRuqdSvxmWiwyYFhyYX2ncREp2j8Sv2Tu7izMkvXwmFE4 BRtYAR/KTnp4+WH+Xmq1eE/dibRfX4h9nkyxnfr9+J3KY31OYTs7ezq9BOU7+zu8vT37A/y7fr+s 6yf4+OJpA8VySU+wpYL+dfLmzthd/UQ5JrtY8l7ynuljTATxxZoDQYbmFS6NT1NFS8Yl+CfTH9E6 ecMjm+XZELfQs6grBOIgelRJ6Om54mkqBCuJNXg3J1nlFy3tUALBf18QLTHKdKufMt4Ts+ALdCQG cNvkrlynlj/BJXxBr283ey3gf12EANP6TY+qXk3csha6MUdnhTJBQ031ZE75Svp9zhcCcAOrqfla SsWrkiuI0B73HwgdVkQttsir8QZws0AsPaffbWdLf2dlMLdUWBdip1jOahWPuWaBQ4LthhEMhV2m /B1SetEduSxK5pGZo3XMQtnFyzVcZJZ1lk4Q6FPjiUJ0rlT+sGaiuTJiVpXlb+jF9sK5atx40gZN 5jJL76OCyGRTt7JVwaewC9i9bLdT90Z0JKm6AV3qEfBCnyfIdZugDNkSnUiKF1nsHGSK0vQb1uKb mRpnf2Te8Zk/Mn90PDoTFX2n8vJSK3HJKMALNCUSAlDrKk+tikaZifTlmKjWl+uLy5R1iHK2isjU zpBw3KI8SwjeOONxFu6IPO40Es5ls3pbeEDZ12BPP9Raa9YRTH1Ss3q+IG5FVucAj1U+WRIBg6W/ 4pF1kwEJjig3BVdXjJXKnFtpY0u/GivlM0pb/Cxd0b+CBZbP6HOlpVzGlryfzVfmmGpDnf3T/Lf5 ewozPdbsjCbTc+ztsQnKGLh3gQuzNCWBtFL1vmz6qNmUFMgtFFIvELG64oLxRfVq8ev8DWatEM/8 O5+CVrpdSWkmq9VLPJ4WZm22P5n1ZfDYBApLnlqyFnDoce70uFuZDV8neH3Zwr+1Kphma3kpTfPy UqqVl2Z1KZnVpYTqUhLVpQoC4puVNVK/mjNLHFJBw5f0Ka+iM7Qs87nSu7FZ04XYDlGD7mAw6OQp KIQ6VfUy1axQRG/YZrOeNhabmwi5ReaJGSntKpyD090t/jb/rVUfmgTPAoMbKl+IvLHgbW5KX/vw GpSPCIchH9tYS/GfcBwxFZymkKQYYCYFvAlkfIb7yOaRDPC+mKiU22rNalG6AJBvYJm8csHE5LZ3 S0v5RM0gETMYBQ3m8XCVc7MWIJhYY7EzxnV4nPEEReVpRC3qe8GC43/nflP4IPaNuTPy0ksYW1xk yx8mEDtEFsQfZBTiqqXUaup86V2umGUohnLCNkqA2ogGGOQoQtOQLDhh6tq1sV5vf20qPFbKls9U Yem2FoSXz1nhUQpZ4/3KY7iJsZK41lqL9vn78Dt8m+cJnHE5/zi+BEaTd/ErdyOHqulGI1AkC/Nf Lf6mFL4sXGTJZC5DUuDimP8in6eO6+PinNiDwFJ5ZDPWMovQV+XXyhzPDPlOipXmUi/GLTuBhy0o 2k9XqkIprW39uwAsbdQ4aiQAYSX/hUXO6zDY+Z8pgyEqQHIjl6+2hCmqtXJojZ/l0jYybQgyuaoI ssRwiToKhXPQj0jYhYmsCHb6QpJ/T8g20NMZP9vGNfyf/0m/GA/m1HsDrqTWiicztOWU0UHF6s+3 xe7Of0XESStE3rsvvAe5k8/W4Q0zSMu3p7+zp8sWGg7xLjv02lI4M/8tSIpGLfWBRWLUyhXHFcSz ylrbgZBbv93GqvFsBmBCa6YGwm1K8+pJAKmpfF9fMJ5k41w1mZ+S9wsGzchk7eDYDN8R4EYvamDC eA7PbMAb9nVTp/ZnDsxiIBndk9j3+UdkERQWRbAWE2Xups4nbyqsLYQ48PJOgbe+faHwvr5aCmgV X1bLnTrudlbL3Iui8Vzzx3pWmM1WPkydV0XtUnnpJZYs42EzWebenfmkjccTznO+kiGDsFhDYncx lTZWsucUToF62KgwajEIYygAYYQISemvQJA3//ABUkNM7XXRSMLhJbYTwbLysPQQXwuzcKm5nTSa 8sds1qrVRbCN/XVx/bXe8OuNnFi7KDRGhJkLDVr7lZ5K/CJWbFwvZXlvyViNXWSxGC//fH5JlLMB vi9AiGv2CLhJcfOrXo2vw8dM2zZHihm842ORaTYYeSt6aAoxgvVFjkfYW6rNTrcp06Oyg7Y2rA73 yy+zkfbaHDAFUU8kLsBpRH6JmtV6mO4hD+kdG4lOTI9NHGaIRceOUkLJlbyQ+zhX4g1l8WBzE0/p fLz9bCVsVqiZPjwWeXu03nTBwkbaD0TePjAyeeRAdGbkQMMDZlHSkrxe/E1scP3cWt+EpEk2ziFm iLwt20YjM1b2SMGoNubfRSU3eeTosZno1J94UBTlOu3siiaCsaK/x2VgRaS/12RGm1+4IR7kz2WA FsUFCyyYfjeFwib1KeVb3CDfmJyemYgciRI21PpUzU35v8KxqRnQ2MzX9fzXInU9NB59Z/wIm45O vRWdmoY9cf8s3qDkDOOPTk7NMJfDwRpah4uxlRqhUCC4PxBk0O0qlsUG8Di1/ohy5WFlzmwv03b3 RgZoY79AhgVE2KwnM9033luaxfiByMwbhJQ8xagJiFYEZXoHD/j29G1SZnMT1HBps3LocXOxRBkK j7z9Z7Fskhp/lDfiIOpF0cZHkfzYuFnTaN14Do5NHBg/MjM5OT7dYF4ilFtP7xiZnDg0dvjYVGRm bHKCHePWTPPBtKd3iOh6iSy49mC04Xa5aoFbzTPOpddN5rh2xXXWUki3syPwQZUWhxylUbLFdWqa 8mKhccwLf3jBs0HK40cOT5lC9rUf6OwNDI0fObBFkE+/OT55mLVY+3KV4kPk6zxOFB8W32WNTGIl O45NN4iE4meOMhLqqFCdQiCDqDbzRpSNc7iImlZsAhCjHXakLRQNMMOO6ZkIbFk8wqDso5NvR6eO Hd3BeC+EaG8U+I4QMA74w+en6ak7Srv3w6Qg8fsvtWeJ+M7QzOTRncHoVDQySircSI86pJzbmras rXKYAWOCBJ8vOrWDNbRk/9LQ+9UXAMuKANt6B5WqtM2Qt3yO2yTkzL+ZTkXjG3AyeZL3pyxXMceI oFS9amZZlI7wKxhfSl+IFa9Zbk8Q92cL4v7Mwadl67XW2G/LJ+olNFUNiTvUtWSJW1vQcJEVTy7P LT9k898an/NNknqZaWUzyVXeAC5es5BesGcen9ksA3Pl1qr10xRnqU9qEa/G7toofeUF8GPeVuYt Ge78lyyhmNhRFx6lRXxbicK/Nb54On+vUrWSbDGmtouEIhuPkCNTsVwRrADUaktEnS+2CmnX+evY CbHrYZaKn4rdelEaIRZgEG/dUJy/TLU+OX2+whZ/S71vMyVVvGxUi7OUAYtO06cL7zE1/cjClqsN eTTH7OoV/ScekMznbxBd2sUyd4hFlWtj8SsIOg85JFmtBiJm0TJn58YqOlps4T19IXGtLpHlWDaz TAX/0iVaXr0QfnnvscjUmyzwztGp6PQ0cyDPa3O02ZV/E9eHxOWByPQ0j03cEWodSuraGjmIf+n9 apW3aklYbW147NhRWHiUEqbZ+FnauptDyOL+dQID977jsCvHjm5OIfjltw7xbW3TDjgbgAxr67m5 qWGQNS2thrNGCmhueumll3/HT3MTP9/z4aP8PUg0/gvf+hE72F+WvjZWjJWlL+l4Cwpjc2+pSOGO WDEV1JL+e/ImsNNil1T3eWvNtrm3UKGHwYD/o+aJoUP8xBBfv9BCc5OlhgO8JGxuqondEulbhyh2 k5tcYrGHhdmGBhIZvaimVnj1jltMr6avglXZ7m5uOnh8JsqORmZG3oiOmse9at1PSnlpG5J6+LRZ CRJQa9LQ+YI5i3WvizU2qgZCNh545u+JLVtUj+RUCDxk3h9Txmvmpfm/EgbUkxbSudhP+YYZD/KV wnfsv1NLIDUPd5y/QgcMK4k1Ou8gGHC8dagFd8/j2j3e2OKrL5yb/9bcQZynAyO0kUgnARMXeFQU RyIY0Y19RPsoosogDYG1XxYecPr8tuBStNKpB4PSCPFO9EIbH33l993Nfx5BUeRgwfpc/gF7IYK0 g0vNeNRE37DYTyhit//Qbkc76/cG3VKnd5cm7fL2OqTg8C6X5HBrLqTpH+VRYKu0Cbtv9zPSGkHH 6bTLkuJw2J2KLKmy5nbaQciheZqbqh8nb/4b77592M7IDarV6s1KybE9If9whyp1ebvcUq83qEmd +17VJI/LAYay65Uv0td419Ful5/HkOy02yWH4nY7FFVSPG7FIzuJMdRy/d297NkkthByqm7ZKXsk u0ORXXaPpDgVFLH+aPQoC0bGRpEDvQAhu2J32q2P3NwUKxf+aTwx/vlifHjHx1n2N+N6mwwzFCEv 9W4737szHrPCSX2uMse3FrcO9alqUAoOaR6pM+wblvo7ugcklxNQv/yXwq/80F5ZL3+gzxV/fhYD rMvbqUk+b4dDCgWGnNKrw72apGgkCIa0KfdR8V4L4sDNyqXWZ6/ErWmq5PBomktWJNXjcLo0tyR7 VAcFn3OZH/TP9BgrY13lTC7TEjp28EhkamwiysJjM5GJ6dY6oS7vcJ/X37FnWHKFA90U/kuonf6W K6WXqHBHFpS/nLxZuLA9G3ZVhT6hXLtHaAQft53Eos+V18QhCKzLWEW4TlO/lOmf5ea2kNnIBE/z Le2wpS+XfiXL3zC72OsxXbqdKQHZ3uHr7+7pcWv7Bpz7RaUQHOjiAeRiC4Fqpdr6LIHCmHdjAQMS LSNkt++ye12dPAsh1o1VhbX4KdwHo2OHJ5jSui2RLq9fk8IBaNe3b8AjDXgHNMnpVDx0gvN+vpKh ApoIjUUOjk9uJVKjs1sJhCV/uF+Tgru1VyVfH4EJS/9o7gyylv2RI0fHpqKt7UjrjJss/X4yuaxv IAEBKVLI26sACMKqFPT6VUlzOkg12XvzmXbalSyss9Abk4ePTbSHJ2ci42wwMrXV4zTSLiDJIdf/ 1RwKGVriTjoW/yBXmj+pPN/3VNWtKZpH8Tg0FAssjLojHBmbmImOPn+sQ5YGtXCvrzc4GO5wdyi9 /TynW3ggzsvyowfPpsDFESRx+LwhUxyq00F+l/soVzJBeuk6DKrSlr+vz6VXKtkNuG+aiQxstkMm XCzmvw6XKnMVw05vsReDIrvdLe0aAN7bPW5Srr5Ae0Asf5XpZVShbiYxYbXb2kdXd8DlUBSnsy/I iyE6BYHR/LhPJpv6jW2nkOmdE4SBCqxbdbk1p5u6/mzTaaWnfcTgg9EJRToYGXFJB4/9hyb9j8io SpGFxBin81fc01pfAMcVCpAIAW6HU5NkWVEcTvpl5/oo3ntxQna7x6VIHllVnLBL0HG4EWkUsvPQ 2JGRsZnjjFT7DHqCkMfT0Yn4q3rsg3sJBetnTp7PhEvTZMlN6gAOymQKdF6vfMdYe7HoiFlVt6Q6 uHfmMoWLtPH3QkM7yKw7vB2N/1FUp1KPSy9mjR3DvfCKXfu6VMnv7UKMG+5zQB8e8nKKIpkTcIxl lvtfLb5/8zGlnGl9qlnbXU5F2viPy8kjpTBx08Jd7DVh36+zFsW42bqdiWMlTk3lJi6OQdDZQ5MI 0VDrNDaMHez0dSluFWnL3g6M3bvPuzugsvZ8JZWOn32OJLpc/oFQMNzb7VU6Bn3qLt4D5y17Bjaf L0nkOHao0oX8RnW5JKfL5QZOUMpkbUinqUH6fHwgwakOu8uB8O7Rnpnm1jZs/k+y3IHI1MwY7wT2 RQ6PjbCBqUnmRG27LTcDdG4m0B/q9fkl2fyg6svyU7S+P/6RdRwbG6cUjigUTpQvCu8pijqjOpde L55nmizTuUfrrDN9CKviV4zP2tl+38BAhzOACTEfqEvm/2VmPb07MEyhIHrwHYjW/g41vMYmjh6b aaizGXWwFr8vnubF0Spi4wr446jYLo5h1yvjiUOTfMP+wpPiQosQ2x/re9x0i++jNzdR0KU3CvhW 7lO0FQr73Xa7AlUrgDW7ipTO5SLrhSeiuL9vnKKOEIY7NkvYhACHXbYjlbLLLu68z/r4/JAET1gU t535wvvs+Efp7OjrGPSwV8Pdvf0+BJQeKfRGZCrKVJtTmpl8e1s0VxU7ycZN8mF2D0U2tbMDUvd6 JGAxGOoJdXuDARivdzRydCY6wgKR6eN08sY3FY3MTFK6gBXJ4vx5I2lZtqOQUWWRpadvJ1cTd2In 6CQ4M57Mp1nsyfxJVlxPJlnrNoztCsmQhMeNoju0pzPM+rwD7AWRTJbr9nlobIIOB3jcLzjW7YES IBLoQXNomHy5kl4tnoRdcRN6PoHufXhQ8kKXEvJhJ4Rg18DH/BeJ91+EixqZLockOwAemlt2aQ7J H5Sh0cJ68mYpy19xIi9rKSTpPYzC2adB8aDPaR/qCL8KSTqoVXDhXoLOCNMbQS3m/jORbH1aYHW4 ZLJHj+R2elQnyq7mpr6Q0HTBqFZzGS4UOhSeXsmvM83Ymi11+bRdqETDezVF6hxwu1CGOjo7gpJf 9Q+56Uy6TpsCQsrLP1Ib+dly2U3iDUBHEuDIJbsUlJIoji8tLZkseVxsILjneeHa41IdTuSU8CA7 PM9dW1iNyPMLWqQtdsXj8TjJvD+ofsvAvfNF9TuMZEXGzPY6Sj3XwmhsOwv0d6Fy9Pk7e/v6JFnh XQZLAuv07gszwfbZdKgQhwg44sguQJXrOaCz3adBjnYSpZsYgXUM9vT79wyGWB/QvBSH91Bf0rhe uLMNIx1ax7BP0sIuH8rZgaHgoKQM7R7skLqG96sqL+OMM+Q56U9QP67BzIonc0uspW9sfDw6MTF2 7AgLjPIo1vpiJEEPpl9jEaQhzT39fhbw94R79vSzzn29vWx/IBiiH5xep0sdDEuD3X51l+TzO/YH JaVrcLdfCqvuYf+mJQuXoCt5VCbpH5CwUE+aquErlA0SvW4tPLhXCu/d2+eWuod2DXdJfs3T6ZKC bsf+PpPe2+KtnAZ6G8i0KD6/VcO3h13u8JA0NNTXtws1o39wSBruCLoHpWGHOrTrqfQoZah8ly3H V2tUTXqd2kBXl+QYHvbvktTOTjUsBVXFPSCpHUPhrq3ye67NdrrCXT7JPdg32CW5B3wd+6X93W6t T3J0drrDgDU6ZTbYyN9z6AU7/D6PtD8c9Lklv4uy/10e165haSC4v+//A3+N+v1voJfNLhXpICHi ebbKWujcVWw28VFrA70Xtheixw0aEXVbvyV6vmG/r1sa9Pn27pfCgwNhVPSaJzwsDQ07+rTN9Jxs TyioPBWLiB4wz+OU9gT6yG8VpwxQdrrcHpNSf1jkKIN7grtDYS/5RIvmclHi1roVRVDwyBpqSVeb Q3FKsoc6e/ImSmJrrkVz2rcQqVHygJJidyou2fF7v+zFeUl/H/84/Y8NyZfVlVCciiq5AV9Ypbl1 cpEHye1Cqn/QRXU/T8vtLrsHWb7dodrNWSrf8XcAxNtRms25u94mG8TygwioDqSGkpsKPXMm91Nn cvPGi4Kg6XBR3MNMVGgvfUTt28LDzSN9CHtUiiJeQ68qqmpAc50k8w0OeDnz/GPRQdTAfzwNpOjh V/7E6FHkMBISMScSsfo0IMM8Vgf26TnWUzKq31u7Vkayvye0z9uLejjU4+NHsVocBJG1ohRydLll zaPZHVRMYVhob6+1a/wUbTsgS8RHzU1ix4jMT8UfUFvtQrmjbSpzTOetJQc8tXB51DqD5mBUF2fo ABrktaFMMgm0lC4hj2p9bjDmE22Y5/d2GiQU82mkiIk7i7eMJ8/KZkjFilMz0wD8oOH6Vyx5v7he XgRexr5P36YXk8wQbmtxUFHYWk80FW4gDhlZkSrDSJKriz+wZCFf4YMTd/hwCg0tgQk2cvxgdKq1 NnuPf5cckna7AWKwfNnhkRULgDI/UGRLrMEZN9FhLSq1HMzeRzAMKHT5OpFPqS7J6+9wmCuoLOUy S3PmODHkKaky1VG0BI+quVVKt3lU254Bj6dGyzRPjUtOdSFB/r0VGRoIhUzvxmRyrT7aYGG4o7Sr qFcciAPw6d7IQbZ/LPp2PY+X7UOmv//O7E2Oj40OTk69aYb+/jBBhNWRwwWalLkAmsyhODSkg8FA l2+PP4D7fUG/BxcGuveE91iPy/XHnRo93hnwhvcF6XE7lsaA2RpzYZkASoWP7hno6e+i2zLSfqjR w6BNFYjtUnDb29/T5w3v4VqiahtgqOA/qHgROSEN6f/pQ8lK6jw1HMytFq6pFsoIWmtbVqjq7Tx0 KC5FkTSPg5LiXCl+RV9w+IeQq2qb0EuM02h3zq4pvD9tVxQK8H3RmcgIFe7Il6eZLzI1FZmKMJmP N9vknXZlsKNTIjuAN0je/m5WxzDkjJ9U5kSUs1I1Ma7P3znUjRzU1T0oaUMe1SENhR1uRVKHtG4/ dQ8mD0ZZz5HI4WgwGhk9zvbLNaYFgcBQH3Q3NKR6zA/8Gc7QORWNvkHvZr/leQr6dHaTfCSOPBQo XW7J7fbQXmfDpKGZ4+PRqYZZzbG7BmUhW9WFgKm6FXozWbEzf3Sadnn2O23yNs13vy+gqPBy6lbn K+UzqdXM2a2Nndrjg7tR6AWomEbNSoVrc1PlYfk7OtwQQ32gYiBp3Mr/rBYAsdYtRjklDxVoqVU6 woKsUwFbLb2ThydZ36RZ+1iBziE5ZTeg2OGmXrQTWKx/RV1HankZK0hYob1VWJqTJ4hmc88LpoLe VyFCp+pySl1dIcoNgRHBN8YmJukPesgmk+JwDRLsWv7kl2jXmlp1mkNCKUmbf0vXU9nkzdRq4Udu 0RuQ09yhDgKsNVXz2IOqk797oPpRMHqHGD+3W3tYdHSQhcAi7C5FE7eQLYtmYGhwwLNvv/W8iQuO EWUkMjJKreuX6S2V+h+bMd+9F6eM+EEc8dJWhr9EAWiOxeonQvkf/xF/TSO+WPuLEnS6Lb5oncZR R6ePRN6hk13mgUt6v43eObNeLKNtqu/4i8q4r9/FEzI9LQ7Y3hBHK6w/KbJindpUR0HUJMHPyTfQ sd7hitXeWKU/kyFexoa4sAYhHDoZx0vvC/mH9L5inL+vdpaOZq3QqxUkKzptYglnsYFymSYqpfnf EuBHRCLHZianxv5DnBsdmRyN8j0n8db1JfFuvJEzj07T6wSr1uvQtVf1Sdxfmm9Fg42GP1ni9e/p CDByiOwpbpWNvmAZ6OCgQ/ipBr+TVBUW0zkemX5jO69r9O9eGifJmgbbVGjLi0I8Jd9iVpG0W1Pb lU09721mFZgyMBU9Mhadim7ul5tYODRE/qTxD/m7xP1QTLkJ8N0bAQlg7+ZTyh5Zs0tu1+9eDXmh ytHo9JvMG/R1hwO+MGXNgLs3ZyaP8v5brYuq1Br9Vs+ZEoEhd/8+FNk+L7+AVCa49QgI705sk8Ly MoRRldLRT9GaUJv+J2/z7JvR42RoxMruPk0a0mRZCnbLHdLQq0P8feB8RZ9DdkZ/kIzS93bG+0T0 8qVxnQ5TcsM1D3BSMsbNk27wP4NSE4Nv8shR/uphVw9KgmNj+NaibmTfkohL8nhc1NJ21m5aYhlU te76CBOHfKq/U1UCnFt6ccYfCO2GP5S/40zzdLZ4MrNIJ9RaaW9pmynlhs2W2k3vTh/Zdqff6fA6 vVt4sVTUMCmCVKx8tbTEkqcA32fKeXFgd+t0ytb5NpP9fc3xfwNQSwMEFAACAAgAtXCFKULQgoup AAAAxQAAABIAAAC5wsH3uvG18L/AvcO18C5UWFQ1js0KgkAYRfeC73CfQCTc9Lju2gSaDo6D43wq afRjCVFERLRwEUToptwESdL63HO4Usw5u1OBME3eomWNIpmxBrwhmXxo72/9k65lFcZUEw9KuDwS rIifoIOkgeqaFzpeUPop8kXyQrwciNE7KKrZJOyUjXw1rN1LfCQBi3PVDX0DtHY2jCGailYKjHqN 1dz7MQO6FjrBDuoRnYMbLNM0oTpkV8f+3/sCUEsDBBQAAgAIAGqI0Co9RA1MNz4AAGa1AAAMAAAA vLrAzr+1yK0udHh0tFvfbxtHkn4XoP+hjQALO0gIy072kkU2huB4L4vLOcE6CZxb7MPhLg8H3FOS u8u++H+hacuWZEkzmhmy53cPyeHQNk1aikL9sC3ZimRakUVbq4RiJNm4qu6eISnv7T0sxSCyONPT 01Vd9dVXVa3XiLKlLhOl7RaM55Qym9gNfzNacCZIMMLuRQvEWKeaXtMXBwdeI2xdbxBK/Tabw0sp vBbUzcmo5kbZa3qemA+MdbdAzHY5k6uKWwtB3S0oW4Q22TqrBi3DIN7tXBDUHcdfGxwYHCAjmZH0 3/3fFZzocmnKUhyH1dRVJROsiFWS3/72fRLNmG0/Td6GNaCIboFuEGfC2nYtMsSvxWKOXMaJRvqw oqsoHExGXn/9dULMBUZBJcpVp5WrkUJdXfSN8oTUY3ki2GMWoc+NKtyyd9RlqV4iPkqmfIUEQdAi tB3NKHdgrGb7myBQdNUtRCsu44J2XrYRtHyDRJNmix0oeyRoB/XyNsE9VtKEzTktI/L2xFPHh945 +ebQO0MnkrcVHisPyLFjx4i6pi7jM/gAefNNQrNUpQrdATlKuzSjbfKpCMxw6oQQ9rXkQwjdztXk DpDXuj9ECKpt0udsiVXCUTEKn3/z7/8MDvzx87MfkCGz/SeQhf5iHpDjrGbZJwiJJXwvqOd32bqf diZSqRQpZ8Kl+Hd/lC2BhfqmvQQ2GywqIZ2E76wulJUihZWCwe6938+lnuJLVTWvwfbBHYNsvGCx 3vdYRTXZPjcf+4W6xteIa6Vh+QpcrxK25Dh4QUtrdlAHN3RD5jqzdBIverdpiz/rgEkMDkQ1uM/W 6QZIZTmURt8LuSwabhI0Sf8O0RdpRpmDf7xGNCOVABNYVM+zCh0hwbZSgfvo2oMDMB0+Bm9iFQAM xR8DAEAtRbPJ7P1RV6yv01xfzqz2kEXEsQpO9KRXY+S9gu2Ao/SOASdX56lCrG3juc9U6q/1aVnx ut7i6/ro47PnPvqCfHJu+OyHhzbSH9WZfD26lX8HdKczbYRVSGCj1q+LvcCHuFL1taDl3QJVhzdy 1aDp7cJItkKMaHDAa7I6ygB6L47T5eyO9z3aMDhm0IQtKmzCRrfRVKoptIJImA14v7JlNKO79gsJ Pak+b87bXAkQVDR/VNXsxisqwItgY3wJFcIXx1ximtmdqBa0+ruYX4vFZMqZVxYC1iGug32wmrHR ax1SOaQ8xZZAmzgyQiBTJpQMjNQbwo0q3oq6moqtTl9krp8h5atsCVySXYMH8SHQOU4DMqvzwUtm I8rEPoIO0+8d+AcudOmea5UmiTbGKvBPr+zcBGpKE0xCboNruRZ4eMFUHnNHiSCCEnYNwr/6GL2f m5Y2zZXBpspX4IYYK0XnjyQagXiTv9oxtIpqoZ32V8p3BL73dc53+ZxuWL4KinlIjkczqpkoLRgJ 6oYBITe5r6BS8s+YpYTZHRAexSQylIMtTSYRG+yaUoKzcT0ODmhjfl65Q4pp5RmZrvXgcN8dcuik gKVh4pXoZHZfiMWmcGvCUToJZuLRyRPHPxoW90+Q44ZvVAvGCW6hCSsYSgFAXQUIQkvWl0G8D4Y/ LUU8tAincWZdy6qGd8DgcahgDgm/KdJkKkJODdlPwfHi9xOYrTt+aavSaIj3EBwO1LnG1sFj6XOX dc1SfsyqwG7Q8oyrxGsVbBKO86tsCVQ+Quw0GKNbAC+T2gXGhWQvgD1R5rpm4oRXnc+psGEAxeg1 xobXtCisY9UwUh0qdiplVM12XoFVxqsH//EaoUKbdItVQMEwz1PHdS3h/3lO1WIiREiHhsBc1rZ2 y7W49XDQdyxW9ep6jS6zihMBmEdzMTnqZ6QaEuyoz5MKHqOkgysS45UJIBkdcd/DCNR9X5tGI+yg EKvzjcTHwIaK19gc3xdHtV/ANsthdrcGSX43dwtpNeAybOkWyUbkDfF5v1/i4euEgIJ4+GvBFYlz vawDBMRbkb2DcDgTB1xw9jIAo72kNzDWAVcDrQRrrALLxcGdb6W/2DuWCd8HB9i6NoF2VdJr2jzp M1EZEkwFCPg2cM6lw1JwS8TIBFhohRREMCB3I7EPEW6q4L2nc78ABLbym0BI9DwMs7xO2sIACKw1 kIVvi/nYuaeawMciBS7hdPwyCVb8NUhoolhXwRVqc11x7+cTTd/HrPENVMUcCUbxC6E/ZVFtHC8e dHg5Mk5UPK79SNxGkJviftDUN8v0EOfEb9pzYBKWWNhDxC8cy3GAbqAlW8qB8oSOpGJ5Ic8wcBgC JNpB4JW43H1dtWBBdsNuIR0k/+d2cyh/C/yzBZsLO79GJ3HvAQfBM5mLi1a2wAMjzm5I9JBdM5pI 4PhUBRNhkWOdBW6JQQCCBNp4nDslQwEgpzgvimZQD6CfMO8/xXzrBV+DcRUfBIBgDX/nrzz6s17j ZIQYMwCTE7AcZQuxg8jZaE4Cgp4X1CN+OoFur5mdllugj4O3Ktfh7cp1ewfiO3ukrvJlIxh1nsVH 8KXwiGOpqyqFFxkbMNBnfEHy3eVn1l23ECqHX4234cV4G0GNm7E6nqv6LfEF7kmrjpM3mEyzla1k BuWJ8518NegInv2uvHv4LY4jBZQrNXIgnONwceKRxw3DqGnPIXSGRFEwvHEfTaVO9Gq4S0cK/ANw h6bAYRs4QBqykkKdIm9WbiY7ArYhvP8ApLCJVzfHZRTsXac2L9cpX2A3lD3k2WgvXRmMNn9YhTh2 R2+Ud2F5VBESyJlh5fB6XEUxo1JWNbYACuwG6DDNH/Xv9MwEjloReIPVCIjNmPMnq5RigGvAO9At o5pb0PPWXUAnJDZYHzl2jAjY+T6x0X4BdeK7gsxj+hq0/CClacAZwbQPOzER/uCP5qaQhBBvR3WQ qgJ8h2gC3jQaKobfaAYG2MI/vhcQGU8BsdP+0fmOc9RspC9CjoI8Tlo2imfNunVIDSws3JH+Cir4 vN/+K1EVUpA0NxWOPsDOQAmcGFgKbLilBC9hnXF0Msddh7hR9CSqGaCJlNhsgARlNJFUjARxoxnp J+YSJIKxxWQxzdbGlDQ8p66WqRXAu6R79+BKFxHhmpmJSzN9M4NEPSI1QVbp33DZK9uv3vFH/aZI qoUYCPWgHWTMfEM5C0alIU3WJngJCHTp3yisHrIDNCIMAmB17JoM/omJo74AMPRN/T4Ygqg/9FvY UyJjce6ZD5QnhIawhuPl8eKjTqjFb0nEArqwg7nBRnD5+JkTIJNll4uEMrvBi83msrL1BsAE7CkO gVhn+LlHCGroRzAjJvO0QYL5uMSH8EEs08EMgufAzqzqYHac8UpIXzGZY6vRTyKgb5mTsiLAsRom TNAFiQxGNQSZYD6uKRg+kK4qJn8QctKuD2sMR/FZnijgNyu0pMJhNravLnTDTP9sK9G3yAZyVToZ 0lfqNYLDdjEt/ymd1MayO8R84j9Vl2OxaIuGaBkFjwlVxDEonA9H9bugDrl7QRArWiTLgMJZ9QHJ al4zeCHr2P2WUKQmrsWulSYhXh2yJ58R7ZY5nhBP2EGUDdZO7aRMxlN6RFGs3VhTYZ7ts0owy83P tXKqnMswVMo3H2g/i4sC04yoEXgR76bgJO4dGWni+gkPKlgO3KSU+yulRiOusvNMutpNRohIKgHo b+d3e0MrRAuNuQD+gnOLys2Yn5e4FldlREjEKI6lNyQInLALotqZC2vjYPrTbWWLlzsuXuyktJUk PCeKHFVXhdwcdBM23xvHT5W2yG/AevRlXBcpbbEowBAdeN6u30aA7+J23rOglSR48s3ibWin09eB j5gV1YRfINwVAQlqbmjdNTbiOH1UAbrLuE73sxTVO7VI1Fhl+ifrIP8j8VZyDf8pGFQM1jImVmRK 1VNsSJX+Yh7E2N7vhYlM6PS///lfvyZff/ltD2qwmn6fFFb9G0EbLRTLMthKIB1Mg4XfyN0svES8 wCYD5oIi4YArNPSfvvpAaQo4H9qXn+4ImyQkEmMsyBKDOsBKLuh9mwEgvURz0i3hbTLh4sPVvekX PaPRM9bOnDnDbTeYRaInauxAB8wX3YtOsEwwdIgNCOpPsLWJbiFKvP3XvsjovGdOC/JyUMJBb62S X/Jl6gYhJiLZaySosyha8FaIIlguCJej4P75Z+U9TKmf04xeU5tnxBQq5SXg8j6gkFKRwM9nhXQF aMVPuXSsk//nwxuq8EE4gjVpss7m5X4JViAz0MbiAKL/jFBKHI1ukegWGLnXDmbP/I0Zrap1F/9P wogNSOm383scc+EtadgqZ5atK+limuMgo9m1v7XGWEJAIO0hR3Fz3PtFFrdBSWwfAx/WDkFt0U8i Le7/9grSb9n6TbYPIGo3Em7GE5KbPQkJGD0W8LF9PwI0BAzCDQt2VEMbxBxF5NgYy7b99TDg4tkv Bwf8Fs/MejJdIMGV4hKSJSvJIDHn4xkuDpAsGPM6bh/dtdXBgdyU9WMwCmiNw8BKvH3jMm8YQkJu bVvbtIFzBJlpxquzfJYEmjEzTjQN391wcKArERbPKqG+CVzv4kV4iXcVFFATawIsQJ1gvGjm/WCR 2dygRdwBU4BHzcp0e3AAf2JPcwQ7mjijM5HjPLmFxDFZY3m6PBItxIsThA655DgYgewNh3YuA2Ri cMDWi7xvhzDBI556D7utmkjEysZtflNAjcyRE0oUzEPYW7S/A0aJpT7wpnB+cABvQsQrT0gC6qjI IDpdAp579p11iwzsf776j2++/Aq7/QK8Ookw71VBopPbBzdWDkCLXbFGlkh0Rtg9JS2qniw2KwGO bV5dUdJqEzIV9R7PSnm913ip7GGXVpTMufY8szNrUi1SHqkmGKbxEvPXSmijBWK9pgLI1f0mhAOh 7iAAJp8EFnUkv5fAdb999t1+k4C42X2yn6X6rnkF6WcH2R2/afjlbuLvtNxbdIuXXGvwxdzgpgw7 elN4utfM2gCB9Lk3i86KpStwNp4XJbmPfwuzokXzJbgKgA1/BQcc9EnIIYC3Xep8vO+OQEJB+svj ynVR5Hw/Do9/1MfROLUpYt6TBz8Ka+Jk0i1t7NKfiF9jB+Ts71QLnMBvKvf9ZyC9OQ7Gpq7qm4Ay nH3IOoj4GOs50wUonkMCEPrPEE6oKHJCnpwkD+tuhG/EIyVY4bdTXa0ltFvRAoORAFsCJUh8KaYT qf5T2NP9p7DxzILBnv+vr77+klz48t+++vKb//wzuTD8xTD58Pdnh/9p+NDhHBmr2BSVRYylmB5A 7u3dBgQUV2XOg7UKfugkznJ8WeXpPCe7/FUlbdkIEkRdCFb8tGBAQFSxN1+8pm8mLW5iVOkWthWT fkc8peMADWUVUQHrP4acFqTa0aKWv8VLUpLWJRbSdYsfawFGd5cUJ3NanKV2ijhowdpmYTU5qwW8 ZQHMTtnznovG0vfxI/0WQ7DT6ZvmY2LezbeBLBbHySGGCvFAY1V5qklJA2uhHjLWdeyE8kMRqWA3 uBy3CNmSG8KqebP9Dj7TLaqhPMGAM421cYAY60CecIIEdYwk553AId0oGOFti7gzC3PZyTyCzsIi 9B90huUNDPaYX4DJGVuRoCn915Yke1WrSk69qiXM5bGnTvwc2h8oS8dCn70T5uH3RGbzrtfU6rGk qFNkZgRZQlLVw6FgNYU538Ba2KQniCx+x9OAPecNbwdXSHYqC8ZOimmaRR4y1+mxIGGSl42NwgoW eyRb7NJ91w5J1mMshZtOC0dRVj2KIHz6nSOKlSK4i2wTAiLkMHZDiSR0JTmX7GJHM2wfTEZ9jAcN WlhH5izHN61t1bJMkt+l00iOS2zP8zrNldJl2MIxbHo9jbffrcL+eE11D4ySLvMajbpI3IxwAEQ/ +UrzQTTPi5iSLkMozgCQFfHUHhDIXzotcx5xyhn4oc6DFZWnZTSCXZ1idXidsVxMc5MSCTZfNK51 yfNkpaffIeItwXD6W0BJJhc05/TJoK6tkrdPmhXtISc9RN+EZPPQydC3TwLTiQgWB9/gbdHSLhYC gdBE2Bbc9nz45dtvxfnJjW5OxI8/8t7zOh4zPplMyakTP++q/6Dc72mG+gxTBn4PsSZOLpbj+2BI 6/lNnsFCsnczmZI3ivHI8pbskB1F6ektwZ6OK2m3eAKABMvQyD9gxVwzXVjBLLtFaGA3SrMlh/8i +04V5PQ3ZLjsOlp76HTz0G+GwE45/VEX7J1jRyGNIDiffniODJ8f/ogMf/D5ufOffvaHc+TCZ//y Bfz45NwfyIWPPvu0q6PWOcHBczlbJMtYGeCHUyRjMCvFDMFOE4kW9M2udi3/iNCLEBu1xIFj0F58 MpMDZsZY561Si2JViufAvVMktejiTdcqFYwIUBybEsp1Iwss5eJF3prrjIc8C4sADAIKePG0D0ly O+5LYQblZ+AZH5vYSluenILktwLz6Q3Kr4A4PTOqi3goh0+Ls0Jkxiy3vI/5a6BanbKA2c67SIRz BDJWDFdc4F+/Gx2gUEfi3oJelor0UXbHW9B/dh3yKxKumRU62dlKx+GRj/u+GErEWNCfGIsHHuJj fcEKnlM5EHQAARS4B0cAr57MGFyJHiqXMcP5ATJSQUnAAPz7YMQj7B6reHvBLGACgkI4z+Zwg++6 UVQDVBZvhA3FpXQWmd3B5JeGNFrRF2ETnFlzEgu7pjiAdjTqE4zz58qdOTJWvfVsjI6VSJeQsM28 6tB9pCaVinn3ujMrfxVZH7+TMsfpdbWJUIbtD69BOwwLKVgI+hLdeA6lGP/S3FztHWyoxL2MI5FW EFNzJbhSqHtlZ68j6j//apgUVpEzcRmimvcIMC37M9aJsJWyqNeUm8TadgPURcWs8DMylslPE2Kw F/1XzD7iM18yLgBTMB/zAh19WJq0Jrml0BwvHiID3cXQYU3y0jbbU1fBPb/5b445xTTQsiaeBasL WMGYzc+ziyMraZ5RfvstmA0vw9XiIoi+WZ7A2I0pgLfiaMTWi2nZGjgq1QoWe2H48+F/PEc+Gb5w 4fcfn4/xA3tasabl4Q22YpTRpC7J5Nn3DXsHvBHYhmZEYDzeLTwsg4WcTv8z+XuCS0fSbHmLs8e+ aieZWhDIhVEAp4rWU80FiwPxTYWXwM6cOYNEAvi+9gCrZbzWnlUMEyCcVXKqPGhrKiIytIMsz5WT CXO6CDGVYAR9r+QWvJIaxXSRlKd1/IMOMUmK/50P//sReaHvfpf8TYBgeGeHLwyf//jzYbncKMju Y8WElxVFvwGkcVW++4AS8r5yExKZuNkvH1UpHg2FmOlgy5m90DdJuVim5PzHly5dOhoR/pe2a+uJ 40zT95HyHz5uNlgiyGAnPmi1luOxN94kk5WdHXk0mgs0IQlajxlhMsrc5L+0wXZsBqiiqrqrqrvr 0KdqE4yxiSEQH7GB2ASC4zEQDtG+h68ODd67bo0yMt1V1e93eo/P8xb7kcXRyrD6AHY0BVdNRC0D n3BNWYDjpjyuBAlIxrThOlX41lkkwlb7fntCy8LgDsA/ROEymQBvuIxVXKNCybN4Y4wRW42IWlVl He5+F27CeyIdHAdXcKpZVSeK9K0MKZRkMgk+bsTBfwfdxIY8mD224lS+HJtmDJA/6O7p7Ngn3n6b BpgYc0OkYP+CoCL/JiobIEM+wLwMS9EALfQOm+TDVEzkxaWcQCtWuffFJato/YlWcE3ZpiwLoTfp UrqT/iScJfGNUvWO4CKh2bKiPmMUSXNbey4nKSL7wuxrLPWfKBPjPCwto7Us/IzZB72Q0yQGHEwt EQtDYmO02eMfQPSMtBAhjC+qxUJQZ90XIBd9O7kvLpYj/LycL5KiCQJr20JEBIKXa9EYoq09+5M3 htWYCUoKIw+AIi2qv93EiM6C/9PBQfS1GKosQhANKiWurkoBg7nsS/idGaqi/bnuCYp3DsWUuO2c 1tx2EGafRdm3O/dNQ9KG1RVhZtUVMAd0sWTK0brIQgzCYYM7hIBr3WW+wd1RMR0xlv0BcwMhEAR/ SOYT1O/tF+Q6UXqpKtgvjp5Ts/5gf6wJuhjze+hNR5ibkE4Tg4MaMHmHJRo+/codRa8OU3H/jsfq PxKV5ViCcCLxjIFhQrOUQ3/LmAcr/h3uDJugc5iKNN1r/pS52JLcglRtJFRbAj1Q7zGxw6Fa2eci Ug7t4ajCEbTnp0CYtv1kPq37Eh0B4nKa+7bwU7IQ7ExhuiMcRY4AmEJbljnT9MvcYIss/YAZIyhB gdK+yepgCFJFeJ3xTLsEERoWX8EUwlYCHbCCD8SbcD5bdjuMi9aYN0X7rBmdwX11n7J32UmhmTJX vbzI/pwDJyRwKtqSqEnEo2qFIBG/56+J4aHO+JcKW65BOThnw8vXu0D7LrsgxjyEihhX2s8TzgYs tIRpwKmxlMwEeX8UgybQMuHmewCbrzBpb/sbsGGxLBphqKMn0g4Ii/NkZERl/dy56GjKGiDpboRG 5MvqnMz0IOn4EXksoJjffMMw4Eczqj5dNr1JjPAEPw9ZcwisRTwdL2+YGguLQMiZuQWKSn8lL6hv 3SWcV850mavGN+IgedVXxFGSEHPWRmELPuW/E8l0ZTuxv+su0YFYogOvleiA/Fv8fyK1hppLqpi6 i3gwFrH9tSK2hyK+HcmI+ICQbC9POsQ+6nT6lWqaPxj8uSzyIAglL/Wvdl14+ZxNw4EPnUr0RITA CJuBX/miMsvYXIqfwLfOPBaIaKkwfZUQARDC3wbXSrkP1qZSlfwUeEaczrwJmi5KdNQZzv8uO3c0 LdYATFnid1N5FzMNQ1ToitgsyJSGsxuebXlwJPAaD5XgU8XVKnVBteMdwZDLmmngxhMp4RbTL91C goueiCvqOV7pFw6bQ6XZ5rMfibxdmchV9yV6P9T39w5FfijNb1SakVXdEFt6ALPyqKewOGxbNOHS hxGF54XnkjghjFl/B+ySo2ur1ASCsQxPzaHsIjpREuJCTBn0mooyZcywWhs9m/GyxaAmAlCJbCa4 5d9BaGF52huzl3FjooaUQKy8qNcKhBNyOMp7d134rLPnQrdopkAiJi5MYkJuVBal0tPpaRiEE5hp zmLdhNOk9HGxeUu486aPBdKl4JZ7LSR7B7dpZ775BkE04W7MsxLnJjMsgXQ0IeA93RP9bn+mhkJP tULhTKiBN4bV9pyaGYJnFA1EvXGObZZzbPKx2rSgIg0+mZ5r3M4M58dBHrU//coLKCHGT6d0GIQS 3DojZT578w3QA4abL8IgvvoKBudMaeMIStpQ7kuZYHfgD2HB5ztSG0q51EecLEzl3iSAp9+fLzuI bVXnYPHuYkeZn5HxJeL8HKiqVGFdmL9m7oKnhBgZEKauK3ukbrXOsG+ApF2s+fdxS2z4aVWLjpCI PoAlwKK0pJlQATIIbwou+/1R9ZmBb3Gcyix4iJ846ZQPMgWMvp45K5pWv/xEOBh2lnIreIqJzi6a SXaJ0SUFq875Jpor+l7ZFJURcyQuBtKWA2/F1rOLSoh2DUl/fA+VcZWU4xTHsB4HQ1E44sGZGTWv hlo1fKQz4oHiH8LyrO4JCWZU52gL2SZRRLGNB/jFxGqEXRdwgtcsmyYBraSFLV4KH6k9iqhv9KAx 8JiLObgltw6TXOwX+KRE3d5AOL9hodgiuO5iYllkQf3DjVF9MaB8s1CfmpNUGpG38oFA4rstBJlj bwceBodig71E9x4Ih1cqg0ikgqdGZWe4dlPLGgF3rgkW0qo3Zi7SuaK0L+lmmpeCzGiA9KShU6BU si+JU10cdX+tb6sMdv38KYj4YG/3K4N5Twgrq6TMPkyZIy46i85FtbwU7l+Tekep960F4XxrLCea CGC0skaMOaZHkLeKz6Z0QHYWrXZ9xWc/0U/nVD9Tuo+8llq8kLddHURGh9AfZHyqx+BVXMx6rs7J 7cnmkekWZB6ZIxiXz7hPlowGKO2GwMp6D+agZACymqEYzN+pb4OPQ+x/nensOC8+7D7f1dtRA+EQ 1PgBiaWUD0EgxUNtTpJKY92hvYi6bfH8ECcXFplbp8HmwYOcD/IeFrwiLnCdh8KuVfmpX9Aegast EXOUKB+juC828YoX2ErIk7MUJUB02/fZ55YCseFYkuDHwRgmucbqFzWEErNzZi0om9UScr40EPvs R5aSSGb7V8wXoMz0JSynTqgaU8+uw6QTDEySV5kfLrRBArsw+jomdy4Fl8FVufhXGGmIAax3q4tD 0q3q6L0YIkhgmk1QwPPWEBhDrACDP3mNtOgvI1sIAa2JriOOJWoK2woDbWXDHkegmZklbiA3yiA0 flhh/9H9SS/ENpXhP0Y/YnZCL5L9rhiaXW+n/tCRmoMapbbgb0EnlwKWG6KUKc3qrzKLwl/HFjkQ 0Mkp0ZZE6P03NYmzJ89ibX5GnwF/LF1VlCjZOxa2OyPYFSZZuIo15I0zvQHNw2DxYd3A8GFrof1x FFG+WVbKfmTG4o8klgMxW2FpVX5DxM+MqqyH1ex6+jWH2a+BI81oklqFjzE1NRVKz4Bggxw+h/jZ R0qfKC+Vl2SQkt5qPrC/OGrdx8D4npmGIDu36e9Q7kVB6sU+omWaabBnB/brS5ghJEUY9q+qydmg 63tDVPvUufwNJEo8NFxKrVOkWtcJYJPtzRaXwAJLuOTbNHIKd5ux+k1E2mfgzNX1l9naOpXSDTPt jOziYHPPNrlVZQ+C9Bb4iUpZNv+gKJFRf+jRmbChU3ge6ujCHz4Y5xckd3QXoJTcS2ZOEl5aVEsI u4WQVTpe8j7Zt6ZuBaNQQDbAp86cPP7BWfHxKfH744jCajYs9582ok3ROu2jsmrxtjgA4WHSjAnX y48qGp76TIHAaBDdDWNuIwM+8xpl3ll8dTr9MggwxX4FApHA2VSWW5RLcAQuZdcorEQ2LCH4kKcY POS8UVxhb+E/JInRFugIlycEWSKKfihWhcP+m4lQOKdqm+UCocM4xZpN38EiUfYr5ACI6rjjEccb u6ktC/0ekueJM50upahfVehh5Isl17wLT1QumS8o7M3hgvlPZPsGjAfg42OEXS5qGQ2xtLcgIDUM auJ4x/kWfrfaZ83Sl+UBoa22BJsWmEd9FkFeqUwqrdJ36oKzgoReMJhgKjBoO4eUnMuUUoO7xDni 8aBzKawB9ye6yUqX15D4s9pyDiLfccRwh9diuxeFhGwxVowVgSkC0DjUV5JyCDax/bCeVqWtV7e6 R7i32COi5h8Yl2lxp6gcImg9TOXIb0HPpYT1RMfeikjrB0HlCiRuxyDqjgKDfqAXSMXNmavaEmyf 7zxbpqitgaLOfdUu4RXyGchHMy4nH4UTeUmd4b66/dlF6nXCT40wQ8aqsQUBhPKCN1fhMuZGiCYt 4Jxqj3JDhr6kZdxjyCK5geFQv7tCmv2lmpM9S2kfZ3/G/QPhIpxifSl7VRS2ebtp15H5ILvDgLVF ATEMvJu/QQkd6WSE7tUydSuYN1WYK1jt+fRLb8xC4t5Ilah26rSyTph9s4/+1//WW29xHwBRmGyl jKbIXs1eBZO9HvjgquYD/I+NdmudXbLD7F06DyHkxUyvOanfgsWvDvgbygLl87xbXtxnaqo6YG9h 9y1sLGZlfxDmC+UGcRVDSiTmoqb8dew0A/NL59gdhaWCY33X2xQ6soHSP0o61AicAnySl+nDitUT j9AYeVKsInhgG7JxJ9Ibqn3Vwcy4u4Kl6ODNN1ysf+ZtYwl+Sb/mrlGwjm074JbKPaFt5uYQGMdb hcFlrGT8fmcafgf7YwlnEY4fFh+/w4as4VYUuRzBj+W6+mnOQ4lEczFa4n+hxZ4lMl2+6r/COiBH gqQhQUTWPLbpr8El2ZTSpywXH2KdsDqgL1oD+K/8DX/NWUHU0bdl0xwilYFn/XKubM2GO52ImkqZ NHBx1J9SvpX1d+MyXjsFOmZSncO5xoTFv9S58Da4HnNLMMVhdyQCz9iKdl12K6jrXpLNJe0Je8J3 cmvu01KYb3Eq9jaeVeQgGlsmsr3MLCI2jwpsmbRmpon2JTRdBQPfiheOYbeUp3yN6xFDAq9TUvKR mq7PoGlAmuMGI/hE6TFoavCcd5xqKzlapumn6gfdCMd5pL58ibCN5n7ZcEydE5Qj0yDEgdV15xPg KMqXezvYL0+YZUoFIq5SaOOweahB+IYoTimY6T3+Bwx7Qrb4OD24iCfK30HTi/kmCJXscUxsYSh7 m7NRxSzsE8ljwMQsajYuMWG8hIzhHX+K2uPS1/hBP1nzYBRcCmYmIbGC8vfmovA2kWSBGrZVNjfB xOdddYHsat5F62lgdngNFl4+FK44B5YyN0lPq5SUZThSlAJTHhMrkDPNYzkbzKM1oI1SgkGKIxPX lAfMJjpgjKDBCPN9WUGoA6MakhAgAMP7KTUOQtpCgZN7h4PIedPPTtYT5ReuuOwgM2w/x/qe2JVV YVyIMR5dQAUXDo4oXCUcQvilhD2imWyApBw+nDiFMcOq8c1rJcXIjtMpJ07hRV4g3cqmuqMOjnBQ 8YfTJ07uKswEQ958WAkED+MqxMcr5LegwhPGOM1ZyQ2K6DX/qCzA+uoP7K3wFutJA4Tl8OLsx2c+ PnP6kz9C6H5OfHD6k09O/v6saN8lfiSyew18kLBFCXYtBytkZtzUO/vda1TI4QsoKaldL+awnUgO 21bUZlbFLoh4/QfHocl//c/pE38UJ94/efLMhyeP/+7kmbM1A+Nm6OKoKKWcFXNIfwX6yH9OPrNs rAXiq/1NcYaHmkvDEm06K7IM1Ajh2fdtbxNBMWOBH/MA6727l4QFVJYxLYCmVC/fxO0dxUFIOq4O 0yyPi+qg+awJR0NuqG3Wog6x2zX5KcY3xOSEZdVnUB+uCEqbgoPKGrSyUiwxbqoRwz4UkdgFU8x3 nWdJXpc7C4sKcdBHHm/ES5cZOFhgfcYcAtUKMczuHUiI+uoVCOut37CxQKCxskiw20MoYaJbQ/1H ze6JvxbcKqYxlkWvo3bg1UXjGezOgryIpKz+Iss5HKW0tjqV0lWYCghLqBL7m2djsQIuqFlqaTOj Xh7OiD5jLO2lmgpkf2Fck/KuotV6CGtiru7Bq3om3Fpcssbq3sDiCHsz73d/ebFTfND5t7919uw2 RLJGz+4ChQHeuP4TtpK8rGDLCGoDL1sKY5vzJnlY6m+H2vazk6SaqmmNyVRSjIkIeUtSQUZNnlSN aKUQqphYPWO+CmXKpdXM7lSVr5FV0SxzUQhU1a5HSdrqPk7eYY0b07GsFK5jGIyvTEBMPcQahUTz dmq/rH+nbDbg/Lbtb0u0B/iw+++d4vhnn3V07Vk4LMaSmuHEp2zInxnGyJgJ/hgPcPtoW3cRPG8Y hQ064wlqHF1pW7RrqUGFctmpUMsG2ejfsOwsqIHs8/QC/GL1l4gEBI/fpQCdCcPwtpqIWI2IT5w+ DB2dKoafynL+JnXmQapQU30pCfHssTNz+tPu8+Jsb0ePeK/zYq848UV310Vxes8URhZJv1dZ5upa E3ZbSZmT1NyGIM0hcalhIh9IUKkxpnxhTeyRtDo4skZZ6kRzsyZhXcGq+iPDlV2CqJkD94RpbeVF b2091ii52fWp3iiWsM6zR2SEx4CkhBLeiIenP/Em+fxQvG2tQQR9kzIEMiksj3D8IC/A3A5icOhq 7NuEvbaKD5FUrjzGY9iwtXlHJri9sdIAaAhs9BhmuY/uUU6y3U/o5+XYyIRuTvhujFZRfqpdwmoq vjXA15e0kYaJzz7QyZ7u3q6/sDI529vd84/XHARvFiNKkKgdbWHeLgeSftUo0dhPea/jL/8rftfd 3SN6u8WZLy9e7OrYDceCKAhJW8J5mRkv3aBeDeNExw2/QHVDPkxctW3YhLKfcba3p+PC52BMO3pF 7xed8Sh2ix65/Bi61O6GAByuprA5UKL/FXbqk5y+Rg2CvIIT57u//PTInslmhC3lyGR0Eo0B3V/V JJRLZbiQ4ipao4Tkd3R81HW+U7zf9fkX4pMverrOn794VFlWNqRhz4Pa2SO//SJ4hGm7mqn+KfD1 6SaEWl5zVozVPGwXcG7UOW++ReQL1oC7QV3bG7Vr2pIm/ZOOrvN7pCbjLV2WWG5liIwTZgG4vULD BKx9T8VeQ9l2tC35lgp0gwgC6eXLSP8NJeQt0TAp47dcPXqFL7TbIyapX8xdS+4O+ENYV0DePTV2 0Z84dzwnZCH/5q5hHxlY+GPHBPKzGyX3QUmU9PLpVzCLmb1yIw7bW7Tuyrp5E2rhNhoCzjo3uhX5 cWpFaE94V6kdSUJ9Ry2rW+lFBNjQh/kNnr0dvZ+IsiTHjoEpvUXvpiAYVKKnwbRyg7qbGy65GGzZ nXrHqbVTw/Y1zCpbV8rFPZOjLwUTpQy+vAlObG4dNiAff9yEpDoxLRYbVw5PGrYH2aJq1ykIwZk6 +tE/xHtgYL/o7HnrovjPrp7zr3UzRWVZkJONGpRY7PJdcuQs1yCOWqkLDTamuqRcqom240cWrcqy hB4iQIj0BmbZIZgLhDpT6su+hAM6Rq/R4W5/4U9/W98AvHZ22Kj7/X5aX3rt6WwR8j10UccAp6os OHpYyKmZBlxIhtU1bgOyQSfX6NT5L7s+fb1OSWYeI6BJu6wZhl3ZglgPUmnLupJoUypwzb0p1j4N 250c7xf1ShUisfk/wXIbCOCsmn9+XfgIvpMwtsCyM2IXp9+QY6Na2bsELTNXnYr2CsK4Y8cY6H47 YbcGCdFnbUawXm0FuyfKPVfvvGTNYGVPfBnU73n7w4HKcnTemuR5wW7ii4aF/V85jpIujjJG2PXc eqYoqQq7jpu+Yw8SypnyzPJFHZFBJG7DoDde7MemhiZcE710pP1oe6OGz04FNvDftbYS5iJ75Bhl dS4zjuDjlNJHbE5ebdi4eC+/jg+HNW+sOisxGxXMa3kaX5gnk3hsgiAuoE4mhutuNGoXy9b0/93T 9feO3k4K4y/CEIczelKnVvVb1lreDrbzpWidW8PXfQRCNqnapVhhwX5oSYSoaxBMzIvge3sYS1UU YOBbxuiBGGk0bIjsyhy/0HEeHPGuv3Z8Jdr3OIXUhPu2ZK3FHncrdouPTUkF816t/A4FSY/KDfI/ E+c0JV/sQZ2RuMeupPc0aoTs9Jz48kKvONnR29t14XOIkD4XzbClnnrj0TCx0Qd649KOYw+geKTc ByTZy52xSP5DKoTm1vzvGzcAdk3e7+z4VJzq6rnYu2d9ZE4GxQ5fHbKBvfbBh3rW2ji55Bs8GWjV 3O7N79uNcRfWQPZH/4qoIEGBWy0jWRDh2DvZncZGyNypW9U8BdHee6xOuHURhNYUukAc+/ILR83s YpNoi5yb6ovgNqWnzWeOnkgJhb5CEzhJvoNvmEA3d8xFKKe1YO3IBi+NGuThCA7rXgu2rc34Xar4 8pN80RzyV9oTysqoDko1xQPPLloDiB3KF/Wl9NUQhCPfmzKTeYY3YGPLBxB8l3fZIrLFhkVq2Czj JUL7Vepnfr3EPUQDh7xjfJT6NOQaJfwafAmBUwl8odDLKL7+OpKK9KaUBuKmsna9ReTuIkSGANXk kNXKlGjE3agpPyIrPK7vBdY/88XMrT0H0r2m2hDXayMqMXG2vZ851iEfLpduogsq6xnsAocX8TgJ RKCa2CUntgvKN0aVH4Q0pOIo3kmXS5J38H+1XW1vE1cW/r7S/oebb3TXRa0DbVWpqiiwq11pW9Ts 21dUIjUSkFUS1N2/sf8gvG1DSxjHdjwzHntm4tjjssFAyvIOqSiQQhq2FEi8IaC9zznnjsd2KvUD k6oSie3x3Dv3nntenvM8i9akf1eHjbXcLWIiZM13r46JTGkKhPdar67Z4vPcI3s2zkUmDL3eDUqk 2Kj3wnAbCRG7a+FFkiPl/k792Lmm0q2bZcR6bghQqvyEGhCSV76q8itc20vrmRtC7vP5lfB4Ybl/ sO3yckwiCLKKajPYtEH6rwMKAR4iGyDHYvg4d6cwR/F1WjcseRTsk96bHczPEMNFeRle6M3ZZ1J1 8wGwDC6hwfMilCVY6ZNjS/IsEcPru08G6gqiydRH0+lxcF5aN8k0yD4FHQz2P/qdKbOQ6sClPb+z JNXP+unPoOs1x22wtTzhk2KMj1etnwvXtddpQsWY4VXoYKNIv73bLDUfMsX4WTKWc89yd8gIgiEp JnvEAtabQB/adnw7BERLZ6IEL/LZyKFDcIn2jY725wtQRWfXlIE3m840zYOzORi0iOAMXT9Vn9rX jMDjbFChx58MzqxjUsU3VVt/UsXKDYZ1dEC9cqbZxHjZi/rzyNjEEe3rDkEXp8dqg+qXNAzRi0VW xlmr/Vh9ND6MNk/etJIV40Gkm2UUru6hkXGIPgwd3v/Jp9ktThodHkucBdZRzj6ldkucVtk3fHh4 Ymz/xOhY/w0FC1ZdyPBjl0/vekk3qPo5ZyF/RS/tc1k9p40LpTPFHyAyS07DlpgO/6l1k1nEBowI Gy6Ipi29+hqryg1dmwRV0ho0+1gfjB74hw4Fh8ePjA33R0gzwb3meveyUNF/dZT6JfP+ac8qazgj KP4BhqWr7SyuwAgBEYF95Ep2I7wcvoDvqdxryN4ANnncWi3cLs35k0mX7FS8FYsPuKvrbnrlBOHe HtL24+CwZBx7JkYogkSTrZXofTMlJyIbks1FDvNCnCbfLgT/ady7MFvXKzk7eA5B0/4kfpbid9w6 tKCXRaqUQPilsHCNlCxx6F0lfuDYK+0yfXJOhi9fPU9sYizSeIZJ1h78vfB431jktdzV+UlQMNwm ABK5TKzwh2Z8YsimnGEv3CC5RBnkfg918MI1uOTGwSFwdGA3bw+Y/hK5KNgg0AiU2vCznZ5AYA26 BMATU8DYE3/O+JVlZVfJzIeQwkV3e6PtLNEy1Sbf+koNDGg/031YcfUgEksa7UlFlb8IRgFU05/r L2xjpw0gl4mvgZI04emrDd8RYELXsmCsqAoC7b6mGq0IuTbAVcqebqzXz22Vf+VXLHMmgzSD3Wwv 70yHs+XlcImUwURXGtHYf3pELegys8UfRGHK0FujpSBcjJGlxzAj4Lf2J4lfAdfuKiB1UHppTQj7 PcWWydduWb+zjqK/wT4hNoAqeZ497Tryqe2d3Ff+VGGGmbaKJzJIGARusmSUL+nxZoUVBfY/Q590 lfOtfoHp1bX1eyBpJr58MVkOS3SEwAl3WLIxtQWzUxj39MLtA9J8V16uVGjMJLjjnNaPmpQtJD6j 3FnN0395PzW8hjBFF33rPtXbtkD7tGyb9Llcu0PmLkoOpijZ0X1nlE9q00ke0+5df1G/37Vv14f9 wVh8xrAyE9qdcMdop+icNDLtzmm0nq8609iCyZ1HeN/k0SrQyLQGxR7R3Drgi3Xbf0R5vxuNqMuq 5G44a+EZphIxMl/w3IzC4yPSSrBWqfFOj5CkQTtStKRGi+4bvRmQz9Bv6uiFpva42KNxFry8tzj7 tL8GxzVCOfEEVQvort4N1YLenqxBJNp2XDaU9tBisSu2vC6KxKkMQ0idgzPNx7NPZ5/2LbpE2p6y 8Nz1GLYJm+BsBAuUpyPEZnNauzkXGVtvJbN2bcEvpDUE9mnmv5t9mv/mJ7O3GAFJIpL1aYHvCwiG WMdCL0MHPcKAtWjHoMNSLe4dH3Tks8XVtKatrYo/5T4mBsyYLT6tcWbFnDkW58eUHnhvjUkPap0y B8JcG6Jw3VOwgL0rB8/Bbommzmqz484lQFVOl1icXc5Y+YxveYscjugPVGracQOMg+vzqQ2b/ZKh vXv+tHuv+sPegb7IwblWuEddzoJ6ztZeitcUw5KG9v4Vy9e+Hrb14xP1D1oACRuCqYIDLiIh27l4 eJcc4EHAmvgMn9LXnFamLp7asHfEzVh8E7yyCfYrrDrJWJo8WloVNPDoPIAU6B6hFFEMIVLhkn8X UXQ3LLfbq2JhnKK0dxvHLD0TtLPvjMADfhfnAuR+kzkMJ9iEsg8qMJ33J4XQVPkZdeVyhw81KlW/ cTZBXtdbILfnqFxTuOl97dyS7RGt15+RncNaAIMyN+N9TocU+1930swgCAX3B/sPHkSqrW+lLxBv mN55j8M1EqSgnjE7aX3UYKLBWKh23MXSGVAUxkv9SnnZWYKEhV38XvzJ2O9G0R24w/Xa+vwX8CyK pRahKHpyddWGflNTaDllS8Xbhxym/CRzwm3vOhumuzLDKHorOs3fLP0vd9uoHLBMYqJ+mtqMvx23 4VQiMZC9Z0h+Ru85z3VOIiQ0MUubmkTxKXSsau+LlNXFvuJkpEOxLyKmkkZCHyqtYbHjte+jjz8c +uOuj/vzta79g5cjHbe4UM2uYIJOVCI0sOGd1WGpPjz1iKS9tuN5VRvJjikICoVhYBPlL+AnoEun 1RCvDRQAxMCmNXp2zip1/dTy32wZt3leg/xpUdFwHVTDKQURF2qTwBkKz8OT7uPyArApSZzNlETD elkDqaiiRZCftyykT8LjRtwrhtdwCrYrF0dcJITfoI42SssJFMZara9U3NIZHyKG0SVUSJT/JM2D Rxi0AfwM13L5vokDowtNnSwXSSnHQp0AAFJAHMNZmI4cEWyyZEcmNpZgS/gRhFbL+EEUVdwMCJGL j4SmSSV6MEmANr0igNB0D40cfn3X6x8cGTvcZ4thhBnDeCxYmPft6Vhtbyqm5RCSDmpJgoHQs1Be nn3eFZIRmEnZj/TwmvNGHTl3pfT9+++DPi3eWV39JULfBxNEJpUDJsOtntackAPqLaLXTa/fPsjo 6TntS3IrpXEuKnrJ6y1BYF6Qss5t6qXR7mwzxp51DS3ecs4XFU+F1VxeDA8VMCp1qjVuI98NvbvY DzoUTsLoisXwMpUh3YCMcRxlxUuXd31a0yQO60dDKrpaXc7ZjCztWT4AcNFcvUNxvXmn3+4gwDqH Xw8BPxoOa3eii8gvWhv62TNCGqnl69q4UqJc/7Vws+aVWsmXifqQyJNix1G2bSyQKDWFJLnIsy5t DEUrTQcPtv1ANc+4i5LgS2s22Q/+3aFDo2P7D6o9w+MjW1RVQCXVXO/4DIxeEdvUGSP114dLnhcs cKy9iWR9YuXQtOtdOj8flevn9C6cjJrWhjZqblniHu2l4OIq1oun9lOrjfpk0h+HM6PIYFmrGb2W 3QuuJT4lmm3ny08AbyFdEuObJw6nxUBHNPOT0g6pcBgPpOUBCZ15Wldnj7bRRrA9RaKGW3VyEcoA yoTKaifwvKieJ7PMs/+iHY/KMX5PAgzEueDTNvFZV7lPc3dsmzYAPq+XrQ2WL2cjvNzVTRCd8k6w Z0Jtpc7L3B2S8N4uSXiy5oB5Ibl6PthEtcoJq8ZEd0cXg2LF7HK1WfyuMIe7MUk6/yyQD3qIMhy+ ebCWb6bmEgmpuv9l0HqXokrPj0JmQ1bZXjBez+tMt9LCZ8GDc61SE/+I+QjhC3xLXCxuy4UuTU+g FVwmCEPMSeAHpRk6+KEJ4a+S1golE8pP/KISLyC1eXhHINj6WH7s36uHRDpoJiCdr2RvtHk6uFeJ Ol+XkW2QyncKDXj+FHgkmCCia6CdMjC/QQlDSowMdUmLQjQeSpNGtNuAXF0d9umV3POkIQAB0qwy UrCX9MOMlvKnVMoNOW93yDRVYtH2jlSVH7qL4WzlKyU9JtGUXQaLhHa+fYPMLD/0voZ/YPW2Piau gylKyxYLlXVaVxfuy2ZVP2NQC2y+ljGqbNvCk+HlYrEBrH3h0sBrtDoBx8n4N1Gr6kzADsmovrXz DZKgmfl37bi/mW6XiKGVZpE+LEh+yln1rnW/sV5YQQFBbRO3WECCbw3SDb6WipTgm8JCjQK5V6+4 qs8nSWI1GLpQVqDoI8KGYCN3hf8M75dV/kiVML2gWLim07r626lena127lYppFLez/vZFi6lZ9WF QDlsV2rNGVW9TExXCt+o91ACPW3bUBTgjHFlu7mlnjudW3cvIBzetPI6dIy737jJciXtXLNQJTsP wjVts3dA8imadtaCzaTZQ2UB/BJt1/YW0C+gwrXcLQMi9vwpWsWZ3J1cPoMCI/Riw1Imk9Y9vynT H15uPlbbsrv39MyqP1lqSRKF+cCUFeXPdpQd8IiM8FMXvhPMlxRasybnlVesDtUzjKxBoeZsy4ZQ teRTfo2884vGtPzec49lQ69O6q+GG7opsgaNH8svSEp1q/FRP8VF6ownUknt610g0KK1AJD41fCa OebTGvKgII7Dk966GW7XCcO6R+GPyrnv3dDhF0tB6SdI+oMt89FkbNz9Yb4oyyVRXIESXfzB2WeE zKHRU/q5sFLRj3w9PNp9leB6rUwlZyNt2R1PBmf+uUdPJOkuLRTO641eP61mAtKWyN1PzYy/s2OL 6cs2eqFkEJ8lxVp+IwmkUEoG4xS+5B4wQM864dnzH/nF4LpecaUW1BFBZEgJAurFEI1J5IAJ47Wq DFlW19NgGUJacWUWpLzKQEzV0yr8iieM/4uv/yv6AbtseTlsq45glnnp1T8xhW/CF4GQwGkrJFZZ 1wwviDiGfgF3GSsPoC2OCDLDtkHYBZdFLIzwEIiw5jZiVgB/pTQNXmZ9xCyk1XmcHEj2pwaS5YGY 7QrZJajCxyJ2+iZlVVlWtYE4vTEfnC8sq+wbb9Tz2lxfw4soXV3Ua+23v/sNroa3xGmqw0cODGcm Rv92cHh8PPPZ8IQa/3RkbCIz/tnIITV+ZGQic2j/YXoT/HlQKQL16p3WQQjNcCVch+V3vA2eXSMs wVKLS0QUwSrmUHu9NDPTYcbfvQcF/88bd7VZXqvM03KNu6PATW7eSLAiHqbeGtqq36eMAhFJkcZd /lbFRc9mxOoDtEDHRkcn1IGRseFPwHUTRCOHDwz/ffunE4fQMxFF30TnybCbDDndL+njRmGplbtS OiGCra6H+/LWVHzjPQ+kvjJnAa3n0gKTm/Tr1k3/Eu3f8gvrKDUHpVbUT66kwZ9aSYO8kqK18KR5 NXHLojC4QetJf4ZK3A3tioQnXYyOfnNrsdPE9fEMZdUzBKHKEDgqo1dJ51PBEmpb00R0QCJx+u1H o6Z7V/8eHq/MM0YJV7Ms2pLEvO4fg16EvoXClH2MYWI5pJ7tSkSPITXPLTmPO2ge0V+au83bLaKX BShgzHufLWRrCAzcFtZQv7itdnEnmjXfe09FiyhpWbfUoG37bbpWgma1vgK5KSWs18VlfVX0Cl0K vtbHN66PzDL+Ll2n+r5cw2Spr5TQLkzmPmv3yStO3Jq+RkvpW5I35x39z4iUIAlLCeERyjUBzKP9 BXo7yczz/qF7Z7LzvFkb4ZJ1DP/ThBkCNbjs8R7iafvlL/4PUEsDBBQAAgAIADAO6irG4zSmHj8A AHHtAAAOAAAAwK/Gv8euufbBry50eHS8W+lTW1eW/04V/8Nx5wuuQlj74qpMF2vM2GACxE5PV9eU ArKtspBoScRx1dT8LxgvMQnwFOmhp/U9IaSn2FgytIN3J6FNSEJMnKYCtJepOefepwXHSadq/EY2 IN3tnHvuWX7n3CeA6utteuHfxUU1VbgBwot4HtRcvBy5Hb8E0mwmWZxVbsUqsbvVsc1NzU1vgfAk 8giEvUxefCpJSgpSG/Kmeic9A7nLyn31DojrUpRm0VhlPbYBkiTv8YXaqC23mphVKxl1/kpsARIP xfVMHhJ7pal4mXfdya1m8sITkLaUdaWc2xFFyF6P53Kr6bT8mFiAy1OXJ//P/y7SQheKc0khnVYq kTVhKveltt233/43UJcTe/Ik2JAH2mImL30H6ZnkT5kkmFhbdZuXL9BCl98AR5doc7jYq6+3qi/6 oMwVZSDZgzqb2MnNNfa/9RZfwfBGX81Nf2ZELRZjYu8vAO/5PO5ROOEd9QRgKDwx6g3Ah7Y2436e W8ydXQeJl6FD/XAYTCaT0Wxw2oxGowF/TDZcTDc+zS7Gp6pG5+IJM1Jr6fH63T4P0PuDQFyFPEGv 24eMnezpHzSZzFY7soM96bTwLeRXhSeKCumIWFaeK2VILOR2Ib2i5tAeVLZIdA3ya5l8Ykd5oSk2 zlUyWRX1QrkvbKF651G5kzflSeEWvlGvpXdwqaXcyoEDsLArzYOUQnVXL6k76gqkdyC7h6Oam6Jb 89vyFkTWYp8rS1CcW5hUlqSNVlDKhRvRh9ieeIgcxO5mN9RlRqhVzUlCcRZHXFKeKetsZmQrt4Nr 5eOxB9WV2Lo/gvhc+rjKb89gdzfO0nSabOwLRSKeVkC4oSzNb0dvy48PHGhuIvNOvIR5FUkKU7EH akW+CvlrSUm5Fy8nkTFQXiRmhUnaKjDa0lOxDPkv86L6BaNFq8jTsU0ULBpXUZUKcRJko1hrQtRF H5wNetvnGfW6NbUdCKLq2lF1W0YOat1D50Nhz1gI6qoL2WLiE0i/VO5Fp0G5FV8AzUg1NUn+JD6V FSg+yb1MrxRn5f/JbtGGccCBAwfU5ch95Z4Uh9xu7kJuR96jRtYprRbTiSXxaXaL+80KejxRlsXU NluKfU58k74fSShL0Wk2RRZLM6xTuSd+h6cqYRf3vsuxu3RcbfRpS1xng1obl6t9WCznF0Hc0knQ DiZo8ePiInJGgkU/oKwf1M/S7Yxgn3ckGAgFToXh+KlT3hEPvD/AzvZoIOhx+6F71Bv2BvxAh1FU 0QI1pjRX1dllOOo5jyfd0+fq+RMM9/U43oWjnUc7h+GEa9jsguGOjo539NuDje1BmleWClfjZW4Q oFwVRfkH2khyqiCZkWWr3XxQ2wKQDunFjpWxIyuFx4tRVCV0d+aqKVjRe5vMFqvN7nA2N6HcznrO Hx62dnfZB/QyXQvjpvP4YPcx6BpsPwkuMlcSA48u/ciVzW4wmSxWg8nldLAT/S/2m/q6Bl39gwab y2ketFgcNhfNeWUxTaRa6He2GYVnEHskzULi7mc/kiskO0sKiI8EbmPNTQiQJtUSLFxjHpOZIUMo ewifpCmCT+Tq37A7axCKmWu9G7V+jNwZ9PjcoTNwAigMM73m52W0O61Wg9VhtjgNLovd6dLpkEyM n/bRwAceGDgTCAeGzgTGuWdlrpX3VF1rr3+krYHJgZMn7UbjoMNktFntDoPL6tRPtzmAsXRVccuJ 3v+AExYvtHQik+8NH+/qHjraCF/w3UjQPXIWsiXEguno4iT6ZAyGympG0fCsTqyaOIbpRA/mQ1/m 9YfhSGAixDCMkbsuLr5Xo5N+HPEoOjDhHzlzgNzrKU8ohG4VYdQRVEPo8oS8p/1vknydNI8rnWfc eBhhT7B6fBamXV3e0EjQ4wkzqSjlTLKwAaVFebIVDo2ELP/JDjAEGKkRl2DPjFJBlMYGV5Md7Bv3 TZw2eP0hEJ/Gk4XH0iyet3gRf2WT8g8M/IvX3+SJ1/dmb/BwJ48PdsFA92BPNwYfLZbRgYN+p8qj zxHEPj6v31MzDFPVk2hqdqTHaOrs7zTYXXZ8uQzdfzqqH088BL13rLu9Cy0g4COLRTttM9aTo3pa YTMYLVpaYXFZjXb92LJo3mMI+trf52ycsL6a+HDvUcMXxCdj1GiwYJ5hcrlcvANDJ3UMn3jH+e/H eBNudRSbzPaRUdeoYxRb9NuLudFlBz1jXk/QgwTJZzc3vdLMHPkQz5jeOgx9HVWHbXTYbQan01Sb Qb4fQuT8j3U3zBjq6rMZTR0Wp9lqMzoNZpOjuWnQ89cJL1Lw+MMhigJ4hq3oofs6YLC9rxWcNnx3 pKsVTvb2u5yH+roP9Q8fMh+l+J3dEsXkT3X2kDsl2SKKEUm6zLHzMuY9ykvMZCSpMMNidOxBeo9B amEGe3O72V2W2REkPohYJ5bHlFpZR3MXJjGLyl2I3FUrkTXIfIrZmPJc3qRF0jOAmcsCm5jaVgUt dyHAD8qVxUmkXppV1pGsKLN4gdmV8HBhF991ncDOyFryZi6HSZJciX+tpUbNTVTfYEviaC2VUF9w Z1XGScoVyvQYGMxtgZqPXyk+R4BCeDdkGPe5w6cCwTFIPFq8ElkTv6iSwll3IPVzvIzsU9aBM1pB /jRyBxcW9uRPIZ+IzilJyK0qV8jR7ZMdF0FOSXJ24uXM10x+pV2I3EZApIIv4D9tOOPxjTKpsc1n S0zO8tX4nDCJOSDlrkiV5Z8pyO3lN3GTNKKwqX5R27xe2m16FSB1YSIwds7j/hCDBzfZuivpOnmS gK0D0YfRYLZanS6DxeWyWH45wmKzYJ/DYbEYTBazy6gPnDJxlNLtDp3H3AQ6kfVwIMhrLAN44l7/ xBg07kBLYNDQBgyO4XfetRreMdo7+wz9tndMx3TCoEaXlrVguL2h3lmUoaXPHaLYfATDrSfI3B/v BeqOLdS1OHEblLnYzUyyqt/qnUIcMGesUFdhjxTmsrCnaQkoS9Ij7Mp/qTwndWqFTFKdLt5vhYIg 74jr2evZYjQVWWsFtaIsKRuFOJluK+qqNIsGH/uZ/hOEB+EGS5tpbS2Y86oGUUaamH1doMnIqjAT X8COV1jB1B1XBfkBxO4qGbQb9U5sg8bnLibJfhqZRt863Adj7pEzGFVDrTDuPj9+JsDe+gIjZw3j 3pGzXv/pVhhxf+DzYBiAUQ/CGPfYBz7WXONefrKPf/0SPyPDd739Q8Ptx44NHentPtbFscfA4HEK ASYjKzuqs6+pUELnqJZD9w51Dh1zGowYHAwY63D+cHffgH5MM2Q4dH7M7Q97Rtr6A8FwwN/Wix+C fk+4bcgzMhH0hs+3UdEOGvJGRHRfFdBFbqA3++1JWno42D3c7j1G9tgz4fNR4bVW0Ub3+hDPPssU O5NHlb8PSSlbqh1itlRMJ+4qS/G5TFJAb/sdBYxVVLPiTRByO/E/Ui4t8w7e/iz2MzIWkdJJPHbM crX9aaxClVWosgra/vYXPA7+cuaAJxhikL0HY+85t9fn41P/9cxfodnjHvP6ztdKLP96nXZ/2HvC G5wI/Rrhai0QlHvpNBphakO9jVI4Ew6PHz506Ny5c22h6nGPBNrOBgFtdOFFbl6tZK5l8jxBj22q l1hQJYeBRp9EBUSjlbfiZXEdz0iYwkmxB/mvmLVHLuIhLexq5VI+VLpEAVl+nF7B6SnW+ytjtWIA daAP+I2BiiJvNqYcWlE3ezudziTZUBq1+KQg1OdVr1dWYP4K71Luo1JUGcJAm72mZGhe8vv5bfkH 5RnksvF/kiZScXrfQog/UsI0C8LpSCGPaqneopnF69ldyF+oj0VlVpcZx5fIQpaKs0zANRZRw69K UWrFBrYeDiw+VpYQakymZ3Br1RGSVJukbaNa667KAdUeD2sZ0+rSTHIWIrcWL7At0hStLXtd+gyk R5k87paK3NQ16Dk94kO9EZ6xCmxpqjTH56h/lzfFksb2/LYoMgbEz7UWctq3pZ+ouL6r3hLV7DMU jPCN/AMfdq1RkrQX2gBtPbeaXqmeLtuEssrFTqJCesK3uYtsi8o9VgdHIFjWeEaLVy+h51QbDqvt tPcUD3jZ1VgFw9tSWuXyLy2y0TSINB5Bm/A1HenX7DyYxhBfVT+DsfEKpJ9HvtUrzLPsdGigu7sL k54B8n/Ki9IMXdcly3+m8LASc3xfAHtsEzVens7kERrLm39htblxj2e0zz2Ok/h4PPb0jPwjKWd9 PN2o2Iwo59R2aepQdjeXrVFgQAGxJYVXsFgkiS4NvmHqoryIJPBQ5McoiHQ0IQCNqTnc/GqmgKA2 XqZWlD8765I2CfG2dFlAAI7LsDsS5YVyjzU3bK3m3DV64iVlqUDQN/lCmkIK6S94alDlTrie2kEn lRDiN1sB9es5HnZ+NfZAKEizrBNbnypqblX9imOYxEPhm2gK2H6pH8Qt1MSSgEZC9ytclUC5RUkJ Hrd25YO6LZK5LVVtSVnFhkrNwjFg4PRYrThVnEPQLspIg/ZHQQbXyk9li8l0zRK59BsOpnaO1fPo 6pBv8E0ky8KkRgtx/B0QLmC3LGZ3S4Iot6a2I2ryZnqW5ROUdBHTFbQGZvuVjMo55tyhaOsiYOJj a6K/r65C+QtOxVQtRXnGfbUSzxE2Q2ttBaWCBof+ZppJEqJkxcqP2d18upUxhPq1jZ/+iGLFQ7tZ 3AVas8o3uUItj+PE0CEIk7HPNfTW8ks1JTxblwjx29y0/3N1bZI02gBJuqoe6DloRPXItOP5FSo1 7Zen62RebX1TxEhHoaak1F9V0+YmYVJ4otxjwYxrNF3uoTSret3K3lEwhcV7DMwnliRy11X1UlaF J61QmpG+01ismQDdEqp3qqNq6orbSewxRnjMpI9U03zNblmXWs27i4tZ9fdtOL0Tx+wgdwdd72EG b6Nr4JD/CVKKkRfF/Ff5GBVs8MfWymut5DfI7qQcdVgd1Hx0DDsIG8JJr380cC4ELhscApcTf/UP 4y8GnTsH3oPiN8V0difyCK02tY0s93b0AcUr5CILLby3t5f1QkRV1g9SAYRXQlhbi92qvW1uYv0t 0qPCZ4XHiHVQEHg4ZF3JFWGStoep4ODxPjBbE9+m/8bnH+nqApuxr4N9kJ7GKiwjS1FoNBnNVngf HHZnnTzEE5hFPaN7ZRzIWlqUSrJM7GoElXJ6Db0q0USTIbEjasN4eBAMGLUw4x53n/agqBog29nw qAbX3nQqoEvU40XRbDH2d9y8qt6kR2PYMxf5ZXC88QvNOl1e+ES3pmioskUjSJLNbkkC+in0bluR qCJUEZRevPBqZ/Kn3PfZbQR0xausNkWlQHkKU/7c/DYCvi0OM6HFqqNUeK0y+bi4q5QRdUpPxY8l EdIrmaReFHn9aPGT6PT8ti532HVSvNjTN2Cpy5gSI33ImV28bBPdLFQ0CCnvYvKhJ0V+baQuLy6C vCM+zZb0IsQviYqz8clYRbsm04cQv7Hp7hhCFJJMYTJfkkozehHjrugzmd1I0R+Ks5+gFyY/oBdR zQ/dlWazRYiXEzv53WpWhxno7ch9aTbzKfkkC0vHdOGB+x/huSxirE69RGiMGyaaZv1ock+TKUSn UcA2IQqRBNKUrxIc0oeiSXvaIp3MLP5/7ZK7nDTdFihrpV16CvOuiDLeKAk6kXRyt5NJzm/TT9Vu 8tcQFlX3Cr/5yn35u4ey51N1laCT+7T2nqP9wOyQXfrll/ULgmYn926JcjKWn4fCY+UG6EWJuzcl mRRILfZLOx2VnhyGZEVd5ij8snJfVKmciQfKK0s7+TWxJN7D5A9zyEgimtIKmzJp2f7FRMwNlb+x 1ZgG0qdq9Y8lfCvzVyA6LStUOEjKP6ALUpelefEpgs/szYh64FVN+AOefTwKmMImajmjcC8jR2/H 7v43/EEvgXEXTTtI/RhJ5Hb0osO9cvEf6WRkTd5rIYK6qRv3vtIj8avUBuhLijvdvKhW0jsIuF0O vQiZ9hNiGZq+W9PA3RAkvpMxj+BIywi/94UuxV5/UtHURkX4YGB0YoRK5VqruQ06PKcCQQ8MTvj9 Xv9pGPKEJ8a1Xkvba5utbfDe+Omge5Q6OtwjZ6vPmrR9pI2w/cqIoTG3zwcdEyG61grRHf+HnqA2 x95WS4YxBbbVHtdw7Gun69fj4+y2YADX1cY4+ebc7IYh7A6yp3y8YY/W7WpreMizdhXR/dG4D3fO rnRNfKTJ2Diy+6ORM24/JqONfJpMjUOG3j22v9fc2DsQDHx0fn8/irRBHp0+r8cf5sKl0SiyMW0g CnnI4z7tDuOo4PlQ2O1Dzk8FtF4U8EnPB9A+Oub1e0O483CgSsG+jz/tqbk+tx+z6jFOrIEdx77B /e21Xl002sEDOQLCf2BWKK5TEpj8nms1vx3UvpOw72W3O6VHwqRePPFo3GsYOuNGM7C02QzhwLn9 sSF0yA+H6QFA4tTJbNDoMpsMRktPh8FkancZbNhqMfQOHWkf7La8DmIUNjOF2rUFauuAsKfM1e9z bvGi5i/nmW322CaGLv4tG6rO4TxWFtXlMYi6WDhiQMg+i8A9BfFEcTe/Sw+4QkuX50OPLzDuCR58 9dAsNpOeR2WvFhVWUX0WPyk+htc+QLX/ZTK59OTJVn/cgq4C5FzxCfpam/athk3IXURobjJaiYcG JX8dMKInDLWvXMTu1u9z9y9Fk9tepymZy9kt1A96DoF9nyr7WWwB1SRbjNGTS5k8ZmPbVP1njzhS XfZ1ixAJdj1NaCz3kpJGBYTZ/Ia4mv1SXalvkWvsAb2katXS/sh9Xm1ovASvRUGTyfILqerDDscz iZvxRKyS3UEZCpPKEn+8fZ/naqG7I1lk3/6a1gsXODjk+V/ervW5iSvLf9+q/R8uXzYmIymS9bBE 1UwWP3gbHFvh8WVqPeDaYcICZZsNs//B/hkOIQkPiRZSW92tlrqFLLUgRsa8MRMgHmxDjL0kJMZQ uGrvOfe21LZbTE2VL1QlGLnV5z7PPefc3/mdwn3I4pqQZ+SX4FojaEB69wEGgxlC+48OHT3BBqAL TtSTg0eHBtZocWqBiAt+tbb564ukYuEOdOCd4Exvut1QoTNcZSjkDwb84gJYkZhtxNHj/S8Dh4fX rhlRcqO23AMnBr8Y+lBS22yp3SeOD/z1Q0ll58LOzv3UiAzTec38raQTgH2pj/WHVHE2oJZr1gHT uwC2wDAG1Xly1vYhzXHpKkIdeDqeviydIVUlNwdgzHuK4hpIkGt6WZZJscjvkehH/FZZSpssH5Df SRbvaz/XQSc+V41O/VEpA/fCDxD5mC8DKuCl3Lhebpj2hQrVRy+p/1xcQQyGl/R0MJtDup0v0e2R ma8m1FkiL6LnzR4HAN2UbICub4iHVzDTouEirH6X8w2K43lHH7zePxBjWUnChSsk/XFYm6aU5/k3 YUD1bI12TJJoF40EhJMcd3mOPwCaS0Bq5O3sFWtCeV5vdKMRpcel6XWNwEOxROXP0fOXKAqdAavR 8/XtDvoc48LRNfhvODWpSKJdql7iX/GtGbBJ/ijtxb937Ni3Z8/OrXt9e7viPjL6CqKtV3XLuWKK d2k3MNFxrSD1weW/q0t2CrTtbiHYo5TVao0UTZfBglFPqbmf6HjSxXvbvmKbKN78lKrJieISHSn6 C8t5Wd1w2AAGT5QFBKBoSjqXuSKfpTuJjp12gy5p6aqSRAzKarHU2yg+1lTZor2sz2x9gnLPit+U 0kqSTtscHah8WSprNXMKEDz0iFQUeTE7QWBOG50AcCSBfZsvOd5zjhR/YGuosFTKkfR5SKYif/wj kb4ra2TUwr8dER28LeUb2Voy5yAQdJ3B5hAOCgJS07Tp/FISUcuI2+Tz6xhWtEKUckajRufqod8k yv6J8KDQeHYELAkSBOz2JbixclFfuTnzHSwL6S0B04PAN7gZyZGo8End9/A10zYQFrSfohOOsJdK SjOeCutlyD4t+nbGu0hfV+/+rl66Df0kHPK/117mPe/uy82hNqKzC+ggdSmllJ44cHJ05yzQ1TeJ 2wwwZnmNribX3mfOpZT0eXwJ3f/5FKQj05d5pHdKktRRW4oy994AcmMJCRs0frNx27ylzmLjwGav Ey8EiwXXoYLnlUeZiWISzmQP0Rayc1TvBH2tHrK9l05Bqy8adu0ahzkgKuo9UlvA8YA1I8rcizCz tziqp/A0ys3RNvsBXiDW3I4EbDNTxUMwFvsIxwJwHZD5WVMWPKtANlRLO23f9XMRaWWrW7vBMtkR JOahL2bIMwCL4em2jPCM0deQILps5tz9NQCecUUXCIToyFQTxtPUD8RcKTyhGoG6f1fwHTmi32HL 2nX9l86YObbECyLDChFms3MANYMHoCMPu164oRi276+1b0n6Hk++qZNPiPVWwtGGbLpnXnDZraLE tXEQinJGHcc+2mGEFjWpJ8wa9fPvgW16GeBR94GtJVsDA0dY/5mRDjkXJR2IWbBRLaKd5XC4GWTh Q6y3RhgjSw8gKjdE/RPxYoOusbs2nx8UtiihTD2b41cWM+CvtDHdjDe1MOmbXY8leABPcOOFkkS8 TKGSHYEBo7pLAsBS4bI5DhY0fQW0Xtfpw67nFNeCvsY70ahj+fWXMaXeJ0qthQN1mAq7qYm1wTmB VlmimqhYouQydcpievlL8gzdVOFW8SssxBQp9QsBgY6qLObMr3XMMAQR6VwwROAYNUqp5VEjrRjU 1hPZGiZLsOi2dIZ+xrDS1ARzneTiXWlBfQTOY92lB+/skrJAjTxHcyBRZgbpUdzXyrlYFJoFxDXV 4tc8uZAlGeApSCXQDuGnQNUjypgLsUOBs3Yo1wjiTgFI6r5d2G+N85DY8UrX8R6g8L3dYviez7cJ ke3SO2lZT3jce69ZTzwQyZAX5UW6YYz7ikKHT/tVfgOxi6+raDEzbGzhe2r52lbBJtfXGcss6w1s jIDfvyXAvKRqMsOIvaSflZ/ZRylFT8J/TeZ2Sfk2NUtH/Py+QkUaAb6uTdhj6rZSA/+qSKs6xI7L rr6Ofb1xEsCTydZIEPOGofWgP2rdU1c2/yPHBBC/HmlBvwXAXxxjzB5gMGDQR5XiXZzAyfrb3Yf2 nPWE+sHp+UpSm4Bkl78XKnINYgdl4wVd9nS9MmeDGIvmOwh2NHmR7eRA0tJNh523qZ4VQkYlWQb3 OI3xf2hj5s5734VfD/rXemrCpogZEOpzuZaZl86QLWTdDImSHLb9VDCTlCTdqi3qOGA1mu1T+C3g y1kOGjxHhwgmvPoaRypLXdRJzBiHGS0mG9PhOuLwOrYUPERa1mp0SVw2iXXNeArBHXqs1T1hdIQh b52QJm7ub4jVhgRtbBeEbZbru1vM8IW4ZYB0ONgXuUCNBIQnA+hpVQNFNYLZRHvjO3ECIGlqzIDb 3nqO5tq7zDBb2aLaw80l7rwS9QH1C6gTtKX+EeZKSAuauall9FfIDi6LspFDAXt9Y6iLWTBoIdNT O6mOF5ZWI0rWrCw3F7fND7SN5MpZjBRYEqQX3cvMU+U+dsGyYMVKI1fO0k1hPC3+gjaa22qVVWnB vIu8ST7SGv30U/p9wGVhtBFfe9vtWOroJAFCtp04PtzT/58DngMnBo94uk4fHjjm6Tnx5cBgz4mj x4c9Ww8fHhga8uw7NXzsxIkvPDu7wv71r2kFxpo/HTs69Oc6TMXx2yBhnBWdg/1fEjqGNucKw1CQ rtPDA8eB42Zo/VdDzq/SpQBIkJP9g8PrnwzTJ4+dGgKwCz2TrupWZXKzNxDyYzQb54tqkimSeniZ KgewkvVEfqyFqmUpvdlVA1QeagtKUi/jc4FQlD7nMQr4Joiwp6ZbvqQDZsxv9mTPpa4XlyqTBE4w 3/qmRQjRJnTDKkIgRtTa9Dv92JBv9XUrBKG2GBNaMm9ZT9y7yxckPITmEjzJ8vc3EXUZU/rhpGMf NF9TqyOl57Jf2bm11PSRroMdye7ZjQnzHVXy8CJR+jQYW+tJhz6EJx1ktqqyYNZE4uODzBKrVtSa K+hNbJQmyIwMniwDjaDm8AuB6zsYdiQ4cNdRlCh2DqceZi7Y3BqxKGkJx5gFZyWFDSpPBsL8o4Q1 mXshguerNciO1PjWPbtJfB/p7iIE14oYYezMrLyhxmDlrZI0TMBGiRHFcaD9JwknSQFnYqPt3bo4 zn+bL1fP+sxb+bKvNJ37yVeopKZ96nPpLdw2iZEbtZksa8VFtO2LK/b1qDQiPdNqG70NG6KZzrF9 bztPXauJkcZ0TPo+bsHy03JOTwBe4SVm9wuQF65fYBhPqT1G9SnRU6KUaUMsUzfp83RANaXwRJ3K zYkRxFk+Owk1DzUFkQXSM1HCmJLJXAAqoCL13ZaovMwUnUi4/S4uihHKKTIHEVJMAlG/oH3ANA1n dLduZOZISTan1KQQaZykEqiMCecyRlNWqJbhPJTFx4VbXDKVRmIxMcLaGuHZMSBWfl1+Sv3gygw9 NAKCdBlnhMzNFZeRkg1uw9PSrE99Js1S2eo4hOYS5oQY4UzV7G7vI8Yb2mGzVnnN+UnE5Dg1JPOr lmIWbjzkl+YUNVMrT+H8gIumoBihTPMAARl4JWJkMIVjlbIj+YskKGrVBPi2SKnqBesNka6aD/WU GFFMyShKNQF4p2fGC+CseoibQlBGbF02552DTEmnLLy1UmfFiOQh/juaKWcRYyNGDFM1mQfaq7ER MRKYYtmxjxrWnV19O7fvJT29Xd07u3rFiGOqJD54aoD0new/PABerhhJTHXE/zxAPj86fPS/IOXG uq/VrBtixNlKQ0nmdQL8EHAEiRHFdEfu/3QNSqXI1Mpk6BJNjPrnzAdGMa9VXlP1b8iGTDLzwg5z Tn+ATPNgRxP9bnauftaIsmwDnAZhbCqryzPZmvGC+oFj5XNiZEXXybIsqyRGVpudX7NE3VmAZ4Dd knkgz4gRF1ktLkw2Gp7QEBVueOvgZ1HPskW9aE37qo+UO4IWSagR2FFXsleLK2LEcKxHNq9Z1+g2 EKQkA5zcANahzVlYmRQjiSkR8ywz4sTIcCiOvKVeEDQ5NnEBY4QAr9Q4n5sTrJ04vYD6LD2qlIFs jooVtK04rYCDhbDOQhOLipEY4VnY5pz8HOmos7Oijs8AT82vCzNrJV2csNAaYVPGRXHCgmuG8a04 KyRQT9Hnwlh0Rpw4boRAvSJdk2bFCOEsKIlqIjNHF0ZuxUrCHaYAUTxpGmuLcf997IespltipDHt sXfHbttBEqqs7DTjeUhR5bpDjCDOSzJeeJyaxliomABhgCcEGyUFsN0AsJUNMd5sgGfJGrfGHpGO 3/0OqAnEHP5tdh2l7vi+vXRnqUlhu5cnt+7ywq09+YT+EO8/9sXGMhI0hDFVUZaMkbEpMRKYnoDA n/pSkIvQSDFt37dvN+nb0bVnmxhBPJSRyI9t9Pw7hHAitjFjqfBAfSdICNMGewaG/2MIqiL8VZAY pguyc9pPyhmiTqmSJKpDIc64I42ULyrpQqWSFCQoyMPLWCkQi74yh0qQuFa+Q+UZq5rXhJwRDmkB 3jl6zi6hUQRwkWd5S5A4jt6eUsflmr4kRki4Eawg0mj2kiJoYfD8FvNSoWLMw2XcRt9nOkQxFaFU HPWGxQljqmJre4ft9+YzojYXT1YBSjNxCpYnpehm5TKYxxsdMXAICnLDVV0hFSt7TZSO4JknhbtW EcrJ4vWaIEm2fgAq5o0NDzuE2LQW6qxsmJamSN+JEcSTOIyvdCPWBsWzLyhnUtOCZDHtsL9rb/zz 3q3CgFwNeTwy8Vi9UFzmnowgSUw/yKP0sLCJKVXpqpknguTxgq9J7Y02QT7ASHL0NpZfopo9Ht+G YFOBKpdjta1J/S6K2lApgFe25fCr1YkCFMnYWPfd0RumNLDYASQqOYPQ7/3jRKAyEGvhRukJ5iQx bqjCIiRWJZXnSIqQThBjHhOKQYJkFwTi+bwuKf8Q+wbkkYeOdGEOvgR0+1KC/WQtZebhN3rCQ8pX WOqkh5S+MmsuSUXls1CQi2GQC3PmHP1/JV8qVDxEf6hrVfq3mizpWs1DsjVg9U9jwqkrEQGQftbH SfkGISHIXqy8LNy0O+NzFAgXBLMNcOSxmYIxwkkTnVYX4MheuJkA3pUwWSXyf8TIZJqZUSx+NNQg uUK2saZ5Tqxk1xbSHmk/1OGNxNs6gt5Qz8HeA97Wg7vbD3i3H9ofDIoapjYn8VO95YgTNq4bLxAb vgWNQw/wOXgK1FfRzuY1+Aex7mg5UQ2LNG/Y1iP/3X/88MARMsSyA2ymtSbjuiMSP/CZN/7ZZ91R 746Duw5t93ZGYtvavL3R0P5uUc0PN29+3+pWrwVju/Yh3haNH/QePNjdvcvbGe88cNB7qL03esB7 KBQ8uEtUH0LN+9CoOgyVRf/BBGyL9Gzf7g0dOtS5yxvcti0Y9/YGW6M93mD7wfh2UY0Prt6L/3yr e9s7O2Le/fHejqi3sy3W1urdFWvbdcjb07u/W1irW11avW6VixEdcBHdfKdtZBs+bW9v/9d/aRfU MQ7C3u1VkpnzeY1ERCUgBDjsuvD9lbMkq8oz1i9EvEyOi6TmMlTo7dx3oO+jWJT0dbXo+lhRnjFG 5Je6tVn8gcuh2O0D+/o+CDVDoIHFfujac8K7vqVFq1VKwNP1nlzjdM6Y34K57NToi8XS02HjDTWU kFa9ygv4orJmZGnV4te6Zo6T0QeFxfR5d7pZIi3IzyGnST7r8zGysMJrwAxVkhWLpUpNYnITpPFx 0nbmGri/bYSkfskWzbvIHFaoyDLRr9AXWpC1SkI8dxizBNPzYxV8syiShkBrnW6q5+jh4VODA2Tn 8Pu4hyORMEsAdeXcKi57ID4Ng11eZrmaCXNqE/IkNQp8ijJOOeYdy81fR1be5vzJyG3XFmnaF06U AC/hqd/p88ZtOyEZQNIcnQ0iyu68h3SBXIay0wt5K/dKq0FxPDYeovrPzpzPjw30H8nN2fDxOvoA TD8GYHLsHdfOQ4otFoHE7wFgWr/JeCU24S6lzkeWFF8Xv4JC2O5JgY4RgtWAhcJlA++fsSY2/Fud 1R+mVHM8fd49z1+uJvBhcwozEpG0BNMLJzMPMP/VjrjDQ+6sDg6RHvsfY7XSGJEXRU0CO307+r8Y +LJ/8AtgzHBZhu42IiFtUOOX/hfwB8KxaHTd7zsO9GyFCsD4R1QP/I7bjMprTKUM9wsSxvMdLCt9 KasyxYM+Fh8ueyMK5BsJ8OyH6nes3ipWwYKwrMvGqD8Dazpfggzcb6EGLoFEAg9fjYxAxJ3No4g0 lIBXMK6jIFzZ0og8K4yHJ8ATLvSbShJITpp2LDNRXIJ+edarN9BkvMtAsuGu7YB4Y7JBzH1g635k 6GRRHbGaP9DwMdVn6Wvq7JqkaNc+d8Z7PEQ6U7E8pPIa0s7kRRaQKk1TLwlv8epU9KvYYJ3MEcAU ASEn+KH6v43LF7MmlTHeAzyjpWtAgSis88x8+uwUqJuu0ycHoYoE7f+/sU8Osg96+oeGTp4YHIbf tLqOis0+9c6cghEwgR9XWaAHyc72bjqf6RPCOhCq4wHoYaWPGcg1I9zs5IkqhqnfrHPeiRfaWs/v 4jusvKxNULfiPcTcNn/OdFGhlmzhNT8PK9XMMme5Aoaib5BJgtdElhbcU/Ux0V/GpwrXoKT2vWyK OLhtGGci8AJwDdy8CINtaFFFlvlNu0l7AuuEFavmBoSjl4aZX1TkMm3wbfeXMcl0HCD/hQouAMMj FEKCOqzj6nLmEe07HANQYbpOtytmjhrUH9XSmHkHKTUbs8Mi5i3hAJYv2Ow+WUqONh/IaJCwEpho 6HiggcwvTOt6EmyTxp2t+7FBT0T0KiqWUkZeKadiQsYG6S39tHzhCh01aUQ0Y2WApyuZ1/P50Vcs gy/gC7SA7Y9HozFPZxq0cZPRsUmK6hWvoBDzhK7RpZn+FY5IqoPwZatrgfjchweNQulH6S0xz/Lz GeqdU69RrtOXQeFcu9J1AeaiyZLGTBA6gnAkw2UC/aGYhXkDmmigun1OlClegcKcItBIM9fkZYoi P3fSh/IAnFmTz2YeONh3aTPzF40lqEnN+Hab93IVT5WvGR1HKIyOTaO2N+OPozsV3kGsG3nTwWmc zpkzWHHM/XWN5tOh+JquaX3J5gPxkY8//hhvHeAHQWuNp6dhdIDNLucpivjCu8k/dZLZrXZszveO JJ8O2KpgLVATp4h3SFcb7G+idhjPkNP07BlqUgKQsf3U0WNHBgbxmFpVLtbhXUQCARePtv6Hvm0l fc+8tYXs7+jpaQ93NXuwby/7G6pBBLz8v0Czp3d3HeJPhwb+dNrbGvSfJso35Ojxk6eG0dFLJ5DA /DT9EMjPRQ1ZAySn/Zr5Dck2XQIA1PUKCuNKCfCEQPk7avuOr58rbAkP8Qi1M3imoGGOvipfpHqR FBatkpIErkndQkJv8bYOzyHkbYj6/M5YYksk7OfnpxjhQfsQZ4TKsIXWVVpmgUXxFDoBnnQIrO6f 7WHD3/YhzE2efNhQI7gzgFe645M+Ila03yl6V11wE90lphUxGwbMi27vclsFwhsRXUUlx5uinaHC X69vDXLIN1RWs0iRHaqbhKKsaAamFO1nucpIvSZJw3gXFVjgmZFc1YHDXb4IfSi8rCQ/+SAahidL NhSMeIm8BsUK9W9y648UAox35gxU25lXV4xlQPh5rInUI5K/WrGkHz3WjLpizlUs/Sai/zyQBAlf a+VfU5PWTIt1w/w2vUBtjuI3xt82e9iriKGm0HUK8kf19NiIZ9Xzmz3FpeLX5lT2RxbX5V+UZT0h vaNTpN80Z/A8RvsVMSXgqHkwPE+NJFbUQJYrFk/ORLMIrh+Aa+gH+oaIHykModQXgShs5gqUwhC2 wEK8qNbg8Kn+Y6Rv+NQRXj3JB8WISZvfQ/9hLNPhD4SBgvH3v/8D1a3az3mNWCvlErXu8vVqQJy/ JTVLl+h0nVmx1cdunVgtzVi0XvWmpwPqGqB/wuiWpO9zS8DXW68/g18EXjJeK4bzHNY/idif/H9v V/fcxJXl37dq/4fLy5Q82xb6sPyRl5SDnIQZG7zYk6Rqa6tW2I3RYiyXbSB5mf+FhZghgGkhy27J krqFLLX5iGwgwUDIMOMiMeDgsEvG9kCo2nPOvd1qi5aZh7mmKo7U6r59v8/vnHvO73BeOHuuEOfi cN1Fzrvovtjm/TQFgGy/hHinsmlW0b/TvlaoGL/MPnHf2O53KeOOGRM1FPRuFAlBBQFa52DisMqp GMePJkadLKDbfo4PD58QOTY5yZfIAxqOjjf3xD5HR53fsAPqKTY6fGIobtM9BkN2KT2xgbHEcXUw HmPR+Jg6AOUAoHcSgmIAav0hQnIl88ZJBOp+fkyNHT+lxk6qY2GnJhGoCU2ZeALe9Tk7pA6rsXGV SfK/ESHHXc0fJBLH+CR9j2/3/CQQr9CemEyZmisZi6TahFwEeqBr63MSGAdcr+MoI12de0YhebDx IIGQcYYHDdhchbBOI9IgVoftIaz/Of2iuFFectfE8d+Sm1K83aWqZp/pU+Xl6UVQVF0Vka+BiEhn zAhjfFucyVuziw3yIEvsB8GZ8AwVjvou6OhgzRQu97bwbMhTmjbSOHt5OnQoCsWW3GybIqaapnTa KFTqWrAbvJsi0ronNtEdOwwCJiwd3Yhw677evr4OngBG+huFltbZ/zH8t39fJ+HIyFv86Y3dgaXU im+f2O2fxEGEedfDG5nTjOUBUoQe0OJG1Mx4DUrKzM9mSAd3m3AbJCUwTFi+1Xx2/oFVZGlQV8/P XkYr3AY3PiZXkiv6JDMuan+1Fo3zwnipT3qmMsJkgPdSBZ6yi9vPJXVesH5IUesjVmJxWoEdKWvN cCnQ19nLU9EjePVmo4db6GzevLnA8wfT5tI1eGIgRonUQT1XDiRGhuMjKp3O8Fs8dynSvXJZP4wu 5s5j6UyhAtgY7fRtOI/JladwZTaTXIFJjZzIMy89C7KnRFBLUX5Gvgq008l186ZD722cnr5PSl5l af40JaST05UixB43g11RrUSQ/e/7kt9o3zPNyqWyVUdIvPuf5yCj/xcsE+RJzaC7PCin67AUNPQH K54FZVmrcj8wWKxruawJesNGcbORnRNThqWfUi5I7Ubxb6Bk06GD6wA4fc0ZQ0lySXADmK9BLjmH RiCQfHTawqYfaqf5NkBK3Z5/rJuSOuiooPixhdfppyBZ51aTK8YZlroOGBy0qVuS0aqgIdC2imd5 YkG7XaR6+rTndJTh7Jc3i7ffb5ItAgRjQW9f7/59Xbsz/1s89k1Jr3KkbjfsghF/iPUeOijpVcLw qU6AvsZ31n2xsbHYWIwO+WVjKEFmkC+llvUZ1hJln3WTxU36YHI5BHu1TQJkk4t3SH+3oD7QZwqP SPQWXmC+ikoOaZ1kv1pYOlVHN/9wTFWPxkYGG/jBCUfMiIdT6fjekffYhx9/iu5wmIs80NzSFmpr b25v72iRxAYvaBa4gcNcxOSylSmEazhwjevfEpGYFEWwMnz4GTukxoaPC5PGOM/pjv66dnL3oD8C P0JXx4YTI6pX/hGkatJfpP+kpxXXzFRY8kJGU1jm1WwGrj/UnphVMreYlpcgzJdBNmztYXoln1Vw jilo80XvUPNm9pnCs3ZxFzcFOm8VuvCxVzl48E2uckxD2yPUa5WFo84uz/OjlWYvJ5fNqpOIzKug GYuSK5dy250i8HZJMlgwWIgEZYJ+KOzvcMFbSS/eFsfjOU138HreIflqcSb5PZu+nnxsPRIJsYuT sHsALni0Q5IzDhsAM6ySYRiWwJ63A+Sk9EP47X5wzJVEmriT5rhTP5DrKXoRItrPElZP6pRphywW vEhC4NwfYWne87BdeFRtCzblRwPQuUnd/MZazJXRD+uGRB+C1pC7l2BxLFWmhN23sYN/JBB+eyu2 XeL1K+a5zIYCyzKTv1jz+wpPr233jHWDYA9V9HpWNx8ABp++PwtAE/PvPqcU7ujFVpSadktwmaS+ 0l8w80s8/YUl0/LOQAHWEmzYK5hb3ilLmKfwfxugby/SzjTzOp+dTcpWDARvCl8MIkXVet1akPNm QabCxQDjcqAOZHl2aqudS8zDew6ES21+gd71mvJbhqPlrfIMS56tzNMLRJDG3N9m72ieboXoLwhr t7YrManp+ATdSzjaB9j6MxAJQQXQmJ1JptYRO+xAANjQ/43ODGiZkiAEzTKD6R9xc4b2QMFwE9oA FjyV1YUzC5fF1uK3K6BPsis3SmeNdfe2bUcByuoPcUIsNo638lk32IAxFwf1GWblE+H7bm9Uv7Pb cJhCYTWSWtDqUl9Urr/0xuIjmHCmtT65K28C59fHESfafZ6CENpT1jH3sHEaMRchlNStwrp2Jv3c 7x0sYGSKk+hAT4nOnRyUCDcseFh41c8JaZIvJeVFEAgGnspmceotv3op7yOYw3ey/cdjQ2rfxBfD 0OEu56FQa5tE56GIB77oBJXmsEru88eYuZRcKVxBc970NQUzDsv257ITSV8GPEL+wwCegxF0ucuX 9KnCS9gOyIXAcPn+boc7ku0lggWoczgeGwcQGmFHQCU50L+DU7uzYFLrM7Ybpn8Pw0zk5WVcJAZl Q94opdHlgGyo4ahQXxrmoXMp3LVkyKxwA/oIREotAXLvPijdTmQsqUcCwntBPcUouyLrSQyqw/GR IdaXODE2AJpbVM6bBYeR683bHdh9wgHRWwBFxaE5ijDRSR+piaGx2OjRLxRmLWtbCqb8vbqpIN0T KZWe46FZpb/shUHQFCIk3juf0i+Xv4YvP5d+nP27wnLJzAPQN38q3t2bzM6t7kVmOc+CQERpGLyH fwvr+Ognew8Za4x1J04xdvDwf6sDEwqGOW6WNo01eJ9XIT0JYXsaRaUZtM5gByWLpBiGx8Slov0P m79QXtae61NZzTveJ/XV9PnCOmyDHNkDboWHwlc3jS2hBqafwkpMLgMafK1/yUL4i1c5V3+FR3Fz 9w3Fj1Q29RtNLv4amBegJaCw154DJE4u8zd45gIlv248VFifuYJkMKsgERwXH8o3bVat2+5Dn3pZ gz4zvuxj7kGCDrrkZc6K9yl6CeROdin9FOqTL5fmMvdntqgMSfuuIMQSO//IoDoeHxrxmVVOet70 DuyAkdTZZxRoQUnuMeYKA9IEZ3p5C/oYDwSsxcz3oHbgyvceZdtbAJq/Bj1SfA1D/spVDoAqEOfn Z6voalCo4Bu9inHUJBv/QFnpByi0oTsxDOFR/pr53R4pBEuC6osiM2CKayAuwu9G5ByVtzRC5XZo txPYzeQ6GAoWMWRHgrmds0L+IPN1J4YSYjW/a0JQMF84Ss+7BAO5829TU1FFgC6LyLPiCYKy7vjQ 0QnWNxAbVWE8QtKRlOApy0+aN9M/oHntPRvUwGcOJMpbXl1HGYitJWOL2+HgmdlqeoFx8YuuPU53 0rIyq8kVT11/5heWmSpO0i1oG8vOcasKBZrBMsj+WtzSvsZrWzVOLik9wSHdoaPxkQQ2Hg8fKKxK VMtTC02Jc+ElHnuOjA1QZ9dJNjUH9SnA3yt4euYZGisUMdxZsWD0IhSbvTjSlYbcBZnbodgX3EkO Wx7xBxrHGvYdQATQHAkEmzHmo7WlOdjWFoh4WpNvzuqYOjgJf8JRw8w+K57jEuRNLuuKU0quv1+7 tyFwg1+dYGr9ulVFOcbLmDZT82iDe5+fR5K1iD6hztegNNj4F5M6v41irsNRyeYXQWjnSkmDBwbv 2SFEMOVrQXsyA1FqFeLw84MxdCKFYW/xB3bFa0nQtdFO92nspArzrVUSeUC43VGKWE0ramGtLdzk gktL0pvb7PxzIOF3RScWLGpCFz0yoY51HTkCwHecO0y1djgt5iQ0kmoRqTGMsH2JxDBMrNButN5m 8nYbUVhv5/4D/V2HyMj5qXpYHYwTxpdeGS5K/tDd1RllPXjKKTQmTEMaamziElb0GiOJ0K4qlxc2 mf6LVUX/ZjuD+u2Zc45jicc2R64mFE3NVX3C/66YTu41zalfCusC1nuUYy2iF/iWtag/tQNHsCZ8 991irvhIKT0Z2mazns2Yd0Rs527YrQVP2jbbXhRJ0my3cekVaOAk0NEu/dWhms0++wz5z2uEK6gz IFW+r/fjg/0HWeeh/iYWLL5RQjVq1oYxSdu5oKxvc1mARYKHNbtEhlwRA69fAfldevRHSeJYELh5 tY9I33G31O7SD97O0RHRPt6amlhH5RLVCvtoWmG8GIUIZjn1Cz/MxhMtuDu1PvPSWK91FWjkP1Ru 0cLfViq/j56yVuZe7mFQA7h85cbVv9NsICCe+sow3fuB6yFYsrqeOiPZFCxI6rz6tScGQgnZGJHW Bua2CD0BYcw+B80+oLBgaw+bh36DZv2ut+sjF3MvRp+TOaV0C/Z6NMxYy/r/+pB/uPhK+5OS+ipz gZt18iX9L8jEm/w+d8fvb+Lee45ZBt8Kmj+eGxB/FeDR60xgA2FL324HwWRnxhrTy1YVq62wWtBI 7VotwoZl7uHUVZzQcnhWXKLiMPKgcsUmznJu5vnanSNS+7p9n/ldYRNj9cXlns7PeGl0pN13NDGq gKwdU4cBw8dOKWy/iLyJo9dHeh2mFAaUZH41zwECyFywbk2vzbxk1j0QA9qrwgsR6wQI9Lauly8B HpbKniHYA71mCLWnFpSUzfta2psU47x+jj5op805/uGh8TN9QJufL9QCVyz40BZpUjBHEeYU94VD TbyTkrp+zlqcLvmCrU3KlWu+tg64/ZW5SHfwkfeF4CO3z1Fpc88Km3Rf4ZH2Iz5HBWUupH/wtQTg zgfGRXoZ9/ekR5I/UnmZ+9P36Tu3NtI1c7G04hSSzjBztfiK7sG6mr+W13xtbU00g6mK2hNtHZ+T 1PuRd/R+0O79/6DtPdgcCP6nLxQJNDHKiK3k4I9v+kKTUtmqbCrYsTAus9XchmgyMx66Hg81B0L2 4/3xYfV4YlDFVCvUUUplPp2GIVHy5WyVOnP7w+HmQNh+2Lw/t5r8WsGhTT9VrHvZy0puqrCqZKq5 O6l186aiPYcllwfFe1sRLc2BFqcI+PXqJiwgWG7L+lRhnWYNDDZvBRQ7/Wd9BmqE45LbyFxcuESF /TOHwaFRF7SK+zprHk0wBPsANffExvHwcBf8AAUdYl0dOscGjg5APXbDC1IQEtbV4OAYXujwB3ch vsRm4+vscdcAjyaYPU1yXza0hTo451//xUfeO/SRBf0gfrRLzaV08Wzl//SnsNHiiQhyztTe8m90 DysWrG/xdeYDc/W/KDY05GdzPxs/wUJ7wpqpJukX5WVzEZ6ASZ5Nfsd8hll+TGk4gyGSZZzghs5r wn5WmjN+4tTzzYDT5kEqTT80z+Vy02vI3YcVsrO5dp6YSOCcGwS5gedOg7GJGDsC65Q3KbStSdmp uWfUJGpMdsm67TRGoR+Lk5aGASw/5i7xZnR/tHDJWmrOThU3fgMLHlroim/hIIXfgkysbakVhiUA TjFvElMcPmd8zfiTIMWLd8slbUs7g4SQbO5lYROkGn5H5MNLy1vFSXhC08wsmzZTk9x13xVSs5hO zy6C6CvedZlbeK+Zi/lycUZ/3szwr/aKCN7SC/QNQ6kzb3Dve5J5w7SU8RjZ+XLaE/NybgMRH4wS nj4lU7NT4nQpuwRbIujbxhYgQNgg0+sK1Pnq6YwGw3e6slou4JGUVS2fRwRhWTMvM98obDprADp5 YF52CIiM8/ny3EtCjQiO38y9gZ7hYguRcvopQDmoLLbFfJKz+MiKOrhSjOJ11sxyWXRGAoGUNRVm rGH0mraFVcS5aGTy8+YPCjaYGRdLK+ytUgC6aSmY3Mupa7ZbI9HgYUg59DTiDIIVZFLLbaXTnKyJ 3ykOlwXM0jNm3m/dg6alAZW0RQK/bQ0EfgsIkLDZHb8kq5fgrqzf82AdDKrjxwAElbXyPaT//BLW z/lygfT1cGuk57B8Lo4Or6qhzaBrZCg+ooJQQGgUl1+Rdk/Z1Nm/v3NXogwFH2X9GP2h/yBe6u48 EGXRrk+6ug/29nQd6IfPfb/vP9grv1qtO06dHnXg6Eh8APSbKHydSIyS4a3Ow0FKvSINoMQx9QtX KOo7ZZiUunnCHHKNtWXPDlzSkusW3nE89yWOjw6rEyr7aH8f6zsRh0/1dWsclgz/BgaDsOFicQOE 6kZZuN4fbNvdIdfd3RgQEVVPqsOJ0ePqyIQ9pXZ4PCwe53WPn4zTPIwPqSN4lBWSRQW8Yxf++4n4 wDGBJWURDXpVIHdXnwK1/VyxnkSJRSISz3CDgR0qs5nP0mJ0V8Y+SZdRGU9hUgcHAXcsJVPptP5U ERgTgQx+l5GeshaD6ynnOqN9rDdxCqRc774PWKiO71RGPdq8u0ifymcJXLftRBFsR6mc72gn9G0+ YLkUwD0ihLmpnwMYixEBnJEAfpDk1O3VBFr3I3RVuiemN1LoQR6aY+O7ocS2NKhBOBLYFcLe8DtB 28nQLijSXrXYPzKhDg/HSZluZ0fGEsfZJ/HxXTi38NyUcUmhoRQjkNA4jnlppdXj/wFQSwMEFAAC AAgAD3eKKvmvwwKmnAAAfrYBAAwAAABNUDMguPDAvS50eHS8Wv9TE+e6/90Z/4e305mKc5os2YQY 7txzZqhQpCLxktge6nSYtMSaIxIvQnv9Jf8Loli/EDckIbubTXaXfNmcFkMVq4JWW4+IrULxcBpo 1TP3ed7dzW7Aub9cLAwk+7yfffd53vf5/u7bhFtJ3CfcZq6QXuN5JUuyy/JT7Y40SdQJ5a52h6SX +GRqLrWwe9fbRFlKLROelzeVm0hyIk29JcS1uZw2fSE1Q4Tv00u5AhE2K+OZqj50R72VK3ArhF9V lpSqWkunSf6bjKrekiT50e5du3eRifGJsf/37zmc6Gz5qshJkjKXeMiNqw90Lsmf//wXol0XNuUx 0gI8oIi5Av8TkSbF5zmRuCjNFHPiLE40sQMcnYeJCP41/LxG2HPbQWfJocPEQdyE8PGcWI4TytYW 0MTrHom/b1s/MI/DTeRH+R9InYYQbkx+RMh/wLokBFLZKMff5Ve4VSLVMnNOp9Pxf/30+J3ERWKE uL3CJsHJyt9Id3EyuZBeKn9DZIWPq7Vkldin1J6Jz/n7pey7ZPpfpP4IUp+MdQmbOJcyJ2ZxLvop j6Xm+PvKrKSBLqkTMJvTSZJP+XhxETaxeFmZJcpLblV/hLVAH7f1ttsGnOSvjg/aDrf1wNd3yWtl svhoBZkIIfpC7t7l2NGf3buOwoa4+TUlp74idA/oIn5CnydXc6KLUa7mZtQ7lY30ck4sPeLjjDp9 uN3NgL3EXczMRmUcP4tq4Z98fEqekt3OFqa8odYkrYXZvUurlq5UNowbO3r62kCJ2kh76Az5KDJy PDo6QnpDkSGmi3RHvwiTvugoYdVXf4SULXUpxWqF28eIz8tx7rtcqsQrVft3HJhSV4m8yUh3FVGZ dTG5kiTKz7xM/kcXSPhY+5pzKrPCrHxFSnCr6iumzdPPkj9CBk9dhqP+0yOf8PfTa8WClC9dY9jm ZhdJPQUnU00ITILXNA+TeKIsVcpe+FSntevu3buSz7I1tZZ62sKk16Y1FyMsCrPc4xb41F5xj1n4 rMi5EnyulS72vxc+PfJHyOSmMlGhdMVrYcDcbkyvexhlXlkWXvYfiJweiQ6f6Y8e69cpjHY99VSq +ZjiSoljd+/q+JhtDw19Fh7uDw0N9OPV3/oDHf3+QJDpjA64mUNtf93HdA6HPguzDAkcIsHol0OE Zfq6ug6yf4SILIqIAuo7QrygM4knwkup1s/Sr1IiX+53qa/6Xa3sQbwW1VdwyeAdWk0952pmmw9F /oepbyCMpdeEBeKBL8JPak1OB06FP4uEBo+6/sR+wmR/LY4neFJMZq4z2X+XLk6v69/zld27suvG Y9HYCVj7bG6mUu5377gVktcthctcCm5Sq0k1lpFuJIsskwchK5PECyqontNqbvBBfDy7rix6DG/U NjjYHzweGulvAk1v3gsro8wXzqrn9jGKCOJvgkNalB+VbhM309nVGWBxz537mD72IGx0sPOo65Od k+51cjWbcqnTksivuXV2ZtCI+nHneno7kfHurg87+vf7e/Z39AYZMGFuTMmm5cok/f545kX5KreZ esqA5grf5x+AlPAtV5B/y99ChLrAx+ULipacUhYRQ3p72kA41xsVjW2tb1kycbt4T5osxxnuubCG nrE4VprSnqWXXIymaYXSxcwyy2AEcAPrB5x+Z7CF0W5AsHzlZgYHT4C2+R0sOMs3y7DPZFhYlOcS N0HHJoV4SWAZ+aL2Q04s/r045gO1Fxazy/3gQn/i4y6Hl1GW0jKnvWHW9pmsSZOlGRXVXwSnXYMQ I5YfgSWKpA0CraFC5Tz8FpVZ8Wf4XiwX8w9cTPmb4j30a9pc8pL4HMOR9o/UXPlb4Vs+zjIH/EEi pyuTiMCVBt0PfOxigh8cPqosab++WRtgvZab4x5XxlvQx1XVvNff0/En+GOmFLWGnCWfCgvSjdS3 LJNO83H8czHpKh/PVzAE8SvoFsAP1JSEh8FN1ObkRyiryOfLLgayPjCu5KWWNytMiykM8FX2QIoD 2vEVch/oCNDUENQpXQIXCuEqIX2nzYFGUQVicMMUjfBr6WXCXWMKtwpnhSoaRLEAaXT2l8L17LKH gfxouvQIJyw9VebAC/7ABIOH2limcpl7rFTfsE17TOk88m/AqzKbf5B4yLS390ZPj9Q51lM8gjke rDm4UpoR52YTd2Fn5U31jo8yqwtn7Bh5DyQyl0p8XkgLl/GbvlSlK5lUC80mCTpCgh4RLlE13W9W Xrcpb64EYQZM7EKJ41ZETskJ3wObKlgYt1IZxyRIj7huRojPbChz6Np0yUD/xkUB4tEsRiiWQRvG yMMyuR9LVyCELZeLoMdrULTOpmoYoTM/T6/vo1F8Z0U7CCk1a+QUOzfzgbbe7o7/irWYJcyB0PBg +L9HI0PwtD2tXiI+z67v3nWQhUQhtq9eAh5kCc0cAgf7IGGJtZr0wIkzxIUDiSeJczGXq34DXgtV HGsiai3By2PSpDxDyitqjexFuLoZc7ltcHVTO0/h8qR8DxDppUwm5qqzSfC6dJlA6j7LlRBIjpK+ cGiYRI+R4PEwCUY+Dw/jUok5+WLMZbEu5oh8kb9AMAYT7p78Cwj6XgdEVf/7JHigg35vAlvM5TV4 LCqJK+aqC4jXuoSYoMRYS0I9YSF6pCT5BeElZgXcyxhriYXX8jPSHYEaaE/rPhPQshVgZHWktZWE ByIjkejQ7l2YzsVYSw68Vm6T5LzOzhvQNddO65oeGOq6pl9iWmwmvHUN0y91HdPdSl3H8JJEsUhB o7PpmG6DhBqh4b9RpeCKYDcjXybgz3EI/ZNNlXR3RWekQddSFrzUecCs06YFehKqc44PZS1FoDzQ 2hb9qG3zrcpZn7K4BsxYe19cI5S5slSWbNuMl/z0zhbLti1u1quwtt7gu2R/t7/nXT2GE/meE/sa O/fENo9DfhrzEnTRVDD5qTSp3VEXMmNOIAGg+6O2vgCxADrBGOwNOmKuZmsw/4M0r93RB5FvGGXr g0gA4d4fHQJvFIwORT4/PtIA9WyFpoV8Wb7WgPFuxWSXp19wv2Oedd4A+v3dAPRZQCAAMHkJQquw kDnvPHmqDmObt8KEWZWzT8SyWxG5r7knTfiPX9mrI9t7O9oOEdsiUYI+1vFhh2N/jLX4BgJMsj96 Mkz8QxamI8b6tmA6vgg3tUeH9oyQQOgM6YxGBz49EzYeCbmlI+a2LT3N7+GmfBnTB13Gg6wjcTvm tiSA+OAgidvJH2Ap5CtKVR7jbjbp3SHSZcwMNylXY25P401YASqaJNbRXXV8VyBA7MIjQR/q9oMc 9iEkWEOurUMufazH/9E7PTGPxTYQyDukp+MjYART7bSWXzWgvZ2OmMdjTdPj7HV2Aoy/nyspv+vL gLk3oKwtoMk4gv4FpTj+0yczcL5tOGVRudqUXlRf5Vf32qEtzdugBQEV0gCxvY6uWIslBxAA0kUO DkW/xGabBYu12GTQYTP/1Id7/f49vbEWi3tKwEYetyL81IDxbcckHqbTdoy3eTvmUPSLyNDnOirQ 0XHEEfNaPAfC4SOAof3BADZ+TFzA8V7Ma2lJwNnhDGDMDg9GwoCFTAXv0XcA0d0xr3cbujsyMjIY Ju9FhgcsZF/M69uG7Bs9GY6Sg6HToaHwiG3a2D6bEZjgSz9e4i79fOnspYkfJ66N6xwH/X0AZi0w EAAqX1ReVjbAbPgLqQV5Va0ZaMj+AW7JF3QGnYfoap0h74U+NZYB0nBA2fwntjgcELsyBZ1FHeDb CtCe5VfVTVIpyoaf7evo7vbHfNbuUIKp8Aam8/22QzGftTd9zk4nkLq6qSDP+HhqRqeFTkYGDQ4x kY75bNqlZ9aoqkklB77i9/yq/EjHYqPSEfNZ24QEVLSbyjw6z1fFsw1A31ZgakF5kP474UrggXSg Bglkq22HkCBvAvRA6NSpM7jxI8cHQhgPLIPAYBdrte2UEf1wXdVzTfcv/XJ7rx3peQ2S7ucj7iaN D9ocLEzyagJ2tynxvVpLVyiZbZjF+5pZeqOfndgzBB+DgyY0LcdafXZoWs68xLjxJKPaMK7m5q2Y dwh2UhWRWqXywgQLVQCzNjDNvlBWebPp+7WfC3sbkJ7tSGlTqpmY7DpgbBsIBMjvHeTI0EhkUFdJ SOLzALJtHhCkSYxsmnzFnAgxrubtmG7qLOybpdUAaRdAq0koZC6nzRDxKr/SAPRsBypX1W8aMN4G DGR0kApoNBmYweSPawD7toNzWmZZvmBHsc3bUejVpUR+rQHXKEdhGg3rSv6WjklWlTuAsURIVoly R8lKNaLc4m7qy4v9FABZMpgNFlMrwcsQScoaQceA+14HL83kl8Hukpem6+B8GZLnZhsY8mewu8sC h7G8AcVuRaHOQ3El8sksv6xDU7+mfgWoJRESMEaN7Dlt7TE2twFliUS73RiA+HgDwrcVkVKmeFF9 Swdllvl5yPIs7pGQo6oilp7oGGEx8RAwFu9IkNOUez6DTijeAPRsB+YKyl0Tg+ZgC/xIoOYgXAbw RfBXuQKeBJtwRQS4zwZXxFzJVGUa2OkWY1scKpVmGxC7EJhR/KY+UKpNC/PPf3p2fa85LUWz29G0 zNZuTE2ZDhgPDwBqE4qeJqCNJ0pGRBHHlVnAWEIhQXwuCnQlD0YGB8PDBrKa+kdD+oUEY2gls5w+ DyVRfcggGMNQTkOubbFM62vwWxMzv+fLDRjPVkzqYoIX+dQCGgd1vkY9kF1WwXhsOQAS0LzSsrH+ aBTYgKgjTIL+QDybgCLQWnUkoKPklVlYx/zXyUuwjjr0Owl2cp/FPxIqaAMmU3Ow/0boxWYvgC1B zO4vRntJlDb0OVEHAGbxT5VCSgicMV4wasP6uLFhuZJIE21rwCCYwxqsiy2qI4E6ntQcN0bUzZnz mSqRNzGIwST8vBlbsXkGN9r4xm6aAzIVv/NwU/DLyNCJQXTV/mPkcGg4NBA5bRYPxp3erXf2Rd9q ymtpWeS5FWnSBENQaJQLowRlPX8rU2gYQoIx9CAFDqHVkgoJ6HRnhVm6claajK06gFpyIAHPqfcM DESiDRjvVgzWMvkK9ZEGENsVrlbLho2zLIctz6cY1hag65j3w6dHIl+EjGCPbVLAWTJYfVN0fiX1 33zWQArcVw0LgQR9IeRrW9QCClp9YBNcL2sLw0gQaukltIl88ioskKF5RkvL4tfoaYFMJXWDKNXS NV1hG+DsdjjV2OIFwQjyBtCzHShPqucaMN7tmMDx0RFy5JTxzATkC6wtFiOBuk7hifyrMdVs4i6U 0zYxgKCfqODSR4bDJk5MAc7GPxA0WBaMcsbjZsG+WVsgRgJ17LrHIfy0WuMzqB4066vfdQPu8trv ugEVIBQtg6NhbJKaDFCcrwFH8za3eovn4RmJa/lVUbWj3c3b0cpdM1XBU13A2EXKzejJhQI7mPw6 O69UQYf5iQa8pwFfuUoVPvUUkll+jf+KvnFlh3u3wyWJcGPgHKUbppNVZpUXgLULp7zAVDcUGTKX CYIQ67ELpNao88yvqRPT62ZBqcxqiLMLpeHbXBDXNrVkA8bTgJGfYRkVOX26IZFUZivPAWoXovJc xVIhdY++rgVWbjkNpbrFKyHB4B98e4y1RWckyILI0+o0NDoSOTY6SDojw4aZK/OoTLb4jAS6gYYW 0dRenxr7jawtPhsdR6M+bjt2LBQZNmelUO92qLAwvcH9TrSbU1Mo0Lpaq+/jPK6WrYxHgnGPyOMB vB1nK+XrOHv7QT2nLAPKkgsJ8gru4yofl+IgIk2mqWQG2NMA1rCwSWbzFXkMlBnwufGGqb3b0QUp aeQy6oUcLKutkkdCiaNZCna/Pg19dsJ49rQjxtrLeHWaPhein3JLyU5NGRNOH24HnE0ePLqC0iCT L+OfORlFebaiMK6Z6Q0e6QLGxj494zU9JPYSc8UGqG87NLteSBqYWupijLXV7kiQNJrAJ7QPDe51 ELsddCD6JWkPh0+RCE25h/W+iXFTGVymLcQjwVybemWLQTA1o99ROIexzRbakZCv0JQXfDrlt5BO goHYqnckKJqV3xZuQanJtloCIUGq6etTxPOZcXVDu44cbKSNFhQeU8I9rO0ePLe0+o3pRXkMmNVu Z9fNvQW9p8/DF/fgXktMJOBrjk3+QHAvNUQlp/CQBiVu0yYHLZ/0W2k335YY2Pr5DjDykyfDbxkf xg2FchxusIRHQjnOx7UCtQwpiRpwDt8EhdCdfTazBk9PZ2j32FoheurjtqUQ+rFPch6Zzabu83HT ViFbEABprQsSZAWZi0YHSDBy0tjrEqREALQWAQnKIgArfO7vnJGsYqAHlCUvElTcmvZwyHA9+PIH YCwRzbdBjC4RyIXOxwBXS1dibltygQQAfhSKjKB/fj86TH00FdsAs1vBjdWDgfJsRWGmr2vNi4Zn e7cClUUVRDYw18GNuG2ZBRKEn2maVBlPPAQcfSiefcfctuxCPwynxkKSU+C8jPJXuWBWJJVJXEtb ooGEchzft6PnBaBouVLiIVSpE1Bk5G+Y6mrc53n9fXrRQvKbKXvJuPOHRK7WnT4H7PS3s+or4xyw E5STHm99cKS9r63HOAL8YHTgDGkbGiCHQsNnsAFLz/8C/b315utR0tvRtv8A8R8JInd6z9I4Dezr JHprkuivM+otLXfDsSOOkLbBT0dPwlR4YvwpEqLHyInISXIyMkT+FgWt/ERvXTSZ54X0YgTQ8LdX P3mlJmqeGdZPZZv2D59Bte4ZHdlLdAH1t2XNgz168Ub2y7fT+4XvFr1jvSLwn+1dvX8xL3AMz8oJ 8w5JL02v89PoonMlfAHD2MsGPI7RtzPoi8evuVn7JVNVLhLxf2m7tucmjqz/ThX/w9mXRK5vsdHo Zu3LV2N5bCtIGpckA/pcrlSSYnezlYRULlu7L/k79tWBwAcsICPZHt1HyJYUYkMCgUAukCUQwnIJ JME4JKT2nO65q614q+JNLTXu8+tWX850nz63OcDcz4cM405SVUfpj0w8qabgGRiX0zA2lYJdSoKK 5XgaMlOTk4kc/ZWNZ+VUPAZD5O89OPj77dv2xFPJSWlnFJS9ZCjCK+urr+Ofg/v+to93l1kXJ7JJ Zw+BfEkG//zWq69syTJZTmH+t/7+91fJsyS2f/8rz5M39V/oL9PjCGWe2hJwv1Aqu3vv8+vM32b7 tsLRymdAPp/zt4e4i8TyMe4RQQ1wnQ494b1zrTpHbmPcl9B+Iio/KIynD4G8r5ZXy1poSzxY/Ja7 WGN26dPgkOkVEB4idQH5pEaG+NWg2yYqFz4oZGOQnJRIO3P6x+4lIqGUp+FpM9tpIqOobEIMoUka DLFGqjh+P3/Cm5LEG75UuMPL2CUC2Qr5aJflWUr9aK7XOvzHtmD8IYe7XAf7Gja8581O82tvkD22 DvL+lz6d+7hxjp5S6XFyu6p3mYQdMFgiYLFG0GzN4YcyxHZckNjImpfYg+E2S4/cNWLI2p+CWzNu y/csjOL88ifLRwp3hizX6KD9GGIr2279Lxs3cy6jgZO3FXuod5dmuyfDrELr3cUlVmjcpGgeuEsh K+2cIxYAPoPk885+x1Zjsok4tvD9NDLPzNaM2vJAI207MHW735xz6i3TZUoWx0+PDGYGWV+Ypsx4 d0lnRNPC7lXzrAFDuKNHeo/sekzLwRvErYPoXGhgQ08msmkbugXDtVzeyT0VuH8q6wSp6acb8zN+ 59C0B4U7OJACQ+A1pYzcJ9nvQMDckeiBGf7ogTnY+DnDT9+9N6OdKK3Wyvbf5KjIOaZc4BNEelvm 874lQ/bbbseMWQPcefWpsVCGYp09ktwWYhw4WC65l796vnugeIcvOGkcA+6Vb9zJz2onplXHKpOm iu9jTMPD9hHjer5FI91p71wUWeLtt63NZqMgNax/yDUtpnc/X8fDy3nGlOS9zM6cIxRytqwN8bs1 36+M/XyIy+dMHKc/KIaDtZ4bdzDZbz9mywl+8cdaq7HOfrv878WzBjsta5VfkM/ZXnMZ+XP5Uf7j 4iN7mVpVdif2G8OdloYCQ9EoOcEyz+9ql0D/uMqapSMXSh8ulorn6mtQvMd4mnudsgaMay7rwcP5 Bw39D4yNdowrWZiaBOu12TEdG5th+lqczE8ohG0rJsZytm+so8BxgfUwf7yKcgZEzQU03uojxlu9 9IAc8Ia4TwsjkmNEkM+Af8j0H2fYuW86T7VTELGkGsvR09hL+AtivimGyiu0FSNlYprD9hVoPv09 lG7rtzpr7JHzKj3Ndarn8bxuPv3t3eemR+SR3G51L7kOzsBOP8RT2bTKb5cemgScI4TEACTjmUw8 NQ45dUqICMKueCKhpIXEEJx6v3SsuALlh8v54jkhJmyoxk1To4ccgaSc2SUkDUPnXLFlaCxd93cP MIqyfjKpoMifVdM5EQSl+cYPtr+Jh+hnTmAgp0ZBiWWyckbchjmTvmTaMFFNk9cSieJsDZoHtYq+ Yk2DgybxH3B2z0ENMJGdGSDJN470Tb2gIEwmFDkzlVZ6aSFSGF8qa3PXe2lhGFPTym6cnLF0XEmN 9iIiXLm20jgC9W7h1ju/64UMC9jEQY5CaaWxxv7pIeLM22MHx9Txt4N5ascG1cHYIJtD9uiLTajx mEIe2LF4alRJK4mEPLAjrSTje/vUxvXBW+FIDm+HOfdoRegAJJ5N4ntjrP24HE/1QQehuVb53vfd u9fqA2yl8rP6Ta61Jd/TPjVDUL+/cAoaH7YeN2Yh/zMy8vxZZhtpXat/26diGOgM4UdIH1gU2icW by2e1Tq18sYwWoakPB5PKX0wfhwLdk97UNP7oKR+i2TUM4Vu480oVIAbS8+I6BLEcSUyWdxnaDHc bOZCBrgfrYAShNaZ4h0RJYS/ij996mr1AtPk+jIxOQsZNTUu7GyYWbqgftFh23UjIsLugi+eymTT U0kllZUTwqaH8RzQbosoUZi7XryinaLfnBUAcPVcgxBB/Bt0y37jeBwcW0xSvDfX6peMs2NMSafU vijJ0NU7N2ExMuB8IcSQILBeZlUWYJHGN29E3dO3hrGIZIjVK1yLX64Cc3+an18817cuHkCPFs82 7jO+dsyeGB2Bwqn85811KJw0LQwbIIfhu8tfPe0LiTJfr34QXFk5Na4k+mL8oKZI5ZVWIGsdIGKo ZPpunbpq4phoYgkK8ijuAiq5dzYXP1o8O/eJGOaUJ1wkiRvkHO+hixwwdvv4eEpOiAHMo0hACeJL mU7bjOCm5WdLa6ajo5sWgpG0uktJiWnM9UhACTNmElO6S6bjnZsSYX33MXf8jJwckfFY3DsgRjaO 6J8il1KMrnYIFvKFkwuHRchhGElMMX1mSkwuHNXPEaeXPjP9htyIKBuiL4P7TpxvPhBLTI0AnZYD 4gq1bvORgIK8OKLE5KmMIiYWUD75luVNsV1a3Bg/DkZhgoKIKjEPfTpy6bUfldO7BKh6u3Qsvzo/ Tz/RuCEZCC7ZG7zZ43vjJEsgPzsKo3G1lxSAGw+/Xvji4tWjvvolFN/Plx8O9KKC0NCLLU3rpeAm dLTyWefx8p1eWhja3zVO95ZHrOg2cn+sAR6vrYVe2DBoF6D0Af+3lxw1DqU23gWf4EFxm9TYXhSt 0NHyQ5yX8sPOl71kPzRuVJ/k15smb+srpRPV6gxKS46wEas0P7t4trqGv9uqtxex/9bJZQN0FHcb ei/h88a3eqe0Uj3vIcwd7B4vnWj807Qp2oTTpSv6ireQmW8bP+i16nntROVCD9k6751F5MtS1nr6 RKTGKhkCu4+9pHt6ufSVXimcrLerxz1Eaxs1CwrHDV9Eb3G93XysPdAO6F/U29Y9wyJXyJKMh3en cMb0tXEQG/riARquh1AqkU1PX1l4ZDpq2KSv9BXtAt69TucfN7zTWb6glwt39IqnmNkhV5prhaP5 2Z4JotBjb9ElPDZLp3/0FJPQK1jcWks7pB/ufFRreQiNukNmMAvJAYSHG/cQaMxQuVtv52eLVwRL qd8sHNfPNq+gyKvVP6ifN0NyLEBzobnQOa+f9RSfPnT6kL5SWy5d8xDaSws/VR55Cjvn8TJX6Zxr rmnrnWtN72iRkY95iy5hQyZzMS0A7nR4m0yPqknAC1gmrqZAGtzpOF95bNjC9/oFvPmhcHJzU7Ul 06dkM+AAjNHtb1PYIAo9oF+u35c2BaebjfYexX1tCh4mI92okiIEXtCScet61r9eBJaOVW6RvnxT cJSyZzt4bZm/6d8UPmr78WwCTpssn6NNtY6b7lhCTiqbwkowqo7TXrcpdACkKZhMyDkZJuSs/H+b qhSEzs/6TRbqX6ttqkbImn1IJ83bt6l7NA7kZBzr7lJERAmKt1qLIkrA4Z9zwOWdQ0ecqEYQRTby Afp/a6lc5BD3W2bHrGPHcWEisMcSMF2EYZRH8H4sHEMUtHlBObIC/QxzOW82USYmLY6Ba+u+LB6p A0D/0iKBv0esFmNQvl7Jr5o+nhuAAuxPtvq+ZhNPHvz/QN8aQSg96Qugl3n+Ad6P87OWWCVGRpCr /X0RwyzAoC8kipeWuZIZUyEG4QS3ri380BeCzIcCp71wnbXaaZ5XgM038mVORJGQZ2MTSiKhgK/x T2TC5U+0hQERMuCMqXWTcLtctRj3VmMWfKVj3X/1aywErTPabd8P65d/FtLDEJNTozkYj6cTInrE 1MOJiMO0q9qBrm4i0zDcEVCYaoHyLYpodPGEZ8C6mriIEp8Z8DG9nGg8uEfRAvRBmM+DL776Omn5 KZ0IubjPzt1np4pkWb12mAoeyWH6ofCUytPixwYSrw7z8/Vu6RwTCVhJrcWCM7ij2+qS0SZZIxnv Sb9laj3bRsBT6XEbkcSNAmS3Yo/cL9LPDATMwh3Cx56cis7MF/Xq8ciWGBEm1JSSAx7IaW9PpBuw kgmhcILXlxvgG0srpMTNKeYyeipLsHhorgB+bZG5iEWjVho65nMgrhSAu7fvXX304MoFn35Ov9n6 l/bjwA7QLjbXcCO3g6291fCKdnH+J5h/37qFegAhcvSxY1y95DA7evBaXv8gf6+2iqeNGBdh13cu ppLneA72WNuJBzoM8xfnL4ppUT41krYopOMb2KzPlfXD9W6Z3AYp3ByXIZHIkEVCTmUVcTU/7tin q7Q+YjqKiW2Ix8XEANR/Wl7F9e18WHkqhgQBZeUrC48ZN1CWLDEsxFw7IY/iPDisPJlJOaaAbMkI 5t859Xc+xmYDQqDEA59EpAA0HzV0ISkI1RoF1LH1EiJCKIflSCeaVSEjp8bScioWz8RUIZg0QF1N SIqQG+c3bmOUGzFMslWrVjbUlUJMlKszl2bLZ31rlS8qwrlAvjAc14RUPzQvdY/NfVav++K7c3gq xiZSKrh2WncFya5AJnZ2hJKrU65fpQBKx81/1y/8F1WCZpWNupUbHHduOrlxPNXwJE7Fp5IuAcmF k6w4c7NQhAoQeUSdSsUU33Px1FRGkVPCnw1yPSVKzgpMppXE1KgigoWgenz+o8WTvpycGh9XVXFj yC9f55+UbvusvglhEYhNxBOjE+S6mNkVz4owuI8s0n8+P2RzSWEzUdB/1r/NP4H2d93jfUeJHJQB XDbfpJJOC/uEXOTH3wE5m5Vjuzb+UWQeporoQOvLpqm/MAL6SQM9nlb30Ns1NcmW1P6zP5QkPEcy AIetYqO2JUH2gA3BAXKVXD792NIbbwQMOm0WG4FCMKnuUdJk8HJIWRuhw1D6prb8K6AIvh+JBCR/ rbFh0r0Wr1rH3Ua4KHQPWvoX03/O2IBJbcOCRnupuAxMv6hfIzdXEcAPG1Sl+8plXVs8iTIbRYR8 LcIEUEDG830FWgfqbYfC0AUKMustkPl21DplXYgQdDX90+ZB64LsooZZrJKIEmGR581Llq7JRR2G 0hfWZcVFiUJDb9+wJt2SxPh0WikLnARu7WbrIbQHOtuQHBk2PASzDQERNy5yQsjApJzO5gSAEA8g ELYcppvKxzgdjSPNLwV0nKkTguJhCAyHBeVR6BzV3it9pXcsNanpF4Wcqf3ou3JhgE2W4+0SAHDS jIA3O8eCsCGJBdv59sSzEyxiY6APNoAXTNywTlqWHBEoKPBrEOFQelCUBOIyfUBhV4oqISTiSAa1 MWqYh3htDIhyl5qPileKp/PvW2oc44oxM6amaTxpyKhTiR4q7V1k/e4hpOLjE9mknFZ6KGShzfHb XqaHmNmjIEOSp0wPCTvxTNw3JmeyA2JaTynnA4qb7CHVr1W+z9/vKe4er9y1cw05CNcaP7zno4k0 f9t0TTReYMoCK6AgM1bPN6+RLHlGVFFiuRuMDGFNUQvIerQ8LGQsf8/p5eFCBZnK3WmpdZFDrhwG blqYm+Lyq5qGcrfD3OBCRaBWLD+cvymiDRsuR0aeGr0CRb3wnmWhdGHJu6fetXpieqEa0+gwBboo UdPvSEBklqri8eoaxSo5BGkXhq4MOVHLkpETDG8KIjIpvDPZ+G7L/OyiBmHuRkPvLoloIWMbmrtu Cf8uepjEWBUlWpWE1AQ8A0mSzm2XLBcap7+8dGKxIaZlYpRnMysiDrPIV73jNHBZjrK4DYyQ2Do5 yYVntp84+H8DJM44Hr9MVVl8RNrKSnUd6uu2WWODH5CgMFuooMBJhhAgS0hxHbSKz4TgNXvgV5og PW/xPmha4agpJRRO/kqdoJ2qoj8wxLTxh+kzIbZJdCMwvjZneHhcvb10+FfAEXfOHPsivVGFYdNN sdbKH8BpY/lD+leJWolGbHcylJPKWJutlr5ihPLh+8mycKxaJidyAzaVnDt24v/8vSS6QNI9VxGQ /LB0TDugLQhIEsT55WivgBjgvyYJOiLB+F4IBKI7gjCdmISUGs8oUHmgfzwjAAdgJJ4eFRCCeDqe +kpACEFDNPywOfyQgIg3Lhkv0SiCQVKNCwDD0K4WjlarAlIUWl/nvzCPFTOEPGjMeUxNjuCNSUjG eU/Hx1V8vbMq+MgRhPJAL+i1ATGcezTkZwun5q7n7+UPOERtD1ISyCseSADMDF9eSpAJ+YtnQbvc uiWGhGhczwKNzKO09QDDpset6T/ZF43bHV4jDSdL8Kk4O/GULRR70MOg/VJ+2LjLVCgLd/s2TWoB yngipHFfJPcx5IEEofxQTAk5+4xd2OD3vRMhRkVA/h8xxTnYhbtiDOnu69/y5KjuyTBi7M2NYBJP JXV8ii5QiYyq7ooLYMhtFJAPPlIz7pFx6Qx7n6hNZDgONtQ4/aABT7vpfuidvGERJcD9ZUl6anwn AuBlvTu/LKKEqNEPRBTuhA4ujwMXIGJlbrEPfxcg6siZ6B74TqeTnxEVb24ThTNMxmpeQkGwtsoS Xzh64ASTTISXZHDIvi6yH8bSSio24chy6gZIxCVfiigBJoPiy8RLtUNQ+GjuupmJzd1liYXUQ+FO +4SIHICMnDPdrH2jUyj5s9sYRQB1Tw6IqgRRXrCERxcFD+9ZO1pdAAjjsWipM1wU3FHUpGLrCVzE YcoPt9D42aEhctGjUFgTlJvPg395/U9bYxbi3x4yQw/JAkTuWQFuCqKkfxFWxoRBlAV/c4OPko05 TUs8DhsLt28bQzEhMWWl2+aUsRdeg9grb7/Io9Xju3NJZdxKu80h0SiQlhcJzBdy+7bsVHpEtZNw c1T27Tde3A/TSUoR99prL7/9KrDv9EBy359egOTLf2MJ3ylxWsDdNSrUbvt2SQNMcprevf+lF155 +c23ZsysiSEvnmVOJGPZdP1+UWcp4ZDdHbdlvHyvLB1o/kLv4QwPHXIk+ObN8HgiasTu8QwPGXXk /OZYezF5+FHAzvzNAaYDnpn9C4e4M/y8TbYkf54h6Xk7AzgHUOH0m/tf2Q8vUG6C2YMwqsijoKRG Z3g4mCM5uFmjebCsG0nFeZYSN8D5QQfSK0y/hM2zRPmxCTmpJBQ1NbM1LwD/cBUFOTJTKOlw6MGY BAq0J1vhb873MRyS35uvgAp5woYJNcs5f0cibpFZWuvBHewDFcw7RlGnEpQierecUT1vQWr/X194 c/9rL7/E20upe0JZ7ztAqaRDb/0ZfDTK9gfI8mllLLjD5nkOS+/7IzETztUf97+x76/73uCRrgHv W8vDX1k6/C9rZcf3DAwWxkIjZcL2bfQBirC3ASrkCevZcnjZlgeimmyLi+Ou7Vkx8FE4XvtU/v4f mEJggDPzDhEzW/xbWmue3L6NfwDF07xRaDbPs+BrC343ysiFz+acsZJ3jDyMnshbwcz8i2UUkMzj /lhkIxnzedwlFfI4xNBWGO/VTLYx7+VplqrC+uqhmU2jfWLxXcqHwPJXsLhoyfHxDl6TsgXQXvAM 6Lfa5/nS5O81L+NvuHmdF5of9aCEw37vJsySDhsAR54VG8DyrbAtj2LVA+yDDA4AFRqfWaAkgF7e NqPBGYDS/3n3ZCMFYITvqdU5x1c5TDasznUfokzFESyHnRfB8tiFrW89SJ6ZNiNMGeBm52nvLoyF zXUO4Lm8PL00QplZH1iOroCnl0aoLGvB4DLPW8Ji4beKvVnoPuco/SxeTO8z9sk/oSyy6415YnTg kfRbEuFKLiTFO++49w+3XwnfvOOT6qTfw80TL7++/3VOf871PRqD/pzJniyRc68QgSvLtg0aag// 8vHzdaEJ6BFDzPwCbPd8sKz1cDAV0nbJxYaGvvyoh4epsP2Yt8EznPm9rzrzRGQASt7Rw8JGRg8O eBDkHMw/fmIAHpgfQJmmVXYsMp7+IDNzwDtm+isZ2N/WSQjTyyguG5od+A9t19rUxtGlv1PFf+it VNlk6x3KxoTgj0IIEAiJlcAOS6XYMYxhFiFRupgoH/xfiJ2LL+ARQjC6wIwAIZIQfEl8S94kDrGD ncROXN4Q3rWT2nO659IjOdkvxokx0/P0zHT36e5zTnefpy3ocfWctWJ5tcUkcYJ0xCSJ0N2lJgzU C3+nzcxBLz1kiEUEsECg2LfZnByUr6JNHJkgDczn/jrodr+XVe2JmYGuS9gEHe3w8sk4ZuuPJeED YGR7m4XCMpGtPJIMsZ5qPg1tG59Nz0FjpdEYi0O4UG6ifC74zybX8LmM/4fSXyszm7MWzNN/OGTz a/gkjG7tCoeJe1yMJKoLQjeonLUCerL9KkOh11zBviqIWYM+GlJqqPi+eR8pBV02h0YAtWzXmChH yBDO6CYsdNIb9J614nbSS9KwfFmdM0w4PKGDCPPLMR5WEAPUNmTvaR8akYKhJfJX9F3NqjvlfbV8 ttmKp4iX6R2QFDMGloVT9DzSbJg4uCTqCj2dObRwF3cSWchy6U+OZoOFvmUZqJvVIYVISzFs023g JajwwcYmC/BiFRRsK842XpKhTlD0LAlN316aQXYNA4GX2SyutuC653k9b+F2stkGm2EDL0Gzyxbw 5B16bqBqSucrd7TLdoaVXziuDebQ0e4TdiLFmdfIgsYxUmsYWQxbmR0UBdHZ3CgKmZ9A2bfkJzOb 2UaeDTPDLAad1vYrd8iQI2iChb+Su4qMGyb+CsGdk6V7DdBx4gmwzl6nxQbD3spRUGaQe8PMYUfK JA2lFX2rcg2ydAdsePEGkm9YcHNpDYtf3VfQ+4H8GxaYesIrd+AVi98t3MV+urao/WbBP1E/4Cg4 8NIIMA9Vv19M57Yt5HZhl+PfcATihr5DA3SbWORaQfINA8uoVxrQvwMFO9LUbOF+Le1x9Bt4Wb6G Pt7t7AMytJTLPqisLV1ZtuRFvZl/zrFxqDdJ/jmeBsIViSH9c2U2rZrQ/PPhrsBZK/RmHkQUDBRz CMNPR6IM4661AR0PMdFlYzqcnq/s/YNx5JpPZfla/y7fSzLYBBrMhAb9/Qp0Clx4ZL3V2f/xOcNn rVCc7LF57KzQ9MrMsqbNmFBc+OAINOgSS/o20T/Ep8Jr8jmrW6PMcCwZhghRf17V1FF8DuOKTZKB l+hHnCdr53AcYkaLCV7ZSN/m2DLwUv8KBhQa/NKsbugOH3AsGXiJK1mzZHlhYw0Dqqjw2F8XrmZu Y4DxbxWr+lYoF5kVVBMvMxfZrj/cKl6cJQ1GxbB6ed3O9xFHpIGX0AEwCjGZ19m/LxEv5JLhWDNq qGWc46Q2q65yzBl4ubbrkDI8j8ZRZuAlPCRzMXepeiDUbmm3OC4MvKStAhqSBflZneOIMOhuUcMb S5cjGrTLlQweCiRbVjWgoHGkGFTuuIFl9cowpcMwbq/CTaYPmQB0eHLkFngJYnWlbA0f61pljSO0 wEti+d1N0Ma13EOOfgIvcfEQh2FkmiFDyoz6WHlswjFaCcdFgZe0pTOFpZKmY6aHC/98+Vh8IPGZ qAKP1U2DF+ZvbK7jOtRj5QnjxHyV7zxy9I02gadzwwQadb/0EY0qwgSLwVprYHTh04qjzVBcZFgD Vb6Vf6aU1TmbmYHuj+ap3lyRUVCsJEGKx8UUw7R3twfcPMdb+3+PRkcE9fNKxaQWYuw0KlL68WQ8 kKD+Kmw+zVxU50wGG6WC+iNP2FMBjLVUbMe1poSXTTwBESQU54T0+ZVv7QIwVFMtCmb5pZK5vYSh mmtQdPE/85NJmcdgLTUwOnZ/W9pTVf6lrTU4fSv7JL+A6wSPzcj11IA/5iiFwf2D0k3YyWATCsbU MUdRKnvL60L+6VpmKYN+CPyXxzaTKs4bQb9a+EMv8JiWGkzlXj6nF0q36M6R33lsazV2mMXZF3Dd E3dU4NKGwZWDikwzVy5MwMP9levpH4RyTt/dNMJ6Zz7LzHO6KiAhQd9a2cisC55AyKTeATOQZ4Nj ipkwMh6T44lJMT5qSuPC3aKKKqrNewMJxZvKzOL/CIXf8nPpndXfeWTrS5HFPe2+fpWGtS7MgBqs P8htqR+wfOj6czDE0YTOwL+x/x2gJicIz07TnU35kgPW7ITlLpWc72px3rcDlBv3W533McgM3ajP YVqqvhcpWTH8uyldBqrqg9mWcIbAgxCcbkqMkyuCMlv4UZthGHVxaZtTSEERg4QFqEhh/XL5Nkif FTYZQxEKPB0cTch8ZszkJkj/0kEDhwn6VvmCoN3Uv9Q+I/mFwm72kcHdc6ly3UEDhwnpT7NZJp43 QRkF4d/CDTcXFdyKxeVqfkmu/FNoLHUVLSGMQoQGhN3BWLaWl2QrLaa/XvjNPGFlsAqldxxUcZiw eU6Y/zj9Q/b54jOzDShzbitX3PxyI7ZTI0YCaMRT/wLoeRUFg1Bvgor/hM/W9HfZWDx3KEr+CmU0 L/E5m/8uJ64Vg3ZAd9EZ3EObioNKjibQIfBGcc8MFcOOwmsXOE4glmDQ+OSr2OMwQftZQP1t5cf0 jtnXltf0bQdhHCYo/7u2pT8QcOkSNSaObIcnjGMmtICbCfNPlRkwXOYyt3lsSy12d7ms57Hdsdmd Dc7ytNbk0S6n7xQ/t/sRRkt1cMSx8Km0BUD45j+mVoExnxmTAB4MdVDFYUIxjQdF9QpMP+ezD5XH aAay1W4hANO1QTVzoXLPQR2HCcv59Y/XZwQ8/09K+wt3zWJrOcoz18Jx2eS2hcKPytPiDRp6iMq5 sYBuEM7ouw5COUyoXKUdCkZ0lEQe6CCysYDQTY2wEDy0qRoKko1beEC280/Xz6FBQ8Nk8Xmaq/OY diZZ/DA3V/UtLX8Ffgm2poClPTTur3AUODzRHPN/C6C1z+gvkInGpFdRFx1Ec5igL9P9rNoFSktl 4HJzDrI5FuBAoBEiTD6btINpjjnUhW6bXIp61Y86qGwwLKnAdlmwYMQ80kFjQ5H5p9pnVOIrjiZn 6KYqxhmB2v+VHYxeBmVyYKvJbAQjUH7hOmhY+7Tnq2p51pGnmtFGQN2Tf7KmO1jnMEHZVz4S5r+Z v4s8ESCxPNRBamNAK9dppytg0AzHo/cdPHSYUNoXkFwuW1lYxQiBMFQWKJuAkYOyx/HFRPNZQCeL ES6Mx7VU4/jtNiYPz3kHHR0mFOcOlRaVC8oPVFDxcNtPm7M8/o0jVXiB4zszcHTN3snbA7jKtbX3 oHh/mFQ3yJ3noLopPFvZYMou8lM5hwBce+FJ6Zg3VygrGKYKlVQD9wJG6qM8ww0kpCvsG6/TrT0G HY3yA1gBHKUKJGzOwttRtpe28QQUnkM2wEhq7yC6SZ8vrwrZrHa/8BsNxJO7ZkLLqw7SOkxY++4Q Mv1pJWzdbbZJsODAt/wFfu1a/obJE6OA6c+z3VDKeIEG4eEqiuE4EjsDt/CFnldv0iAyBm5hz8Fg hwm5h+aYqq5Az8k+WnmCx3j0vCNPc3We+W+qntpSjXh5o5YWK1cBzZepcjU3J1C/r2V48FieA4dh Fy5Rkzv3vQPWVA2zuGxQlXRAm6uhMF1hmCC2/5+SN/Lwlmp45Y7Jho2RfM8e5VhtMAF5PjB+Slp/ bukuBrDJCQzj6oMcb2xsJA5YsxOWmAZTg0wgoTKPanGibDrHCkzdDsI6TCgrmi4wZnPt59L5wq5F rYJonrrOQtNwQBa7eeV6VnNQ12FC6Q4VH3QWbxmDr34LtzMzN6KR807uLuTkyFsgAXT4HTbgWDgM swM4u1ws7g7yi25TWgDGJER3vFUtH5r74Kg/5N//3z/1dSGX390/cJajjxYjI4lknBYHi0CU39MW dbPyOLsIancrx3iMCeiOM74dR1kHbz0bdlV1+ba+ZepBbNG8yWlzQzXkHqVVHtFcg6CR+bTL6j4P a6mB0TglzG69uLnh8GdgAoy1+s7aJwZilrYKh5ilPGIY+sKmxcPwVg43Bot3RZT3FWwY/YZpC2R+ Wjvn8GRgQmG3yivCUC21KNBloBfSE4QcsLUGWNhVHnII3oFhIIq3Vjbwb+Wiek59H38zrO4LyozD i4EJILZsqkb6u3NGSAlmlmqVew42OEwwbj1K5xz+C0yAmcRwn2/R5RCLToqhW2vQalm/agQv44C8 58IAVu6VjGbPPgcjl/dYYMJiBZfVBMOfbCuFDNz8UnDlDl1v0n5ZeeIIDkMzLm2vaw5HBibgfiMB B+jCnjWoqZnlvMOPgQkby2T1nPIFiJJ6TnlsANXMvKMuMcG4tY8Rl/hbNMEwX+8u3HXQ2GNC4TeB /WOauLkt9FNwJi7u2xNyoEst5cjmBysrNNyEAQYN5A2HPVx4BtM6NPtnikLD7zHcw+xzbr0NcA/R XIYetrKRfwF2RfnCUm5j3aTHpCsqLVy7sHGWHuMWiucrdCq8b3KlFXa1fzncGZgAaE3X/iWgv8eA /aj94vBoYII6LyiZtKr/ojtQrTUoOqkvKuzA6BWChihGP1w1A/TRfLyDw8y3U8blH00v38fAfaB6 l1Uz8ALL01STh548pUN5nmQ+yV0iy9/xGZprM+BiCcYR5GG1Jc0u5h7xiNpSGgWkzqIvOGhrbcFy l0p7SoartNbagtjubIao/XLo3Omdwtf8q2q/e/VP/Z/8Y2q/e+293BwubH4OvW+pXJnHoW+FFP5Q 3sPR46LyZWnP3OBMH3G8tjybqjnAFP6slISznG5BE9A9wHxOs2Rz3eQwBjWdd1VgAlh30M4fsu3a RqcqfrX2nsNPgQnL6wIOEgswdfOo1hrUwve5hwpujsdAfysrHJh3T5hg6vpwYJqqMcW09qSw68A0 V2NYwO5n6SIp/YkH2gr08CSfpaU6C+9jNDCt1ZjVF1Tdr1xdcrz/aE052HRjme7FryrXCruErxtM MFw6HxedvPWYkNeh0y5+mL5tO7+X7+cUh0MBE4TcNWPRaWM9myUYVc7UxVduqb9WkServxq3djef OlwJmKDnhYV1XEnNUxuFrjfw6KZqdJUaol3ATVRNvBMIDDRT8yG86qNltayTsxgSTOMR9xo6HApZ TdtHg2i7uCdUdooW2W52u8qfkN2uPADxXfuTxWEtEFxFspwij6v8CerjzQ3BOCqVvr2k2i6N3Isq d0LuhfbTIbDeH+tpMHaqjOJytSOhvLp5TiA53BtmznnMzOMcCU4zD0cuemIy95DHNx/5C7xlzehb tiumtIg118ybPqCS7wulD/JP5z82MdTk522e0nno8yjYyNr4fXEP5rSnDLw6o3zqcCRgAkyLYHR9 Yb92o1j4xeFFwITlPNNomFpDF7lM7R/dJJwPARNs7T9Pct+gwQBjFQbBXXymPjKVRWx5h8zYorC5 C8YVfwsTXjUtIv732l/+oe9m661QA58WvyLkr8Gvvbrv4taCj7H3NrH14Aa3FA5HyUg0MiLFEtHX X/Er4Z2uSCIakUn7mWhMnDAvo+QEbh8blevr2qMR4kvKcdIWHRkZl2IRSPOMnhFjo6RLHJNiySnS GZOlMUydxlRPeEyM1dd1xMTIu6Q7GpemxgGZGpUi9XXd0XExEpHgYTFxfDJeX+dLjk7LY+SMGCFt kpQYB+MZYH2paCJGvOH/Sskj46R/ZFyUJ6Jn4hOp+rpg9BRUBAmNjCcn4VGvvj74NjjC2qBbfPfd A6j5NjkcJh4oOtSD552pMDRAQo7ilTeSSMr4O1RFNJaIiXKCIKUlfAdYucnIqJgiYgJJLMkZeAg0 A9bgWBKqv77upBhOvIvnEUi7dOpUCgW+M9hXX3f0SGKcQJXJZ6RYXIylQKjCYWkEX9NwbGQUCtgJ N8an4UUgbhF2BxJjUyQehXfiiZPDx5vr67qik/jGRJS0JyekA20BRl5KGvzSNHGNSQch/u1eT+9A CKo14O8MYbQg5kVwBQeh7J5AsNNDTmJsmIAfGsPngl/xCEqoy0sG8aerx4u7mns9Pa5er9Ad6EKC yx6XNzg4AOIe8JAub8jlBSC06uHJ+rreFPFF4wnilhPQND2eE15kwQzCw41A63hqEKPItRvxdyEL dAJxJEy6olNTUN0IGvB34Jf19+Oe0y6PK9gP6SANg/CrH9MEEoRWgkEjTiXBFYbW6ggnE5A/mErC A2USEifEyWgiSjdvt9TXxaehA5KYhJIEsBPeYKfXz17XAQXwBHs9fnIqBX05Eofne2LyBOkbl8Py VH3dYEAYDJBeF2kLtLUNkl53hycYhAIJpGsg1HWwItLKRKQJxfuAeqrbFfIG+jwuo5/AoIgncXsC /2n/JrAg+X63B8QGhAcpAoLwe5crCBfugN/vdff8ozsIbe4N9pCTXS7fQK9gxH452ApiFFgNyJh7 IPOHPCmyoQKqyec54fJ7XQ0rFXWxmKessOX3F5+9haMLjlvQA9yxaDwepWelXH7c4w1C4/b4fF6Q lhgK7bsi9MZoONrgGhXHZJzzQiJMFzBnyGPjCQAICXlSCktxGCkHB7p6vKRnIOjqDfQHkDGeTpRy BMRaoEfduz0nPT7szH0BGASxq3Rhh24nh0CssYWCjT3w9kHqPux3+V1CmyeEEXJ8Plc79HV2lhr5 jWlgPJe7PwCN2Bf09rp8JOTGPeoH23wsOmnD6WQcKpnOAQfQin3RZFiKSNAEfbIYiZr1yP2Cw0gT uxsngdiYiA1u3ITBYyqGe9vjSLoMY8NAJ4wVbq/bEwyQ/qAXqq9fCP0HDKpQ316MHQs/YhIObdiI fhH/JuCHNA2XQek0zvNxiYoB/JiCORCegOrJSfGM9Kp33/VZvK60xl8pVfaAP3QoaJ/7gj4QP4RF g2L2Ihl2m7fTvNcba2yTx/A8YrtroK3fOgPjj46KyVNQASDNQWR3M28EoA9NwPQPNeQOBPu4ky+h kWhsiqkSJzCGA/fnhChHMNXf5eEOupwQI10SHp5lhNuD/s6TXu6Qy2BkbFqWesXwZDwhSZEDaYDm A2kAlw+E0Gs1gCssj0jEG8ETHTJMY0OHj79Rnfg2aGZQy4Pd1iklVNRSoMpKYTKEFQQI92Bf0BOy Tiq5UyDO8TjpQpUOHnqMtIXxEAzT1QDv8Q+6hu3DS55ISkTcm6QPXsk0udBEikzLMImFEmIsbozX mBWa3Wc3rgdaPSyCBjF0uPVNcnJcTkSkFOmIguYdgi4Yp4c/2sJJCQvi87kDAfvEE8gOklSTbuPd 41IkOgl/IwD1e4MnXLZI+OUYKAL0I1tIB4zL9Lm9ydHRFGkTIxMwBpymSSfl+PgEjM4NPlAs8Xv7 Bjo62m3h6UuePk3aRcxnVl6o1xXqso9IhSbF+DiOHn3JyakJq1l60fKBRgEtVZYomTy+zhs5LUfk BFSXOAqGBBYy5A8E+uwDVaFINDpF2qNjYyn6k7UHuw4lUmEJswx42j32KcFQUhqVENeMONIL1gg2 wtsHIujHDkbQQ13Dh4/bI40rPo4FaiX+pOAOS2KMhFCJp9LtglnXZ0k3NOcoCUpheQznF9reWNGd MTAyguIIVlfbgLtHsI9Rk7bkyIQQEPxyRGKS1D8tRRIpwYMTNOlHQw77iA+b2T6w5waxxY968zio wJFRbFsR2jYyBth2mDA83AgG2i9MR8wgYt/kj4IZGhkZZz2iZZg7xwddgrSw0tJf30aLx+PxcwNc ZwzGLRDDlNnK0QkZS+YPdLw1jMLq855gg+3pd5j4eUmXhOYs1AXIDRS4sbERRRwyBTo6Qn3cEb/A 6dPG/Ad98rh9aUOPvQwKn+ualGLyCPQz7Dcev3+QO7naJ0UiqWk5Lhmj1KloEuoWNB+UX89bfV48 xDpsCLD0DkzN8UQ0jJ3nzTeJHw+jk17Z6DVt0ImiIxO4Kk07TMfAMHfCNRQ5nWQvQWwAGvX/aLuW 3caRJbtvoP+Bq7ILaBZsWZZVvaNeFm29LimXy9W4SKTElMQxxdTlwy7VQv8ymB+42xkMMH81mOWc SD5TVtfdtBtGl2yeIPMREXkiIpP6IhPhGWMKVEb+s4D3m0sahKUQHoVKXduqHYB15dLngdGjBkTV jJFvEpAnncg+Y0SLj/MIyvB3olegjIercoDmIHYvfpzdBB0Z8+gfqYDnkcpLvYM9Nt7FHkfTh96k 77rVyjuSqfJYWPn746ljVwaItV9sZeQjWMMqNH8xuiuw017EtxwrShKfI0Brg/RN+o9Dew4zHHf6 uZdGXAyE0f00Nsi5EvJavaygN6y91wP/OZjPoQQSEZuAbiGUjGKayodJr2Z3RuYm1tB8WuddFWDW /3PBrdcqKhzUVov8zOGAv8g0wvTGlCxw0ImOgjrTGpnIjydm4amK2LAIRtzLQltrXjMsBeVJJOh2 0Ji18PbvogOX76IDdw89C9Z/tKvBMO5Sj8fGjCY8yVEGAgqEHabREysRepgb6vKKgw9QKk2I140A /VikUajG/46/LujYLkVRDizb2JCvinwsYyugs2xADKcMFw2CqI7ELmhi4D1hg1th8MB/UQwbnzHI XmxwjPNahlj0I0mscqIsdwlAbHjyFeoA+33ZG15KqQutocRf8saa6p0yZv5uGfWWLef8+verq49k FN3efZ++vua8+fvl548qjvqSvdQb8bUzf8LfG+rvCBXUl+PdPtgqqj6/+r2hNHvavVfflIn4zLAc Ul+VNnmcOqMeQFc3AE0f5sX31nWn+HPr9wb9+dEe9bKD0e5vxnA6/9B1rG9P9P5iF8+9oufSe9MR lFOrqYkNZUvde/qaPPr9RkX/E3vStydHh9gVZwqJoCw3xoT7AVnX3LHmx68fUUaElU2+8MhP43fR 54t30eeLy/t+f1bbX/MsxI7WsnL6PwHUsDA+tW01IFN+GMollNGAzRPkyhpb9RNDHBeSRKiX2iR0 mpVAzY7VqR8WWvDF3lhHHEvauZeKxHg1iaIsofmBiD+SyPV8aNfPDiUbPzbwQ+2jnAFhWiMiBlUf EPSgC/A/dPHmsd871DbwvgrD873wLDFi8MGMp6/8SN2obd9OD7Ximw/joaSo+A6HBZshzGcL3rVW cqPGx9KAx15Lhbi8gJIeGvUmC2VsAhQfA3LGA/GdnxHy0h1ah9ou3njDsywIXWzAHA61chuIlcGJ MQSUvA2MczTJ/06DdHk1ehgdagW3IA0CDK0wztdSeiEZ/W/Gdm9QGjBQEk1qY63oRm2MKI1M8+Wp A/wEux5b94dawW0L92TsZWqsyHXhjrQ1joCtYf/pUKu1EcNa+1FA125G9u2hVmELlBPi2RzC5Ykf dAsVoNG+mvnXLFBeqBDt3xCimWs0CI4uMcAzYuNFBik8nG3bn5LvyXsY2+d3sbXW51G/961cO0ZY vr/Rog2+jM6U129OXv/1l5sLdfnzaXECXI5I1S9PAr7g+tVw+lARg6FMY1HGfEMZYAW4uZ4Nnyoa PtvsY3DZgCKH1cpPfCBaiJIrljBDjCyw6OPCZ3syrzgBsZ5NJNP1JmOgILpg6Fja2o3utFcRgq70 OJEKGcJHRAiwf/3l802n060INn4BGY7jLPnRo+8MqSg1COpSwtR3G7T+rj8YdKr3wNwJhKkdgZX0 j5trxM/y1ejs1b9EmOfW02NFmBEb7l+54sS0IiKwMMFO/IVKr//1CtZ+FwVrzKwuO6sCxgZY2DKL 5hzjgXgeXEgPnug//ieLGTvTJz1m7EhEU7eFtRFRRdygrO2Sor/pdGTXYkZKPPgyCzNu4VvgUM/i jPkhxqEQ0MnVEdGp+if6RO/8IImGUosuVCT0l4AOHm779WhxkK6FiKvYlfJf4m36Q89/wAMSwXa5 7xn3IXGoJ/gq6B6FhZaLsano7YTnd7cRv+DzI0huIlTaZDqfOjV2O5GIgXxYi9Hx11mw6YBdKWXp qZBzOnlCyFmLHsP99zxnxJceX6XLdAfY44M5t2qR42NqzjFsFEWH2TQVfxlkrx6DzNdvdseuhZBf f/ggfVmoCWeJ8PcHzAefFLX78S7x1M1//t9fr6wPDXbWviiVFWH2Banf3/Mr1QuFcOXSmC4TqhIX V69KJcTVK+OBWKthkW1LT8VFlHkr01dKpHKMSuSRR9WVq+pKU2nbQ7iS0VokCV8gtBr4SvVycK3F N1QM36QcrkLUELWWtw0HNCjIkl1D9RZDAn2u1AszeWlYy02SYt47WLVLSKNqMDTpG7yn3PHqatVo yvvJXXalngP7oydiNN04pyxiUAxFz65c5B/Kf2IdRkB+BIMJlN7xj2nkr/0QC4EKJZWfjpVLANC1 q7zBH9kt4ndRw9a7OM37qTMxs3Ry9tF1H/pu/vcspXYvHVoPRv4KrAMOTvAlLTcjezyDbdIgZR+/ 3dvzX38ZW12irDQk6uOkjxC4l+f6M10r0/4m3A4WKP/QKK9fa9ezy9AMkK7ICPHLZZFsVWr2JtEK L+30+3mydgm19EzQNPh8Yxf5MZX0ppZru5lySR77sblVvHQXUPnHHVlP/Uy34oDvRWRGwl+DTi/I tMo8LzUyzh+9y59sck9SAegRAbKZqdgrj3dmFpT+9epQlXeMf/77f//vf/3TyHf5jIyDMfuLEz+2 28+DpJFMsbiZEzBhL9vJpC6zPDxSl5kVbcFmZLg2Hzc8YZw9SnJRqzTApyioCxZB07HgiLMvvmD9 kFFxqRRg3SKAggDrquPtvjA7Yo8nMPguRoUCNsSK9UOGhRj0qQiiKG8QLeTeRENIsxg8HYMHYI9C PCP8L0XsMqaCiB+euTspQ/TAxJrD1Ju7NGj7FNRNt1sRMT9UT6ANErnMw+jBLCKtUYofk7KRfpSV S6iNBVAFU3mPU9wlYl8QclHBmX1gY8TbfMO6PBJ7sx96FDuxN9LNU9ImwdSATUPBwBPOIowBBbyZ 6NPkySlis9E+3Ecew6JC/5oubavAEG8FsxBngXJkMmOrN50UIdsY5hCG3OxGe+XW65A8VCsgPYlw lAGo5mKMu2LtoTyPdt88WiuEBpH8IUIN0NQAE/Bd+2wLLhGA8pKPQCfPdxTzXv5mND5qoi1NdMZ3 nKlWaSC9Y3NYADR7IV/roKbeNXoDnNJIDdM4GiH+I+s6Gljgxtbo0Cw6tOUB94TpiFW+uylmcsXG e0YuuZJwi1ePkUT8gXoRm10e+Lh36PO60ubw9hu4zaiCwcjdsgmi8QI+QaR+XfQthFEnPGTziIfx Ck4SxIWtIrllE/GKXkTPNV0fW073qXjTAxR2uTdmcK3riJZSk9L8xA26UMtKwLaKdz7UNRwKjwfF zPehJKFJeqtUsXy3RS7ZeiNpWgGim5gtBI1aXR2VQPutwFBEso5pXZzAyFBoN2o13oLKVrKe3sxW 8wR4J0LlAzXgif58UfUE0oLK2nP0ic6QWcs0oVmtoKPDTdWnYB/CmYSx3ObWnb3EsETfs8NN2bln huBiB12MTEs9n9me4Bq2eQJLvmYE1w6Hzr0SPbcPN2UHE/8ZNoMgLJaB54uoRD2xw03ZsT38Pt/B qaJ3GDAs3pguuDI/fI7ZUJxBf++F2OFjeQO3bx7aRXexfKllCebGHnlYGHnfmo8O+QHNMULAQK5M 23iUaeAhaoSW7hNFNRCcKA993kFQT4CQYnvwZp4UTqU/h/nmBzjHIqGa4JKbDfadNTVE6xjxVb/e Prpu+eQpSYX9pA7Mj3ZWwE4A5kOrW2nBGa5xhOumkQ44bnOfhpe5sE5KdNaRx20fwEWxRDK1TUBD HveCbItUl9bEynaBLQ9eVNh76kQo1chrwOOekBNjMSJfDdV8gyKuRw+fpbudSGINfdwl2K52/bgj M0ncgY69Ck8b6fLkRYV14Ot9HXLcBTIQlZVidxhC1kn9INEEmicEKCHKXzHwUahhWyewWVgHPqpD 22+guBkjJuJrwMZxnx4SP2B+wmJo204bysZx3x4x8Eof9wx2Uo1DvzyYAazIsJNsulk/wFCMVRq9 uLndHZbvfVCbSEWANSFIZAhv/Mr4lvksxsyCMnqkjES+VU9095fdpn3qNpQ8YbZya55akD99wkwk 9Ce/YLyZfMFidPnHDVw4J2eq7hGD8FaWk8k1NDmaawQmZofrd2+eRgn9Xq3TKModsztx9OD2aTAZ LIMmqzJ2XaB5cVKgD0e9Ya4sLTIDn+7WUPBA0cwa8c8FTvdwqGruew15upc2eXos6cRr9Xaf7uhd yX4U6vp076iSFa7hJGwsiTJelvwuEzrdSyw+MaOdDFi9iddoIs0/EYnoyx0iDXq6o7RQWaDnMAww bhlqnb3WOzsSPAI/hO5TEdVktCydQQu5NqKtiz8RikjIYp6/Aq/D2srio2luNX4qSVtnA81aW82f CdDer31tFchEWv9SJPMQPqOwPdTtstX+mXSeWmRY0WCmRw+++emw2Fumismkc/zNNN/8dGDGfO0v NfhPh6VwgeTCyvA3F2z9bL7V5jsVGlS8MBP76ajMYNLaSLR/OhJqq0PiL9mCB0sZ6pI/HQcqzmdd gzdm8YbYFXsOdSNr62Pjii2eIzGGiGK0QWxXYwE3Y2TPory0GovGNW0X8pNUlAp5j/WmYFX+s/hA FGQs8JjQX8aIEgL4+QmoE4M5w4n7EV8Goi5cMC0IIxzRxRXB9V+oc09oifbQgnmR3DTwVr4IPJN2 AKlqIHM3CAaLMZj2+uXbNcbSE1iM5zygZIVpYbHHwMfUvnyr2bk7dVX0SDNeENDp5L589cZYhs9C xJS3UJVNoyMCn2ygxM7L13AAS6uwcScjj4dm9r5wx/eKMZhS7aogaVJ6exXcxuShsH74gSfiRIsz aVdQ8TaOsYzQ7H5Ax53MgaDC3DoucfPy3RvAYSVlQ0QPIkEAS8VqiraN8d7o71XNbkV1uypcdqhG UNC3iOoUlE/p0FbOZFPHsTFweVcjzC+xQfN+H5XM7MFxDo2CvKVRxPcII7inwjhVYqBkTgcLxLPM Se7EoqJGTuYmHITHpx2ewtSS6Dm2/0h1kqybFCvPaV8KFE8dCygwX2nDUCvHfE/QFWl0KzcwsScm AFkv6JeZiFZiSeOerguI8+XQyPlavu/V7FA2VLve0K6rF91bsaoZWZHQkE0NaRtDcDhMRyyClQrf KYyiYpAm1NKERsQn062GaGsId0uqF8BEDNqTDc2jjYVJXeJK79LjsO/0jZ7dU/tn3FG/PzNGljvP tsRkJ9MnUwadzUnXRLKeTBeJ2SsXuJmQu3J+MmzzCKvyU+5O8OdzK4DGhDzxS1vLZVp/KqPB2jqs /31JfH+Mn6iOy5lXiRvy3W6P9f9VAx31aSj2VQophxx15S6NKR17S1sT6rCj1rs7mDwMWixiDXbU +mwvOFiS2sJVR14ftZ9cYzfwtwsNdNR+2g6HNYVCPk9uNWTzDRLRm0e2yEG8v2vYo74QeYIPwW/M LnTJfZoAmPfGcPfhkiJ90mFS/k4ZwFKt4NDIydJUVQsQ6dMGEFqyjFdwK8M2tiXPzvENDU+KMJIS AR3xbDTZInqZCwwGLgSy7pU7ac1bcDxmvRbkZDqyofs5K5oipvE5ZdrISd7JTWh+hS14+bxPxz14 h5wD0S/2SiU6RlTWzyEP88GhkXOdaZpkixG58FrmeWbd9gHKujLja0GpxIjD7JjLC3o+s2YEauag ncAd+FKo3LJRBQgzaw6XlhOXGQK6PXO3cAcZGwBrzpLWTGlnluPoh7R3ohSH18wJDMQx4xgf08JY Baze4gfaMHSRw9LgA/2PK7NQnzRYo4Rxptz1I0URWHReKKsdZAl7+bqghONtSblz4WYpzMZLDAsd WAAdeKQFzXRV8KU6VB8CJdg6IQijDJ81VLtCuf4WAUAvDZeFjmWYz1U32VMKlclYMUUgNNu3sqY+ M+sLVqjPRY9fwF2TxKfpTON80Zn1Lap35v0CeQEF4FvzlnIFxKcGwV4DtiogI+ATnWx4hZJ5C0Hx egF2ugDn3RHREvMeCG8t3kbJvB4nz/qY8KucZsxEQjxxx2gqEJpEsPtAPaRi77lA44RAR9D3mGmw 5glYVggWS64hWyeQfcrBR/6yTHDn2HaJdQlLmWrYMXxonNRxl6d6ZcMpZxlqtTeVcfwYcRpRzVJr +2XjxFNsCvA4VEUbvstT3aSEzFZGu42Eb9LQp7rq8iSNyMOrLXQs/0I4Tax9SozqIi++x1ne9vco fzb/rPw5Mw7G/K98IvXUHR5ODpAq91cDAtipAaHVD7P54r/IqDbqZe3zCC0ZaOkOSlDy7hx9Sr8f AKTv14Hn9BMN3TyhKmpqvtDU9Nn5fMMjaI5KzvCsmIS44qN2k9aJm6jkuXKUNlXJVNa3J2IRqYJi qVdDe9Qt6qJ0qjo79xTChimfi6WCzq7YYblhqhJjRWmUxFgplneTvPPU84rH2JN7VlRIZ374zAaB 3HvFQ1gHpqpW3aybkFU1QOb7RUfHrGcVRVL6hb+GGCc8x4v8VcKwyKqzDBTq+HHxVCzJ3aI8OpN0 3C5PZdBXTyUb5YQpZingztwpKqPF+w8oY2n0hNjRfl61vyGo1rKHweCpqJPSebM9UwfOPgxoTzJT r1g4XwmyTwo3Ly8bH7N0WEdQVBOrGLSggn97oJNDOQP+WwpqDTcKluWpKmKVmMhxzTouH0UKfzq0 2V4NYy8tfFou0qqJdPzlHkEzo4NWGqhdB8mN2Prw/s6G72JZlP4yZE5+M2RWHUXwkARZjWetAl8s AtXKn4vVO5jz7wQ6OxYVcc6R9S4OFKFIEjheTxHjWIPWuzag417a1Xqf6Ju6KLZnA9oYArvImhiR 0dSFruvds1UFStVN6PADo4MRGrjeqXuVMGTqFw1U748iHsfl4RxX7wzGhNlnW6qS6aB6n6hSq6b8 tqwFZ6hWvRMO7FcCgh8NU2+7S/5irN+j3mwXSwuopcDSN11BLfY6tN5yYo0Lyj3AUx4rQave+keh 0qYq+NjwrTo/XAffXOjgR4yvSqMd285NvSf5XgmqwlG2YxD55bYRx+rZ06L6qUaFzqFAh2HlBcKe dIqKpwOHtpCvKhj1l6lSA6rIBQV20nsq6p4Oj8TCp90X++0OHiZXqexYVM5m6yei/OJElJntDlRn 5iIf5KsQnMK/50xW/bITwnvla9BNlXJhA7Xoq8x2nqzRJFunJFXdVSpSp7mgXKZ9SkZtpPCVoyXS 7aS5bjuDkdUtSpvOp4EqU3xgs0+daK8S6DKjJTbrikAsIp4IPfHp2N2hVdQ8HUomRh5tmfmudJ8S wIM6o8nhzbdwRz2HDAXWmlQDYXex9ORc2KFlxlXhWxZP3dGebYH1tQq2HXtusaIe6vgJRR5YOxQh FqRTtLTVEvzOtNMpa6KOXCz8TEd9vo1N8hRlmAxkvyyKZi8U4kyNmHIaNBdjCkdWCUITqoexIaa1 Ck9y+eYJebKegR9B01V9o6+WfZfTPo80gq9bCu0Wrfot1B0+IExYyH89af9P29X0tm5m57/yzuY6 AUogcVzDs6QkWuI1JWpEyhpnQ9ASbTGWSJWSrqK78D9qOwUmmNtpgwlQBC3Qouiuuy6KLtsi/Qc9 z3k/aesGWSSL+MbWcySRfN9znvP5tktgJnEvMSnXSb0Qya44kOFGgs5Zi3EvM8lWQmUapehJWq8W 0v2lD9I+zCSOIpN+ndTy9pCpqApwk8fSXNBvA5N0ndRfw+cAUx/CS+X375A6cNebFLhsCdBCrzgT T1eJG6ihdx2TeZ3UR/QfLxHR4pZ0rJx8KfCo5fGTTH2MZGZSsSSZxc19ydmwqlW0oXDnr3DxMhs3 BXxwx+OaTEeZycTSDsx62TDresSXnqQGMPmj5E3fMylY/JLM8+a+5lYHWg2l2kyJP8xMijXJ12Te avAqMsgagLCzYjgJ2cBcBNt10eSrRa5ULMd7TbKnJXZuxTIrpmItxN2GhWJCe27o25FpbslfnJS3 mv31x058k22Vs1uG8yifL1d5JStmRLJvGm4fbElcWYnMTHshLeZXiMUTNZgj6e3x1iLtn5C5BY+4 1+ZPvs3FZ87b3OZ0q/NK1d6AweuhJVoEUw8u9C16h8lWfe5+RTna6ojCM/oJ5ql3hBK5cEQyJaII itmXSTeOTEY2mdcrtqrEZUmPmTXSRQOBIkdmcocuwoL5PtiUrQQrUmTB3K3xyo4o8PkL8EyRWZxq +mjfNzXJV4LuaFXMn4rqfUmbkp4BprnN4fUreOBHJgFLNGTljRsUALNWYtJ7tKsh6E5M4jUp5rSd 9O2CSpWlcOSQu68oyQGfFKsuFpykrump1HuTIiDEyGRZE84skdaRCpI1brIuHezMJFgJe+DZEnTH EJmtjqJLpE2gTlPD0WKiqFSyJOVFiz/fomrhWqreJkN+hdi+WRhS5OqECNraH4ypwjQtkz8lYHMk 1UVbnhT+mpwn+j/VwN8rdTZOiZxbEVgFyMAM0qqrUITZwl442JXE8k5FjCLcIv7GqtYWmCVhdGtS pkm5IjBG7zWefy/j7ho2jE2KlENu4g32zMO+eloVnuRNArtNqIcliAiYrc7SKvDI0rTBpTQtuJU3 bLb0le7JedUVyUri/KQEfSC3GWBB01dGe5mRGpvkKEnR9gXl80JOhQnWfuj7OZAFQauX8XqU4KUj mEGQx7JoyMimRpOyItqaxWeYmlc3JhtNtoh854KzuXZL3gQ2L5o8kSqkTdPL35Uy7hHIC9m1K0CS m7BnkqLJU7kgE3XgIiHV1uqiLgwqA+rzK7pZ1rVRoMs2KKQLXBdrYiHONx3GNybTmawxL8NT+Vrk 2bIel3PVGU/PUSJj2o064ZlsiDPm+6wD/3PHtb0ahWCAYl/JBrN32JHkzN2QLHsLdmFh0t/0zrP7 AoG/7PMW8PIVkDfFvf3UkclmJqiH7NXzXU2Mn8kJWA82B6mhQjFrQyJI1KY5SbSpH49N7sF57dT1 DhtJf0hKHFxnN2m9zItj9hsvPXABH8aJ6BI6Ak5MapMX1rLc6JVzxjF02s/skE+31iFXYpdtMRi6 1utX7dfJV+PquAzt0E6tcZIGgcl7EhUsVvI7eqQyztw4PgFtApSAdL9IBXJiGj5xKGkd18M760cK XThCQ+mRd2hhwAhh6VuSp/CXBl8WQjZCeCj1x6jJFvDKAaqOCS7MkMSbjb3G48lr7gSHxAuqx1W5 Xa65NR2p5WPdPLXQ5w6aiBXdCu7drknXO4EnBb5wwGRYNjqiwHdTIyd3Ju+Z7JrjBnW4INE7Yz3S u9+anGeyO37NOeYMDN5JT0iUpjhADRvoy9oQGgk4t4BkX8JvyBdk4Jzy+mTaiUzOMyE1TfcNtp4e S6nX0xQZK01f9vSddw1ZYUMdZZTCWZ8Sf/USPygXBaKK0iQvicS5eM1mLJ5j9NiA0DYOnVf485d4 WSz9iO5jx01LppNrkw0lwvmAZFuyrA8F900c1HJtHKdEiVxakYZWKj3QeL8ziFuTDU1UmNojIoBn npYmVylxmrtoHDen0qqYLxHGjO0anX5pU6HJ/n0pfrPPd01NhpW7dsg6NRh8mOz2a3pQ1dmqUqfL JLNbD2ESKYlfzN1K/eHQJELTfL0mJ+ZYST9rB4f+/iivf6gdm5TzVYrApKjKYUJ3jf/DndM3ATMR TU40LebLqt5xb66HzrJsumENaioI04Asqs6OpsV6s5ODbr0+ET7ujm3hLl7haC/ZuEAaoOpEsZS0 aIjdcOmfh3AYuj1UA1GiQyPpIBiYjKhsX6+K46IpZcRnW+SYY2B3NeEzkxrlJin08KmUwKomnYw8 ctZpoc8tumwWZMz2KETSP1rQCwOFLvb8Nd3gamsIkkJdGhRZWsQyyCdEdJnzXxw5gs0i79NWEyjJ K1eS8DJWGiOo39g8sQT/2l7ldflAG6JHWqBCu4Q3LMjxyfy/2POYkpaQvdhrrJ+03sheGGiFQbHa ZLLYpSVjr/omus5MNP5Ne2EiqV0+lMWCI04++RyFbjlQ72Pvy3glq509MHBreBTu6jUOLIbIQbHb GmUEBu+I6TQqxCZ1/QADjLQVpNm9l8GtsGrJ2NtBOolnf3gcIHGj7gpq78ItZ4DGpFxk0IiY4tJE GBTaXit9WVKF3LK8lYVmuA66848FFoWWIqKic6vpktYhrg+ZGDK4g/pAQrR2+jW0alrTstZi8dCk WtMl0VbaRll6KKWnumip+HQwCUxmlRZUgVX2KKu9PL86EdJ3NLISvjgp/LbmGPWL6mclcnlS5PWH KaHw+tqkW9Py4SGvjrRAuekl08FD5OLsZcWkK79QXAheGJQKkstvkMojcrHa/qQ3OP+xNxjWFep/ dAVoGo9CElF3g9QnbfH8a3iLMi1WuKZPgS9fg6cVT4J6QTgIf0f4K40/Gnwom/V0KkXDs/T5iy/0 9dOD8PwHjKZTL097Mb2srm6/4AJKRGIRE9bprXQ69gmkrme/yedws5/2aDharZr8fd20gJevgb2C pzti+hup5FzslvtHMfrVrx7zluTVa8nr/fxJkCss7s5yTS8kWnGlFjoUB2aMonzA8CvUbTzWO/rA /pLUUN0SPz8hfrYWqFUk8ji0bW0Kf+L6acNifs2afmDyBX1WS+LEjYhKHrD+VNJV6Uz1LzFkGMUB X3ysOCAVz+LuZx1SGU6Iwr0eiCYnVoYTQa+Oo7tP+pPATzGFeRCmCaZyBVEUz14P3JKjabiaBuMd 5fBaNDAPTwzdUkP43hUoxR3XG91gakY9tJG64ZTH6hEyEJ070Q2iJIwnn8qgxMgOg2jL8otv+v7k ejq6CSJzPZm6njRM/VHYFSeFd+UOcSwcr/JPf4mD2E+i9IuoF3nrj4LUnaf1NidrKkzvhDISbmAc TnPgTrr6uCOORdp1h1i1FiqaMHnmRQt8cRqsHFys7MhU6CqRy9Mik2IBIljqYJBCX51Gp9AXPOTV RTvDrlpoLmITixpjvh5rgUCksKFWJfuR627PyJES03OvF7oTsPAHOzPDgJLUnX6FP5Crzq7Ors1c p6NuFLjTsKYVigWSfG20OActWJWT1k4KGclwHvR01Asmz84RNJzgPMDAfpI2qBHZoL6tevzU66CR LVkRLVYKbToJ/cGzcxTNlNtkB0Q+iaitXtSyKvTFKbR1SqaJn10/O6fR4A9wMqS5QbAib4qXEbAp hzSd02mmW3pQ3ghrFhXVRMuVHb6lvZA8OyfT3OYYupnbVCDn1onpcj6aWwFybcFIuB88O0fe3vIQ tHLrdZf0hOodt5Lb1U74bPDsHH5L+GyQr1BS4WSXboPJtPvsnHpL3G8/z+k5rnZb77ZezfOqdqsp bmPsTuf429uarnRL3zrfcZey9/IPUm7mR9H1s3McLkp4HqAdmSUXXJ3PPRQaP+pnz86JuLSQHrPu 0pRIcuHAEjfsek+UUKYjtexkYvqypWzT0Dr05EgsCwqenXNxASKF0ad9/bhfmd7GWZDOgmfnWNwZ 6S/1n6yPJR8Y1t1tGJsN/KH37JyRO1vSxsDd4MkOs2W53WhqrLDnbWwrK6wgF20IUyp4gLsW6rKN whJS8zXW+baFvGojZ8jfE6EmH1kWW6oKVC0T9q+fr9xLKlWGvFM+OtEyDIINnq/c60GQJyp1UyVX 5C7L1aIxz0KKXLwQSSr6Rh6n60OuhLW6Q0lcvpBIkZuUPSw2JwrsSNcsaCwmk6NHF7TTDArjA3LB 7jRNm4VRFD47B+7yViVuTZwZKVhZjYY0RevLkVTinpDHCWBZKT2kJRZWwmmuVuiLU+g+M7kz8bbE iHBugtG17xAzRQtaDFHvMfaUh9kImZtumuVHXlSoPcngQGtuSG+UxM/O8b30RvCyxkTw6ONpAZG7 Gz9kn3/22WdZjw9uUYJ33ah1xN4M9WIP3K4qK99TfKURfQXE76XQnX8Tts7cu8ufykVORmObH+S4 CnyGUd13QeK1zt+7Ixc2PlSy+TuiT1m1nItfionKUczf/evf/Kf4x//+4/99+I/v/w4cB6duEjsF KxXf/sM3P/ys9arx2B1vLEmW+bRvfvjDH7//rw9/JX7C6cPi/M+zIR+2IO8i/brWi1X4SRbFdiqq v5XDHehfrreonXIv0QkmUWjpXKdoyIGXhT9DUzJpI8KET7kz3OB3CPeWC4yRuJbJVYzmzk1qDDQW U3j08+6iXon8aigPZBNpUbsBHA2/PAHn+ApHVFvTNQTOMOpbfilTzS+tOqHCrm9nqJK+muePdasJ oxV80ALnbQE0vy10QQAyEkndNEeOLjq3qRuOMM3MXDTSnyLKEUWmpcfWVyD8JDhvJJAWEteaiQny FM5Sy1JfdSyJa552b4gpVz/KnawAYZaQjTNcNBTbA8byw6pdCJNrEW+nw7FHxELB3u7XG+9Wa1l6 NUEl+YV5FZVGdFeRYyL1MVVaQ9AD6/mWZUZ0sTmp0IqWwWInY2t5Q/pnVOAAsUJF9JEOzSzzp3eJ Rw7/hHUpVhmqvcrCTFCygVOFN2SzjcfDwWPFv8MXEucnJWS4J+WWl5xomo4T81DpzFJNOVVlKwvC HIIgyG3rxZZskktHPl0OoouGrcjk7YQaNXRlgez7RTm97QqFJxU5ZS2sYZgGi+EJiJyY7IYYco2c oZM/1qErZCW3oZIna7lRj12bWm4hS/AMrfx4EV5pq/AEUte+pZYmed39ePLaTIIQSL2Fll+2k2+h 7EiS9cZaYBqlviWYyX5FaohrVhMMmSLvqCkSru/WF5X6N/RoDa1krRdXdsEgMjqxjFIygy1mmimt tzBTAkSKI6Esq0zrXY0KnVJWfiP7YqPGDM58o70Bznz12oy894llj1zNkD3QhXpp1NUYJkCGPr6k PygUguuL7c5nwEG71I1tt9VvcNl+g+wlf+L9Bm1r+JOWvPqIZKjLQ6CMZJZWFwWrN7iLp5PM0k6m MgUi49wTKvysH04s2cwzDGuW+bMcbWXaxvX8fhibO5jLNl31FuHElsHSa2XDk0dWR2+d82A5R4t0 /O5NP457CntPJO7RlKSJrg9FbNjinJMOOyyT9ZG/NN2bB2fNdgfToXOqKM6N1CodZ3dZTigHWXtz cmKISDWm8kb0o3hyZ0ng4wrtDfQAnK/cj7MZ4lUaUmcHExYVg+DOezvtBerFZXH0vtovjFm41gEn frXURvcmTBKHkz2VpGpVqVRjYicademg1LgADYhv4qF9KE/1U72utX4aDjtMf+Rr3337t+p8ajEk M2OKPoVYY2OzG3iP8gjnwuNekDmnHtdyqhE9iYd8XerMthj74A+GQGx47AKBnDca+5PQ1HgCQr5U WVTEMw756gmlcBoYzwLn0OMNyEc7f8eK0TnpuFGKcQ3FWKli5lZ7lpDFLoYbbDlR9Fhw//rR7Aat 00Z9svWJxpKzTLbe6K+BnzoHH+/kQJGDrkBn/eWcdwxGtIYXeKAb17wAnTsg7hyCt49JEM61mlCi hH7/4bt/+f7D7//NKDXUtRoasKuPmRoWRvuOB4gp4HTUmTgnG+9VTgEDiCztF9MxJkoa+77fZHN0 2vMNRS6VjOvKE3//pw+/+/133/zwp39WYrdhNxilZp29K3EWgFppM75fxpQf5P3ab8zLmNZvLPgB rm2YPXCFNW8Ju9K/jIedMDCf8r5e35eFfBt1bIQ/6rVovutjiJ/G91kbpn4UmFMQfFI+K/VsDvkW 2qixURLhB5M4GVriX9DmZa/z8y88f52/t5bZj2b+naX9sv6TuEr1tn5XtjHnLYytEfVMkafGj+J0 YIm+blC6121eWFkH2DHdC6YngpFTcY3i0UvjVHCsgpPKuY53ik48CIaW5b/qU/Kc5hsCJ6lzYEKn ZuM0lG+bo8G11Tih8ectfEb3jKissQUTlNUYSp+jGABs4QhPHKcRI/mowZM7VOsYL6Y5ktPvmQei jUJwTQ/X7N9e8RAVG9JGC29w3DqlMcohMBtZEui52cLSuJgtzOHAjE+zwSBA+RzMjEONvjiJDuXp GWS7MTVu0Ra5PCky3hPHQZTJlliL3nTijyyZ7+3J0PEPL24WZYVJga5v1mNPw+x1dLGh0ovTs8gn 3xCR06EuEYxJDVkaH2yILm+Wch5dtynXppZTBNNJPLbUPdg39aZA0M5MFeFjOQeWtSPcusSgN9Os lXNBo618xIktQWjpO5KS5WPFnFRSH3ZsuBNT+QrGNPuT1HJ5Wf4me0qk/sHIjNBSeBBq8twea8Ft pJ48y2pbmd5FMYijXmp5PPLnfHQFXGY5Y9xL67S26LBnKbyqC3+1jQdxGkSWtA/qHbkRdlapZhJn CFYZdt4a+MWBbqsr6b74I8vLQ5NBsH11rb1L3H6aWFYeZl9hOSxKOVWCLWRuBnESpcnuYsvRT7jz nvLctVdL/HNkifpbej+0+vsVjlkwkyfNRAqFN5FfjX8xEFTc+KPEt7Rdrljv5UrWZCjA4ATD3zHT khZL/uCFZwuMw9ATLVH66EY6pJNnaPuJOXv+Gj1Acs4ed+GVqlgSY/bA/+VSkwcwGhbfmvOSYc5L Jue8ZM6cFzGKO3HPMvdRDVa/va5rWh8lNj8J5wZ7S9ra0HgdMnQqXUXcDWhdmBhxPC/yqn/cbFEB XeVkb514RjyeYpC1vvB4s9/qrmin4FhgBkJmA8OYgtAegpAv7ouFVVPAR5bf26kJPsYTtkHnr0Bv 6YrXWqtOgjgZW4KPX9FIx313cSW7Jaz/JZsNDc1X7YbM/Dz1i0bGHLDWl/SyKWqbydK5Pm2noyPi hHFfiMg5ZOXOHQcqkmDsO0HcpCArhAawmeXCsprb+AgfK/rWuMuXuDBrdN234+QzF/7MRAiYC6t2 Q6eOXySk6Uw3Gc6NY14J/Uy6ZrevCm+BKrXNvsHEILnGk9QPHb8i2ZEjiC1Ou8JNG4nkDjX4hrfo Lk5P93VqehswzAQDijV9lD6PjCfhe6JpPTrJrA1j4ZottIhkg5xWbfGws2Vhn6CaeEtbN8vC8FOl u/2tUbcIGDiOCEcXJvUW9kbT5XPPd/wQ/Moz06Qy2zrBByQSHf/DphG5UBMrBRVZ9eZEcwB7/6bH 7McTQRgbrp5EJ+hljp9CWxDvDc9SL65uPB05nsq83le7hcl1C5wcMHb8atu1K3Bi7V3WmaiXCm71 v2/UJ8O8Oz7JgzbvGZP7kpwbPSxMDML+wPFKlsSrs8KZdUOGcRg4DskSBdN8jn22NI08gg8t+9yQ ExxaxndFnlim45CJ64asMOusUsGvpuUDRTEC24adrBDGf5RNaFsnPGk6ugR7phgM6X3/799++4e/ Nto4tWM1hVBTe7dqaOIWlYe66lKgr9o0cgmBAzGrbIE9KYF01ZXVTuxsGwaC9e/tkYpf2ieUDIIz 07+Fo8RQ8P9og9DJjD9QX4G8pXOsoqxGVqOwK3xmOrTIITz3OCpEFvLVGFm4coHp1WJXjsyk8kG2 T0fvK2nFf7khKPaQxw//87v/VUVOP2t5UxaFaep4his5iGFTFvMCxQo1/XK9Kgvl4qhyKOMblg2K 2hEUi3Dyalk5QQ0/ii5i1ztE1iCu0P3EtTrId0YOeuh/6fqJ5GmS8qwWx26TH0g/K+XhD4OJc2Ke Po42G5ecEsiG88iM6yLv2XeyQD65YdWu+LNc/uv59/e5Bo5Cp7bIxyjnM9k/7XHldK+oTOilE/io JbfJrpyuRZZa75sHugXTxNfIoB84/mBRiD4mNZIu1CHxTjRF7a++HD7c4l2xelfsyI++vz9mt2Rn tSvSoQ2YWX+wQxswwxCZLfYSzjZGwmS/3eoF3JmEvb71DGWbW8YzK3ayzY1c6R23q6BFDTER1RSn RxR0z4LEcRm7ZwjnRpj+U3jBmuMn2YpciTfjfLXWN6jrR+G1dSSdEwo4YMkNKjiSgD+QjyXQcpNx YF1KM/19S8wLjiz5GTGRueH/03atzU1cSfu7q/wfztZbZYcK4wIBxv44ksfW2JLGkWR7HYqaGlsD aJElr2TFMR/8XyCESkYhgeVOcDBvuAUTsyEkASpLltsmQDYsTm0Cb6Dq7eecmTMX2SYfyGarsGa6 z8ycS5/uPt1PS7wnl6GziQGK1ZhVsmasEGFXMyHtUMY22lMD21NCzalx34xMWDVrrERaJALrqlNF 2yShvr1Yli+dpx7a6H/slEgdKteUCRFrZO6gTx2rkk7iDmMiqb8x5BuUtNX9tV5EDJ2ixuPu1EkY NCV9izLB0cXdlFZl2Bq3/Pgyl7RrOVI3FVzAq/h1EWhZJHXfiOyxyigDb0q4NmzDI3a+Is/VUNA0 YFS6R/GmCyIj37pHy1E/S0HeYyOcxSpUFM1C2SSXSKcX9i1IHMqW7RGLlnHbNo61gcRC+NRg/Qr0 jZpatXu9WFyXvyvKPw0PEUxInogKyYLMdtI9AyEYwgXSGXKBwPjebk9xWFlXt6SRtrFSXaahTCJw JCTA2hRAs4ncTkGlpfJGxjc4NRhTQnZYNB4lj2hYz/l2plZ6q1hDjcGSPSOSEZCL0CuAX/WyLx1d vq7l+PhHxO1EtR5+ijQ2Q9RIVCJz1qhmfGeylulJab7VGSw0o/QULS5WarW20FGny8m9KNIEXdmL QkI7kfBtTo1Gm1bhBKzfUik+Ezy8xxxK+FalRnMIxbpLM55HQOlH1gy+u0L25tqBGYTepIvQsrzX InWuz7cxERi2vcpxiazqWBVpilW7SHpvIUQeayLP1YlI5Or4lKO+tckjznhCKweNhJOFbAMxNWaQ /xDi6gxyibBSnRnTInjefZVe2jU13/bEVKD3YCn4CWlpV2dwVsu10l4DaLfS6oSNj/MJqzCjBJB7 3VazRtr0jU83xKLghlgowfgLwYDDrLhvh7qQBQLlmVfBVoxdu2ZMozZGMs7t9L6s2jPkW6N9tPDr XExN+WDJPKzYt0PlCSH3cdFMUCIngYIryXP31wV8XgK/kceEKhE0dcmSDZiinpusxFwcUNQ2rKDa WRrAw/xsky5J8yap4RRCmqmAmOyvF9BT1pQUZEluTq4LuMJg9zAUvaeZyiz43ipwh9P6Z/kZ2blJ BBD45qrIqZzxQP0r3irW4cDyrVWdwYPFcIbr6VmuS4/UFRfL2GVsD+CfCK8asJLz3N8uCsfwujEe dVoPGK5IFHAVM4murPAdjbkZtB7bsBYwZPV2IgBeClNFnVHESwPp1IZwZXHU/WY5261v5DZhDCkB yxY/uT+c9LSspDETasBk5SlbPD7Aw/YBUKpCeqgp9FCPayRoxr7MWaibiF6K+b5C7ruCpHFljCQz AmarLs61cbpF62IaT5iAx3esEnoJ+XkgIVG6A/lJwkZDVnFoRhGLHjBgiYXmxLIksRCJhy7pvdDy y0jvVeK0/nqkkzMoeOABDdi4L/WA6mm1L2Do6hMW6US20JZTdrksH5oxewL2rl423VPrAGaNS5nl B2fyy8j6t6GqofTMhOuO0fMk83yjV6cubz7oVVxsHtFsv6EGz+P6K1Y5btm7kJk2zXdZaH/Sqdpv aImAIUyrMVEZp7nb1k/fVNxmV0nRoOVqDk3yUPwRO26XZLJYvzGqBAzk/sqMwnWo+ExAlUK0VOD0 HNFS3o1cPmAF88AueIWwnrC7IIiaywjmywiXpzMYXAWAd9jX3rErZiXSx6Ftky6ylg8RrZ4Cx8V1 V4w4lZdK1QAOKmkdBgFrFFkYrBbkkcrUgHuSb9E+XSm5K990pbPLkSHDwDeoB9CjCgDZpmUI0oAB /BmpRg1QU200Qn0izJuMPQ+hL6WacYl2wmiHNONQ+mGImliENY+sZ1QinICMdkaahIDH4NHPZNqZ 8Xp1u2wVHSpVJx4lPe5FSQMZ06sKCHjU9VJlAiaRjqDr8GJFTJuENXFj2kiVQkRbWwq5djrquE/4 x6FGfSrv53Ok9GFdopuAPYJlkXexLBQBdiGWSCrT42OdEFO5UCkzDiXKy85PFHjRVK+2odojkU0Q lWYVUHCIG2YoGa24e6pAd5JM+CipLZGYxxMEUi0q9AgkCEALRxL8hJOpKxQDx71MHFnaTEmoMZSj k3gmzC9Ih7K3OJVS1KQqi3plJKwJjkB4bgVHuKd/VdrjtzOUuUPp50pANqf1nowENcERiKgib46R zqRoLMWMEF1sWTpRKtOcqkNAeHUOEn5tB6KvjNsFi3pc0ZB06J6bpA24E6WiBHsW1cXKjPsFFO3t Kfi43QZHzRGJaUK0M27AtlXeiTRfa8oD0iDCPolkwgkR8qQEctIlXVpimXC6CVmlYgI4qEUej8R3 kTg/nUbQn0xWyeipnMQ4wZFPqYb54Z4NBdDp80mJcMJLTIdgQtzgWg8YzkUnUvpI10XgXMGmB9ZC LXWFWwKOcjDaTwlFBdoSa5+XY/CPmkKBNEow/NBFTk+apkRDYczYsTaEpda8ZxFDQqKigAGpLST8 MvQFZo7G3gtXIVXRlDgoRFgqcPE6glqrKolmk76GWqUemqxW/kJakpgqpCmaEh4FhbcBNMxrjpZF BnKxPL6jvsNqU8fcgAsjkxqVECngIJ0SHeSllHuQ4VlV4qMwCdGrDO6o2GPYdafsWhCOXOpGMG3U 8k4aQuC2RsHZpW4kybj5KNHCkxIFBSdgVcRciB2b3m68WACkP9xDlbYmp9ugrvqQKMRMzVYYhiS6 IwJZV6KhMI6ty22FCV57oFDlkJSDHMSIg6tjQqQl4P0bQ1pOwqMwAILWXDwHq7wNyOT0b7lmigpZ cWlAZmGgxKTylCUDBTgJ3gRDeT3uK3sta41VKhNrPLjIvqSET0E0LI0oz+ajLZ8HwHoNMH+GZvVh TYKpgOcteLFovY5ZYzMlJGLT/Kc1G8BsjEmVKgT8aHrAkTiACABHAnHHLwqVUzFvpcKVozU2btGm HXTo5NRMr8RcAU2ZSfA1hSOzMQ+ZzYNuA2iHVLICCIMMCINKrq1PTP+cppoSbQUHihY+lZ9t8Ggv ZbAi8d2S+qAEWiHSHcXJmhBgLCTAODRXTGpZPhiYcHsqWomNkxgm+23SqlnuawiezpV4gh+wDRCJ Qa6ulbiA61FD6DeO/2ouEFiA0w9aDgOWEWucFFzvKQawRfx4ZeQRmDXbnuCiUQRTmJhEMLPJYC4o 3DPFAUG8xFrajmJS48pNwigQFso0UHCm3aoHtZq3xnJ5LEapevETPwCS8RIT1NsKR8hgLkJGiKcr yGPGEVePmnemxsuCeKRDaYnVAlIXQYaMB8VDmqk2Q814uDSAkNnsx29zabnDDVNJlIokD9xl5cHR aH6NC2LgYI/UwYE6ZO3If0eGBYlGqxSIlUPotwR2CYZ+K6qZtCQwxqDEcuHnt4ynn6DCEfewieSU Hj9fOKn1SjAXwcCjB4WfSeeWf4F5m1iqWLMYKo6USvYy8C7iwFiEf3MEvYKtDJAeaJGcqGzbtgzK i+CorhChHoJ6EaQ1q8AnF+8qJW2X4O+kq9t2WsuAvAgenKBPI4QUNs2yPrkQ2Itg4h41k4cfLDOO eV3zq2AQQ9FWRcBGtjg2VilnsdKoFdp5DWtnvmrbryEssNdDdUGmqFGFkVRZE4DkiEldToJykICb ZsniBPNOullAZc8bqBAjdTu36veIV/VbSdVT9QD8RqzbD/XHkkEhFqZIlw1fUFGsUoGrsc4/xeeq AE2McQ9xl00IyC94oWjrD4j98s61HK3XFHC9XoN5VWLC8LAAq2Ta4yWSoLZ3fM9lruvLMgO+LB6u u0Hqg3lSkNywCoXX+/XgOIYyiaSEh+FZ4TusYpmXVS0h7JJvfnalXpOgQR5fryEBYsAXqLmliGpc 3Ix1s5D1TELiwjA2TNqRXebFmmgHKslzwREs2w3r/eSI5RNc6f8Bi29Ea89KJBik+wLBlif4IviO umYXNrLtXsWzES2VkCgwIC8BARATIj3D+GkTiilOWWzArlaZi9jjJaYCTn+9nxyB3FARLqlw9ZJM 7UIhSCvVvRERbcxL3EGjTtk8xUzmFOukTG+Qal+gbrSS5Lq+q8+71DD0NkjVTyTNbKsjm1Ron/Di m4mSNSldTKPphBpwbuCnl6+ZSklwF2Rr8lCqXH1sAjgCEbN5lB86SmVPnP4pcGmIv+DZmPGOBJVQ Tk+ogVioAdCGH2MMJST6C88hwVllielTYq0OoK/p5dhAtS5R0oipXSLBcKYwkrHUnFzCrhChCTg+ s8TTU5X+HlordR8MSXBsXBfmqHGgXDegXuGIsZaZn5ZHWi5XLMBFJlUfSom62PWKgPXJW6Qg+o8y JfALZ+IYBjVoDFZ9qkijrJBOTUtrpx1mCXy4KazG+iQ/eIArp8fGkTUv3+SftxGT1wkFft42DR0F e+kOSwI34MBhdoPU9NzwFMXPuvFc5yMgi8nomWlWWL7Cht6eHiVK7wuL7SQTQSEVBe6N2LCpMxDy ovyFlCJWCngvyVSn5SV1OH6iu73MkP/lUQyRwN8gdbWJeq04rvRmzYL1VlFiUvekjWHdy6ah/XKi 8lbR361pYUjtiwfeklI7UfH95EODeZKBUt2q03KbLm+X6HLDeg8OwbtkrkLBruxEimQBUwtFCmpT licAjCz1n1StprnDoTfLOJ5rcJylAoW1BlVtAnYqkEoTlcpkYE6kiXajT8uLpYn4KSaRUzxnBpK2 ckamzyevMt/UeHVRLfjvf17yPzZ/5eTHjOdRrEr36gN7aH/vRlzPK43jSQ9lkeIpkYkm6qQfZ6yJ os22tJOSsb5rfTftEq8BQmQNPTre/qbZ3i3xiVi8fZcgxB+8lgSADxRGipJVq1dtn6X7ZSyDJcmS UHO64cMVIZaiSLPHYlt6OcQHkfSlVJ7w45H0lawZNLuZrGhaJNNsljdLyjLuzHIOXolgk89B+o1g QbWCGoMzwa4RZapdzSZm18uPpN/V8Vm7PJso2iXx7tw96ZN2r0jayYAHvBVFRmdj/IMSSZ3vdNUO 5kUrgnAjU6cqE8Vx2XRuUNNQGlJCLSGiVzw9TSpBecoflbwSN1JkM3qk9LtCShvb4v7BSXJvDJE9 4ZPkgHdIHYC6QHwT0zlALP1Z3UkM9y7/9Jj0TIkXgN9Le768TW9AKrkuTvrA5jScB84V57hz2/nB 2Sdeiq1fs/VVz/9+miNdr3oBpNU/B0ERyAp9G97bnK4GLxZrRau1xeijxZL2J7KxHYslbe0swkmV 0ROBGTtol4vj3FHCEajybwaay00Wp3bRiGR7Q4+m33TRpJFUM/5FcwwDCGoOYyUfnicdiqT0VGWy 1tryZ6VfHQxwub9bW95Usz3BZ+D3HzEum1+5YEoYwfdWxysIIhxQR1Qpe9TiTmvaImFVtmo2AgGp g3Q5OnzTwYF3AgZDDdFTajYwqIA5shAUNKzm/Ks9xbcsok3qZGXpPu5aESuTLo/mAD/hvYCbJjXO o+9wrJU1sv5bDxSrlWoFJ0ODQ3n/wSlrsj5liSOeuJbt8y4XywWytrbzQww9lwxMyHKxtqO15cG1 qy8Cyxc/H7/TuNpoNB61tpzeffxWYK3i59Ffjtw/e2hujsVebeSnN+Kdr3rEeZZXzt2KBKaUKHIC +cm2eNI8emcrwmQ4mNVmWiwIkhFAVmS6bTE6ch35rW4cTcqdGiL2RkS2MV44TMhUgC/w8A64bsv8 6GMrDkp7Rtu8dd1fL8ywNnhVi+BBGXFeCBzThtrBdjCUUXPerpSqly34HoV0T3PzdCsv9pzPevsQ BK4o9gyqbuaV7GB91QpZVFtFiYNRb9IFKiiIzSVwYatY7qYnJN6EB5hvb/yvOOmnhdlcvdzGUzFm JbnYlST5Rmbs8PL2fZoNIRra1CoFVOmrsUDRvj9E4m961fPsk68PX0mvhMyIm4xrlQeeHthz8M6R 04f58jrxjwPXjn94+n9bW07cOPrr/IW5cwcWWlvOHj//Cfv4+7P/Pvpza8sh58i7c5+evQnyuZNn Gxc+PbZ46JvWloPfsEN/m7/J6N/T78/fnL9AHGf2EtU8O+TQr9Pvz507fO2P6LqNr7rr6BP/88n5 1paj/z1+tLXl2In5y5/8NHfyddElBxbmPmttOTd3Zu/Zm4f2t7bMnTt16uAdtn3y7Y+/n7984pfz v544e+yj18Odc/rpsc8OPD3zNfVl4/SPJ4/PX2Ynn5y4R+3cO3fv2OLrcyfPHT/3/rHdF86c//CP 6CIBCIo5Pv/8wE/s1C/HrnR0dLzKJ7FBNa2l1CQ9bN36DpYyjAGdLJleI4sMHdr0h/JJN10kQBnr YKjFoOebb23oEFkn+SS103x7YwfLjxjM6BUZnzmXgmuIpCGItyBl7UfnU+e0s/fek2YCerjz2PnA uUX/LTz9u7P/2UPnPSK+5DxoJqbX+Xnhi9vOEWfp9innY+eec4wI9zYT0oul1ayueneG4pr3NvP0 LueffUJvdTfI61LgdfY4J52DznnnMKmaP7PXblz64j3qAzISMmsi1PQ+OMrkhd+vfO1cpGYXf/y3 sxQho7f5+xekrz507kCXJZseHBGiTTQKQ+m0lhUpyJG7nR3s+Tu/vfDS99VMT877oDv0QRcX9jsf Pb3h7KcOuR3qPUlKX3Z73+fvPHngLN45w19mPxjZa08efPfOzeO/HaLNhhOviXLSV/7zqbOI3vr8 F2fx2cfOhSgJfeG9J87S/VvOIzR9ZY9zjrpwibT1x86csy9KTt/6+ZFrp5zrzmJezfZp+SgBfS5C kPRMO+tXEwMsboxGSTZ3cNQmpiJ1SKNBWIamq4ONGFkiSmT1tMZm1bgxBA4OW4CqHmwkaRB5jq7l RnREGGdno410d7Ab79Ko3nGO0Rh/sPgVTefzzp0I2fp1HSyOYomMtlw+xi4B14oxVGoHgwNJiY9q LD0q3lrPaLlclDDOO/PKvVv3bjuLNF4XIgQxlY/6vl8/pIXgT2F5m/idQ87PdGuB2jkWeFmPZAO1 8I+vbn39427ncxJB0bvUwO2LS2echfuPaC1ecj5yzkdINlID976gjqDH33/PWaKpt7eZiNrpgbaU NYZyDCcCfcl8hGYTNYQqC6NMzaZXJKKGnl0VfZHIjkbuduJjjtJ0o3dp6qvNdBOjRreae2oztXvr e5IIBy8fd87Swol+QVfcnWSQoP6S9W53023SiS81Hjb2hG+tX6d2iPV1fVH0UvQ+sT7/9rfvnQVv KowKGRqhw2TwJ7Z3lc8Ad4hpff3dWVj4llbeorMQIcRAkzy7RCJh6dJjknnnqSNON70NRhzHhIwW Sd7guEUhKeTRYUQRnDlKM/lPkXsYpLymZdQ+bVleDFPjSOMH6i6y4Eke3qEvWHxxnb/7LedEhBxj c+PzS+chzv5z0bkSud1Frd194SwtXG2eeOu76SZPouCCOadpLPqyGLkrL0i+X7575tI/l1tlsXVi 5ix8+4R32UfUidjEHkSXS2ydWK9Ld2+v1L8xrP1n+5wPfv3GeXjzN5qqjy4dda5Hiaidh/POXpK1 S3f20cKLfFYMo/79kYfz0cvEpwv8JpbS8jQ0EQJMApplcTVO48ZF1O79zmX6oju0CXzw4ACJCFrh u/dH2eIdYq/Sc9RmJiLPYhABd7+kNi7QRG+a4LGNcdYxrGfyNB0id7DkH+6+sddZbDxSGj82Pm1c fP4dxFSUDmLo8FWaJJefOAtf/cC7/zv0bnSaxzC37v6L2tjb+KyxZ/baFWr7auNW43HjYYRysyuF STAFF9XarDa8VojyNvbm6Gifu7l+/oJGlOsYN76U2/qKDLTFPnjkLDzajR0iQLwFQBqkQmA6bnVb pgVwwjnw/D6+5qvF1cmp3caVxt7GVaXx6Nf9zoe3vqG3WpWDtuzApdUoN4q95NpB52/UtQ/FxzqP v7vs7P3vz/C2rca86aXSpYmFdvYv3vvqXWfh/07R+t+3Gint8Hp7GttDZDttouz6HeKwianble1x 2oY1TPOXPgd7/LWb9IQHYuMNyYwtfHNnTbu7N+Av3ftXbSC2ik6wKiPNhH9dwCJ6cP3hvt/LRJPC SP6J9NE+UpEgN34vI02I+89JIjRNg9WYaEro+XboYOGdbgtyV2hL8npwVYUjREy9RTpuw/ngSyjH 551HKxFu8PekZXWdEPFGPtsXbx64fY7k0JK3s4fHIshAvfHbaS4df3D2OQsPPqP1BfG1uBJD5+oK U4h286paXogUanByNLAlpjR1mG/2aios2ENs3WLOXX+2ah9iUWDbIg15MWOQUp3qk3ZXEy2NYs6g LyOVP6llg1RGUsyMYTnc/pVV6Gik88YgQzFULb8KHQ30ivpYlNYVibcPO8cw4BfxR1hLjnJsWknw R+g6+ZgtUq/+f23X+tTEsu2/U8X/0H64daHqQjmZ8Po4wACzk8xw89gcPOeW/8n+XyLIxWlUvLo3 oCJwfICiAXy/TnTz2AIBUfG41aNV97d6EjIJ05NJ5FRttsms9Vsz3b1Wr7W613QW3/xmn/til6QS XgiaA5GpGNEoAq+YHuv07TUMtNEjRrjXQCrJEjEj6td7GOFHmfuXkNNd83sKGuL8PL+IqGm73LiT FrwphQniXDTKYLXBwijCCw8z/gh+fp/fDgQKHUTsM+X+R4pRD8WW8uhSLiWcD3h+gcrv2JfR2Md2 5tvH9Yf4DNW5m3dwvwQS1iJsWfytfX+6gabQWJ8PhIWe4BG2A/G2SQJhOQJa8vDeHw8D8XZQpELJ bxBu0hMvWiCsImabMXTyaLl9SjFQlULm5rgcpLMunAj6OqO6SaFfImUiVEtgVj2YYSThfWARuP3m RwxrjqKlwChVkpH6o8KyYfZFtQSJO3wltFbIz/3RbUFcpq+Edpkj8EVJJzY/FKlvhTjbF674ZZ3+ 0FCl6MYXrR4OBZpY3u26hbgXjQo24L0MdJg1JF1zOsyr+q4fHeYnh3vfXqBslOIlX96Wg8zGl621 ubCqQudpGZgzymLLQwhS1WHMJbxkreGvRQMv9Ji3yZfx0Zq6riUs04enZCJgDZ1NZavMXphwJXMs 43dlaCIUnbUv2Ld9+Fsla2nlfOgtOttJN2m9qFTLyjhhwGQPtOyAiKQB/0LT/JrYQSEPUutkeepa ykfWujO0s0I2XuAqJu7UsYWVDTQ+i5TNpbXFfF3Yy6/C4gpr51k7Wzje9uj3gJyf4riYmzx34/mV Nzf47F32b9sMMq24EbFYQotoBm79fnnv7otPu2fx8WUawzuCdp9jDa+ufT1Lw9HrnBadPK6wHnS+ RlUpDQjc0gjcZvgkH+KnGgHtMWg9XYt2pmJVA/5GI7PyLzvDLyJRv+MEksCc4jm+zF+z+jq+nD4D 6Bu+33iw21TdHWitZI+PIezMMj5BQSffhczXNYqjqdXevm4P81lI2eb7NcqB3fInwN/iQ4yv8C2e gZ85VaOwFhFW7/NVPsUg6jo/y4eK01u10lpdsXNG7NhsHyycVCsL08Lbv2N8C1wTfKhGSZg2tm/C F85jAM/y68dqFIPJZOPSm1GexeidtxdXl0SUd6E2aSJAyPJxvsjn+AYk3mb8Pt/FSNaoFiLofYt5 5yzG8g5/DZG5GiXR9t7CvSv2HaH088i3thhEDvOF2gQW+JpjaqqADrHelGZ2anH98BVh2074k6CM vFc3I4b71m5WMtIx3HuZb4nw4Lo9Z6+VDbKbH1b459LmZ+G9looNlLHD2D5OZm/amcy0jAUmpLTx B+jwBRkL7KLwBW6LOoXFjL80ytih+i/szPD3s2Lt+ZBSuFmh253o92H+pCTgOcTXQcsKT4fspa1l x5NJGEkvaU2hMKXK2Cgdf4UmL6XPSFgKH9yjrorQG5FU0ojpCejNFn+MCXubiSa85pcbg3MKLXG6 nWH0d8iG3I8SRAIpzwIIw0zr1QwzPXKsWgm0WjACpd+nKeGPz66Nv8AioGL9Vj+6fJhWse3NavEt nvFTYDh0cz/3bsLO/DGf5V+vsqbVM5ufW9bufnn+7F5TtcKguWIuwFxRdVdCleG+z5Nf448ZaVap QQWRATWnvXg6GR1x38/VdgZpv2I/p8DBzmipXoipVgKUUtlYheFO0XIVz7Gm/iiid93ZCRWraOjV +rqqpDoMbksKMzpJkVGhARDgT58pKOLtxkBMwn6+jOBJT+H7LP5KNLcCNpRf34rSL5vFqwCKTQQE B5Qt8SpwYSccoLWs73tV4GAd+Q2o8vXGIGjKYb4+X0QnjUEp5kvn4QrYNifNpb05O/Nm7U41T90u AilMKhQdYIC2q8DCBuCtCbdVGgL440j3xWY769Ki0SpwSt5FjsGt7Ngz8KbwV/xlqWPwl0E0Irk1 vIVS025di4MflpQeQvdTcFGJLvQ6qUf1/j4t2VcSycohoeKqNH9BMT4ig+v8fDAw+YDzCMjJ4qeY d0whR0OxE5gUzC5dlIa41qYqAKHZ9IPcMc2IBgNAmTVa/Hfl+RUQUGHl+PH/IN+wsxIM0u7YN9o/ wR8Gg3QIyALCjgzC4Q0xH00FgopKqahhRoJxK2KUt6GpC/aI42AOx21SeGyQrrpVtFWc7K2zXiMe BfcLZItwfEDQZJFrDMj2N6e+sli3g1Bg096lMI01iAIDUx9IMFrRoTPkzJKwsaLskKgrmuG0h7m1 8x1yR6rCU9Y6jVmM26vHaFVrWHyqSgQlrGVXq8LTwtMrsSZJty8ttgwmAZq/dX/vCWV/pZpVEXlg AVs5e2xx2q7uyWkan8W1deRkmOjSz/IzX8NPKQx2eQpQUVyHswRONSwv35d7skposhU6+yEpjmSv Cgn9/Dr18im6fd++Zb8QCYQo7ahGiqC6rafNeZz/NFmnQUEEQFPkEoRZnub7gD7gM+kzjVUDnNRg gq/xPbo3zef24t7Fb6fdz1uFtBC1374iQvQ5e9neX87Yw6/HapQGixLTS9kySxUSwmKPOLMy+uG0 PVejDBhVYStF7HtdsGdqlEQ70VP2JfydKzWPKmTAzELH31Iwuiy2d2fKc94qZLWL/flXdubd7tvh GmV0iDZdtCderq6M1iZDrPAM84925tF4jRKUfLnwU4zPTfs84rkp8EyAs8a+EXxuG2xH+NBrIOBj MUsU2LEuK9avmYPC+U3SW1pA0+Q1I1ZTN/CNIzpa4Ysuw/wxKcJabRs++Vx93bfT0AHPCOpHbwIj /sdm5rKdqa9bWhbvftI+1yIMeu8ob0P+kmN+nKiv45f4gv0Bs+Vmqc/90VuEKW/L/gmR9XVHJpQW ggW1vs6hH+UTtxZ2FevrsrP2vL26kROFQK9ENRO37xzlzTCX7N6iEqL6OlFvcMdVvXckN2gXbpjb +/V19rOjFEyzzjpE36uvO33hCAUXi27wxItOsiaKI3Jrc0d5G0VkJOmzCU2cQ0q1FYkjlJ8Hu+ev DkiMxaxkn5AgtjEa/WhirhHbCg/5Lcjexwy5y58gbWsoboN4bxx5i6OisZSeoKKSpFG6Su0NoGTx AeXH/4UkXfxDtJeVgWExSU6KEGTd3qcalgEt2UVvU7Hkz5XxhQrC2dIVRm/mVqGJv4pIj4oATomS 3uHKQBjf57mV0WPO/yvzt1NR0MaovUqZH/p9CkP+Arl0WfLtDYa9rG3Dui/a1z5csHNORmf/gWce rQgmm6BjDCsy5i+5tE45XlgsGHt6BaNxi27pR3M8nKgZFDOSOHjAdWMJKER58c4KLs9BYbkIjGZL llUkQJUqBross5v1xLWSWF8CCIuX2Si3eoP5+HF6pDKEynOdkoxh5IcLGIOFyqDW4pLYl2v22KNM ScAoAbUdrM1knPqGg016HxD06uAlilyJxksAHWIxdPHTkKium7G3KkJcpYyuy6wh1c8sU7wkGbes HlZWieEjD0oidmeGxUhfrgjQTC3p3lRTFOSqjA6cSbAGfOLTEDNenBGldEc/z0PwA3TWYvrUQe1b BRgtm93GeN4BjHZ7uVMb4SoMqSBAlPesP7Qz2TcH70RUgEBXc5tU0yTSUe6oREkM5wNuEUtNY7TD 9XIUD5xbzd15HQza6rwxg7RiIRgAevvuX7iH6JLn9kY2aAuhu7nzAO7Yt9IjVObiVCp6KZJcSMdB IZTI2rM3vmxDZOnCiRzu0u3Zki1uP4i46tbHEDMtTKkRnTXQKDfKrgv9+/p1dxPR8g37/IZ79vZg htYN6N3d5Pg69WiU2Rn29eqLcX8QNI1+KZYZTIuxJlKhs+TR1ubsJXy+IKa/YbjVJn8x0L4Xp+0P v5/B1Lfsz0oR9RYywOWS5S4PRmhW9rHYovhg/w4zzOHBfrcXmT8K6kWnbLnepfZkgzIVS3T8WaEy 35/Zw+srdubZPV9WUo+9hWff8q/4zPszY3CfkKPYElshi/bSP/fLFfEwKFQwN/EWzjyGrKiP9qLz qiX6yH+4TIu+uVVSpZq3hGkN9ERBSUguC4VUWn4fFRPTU/c9DnHiQf+8uvHIzuxs7ez6cqoHNkX1 3zP3PvlyQ9NCrWvk+Sf5/0KRJpp82emdb23QMrW45ssHZbv7ZW/aeQebVhd8uakS4SUcUpY/4lv+ D0BrnWdJ4UXxwNZhxTiEgL5t2yujyAenbF4sGvVkJo0z2AC9vNBjRaPWgKjoq4DBIPaAFfOmLxuV fr9DP9+G353y4zRM+pJXp2cPnl38usQOSuP69S5Di0oJpFIOJX8HGVsIbPTiu1N+W4FZbUafryFa nuN7TWjA2N6EvQ3zuuIyMBk23MwziLZ30kP2HfwN0xu36TPFlyxluJbmfKBNL49lnFq0ywdVcTJU azNUaIhv8hy/bWe+jFRgb2t2DiPg85DOac2rAqC9WWw7TYmlw5w/82AqVpgUtvf/yH787cmO6yON VOFzXk6RFGpe/7/1988nd1Y2Xh8iqvkRbnq/tbS8kT1EDzevv3/7cu373pNDpJZmWo0tvzw4+N/5 dPffUUDq/NqmOBdwJn1paTI7e/fqPJt7PDcy/pZdX5mc+23/iOtI/xo73vY/zDn3KIpY5iQ+oktF qz1pqg8t7ENr8aG1+tDafGjtPrQOOQ0zl5ym+NB8+kXx6RfFp+2KT9sVn7YrPm1XfNoe8ml7yKft IZ+2h3zaHjESekRONn1IzkdYRVc8pUeZuJCgLC5hJILAemhDTxx5QJlfzLLMBi2RimiNNYJjRkJL WoHQJzQzYkVSzNRYUjcTfQaFQUndOKEHQVMMwJ/KOZNNMsXIP/Vg8amb4rohZ47pSUtCHbQiWizl JvZo0S4rdvK44nUx5HVR9boY9rrY4nWx1etim9fFdq+LHR4XS02/cNGrRYpXixSvFileLVK8WqR4 tUjxapHi1SLFq0WlBt2TgrL1GmwwlcL/G8RJhV1JhFvsZ0us8uoxOF49QQXBmpG0hIqSbmoRjX5m vhY5RjyFyM9EGmckaEcZ32uSI16E9WnMgIU7HFwcsOLRblHXDLzZTT++UT22T+un4zYLGZsXFP3U lTSE+Wtlc0c5Y58WSSGqScVTDIQIvvlyW0mrD43348EIWTR70CmSzjDF8LgN9HPqjTXgErhf0hcY 1XvpLTSrR0wgidQJLWL58ffHrajVm6JTrDotK1IA9lBlZR+9h04HaPVa3Qk/IXHkhGbS6ArQxQnd MDCWsVQc7fFl7Eul4ppxzMHEcZnGhA7MxVf844sVzQ7Oj97VihUcEh4rYsT0iHAE3Ra8UEI3K4+j J6ryKA6QNSd1qIHWp53w1cIBwzQL1aJeHPkAvaHQiV2wdNrQhnytK0I2ZIpDNHr1JNMG6G3gWuXQ eSt63NcWy4TkZRRFFLTRLUFsUbGIeJWOxbVBKufqYw2deiIpFs2E3jayUq8WFBSqHlTqFD0xFRlO diY6aWJKpJhOqoG+iBhBUTQzxQ2KbCK03wfFoiCtD3pGehzTgsoxkhRMkRBtsGyq84NFDJglg7cw NdiwFvixo1oT/uscxMdBLaHRBJuiR4dJJPWgQgZTJ1LirtDa3iD39h5TK5FUIe3am8uT8/fZ1U/s 2udLf2dX7898bk7WIC/gYzgXDx4CM26JZjUn/5KsRQpcUK9hwhe7JP2gnBRcCEhdkR+SQ78qALed 6jYsfzmWYw2098J6NUaeDzrB4Ij1ZAB1zsMpdtGqsicH2KX3GHGL/dJz4pcgkKSKNJ9cBtwTbIAO h/bUpIaU2R9N9epB5IWo5FhscMX0BivehRQJPRr4cVQ2+W52evwtm/1285814MNsITt9Iyh3CzPM ZNzqTomwCo2ffzp9k129OjE1fTmojNZyGeOfIWP2zKW1oBLayiXMjEOCOIj2VvDnaGczO3PD7MKT yXPju2zh/eTc7OREpoYu7Ch/HHXyNzzP/KPrVwOKUI4zAZl9Pp6+uU4NSk9mJzK//hoUr3hqYdVN UUJIP2FLJjmZiE6LfE3s4pXZpZk0HVGcu7DaoHXBcyParyiNzKtbBLIws6jeE+gRCAQ7QGfqjLxa YNBP9NyWyN57tSTNA51WPJhry0soWmFgCAU2SNcTlkid4B07kUxVga7Sn1k/a+S6SdeCMkcMsz9Y JzjsyAUDP0hM+8kw43okBYce+A5VNTWhGYNVPH2CUjiREaPZVhKhErIm2ttI6rH+0rUfK05rJSdN 66RStiZSQglJKaqUEpZSWqSUVimlTUppl1I6ZBRF2lJF2lJF2lJF2lJF0tJQ2RJOCUWRUkIyiiXF WHKMKqWEpRRpe6xWKaVNSmmXUiQjp0p1VJXqqCrVUVWqo6pUR1WpjqpSHVWlOqpKdVSVaogq1RBV qiGqVHtVqfaqUu0NS0chLB2FsHQUwtJRCEtHISwdhbB0FMLSUQhLRyEsHYWw9yhM35yZnbgy9wkh ywYm4n88+jZGZcilR6qHCiBgYprX3OsmhGQEVUYIywgtnoSQ7OYh2c1DspuHZDcP+dy8VUZokxHa ZYQOCaF0FN0E75arsi5RZV2iyrpElXWJKusSVdYlqqxLVFmXhGXtCMvaEZa1IyxrR1jWjrCsHWFZ O8I+7cgP7f8DUEsBAhYLFAACAAgAkgXqKmVqYr0oIwAAlU0AAAgAAAAAAAAAAAAgAICBAAAAALDU wNMuVFhUUEsBAhYLFAACAAgA4YXyKlBodMguBAAAwgcAAAwAAAAAAAAAAAAgAICBTiMAALG4wNS5 5rn9LlRYVFBLAQIWCxQAAgAIAIByhSl6+Ya5tiYAAGZPAAAMAAAAAAAAAAAAIACAgaYnAAC5rsGm x9iw4S50eHRQSwECFgsUAAIACAC1cIUpQtCCi6kAAADFAAAAEgAAAAAAAAAAACAAgIGGTgAAucLB 97rxtfC/wL3DtfAuVFhUUEsBAhYLFAACAAgAaojQKj1EDUw3PgAAZrUAAAwAAAAAAAAAAAAgAICB X08AALy6wM6/tcitLnR4dFBLAQIWCxQAAgAIADAO6irG4zSmHj8AAHHtAAAOAAAAAAAAAAAAIACA gcCNAADAr8a/x6659sGvLnR4dFBLAQIWCxQAAgAIAA93iir5r8MCppwAAH62AQAMAAAAAAAAAAAA IACAgQrNAABNUDMguPDAvS50eHRQSwUGAAAAAAcABwCaAQAA2mkBAAAA --==SoftForum-WebMail-1.0-32BF5B923B738D40==-- From jefferyspeed@lycos.com Fri Aug 10 22:34:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15VXb5-0000DS-00 for ; Sat, 11 Aug 2001 14:10:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Sat, 11 Aug 2001 14:10:31 +0200 (CEST) Received: (qmail 31598 invoked by uid 0); 10 Aug 2001 20:45:24 -0000 Received: from n35.groups.yahoo.com (216.115.96.85) by mx0.gmx.net (mx021-rz3) with SMTP; 10 Aug 2001 20:45:24 -0000 X-eGroups-Return: sentto-1101623-3089-997476322-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.54] by mu.egroups.com with NNFMP; 10 Aug 2001 20:45:23 -0000 X-Sender: jefferyspeed@lycos.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 10 Aug 2001 20:45:22 -0000 Received: (qmail 34967 invoked from network); 10 Aug 2001 20:45:21 -0000 Received: from unknown (10.1.10.26) by l8.egroups.com with QMQP; 10 Aug 2001 20:45:21 -0000 Received: from unknown (HELO mail2.kc.rr.com) (24.94.163.49) by mta1 with SMTP; 10 Aug 2001 20:45:20 -0000 Received: from rr.com ([65.26.130.34]) by mail2.kc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 10 Aug 2001 15:42:44 -0500 Message-ID: <2877420018510203455900@rr.com> X-EM-Version: 5, 0, 0, 18 X-EM-Registration: #01B0530810E603002D00 To: "1" From: "Gifts Alpha To Omega" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Fri, 10 Aug 2001 15:34:55 -0500 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] Safe Away for Shopping on Internet Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N Alpha To Omega



Dear Friend,

I like you to visit a site that is operated by one person, so I can

put the saving back into your pocket. I invite you to visit my site.

Alpha to Omega Gifts,the place for unique, high quality gifts and

collectibles for your friends and family. save 10% and a free gifts

http://www.alphatoomga.com



NOTE: Your e-mail address was on a MLM list, If you did not add to this list, please forgive me for this  e-mail.

Sincerely
Alpha to Omega
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From whygee@f-cpu.org Wed Aug 8 23:25:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15VhiU-0002jE-00 for ; Sun, 12 Aug 2001 00:58:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Sun, 12 Aug 2001 00:58:50 +0200 (CEST) Received: (qmail 23192 invoked by uid 0); 11 Aug 2001 17:07:02 -0000 Received: from n19.groups.yahoo.com (216.115.96.69) by mx0.gmx.net (mx17) with SMTP; 11 Aug 2001 17:07:02 -0000 X-eGroups-Return: sentto-1101623-3090-997549620-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.56] by mw.egroups.com with NNFMP; 11 Aug 2001 17:07:01 -0000 X-Sender: whygee@bocal.cs.univ-paris8.fr X-Apparently-To: f-cpu@yahoogroups.com Received: (EGP: mail-7_3_1); 11 Aug 2001 17:06:59 -0000 Received: (qmail 80311 invoked from network); 11 Aug 2001 17:06:58 -0000 Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 11 Aug 2001 17:06:58 -0000 Received: from unknown (HELO inferno.cs.univ-paris8.fr) (193.54.153.250) by mta2 with SMTP; 11 Aug 2001 17:06:58 -0000 Received: from neptune.bocal.cs.univ-paris8.fr ([192.168.3.2]) by inferno.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15UaqK-0008WL-00 for f-cpu@yahoogroups.com; Wed, 08 Aug 2001 23:26:20 +0200 Received: from aqua.bocal.cs.univ-paris8.fr ([192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr with esmtp (Exim 3.16 #1) id 15UaqL-0000Z7-00 for f-cpu@yahoogroups.com; Wed, 08 Aug 2001 23:26:21 +0200 Received: (from whygee@localhost) by aqua.bocal.cs.univ-paris8.fr (8.8.8+Sun/8.8.8) id XAA01616 for f-cpu@yahoogroups.com; Wed, 8 Aug 2001 23:25:00 +0200 (MET DST) Message-Id: <200108082125.XAA01616@aqua.bocal.cs.univ-paris8.fr> From: Whygee MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Wed, 8 Aug 2001 23:25:00 +0200 (MET DST) Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The list has moved ... Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sloyment@gmx.net Status: R X-Status: N Hello,

This message is sent automatically every week to remember you that
the main f-cpu mailing has moved to
http://www.seul.org/archives/f-cpu/f-cpu/

To join the f-cpu mailing list, send an e-mail message to
majordomo@seul.org with no subject and a body of "subscribe f-cpu".

Due to the lack of manager (He disapeared 2 years ago !) and the
impossibility to administrate this YahooGroups list, we are forced
to move to a more friendly server.

Read you there,

whygee
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From enddebt5@arabia.com Sat Aug 11 23:13:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15WgKc-0006eU-01 for ; Tue, 14 Aug 2001 17:42:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Tue, 14 Aug 2001 17:42:14 +0200 (CEST) Received: (qmail 25676 invoked by uid 0); 13 Aug 2001 13:37:58 -0000 Received: from n23.groups.yahoo.com (216.115.96.73) by mx0.gmx.net (mx002-rz3) with SMTP; 13 Aug 2001 13:37:58 -0000 X-eGroups-Return: sentto-1101623-3091-997709877-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by ck.egroups.com with NNFMP; 13 Aug 2001 13:37:57 -0000 X-Sender: enddebt5@arabia.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 13 Aug 2001 13:37:56 -0000 Received: (qmail 29508 invoked from network); 13 Aug 2001 13:37:51 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 13 Aug 2001 13:37:51 -0000 Received: from unknown (HELO smtp.uservices.com) (204.142.171.2) by mta3 with SMTP; 13 Aug 2001 13:37:50 -0000 Received: from 65.44.237.26 [65.44.237.26] by smtp.uservices.com (SMTPD32-4.07) id A45D50E0C0E; Sat, 11 Aug 2001 17:32:13 EDT Message-ID: <00006dac0a0a$000043f7$00006c90@> To: X-Priority: 3 X-MSMail-Priority: Normal From: enddebt5@arabia.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Sat, 11 Aug 2001 14:13:59 -0700 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] GET FREE CABLE TV! Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R X-Status: N
NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV
DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION
PLEASE CLICK DELETE NOW. THANK YOU--

LEGAL CABLE TV DE-SCRAMBLER

Want to watch Sporting Events?--Movies?--Pay-Per-View??

*This is the Famous R-D-O Shack TV Descrambler
You can assemble it from R-D-O Shack parts for about $12 or $15.

We Send You:
E-Z To follow Assembly Instructions.
E-Z To read Original Drawings.
The Famous R-D-O Shack Parts List.

PLUS SOMETHING NEW YOU MUST HAVE!

Something you can't do without.

THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY



Warning: You should not build a TV Descrambler without
reading this report first.

Frequently Asked Questions--CABLE TV DESCRAMBLER

Q: Will the descrambler work on Fiber, TCI, Jarrod
and satellite systems?
A: The answer is YES. In respect to satellite,
you just get more stuff! There is one exception:
The descrambler will not work with DSS satellite.

Q: Do I need a converter box?
A: This plan works with or without a converter box.
Specific instructions are included in the plans for each!

Q: Can the cable company detect that I have the descrambler?
A: No, the signal descrambles right at the box and does
not move back through the line!

Q: Do I have to alter my existing cable system,
television or VCR?
A: The answer is no!

Q: Does this work with my remote control?
A: The answer is yes. The descrambler is
manually controlled--but very easy to use!

Q: Can you email me the plans?
A: No the program comes with an easy to follow picture guide.

Q: Does this work everywhere across the country?
A: Yes, every where in the USA plus England,
Brazil, Canada and other countries!

Q: When I order, when will I get my stuff?
A: We mail out all orders within 48 hours of receiving them.

YOU SUPPLY A SELF-ADDRESSED, STAMPED, #10 LONG ENVELOPE, WITH
TWO-FIRST CLASS STAMPS.


Q: How much does it cost to get the instruction
plans, the easy to follow diagram, and most
important of all the Using a Descrambler LEGALLY.

A: You get the complete package all for just--$10.00
(Cash, Check or Postal Money Order.)
(Arizona residents include 7% Arizona State Sales Tax)

(All orders outside the U.S.A. add $5.00)
ORDERS OUTSIDE THE US MUST BE IN THE FORM OF AN
INTERNATIONAL MONEY ORDER PAYABLE FROM A US BANK OR US CASH!
NO POSTAGE COUPONS ACCEPTED!
FOREIGN CHECKS WILL BE RETURNED!

Q: How do I order?
A: Fill out form below and send it, along with your payment
AND YOUR SELF ADDRESSED STAMPED (2 STAMPS) ENVELOPE to:

A Groves
PO BOX 8051
Mesa, AZ 85214-8051

MAKE CHECKS PAYABLE TO: A Groves
PRINT YOUR:
(orders without an envelope or stamps will be processed
up to 2 weeks later than complete orders)

Don't forget the 2 stamps and #10 long envelope!!!!
NAME_____________________________________________

ADDRESS__________________________________________

CITY/STATE/ZIP_____________________________________

Don't forget the 2 stamps and #10 long envelope!!!!




*A Groves is NOT ASSOCIATED in any way with RADIO SHACK.
Neither the design nor instructions were developed
by, are sold by, or are endorsed by Radio Shack.
Parts for this fine-tuning device are available
at many electronics stores (including Radio Shack)
This is not a Radio Shack product.



To be removed from our mailing list please
send an email to: remove2001@arabia.com









NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV

DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
From webinfo@msn.com Mon Aug 13 19:59:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15WgKk-0006eU-01 for ; Tue, 14 Aug 2001 17:42:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Tue, 14 Aug 2001 17:42:22 +0200 (CEST) Received: (qmail 11333 invoked by uid 0); 13 Aug 2001 22:00:01 -0000 Received: from n2.groups.yahoo.com (216.115.96.52) by mx0.gmx.net (mx21) with SMTP; 13 Aug 2001 22:00:01 -0000 X-eGroups-Return: sentto-1101623-3092-997739999-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.52] by hi.egroups.com with NNFMP; 13 Aug 2001 22:00:00 -0000 X-Sender: webinfo@msn.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 13 Aug 2001 21:59:58 -0000 Received: (qmail 62058 invoked from network); 13 Aug 2001 21:59:57 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 13 Aug 2001 21:59:57 -0000 Received: from unknown (HELO ntserver02.pi-schools.gr) (195.251.20.36) by mta2 with SMTP; 13 Aug 2001 21:59:56 -0000 Received: from plain (161.58.176.124 [161.58.176.124]) by ntserver02.pi-schools.gr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QBVY8KQ4; Tue, 14 Aug 2001 00:56:19 +0100 To: f-e-l@msn.com X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-eGroups-From: rogerwoods3276@runbox.com From: webinfo@msn.com MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Mon, 13 Aug 2001 17:59:50 Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] HELLO! Content-Type: text/plain; charset=DEFAULT_CHARSET Content-Transfer-Encoding: 8bit Message-ID: <20010813220002.11360gmx1@mx21.gmx.net> Status: R X-Status: N Urgent Message for f0xyr0xy, STOP! URGENT MESSAGE! PLEASE READ COMPLETELY! It is important that you read this message as soon as possible. Again I urge you to read this message to its fullest! Last year 72% of bankruptcies could have been saved by an extra $200 a month. We are an International E-Commerce Mail Order Company looking for people with a Good Work Ethic and the Desire to Earn $500 - $1,500 per Month Part Time or $2,000 - $7,500+ per Month Full Time Working From Home or Office! The demand for our product line (over 150 different products) is so great we need to train more people to process the orders and service the growing customer base. To better assist you in the understanding E-Commerce and what the world is raving about with E-Commerce and the Internet, I URGE you to read this message for your own training and understanding on what it can do for you. Everyone is excited about E-Commerce. We recently opened our business in India and with that we are trying to help as many people start and generate foreign and local business in India as fast as possible. As the Economy in India is tested, this opportunity right now is the fastest growing industry in India, Panama, Cyprus, Korea, China and Japan. This is a U.S. Based Company so it is very exciting to be growing by doubling and tripling in over 50 Countries right now. Expected growth in the next three years is 80 % in each country with new countries opening every day. We are expected to reach the world in the next 4 years and with that you can imagine the internet and E-Commerce is currently growing by 200 % each Quarter. There will be a 2000 % increase in E-Commerce Business and revenues on the Internet in the next 18 Months. No special skills or experience is required. We will give you all the training and personal support you will need to ensure your success. You will be trained via Internet in the comfort of your own home and you will determine your work hours. A minimum commitment of 7-10 hours a week is required. The income you generate from your efforts can put you back in Control of your Time, Your Finances and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, this is different than anything else you are aware of! This is not a get rich scheme. You must work to earn income! Your financial past does not have to be your financial future. "There is no security on this earth. There is only opportunity." -Douglas Macarthur Do you feel like you are too busy earning a living to make any real money? Are you tired of living "paycheck to paycheck" like I was? Do you dream of a better lifestyle for yourself and your family? If so, then I urge you to take read on to better understand why I sent you this message. We provide the system, experience and hands on training. The only thing that we can not give you, but is required is that you, number one have the desire and number two, is that you are teachable. We know that you have some level of desire because you are reading this letter. Ask yourself if you are teachable. Everyone evolved in our business had three things in common when they got started: They saw an opportunity, they were teachable, and they applied what they learned. It's THAT simple. And it's THAT powerful. ************************************* Now imagine just for a moment that you had a home-based business that provided Spending more time with your family, Unlimited income based on YOUR efforts, Freedom from commuting, Not having your kids in day care, Affordable health care for your family, Significantly helping others with their lives, Loving what you do and doing what you love, Having your own business/being your own boss Sounds too good to be true? That's what we thought, but today our dreams are coming true and now we're here to help you, like others have helped us! ********************************************** We like to get right to the point...so here is what we have to offer you: A well established, financially stable company, 2 Billion dollar + sales / publicly traded, Patented, exclusive, high demand consumable products, Comprehensive, high-tech in home training, Phenomenal support system, Worldwide income opportunities (especially through E-Commerce), Exotic paid vacations and Minimal start up investment. ARE YOU GETTING A BIT CURIOUS? GREAT! That's fine... as long as you're serious! Because our business is bursting at the seams, we ONLY have time to work with serious, motivated people who are ready to make changes in their life NOW! And because of the time we spend with each of you as we help you get your business off the ground, we have limited number of openings available. Here is what you need to do... This business fell into my lap in September of 1997. I got started as a customer and woke up when my wife made an extra $500 in the first week. At the time I was an Active Duty Marine living paycheck to paycheck making less that $19,000 a year. I was attending college at a local University and had two children. $500 at that time would have been a dream come true. I got started and in our first month I earned $2700 profit, and in the first four months my wife and I made $19,000 profit. I had made more in 4 months than I made in an entire year as an active duty Marine just part time working 10 - 12 hrs a week. The average person can start earning any where from $25.00 - $75.00 an hour from their home or office computers without dedicating allot of time and effort. Most of us have been thinking it's about time we took advantage of this Internet Craze. Through out the Holidays and especially the last year, every thing that we have seen on Television and heard on the Radio has either started or ended with www. -----------. Com and the reason why is because the Internet has truly simplified shopping, convenience which frees up more time for all of us to turn that time into quality time. Security and convenience has been technologically advanced to give us all the piece of mind. E-Commerce is so rampant right now that most of the states in the U.S. are buying their groceries over the Internet This is your opportunity to take advantage of the E-commerce that is literally changing the way the world does business. Internet Marketing Group will show you how you can work at home using your very own e-commerce storefront. Our opportunity is the only business of its kind right now. It's growing by leaps and bounds and you can be a part of it while you work at home. The Work at Home Network with our company was reviewed and published Wall Street Journal, Business Week, Home PC, Forbes, Success, and Money, just to name a few. You can work at home and use the Internet to run your business. You can market our high demand consumable products that are geared and driven by the needs of over eighty- percent of the world's population. Our products sell them selves, so there is no selling or need for out right sales techniques. Also because they are high demand consumable products, return business, on going business, and referral business is generated. By working at home, you reduce overhead, set your own schedule, be your own boss, and achieve your own goals. Be an entrepreneur, WORK AT HOME! The Market Opportunity is colossal. Over 1/2 of American homes have a computer, and E-Commerce sales are increasing month on month. America is looking for a better way to buy our products and now with this opportunity you can. The Work at Home Network a brand of e-commerce that is enabled and energized. The five top industries in the world are Medical - Health - Nutrition, Computer, Personal Care, Communication and the Burial Businesses due to the Baby Boomers. The Work at Home Network put them all into a package except for the Burial Business. Our industries are guaranteed to be the fastest growing industries for the next 18 years and each year sales have doubled almost tripled. If your country is listed here, you are eligible to start doing business immediately. (Argentina, India, Cyprus, Greece, Poland, Australia, Hong Kong, Russia, Austria, Indonesia, Portugal, Belgium, Israel, South Africa, Botswana, Italy, Spain, Brazil, Jamaica, Swaziland, Canada, Japan, Sweden, Chile, Korea, Switzerland, Czech Republic, Lesotho, Taiwan, Denmark, Mexico, Thailand, Dominican Republic, Namibia, Turkey, Finland, The Netherlands, United Kingdom, France, New Zealand, United States, Germany, Norway, Venezuela, Philippines, Ireland, Panama, Morocco, and China) However, if your country is not listed here, it does not mean we won't be there very soon. Because our company is expanding into several countries a year, yours could be the next one to become available. This is an optimal position to be in, one that you will definitely want to take advantage of. Due to the fact that countries can "open" only once in our industry, if you are one of the first to receive this valuable information and one of the first to start softening your market, you will belong to an exclusive group of wealthy leaders. Our experience in 50 countries confirms this fact. One of the strongest aspects of our business is the on going training that is offered. We have International Training's on an ongoing basis in most major cities. Weekly conference calls are also available, as well as satellite television training programs, monthly magazine's and quarterly journals. Our company does over 1.5 billion US Dollars in business annually and you too can be a part of this growth. Maybe some of you have tried other businesses and failed. We welcome you with open arms. Here you will find success because we give you the blueprint to follow and support you need to develop your own profitable home-based business. All we ask of you is to be coachable and be willing to learn. We have no need for tire-kickers or window shoppers. Please do not request our "decision package" if you are not serious about changing the course in your life right now. By ordering your "decision package", you will receive all you need to get yourself moving towards financial independence. So, if you are tired of worrying about money and tired of choosing what you can live without, come join the thousands of us working from home, setting our own schedules, making a fortune and living out our dreams. We invite you to explore how the "Work From Home" Internet Program capitalizes on today's advancements in technology to help you build a successful home-based business. Have you noticed the surge of people looking to start home-based businesses? Did you know that 32 million households now have home-based businesses and that number grows every day? Have you asked yourself, "Why?" Why are so many people, including yourself, interested in working from home? Our parents never searched for a business to operate from home nor did their friends. So, why now and why is it suddenly so popular? Americans are "cocooning". We want to spend less time on the busy freeways commuting, and in over-crowded shopping malls and replace that with spending more time at home with our families where it is warm and safe. Apparently, we trust society less and want to protect ourselves and our families from the "cruel" outside world. This is the wave of the future and we are beginning to realize with the advancement in technology, we do not need to be in an office environment in order to access the marketplace and make money. In today's world, the quickest way to build a home-based business is to take advantage of the Internet craze that has hit the United States and is quickly spreading around the world. Like how the Gutenberg Press radically changed the communication world in 16th Century Europe, the Internet is revolutionizing how we communicate, distribute information and the manner in how and where we spend our money. It has been said that those who pursue electronic commerce (business over the Internet) have the opportunity to build an explosive business. While a conventional business can cost thousands to hundreds of thousands of dollars to set up and run successfully, an Internet business costs dramatically less and has the potential to attract international business for just a fraction of what the traditional company would spend. On average, 30% of all U.S. web traffic is already international and 5% to 20% of all web sales originate from outside the United States. Everyday, these percentages are radically increasing. Consumers worldwide are spending 6.6 billion U.S. dollars a year in transactions over the Internet. The awareness level and need for users, buyers, advertisers and merchants to get onto the Web, and to set-up shop, has dramatically changed even from one year ago. This medium of doing business is skyrocketing, and we are reaping the benefits, daily. If you combine the Internet craze with people's desire to work from home and set their own schedule, you have a powerful team, and here is why. Many people have heard of SOHO, and no, we don't mean that hip section of New York City, rather the S.O.H.O. which refers to "Small Office/Home Office." One of today's biggest explosions in the economy. The home-based business has been born out of necessity. In an era where large corporations can only think of downsizing, what are your options? There is no security in Corporate America any more! Not only are tens of thousands of workers and managers being downsized out of their companies, but also thousands of men and women are tired of the corporate "rat race" and want to retreat to a home-based business. If you decide to "stick it out" in Corporate America or the Corporate World, your choices could boil down to finding a lucrative niche in the small business world, standing in line at the unemployment office, or accepting a cut in pay and benefits. We were all raised to give 9 hours work for 8 hours pay, and we are not backing away from that. Today's large companies have no loyalty to the employees. Their only loyalty is to the bottom line. And the bottom line is exactly where most of us are when it's time to cut back. Your life is suddenly turned upside down because you have no control over your future. Someone who has no idea of the quality of your work makes these decisions behind closed doors or the extra time you gave the company without requesting overtime. They don't know about your family's life: they don't understand that you just put braces on your child's teeth and now have to pay for them. These "decision makers" job is to be impersonal and unbiased in all areas except for the company's "best interests." In other words: TO THEM, YOU REALLY DON'T MATTER. The Great American Dream is gone. Official U.S. government reports indicate that more than 3.5 million jobs have been eliminated in the past 10 years - including over 2000 jobs per day last year alone - and an estimated 55% of all jobs created in the next 10 years will be near minimum wage in stores, restaurants, and bars. 90% of all the people in North America earn less than $40,000 a year and today's two-income family are not living as well as their parents did. So what is the alternative to the to the Great American Job? Richard Poe, former senior editor for "Success Magazine," describes in his recent book that a shift in thinking has resulted in over 14 million people working from home full-time, and another 13 million part-time. This number is increasing by almost 600,000 per year. And the average work from home income is $50,250 per year, about twice the average income of wage earners working for someone else. By the end of the decade over 44% of us will be working from home. Home based business wage earner's success rate is over 85% compared with small businesses like retail shops and restaurants, at about 95% failure rate after 5 years. Couple that with the flexibility we have to change our schedules and set our hours and then those of us who are parents are now available when our children need us, plus we no longer have the need for the "foster homes" we call day cares, where the care-givers get to see all the "firsts" your child performs. There's no wonder the number of people looking to work from home has skyrocketed. This "New Era" of financial growth is largely due to the latest technologies that are now available to those who desire to work from home. Imagine what it would be like to run an international operation if you so choose, right from the comfort of your own home. Well, this is exactly what we offer! We offer a "freedom" that is available through a constant flow of income that does not depend on the whims of a boss, bonuses or the economy. Take a look at some of these statistics: At age 50, 75% of the population has less than $5,000 in the bank for retirement. At age 65, 45% of Americans depend on relatives, 30% depend on charities, 23% are still working (most can't afford to quit and work until they are no longer physically capable) and Only 2% are self-sustaining. At the present time, it is impossible to support a family of two working full time at minimum wage! For the first time in history, the current generation is averaging a lower standard of living then their parents! Automation is taking layoffs to record highs! The Bureau of Labor Statistics says that Out of 100 people that start working at the age of 25, by the age of 65... - 1 is wealthy - 4 have enough money to retire - 63 depend on social security or charity - 29 are deceased 95% of people, age 65 and over cannot afford to retire and work until they die!! What Happened to Safety & Security? Why we no longer put our trust & faith in "Big Business". In J. Paul Getty's book "How To Get Rich", his first rule for success is, "You must be in business for yourself. You will never get rich working for someone else." This partly explains why someone starts a new home-based business in the United States every 10 seconds. In the past 14 years alone, the numbers of home-based businesses have grown >from 6 million to 32 million with no slow - down in sight. In fact, an estimated 8,493 new home businesses open every day. The United States is now driven by an information and service economy. Over the past decade, Fortune 500 companies have laid off 4.4 million workers while smaller companies steadily continue to reduce their work forces. As companies continue to downsize and re-organize, many professionals will seek out and search for new ways to take control of their careers. Many of these individuals have forsworn traditional "nine to five" office jobs and are making their homes pay off in more ways than one. For the entrepreneur, home-based businesses have become the bridge between work- crazed big cities and easy- paced family-oriented small towns. Link Resources Corp. reports that market research shows more than 29 million people run either full-time or part-time businesses from their homes. People used to believe that their livelihood depended on living in big cities near big corporations. That is no longer true, thanks to personal computers, increased phone services, fax machines, and the Internet, it is no longer necessary to live in close proximity to "Big Business". You can now operate that "Big Business" right from your home office. Within the last five to seven years, technology has been brought to an affordable level so that almost everyone has an equal playing field in the work-from-home industry. Check out these Statistics: 11% of the US market is now on the Internet 1,092,000 new people get Internet access each week, while approximately 38% of the US adult population, or 68 million US citizens' currently use the Internet, according to the fall 1999 Cyber Status reports from Mediamark Research Inc. This is an increase of 49% from the prior quarter, and this study only counts people who have used the Internet in the last 30 days. Ziff-Davis's Technology User Profile reported that there are 60 million PC's connected to the Internet in the US, but home PC's still represent the lion's share of the market, with 68 million consumers hooked up to the Internet. They predict that up to $54 billion US dollars will change hands from business transactions online by year 2001. Most people are ready to do some sort of business online, they just don't know where to start. This is why we are so successful. We link-up our marketing techniques with something people need, and most of all, something people want. If you add strong work ethics, a powerful support system, along with personal business coaching, you can't help but be successful. We provide not only the vehicle that puts you on the road to success, but we also provide the road map. All you have to do is be teachable, have the desire for a better life and be willing to change what you're doing now. 94% of home-based business owners are happier running their own business versus working for someone else. 92% recommend working from home to others. 94% plan to still be running their own business in five years. 20% of home entrepreneurs reported that their businesses grossed between $100,000 and $500,000 last year. 23% paid themselves annual salaries of $65,000 to $350,000. 41% work at home with other family members. 71% think their businesses are doing as well or better than they expected. 79% expect their home-based business revenues to grow this year. Your search for the ideal work environment and for the ideal vehicle to wealth is over. You will be able to work more flexible hours while increasing your productivity, not to mention drastically cutting your commute time, and increasing your most precious commodity-quality of life. We have developed one of the most exciting, technologically advanced home-based businesses that will take you through the new millennium. We don't expect you to come to us with tremendous business knowledge or a successful track record. We have already figured out how to make this work; all you need to do is copy what we're already doing. Since you've gotten this far, we know you are serious about working from home. Your next step will help you make some changes and learn some new skills. So, let's go! As you know, this is not a lay-on-the-couch, get-rich-quick scheme. This is a REAL business and a real opportunity- one that has drawn so much interest from people that we had to put this screening process in place to help us determine who to work with. Our company has been in business for 20 years, is publicly held and traded on the NASDAQ. It is important that you realize that we can help you build a powerful and profitable business. We have an explosive, start to finish, proven Internet Marketing system. And we are offering you this simple easy method where you can make money working for yourself, over the Internet, from the comfort of your home or office. You can earn $1,000 to $7,000 per month working around your current job and your family's schedule. Our system works regardless of your background or computer knowledge. We provide the system, experience and hands on training. The only thing that we cannot give you, but is required is that you have the desire, and that you are teachable. We know that you have some level of desire because you got this far. Are you teachable? ARE YOU TIRED OF MAKING YOUR BOSS RICH? Start your own business NOW! I will help you! Become financially Independent using our proven system! Learn to TRULY succeed working from HOME with our TURN-KEY system I CAN SHOW YOU AN OPPORTUNITY THAT IS NOTHING SHORT OF A MIRACLE Does that sound like something you would be interested in? Are you.... Tired of working for someone else to make THEIR dream come true? Would you like to start Right Away with a SIMPLE system. Work with some of Americas TOP entrepreneurs! Use an advanced DUPLICATABLE system to quickly build your business. You must be at least 18 and have a serious desire for personal success Take a moment right now to take the next step below: STEP 1. You must call our toll free "International Internet Business hotline and listen to some of the members of our team talk about the success of their new home based businesses. EVEN IF YOU ARE CALLING THIS NUMBER FROM AN INTERNATIONAL COUTRY, I URGE YOU TO CALL RIGHT NOW. This is part of our job-to introduce you to many others who took a step of faith (like you're ready to), and whose lives have changed because of it. This call is for everyone. I.E. former Military Service Members, Executive Professionals and Laborers Doctors and Nurses 1-800-708-RICH and enter Access Code 7228 or 5050. Also to Learn about our industry and company dial 1-800-555-1795 and enter Access Code 7228 or 5050. This 10-minute calls is a 24-hour toll free for all that are in the United States; however if you are International I urge you to dial this number now and listen to this short message and take some notes. ********************************************** CAUTION! This Access Code expires on August 25th 2001 (So call right now!) ********************************************** IMPORTANT! DO NOT PROCEED TO STEP 2 UNTIL YOU HAVE LISTENED TO THE CALL MENTIONED IN STEP 1 ********************************************** If you are unsure and need more information, we have put together a "How to do business over the Internet" decision package that will help you determine whether our business is for you or not. This step is only for individuals who have the desire to control their own future and who want to work from their homes and earn the kind of income that will give you the life you deserve. This decision package contains approximately three hours of information about our explosive Internet business and it also begins your training. You will receive a manual that explains how, why and what we are doing, a video where you'll meet us and see exactly how our business works and an audiotape to further help you with your decision. Your package also contains the name and telephone number of your personal coach who will be working with you on a daily basis, helping you make money in your first week. In other words, you will receive all of the information you will need to make a decision to determine if this is for you. After you request your "International Decision Package", and go through all the materials, we will call you and your personal training program will begin. At that point, we will also be happy to locate the nearest training to you, which are available in numerous translations. We have training being conducted in over 27 different languages worldwide! This package acts only as a way for you to review information about our business and begins your training without risk. This step eliminates the people who are not serious and allows us to work with those of you who are. Please recognize the importance of this step. We simply do not have the time to spend with people who are merely curious, which is why we designed this package to provide you with all of the information you will need to make a decision and determine if this is for you. If we spent our time answering e-mail requests for additional information, we'd not only be duplicating the effort we put into developing the decision package, but we'd also be taking valuable time away from running our business and training new people. Once you start working with us, we're sure you will appreciate our spending time training you instead of responding to curious e-mails all day long. Since we don't spend countless hours answering the tireless questions of the curiosity-seekers, you benefit, because it frees us up in order to dedicate ourselves to your success. When we spend time with you, we know we are working with someone who, like us, is committed to a better lifestyle. What is Your Future Worth? Decide for yourself and for your family what it is you want and by when you want to achieve it. Only you can determine how dedicated you are to achieving your dreams. Hopefully, you won't find yourself relying on your friends and family for direction and salvation. They cannot provide that for you - only you can do that. You need to make a decision to either give this a shot or to continue down the path you're on. Most likely, if you have read this far, you have already made the decision to make some healthy changes in your life. When we were looking at this "Work From Home" Opportunity for the first time, just like you, we were nervous and thought that maybe this wouldn't work. Like you, we doubted we could really achieve our dreams. We went for it any way and now we are making incredible incomes, working from home, and for most of us- it's a dream come true. We don't have a boss to answer to or a clock to punch. All you need to do now is take action. Take action by ordering your "Decision Package" and we'll be there to help you through your questions and then to work with you to build your own "Work >From Home" Internet Business. But please don't request more information unless you are committed to improving your life. If you are ready to learn and you are serious about achieving a brighter future and a better life, then we are committed to you. We are ready to give you the same step-by-step plan we used to build our fortune. There will be no surprises. We know exactly what to do and how to coach others be successful within the same system. Our Program works. It's already happening for hundreds of people. Why not you? Right now, take the next step, and get started on your way to a brighter lifestyle. STEP 2: To get started or request your decision package only after you have completed STEP 1 please call our international 24 hour order hotline at 1-206-222-2829. International callers and for United States, Canada, and Mexico callers please also dial 1-206-222-2829. We are willing to train you and work with you, as others have done with us, to help secure your financial future. But, remember, we only work with those that truly have the desire and ambitions to work-we don't have time to work with couch potatoes! Successful people do what unsuccessful people won't. So develop a sense of urgency and give your desires value! Procrastination is the biggest killer of success and you can now break that cycle! REMEMBER, for things to change, you have to change and for things to get better, you have to get better. Order your materials today, and when they arrive, review everything thoroughly BEFORE calling your personal coach. Remember the importance of following directions- we are looking for people who are teachable and willing to work. We're very excited about our future and we know you will be, too!! Until we speak personally, thank you and have a great day! Again please follow STEP 2: To get started or request your decision package only after you have completed STEP 1 please call our international 24 hour order hotline at 1-206-222-2829. International callers and for United States, Canada, and Mexico callers please also dial 1-206-222-2829. © 2001 all rights reserved. This message is an advertisement sent to you with support and concent of an independent marketing company. (POSTMASTERDIRECT Inc.) Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From news_4693+377250.172610729.3@reply.tm0.com Wed Aug 15 03:23:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15Wpku-0002ZM-00 for ; Wed, 15 Aug 2001 03:46:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 03:46:00 +0200 (CEST) Received: (qmail 9420 invoked by uid 0); 15 Aug 2001 01:28:06 -0000 Received: from n21.groups.yahoo.com (216.115.96.71) by mx0.gmx.net (mx013-rz3) with SMTP; 15 Aug 2001 01:28:06 -0000 X-eGroups-Return: sentto-1101623-3093-997838884-sloyment=gmx.net@returns.onelist.com Received: from [10.1.4.53] by ci.egroups.com with NNFMP; 15 Aug 2001 01:28:05 -0000 X-Sender: ann4693-errors+377250+f-cpu+egroups.com@bounce.lodo.exactis.com X-Apparently-To: f-cpu@egroups.com Received: (EGP: mail-7_3_1); 15 Aug 2001 01:28:04 -0000 Received: (qmail 39650 invoked from network); 15 Aug 2001 01:28:03 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 15 Aug 2001 01:28:03 -0000 Received: from unknown (HELO sender21.lodo.exactis.com) (64.208.135.34) by mta2 with SMTP; 15 Aug 2001 01:28:01 -0000 Received: by sender21.lodo.exactis.com (queueup version 6.1: Copyright 2000 24/7 Media, Inc. All rights reserved.) with stdio id EGROUPSAACDG16163; Tue, 14 Aug 2001 19:23:23 MDT To: f-cpu@yahoogroups.com Errors-To: ann4693-errors+377250+f-cpu+egroups.com@bounce.lodo.exactis.com Priority: normal Message-Id: <5.1437.5.0.0.16163.997838603@sender21.lodo.exactis.com> X-Mailer: Experian InformMessaging Build v1.25 From: "News From Michael Jackson" MIME-Version: 1.0 Mailing-List: list f-cpu@yahoogroups.com; contact f-cpu-owner@yahoogroups.com Delivered-To: mailing list f-cpu@yahoogroups.com Precedence: bulk List-Unsubscribe: Date: Tue, 14 Aug 2001 19:23:23 MDT Reply-To: f-cpu@yahoogroups.com Subject: [f-cpu] The Latest News from the King of Pop! Content-Type: multipart/alternative; boundary="_----__Experian__----_" Status: R X-Status: N --_----__Experian__----_ Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" This mailing is based on your providing opt-in/subscriber requests to receive this kind of information from one of our associated=20 websites. ------------------------------------ Great news from the King of Pop! Michael Jackson reaches out to his global fan community: Derni=E8res nouvelles du Roi de la Pop! Michael Jackson plus que jamais proche de ses fans du monde entier: Brandhei=DFe News vom King of Pop! Michael Jackson geht interaktiv auf seine Fans zu: =A1Informaciones exclusivas del Rey del Pop! Michael Jackson se aproximara a todos sus aficionados del mundo: http://tm0.com/4693/sbct.cgi?s=3D172610729&i=3D377250&d=3D1645823 ----------------------------- If you no longer wish to receive any of our mailings reply to this message with 'unsubscribe' as the subject.=20 --_----__Experian__----_ Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Welcome to MJWorld

if the interactive content above does not load, please click here

 
 
This mailing is based on your providing opt-in/subscriber requests to receive this kind of information from one of our associated websites. If you no longer wish to receive any of our mailings you may be permanently removed from our database and opt-out of future emails by clicking here.

Yahoo! Groups Sponsor

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--_----__Experian__----_-- From whygee@f-cpu.org Wed Aug 15 05:44:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WC-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:00 +0200 (CEST) Received: (qmail 6007 invoked by uid 0); 15 Aug 2001 03:46:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 15 Aug 2001 03:46:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA32012 for ; Tue, 14 Aug 2001 23:46:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 03:44:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA31454 for f-cpu-list; Tue, 14 Aug 2001 23:44:52 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA31440 for ; Tue, 14 Aug 2001 23:44:51 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7F3iZb25326 for ; Tue, 14 Aug 2001 23:44:35 -0400 Received: from f-cpu.org (nas1-100.aub.club-internet.fr [195.36.202.100]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA20016 for ; Wed, 15 Aug 2001 05:44:48 +0200 (MET DST) Message-ID: <3B79F01E.2CE07BFE@f-cpu.org> Date: Wed, 15 Aug 2001 05:44:30 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Tue, Aug 14, 2001 at 10:43:57AM +0200, Yann Guidon wrote: > > thanks ! > > i'll test them ASAP ! > Maybe you'll like this one better... :) i've taken a short look at your FLEX+BISON file and it looks interesting. However, i wonder ... what about those who work under Win/Dos ? The remark also applies to your scripts. Btw, the idea of the scripts is not bad because it spares us one compilation run. i'll try to use your files locally, and i'll probably put what works in CVS so other people can work with good software stability. it's maybe a matter of a week. > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 05:44:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WC-0000Q4-01 for ; Wed, 15 Aug 2001 22:44:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:00 +0200 (CEST) Received: (qmail 22581 invoked by uid 0); 15 Aug 2001 03:46:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 15 Aug 2001 03:46:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA32011 for ; Tue, 14 Aug 2001 23:46:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 03:44:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA31541 for f-cpu-list; Tue, 14 Aug 2001 23:44:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA31522 for ; Tue, 14 Aug 2001 23:44:56 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7F3ieb25331 for ; Tue, 14 Aug 2001 23:44:40 -0400 Received: from f-cpu.org (nas1-100.aub.club-internet.fr [195.36.202.100]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA20028 for ; Wed, 15 Aug 2001 05:44:52 +0200 (MET DST) Message-ID: <3B79F022.661E7A3E@f-cpu.org> Date: Wed, 15 Aug 2001 05:44:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Tue, Aug 14, 2001 at 10:43:12AM +0200, Yann Guidon wrote: > > > > i wrote this stuff tonight. > Some remarks: cool :-) > [...] > > // There is no integer divide instruction. > > Michael is (was ?) trying to make a divide unit, i understand his pain. > > but the instruction is defined in the opcode map anyway, even if it must > > be emulated. > > I'm still working on it. The real pain is that the IDU duplicates so > many things that are already present (parts of the INC, SHL and ASU > units are needed for operand normalization and result postprocessing) > but I can't drop them and make the divider core a separate instruction > because it uses too many registers (3r4w). 3R4W ? can you explain, or write a draft, about this unit ? i'm surprised. if there is a painful problem, maybe we can go the route of half-emulation, like with the emulation of multiplies with a sequence of partial instructions ? > [...] > > // The floating operate instructions include four complete sets of VAX and > > // IEEE arithmetic, plus conversions between float and integer. > > > > IEEE only is goinf to be supported, in 32, 40, 64, 80 bit modes. > > 32 and 64 bit versions are preferred of course. > > We don't have any registers that can hold 80-bit floating-point > values, i told you, i was tired (me too :-)) on top of that, it goes against the idea of SIMD. > and I'd rather add a `tiny float' data type (1+4+11 bits) ? > for low-precision operations than implement 40-bit FP (which is IMHO > rather useless, and a waste of space). are tiny floats really useful ? > > // There is no floating square root instruction. > > We intend to provide "seed" generation for accelerating Newton-Raphson > > computations of divide and SQRT. > In the FC0, we can probably get away with some bit-shuffling (hardwired). > For sqrt(x), divide the exponent by 2 (right shift); for 1/x, invert it. believe me, if this was so simples, others would do it already. The problems is that this trick "only" does not provide enough precision. The strategy in most computers is not to run the NR iterations inside a loop, but to emit a fixed number of unrolled instructions. The "seed" must be constructed in such a way that when the specified number of iteration is executed, we get at least a certain precision/acuracy. For example, imagine we have a table that yields a "seed" for 8 acurate bits (in addition to a correct exponenent). A single run will give 16 acurate bits then another will give 32 bits of precision. if you work with IEEE floats, the compiler will generate 2 optimized unrolled iteration bodies. If you work with IEEE long reals, it will generate 3 iterations. If you "only" do an exponent adjustment, 1) you won't get a precise garanteed minimum acuracy of the approximation 2) you will thus have to put one NR iteration in a while(){} loop and if you work with SIMD float, the slow convergence of one number will keep the whole SIMD packet from being used even though other numbers are "ready" (converged). of course, if you don't mind, you can "forget" or "simplify" the seed LUT. but the program/compiler must be adapted in consequence. > [...] > > // Instead, the byte shifting and masking is done in Alpha with normal 64-bit > > // register-to-register instructions, crafted to keep the sequences short. > > > > hmmm, this family of instructions is often very useful anyway ! > > Indeed... but why limit it to bytes? The ia64 (aka Itanium) has dedicated > insert/extract instructions that work with arbitrary bit fields. concerning the f-cpu, as long as we don't have a final specification of the SHL unit, we can't be sure. > [...] > > // If precise arithmetic exceptions are desired, trap barrier instructions can > > // be explicitly inserted in the program to force traps to be delivered at > > // specific points. > > > > no need for them. But there is a "barrier" instruction that can do that anyway > > (flushes the pipeline, "serialise" the issue, wait until all operations are completed...) > > Shouldn't we drop the serialize instruction and make it a special register? that would be an interesting idea. we have already defined "serialize" in the instruction set, however. but using the SR would probably help reduce a very little overhead caused by the instruction. It frees one opcode byte ("only"). i'll check whatever i can do. > [...] > > I am still wondering if PALcode is such a good idea. > > We're used for a long time to rewrite the trap handlers for each new computer. > > Maybe this idea came from the VMS transition constraint, but there is > > no need of this stuff in the F-CPU. > We can implement a `PALcall' SR if we have to. and what would we do with it ? :-) the PALcode is probably a good idea for the Alpha but from a F-CPU POV, it goes against our logic. In the DEC world, you buy one expensive ALPHA computer and every 6 month or so, the maintainance service sends you a pile of CDs with updates, including PALcode changes/patches. Nice, because there are several ALPHA families and even more members (ie : 21064, 21064A, 21066, 21068, ...) so Digital can manage to make one PALcode revision for every member. In the F-CPU world, the CPU itself is a "commodity" : you can buy a bunch of (cheap or not, according to what you can access, want, have, and can pay) chips, which can have different versions and come from a lot of different vendors/funders. In the current PC industry, a new CPU version comes every 6 months in average, maybe the F-CPU will shorten this to even less (due to increased competitivity and open sourcing). In this condition, it is not realistic to have PALcode : if one vendor goes out of business and takes the PALcode away (even though he should release the source code under GPL in the "ideal case"), you won't be able to use the chip. The PALcode becomes like a key and if you don't have it, you won't be able to make your computer work. On top of that, i imagine that it's the place where companies that don't want to play the "open" game will put "proprietary feature" in order to make others captive. Maybe some points are wrong but i believe that PALcode is not a good idea here. Maybe i don't understand completely what the PALcode philosophy is, but IMHO it does what the OS should do. PALcode "hides" stuffs from the OS and enables the vendor to include "non documented" or "chip-specific" features which break the architecture standards. And now, i think i'll update my text with these comments :-) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 05:44:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WE-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:02 +0200 (CEST) Received: (qmail 23568 invoked by uid 0); 15 Aug 2001 03:46:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 15 Aug 2001 03:46:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA32092 for ; Tue, 14 Aug 2001 23:46:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 03:44:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA31264 for f-cpu-list; Tue, 14 Aug 2001 23:44:36 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA31261 for ; Tue, 14 Aug 2001 23:44:35 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7F3iJb25316 for ; Tue, 14 Aug 2001 23:44:20 -0400 Received: from f-cpu.org (nas1-100.aub.club-internet.fr [195.36.202.100]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id FAA19956 for ; Wed, 15 Aug 2001 05:44:28 +0200 (MET DST) Message-ID: <3B79F00A.73944EBA@f-cpu.org> Date: Wed, 15 Aug 2001 05:44:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <3B78ECE2.4090601@free.fr> <3B7926AF.D2820B91@f-cpu.org> <20010814215005.79c4de9c.philippe.trbich@free.fr> <20010815004441.6ab69f29.philippe.trbich@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, philippe.trbich@free.fr wrote: > > > otherwise, prettyprinting, HTML versions etc. are welcome :-) > > what is that prettyprinting, HTML versions? > > I don't understand what you mean! > you want to put the txt file in html one? for linuxfocus (in meta html)? i meant that changing the text presentation was not a problem. conversiont to HTML was a possibility. however concerning LF, the copyright issue is not clear. DEC is both dead/alive and i don't want any problem. I don't think that the text can be sent to linuxfocus as is, it was not written in this perspective. i think that it is a good material for conferences, however. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 10:22:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WG-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:04 +0200 (CEST) Received: (qmail 30462 invoked by uid 0); 15 Aug 2001 08:23:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 15 Aug 2001 08:23:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA04246 for ; Wed, 15 Aug 2001 04:23:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 08:22:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA03981 for f-cpu-list; Wed, 15 Aug 2001 04:22:44 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA03978 for ; Wed, 15 Aug 2001 04:22:42 -0400 Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7F8MPb27447 for ; Wed, 15 Aug 2001 04:22:25 -0400 Received: from f-cpu.org (nas2-211.aub.club-internet.fr [195.36.133.211]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA13380 for ; Wed, 15 Aug 2001 10:22:35 +0200 (MET DST) Message-ID: <3B7A3133.744063F0@f-cpu.org> Date: Wed, 15 Aug 2001 10:22:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Tue, Aug 14, 2001 at 03:25:04PM +0200, Yann Guidon wrote: > > hi ! > > > > Juergen Goeritz wrote: > > > On Mon, 13 Aug 2001, Yann Guidon wrote: > > > > > do you have a link to basic floating point implementations > > > > > that can be used to begin with a pipeline fpu unit? > > > > > > > > There are some docs floating around on Internet but nothing > > > > that could do the trick for the FC0 (due to its specific structure). > > > > superpipeline + SIMD is not easy to do. > > SIMD is IMHO not reasonable for the FP units. in what context are you speaking ? SSE2, when correctly used, can do some nice things (if you don't fall in Intel's crappy traps). > A reasonable approach is > to build a set of pipelined 64-bit FP units, and then issue the 32-bit > operations in two consecutive cycles. that's vectoring, then. Scheduling might become more complex, in situations such as chaining for example. I have nothing to object to that, but - 1) currently we have no FP unit - 2) SIMD already works well (when it does) - 3) vectoring will be used in another core because FC0 would require too much changes - 4) if you have 1 FP unit, the hardest is done : you can duplicate it :-P > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). geez, the instruction set in the current version of the manual needs a big rework... Sure, there needs to be an expansion/reduction code for FP but SDUP works for SIMD FP if the packets have the same boundaries. > While we're at it: something that I miss in most CPUs is `variable' > register addressing, that is, accessing a register when its number > is not known at compile time -- like get and put in the F-CPU, but for > ordinary registers. I know that this is likely to cause trouble with the > scheduler, but what about mirroring the general registers in the SR area > and simply use get and put? that is certainly one solution. we've already thought about that, "long ago" (if i can even remember), for register save backup/restore with a simple loop (otherwise it would require 64 instructions min.). however, it is not going to be easy in FC0 because the R7 read address ports are directly connected to the instruction coming from the fetcher. There might be a "dirty hacking solution" : the BIST needs to access the three register read address ports in order to test the register set. of course it's not going to be fast and clean, but it could work. BTW i'm currently updating the ALPHAvsFCPU text. it's getting larger and larger... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 13:38:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WL-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:09 +0200 (CEST) Received: (qmail 10224 invoked by uid 0); 15 Aug 2001 11:39:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 15 Aug 2001 11:39:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06169 for ; Wed, 15 Aug 2001 07:39:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 11:38:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05922 for f-cpu-list; Wed, 15 Aug 2001 07:38:39 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05919 for ; Wed, 15 Aug 2001 07:38:37 -0400 Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FBcLb28776 for ; Wed, 15 Aug 2001 07:38:21 -0400 Received: from f-cpu.org (nas1-142.ras.club-internet.fr [195.36.192.142]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id NAA19667; Wed, 15 Aug 2001 13:38:22 +0200 (MET DST) Message-ID: <3B7A5F1D.9F63DDD1@f-cpu.org> Date: Wed, 15 Aug 2001 13:38:05 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> Content-Type: multipart/mixed; boundary="------------0A2DA751C982A11F90F9425A" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------0A2DA751C982A11F90F9425A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, here is another version of the text. Please tell me what you think :-) Btw, it is getting truely huge. i have zip'ed it this time. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------0A2DA751C982A11F90F9425A Content-Type: application/x-zip-compressed; name="cmp-fcpu.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cmp-fcpu.zip" UEsDBBQAAgAIADdqDyuhSXgbIUsAAN+/AAASAAAAYWxwaGFfdnNfZi1jcHUudHh0tX37cxtH kubPpwj9D2Vs7BoYA6BI2RpZc7teipIs3oiPISlrJjbu5proBtBDoBvuByE4Nu5vv/y+zKqu BimPd29PM2FRBLq6HvnOL7OS1WaZ/PW+/ut8Mtu00+Zz8/TJrMqSJkvdTZu543bhDr91z37/ 6ujZq2eH7uiZ/Od25/6SFIX7sc3TsnD/fbvcLbLsX3WIslr8y9MnF1W+yItk5eb5KnOv3Kxs qyard66cuzfyUZOsDk7K9Sb52Q2L0p2Um508sWxcUTb5LHPbpHbzsi3SkcynraqsaNx9VtW5 vO+VS9rF1B1+1yzHnNDTJ/if0z/HHy7fH7v7eureTU4uP8q3j6vZMm+yWdNWMqEZ3lrldVlM 9bnJf/7P0ydv8nq2SvJ1VsmLbpZ57dJy1q4x3ezzpsrqOqvdRiZeYjPKTV7ICurx0yfrZCdT KZokL9zf2nSR6TNVVVa1S4r0oKzcOq+bnTyyqGWq1+U6c4mMVzUYAuvI3Lwq165Z4isu//o+ c8ssqVInz8oZpu62lePM3Swpvm5cstomu9otcvlalc0z2dOZTG64xN8yiGx6Kc8ObJKDkbz0 1GGetbyqkTXWrt5kyZ2TKePrRSIzkPPEz7rXm6r8m+zz0yfDwTYbjPB+l7tkLSO4Wg7hl3Kz lNfmM3kmwUdFJofq7opy67YyD76xqXIhvqbUmQoxpnmDTyt+l6sZu80qS2pZv1CbfOvpk6TY Ybvkt6lsBjZgW5XyQ17IV9YJtswNq2xTVg3mu8b4a31OdmU0dcerlbutZONl9yts0EI2X96Z 4jDcPWgS9JdM/x8JRlZYNFWZtrNGaZnnOpgns6YeuOS2bDlBmY8wpmwk3v6J/PV17UkKD8q+ g9rqJC3kNyMMzEccSFB2YepOG3lCyGC12slqS5e261supi3mSV7JkoUPGk9CdoRCmbLbMgZ+ UxbyaNJxT+aPbZ6tGrfK78CnRYMNl+2Uw19UyfrpE9lxebtbJnJ8WVG2i6X/bC3bKXOv5ZE7 PLVZJQ3Oh9OyFSvnC/FnkAU2BzdYinSQ0dJBeGjsQBfy7WQl5CXzFaYq68bNhAgKjjios8+7 gQyRyXzWiQgkiCIRN+ukusuaMk8pDWQD8jqTlfMdt/LkNk8hW1ZCQdl93uzGbggeGIHVhEWw b3lWj/mSBHOUd4NB/IyEUmUGtyL5ZF+aRPYpcfUSdGXscnlic5B/Vdihp09W5XaSgdRUyon8 ugILB1qYvL/4dHOhW1PKSBFl1zIDiCKKVTn0mUw8k2/Js9VtKQKhnnb0gfnVjaxAzkIY+fD7 ly8h0O3psR7xbTYDcydcqkz66ZOTyz+5w2duJ/KldnICWaXLB+viMyGpVY0B58m9yHos9PT4 xbdTId5EBMIeYctJ4jRkqe6HiOh72+s/ka2VjzbKM5SN/G7dbsjNP9iIdZata+z3LeaN6QjB Pn2SZvVGyJeP4HwzoZCf22SV6wlul/ls6bbC6HjDveyJ7EXeYCVNJiRLJs1ld08qEYRXWZ2B H9zN8zecyM3zt1N30lZ52dZCp0rtY51fAvki/Clzkfcvk80mK1SwcSwS4s3zdyCWSpQc9hvb 3tZKRmW7SpWHQKMZjmubN0t3dnnJ37RyBPXTJ7dtLrwok77+8dQNbTlyxKQRoZWVSAcQzUxf fdvu+HqhdnlmLqsxnvZvlN27xSI4pjyX5YtCdWYhGzadTkdKS7J40f2iVmpZC4dQxYt3Q9pg r0HPWKjRlqym5oHIkCZXdfZG+mM3E/UlyjLwgGeXN9nsZJlv5GlugT8bGeTy5FTEdi76k+Ot M1m3KtaqXK1kqGHdyo7gxRjo6PDZi5eu26UwGbDVn51s6RpWS22LdIuyTPsSUERjeXtv5w0B ZRIOA0BeTFYJxNtCjr6diX4VPg5sw9VU+WoF2Xd9+fbEgcCouyHFoLJ3wioy/XKlWp0adJuB uMlp3GhoSm6LHstOeW+sK4wnK8q+lP8kouEOEkxuChMl4jCRlPfZGOcFejDiwyiyizCVkrYx XYNfQrnKjsopyo/KhF6IlVhummYQ1mleg9YTKIEizYTqU1oYUDQ6x3VStFB4MsXqIJPDEgE8 O5DfJmoGHdiw92KnmYCTyYkAriHiVQ0VYjtge5NqB2WjtAhtBCrPi3vwOfYmm88hJcDCNGO4 q7qNchAOp6U8wjGf21GJcix2+l18KEqx5mGLhST0p3vfFg0fFKMj2/CnAhasSigRbp/FgJD5 4L2zXHZzlc+hh3iwdzqFREgG4lUsxFKGEM0sG4ynhNcpNgfBdNQlYXcGQuVJoSL9VBT8TH63 2qm1jMEjE1QIXUa9rcptrcsWhZ3d6maoIAPZKuMmPSu5btr5vI5kG7UtZSzOMIGh7trNpCkn KcQbFbaIiGIxb1c9q0vMNQgVTi/WA9Ah0Nbg66l7X25p3mF7VPz0xBKok2wvRO3tDTXklV5F xIquC7pBBl2lskF/gYhX0zTfE4kyK9MbyqYlDHgzQTAMiEUFtcqI2pkg4QtO3py8ePHs2VgF dAoCEM6VZa9a0LrOQnZYzkWOc5HVfTs5zeZiY2N7xMIzC8Ctd47WHaRMWRh75ZQVKyGlMd7N WcmOPn1SCaesb7NKTNfr0u3KVulZxk3VPo/pAI/JsjZCYzgx/hA5QrX7SgQD9sactvCg8qyX 3+av1B3d1rtC5ikeW98caUi8dvJiqOcqFmatuC8pCff1TqlRNJFQ6a53mLpHTRmZCz/IE3IM chR23DMjEP040nsJTV6ZTtrW4kkkq6dPzCsZyRSg37N52XuRPQzBbrZm24gPlAyUENQ9gtAT ih9slrs6nyWrgSN/47PROBqMmicXqV1COS9F+2efE9EpRhLwdIo9GU3KkKXQgBwe/un776F9 3O/cpViJw9PXZwdnpQxXrpIRJjmHyi6V/FfZZzGw1ArPUrrAnZCrc3yBPHFxccHNuc3wwawS 0pvlv2Q0XsO7+TjkgayhbtfKZWIrg+w3wp7KXnKWuXxBbREVhNS1QhGLfDblIBdCf+XGL2wM BabGBUQozDOzjCNxZx5vmt2Ka8/Vn52d/tkN/1i0zXIkrKleyTYTGtdNlOf9cG7AMxfhvEoH nEG8w1MxHzobsCOdN/nszl3L72sxVtZ1tprzURpiMvgyW22Ci4E3BVvB25hyAuuMot3bYzrz t5enJwcwfmXaW2oKW3oCXZSa9KvEZEmhhJNCT05XKOJNlmghDyFHPTJhrBa+6PCnD6efnCmj XdbwQfPxEpFjG9hEngvE9sLWml0r54TPjbZO3SyrwMzUHDKXSBnRb7Cognz7xu9aXpvizIID kYgW3vYNpAEdynomps1sCR6qqJjW+NIBogmH33///VjpR/ZQFDAZyp2dXl67q6Nnz565Tb7J RO5lkKji1RcqMi4RCZhBa6i9TrcvcBcIt2NDmE11KWQqYhKrFzG7aCH2xajdLkv3h8mbUbC2 X2nsaCLTeX40ucU5FCI7zENnUISzfcHP5nm2StVFzRJhDR8p8AGoFCYXjofGlTcP600yy8Ik N34pTkas/etp10Um5aZbMERjci/aAKxDeYPzbtzf2lodcf/2gRxzSs0SJlYPEDETq74Re0WM pjt90aKkkGhhYcj+J2EBDDnkCB4M4NxPrk6vTwYj929nomNzoS0ItbyYrdo0Q7RIKGjgnkeT FR/hf/olRUsQUSl+oehCocRUFr4qYQCBPkuGq8QeQLxHpkNFAqH7yk+pI0352HRMQmO8bjOG uRxdf/xOThQKfoyY0zajgu6GERNjR9dEJHmW3A3c2bsPF0J3aofrMXM+tWxsQsKKJjT1A12X 82aLlxml4tlhkt4n1P2QBjl8D2GJZZH/LIRHr7jihgsjNH6cmM5qcX7SFup+JEeN2AR1uHCv HPnax9yS25r6CDZjt+Odd19lsCEyqAN+/7qhdabGxzENYYcD7fGsBn22ZttwJ7P7cgWpMRQh g92BRIgUCmIs1cgthJ7MR5ZXYFzv38n5zJtMqX2ei5CfRN9dy+7UTVnAA0EQ6fjqbEz+H4tX dHx1IhQE52suomVWQkUy1mmzmK3KmgJa41U9s+z6/eS7sUY9VQ6YNH1gt7Q8Fox7KwaPX4C4 w1TJDEPeysGKSaoiDwOrgaURy0iJzcXPpGfmZQ+4SzcU3wdvCVFu3KvJJY7p//zX/MFQIioQ z2piy63JPkMgYGspo5WkT775Rv65U6MPhl1NuzMBk4vucLmaTraitORTQilvz45P5FDqJSO9 cnB0FuWMc1rhbV4vH3l9iCj6l6k3fXDgg/NyxO9Pb96e3Hy8euvk7/fnpyfHH9z1x7Oz46u/ OP1qp57H7goG2if5+U7mvRH61DgiGG1KN0bE+t8W/zqrVtM0m03l9274P/K1+zFrml0tBtpN KzM/+s69E+9H9M+RO/z9K/n/85fux7MbDZ5a2iDYcd44Fi8iynUMk3YBmYu0w8iv6t/OL27e vnIDsuCAznyh3kpB4yDVWDmcSiGzeU6bgdFzkgiIqRCRD+GhA1J3QYoiWqy+BMIj+GHAiQ70 cVilouEoqEi02xImFZ1Hc9kXPJVkHfwq74HlFjHYRZYARLsQgNcc6jExKs73mZOcfd6I3JAj eDUZqXkwOP7z5UB9RmMQ0azqxMnaGjGTwWK6AHMT1ayy2BekSRfYy0U+yN43OyXewU/Hfx7w 6yIXqB/1+1kOeSDLPkt2tyH0isjnfT5rEAYysdfFGst7E0khAFxjEQ4bPeDBD9S42tKCCikA 3QL1SCGNJmKAaqiwxgrMNfJ2v9lM3HX5ooomMXMQBsC2pSVOzHbUr1qsmHzdrnUT5WAQpBbR SIevzuiEwxS5C6z06f3xjTu9Vpb6gaQypx84Y/S7hsFOHwoWeAONjw/XTLKpWKTvKrZ7K3xf m0+Kg6HzZkald56n7mLOJF6djc1STYLZ21cmajvQOkt8RmiMsBY2ZIzHlN7g/OGIEBeBp4Hg VKYRNvHKG0vf+ACSnHq7ooFJexlyBUHcXbyxXK48PjBbdzB1r1sGEZRJamUMC7aYmJOPp579 KQWLyHkM89+LIoALjKqwZZXFhYOvOXXvIA9lAxGhUU+d+994zlyUyAfOu3FB2LKAAUKiGhwV Q2Y1QGCu1U9Usw7g79BpSqp0QJNSrfC5WMIr7ug6n1WlzETjGjVSQWHmakcIuc8h7msxDm21 O1LWRcG0S2ZiYnBdngx8ZnO4/l1197vmd7BQECl1GuaTjWc+wJsouiJ5ADw49Zo4sDsFQKNO FPV6wrdQ08uBfXh7cY4vT917Gjr89xBhGrF8NBdQZeWcrjDUEJkuS9WXdB9+vPwwtrBX2Fn1 lJtMNke/JV+a6lIhLRBWIE3DctdEKRR6iEJY5MkCzkJF8n0xH7HDeSY6didOziyvZq2Y8lP6 vtCIZjGlaq3jlV+n7vTSjF/kLmVmi6rc0igsGV1baqgruLUrkYS0S+F+Ian22mJndHdJQcFj NPIBjcgDQp8Dvkz2VAnIrKekvxvl7bytZ1xYsqK+ohHu/ZTPL1+4iI6CFveJxsS9+JZO0UOT snOX1ahGxFk4GHJ7LU/XDLeYqq83WSbqbS0MnoMzY7OYJn70WTcdWPhmhotUM9NSB6QFImrD /XR2TVaic/nxw83V6Z81bYVoOCUPIh+UPN30oVP/phpOh2OMXW1DZeA0N4eeDGBE0tY0oMiQ 9P5gJnxn8WRsnTEGkjOwWVWQiAHaULjjOE3B8h1DZvCNp/I4Z5wsRJbBpgrnwLBInMuAAklF vN6q+PPMz9G7dMRK03dDU53+JZoY1OgljCWTQCGiCTX0IIc4kk3EK8dGHcwS5Pc01GCorOaQ TPR2g/0Q8quWSdS4FZ6cIXgAogxOxNHh4YtvRRBoAAyzpaKrsww7cY3J+BB3D4vQBaqQkLNd NndBhb7FGLoQFYPNPpUnrCnc8jWCqS3tY9i1QHwgaHrsvgspUaElca8X8rKQSBOFCp8xaE47 ClAOOBhG9IxHxPAtMxiLkuvLVZV7yEbyC8yop092yKyKmBAXxZ37dJBlR7lYGf15d7oi1eJs A3WjcJaw+2L39IkcByOd4r4vo5ywEHOwM4IITTRQ4AMzMvL16dmbx7ABGqOmnu3C4Uw2dgRk CQfZ85M3fbEh63ptUZktOLKCNNpLO3uEgjAYgA3MjfF93n1TD3VZ5jMfKkpBgyIMK3mLvH8o LCqHMFJDrQKygqCAhRzHKzpEIXCg7lDOxPKqLO+cbbgyW3iLqusM50aT2gysklmIG5XYCkyZ IzkN6I04LRhvOPggz8caOxNScWbly7a9hlSuZAsv2moh/LvKgX8RvhRP95QZEY33iDw8vX59 7o7c74++f+GefffiO/f7EY8WoUzlVIhhurdmwTG/ObjLhAbUwpjtNrIjAzNJZVL9tFDYYjWt zW6KjEMFBmXb29yiViHsY56FQRou4RUgteX+CYoeGBYhSexI7f0cipHjmMKuPGrJnSVFiyA8 gQshjJs1M5LtFcW3Fwdptkp2ZsSLUKmdKbel7Cq1h1A+gmIgFO6HKG3ki+N8KELiwjgiIbn0 KGoW0kN8XszYp0/Udp2Kw1qk5VbeHCJxXdyMkXXoFYvv1CFOz4iH4QGC7Do6PBLpxw1EPJO/ Q1yJ+sCySaLRxexU3xtWbpkj+Sizvc+z7diYDuQQzDYGigfEywwe4WV4WYXBL2AqMrOTeGwA LRzFJIkRTCwZN98yeeOI35VLlPbrzYr2uHmYYtOFALsiTwgD7HbfTEvYLLT5NfhnjqptJwyI WS5+NSMObYGoGHNrkSEh5itnvAXUh8LVxliUHoMjRu16U1Zi0XkcwarUkRjB2M9q8FzkVLCl ODgNm3bBpk7J+6RRRwjMoRamDzZlXecWe0mYjKTa8XsVb1GcAoWhETBbqi+CqzEse5Md6d6+ O3lGAS1Pryx4Gol5Jtg7kmtg5poH/SEv2s+aX1Fb6cfzj5HOefoEFokZsrZsHFa7DgkD8Bls DRF9WRcg2mI9K0YpZjuEleSQ14kbxkFgJqTWGzmH25wO3w8jKD8RMipSMjENLQNd5/rzGDa0 uxF+r9dioYu5TcErvsLMi5f4DaaSARq6Y3wCKVimPxngkHcNLo8/wHAfmBtjwIOxzxjeiYzO VgdCr4iZpAzraxy9n1SBbEBeXYyDZV5o4NrCcMoAmbItUjsaNLsufUBKk6kQRHIwxr1QazI2 WftraF5oAUJGcIq3Ir1TvNSMHpi9weI9BRO2QKd2yVxvThNJ80D4q+EmZlat30jStCZUqtwW gHrQSxlrciF3fytD0nMPG0qDESmg3PKWXonn8xB8gwFlsCddi0ovLA3YOrAPOVa2uVNwerI9 Oeaz7kL4msFVExMACIgKn8eEIKal0xMzHu1IeGo5N7gwHIIbH9UmfGH/sapFqLlB0FdWdvTs mTt7/8tUn6KrwzOjetPh9qVbXncxNuyNDyF7tC/TWMHHSMw9xKg63iGSaCHWVSAmGxwRxroY s+NUBm44Eyl3B8b8GcbabtSHKuQdaZLYc4hI4Fo0UjUFfxCxrRZDQOBCdttACivW140VIjhr fLwuigYo3MWz5YB+iW7FSlMxUZgBFpmsS5kkCk3ppM8+Xt/QAE+Am2DSR38MKoCgA4Pa/eD9 aiQrI+JZI9DLOFYU7g+HkRABh2y+RvrJUoznhniqolb84fYDhnFka66J8ANE/MRIGCaUH0yN wHEVJV5pYsTSIcw9fk4wcD2y4AEniyWvss9UJpEKwCsVzSTiTIMjd1m28QZSLAtpOvfELV4m 3jXmT5dzZRGIGWNyj0UAa4ssIhqBtLxqlKRhhBrgCzC78pYByctmUpeTVAFTk3mrEQRL6cUD K7BElUnTrdUSplsfCBEBfg/PoWwbRmvkJbmY/LmYf2aPh4n76Jd6Lq4tNK3WWKIVLi3TURov 6owds446XWbOpOXIiQA2IUWPQKwNkVpywMwMUNEDQWYcCoWCzVYY9T3mDN6AXBIxWzFzTd85 icyF4eDYi+7+LhHnwomJKKJeRiwPX4vGGox8/F8O97EvOMXGq0AXVgnBiJOr47+4m+e6kyFp IFvjY9lhlBbcq2kQIMiEKb4m4yeWUvqBvpy3WiAMGL7ciT1fwMmu3OXJBAKUNPTy2csXPv72 B2TTjj3gLYBr420neAsiBu5syO4STvr2hMHoqXy0ZWmFHnQUuVN712vdV4YvJJQ7WiFxnrNk kxivmMCDCPIhtHonBt/66zpAU+XbM/ku8haXl6S6VbkF0KOtqh1B8YnIh5WYRfcZxbqOUBsV BvN6HzuoLufaz5DRDhSQ4Bev3CBx54zUydyIZpQDBVJPZbpajx49qTaoO/pf5yKwxK8a+ADy XIQhs/ITs95S2VBbc+fjMC9eyQHmG0bASTrYDkZRZW9LQg1kMoRSGCsm5sOSfc2KxEO0h7IK 3pSdXiXiGwPIixmE6CXRs4YUV9Q6Wt6HE9pWGaTQxQCkEErZwrwaexRsFkEODma72YoaA2Sx w+QxyNCgLGcXl9cH4kHD/uMTISIie1EBBSfyV7ayK9Ph5ywecKSZIRBfP6jPfvSdwk0GaxFH ySDaX8h7T48I7uBpD5bMQ8VHLdQAIpuYhLEz6DG4zSujPXEIC/pIPwAGG+YCAQ9paZmLEEjC NEEsdY9aZMZKL2Brh4jKK6/sfcrIO3V6boH0hUYppO4J/SbRK1HIb6dREvQxoCpt2zEtYTn2 OWKaPdvelmg2kpaXBJujq6GihWqMl9frMQZTRB4/VhtJjTeTck+fEDvsv1frF2NiXAmjruJR p3GxFY00zjfMUXbL7DRDaelrX/mMGhViBdSRh+51kVU66cikDQ+/eyb2JlLZhyjWk59HHCya iAyJDTNBbhKGVA2LQUY++qMS5OGzz966vF3B2BHDR2jl6Nm3L5/9o/tqpGA7E/snb4/d0GJb xw0w3e5tkVULsa1h/lRK2Il7/kcPveV74VFa5FBtIw4qNmOmkPl1sijyBm5+51HTezaPgnYJ IG0fLomG4EBWC1K3s7vxvjKu1B1lajV2qBHTgdUtloNissjY13AqRURkCNKfIQ1xs/TRvOFz 8f9/cN/iv8La38bH78XFMECJdLfiOhWGLT1cqOYBpF4XDVHYZjj/SvTbzhdR1Qb/QrgKXxlZ LgtJz1Vba9IkyLOdGmOearho9QcjICwIWCis3Yy7gplELT3RwWIRWSUA8lt/HHemjukcHMtt 1mioPglzLu52rHYTJsAKaiKVqZssBm1xVcavMnf19vjDh7+4j+fyw8n749cf3rofL44/XANA 77bZ1zgymOVEk0L6cU36skxx0rakhJkFrd/i2hRy3AaDs0NTMCYwsIkoypOTCRElofyfW+Dg Gk2NmS8NKxQ2/59YStT7qDLFkcBFgvbt5UVDgvi87BefFaWHgIndKToMVhG9DTMuxiFzxyBK KsLGUDox+rhnuQuxZGOD61tgPqp/yM3JVMEFUzNVo15GmnoOXTKA6aHaPApNhyxKjY54l/jd xdXZ8c21/+ebpEncOyLC60fShqsySQ+QIM4epg7NJV+tYrQfI/hCY9sM3j9GCwpxGmWcnh8F KyMySEQ+yQdzIA41W2+fjIng1OGEhW+ZwD3de95dPT/kEA+ed+/wCZGoTNP8klXlVEf7IJRH t3eoiNIRRxBCSvW3mjYd+ckq1VhFm8gz2bm2slSmf2sqO9rsNtned18xz/luwu+N+Y8f/T9O 3759a9E+HczPRnOg/NjSWn5GU3emdiqOiZo9Q/VrSPTe51XTQkRjOKGyZpWhdCuHnbxrgmGc WaBB7EYhb1gYOD+Nbb3q5EfiBhucuJZsPqCEQUjLa1rOl/wlvjYnW9WmC2x62CQg4lcsZOxJ eridFfKRnX3IUlV3ePSSzzKeoeEzCIKgbKaKfgB5bVbJojV+iCeqAyUKPBijbANmNR0nTJjl Xp+Uz9S98DWsdT/NFgyTaKVck5ziL12GLTE8PtT+thyHUBBANjgFjdH2gt/KSgTx4RtjBmXG TsmRtKk/YXBCkXDGCAnlGgoNSJo8QHseZgBp71FxW3CeZo0mEGgdwy4hR7MmAJYgFxdbJpiL 7oePaPjIi6XHIHg1MtCXEAYzmN1lmqPByAFm7kPe3ZY8fTLE+WhNeUO/CXZDUWdW+6cAJ/k3 w2JZXOTRZS9wKrIjfxWC+atqjvSvFrd6+mTQj+tNQsBngErHUl4mGr/OJre7Cf52liMVlZ6W qOtRp0spmxlUeUMiBogbxmECf1z7wh81gclc0dajsfMp/JCLEC+wH7ac+bR1YoACYwxY1xX8 Ef793eERcHgRWKsonz4RcgUqFkh/LaWHxzCknzXqokFMpM6EXRcsiFY4MfLJDMj2imjm+aI1 SMecPFVlZifF6VcGqr3Hq5Vk/dKigOj3A1dZt84AmNA2BVbOmmVdHL6fBCQUiUMMLRrHOusO eTSK6ji7qINspcYYzKJyVzcf/AKwNhXo83JGRxn4Di/N+C5ScJVtViGrZdZ+W8BVo5Chz6q8 hLGMEknHVMSDTA+6HrghkJXLtdVsqaozAydHNBHPvxy7Qzlt0Zly4KoY+QotiJrnzP95YsyL CCtJsijGNqHAJ4O01flnA3WdNkz/6gFuWdHm2Vve7AazZVvcyWRlpfJP81XlNd4pDgNHkVDN as/bwiSeSQlGUYGYoyW1kgmYhxmARNYTQb+oR4RUh0KcH4QYrC2JN+p8bxKhLsss8YGBJcoH oXIUoMzUKjPIOb6k6ZGYYIgpKoTbEos0euUI5vNsprx8K0uyYoAHmQ+bn8ZSu9j0UsNHBCqa /GB4/D5ZtRS0iPhFwjvUGbfeRQquNQiT5fldeMPQMcFXVkUU1Jsyhm+JEBIUzCsabP6sLInH WCXbAI7OC5ldnrpXvxv55EWcP2ZhJDCLvrZv7JMWzJ/qHISKH8vC+g4sFmVSW1E1R14E/mCL ClDaPZKaDK8gsOEtM59pRwH4QtlLmKtoEdNkUlTd6+Hgw/n1YORUDTDgYeCuvhymG6GspoW+ zgfdyeAWkqSmIxmS4OZJvSTEOvsM5Gu3oKGXOho/9kqVO2qesYJW9qdBO8MznBXkj/bEPo6d aYaQl1QbxeRXmIR/qwb7q7XG05fj7hz/gZlpQjLyStNeMKfHXikKWYLBv14b0LHhKchb73PW 3PRiXyFBS1Wsql21hihDwiMp0taqDVhGOTKcLYLTyGvqNwCRolXaiHWVhTgoBfX33/0jCC8q uBIRkQFO6/7Wrjd2grN1ec9KpOUOFVhLhBbxHjUDY9Q4I9u1pfxUZcLsNEESJR9PoxDT4x5W LK3UP1lBmKsuB+UCRpbmc6Jp+tVucz+g4TLFCWZQ+pmohLE7ognwPJK/LIZTCrVHde6JVcuV G9gf6gxgyP/2DfvgfPPFDjnf2Pf+3V1cOvfvzv9Rdgr/lE+Qk5eVPRz3m98y7tVxN3ia15tu 3NfECX1h2G9+y7BXr3XsaNx/N7/q7w/7zd8ZFhpuyhHFApHP1bD/7eOqADWZvE8pIFFfgKGy MFBJP9El5jNSk7uR81B0nw6iw2UjRNbTrtewyvITGOKADLbQKtFXZq+JfhJNo2g9kVS00nqT pVX0fEL7H2zW5WDwT5EghLF6hqeg9wAu8+e0Sqc0rD2LZAuv/SyK398eGBdC5iwro3LDXnoU AG1arcWSE9PEhrzhJZhOkxovYJp22Ma0KjemoYtZsHNTMyLCGJScwNCl2YO2PwoQQf+M1JeB UapYhSoLJAuR3IwoIKEMdJ0aRK+ihmnhT13NDu3vI1BvBo/ym0mPYb959K+nT4QwlVLn4iLX oFMhWf71Wv86cTGx7j3/90b1g+br9csvjuq+cerI52vmTHrv+eZXFhG9R344FMHVDeGi9yBo pUhAeOnfuOsrt8iag03b7L9o8qUX4X++jvZ1VUJJpZpAJUmmWcIE/YzIFjpI+TwP2osugxl7 e1kvOtTqwQTdgSKPjriEJgbeKlznabqi3ViU7KxGzbaC59wyymE5inKDhxEKiCqfrZ+DgWxR jGlxuWjXaKnQbhd9gdPT4BpEBODq7PqQWRm3uffrDBXxDIpYowGufvdgtatkR7NzmDMxK3wU kAwv+uevhpvPxJJ9AmRASQVfgBkDcRHZCFnl7QJIFIBtCivoWEOXJmuY6YgThGxs3sPMPJit wu4w4lj9C9WLGvI3hRlKnFXehKZ7U3cGR0bPvfaHYvacWYOo+BVZbfhma52Rfc5m2sBHXUUf 2dJwpVkU2hDoVSyqLWomJnMXQ91aDvH571788+HL4JLtnQ0GPdRAqpVchd3vZHUXsxmHiFY5 Rx5NYRxqsFeUPuGjwUbMMsCVKPg9Xaq00RgaGkwu2WlSDMKKqIeBHeIgjhMN86+1ZSK9cy1z 0v4oZj1m4ieWodinUwC2XCQ/WYKGf7y/nFwePwxcjsZ1ThdJYeTacaYqy44Y9fzF6PRfIbbX RxqifYd7n7JU3xYTWvMQxNXWxEF36+MytOgCr9qWe4HwbcVOGAjgabc1+ebYKAunDpMKgP3B 0dXhp4G20TvEj1PtVBjtJDUJhSL5tQnRCrP7XbtJKYUtjuieyzj87tHV0ac+3SikTs8wWJdm 81nnp2A66Lz7Nui4Q3d8uH4ttLpINDH4b9tEicFSg2xol9ddridH7uZBtFjdKN1Q69VkoCMU xHf1d6zRfZfPSXrPDTdD4GHjUTMI56ohbSevbIDYYQ1FzMwGcb4rFh+FIAKRpEyuyily5Hgc DZIMOA6ruTMNRwb90OHLKI0NOBOTF/qqPBLrqVl9v85g1SAkS8fKgucE+jSZB95UtHs8fjrB gqtJCN/dIu8AqwNISMp57cmgQq+ACvLB92EUyRnphC2+gG0wJ4SScx/uwecsWINi/irP6shb Mi+h2zvDzCZsL5CWv2RF4KyItjU/a+EOs/U6u1lxs6YTwkaNtTdB5eWvpj4Z3TBYrGZUaJCG 6oNQUvHKXW+0ncxV4NgeFPD6qlejFQj+EuXV7VoDoFbUQq1Mi1u7/SSrIOFD+zhfzRP6w6Ls sa19GeGiYEzDJyVpLfsNcggto5LGd1+oRdpvlsD2jX2OyCOeur5uHC8FyVRIpvfDvNpvZuSh Iqts3viNfGRfBtdXg1Eoz2G9LQxx9uBAwy0fXivZZkxH+dR5H+8/aQrsiKZz9E1rNul3JqRG l8kv1lg3iOHQr8OpJdJtwagfN2ZzHfgYbdPXKNZ5yhA0nOPVCECL2V3vgEINUa2lfNxQzULB f2HRCm0qz4jizUATeTMhFG6e+FhFsurKYdiGrct2amGW5xaE6el9HR2qX0aeOpmEfi0rn+ls EnYRgs8L+1GTRtftrcyoUSIDF25CBasQvWVyPSYJrUmONVTA/ENjbhpb4nxO1LTRWJARCbPC p6dXJwGDYlW76GDtIXdPn9gGD3ub/w2lzIiB5UIDYRoQItShpZXqvtJSdEq5df6ZsfdV8gv6 a6g6ZQdNZpuMqg8e0gf6PujsbrHV6mPCBBTzDhK7y8tHMASCev8wCRHPcFy9hD/AJKSLKidu BfbPEi1+WCNKcHiITyF7n1jt0MnppRueWOw6Dihdquoeu8HliRaXUx0qcE6YE6Etsh0VMY+8 a95HdxYb4vEnaVtpuE2UwGYcR+utW6WuiqHgJRtWa5tHV+UpqoW1y6Z19JHDOOVZ0eYJCN6x alD7p7IRZukJ0mcAablHroG66A9MWE5MTh/Beu0z6JsVFrMA8MT4KkBC2oiNsbvuhiFPvvbp 9LrNzMzp4AooIi9rD8spAKMXOdRay0tmpbRdb444V1vUwnO1zNwC63LUFdpceHGexcCfLt0w DKv+Rs59RKs6aDY9FOYAcEhCdV7E91FT8gxyBFnX38qCHl91GWyCSTu5UsYYjX6FoBawIwSk JL9BQ/IGUbfYPtGOh8iIdahn37KXUVqW729YfVBaCkS7Fft+075O6i8KaKs1je3z5QjMbMc9 yLKJG6MmsYMVOw8goJGhBv9JFLJf3vmoPCqeafVIEqEJiLYB3KzKyh91UPohmfTm+tJCxl2p /MrOhAWKIr98bvLYJvujtlQqq9Be8lgke7lwbzI0LJfxrt8jTyljj6buIyJHTVskrP1Xiz/M w+d70pDwMefXBkYqUqdXhK5MUYvihKF7BUw2CmOOSrP670JLiNwQ4dbvBYUMKhit8zgE5dhD HGfm/nLnRJfsPDsq7IIoMKXdwlf7iD3AxFfQ1jZjZJSGoT5jZOWUoDr2I8gmitnz8igozg/i 5dSdm4Ny+kj31YYSS/UfPhxiqlQlwFjoB9ui4129dptVW3fq9VBDF7H29FXqJkGMQjklSIqQ 0g8I/JDAcQHVQUxO30WzMuoIeEKO3vPj+sCTHHYEu+or5Mcp5EfdDubrEo3yPJSnmjKq94Op hJCk8DNrKGvhEUCD6M4PnLZz5/vnYpPWLkQ5gBSxpgPXn5QerSKWxBH0iM3j/aepO4E+DKUu PiOlI8oIW6Dg1TjXTChS170CX2bhfQar172adI228YBCa3o1W23iQzOEq++YDXgNFPO4q6cK QC5199C9RuM4kHiN8qVWDw18ubq2Kg2L6cSlSkb+uvYSsYPBAB1UiwieZQcpEa9Jr02g1vQV 3Ru7pL7nAgu0MgFmQ0XRBSP3q9djBhmsLw4gAp1xeeITiFb4xhi8OpTAPmws7K4A6UMN0fVC mB0+r/STmdEk8EMSYPHa1LsXp16K9ceKPXMZQx1RHQW5x0mY14pKccV9kMnZvSKsNDcYm22G ZY61QMBXjjEIkNSxKSYjyRz/A0/6Kgh57sTLyMcO8VeG0KgJg6ozRBv4Xi5pL2qubbJWyQYn yiLWI0sswJcYqaveFxc90w6p1MMXvzKmpxJdip+hbQSbwIaFiYShDdpo80Q2isT9IPeEZuy7 hf1pBLI9Pb++ufp4cnN6cX69FxaIbd86ru68rPL7fJXBzeq1IPiQ37JAnA/3RNpj8QUdrx9k 6BAq+zEGE5TdF0L5nHELSKBqN9ZivAtRjZGfvnO1fHUGP2LfBVdT1SqQMdJjAQ+YjUHKYREJ IfzQ09OwXXlvuzCUoWkabfYVNm1l+xSXFdfBGRRbpg14EWYCe+Ww/QiPFa932q0LRBSLiUrY ScBrMyTkQ+VfWq06mceRj8kVe/dZAy2dFTd9JAIR4az0VgIClLADKEAnnmids6+SGWvaATaC bHPgGzr94tJvMIpMSBtvet3fKWh+Ndxs4Ju+mJdvWcM9p2NsTpqQBh4TcWbfi4M1jR8VwfqA v2Av866fd+fXhERrHh7OirqtOqBQB0EMhTIRit27Yz5De/2pb2x5qMtjkXfdDAIatLpEuQBJ jszZ9ofaTTGSNHosxKCIJJp2tWZKPYTlkWgO/MlQJdxTGgy9bDa+0dwjcSmvocePcRjr4oLb FZI1MvH3n4zL9wCjgag1baLhgtT5ZmNuGLsKagx3R2vXEITGZe8/jbp2wVRGAQEXJKVCHx4V ig9DR/0zYvEQL13oo/PEimGE/YAhed7VhOFK/RR69qAoC0LnjcK99uJoD9H85q8WB2WaTo3D Pxaz3zA9TX0kFnuKwk4UXv2qgrgZocKdhYZndGdSDS/EUqqJAzQYzTciSypRgxSEBomKYl1J 38B63QV4Ytz2vOdMyo4MDRCq/OOZp0ulvVJxBIaFzwllD3/Plyw1y1DcEnemGfGDs+vXY59D Gat5LaaxtQOP/PJcix2c9lFyQy9FDXPpg3WkNA/tJWwEF235NE8HnAqVRD7NIO/elOwaqrdX WYHWeXLuhrwibaQm+7vLDiTYldn7NPMdWmyg6VicjiUGgoa+B6nIeal5wzQegZxdx7O9WGNu z8bgKdMRXcoBzuLBNd2oxzjpQ9/TekCmdGe0uSnQMJqXUeJRJIwO04F2VYug8sNDEidaaRFV 2fRNla0YYuqrIhCJ0XjXmgLeea1BH2O7Tpgq1/HrUCMSij0UwbxKGl9LE9eKdF+zJB0qnbJF EHMgidB3XbldrOF2TQw9hqNHnPZZRv8l21UWTG4w0682DOF+z59DwOXdxRto+q3DGbDPnKN2 Hb0/LrbhBL78bjMtHpmAug21peA3QjYFAdM+O1ikva/Mq8QKEjAgN+joe16JpJUUYDTZcpth 8Ho2xitm6fQn0rX56H1kzWc0YuMzJYZ5rZLtLaJMoXPpuCszZPFN3AHArKJPmjANt0T4dGdo Qm71wGLMqI/BCCLYS/v6JSjT0ZSgRlFNPTIo0tXpaPw86dLK2rVmuyxXTC7bqQxRTRni0Ihb dC7ATcjuCvG9JE+Zi/IFHgnRFXtsnszM6vEtJuGoMC/PGMs6KfIN1IPeFxZFPn0Av1agVkA0 eKxqCOX4NiuElJkynFsXWYIffHxdK466KE6H/LRbSp4fHbz4tmtEhNYwil7BIaWMDU7diS87 JX5azRFtUaIjsplRms1WSUBrQDpZG3eNEK3zz77NDiQVCMl4P7K1McVeqCoGkS9ZwwCi125p tTu/0Vbpvlsm0sToh/ehi0fVLsMVbliYWKb32saVhU8dRlYFiYeGfcnNy/vBhL6YDGeaKfLP izUlYrOv2ICsCz1obgI9iSte1qTNOXzFxdjfczPW61Jw3x41wTKfNw+cn3oa0S1NN3FQsmxf WHqR8ApUgn74tw1Eytj3Lk1989Sd9zBVe4VsaF51BSctOIxdAt3F+Ye/sKBLWAphOHNmM59Z 1PXbxXxgBJtXJ280/GPCaJFlv/g7WYMUk2E6AIKSj/N1fKEMxE87lIXwAqRbNOElCH4QUPAW jJ2TOLU9xXC/WO5f/tlQDiNvJ+A6pNwMN3TsF+EDqzvpQ6PrgK2Xh3GLUp/Mnz4ZXl1c6iLO Pv5ZCz6hysf0QJj62BNH6oEEnZezHiN6I79+ls+WScZGv0MaSaMowL7WqyXtUaC8okKvruNu d5+Kj+Zb5m8P8j98d/JsZAqUOL2yuiOxYJzGstD95rzeB/aawUJ44oRY+5iuxsCaFGl3Vc0M pBHDdvkq864i1ylkSQD412bycLv2YVf1ODCix/KgWxN98APPF5TcP7foGome0rMq3zTBuGcJ hWFSdCzPOyrwZaNZYA9IYAcF7XhMhKh+IeJ5H4ToHBSQhToyvOiDSsSs/7EPw5r2Q2Q705yW SodJ0HeP6Z1emVI0vNY/TvgI3aC66/aN9Fmvu3Fu1oVat1Ffo0zLqHRDuZgB3I1wcJTjlGVd TrhreUsTwZdhObaz6Toi+wTtEkxVdFtr289ow23ADggNLDK2cPN9N5pImIcjA0O47nav4ED7 DsxRWtFu2tX2+Jk2b9Pe+3rfVWdKXCXeHypCF63ELVblLS0su9Sn3/DGJKhwrvBFVrC3VKcz 9BdsdUagd9oVb/XC1ejklfQdW4jGFltT+iDh8Zs3fzr4SS/UlR+dB5oSI6UJ/a6qo3NKfR+8 tCvropvuZz6zLIqB51VGhHbADzrYASPcyzGZZcIkUUKs0VTcuTSR/+YZO4P1exApigHTDVMo C8/HY+ehNQQSKojXroAjcSutwuQf9OL/lo8YzpKq2h3cluJKbh0L8RkC2MMfqgOsYQgrI1Nm sCRQxffg5rD7kA1NFtDQNGCGvhkwbJ6l9b1VetNQWMMUmG9eFvga6aA63C3yru/SfcmgOSec EdcQdldi7YDN+GT4Uqs7991mkfpgoFGtzV5jQ+8EPWoU+ZarrCEKHSlqK7qGE0pwLGU6+gvE xg9TnhThdr2rz5TOw2VQxjLWPQADaIeq2u6r0ph5SJqxnKlvOsDsra0/tZyAZ/BHdW9Yai32 JG79LsvmgQb+pJKlSOPubIOazROjS40ob2ezbGWRaXeebZuymFwlmyWvkYn7XPHmhzenyqfv rv90dfNfrQndvir8DykgBeODyg+CC/vQPlVxomXcVq4SqSOuqBsoxFACbnHID9PQBYOZVpGL 3X004atysIzHimX14Hy+JJT3RbItuCt/jqRx3VEtC5F4516ZBmS0iWi16dKsw/n+qsQ2GfqY 2O7jSd9d7oWBLB4vdgB5gHyW02GCBB2zD2AS9Y8JnBR902B8mlhCJSET9DWuftX7RPx3m0Fc z514bK+cK8ylsg8W9YJWMaPZGurDgLAdOtT68NiNhsGwQMkoNx3aoJzNcKUhLgg3PKpNUEt3 M9+/pFtRqKVeJOxHyY6vaCykpU6LgvgaYlRaIS0LeVjiQUgxQbYdnk9kJHugp78gxrphC2Ex zhigB9ACHnOb9HiJwWBZ83lyHsjx+vTH89N3pyfH4sy+OX337u3V2/OTt9fu9dubT2/fnvtr sM7fuJOL85/eniM1efxB2fjy6kK+en1xFXKVhLaO4/Y5qDQNyrt364ZN0PeE6HIg5pw95mSe Nl0LZPvaw2bgwKFp/1Vt9KiRnhffhpiauXmfMovgMxIcLgfvMkhK8eZKoZFEuOg3sTYv8UWb VkUSWiIw7mQOXAALJej86iH56veZ7mYIzrd7CbFiADpruOEi1UxLO6sMrlrfkEGEqLbg7Uw/ rbXzJ9G7P1x9R7Emwg2DE+0Wt2cZRSZRBzllI6XXetN3gFMVuNxvE1Xm9Au8oH7RkA29Y6tw jWjiLxZF67lywwiEXru09TDvJtmtRA4OGNKYiUNWrgf+FuZP/tqDxHJmYkM1bMMQug0/f/aP 0c2Kpo+tdRd67ELnbjNvx6nWywBczKxdna5r2o/C7JWh+vg8FMuwKBmkm8DiCN5PPWkLC4dP ZMgJ7cVJCM3R06kn5XyC8Olo2g8A1pa365JKSuK04DZ0L8z+je537N1OA3EUQstMYMcVRvKK sz/1gTVFuecGsi9LPXqkVQ+DnIm/uYSqQ+UrAzK3O+0YuZ8o95CbKEzNO7m7/H8Q00V3HYX3 nazeGwthxLtn5qOSP8Yk+os39KaqfdNfW/Qquqdus0dv9akNccqeLEjLTt2w66ndH9Ev1d9B CxwtK2IeGU/HGoWe1K/cB6Sg9MMY08WbI1UKE/NgzI6IUl4FOTAg3Cc0NBpA2w3cUf/NaHyj 76Xwi25dPIy/6JuHFmxGDv3T9XXXntLmlY59PfKtmBw7vfB+rE2u9LKNx2Laj/UR79LHQcvB AeYNOyhmYLNVZS1ekYFunI3afzqcfKpWYfx5QKl45KhyDSNRBDBatEjDUzntGK8jCiJn+hiB GapgIyLZoyZfg+7HtKCMDaxxWeupXoRRJkp5+6KX+ilO/tfZrMqacJd8mBRh926vaV1b9Exu fx/rRk6KbQjLhwGZKfoY+7iLsVhT9mC/f8eMhyybQXLPllkEJn28bXx0IQanwkgMpeMaGBBG nC3ebE2tKv2luQplyL9APEy07mqiWXNe/smkH2OsU7t/tJ8QMpNW6LsJPTd06hcfb7y0HHRl qZ4uB2Pr8aimQ2oB8drs7SrAu2OcfqgPC1Yw66oscXorj1p/4srXvwEKoZ2XPQNp8FcPED9v 77aEMe/zk8YLVyZILXdXsn2t9oC3A7JCnpJNTpKVpW97SVHfzSBO355am/kgbruJmJBNIpNC h6N5OrE7jdhnCuc0QQ5PZzOOIl9MOKF+Vy0VeEgGdzWNCcVN6tuLCN+29a6bH7PTjzF65xxE IVOjwn3UlVENQNpPn3wMKLBOW4bW2uaBod2UlYWwhcNi2YgtUPkNAqkpwkAPwTqZaw9SK30D AQh/L020dpnTaOZUhRuUjqkfRM9iGjddMZhFzF161x7EX31nBTyKEyi8kagJb1KD7+QW40yQ SIjyynG2YVYhS9odmCK3lHFrdOasNG6zXK/Rr5guXrgCsm9ReBKgHrTO39bd/auH3TlX7IP/ 96TdniPNzpnBxpHf1CZY/06YQl+7P5i1q/Sxv7E2WdMfccuT9ikTYmXAPXOTiQHZ1FsTfZXf 6yUpxT4Qp3OJ+mZnuGmuD+xBDUKVLxYcLVhKmKQJAzqgJB6263+0rU5wI6vMwN5s/E38bZBE xv2PmFMMd0amaJTTs2t8TLm0t4yaK2pGY7BBhij36RVAtKHywhAGyWOYu1Dz3L9xhn2jprxw KNEACv34ehzuoDh/+9PbK8eGz30Xe+gdGePOi4sLdQ9WmQr0vAlX59nFoAWYfa0YA9m7bW4+ XRjzq6++GgXcYAeItR70ShtdVYiimZcikWA37HrKazT9AvhQgZ6dm6ctI40m/CYo9XQ3KlFk zMMUIvLemyRGrnwgQ7RWVeV7gkCznTSgsoDo4uTrzF/AaGhQlDzpleQwGpQy1UGLGKKJezvB OCy1KY7K5q5TPELb4cZRfy3vwGY4eMglvnk16YayBeDtVVsvzRLwhzZG8BSX68rO6EVzdsfn NhEKaIV8V/u9PZNQyYOc4XQ6+s8KLcvS+c5/9TKpvEJV82bqjmtemOZv0Eg8cKN7aqhWlt2z enpwYZgKtNX1N5qanAatw5iKei/UutzUPLloXASo0H7TRBUkuVcWZFR9BiUaPRlhvhrDD/Vj RmFXHMHli41QmI2AzNFuk7DJr9p5twyQ1WP7JyK0BJR3qR5bRARXAiSfVYi0SVRAg/q1KlX9 J+3OrTFKOG/WWzi0huvb9bwNVs3NL7HEr3ODee/KEkrbVu0KIw6igCAizqSzNwjRBkJ4YDju gUdtkwMMtM0wZKjfWScKPlLjY1YueUOhXiezZ60oJmDgL6VhY4AB4qlZFTpPdhuj7Zu8iGaL Sr4DgWiNGgCMbHdKerj7w8WYCA8NGaw/lgGZrbvexXXAvu8XrsIiilpm6aV+olhCIXPoxapW JDzbkOQ1pLK1ILdTA7mtb1csErhDV9UfL7TmnahYrHDT3YFil5/w4leU2zHyrbecV1kUVWTQ RNZZZJ9ptwbzn7eeWfXuq8kBm+XTQ9hnFE39gleSSIl74eEhTFZ6pSly+Q6YUnQh8xr+Rgw1 2cMmKNOxWttucoljX7eymbN9ucTVYEvYXrLiNdD3JoJhRE3qZud7esOB/yu+S6ahzzZWN/Ov cZjaSyS+XOOIXlr34PVfWWmrOIDmq35RG7IO3Pp4hI4dvgUzzEHiUoCH0npE9Y68qNK+u8hG BMR61AzpNkn3EhD9ijr3sY7rGIzC2HtfKdsWhVKOr1zXdQommscFWxiQkIAwFMLPEOaeWjvU QP9Gn9BxgOihWdLzSZHmoH2gjNhWbCigd2vVEFfqZ5hyhLycxmZDbOnzNrlO2LKXlK8DGnfW BBszJtqytJrri1WEWwuLqPon0NlYE2Z2wWlHKkRD1q2cV4bmjhfdvZnalJaNtNBfuoOYxRZI 1CZVpbvi8emaqvSBvogXqfLFR0h22pqsxwQMkVlfapJZuNQtaDLfDLr2PoWZTZmdM2CUDSFA xDrHGQ4cLbk2DvROIjshYtyu2QFv9mG5jgqFwTJP06wYGMoBRAYNwSJ1T157+STeI6FXVAAx o17dRNirwWUdX0Fi7ff2ZIAHgqBzZN6fnt9cK+KkL9TGVCtJvlaPg3zXFSEjpJBVPkd40q9v CH08rY0C63ODGNdcB0E0XQSBCNO9fh923m3VS32w4tjLHt99Q+P9FVu9OnR6lf1vU9VuvnET oMbWFKMfAvUNBBjeZP2rZ9fYuvO8+9g6bDdUjwOGRITitNfbQG8+VzEXvZBqHZhPITOEBAaE ps+W1tyc2JKo1kOhLlW4+MUNunuo6kGveYVvRxy/jrfX4hIp6zTu+5vsXbW+d7PfI2Fj2MyG /hcORXAfwc/+7pk5MPF1K97meGwHGakznmOTavCZd/iQcjOYGmowEppAZm0q/+ULRg7EUIGw 9MIAmse6Bhhc04K7XRF5pYvvY9NvwgWhlttE3y7vQyCubsDFscpibU+VoR2vKaKFQgoAH+BF 7d4l5nq90VRaC0TrZgKriMOxaj5qTjBLenCFB7ys0sz3Jvw7dZRERYUCSNuovTLIuMkehNSd T177flhm0vnxzXvgxEI4WFSPRth/Oru29gWgMIPvBM4ME/ODaR1Grgl0REUCEKKxQpX9+s2Q TrCgir774vrdwaG9ODLKfOGpzuLBy/x70Fz277zI9k4LgQzjeX5jGs8FmFK4MUB8E23iMWcl svAFRDcuC0uUNY364QCxitg3H1Oq0WO3xWFPeSIouoSqBPeErmDI95h2fSSGtubrMuIo2PlN XtTh/fOmzlZzg1t9y7uEkqD5475QYBkS6M1rkv5utEcVfXUaaVKb2q+o0xCfCicQtKhiu5xY Clr1tS0L8xDFkrablhU4Aoxmdyc7E2y4BircKJh0VzxZhEi7Gy41+mHGqS8axEq1e4l2DsIV jMnuNuuarzreuh4ApTgiCi6fsfU9hOPqENgtPm4SOAKFNvu5EXTLKPn52HlU91WebeCS1Vu6 969Es/2LMwhFVPDs/rdR0tcoFtYMu6XfObAW6oUUNpECSly83tYuajJC8dvrU4zxFge5r2eO VVoUhKtAWV6uRQ16qbwMv4Au9+2m1HdY5LP42j5ct2ld8OC53bZqE+H2KUU4ayK2u0u2SC1l +0KIutAcTl1ayygfIyDGCYF8dk1iSgaji6rM1X48eWOqWttQUhD6uI1tw9Mn2sSoPtgkDaxI wFFZj/OgG6q/t1fnykC7oS46IAedZl5kqh3hjg6fvfh2rH8d698v9K+XY0BfeHfvm3yRN+hn xeRKQWWkqSBtbOVPrMoMe941bNK3MT9jdeF1dNevG1790xtcRlTdoYherwmWt8RHo7aNHY6/ ulTlhwX8eE22uAa7gSxIHe+CRwjqYO+uuRC2eu1aDjrmPRaVb59FuvQP+uvt4SuPScIq8HkB SLIb4UDyTe1zV8Eh7BzyIJTtpmLv4Pj2uZGW0It06gO7Xpl3lMfVD5cn4fZfRO4gGrB8r1g0 5dQjxJqAgASUsOA9Tzu71MD2EdKMJnxmd1R3GJ8hJPpdHd+tkSL8LeKxyUM9jfyr0E4Ydlmo jdM1cYssGiggmibmiN93xPLKAyJwPbkKBd+EVbZ0kAfXfOBlfWgusw3KDmV9nT5dG47ltkx3 phE9uS6txc07wKezShELFhXRQ1ApYam5W2h030CvyxQHnkwQWBrG7cfgKi5tFatwLYl1DOGC 9RKeHy8/eKk7gDhboUFynQ1GKnn02sDoSikPI8c2dRqbetQyjlYsf5ftVMraVbkREAs1N48O zkxpMPQp2eA/8LZGfzM3jBfcUpuvkwVdBcXCfW0R81UXfCRCoci935TqZTAeLr9Z2e3FA1DQ QFurkRzRcHGAPnNi2DbQ6f5mmnBXF6mHk2WMANbvBjpdy49I4toDUPsKQRhuK6hdbVB3m4kg vLepR+pF8YTQLMI0UC3aZ1wH9G3zogt4O9tcRUasrTZLsbvqcrPcIfiq2vf07P1FuB4uPCFG uVFKWk7D8/DMMzSW0gLYDvUkX6cENxBwd/1WDKYYFCVSG7PW+jBBzg1AMsHcHjx90uFhKLlu K/QDfHArjwcp1naqMv+lMA28m0/0LjabDCkJT3e94pxZPzm2lTcUvBCNAEm9RUdoaoHml7h2 r9vcLkoMFgkmg/Wiys0Oe+QCLDxlm2jojotgzl3btTY/nn88+JAX7eeD922VHvgq3JEQ8V1W FVq75m+2Q+xRT8ufjTY3MbJQFCiMnzQv1x3yNC9ku3I25AvWGVqfwrSACBrmdj9xFxFe57Oq VNlA/Y/eane4pHSE+4k9stZKnUMeidjjBuQNI3dYKI5MS5/s16IIJ29GHtOkPfNKohFCuMc6 b8ddCC1YK9ZGqxF1Rd1CJ/6KFa0hAvo/HoCZWD8hK8cMirEbunelIBY00GkO/Dwf3J9oDSNX i5KJSoVJ9GIHMluRJHUI1oi+v0da5laOXP5ZFqH/CyIayqF2be31JwW5ma1PCai09HOLxg5l uNMAS8Bphn4QMrr17jYoednHnUCPshT56ZOBBmpr3ykd0xhYQX4eOlj4BjLh3HrvHYLr1MrM 6A/S2fLSux45M4799327pP5o/Yshh9usR5rWVzSiEtEtWrfq+wKJoyQW7udRKKKz/oRCwLO2 pm2ijllLxwZxIg1NuBBb05a52hkn8fPVHAZjNnbQHbL549nZ8dVfHqRV48T3LYfKEggVmBWP 4M9Drbe1zGCR2avJ0I/72MU8+gn+XJs09TBaf5G1v3uq++al3RV3k82WRSkOx667xWT6+++U 9wt3cibyvXvqhAjMGziLD//Iy3BVthu+mL5wRT3qHnsjtvw14jmP/Tl8Pv1+vXaf3eGL6cv1 unvqhn4jYuXuhJe69Z6avngpk1ytAr6Vq0pmdyCrR/98+/xQPJvCXf543D1xHkLA13JM4kRc oobB/hx9fxiNzRroN7mQz0ajcNGfo+fuEwSMLl3RrPuPXrcbFJft/3k+fe7uy5W/MYrb7GP2 pwWMj73vP9NtDnIr51WU/tmLYkKT9c1E46e9Py/dH/XuUn+T29jaFkw05zPuxvnVP4qUs4Tn mCUPbJNJbIL/1zz3V0vF8zr9/zmvL09kjJKH4+vz+pGdunn96EiM5/yB4bvdJMSm77M/uJcT ne5vnJWwuS0Pl8HZj99Ozji5EOx8ZGanj83spU5srBNz0cTGfmIc9DdOTkNcvTEnvTHjiXZj +qJKbXftPqJOOPzx83+HjK0WGtZ6MZYWNIpu/On4z79xgvuXBPqHXrf1lx+6tj6ndqNn0TWR E9dp+hvfbFXsB9HNyHg8ErcE4birizO2y6jmcDb8n2ONB3vniHl+61j2G99v6d46vKV77idr DOT7GPekqy/uYUVHlv5BJJ/ddfObXhv1gYpEmL/68bE3PvfVRI8+CQL/kvQ3xo+mdsrcxJVe HLX/50uFA9jc48lt+fm3suRbfhn2wzv8FL3eCikvPT4u/vP7Sc2bEfpg3T47PPLc4bMHz9Ec 3A9CBBi9IWUY9fJl5Y8UlGlFOPMyaAmRFXstvIjZKeGC0eJhu1XLjftmN6nZObw2cdwLaPmr jLWbiFc2NGRrRh7FHWb/mWy1yeKrA7x7ZXbuLTyG6iFyVUZ66+PJvbXdIpANELe1VEb1Z7GE Fc0LeMdd4YQ6vQUS+HV3lZTTm4M0zNhdhk35k+TR3XkexcDrQt0wbqpDzIv4Ktl93iCmBmOT tmqSol7TG/yheqTROE/Xen448FBIoKZRe43TvZKNGRAn6YNt0UaqdRvPIurOYO2HfHIqtMqz 20OePnlzfSlO2PWpXuTASp1w6ezUffBr8dfXuu5SXfaac/UsN3DLhwzRE2A8O8cmmmYZU1C/ ZXN8/sjKp0A1EQUReiQ+fXJ5DUq0ZgVq12vMxqry2NJZHB9Ek5Ws6paSdWxhnar1nrTdcp4U EIU5iuHVd9HOFwiDiJ2CSKIPkLIx67YAWRk68emTZdNsXh0czCezTTtdJGU9FYdAuwBrDXFt BRSoHzr8/TPFc/krhYlm0mbw4MFFXtDd+kpXeoSl2sKsIYi8l3Sjde+r0JIzMAAakIUMG4cl 7nYQ3b/9D88Go+4em7oL3Taw5vOf2yxCHzdl6UHCny3lQ+oQMoJaQVNTjZXAQ5q6q8z6LPjx fT8unUq840xS7d2oqFedh/vYyjuiJhCtLpLbbLJJNuwKIcJLt3273U5169PsINvMj549OzzQ zXuOzXv0HVGMglw+JkK0I8vJ+4tPNxe8K0cLIyi7sFOzPML7Yumcbp1h/wOAb1GWi1U2lT0T Ovu/UEsDBBQAAgAIABJrDytGq2oi2wAAACcBAAAKAAAAUkVBRE1FLnR4dE2P0UoDQQxF3wfm H/KosN22guCjS60oKBSpHxBnszsD08mSyXS7f+9YEH0L5N5zko999/S+b/WiDTyst/fru81m a83RE1BykTP1oHRRCBkwAYrzQclpEYzAZ5JzoNkaHkBr5Xm1O3w2dRQuowcEx6cJJWROMAf1 19ANocTl1pru7fDS/UdSC0dfRb/CvKRa0ODgqyj0TNmaxFqpVQwY45XXk2KIuQEh7P/OgBOm gtGagQWGInUhEFIOo9cWXsHzRDVdNZ7i9PPdMuPSWmPN7JeR6HFYuam0LKM131BLAQIUABQA AgAIADdqDyuhSXgbIUsAAN+/AAASAAAAAAAAAAEAIAC2gQAAAABhbHBoYV92c19mLWNwdS50 eHRQSwECFAAUAAIACAASaw8rRqtqItsAAAAnAQAACgAAAAAAAAABACAAtoFRSwAAUkVBRE1F LnR4dFBLBQYAAAAAAgACAHgAAABUTAAAAAA= --------------0A2DA751C982A11F90F9425A-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 15 21:41:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WP-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:13 +0200 (CEST) Received: (qmail 16092 invoked by uid 0); 15 Aug 2001 13:33:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 15 Aug 2001 13:33:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA08631 for ; Wed, 15 Aug 2001 09:33:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 13:32:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA08363 for f-cpu-list; Wed, 15 Aug 2001 09:32:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA08360 for ; Wed, 15 Aug 2001 09:32:56 -0400 Received: from localhost.localdomain (nas25-30.vlt.club-internet.fr [195.36.224.30]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FDWKb30670 for ; Wed, 15 Aug 2001 09:32:21 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id B009113E5 for ; Wed, 15 Aug 2001 15:41:30 -0400 (EDT) Message-ID: <3B7AD06A.6C0A9589@ifrance.com> Date: Wed, 15 Aug 2001 15:41:30 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Aug 14, 2001 at 03:25:04PM +0200, Yann Guidon wrote: > > hi ! > > > > Juergen Goeritz wrote: > > > On Mon, 13 Aug 2001, Yann Guidon wrote: > > > > > do you have a link to basic floating point implementations > > > > > that can be used to begin with a pipeline fpu unit? > > > > > > > > There are some docs floating around on Internet but nothing > > > > that could do the trick for the FC0 (due to its specific structure). > > > > superpipeline + SIMD is not easy to do. > > SIMD is IMHO not reasonable for the FP units. A reasonable approach is > to build a set of pipelined 64-bit FP units, and then issue the 32-bit > operations in two consecutive cycles. > It's a kite big area but we need it. > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). > In sparc, there is no 80 bits float but 128 bits (2 registers used in the same time). We don't need 1 cycle multiplication so it could be done for the fcpu. > While we're at it: something that I miss in most CPUs is `variable' > register addressing, that is, accessing a register when its number > is not known at compile time -- like get and put in the F-CPU, but for > ordinary registers. I know that this is likely to cause trouble with the > scheduler, but what about mirroring the general registers in the SR area > and simply use get and put? > This kind of readressing register is a little bit like memory adressing for DSP. Register just contain address. But it's the same thing that using memory, it make a much longer pipeline, it's hard to manage for switching context,... nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 17:14:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WQ-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:14 +0200 (CEST) Received: (qmail 2172 invoked by uid 0); 15 Aug 2001 15:15:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 15 Aug 2001 15:15:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA11926 for ; Wed, 15 Aug 2001 11:15:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 15:14:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA11477 for f-cpu-list; Wed, 15 Aug 2001 11:14:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA11450 for ; Wed, 15 Aug 2001 11:14:27 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FFEBb32325 for ; Wed, 15 Aug 2001 11:14:11 -0400 Received: from f-cpu.org (nas1-3.aub.club-internet.fr [195.36.202.3]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA00590 for ; Wed, 15 Aug 2001 17:14:19 +0200 (MET DST) Message-ID: <3B7A91B9.2D0D0E42@f-cpu.org> Date: Wed, 15 Aug 2001 17:14:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > > Michael Riepe a écrit : > > > > On Tue, Aug 14, 2001 at 03:25:04PM +0200, Yann Guidon wrote: > > > hi ! > > > > > > Juergen Goeritz wrote: > > > > On Mon, 13 Aug 2001, Yann Guidon wrote: > > While we're at it: something that I miss in most CPUs is `variable' > > register addressing, that is, accessing a register when its number > > is not known at compile time -- like get and put in the F-CPU, but for > > ordinary registers. I know that this is likely to cause trouble with the > > scheduler, but what about mirroring the general registers in the SR area > > and simply use get and put? > > This kind of readressing register is a little bit like memory adressing > for DSP. Register just contain address. But it's the same thing that > using memory, it make a much longer pipeline, it's hard to manage for > switching context,... Going through SRs will solve the problem about the pipeline. Of course don't expect to use this kind of tricks in "fast" code. It is only provided to avoid self-modifying code or 64* code replication. The number of lost cycles is still unknown and it will be implemented only if the BIST can be appropriately hacked. There should be no modification of the instruction set. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 17:41:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WR-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:15 +0200 (CEST) Received: (qmail 4539 invoked by uid 0); 15 Aug 2001 15:42:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 15 Aug 2001 15:42:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA12684 for ; Wed, 15 Aug 2001 11:41:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 15:41:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA12439 for f-cpu-list; Wed, 15 Aug 2001 11:41:41 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA12436 for ; Wed, 15 Aug 2001 11:41:39 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FFfNb32725 for ; Wed, 15 Aug 2001 11:41:24 -0400 Received: from f-cpu.org (nas4-109.ras.club-internet.fr [195.36.203.109]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA26070 for ; Wed, 15 Aug 2001 17:41:36 +0200 (MET DST) Message-ID: <3B7A981D.898D4C78@f-cpu.org> Date: Wed, 15 Aug 2001 17:41:18 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Open Source Arithmetic cores Content-Type: multipart/mixed; boundary="------------E66A443F903307225B5AB107" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------E66A443F903307225B5AB107 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit while inspecting the Utopia Computing webring, i saw that Jamil had done some search on the FPU stuffs. it might be interesting. http://www.geocities.com/SiliconValley/Pines/6639/ip/arith_cores.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------E66A443F903307225B5AB107 Content-Type: text/html; charset=us-ascii; name="arith_cores.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arith_cores.html" Content-Base: "http://www.geocities.com/SiliconValley /Pines/6639/ip/arith_cores.html" Content-Location: "http://www.geocities.com/SiliconValley /Pines/6639/ip/arith_cores.html" Open Source Arithmetic cores

Arithmetic Cores

Introduction to number system

download ps file or download pdf file

Introduction Floating point standards

download ps file or download pdf file

The aim of this project is to develop generic synthesizable Arithmetic cores
Most of the cores are synthesized on different FPGAs and gave good results.
If you have any comments please email me.
You can find the latest version of the cores in the opencores CVS
To use these cores of for any licensing information please contact me and check the OpenIPCore site


Last update 23 January 2001

1
1 --------------E66A443F903307225B5AB107-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Aug 15 18:56:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WU-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:18 +0200 (CEST) Received: (qmail 28987 invoked by uid 0); 15 Aug 2001 16:59:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 15 Aug 2001 16:59:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA14978 for ; Wed, 15 Aug 2001 12:59:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 16:58:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA14730 for f-cpu-list; Wed, 15 Aug 2001 12:58:44 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA14727 for ; Wed, 15 Aug 2001 12:58:43 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FGwRb02062 for ; Wed, 15 Aug 2001 12:58:27 -0400 Received: from jetnet.ab.ca (dialin38.jetnet.ab.ca [207.153.6.38]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA09480 for ; Wed, 15 Aug 2001 10:58:40 -0600 (MDT) Message-ID: <3B7AA9B1.947ABE82@jetnet.ab.ca> Date: Wed, 15 Aug 2001 10:56:17 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > Ok, here is another version of the text. > Please tell me what you think :-) > Btw, it is getting truely huge. > i have zip'ed it this time. > WHYGEE Zip's may not be that portable. Debian linux does not have unzip in the latest unstable release.The prevous release of unzip is broken. I grabed a red hat rpm of unzip. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 15 22:01:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WW-0000Q4-00 for ; Wed, 15 Aug 2001 22:44:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:44:20 +0200 (CEST) Received: (qmail 16233 invoked by uid 0); 15 Aug 2001 20:02:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 15 Aug 2001 20:02:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA18135 for ; Wed, 15 Aug 2001 16:01:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 20:01:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA17887 for f-cpu-list; Wed, 15 Aug 2001 16:01:31 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA17884 for ; Wed, 15 Aug 2001 16:01:30 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FK1Eb05725 for ; Wed, 15 Aug 2001 16:01:14 -0400 Received: from f-cpu.org (nas2-28.aub.club-internet.fr [195.36.133.28]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA01781 for ; Wed, 15 Aug 2001 21:59:50 +0200 (MET DST) Message-ID: <3B7AD505.F2417336@f-cpu.org> Date: Wed, 15 Aug 2001 22:01:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Yann Guidon wrote: > > > > Ok, here is another version of the text. > > Please tell me what you think :-) > > Btw, it is getting truely huge. > > i have zip'ed it this time. > > WHYGEE > > Zip's may not be that portable. Debian linux does not have unzip in the > latest unstable release.The prevous release of unzip is broken. > I grabed a red hat rpm of unzip. > Ben. sorry. i have put the text online at http://www.f-cpu.org/alpha_vs_f-cpu.txt hope you'll like, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 15 23:12:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15XAnL-0004mY-01 for ; Thu, 16 Aug 2001 02:13:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 02:13:55 +0200 (CEST) Received: (qmail 22310 invoked by uid 0); 15 Aug 2001 22:22:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 15 Aug 2001 22:22:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA22146 for ; Wed, 15 Aug 2001 18:22:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 22:22:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA21898 for f-cpu-list; Wed, 15 Aug 2001 18:22:26 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA21895 for ; Wed, 15 Aug 2001 18:22:25 -0400 Received: from tribble.stud.uni-hannover.de (root@a200.home.uni-hannover.de [130.75.232.200]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FMM3b08577 for ; Wed, 15 Aug 2001 18:22:03 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02302; Wed, 15 Aug 2001 23:12:27 +0200 Message-ID: <20010815231227.63958@thrai.stud.uni-hannover.de> Date: Wed, 15 Aug 2001 23:12:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7A3133.744063F0@f-cpu.org>; from Yann Guidon on Wed, Aug 15, 2001 at 10:22:11AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 15, 2001 at 10:22:11AM +0200, Yann Guidon wrote: [...] > > SIMD is IMHO not reasonable for the FP units. > in what context are you speaking ? I mean: I think it's unreasonable to build *variable-size* FP units. There are too many special cases to consider -- rounding, exceptions, infinities and NANs, ... (ok, go blame IEEE for it ;) > > A reasonable approach is > > to build a set of pipelined 64-bit FP units, and then issue the 32-bit > > operations in two consecutive cycles. > that's vectoring, then. Scheduling might become more complex, > in situations such as chaining for example. Not if it's "hidden" inside the EU. > I have nothing to object to that, but > - 1) currently we have no FP unit > - 2) SIMD already works well (when it does) > - 3) vectoring will be used in another core because FC0 would require too much changes > - 4) if you have 1 FP unit, the hardest is done : you can duplicate it :-P If you have enough room. Do you have an idea how big the FP unit will be? > > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). > > geez, the instruction set in the current version of the manual needs a big rework... Yep. There are a handful of inconsistencies, typing errors, missing parts etc. in it. Major things I've found so far: - The manual doesn't state whether `modi' is a signed operation I suggest it should be signed (like `divi') - Complement `abs' with `nabs' (negative absolute) for symmetry, and to avoid the `sign surprise' when the argument is -2**(chunksize-1) - The syntax for the rounding mode (`l2int', `f2int') is not specified. I suggest to use the following syntax: l2int[r|t|f|c] f2int[r|t|f|c][x] with these meanings: -r (round) round to nearest (default) -t (trunc) round towards zero -f (floor) round towards -infinity -c (ceil) round towards +infinity - `int2f' and `int2l' also need rounding modes because both conversions may result in precision loss if the integer operand has a large value. - `bitop[s|c|x|t]i' should be `bitopi[s|c|x|t]' (`i' is NOT a suffix!) - Assign four opcodes for bitop[i] and increase the imm6 operand to imm8 (for consistency with the rop2, shift, rot, bitrevi and loadcons[x] instructions). Since bitop[i] is a ROP2 instruction, change the function encoding to match that of rop2, that is: fun rop2 bitop ================ 000 and btst 001 andn bclr 010 xor bchg 011 or bset 100 nor -- 101 xnor -- 110 orn -- 111 nand -- I guess we can get the missing four instructions for free, but they aren't really useful. - The description of the ROP2 is obsolete (and the syntax for combine/mux is unspecified) I suggest -o and -a suffixes for combine, and a new `mux' instruction. - For the `andn' and `orn' instructions, the manual must clearly state which operand is inverted. IMHO, `andni' and `orni' will be almost useless if we invert the leftmost (== immediate) operand (but not completely useless, because the upper bits differ when the chunk size is 16 or more). On the other hand, we could add a flag for sign extension of the immediate operand and invert the middle (== register) operand. Since the function bits have moved to the opcode field, there should be a free flag. - There is no explicit `not' instruction, but users can write `nor r0, r2, r1', `xnor r0, r2, r1' or similar. Since this may not be obvious, F-CPU assemblers should recognize `not r2, r1' and convert it to one of the other forms internally. The `not' instruction should, however, be documented in the Instruction Set Manual. - In `bitrev[i]', use the formula `r1 = bit_reverse(r2) >> (size-r3-1)'. That will change the useful range for r3 to [size-1;0]. In the current version, it's [size;1] which is pretty ugly. Another possible variant is `r1 = bit_reverse(r2) >> r3', with the same useful range but a nicer default (r3 == r0) which makes the 2-operand short form `bitrev r2, r1' meaningful, but that may cause trouble when the register size is increased beyond 64 bits :( - `flog' and `fexp' should both take only two operands. Remember that (a**b)**c = a**(b*c) = a**(c*b) = (a**c)**b. That is, with a simple multiplication (before fexp / after flog) you get any base you want, and the FP unit probably works better with a fixed base. - We need a level-1 floating-point compare instruction; `cmpl'/`cmple' may work with LNS (if there are no NANs), but not with FP. - The arguments of `store[f]' are reversed (dest, src). It's ok that way (because it mirrors the `load' instruction) but there should be a BIG FAT WARNING in the manual. - Some immediate instructions may benefit from a non-linear encoding of the immediate operand (for example, 6 bits value + 2 bits left-shift). At least this is an option for `loadi' and `storei'. - The naming of the memory hierarchies in the `cachemm' instruction is ambiguous (in particular, the -c and -l suffixes). We can still use numeric suffixes [0-7], however. Again, the arguments are reversed (`cachemm addr,count'). - In the description of `move', remove the reference to `nop'. BTW: there is no need to give `cmove' a separate name and opcode. If there is a condition suffix, it's a conditional move (3-operand form), otherwise it's unconditional (2 operands): move[s]{cond} r3, r2, r1 move[s] r2, r1 - We need to clarify the syntax of the `condition' suffixes for `move' and `jmpa'. I suggest 000 -z (zero) 001 (unassigned) 010 -m (msb == 1) 011 -l (lsb == 0) 100 -nz (not zero) 101 (unassigned) 110 -nm (msb == 0) 111 -nl (lsb == 0) - Assemblers must accept `loadcons[x] large-number' and emit a suitable series of loadcons.n (or loadconsx.n) instructions instead. This is necessary for external symbol references (which are resolved at link time). Assemble-time constants may be shortened to less than 64 bits, however, and if the user explicitly requests `loadcons.0' or `loadconsx.0', the assembler should of course do what (s)he wants (and complain if the value is too large). - Can we please drop the `a' from `jmpa'? As with `move', the presence of the condition suffix indicates the form of the instruction: jmp[a]{cond} r3, r2 [, r1] jmp[a] r2 [, r1] - When calling functions through pointers, it would be nice to be able to tell the F-CPU *a priori* that a register contains a code address. While this can be done with an explicit prefetch (load to r0) for data pointers, there is no way to specify that a register contains a code address that the CPU will have to visit soon. The same is true when an absolute code address is obtained via loadcons (which will probably be the common idiom when a function in another object file is called, unless jump tables are used -- which points us back to the `code pointer in register' problem, again). To cut a long story short: I'd like to have an instruction that explicitly `tags' a register as a pointer, and probably initiates a prefetch cycle (for code or data, depending on the instruction's flags). It may or may not move data from one register to another (one idea I had was a `pointer move' instruction); if it does, it might be a good idea to let it participate in address calculation (i.e. let it be able to add two operands, like the `lea' instruction on Intel CPUs). - Let's clarify the suffix order, e.g. like this (? means the suffix is currently unused, and its name is unassigned): add[c|s|?] sub[b|f|?] mul[h][s] div[m][s] mac[l|h][s] # I suggest to allow `macl' as an alias for `mac'. scan[n][r] bitop[s|c|x|t] bitopi[s|c|x|t] mix[l|h] expand[l|h] {rop2}[a|o] {rop2i}[a|o] load[f][e][0-7] loadi[f][e][0-7] store[f][e][0-7] storei[f][e][0-7] cachemm[f|p][l][c][0-7] move[s][n][z|?|m|l] jmpa[n][z|?|m|l] serialize[s][x][m] - Some instructions (e.g. `mac' and `addsub') could have variants with an immediate operand. - The loadm/storem has a surprising operand order (start,src/dest,count), and it's not clear whether the register *numbers* or the register *contents* serve as the start/count values. I suggest the former, and I would also change the operands to (firstreg, lastreg, memaddr) which is much easier to grok for humans. Since there are some unused flags, another variant might be interesting: `storem r2, r1', where r2 is used as a mask (bit == 1 means "load/store register "), and r1 is the address of the source/destination memory area (which must be big enough to hold all registers, just like the CMB). Maybe it would be wiser to put the memory address into the rightmost operand in *all* memory operations (load, store, cachemm, loadm and storem). Some instructions will always have the wrong operand order, though. - And finally, the most important point: the new `nop' instruction is still undocumented ;) In case you wonder: I needed a break from VHDL coding (I couldn't even write C any more!), so I decided to play with something totally different for a while. The result is a flex-based instruction encoder that recognizes almost any instruction the F-CPU will have (with the exceptions mentioned above). I'll probably also build an assembler around it. (I finally found a real use for my libelf library! Yeah! ;) > Sure, there needs to be an expansion/reduction code for FP > but SDUP works for SIMD FP if the packets have the same boundaries. That's a different kind of operation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 15 17:14:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15XAnN-0004mY-00 for ; Thu, 16 Aug 2001 02:13:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 02:13:57 +0200 (CEST) Received: (qmail 2156 invoked by uid 0); 15 Aug 2001 22:23:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 15 Aug 2001 22:23:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA22442 for ; Wed, 15 Aug 2001 18:23:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 22:22:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA22167 for f-cpu-list; Wed, 15 Aug 2001 18:22:51 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA22155 for ; Wed, 15 Aug 2001 18:22:50 -0400 Received: from tribble.stud.uni-hannover.de (root@a200.home.uni-hannover.de [130.75.232.200]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FMMBb08581 for ; Wed, 15 Aug 2001 18:22:13 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01266; Wed, 15 Aug 2001 17:14:00 +0200 Message-ID: <20010815171400.05757@thrai.stud.uni-hannover.de> Date: Wed, 15 Aug 2001 17:14:00 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=OOAslEiF7prFVrbC X-Mailer: Mutt 0.84e In-Reply-To: <3B79F022.661E7A3E@f-cpu.org>; from Yann Guidon on Wed, Aug 15, 2001 at 05:44:34AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --OOAslEiF7prFVrbC Content-Type: text/plain; charset=us-ascii On Wed, Aug 15, 2001 at 05:44:34AM +0200, Yann Guidon wrote: [...] > 3R4W ? can you explain, or write a draft, about this unit ? > i'm surprised. That's only the SRT divider core. It takes a 128-bit numerator and a 64-bit denominator as inputs (3R) and produces a 64-bit quotient and a 64-bit remainder, using a redundant encoding (that is, *two* 64-bit vectors per number). You already have an early draft of the IDU core -- search your mailing list archive for the message id <20010302162502.24372@thrai.stud.uni-hannover.de> or the subject "Divider News" (or look for the "Blah2" entity, probably in a file named blah2.vhdl). > if there is a painful problem, maybe we can go the route of half-emulation, > like with the emulation of multiplies with a sequence of partial > instructions ? Dividers don't scale up, like multipliers and adders do. I have to think that over; maybe there's a better (and smaller) solution; I really don't want to waste so many transistors for an operation that is rarely used. [...] > > and I'd rather add a `tiny float' data type (1+4+11 bits) > ? > > > for low-precision operations than implement 40-bit FP (which is IMHO > > rather useless, and a waste of space). > are tiny floats really useful ? In some cases, yes (especially if you can process 4 of them in a row ;). Like audio/video processing where integers introduce too much rounding errors but 32-bit floats would be overkill. Whenever you need an FP type with 3-digit precision and values close to zero (-100...100, or -10000...10000 if we use 1+5+10 form). > > > // There is no floating square root instruction. > > > We intend to provide "seed" generation for accelerating Newton-Raphson > > > computations of divide and SQRT. > > In the FC0, we can probably get away with some bit-shuffling (hardwired). > > For sqrt(x), divide the exponent by 2 (right shift); for 1/x, invert it. > > believe me, if this was so simples, others would do it already. > The problems is that this trick "only" does not provide enough precision. > > The strategy in most computers is not to run the NR iterations inside > a loop, but to emit a fixed number of unrolled instructions. > The "seed" must be constructed in such a way that when the specified number > of iteration is executed, we get at least a certain precision/acuracy. > > For example, imagine we have a table that yields a "seed" for 8 acurate > bits (in addition to a correct exponenent). A single run will give 16 acurate > bits then another will give 32 bits of precision. if you work with IEEE floats, > the compiler will generate 2 optimized unrolled iteration bodies. > If you work with IEEE long reals, it will generate 3 iterations. > > If you "only" do an exponent adjustment, > 1) you won't get a precise garanteed minimum acuracy of the approximation Of course I will. Let x be 1.m * 2**e (with 1.0 <= 1.m < 2.0) Then y = 1/x is 1/1.m * 2**(-e), with 0.5 < 1/1.m <= 1.0 Let y0 = 0.75 * 2**(-e) be the first approximation Then y - y0 becomes (1/1.m - 0.75) * 2**(-e), and the maximum error is |y - y0| <= 0.25 * 2**(-e) Q.E.D. (I agree that it's not a *good* approximation ;) > 2) you will thus have to put one NR iteration in a while(){} loop > and if you work with SIMD float, the slow convergence of one number > will keep the whole SIMD packet from being used even though other > numbers are "ready" (converged). That problem won't go away anyway. > of course, if you don't mind, you can "forget" or "simplify" the seed LUT. > but the program/compiler must be adapted in consequence. With simple approximation (y0 = 0.75 * 2**(-exp(b))), it takes ~6 iterations to produce a `double' quotient. In order to reduce that to ~3 iterations, we need to consider ~6 bits of `b' (that means we need a lookup-table with at least 2**6 = 64 entries). 4 iterations cost ~2**3 entries, 2 iterations ~2**13 entries (which is too much). See the output of the attached C program (I don't have numbers for sqrt approximation, sorry). I think 4 iterations is good enough, 3 is already too expensive. [...] > > > I am still wondering if PALcode is such a good idea. > > > We're used for a long time to rewrite the trap handlers for each new computer. > > > Maybe this idea came from the VMS transition constraint, but there is > > > no need of this stuff in the F-CPU. > > We can implement a `PALcall' SR if we have to. > and what would we do with it ? :-) Play soccer? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --OOAslEiF7prFVrbC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NRdiv.c" /* * Copyright (C) 2001 Michael Riepe * All Rights Reserved. */ #include #define MAX_ITERATIONS 8 typedef unsigned long long ullong; /* type conversion unit */ union blah { double d; ullong i; }; /* `double' characteristics */ #define S_SHIFT 63 #define S_MASK (1ull << S_SHIFT) #define E_SHIFT 52 #define E_MASK ((1ull << S_SHIFT) - (1ull << E_SHIFT)) #define M_SHIFT 0 #define M_MASK ((1ull << E_SHIFT) - (1ull << M_SHIFT)) #define BIAS 0x3ff double epsilon = 0.0; /* accuracy */ int approx_bits = 0; /* approximation quality */ double divide(double a, double b, unsigned *iter) { union blah blah; double x, y; int asign, bsign; short aexp, bexp; ullong am, bm; unsigned n; /* decompose a */ blah = a; asign = blah.i >> S_SHIFT; aexp = (blah.i >> E_SHIFT) & 0x7ff; am = blah.i & M_MASK; aexp -= BIAS; /* decompose b */ blah = b; bsign = blah.i >> S_SHIFT; bexp = (blah.i >> E_SHIFT) & 0x7ff; bm = blah.i & M_MASK; bexp -= BIAS; /* normalize */ asign ^= bsign; aexp -= bexp; /* over/underflow checking omitted */ bsign = 0; bexp = 0; /* that is, 1.0 <= b < 2.0 */ /* restore a and b */ blah.i = am | ((ullong)(aexp + BIAS) << E_SHIFT) | ((ullong)asign << S_SHIFT); a = blah.d; blah.i = bm | ((ullong)(bexp + BIAS) << E_SHIFT) | ((ullong)bsign << S_SHIFT); b = blah.d; /* first approximation (i.e. the F-CPU `fiaprx' instruction) */ blah.i = bm & ((1ull << E_SHIFT) - (1ull << (E_SHIFT-approx_bits))); blah.i |= 1ull << (E_SHIFT-approx_bits-1); blah.i |= (ullong)BIAS << E_SHIFT; x = 1.0 / blah.d; /* iteration */ for (n = 0; n < MAX_ITERATIONS; n++) { y = b * x; if (1.0 - epsilon <= y && y <= 1.0 + epsilon) { /* finished! */ break; } x *= (2.0 - y); } iter && (*iter = n); return a * x; } int main(int argc, char **argv) { union blah blah; unsigned n, maxn; double q; int a, b; /* epsilon = 2**(-52) */ blah.i = (ullong)(BIAS - 52) << E_SHIFT; epsilon = blah.d; for (approx_bits = 0; approx_bits <= 16; approx_bits++) { maxn = 0; a = 1 << 20; /* some reasonable number range */ for (b = a; b < (a << 1); b++) { q = divide((double)a, (double)b, &n); if (maxn < n) maxn = n; /* printf("%d / %d = %f after %u iterations\n", a, b, q, n); */ } /* result */ printf("approx_bits = %2d -> %u iterations max\n", approx_bits, maxn); } exit(0); } --OOAslEiF7prFVrbC-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 15 14:14:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15XAnP-0004mY-00 for ; Thu, 16 Aug 2001 02:13:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 02:13:59 +0200 (CEST) Received: (qmail 13385 invoked by uid 0); 15 Aug 2001 22:23:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 15 Aug 2001 22:23:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA22677 for ; Wed, 15 Aug 2001 18:23:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 22:23:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA22397 for f-cpu-list; Wed, 15 Aug 2001 18:23:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA22379 for ; Wed, 15 Aug 2001 18:23:07 -0400 Received: from tribble.stud.uni-hannover.de (root@a200.home.uni-hannover.de [130.75.232.200]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FMMgb08596 for ; Wed, 15 Aug 2001 18:22:43 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00519; Wed, 15 Aug 2001 14:14:08 +0200 Message-ID: <20010815141407.43955@thrai.stud.uni-hannover.de> Date: Wed, 15 Aug 2001 14:14:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B79F01E.2CE07BFE@f-cpu.org>; from Yann Guidon on Wed, Aug 15, 2001 at 05:44:30AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 15, 2001 at 05:44:30AM +0200, Yann Guidon wrote: > i've taken a short look at your FLEX+BISON file and it looks > interesting. However, i wonder ... what about those who > work under Win/Dos ? The remark also applies to your scripts. > Btw, the idea of the scripts is not bad because it spares > us one compilation run. The scripts will also run on Win32 (if you have bash installed ;). The problem with them is that they do not check the syntax. That *may* introduce Big Bad Bugs (tm). The parser avoids that because all expressions have to be syntactically correct in the input. Please let's not follow Steinbach's Guideline for Systems Programming: "Never test for an error condition you don't know how to handle." I can try to make a win32 .EXE (using LCC or CYGWIN). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 01:10:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15XAnQ-0004mY-01 for ; Thu, 16 Aug 2001 02:14:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 02:14:00 +0200 (CEST) Received: (qmail 30934 invoked by uid 0); 15 Aug 2001 23:11:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 15 Aug 2001 23:11:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA23652 for ; Wed, 15 Aug 2001 19:11:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 23:10:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA23406 for f-cpu-list; Wed, 15 Aug 2001 19:10:59 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA23403 for ; Wed, 15 Aug 2001 19:10:58 -0400 Received: from tribble.stud.uni-hannover.de (michael@a200.home.uni-hannover.de [130.75.232.200]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FNAeb08964 for ; Wed, 15 Aug 2001 19:10:41 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03229; Thu, 16 Aug 2001 01:10:59 +0200 Message-ID: <20010816011059.37312@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 01:10:59 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7AA9B1.947ABE82@jetnet.ab.ca>; from Ben Franchuk on Wed, Aug 15, 2001 at 10:56:17AM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 15, 2001 at 10:56:17AM -0600, Ben Franchuk wrote: > Zip's may not be that portable. [...] They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Aug 15 23:21:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15XAnR-0004mY-00 for ; Thu, 16 Aug 2001 02:14:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 02:14:01 +0200 (CEST) Received: (qmail 29995 invoked by uid 0); 15 Aug 2001 23:56:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 15 Aug 2001 23:56:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA24470 for ; Wed, 15 Aug 2001 19:56:05 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 15 Aug 2001 23:55:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA24223 for f-cpu-list; Wed, 15 Aug 2001 19:55:30 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA24220 for ; Wed, 15 Aug 2001 19:55:29 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7FNtDb09255 for ; Wed, 15 Aug 2001 19:55:13 -0400 Received: from jetnet.ab.ca (dialin60.jetnet.ab.ca [207.153.6.60]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA18844 for ; Wed, 15 Aug 2001 17:55:22 -0600 (MDT) Message-ID: <3B7AE7DA.EEF74899@jetnet.ab.ca> Date: Wed, 15 Aug 2001 15:21:30 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <20010816011059.37312@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Wed, Aug 15, 2001 at 10:56:17AM -0600, Ben Franchuk wrote: > > > Zip's may not be that portable. [...] > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. > There is still a lot of arhcival stuff zips - cp/m dos and dusty old programs off the web. The problem is not finding the stuff is finding the archive program used to get all the dusty old files back. The problem with the linux unzip program is the runtime libraries changed (newer version) and I could not run the old program as something had changed. Ben. PS: here is some "dusty files" that will get you far away from VHDL. (Zipped Vacume tube schematics) :-) http://www.triodeel.com/dusty.htm -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From majordomo@seul.org Wed Aug 15 03:33:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15Wqbh-0002z8-00 for ; Wed, 15 Aug 2001 04:40:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 04:40:33 +0200 (CEST) Received: (qmail 15415 invoked by uid 0); 15 Aug 2001 01:33:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 15 Aug 2001 01:33:01 -0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA29697; Tue, 14 Aug 2001 21:33:00 -0400 Date: Tue, 14 Aug 2001 21:33:00 -0400 Message-Id: <200108150133.VAA29697@belegost.mit.edu> To: sloyment@gmx.net From: majordomo@seul.org Subject: Majordomo results Reply-To: majordomo@seul.org Status: RO X-Status: O -- >>>> subscribe f-cpu **** Your request to majordomo@seul.org: **** **** subscribe f-cpu sloyment@gmx.net **** **** must be authenticated. To accomplish this, another request must be **** sent in with an authorization key, which has been sent to: **** sloyment@gmx.net **** **** If the message is not received, there is generally a problem with **** the address. Before reporting this as a problem, please note the **** following: **** **** You only need to give an address to the subscribe command if you want **** to receive list mail at a different address from where you sent the **** command. Otherwise you can simply omit it. **** **** If you do give an address to the subscribe command, it must be a legal **** address. It should not consist solely of your name. The address must **** point to a machine that is reachable from the list server. **** **** If you have any questions about the policy of the list owner, please **** contact "f-cpu-approval@seul.org". **** **** Thanks! **** **** majordomo@seul.org From notify@yahoogroups.com Wed Aug 15 04:30:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WA-0000Q4-01 for ; Wed, 15 Aug 2001 22:43:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:43:58 +0200 (CEST) Received: (qmail 19726 invoked by uid 0); 15 Aug 2001 02:30:21 -0000 Received: from n4.groups.yahoo.com (216.115.96.54) by mx0.gmx.net (mx23) with SMTP; 15 Aug 2001 02:30:21 -0000 X-eGroups-Return: notify-return-sloyment=gmx.net@yahoogroups.com Received: from [10.1.4.53] by hk.egroups.com with NNFMP; 15 Aug 2001 02:30:20 -0000 Received: (qmail 85330 invoked by uid 7800); 15 Aug 2001 02:30:19 -0000 Date: 15 Aug 2001 02:30:19 -0000 Message-ID: <997842619.140.85321.l7@yahoogroups.com> From: Yahoo! Groups Notification To: sloyment@gmx.net Subject: You have been unsubscribed from f-cpu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Status: RO X-Status: O Hello, This is to inform you that your request to unsubscribe from f-cpu has been completed. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From majordomo@seul.org Wed Aug 15 04:30:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WA-0000Q4-02 for ; Wed, 15 Aug 2001 22:43:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:43:58 +0200 (CEST) Received: (qmail 12284 invoked by uid 0); 15 Aug 2001 02:30:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 15 Aug 2001 02:30:26 -0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id WAA30376; Tue, 14 Aug 2001 22:30:25 -0400 Date: Tue, 14 Aug 2001 22:30:25 -0400 Message-Id: <200108150230.WAA30376@belegost.mit.edu> To: sloyment@gmx.net From: majordomo@seul.org Subject: Welcome to f-cpu Reply-To: majordomo@seul.org Status: RO X-Status: O -- Welcome to the f-cpu mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe f-cpu or from another account, besides sloyment@gmx.net: unsubscribe f-cpu sloyment@gmx.net If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. #### No info available for f-cpu. From majordomo@seul.org Wed Aug 15 04:30:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15X7WB-0000Q4-00 for ; Wed, 15 Aug 2001 22:43:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 22:43:59 +0200 (CEST) Received: (qmail 12956 invoked by uid 0); 15 Aug 2001 02:30:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 15 Aug 2001 02:30:26 -0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id WAA30375; Tue, 14 Aug 2001 22:30:25 -0400 Date: Tue, 14 Aug 2001 22:30:25 -0400 Message-Id: <200108150230.WAA30375@belegost.mit.edu> To: sloyment@gmx.net From: majordomo@seul.org Subject: Majordomo results Reply-To: majordomo@seul.org Status: RO X-Status: O -- >>>> auth 7e2da555 subscribe f-cpu sloyment@gmx.net Succeeded. From majordomo@seul.org Wed Aug 15 03:33:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15Wqbg-0002z8-01 for ; Wed, 15 Aug 2001 04:40:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 04:40:32 +0200 (CEST) Received: (qmail 3215 invoked by uid 0); 15 Aug 2001 01:33:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 15 Aug 2001 01:33:01 -0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA29698; Tue, 14 Aug 2001 21:33:00 -0400 Date: Tue, 14 Aug 2001 21:33:00 -0400 Message-Id: <200108150133.VAA29698@belegost.mit.edu> To: sloyment@gmx.net From: majordomo@seul.org Subject: Confirmation for subscribe f-cpu Reply-To: majordomo@seul.org Status: RO X-Status: O -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "f-cpu@seul.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "majordomo@seul.org": auth 7e2da555 subscribe f-cpu sloyment@gmx.net If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 7e2da555 subscribe f-cpu \ sloyment@gmx.net If you have any questions about the policy of the list owner, please contact "f-cpu-approval@seul.org". Thanks! majordomo@seul.org From confirm-unsub-FkgTcNkGhVwQb28vVzGJ3kjRpX8@yahoogroups.com Wed Aug 15 03:32:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.12 #1 (Debian)) id 15Wqbg-0002z8-00 for ; Wed, 15 Aug 2001 04:40:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net by localhost with POP3 (fetchmail-5.3.3) for thomas@localhost (single-drop); Wed, 15 Aug 2001 04:40:32 +0200 (CEST) Received: (qmail 21602 invoked by uid 0); 15 Aug 2001 01:32:56 -0000 Received: from n6.groups.yahoo.com (216.115.96.56) by mx0.gmx.net (mx019-rz3) with SMTP; 15 Aug 2001 01:32:56 -0000 X-eGroups-Return: confirm-return-sloyment=gmx.net@yahoogroups.com Received: from [10.1.4.53] by hm.egroups.com with NNFMP; 15 Aug 2001 01:32:56 -0000 Received: (qmail 50894 invoked by uid 7800); 15 Aug 2001 01:32:55 -0000 Date: 15 Aug 2001 01:32:55 -0000 Message-ID: <997839175.68.50890.l7@yahoogroups.com> From: Yahoo! Groups Notification Reply-To: confirm-unsub-FkgTcNkGhVwQb28vVzGJ3kjRpX8@yahoogroups.com To: sloyment@gmx.net Subject: Please reply to unsubscribe from f-cpu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Status: RO X-Status: A Hello, We have received a request from you to unsubscribe from the f-cpu group. Please confirm your request by replying to this message. If you do not wish to unsubscribe from f-cpu, please ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From whygee@f-cpu.org Thu Aug 16 06:52:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTX-0002kq-00 for ; Thu, 16 Aug 2001 22:10:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:43 +0200 (CEST) Received: (qmail 30752 invoked by uid 0); 16 Aug 2001 04:54:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 16 Aug 2001 04:54:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id AAA29251 for ; Thu, 16 Aug 2001 00:54:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 04:52:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id AAA28988 for f-cpu-list; Thu, 16 Aug 2001 00:52:49 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id AAA28985 for ; Thu, 16 Aug 2001 00:52:47 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7G4qVb13989 for ; Thu, 16 Aug 2001 00:52:31 -0400 Received: from f-cpu.org (nas2-131.aub.club-internet.fr [195.36.133.131]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA09607 for ; Thu, 16 Aug 2001 06:51:06 +0200 (MET DST) Message-ID: <3B7B518A.A523A7A8@f-cpu.org> Date: Thu, 16 Aug 2001 06:52:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Wed, Aug 15, 2001 at 05:44:30AM +0200, Yann Guidon wrote: > > > i've taken a short look at your FLEX+BISON file and it looks > > interesting. However, i wonder ... what about those who > > work under Win/Dos ? The remark also applies to your scripts. > > Btw, the idea of the scripts is not bad because it spares > > us one compilation run. > > The scripts will also run on Win32 (if you have bash installed ;). > > The problem with them is that they do not check the syntax. That *may* > introduce Big Bad Bugs (tm). The parser avoids that because all > expressions have to be syntactically correct in the input. Please let's > not follow Steinbach's Guideline for Systems Programming: "Never test > for an error condition you don't know how to handle." > > I can try to make a win32 .EXE (using LCC or CYGWIN). if you can do that, great ! i'll try to see if a DOS/16 .exe can be compiled, too. i just woke up and have to digest all your interesting posts, but concerning the assembler, i encourage you to reuse as much as possible from the one found at htt://www.f-cpu.de/design/snapshot.tgz it is a working assembler frame with bells and whistles, modifying the (small) syntax should be really easy. i have to integrate the configuration files that you have created, so expect some small changes in the include hierarchy, but the rest will be ok. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Thu Aug 16 07:49:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTX-0002kq-01 for ; Thu, 16 Aug 2001 22:10:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:43 +0200 (CEST) Received: (qmail 1274 invoked by uid 0); 16 Aug 2001 06:00:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 16 Aug 2001 06:00:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA30537 for ; Thu, 16 Aug 2001 02:00:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 06:00:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA30287 for f-cpu-list; Thu, 16 Aug 2001 02:00:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA30284 for ; Thu, 16 Aug 2001 02:00:07 -0400 Received: from online.ln.cn ([202.96.74.114]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f7G5xnb14497 for ; Thu, 16 Aug 2001 01:59:50 -0400 Received: from maveric([61.176.52.90]) by online.ln.cn(AIMC 2.9.5.1) with SMTP id jm73b7bcf10; Thr, 16 Aug 2001 13:55:12 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? Date: Thu, 16 Aug 2001 13:49:27 +0800 X-Mailer: KMail [version 1.2] References: <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> In-Reply-To: <3B7AD06A.6C0A9589@ifrance.com> MIME-Version: 1.0 Message-Id: <01081613492700.00283@maveric> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id CAA30285 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi. This is my first post to this list. My background is as a hardware technician, not a chip designer so bear with me. On Thursday 16 August 2001 03:41, you wrote: > Michael Riepe a écrit : > > In sparc, there is no 80 bits float but 128 bits (2 registers used in > the same time). We don't need 1 cycle multiplication so it could be done > for the fcpu. I am thinking that taking the two-register approach might be over-complicating matters. Since F-CPU is intended to later be scaled above 64 bits, if someone wanted 128-bit floats in the future they would impliment a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS (Keep It Simple for us Stupid people). BTW: I am wondering about the reasons for having endian-ness encoded in the instruction. How often do you need to change endinianness. I am thinking a SR for endinian would free up that bit as well as allowing other endiniannesses as well as big and little (Not in popular usage at present but I can think of several other bizaar ways to re-arrange the bits in a word that may be useful in some obscure application). I'd be inclined to use that bit to extend the addressing size from 4 addressing widths to eight as follows: 000 - 1 bit 001 - 2 bits 010 - 4 bits 011 - 8 bits (mandatory) 100 - 16 bits (mandatory) 101 - 32 bits (mandatory) 110 - 64 bits (mandatory) 111 - maxWidth (the maximum avaliable width) I'm not sure about the merits of the first three widths but they are nice and neat. Since you don't want a bank select line for every bit, sub-byte writes would have to be implimented as a read-alter-write, wasting at least one memory bus cycle. I make no claims as to whether this is worth it. You would also need to address each bit instead of each byte, chopping 3 effective bits off your maximum memory size. Crazy idea, I know. An alternative might be: 000 - 8 bits (mandatory) 001 - 16 bits (mandatory) 010 - 32 bits (mandatory) 011 - 64 bits (mandatory) 100 - 128 bits 101 - 256 bits 110 - application defined 111 - maxWidth (the maximum avaliable width) 256-bit floats anyone? -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy: Use GNU ( www.gnu.org ) -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Aug 16 10:56:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTa-0002kq-01 for ; Thu, 16 Aug 2001 22:10:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:46 +0200 (CEST) Received: (qmail 6685 invoked by uid 0); 16 Aug 2001 08:31:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 16 Aug 2001 08:31:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA01184 for ; Thu, 16 Aug 2001 04:31:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 08:29:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA00713 for f-cpu-list; Thu, 16 Aug 2001 04:29:31 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA00710 for ; Thu, 16 Aug 2001 04:29:29 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7G8TCb15763 for ; Thu, 16 Aug 2001 04:29:13 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XIx1-0002UQ-00 for f-cpu@seul.org; Thu, 16 Aug 2001 10:56:27 +0200 Date: Thu, 16 Aug 2001 10:56:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id EAA00711 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 15 Aug 2001, nicO wrote: > Michael Riepe a écrit : > > > > On Tue, Aug 14, 2001 at 03:25:04PM +0200, Yann Guidon wrote: > > > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). > > In sparc, there is no 80 bits float but 128 bits (2 registers used in > the same time). We don't need 1 cycle multiplication so it could be done > for the fcpu. Actually there never was an implementation of 128bit precision as far as I know. There is a chapter regarding this topic in the SPARC V8 manual. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Aug 16 10:56:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTb-0002kq-00 for ; Thu, 16 Aug 2001 22:10:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:47 +0200 (CEST) Received: (qmail 11493 invoked by uid 0); 16 Aug 2001 08:31:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 16 Aug 2001 08:31:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA01246 for ; Thu, 16 Aug 2001 04:31:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 08:29:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA00926 for f-cpu-list; Thu, 16 Aug 2001 04:29:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA00921 for ; Thu, 16 Aug 2001 04:29:47 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7G8TUb15775 for ; Thu, 16 Aug 2001 04:29:30 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XIxM-0002UV-00 for f-cpu@seul.org; Thu, 16 Aug 2001 10:56:48 +0200 Date: Thu, 16 Aug 2001 10:56:48 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 16 Aug 2001, Glenn Alexander wrote: > I am thinking that taking the two-register approach might be > over-complicating matters. Since F-CPU is intended to later be scaled above > 64 bits, if someone wanted 128-bit floats in the future they would impliment > a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS > (Keep It Simple for us Stupid people). > > BTW: I am wondering about the reasons for having endian-ness encoded in the > instruction. How often do you need to change endinianness. I am thinking a SR > for endinian would free up that bit as well as allowing other endiniannesses > as well as big and little (Not in popular usage at present but I can think of > several other bizaar ways to re-arrange the bits in a word that may be useful > in some obscure application). Hi, enidaness things may cost a lot in some implementations. Think of some network protocols having fixed byte order that are not compliant with the architecture. Network needs fast responding time though. I had that problem once and thanks to the RISC processor it was possible to access different endianess memory banks that could be overlapped... ;-) > > An alternative might be: > 000 - 8 bits (mandatory) > 001 - 16 bits (mandatory) > 010 - 32 bits (mandatory) > 011 - 64 bits (mandatory) > 100 - 128 bits > 101 - 256 bits > 110 - application defined > 111 - maxWidth (the maximum avaliable width) > > 256-bit floats anyone? Please, do not use maxWidth here but just state something like 'reserved - for further extension'. That helps to use it in a new or better way later on... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 16 19:37:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTi-0002kq-00 for ; Thu, 16 Aug 2001 22:10:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:54 +0200 (CEST) Received: (qmail 3342 invoked by uid 0); 16 Aug 2001 11:29:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 16 Aug 2001 11:29:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA03271 for ; Thu, 16 Aug 2001 07:29:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 11:28:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA03025 for f-cpu-list; Thu, 16 Aug 2001 07:28:52 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA03022 for ; Thu, 16 Aug 2001 07:28:47 -0400 Received: from localhost.localdomain (nas7-9.vlt.club-internet.fr [194.158.109.9]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GBSTb17226 for ; Thu, 16 Aug 2001 07:28:30 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id DA61413DD for ; Thu, 16 Aug 2001 13:37:45 -0400 (EDT) Message-ID: <3B7C04E9.196450D5@ifrance.com> Date: Thu, 16 Aug 2001 13:37:45 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <20010816011059.37312@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Wed, Aug 15, 2001 at 10:56:17AM -0600, Ben Franchuk wrote: > > > Zip's may not be that portable. [...] > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. winzip handel tar.gz very well ! nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 16 19:42:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTi-0002kq-01 for ; Thu, 16 Aug 2001 22:10:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:54 +0200 (CEST) Received: (qmail 19239 invoked by uid 0); 16 Aug 2001 11:33:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 16 Aug 2001 11:33:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA03578 for ; Thu, 16 Aug 2001 07:33:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 11:33:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA03331 for f-cpu-list; Thu, 16 Aug 2001 07:33:16 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA03328 for ; Thu, 16 Aug 2001 07:33:15 -0400 Received: from localhost.localdomain (nas7-9.vlt.club-internet.fr [194.158.109.9]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GBWtb17262 for ; Thu, 16 Aug 2001 07:32:55 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 730AD13DD for ; Thu, 16 Aug 2001 13:42:12 -0400 (EDT) Message-ID: <3B7C05F4.35FA607C@ifrance.com> Date: Thu, 16 Aug 2001 13:42:12 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Wed, Aug 15, 2001 at 10:22:11AM +0200, Yann Guidon wrote: > [...] > > > SIMD is IMHO not reasonable for the FP units. > > in what context are you speaking ? > > I mean: I think it's unreasonable to build *variable-size* FP units. > There are too many special cases to consider -- rounding, exceptions, > infinities and NANs, ... (ok, go blame IEEE for it ;) > > > > A reasonable approach is > > > to build a set of pipelined 64-bit FP units, and then issue the 32-bit > > > operations in two consecutive cycles. > > that's vectoring, then. Scheduling might become more complex, > > in situations such as chaining for example. > > Not if it's "hidden" inside the EU. > > > I have nothing to object to that, but > > - 1) currently we have no FP unit > > - 2) SIMD already works well (when it does) > > - 3) vectoring will be used in another core because FC0 would require too much changes > > - 4) if you have 1 FP unit, the hardest is done : you can duplicate it :-P > > If you have enough room. Do you have an idea how big the FP unit will be? > It's big but not as a 256 Ko SRAM cache. So it will be the choice of the user. Duplicate big unit could save a lot of computing power (because you make a single run). For your 16 bit fp processing, could not be better to use log number ? For audio processing it could be enough (no DC stuff). For the following text, it could be nice to update quickly the manual. If whygee is ok. nicO > > > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > > > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). > > > > geez, the instruction set in the current version of the manual needs a big rework... > > Yep. There are a handful of inconsistencies, typing errors, missing > parts etc. in it. Major things I've found so far: > > - The manual doesn't state whether `modi' is a signed operation > I suggest it should be signed (like `divi') > > - Complement `abs' with `nabs' (negative absolute) for > symmetry, and to avoid the `sign surprise' when the argument > is -2**(chunksize-1) > > - The syntax for the rounding mode (`l2int', `f2int') is not > specified. I suggest to use the following syntax: > > l2int[r|t|f|c] > f2int[r|t|f|c][x] > > with these meanings: > > -r (round) round to nearest (default) > -t (trunc) round towards zero > -f (floor) round towards -infinity > -c (ceil) round towards +infinity > > - `int2f' and `int2l' also need rounding modes because both > conversions may result in precision loss if the integer operand > has a large value. > > - `bitop[s|c|x|t]i' should be `bitopi[s|c|x|t]' (`i' is NOT a suffix!) > > - Assign four opcodes for bitop[i] and increase the imm6 operand > to imm8 (for consistency with the rop2, shift, rot, bitrevi and > loadcons[x] instructions). Since bitop[i] is a ROP2 instruction, > change the function encoding to match that of rop2, that is: > > fun rop2 bitop > ================ > 000 and btst > 001 andn bclr > 010 xor bchg > 011 or bset > 100 nor -- > 101 xnor -- > 110 orn -- > 111 nand -- > > I guess we can get the missing four instructions for free, > but they aren't really useful. > > - The description of the ROP2 is obsolete (and the syntax for > combine/mux is unspecified) I suggest -o and -a suffixes for > combine, and a new `mux' instruction. > > - For the `andn' and `orn' instructions, the manual must > clearly state which operand is inverted. IMHO, `andni' and > `orni' will be almost useless if we invert the leftmost > (== immediate) operand (but not completely useless, because > the upper bits differ when the chunk size is 16 or more). > > On the other hand, we could add a flag for sign extension of the > immediate operand and invert the middle (== register) operand. > Since the function bits have moved to the opcode field, there > should be a free flag. > > - There is no explicit `not' instruction, but users can write > `nor r0, r2, r1', `xnor r0, r2, r1' or similar. Since this > may not be obvious, F-CPU assemblers should recognize `not > r2, r1' and convert it to one of the other forms internally. > The `not' instruction should, however, be documented in the > Instruction Set Manual. > > - In `bitrev[i]', use the formula `r1 = bit_reverse(r2) >> (size-r3-1)'. > That will change the useful range for r3 to [size-1;0]. In the > current version, it's [size;1] which is pretty ugly. > > Another possible variant is `r1 = bit_reverse(r2) >> r3', with > the same useful range but a nicer default (r3 == r0) which > makes the 2-operand short form `bitrev r2, r1' meaningful, > but that may cause trouble when the register size is increased > beyond 64 bits :( > > - `flog' and `fexp' should both take only two operands. > Remember that (a**b)**c = a**(b*c) = a**(c*b) = (a**c)**b. > That is, with a simple multiplication (before fexp / after > flog) you get any base you want, and the FP unit probably > works better with a fixed base. > > - We need a level-1 floating-point compare instruction; > `cmpl'/`cmple' may work with LNS (if there are no NANs), > but not with FP. > > - The arguments of `store[f]' are reversed (dest, src). It's > ok that way (because it mirrors the `load' instruction) but > there should be a BIG FAT WARNING in the manual. > > - Some immediate instructions may benefit from a non-linear > encoding of the immediate operand (for example, 6 bits value + > 2 bits left-shift). At least this is an option for `loadi' > and `storei'. > > - The naming of the memory hierarchies in the `cachemm' > instruction is ambiguous (in particular, the -c and -l suffixes). > We can still use numeric suffixes [0-7], however. > > Again, the arguments are reversed (`cachemm addr,count'). > > - In the description of `move', remove the reference to `nop'. > BTW: there is no need to give `cmove' a separate name and > opcode. If there is a condition suffix, it's a conditional move > (3-operand form), otherwise it's unconditional (2 operands): > > move[s]{cond} r3, r2, r1 > move[s] r2, r1 > > - We need to clarify the syntax of the `condition' suffixes for > `move' and `jmpa'. I suggest > > 000 -z (zero) > 001 (unassigned) > 010 -m (msb == 1) > 011 -l (lsb == 0) > 100 -nz (not zero) > 101 (unassigned) > 110 -nm (msb == 0) > 111 -nl (lsb == 0) > > - Assemblers must accept `loadcons[x] large-number' and emit a > suitable series of loadcons.n (or loadconsx.n) instructions > instead. This is necessary for external symbol references > (which are resolved at link time). Assemble-time constants > may be shortened to less than 64 bits, however, and if the > user explicitly requests `loadcons.0' or `loadconsx.0', the > assembler should of course do what (s)he wants (and complain > if the value is too large). > > - Can we please drop the `a' from `jmpa'? > > As with `move', the presence of the condition suffix indicates > the form of the instruction: > > jmp[a]{cond} r3, r2 [, r1] > jmp[a] r2 [, r1] > > - When calling functions through pointers, it would be nice to > be able to tell the F-CPU *a priori* that a register contains a > code address. While this can be done with an explicit prefetch > (load to r0) for data pointers, there is no way to specify that > a register contains a code address that the CPU will have to > visit soon. The same is true when an absolute code address is > obtained via loadcons (which will probably be the common idiom > when a function in another object file is called, unless jump > tables are used -- which points us back to the `code pointer > in register' problem, again). > > To cut a long story short: I'd like to have an instruction > that explicitly `tags' a register as a pointer, and probably > initiates a prefetch cycle (for code or data, depending on > the instruction's flags). It may or may not move data from > one register to another (one idea I had was a `pointer move' > instruction); if it does, it might be a good idea to let it > participate in address calculation (i.e. let it be able to > add two operands, like the `lea' instruction on Intel CPUs). > > - Let's clarify the suffix order, e.g. like this (? means the > suffix is currently unused, and its name is unassigned): > > add[c|s|?] > sub[b|f|?] > mul[h][s] > div[m][s] > mac[l|h][s] # I suggest to allow `macl' as an alias for `mac'. > scan[n][r] > bitop[s|c|x|t] > bitopi[s|c|x|t] > mix[l|h] > expand[l|h] > {rop2}[a|o] > {rop2i}[a|o] > load[f][e][0-7] > loadi[f][e][0-7] > store[f][e][0-7] > storei[f][e][0-7] > cachemm[f|p][l][c][0-7] > move[s][n][z|?|m|l] > jmpa[n][z|?|m|l] > serialize[s][x][m] > > - Some instructions (e.g. `mac' and `addsub') could have > variants with an immediate operand. > > - The loadm/storem has a surprising operand order > (start,src/dest,count), and it's not clear whether the > register *numbers* or the register *contents* serve as the > start/count values. I suggest the former, and I would also > change the operands to (firstreg, lastreg, memaddr) which is > much easier to grok for humans. > > Since there are some unused flags, another variant might be > interesting: `storem r2, r1', where r2 is used as a mask > (bit == 1 means "load/store register "), and r1 is the > address of the source/destination memory area (which must be > big enough to hold all registers, just like the CMB). > > Maybe it would be wiser to put the memory address into the > rightmost operand in *all* memory operations (load, store, > cachemm, loadm and storem). Some instructions will always > have the wrong operand order, though. > > - And finally, the most important point: the new `nop' instruction > is still undocumented ;) > > In case you wonder: I needed a break from VHDL coding (I couldn't > even write C any more!), so I decided to play with something totally > different for a while. The result is a flex-based instruction encoder > that recognizes almost any instruction the F-CPU will have (with the > exceptions mentioned above). I'll probably also build an assembler > around it. (I finally found a real use for my libelf library! Yeah! ;) > > > Sure, there needs to be an expansion/reduction code for FP > > but SDUP works for SIMD FP if the packets have the same boundaries. > > That's a different kind of operation. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 16 19:46:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTl-0002kq-00 for ; Thu, 16 Aug 2001 22:10:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:57 +0200 (CEST) Received: (qmail 22014 invoked by uid 0); 16 Aug 2001 11:37:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 16 Aug 2001 11:37:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA03869 for ; Thu, 16 Aug 2001 07:37:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 11:37:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA03618 for f-cpu-list; Thu, 16 Aug 2001 07:37:11 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA03615 for ; Thu, 16 Aug 2001 07:37:10 -0400 Received: from localhost.localdomain (nas7-9.vlt.club-internet.fr [194.158.109.9]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GBarb17306 for ; Thu, 16 Aug 2001 07:36:53 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 4CC0113DD for ; Thu, 16 Aug 2001 13:46:09 -0400 (EDT) Message-ID: <3B7C06E1.EF155DA9@ifrance.com> Date: Thu, 16 Aug 2001 13:46:09 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > Michael Riepe wrote: > > On Wed, Aug 15, 2001 at 05:44:30AM +0200, Yann Guidon wrote: > > > > > i've taken a short look at your FLEX+BISON file and it looks > > > interesting. However, i wonder ... what about those who > > > work under Win/Dos ? The remark also applies to your scripts. > > > Btw, the idea of the scripts is not bad because it spares > > > us one compilation run. > > > > The scripts will also run on Win32 (if you have bash installed ;). > > > > The problem with them is that they do not check the syntax. That *may* > > introduce Big Bad Bugs (tm). The parser avoids that because all > > expressions have to be syntactically correct in the input. Please let's > > not follow Steinbach's Guideline for Systems Programming: "Never test > > for an error condition you don't know how to handle." > > > > I can try to make a win32 .EXE (using LCC or CYGWIN). > if you can do that, great ! > i'll try to see if a DOS/16 .exe can be compiled, too. > > i just woke up and have to digest all your interesting posts, > but concerning the assembler, i encourage you to reuse as much > as possible from the one found at htt://www.f-cpu.de/design/snapshot.tgz > it is a working assembler frame with bells and whistles, > modifying the (small) syntax should be really easy. > > i have to integrate the configuration files that you have created, > so expect some small changes in the include hierarchy, but the rest > will be ok. > I could add there is many assembler soon written. So maybe, it will be more interresting to make a quick emulator. Whygee one is for proof of concept. So, we need a quick one to run long program at raisonnable speed. If you put macro inside your asm, never forget to introduice the dot (like .not), most of the time we expect that 1 instruction take 32 bits but it could be much more with macro. nicO > > Michael "Tired" Riepe > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 16 21:05:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTm-0002kq-00 for ; Thu, 16 Aug 2001 22:10:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:58 +0200 (CEST) Received: (qmail 26916 invoked by uid 0); 16 Aug 2001 12:56:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 16 Aug 2001 12:56:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA04830 for ; Thu, 16 Aug 2001 08:56:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 12:56:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA04577 for f-cpu-list; Thu, 16 Aug 2001 08:56:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA04574 for ; Thu, 16 Aug 2001 08:56:05 -0400 Received: from localhost.localdomain (nas5-110.vlt.club-internet.fr [194.158.107.110]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GCtmb17856 for ; Thu, 16 Aug 2001 08:55:49 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 324AC15D3 for ; Thu, 16 Aug 2001 15:05:05 -0400 (EDT) Message-ID: <3B7C1961.B7603F9B@ifrance.com> Date: Thu, 16 Aug 2001 15:05:05 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >FC0 issues in-order all the instructions that are considered as valid. >if a trap occurs, it must NEVER enter the pipeline (because of the OOO >completion, it would become a nightmare to rewind the pipeline !!!). !!! "rewind the pipeline !" You just have to bypass the write back stage ! >Currently, FC0 uses two addressing spaces : "private" space where the CPU >is the only master (cache coherency is straight-forward) and "outside world" >where all the accesses are in-order and uncacheable. I don't think it will be very interresting (too slow). It will be much interresting to manage this inside the VM unit by page (the page will have the information of none caching, none registering,...). And then a decoder will send the data thought memory port or fbus port. >Use semaphores >that are mapped in the SRs ! In all case, we need to write something in memory or to touch something in the VM unit. So it's just pushing the problem away ! More generaly, i find the text very agressive against Alpha.(the 2 first sentences of the text, for example). We should never forget that alpha work since 10 years and fcpu is in it's very beginning. So this kink of speech could make laught a futur investor in the fcpu, never forget that. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Aug 16 06:42:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTn-0002kq-00 for ; Thu, 16 Aug 2001 22:10:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:10:59 +0200 (CEST) Received: (qmail 2678 invoked by uid 0); 16 Aug 2001 14:03:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 16 Aug 2001 14:03:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA05796 for ; Thu, 16 Aug 2001 10:03:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 14:03:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA05544 for f-cpu-list; Thu, 16 Aug 2001 10:03:14 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA05541 for ; Thu, 16 Aug 2001 10:03:13 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GE2vb19309 for ; Thu, 16 Aug 2001 10:02:57 -0400 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA16084 for ; Thu, 16 Aug 2001 08:03:10 -0600 (MDT) Message-ID: <3B7B4F2A.A1EFB267@jetnet.ab.ca> Date: Wed, 15 Aug 2001 22:42:18 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Thu, 16 Aug 2001, Glenn Alexander wrote: > > I am thinking that taking the two-register approach might be > > over-complicating matters. Since F-CPU is intended to later be scaled above > > 64 bits, if someone wanted 128-bit floats in the future they would impliment > > a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS > > (Keep It Simple for us Stupid people). > > > > BTW: I am wondering about the reasons for having endian-ness encoded in the > > instruction. How often do you need to change endinianness. I am thinking a SR > > for endinian would free up that bit as well as allowing other endiniannesses > > as well as big and little (Not in popular usage at present but I can think of > > several other bizaar ways to re-arrange the bits in a word that may be useful > > in some obscure application). > > Hi, > > enidaness things may cost a lot in some implementations. Think > of some network protocols having fixed byte order that are not > compliant with the architecture. Network needs fast responding > time though. I had that problem once and thanks to the RISC > processor it was possible to access different endianess memory > banks that could be overlapped... ;-) > > > > > An alternative might be: > > 000 - 8 bits (mandatory) > > 001 - 16 bits (mandatory) > > 010 - 32 bits (mandatory) > > 011 - 64 bits (mandatory) > > 100 - 128 bits > > 101 - 256 bits > > 110 - application defined > > 111 - maxWidth (the maximum avaliable width) > > > > 256-bit floats anyone? > > Please, do not use maxWidth here but just state something > like 'reserved - for further extension'. That helps to use > it in a new or better way later on... > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ Can't both the endands default and byte/word sizes and floating point sizes be setup from special registers rather than hard coded into the instruction path decoding. Ben. PS.What would be nice is to have non standard sizes for special functions. While not used any more 3 - 5 bit fields come to mind for packing 15 bit colors for a video display. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 16:13:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTo-0002kq-00 for ; Thu, 16 Aug 2001 22:11:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:00 +0200 (CEST) Received: (qmail 17048 invoked by uid 0); 16 Aug 2001 14:14:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 16 Aug 2001 14:14:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA06218 for ; Thu, 16 Aug 2001 10:14:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 14:14:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA05970 for f-cpu-list; Thu, 16 Aug 2001 10:14:21 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA05966 for ; Thu, 16 Aug 2001 10:14:19 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GEE3b19572 for ; Thu, 16 Aug 2001 10:14:03 -0400 Received: from f-cpu.org (nas2-249.ras.club-internet.fr [195.36.192.249]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA18234 for ; Thu, 16 Aug 2001 16:14:15 +0200 (MET DST) Message-ID: <3B7BD51F.2031DD5@f-cpu.org> Date: Thu, 16 Aug 2001 16:13:51 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Juergen Goeritz wrote: > On Thu, 16 Aug 2001, Glenn Alexander wrote: > > BTW: I am wondering about the reasons for having endian-ness encoded in the > > instruction. How often do you need to change endinianness. I am thinking a SR > > for endinian would free up that bit as well as allowing other endiniannesses > > as well as big and little (Not in popular usage at present but I can think of > > several other bizaar ways to re-arrange the bits in a word that may be useful > > in some obscure application). > > Hi, > > enidaness things may cost a lot in some implementations. Think > of some network protocols having fixed byte order that are not > compliant with the architecture. Network needs fast responding > time though. I had that problem once and thanks to the RISC > processor it was possible to access different endianess memory > banks that could be overlapped... ;-) For those who where not yet here when the question was raised first : there is already a patent (MIPS) on a configuration register that defines endianness. So we thought : fuck, let's simply move the bit to the instruction. In fact, it's exactly the same amount of HW (a "swap" unit that works both ways) but it is not configured at boot time. that's all. I think that VAX byte ordering was never considered. For this and the rest, there must be all the necessary instructions provided by the SHL (bit shuffling) unit. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 16 22:41:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTp-0002kq-00 for ; Thu, 16 Aug 2001 22:11:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:01 +0200 (CEST) Received: (qmail 10891 invoked by uid 0); 16 Aug 2001 14:33:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 16 Aug 2001 14:33:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA06799 for ; Thu, 16 Aug 2001 10:33:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 14:32:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA06551 for f-cpu-list; Thu, 16 Aug 2001 10:32:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA06548 for ; Thu, 16 Aug 2001 10:32:56 -0400 Received: from localhost.localdomain (nas25-47.vlt.club-internet.fr [195.36.224.47]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GEWdb19992 for ; Thu, 16 Aug 2001 10:32:39 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 5D83415D3 for ; Thu, 16 Aug 2001 16:41:55 -0400 (EDT) Message-ID: <3B7C3013.787E05A3@ifrance.com> Date: Thu, 16 Aug 2001 16:41:55 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7B4F2A.A1EFB267@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > Juergen Goeritz wrote: > > > > On Thu, 16 Aug 2001, Glenn Alexander wrote: > > > I am thinking that taking the two-register approach might be > > > over-complicating matters. Since F-CPU is intended to later be scaled above > > > 64 bits, if someone wanted 128-bit floats in the future they would impliment > > > a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS > > > (Keep It Simple for us Stupid people). > > > > > > BTW: I am wondering about the reasons for having endian-ness encoded in the > > > instruction. How often do you need to change endinianness. I am thinking a SR > > > for endinian would free up that bit as well as allowing other endiniannesses > > > as well as big and little (Not in popular usage at present but I can think of > > > several other bizaar ways to re-arrange the bits in a word that may be useful > > > in some obscure application). > > > > Hi, > > > > enidaness things may cost a lot in some implementations. Think > > of some network protocols having fixed byte order that are not > > compliant with the architecture. Network needs fast responding > > time though. I had that problem once and thanks to the RISC > > processor it was possible to access different endianess memory > > banks that could be overlapped... ;-) > > > > > > > > An alternative might be: > > > 000 - 8 bits (mandatory) > > > 001 - 16 bits (mandatory) > > > 010 - 32 bits (mandatory) > > > 011 - 64 bits (mandatory) > > > 100 - 128 bits > > > 101 - 256 bits > > > 110 - application defined > > > 111 - maxWidth (the maximum avaliable width) > > > > > > 256-bit floats anyone? > > > > Please, do not use maxWidth here but just state something > > like 'reserved - for further extension'. That helps to use > > it in a new or better way later on... > > > > JG > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > Can't both the endands default and byte/word sizes and floating point sizes > be setup from special registers rather than hard coded into the instruction > path decoding. > Ben. > PS.What would be nice is to have non standard sizes for special > functions. While not used any more 3 - 5 bit fields come to mind > for packing 15 bit colors for a video display. > Maybe a shift&mask (SIMD) instruction could be enough. You just add an instruction but just for the convertion. nicO > -- > Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. > "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk > Now with schematics. > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Aug 16 07:15:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTq-0002kq-01 for ; Thu, 16 Aug 2001 22:11:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:02 +0200 (CEST) Received: (qmail 32253 invoked by uid 0); 16 Aug 2001 14:36:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 16 Aug 2001 14:36:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA07088 for ; Thu, 16 Aug 2001 10:36:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 14:36:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA06840 for f-cpu-list; Thu, 16 Aug 2001 10:36:30 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA06837 for ; Thu, 16 Aug 2001 10:36:29 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GEaDb20076 for ; Thu, 16 Aug 2001 10:36:13 -0400 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA16478 for ; Thu, 16 Aug 2001 08:36:25 -0600 (MDT) Message-ID: <3B7B56F5.94C34BD8@jetnet.ab.ca> Date: Wed, 15 Aug 2001 23:15:33 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7BD51F.2031DD5@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > For those who where not yet here when the question was raised first : > there is already a patent (MIPS) on a configuration register > that defines endianness. So we thought : fuck, let's simply move > the bit to the instruction. In fact, it's exactly the same amount > of HW (a "swap" unit that works both ways) but it is not configured > at boot time. that's all. I think that VAX byte ordering was never > considered. For this and the rest, there must be all the necessary > instructions provided by the SHL (bit shuffling) unit. Ok what about instruction decoding of the opcode in a configuration register with each setup modifying the fields used? version 1 - endian bit active high version 2 - endian bit active low ( Special register xor endian flag ). Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Aug 16 07:30:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTr-0002kq-00 for ; Thu, 16 Aug 2001 22:11:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:03 +0200 (CEST) Received: (qmail 4155 invoked by uid 0); 16 Aug 2001 14:52:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 16 Aug 2001 14:52:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA07514 for ; Thu, 16 Aug 2001 10:52:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 14:51:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA07266 for f-cpu-list; Thu, 16 Aug 2001 10:51:51 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA07263 for ; Thu, 16 Aug 2001 10:51:50 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GEpXb20396 for ; Thu, 16 Aug 2001 10:51:33 -0400 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA16710 for ; Thu, 16 Aug 2001 08:51:47 -0600 (MDT) Message-ID: <3B7B5A90.7B3A0239@jetnet.ab.ca> Date: Wed, 15 Aug 2001 23:30:56 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7B4F2A.A1EFB267@jetnet.ab.ca> <3B7C3013.787E05A3@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO wrote: > > Maybe a shift&mask (SIMD) instruction could be enough. You just add an > instruction but just for the convertion. The PDP-10 had a very nice bit packing/unpacking instructions but that is CISC rather RISC stuff. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Aug 16 17:28:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTr-0002kq-01 for ; Thu, 16 Aug 2001 22:11:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:03 +0200 (CEST) Received: (qmail 15654 invoked by uid 0); 16 Aug 2001 15:01:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 16 Aug 2001 15:01:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA07884 for ; Thu, 16 Aug 2001 11:01:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:00:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA07633 for f-cpu-list; Thu, 16 Aug 2001 11:00:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA07630 for ; Thu, 16 Aug 2001 11:00:46 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GF0Tb20597 for ; Thu, 16 Aug 2001 11:00:30 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XP3w-0002uA-00 for f-cpu@seul.org; Thu, 16 Aug 2001 17:28:00 +0200 Date: Thu, 16 Aug 2001 17:28:00 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? In-Reply-To: <3B7B56F5.94C34BD8@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 15 Aug 2001, Ben Franchuk wrote: > Yann Guidon wrote: > > > For those who where not yet here when the question was raised first : > > there is already a patent (MIPS) on a configuration register > > that defines endianness. So we thought : fuck, let's simply move > > the bit to the instruction. In fact, it's exactly the same amount > > of HW (a "swap" unit that works both ways) but it is not configured > > at boot time. that's all. I think that VAX byte ordering was never > > considered. For this and the rest, there must be all the necessary > > instructions provided by the SHL (bit shuffling) unit. > > Ok what about instruction decoding of the opcode in a configuration > register with each setup modifying the fields used? > version 1 - endian bit active high > version 2 - endian bit active low > ( Special register xor endian flag ). > Ben. What's the hack here if it's just one bit? Why does it add up to and complicate the decode stage? Since after decode the intermediate signals have to be registered anyway for later execution I don't really see the point. Could someone please point me to it? The other suggestion about using a toggle filpflop may be interesting either - but I am a bit worried about the poor compiler designers... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 17:16:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTs-0002kq-00 for ; Thu, 16 Aug 2001 22:11:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:04 +0200 (CEST) Received: (qmail 1048 invoked by uid 0); 16 Aug 2001 15:18:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 16 Aug 2001 15:18:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA09394 for ; Thu, 16 Aug 2001 11:18:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:17:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA08369 for f-cpu-list; Thu, 16 Aug 2001 11:17:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA08361 for ; Thu, 16 Aug 2001 11:17:03 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFGlb20835 for ; Thu, 16 Aug 2001 11:16:47 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA21741 for ; Thu, 16 Aug 2001 17:16:59 +0200 (MET DST) Message-ID: <3B7BE3DB.85689C92@f-cpu.org> Date: Thu, 16 Aug 2001 17:16:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA (=?iso-8859-1?Q?r=E9ponse=20=E0?= deux balles) References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <20010816011059.37312@thrai.stud.uni-hannover.de> <3B7C04E9.196450D5@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO wrote: > Michael Riepe a écrit : > > On Wed, Aug 15, 2001 at 10:56:17AM -0600, Ben Franchuk wrote: > > > Zip's may not be that portable. [...] > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. > winzip handel tar.gz very well ! yup :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 17:16:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTt-0002kq-00 for ; Thu, 16 Aug 2001 22:11:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:05 +0200 (CEST) Received: (qmail 17833 invoked by uid 0); 16 Aug 2001 15:18:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 16 Aug 2001 15:18:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA09412 for ; Thu, 16 Aug 2001 11:18:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:17:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA08376 for f-cpu-list; Thu, 16 Aug 2001 11:17:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA08367 for ; Thu, 16 Aug 2001 11:17:07 -0400 Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFGpb20839 for ; Thu, 16 Aug 2001 11:16:51 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA21942; Thu, 16 Aug 2001 17:17:04 +0200 (MET DST) Message-ID: <3B7BE3DF.CCE3BA5A@f-cpu.org> Date: Thu, 16 Aug 2001 17:16:47 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7C05F4.35FA607C@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Michael Riepe a écrit : > > If you have enough room. Do you have an idea how big the FP unit will be? > It's big but not as a 256 Ko SRAM cache. So it will be the choice of the > user. Duplicate big unit could save a lot of computing power (because > you make a single run). After all, the files are under GPL so they can be modified if needed. > For your 16 bit fp processing, could not be better to use log number ? > For audio processing it could be enough (no DC stuff). i'd rather use 32-b ints or 32-b FP instead of 16-b FP. unless you really don't care about the huge rounding noise that you will create. 16-b and 32-b LNS could be used too, but i know that some people are not very happy with it. > For the following text, it could be nice to update quickly the manual. > If whygee is ok. the "little" problem is that Olivier Jean has not submitted his work. i'm ok for modifying the manual, of course, but it is a very heavy and long work and if Olivier comes with a "forked" revision, the branch merge will be another nightmare. - i hope that olivier will send some news about what he has done, is doing and will do. - we can prepare "patches" that will be applied to the manual in either new or old version. these would be "manual patches" in case a new manual revision comes. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 17:16:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTu-0002kq-00 for ; Thu, 16 Aug 2001 22:11:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:06 +0200 (CEST) Received: (qmail 27324 invoked by uid 0); 16 Aug 2001 15:18:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 16 Aug 2001 15:18:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA09506 for ; Thu, 16 Aug 2001 11:18:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:17:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA08424 for f-cpu-list; Thu, 16 Aug 2001 11:17:12 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA08395 for ; Thu, 16 Aug 2001 11:17:10 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFGrb20843 for ; Thu, 16 Aug 2001 11:16:54 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA21839 for ; Thu, 16 Aug 2001 17:17:06 +0200 (MET DST) Message-ID: <3B7BE3E2.728A1FC5@f-cpu.org> Date: Thu, 16 Aug 2001 17:16:50 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> <3B7C06E1.EF155DA9@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > I could add there is many assembler soon written. So maybe, it will be > more interresting to make a quick emulator. Whygee one is for proof of > concept. it is also for preparing RTL files. > So, we need a quick one to run long program at raisonnable speed. i think that it can't be "invented" : those who want to make lightning-fast emulators must read other's SW. There are many techniques and tricks such as "compiling" huge jmp tables on teh fly etc... > If you put macro inside your asm, never forget to introduice the dot > (like .not), most of the time we expect that 1 instruction take 32 bits > but it could be much more with macro. ? can you explain with more details/examples ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 17:16:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTu-0002kq-01 for ; Thu, 16 Aug 2001 22:11:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:06 +0200 (CEST) Received: (qmail 7649 invoked by uid 0); 16 Aug 2001 15:18:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 16 Aug 2001 15:18:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA09572 for ; Thu, 16 Aug 2001 11:18:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:17:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA08513 for f-cpu-list; Thu, 16 Aug 2001 11:17:20 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA08445 for ; Thu, 16 Aug 2001 11:17:14 -0400 Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFGwb20847 for ; Thu, 16 Aug 2001 11:16:58 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA22037 for ; Thu, 16 Aug 2001 17:17:11 +0200 (MET DST) Message-ID: <3B7BE3E6.EE28E24C@f-cpu.org> Date: Thu, 16 Aug 2001 17:16:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > > >FC0 issues in-order all the instructions that are considered as valid. > >if a trap occurs, it must NEVER enter the pipeline (because of the OOO > >completion, it would become a nightmare to rewind the pipeline !!!). > > !!! "rewind the pipeline !" You just have to bypass the write back stage ! i told you i was really lazy :-) > >Currently, FC0 uses two addressing spaces : "private" space where the CPU > >is the only master (cache coherency is straight-forward) and "outside world" > >where all the accesses are in-order and uncacheable. > > I don't think it will be very interresting (too slow). It will be much > interresting to manage this inside the VM unit by page (the page will > have the information of none caching, none registering,...). And then a > decoder will send the data thought memory port or fbus port. there will be something like that. however i have to solve a bunch of problems concerning the "execution pipeline" first. > >Use semaphores that are mapped in the SRs ! > In all case, we need to write something in memory or to touch something > in the VM unit. why ? a semaphore is a semaphore, a flag if you want. whether it is implemented in memory or with a dedicated HW in a different addressign space, is "implementation dependent". > So it's just pushing the problem away ! and if possible where it doesn't disturb us :-P the L/S unit is optimised to allow high bandwidth through cache-line width packet transfers, accessing single bytes in scattered order is a good way to "kill" your memory subsystem and the speed of your synchronisation. > More generaly, i find the text very agressive against Alpha.(the 2 first > sentences of the text, for example). We should never forget that alpha > work since 10 years and fcpu is in it's very beginning. So this kink of > speech could make laught a futur investor in the fcpu, never forget > that. i think that you know that i am not "agressive" and that i respect the ALPHA. I have two expensive books about it and unfortunately no Alpha server at home. We can still discuss whether Alpha is dead or not. CPQ will keep Alpha alive artificially as long as IA64 is not a serious competitor. that is enough for me : it's just marketing and financial manipulation, the ALPHA engineers have a very reduced freedom of decision now, because they know that it will be dropped after the 364. So i could say : Alpha is dead as much as F-CPU is alive. it's time to learn alpha's lessons, i think. > nicO > ************************************************************* WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 17:17:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTv-0002kq-00 for ; Thu, 16 Aug 2001 22:11:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:07 +0200 (CEST) Received: (qmail 16165 invoked by uid 0); 16 Aug 2001 15:18:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 16 Aug 2001 15:18:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA09631 for ; Thu, 16 Aug 2001 11:18:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:17:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA08762 for f-cpu-list; Thu, 16 Aug 2001 11:17:35 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA08624 for ; Thu, 16 Aug 2001 11:17:26 -0400 Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFH9b20857 for ; Thu, 16 Aug 2001 11:17:10 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA17145 for ; Thu, 16 Aug 2001 17:17:22 +0200 (MET DST) Message-ID: <3B7BE3F2.8F859E06@f-cpu.org> Date: Thu, 16 Aug 2001 17:17:06 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> <01081613492700.00283@maveric> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Glenn Alexander wrote: > Hi. This is my first post to this list. welcome ! > My background is as a hardware > technician, not a chip designer so bear with me. i don't see where the problem is :-) > On Thursday 16 August 2001 03:41, you wrote: > > Michael Riepe a écrit : > > > > In sparc, there is no 80 bits float but 128 bits (2 registers used in > > the same time). We don't need 1 cycle multiplication so it could be done > > for the fcpu. > > I am thinking that taking the two-register approach might be > over-complicating matters. Since F-CPU is intended to later be scaled above > 64 bits, if someone wanted 128-bit floats in the future they would impliment > a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS > (Keep It Simple for us Stupid people). yup, that's obvious. but we are still defining a lot of things currently. In the absence of both an acurate manual and working execution units, a lot of things are still floating. > BTW: I am wondering about the reasons for having endian-ness encoded in the > instruction. How often do you need to change endinianness. I am thinking a SR > for endinian would free up that bit as well as allowing other endiniannesses > as well as big and little (Not in popular usage at present but I can think of > several other bizaar ways to re-arrange the bits in a word that may be useful > in some obscure application). see my latest post. > I'd be inclined to use that bit to extend the addressing size from 4 > addressing widths to eight as follows: > 000 - 1 bit > 001 - 2 bits > 010 - 4 bits > 011 - 8 bits (mandatory) > 100 - 16 bits (mandatory) > 101 - 32 bits (mandatory) > 110 - 64 bits (mandatory) > 111 - maxWidth (the maximum avaliable width) > > I'm not sure about the merits of the first three widths but they are nice and > neat. do you mean that you want bit addressability ? i'm surprised. I've never needed that, and it makes the load/store unit much more heavy. > Since you don't want a bank select line for every bit, sub-byte writes > would have to be implimented as a read-alter-write, wasting at least one > memory bus cycle. I make no claims as to whether this is worth it. You would > also need to address each bit instead of each byte, chopping 3 effective bits > off your maximum memory size. Crazy idea, I know. AFAIK byte addressability is enough. if you want to access individual bytes, you have to use shift/rotate/mask etc. and perform the read/modify/write with a sequence of instructions. > An alternative might be: > 000 - 8 bits (mandatory) > 001 - 16 bits (mandatory) > 010 - 32 bits (mandatory) > 011 - 64 bits (mandatory) > 100 - 128 bits > 101 - 256 bits > 110 - application defined > 111 - maxWidth (the maximum avaliable width) > > 256-bit floats anyone? in fact, we provided another system for handling "wide" registers. There are usually 3 bits used by every operation code, one is the "SIMD" bit and the 2 others are size bits. In 64-bit implementations, these 2 bits are "hardwired" to sizes 00 - 8 bits 01 - 16 bits 10 - 32 bits 11 - 64 bits in "wide" implementations, a set of SRs define the mapping. when a task is initialised, it is set to the defaults (see above) to provide compatibility, then the application modifies the mapping. It is not hardwired but there is a user-configurable LUT. This way, ANY arbitrary register size can be encoded. I think that it also answers Jürgen's remark. > -------------------------------------------------------- > Glenn Alexander - The man with no surname and a silly hat. i'd like to see that :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Aug 16 08:24:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTw-0002kq-00 for ; Thu, 16 Aug 2001 22:11:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:08 +0200 (CEST) Received: (qmail 12408 invoked by uid 0); 16 Aug 2001 15:45:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 16 Aug 2001 15:45:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA10573 for ; Thu, 16 Aug 2001 11:45:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 15:44:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA10274 for f-cpu-list; Thu, 16 Aug 2001 11:44:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA10271 for ; Thu, 16 Aug 2001 11:44:55 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GFidb21268 for ; Thu, 16 Aug 2001 11:44:39 -0400 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA17554 for ; Thu, 16 Aug 2001 09:44:52 -0600 (MDT) Message-ID: <3B7B6702.A012D816@jetnet.ab.ca> Date: Thu, 16 Aug 2001 00:24:02 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> <01081613492700.00283@maveric> <3B7BE3F2.8F859E06@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > in fact, we provided another system for handling "wide" registers. > There are usually 3 bits used by every operation code, > one is the "SIMD" bit and the 2 others are size bits. > In 64-bit implementations, these 2 bits are "hardwired" > to sizes > 00 - 8 bits > 01 - 16 bits > 10 - 32 bits > 11 - 64 bits > in "wide" implementations, a set of SRs define the mapping. > when a task is initialised, it is set to the defaults (see above) > to provide compatibility, then the application modifies > the mapping. It is not hardwired but there is a user-configurable LUT. > > This way, ANY arbitrary register size can be encoded. > Anybody for 56 bit floating point, ints, pointers ? I was thinking LISP and other list processing languages might want to use the upper byte for internal flags and garbage collection and the remaining 56 bits as data in a 64 bit word. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 17 00:30:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTx-0002kq-00 for ; Thu, 16 Aug 2001 22:11:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:09 +0200 (CEST) Received: (qmail 8010 invoked by uid 0); 16 Aug 2001 16:22:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 16 Aug 2001 16:22:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA11524 for ; Thu, 16 Aug 2001 12:22:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 16:21:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA11268 for f-cpu-list; Thu, 16 Aug 2001 12:21:53 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA11265 for ; Thu, 16 Aug 2001 12:21:51 -0400 Received: from localhost.localdomain (nas7-130.vlt.club-internet.fr [194.158.109.130]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GGLYb21743 for ; Thu, 16 Aug 2001 12:21:35 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1ACAF15D3 for ; Thu, 16 Aug 2001 18:30:51 -0400 (EDT) Message-ID: <3B7C499A.B97ABA7@ifrance.com> Date: Thu, 16 Aug 2001 18:30:50 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> <3B7C06E1.EF155DA9@ifrance.com> <3B7BE3E2.728A1FC5@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > I could add there is many assembler soon written. So maybe, it will be > > more interresting to make a quick emulator. Whygee one is for proof of > > concept. > it is also for preparing RTL files. > > > So, we need a quick one to run long program at raisonnable speed. > i think that it can't be "invented" : those who want to make > lightning-fast emulators must read other's SW. There are many > techniques and tricks such as "compiling" huge jmp tables on teh fly etc... > > > If you put macro inside your asm, never forget to introduice the dot > > (like .not), most of the time we expect that 1 instruction take 32 bits > > but it could be much more with macro. > ? > > can you explain with more details/examples ? > For me ASM is just an other way to read a binary code. But if you use macro, you don't know how much instruction are inserted like for .not wich combine 2 instructions, or .loadcons with more than 16 bit. So the dot si a good way to say : be carefull it's bigger than usual. nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 18:24:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTTy-0002kq-00 for ; Thu, 16 Aug 2001 22:11:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:10 +0200 (CEST) Received: (qmail 11646 invoked by uid 0); 16 Aug 2001 16:25:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Aug 2001 16:25:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA11857 for ; Thu, 16 Aug 2001 12:25:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 16:24:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA11596 for f-cpu-list; Thu, 16 Aug 2001 12:24:33 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA11593 for ; Thu, 16 Aug 2001 12:24:32 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GGOGb21873 for ; Thu, 16 Aug 2001 12:24:16 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA12845 for ; Thu, 16 Aug 2001 18:24:26 +0200 (MET DST) Message-ID: <3B7BF3A9.5B0E4DD4@f-cpu.org> Date: Thu, 16 Aug 2001 18:24:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: (m) Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i finally take some time to answer this long and interesting mail. blame it on the pillow. Michael Riepe wrote: > On Wed, Aug 15, 2001 at 10:22:11AM +0200, Yann Guidon wrote: > [...] > > > SIMD is IMHO not reasonable for the FP units. > > in what context are you speaking ? > I mean: I think it's unreasonable to build *variable-size* FP units. > There are too many special cases to consider -- rounding, exceptions, > infinities and NANs, ... (ok, go blame IEEE for it ;) come on, pipelined/vector FP and SIMD FP are not new. On top of that i have added a new condition for jumps : NaN. > > > A reasonable approach is > > > to build a set of pipelined 64-bit FP units, and then issue the 32-bit > > > operations in two consecutive cycles. > > that's vectoring, then. Scheduling might become more complex, > > in situations such as chaining for example. > Not if it's "hidden" inside the EU. i fear the worse now ;-) > > I have nothing to object to that, but > > - 1) currently we have no FP unit > > - 2) SIMD already works well (when it does) > > - 3) vectoring will be used in another core because FC0 would require too much changes > > - 4) if you have 1 FP unit, the hardest is done : you can duplicate it :-P > If you have enough room. Do you have an idea how big the FP unit will be? i know that others have done that. Ok, it takes "some room" but you get what you pay for. > > > BTW: I think we need another instruction that converts 32-bit FP to 64-bit > > > and vice versa (and maybe also does the mix/expand/sdup thingy for FP). > > geez, the instruction set in the current version of the manual needs a big rework... > Yep. There are a handful of inconsistencies, typing errors, missing > parts etc. in it. thank you for remembering me that :-P > Major things I've found so far: > > - The manual doesn't state whether `modi' is a signed operation > I suggest it should be signed (like `divi') i think that it goes along with the divide unit that you are doing. > - Complement `abs' with `nabs' (negative absolute) for > symmetry, and to avoid the `sign surprise' when the argument > is -2**(chunksize-1) negation should be no worry, but the INC unit is still oncomplete. it is optional, though (currently). > - The syntax for the rounding mode (`l2int', `f2int') is not > specified. I suggest to use the following syntax: > > l2int[r|t|f|c] > f2int[r|t|f|c][x] > > with these meanings: > > -r (round) round to nearest (default) > -t (trunc) round towards zero > -f (floor) round towards -infinity > -c (ceil) round towards +infinity it looks ok. > - `int2f' and `int2l' also need rounding modes because both > conversions may result in precision loss if the integer operand > has a large value. > > - `bitop[s|c|x|t]i' should be `bitopi[s|c|x|t]' (`i' is NOT a suffix!) i agree. > - Assign four opcodes for bitop[i] and increase the imm6 operand > to imm8 (for consistency with the rop2, shift, rot, bitrevi and > loadcons[x] instructions). right. > Since bitop[i] is a ROP2 instruction, > change the function encoding to match that of rop2, that is: > > fun rop2 bitop > ================ > 000 and btst > 001 andn bclr > 010 xor bchg > 011 or bset > 100 nor -- > 101 xnor -- > 110 orn -- > 111 nand -- > > I guess we can get the missing four instructions for free, > but they aren't really useful. it seems interesting but i have done something else. i've dropped the "mode bits" instead so we have all functions available. check my latest snapshot : f-cpu/ contains some text files which describe the changes. > - The description of the ROP2 is obsolete (and the syntax for > combine/mux is unspecified) I suggest -o and -a suffixes for > combine, and a new `mux' instruction. > > - For the `andn' and `orn' instructions, the manual must > clearly state which operand is inverted. IMHO, `andni' and > `orni' will be almost useless if we invert the leftmost > (== immediate) operand (but not completely useless, because > the upper bits differ when the chunk size is 16 or more). > > On the other hand, we could add a flag for sign extension of the > immediate operand and invert the middle (== register) operand. > Since the function bits have moved to the opcode field, there > should be a free flag. > > - There is no explicit `not' instruction, but users can write > `nor r0, r2, r1', `xnor r0, r2, r1' or similar. Since this > may not be obvious, F-CPU assemblers should recognize `not > r2, r1' and convert it to one of the other forms internally. > The `not' instruction should, however, be documented in the > Instruction Set Manual. > > - In `bitrev[i]', use the formula `r1 = bit_reverse(r2) >> (size-r3-1)'. > That will change the useful range for r3 to [size-1;0]. In the > current version, it's [size;1] which is pretty ugly. > > Another possible variant is `r1 = bit_reverse(r2) >> r3', with > the same useful range but a nicer default (r3 == r0) which > makes the 2-operand short form `bitrev r2, r1' meaningful, > but that may cause trouble when the register size is increased > beyond 64 bits :( > > - `flog' and `fexp' should both take only two operands. > Remember that (a**b)**c = a**(b*c) = a**(c*b) = (a**c)**b. > That is, with a simple multiplication (before fexp / after > flog) you get any base you want, and the FP unit probably > works better with a fixed base. > > - We need a level-1 floating-point compare instruction; > `cmpl'/`cmple' may work with LNS (if there are no NANs), > but not with FP. IEEE FP defines FP comparison with Integer operations. the format has be designed specifically for this purpose (however i don't remember what happens with NaNs etc) > - The arguments of `store[f]' are reversed (dest, src). It's > ok that way (because it mirrors the `load' instruction) but > there should be a BIG FAT WARNING in the manual. there will certainly be a change in the L/S instruction format ! the pointer that gets updated must be written somewhere and the current fields don't match the expected behaviour. ie : load r1, r2, r3 does : load [r2] into r3, and add r1 to r2 this means that the r2 field must be written to. IT IS NOT POSSIBLE yet. so it will become : "load [r2] into r3, and r1 + r2 => r3^1" > - Some immediate instructions may benefit from a non-linear > encoding of the immediate operand (for example, 6 bits value + > 2 bits left-shift). At least this is an option for `loadi' > and `storei'. maybe but it makes the decoder more complex. > - The naming of the memory hierarchies in the `cachemm' > instruction is ambiguous (in particular, the -c and -l suffixes). > We can still use numeric suffixes [0-7], however. > > Again, the arguments are reversed (`cachemm addr,count'). > > - In the description of `move', remove the reference to `nop'. ASAP. > BTW: there is no need to give `cmove' a separate name and > opcode. maybe, maybe not. you are certainly right but i'll verify with some real code. > If there is a condition suffix, it's a conditional move > (3-operand form), otherwise it's unconditional (2 operands): > > move[s]{cond} r3, r2, r1 > move[s] r2, r1 yo. > - We need to clarify the syntax of the `condition' suffixes for > `move' and `jmpa'. I suggest > > 000 -z (zero) > 001 (unassigned) > 010 -m (msb == 1) > 011 -l (lsb == 0) > 100 -nz (not zero) > 101 (unassigned) > 110 -nm (msb == 0) > 111 -nl (lsb == 0) in the assembler that i have written, it's written differently and more verbosely (less confusing when you don't know the meanings). > - Assemblers must accept `loadcons[x] large-number' and emit a > suitable series of loadcons.n (or loadconsx.n) instructions > instead. This is necessary for external symbol references > (which are resolved at link time). Assemble-time constants > may be shortened to less than 64 bits, however, and if the > user explicitly requests `loadcons.0' or `loadconsx.0', the > assembler should of course do what (s)he wants (and complain > if the value is too large). > > - Can we please drop the `a' from `jmpa'? probably. i don't remember where it comes from, probably from Mathias. > As with `move', the presence of the condition suffix indicates > the form of the instruction: > > jmp[a]{cond} r3, r2 [, r1] > jmp[a] r2 [, r1] looks ok. > - When calling functions through pointers, it would be nice to > be able to tell the F-CPU *a priori* that a register contains a > code address. While this can be done with an explicit prefetch > (load to r0) for data pointers, there is no way to specify that > a register contains a code address that the CPU will have to > visit soon. what about loadaddr(i) ? > The same is true when an absolute code address is > obtained via loadcons (which will probably be the common idiom > when a function in another object file is called, unless jump > tables are used -- which points us back to the `code pointer > in register' problem, again). if the data/code is not explicitely prefetched, the code will still work, but with the "late fetch" penalty : the CPU will perform the "fetch" operation automatically while stalling the decode stage. > To cut a long story short: I'd like to have an instruction > that explicitly `tags' a register as a pointer, and probably > initiates a prefetch cycle (for code or data, depending on > the instruction's flags). It may or may not move data from > one register to another (one idea I had was a `pointer move' > instruction); if it does, it might be a good idea to let it > participate in address calculation (i.e. let it be able to > add two operands, like the `lea' instruction on Intel CPUs). this is what loadaddr is meant to do. > - Let's clarify the suffix order, e.g. like this (? means the > suffix is currently unused, and its name is unassigned): > > add[c|s|?] > sub[b|f|?] > mul[h][s] > div[m][s] > mac[l|h][s] # I suggest to allow `macl' as an alias for `mac'. > scan[n][r] > bitop[s|c|x|t] > bitopi[s|c|x|t] > mix[l|h] > expand[l|h] > {rop2}[a|o] > {rop2i}[a|o] > load[f][e][0-7] > loadi[f][e][0-7] > store[f][e][0-7] > storei[f][e][0-7] > cachemm[f|p][l][c][0-7] > move[s][n][z|?|m|l] > jmpa[n][z|?|m|l] > serialize[s][x][m] wow, what a work :-) > - Some instructions (e.g. `mac' and `addsub') could have > variants with an immediate operand. glups. maybe. > - The loadm/storem has a surprising operand order > (start,src/dest,count), and it's not clear whether the > register *numbers* or the register *contents* serve as the > start/count values. I suggest the former, and I would also > change the operands to (firstreg, lastreg, memaddr) which is > much easier to grok for humans. some remarks : - it is optional and conditioned by the presence of a SRB mechanism - the 2nd register field is always the address. It must be pre-validated if possible. - whether it is the contents or the value of the address does not change much except that the value is know 2 cycles before or after. i'd prefer to use the register number than its value, though, if possible. though using the register contents might also help. > Since there are some unused flags, another variant might be > interesting: `storem r2, r1', where r2 is used as a mask > (bit == 1 means "load/store register "), and r1 is the > address of the source/destination memory area (which must be > big enough to hold all registers, just like the CMB). this mask idea is interesting. It remembers me of the 6809 by the way :-) however it means that 4x loadcons might be necessary (in arbitrary cases) to backup the whole (non-contiguous) register set. > Maybe it would be wiser to put the memory address into the > rightmost operand in *all* memory operations (load, store, > cachemm, loadm and storem). Some instructions will always > have the wrong operand order, though. right. but i still prefer to leave the "pointer" field in the middle, because it is the most usual case where it makes sense (at least for myself). > - And finally, the most important point: the new `nop' instruction > is still undocumented ;) yes, yes i know. > In case you wonder: I needed a break from VHDL coding (I couldn't > even write C any more!), all my sympathy ! > so I decided to play with something totally > different for a while. :-) > The result is a flex-based instruction encoder > that recognizes almost any instruction the F-CPU will have (with the > exceptions mentioned above). I'll probably also build an assembler > around it. (I finally found a real use for my libelf library! Yeah! ;) where's the source code ? :-) btw, please provide a "raw mode" so emulators don't need clomplex load functions... > > Sure, there needs to be an expansion/reduction code for FP > > but SDUP works for SIMD FP if the packets have the same boundaries. > That's a different kind of operation. ? SDUP (IIRC) "duplicates" one item of a specified size into all the rest of the destination register. whether the data is FP or int or whatever doesn't change anything (as long as the data size is valid). expansion/reduction is another problem but i think that the SHL unit can do this, too. Another proposition : make a signed and unsigned version of the integer expansion so we can extend the sign of the datum. This removes the "sign extension" flag >from the move instruction and it removes one funky operation from the Xbar. wow, all these things to do remember me that the summer is soon over... i don't think i'll be able to do all this before october begins. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 18:24:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU1-0002kq-00 for ; Thu, 16 Aug 2001 22:11:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:13 +0200 (CEST) Received: (qmail 32189 invoked by uid 0); 16 Aug 2001 16:25:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 16 Aug 2001 16:25:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA12135 for ; Thu, 16 Aug 2001 12:25:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 16:25:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA11881 for f-cpu-list; Thu, 16 Aug 2001 12:25:21 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA11876 for ; Thu, 16 Aug 2001 12:25:19 -0400 Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GGOob22057 for ; Thu, 16 Aug 2001 12:24:51 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA03756 for ; Thu, 16 Aug 2001 18:25:02 +0200 (MET DST) Message-ID: <3B7BF3CD.EFB4591D@f-cpu.org> Date: Thu, 16 Aug 2001 18:24:45 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: "reinventing RISC" (was Re: [f-cpu] Re: Floating-Point?) References: <3B7B4F2A.A1EFB267@jetnet.ab.ca> <3B7C3013.787E05A3@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, nicO wrote: > Ben Franchuk a écrit : > > Juergen Goeritz wrote: > > PS.What would be nice is to have non standard sizes for special > > functions. While not used any more 3 - 5 bit fields come to mind > > for packing 15 bit colors for a video display. today, 24-bit display is a commodity, so why bother ? ;-) > Maybe a shift&mask (SIMD) instruction could be enough. You just add an > instruction but just for the convertion. it IS enough. then Ben Franchuk wrote: > nicO wrote: > > Maybe a shift&mask (SIMD) instruction could be enough. You just add an > > instruction but just for the convertion. > The PDP-10 had a very nice bit packing/unpacking instructions but that > is CISC rather RISC stuff. Ben. Some other non-CISC have nice bitfield extraction/insertion capabilities. unfortunately there are 2 problems : - make the function fit into a F-CPU instruction format - keep the instruction scalable. What looks good for a computer will not be useful when the register size increases, for example. There are some proposed (optional) instructions for this kind of operations in the F-CPU opcode map, but the necessary unit must be designed. notice that the recently added MUX instruction helps a bit. Juergen Goeritz wrote: > On Wed, 15 Aug 2001, Ben Franchuk wrote: > > Ok what about instruction decoding of the opcode in a configuration > > register with each setup modifying the fields used? > > version 1 - endian bit active high > > version 2 - endian bit active low > > ( Special register xor endian flag ). > > Ben. > > What's the hack here if it's just one bit? Why does > it add up to and complicate the decode stage? Since > after decode the intermediate signals have to be > registered anyway for later execution I don't really > see the point. Could someone please point me to it? > > The other suggestion about using a toggle filpflop > may be interesting either - but I am a bit worried > about the poor compiler designers... i was thinking about that, too. why make it more complex than it already is ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 17 00:40:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU1-0002kq-01 for ; Thu, 16 Aug 2001 22:11:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:13 +0200 (CEST) Received: (qmail 10372 invoked by uid 0); 16 Aug 2001 16:31:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 16 Aug 2001 16:31:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA12543 for ; Thu, 16 Aug 2001 12:31:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 16:31:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA12287 for f-cpu-list; Thu, 16 Aug 2001 12:31:04 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA12282 for ; Thu, 16 Aug 2001 12:31:03 -0400 Received: from localhost.localdomain (nas7-130.vlt.club-internet.fr [194.158.109.130]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GGUkb22187 for ; Thu, 16 Aug 2001 12:30:46 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 12C9E15D3 for ; Thu, 16 Aug 2001 18:40:03 -0400 (EDT) Message-ID: <3B7C4BC3.F058CE06@ifrance.com> Date: Thu, 16 Aug 2001 18:40:03 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > > > >FC0 issues in-order all the instructions that are considered as valid. > > >if a trap occurs, it must NEVER enter the pipeline (because of the OOO > > >completion, it would become a nightmare to rewind the pipeline !!!). > > > > !!! "rewind the pipeline !" You just have to bypass the write back stage ! > > i told you i was really lazy :-) > > > >Currently, FC0 uses two addressing spaces : "private" space where the CPU > > >is the only master (cache coherency is straight-forward) and "outside world" > > >where all the accesses are in-order and uncacheable. > > > > I don't think it will be very interresting (too slow). It will be much > > interresting to manage this inside the VM unit by page (the page will > > have the information of none caching, none registering,...). And then a > > decoder will send the data thought memory port or fbus port. > > there will be something like that. > however i have to solve a bunch of problems concerning the > "execution pipeline" first. > > > >Use semaphores that are mapped in the SRs ! > > In all case, we need to write something in memory or to touch something > > in the VM unit. > why ? a semaphore is a semaphore, a flag if you want. > whether it is implemented in memory or with a dedicated HW in > a different addressign space, is "implementation dependent". > In all case, you have one memory access + 1 or more port to the outside. Plus, you could add many problem for multicpu system. So there isn't any port dedicated to it, and shouldn't have ! Because it so tight to the OS, that we could have many compatibility problem in the futur. I think you thought to an implementation of SGI not really usual processor. Today's µp implement semaphore with atomic read_modify_write instructions. > > So it's just pushing the problem away ! > and if possible where it doesn't disturb us :-P > > the L/S unit is optimised to allow high bandwidth through > cache-line width packet transfers, accessing single bytes > in scattered order is a good way to "kill" your memory subsystem > and the speed of your synchronisation. > You could add specific memory barrer (semaphore aren't so common!). > > More generaly, i find the text very agressive against Alpha.(the 2 first > > sentences of the text, for example). We should never forget that alpha > > work since 10 years and fcpu is in it's very beginning. So this kink of > > speech could make laught a futur investor in the fcpu, never forget > > that. > > i think that you know that i am not "agressive" and that i respect the > ALPHA. I have two expensive books about it and unfortunately no > Alpha server at home. > > We can still discuss whether Alpha is dead or not. CPQ will keep > Alpha alive artificially as long as IA64 is not a serious competitor. > that is enough for me : it's just marketing and financial manipulation, > the ALPHA engineers have a very reduced freedom of decision now, > because they know that it will be dropped after the 364. > > So i could say : Alpha is dead as much as F-CPU is alive. > it's time to learn alpha's lessons, i think. > the problem is the tone not the content. nicO > > nicO > > ************************************************************* > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 16 19:15:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU2-0002kq-00 for ; Thu, 16 Aug 2001 22:11:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:14 +0200 (CEST) Received: (qmail 10188 invoked by uid 0); 16 Aug 2001 17:16:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 16 Aug 2001 17:16:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA14175 for ; Thu, 16 Aug 2001 13:16:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 17:15:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA13923 for f-cpu-list; Thu, 16 Aug 2001 13:15:41 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA13920 for ; Thu, 16 Aug 2001 13:15:40 -0400 Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GHFOb22798 for ; Thu, 16 Aug 2001 13:15:24 -0400 Received: from f-cpu.org (nas3-10.ras.club-internet.fr [195.36.203.10]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA21346 for ; Thu, 16 Aug 2001 19:15:37 +0200 (MET DST) Message-ID: <3B7BFFA7.9922B88A@f-cpu.org> Date: Thu, 16 Aug 2001 19:15:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B785820.969A851B@f-cpu.org> <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> <3B7C06E1.EF155DA9@ifrance.com> <3B7BE3E2.728A1FC5@f-cpu.org> <3B7C499A.B97ABA7@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > If you put macro inside your asm, never forget to introduice the dot > > > (like .not), most of the time we expect that 1 instruction take 32 bits > > > but it could be much more with macro. > > ? > > > > can you explain with more details/examples ? > > > For me ASM is just an other way to read a binary code. But if you use > macro, you don't know how much instruction are inserted like for .not > wich combine 2 instructions, or .loadcons with more than 16 bit. So the > dot si a good way to say : be carefull it's bigger than usual. i didn't know this kind of syntax. btw, "not" a register does not need 2 instructions, one is enough. you can don "xnor r0, src, dest" for example. for loadcons, we can probably use another syntax or even a pre-processor : i'm thinking about the in-source debugging. btw, IIRC there is no debugger yet. there are plans for cross-emulators but it is not enough, what will we do when the real chip will be available ? we can use the emulator to debug the debugger stub, for example. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 20:47:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU5-0002kq-01 for ; Thu, 16 Aug 2001 22:11:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:17 +0200 (CEST) Received: (qmail 29935 invoked by uid 0); 16 Aug 2001 19:00:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 16 Aug 2001 19:00:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA18453 for ; Thu, 16 Aug 2001 14:59:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 18:59:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA17719 for f-cpu-list; Thu, 16 Aug 2001 14:59:12 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA17716 for ; Thu, 16 Aug 2001 14:59:10 -0400 Received: from tribble.stud.uni-hannover.de (root@a128.home.uni-hannover.de [130.75.232.128]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GIwrb25053 for ; Thu, 16 Aug 2001 14:58:53 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01210; Thu, 16 Aug 2001 20:47:43 +0200 Message-ID: <20010816204743.60168@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 20:47:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7BD51F.2031DD5@f-cpu.org> <3B7B56F5.94C34BD8@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7B56F5.94C34BD8@jetnet.ab.ca>; from Ben Franchuk on Wed, Aug 15, 2001 at 11:15:33PM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 15, 2001 at 11:15:33PM -0600, Ben Franchuk wrote: [...] > Ok what about instruction decoding of the opcode in a configuration > register with each setup modifying the fields used? > version 1 - endian bit active high > version 2 - endian bit active low > ( Special register xor endian flag ). No, no, three times NO! Can you imagine what happens when a piece of code runs with the wrong configuration settings? *kaboom* FUBAR. Don't you remember the `D' flag in Intel's x86? Let's not duplicate this insanity. A configuration register should NEVER affect the semantics of a program. The configurable translation (size bits -> register size) is already too much, from a programmer's point of view. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 20:26:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU6-0002kq-00 for ; Thu, 16 Aug 2001 22:11:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:18 +0200 (CEST) Received: (qmail 7966 invoked by uid 0); 16 Aug 2001 19:00:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 16 Aug 2001 19:00:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA18530 for ; Thu, 16 Aug 2001 15:00:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 18:59:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA17761 for f-cpu-list; Thu, 16 Aug 2001 14:59:15 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA17737 for ; Thu, 16 Aug 2001 14:59:13 -0400 Received: from tribble.stud.uni-hannover.de (root@a128.home.uni-hannover.de [130.75.232.128]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GIwtb25058 for ; Thu, 16 Aug 2001 14:58:56 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01150; Thu, 16 Aug 2001 20:26:20 +0200 Message-ID: <20010816202619.64025@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 20:26:19 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7C05F4.35FA607C@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7C05F4.35FA607C@ifrance.com>; from nicO on Thu, Aug 16, 2001 at 01:42:12PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 01:42:12PM -0400, nicO wrote: [...] > For your 16 bit fp processing, could not be better to use log number ? > For audio processing it could be enough (no DC stuff). [...] 16-bit LNS would be fine as well. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 20:33:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU7-0002kq-00 for ; Thu, 16 Aug 2001 22:11:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:19 +0200 (CEST) Received: (qmail 4522 invoked by uid 0); 16 Aug 2001 19:00:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 16 Aug 2001 19:00:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA18605 for ; Thu, 16 Aug 2001 15:00:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 18:59:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA17818 for f-cpu-list; Thu, 16 Aug 2001 14:59:19 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA17787 for ; Thu, 16 Aug 2001 14:59:16 -0400 Received: from tribble.stud.uni-hannover.de (root@a128.home.uni-hannover.de [130.75.232.128]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GIwvb25061 for ; Thu, 16 Aug 2001 14:58:58 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01171; Thu, 16 Aug 2001 20:33:24 +0200 Message-ID: <20010816203324.03725@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 20:33:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> <3B7C06E1.EF155DA9@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7C06E1.EF155DA9@ifrance.com>; from nicO on Thu, Aug 16, 2001 at 01:46:09PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 01:46:09PM -0400, nicO wrote: [...] > If you put macro inside your asm, never forget to introduice the dot > (like .not), most of the time we expect that 1 instruction take 32 bits > but it could be much more with macro. [...] Names with a leading `.' are usually reserved for ASM directives (like .align, .org, .byte, .global and so on). `not r2, r1' translates to something like `nor r0, r2, r1', so there *is* only one instruction. The only exception is the `generic loadcons' which may emit several instructions (but in a predictable -- and documentable -- way). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 17:13:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU8-0002kq-00 for ; Thu, 16 Aug 2001 22:11:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:20 +0200 (CEST) Received: (qmail 30324 invoked by uid 0); 16 Aug 2001 19:00:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 16 Aug 2001 19:00:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA18803 for ; Thu, 16 Aug 2001 15:00:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 18:59:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA18371 for f-cpu-list; Thu, 16 Aug 2001 14:59:54 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA18302 for ; Thu, 16 Aug 2001 14:59:47 -0400 Received: from tribble.stud.uni-hannover.de (root@a128.home.uni-hannover.de [130.75.232.128]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GIxRb25088 for ; Thu, 16 Aug 2001 14:59:27 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00564; Thu, 16 Aug 2001 17:13:23 +0200 Message-ID: <20010816171322.38671@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 17:13:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL interface References: <20010814021947.30730@thrai.stud.uni-hannover.de> <3B787096.15E10539@f-cpu.org> <20010814030256.63061@thrai.stud.uni-hannover.de> <3B787A07.6C80ADEB@f-cpu.org> <20010814040728.34336@thrai.stud.uni-hannover.de> <3B78E4CD.70CBD0F7@f-cpu.org> <20010814195955.49330@thrai.stud.uni-hannover.de> <3B79F01E.2CE07BFE@f-cpu.org> <20010815141407.43955@thrai.stud.uni-hannover.de> <3B7B518A.A523A7A8@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7B518A.A523A7A8@f-cpu.org>; from Yann Guidon on Thu, Aug 16, 2001 at 06:52:26AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 06:52:26AM +0200, Yann Guidon wrote: [...] > i just woke up and have to digest all your interesting posts, > but concerning the assembler, i encourage you to reuse as much > as possible from the one found at htt://www.f-cpu.de/design/snapshot.tgz > it is a working assembler frame with bells and whistles, > modifying the (small) syntax should be really easy. It really has a lot of bells and whistles, but it also lacks a lot of things. We need an assembler that works with gcc; your one is more useful for assembler coding than for compiler post-processing. But we can integrate the instruction encoder anyway :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 17:31:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU8-0002kq-01 for ; Thu, 16 Aug 2001 22:11:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:20 +0200 (CEST) Received: (qmail 21824 invoked by uid 0); 16 Aug 2001 19:00:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 16 Aug 2001 19:00:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA19064 for ; Thu, 16 Aug 2001 15:00:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 19:00:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA18786 for f-cpu-list; Thu, 16 Aug 2001 15:00:28 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA18770 for ; Thu, 16 Aug 2001 15:00:25 -0400 Received: from tribble.stud.uni-hannover.de (root@a128.home.uni-hannover.de [130.75.232.128]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GIxdb25094 for ; Thu, 16 Aug 2001 14:59:46 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00668; Thu, 16 Aug 2001 17:31:42 +0200 Message-ID: <20010816173142.58827@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 17:31:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> <01081613492700.00283@maveric> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <01081613492700.00283@maveric>; from Glenn Alexander on Thu, Aug 16, 2001 at 01:49:27PM +0800 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 01:49:27PM +0800, Glenn Alexander wrote: > Hi. This is my first post to this list. My background is as a hardware > technician, not a chip designer so bear with me. > > On Thursday 16 August 2001 03:41, you wrote: > > Michael Riepe a écrit : > > > > In sparc, there is no 80 bits float but 128 bits (2 registers used in > > the same time). We don't need 1 cycle multiplication so it could be done > > for the fcpu. > > I am thinking that taking the two-register approach might be > over-complicating matters. Since F-CPU is intended to later be scaled above > 64 bits, if someone wanted 128-bit floats in the future they would impliment > a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS > (Keep It Simple for us Stupid people). 128-bit `quadruple precision' (like SPARC) is IMHO the way to go, but not in the FC0. For now, let's stick to 32-bit and 64-bit (with 80-bit `double extended' used inside the FP unit, to maintain IEEE compliance). > BTW: I am wondering about the reasons for having endian-ness encoded in the > instruction. How often do you need to change endinianness. I am thinking a SR > for endinian would free up that bit as well as allowing other endiniannesses > as well as big and little (Not in popular usage at present but I can think of > several other bizaar ways to re-arrange the bits in a word that may be useful > in some obscure application). Please don't. Mode registers are a PITA. You never know whether they're set correctly (like the `D' flag on x86). Except for the register width translation SRs, NO special register should affect the semantics of a program! We could drop the `e' flag and use [s]byterev.* to swap the bytes. But byterev takes 3 extra cycles to execute, while load/store don't slow down in `foreign-endian' mode. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From philippe.trbich@free.fr Thu Aug 16 21:50:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XTU9-0002kq-00 for ; Thu, 16 Aug 2001 22:11:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 16 Aug 2001 22:11:21 +0200 (CEST) Received: (qmail 3741 invoked by uid 0); 16 Aug 2001 19:49:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 16 Aug 2001 19:49:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA21013 for ; Thu, 16 Aug 2001 15:49:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 19:49:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA20759 for f-cpu-list; Thu, 16 Aug 2001 15:49:21 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA20755 for ; Thu, 16 Aug 2001 15:49:20 -0400 Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GJn4b26217 for ; Thu, 16 Aug 2001 15:49:04 -0400 Received: from linux (nantes-2-a7-39-22.dial.proxad.net [213.228.39.22]) by postfix1-2.free.fr (Postfix) with SMTP id ADD43AB47A for ; Thu, 16 Aug 2001 21:49:17 +0200 (CEST) Date: Thu, 16 Aug 2001 21:50:11 +0200 From: philippe.trbich@free.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? Message-Id: <20010816215011.5d9fda0f.philippe.trbich@free.fr> In-Reply-To: <3B7BE3DF.CCE3BA5A@f-cpu.org> References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7C05F4.35FA607C@ifrance.com> <3B7BE3DF.CCE3BA5A@f-cpu.org> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 16 Aug 2001 17:16:47 +0200 Yann Guidon wrote: > hi, > > nicO wrote: > > Michael Riepe a écrit : > > > If you have enough room. Do you have an idea how big the FP unit will be? > > It's big but not as a 256 Ko SRAM cache. So it will be the choice of the > > user. Duplicate big unit could save a lot of computing power (because > > you make a single run). > > After all, the files are under GPL so they can be modified if needed. > > > For your 16 bit fp processing, could not be better to use log number ? > > For audio processing it could be enough (no DC stuff). > > i'd rather use 32-b ints or 32-b FP instead of 16-b FP. > unless you really don't care about the huge rounding noise that you will > create. 16-b and 32-b LNS could be used too, but i know that some people > are not very happy with it. > > > For the following text, it could be nice to update quickly the manual. > > If whygee is ok. > > the "little" problem is that Olivier Jean has not submitted his work. > > i'm ok for modifying the manual, of course, but it is a very heavy > and long work and if Olivier comes with a "forked" revision, > the branch merge will be another nightmare. > > - i hope that olivier will send some news about what he has done, > is doing and will do. > - we can prepare "patches" that will be applied to the manual in either > new or old version. these would be "manual patches" in case a new > manual revision comes. If I remember well, the manual is on CVS and can be used to be updated. I think that's the best way (time saver) to work! Before put it on CVS, it'll be great to propose updates to the list. Pas lui, l'autre. > > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 17 00:35:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XZw3-0004L9-01 for ; Fri, 17 Aug 2001 05:04:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 Aug 2001 05:04:35 +0200 (CEST) Received: (qmail 9389 invoked by uid 0); 16 Aug 2001 22:41:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 16 Aug 2001 22:41:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA24805 for ; Thu, 16 Aug 2001 18:41:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 22:41:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA24339 for f-cpu-list; Thu, 16 Aug 2001 18:41:24 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA24336 for ; Thu, 16 Aug 2001 18:41:23 -0400 Received: from tribble.stud.uni-hannover.de (root@a107.home.uni-hannover.de [130.75.232.107]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GMedb28853 for ; Thu, 16 Aug 2001 18:40:40 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01885; Fri, 17 Aug 2001 00:35:53 +0200 Message-ID: <20010817003553.36482@thrai.stud.uni-hannover.de> Date: Fri, 17 Aug 2001 00:35:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7BF3A9.5B0E4DD4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7BF3A9.5B0E4DD4@f-cpu.org>; from Yann Guidon on Thu, Aug 16, 2001 at 06:24:09PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 06:24:09PM +0200, Yann Guidon wrote: [...] > > I mean: I think it's unreasonable to build *variable-size* FP units. > > There are too many special cases to consider -- rounding, exceptions, > > infinities and NANs, ... (ok, go blame IEEE for it ;) > > come on, pipelined/vector FP and SIMD FP are not new. > On top of that i have added a new condition for jumps : NaN. Didn't we already decide that months ago? [...] > > - The manual doesn't state whether `modi' is a signed operation > > I suggest it should be signed (like `divi') > i think that it goes along with the divide unit that you are doing. The IDU will be able to perform both signed and unsigned division/remainder. The signed division will be symmetric (FORTH people probably know this as SM/REM). I still have to elaborate whether asymmetric `floored' division and modulus (FM/MOD) is possible. > > - We need a level-1 floating-point compare instruction; > > `cmpl'/`cmple' may work with LNS (if there are no NANs), > > but not with FP. > > IEEE FP defines FP comparison with Integer operations. Yes, but unfortunately in sign-magnitude (not 2's complement) form. > the format has be designed specifically for this purpose > (however i don't remember what happens with NaNs etc) IIRC, if at least one of the operands is a NAN, the result of all comparisions (except `!=') is always false. Mapped to (2's complement signed) integer, the order is as follows (assuming IEEE `single' format): s eeeee fff meaning ===================== 0 ff >0 NAN 0 ff =0 +INF 0 01-fe any positive normal 0 00 >0 positive subnormal 0 00 =0 +0 1 ff >0 NAN 1 ff =0 -INF 1 01-fe any negative normal 1 00 >0 negative subnormal 1 00 =0 -0 That's obviously not correct. > > - The arguments of `store[f]' are reversed (dest, src). It's > > ok that way (because it mirrors the `load' instruction) but > > there should be a BIG FAT WARNING in the manual. > > there will certainly be a change in the L/S instruction format ! > the pointer that gets updated must be written somewhere and the > current fields don't match the expected behaviour. ie : > load r1, r2, r3 does : load [r2] into r3, and add r1 to r2 > this means that the r2 field must be written to. IT IS NOT POSSIBLE yet. > so it will become : "load [r2] into r3, and r1 + r2 => r3^1" I like the current form better. This one is too crazy. [...] > > - We need to clarify the syntax of the `condition' suffixes for > > `move' and `jmpa'. I suggest > > > > 000 -z (zero) > > 001 (unassigned) > > 010 -m (msb == 1) > > 011 -l (lsb == 0) > > 100 -nz (not zero) > > 101 (unassigned) > > 110 -nm (msb == 0) > > 111 -nl (lsb == 0) > > in the assembler that i have written, it's written differently > and more verbosely (less confusing when you don't know the meanings). Yep, I saw the .lsb/.msb/.and/.or suffixes. I didn't find .zero or a negation suffix, though. I suggest we allow both forms -- the long one for humans, the short one for compilers (or people like me, who don't like writing a novel to flip a single bit ;). Summarized: 000 -z .zero, .z, .null, ... 001 -x .nan, .not.number, ... 010 -m .msb, .msb1, ... 011 -l .lsb, .lsb1, ... 100 -nz .notzero, .not.zero, .nz, ... 101 -nx .notnan, .not.nan, .number, ... 110 -nm .notmsb, .not.msb, .msb0, ... 111 -nl .notlsb, .not.lsb, .lsb0, ... I choose the short names, you the long names ;) In case you wonder, the `x' stands for `eXtra' or `eXception'. I could also use `n' for `NAN', but that makes the instruction encoder a little more complex and is probably misleading anyway. But I'll think it over. [...] > > - Can we please drop the `a' from `jmpa'? > probably. i don't remember where it comes from, probably from Mathias. It was meant to indicate an (A)bsolute jump. Since that's the only one the F-CPU knows, the suffix is redundant (and it looks too much like `jump always'). > > - When calling functions through pointers, it would be nice to > > be able to tell the F-CPU *a priori* that a register contains a > > code address. While this can be done with an explicit prefetch > > (load to r0) for data pointers, there is no way to specify that > > a register contains a code address that the CPU will have to > > visit soon. > what about loadaddr(i) ? Not useful. Imagine a C++ `member' function -- the first (hidden) argument is a pointer to the class, the class contains a pointer to the virtual method table, and the VMT contains pointers to all the members. To call another member, you have to // let r1 point to the current instance load r1, r2 // get pointer to VMT (usually stored at offset 0) add $offset, r2, r3 // VMT slot address load r3, r4 // get member's address // argument passing omitted jmp r4, r5 // call member Both r2 (data pointer) and r4 (code pointer) are loaded from memory, and r3 (also a data pointer) is calculated from r2 and a constant (which probably has to be loadcons'd if it is too large). But there is no loadaddr[i] in that sequence, and the CPU has no way to tell that r4 points to a function that is going to be called real soon (that is, its code should be prefetched to avoid a stall). > > The same is true when an absolute code address is > > obtained via loadcons (which will probably be the common idiom > > when a function in another object file is called, unless jump > > tables are used -- which points us back to the `code pointer > > in register' problem, again). > if the data/code is not explicitely prefetched, the code will still work, > but with the "late fetch" penalty : the CPU will perform the "fetch" > operation automatically while stalling the decode stage. The point is that one cannot prefetch code. `load r4, r0' will prefetch the code into the D-cache, not the I-cache. > > To cut a long story short: I'd like to have an instruction > > that explicitly `tags' a register as a pointer, and probably > > initiates a prefetch cycle (for code or data, depending on > > the instruction's flags). It may or may not move data from > > one register to another (one idea I had was a `pointer move' > > instruction); if it does, it might be a good idea to let it > > participate in address calculation (i.e. let it be able to > > add two operands, like the `lea' instruction on Intel CPUs). > > this is what loadaddr is meant to do. But it only works with PC-relative addressing. While that's fine for conditional branches, loops and local function calls, inter-module calls cannot use it because the target address is resolved at link time (and what's worse: it may be too far away for a 16-bit displacement unless you limit the text segment size to 64 KB -- which is not a realistical value at all). > > - Let's clarify the suffix order, e.g. like this (? means the > > suffix is currently unused, and its name is unassigned): [...] > wow, what a work :-) You should see the complete flex source for the encoder; this is only a small snippet ;) [...] > > - The loadm/storem has a surprising operand order > > (start,src/dest,count), and it's not clear whether the > > register *numbers* or the register *contents* serve as the > > start/count values. I suggest the former, and I would also > > change the operands to (firstreg, lastreg, memaddr) which is > > much easier to grok for humans. > > some remarks : > - it is optional and conditioned by the presence of a SRB mechanism > - the 2nd register field is always the address. It must be pre-validated if possible. > - whether it is the contents or the value of the address does not change much > except that the value is know 2 cycles before or after. i'd prefer to use > the register number than its value, though, if possible. > though using the register contents might also help. No, the register number is perfect. After all, a programmer should know which registers he's going to use -- at least most of the time ;) > > Since there are some unused flags, another variant might be > > interesting: `storem r2, r1', where r2 is used as a mask > > (bit == 1 means "load/store register "), and r1 is the > > address of the source/destination memory area (which must be > > big enough to hold all registers, just like the CMB). > > this mask idea is interesting. It remembers me of the 6809 by the way :-) > however it means that 4x loadcons might be necessary (in arbitrary cases) > to backup the whole (non-contiguous) register set. You can still use loadm/storem if you have only two or three contiguous register blocks to save/restore. The mask is useful when a) the registers to save are too scattered or b) not known at compile time (emulators, debuggers, ...), and you don't want to loop over the whole register bank (that is, 63 times) and loadm/storem a single register each time. > > Maybe it would be wiser to put the memory address into the > > rightmost operand in *all* memory operations (load, store, > > cachemm, loadm and storem). Some instructions will always > > have the wrong operand order, though. > right. but i still prefer to leave the "pointer" field in the middle, > because it is the most usual case where it makes sense (at least for myself). Ok, then let it stay that way. After all, it's matter of taste, and it's MUCH easier to create machine code if the order of arguments in an assembler instruction corresponds to the order of slots in the instruction word. [...] > > The result is a flex-based instruction encoder > > that recognizes almost any instruction the F-CPU will have (with the > > exceptions mentioned above). I'll probably also build an assembler > > around it. (I finally found a real use for my libelf library! Yeah! ;) > > where's the source code ? :-) Locked in my safe? Just kidding ;) But I wanted to eliminate the ambiguities first before I release something that might be a reference implementation for others. > btw, please provide a "raw mode" so emulators don't need clomplex load functions... You mean, relocated and linked ready-to-execute output? I'd rather not bloat the assembler with it but create a separate tool (do you remember the good(?) old EXE2BIN? ;) A simulator/debugger can really benefit from an elaborated binary format like ELF. It will have access to symbol names, line numbers and symbolic debugging information (if the compiler/assembler supports it)... Hexdumps? Nein danke :) [...] > expansion/reduction is another problem but i think that the SHL unit can do this, > too. FP expansion is trivial, but FP reduction may trigger exceptions (or at least need rounding), and therefore has to be handled separately. > Another proposition : make a signed and unsigned version of the integer expansion > so we can extend the sign of the datum. This removes the "sign extension" flag > from the move instruction and it removes one funky operation from the Xbar. Ok, go ahead with that. It also has the nice side effect that I can now reclaim the -s suffix as a synonym for -m ;) Most `unsigned' widening operations (with zero extension) can be done with a single and[i] and/or loadcons[x] instruction (loadcons[x] needs an additional `move' if you want to keep the old value as well): andi.w $0xff, reg, reg // 8->16 sandi.w $0xff, reg, reg // 8->16 SIMD andi.q $0xff, reg, reg // 8->32 sandi.q $0xff, reg, reg // 8->32 SIMD andi $0xff, reg, reg // 8->64 loadcons.1 $0, reg // 16->32 loadconsx.1 $0, reg // 16->64 loadconsx.2 $0, reg // 32->64 There is only one operation that always needs 2 instructions: sshiftli.q $16, r1, r2 ; sshiftri.q $16, r2, r3 // 16->32 SIMD Note that SIMD widening doesn't work with `move' at all (move doesn't take a SIMD flag -- another reason to handle that operation in the SHL unit, or explicitly). `signed' widening can also be done with two shifts: shiftli.w $8, r1, r2 ; shiftrai.w $8, r2, r3 // 8->16 sshiftli.w $8, r1, r2 ; sshiftrai.w $8, r2, r3 // 8->16 SIMD shiftli.q $24, r1, r2 ; shiftrai.q $24, r2, r3 // 8->32 sshiftli.q $24, r1, r2 ; sshiftrai.q $24, r2, r3 // 8->32 SIMD shiftli $56, r1, r2 ; shiftrai $56, r2, r3 // 8->64 shiftli.q $16, r1, r2 ; shiftrai.q $16, r2, r3 // 16->32 sshiftli.q $16, r1, r2 ; sshiftrai.q $16, r2, r3 // 16->32 SIMD shiftli $48, r1, r2 ; shiftrai $48, r2, r3 // 16->64 shiftli $32, r1, r2 ; shiftrai $32, r2, r3 // 32->64 If there is enough room in the SHL unit, we can add a little logic that does it in one operation. I suggest we define the `widen' instruction as follows: [s]widenb[s][.b|.d|.q] r2, r1 // 8->xx [s]widenw[s][.b|.d|.q] r2, r1 // 16->xx [s]widenq[s][.b|.d|.q] r2, r1 // 32->xx [s]widen[s][.b|.d|.q] r2, r1 // 64->xx that is, [.b|.d|.q] refers to the new size, `s-' means SIMD (as usual), and `-s' activates sign extension. We need only a single opcode (the source size can be encoded in the flag bits -- since the instruction uses only two registers and no immediate operand, we have plenty of them). Whether e.g. `widenq.b' actually truncates 32-bit values to 8-bit, and how the result looks like when the value is not representable with the destination size, needs to be defined. The default (and probably the only option for FC0) should be `chop' -- discard the upper bits --, but signed/unsigned saturation (depending on the -s suffix) would be nice, too. FP conversions are a different beast. We should have at least these: // FP -> FP 32-bit FP -> 64-bit FP // trivial 64-bit FP -> 32-bit FP // non-trivial (exceptions & rounding) // mandatory FP -> INT 32-bit FP -> 32-bit INT // non-trivial (exceptions & rounding) 32-bit FP -> 64-bit INT // non-trivial (exceptions & rounding) 64-bit FP -> 32-bit INT // non-trivial (exceptions & rounding) 64-bit FP -> 64-bit INT // non-trivial (exceptions & rounding) // mandatory INT -> FP 64-bit INT -> 32-bit FP // non-trivial (rounding) 64-bit INT -> 64-bit FP // non-trivial (rounding) // optional INT -> FP 32-bit INT -> 32-bit FP // non-trivial (rounding) 32-bit INT -> 64-bit FP // trivial Note: the optional conversions can be replaced with an integer conversion to 64-bit and one of the mandatory INT -> FP conversions. Smaller integers must be converted to 32-bit or larger before FP'izing them; this decision was of course influenced by C's default integer promotion rules. The INT -> FP and FP -> INT conversions should come in to flavors: one for signed and one for unsigned integers. That results in 8 variants of `f2int', 4...8 variants of `int2f', plus `f2d' and `d2f' or whatever they're going to be called. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 16 21:18:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XZw6-0004L9-00 for ; Fri, 17 Aug 2001 05:04:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 Aug 2001 05:04:38 +0200 (CEST) Received: (qmail 9432 invoked by uid 0); 16 Aug 2001 22:42:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 16 Aug 2001 22:42:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA24852 for ; Thu, 16 Aug 2001 18:42:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 16 Aug 2001 22:41:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA24424 for f-cpu-list; Thu, 16 Aug 2001 18:41:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA24410 for ; Thu, 16 Aug 2001 18:41:30 -0400 Received: from tribble.stud.uni-hannover.de (root@a107.home.uni-hannover.de [130.75.232.107]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7GMf9b28862 for ; Thu, 16 Aug 2001 18:41:11 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01384; Thu, 16 Aug 2001 21:18:42 +0200 Message-ID: <20010816211842.05164@thrai.stud.uni-hannover.de> Date: Thu, 16 Aug 2001 21:18:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7AD06A.6C0A9589@ifrance.com> <01081613492700.00283@maveric> <3B7BE3F2.8F859E06@f-cpu.org> <3B7B6702.A012D816@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7B6702.A012D816@jetnet.ab.ca>; from Ben Franchuk on Thu, Aug 16, 2001 at 12:24:02AM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 16, 2001 at 12:24:02AM -0600, Ben Franchuk wrote: [...] > Anybody for 56 bit floating point, ints, pointers ? > I was thinking LISP and other list processing languages might want to > use the upper byte for internal flags and garbage collection > and the remaining 56 bits as data in a 64 bit word. Ben. If somebody wants to turn the F-CPU into a LISP machine, he should rather *add* bits (and send me a dozen working chips, for free ;). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 03:06:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XZw8-0004L9-00 for ; Fri, 17 Aug 2001 05:04:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 Aug 2001 05:04:40 +0200 (CEST) Received: (qmail 25780 invoked by uid 0); 17 Aug 2001 01:10:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 17 Aug 2001 01:10:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA29014 for ; Thu, 16 Aug 2001 21:10:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 01:06:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA28759 for f-cpu-list; Thu, 16 Aug 2001 21:06:33 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA28756 for ; Thu, 16 Aug 2001 21:06:32 -0400 Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H16Gb30536 for ; Thu, 16 Aug 2001 21:06:16 -0400 Received: from f-cpu.org (nas3-50.ras.club-internet.fr [195.36.203.50]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA01800 for ; Fri, 17 Aug 2001 03:06:24 +0200 (MET DST) Message-ID: <3B7C6DFA.B1E75224@f-cpu.org> Date: Fri, 17 Aug 2001 03:06:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! (with this flood of emails, i wasn't able to compile anything today, not even MR's preprocessors... so don't worry if i stay mute awhile :-D) nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > >Use semaphores that are mapped in the SRs ! > > > In all case, we need to write something in memory or to touch something > > > in the VM unit. > > why ? a semaphore is a semaphore, a flag if you want. > > whether it is implemented in memory or with a dedicated HW in > > a different addressign space, is "implementation dependent". > > In all case, you have one memory access + 1 or more port to the outside. maybe not. I am thinking about a separate and dedicated port in the chip, that will communicate to a central FPGA or ASIC that will perform the arbitration. a dozen of signal pins do the trick. > Plus, you could add many problem for multicpu system. So there isn't any > port dedicated to it, and shouldn't have ! Because it so tight to the > OS, that we could have many compatibility problem in the futur. if the SR interface is respected, it is transparent to the OS. > I think > you thought to an implementation of SGI not really usual processor. SGI Indigo and other similar machines have a central semaphore management that does not pollute the memory system. > Today's µp implement semaphore with atomic read_modify_write > instructions. so what ? > > > So it's just pushing the problem away ! > > and if possible where it doesn't disturb us :-P > > > > the L/S unit is optimised to allow high bandwidth through > > cache-line width packet transfers, accessing single bytes > > in scattered order is a good way to "kill" your memory subsystem > > and the speed of your synchronisation. > > You could add specific memory barrer (semaphore aren't so common!). there is already a "barrier" ("serialize"). the problem is that not only it stalls the pipeline, but it also perturbates the memory system's behaviour. It is used only in "critical" sections that deal with DMA or I/O for example ("low speed" things). OTOH you would want your semaphore to be effective in as few cycles as possible. when doing fine grained multitasking and multiprocessing, the semaphore latency can become the killer, especially in real-time. > > > More generaly, i find the text very agressive against Alpha.(the 2 first > > > sentences of the text, for example). We should never forget that alpha > > > work since 10 years and fcpu is in it's very beginning. So this kink of > > > speech could make laught a futur investor in the fcpu, never forget > > > that. > > > > i think that you know that i am not "agressive" and that i respect the > > ALPHA. I have two expensive books about it and unfortunately no > > Alpha server at home. > > > > We can still discuss whether Alpha is dead or not. CPQ will keep > > Alpha alive artificially as long as IA64 is not a serious competitor. > > that is enough for me : it's just marketing and financial manipulation, > > the ALPHA engineers have a very reduced freedom of decision now, > > because they know that it will be dropped after the 364. > > > > So i could say : Alpha is dead as much as F-CPU is alive. > > it's time to learn alpha's lessons, i think. > > > > the problem is the tone not the content. what would you write instead ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 04:24:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XZw9-0004L9-00 for ; Fri, 17 Aug 2001 05:04:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 Aug 2001 05:04:41 +0200 (CEST) Received: (qmail 12837 invoked by uid 0); 17 Aug 2001 02:26:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 17 Aug 2001 02:26:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id WAA30295 for ; Thu, 16 Aug 2001 22:26:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 02:24:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id WAA29814 for f-cpu-list; Thu, 16 Aug 2001 22:24:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id WAA29796 for ; Thu, 16 Aug 2001 22:24:56 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H2Oeb32161 for ; Thu, 16 Aug 2001 22:24:40 -0400 Received: from f-cpu.org (nas3-58.ras.club-internet.fr [195.36.203.58]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA28166 for ; Fri, 17 Aug 2001 04:24:53 +0200 (MET DST) Message-ID: <3B7C8066.C2D9400B@f-cpu.org> Date: Fri, 17 Aug 2001 04:24:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7C05F4.35FA607C@ifrance.com> <20010816202619.64025@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Thu, Aug 16, 2001 at 01:42:12PM -0400, nicO wrote: > [...] > > For your 16 bit fp processing, could not be better to use log number ? > > For audio processing it could be enough (no DC stuff). > [...] > 16-bit LNS would be fine as well. maybe for gaming or stuff like that. but when doing "real" sound processing, i guess that the rounding noise can be limiting... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 04:24:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15XZw9-0004L9-01 for ; Fri, 17 Aug 2001 05:04:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 Aug 2001 05:04:41 +0200 (CEST) Received: (qmail 12180 invoked by uid 0); 17 Aug 2001 02:26:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 17 Aug 2001 02:26:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id WAA30308 for ; Thu, 16 Aug 2001 22:26:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 02:24:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id WAA29780 for f-cpu-list; Thu, 16 Aug 2001 22:24:55 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id WAA29777 for ; Thu, 16 Aug 2001 22:24:54 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H2Obb32156 for ; Thu, 16 Aug 2001 22:24:37 -0400 Received: from f-cpu.org (nas3-58.ras.club-internet.fr [195.36.203.58]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id EAA28156 for ; Fri, 17 Aug 2001 04:24:47 +0200 (MET DST) Message-ID: <3B7C8059.957E20D3@f-cpu.org> Date: Fri, 17 Aug 2001 04:24:25 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7BF3A9.5B0E4DD4@f-cpu.org> <20010817003553.36482@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N what a pity ! there are so many interesting and useful things here, with a lot of insight, and the manual is still a beast to update. maybe we should use the system of RFCs, so we don't loose the idea if we can't update the man. This mail would contain several RFCs at least. on top of that, i didn't do anything at all today, except answering mail. that's impossible... Michael Riepe wrote: > On Thu, Aug 16, 2001 at 06:24:09PM +0200, Yann Guidon wrote: > [...] > > > I mean: I think it's unreasonable to build *variable-size* FP units. > > > There are too many special cases to consider -- rounding, exceptions, > > > infinities and NANs, ... (ok, go blame IEEE for it ;) > > come on, pipelined/vector FP and SIMD FP are not new. > > On top of that i have added a new condition for jumps : NaN. > Didn't we already decide that months ago? i rediscovered it recently :-) > [...] > > > - The manual doesn't state whether `modi' is a signed operation > > > I suggest it should be signed (like `divi') > > i think that it goes along with the divide unit that you are doing. > The IDU will be able to perform both signed and unsigned > division/remainder. The signed division will be symmetric (FORTH people > probably know this as SM/REM). I still have to elaborate whether > asymmetric `floored' division and modulus (FM/MOD) is possible. good luck ! > > > - We need a level-1 floating-point compare instruction; > > > `cmpl'/`cmple' may work with LNS (if there are no NANs), > > > but not with FP. > > IEEE FP defines FP comparison with Integer operations. > Yes, but unfortunately in sign-magnitude (not 2's complement) form. ??? i'm surprised. but i'm not a FP expert neither. > > the format has be designed specifically for this purpose > > (however i don't remember what happens with NaNs etc) > IIRC, if at least one of the operands is a NAN, the result of all > comparisions (except `!=') is always false. it sounds logical. > Mapped to (2's complement signed) integer, the order is as follows > (assuming IEEE `single' format): > > s eeeee fff meaning > ===================== > 0 ff >0 NAN > 0 ff =0 +INF > 0 01-fe any positive normal > 0 00 >0 positive subnormal > 0 00 =0 +0 > 1 ff >0 NAN > 1 ff =0 -INF > 1 01-fe any negative normal > 1 00 >0 negative subnormal > 1 00 =0 -0 > > That's obviously not correct. where ? negative normal/subnormal ? +0/-0 ? we'll have to ask some experts... > > > - The arguments of `store[f]' are reversed (dest, src). It's > > > ok that way (because it mirrors the `load' instruction) but > > > there should be a BIG FAT WARNING in the manual. > > > > there will certainly be a change in the L/S instruction format ! > > the pointer that gets updated must be written somewhere and the > > current fields don't match the expected behaviour. ie : > > load r1, r2, r3 does : load [r2] into r3, and add r1 to r2 > > this means that the r2 field must be written to. IT IS NOT POSSIBLE yet. > > so it will become : "load [r2] into r3, and r1 + r2 => r3^1" > I like the current form better. This one is too crazy. probably but r2 can't be written to ! i think... i'll have to re-check the instruction decoder/issue. there may be something that i missed along the way. i was worried about the comparators that detect the unavailable registers and i feared that a 5th would be necessary. of course it is not the case. > [...] > > > - We need to clarify the syntax of the `condition' suffixes for > > > `move' and `jmpa'. I suggest > > > > > > 000 -z (zero) > > > 001 (unassigned) > > > 010 -m (msb == 1) > > > 011 -l (lsb == 0) > > > 100 -nz (not zero) > > > 101 (unassigned) > > > 110 -nm (msb == 0) > > > 111 -nl (lsb == 0) > > > > in the assembler that i have written, it's written differently > > and more verbosely (less confusing when you don't know the meanings). > Yep, I saw the .lsb/.msb/.and/.or suffixes. the .and and .or suffixes are for ROP2. > I didn't find .zero or a negation suffix, though. it's a higher-level trick :-) the syntax defines the usual émove src, dest" and "cmove cond.y == x, src, dest" for conditional moves. i have chosen to explicitely use "cmove" because i feared a shift-reduce problem. "y" can be nothing, ".lsb" and ".msb" and "x" can be 0 or 1. There is an inconsistency for "cmove r==1" (i'll fix that with inverting everything :*D) but otherwise it is written "r.lsb==0", "r==0", "r.msb==0" and idem for 1. the x value gives the negation directly ;-) and the absence of specifier means the whole register, hence zero or not. i know, it's lame, but it works :-) and it's less confusing than -nm for example. > I suggest we allow both forms -- the > long one for humans, the short one for compilers (or people like me, > who don't like writing a novel to flip a single bit ;). why not. > Summarized: > 000 -z .zero, .z, .null, ... > 001 -x .nan, .not.number, ... > 010 -m .msb, .msb1, ... > 011 -l .lsb, .lsb1, ... > 100 -nz .notzero, .not.zero, .nz, ... > 101 -nx .notnan, .not.nan, .number, ... > 110 -nm .notmsb, .not.msb, .msb0, ... > 111 -nl .notlsb, .not.lsb, .lsb0, ... > I choose the short names, you the long names ;) allright. gimme some time however :-) > In case you wonder, the `x' stands for `eXtra' or `eXception'. thanks for this kind explanation :*) > I could > also use `n' for `NAN', but that makes the instruction encoder a little > more complex and is probably misleading anyway. But I'll think it over. > [...] 'i' for 'i'nvalid ? > > > - Can we please drop the `a' from `jmpa'? > > probably. i don't remember where it comes from, probably from Mathias. > It was meant to indicate an (A)bsolute jump. Since that's the only > one the F-CPU knows, the suffix is redundant (and it looks too much > like `jump always'). ok let's go. > > > - When calling functions through pointers, it would be nice to > > > be able to tell the F-CPU *a priori* that a register contains a > > > code address. While this can be done with an explicit prefetch > > > (load to r0) for data pointers, there is no way to specify that > > > a register contains a code address that the CPU will have to > > > visit soon. > > what about loadaddr(i) ? > Not useful. that's sad. Maybe... we can use one or two bits from the add/sub instructions so they validate and prefetch the resulting pointer ? > Imagine a C++ `member' function -- the first (hidden) > argument is a pointer to the class, the class contains a pointer to > the virtual method table, and the VMT contains pointers to all the > members. i can understand english, french and german, i know a few words in several european langages such as italian, spanish, portugese, tchech, russian, polish, latvian... but i still believe that C++ comes from Mars. > To call another member, you have to > > // let r1 point to the current instance > load r1, r2 // get pointer to VMT (usually stored at offset 0) > add $offset, r2, r3 // VMT slot address > load r3, r4 // get member's address > // argument passing omitted > jmp r4, r5 // call member what an ugly code :-( is all this necessary ??? There is one "programming trick" in FC0 : you use a "software barrel of 8 registers" for data and another "barrel" for instructions. when you want to access data, use post-incremented form as possible, with an increment such as it points to the data that you will access in 8 L/S instructions. the code above is extremely short-sighted and utterly underefficient. > Both r2 (data pointer) and r4 (code pointer) are loaded from memory, > and r3 (also a data pointer) is calculated from r2 and a constant > (which probably has to be loadcons'd if it is too large). But there > is no loadaddr[i] in that sequence, and the CPU has no way to tell > that r4 points to a function that is going to be called real soon > (that is, its code should be prefetched to avoid a stall). maybe we need a sort of loadaddr(i) without PC ? i have the feeling that i miss something here... > > > The same is true when an absolute code address is > > > obtained via loadcons (which will probably be the common idiom > > > when a function in another object file is called, unless jump > > > tables are used -- which points us back to the `code pointer > > > in register' problem, again). > > if the data/code is not explicitely prefetched, the code will still work, > > but with the "late fetch" penalty : the CPU will perform the "fetch" > > operation automatically while stalling the decode stage. > The point is that one cannot prefetch code. `load r4, r0' will prefetch > the code into the D-cache, not the I-cache. something seems broken here. > > > To cut a long story short: I'd like to have an instruction > > > that explicitly `tags' a register as a pointer, and probably > > > initiates a prefetch cycle (for code or data, depending on > > > the instruction's flags). It may or may not move data from > > > one register to another (one idea I had was a `pointer move' > > > instruction); if it does, it might be a good idea to let it > > > participate in address calculation (i.e. let it be able to > > > add two operands, like the `lea' instruction on Intel CPUs). > > this is what loadaddr is meant to do. > > But it only works with PC-relative addressing. While that's fine for > conditional branches, loops and local function calls, inter-module calls > cannot use it because the target address is resolved at link time (and > what's worse: it may be too far away for a 16-bit displacement unless > you limit the text segment size to 64 KB -- which is not a realistical > value at all). what's your conclusion, doctor ? > > > - Let's clarify the suffix order, e.g. like this (? means the > > > suffix is currently unused, and its name is unassigned): > [...] > > wow, what a work :-) > > You should see the complete flex source for the encoder; this is only > a small snippet ;) i WANT to see it ;-) > [...] > > > - The loadm/storem has a surprising operand order > > > (start,src/dest,count), and it's not clear whether the > > > register *numbers* or the register *contents* serve as the > > > start/count values. I suggest the former, and I would also > > > change the operands to (firstreg, lastreg, memaddr) which is > > > much easier to grok for humans. > > > > some remarks : > > - it is optional and conditioned by the presence of a SRB mechanism > > - the 2nd register field is always the address. It must be pre-validated if possible. > > - whether it is the contents or the value of the address does not change much > > except that the value is know 2 cycles before or after. i'd prefer to use > > the register number than its value, though, if possible. > > though using the register contents might also help. > > No, the register number is perfect. After all, a programmer should know > which registers he's going to use -- at least most of the time ;) sure, that's why i did not care before. > > > Since there are some unused flags, another variant might be > > > interesting: `storem r2, r1', where r2 is used as a mask > > > (bit == 1 means "load/store register "), and r1 is the > > > address of the source/destination memory area (which must be > > > big enough to hold all registers, just like the CMB). > > > > this mask idea is interesting. It remembers me of the 6809 by the way :-) > > however it means that 4x loadcons might be necessary (in arbitrary cases) > > to backup the whole (non-contiguous) register set. > > You can still use loadm/storem if you have only two or three contiguous > register blocks to save/restore. The mask is useful when a) the registers > to save are too scattered or b) not known at compile time (emulators, > debuggers, ...), and you don't want to loop over the whole register bank > (that is, 63 times) and loadm/storem a single register each time. in such a 'scattered' case, why not use a loop with a get/put to the register set ? > > > Maybe it would be wiser to put the memory address into the > > > rightmost operand in *all* memory operations (load, store, > > > cachemm, loadm and storem). Some instructions will always > > > have the wrong operand order, though. > > right. but i still prefer to leave the "pointer" field in the middle, > > because it is the most usual case where it makes sense (at least for myself). > Ok, then let it stay that way. After all, it's matter of taste, and > it's MUCH easier to create machine code if the order of arguments > in an assembler instruction corresponds to the order of slots in the > instruction word. right. But using BISON, one can easily swap operand orders. replace "$2" with "$4" and vice versa. > [...] > > > The result is a flex-based instruction encoder > > > that recognizes almost any instruction the F-CPU will have (with the > > > exceptions mentioned above). I'll probably also build an assembler > > > around it. (I finally found a real use for my libelf library! Yeah! ;) > > > > where's the source code ? :-) > > Locked in my safe? > > Just kidding ;) Pfiew ! i prefer that ;-) > But I wanted to eliminate the ambiguities first > before I release something that might be a reference implementation > for others. yup. > > btw, please provide a "raw mode" so emulators don't need clomplex load functions... > > You mean, relocated and linked ready-to-execute output? I'd rather not > bloat the assembler with it but create a separate tool (do you remember > the good(?) old EXE2BIN? ;) i think i did not use it much. i preferred to write my own EXE from scratch. i have contributed NASM with an EXE header generator :-) this way, no need of any external tool. > A simulator/debugger can really benefit from an elaborated binary format > like ELF. It will have access to symbol names, line numbers and symbolic > debugging information (if the compiler/assembler supports it)... > > Hexdumps? Nein danke :) "elaborated" sometimes becomes "utterly complex"... > [...] > > expansion/reduction is another problem but i think that the SHL unit can do this, > > too. > > FP expansion is trivial, but FP reduction may trigger exceptions (or at > least need rounding), and therefore has to be handled separately. couldn't reduction be handled in a FP unit such as fadd ? > > Another proposition : make a signed and unsigned version of the integer expansion > > so we can extend the sign of the datum. This removes the "sign extension" flag > > from the move instruction and it removes one funky operation from the Xbar. > Ok, go ahead with that. it's done in my simulator. > It also has the nice side effect that I can > now reclaim the -s suffix as a synonym for -m ;) what is "-m" ? > Most `unsigned' widening operations (with zero extension) can be done > with a single and[i] and/or loadcons[x] instruction (loadcons[x] needs > an additional `move' if you want to keep the old value as well): > > andi.w $0xff, reg, reg // 8->16 > sandi.w $0xff, reg, reg // 8->16 SIMD > andi.q $0xff, reg, reg // 8->32 > sandi.q $0xff, reg, reg // 8->32 SIMD > andi $0xff, reg, reg // 8->64 > loadcons.1 $0, reg // 16->32 > loadconsx.1 $0, reg // 16->64 > loadconsx.2 $0, reg // 32->64 > > There is only one operation that always needs 2 instructions: > > sshiftli.q $16, r1, r2 ; sshiftri.q $16, r2, r3 // 16->32 SIMD nice snippet collection ! they have certainly a reserved place in the manual. > Note that SIMD widening doesn't work with `move' at all (move doesn't > take a SIMD flag -- another reason to handle that operation in the SHL > unit, or explicitly). right. but the main reason is that i was worried about adding "operation" functionalities in the Xbar. > `signed' widening can also be done with two shifts: > > shiftli.w $8, r1, r2 ; shiftrai.w $8, r2, r3 // 8->16 > sshiftli.w $8, r1, r2 ; sshiftrai.w $8, r2, r3 // 8->16 SIMD > shiftli.q $24, r1, r2 ; shiftrai.q $24, r2, r3 // 8->32 > sshiftli.q $24, r1, r2 ; sshiftrai.q $24, r2, r3 // 8->32 SIMD > shiftli $56, r1, r2 ; shiftrai $56, r2, r3 // 8->64 > shiftli.q $16, r1, r2 ; shiftrai.q $16, r2, r3 // 16->32 > sshiftli.q $16, r1, r2 ; sshiftrai.q $16, r2, r3 // 16->32 SIMD > shiftli $48, r1, r2 ; shiftrai $48, r2, r3 // 16->64 > shiftli $32, r1, r2 ; shiftrai $32, r2, r3 // 32->64 2 shifts ? i would prefer 1 simple instruction instead. > If there is enough room in the SHL unit, we can add a little logic that > does it in one operation. I suggest we define the `widen' instruction > as follows: the 6809 defined a funny opcode : "sex" for "sign extension" :*) now i understan much more about the meaning of Life :-D > [s]widenb[s][.b|.d|.q] r2, r1 // 8->xx > [s]widenw[s][.b|.d|.q] r2, r1 // 16->xx > [s]widenq[s][.b|.d|.q] r2, r1 // 32->xx > [s]widen[s][.b|.d|.q] r2, r1 // 64->xx > > that is, [.b|.d|.q] refers to the new size, `s-' means SIMD (as usual), > and `-s' activates sign extension. We need only a single opcode (the > source size can be encoded in the flag bits -- since the instruction > uses only two registers and no immediate operand, we have plenty of them). exactly. > Whether e.g. `widenq.b' actually truncates 32-bit values to 8-bit, and > how the result looks like when the value is not representable with the > destination size, needs to be defined. The default (and probably the > only option for FC0) should be `chop' -- discard the upper bits --, > but signed/unsigned saturation (depending on the -s suffix) would be > nice, too. i'm too tired tonight ... i can't concentrate on this. > FP conversions are a different beast. We should have at least these: > > // FP -> FP > 32-bit FP -> 64-bit FP // trivial > 64-bit FP -> 32-bit FP // non-trivial (exceptions & rounding) > > // mandatory FP -> INT > 32-bit FP -> 32-bit INT // non-trivial (exceptions & rounding) > 32-bit FP -> 64-bit INT // non-trivial (exceptions & rounding) > 64-bit FP -> 32-bit INT // non-trivial (exceptions & rounding) > 64-bit FP -> 64-bit INT // non-trivial (exceptions & rounding) > > // mandatory INT -> FP > 64-bit INT -> 32-bit FP // non-trivial (rounding) > 64-bit INT -> 64-bit FP // non-trivial (rounding) > > // optional INT -> FP > 32-bit INT -> 32-bit FP // non-trivial (rounding) > 32-bit INT -> 64-bit FP // trivial > > Note: the optional conversions can be replaced with an integer conversion > to 64-bit and one of the mandatory INT -> FP conversions. Smaller integers > must be converted to 32-bit or larger before FP'izing them; this decision > was of course influenced by C's default integer promotion rules. i didn't know about this detail. > The INT -> FP and FP -> INT conversions should come in to flavors: one > for signed and one for unsigned integers. That results in 8 variants of > `f2int', 4...8 variants of `int2f', plus `f2d' and `d2f' or whatever > they're going to be called. this is certainly going to increase the size of the manual... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 08:29:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3b-0000SB-00 for ; Sat, 18 Aug 2001 02:33:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:43 +0200 (CEST) Received: (qmail 11146 invoked by uid 0); 17 Aug 2001 06:03:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 17 Aug 2001 06:03:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA00779 for ; Fri, 17 Aug 2001 02:03:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 06:01:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA00492 for f-cpu-list; Fri, 17 Aug 2001 02:01:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA00489 for ; Fri, 17 Aug 2001 02:01:47 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H61Ub00874 for ; Fri, 17 Aug 2001 02:01:30 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15Xd8I-0003OL-00 for f-cpu@seul.org; Fri, 17 Aug 2001 08:29:26 +0200 Date: Fri, 17 Aug 2001 08:29:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? In-Reply-To: <20010816204743.60168@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 16 Aug 2001, Michael Riepe wrote: > On Wed, Aug 15, 2001 at 11:15:33PM -0600, Ben Franchuk wrote: > [...] > > Ok what about instruction decoding of the opcode in a configuration > > register with each setup modifying the fields used? > > version 1 - endian bit active high > > version 2 - endian bit active low > > ( Special register xor endian flag ). > > No, no, three times NO! > > Can you imagine what happens when a piece of code runs with the wrong > configuration settings? *kaboom* FUBAR. > > Don't you remember the `D' flag in Intel's x86? > > Let's not duplicate this insanity. A configuration register should > NEVER affect the semantics of a program. The configurable translation > (size bits -> register size) is already too much, from a programmer's > point of view. I agree to your opinion! Basically, if one uses a toggle type register it is always hard to detect the current setting, i.e. this requires extra code... and thus slows down the program -> a penalty you don't want at all. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 08:57:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3b-0000SB-01 for ; Sat, 18 Aug 2001 02:33:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:43 +0200 (CEST) Received: (qmail 2207 invoked by uid 0); 17 Aug 2001 06:59:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 17 Aug 2001 06:59:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA02692 for ; Fri, 17 Aug 2001 02:59:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 06:57:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA02441 for f-cpu-list; Fri, 17 Aug 2001 02:57:53 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA02438 for ; Fri, 17 Aug 2001 02:57:52 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H6vab01321 for ; Fri, 17 Aug 2001 02:57:36 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id CAA06748 for ; Fri, 17 Aug 2001 02:51:59 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id CAA29260 for ; Fri, 17 Aug 2001 02:57:46 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 07:57:45 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F020@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 07:57:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id CAA02439 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > On Thu, Aug 16, 2001 at 01:49:27PM +0800, Glenn Alexander wrote: > > Hi. This is my first post to this list. My background is as > > a hardware technician, not a chip designer so bear with me. > > > > On Thursday 16 August 2001 03:41, you wrote: > > > Michael Riepe a écrit : > > > > > > In sparc, there is no 80 bits float but 128 bits (2 > > > registers used in the same time). We don't need 1 cycle > > > multiplication so it could be done for the fcpu. > > > > I am thinking that taking the two-register approach might be > > over-complicating matters. Since F-CPU is intended to later > > be scaled above 64 bits, if someone wanted 128-bit floats > > in the future they would impliment a 128-bit F-CPU. > > Especially for the FC-0 and probably for the FC-1, KISS > > (Keep It Simple for us Stupid people). > > 128-bit `quadruple precision' (like SPARC) is IMHO the way to go, but > not in the FC0. For now, let's stick to 32-bit and 64-bit > (with 80-bit `double extended' used inside the FP unit, > to maintain IEEE compliance). > Could someone explain to me why 128-bit FP is desireable? I am struggling here to think of an application which needs 30 decimal places of precision (or whatever it is). In fact I'd go as far as to suggest that in most cases 32-bit FP would be sufficient. Chip designers tend to dream of having a 128-bit or 256-bit processor etc., but without reference to the real world which doesn't need (actually can't make good use of) such high precision FP. Expanding the word size won't deliver a performance enhancement. My belief is the only way such large word sizes make any kind of sense is in the contect of SIMD, where the large word size is effectively a parrelisation. ------------------ Hans Summers http://www.hanssummers.com/computers/fcpu/scheduler.htm ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 09:32:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3c-0000SB-00 for ; Sat, 18 Aug 2001 02:33:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:44 +0200 (CEST) Received: (qmail 30053 invoked by uid 0); 17 Aug 2001 07:06:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 17 Aug 2001 07:06:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA03063 for ; Fri, 17 Aug 2001 03:06:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 07:04:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA02796 for f-cpu-list; Fri, 17 Aug 2001 03:04:21 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA02793 for ; Fri, 17 Aug 2001 03:04:20 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H743b01390 for ; Fri, 17 Aug 2001 03:04:03 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15Xe6q-0003SM-00 for f-cpu@seul.org; Fri, 17 Aug 2001 09:32:00 +0200 Date: Fri, 17 Aug 2001 09:32:00 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] dc and linux In-Reply-To: <20010814184833.00136@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 14 Aug 2001, Michael Riepe wrote: > > On Tue, Aug 14, 2001 at 03:09:01PM -0400, nicO wrote: > > I never see a tools that could use more than one cpu ! So forget SMP, > > Yep, it's a pity. > > > you will lose just a little more money. I just see in my favorite > > asiatic shop that a Mother board+Athlon 1.4GHz+2Go will cost less than > > 5000 F ( <800 Euros). Pentuim 4 is good only for specific written code > > (SSE2) so athlon could be much faster than Pentuim 4. > > A decent board (with AMD chipset) with 1,4 GHz AMD and 2GB registered > PC2100 DDR-SDRAM (4x512MB modules) costs 2000 EUR in Germany, and I > also need an ATX case, power supply, hard disk(s) and so on, so I'll > probably get away with 2500 EUR for a complete system. Sorry, but I > can't afford that. Hi, we are currently setting up a configuration like this for cluster applications. Since the amount of machines is a little bit higher than usual it may get cheaper in price. Since they are cluster node configurations don't expect good graphics or DVD or other creapy game stuff. It comes with Linux & Ethernet card. German type 230V AC. Desktop. If someone is interested please drop me an email directly for further details. PLEASE DO NOT STATE ANY INTEREST OVER THE F-CPU LIST! I want to apologize for this mail in advance. I know that the f-cpu mailing list is not intended for this purpose. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 09:37:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3d-0000SB-00 for ; Sat, 18 Aug 2001 02:33:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:45 +0200 (CEST) Received: (qmail 4107 invoked by uid 0); 17 Aug 2001 07:11:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 17 Aug 2001 07:11:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA03379 for ; Fri, 17 Aug 2001 03:11:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 07:09:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA03092 for f-cpu-list; Fri, 17 Aug 2001 03:09:55 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA03089 for ; Fri, 17 Aug 2001 03:09:54 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7H79ab01474 for ; Fri, 17 Aug 2001 03:09:37 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XeCE-0003T4-00 for f-cpu@seul.org; Fri, 17 Aug 2001 09:37:34 +0200 Date: Fri, 17 Aug 2001 09:37:34 +0200 (MEST) From: Juergen Goeritz To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F020@po1-exch.lon.tudor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Hans Summers wrote: > Could someone explain to me why 128-bit FP is desireable? I am struggling > here to think of an application which needs 30 decimal places of precision > (or whatever it is). In fact I'd go as far as to suggest that in most cases > 32-bit FP would be sufficient. Chip designers tend to dream of having a > 128-bit or 256-bit processor etc., but without reference to the real world > which doesn't need (actually can't make good use of) such high precision FP. > Expanding the word size won't deliver a performance enhancement. My belief > is the only way such large word sizes make any kind of sense is in the > contect of SIMD, where the large word size is effectively a parrelisation. Ah, I have the same opinion about this theme. You don't really need a higher precision than 64 bit. Maybe that will change for galaxy navigation in the future but until now 32 bit are good (and fast) for most cases. I would rather implement some 32 bit pipelined floating point instructions than go for a dedicated fpu anyway... ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Fri Aug 17 12:07:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3f-0000SB-00 for ; Sat, 18 Aug 2001 02:33:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:47 +0200 (CEST) Received: (qmail 20109 invoked by uid 0); 17 Aug 2001 10:07:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 10:07:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA05798 for ; Fri, 17 Aug 2001 06:07:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 10:07:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA05534 for f-cpu-list; Fri, 17 Aug 2001 06:07:00 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA05528 for ; Fri, 17 Aug 2001 06:06:55 -0400 Received: from online.ln.cn ([202.96.74.83]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f7HA6ab02853 for ; Fri, 17 Aug 2001 06:06:37 -0400 Received: from maveric([61.176.53.191]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm233b7d06f8; Fri, 17 Aug 2001 18:02:58 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? (way off topic - by 63 light years actually - sorry) Date: Fri, 17 Aug 2001 18:07:26 +0800 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01081718072600.01686@maveric> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id GAA05529 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > You don't really > need a higher precision than 64 bit. Maybe that will change for > galaxy navigation in the future > > JG > Well, in Universe A (where I base a good deal of my SF writing) the only thing powerful enough for that is an organic brain which has to be wired into the nav comp - physically wired in for a human brain! (Unless you are a major government with huge ships - then you can get away with mega-expensive hardware). More than a few kilometres off arc per lightyear (jock talk) will scramble the atoms of the moving object. As pilot Jodie said in book 1 (almost finished): "What comes out the other end is a lump of metal with some organic mush distributed through it." In book two (one third finished), Steve has to experience a jump on autopilot and we get to experience the effect in action. I agree: untill we start launching space-probes, 64 bit FP seems fine. But the option for more will be there when we do build the F-rocket (FR-1). -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy. Use GNU! [ http://www.gnu.org ] -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 13:05:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3f-0000SB-01 for ; Sat, 18 Aug 2001 02:33:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:47 +0200 (CEST) Received: (qmail 21148 invoked by uid 0); 17 Aug 2001 10:38:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 17 Aug 2001 10:38:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA07141 for ; Fri, 17 Aug 2001 06:38:24 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 10:38:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA06890 for f-cpu-list; Fri, 17 Aug 2001 06:38:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA06887 for ; Fri, 17 Aug 2001 06:38:06 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HAbnb03045 for ; Fri, 17 Aug 2001 06:37:49 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XhRo-0003bu-00 for f-cpu@seul.org; Fri, 17 Aug 2001 13:05:52 +0200 Date: Fri, 17 Aug 2001 13:05:52 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic In-Reply-To: <01081718072600.01686@maveric> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Glenn Alexander wrote: > > You don't really > > need a higher precision than 64 bit. Maybe that will change for > > galaxy navigation in the future > > > Well, in Universe A (where I base a good deal of my SF writing) the only > thing powerful enough for that is an organic brain which has to be wired into > the nav comp - physically wired in for a human brain! (Unless you are a major > government with huge ships - then you can get away with mega-expensive > hardware). More than a few kilometres off arc per lightyear (jock talk) will > scramble the atoms of the moving object. As pilot Jodie said in book 1 > (almost finished): "What comes out the other end is a lump of metal with some > organic mush distributed through it." In book two (one third finished), Steve > has to experience a jump on autopilot and we get to experience the effect in > action. > > I agree: untill we start launching space-probes, 64 bit FP seems fine. But > the option for more will be there when we do build the F-rocket (FR-1). Error is human - maybe we live in an evolution based simulation for optimization? Who knows how our senses are really working? :-) Hmh, don't think I want to live in this universe A instead. But the thought of a far distant space ship is enticing... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From emorgens@prs-gmbh.de Fri Aug 17 12:54:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3g-0000SB-00 for ; Sat, 18 Aug 2001 02:33:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:48 +0200 (CEST) Received: (qmail 11081 invoked by uid 0); 17 Aug 2001 10:57:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 10:57:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA07638 for ; Fri, 17 Aug 2001 06:57:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 10:56:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA07393 for f-cpu-list; Fri, 17 Aug 2001 06:56:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA07390 for ; Fri, 17 Aug 2001 06:56:56 -0400 Received: from prs-02.prs ([212.126.220.227]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HAudb03141 for ; Fri, 17 Aug 2001 06:56:40 -0400 Subject: RE: [f-cpu] Re: Floating-Point? To: f-cpu@seul.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ekkehard Morgenstern" Date: Fri, 17 Aug 2001 12:54:01 +0200 X-MIMETrack: Serialize by Router on PRS_02/PRS GmbH(Release 5.0.8 |June 18, 2001) at 17.08.2001 13:00:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Ah, I have the same opinion about this theme. You don't really > need a higher precision than 64 bit. Maybe that will change for > galaxy navigation in the future but until now 32 bit are good > (and fast) for most cases. Actually, floating-point is too imprecise for ANY precision calculation. There are lots of numbers that can't be encoded into floating-point values. The bits in the mantissa are encoded as follows, for example: - bit 0: 1/2: 0.5 - bit 1: 1/4: 0.25 - bit 2: 1/8: 0.125 - bit 3: 1/16: 0.0625 and so on. By setting the bits, you're adding up the fractions. So, for example with financial computing, floating-point is a big no-no, otherwise you end up with respresentation and rounding errors. Any precision computing does not use floating-point. BCD string arithmetic (as known from COBOL and FORTRAN) is most commonly used for these tasks. So, it doesn't really matter how precise the FP is, but the finer the better, of course. It would extend the number of applications for the CPU, since sometimes it's desirable to sacrifice the precision for the sake of speed. On mainframes, there are AFAIK some applications that use custom code to do as much arithmetic in integer or FP as possible, and that use fixed-point or BCD otherwise. 32, 64 and 80 bit floating-point are standard nowadays, so these should be supported to avoid software emulation (preferrably IEEE standard compliant). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 13:13:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3g-0000SB-01 for ; Sat, 18 Aug 2001 02:33:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:48 +0200 (CEST) Received: (qmail 25818 invoked by uid 0); 17 Aug 2001 11:14:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 17 Aug 2001 11:14:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA08051 for ; Fri, 17 Aug 2001 07:14:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 11:14:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA07805 for f-cpu-list; Fri, 17 Aug 2001 07:14:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA07802 for ; Fri, 17 Aug 2001 07:14:06 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HBDob03301 for ; Fri, 17 Aug 2001 07:13:50 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id HAA14871 for ; Fri, 17 Aug 2001 07:08:13 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id HAA05630 for ; Fri, 17 Aug 2001 07:14:00 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 12:14:00 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 12:13:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Ah, I have the same opinion about this theme. You don't really > > need a higher precision than 64 bit. Maybe that will change for > > galaxy navigation in the future but until now 32 bit are good > > (and fast) for most cases. > > Actually, floating-point is too imprecise for ANY precision > calculation. There are lots of numbers that can't be encoded > into floating-point values. > > The bits in the mantissa are encoded as follows, for example: > - bit 0: 1/2: 0.5 > - bit 1: 1/4: 0.25 > - bit 2: 1/8: 0.125 > - bit 3: 1/16: 0.0625 > > and so on. By setting the bits, you're adding up the fractions. > > So, for example with financial computing, floating-point is a > big no-no, otherwise you end up with respresentation and rounding > errors. I've spent the last 7 years writing financial applications, and have NEVER seen or heard of BCD arithmetic being used. I always use 64-bit representation mostly because it is most standard. Yes, you will get rounding errors but you need a heck of a lot of calculations for the rounding errors in the 16'th decimal place to add up to anything of any significance. Hans ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 13:16:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3h-0000SB-00 for ; Sat, 18 Aug 2001 02:33:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:49 +0200 (CEST) Received: (qmail 31703 invoked by uid 0); 17 Aug 2001 11:17:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 17 Aug 2001 11:17:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA08353 for ; Fri, 17 Aug 2001 07:17:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 11:16:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA08105 for f-cpu-list; Fri, 17 Aug 2001 07:16:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA08102 for ; Fri, 17 Aug 2001 07:16:56 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HBGeb03339 for ; Fri, 17 Aug 2001 07:16:40 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id HAA15013 for ; Fri, 17 Aug 2001 07:11:03 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id HAA05735 for ; Fri, 17 Aug 2001 07:16:50 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 12:16:50 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F02A@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 12:16:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Ah, I have the same opinion about this theme. You don't really > > need a higher precision than 64 bit. Maybe that will change for > > galaxy navigation in the future but until now 32 bit are good > > (and fast) for most cases. > > Actually, floating-point is too imprecise for ANY precision > calculation. There are lots of numbers that can't be encoded > into floating-point values. There are also lots of numbers which can't be encoded into BCD values, e.g. 1/3, 1/7 etc. Floating-point calculations aren't absolute precision but neither are BCD. Hans ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 14:02:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3i-0000SB-00 for ; Sat, 18 Aug 2001 02:33:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:50 +0200 (CEST) Received: (qmail 20968 invoked by uid 0); 17 Aug 2001 11:34:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 17 Aug 2001 11:34:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA08726 for ; Fri, 17 Aug 2001 07:34:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 11:34:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA08480 for f-cpu-list; Fri, 17 Aug 2001 07:34:18 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA08477 for ; Fri, 17 Aug 2001 07:34:18 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HBY0b03497 for ; Fri, 17 Aug 2001 07:34:00 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XiKE-0003h8-00 for f-cpu@seul.org; Fri, 17 Aug 2001 14:02:06 +0200 Date: Fri, 17 Aug 2001 14:02:06 +0200 (MEST) From: Juergen Goeritz To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi guys, don't fight about it :-) All fast implementations have a problem on precision. Usually you shrink down the window where the system will work correctly to achieve maximum speed. I read a lot about filtering lately - my head still aches. Was talking to Yann lately if it won't be possible to design fast 32 bit floating point instructions that keep the computed value as one part of a 64 bit value pair, the other being the imprecise error of this value due to the limitations of precision. I am just getting into floating point methods though and therefore can't tell today if this is possible or not. But imagine you add/subtract/multiply/divide a number and take care of the number unsharpness the same instance. Forget about rounding problems, just track them with the computation values. What's your opinion? JG On Fri, 17 Aug 2001, Hans Summers wrote: > > > > > > Ah, I have the same opinion about this theme. You don't really > > > need a higher precision than 64 bit. Maybe that will change for > > > galaxy navigation in the future but until now 32 bit are good > > > (and fast) for most cases. > > > > Actually, floating-point is too imprecise for ANY precision > > calculation. There are lots of numbers that can't be encoded > > into floating-point values. > > > > The bits in the mantissa are encoded as follows, for example: > > - bit 0: 1/2: 0.5 > > - bit 1: 1/4: 0.25 > > - bit 2: 1/8: 0.125 > > - bit 3: 1/16: 0.0625 > > > > and so on. By setting the bits, you're adding up the fractions. > > > > So, for example with financial computing, floating-point is a > > big no-no, otherwise you end up with respresentation and rounding > > errors. > > I've spent the last 7 years writing financial applications, and have NEVER > seen or heard of BCD arithmetic being used. I always use 64-bit > representation mostly because it is most standard. Yes, you will get > rounding errors but you need a heck of a lot of calculations for the > rounding errors in the 16'th decimal place to add up to anything of any > significance. > > Hans > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From emorgens@prs-gmbh.de Fri Aug 17 13:38:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3i-0000SB-01 for ; Sat, 18 Aug 2001 02:33:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:50 +0200 (CEST) Received: (qmail 10842 invoked by uid 0); 17 Aug 2001 11:41:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 17 Aug 2001 11:41:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA09092 for ; Fri, 17 Aug 2001 07:41:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 11:41:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA08846 for f-cpu-list; Fri, 17 Aug 2001 07:41:29 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA08843 for ; Fri, 17 Aug 2001 07:41:28 -0400 Received: from prs-02.prs ([212.126.220.227]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HBfBb03597 for ; Fri, 17 Aug 2001 07:41:11 -0400 Subject: RE: [f-cpu] Re: Floating-Point? To: f-cpu@seul.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ekkehard Morgenstern" Date: Fri, 17 Aug 2001 13:38:37 +0200 X-MIMETrack: Serialize by Router on PRS_02/PRS GmbH(Release 5.0.8 |June 18, 2001) at 17.08.2001 13:45:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Yes, you will get > rounding errors but you need a heck of a lot of calculations for the > rounding errors in the 16'th decimal place to add up to anything of any > significance. I just found an article that outlines the problem I stated more precisely than I can: http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html The article says: "For instance, 7/5 is 1.4 exactly in decimal numeration, but the .4 part cannot be expressed as a sum of powers of two; 7/5 has an infinite binary expansion 1.011001100110011001100..., " Before such a number is prepared for display, the C standard library for example does the rounding to a legible number. So if you write printf( "%g\n", 7.0/5.0 ); you might get 1.4 as desired, but internally the number is not correct. Many years ago, I've been responsible for a development system for business applications, which used floating-point arithmetic, and we had error reports from customers that turned out as floating-point representation problems. Mind you, we've been using only 2 decimal places. And the number of calculations didn't matter either. Sometimes after the first divison, and sometimes after millions of computations, and the problem was simply that a value has been used that could not be represented properly as a floating-point number. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 13:58:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3j-0000SB-00 for ; Sat, 18 Aug 2001 02:33:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:51 +0200 (CEST) Received: (qmail 8895 invoked by uid 0); 17 Aug 2001 11:58:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 17 Aug 2001 11:58:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA09537 for ; Fri, 17 Aug 2001 07:58:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 11:58:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA09291 for f-cpu-list; Fri, 17 Aug 2001 07:58:29 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA09288 for ; Fri, 17 Aug 2001 07:58:28 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HBwCb03702 for ; Fri, 17 Aug 2001 07:58:12 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id HAA16831 for ; Fri, 17 Aug 2001 07:52:35 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id HAA07141 for ; Fri, 17 Aug 2001 07:58:22 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 12:58:22 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F02C@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 12:58:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Yes, you will get > > rounding errors but you need a heck of a lot of calculations for the > > rounding errors in the 16'th decimal place to add up to > > anything of any significance. > > I just found an article that outlines the problem I stated > more precisely > than I can: > > http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html Interesting article. > > The article says: > > "For instance, 7/5 is 1.4 exactly in decimal numeration, but > the .4 part > cannot be expressed as a sum of powers of two; 7/5 has an > infinite binary > expansion 1.011001100110011001100..., " > > Before such a number is prepared for display, the C standard > library for example does the rounding to a legible number. > > So if you write > > printf( "%g\n", 7.0/5.0 ); > > you might get 1.4 as desired, but internally the number is > not correct. I agree but decimal notation has exactly the same problem with other numbers, e.g. 7/3. It's true to say that a decimal system can always accurately display the decimal equivalent of a binary number, but the reverse isn't necessarily true, and that therefore decimal systems can accurately represent more numbers than binary. > > Many years ago, I've been responsible for a development > system for business applications, which used floating-point > arithmetic, and we had error reports from customers that turned out > as floating-point representation problems. Mind you, we've > been using only 2 decimal places. > > And the number of calculations didn't matter either. > Sometimes after the first divison, and sometimes after > millions of computations, and the problem was > simply that a value has been used that could not be > represented properly as a floating-point number. > If you are only using 2 decimal places then I can imagine such errors occuring. The rule should always be to internally use somewhat greater precision than you need to display externally, so that any rounding errors nearly always remain invisible. On a related topic, I recall with some amusement certain news reports in 1999, when the US' Dow Jones Industrial stock index was approaching a value of 10,000. At that time obviously there were an abundance of Y2K fears, and there was this story doing the rounds about the so-called "D10K bug". Allegedly when the Dow exceeded 10,000 various computers tracking its progress would think the value had suddenly dropped to near zero, and these automated systems would frantically issue sell orders, plunging world stock markets into the worse crash anyone has ever seen. These systems were imagined to only be able to represent 4 digits of the Dow's value. Of course, regardless of how much space programmers had allowed on screens for the DJI, internally the applications most definitely did not use 4-digit BCD representation. Inevitably when the Dow did eventually pass 10,000 nothing happened and equally inevitably, the media conveniently forgot about the earlier scare stories. ------------------ Hans Summers ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 17 20:28:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3k-0000SB-01 for ; Sat, 18 Aug 2001 02:33:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:53 +0200 (CEST) Received: (qmail 11150 invoked by uid 0); 17 Aug 2001 12:19:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 17 Aug 2001 12:19:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA09995 for ; Fri, 17 Aug 2001 08:19:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 12:18:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA09748 for f-cpu-list; Fri, 17 Aug 2001 08:18:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA09745 for ; Fri, 17 Aug 2001 08:18:57 -0400 Received: from localhost.localdomain (nas5-168.vlt.club-internet.fr [194.158.107.168]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HCIdb03823 for ; Fri, 17 Aug 2001 08:18:40 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6D10015D7 for ; Fri, 17 Aug 2001 14:28:01 -0400 (EDT) Message-ID: <3B7D6231.5981342F@ifrance.com> Date: Fri, 17 Aug 2001 14:28:01 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F020@po1-exch.lon.tudor.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hans Summers a écrit : > > > On Thu, Aug 16, 2001 at 01:49:27PM +0800, Glenn Alexander wrote: > > > Hi. This is my first post to this list. My background is as > > > a hardware technician, not a chip designer so bear with me. > > > > > > On Thursday 16 August 2001 03:41, you wrote: > > > > Michael Riepe a écrit : > > > > > > > > In sparc, there is no 80 bits float but 128 bits (2 > > > > registers used in the same time). We don't need 1 cycle > > > > multiplication so it could be done for the fcpu. > > > > > > I am thinking that taking the two-register approach might be > > > over-complicating matters. Since F-CPU is intended to later > > > be scaled above 64 bits, if someone wanted 128-bit floats > > > in the future they would impliment a 128-bit F-CPU. > > > Especially for the FC-0 and probably for the FC-1, KISS > > > (Keep It Simple for us Stupid people). > > > > 128-bit `quadruple precision' (like SPARC) is IMHO the way to go, but > > not in the FC0. For now, let's stick to 32-bit and 64-bit > > (with 80-bit `double extended' used inside the FP unit, > > to maintain IEEE compliance). > > > Could someone explain to me why 128-bit FP is desireable? I am struggling It's very easy : almost all scientific calculation ! This include electric simulation (spice), aerodynamic, and so on... For a lot of mathematician 32 bits are a none sense ! For laughing, they said that they didn't want to take a plane any more ! Don't forget that every compiler defined float as double (64b) by default. With 32 bit there is too much rounding problem. The only killing application for it is the image processing. That's wy some of them want 256 bits fp number. nicO > here to think of an application which needs 30 decimal places of precision > (or whatever it is). In fact I'd go as far as to suggest that in most cases > 32-bit FP would be sufficient. Chip designers tend to dream of having a > 128-bit or 256-bit processor etc., but without reference to the real world > which doesn't need (actually can't make good use of) such high precision FP. > Expanding the word size won't deliver a performance enhancement. My belief > is the only way such large word sizes make any kind of sense is in the > contect of SIMD, where the large word size is effectively a parrelisation. > > ------------------ > Hans Summers > http://www.hanssummers.com/computers/fcpu/scheduler.htm > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 14:34:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3l-0000SB-00 for ; Sat, 18 Aug 2001 02:33:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:53 +0200 (CEST) Received: (qmail 24022 invoked by uid 0); 17 Aug 2001 12:35:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 17 Aug 2001 12:35:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA10398 for ; Fri, 17 Aug 2001 08:35:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 12:35:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA10154 for f-cpu-list; Fri, 17 Aug 2001 08:35:00 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA10142 for ; Fri, 17 Aug 2001 08:34:59 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HCYhb04092 for ; Fri, 17 Aug 2001 08:34:43 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id IAA19100 for ; Fri, 17 Aug 2001 08:29:06 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id IAA08967 for ; Fri, 17 Aug 2001 08:34:53 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 13:34:53 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F02D@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 13:34:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id IAA10143 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Hans Summers a écrit : > > > > > On Thu, Aug 16, 2001 at 01:49:27PM +0800, Glenn Alexander wrote: > > > > Hi. This is my first post to this list. My background is as > > > > a hardware technician, not a chip designer so bear with me. > > > > > > > > On Thursday 16 August 2001 03:41, you wrote: > > > > > Michael Riepe a écrit : > > > > > > > > > > In sparc, there is no 80 bits float but 128 bits (2 > > > > > registers used in the same time). We don't need 1 cycle > > > > > multiplication so it could be done for the fcpu. > > > > > > > > I am thinking that taking the two-register approach might be > > > > over-complicating matters. Since F-CPU is intended to later > > > > be scaled above 64 bits, if someone wanted 128-bit floats > > > > in the future they would impliment a 128-bit F-CPU. > > > > Especially for the FC-0 and probably for the FC-1, KISS > > > > (Keep It Simple for us Stupid people). > > > > > > 128-bit `quadruple precision' (like SPARC) is IMHO the > > > way to go, but not in the FC0. For now, let's stick to > > > 32-bit and 64-bit (with 80-bit `double extended' used > > > inside the FP unit, to maintain IEEE compliance). > > > > > Could someone explain to me why 128-bit FP is desireable? I > > am struggling > > It's very easy : almost all scientific calculation ! This include > electric simulation (spice), aerodynamic, and so on... For a lot of > mathematician 32 bits are a none sense ! For laughing, they said that > they didn't want to take a plane any more ! Don't forget that every > compiler defined float as double (64b) by default. With 32 > bit there is too much rounding problem. The only killing application > for it is the image processing. That's wy some of them want 256 > bits fp number. Sorry I still can't see it. Which electric or aerodynamic simulations require 30 decimal places of accuracy? In my scientific days I never came across a calculation needing anything like 128 bits of precision. "Almost all scientific calculation" seems to me like a huge exagerration. The limits of measurement are often to be measured in percent, so why would you want to calcuate to 30 decimal places when you can only measure to one or two? As for electrical simulation, when resistors usually have a 1% error, and capacitors 5 or 10%, where are the 30 decimal places needed? Fine, for the sake of comfort, use doubles (64-bit). And I am sure that some areas genuinely need more precision. But I still believe the number of applications requiring this much precision to be very small. For a general purpose processor implementing 128-bit FP is a waste of resources. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Fri Aug 17 15:01:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3n-0000SB-00 for ; Sat, 18 Aug 2001 02:33:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:55 +0200 (CEST) Received: (qmail 14738 invoked by uid 0); 17 Aug 2001 13:02:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 13:02:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA10921 for ; Fri, 17 Aug 2001 09:02:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 13:01:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA10674 for f-cpu-list; Fri, 17 Aug 2001 09:01:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA10671 for ; Fri, 17 Aug 2001 09:01:44 -0400 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HD1Pb04626 for ; Fri, 17 Aug 2001 09:01:27 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA08087 for ; Fri, 17 Aug 2001 16:01:39 +0300 (EET DST) Date: Fri, 17 Aug 2001 16:01:38 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F02D@po1-exch.lon.tudor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Hans Summers wrote: > Sorry I still can't see it. Which electric or aerodynamic simulations > require 30 decimal places of accuracy? I don't see it either. I have done some analog electronic simulations when I was at the university and the lecturers always were saying that the simulations usually are 5-20% accurate :) Not anywhere near the 30 decimal places. I understand that in iterations inside the models some accuracy is needed, but not this much. It's quite fun to compare the simulated and real silicon results of the simulations, there are always differences, 1% accuracy is an excellent result. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Aug 17 15:33:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3o-0000SB-00 for ; Sat, 18 Aug 2001 02:33:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:56 +0200 (CEST) Received: (qmail 17071 invoked by uid 0); 17 Aug 2001 13:05:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 17 Aug 2001 13:05:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA11216 for ; Fri, 17 Aug 2001 09:05:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 13:05:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA10971 for f-cpu-list; Fri, 17 Aug 2001 09:05:11 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA10968 for ; Fri, 17 Aug 2001 09:05:10 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HD4rb04748 for ; Fri, 17 Aug 2001 09:04:53 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15XjkD-0003oA-00 for f-cpu@seul.org; Fri, 17 Aug 2001 15:33:01 +0200 Date: Fri, 17 Aug 2001 15:33:01 +0200 (MEST) From: Juergen Goeritz To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F02D@po1-exch.lon.tudor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Hans Summers wrote: > Fine, for the sake of comfort, use doubles (64-bit). And I am sure that some > areas genuinely need more precision. But I still believe the number of > applications requiring this much precision to be very small. For a general > purpose processor implementing 128-bit FP is a waste of resources. Are there any 128BIT fp at all? There may be no requirement >from the market so far for this high precision. ;-) jg ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From emorgens@prs-gmbh.de Fri Aug 17 16:04:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3o-0000SB-01 for ; Sat, 18 Aug 2001 02:33:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:56 +0200 (CEST) Received: (qmail 15085 invoked by uid 0); 17 Aug 2001 14:07:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 17 Aug 2001 14:07:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA12110 for ; Fri, 17 Aug 2001 10:07:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 14:07:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA11864 for f-cpu-list; Fri, 17 Aug 2001 10:07:14 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA11861 for ; Fri, 17 Aug 2001 10:07:13 -0400 Received: from prs-02.prs ([212.126.220.227]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HE6vb06090 for ; Fri, 17 Aug 2001 10:06:57 -0400 Subject: RE: [f-cpu] Re: Floating-Point? To: f-cpu@seul.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ekkehard Morgenstern" Date: Fri, 17 Aug 2001 16:04:23 +0200 X-MIMETrack: Serialize by Router on PRS_02/PRS GmbH(Release 5.0.8 |June 18, 2001) at 17.08.2001 16:10:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > It's true to say that a decimal system can always accurately display the > decimal equivalent of a binary number, but the reverse isn't necessarily > true, and that therefore decimal systems can accurately represent more > numbers than binary. Yeah. For the purpose of F-CPU, I'd say let's support at least 64 bit FP, 32 is not enough, and for 128 there might be no data type support from programming languages (i.e. compilers assuming max. FP bit depths). I don't know if FP portability is really an issue with this processor, but if we do 128 or 256 bits, we have to support 32, 64, 80, and 96 as well. (the latter four are IEEE standards). [off-topic] > If you are only using 2 decimal places then I can imagine such errors > occuring. The rule should always be to internally use somewhat greater > precision than you need to display externally, so that any rounding errors > nearly always remain invisible. The problem was that the data was stored in database fields with fixed precision (two decimal points), in ASCII format. When retrieved, conversion errors occurred, and the system internally did conversions from and to strings all the time (before and after computations in string fields). We solved the problem by providing a configurable rounding mechanism, which could be set, for example, to 4 decimal places. Still, manual rounding in computation expressions for some special cases was necessary. Arbitrary-length BCD- or fixed-/floating-point arithmetic maybe could have eliminated the problems, but we couldn't change it because there was so much code that did manual rounding, working around the existing problem. lol > Of course, regardless of how much space programmers had allowed on screens > for the DJI, internally the applications most definitely did not use 4-digit > BCD representation. Inevitably when the Dow did eventually pass 10,000 > nothing happened and equally inevitably, the media conveniently forgot about > the earlier scare stories. That doesn't surprise me. Thank god that the code wasn't written in COBOL! ;-) [/off-topic] ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From emorgens@prs-gmbh.de Fri Aug 17 16:40:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3r-0000SB-00 for ; Sat, 18 Aug 2001 02:33:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:33:59 +0200 (CEST) Received: (qmail 31810 invoked by uid 0); 17 Aug 2001 14:43:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 17 Aug 2001 14:43:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA12687 for ; Fri, 17 Aug 2001 10:43:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 14:42:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA12445 for f-cpu-list; Fri, 17 Aug 2001 10:42:55 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA12442 for ; Fri, 17 Aug 2001 10:42:54 -0400 Received: from prs-02.prs ([212.126.220.227]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HEgbb06896 for ; Fri, 17 Aug 2001 10:42:37 -0400 Subject: RE: [f-cpu] Re: Floating-Point? To: f-cpu@seul.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ekkehard Morgenstern" Date: Fri, 17 Aug 2001 16:40:03 +0200 X-MIMETrack: Serialize by Router on PRS_02/PRS GmbH(Release 5.0.8 |June 18, 2001) at 17.08.2001 16:46:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Was talking to Yann lately if it won't be possible > to design fast 32 bit floating point instructions > that keep the computed value as one part of a 64 bit > value pair, the other being the imprecise error of > this value due to the limitations of precision. This might be a good idea, but why not use 128 bits internally (i.e. by making the registers that wide), and design FMOV instructions that cut off / expand mantissa and exponent when loading/storing floating-point data to different bit widths? When the FPU internally uses one bit-depth with high precision, rounding and representation errors can be minimized. Whether execution speed suffers from 128 bits, is a question of FPU design, I think. For example, Intel's Pentium processor line uses lots of tables to maximize the speed of multiplication and division operations. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Fri Aug 17 17:19:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3s-0000SB-00 for ; Sat, 18 Aug 2001 02:34:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:00 +0200 (CEST) Received: (qmail 1008 invoked by uid 0); 17 Aug 2001 15:21:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 15:21:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA13281 for ; Fri, 17 Aug 2001 11:21:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 15:19:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA13025 for f-cpu-list; Fri, 17 Aug 2001 11:19:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA13022 for ; Fri, 17 Aug 2001 11:19:44 -0400 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HFJRb07552 for ; Fri, 17 Aug 2001 11:19:27 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA07675 for ; Fri, 17 Aug 2001 18:19:42 +0300 (EET DST) Date: Fri, 17 Aug 2001 18:19:41 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: RE: [f-cpu] Re: Floating-Point? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Ekkehard Morgenstern wrote: > Whether execution speed suffers from 128 bits, is a question of > FPU design, I think. 128 bits is quite wide bus even with current ASIC processes. It is near the limit where the busses have to be layouted manually and even with manual layout there can be problems. Also adders with even 64-bit width are quite complex and have many levels of logic. But I think the biggest problem is the FPGA implementation. FPGA structures don't like wide busses and wide muxes. Current high end FPGAs have some structures to help these problems but even they have problems with wide busses. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Aug 17 17:47:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3s-0000SB-01 for ; Sat, 18 Aug 2001 02:34:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:00 +0200 (CEST) Received: (qmail 29639 invoked by uid 0); 17 Aug 2001 15:48:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 17 Aug 2001 15:48:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA13873 for ; Fri, 17 Aug 2001 11:48:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 15:48:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA13629 for f-cpu-list; Fri, 17 Aug 2001 11:48:12 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA13626 for ; Fri, 17 Aug 2001 11:48:11 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HFlsb07819 for ; Fri, 17 Aug 2001 11:47:55 -0400 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA25043 for ; Fri, 17 Aug 2001 09:48:08 -0600 (MDT) Message-ID: <3B7D3C77.6652E297@jetnet.ab.ca> Date: Fri, 17 Aug 2001 09:47:03 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hans Summers wrote: > I've spent the last 7 years writing financial applications, and have NEVER > seen or heard of BCD arithmetic being used. I always use 64-bit > representation mostly because it is most standard. Yes, you will get > rounding errors but you need a heck of a lot of calculations for the > rounding errors in the 16'th decimal place to add up to anything of any > significance. I suspect most programs that do acounting and other stuff for small financial applications ended up being written in languages that did not support decimal format.Note many database style languages may calculate in decimal character data. Not too long ago floating point was 32 bit math still done in software on 386's. 64/80 bit math was not a option back then. Ben. PS. Any idea when you web page will be back on line ,Hans? -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 18:20:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3t-0000SB-00 for ; Sat, 18 Aug 2001 02:34:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:01 +0200 (CEST) Received: (qmail 24204 invoked by uid 0); 17 Aug 2001 16:21:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 17 Aug 2001 16:21:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA14671 for ; Fri, 17 Aug 2001 12:21:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:20:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA14234 for f-cpu-list; Fri, 17 Aug 2001 12:20:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA14231 for ; Fri, 17 Aug 2001 12:20:42 -0400 Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGKQb08168 for ; Fri, 17 Aug 2001 12:20:26 -0400 Received: from f-cpu.org (nas3-27.ras.club-internet.fr [195.36.203.27]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA15983 for ; Fri, 17 Aug 2001 18:20:40 +0200 (MET DST) Message-ID: <3B7D4446.14BFB692@f-cpu.org> Date: Fri, 17 Aug 2001 18:20:22 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > On Fri, 17 Aug 2001, Glenn Alexander wrote: <> > > I agree: untill we start launching space-probes, 64 bit FP seems fine. But > > the option for more will be there when we do build the F-rocket (FR-1). > > Error is human - maybe we live in an evolution based > simulation for optimization? Who knows how our senses > are really working? :-) > > Hmh, don't think I want to live in this universe A instead. > But the thought of a far distant space ship is enticing... "Anywhere outa this f*k*ng world", huh ? but please don't leave before the first F-CPU prototype is built ;-) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 18:20:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3u-0000SB-00 for ; Sat, 18 Aug 2001 02:34:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:02 +0200 (CEST) Received: (qmail 21779 invoked by uid 0); 17 Aug 2001 16:21:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 17 Aug 2001 16:21:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA14750 for ; Fri, 17 Aug 2001 12:21:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:20:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA14306 for f-cpu-list; Fri, 17 Aug 2001 12:20:54 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA14293 for ; Fri, 17 Aug 2001 12:20:52 -0400 Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGKZb08172 for ; Fri, 17 Aug 2001 12:20:35 -0400 Received: from f-cpu.org (nas3-27.ras.club-internet.fr [195.36.203.27]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA24885 for ; Fri, 17 Aug 2001 18:20:43 +0200 (MET DST) Message-ID: <3B7D4448.E487FE0@f-cpu.org> Date: Fri, 17 Aug 2001 18:20:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, just a quick answer. Juergen Goeritz wrote: > > On Fri, 17 Aug 2001, Hans Summers wrote: > > Could someone explain to me why 128-bit FP is desireable? I am struggling > > here to think of an application which needs 30 decimal places of precision > > (or whatever it is). In fact I'd go as far as to suggest that in most cases > > 32-bit FP would be sufficient. Chip designers tend to dream of having a > > 128-bit or 256-bit processor etc., but without reference to the real world > > which doesn't need (actually can't make good use of) such high precision FP. > > Expanding the word size won't deliver a performance enhancement. My belief > > is the only way such large word sizes make any kind of sense is in the > > contect of SIMD, where the large word size is effectively a parrelisation. > > Ah, I have the same opinion about this theme. You don't really > need a higher precision than 64 bit. Maybe that will change for > galaxy navigation in the future but until now 32 bit are good > (and fast) for most cases. I would rather implement some 32 bit > pipelined floating point instructions than go for a dedicated > fpu anyway... ;-) 32 bits is fine as long as - your algorithm is correctly designed so numerical stability is ensured "by design" - the precision of the measuraments is below the precision of the number 64 bit can look as an overkill in a lot of applications. however, high precision is required when - your equation/algorithm creates values that are concentrated in one small fraction of the precision (and you don't know where, so you can't optimize the equation) - your algorithm has to run millions of loops over the same data without rounding artifacts. - your algorithm is HIGHLY NON LINEAR and a meaningless rounding error can result in completely false errors. examples of things that are ok for 32 bits FP : spectrum analysis, filtering... (sound/image processing, machine control...) examples of things that need 64 bits : 3-body (or more) interaction, nuclear physics... I have once seen a picture of a 3-D representation of Lorenz's attractor, computed by different machines. even though most machines were (claimed) IEEE, there are differences. the CRAY diagram differed most (non-IEEE). so yes : numerical stability and precision are coupled. > JG Ekkehard Morgenstern wrote: > > Ah, I have the same opinion about this theme. You don't really > > need a higher precision than 64 bit. Maybe that will change for > > galaxy navigation in the future but until now 32 bit are good > > (and fast) for most cases. > > Actually, floating-point is too imprecise for ANY precision calculation. > There are lots of numbers that can't be encoded into floating-point values. > > The bits in the mantissa are encoded as follows, for example: > - bit 0: 1/2: 0.5 > - bit 1: 1/4: 0.25 > - bit 2: 1/8: 0.125 > - bit 3: 1/16: 0.0625 > > and so on. By setting the bits, you're adding up the fractions. > > So, for example with financial computing, floating-point is a big no-no, > otherwise you end up with respresentation and rounding errors. > > Any precision computing does not use floating-point. BCD string arithmetic > (as known from COBOL and FORTRAN) is most commonly used for these > tasks. > > So, it doesn't really matter how precise the FP is, but the finer the > better, > of course. It would extend the number of applications for the CPU, since > sometimes it's desirable to sacrifice the precision for the sake of speed. > > On mainframes, there are AFAIK some applications that use custom code > to do as much arithmetic in integer or FP as possible, and that use > fixed-point > or BCD otherwise. > > 32, 64 and 80 bit floating-point are standard nowadays, so these should be > supported to avoid software emulation (preferrably IEEE standard > compliant). concerning precision : some weeks ago, we discussed about an arbitrary precision computation package. if extreme acuracy is required, it is one way to go. multi-precision computation (with int operations) should be no problem on F-CPU. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 17 15:15:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3v-0000SB-00 for ; Sat, 18 Aug 2001 02:34:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:03 +0200 (CEST) Received: (qmail 31958 invoked by uid 0); 17 Aug 2001 16:23:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 17 Aug 2001 16:23:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA15033 for ; Fri, 17 Aug 2001 12:23:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:22:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA14781 for f-cpu-list; Fri, 17 Aug 2001 12:22:29 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA14778 for ; Fri, 17 Aug 2001 12:22:27 -0400 Received: from tribble.stud.uni-hannover.de (root@a175.home.uni-hannover.de [130.75.232.175]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGLgb08210 for ; Fri, 17 Aug 2001 12:21:45 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00709; Fri, 17 Aug 2001 15:15:28 +0200 Message-ID: <20010817151528.01360@thrai.stud.uni-hannover.de> Date: Fri, 17 Aug 2001 15:15:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F02A@po1-exch.lon.tudor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F02A@po1-exch.lon.tudor.com>; from Hans Summers on Fri, Aug 17, 2001 at 12:16:44PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 17, 2001 at 12:16:44PM +0100, Hans Summers wrote: [...] > There are also lots of numbers which can't be encoded into BCD values, e.g. > 1/3, 1/7 etc. That's why LISP has bignums and the `rational' data type :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 17 15:06:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3w-0000SB-00 for ; Sat, 18 Aug 2001 02:34:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:04 +0200 (CEST) Received: (qmail 31036 invoked by uid 0); 17 Aug 2001 16:23:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 17 Aug 2001 16:23:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA15536 for ; Fri, 17 Aug 2001 12:23:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:23:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA15120 for f-cpu-list; Fri, 17 Aug 2001 12:23:17 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA15099 for ; Fri, 17 Aug 2001 12:23:14 -0400 Received: from tribble.stud.uni-hannover.de (root@a175.home.uni-hannover.de [130.75.232.175]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGMob08254 for ; Fri, 17 Aug 2001 12:22:51 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00677; Fri, 17 Aug 2001 15:06:12 +0200 Message-ID: <20010817150612.31893@thrai.stud.uni-hannover.de> Date: Fri, 17 Aug 2001 15:06:12 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] Re: Floating-Point? References: <3B7926B0.C1FC207D@f-cpu.org> <20010814210034.54796@thrai.stud.uni-hannover.de> <3B7A3133.744063F0@f-cpu.org> <20010815231227.63958@thrai.stud.uni-hannover.de> <3B7BF3A9.5B0E4DD4@f-cpu.org> <20010817003553.36482@thrai.stud.uni-hannover.de> <3B7C8059.957E20D3@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3B7C8059.957E20D3@f-cpu.org>; from Yann Guidon on Fri, Aug 17, 2001 at 04:24:25AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 17, 2001 at 04:24:25AM +0200, Yann Guidon wrote: [...] > > Mapped to (2's complement signed) integer, the order is as follows > > (assuming IEEE `single' format): > > > > s eeeee fff meaning > > ===================== > > 0 ff >0 NAN > > 0 ff =0 +INF > > 0 01-fe any positive normal > > 0 00 >0 positive subnormal > > 0 00 =0 +0 > > 1 ff >0 NAN > > 1 ff =0 -INF > > 1 01-fe any negative normal > > 1 00 >0 negative subnormal > > 1 00 =0 -0 > > > > That's obviously not correct. > where ? negative normal/subnormal ? +0/-0 ? > we'll have to ask some experts... The point is: when compared as 2's complement signed integers, the order of FP values would be -0 < -x < -INF < +0 < +x < +INF which is certainly not correct. > > I didn't find .zero or a negation suffix, though. > it's a higher-level trick :-) > the syntax defines the usual émove src, dest" > and "cmove cond.y == x, src, dest" for conditional moves. Sorry, but that's plain ugly :( > i have chosen to explicitely use "cmove" because i feared > a shift-reduce problem. Not in my parser :) The trick is not to add grammar rules for individual instructions, but to use a general rule like instruction : opcode | opcode operand_list operand_list : operand | operand_list ',' operand operand : '$' expression | register or something like that, and let the semantic actions do the rest (asm directives have individual rules, but not machine instructions). BTW: to avoid ambiguities, either expressions or register names must be prefixed with a special character; otherwise it's impossible to tell the difference between the symbol `r63' and the register `r63' -- and symbols like `r63' *must* be allowed (otherwise, compilers may have trouble). Prefixing the expression is the lesser evil, IMHO (register names are used more often than expressions -- and I never liked the `%eax' syntax ;). > "y" can be nothing, ".lsb" and ".msb" > and "x" can be 0 or 1. what about NaN? `r3.nan == 0' would be pretty confusing, and `r3 == nan' is yet another syntactic special case. > There is an inconsistency for > "cmove r==1" (i'll fix that with inverting everything :*D) > but otherwise it is written "r.lsb==0", "r==0", "r.msb==0" > and idem for 1. the x value gives the negation directly ;-) Why not `r != 0', `r.lsb != 0' and `r.msb != 0'? Or use a syntax similar to C (or VHDL): !=0 =0 =0 (alt.) r !r not r r.nan !r.nan not r.nan r.lsb !r.lsb not r.lsb r.msb !r.msb not r.msb > and the absence of specifier means the whole register, hence > zero or not. > i know, it's lame, but it works :-) and it's less confusing than > -nm for example. If you really intend to do that, please do it a little different: use `if ', where can be move or jmp. It's much cleaner that way (from both the stylistic and the syntactic point of view). If your asm directives don't start with "." (that is, `.if' instead of `if'), you could use `cond[itional]' as the keyword. Or use ia64-style syntax: (r3.lsb) move r2, r1 (!r3) jmp r2, r1 Anyway, this is still a special case that has to be handled in the parser :( [...] > > I could > > also use `n' for `NAN', but that makes the instruction encoder a little > > more complex and is probably misleading anyway. But I'll think it over. > > [...] > > 'i' for 'i'nvalid ? Also possible. Thank you :) > > > > - Can we please drop the `a' from `jmpa'? > > > probably. i don't remember where it comes from, probably from Mathias. > > It was meant to indicate an (A)bsolute jump. Since that's the only > > one the F-CPU knows, the suffix is redundant (and it looks too much > > like `jump always'). > ok let's go. Done :) > > > > - When calling functions through pointers, it would be nice to > > > > be able to tell the F-CPU *a priori* that a register contains a > > > > code address. While this can be done with an explicit prefetch > > > > (load to r0) for data pointers, there is no way to specify that > > > > a register contains a code address that the CPU will have to > > > > visit soon. > > > what about loadaddr(i) ? > > Not useful. > that's sad. > > Maybe... we can use one or two bits from the add/sub instructions > so they validate and prefetch the resulting pointer ? Umh... not really. There is not always an add/sub instruction in the chain (expecially not when a function's address is read from memory). > > Imagine a C++ `member' function -- the first (hidden) > > argument is a pointer to the class, the class contains a pointer to > > the virtual method table, and the VMT contains pointers to all the > > members. > i can understand english, french and german, > i know a few words in several european langages such as > italian, spanish, portugese, tchech, russian, polish, latvian... > but i still believe that C++ comes from Mars. Or worse ;) But C++ is not the only language that does things like that. > > To call another member, you have to > > > > // let r1 point to the current instance > > load r1, r2 // get pointer to VMT (usually stored at offset 0) > > add $offset, r2, r3 // VMT slot address > > load r3, r4 // get member's address > > // argument passing omitted > > jmp r4, r5 // call member > > what an ugly code :-( > is all this necessary ??? I think so. How would *you* do it? > There is one "programming trick" in FC0 : > you use a "software barrel of 8 registers" for data and another > "barrel" for instructions. when you want to access data, > use post-incremented form as possible, with an increment > such as it points to the data that you will access in 8 L/S > instructions. the code above is extremely short-sighted and > utterly underefficient. Since it is lacking any context, there is no other way, IMHO. Of course you can keep the VMT pointer in a register if you use it more than once. If you call a function from inside a loop, you can also keep its address in a register (and you probably won't have the prefetch problem when the loop is executed the second time). But that's not always the case. > > Both r2 (data pointer) and r4 (code pointer) are loaded from memory, > > and r3 (also a data pointer) is calculated from r2 and a constant > > (which probably has to be loadcons'd if it is too large). But there > > is no loadaddr[i] in that sequence, and the CPU has no way to tell > > that r4 points to a function that is going to be called real soon > > (that is, its code should be prefetched to avoid a stall). > maybe we need a sort of loadaddr(i) without PC ? > i have the feeling that i miss something here... It need not be a load (or move) operation, just a no-op that hints the CPU to prefetch code. A little like `cachemm', but more lightweight and `for-the-moment' (cachemm is supposed to change the caching parameters permanently, isn't it?). > > > > The same is true when an absolute code address is > > > > obtained via loadcons (which will probably be the common idiom > > > > when a function in another object file is called, unless jump > > > > tables are used -- which points us back to the `code pointer > > > > in register' problem, again). > > > if the data/code is not explicitely prefetched, the code will still work, > > > but with the "late fetch" penalty : the CPU will perform the "fetch" > > > operation automatically while stalling the decode stage. > > The point is that one cannot prefetch code. `load r4, r0' will prefetch > > the code into the D-cache, not the I-cache. > something seems broken here. The question is what: the argument, or the design? ;) > > > > To cut a long story short: I'd like to have an instruction > > > > that explicitly `tags' a register as a pointer, and probably > > > > initiates a prefetch cycle (for code or data, depending on > > > > the instruction's flags). It may or may not move data from > > > > one register to another (one idea I had was a `pointer move' > > > > instruction); if it does, it might be a good idea to let it > > > > participate in address calculation (i.e. let it be able to > > > > add two operands, like the `lea' instruction on Intel CPUs). > > > this is what loadaddr is meant to do. > > > > But it only works with PC-relative addressing. While that's fine for > > conditional branches, loops and local function calls, inter-module calls > > cannot use it because the target address is resolved at link time (and > > what's worse: it may be too far away for a 16-bit displacement unless > > you limit the text segment size to 64 KB -- which is not a realistical > > value at all). > > what's your conclusion, doctor ? Add an instruction that says `i will soon jump to '. Nothing more, nothing less. > > > > - Let's clarify the suffix order, e.g. like this (? means the > > > > suffix is currently unused, and its name is unassigned): > > [...] > > > wow, what a work :-) > > > > You should see the complete flex source for the encoder; this is only > > a small snippet ;) > > i WANT to see it ;-) Don't worry, you will :) [...] > > > > Since there are some unused flags, another variant might be > > > > interesting: `storem r2, r1', where r2 is used as a mask > > > > (bit == 1 means "load/store register "), and r1 is the > > > > address of the source/destination memory area (which must be > > > > big enough to hold all registers, just like the CMB). > > > > > > this mask idea is interesting. It remembers me of the 6809 by the way :-) > > > however it means that 4x loadcons might be necessary (in arbitrary cases) > > > to backup the whole (non-contiguous) register set. > > > > You can still use loadm/storem if you have only two or three contiguous > > register blocks to save/restore. The mask is useful when a) the registers > > to save are too scattered or b) not known at compile time (emulators, > > debuggers, ...), and you don't want to loop over the whole register bank > > (that is, 63 times) and loadm/storem a single register each time. > > in such a 'scattered' case, why not use a loop with a get/put > to the register set ? Loops are evil ;) Of course, you can also use regular load/store with auto-increment to save/restore registers (1 instruction per copy, plus setup). > > > > Maybe it would be wiser to put the memory address into the > > > > rightmost operand in *all* memory operations (load, store, > > > > cachemm, loadm and storem). Some instructions will always > > > > have the wrong operand order, though. > > > right. but i still prefer to leave the "pointer" field in the middle, > > > because it is the most usual case where it makes sense (at least for myself). > > Ok, then let it stay that way. After all, it's matter of taste, and > > it's MUCH easier to create machine code if the order of arguments > > in an assembler instruction corresponds to the order of slots in the > > instruction word. > right. But using BISON, one can easily swap operand orders. > replace "$2" with "$4" and vice versa. I'm doing that differently. There are too many instruction variants to handle each of them in its own grammar rule, and I wanted the parser to be more general anyway (that is, portable to other architectures). > > A simulator/debugger can really benefit from an elaborated binary format > > like ELF. It will have access to symbol names, line numbers and symbolic > > debugging information (if the compiler/assembler supports it)... > > > > Hexdumps? Nein danke :) > > "elaborated" sometimes becomes "utterly complex"... ELF is pretty clean once you're used to it (except the part that is responsible for dynamic linking -- but we don't need that from the beginning). And it's the binary format of choice for Linux. > > [...] > > > expansion/reduction is another problem but i think that the SHL unit can do this, > > > too. > > > > FP expansion is trivial, but FP reduction may trigger exceptions (or at > > least need rounding), and therefore has to be handled separately. > couldn't reduction be handled in a FP unit such as fadd ? There will probably be a `normalize-and-round' subunit that is shared by the FP units (or duplicated, for speed). [...] > > If there is enough room in the SHL unit, we can add a little logic that > > does it in one operation. I suggest we define the `widen' instruction > > as follows: > > the 6809 defined a funny opcode : "sex" for "sign extension" :*) > now i understan much more about the meaning of Life :-D Try `man sex' (if you have emacs installed ;) > > [s]widenb[s][.b|.d|.q] r2, r1 // 8->xx > > [s]widenw[s][.b|.d|.q] r2, r1 // 16->xx > > [s]widenq[s][.b|.d|.q] r2, r1 // 32->xx > > [s]widen[s][.b|.d|.q] r2, r1 // 64->xx > > > > that is, [.b|.d|.q] refers to the new size, `s-' means SIMD (as usual), > > and `-s' activates sign extension. We need only a single opcode (the > > source size can be encoded in the flag bits -- since the instruction > > uses only two registers and no immediate operand, we have plenty of them). > exactly. Minor correction: the syntax should be [s]widen[s][b|d|q][.b|.d|.q], that is, -s suffix before -b/-d/-q (source size). I already added that to my encoder :) CU on the bazaar, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 17 18:30:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3y-0000SB-00 for ; Sat, 18 Aug 2001 02:34:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:06 +0200 (CEST) Received: (qmail 25302 invoked by uid 0); 17 Aug 2001 16:31:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 16:31:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA15883 for ; Fri, 17 Aug 2001 12:31:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:31:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA15657 for f-cpu-list; Fri, 17 Aug 2001 12:31:05 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA15654 for ; Fri, 17 Aug 2001 12:31:02 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGUjb08375 for ; Fri, 17 Aug 2001 12:30:46 -0400 Received: from f-cpu.org (nas1-10.aub.club-internet.fr [195.36.202.10]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA07752 for ; Fri, 17 Aug 2001 18:30:59 +0200 (MET DST) Message-ID: <3B7D46B6.2475D4C1@f-cpu.org> Date: Fri, 17 Aug 2001 18:30:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> <3B7D3C77.6652E297@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Hans Summers wrote: > > I've spent the last 7 years writing financial applications, and have NEVER > > seen or heard of BCD arithmetic being used. I always use 64-bit > > representation mostly because it is most standard. Yes, you will get > > rounding errors but you need a heck of a lot of calculations for the > > rounding errors in the 16'th decimal place to add up to anything of any > > significance. > > I suspect most programs that do acounting and other stuff for small > financial applications ended up being written in languages that did not > support decimal format.Note many database style languages may calculate > in decimal character data. Not too long ago floating point was 32 bit math > still done in software on 386's. 64/80 bit math was not a > option back then. Ben. the 8087 was one of the first 80-bit IEEE computing chips. with a 80387, you could do 64-bit quite quickly. > PS. Any idea when you web page will be back on line ,Hans? i have redirected the webring to one subpage of his site, http://www.hanssummers.com/computers/fcpu/scheduler.htm where he has put the appropriate links. before he posted this URL, his page was deactivated from the ring. thanks for the update. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From patrick.pelgrims@pandora.be Fri Aug 17 18:49:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3z-0000SB-00 for ; Sat, 18 Aug 2001 02:34:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:07 +0200 (CEST) Received: (qmail 26327 invoked by uid 0); 17 Aug 2001 16:47:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 17 Aug 2001 16:47:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA16346 for ; Fri, 17 Aug 2001 12:47:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:47:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA16104 for f-cpu-list; Fri, 17 Aug 2001 12:47:37 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA16101 for ; Fri, 17 Aug 2001 12:47:36 -0400 Received: from pop3.telenet-ops.be (pop3.telenet-ops.be [195.130.132.40]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGlJb08710 for ; Fri, 17 Aug 2001 12:47:19 -0400 Received: from pandora.be (D5E04459.kabel.telenet.be [213.224.68.89]) by pop3.telenet-ops.be (Postfix) with ESMTP id 70DEC9BB39 for ; Fri, 17 Aug 2001 18:47:34 +0200 (CEST) Message-ID: <3B7D4B0A.C3CD7303@pandora.be> Date: Fri, 17 Aug 2001 18:49:14 +0200 From: Patrick Pelgrims X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <3B7D4448.E487FE0@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > hi, > > just a quick answer. > > Juergen Goeritz wrote: > > > > On Fri, 17 Aug 2001, Hans Summers wrote: > > > Could someone explain to me why 128-bit FP is desireable? I am struggling > > > here to think of an application which needs 30 decimal places of precision > > > (or whatever it is). In fact I'd go as far as to suggest that in most cases > > > 32-bit FP would be sufficient. Chip designers tend to dream of having a > > > 128-bit or 256-bit processor etc., but without reference to the real world > > > which doesn't need (actually can't make good use of) such high precision FP. > > > Expanding the word size won't deliver a performance enhancement. My belief > > > is the only way such large word sizes make any kind of sense is in the > > > contect of SIMD, where the large word size is effectively a parrelisation. > > > > Ah, I have the same opinion about this theme. You don't really > > need a higher precision than 64 bit. Maybe that will change for > > galaxy navigation in the future but until now 32 bit are good > > (and fast) for most cases. I would rather implement some 32 bit > > pipelined floating point instructions than go for a dedicated > > fpu anyway... ;-) > > 32 bits is fine as long as > - your algorithm is correctly designed so numerical stability is ensured "by design" > - the precision of the measuraments is below the precision of the number > > 64 bit can look as an overkill in a lot of applications. > however, high precision is required when > - your equation/algorithm creates values that are concentrated in > one small fraction of the precision (and you don't know where, so you can't > optimize the equation) > - your algorithm has to run millions of loops over the same data without > rounding artifacts. > - your algorithm is HIGHLY NON LINEAR and a meaningless rounding error > can result in completely false errors. > > examples of things that are ok for 32 bits FP : > spectrum analysis, filtering... > (sound/image processing, machine control...) > > examples of things that need 64 bits : > 3-body (or more) interaction, nuclear physics... > > I have once seen a picture of a 3-D representation of Lorenz's attractor, > computed by different machines. even though most machines were (claimed) IEEE, > there are differences. the CRAY diagram differed most (non-IEEE). > so yes : numerical stability and precision are coupled. Indeed. The person who has written a program to calculate the number PI has found some bugs in the IEEE calculation unit !! Mr. Cray was very amazed ! > > > JG > > Ekkehard Morgenstern wrote: > > > Ah, I have the same opinion about this theme. You don't really > > > need a higher precision than 64 bit. Maybe that will change for > > > galaxy navigation in the future but until now 32 bit are good > > > (and fast) for most cases. > > > > Actually, floating-point is too imprecise for ANY precision calculation. > > There are lots of numbers that can't be encoded into floating-point values. > > > > The bits in the mantissa are encoded as follows, for example: > > - bit 0: 1/2: 0.5 > > - bit 1: 1/4: 0.25 > > - bit 2: 1/8: 0.125 > > - bit 3: 1/16: 0.0625 > > > > and so on. By setting the bits, you're adding up the fractions. > > > > So, for example with financial computing, floating-point is a big no-no, > > otherwise you end up with respresentation and rounding errors. > > > > Any precision computing does not use floating-point. BCD string arithmetic > > (as known from COBOL and FORTRAN) is most commonly used for these > > tasks. > > > > So, it doesn't really matter how precise the FP is, but the finer the > > better, > > of course. It would extend the number of applications for the CPU, since > > sometimes it's desirable to sacrifice the precision for the sake of speed. > > > > On mainframes, there are AFAIK some applications that use custom code > > to do as much arithmetic in integer or FP as possible, and that use > > fixed-point > > or BCD otherwise. > > > > 32, 64 and 80 bit floating-point are standard nowadays, so these should be > > supported to avoid software emulation (preferrably IEEE standard > > compliant). > > concerning precision : some weeks ago, we discussed about an arbitrary > precision computation package. if extreme acuracy is required, it is one > way to go. > > multi-precision computation (with int operations) should be no problem > on F-CPU. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- Patrick Pelgrims Cellular: +32 478 98 45 35 Fax: +32 2 340 10 21 Home: +32 15 24 58 53 Work: +32 2 340 10 20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Aug 17 18:46:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu40-0000SB-00 for ; Sat, 18 Aug 2001 02:34:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:08 +0200 (CEST) Received: (qmail 12842 invoked by uid 0); 17 Aug 2001 16:48:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Aug 2001 16:48:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA16614 for ; Fri, 17 Aug 2001 12:48:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:48:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA16372 for f-cpu-list; Fri, 17 Aug 2001 12:48:02 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA16369 for ; Fri, 17 Aug 2001 12:48:01 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGljb08736 for ; Fri, 17 Aug 2001 12:47:45 -0400 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA26110 for ; Fri, 17 Aug 2001 10:47:56 -0600 (MDT) Message-ID: <3B7D4A7C.E04D93DA@jetnet.ab.ca> Date: Fri, 17 Aug 2001 10:46:52 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> <3B7D3C77.6652E297@jetnet.ab.ca> <3B7D46B6.2475D4C1@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > the 8087 was one of the first 80-bit IEEE computing chips. > with a 80387, you could do 64-bit quite quickly. That was one nice feature ( very few mind you ) of the intel chips. Still most people I think did not have a math co-processer until after they got in the late 386/early 486 era. Most number crunching stuff needed lots of memory too. Raytracing comes to mind. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 19:08:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu41-0000SB-00 for ; Sat, 18 Aug 2001 02:34:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:09 +0200 (CEST) Received: (qmail 1782 invoked by uid 0); 17 Aug 2001 17:08:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 17 Aug 2001 17:08:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA17088 for ; Fri, 17 Aug 2001 13:08:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 17:08:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA16845 for f-cpu-list; Fri, 17 Aug 2001 13:08:25 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA16842 for ; Fri, 17 Aug 2001 13:08:24 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HH87b09260 for ; Fri, 17 Aug 2001 13:08:07 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id NAA06718 for ; Fri, 17 Aug 2001 13:02:30 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id NAA23140 for ; Fri, 17 Aug 2001 13:08:17 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 18:08:18 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F031@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 18:08:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi Ben, > PS. Any idea when you web page will be back on line ,Hans? I have some copyright problems I am resolving. But you can still get in, just not through the front door: e.g. http://www.hanssummers.com/computers/computers.htm. From there you can click "Computers", "Electronics" or "Radio" at the top of the screen to get to the 3 subsections. Or see http://www.hanssummers.com/electronics/clocks/nixie/index.htm for my giant nixie clock project (full details to follow when I have time). Hans ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Fri Aug 17 19:10:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu41-0000SB-01 for ; Sat, 18 Aug 2001 02:34:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:09 +0200 (CEST) Received: (qmail 31226 invoked by uid 0); 17 Aug 2001 17:11:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 17 Aug 2001 17:11:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA17370 for ; Fri, 17 Aug 2001 13:11:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 17:10:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA17129 for f-cpu-list; Fri, 17 Aug 2001 13:10:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA17126 for ; Fri, 17 Aug 2001 13:10:44 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HHASb09336 for ; Fri, 17 Aug 2001 13:10:28 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id NAA06836 for ; Fri, 17 Aug 2001 13:04:50 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id NAA23239 for ; Fri, 17 Aug 2001 13:10:38 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 18:10:38 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F032@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point? Date: Fri, 17 Aug 2001 18:10:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > PS. Any idea when you web page will be back on line ,Hans? > i have redirected the webring to one subpage of his site, > http://www.hanssummers.com/computers/fcpu/scheduler.htm > where he has put the appropriate links. > before he posted this URL, his page was deactivated from the ring. > thanks for the update. Thanks for that. I'm on holiday now until 29'th Aug. > WHYGEE ------------------ Hans Summers http://www.HansSummers.Com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 18 05:04:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu42-0000SB-00 for ; Sat, 18 Aug 2001 02:34:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:10 +0200 (CEST) Received: (qmail 18238 invoked by uid 0); 17 Aug 2001 20:56:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 17 Aug 2001 20:56:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA20576 for ; Fri, 17 Aug 2001 16:56:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 20:55:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA20332 for f-cpu-list; Fri, 17 Aug 2001 16:55:39 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA20329 for ; Fri, 17 Aug 2001 16:55:38 -0400 Received: from localhost.localdomain (nas5-149.vlt.club-internet.fr [194.158.107.149]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HKtJb13232 for ; Fri, 17 Aug 2001 16:55:19 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 543C215D7 for ; Fri, 17 Aug 2001 23:04:43 -0400 (EDT) Message-ID: <3B7DDB4B.911EE4A1@ifrance.com> Date: Fri, 17 Aug 2001 23:04:43 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > (with this flood of emails, i wasn't able to compile anything today, > not even MR's preprocessors... so don't worry if i stay mute awhile :-D) > > nicO wrote: > > Yann Guidon a écrit : > > > nicO wrote: > > > > >Use semaphores that are mapped in the SRs ! > > > > In all case, we need to write something in memory or to touch something > > > > in the VM unit. > > > why ? a semaphore is a semaphore, a flag if you want. > > > whether it is implemented in memory or with a dedicated HW in > > > a different addressign space, is "implementation dependent". > > > > In all case, you have one memory access + 1 or more port to the outside. > maybe not. I am thinking about a separate and dedicated port in the chip, > that will communicate to a central FPGA or ASIC that will perform the > arbitration. a dozen of signal pins do the trick. > Yep, it's 12 pins more for a very short use. We add the chipset inside the fcpu to avoid an other chip and you want to introduice another chip ! This chip to be fast will need as many port as cpu. In all case, this component must be design. In actual chip design, we don't make difference with system boad and the cpu chip. So if we could put this componant inside the fcpu we will gain a lot of money ! Soc (system-on-chip) are not just fashon. It's how todays chip are made. Nowdays, you would never see an ARM in a chip alone, NEVER. StrongARM are _the_ only exception. Before, you will choose between chips to make your system. Nowdays, if you want to make more than 100 000 pieces you will choose the good IP and then make your system. Most of it on the same die for cost and power saving problem (less pin, so less power transistor, ...). So my problem concern our licence, the GPL. We say it's ok ! Because we couldn't mix GPL code and private code, but we could mix after at the layout level. The problem is that isn't very usefull for a compagny to do it at this level. LEON was written in LGPL to be used with the meiko floating point unit, very easly. In your case, to make a Chip (or a SOC, it the same !), all vhdl code must be in GPL. All the code ! Which compagny would make a fcpu if it couldn't add something to create more value than the other ? That said that we will never use all proprietary interface (IEEE1394, ethernet, USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low cost. Never forget that board=chip, todays. If the code stay in GPL, it will be very difficult for compagny not to release all it's code in GPL. I personnaly think it's too much to ask. We made a cpu not systems. A computer could be used in very different way what is in common with a numerical camera, an hard disk controleur, or a PDA. In each of this system, you could use a fcpu BUT, peripherals and interface could be very different (no need of LCD display port for the hard disk controleur). In SW, Linux and some software are in GPL but could be used with proprietary program. Lot of compagny want to sell solution with linux for embedded market, for example. This system work well, no code stolen, but you could sell something, so made a wide spread of the GPL code (Red hat, Mandrake are responsible to make linux so well known, never forget that !). In the case of the fcpu, where a compagny could make money ? By selling exactly the same chip than the other ? But no system is built like that, any more (no use in SoC)! So forget the use of the fcpu in wide spread use. It's still possible to change our licence because few people write code(whygee and Michael, that's all i think). I think that LGPL are more appropriate. > > Plus, you could add many problem for multicpu system. So there isn't any > > port dedicated to it, and shouldn't have ! Because it so tight to the > > OS, that we could have many compatibility problem in the futur. > if the SR interface is respected, it is transparent to the OS. > > > I think > > you thought to an implementation of SGI not really usual processor. > SGI Indigo and other similar machines have a central semaphore management > that does not pollute the memory system. > > > Today's µp implement semaphore with atomic read_modify_write > > instructions. > so what ? So you don't need special port ! > > > > > So it's just pushing the problem away ! > > > and if possible where it doesn't disturb us :-P > > > > > > the L/S unit is optimised to allow high bandwidth through > > > cache-line width packet transfers, accessing single bytes > > > in scattered order is a good way to "kill" your memory subsystem > > > and the speed of your synchronisation. > > > > You could add specific memory barrer (semaphore aren't so common!). > there is already a "barrier" ("serialize"). > the problem is that not only it stalls the pipeline, but it > also perturbates the memory system's behaviour. It is used only > in "critical" sections that deal with DMA or I/O for example > ("low speed" things). OTOH you would want your semaphore to be > effective in as few cycles as possible. when doing fine grained > multitasking and multiprocessing, the semaphore latency can become > the killer, especially in real-time. > > > > > More generaly, i find the text very agressive against Alpha.(the 2 first > > > > sentences of the text, for example). We should never forget that alpha > > > > work since 10 years and fcpu is in it's very beginning. So this kink of > > > > speech could make laught a futur investor in the fcpu, never forget > > > > that. > > > > > > i think that you know that i am not "agressive" and that i respect the > > > ALPHA. I have two expensive books about it and unfortunately no > > > Alpha server at home. > > > > > > We can still discuss whether Alpha is dead or not. CPQ will keep > > > Alpha alive artificially as long as IA64 is not a serious competitor. > > > that is enough for me : it's just marketing and financial manipulation, > > > the ALPHA engineers have a very reduced freedom of decision now, > > > because they know that it will be dropped after the 364. > > > > > > So i could say : Alpha is dead as much as F-CPU is alive. > > > it's time to learn alpha's lessons, i think. > > > > > > > the problem is the tone not the content. > > what would you write instead ? Avoid bads word. nicO > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 18 05:26:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu43-0000SB-00 for ; Sat, 18 Aug 2001 02:34:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:11 +0200 (CEST) Received: (qmail 8741 invoked by uid 0); 17 Aug 2001 21:17:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 17 Aug 2001 21:17:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA21452 for ; Fri, 17 Aug 2001 17:17:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 21:17:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA21208 for f-cpu-list; Fri, 17 Aug 2001 17:17:24 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA21205 for ; Fri, 17 Aug 2001 17:17:23 -0400 Received: from localhost.localdomain (nas5-149.vlt.club-internet.fr [194.158.107.149]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HLH4b13534 for ; Fri, 17 Aug 2001 17:17:05 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 5A4A115D7 for ; Fri, 17 Aug 2001 23:26:29 -0400 (EDT) Message-ID: <3B7DE065.E2304D7B@ifrance.com> Date: Fri, 17 Aug 2001 23:26:29 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F02D@po1-exch.lon.tudor.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hans Summers a écrit : > > > Hans Summers a écrit : > > > > > > > On Thu, Aug 16, 2001 at 01:49:27PM +0800, Glenn Alexander wrote: > > > > > Hi. This is my first post to this list. My background is as > > > > > a hardware technician, not a chip designer so bear with me. > > > > > > > > > > On Thursday 16 August 2001 03:41, you wrote: > > > > > > Michael Riepe a écrit : > > > > > > > > > > > > In sparc, there is no 80 bits float but 128 bits (2 > > > > > > registers used in the same time). We don't need 1 cycle > > > > > > multiplication so it could be done for the fcpu. > > > > > > > > > > I am thinking that taking the two-register approach might be > > > > > over-complicating matters. Since F-CPU is intended to later > > > > > be scaled above 64 bits, if someone wanted 128-bit floats > > > > > in the future they would impliment a 128-bit F-CPU. > > > > > Especially for the FC-0 and probably for the FC-1, KISS > > > > > (Keep It Simple for us Stupid people). > > > > > > > > 128-bit `quadruple precision' (like SPARC) is IMHO the > > > > way to go, but not in the FC0. For now, let's stick to > > > > 32-bit and 64-bit (with 80-bit `double extended' used > > > > inside the FP unit, to maintain IEEE compliance). > > > > > > > Could someone explain to me why 128-bit FP is desireable? I > > > am struggling > > > > It's very easy : almost all scientific calculation ! This include > > electric simulation (spice), aerodynamic, and so on... For a lot of > > mathematician 32 bits are a none sense ! For laughing, they said that > > they didn't want to take a plane any more ! Don't forget that every > > compiler defined float as double (64b) by default. With 32 > > bit there is too much rounding problem. The only killing application > > for it is the image processing. That's wy some of them want 256 > > bits fp number. > > Sorry I still can't see it. Which electric or aerodynamic simulations > require 30 decimal places of accuracy? > > In my scientific days I never came across a calculation needing anything > like 128 bits of precision. "Almost all scientific calculation" seems to me > like a huge exagerration. The limits of measurement are often to be measured > in percent, so why would you want to calcuate to 30 decimal places when you > can only measure to one or two? As for electrical simulation, when resistors > usually have a 1% error, and capacitors 5 or 10%, where are the 30 decimal > places needed? > > Fine, for the sake of comfort, use doubles (64-bit). And I am sure that some > areas genuinely need more precision. But I still believe the number of > applications requiring this much precision to be very small. For a general > purpose processor implementing 128-bit FP is a waste of resources. > 1) IEEE said to use only 64 bit never 32. 2) I have read in french scientist magasin ("la recherche") an article about fp number they give an exemple of "a suite" ( sum(S(N)) ). The limit is 6 by calculating by hand but every computer calculate 100 because of the rounding problem. 3) Have you heard about chaos ? That means that all the decimal from far away in the number come to the main value (imagine (a-b)*c, what happen if a and b are really clause to each other ? and if c is a great number ?). Most of the time, the calculation are made by recurence (french word ?). So rounding is a very hard problem. nicO > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 17 15:18:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu3v-0000SB-01 for ; Sat, 18 Aug 2001 02:34:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:03 +0200 (CEST) Received: (qmail 19874 invoked by uid 0); 17 Aug 2001 16:23:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 17 Aug 2001 16:23:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA15444 for ; Fri, 17 Aug 2001 12:23:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 16:23:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA15055 for f-cpu-list; Fri, 17 Aug 2001 12:23:08 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA15052 for ; Fri, 17 Aug 2001 12:23:06 -0400 Received: from tribble.stud.uni-hannover.de (root@a175.home.uni-hannover.de [130.75.232.175]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HGMlb08245 for ; Fri, 17 Aug 2001 12:22:47 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00720; Fri, 17 Aug 2001 15:18:51 +0200 Message-ID: <20010817151851.18840@thrai.stud.uni-hannover.de> Date: Fri, 17 Aug 2001 15:18:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: <0CFA3081B86BD311B37A00902762718F0152F029@po1-exch.lon.tudor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Fri, Aug 17, 2001 at 02:02:06PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 17, 2001 at 02:02:06PM +0200, Juergen Goeritz wrote: [...] > Was talking to Yann lately if it won't be possible > to design fast 32 bit floating point instructions > that keep the computed value as one part of a 64 bit > value pair, the other being the imprecise error of > this value due to the limitations of precision. Alternatively, upper and lower bounds of the exact value. > I am just getting into floating point methods though > and therefore can't tell today if this is possible > or not. But imagine you add/subtract/multiply/divide > a number and take care of the number unsharpness the > same instance. Forget about rounding problems, just > track them with the computation values. Go ahead, I'm listening :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 17 18:29:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu47-0000SB-00 for ; Sat, 18 Aug 2001 02:34:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:15 +0200 (CEST) Received: (qmail 29435 invoked by uid 0); 17 Aug 2001 23:35:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 17 Aug 2001 23:35:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA24617 for ; Fri, 17 Aug 2001 19:35:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 23:35:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA24342 for f-cpu-list; Fri, 17 Aug 2001 19:35:21 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA24339 for ; Fri, 17 Aug 2001 19:35:20 -0400 Received: from tribble.stud.uni-hannover.de (root@a033.home.uni-hannover.de [130.75.232.33]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HNZ2b14774 for ; Fri, 17 Aug 2001 19:35:03 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01862; Fri, 17 Aug 2001 18:29:20 +0200 Message-ID: <20010817182920.05704@thrai.stud.uni-hannover.de> Date: Fri, 17 Aug 2001 18:29:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Ekkehard Morgenstern on Fri, Aug 17, 2001 at 04:40:03PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 17, 2001 at 04:40:03PM +0200, Ekkehard Morgenstern wrote: [...] > Whether execution speed suffers from 128 bits, is a question of > FPU design, I think. > > For example, Intel's Pentium processor line uses lots of tables > to maximize the speed of multiplication and division operations. Yep, that's where the famous FDIV bug came from :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 18 08:27:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu48-0000SB-00 for ; Sat, 18 Aug 2001 02:34:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:16 +0200 (CEST) Received: (qmail 1524 invoked by uid 0); 18 Aug 2001 00:18:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Aug 2001 00:18:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA27113 for ; Fri, 17 Aug 2001 20:18:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 00:17:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA26871 for f-cpu-list; Fri, 17 Aug 2001 20:17:59 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA26868 for ; Fri, 17 Aug 2001 20:17:58 -0400 Received: from localhost.localdomain (nas5-149.vlt.club-internet.fr [194.158.107.149]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7I0Hdb14993 for ; Fri, 17 Aug 2001 20:17:39 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2774415D7 for ; Sat, 18 Aug 2001 02:27:03 -0400 (EDT) Message-ID: <3B7E0AB7.635A4194@ifrance.com> Date: Sat, 18 Aug 2001 02:27:03 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > nicO wrote: > > Yann Guidon a écrit : > > > > In all case, you have one memory access + 1 or more port to the outside. > > > maybe not. I am thinking about a separate and dedicated port in the chip, > > > that will communicate to a central FPGA or ASIC that will perform the > > > arbitration. a dozen of signal pins do the trick. > > > > > > > Yep, it's 12 pins more for a very short use. We add the chipset inside > > the fcpu to avoid an other chip and you want to introduice another chip > > ! This chip to be fast will need as many port as cpu. In all case, this > > component must be design. In actual chip design, we don't make > > difference with system boad and the cpu chip. So if we could put this > > componant inside the fcpu we will gain a lot of money ! Soc > > (system-on-chip) are not just fashon. It's how todays chip are made. > > Nowdays, you would never see an ARM in a chip alone, NEVER. StrongARM > > are _the_ only exception. > > > > Before, you will choose between chips to make your system. Nowdays, if > > you want to make more than 100 000 pieces you will choose the good IP > > and then make your system. Most of it on the same die for cost and power > > saving problem (less pin, so less power transistor, ...). > > let's sum it up : you don't want extra pins and i don't want to go through > memory. We can still try to "multiplex" the semaphores on the front side bus. > Note that in a mutli-CPU system with tens or hundreds of chips, because > you have to go through the "normal" path, the latency of the semaphores > will be this of the memory. > Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA can have > around 160 user pins, so we can connect more than ten CPU DIRECTLY to each > others. With a good PCB layout, a good topology, some VHDL and a few more > pins per CPU, we can increase the "cut" of the system and drastically reduce > the semaphore latency. So you add another chip it cost a lot. Why using a new port ? What does it add ? Nothing ! Just few more problem ! Canonical CPU are always put on one bus (or switch, it's the same). > There's no secret to performance : you get what you buy. And as you know, > the F-CPU is open-sourced so if you don't like it and if you target > single-CPU systems, you can simply remove the "feature" before funding > your batch. > > Concerning SoCs : would you call the P4, the G4, the US3, the R18K... SoC ? > maybe, maybe not. i stick to the definitions that were defined before i came. > i recently browsed the net and found that on f-cpu.tux.org : We could _never_ fight against G4, US3, ... because our design flow are semi-custom. So we lose 30% of the performance. We fight against R10000, SH4, SH5, ARM9-10, even a kind of PPC, all this are made for SOC only. If you want create a complete new computer never forget what happen to Next. they were the best computer during there life, but now is dead : too new ! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The Freedom CPU ISA and Register Organization > Andrew D. Balsa (maintainer/coordinator) > Rev. 0.0.2, 24 September 1998 > <> > 3. Mission statement > > The mission of the Freedom Project is to develop a new high-performance > 64-bit CPU architecture, suitable for Personal Workstation use, and to > implement this architecture in the available process technology. > <> > It is perhaps useful to mention development issues that are not part of > the Freedom Project, e.g.: > * Develop a new microcontroller-type 8, 12, 14 or 16-bit microprocessor > (e.g. PIC devices). Reason: outside the scope of the project. > * Develop yet another 32-bit RISC processor for low-power/low cost > embedded applications (e.g. ARM). Reason: there is an infinite > variety of such processors on the market now, with excellent characteristics. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > "SoC trend" or not, the goal was not to make a "microcontroller" (old > denomination) or an "integrated controller", but a CPU (Central Processing > Unit) for PC/Workstation. > > > So my problem concern our licence, the GPL. We say it's ok ! Because we > > couldn't mix GPL code and private code, but we could mix after at the > > layout level. The problem is that isn't very usefull for a compagny to > > do it at this level. LEON was written in LGPL to be used with the meiko > > floating point unit, very easly. > > Our goal is not to make a Nth Sparc clone or a LEON. > it is not either our goal to use Meiko's FPU. > Btw, have a look at Opencores.org : they have already a FPU > for add/mul. > I know it's very slow (60 Mhz compare to 450 Mhz for michael's mul unit) > > In your case, to make a Chip (or a SOC, it the same !), all vhdl code > > must be in GPL. All the code ! Which compagny would make a fcpu if it > > couldn't add something to create more value than the other ? > > Our goal is not to let "companies" make money "for free" with our work. > If they want to play the faire game, they use the GPL. If they want to > make more value than others, they still have to respect the GPL. > My understanding of what the LGPL would do is : companies will not > respect the architecture and add non-standard extensions. It may be > "worth" for an individual company but it's not a benefit for everybody. > _NO_ ! LGPL just said you could _link_ with proprietary code. If you touch the fcpu it-self, it's like touching GPL code ! You absolutely can't touch the code as you want ! (that's the goal of LGPL) > > That said > > that we will never use all proprietary interface (IEEE1394, ethernet, > > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low > > cost. Never forget that board=chip, todays. > > again : look at opencores : they have an increasing number of free cores. > Yes, but what about IP right ?...What about the choice ? > > If the code stay in GPL, it will be very difficult for compagny not to > > release all it's code in GPL. I personnaly think it's too much to ask. > Our goal is not to be "kind" with companies, to the point that they > will benefit from our work for nothing. Others would call this a > "fucked up business plan". Once they will fabricate the chips, what > will they do then ? I do not ask for money, i simply ask for the respect > of my work and of my copyright. I do not want to promote captive > and proprietary work. Otherwise i would work for Sun/Intel/IBM > and drop F-CPU. > > > We made a cpu not systems. A computer could be used in very different > > way what is in common with a numerical camera, an hard disk controleur, > > or a PDA. In each of this system, you could use a fcpu BUT, peripherals > > and interface could be very different (no need of LCD display port for > > the hard disk controleur). > > IMHO, a F-CPU would consume too much power and silicon for a digital camera ;-) > (in today's standards). > fcpu will be finish in 2 years, so... > > In SW, Linux and some software are in GPL but could be used with > > proprietary program. > and vice versa : Emacs runs under Windows, for example. > But concerning our case : it is simply a matter of tools. > i don't want to change my mind simply because others don't do their > work at making their product work. > > > Lot of compagny want to sell solution with linux > > for embedded market, for example. This system work well, no code stolen, > > but you could sell something, so made a wide spread of the GPL code (Red > > hat, Mandrake are responsible to make linux so well known, never forget > > that !). > > What RedHat and Mandrake do (apart from playing with stocks) is service > around, not on, what they distribute. They distribute, customize, > But that the problem ! How would you customise fcpu with GPL ? For exemple, suse couldn't make a priorietary distribution of the fcpu. If a distrib could be see as a "chip". That's the problem. With the current licence system, i'm afraid that no compagny will invest an euro in the project. But we need some compagny to produice chips, to make the fcpu alive. In SW GPl allow to run gpl program and proprietary program. How do you do that in HW ? > > In the case of the fcpu, where a compagny could make money ? By selling > > exactly the same chip than the other ? But no system is built like that, > > any more (no use in SoC)! So forget the use of the fcpu in wide spread use. > > please tell me : why are compnies still making 74xxx devices ? > look at catalogs ! (ie Radiospares/Arrow/Radioshacks...) > Why do companies produce the "same" part numbers ??? > one will emphasize on the package (SOP, DIL, ...), the other > will provide more diversity, another will reduce the power consumption, > another will increase the speed, another has more marketing > and better fundries... and you know what ? even though they produce > "the same thing" these companies are still in business ;-P > Haven't you seen that that kind of chip are almost always made by the same compagny (ST for power product,...). It's old line of product still in production, not new one. The catalog that you speak are for PME of 10 people who produice very few number of pieces for a product, it's not serious for "great public" for exemple. (try to buy a big fpga with radiospare or Farnell !) > Even with a single source code, you can make a large number of > variations. the resulting F-CPU can be customized without even > having to redistribute the source files, simply because > f-cpu_config.vhdl will have a few changed lines. Use a different > compiler/synthesis tool, go to another fundry, hire more or less > people and the product will be more or less expensive with more > or less performance. > I don't speak about the fcpu it-self, but all peripheral put beside. Imagine an LCD controller for example for PDA. This has nothing to do with the fcpu project ! Or imagine a compagny which made a video card, and put a 3D accelerator beside the fcpu. > > It's still possible to change our licence because few people write > > code(whygee and Michael, that's all i think). I think that LGPL are more > > appropriate. > > i am against, you are not. I will follow Michael Riepe's choice. > What does he vote for ? i do not want to spoil the situation > between you and me so i prefer to listen to others's choices. > As you know, i am not the reincarnation of the project. > The trend is to know how to interest chip maker in our project. That's all ! > > > > Today's µp implement semaphore with atomic read_modify_write > > > > instructions. > > > so what ? > > So you don't need special port ! > And what is your answer to the performance loss ? > do you have anything smarter ? > Memory access in an atomic way like is made by other cpu. That's enought. nicO > > > > > So i could say : Alpha is dead as much as F-CPU is alive. > > > > > it's time to learn alpha's lessons, i think. > > > > the problem is the tone not the content. > > > what would you write instead ? > > Avoid bads word. > i can change the first sentences if you want but i don't know > what i could write instead. > > @+ ! > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 18 00:40:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Xu45-0000SB-00 for ; Sat, 18 Aug 2001 02:34:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 Aug 2001 02:34:13 +0200 (CEST) Received: (qmail 15569 invoked by uid 0); 17 Aug 2001 22:41:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 17 Aug 2001 22:41:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA22805 for ; Fri, 17 Aug 2001 18:41:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 17 Aug 2001 22:41:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA22558 for f-cpu-list; Fri, 17 Aug 2001 18:41:02 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA22555 for ; Fri, 17 Aug 2001 18:41:01 -0400 Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7HMeib14343 for ; Fri, 17 Aug 2001 18:40:44 -0400 Received: from f-cpu.org (nas1-171.ras.club-internet.fr [195.36.192.171]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA10615 for ; Sat, 18 Aug 2001 00:40:56 +0200 (MET DST) Message-ID: <3B7D9D6C.8EBAB6ED@f-cpu.org> Date: Sat, 18 Aug 2001 00:40:44 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > > > In all case, you have one memory access + 1 or more port to the outside. > > maybe not. I am thinking about a separate and dedicated port in the chip, > > that will communicate to a central FPGA or ASIC that will perform the > > arbitration. a dozen of signal pins do the trick. > > > > Yep, it's 12 pins more for a very short use. We add the chipset inside > the fcpu to avoid an other chip and you want to introduice another chip > ! This chip to be fast will need as many port as cpu. In all case, this > component must be design. In actual chip design, we don't make > difference with system boad and the cpu chip. So if we could put this > componant inside the fcpu we will gain a lot of money ! Soc > (system-on-chip) are not just fashon. It's how todays chip are made. > Nowdays, you would never see an ARM in a chip alone, NEVER. StrongARM > are _the_ only exception. > > Before, you will choose between chips to make your system. Nowdays, if > you want to make more than 100 000 pieces you will choose the good IP > and then make your system. Most of it on the same die for cost and power > saving problem (less pin, so less power transistor, ...). let's sum it up : you don't want extra pins and i don't want to go through memory. We can still try to "multiplex" the semaphores on the front side bus. Note that in a mutli-CPU system with tens or hundreds of chips, because you have to go through the "normal" path, the latency of the semaphores will be this of the memory. Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA can have around 160 user pins, so we can connect more than ten CPU DIRECTLY to each others. With a good PCB layout, a good topology, some VHDL and a few more pins per CPU, we can increase the "cut" of the system and drastically reduce the semaphore latency. There's no secret to performance : you get what you buy. And as you know, the F-CPU is open-sourced so if you don't like it and if you target single-CPU systems, you can simply remove the "feature" before funding your batch. Concerning SoCs : would you call the P4, the G4, the US3, the R18K... SoC ? maybe, maybe not. i stick to the definitions that were defined before i came. i recently browsed the net and found that on f-cpu.tux.org : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Freedom CPU ISA and Register Organization Andrew D. Balsa (maintainer/coordinator) Rev. 0.0.2, 24 September 1998 <> 3. Mission statement The mission of the Freedom Project is to develop a new high-performance 64-bit CPU architecture, suitable for Personal Workstation use, and to implement this architecture in the available process technology. <> It is perhaps useful to mention development issues that are not part of the Freedom Project, e.g.: * Develop a new microcontroller-type 8, 12, 14 or 16-bit microprocessor (e.g. PIC devices). Reason: outside the scope of the project. * Develop yet another 32-bit RISC processor for low-power/low cost embedded applications (e.g. ARM). Reason: there is an infinite variety of such processors on the market now, with excellent characteristics. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "SoC trend" or not, the goal was not to make a "microcontroller" (old denomination) or an "integrated controller", but a CPU (Central Processing Unit) for PC/Workstation. > So my problem concern our licence, the GPL. We say it's ok ! Because we > couldn't mix GPL code and private code, but we could mix after at the > layout level. The problem is that isn't very usefull for a compagny to > do it at this level. LEON was written in LGPL to be used with the meiko > floating point unit, very easly. Our goal is not to make a Nth Sparc clone or a LEON. it is not either our goal to use Meiko's FPU. Btw, have a look at Opencores.org : they have already a FPU for add/mul. > In your case, to make a Chip (or a SOC, it the same !), all vhdl code > must be in GPL. All the code ! Which compagny would make a fcpu if it > couldn't add something to create more value than the other ? Our goal is not to let "companies" make money "for free" with our work. If they want to play the faire game, they use the GPL. If they want to make more value than others, they still have to respect the GPL. My understanding of what the LGPL would do is : companies will not respect the architecture and add non-standard extensions. It may be "worth" for an individual company but it's not a benefit for everybody. > That said > that we will never use all proprietary interface (IEEE1394, ethernet, > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low > cost. Never forget that board=chip, todays. again : look at opencores : they have an increasing number of free cores. > If the code stay in GPL, it will be very difficult for compagny not to > release all it's code in GPL. I personnaly think it's too much to ask. Our goal is not to be "kind" with companies, to the point that they will benefit from our work for nothing. Others would call this a "fucked up business plan". Once they will fabricate the chips, what will they do then ? I do not ask for money, i simply ask for the respect of my work and of my copyright. I do not want to promote captive and proprietary work. Otherwise i would work for Sun/Intel/IBM and drop F-CPU. > We made a cpu not systems. A computer could be used in very different > way what is in common with a numerical camera, an hard disk controleur, > or a PDA. In each of this system, you could use a fcpu BUT, peripherals > and interface could be very different (no need of LCD display port for > the hard disk controleur). IMHO, a F-CPU would consume too much power and silicon for a digital camera ;-) (in today's standards). > In SW, Linux and some software are in GPL but could be used with > proprietary program. and vice versa : Emacs runs under Windows, for example. But concerning our case : it is simply a matter of tools. i don't want to change my mind simply because others don't do their work at making their product work. > Lot of compagny want to sell solution with linux > for embedded market, for example. This system work well, no code stolen, > but you could sell something, so made a wide spread of the GPL code (Red > hat, Mandrake are responsible to make linux so well known, never forget > that !). What RedHat and Mandrake do (apart from playing with stocks) is service around, not on, what they distribute. They distribute, customize, > In the case of the fcpu, where a compagny could make money ? By selling > exactly the same chip than the other ? But no system is built like that, > any more (no use in SoC)! So forget the use of the fcpu in wide spread use. please tell me : why are compnies still making 74xxx devices ? look at catalogs ! (ie Radiospares/Arrow/Radioshacks...) Why do companies produce the "same" part numbers ??? one will emphasize on the package (SOP, DIL, ...), the other will provide more diversity, another will reduce the power consumption, another will increase the speed, another has more marketing and better fundries... and you know what ? even though they produce "the same thing" these companies are still in business ;-P Even with a single source code, you can make a large number of variations. the resulting F-CPU can be customized without even having to redistribute the source files, simply because f-cpu_config.vhdl will have a few changed lines. Use a different compiler/synthesis tool, go to another fundry, hire more or less people and the product will be more or less expensive with more or less performance. > It's still possible to change our licence because few people write > code(whygee and Michael, that's all i think). I think that LGPL are more > appropriate. i am against, you are not. I will follow Michael Riepe's choice. What does he vote for ? i do not want to spoil the situation between you and me so i prefer to listen to others's choices. As you know, i am not the reincarnation of the project. > > > Today's µp implement semaphore with atomic read_modify_write > > > instructions. > > so what ? > So you don't need special port ! And what is your answer to the performance loss ? do you have anything smarter ? > > > > So i could say : Alpha is dead as much as F-CPU is alive. > > > > it's time to learn alpha's lessons, i think. > > > the problem is the tone not the content. > > what would you write instead ? > Avoid bads word. i can change the first sentences if you want but i don't know what i could write instead. @+ ! > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 18 03:06:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMS-0002hO-00 for ; Sun, 19 Aug 2001 07:43:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:00 +0200 (CEST) Received: (qmail 26461 invoked by uid 0); 18 Aug 2001 01:07:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 18 Aug 2001 01:07:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA27986 for ; Fri, 17 Aug 2001 21:07:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 01:07:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA27636 for f-cpu-list; Fri, 17 Aug 2001 21:07:15 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA27632 for ; Fri, 17 Aug 2001 21:07:12 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7I16tb15303; Fri, 17 Aug 2001 21:06:56 -0400 Received: from f-cpu.org (nas1-103.aub.club-internet.fr [195.36.202.103]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA01961; Sat, 18 Aug 2001 03:07:08 +0200 (MET DST) Message-ID: <3B7DBFB0.5818DD4A@f-cpu.org> Date: Sat, 18 Aug 2001 03:06:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm , "hardlicense-discuss@seul.org" Subject: [f-cpu] about LGPL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i found a link on linuxfr about the "problems" caused by GNU licences : http://news.linuxprogramming.com/news_story.php3?ltsn=2001-08-16-002-06-LT skip the technical part about the new glibc and you'll find these selected snippets. " The most remarkable thing is that Stallman was all for this despite the clear motivation of commercialization. The reason: he finally got the provocative changes he made to the license through. In case you forgot or haven't heard, here's an excerpt: [...] For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. This $&%$& demands everything to be labeled in a way which credits him and he does not stop before making completely wrong statements like "its variant". I find this completely unacceptable and can assure everybody that I consider none of the code I contributed to glibc (which is quite a lot) to be as part of the GNU project and so a major part of what Stallman claims credit for is simply going away. This part has a morale, too, and it is almost the same: don't trust this person. Read the licenses carefully and rip out parts which give Stallman any possibility to influence your future. Phrases like [...] GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. just invites him to screw you when it pleases him. Rip out the "any later version" part and make your own decisions when to use a different license since otherwise he can potentially do you or your work harm. " and " The LGPL 2.1 issue was declared political and therefore in scope of the SC. I didn't feel this was reason enough to leave the project for good so I tolerated the changes. Especially since I didn't realize the mistake with the wording of the copyright statements which allow applying later license versions before. " one can discuss endlessly about the real reasons of the problems : is the author biased by his work at Red Hat or is RMS machiavelic ? however i think that the licence issue is still not closed. this text speaks about the LGPL in embarassing terms, but we have to verify that the same potential problems are not present in the GPL and the GFDL. After all : remember that the Freedom project has not started as belonging to the GNU project. I cannot start the work to design a new licence. We tried before and we did not succeed. However a new 'Free HW' licence is required to clear some problems that Nicolas Boulay points to, for example. help. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Aug 18 03:29:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMT-0002hO-00 for ; Sun, 19 Aug 2001 07:43:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:01 +0200 (CEST) Received: (qmail 6929 invoked by uid 0); 18 Aug 2001 01:30:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 18 Aug 2001 01:30:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA29643 for ; Fri, 17 Aug 2001 21:30:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 01:29:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA29387 for f-cpu-list; Fri, 17 Aug 2001 21:29:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA29384 for ; Fri, 17 Aug 2001 21:29:57 -0400 Received: from tribble.stud.uni-hannover.de (michael@a033.home.uni-hannover.de [130.75.232.33]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7I1Tab15589 for ; Fri, 17 Aug 2001 21:29:37 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA00809; Sat, 18 Aug 2001 03:29:49 +0200 Message-ID: <20010818032949.00614@thrai.stud.uni-hannover.de> Date: Sat, 18 Aug 2001 03:29:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7D9D6C.8EBAB6ED@f-cpu.org>; from Yann Guidon on Sat, Aug 18, 2001 at 12:40:44AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Aug 18, 2001 at 12:40:44AM +0200, Yann Guidon wrote: [...] > > It's still possible to change our licence because few people write > > code(whygee and Michael, that's all i think). I think that LGPL are more > > appropriate. > > i am against, you are not. I will follow Michael Riepe's choice. > What does he vote for ? i do not want to spoil the situation > between you and me so i prefer to listen to others's choices. > As you know, i am not the reincarnation of the project. Neither am I. I may change my mind in the future, but at the moment I see absolutely no reason to switch to LGPL. I want people to have access to the *complete* source code of their F-CPU (or derived work), not only to the public parts. It's a matter of philosophy, not business. The money makers will not like the idea, of course -- but do I have to care for them? Do I have to feed them? If they want to make Euros, they shall sit down and *work*. There is currently only a single reason why I might be convinced to switch to another license (and that does not automatically mean LGPL): if the GPL makes it impossible to produce F-CPU chips legally. We can cross that bridge when we reach it, so please stop this fruitless F-CPU license discussion now. I don't mind if other project members decide to put their sources under LGPL. We can convert the license to GPL for the F-CPU, and others may use the same sources under the terms of the LGPL (which is a win for them, while we lose nothing -- we don't even have to release our modifications under LGPL if we don't want to). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 18 03:52:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMT-0002hO-01 for ; Sun, 19 Aug 2001 07:43:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:01 +0200 (CEST) Received: (qmail 20869 invoked by uid 0); 18 Aug 2001 01:52:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 18 Aug 2001 01:52:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA30134 for ; Fri, 17 Aug 2001 21:52:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 01:52:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA29894 for f-cpu-list; Fri, 17 Aug 2001 21:52:34 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA29891 for ; Fri, 17 Aug 2001 21:52:33 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7I1qHb15748 for ; Fri, 17 Aug 2001 21:52:17 -0400 Received: from f-cpu.org (nas1-103.aub.club-internet.fr [195.36.202.103]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA28169 for ; Sat, 18 Aug 2001 03:52:26 +0200 (MET DST) Message-ID: <3B7DCA4C.BB512A48@f-cpu.org> Date: Sat, 18 Aug 2001 03:52:12 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <3B7E0AB7.635A4194@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > > hello, > > nicO wrote: > > > Yann Guidon a écrit : etc. > > let's sum it up : you don't want extra pins and i don't want to go through > > memory. We can still try to "multiplex" the semaphores on the front side bus. > > Note that in a mutli-CPU system with tens or hundreds of chips, because > > you have to go through the "normal" path, the latency of the semaphores > > will be this of the memory. > > Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA can have > > around 160 user pins, so we can connect more than ten CPU DIRECTLY to each > > others. With a good PCB layout, a good topology, some VHDL and a few more > > pins per CPU, we can increase the "cut" of the system and drastically reduce > > the semaphore latency. > > So you add another chip it cost a lot. Why using a new port ? What does > it add ? Nothing ! Just few more problem ! Canonical CPU are always put > on one bus (or switch, it's the same). and that's their problem. note that your "always" shows that you don't know alternatives, there are other computers that have different architectures than the SMP/MPP you learn at school. > > Concerning SoCs : would you call the P4, the G4, the US3, the R18K... SoC ? > > maybe, maybe not. i stick to the definitions that were defined before i came. > > i recently browsed the net and found that on f-cpu.tux.org : > We could _never_ fight against G4, US3, ... because our design flow are > semi-custom. So we lose 30% of the performance. We fight against R10000, > SH4, SH5, ARM9-10, even a kind of PPC, all this are made for SOC only. i do not "fight against", i "fight for" a free, ununcumbered platform. i do not work as SoC expert. i'm just a wannabe-computer-architect. > If you want create a complete new computer never forget what happen to > Next. they were the best computer during there life, but now is dead : > too new ! they didn't obviously found their market. and Next is not the only "fallen" company around. you should read the book i showed you :-) > > Our goal is not to make a Nth Sparc clone or a LEON. > > it is not either our goal to use Meiko's FPU. > > Btw, have a look at Opencores.org : they have already a FPU > > for add/mul. > I know it's very slow (60 Mhz compare to 450 Mhz for michael's mul unit) so either you use a slow foreign IP, or we redesign design it from scratch for speed, freedom and all the bells and whistles. > > > In your case, to make a Chip (or a SOC, it the same !), all vhdl code > > > must be in GPL. All the code ! Which compagny would make a fcpu if it > > > couldn't add something to create more value than the other ? > > > > Our goal is not to let "companies" make money "for free" with our work. > > If they want to play the faire game, they use the GPL. If they want to > > make more value than others, they still have to respect the GPL. > > My understanding of what the LGPL would do is : companies will not > > respect the architecture and add non-standard extensions. It may be > > "worth" for an individual company but it's not a benefit for everybody. > > _NO_ ! LGPL just said you could _link_ with proprietary code. If you > touch the fcpu it-self, it's like touching GPL code ! You absolutely > can't touch the code as you want ! (that's the goal of LGPL) remove your pink glases. Of course, i know that the f-cpu itseld must not modified. But you forget one detail : as you said, "the chip is the system" and what's the use of a system where the CPU is surrounded with "cores" that you can't access as a programmer ? LGPL does not tell anybody to release the API/ABI/interface of the other cores. So imagine i am Intel or whatever "big bad company". i come, d/l the code, add my "proprietary" stuff to the f-cpu core, such as the SDRAM controller, the interrupt controller and a secret backdoor or two. now, who will bug me about that ??? i try to have a long sighted vision, and i am not impressed by short- or middle-term issues about revenue or whatever. I have seen that the lack of long-term vision does to my own life and other's. I would like to find a good solution but IMHO it is not a good solution to help companies stay in their short-term revenue goals. > > > That said > > > that we will never use all proprietary interface (IEEE1394, ethernet, > > > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low > > > cost. Never forget that board=chip, todays. > > again : look at opencores : they have an increasing number of free cores. > Yes, but what about IP right ?...What about the choice ? what what ? you want everything ready for you ? you have access to the source, you have direct connexion to the authors, so instead of paying an inhouse engineer for customizing the external cores, you can pay (often "less" than the inhouse engineers, particularly in France where the taxes for working are very expensive) the original developper to do its works, and that's all. what more do you want ??? > > IMHO, a F-CPU would consume too much power and silicon for a digital camera ;-) > > (in today's standards). > fcpu will be finish in 2 years, so... ain't it a bit optimistic ? :-P > > > In SW, Linux and some software are in GPL but could be used with > > > proprietary program. > > and vice versa : Emacs runs under Windows, for example. > > But concerning our case : it is simply a matter of tools. > > i don't want to change my mind simply because others don't do their > > work at making their product work. i should add : these tools are extremely expensive and they work only in ideal cases ;-P > > > Lot of compagny want to sell solution with linux > > > for embedded market, for example. This system work well, no code stolen, > > > but you could sell something, so made a wide spread of the GPL code (Red > > > hat, Mandrake are responsible to make linux so well known, never forget > > > that !). > > > > What RedHat and Mandrake do (apart from playing with stocks) is service > > around, not on, what they distribute. They distribute, customize, > But that the problem ! How would you customise fcpu with GPL ? open EMACS and a good VHDL book. don't forget to read the manual, btw. > For exemple, suse couldn't make a priorietary distribution of the fcpu. that is their problem. > If a distrib could be see as a "chip". btw, their distribution is "proprietary" because they ADDED a non-gpl part at the critical place. this is what i want to prevent and avoid, and this is what WILL happen if LGPL is used. now, apart from being in bad terms with Lionel, does Suse's strategy help anybody ??? > That's the problem. With the current > licence system, i'm afraid that no compagny will invest an euro in the > project. But we need some compagny to produice chips, to make the fcpu > alive. don't worry for that. Japan, India, South America and other countries are already doing their own projects. I have contacts with several working groups. i'll let you know when i have news. My REAL worry is to have the core ready enough before october :-( > In SW GPl allow to run gpl program and proprietary program. How do you > do that in HW ? that is a problem that we have to solve. > > > In the case of the fcpu, where a compagny could make money ? By selling > > > exactly the same chip than the other ? But no system is built like that, > > > any more (no use in SoC)! So forget the use of the fcpu in wide spread use. > > please tell me : why are compnies still making 74xxx devices ? > > look at catalogs ! (ie Radiospares/Arrow/Radioshacks...) > > Why do companies produce the "same" part numbers ??? > > one will emphasize on the package (SOP, DIL, ...), the other > > will provide more diversity, another will reduce the power consumption, > > another will increase the speed, another has more marketing > > and better fundries... and you know what ? even though they produce > > "the same thing" these companies are still in business ;-P > > Haven't you seen that that kind of chip are almost always made by the > same compagny (ST for power product,...). It's old line of product still > in production, not new one. The catalog that you speak are for PME of 10 > people who produice very few number of pieces for a product, it's not > serious for "great public" for exemple. (try to buy a big fpga with > radiospare or Farnell !) however, if your previous statement was true, there would be only one single source for the 74xxx series. well, there are FPGAs, GAL, PAL and even resistors, condensers, connectors.... > > Even with a single source code, you can make a large number of > > variations. the resulting F-CPU can be customized without even > > having to redistribute the source files, simply because > > f-cpu_config.vhdl will have a few changed lines. Use a different > > compiler/synthesis tool, go to another fundry, hire more or less > > people and the product will be more or less expensive with more > > or less performance. > > I don't speak about the fcpu it-self, but all peripheral put beside. > Imagine an LCD controller for example for PDA. This has nothing to do > with the fcpu project ! Or imagine a compagny which made a video card, > and put a 3D accelerator beside the fcpu. so what ? do you want short-term or long-term POV ? > > > It's still possible to change our licence because few people write > > > code(whygee and Michael, that's all i think). I think that LGPL are more > > > appropriate. > > i am against, you are not. I will follow Michael Riepe's choice. > > What does he vote for ? i do not want to spoil the situation > > between you and me so i prefer to listen to others's choices. > > As you know, i am not the reincarnation of the project. > > The trend is to know how to interest chip maker in our project. That's all ! i don't think that it is a real problem. for DATE 2002, we'll go together speak to the companies' reprensentors. you will be surprised. but it's not the "big thing". they are only followers. > > > > > Today's µp implement semaphore with atomic read_modify_write > > > > > instructions. > > > > so what ? > > > So you don't need special port ! > > And what is your answer to the performance loss ? > > do you have anything smarter ? > Memory access in an atomic way like is made by other cpu. That's enought. i told you : FC0 handles memory accesses with 256-bit lines. if you do RMW you WASTE a lot of performance. but i think that you don't care. ok, i'll try to sleep. i hope that this licence discussion will not degenerate in a war, because i prefer to code : "make file, not war" (lame attempt at doing humor at 4am, sorry) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 18 18:46:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMY-0002hO-01 for ; Sun, 19 Aug 2001 07:43:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:06 +0200 (CEST) Received: (qmail 23538 invoked by uid 0); 18 Aug 2001 10:38:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Aug 2001 10:38:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA04675 for ; Sat, 18 Aug 2001 06:38:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 10:37:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA04432 for f-cpu-list; Sat, 18 Aug 2001 06:37:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA04429 for ; Sat, 18 Aug 2001 06:37:31 -0400 Received: from localhost.localdomain (nas25-64.vlt.club-internet.fr [195.36.224.64]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7IAb7b18934 for ; Sat, 18 Aug 2001 06:37:09 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8846E15D7; Sat, 18 Aug 2001 12:46:34 -0400 (EDT) Message-ID: <3B7E9BEA.EB6F5B73@ifrance.com> Date: Sat, 18 Aug 2001 12:46:34 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Yann Guidon , "f-cpu@seul.org" Subject: [f-cpu] Re: References: <3B7DCA4C.BB512A48@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > MIME-Version: 1.0 > To: f-cpu@seul.org > Subject: Re: [f-cpu] F-CPU vs ALPHA and licence > References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <3B7E0AB7.635A4194@ifrance.com> > Content-Type: text/plain; charset=iso-8859-1 > Sender: owner-f-cpu@seul.org > Reply-To: f-cpu@seul.org > X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu > Content-Transfer-Encoding: quoted-printable > X-MIME-Autoconverted: from 8bit to quoted-printable by moria.mit.edu id f7I1qOb15752 > > hello, > > nicO wrote: > > Yann Guidon a =E9crit : > > > hello, > > > nicO wrote: > > > > Yann Guidon a =E9crit : > etc. > > > > let's sum it up : you don't want extra pins and i don't want to go th= > rough > > > memory. We can still try to "multiplex" the semaphores on the front s= > ide bus. > > > Note that in a mutli-CPU system with tens or hundreds of chips, becau= > se > > > you have to go through the "normal" path, the latency of the semaphor= > es > > > will be this of the memory. > > > Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA c= > an have > > > around 160 user pins, so we can connect more than ten CPU DIRECTLY to= > each > > > others. With a good PCB layout, a good topology, some VHDL and a few = > more > > > pins per CPU, we can increase the "cut" of the system and drastically= > reduce > > > the semaphore latency. > >=20 > > So you add another chip it cost a lot. Why using a new port ? What does > > it add ? Nothing ! Just few more problem ! Canonical CPU are always put > > on one bus (or switch, it's the same). > and that's their problem. > note that your "always" shows that you don't know alternatives, > there are other computers that have different architectures than > the SMP/MPP you learn at school. > When you don't criticize my school, it's my books ! You're funny (jalous ?) ! As you, i read a lot on the net about a lot of architecture, and i please you to stop this kind of personal attack. I'm really feed up with it ! Don't you remember when i try to explain how COMA from sun work, and you don't understand a word ? It's just to refresh your mind a little. > > > Concerning SoCs : would you call the P4, the G4, the US3, the R18K...= > SoC ? > > > maybe, maybe not. i stick to the definitions that were defined before= > i came. > > > i recently browsed the net and found that on f-cpu.tux.org : > > We could _never_ fight against G4, US3, ... because our design flow ar= > e > > semi-custom. So we lose 30% of the performance. We fight against R10000= > , > > SH4, SH5, ARM9-10, even a kind of PPC, all this are made for SOC only. > > i do not "fight against", i "fight for" a free, ununcumbered platform. > i do not work as SoC expert. i'm just a wannabe-computer-architect. > Hum, so you never mind, if no fcpu will be made ? > > If you want create a complete new computer never forget what happen to > > Next. they were the best computer during there life, but now is dead : > > too new ! > > they didn't obviously found their market. > and Next is not the only "fallen" company around. > you should read the book i showed you :-) > Ooooh, you read book ? It's not only crap ? What a surprise from you ! > > > Our goal is not to make a Nth Sparc clone or a LEON. > > > it is not either our goal to use Meiko's FPU. > > > Btw, have a look at Opencores.org : they have already a FPU > > > for add/mul. > > I know it's very slow (60 Mhz compare to 450 Mhz for michael's mul unit= > ) > so either you use a slow foreign IP, or we redesign design it from scratc= > h > for speed, freedom and all the bells and whistles. > > > > > In your case, to make a Chip (or a SOC, it the same !), all vhdl co= > de > > > > must be in GPL. All the code ! Which compagny would make a fcpu if = > it > > > > couldn't add something to create more value than the other ? > > > > > > Our goal is not to let "companies" make money "for free" with our wor= > k. > > > If they want to play the faire game, they use the GPL. If they want t= > o > > > make more value than others, they still have to respect the GPL. > > > My understanding of what the LGPL would do is : companies will not > > > respect the architecture and add non-standard extensions. It may be > > > "worth" for an individual company but it's not a benefit for everybod= > y. > >=20 > > _NO_ ! LGPL just said you could _link_ with proprietary code. If you > > touch the fcpu it-self, it's like touching GPL code ! You absolutely > > can't touch the code as you want ! (that's the goal of LGPL) > > remove your pink glases. Of course, i know that the f-cpu itseld must not > modified. But you forget one detail : as you said, "the chip is the syste= > m" > and what's the use of a system where the CPU is surrounded with "cores" > that you can't access as a programmer ? LGPL does not tell anybody to > release the API/ABI/interface of the other cores. > And so ? Where is the problem ? There is a lot system where there isn't programmer at all ! (hard disk controler ?) Look around you programable product are rare, you only think about workstation, don't be so narrow minded. For me, it's the only market that is almost impossible to reach (old concept, dominated by the PC (so the cost will be much lower, see the price of the G4), market which didn't grow any more ). > So imagine i am Intel or whatever "big bad company". > i come, d/l the code, add my "proprietary" stuff to the f-cpu core, > such as the SDRAM controller, the interrupt controller and a secret > backdoor or two. now, who will bug me about that ??? > Where is the problem ? They always use our compiler, simulateur and emulateur ! Or even debugger and so one. The interrupt handler should be done by the fcpu project that sure. But if intel want to make a fcpu with a RDRAM controler, for me that's fine, where is the problem ? You could always run those program with SDRAM. Intel try to keep the compatibility with 8086 and you think that they want to brake the compatibility with the other line of product. > i try to have a long sighted vision, and i am not impressed by short- > or middle-term issues about revenue or whatever. I have seen that the lac= > k > of long-term vision does to my own life and other's. > I would like to find a good solution but IMHO it is not a good solution > to help companies stay in their short-term revenue goals. > I know you're a great visonnar and you will never failed or make a mistake. > > > > That said > > > > that we will never use all proprietary interface (IEEE1394, etherne= > t, > > > > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at = > low > > > > cost. Never forget that board=3Dchip, todays. > > > again : look at opencores : they have an increasing number of free co= > res. > > Yes, but what about IP right ?...What about the choice ? > what what ? > you want everything ready for you ? > you have access to the source, you have direct connexion to the authors, > so instead of paying an inhouse engineer for customizing the external > cores, you can pay (often "less" than the inhouse engineers, > particularly in France where the taxes for working are very expensive) > the original developper to do its works, and that's all. > what more do you want ??? > But no, you speak about the fcpu, i speak about peripherals : what is in common with fcpu and a numerical filter or specific buses ? > > > IMHO, a F-CPU would consume too much power and silicon for a digital = > camera ;-) > > > (in today's standards). > > fcpu will be finish in 2 years, so... > ain't it a bit optimistic ? :-P > > > > > In SW, Linux and some software are in GPL but could be used with > > > > proprietary program. > > > and vice versa : Emacs runs under Windows, for example. > > > But concerning our case : it is simply a matter of tools. > > > i don't want to change my mind simply because others don't do their > > > work at making their product work. > i should add : these tools are extremely expensive and they work > only in ideal cases ;-P=20 > No, i speak about tools like for embedded market, where the compagny write the code for it's own product. Or Oracle, from example, which has no equivalent in GPL world. > > > > Lot of compagny want to sell solution with linux > > > > for embedded market, for example. This system work well, no code st= > olen, > > > > but you could sell something, so made a wide spread of the GPL code= > (Red > > > > hat, Mandrake are responsible to make linux so well known, never fo= > rget > > > > that !). > > > > > > What RedHat and Mandrake do (apart from playing with stocks) is servi= > ce > > > around, not on, what they distribute. They distribute, customize, > > But that the problem ! How would you customise fcpu with GPL ? > open EMACS and a good VHDL book. > don't forget to read the manual, btw. > Stop kidding. I speak from a compagny point of view. If compagny couldn't make money with the core, it will dy because nobody will use it. > > For exemple, suse couldn't make a priorietary distribution of the fcpu. > that is their problem. > > > If a distrib could be see as a "chip". > btw, their distribution is "proprietary" because they ADDED > a non-gpl part at the critical place. this is what i want to prevent > and avoid, and this is what WILL happen if LGPL is used. > > now, apart from being in bad terms with Lionel, does Suse's > strategy help anybody ??? > > > That's the problem. With the current > > licence system, i'm afraid that no compagny will invest an euro in the > > project. But we need some compagny to produice chips, to make the fcpu > > alive. > > don't worry for that. > Japan, India, South America and other countries are already doing their > own projects. I have contacts with several working groups. > i'll let you know when i have news. > My REAL worry is to have the core ready enough before october :-( > > > In SW GPl allow to run gpl program and proprietary program. How do you > > do that in HW ? > that is a problem that we have to solve. > Oooh, you think ? That what i speak since 100 lines. > > > > In the case of the fcpu, where a compagny could make money ? By se= > lling > > > > exactly the same chip than the other ? But no system is built like = > that, > > > > any more (no use in SoC)! So forget the use of the fcpu in wide spr= > ead use. > > > please tell me : why are compnies still making 74xxx devices ? > > > look at catalogs ! (ie Radiospares/Arrow/Radioshacks...) > > > Why do companies produce the "same" part numbers ??? > > > one will emphasize on the package (SOP, DIL, ...), the other > > > will provide more diversity, another will reduce the power consumptio= > n, > > > another will increase the speed, another has more marketing > > > and better fundries... and you know what ? even though they produce > > > "the same thing" these companies are still in business ;-P > >=20 > > Haven't you seen that that kind of chip are almost always made by the > > same compagny (ST for power product,...). It's old line of product stil= > l > > in production, not new one. The catalog that you speak are for PME of 1= > 0 > > people who produice very few number of pieces for a product, it's not > > serious for "great public" for exemple. ( > > however, if your previous statement was true, there would be only > one single source for the 74xxx series. well, there are FPGAs, > GAL, PAL and even resistors, condensers, connectors.... > Yes you could, but it's old. and i repeat myself : try to buy a big fpga with radiospare or Farnell ! > > > Even with a single source code, you can make a large number of > > > variations. the resulting F-CPU can be customized without even > > > having to redistribute the source files, simply because > > > f-cpu_config.vhdl will have a few changed lines. Use a different > > > compiler/synthesis tool, go to another fundry, hire more or less > > > people and the product will be more or less expensive with more > > > or less performance. > >=20 > > I don't speak about the fcpu it-self, but all peripheral put beside. > > Imagine an LCD controller for example for PDA. This has nothing to do > > with the fcpu project ! Or imagine a compagny which made a video card, > > and put a 3D accelerator beside the fcpu. > > so what ? > do you want short-term or long-term POV ? > > > > > It's still possible to change our licence because few people write > > > > code(whygee and Michael, that's all i think). I think that LGPL are= > more > > > > appropriate. > > > i am against, you are not. I will follow Michael Riepe's choice. > > > What does he vote for ? i do not want to spoil the situation > > > between you and me so i prefer to listen to others's choices. > > > As you know, i am not the reincarnation of the project. > >=20 > > The trend is to know how to interest chip maker in our project. That's = > all ! > > i don't think that it is a real problem. > for DATE 2002, we'll go together speak to the companies' reprensentors. > you will be surprised. but it's not the "big thing". they are only follow= > ers. > > > > > > > Today's =B5p implement semaphore with atomic read_modify_write > > > > > > instructions. > > > > > so what ? > > > > So you don't need special port ! > > > And what is your answer to the performance loss ? > > > do you have anything smarter ? > > Memory access in an atomic way like is made by other cpu. That's enough= > t. > > i told you : FC0 handles memory accesses with 256-bit lines. > if you do RMW you WASTE a lot of performance. > but i think that you don't care. Yep, because semaphore aren't access so much and not inside inner loop. > > ok, i'll try to sleep. i hope that this licence discussion will not > degenerate in a war, because i prefer to code : "make file, not war" > (lame attempt at doing humor at 4am, sorry) > I think you had better to wait this morning to answer... nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 18 18:53:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMb-0002hO-00 for ; Sun, 19 Aug 2001 07:43:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:09 +0200 (CEST) Received: (qmail 8491 invoked by uid 0); 18 Aug 2001 10:44:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Aug 2001 10:44:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA05004 for ; Sat, 18 Aug 2001 06:44:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 10:43:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA04763 for f-cpu-list; Sat, 18 Aug 2001 06:43:54 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA04760 for ; Sat, 18 Aug 2001 06:43:53 -0400 Received: from localhost.localdomain (nas25-64.vlt.club-internet.fr [195.36.224.64]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7IAhZb18979 for ; Sat, 18 Aug 2001 06:43:36 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 408D015D7 for ; Sat, 18 Aug 2001 12:53:03 -0400 (EDT) Message-ID: <3B7E9D6F.4FA9B094@ifrance.com> Date: Sat, 18 Aug 2001 12:53:03 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <20010818032949.00614@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Aug 18, 2001 at 12:40:44AM +0200, Yann Guidon wrote: > [...] > > > It's still possible to change our licence because few people write > > > code(whygee and Michael, that's all i think). I think that LGPL are more > > > appropriate. > > > > i am against, you are not. I will follow Michael Riepe's choice. > > What does he vote for ? i do not want to spoil the situation > > between you and me so i prefer to listen to others's choices. > > As you know, i am not the reincarnation of the project. > > Neither am I. > > I may change my mind in the future, but at the moment I see absolutely no > reason to switch to LGPL. I want people to have access to the *complete* > source code of their F-CPU (or derived work), not only to the public > parts. It's a matter of philosophy, not business. The money makers will > not like the idea, of course -- but do I have to care for them? Do I have > to feed them? If they want to make Euros, they shall sit down and *work*. > > There is currently only a single reason why I might be convinced to > switch to another license (and that does not automatically mean LGPL): > if the GPL makes it impossible to produce F-CPU chips legally. We can > cross that bridge when we reach it, so please stop this fruitless F-CPU > license discussion now. > For me, the only think that a compagny could do is only to make the fcpu as we design it, only. So i think that too few compagny will find there way to produice an fcpu : what will be the difference with the other compagny : where is the added value ? Nowdays, the chip are SoC, so it bring together a lot of IP. In your case, fcpu couldn't be mixed with private IP to be part of big project (as PDA, or ...). And it's annoying me. nicO > I don't mind if other project members decide to put their sources under > LGPL. We can convert the license to GPL for the F-CPU, and others may > use the same sources under the terms of the LGPL (which is a win for them, > while we lose nothing -- we don't even have to release our modifications > under LGPL if we don't want to). > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 18 16:49:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMd-0002hO-00 for ; Sun, 19 Aug 2001 07:43:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:11 +0200 (CEST) Received: (qmail 6507 invoked by uid 0); 18 Aug 2001 14:50:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 18 Aug 2001 14:50:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA07868 for ; Sat, 18 Aug 2001 10:50:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 14:49:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA07617 for f-cpu-list; Sat, 18 Aug 2001 10:49:52 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA07614 for ; Sat, 18 Aug 2001 10:49:51 -0400 Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7IEnYb21381 for ; Sat, 18 Aug 2001 10:49:34 -0400 Received: from f-cpu.org (nas1-156.ras.club-internet.fr [195.36.192.156]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA12918 for ; Sat, 18 Aug 2001 16:49:47 +0200 (MET DST) Message-ID: <3B7E807D.B300EA13@f-cpu.org> Date: Sat, 18 Aug 2001 16:49:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs ALPHA and licence References: <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <20010818032949.00614@thrai.stud.uni-hannover.de> <3B7E9D6F.4FA9B094@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Michael Riepe a écrit : > > On Sat, Aug 18, 2001 at 12:40:44AM +0200, Yann Guidon wrote: > > [...] > > > > It's still possible to change our licence because few people write > > > > code(whygee and Michael, that's all i think). I think that LGPL are more > > > > appropriate. > > > i am against, you are not. I will follow Michael Riepe's choice. > > > What does he vote for ? i do not want to spoil the situation > > > between you and me so i prefer to listen to others's choices. > > > As you know, i am not the reincarnation of the project. > > > > Neither am I. > > > > I may change my mind in the future, but at the moment I see absolutely no > > reason to switch to LGPL. I want people to have access to the *complete* > > source code of their F-CPU (or derived work), not only to the public > > parts. It's a matter of philosophy, not business. The money makers will > > not like the idea, of course -- but do I have to care for them? Do I have > > to feed them? If they want to make Euros, they shall sit down and *work*. > > > > There is currently only a single reason why I might be convinced to > > switch to another license (and that does not automatically mean LGPL): > > if the GPL makes it impossible to produce F-CPU chips legally. We can > > cross that bridge when we reach it, so please stop this fruitless F-CPU > > license discussion now. > For me, the only think that a compagny could do is only to make the fcpu > as we design it, only. So i think that too few compagny will find there > way to produice an fcpu : what will be the difference with the other > compagny : where is the added value ? Nowdays, the chip are SoC, so it > bring together a lot of IP. In your case, fcpu couldn't be mixed with > private IP to be part of big project (as PDA, or ...). And it's annoying > me. I understand your disapointment. i wish there was a better licence, specifically for HW designs. the notion of "system" is too unclear and everybody has a different opinion. However, let's concentrate on the most important thing : make something that WORKS. we'll kill each others with the licences, but we have to make something "serious" first. If i find a better licence, i will change my mind. maybe we'll have to write our own licence, in the end. you know that i have nothing against the linking with other IP, the problem is the openness of these IPs which are a potential danger to the F-CPU. I'll try to ask specialists. But i have two priorities : - finish something that works (even a little) before october - have REAL vacations. and also sleep this afternoon. have a nice week-end everybody, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From philippe.trbich@free.fr Sat Aug 18 18:09:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMe-0002hO-01 for ; Sun, 19 Aug 2001 07:43:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:12 +0200 (CEST) Received: (qmail 21281 invoked by uid 0); 18 Aug 2001 16:09:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 18 Aug 2001 16:09:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA09135 for ; Sat, 18 Aug 2001 12:09:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 16:09:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA08891 for f-cpu-list; Sat, 18 Aug 2001 12:09:13 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA08888 for ; Sat, 18 Aug 2001 12:09:12 -0400 Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7IG8tb22022 for ; Sat, 18 Aug 2001 12:08:55 -0400 Received: from linux (nantes-2-a7-39-85.dial.proxad.net [213.228.39.85]) by postfix1-2.free.fr (Postfix) with SMTP id EB756AB13D for ; Sat, 18 Aug 2001 18:09:05 +0200 (CEST) Date: Sat, 18 Aug 2001 18:09:58 +0200 From: philippe.trbich@free.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Message-Id: <20010818180958.4ec9a066.philippe.trbich@free.fr> In-Reply-To: <3B7E9BEA.EB6F5B73@ifrance.com> References: <3B7DCA4C.BB512A48@f-cpu.org> <3B7E9BEA.EB6F5B73@ifrance.com> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 18 Aug 2001 12:46:34 -0400 nicO wrote: > Yann Guidon a écrit : > > > > MIME-Version: 1.0 > > To: f-cpu@seul.org > > Subject: Re: [f-cpu] F-CPU vs ALPHA and licence > > References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <3B7E0AB7.635A4194@ifrance.com> > > Content-Type: text/plain; charset=iso-8859-1 > > Sender: owner-f-cpu@seul.org > > Reply-To: f-cpu@seul.org > > X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu > > Content-Transfer-Encoding: quoted-printable > > X-MIME-Autoconverted: from 8bit to quoted-printable by moria.mit.edu id f7I1qOb15752 > > > > hello, > > > > nicO wrote: > > > Yann Guidon a =E9crit : > > > > hello, > > > > nicO wrote: > > > > > Yann Guidon a =E9crit : > > etc. > > > > > > let's sum it up : you don't want extra pins and i don't want to go th= > > rough > > > > memory. We can still try to "multiplex" the semaphores on the front s= > > ide bus. > > > > Note that in a mutli-CPU system with tens or hundreds of chips, becau= > > se > > > > you have to go through the "normal" path, the latency of the semaphor= > > es > > > > will be this of the memory. > > > > Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA c= > > an have > > > > around 160 user pins, so we can connect more than ten CPU DIRECTLY to= > > each > > > > others. With a good PCB layout, a good topology, some VHDL and a few = > > more > > > > pins per CPU, we can increase the "cut" of the system and drastically= > > reduce > > > > the semaphore latency. > > >=20 > > > So you add another chip it cost a lot. Why using a new port ? What does > > > it add ? Nothing ! Just few more problem ! Canonical CPU are always put > > > on one bus (or switch, it's the same). > > and that's their problem. > > note that your "always" shows that you don't know alternatives, > > there are other computers that have different architectures than > > the SMP/MPP you learn at school. > > > > When you don't criticize my school, it's my books ! You're funny (jalous > ?) ! As you, i read a lot on the net about a lot of architecture, and i > please you to stop this kind of personal attack. I'm really feed up with > it ! Don't you remember when i try to explain how COMA from sun work, > and you don't understand a word ? It's just to refresh your mind a > little. > > > > > Concerning SoCs : would you call the P4, the G4, the US3, the R18K...= > > SoC ? > > > > maybe, maybe not. i stick to the definitions that were defined before= > > i came. > > > > i recently browsed the net and found that on f-cpu.tux.org : > > > We could _never_ fight against G4, US3, ... because our design flow ar= > > e > > > semi-custom. So we lose 30% of the performance. We fight against R10000= > > , > > > SH4, SH5, ARM9-10, even a kind of PPC, all this are made for SOC only. > > > > i do not "fight against", i "fight for" a free, ununcumbered platform. > > i do not work as SoC expert. i'm just a wannabe-computer-architect. > > > > Hum, so you never mind, if no fcpu will be made ? > > > > If you want create a complete new computer never forget what happen to > > > Next. they were the best computer during there life, but now is dead : > > > too new ! > > > > they didn't obviously found their market. > > and Next is not the only "fallen" company around. > > you should read the book i showed you :-) > > > > Ooooh, you read book ? It's not only crap ? What a surprise from you ! > > > > > Our goal is not to make a Nth Sparc clone or a LEON. > > > > it is not either our goal to use Meiko's FPU. > > > > Btw, have a look at Opencores.org : they have already a FPU > > > > for add/mul. > > > I know it's very slow (60 Mhz compare to 450 Mhz for michael's mul unit= > > ) > > so either you use a slow foreign IP, or we redesign design it from scratc= > > h > > for speed, freedom and all the bells and whistles. > > > > > > > In your case, to make a Chip (or a SOC, it the same !), all vhdl co= > > de > > > > > must be in GPL. All the code ! Which compagny would make a fcpu if = > > it > > > > > couldn't add something to create more value than the other ? > > > > > > > > Our goal is not to let "companies" make money "for free" with our wor= > > k. > > > > If they want to play the faire game, they use the GPL. If they want t= > > o > > > > make more value than others, they still have to respect the GPL. > > > > My understanding of what the LGPL would do is : companies will not > > > > respect the architecture and add non-standard extensions. It may be > > > > "worth" for an individual company but it's not a benefit for everybod= > > y. > > >=20 > > > _NO_ ! LGPL just said you could _link_ with proprietary code. If you > > > touch the fcpu it-self, it's like touching GPL code ! You absolutely > > > can't touch the code as you want ! (that's the goal of LGPL) > > > > remove your pink glases. Of course, i know that the f-cpu itseld must not > > modified. But you forget one detail : as you said, "the chip is the syste= > > m" > > and what's the use of a system where the CPU is surrounded with "cores" > > that you can't access as a programmer ? LGPL does not tell anybody to > > release the API/ABI/interface of the other cores. > > > > And so ? Where is the problem ? There is a lot system where there isn't > programmer at all ! (hard disk controler ?) Look around you programable > product are rare, you only think about workstation, don't be so narrow > minded. For me, it's the only market that is almost impossible to reach > (old concept, dominated by the PC (so the cost will be much lower, see > the price of the G4), market which didn't grow any more ). > > > So imagine i am Intel or whatever "big bad company". > > i come, d/l the code, add my "proprietary" stuff to the f-cpu core, > > such as the SDRAM controller, the interrupt controller and a secret > > backdoor or two. now, who will bug me about that ??? > > > > Where is the problem ? They always use our compiler, simulateur and > emulateur ! Or even debugger and so one. The interrupt handler should be > done by the fcpu project that sure. But if intel want to make a fcpu > with a RDRAM controler, for me that's fine, where is the problem ? You > could always run those program with SDRAM. Intel try to keep the > compatibility with 8086 and you think that they want to brake the > compatibility with the other line of product. > > > i try to have a long sighted vision, and i am not impressed by short- > > or middle-term issues about revenue or whatever. I have seen that the lac= > > k > > of long-term vision does to my own life and other's. > > I would like to find a good solution but IMHO it is not a good solution > > to help companies stay in their short-term revenue goals. > > > > I know you're a great visonnar and you will never failed or make a > mistake. > > > > > > That said > > > > > that we will never use all proprietary interface (IEEE1394, etherne= > > t, > > > > > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at = > > low > > > > > cost. Never forget that board=3Dchip, todays. > > > > again : look at opencores : they have an increasing number of free co= > > res. > > > Yes, but what about IP right ?...What about the choice ? > > what what ? > > you want everything ready for you ? > > you have access to the source, you have direct connexion to the authors, > > so instead of paying an inhouse engineer for customizing the external > > cores, you can pay (often "less" than the inhouse engineers, > > particularly in France where the taxes for working are very expensive) > > the original developper to do its works, and that's all. > > what more do you want ??? > > > > But no, you speak about the fcpu, i speak about peripherals : what is in > common with fcpu and a numerical filter or specific buses ? > > > > > IMHO, a F-CPU would consume too much power and silicon for a digital = > > camera ;-) > > > > (in today's standards). > > > fcpu will be finish in 2 years, so... > > ain't it a bit optimistic ? :-P > > > > > > > In SW, Linux and some software are in GPL but could be used with > > > > > proprietary program. > > > > and vice versa : Emacs runs under Windows, for example. > > > > But concerning our case : it is simply a matter of tools. > > > > i don't want to change my mind simply because others don't do their > > > > work at making their product work. > > i should add : these tools are extremely expensive and they work > > only in ideal cases ;-P=20 > > > > No, i speak about tools like for embedded market, where the compagny > write the code for it's own product. Or Oracle, from example, which has > no equivalent in GPL world. > > > > > > Lot of compagny want to sell solution with linux > > > > > for embedded market, for example. This system work well, no code st= > > olen, > > > > > but you could sell something, so made a wide spread of the GPL code= > > (Red > > > > > hat, Mandrake are responsible to make linux so well known, never fo= > > rget > > > > > that !). > > > > > > > > What RedHat and Mandrake do (apart from playing with stocks) is servi= > > ce > > > > around, not on, what they distribute. They distribute, customize, > > > But that the problem ! How would you customise fcpu with GPL ? > > open EMACS and a good VHDL book. > > don't forget to read the manual, btw. > > > > Stop kidding. I speak from a compagny point of view. If compagny > couldn't make money with the core, it will dy because nobody will use > it. > > > > For exemple, suse couldn't make a priorietary distribution of the fcpu. > > that is their problem. > > > > > If a distrib could be see as a "chip". > > btw, their distribution is "proprietary" because they ADDED > > a non-gpl part at the critical place. this is what i want to prevent > > and avoid, and this is what WILL happen if LGPL is used. > > > > now, apart from being in bad terms with Lionel, does Suse's > > strategy help anybody ??? > > > > > That's the problem. With the current > > > licence system, i'm afraid that no compagny will invest an euro in the > > > project. But we need some compagny to produice chips, to make the fcpu > > > alive. > > > > don't worry for that. > > Japan, India, South America and other countries are already doing their > > own projects. I have contacts with several working groups. > > i'll let you know when i have news. > > My REAL worry is to have the core ready enough before october :-( > > > > > In SW GPl allow to run gpl program and proprietary program. How do you > > > do that in HW ? > > that is a problem that we have to solve. > > > > Oooh, you think ? That what i speak since 100 lines. > > > > > > In the case of the fcpu, where a compagny could make money ? By se= > > lling > > > > > exactly the same chip than the other ? But no system is built like = > > that, > > > > > any more (no use in SoC)! So forget the use of the fcpu in wide spr= > > ead use. > > > > please tell me : why are compnies still making 74xxx devices ? > > > > look at catalogs ! (ie Radiospares/Arrow/Radioshacks...) > > > > Why do companies produce the "same" part numbers ??? > > > > one will emphasize on the package (SOP, DIL, ...), the other > > > > will provide more diversity, another will reduce the power consumptio= > > n, > > > > another will increase the speed, another has more marketing > > > > and better fundries... and you know what ? even though they produce > > > > "the same thing" these companies are still in business ;-P > > >=20 > > > Haven't you seen that that kind of chip are almost always made by the > > > same compagny (ST for power product,...). It's old line of product stil= > > l > > > in production, not new one. The catalog that you speak are for PME of 1= > > 0 > > > people who produice very few number of pieces for a product, it's not > > > serious for "great public" for exemple. ( > > > > however, if your previous statement was true, there would be only > > one single source for the 74xxx series. well, there are FPGAs, > > GAL, PAL and even resistors, condensers, connectors.... > > > > Yes you could, but it's old. and i repeat myself : try to buy a big fpga > with radiospare or Farnell ! > > > > > Even with a single source code, you can make a large number of > > > > variations. the resulting F-CPU can be customized without even > > > > having to redistribute the source files, simply because > > > > f-cpu_config.vhdl will have a few changed lines. Use a different > > > > compiler/synthesis tool, go to another fundry, hire more or less > > > > people and the product will be more or less expensive with more > > > > or less performance. > > >=20 > > > I don't speak about the fcpu it-self, but all peripheral put beside. > > > Imagine an LCD controller for example for PDA. This has nothing to do > > > with the fcpu project ! Or imagine a compagny which made a video card, > > > and put a 3D accelerator beside the fcpu. > > > > so what ? > > do you want short-term or long-term POV ? > > > > > > > It's still possible to change our licence because few people write > > > > > code(whygee and Michael, that's all i think). I think that LGPL are= > > more > > > > > appropriate. > > > > i am against, you are not. I will follow Michael Riepe's choice. > > > > What does he vote for ? i do not want to spoil the situation > > > > between you and me so i prefer to listen to others's choices. > > > > As you know, i am not the reincarnation of the project. > > >=20 > > > The trend is to know how to interest chip maker in our project. That's = > > all ! > > > > i don't think that it is a real problem. > > for DATE 2002, we'll go together speak to the companies' reprensentors. > > you will be surprised. but it's not the "big thing". they are only follow= > > ers. > > > > > > > > > Today's =B5p implement semaphore with atomic read_modify_write > > > > > > > instructions. > > > > > > so what ? > > > > > So you don't need special port ! > > > > And what is your answer to the performance loss ? > > > > do you have anything smarter ? > > > Memory access in an atomic way like is made by other cpu. That's enough= > > t. > > > > i told you : FC0 handles memory accesses with 256-bit lines. > > if you do RMW you WASTE a lot of performance. > > but i think that you don't care. > > Yep, because semaphore aren't access so much and not inside inner loop. > > > > > ok, i'll try to sleep. i hope that this licence discussion will not > > degenerate in a war, because i prefer to code : "make file, not war" > > (lame attempt at doing humor at 4am, sorry) > > > > I think you had better to wait this morning to answer... > nicO > > > nicO > > WHYGEE > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > I know it's a discussion between nicO and Whygee but when I see what happen (it's seems to become hot, very hot!), I just want to make you remember that we are all here for the same thing and we can have differents points of view. But, we must keep cool whatever happens. Remember, in a thousand years, we will be dead and angry or so isn't the best way to make things evolve in a good way. Sorry to polute the mailing list but stay cool. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Aug 18 18:34:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMl-0002hO-00 for ; Sun, 19 Aug 2001 07:43:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:19 +0200 (CEST) Received: (qmail 17329 invoked by uid 0); 18 Aug 2001 23:23:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 18 Aug 2001 23:23:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA18296 for ; Sat, 18 Aug 2001 19:23:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 23:21:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA17909 for f-cpu-list; Sat, 18 Aug 2001 19:21:28 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA17892 for ; Sat, 18 Aug 2001 19:21:27 -0400 Received: from tribble.stud.uni-hannover.de (root@a048.home.uni-hannover.de [130.75.232.48]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7INL7b25874 for ; Sat, 18 Aug 2001 19:21:07 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00902; Sat, 18 Aug 2001 18:34:26 +0200 Message-ID: <20010818183426.17338@thrai.stud.uni-hannover.de> Date: Sat, 18 Aug 2001 18:34:26 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: References: <3B7DCA4C.BB512A48@f-cpu.org> <3B7E9BEA.EB6F5B73@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7E9BEA.EB6F5B73@ifrance.com>; from nicO on Sat, Aug 18, 2001 at 12:46:34PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Aug 18, 2001 at 12:46:34PM -0400, nicO wrote: [...] > > > So you add another chip it cost a lot. Why using a new port ? What does > > > it add ? Nothing ! Just few more problem ! Canonical CPU are always put > > > on one bus (or switch, it's the same). > > and that's their problem. > > note that your "always" shows that you don't know alternatives, > > there are other computers that have different architectures than > > the SMP/MPP you learn at school. > > > > When you don't criticize my school, it's my books ! You're funny (jalous > ?) ! As you, i read a lot on the net about a lot of architecture, and i > please you to stop this kind of personal attack. I'm really feed up with > it ! Don't you remember when i try to explain how COMA from sun work, > and you don't understand a word ? It's just to refresh your mind a > little. May I interrupt your personal "conversation", please? Nicolas, I'm pretty sure that Yann didn't mean *your* school in particular, but school(s) in general. And I agree with him -- there *are* things one doesn't learn at school (or at most schools). Another thing one usually doesn't learn at school is to respect people as they are, let them have different opinions and accept their decisions. Maybe it's time to learn that now, for some of us (perhaps most of us). The F-CPU Project is not a contest. It's not work (or business in general) either. It's supposed to be fun, not competition. And it's a kind of experiment, both technically and socially. We will probably never know whether Free Hardware (in the GPL sense) really `works' if we switch licenses before the experiment is finished (or obviously fails, in case we find out that it *doesn't* work that way). I'm absolutely not willing to declare failure of the `social aspect' by switching to another license before we have reached the critical (implementation) phase; I want to see how far we can go. The farther, the better. [...] > > i do not "fight against", i "fight for" a free, ununcumbered platform. > > i do not work as SoC expert. i'm just a wannabe-computer-architect. And I don't want to fight at all. 'nuff said, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Aug 19 01:18:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMm-0002hO-00 for ; Sun, 19 Aug 2001 07:43:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:20 +0200 (CEST) Received: (qmail 484 invoked by uid 0); 18 Aug 2001 23:23:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 18 Aug 2001 23:23:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA18357 for ; Sat, 18 Aug 2001 19:23:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 18 Aug 2001 23:21:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA17835 for f-cpu-list; Sat, 18 Aug 2001 19:21:23 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA17832 for ; Sat, 18 Aug 2001 19:21:22 -0400 Received: from tribble.stud.uni-hannover.de (root@a048.home.uni-hannover.de [130.75.232.48]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7INKxb25869 for ; Sat, 18 Aug 2001 19:21:01 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01920; Sun, 19 Aug 2001 01:18:46 +0200 Message-ID: <20010819011846.39974@thrai.stud.uni-hannover.de> Date: Sun, 19 Aug 2001 01:18:46 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] More Instruction Set Trouble Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi *, today I found another dark corner... When an F-CPU program wants to access a (global) variable, it has to load its address and use load/store. For loading the address, we have several options: loadaddrd, loadaddrid and loadcons[x] (or load it from memory, but then we have to load the address of the place where the address is stored...). The address of a variable is usually not known at compile/assemble time. The difference between the variable's address and the address of the instruction loading it will also be unknown in most cases (code and data usually belong to different sections that can be moved independently). That means that we have to use relocations: the compiler/assembler will create code for the general case, leaving the (absolute or relative) address open (usually set to 0), and let the link editor patch in the correct value. Unfortunately, the term `general case' means four(!) successive loadcons instructions (or similar). There is no way to optimize one or two of them away because the compiler/assembler doesn't know which value is loaded. You might say: "use PC-relative addresses". But that doesn't work either -- in fact it's even *worse* than using the absolute address because you need four loadcons instructions to put the relative address into a register, and then you still have to execute loadaddrd (that is, you need one instruction *more* for relative addressing). The same is true if you use a `base' register that points to the beginning of the data section and calculate the distance to that point. You still need 4x loadcons + 1x add to get the variable's address (and yet another instruction if you want the data to be prefetched, because `add' doesn't do that). A module-local base register is also possible, but you'll have to save, set and restore it in every function that is not module-local (e.g. has `extern' linkage in C) and uses global variables -- and you need the full `quadruple-loadcons' instruction sequence again each time you access a global variable that belongs to *another* module (just in case it isn't clear: `module' means `source file'). Another (inferior) way is to limit the program size to 2^32 bytes (or maybe 2^48 bytes), which saves two (one) loadcons per address loaded. Did anybody say `tiny/small/large/huge memory model'? *YUCK* >From a compiler's point of view, the loadaddr instruction is pretty useless except for module-local jumps and calls, and access to jump tables or other data that resides in the same (code) section of the same module. Any other ideas how we can reduce/avoid the `address load penalty'? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 19 03:33:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMo-0002hO-00 for ; Sun, 19 Aug 2001 07:43:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:22 +0200 (CEST) Received: (qmail 18080 invoked by uid 0); 19 Aug 2001 01:36:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Aug 2001 01:36:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA21614 for ; Sat, 18 Aug 2001 21:36:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 01:34:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA21342 for f-cpu-list; Sat, 18 Aug 2001 21:34:01 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA21338 for ; Sat, 18 Aug 2001 21:34:00 -0400 Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7J1Xgb27822 for ; Sat, 18 Aug 2001 21:33:43 -0400 Received: from f-cpu.org (nas2-232.ras.club-internet.fr [195.36.192.232]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA24705 for ; Sun, 19 Aug 2001 03:33:57 +0200 (MET DST) Message-ID: <3B7F177A.6696E90@f-cpu.org> Date: Sun, 19 Aug 2001 03:33:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: (m) Re: [f-cpu] More Instruction Set Trouble References: <20010819011846.39974@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello; Michael Riepe wrote: > Hi *, > today I found another dark corner... > From a compiler's point of view, the loadaddr instruction is pretty > useless except for module-local jumps and calls, and access to jump tables > or other data that resides in the same (code) section of the same module. > > Any other ideas how we can reduce/avoid the `address load penalty'? i have one proposition : a "new" addition instruction dedicated to pointer computation. no SIMD flag etc, but other flags for prefetch etc. when used, the add instruction will perform the addition of two operands and check the result in the specified TLB (instruction/data), prefetch the lines and associate them to the specified destination register. i think that it will do the beginning of something for us. another thing that i have thought from your C++ example : when doing "pointer chasing", it is useless to prefetch unless you chase several pointers at once. in fact when there is nothing to interleave, the prefetch instructions will induce some code bloat and a proportional (small) slowdown. prefetch is good when a loop is sufficiently unrolled, not when it's too tight. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Sun Aug 19 03:55:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMp-0002hO-00 for ; Sun, 19 Aug 2001 07:43:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:23 +0200 (CEST) Received: (qmail 6417 invoked by uid 0); 19 Aug 2001 01:55:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 19 Aug 2001 01:55:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA22143 for ; Sat, 18 Aug 2001 21:55:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 01:55:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA21902 for f-cpu-list; Sat, 18 Aug 2001 21:55:25 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA21899 for ; Sat, 18 Aug 2001 21:55:23 -0400 Received: from online.ln.cn ([202.96.74.82]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f7J1t4b28055 for ; Sat, 18 Aug 2001 21:55:05 -0400 Received: from maveric([61.176.52.135]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm103b7f6084; Sun, 19 Aug 2001 09:52:19 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: [f-cpu] Re: Floating-Point Date: Sun, 19 Aug 2001 09:55:25 +0800 X-Mailer: KMail [version 1.2] References: <20010817182920.05704@thrai.stud.uni-hannover.de> In-Reply-To: <20010817182920.05704@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Message-Id: <01081909552501.00301@maveric> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id VAA21900 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, All, I'm new here, but aren't we developing a concept implimentation called FC-0 and is complicating matters with 128-bit FP really useful at this stage? This is (i understand) intended to be a general purpose processor so shouldn't we be looking at general purpose cases that apply to normal users? I think if a special application needs 128 (or more) FP, they are more likely at this stage to be on a purpose-built mainframe. Later that may be different, but later FC1 will be done (hey, lets be optimistic) and since the F-architecture is already designed to go above 64-bits, implimenting a full 128 (or more) F-CPU is just something you do. In other words, why are we talking about special use FP now while we haven't even got a general use implimementation? As long as we have enough foresight to allow future expansion (and the docs appear to show we have) then the point should be moot. The discussions of different _types_ of FP unit are a different matter and very interesting. I'm learning heaps. Regards, Glenn -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy. Use GNU! [ http://www.gnu.org ] -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Sun Aug 19 04:09:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMp-0002hO-01 for ; Sun, 19 Aug 2001 07:43:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:23 +0200 (CEST) Received: (qmail 10755 invoked by uid 0); 19 Aug 2001 02:15:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 19 Aug 2001 02:15:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id WAA22744 for ; Sat, 18 Aug 2001 22:15:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 02:14:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id WAA22484 for f-cpu-list; Sat, 18 Aug 2001 22:14:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id WAA22481 for ; Sat, 18 Aug 2001 22:14:57 -0400 Received: from lvdi.net ([216.24.138.2]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f7J2Eeb28242 for ; Sat, 18 Aug 2001 22:14:40 -0400 Received: from lvdi.net ([128.2.115.108]) by lvdi.net ; Sat, 18 Aug 2001 19:14:51 2000 PDT Message-ID: <3B7F1FE3.59021CA3@lvdi.net> Date: Sat, 18 Aug 2001 22:09:39 -0400 From: Lee Salzman X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: >The address of a variable is usually not known at compile/assemble time. >The difference between the variable's address and the address of the >instruction loading it will also be unknown in most cases (code and data >usually belong to different sections that can be moved independently). >That means that we have to use relocations: the compiler/assembler will >create code for the general case, leaving the (absolute or relative) >address open (usually set to 0), and let the link editor patch in the >correct value. > >Unfortunately, the term `general case' means four(!) successive loadcons >instructions (or similar). There is no way to optimize one or two of >them away because the compiler/assembler doesn't know which value is >loaded. The linker can handle whatever optimizations are necessary for efficient relocations or else it is a very sad linker indeed. If this means providing several alternatives patches of code to fill in depending on the distances, then so be it. Too much focus has been put on optimizing at compile time traditionally when it is quite beneficial to do it at load time. The distances between code and data sections are very well known at this peculiar and oft ignored time. >You might say: "use PC-relative addresses". But that doesn't work >either -- in fact it's even *worse* than using the absolute address >because you need four loadcons instructions to put the relative address >into a register, and then you still have to execute loadaddrd (that is, >you need one instruction *more* for relative addressing). I don't see why you couldn't just use loadraddrid here and fall back to loadaddrd if the distance is too large. >The same is true if you use a `base' register that points to the >beginning of the data section and calculate the distance to that point. >You still need 4x loadcons + 1x add to get the variable's address (and >yet another instruction if you want the data to be prefetched, because >`add' doesn't do that). The distance of the variable from the current PC is easily calculated at load time so a loadaddrid can be use great utility here, as has been noted. >A module-local base register is also possible, but you'll have to save, >set and restore it in every function that is not module-local (e.g. has >`extern' linkage in C) and uses global variables -- and you need the full >`quadruple-loadcons' instruction sequence again each time you access a >global variable that belongs to *another* module (just in case it isn't >clear: `module' means `source file'). Not quite... a function need only have two entry points - one entry point is module local and does nothing while the other is for the non-local case and sets the current module. Calls to non-local functions are responsible for setting the current module after the non-local function returns. This allows for efficient local calls that pay no penalty at all. Additionally, one should not neglect the effectiveness of redundancy elimination when applied to constant loads. When that fails... hasn't anyone told you that global variables are evil anyway? :) >Any other ideas how we can reduce/avoid the `address load penalty'? An add coupled with a prefetch for data address loads off a base/module register would be very nice. Possibly an immediate add that some how supported longer immediate constants would be nice too, but that could be done without. Lee Salzman The Long Lost F-CPU GCC Porter and "Maintainer" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Aug 19 04:27:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMs-0002hO-00 for ; Sun, 19 Aug 2001 07:43:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:26 +0200 (CEST) Received: (qmail 20329 invoked by uid 0); 19 Aug 2001 03:02:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Aug 2001 03:02:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA23756 for ; Sat, 18 Aug 2001 23:02:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 03:02:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA23514 for f-cpu-list; Sat, 18 Aug 2001 23:02:00 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA23511 for ; Sat, 18 Aug 2001 23:01:59 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7J31gb28533 for ; Sat, 18 Aug 2001 23:01:43 -0400 Received: from jetnet.ab.ca (dialin51.jetnet.ab.ca [207.153.6.51]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA10730 for ; Sat, 18 Aug 2001 21:01:57 -0600 (MDT) Message-ID: <3B7F240F.6E031F9E@jetnet.ab.ca> Date: Sat, 18 Aug 2001 20:27:27 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Lee Salzman wrote: > When that fails... hasn't anyone told you that global variables are > evil anyway? :) I thought Objects and dynamic linking are Evil. I like global Variables. I sooner would see more globals in use than putting everything local. foo{ char bar[2000]...} I think if compilers did more sorting of data on size ( objects <= 8 bytes ) first and then everything else you would not need as many immediate constants. > > >Any other ideas how we can reduce/avoid the `address load penalty'? > An add coupled with a prefetch for data address loads off a > base/module register would be very nice. Possibly an immediate add > that some how supported longer immediate constants would be nice too, > but that could be done without. Yes otherwise you would have F-CSIC :-). Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 19 06:19:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15YLMv-0002hO-00 for ; Sun, 19 Aug 2001 07:43:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 19 Aug 2001 07:43:29 +0200 (CEST) Received: (qmail 27442 invoked by uid 0); 19 Aug 2001 04:20:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 19 Aug 2001 04:20:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id AAA25167 for ; Sun, 19 Aug 2001 00:20:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 04:19:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id AAA24899 for f-cpu-list; Sun, 19 Aug 2001 00:19:30 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id AAA24896 for ; Sun, 19 Aug 2001 00:19:29 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7J4JCb29126 for ; Sun, 19 Aug 2001 00:19:12 -0400 Received: from f-cpu.org (nas4-97.ras.club-internet.fr [195.36.203.97]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id GAA21730 for ; Sun, 19 Aug 2001 06:19:26 +0200 (MET DST) Message-ID: <3B7F3E44.E08932FF@f-cpu.org> Date: Sun, 19 Aug 2001 06:19:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] preprocessing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, after several days of laziness, i tried to use Michael's preprocessing software written in FLEX and BISON. i find no way for it to work perfetclyin all cases. For example, only decimal values are possible, and VHDL is a strongly typed langage that is not limited to names, char and strings. Michael's xtoy package does not contain examples and when i try to use it in the existing files, it creates more problems than it solves. Maybe there are new versions of this tool, but i will try to do what i can and see fits best. If there are other ideas, i will be glad to test them. i think that using cpp/m4 was finally not a bad idea, i will also try to use the two scripts that Michael has written. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 19 11:16:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vM-0005z5-00 for ; Tue, 21 Aug 2001 04:05:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:05:48 +0200 (CEST) Received: (qmail 13215 invoked by uid 0); 19 Aug 2001 09:18:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 19 Aug 2001 09:18:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA29737 for ; Sun, 19 Aug 2001 05:18:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 09:16:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA29484 for f-cpu-list; Sun, 19 Aug 2001 05:16:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA29481 for ; Sun, 19 Aug 2001 05:16:46 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7J9GTb05297 for ; Sun, 19 Aug 2001 05:16:29 -0400 Received: from f-cpu.org (nas1-95.aub.club-internet.fr [195.36.202.95]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA10851 for ; Sun, 19 Aug 2001 11:16:43 +0200 (MET DST) Message-ID: <3B7F83F1.292EE0C0@f-cpu.org> Date: Sun, 19 Aug 2001 11:16:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] xtoys vs m4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i tried to see what i could do with cpp but i have reached its limits quickly. so i tried my and i start to have meaningful results with it. i'm still translating my local files in the new proper format, and i will release another snapshot of my work when it is more or less ready, to give an example. i will let Michael create a Makefile because i'm really bad at writing them :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Aug 19 21:23:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vM-0005z5-01 for ; Tue, 21 Aug 2001 04:05:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:05:48 +0200 (CEST) Received: (qmail 14338 invoked by uid 0); 19 Aug 2001 13:16:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 19 Aug 2001 13:16:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA32127 for ; Sun, 19 Aug 2001 09:16:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 13:14:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA31847 for f-cpu-list; Sun, 19 Aug 2001 09:14:37 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA31844 for ; Sun, 19 Aug 2001 09:14:36 -0400 Received: from localhost.localdomain (nas5-121.vlt.club-internet.fr [194.158.107.121]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7JDEHb06598 for ; Sun, 19 Aug 2001 09:14:18 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 929CE160C for ; Sun, 19 Aug 2001 15:23:50 -0400 (EDT) Message-ID: <3B801246.E4DA91A6@ifrance.com> Date: Sun, 19 Aug 2001 15:23:50 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just one point about SIMD FP. I think that SIMD flag should means an others thing that for integer (no need for 8 bit). What about 16 32 64 128(80 ?) ? 4 differents precisions, the last don't need to be implemented in FC0. What do you think ? nicO Glenn Alexander a écrit : > > Hi, All, > > I'm new here, but aren't we developing a concept implimentation called FC-0 > and is complicating matters with 128-bit FP really useful at this stage? This > is (i understand) intended to be a general purpose processor so shouldn't we > be looking at general purpose cases that apply to normal users? I think if a > special application needs 128 (or more) FP, they are more likely at this > stage to be on a purpose-built mainframe. Later that may be different, but > later FC1 will be done (hey, lets be optimistic) and since the F-architecture > is already designed to go above 64-bits, implimenting a full 128 (or more) > F-CPU is just something you do. > > In other words, why are we talking about special use FP now while we haven't > even got a general use implimementation? As long as we have enough foresight > to allow future expansion (and the docs appear to show we have) then the > point should be moot. > > The discussions of different _types_ of FP unit are a different matter and > very interesting. I'm learning heaps. > > Regards, Glenn > > -------------------------------------------------------- > Glenn Alexander - The man with no surname and a silly hat. > (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) > (Now avaliable in China!) > > http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) > > I use GNU/Linux: http://www.linux.org > from Debian: http://www.debian.org > and KDE : http://www.kde.org > -------------------------------------------------------- > Fight software piracy. Use GNU! [ http://www.gnu.org ] > -------------------------------------------------------- > The above message was bought to you by 'sigrot' > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Aug 19 23:33:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vQ-0005z5-01 for ; Tue, 21 Aug 2001 04:05:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:05:52 +0200 (CEST) Received: (qmail 20310 invoked by uid 0); 19 Aug 2001 15:25:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 19 Aug 2001 15:25:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA02312 for ; Sun, 19 Aug 2001 11:25:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 15:24:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA02042 for f-cpu-list; Sun, 19 Aug 2001 11:24:20 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA02038 for ; Sun, 19 Aug 2001 11:24:19 -0400 Received: from localhost.localdomain (nas25-27.vlt.club-internet.fr [195.36.224.27]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7JFO0b07705 for ; Sun, 19 Aug 2001 11:24:01 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 97F2515CB for ; Sun, 19 Aug 2001 17:33:05 -0400 (EDT) Message-ID: <3B803091.C8F69A22@ifrance.com> Date: Sun, 19 Aug 2001 17:33:05 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Execution unit port References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I'm looking for the "usual" definition of the port of a unit : 3 data in, 2 data out, SIMD flag, clk, enable or start, reset, something for the exception ? If there is something to say if the outed data is correct or not ? Does i miss a signal ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 20 05:28:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vV-0005z5-00 for ; Tue, 21 Aug 2001 04:05:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:05:57 +0200 (CEST) Received: (qmail 1362 invoked by uid 0); 19 Aug 2001 21:20:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Aug 2001 21:20:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA08304 for ; Sun, 19 Aug 2001 17:20:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 19 Aug 2001 21:20:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA08052 for f-cpu-list; Sun, 19 Aug 2001 17:20:25 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA08049 for ; Sun, 19 Aug 2001 17:20:23 -0400 Received: from localhost.localdomain (nas7-219.vlt.club-internet.fr [194.158.109.219]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7JLK0b11144 for ; Sun, 19 Aug 2001 17:20:00 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0EA5615CC for ; Sun, 19 Aug 2001 23:28:49 -0400 (EDT) Message-ID: <3B8083F0.1492B76D@ifrance.com> Date: Sun, 19 Aug 2001 23:28:48 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Scheduler References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> Content-Type: multipart/mixed; boundary="------------8FA035ACA1202EBDE000CBEA" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Il s'agit d'un message multivolet au format MIME. --------------8FA035ACA1202EBDE000CBEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I send you a scheme of a bypass net. The "Active" signal is the number of the active unit. On the same pipeline stage, there is only one active unit. For each active stage, i compare the address of the 2 write registers to the 2 registers in use by the instructions of the stage. I only drawn the system for one register (not the 3 read register) and only for one pipeline stage. I try to make a more clear one. nicO --------------8FA035ACA1202EBDE000CBEA Content-Type: image/gif; name="bypassnet.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="bypassnet.gif" R0lGODdhUQUyAoAAAAAAAP///ywAAAAAUQUyAgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s7TwA/oCYfEovGITCqXzKbzCY1Kp7xgCcj4BbDUrvcLDovH5LL5jE6r j1oSN9Hextf0uv2Oz+v3/L7///I2MncwZwWImKi4yNjo+AgZqQh0uFHpICipucnZ6fkJGioK SXmJQdiQObrK2ur6ChsrOwsRRGmJmpVLy9vr+wscLDyc06ZKcatAeEzc7PwMHS09LWq8W1ha mW2bvM1MDR4uPk5ebr6jvSu4bpiMbXoeLz9PX28/3w4vB5evvHx9L6DAgQQLGnRkSlWuSwr/ 6TsIMaLEiRQrGkGV6RuC/oYMAVr8CDKkyJEkH3hzJ+fhRowOS7p8CTOmzHrq+tVi2VHlzJ08 e/r82almHI3v/OUEijSp0qVM66h8g7LQyoQtm1q9ijWrVnRPhx5LR/Xo1rFky5o9ewGgu1Ib +YV1izau3Ll0m2pE6c2ogUMZPdb9CziwYIHZjLLde9gw4m7bBjt+DDmy5MmUK1u+jDmz5s2c O3v+DDq06NGkS5s+jTq16tWsW7t+DTu27Nm0a9u+jTu37t28e/v+DTy48OHEixs/jjy58uXM mzt/PlAn9OnUq+Ozjj279nLSt3v/Dv5V9/Dky5sndT69+vWNxrN/Dz8+GPfy69u/zwa//v38 /i/2/w9ggDLQJ2CBBh4oAYEILsggggo2CGGE+z0oYYUWskfhhRpu+F2GHH4IInQehkhiicaN aGKKKvKG4oouvihbizDOSCNqMtaIY46e3ahjjz5SxuOPQg4JWJBEHolkWUYmyWSTTC3pZJRS 7gTllFZeKVKVWG7JJURadglmmDSJSWaZL31pZppqOoPmmm6+yUubcM5J5ypy1olnnprcqWef fibC55+CDopHoIQeiqgZhibKaKNULOpopJIqAemkll5aBaaabrpGpZx+CmoKnoZKaqkfjGpq qqpWgOqqrr66QKuwzvqqrLTeaqqtuO76qa68/nqpr8AO66iwxB57/qixyC7rp7LMPluns9BO 66a01F5bprXYbtulttx+a6W34I7bpLjknkukueiu26O67L5Lo7vwzruivPTeS6K9+O67ob78 /iuhvwAPvKDABB8soMEIL8yfwgw/bJ/DEE/8nsQUX3yexRhvDJ7GHH+cnccgjzydyCSfzJzJ KK98nMozucxyzHDsBrPMNtcME842s6yzSz3vfPLPJAkNNMhET0EUCiclrXTRTktxNNR+iZrP 1Fc8jbUTUUtdA0eVbp31w2AvMt5XVg8SdtpIjA1o2QudLQLbag8s9x9MpxQr3CHUPTe/fDPx D6tuuQ3P3SYp+Hff9ybOxlpcJPaO45Dn/h1W4YUZdnktim+uA+MX4bV0W0WNftNbei3Gz1TI cM66DZ43DhZY2KRO+uEnZXE63rVr3nrvMbz+ueyqoy468aVn7s/pURkOvO/fNk8EO2KlJFSC 1lyztBXLnw2989h2L4T0cEVuOeGR62L79Lx7z37T9Ig//FRVlS5/3vSvtHr7+l/9vk27L+Y/ 242PdgJEjOD2h8C90SSAutvC4P6ni5yYThny05sDE4jBDoCvB/Aj3QTv5rUBFm8fGthgBoFl Qq4Iz4PTA+HbHJKO2VnihDQ8xQJXaDx2DE8nzABdYwD4wwTVcIj5i8fljsgY5AEQE0EEYuwq 10STEJFn2aui/hWviMUsatGCFtFeFFMxxZX9LYVnwJ4Qwxi0PZCxDGo5IxpHNkaefMM9a3zj leJIpe3R0Y5wVGNPQldEPm4Mj3+cnBsFiTFCzqWOiHSSIuXCyEYy6ZFxiaQkkURJtFjykuny Y102yUkh8Y2LTwrlxOQWlUqaEmJjuwUoEfHKVeZoa2v5SyxlWaOjLc+WuFyY0FJ5QbrcUh7D 7GUUegbMvfAyNXmZQDKbYDhj8gFnz1TmJ20kve4Y8gnRlKYeYFZNqVzTND20WjeLQEpvOmU+ zFsmae6CkdyxUZ1280I4KTjO0RClL/IcQzrpGQaN3TNW7hTNPqGCE0X9858ARYfU/tJZzGm+ 86DXmyAHbFU1XEQ0bA4bKBjzGRqmPS5zWFAi9bJpvAf+D4bZfCJEz9nQziENpsFc5ES16RUo LpGFfGFMKgJHQBLmUI8a9GhMHfqoc270mzeNAEIrF7+aDtV8Ua2p5ETYQI3S9KgD+oJRpapK fU7tqf1EaO6YF0CgpjSrbC2hSbnKwYCCsKCgEWlOy5rTZrb1p7GTYQTVt9cMlHSrcF1Bze65 1DwkNhR27alFG+iXaGbUmpTrC2AvWtHCxpUM1VzsHTz7iXBeFatmLaD1vEjCF67VsnHLq2Zl qlB10LWuHung7krLRPo8DnWWqyprW9vX17ouDakE7Tqb/prbqrKVrAQNLF8ratHfQrCoEhSu Dzq1jtnStitYXe5d8encv9ZPhNJdKwhCaF0YgK0b2t0u+rpbXtBN97nKzWp5w4vZ8hkXYWzb 5ln2CwofUo6y8dUrfu1XXyuu1hhuEAqAAVY3wiblwQF+6/mA6MTBuZR7CXmuFz9sWS3NUcLp daYnhZkstZC4xFJkKkgFRVEKwyuT/01U0r7K4kN+tr3NGuuKc0zZQvG4x4ST8bhobBYj/wat DM0xkpUUKcn+WLhPJouSgdNNHAMZrMdFsaSUOmWuVnksVw4OTLWc3jFvpcxmJiWaX6tmrbC5 zRl6M1y3iOc863nPcw5okvgM/mg7G3DL4aPZplDUZ44l2hWLXvJFCV1o3TTaN4iG9GZzM+ne VPojgVJWppXy6Wq054vY2XRuk4g8C0fwBN9NapNPqyv/frRAoWYs2e5rHVOnT6UIRsarf1pf rQnamcPem5Z/3TFDt42J29H1qfuJPwsgO3lBnemdwuyBM9eaItsO7bLXl+tHn1YxzT0VZikl 2Gmb9gY07bZE3B0UWPo4ZOJ2Kkd6XdRzr63O6k5uMdwM74MEfBPAC6E1Sl1ve0O12m4dUb9Z /dJrP1yj6QbQwPcEiN+OFOEzJPbCRyhtx3poxAxvcVrInZaJD/jf/L44YZTdB/l6kOMl9DUM Sx7F/sSQ+n4VvLAhc57qkXJD1uTTIzBJfbvjhdixmJufEx+C7XBL2m5p1QbNBcuqqhkC3y0N tsIru2G8RJW5Jx20C0UeP37e1rX+TmlDxl51ple2Py6PxOtsu3Wp19zmPbUvyu89X57LU8CD 9itYye513+Y97YjHdbXv2w7yLn66UadO3dHjB8QLlcvOcfbxzO4Vric08OuWfAuXYfiprvxw Z40uDkf/3pmRNtqyZyG0zRsxmE+z1ZC9vC88f7/Mcp7XtdvqiHHYe7Mlfa83hn326Gve44/b r40tun8rXzLdq5H3k7d8wmFtVS3U9ucMtDlfFf9Earc98dEPvcc171wm/osT963Puu/fp/1v Ct32V7eh/VsKddczeBF3fmunU6m3euzXVrhVQPAnfdNXfqunN9gnIvmnf0znU/TWcf9XXbG3 gBE4fQnoeDonHconeENlb4z3WAqoOiA4QBOocs9xf+0hb2hHPc32feBHfHDnei1XgAvGFyrV Q7jXfB8kW/bFe/R3g+DVgjsYZPAXZKRXMRZ4gVO4gfaHcqY3gD64agY4f6PzFRBUhKdXOMXH dvN1dOI1XrWXfOXWXbk3dW0zg9EAfF+nfluIh+mmD7bVey+oQ0ToY+ojc0iIfPCUXV2oYSCH Ugh4YFaIabcGe/13cinngRqmV/DzIOVUiNwX/nbIRzw8BF2hCIA/JHTPZGD4VkGA93TVQ3dU mHnLp4F7N4l3iDlTtYiUaIkZVnYnpXxaF2IKJ3448UIC2HNjGFkBaHQsxWz/EWjN6IzPCI3R KI3TyGc5GAjOaHnUqEXWyFm+5ykxmH0hxY0t0CLFBoeyiAbgyArquIzMaFDjyAI3Yo7xUYfd aERfM4djIo5X+DvGxo7eUY/2KA6opV75qI91BY+GNQgUmGz8SFzdpmoQp1hYtI5RY0KnaCcJ qQJVMo8Zo5H+FA5EFyesyFgMeWk1eFm25pCBAHH/6H0r2Rkm+QgkZ2syiVTy1o6jEJAKqTQ2 GY7o+CY0uTZD4JPF/vBtJidqMEmOhlWUzbGTZDJHlGItTcluNZiCOvmR7sOULrkcTykmVGkC YImFalBwwphaEeWVWhmPYlkcaQkmQ0iUa+hWDWaRGVcVG5eUQKlev8OWwuGW3fI2RbdSFrZz lghiowh2kFOYiJiOVBd5M5eXWHddA9KXjqZV2oiZzxgygfmCEuh0+6SCd6h2QCiFLGhPjgl3 IOcJf8k/M9CRMpiVb/l8erEQA/iGqZeEo+V2qHebCVhGqGmGqhlvShmP7FaZcaiXa2I2YIeK fciEvil3tJd8p3d7jPmbrxidhTd8GEecPGmcXElpsQmYveWb1pdEKWeCz7ZTPIWRP9iY/thp hn0Xmf7nmipkkM/AmlsCl+W5efwJjCsomOuJghRHlsCJhMI5nMnpAs7ymiZWG/npM8fpVAsa WyFHnu5poRG4f2snnacAnsOFnR/Gf/M5i10VPj6JWB+6ZuJZYYDUOUNXBUXZoBwEg2+3fuiZ hJsnXWqlh51ilxiIl1jZnRuJTiYpko2oGRAaWsponKVJjjP6V8ikYvhDVASVhrO2UwUGRQC6 nabZBc3zVCDWCkqqQMHzJXZ1GmQaFMPYpF/Icmsppdw1fyMooG7Khp/4mTzKn3SkopNpoL/H om6QBFCqhBO6I4HaohgaSAQaPVwpoRuJPTFkgJK6i1FIixsa/p8dqobaWXqKMgl9umNDKipL AKXGd59fiqhLioyZKI+gOpaQGqdzx6k+pETtKXlguIpZZJhw86gU+qmRSKLS1jXQhG3t5qpA oaacYIgWeirH6nFw2o1XtJ5NdH1Hyos3Rz62+EXWap7vCYmLaQfJ2qVEKmzI5kIXFpOpupoq xqtTtp+SmW2/dowjF69xsooBZksLlV+ZWUXH1KpD13VPl6H8SrAFa6tParCwSJ+9QFGGmYoi F2OFcZ7WJ4SSE4iV+rDjNTlh2p8am1e9GJFLiqXKmq/tBjUnG6+lmK1O6oareWLwyrDjR6mE GFTV13NCpXkkCIW7+oe7CYs9e2oE/pmznmgnT4Gv43RsKAsF/7qJRKtjCSpkolqRoGiDNIuu Nptgeep0+GWxVztZPsuI1mmpjees/mRGR+tldYqUWqO0+UVaLghuLutiChoLDWt4fAi3g7mC uumFN+o4PKiFHXujHauyXioJG1u2bQtJWYgJigtNzQpYfLioUBuqdAsLdiurhTpQqiiGOep4 6LeHeNsPiCOMpPi5JXmw3Jm2Tvicj3tMkPu2TmuoaBu1liseMpuYwRay7QegDri10OY1DASA rxq26FqoqNurqPpirGungOO4PYp+hnunlBuu6rqmXXGX5Yepg8u5PIVXVJuHois7UkYVJ5i4 Nba8jNu8/qT6vB4auXnbuCqpWNarrOxas8Iru8rVvaoXu53KgOLbgu1avjx3vui7uuqJoOj2 uinbvyzbuiQ7tzA7ktgLuJlamvubnh+YkvpLjGBbwfJ3my5lG6cKWzpoqc67wNTVwMcbv7Rb uRJMCw9owR7Mwhpcntr7u/CVnQDsvXaYYJr6oEOmhhJDxLAbvQ48vRA8v1JbtKHbgxVcw/vr XZ54ugsGxVN8xYq6hIVXwOlrwBzYvgqswkf8icIqv7ULw7OwdInZGLulYIqqiX1LxpvKUnmh pXIpttf6sbtrI0K8a0sbxmDMi7qotrPrbRG8sGrcrx7msxCruW2MdMUlsZMs/lpvdRilCF3X qslsfIAPS6iTQcJGqVXcFMhDecYvnMgpcpjJa2V+bMJiTMopfMhLbLsccrawEco4wCOfHJal nB+nXL1MXCFtFBu5XJX+6C5FLMtyS8tpDCJRGSOujKO/DMjLTL1d5swfgrjGTAfQQ5GZF5as PLKuW80uHMy1nLIKqx0uGs04CYRdXJ8tOZW+7B/AjM2pHM4SxM2Xy63MdJS9+LL5zKD0jE7B 2s30S7zGS2hgmqNI7GdbaSzKXM6zjMb4fAWRWmfqxNBex8vUDNGiPNFsa88HLcxuu6m+ptHu /MgRVpDnK9GxbM73XKI9ScEJjUtlmb9vBs8WDaut/vLSIh3TJI3ORnzSn+dNZdmbvGt0GOaw IM2Xw+qvCUuN1SDVVf3N7gutfht0OtvRPrDTeoLU7LejdayYDW2i8YzWlxk6V/20KBzUD0kh XZ3UBzrD2inO/sgtd5fDWXyLfjfXS+mnZ63Wt8PWhgzUFN3NXCTX1cmedQ0Aj52d9vTYeU11 jM2/awjZfmjZvprW/WjNbo3YZDnZ/8eX4Hu3o23FDr1v+0wcnpPZc/3azIfasa2tkE3bge3Z nU3OMB3a6Yjar3yNpp254WXbYnDb0+La5WNax92GjFfQuL2Xn82+I52xeizCz3rRusXcC/rb e2rbTvvd4NTdyP2K/jmt/uPd3CMaabrNktINy8z8xwoNxJ1K1EbdNeit0K9N28et3/j9UJS9 e8rtnswd27dd4N7i01C9r+H93dYd3gcU0tc83Ero3zl5XhWOx15d06e9idI7qBh+LIyD39tN w6Fp4g8c3ezN2YPN4ADb4iSOO+59uNid4Sc81Fqsvve94VZb4jC+tCBOLCLuxHA83r9t4LON 3rGm4IJ92E0u4RMu2xfecPb9osgYuD0O5MTK2sORONvt5Une3fsd5kYu5rq85LnN206uxD4s 31nO5jbNvN8ptmL+emQu3lvul7uHoQ2OiEcuiC3u1Ggu6Lut5gRnfk44clUL5/KtQonYdAyu /jsuDuiSjedmpueP/uBK13RMvbKBnuJMTuihvuZUvsWcKrA3u8khmONV/uLYO9p07shISqpu /iuV/umD3t4RDtrwzeaZfsJ2juqyTnk+PjS0ziu2nuugnuyF/t5PTscwaqfFzbvSS+DEXhLW PizIvuK4vu2iPt1vPcQiauo6WuTATuOMnkfarmnSzGpn7u3NPup2+Or6DYx5+ObSPmHGvivq XpzQvezvPqgG/WzjS7X8be6Ch++gpu+4wu/eqezdvusAb3cDe90rZ/D529hWge0oxO697O/f nubOzsg1btfljvGRvvHpDuAHfOstH/Evb+gZuup0bu+rlvBXkfLH/t7xrfnw8A7yvH7uhczj df3oVrbwt9Lw5KrigK3rPy/yWuzfNH/lm64kR08rY9TqWa/1W8/1Xe/1X//17v7vMO/zqpt1 lejJfG61+qxJVj8rWA/2cS/3c0/3dZ/gH1/2AU/dcVu8u3jgCX/zN//hdk/4hV/4run2smn4 i8/4Xa/jjQ/5kd/4jy/5XP/jP/30Raowlc/5lY/4Sc/yMh3cnU/6pa/1Yg/xsGMxxbT5RGz6 r1/3nz8ocSbPsG/7po/6TD/4HsP6IV+uEzkqOW8mtG8Od7/0NJr4mbL3v5f8US37MBbQL4f3 /W6mDw3uzB9hzT/l0I/I0n/8Dn+i2n+S/kAvDMLvVeKP1dzfzNGR+9SP/DrT+/iJ/lr+/H9C /NzR/uDPcj8T/2wy/4BDAEAwdbn9kTmQVntx1pt3/8FQHMnS3KZTXZWUfeGYdWWHrpkbpyR9 /wM+4FAlJB6RLUOSGVkiJU3plFq1Xo9G7Gzb9WprYJn41/OuyGdpWt2GRN2zZ3Yet9/xeX2D vbf0/QIvAIuaCOXqBDMOFU8YG6ngIDkkiSonMTM1N984NR499UBHRkVKTS9Dc1RxTlljUl+V XDtiZW9xcy11c2h5q3xrDZnMfiOMTYKRP2xvm8MSl6WnqTuNi6v9lFGG6aJ5t3XDs/++cZ/H zMnX2Z1/zcbb/l/iB7uBsKXpZfXlZ5fRYanrN5CgIH5WsB0sGELhg4Y27gHM9ZATRXYSQ2FE tJBjxz0WoVwC6bEeMXvpBF4jCXGlo5SsNKJ52ZJmzR0jI37DaXOVSZ8BZ77jeWwow6CeYhY5 WpRpU0owm+1sKpUqUKlnrirK+m/ppqQutzoVmy2s0pRla1b9aRYtlrZ53k7squlrsrlj8eYN UlFiXJJqk2zDN9CvncL77mKqW2KxXsdFD1PSGHkhYChgKUeC/HhQ4kmNSXnmPHpl5s5dTRM+ mYUxaJVDU/ONDTawaNK3K0MaXBI3l7WsUdlGNtttbxvCDSJnptx4c2rEF+zGAH2d/mXgy5kL he08enZR3lGA5z7+XHLR1MlZt9SDfXv30v9uJh/pfX379/Hn17+ff3//7+cLMA70EoCvAgKr UU/AXbZbkBjxOnLNwQnn+ewrBJ9bjcIy5NtwPQzhgtDDEblRLCYQ89GQRFg6XPEmEfuR0MUZ n6ILIxT/UZHGQhrcERoc1ZDRxyF5QAogIF8LjMgKe1xyHhjTg9LJHZHsTqAqwdFxShCwvGdL GIQkTMovXexyFh/MLO83MrlskU270nwwzjflmdOJaOyESUs6F3GTz9DyzOnPQXlDrI5AM9qT 0CKbXNQoRH90VFI+wIED0ooUnbQnni71KMznxtRUwE6D/jCQSAVFZYnTVB9l6lNWRyT1Tjqp +s/WW3HNVdddebUVsl6BDVbYYYkt9tV3QoWVPFkLpDVTWJklIVqOjpVrWmVVmfZarZ5ldds2 scWOpmrDnVBbZ9csl6hV1a0lWRO/bTeTc99Etdx4PcCXIHKN1Fde3abxF65uS8ND4E/+dfdg KxN2lF427R2XXybZbfiTd7XB2OLbHiYz4tJM3WLh6TYOb+GJS+au4y8/bgllNPxMmQeNDaNZ 5sdW3rJlYNx4mceKby5HX5+Dxi3nKXeewmbJYhu50KJnjpdoqEk7Oidjsc7aP4Ll7HlpZmKm mo+vr5habM6sLkPrtdm+j2sO/guUUcrFlnb6j7OFDphsvKdq2+//DPlb8LbftsrS9s6Mxb7E j6qvF/asnADyyOUOuzezZRpcc/z47pxRrjYPfdjCKS41hVQOTSR1GiTpa47BWld98bhPF87u AwPE3Ku9Pe/dIb1FD75X0mXqjvbIj09+1hYej5ph5Ze/04VKbnDt9s/H093G6333kPt+wVVy DdWhd8If6Z8vtfk3qn8dz9hZd3/9fC03mnfzus9faYutJ54tHdCREJG4z3EOeV/tAEjA9LkN bI1yjvbmdT/9de97sgnfZZS2m6hMznTxqx3T5qc4BZ5PfT+zyX5wJsGMVXCCueOfbZL2Iurp 5Akz/oyfEkC4QBoiUIcw69EAVbg7FpKwhUW8yQtBEUMZjhCH5Yud8UwWwh06UX4mTEv5ojcW CMLLiF1sBRIveJ3fFAOIRJTeAVU1P+WJkIcktMUjhhgdLHYwL1u0UBy9eDkwNlB8GjqcB814 Fp2wT3bTe18gmcg8Pp5wjqarYxC/g8c8cmyP9EvXep5XRujNBB+CBCQVDflJ9MUtjONqpB2z BckQSXKSo2FlI/p3ySHMMHmSyxXlQrY896yxkOnrIActWbE3egY8WjANKmGpylbK7JVagaH/ MAM7G9aQgACi3CLgscMD/rGQyhHeN3c1R9QJEIEHQBwu2wfMXypzbJJE/uYyxdZM/C1SjJha JztphUY1mu+MuyTlJokYSq+5E5/wbJg8AxHLPvLldwZlYDuhOEo6SvSJTSzhP4NU0IEalKOl VJdCMcjQhsKTm8NknS8nelFHZnEvLKXMO+fZUZki7KDPlKUzhYDQi2hTjb1EKe3KmUCYXoyg Op0p0OQF0nrCy6cONYcGX7fPlTIuce3UqFT/ctWjKmtk1uQiPRkkG392dIPp5KcZp7rScbJR qywFmVG3aso6aVI3Nl2oWNtaL3WwUaVurahbf2nVl+a1C0ONa8IEdiUUKTWsh31FWSEq1PXZ sFlnWpdEv0BYkWnWsYvyFyfrmkRodvYOJkUT/l/duLrKns+sGS0qaWHb0iiJgbPHEe1NY5tM oeb0qU2l7Fl1KcrMvja3jsXXWs1pS5x61EvFtWBV2WfbNvZzdmelZRsM+5HaOpdl1fHp4ZYL 1llyN4IPja5g2WpL9QLTq67l1HbJ6ySpXTd6CGKs2uBqRN4eLLuRjO9R5ytQjMp2hcxFSX6L uFf4RuqEC/6vjwIc0OmFN5hLfHCUDMhfB48PwRfOEFkSqVL72vVHHZ6gcjMcow0HzsQezhGI pzvVFd83cy3W3zltq2LiuniZEc7ioXRr4NasmMeA8qSO32vjIotjturlZZDFO2QlJ1ixubwG kWsz5SW7Y7bHIyOI/mgcHC1v2RlYDsmYyZytnZYTszEVBmbS3GMzeyPOXRzanA9EYjHXWc47 5vON52qnMJsMzX9+LJ5niWhDG03HrYVyhfPV30Xn08+T9lxXCxhaIQut0JaGSqU9jbdOl03P 2FR0qOcjaYOdGtV1rOSbiTrqVmeE1a2o9aydImtglDpqusb1c9Ny61/Xj6u8lu6w+5xkZFPN 1xm8ba+XnewGN9tQ+YGNOlNU02cfO9rSDja1y3zaomJ7OK+ukVW77VRQk1XBDbbshxHLayun +8bCBsphN1jaXT/uWuDuGj3nTe96r5ujUSltWMQN738pNOACH7iy46rqHO4PogEzNzca/u7w h08b30/9AvK4RA+Jj1fbIbe3xnN38if5+9AJBGqI74le2uJ4rGNlXCdxHEWLl3w5KN/qyAek 8lHRMIQVT+tvR3p02SESkTGejtCxl1So+1xnU6dNxM3rZQBK8acWBe40N6laRaI1z2S5ONU9 DPSNYt3l/G47a7dOSDlSMbW+dfTTzc5ztBdZ7di1evaIbnR0ZpMQ5E4rv4Gqw0x3Jj1n3/t/ ++5etqex61VW2BTRm/jUoqI6Ccr69h7P978PueOAEKHcI03XWop9wLYbWpehC/rQuzjyWBn9 A1EDVdSnnvVft3tEIZ0g2IO8vLOn/e0BVfrzmk+a4h5k0lOK/vTDrxOrBIZ+3j2/X9kb/8G1 H67yDTh21TdLOkZwtPQH6LxNWWP9SQLVfoHkfe4Xm+DqDn/ru9lE9s5M8RI2JKe9jvIGzP2A Z/c0bf4gD/mCA/yIL/9eDudyLsfwT3LuqT8GDww+Tzuyj5AK7y3kDwFT5QPdQgE5BoWiL+fI LQKlC6qqycmoiwU5KQOzBMbU7wE9aL3SKeMUBgTjSwRJjeW85QXRZvgksL66yebg5954kLt8 ECFIsOOuT4uI0OhUDwLHrpGk5QmXMNW0MPW2EEzMbwhpEPWQC5QGcPrg5AuLqwl3DQgnxeDE cAPJEPMOD37ayyzUMLfYkD7cUFLU/mkPDWMKJ4sO6cpmADEPPaYLdxARo8nw8MLHuA216rCK BIURO+sQWcwS/2fMIJEKCfH3Eq0PNZHW6m8Ul6QTpUiyXArmLuvqTBHAFHHiXrG7xlDwpq/3 ZOz5NmIWZwoT/40XdUYQ/aqpJjGU/m/lgFGmfDHLkjEYa/GMinD8pskRs1AUm/HRJMYar5H9 8oFzei0HqQmIQgWcyLEczfEc0TEd1XEdgwfitnFItHGJ2HEe6bEe7fEe8TEfi8Ud35FKkEgf ATIgBXIgCbIgN4cf+3FG4jEhGbLAGlIhHzIivWgZJdKeKvIiKSgWMZLiNrIjRU0jPfKuQnIk U4YiSTKh/k4yJUvGJFVyYFryJduFJWFyQGayJunPJvUIJ3XSD0FyJ63IJ4EyERfyIYcyKI2y Bo9SCpNyKU+lJ5kyyp4yKs3FKaWyRKryKqeyKBlSK7ESKGWyK5trX8ByLHeRLAum0cwyLatR LeMj0KiSLentK+HSN5BsLu3S1O6yIDCt8PLSLOWyL6VlX+biLQHz+LiyH/eSqAoTLP9yMTet AJ+OMB0zAQ/T0wwynNowApGQ5lRwMmGyMYMybT5E83xPwCbQM3ESNL1y5zhM8WIM7AALNVNS NX1SNCOip0xzEslONk+SNnfSNmWo+lIKDUmTN1vSN3USOG3t7h5wNzvTOEcS/jlTkzV/0QyV rrWkEzopUztFcgYz0Zd6L/2wkDsxMjtrUjkZrO78bz3JszclcyupM8tECf3C8z3b087sEzHj kxnVM+xy0zzvM7YA9DP3kz93ydospQKpMUATckBfMlogCXKm8cfs0AUZdCMd9DiHI0MvNCQ5 dDaRZQkqs0Pr7EN7Uxxah0RV1BVXlC5b7qRaNEZNTkZdlBTjjkZxFC9zNBk+Lad29EfzbEQn zUxCRkiBlLxMlCSxxMqM9EidK0mjc3vSoEmdVA/z8x1xJOOotEphC0o9NLT4kku51Es9csSI SUzH9Eq3kUB08ArR9EfJtCMxpE2t701zNE4x9I5M/s9OjxRPy7O82GBL+RQWBTXOqmTeCnVQ 2S1RyaxLcolRFZWk1PQa08RUIDVSW8lPL3JO4ONSMTWPNLUi80SDPpVGQ1UiEaWTSlVGTzUi L4WMVjVGW5Uor2xWY5XqbBU+N9RTb/XEJrUZ0bNXZTNXG7RAhZU8iVU/s+1YGTRZsdRYmRU6 nXVNoTVaeXNaKbVarRU1sRVYtXVbJ7NbkzFYwbUvxRUYybVc7/JceTFd1XUu2XUW3fVd2TJe X3Fe6TUt7dUUL1NX8vVfwZVXAXZgeVBgCfZgjc9gEXZh0U5hGfZhHc5hIXZio01iKfZicc1i MXZjLZNjPfZiNfZjRXZk/km2ZE32ZFE2ZVV2ZVm2ZV32ZWE2ZmV2Zmm2Zm32ZnE2Z3V2Z3m2 Z332Z98QaIXWOEN2aI02Jo82aQuzaJW2aUWFaZ02aj1LaqmWLKG2arGWFrN2a5nyarn2a2nE a8H2Tfnj2uh0bNE2BHtr3M42bd3Ws9ot2N7tbek2JuOWJulDOOt2b99wrw6OZ/SWbwV3UHyx 7/Z1cBG3sDyusIgv0sAwcSHXYQKP+oYxBZ8TnWwwc92OvS53+SL3cyltbIouFdkz6aRPxJbO OokzxUC3dSEmA6NAF59sN4ELdY3RPwMpcDXXdXm3Kd8u9gJQrW60CC9LPI0QFGlXsISvd5nX /vZ+1zkXpy4M7xnIaT6rKzL7rXm1d7PQhHWBT3dX0Babs83+agG/dXvRF7907nu7DnuFK7hy E3VJ73zTt36V0H17wQCZBhf5lxJrd0bp134FGA/vj/nG7+UoBfrIqXTH1znX98UGOIKX03Od TnGGc7USuD8p9Ib0txUZT+EkOITLMn9Pc25LaP88Nxf/M3UA8AznLnknQoRleIRJ0wFf0Bgf lYVrSUFN0AY9yekgeIaF+FGs7QQ5N71mTgWr10I/b0F3d3mHOIob5A6luIq7z0etOIsTkBu1 uIu71G+9OIy/+IDFuIx7cfHMOI1/zonVuI3d+I3hOI7leI7pmG/FTraO8fgn83iPfeeO+fiP oRKQBTlo/HiQDfluDjmRCVmRGbkkG/mRDwqSJRlpJ7mSLfmSMTmTNXmTObmTPfmTQTmURXmU SbmUTfmU5aEAAAA7 --------------8FA035ACA1202EBDE000CBEA-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Sun Aug 19 15:12:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vX-0005z5-00 for ; Tue, 21 Aug 2001 04:05:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:05:59 +0200 (CEST) Received: (qmail 2116 invoked by uid 0); 20 Aug 2001 03:08:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Aug 2001 03:08:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA03039 for ; Sun, 19 Aug 2001 23:08:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:07:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA02341 for f-cpu-list; Sun, 19 Aug 2001 23:07:37 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA02329 for ; Sun, 19 Aug 2001 23:07:35 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K37Za01799 for ; Sun, 19 Aug 2001 23:07:35 -0400 Received: from tribble.stud.uni-hannover.de (root@a223.home.uni-hannover.de [130.75.232.223]) by studserv.stud.uni-hannover.de (8.11.3/8.11.3/MX/check_local4.3) with ESMTP id f7JNT6l24489 for ; Mon, 20 Aug 2001 01:29:06 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00506; Sun, 19 Aug 2001 15:12:23 +0200 Message-ID: <20010819151223.17691@thrai.stud.uni-hannover.de> Date: Sun, 19 Aug 2001 15:12:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <3B7F240F.6E031F9E@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7F240F.6E031F9E@jetnet.ab.ca>; from Ben Franchuk on Sat, Aug 18, 2001 at 08:27:27PM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Aug 18, 2001 at 08:27:27PM -0600, Ben Franchuk wrote: > > When that fails... hasn't anyone told you that global variables are > > evil anyway? :) > > I thought Objects and dynamic linking are Evil. > I like global Variables. I sooner would see more globals in use than putting > everything local. > foo{ char bar[2000]...} Ben, you're a dinosaur ;) > I think if compilers did more sorting of data on size ( objects <= 8 bytes ) > first > and then everything else you would not need as many immediate constants. I'd rather sort by alignment, not size. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Sun Aug 19 20:55:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vY-0005z5-00 for ; Tue, 21 Aug 2001 04:06:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:00 +0200 (CEST) Received: (qmail 31596 invoked by uid 0); 20 Aug 2001 03:08:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 20 Aug 2001 03:08:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA03035 for ; Sun, 19 Aug 2001 23:08:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:07:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA02358 for f-cpu-list; Sun, 19 Aug 2001 23:07:38 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA02338 for ; Sun, 19 Aug 2001 23:07:36 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K37Za01803 for ; Sun, 19 Aug 2001 23:07:36 -0400 Received: from tribble.stud.uni-hannover.de (root@a223.home.uni-hannover.de [130.75.232.223]) by studserv.stud.uni-hannover.de (8.11.3/8.11.3/MX/check_local4.3) with ESMTP id f7JNT3l24453 for ; Mon, 20 Aug 2001 01:29:04 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00371; Sun, 19 Aug 2001 20:55:31 +0200 Message-ID: <20010819205531.17305@thrai.stud.uni-hannover.de> Date: Sun, 19 Aug 2001 20:55:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <01081909552501.00301@maveric>; from Glenn Alexander on Sun, Aug 19, 2001 at 09:55:25AM +0800 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 19, 2001 at 09:55:25AM +0800, Glenn Alexander wrote: > I'm new here, but aren't we developing a concept implimentation called FC-0 > and is complicating matters with 128-bit FP really useful at this stage? This > is (i understand) intended to be a general purpose processor so shouldn't we > be looking at general purpose cases that apply to normal users? I think if a > special application needs 128 (or more) FP, they are more likely at this > stage to be on a purpose-built mainframe. Later that may be different, but > later FC1 will be done (hey, lets be optimistic) and since the F-architecture > is already designed to go above 64-bits, implimenting a full 128 (or more) > F-CPU is just something you do. There are, in general, two reason why one wants large floating-point types. One of them is precision (as some of you mentioned, that's a rather rare case), the other (and more important) one is the increased range. People often use IEEE double not because they need >6 digit precision but because single has only 8 bits for the exponent -- and sometimes 11 bits aren't enough either. But I agree with you: there's no need to worry about FP with more than 64 bits for the FC0. In fact, the FC0 may not have FP hardware at all (it's all optional, IIRC). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Mon Aug 20 02:08:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vZ-0005z5-00 for ; Tue, 21 Aug 2001 04:06:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:01 +0200 (CEST) Received: (qmail 5180 invoked by uid 0); 20 Aug 2001 03:08:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 20 Aug 2001 03:08:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA03038 for ; Sun, 19 Aug 2001 23:08:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:07:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA02332 for f-cpu-list; Sun, 19 Aug 2001 23:07:36 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA02325 for ; Sun, 19 Aug 2001 23:07:35 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K37Ya01795 for ; Sun, 19 Aug 2001 23:07:34 -0400 Received: from tribble.stud.uni-hannover.de (michael@a223.home.uni-hannover.de [130.75.232.223]) by studserv.stud.uni-hannover.de (8.11.3/8.11.3/MX/check_local4.3) with ESMTP id f7K0C3l12228 for ; Mon, 20 Aug 2001 02:12:03 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA05689; Mon, 20 Aug 2001 02:08:33 +0200 Message-ID: <20010820020833.14296@thrai.stud.uni-hannover.de> Date: Mon, 20 Aug 2001 02:08:33 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B801246.E4DA91A6@ifrance.com>; from nicO on Sun, Aug 19, 2001 at 03:23:50PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 19, 2001 at 03:23:50PM -0400, nicO wrote: > Just one point about SIMD FP. I think that SIMD flag should means an > others thing that for integer (no need for 8 bit). > What about 16 32 64 128(80 ?) ? 4 differents precisions, the last don't > need to be implemented in FC0. The manual says: 00 32-bit 01 64-bit 1x unassigned and the second one... On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > Hello, > > I'm looking for the "usual" definition of the port of a unit : > > 3 data in, Or less. > 2 data out, Or more. > SIMD flag, Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > clk, > enable or start, > reset, > something for the exception ? > > If there is something to say if the outed data is correct or not ? Currently not; the scheduler should know. But we can add a `here is the result, take it or I'll throw it away in the next cycle' signal. Something is missing: the lines that select the instruction to execute (if the unit can handle more than one instruction). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Sun Aug 19 15:08:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vZ-0005z5-01 for ; Tue, 21 Aug 2001 04:06:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:01 +0200 (CEST) Received: (qmail 31861 invoked by uid 0); 20 Aug 2001 03:16:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 20 Aug 2001 03:16:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA03464 for ; Sun, 19 Aug 2001 23:16:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:16:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA03247 for f-cpu-list; Sun, 19 Aug 2001 23:16:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA03244 for ; Sun, 19 Aug 2001 23:16:26 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K3GPa01964 for ; Sun, 19 Aug 2001 23:16:25 -0400 Received: from tribble.stud.uni-hannover.de (root@a223.home.uni-hannover.de [130.75.232.223]) by studserv.stud.uni-hannover.de (8.11.3/8.11.3/MX/check_local4.3) with ESMTP id f7JNT8l24492 for ; Mon, 20 Aug 2001 01:29:08 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00493; Sun, 19 Aug 2001 15:08:17 +0200 Message-ID: <20010819150816.00917@thrai.stud.uni-hannover.de> Date: Sun, 19 Aug 2001 15:08:16 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B7F1FE3.59021CA3@lvdi.net>; from Lee Salzman on Sat, Aug 18, 2001 at 10:09:39PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Aug 18, 2001 at 10:09:39PM -0400, Lee Salzman wrote: [...] > >Unfortunately, the term `general case' means four(!) successive loadcons > >instructions (or similar). There is no way to optimize one or two of > >them away because the compiler/assembler doesn't know which value is > >loaded. > > The linker can handle whatever optimizations are necessary for efficient > relocations or else it is a very sad linker indeed. If this means > providing several alternatives patches of code to fill in depending > on the distances, then so be it. Too much focus has been put on > optimizing at compile time traditionally when it is quite beneficial > to do it at load time. The distances between code and data sections > are very well known at this peculiar and oft ignored time. Linkers cannot insert code when necessary, nor can they remove superfluous instructions. They can just overwrite them with something different. > >You might say: "use PC-relative addresses". But that doesn't work > >either -- in fact it's even *worse* than using the absolute address > >because you need four loadcons instructions to put the relative address > >into a register, and then you still have to execute loadaddrd (that is, > >you need one instruction *more* for relative addressing). > > I don't see why you couldn't just use loadraddrid here and fall back > to loadaddrd if the distance is too large. Because it makes almost no difference. You have to provide space for the longest possible load sequence, and fill it with NOPs or similar when a shorter sequence is used. Bigger code, longer delay. Besides that, it makes the link editor more complex; I'd rather not do that. > >The same is true if you use a `base' register that points to the > >beginning of the data section and calculate the distance to that point. > >You still need 4x loadcons + 1x add to get the variable's address (and > >yet another instruction if you want the data to be prefetched, because > >`add' doesn't do that). > > The distance of the variable from the current PC is easily calculated > at load time so a loadaddrid can be use great utility here, as has > been noted. How many programs do you know that fit into 128K (including the initial working set)? My /bin/bash needs >400K (on ia32 -- that's CISC, not RISC). > >A module-local base register is also possible, but you'll have to save, > >set and restore it in every function that is not module-local (e.g. has > >`extern' linkage in C) and uses global variables -- and you need the full > >`quadruple-loadcons' instruction sequence again each time you access a > >global variable that belongs to *another* module (just in case it isn't > >clear: `module' means `source file'). > > Not quite... a function need only have two entry points - one entry > point is module local and does nothing while the other is for the > non-local > case and sets the current module. Calls to non-local functions are > responsible for setting the current module after the non-local function > returns. This allows for efficient local calls that pay no penalty at > all. That bloats external function calls with `base restore' operations. But the idea is interesting. Gotta think that over. > Additionally, one should not neglect the effectiveness of redundancy > elimination when applied to constant loads. > > When that fails... hasn't anyone told you that global variables are > evil anyway? :) I learned LISP ~20 years ago. (questionsp 'any) There is also constant global data. String constants, for example. Or jump and lookup tables. > >Any other ideas how we can reduce/avoid the `address load penalty'? > An add coupled with a prefetch for data address loads off a > base/module register would be very nice. Possibly an immediate add > that some how supported longer immediate constants would be nice too, > but that could be done without. The `address add' idea looks better and better, and it's good for pointer/array/structure accesses, too. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 02:24:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0va-0005z5-00 for ; Tue, 21 Aug 2001 04:06:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:02 +0200 (CEST) Received: (qmail 2223 invoked by uid 0); 20 Aug 2001 03:24:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 20 Aug 2001 03:24:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA03877 for ; Sun, 19 Aug 2001 23:24:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:24:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA03630 for f-cpu-list; Sun, 19 Aug 2001 23:24:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA03627 for ; Sun, 19 Aug 2001 23:24:20 -0400 Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K3OIa02132 for ; Sun, 19 Aug 2001 23:24:19 -0400 Received: from f-cpu.org (nas4-91.ras.club-internet.fr [195.36.203.91]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA28371 for ; Mon, 20 Aug 2001 02:24:51 +0200 (MET DST) Message-ID: <3B8058CB.5ADEF33C@f-cpu.org> Date: Mon, 20 Aug 2001 02:24:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] m4 won. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, m4 is finally the best choice, i am currently updating my files locally. i will then have to integrate Michael's data and i will post a "release candidate" that will be suitable for the CVS. It is going to take some time before i am ready so i am waiting for an update from Michael. The good news is that it is not limited to C and VHDL, anybody can adapt a few line is a langage-specific file and make a verilog port, for example, without rewriting all the definition files. The existing files did not require big changes but there are tens of different stufss in several directories, it takes a while to check everything. Before putting the files on CVS, i have to check that all the released files are correctly under GPL (not mixing my own copyright on QDCPOC with the team's work), and i'll ask Michael to craft a nice Makefile. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 02:48:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vb-0005z5-00 for ; Tue, 21 Aug 2001 04:06:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:03 +0200 (CEST) Received: (qmail 1352 invoked by uid 0); 20 Aug 2001 03:33:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Aug 2001 03:33:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA04246 for ; Sun, 19 Aug 2001 23:33:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:33:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA03999 for f-cpu-list; Sun, 19 Aug 2001 23:33:03 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA03996 for ; Sun, 19 Aug 2001 23:33:02 -0400 Received: from delay-1v.clubint.net (delay-1v.clubint.net [194.158.96.105]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K3X0a02312 for ; Sun, 19 Aug 2001 23:33:01 -0400 Received: from f-cpu.org (nas2-145.aub.club-internet.fr [195.36.133.145]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA24502 for ; Mon, 20 Aug 2001 02:48:41 +0200 (MET DST) Message-ID: <3B805E5D.81BE0CC6@f-cpu.org> Date: Mon, 20 Aug 2001 02:48:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Scheduler References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B8083F0.1492B76D@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO wrote: > I send you a scheme of a bypass net. > > The "Active" signal is the number of the active unit. On the same > pipeline stage, there is only one active unit. For each active stage, i > compare the address of the 2 write registers to the 2 registers in use > by the instructions of the stage. I only drawn the system for one > register (not the 3 read register) and only for one pipeline stage. > > I try to make a more clear one. thanks, but i do not understand everything. giving signal types and names would be helpful, for example. Is it a "simple bypass" or something more sophisticated ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 20 05:04:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vb-0005z5-01 for ; Tue, 21 Aug 2001 04:06:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:03 +0200 (CEST) Received: (qmail 12797 invoked by uid 0); 20 Aug 2001 03:43:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 20 Aug 2001 03:43:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA04653 for ; Sun, 19 Aug 2001 23:43:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 03:42:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA04406 for f-cpu-list; Sun, 19 Aug 2001 23:42:48 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA04400 for ; Sun, 19 Aug 2001 23:42:46 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K3gja02571 for ; Sun, 19 Aug 2001 23:42:46 -0400 Received: from jetnet.ab.ca (dialin51.jetnet.ab.ca [207.153.6.51]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id VAA11562 for ; Sun, 19 Aug 2001 21:42:38 -0600 (MDT) Message-ID: <3B807E58.831BB27@jetnet.ab.ca> Date: Sun, 19 Aug 2001 21:04:56 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <3B7F240F.6E031F9E@jetnet.ab.ca> <20010819151223.17691@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Sat, Aug 18, 2001 at 08:27:27PM -0600, Ben Franchuk wrote: > > > > When that fails... hasn't anyone told you that global variables are > > > evil anyway? :) > > > > I thought Objects and dynamic linking are Evil. > > I like global Variables. I sooner would see more globals in use than putting > > everything local. > > foo{ char bar[2000]...} > > Ben, you're a dinosaur ;) Get REAL !!! Late Neanderthal!. Having used computers with a whopping 16kw in the 1980's I still think in terms of small systems. It is just things seem to grow and grow. Take a web browser - mozilla - while I expect large data space for buffers and displays, why does seem the program it self is larger than the linux kernel and X-windows and longer to write? > > > I think if compilers did more sorting of data on size ( objects <= 8 bytes ) > > first > > and then everything else you would not need as many immediate constants. > > I'd rather sort by alignment, not size. Most simple items would align to the common 'word' size. The problem is things like structure BIG stuff[Big_number]; structure * BIG Next ; while (Next!= NULL) { Next=stuff.link; ... } Next needs full 32 bit offset unsorted and a small offset if sorted. The problem is the compilers don't really tellme what is being generated or what are inefficient coding practices. Sometimes one needs to be able to see under the hood. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 02:48:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vc-0005z5-00 for ; Tue, 21 Aug 2001 04:06:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:04 +0200 (CEST) Received: (qmail 13528 invoked by uid 0); 20 Aug 2001 04:01:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 20 Aug 2001 04:01:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id AAA05113 for ; Mon, 20 Aug 2001 00:01:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 04:01:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id AAA04864 for f-cpu-list; Mon, 20 Aug 2001 00:01:38 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id AAA04861 for ; Mon, 20 Aug 2001 00:01:37 -0400 Received: from delay-1v.clubint.net (delay-1v.clubint.net [194.158.96.105]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7K41aa03037 for ; Mon, 20 Aug 2001 00:01:36 -0400 Received: from f-cpu.org (nas2-145.aub.club-internet.fr [195.36.133.145]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA03111 for ; Mon, 20 Aug 2001 02:48:46 +0200 (MET DST) Message-ID: <3B805E66.578CB9EC@f-cpu.org> Date: Mon, 20 Aug 2001 02:48:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Execution unit port References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Hello, > > I'm looking for the "usual" definition of the port of a unit : > > 3 data in, > 2 data out, "as much as needed" (ASU could have 4 output ports but this is not yet completely determined). > SIMD flag, > clk, > enable or start, > reset, > something for the exception ? except for the SR unit, no EU needs to report exceptions (protection violation, but the pipeline is stalled at issue when the SR EU is used). FP units can report exceptions if the "IEEE flag" is set (again : the pipeline is stopped until we are sure that the result is ok). concerning the "necessary flags" for example, ROP2 requires the 2 mode bits and 4 function bits. Some transation and buffering of the 4 function bits is performed during the Xbar cycle. > If there is something to say if the outed data is correct or not ? no. Data are discarded "implicitely" by the Xbar write stage, by choosing a proper source for the proper register and with the right write mask. > Does i miss a signal ? no, except for very special cases, it does the trick. there's no magic :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 20 07:39:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vd-0005z5-00 for ; Tue, 21 Aug 2001 04:06:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:05 +0200 (CEST) Received: (qmail 29357 invoked by uid 0); 20 Aug 2001 12:16:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 20 Aug 2001 12:16:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA14179 for ; Mon, 20 Aug 2001 08:18:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 12:17:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA13934 for f-cpu-list; Mon, 20 Aug 2001 08:17:51 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA13931 for ; Mon, 20 Aug 2001 08:17:50 -0400 Received: from tribble.stud.uni-hannover.de (root@a239.home.uni-hannover.de [130.75.232.239]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KCHWa07485 for ; Mon, 20 Aug 2001 08:17:32 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id HAA06911; Mon, 20 Aug 2001 07:39:07 +0200 Message-ID: <20010820073907.20382@thrai.stud.uni-hannover.de> Date: Mon, 20 Aug 2001 07:39:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] m4 won. References: <3B8058CB.5ADEF33C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B8058CB.5ADEF33C@f-cpu.org>; from Yann Guidon on Mon, Aug 20, 2001 at 02:24:43AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 20, 2001 at 02:24:43AM +0200, Yann Guidon wrote: > m4 is finally the best choice, > i am currently updating my files locally. > i will then have to integrate Michael's > data and i will post a "release candidate" > that will be suitable for the CVS. > > It is going to take some time before i am > ready so i am waiting for an update from Michael. Update for what, the instruction encoder? BTW: I created the first F-CPU object files yesterday :) > The good news is that it is not limited to C > and VHDL, anybody can adapt a few line is a > langage-specific file and make a verilog port, > for example, without rewriting all the > definition files. The existing files did > not require big changes but there are tens > of different stufss in several directories, > it takes a while to check everything. Before > putting the files on CVS, i have to check that all > the released files are correctly under GPL (not mixing > my own copyright on QDCPOC with the team's work), > and i'll ask Michael to craft a nice Makefile. No problem. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Aug 20 15:38:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vf-0005z5-00 for ; Tue, 21 Aug 2001 04:06:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:07 +0200 (CEST) Received: (qmail 18140 invoked by uid 0); 20 Aug 2001 13:37:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 20 Aug 2001 13:37:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA16251 for ; Mon, 20 Aug 2001 09:37:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 13:33:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA15959 for f-cpu-list; Mon, 20 Aug 2001 09:33:59 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA15956 for ; Mon, 20 Aug 2001 09:33:58 -0400 Received: from imf05bis.bellsouth.net (mail205.mail.bellsouth.net [205.152.58.145]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KDXva08227 for ; Mon, 20 Aug 2001 09:33:57 -0400 Received: from computer ([209.215.11.33]) by imf05bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010820133448.ERNQ3517.imf05bis.bellsouth.net@computer>; Mon, 20 Aug 2001 09:34:48 -0400 Message-ID: <003c01c1297d$7816de60$210bd7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Web Site Date: Mon, 20 Aug 2001 08:38:59 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C12953.8E55DA20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C12953.8E55DA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This to inform anyone still interested in M2M design in the processor = Architecture; look at my Web Site at =20 egandaonline.com What you will see is only the System Overview. More will be added later = - this is only the eye-catcher for Venture Capital - Software Designers = - and Hardware Designers that will attend Microprocessor Forum 2001 in San Jose, = California, where I will make my presentation. =20 Anyone desiring more data will be responded to... Regards Richard M2M Hartney ------=_NextPart_000_0039_01C12953.8E55DA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This to inform anyone still interested = in M2M=20 design in the processor Architecture;
look at my Web Site at  =
       =20             =    =20             =    =20     egandaonline.com
 
What you will see is only the System=20 Overview.  More will be added later - this is only the eye-catcher = for=20 Venture Capital - Software Designers - and Hardware
Designers that will attend = Microprocessor Forum=20 2001 in San Jose, California,
where I will make my = presentation. =20
 
Anyone desiring more data will be = responded=20 to...
 
Regards
Richard M2M Hartney
 
------=_NextPart_000_0039_01C12953.8E55DA20-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 20 07:51:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vi-0005z5-00 for ; Tue, 21 Aug 2001 04:06:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:10 +0200 (CEST) Received: (qmail 12343 invoked by uid 0); 20 Aug 2001 17:53:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 20 Aug 2001 17:53:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA24360 for ; Mon, 20 Aug 2001 13:53:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 17:52:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA24081 for f-cpu-list; Mon, 20 Aug 2001 13:52:59 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA24071 for ; Mon, 20 Aug 2001 13:52:58 -0400 Received: from tribble.stud.uni-hannover.de (root@a193.home.uni-hannover.de [130.75.232.193]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KHpKa13405 for ; Mon, 20 Aug 2001 13:51:20 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id HAA06949; Mon, 20 Aug 2001 07:51:32 +0200 Message-ID: <20010820075132.19291@thrai.stud.uni-hannover.de> Date: Mon, 20 Aug 2001 07:51:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <3B7F240F.6E031F9E@jetnet.ab.ca> <20010819151223.17691@thrai.stud.uni-hannover.de> <3B807E58.831BB27@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B807E58.831BB27@jetnet.ab.ca>; from Ben Franchuk on Sun, Aug 19, 2001 at 09:04:56PM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 19, 2001 at 09:04:56PM -0600, Ben Franchuk wrote: > Michael Riepe wrote: > > > > On Sat, Aug 18, 2001 at 08:27:27PM -0600, Ben Franchuk wrote: > > > > > > When that fails... hasn't anyone told you that global variables are > > > > evil anyway? :) > > > > > > I thought Objects and dynamic linking are Evil. > > > I like global Variables. I sooner would see more globals in use than putting > > > everything local. > > > foo{ char bar[2000]...} > > > > Ben, you're a dinosaur ;) Get REAL !!! ^^^^^^^^^^^^ Violating my copyright, eh? I certainly didn't write *THAT*. > Late Neanderthal!. Oh, you're from Duesseldorf? ;) > Having used computers with a whopping 16kw in the 1980's I still think in terms > of small systems. It is just things seem to grow and grow. Take a web browser - > mozilla - while I expect large data space for buffers and displays, why does > seem the program it self is larger than the linux kernel and X-windows and > longer to write? I remember wordstar on a 16k CP/M machine, too. [...] > > I'd rather sort by alignment, not size. > Most simple items would align to the common 'word' size. The problem is things > like > structure BIG stuff[Big_number]; > structure * BIG Next ; > while (Next!= NULL) { Next=stuff.link; ... } > Next needs full 32 bit offset unsorted and a small offset if sorted. The > problem is the compilers don't really tellme what is being generated or what are > inefficient coding practices. Sometimes one needs to be able to see under the > hood. Good point -- if this weren't "late 60's FORTRAN coding style". Modern programmers don't allocate huge arrays (with static bounds) at compile time, they use pointers and run-time memory allocation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 20 07:57:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vj-0005z5-00 for ; Tue, 21 Aug 2001 04:06:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:11 +0200 (CEST) Received: (qmail 5185 invoked by uid 0); 20 Aug 2001 18:22:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 20 Aug 2001 18:22:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA26065 for ; Mon, 20 Aug 2001 14:22:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 18:22:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA25823 for f-cpu-list; Mon, 20 Aug 2001 14:22:08 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA25819 for ; Mon, 20 Aug 2001 14:22:07 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KIM6a14144 for ; Mon, 20 Aug 2001 14:22:06 -0400 Received: from jetnet.ab.ca (dialin51.jetnet.ab.ca [207.153.6.51]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA08099 for ; Mon, 20 Aug 2001 12:22:03 -0600 (MDT) Message-ID: <3B80A6C5.43A7E0D9@jetnet.ab.ca> Date: Sun, 19 Aug 2001 23:57:25 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <3B7F240F.6E031F9E@jetnet.ab.ca> <20010819151223.17691@thrai.stud.uni-hannover.de> <3B807E58.831BB27@jetnet.ab.ca> <20010820075132.19291@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Oh, you're from Duesseldorf? ;) No Canada:-) > > > Having used computers with a whopping 16kw in the 1980's I still think in terms > > of small systems. It is just things seem to grow and grow. Take a web browser - > > mozilla - while I expect large data space for buffers and displays, why does > > seem the program it self is larger than the linux kernel and X-windows and > > longer to write? > > I remember wordstar on a 16k CP/M machine, too. The 16K machine was very old Main-frame computer. I did use a cp/m machine for a while but it had problem with the 8 inch floppies. They stuck and you had to rap the case to get them to work. Rap too hard and the machine would reset do to loose connection. > Good point -- if this weren't "late 60's FORTRAN coding style". > Modern programmers don't allocate huge arrays (with static bounds) > at compile time, they use pointers and run-time memory allocation. Only with the advent of the pentium has home/small business people have had access to large memory. Large memory may be cheep but it is very slow. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 23:33:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vp-0005z5-01 for ; Tue, 21 Aug 2001 04:06:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:17 +0200 (CEST) Received: (qmail 29600 invoked by uid 0); 20 Aug 2001 21:34:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 20 Aug 2001 21:34:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01073 for ; Mon, 20 Aug 2001 17:34:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:33:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA32710 for f-cpu-list; Mon, 20 Aug 2001 17:33:17 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA32701 for ; Mon, 20 Aug 2001 17:33:15 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLXEa17996 for ; Mon, 20 Aug 2001 17:33:14 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA03020 for ; Mon, 20 Aug 2001 23:33:08 +0200 (MET DST) Message-ID: <3B81820D.14C21895@f-cpu.org> Date: Mon, 20 Aug 2001 23:33:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: [ff] f-cpu et savannah] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, the message below announces that a project account is opened for F-CPU in the Savannah server (FSF/MIT). if you want to help with the organisation, you have to subscribe there then send your request to Philippe BTW, we still need help for the maintainance of the F-CPU websites :-/ REYNES Philippe wrote: > > Bonjour > > je viens de creer le projet f-cpu sur savannah. > http://savannah.gnu.org/projects/f-cpu/ > > Bien entendu, toutes les personnes desirant faire > partie du projet doivent s'inscrire a savannah puis > me faire parvenir leur demande. > > Si vous avez des idees, des gestions, je suis preneur. > > Mes projects actuels sont: > > * utiliser le task manager: > Pour le moment, j'ai creer 4 sous projets que je considere comme > majeur: > - architecture (parle de lui meme) > - design: implementation de l'architecture > - compilater: (easy non !!) > - system: portage de linux pour le f-cpu > > Je differencie l'architecture et le design car pour moi, c'est > totalement > different. Je pense que que ce doit etre deux equipes differentes qui > doivent > gerer cela. > > A mon avis, chaque groupe devrait avoir un leader (j'ai bien dit > leader, pas chef) > Celui-ci aurait le role de coordoner l'equipe et de la synchroniser > (comme > une semaphore). > > bien entendu, cela est une proposition, je peut le changer, modifier. > > phil > WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 23:33:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vq-0005z5-00 for ; Tue, 21 Aug 2001 04:06:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:18 +0200 (CEST) Received: (qmail 7025 invoked by uid 0); 20 Aug 2001 21:34:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 20 Aug 2001 21:34:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01163 for ; Mon, 20 Aug 2001 17:34:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:33:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA32763 for f-cpu-list; Mon, 20 Aug 2001 17:33:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA32741 for ; Mon, 20 Aug 2001 17:33:20 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLXJa18008 for ; Mon, 20 Aug 2001 17:33:19 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA25377 for ; Mon, 20 Aug 2001 23:33:17 +0200 (MET DST) Message-ID: <3B818215.5720F8B4@f-cpu.org> Date: Mon, 20 Aug 2001 23:33:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] m4 won. References: <3B8058CB.5ADEF33C@f-cpu.org> <20010820073907.20382@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Mon, Aug 20, 2001 at 02:24:43AM +0200, Yann Guidon wrote: > > > m4 is finally the best choice, > > i am currently updating my files locally. > > i will then have to integrate Michael's > > data and i will post a "release candidate" > > that will be suitable for the CVS. > > > > It is going to take some time before i am > > ready so i am waiting for an update from Michael. > > Update for what, the instruction encoder? yes, or for whatever you have/want. since you sent me a "preliminary" package, i believe that a new version exists. > BTW: I created the first F-CPU object files yesterday :) and what does it make/compute ? :-) > > The good news is that it is not limited to C > > and VHDL, anybody can adapt a few line is a > > langage-specific file and make a verilog port, > > for example, without rewriting all the > > definition files. The existing files did > > not require big changes but there are tens > > of different stufss in several directories, > > it takes a while to check everything. Before > > putting the files on CVS, i have to check that all > > the released files are correctly under GPL (not mixing > > my own copyright on QDCPOC with the team's work), > > and i'll ask Michael to craft a nice Makefile. > > No problem. ok, i try to finish some stuff tonight. i have to finish the uniformisation of the opcode definitions (between C and VHDL), test the scripts and verify that the existing SW still works. it will be a complete GPL stuff and i highly recommend to reuse what i have written. I have focused on RTL simulation and synthesis with the availability of several options, but it is also very useful for SW like assembler and compiler. read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 23:33:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vq-0005z5-01 for ; Tue, 21 Aug 2001 04:06:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:18 +0200 (CEST) Received: (qmail 7236 invoked by uid 0); 20 Aug 2001 21:34:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 20 Aug 2001 21:34:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01235 for ; Mon, 20 Aug 2001 17:34:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:33:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA00375 for f-cpu-list; Mon, 20 Aug 2001 17:33:26 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA32699 for ; Mon, 20 Aug 2001 17:33:15 -0400 Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLXEa17995 for ; Mon, 20 Aug 2001 17:33:14 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA29556 for ; Mon, 20 Aug 2001 23:33:12 +0200 (MET DST) Message-ID: <3B818211.DEC0AD60@f-cpu.org> Date: Mon, 20 Aug 2001 23:33:05 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sun, Aug 19, 2001 at 03:23:50PM -0400, nicO wrote: > > Just one point about SIMD FP. I think that SIMD flag should means an > > others thing that for integer (no need for 8 bit). > > What about 16 32 64 128(80 ?) ? 4 differents precisions, the last don't > > need to be implemented in FC0. > > The manual says: > > 00 32-bit > 01 64-bit > 1x unassigned > > and the second one... the two first codes are allocated, so we can use 2 other reserved sizes, for example 80 and 128. > On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > > Hello, > > > > I'm looking for the "usual" definition of the port of a unit : > > > > 3 data in, > > Or less. > > > 2 data out, > > Or more. > > > SIMD flag, > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. oh btw, the SIMD flag is useful for an EU _only_ if you optimize for speed and/or consumption. This flag is forwarded to the units but it is used mainly for the making of the writeback mask (in the register set). > > clk, > > enable or start, > > reset, > > something for the exception ? > > > > If there is something to say if the outed data is correct or not ? > > Currently not; the scheduler should know. But we can add a `here is > the result, take it or I'll throw it away in the next cycle' signal. currently, only the IDIV has one. > Something is missing: the lines that select the instruction to execute > (if the unit can handle more than one instruction). ?? > Michael "Tired" Riepe WHYGEE "Gimme Doop, Joana" :-) (JBO) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 20 23:55:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vv-0005z5-00 for ; Tue, 21 Aug 2001 04:06:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:23 +0200 (CEST) Received: (qmail 25954 invoked by uid 0); 20 Aug 2001 21:56:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 20 Aug 2001 21:56:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA02106 for ; Mon, 20 Aug 2001 17:56:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:56:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA01866 for f-cpu-list; Mon, 20 Aug 2001 17:56:00 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA01863 for ; Mon, 20 Aug 2001 17:55:58 -0400 Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLtwa18422 for ; Mon, 20 Aug 2001 17:55:58 -0400 Received: from f-cpu.org (nas2-162.aub.club-internet.fr [195.36.133.162]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA25865 for ; Mon, 20 Aug 2001 23:55:55 +0200 (MET DST) Message-ID: <3B818761.B8B9E367@f-cpu.org> Date: Mon, 20 Aug 2001 23:55:45 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Scheduler References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B8083F0.1492B76D@ifrance.com> <3B809F00.8E7C5A3F@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > A much more explicit scheme, i hope ;p it's a bit better... but the picure is even larger and i can't display it completely. i don't understand all the signal meanings and types either, and some parts are detached from the rest, i don't see what their use and place is... Is it possible to meet and discuss about it ? > nicO > > nicO a écrit : > > > > I send you a scheme of a bypass net. > > > > The "Active" signal is the number of the active unit. On the same > > pipeline stage, there is only one active unit. For each active stage, i > > compare the address of the 2 write registers to the 2 registers in use > > by the instructions of the stage. I only drawn the system for one > > register (not the 3 read register) and only for one pipeline stage. > > > > I try to make a more clear one. > > > > nicO > > > > ------------------------------------------------------------------------ > > [Image] > WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:06:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vw-0005z5-00 for ; Tue, 21 Aug 2001 04:06:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:24 +0200 (CEST) Received: (qmail 29711 invoked by uid 0); 20 Aug 2001 21:57:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 20 Aug 2001 21:57:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA02388 for ; Mon, 20 Aug 2001 17:57:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:56:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA02148 for f-cpu-list; Mon, 20 Aug 2001 17:56:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA02145 for ; Mon, 20 Aug 2001 17:56:52 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLupa18440 for ; Mon, 20 Aug 2001 17:56:51 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 95FCE3B2 for ; Tue, 21 Aug 2001 00:06:14 -0400 (EDT) Message-ID: <3B81DE36.9D571C3F@ifrance.com> Date: Tue, 21 Aug 2001 00:06:14 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: optionnal instruction References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <20010819205531.17305@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sun, Aug 19, 2001 at 09:55:25AM +0800, Glenn Alexander wrote: > > > I'm new here, but aren't we developing a concept implimentation called FC-0 > > and is complicating matters with 128-bit FP really useful at this stage? This > > is (i understand) intended to be a general purpose processor so shouldn't we > > be looking at general purpose cases that apply to normal users? I think if a > > special application needs 128 (or more) FP, they are more likely at this > > stage to be on a purpose-built mainframe. Later that may be different, but > > later FC1 will be done (hey, lets be optimistic) and since the F-architecture > > is already designed to go above 64-bits, implimenting a full 128 (or more) > > F-CPU is just something you do. > > There are, in general, two reason why one wants large floating-point > types. One of them is precision (as some of you mentioned, that's a > rather rare case), the other (and more important) one is the increased > range. People often use IEEE double not because they need >6 digit > precision but because single has only 8 bits for the exponent -- and > sometimes 11 bits aren't enough either. > > But I agree with you: there's no need to worry about FP with more than > 64 bits for the FC0. In fact, the FC0 may not have FP hardware at all > (it's all optional, IIRC). > Yep, but we need to defined precisely the group of insrtruction to be defined. I think is to difficult to handel a compiler if almost all instruction could remove or not. I propose an FP group, a mul group (large interger unit : mul+divide?). I think it could have other proposal. nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:09:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vx-0005z5-00 for ; Tue, 21 Aug 2001 04:06:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:25 +0200 (CEST) Received: (qmail 8685 invoked by uid 0); 20 Aug 2001 22:00:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Aug 2001 22:00:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA02703 for ; Mon, 20 Aug 2001 18:00:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:00:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA02463 for f-cpu-list; Mon, 20 Aug 2001 18:00:18 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA02460 for ; Mon, 20 Aug 2001 18:00:17 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KM0Fa18491 for ; Mon, 20 Aug 2001 18:00:16 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D0D833B2 for ; Tue, 21 Aug 2001 00:09:37 -0400 (EDT) Message-ID: <3B81DF01.4103E718@ifrance.com> Date: Tue, 21 Aug 2001 00:09:37 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sun, Aug 19, 2001 at 03:23:50PM -0400, nicO wrote: > > Just one point about SIMD FP. I think that SIMD flag should means an > > others thing that for integer (no need for 8 bit). > > What about 16 32 64 128(80 ?) ? 4 differents precisions, the last don't > > need to be implemented in FC0. > > The manual says: > > 00 32-bit > 01 64-bit > 1x unassigned > > and the second one... > Yep, but you speak about an 16 bit shunk size. > On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > > Hello, > > > > I'm looking for the "usual" definition of the port of a unit : > > > > 3 data in, > > Or less. > Yep! > > 2 data out, > > Or more. > MORE ? I beleive that the fc0 is 3r2w (which give the number of register bank port). So ? > > SIMD flag, > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > The same of the instruction ? > > clk, > > enable or start, > > reset, > > something for the exception ? > > > > If there is something to say if the outed data is correct or not ? > > Currently not; the scheduler should know. But we can add a `here is > the result, take it or I'll throw it away in the next cycle' signal. > Maybe, it's not useful but it could at least help for debugging. > Something is missing: the lines that select the instruction to execute > (if the unit can handle more than one instruction). > Could have many enable flag, corresponding to each differents instructions ? nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 00:12:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vx-0005z5-01 for ; Tue, 21 Aug 2001 04:06:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:25 +0200 (CEST) Received: (qmail 10964 invoked by uid 0); 20 Aug 2001 22:12:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 20 Aug 2001 22:12:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA03430 for ; Mon, 20 Aug 2001 18:12:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:12:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA02941 for f-cpu-list; Mon, 20 Aug 2001 18:12:20 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA02934 for ; Mon, 20 Aug 2001 18:12:18 -0400 Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMCHa18669 for ; Mon, 20 Aug 2001 18:12:18 -0400 Received: from f-cpu.org (nas2-164.aub.club-internet.fr [195.36.133.164]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA07890 for ; Tue, 21 Aug 2001 00:12:14 +0200 (MET DST) Message-ID: <3B818B37.83211BD9@f-cpu.org> Date: Tue, 21 Aug 2001 00:12:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: optionnal instruction References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <20010819205531.17305@thrai.stud.uni-hannover.de> <3B81DE36.9D571C3F@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Michael Riepe a écrit : > > But I agree with you: there's no need to worry about FP with more than > > 64 bits for the FC0. In fact, the FC0 may not have FP hardware at all > > (it's all optional, IIRC). > > Yep, but we need to defined precisely the group of insrtruction to be > defined. I think is to difficult to handel a compiler if almost all > instruction could remove or not. I propose an FP group, a mul group > (large interger unit : mul+divide?). I think it could have other > proposal. there is already an FP "group" in the instruction census. It is divided into several optional subgroups, where instructions are emulated when the corresponding unit is not available. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 00:12:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vy-0005z5-00 for ; Tue, 21 Aug 2001 04:06:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:26 +0200 (CEST) Received: (qmail 12707 invoked by uid 0); 20 Aug 2001 22:12:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 20 Aug 2001 22:12:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA03437 for ; Mon, 20 Aug 2001 18:12:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:12:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA02951 for f-cpu-list; Mon, 20 Aug 2001 18:12:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA02938 for ; Mon, 20 Aug 2001 18:12:19 -0400 Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMCJa18674 for ; Mon, 20 Aug 2001 18:12:19 -0400 Received: from f-cpu.org (nas2-164.aub.club-internet.fr [195.36.133.164]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA07906 for ; Tue, 21 Aug 2001 00:12:16 +0200 (MET DST) Message-ID: <3B818B31.24F958E9@f-cpu.org> Date: Tue, 21 Aug 2001 00:12:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B81DF01.4103E718@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Michael Riepe a écrit : > > On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > > > Hello, > > > I'm looking for the "usual" definition of the port of a unit : > > > 3 data in, > > Or less. > Yep! > > > 2 data out, > > Or more. > MORE ? I beleive that the fc0 is 3r2w (which give the number of register > bank port). So ? some units have "variable latency". IE the multiplier can give results with different latency, depending on the data chunk size. The different outputs are then "mixed" with the Xbar (sorry : the big mux). > > > SIMD flag, > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > The same of the instruction ? i don't know : Michael uses a specific strategy. > > > If there is something to say if the outed data is correct or not ? > > Currently not; the scheduler should know. But we can add a `here is > > the result, take it or I'll throw it away in the next cycle' signal. > Maybe, it's not useful but it could at least help for debugging. at least. > > Something is missing: the lines that select the instruction to execute > > (if the unit can handle more than one instruction). > Could have many enable flag, corresponding to each differents > instructions ? i still don't catch the precise context. > nicO WHYGEE "programmer ou dormir, il faut choisir"... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:33:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vy-0005z5-01 for ; Tue, 21 Aug 2001 04:06:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:26 +0200 (CEST) Received: (qmail 28921 invoked by uid 0); 20 Aug 2001 22:24:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 20 Aug 2001 22:24:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA04015 for ; Mon, 20 Aug 2001 18:24:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:23:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA03744 for f-cpu-list; Mon, 20 Aug 2001 18:23:55 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA03739 for ; Mon, 20 Aug 2001 18:23:54 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMNpa18790 for ; Mon, 20 Aug 2001 18:23:52 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C23853B2 for ; Tue, 21 Aug 2001 00:33:15 -0400 (EDT) Message-ID: <3B81E48B.1B9C5D1E@ifrance.com> Date: Tue, 21 Aug 2001 00:33:15 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Aug 18, 2001 at 10:09:39PM -0400, Lee Salzman wrote: > [...] > > >Unfortunately, the term `general case' means four(!) successive loadcons > > >instructions (or similar). There is no way to optimize one or two of > > >them away because the compiler/assembler doesn't know which value is > > >loaded. > > > > The linker can handle whatever optimizations are necessary for efficient > > relocations or else it is a very sad linker indeed. If this means > > providing several alternatives patches of code to fill in depending > > on the distances, then so be it. Too much focus has been put on > > optimizing at compile time traditionally when it is quite beneficial > > to do it at load time. The distances between code and data sections > > are very well known at this peculiar and oft ignored time. > > Linkers cannot insert code when necessary, nor can they remove > superfluous instructions. They can just overwrite them with something > different. > > > >You might say: "use PC-relative addresses". But that doesn't work > > >either -- in fact it's even *worse* than using the absolute address > > >because you need four loadcons instructions to put the relative address > > >into a register, and then you still have to execute loadaddrd (that is, > > >you need one instruction *more* for relative addressing). > > > > I don't see why you couldn't just use loadraddrid here and fall back > > to loadaddrd if the distance is too large. > > Because it makes almost no difference. You have to provide space for > the longest possible load sequence, and fill it with NOPs or similar > when a shorter sequence is used. Bigger code, longer delay. Besides > that, it makes the link editor more complex; I'd rather not do that. > > > >The same is true if you use a `base' register that points to the > > >beginning of the data section and calculate the distance to that point. > > >You still need 4x loadcons + 1x add to get the variable's address (and > > >yet another instruction if you want the data to be prefetched, because > > >`add' doesn't do that). > > > > The distance of the variable from the current PC is easily calculated > > at load time so a loadaddrid can be use great utility here, as has > > been noted. > > How many programs do you know that fit into 128K (including the initial > working set)? My /bin/bash needs >400K (on ia32 -- that's CISC, not RISC). > I just could add that x86 code could be much compact than even ARM thumb code. > > >A module-local base register is also possible, but you'll have to save, > > >set and restore it in every function that is not module-local (e.g. has > > >`extern' linkage in C) and uses global variables -- and you need the full > > >`quadruple-loadcons' instruction sequence again each time you access a > > >global variable that belongs to *another* module (just in case it isn't > > >clear: `module' means `source file'). > > > > Not quite... a function need only have two entry points - one entry > > point is module local and does nothing while the other is for the > > non-local > > case and sets the current module. Calls to non-local functions are > > responsible for setting the current module after the non-local function > > returns. This allows for efficient local calls that pay no penalty at > > all. > > That bloats external function calls with `base restore' operations. > But the idea is interesting. Gotta think that over. > > > Additionally, one should not neglect the effectiveness of redundancy > > elimination when applied to constant loads. > > > > When that fails... hasn't anyone told you that global variables are > > evil anyway? :) > > I learned LISP ~20 years ago. (questionsp 'any) > > There is also constant global data. String constants, for example. > Or jump and lookup tables. > > > >Any other ideas how we can reduce/avoid the `address load penalty'? > > An add coupled with a prefetch for data address loads off a > > base/module register would be very nice. Possibly an immediate add > > that some how supported longer immediate constants would be nice too, > > but that could be done without. > > The `address add' idea looks better and better, and it's good for > pointer/array/structure accesses, too. > Hum i don't like that at all because you schould put an adder just before the memory unit. So we just as to make the pipeline longer. One of the key point of the FC0, to shorten the pipeline, is to put in parrallele the ALU and the load&store unit. If we put it in serial, we longer the pipe. So i think, it's much better for that case to use 2 instructions. Never forget that it's adding an other addressing mode . nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:36:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w0-0005z5-00 for ; Tue, 21 Aug 2001 04:06:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:28 +0200 (CEST) Received: (qmail 14776 invoked by uid 0); 20 Aug 2001 22:27:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 20 Aug 2001 22:27:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA04346 for ; Mon, 20 Aug 2001 18:27:24 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:27:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA04094 for f-cpu-list; Mon, 20 Aug 2001 18:27:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA04091 for ; Mon, 20 Aug 2001 18:27:05 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMR3a18819 for ; Mon, 20 Aug 2001 18:27:03 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 7D5833B2 for ; Tue, 21 Aug 2001 00:36:27 -0400 (EDT) Message-ID: <3B81E54B.C0FD92D1@ifrance.com> Date: Tue, 21 Aug 2001 00:36:27 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Execution unit port References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B805E66.578CB9EC@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > nicO wrote: > > Hello, > > > > I'm looking for the "usual" definition of the port of a unit : > > > > 3 data in, > > 2 data out, > "as much as needed" > (ASU could have 4 output ports but this is not yet completely determined). > > > SIMD flag, > > clk, > > enable or start, > > reset, > > something for the exception ? > except for the SR unit, no EU needs to report exceptions > (protection violation, but the pipeline is stalled at issue > when the SR EU is used). > > FP units can report exceptions if the "IEEE flag" is set > (again : the pipeline is stopped until we are sure that the > result is ok). > > concerning the "necessary flags" for example, ROP2 requires the 2 mode > bits and 4 function bits. Some transation and buffering of the 4 function bits > is performed during the Xbar cycle. > > > If there is something to say if the outed data is correct or not ? > no. Data are discarded "implicitely" by the Xbar write stage, > by choosing a proper source for the proper register and with the right write mask. > > > Does i miss a signal ? > no, except for very special cases, it does the trick. > there's no magic :-) Yep, but we need something more precise. In that case, it will be much more easy to add or remove unit. Special case could became very boring to handel... nicO > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:47:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w0-0005z5-01 for ; Tue, 21 Aug 2001 04:06:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:28 +0200 (CEST) Received: (qmail 19268 invoked by uid 0); 20 Aug 2001 22:38:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 20 Aug 2001 22:38:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA05849 for ; Mon, 20 Aug 2001 18:38:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:38:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA05623 for f-cpu-list; Mon, 20 Aug 2001 18:38:12 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA05620 for ; Mon, 20 Aug 2001 18:38:11 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMc9a18933 for ; Mon, 20 Aug 2001 18:38:09 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BB31A3B2 for ; Tue, 21 Aug 2001 00:47:32 -0400 (EDT) Message-ID: <3B81E7E4.6FB0F020@ifrance.com> Date: Tue, 21 Aug 2001 00:47:32 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > Michael Riepe wrote: > > On Sun, Aug 19, 2001 at 03:23:50PM -0400, nicO wrote: > > > Just one point about SIMD FP. I think that SIMD flag should means an > > > others thing that for integer (no need for 8 bit). > > > What about 16 32 64 128(80 ?) ? 4 differents precisions, the last don't > > > need to be implemented in FC0. > > > > The manual says: > > > > 00 32-bit > > 01 64-bit > > 1x unassigned > > > > and the second one... > > the two first codes are allocated, so we can use 2 other reserved sizes, > for example 80 and 128. > > > On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > > > Hello, > > > > > > I'm looking for the "usual" definition of the port of a unit : > > > > > > 3 data in, > > > > Or less. > > > > > 2 data out, > > > > Or more. > > > > > SIMD flag, > > > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > > oh btw, the SIMD flag is useful for an EU _only_ if you optimize for speed > and/or consumption. This flag is forwarded to the units but it is used mainly > for the making of the writeback mask (in the register set). > So the SIMD stuff is for the same thing for register bank. But we should always take good habit for improving power consumption (speed and blablabla). nicO > > > clk, > > > enable or start, > > > reset, > > > something for the exception ? > > > > > > If there is something to say if the outed data is correct or not ? > > > > Currently not; the scheduler should know. But we can add a `here is > > the result, take it or I'll throw it away in the next cycle' signal. > currently, only the IDIV has one. > > > Something is missing: the lines that select the instruction to execute > > (if the unit can handle more than one instruction). > > ?? > > > Michael "Tired" Riepe > WHYGEE "Gimme Doop, Joana" :-) (JBO) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 06:52:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w1-0005z5-00 for ; Tue, 21 Aug 2001 04:06:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:29 +0200 (CEST) Received: (qmail 21658 invoked by uid 0); 20 Aug 2001 22:43:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 20 Aug 2001 22:43:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA06175 for ; Mon, 20 Aug 2001 18:43:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:42:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA05958 for f-cpu-list; Mon, 20 Aug 2001 18:42:51 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA05951 for ; Mon, 20 Aug 2001 18:42:50 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMgna18969 for ; Mon, 20 Aug 2001 18:42:49 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2B0A33B2 for ; Tue, 21 Aug 2001 00:52:13 -0400 (EDT) Message-ID: <3B81E8FD.D5A51C6@ifrance.com> Date: Tue, 21 Aug 2001 00:52:13 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: optionnal instruction References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <20010819205531.17305@thrai.stud.uni-hannover.de> <3B81DE36.9D571C3F@ifrance.com> <3B818B37.83211BD9@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Michael Riepe a écrit : > > > But I agree with you: there's no need to worry about FP with more than > > > 64 bits for the FC0. In fact, the FC0 may not have FP hardware at all > > > (it's all optional, IIRC). > > > > Yep, but we need to defined precisely the group of insrtruction to be > > defined. I think is to difficult to handel a compiler if almost all > > instruction could remove or not. I propose an FP group, a mul group > > (large interger unit : mul+divide?). I think it could have other > > proposal. > > there is already an FP "group" in the instruction census. > It is divided into several optional subgroups, where instructions > are emulated when the corresponding unit is not available. > Yes, we speak about that since a long time but now we something more precise. nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 00:43:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w4-0005z5-00 for ; Tue, 21 Aug 2001 04:06:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:32 +0200 (CEST) Received: (qmail 22288 invoked by uid 0); 20 Aug 2001 22:57:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 20 Aug 2001 22:57:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA07246 for ; Mon, 20 Aug 2001 18:57:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:56:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA06518 for f-cpu-list; Mon, 20 Aug 2001 18:56:39 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA06515 for ; Mon, 20 Aug 2001 18:56:38 -0400 Received: from tribble.stud.uni-hannover.de (root@a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMuZa19091 for ; Mon, 20 Aug 2001 18:56:36 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01913; Tue, 21 Aug 2001 00:43:25 +0200 Message-ID: <20010821004325.16303@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 00:43:25 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B818211.DEC0AD60@f-cpu.org>; from Yann Guidon on Mon, Aug 20, 2001 at 11:33:05PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 20, 2001 at 11:33:05PM +0200, Yann Guidon wrote: [...] > > > If there is something to say if the outed data is correct or not ? > > > > Currently not; the scheduler should know. But we can add a `here is > > the result, take it or I'll throw it away in the next cycle' signal. > currently, only the IDIV has one. No it doesn't, but I can add one :) > > Something is missing: the lines that select the instruction to execute > > (if the unit can handle more than one instruction). > > ?? Signals like Sub/Saturate in the ASU, or MacH/MacL in the IMU. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 00:40:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w5-0005z5-00 for ; Tue, 21 Aug 2001 04:06:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:33 +0200 (CEST) Received: (qmail 1263 invoked by uid 0); 20 Aug 2001 22:57:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 20 Aug 2001 22:57:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA07404 for ; Mon, 20 Aug 2001 18:57:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:56:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA06567 for f-cpu-list; Mon, 20 Aug 2001 18:56:42 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA06549 for ; Mon, 20 Aug 2001 18:56:41 -0400 Received: from tribble.stud.uni-hannover.de (root@a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMuca19095 for ; Mon, 20 Aug 2001 18:56:38 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01898; Tue, 21 Aug 2001 00:40:20 +0200 Message-ID: <20010821004020.29391@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 00:40:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] m4 won. References: <3B8058CB.5ADEF33C@f-cpu.org> <20010820073907.20382@thrai.stud.uni-hannover.de> <3B818215.5720F8B4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B818215.5720F8B4@f-cpu.org>; from Yann Guidon on Mon, Aug 20, 2001 at 11:33:09PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 20, 2001 at 11:33:09PM +0200, Yann Guidon wrote: [...] > > > It is going to take some time before i am > > > ready so i am waiting for an update from Michael. > > > > Update for what, the instruction encoder? > yes, or for whatever you have/want. > since you sent me a "preliminary" package, i believe > that a new version exists. No, the code is still the same. If there's nothing wrong with it, I can put it into CVS. Somehere below f-cpu/compiler, I suppose? > > BTW: I created the first F-CPU object files yesterday :) > and what does it make/compute ? :-) Nothing... the source just contains every instruction variant we've defined so far, plus the 79 asm directives I implemented (don't worry, there are some aliases on the list). The only thing that's still missing is the relocation table. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 20 07:24:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0vr-0005z5-00 for ; Tue, 21 Aug 2001 04:06:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:19 +0200 (CEST) Received: (qmail 4876 invoked by uid 0); 20 Aug 2001 21:34:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 20 Aug 2001 21:34:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01270 for ; Mon, 20 Aug 2001 17:34:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 21:33:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA32746 for f-cpu-list; Mon, 20 Aug 2001 17:33:20 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA32724 for ; Mon, 20 Aug 2001 17:33:18 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KLWwa17985 for ; Mon, 20 Aug 2001 17:33:04 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BBDEC1615 for ; Mon, 20 Aug 2001 01:24:16 -0400 (EDT) Message-ID: <3B809F00.8E7C5A3F@ifrance.com> Date: Mon, 20 Aug 2001 01:24:16 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Scheduler References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B8083F0.1492B76D@ifrance.com> Content-Type: multipart/mixed; boundary="------------4CE1A7D1CBDC6ECE454937E2" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Il s'agit d'un message multivolet au format MIME. --------------4CE1A7D1CBDC6ECE454937E2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit A much more explicit scheme, i hope ;p nicO nicO a écrit : > > I send you a scheme of a bypass net. > > The "Active" signal is the number of the active unit. On the same > pipeline stage, there is only one active unit. For each active stage, i > compare the address of the 2 write registers to the 2 registers in use > by the instructions of the stage. I only drawn the system for one > register (not the 3 read register) and only for one pipeline stage. > > I try to make a more clear one. > > nicO > > ------------------------------------------------------------------------ > [Image] --------------4CE1A7D1CBDC6ECE454937E2 Content-Type: image/gif; name="bypassnet2.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="bypassnet2.gif" R0lGODdhVwVTA4AAAAAAAP///ywAAAAAVwVTAwAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+x2FwCPw3VzN0Iuv+EB9sO+XrPXN0hYaHiImOiTdwc4w2gHaRBH88fnJhlA+fin6PkJGio6 muioYPrCt4l5yYDK4piJ9urXmmorS6q7y9vr+7to2yAMs8pGm0CsgppLhnxXTGwMTF1tfY2d 7TDtqtzCPftcm9rtLQZ+am6ijK7t/g4fL3/GnVcnjtLuzEx5r07iTd+Xev0u4Vt2cJ7ChQwb OgwmbJNEdh7ECTxnaqJB/oodEmryqGWaxkkcOSQE+TClypUsW16QFAsQrpEk8Syw9OoiGJgz W/Xc6FNQOksPdG7h2chnUqC1bA7t1M2l1KlUq1o1hhXX0o01mybrOQzl0ZgzoTX11zXtOK9F xV7JWtbPVpJqRYIN+8+q3r18++qC28gs22RDB380Z9QL4LWTvpYcvHhbXsVkA8tNerOw2sPl mvn9DDq06HBBI2rF/FVzJnSJ38jMeNowXcc1Tf9z+/a1acGbZ6Nejczp6OHEixuvsioybGk4 gdoud0w36o+0HRM9/DzsmuSVfffGDhX47dbHy5s/j/6bdMaaNFvGm919Gu5xG1d/3/l+uuil /vEzZ97WchCQl16BBh6I4ASM0Mfed/jYhRd/TNX1334BphaVhBQGJZ930OEXYYIijkhiiTdJ tyA7/ETAnWST7YTiRCcCOOBr20QSI1odUlcjhyziZmKQQg5JFX3OfTgdYWdZBGQWRtaGpGyX 1fbMi2M8iV2U39lHpZUEEglmmGIq9KWDOYF4YRtlcqbflDwO6Mp8QBL0GG5Njolnnnr28iU4 SHnYYx995pRVg8NkKKeVSZ713kEV7glppJJaIwtrhEIFnlAzDlIpLX5el6lwXYqa6KM7hqob qFluOWmrrr6KSHMzkgreU5guueZYquLKD52gNncnFrLa6ut/qt4K/muyyi7LkHOeueRsrvJE Gyyz1l6LLSjB8bXtXt1mC2644v6ljqLNlustuuOuy267gn5bVTvmLiSvu/beiy9Gds1Lpnjp 7ptvwAIPPMWw3OLkl8EEL8xww0Ro+hnECdPqcMUWX4xxxhpvzHHHHn8Mcsgij0xyySafjHLK Kq/McssuvwxzzMnyC61xNE9rksw675zBzSz5vBLQ7wgtNM9Gr1z0Q0k7tDQ2RB8NddSn2Ey1 Xk9LjTXUTTdb9VU5P/Fs1mIXuDW9XVezqwRXK1hfPp6qUu3Yclt99mhlbwcwBWur3fYJn0o5 d+DH3T0P4ThTU6Wie/+I5joq8iZ45HWL/mZ4PJWX4aiCX7MNeEdsXy556GROHhro+jLO4uZ8 d76BR9KKDnvQpINmOozG8ph563rbKEJir8cOfEO1ZzO807/kLSOcun9uqEmWthl89N7OHrEv f9aV+vIBAsvrrEZq5E/a0o//M/UJW9+dd5Mt3tmw6bO5oXXxkU+/VMVfcz+l6N+lfvYaKN42 SBRqOp+aX/0OqJL8oc18n2CQf/zXs93JJn1nAlzeEIhBpTGQW/szTIuU9z8JAso6rFpUb36X wRSOQoGI26AiHNg/CGIgL8Aq1oRctCkTqnCH2mAhMHx4vP3d8IMgjOD2FEaTixQQejxsov6K A0TrHS9HXFGb/uragqbuKPFSTHSiF6UIRRd6AkthU1IIV9egxeSiPx1C4RffqCYxem2KW2Of dtKoRT9ZUEBw7CMvosgnOY4xbu3RXo0mSEGY6PCCfmxkKAD5R0EOsld6u2KI3sQrQexKIoty oyM/uRNJTgWSIUFYJQ0pmcY5BS4FLA34ygjKWM5ClPabHipliUsDkfIvtCycJXMJTPPskhTD XKEtzxjMZAqzly0pJqd+qcxolo6Z5aPbLaWJzfOFcZtzRGY2v9kXZz6SmvCwIzjPWUtuDkec kYAmOt+ZQHLG05rehKc950kcdjbwmEa8pz81qE678XOG/yyo8OSZEn3G8ZoGbSjx/hAK0G72 06EUfWhAKTfQl1R0o8a76DTpOVGOijSQHqVdRi2g0JGqNAkpLQVELVrPlcp0nyWtHkgJOtOc 0jSfL+1oTHUK1GfWVJsSxWlQjypUng5VdgxFqlPp0VOu3VSjT62qGloaq6g+8adW7Wool8rB qaLUq2S9klZHJ9YKYLWsbO3dWX2Z1lO2da5OeuvhikpVuuoVOXa13EnVutfAFqyv5fyrXAWL WCas1RCLLURjzWDOxEp2CI9N6joNq7nJatYIlRUUYUnK1c2KdgedbSdYE+rO0arWBqXFxGcj 2dTVylYGrV2oUvE61tnqlrWv7SFmrbjb4NK2tzCNV2qF/ovcEtT2GMQl5nGTC10QLHc7zTVm bKOLXc+dNq7VDG12v+vdcFZXFJEFr3lze9vLche4521vSDG6XaY91730zUx8jbteGdZ3vze6 b5F+q1/+CtiM6k3vf6874P1O96rjHSeCE0zfBc+nwdqaL4TbK+FZ+tdsD77weTMM1Q2jNbwe xjCFfwjgIpZYwCCG7InHaOEVZ7fFmHvxC2Ms4+jS2Bk2dmmHc6zjHsMWt4AFMn93bFYRw5XE Rg6ykpuZ4qI0WcFC3gWSrVDeKTvZwPAl8mG1bN4rh0HMX/VyZsH84SrzMr8qRvOM1excNkvZ zWGGs3XNzF46v/nJ3cUvk/Us/lsyD8TOljUqoLdc4EQf+M+HHq2gFUNoz/640Zt99BsibVpG U1qzluZCp48S5f5uGrmfDgmmXTvpUSe21HXlc2FTrWrBslpYp7bte2O92lm/pdbMhTWu9apr LPOaur7+9VyDzVdXDw3Hxgb2sLNKzBpKe9rUrra1pd1slSKbCtsebJxrnG2RdlsK445CuSsS 4nBv9NxgezZl061uirLbCfNuQr01vet4V/TeS+C3EvydVx7rW97uZuyawT3whgIcCQs/QsO/ fI6EO/ThRaD4ww4ucIkX1OLvVraGEa5xf3JcCCMPQslFnfGQ3/PkP2D5IjCeZJWvvOCOhfmY XS7z/nHhnAc7J63NKUPInL+x53SgORCQbQ+h25PoOWA6DpxeSKArRenvhDpvPQ7vUmaE6lU3 eqErrKvHcD2bVg+E11/upHqNHZxlr8TZeyDosLV97ZKa+3Cx7mLk6MTudN8T34vxdp5z23d9 J3vgbe1gKMAScoUP5t/JgXeQK7ZPjZfm411w+W/83OFrynzlh+T5FYR+GZuveK5G//kSoT4f hy86vcu0+tSLKPbraH3TzU0g2sv+QLoHiO2fXrDW9H736Rm+WyOfctyfhPi5NH4InC/d0r/+ QQkKekcoxnyG/37C38ayPqDvNuu3DlnZ1z7yOXxnYbFGl/CrxE/K3+/t/n+cvK5hBoI8+b/b wd/8XP5o+sPOeOeBf7fWfvt3cec3YvRnOwZxf+JnaDpkgEcnf1kHdjc3gM3kgNKVgRFYewi4 ZAp4JRv4SJoiHNj3OphSgmV0gRzYgf1nUt0Xc//WJKcXNzBUgJYCNDbISDnEgh3ngjb1fxE3 eT5Dg0ljKjvIOnkWPxDYPD2Idj9IVCCYfAw3g1VYNJR0Qm9DhEfIR3fkhCQ3gXkXhGNmb1aY f1doMEhYQj9iSjeYOF94gFAoXjAohP1mhj1TLQ/ShV2ERjjEhCIIh8cnh2E1hmUmg1uIiNcX KBBIg4vYOYAYiM8XhpJXgVPIeYmIh2joiKzS/ohp8oiRGIeK1mVSGIMsdYczlIeekoUBcYpK oobgV2ceeFekWIeHeIa36DwloYYFqFYV5IbSECeg6HOy6Fd0SIZDiIuoaIQDtCrNyIewQUKM IUAigSiYNELC2IKi6H+0eIx2iInKWBHHwj2n0ow8cSs1lEmstBTYKHqTaIkwJoa2mInJeH2t dEOZpB/26D0b0oa/yI7tSIyvtkLXRpAFaZAHWYbf+BKQ+I8CqY0viGcBhjcKiVIM2ZDuAIva NYioVWxAR48VmZEXyWyj5I75hm8W+JG9GJIieZLptJERRYBX1YogyZIvGZGhdlAdWX8puTsr WZMBJ1ABCVoxmSg8/sk8PzmKQWmTOdmSAzGTKomUSSmV27hoREkaRsk3PhmVZ/aQQOhnVkkP T9mTWwmRXRmFVfmAaiKWR0mWc7iUaEmSOulpa5mVbXmWU1mWcIleOEKRUGmXhGiWbvmVackf WMmGfwmYShmY+ASWkEWXh4mYcnaTksmUjYk5j7mJkRmXb7mZgwmUatmXY6mZnkmVeAllcqkr hpmZo3manOmSpFlk7xKabMmaNSOUGImTwSibqumJtdmai5mb6GeZ+zCbdembtumayAmbEFeY 8+icx9lniimdnUmYE8mbfgidTJWcv6mXscmX13lJ2cmR2xmd1PmZzQmOzymeMDmdpfma/tWp fAcpn/NJnxKzntyomVkGNhYJd/x5n6AGnfq5n8G2gv9Zi7UpoAPqlFr5jwwKVAmqoHPpoOw4 oTkFoRGadhWKjRoqUxeKod7HocIYoto2ktOXGyMKiigqbiVqooOnopH4ouvGoi2qfAa6QAE6 ozSqozYKRsfpocGXYQXKoxTIc/VppEeKpEmqpEvKpE3qpE8KpVHapLkopVVKkAk5pDcqgbfp W/EInzspj1mKYiZXkgdqpnsZgq0lpGLqpXBXpt34jsyJkpzln2xqiE8InJRpksOpdaYXow25 Vn9qX+RpbjnqopRVp3Z6p27KpcVViudJnCaXqIo6aGTaqD4V/qdceZUQQalb1XJvuqhw+qVp 2p+CKpKBCqqVSoloWpR0MKmdqqqfeqn4Q6TeaZ1P96qwCmmWSqiM+aisKpO7tKa6Wquu16vj malKiJ60lavEemnjZ6VMSm9UGq1JOq3QWq3Wyqt8qi/Zap/O2qPcyqiKZah6cK1Naayyiq6x 0qzganCoeXXkCq9mZ2/lGq/qKq6T5K7mCawOd675Oozyuq7At62jSi6mmqU/Knj1Oq9ux7AD a64FC6l80q77+nX9yln/arBg+LAAm654urEDibBDqrABG38N+wgaO7EVx7EQ61gVa7GZ5rG3 17Ehu6UCO7MEe7M5y1gwG7OIt7Kh/vhv9kqvOGuz+AqyQXuwP1ueGMuyNau0LXuyLlu0SBu1 Isu02smz9zq0KHt3Rnu1O5u0TmtlPpu13Ee1Dgu2ZOuDU7u1VTu2tvpDZnu2xaqpLKWybCu1 XZu2KSuxeou1dStfXhsDElayH4u3hAt4fyu3dCS4g9u3X+u2Rxu3Gau4kCe2YTuCI8ujh0uz a9u4/gq1gJu5Cxu5rMC5Nuq5Oju5mlu5T3u6i1u6oUuxqWugqxuxoCunlqu7d8t/Vku6m3u7 1PZHdUS0atu6wfu6Quu64wq8tFu8aKgwuApmOHiwxnu5mJe30Mu8v0u5zru8Elm7H7AvZrt4 AyYvTgc3/tgbu5ibvNzbtnz7tsgbvm3muOGoIjC7vtUbHJWlUPiHu1ybuO2rvaMLv3sLvs2r r/gbngdMm0amdg/zv9YXwHA7wPPrt72rrN6bwMrbQISUvm4RdMM6WySMEBPMvhgsufL7vab7 vrsLu88Lw2W7NN8nFp5kwrmmiiB7vl74fBR8vBn8wr4ruhosvjFcv3NGKSCcOCDRw6uZY3/T JVJCfqHChtOYghSDRN+Knfgrn9P3xe43n2CMkGIcxkN4xtnYwi/ExOPxE+X7Pa5Dt3QlxQTE g5HBiwSGx5gEIYjERsZJvkRLvMQ7w/GrwN4jK4RMxLz7toM8bQ5Mv4dcCm3s/onv44ZMyIcl ho6F4YuQYUAYwh7quBl7bCpQDLHLiG2KvMFF3MiPrMpH3L2QfESJ/MiFLMAevMD1mCZYnI82 2MUQTCj7aCG/IXZt1En84y+A4jtAnL2aZ8C2zLiMvMaI68LTzK41zCQ+soqgnMc82GR13EXc MyjWCx+MQkDT+8vlarjbC82zK82S/LkyvMjRS77ZnB+YvHg5rFrrpyXXuIYuwkWIbM6enIuS 2MywwM7zHMvvjMsmm8QohziUnM4Sg4NGoc+OdsPB3MAquYdpQcp9s5ApbM2sy8LwTNIXPNK5 K8+rPL4MXM5sgYQ0YcorRh600sTYyj/q04XQCK0G/k21joxt7bzSsPw56PjK9svKKT0qRHHU SjzUSN3SuhyeltzH/5yEHmbDgZHMtjKoXV2O72ND5PgiACzIrlzLCm3IDU0sCNPUEI3SJp2O mnTWLB3PSk0IbmTDf+yPHnQSc3xsbzglr+iMbjI194HHVd3PUTfTKb3Oz4zWCMzBal3XHSzL 2iLR3vzROW3Rft1W6esfyxEXojIehg3WMXHFjZPYp5zQC/3Y0YzEcH3LDg3bd33ZbZLZSbLZ tgsyrYRHZAEx4tPLv4Eq1SY/PUzWBw2QRgzVrx3ZlU3Z1OzcuVzQc1Hc4XEPwy13nE1WxP3V or1G2Ffd+lcr8DOO1J2V/uAd3QRW0s0t1A/91E693rIt2YfwO0EtzOW7JP8M3OJJLS1VwZHM 3q3tzsyd3tBt4AL+uGMCL9U82wCe1A0uxPHd3s892fOd4CRSJQNO16zN4UQN2Q9u4bF94Bt+ 4Qq+4Awe4hYc4CT+4Qxd4BUu3y9e4rO31e6tm0Pc4cud467N4jyu0nY947rUj+/t1iue1jL+ 42+d4g4+4h4e5GHCxRTe4xp+5BOO4iCO5CIO41b+5Crz3xGu5Fmu4ljO5U2u5VPe5S3z5Ssc 5mW+5QTu5id95XGe5iSz5oW72k5O5S2O4DaO58hd5xZz57KL43pO5Id+4xL+5mge6Ckz6O6r /uiMLuVV3ueTfuaG3ugoQzTeqq3KPcucPsaOfd6gTp/USuqknukMY7urLn3PmuoDw+qzuqe/ +ur2EuvHareuXuv5cut5ete5vuviAmLiKBSDUo0ipN5e7Y3eXewibBvGXthFHtLMvkrOXtwL qezRnqzBHi40FsKZfOxQwtHhHoDe2MC59+zG/TyHUs+I0dGog49FTe6Efabcvi7e3r80wjlT U9PdbI3lHqY7ghI8Le5w4tmJ3tP9PPC7MdBSdvDZHqr2rnPklu/MedM0ye4QH/DgnuzW2Cte kuEIj5XCdyLcbNX4nPHbLvHXgu/uDvIlv9GQOe8tH/PkvnXe3JvD/tzx6snxzXPzPZ+EO7yq K9/tFO/ygNyEV53aPm/0NS/wwIjz6WzyXCLVUa/wY+3ETKLxu0r07ELzie3b4D7OOa/YO7pI 74fJQO/vDqKBR6/zNZ5KornR56bbXX/pdOr2VLIV4UP2Mq/wTR8l1C7Tiy329tfuU22OKbI+ 8yIQ9eCYdu/1gI/ZNb5F/NL41FijgU/5cgxAbhwRbY/4jLR3Ge35Oy+hdQ/5YI7G5e3Hab/2 Tj9BRr/Jx5zTWCT35972s9/6V13FsH9C3Vr2qY8tXx/1oq+Hln/8pm+Keb/7J+/PSx/7h3/1 8zP6wpf8AH+iUyf84EL8T0/91++Xv9z9/tBj/FiP8eIP+tPfyyDP+ZnJaqux/UWf+cW/h5Uf 0u4v+d6//vB++1rSNN9OALEhD/USVpThTVutay53/8FQXB5IMsdUXdnWfeFYnunavvFc3/ne /4FB4Wm4w0yOGhRjmbxsRk4klFLUSZUnahIboYq6pC0tLHVyv52wdvlst628UgYet9/xef2e 3/f/AQMF8+oGPcq+zqDWmFYYKcYMo9IavbYWKUlaHs/IMs0umzKnCkk/OiU3GUtTW11fYWNl Z2lrba9uxUpB3zBZK1M4I3MhdxNDdQ9dhN88jeEURX8tp7MOh4mVqquzu72/wcPFx8nxuFsR oZGt1Ubp3Iu9/rrT2aiT6S5CmOVn6O3vgYGAB/BdM29z9JVTuJBhQ4cPIeY6l8ofwXgW65nS WJBItorsAl7sqAUkxn+a+n061oslkowlYZ7k4PERv4g3cebUuZNnT3w0n7W8Z2JVmhJ1ikKb p3KdNaJGjx7VhtSdGWcFhToNWQxFNKi/rEqsOdJnWbNn0aZVy2fioKi+pEalJgorQm1z7Vpy KVbu1Ap972pg8xYu3i5GZRDWFVfqYjGk8jpeHFkw2VmUwazVvJlzZ8+f934eqMxRobY8R6th Qem0udY2g5m2hTkzaNu3cefWfdB26ierZYP2PQV4vlfDSZY2Pnus5d3PoUeXPv3H/mudyCur +HQbO4Piy111h/Q99C3aqqmnV7+effvyolt3H2X9evzX82Vhl8+KPqDz790LUMABCUSrv5zE 0w6s3BKMjbRYGpzkwaVGO7DACzHMUENJLMSpw8R0+zAGEYcg8QUT2eJkwxVZbNFFQ1DUMMYM Z3SoRj3+u/HFHXns0ccqfnQkSCGf0xHHw4ZMUsklmQSyyQmfBI9BhigzMsorsczSQy0B5NLK cr7cI68wuSzTzDNnQxMBNZ0MESKEyGRTzjnpvCNO9u5cL89v9iTkvzoBDVRQitjskzpDPUIw wkEZbdTRHBCVLtLoJjVvp0ofzVRTQDHdrVM3i7x001FJ/i21hk+nVBPV/EQ11dVXYT2l0FlD vS7WW3GNdVXuaPW01VyBDfbRXXvrFVQEHV3UmeaEbbZWNIkVDrpogaC2SGbleMvZbduztjNv OQMXxl85FclOacTlVl10jDUzXUHehbRRbCFVR9l18UVW1XZxixcHf4W790Q38i24X369nJbc QOn9l2CDIfYM4LMmNqtithbmVOAbGo7Y44cu9inknkb2k7CTUU5Z5ZVZblnbWjreapIPX+aq K9pi9uvmIxprp+SPgXZ436GZPPDnKxLMOWeA0MhKptJ2tiipoKm2GGEtjybHaM2UTlpZe0s6 rEGwQyqq6rNJvjrLrMfZeq2u/ulb2ruTonmYPHbqbgftvfWFVm0f3VYL7mUWTTls1rw++XD+ 2Obb8dr8JnrJwNMaXBUL4cn7JeWucVqvx0FvqPGIRn/zScoNTJxwzKfR/GkHO3997tBpB/Pv K0vnE4bcU4pb9d1bb0p2MIL3fKbakReHd9Fv5xF1in8HjvXgXDeJeOqFPz757XmT3N3Td+c6 eqhHRKxsxH1HanHn1uTefVa9L3P5RAd+e3wFOxxz5/3tTi47JugCwMBo7zH/m937EGiO5oGv Sc+z2P1ikz/F6Kxn1rOL/mpms5oZboBcSeAH7TC/hYhQISS0VP0EB8GZLYsqGOBFBc2FBRgC 8Cn7/pvg+UwIQl0tsIEMXIb40rc6HQ6RYTwsmg83AUQhXo6ITZxTDttmxBY5sCyWk54TsRg5 LZ4JirSgoshUeL0sjjFh8SvjEVFYuTDqY2NkdGOAuhiOOIJjjhAKn/2CyMQ37nFyUlRSHWHx RZKtUSBt5OMhJeXHJAHyOHdMYR6viEhJOk+RQ2JkeBypRkiSb5KdnGIlg3RJdqUxdZvEnydR uSFRSgSUNMpkKZcYyVTOkkCrPOEW//hK6JkygrT0pYBsmSYzhlKXD+TlCn+ZTD0pk4iCRA0h T2FIZk7zJsGkZoGceSloxu6a3TyYN9+XzfocU4zgNOe3zsk9cSqKnGy0/mY64QmbeIJunR7a ps/mmU+R6TN09azmPTnCT4FWc6CO8yfpANq/gi7Udgw920HflNCNOJSidKwo1SAKMolu7qId vaVHIZZRG210eCA16ShPWjCRio6k1kvpSwPhLZfNlKY1telNcZpTne6Upz316U+BGlShDhVl xaQQUZEaVJgutQcybSXgMqYdMEmTIlRl6lXbFNOn9kiUKz2OVeEFVqwu1anDXFtUgzFCsfpB bmN1K/vYulVK2oqUbVurmO761pOWFZfyQ2sUWCrCtuqVsFn1j1x31FWjKi+vcRhsYfXKVy4i 9qOr0WjuHgvZt0r2e2ZlXl1L2NggZFazbuWs/l89S6XFak20PiBtacd62jNOlq4/ROjRXgtb rMoWa5QVpm1vyxfdDleq40ptlBQL2sAy553EpZ3Rkhrd1gptddJFamWhZl2icgh42vVuTb04 XedS1Ktiwm5xYXbetP4WXqulknjL19zx9tO9hGKvZe8LP+B6kbvKvWwg4TtfhpYXR+oFbH7t 6F9MGne/7AxPgAW8UAITwsCQ4y+C15teBidxkODKbYSZOmEFYvjAGjYxh0+sVQVH1FofBjFZ 69vfFBNpxglusH7bu2IWh1W+L6ZnjDd8GSC7pcIJITHGdLzjP7jYxzAVsZ2KLJAoyxjFFyZy kpWcoh43+XFPDuGU/qGEYyFj+cplrnIVIcxRLq/Zy44FM3pqHMgh59jM+IWlydacZ5Tc2MZW PrOYAY1eP6uYz2CMFJP1nNI2W2Fkiy5Co+dMaDr/2ZjfvWGi8+zoEr35J3FuJJknLWk74ynN mI5spA97ZCN7esGF/nSdaUzqLZs6i5oWAqRBLepAZ3jQqXa1pEpN69iiesmcltKuX01pOQc5 1noKtrCvauvRGrtLy2b1qntd7Fxz59nQTo/LrvUnXo96zNeWsqrt+2uUhrrZ6kG0t1kktlkX EjDElieyW63sZJdb3/nWtaCdPW94X0YlIUIXiLatbXPLCt1UJje+zZvwgAl84BAquL/P/jWY Edm7D7hWd7qzPW6IF1ji8KF4xb+6i68iWc3tBvjIHe5ya4e8xDRneb8p1W2U57xk7xa5zF4e 9Jnz++F9JrrM9+1rnE9L5zsP97Fv7sET6ait0q4WteGadKMjHeMKX/rTnV4oqPgFJhnUGb0v CBiz07CCay/n1HVqnp26Ju7MzSnd7253nDaV4xJretgZNHa6baRpLm1fQBQhNWnQTT/PluDK NKi4mhM0viqL/KXP3Te4W75lP49ryf1+csC7hYP2MB/TjFfA/zUtaiBBheF/Q/Lucp5lnrdR Ymrf+cmTDveQ172F/217YIt+9DEVPF6I84/TK3TxqhdJZHhG/jYJyd7mqm14Qxc+4o+Dvfjy O/7wDNewGQJdgOXHW1GnT/2jm+76WsP6pkH/rb933+RQl9l89iND9EW/KYX7lMe3pP2iSADd LP7Cxf/Q70jEjf5gBDn0D58uJ3suovCcL0L+DgApL/vcjwAZre/kj2ZCodQwjwFTLoKOAQIj sPlWr/96wQPlpfLCr/Z2j/1mLwYhbwZBpvdo7waBT+mK7lDuRf8grDBI0OIY5zGgb//Up9PM jwK3ot6Abht8MAWL6vewLQM3zwYtDwdvDwarUAZ70Ot+cDoe6yOEr5A0rghL8B32rHrWBDP4 4yWc0FzGAwX3DM7uDf40cAD3UHne/u/WXHAzypAp7EO5fE4NT+XiDsgrCqjtroHxVDCGtgEN GM5/CrAP5egP50ETr84ABTEI8e80lsY05g8RA2ouDAiD6m0EN8cX3jDvKKh4WFEPq2+EOJEY MHAKhY4MQZFxfGMBOckUSU8G067t4HD8BqNK+K8BlnHtkNEwoLADOdCiplF3qhEQPVGJeo+b 2I4lihEYS0oYf6SGnhEXb5GVrnET07ETt89TepEbXVHxYK/lxDGUVI4Pa7GEznEfoYzZdnH4 eoebilEmBjL96vGP4hAf1y8H19EcG9K1AlEb4wseI5EO45F4DnJytmMDMZEaO9IaPxIb29Hg QBAs9i8c/sGxDjNykZJwfnKRBvMR+2KyH0cy8EqSG8nOgsrxc1YSIWcRJGdSIWFOJhey4yIS jwISK4ZCAl2oQoivJ0NoJ7snJNWRKunHKqvjKB8pKfvnIs9nHg8PKg/pJRkSK9HRLPkuG5Fy G09xDiWxIu1PLMmILLsQLR9S+9jtH3mOK1vRK99yHoNDLrGILj/LLg3zEvPyDJnuJifqLwnC LeGqFAWTVAjT+g6zKLvu82qyX95xMpJxglzo8sav9CaziSrTFu8yNb/MHxWT+6pL8iCjhlCR hqKQNEtziCxtqLQpN4FqN3nTp2rwN4XzEIfxNo3zOCNO85BzOZnzQpKrOaEz/jq75a+kszqt s1hq6zq185lW8WXEjxRNMBHeqzv74jsNY2bCIjjhoiANUoPCUynU8jK3cz7D6xnCMfZm051m SDI5hinuM/koSD+VkS0bkw6jCRrPYQSThjrps0FDyz55ko1cojmI0PnsCkIt9EArUBgkI0OD seV+sQU7iA1HVCX1EjUdNEVHCkMzz0NjAkBLlITMMMxMtEalDj9jdCIVikYvgR4ztEq+jihV dEgv9BQ1NEJ9NA8NlD+vYkdJFElJMSHVzAL9U0It0bAMNDJPkOssk0i9VI6qNJrUASfx0CSY lECTFCPEs0Dv0Ez7Y0Z31Clbx0n1g0G/9E4JjkVX/lAC/5NMyQ8Xw3RD+dRJxZRN344eN6Al rVSWwFJJ6xJPIVXuWNQYG2NqYqlR69NIKRVOUuM7W+hSn6ZnvHMgxuYrTnSqIjVVmUtTFfVF MdVQU9IIWdV1KLTxotQ6zJBSwdKK8vMKV/QpVVUNrRCHANNr7JBPwHB9XPVKMdJI3xM2H9Mv P/M+fLE16egvgjVbAUxPLVJa0/QRnfUgApVYlxVJm5VQ6S1cHfNPp+JuvtVRGStRtXVeq4pb aTVzxKMqzhTuwvVeuWE//PRQZWcOa9UBTbItcgj66HVheaxfhWcfOOdYxdVeH5ZUqbVQGXVg vZJZsAVfEVatlo9hRVYB/h3WaSAWdgIWKEqWIPHVXdEVY9mUYEN0Iiz2Y1lrI0c2Z+luZaO1 eLi0XFc1Tit2TsewT9FVCHsWmXz1ZasNUKtCZ6E2KinWZD32VNk1aAvUX2l0aZlWYmNCZmm2 UwW2EidWCqP2bG9tXLsVLt+1TQnoamFGbbWWCd02Mg01Xel0Y0M0DLG0Y5FVbNE2cF1LbrPH UjkKPI02U4XWc5AEQF/PXHlVYytShg53TZmVXrImVoFVcIUtHRiXGdlVCBM1AV81PwgxVEE3 S0tPVEkXaL3W/FwvdV9ocdYzGrN0a40wPjh3d/uTPBmjJQMoNhlRNB8wXjd1DqBQf6Z1U7tx /jRxNYNAk3kNqBvdwIbcrk7tLkh5d3s7TqT2FR2818NWSj6yV3u593xdY+pcNvDUN2JJr33d lwtT7j7Qt34bUBXW1+DwN37fN3/RsGi3VRTtd4CNj38XlRcN+H8fLIEV+GcDWH4JOIIZ7Uu+ 13SrA2Aaa2yutUIkuIOTk7beJjP5gmg9uIRTdXlyxIRVGFIFq3FX+IWH1ISAFIZp2EGhaExq OIfnM47gRId92DrrSCp/eIjFkpGIk4iR2NSeM4mZWC6XuImhOCOfOIqp2BSnuIqxmAGvOIu5 GPC2uIvBuOK+OIzJuHPttIzRmM3OOI3ZGMTGuI3hOMLeOI7pmLjm/riO8VizhnOPYzWP/Rjl rO6PBVkYA3mQDZkEC/mQFXn0EnmRHRmQtfKRJbn4GnmSLRnTKvmSNZnLMnmTPVmOI/mTRVnP OnmUTfmUUTmVVXmVWbmVXfmVYTmWZXmWabmWbfmWcTmXdXmXebmXfdmSS/mXhRmVgnmYjRmR ivmYldmNknmZndmJmvmZpRmEonmardl9qvmatbl2snmbvdmgQvmbxVmHunmczfljyvmc1Xmd 2bmd3fmd4Tme5Xme6bme7fme8Tmf9Xmf+bmf/fmfAXpe0zmgCRq5wrmgEVpQBjqhGXocD7qh IbqvrDaiKXpYHrqiMdqg4zOjORp3Lrqj/kHaoTc6pEmamEa6pFE6sT46pVm6pV36pWE6pmV6 pmm6pm36pnE6p3V6p3m6p336p4E6oxc6qIn6Ks23qJE6XFY6qZm6qZ36qaE6qqV6qqm6qq06 grdwhbNahbeair1ic53rq19YrL36K8B6uERXq826rLmVb+kVTrn2rdXWrbfXcxlYoE9XQaLW rvUaq0PxlKB2DTC3grtPsA32rAnLsGf2YlVUscMWYBs7FB+bseEtcnsJb50VetUueZvyiM/J spU2ZWmX9ZoxBGlTt0B7bJn2q2vXer3xtBMttd1ptu1Qb0UUh37StFrKdW83dpNWUBHUs8FJ tjFbtBEvEhNv/rRt18eIG2aN+/n4r2dbr4OE25ua+7nLdRlj9+Bwu3QVbbfhtreBgT3fcrph t7od6rpfN00pcbsjtHrQ+5rUW13v9rh/e09RF7FfZb67NnQx4b4XsXAJW5n4u75hj6//tFV5 m6zAW7wPPK8THL4HfC4bfCwMNw0jXMD1O18KvG0vPCdrU8HDm8HbqbjX+/50VXjzG7UrXE4D ljyrV8MxucX/VbKVT1o7e8Vhq8ON1rFvHC5zXPE23FR4vFF9fCmBnBllPLZpnLaZD7l7VFkX 3Mma3MRRF8BNVMKHvFSKnLcV+739MswH9cW6PLy/3L3RnFyn/KXK3MGXFWwBXMtZ/rzEnfvE 4TzN1zZx7bjK61zI41zMUy+y+Fy05/a4J3fMdZvOsZv8Cn1d89y7d3zQX5cX/vzQA32zJJ2+ KR3P3dINEzvTCXXTDR3LPZ25Qb0xndcGX5GDSh3TFf3EhdysFSc0b7DVEx1UL7vOU/0LiYJ4 g3zN5xzXQzvGc7tSK9TYrRe2IavNmaF1ka+82xW6OTW+p4nZPdbZPRPaT7u0lZ2TTz1FrX3L 5fvb5frV6Rvcyb1Bw/1s1x1P2/1O311n491L551I691Z+lgfRdKx0p1R8l1I01JqhV21M+Xf OZId+d3c+/vbbPNI3Hw8w8TgmzRjc90dsT19qZ2tjlji/vkSsCmeMy8+4zK+ezN45B/+3K28 lkIQU0a3qzgePQ+t3+sv2/0E2Dc4r4Q4WxTewCfu2Wt+xC8U519eRz+e4IFprX8+LMdptERQ 5kMPMhz+be2JTEz+3m0S6pMeS/+J6pt+59vW3eY6rj3emJg+5r1ezz+xrcW+4tGM681+4J18 MVEed8e+7ct+Z/Wo6I8+KO6a7Q3t7s/l7CF9K6u374f976ul6+E+5a++8Pua6Mk+8d8+7z/U Of/a7ynf7iUf7/We8UEe1nne6Jd+8wN/8fucJEH/60+fOwFf4DMf8wfkyPWz46XeWiH4XBf9 gBfeCJz+A31msmlf6R3Y9sF1/vUNv+p7/wB9EfjRtG6Jf+1xP/V1P/R13vRzH+wPdjJWvuX/ hNdl8+wkg3WbfbxtN+TjYdeHF4a028Vf//Ddv/FnFXhL+2C1Zdq1/7VtJtp/n/zRvxz/4hgJ AHZkHiyra7EhaOG5eofMfwSCnliaJ5qqa1dxZMtIiuzW83ZnT4zVFk9G432Ctt9F59LsiD7h UwIdzh7L4jUFU221WRY4LB6TqaPjE3hddplrozkUrRLbc4e850uflfs4lQ4fnhcO19eJnYli WaPjYw4iINubIaVhpCVc3taUp+SElCid5uCLEs6lmh9gyyEmCqOIbB+k7S2u3imdqS5hHpam xxHp/ioxcV+FMvIfcKbgUC9qKuVrGG3wNWgud/ej7DBJ52XxbFbbOHXlam1SErOz23Fga4z6 4HamNmxifrY3wIDm+MWps45ePHnvYKWLwq7XQiYRgdEyOM+ZExjiCP5jgW3XPoEiR0J8aPHh hHr6UEojx9KXQncoNeazSKocQoporIH5uNKjP5JChYLbifFNyYkQu5x8WRTTuWUHQTr8BbNh QY4dV/iMCVTr0LBknkarNy7pS5hqm7bUyhSqVGHtcqpqyyeoUq54veoFK/bv17l1zd4bmDce W8Juo050otbpRrumwgXuufdwIcCah5KVJ3eX37dwGcJTPDfQjZRojyJy/ow1hF+qlWf33Wx7 TOeFn5+VEI1Zl+/Va1GpVgm59WudFEJajv2z9u3o0GUbS1v1NOIvG0dbX0rcXnfF/FxP7eGc L0/a6aWzh5Qb9W5j/oKX3H74vVXP4bOPTu4LyXQBrjdgewWihxmACdkzX1TcKUWfgiptQ95i Ds4R339TEBjLZfsZZiCIB6aV4GMLhtbgb/Ydh50rwWCIYIP+0eQYh+f91o+NHoa441a63VWe HNhAmJCKklGXH3o1oZgVhjOW+KF6mTXHI5WMZCTViFhCKaF2pbHGopKlgFmXjKp0JRyLNTJH ZYhWOnnVkkIuWZ+XcFb4zpYt9pjhKCuacaZx/jiuKSCbhT6X12BHoTmchfjMGWF2vRm1Z2Sm TYYAoJDmKWWUhkbnJjVGWiVno0TW6R+MkvKyaaVfXkpBh5qmKeiUnhYIajN2qrHokI8VaemR enbEoIWJ6vpnrE+qOuiGtnqKq3IsvTlmqZw8qiyjOVy4SJzGJhdOjtjOym24gToLGLR8Smvs odk+eC1+JarzUXDTuhpkrJmau2yt534Kyq/fsntgr8DBO+G1NGzL74+FAatHpvrKuqea/p6r iL0CO0xpl3B592KWDOVKazP2HmttjhKLSzHJFm+GcaIa85rwcB97WHCoBJZWpsOAqvxzshO7 LBDMG8u8L5ekeZz0/s0058xpWeqK+iu5zELd7NBtIhff0RPjXN6Q8YIXdbJntcLzq1erXXGn WRO19bpcDwyj0nHfh7DST5eN1NlAZnwZ0OUK3a7bb48HNuIbB4tO4nff6SPZ5Zod7dRzB8s2 oZgXvmM6MbIyjImpLQ73vQ+LyEroNEIubOpQdD121f1m3vLmhsun2+fKtK46016hiqp1qE8z 0Krwif4674TTvvbytYvUeX+5S7F7uoFSHTbenn2COmhRhwIN8l0FbrXmzrM3jSSuV3JTn6BZ Ifrt8mH6A4nGR497/fjn3b6JoYT+P8NmF7u2mY8b6COI+oTBPkgJAhrxuxCshJC/1OFO/n/J M572UAau+UlwgjcaoAADWECAHNB9rFmgshoIvzvIL4Lv450DUWPBiuQvgfDxX2pWyDIQYk2E I/whEL0xCg25bXyy62EQk6hEmcSwiEFb2eWat8QpUnGIF7zYE41IQCpysYuReIHztBjCTXmx jOZLXxizqEbBQdGMbnQWGmsnRiSO6412DCLA0sjGOTLvjn40VB7luEbySfGPhuRRIDfHx/Ix 8pCOzBrGzjjII/bxkZa8TST1SEgeVvKSnvxLJgW5x0lu8ZOm1BrwhrbIQvrwlK40HJCcOMpZ bvKVthQihSRJS0o28pa+tM13dFlLMrLyl8b8BvdEOcw6EvOY/s5sRDA1yctiMvOZ1gyIB2W5 zB228pre3IfKqkTKMVbzm+ZUVTgROU46cvOc7jTmKjnZy3fS047x7KY866lPN96zmfjcJ0Av 2c9yRjGgBlXiQNtJ0IMyVJHr7ORCGyrRKSa0oP+cKEZV+dB5+jOjHsXiLksZ0Y+StHAVVV4+ S6pSNp1URNRcKUzb09IPXjSmNgXpNi3a0ZvyVDMz1ZFCeypUzmz0pTodKlKxAM4DMrWpTn0q VKOKvqQGdI1SvSpWs6rVplIVoFbdKljDKlaodhWmP/VjOsv6ybPeMa1qFWhRTenWt16Trfx8 Il3lGle4sjGva92rJefq12fa1YuC/h3sIQvbxcMi9o+K5SJjG/vLxy4xspJtK2Adi9fLBjaz aN0sZ903o+0d4ovfcARl8QhausbQgT5T4GoVBk3PvtGySG0t/F4rv9PONqR8Da0B00czpa4O tX1d1FHvelzEFo2mbmjhckeWU5RiNrp+bS5QR9ZE3Fg3tSO0LXAjxDgOScSysfWuNMPby/H2 Y1c5KcN5abvY2F5XuKQhb66uWFr4yhey9FXvB8X33OR6xLi+/ax1B4vdRQzYe8WBr4GnS9H/ 5nXBvWkwkhibYPSalMIARotPuhRUoER4mmUEb1ktfAYMd4C6eimxSKvoYdbat714woBLtQFj cso4wR8O/nBQ3jJSL+yYnQidMY0RGGTGAMHFL+6thIGI4hTX2IdL9jGSopzdJE4ZwCqOXCy3 nGUnc3TIwvxxH+1wEaTNzKgprSmXkZzkKK5ZaHi5M305jFM040LF2zPC49DpvxyLdqz6lbKc 53yoP4OrmIAmXY0Mnc04Y5m5VZbh9/hHXOIN2rnak3SXUcnnXPj5Sooj9Aw75mM9FyrUVFYy bNP2Zvsx7r+sZmmiFZ0kU8/MOcMr7lj6q8xR95mpfDEZqqtjPQrfmnO5TvJUEWW5G3N62Vhu tqiJHelf2w1pOuSNtd0jbG1q+xZflpqsxBfmNpZ5xB2utGTP/TdfxyaVkcX2/q2eresUxYxY xOrOvcftMlf/WN79Bou6QcbudhMYkvred/AOzi3aqXnG+JYOwdVqcKPhOUwAt7jA91xuc19a 1unei72RfHFgPhzidOL4iTRXcXgvXMz+yrjGS963Uys05TRf+ctajuaNm7zhJ7M5RN0t8pEX stZFNy3FIW0LoINS6G8l+s7L7HNSh7zVVi+4zil38vNsnesHdijNOYt1sYPxajMP7tnfzXSs OT3r1Cx7seNO7rmTHNbHnvbgjo5cLQ8ekF+/etjRja1w4T3vhFdn2tWe+Hlrfd1TpjpJcM7n tSuezKZjc7D1fvPDI97v0ua5bGVypLd3A/NEI33O/k3f7cD/Oylddj02Yf9hzqcy3KICPX9F byvNV3jy3moN1NHmaSibePi6f/XlTIYOx/kJ6c3fqdcjz/cn0ehNmj4dr1/+euFnf/sC7D6Z TCW88BuH4Lg3u/npDiHQMQonnRZ84LlLflxrf+64RUKCXEmhKdANLQi15d7+OVv/Xdb/JdBo SVe0FQcAot9IvN/UPV9XNeCjuYSDZRq49Y8Butf4Pd6/LGD8td5xCc7h4RWotWAJneD5pKBl vI0YuKANJhMMBh1uzGDm9dUN/iAR5aDh1aAKmqDhGaEQshwR8qAhEV8SigULFqEjOeETqhMT 7ldiYWAVPo8UktgUauEW/ubeFRLZFyJhGOLak6VhFprhGYZFvnRhGbahaqkhGcahHGrW6/3W Hf5Qy4FhvrHhHlagEfqhTBFiIKLLSlHhIZJQIhriIvJWSSniI4ahJE7iqFWiJQ6dI2bi9mEi J3rZJn5ivIWiKJabJ5ZiaJ0iKjIgKa7i5rWiK8ZeLLqiKs4isdWiLbpcLk4iLu7i7sGiLwpV LwZjUg0jMaYiMB6jTRmjMvIUMzajpQEiNBafNE5j6VljLj4jNkZiMm6jR2mjN2ZgN4bjRIEj OZbjOJ5jT5mjOjIUO7ajQb0jPMaUPM6jPtWjPdITPubjR6VVBM4XP2YbCkaTGU1aQBZZ3uGg /mEF4UGiS3zF2oSlIzy63/pUY9AZZEPq3wiy0EJiZEYiIPMpG5fV3EeSUB+q2kJeR0ki0yCi JEC+10raTvAZXZM9i0S2I0XKHhdgEbDFpEaCpOdJBBxVi09uZOh1DxaWX1H61EnCGuNZ5A4m 21LOGksiZR0+i1ROpbh1F8B0yD7uIznmpNLl36cEpVbSJBFyxGtB5QWyZUnOFaiQnWBxpZmd JULCn1UKGjTxV1raJQmG0KHBZA3y5Rj6JdyF5KIFIIB8G+RsBwwpJFiGo1huhQ7llkECGgal Go8ZZlbOJGWSiGUypLI5Zq0x5qZx5kAi5t89HeCpD8oc4Lmh5mEC/qVsHJ+YaIprGsxtkiRv cuZk1qbiTM7ibcL1oN5YymaMzZpj2p0EepzqMSf33aQ6/uZKJAaf2B/hFAvgnQJyGplnUoV1 PuDYCaWjGOenueVHwmX2eI/0mWekzETjdedsmmSg2aYIiouQmUTvnaZ8Yp9qvsvvbWd+NozC mVB/buV/hgf76Qe1uFZ8HmhbGqXy5FJetsuvUSh+Qah/fueE7qd+iQb47GeFauhfNs3+oN5l MpmLfBx6FiV1EgwRzRwNLU2Fnol00mJTNqjliaZ3JIP19SaJ/iihUSiyNdqYiFDiBelR0iaD 4suLGCnH5AngtKg3vqhIQkwsQenoSGkR/lJpQKqnWvIN2wnLjB7gsISpl66klV5KgLpnzUCJ VyopnCVo37QpmgzomZaonILpZ8Lc08HoeOzWccrphi7pT7Snn1KLthRgLBBqof7kodondFoo 8jFqcjpqZzZT+CQqx4iMdA0qppolpJ5e5bgpznxqIiwqpq4p220qq2gHqnphqHonMc2fxLFZ aeaXjURmleborgXnrVKMAI4Zg7HYnvoq9T0MsvFbNRDrLCzfrEIrkqpOCYHOC4LfCnGbtEYr WjJLEL6gtf5jxIXmdp1nYMrni35rtIWrto7rYhJkk/JqM/qjuMaPeIZg0ahraX5buXLrnOof vGJa5wisfemr/udMWr0e6wJeawXZCQrlK/qBqGlCkL9uZltlWpr6pbyWJQVVLK2uFcZ67Hz+ VduJLJ36UhyZLFW6UsqqbFXqVRG4LIceUyLJLKhmYcza7F2uYcnq7PWdUij5rKg+UtAKbV/+ lYga7c1qVtLq7MYyZdMq7aOemEJK7crqVb9a7dNC7cRaLcNV19byY9hy7Y3iZNkW4rl6bV2q Lc2eLds6X8a+rT25rdwqZd3u09jerUbFrd7KXd/WU97+7dIJrjkFLuFe5OH2I90mbgzyLeMO peM+Lh8uruSyXORWLv9hruZuLud2rud+LuiGruiOLumWrumeLuqmruquLuu2ruu+/i7sxq7s zi7t1q7t3i7u5q7u7i7v9q7v/i7wBq/wDi/xFq/xHi/yJq/yLi/zNq/zPi/0Rq/0Ti/1Vq/1 Xi/2Zq/2bi/3dq/3fi/4hq/4ji/5lq/5ni/6pq/6ri/7tq/7vi/8xq/8zi/91q/93i/+5q/+ 7i//9q///i8AB7AADzABF7ABHzACJ7ACLzADN7ADPzAER7AEP/DlTrAF1y/lXrAGj17lGu4G fzCI8Ojdpi0Il/BkheDhirAJr/AJY5rgeiQLx7BANezfdq0M3zDRGqjeNkEG47D1aiDVyFEy VOPxAPHXnuEG+TAOf5kHp94QE9X6cGfS3eFyKjELGxwf/m5bDw4X60wcKt6rFX9wbKrqwPWF 0IEoGY+FJQ5sGG/wGJvpzTXHw0WsserYGsdIG1/wGxdemwBs/6HxfR7tHedNHktwbNZZCD9r 6CUaIOMYE5LwE8poIVOwzjFaKAbsqkEyuRDgp1amTTQx4BbsJDNwqS3rRUaxI7Okh40WG2AY K/PxFsblKCcwV5EqxsnyAphdnkWGRqyOrVbwUD0FMM/y8fKeI9KL7sDdahHnpLDno4ByPIbJ MBPz8BqzlyZci9HnZlHG2JzIM/fwN/obNQOwNf9LaSGhCvvoPeDNL8ciMoPzOL9uOSuhxary U5oadrWzO3fcNMdz7s6zDtbz/lZ6JYUomc0A3yImXD/7c+0CtEPaMRSea8QezqmZsijaKDQz 9Oc6dNVBdNW9c0+OaefhaMpktEZvLkdHtEeTbZqUnD5n4xvC80lvtCh3G1uyYOMKF9SlWsAk 8yzqiybP9A9naxHj8yJjVVSibaDWMcGyz7z4YtcJdSHjdB+HqgxKNVbHqqRwzqxedVZntRpx tVUn9VdLdVhX9aqSdVkLddA8X2h0tVob1vOcz1oT6t6opS5f2FgP5hAHdU5rs+XKdF1HMkF3 Zd/NB1zz9b9C3rOl8/gJ9mAnIUZnc6ay00JfdFx3q0CmJiZBdmQLYYhNzwciqCKntWJPLdH8 7MlC/vFnKyycPsPPIfZeX4ObCaJqz6xDXnZrP+JjtnJ5mZdsmzZtX60gdimTQu1u27W43lcK SU5wO6pXkxHg9ERIE/eoIndyK/cEMbckozAE+RsQXhUrhnfAakHUxUX0VCQH8vCHNhG/bnfW UqwLS+zBOHZ2oyt5ygtBVvEIJPZwW1k0cSppEgJIP1hPHzTsPEcQB6vYmfR9wyCN6jeDr4xu c2J0N6ij3Kd21g2XpkJjFGeB5kd7ahfYbOuDa+xzqt+6LF+FZ+KFdyp8WkIHBjGFayeAEgZN wao0dPKNw/KJa+Vuqnh5srh/UzcnvQZDclvdwTjGdjd/JBdNAB9pwvCP/ktUwjYhdNHxkANV i0fkBuJzx5lUZlOq3OBpdjpnhm8yu+zxJCBXq1Q59HFkYqEq9mAnhb8aJzO1Zt/KmANqyDSr sKL5JHizSLM5vrh5M8N5MbrknHfgg51MwaR4MEd6F5uDmJ+2or5cojPrqxaPFBd6kirEdlqL osvi0I6kEyfroBOlpE96f6RxnycypjN5m1eFmgk5rd865Sno9LFDnqfya+Z3qatUvjZ6pZsO f3tN7BHlLg9frIfMTHy4p/qKNMe4UM5bgVJrkz56Lm95TQ67WXVll/eZo7/X69y5qauks04x xj07gpN6eepNx0zrU5cFou6HhlB0BqX6dWo1/rijI5o+ZQF935Uqnw2Pu3+9+rcn5QXx7YvX 6FREOa2JH2VX5wSS6/pZUcE2PEUnOTnY978fFH54MnrrDzqRdw4Z7AttUKyJjav/eqUTNSsf A32jvF/zu7m6UMl37APxPLdnkMQ2bNDPaFGIFv70fMgT+3oGO60NBjg6/M1n1MwDuzOjkFn4 uBC5+20lvf8tvcYYjYkTxS07uC7xQi+LpPKJeMY+PJVxPdN1RiMjOatjUmeT/cBz85tXffVd BV3Pes65/cjB/bzfS7v2/Ud7dsITOP35aKnCItsH87oDfngJPodDeoVDJciLI6akATv7TUUa yOOvY+ZLfmPh8pLL/j0cQTHiF2S+86iW4p93073fvzzCkz7Linv7eUnes9QWr35tFfSnC56M rr3WL6Pv2z6CnWnly/1S8zkCHv/c4vHfNYlvCyYizj7yz24pw2bE6zjoa3Ptv1Ijz17pzL0b Fn/2sy7rlWrcPI3zJ2T43xJ7Tf/erxsUon/6qy70RCr1z8vocwYBxMfUTXBnUU5a7cVZb17h +sBnJI2n+YDgPMLulVRYhmv7xnN953v/BwaFQ2LReEQmlcshyelilFAjExUhZV5oOGzW+/Vu r+JpymxtsZ5kMDvjBsflc3rdfsfn9Xt+3/9ngtvoAiw0vFtLVFxkFLRohIyUnKSstLzE/syM POTs9PwEDRUdJf1xfEQrVV31PKVwZY2VnaWttb3FzdWNmUnd/QXugeUNLjY+Rk5WXmZWHS57 bpb+jQaZvsbO1t7m7jauJvQWr61WKB9HT1dfZ293Hw53l+88v5q/x8/X3+d39vDtF9BOvRYC DR5EmFDhQg2C4jGEWISgiYgVLV7EmLGZm4caPdqYuOLjSJIlTZ5EBA3lSg4hQ7KEGVPmTI80 OtKk6RLnTp49fVZ08vOnTqFFjR5F2g1gUm2LIjiNoqjGS6ZVrV7FqodqVoREuX4FG1bsWLIz ppZFm1btWrZFvbaFG1fuXLoB39bFm1fvXr7F7vZ9J2qrj8GA/g0fZvu3JKRWD58AWgqZBZ3I SCZ3WCP45ubKaRB/Bl3QrMzLK0ob6nh6z00+rJW4JqJay+XOfTKbCwGlik04tUP/nqv4pGrZ f1JzKm5cd5zkR5aj4vjc9haAUHRbZ6OiOXDubYWbJL5da+V6hVtKV24+h/jxDtEHekUmVWna 2KOr757f7VnSz9nj0U62c95rgsDWDHwNQQDf+88IAu8bQ4z6JPRPQf0u/Oq7xSrEz0HTiBvE QsJERIREiUycoznfnHswKt6uO0O+5RrEsEarNCRJQBRN28GR7Ha7riEaYxjQwg5FC/HIKGZT sgpU3lBxSCBWdDGN7M4Q4combeQS/pvwtMwyTCQxm+lL3CZD84SgoIGRkMfsAdKcM31586k1 4/xwxtuIDKdOK+lUI7c7rczzvqX8tGLCQXlIdL7qBhVvOz//VPRFQWGbgtAzdxMz0y4/DQvH kU4zEwVKEaXOhVSpi7CBCCX09MNYiWz1VDcv9bFWTjXdVVZKnfQ1WCAnTZNCXaW49M8goCpU 12AjZXDVWOmzz1kMJhSz1FlB5fZG/mJidtMxXlUWz2eNBdYzOMulaF1ehXXxRXLfpdY9U9Xl tV5r23UWDUcptJRePQFeFtt+Ce6VTz7lfVdYfRuebdtdtd23W4uNEvWjQB2zblt/pU1YpJBh LWPMNivG/u1ghNOF2FrerAk5T4hPbrhRGQVVWQRxTan22B9b3jkqn29mWOAiJfaVYqAvVoeg LfXLuKaBbx53Xx1x1VK6rPktFFIS/52W5nipVnhnUqWqeeNOS55Z7CwZmeBhTSU1sMGPwRxZ VRPdnnvgtZleTwZJGtub7lOeTitqja4mW2Sr26z0bY7e5rpuI7uQ+2wfAd0cb3h5jI9spbt+ vHHJ0bZz5YkftByWO7WV+/P4/l7dc5QBf6HnoAvB9NXDLf9U8YyK05zlmA3WfGr54nUc9LgR VDvtopf2nXrZi005dHEpjv54vhnVvfbQO/9d8GTNDp9GDrP1e3fce3EfX+RQ/oT2SS6Fx4h4 v79Ps+J43Eyd3v7hCr2BLF/fG1vMkIa9ez1PdO1znsP4tyMmeQxL2isbrQ7oudipL3Xss531 3hex+BkPNfSj4M9shL+L6A9MIUxaAccks+bRkGtzQtn0qmS0sJlOTuQ6lAIZmMO2mQ9vBvOe D8GnuhjO6HYKzJkQz8dDLThwVrF74ghJiLQbHkJKsrNfAzHEQoswjnm7G+Kzthe0zvkvixI0 YK84R4xWBdF7pYPZHdtGxSQycYkWNKIKoWhCNspQjB1U0OTyFkcwflGL8nsj4c5TpOis8Fsw +VJv1jc0n3kqfbObF8sMF0U+DjKCTVSVywzJNlFi/geQpVSaIyuoSkuxqoStI2XC7sbIpwht kbTc4SOTFMyqDSJFKHRdwGjHHTICxT7ROiMcG1HM+rwRYItSQwATAa+HTUpgviveL+d0K5yh b1VSudqwKIhB6YFTa0h0INrS2LXXpWBhxJriBj8ozGEuE3L1MuI9lTdQaS2qSl4r1hwvtM51 JmSaoBxnJgNKz3P+izySi2YCURmjawbIPQY16K/cSTRDJed/NqPoOMHIBWTZrFLlo5JIk1fS RX50m2wqKYd6x08X6oyTMtWkDlcJR6CybmO1zKEs5eLImO6HmPyEalSho01UqY49jbtbMeUI z4wiMqj5+WJT3fJVqZbV/qxP9Z8ObVi/KxrQie20IjCXplTvFK6hO3kn4s6618P0NHvXyydV U9O9fYoQi1yNpF6GJFahmC+DfIUsVP3aQNgBj0mEfeoo5TpIuqpFfZ3NCWf0GlnS1mWyhf3p 86baRHaaUpyl5GJf7AZanLCGtqXFbV/z2lp9QlSD4ourYcNHVLQC5j+MTYpJd5pb5gLntMWd Z3FFhjwQvRa13BxqbBULvds217vfHc5ueRtBaKmQum/FbvleOde7jqW8owVvfOXblU0GV5fc FeB9kWqy4f7Nq9LdLkznO2ACN1anA4Tr+DAHtz1ZN7Pps2di4xKl9hbYwhdWyD/f29ENY1Sa p88MJHpa6tICyggxyq0whlW84n6kmB0u5ooL4ctiGte4KTOeBoyxYkYb99jHZcQxM3R8lUz+ 2MhHXsiQlRJkvEIOyU+GskCUfGPdXjPKV8ZyPpic5V6ck8tfBnOYY4wrMZfZzGfuyVHRvGY2 tzlHEECum+U8Zzo3LaR1xnOe9TyOO+/Zz38GdDKWG2hCF9rQo4jzoRW9aEbnobuNhnSkJV2w SVf6IAUAADs= --------------4CE1A7D1CBDC6ECE454937E2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 00:28:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w5-0005z5-01 for ; Tue, 21 Aug 2001 04:06:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:33 +0200 (CEST) Received: (qmail 17329 invoked by uid 0); 20 Aug 2001 22:57:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 20 Aug 2001 22:57:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA07502 for ; Mon, 20 Aug 2001 18:57:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:56:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA06649 for f-cpu-list; Mon, 20 Aug 2001 18:56:47 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA06602 for ; Mon, 20 Aug 2001 18:56:44 -0400 Received: from tribble.stud.uni-hannover.de (root@a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMufa19099 for ; Mon, 20 Aug 2001 18:56:42 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01859; Tue, 21 Aug 2001 00:28:07 +0200 Message-ID: <20010821002807.26313@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 00:28:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B81820D.14C21895@f-cpu.org>; from Yann Guidon on Mon, Aug 20, 2001 at 11:33:01PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 20, 2001 at 11:33:01PM +0200, Yann Guidon wrote: > hello, > > the message below announces that a project account is > opened for F-CPU in the Savannah server (FSF/MIT). > if you want to help with the organisation, you have > to subscribe there then send your request to Philippe > > > BTW, we still need help for the maintainance of the > F-CPU websites :-/ We have too many of them already. What's this one supposed to be good for? > REYNES Philippe wrote: > > > > Bonjour > > > > je viens de creer le projet f-cpu sur savannah. > > http://savannah.gnu.org/projects/f-cpu/ > > > > Bien entendu, toutes les personnes desirant faire > > partie du projet doivent s'inscrire a savannah puis > > me faire parvenir leur demande. [...] Does `toutes les personnes desirant faire partie du projet' mean what I think? "all people who wish to participate in the project"? I didn't understand much of the rest. Can somebody translate that, please? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 00:48:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w6-0005z5-00 for ; Tue, 21 Aug 2001 04:06:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:34 +0200 (CEST) Received: (qmail 28559 invoked by uid 0); 20 Aug 2001 22:57:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 20 Aug 2001 22:57:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA07547 for ; Mon, 20 Aug 2001 18:57:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 22:56:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA06726 for f-cpu-list; Mon, 20 Aug 2001 18:56:51 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA06650 for ; Mon, 20 Aug 2001 18:56:47 -0400 Received: from tribble.stud.uni-hannover.de (root@a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KMuia19103 for ; Mon, 20 Aug 2001 18:56:45 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01928; Tue, 21 Aug 2001 00:48:16 +0200 Message-ID: <20010821004816.62554@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 00:48:16 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B81DF01.4103E718@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B81DF01.4103E718@ifrance.com>; from nicO on Tue, Aug 21, 2001 at 12:09:37AM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 12:09:37AM -0400, nicO wrote: [...] > > The manual says: > > > > 00 32-bit > > 01 64-bit > > 1x unassigned > > Yep, but you speak about an 16 bit shunk size. I was convinced to drop that :) > > > 2 data out, > > > > Or more. > > > > MORE ? I beleive that the fc0 is 3r2w (which give the number of register > bank port). So ? Look at the ASU -- it has four outputs. The IMU has even more (2 for each chunk size). > > > SIMD flag, > > > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > > > > The same of the instruction ? No, {en,de}coded: 210 chunks ============ 000 8-bit 001 16-bit 011 32-bit 111 64-bit [...] > > Something is missing: the lines that select the instruction to execute > > (if the unit can handle more than one instruction). > > > > Could have many enable flag, corresponding to each differents > instructions ? I think we can add that easily. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 01:12:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w6-0005z5-01 for ; Tue, 21 Aug 2001 04:06:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:34 +0200 (CEST) Received: (qmail 9365 invoked by uid 0); 20 Aug 2001 23:13:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Aug 2001 23:13:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA08216 for ; Mon, 20 Aug 2001 19:13:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 23:13:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA07961 for f-cpu-list; Mon, 20 Aug 2001 19:13:02 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA07958 for ; Mon, 20 Aug 2001 19:13:01 -0400 Received: from tribble.stud.uni-hannover.de (a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KNCva19277 for ; Mon, 20 Aug 2001 19:12:58 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02046; Tue, 21 Aug 2001 01:12:40 +0200 Message-ID: <20010821011240.05053@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 01:12:40 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B81E48B.1B9C5D1E@ifrance.com>; from nicO on Tue, Aug 21, 2001 at 12:33:15AM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 12:33:15AM -0400, nicO wrote: [...] > > The `address add' idea looks better and better, and it's good for > > pointer/array/structure accesses, too. > > > > Hum i don't like that at all because you schould put an adder just > before the memory unit. So we just as to make the pipeline longer. One > of the key point of the FC0, to shorten the pipeline, is to put in > parrallele the ALU and the load&store unit. If we put it in serial, we > longer the pipe. So i think, it's much better for that case to use 2 > instructions. Never forget that it's adding an other addressing mode . I think we have a slight misunderstanding here -- `address add' *is* a separate instruction. Like normal full-width add, but with slightly different semantics (like code/data prefetching). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 07:34:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w7-0005z5-00 for ; Tue, 21 Aug 2001 04:06:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:35 +0200 (CEST) Received: (qmail 32185 invoked by uid 0); 20 Aug 2001 23:25:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 20 Aug 2001 23:25:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA08800 for ; Mon, 20 Aug 2001 19:25:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 23:24:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA08544 for f-cpu-list; Mon, 20 Aug 2001 19:24:57 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA08541 for ; Mon, 20 Aug 2001 19:24:56 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KNOsa19530 for ; Mon, 20 Aug 2001 19:24:55 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2A91D3B2 for ; Tue, 21 Aug 2001 01:34:17 -0400 (EDT) Message-ID: <3B81F2D9.FCEB9971@ifrance.com> Date: Tue, 21 Aug 2001 01:34:17 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <20010821011240.05053@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Aug 21, 2001 at 12:33:15AM -0400, nicO wrote: > [...] > > > The `address add' idea looks better and better, and it's good for > > > pointer/array/structure accesses, too. > > > > > > > Hum i don't like that at all because you schould put an adder just > > before the memory unit. So we just as to make the pipeline longer. One > > of the key point of the FC0, to shorten the pipeline, is to put in > > parrallele the ALU and the load&store unit. If we put it in serial, we > > longer the pipe. So i think, it's much better for that case to use 2 > > instructions. Never forget that it's adding an other addressing mode . > > I think we have a slight misunderstanding here -- `address add' *is* > a separate instruction. Like normal full-width add, but with slightly > different semantics (like code/data prefetching). > You mean that prefetching could be done 'later' in a no synchronous way (in the sense of none blocking way), to avoid to increase the umber of pipe stage ? Does this instruction still use the common ALU or does it add something else ? nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 07:36:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w8-0005z5-00 for ; Tue, 21 Aug 2001 04:06:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:36 +0200 (CEST) Received: (qmail 27297 invoked by uid 0); 20 Aug 2001 23:27:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 20 Aug 2001 23:27:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA09097 for ; Mon, 20 Aug 2001 19:27:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 23:26:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA08852 for f-cpu-list; Mon, 20 Aug 2001 19:26:45 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA08849 for ; Mon, 20 Aug 2001 19:26:44 -0400 Received: from localhost.localdomain (nas24-99.vlt.club-internet.fr [195.36.223.99]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KNQga19594 for ; Mon, 20 Aug 2001 19:26:43 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1AAA63B2 for ; Tue, 21 Aug 2001 01:36:07 -0400 (EDT) Message-ID: <3B81F346.88BE4D60@ifrance.com> Date: Tue, 21 Aug 2001 01:36:07 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Mon, Aug 20, 2001 at 11:33:01PM +0200, Yann Guidon wrote: > > hello, > > > > the message below announces that a project account is > > opened for F-CPU in the Savannah server (FSF/MIT). > > if you want to help with the organisation, you have > > to subscribe there then send your request to Philippe > > > > > > BTW, we still need help for the maintainance of the > > F-CPU websites :-/ > > We have too many of them already. > What's this one supposed to be good for? > > > REYNES Philippe wrote: > > > > > > Bonjour > > > > > > je viens de creer le projet f-cpu sur savannah. > > > http://savannah.gnu.org/projects/f-cpu/ > > > > > > Bien entendu, toutes les personnes desirant faire > > > partie du projet doivent s'inscrire a savannah puis > > > me faire parvenir leur demande. > [...] > > Does `toutes les personnes desirant faire partie du projet' mean what > I think? "all people who wish to participate in the project"? > Yep ! > I didn't understand much of the rest. > Can somebody translate that, please? > Every who want to be part of the project should apply (?) to savannah and then mail Philippe. nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 01:51:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0w8-0005z5-01 for ; Tue, 21 Aug 2001 04:06:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:36 +0200 (CEST) Received: (qmail 1538 invoked by uid 0); 20 Aug 2001 23:52:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 20 Aug 2001 23:52:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA09888 for ; Mon, 20 Aug 2001 19:52:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 20 Aug 2001 23:52:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA09648 for f-cpu-list; Mon, 20 Aug 2001 19:52:05 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA09645 for ; Mon, 20 Aug 2001 19:52:04 -0400 Received: from tribble.stud.uni-hannover.de (michael@a053.home.uni-hannover.de [130.75.232.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7KNq2a19984 for ; Mon, 20 Aug 2001 19:52:02 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02204; Tue, 21 Aug 2001 01:51:59 +0200 Message-ID: <20010821015159.00560@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 01:51:59 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B81F346.88BE4D60@ifrance.com>; from nicO on Tue, Aug 21, 2001 at 01:36:07AM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: [...] > > I didn't understand much of the rest. > > Can somebody translate that, please? > > Every who want to be part of the project should apply (?) to savannah > and then mail Philippe. I consider myself being part of the project already. If I'm not, then something went wrong. But I don't know who Philippe is -- is *he* part of the project? Can we please *stop* moving from one server to another? I'm tired of that. What we really need is *one* central site which has basically everything, *one* mailing list, and no WWW clicky-clacky GUI, please (I can have that on sourceforge, too, and it *sucks*). It doesn't surprise me at all that nobody wants to maintain that mess. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Tue Aug 21 02:55:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Z0wA-0005z5-00 for ; Tue, 21 Aug 2001 04:06:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 04:06:38 +0200 (CEST) Received: (qmail 13953 invoked by uid 0); 21 Aug 2001 00:54:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 21 Aug 2001 00:54:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA11529 for ; Mon, 20 Aug 2001 20:54:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 00:53:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA11284 for f-cpu-list; Mon, 20 Aug 2001 20:53:41 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA11279 for ; Mon, 20 Aug 2001 20:53:38 -0400 Received: from online.ln.cn ([202.96.74.116]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f7L0ra620633 for ; Mon, 20 Aug 2001 20:53:37 -0400 Received: from maveric([61.137.139.100]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm03b81fef1; Tue, 21 Aug 2001 08:49:21 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point Date: Tue, 21 Aug 2001 08:55:02 +0800 X-Mailer: KMail [version 1.2] References: <3B81DF01.4103E718@ifrance.com> <20010821004816.62554@thrai.stud.uni-hannover.de> In-Reply-To: <20010821004816.62554@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Message-Id: <01082108550200.00266@maveric> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id UAA11282 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > On Tue, Aug 21, 2001 at 12:09:37AM -0400, nicO wrote: > The manual says: > > 00 32-bit > 01 64-bit > 1x unassigned Shouldn't we have SRs (yeah I know) to define the sizes the same as for the int unit? Then the software can choose the FP widths that it wants. Default might be: 00 32bit 01 64 bit 10 80 bit (optional and I don't like binary numbers that have more than one 1 in them and if the registers are 128 bit anyway, why not just bump up the resolution?) 11 128 bit (optional, but better than 80bit ;-) That's four more SRs, but they would only have to be state-saved if they were being used. Alternatively, just use the Int SRs for the float width. (we waste the 8 value - assuming we are using the defaults abd assuming no-one wants 8-bit floats (well someone might!) - and 16 bit floats are of dubious value at best, we would also have to re-define int types away if we wanted >64 bit floats and 80bit floats would be out (but I don't mind that - not if 128bit is avaliable) ) It depends on how many int-widths are likely to be used by the a program segment using floats, I guess. Is a mix adding up to four enough? -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy. Use GNU! [ http://www.gnu.org ] -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 08:55:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3F-0007uq-00 for ; Tue, 21 Aug 2001 22:23:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:05 +0200 (CEST) Received: (qmail 26486 invoked by uid 0); 21 Aug 2001 06:56:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Aug 2001 06:56:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA19787 for ; Tue, 21 Aug 2001 02:56:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 06:55:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA19522 for f-cpu-list; Tue, 21 Aug 2001 02:55:23 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA19518 for ; Tue, 21 Aug 2001 02:55:20 -0400 Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L6tJ623223 for ; Tue, 21 Aug 2001 02:55:19 -0400 Received: from f-cpu.org (nas3-38.ras.club-internet.fr [195.36.203.38]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id IAA13207 for ; Tue, 21 Aug 2001 08:55:16 +0200 (MET DST) Message-ID: <3B8205CE.1A3ECBE4@f-cpu.org> Date: Tue, 21 Aug 2001 08:55:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] still working... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i have downloaded vanilla but i don't really understand how to use it. can someone send me a little example script ? i am now trying to update the ROP2 unit and i have temporarily stopped with QDCPOC. i need a working VHDL compiler on Linux/x86 to test the new file generators. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3I-0007uq-00 for ; Tue, 21 Aug 2001 22:23:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:08 +0200 (CEST) Received: (qmail 28153 invoked by uid 0); 21 Aug 2001 08:20:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 21 Aug 2001 08:20:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22431 for ; Tue, 21 Aug 2001 04:20:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:18:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21139 for f-cpu-list; Tue, 21 Aug 2001 04:18:52 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21122 for ; Tue, 21 Aug 2001 04:18:46 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8Ij623997 for ; Tue, 21 Aug 2001 04:18:45 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA18289 for ; Tue, 21 Aug 2001 10:18:43 +0200 (MET DST) Message-ID: <3B821954.ECFF3B5C@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:28 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Execution unit port References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B805E66.578CB9EC@f-cpu.org> <3B81E54B.C0FD92D1@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > I'm looking for the "usual" definition of the port of a unit : > > > Does i miss a signal ? > > no, except for very special cases, it does the trick. > > there's no magic :-) > > Yep, but we need something more precise. In that case, it will be much > more easy to add or remove unit. Special case could became very boring > to handel... At this point, any "new" unit will be a "special case" because otherwise the addition would not be justified :-) It is fairly easy to "plug" the execution units to the necessary flags, just draw a wire from the corresponding port to the "current instruction buffer" and delay with the apropriate FF. Concerning the addition/removal of the units, i have added a special set of configuration lines in the m4 preprocessing files. There is a file : f-cpu/configuration/f-cpu_user.m4 which contains all the user-modifiable definition (register size, stepping, URL, etc.). The user can select which units he wants implemented by defining or not certain symbols. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3I-0007uq-01 for ; Tue, 21 Aug 2001 22:23:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:08 +0200 (CEST) Received: (qmail 32296 invoked by uid 0); 21 Aug 2001 08:20:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Aug 2001 08:20:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22447 for ; Tue, 21 Aug 2001 04:20:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:18:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21149 for f-cpu-list; Tue, 21 Aug 2001 04:18:55 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21126 for ; Tue, 21 Aug 2001 04:18:48 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8Il624002 for ; Tue, 21 Aug 2001 04:18:47 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA18307 for ; Tue, 21 Aug 2001 10:18:45 +0200 (MET DST) Message-ID: <3B82195F.484527D3@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: > [...] > > > I didn't understand much of the rest. > > > Can somebody translate that, please? > > > > Every who want to be part of the project should apply (?) to savannah > > and then mail Philippe. > > I consider myself being part of the project already. If I'm not, then > something went wrong. But I don't know who Philippe is -- is *he* > part of the project? i think that it was not explicitely what Philippe said, it was more in the sense of "if you want to participate in this site,..." of course there is no subscription, no requirement, no test etc if you want to become "part" of the project. only "participating" is necessary :-) > Can we please *stop* moving from one server to another? I'm tired of > that. What we really need is *one* central site which has basically > everything, *one* mailing list, and no WWW clicky-clacky GUI, please > (I can have that on sourceforge, too, and it *sucks*). It doesn't > surprise me at all that nobody wants to maintain that mess. i am often surprised (and not, at the same time), when people bark at the lack of "management" in this project. It is also surprising that we have so many websites in the same time, and too few are up to date. In the end, i prefer to "code" instead of asking impossible questions ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3J-0007uq-00 for ; Tue, 21 Aug 2001 22:23:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:09 +0200 (CEST) Received: (qmail 24816 invoked by uid 0); 21 Aug 2001 08:20:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 21 Aug 2001 08:20:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22475 for ; Tue, 21 Aug 2001 04:20:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:18:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21162 for f-cpu-list; Tue, 21 Aug 2001 04:18:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21135 for ; Tue, 21 Aug 2001 04:18:50 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8In624008 for ; Tue, 21 Aug 2001 04:18:49 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA09301 for ; Tue, 21 Aug 2001 10:18:46 +0200 (MET DST) Message-ID: <3B821958.A0104694@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Michael Riepe a écrit : > > On Sat, Aug 18, 2001 at 10:09:39PM -0400, Lee Salzman wrote: > > [...] > > > >Any other ideas how we can reduce/avoid the `address load penalty'? > > > An add coupled with a prefetch for data address loads off a > > > base/module register would be very nice. Possibly an immediate add > > > that some how supported longer immediate constants would be nice too, > > > but that could be done without. > > The `address add' idea looks better and better, and it's good for > > pointer/array/structure accesses, too. > Hum i don't like that at all because you schould put an adder just > before the memory unit. So we just as to make the pipeline longer. One > of the key point of the FC0, to shorten the pipeline, is to put in > parrallele the ALU and the load&store unit. If we put it in serial, we > longer the pipe. So i think, it's much better for that case to use 2 > instructions. Never forget that it's adding an other addressing mode . my personal point of view is to simply add a new "flavour" of the loadaddr instruction, which doesn't use the PC, that's all. The current form of LOADADDR looks like this : (from the manual) LOAD a relative ADDRess to a register loadaddr r2, r1 loadaddrd r2, r1 r1 = PC + 4 + r2, check the result in the D/I TLB and eventually prefetch the data. If you add a new opcode which says that we don't use PC but r3 (it's fairly straight-forward), we're done. no curious scheduling, nothing to change, the necessary HW doesn't change and we must simply update the manual and the instruction encoders/decoders. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3K-0007uq-00 for ; Tue, 21 Aug 2001 22:23:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:10 +0200 (CEST) Received: (qmail 31066 invoked by uid 0); 21 Aug 2001 08:20:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 21 Aug 2001 08:20:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22512 for ; Tue, 21 Aug 2001 04:20:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:19:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21165 for f-cpu-list; Tue, 21 Aug 2001 04:18:59 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21137 for ; Tue, 21 Aug 2001 04:18:51 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8In624009 for ; Tue, 21 Aug 2001 04:18:50 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA09308 for ; Tue, 21 Aug 2001 10:18:47 +0200 (MET DST) Message-ID: <3B821961.44DD6394@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:41 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] m4 won. References: <3B8058CB.5ADEF33C@f-cpu.org> <20010820073907.20382@thrai.stud.uni-hannover.de> <3B818215.5720F8B4@f-cpu.org> <20010821004020.29391@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Aug 20, 2001 at 11:33:09PM +0200, Yann Guidon wrote: > [...] > > > > It is going to take some time before i am > > > > ready so i am waiting for an update from Michael. > > > Update for what, the instruction encoder? > > yes, or for whatever you have/want. > > since you sent me a "preliminary" package, i believe > > that a new version exists. > No, the code is still the same. If there's nothing wrong with it, > I can put it into CVS. Somehere below f-cpu/compiler, I suppose? in a separate directory of f-cpu/compiler, i don't know yet. if you have not touched your files, i'll try to integrate them in my next bundle. > > > BTW: I created the first F-CPU object files yesterday :) > > and what does it make/compute ? :-) > Nothing... the source just contains every instruction variant we've > defined so far, plus the 79 asm directives I implemented (don't worry, > there are some aliases on the list). The only thing that's still > missing is the relocation table. wow. but if you can assemble, maybe you can disassemble ? and maybe even integrate it in the past attempt at a simulator ? someone has even made a GTK interface to one of the toys that were done. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3K-0007uq-01 for ; Tue, 21 Aug 2001 22:23:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:10 +0200 (CEST) Received: (qmail 27220 invoked by uid 0); 21 Aug 2001 08:20:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 21 Aug 2001 08:20:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22573 for ; Tue, 21 Aug 2001 04:20:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:19:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21234 for f-cpu-list; Tue, 21 Aug 2001 04:19:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21172 for ; Tue, 21 Aug 2001 04:18:58 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8Iv624018 for ; Tue, 21 Aug 2001 04:18:57 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA05890 for ; Tue, 21 Aug 2001 10:16:55 +0200 (MET DST) Message-ID: <3B821965.C8C3CCC9@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:45 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Mon, Aug 20, 2001 at 11:33:05PM +0200, Yann Guidon wrote: > [...] > > > > If there is something to say if the outed data is correct or not ? > > > Currently not; the scheduler should know. But we can add a `here is > > > the result, take it or I'll throw it away in the next cycle' signal. > > currently, only the IDIV has one. > No it doesn't, but I can add one :) if you use a fixed-latency approach, you don't need one. however, you could want to "optimise" one day with a data-dependent algorithm (leading MSB strip, etc...) and as long as the latency is still higher than the scheduling queue's depth, it is possible to have _one_ "ready" flag if it can be reased enough in advance. > > > Something is missing: the lines that select the instruction to execute > > > (if the unit can handle more than one instruction). > > ?? > Signals like Sub/Saturate in the ASU, or MacH/MacL in the IMU. in the ROP2 unit, these are "mode" flags and "function" flags, right ? add/substract would be a "function" and "saturation" would be a "mode" flag, i guess. nicO wrote : > whygee wrote : > > Michael wrote : > > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > > oh btw, the SIMD flag is useful for an EU _only_ if you optimize for speed > > and/or consumption. This flag is forwarded to the units but it is used mainly > > for the making of the writeback mask (in the register set). > So the SIMD stuff is for the same thing for register bank. The SIMD flag, the Opcode and the size flags are mixed to give a 5-bit field (the "write back mask") that goes to the register set. one can also combine these flags so only one part of the register is "computed" but i am still wondering stuffs about "clock gating". The Fetcher and the decoder have to "hold" some instructions, when a certain signal is asserted. by default, i use a MUX that loops the output to the input, under the control of the "next instruction" signal. However, the clocking is often not defined _inside_ the units but at the top level of the design. One year ago (approximately) we have tried to define a "generic" Flip-Flop gate but it is not satisfying yet. Could you (nicO and Michael) try to make this kind of generic gate ? > But we should always take good habit for improving power consumption > (speed and blablabla). i have been rather impressed by what you told me about it. if well-designed clock management is possible, i believe that we can synthesise a really competitive CPU. i simply wish that it doesn't run "too fast" because otherwise the core will stay idle and spend all the time waiting for data from memory ... Currently i need hints about core generators for the register set. i don't know precisely how to handle the partial writes and the speed i can get. I am also designing the last (i hope) version of the ROP2 unit. This will give a rough estimate of the clock speed. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 10:18:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3L-0007uq-00 for ; Tue, 21 Aug 2001 22:23:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:11 +0200 (CEST) Received: (qmail 28565 invoked by uid 0); 21 Aug 2001 08:20:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 21 Aug 2001 08:20:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA22602 for ; Tue, 21 Aug 2001 04:20:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:19:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA21371 for f-cpu-list; Tue, 21 Aug 2001 04:19:16 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA21254 for ; Tue, 21 Aug 2001 04:19:07 -0400 Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8J5624027 for ; Tue, 21 Aug 2001 04:19:05 -0400 Received: from f-cpu.org (nas4-115.ras.club-internet.fr [195.36.203.115]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA13954 for ; Tue, 21 Aug 2001 10:19:03 +0200 (MET DST) Message-ID: <3B82196E.5E525B8C@f-cpu.org> Date: Tue, 21 Aug 2001 10:18:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: Re: [f-cpu] floating point width. References: <3B819298.97E050E9@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, (i answer in the "new" mailing list, btw) Ben Franchuk wrote: > Just what is the internal width for the floating point registers in the FCPU? they share the integer stuff, so with a 64-bit F-CPU we can store one 64-bit FP number or 2*32. > Ben. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Tue Aug 21 10:36:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3M-0007uq-00 for ; Tue, 21 Aug 2001 22:23:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:12 +0200 (CEST) Received: (qmail 3053 invoked by uid 0); 21 Aug 2001 08:51:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Aug 2001 08:51:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA23342 for ; Tue, 21 Aug 2001 04:51:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 08:50:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA23079 for f-cpu-list; Tue, 21 Aug 2001 04:50:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA23061 for ; Tue, 21 Aug 2001 04:50:33 -0400 Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7L8oW624299 for ; Tue, 21 Aug 2001 04:50:33 -0400 Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 15Z718-0007fM-00; Tue, 21 Aug 2001 10:36:10 +0200 Date: Tue, 21 Aug 2001 10:36:10 +0200 From: Paul Marques Mota To: f-cpu@seul.org Cc: REYNES Philippe Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] Message-ID: <20010821103610.A22097@opium.april.org> References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010821015159.00560@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Tue, Aug 21, 2001 at 01:51:59AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 01:51:59AM +0200, Michael Riepe wrote: > On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: > [...] > > > I didn't understand much of the rest. > > > Can somebody translate that, please? > > > > Every who want to be part of the project should apply (?) to savannah > > and then mail Philippe. > > I consider myself being part of the project already. If I'm not, then > something went wrong. But I don't know who Philippe is -- is *he* > part of the project? > > Can we please *stop* moving from one server to another? I'm tired of > that. I second that. > What we really need is *one* central site which has basically > everything, *one* mailing list, and no WWW clicky-clacky GUI, please You mean seul.org? That means that all the web sites should be moved, the cvs repository should be moved either and the french and german mailing-list should be closed. It also means that there might be a single point of failure which frightened whygee (that's not surprising after the yahoo problems) Last but not the least, it spoils the wonderful job that andreas has done on the CVS setup. > (I can have that on sourceforge, too, and it *sucks*). It doesn't > surprise me at all that nobody wants to maintain that mess. > > -- > Michael "Tired" Riepe -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 12:37:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3N-0007uq-00 for ; Tue, 21 Aug 2001 22:23:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:13 +0200 (CEST) Received: (qmail 17830 invoked by uid 0); 21 Aug 2001 10:38:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 21 Aug 2001 10:38:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA25353 for ; Tue, 21 Aug 2001 06:38:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 10:37:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA25103 for f-cpu-list; Tue, 21 Aug 2001 06:37:56 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA25100 for ; Tue, 21 Aug 2001 06:37:55 -0400 Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LAbs625323 for ; Tue, 21 Aug 2001 06:37:55 -0400 Received: from f-cpu.org (nas3-50.ras.club-internet.fr [195.36.203.50]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA03724 for ; Tue, 21 Aug 2001 12:37:52 +0200 (MET DST) Message-ID: <3B8239FA.94702F60@f-cpu.org> Date: Tue, 21 Aug 2001 12:37:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] vanilla vhdl: "=?iso-8859-1?Q?g=E4=E4=C4hhh?= !" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, now i have understood why i can't use vanilla vhdl : it uses an outdated libc.so version and i can't install an older one on my computer(s). i'll try simili/wine if i have enough courage :-/ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From reynes@irit.fr Tue Aug 21 12:40:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3N-0007uq-01 for ; Tue, 21 Aug 2001 22:23:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:13 +0200 (CEST) Received: (qmail 31868 invoked by uid 0); 21 Aug 2001 10:41:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 21 Aug 2001 10:41:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA25687 for ; Tue, 21 Aug 2001 06:41:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 10:40:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA25446 for f-cpu-list; Tue, 21 Aug 2001 06:40:59 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA25443 for ; Tue, 21 Aug 2001 06:40:58 -0400 Received: from irit.irit.fr (irit.irit.fr [141.115.4.5]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LAev625364 for ; Tue, 21 Aug 2001 06:40:58 -0400 Received: from irit.fr (ares [141.115.8.74]) by irit.irit.fr (8.9.3/8.9.3) with ESMTP id MAA05919 for ; Tue, 21 Aug 2001 12:41:17 +0200 (MET DST) Message-ID: <3B823AB6.2FBD969A@irit.fr> Date: Tue, 21 Aug 2001 12:40:54 +0200 From: REYNES Philippe Organization: APARA X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi > > > > I didn't understand much of the rest. > > > > Can somebody translate that, please? > > > > > > Every who want to be part of the project should apply (?) to savannah > > > and then mail Philippe. > > > > I consider myself being part of the project already. If I'm not, then > > something went wrong. But I don't know who Philippe is -- is *he* > > part of the project? > > > > Can we please *stop* moving from one server to another? I'm tired of > > that. > I second that. First, I have to present me a bit. I'm a french computer science student, I study processor architecture. I try to understand this project, where you are and where you go. My main problem was to gather all f-cpu information. It isn't very easy. My second problem was, who works on what ? who makes the architecture, the design, ..... !!! who takes decision ??? It's the reason of my proposition to use savannah and his task manager. I think that this project need a bit of managing. > > What we really need is *one* central site which has basically > > everything, *one* mailing list, and no WWW clicky-clacky GUI, please > You mean seul.org? > That means that all the web sites should be moved, the cvs repository > should be moved either and the french and german mailing-list should be > closed. It also means that there might be a single point of failure > which frightened whygee (that's not surprising after the yahoo > problems) well, yes and not !!! We could mrigrate slowly to savannah. For example, we could start to use The task manager and the news part and patch and support. > Last but not the least, it spoils the wonderful job that andreas has done > on the CVS setup. I think that we should keep it (at least in a first step). As I said up, I think that we (this project) need to managed more. Some people works on everything, some people works on nothing. I have worked on another project (v2os) and it was clear that many people want (or need) to be led. If I take my example, I'm an architect and I don't know VHDL. I would like to learn (VHDL), but to work on f-cpu I need help. I can try to write a body but not found entity. You see what I mean ? As I have proposed it on the french ML (forwarded by yg), I propose: - to split this big project on sub-project * architecture (and simulator) * design * compiler * system (port linux to f-cpu processor) to anwser yg's question, manuel are part of each sub-project. architecture group make the architecture manual, and so on ... - to put a leader (manager) to each sub-project. This isn't a boss but a manager. His job would be to gather information (who works on what, last manual, ..). I said it again, It woun't be a boss, we are in an open source project but wasting time isn't nice and necessary. For example: architecture leader -> yg design leader -> mikael compiler leader -> nic0 system leader -> dunno savannah is nice because it's easy to change admin. If I don't mistake, you have lost one (or more) web site with the lost of the owner. I'll put another admin in savannah. I think that savannah could make us publicity too. Of course, it's a proposition ..... If you think that it's a bad idea, just tell me and I'll throw it away. But if you think that it's a good idea and that we must use it, I propose to manage savannah. philippe PS: sorry for my english, I'm a little frenchy :( ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From philippe.trbich@free.fr Tue Aug 21 14:33:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3P-0007uq-00 for ; Tue, 21 Aug 2001 22:23:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:15 +0200 (CEST) Received: (qmail 6249 invoked by uid 0); 21 Aug 2001 12:34:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Aug 2001 12:34:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA27661 for ; Tue, 21 Aug 2001 08:34:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 12:33:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA27421 for f-cpu-list; Tue, 21 Aug 2001 08:33:52 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA27418 for ; Tue, 21 Aug 2001 08:33:51 -0400 Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LCXo626595 for ; Tue, 21 Aug 2001 08:33:51 -0400 Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix1-2.free.fr (Postfix) with ESMTP id 387F5AB29F; Tue, 21 Aug 2001 14:33:46 +0200 (CEST) Received: from imp3-1.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f7LCXkGc020204; Tue, 21 Aug 2001 14:33:46 +0200 Received: (from www-data@localhost) by imp3-1.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f7LCXjid020203; Tue, 21 Aug 2001 14:33:45 +0200 To: f-cpu@seul.org, Yann Guidon Subject: Re: [f-cpu] still working... Message-ID: <998397225.3b82552983244@imp3-1.free.fr> Date: Tue, 21 Aug 2001 14:33:45 +0200 (MEST) From: philippe.trbich@free.fr Cc: fm References: <3B8205CE.1A3ECBE4@f-cpu.org> In-Reply-To: <3B8205CE.1A3ECBE4@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 164.2.255.244 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N En réponse à Yann Guidon : > hello, > > i have downloaded vanilla but i don't really understand > how to use it. can someone send me a little example script ? > i am now trying to update the ROP2 unit and i have > temporarily stopped with QDCPOC. i need a working VHDL > compiler on Linux/x86 to test the new file generators. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > I'm interrested too! Please, send the response, if any on the main list. Cordially. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 23:14:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3R-0007uq-01 for ; Tue, 21 Aug 2001 22:23:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:17 +0200 (CEST) Received: (qmail 30273 invoked by uid 0); 21 Aug 2001 15:05:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Aug 2001 15:05:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA31270 for ; Tue, 21 Aug 2001 11:05:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 15:05:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA31018 for f-cpu-list; Tue, 21 Aug 2001 11:05:24 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA31008 for ; Tue, 21 Aug 2001 11:05:11 -0400 Received: from localhost.localdomain (nas24-27.vlt.club-internet.fr [195.36.223.27]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LF5A629357 for ; Tue, 21 Aug 2001 11:05:10 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 09BA4161A for ; Tue, 21 Aug 2001 17:14:38 -0400 (EDT) Message-ID: <3B82CF3D.65DDB4A2@ifrance.com> Date: Tue, 21 Aug 2001 17:14:37 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <3B821958.A0104694@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Michael Riepe a écrit : > > > On Sat, Aug 18, 2001 at 10:09:39PM -0400, Lee Salzman wrote: > > > [...] > > > > >Any other ideas how we can reduce/avoid the `address load penalty'? > > > > An add coupled with a prefetch for data address loads off a > > > > base/module register would be very nice. Possibly an immediate add > > > > that some how supported longer immediate constants would be nice too, > > > > but that could be done without. > > > The `address add' idea looks better and better, and it's good for > > > pointer/array/structure accesses, too. > > Hum i don't like that at all because you schould put an adder just > > before the memory unit. So we just as to make the pipeline longer. One > > of the key point of the FC0, to shorten the pipeline, is to put in > > parrallele the ALU and the load&store unit. If we put it in serial, we > > longer the pipe. So i think, it's much better for that case to use 2 > > instructions. Never forget that it's adding an other addressing mode . > > my personal point of view is to simply add a new "flavour" of the > loadaddr instruction, which doesn't use the PC, that's all. > > The current form of LOADADDR looks like this : (from the manual) > > LOAD a relative ADDRess to a register > loadaddr r2, r1 > loadaddrd r2, r1 > r1 = PC + 4 + r2, check the result in the D/I TLB and eventually prefetch the data. > > If you add a new opcode which says that we don't use PC but r3 > (it's fairly straight-forward), we're done. no curious scheduling, > nothing to change, the necessary HW doesn't change and we must simply > update the manual and the instruction encoders/decoders. > Seems ok to me. But why don't we map the PC inside the register map ? nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 23:20:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3S-0007uq-00 for ; Tue, 21 Aug 2001 22:23:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:18 +0200 (CEST) Received: (qmail 6327 invoked by uid 0); 21 Aug 2001 15:11:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 21 Aug 2001 15:11:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA31788 for ; Tue, 21 Aug 2001 11:11:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 15:11:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA31517 for f-cpu-list; Tue, 21 Aug 2001 11:11:14 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA31492 for ; Tue, 21 Aug 2001 11:10:39 -0400 Received: from localhost.localdomain (nas24-27.vlt.club-internet.fr [195.36.223.27]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LFAZ629472 for ; Tue, 21 Aug 2001 11:10:36 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0F84E161A for ; Tue, 21 Aug 2001 17:20:04 -0400 (EDT) Message-ID: <3B82D083.C836C8E9@ifrance.com> Date: Tue, 21 Aug 2001 17:20:03 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > Michael Riepe wrote: > > On Mon, Aug 20, 2001 at 11:33:05PM +0200, Yann Guidon wrote: > > [...] > > > > > If there is something to say if the outed data is correct or not ? > > > > Currently not; the scheduler should know. But we can add a `here is > > > > the result, take it or I'll throw it away in the next cycle' signal. > > > currently, only the IDIV has one. > > No it doesn't, but I can add one :) > > if you use a fixed-latency approach, you don't need one. > however, you could want to "optimise" one day with a data-dependent > algorithm (leading MSB strip, etc...) and as long as the latency is > still higher than the scheduling queue's depth, it is possible to > have _one_ "ready" flag if it can be reased enough in advance. > > > > > Something is missing: the lines that select the instruction to execute > > > > (if the unit can handle more than one instruction). > > > ?? > > Signals like Sub/Saturate in the ASU, or MacH/MacL in the IMU. > in the ROP2 unit, these are "mode" flags and "function" flags, right ? > add/substract would be a "function" and "saturation" would be a "mode" > flag, i guess. > > nicO wrote : > > whygee wrote : > > > Michael wrote : > > > > Make that `chunk size'; I use std_ulogic_vector(2 downto 0) for it. > > > oh btw, the SIMD flag is useful for an EU _only_ if you optimize for speed > > > and/or consumption. This flag is forwarded to the units but it is used mainly > > > for the making of the writeback mask (in the register set). > > So the SIMD stuff is for the same thing for register bank. > The SIMD flag, the Opcode and the size flags are mixed to give a 5-bit > field (the "write back mask") that goes to the register set. > one can also combine these flags so only one part of the register > is "computed" but i am still wondering stuffs about "clock gating". > > The Fetcher and the decoder have to "hold" some instructions, > when a certain signal is asserted. by default, i use a MUX > that loops the output to the input, under the control of the > "next instruction" signal. However, the clocking is often not > defined _inside_ the units but at the top level of the design. > One year ago (approximately) we have tried to define a "generic" > Flip-Flop gate but it is not satisfying yet. > Could you (nicO and Michael) try to make this kind of generic gate ? > > > But we should always take good habit for improving power consumption > > (speed and blablabla). > i have been rather impressed by what you told me about it. > if well-designed clock management is possible, i believe that > we can synthesise a really competitive CPU. > > i simply wish that it doesn't > run "too fast" because otherwise the core will stay idle and spend > all the time waiting for data from memory ... > > Currently i need hints about core generators for the register set. > i don't know precisely how to handle the partial writes and the speed > i can get. > > I am also designing the last (i hope) version of the ROP2 unit. > This will give a rough estimate of the clock speed. > Typically register bank could be seen as multiported SRAM memory. So it's hard for me to understand why you need 5 flags to write back the registers. When you write back a none SIMD 8 bit result does the 56 other bits remain unchange or are zeroed ? nicO > > Michael "Tired" Riepe > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 23:34:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3T-0007uq-00 for ; Tue, 21 Aug 2001 22:23:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:19 +0200 (CEST) Received: (qmail 22641 invoked by uid 0); 21 Aug 2001 15:25:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 21 Aug 2001 15:25:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA32388 for ; Tue, 21 Aug 2001 11:25:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 15:25:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA32144 for f-cpu-list; Tue, 21 Aug 2001 11:25:19 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA32141 for ; Tue, 21 Aug 2001 11:25:18 -0400 Received: from localhost.localdomain (nas24-27.vlt.club-internet.fr [195.36.223.27]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LFPG629847 for ; Tue, 21 Aug 2001 11:25:17 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D9ED3161A for ; Tue, 21 Aug 2001 17:34:44 -0400 (EDT) Message-ID: <3B82D3F4.43924223@ifrance.com> Date: Tue, 21 Aug 2001 17:34:44 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Scheduler References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <3B803091.C8F69A22@ifrance.com> <3B8083F0.1492B76D@ifrance.com> <3B809F00.8E7C5A3F@ifrance.com> <3B818761.B8B9E367@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N To be even explicit about my proposal : @ reg # is the the address of the register # inside the instruction word. @ (alone) is the 2 (i miss one sorry) address of the register that will be write, it correspond to a specific place inside the execution pipeline (ususefull later for write back). #active is the number of the active unit for a given pipeline stage, normaly there is only one active unit for a given pipe stage because FC0 is a one way processor, there is here a problem for instruction with low thoughput (a thoughput of 1, signify that the unit could give a result every cycle, a thoughput of 2 is a unit that give a result every 2 cycle). The other parameter is the latency of the unit, typically the number of pipe stage. eu1..eu2.. is the data bus from each eu if it exist, it's multiplexed with #active to give the really used bus. So if there is a hit and if the work is done (it seems that i forget this 'and'..) i bypass the access to the register bank (there is 3 register read so 3 bypass mux). If there is a hit and not a done, a 'dead cycle' should be inserted (off: a counter of dead cycle should be used to better tune the code). The done could the flag explain by Michael to say "ok, the output data is valid". Is it more explicit ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 21 23:38:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3U-0007uq-00 for ; Tue, 21 Aug 2001 22:23:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:20 +0200 (CEST) Received: (qmail 30647 invoked by uid 0); 21 Aug 2001 15:28:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 21 Aug 2001 15:28:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA32702 for ; Tue, 21 Aug 2001 11:28:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 15:28:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA32452 for f-cpu-list; Tue, 21 Aug 2001 11:28:36 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA32449 for ; Tue, 21 Aug 2001 11:28:34 -0400 Received: from localhost.localdomain (nas24-27.vlt.club-internet.fr [195.36.223.27]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LFSX629988 for ; Tue, 21 Aug 2001 11:28:33 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2FE02161A for ; Tue, 21 Aug 2001 17:38:01 -0400 (EDT) Message-ID: <3B82D4B9.89A618EA@ifrance.com> Date: Tue, 21 Aug 2001 17:38:01 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Paul Marques Mota a écrit : > > On Tue, Aug 21, 2001 at 01:51:59AM +0200, Michael Riepe wrote: > > On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: > > [...] > > > > I didn't understand much of the rest. > > > > Can somebody translate that, please? > > > > > > Every who want to be part of the project should apply (?) to savannah > > > and then mail Philippe. > > > > I consider myself being part of the project already. If I'm not, then > > something went wrong. But I don't know who Philippe is -- is *he* > > part of the project? > > > > Can we please *stop* moving from one server to another? I'm tired of > > that. > > I second that. > > > What we really need is *one* central site which has basically > > everything, *one* mailing list, and no WWW clicky-clacky GUI, please > > You mean seul.org? > > That means that all the web sites should be moved, the cvs repository > should be moved either and the french and german mailing-list should be > closed. It also means that there might be a single point of failure > which frightened whygee (that's not surprising after the yahoo > problems) > Last but not the least, it spoils the wonderful job that andreas has done > on the CVS setup. > I have eard a lot about cvs but i didn't really know about it. Somebody could write something to resume all the "thing" that is used by the project (cvs, savannah, fcpu.org,...). I'm a little lost. nicO > > (I can have that on sourceforge, too, and it *sucks*). It doesn't > > surprise me at all that nobody wants to maintain that mess. > > > > -- > > Michael "Tired" Riepe > > -- > Paul > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 17:42:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3V-0007uq-00 for ; Tue, 21 Aug 2001 22:23:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:21 +0200 (CEST) Received: (qmail 11689 invoked by uid 0); 21 Aug 2001 15:43:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 21 Aug 2001 15:43:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA00790 for ; Tue, 21 Aug 2001 11:43:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 15:42:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA00533 for f-cpu-list; Tue, 21 Aug 2001 11:42:42 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA00530 for ; Tue, 21 Aug 2001 11:42:41 -0400 Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LFge630378 for ; Tue, 21 Aug 2001 11:42:40 -0400 Received: from f-cpu.org (nas2-212.aub.club-internet.fr [195.36.133.212]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA16052 for ; Tue, 21 Aug 2001 17:42:29 +0200 (MET DST) Message-ID: <3B82815F.7B114CCF@f-cpu.org> Date: Tue, 21 Aug 2001 17:42:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] sigsegv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i gave FreeHDL a try and it's not brilliant. the compilation ran my laptop out of memory and ended up with sigsegv. i'll have to test my files with simili. The only good thing is that i have learnt how to configure a swap filewith Linux. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 17:11:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3X-0007uq-00 for ; Tue, 21 Aug 2001 22:23:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:23 +0200 (CEST) Received: (qmail 25943 invoked by uid 0); 21 Aug 2001 16:05:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 21 Aug 2001 16:05:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA02131 for ; Tue, 21 Aug 2001 12:05:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:04:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01349 for f-cpu-list; Tue, 21 Aug 2001 12:04:51 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01346 for ; Tue, 21 Aug 2001 12:04:50 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG4m630668 for ; Tue, 21 Aug 2001 12:04:48 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00929; Tue, 21 Aug 2001 17:11:18 +0200 Message-ID: <20010821171118.02508@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 17:11:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <3B821958.A0104694@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B821958.A0104694@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 10:18:32AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 10:18:32AM +0200, Yann Guidon wrote: [...] > my personal point of view is to simply add a new "flavour" of the > loadaddr instruction, which doesn't use the PC, that's all. *nod* > The current form of LOADADDR looks like this : (from the manual) > > LOAD a relative ADDRess to a register > loadaddr r2, r1 > loadaddrd r2, r1 > r1 = PC + 4 + r2, check the result in the D/I TLB and eventually prefetch the data. > > If you add a new opcode which says that we don't use PC but r3 > (it's fairly straight-forward), we're done. no curious scheduling, > nothing to change, the necessary HW doesn't change and we must simply > update the manual and the instruction encoders/decoders. What about this: loadaddrb r3, r2, r1 # r1 = r2 + r3 (code address) loadaddrbd r3, r2, r1 # r1 = r2 + r3 (data address) loadaddrbi simm8, r2, r1 # r1 = r2 + simm8 (code address) loadaddrbid simm8, r2, r1 # r1 = r2 + simm8 (data address) (`-b' means `based (on register r2)'). Unfortunately, the encoding has to be different (3 operands instead of 2), so there's not enough room for a 16-bit immediate operand (the maximum is 32-8-2*6-1 = 11 bits). Otherwise, the original `loadaddr' instruction could be made a special case of this one (e.g. when r2=0, use PC+4 instead). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 16:42:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3X-0007uq-01 for ; Tue, 21 Aug 2001 22:23:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:23 +0200 (CEST) Received: (qmail 5709 invoked by uid 0); 21 Aug 2001 16:05:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 21 Aug 2001 16:05:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA02480 for ; Tue, 21 Aug 2001 12:05:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:04:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01411 for f-cpu-list; Tue, 21 Aug 2001 12:04:57 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01394 for ; Tue, 21 Aug 2001 12:04:54 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG4p630672 for ; Tue, 21 Aug 2001 12:04:51 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00852; Tue, 21 Aug 2001 16:42:28 +0200 Message-ID: <20010821164228.36087@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 16:42:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> <3B823AB6.2FBD969A@irit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B823AB6.2FBD969A@irit.fr>; from REYNES Philippe on Tue, Aug 21, 2001 at 12:40:54PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 12:40:54PM +0200, REYNES Philippe wrote: [...] > First, I have to present me a bit. > I'm a french computer science student, I study processor architecture. > I try to understand this project, where you are and where you go. Bonjour Philippe, nice to meet you. > My main problem was to gather all f-cpu information. It isn't very easy. > My second problem was, who works on what ? > who makes the architecture, the design, ..... !!! who takes decision ??? > It's the reason of my proposition to use savannah and his task manager. > I think that this project need a bit of managing. I suggest a meta-manager who manages the management :) > > > What we really need is *one* central site which has basically > > > everything, *one* mailing list, and no WWW clicky-clacky GUI, please > > You mean seul.org? > > > That means that all the web sites should be moved, the cvs repository > > should be moved either and the french and german mailing-list should be > > closed. It also means that there might be a single point of failure > > which frightened whygee (that's not surprising after the yahoo > > problems) > > well, yes and not !!! I'd rather not move the CVS now that we have it. It was supposed to be on seul.org, but it's fine the way it is. We can mirror it somewhere to avoid the SPOF, though (read-only). The english mailing list on seul is fine, too. There's no need to move it again. The french and german lists need not be closed, but I ask people again and again to move important discussions to the english list. I feel a little bit lost here, sometimes. There should be a single, central website that is easy to find (probably www.f-cpu.org) and has links to everything -- the CVS, the mailing list(s), websites of national organizations (like the "F-CPU Verein" in Germany) and so on. Any other websites we may have should be redirected to this main entry point, to ease maintenance. I really don't care on which host and in which country the CVS repository and the mailing lists are located, as long as there is a single "portal" site that leads people everywhere they want. [...] > As I said up, I think that we (this project) need to managed more. > Some people works on everything, some people works on nothing. Is that a problem? I'm pretty glad that at least somebody works on something ;) > I have worked on another project (v2os) and it was clear that many > people > want (or need) to be led. Sorry, but I don't like being `led'. The very day this project is going to become `led' by somebody (group or individual), it's also going to lose one of its contributors -- me. [...] > As I have proposed it on the french ML (forwarded by yg), I propose: > - to split this big project on sub-project > * architecture (and simulator) > * design > * compiler > * system (port linux to f-cpu processor) I guess I have my fingers in 3 of 4 pies already -- and the only reason why I don't have them in all of them is that the Linux port didn't start yet ;) > to anwser yg's question, manuel are part of each sub-project. > architecture group make the architecture manual, and so on ... > > - to put a leader (manager) to each sub-project. This isn't a boss but a > manager. His job would be to gather information (who works on what, last > manual, ..). And what is (s)he going to do with that information? > I said it again, It woun't be a boss, we are in an open source project > but > wasting time isn't nice and necessary. > For example: > architecture leader -> yg > design leader -> mikael > compiler leader -> nic0 > system leader -> dunno What we really need is a `speaker', a PR agent -- somebody who watches the project (but does not participate in any of these sub-projects), reports the latest-and-greatest facts and details on the website, talks to the outer world (companies, organizations, the press), answers questions and so on. This is something I definitely don't want to do myself. It's not the sexiest job either. But perhaps it helps cleaning up the mess -- and it gives people like me a chance to do what we're really good at, without being disturbed or interrupted too much. Find me somebody who keeps people off my back, and I can work wonders (like writing an almost complete assembler in less than a week ;). [...] > PS: sorry for my english, I'm a little frenchy :( It's much better than my french, believe me ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 15:39:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3Y-0007uq-00 for ; Tue, 21 Aug 2001 22:23:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:24 +0200 (CEST) Received: (qmail 28151 invoked by uid 0); 21 Aug 2001 16:06:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 21 Aug 2001 16:06:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA02950 for ; Tue, 21 Aug 2001 12:06:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01589 for f-cpu-list; Tue, 21 Aug 2001 12:05:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01536 for ; Tue, 21 Aug 2001 12:05:02 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG4w630679 for ; Tue, 21 Aug 2001 12:05:00 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00696; Tue, 21 Aug 2001 15:39:17 +0200 Message-ID: <20010821153917.18399@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 15:39:17 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Re: =?iso-8859-1?Q?=5Bf-cpu=5D_vanilla_vhdl=3A_=22g=E4=E4=C4hhh_!=22?= References: <3B8239FA.94702F60@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B8239FA.94702F60@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 12:37:46PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 12:37:46PM +0200, Yann Guidon wrote: > now i have understood why i can't use vanilla vhdl : > it uses an outdated libc.so version and i can't install > an older one on my computer(s). Why not? Put libc.so.5 and ld-linux.so.1 into /lib, run ldconfig, and you're basically done. Alternatively, you can use vv87 instead of va87 and vs87 (it is statically linked and should work on your system, too). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 15:34:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3Z-0007uq-00 for ; Tue, 21 Aug 2001 22:23:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:25 +0200 (CEST) Received: (qmail 23930 invoked by uid 0); 21 Aug 2001 16:06:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 21 Aug 2001 16:06:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03127 for ; Tue, 21 Aug 2001 12:06:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01738 for f-cpu-list; Tue, 21 Aug 2001 12:05:14 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01661 for ; Tue, 21 Aug 2001 12:05:10 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG52630688 for ; Tue, 21 Aug 2001 12:05:03 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00674; Tue, 21 Aug 2001 15:34:48 +0200 Message-ID: <20010821153448.44018@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 15:34:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B821965.C8C3CCC9@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 10:18:45AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 10:18:45AM +0200, Yann Guidon wrote: [...] > > > > Something is missing: the lines that select the instruction to execute > > > > (if the unit can handle more than one instruction). > > > ?? > > Signals like Sub/Saturate in the ASU, or MacH/MacL in the IMU. > in the ROP2 unit, these are "mode" flags and "function" flags, right ? > add/substract would be a "function" and "saturation" would be a "mode" > flag, i guess. That's it, exactly. > The Fetcher and the decoder have to "hold" some instructions, > when a certain signal is asserted. by default, i use a MUX > that loops the output to the input, under the control of the > "next instruction" signal. However, the clocking is often not > defined _inside_ the units but at the top level of the design. > One year ago (approximately) we have tried to define a "generic" > Flip-Flop gate but it is not satisfying yet. > Could you (nicO and Michael) try to make this kind of generic gate ? You mean, like this? process (Clk) begin if rising_edge(Clk) then if to_X01(Enable) = '0' then Output <= Input; end if; end if; end process; Synopsys can turn that into a clock gate if you tell it to do so. I've been using it in the latest versions of the multiplier, too. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 15:09:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3a-0007uq-01 for ; Tue, 21 Aug 2001 22:23:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:26 +0200 (CEST) Received: (qmail 1364 invoked by uid 0); 21 Aug 2001 16:06:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 21 Aug 2001 16:06:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03275 for ; Tue, 21 Aug 2001 12:06:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01918 for f-cpu-list; Tue, 21 Aug 2001 12:05:26 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01818 for ; Tue, 21 Aug 2001 12:05:18 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG5G630706 for ; Tue, 21 Aug 2001 12:05:16 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00610; Tue, 21 Aug 2001 15:09:53 +0200 Message-ID: <20010821150953.28365@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 15:09:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <3B82195F.484527D3@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B82195F.484527D3@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 10:18:39AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 10:18:39AM +0200, Yann Guidon wrote: [...] > i am often surprised (and not, at the same time), when people bark > at the lack of "management" in this project. It is also surprising > that we have so many websites in the same time, and too few are > up to date. What was "management" good for, by the way? ;) I certainly don't need a project manager; I know what to do, how to do it, and in which sequence. The public appearance of the F-CPU Project, on the other hand, could be improved a lot. At the moment, it is pretty confusing, and adding yet another (potentially unmaintained and unused) website only makes it worse. I guess it's time for "Grossreinemachen" (in english: a major clean-up). Think about it. > In the end, i prefer to "code" instead of asking impossible questions ;-) Amen. But I still wonder what you guys in France are doing behind the curtains. You won't let us have a look, will you? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 14:42:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3b-0007uq-00 for ; Tue, 21 Aug 2001 22:23:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:27 +0200 (CEST) Received: (qmail 14626 invoked by uid 0); 21 Aug 2001 16:06:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 21 Aug 2001 16:06:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03289 for ; Tue, 21 Aug 2001 12:06:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01983 for f-cpu-list; Tue, 21 Aug 2001 12:05:30 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01859 for ; Tue, 21 Aug 2001 12:05:21 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG5J630710 for ; Tue, 21 Aug 2001 12:05:19 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00543; Tue, 21 Aug 2001 14:42:36 +0200 Message-ID: <20010821144236.58101@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 14:42:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] still working... References: <3B8205CE.1A3ECBE4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B8205CE.1A3ECBE4@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 08:55:10AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 08:55:10AM +0200, Yann Guidon wrote: > i have downloaded vanilla but i don't really understand > how to use it. can someone send me a little example script ? It's rather simple. Change to the `vvhdlt' directory and run `./va87 -x ../wherever/it/is/myfile.vhdl' (the `-x' option enables support for VHDL'93). If there are no errors, you can run the simulation with `./vs87 work.testbench_entity_name'. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 14:38:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3b-0007uq-01 for ; Tue, 21 Aug 2001 22:23:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:27 +0200 (CEST) Received: (qmail 24988 invoked by uid 0); 21 Aug 2001 16:06:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 21 Aug 2001 16:06:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03334 for ; Tue, 21 Aug 2001 12:06:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA02109 for f-cpu-list; Tue, 21 Aug 2001 12:05:37 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01946 for ; Tue, 21 Aug 2001 12:05:27 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG5M630714 for ; Tue, 21 Aug 2001 12:05:22 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00527; Tue, 21 Aug 2001 14:38:02 +0200 Message-ID: <20010821143802.05173@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 14:38:02 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <3B81DF01.4103E718@ifrance.com> <20010821004816.62554@thrai.stud.uni-hannover.de> <01082108550200.00266@maveric> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <01082108550200.00266@maveric>; from Glenn Alexander on Tue, Aug 21, 2001 at 08:55:02AM +0800 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 08:55:02AM +0800, Glenn Alexander wrote: [...] > Shouldn't we have SRs (yeah I know) to define the sizes the same as for the > int unit? Then the software can choose the FP widths that it wants. Default > might be: > > 00 32bit > 01 64 bit > 10 80 bit (optional and I don't like binary numbers that have more than one 1 > in them and if the registers are 128 bit anyway, why not just bump up the > resolution?) > 11 128 bit (optional, but better than 80bit ;-) "binary numbers with only one `1' in them" are commonly called "powers of two" :) And yes, they're something special... > That's four more SRs, but they would only have to be state-saved if they were > being used. > > Alternatively, just use the Int SRs for the float width. No, the encoding is different. I suggest we don't even use the same bits in the instruction word. The reason is that there are two instructions that need both an FP size and an integer size (int2f and f2int), unless we declare the operation to be `size-preserving' (that is, 32-bit int <-> 32-bit FP only, and likewise for 64-bit). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 18:09:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3c-0007uq-00 for ; Tue, 21 Aug 2001 22:23:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:28 +0200 (CEST) Received: (qmail 26235 invoked by uid 0); 21 Aug 2001 16:10:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 21 Aug 2001 16:10:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03838 for ; Tue, 21 Aug 2001 12:10:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:09:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA03397 for f-cpu-list; Tue, 21 Aug 2001 12:09:49 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA03394 for ; Tue, 21 Aug 2001 12:09:48 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG9l630830 for ; Tue, 21 Aug 2001 12:09:47 -0400 Received: from f-cpu.org (nas4-117.ras.club-internet.fr [195.36.203.117]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA03966 for ; Tue, 21 Aug 2001 18:09:39 +0200 (MET DST) Message-ID: <3B8287BE.598D1D75@f-cpu.org> Date: Tue, 21 Aug 2001 18:09:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> <3B82D083.C836C8E9@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : <> > > Currently i need hints about core generators for the register set. > > i don't know precisely how to handle the partial writes and the speed > > i can get. > Typically register bank could be seen as multiported SRAM memory. So > it's hard for me to understand why you need 5 flags to write back the > registers. When you write back a none SIMD 8 bit result does the 56 > other bits remain unchange or are zeroed ? in our case, the 5 write masks are "write enable"s. so if the bit is not set, you don't update the register subfield. In fact, i think that the "lazy way" is a set of 5 banks of 63 registers, each with 2 common register write addresses but with 1 write enable bit per bank. Of course, semi-manual layout would help, but it would be too easy ... > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 21 18:09:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3c-0007uq-01 for ; Tue, 21 Aug 2001 22:23:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:28 +0200 (CEST) Received: (qmail 6326 invoked by uid 0); 21 Aug 2001 16:10:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 21 Aug 2001 16:10:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03849 for ; Tue, 21 Aug 2001 12:10:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:09:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA03415 for f-cpu-list; Tue, 21 Aug 2001 12:09:52 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA03412 for ; Tue, 21 Aug 2001 12:09:51 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG9o630837 for ; Tue, 21 Aug 2001 12:09:51 -0400 Received: from f-cpu.org (nas4-117.ras.club-internet.fr [195.36.203.117]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA11546 for ; Tue, 21 Aug 2001 18:07:46 +0200 (MET DST) Message-ID: <3B8287C1.CE72D09@f-cpu.org> Date: Tue, 21 Aug 2001 18:09:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <3B821958.A0104694@f-cpu.org> <3B82CF3D.65DDB4A2@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : <> > > If you add a new opcode which says that we don't use PC but r3 > > (it's fairly straight-forward), we're done. no curious scheduling, > > nothing to change, the necessary HW doesn't change and we must simply > > update the manual and the instruction encoders/decoders. > > Seems ok to me. But why don't we map the PC inside the register map ? wow, i should sleep and i'm dreaming awake, or i am reading something strange here ? I see no reason to map the PC in the register set. I see no use, and if you want it, just use loopentry or loadaddr. There is one case, however, where mapping the PC in the visible registers is more or less necessary, it is with my prefetch-queue-based architecture, which has to juggle with several simultaneous instruction fetches, but it is very, very far fetched. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 21 15:26:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZI3a-0007uq-00 for ; Tue, 21 Aug 2001 22:23:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 21 Aug 2001 22:23:26 +0200 (CEST) Received: (qmail 2413 invoked by uid 0); 21 Aug 2001 16:06:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 21 Aug 2001 16:06:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03236 for ; Tue, 21 Aug 2001 12:06:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 21 Aug 2001 16:05:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA01838 for f-cpu-list; Tue, 21 Aug 2001 12:05:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA01762 for ; Tue, 21 Aug 2001 12:05:15 -0400 Received: from tribble.stud.uni-hannover.de (root@a043.home.uni-hannover.de [130.75.232.43]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7LG5C630701 for ; Tue, 21 Aug 2001 12:05:13 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00653; Tue, 21 Aug 2001 15:26:48 +0200 Message-ID: <20010821152647.20372@thrai.stud.uni-hannover.de> Date: Tue, 21 Aug 2001 15:26:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] m4 won. References: <3B8058CB.5ADEF33C@f-cpu.org> <20010820073907.20382@thrai.stud.uni-hannover.de> <3B818215.5720F8B4@f-cpu.org> <20010821004020.29391@thrai.stud.uni-hannover.de> <3B821961.44DD6394@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B821961.44DD6394@f-cpu.org>; from Yann Guidon on Tue, Aug 21, 2001 at 10:18:41AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 21, 2001 at 10:18:41AM +0200, Yann Guidon wrote: [...] > > > > Update for what, the instruction encoder? > > > yes, or for whatever you have/want. > > > since you sent me a "preliminary" package, i believe > > > that a new version exists. > > No, the code is still the same. If there's nothing wrong with it, > > I can put it into CVS. Somehere below f-cpu/compiler, I suppose? > in a separate directory of f-cpu/compiler, i don't know yet. > if you have not touched your files, i'll try to integrate them > in my next bundle. Ok. We can extract it later and make it a separate module. But there are still some things to do, e.g. the opcode assignment needs to be redone (I assigned them in no particular order; we definitely need to renumber them if we want fast+easy instruction decoding inside the CPU). > > > > BTW: I created the first F-CPU object files yesterday :) > > > and what does it make/compute ? :-) > > Nothing... the source just contains every instruction variant we've > > defined so far, plus the 79 asm directives I implemented (don't worry, > > there are some aliases on the list). The only thing that's still > > missing is the relocation table. > wow. Minor update: the relocation table is no longer missing :) > but if you can assemble, maybe you can disassemble ? Not with the same program. My encoder only gives you a one-way ticket; there's no way to reverse the name -> code translation. But it shouldn't be hard to write a disassembler module, too. > and maybe even integrate it in the past attempt at a simulator ? A full-blown simulator should contain a disassembler and a symbolic debugger anyway :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 22 18:37:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZeeZ-0004Vd-01 for ; Wed, 22 Aug 2001 22:31:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:07 +0200 (CEST) Received: (qmail 23837 invoked by uid 0); 22 Aug 2001 10:28:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 22 Aug 2001 10:28:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA29581 for ; Wed, 22 Aug 2001 06:28:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 10:27:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA29341 for f-cpu-list; Wed, 22 Aug 2001 06:27:57 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA29338 for ; Wed, 22 Aug 2001 06:27:56 -0400 Received: from localhost.localdomain (nas24-137.vlt.club-internet.fr [195.36.223.137]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MARs616139 for ; Wed, 22 Aug 2001 06:27:55 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 91C941620 for ; Wed, 22 Aug 2001 12:37:25 -0400 (EDT) Message-ID: <3B83DFC5.169ECE6F@ifrance.com> Date: Wed, 22 Aug 2001 12:37:25 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: [f-cpu] vanilla vhdl: "=?iso-8859-1?Q?g=E4=E4=C4hhh?= !" References: <3B8239FA.94702F60@f-cpu.org> <20010821153917.18399@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Aug 21, 2001 at 12:37:46PM +0200, Yann Guidon wrote: > > > now i have understood why i can't use vanilla vhdl : > > it uses an outdated libc.so version and i can't install > > an older one on my computer(s). > > Why not? Put libc.so.5 and ld-linux.so.1 into /lib, run ldconfig, and > you're basically done. > > Alternatively, you can use vv87 instead of va87 and vs87 (it is > statically linked and should work on your system, too). Have you some exemple how to run it ? nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 22 18:40:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeea-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:08 +0200 (CEST) Received: (qmail 27717 invoked by uid 0); 22 Aug 2001 10:31:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 22 Aug 2001 10:31:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA29870 for ; Wed, 22 Aug 2001 06:31:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 10:30:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA29627 for f-cpu-list; Wed, 22 Aug 2001 06:30:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA29624 for ; Wed, 22 Aug 2001 06:30:57 -0400 Received: from localhost.localdomain (nas24-137.vlt.club-internet.fr [195.36.223.137]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MAUt616171 for ; Wed, 22 Aug 2001 06:30:56 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BCE991620 for ; Wed, 22 Aug 2001 12:40:27 -0400 (EDT) Message-ID: <3B83E07B.47752752@ifrance.com> Date: Wed, 22 Aug 2001 12:40:27 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> <3B82D083.C836C8E9@ifrance.com> <3B8287BE.598D1D75@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Yann Guidon a écrit : > <> > > > Currently i need hints about core generators for the register set. > > > i don't know precisely how to handle the partial writes and the speed > > > i can get. > > Typically register bank could be seen as multiported SRAM memory. So > > it's hard for me to understand why you need 5 flags to write back the > > registers. When you write back a none SIMD 8 bit result does the 56 > > other bits remain unchange or are zeroed ? > > in our case, the 5 write masks are "write enable"s. so if the bit > is not set, you don't update the register subfield. In fact, i think > that the "lazy way" is a set of 5 banks of 63 registers, each with > 2 common register write addresses but with 1 write enable bit per bank. > Of course, semi-manual layout would help, but it would be too easy ... > 5 banks ??? I beleive that conventionnal 8*8 bits (=64 bits) SRAM would be enought (8 banks with 64 registers of 8 bits). You need to decode the 5 lines to set the 8 enable line. nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 22 16:56:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeec-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:10 +0200 (CEST) Received: (qmail 11532 invoked by uid 0); 22 Aug 2001 14:57:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 22 Aug 2001 14:57:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA13761 for ; Wed, 22 Aug 2001 10:57:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 14:56:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA13191 for f-cpu-list; Wed, 22 Aug 2001 10:56:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA13188 for ; Wed, 22 Aug 2001 10:56:57 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MEuu620504 for ; Wed, 22 Aug 2001 10:56:56 -0400 Received: from f-cpu.org (nas1-188.ras.club-internet.fr [195.36.192.188]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA03223 for ; Wed, 22 Aug 2001 16:56:53 +0200 (MET DST) Message-ID: <3B83C831.CF904A5C@f-cpu.org> Date: Wed, 22 Aug 2001 16:56:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <3B821958.A0104694@f-cpu.org> <20010821171118.02508@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Aug 21, 2001 at 10:18:32AM +0200, Yann Guidon wrote: > [...] > > my personal point of view is to simply add a new "flavour" of the > > loadaddr instruction, which doesn't use the PC, that's all. > *nod* > > > The current form of LOADADDR looks like this : (from the manual) > > > > LOAD a relative ADDRess to a register > > loadaddr r2, r1 > > loadaddrd r2, r1 > > r1 = PC + 4 + r2, check the result in the D/I TLB and eventually prefetch the data. > > > > If you add a new opcode which says that we don't use PC but r3 > > (it's fairly straight-forward), we're done. no curious scheduling, > > nothing to change, the necessary HW doesn't change and we must simply > > update the manual and the instruction encoders/decoders. > > What about this: > loadaddrb r3, r2, r1 # r1 = r2 + r3 (code address) > loadaddrbd r3, r2, r1 # r1 = r2 + r3 (data address) > loadaddrbi simm8, r2, r1 # r1 = r2 + simm8 (code address) > loadaddrbid simm8, r2, r1 # r1 = r2 + simm8 (data address) my first remark is : several opcodes are too much verbose and lengthy. some of my propositions are : "move" -> "cp" (it's very explicit for linuxers :-D) "loadaddr" -> "lai", "lad" i can see 3 forms : one with PC, one with a register, and one with imm8. the BISON syntax is not complex then. > (`-b' means `based (on register r2)'). Unfortunately, the encoding has > to be different (3 operands instead of 2), so there's not enough room > for a 16-bit immediate operand (the maximum is 32-8-2*6-1 = 11 bits). > Otherwise, the original `loadaddr' instruction could be made a special > case of this one (e.g. when r2=0, use PC+4 instead). i have the feeling (beware !) that we can attempt to do an exception. i presume that this instruction will be used more often than i thought, depending on the compiler quality etc... we can maybe try to make an "extended" form with (r1+1) as a destination. opcode : 8 bits I/D flag : 1 bit sign : 1 imm16 : 16 src/dest+1 : 6 bits total : 32 bits. it's tight but it's worth. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 22 16:56:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeed-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:11 +0200 (CEST) Received: (qmail 22956 invoked by uid 0); 22 Aug 2001 14:57:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 22 Aug 2001 14:57:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA13905 for ; Wed, 22 Aug 2001 10:57:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 14:57:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA13259 for f-cpu-list; Wed, 22 Aug 2001 10:57:02 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA13242 for ; Wed, 22 Aug 2001 10:57:01 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MEv0620511 for ; Wed, 22 Aug 2001 10:57:01 -0400 Received: from f-cpu.org (nas1-188.ras.club-internet.fr [195.36.192.188]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA16380 for ; Wed, 22 Aug 2001 16:54:55 +0200 (MET DST) Message-ID: <3B83C834.63E7D076@f-cpu.org> Date: Wed, 22 Aug 2001 16:56:52 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> <3B82D4B9.89A618EA@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Paul Marques Mota a écrit : > > On Tue, Aug 21, 2001 at 01:51:59AM +0200, Michael Riepe wrote: > > > On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: > > > [...] > I have eard a lot about cvs but i didn't really know about it. Somebody > could write something to resume all the "thing" that is used by the > project (cvs, savannah, fcpu.org,...). I'm a little lost. we need a good 'full-time' webmaster. The problem is that i don't know where to find one. it would be too easy otherwise. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 22 16:56:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeee-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:12 +0200 (CEST) Received: (qmail 14987 invoked by uid 0); 22 Aug 2001 14:57:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 22 Aug 2001 14:57:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA13952 for ; Wed, 22 Aug 2001 10:57:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 14:57:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA13322 for f-cpu-list; Wed, 22 Aug 2001 10:57:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA13268 for ; Wed, 22 Aug 2001 10:57:03 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MEv2620517 for ; Wed, 22 Aug 2001 10:57:02 -0400 Received: from f-cpu.org (nas1-188.ras.club-internet.fr [195.36.192.188]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA16395 for ; Wed, 22 Aug 2001 16:54:58 +0200 (MET DST) Message-ID: <3B83C837.F059B6A3@f-cpu.org> Date: Wed, 22 Aug 2001 16:56:55 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> <3B82D083.C836C8E9@ifrance.com> <3B8287BE.598D1D75@f-cpu.org> <3B83E07B.47752752@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > Yann Guidon a écrit : > > <> > > > > Currently i need hints about core generators for the register set. > > > > i don't know precisely how to handle the partial writes and the speed > > > > i can get. > > > Typically register bank could be seen as multiported SRAM memory. So > > > it's hard for me to understand why you need 5 flags to write back the > > > registers. When you write back a none SIMD 8 bit result does the 56 > > > other bits remain unchange or are zeroed ? > > > > in our case, the 5 write masks are "write enable"s. so if the bit > > is not set, you don't update the register subfield. In fact, i think > > that the "lazy way" is a set of 5 banks of 63 registers, each with > > 2 common register write addresses but with 1 write enable bit per bank. > > Of course, semi-manual layout would help, but it would be too easy ... > > 5 banks ??? > I beleive that conventionnal 8*8 bits (=64 bits) SRAM would be enought > (8 banks with 64 registers of 8 bits). > You need to decode the 5 lines to set the 8 enable line. >from the user point of view, there are 2 banks of 8 bit and 3 banks of 16 bits. at our level, it is not difficult to mimic a 16-bit bank with 2x8-bit banks. Now my problem is : how well does this synthesises ? how do you write this is VHDL ? Can we use a macro generator ? > nicO > > > nicO > > WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 23 00:36:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeeg-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:14 +0200 (CEST) Received: (qmail 7760 invoked by uid 0); 22 Aug 2001 16:27:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 22 Aug 2001 16:27:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA24236 for ; Wed, 22 Aug 2001 12:27:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 16:27:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA24015 for f-cpu-list; Wed, 22 Aug 2001 12:27:11 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA24012 for ; Wed, 22 Aug 2001 12:27:10 -0400 Received: from localhost.localdomain (nas25-142.vlt.club-internet.fr [195.36.224.142]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MGR8623009 for ; Wed, 22 Aug 2001 12:27:08 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 7BF9E1620 for ; Wed, 22 Aug 2001 18:36:40 -0400 (EDT) Message-ID: <3B8433F8.4F681666@ifrance.com> Date: Wed, 22 Aug 2001 18:36:40 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <20010817182920.05704@thrai.stud.uni-hannover.de> <01081909552501.00301@maveric> <3B801246.E4DA91A6@ifrance.com> <20010820020833.14296@thrai.stud.uni-hannover.de> <3B818211.DEC0AD60@f-cpu.org> <20010821004325.16303@thrai.stud.uni-hannover.de> <3B821965.C8C3CCC9@f-cpu.org> <3B82D083.C836C8E9@ifrance.com> <3B8287BE.598D1D75@f-cpu.org> <3B83E07B.47752752@ifrance.com> <3B83C837.F059B6A3@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Yann Guidon a écrit : > > > nicO wrote: > > > > Yann Guidon a écrit : > > > <> > > > > > Currently i need hints about core generators for the register set. > > > > > i don't know precisely how to handle the partial writes and the speed > > > > > i can get. > > > > Typically register bank could be seen as multiported SRAM memory. So > > > > it's hard for me to understand why you need 5 flags to write back the > > > > registers. When you write back a none SIMD 8 bit result does the 56 > > > > other bits remain unchange or are zeroed ? > > > > > > in our case, the 5 write masks are "write enable"s. so if the bit > > > is not set, you don't update the register subfield. In fact, i think > > > that the "lazy way" is a set of 5 banks of 63 registers, each with > > > 2 common register write addresses but with 1 write enable bit per bank. > > > Of course, semi-manual layout would help, but it would be too easy ... > > > > 5 banks ??? > > I beleive that conventionnal 8*8 bits (=64 bits) SRAM would be enought > > (8 banks with 64 registers of 8 bits). > > You need to decode the 5 lines to set the 8 enable line. > > from the user point of view, there are 2 banks of 8 bit and 3 banks of 16 bits. > at our level, it is not difficult to mimic a 16-bit bank with 2x8-bit banks. > Now my problem is : how well does this synthesises ? how do you write this is VHDL ? > Can we use a macro generator ? > Take the description of the ff from Michael use a stdlogic_vector for the signal. You just decode wich register are concerne before. I think you should look to the code of the leon (see www.gaisler.com), there are greate number of examples inside. > > nicO > > > > nicO > > > WHYGEE > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 23 00:38:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeeg-0004Vd-01 for ; Wed, 22 Aug 2001 22:31:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:14 +0200 (CEST) Received: (qmail 10609 invoked by uid 0); 22 Aug 2001 16:29:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 22 Aug 2001 16:29:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA24478 for ; Wed, 22 Aug 2001 12:29:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 16:29:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA24258 for f-cpu-list; Wed, 22 Aug 2001 12:29:18 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA24255 for ; Wed, 22 Aug 2001 12:29:17 -0400 Received: from localhost.localdomain (nas25-142.vlt.club-internet.fr [195.36.224.142]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MGTG623060 for ; Wed, 22 Aug 2001 12:29:16 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C77A21620 for ; Wed, 22 Aug 2001 18:38:48 -0400 (EDT) Message-ID: <3B843478.2D946EE2@ifrance.com> Date: Wed, 22 Aug 2001 18:38:48 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> <3B82D4B9.89A618EA@ifrance.com> <3B83C834.63E7D076@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Paul Marques Mota a écrit : > > > On Tue, Aug 21, 2001 at 01:51:59AM +0200, Michael Riepe wrote: > > > > On Tue, Aug 21, 2001 at 01:36:07AM -0400, nicO wrote: > > > > [...] > > I have eard a lot about cvs but i didn't really know about it. Somebody > > could write something to resume all the "thing" that is used by the > > project (cvs, savannah, fcpu.org,...). I'm a little lost. > > we need a good 'full-time' webmaster. > The problem is that i don't know where to find one. > it would be too easy otherwise. > You miss the point. I even don't what are actualy working for the fcpu on the net. nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 22 14:58:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeeh-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:15 +0200 (CEST) Received: (qmail 18328 invoked by uid 0); 22 Aug 2001 16:48:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 22 Aug 2001 16:48:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA27092 for ; Wed, 22 Aug 2001 12:48:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 16:48:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA26840 for f-cpu-list; Wed, 22 Aug 2001 12:48:16 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA26837 for ; Wed, 22 Aug 2001 12:48:14 -0400 Received: from tribble.stud.uni-hannover.de (root@a242.home.uni-hannover.de [130.75.232.242]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MGm8623449 for ; Wed, 22 Aug 2001 12:48:08 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00530; Wed, 22 Aug 2001 14:58:29 +0200 Message-ID: <20010822145829.63200@thrai.stud.uni-hannover.de> Date: Wed, 22 Aug 2001 14:58:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Re: =?iso-8859-1?Q?=5Bf-cpu=5D_Re=3A_=5Bf-cpu=5D_vanilla_vhdl=3A_=22g=E4=E4?= =?iso-8859-1?Q?=C4hhh_!=22?= References: <3B8239FA.94702F60@f-cpu.org> <20010821153917.18399@thrai.stud.uni-hannover.de> <3B83DFC5.169ECE6F@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B83DFC5.169ECE6F@ifrance.com>; from nicO on Wed, Aug 22, 2001 at 12:37:25PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 22, 2001 at 12:37:25PM -0400, nicO wrote: [...] > > Alternatively, you can use vv87 instead of va87 and vs87 (it is > > statically linked and should work on your system, too). > > Have you some exemple how to run it ? Just start "vv87" and type `help'. It's a bit like dc_shell -- first, you have to analyze the sources, then you load a design and start simulating. For the ASU EU, the command sequence is: analyze ../f-cpu_config.vhdl analyze generic_adder.vhdl analyze iadd.vhdl analyze iatest5.vhdl analyze iatest6.vhdl analyze asu.vhdl simulate work.iadd_test run simulate work.iadd_pipetest run quit If va87 and vs87 work, you can analyse files (va87) and simulate designs (vs87) from the unix command line (vs87 puts you in the command interpreter where you have to type "run", as in vv87). For all three commands, the option "-x" enables VHDL'93 extensions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lsalzman+@andrew.cmu.edu Wed Aug 22 19:37:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeej-0004Vd-00 for ; Wed, 22 Aug 2001 22:31:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:17 +0200 (CEST) Received: (qmail 9832 invoked by uid 0); 22 Aug 2001 17:39:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 22 Aug 2001 17:39:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA31054 for ; Wed, 22 Aug 2001 13:39:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 17:38:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA30809 for f-cpu-list; Wed, 22 Aug 2001 13:38:38 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA30806 for ; Wed, 22 Aug 2001 13:38:37 -0400 Received: from po1.andrew.cmu.edu (PO1.ANDREW.CMU.EDU [128.2.10.101]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MHcb624564 for ; Wed, 22 Aug 2001 13:38:37 -0400 Received: (from postman@localhost) by po1.andrew.cmu.edu (8.9.3/8.9.3) id NAA25428 for f-cpu@seul.org; Wed, 22 Aug 2001 13:38:34 -0400 (EDT) Received: via switchmail; Wed, 22 Aug 2001 13:38:34 -0400 (EDT) Message-ID: Received: from unix15.andrew.cmu.edu via qmail ID ; Wed, 22 Aug 2001 13:37:13 -0400 (EDT) Date: Wed, 22 Aug 2001 13:37:13 -0400 (EDT) From: Lee Randolph Salzman To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: >i have the feeling (beware !) that we can attempt to do an exception. >i presume that this instruction will be used more often than i thought, >depending on the compiler quality etc... > >we can maybe try to make an "extended" form with (r1+1) as a destination. >opcode : 8 bits >I/D flag : 1 bit >sign : 1 >imm16 : 16 >src/dest+1 : 6 bits > total : 32 bits. > >it's tight but it's worth. > >WHYGEE I think this may end up being messy. Consider that two places where this instruction will be heavily used: 1) loading data at an immediate offset from a stack/frame pointer 2) loading data at an immediate offset from a global storage pointer In both cases, these pointers are fixed registers, therefor the destination of said load instruction would also end up being fixed. So then you'd have to carefully lay out your ABI so that fixed registers are atleast a distance of 2 away from eachother. Moreover, since it is a fixed register if you wanted to load another address in parallel with it (you're not going to use the data quite immediately or else you fuck with the pipeline/scheduling/prefetch), you'd have to move the calculated address out of that fixed register to make room for another. What I suggest is, as controversial as this may be or not, just to overwrite the source register (r1) with the calculated address. This can be quite handy in a number of situations such as iterating over an array (where you're constantly incrementing a pointer to load/store elements), and also gives the processor good hints about what you're doing with an array as a side-effect. This does mean you have to move the base register to a scratch register before you can use the instruction, but consider that you can also reuse previously calculated addresses to minimize this cost signifigantly: i.e. if we need to calculate SP + 16 for some snippet of code, and later need to calculate SP + 48, so long as the result of the SP + 16 calculation is still live, we can just calculate the result + 32 with the special form of the loadaddr instruction all the same. Lee Salzman ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 22 20:01:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zeej-0004Vd-01 for ; Wed, 22 Aug 2001 22:31:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 22 Aug 2001 22:31:17 +0200 (CEST) Received: (qmail 17517 invoked by uid 0); 22 Aug 2001 18:02:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 22 Aug 2001 18:02:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA01123 for ; Wed, 22 Aug 2001 14:02:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 18:02:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA00885 for f-cpu-list; Wed, 22 Aug 2001 14:02:39 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA00882 for ; Wed, 22 Aug 2001 14:02:38 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MI2b625251 for ; Wed, 22 Aug 2001 14:02:37 -0400 Received: from f-cpu.org (nas4-79.ras.club-internet.fr [195.36.203.79]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA04881 for ; Wed, 22 Aug 2001 20:02:35 +0200 (MET DST) Message-ID: <3B83F393.4A101C4A@f-cpu.org> Date: Wed, 22 Aug 2001 20:01:55 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: [f-cpu] Re: [f-cpu] vanilla vhdl: " =?iso-8859-1?Q?g=E4=E4=C4hhh?= !" References: <3B8239FA.94702F60@f-cpu.org> <20010821153917.18399@thrai.stud.uni-hannover.de> <3B83DFC5.169ECE6F@ifrance.com> <20010822145829.63200@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Wed, Aug 22, 2001 at 12:37:25PM -0400, nicO wrote: > [...] > > > Alternatively, you can use vv87 instead of va87 and vs87 (it is > > > statically linked and should work on your system, too). > > > > Have you some exemple how to run it ? > > Just start "vv87" and type `help'. It's a bit like dc_shell -- first, > you have to analyze the sources, then you load a design and start > simulating. For the ASU EU, the command sequence is: > > analyze ../f-cpu_config.vhdl > analyze generic_adder.vhdl > analyze iadd.vhdl > analyze iatest5.vhdl > analyze iatest6.vhdl > analyze asu.vhdl > simulate work.iadd_test > run > simulate work.iadd_pipetest > run > quit > > If va87 and vs87 work, you can analyse files (va87) and simulate designs > (vs87) from the unix command line (vs87 puts you in the command > interpreter where you have to type "run", as in vv87). For all three > commands, the option "-x" enables VHDL'93 extensions. > Michael "Tired" Riepe thanks, i'll try that and i'll update my files. give me one day or two. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 22 19:29:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigP-0003gL-01 for ; Thu, 23 Aug 2001 02:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:17 +0200 (CEST) Received: (qmail 11850 invoked by uid 0); 22 Aug 2001 23:23:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 22 Aug 2001 23:23:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA25511 for ; Wed, 22 Aug 2001 19:23:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 23:22:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA25261 for f-cpu-list; Wed, 22 Aug 2001 19:22:42 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA25258 for ; Wed, 22 Aug 2001 19:22:41 -0400 Received: from tribble.stud.uni-hannover.de (root@a067.home.uni-hannover.de [130.75.232.67]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MNMa600386 for ; Wed, 22 Aug 2001 19:22:37 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA03972; Wed, 22 Aug 2001 19:29:25 +0200 Message-ID: <20010822192924.10475@thrai.stud.uni-hannover.de> Date: Wed, 22 Aug 2001 19:29:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble References: <3B7F1FE3.59021CA3@lvdi.net> <20010819150816.00917@thrai.stud.uni-hannover.de> <3B81E48B.1B9C5D1E@ifrance.com> <3B821958.A0104694@f-cpu.org> <20010821171118.02508@thrai.stud.uni-hannover.de> <3B83C831.CF904A5C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B83C831.CF904A5C@f-cpu.org>; from Yann Guidon on Wed, Aug 22, 2001 at 04:56:49PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 22, 2001 at 04:56:49PM +0200, Yann Guidon wrote: [...] > > What about this: > > loadaddrb r3, r2, r1 # r1 = r2 + r3 (code address) > > loadaddrbd r3, r2, r1 # r1 = r2 + r3 (data address) > > loadaddrbi simm8, r2, r1 # r1 = r2 + simm8 (code address) > > loadaddrbid simm8, r2, r1 # r1 = r2 + simm8 (data address) > > my first remark is : several opcodes are too much verbose and lengthy. > some of my propositions are : "move" -> "cp" (it's very explicit for linuxers :-D) > "loadaddr" -> "lai", "lad" No, please don't do that. This naming style is obsolete since the early 80's ;) And it reminds me too much of the 6502 and 8080 instruction sets. The names we currently have are IMHO perfect -- not too long, but easy to remember. > i can see 3 forms : one with PC, one with a register, and one with imm8. > the BISON syntax is not complex then. Not quite... there are four forms: reg = PC + 4 + simm (the current loadaddri) reg = PC + 4 + reg (the current loadaddr) reg = basereg + simm (new) reg = basereg + reg (new) > > (`-b' means `based (on register r2)'). Unfortunately, the encoding has > > to be different (3 operands instead of 2), so there's not enough room > > for a 16-bit immediate operand (the maximum is 32-8-2*6-1 = 11 bits). > > Otherwise, the original `loadaddr' instruction could be made a special > > case of this one (e.g. when r2=0, use PC+4 instead). > > i have the feeling (beware !) that we can attempt to do an exception. > i presume that this instruction will be used more often than i thought, > depending on the compiler quality etc... > > we can maybe try to make an "extended" form with (r1+1) as a destination. > opcode : 8 bits > I/D flag : 1 bit > sign : 1 > imm16 : 16 > src/dest+1 : 6 bits > total : 32 bits. > > it's tight but it's worth. I don't like this "flip the lsb of the register number" trick at all, and certainly not in *this* case. It complicates the register assignment procedure in compilers, and may introduce register pressure (64 registers may look much at the first glance, but it isn't much, believe me). I'd rather live with a short immediate for loadaddrb. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 23 01:27:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigQ-0003gL-00 for ; Thu, 23 Aug 2001 02:49:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:18 +0200 (CEST) Received: (qmail 7188 invoked by uid 0); 22 Aug 2001 23:28:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx22) with SMTP; 22 Aug 2001 23:28:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA25856 for ; Wed, 22 Aug 2001 19:28:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 23:28:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA25608 for f-cpu-list; Wed, 22 Aug 2001 19:28:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA25605 for ; Wed, 22 Aug 2001 19:28:21 -0400 Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MNSK600582 for ; Wed, 22 Aug 2001 19:28:21 -0400 Received: from f-cpu.org (nas2-175.aub.club-internet.fr [195.36.133.175]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA24818 for ; Thu, 23 Aug 2001 01:28:14 +0200 (MET DST) Message-ID: <3B843FE1.9A429733@f-cpu.org> Date: Thu, 23 Aug 2001 01:27:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] ongoing work Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N - i have debugged the m4 files. they now perform the constant evaluations, which removes the need to transform the "|" into "or". - i figured out how to use vv87 but i have not been as far as doing scripts (yet). - i have started to write a VHDL-HOWTO.fcpu file, which contains some starter hints for the newcomers. I would like this to become a well-featured file, so if you are a HOWTO-writing professional, please help me and make it into a fine-looking text :-) - ROP2 is still under work. have a look anyway but i doubt it will compile. i have put the latest "snapshot" at f-cpu.seul.org, in the incoming directory. http://f-cpu.seul.org/new/snapshot_yg_8_23_2001.tgz Michael, i thnk that you prefer this name, no ? :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 23 01:39:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigR-0003gL-00 for ; Thu, 23 Aug 2001 02:49:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:19 +0200 (CEST) Received: (qmail 4518 invoked by uid 0); 22 Aug 2001 23:39:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 22 Aug 2001 23:39:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA27330 for ; Wed, 22 Aug 2001 19:39:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 23:39:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA27114 for f-cpu-list; Wed, 22 Aug 2001 19:39:28 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA27111 for ; Wed, 22 Aug 2001 19:39:28 -0400 Received: from tribble.stud.uni-hannover.de (michael@a067.home.uni-hannover.de [130.75.232.67]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MNdP600920 for ; Wed, 22 Aug 2001 19:39:25 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05008; Thu, 23 Aug 2001 01:39:29 +0200 Message-ID: <20010823013929.65475@thrai.stud.uni-hannover.de> Date: Thu, 23 Aug 2001 01:39:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] ongoing work References: <3B843FE1.9A429733@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B843FE1.9A429733@f-cpu.org>; from Yann Guidon on Thu, Aug 23, 2001 at 01:27:29AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 23, 2001 at 01:27:29AM +0200, Yann Guidon wrote: > - i have debugged the m4 files. they now perform > the constant evaluations, which removes the need > to transform the "|" into "or". Beware! m4 may be limited to 32-bit signed integers or something like that. > - i figured out how to use vv87 but i have not been > as far as doing scripts (yet). Put the commands in a file and type "do filename" :) > - i have started to write a VHDL-HOWTO.fcpu file, > which contains some starter hints for the newcomers. > I would like this to become a well-featured file, > so if you are a HOWTO-writing professional, please > help me and make it into a fine-looking text :-) I may be a writing professional, but... ;) > - ROP2 is still under work. have a look anyway > but i doubt it will compile. > > i have put the latest "snapshot" at f-cpu.seul.org, > in the incoming directory. > http://f-cpu.seul.org/new/snapshot_yg_8_23_2001.tgz > Michael, i thnk that you prefer this name, no ? :-) Guess what? I *love* it :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 23 01:44:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigR-0003gL-01 for ; Thu, 23 Aug 2001 02:49:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:19 +0200 (CEST) Received: (qmail 11555 invoked by uid 0); 22 Aug 2001 23:45:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Aug 2001 23:45:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA27619 for ; Wed, 22 Aug 2001 19:45:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 23:44:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA27391 for f-cpu-list; Wed, 22 Aug 2001 19:44:57 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA27388 for ; Wed, 22 Aug 2001 19:44:55 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MNit601044 for ; Wed, 22 Aug 2001 19:44:55 -0400 Received: from f-cpu.org (nas2-175.aub.club-internet.fr [195.36.133.175]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA03289 for ; Thu, 23 Aug 2001 01:44:53 +0200 (MET DST) Message-ID: <3B8443C7.CA7C6C18@f-cpu.org> Date: Thu, 23 Aug 2001 01:44:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ongoing work References: <3B843FE1.9A429733@f-cpu.org> <20010823013929.65475@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Aug 23, 2001 at 01:27:29AM +0200, Yann Guidon wrote: > > - i have debugged the m4 files. they now perform > > the constant evaluations, which removes the need > > to transform the "|" into "or". > Beware! m4 may be limited to 32-bit signed integers or something > like that. i'll try to remember this. currently it is not a problem. if larger stuff is needed, it will be handled as character strings and computations will be avoided. > > - i figured out how to use vv87 but i have not been > > as far as doing scripts (yet). > Put the commands in a file and type "do filename" :) but is there a command line argument for vv87 ? it ignores them, AFAIK. > > - i have started to write a VHDL-HOWTO.fcpu file, > > which contains some starter hints for the newcomers. > > I would like this to become a well-featured file, > > so if you are a HOWTO-writing professional, please > > help me and make it into a fine-looking text :-) > > I may be a writing professional, but... ;) i was more thinking about philippe, but please give your advices about this file. it's only a first try. look at it under f-cpu/vhdl/VHDL-HOWTO.f-cpu. > > - ROP2 is still under work. have a look anyway > > but i doubt it will compile. > > > > i have put the latest "snapshot" at f-cpu.seul.org, > > in the incoming directory. > > http://f-cpu.seul.org/new/snapshot_yg_8_23_2001.tgz > > Michael, i thnk that you prefer this name, no ? :-) > Guess what? I *love* it :) maybe, but now : fetch it ! ;-) i know you're dying to read its contents ;-P have fun, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: i will maybe visit Graham Seaman in London next week. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 23 01:55:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigS-0003gL-00 for ; Thu, 23 Aug 2001 02:49:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:20 +0200 (CEST) Received: (qmail 15752 invoked by uid 0); 22 Aug 2001 23:55:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 22 Aug 2001 23:55:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA28917 for ; Wed, 22 Aug 2001 19:55:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 22 Aug 2001 23:55:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA28702 for f-cpu-list; Wed, 22 Aug 2001 19:55:31 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA28699 for ; Wed, 22 Aug 2001 19:55:30 -0400 Received: from tribble.stud.uni-hannover.de (michael@a067.home.uni-hannover.de [130.75.232.67]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7MNtR601212 for ; Wed, 22 Aug 2001 19:55:27 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05056; Thu, 23 Aug 2001 01:55:32 +0200 Message-ID: <20010823015531.37954@thrai.stud.uni-hannover.de> Date: Thu, 23 Aug 2001 01:55:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (m) Re: [f-cpu] More Instruction Set Trouble References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Lee Randolph Salzman on Wed, Aug 22, 2001 at 01:37:13PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 22, 2001 at 01:37:13PM -0400, Lee Randolph Salzman wrote: [...] > I think this may end up being messy. Consider that two places > where this instruction will be heavily used: > > 1) loading data at an immediate offset from a stack/frame pointer > 2) loading data at an immediate offset from a global storage pointer loading/storing data at an immediate offset from any pointer > In both cases, these pointers are fixed registers, therefor the > destination of said load instruction would also end up being fixed. So > then you'd have to carefully lay out your ABI so that fixed registers > are atleast a distance of 2 away from eachother. Moreover, since it is > a fixed register if you wanted to load another address in parallel with > it (you're not going to use the data quite immediately or else you fuck > with the pipeline/scheduling/prefetch), you'd have to move the calculated > address out of that fixed register to make room for another. Yep, that's bad. That's what I meant with "register pressure". > What I suggest is, as controversial as this may be or not, just > to overwrite the source register (r1) with the calculated address. This > can be quite handy in a number of situations such as iterating over an > array (where you're constantly incrementing a pointer to load/store > elements), and also gives the processor good hints about what you're > doing with an array as a side-effect. This does mean you have to move > the base register to a scratch register before you can use the > instruction, but consider that you can also reuse previously calculated > addresses to minimize this cost signifigantly: i.e. if we need > to calculate SP + 16 for some snippet of code, and later need > to calculate SP + 48, so long as the result of the SP + 16 calculation > is still live, we can just calculate the result + 32 with the > special form of the loadaddr instruction all the same. That's bad as well. Moving the base pointer before calculating the address is even worse in terms of address calculation delay because the move will need lots of extra cycles -- the sequence causes a read-after-write dependency. This is also true for the `move-away' case, but there we can move the register later (maybe in parallel with the memory access). Instructions that overwrite their own operands are evil in general. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 23 02:16:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ZigT-0003gL-00 for ; Thu, 23 Aug 2001 02:49:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 02:49:21 +0200 (CEST) Received: (qmail 22059 invoked by uid 0); 23 Aug 2001 00:17:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 23 Aug 2001 00:17:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA31062 for ; Wed, 22 Aug 2001 20:17:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 23 Aug 2001 00:16:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA30664 for f-cpu-list; Wed, 22 Aug 2001 20:16:48 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA30646 for ; Wed, 22 Aug 2001 20:16:47 -0400 Received: from tribble.stud.uni-hannover.de (michael@a067.home.uni-hannover.de [130.75.232.67]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7N0Gi601624 for ; Wed, 22 Aug 2001 20:16:44 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA05163; Thu, 23 Aug 2001 02:16:41 +0200 Message-ID: <20010823021640.14462@thrai.stud.uni-hannover.de> Date: Thu, 23 Aug 2001 02:16:40 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] ongoing work References: <3B843FE1.9A429733@f-cpu.org> <20010823013929.65475@thrai.stud.uni-hannover.de> <3B8443C7.CA7C6C18@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B8443C7.CA7C6C18@f-cpu.org>; from Yann Guidon on Thu, Aug 23, 2001 at 01:44:07AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 23, 2001 at 01:44:07AM +0200, Yann Guidon wrote: [...] > > > - i figured out how to use vv87 but i have not been > > > as far as doing scripts (yet). > > Put the commands in a file and type "do filename" :) > but is there a command line argument for vv87 ? > it ignores them, AFAIK. I didn't test that, but you can try to read the script from standard input, e.g. `vv87 < script'. > > > - i have started to write a VHDL-HOWTO.fcpu file, > > > which contains some starter hints for the newcomers. > > > I would like this to become a well-featured file, > > > so if you are a HOWTO-writing professional, please > > > help me and make it into a fine-looking text :-) > > > > I may be a writing professional, but... ;) > i was more thinking about philippe, but please > give your advices about this file. it's only a first try. > look at it under f-cpu/vhdl/VHDL-HOWTO.f-cpu. Yep... tomorrow. > > > i have put the latest "snapshot" at f-cpu.seul.org, > > > in the incoming directory. > > > http://f-cpu.seul.org/new/snapshot_yg_8_23_2001.tgz > > > Michael, i thnk that you prefer this name, no ? :-) > > Guess what? I *love* it :) > maybe, but now : fetch it ! ;-) > i know you're dying to read its contents ;-P I already did -- *before* I replied to your last mail :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 23 03:34:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15Zoei-0002lc-00 for ; Thu, 23 Aug 2001 09:11:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 23 Aug 2001 09:11:56 +0200 (CEST) Received: (qmail 29471 invoked by uid 0); 23 Aug 2001 01:35:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 23 Aug 2001 01:35:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA08612 for ; Wed, 22 Aug 2001 21:35:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 23 Aug 2001 01:35:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA08395 for f-cpu-list; Wed, 22 Aug 2001 21:35:15 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA08392 for ; Wed, 22 Aug 2001 21:35:14 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7N1ZC603164 for ; Wed, 22 Aug 2001 21:35:13 -0400 Received: from f-cpu.org (nas3-20.ras.club-internet.fr [195.36.203.20]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA02191 for ; Thu, 23 Aug 2001 03:33:02 +0200 (MET DST) Message-ID: <3B845D9B.5ADEF3EB@f-cpu.org> Date: Thu, 23 Aug 2001 03:34:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ongoing work References: <3B843FE1.9A429733@f-cpu.org> <20010823013929.65475@thrai.stud.uni-hannover.de> <3B8443C7.CA7C6C18@f-cpu.org> <20010823021640.14462@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Aug 23, 2001 at 01:44:07AM +0200, Yann Guidon wrote: > [...] > > > > - i figured out how to use vv87 but i have not been > > > > as far as doing scripts (yet). > > > Put the commands in a file and type "do filename" :) > > but is there a command line argument for vv87 ? > > it ignores them, AFAIK. > I didn't test that, but you can try to read the script from standard > input, e.g. `vv87 < script'. /me is dumb, i did not think about this trick :-D > > > > - i have started to write a VHDL-HOWTO.fcpu file, > > > > which contains some starter hints for the newcomers. > > > > I would like this to become a well-featured file, > > > > so if you are a HOWTO-writing professional, please > > > > help me and make it into a fine-looking text :-) > > > > > > I may be a writing professional, but... ;) > > i was more thinking about philippe, but please > > give your advices about this file. it's only a first try. > > look at it under f-cpu/vhdl/VHDL-HOWTO.f-cpu. > Yep... tomorrow. sleep well and have nice dreams ;-) > > > > i have put the latest "snapshot" at f-cpu.seul.org, > > > > in the incoming directory. > > > > http://f-cpu.seul.org/new/snapshot_yg_8_23_2001.tgz > > > > Michael, i thnk that you prefer this name, no ? :-) > > > Guess what? I *love* it :) > > maybe, but now : fetch it ! ;-) > > i know you're dying to read its contents ;-P > I already did -- *before* I replied to your last mail :) gnark gniark :-) btw, please help me ASAP with the file i sent you :-/ > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From reynes@irit.fr Fri Aug 24 16:45:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15aQws-0006YR-00 for ; Sat, 25 Aug 2001 02:05:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 25 Aug 2001 02:05:14 +0200 (CEST) Received: (qmail 3459 invoked by uid 0); 24 Aug 2001 14:46:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 24 Aug 2001 14:46:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA15044 for ; Fri, 24 Aug 2001 10:46:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 24 Aug 2001 14:45:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA14417 for f-cpu-list; Fri, 24 Aug 2001 10:45:30 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA14408 for ; Fri, 24 Aug 2001 10:45:29 -0400 Received: from irit.irit.fr (irit.irit.fr [141.115.4.5]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7OEjS604017 for ; Fri, 24 Aug 2001 10:45:28 -0400 Received: from irit.fr (ares [141.115.8.74]) by irit.irit.fr (8.9.3/8.9.3) with ESMTP id QAA22160 for ; Fri, 24 Aug 2001 16:45:52 +0200 (MET DST) Message-ID: <3B866885.F1221364@irit.fr> Date: Fri, 24 Aug 2001 16:45:25 +0200 From: REYNES Philippe Organization: APARA X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> <3B823AB6.2FBD969A@irit.fr> <20010821164228.36087@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > [...] > > First, I have to present me a bit. > > I'm a french computer science student, I study processor architecture. > > I try to understand this project, where you are and where you go. > Bonjour Philippe, nice to meet you. thanks > > My main problem was to gather all f-cpu information. It isn't very easy. > > My second problem was, who works on what ? > > who makes the architecture, the design, ..... !!! who takes decision ??? > > It's the reason of my proposition to use savannah and his task manager. > > I think that this project need a bit of managing. > I suggest a meta-manager who manages the management :) why not, perhaps written with prolog :) > > > > What we really need is *one* central site which has basically > > > > everything, *one* mailing list, and no WWW clicky-clacky GUI, please > > > You mean seul.org? > > > > > That means that all the web sites should be moved, the cvs repository > > > should be moved either and the french and german mailing-list should be > > > closed. It also means that there might be a single point of failure > > > which frightened whygee (that's not surprising after the yahoo > > > problems) > > > > well, yes and not !!! > > I'd rather not move the CVS now that we have it. It was supposed to be > on seul.org, but it's fine the way it is. We can mirror it somewhere > to avoid the SPOF, though (read-only). the CVS is on gaos, isn't it ? > The english mailing list on seul is fine, too. There's no need to move > it again. The french and german lists need not be closed, but I ask > people again and again to move important discussions to the english list. > I feel a little bit lost here, sometimes. yes, I don't speak often in this ML because my english is worse than anything. > There should be a single, central website that is easy to find (probably > www.f-cpu.org) and has links to everything -- the CVS, the mailing list(s), > websites of national organizations (like the "F-CPU Verein" in Germany) > and so on. Any other websites we may have should be redirected to this > main entry point, to ease maintenance. I really don't care on which > host and in which country the CVS repository and the mailing lists are > located, as long as there is a single "portal" site that leads people > everywhere they want. yes, I agree with you. One portal that leads to other part is nice. But how many people have the passwd of www.f-cpu.org ? > [...] > > As I said up, I think that we (this project) need to managed more. > > Some people works on everything, some people works on nothing. > > Is that a problem? I'm pretty glad that at least somebody works on > something ;) I think that the problem is that a newcomer dont know who works on what. > > I have worked on another project (v2os) and it was clear that many > > people > > want (or need) to be led. > > Sorry, but I don't like being `led'. The very day this project is > going to become `led' by somebody (group or individual), it's also going > to lose one of its contributors -- me. ok, you don't want to be led but are you sure that it's the same for everybody ? > [...] > > As I have proposed it on the french ML (forwarded by yg), I propose: > > - to split this big project on sub-project > > * architecture (and simulator) > > * design > > * compiler > > * system (port linux to f-cpu processor) > > I guess I have my fingers in 3 of 4 pies already -- and the only reason > why I don't have them in all of them is that the Linux port didn't start > yet ;) congratulation, you're one the most active people of this project. I know that a project people like you. > > to anwser yg's question, manuel are part of each sub-project. > > architecture group make the architecture manual, and so on ... > > > > - to put a leader (manager) to each sub-project. This isn't a boss but a > > manager. His job would be to gather information (who works on what, last > > manual, ..). > > And what is (s)he going to do with that information? Gather them and give it to everybody. So if someone wants to work on a file (or on a suject), he can know if someone already work on. for example a who's who and a task list. > > I said it again, It woun't be a boss, we are in an open source project > > but > > wasting time isn't nice and necessary. > > For example: > > architecture leader -> yg > > design leader -> mikael > > compiler leader -> nic0 > > system leader -> dunno > > What we really need is a `speaker', a PR agent -- somebody who watches > the project (but does not participate in any of these sub-projects), > reports the latest-and-greatest facts and details on the website, talks to > the outer world (companies, organizations, the press), answers questions > and so on. well, Isn't it a bit soon to talk to companies. As far as I know this project haven't got anything that work. > This is something I definitely don't want to do myself. It's not > the sexiest job either. But perhaps it helps cleaning up the mess -- > and it gives people like me a chance to do what we're really good at, > without being disturbed or interrupted too much. Find me somebody who > keeps people off my back, and I can work wonders (like writing an > almost complete assembler in less than a week ;). Ok, I think that I have understood what you think. > [...] > > PS: sorry for my english, I'm a little frenchy :( > It's much better than my french, believe me ;) But english is most used that french :( phil ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 24 21:23:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15aQxJ-0006YR-00 for ; Sat, 25 Aug 2001 02:05:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 25 Aug 2001 02:05:41 +0200 (CEST) Received: (qmail 5631 invoked by uid 0); 24 Aug 2001 22:24:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 24 Aug 2001 22:24:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA10499 for ; Fri, 24 Aug 2001 18:24:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 24 Aug 2001 22:24:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA10260 for f-cpu-list; Fri, 24 Aug 2001 18:24:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA10257 for ; Fri, 24 Aug 2001 18:24:21 -0400 Received: from tribble.stud.uni-hannover.de (root@a139.home.uni-hannover.de [130.75.232.139]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7OMOG614377 for ; Fri, 24 Aug 2001 18:24:17 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00707; Fri, 24 Aug 2001 21:23:07 +0200 Message-ID: <20010824212307.58689@thrai.stud.uni-hannover.de> Date: Fri, 24 Aug 2001 21:23:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: [ff] f-cpu et savannah] References: <3B81820D.14C21895@f-cpu.org> <20010821002807.26313@thrai.stud.uni-hannover.de> <3B81F346.88BE4D60@ifrance.com> <20010821015159.00560@thrai.stud.uni-hannover.de> <20010821103610.A22097@opium.april.org> <3B823AB6.2FBD969A@irit.fr> <20010821164228.36087@thrai.stud.uni-hannover.de> <3B866885.F1221364@irit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B866885.F1221364@irit.fr>; from REYNES Philippe on Fri, Aug 24, 2001 at 04:45:25PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 24, 2001 at 04:45:25PM +0200, REYNES Philippe wrote: [...] > the CVS is on gaos, isn't it ? Yes. > > The english mailing list on seul is fine, too. There's no need to move > > it again. The french and german lists need not be closed, but I ask > > people again and again to move important discussions to the english list. > > I feel a little bit lost here, sometimes. > > yes, I don't speak often in this ML because my english is worse > than anything. Good enough, IMHO. [...] > I think that the problem is that a newcomer dont know who works on what. Sometimes I don't know that myself :) A "Beginners' Guide to the F-CPU Project" would certainly be nice, but it will need permanent maintenance by somebody, otherwise it's useless. [...] > ok, you don't want to be led but are you sure that it's the same for > everybody ? I'm not sure whether you really mean `leading', or perhaps `guiding'. I usually want no guidance either (I consider figuring things out myself part of the fun), but in general, being guided is a good thing, as well as guiding somebody yourself. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 26 03:24:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15az6E-0007Hl-00 for ; Sun, 26 Aug 2001 14:33:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 26 Aug 2001 14:33:10 +0200 (CEST) Received: (qmail 32422 invoked by uid 0); 26 Aug 2001 01:25:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 26 Aug 2001 01:25:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id VAA12566 for ; Sat, 25 Aug 2001 21:25:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 26 Aug 2001 01:24:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id VAA12269 for f-cpu-list; Sat, 25 Aug 2001 21:24:46 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id VAA12266 for ; Sat, 25 Aug 2001 21:24:45 -0400 Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7Q1Oi631511 for ; Sat, 25 Aug 2001 21:24:44 -0400 Received: from f-cpu.org (nas4-91.ras.club-internet.fr [195.36.203.91]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA14709 for ; Sun, 26 Aug 2001 03:22:30 +0200 (MET DST) Message-ID: <3B884FB4.A1F897AE@f-cpu.org> Date: Sun, 26 Aug 2001 03:24:04 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] trip to london Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, so here it is : i go to London soon, >from 29th to sept. 12th. i have no ticket to see Tori Amos on stage but getting out of France is invaluable sometimes... And the best part is that Graham will kindly host me. We will maybe have the occasion to resume the discussions we had in Dortmund, if he finds a few minutes out of work. i'll be doing C and VHDL in my corner, i'll probably come back with some enhancements. But i'll be less "responsibe" during two weeks. i presume that you can survive, no ? :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 27 02:33:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bLVD-0001Xu-01 for ; Mon, 27 Aug 2001 14:28:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 27 Aug 2001 14:28:27 +0200 (CEST) Received: (qmail 1458 invoked by uid 0); 27 Aug 2001 00:34:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 27 Aug 2001 00:34:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA22152 for ; Sun, 26 Aug 2001 20:34:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 00:34:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA21915 for f-cpu-list; Sun, 26 Aug 2001 20:34:09 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA21912 for ; Sun, 26 Aug 2001 20:34:02 -0400 Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7R0Y1620972 for ; Sun, 26 Aug 2001 20:34:02 -0400 Received: from f-cpu.org (nas2-226.ras.club-internet.fr [195.36.192.226]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA25065; Mon, 27 Aug 2001 02:33:58 +0200 (MET DST) Message-ID: <3B899550.32F9206A@f-cpu.org> Date: Mon, 27 Aug 2001 02:33:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: patrick.van-hove@cec.eu.int Subject: [f-cpu] http://www.cordis.lu/ist/ka4/mel/index.htm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, concerning the page at http://www.cordis.lu/ist/ka4/mel/index.htm, i would like to know how to follow and possibly contribute to this part of IST. I am part of a volunteer work/design team that is designing an industry-class microprocessor standard in an "open" environment and we seek help and collaborations with other similar teams for system integration, design and manufacturing. Can you help me, and if not, can you tell me where to ask ? regards, YG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 11:13:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bLVH-0001Xu-00 for ; Mon, 27 Aug 2001 14:28:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 27 Aug 2001 14:28:31 +0200 (CEST) Received: (qmail 25247 invoked by uid 0); 27 Aug 2001 08:41:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 27 Aug 2001 08:41:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA30199 for ; Mon, 27 Aug 2001 04:41:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 08:39:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA29929 for f-cpu-list; Mon, 27 Aug 2001 04:39:28 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA29926 for ; Mon, 27 Aug 2001 04:39:26 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7R8dP624956 for ; Mon, 27 Aug 2001 04:39:25 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bISl-000821-00 for f-cpu@seul.org; Mon, 27 Aug 2001 11:13:43 +0200 Date: Mon, 27 Aug 2001 11:13:43 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic In-Reply-To: <3B7D4446.14BFB692@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 17 Aug 2001, Yann Guidon wrote: > Juergen Goeritz wrote: > > On Fri, 17 Aug 2001, Glenn Alexander wrote: > <> > > > I agree: untill we start launching space-probes, 64 bit FP seems fine. But > > > the option for more will be there when we do build the F-rocket (FR-1). > > > > Error is human - maybe we live in an evolution based > > simulation for optimization? Who knows how our senses > > are really working? :-) > > > > Hmh, don't think I want to live in this universe A instead. > > But the thought of a far distant space ship is enticing... > > "Anywhere outa this f*k*ng world", huh ? Not at all! Conquering new frontiers fits much better. :-) > but please don't leave before the first F-CPU prototype is built ;-) Yes, it's one of the required base technologies though ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Aug 27 15:15:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bN2m-0003n2-00 for ; Mon, 27 Aug 2001 16:07:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 27 Aug 2001 16:07:12 +0200 (CEST) Received: (qmail 24942 invoked by uid 0); 27 Aug 2001 13:31:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 27 Aug 2001 13:31:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA09079 for ; Mon, 27 Aug 2001 09:31:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 13:31:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA08576 for f-cpu-list; Mon, 27 Aug 2001 09:31:04 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA08569 for ; Mon, 27 Aug 2001 09:31:02 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RDV1627822 for ; Mon, 27 Aug 2001 09:31:01 -0400 Received: from art1.none.de (dialin133.pg4-nt.berlin.nikoma.de [213.54.67.133]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f7RDV3311223 for ; Mon, 27 Aug 2001 15:31:03 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin133.pg4-nt.berlin.nikoma.de [213.54.67.133] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15bMFa-0003LA-00 for ; Mon, 27 Aug 2001 15:16:22 +0200 Date: Mon, 27 Aug 2001 15:15:22 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] the wrong way (of floating point and so on) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am back from my vacation and I was slayed from your discussions... :) I think we should forget to trace the way to include floating point now. Why? IMHO there are too many tasks to do, which are more important than thinking about floating point units. First, we should have a working "simple" F-CPU, not more nor less. Second, a FPU was declared as an optionally unit, Floating-point-operations are rare and should be emulated in an intelligent way (software) to use the full power of F-CPU's SIMD-capabilities Last, If we are better in designing units and we have a real (!) F-CPU we can easily extend the core with an existing FPU, I think. In my mind I do not realisize how you will design the scoreboard and the shifting unit in a possible way or I misunderstood anything. In my opinion we need in near future a working CPU to get and hold a good developer-basis, and to make tests in reality not in emulations only. Because we can compose a set of FPGAs (Altera and Co.) to load and emulate the CPU, we should go in this direction, to make FC0 to that what it is, "a proof of concept". I am in right? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ikftClxplZklbgERAgdvAJoC3UjRJA3x5kQWasuAOfdlImYl5QCglqeA eonfo1h0LO8kbgOK+pOuLVc= =eljA -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Aug 27 14:40:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bN2m-0003n2-01 for ; Mon, 27 Aug 2001 16:07:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 27 Aug 2001 16:07:12 +0200 (CEST) Received: (qmail 25954 invoked by uid 0); 27 Aug 2001 13:31:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 27 Aug 2001 13:31:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA09106 for ; Mon, 27 Aug 2001 09:31:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 13:31:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA08586 for f-cpu-list; Mon, 27 Aug 2001 09:31:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA08575 for ; Mon, 27 Aug 2001 09:31:04 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RDV3627827 for ; Mon, 27 Aug 2001 09:31:03 -0400 Received: from art1.none.de (dialin133.pg4-nt.berlin.nikoma.de [213.54.67.133]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f7RDV0311219 for ; Mon, 27 Aug 2001 15:31:01 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin133.pg4-nt.berlin.nikoma.de [213.54.67.133] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15bLih-0003H0-00 for ; Mon, 27 Aug 2001 14:42:23 +0200 Date: Mon, 27 Aug 2001 14:40:55 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA In-Reply-To: <20010816011059.37312@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Thu, 16 Aug 2001, Michael Riepe wrote: > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. I disagree. Gunzip + Tar are available for all possible platforms (unices, amiga, atari, c64, winxx-PC, beos, Mac, etc.) Windows-User can use winzip and co. gzip/gunzip are also available in sourcecode So far as good. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ij/bClxplZklbgERAjPTAJ46y4Qn+EBm7WpQVE0b6rWg1B9o/gCZAYXa HwAF9M8D3gMnahX7dDZnMiQ= =ivcm -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 16:34:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpp-0004r2-00 for ; Tue, 28 Aug 2001 00:26:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:21 +0200 (CEST) Received: (qmail 13735 invoked by uid 0); 27 Aug 2001 14:01:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 27 Aug 2001 14:01:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA15885 for ; Mon, 27 Aug 2001 10:01:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 14:00:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA15643 for f-cpu-list; Mon, 27 Aug 2001 10:00:47 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA15638 for ; Mon, 27 Aug 2001 10:00:45 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RE0h628531 for ; Mon, 27 Aug 2001 10:00:43 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bNTf-000092-00 for f-cpu@seul.org; Mon, 27 Aug 2001 16:34:59 +0200 Date: Mon, 27 Aug 2001 16:34:59 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, my opinion is that the core parts of f-cpu should be verified. The parts outside the core like memory controller, interrupt unit a.s.o. could be 'delayed'. The best way to get started is to use some FPGA to test the concept in hardware. But to remind everybody of Intel x86 success. One part was that it came with the x87 floating coproc that speeded up arithmetics quite a bit. Motorola had no real floating point unit fitting to 68K. It may be a bit carried to far to claim that this was the only point for Intel success but it is at least one of them. If you don't go for floating point right from the start you will have targeted the f-cpu to embedded applications. I don't know if that can be 'healed' later but it's much easier to strip a unit to make some shrinked version than to extend something. The direct competition right now is the LEON Sparc which comes with the nearly free Meiko FPU for low quantities (SUN SDLC license required). I don't see the Alpha architecture as THE direct competition at all - sorry WHYGEE. LEON is only 32 bit though but a lot of software for it is already available as open source. And it could be used as a powerfull IO processor... Why not implement f-cpu as a coprocessor into the LEON IO processor. With the LEON coprocessor opcodes it could be easy to implement a debug interface for f-cpu testing with download and single stepping... Does anybody have access to a synthesis tool for some prototyping? Does anybody have access to a FPGA board for testing? JG On Mon, 27 Aug 2001, Andreas Romeyke wrote: > Hash: SHA1 > > Hello, > > I am back from my vacation and I was slayed from your discussions... :) > > I think we should forget to trace the way to include floating point now. > Why? > IMHO there are too many tasks to do, which are more important than > thinking about floating point units. First, we should have a working > "simple" F-CPU, not more nor less. > Second, a FPU was declared as an optionally unit, > Floating-point-operations are rare and should be emulated in an > intelligent way (software) to use the full power of F-CPU's > SIMD-capabilities > Last, If we are better in designing units and we have a real (!) F-CPU we > can easily extend the core with an existing FPU, I think. > > In my mind I do not realisize how you will design the scoreboard and the > shifting unit in a possible way or I misunderstood anything. > > In my opinion we need in near future a working CPU to get and hold a good > developer-basis, and to make tests in reality not in emulations only. > > Because we can compose a set of FPGAs (Altera and Co.) to load and emulate > the CPU, we should go in this direction, to make FC0 to that what it is, > "a proof of concept". > > I am in right? > > Bye Andreas ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 16:39:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpr-0004r2-00 for ; Tue, 28 Aug 2001 00:26:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:23 +0200 (CEST) Received: (qmail 9048 invoked by uid 0); 27 Aug 2001 14:50:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 27 Aug 2001 14:50:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA19121 for ; Mon, 27 Aug 2001 10:50:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 14:50:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA18901 for f-cpu-list; Mon, 27 Aug 2001 10:50:11 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA18898 for ; Mon, 27 Aug 2001 10:50:09 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7REo8629746 for ; Mon, 27 Aug 2001 10:50:08 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA14182 for ; Mon, 27 Aug 2001 08:49:57 -0600 (MDT) Message-ID: <3B8A5B8F.34284EE1@jetnet.ab.ca> Date: Mon, 27 Aug 2001 08:39:11 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (of floating point and so on) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I think we should forget to trace the way to include floating point now. > Why? > IMHO there are too many tasks to do, which are more important than > thinking about floating point units. First, we should have a working > "simple" F-CPU, not more nor less. > Second, a FPU was declared as an optionally unit, > Floating-point-operations are rare and should be emulated in an > intelligent way (software) to use the full power of F-CPU's > SIMD-capabilities > Last, If we are better in designing units and we have a real (!) F-CPU we > can easily extend the core with an existing FPU, I think. > > In my mind I do not realisize how you will design the scoreboard and the > shifting unit in a possible way or I misunderstood anything. > > In my opinion we need in near future a working CPU to get and hold a good > developer-basis, and to make tests in reality not in emulations only. > > Because we can compose a set of FPGAs (Altera and Co.) to load and emulate > the CPU, we should go in this direction, to make FC0 to that what it is, > "a proof of concept". > > I am in right? I suspect it better to design for the floating point unit now but leave it out when on the first revision of the cpu design. Otherwise you could have a large problem trying to "patch" the floating point unit to the cpu. Say for example you wanted a few extra bits used just by floating registers you may use 67 bits for all the registers?This could have a large impact if you all ready designed 64 bit registers. Ben. PS. I suspect using low cost (slow) Altera parts you will have a clock rate about 8-16 Mhz. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 16:49:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpr-0004r2-01 for ; Tue, 28 Aug 2001 00:26:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:23 +0200 (CEST) Received: (qmail 11429 invoked by uid 0); 27 Aug 2001 15:01:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 27 Aug 2001 15:01:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA19804 for ; Mon, 27 Aug 2001 11:01:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:00:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA19393 for f-cpu-list; Mon, 27 Aug 2001 11:00:43 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA19390 for ; Mon, 27 Aug 2001 11:00:41 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RF0e630012 for ; Mon, 27 Aug 2001 11:00:40 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA14436 for ; Mon, 27 Aug 2001 09:00:38 -0600 (MDT) Message-ID: <3B8A5E10.E17AE3FC@jetnet.ab.ca> Date: Mon, 27 Aug 2001 08:49:52 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Andreas Romeyke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > On Thu, 16 Aug 2001, Michael Riepe wrote: > > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. > > I disagree. Gunzip + Tar are available for all possible platforms (unices, > amiga, atari, c64, winxx-PC, beos, Mac, etc.) Windows-User can use winzip > and > co. Yes but I want the old archive programs too - zip/unzip lha arc so when I show the great grand kids what kind of computers I ran as a kid I can load a dusty old cd-rom labeled CP/M 2003 and unarchive the programs found there. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 17:00:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUps-0004r2-00 for ; Tue, 28 Aug 2001 00:26:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:24 +0200 (CEST) Received: (qmail 22099 invoked by uid 0); 27 Aug 2001 15:12:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 27 Aug 2001 15:12:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA21087 for ; Mon, 27 Aug 2001 11:12:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:11:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA20866 for f-cpu-list; Mon, 27 Aug 2001 11:11:39 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA20863 for ; Mon, 27 Aug 2001 11:11:34 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFBX630329 for ; Mon, 27 Aug 2001 11:11:33 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA14629 for ; Mon, 27 Aug 2001 09:11:31 -0600 (MDT) Message-ID: <3B8A609D.A72BB31@jetnet.ab.ca> Date: Mon, 27 Aug 2001 09:00:45 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Not at all! Conquering new frontiers fits much better. :-) > > > but please don't leave before the first F-CPU prototype is built ;-) > > Yes, it's one of the required base technologies though ;-) I say use my CPU designs instead.The F-cpu is too complex for what really could be future computer design in deep space - plastic transistors. In deep space you are living in a closed habit and almost all products have to be recycled and/or repaired. Conventional cpu design is too complex and poisonous and wasteful and not productive for small population bases. Earth 4 billion people - Mars - 20 000 . Plastic computers would be IBM PC size and speed for the critical systems. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 17:52:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUps-0004r2-01 for ; Tue, 28 Aug 2001 00:26:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:24 +0200 (CEST) Received: (qmail 671 invoked by uid 0); 27 Aug 2001 15:18:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 27 Aug 2001 15:18:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA21438 for ; Mon, 27 Aug 2001 11:18:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:18:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA21195 for f-cpu-list; Mon, 27 Aug 2001 11:18:24 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA21192 for ; Mon, 27 Aug 2001 11:18:21 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFIK630473 for ; Mon, 27 Aug 2001 11:18:20 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bOh4-0000NF-00 for f-cpu@seul.org; Mon, 27 Aug 2001 17:52:54 +0200 Date: Mon, 27 Aug 2001 17:52:54 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA In-Reply-To: <3B8A5E10.E17AE3FC@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Ben Franchuk wrote: > Andreas Romeyke wrote: > > On Thu, 16 Aug 2001, Michael Riepe wrote: > > > > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. > > > > I disagree. Gunzip + Tar are available for all possible platforms (unices, > > amiga, atari, c64, winxx-PC, beos, Mac, etc.) Windows-User can use winzip > > and > > co. > Yes but I want the old archive programs too - zip/unzip lha arc > so when I show the great grand kids what kind of computers I ran > as a kid I can load a dusty old cd-rom labeled CP/M 2003 and > unarchive the programs found there. > Ben. But they all run under Linux! if you really want to live that 'dusty old CD' stuff you have to get the source code anyway because it's the only way! It's available though... with Linux :-) By the way, some bank companies relying on Windows programs may run into these problems already today. Imagine you used some Windows 95 stuff and some M**osoft tools to compute your results and you have to backup and be able to re-compute everything of the last 10 years... That means to have about 5 generations of PCs working - ... ... - quite a museum though. :-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 27 23:30:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpt-0004r2-00 for ; Tue, 28 Aug 2001 00:26:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:25 +0200 (CEST) Received: (qmail 25566 invoked by uid 0); 27 Aug 2001 15:21:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 27 Aug 2001 15:21:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA21772 for ; Mon, 27 Aug 2001 11:21:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:20:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA21522 for f-cpu-list; Mon, 27 Aug 2001 11:20:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA21519 for ; Mon, 27 Aug 2001 11:20:57 -0400 Received: from localhost.localdomain (nas6-64.vlt.club-internet.fr [194.158.108.64]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFKt630561 for ; Mon, 27 Aug 2001 11:20:56 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2D2C616CD for ; Mon, 27 Aug 2001 17:30:47 -0400 (EDT) Message-ID: <3B8ABC06.3D8A95E4@ifrance.com> Date: Mon, 27 Aug 2001 17:30:46 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N An other trick could be used : It's to implement the full set of instruction but when a none present instruction is decoded a specific execption is raised and a specific code is runned. This code could be a part of the fcpu and not from a compiler. So you keep the complete compatibility. That's what has been proposed a long time ago. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 17:56:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpt-0004r2-01 for ; Tue, 28 Aug 2001 00:26:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:25 +0200 (CEST) Received: (qmail 7145 invoked by uid 0); 27 Aug 2001 15:22:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 27 Aug 2001 15:22:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA22054 for ; Mon, 27 Aug 2001 11:22:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:21:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA21803 for f-cpu-list; Mon, 27 Aug 2001 11:21:44 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA21800 for ; Mon, 27 Aug 2001 11:21:43 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFLg630594 for ; Mon, 27 Aug 2001 11:21:42 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bOkK-0000P2-00 for f-cpu@seul.org; Mon, 27 Aug 2001 17:56:16 +0200 Date: Mon, 27 Aug 2001 17:56:16 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic In-Reply-To: <3B8A609D.A72BB31@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Ben Franchuk wrote: > Juergen Goeritz wrote: > > Not at all! Conquering new frontiers fits much better. :-) > > > > > but please don't leave before the first F-CPU prototype is built ;-) > > > > Yes, it's one of the required base technologies though ;-) > > I say use my CPU designs instead.The F-cpu is too complex for > what really could be future computer design in deep space - > plastic transistors. In deep space you are living in a closed > habit and almost all products have to be recycled and/or > repaired. Conventional cpu design is too complex and poisonous > and wasteful and not productive for small population bases. > Earth 4 billion people - > Mars - 20 000 . Plastic computers would be IBM PC size and speed > for the critical systems. How do you built plastics without oil? And some loss of performance with every recycling step? :-( ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 18:01:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpu-0004r2-00 for ; Tue, 28 Aug 2001 00:26:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:26 +0200 (CEST) Received: (qmail 22697 invoked by uid 0); 27 Aug 2001 15:26:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Aug 2001 15:26:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA22371 for ; Mon, 27 Aug 2001 11:26:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:26:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA22133 for f-cpu-list; Mon, 27 Aug 2001 11:26:30 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA22130 for ; Mon, 27 Aug 2001 11:26:28 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFQR630707 for ; Mon, 27 Aug 2001 11:26:28 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bOow-0000QR-00 for f-cpu@seul.org; Mon, 27 Aug 2001 18:01:02 +0200 Date: Mon, 27 Aug 2001 18:01:02 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP In-Reply-To: <3B8ABC06.3D8A95E4@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, nicO wrote: > An other trick could be used : It's to implement the full set of > instruction but when a none present instruction is decoded a specific > execption is raised and a specific code is runned. This code could be a > part of the fcpu and not from a compiler. So you keep the complete > compatibility. That's what has been proposed a long time ago. Ain't that some kind of microcode then? -> That means it has to be coded -> developed It's better to just have the exception but no built-in code. Emulation per software (e.g. it's also implemented in LEON this way) is preferable BUT introduces additional overhead. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 17:19:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpu-0004r2-01 for ; Tue, 28 Aug 2001 00:26:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:26 +0200 (CEST) Received: (qmail 27600 invoked by uid 0); 27 Aug 2001 15:30:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 27 Aug 2001 15:30:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA22684 for ; Mon, 27 Aug 2001 11:30:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:30:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA22441 for f-cpu-list; Mon, 27 Aug 2001 11:30:05 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA22438 for ; Mon, 27 Aug 2001 11:30:03 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFU2630790 for ; Mon, 27 Aug 2001 11:30:02 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA14980 for ; Mon, 27 Aug 2001 09:30:00 -0600 (MDT) Message-ID: <3B8A64F2.68463015@jetnet.ab.ca> Date: Mon, 27 Aug 2001 09:19:14 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > But they all run under Linux! if you really want to live > that 'dusty old CD' stuff you have to get the source code > anyway because it's the only way! No a lot of the old computers the SOURCE has been lost and running a emulator for a machine that last ran in the 1980's ... 1970's ... 1960's and even the 1950's is the only way for people to have a feel for what the old machines where like. > By the way, some bank companies relying on Windows programs > may run into these problems already today. Imagine you used > some Windows 95 stuff and some M**osoft tools to compute your > results and you have to backup and be able to re-compute > everything of the last 10 years... The mind set of windows - Thy shall not BACK UP or COPY thy system BUT forever BUY new systems from the unholy GOD MicroSoft. > That means to have about 5 generations of PCs working - ... > ... - quite a museum though. :-) Ben. PS. Linux you can back up off a boot floppy. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 17:27:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpv-0004r2-00 for ; Tue, 28 Aug 2001 00:26:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:27 +0200 (CEST) Received: (qmail 30947 invoked by uid 0); 27 Aug 2001 15:39:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 27 Aug 2001 15:39:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA23162 for ; Mon, 27 Aug 2001 11:39:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:38:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA22808 for f-cpu-list; Mon, 27 Aug 2001 11:38:44 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA22805 for ; Mon, 27 Aug 2001 11:38:43 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFcg631075 for ; Mon, 27 Aug 2001 11:38:42 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA15202 for ; Mon, 27 Aug 2001 09:38:40 -0600 (MDT) Message-ID: <3B8A66FA.6BD25925@jetnet.ab.ca> Date: Mon, 27 Aug 2001 09:27:54 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > How do you built plastics without oil? And some > loss of performance with every recycling step? :-( Well on MARS if you can find water you take CO2 from the air. Grow icky green plants and cover over with earth. Wait a few millon years and you have oil! Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 18:16:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpv-0004r2-01 for ; Tue, 28 Aug 2001 00:26:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:28 +0200 (CEST) Received: (qmail 32490 invoked by uid 0); 27 Aug 2001 15:42:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 27 Aug 2001 15:42:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA23641 for ; Mon, 27 Aug 2001 11:42:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:42:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA23397 for f-cpu-list; Mon, 27 Aug 2001 11:42:10 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA23392 for ; Mon, 27 Aug 2001 11:42:09 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFg7631187 for ; Mon, 27 Aug 2001 11:42:08 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bP46-0000Tb-00 for f-cpu@seul.org; Mon, 27 Aug 2001 18:16:42 +0200 Date: Mon, 27 Aug 2001 18:16:42 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA In-Reply-To: <3B8A64F2.68463015@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Ben Franchuk wrote: > Juergen Goeritz wrote: > > But they all run under Linux! if you really want to live > > that 'dusty old CD' stuff you have to get the source code > > anyway because it's the only way! > > No a lot of the old computers the SOURCE has been lost and > running a emulator for a machine that last ran in the 1980's ... > 1970's ... 1960's and even the 1950's is the only way for people > to have a feel for what the old machines where like. Still got one of the 'old ones' - handcrafted Z80 CP/M machine. But I don't know of any emulator still available for these... Maybe we need some new backup tools where the required hardware functionality is described and included in the backup file? No more operating systems, just a VHDL to hardware synthesizer. Self-extracting hardware for the universal logic array PCBs of the future. Every software runs on its own dedicated hardware. Forget about PCs! :-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 27 23:58:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpw-0004r2-00 for ; Tue, 28 Aug 2001 00:26:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:28 +0200 (CEST) Received: (qmail 25835 invoked by uid 0); 27 Aug 2001 15:49:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 27 Aug 2001 15:49:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA24838 for ; Mon, 27 Aug 2001 11:49:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:48:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA24453 for f-cpu-list; Mon, 27 Aug 2001 11:48:58 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA24433 for ; Mon, 27 Aug 2001 11:48:54 -0400 Received: from localhost.localdomain (nas7-59.vlt.club-internet.fr [194.158.109.59]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFmr631357 for ; Mon, 27 Aug 2001 11:48:53 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BC48016BE for ; Mon, 27 Aug 2001 17:58:44 -0400 (EDT) Message-ID: <3B8AC294.41D067D6@ifrance.com> Date: Mon, 27 Aug 2001 17:58:44 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Mon, 27 Aug 2001, nicO wrote: > > > An other trick could be used : It's to implement the full set of > > instruction but when a none present instruction is decoded a specific > > execption is raised and a specific code is runned. This code could be a > > part of the fcpu and not from a compiler. So you keep the complete > > compatibility. That's what has been proposed a long time ago. > > Ain't that some kind of microcode then? > -> That means it has to be coded -> developed > Nono ! Nothing to do with microcode. It's normal code run like exeption handler ! > It's better to just have the exception but no built-in > code. Emulation per software (e.g. it's also implemented > in LEON this way) is preferable BUT introduces additional > overhead. Yep, and you lose compatibility (compiling for a low-end f-cpu and you're will slow down on a high-end fcpu) nicO > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Mon Aug 27 17:54:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpx-0004r2-00 for ; Tue, 28 Aug 2001 00:26:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:29 +0200 (CEST) Received: (qmail 23481 invoked by uid 0); 27 Aug 2001 15:56:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 27 Aug 2001 15:56:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA25892 for ; Mon, 27 Aug 2001 11:56:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:54:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA25370 for f-cpu-list; Mon, 27 Aug 2001 11:54:43 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA25367 for ; Mon, 27 Aug 2001 11:54:42 -0400 Received: from localhost (graham@localhost) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFsg831514 for ; Mon, 27 Aug 2001 11:54:42 -0400 Date: Mon, 27 Aug 2001 11:54:42 -0400 (EDT) From: Graham Seaman X-Sender: To: Subject: Re: [f-cpu] http://www.cordis.lu/ist/ka4/mel/index.htm In-Reply-To: <3B899550.32F9206A@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Yann Guidon wrote: > hello, > > concerning the page at http://www.cordis.lu/ist/ka4/mel/index.htm, You might have more luck with http://www.cordis.lu/ist/cpt/cpa13.htm which (depending on the meaning they attach to 'open') sounds like it has explicit encouragement for open designs, even if its not quite so close to the fcpu. For software there is actual EU money for free software development, but the deadline for this year is very close: http://www.cordis.lu/ist/ka4/tesss/impl_free.htm If you don't get a reply from the guy you mailed you could try the mailing list linked with EU funded free software development at http://eu.conecta.it/ It's software only, but at least the people on the list are into libre stuff and have some experience of the inner workings of EU bureaucracy... Good luck Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 17:47:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpx-0004r2-01 for ; Tue, 28 Aug 2001 00:26:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:29 +0200 (CEST) Received: (qmail 30083 invoked by uid 0); 27 Aug 2001 15:58:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 27 Aug 2001 15:58:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id LAA26722 for ; Mon, 27 Aug 2001 11:58:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 15:58:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id LAA26489 for f-cpu-list; Mon, 27 Aug 2001 11:58:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id LAA26484 for ; Mon, 27 Aug 2001 11:58:19 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RFwI631609 for ; Mon, 27 Aug 2001 11:58:18 -0400 Received: from jetnet.ab.ca (dialin36.jetnet.ab.ca [207.153.6.36]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA15685 for ; Mon, 27 Aug 2001 09:58:16 -0600 (MDT) Message-ID: <3B8A6B92.D05A5479@jetnet.ab.ca> Date: Mon, 27 Aug 2001 09:47:30 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Re: OFF: CP/M References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Mon, 27 Aug 2001, Ben Franchuk wrote: > > > Juergen Goeritz wrote: > > > But they all run under Linux! if you really want to live > > > that 'dusty old CD' stuff you have to get the source code > > > anyway because it's the only way! > > > > No a lot of the old computers the SOURCE has been lost and > > running a emulator for a machine that last ran in the 1980's ... > > 1970's ... 1960's and even the 1950's is the only way for people > > to have a feel for what the old machines where like. > > Still got one of the 'old ones' - handcrafted Z80 CP/M machine. > But I don't know of any emulator still available for these... Try here. http://www.cpm.z80.de/ > Maybe we need some new backup tools where the required hardware > functionality is described and included in the backup file? > No more operating systems, just a VHDL to hardware synthesizer. > Self-extracting hardware for the universal logic array PCBs > of the future. Every software runs on its own dedicated hardware. > Forget about PCs! :-) A 150 MHZ PC will run CP/M faster than a 2MHZ 8080. Why not just design the F-cpu that way - the wave of the future today. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 18:36:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpy-0004r2-00 for ; Tue, 28 Aug 2001 00:26:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:30 +0200 (CEST) Received: (qmail 15095 invoked by uid 0); 27 Aug 2001 16:02:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 27 Aug 2001 16:02:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA27494 for ; Mon, 27 Aug 2001 12:02:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 16:02:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA27161 for f-cpu-list; Mon, 27 Aug 2001 12:02:08 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA27141 for ; Mon, 27 Aug 2001 12:02:05 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RG24631751 for ; Mon, 27 Aug 2001 12:02:04 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bPNP-0000XX-00 for f-cpu@seul.org; Mon, 27 Aug 2001 18:36:39 +0200 Date: Mon, 27 Aug 2001 18:36:39 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] http://www.cordis.lu/ist/ka4/mel/index.htm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Graham Seaman wrote: > On Mon, 27 Aug 2001, Yann Guidon wrote: > > concerning the page at http://www.cordis.lu/ist/ka4/mel/index.htm, > > > You might have more luck with > http://www.cordis.lu/ist/cpt/cpa13.htm > which (depending on the meaning they attach to 'open') sounds like it > has explicit encouragement for open designs, even if its not quite so > close to the fcpu. > For software there is actual EU money for free software development, but > the deadline for this year is very close: > http://www.cordis.lu/ist/ka4/tesss/impl_free.htm > > If you don't get a reply from the guy you mailed you could try the > mailing list linked with EU funded free software development at > http://eu.conecta.it/ It's software only, but at least the people on > the list are into libre stuff and have some experience of the inner > workings of EU bureaucracy... Hi, don't want to disappoint you but there are some handicaps when looking for funding by EU tax money. The company or university or whatever must have stable setup and usually has to finance part of the work by itself. I don't know if it's possible at all to get funding money without a legal entity/company behind. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Aug 27 18:46:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUpy-0004r2-01 for ; Tue, 28 Aug 2001 00:26:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:30 +0200 (CEST) Received: (qmail 30116 invoked by uid 0); 27 Aug 2001 16:12:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 27 Aug 2001 16:12:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA29432 for ; Mon, 27 Aug 2001 12:12:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 16:12:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA29129 for f-cpu-list; Mon, 27 Aug 2001 12:12:02 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA29126 for ; Mon, 27 Aug 2001 12:12:00 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RGBx632050 for ; Mon, 27 Aug 2001 12:11:59 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bPX0-0000Yl-00 for f-cpu@seul.org; Mon, 27 Aug 2001 18:46:34 +0200 Date: Mon, 27 Aug 2001 18:46:34 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: OFF: CP/M In-Reply-To: <3B8A6B92.D05A5479@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > > But they all run under Linux! if you really want to live > > > > that 'dusty old CD' stuff you have to get the source code > > > > anyway because it's the only way! > > > > > > No a lot of the old computers the SOURCE has been lost and > > > running a emulator for a machine that last ran in the 1980's ... > > > 1970's ... 1960's and even the 1950's is the only way for people > > > to have a feel for what the old machines where like. > > > > Still got one of the 'old ones' - handcrafted Z80 CP/M machine. > > But I don't know of any emulator still available for these... > > Try here. http://www.cpm.z80.de/ > > Maybe we need some new backup tools where the required hardware > > functionality is described and included in the backup file? > > No more operating systems, just a VHDL to hardware synthesizer. > > Self-extracting hardware for the universal logic array PCBs > > of the future. Every software runs on its own dedicated hardware. > > Forget about PCs! :-) > > A 150 MHZ PC will run CP/M faster than a 2MHZ 8080. Why not just > design the F-cpu that way - the wave of the future today. But why you still want CP/M? Just because the program can't be adapted/recompiled to/for nowadays hardware. That brings us back to the open source idea... (hmh, but why do you want to recompile at all?) ... OR to a new design that is optimzed for emulation of all kind of today's microprocessors. Maybe it's really time for the motto 'give every program its own processor' like in the begining (e.g. with CP/M). That may simplify everything for the future... ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Aug 27 20:32:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bUq0-0004r2-01 for ; Tue, 28 Aug 2001 00:26:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 00:26:32 +0200 (CEST) Received: (qmail 24037 invoked by uid 0); 27 Aug 2001 18:28:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 27 Aug 2001 18:28:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA06518 for ; Mon, 27 Aug 2001 14:28:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 18:27:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA06277 for f-cpu-list; Mon, 27 Aug 2001 14:27:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA06274 for ; Mon, 27 Aug 2001 14:27:19 -0400 Received: from imf04bis.bellsouth.net (mail104.mail.bellsouth.net [205.152.58.44]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RIRI603551 for ; Mon, 27 Aug 2001 14:27:19 -0400 Received: from computer ([209.215.24.83]) by imf04bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010827182809.TGWU25031.imf04bis.bellsouth.net@computer>; Mon, 27 Aug 2001 14:28:09 -0400 Message-ID: <007301c12f26$a6653d80$5318d7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] ERIN32 Presentation Date: Mon, 27 Aug 2001 13:32:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01C12EFC.BC9C9820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0070_01C12EFC.BC9C9820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If any of you are interested in M2M design (Emulation ofmthe Honeywell = DDP-516 in my case), take a look at my Web Site: egandaonline.com What you see is the basis for my presentation at Microprocessor Forum = 2001 at San Jose California this coming October 16th from 6:00 PM to = 9:00 PM. I will distributing a 56 Page Handout to all participants. = Included is thr history of the Language of TIPS (my operating system); = an application for Hospital systems & sevewral logic diagrams of Barrel = Shifter design; and the complete design for Eight Priority Interrupts = with individual mask & a common Interrupt Enable/Disable. I firmly believe my system design will cause a STIR in the industry = because I dont use networking hardware/software and I don't require = Megabytes of programs Regards Richard E. Hartney Research Difector Erin Greene & Associates ------=_NextPart_000_0070_01C12EFC.BC9C9820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If any of you are interested in M2M = design=20 (Emulation ofmthe Honeywell DDP-516 in my case), take a look at my Web=20 Site:
 
       =20 egandaonline.com
 
What you see is the basis for my = presentation at=20 Microprocessor Forum 2001 at San Jose California this coming October = 16th from=20 6:00 PM to 9:00 PM.  I will distributing a 56 Page Handout to all=20 participants.  Included is thr history of the Language of TIPS (my=20 operating system); an application for Hospital systems & sevewral = logic=20 diagrams of Barrel Shifter design; and the complete design for Eight = Priority=20 Interrupts with individual mask & a common Interrupt=20 Enable/Disable.
 
I firmly believe my system design will = cause a STIR=20 in the industry because I dont use networking hardware/software and I = don't=20 require Megabytes of programs
 
Regards
Richard E. Hartney
Research Difector
Erin Greene &=20 Associates
------=_NextPart_000_0070_01C12EFC.BC9C9820-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 18:33:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHN-0003Pr-00 for ; Tue, 28 Aug 2001 05:11:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:05 +0200 (CEST) Received: (qmail 18686 invoked by uid 0); 27 Aug 2001 23:13:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 27 Aug 2001 23:13:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA18385 for ; Mon, 27 Aug 2001 19:13:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:13:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18144 for f-cpu-list; Mon, 27 Aug 2001 19:13:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18141 for ; Mon, 27 Aug 2001 19:13:21 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNDG609379 for ; Mon, 27 Aug 2001 19:13:17 -0400 Received: from jetnet.ab.ca (dialin46.jetnet.ab.ca [207.153.6.46]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA24721 for ; Mon, 27 Aug 2001 17:13:13 -0600 (MDT) Message-ID: <3B8A764A.BA3E0829@jetnet.ab.ca> Date: Mon, 27 Aug 2001 10:33:14 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ERIN32 Presentation References: <007301c12f26$a6653d80$5318d7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "Richard E. Hartny" wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable What brand of FPGA are you using for cpu? I suspect anti-fuse FPGA's are the only reliable ones in high reliable systems? -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 01:52:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHN-0003Pr-01 for ; Tue, 28 Aug 2001 05:11:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:05 +0200 (CEST) Received: (qmail 26009 invoked by uid 0); 27 Aug 2001 23:54:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 27 Aug 2001 23:54:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA19711 for ; Mon, 27 Aug 2001 19:54:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:53:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18773 for f-cpu-list; Mon, 27 Aug 2001 19:53:09 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18770 for ; Mon, 27 Aug 2001 19:53:08 -0400 Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNr8609760 for ; Mon, 27 Aug 2001 19:53:08 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA18983 for ; Tue, 28 Aug 2001 01:52:59 +0200 (MET DST) Message-ID: <3B8ADD35.FC6B3176@f-cpu.org> Date: Tue, 28 Aug 2001 01:52:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] http://www.cordis.lu/ist/ka4/mel/index.htm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > On Mon, 27 Aug 2001, Graham Seaman wrote: > > On Mon, 27 Aug 2001, Yann Guidon wrote: > > > concerning the page at http://www.cordis.lu/ist/ka4/mel/index.htm, > > > > > > You might have more luck with > > http://www.cordis.lu/ist/cpt/cpa13.htm > > which (depending on the meaning they attach to 'open') sounds like it > > has explicit encouragement for open designs, even if its not quite so > > close to the fcpu. on other sides of the site, there are stuffs about microelectronics and all the likes. browse and search. > > For software there is actual EU money for free software development, but > > the deadline for this year is very close: > > http://www.cordis.lu/ist/ka4/tesss/impl_free.htm we are too few to handle all these papers, but we can still hope ... > > If you don't get a reply from the guy you mailed you could try the > > mailing list linked with EU funded free software development at > > http://eu.conecta.it/ It's software only, but at least the people on > > the list are into libre stuff and have some experience of the inner > > workings of EU bureaucracy... let's try ! there's nothing to loose (except time and patience). after all we work for the long term, so the bureaucracy's delays might not be such a problem for us. F-CPU is 3 years old, no ? :-) > Hi, > > don't want to disappoint you but there are some handicaps > when looking for funding by EU tax money. The company or > university or whatever must have stable setup and usually > has to finance part of the work by itself. I don't know > if it's possible at all to get funding money without a > legal entity/company behind. at least, we can create legal frames. What happened to the idea of a Verein ? Would it be possible to meet everybody in Berlin (during 18C3) to create it ? In France, Nicole wants to resurface the idea of such organisation. i hope that it is going to work this year. it's not wonderful, but it is a start. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 01:52:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHO-0003Pr-00 for ; Tue, 28 Aug 2001 05:11:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:06 +0200 (CEST) Received: (qmail 17802 invoked by uid 0); 27 Aug 2001 23:54:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 27 Aug 2001 23:54:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA19786 for ; Mon, 27 Aug 2001 19:54:05 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:53:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18792 for f-cpu-list; Mon, 27 Aug 2001 19:53:11 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18775 for ; Mon, 27 Aug 2001 19:53:09 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNr9609765 for ; Mon, 27 Aug 2001 19:53:09 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA26730 for ; Tue, 28 Aug 2001 01:53:06 +0200 (MET DST) Message-ID: <3B8ADD3F.DD5E6D12@f-cpu.org> Date: Tue, 28 Aug 2001 01:52:31 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > On Mon, 27 Aug 2001, nicO wrote: > > An other trick could be used : It's to implement the full set of > > instruction but when a none present instruction is decoded a specific > > execption is raised and a specific code is runned. This code could be a > > part of the fcpu and not from a compiler. So you keep the complete > > compatibility. That's what has been proposed a long time ago. > > Ain't that some kind of microcode then? > -> That means it has to be coded -> developed > It's better to just have the exception but no built-in > code. Emulation per software (e.g. it's also implemented > in LEON this way) is preferable BUT introduces additional > overhead. This choice is left to the end-user. however, you can remark that, at our level, "microcode" is almost the same as a FMS. it has to be coded and decoded. If we want to provide a FDIV instruction, we need to provide a way (either HW/SW) to perform the different steps of the NR iterations. Here are different possibilities to perform NR operations at different stages of the pipeline (after scheduling, during scheduling, before scheduling) : * you can use a state machine that locally controls the FP units + => simple and efficient - => blocks the pipeline for the other operations * you design the scheduler so it sends the proper control signal at the right time to "emulate" the FP operation + => other instructions can use the FP units when they are free, so the available slots can still be used - => makes the scheduler REALLY fucked up and complex, at the risk of reducing the clock speed by the incured complexity * you "replace" the emulated instruction with optimized, hardwired instructions (pseudo-microcode, that goes directly to the decoder) + => no decoding hit, no code bloat for the binaries, fast operation - => the exploitation of the potential ILP is not always garanteed. i would preferably go for the last solution, unless someone (a big genius) creates a very very good FP unit that performs complex operations in a non blocking way. THAT is a challenge (and a very interesting one). > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 01:52:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHP-0003Pr-00 for ; Tue, 28 Aug 2001 05:11:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:07 +0200 (CEST) Received: (qmail 13475 invoked by uid 0); 27 Aug 2001 23:54:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 27 Aug 2001 23:54:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA19837 for ; Mon, 27 Aug 2001 19:54:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:53:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18837 for f-cpu-list; Mon, 27 Aug 2001 19:53:14 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18801 for ; Mon, 27 Aug 2001 19:53:11 -0400 Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNrB609770 for ; Mon, 27 Aug 2001 19:53:11 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA28242 for ; Tue, 28 Aug 2001 01:53:08 +0200 (MET DST) Message-ID: <3B8ADD41.68A15859@f-cpu.org> Date: Tue, 28 Aug 2001 01:52:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA References: <3B8A5E10.E17AE3FC@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Andreas Romeyke wrote: > > Hello, > > On Thu, 16 Aug 2001, Michael Riepe wrote: > > > They're more portable than .tar.gz -- not *everybody* uses Linux/Unix. > > I disagree. Gunzip + Tar are available for all possible platforms (unices, > > amiga, atari, c64, winxx-PC, beos, Mac, etc.) Windows-User can use winzip > > and > > co. > Yes but I want the old archive programs too - zip/unzip lha arc > so when I show the great grand kids what kind of computers I ran > as a kid I can load a dusty old cd-rom labeled CP/M 2003 and > unarchive the programs found there. > Ben. btw, the scientists recently discovered a much more interesting data compression algorithm (Burrow-Wheeler). The utilisty is provided with Un*x (bzip2) but it is not yet widely available under other platforms :-( ie : winzip doesn't use it yet. it's a shame : bz2 files often get 20% better compression than tgz. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 01:52:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHP-0003Pr-01 for ; Tue, 28 Aug 2001 05:11:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:07 +0200 (CEST) Received: (qmail 15332 invoked by uid 0); 27 Aug 2001 23:54:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 27 Aug 2001 23:54:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA19927 for ; Mon, 27 Aug 2001 19:54:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:53:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18956 for f-cpu-list; Mon, 27 Aug 2001 19:53:20 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18887 for ; Mon, 27 Aug 2001 19:53:16 -0400 Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNrF609777 for ; Mon, 27 Aug 2001 19:53:16 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA15901 for ; Tue, 28 Aug 2001 01:53:13 +0200 (MET DST) Message-ID: <3B8ADD45.50A0F029@f-cpu.org> Date: Tue, 28 Aug 2001 01:52:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (of floating point and so on) References: <3B8A5B8F.34284EE1@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > > I think we should forget to trace the way to include floating point now. > > Why? > > IMHO there are too many tasks to do, which are more important than > > thinking about floating point units. First, we should have a working > > "simple" F-CPU, not more nor less. i agree. > > Second, a FPU was declared as an optionally unit, > > Floating-point-operations are rare and should be emulated in an > > intelligent way (software) to use the full power of F-CPU's > > SIMD-capabilities > > Last, If we are better in designing units and we have a real (!) F-CPU we > > can easily extend the core with an existing FPU, I think. that's the idea, yes :-) > > In my mind I do not realisize how you will design the scoreboard and the > > shifting unit in a possible way or I misunderstood anything. i am working on the scheduling issues. I leave the shifting unit for whoever wants to have some headaches :-) > > In my opinion we need in near future a working CPU to get and hold a good > > developer-basis, and to make tests in reality not in emulations only. at least, emulation is not expensive ;-) > > Because we can compose a set of FPGAs (Altera and Co.) to load and emulate > > the CPU, we should go in this direction, to make FC0 to that what it is, > > "a proof of concept". > > > > I am in right? at least it's not too far. > I suspect it better to design for the floating point unit now > but leave it out when on the first revision of the cpu design. > Otherwise you could have a large problem trying to "patch" the > floating point unit to the cpu. Say for example you wanted a few > extra bits used just by floating registers you may use 67 bits > for all the registers?This could have a large impact if you all > ready designed 64 bit registers. not necessarily. When "customizing" the F-CPU design files, the user has to indicate which units he wants implemented. The files go through m4 and generate other files which can implement conditional compilation, too. This means that "if it is well done", we can avoid problems in the vein that what you have described : the bits will only be implemented if the necessary flags or features are required. Ain't conditional compilation cool ? :-) > Ben. > PS. I suspect using low cost (slow) Altera parts you will have a > clock rate about 8-16 Mhz. even that is far too fast :-P OTOH according to some figures given by nicolas, a FC0 ASIC could reach 400MHz in .18u. nicO wrote: (about FPU) > An other trick could be used : It's to implement the full set of > instruction but when a none present instruction is decoded a specific > execption is raised and a specific code is runned. This code could be a > part of the fcpu and not from a compiler. So you keep the complete > compatibility. That's what has been proposed a long time ago. > > nicO yep, that is probably going to happen, as soon as we have a working "execution core" for the FC0. notice that the "valid instructions" depend on whether the corresponding unit is present/implemented or not. We could provide some sort of "microcode" (in fact : a hardwired and optimised emulation routine in F-CPU binary format) directly in the VHDL source, and it will be selected/switched with the user configuration file. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 01:52:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHQ-0003Pr-00 for ; Tue, 28 Aug 2001 05:11:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:08 +0200 (CEST) Received: (qmail 23798 invoked by uid 0); 27 Aug 2001 23:54:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Aug 2001 23:54:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA19966 for ; Mon, 27 Aug 2001 19:54:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 27 Aug 2001 23:53:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA18989 for f-cpu-list; Mon, 27 Aug 2001 19:53:23 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA18924 for ; Mon, 27 Aug 2001 19:53:18 -0400 Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7RNrD609775 for ; Mon, 27 Aug 2001 19:53:13 -0400 Received: from f-cpu.org (nas1-144.ras.club-internet.fr [195.36.192.144]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA19108 for ; Tue, 28 Aug 2001 01:53:10 +0200 (MET DST) Message-ID: <3B8ADD43.B308B2E0@f-cpu.org> Date: Tue, 28 Aug 2001 01:52:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > Hi, > > my opinion is that the core parts of f-cpu should be verified. this remembers me that i still have to design the BIST unit :-) > The parts outside the core like memory > controller, interrupt unit a.s.o. could be 'delayed'. > The best way to get started is to use some FPGA to > test the concept in hardware. yup, but before that, we need VHDL source code :-P > But to remind everybody of Intel x86 success. One > part was that it came with the x87 floating coproc > that speeded up arithmetics quite a bit. Motorola > had no real floating point unit fitting to 68K. It > may be a bit carried to far to claim that this was > the only point for Intel success but it is at least > one of them. one "part" of the success is the lobbying they did at the IEEE committee so the standard could adhere to the chip.... which was under design already. I don't think that the x86 FP is such a wonderful thing : sure it is practical in certain circumstances but from experience, i have never used it, though i know how to do. Other "keys" to the "success" of the 8088/8086 are : - IBM did not choose the 68000 because they wanted a cheaper CPU for their "IBM PC". - Intel was second-sourced by AMD, IIRC : less risk if either one goes out of business. - the 8080 and 8085 families were already widely used and had source code base. 68000 was new. > If you don't go for floating point right from the > start you will have targeted the f-cpu to embedded > applications. F-CPU is what you make with it. it is already configurable to a certain extent, so it can be retargetted by modifying one user-visible file. > I don't know if that can be 'healed' > later but it's much easier to strip a unit to make > some shrinked version than to extend something. how can you "strip" something that doesn't exist ? > The direct competition right now is the LEON Sparc > which comes with the nearly free Meiko FPU for low > quantities (SUN SDLC license required). I don't see > the Alpha architecture as THE direct competition at > all - sorry WHYGEE. I both agree and disagree. Yes, LEON will win, so why "compete" ? F-CPU's goal is not to compete with LEON, it would be pointless. > LEON is only 32 bit though but a lot of software for > it is already available as open source. And it could > be used as a powerfull IO processor... LEON serving as "service processor" for the F-CPU is cool but there must be a way to handle the bandwidth and clock speed difference : the F-CPU works with 256-bit wide cache lines and is clocked at least 2x faster (with the same silicon process, as a rough estimate). You'll have to put two or four LEONs in your desktop box to make a balanced system. However i don't see what the LEON can do that the F-CPU can't do. Adding a LEON or more, you will increase the cost and complexity of the machine, making it useless. And today, i don't see what would be the use of a Peripheral Processing Unit. > Why not implement f-cpu as a coprocessor into the > LEON IO processor. With the LEON coprocessor opcodes > it could be easy to implement a debug interface for > f-cpu testing with download and single stepping... F-CPU as a coprocessor INSIDE LEON ? if you put them in the same chip, the difference in the pipeline complexity will make the F-CPU a ridiculous underperformer if you clock the chip at a fixed frequency. If you want single-stepping, a simple FPGA board or a CELARO emulator can do the trick. I don't see why you would need to put a SPARC next to F-CPU, a direct interface to the host station is more useful. > Does anybody have access to a synthesis tool for some > prototyping? Does anybody have access to a FPGA board > for testing? i think that some people here have some means. however, without complete source code, it's almost useless :-( > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Aug 27 19:34:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bZHR-0003Pr-00 for ; Tue, 28 Aug 2001 05:11:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 05:11:09 +0200 (CEST) Received: (qmail 14096 invoked by uid 0); 28 Aug 2001 00:15:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 28 Aug 2001 00:15:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA20562 for ; Mon, 27 Aug 2001 20:15:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 00:15:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA20319 for f-cpu-list; Mon, 27 Aug 2001 20:15:02 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA20303 for ; Mon, 27 Aug 2001 20:15:00 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7S0Ex609955 for ; Mon, 27 Aug 2001 20:15:00 -0400 Received: from jetnet.ab.ca (dialin46.jetnet.ab.ca [207.153.6.46]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA26091 for ; Mon, 27 Aug 2001 18:14:52 -0600 (MDT) Message-ID: <3B8A84BE.A5E2DC7F@jetnet.ab.ca> Date: Mon, 27 Aug 2001 11:34:54 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [Fwd: [f-cpu] the wrong way (of floating point and so on)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > This means that "if it is well done", we can avoid problems in the vein that > what you have described : the bits will only be implemented if the > necessary flags or features are required. Ain't conditional compilation cool ? :-) How high level will the tools be? A adder could be a stock adder or custom designed one at the transistor level? Ripple carry? Carry lookahead? Carry-skip? > > Ben. > > PS. I suspect using low cost (slow) Altera parts you will have a > > clock rate about 8-16 Mhz. > even that is far too fast :-P > > OTOH according to some figures given by nicolas, a FC0 ASIC could > reach 400MHz in .18u. Did you know intel is claming a 2 GHZ chip? Still 400 MHZ is not to shabby. > nicO wrote: (about FPU) > > An other trick could be used : It's to implement the full set of > > instruction but when a none present instruction is decoded a specific > > execption is raised and a specific code is runned. This code could be a > > part of the fcpu and not from a compiler. So you keep the complete > > compatibility. That's what has been proposed a long time ago. > > > > nicO > > yep, that is probably going to happen, as soon as we have a working > "execution core" for the FC0. notice that the "valid instructions" > depend on whether the corresponding unit is present/implemented or > not. We could provide some sort of "microcode" (in fact : a hardwired > and optimised emulation routine in F-CPU binary format) directly in the VHDL > source, and it will be selected/switched with the user configuration file. I like a separate math floating point FPGA idea like intel did with their CPU's. > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ Ben. PS. Yipes supper is burn... -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Tue Aug 28 07:56:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopR-0003cg-00 for ; Tue, 28 Aug 2001 21:47:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:17 +0200 (CEST) Received: (qmail 27454 invoked by uid 0); 28 Aug 2001 05:56:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 28 Aug 2001 05:56:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id BAA02942 for ; Tue, 28 Aug 2001 01:56:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 05:56:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id BAA02707 for f-cpu-list; Tue, 28 Aug 2001 01:56:37 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id BAA02704 for ; Tue, 28 Aug 2001 01:56:31 -0400 Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7S5uV614931 for ; Tue, 28 Aug 2001 01:56:31 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA26667 for ; Tue, 28 Aug 2001 08:56:29 +0300 (EET DST) Date: Tue, 28 Aug 2001 08:56:28 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) In-Reply-To: <3B8ADD43.B308B2E0@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 28 Aug 2001, Yann Guidon wrote: > LEON serving as "service processor" for the F-CPU is > cool but there must be a way to handle the bandwidth and > clock speed difference : the F-CPU works with 256-bit wide > cache lines and is clocked at least 2x faster (with the > same silicon process, as a rough estimate). You'll have > to put two or four LEONs in your desktop box to make a > balanced system. How do you know how well F-CPU will clock before the RTL code is done :) Or has someone made already some rough estimations about the logic deepness in each pipeline stage and estimations about the critical paths inside pipeline. That could give some hints about the speed. btw. for FPGA emulation there might be a need to do the ALU differently. In FPGA architecture ALU must be designed around the 4-input LUT (many architectures use 4 input). This limitation leads to a design where the logical and aritcmetical ALUs are implemented separately etc. In this way the logic deepness can be one logic level less (at least). But I'm not a expert on this, there have been some discussions about this in comp.arch.fpga or comp.lang.vhdl or verilog areas. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Aug 28 07:17:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopS-0003cg-00 for ; Tue, 28 Aug 2001 21:47:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:18 +0200 (CEST) Received: (qmail 30725 invoked by uid 0); 28 Aug 2001 06:03:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 28 Aug 2001 06:03:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA03243 for ; Tue, 28 Aug 2001 02:03:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 06:03:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA03005 for f-cpu-list; Tue, 28 Aug 2001 02:03:23 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA03002 for ; Tue, 28 Aug 2001 02:03:22 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7S63L614998 for ; Tue, 28 Aug 2001 02:03:22 -0400 Received: from art1.none.de (dialin193.pg4-nt.berlin.nikoma.de [213.54.67.193]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f7S63Dj06432 for ; Tue, 28 Aug 2001 08:03:16 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin193.pg4-nt.berlin.nikoma.de [213.54.67.193] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15bbGI-0000jS-00 for ; Tue, 28 Aug 2001 07:18:06 +0200 Date: Tue, 28 Aug 2001 07:17:05 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: OFF: ZIP vs GZ was:Re: [f-cpu] F-CPU vs ALPHA In-Reply-To: <3B8ADD41.68A15859@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id CAA03003 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Tue, 28 Aug 2001, Yann Guidon wrote: > algorithm (Burrow-Wheeler). The utilisty is provided with Un*x (bzip2) I know about and I use it. > but it is not yet widely available under other platforms :-( > ie : winzip doesn't use it yet. it's a shame : bz2 files often get 20% better > compression than tgz. bzip2 is availöable as Source and you can compile it under gcc for dos. Tzip is similar to bzip2 but with larger blocks. Very cool was bzip (the thing before bzip2), it uses arithmetic compression instead huffman, and compresses so 2-5 percent points smaller. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7iylVClxplZklbgERAmySAJ48jmIrk5S5L5cH1oPoPsM+WmdzBQCdEtpL mWtLx7CEuJPrn+60q+b8YBY= =aRfv -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Tue Aug 28 08:04:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopS-0003cg-01 for ; Tue, 28 Aug 2001 21:47:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:18 +0200 (CEST) Received: (qmail 13318 invoked by uid 0); 28 Aug 2001 06:04:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 28 Aug 2001 06:04:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA03504 for ; Tue, 28 Aug 2001 02:04:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 06:04:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA03263 for f-cpu-list; Tue, 28 Aug 2001 02:04:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA03260 for ; Tue, 28 Aug 2001 02:04:21 -0400 Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7S64L615017 for ; Tue, 28 Aug 2001 02:04:21 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA09703 for ; Tue, 28 Aug 2001 09:04:20 +0300 (EET DST) Date: Tue, 28 Aug 2001 09:04:19 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [Fwd: [f-cpu] the wrong way (of floating point and so on)] In-Reply-To: <3B8A84BE.A5E2DC7F@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 27 Aug 2001, Ben Franchuk wrote: > How high level will the tools be? A adder could be a stock adder > or custom designed > one at the transistor level? Ripple carry? Carry lookahead? > Carry-skip? I think in the beginning F-CPU should use the adders the synthesizers produce. They are so much faster to produce (I mean writing + sign is faster than creating adder with complex generate structures :)). There is time after the functional testing and proof on concept to tinker with the small bits and optimize the design. Even if the design runs at 1 MHz without optimization that is way faster for testing than simulation. > > OTOH according to some figures given by nicolas, a FC0 ASIC could > > reach 400MHz in .18u. > > Did you know intel is claming a 2 GHZ chip? Still 400 MHZ is not > to shabby. Intel has very long pipeline in the chip which helps in the MHz rally. Intel also knows their ASIC process very well, each chip is tailor made for the process. I bet they have tools to use all their different cells at the same time (low power/slow, power hungry/fast etc.) Many ASIC vendors support only one library at the same time currently, but this is changing with the new design flows. And full custom design can do wonders sometimes, but it takes huge amounts of time and ties you to one process. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 12:35:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopW-0003cg-00 for ; Tue, 28 Aug 2001 21:47:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:22 +0200 (CEST) Received: (qmail 14919 invoked by uid 0); 28 Aug 2001 10:36:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 28 Aug 2001 10:36:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA08660 for ; Tue, 28 Aug 2001 06:36:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 10:36:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA08419 for f-cpu-list; Tue, 28 Aug 2001 06:36:20 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA08416 for ; Tue, 28 Aug 2001 06:36:18 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SAaI617761 for ; Tue, 28 Aug 2001 06:36:18 -0400 Received: from f-cpu.org (nas4-100.bls.club-internet.fr [195.36.133.100]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA09286 for ; Tue, 28 Aug 2001 12:36:14 +0200 (MET DST) Message-ID: <3B8B73F9.90CEE88D@f-cpu.org> Date: Tue, 28 Aug 2001 12:35:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Kim Enkovaara wrote: > On Tue, 28 Aug 2001, Yann Guidon wrote: > > > LEON serving as "service processor" for the F-CPU is > > cool but there must be a way to handle the bandwidth and > > clock speed difference : the F-CPU works with 256-bit wide > > cache lines and is clocked at least 2x faster (with the > > same silicon process, as a rough estimate). You'll have > > to put two or four LEONs in your desktop box to make a > > balanced system. > > How do you know how well F-CPU will clock before the RTL code is done :) > Or has someone made already some rough estimations about the logic > deepness in each pipeline stage and estimations about the critical paths > inside pipeline. That could give some hints about the speed. concerning synthesis, nicolas is best placed to answer. However, the FC0 is designed from the start around the critical datapath : each pipeline stage must have a very reduced complexity and depth. this eases both the design and the clock speed. > btw. for FPGA emulation there might be a need to do the ALU differently. > In FPGA architecture ALU must be designed around the 4-input LUT (many > architectures use 4 input). This limitation leads to a design where the > logical and aritcmetical ALUs are implemented separately etc. In this way > the logic deepness can be one logic level less (at least). But I'm not a > expert on this, there have been some discussions about this in > comp.arch.fpga or comp.lang.vhdl or verilog areas. Several years ago, i have used MUX-based FPGAs (Actel A1020). the "gates" are 3 2-input multiplexors, and they could be arranged to perform a wide range of logic funtions (sequential or combinatorial). logic functions are often limited to 4 inputs in this context. So yes i'm already used to live with this limitation. I have also used 4-input LUTs with the custom chips at META. Concerning the FC0, the original goal is to have a maximum of 6 four-input gates in the critical datapath. Add to that the fanout problems and the wire lengths. If you consider the 6 logical gates CDP, you see that you can't do much during a clock cycle. at least one half of what other CPUs do. This morning i polished the last version of the ROP2 unit and i'll release it ASAP. the critical datapth contains (in order) : AND3, OR4, AND/OR8, MUX4. This is in "VHDL" coding style without using gates or synthesis. through optimisation and boolean simplifications (choosing to use inverted levels at the proper place), i think that the criterium will be met. Concerning your answer to Ben, i agree : i have nothing to add. Concerning the LEON, i have just read a few source files, concerning the technology-dependent ("megacells") part. The PDF manual is well done but in return the source files (those that i have read) are not commented at all :-/ I am now concerned about the register set and its asynchrounous write cycle. It is not clear yet but if we use asynchronous stuff, we need a local 2x clock to generate the write strobe. Otherwise write will require at least 2 cycles and we won't meet the goal of 2 writes / cycle. using synchronous banks just "moves" the problem to the next cycle. help ! > Mr. Kim Enkovaara WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Aug 28 14:19:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopX-0003cg-00 for ; Tue, 28 Aug 2001 21:47:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:23 +0200 (CEST) Received: (qmail 19206 invoked by uid 0); 28 Aug 2001 11:44:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 28 Aug 2001 11:44:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA10562 for ; Tue, 28 Aug 2001 07:44:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 11:44:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA10318 for f-cpu-list; Tue, 28 Aug 2001 07:44:26 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA10315 for ; Tue, 28 Aug 2001 07:44:24 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SBiN618479 for ; Tue, 28 Aug 2001 07:44:23 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bhq6-0001mP-00 for f-cpu@seul.org; Tue, 28 Aug 2001 14:19:30 +0200 Date: Tue, 28 Aug 2001 14:19:30 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) In-Reply-To: <3B8ADD43.B308B2E0@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 28 Aug 2001, Yann Guidon wrote: > this remembers me that i still have to design the BIST unit :-) > yup, but before that, we need VHDL source code :-P Yes, a lot to do still... > > If you don't go for floating point right from the > > start you will have targeted the f-cpu to embedded > > applications. > F-CPU is what you make with it. it is already configurable > to a certain extent, so it can be retargetted by modifying > one user-visible file. > > I don't know if that can be 'healed' > > later but it's much easier to strip a unit to make > > some shrinked version than to extend something. > how can you "strip" something that doesn't exist ? Yes agreed, but the name (i.e. f-cpu) will be burdened by the first running silicon functionality. It's like a brand. > F-CPU's goal is not to compete with LEON, it would be pointless. I didn't mean to compete. Just wanted to say that LEON is the first open source processor available. > > LEON is only 32 bit though but a lot of software for > > it is already available as open source. And it could > > be used as a powerfull IO processor... > LEON serving as "service processor" for the F-CPU is > cool but there must be a way to handle the bandwidth and > clock speed difference : the F-CPU works with 256-bit wide > cache lines and is clocked at least 2x faster (with the > same silicon process, as a rough estimate). You'll have > to put two or four LEONs in your desktop box to make a > balanced system. > However i don't see what the LEON can do that the F-CPU > can't do. Adding a LEON or more, you will increase the > cost and complexity of the machine, making it useless. > And today, i don't see what would be the use of a Peripheral > Processing Unit. Maybe you don't see it the same way. But my opinion is that interrupts of different sources will give penalty on cache hits, thus slowing down the hardware. Ideally the main processor should concentrate on the job that it should do - not to serve I/O devices. > > Why not implement f-cpu as a coprocessor into the > > LEON IO processor. With the LEON coprocessor opcodes > > it could be easy to implement a debug interface for > > f-cpu testing with download and single stepping... > F-CPU as a coprocessor INSIDE LEON ? > if you put them in the same chip, the difference > in the pipeline complexity will make the F-CPU > a ridiculous underperformer if you clock the > chip at a fixed frequency. No, you got it wrong. I mean why not use LEON as a debug frontend tool. I didn't mean to clock it the same frequency, nor did I mean to let the memory interface of f-cpu go over LEON AMBA bus. > If you want single-stepping, a simple FPGA board > or a CELARO emulator can do the trick. I don't see why you > would need to put a SPARC next to F-CPU, a direct > interface to the host station is more useful. No, the problem is that you have to get/put the data and verify it. If you use a prooved design for control it gets easier. Of course you can write and run the control software on your PC but the interface is even worse than the coprocessor interface of LEON. Hey, I didn't say to integrate the f-cpu into LEON, just to use the coprocessor interface as a built-in control functionality for debugging. > > Does anybody have access to a synthesis tool for some > > prototyping? Does anybody have access to a FPGA board > > for testing? > > i think that some people here have some means. > however, without complete source code, it's almost > useless :-( Anybody out there? By the way, what is still missing? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Aug 28 15:17:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopZ-0003cg-00 for ; Tue, 28 Aug 2001 21:47:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:25 +0200 (CEST) Received: (qmail 22702 invoked by uid 0); 28 Aug 2001 13:12:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 28 Aug 2001 13:12:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA12822 for ; Tue, 28 Aug 2001 09:12:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 13:12:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA12583 for f-cpu-list; Tue, 28 Aug 2001 09:12:35 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA12580 for ; Tue, 28 Aug 2001 09:12:34 -0400 Received: from imf11bis.bellsouth.net (mail211.mail.bellsouth.net [205.152.58.151]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SDCX619825 for ; Tue, 28 Aug 2001 09:12:33 -0400 Received: from computer ([208.60.245.119]) by imf11bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010828131325.YRHJ20566.imf11bis.bellsouth.net@computer>; Tue, 28 Aug 2001 09:13:25 -0400 Message-ID: <005b01c12fc3$d9e55c60$77f53cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] ERIN32 Components Date: Tue, 28 Aug 2001 08:17:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C12F99.F01B3060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C12F99.F01B3060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben-- I will be using QL6600's of the Eclipse Family from Quicklogic having = 4032 Logic Cells.=20 The Language Processor uses two FPGA's and the Peripheral Processor is a = mirror image. =20 Each ERIN32 consists of a Data Processor & an Address Processor. I = fetch four instructions and four operands in parallel. The = Microinstruction is 72 Bits, where 18 are Source address and 18 Bits are = Destination address. Modified Harvard Architecture. The instruction Pipeline is four deep. And where possible all four are = executed. I have a Bit in the instruction which I call DDP (data = dependent) if an instruction requires the result of the previous, I have = a controlled stall/restart. There seems to be a direct correlation of performance to pipeline depth. = I.E.-- 1, 2, 4, 8.16 etc. I will have a 200 MHZ average execution time = operating from a base 50 MHZ oscillator applied to a PLL. The design is NOT logic cell limited. The DAP uses 2100 cells and the = ADP uses 1800 - most are used by Multiply and Divide instructions. I was = going to have these as optional instructions - but since I had space to = burn, they are free-bees. I am using Synchronous Static Rams (SSRAM) from Cypress Semi. Both two = port and four port. The local memory is essentially an Orthogonal Array. = Access time is 4.5 NS for both types. I am currently doing the FBC (fully buffered channel) which should be = complete this week. Will probably use an QL6500 here. Next I will be doing the CICU (Console Interrupt Control Unit) for 128 = User Stations. This design should take two weeks - and at this point I will have all = designs completed for the Expo at San Jose. Don't hesitate sending Questions - the only thing I have that is Company = Private is the Memory Architecture. Regards Dick Hartney ------=_NextPart_000_0058_01C12F99.F01B3060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ben--
 
I will be using QL6600's of the Eclipse = Family from=20 Quicklogic having 4032 Logic Cells.
 
The Language Processor uses two FPGA's = and the=20 Peripheral Processor is a mirror image. 
 
Each ERIN32 consists of a Data = Processor & an=20 Address Processor.  I fetch four instructions and four operands in=20 parallel.  The Microinstruction is 72 Bits, where 18 are Source = address and=20 18 Bits are Destination address.  Modified Harvard=20 Architecture.
 
The instruction Pipeline is four = deep.  And=20 where possible all four are executed.  I have a Bit in the = instruction=20 which I call DDP (data dependent) if an instruction requires the result = of the=20 previous, I have a controlled stall/restart.
 
There seems to be a direct correlation = of=20 performance to pipeline depth.  I.E.--
1, 2, 4, 8.16 etc.  I will have a = 200 MHZ=20 average execution time operating from a base 50 MHZ oscillator applied = to a=20 PLL.
 
The design is NOT logic cell = limited.  The DAP=20 uses 2100 cells and the ADP uses 1800 - most are used by Multiply and = Divide=20 instructions. I was going to have these as optional instructions - but = since I=20 had space to burn, they are free-bees.
 
I am using Synchronous Static Rams = (SSRAM) from=20 Cypress Semi.  Both two port and four port. The local memory is = essentially=20 an Orthogonal Array.  Access time is 4.5 NS for both = types.
 
I am currently doing the FBC (fully = buffered=20 channel) which should be complete this week.  Will probably use an = QL6500=20 here.
 
Next I will be doing the CICU (Console = Interrupt=20 Control Unit) for 128 User Stations.
This design should take two weeks - and = at this=20 point I will have all designs completed for the Expo at San = Jose.
 
Don't hesitate sending Questions - the = only thing I=20 have that is Company Private is the Memory Architecture.
 
Regards
Dick Hartney
------=_NextPart_000_0058_01C12F99.F01B3060-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Aug 28 16:52:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopa-0003cg-00 for ; Tue, 28 Aug 2001 21:47:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:26 +0200 (CEST) Received: (qmail 11383 invoked by uid 0); 28 Aug 2001 14:17:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 28 Aug 2001 14:17:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA13757 for ; Tue, 28 Aug 2001 10:17:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 14:17:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA13514 for f-cpu-list; Tue, 28 Aug 2001 10:17:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA13511 for ; Tue, 28 Aug 2001 10:17:21 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SEHK621109 for ; Tue, 28 Aug 2001 10:17:20 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15bkEC-00028i-00 for f-cpu@seul.org; Tue, 28 Aug 2001 16:52:32 +0200 Date: Tue, 28 Aug 2001 16:52:32 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP In-Reply-To: <3B8ADD3F.DD5E6D12@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 28 Aug 2001, Yann Guidon wrote: > i would preferably go for the last solution, unless someone > (a big genius) creates a very very good FP unit that performs > complex operations in a non blocking way. THAT is a challenge > (and a very interesting one). What do you mean by complex operations? sqrt(), log(), cos(), sin(), ...? I think a floating unit will be fine with add, sub, mul, div and maybe muladd. And I expect that it could be designed in pipelined operation to give single cycle average execution time. A 64 bit floating number unit would be just enough for a start because you can convert any AD sampled 32bit integer value into this format... Who needs more accuracy? So why divide into integer and floating unit? Add those basic floating functionality to *the* f-cpu unit. If you want to add the complex function stuff like sin() it gets more complicated and you get rid of pipelining the instructions due to longer delays for the results and reuse of the units. It will be more of a microcode thing then or better say it this way, you end up with ordinary FPU design. But actually most brute force problems I know don't have a need for the complex functions but for a high performance in basic arithmetics. Complex functions could be emulated by software anyway. Am I right? Are there any intelligent algorithms for fast emulation of the complex functions? This exceeds my experience (logic, network and software design on all layers) but I would volunteer on this part ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Aug 28 16:17:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopb-0003cg-00 for ; Tue, 28 Aug 2001 21:47:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:27 +0200 (CEST) Received: (qmail 29363 invoked by uid 0); 28 Aug 2001 14:22:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 28 Aug 2001 14:22:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA14062 for ; Tue, 28 Aug 2001 10:22:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 14:22:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA13820 for f-cpu-list; Tue, 28 Aug 2001 10:22:01 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA13817 for ; Tue, 28 Aug 2001 10:22:00 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SELx621194 for ; Tue, 28 Aug 2001 10:22:00 -0400 Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA21838 for ; Tue, 28 Aug 2001 08:21:53 -0600 (MDT) Message-ID: <3B8BA80E.9C04AB0@jetnet.ab.ca> Date: Tue, 28 Aug 2001 08:17:50 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > i think that some people here have some means. > > however, without complete source code, it's almost > > useless :-( > > Anybody out there? By the way, what is still missing? > > JG Are the DOC's current? If you have the DOC's you can then generate the logic design, but not the other way around. With the F-CPU the logic pipeline is limited to about 6 CMOS gates. The organization so far looks good but putting the design in a FPGA will mess up the timing because of the logic structure used in the FPGA. Lets not worry about the speed of the pipeline here because it is the relative speed of the stages that counts. Everything done in the for speed FPGA will completely be undone in the custom version. Reading the book "CMOS circuit design layout and simulation" ISBN 0-7803-3416-7 and just other stuff the datapath layout is still best designed by hand. Can such a layout (transistor level) be merged with VHDL so that non-crital stuff and critical hand placed logic both be used in the same layout? Ben. PS. looking a paper on carry skip adders ( grabbed off the web ) a sample 64 bit adder is about 18 unit delays. A adder delay is 3x the basic pipeline speed. I am guessing a carry skip adder may be faster in the future because it can scale better for the very latest in technology over the other kinds of adders. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 28 14:52:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15boph-0003cg-00 for ; Tue, 28 Aug 2001 21:47:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:33 +0200 (CEST) Received: (qmail 15905 invoked by uid 0); 28 Aug 2001 17:45:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 28 Aug 2001 17:45:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA19290 for ; Tue, 28 Aug 2001 13:45:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 17:44:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA18999 for f-cpu-list; Tue, 28 Aug 2001 13:44:36 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA18996 for ; Tue, 28 Aug 2001 13:44:34 -0400 Received: from tribble.stud.uni-hannover.de (root@a081.home.uni-hannover.de [130.75.232.81]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SHhx625925 for ; Tue, 28 Aug 2001 13:44:06 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00552; Tue, 28 Aug 2001 14:52:01 +0200 Message-ID: <20010828145201.41997@thrai.stud.uni-hannover.de> Date: Tue, 28 Aug 2001 14:52:01 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) References: <3B8ADD43.B308B2E0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Tue, Aug 28, 2001 at 08:56:28AM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 28, 2001 at 08:56:28AM +0300, Kim Enkovaara wrote: [...] > btw. for FPGA emulation there might be a need to do the ALU differently. > In FPGA architecture ALU must be designed around the 4-input LUT (many > architectures use 4 input). This limitation leads to a design where the > logical and aritcmetical ALUs are implemented separately etc. In this way > the logic deepness can be one logic level less (at least). But I'm not a > expert on this, there have been some discussions about this in > comp.arch.fpga or comp.lang.vhdl or verilog areas. I wish you guys would at least read the F-CPU documentation and/or the available source code before you waste my time. - there is no single ALU - logical operations are handled by the ROP2 execution unit - add/subtract are done in the ASU EU - the multiplier also is a separate unit - the ROP2 is 1 stage "deep" - the ASU needs 2 stages (for a full-width result) - the IMU (integer multiply) currently has 6 stages They're not optimized for FPGA use yet (which FPGA? They differ so much that you need to rewrite all your stuff when you move from one vendor/family to another). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 28 21:05:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopi-0003cg-00 for ; Tue, 28 Aug 2001 21:47:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:34 +0200 (CEST) Received: (qmail 1487 invoked by uid 0); 28 Aug 2001 19:06:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 28 Aug 2001 19:06:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA20759 for ; Tue, 28 Aug 2001 15:06:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 19:05:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA20510 for f-cpu-list; Tue, 28 Aug 2001 15:05:48 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA20504 for ; Tue, 28 Aug 2001 15:05:47 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SJ5k627201 for ; Tue, 28 Aug 2001 15:05:46 -0400 Received: from f-cpu.org (nas3-47.ras.club-internet.fr [195.36.203.47]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA03465 for ; Tue, 28 Aug 2001 21:05:42 +0200 (MET DST) Message-ID: <3B8BEB63.279A236A@f-cpu.org> Date: Tue, 28 Aug 2001 21:05:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > On Tue, 28 Aug 2001, Yann Guidon wrote: > > i would preferably go for the last solution, unless someone > > (a big genius) creates a very very good FP unit that performs > > complex operations in a non blocking way. THAT is a challenge > > (and a very interesting one). > > What do you mean by complex operations? > sqrt(), log(), cos(), sin(), ...? "simple" operations are fadd/fsub and fmul. of course the conversion operations are necessary (FP<->int, truncation, fractional part...) and should be simple (at least most of them). division and sqrt require several Newton-Raphson steps, using floating point multiply and add/sub. Because it is better to reuse the existing units, fdiv and fsqrt have to share them with the "normal" operations. However, for the first FC0s, the fdiv and fsqrt will have to be emulated with a "invalid opcode" trap. > I think a floating unit will be fine with add, sub, mul, div Unless you know a good unit that perform fdiv quickly and without using too much ressources, why not. > and maybe muladd. And I expect that it could be designed in > pipelined operation to give single cycle average execution > time. A 64 bit floating number unit would be just enough for > a start because you can convert any AD sampled 32bit integer > value into this format... Who needs more accuracy? > > So why divide into integer and floating unit? Add those > basic floating functionality to *the* f-cpu unit. i think that it will be complex, if you mean what i have understood. But you can remember that the register set stores all kinds of data, so the FP EU can not be taken outside of the F-CPU core. So there is no "division". > If you want to add the complex function stuff like sin() > it gets more complicated and you get rid of pipelining the > instructions due to longer delays for the results and reuse > of the units. It will be more of a microcode thing then or > better say it this way, you end up with ordinary FPU design. > > But actually most brute force problems I know don't have a > need for the complex functions but for a high performance > in basic arithmetics. Complex functions could be emulated > by software anyway. Am I right? right. > Are there any intelligent algorithms for fast emulation of > the complex functions? This exceeds my experience (logic, > network and software design on all layers) but I would > volunteer on this part ;-) last time i searched, i found some informations about FP unit design. i even posted a web page about it. that's a good starting point if you want to volunteer. What we need now is fadd/fsub and fmul in IEEE 32-bit and 64-bit format. From that, we can derive all the rest. good luck :-) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Tue Aug 28 21:06:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bopj-0003cg-00 for ; Tue, 28 Aug 2001 21:47:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 28 Aug 2001 21:47:35 +0200 (CEST) Received: (qmail 24464 invoked by uid 0); 28 Aug 2001 19:07:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 28 Aug 2001 19:07:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA21032 for ; Tue, 28 Aug 2001 15:07:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 19:06:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA20792 for f-cpu-list; Tue, 28 Aug 2001 15:06:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA20789 for ; Tue, 28 Aug 2001 15:06:52 -0400 Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SJ6p627219 for ; Tue, 28 Aug 2001 15:06:51 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.224.52]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id WAA19132 for ; Tue, 28 Aug 2001 22:06:50 +0300 (EET DST) Date: Tue, 28 Aug 2001 22:06:49 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) In-Reply-To: <20010828145201.41997@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 28 Aug 2001, Michael Riepe wrote: > They're not optimized for FPGA use yet (which FPGA? They differ so > much that you need to rewrite all your stuff when you move from one > vendor/family to another). Actually new Altera and Xilinx chips are very similiar. The logic element structure is almost identical. The biggest differences are in the routing matrix. At least with RTL VHDL that is targeted for FPGA the results are quite similiar (assumes 4 input luts etc.). There are some more exotic FPGA structures available, but the big ones are quite similiar. At least this is my experience with these new chips. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 28 20:37:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bsny-0000u6-00 for ; Wed, 29 Aug 2001 02:02:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 02:02:02 +0200 (CEST) Received: (qmail 641 invoked by uid 0); 28 Aug 2001 21:57:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 28 Aug 2001 21:57:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA26663 for ; Tue, 28 Aug 2001 17:57:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 21:57:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA26421 for f-cpu-list; Tue, 28 Aug 2001 17:57:33 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA26418 for ; Tue, 28 Aug 2001 17:57:32 -0400 Received: from tribble.stud.uni-hannover.de (root@a244.home.uni-hannover.de [130.75.232.244]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SLvJ630406 for ; Tue, 28 Aug 2001 17:57:20 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01676; Tue, 28 Aug 2001 20:37:22 +0200 Message-ID: <20010828203722.53739@thrai.stud.uni-hannover.de> Date: Tue, 28 Aug 2001 20:37:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: <3B8ADD3F.DD5E6D12@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Aug 28, 2001 at 04:52:32PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 28, 2001 at 04:52:32PM +0200, Juergen Goeritz wrote: [...] > Are there any intelligent algorithms for fast emulation of > the complex functions? This exceeds my experience (logic, > network and software design on all layers) but I would > volunteer on this part ;-) Depends on the function. N-R iteration, polynomial approximation, maybe CORDIC for trigonometric functions, ... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 29 00:22:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15bsnz-0000u6-00 for ; Wed, 29 Aug 2001 02:02:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 02:02:03 +0200 (CEST) Received: (qmail 13683 invoked by uid 0); 28 Aug 2001 22:22:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 28 Aug 2001 22:22:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA27286 for ; Tue, 28 Aug 2001 18:22:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 28 Aug 2001 22:22:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA27045 for f-cpu-list; Tue, 28 Aug 2001 18:22:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA27042 for ; Tue, 28 Aug 2001 18:22:26 -0400 Received: from tribble.stud.uni-hannover.de (michael@a244.home.uni-hannover.de [130.75.232.244]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7SMMO630703 for ; Tue, 28 Aug 2001 18:22:24 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02374; Wed, 29 Aug 2001 00:22:29 +0200 Message-ID: <20010829002229.22158@thrai.stud.uni-hannover.de> Date: Wed, 29 Aug 2001 00:22:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) References: <20010828145201.41997@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Tue, Aug 28, 2001 at 10:06:49PM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 28, 2001 at 10:06:49PM +0300, Kim Enkovaara wrote: [...] > Actually new Altera and Xilinx chips are very similiar. The logic > element structure is almost identical. The biggest differences are in the > routing matrix. At least with RTL VHDL that is targeted for FPGA the > results are quite similiar (assumes 4 input luts etc.). I checked Xilinx and Atmel (AT40K, not AT6K), and they look pretty different to me, although both use 16:1 LUTs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Aug 29 09:48:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15c03o-0001es-00 for ; Wed, 29 Aug 2001 09:46:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 09:46:52 +0200 (CEST) Received: (qmail 10062 invoked by uid 0); 29 Aug 2001 07:13:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 29 Aug 2001 07:13:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA03664 for ; Wed, 29 Aug 2001 03:13:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 07:13:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA03418 for f-cpu-list; Wed, 29 Aug 2001 03:13:00 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA03415 for ; Wed, 29 Aug 2001 03:12:59 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7T7Cv603493 for ; Wed, 29 Aug 2001 03:12:58 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15c05V-0003KK-00 for f-cpu@seul.org; Wed, 29 Aug 2001 09:48:37 +0200 Date: Wed, 29 Aug 2001 09:48:37 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP In-Reply-To: <3B8BEB63.279A236A@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 28 Aug 2001, Yann Guidon wrote: > hi, > > Juergen Goeritz wrote: > > What do you mean by complex operations? > > sqrt(), log(), cos(), sin(), ...? > > "simple" operations are fadd/fsub and fmul. > of course the conversion operations are necessary > (FP<->int, truncation, fractional part...) and should be > simple (at least most of them). Oops, I forgot about the conversion functions... :-] > However, for the first FC0s, the fdiv and fsqrt will have to > be emulated with a "invalid opcode" trap. Everything that's not included must be emulated like this anyway ;-) > > So why divide into integer and floating unit? Add those > > basic floating functionality to *the* f-cpu unit. > i think that it will be complex, if you mean what i have > understood. But you can remember that the register set > stores all kinds of data, so the FP EU can not be taken > outside of the F-CPU core. So there is no "division". Is there no opcode left for fdiv inside the f-cpu? > last time i searched, i found some informations about FP unit > design. i even posted a web page about it. that's a good starting > point if you want to volunteer. What we need now is fadd/fsub > and fmul in IEEE 32-bit and 64-bit format. From that, we can > derive all the rest. I took a look into the links you mailed. Haven't seen much about a good division though. I will concentrate on the 64 bit version, because 32bit is derivable from this. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Wed Aug 29 10:48:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cBNK-0006Bx-00 for ; Wed, 29 Aug 2001 21:51:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 21:51:46 +0200 (CEST) Received: (qmail 11038 invoked by uid 0); 29 Aug 2001 08:48:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 29 Aug 2001 08:48:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA06484 for ; Wed, 29 Aug 2001 04:48:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 08:48:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA06238 for f-cpu-list; Wed, 29 Aug 2001 04:48:22 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA06235 for ; Wed, 29 Aug 2001 04:48:21 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7T8mK604510 for ; Wed, 29 Aug 2001 04:48:20 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id EAA17787 for ; Wed, 29 Aug 2001 04:42:09 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id EAA26986 for ; Wed, 29 Aug 2001 04:48:09 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 09:48:07 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F053@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point Date: Wed, 29 Aug 2001 09:48:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id EAA06236 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hi, > > nicO wrote: > > Michael Riepe a écrit : > > > On Sun, Aug 19, 2001 at 05:33:05PM -0400, nicO wrote: > > > > Hello, > > > > I'm looking for the "usual" definition of the port of a unit : > > > > 3 data in, > > > Or less. > > Yep! > > > > 2 data out, > > > Or more. > > MORE ? I beleive that the fc0 is 3r2w (which give the > > number of register bank port). So ? > > some units have "variable latency". IE the multiplier can give results > with different latency, depending on the data chunk size. > The different outputs are then "mixed" with the Xbar (sorry : > the big mux). Previously you insisted on fixed latency. Remember my heretical scheduler design? See http://www.hanssummers.com/computers/fcpu/scheduler.htm. With this design you can easily have fixed latency, with exactly the same issue order and completion order as your current scheduler design. But my design can very easily be extended in future, allowing run-time optimisations because of variable latency (early completion of execution units). > > > nicO > WHYGEE "programmer ou dormir, il faut choisir"... > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------ Hans Summers http://www.HansSummers.Com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Aug 29 16:22:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cBNR-0006Bx-00 for ; Wed, 29 Aug 2001 21:51:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 21:51:53 +0200 (CEST) Received: (qmail 2429 invoked by uid 0); 29 Aug 2001 14:18:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 29 Aug 2001 14:18:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA17733 for ; Wed, 29 Aug 2001 10:18:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 14:17:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA17502 for f-cpu-list; Wed, 29 Aug 2001 10:17:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA17499 for ; Wed, 29 Aug 2001 10:17:26 -0400 Received: from imf06bis.bellsouth.net (mail106.mail.bellsouth.net [205.152.58.46]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7TEHQ609191 for ; Wed, 29 Aug 2001 10:17:26 -0400 Received: from computer ([209.214.154.87]) by imf06bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010829141815.RBHJ9998.imf06bis.bellsouth.net@computer>; Wed, 29 Aug 2001 10:18:15 -0400 Message-ID: <003001c13096$14d1b580$579ad6d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] ERIN32 Presentation Date: Wed, 29 Aug 2001 09:22:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C1306C.1596F360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C1306C.1596F360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Juergen Thank you for the questions. Post your mailing address and I will send you a copy of my presention = Handout. Reference your other questions 1. Is the design only relating to SSRAMs with full decoding? Please explain further - I don't understand your question. 2. Maybe it is based on a 24 bit original design? No. The DDP-516 was a 16 bit Minicomputer. The Software = that I am going to capture is written for that processor - all 9,967 = Instructions --------------------this portion is the Language Processor. = A DDP-416, also 16 Bit; was used as a Peripheral Processor. The 416 had a reduced = instruction set. But otherwise identical to the 516. I intend to move Disk = Processing from the Language to the Peripheral. The two will = comunicate with each- other via Interprocessor Interrupt with a Mailbox in Global = Memory. The basic system can service up to 128 User Terminals; = anything=20 more than 128 - will have to communicate via Inter-System = Interrupt. All Hard Disk operations will be handled with one Peripheral = Processor being designated as System Master. He also communicates = with other standard peripheral devices such as, Printers, Modems, FAX, = Real Time Clock, you name it. =20 3. Could you explain why you use a 72 bit design? The 72 Bits are for Instructions and all Data is 32 bit. = Frankly, I pursue all logic design with micropramming in my mind. It = simplifies the design of control functions. For example; the Floating Point = design I worked on at Honeywell Information Systems had a 108 Bit Micro = Instruction. My management never directed me with any constraints - make it = WORK. I DID. In this design I ended up with One Bit for each Class of = Instructions; with a 4-bit Field used for decoding one of 15 possible = instructions. An all zero's fetch is used for the NOP instruction which occupies = program space - but has zero execution time. This will come in = handy later in the program process. You must also understand - there is = basically only one on chip register and that is a 32 Bit Accumulator. I also = have implemented 128 Index Registers - one for each User. I hope they aren't = used as it adds to the execution time. The 18 bits should be used for = all Direct Operations if possible. I also have an Indirect Addressing = Mode. This too will add to execution time. The instruction also contains = four bits to timing - very useful for massage purposes. All direct JMP & JST (jump and store return) instructions = ooccupy program space but have ZERO execution time. There are currently = 2,082 of these out of the 9,967. This will undoubtedly change as I found = several places in the code where Instruction Modification was used, and was = permitted in that period of time. Will also have to consider Data - = will change from two bytes to four bytes. Historically, Registers of varying numbers were added to the = hardware due to the cost of relatively slow Core Memory. I can now = access CMOS memory just as fast as I can an on-chip Register File. And = I can now have thousands of so-called registers. Hope this answers your questions. Don't hesitate to ask more....... Regards Dick Hartney ------=_NextPart_000_002D_01C1306C.1596F360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Juergen
 
Thank you for the = questions.
 
Post your mailing address and I will = send you a=20 copy of my presention Handout.
 
Reference your other = questions
 
        = 1. Is the=20 design only relating to SSRAMs with full decoding?
       =20     Please explain further - I don't understand your=20 question.
 
        = 2. Maybe it=20 is based on a 24 bit original design?
       =20     No.  The DDP-516 was a 16 bit = Minicomputer.  The=20 Software that I am
       =20     going to capture is written for that processor  = - =20 all 9,967 Instructions --------------------this portion is the Language=20 Processor.  A DDP-416, also 16 Bit; was
       =20     used as a Peripheral Processor.  The 416 had a = reduced=20 instruction set.
       =20     But otherwise identical to the 516.  I intend to = move=20 Disk Processing
       =20     from the Language to the Peripheral.  The two = will=20 comunicate with each-
       =20     other via Interprocessor Interrupt with a Mailbox in = Global=20 Memory.
       =20         The basic system can service up to = 128=20 User Terminals; anything
       =20     more than 128 - will have to communicate via = Inter-System=20 Interrupt.
       =20     All Hard Disk operations will be handled with one = Peripheral=20 Processor
       =20     being designated as System Master.  He also = communicates=20 with other
       =20     standard peripheral devices such as, Printers, = Modems, FAX,=20 Real Time
       =20     Clock, you name it.
       =20
        = 3. =20 Could you explain why you use a 72 bit design?
          &nbs= p; The 72=20 Bits are for Instructions and all Data is 32 bit.  Frankly, I=20 pursue
       =20     all logic design with micropramming in my mind.  = It=20 simplifies the design
       =20     of control functions.  For example; the Floating = Point=20 design I worked on
       =20     at Honeywell Information Systems had a 108 Bit Micro=20 Instruction.  My
       =20     management never directed me with any constraints - = make it=20 WORK.
       =20     I DID.
 
       =20     In this design I ended up with One Bit for each Class = of=20 Instructions; with
       =20     a 4-bit Field used for decoding one of 15 possible=20 instructions.  An all
       =20     zero's fetch is used for the NOP instruction which = occupies=20 program
       =20     space - but has zero execution time.  This will = come in=20 handy later in the
       =20     program process.  You must also understand - = there is=20 basically only one
       =20     on chip register and that is a 32 Bit = Accumulator.  I=20 also have implemented
       =20     128 Index Registers - one for each User.  I hope = they=20 aren't used as it
       =20     adds to the execution time. The 18 bits should be = used for=20 all Direct
       =20     Operations if possible.  I also have an Indirect = Addressing Mode.  This too
       =20     will add to execution time.  The instruction = also=20 contains four bits to
       =20     timing - very useful for massage = purposes.
 
       =20     All direct JMP & JST (jump and store return) = instructions=20 ooccupy program
       =20     space but have ZERO execution time.  There are = currently=20 2,082 of these
       =20     out of the 9,967.  This will undoubtedly change = as I=20 found several places
       =20     in the code where Instruction Modification was used, = and was=20 permitted
       =20     in that period of time.  Will also have to = consider Data=20 - will change from
       =20     two bytes to four bytes.
 
       =20     Historically, Registers of varying numbers were added = to the=20 hardware
       =20     due to the cost of relatively slow Core Memory.  = I can=20 now access CMOS
       =20     memory just as fast as I can an on-chip Register = File. =20 And I can now have
       =20     thousands of so-called registers.
 
Hope this answers your questions.  = Don't=20 hesitate to ask more.......
 
Regards
Dick Hartney
------=_NextPart_000_002D_01C1306C.1596F360-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 29 14:14:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cBNX-0006Bx-00 for ; Wed, 29 Aug 2001 21:51:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 21:51:59 +0200 (CEST) Received: (qmail 13023 invoked by uid 0); 29 Aug 2001 17:39:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 29 Aug 2001 17:39:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA25198 for ; Wed, 29 Aug 2001 13:39:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 17:38:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA24717 for f-cpu-list; Wed, 29 Aug 2001 13:38:45 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA24714 for ; Wed, 29 Aug 2001 13:38:44 -0400 Received: from tribble.stud.uni-hannover.de (root@a136.home.uni-hannover.de [130.75.232.136]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7THcT613740 for ; Wed, 29 Aug 2001 13:38:34 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00565; Wed, 29 Aug 2001 14:14:40 +0200 Message-ID: <20010829141439.62122@thrai.stud.uni-hannover.de> Date: Wed, 29 Aug 2001 14:14:39 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Floating-Point References: <0CFA3081B86BD311B37A00902762718F0152F053@po1-exch.lon.tudor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <0CFA3081B86BD311B37A00902762718F0152F053@po1-exch.lon.tudor.com>; from Hans Summers on Wed, Aug 29, 2001 at 09:48:00AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 29, 2001 at 09:48:00AM +0100, Hans Summers wrote: [...] > Previously you insisted on fixed latency. Latency may depend on the chunk (= operand) size, but not on the operands. That is, it is known at *decode time*. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 29 14:11:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cBNY-0006Bx-00 for ; Wed, 29 Aug 2001 21:52:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 21:52:00 +0200 (CEST) Received: (qmail 8928 invoked by uid 0); 29 Aug 2001 17:39:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 29 Aug 2001 17:39:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA25219 for ; Wed, 29 Aug 2001 13:39:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 17:38:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA24774 for f-cpu-list; Wed, 29 Aug 2001 13:38:49 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA24753 for ; Wed, 29 Aug 2001 13:38:48 -0400 Received: from tribble.stud.uni-hannover.de (root@a136.home.uni-hannover.de [130.75.232.136]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7THcj613749 for ; Wed, 29 Aug 2001 13:38:45 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00553; Wed, 29 Aug 2001 14:11:55 +0200 Message-ID: <20010829141155.38820@thrai.stud.uni-hannover.de> Date: Wed, 29 Aug 2001 14:11:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: <3B8BEB63.279A236A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Aug 29, 2001 at 09:48:37AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 29, 2001 at 09:48:37AM +0200, Juergen Goeritz wrote: [...] > I took a look into the links you mailed. Haven't seen much > about a good division though. I will concentrate on the 64 bit > version, because 32bit is derivable from this. I'd rather forget fdiv, for the moment. Concentrate in Level-1 FP, that is: fadd, fsub, fmul, f2int, int2f, fiaprx and fsqrtiaprx (IIRC). fadd/fsub: use my generic adder as the core element and add an "input (de)normalizer" to it. fmul: basically, an unsigned multiplier (like IMU, but without all the bells and whistles like MAC and signed multiplication) for the fractional part, and a small (<= 16-bit) adder for the exponent. fiaprx/fsqrtiaprx: table lookup (8...16 entries) + some easy bit shuffling f2int/int2f: bit shuffling Most units will also need a postprocessor for rounding, range checking and so on. Shouldn't be too hard either (unless you try to be 100% IEEE compliant). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 30 05:20:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cDMb-0000OP-00 for ; Wed, 29 Aug 2001 23:59:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 29 Aug 2001 23:59:09 +0200 (CEST) Received: (qmail 10207 invoked by uid 0); 29 Aug 2001 21:20:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 29 Aug 2001 21:20:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01117 for ; Wed, 29 Aug 2001 17:20:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 21:20:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA00893 for f-cpu-list; Wed, 29 Aug 2001 17:20:25 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA00887 for ; Wed, 29 Aug 2001 17:20:24 -0400 Received: from localhost.localdomain (nas24-223.vlt.club-internet.fr [195.36.223.223]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7TLKM618636 for ; Wed, 29 Aug 2001 17:20:23 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D41411671 for ; Wed, 29 Aug 2001 23:20:41 -0400 (EDT) Message-ID: <3B8DB109.46E8DC7C@ifrance.com> Date: Wed, 29 Aug 2001 23:20:41 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: <3B8BEB63.279A236A@f-cpu.org> <20010829141155.38820@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Don't forget the complet FPU design from opencores.com. It seems to work but very slow. nicO Michael Riepe a écrit : > > On Wed, Aug 29, 2001 at 09:48:37AM +0200, Juergen Goeritz wrote: > [...] > > I took a look into the links you mailed. Haven't seen much > > about a good division though. I will concentrate on the 64 bit > > version, because 32bit is derivable from this. > > I'd rather forget fdiv, for the moment. Concentrate in Level-1 FP, > that is: fadd, fsub, fmul, f2int, int2f, fiaprx and fsqrtiaprx (IIRC). > > fadd/fsub: > use my generic adder as the core element and add an > "input (de)normalizer" to it. > > fmul: > basically, an unsigned multiplier (like IMU, but > without all the bells and whistles like MAC and signed > multiplication) for the fractional part, and a small > (<= 16-bit) adder for the exponent. > > fiaprx/fsqrtiaprx: > table lookup (8...16 entries) + some easy bit shuffling > > f2int/int2f: > bit shuffling > > Most units will also need a postprocessor for rounding, range checking > and so on. Shouldn't be too hard either (unless you try to be 100% > IEEE compliant). > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Aug 29 23:53:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cGzB-0004xj-00 for ; Thu, 30 Aug 2001 03:51:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 30 Aug 2001 03:51:13 +0200 (CEST) Received: (qmail 22175 invoked by uid 0); 29 Aug 2001 21:48:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 29 Aug 2001 21:48:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA01720 for ; Wed, 29 Aug 2001 17:48:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 29 Aug 2001 21:48:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA01470 for f-cpu-list; Wed, 29 Aug 2001 17:48:14 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA01467 for ; Wed, 29 Aug 2001 17:48:12 -0400 Received: from imf10bis.bellsouth.net (mail110.mail.bellsouth.net [205.152.58.50]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7TLmB619512 for ; Wed, 29 Aug 2001 17:48:12 -0400 Received: from computer ([209.215.24.53]) by imf10bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010829214902.ZBJ16648.imf10bis.bellsouth.net@computer>; Wed, 29 Aug 2001 17:49:02 -0400 Message-ID: <002601c130d5$0e31da40$3518d7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] ERIN32 Presentation Date: Wed, 29 Aug 2001 16:53:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C130AB.24154880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C130AB.24154880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeurgen If you have a FAX available - I think I could send the Handout much = cheaper than REGULAR MAIL. For FDIV - look in the Textbook "The Logic of Computer Arithmetic" by = Ivan Flores. The design of both FMUL & FDIV skips strings of ONE's and = Zero's to obtain results. I will use this process. You will also require a = Barrel Shifter that is common for all processes - Normalize & Round. Regards Dick Hartney ------=_NextPart_000_0023_01C130AB.24154880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jeurgen
 
If you have a FAX available - I think I = could send=20 the Handout much cheaper than
REGULAR MAIL.
 
For FDIV - look in the Textbook  = "The Logic of=20 Computer Arithmetic" by Ivan
Flores.  The design of both FMUL = & FDIV=20 skips strings of ONE's and Zero's
to obtain results. I will use this = process. You=20 will also require a Barrel Shifter
that is common for all processes - = Normalize &=20 Round.
 
Regards
Dick Hartney
------=_NextPart_000_0023_01C130AB.24154880-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Thu Aug 30 09:34:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cXkp-0000Ev-01 for ; Thu, 30 Aug 2001 21:45:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 30 Aug 2001 21:45:31 +0200 (CEST) Received: (qmail 10626 invoked by uid 0); 30 Aug 2001 07:34:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 30 Aug 2001 07:34:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA11746 for ; Thu, 30 Aug 2001 03:34:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 30 Aug 2001 07:34:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA11497 for f-cpu-list; Thu, 30 Aug 2001 03:34:30 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA11494 for ; Thu, 30 Aug 2001 03:34:29 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7U7YS626989 for ; Thu, 30 Aug 2001 03:34:28 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id DAA04261 for ; Thu, 30 Aug 2001 03:28:16 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id DAA05128 for ; Thu, 30 Aug 2001 03:34:16 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 08:34:15 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F056@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Re: Floating-Point Date: Thu, 30 Aug 2001 08:34:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > On Wed, Aug 29, 2001 at 09:48:00AM +0100, Hans Summers wrote: > [...] > > Previously you insisted on fixed latency. > > Latency may depend on the chunk (= operand) size, but not on the > operands. That is, it is known at *decode time*. I understand that but previously it was written: > Michael Riepe wrote: > > On Mon, Aug 20, 2001 at 11:33:05PM +0200, Yann Guidon wrote: > > [...] > > > > > If there is something to say if the outed data is > > > > > correct or not ? > > > > Currently not; the scheduler should know. But we can > > > > add a `here is the result, take it or I'll throw it away > > > > in the next cycle' signal. > > > currently, only the IDIV has one. > > No it doesn't, but I can add one :) > > if you use a fixed-latency approach, you don't need one. > however, you could want to "optimise" one day with a data-dependent > algorithm (leading MSB strip, etc...) and as long as the latency is > still higher than the scheduling queue's depth, it is possible to > have _one_ "ready" flag if it can be reased enough in advance. Here we are talking about more than just chunk-size-dependent latency, we are talking about real data-dependent latency right? In this case my alternative scheduler is more suitable: for the time being it can be made fixed latency and still obtain a simpler scheduler with other benefits (e.g. greater maintainability and modularity), and in the future it is easy to move to variable latency data-dependent optimisations without a complete redesign. ------------------ Hans Summers http://www.HansSummers.Com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Aug 30 09:50:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cXkq-0000Ev-00 for ; Thu, 30 Aug 2001 21:45:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 30 Aug 2001 21:45:32 +0200 (CEST) Received: (qmail 2791 invoked by uid 0); 30 Aug 2001 08:07:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 30 Aug 2001 08:07:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA12558 for ; Thu, 30 Aug 2001 04:07:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 30 Aug 2001 08:06:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA12299 for f-cpu-list; Thu, 30 Aug 2001 04:06:41 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA12296 for ; Thu, 30 Aug 2001 04:06:38 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7U86Y627440 for ; Thu, 30 Aug 2001 04:06:37 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15cMah-0004uj-00 for f-cpu@seul.org; Thu, 30 Aug 2001 09:50:19 +0200 Date: Thu, 30 Aug 2001 09:50:19 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP In-Reply-To: <3B8DB109.46E8DC7C@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 29 Aug 2001, nicO wrote: > Don't forget the complet FPU design from opencores.com. It seems to work > but very slow. Have downloaded it, but not yet checked. > > I'd rather forget fdiv, for the moment. Concentrate in Level-1 FP, > > that is: fadd, fsub, fmul, f2int, int2f, fiaprx and fsqrtiaprx (IIRC). > > > > fadd/fsub: > > use my generic adder as the core element and add an > > "input (de)normalizer" to it. Where to find? In the snapshots? > > fmul: > > basically, an unsigned multiplier (like IMU, but > > without all the bells and whistles like MAC and signed > > multiplication) for the fractional part, and a small > > (<= 16-bit) adder for the exponent. Guessed though. But I rather intend to start with a diagram first since the last diagramm from YG gave some aha effects... > > fiaprx/fsqrtiaprx: > > table lookup (8...16 entries) + some easy bit shuffling > > > > f2int/int2f: > > bit shuffling > > > > Most units will also need a postprocessor for rounding, range checking > > and so on. Shouldn't be too hard either (unless you try to be 100% > > IEEE compliant). Hehe, rounding is interesting. Maybe I will add that error tracking we discussed earlier for the 32bit version... Anyway first I have to read what has been stated about fpu functionality in f-cpu documentation. Then propose changes and afterwards implement it. ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 30 14:42:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15cXl8-0000Ev-00 for ; Thu, 30 Aug 2001 21:45:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 30 Aug 2001 21:45:50 +0200 (CEST) Received: (qmail 9466 invoked by uid 0); 30 Aug 2001 16:57:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 30 Aug 2001 16:57:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA26357 for ; Thu, 30 Aug 2001 12:57:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 30 Aug 2001 16:55:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA25844 for f-cpu-list; Thu, 30 Aug 2001 12:55:51 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA25839 for ; Thu, 30 Aug 2001 12:55:49 -0400 Received: from tribble.stud.uni-hannover.de (root@a047.home.uni-hannover.de [130.75.232.47]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7UGtl603338 for ; Thu, 30 Aug 2001 12:55:48 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00470; Thu, 30 Aug 2001 14:42:20 +0200 Message-ID: <20010830144220.12685@thrai.stud.uni-hannover.de> Date: Thu, 30 Aug 2001 14:42:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: <3B8DB109.46E8DC7C@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Thu, Aug 30, 2001 at 09:50:19AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 30, 2001 at 09:50:19AM +0200, Juergen Goeritz wrote: [...] > > > fadd/fsub: > > > use my generic adder as the core element and add an > > > "input (de)normalizer" to it. > > Where to find? In the snapshots? Yes, but that's old code that doesn't synthesize well. I wrote a package for use in the IMU; I can send you a copy. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Aug 31 20:39:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15d8aZ-0007bg-00 for ; Sat, 01 Sep 2001 13:05:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Sep 2001 13:05:23 +0200 (CEST) Received: (qmail 11460 invoked by uid 0); 31 Aug 2001 18:36:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 31 Aug 2001 18:36:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA01147 for ; Fri, 31 Aug 2001 14:36:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 31 Aug 2001 18:34:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA00860 for f-cpu-list; Fri, 31 Aug 2001 14:34:48 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA00857 for ; Fri, 31 Aug 2001 14:34:37 -0400 Received: from imf02bis.bellsouth.net (mail102.mail.bellsouth.net [205.152.58.42]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f7VIYa630151 for ; Fri, 31 Aug 2001 14:34:37 -0400 Received: from computer ([208.60.244.229]) by imf02bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010831183528.RAGE11665.imf02bis.bellsouth.net@computer>; Fri, 31 Aug 2001 14:35:28 -0400 Message-ID: <001801c1324c$5b73bee0$e5f43cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Mailing Address Date: Fri, 31 Aug 2001 13:39:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C13222.5CC86B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C13222.5CC86B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Juergen: Send your mailing address. The stuff I have is too complicated for = my uneducated mind to send it e-mail. Finished the FBC on schedule. Will also send a copy with other. Now = on the last but not least - the CICU (Console Interrupt Control Unit). Not a very complicates design. It works this way. The user = generates three types of information; Keyboard Inputs, Mouse clicks, and = I.D. Card Reader. Any one of these actions will generate a Start Bit (Similar to Modem = Protocol). A free running counter will stop on receipt of coincident with Terminal = Number. The CICU sends a shift clock - gets the next bit; sends another shift = clock, gets the next bit. The first two bits determine which of the = types of interrupt so it knows how many shift clocks to send. On = completion of the shift process, the CICU will send an Interrupt Pulse = to the Language Processor. If the Interrupt Level is not Masked out, = and Interrupts are Enabled, the processor will Break at the Instruction = Fetch. Save what it has too, and Read the word from the CICU. The read = will release the Counter and look for another request. The processor = will interpret what it has received and act according to type. End of = story. Will it work - yes - it is the exact same design we used on Saturn V = Display and Hard Copy System for NASA it 1965 which had 15 Terminals and = a 2 microsecond DDP-224. Also had an FBC with RCA110A interface. Regards; Dick Hartney ------=_NextPart_000_0015_01C13222.5CC86B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Juergen:
 
    Send your mailing = address. =20 The stuff I have is too complicated for my uneducated mind to send it=20 e-mail.
 
    Finished the FBC on = schedule.=20 Will also send a copy with other.  Now on the last but not least - = the CICU=20 (Console Interrupt Control Unit).
 
    Not a very = complicates design.=20 It works this way.  The user generates three types of information; = Keyboard=20 Inputs, Mouse clicks, and I.D. Card Reader.
Any one of these actions will generate = a Start Bit=20 (Similar to Modem Protocol).
A free running counter will stop on = receipt of=20 coincident with Terminal Number.
The CICU sends a shift clock - gets the = next bit;=20 sends another shift clock, gets the next bit.  The first two bits = determine=20 which of the types of interrupt so it knows how many shift clocks to = send. =20 On completion of the shift process, the CICU will send an Interrupt = Pulse to the=20 Language Processor.  If the Interrupt Level is not Masked out, and=20 Interrupts are Enabled, the processor will Break at the Instruction = Fetch. =20 Save what it has too, and Read the word from the CICU.  The read = will=20 release the Counter and look for another request.  The processor = will=20 interpret what it has received and act according to type.  End of=20 story.
 
    Will it work - yes - = it is the=20 exact same design we used on Saturn V Display and Hard Copy System for = NASA it=20 1965 which had 15 Terminals and a 2 microsecond
DDP-224.  Also had an FBC with = RCA110A=20 interface.
 
 
Regards;
Dick Hartney
------=_NextPart_000_0015_01C13222.5CC86B80-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 1 20:11:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15dK4B-00048i-00 for ; Sun, 02 Sep 2001 01:20:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Sep 2001 01:20:43 +0200 (CEST) Received: (qmail 6831 invoked by uid 0); 1 Sep 2001 18:12:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 1 Sep 2001 18:12:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA25339 for ; Sat, 1 Sep 2001 14:12:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Sep 2001 18:11:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA24416 for f-cpu-list; Sat, 1 Sep 2001 14:11:19 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA24395 for ; Sat, 1 Sep 2001 14:11:17 -0400 Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f81IBH611369 for ; Sat, 1 Sep 2001 14:11:17 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA07491 for f-cpu@seul.org; Sat, 1 Sep 2001 20:11:16 +0200 (MET DST) Date: Sat, 1 Sep 2001 20:11:16 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] new snapshot X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id OAA24396 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, http://f-cpu.seul.org/new/snapshot_yg_9-1-2001.tgz is my latest snapshot. comments welcome. read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 1 21:08:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15dK4C-00048i-01 for ; Sun, 02 Sep 2001 01:20:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Sep 2001 01:20:44 +0200 (CEST) Received: (qmail 816 invoked by uid 0); 1 Sep 2001 19:08:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 1 Sep 2001 19:08:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA26080 for ; Sat, 1 Sep 2001 15:08:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Sep 2001 19:08:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA25819 for f-cpu-list; Sat, 1 Sep 2001 15:08:32 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA25816 for ; Sat, 1 Sep 2001 15:08:31 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f81J8U612148 for ; Sat, 1 Sep 2001 15:08:30 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA27099; Sat, 1 Sep 2001 21:08:28 +0200 (MET DST) Date: Sat, 1 Sep 2001 21:08:28 +0200 (MET DST) From: whygee@club-internet.fr To: goeritz@oekomm.de Cc: f-cpu@seul.org Subject: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id PAA25817 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: Juergen Goeritz >Hi Yann, > >soon I will write a project summary for my new cluster >architecture. It would be great to include the f-cpu as >central vector processor into this new SOC design. SoC ? :-)) >Do I have the agreement with the f-cpu team to use the >f-cpu in my design and try to go for funding from germany >and/or EU? If yes, do you have a short summary of f-cpu >that can be used and included into the overall project >summary? Basically I have to decide now whether to >include the f-cpu into the application request for >funding or not. Your okay is necessary to include it. i will repeat it again : my name is NOT F-CPU :-) just ask on the mailing list. i believe that others will be pleased to help. Concerning the description, there are several documents out there, download the CVS tarball with the documentation and the websites. A french "brochure" is available but a translation will be needed. Also, external papers have been written by me and others : Andreas from http://www.gaos.org/ has written a german introduction paper. I think that it is on the GAOS CVS. Any help from the F-CPUers welcome :-) >My best regards good luck and keep in touch, >JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 1 21:27:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15dK4D-00048i-00 for ; Sun, 02 Sep 2001 01:20:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Sep 2001 01:20:45 +0200 (CEST) Received: (qmail 2787 invoked by uid 0); 1 Sep 2001 19:28:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 1 Sep 2001 19:28:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA26436 for ; Sat, 1 Sep 2001 15:28:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Sep 2001 19:27:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA26188 for f-cpu-list; Sat, 1 Sep 2001 15:27:45 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA26185 for ; Sat, 1 Sep 2001 15:27:44 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f81JRh612301 for ; Sat, 1 Sep 2001 15:27:43 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA03346 for f-cpu@seul.org; Sat, 1 Sep 2001 21:27:42 +0200 (MET DST) Date: Sat, 1 Sep 2001 21:27:42 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] YG's electronic postcard from under Heathrow X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id PAA26186 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! so yes Graham has finally setup an account for me on his computer so i can access (with difficulties) my email. I did not expect Heathrow to be so ... close, but i can cope with it. I lived close to a railway ten years ago. But the good side is that Graham's personal library contains all the books required to prepare the coming year at the university :-) so don't worry for me. And if i EVER get bored, i have brought my laptop and i can play Tetris on xemacs. i got up to 2980 yesterday. I'll check my mail every few days. i'm now working on VHDL and package stuffs. being far from emails boosts my productivity :-) read you soon, YG (ohoh, i'm an alien, i'm a legal alien, i'm a frenchman in London) (adapted from Sting) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 2 00:28:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15dK4I-00048i-01 for ; Sun, 02 Sep 2001 01:20:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Sep 2001 01:20:50 +0200 (CEST) Received: (qmail 23070 invoked by uid 0); 1 Sep 2001 22:28:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 1 Sep 2001 22:28:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA30268 for ; Sat, 1 Sep 2001 18:28:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Sep 2001 22:27:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA30018 for f-cpu-list; Sat, 1 Sep 2001 18:27:56 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA30001 for ; Sat, 1 Sep 2001 18:27:55 -0400 Received: from tribble.stud.uni-hannover.de (michael@a118.home.uni-hannover.de [130.75.232.118]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f81MRq615194 for ; Sat, 1 Sep 2001 18:27:53 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA13525; Sun, 2 Sep 2001 00:28:05 +0200 Message-ID: <20010902002805.06922@thrai.stud.uni-hannover.de> Date: Sun, 2 Sep 2001 00:28:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Sat, Sep 01, 2001 at 09:08:28PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 01, 2001 at 09:08:28PM +0200, whygee@club-internet.fr wrote: > >De: Juergen Goeritz [...] > >Do I have the agreement with the f-cpu team to use the > >f-cpu in my design and try to go for funding from germany > >and/or EU? If yes, do you have a short summary of f-cpu > >that can be used and included into the overall project > >summary? Basically I have to decide now whether to > >include the f-cpu into the application request for > >funding or not. Your okay is necessary to include it. Wait a minute, Jürgen... you want to do WHAT? Precisely, please. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sun Sep 2 19:42:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15deCX-0005AF-00 for ; Sun, 02 Sep 2001 22:50:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Sep 2001 22:50:41 +0200 (CEST) Received: (qmail 10958 invoked by uid 0); 2 Sep 2001 17:43:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx22) with SMTP; 2 Sep 2001 17:43:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA13322 for ; Sun, 2 Sep 2001 13:43:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Sep 2001 17:42:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA13099 for f-cpu-list; Sun, 2 Sep 2001 13:42:42 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA13096 for ; Sun, 2 Sep 2001 13:42:41 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f82Hge632430 for ; Sun, 2 Sep 2001 13:42:41 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id TAA08844 for f-cpu@seul.org; Sun, 2 Sep 2001 19:42:39 +0200 (MET DST) Date: Sun, 2 Sep 2001 19:42:39 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id NAA13097 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, De: Michael Riepe >On Sat, Sep 01, 2001 at 09:08:28PM +0200, whygee@club-internet.fr wrote: > >> >De: Juergen Goeritz >[...] >> >Do I have the agreement with the f-cpu team to use the >> >f-cpu in my design and try to go for funding from germany >> >and/or EU? If yes, do you have a short summary of f-cpu >> >that can be used and included into the overall project >> >summary? Basically I have to decide now whether to >> >include the f-cpu into the application request for >> >funding or not. Your okay is necessary to include it. > >Wait a minute, Jürgen... you want to do WHAT? >Precisely, please. Juergen has sent me a text file but i can't manage them in my current environment. I will let Juergen explain his view better than me, after all it's his idea. You know, if one uses F-CPU for feeding cattle or anything, i don't mind. It makes no difference. Where Juergen's project concerns us is : we will have to work together. There is currently no "organisation" so it is going to be slow/difficult. This is the only problem. As I will study this year, it will be even more difficult for me to care of the project. Next year will be a better time for me (if i can find a nice and paid job). ok, have a nice day, > Michael "Tired" Riepe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 3 09:24:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3L3-0002P5-00 for ; Tue, 04 Sep 2001 01:41:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:09 +0200 (CEST) Received: (qmail 8100 invoked by uid 0); 3 Sep 2001 09:17:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 3 Sep 2001 09:17:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA22339 for ; Mon, 3 Sep 2001 05:17:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 09:16:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA21838 for f-cpu-list; Mon, 3 Sep 2001 05:16:59 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA21835 for ; Mon, 3 Sep 2001 05:16:58 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f839Gv611549 for ; Mon, 3 Sep 2001 05:16:57 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15do5n-0007HT-00; Mon, 3 Sep 2001 09:24:23 +0200 Date: Mon, 3 Sep 2001 09:24:23 +0200 (MEST) From: Juergen Goeritz To: RHARTNEY@bellsouth.net cc: f-cpu@seul.org Subject: Re: [f-cpu] Mailing Address In-Reply-To: <001801c1324c$5b73bee0$e5f43cd0@computer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi Richard, why are you always answering to f-cpu mailing list when I send my emails to you directly? The f-cpu list is not the right place for your design discussion. JG On Fri, 31 Aug 2001, Richard E. Hartny wrote: > Hi Juergen: > > Send your mailing address. The stuff I have is too complicated for my uneducated mind to send it e-mail. > ... rest deleted ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 3 09:10:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3L3-0002P5-01 for ; Tue, 04 Sep 2001 01:41:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:09 +0200 (CEST) Received: (qmail 31164 invoked by uid 0); 3 Sep 2001 09:17:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 3 Sep 2001 09:17:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA22342 for ; Mon, 3 Sep 2001 05:17:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 09:17:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA21914 for f-cpu-list; Mon, 3 Sep 2001 05:17:12 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA21904 for ; Mon, 3 Sep 2001 05:17:10 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f839H9611560 for ; Mon, 3 Sep 2001 05:17:09 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15dnsJ-0007HQ-00 for f-cpu@seul.org; Mon, 3 Sep 2001 09:10:27 +0200 Date: Mon, 3 Sep 2001 09:10:27 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010902002805.06922@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id FAA21905 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 2 Sep 2001, Michael Riepe wrote: > On Sat, Sep 01, 2001 at 09:08:28PM +0200, whygee@club-internet.fr wrote: > > > >De: Juergen Goeritz > [...] > > >Do I have the agreement with the f-cpu team to use the > > >f-cpu in my design and try to go for funding from germany > > >and/or EU? If yes, do you have a short summary of f-cpu > > >that can be used and included into the overall project > > >summary? Basically I have to decide now whether to > > >include the f-cpu into the application request for > > >funding or not. Your okay is necessary to include it. > > Wait a minute, Jürgen... you want to do WHAT? > Precisely, please. Long story... To make it short some headlines only - new architecture for cluster computing - want to go for EU or german funding for this project - performant user processor still to be decided on (may be either a LEON extended to 64bit or F-CPU or other 64bit architecture that can be used for embedded) - system on chip design already specified - team to be built for realization - drawback: new architecture is not built as open source... I like f-cpu because it is extendable to higher bitwidth later on and seems to be designed for low gate count. So what's the basic feeling of you people involved in f-cpu design and simulation to include f-cpu into a system? I am interested in your views very much. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 3 14:46:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3L8-0002P5-00 for ; Tue, 04 Sep 2001 01:41:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:14 +0200 (CEST) Received: (qmail 4719 invoked by uid 0); 3 Sep 2001 16:06:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 3 Sep 2001 16:06:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA26120 for ; Mon, 3 Sep 2001 12:06:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 16:06:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA25773 for f-cpu-list; Mon, 3 Sep 2001 12:06:06 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA25760 for ; Mon, 3 Sep 2001 12:06:04 -0400 Received: from tribble.stud.uni-hannover.de (root@a225.home.uni-hannover.de [130.75.232.225]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83G5u618625 for ; Mon, 3 Sep 2001 12:06:02 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00604; Mon, 3 Sep 2001 14:46:23 +0200 Message-ID: <20010903144623.17602@thrai.stud.uni-hannover.de> Date: Mon, 3 Sep 2001 14:46:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010902002805.06922@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Sep 03, 2001 at 09:10:27AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 03, 2001 at 09:10:27AM +0200, Juergen Goeritz wrote: [...] > Long story... To make it short some headlines only - > new architecture for cluster computing - want to go for > EU or german funding for this project - performant user > processor still to be decided on (may be either a LEON > extended to 64bit or F-CPU or other 64bit architecture > that can be used for embedded) - system on chip design > already specified - team to be built for realization - > drawback: new architecture is not built as open source... If you make a SoC that includes an F-CPU core, the source code for the entire chip must be released under the terms of the GPL because it's a derived work. If you can live with that restriction... > I like f-cpu because it is extendable to higher bitwidth > later on and seems to be designed for low gate count. *giggle* didn't you see the multiplier? > So what's the basic feeling of you people involved in > f-cpu design and simulation to include f-cpu into a > system? I am interested in your views very much. Do you want only the design for your project, or the design team as well? You can do with the design whatever you like, as long as you follow the rules. But isn't it a bit too early? We're still in the first of many implementation phases, and we can give no guarantees that the F-CPU will be finished some day, that it will perform well, or work at all. If you rely on that, your project may fail. CU, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 3 17:33:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3L9-0002P5-00 for ; Tue, 04 Sep 2001 01:41:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:15 +0200 (CEST) Received: (qmail 14806 invoked by uid 0); 3 Sep 2001 16:06:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 3 Sep 2001 16:06:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA26170 for ; Mon, 3 Sep 2001 12:06:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 16:05:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA25652 for f-cpu-list; Mon, 3 Sep 2001 12:05:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA25649 for ; Mon, 3 Sep 2001 12:05:51 -0400 Received: from tribble.stud.uni-hannover.de (root@a225.home.uni-hannover.de [130.75.232.225]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83G56618603 for ; Mon, 3 Sep 2001 12:05:11 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01151; Mon, 3 Sep 2001 17:33:23 +0200 Message-ID: <20010903173323.64816@thrai.stud.uni-hannover.de> Date: Mon, 3 Sep 2001 17:33:23 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] More Dark and Dusty Corners Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! Again, some ambiguities crossed my way. This time it's all about user/supervisor mode, context switching, SRB, nested interrupts and so on. I hope it's not too confusing; this is rather complex stuff that isn't easily groked at the first glance (I'm not quite sure whether *I* grok everything -- and I may have overlooked some important details). First of all, how do we detect supervisor mode? I guess there should be a special register indicating the current privilege level. Bit 0 will be the `supervisor' bit, all other bits are reserved and must be zero (we can later refine the model to include specific privileges, similar to capabilities in the linux kernel). When doing a context switch, the `privilege' SR should be loaded from the new CMB before any other operation is performed. Remember that the F-CPU might be interrupted in supervisor mode, and must be able to return to that mode when `rfe' is executed. Apropos `rfe'/interrupts: something that is not clear yet is what happens when the F-CPU is interrupted. Is it supposed to perform a full context switch in all cases? That might be overkill in some situations, especially when the interrupt handler is short. What happens if the IRQ handler reaches the final `rfe' before the SRB is finished? According to the manual, the running SRB must finish before a new one can be started, but that's not appropriate -- why finish something you have to undo anyway? Another problem is nested interrupts. When each interrupt (or exception) causes a context switch, we need a CMB stack -- on the second interrupt, the context of the first IRQ handler must be saved, and it must be properly restored when the "inner" handler returns. If we don't permit an IRQ to interrupt its own handler (that is, block it until the corresponding `rfe'), we may get away with one CMB per possible IRQ/exception, but that's already a whole lot of CMBs. Oh by the way: we need an `interrupt enable' SR, too. There are several instructions which cause a user/supervisor mode transition and/or a context switch: `syscall'/`trap', `rfe' and `halt'. `rfe' is supposed to undo the effects of `syscall'/`trap' as well as those of an IRQ or exception; that means it needs to know *what* to undo if syscall, IRQs and exceptions act differently. This information must be saved somewhere, and must not be overwritten when a nested interrupt returns (that means we need an "invocation stack" here, too). One question is what to do when an IRQ/exception/syscall/rfe occurs. Always switching contexts is too expensive, IMHO. Switching only under certain conditions makes `rfe' a very complex task (similar to `iret' on Intel CPUs, which is a real nightmare). On the other hand, we have to save and restore certain items -- return address, privileges, interrupt mask, maybe the contents of other special registers -- in order to be able to return to the original state. And we *may* want to preload some special registers when entering supervisor mode in order to put the CPU into a defined state. But shall we really preload the general registers >from memory when an interrupt occurs, and save them before we return to the interrupted task? Or discard their contents when `rfe' is executed? IMHO, we should leave that decision to the programmer. Whether or not we do a full context switch on each IRQ/exception, we always need a kind of "invocation stack" in order to handle nested interrupts properly. If we change CMBs, there must be at least one CMB pointer for each possible interrupt source (assuming an interrupt never interrupts its own handler, which may not be possible for some exceptions), or a stack of CMBs. If we don't, we need at least some space for the return address, privileges, and interrupt mask of the interrupted program, plus pointers to the current and last "invocation records" for `rfe'. I'd better stop now before my head starts spinning ;) But that doesn't mean that this topic is dead and buried now, not at all. CU, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Sep 4 02:22:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3LA-0002P5-01 for ; Tue, 04 Sep 2001 01:41:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:16 +0200 (CEST) Received: (qmail 8617 invoked by uid 0); 3 Sep 2001 18:12:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 3 Sep 2001 18:12:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA27973 for ; Mon, 3 Sep 2001 14:12:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 18:12:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA27711 for f-cpu-list; Mon, 3 Sep 2001 14:12:31 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA27708 for ; Mon, 3 Sep 2001 14:12:30 -0400 Received: from localhost.localdomain (nas5-28.vlt.club-internet.fr [194.158.107.28]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83ICM621924 for ; Mon, 3 Sep 2001 14:12:22 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 04C7A161F for ; Mon, 3 Sep 2001 20:22:52 -0400 (EDT) Message-ID: <3B941EDC.DF576A54@ifrance.com> Date: Mon, 03 Sep 2001 20:22:52 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: <20010903173323.64816@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > Hi! > > Again, some ambiguities crossed my way. This time it's all about > user/supervisor mode, context switching, SRB, nested interrupts and so on. > I hope it's not too confusing; this is rather complex stuff that isn't > easily groked at the first glance (I'm not quite sure whether *I* grok > everything -- and I may have overlooked some important details). > > First of all, how do we detect supervisor mode? I guess there should be > a special register indicating the current privilege level. Bit 0 will > be the `supervisor' bit, all other bits are reserved and must be zero > (we can later refine the model to include specific privileges, similar > to capabilities in the linux kernel). Nice idea the capabilities ! It look like new protection scheme from new designed OS. But do you want to detect the mode by software or you speak from the hardware point of view ? I don't like the idea that a software could check in wich state it's. I imagine software like Plex86 that emulate in parrallele many cpus. So if a soft could see a difference it could have some problem. If there is nothing to see if a priviledged instruction is send during a user mode a trap occur and the kernel could 'emulate' the good behavior. > > When doing a context switch, the `privilege' SR should be loaded from > the new CMB before any other operation is performed. Remember that > the F-CPU might be interrupted in supervisor mode, and must be able to > return to that mode when `rfe' is executed. > ??? During an interrupt the cpu switch to priviledge mode and then the kernel do what i want. But the some trap could stay in user land to handel some error (div by zero,...). > A propos `rfe'/interrupts: something that is not clear yet is what > happens when the F-CPU is interrupted. Is it supposed to perform > a full context switch in all cases? That might be overkill in some > situations, especially when the interrupt handler is short. What happens > if the IRQ handler reaches the final `rfe' before the SRB is finished? It freeze the code ! > According to the manual, the running SRB must finish before a new one > can be started, but that's not appropriate -- why finish something you > have to undo anyway? I don't think that you're supposed to come back to the same program after an interrupt, the kernel should choose. Maybe we can implement such fast interrupt with shadow register (like ARM does). Instead of saving the regiter bank, you just switch the bank (maybe we don't need a complete new 64 registers set). But then you could have many problems with the implementation of a preemptive system (allowing an interrupt to interrupt an other interrupt). Because, then you should save 2 register sets ! > > Another problem is nested interrupts. When each interrupt (or exception) > causes a context switch, we need a CMB stack -- on the second interrupt, > the context of the first IRQ handler must be saved, and it must be > properly restored when the "inner" handler returns. If we don't > permit an IRQ to interrupt its own handler (that is, block it until > the corresponding `rfe'), we may get away with one CMB per possible > IRQ/exception, but that's already a whole lot of CMBs. Oh by the way: > we need an `interrupt enable' SR, too. > That's the difference between instrerrupt enable and interrupt mask (which leaves the interrupt pending until the rfe). In fact, the first thing that the kernel should do is to prepare a new pointer to a CMB and then renable the interrupt. In fact, it's the common problem with every cpu. > There are several instructions which cause a user/supervisor mode > transition and/or a context switch: `syscall'/`trap', `rfe' and `halt'. > `rfe' is supposed to undo the effects of `syscall'/`trap' as well as > those of an IRQ or exception; that means it needs to know *what* to > undo if syscall, IRQs and exceptions act differently. This information > must be saved somewhere, and must not be overwritten when a nested > interrupt returns (that means we need an "invocation stack" here, too). > > One question is what to do when an IRQ/exception/syscall/rfe occurs. > Always switching contexts is too expensive, IMHO. Switching only under > certain conditions makes `rfe' a very complex task (similar to `iret' > on Intel CPUs, which is a real nightmare). On the other hand, we have to > save and restore certain items -- return address, privileges, interrupt > mask, maybe the contents of other special registers -- in order to be > able to return to the original state. And we *may* want to preload some > special registers when entering supervisor mode in order to put the CPU > into a defined state. But shall we really preload the general registers > from memory when an interrupt occurs, and save them before we return to > the interrupted task? Or discard their contents when `rfe' is executed? > IMHO, we should leave that decision to the programmer. > > Whether or not we do a full context switch on each IRQ/exception, > we always need a kind of "invocation stack" in order to handle nested > interrupts properly. If we change CMBs, there must be at least one > CMB pointer for each possible interrupt source (assuming an interrupt > never interrupts its own handler, which may not be possible for some > exceptions), or a stack of CMBs. If we don't, we need at least some space > for the return address, privileges, and interrupt mask of the interrupted > program, plus pointers to the current and last "invocation records" for > `rfe'. > > I'd better stop now before my head starts spinning ;) But that > doesn't mean that this topic is dead and buried now, not at all. > The only thing that we could add is that the SRB could be down in 'advance' to gain a lot of time with a shadow register bank. Imagine that the rtc (real time clock) interrupt is control with a different mecanism : maybe we could gain the transfert of the CMB (during the tranfert, the cpu continue to work with the previous work). But it's hard to find the same trick for common interrupt. nicO > CU, > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Sep 3 22:47:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3LG-0002P5-00 for ; Tue, 04 Sep 2001 01:41:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:22 +0200 (CEST) Received: (qmail 307 invoked by uid 0); 3 Sep 2001 20:47:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 3 Sep 2001 20:47:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA02180 for ; Mon, 3 Sep 2001 16:47:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 20:47:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA01931 for f-cpu-list; Mon, 3 Sep 2001 16:47:10 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA01928 for ; Mon, 3 Sep 2001 16:47:09 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83Kl9626082 for ; Mon, 3 Sep 2001 16:47:09 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA03989 for f-cpu@seul.org; Mon, 3 Sep 2001 22:47:04 +0200 (MET DST) Date: Mon, 3 Sep 2001 22:47:04 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] Simili works under Linux ! X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id QAA01929 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i have put a new snapshot at the usual place : http://f-cpu.seul.org/new I now run Simili with wine because Vanilla doesn't understand the "impure" stuff in the ROP2 testbench. Please verify that the ROP2 behaviour is exactly what is expected. Btw, i still have problems with the register set clocking. Any help ? @+ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Sep 3 22:55:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3LG-0002P5-01 for ; Tue, 04 Sep 2001 01:41:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:22 +0200 (CEST) Received: (qmail 18137 invoked by uid 0); 3 Sep 2001 20:56:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 3 Sep 2001 20:56:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA02494 for ; Mon, 3 Sep 2001 16:56:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 20:55:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA02244 for f-cpu-list; Mon, 3 Sep 2001 16:55:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA02241 for ; Mon, 3 Sep 2001 16:55:52 -0400 Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83Ktp626270 for ; Mon, 3 Sep 2001 16:55:51 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA09409 for f-cpu@seul.org; Mon, 3 Sep 2001 22:55:47 +0200 (MET DST) Date: Mon, 3 Sep 2001 22:55:47 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id QAA02242 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N To make things short, Linux kernel = LEON (which is not a truely "free" CPU btw) Hurd kernel = F-CPU (which is not finished btw). Last btw : Industry means risk. * If you take the risk of using LEON, you can remain stuck with the SPARC problems for a long, long while, and SPARC is a 20-year old architecture which doesn't compete well newer cores like SH-5 for example.* If you take the risk to use F-CPU, your future is bright and clear, if it arrives. At least not before 2 years. OK, now i'm trying to finish one of Graham's books on IC design... Read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Sep 4 06:37:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3LH-0002P5-01 for ; Tue, 04 Sep 2001 01:41:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:23 +0200 (CEST) Received: (qmail 15618 invoked by uid 0); 3 Sep 2001 22:27:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 3 Sep 2001 22:27:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA03593 for ; Mon, 3 Sep 2001 18:27:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 22:26:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA03345 for f-cpu-list; Mon, 3 Sep 2001 18:26:48 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA03342 for ; Mon, 3 Sep 2001 18:26:47 -0400 Received: from localhost.localdomain (nas25-220.vlt.club-internet.fr [195.36.224.220]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83MQh628075 for ; Mon, 3 Sep 2001 18:26:43 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C8E7D1671 for ; Tue, 4 Sep 2001 00:37:12 -0400 (EDT) Message-ID: <3B945A78.4022C01C@ifrance.com> Date: Tue, 04 Sep 2001 00:37:12 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr a écrit : > > To make things short, > Linux kernel = LEON (which is not a truely "free" CPU btw) > Hurd kernel = F-CPU (which is not finished btw). Hurd is based on Mach. Mach has been designed in 1989... > Last btw : Industry means risk. > * If you take the risk of using LEON, you can remain stuck > with the SPARC problems for a long, long while, and SPARC > is a 20-year old architecture which doesn't compete well newer > cores like SH-5 for example.* If you take the risk to use F-CPU, your future is bright and > clear, if it arrives. At least not before 2 years. > > OK, now i'm trying to finish one of Graham's books on IC design... > Read you soon, > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 01:22:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e3LN-0002P5-00 for ; Tue, 04 Sep 2001 01:41:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 01:41:29 +0200 (CEST) Received: (qmail 30447 invoked by uid 0); 3 Sep 2001 23:23:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 3 Sep 2001 23:23:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA06929 for ; Mon, 3 Sep 2001 19:23:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Sep 2001 23:23:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA06704 for f-cpu-list; Mon, 3 Sep 2001 19:23:24 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA06701 for ; Mon, 3 Sep 2001 19:23:23 -0400 Received: from tribble.stud.uni-hannover.de (root@a177.home.uni-hannover.de [130.75.232.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f83NNJ629431 for ; Mon, 3 Sep 2001 19:23:19 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03341; Tue, 4 Sep 2001 01:22:00 +0200 Message-ID: <20010904012200.10406@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 01:22:00 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: <20010903173323.64816@thrai.stud.uni-hannover.de> <3B941EDC.DF576A54@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B941EDC.DF576A54@ifrance.com>; from nicO on Mon, Sep 03, 2001 at 08:22:52PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 03, 2001 at 08:22:52PM -0400, nicO wrote: [...] > > First of all, how do we detect supervisor mode? I guess there should be > > a special register indicating the current privilege level. Bit 0 will > > be the `supervisor' bit, all other bits are reserved and must be zero > > (we can later refine the model to include specific privileges, similar > > to capabilities in the linux kernel). > > Nice idea the capabilities ! It look like new protection scheme from new > designed OS. > > But do you want to detect the mode by software or you speak from the > hardware point of view ? [...] I said "register", so I guess I meant hardware ;) Whether user mode programs are allowed to read that register is currently unspecified. > > When doing a context switch, the `privilege' SR should be loaded from > > the new CMB before any other operation is performed. Remember that > > the F-CPU might be interrupted in supervisor mode, and must be able to > > return to that mode when `rfe' is executed. > > > > ??? During an interrupt the cpu switch to priviledge mode and then the > kernel do what i want. > But the some trap could stay in user land to handel some error (div by > zero,...). I'm not in OS/Software land here either... The CPU simply must know where it came from, in order to return properly. That in turn means it has to save a certain amount of state, including the priviledge mode SR, automatically (that is, in hardware). > > A propos `rfe'/interrupts: something that is not clear yet is what > > happens when the F-CPU is interrupted. Is it supposed to perform > > a full context switch in all cases? That might be overkill in some > > situations, especially when the interrupt handler is short. What happens > > if the IRQ handler reaches the final `rfe' before the SRB is finished? > > It freeze the code ! That's what I was afraid of. > > According to the manual, the running SRB must finish before a new one > > can be started, but that's not appropriate -- why finish something you > > have to undo anyway? > > I don't think that you're supposed to come back to the same program > after an interrupt, the kernel should choose. You don't call the scheduler on every interrupt. Linux only calls it when the current process runs out of fuel (timeslice is over), or when another process is woken up (or created) that probably has a higher priority. And a timeslice is rather long -- 20 ticks IIRC (that's 2 seconds). Most interrupts are handled on-the-fly, without switching to kernel mode. They do their (short) work and then return to the interrupted process. You would lose too much time otherwise. > Maybe we can implement such fast interrupt with shadow register (like > ARM does). Instead of saving the regiter bank, you just switch the bank > (maybe we don't need a complete new 64 registers set). But then you > could have many problems with the implementation of a preemptive system > (allowing an interrupt to interrupt an other interrupt). Because, then > you should save 2 register sets ! We have that nasty nested interrupt problem anyway. > > > > Another problem is nested interrupts. When each interrupt (or exception) > > causes a context switch, we need a CMB stack -- on the second interrupt, > > the context of the first IRQ handler must be saved, and it must be > > properly restored when the "inner" handler returns. If we don't > > permit an IRQ to interrupt its own handler (that is, block it until > > the corresponding `rfe'), we may get away with one CMB per possible > > IRQ/exception, but that's already a whole lot of CMBs. Oh by the way: > > we need an `interrupt enable' SR, too. > > > > That's the difference between instrerrupt enable and interrupt mask > (which leaves the interrupt pending until the rfe). In fact, the first > thing that the kernel should do is to prepare a new pointer to a CMB and > then renable the interrupt. In fact, it's the common problem with every > cpu. What about exceptions? You can't turn them off like interrupts. An interrupt/exception handler may trigger an exception, and there may be interrupts while an exception handler is executed. You can't avoid the nesting, and software may not always be fast enough to prepare a new CMB pointer before the next interrupt/exception occurs. Linux uses CMBs (or Task State Segments, or struct task_struct, or whatever) only for user tasks, and it only does a context switch (save/reload all registers) when switching from one task to another, because that's faster. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Tue Sep 4 05:45:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15e7rZ-0006ek-00 for ; Tue, 04 Sep 2001 06:31:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 06:31:01 +0200 (CEST) Received: (qmail 23524 invoked by uid 0); 4 Sep 2001 03:45:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 4 Sep 2001 03:45:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id XAA13830 for ; Mon, 3 Sep 2001 23:45:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 03:43:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id XAA13535 for f-cpu-list; Mon, 3 Sep 2001 23:43:37 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id XAA13532 for ; Mon, 3 Sep 2001 23:43:34 -0400 Received: from online.ln.cn ([202.96.74.86]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f843hT600337 for ; Mon, 3 Sep 2001 23:43:31 -0400 Message-Id: <200109040343.f843hT600337@moria.mit.edu> Received: from there([61.176.53.41]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm03b949e4f; Tue, 04 Sep 2001 11:38:37 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description Date: Tue, 4 Sep 2001 11:45:06 +0800 X-Mailer: KMail [version 1.3.1] References: <3B945A78.4022C01C@ifrance.com> In-Reply-To: <3B945A78.4022C01C@ifrance.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id XAA13533 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001 12:37, you wrote: > whygee@club-internet.fr a écrit : > > > > To make things short, > > Linux kernel = LEON (which is not a truely "free" CPU btw) > > Hurd kernel = F-CPU (which is not finished btw). > > Hurd is based on Mach. Mach has been designed in 1989... But can / has been easily (using a loose definition of easy) ported to other microkernels such as OSkit (sort of done - some hackers have it working on their systems, but us non-hackers who rely on installing .debs are still using the Mach version) or L4 (they talk about this occasionally). -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.gnu.org / http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- If you give an infinite number of monkeys an infinite number of keyboards... ... Hey! That's the internet!!! -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Tue Sep 4 08:38:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eC4L-0006BO-01 for ; Tue, 04 Sep 2001 11:00:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 11:00:29 +0200 (CEST) Received: (qmail 3739 invoked by uid 0); 4 Sep 2001 06:40:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 4 Sep 2001 06:40:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA17169 for ; Tue, 4 Sep 2001 02:40:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 06:39:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA16908 for f-cpu-list; Tue, 4 Sep 2001 02:39:15 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA16905 for ; Tue, 4 Sep 2001 02:39:14 -0400 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f846dD603092 for ; Tue, 4 Sep 2001 02:39:14 -0400 Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.de with smtp id 15e9rc-00010x-03; Tue, 04 Sep 2001 08:39:12 +0200 Received: from (0893089296-0001@[62.153.23.241]) by fwd06.sul.t-online.com with smtp id 15e9rN-1PuyUSC; Tue, 4 Sep 2001 08:38:57 +0200 From: Thilo.Reichelt@t-online.de (Reichelt) To: f-cpu@seul.org References: <20010903173323.64816@thrai.stud.uni-hannover.de> <3B941EDC.DF576A54@ifrance.com> <20010904012200.10406@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] More Dark and Dusty Corners X-Mailer: T-Online eMail 2.34 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Tue, 4 Sep 2001 08:38:57 +0200 Message-ID: <15e9rN-1PuyUSC@fwd06.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe schrieb: > On Mon, Sep 03, 2001 at 08:22:52PM -0400, nicO wrote: > [...] > > > First of all, how do we detect supervisor mode? I guess there should be > > > a special register indicating the current privilege level. Bit 0 will > > > be the `supervisor' bit, all other bits are reserved and must be zero > > > (we can later refine the model to include specific privileges, similar > > > to capabilities in the linux kernel). > > > > Nice idea the capabilities ! It look like new protection scheme from new > > designed OS. > > > > But do you want to detect the mode by software or you speak from the > > hardware point of view ? [...] > > I said "register", so I guess I meant hardware ;) Whether user mode > programs are allowed to read that register is currently unspecified. NO they should NOT be allowed to read that register. If a user mode program has a way of getting information about the internal state of the CPU, you can not do fast virtual machines. Any instruction which reveals whether its user mode or supervisor mode MUST trap while in user mode. A virtual machine works by keeping the CPU in user mode while sometimes tricking it into believing it is in supervisor mode. Instructions which would blow the masquerade are handle in the trap handler. Thilo Reichelt ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 09:50:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eC4N-0006BO-00 for ; Tue, 04 Sep 2001 11:00:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 11:00:31 +0200 (CEST) Received: (qmail 8733 invoked by uid 0); 4 Sep 2001 07:50:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 4 Sep 2001 07:50:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA18576 for ; Tue, 4 Sep 2001 03:50:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 07:49:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA17917 for f-cpu-list; Tue, 4 Sep 2001 03:49:11 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA17914 for ; Tue, 4 Sep 2001 03:49:10 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f847n9603421 for ; Tue, 4 Sep 2001 03:49:09 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eAyI-0000vr-00 for f-cpu@seul.org; Tue, 4 Sep 2001 09:50:10 +0200 Date: Tue, 4 Sep 2001 09:50:10 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <200109040343.f843hT600337@moria.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id DAA17915 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Glenn Alexander wrote: > On Tue, 4 Sep 2001 12:37, you wrote: > > whygee@club-internet.fr a écrit : > > > > > > To make things short, > > > Linux kernel = LEON (which is not a truely "free" CPU btw) > > > Hurd kernel = F-CPU (which is not finished btw). > > > > Hurd is based on Mach. Mach has been designed in 1989... > > But can / has been easily (using a loose definition of easy) ported to other > microkernels such as OSkit (sort of done - some hackers have it working on > their systems, but us non-hackers who rely on installing .debs are still > using the Mach version) or L4 (they talk about this occasionally). Looked into MACH when taking XINU for i960 in a former project but it wasn't really complete at that time. Who can point me to the latest work? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 09:44:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eC4N-0006BO-01 for ; Tue, 04 Sep 2001 11:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 11:00:31 +0200 (CEST) Received: (qmail 7006 invoked by uid 0); 4 Sep 2001 07:50:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 4 Sep 2001 07:50:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA18640 for ; Tue, 4 Sep 2001 03:50:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 07:49:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA17963 for f-cpu-list; Tue, 4 Sep 2001 03:49:14 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA17944 for ; Tue, 4 Sep 2001 03:49:12 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f847nB603426 for ; Tue, 4 Sep 2001 03:49:11 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eAsk-0000vJ-00 for f-cpu@seul.org; Tue, 4 Sep 2001 09:44:26 +0200 Date: Tue, 4 Sep 2001 09:44:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 3 Sep 2001 whygee@club-internet.fr wrote: > To make things short, > Linux kernel = LEON (which is not a truely "free" CPU btw) It's LGPL with LEON. That's why you can use your own IPs around it. But I don't agree with your distinction here - Linux is far more widespread, thus your equation hopelessly fails... > Hurd kernel = F-CPU (which is not finished btw). Are there actally people working on Hurd? I haven't heard anything for quite a while. Is anybody working on a F-CPU compiler suite? > Last btw : Industry means risk. :-) > * If you take the risk of using LEON, you can remain stuck > with the SPARC problems for a long, long while, and SPARC > is a 20-year old architecture which doesn't compete well newer > cores like SH-5 for example.* Where is it said that you have to use it the way it was written? My opinion is that the SPARC V7/V8 opcode set is a bit outdated but it's still better than ARM (just as example also standing for a lot of other embedded IP cores) because you get the source with an open license for free and you may change it. > If you take the risk to use F-CPU, your future is bright and > clear, if it arrives. At least not before 2 years. :-) Did you read the mail of Michael? He told me that it's not yet clear when and if it will ever run. At least it is a big pitty that the participants work on it between some jobs for earning money... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 09:22:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eC4O-0006BO-00 for ; Tue, 04 Sep 2001 11:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 11:00:32 +0200 (CEST) Received: (qmail 25741 invoked by uid 0); 4 Sep 2001 07:51:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 4 Sep 2001 07:51:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA18700 for ; Tue, 4 Sep 2001 03:51:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 07:49:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA18040 for f-cpu-list; Tue, 4 Sep 2001 03:49:18 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA17996 for ; Tue, 4 Sep 2001 03:49:15 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f847nE603431 for ; Tue, 4 Sep 2001 03:49:14 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eAXc-0000uD-00 for f-cpu@seul.org; Tue, 4 Sep 2001 09:22:36 +0200 Date: Tue, 4 Sep 2001 09:22:36 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010903144623.17602@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 3 Sep 2001, Michael Riepe wrote: > On Mon, Sep 03, 2001 at 09:10:27AM +0200, Juergen Goeritz wrote: > [...] > > Long story... To make it short some headlines only - > > new architecture for cluster computing - want to go for > > EU or german funding for this project - performant user > > processor still to be decided on (may be either a LEON > > extended to 64bit or F-CPU or other 64bit architecture > > that can be used for embedded) - system on chip design > > already specified - team to be built for realization - > > drawback: new architecture is not built as open source... > > If you make a SoC that includes an F-CPU core, the source code for the > entire chip must be released under the terms of the GPL because it's a > derived work. If you can live with that restriction... No, I can't. I was wondering if it could be changed to the more open LGPL license style like with LEON. Is this possible? On the other hand, if it's not possible to change to LGPL, I would not want to invest my own money but only go for it when there is enough funding money and goods. Up to now my opinion was that you can't really live from open projects. But you are invited to proove the opposite... > > I like f-cpu because it is extendable to higher bitwidth > > later on and seems to be designed for low gate count. > > *giggle* didn't you see the multiplier? :-) multipliers always come with high gate count... > > So what's the basic feeling of you people involved in > > f-cpu design and simulation to include f-cpu into a > > system? I am interested in your views very much. > > Do you want only the design for your project, or the design team as well? Good question. If I had a team it would be much easier to get it done. On the other hand I don't have enough money to set it up just for fun. I want to build a team at Karlsruhe or Baden-Baden (Germany) to focus on my mCluster project. But the people inside this team would be free to work on f-cpu as well since it may be a part of the whole project. Other companies and universities are interested and will be invited to participate as well. > You can do with the design whatever you like, as long as you follow > the rules. But isn't it a bit too early? We're still in the first of > many implementation phases, and we can give no guarantees that the F-CPU > will be finished some day, that it will perform well, or work at all. > If you rely on that, your project may fail. There may be the fallback to use an extended LEON design in the first place. Don't know if you like that. It's a big challenge anyway... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 10:59:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eE1h-0007XP-00 for ; Tue, 04 Sep 2001 13:05:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 13:05:53 +0200 (CEST) Received: (qmail 30365 invoked by uid 0); 4 Sep 2001 08:59:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 4 Sep 2001 08:59:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA20456 for ; Tue, 4 Sep 2001 04:59:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 08:58:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA19838 for f-cpu-list; Tue, 4 Sep 2001 04:58:18 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA19835 for ; Tue, 4 Sep 2001 04:58:17 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f848wG604107 for ; Tue, 4 Sep 2001 04:58:16 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eC3b-00018J-00 for f-cpu@seul.org; Tue, 4 Sep 2001 10:59:43 +0200 Date: Tue, 4 Sep 2001 10:59:43 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP In-Reply-To: <20010830144220.12685@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 30 Aug 2001, Michael Riepe wrote: > On Thu, Aug 30, 2001 at 09:50:19AM +0200, Juergen Goeritz wrote: > [...] > > > > fadd/fsub: > > > > use my generic adder as the core element and add an > > > > "input (de)normalizer" to it. > > > > Where to find? In the snapshots? > > Yes, but that's old code that doesn't synthesize well. I wrote a > package for use in the IMU; I can send you a copy. Why didn't you do it yet? ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 12:36:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eE1i-0007XP-00 for ; Tue, 04 Sep 2001 13:05:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 13:05:54 +0200 (CEST) Received: (qmail 14767 invoked by uid 0); 4 Sep 2001 10:36:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 4 Sep 2001 10:36:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA22337 for ; Tue, 4 Sep 2001 06:36:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 10:35:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA22079 for f-cpu-list; Tue, 4 Sep 2001 06:35:47 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA22076 for ; Tue, 4 Sep 2001 06:35:46 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84AZi604909 for ; Tue, 4 Sep 2001 06:35:45 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eDZN-0001EH-00 for f-cpu@seul.org; Tue, 4 Sep 2001 12:36:37 +0200 Date: Tue, 4 Sep 2001 12:36:37 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > So what's the basic feeling of you people involved in > > > f-cpu design and simulation to include f-cpu into a > > > system? I am interested in your views very much. > > > > Do you want only the design for your project, or the design team as well? > > Good question. If I had a team it would be much easier > to get it done. On the other hand I don't have enough > money to set it up just for fun. I want to build a team > at Karlsruhe or Baden-Baden (Germany) to focus on my > mCluster project. But the people inside this team would > be free to work on f-cpu as well since it may be a part > of the whole project. Other companies and universities > are interested and will be invited to participate as well. Additionally I could also offer free web hosting for f-cpu and flow problem purposes on a company webserver. There are jobs vacant in sales/PR and development but only for people with real drive behind who go for results. > > You can do with the design whatever you like, as long as you follow > > the rules. But isn't it a bit too early? We're still in the first of > > many implementation phases, and we can give no guarantees that the F-CPU > > will be finished some day, that it will perform well, or work at all. > > If you rely on that, your project may fail. But on the other hand, F-CPU is the ONLY project I know that is designed with bitwidth extension in mind from the start. My opinion is that this really can be the future for software compatibility and system development. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 15:03:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvn-0000nU-00 for ; Tue, 04 Sep 2001 16:11:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:11:59 +0200 (CEST) Received: (qmail 24692 invoked by uid 0); 4 Sep 2001 13:06:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 4 Sep 2001 13:06:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA27589 for ; Tue, 4 Sep 2001 09:06:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:05:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA26647 for f-cpu-list; Tue, 4 Sep 2001 09:05:21 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA26644 for ; Tue, 4 Sep 2001 09:05:20 -0400 Received: from tribble.stud.uni-hannover.de (root@a156.home.uni-hannover.de [130.75.232.156]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84D5H606654 for ; Tue, 4 Sep 2001 09:05:17 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00681; Tue, 4 Sep 2001 15:03:45 +0200 Message-ID: <20010904150345.14731@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 15:03:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 04, 2001 at 09:44:26AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 09:44:26AM +0200, Juergen Goeritz wrote: > [...] Is anybody working on a F-CPU > compiler suite? We have an early gcc port (not very useful at the moment). Yann and I both work on F-CPU assemblers (although with different goals in mind). I also have a semi-finished ld somewhere, and a set of other tools (ar, ranlib, strip, nm, mcs) that can be "recycled" easily since they are (almost) processor-independent. [...] > > If you take the risk to use F-CPU, your future is bright and > > clear, if it arrives. At least not before 2 years. > > :-) Did you read the mail of Michael? He told me that it's > not yet clear when and if it will ever run. At least it is > a big pitty that the participants work on it between some > jobs for earning money... At least you know both sides of the medal now ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 14:10:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvo-0000nU-00 for ; Tue, 04 Sep 2001 16:12:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:00 +0200 (CEST) Received: (qmail 32114 invoked by uid 0); 4 Sep 2001 13:06:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 4 Sep 2001 13:06:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA27659 for ; Tue, 4 Sep 2001 09:06:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:05:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA26683 for f-cpu-list; Tue, 4 Sep 2001 09:05:23 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA26664 for ; Tue, 4 Sep 2001 09:05:22 -0400 Received: from tribble.stud.uni-hannover.de (root@a156.home.uni-hannover.de [130.75.232.156]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84D5K606658 for ; Tue, 4 Sep 2001 09:05:20 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00545; Tue, 4 Sep 2001 14:10:11 +0200 Message-ID: <20010904141011.12579@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 14:10:11 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] the wrong way (or not?) concerning FP References: <20010830144220.12685@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 04, 2001 at 10:59:43AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 10:59:43AM +0200, Juergen Goeritz wrote: [...] > > Yes, but that's old code that doesn't synthesize well. I wrote a > > package for use in the IMU; I can send you a copy. > > Why didn't you do it yet? You didn't ask for it ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 14:15:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvo-0000nU-01 for ; Tue, 04 Sep 2001 16:12:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:00 +0200 (CEST) Received: (qmail 13507 invoked by uid 0); 4 Sep 2001 13:06:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 4 Sep 2001 13:06:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA27668 for ; Tue, 4 Sep 2001 09:06:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:05:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA26738 for f-cpu-list; Tue, 4 Sep 2001 09:05:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA26706 for ; Tue, 4 Sep 2001 09:05:24 -0400 Received: from tribble.stud.uni-hannover.de (root@a156.home.uni-hannover.de [130.75.232.156]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84D5M606662 for ; Tue, 4 Sep 2001 09:05:23 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00565; Tue, 4 Sep 2001 14:15:58 +0200 Message-ID: <20010904141558.43293@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 14:15:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 04, 2001 at 12:36:37PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 12:36:37PM +0200, Juergen Goeritz wrote: [...] > Additionally I could also offer free web hosting for f-cpu > and flow problem purposes on a company webserver. There > are jobs vacant in sales/PR and development but only for > people with real drive behind who go for results. I have a real drive to stay away from marketroids and sales/PR divisions in general. No, thank you. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 14:07:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvp-0000nU-00 for ; Tue, 04 Sep 2001 16:12:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:01 +0200 (CEST) Received: (qmail 5649 invoked by uid 0); 4 Sep 2001 13:06:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 4 Sep 2001 13:06:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA27843 for ; Tue, 4 Sep 2001 09:06:24 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:05:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA27033 for f-cpu-list; Tue, 4 Sep 2001 09:05:41 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA26947 for ; Tue, 4 Sep 2001 09:05:36 -0400 Received: from tribble.stud.uni-hannover.de (root@a156.home.uni-hannover.de [130.75.232.156]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84D5P606666 for ; Tue, 4 Sep 2001 09:05:25 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00528; Tue, 4 Sep 2001 14:07:10 +0200 Message-ID: <20010904140710.43571@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 14:07:10 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010903144623.17602@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 04, 2001 at 09:22:36AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: [...] > > If you make a SoC that includes an F-CPU core, the source code for the > > entire chip must be released under the terms of the GPL because it's a > > derived work. If you can live with that restriction... > > No, I can't. I was wondering if it could be changed to the > more open LGPL license style like with LEON. Is this possible? We had that discussion (again!) some weeks ago... For the moment, my answer is "no". > On the other hand, if it's not possible to change to LGPL, > I would not want to invest my own money but only go for it > when there is enough funding money and goods. Up to now my > opinion was that you can't really live from open projects. > But you are invited to proove the opposite... We have to prove nothing, since we never claimed to be able to make money with the F-CPU. On the other hand, switching to LGPL won't make us rich and famous, either. I agree that commercial F-CPU users might benefit from LGPL, but my primary goal never was to enable companies to make lots of money, without having to return *anything*. > > > I like f-cpu because it is extendable to higher bitwidth > > > later on and seems to be designed for low gate count. > > > > *giggle* didn't you see the multiplier? > > :-) multipliers always come with high gate count... Not always -- but *fast* multipliers do, of course ;) > > > So what's the basic feeling of you people involved in > > > f-cpu design and simulation to include f-cpu into a > > > system? I am interested in your views very much. > > > > Do you want only the design for your project, or the design team as well? > > Good question. If I had a team it would be much easier > to get it done. On the other hand I don't have enough > money to set it up just for fun. I want to build a team > at Karlsruhe or Baden-Baden (Germany) to focus on my > mCluster project. But the people inside this team would > be free to work on f-cpu as well since it may be a part > of the whole project. Other companies and universities > are interested and will be invited to participate as well. Interested in the mCluster project, or in F-CPU development? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 13:41:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvq-0000nU-00 for ; Tue, 04 Sep 2001 16:12:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:02 +0200 (CEST) Received: (qmail 21065 invoked by uid 0); 4 Sep 2001 13:06:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 4 Sep 2001 13:06:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA27892 for ; Tue, 4 Sep 2001 09:06:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:05:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA27217 for f-cpu-list; Tue, 4 Sep 2001 09:05:52 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA27149 for ; Tue, 4 Sep 2001 09:05:46 -0400 Received: from tribble.stud.uni-hannover.de (root@a156.home.uni-hannover.de [130.75.232.156]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84D5i606686 for ; Tue, 4 Sep 2001 09:05:44 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00462; Tue, 4 Sep 2001 13:41:43 +0200 Message-ID: <20010904134143.06970@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 13:41:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: <20010903173323.64816@thrai.stud.uni-hannover.de> <3B941EDC.DF576A54@ifrance.com> <20010904012200.10406@thrai.stud.uni-hannover.de> <15e9rN-1PuyUSC@fwd06.sul.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <15e9rN-1PuyUSC@fwd06.sul.t-online.com>; from Reichelt on Tue, Sep 04, 2001 at 08:38:57AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 08:38:57AM +0200, Reichelt wrote: [...] > > I said "register", so I guess I meant hardware ;) Whether user mode > > programs are allowed to read that register is currently unspecified. > NO they should NOT be allowed to read that register. [...] > A virtual machine works by keeping the CPU in user mode while sometimes tricking > it into believing it is in supervisor mode. Instructions which would blow the > masquerade are handle in the trap handler. For a VM, read access should be turned off, right. But there may be other situations where limited (read-only) access to selected special registers is useful. In a simple privilege model (user/supervisor only), the register should be invisible. In the capabilities model, there might be a bit that turns access privileges on and off independently. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 15:32:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvr-0000nU-00 for ; Tue, 04 Sep 2001 16:12:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:03 +0200 (CEST) Received: (qmail 14482 invoked by uid 0); 4 Sep 2001 13:38:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 4 Sep 2001 13:38:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA28533 for ; Tue, 4 Sep 2001 09:38:24 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:38:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA28290 for f-cpu-list; Tue, 4 Sep 2001 09:38:08 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA28287 for ; Tue, 4 Sep 2001 09:38:07 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84Dc4607230 for ; Tue, 4 Sep 2001 09:38:05 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eGJX-0001YY-00 for f-cpu@seul.org; Tue, 4 Sep 2001 15:32:27 +0200 Date: Tue, 4 Sep 2001 15:32:27 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: <20010904150345.14731@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 09:44:26AM +0200, Juergen Goeritz wrote: > > [...] Is anybody working on a F-CPU > > compiler suite? > > We have an early gcc port (not very useful at the moment). Yann and I > both work on F-CPU assemblers (although with different goals in mind). > I also have a semi-finished ld somewhere, and a set of other tools (ar, > ranlib, strip, nm, mcs) that can be "recycled" easily since they are > (almost) processor-independent. That's a good start. > [...] > > > If you take the risk to use F-CPU, your future is bright and > > > clear, if it arrives. At least not before 2 years. > > > > :-) Did you read the mail of Michael? He told me that it's > > not yet clear when and if it will ever run. At least it is > > a big pitty that the participants work on it between some > > jobs for earning money... > > At least you know both sides of the medal now ;) I know them since 3 years when I started to go for mCluster ;) Everytime I did run into some trouble on these jobs for money because I was a bit too far ahead already... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 15:38:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvr-0000nU-01 for ; Tue, 04 Sep 2001 16:12:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:03 +0200 (CEST) Received: (qmail 27430 invoked by uid 0); 4 Sep 2001 13:39:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Sep 2001 13:39:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA29034 for ; Tue, 4 Sep 2001 09:39:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:39:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA28570 for f-cpu-list; Tue, 4 Sep 2001 09:39:08 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA28567 for ; Tue, 4 Sep 2001 09:39:07 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84Dd3607268 for ; Tue, 4 Sep 2001 09:39:04 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eGPa-0001Ya-00 for f-cpu@seul.org; Tue, 4 Sep 2001 15:38:42 +0200 Date: Tue, 4 Sep 2001 15:38:42 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010904141558.43293@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 12:36:37PM +0200, Juergen Goeritz wrote: > [...] > > Additionally I could also offer free web hosting for f-cpu > > and flow problem purposes on a company webserver. There > > are jobs vacant in sales/PR and development but only for > > people with real drive behind who go for results. > > I have a real drive to stay away from marketroids and sales/PR > divisions in general. No, thank you. What is a 'marketroid'? Go away with divisions! No divisions in my company, I love flat structures, i.e. a team and I wouldn't extend to more than 10 people anyway. If it's getting more better to found a new company... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 15:26:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvs-0000nU-00 for ; Tue, 04 Sep 2001 16:12:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:04 +0200 (CEST) Received: (qmail 10503 invoked by uid 0); 4 Sep 2001 13:39:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 4 Sep 2001 13:39:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA29276 for ; Tue, 4 Sep 2001 09:39:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:39:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA28698 for f-cpu-list; Tue, 4 Sep 2001 09:39:15 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA28671 for ; Tue, 4 Sep 2001 09:39:13 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84Dd8607272 for ; Tue, 4 Sep 2001 09:39:09 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eGDQ-0001Xx-00 for f-cpu@seul.org; Tue, 4 Sep 2001 15:26:08 +0200 Date: Tue, 4 Sep 2001 15:26:08 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010904140710.43571@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: > [...] > > > If you make a SoC that includes an F-CPU core, the source code for the > > > entire chip must be released under the terms of the GPL because it's a > > > derived work. If you can live with that restriction... > > > > No, I can't. I was wondering if it could be changed to the > > more open LGPL license style like with LEON. Is this possible? > > We had that discussion (again!) some weeks ago... > For the moment, my answer is "no". That's a pity because I also don't want to open my design without any return involved. How to solve this situation? > > On the other hand, if it's not possible to change to LGPL, > > I would not want to invest my own money but only go for it > > when there is enough funding money and goods. Up to now my > > opinion was that you can't really live from open projects. > > But you are invited to proove the opposite... > > We have to prove nothing, since we never claimed to be able to make > money with the F-CPU. On the other hand, switching to LGPL won't make > us rich and famous, either. I agree that commercial F-CPU users might > benefit from LGPL, but my primary goal never was to enable companies to > make lots of money, without having to return *anything*. Hmh! Why not found an AG and you become shareholders until the proof of concept is done and the first chip released? This way we could start with only about 100K DM. > Interested in the mCluster project, or in F-CPU development? Interested in a new architecture that must be extendable and free the developer from that creapy kernel/driver and whatsoever low level adaption stuff and provide software portability. I do not focus on a processor alone... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 4 15:13:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eGvt-0000nU-00 for ; Tue, 04 Sep 2001 16:12:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Sep 2001 16:12:05 +0200 (CEST) Received: (qmail 4973 invoked by uid 0); 4 Sep 2001 13:39:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 4 Sep 2001 13:39:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA29317 for ; Tue, 4 Sep 2001 09:39:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 13:39:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA28770 for f-cpu-list; Tue, 4 Sep 2001 09:39:19 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA28735 for ; Tue, 4 Sep 2001 09:39:17 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84DdC607275 for ; Tue, 4 Sep 2001 09:39:13 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eG0o-0001Xv-00 for f-cpu@seul.org; Tue, 4 Sep 2001 15:13:06 +0200 Date: Tue, 4 Sep 2001 15:13:06 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners In-Reply-To: <20010904134143.06970@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 08:38:57AM +0200, Reichelt wrote: > [...] > > > I said "register", so I guess I meant hardware ;) Whether user mode > > > programs are allowed to read that register is currently unspecified. > > NO they should NOT be allowed to read that register. > [...] > > A virtual machine works by keeping the CPU in user mode while sometimes tricking > > it into believing it is in supervisor mode. Instructions which would blow the > > masquerade are handle in the trap handler. > > For a VM, read access should be turned off, right. But there may be > other situations where limited (read-only) access to selected special > registers is useful. Maybe from the debugging interface? > In a simple privilege model (user/supervisor only), the register should > be invisible. In the capabilities model, there might be a bit that > turns access privileges on and off independently. Why not add another mode for access that may be switched on from 'outside' to go into hardware debugging mode? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Sep 4 17:47:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZk-0007sa-01 for ; Wed, 05 Sep 2001 05:42:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:04 +0200 (CEST) Received: (qmail 10548 invoked by uid 0); 4 Sep 2001 16:15:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 4 Sep 2001 16:15:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id MAA03628 for ; Tue, 4 Sep 2001 12:15:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 16:15:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id MAA03378 for f-cpu-list; Tue, 4 Sep 2001 12:15:20 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id MAA03375 for ; Tue, 4 Sep 2001 12:15:19 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84GFI611118 for ; Tue, 4 Sep 2001 12:15:18 -0400 Received: from jetnet.ab.ca (dialin56.jetnet.ab.ca [207.153.6.56]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA28578 for ; Tue, 4 Sep 2001 10:15:14 -0600 (MDT) Message-ID: <3B94F7AD.733D7375@jetnet.ab.ca> Date: Tue, 04 Sep 2001 09:47:57 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > Maybe from the debugging interface? > > > In a simple privilege model (user/supervisor only), the register should > > be invisible. In the capabilities model, there might be a bit that > > turns access privileges on and off independently. > > Why not add another mode for access that may be switched > on from 'outside' to go into hardware debugging mode? > Why is a virtual cpu needed on the first revision? I don't mind slow interrupt service providing hardware is defined for it - dma access and fifo's where needed. The serial port on the PC ( the whole pc) is a bad example of doing interrupts. What is needed is smart - dumb hardware i/o controllers. If you you define a virtual machine lets define virtual hardware that is clean and works well. Bring back I/O control blocks? Pesudo fixed memory frame buffers? More real time smarts. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 5 01:54:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZr-0007sa-01 for ; Wed, 05 Sep 2001 05:42:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:11 +0200 (CEST) Received: (qmail 14388 invoked by uid 0); 4 Sep 2001 17:43:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 4 Sep 2001 17:43:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA09940 for ; Tue, 4 Sep 2001 13:43:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 17:43:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA09697 for f-cpu-list; Tue, 4 Sep 2001 13:43:34 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA09694 for ; Tue, 4 Sep 2001 13:43:33 -0400 Received: from localhost.localdomain (nas5-160.vlt.club-internet.fr [194.158.107.160]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84HhV613871 for ; Tue, 4 Sep 2001 13:43:32 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C992E165F for ; Tue, 4 Sep 2001 19:54:06 -0400 (EDT) Message-ID: <3B95699E.DB0AEA29@ifrance.com> Date: Tue, 04 Sep 2001 19:54:06 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010903144623.17602@thrai.stud.uni-hannover.de> <20010904140710.43571@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: > [...] > > > If you make a SoC that includes an F-CPU core, the source code for the > > > entire chip must be released under the terms of the GPL because it's a > > > derived work. If you can live with that restriction... > > > > No, I can't. I was wondering if it could be changed to the > > more open LGPL license style like with LEON. Is this possible? > > We had that discussion (again!) some weeks ago... > For the moment, my answer is "no". > > > On the other hand, if it's not possible to change to LGPL, > > I would not want to invest my own money but only go for it > > when there is enough funding money and goods. Up to now my > > opinion was that you can't really live from open projects. > > But you are invited to proove the opposite... > > We have to prove nothing, since we never claimed to be able to make > money with the F-CPU. On the other hand, switching to LGPL won't make > us rich and famous, either. I agree that commercial F-CPU users might > benefit from LGPL, but my primary goal never was to enable companies to > make lots of money, without having to return *anything*. > > I agree ! But Juergen should not forget that lgpl code said you could NOT modify the sources without redistribut it. We could juste 'link' it with other IP. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 5 01:58:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZs-0007sa-00 for ; Wed, 05 Sep 2001 05:42:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:12 +0200 (CEST) Received: (qmail 23454 invoked by uid 0); 4 Sep 2001 17:47:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 4 Sep 2001 17:47:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA10252 for ; Tue, 4 Sep 2001 13:47:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 17:47:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA10000 for f-cpu-list; Tue, 4 Sep 2001 13:47:42 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA09997 for ; Tue, 4 Sep 2001 13:47:41 -0400 Received: from localhost.localdomain (nas5-160.vlt.club-internet.fr [194.158.107.160]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84Hld613987 for ; Tue, 4 Sep 2001 13:47:40 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 62860165F for ; Tue, 4 Sep 2001 19:58:15 -0400 (EDT) Message-ID: <3B956A97.DAB18AD4@ifrance.com> Date: Tue, 04 Sep 2001 19:58:15 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Tue, 4 Sep 2001, Michael Riepe wrote: > > > On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: > > [...] > > > > If you make a SoC that includes an F-CPU core, the source code for the > > > > entire chip must be released under the terms of the GPL because it's a > > > > derived work. If you can live with that restriction... > > > > > > No, I can't. I was wondering if it could be changed to the > > > more open LGPL license style like with LEON. Is this possible? > > > > We had that discussion (again!) some weeks ago... > > For the moment, my answer is "no". > > That's a pity because I also don't want to open my design > without any return involved. How to solve this situation? > ??????????? We soon give you (and to the world) a quite complete cpu with really fast unit and a pretty good ISA, and you say that there isn't any return ! That's the goal of the GPL, i give my work to the world and nobody could steal my work but other could help me. nicO <...> > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Tue Sep 4 20:55:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZt-0007sa-00 for ; Wed, 05 Sep 2001 05:42:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:13 +0200 (CEST) Received: (qmail 3506 invoked by uid 0); 4 Sep 2001 18:57:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 4 Sep 2001 18:57:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA12620 for ; Tue, 4 Sep 2001 14:57:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 18:55:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA12303 for f-cpu-list; Tue, 4 Sep 2001 14:55:34 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA12300 for ; Tue, 4 Sep 2001 14:55:33 -0400 Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84ItW615652 for ; Tue, 4 Sep 2001 14:55:33 -0400 Received: from skule.ecf (fender@skule.ecf [128.100.8.6]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id OAA08085 for ; Tue, 4 Sep 2001 14:55:27 -0400 Received: from localhost (fender@localhost) by skule.ecf (SGI-8.9.3/8.9.3) with SMTP id OAA09118 for ; Tue, 4 Sep 2001 14:55:27 -0400 (EDT) X-Authentication-Warning: skule.ecf: fender owned process doing -bs Date: Tue, 4 Sep 2001 14:55:27 -0400 (EDT) From: Josh Fender X-Sender: fender@skule.ecf To: f-cpu@seul.org Subject: [f-cpu] Re: Testing Hardware In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Does anybody have access to a synthesis tool for some > > > prototyping? Does anybody have access to a FPGA board > > > for testing? > > > i think that some people here have some means. > > however, without complete source code, it's almost > > useless :-( > > Anybody out there? By the way, what is still missing? Just for your information I do have access to hardware and software needed to test various units. The university lab, in which I work, has a nice little setup with 4 virtex 2000e chips onboard with some SRAM and an interface to a SUN system. On the synthesis end I use synplify pro. Unfortunately, like YG said, there isn't really anything to test yet. I have synthesised the multiplier source code just out of curiousity but there is no point in testing an incomplete unit. Maybe once some more VHDL code is released I will synthesis more. - Josh ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Sep 4 21:29:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZt-0007sa-01 for ; Wed, 05 Sep 2001 05:42:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:13 +0200 (CEST) Received: (qmail 7674 invoked by uid 0); 4 Sep 2001 19:25:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 4 Sep 2001 19:25:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA13878 for ; Tue, 4 Sep 2001 15:24:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 19:24:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA13632 for f-cpu-list; Tue, 4 Sep 2001 15:24:36 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA13629 for ; Tue, 4 Sep 2001 15:24:35 -0400 Received: from imf01bis.bellsouth.net (mail201.mail.bellsouth.net [205.152.58.141]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84JOY617053 for ; Tue, 4 Sep 2001 15:24:35 -0400 Received: from computer ([208.60.245.154]) by imf01bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010904192447.TWBO23234.imf01bis.bellsouth.net@computer>; Tue, 4 Sep 2001 15:24:47 -0400 Message-ID: <004701c13577$f88dafa0$9af53cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] mCluster Date: Tue, 4 Sep 2001 14:29:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C1354E.04EAC320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C1354E.04EAC320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all. I see Jeurgen is working on a cluster - apparently several = or many display terminals. The concept is not new. Sanders Associates = did that on the Saturn V system for NASA in 1965. I was a member of = that team for several years. Later did the same for Kaiser Hospital in = San Francisco. Later did the same for Mayo Clinic. Later did the same = for GTE Sylvania where I designed the first raster scan monitor for the = U.S.Navy - later sold to German Navy. And now, that is exactly what I will be presenting at the = Microprocessor Forum Expo 2001 in San Jose. What advantages are there = for 128 Users?????? 1. One power supply NOT 128 2. One RTC NOT 128 3. In my case - 2 Processors, NOT 128 4. KBytes of Programs NOT Mbytes 5. One or two Hard Disk Drives, NOT 128 6. Several Modems - NOT 128 7. One Disk backup (Iomega), NOT 128 8. System Integrity - NOT prone to VIRUS Intrusion 9. Centralized Data Distribution 10. Maintainability 11. No Visable wait for data response. 12. And list goes on----- Regards, Dick Hartney =20 =20 ------=_NextPart_000_0044_01C1354E.04EAC320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all.  I see Jeurgen is = working on a=20 cluster - apparently several or many display terminals.  The = concept is not=20 new.  Sanders Associates did that on the Saturn V system for NASA = in=20 1965.  I was a member of that team for several years.  Later = did the=20 same for Kaiser Hospital in San Francisco.  Later did the same for = Mayo=20 Clinic.  Later did the same for GTE Sylvania where I designed the = first=20 raster scan monitor for the U.S.Navy = - later sold=20 to German Navy.
 
    And now, that is = exactly what I=20 will be presenting at the Microprocessor Forum Expo 2001 in San = Jose.  What=20 advantages are there for 128 Users??????
 
       =20     1.  One power supply NOT 128
       =20     2.  One RTC NOT 128
       =20     3.  In my case - 2 Processors, NOT = 128
       =20     4.  KBytes of Programs NOT Mbytes
       =20     5.  One or two Hard Disk Drives, NOT = 128
       =20     6.  Several Modems - NOT 128
       =20     7.  One Disk backup (Iomega), NOT = 128
       =20     8.  System Integrity - NOT prone to VIRUS=20 Intrusion
       =20     9.  Centralized Data Distribution
       =20     10. Maintainability
       =20     11. No Visable wait for data response.
       =20     12. And list goes on-----
 
Regards,
Dick Hartney
 
   
 
 
    
------=_NextPart_000_0044_01C1354E.04EAC320-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 4 21:51:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZu-0007sa-00 for ; Wed, 05 Sep 2001 05:42:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:14 +0200 (CEST) Received: (qmail 9077 invoked by uid 0); 4 Sep 2001 19:51:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 4 Sep 2001 19:51:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA14812 for ; Tue, 4 Sep 2001 15:51:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 19:51:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA14565 for f-cpu-list; Tue, 4 Sep 2001 15:51:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA14562 for ; Tue, 4 Sep 2001 15:51:26 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84JpP617858 for ; Tue, 4 Sep 2001 15:51:25 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA01185 for f-cpu@seul.org; Tue, 4 Sep 2001 21:51:19 +0200 (MET DST) Date: Tue, 4 Sep 2001 21:51:19 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] mCluster X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id PAA14563 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >Hello all. I see Jeurgen is working on a cluster > - apparently several or many display terminals. > The concept is not new. Sanders Associates did > that on the Saturn V system for NASA in 1965. > I was a member of that team for several years. > Later did the same for Kaiser Hospital in San Francisco. > Later did the same for Mayo Clinic. Later did the same > for GTE Sylvania where I designed the first raster > scan monitor for the U.S.Navy - later sold to German Navy > And now, that is exactly what I will be presenting > at the Microprocessor Forum Expo 2001 in San Jose. > What advantages are there for 128 Users?????? I think that the answer is not what you think. I think that Juergen wants to design a compact MPP computer (1m^3 ?), not a cybercafe or NASA control room thing. The problem is more on resolving lots of parallel equations and computing large matrices, not on entering/displaying forms. >Regards, >Dick Hartney Read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 4 21:58:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZv-0007sa-00 for ; Wed, 05 Sep 2001 05:42:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:15 +0200 (CEST) Received: (qmail 4841 invoked by uid 0); 4 Sep 2001 19:58:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 4 Sep 2001 19:58:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA15143 for ; Tue, 4 Sep 2001 15:58:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 19:58:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA14900 for f-cpu-list; Tue, 4 Sep 2001 15:58:33 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA14897 for ; Tue, 4 Sep 2001 15:58:32 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84JwH618028 for ; Tue, 4 Sep 2001 15:58:17 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA05828 for f-cpu@seul.org; Tue, 4 Sep 2001 21:58:15 +0200 (MET DST) Date: Tue, 4 Sep 2001 21:58:15 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id PAA14898 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >> > > Does anybody have access to a synthesis tool for some >> > > prototyping? Does anybody have access to a FPGA board >> > > for testing? >> > i think that some people here have some means. >> > however, without complete source code, it's almost >> > useless :-( >> Anybody out there? By the way, what is still missing? > >Just for your information I do have access to hardware and software needed >to test various units. The university lab, in which I work, has a nice >little setup with 4 virtex 2000e chips onboard with some SRAM and an >interface to a SUN system. On the synthesis end I use synplify pro. yummy :-)) >Unfortunately, like YG said, there isn't really anything to test yet. I >have synthesised the multiplier source code just out of curiousity but >there is no point in testing an incomplete unit. i think that the multiplier is being currently re-re-re-redesigned... don't worry :-) >Maybe once some more VHDL code is released I will synthesis more. can you try with my latest snapshot of the ROP2 unit ? i am curious about the signal drivers and the clocking frequency. i'll try to make a testframe for this, if you want (otherwise look at the testbench to see the way to use the different parts but it won't synthesise because of the file parsing stuffs). Btw, i will start the design of the register set. Any help welcome !!! >- Josh YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 4 22:16:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZw-0007sa-00 for ; Wed, 05 Sep 2001 05:42:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:16 +0200 (CEST) Received: (qmail 3466 invoked by uid 0); 4 Sep 2001 20:16:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 4 Sep 2001 20:16:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA15912 for ; Tue, 4 Sep 2001 16:16:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 20:16:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA15667 for f-cpu-list; Tue, 4 Sep 2001 16:16:38 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA15664 for ; Tue, 4 Sep 2001 16:16:37 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84KGZ618561 for ; Tue, 4 Sep 2001 16:16:36 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA14614 for f-cpu@seul.org; Tue, 4 Sep 2001 22:16:33 +0200 (MET DST) Date: Tue, 4 Sep 2001 22:16:33 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id QAA15665 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hallo alle, >De: Juergen Goeritz >On Tue, 4 Sep 2001, Michael Riepe wrote: >> On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: >> [...] >> > > If you make a SoC that includes an F-CPU core, the source code for the >> > > entire chip must be released under the terms of the GPL because it's a >> > > derived work. If you can live with that restriction... >> > No, I can't. I was wondering if it could be changed to the >> > more open LGPL license style like with LEON. Is this possible? >> We had that discussion (again!) some weeks ago... >> For the moment, my answer is "no". >That's a pity because I also don't want to open my design >without any return involved. How to solve this situation? there is no "solution". Would you ask Micro$oft to change their distribution licence ? :-P There is a probability that the F-CPU licence will change if we get advices from legal experts : GPL has a few drawbacks but it's the only working licence that we know. Later, a F-CPU licence will cover the dark corners of RTL source code (all the problems with the meanings of "compilation" and "linking" that is different in our case), but i don't believe that our basic idea and understanding of "freedom" will change. >> > On the other hand, if it's not possible to change to LGPL, >> > I would not want to invest my own money but only go for it >> > when there is enough funding money and goods. Up to now my >> > opinion was that you can't really live from open projects. >> > But you are invited to proove the opposite... >> We have to prove nothing, since we never claimed to be able to make >> money with the F-CPU. On the other hand, switching to LGPL won't make >> us rich and famous, either. I agree that commercial F-CPU users might >> benefit from LGPL, but my primary goal never was to enable companies to >> make lots of money, without having to return *anything*. >Hmh! Why not found an AG and you become shareholders until >the proof of concept is done and the first chip released? >This way we could start with only about 100K DM. how much chocolate could i buy with 100K DM ? >> Interested in the mCluster project, or in F-CPU development? >Interested in a new architecture that must be extendable >and free the developer from that creapy kernel/driver and >whatsoever low level adaption stuff and provide software >portability. I do not focus on a processor alone... We do not "only" focus on the CPU : For example i am both a programer and electronician (rather loosy both) and i have remarked that the CPU is the center of both worlds. This is why my efforts are in this direction. Concerning your reasons (I/O, programming model etc.), assume that the CPU is the center of the computer. If the CPU is not free the rest will remain crappy. OTOH, putting a "free" CPU in the middle of a "non-free" HW won't solve everything magically. Ok, i will let others answer (i've seen nicO's answer and i fear a flame war...). >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 4 22:28:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZw-0007sa-01 for ; Wed, 05 Sep 2001 05:42:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:16 +0200 (CEST) Received: (qmail 15824 invoked by uid 0); 4 Sep 2001 20:29:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 4 Sep 2001 20:29:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA16308 for ; Tue, 4 Sep 2001 16:29:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 20:28:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA16058 for f-cpu-list; Tue, 4 Sep 2001 16:28:52 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA16055 for ; Tue, 4 Sep 2001 16:28:51 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84KSd618834 for ; Tue, 4 Sep 2001 16:28:49 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA21019 for f-cpu@seul.org; Tue, 4 Sep 2001 22:28:37 +0200 (MET DST) Date: Tue, 4 Sep 2001 22:28:37 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] the wrong way (or not?) concerning FP X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id QAA16056 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: Michael Riepe >On Tue, Sep 04, 2001 at 10:59:43AM +0200, Juergen Goeritz wrote: >[...] >> > Yes, but that's old code that doesn't synthesize well. I wrote a >> > package for use in the IMU; I can send you a copy. >> Why didn't you do it yet? >You didn't ask for it ;) here is an official request : can you upload your files on f-cpu.seul.org ? it is very simple in fact : $> ftp ftp.seul.org login : anonymous password : garbage or whatever you want. it's not checked. > bin > hash > cd pub > cd f-cpu > cd contrib > put your_file and send a message giving the filename. it is visible at http://f-cpu.seul.org/new > Michael "Tired" Riepe YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 4 23:08:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTZx-0007sa-00 for ; Wed, 05 Sep 2001 05:42:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:17 +0200 (CEST) Received: (qmail 16401 invoked by uid 0); 4 Sep 2001 21:09:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 4 Sep 2001 21:09:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA17136 for ; Tue, 4 Sep 2001 17:09:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 21:08:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA16888 for f-cpu-list; Tue, 4 Sep 2001 17:08:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA16885 for ; Tue, 4 Sep 2001 17:08:44 -0400 Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84L8c619649 for ; Tue, 4 Sep 2001 17:08:39 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA14388 for f-cpu@seul.org; Tue, 4 Sep 2001 23:08:28 +0200 (MET DST) Date: Tue, 4 Sep 2001 23:08:28 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] More Dark and Dusty Corners X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id RAA16886 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that i have let this discussion pass... here are some hints. BTW, how can a user-land SW emulate a virtual OS if the instructions have to trap when emulation must be done ? I have no idea of how it works on mainframes (heck) but here is some idea : 1) there is a "capability bit" which allows the running code to modify its own Interrupt Routine Table pointer. This way, the IRQ table can be stored in the user land and be modified at will. Software interrupts/traps occuring from THIS user program (of course) are redirected to this table. HW interrupt and failures in the setup of the new table are redirected to the kernel. Note : When the bit is set, the "local IRQ table pointer" is stored in the CMB. This isolates every task for each others. 2) setup the table so every "supervisor" instruction is trapped and handled by our code. Other instructions are simply "forwarded" (ie : FDIV emulation...) to the kernel by re-running the code inside the trap handler or something like that. you're done. >De: Michael Riepe >On Mon, Sep 03, 2001 at 08:22:52PM -0400, nicO wrote: >[...] >> > First of all, how do we detect supervisor mode? I guess there should be >> > a special register indicating the current privilege level. Bit 0 will >> > be the `supervisor' bit, all other bits are reserved and must be zero >> > (we can later refine the model to include specific privileges, similar >> > to capabilities in the linux kernel). yes, something like that. >> Nice idea the capabilities ! It look like new protection scheme from new >> designed OS. >> >> But do you want to detect the mode by software or you speak from the >> hardware point of view ? [...] >I said "register", so I guess I meant hardware ;) Whether user mode >programs are allowed to read that register is currently unspecified. It is mapped in the SRs so reading and writing is controlled by another "capability bit", on a register-wise granularity (some SRs are strictly user-dependent, such as the size properties, some others are striclty kernel-only.) >> > When doing a context switch, the `privilege' SR should be loaded from >> > the new CMB before any other operation is performed. Remember that >> > the F-CPU might be interrupted in supervisor mode, and must be able to >> > return to that mode when `rfe' is executed. >> >> ??? During an interrupt the cpu switch to priviledge mode and then the >> kernel do what i want. It depends on the IRQ. Ie : see above, a user application may want to emulate some instructions itself. >> But the some trap could stay in user land to handel some error (div by >> zero,...). > >I'm not in OS/Software land here either... > >The CPU simply must know where it came from, in order to return properly. obviously :-) >That in turn means it has to save a certain amount of state, including >the priviledge mode SR, automatically (that is, in hardware). > >> > A propos `rfe'/interrupts: something that is not clear yet is what >> > happens when the F-CPU is interrupted. Is it supposed to perform >> > a full context switch in all cases? That might be overkill in some >> > situations, especially when the interrupt handler is short. not necessarily. In practice, the time to fetch the handler code can be very long, if you have to fetch it from external SDRAM... >> > What happens >> > if the IRQ handler reaches the final `rfe' before the SRB is finished? >> It freeze the code ! >That's what I was afraid of. no. SRB is ATOMIC. It also reorganises the access pattern to avoid certain stalls. If RFE occurs before SRB ends, the return code will be fetched but SRB will continue. SRB also blocks IRQs. SRB IS SAFE by design. It simply spares some time during most context switches. One solution to your problem (fast/slow IRQs) would be to use the SRB instruction explicitely when the IRQ routine starts but we will have wasted some precious time (it can take a long time before the routine code is available). >> > According to the manual, the running SRB must finish before a new one >> > can be started, but that's not appropriate -- why finish something you >> > have to undo anyway? it is because when it returns, it would be very complicated to know if the register was saved or something like that. In fact i think that i remember : If you interrupt one SRB by another, we can't know which register belongs to what. >> I don't think that you're supposed to come back to the same program >> after an interrupt, the kernel should choose. > >You don't call the scheduler on every interrupt. Linux only calls it >when the current process runs out of fuel (timeslice is over), or when >another process is woken up (or created) that probably has a higher >priority. And a timeslice is rather long -- 20 ticks IIRC (that's 2 >seconds). > >Most interrupts are handled on-the-fly, without switching to kernel mode. >They do their (short) work and then return to the interrupted process. >You would lose too much time otherwise. > >> Maybe we can implement such fast interrupt with shadow register (like >> ARM does). Instead of saving the regiter bank, you just switch the bank >> (maybe we don't need a complete new 64 registers set). But then you >> could have many problems with the implementation of a preemptive system >> (allowing an interrupt to interrupt an other interrupt). Because, then >> you should save 2 register sets ! > >We have that nasty nested interrupt problem anyway. Register windows are no-no. We already have a "huge" register set and SRB to reduce the latency. register windows would kill the clock cycle length. >> > Another problem is nested interrupts. When each interrupt (or exception) >> > causes a context switch, we need a CMB stack -- on the second interrupt, >> > the context of the first IRQ handler must be saved, and it must be >> > properly restored when the "inner" handler returns. If we don't >> > permit an IRQ to interrupt its own handler (that is, block it until >> > the corresponding `rfe'), we may get away with one CMB per possible >> > IRQ/exception, but that's already a whole lot of CMBs. Oh by the way: >> > we need an `interrupt enable' SR, too. we have it, at least internally. SRB masks it. >> That's the difference between instrerrupt enable and interrupt mask >> (which leaves the interrupt pending until the rfe). In fact, the first >> thing that the kernel should do is to prepare a new pointer to a CMB and >> then renable the interrupt. In fact, it's the common problem with every >> cpu. right. if you want your IRQ handler to be reentrant, you have to setup your CMB stack in SW explicitely and reenable IRQs. (it's the reverse when leaving.) >What about exceptions? You can't turn them off like interrupts. >An interrupt/exception handler may trigger an exception, and there may >be interrupts while an exception handler is executed. You can't avoid >the nesting, and software may not always be fast enough to prepare a >new CMB pointer before the next interrupt/exception occurs. > >Linux uses CMBs (or Task State Segments, or struct task_struct, >or whatever) only for user tasks, and it only does a context switch >(save/reload all registers) when switching from one task to another, >because that's faster. > > Michael "Tired" Riepe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Sep 4 23:49:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa1-0007sa-00 for ; Wed, 05 Sep 2001 05:42:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:21 +0200 (CEST) Received: (qmail 30394 invoked by uid 0); 4 Sep 2001 22:19:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 4 Sep 2001 22:19:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA20893 for ; Tue, 4 Sep 2001 18:19:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 22:18:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA20670 for f-cpu-list; Tue, 4 Sep 2001 18:18:41 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA20667 for ; Tue, 4 Sep 2001 18:18:40 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84MIY620760 for ; Tue, 4 Sep 2001 18:18:35 -0400 Received: from art1.none.de (dialin172.pg4-nt.berlin.nikoma.de [213.54.67.172]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f84MIbK01820 for ; Wed, 5 Sep 2001 00:18:38 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin172.pg4-nt.berlin.nikoma.de [213.54.67.172] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15eO5g-0004f3-00 for ; Tue, 04 Sep 2001 23:50:40 +0200 Date: Tue, 4 Sep 2001 23:49:40 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: OFF TOPIC: Chocolate Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: > how much chocolate could i buy with 100K DM ? At "Aldi"-Discounter you get 0,1 kg for 0,59 DM... means 16949 kg Have fun and a good smelling Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7lUx3ClxplZklbgERAsNsAJ9UNtt0d6c0qozGTlI66eC/VPAXHQCeKRMj fowCEFFv9vssCsxVy0TINFI= =0p7f -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 00:41:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa2-0007sa-00 for ; Wed, 05 Sep 2001 05:42:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:22 +0200 (CEST) Received: (qmail 13316 invoked by uid 0); 4 Sep 2001 22:42:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 4 Sep 2001 22:42:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA23714 for ; Tue, 4 Sep 2001 18:42:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 22:42:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA23337 for f-cpu-list; Tue, 4 Sep 2001 18:42:25 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA23334 for ; Tue, 4 Sep 2001 18:42:24 -0400 Received: from tribble.stud.uni-hannover.de (root@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84MgE621102 for ; Tue, 4 Sep 2001 18:42:15 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00990; Wed, 5 Sep 2001 00:41:20 +0200 Message-ID: <20010905004120.28005@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 00:41:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <3B956A97.DAB18AD4@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3B956A97.DAB18AD4@ifrance.com>; from nicO on Tue, Sep 04, 2001 at 07:58:15PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 07:58:15PM -0400, nicO wrote: > Juergen Goeritz a écrit : [...] > > That's a pity because I also don't want to open my design > > without any return involved. How to solve this situation? > > ??????????? We soon give you (and to the world) a quite complete cpu > with really fast unit and a pretty good ISA, and you say that there > isn't any return ! That's the goal of the GPL, i give my work to the > world and nobody could steal my work but other could help me. A- -men! Our source code is freely available; that's already much more than anybody can expect, IMHO. I don't mind if somebody doesn't want to show his/her code, but then (s)he shouldn't ask for more. But I guess Juergen meant "money" when he wrote "return"... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 21:58:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa2-0007sa-01 for ; Wed, 05 Sep 2001 05:42:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:22 +0200 (CEST) Received: (qmail 18446 invoked by uid 0); 4 Sep 2001 22:42:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 4 Sep 2001 22:42:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA23854 for ; Tue, 4 Sep 2001 18:42:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 22:42:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA23496 for f-cpu-list; Tue, 4 Sep 2001 18:42:35 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA23476 for ; Tue, 4 Sep 2001 18:42:33 -0400 Received: from tribble.stud.uni-hannover.de (root@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84MgU621107 for ; Tue, 4 Sep 2001 18:42:30 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00611; Tue, 4 Sep 2001 21:58:37 +0200 Message-ID: <20010904215837.38420@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 21:58:37 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010903144623.17602@thrai.stud.uni-hannover.de> <20010904140710.43571@thrai.stud.uni-hannover.de> <3B95699E.DB0AEA29@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B95699E.DB0AEA29@ifrance.com>; from nicO on Tue, Sep 04, 2001 at 07:54:06PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 07:54:06PM -0400, nicO wrote: [...] > > We have to prove nothing, since we never claimed to be able to make > > money with the F-CPU. On the other hand, switching to LGPL won't make > > us rich and famous, either. I agree that commercial F-CPU users might > > benefit from LGPL, but my primary goal never was to enable companies to > > make lots of money, without having to return *anything*. > > I agree ! But Juergen should not forget that lgpl code said you could > NOT modify the sources without redistribut it. No, you can modify and use (L)GPL code as much as you like, without redistributing it. You only have to redistribute the source *together with the resulting binaries*. If you never distribute the binaries (i.e. use them only internally), you need not publish your changes at all. The (L)GPL only specifies rules for modification and redistribution, not for *using* a piece of GPLed code. Quoting from the GPL: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. Disclaimer: I'm not a shark^H^H^H^H^Hlawyer. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 4 21:16:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa3-0007sa-00 for ; Wed, 05 Sep 2001 05:42:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:23 +0200 (CEST) Received: (qmail 25629 invoked by uid 0); 4 Sep 2001 22:43:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 4 Sep 2001 22:43:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA24118 for ; Tue, 4 Sep 2001 18:43:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 22:43:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA23873 for f-cpu-list; Tue, 4 Sep 2001 18:43:04 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA23870 for ; Tue, 4 Sep 2001 18:43:03 -0400 Received: from tribble.stud.uni-hannover.de (root@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84Mgx621127 for ; Tue, 4 Sep 2001 18:42:59 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00502; Tue, 4 Sep 2001 21:16:43 +0200 Message-ID: <20010904211643.11853@thrai.stud.uni-hannover.de> Date: Tue, 4 Sep 2001 21:16:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010904141558.43293@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 04, 2001 at 03:38:42PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 03:38:42PM +0200, Juergen Goeritz wrote: [...] > > I have a real drive to stay away from marketroids and sales/PR > > divisions in general. No, thank you. > > What is a 'marketroid'? Go away with divisions! Quoting from "The New Hacker's Dictionary": :marketroid: /mar'k*-troyd/ n. alt. `marketing slime', `marketeer', `marketing droid', `marketdroid'. A member of a company's marketing department, esp. one who promises users that the next version of a product will have features that are not actually scheduled for inclusion, are extremely difficult to implement, and/or are in violation of the laws of physics; and/or one who describes existing features (and misfeatures) in ebullient, buzzword-laden adspeak. Derogatory. Compare droid (*note droid::.). These are the guys (and sometimes also gals) you *have* to put into a separate division (and never feed them after midnight! ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 01:02:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa4-0007sa-00 for ; Wed, 05 Sep 2001 05:42:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:24 +0200 (CEST) Received: (qmail 17839 invoked by uid 0); 4 Sep 2001 23:03:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 4 Sep 2001 23:03:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA24552 for ; Tue, 4 Sep 2001 19:03:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 23:03:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA24304 for f-cpu-list; Tue, 4 Sep 2001 19:03:00 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA24301 for ; Tue, 4 Sep 2001 19:02:59 -0400 Received: from tribble.stud.uni-hannover.de (michael@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84N2v621353 for ; Tue, 4 Sep 2001 19:02:58 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01206; Wed, 5 Sep 2001 01:02:57 +0200 Message-ID: <20010905010257.23340@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 01:02:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Tue, Sep 04, 2001 at 09:58:15PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 09:58:15PM +0200, whygee@club-internet.fr wrote: [...] > >Unfortunately, like YG said, there isn't really anything to test yet. I > >have synthesised the multiplier source code just out of curiousity but > >there is no point in testing an incomplete unit. > i think that the multiplier is being currently > re-re-re-redesigned... don't worry :-) No, we were stuck when Synopsys ran out of memory (1GB wasn't enough). Josh, which version did you synthesize? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 01:24:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa6-0007sa-00 for ; Wed, 05 Sep 2001 05:42:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:26 +0200 (CEST) Received: (qmail 4871 invoked by uid 0); 4 Sep 2001 23:26:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 4 Sep 2001 23:26:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA26150 for ; Tue, 4 Sep 2001 19:25:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 4 Sep 2001 23:24:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA25916 for f-cpu-list; Tue, 4 Sep 2001 19:24:27 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA25913 for ; Tue, 4 Sep 2001 19:24:26 -0400 Received: from tribble.stud.uni-hannover.de (michael@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f84NON621634 for ; Tue, 4 Sep 2001 19:24:24 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01284; Wed, 5 Sep 2001 01:24:20 +0200 Message-ID: <20010905012420.64679@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 01:24:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] More Dark and Dusty Corners References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Tue, Sep 04, 2001 at 11:08:28PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Quick reply... On Tue, Sep 04, 2001 at 11:08:28PM +0200, whygee@club-internet.fr wrote: [...] > >> > According to the manual, the running SRB must finish before a new one > >> > can be started, but that's not appropriate -- why finish something you > >> > have to undo anyway? > > it is because when it returns, it would be very complicated > to know if the register was saved or something like that. > > In fact i think that i remember : If you interrupt one SRB > by another, we can't know which register belongs to what. [...] Hmm... gotta think that over. But there still are open questions. Is a context switch *one* SRB, or two (save/reload) in sequence? Do the "events" - syscall instruction - trap instruction - rfe instruction - external interrupt - exception/fault cause a context switch, or do they only save (or restore, in case of rfe) the registers? And where does the *new* CMB pointer come from if a second event occurs while the SRB from the first is still active (which probably triggers a second SRB)? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Wed Sep 5 02:00:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa7-0007sa-00 for ; Wed, 05 Sep 2001 05:42:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:27 +0200 (CEST) Received: (qmail 389 invoked by uid 0); 5 Sep 2001 00:07:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 5 Sep 2001 00:07:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA26978 for ; Tue, 4 Sep 2001 20:07:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 00:06:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA26719 for f-cpu-list; Tue, 4 Sep 2001 20:06:26 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA26716 for ; Tue, 4 Sep 2001 20:06:24 -0400 Received: from lvdi.net ([216.24.138.2]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f8506N622152 for ; Tue, 4 Sep 2001 20:06:24 -0400 Received: from lvdi.net ([151.201.31.214]) by lvdi.net ; Tue, 04 Sep 2001 17:06:15 2000 PDT Message-ID: <3B956B15.1011A497@lvdi.net> Date: Tue, 04 Sep 2001 20:00:21 -0400 From: Lee Salzman X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] More Dark and Dusty Corners Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee wrote: > hello, > > it seems that i have let this discussion pass... > here are some hints. > > BTW, how can a user-land SW emulate a virtual OS > if the instructions have to trap when emulation > must be done ? > The basic idea is that all instructions you want to virtualize must simply trap to supervisor code. That's about it. Then for each virtualized environment you want to keep, you maintain some tables that essentially are what the normal processor's control registers would store were they not virtualized. All the instructions you then want to virtualize are emulated by modifying/reading from this context instead of the real registers themselves. You just interpreter the instruction in the supervisor code, bump the return instruction pointer past it, and the code thinks the instruction executed in a non-virtualized fashion. > I have no idea of how it works on mainframes (heck) > but here is some idea : > 1) there is a "capability bit" which allows the running > code to modify its own Interrupt Routine Table pointer. > This way, the IRQ table can be stored in the user land > and be modified at will. Software interrupts/traps > occuring from THIS user program (of course) are redirected > to this table. HW interrupt and failures in the setup > of the new table are redirected to the kernel. > Note : When the bit is set, the "local IRQ table pointer" > is stored in the CMB. This isolates every task for each others. This is completely unnecessary, you only really want one global interrupt routing table for supervisor code. Per-thread tables are just as easily maintained via the virtualization methods described above. Usually, when your doing virtualization, the interrupt dispatching is much more complex than simply dispatching to the current thread and requires some extra maintenance by supervisor code (and hence supervisor code needs to intercept these interrupts anyway). > 2) setup the table so every "supervisor" instruction is > trapped and handled by our code. Other instructions are simply > "forwarded" (ie : FDIV emulation...) to the kernel by re-running > the code inside the trap handler or something like that. > > you're done. Lee ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 02:11:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa8-0007sa-00 for ; Wed, 05 Sep 2001 05:42:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:28 +0200 (CEST) Received: (qmail 30144 invoked by uid 0); 5 Sep 2001 00:13:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 5 Sep 2001 00:13:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA27321 for ; Tue, 4 Sep 2001 20:13:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 00:11:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA27047 for f-cpu-list; Tue, 4 Sep 2001 20:11:28 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA27044 for ; Tue, 4 Sep 2001 20:11:27 -0400 Received: from tribble.stud.uni-hannover.de (michael@a153.home.uni-hannover.de [130.75.232.153]) by moria.mit.edu (8.11.0/8.11.0) with ESMTP id f850BP622193 for ; Tue, 4 Sep 2001 20:11:25 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01673; Wed, 5 Sep 2001 02:11:20 +0200 Message-ID: <20010905021120.02103@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 02:11:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] the wrong way (or not?) concerning FP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Tue, Sep 04, 2001 at 10:28:37PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 10:28:37PM +0200, whygee@club-internet.fr wrote: [...] > here is an official request : > can you upload your files on f-cpu.seul.org ? Done. The latest eu_asu and eu_imu can be found in http://f-cpu.seul.org/new/fcpu-mr-20010905.tar.gz -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Wed Sep 5 01:57:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eTa8-0007sa-01 for ; Wed, 05 Sep 2001 05:42:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 05:42:28 +0200 (CEST) Received: (qmail 31253 invoked by uid 0); 5 Sep 2001 00:41:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 5 Sep 2001 00:41:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA28181 for ; Tue, 4 Sep 2001 20:41:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 00:40:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA27932 for f-cpu-list; Tue, 4 Sep 2001 20:40:53 -0400 Received: from moria.mit.edu (IDENT:root@MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA27929 for ; Tue, 4 Sep 2001 20:40:51 -0400 Received: from online.ln.cn ([202.96.74.85]) by moria.mit.edu (8.11.0/8.11.0) with SMTP id f850en622420 for ; Tue, 4 Sep 2001 20:40:50 -0400 Message-Id: <200109050040.f850en622420@moria.mit.edu> Received: from there([61.176.52.217]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm153b9584a9; Wed, 05 Sep 2001 08:36:54 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: [f-cpu] Related: Something YG may not have HURD ;-) Date: Wed, 5 Sep 2001 07:57:15 +0800 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id UAA27930 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001 15:44, you wrote: > On Mon, 3 Sep 2001 whygee@club-internet.fr wrote: > > Are there actally people working on Hurd? I haven't heard > anything for quite a while. > The dev list is about as active as that of FCPU. We have about 40% of Debian distro compiling successfully - mostly smaller apps as we started at the small end. This is all compatibility stuff. The big improvement will be when applications are written specifically to take advantage of HURDs many new features and capbilities. We have X, but not a lot of X applications (no Gnome or KDE which may or may not be a bad thing depending on your perspective ;-). HURD is not optimised. ie: it is slooooow. That is considered less important than getting the thing working at present. I'm sure this list can appreciate that. Current estimates for Hurd being reasonably mainstream usable are about a year down to the stable release of Debian/Woody. I believe the latter requires 80% of the Debian source archive to be compiled. The big missing part is a pthreads implimentation which means everything has to be ported to cthreads for the moment. This is being worked on and seems to be 95% there. There ate one or two other show-stoppers but no more than that. The mainstream of us testers are on Mach which is based on Linux 2.0 drivers. Some hackers have been using the OSkit microkernel with some sort of Mach component to provide something OSkit lacks. OSit has newer drivers (based on 2.2 [2.4??] linux kernel) Something called L4 also gets discussed occasionally when kernels come up. You can get the Kernel-Cousin HURD list summary off Linux Today (or, I assume, other news portals) every week or so. Here is the most recent monthly Hurd Orientation email: ########################################################                           Welcome to the Hurd                           =================== Welcome to the Hurd.  This email is automatically sent at the begining of each month to the help-hurd@gnu.org and debian-hurd@lists.debian.org mailing lists.  This message is intended for a quick orientation to new users. What is the Hurd? ----------------- The Hurd is GNU's Multiserver Microkernel operating system.  It is designed with the intention of fixing many of the flaws in *nix.  What are these flaws?  The arbitrary limits that it imposes on the user: there is not a whole lot that a user can do without special privileges. Consider an NFS filesystem.  Only root can mount this on a traditional *nix system.  Why is this?  It is not that NFS accesses anything dangerous, at least, it is no more dangerous than ftp.  However, as a portion of the NFS code lives in the kernel, this presents a potential security problem.  In the Hurd, a user can transparently mount a NFS filesystem directly into their home directory without affecting the security of the system as a whole.  And this is only the tip of the iceberg. Getting Started --------------- Installation Guides can be found at the following locations:         http://web.walfield.org/papers/hurd-installation-guide/         http://www.pick.ucam.org/~mcv21/hurd.html You can find out about ISO images at:         http://www.debian.org/ports/hurd/hurd-cd They come with a modified version of the Debian boot floppies making installation relatively simple. GNU Mach uses the drivers found in the Linux 2.0.x kernel.  Note, there is no support for PCMCIA.  Here is a HCL:         http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html Mailing Lists:   - bug-hurd@gnu.org:  Hurd and Mach development.   - help-hurd@gnu.org: General Hurd questions.   - web-hurd@gnu.org:  Maintenance of the hurd webpages at                        http://hurd.gnu.org.   - debian-hurd@lists.debian.org: All things related to Debian GNU/Hurd                        (especially porting issues). Subscribe in the usual fashion. The Hurd FAQ:         http://web.walfield.org/papers/hurd-faq/ Contributions ------------- A common question is: how can I contribute?  There are many tasks that need to be done:   - Help update the web pages at hurd.gnu.org.  Contact     web-hurd@gnu.org.   - Write documentation.   - Port applications.  Contact debian-hurd@lists.debian.org.  Look at     http://people.debian.org/~jbailey/turtle/group/Debian/index.html   - Write code.  Contact bug-hurd@gnu.org.  Look at:     http://www.debian.org/ports/hurd/hurd-devel-tasks, /tasks     and /TODO   - Send feedback.  This is, of course, the most important task of all:     Help us help others. Happy Hacking. ####################################################### Hope this is useful / interesting. Cheers, Glenn. BTW (WOT): a more thorough description of Universe A is now at: http://members.ozemail.com.au/~glenalec/lit/Universe A.html Some people seemed interested, thats all :-) -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.gnu.org / http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy. Use GNU! [ http://www.gnu.org ] -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 09:37:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZW-0006PS-00 for ; Wed, 05 Sep 2001 15:18:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:26 +0200 (CEST) Received: (qmail 16175 invoked by uid 0); 5 Sep 2001 11:58:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 5 Sep 2001 11:58:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06334 for ; Wed, 5 Sep 2001 07:58:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05134 for f-cpu-list; Wed, 5 Sep 2001 07:57:47 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05125 for ; Wed, 5 Sep 2001 07:57:46 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AviZ14905 for ; Wed, 5 Sep 2001 06:57:44 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eXF7-0002wp-00 for f-cpu@seul.org; Wed, 5 Sep 2001 09:37:01 +0200 Date: Wed, 5 Sep 2001 09:37:01 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: > hallo alle, > > >De: Juergen Goeritz > >On Tue, 4 Sep 2001, Michael Riepe wrote: > >> On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: > >> [...] > >> > > If you make a SoC that includes an F-CPU core, the source code for the > >> > > entire chip must be released under the terms of the GPL because it's a > >> > > derived work. If you can live with that restriction... > >> > No, I can't. I was wondering if it could be changed to the > >> > more open LGPL license style like with LEON. Is this possible? > >> We had that discussion (again!) some weeks ago... > >> For the moment, my answer is "no". > >That's a pity because I also don't want to open my design > >without any return involved. How to solve this situation? > > there is no "solution". Would you ask Micro$oft to change their > distribution licence ? :-P Why not? To ask doesn't cost a thing (but my own nerves). And for me they could be willing to make an exception :-) > There is a probability that the F-CPU licence will change > if we get advices from legal experts : GPL has a few drawbacks > but it's the only working licence that we know. Later, a F-CPU > licence will cover the dark corners of RTL source code (all the > problems with the meanings of "compilation" and "linking" that > is different in our case), but i don't believe that our basic > idea and understanding of "freedom" will change. But you also want to keep control. Ain't that a contradiction? > >> > On the other hand, if it's not possible to change to LGPL, > >> > I would not want to invest my own money but only go for it > >> > when there is enough funding money and goods. Up to now my > >> > opinion was that you can't really live from open projects. > >> > But you are invited to proove the opposite... > >> We have to prove nothing, since we never claimed to be able to make > >> money with the F-CPU. On the other hand, switching to LGPL won't make > >> us rich and famous, either. I agree that commercial F-CPU users might > >> benefit from LGPL, but my primary goal never was to enable companies to > >> make lots of money, without having to return *anything*. > >Hmh! Why not found an AG and you become shareholders until > >the proof of concept is done and the first chip released? > >This way we could start with only about 100K DM. > > how much chocolate could i buy with 100K DM ? Depends on the chocolate - I vote for cool Toblerone ;-) How much do you earn a year? Whether this is enough only depends on your usual way to spend the money... I just proposed to setup an environment where industry could relate to and go for contracts and license. Because either one wants to stay in control of something, then one has to take the responsibility, or one doesn't and is free of it. Even LEON is maintained by a company - Gaisler Research. > >> Interested in the mCluster project, or in F-CPU development? > >Interested in a new architecture that must be extendable > >and free the developer from that creapy kernel/driver and > >whatsoever low level adaption stuff and provide software > >portability. I do not focus on a processor alone... > > We do not "only" focus on the CPU : For example i am both > a programer and electronician (rather loosy both) and i have > remarked that the CPU is the center of both worlds. This is > why my efforts are in this direction. > > Concerning your reasons (I/O, programming model etc.), assume > that the CPU is the center of the computer. If the CPU is not > free the rest will remain crappy. OTOH, putting a "free" CPU > in the middle of a "non-free" HW won't solve everything > magically. No, in my opinion the cpu is not the center of the hardware because if you have multi cpu on chip which one should be the center? I see a cpu just as an information modification engine. Look at Richard, he thinks the display is the center of all. He is misleaded too. He just sees it from his application. The center may be the communication but from where to where? Look at cpu vs. memory. There is communication taking place (address vs. data). Look at two cpus - the same. Me think the center is the exchange of information! > Ok, i will let others answer (i've seen nicO's answer > and i fear a flame war...). No, why make a flame war. But it's very interesting to read your opinions and fears. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 10:01:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZX-0006PS-00 for ; Wed, 05 Sep 2001 15:18:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:27 +0200 (CEST) Received: (qmail 19950 invoked by uid 0); 5 Sep 2001 11:58:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 5 Sep 2001 11:58:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06338 for ; Wed, 5 Sep 2001 07:58:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05109 for f-cpu-list; Wed, 5 Sep 2001 07:57:44 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05106 for ; Wed, 5 Sep 2001 07:57:43 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AvgZ14902 for ; Wed, 5 Sep 2001 06:57:42 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eXd3-0002yJ-00 for f-cpu@seul.org; Wed, 5 Sep 2001 10:01:45 +0200 Date: Wed, 5 Sep 2001 10:01:44 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware In-Reply-To: <20010905010257.23340@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 09:58:15PM +0200, whygee@club-internet.fr wrote: > [...] > > >Unfortunately, like YG said, there isn't really anything to test yet. I > > >have synthesised the multiplier source code just out of curiousity but > > >there is no point in testing an incomplete unit. > > i think that the multiplier is being currently > > re-re-re-redesigned... don't worry :-) > > No, we were stuck when Synopsys ran out of memory (1GB wasn't enough). > Josh, which version did you synthesize? Now, do you have enough money to go for 2GB? 100K would be fine. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 09:51:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZX-0006PS-01 for ; Wed, 05 Sep 2001 15:18:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:27 +0200 (CEST) Received: (qmail 16299 invoked by uid 0); 5 Sep 2001 11:59:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 5 Sep 2001 11:59:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06474 for ; Wed, 5 Sep 2001 07:58:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05189 for f-cpu-list; Wed, 5 Sep 2001 07:57:50 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05157 for ; Wed, 5 Sep 2001 07:57:48 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AvkZ14908 for ; Wed, 5 Sep 2001 06:57:47 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eXSm-0002xt-00 for f-cpu@seul.org; Wed, 5 Sep 2001 09:51:08 +0200 Date: Wed, 5 Sep 2001 09:51:08 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] More Dark and Dusty Corners In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: > hello, > > it seems that i have let this discussion pass... > here are some hints. > > BTW, how can a user-land SW emulate a virtual OS > if the instructions have to trap when emulation > must be done ? > > I have no idea of how it works on mainframes (heck) > but here is some idea : > 1) there is a "capability bit" which allows the running > code to modify its own Interrupt Routine Table pointer. > This way, the IRQ table can be stored in the user land > and be modified at will. Software interrupts/traps > occuring from THIS user program (of course) are redirected > to this table. HW interrupt and failures in the setup > of the new table are redirected to the kernel. > Note : When the bit is set, the "local IRQ table pointer" > is stored in the CMB. This isolates every task for each others. Hey, there is a small problem here. There may be a lot of userland programs, all in need of such an own table for emulation of unimplemented instructions. The extreme would be to lead all instructions (nothing implemented) to the table -> deadlock. Therefore a basic instruction set that will always work must be defined. > 2) setup the table so every "supervisor" instruction is > trapped and handled by our code. Other instructions are simply > "forwarded" (ie : FDIV emulation...) to the kernel by re-running > the code inside the trap handler or something like that. > > you're done. layering could be a solution here. inner Layer: working cpu hardware opcodes middle Layer: emulated cpu opcodes (maybe onchip) shell around this: virtual 'complete' cpu I am talking about a chip still, no software delivery. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 09:58:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZY-0006PS-00 for ; Wed, 05 Sep 2001 15:18:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:28 +0200 (CEST) Received: (qmail 15816 invoked by uid 0); 5 Sep 2001 11:59:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 5 Sep 2001 11:59:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06547 for ; Wed, 5 Sep 2001 07:59:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05246 for f-cpu-list; Wed, 5 Sep 2001 07:57:54 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05191 for ; Wed, 5 Sep 2001 07:57:50 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AvnZ14911 for ; Wed, 5 Sep 2001 06:57:49 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eXZt-0002xv-00 for f-cpu@seul.org; Wed, 5 Sep 2001 09:58:29 +0200 Date: Wed, 5 Sep 2001 09:58:29 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010905004120.28005@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id HAA05192 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 07:58:15PM -0400, nicO wrote: > > Juergen Goeritz a écrit : > [...] > > > That's a pity because I also don't want to open my design > > > without any return involved. How to solve this situation? > > > > ??????????? We soon give you (and to the world) a quite complete cpu > > with really fast unit and a pretty good ISA, and you say that there > > isn't any return ! That's the goal of the GPL, i give my work to the > > world and nobody could steal my work but other could help me. If you give it for free nobody could steal it. Agreed! But do they also value it when it's for free? > > > > A- > > -men! > > Just have a base quitar and a djembe. Sounds strange but that may be related to the voice part. > Our source code is freely available; that's already much more than anybody > can expect, IMHO. I don't mind if somebody doesn't want to show his/her > code, but then (s)he shouldn't ask for more. > > But I guess Juergen meant "money" when he wrote "return"... Sure. The central problem stays 'how to make a living by doing the things one likes' ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 08:33:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZZ-0006PS-00 for ; Wed, 05 Sep 2001 15:18:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:29 +0200 (CEST) Received: (qmail 28015 invoked by uid 0); 5 Sep 2001 11:59:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 5 Sep 2001 11:59:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06579 for ; Wed, 5 Sep 2001 07:59:05 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05289 for f-cpu-list; Wed, 5 Sep 2001 07:57:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05219 for ; Wed, 5 Sep 2001 07:57:52 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AvoZ14914 for ; Wed, 5 Sep 2001 06:57:50 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eWFv-0002pb-00 for f-cpu@seul.org; Wed, 5 Sep 2001 08:33:47 +0200 Date: Wed, 5 Sep 2001 08:33:46 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <20010904211643.11853@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001, Michael Riepe wrote: > On Tue, Sep 04, 2001 at 03:38:42PM +0200, Juergen Goeritz wrote: > [...] > > > I have a real drive to stay away from marketroids and sales/PR > > > divisions in general. No, thank you. > > > > What is a 'marketroid'? Go away with divisions! > > Quoting from "The New Hacker's Dictionary": > > :marketroid: /mar'k*-troyd/ n. > > alt. `marketing slime', `marketeer', `marketing droid', > `marketdroid'. A member of a company's marketing department, > esp. one who promises users that the next version of a product > will have features that are not actually scheduled for inclusion, > are extremely difficult to implement, and/or are in violation > of the laws of physics; and/or one who describes existing > features (and misfeatures) in ebullient, buzzword-laden adspeak. > Derogatory. Compare droid (*note droid::.). > > These are the guys (and sometimes also gals) you *have* to put into a > separate division (and never feed them after midnight! ;) But why put them into a separate division only? Put them into another company and let them feed you. That's another company then... :-) And never feed them after midnight ... that's from a horror video with some cuddle monsters, is it gremlins? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Sep 5 08:42:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZZ-0006PS-01 for ; Wed, 05 Sep 2001 15:18:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:29 +0200 (CEST) Received: (qmail 13786 invoked by uid 0); 5 Sep 2001 11:59:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 5 Sep 2001 11:59:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id HAA06570 for ; Wed, 5 Sep 2001 07:59:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 11:57:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA05293 for f-cpu-list; Wed, 5 Sep 2001 07:57:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA05233 for ; Wed, 5 Sep 2001 07:57:52 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85AvpZ14917 for ; Wed, 5 Sep 2001 06:57:51 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15eWNt-0002pd-00; Wed, 5 Sep 2001 08:42:01 +0200 Date: Wed, 5 Sep 2001 08:42:01 +0200 (MEST) From: Juergen Goeritz To: RHARTNEY@bellsouth.net cc: f-cpu@seul.org Subject: Re: [f-cpu] mCluster In-Reply-To: <004701c13577$f88dafa0$9af53cd0@computer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hey, forget it! In the time of networking it's useless to focus on display terminals at all. You just need a single display! Only if you go for real-time cluster 3D simulation in some flight simulators or weather simulators will be more than a single display involved. And please stop your announcements on this mailing list now. Thank you. JG On Tue, 4 Sep 2001, Richard E. Hartny wrote: > Hello all. I see Jeurgen is working on a cluster - apparently several > or many display terminals. ... rest deleted ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Wed Sep 5 04:32:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ecZa-0006PS-00 for ; Wed, 05 Sep 2001 15:18:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 15:18:30 +0200 (CEST) Received: (qmail 1683 invoked by uid 0); 5 Sep 2001 12:17:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 5 Sep 2001 12:17:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA07196 for ; Wed, 5 Sep 2001 08:17:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 12:16:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA06944 for f-cpu-list; Wed, 5 Sep 2001 08:16:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA06941 for ; Wed, 5 Sep 2001 08:16:57 -0400 Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85BGuZ15626 for ; Wed, 5 Sep 2001 07:16:56 -0400 Received: from skule.ecf (fender@skule.ecf [128.100.8.6]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id WAA11994 for ; Tue, 4 Sep 2001 22:32:15 -0400 Received: from localhost (fender@localhost) by skule.ecf (SGI-8.9.3/8.9.3) with SMTP id WAA93563 for ; Tue, 4 Sep 2001 22:32:15 -0400 (EDT) X-Authentication-Warning: skule.ecf: fender owned process doing -bs Date: Tue, 4 Sep 2001 22:32:15 -0400 (EDT) From: Josh Fender X-Sender: fender@skule.ecf To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware In-Reply-To: <20010905010257.23340@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > >Unfortunately, like YG said, there isn't really anything to test yet. I > > >have synthesised the multiplier source code just out of curiousity but > > >there is no point in testing an incomplete unit. > > i think that the multiplier is being currently > > re-re-re-redesigned... don't worry :-) > > No, we were stuck when Synopsys ran out of memory (1GB wasn't enough). > > Josh, which version did you synthesize? I'm not sure the version, but I pulled it from CVS so hopefully it was new. I synthesised and compiled on a 4GB sun box. If your interested it was estimated to run at 8Mhz. Of course it wasn't designed for an FPGA and it didn't have any pipeline stages I believe so this number is meaningless. - Josh ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Wed Sep 5 09:11:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15edol-0008Up-00 for ; Wed, 05 Sep 2001 16:38:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 16:38:15 +0200 (CEST) Received: (qmail 32698 invoked by uid 0); 5 Sep 2001 13:47:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 5 Sep 2001 13:47:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA09478 for ; Wed, 5 Sep 2001 09:47:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 13:47:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA09226 for f-cpu-list; Wed, 5 Sep 2001 09:47:20 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA09223 for ; Wed, 5 Sep 2001 09:47:19 -0400 Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85ClJZ17099 for ; Wed, 5 Sep 2001 08:47:19 -0400 Received: from fwd01.sul.t-online.de by mailout00.sul.t-online.de with smtp id 15eWqW-0002uy-0H; Wed, 05 Sep 2001 09:11:36 +0200 Received: from (0893089296-0001@[62.226.150.112]) by fwd01.sul.t-online.com with smtp id 15eWqT-0woGVkC; Wed, 5 Sep 2001 09:11:33 +0200 From: Thilo.Reichelt@t-online.de (Reichelt) To: f-cpu@seul.org References: <3B94F7AD.733D7375@jetnet.ab.ca> Subject: Re: [f-cpu] More Dark and Dusty Corners X-Mailer: T-Online eMail 2.34 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Wed, 5 Sep 2001 09:11:33 +0200 Message-ID: <15eWqT-0woGVkC@fwd01.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk schrieb: ... > Why is a virtual cpu needed on the first revision? I don't mind > slow interrupt service providing hardware is defined for it - > dma access and fifo's where needed. The serial port on the PC ( > the whole pc) is a bad example of doing interrupts. What is > needed is smart - dumb hardware i/o controllers. If you you > define a virtual machine lets define virtual hardware that is > clean and works well. Bring back I/O control blocks? Pesudo > fixed memory frame buffers? More real time smarts. > Ben. > > -- > Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. > "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk > Now with schematics. I do not know whether anyone will need a virtual CPU some day in the future. I just suggested to make it possible, because someone might need it. If an application can determine whether it runs under a VM or not, the VM is not a very good VM. The VMs of Windows are not good VMs from this point of view. And they are an acceptable solution to problem of using applications and drivers for another OS (DOS) which a compromise at the best. I am thinking of VMs like VMware or Bochs here, where you have several virtual machines each including its OS on a single machine. There are people who need this, network simulations are one example. At www.vmware.com there is a paper somewhere, which explains that the i386 architecture does not really allow a VM. VMware has to replace drivers for the OS inside the VM to make it really work. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Sep 5 00:01:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ef3f-00028k-01 for ; Wed, 05 Sep 2001 17:57:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Sep 2001 17:57:43 +0200 (CEST) Received: (qmail 13653 invoked by uid 0); 5 Sep 2001 14:51:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 5 Sep 2001 14:51:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA10966 for ; Wed, 5 Sep 2001 10:51:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 14:51:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA10718 for f-cpu-list; Wed, 5 Sep 2001 10:51:29 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA10713 for ; Wed, 5 Sep 2001 10:51:28 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85DpRZ18677 for ; Wed, 5 Sep 2001 09:51:27 -0400 Received: from jetnet.ab.ca (dialin48.jetnet.ab.ca [207.153.6.48]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA04804 for ; Wed, 5 Sep 2001 08:51:25 -0600 (MDT) Message-ID: <3B954F4A.A4E7A452@jetnet.ab.ca> Date: Tue, 04 Sep 2001 16:01:46 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: <3B94F7AD.733D7375@jetnet.ab.ca> <15eWqT-0woGVkC@fwd01.sul.t-online.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I do not know whether anyone will need a virtual CPU some day in the future. > I just suggested to make it possible, because someone might need it. > > If an application can determine whether it runs under a VM or not, the VM is not > a very good VM. The VMs of Windows are not good VMs from this point of view. And > they are an acceptable solution to problem of using applications and drivers for > another OS (DOS) which a compromise at the best. > > I am thinking of VMs like VMware or Bochs here, where you have several virtual > machines each including its OS on a single machine. There are people who need > this, network simulations are one example. > > At www.vmware.com there is a paper somewhere, which explains that the i386 > architecture does not really allow a VM. VMware has to replace drivers for the > OS inside the VM to make it really work. But was the whole point of a REAL OS to hide all the I/O and abstract the devices so that you DON'T need virtual stuff. It is only a cheap and dirty way to run software,that really needs to be re-written or even re-compiled. Virtual machines are a throw back to a era when emulation of tube computers was a big thing and I/O was simple - 110 baud TTY or Flexwriter , paper tape and drum or tape drive. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 6 05:20:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVu-00076V-00 for ; Thu, 06 Sep 2001 08:19:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:46 +0200 (CEST) Received: (qmail 27079 invoked by uid 0); 5 Sep 2001 21:10:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 5 Sep 2001 21:10:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA05051 for ; Wed, 5 Sep 2001 17:10:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 21:09:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA04793 for f-cpu-list; Wed, 5 Sep 2001 17:09:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA04790 for ; Wed, 5 Sep 2001 17:09:57 -0400 Received: from localhost.localdomain (nas25-159.vlt.club-internet.fr [195.36.224.159]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85L9tZ28038 for ; Wed, 5 Sep 2001 17:09:55 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 71D0D1671 for ; Wed, 5 Sep 2001 23:20:36 -0400 (EDT) Message-ID: <3B96EB84.E2C829C2@ifrance.com> Date: Wed, 05 Sep 2001 23:20:36 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: <20010903144623.17602@thrai.stud.uni-hannover.de> <20010904140710.43571@thrai.stud.uni-hannover.de> <3B95699E.DB0AEA29@ifrance.com> <20010904215837.38420@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Sep 04, 2001 at 07:54:06PM -0400, nicO wrote: > [...] > > > We have to prove nothing, since we never claimed to be able to make > > > money with the F-CPU. On the other hand, switching to LGPL won't make > > > us rich and famous, either. I agree that commercial F-CPU users might > > > benefit from LGPL, but my primary goal never was to enable companies to > > > make lots of money, without having to return *anything*. > > > > I agree ! But Juergen should not forget that lgpl code said you could > > NOT modify the sources without redistribut it. > > No, you can modify and use (L)GPL code as much as you like, without > redistributing it. You only have to redistribute the source *together > with the resulting binaries*. If you never distribute the binaries > (i.e. use them only internally), you need not publish your changes at all. > The (L)GPL only specifies rules for modification and redistribution, > not for *using* a piece of GPLed code. Quoting from the GPL: > > Activities other than copying, distribution and modification are > not covered by this License; they are outside its scope. The act > of running the Program is not restricted, and the output from the > Program is covered only if its contents constitute a work based > on the Program (independent of having been made by running the > Program). Whether that is true depends on what the Program does. > > Disclaimer: I'm not a shark^H^H^H^H^Hlawyer. Mmh sorry, i'm shorten to much the licence. > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 6 05:25:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVu-00076V-01 for ; Thu, 06 Sep 2001 08:19:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:46 +0200 (CEST) Received: (qmail 10217 invoked by uid 0); 5 Sep 2001 21:15:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 5 Sep 2001 21:15:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA05383 for ; Wed, 5 Sep 2001 17:15:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 21:14:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA05124 for f-cpu-list; Wed, 5 Sep 2001 17:14:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA05121 for ; Wed, 5 Sep 2001 17:14:44 -0400 Received: from localhost.localdomain (nas25-159.vlt.club-internet.fr [195.36.224.159]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85LEgZ28206 for ; Wed, 5 Sep 2001 17:14:43 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 084E71671 for ; Wed, 5 Sep 2001 23:25:23 -0400 (EDT) Message-ID: <3B96ECA3.97ABAFE3@ifrance.com> Date: Wed, 05 Sep 2001 23:25:23 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More Dark and Dusty Corners References: <20010905012420.64679@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > Quick reply... > > On Tue, Sep 04, 2001 at 11:08:28PM +0200, whygee@club-internet.fr wrote: > [...] > > >> > According to the manual, the running SRB must finish before a new one > > >> > can be started, but that's not appropriate -- why finish something you > > >> > have to undo anyway? > > > > it is because when it returns, it would be very complicated > > to know if the register was saved or something like that. > > > > In fact i think that i remember : If you interrupt one SRB > > by another, we can't know which register belongs to what. > [...] > > Hmm... gotta think that over. > > But there still are open questions. Is a context switch *one* SRB, or > two (save/reload) in sequence? Do the "events" > > - syscall instruction > - trap instruction > - rfe instruction > - external interrupt > - exception/fault > > cause a context switch, or do they only save (or restore, in case of > rfe) the registers? And where does the *new* CMB pointer come from > if a second event occurs while the SRB from the first is still active > (which probably triggers a second SRB)? > And what about a "context switch" instruction (SRB ?)? Something that launch the SRB as previously design (asynchronous but in order) but explicitly so we cover different cases. nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 6 05:30:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVv-00076V-00 for ; Thu, 06 Sep 2001 08:19:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:47 +0200 (CEST) Received: (qmail 11613 invoked by uid 0); 5 Sep 2001 21:20:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 5 Sep 2001 21:20:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA05761 for ; Wed, 5 Sep 2001 17:20:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 21:20:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA05503 for f-cpu-list; Wed, 5 Sep 2001 17:20:04 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA05499 for ; Wed, 5 Sep 2001 17:20:02 -0400 Received: from localhost.localdomain (nas25-159.vlt.club-internet.fr [195.36.224.159]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85LK1Z28350 for ; Wed, 5 Sep 2001 17:20:01 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 3D4991671 for ; Wed, 5 Sep 2001 23:30:42 -0400 (EDT) Message-ID: <3B96EDE2.CEA3C4C3@ifrance.com> Date: Wed, 05 Sep 2001 23:30:42 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: > > > hallo alle, > > > > >De: Juergen Goeritz > > >On Tue, 4 Sep 2001, Michael Riepe wrote: > > >> On Tue, Sep 04, 2001 at 09:22:36AM +0200, Juergen Goeritz wrote: > > >> [...] > > >> > > If you make a SoC that includes an F-CPU core, the source code for the > > >> > > entire chip must be released under the terms of the GPL because it's a > > >> > > derived work. If you can live with that restriction... > > >> > No, I can't. I was wondering if it could be changed to the > > >> > more open LGPL license style like with LEON. Is this possible? > > >> We had that discussion (again!) some weeks ago... > > >> For the moment, my answer is "no". > > >That's a pity because I also don't want to open my design > > >without any return involved. How to solve this situation? > > > > there is no "solution". Would you ask Micro$oft to change their > > distribution licence ? :-P > > Why not? To ask doesn't cost a thing (but my own nerves). > And for me they could be willing to make an exception :-) > > > There is a probability that the F-CPU licence will change > > if we get advices from legal experts : GPL has a few drawbacks > > but it's the only working licence that we know. Later, a F-CPU > > licence will cover the dark corners of RTL source code (all the > > problems with the meanings of "compilation" and "linking" that > > is different in our case), but i don't believe that our basic > > idea and understanding of "freedom" will change. > > But you also want to keep control. Ain't that a contradiction? > > > >> > On the other hand, if it's not possible to change to LGPL, > > >> > I would not want to invest my own money but only go for it > > >> > when there is enough funding money and goods. Up to now my > > >> > opinion was that you can't really live from open projects. > > >> > But you are invited to proove the opposite... > > >> We have to prove nothing, since we never claimed to be able to make > > >> money with the F-CPU. On the other hand, switching to LGPL won't make > > >> us rich and famous, either. I agree that commercial F-CPU users might > > >> benefit from LGPL, but my primary goal never was to enable companies to > > >> make lots of money, without having to return *anything*. > > >Hmh! Why not found an AG and you become shareholders until > > >the proof of concept is done and the first chip released? > > >This way we could start with only about 100K DM. > > > > how much chocolate could i buy with 100K DM ? > > Depends on the chocolate - I vote for cool Toblerone ;-) > > How much do you earn a year? Whether this is enough only > depends on your usual way to spend the money... > > I just proposed to setup an environment where industry could > relate to and go for contracts and license. Because either one > wants to stay in control of something, then one has to take the > responsibility, or one doesn't and is free of it. Even LEON is > maintained by a company - Gaisler Research. You can't say that ! ESA have paid Jery Gaisler to wrote the LEON. Then he founded a compagny to sell it's knowledge to design chip with leon. nicO <...> > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 6 05:35:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVw-00076V-00 for ; Thu, 06 Sep 2001 08:19:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:48 +0200 (CEST) Received: (qmail 7403 invoked by uid 0); 5 Sep 2001 21:25:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 5 Sep 2001 21:25:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA06123 for ; Wed, 5 Sep 2001 17:25:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 21:25:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA05871 for f-cpu-list; Wed, 5 Sep 2001 17:25:03 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA05868 for ; Wed, 5 Sep 2001 17:25:02 -0400 Received: from localhost.localdomain (nas25-159.vlt.club-internet.fr [195.36.224.159]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85LP1Z28469 for ; Wed, 5 Sep 2001 17:25:01 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 79CC01671 for ; Wed, 5 Sep 2001 23:35:42 -0400 (EDT) Message-ID: <3B96EF0E.D8E5292@ifrance.com> Date: Wed, 05 Sep 2001 23:35:42 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Wed, 5 Sep 2001, Michael Riepe wrote: > > > On Tue, Sep 04, 2001 at 07:58:15PM -0400, nicO wrote: > > > Juergen Goeritz a écrit : > > [...] > > > > That's a pity because I also don't want to open my design > > > > without any return involved. How to solve this situation? > > > > > > ??????????? We soon give you (and to the world) a quite complete cpu > > > with really fast unit and a pretty good ISA, and you say that there > > > isn't any return ! That's the goal of the GPL, i give my work to the > > > world and nobody could steal my work but other could help me. > > If you give it for free nobody could steal it. Agreed! > But do they also value it when it's for free? > > > > > > > > > A- > > > > -men! > > > > > > Just have a base quitar and a djembe. Sounds strange but that > may be related to the voice part. > > > Our source code is freely available; that's already much more than anybody > > can expect, IMHO. I don't mind if somebody doesn't want to show his/her > > code, but then (s)he shouldn't ask for more. > > > > But I guess Juergen meant "money" when he wrote "return"... > > Sure. The central problem stays 'how to make a living by doing > the things one likes' ;-) > Personnaly i could see it when you want to create a product but a piece of it is to big for you or you didn't want to spend to much money for it. Your 'added value' aren't this part but the whole system. So you decide to use the GPL to be help to design this none-so-important part (from money back point of view). But then you use it to develop and sell your product. As IBM : devellop Linux to sell even more computers. nicO > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 6 05:50:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVx-00076V-00 for ; Thu, 06 Sep 2001 08:19:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:49 +0200 (CEST) Received: (qmail 7656 invoked by uid 0); 5 Sep 2001 21:40:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Sep 2001 21:40:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id RAA06704 for ; Wed, 5 Sep 2001 17:40:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 21:39:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id RAA06446 for f-cpu-list; Wed, 5 Sep 2001 17:39:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id RAA06443 for ; Wed, 5 Sep 2001 17:39:56 -0400 Received: from localhost.localdomain (nas25-159.vlt.club-internet.fr [195.36.224.159]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85LdsZ28983 for ; Wed, 5 Sep 2001 17:39:55 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6E9021671 for ; Wed, 5 Sep 2001 23:50:35 -0400 (EDT) Message-ID: <3B96F28B.45D36DF9@ifrance.com> Date: Wed, 05 Sep 2001 23:50:35 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Pb to connect to seul.org References: <3B96EF0E.D8E5292@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I can't connect anymore to seul.org : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is 20:b6:b1:84:61:cb:47:c8:51:41:68:da:9e:cf:03:10. Please contact your system administrator. Add correct host key in /home/XXXX/.ssh/known_hosts to get rid of this message. Offending key in /home/XXXX/.ssh/known_hosts:1 Password authentication is disabled to avoid trojan horses. Agent forwarding is disabled to avoid trojan horses. X11 forwarding is disabled to avoid trojan horses. Permission denied. --------- In other case, i didn't know how to see my fingerprint from ssh. But it work with ssh.seul.org. What happen ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 15:10:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVz-00076V-00 for ; Thu, 06 Sep 2001 08:19:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:51 +0200 (CEST) Received: (qmail 5266 invoked by uid 0); 5 Sep 2001 22:42:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 5 Sep 2001 22:42:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA11142 for ; Wed, 5 Sep 2001 18:42:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 22:41:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA10877 for f-cpu-list; Wed, 5 Sep 2001 18:41:56 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA10874 for ; Wed, 5 Sep 2001 18:41:55 -0400 Received: from tribble.stud.uni-hannover.de (root@a237.home.uni-hannover.de [130.75.232.237]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85MfkZ30069 for ; Wed, 5 Sep 2001 18:41:47 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00720; Wed, 5 Sep 2001 15:10:08 +0200 Message-ID: <20010905151008.43593@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 15:10:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware References: <20010905010257.23340@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Josh Fender on Tue, Sep 04, 2001 at 10:32:15PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 04, 2001 at 10:32:15PM -0400, Josh Fender wrote: [...] > > Josh, which version did you synthesize? > > I'm not sure the version, but I pulled it from CVS so hopefully it was > new. I synthesised and compiled on a 4GB sun box. If your interested it > was estimated to run at 8Mhz. Of course it wasn't designed for an FPGA > and it didn't have any pipeline stages I believe so this number is > meaningless. Can you please try the one I uploaded yesterday? http://f-cpu.seul.org/new/fcpu-mr-20010905.tar.gz -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 5 15:23:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esVz-00076V-01 for ; Thu, 06 Sep 2001 08:19:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:51 +0200 (CEST) Received: (qmail 16626 invoked by uid 0); 5 Sep 2001 22:42:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 5 Sep 2001 22:42:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA11342 for ; Wed, 5 Sep 2001 18:42:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 22:42:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA11066 for f-cpu-list; Wed, 5 Sep 2001 18:42:14 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA11057 for ; Wed, 5 Sep 2001 18:42:12 -0400 Received: from tribble.stud.uni-hannover.de (root@a237.home.uni-hannover.de [130.75.232.237]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85Mg9Z30076 for ; Wed, 5 Sep 2001 18:42:10 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00755; Wed, 5 Sep 2001 15:23:50 +0200 Message-ID: <20010905152350.46094@thrai.stud.uni-hannover.de> Date: Wed, 5 Sep 2001 15:23:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Sep 05, 2001 at 09:37:01AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 05, 2001 at 09:37:01AM +0200, Juergen Goeritz wrote: > On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: [...] > > There is a probability that the F-CPU licence will change > > if we get advices from legal experts : GPL has a few drawbacks > > but it's the only working licence that we know. Later, a F-CPU > > licence will cover the dark corners of RTL source code (all the > > problems with the meanings of "compilation" and "linking" that > > is different in our case), but i don't believe that our basic > > idea and understanding of "freedom" will change. > > But you also want to keep control. Ain't that a contradiction? No. We're the `benevolent dictators' who keep control to prevent (probably malevolent) others from gaining control. You wouldn't want Microsoft to buy Linux, would you? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Thu Sep 6 01:17:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15esW0-00076V-00 for ; Thu, 06 Sep 2001 08:19:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 08:19:52 +0200 (CEST) Received: (qmail 26720 invoked by uid 0); 5 Sep 2001 23:17:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 5 Sep 2001 23:17:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA14114 for ; Wed, 5 Sep 2001 19:17:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 5 Sep 2001 23:17:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA13891 for f-cpu-list; Wed, 5 Sep 2001 19:17:35 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA13888 for ; Wed, 5 Sep 2001 19:17:34 -0400 Received: from localhost (graham@localhost) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f85NHYG30733 for ; Wed, 5 Sep 2001 19:17:34 -0400 Date: Wed, 5 Sep 2001 19:17:34 -0400 (EDT) From: Graham Seaman To: Subject: Re: [f-cpu] Pb to connect to seul.org In-Reply-To: <3B96F28B.45D36DF9@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, nicO wrote: > I can't connect anymore to seul.org : > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ They had a faulty drive, which has been replaced. I guess the old ssh keys died with the old drive... You could try editing your file ~/.ssh/known_hosts to delete the old entry for seul.org (that worked for me) and trying again... good luck Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Thu Sep 6 09:47:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eubm-0001IQ-00 for ; Thu, 06 Sep 2001 10:33:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 10:33:58 +0200 (CEST) Received: (qmail 29746 invoked by uid 0); 6 Sep 2001 07:48:06 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 6 Sep 2001 07:48:06 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA09353 for ; Thu, 6 Sep 2001 03:48:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 07:47:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA09097 for f-cpu-list; Thu, 6 Sep 2001 03:47:19 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA09094 for ; Thu, 6 Sep 2001 03:47:18 -0400 Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f867lEw08571 for ; Thu, 6 Sep 2001 03:47:15 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA19240 for ; Thu, 6 Sep 2001 10:47:03 +0300 (EET DST) Date: Thu, 6 Sep 2001 10:47:02 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware In-Reply-To: <20010905151008.43593@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Can you please try the one I uploaded yesterday? > http://f-cpu.seul.org/new/fcpu-mr-20010905.tar.gz I compiled the multiplier to VirtexII 6000-6 chip with Synplify. Synplify only wanted ~350M mem maximum during the compilation. The compilation took time 2 hours. The speed was ~23MHz and utilization 54%. I did not optimize the design for speed and I didn't use retiming or pipelining options. During the compilation I got the following warnings: Synthesizing work.imul64.behave_1 @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":173:27:173:29|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":173:32:173:34|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":244:53:244:55|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":244:58:244:60|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":244:63:244:66|S ignal en_1 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":388:27:388:29|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":388:32:388:34|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":388:37:388:40|S ignal en_2 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":423:24:423:26|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":423:29:423:31|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":423:34:423:37|S ignal en_3 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":475:24:475:26|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":475:29:475:31|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":475:34:475:37|S ignal en_4 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":534:37:534:39|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":534:42:534:44|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":534:47:534:50|S ignal en_3 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":616:37:616:39|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":616:42:616:44|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":616:47:616:50|S ignal en_3 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":641:37:641:39|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":641:42:641:44|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":641:47:641:50|S ignal en_4 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":714:37:714:39|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":714:42:714:44|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":714:47:714:50|S ignal en_4 in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":803:37:803:39|S ignal clk in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":803:42:803:44|S ignal rst in the sensitivity list is not used in the process @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":803:47:803:50|S ignal en_5 in the sensitivity list is not used in the process Post processing for work.imul64.behave_1 @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":51:2:51:4|Input clk is unused @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":52:2:52:4|Input rst is unused @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":53:2:53:3|Input en is unused ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Sep 6 11:38:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eyJR-0005aO-00 for ; Thu, 06 Sep 2001 14:31:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 14:31:17 +0200 (CEST) Received: (qmail 18237 invoked by uid 0); 6 Sep 2001 09:47:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 6 Sep 2001 09:47:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA13269 for ; Thu, 6 Sep 2001 05:47:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 09:46:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA12608 for f-cpu-list; Thu, 6 Sep 2001 05:46:40 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA12605 for ; Thu, 6 Sep 2001 05:46:39 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f869kcw09782 for ; Thu, 6 Sep 2001 05:46:38 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15evcF-0004oN-00 for f-cpu@seul.org; Thu, 6 Sep 2001 11:38:31 +0200 Date: Thu, 6 Sep 2001 11:38:31 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <3B96EDE2.CEA3C4C3@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id FAA12606 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, nicO wrote: > Juergen Goeritz a écrit : > > I just proposed to setup an environment where industry could > > relate to and go for contracts and license. Because either one > > wants to stay in control of something, then one has to take the > > responsibility, or one doesn't and is free of it. Even LEON is > > maintained by a company - Gaisler Research. > > > You can't say that ! ESA have paid Jery Gaisler to wrote the LEON. Then > he founded a compagny to sell it's knowledge to design chip with leon. What's wrong with that? I personally met Jiri Gaisler at a workshop at ESTEC. I think he is doing a great job maintaining the LEON which ESA/ESTEC let him develop when he was employee at ESTEC. And I think it was a good idea to let him maintain the public part of the project with his own company now, because I don't think it's the duty of ESA to maintain it for the public side. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Sep 6 11:28:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eyJS-0005aO-00 for ; Thu, 06 Sep 2001 14:31:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 14:31:18 +0200 (CEST) Received: (qmail 3297 invoked by uid 0); 6 Sep 2001 09:47:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 6 Sep 2001 09:47:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA13368 for ; Thu, 6 Sep 2001 05:47:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 09:46:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA12659 for f-cpu-list; Thu, 6 Sep 2001 05:46:44 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA12642 for ; Thu, 6 Sep 2001 05:46:43 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f869kgw09786 for ; Thu, 6 Sep 2001 05:46:42 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15evSV-0004np-00 for f-cpu@seul.org; Thu, 6 Sep 2001 11:28:27 +0200 Date: Thu, 6 Sep 2001 11:28:27 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: <20010905152350.46094@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, Michael Riepe wrote: > On Wed, Sep 05, 2001 at 09:37:01AM +0200, Juergen Goeritz wrote: > > But you also want to keep control. Ain't that a contradiction? > > No. We're the `benevolent dictators' who keep control to prevent > (probably malevolent) others from gaining control. You wouldn't want > Microsoft to buy Linux, would you? Why would they want to buy 'good code'? By the way, why would you want to sell a free source anyway? All you could sell is the company. But that doesn't mean your free code will be less free afterwards. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Sep 6 11:46:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15eyJS-0005aO-01 for ; Thu, 06 Sep 2001 14:31:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 14:31:18 +0200 (CEST) Received: (qmail 9793 invoked by uid 0); 6 Sep 2001 09:47:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 6 Sep 2001 09:47:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id FAA13466 for ; Thu, 6 Sep 2001 05:47:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 09:46:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id FAA12731 for f-cpu-list; Thu, 6 Sep 2001 05:46:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id FAA12685 for ; Thu, 6 Sep 2001 05:46:45 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f869khw09790 for ; Thu, 6 Sep 2001 05:46:44 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15evkM-0004oP-00 for f-cpu@seul.org; Thu, 6 Sep 2001 11:46:54 +0200 Date: Thu, 6 Sep 2001 11:46:54 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <3B96EF0E.D8E5292@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 5 Sep 2001, nicO wrote: > > Personnaly i could see it when you want to create a product but a piece > of it is to big for you or you didn't want to spend to much money for > it. Your 'added value' aren't this part but the whole system. So you > decide to use the GPL to be help to design this none-so-important part > (from money back point of view). But then you use it to develop and sell > your product. As IBM : devellop Linux to sell even more computers. To my experience it is the other way round. Most new software was derived from a preexisting work. IBM did take Linux because it was already what it was - a very stable system. It is no use, even for a big company, to develop the same thing anew, maybe except you already have a very big customer base. IBM lost their (PC) customer base already two times. I assume they also will manage that a third time... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 6 13:53:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ezTy-0006OZ-01 for ; Thu, 06 Sep 2001 15:46:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 15:46:14 +0200 (CEST) Received: (qmail 26517 invoked by uid 0); 6 Sep 2001 12:26:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Sep 2001 12:26:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA27938 for ; Thu, 6 Sep 2001 08:26:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 12:25:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id IAA27428 for f-cpu-list; Thu, 6 Sep 2001 08:25:33 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id IAA27410 for ; Thu, 6 Sep 2001 08:25:32 -0400 Received: from tribble.stud.uni-hannover.de (root@a115.home.uni-hannover.de [130.75.232.115]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86CPTw11363 for ; Thu, 6 Sep 2001 08:25:30 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00454; Thu, 6 Sep 2001 13:53:57 +0200 Message-ID: <20010906135357.11391@thrai.stud.uni-hannover.de> Date: Thu, 6 Sep 2001 13:53:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware References: <20010905151008.43593@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Thu, Sep 06, 2001 at 10:47:02AM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 06, 2001 at 10:47:02AM +0300, Kim Enkovaara wrote: [...] > I compiled the multiplier to VirtexII 6000-6 chip with Synplify. Synplify > only wanted ~350M mem maximum during the compilation. The compilation > took time 2 hours. > > The speed was ~23MHz and utilization 54%. I did not optimize the design > for speed and I didn't use retiming or pipelining options. > > During the compilation I got the following warnings: > Synthesizing work.imul64.behave_1 > @W:"/home/kenkovaa/personal/fcpu-mr-20010905/eu_imu/imul64.vhdl":173:27:173:29|S > ignal clk in the sensitivity list is not used in the process That's because Imul64 is not pipelined by default. Please try the EU_IMU entity (in imu.vhdl). It includes Imul64 in its pipelined (6-stage) form which should run faster (and take longer to compile, of course ;). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Thu Sep 6 15:18:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ezU0-0006OZ-01 for ; Thu, 06 Sep 2001 15:46:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 15:46:16 +0200 (CEST) Received: (qmail 24806 invoked by uid 0); 6 Sep 2001 13:12:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Sep 2001 13:12:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id JAA10607 for ; Thu, 6 Sep 2001 09:12:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 13:12:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA10351 for f-cpu-list; Thu, 6 Sep 2001 09:12:31 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA10348 for ; Thu, 6 Sep 2001 09:12:30 -0400 Received: from imf12bis.bellsouth.net (mail112.mail.bellsouth.net [205.152.58.52]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86DCTw12254 for ; Thu, 6 Sep 2001 09:12:29 -0400 Received: from computer ([209.215.24.99]) by imf12bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010906131322.XOWI18534.imf12bis.bellsouth.net@computer>; Thu, 6 Sep 2001 09:13:22 -0400 Message-ID: <002b01c136d6$633c9320$6318d7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Re: Display Terminal Clusters Date: Thu, 6 Sep 2001 08:18:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C136AC.798C57C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C136AC.798C57C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I couldn't let it pass!!!!!!!!! Juergen Goeritz stated---- Hey, forget it! in the time of networking it's useless to focus on display terminals at all. you just need a single display! Only if you go for real-time cluster 3D simulation in some flight simulators or weather simulators will be more than a single display involved' And please stop your announcements on this mailing list now, Thank you JG And further; Look at Richard, he thinks the display is the center of all. He is misleaded too. He just sees it from his application. And my response is --------bullshit to both of your uneducated = responses. The number of terminals in any system is guided by the Processor = performance, if you don't want the user (people) to wait for data responses. Most = are presently unhappy with Novel networking because of WAIT time with = peak user requests. I have addressed the unhappy ones with the design of the ERIN32 -- an = M2M architecture. That is exactly where the f-cpu was at its inception = quite some time ago. And the f-cpu is targeted toward Game Machines = (single user) and Flight Simulators, and Weather simulators - very high = performance stuff. I am targeting the World of Business where more than = one terminal is required. =20 I stated all of the above before you entered the scene - Yann Guidon = knows this as well as others. Since all of my designs use SCHEMATIC input and f-cpu is VHDL, the = only help I can be is to provide what I have - if requested. I will continue to provide tidbits of information to f-cpu whether = you like it or not. And to f-cpu design team I say - keep going guys & gals!!!! Regards Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0028_01C136AC.798C57C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I couldn't let it = pass!!!!!!!!!
 
Juergen Goeritz stated----
 
Hey,
 
forget it!  in the time of = networking it's=20 useless to focus
on display terminals at all.  you = just need a=20 single display!
Only if you go for real-time cluster 3D = simulation=20 in some
flight simulators or weather simulators = will be=20 more than a
single display involved'
 
And please stop your announcements on = this mailing=20 list now,
Thank you
 
JG
 
And further;
 
Look at Richard, he thinks the display = is the=20 center of all.
He is misleaded too.  He just sees = it from his=20 application.
 
And my response is --------bullshit to = both of your=20 uneducated responses.
The number of terminals in any system = is guided by=20 the Processor performance,
if you don't want the user (people) to = wait for=20 data responses.  Most are presently unhappy with Novel networking = because=20 of WAIT time with peak user requests.
I have addressed the unhappy ones with = the design=20 of the ERIN32 -- an M2M architecture.  That is exactly where the = f-cpu was=20 at its inception quite some time ago.  And the f-cpu is targeted = toward=20 Game Machines (single user) and Flight Simulators,  and Weather = simulators=20 - very high performance stuff.  I am targeting the World of = Business where=20 more than one terminal is required. 
    I stated all of the = above before=20 you entered the scene - Yann Guidon knows this as well as = others.
    Since all of my = designs use=20 SCHEMATIC input and f-cpu is VHDL, the only help I can be is to provide = what I=20 have - if requested.
 
    I will continue to = provide=20 tidbits of information to f-cpu whether you like it or not.
And to f-cpu design team I say - keep = going guys=20 & gals!!!!
 
Regards
Richard E. Hartney
Research Director
Erin Greene &=20 Associates
------=_NextPart_000_0028_01C136AC.798C57C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Sep 6 16:02:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15f1iI-0000rD-00 for ; Thu, 06 Sep 2001 18:09:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Sep 2001 18:09:10 +0200 (CEST) Received: (qmail 16768 invoked by uid 0); 6 Sep 2001 14:00:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Sep 2001 14:00:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA13974 for ; Thu, 6 Sep 2001 10:00:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 13:59:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id JAA13716 for f-cpu-list; Thu, 6 Sep 2001 09:59:55 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id JAA13713 for ; Thu, 6 Sep 2001 09:59:54 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86Dxrw13116 for ; Thu, 6 Sep 2001 09:59:53 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15ezjs-0005KO-00; Thu, 6 Sep 2001 16:02:40 +0200 Date: Thu, 6 Sep 2001 16:02:40 +0200 (MEST) From: Juergen Goeritz To: RHARTNEY@bellsouth.net cc: f-cpu@seul.org Subject: Re: [f-cpu] Re: Display Terminal Clusters In-Reply-To: <002b01c136d6$633c9320$6318d7d1@computer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Sep 2001, Richard E. Hartny wrote: > I couldn't let it pass!!!!!!!!! > Juergen Goeritz stated---- > > forget it! in the time of networking it's useless to focus > on display terminals at all. you just need a single display! > Only if you go for real-time cluster 3D simulation in some > flight simulators or weather simulators will be more than a > single display involved' > > And please stop your announcements on this mailing list now, > Thank you > > JG > > And further; > > Look at Richard, he thinks the display is the center of all. > He is misleaded too. He just sees it from his application. > > And my response is --------bullshit to both of your uneducated responses. Seufz. Sorry to have scratched your pride. > The number of terminals in any system is guided by the Processor performance, I am more thinking in distributed systems with a lot of computation on a lot of nodes using pipelined or parallel processing. Most of the problems I work on are flow through problems for real-time or optimization stuff. The user interface is only for administrative and management purposes in my work. But I worked with 32 terminals on a normal UN*X machine in the 1980's. It worked well for the ttys without a lot of processer performance compared to todays performance. > if you don't want the user (people) to wait for data responses. Most are presently unhappy with Novel networking because of WAIT time with peak user requests. > I have addressed the unhappy ones with the design of the ERIN32 -- an M2M architecture. That is exactly where the f-cpu was at its inception quite some time ago. And the f-cpu is targeted toward Game Machines (single user) and Flight Simulators, and Weather simulators - very high performance stuff. I am targeting the World of Business where more than one terminal is required. > I stated all of the above before you entered the scene - Yann Guidon knows this as well as others. > Since all of my designs use SCHEMATIC input and f-cpu is VHDL, the only help I can be is to provide what I have - if requested. How about a bottleneck analysis of the applications instead? I never said that using a window system is the best. I still prefer to read and write ASCII on a tty and I know that the LPT/COM/Keyboard I/O handling in a PC is long outdated. ;-) > I will continue to provide tidbits of information to f-cpu whether you like it or not. SOS (sound of silence). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Sep 7 06:52:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fEuC-00085A-00 for ; Fri, 07 Sep 2001 08:14:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 08:14:20 +0200 (CEST) Received: (qmail 4685 invoked by uid 0); 6 Sep 2001 22:42:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 6 Sep 2001 22:42:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA06028 for ; Thu, 6 Sep 2001 18:42:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 22:42:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA05713 for f-cpu-list; Thu, 6 Sep 2001 18:42:11 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA05708 for ; Thu, 6 Sep 2001 18:42:10 -0400 Received: from localhost.localdomain (nas24-171.vlt.club-internet.fr [195.36.223.171]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86Mg9w23973 for ; Thu, 6 Sep 2001 18:42:09 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id F16251671 for ; Fri, 7 Sep 2001 00:52:50 -0400 (EDT) Message-ID: <3B9852A2.8E2BB1A2@ifrance.com> Date: Fri, 07 Sep 2001 00:52:50 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Pb to connect to seul.org References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Graham Seaman a écrit : > > On Wed, 5 Sep 2001, nicO wrote: > > > I can't connect anymore to seul.org : > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > They had a faulty drive, which has been replaced. > I guess the old ssh keys died with the old drive... > You could try editing your file ~/.ssh/known_hosts to > delete the old entry for seul.org (that worked for me) > and trying again... > Ok, things ! nicO > good luck > Graham > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Sep 7 06:56:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fEuC-00085A-01 for ; Fri, 07 Sep 2001 08:14:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 08:14:20 +0200 (CEST) Received: (qmail 26706 invoked by uid 0); 6 Sep 2001 22:45:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 6 Sep 2001 22:45:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA08066 for ; Thu, 6 Sep 2001 18:45:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 22:45:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA07616 for f-cpu-list; Thu, 6 Sep 2001 18:45:27 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA07598 for ; Thu, 6 Sep 2001 18:45:26 -0400 Received: from localhost.localdomain (nas24-171.vlt.club-internet.fr [195.36.223.171]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86MjOw24081 for ; Thu, 6 Sep 2001 18:45:25 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 714691671 for ; Fri, 7 Sep 2001 00:56:10 -0400 (EDT) Message-ID: <3B98536A.567598F@ifrance.com> Date: Fri, 07 Sep 2001 00:56:10 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Wed, 5 Sep 2001, nicO wrote: > > > > Personnaly i could see it when you want to create a product but a piece > > of it is to big for you or you didn't want to spend to much money for > > it. Your 'added value' aren't this part but the whole system. So you > > decide to use the GPL to be help to design this none-so-important part > > (from money back point of view). But then you use it to develop and sell > > your product. As IBM : devellop Linux to sell even more computers. > > To my experience it is the other way round. Most new software > was derived from a preexisting work. IBM did take Linux because > it was already what it was - a very stable system. It is no > use, even for a big company, to develop the same thing anew, > maybe except you already have a very big customer base. IBM > lost their (PC) customer base already two times. I assume they > also will manage that a third time... > So you could see the developpement of the LEON. Europeen Space compagny can't develop a cpu them self, so ESA payed for one. nicO > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 6 21:31:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fEuD-00085A-00 for ; Fri, 07 Sep 2001 08:14:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 08:14:21 +0200 (CEST) Received: (qmail 13188 invoked by uid 0); 6 Sep 2001 22:57:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Sep 2001 22:57:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA09613 for ; Thu, 6 Sep 2001 18:57:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 6 Sep 2001 22:57:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA09339 for f-cpu-list; Thu, 6 Sep 2001 18:57:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA09335 for ; Thu, 6 Sep 2001 18:57:31 -0400 Received: from tribble.stud.uni-hannover.de (root@a135.home.uni-hannover.de [130.75.232.135]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f86MvTw24201 for ; Thu, 6 Sep 2001 18:57:29 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA06788; Thu, 6 Sep 2001 21:31:46 +0200 Message-ID: <20010906213146.33753@thrai.stud.uni-hannover.de> Date: Thu, 6 Sep 2001 21:31:46 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description References: <20010905152350.46094@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Thu, Sep 06, 2001 at 11:28:27AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 06, 2001 at 11:28:27AM +0200, Juergen Goeritz wrote: > On Wed, 5 Sep 2001, Michael Riepe wrote: > > > On Wed, Sep 05, 2001 at 09:37:01AM +0200, Juergen Goeritz wrote: > > > But you also want to keep control. Ain't that a contradiction? > > > > No. We're the `benevolent dictators' who keep control to prevent > > (probably malevolent) others from gaining control. You wouldn't want > > Microsoft to buy Linux, would you? > > Why would they want to buy 'good code'? By the way, why > would you want to sell a free source anyway? All you > could sell is the company. But that doesn't mean your > free code will be less free afterwards. Code that is free remains free, that's right. But the problem with LGPL (as opposed to GPL) is that companies can add proprietary parts and redistribute the result without having to release the source of the *complete* program/system. The LGPLed part is still free, but the work as a whole is neither free nor open. Free Software (the *real*, GPLed one) comes at a price: if you use it, you can no longer hide behind patents, trade secrets, NDAs, lawyers and so on. We don't play "Null ouvert" -- you have to show your cards, too. If you don't like that -- don't use Free Software. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Sep 7 07:14:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fEuH-00085A-00 for ; Fri, 07 Sep 2001 08:14:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 08:14:25 +0200 (CEST) Received: (qmail 13457 invoked by uid 0); 7 Sep 2001 05:10:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 7 Sep 2001 05:10:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id BAA02247 for ; Fri, 7 Sep 2001 01:10:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 05:09:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id BAA01987 for f-cpu-list; Fri, 7 Sep 2001 01:09:36 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id BAA01984 for ; Fri, 7 Sep 2001 01:09:35 -0400 Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8759Zw30037 for ; Fri, 7 Sep 2001 01:09:35 -0400 Received: from computer ([208.60.244.229]) by imf08bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010907051027.SAED4320.imf08bis.bellsouth.net@computer>; Fri, 7 Sep 2001 01:10:27 -0400 Message-ID: <001901c1375c$18147f80$e5f43cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] mCLUSTER Date: Fri, 7 Sep 2001 00:14:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C13732.19FEB560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C13732.19FEB560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Couple things for Juergen--- You stated - How about a bottleneck analysis of the applications? We have. The bottleneck was - Process Bound and I/O bound with the = disk. Current implementation cures these ailments. The ideal situation now is = to become I/O bound - hard disk that is. I too worked with 32 TTY' s (64) to be exact (32 for hardware design and = 32 for Software Design.. All into a processor front-end to to the = Honeywell - number forgot. From these inputs we received about 4 hours = later a Mag Tape we used for Floating Point firmware (micro code as now = called) or Tape for hardware. Happy - NO. Twiddle'd our thumbs waiting. Now for for what I think you are trying to say about a distributed = system In 1976-78 I worked on a system called TASES (Tactical Airborne = Surveilance Exploitation System) It consisted of four Processors ( an = Emulation of the=20 NOVA-3 - Data General Mini). There was an IF (Intermediate Frequency) = processor, an Audio Processor, and Azimuth Processor and a DF (Direction = Finding) Processor. Prior to this system it a minute or two to get a = DF. This was reduced to approximately 50 milli-seconds. It was also = determined FRIEND or FOE. Russian or one of ours. What made this all = possible was a Programmer discription to me of an FFT Transform. A lot = of Multiplies and Add. So I investigated MUL for a good six months. = Ended up with what I called an AFG Board. AFG =3D arithmetic function = generator. Used a Time- sequence MUL, Bit Reversal, Square Root PROM = look-up, a Trig function I forget and a Memory containing Antenna = Correlation Coeficients. The audio was recorded and the Pilot of the = Aircraft was the lone human interface. With several Aircraft you = pinpoint, up or down, and where is it. Ours or theirs. Missle = away..... Am I on target - or is their more????? Regards Dick Hartney ------=_NextPart_000_0016_01C13732.19FEB560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Couple things for = Juergen---
 
You stated - How about a bottleneck = analysis of the=20 applications?
 
We have.  The bottleneck was - = Process Bound=20 and I/O bound with the disk.
Current implementation cures these = ailments. =20 The ideal situation now is to become I/O bound - hard disk that = is.
 
I too worked with 32 TTY' s (64) to be = exact (32=20 for hardware design and 32 for Software Design..  All into a = processor=20 front-end to to the Honeywell - number forgot. From these inputs we = received=20 about 4 hours later a Mag Tape we used for Floating Point firmware = (micro code=20 as now called) or Tape for hardware.  Happy - NO. Twiddle'd our = thumbs=20 waiting.
 
Now for for what I think you are trying = to say=20 about a distributed system
 
In 1976-78 I worked on a system called = TASES=20 (Tactical Airborne Surveilance Exploitation System)  It consisted = of four=20 Processors ( an Emulation of the
NOVA-3 - Data General Mini). There was = an IF=20 (Intermediate Frequency) processor, an Audio Processor, and Azimuth = Processor=20 and a DF (Direction Finding) Processor.  Prior to this system it a = minute=20 or two to get a DF.  This was reduced to approximately 50 = milli-seconds. It=20 was also determined FRIEND or FOE.  Russian or one of ours.  = What made=20 this all possible was a Programmer discription to me of an FFT = Transform. =20 A lot of Multiplies and Add.  So I investigated MUL for a good six=20 months.  Ended up with what I called an AFG Board.  AFG =3D = arithmetic=20 function generator.  Used a Time- sequence MUL, Bit Reversal, = Square Root=20 PROM look-up, a Trig function I forget and a Memory containing Antenna=20 Correlation Coeficients.  The audio was recorded and the Pilot of = the=20 Aircraft was the lone human interface. With several Aircraft you = pinpoint, up or=20 down, and where is it.  Ours or theirs.  Missle = away.....
 
Am I on target - or is their = more?????
 
Regards
Dick Hartney
 
 
------=_NextPart_000_0016_01C13732.19FEB560-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Fri Sep 7 09:29:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fJjz-0005TH-00 for ; Fri, 07 Sep 2001 13:24:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 13:24:07 +0200 (CEST) Received: (qmail 17303 invoked by uid 0); 7 Sep 2001 07:30:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Sep 2001 07:30:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id DAA11241 for ; Fri, 7 Sep 2001 03:30:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 07:29:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id DAA10995 for f-cpu-list; Fri, 7 Sep 2001 03:29:43 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id DAA10992 for ; Fri, 7 Sep 2001 03:29:42 -0400 Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f877Tfw31344 for ; Fri, 7 Sep 2001 03:29:42 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA10682 for ; Fri, 7 Sep 2001 10:29:39 +0300 (EET DST) Date: Fri, 7 Sep 2001 10:29:38 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware In-Reply-To: <20010906135357.11391@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Sep 2001, Michael Riepe wrote: > That's because Imul64 is not pipelined by default. Please try the EU_IMU > entity (in imu.vhdl). It includes Imul64 in its pipelined (6-stage) form > which should run faster (and take longer to compile, of course ;). OK, I resynthesized the multiplier. Actually the compilation went much faster (little over 1 hour only). Also this time I did the synthesis without any speed constraints. The results were following with the same VirtexII 6000-6 bf957. Speed: ~72MHz Utilization: 29% I can try the same with some speed constaints and with retiming. But that slows down the compilation quite much. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Sep 7 12:22:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fJk2-0005TH-01 for ; Fri, 07 Sep 2001 13:24:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 13:24:10 +0200 (CEST) Received: (qmail 21406 invoked by uid 0); 7 Sep 2001 10:53:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 7 Sep 2001 10:53:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA18138 for ; Fri, 7 Sep 2001 06:53:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 10:52:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA17406 for f-cpu-list; Fri, 7 Sep 2001 06:52:48 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA17397 for ; Fri, 7 Sep 2001 06:52:47 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Aqkw00706 for ; Fri, 7 Sep 2001 06:52:46 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15fImY-0006bA-00 for f-cpu@seul.org; Fri, 7 Sep 2001 12:22:42 +0200 Date: Fri, 7 Sep 2001 12:22:42 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: <20010906213146.33753@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Sep 2001, Michael Riepe wrote: > On Thu, Sep 06, 2001 at 11:28:27AM +0200, Juergen Goeritz wrote: > > On Wed, 5 Sep 2001, Michael Riepe wrote: > > > > > On Wed, Sep 05, 2001 at 09:37:01AM +0200, Juergen Goeritz wrote: > > > > But you also want to keep control. Ain't that a contradiction? > > > > > > No. We're the `benevolent dictators' who keep control to prevent > > > (probably malevolent) others from gaining control. You wouldn't want > > > Microsoft to buy Linux, would you? > > > > Why would they want to buy 'good code'? By the way, why > > would you want to sell a free source anyway? All you > > could sell is the company. But that doesn't mean your > > free code will be less free afterwards. > > Code that is free remains free, that's right. But the problem with > LGPL (as opposed to GPL) is that companies can add proprietary parts > and redistribute the result without having to release the source of the > *complete* program/system. The LGPLed part is still free, but the work > as a whole is neither free nor open. > > Free Software (the *real*, GPLed one) comes at a price: if you use it, > you can no longer hide behind patents, trade secrets, NDAs, lawyers and > so on. We don't play "Null ouvert" -- you have to show your cards, too. > > If you don't like that -- don't use Free Software. Hi Michael, thanks for explaining your point of view about free software. But with your remarks it does not seem to be free any more, but some kind of shared software. Why should one develop this software on, if one can't make a living of this? On the hardware side its a different world. One cannot just build a chip. One has to relate to a certain process and a certain library of a certain vendor to really make one. The chip manufacturing process is not comparable to the software development process. One works with acid/toxic things in expensive cleanroom environments using expensive machines. This means one has to invest a lot of money if one wants a design to be manufatured into a chip. Of course this is a very easy explanation... >From this point of view I cannot follow your idea that one has to share all the 'intelligence' that will be put into the design. Worst case szenario is that you want the asic manufacturer to open all their know-how as well. Did you draw the border in the license for f-cpu where it stops? Therefore my opinion is to use a more open license for all hardware related things. Maybe LGPL is not the best but it is at least a start. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Sep 7 12:31:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fJk3-0005TH-00 for ; Fri, 07 Sep 2001 13:24:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 13:24:11 +0200 (CEST) Received: (qmail 31738 invoked by uid 0); 7 Sep 2001 10:53:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Sep 2001 10:53:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA18134 for ; Fri, 7 Sep 2001 06:53:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 10:52:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA17378 for f-cpu-list; Fri, 7 Sep 2001 06:52:45 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA17375 for ; Fri, 7 Sep 2001 06:52:44 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Aqiw00701 for ; Fri, 7 Sep 2001 06:52:44 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15fIuj-0006cE-00 for f-cpu@seul.org; Fri, 7 Sep 2001 12:31:09 +0200 Date: Fri, 7 Sep 2001 12:31:09 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description In-Reply-To: <3B98536A.567598F@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id GAA17376 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Sep 2001, nicO wrote: > Juergen Goeritz a écrit : > > > > On Wed, 5 Sep 2001, nicO wrote: > > > > > > Personnaly i could see it when you want to create a product but a piece > > > of it is to big for you or you didn't want to spend to much money for > > > it. Your 'added value' aren't this part but the whole system. So you > > > decide to use the GPL to be help to design this none-so-important part > > > (from money back point of view). But then you use it to develop and sell > > > your product. As IBM : devellop Linux to sell even more computers. > > > > To my experience it is the other way round. Most new software > > was derived from a preexisting work. IBM did take Linux because > > it was already what it was - a very stable system. It is no > > use, even for a big company, to develop the same thing anew, > > maybe except you already have a very big customer base. IBM > > lost their (PC) customer base already two times. I assume they > > also will manage that a third time... > > > > So you could see the developpement of the LEON. Europeen Space compagny > can't develop a cpu them self, so ESA payed for one. No, ESA had a processor on SPARC V7 architecture licensed before which started to be too slow and inflexible for new developments. The idea now is to be able to build 'system on chip' designs for space. That's why they started to develop a compilable source code processor, the LEON. To be compatible to the old ERC32 they decided to stay with SPARC V8 architecture. There have been other designs, like Thor, that have not been used because of less performance as far as I know. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Sep 7 12:56:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fJk4-0005TH-00 for ; Fri, 07 Sep 2001 13:24:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 13:24:12 +0200 (CEST) Received: (qmail 3565 invoked by uid 0); 7 Sep 2001 10:53:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 7 Sep 2001 10:53:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id GAA18137 for ; Fri, 7 Sep 2001 06:53:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 10:52:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id GAA17455 for f-cpu-list; Fri, 7 Sep 2001 06:52:54 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id GAA17443 for ; Fri, 7 Sep 2001 06:52:53 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Aqrw00711 for ; Fri, 7 Sep 2001 06:52:53 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15fJIo-0006dt-00; Fri, 7 Sep 2001 12:56:02 +0200 Date: Fri, 7 Sep 2001 12:56:02 +0200 (MEST) From: Juergen Goeritz To: RHARTNEY@bellsouth.net cc: f-cpu@seul.org Subject: Re: [f-cpu] mCLUSTER In-Reply-To: <001901c1375c$18147f80$e5f43cd0@computer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Sep 2001, Richard E. Hartny wrote: > Couple things for Juergen--- > > You stated - How about a bottleneck analysis of the applications? > > We have. The bottleneck was - Process Bound and I/O bound with the disk. > Current implementation cures these ailments. The ideal situation now is to become I/O bound - hard disk that is. > > I too worked with 32 TTY' s (64) to be exact (32 for hardware design and 32 for Software Design.. All into a processor front-end to to the Honeywell - number forgot. From these inputs we received about 4 hours later a Mag Tape we used for Floating Point firmware (micro code as now called) or Tape for hardware. Happy - NO. Twiddle'd our thumbs waiting. > > Now for for what I think you are trying to say about a distributed system > > In 1976-78 I worked on a system called TASES (Tactical Airborne Surveilance Exploitation System) It consisted of four Processors ( an Emulation of the > NOVA-3 - Data General Mini). There was an IF (Intermediate Frequency) processor, an Audio Processor, and Azimuth Processor and a DF (Direction Finding) Processor. Prior to this system it a minute or two to get a DF. This was reduced to approximately 50 milli-seconds. It was also determined FRIEND or FOE. Russian or one of ours. What made this all possible was a Programmer discription to me of an FFT Transform. A lot of Multiplies and Add. So I investigated MUL for a good six months. Ended up with what I called an AFG Board. AFG = arithmetic function generator. Used a Time- sequence MUL, Bit Reversal, Square Root PROM look-up, a Trig function I forget and a Memory containing Antenna Correlation Coeficients. The audio was recorded and the Pilot of the Aircraft was the lone human interface. With several Aircraft you pinpoint, up or down, and where is it. Ours or theirs. Missle away..... > > Am I on target - or is their more????? Hi, quite interesting and I didn't mean to let you down before. There are a lot of views one can take of systems. In a cpu design it's only necessary to have a fast switching time to serve external events without loosing the many things done for the 'main' task (e.g. register, cache contence...). But even this can be improved or equalled by a buffered/cached IO subsystem design that even may use some local intelligence. By the way mCluster is supposed to have up to 1000 cpu nodes in a single qubic meter but it's not sure that it will ever come with f-cpu. ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Fri Sep 7 16:13:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fP7v-00034t-01 for ; Fri, 07 Sep 2001 19:09:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 19:09:11 +0200 (CEST) Received: (qmail 13405 invoked by uid 0); 7 Sep 2001 14:21:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 7 Sep 2001 14:21:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA06741 for ; Fri, 7 Sep 2001 10:21:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 14:21:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA06504 for f-cpu-list; Fri, 7 Sep 2001 10:21:33 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA06501 for ; Fri, 7 Sep 2001 10:21:32 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87ELWw03710 for ; Fri, 7 Sep 2001 10:21:32 -0400 Received: from art1.none.de (dialin174.pg1-nt.berlin.nikoma.de [213.54.64.174]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f87ELXK15511 for ; Fri, 7 Sep 2001 16:21:33 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin174.pg1-nt.berlin.nikoma.de [213.54.64.174] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15fMP4-0002YX-00 for ; Fri, 07 Sep 2001 16:14:42 +0200 Date: Fri, 7 Sep 2001 16:13:46 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Why we need GPL? was: Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, On Fri, 7 Sep 2001, Juergen Goeritz wrote: > On the hardware side its a different world. One cannot just It is not. The question is what is Software or Sourcecode? It is the way to do things to solve a problem, it is an algorithm. If we can use a hardware description language, so it changes the way how hardware is produced, hardware will be similiar to software in the way of development. Now, we can differ between two things, a general description to do something, and a detailled description to do something. You can compare the first one with a specification of an interface and the second one with a realization of an interface (in software-world). The F-CPU-Project is similiar to the first one. ok. > Therefore my opinion is to use a more open license for > all hardware related things. Maybe LGPL is not the best > but it is at least a start. The GPL is very well, because we have the full control about the "interface". The differences between GPL and BSD par example is that GPL depends on a "bad" view of human behaviour, and BSD on a "good" view of human behaviour, both want be follow the idea "Who uses 10000 lines of code, should/must return 10 lines of code". Because hardware can be described with "sourcecode", we can use all mechanism of software development, too. Because we share our knowledge/ideas in the way of software developing, we must protect us and the project like well prooved license for free and open software. Is not it? Bye Andreas ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 7 15:42:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fRLx-0005ho-01 for ; Fri, 07 Sep 2001 21:31:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 21:31:49 +0200 (CEST) Received: (qmail 20892 invoked by uid 0); 7 Sep 2001 17:19:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 7 Sep 2001 17:19:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA23343 for ; Fri, 7 Sep 2001 13:19:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 17:19:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA23083 for f-cpu-list; Fri, 7 Sep 2001 13:19:17 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA23080 for ; Fri, 7 Sep 2001 13:19:16 -0400 Received: from tribble.stud.uni-hannover.de (root@a033.home.uni-hannover.de [130.75.232.33]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87HJEw07306 for ; Fri, 7 Sep 2001 13:19:14 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00755; Fri, 7 Sep 2001 15:42:44 +0200 Message-ID: <20010907154243.47384@thrai.stud.uni-hannover.de> Date: Fri, 7 Sep 2001 15:42:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description References: <20010906213146.33753@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Fri, Sep 07, 2001 at 12:22:42PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Sep 07, 2001 at 12:22:42PM +0200, Juergen Goeritz wrote: [...] > thanks for explaining your point of view about free software. De nada :) > But with your remarks it does not seem to be free any more, > but some kind of shared software. Why should one develop this > software on, if one can't make a living of this? It *is* "some kind of shared software", and the word "free" never meant "gratis". Why one should use and improve Free Software? Because it improves your karma and brightens your teeth (I don't remember who said that, maybe Linus Torvalds). > On the hardware side its a different world. One cannot just > build a chip. One has to relate to a certain process and a > certain library of a certain vendor to really make one. The > chip manufacturing process is not comparable to the software > development process. One works with acid/toxic things in > expensive cleanroom environments using expensive machines. > This means one has to invest a lot of money if one wants > a design to be manufatured into a chip. Of course this is a > very easy explanation... On the software side, you work on a certain machine, with a certain operating system and compiler, and you link your program with certain system libraries which can all be proprietary, too. Of course this is a very easy explanation ;) You may not be able to make chips at home, in your living room or on your kitchen table, but it's no black art either. In the future, it might be as easy as photographing -- you take a picture (design a circuit), send it to the laboratory, and get the result back within less than 24 hours. They also use acid/toxic/bad-smelling substances, by the way, but you're not required to know anything about the chemical and physical processes or the materials involved. > >From this point of view I cannot follow your idea that one > has to share all the 'intelligence' that will be put into > the design. Worst case szenario is that you want the asic > manufacturer to open all their know-how as well. Did you > draw the border in the license for f-cpu where it stops? The border is almost the same as in the software world. The system libraries come with the OS, and are usually not free, but you can use them in a GPLed program. Analogously, an ASIC manufacturer can use (usually proprietary) technology libraries and chip manufacturing processes when building an F-CPU chip. On the "macroscopic" side, a GPLed program may run a proprietary tool in a separate process and communicate with it via files, pipes, sockets, shared memory or whatever. The GNU compiler runs as(1) and ld(1) this way, for example. An F-CPU chip (or F-CPU based SoC) can be plugged into a socket (more general, mounted on a PCB) and connected to other chips and sockets, and communicate with them in one of the usual ways. Of course it would be nice if the rest of the system were free as well (like Linux or GNU on the software side), but that is not required. > Therefore my opinion is to use a more open license for > all hardware related things. Maybe LGPL is not the best > but it is at least a start. Why don't *you* use a more open license? As far as I understood, you don't intend to release your source code at all, do you? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 7 14:00:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fRLy-0005ho-00 for ; Fri, 07 Sep 2001 21:31:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 21:31:50 +0200 (CEST) Received: (qmail 8487 invoked by uid 0); 7 Sep 2001 17:20:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 7 Sep 2001 17:20:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA23627 for ; Fri, 7 Sep 2001 13:20:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 17:19:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA23364 for f-cpu-list; Fri, 7 Sep 2001 13:19:58 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA23361 for ; Fri, 7 Sep 2001 13:19:56 -0400 Received: from tribble.stud.uni-hannover.de (root@a033.home.uni-hannover.de [130.75.232.33]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87HJnw07323 for ; Fri, 7 Sep 2001 13:19:50 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00464; Fri, 7 Sep 2001 14:00:11 +0200 Message-ID: <20010907140010.51301@thrai.stud.uni-hannover.de> Date: Fri, 7 Sep 2001 14:00:10 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware References: <20010906135357.11391@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Fri, Sep 07, 2001 at 10:29:38AM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Sep 07, 2001 at 10:29:38AM +0300, Kim Enkovaara wrote: [...] > OK, I resynthesized the multiplier. Actually the compilation went much > faster (little over 1 hour only). Also this time I did the synthesis > without any speed constraints. The results were following with the same > VirtexII 6000-6 bf957. > > Speed: ~72MHz Is that good or bad for that particular FPGA? > Utilization: 29% How can it become *smaller* when pipelining is turned on? Or is that caused by the missing speed constraints? > I can try the same with some speed constaints and with retiming. But that > slows down the compilation quite much. I know... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Fri Sep 7 19:45:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fRLz-0005ho-01 for ; Fri, 07 Sep 2001 21:31:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 21:31:51 +0200 (CEST) Received: (qmail 32096 invoked by uid 0); 7 Sep 2001 17:46:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 7 Sep 2001 17:46:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA24375 for ; Fri, 7 Sep 2001 13:46:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 17:45:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA24112 for f-cpu-list; Fri, 7 Sep 2001 13:45:56 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA24109 for ; Fri, 7 Sep 2001 13:45:55 -0400 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Hjtw07680 for ; Fri, 7 Sep 2001 13:45:55 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id UAA22851 for ; Fri, 7 Sep 2001 20:45:53 +0300 (EET DST) Date: Fri, 7 Sep 2001 20:45:53 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Testing Hardware In-Reply-To: <20010907140010.51301@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Sep 2001, Michael Riepe wrote: > > VirtexII 6000-6 bf957. > > > > Speed: ~72MHz > > Is that good or bad for that particular FPGA? I think that is quite good. It's the fastest FPGA available, but 64-bit multiplier is quite a big block. Also VII/6000 is the biggest FPGA chip that is available currently (for some customers as samples). I can on monday test what Synplify does if I just say A*B for 64 bit vectors and give 6 clocks time for that and enable pipelining :) Synplify should make better multiplier than Xilinx coregen at least. I just have to figure out a way where Synplify won't use the internal multipliers of VirtexII. > > Utilization: 29% > > How can it become *smaller* when pipelining is turned on? > Or is that caused by the missing speed constraints? I think one reason is that the combinatorial part is much smaller (between flipflops) and that is easier to fit to FPGA structures. In FPGA one logic block is limited to 4 inputs. The schematic view had something like 400 sheets. I didn't have time do look what the synthesis really produced. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Sep 8 02:39:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fRM1-0005ho-01 for ; Fri, 07 Sep 2001 21:31:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Sep 2001 21:31:53 +0200 (CEST) Received: (qmail 7905 invoked by uid 0); 7 Sep 2001 18:28:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Sep 2001 18:28:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA27888 for ; Fri, 7 Sep 2001 14:28:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 18:28:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA27630 for f-cpu-list; Fri, 7 Sep 2001 14:28:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA27627 for ; Fri, 7 Sep 2001 14:28:31 -0400 Received: from localhost.localdomain (nas25-225.vlt.club-internet.fr [195.36.224.225]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87ISUw08636 for ; Fri, 7 Sep 2001 14:28:30 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 37EF1165F for ; Fri, 7 Sep 2001 20:39:20 -0400 (EDT) Message-ID: <3B9968B8.9BDEEDF8@ifrance.com> Date: Fri, 07 Sep 2001 20:39:20 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Thu, 6 Sep 2001, Michael Riepe wrote: > > > On Thu, Sep 06, 2001 at 11:28:27AM +0200, Juergen Goeritz wrote: > > > On Wed, 5 Sep 2001, Michael Riepe wrote: > > > > > > > On Wed, Sep 05, 2001 at 09:37:01AM +0200, Juergen Goeritz wrote: > > > > > But you also want to keep control. Ain't that a contradiction? > > > > > > > > No. We're the `benevolent dictators' who keep control to prevent > > > > (probably malevolent) others from gaining control. You wouldn't want > > > > Microsoft to buy Linux, would you? > > > > > > Why would they want to buy 'good code'? By the way, why > > > would you want to sell a free source anyway? All you > > > could sell is the company. But that doesn't mean your > > > free code will be less free afterwards. > > > > Code that is free remains free, that's right. But the problem with > > LGPL (as opposed to GPL) is that companies can add proprietary parts > > and redistribute the result without having to release the source of the > > *complete* program/system. The LGPLed part is still free, but the work > > as a whole is neither free nor open. > > > > Free Software (the *real*, GPLed one) comes at a price: if you use it, > > you can no longer hide behind patents, trade secrets, NDAs, lawyers and > > so on. We don't play "Null ouvert" -- you have to show your cards, too. > > > > If you don't like that -- don't use Free Software. > > Hi Michael, > > thanks for explaining your point of view about free software. > But with your remarks it does not seem to be free any more, > but some kind of shared software. Why should one develop this > software on, if one can't make a living of this? > > On the hardware side its a different world. One cannot just > build a chip. One has to relate to a certain process and a > certain library of a certain vendor to really make one. The > chip manufacturing process is not comparable to the software > development process. One works with acid/toxic things in > expensive cleanroom environments using expensive machines. > This means one has to invest a lot of money if one wants > a design to be manufatured into a chip. Of course this is a > very easy explanation... GPL is a copyright based licence so it cover only text file. All library or things like that aren't concern at all. I should discuss with a lawyer from April but i didn't see her at the "first jeudi" a meeting in Paris for the linuxfr.org reader. That's a pitty because this issue should be more precise. nicO > > >From this point of view I cannot follow your idea that one > has to share all the 'intelligence' that will be put into > the design. Worst case szenario is that you want the asic > manufacturer to open all their know-how as well. Did you > draw the border in the license for f-cpu where it stops? > > Therefore my opinion is to use a more open license for > all hardware related things. Maybe LGPL is not the best > but it is at least a start. > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Sep 7 16:50:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fVsC-0002dv-00 for ; Sat, 08 Sep 2001 02:21:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 02:21:24 +0200 (CEST) Received: (qmail 20726 invoked by uid 0); 7 Sep 2001 19:56:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 7 Sep 2001 19:56:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA31155 for ; Fri, 7 Sep 2001 15:56:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 19:56:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA30896 for f-cpu-list; Fri, 7 Sep 2001 15:56:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA30893 for ; Fri, 7 Sep 2001 15:56:06 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Ju6w10644 for ; Fri, 7 Sep 2001 15:56:06 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15fMxr-00074T-00 for f-cpu@seul.org; Fri, 7 Sep 2001 16:50:39 +0200 Date: Fri, 7 Sep 2001 16:50:38 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Why we need GPL? was: Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Sep 2001, Andreas Romeyke wrote: > Hello, > > On Fri, 7 Sep 2001, Juergen Goeritz wrote: > > > On the hardware side its a different world. One cannot just > > It is not. The question is what is Software or Sourcecode? It is the way > to do things to solve a problem, it is an algorithm. What about the vendor libraries. This is source code too. What about routing algorithms, crosstalk algorithms that must be used to get your source into being. > If we can use a hardware description language, so it changes the way how > hardware is produced, hardware will be similiar to software in the way of > development. > Now, we can differ between two things, a general description to do > something, and a detailled description to do something. You can compare > the first one with a specification of an interface and the second one > with a realization of an interface (in software-world). > > The F-CPU-Project is similiar to the first one. > > ok. Maybe you are right here but there is one big difference. Software execution relies on hardware to run the binaries. Hardware development won't produce any binaries but chips. What does GPL say about binaries or chips? What does GPL state for these binaries or chips when it comes to add other binaries or chip parts? What if one develops an own program, compiles it and uses it together with another compiled program in an operating system (or chip)? Is the operating system automatically to be open source? If you don't put the sources together - what happens? Do you still think GPL will work? > > Therefore my opinion is to use a more open license for > > all hardware related things. Maybe LGPL is not the best > > but it is at least a start. > > The GPL is very well, because we have the full control about the > "interface". The differences between GPL and BSD par example is that GPL > depends on a "bad" view of human behaviour, and BSD on a "good" view of > human behaviour, both want be follow the idea "Who uses 10000 lines of > code, should/must return 10 lines of code". > > Because hardware can be described with "sourcecode", we can use all > mechanism of software development, too. Because we share our > knowledge/ideas in the way of software developing, we must protect us and > the project like well prooved license for free and open software. > > Is not it? Yes, I agree with protection. But you are focusing on the source only but hardware will be the chip. Do you want to prevent 'illegal' f-cpu chips to come to market and how can GPL manage to protect it? Just for thinking... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 8 00:48:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fVsG-0002dv-00 for ; Sat, 08 Sep 2001 02:21:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 02:21:28 +0200 (CEST) Received: (qmail 2818 invoked by uid 0); 7 Sep 2001 22:49:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 7 Sep 2001 22:49:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id SAA02751 for ; Fri, 7 Sep 2001 18:49:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 22:48:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id SAA02496 for f-cpu-list; Fri, 7 Sep 2001 18:48:42 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id SAA02491 for ; Fri, 7 Sep 2001 18:48:41 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Mmfw13289 for ; Fri, 7 Sep 2001 18:48:41 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA03046 for f-cpu@seul.org; Sat, 8 Sep 2001 00:48:38 +0200 (MET DST) Date: Sat, 8 Sep 2001 00:48:38 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id SAA02492 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: nicO > >GPL is a copyright based licence so it cover only text file. All library >or things like that aren't concern at all. I should discuss with a >lawyer from April but i didn't see her at the "first jeudi" a meeting in >Paris for the linuxfr.org reader. That's a pitty because this issue >should be more precise. > >nicO i'm sad you didn't meet her. i follow this discussion very loosely because i access Internet every few days during some minutes. If a new licence is written, i'll be there. I am embarrassed too by this issue. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 8 01:14:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fVsH-0002dv-00 for ; Sat, 08 Sep 2001 02:21:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 02:21:29 +0200 (CEST) Received: (qmail 15220 invoked by uid 0); 7 Sep 2001 23:14:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 7 Sep 2001 23:14:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA03334 for ; Fri, 7 Sep 2001 19:14:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 23:14:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA03081 for f-cpu-list; Fri, 7 Sep 2001 19:14:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA03076 for ; Fri, 7 Sep 2001 19:14:08 -0400 Received: from tribble.stud.uni-hannover.de (michael@a154.home.uni-hannover.de [130.75.232.154]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87NE7w13626 for ; Fri, 7 Sep 2001 19:14:07 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA04774; Sat, 8 Sep 2001 01:14:03 +0200 Message-ID: <20010908011403.38762@thrai.stud.uni-hannover.de> Date: Sat, 8 Sep 2001 01:14:03 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Upload Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! I have uploaded a `double-zero' version of my assembler. It won't compile on most systems (maybe on Solaris, but you'll need my not-yet-released new version of libelf on other OSes), but it might be interesting anyway. Have a look at http://f-cpu.seul.org/new/mr-as-0.0.tar.gz -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 8 01:17:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fVsH-0002dv-01 for ; Sat, 08 Sep 2001 02:21:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 02:21:29 +0200 (CEST) Received: (qmail 18955 invoked by uid 0); 7 Sep 2001 23:18:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 7 Sep 2001 23:18:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA03658 for ; Fri, 7 Sep 2001 19:18:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 23:18:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA03400 for f-cpu-list; Fri, 7 Sep 2001 19:18:02 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA03397 for ; Fri, 7 Sep 2001 19:18:01 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87NI1w13715 for ; Fri, 7 Sep 2001 19:18:02 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id BAA10261 for f-cpu@seul.org; Sat, 8 Sep 2001 01:17:59 +0200 (MET DST) Date: Sat, 8 Sep 2001 01:17:59 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] EU X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id TAA03398 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, after my mail to the EU i recently got a first answer/contact. There is no 'exact' project description (that fits in 3 lines) so it will take some time before we find something to collaborate on. i keep you informed. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 8 01:37:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15fVsI-0002dv-00 for ; Sat, 08 Sep 2001 02:21:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 02:21:30 +0200 (CEST) Received: (qmail 25657 invoked by uid 0); 7 Sep 2001 23:37:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 7 Sep 2001 23:37:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA05130 for ; Fri, 7 Sep 2001 19:37:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 7 Sep 2001 23:37:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA04879 for f-cpu-list; Fri, 7 Sep 2001 19:37:10 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA04876 for ; Fri, 7 Sep 2001 19:37:09 -0400 Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f87Nb9w13980 for ; Fri, 7 Sep 2001 19:37:10 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id BAA14311 for f-cpu@seul.org; Sat, 8 Sep 2001 01:37:07 +0200 (MET DST) Date: Sat, 8 Sep 2001 01:37:07 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id TAA04877 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry to speak about non-space stuff, but here it goes : We/you use VHDL. right ? we use ASCII, ELF, DIMM modules and lot of other standard parts, either EU standards (wall plugs, food denomination, etc), Internal or US standards. we can name a lot of IEEE standards, no ? So what is the problem with a standard for a CPU ? What money do you want from 'making a standard' except the satisfaction that your computer (and all SW thereogf !) is compatible with your neighbour's ? Btw, even IEEE 'gives away' implementation examples, as you can find Implementation Notes from mostly all component builders. If you are electronician you certainly even receive 'samples'. So what we do is not 'waste'. We don't search 'monopoly' (which would justify a return >from the 'market'). F-CPU is to become a 'standard', a 'commodity', not a milk cow. At least this is my opinion. Comments welcome :-) YG De: Juergen Goeritz >On Fri, 7 Sep 2001, nicO wrote: > >> Juergen Goeritz a écrit : >> > >> > On Wed, 5 Sep 2001, nicO wrote: >> > > >> > > Personnaly i could see it when you want to create a product but a piece >> > > of it is to big for you or you didn't want to spend to much money for >> > > it. Your 'added value' aren't this part but the whole system. So you >> > > decide to use the GPL to be help to design this none-so-important part >> > > (from money back point of view). But then you use it to develop and sell >> > > your product. As IBM : devellop Linux to sell even more computers. >> > >> > To my experience it is the other way round. Most new software >> > was derived from a preexisting work. IBM did take Linux because >> > it was already what it was - a very stable system. It is no >> > use, even for a big company, to develop the same thing anew, >> > maybe except you already have a very big customer base. IBM >> > lost their (PC) customer base already two times. I assume they >> > also will manage that a third time... >> > >> >> So you could see the developpement of the LEON. Europeen Space compagny >> can't develop a cpu them self, so ESA payed for one. > >No, ESA had a processor on SPARC V7 architecture licensed before >which started to be too slow and inflexible for new developments. >The idea now is to be able to build 'system on chip' designs for >space. That's why they started to develop a compilable source >code processor, the LEON. To be compatible to the old ERC32 they >decided to stay with SPARC V8 architecture. > >There have been other designs, like Thor, that have not been >used because of less performance as far as I know. > >JG > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Sat Sep 8 10:07:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ff2W-0005IJ-00 for ; Sat, 08 Sep 2001 12:08:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 12:08:40 +0200 (CEST) Received: (qmail 23157 invoked by uid 0); 8 Sep 2001 08:09:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 8 Sep 2001 08:09:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id EAA20714 for ; Sat, 8 Sep 2001 04:09:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 8 Sep 2001 08:07:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id EAA20450 for f-cpu-list; Sat, 8 Sep 2001 04:07:42 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id EAA20447 for ; Sat, 8 Sep 2001 04:07:39 -0400 Received: from mailout01.sul.t-online.de (mailout01.sul.t-online.com [194.25.134.80]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8887ew22904 for ; Sat, 8 Sep 2001 04:07:40 -0400 Received: from fwd01.sul.t-online.de by mailout01.sul.t-online.de with smtp id 15fd9O-0001Oy-01; Sat, 08 Sep 2001 10:07:38 +0200 Received: from (0893089296-0001@[62.226.162.103]) by fwd01.sul.t-online.com with smtp id 15fd9G-0hL7vEC; Sat, 8 Sep 2001 10:07:30 +0200 From: Thilo.Reichelt@t-online.de (Reichelt) To: f-cpu@seul.org Subject: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC X-Mailer: T-Online eMail 2.34 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Sat, 8 Sep 2001 10:07:30 +0200 Message-ID: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello. At first I want to apologize for my comments, since I am lurker on this list, with exception of some very few side remarks. But in my opinion the project of Juergen Goeritz could be important to the f-cpu project. I am afraid that a chance for funding might be given away without looking for a good solution which could make evrybody happy. The situation as I see it, is as follows: Juergen Goeritz seems to be prepared to base a major development effort on the f-cpu, which is not even completely defined yet (see discussion on "Dark and dusty corners"). He is prepared to throw major resources at the f-cpu project. He wants to protect his own development effort. The key persons are not willing to switch to LGPL just for Juergen Goeritz. Is it possible to draw a clear line where the f-cpu ends, and where the other parts of Juergen Goeritz' SoC starts ? If that is possible, the f-cpu project could offer a special license to Juergen Goeritz. He would be allowed to use the f-cpu for his project, in exchange for contributions to the project to be negotiated. Changes to the f-cpu itself arising from his project would be put into the f-cpu, but the work on the rest of his SoC would remain his own. All people contributing code would have to agree on this special license. The situation would be similar to the mySQL license: If your code is GPL, it use it for free; if you want it inside propriatory code, get a license. The GPL does not preclude the author to give somebody an additional license. Now the most important question: Is a compromise along these lines ok, both for Juergen Goeritz and the key people (whygee, Michael Riepe, nico, ...) ? I hope this will trigger a discussion about a compromise Thilo Reichelt ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Sep 8 14:04:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15flgY-0004r2-00 for ; Sat, 08 Sep 2001 19:14:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 19:14:26 +0200 (CEST) Received: (qmail 25430 invoked by uid 0); 8 Sep 2001 12:00:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Sep 2001 12:00:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id IAA25246 for ; Sat, 8 Sep 2001 08:00:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 8 Sep 2001 11:58:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id HAA24967 for f-cpu-list; Sat, 8 Sep 2001 07:58:41 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id HAA24964 for ; Sat, 8 Sep 2001 07:58:40 -0400 Received: from imf09bis.bellsouth.net (mail209.mail.bellsouth.net [205.152.58.149]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f88Bwfw24743 for ; Sat, 8 Sep 2001 07:58:41 -0400 Received: from computer ([209.215.11.31]) by imf09bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010908115934.SNDO15169.imf09bis.bellsouth.net@computer>; Sat, 8 Sep 2001 07:59:34 -0400 Message-ID: <002c01c1385e$6b3b1540$1f0bd7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] NODE? Date: Sat, 8 Sep 2001 07:04:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C13834.818AD9E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C13834.818AD9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To JG You stated 1000 Nodes. What is your description of a NODE??? Regards Dick Hartney ------=_NextPart_000_0029_01C13834.818AD9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To JG
 
You stated 1000 Nodes.  What is = your=20 description of a NODE???
 
Regards
Dick Hartney
------=_NextPart_000_0029_01C13834.818AD9E0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 8 16:11:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15flgZ-0004r2-00 for ; Sat, 08 Sep 2001 19:14:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Sep 2001 19:14:27 +0200 (CEST) Received: (qmail 9724 invoked by uid 0); 8 Sep 2001 14:16:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 8 Sep 2001 14:16:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id KAA31490 for ; Sat, 8 Sep 2001 10:16:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 8 Sep 2001 14:14:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id KAA31204 for f-cpu-list; Sat, 8 Sep 2001 10:14:41 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id KAA31201 for ; Sat, 8 Sep 2001 10:14:38 -0400 Received: from tribble.stud.uni-hannover.de (root@a092.home.uni-hannover.de [130.75.232.92]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f88EEaw25881 for ; Sat, 8 Sep 2001 10:14:37 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00770; Sat, 8 Sep 2001 16:11:42 +0200 Message-ID: <20010908161142.05347@thrai.stud.uni-hannover.de> Date: Sat, 8 Sep 2001 16:11:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <15fd9G-0hL7vEC@fwd01.sul.t-online.com>; from Reichelt on Sat, Sep 08, 2001 at 10:07:30AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 08, 2001 at 10:07:30AM +0200, Thilo Reichelt wrote: > Hello. > > At first I want to apologize for my comments, since I am lurker on this list, > with exception of some very few side remarks. But in my opinion the project of > Juergen Goeritz could be important to the f-cpu project. I am afraid that a > chance for funding might be given away without looking for a good solution which > could make evrybody happy. > > The situation as I see it, is as follows: > Juergen Goeritz seems to be prepared to base a major development effort on the > f-cpu, which is not even completely defined yet (see discussion on "Dark and > dusty corners"). He is prepared to throw major resources at the f-cpu project. > He wants to protect his own development effort. > The key persons are not willing to switch to LGPL just for Juergen Goeritz. All Juergen said was that he will *try* to get some funding -- for *his* project, I suppose. Original text (quoted from Yann's mail): Do I have the agreement with the f-cpu team to use the f-cpu in my design and try to go for funding from germany and/or EU? If yes, do you have a short summary of f-cpu that can be used and included into the overall project summary? Basically I have to decide now whether to include the f-cpu into the application request for funding or not. Your okay is necessary to include it. and later: Long story... To make it short some headlines only - new architecture for cluster computing - want to go for EU or german funding for this project - performant user processor still to be decided on (may be either a LEON extended to 64bit or F-CPU or other 64bit architecture that can be used for embedded) - system on chip design already specified - team to be built for realization - drawback: new architecture is not built as open source... Note that he said nothing about his contributions to the F-CPU project, except for some obscure remarks about members of the mCluster design team being allowed to also work on the F-CPU, and founding an AG (with F-CPU team members as shareholders?). I'm still waiting for a clear, precise statement what Juergen wants, and what he offers in return. I have a vague idea about the former, but that's all. On the other hand, it may be already too late. I'm not willing to make any deals with people I don't trust -- and I can't trust people who are unable (or unwilling) to come to the point and say what they mean. I believe that Juergen's commercial interests will collide with the goals of the F-CPU project sooner or later, and that cooperating with his mCluster project/company may (and will, due to Murphy's Law) take away our freedom to design and develop the F-CPU the way we want. It may also result in a separate, incompatible branch of F-CPU development, which is even worse -- in particular if that branch is not open-sourced. In order to prevent that, I will say no to any license changes that drop the special restrictions of the GPL wrt. distribution of derived works. Basta. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Sep 8 21:49:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15g8p6-0006ZL-01 for ; Sun, 09 Sep 2001 19:56:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Sep 2001 19:56:48 +0200 (CEST) Received: (qmail 23603 invoked by uid 0); 8 Sep 2001 19:50:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 8 Sep 2001 19:50:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id PAA07908 for ; Sat, 8 Sep 2001 15:50:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 8 Sep 2001 19:49:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id PAA07647 for f-cpu-list; Sat, 8 Sep 2001 15:49:40 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id PAA07644 for ; Sat, 8 Sep 2001 15:49:38 -0400 Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f88Jndw29175 for ; Sat, 8 Sep 2001 15:49:39 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA24516 for f-cpu@seul.org; Sat, 8 Sep 2001 21:49:35 +0200 (MET DST) Date: Sat, 8 Sep 2001 21:49:35 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Upload X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id PAA07645 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe : >Hi! > >I have uploaded a `double-zero' version of my assembler. It won't compile >on most systems (maybe on Solaris, but you'll need my not-yet-released >new version of libelf on other OSes), but it might be interesting anyway. >Have a look at http://f-cpu.seul.org/new/mr-as-0.0.tar.gz i've just d/l it and i will have a look. Btw, i will have to modify your ASU (at least) because things have evolved quite a bit in the last months... i have even put the fcpu_config stuff in a new vhdl directory (called "configuration" for obvious reasons). I'm also trying to automate the compilation for simili/wine and Vanilla. i am thus learnig bash script syntax... > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" geez, i was at Camden/London today and let me tell you that diese Englaender spinnen, wirklich ! :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 9 01:15:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15g8pO-0006ZL-00 for ; Sun, 09 Sep 2001 19:57:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Sep 2001 19:57:06 +0200 (CEST) Received: (qmail 25306 invoked by uid 0); 8 Sep 2001 23:17:03 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 8 Sep 2001 23:17:03 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA17808 for ; Sat, 8 Sep 2001 19:17:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 8 Sep 2001 23:15:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA17550 for f-cpu-list; Sat, 8 Sep 2001 19:15:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA17545 for ; Sat, 8 Sep 2001 19:15:52 -0400 Received: from tribble.stud.uni-hannover.de (michael@a172.home.uni-hannover.de [130.75.232.172]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f88NFGw00391 for ; Sat, 8 Sep 2001 19:15:16 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03203; Sun, 9 Sep 2001 01:15:22 +0200 Message-ID: <20010909011521.27327@thrai.stud.uni-hannover.de> Date: Sun, 9 Sep 2001 01:15:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Upload References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=wac7ysb48OaltWcw X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Sat, Sep 08, 2001 at 09:49:35PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii On Sat, Sep 08, 2001 at 09:49:35PM +0200, whygee@club-internet.fr wrote: [...] > Btw, i will have to modify your ASU (at least) > because things have evolved quite a bit in the last months... What exactly? Please send patches if possible. > i have even put the fcpu_config stuff in a new vhdl directory > (called "configuration" for obvious reasons). Yep, I saw your new snapshot :) > I'm also trying to automate the compilation for simili/wine and > Vanilla. i am thus learnig bash script syntax... I have scripts for vanilla (I also have make rules but they suck). Ditto for modelsim (and .BAT files for simili). I'll attach a copy. > geez, i was at Camden/London today and let me tell you that > diese Englaender spinnen, wirklich ! :-) *hehehehe* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --wac7ysb48OaltWcw Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="compile-scripts.tar.gz" H4sIAECmmjsCA+1ca2/bOBbNZwH5DxdpPrRB5If8mkl2FuPJJtNgmzZwkikKDGDQEmUT0Wsp yaln0P++l6Jku36ncZzd9l4grURdXlN8nHMkUrRDPxIeL/uhw71Y+GVbJ+xt0aqVSqvRgD0A qNbr2f9g5f+rw4pVBWjV6hX8qzZayqtZbe1BZW8HlsYJkwB7vrAHjHtL/dDNdfe+O3sFeYOX 4gGYZnEGzPOAfxZxIoI+YOdIPR4fQxqr06u8rxiv4CyMRlL0Bwm8PnuDLVmpHKt/q3ClqxM6 gkcc/pHX7q9xkjqlNBDmgAVBOOSy5PB/Gq8w0u1AxBDJsC+ZD3joSs4hDt3kgUl+CqMwBZsF ILmDhZKilyYcRAIscMqhVCUU7gjDYFIaOFxCMuCQcOnHELrZye/v7+B3HnDJPLhOe56w4Z2w eRDjzeIvq5R4wB3oqTAqw4UqwU1eArgIMS5LRBicAhd4XQIWP8ZzsIqfyOMdQygxxmuWqGJL CCOV7Q2WdQQeSyY5SwvvfHKDDoggCzwIsRKTAQbE+3sQ2DY9jo3B3dQ7xgjoCx8vb99+uLuF 9vtP8LHd6bTf3346Rd9kEOJVPuQ6kvAjT2BgvCfJgmSERccAV+eds7eYo/3b5bvL209Yfri4 vH1/fnMDFx860Ibrduf28uzuXbsD13ed6w835yWAG64KxTH/irp1s9bBCnR4woQX63v+hM0Z Y8k8BwZsyLFZbS6GWC6GPTAarW8zjMG8EDujukP0nVThKQgXgjA5hgcpsJMk4XxrYu5Jex7D ZWCXjqHxM9xyrB4O1x6zsRVvUpW/VsM+/VsYJ8rzqg2AcFWtmtVaBZHq7qZtYLDDS+ekGDrH Q6iWatkoKFd+KlsWVGsn9Z9Pag3IRwGcf47g0DBiaTtC/nL4tz44MUulL0ZsSxEleXpxfGIe ap8Cnsd4/cXgn6NQJqCvwziLYRyOjzFX4Ir+dApPuyxOZ1KEnxp7ZD+S2fP8r7rK3g75v9pq Nmf5v96oEf/viv9Vg8/Qv05MZQaQ4CpYI/In8ifyX07+asD8z3D/EH2hyOeadpR283E+HDie sQL/tTDYJf5b1Yo1j/8Vwv/d4L9u8Bn8bztO+Sbtwfkd4T7hPuH+UtzXoyfD/fo34/5XMK5C Mxx+MQ4/HDTJ11iuf68s0ENDOXZbHic9HtgDHi/xVR4N7b7coVnEe5AsirC/qka8MM+u7xZm UpgxwyVk38Hzn34NsFP+r1Xr8/xP7393x//Y4DP8fxkkvI8YcJV6iYi8EQkBEgIkBNYIARxG 2xYCcRqpFDXuImbfs/4CjsefLfdVNQm7i7IAR9VCplduvojtguZ9PbQFlwtd8c9r1jfRGNq7 WVc+y3+68LDWu9Q2VyJ5SUmJPJX/EdCFJ4pXDKUeS3b4/rc15v9Gtar4v1Fp1In/d2G/cnsQ IuC6+4bkPky1/6azwTdZz9HZtyIIslA63jZkgY60DWWgIz1ZHOgwG+iDFRXxSJWggzxNKOgY T9IKOsRj5MJUFTxZNOgwT9ANOsDWpMO+oQNOTx6rgZdpiMaMhmi05jSEyp8P32DfsNUYzd/x YpA8IX+591WC4sssYSH+FwF2Of9Xa87gf73ZpOe/l8H/ov03mw0k8CfwJ/B/OvgXoy7Dfuux 2K+efiKYm+bbNx6t/yd8scv5v1p9Dv9bpP9fAv8n7b96NpBwn3CfcP+puD8Zbd+m+bNbm5oq LJhAx/1zPEmY9+HJO7w5x8kM4cJLzakwcy/lZnIUE4P79D7u/+/93+TxcJfzf1Zrlv9bFYv4 /2X4P2//DWcDSQiQECAhsAUhkA+7bxcCC6YKp5gZw/85P0k44zCeHtQRJzOEM35Tc4OrpIV2 nZoYXHLNWnWxtqH0yMtF0uMb+X8UhFE8itW6LjNWAMBLjh0PtsT/zUpl+fvfupU9/1vVeqNV bzUwpWk16fuPnVj5iIFu7oLtj8qGEQ/gQPpgShc+fuj8+xT8e7XAXB0fZBcRAvmB4XBXBLzr 8Fj0g64nepkHmBFDfFWHhoGjUQRdEbhcdjM86SE//YII7zI86zLPMwwWMG/0FwfThT/e/usd mBhJMjnS0aBUWrCCfXUezJIvU1ywMGLTrJM1lpvmGK+JNGKedG0vtO+7faYguRsnI48b3GO9 UGLd5Q9LYOJlrj0NA+ETM+jaNMpHqIz+k6KEUQ1SPrIlH7uCGTCfw8GZd3+AtY03GDpIGxUw H5AbER19+BsH1kHlAP9KjQP4os8z/y8Yr3z0Med8HU+RXST5UIRpDNhgXKmMNND6wcMM6n58 9hkL57ER1oMMFZd62LBRmsSv34CJlKkSMGaeosozc08Y+V7Xje5y3bzLddXqQ0hkilWM8qcX xtwotKfps6jLXVeti/HCBzB7GQPLUVdJJ1/8lZGxgfyg2G/cx4pz5RL0i7MofOCyOEFOZ4bh c3+qR2OFJ8aPiP9DFqBoZM/x+f8G3//Pr/+s0fzfjtZ/Pv77/z90X8mwkFaB0ipQWgX6MnsA 5JhNWwCQbZH/t/75/wbrP2uz/G81m8T/u+L/R33/T+RP5E/kv24PAOvlub+EPj+11m0CMIv/ z/D5//r1P9W5/V+sFs3/7Qj/N/z+n3CfcJ9wf90eANYz7QEwA+ZrdgFY5j21D8AqlxU7ASzO RnsBfDfPf8/w+f/69T+1Of6vVWj/n93x/6O+/ychQEKAhMC6PQCs590DYJ6Hl+wCsNhxyT4A i52X7wSwzH96L4DVPtYmTrXH6BHaEYCMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIzsB7b/AvZ2 h9MAeAAA --wac7ysb48OaltWcw-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Sun Sep 9 02:05:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15g8pR-0006ZL-00 for ; Sun, 09 Sep 2001 19:57:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Sep 2001 19:57:09 +0200 (CEST) Received: (qmail 18728 invoked by uid 0); 9 Sep 2001 00:03:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 9 Sep 2001 00:03:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id UAA19072 for ; Sat, 8 Sep 2001 20:03:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 9 Sep 2001 00:02:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id UAA18801 for f-cpu-list; Sat, 8 Sep 2001 20:02:26 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id UAA18795 for ; Sat, 8 Sep 2001 20:02:20 -0400 Received: from online.ln.cn ([202.96.74.86]) by moria.mit.edu (8.11.2/8.11.0) with SMTP id f8902Iw01231 for ; Sat, 8 Sep 2001 20:02:20 -0400 Message-Id: <200109090002.f8902Iw01231@moria.mit.edu> Received: from there([61.176.53.100]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm03b9ae60f; Sun, 09 Sep 2001 07:57:30 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Project short description Date: Sun, 9 Sep 2001 08:05:24 +0800 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id UAA18796 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 4 Sep 2001 15:50, you wrote: > > Looked into MACH when taking XINU for i960 in a former project > but it wasn't really complete at that time. Who can point me > to the latest work? > > JG These came up first items on their respective Google Searches: Official Mach project site: http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html You might want to check out OSKit instead. It is much more up-to-date tann Mach. Official OSKit project site: http://www.cs.utah.edu/flux/oskit/ (Server was timing out this morning) -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.gnu.org / http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- Fight software piracy. Use GNU! [ http://www.gnu.org ] -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sun Sep 9 20:52:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfJ-00020Y-00 for ; Mon, 10 Sep 2001 20:20:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:13 +0200 (CEST) Received: (qmail 29458 invoked by uid 0); 9 Sep 2001 18:53:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Sep 2001 18:53:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id OAA15314 for ; Sun, 9 Sep 2001 14:53:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 9 Sep 2001 18:52:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id OAA15034 for f-cpu-list; Sun, 9 Sep 2001 14:52:57 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id OAA15031 for ; Sun, 9 Sep 2001 14:52:55 -0400 Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f89Iquw21432 for ; Sun, 9 Sep 2001 14:52:57 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA15591 for f-cpu@seul.org; Sun, 9 Sep 2001 20:52:51 +0200 (MET DST) Date: Sun, 9 Sep 2001 20:52:51 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Upload X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id OAA15032 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe : >On Sat, Sep 08, 2001 at 09:49:35PM +0200, whygee@club-internet.fr wrote: >[...] >> Btw, i will have to modify your ASU (at least) >> because things have evolved quite a bit in the last months... >What exactly? Please send patches if possible. there are only a few changes necessary. max_chunck_size for example. Btw i would like to 'split' the ASU into two parts, so that the clocking can be done at a higher level. Or if it is possible to define (once again) a 'generic' pipeline latch ... so as few changes as possible are necessary if the latches have to change. >> i have even put the fcpu_config stuff in a new vhdl directory >> (called "configuration" for obvious reasons). >Yep, I saw your new snapshot :) cool :-) btw concerning your asm, it complains about some missing ELF libraries :-( >> I'm also trying to automate the compilation for simili/wine and >> Vanilla. i am thus learnig bash script syntax... > >I have scripts for vanilla (I also have make rules but they suck). >Ditto for modelsim (and .BAT files for simili). I'll attach a copy. ok i'll try to make good use of them :-) >> geez, i was at Camden/London today and let me tell you that >> diese Englaender spinnen, wirklich ! :-) >*hehehehe* > > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" come to Camden and you'lle have much more than needed ;-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Sep 10 05:00:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfM-00020Y-00 for ; Mon, 10 Sep 2001 20:20:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:16 +0200 (CEST) Received: (qmail 10131 invoked by uid 0); 9 Sep 2001 20:52:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx18) with SMTP; 9 Sep 2001 20:52:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id QAA17593 for ; Sun, 9 Sep 2001 16:52:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 9 Sep 2001 20:51:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id QAA17339 for f-cpu-list; Sun, 9 Sep 2001 16:51:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id QAA17336 for ; Sun, 9 Sep 2001 16:51:30 -0400 Received: from localhost.localdomain (nas5-211.vlt.club-internet.fr [194.158.107.211]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f89KpUw22783 for ; Sun, 9 Sep 2001 16:51:30 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 53F201707 for ; Sun, 9 Sep 2001 23:00:19 -0400 (EDT) Message-ID: <3B9C2CC3.8A6C190B@ifrance.com> Date: Sun, 09 Sep 2001 23:00:19 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Reichelt a écrit : > > Hello. > > At first I want to apologize for my comments, since I am lurker on this list, > with exception of some very few side remarks. But in my opinion the project of > Juergen Goeritz could be important to the f-cpu project. I am afraid that a > chance for funding might be given away without looking for a good solution which > could make evrybody happy. > > The situation as I see it, is as follows: > Juergen Goeritz seems to be prepared to base a major development effort on the > f-cpu, which is not even completely defined yet (see discussion on "Dark and > dusty corners"). He is prepared to throw major resources at the f-cpu project. > He wants to protect his own development effort. > The key persons are not willing to switch to LGPL just for Juergen Goeritz. > > Is it possible to draw a clear line where the f-cpu ends, and where the other > parts of Juergen Goeritz' SoC starts ? If that is possible, the f-cpu project > could offer a special license to Juergen Goeritz. He would be allowed to use the > f-cpu for his project, in exchange for contributions to the project to be > negotiated. Changes to the f-cpu itself arising from his project would be put > into the f-cpu, but the work on the rest of his SoC would remain his own. All > people contributing code would have to agree on this special license. > > The situation would be similar to the mySQL license: If your code is GPL, it use > it for free; if you want it inside propriatory code, get a license. The GPL does > not preclude the author to give somebody an additional license. > There is a problem to protect the design. So we use GPL but i want to speak to a lawyer to know what to do. There is a problem concerning the binaries/hardware issue of the licence. But the licence speak a lot about source code and VHDL or C, it's always source code. I don't know exactly where is the limit that Micheal want to put. but i know that he prefer design rather than thinking about licence issue. >From my point of view, i think that prorietary SoC should be possibly made with F-CPU code. Maybe we could use the IP sense of view from opencores.org. They have defined a "simple" Bus for SoC (Wishbones), so we could defined a fcpu component (IP?). So every thing inside this bloc is under GPL (or GPL like) the other part is what you want. nicO > Now the most important question: > Is a compromise along these lines ok, both for Juergen Goeritz and the key > people (whygee, Michael Riepe, nico, ...) ? > > I hope this will trigger a discussion about a compromise > > Thilo Reichelt > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 10 01:37:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfN-00020Y-01 for ; Mon, 10 Sep 2001 20:20:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:17 +0200 (CEST) Received: (qmail 30526 invoked by uid 0); 9 Sep 2001 23:38:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 9 Sep 2001 23:38:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id TAA21145 for ; Sun, 9 Sep 2001 19:38:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 9 Sep 2001 23:37:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id TAA20846 for f-cpu-list; Sun, 9 Sep 2001 19:37:30 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id TAA20843 for ; Sun, 9 Sep 2001 19:37:29 -0400 Received: from tribble.stud.uni-hannover.de (michael@a229.home.uni-hannover.de [130.75.232.229]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f89NbTw26129 for ; Sun, 9 Sep 2001 19:37:29 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA04758; Mon, 10 Sep 2001 01:37:19 +0200 Message-ID: <20010910013719.55402@thrai.stud.uni-hannover.de> Date: Mon, 10 Sep 2001 01:37:19 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Upload References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Sun, Sep 09, 2001 at 08:52:51PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 09, 2001 at 08:52:51PM +0200, whygee@club-internet.fr wrote: [...] > >> Btw, i will have to modify your ASU (at least) > >> because things have evolved quite a bit in the last months... > >What exactly? Please send patches if possible. > there are only a few changes necessary. > max_chunck_size for example. MAX_CHUNK_SIZE must currently be 64 -- the adder doesn't handle 32-bit (and probably never will -- it may be easier to write a separate 32-bit version, and let the EU_IMU wrapper entity include the appropriate one). > Btw i would like to 'split' the ASU into two parts, > so that the clocking can be done at a higher level. The stages are already separate processes (that is, they're easy to separate), and the pipeline register is concentrated at the end of the first stage. > Or if it is possible to define (once again) a 'generic' > pipeline latch ... so as few changes as possible are necessary > if the latches have to change. That would mean that we have to use a register component again (I'd prefer a concurrent procedure, because it would make the code more readable, but some synthesis tools don't grok edge expressions in a procedure. *argh*). [...] > btw concerning your asm, it complains about some missing ELF > libraries :-( Didn't I mention that it won't compile? ;) Before you try again, install the latest libelf pre-release from my homepage; the URL is http://www.stud.uni-hannover.de/~michael/software/libelf-0.7.1-pre6.tar.gz But please do not publish this ANYWHERE! -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From magsilva@din.uem.br Sat Sep 8 23:37:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfT-00020Y-00 for ; Mon, 10 Sep 2001 20:20:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:23 +0200 (CEST) Received: (qmail 28930 invoked by uid 0); 10 Sep 2001 06:37:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 10 Sep 2001 06:37:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id CAA31083 for ; Mon, 10 Sep 2001 02:37:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 06:37:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id CAA30827 for f-cpu-list; Mon, 10 Sep 2001 02:37:15 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id CAA30824 for ; Mon, 10 Sep 2001 02:37:13 -0400 Received: from 127.0.0.1 (ACBB710A.ipt.aol.com [172.187.113.10]) by moria.mit.edu (8.11.2/8.11.0) with SMTP id f8A6b5w31434 for ; Mon, 10 Sep 2001 02:37:14 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Marco =?iso-8859-1?q?Aur=E9lio=20Graciotto=20Silva?= To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic Date: Sat, 8 Sep 2001 18:37:49 -0300 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01090818374900.01517@discovery.localdomain> Content-Transfer-Encoding: 8bit X-GCMulti: 1 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Seg 27 Ago 2001 12:56, Juergen Goeritz wrote: > On Mon, 27 Aug 2001, Ben Franchuk wrote: > > Juergen Goeritz wrote: > > > Not at all! Conquering new frontiers fits much better. :-) > > > > > > > but please don't leave before the first F-CPU prototype is built > > > > ;-) > > > > > > Yes, it's one of the required base technologies though ;-) > > > > I say use my CPU designs instead.The F-cpu is too complex for > > what really could be future computer design in deep space - > > plastic transistors. In deep space you are living in a closed > > habit and almost all products have to be recycled and/or > > repaired. Conventional cpu design is too complex and poisonous > > and wasteful and not productive for small population bases. > > Earth 4 billion people - > > Mars - 20 000 . Plastic computers would be IBM PC size and speed > > for the critical systems. > > How do you built plastics without oil? And some > loss of performance with every recycling step? :-( Well, there are other ways to get plastics. Here in Brazil, a year ago I think, it was developed a technique to produce plastic from sugar cane (actually biodegradable plastic). Unfortunately it cannot be used to build transistors (at least they hadn't tryied that). But hey, halfway gone! :) []'s -- Marco Aurélio Graciotto Silva Computer Science - State University of Maringá Maringá - Paraná - Brasil ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 10 16:54:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfd-00020Y-00 for ; Mon, 10 Sep 2001 20:20:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:33 +0200 (CEST) Received: (qmail 30126 invoked by uid 0); 10 Sep 2001 17:05:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 10 Sep 2001 17:05:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA02766 for ; Mon, 10 Sep 2001 13:05:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:04:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA02319 for f-cpu-list; Mon, 10 Sep 2001 13:04:26 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA02316 for ; Mon, 10 Sep 2001 13:04:25 -0400 Received: from redwood.oekomm.de ([195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8AEoYw05283 for ; Mon, 10 Sep 2001 10:51:54 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15gSST-0002ZK-00 for f-cpu@seul.org; Mon, 10 Sep 2001 16:54:45 +0200 Date: Mon, 10 Sep 2001 16:54:45 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen's SoC In-Reply-To: <20010908161142.05347@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 8 Sep 2001, Michael Riepe wrote: > > Note that he said nothing about his contributions to the F-CPU project, I am interested in the development of a pipeline floating point instruction set. Development for F-CPU is only interesting for me if I can use the F-CPU with my mCluster design. > except for some obscure remarks about members of the mCluster design > team being allowed to also work on the F-CPU, and founding an AG (with > F-CPU team members as shareholders?). I was thinking of setting up a company to handle industrial interest in the F-CPU - to work as coordination and contact. This company could handle e.g. coordination of development, licensing of established versions for industrial use, collect donations, promote F-CPU, produce chips for public use, etc. The shares of this company would belong to F-CPU participants who want entitlement into this company because of their work done for F-CPU. Donations and license fees (if any) could be either spread among the shareholders or used for further proceedings of the development. Ideally it could lead to regular income for the shareholders if enough industrial licensing takes place (at least that's my wish) but I would not want to go for money raising on the stock market. I imagined something like a non/small profit company. > I'm still waiting for a clear, precise statement what Juergen wants, > and what he offers in return. I have a vague idea about the former, > but that's all. Michael, I am not somebody having only a lot of money and knowing nothing about the contence/development. I have built a small start-up company with a good product idea (that's what I think) and could participate into this 'AG idea' personally but can't finance it completely by myself. I don't want to take control over the F-CPU development. I simply had that idea of using it in my design (and get it working for space use). That's all. Of course I could also use some partners. > On the other hand, it may be already too late. I'm not willing to make > any deals with people I don't trust -- and I can't trust people who are > unable (or unwilling) to come to the point and say what they mean. I didn't meet you yet, can't say anything about trust. But maybe you know me already and use some email alias? > I believe that Juergen's commercial interests will collide with the > goals of the F-CPU project sooner or later, and that cooperating with his > mCluster project/company may (and will, due to Murphy's Law) take away > our freedom to design and develop the F-CPU the way we want. It may > also result in a separate, incompatible branch of F-CPU development, > which is even worse -- in particular if that branch is not open-sourced. > In order to prevent that, I will say no to any license changes that drop > the special restrictions of the GPL wrt. distribution of derived works. The story behind why I was complaining about GPL use in the F-CPU project is that I believe that it is not really covering your work. GPL was designed as software license. It should be adapted to cover hardware development first. See some explanations in other mails. On the other hand, I have enough experience to go for own cpu design. But why not try to ask if F-CPU could be used instead? > Basta. Sorry for asking in the first place. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Sep 10 05:14:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfe-00020Y-00 for ; Mon, 10 Sep 2001 20:20:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:34 +0200 (CEST) Received: (qmail 21786 invoked by uid 0); 10 Sep 2001 17:07:06 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 10 Sep 2001 17:07:06 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA04730 for ; Mon, 10 Sep 2001 13:07:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:05:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA02689 for f-cpu-list; Mon, 10 Sep 2001 13:05:07 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA02670 for ; Mon, 10 Sep 2001 13:05:04 -0400 Received: from main.jetnet.ab.ca (root@[207.153.11.66]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8AEJEw04573 for ; Mon, 10 Sep 2001 10:20:44 -0400 Received: from jetnet.ab.ca (dialin42.jetnet.ab.ca [207.153.6.42]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA00435 for ; Mon, 10 Sep 2001 08:18:49 -0600 (MDT) Message-ID: <3B9C3003.875565F2@jetnet.ab.ca> Date: Sun, 09 Sep 2001 21:14:11 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] way off topic References: <01090818374900.01517@discovery.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Marco Aurélio Graciotto Silva wrote: > > Well, there are other ways to get plastics. Here in Brazil, a year ago I > think, it was developed a technique to produce plastic from sugar cane > (actually biodegradable plastic). Unfortunately it cannot be used to build > transistors (at least they hadn't tryied that). But hey, halfway gone! :) I was thinking of self contained environments in space. Producing normal transistors could be done there, but environmental factors are much more demanding as conventional processing produces more wastes and poisonous chemicals than things based on organic materials. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 10 12:08:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfe-00020Y-01 for ; Mon, 10 Sep 2001 20:20:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:34 +0200 (CEST) Received: (qmail 3207 invoked by uid 0); 10 Sep 2001 17:07:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 10 Sep 2001 17:07:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA04863 for ; Mon, 10 Sep 2001 13:07:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:05:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA02786 for f-cpu-list; Mon, 10 Sep 2001 13:05:17 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA02715 for ; Mon, 10 Sep 2001 13:05:09 -0400 Received: from redwood.oekomm.de ([195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8AAY0w01314 for ; Mon, 10 Sep 2001 06:35:20 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15gNza-00026D-00 for f-cpu@seul.org; Mon, 10 Sep 2001 12:08:38 +0200 Date: Mon, 10 Sep 2001 12:08:38 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC In-Reply-To: <3B9C2CC3.8A6C190B@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id NAA02718 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 9 Sep 2001, nicO wrote: > Reichelt a écrit : > > > > Hello. > > > > At first I want to apologize for my comments, since I am lurker on this list, > > with exception of some very few side remarks. But in my opinion the project of > > Juergen Goeritz could be important to the f-cpu project. I am afraid that a > > chance for funding might be given away without looking for a good solution which > > could make evrybody happy. > > > > The situation as I see it, is as follows: > > Juergen Goeritz seems to be prepared to base a major development effort on the > > f-cpu, which is not even completely defined yet (see discussion on "Dark and > > dusty corners"). He is prepared to throw major resources at the f-cpu project. > > He wants to protect his own development effort. > > The key persons are not willing to switch to LGPL just for Juergen Goeritz. > > > > Is it possible to draw a clear line where the f-cpu ends, and where the other > > parts of Juergen Goeritz' SoC starts ? If that is possible, the f-cpu project > > could offer a special license to Juergen Goeritz. He would be allowed to use the > > f-cpu for his project, in exchange for contributions to the project to be > > negotiated. Changes to the f-cpu itself arising from his project would be put > > into the f-cpu, but the work on the rest of his SoC would remain his own. All > > people contributing code would have to agree on this special license. > > > > The situation would be similar to the mySQL license: If your code is GPL, it use > > it for free; if you want it inside propriatory code, get a license. The GPL does > > not preclude the author to give somebody an additional license. > > > > There is a problem to protect the design. So we use GPL but i want to > speak to a lawyer to know what to do. There is a problem concerning the > binaries/hardware issue of the licence. But the licence speak a lot > about source code and VHDL or C, it's always source code. > > I don't know exactly where is the limit that Micheal want to put. but i > know that he prefer design rather than thinking about licence issue. > >From my point of view, i think that prorietary SoC should be possibly > made with F-CPU code. Maybe we could use the IP sense of view from > opencores.org. They have defined a "simple" Bus for SoC (Wishbones), so > we could defined a fcpu component (IP?). So every thing inside this bloc > is under GPL (or GPL like) the other part is what you want. > > nicO > > > Now the most important question: > > Is a compromise along these lines ok, both for Juergen Goeritz and the key > > people (whygee, Michael Riepe, nico, ...) ? > > > > I hope this will trigger a discussion about a compromise Hi, why go for a new bus? It may be a good idea to e.g. define the f-cpu license from caches on (incl.). Everything inside >from caches on is protected. Which external memory interface, which IO and which bus to use would be free for implementor choice. In return anybody using the f-cpu in a chip could be asked to develop a part of the f-cpu or do a 'donation' to the development team or a 'fee' for public registration of the f-cpu ID or whatever. What's your opinion? JG P.S. In my opinion the GPL license has a big drawback when you add own components on the netlist level. My standpoint is that this is the weak point. A netlist is comparable to '.o' files or libraries (vendor macro instantiations like gates are connected to each other in the netlist). Good people can write and modify netlists directly. Netlists mostly are produced by proprietary tools, e.g. synthesis. When you follow this thought you end up with a system around the f-cpu that is completely outside the license coverage because libraries and operating systems (or the chip - in my thought) are not covered. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Malush@MailAndNews.com Mon Sep 10 14:37:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVff-00020Y-00 for ; Mon, 10 Sep 2001 20:20:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:35 +0200 (CEST) Received: (qmail 8038 invoked by uid 0); 10 Sep 2001 17:07:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 10 Sep 2001 17:07:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA04866 for ; Mon, 10 Sep 2001 13:07:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:05:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA02772 for f-cpu-list; Mon, 10 Sep 2001 13:05:17 -0400 Message-Id: <200109101705.NAA02772@belegost.mit.edu> Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA02676 for ; Mon, 10 Sep 2001 13:05:05 -0400 Received: from MailAndNews.com ([199.29.68.123]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8ACcAw02813 for ; Mon, 10 Sep 2001 08:39:30 -0400 X-WM-Posted-At: MailAndNews.com; Mon, 10 Sep 01 08:37:27 -0400 X-WebMail-UserID: Malush Date: Mon, 10 Sep 2001 08:37:27 -0400 From: Shahar Goldin To: f-cpu@seul.org X-EXP32-SerialNo: 50000000 Subject: [f-cpu] Message-ID: <3B9EF34B@MailAndNews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.61.08 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N OK now I don't know much about CPU's and stuff of that nature but the manual needs some immediate changes, IMO -- Highlight outdated sections somehow -In some places the manual contradicts itself entirly (we won't be able to fit these in Intel MoBo's , later recomended that we use Celeron MoBos) -- Include a list of books for reference This would help alot I hope I'm sending this to the right place (this may have been suggested before but I'm not going to read 3 years of Mailing list archives ;-) ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com This message courtesy of Lord of the Morning, Prince of the dawn, The Chief of Chiefs, His Lordship the Dragon, Reborn ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 10 10:32:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfg-00020Y-00 for ; Mon, 10 Sep 2001 20:20:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:36 +0200 (CEST) Received: (qmail 1762 invoked by uid 0); 10 Sep 2001 17:07:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 10 Sep 2001 17:07:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA04941 for ; Mon, 10 Sep 2001 13:07:15 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:05:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA02833 for f-cpu-list; Mon, 10 Sep 2001 13:05:22 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA02752 for ; Mon, 10 Sep 2001 13:05:13 -0400 Received: from redwood.oekomm.de ([195.247.49.177]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8A8vjw00670 for ; Mon, 10 Sep 2001 04:59:12 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15gMUi-0001xW-00 for f-cpu@seul.org; Mon, 10 Sep 2001 10:32:40 +0200 Date: Mon, 10 Sep 2001 10:32:40 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: <20010907154243.47384@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Sep 2001, Michael Riepe wrote: > On Fri, Sep 07, 2001 at 12:22:42PM +0200, Juergen Goeritz wrote: > [...] > > thanks for explaining your point of view about free software. > > De nada :) > > > But with your remarks it does not seem to be free any more, > > but some kind of shared software. Why should one develop this > > software on, if one can't make a living of this? Thanks a lot for some interesting explanations of your view of 'free' software and hardware. ... discussion deleted ... > > Therefore my opinion is to use a more open license for > > all hardware related things. Maybe LGPL is not the best > > but it is at least a start. > > Why don't *you* use a more open license? As far as I understood, you > don't intend to release your source code at all, do you? Why not? It will be included in the chip anyway. You won't be able to change the integral software at all. It's a system design. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Sep 11 00:32:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfh-00020Y-00 for ; Mon, 10 Sep 2001 20:20:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:37 +0200 (CEST) Received: (qmail 27968 invoked by uid 0); 10 Sep 2001 17:39:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 10 Sep 2001 17:39:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA09611 for ; Mon, 10 Sep 2001 13:39:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:39:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA09363 for f-cpu-list; Mon, 10 Sep 2001 13:39:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA09360 for ; Mon, 10 Sep 2001 13:39:08 -0400 Received: from localhost.localdomain (nas24-223.vlt.club-internet.fr [195.36.223.223]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8AHd9w08051 for ; Mon, 10 Sep 2001 13:39:09 -0400 Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C7E481704 for ; Mon, 10 Sep 2001 18:32:48 -0400 (EDT) Message-ID: <3B9D3F90.DC74A80A@ifrance.com> Date: Mon, 10 Sep 2001 18:32:48 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] New way of doing testbench References: <20010910013719.55402@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N http://www.testbuilder.net/resources.thtml Maybe a good way to write a testbench for vhdl. I don't if it could work with free HDL or Simili. It's a way to interface HDL and C++. It look very nice and it's free ! Maybe some guy could try to look at the licence ? ;p nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Sep 10 19:33:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gVfi-00020Y-00 for ; Mon, 10 Sep 2001 20:20:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 20:20:38 +0200 (CEST) Received: (qmail 30371 invoked by uid 0); 10 Sep 2001 17:41:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 10 Sep 2001 17:41:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.9.3/8.9.3) with SMTP id NAA09893 for ; Mon, 10 Sep 2001 13:41:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 17:41:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.9.3/8.9.3) id NAA09646 for f-cpu-list; Mon, 10 Sep 2001 13:41:15 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.9.3/8.9.3) with ESMTP id NAA09643 for ; Mon, 10 Sep 2001 13:41:14 -0400 Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.mit.edu (8.11.2/8.11.0) with ESMTP id f8AHfGw08138 for ; Mon, 10 Sep 2001 13:41:17 -0400 Received: from art1.none.de (dialin151.pg2-nt.berlin.nikoma.de [213.54.65.151]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f8AHfHK17968 for ; Mon, 10 Sep 2001 19:41:17 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin151.pg2-nt.berlin.nikoma.de [213.54.65.151] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.31 #1 (Debian)) id 15gUxP-000397-00 for ; Mon, 10 Sep 2001 19:34:51 +0200 Date: Mon, 10 Sep 2001 19:33:51 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: Project short description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > Thanks a lot for some interesting explanations of your view > of 'free' software and hardware. What is the problem to add your work under the GPL to the F-CPU? Because if you are the "Urheber" of your(!) code/design you can use GPL as a general license and for industrial ports/usage you can deliver a special license. I think, the F-CPU is a project with ideas and work of so many people, so nobody can you give another license than GPL for the whole project. That is a fact, and I believe that is the right way. Nobody of us is interested to found a shareholder company to develop this project. Somebody of us think, a company should develop or paid all libs which they use for a softwareproject or distribute all of their project under the GPL-License, because the company should decide between this two options. In my opinion everybody who takes 10.000 lines of code should return 10 lines. Any private members do not know how how to code, but everybody can help (suggestions, ideas, documentation, discussion, bugreports, translation, sponsoring and so on.) Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7nPmCClxplZklbgERAm9WAKCET+QzJhviWm0/tnNyKIDcM+wcVwCeLLSK 27ziya3ac3MzoMZjlH/ZsfU= =+7ZY -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Mon Sep 10 20:17:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gXQl-0003gj-00 for ; Mon, 10 Sep 2001 22:13:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Sep 2001 22:13:19 +0200 (CEST) Received: (qmail 5444 invoked by uid 0); 10 Sep 2001 18:17:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 10 Sep 2001 18:17:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.9.3) with SMTP id f8AIHtM11192 for ; Mon, 10 Sep 2001 14:17:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 18:17:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.9.3) id f8AIHSl10943 for f-cpu-list; Mon, 10 Sep 2001 14:17:28 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.9.3) with ESMTP id f8AIHRV10940 for ; Mon, 10 Sep 2001 14:17:27 -0400 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.mit.edu (8.11.6/8.11.0) with ESMTP id f8AIHQr08821 for ; Mon, 10 Sep 2001 14:17:28 -0400 Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id VAA09674 for ; Mon, 10 Sep 2001 21:17:21 +0300 (EET DST) Date: Mon, 10 Sep 2001 21:17:19 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] New way of doing testbench In-Reply-To: <3B9D3F90.DC74A80A@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 10 Sep 2001, nicO wrote: > http://www.testbuilder.net/resources.thtml > > Maybe a good way to write a testbench for vhdl. I don't if it could work > with free HDL or Simili. Usually the interfaces to simulators are the difficult part of new Verification languages and class libraries. The biggest commercial simulators are usually well supported. Altough all features are not supported in all simulators. For example Vera supports Temporal expressions only with VCS currently. With Verilog the interfaces are usually easier because PLI is well standardized. There is not yet standard FLI for VHDL. > It's a way to interface HDL and C++. It look very nice and it's free ! I wrote my masters thesis about Object Oriented ASIC vericiation, so methodology is quite familiar for me. I have written with Synopsys VERA one big testbench (30kloc). And now I have much more complex TB under construction. I would not go back to VHDL testbenches. OO methodology and higher level languages just make coding so much easier. Espaecially when the TB complexity is all the time rising. Synopsys VERA has one very nice feature for CPU testing but unfortunately the tool is commercial. VERA stream generator can generate quite easily random but sane instruction stream. The instruction set is just described with BNF and after that the generator can generate instructions. I have heard that stream generator was developed for Sun Sparc verification originally. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Mon Sep 10 20:40:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokO-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:44 +0200 (CEST) Received: (qmail 28877 invoked by uid 0); 10 Sep 2001 23:45:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 10 Sep 2001 23:45:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ANjLB22573 for ; Mon, 10 Sep 2001 19:45:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 23:43:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ANh8M21878 for f-cpu-list; Mon, 10 Sep 2001 19:43:08 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh5C21865 for ; Mon, 10 Sep 2001 19:43:05 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh7e15969 for ; Mon, 10 Sep 2001 19:43:07 -0400 Received: from tribble.stud.uni-hannover.de (root@a097.home.uni-hannover.de [130.75.232.97]) by studserv.stud.uni-hannover.de (8.12.0.Beta19/8.12.0.Beta19/MX/check_local4.4) with ESMTP id f8AMNjo6003968 for ; Tue, 11 Sep 2001 00:23:52 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00550; Mon, 10 Sep 2001 20:40:33 +0200 Message-ID: <20010910204033.61554@thrai.stud.uni-hannover.de> Date: Mon, 10 Sep 2001 20:40:33 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen's SoC References: <20010908161142.05347@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Sep 10, 2001 at 04:54:45PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 10, 2001 at 04:54:45PM +0200, Juergen Goeritz wrote: [...] > I am interested in the development of a pipeline floating point > instruction set. Development for F-CPU is only interesting for > me if I can use the F-CPU with my mCluster design. You won't contribute anything unless it helps your project? Is that what you mean? [...] > I was thinking of setting up a company to handle industrial > interest in the F-CPU - to work as coordination and contact. > This company could handle e.g. coordination of development, > licensing of established versions for industrial use, collect > donations, promote F-CPU, produce chips for public use, etc. > The shares of this company would belong to F-CPU participants > who want entitlement into this company because of their work > done for F-CPU. Before we can coordinate, license, promote, produce or sell the F-CPU, we must *build* it, or at least finish the design and verify it. At the moment, there is nothing to do for a company. [...] > Michael, I am not somebody having only a lot of money and knowing > nothing about the contence/development. I have built a small > start-up company with a good product idea (that's what I think) > and could participate into this 'AG idea' personally but can't > finance it completely by myself. I don't want to take control > over the F-CPU development. I simply had that idea of using it > in my design (and get it working for space use). That's all. > Of course I could also use some partners. I work on the F-CPU for fun, and I want it to stay that way. You want to make money with your mCluster design -- I don't mind, but you should be aware that you can't count on me. I already have a project to work on, and I want to finish it before I start another one. Talking about business and making money is IMHO fruitless, as long as the F-CPU is a `soap bubble' in our minds. Please let it become real first. After that, we can talk about everything else. > > On the other hand, it may be already too late. I'm not willing to make > > any deals with people I don't trust -- and I can't trust people who are > > unable (or unwilling) to come to the point and say what they mean. > > I didn't meet you yet, can't say anything about trust. > But maybe you know me already and use some email alias? Definitely not. [...] > The story behind why I was complaining about GPL use in > the F-CPU project is that I believe that it is not really > covering your work. GPL was designed as software license. > It should be adapted to cover hardware development first. > See some explanations in other mails. Juergen, you contradict yourself. On one hand, you claim that the GPL does not cover (and thus protect) the F-CPU and that it should be replaced, on the other hand you proposed a license that offers even *less* protection but allows you to use the F-CPU in your proprietary design. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Mon Sep 10 15:19:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokP-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:45 +0200 (CEST) Received: (qmail 8266 invoked by uid 0); 10 Sep 2001 23:45:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 10 Sep 2001 23:45:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ANjLV22572 for ; Mon, 10 Sep 2001 19:45:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 23:43:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ANh6v21868 for f-cpu-list; Mon, 10 Sep 2001 19:43:06 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh3C21861 for ; Mon, 10 Sep 2001 19:43:03 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh0e15964 for ; Mon, 10 Sep 2001 19:43:02 -0400 Received: from tribble.stud.uni-hannover.de (root@a097.home.uni-hannover.de [130.75.232.97]) by studserv.stud.uni-hannover.de (8.12.0.Beta19/8.12.0.Beta19/MX/check_local4.4) with ESMTP id f8AMNjo8003968 for ; Tue, 11 Sep 2001 00:23:57 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00599; Mon, 10 Sep 2001 15:19:55 +0200 Message-ID: <20010910151955.08892@thrai.stud.uni-hannover.de> Date: Mon, 10 Sep 2001 15:19:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B9C2CC3.8A6C190B@ifrance.com>; from nicO on Sun, Sep 09, 2001 at 11:00:19PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 09, 2001 at 11:00:19PM -0400, nicO wrote: [...] > I don't know exactly where is the limit that Micheal want to put. but i > know that he prefer design rather than thinking about licence issue. Did I really say that? > >From my point of view, i think that prorietary SoC should be possibly > made with F-CPU code. Maybe we could use the IP sense of view from > opencores.org. They have defined a "simple" Bus for SoC (Wishbones), so > we could defined a fcpu component (IP?). So every thing inside this bloc > is under GPL (or GPL like) the other part is what you want. Adding a WISHBONE interface is a good idea (at least as a configurable option). The interface specification is in the Public Domain, which means that we can use it and still release the F-CPU core under the terms of the GPL (or any other License). On the other hand, I want the License to be valid for the whole chip, up to (and including) the socket it is plugged into. Users *must* be able to replace the F-CPU core with a modified version, and that's impossible if there is any proprietary IP on the chip. The only solution I can see is a 2-chip approach: make an external WISHBONE interface and put the proprietary stuff into another chip. That's no longer an SoC, of course. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Mon Sep 10 23:25:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokQ-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:46 +0200 (CEST) Received: (qmail 26356 invoked by uid 0); 10 Sep 2001 23:45:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx07) with SMTP; 10 Sep 2001 23:45:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ANjOx22610 for ; Mon, 10 Sep 2001 19:45:24 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 23:43:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ANh9u21891 for f-cpu-list; Mon, 10 Sep 2001 19:43:09 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh6C21872 for ; Mon, 10 Sep 2001 19:43:06 -0400 Received: from studserv.stud.uni-hannover.de (root@mx.stud.uni-hannover.de [130.75.176.3]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANh8e15972 for ; Mon, 10 Sep 2001 19:43:09 -0400 Received: from tribble.stud.uni-hannover.de (root@a097.home.uni-hannover.de [130.75.232.97]) by studserv.stud.uni-hannover.de (8.12.0.Beta19/8.12.0.Beta19/MX/check_local4.4) with ESMTP id f8AMNjo4003968 for ; Tue, 11 Sep 2001 00:23:46 +0200 (MET DST) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA00927; Mon, 10 Sep 2001 23:25:07 +0200 Message-ID: <20010910232506.08553@thrai.stud.uni-hannover.de> Date: Mon, 10 Sep 2001 23:25:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <3B9C2CC3.8A6C190B@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Sep 10, 2001 at 12:08:38PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 10, 2001 at 12:08:38PM +0200, Juergen Goeritz wrote: [...] > P.S. In my opinion the GPL license has a big drawback when > you add own components on the netlist level. My standpoint > is that this is the weak point. A netlist is comparable to > '.o' files or libraries (vendor macro instantiations like > gates are connected to each other in the netlist). Good > people can write and modify netlists directly. Netlists > mostly are produced by proprietary tools, e.g. synthesis. One can also modify .o/.a/.so or executable files directly (I've done that several times), but they still don't qualify as `source code'. Whether .o files are generated with a free compiler/assembler or a proprietary toolchain doesn't matter at all. > When you follow this thought you end up with a system > around the f-cpu that is completely outside the license > coverage because libraries and operating systems (or the > chip - in my thought) are not covered. Quoting from the GPL (section 3): The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. The `preferred form of the work for making modifications' is the high-level VHDL (Verilog, other HDL...) source, not the netlist (which is a translated form). Changes at the netlist level are not allowed because they will be lost when a new netlist is generated from the high-level source. The phrase `all the source code for all modules it contains' means that the high-level source for *all* components of the SoC must be released. Vendor-specific gate libraries shall fall under the `special exception' rule, since they are `normally distributed with the major components (compiler, ...) of the operating system', that is, the synthesis tools and/or the manufacturing process. If interpreted in a certain way, the GPL makes sense for Free Hardware, too. After all, modern hardware and software development don't differ much, and the borderline between them is moving. You can implement most (if not all) algorithms entirely in hardware (fast) or software that runs on a `generic' processor (cheap), or use a mixed approach (e.g. a hardware coprocessor for timing-critical parts). More recent research deals with reconfigurable computers that may be able to `compile', `load' and `run' a `program' written in any language (including VHDL/Verilog), or with the automated design of application-specific CPUs (plus matching compilers) on the basis of ordinary (software) programs (see MOVE). >From a more global (visionary? crazy?) point of view, there is no fundamental difference between hard- and software development; they use different terminologies (for historical reasons, I guess), but they both serve the same purpose: implementation of an algorithm. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Sep 10 22:17:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokS-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:48 +0200 (CEST) Received: (qmail 26413 invoked by uid 0); 10 Sep 2001 23:50:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 10 Sep 2001 23:50:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ANoCO23151 for ; Mon, 10 Sep 2001 19:50:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 10 Sep 2001 23:48:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ANmK722709 for f-cpu-list; Mon, 10 Sep 2001 19:48:20 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANmHC22706 for ; Mon, 10 Sep 2001 19:48:17 -0400 Received: from delay-1v.clubint.net (delay-1v.clubint.net [194.158.96.105]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8ANmKe16134 for ; Mon, 10 Sep 2001 19:48:20 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA16565; Mon, 10 Sep 2001 22:17:07 +0200 (MET DST) Date: Mon, 10 Sep 2001 22:17:07 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Cc: Malush@mailandnews.com Subject: Re: [f-cpu] Message-ID: <3B9EF34B@MailAndNews.com> X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f8ANmHC22707 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Once in a while we receive a message like that... ----Message d'origine---- De: Shahar Goldin >OK now I don't know much about CPU's and stuff of that nature but the manual >needs some immediate changes, IMO > >-- Highlight outdated sections somehow > -In some places the manual contradicts itself entirly (we won't be able to >fit these in Intel MoBo's , later recomended that we use Celeron MoBos) > >-- Include a list of books for reference > >This would help alot >I hope I'm sending this to the right place > > >(this may have been suggested before but I'm not going to read 3 years of >Mailing list archives ;-) > What you are refering to is a document inside another document. The part 1 of the manual (well, the up-to-date one) includes an OLD document which is probably the first one that describes the _intended_ features for an _hypothetical_ implementation. I have taken a lot of care to indicate that this document is included for _historical_ reasons and it is not of any other value now. It was written three years ago and we are now writing VHDL for a CPU which is described in the following parts of the manual. In the original HTML version i had 'highlighted' the 'old' parts but i don't think it survived the translation to LaTeX. However if you read in the correct order (from the first page to the last page) you will read the disclaimers _before_ the nasty historical stuff. Concerning the reference books : go to your local university library and spend some months reading whatever you can find on the subject :-) Btw, books are useless without a bit of 'real' experience, theory is useless without practice. Yes, we are hackers, welcome to the club :-) If you have other questions, yes : f-cpu@seul.org is the right place to ask them. I hope i was helpful and you will stay in the neighbourhood, regards, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Sep 10 22:45:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokT-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:49 +0200 (CEST) Received: (qmail 18284 invoked by uid 0); 11 Sep 2001 00:32:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 11 Sep 2001 00:32:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8B0WPl24245 for ; Mon, 10 Sep 2001 20:32:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 00:31:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8B0VWw23989 for f-cpu-list; Mon, 10 Sep 2001 20:31:32 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0VRC23986 for ; Mon, 10 Sep 2001 20:31:28 -0400 Received: from delay-1v.clubint.net (delay-1v.clubint.net [194.158.96.105]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0VUe19567 for ; Mon, 10 Sep 2001 20:31:30 -0400 Received: from club-internet.fr (localhost [127.0.0.1]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA00543 for f-cpu@seul.org; Mon, 10 Sep 2001 22:45:16 +0200 (MET DST) Date: Mon, 10 Sep 2001 22:45:16 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] making things work X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f8B0VSC23987 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! my local work directory has reached new size heights. The (future) inclusion of Michael's assembler won't help :-P Michael Riepe : >On Sun, Sep 09, 2001 at 08:52:51PM +0200, whygee@club-internet.fr wrote: >[...] >> >> Btw, i will have to modify your ASU (at least) >> >> because things have evolved quite a bit in the last months... >> >What exactly? Please send patches if possible. >> there are only a few changes necessary. >> max_chunck_size for example. > >MAX_CHUNK_SIZE must currently be 64 -- the adder doesn't handle 32-bit >(and probably never will -- it may be easier to write a separate 32-bit >version, and let the EU_IMU wrapper entity include the appropriate one). Yes but it seems that the symbolic names have been moved or renamed or something like that. I'll have to fix that... >> Btw i would like to 'split' the ASU into two parts, >> so that the clocking can be done at a higher level. > >The stages are already separate processes (that is, they're easy to >separate), and the pipeline register is concentrated at the end of the >first stage. would it be possible, then, to split the ASU in two files ? i'll try when i can... >> Or if it is possible to define (once again) a 'generic' >> pipeline latch ... so as few changes as possible are necessary >> if the latches have to change. > >That would mean that we have to use a register component again (I'd prefer >a concurrent procedure, because it would make the code more readable, but >some synthesis tools don't grok edge expressions in a procedure. *argh*). I have the intention of doing the 'clocking' in the top level VHDL file. >[...] >> btw concerning your asm, it complains about some missing ELF >> libraries :-( > >Didn't I mention that it won't compile? ;) Before you try again, >install the latest libelf pre-release from my homepage; the URL is >http://www.stud.uni-hannover.de/~michael/software/libelf-0.7.1-pre6.tar.gz >But please do not publish this ANYWHERE! i'm downloading the tgz. will you put your asm on the GAOS CVS later/one day ? Concerning the clock : using the 'ugly' architecture is dangerous. I discovered that i had messed up the NCO loop. I have moved the generic_adder stuff to a 'common' directory. Reading it was very interesting and i discovered new VHDL tricks... but i didn't know (reading the testbench) that one could instanciate a procedure... Maybe i didn't understand well because when i wanted to code a similar stuff, the compilers complained. I'm still a newbie... my snapshots are getting bigger and bigger all the time, and i only concentrate on VHDL now. Your scripts are not yet integrated. I'll come back to France in two days, btw. > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Sep 10 21:57:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokU-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:50 +0200 (CEST) Received: (qmail 14300 invoked by uid 0); 11 Sep 2001 00:43:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 11 Sep 2001 00:43:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8B0hGA24660 for ; Mon, 10 Sep 2001 20:43:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 00:42:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8B0gRF24403 for f-cpu-list; Mon, 10 Sep 2001 20:42:27 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0gNC24400 for ; Mon, 10 Sep 2001 20:42:23 -0400 Received: from imf08bis.bellsouth.net (mail008.mail.bellsouth.net [205.152.58.28]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0gQe19757 for ; Mon, 10 Sep 2001 20:42:26 -0400 Received: from computer ([209.215.11.15]) by imf11bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010910195210.MONQ14126.imf11bis.bellsouth.net@computer>; Mon, 10 Sep 2001 15:52:10 -0400 Message-ID: <003a01c13a32$c9a516a0$0f0bd7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Any Date: Mon, 10 Sep 2001 14:57:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C13A08.DFF4DB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C13A08.DFF4DB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If I were to look back a Year - the discussion on liscencing has = re-surfaced. My friend Whygee stated just a few days ago that the F-CPU = is two or more years away to fruition. I believe he is correct. Your = time could be better spent doing a design that will (Hopefully WORK). = There currently isn't enough VHDL created to even think or waste your = time on liscencing something that doesn't exist. JG said he could design a CPU himself - good - get at it. = Unfortunately; all I can contribute is a tidbit here and there because I = don't use VHDL - use all Schematic Drawings which are available - pay = the postage. =20 Regards Dick Hartney ------=_NextPart_000_0037_01C13A08.DFF4DB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If I were to look back a Year - the = discussion on=20 liscencing has re-surfaced.  My friend Whygee stated just a few = days ago=20 that the F-CPU is two or more years away to fruition.  I believe he = is=20 correct.  Your time could be better spent doing a design that will=20 (Hopefully WORK).  There currently isn't enough VHDL created to = even think=20 or waste your time on liscencing something that doesn't = exist.
 
JG said he could design a CPU himself - = good - get=20 at it.  Unfortunately; all I can contribute is a tidbit here and = there=20 because I don't use VHDL - use all Schematic Drawings which are = available - pay=20 the postage. 
 
Regards
Dick Hartney
------=_NextPart_000_0037_01C13A08.DFF4DB40-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Sep 10 12:11:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokV-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:51 +0200 (CEST) Received: (qmail 20320 invoked by uid 0); 11 Sep 2001 00:53:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 11 Sep 2001 00:53:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8B0rtY26137 for ; Mon, 10 Sep 2001 20:53:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 00:53:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8B0r8L25882 for f-cpu-list; Mon, 10 Sep 2001 20:53:08 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0r5C25878 for ; Mon, 10 Sep 2001 20:53:05 -0400 Received: from main.jetnet.ab.ca (root@jetnet.ab.ca [207.153.11.66]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8B0r8e20004 for ; Mon, 10 Sep 2001 20:53:08 -0400 Received: from jetnet.ab.ca (dialin37.jetnet.ab.ca [207.153.6.37]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA13210 for ; Mon, 10 Sep 2001 18:53:02 -0600 (MDT) Message-ID: <3B9C91DC.5923FB8D@jetnet.ab.ca> Date: Mon, 10 Sep 2001 04:11:40 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Any References: <003a01c13a32$c9a516a0$0f0bd7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "Richard E. Hartny" wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable Schematics are still good docs as PDF files. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 11 11:14:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokb-0000ZB-01 for ; Tue, 11 Sep 2001 16:42:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:57 +0200 (CEST) Received: (qmail 12566 invoked by uid 0); 11 Sep 2001 09:09:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 11 Sep 2001 09:09:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8B991910112 for ; Tue, 11 Sep 2001 05:09:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 09:08:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8B98b809856 for f-cpu-list; Tue, 11 Sep 2001 05:08:37 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8B98aC09853 for ; Tue, 11 Sep 2001 05:08:36 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8B98ce27934 for ; Tue, 11 Sep 2001 05:08:38 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15gjcs-0003r6-00 for f-cpu@seul.org; Tue, 11 Sep 2001 11:14:38 +0200 Date: Tue, 11 Sep 2001 11:14:38 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen's SoC In-Reply-To: <20010910204033.61554@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > [...] > > I am interested in the development of a pipeline floating point > > instruction set. Development for F-CPU is only interesting for > > me if I can use the F-CPU with my mCluster design. > > You won't contribute anything unless it helps your project? > Is that what you mean? I can't work my time on a free project just for fun. I have to look for the bills to get paid too. In my free time I am designing water falls, ponds and streams for renaturation and garden/park surroundings when I am not seeding trees. > [...] > > The story behind why I was complaining about GPL use in > > the F-CPU project is that I believe that it is not really > > covering your work. GPL was designed as software license. > > It should be adapted to cover hardware development first. > > See some explanations in other mails. > > Juergen, you contradict yourself. On one hand, you claim that the > GPL does not cover (and thus protect) the F-CPU and that it should be > replaced, on the other hand you proposed a license that offers even *less* > protection but allows you to use the F-CPU in your proprietary design. There a two parts in me about your project. First part wants F-CPU to become real and help the contributors. And that's why I complained about using GPL for the project because I think it's not covering what you want. The second part would rather use F-CPU in my own design instead of writing a new cpu. It was very interesting to see how people from 'free' projects react when one wants to use their baby in another design. Good learning lesson. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Hans.Summers@tudor.com Tue Sep 11 11:16:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokc-0000ZB-00 for ; Tue, 11 Sep 2001 16:42:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:42:58 +0200 (CEST) Received: (qmail 884 invoked by uid 0); 11 Sep 2001 09:16:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 11 Sep 2001 09:16:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8B9Gta10487 for ; Tue, 11 Sep 2001 05:16:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 09:16:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8B9GaZ10239 for f-cpu-list; Tue, 11 Sep 2001 05:16:36 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8B9GZC10236 for ; Tue, 11 Sep 2001 05:16:35 -0400 Received: from ns2.tudor.com (ns2.tudor.com [63.93.49.196]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8B9Gde28110 for ; Tue, 11 Sep 2001 05:16:39 -0400 Received: from mail1.grn.tudor.com (internal-mail-hub [10.2.10.18]) by ns2.tudor.com (8.9.3/8.9.3) with ESMTP id FAA01115 for ; Tue, 11 Sep 2001 05:10:14 -0400 (EDT) Received: from po-exch-lon.lon.tudor.com (po1-exch.lon.tudor.com [10.5.10.12]) by mail1.grn.tudor.com (8.9.3/8.9.3) with ESMTP id FAA12198 for ; Tue, 11 Sep 2001 05:16:29 -0400 (EDT) Received: by po1-exch.lon.tudor.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 10:16:29 +0100 Message-ID: <0CFA3081B86BD311B37A00902762718F0152F0CB@po1-exch.lon.tudor.com> From: Hans Summers To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] License issues GPL/LGPL and Juergen's SoC Date: Tue, 11 Sep 2001 10:16:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N [...] > > The second part would rather use F-CPU in my own design > instead of writing a new cpu. It was very interesting to > see how people from 'free' projects react when one wants > to use their baby in another design. Good learning lesson. > License issues don't interest me and I didn't properly read the mails about them. But here is someone (JG) who wants to help and wants to actually use the F-CPU in a real project. Why not welcome him with open arms and see how he can contribute? Perhaps his angle could provide the impetus to one day really make the F-CPU a physical reality rather than just dream about it. Or, at least to increase the probability of that happenning, which it seems to me is currently not that high. > > JG > ------------------ Hans Summers http://www.HansSummers.Com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Sep 11 14:44:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gokf-0000ZB-01 for ; Tue, 11 Sep 2001 16:43:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Sep 2001 16:43:01 +0200 (CEST) Received: (qmail 14424 invoked by uid 0); 11 Sep 2001 12:39:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 11 Sep 2001 12:39:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BCdAF16778 for ; Tue, 11 Sep 2001 08:39:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 12:38:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BCckf16528 for f-cpu-list; Tue, 11 Sep 2001 08:38:46 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BCciC16525 for ; Tue, 11 Sep 2001 08:38:44 -0400 Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8BCcke29594 for ; Tue, 11 Sep 2001 08:38:46 -0400 Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15gmuD-00047K-00 for f-cpu@seul.org; Tue, 11 Sep 2001 14:44:45 +0200 Date: Tue, 11 Sep 2001 14:44:45 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC In-Reply-To: <20010910232506.08553@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 10 Sep 2001, Michael Riepe wrote: > On Mon, Sep 10, 2001 at 12:08:38PM +0200, Juergen Goeritz wrote: > [...] > > P.S. In my opinion the GPL license has a big drawback when > > you add own components on the netlist level. My standpoint > > is that this is the weak point. A netlist is comparable to > > '.o' files or libraries (vendor macro instantiations like > > gates are connected to each other in the netlist). Good > > people can write and modify netlists directly. Netlists > > mostly are produced by proprietary tools, e.g. synthesis. > > One can also modify .o/.a/.so or executable files directly (I've done > that several times), but they still don't qualify as `source code'. > Whether .o files are generated with a free compiler/assembler or a > proprietary toolchain doesn't matter at all. > > > When you follow this thought you end up with a system > > around the f-cpu that is completely outside the license > > coverage because libraries and operating systems (or the > > chip - in my thought) are not covered. > > Quoting from the GPL (section 3): > > The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable. > > The `preferred form of the work for making modifications' is the > high-level VHDL (Verilog, other HDL...) source, not the netlist (which > is a translated form). Changes at the netlist level are not allowed > because they will be lost when a new netlist is generated from the > high-level source. > > The phrase `all the source code for all modules it contains' means that > the high-level source for *all* components of the SoC must be released. > > Vendor-specific gate libraries shall fall under the `special exception' > rule, since they are `normally distributed with the major components > (compiler, ...) of the operating system', that is, the synthesis tools > and/or the manufacturing process. How about thinking of IPs as programs? When I run a program on an OS, the GPL license does not affect other programs that run on the same OS. When one runs the F-CPU IP on a chip how can it then affect the other IPs on the chip? Just imagine some kind of a loadable cpu core if you think this is to far ahead. If you now think of the other IPs being the 'operating system' to run the F-CPU IP you are on my view. > If interpreted in a certain way, the GPL makes sense for Free Hardware, > too. After all, modern hardware and software development don't differ > much, and the borderline between them is moving. You can implement most > (if not all) algorithms entirely in hardware (fast) or software that > runs on a `generic' processor (cheap), or use a mixed approach (e.g. a > hardware coprocessor for timing-critical parts). More recent research > deals with reconfigurable computers that may be able to `compile', `load' > and `run' a `program' written in any language (including VHDL/Verilog), > or with the automated design of application-specific CPUs (plus matching > compilers) on the basis of ordinary (software) programs (see MOVE). > > >From a more global (visionary? crazy?) point of view, there is no > fundamental difference between hard- and software development; they use > different terminologies (for historical reasons, I guess), but they both > serve the same purpose: implementation of an algorithm. :-) There still is a difference. Otherwise there would be a meta language where you can write your application and decide later what to put in hardware and what to put in software. That meta language would be a very interesting project... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 11 16:27:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxhy-0008Le-00 for ; Wed, 12 Sep 2001 02:16:50 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:16:50 +0200 (CEST) Received: (qmail 18209 invoked by uid 0); 11 Sep 2001 16:05:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 11 Sep 2001 16:05:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BG5bm20349 for ; Tue, 11 Sep 2001 12:05:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 16:05:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BG5ED20080 for f-cpu-list; Tue, 11 Sep 2001 12:05:14 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BG5DC20077 for ; Tue, 11 Sep 2001 12:05:13 -0400 Received: from tribble.stud.uni-hannover.de (root@a250.home.uni-hannover.de [130.75.232.250]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8BG5Fe32122 for ; Tue, 11 Sep 2001 12:05:15 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00805; Tue, 11 Sep 2001 16:27:19 +0200 Message-ID: <20010911162719.25990@thrai.stud.uni-hannover.de> Date: Tue, 11 Sep 2001 16:27:19 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Any References: <003a01c13a32$c9a516a0$0f0bd7d1@computer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <003a01c13a32$c9a516a0$0f0bd7d1@computer>; from Richard E. Hartny on Mon, Sep 10, 2001 at 02:57:13PM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 10, 2001 at 02:57:13PM -0500, Richard E. Hartny wrote: [...] > Your time could be better spent doing a design that will (Hopefully WORK). [...] That's exactly what I'm trying to do. *sigh* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 11 14:49:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxhz-0008Le-00 for ; Wed, 12 Sep 2001 02:16:51 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:16:51 +0200 (CEST) Received: (qmail 22279 invoked by uid 0); 11 Sep 2001 16:05:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 11 Sep 2001 16:05:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BG5tI20596 for ; Tue, 11 Sep 2001 12:05:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 16:05:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BG5aN20320 for f-cpu-list; Tue, 11 Sep 2001 12:05:36 -0400 Received: from moria.mit.edu (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BG5YC20308 for ; Tue, 11 Sep 2001 12:05:34 -0400 Received: from tribble.stud.uni-hannover.de (root@a250.home.uni-hannover.de [130.75.232.250]) by moria.mit.edu (8.11.6/8.11.6) with ESMTP id f8BG5Ze32130 for ; Tue, 11 Sep 2001 12:05:35 -0400 Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00551; Tue, 11 Sep 2001 14:49:42 +0200 Message-ID: <20010911144942.16746@thrai.stud.uni-hannover.de> Date: Tue, 11 Sep 2001 14:49:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] making things work References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Sep 10, 2001 at 10:45:16PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi *, On Mon, Sep 10, 2001 at 10:45:16PM +0200, whygee@club-internet.fr wrote: > > my local work directory has reached new size heights. > The (future) inclusion of Michael's assembler won't help :-P You should see mine ;) > Michael Riepe : > >On Sun, Sep 09, 2001 at 08:52:51PM +0200, whygee@club-internet.fr wrote: > >[...] > >> >> Btw, i will have to modify your ASU (at least) > >> >> because things have evolved quite a bit in the last months... > >> >What exactly? Please send patches if possible. > >> there are only a few changes necessary. > >> max_chunck_size for example. > > > >MAX_CHUNK_SIZE must currently be 64 -- the adder doesn't handle 32-bit > >(and probably never will -- it may be easier to write a separate 32-bit > >version, and let the EU_IMU wrapper entity include the appropriate one). > > Yes but it seems that the symbolic names have been moved > or renamed or something like that. I'll have to fix that... It's still called MAX_CHUNK_SIZE in eu_asu/asu.vhdl. > >> Btw i would like to 'split' the ASU into two parts, > >> so that the clocking can be done at a higher level. > > > >The stages are already separate processes (that is, they're easy to > >separate), and the pipeline register is concentrated at the end of the > >first stage. > > would it be possible, then, to split the ASU in two files ? > i'll try when i can... Of course it's possible. But is it also reasonable? > >> Or if it is possible to define (once again) a 'generic' > >> pipeline latch ... so as few changes as possible are necessary > >> if the latches have to change. > > > >That would mean that we have to use a register component again (I'd prefer > >a concurrent procedure, because it would make the code more readable, but > >some synthesis tools don't grok edge expressions in a procedure. *argh*). > > I have the intention of doing the 'clocking' in the top level > VHDL file. What's the reason for that? You may have noticed that both ASU and IMU have an `enable' port now; Nicolas convinced me to add that. The signal is supposed to be raised when an instruction is issued, and propagates through the pipeline, depending on the current mode of operation (that is, the later stages are disabled when you do an 8-bit multiplication, for example). That's hard to do at the outer levels. > >[...] > >> btw concerning your asm, it complains about some missing ELF > >> libraries :-( > > > >Didn't I mention that it won't compile? ;) Before you try again, > >install the latest libelf pre-release from my homepage; the URL is > >http://www.stud.uni-hannover.de/~michael/software/libelf-0.7.1-pre6.tar.gz > >But please do not publish this ANYWHERE! > > i'm downloading the tgz. > will you put your asm on the GAOS CVS later/one day ? Once the sources are stable. I will have to move files and directories around a lot when I add the other tools to the package, and it's better not to do that in CVS ;) > Concerning the clock : using the 'ugly' architecture > is dangerous. I discovered that i had messed up the NCO loop. Shit happens ;) In general, ugly code tends to produce ugly errors. Did you see my simple NCO entity, btw? > I have moved the generic_adder stuff to a 'common' directory. > Reading it was very interesting and i discovered new VHDL > tricks... but i didn't know (reading the testbench) that > one could instanciate a procedure... Maybe i didn't understand > well because when i wanted to code a similar stuff, > the compilers complained. I'm still a newbie... You can use a procedure as a concurrent statement when all of its outputs are declared as signals. If they're variables, the procedure will work only as a sequential statement (that is, inside a process). That's why there are the S_* procedures in the Generic_Adder package. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 11 22:37:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxi5-0008Le-01 for ; Wed, 12 Sep 2001 02:16:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:16:57 +0200 (CEST) Received: (qmail 10548 invoked by uid 0); 11 Sep 2001 20:39:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 11 Sep 2001 20:39:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BKdkN23794 for ; Tue, 11 Sep 2001 16:39:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 20:37:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BKbNv23503 for f-cpu-list; Tue, 11 Sep 2001 16:37:23 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BKbLC23500 for ; Tue, 11 Sep 2001 16:37:22 -0400 Received: by moria.seul.org (Postfix) id C76CB1462F9; Tue, 11 Sep 2001 16:37:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.seul.org (Postfix) with ESMTP id 41B7F1462F8 for ; Tue, 11 Sep 2001 16:37:25 -0400 (EDT) Received: from club-internet.fr (localhost [127.0.0.1]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA21613 for f-cpu@seul.org; Tue, 11 Sep 2001 22:37:16 +0200 (MET DST) Date: Tue, 11 Sep 2001 22:37:16 +0200 (MET DST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] beard mode on (suite et peut-etre fin) X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f8BKbMC23501 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i just saw a translation of a text from RMS and here is the original text : http://www.fsf.org/philosophy/gpl-american-way.html Of course it is not directly related to our situation but some parts (well, not everything, forget the part about M$ attacks) are easily transposed : " For the sake of cooperation, we encourage others to modify and extend the programs that we publish. For the sake of freedom, we set the condition that these modified versions of our programs must respect your freedom just like the original version. We encourage two-way cooperation by rejecting parasites: whoever wishes to copy parts of our software into his program must let us use parts of that program in our programs. Nobody is forced to join our club, but those who wish to participate must offer us the same cooperation they receive from us. That makes the system fair. " This means that it is not a matter of what you offer in exchange, because freedom is not a 'ware' that can be sold (well, not anymore, slavery has been abolished, i think). It is further explicited later : " From time to time, companies have said to us, "We would make an improved version of this program if you allow us to release it without freedom." We say, "No thanks--your improvements might be useful if they were free, but if we can't use them in freedom, they are no good at all." Then they appeal to our egos, saying that our code will have "more users" inside their proprietary programs. We respond that we value our community's freedom more than an irrelevant form of popularity. " Of course we will discuss at length about the exact meaning of the GPL in the context of the F-CPU. i hope that we will find a compromise, in terms of unconstrained freedom and maybe of usefulness for the industry. But it is the code writer(s) who decides of the copyright he puts on his work. You can now go back to your previous activity, YG :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Sep 11 03:40:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxi7-0008Le-00 for ; Wed, 12 Sep 2001 02:16:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:16:59 +0200 (CEST) Received: (qmail 24547 invoked by uid 0); 11 Sep 2001 20:48:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 11 Sep 2001 20:48:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BKmok24198 for ; Tue, 11 Sep 2001 16:48:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 20:47:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BKlG223945 for f-cpu-list; Tue, 11 Sep 2001 16:47:16 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BKlFC23942 for ; Tue, 11 Sep 2001 16:47:15 -0400 Received: by moria.seul.org (Postfix) id 7DF7C1462FA; Tue, 11 Sep 2001 16:47:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-222.vlt.club-internet.fr [194.158.109.222]) by moria.seul.org (Postfix) with ESMTP id A8F7E1462F9 for ; Tue, 11 Sep 2001 16:47:18 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 71DE8170E for ; Mon, 10 Sep 2001 21:40:40 -0400 (EDT) Message-ID: <3B9D6B98.99245DA9@ifrance.com> Date: Mon, 10 Sep 2001 21:40:40 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New way of doing testbench References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara a écrit : > > On Mon, 10 Sep 2001, nicO wrote: > > > http://www.testbuilder.net/resources.thtml > > > > Maybe a good way to write a testbench for vhdl. I don't if it could work > > with free HDL or Simili. > > Usually the interfaces to simulators are the difficult part of new > Verification languages and class libraries. The biggest commercial > simulators are usually well supported. Altough all features are not > supported in all simulators. For example Vera supports Temporal > expressions only with VCS currently. With Verilog the interfaces are > usually easier because PLI is well standardized. There is not yet standard > FLI for VHDL. > I think that they used the PLI interface, it's quite easy to interface it to the vhdl signal. > > It's a way to interface HDL and C++. It look very nice and it's free ! > > I wrote my masters thesis about Object Oriented ASIC vericiation, so > methodology is quite familiar for me. I have written with Synopsys VERA > one big testbench (30kloc). And now I have much more complex TB under > construction. I would not go back to VHDL testbenches. OO methodology and > higher level languages just make coding so much easier. Espaecially when > the TB complexity is all the time rising. > > > Synopsys VERA has one very nice feature for CPU testing but unfortunately > the tool is commercial. VERA stream generator can generate quite easily > random but sane instruction stream. The instruction set is just described > with BNF and after that the generator can generate instructions. > I have heard that stream generator was developed for Sun Sparc > verification originally. > > It's completly free ! I ask to put it under LGPL and maybe it will work. nicO > ============================================================================= > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian > Vasamatie 1 C 16 | IRC: embo | curved-space fault in > 02630 Espoo | | write-only file system > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 12 05:26:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxi8-0008Le-00 for ; Wed, 12 Sep 2001 02:17:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:17:00 +0200 (CEST) Received: (qmail 9062 invoked by uid 0); 11 Sep 2001 21:15:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 11 Sep 2001 21:15:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BLFIm24719 for ; Tue, 11 Sep 2001 17:15:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 21:14:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BLEtl24456 for f-cpu-list; Tue, 11 Sep 2001 17:14:55 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BLEsC24453 for ; Tue, 11 Sep 2001 17:14:54 -0400 Received: by moria.seul.org (Postfix) id 785DF1462FA; Tue, 11 Sep 2001 17:14:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-222.vlt.club-internet.fr [194.158.109.222]) by moria.seul.org (Postfix) with ESMTP id BC5611462F7 for ; Tue, 11 Sep 2001 17:14:57 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 87D581435 for ; Tue, 11 Sep 2001 23:26:11 -0400 (EDT) Message-ID: <3B9ED5D3.3376115C@ifrance.com> Date: Tue, 11 Sep 2001 23:26:11 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <3B9C2CC3.8A6C190B@ifrance.com> <20010910232506.08553@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >From a more global (visionary? crazy?) point of view, there is no > fundamental difference between hard- and software development; they use > different terminologies (for historical reasons, I guess), but they both > serve the same purpose: implementation of an algorithm. It's not crazy at all. Since i have worked for Infineon i didn't imagine that so much. I have worked in a team to design an interface. It's just a very big finite state machine. But to reduice the size, we defined a little 8bits RISC cpu (3 pipelines stages), the fsm has been written by software used as a ROM. So we save a lot of gate. We produice a system which is a mix of software and hardware for a typical hardware function. Maybe you have heard about codesign ? So you defined the function of your system and at a latest possible time you separate hardware and software. That's the future for me. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 12 06:14:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxiD-0008Le-00 for ; Wed, 12 Sep 2001 02:17:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:17:05 +0200 (CEST) Received: (qmail 8459 invoked by uid 0); 11 Sep 2001 22:03:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 11 Sep 2001 22:03:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BM3G725851 for ; Tue, 11 Sep 2001 18:03:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 22:02:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BM2s425592 for f-cpu-list; Tue, 11 Sep 2001 18:02:54 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BM2rC25589 for ; Tue, 11 Sep 2001 18:02:53 -0400 Received: by moria.seul.org (Postfix) id DD6C11462FA; Tue, 11 Sep 2001 18:02:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-222.vlt.club-internet.fr [194.158.109.222]) by moria.seul.org (Postfix) with ESMTP id D98221462F7 for ; Tue, 11 Sep 2001 18:02:55 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6F8901435 for ; Wed, 12 Sep 2001 00:14:09 -0400 (EDT) Message-ID: <3B9EE111.CA428915@ifrance.com> Date: Wed, 12 Sep 2001 00:14:09 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sun, Sep 09, 2001 at 11:00:19PM -0400, nicO wrote: > [...] > > I don't know exactly where is the limit that Micheal want to put. but i > > know that he prefer design rather than thinking about licence issue. > > Did I really say that? Whygee maybe, but it's only a shortcut. > > > >From my point of view, i think that prorietary SoC should be possibly > > made with F-CPU code. Maybe we could use the IP sense of view from > > opencores.org. They have defined a "simple" Bus for SoC (Wishbones), so > > we could defined a fcpu component (IP?). So every thing inside this bloc > > is under GPL (or GPL like) the other part is what you want. > > Adding a WISHBONE interface is a good idea (at least as a configurable > option). The interface specification is in the Public Domain, which > means that we can use it and still release the F-CPU core under the > terms of the GPL (or any other License). And it will be more simple to add it into a SoC. Whishbone is great but we need read-modify-write cycle, and i don't know if Wishbone do it. > > On the other hand, I want the License to be valid for the whole chip, > up to (and including) the socket it is plugged into. Users *must* > be able to replace the F-CPU core with a modified version, and that's > impossible if there is any proprietary IP on the chip. > You think only "pc" and it's socket. In which other product could you change the main processor ? "Pc" is an old fation to do a system. Think of embedded market (cars(30%-50% of the electronics industrie market in the futur !), train, plane,...), think of PDA, handel PC. That's the future, not PC or workstation ! Pc industrie are declined and devoted to wintel god and it won't change. X86 word make a course of Mips, ARM word the course of Mips/Watt, i propose the courses of the Mips/euros. > The only solution I can see is a 2-chip approach: make an external > WISHBONE interface and put the proprietary stuff into another chip. > That's no longer an SoC, of course. > And you lose all the benefit of it ! All future product must be very compact, with reduiced power consumption and cheap. So SoC are obligatory to reach that goal. For me, f-cpu should be include in proprietary chip. You want to change the physical chip. So nowdays, physical chip are remplaced by IP. So you could replace IP by another one (or the same but with different parameters, or an other cpu if you use C code). When you create a SoC it's the same that build a PCB in 80's but now it's on silicon die instead of epoxy. A SoC is so specialised ! So there isn't any interrest to change the chip. It's a complete system so you could always create a compatible chip with a complete different SoC. Imagine a mp3 producer, there is so many manner to make it. You could do it with dedicated HW or with a DSP or a powerfull RISC cpu, or with many little cpu. I hope a convince you. nicO Ps: This night, i think about the american people... > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 12 00:27:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxiG-0008Le-01 for ; Wed, 12 Sep 2001 02:17:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:17:08 +0200 (CEST) Received: (qmail 25015 invoked by uid 0); 11 Sep 2001 22:27:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 11 Sep 2001 22:27:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BMRxh26767 for ; Tue, 11 Sep 2001 18:27:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 22:27:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BMReS26521 for f-cpu-list; Tue, 11 Sep 2001 18:27:40 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BMRdC26518 for ; Tue, 11 Sep 2001 18:27:39 -0400 Received: by moria.seul.org (Postfix) id D8C571462FA; Tue, 11 Sep 2001 18:27:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a190.home.uni-hannover.de [130.75.232.190]) by moria.seul.org (Postfix) with ESMTP id DBC431462F7 for ; Tue, 11 Sep 2001 18:27:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA03047; Wed, 12 Sep 2001 00:27:34 +0200 Message-ID: <20010912002734.36261@thrai.stud.uni-hannover.de> Date: Wed, 12 Sep 2001 00:27:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <3B9C2CC3.8A6C190B@ifrance.com> <20010910232506.08553@thrai.stud.uni-hannover.de> <3B9ED5D3.3376115C@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B9ED5D3.3376115C@ifrance.com>; from nicO on Tue, Sep 11, 2001 at 11:26:11PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 11, 2001 at 11:26:11PM -0400, nicO wrote: > > >From a more global (visionary? crazy?) point of view, there is no > > fundamental difference between hard- and software development; they use > > different terminologies (for historical reasons, I guess), but they both > > serve the same purpose: implementation of an algorithm. > > It's not crazy at all. Since i have worked for Infineon i didn't imagine > that so much. I have worked in a team to design an interface. It's just > a very big finite state machine. But to reduice the size, we defined a > little 8bits RISC cpu (3 pipelines stages), the fsm has been written by > software used as a ROM. So we save a lot of gate. We produice a system > which is a mix of software and hardware for a typical hardware function. > > Maybe you have heard about codesign ? So you defined the function of > your system and at a latest possible time you separate hardware and > software. That's the future for me. That's not only the future, it's also a piece of history: IIRC, the first microprocessor was created for exactly the same reasons. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 12 01:37:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxiK-0008Le-00 for ; Wed, 12 Sep 2001 02:17:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:17:12 +0200 (CEST) Received: (qmail 14879 invoked by uid 0); 11 Sep 2001 23:39:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx22) with SMTP; 11 Sep 2001 23:39:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BNdTS28435 for ; Tue, 11 Sep 2001 19:39:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 23:37:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BNbpW28163 for f-cpu-list; Tue, 11 Sep 2001 19:37:51 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BNboC28160 for ; Tue, 11 Sep 2001 19:37:50 -0400 Received: by moria.seul.org (Postfix) id 2EFB31462FA; Tue, 11 Sep 2001 19:37:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a190.home.uni-hannover.de [130.75.232.190]) by moria.seul.org (Postfix) with ESMTP id 7CC3A1462F7 for ; Tue, 11 Sep 2001 19:37:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03233; Wed, 12 Sep 2001 01:37:45 +0200 Message-ID: <20010912013745.05028@thrai.stud.uni-hannover.de> Date: Wed, 12 Sep 2001 01:37:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B9EE111.CA428915@ifrance.com>; from nicO on Wed, Sep 12, 2001 at 12:14:09AM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: [...] > And it will be more simple to add it into a SoC. Whishbone is great but > we need read-modify-write cycle, and i don't know if Wishbone do it. It does. At least the documentation says so. [...] > You think only "pc" and it's socket. In which other product could you > change the main processor ? "Pc" is an old fation to do a system. Think > of embedded market (cars(30%-50% of the electronics industrie market in > the futur !), train, plane,...), think of PDA, handel PC. That's the > future, not PC or workstation ! Pc industrie are declined and devoted to > wintel god and it won't change. X86 word make a course of Mips, ARM word > the course of Mips/Watt, i propose the courses of the Mips/euros. No, I don't think "PC". But I think "workstation" and "server" -- they all have CPU sockets, usually, whether they use Intel CPUs or SPARCs, MIPS or PA-RISC, Alpha or PPC... > > The only solution I can see is a 2-chip approach: make an external > > WISHBONE interface and put the proprietary stuff into another chip. > > That's no longer an SoC, of course. > > > > And you lose all the benefit of it ! All future product must be very > compact, with reduiced power consumption and cheap. So SoC are > obligatory to reach that goal. For me, f-cpu should be include in > proprietary chip. You want to change the physical chip. So nowdays, > physical chip are remplaced by IP. So you could replace IP by another > one (or the same but with different parameters, or an other cpu if you > use C code). When you create a SoC it's the same that build a PCB in > 80's but now it's on silicon die instead of epoxy. Not really. All the PCBs I've seen used 100% proprietary components. > A SoC is so specialised ! So there isn't any interrest to change the > chip. It's a complete system so you could always create a compatible > chip with a complete different SoC. Imagine a mp3 producer, there is so > many manner to make it. You could do it with dedicated HW or with a DSP > or a powerfull RISC cpu, or with many little cpu. > > I hope a convince you. I absolutely don't mind if somebody builds an F-CPU based SoC. As long as users can get the complete source code under GPL ;) > Ps: This night, i think about the american people... I painted the background of my homepage dark this afternoon... I hope I won't have to paint it pitch black. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 11 19:46:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15gxiE-0008Le-00 for ; Wed, 12 Sep 2001 02:17:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Sep 2001 02:17:06 +0200 (CEST) Received: (qmail 31683 invoked by uid 0); 11 Sep 2001 22:06:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 11 Sep 2001 22:06:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8BM6Jv26174 for ; Tue, 11 Sep 2001 18:06:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 11 Sep 2001 22:06:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8BM60m25920 for f-cpu-list; Tue, 11 Sep 2001 18:06:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8BM5xC25917 for ; Tue, 11 Sep 2001 18:05:59 -0400 Received: by moria.seul.org (Postfix) id 8B0DE1462FA; Tue, 11 Sep 2001 18:06:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a190.home.uni-hannover.de [130.75.232.190]) by moria.seul.org (Postfix) with ESMTP id 5FD2A1462F7 for ; Tue, 11 Sep 2001 18:05:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01625; Tue, 11 Sep 2001 19:46:49 +0200 Message-ID: <20010911194649.40695@thrai.stud.uni-hannover.de> Date: Tue, 11 Sep 2001 19:46:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Sep 11, 2001 at 02:44:45PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 11, 2001 at 02:44:45PM +0200, Juergen Goeritz wrote: [...] > How about thinking of IPs as programs? When I run a program > on an OS, the GPL license does not affect other programs that > run on the same OS. When one runs the F-CPU IP on a chip how > can it then affect the other IPs on the chip? Just imagine some > kind of a loadable cpu core if you think this is to far ahead. > If you now think of the other IPs being the 'operating system' > to run the F-CPU IP you are on my view. [...] If you provide ways to install, remove, modify and replace any "program" independently without destroying the rest, I might agree with you, with one exception: all IPs should be considered "programs". I don't like this approach much, but I guess it's reasonable to allow this kind of "use", as long as users have the option to take advantage of all the rights they've been granted by the F-CPU license, without any restrictions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Wed Sep 12 07:43:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLV4-0004Zp-01 for ; Thu, 13 Sep 2001 03:41:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:06 +0200 (CEST) Received: (qmail 29745 invoked by uid 0); 12 Sep 2001 05:43:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Sep 2001 05:43:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8C5ht505737 for ; Wed, 12 Sep 2001 01:43:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 05:43:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8C5hOj05380 for f-cpu-list; Wed, 12 Sep 2001 01:43:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8C5hNC05377 for ; Wed, 12 Sep 2001 01:43:23 -0400 Received: by moria.seul.org (Postfix) id 0E9991462FA; Wed, 12 Sep 2001 01:43:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 7333D1462F7 for ; Wed, 12 Sep 2001 01:43:26 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA12079 for ; Wed, 12 Sep 2001 08:43:17 +0300 (EET DST) Date: Wed, 12 Sep 2001 08:43:17 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] New way of doing testbench In-Reply-To: <3B9D6B98.99245DA9@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 10 Sep 2001, nicO wrote: > Kim Enkovaara a écrit : > > > > Usually the interfaces to simulators are the difficult part of new > > Verification languages and class libraries. The biggest commercial > > simulators are usually well supported. Altough all features are not > > supported in all simulators. For example Vera supports Temporal > > expressions only with VCS currently. With Verilog the interfaces are > > usually easier because PLI is well standardized. There is not yet standard > > FLI for VHDL. > > > > I think that they used the PLI interface, it's quite easy to interface > it to the vhdl signal. At least in commercial simulators PLI can be only used with Verilog code. They have different interfaces for VHDL. For example with Modelsim Vera used PLI interface for Verilog and FLI for VHDL. I know that in dual language simulators you can use Verilog wrapper around VHDL code and that enables PLI. Also one problem is that usually these languages use quite extensivily the PLI interface and require almost complete implementation. Also the wrappers contain fixes for bugs in commercial simulators (at least used to contain). ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From alifed2001@yahoo.com Wed Sep 12 07:58:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLV5-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:07 +0200 (CEST) Received: (qmail 23938 invoked by uid 0); 12 Sep 2001 05:58:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 12 Sep 2001 05:58:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8C5wXx06240 for ; Wed, 12 Sep 2001 01:58:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 05:58:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8C5wFF05993 for f-cpu-list; Wed, 12 Sep 2001 01:58:15 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8C5wEC05990 for ; Wed, 12 Sep 2001 01:58:14 -0400 Received: by moria.seul.org (Postfix) id 31BE91462FB; Wed, 12 Sep 2001 01:58:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web20405.mail.yahoo.com (web20405.mail.yahoo.com [216.136.226.124]) by moria.seul.org (Postfix) with SMTP id AD38F1462FA for ; Wed, 12 Sep 2001 01:58:17 -0400 (EDT) Message-ID: <20010912055812.68809.qmail@web20405.mail.yahoo.com> Received: from [195.166.226.251] by web20405.mail.yahoo.com via HTTP; Tue, 11 Sep 2001 22:58:12 PDT Date: Tue, 11 Sep 2001 22:58:12 -0700 (PDT) From: ali fed Subject: [f-cpu] attention To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 10 USENI ROAD, ABAKPA ENUGU, ENUGU STATE, {VERY URGENT BUSINESS TRANSACTION} GREETINGS IN ORDER TO TRANSFER OUT (USD 26 MILLION DOLLARS) FROM OUR BANK. I HAVE THE COURAGE TO ASK YOU TO LOOK FOR A RELIABLE AND HONEST PERSON WHO WILL BE CAPABLE FOR THIS IMPORTANT BUSINESS BELIEVING THAT YOU WILL NEVER LET ME DOWN EITHER NOW OR IN FUTURE. I AM MR.ALISON FED, THE EASTERN DISTRICT BANK MANAGER OF UNITED BANK FOR AFRICA PLC. (UBA). THERE IS AN ACCOUNT OPENED IN THIS BANK IN 1980 AND SINCE 1990 NOBODY HAS OPERATED ON THIS ACCOUNT AGAIN. AFTER GOING THROUGH SOME OLD FILES IN THE RECORDS I DISCOVERED THAT IF I DO NOT REMITT THIS MONEY OUT URGENTLY IT WILL BE FORFEITED FOR NOTHING. THE OWNER OF THIS ACCOUNT IS MR. SMITH B. ANDREAS, A FOREIGNER, AND THE MANAGER OF PETRO - TECHNICAL SUPPORT SERVICES, A CHEMICAL ENGINEER BY PROFESSION AND HE DIED SINCE 1990. NO OTHER PERSON KNOWS ABOUT THIS ACCOUNT OR ANY THING CONCERNING IT, THE ACCOUNT HAS NO OTHER BENEFICIARY AND MY INVESTIGATION PROVED TO ME AS WELL THAT THIS COMPANY DOES NOT KNOW ANYTHING ABOUT THIS ACCOUNT AND THE AMOUNT INVOLVED IS (USD 26 MILLION DOLLARS). I WANT TO TRANSFER THIS MONEY INTO A SAFE FOREIGNERS ACCOUNT ABROAD BUT I DON'T KNOW ANY FOREIGNER, I AM ONLY CONTACTING YOU AS A FOREIGNER BECAUSE THIS MONEY CAN NOT BE APPROVED TO A LOCAL BANK HERE, BUT CAN ONLY BE APPROVED TO ANY FOREIGN ACCOUNT BECAUSE THE MONEY IS IN US DOLLARS AND THE FORMER OWNER OF THE ACCOUNT IS MR. SMITH B. ANDREAS IS A FOREIGNER TOO. I KNOW THAT THIS MASSAGE WILL COME TO YOU AS A SURPRISE AS WE DON'T KNOW OUR SELVES BEFORE, BUT BE SURE THAT IT IS REAL AND A GENUINE BUSINESS. I ONLY GOT YOUR CONTACT ADDRESS FROM THE COMPUTER, WITH BELIEVE IN GOD THAT YOU WILL NEVER LET ME DOWN IN THIS BUSINESS YOU ARE THE ONLY PERSON THAT I HAVE CONTACTED IN THIS BUSINESS, SO PLEASE REPLY URGENTLY SO THAT I WILL INFORM YOU THE NEXT STEP TO TAKE URGENTLY. I WANT US TO SEE FACE TO FACE OR SIGN A BINDING AGREEMENT TO BIND US TOGETHER SO THAT YOU CAN RECIEVE THIS MONEY INTO A FORIEGN ACCOUNT OR ANY ACCOUNT OF YOUR CHOICE WHERE THE FUND WILL BE REMMITTED.AND I WILL FLY TO YOUR COUNTRY FOR WITHDRAWAL AND SHARING AND OTHER INVESTMENTS. I AM CONTACTING YOU BECAUSE OF THE NEED TO INVOLVE A FOREIGNER WITH FOREIGN ACCOUNT AND FOREIGN BENEFICIARY. I NEED YOUR CO-OPERATION TO MAKE THIS WORK FINE. BECAUSE THE MANAGEMENT IS READY TO APPROVE THIS PAYMENT TO ANY FOREIGNER WHO HAS CORRECT INFORMATION OF THIS ACCOUNT, WHICH I WILL GIVE TO YOU LATER IMMEDIATELY, IF YOU ARE ABLE AND WITH CAPABILITY TO HANDLE SUCH AMOUNT IN STRICT CONFIDENCE AND TRUST ACCORDING TO MY INSTRUCTIONS AND ADVICE FOR OUR MUTUAL BENEFIT BECAUSE THIS OPPORTUNITY WILL NEVER COME AGAIN IN MY LIFE. A NEED TRUTHFUL PERSON IN THIS BUSINESS BECAUSE I DON'T WANT TO MAKE MISTAKE I NEED YOUR STRONG ASSURANCE AND TRUST. WITH MY POSITION NOW IN THE OFFICE I CAN TRANSFER THIS MONEY TO ANY FOREIGNERS RELIABLE ACCOUNT WHICH YOU CAN PROVIDE WITH ASSURANCE THAT THIS MONEY WILL BE INTACT PENDING MY PHYSICAL ARRIVAL IN YOUR COUNTRY FOR SHARING. I WILL DESTROY ALL DOCUMENTS OF TRANSACTION IMMEDIATELY WE RECIEVE THIS MONEY LEAVING NO TRACE TO ANY PLACE. YOU CAN ALSO COME TO DISCUSS WITH ME FACE TO FACE AFTER WHICH I WILL MAKE THIS REMITTANCE IN YOUR PRESENCE AND TWO OF US WILL FLY TO YOUR COUNTRY AT LEAST TWO DAYS AHEAD OF THE MONEY GOING INTO YOUR ACCOUNT. I WILL APPLY FOR ANNUAL LEAVE TO GET VISA IMMEDIATELY I HEAR FROM YOU THAT YOU ARE READY TO ACT AND RECEIVE THIS FUND IN YOUR ACCOUNT. I WILL USE MY POSITION AND INFLUENCE TO EFFECT LEGAL APPROVALS AND ONWARD TRANSFER OF THIS MONEY TO YOUR ACCOUNT WITH APPROPRIATE CLEARANCE FORMS OF THE MINISTRIES AND FOREIGN EXCHANGE DEPARTMENTS. AT THE CONCLUSION OF THIS BUSINESS, YOU WILL BE GIVEN 20% OF THE TOTAL AMOUNT, 75% WILL BE FOR ME, WHILE 5% WILL BE FOR EXPENSES BOTH PARTIES MIGHT HAVE INCURED DURING THE PROCESS OF TRANSFERING. I LOOK FORWARD TO YOUR EARLIEST REPLY BY EMAIL. YOURS TRULY, ALISON. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Wed Sep 12 16:56:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVB-0004Zp-01 for ; Thu, 13 Sep 2001 03:41:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:13 +0200 (CEST) Received: (qmail 12416 invoked by uid 0); 12 Sep 2001 15:12:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 12 Sep 2001 15:12:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CFCNd13589 for ; Wed, 12 Sep 2001 11:12:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 15:12:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CFBx913338 for f-cpu-list; Wed, 12 Sep 2001 11:11:59 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CFBwC13335 for ; Wed, 12 Sep 2001 11:11:58 -0400 Received: by moria.seul.org (Postfix) id B19DE1462FE; Wed, 12 Sep 2001 11:12:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id 57F681462FD for ; Wed, 12 Sep 2001 11:12:02 -0400 (EDT) Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 15hBRJ-0000Ss-00 for ; Wed, 12 Sep 2001 16:56:33 +0200 Date: Wed, 12 Sep 2001 16:56:33 +0200 From: Paul Marques Mota To: f-cpu@seul.org Subject: Re: [f-cpu] attention Message-ID: <20010912165633.A18094@opium.april.org> References: <20010912055812.68809.qmail@web20405.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010912055812.68809.qmail@web20405.mail.yahoo.com>; from alifed2001@yahoo.com on Tue, Sep 11, 2001 at 10:58:12PM -0700 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, See http://hoaxinfo.com/nigeria.htm for more informations about this spam. -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 12 14:05:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVD-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:15 +0200 (CEST) Received: (qmail 23436 invoked by uid 0); 12 Sep 2001 16:28:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 12 Sep 2001 16:28:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CGShl15165 for ; Wed, 12 Sep 2001 12:28:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 16:28:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CGSAA14919 for f-cpu-list; Wed, 12 Sep 2001 12:28:10 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CGS8C14916 for ; Wed, 12 Sep 2001 12:28:08 -0400 Received: by moria.seul.org (Postfix) id 983BB1462FE; Wed, 12 Sep 2001 12:28:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id C0AE51462FD for ; Wed, 12 Sep 2001 12:28:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00432; Wed, 12 Sep 2001 14:05:18 +0200 Message-ID: <20010912140518.58464@thrai.stud.uni-hannover.de> Date: Wed, 12 Sep 2001 14:05:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New way of doing testbench References: <20010910013719.55402@thrai.stud.uni-hannover.de> <3B9D3F90.DC74A80A@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B9D3F90.DC74A80A@ifrance.com>; from nicO on Mon, Sep 10, 2001 at 06:32:48PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 10, 2001 at 06:32:48PM -0400, nicO wrote: > http://www.testbuilder.net/resources.thtml > > Maybe a good way to write a testbench for vhdl. I don't if it could work > with free HDL or Simili. > > It's a way to interface HDL and C++. It look very nice and it's free ! Why don't they let me download the code, then? The `download' button seems to be well-hidden -- does it exist at all? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 13 05:06:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVG-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:18 +0200 (CEST) Received: (qmail 8785 invoked by uid 0); 12 Sep 2001 21:20:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 12 Sep 2001 21:20:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CLKHA21441 for ; Wed, 12 Sep 2001 17:20:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 21:18:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CLIrX21143 for f-cpu-list; Wed, 12 Sep 2001 17:18:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CLIgC21140 for ; Wed, 12 Sep 2001 17:18:46 -0400 Received: by moria.seul.org (Postfix) id CC6DB1462EF; Wed, 12 Sep 2001 17:18:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas24-83.vlt.club-internet.fr [195.36.223.83]) by moria.seul.org (Postfix) with ESMTP id 192A11462E9 for ; Wed, 12 Sep 2001 17:18:43 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 7004D171D for ; Wed, 12 Sep 2001 23:06:11 -0400 (EDT) Message-ID: <3BA022A3.B361E051@ifrance.com> Date: Wed, 12 Sep 2001 23:06:11 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: > [...] > > And it will be more simple to add it into a SoC. Whishbone is great but > > we need read-modify-write cycle, and i don't know if Wishbone do it. > > It does. At least the documentation says so. > So that's good and split transaction ? > [...] > > You think only "pc" and it's socket. In which other product could you > > change the main processor ? "Pc" is an old fation to do a system. Think > > of embedded market (cars(30%-50% of the electronics industrie market in > > the futur !), train, plane,...), think of PDA, handel PC. That's the > > future, not PC or workstation ! Pc industrie are declined and devoted to > > wintel god and it won't change. X86 word make a course of Mips, ARM word > > the course of Mips/Watt, i propose the courses of the Mips/euros. > > No, I don't think "PC". But I think "workstation" and "server" -- they > all have CPU sockets, usually, whether they use Intel CPUs or SPARCs, > MIPS or PA-RISC, Alpha or PPC... > I don't think that we play in the same playground. That's a minor application for f-cpu. > > > The only solution I can see is a 2-chip approach: make an external > > > WISHBONE interface and put the proprietary stuff into another chip. > > > That's no longer an SoC, of course. > > > > > > > And you lose all the benefit of it ! All future product must be very > > compact, with reduiced power consumption and cheap. So SoC are > > obligatory to reach that goal. For me, f-cpu should be include in > > proprietary chip. You want to change the physical chip. So nowdays, > > physical chip are remplaced by IP. So you could replace IP by another > > one (or the same but with different parameters, or an other cpu if you > > use C code). When you create a SoC it's the same that build a PCB in > > 80's but now it's on silicon die instead of epoxy. > > Not really. All the PCBs I've seen used 100% proprietary components. > Arrrghhhhh! [sorry:)] Never forget that GPL world only apply on thing that could be duplicated at no cost, only (soft, and IP)! Fcpu apply only for IP not the chip, never ! To produice it we need partners to do it, and they need to earn money (yes, a little bit ! bad world ! ;D). > > A SoC is so specialised ! So there isn't any interrest to change the > > chip. It's a complete system so you could always create a compatible > > chip with a complete different SoC. Imagine a mp3 producer, there is so > > many manner to make it. You could do it with dedicated HW or with a DSP > > or a powerfull RISC cpu, or with many little cpu. > > > > I hope a convince you. > > I absolutely don't mind if somebody builds an F-CPU based SoC. > As long as users can get the complete source code under GPL ;) > I think that you forget that produice a complet chip cost a lot of money, a lot ! Do you think that a compagny will take 6 month to produice a chip that a direct concurrent could only use 2 month, because of the open source ? GPL was written for software in mind. They want to spread this kind of software, and make some attractive clauses (for example, we can not stole your code). I want that fcpu will be wide spread. Patches aren't free in hardware, it's called a metal fixe and cost some millions dollars... that's not the same risk for compagny than with linux. So we need to give something to the compagny. IBM help linux so it can sell machine so what about hardware. nicO > > Ps: This night, i think about the american people... > > I painted the background of my homepage dark this afternoon... > I hope I won't have to paint it pitch black. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 00:52:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVJ-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:21 +0200 (CEST) Received: (qmail 11005 invoked by uid 0); 12 Sep 2001 22:53:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Sep 2001 22:53:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CMrVN23589 for ; Wed, 12 Sep 2001 18:53:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 22:52:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CMqwS23093 for f-cpu-list; Wed, 12 Sep 2001 18:52:58 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CMquC23078 for ; Wed, 12 Sep 2001 18:52:56 -0400 Received: by moria.seul.org (Postfix) id 76FCF1462EF; Wed, 12 Sep 2001 18:53:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.seul.org (Postfix) with ESMTP id E5E1E1462E9 for ; Wed, 12 Sep 2001 18:53:00 -0400 (EDT) Received: from f-cpu.org (nas2-80.aub.club-internet.fr [195.36.133.80]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA13655 for ; Thu, 13 Sep 2001 00:52:53 +0200 (MET DST) Message-ID: <3B9FE749.619BE63A@f-cpu.org> Date: Thu, 13 Sep 2001 00:52:57 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] binary streams Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, in the Eurostar, i found the reason why my random routin gave strange behaviour. This can be illutrated by the following code : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; -- USE ieee.std_logic_textio.all; LIBRARY std; USE std.textio.ALL; entity test is end test; architecture tst of test is type byte_stream is file of character ; file in_file : byte_stream open read_mode is "in"; file out_file : byte_stream open write_mode is "out"; begin -- test process variable c : character; variable i : integer := 0; variable l : line; begin while not endfile(in_file) loop read(in_file,c); write(out_file,c); i := i+1; end loop; WRITE(l,i); WRITE(l,string'(" bytes copied ")); writeline(output, l); wait; end process; end tst; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ when run with vanilla or simili, the results are different. given a text input file, simili will insert 0xD, 0xA pairs for carriage returns. Well, it's a MSDOS thing. Worse : simili "interprets" the input characters and particularly : it stops on a "EOF" character (i don't know which) while Vanilla copies texto the input to the output. This is not revelant for the text i/O but i want to handle "binary" files, that is : whatever the data is. the different behaviours of the tools almost gave me headaches. anyone can help ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 00:52:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVJ-0004Zp-01 for ; Thu, 13 Sep 2001 03:41:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:21 +0200 (CEST) Received: (qmail 9213 invoked by uid 0); 12 Sep 2001 22:53:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 12 Sep 2001 22:53:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CMrVA23592 for ; Wed, 12 Sep 2001 18:53:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 22:52:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CMqt823062 for f-cpu-list; Wed, 12 Sep 2001 18:52:55 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CMqsC23059 for ; Wed, 12 Sep 2001 18:52:54 -0400 Received: by moria.seul.org (Postfix) id E37FA1462EF; Wed, 12 Sep 2001 18:52:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.seul.org (Postfix) with ESMTP id 4D71A1462E9 for ; Wed, 12 Sep 2001 18:52:58 -0400 (EDT) Received: from f-cpu.org (nas2-80.aub.club-internet.fr [195.36.133.80]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA18185 for ; Thu, 13 Sep 2001 00:52:51 +0200 (MET DST) Message-ID: <3B9FE746.2EFB417F@f-cpu.org> Date: Thu, 13 Sep 2001 00:52:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] new snapshot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, temporary, ugly and huge snapshot for the hardcore developers out there (others would become mad) : http://f-cpu.seul.org/new/snapshot_yg_13_9_2001.tgz it is not "clean" because some parts are left "as is" in the middle of some brainstorming. However i hope that Michael's eagle eyes will find useful things. Btw, i think that Michael mentioned a correction to the clock's NCO but i have seen no code or URL yet. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 13 01:53:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVL-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:23 +0200 (CEST) Received: (qmail 29343 invoked by uid 0); 12 Sep 2001 23:55:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 12 Sep 2001 23:55:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CNtSi25129 for ; Wed, 12 Sep 2001 19:55:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 23:54:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CNst924652 for f-cpu-list; Wed, 12 Sep 2001 19:54:55 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CNsrC24649 for ; Wed, 12 Sep 2001 19:54:53 -0400 Received: by moria.seul.org (Postfix) id A6C801462EF; Wed, 12 Sep 2001 19:54:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id 7A3E51462E9 for ; Wed, 12 Sep 2001 19:54:56 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01567; Thu, 13 Sep 2001 01:53:59 +0200 Message-ID: <20010913015358.58868@thrai.stud.uni-hannover.de> Date: Thu, 13 Sep 2001 01:53:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] binary streams References: <3B9FE749.619BE63A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3B9FE749.619BE63A@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 12:52:57AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi #2, On Thu, Sep 13, 2001 at 12:52:57AM +0200, Yann Guidon wrote: [...] > given a text input file, simili will insert 0xD, 0xA pairs > for carriage returns. Well, it's a MSDOS thing. > Worse : simili "interprets" the input characters and particularly : > it stops on a "EOF" character (i don't know which) while > Vanilla copies texto the input to the output. EOF used to be ^Z (decimal 26); I guess it's still that way. > This is not revelant for the text i/O but i want to > handle "binary" files, that is : whatever the data is. > the different behaviours of the tools almost gave me headaches. > > anyone can help ? That's easy to handle in C -- fopen(file, "rb") should do the trick -- but I don't know what to do in VHDL. Perhaps you can do something like type octet is 0 to 255; type octet_stream is file of octet; If it still stops at a ^Z, I would consider that a bug in Simili. But you'll probably have to write a completely new set of I/O routines for the `octet' type. On the other hand, binary files are evil anyway because they're not portable (imagine you had to transfer them to a big-endian box, like SPARC). Better use a `compact' ASCII representation (e.g. hexadecimal numbers). It will have a 2:1 overhead, but it's portable, and also readable/editable by humans. Another portable and even more compact (but unreadable) encoding is base64 (used by MIME, for example). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 13 01:36:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVM-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:24 +0200 (CEST) Received: (qmail 11528 invoked by uid 0); 12 Sep 2001 23:55:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 12 Sep 2001 23:55:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8CNtWN25188 for ; Wed, 12 Sep 2001 19:55:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 12 Sep 2001 23:55:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8CNt0h24714 for f-cpu-list; Wed, 12 Sep 2001 19:55:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8CNswC24697 for ; Wed, 12 Sep 2001 19:54:58 -0400 Received: by moria.seul.org (Postfix) id 6F9381462EF; Wed, 12 Sep 2001 19:55:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id 6D9611462E9 for ; Wed, 12 Sep 2001 19:54:59 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01517; Thu, 13 Sep 2001 01:36:09 +0200 Message-ID: <20010913013609.62424@thrai.stud.uni-hannover.de> Date: Thu, 13 Sep 2001 01:36:09 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new snapshot References: <3B9FE746.2EFB417F@f-cpu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=7JfCtLOvnd9MIVvH X-Mailer: Mutt 0.84e In-Reply-To: <3B9FE746.2EFB417F@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 12:52:54AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Hi *, > Btw, i think that Michael mentioned a correction > to the clock's NCO but i have seen no code or URL yet. No, that was a misunderstanding. I wrote a small NCO entity a while ago but I wasn't sure whether I sent it to the list. Obviously, I didn't. Here it comes... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nco.vhdl" -- nco.vhdl -- Numerically Controlled Oscillator -- Copyright (C) 2001 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- $Id$ library IEEE; use IEEE.std_logic_1164.all; use work.Generic_Adder.all; entity NCO is generic ( WIDTH : natural := 4 ); port ( -- clock frequency value Freq : in std_ulogic_vector(WIDTH-1 downto 0); -- load new clock frequency value Load : in std_ulogic; -- input clock Clk_In : in std_ulogic; -- stop NCO Hold : in std_ulogic; -- reset NCO Rst : in std_ulogic; -- -- output clock Clk_Out : out std_ulogic ); end NCO; architecture Behave_1 of NCO is begin process (Freq, Load, Clk_in, Hold, Rst) variable counter, delta, y, c : std_ulogic_vector(WIDTH-1 downto 0); variable g, p, o : std_ulogic; begin if to_X01(Rst) = '1' then counter := (others => '0'); delta := (others => '0'); -- soft start o := '0'; elsif rising_edge(Clk_in) then if to_X01(Hold) /= '1' then CIAdd(counter, delta, y, c, g, p); counter := y xor c; if to_X01(g or p) = '1' then if to_X01(Load) = '1' then delta := Freq; end if; o := not o; end if; end if; end if; Clk_Out <= o; end process; end Behave_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --7JfCtLOvnd9MIVvH-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 03:18:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVO-0004Zp-00 for ; Thu, 13 Sep 2001 03:41:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:26 +0200 (CEST) Received: (qmail 25160 invoked by uid 0); 13 Sep 2001 01:19:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 13 Sep 2001 01:19:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D1J5F26867 for ; Wed, 12 Sep 2001 21:19:05 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 01:18:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D1IUO26408 for f-cpu-list; Wed, 12 Sep 2001 21:18:30 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D1ISC26400 for ; Wed, 12 Sep 2001 21:18:29 -0400 Received: by moria.seul.org (Postfix) id BA5381462E9; Wed, 12 Sep 2001 21:18:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by moria.seul.org (Postfix) with ESMTP id 2C5341462EF for ; Wed, 12 Sep 2001 21:18:33 -0400 (EDT) Received: from f-cpu.org (nas2-117.aub.club-internet.fr [195.36.133.117]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA28270 for ; Thu, 13 Sep 2001 03:18:20 +0200 (MET DST) Message-ID: <3BA00961.63249D21@f-cpu.org> Date: Thu, 13 Sep 2001 03:18:25 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Tue, Sep 11, 2001 at 02:44:45PM +0200, Juergen Goeritz wrote: > [...] > > How about thinking of IPs as programs? When I run a program > > on an OS, the GPL license does not affect other programs that > > run on the same OS. When one runs the F-CPU IP on a chip how > > can it then affect the other IPs on the chip? Just imagine some > > kind of a loadable cpu core if you think this is to far ahead. > > If you now think of the other IPs being the 'operating system' > > to run the F-CPU IP you are on my view. > [...] > > If you provide ways to install, remove, modify and replace any "program" > independently without destroying the rest, I might agree with you, > with one exception: all IPs should be considered "programs". > > I don't like this approach much, but I guess it's reasonable to allow > this kind of "use", as long as users have the option to take advantage > of all the rights they've been granted by the F-CPU license, without > any restrictions. > There is still the problem of the 'interface' from my POV. Programs have interfaces : you can write a proprietary SW on Linux, but even though you have the source of the libraries, you can't change them at will (even under GPL) because other programs wouldn't work, or not work as well as with the proprietary thing. The summit is reached with the new "desktop managers" (KDE, GNOME etc) which are extremely complex, and can't cooperate EVEN THOUGH THEY ARE FREE ! There is a small danger with the wishbone stuff. It is public domain, not an IEEE or ANSI standard (AFAIK). I don't believe that the performance is extraordinary. It's ok if you want to communicate with mid-speed I/O or do some IC2IC intercom, but F-CPU needs some strong doses of EPO+amphetamines, if you see what i mean. Otherwise, stick with LEON : having a lot of CPU power is not interesting if you're 'memory-bound' whatever you do. Cache miss rates and refill speed kills all CPU. So at least with LEON you are not too much memory bound. My current view for a "decent" F-CPU chip is : - SDRAM (DDR/whatever) direct interface with the core - onchip L1 cache (low latency) - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM, so we can do very wide SIMD computations - some kind of relatively fast interface to the outside, possibly with rather wide words (64-bit or 128-bit at a time) if it is on-chip. Integrate a raster-scan controller and a video codec and you have a free graphic chipset :-) (just for the fun). > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 03:18:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hLVO-0004Zp-01 for ; Thu, 13 Sep 2001 03:41:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 03:41:26 +0200 (CEST) Received: (qmail 31559 invoked by uid 0); 13 Sep 2001 01:19:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx03) with SMTP; 13 Sep 2001 01:19:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D1J9a26911 for ; Wed, 12 Sep 2001 21:19:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 01:18:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D1IUV26403 for f-cpu-list; Wed, 12 Sep 2001 21:18:30 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D1ISC26396 for ; Wed, 12 Sep 2001 21:18:28 -0400 Received: by moria.seul.org (Postfix) id 2C9841462FD; Wed, 12 Sep 2001 21:18:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by moria.seul.org (Postfix) with ESMTP id B3B511462E9 for ; Wed, 12 Sep 2001 21:18:32 -0400 (EDT) Received: from f-cpu.org (nas2-117.aub.club-internet.fr [195.36.133.117]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA03649 for ; Thu, 13 Sep 2001 03:18:15 +0200 (MET DST) Message-ID: <3BA0095C.3EE0ACA3@f-cpu.org> Date: Thu, 13 Sep 2001 03:18:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > Michael Riepe a écrit : > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: > > [...] > > > A SoC is so specialised ! So there isn't any interrest to change the > > > chip. It's a complete system so you could always create a compatible > > > chip with a complete different SoC. Imagine a mp3 producer, there is so > > > many manner to make it. You could do it with dedicated HW or with a DSP > > > or a powerfull RISC cpu, or with many little cpu. > > > > > > I hope a convince you. > > > > I absolutely don't mind if somebody builds an F-CPU based SoC. > > As long as users can get the complete source code under GPL ;) > > > > I think that you forget that produice a complet chip cost a lot of > money, a lot ! Do you think that a compagny will take 6 month to > produice a chip that a direct concurrent could only use 2 month, because > of the open source ? you fall in the same trap constantly. F-CPU's goal is not to let people do "benefits" on it. It is here to "help" the industry as a whole and harmonize some common stuff. Where people would use SUN/SPARC workstations, they could find F-CPU/Linux boxes for 1/4 the price and a lot of third parties. concerning the difficulty, here is the first opening quote from the "supermen" book (about supercomputers, si tu veux l'emprunter yaka demander) " If a man can write a better book, preach a better sermon, or make a better mousetrap than his neighbor, though he build his house in the woods, the world will make a beaten path to his door. Ralph Waldo Emerson, 1871 " comprenne qui voudra. On top of that, this quote has a special meaning because Seymour Cray built lots of CRAY fabs in the isolated woods. Thanks to him, a lot of people in the neighbourhood have seen helicopters and journalists for the first time in their life :-) > GPL was written for software in mind. They want to > spread this kind of software, and make some attractive clauses (for > example, we can not stole your code). i don't like the "attractive" thing. Of course, the following text probably doesn't apply to your last comment but i write anyway. Of course, i would like F-CPU to be used in big and small designs, in the commercial or industrial world. However there is a limit to attraction. i don't know if you understand what i will say, but i encourage you to visit DATE (with me or alone) and preach for the F-CPU. We are designers, not whores. Most people with whom you will speak have no sense of what freedom means. the only freedom they know is their "holy right to make profit" (sometimes they think it can short-circuit other fundamental or constitutional freedoms). The only thing that they want is money, or profit. other words are market shares, penetration (ouch !), growth... Nobody will speak about advancement of the technology (except in the introduction of very generalistic press releases), about encouraging competition or our freedom to design and do our engineer's work. Some university teachers are still idealistic enough to believe in that, but that tends to disapear quickly as they get funded by the industry. So here, i will draw (or more precisely, redraw and insist upon it) a "line" : You have the right to use the F-CPU sources for any purposes as long as it is "out of the tarball" (unmodified). In fact, most IPs are like that. I remember of an example (unsure but it's a rough figure) for the ARM (?) core IP : ie you get the "compiled IP" for $10K and if you want to modify it, you have to pay $35K (?). If my memory serves me well, i heard these numbers at DATE in Munich). "please contact your local reseller for up-to-date pricing". Now, you get a kick-ass F-CPU with source code "for free". you get the right to integrate it in your preferred washing machine as long as you don't modify the provided sources or integrate stuff into the core. The ARM (? was it ARM btw ?) guy told me that it is done this way most of the time : few customers really want to modify the core's sources. - first reason is that the compiled core is already compiled : the compiler licence would cost more - it is already optimized - it is compatible with anything. So that's fine for me. I don't know if Michael will agree to my POV but i am open to any senseful and argumented discussion. The next step is : you want to modify the core. You don't need to pay more because it is already "free" and it can't be "more free". If i take the ARM guy's saying for true, this is not going to happen a lot. The condition for modifying the code is to redistribute it (in F-CPUland). Of course there is still the problem of where the "limit" of the core is, but it's another discussion. What we "give" is the possibility to "evaluate" the core, within the limits fixed (and slowly loosened) by the m4 files' parameters. So if the company wants to implement, say, a communication controller (SCSI RAID or IP router for example) and wants to avoid the cost of an existing IP, a small team of engineers can d/l the F-CPU tarball, the LEON's, anything else, and make testbenches, comparisons, benchmarks... If it chooses F-CPU, fine. If it needs some changes, then it must release the new files. It is simple. Forcing to release the files is seen, by you and Juergen at least IIRC, as a problem. It is also forcing companies to open their eyes : releasing their specs and sources increases indirectly the customer's self-help and augments the feedback (if the company is open enough). It is a garantee of stability of the product family. And remember the ALPHA fiasco : Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied when purposedly saying that ALPHA would be continued during decades) have now lost money and time porting their applications. Now, imagine ALPHA was open-sourced : the companies would be able to continue the work, probably through a joint-venture that spreads the costs. I wish the microelectronics world was not such a dirty swamp ... Concerning nicO's remarks about integrating F-CPUs everywhere : fine, but woudln't it be an overkill ??? there is no "short" version of F-CPU (32 bit support is not under way and it is discouraged). I know no 'portable' application that needs fast 32-b arithmetics. When it is really required, a 16-b or 32-b µC does multi-precision operations. 32-bit SIMD would be used for real-time imaging and sound processing applications (ie digital handicams) but the devices that do that are often made in Japan with highly proprietary chips/ASICs. F-CPU would not help much. However, it is useful for small quantities (around 1K-100K) runs concerning high-speed control, such as the SCSI or IP router example. Small companies would adopt F-CPU easily because the price tag and the independence from the toolset are "attracting" (to reuse your word). I think that it is where we can seek implementors. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 03:38:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hO8w-0007me-00 for ; Thu, 13 Sep 2001 06:30:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 06:30:26 +0200 (CEST) Received: (qmail 29117 invoked by uid 0); 13 Sep 2001 01:39:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 13 Sep 2001 01:39:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D1dKQ27465 for ; Wed, 12 Sep 2001 21:39:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 01:38:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D1cww27215 for f-cpu-list; Wed, 12 Sep 2001 21:38:58 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D1cuC27210 for ; Wed, 12 Sep 2001 21:38:56 -0400 Received: by moria.seul.org (Postfix) id 7AB8A1462EF; Wed, 12 Sep 2001 21:39:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by moria.seul.org (Postfix) with ESMTP id EC1D31462E9 for ; Wed, 12 Sep 2001 21:39:00 -0400 (EDT) Received: from f-cpu.org (nas2-117.aub.club-internet.fr [195.36.133.117]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA17302; Thu, 13 Sep 2001 03:38:49 +0200 (MET DST) Message-ID: <3BA00E2E.B47A1E40@f-cpu.org> Date: Thu, 13 Sep 2001 03:38:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Cc: "Haneef D. Mohammed" Subject: Re: [f-cpu] binary streams References: <3B9FE749.619BE63A@f-cpu.org> <20010913015358.58868@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi #3, Michael Riepe wrote: > Hi #2, > > On Thu, Sep 13, 2001 at 12:52:57AM +0200, Yann Guidon wrote: > [...] > > given a text input file, simili will insert 0xD, 0xA pairs > > for carriage returns. Well, it's a MSDOS thing. > > Worse : simili "interprets" the input characters and particularly : > > it stops on a "EOF" character (i don't know which) while > > Vanilla copies texto the input to the output. > EOF used to be ^Z (decimal 26); I guess it's still that way. probably :-) > > This is not revelant for the text i/O but i want to > > handle "binary" files, that is : whatever the data is. > > the different behaviours of the tools almost gave me headaches. > > > > anyone can help ? > > That's easy to handle in C -- fopen(file, "rb") should do the trick -- but that's not the problem ;-) > but I don't know what to do in VHDL. Perhaps you can do something like > type octet is 0 to 255; > type octet_stream is file of octet; i think i tried this already, however i presume that this "subset" for the "integer" type keeps the 4-byte encoding (the range is only restricted) so if i read a "byte" i will increment the file counter by four. i'll try anyway because i better prove it, but it's a gut feeling. > If it still stops at a ^Z, I would consider that a bug in Simili. simili and vanilla definitely differ ! > But you'll probably have to write a completely new set of I/O routines > for the `octet' type. not necessarily, but if it's necessary, i'll do it. > On the other hand, binary files are evil anyway because they're not > portable (imagine you had to transfer them to a big-endian box, like > SPARC). in this case (random numbers coming from /dev/random or .tgz files) it is irrevelant. > Better use a `compact' ASCII representation (e.g. hexadecimal > numbers). It will have a 2:1 overhead, but it's portable, and also > readable/editable by humans. Another portable and even more compact > (but unreadable) encoding is base64 (used by MIME, for example). but it adds another C layer, which has to be compiled etc... base-16 is ok, easily VHDL-writeable, but not handy, because pipes etc are not well portable across different platforms. see what i mean ? i simply hope there was a byte file support. i found nothing in Graham's books. good night, and thanks for the NCO file. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 03:49:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hO8x-0007me-00 for ; Thu, 13 Sep 2001 06:30:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Sep 2001 06:30:27 +0200 (CEST) Received: (qmail 7729 invoked by uid 0); 13 Sep 2001 01:50:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 13 Sep 2001 01:50:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D1oC427843 for ; Wed, 12 Sep 2001 21:50:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 01:49:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D1nrq27593 for f-cpu-list; Wed, 12 Sep 2001 21:49:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D1nqC27588 for ; Wed, 12 Sep 2001 21:49:52 -0400 Received: by moria.seul.org (Postfix) id A63E21462EF; Wed, 12 Sep 2001 21:49:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by moria.seul.org (Postfix) with ESMTP id 2A7B01462E9 for ; Wed, 12 Sep 2001 21:49:57 -0400 (EDT) Received: from f-cpu.org (nas2-117.aub.club-internet.fr [195.36.133.117]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA27577 for ; Thu, 13 Sep 2001 03:49:49 +0200 (MET DST) Message-ID: <3BA010C2.6F0D7C4D@f-cpu.org> Date: Thu, 13 Sep 2001 03:49:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] oops ! Content-Type: multipart/mixed; boundary="------------DE6F33226516F64FB1ADE7AF" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------DE6F33226516F64FB1ADE7AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit it seems that there was a transmission error with the included file (cat.vhdl). Here it is, in attached form. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------DE6F33226516F64FB1ADE7AF Content-Type: text/plain; charset=us-ascii; name="cat.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cat.vhdl" LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; LIBRARY std; USE std.textio.ALL; entity test is end test; architecture tst of test is type byte_stream is file of character ; file in_file : byte_stream open read_mode is "in"; file out_file : byte_stream open write_mode is "out"; begin -- test process variable c : character; variable i : integer := 0; variable l : line; begin while not endfile(in_file) loop read(in_file,c); write(out_file,c); i := i+1; end loop; WRITE(l,i); WRITE(l,string'(" bytes copied ")); writeline(output, l); wait; end process; end tst; --------------DE6F33226516F64FB1ADE7AF-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Thu Sep 13 07:46:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhho-0000MN-01 for ; Fri, 14 Sep 2001 03:23:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:44 +0200 (CEST) Received: (qmail 20398 invoked by uid 0); 13 Sep 2001 05:48:23 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Sep 2001 05:48:23 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D5mLC30955 for ; Thu, 13 Sep 2001 01:48:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 05:46:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D5kfX30702 for f-cpu-list; Thu, 13 Sep 2001 01:46:41 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D5kbC30699 for ; Thu, 13 Sep 2001 01:46:37 -0400 Received: by moria.seul.org (Postfix) id 51F261462FB; Thu, 13 Sep 2001 01:46:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id AEF671462E9 for ; Thu, 13 Sep 2001 01:46:41 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id IAA07082 for ; Thu, 13 Sep 2001 08:46:34 +0300 (EET DST) Date: Thu, 13 Sep 2001 08:46:33 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: fm Subject: Re: [f-cpu] binary streams In-Reply-To: <3B9FE749.619BE63A@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 13 Sep 2001, Yann Guidon wrote: > in the Eurostar, i found the reason why my random > routin gave strange behaviour. This can be illutrated > by the following code : .... > variable c : character; I think this is the problem. Define this as bit_vector or std_logic_vector. After that binary mode reading should work. Character is defined differently. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Thu Sep 13 08:12:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhhp-0000MN-01 for ; Fri, 14 Sep 2001 03:23:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:46 +0200 (CEST) Received: (qmail 32066 invoked by uid 0); 13 Sep 2001 06:14:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 13 Sep 2001 06:14:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8D6EBo31787 for ; Thu, 13 Sep 2001 02:14:11 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 06:12:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8D6Cba31540 for f-cpu-list; Thu, 13 Sep 2001 02:12:37 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8D6CZC31537 for ; Thu, 13 Sep 2001 02:12:36 -0400 Received: by moria.seul.org (Postfix) id DAE781462FB; Thu, 13 Sep 2001 02:12:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 0F4BD1462E9 for ; Thu, 13 Sep 2001 02:12:40 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA09251 for ; Thu, 13 Sep 2001 09:12:34 +0300 (EET DST) Date: Thu, 13 Sep 2001 09:12:31 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC In-Reply-To: <3BA0095C.3EE0ACA3@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 13 Sep 2001, Yann Guidon wrote: > you fall in the same trap constantly. F-CPU's goal is not to let people > do "benefits" on it. It is here to "help" the industry as a whole and > harmonize some common stuff. Where people would use SUN/SPARC workstations, > they could find F-CPU/Linux boxes for 1/4 the price and a lot of third > parties. Why would the F-CPU box be so much cheaper. CPU is quite small part of the total cost of a computer. Already IA32 machines are dirt cheap, but not as reliable as workstations. The realiability is what costs with those workstations. IA64/Hammer etc. will take that place in the future when 64-bits are needed. > So here, i will draw (or more precisely, redraw and insist upon it) > a "line" : You have the right to use the F-CPU sources for any purposes > as long as it is "out of the tarball" (unmodified). In fact, most > IPs are like that. I remember of an example (unsure but it's a rough > figure) for the ARM (?) core IP : ie you get the "compiled IP" for $10K > and if you want to modify it, you have to pay $35K (?). If my memory > serves me well, i heard these numbers at DATE in Munich). > "please contact your local reseller for up-to-date pricing". Quite big part of all IP can be bought as hard of soft macro and the soft one costs much more. Usually the reason to buy RTL code is to ensure that if the IP company is bought out or goes out of business there is something usable for process changes etc. It's quite difficult to migrate optimized netlist to a new process. > The next step is : you want to modify the core. You don't need to pay more > because it is already "free" and it can't be "more free". If i take > the ARM guy's saying for true, this is not going to happen a lot. > The condition for modifying the code is to redistribute it (in F-CPUland). > Of course there is still the problem of where the "limit" of the core is, > but it's another discussion. I think the problem is just what you described. What if I add IP forwarding accelerator directly to the CPU as a command to make it network processor. Where is the limit between FCPU and custom logic. Is it the bus interface to the search engine or is GPL forcing actually release of the whole search engine. That search engine on the other hand can contain very sensitive algorithms. What if that search engine is connected to other logic in the chip, does that have to be released also? > What we "give" is the possibility to > "evaluate" the core, within the limits fixed (and slowly loosened) > by the m4 files' parameters. So if the company wants to implement, > say, a communication controller (SCSI RAID or IP router for example) > and wants to avoid the cost of an existing IP, a small team of > engineers can d/l the F-CPU tarball, the LEON's, anything else, > and make testbenches, comparisons, benchmarks... > If it chooses F-CPU, fine. If it needs some changes, > then it must release the new files. It is simple. One problem is that the cost of CPU IP is unnoticable in ASIC projects. The masks can cost $1M currently. Tools that are needed for the flow also can cost the same amount, and count on top of that the salaries or tens of people. $20k for example is neglible sum compared to those. But the real problem is what must be released after the changes. > Forcing to release the files is seen, by you and Juergen at least IIRC, > as a problem. It is also forcing companies to open their eyes : releasing > their specs and sources increases indirectly the customer's self-help > and augments the feedback (if the company is open enough). It is a garantee I think that this just forces companies to use other alternatives. ASICs are the core components of products and one of the most important competitive separators. If you release the code you are very vulenarable to competitors and you loose all the development work quite easily. For example the main reason for Junipers success in IP router area is their ASICs, if Cisco could copy them we would have still only Cisco and no competitors. > Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied > when purposedly saying that ALPHA would be continued during decades) have > now lost money and time porting their applications. Now, imagine ALPHA > was open-sourced : the companies would be able to continue the work, > probably through a joint-venture that spreads the costs. Few companies have the resources to develop further on CPUs. Old ALPHA cores will be manufactured for a long time and can be used. If the development of top of the class CPU would be so easy, companies would not be dropping out of that business. But it is extremely expensive to develop top of the line processors. > I wish the microelectronics world was not such a dirty swamp ... It just is because the structure is so different from SW world. It just takes almost month to make masks currently and that costs. And there is no way to fix small bugs all the time. And also the development cycle is quite long compared to SW. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 13 16:22:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi0-0000MN-00 for ; Fri, 14 Sep 2001 03:23:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:56 +0200 (CEST) Received: (qmail 26517 invoked by uid 0); 13 Sep 2001 16:06:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 13 Sep 2001 16:06:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DG6ox10445 for ; Thu, 13 Sep 2001 12:06:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 16:06:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DG69d10194 for f-cpu-list; Thu, 13 Sep 2001 12:06:09 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DG67C10191 for ; Thu, 13 Sep 2001 12:06:07 -0400 Received: by moria.seul.org (Postfix) id 3FDB41462FB; Thu, 13 Sep 2001 12:06:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a038.home.uni-hannover.de [130.75.232.38]) by moria.seul.org (Postfix) with ESMTP id A65331462E9 for ; Thu, 13 Sep 2001 12:06:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00884; Thu, 13 Sep 2001 16:22:21 +0200 Message-ID: <20010913162221.20357@thrai.stud.uni-hannover.de> Date: Thu, 13 Sep 2001 16:22:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA00961.63249D21@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 03:18:25AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 13, 2001 at 03:18:25AM +0200, Yann Guidon wrote: [...] > Programs have interfaces : you can write a proprietary SW > on Linux, but even though you have the source of the libraries, > you can't change them at will (even under GPL) because > other programs wouldn't work, or not work as well as with > the proprietary thing. The summit is reached with the new > "desktop managers" (KDE, GNOME etc) which are extremely complex, > and can't cooperate EVEN THOUGH THEY ARE FREE ! I love standards -- there are so many of them to choose from ;( I'm afraid that we may get an `interface explosion' when users start to populate the area around the F-CPU core with their own stuff. In order to prevent that, we should provide a fixed, well-documented `general interface' and encourage people to connect to it instead of patching the core. > There is a small danger with the wishbone stuff. It is public domain, > not an IEEE or ANSI standard (AFAIK). I don't believe that the > performance is extraordinary. It's ok if you want to communicate > with mid-speed I/O or do some IC2IC intercom, but F-CPU needs > some strong doses of EPO+amphetamines, if you see what i mean. Just because something is PD (or GPLed), it doesn't have to perform badly ;) > Otherwise, stick with LEON : having a lot of CPU power is not > interesting if you're 'memory-bound' whatever you do. Cache miss > rates and refill speed kills all CPU. So at least with LEON you > are not too much memory bound. > > My current view for a "decent" F-CPU chip is : > - SDRAM (DDR/whatever) direct interface with the core > - onchip L1 cache (low latency) > - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM, > so we can do very wide SIMD computations Only useful if we can bypass the L1 cache. Otherwise, we'll get lots of misses there. What about a bigger L1 cache instead? HP did that in the PA-8500. > - some kind of relatively fast interface to the outside, possibly > with rather wide words (64-bit or 128-bit at a time) if it is on-chip. I like the FSB of the MP-Athlon... it's a fast point-to-point link (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional control buses. It somehow reminds me of the F-BUS ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 13 14:49:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi0-0000MN-01 for ; Fri, 14 Sep 2001 03:23:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:56 +0200 (CEST) Received: (qmail 9433 invoked by uid 0); 13 Sep 2001 16:07:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 13 Sep 2001 16:07:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DG7Wk10709 for ; Thu, 13 Sep 2001 12:07:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 16:07:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DG71e10464 for f-cpu-list; Thu, 13 Sep 2001 12:07:01 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DG6xC10461 for ; Thu, 13 Sep 2001 12:06:59 -0400 Received: by moria.seul.org (Postfix) id 8FDE61462FB; Thu, 13 Sep 2001 12:07:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a038.home.uni-hannover.de [130.75.232.38]) by moria.seul.org (Postfix) with ESMTP id 29F0E1462E9 for ; Thu, 13 Sep 2001 12:07:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00665; Thu, 13 Sep 2001 14:49:45 +0200 Message-ID: <20010913144945.32134@thrai.stud.uni-hannover.de> Date: Thu, 13 Sep 2001 14:49:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] binary streams References: <3B9FE749.619BE63A@f-cpu.org> <20010913015358.58868@thrai.stud.uni-hannover.de> <3BA00E2E.B47A1E40@f-cpu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=31gzZEtNLTqOjlF2 X-Mailer: Mutt 0.84e In-Reply-To: <3BA00E2E.B47A1E40@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 03:38:54AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --31gzZEtNLTqOjlF2 Content-Type: text/plain; charset=us-ascii On Thu, Sep 13, 2001 at 03:38:54AM +0200, Yann Guidon wrote: [...] > > but I don't know what to do in VHDL. Perhaps you can do something like > > type octet is 0 to 255; > > type octet_stream is file of octet; > i think i tried this already, however i presume that this "subset" > for the "integer" type keeps the 4-byte encoding (the range is only restricted) > so if i read a "byte" i will increment the file counter by four. > i'll try anyway because i better prove it, but it's a gut feeling. There's a fundamental difference between the declarations type octet is range 0 to 255; -- i forgot the `range'... subtype other_octet is integer range 0 to 255; `other_octet' is a subtype of `integer', and must use the same (4-byte) encoding, IIRC, while `octet' is a new type that may use a single-byte representation (vanilla doesn't, unfortunately). > > If it still stops at a ^Z, I would consider that a bug in Simili. > simili and vanilla definitely differ ! As well as the underlying OSes. > > But you'll probably have to write a completely new set of I/O routines > > for the `octet' type. > not necessarily, but if it's necessary, i'll do it. Seems like there are predefined read and write procedures... > > On the other hand, binary files are evil anyway because they're not > > portable (imagine you had to transfer them to a big-endian box, like > > SPARC). > in this case (random numbers coming from /dev/random or .tgz files) > it is irrevelant. In that case, you could also try a `file of integer' or something like that, and read larger quantities. I've attached an example (works with vanilla; please try simili yourself, I can't reboot while I'm writing e-mails ;). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --31gzZEtNLTqOjlF2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="randex.vhdl" library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_textio.all; library std; use std.textio.all; entity blah is end blah; architecture blah of blah is type int_stream is file of integer; file x : int_stream open read_mode is "random"; begin process variable y : integer; variable lout : line; begin while not endfile(x) loop read(x, y); write(lout, y); writeline(output, lout); end loop; wait; end process; end blah; --31gzZEtNLTqOjlF2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Sep 13 09:55:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi2-0000MN-00 for ; Fri, 14 Sep 2001 03:23:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:58 +0200 (CEST) Received: (qmail 13624 invoked by uid 0); 13 Sep 2001 16:55:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Sep 2001 16:55:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DGtht11844 for ; Thu, 13 Sep 2001 12:55:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 16:54:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DGsrh11583 for f-cpu-list; Thu, 13 Sep 2001 12:54:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DGspC11580 for ; Thu, 13 Sep 2001 12:54:51 -0400 Received: by moria.seul.org (Postfix) id A58181462FF; Thu, 13 Sep 2001 12:54:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id BA46E1462E9 for ; Thu, 13 Sep 2001 12:54:55 -0400 (EDT) Received: from jetnet.ab.ca (dialin51.jetnet.ab.ca [207.153.6.51]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA25094 for ; Thu, 13 Sep 2001 10:54:47 -0600 (MDT) Message-ID: <3BA06666.11C7E894@jetnet.ab.ca> Date: Thu, 13 Sep 2001 01:55:18 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > I love standards -- there are so many of them to choose from ;( Don't forget paper-tape I/O formats too for bootstrapping. Here are some old computer doc's to know what puter's are really like :) http://www.spies.com/~aek/pdf/ A network interface may be the best 2nd GPL I/O device developed.The Memory controller the first GPL device. As always paper tape and punched cards optional equipment. With memory/network interfaces on the FPGA you can get a simple development board up quickly. > I'm afraid that we may get an `interface explosion' when users start to > populate the area around the F-CPU core with their own stuff. In order > to prevent that, we should provide a fixed, well-documented `general > interface' and encourage people to connect to it instead of patching > the core. I go even further - develop a clean virtual cpu with simple I/O. The OS then has fun job of mapping to the i/o but it looks to be les complex than virtualizing real hardware. Also VHDL I don't think is the best way to document the F-CPU. The F-cpu should be able to be recreated from from original documents. Testing on the real hardware is still important and test programs needed to be written for the F-CPU hardware. F-CPU simulation is important but it is the hardware that gets used. As long as we have leaders like YG ( The System designer? ) who know what direction the F-CPU will take I don't think we will have a patched and hacked system like the PC developed into. > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 19:57:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi3-0000MN-00 for ; Fri, 14 Sep 2001 03:23:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:23:59 +0200 (CEST) Received: (qmail 2990 invoked by uid 0); 13 Sep 2001 17:58:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 13 Sep 2001 17:58:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DHwD312604 for ; Thu, 13 Sep 2001 13:58:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 17:57:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DHvZR12343 for f-cpu-list; Thu, 13 Sep 2001 13:57:35 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DHvXC12340 for ; Thu, 13 Sep 2001 13:57:33 -0400 Received: by moria.seul.org (Postfix) id BCFD91462FF; Thu, 13 Sep 2001 13:57:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by moria.seul.org (Postfix) with ESMTP id 823021462E9 for ; Thu, 13 Sep 2001 13:57:33 -0400 (EDT) Received: from f-cpu.org (nas4-70.ras.club-internet.fr [195.36.203.70]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA08873; Thu, 13 Sep 2001 19:57:21 +0200 (MET DST) Message-ID: <3BA0F36E.18808BE2@f-cpu.org> Date: Thu, 13 Sep 2001 19:57:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Cc: "Haneef D. Mohammed" Subject: [f-cpu] vanilla vs simili Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, yesterday, before i fell asleep, i did a little modification to the cat.vhdl file, following Michael's suggestion : i defined a subtype "byte" with a range'd integer. No surprise for simili : integer is integer, vanilla reads 4 bytes at a time. It even copies the file and rounds the size up to the next multiple of 4. Simili gave me a surprise : first, it deals with bytes. at least, this is what the old version i use does. I think that it gives a little insight in how simili works internally. I tried to raw-"write" some structures and a std_ulogic_vector(N downto 0) outputs N bytes (not N-1). Second, given a binary input, it stops after N bytes. I compared the hexdump of the input and the output : input : 68 FF 7E output : 68 68 (that is : where the output stopped). I fear that it can be worse that i thought. Well i SHOULD update my local copy of simili. Maybe it was fixed long ago. But stopping on a 0xFF is not a good sign for a C program. I know : Simili is written in C++ and i don't know a damn about it. So i will let the experts discuss about it. Any hint ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 22:46:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi6-0000MN-01 for ; Fri, 14 Sep 2001 03:24:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:02 +0200 (CEST) Received: (qmail 20599 invoked by uid 0); 13 Sep 2001 20:47:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 13 Sep 2001 20:47:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DKlZF16657 for ; Thu, 13 Sep 2001 16:47:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 20:46:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DKkTK15964 for f-cpu-list; Thu, 13 Sep 2001 16:46:29 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DKkQC15958 for ; Thu, 13 Sep 2001 16:46:26 -0400 Received: by moria.seul.org (Postfix) id 47C151462F7; Thu, 13 Sep 2001 16:46:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.seul.org (Postfix) with ESMTP id CCD531462E9 for ; Thu, 13 Sep 2001 16:46:30 -0400 (EDT) Received: from f-cpu.org (nas1-81.aub.club-internet.fr [195.36.202.81]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA02265 for ; Thu, 13 Sep 2001 22:46:18 +0200 (MET DST) Message-ID: <3BA11B1B.DEF8B734@f-cpu.org> Date: Thu, 13 Sep 2001 22:46:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Sep 13, 2001 at 03:18:25AM +0200, Yann Guidon wrote: > [...] > > The summit is reached with the new > > "desktop managers" (KDE, GNOME etc) which are extremely complex, > > and can't cooperate EVEN THOUGH THEY ARE FREE ! > I love standards -- there are so many of them to choose from ;( i don't think so (at least, at our level). > I'm afraid that we may get an `interface explosion' when users start to > populate the area around the F-CPU core with their own stuff. In order > to prevent that, we should provide a fixed, well-documented `general > interface' and encourage people to connect to it instead of patching > the core. yup. This means : finding the I/O standard that is most similar to the F-CPU. i know none today. > > There is a small danger with the wishbone stuff. It is public domain, > > not an IEEE or ANSI standard (AFAIK). I don't believe that the > > performance is extraordinary. It's ok if you want to communicate > > with mid-speed I/O or do some IC2IC intercom, but F-CPU needs > > some strong doses of EPO+amphetamines, if you see what i mean. > Just because something is PD (or GPLed), it doesn't have to perform > badly ;) sure, but when you design something, you certainly have something in mind and that influences the rest. wishbone was not designed with the same goals as the Athlon FSB you describe below. > > My current view for a "decent" F-CPU chip is : > > - SDRAM (DDR/whatever) direct interface with the core > > - onchip L1 cache (low latency) > > - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM, > > so we can do very wide SIMD computations > Only useful if we can bypass the L1 cache. Otherwise, we'll get lots > of misses there. What about a bigger L1 cache instead? HP did that in > the PA-8500. i don't think that we can "afford" it. the clock cycle is too short. and after all, that's what cache hierarchies are for :-) L1 "bypassing" is done with one flag in the L/S instructions btw. > > - some kind of relatively fast interface to the outside, possibly > > with rather wide words (64-bit or 128-bit at a time) if it is on-chip. > I like the FSB of the MP-Athlon... it's a fast point-to-point link > (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional > control buses. It somehow reminds me of the F-BUS ;) really cool, but is it free ?... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 22:46:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi7-0000MN-00 for ; Fri, 14 Sep 2001 03:24:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:03 +0200 (CEST) Received: (qmail 10850 invoked by uid 0); 13 Sep 2001 20:47:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 13 Sep 2001 20:47:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DKlem16693 for ; Thu, 13 Sep 2001 16:47:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 20:46:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DKkTE15965 for f-cpu-list; Thu, 13 Sep 2001 16:46:29 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DKkQC15959 for ; Thu, 13 Sep 2001 16:46:26 -0400 Received: by moria.seul.org (Postfix) id 5C8F91462E9; Thu, 13 Sep 2001 16:46:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by moria.seul.org (Postfix) with ESMTP id D8DBB1462F6 for ; Thu, 13 Sep 2001 16:46:30 -0400 (EDT) Received: from f-cpu.org (nas1-81.aub.club-internet.fr [195.36.202.81]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA23688; Thu, 13 Sep 2001 22:46:20 +0200 (MET DST) Message-ID: <3BA11B16.BAF60355@f-cpu.org> Date: Thu, 13 Sep 2001 22:46:14 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org, "Haneef D. Mohammed" Subject: Re: [f-cpu] binary streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello everybody, in this mail i will try to sum up the different discussions so please excuse me for the cross-posting and the length. Kim Enkovaara wrote: > On Thu, 13 Sep 2001, Yann Guidon wrote: > > in the Eurostar, i found the reason why my random > > routin gave strange behaviour. This can be illutrated > > by the following code : > ... > > variable c : character; > > I think this is the problem. Define this as bit_vector or > std_logic_vector. After that binary mode reading should work. Character is > defined differently. i am not sure to understand what you said. I have already tried (well, with simili) to output std-ulogic_vectors and it uses one byte per bit (each bytt represents the different possible states of the corresponding bit). i don't understand what you mean by "Character is defined differently." I have read two (rather exhaustive) VHDL books in the subject and they did not address that point. > ============================================================================= > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian > Vasamatie 1 C 16 | IRC: embo | curved-space fault in > 02630 Espoo | | write-only file system Michael Riepe wrote: > On Thu, Sep 13, 2001 at 03:38:54AM +0200, Yann Guidon wrote: > [...] > > > but I don't know what to do in VHDL. Perhaps you can do something like > > > type octet is 0 to 255; > > > type octet_stream is file of octet; > > i think i tried this already, however i presume that this "subset" > > for the "integer" type keeps the 4-byte encoding (the range is only restricted) > > so if i read a "byte" i will increment the file counter by four. > > i'll try anyway because i better prove it, but it's a gut feeling. > > There's a fundamental difference between the declarations > > type octet is range 0 to 255; -- i forgot the `range'... > subtype other_octet is integer range 0 to 255; > > `other_octet' is a subtype of `integer', and must use the same (4-byte) > encoding, IIRC, while `octet' is a new type that may use a single-byte > representation (vanilla doesn't, unfortunately). i think that Vanilla trapped me with that... > > > If it still stops at a ^Z, I would consider that a bug in Simili. > > simili and vanilla definitely differ ! > As well as the underlying OSes. sure. Fortunately, i see that simili is evolving in the good sense :-))) i'll try to download a newer version if it is available. the latest i got was VHDLSimili15b17.exe but i have not installed it on my laptop. > > > But you'll probably have to write a completely new set of I/O routines > > > for the `octet' type. > > not necessarily, but if it's necessary, i'll do it. > Seems like there are predefined read and write procedures... yes :-) i read that in one of Graham's books :-) you can output almost any scalar type except file itself. the textio interface defines a new type so the textio package itself is just a bunch of wrappers. operator overloading in VHDL is nice but it can become misleading... > > > On the other hand, binary files are evil anyway because they're not > > > portable (imagine you had to transfer them to a big-endian box, like > > > SPARC). > > in this case (random numbers coming from /dev/random or .tgz files) > > it is irrevelant. > In that case, you could also try a `file of integer' or something like > that, and read larger quantities. I've attached an example (works > with vanilla; please try simili yourself, I can't reboot while I'm > writing e-mails ;). i think i have another idea... > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > randex.vhdlName: randex.vhdl > Type: Plain Text (text/plain) well this is plain simple. my newest idea is far ... better :-) i'll code it before i shout victory :-) however i still need some really random bytes for the "seed". There is another problem though : When i reach the end of a file, i would like to wrap around. i tried to explicitely calling file_close and then file_open but the simulators complain :-/ the re-opening is not possible because the file name is still associated, or something like that. I don't know how to cheat/work around that. Any hint or advice ? hello, Haneef Mohammed wrote: > > first good news : Simili (1-year old version) works > > rather well under wine. the hardest part is to setup > > wine directories etc. > > just write : > Good to hear that. > > > $> wine "vhdlp filename.vhdl" 2> /dev/null > > because wine output lots of error messages about semaphores > > or something like that, but simili works anyway and well. > > > > problem : > > i want to make a "true" random function to initialize > > variables and signals at startup, before /reset is activated. > > so i use an external file access to /dev/null. > > but it clashes ! i made a little simili/vanilla > > comparison with the attached file and vanilla > > treats characters as bytes while simili hangs > > on certain characters ('EOF') in a binary stream. > > > > what's your advice ? > > About the semaphore/criticalsection messages from wine, > you can ignore them I believe. i do and it is harmless. > Someone said that there > may even be a way to turn them off in the wine config file. > I dont know why wine is outputting those messages. i will try to investigate on that. i saw some parameters in the wine config file but i don't know what parameter addresses this special case. > About reading binary data.... > Not sure what the problem is. I just tested it and I was > able to read all 8-bit ascii characters in windows. You say > that you are using an year old version which may be the problem. > Can you try it out with the latest version? It works fine for > me with 1.5 and 2.0. i'll update my files. > It is possible that in one of the older version, > the files were being opened for read in text mode (which may explain > what you are seeing). certainly. i never open files in text mode in C (it is a good and safe thing to write 'fopen(filename,"rb"). > Regards, > Haneef Later, Haneef Mohammed wrote: > WHYGEE, > > Please note that if you are writing files from VHDL, > simili does convert \n ro \r\n (this is the default > dos behaviour)..... i know and expected that something like that would happen but it is not a problem because it is more about _reading_ files. > But, reading should be just fine with the latest 1.5 i'm happy to read that :-) > A month or two ago, I noticed this on writes (when I > was doing the Linux port) and 2.0 was changed so that > both reads and writes happen in binary mode. Do you need > the output to be pure binary...If so, I have to give you > a patched version of 1.5 that you and your colleagues > can use. no need of a patch (we already do that all the time on our own files :-P). The problem (currently) is to _read_ binary stream without being interrupted by a 0xFF. > Regards, > Haneef So here are the remaining questions : - what is the safest way to write a VHDL code that read binary inputs in a way that is as much portable as possible ? - how can one "seek" to the beginning of a file when EOF is reached ? - Vanilla complains in the "random" package when i want to put shared variables in the body of the package. how can i I think that i will use a LFSR for the next parts. It still requires the possibility to input some bytes but the pressure is much reduced : /dev/random is very slow and not a continuous stream. This will also spread the randomness if text files were used in the input. However, if the LSFR idea is used, some variables must be saved between two function calls : i have to create "shared variables" but Vanilla doesn't accept them. Thank you everybody for your help ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 22:46:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhi9-0000MN-00 for ; Fri, 14 Sep 2001 03:24:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:05 +0200 (CEST) Received: (qmail 19701 invoked by uid 0); 13 Sep 2001 20:47:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 13 Sep 2001 20:47:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DKlwa16831 for ; Thu, 13 Sep 2001 16:47:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 20:46:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DKkuk16261 for f-cpu-list; Thu, 13 Sep 2001 16:46:56 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DKkmC16203 for ; Thu, 13 Sep 2001 16:46:49 -0400 Received: by moria.seul.org (Postfix) id 2D7C41462F6; Thu, 13 Sep 2001 16:46:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.seul.org (Postfix) with ESMTP id AAC3E1462E9 for ; Thu, 13 Sep 2001 16:46:53 -0400 (EDT) Received: from f-cpu.org (nas1-81.aub.club-internet.fr [195.36.202.81]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA02297; Thu, 13 Sep 2001 22:46:29 +0200 (MET DST) Message-ID: <3BA11B1D.D28967AD@f-cpu.org> Date: Thu, 13 Sep 2001 22:46:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Lotsa 'em References: <20010913073616.67575.qmail@web20408.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Shahar Goldin wrote: > Ok I sorta stumbled upon your project on a google > search for something or other all my apologies :-) > I have a few things to say so if its not too much > trouble or time, please take a look > .. > First off, I don't like mailing lists - IMO Newsgroups > (*(are more functional, and I prefer that my mreserved > for people directing things at me > (You can ignore any part of this, it is all my > personal opinion which, generally, matters little ;^) newsgroups and IRC are fine, but it is not perfect for everybody. it's ok when you have a direct link to the Net and lots of time. However, concerning my case, it's far >from possible. I am in France with a modem and the communications are paid a la minute. It is easy for anyone to participate in the discussions, even if there are several days of delay. another important "detail" is to keep the discussions in archives. When there is a problem, we have at least a proof (even though it is not legally valid) of our intention and we can justify past decisions. it is far from possible on IRC and newsgroup archives are not easy. I do agree that "instant" communication is cool but it must also be realisable for everybody if we want that people contribute without too much efforts. Another solution is to organise meetings : there is a monthly meeting in Paris for example. it is more difficult in other countries because people are more scattered. > Secondly, I understand the manual is incomplete, but > right now I can think of a few immediate modifications > that could help alot... > - Highlight in red stuff that is obsolete, by > previous groups, etc... i hope that the next version will insist even more. somebody is in charge of this but he is often very late. > - Include a booklist for people who want to help > about coding VHDL, Proccessor Architectures, etc, and > so on. I am currently writing a VHDL-HOWTO for the contributors (or those who want to code). However, there are a lot of ressources on the Net for the rest. We try to include a lot of external ressources when we make a CDROM for public diffusion (in meetings or conferences). > Lastly, I think nowadays, a project is best developed > on IRC or other Real Time communication... probably, but most people have "shifted" working times. In France i "work" from around 9pm to 6am... And other people in the world have different schedules. There is a f-cpu IRC channel but i don't know what it has become : is it still in use ? > Please excuse me if any of this has been > discussed/rejected before but I'm not going to read > through 3 years of mailing list archives > ;^) don't worry. But if you can have a look, you will probably see, learn and understand many things. Some parts are really boring, but it is useful to "see" how things evolve and happen. regards, > --SG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 23:18:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiB-0000MN-00 for ; Fri, 14 Sep 2001 03:24:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:07 +0200 (CEST) Received: (qmail 9267 invoked by uid 0); 13 Sep 2001 21:19:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 13 Sep 2001 21:19:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DLJ9317794 for ; Thu, 13 Sep 2001 17:19:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 21:18:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DLIWP17534 for f-cpu-list; Thu, 13 Sep 2001 17:18:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DLIUC17531 for ; Thu, 13 Sep 2001 17:18:30 -0400 Received: by moria.seul.org (Postfix) id 1A0ED1462F6; Thu, 13 Sep 2001 17:18:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.seul.org (Postfix) with ESMTP id E39401462E9 for ; Thu, 13 Sep 2001 17:18:30 -0400 (EDT) Received: from f-cpu.org (nas4-108.ras.club-internet.fr [195.36.203.108]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA16239 for ; Thu, 13 Sep 2001 23:18:21 +0200 (MET DST) Message-ID: <3BA1229F.821A9F08@f-cpu.org> Date: Thu, 13 Sep 2001 23:18:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Cadence software helping me soon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, since i got new ethernet hardware, Martyn from Cadence was able to send me a key. Well, i have nothing installed yet, a key without working SW is a wasted cluster but i hope that it will change soon :-) Now i will have three VHDL compilers on my laptop. If i can compile Savant (there's a pre-release version available, look at OpenCollector's database), i'll have four. wow :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 13 23:36:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiC-0000MN-00 for ; Fri, 14 Sep 2001 03:24:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:08 +0200 (CEST) Received: (qmail 9015 invoked by uid 0); 13 Sep 2001 21:37:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Sep 2001 21:37:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DLbdC18298 for ; Thu, 13 Sep 2001 17:37:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 21:36:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DLajO18039 for f-cpu-list; Thu, 13 Sep 2001 17:36:45 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DLagC18036 for ; Thu, 13 Sep 2001 17:36:43 -0400 Received: by moria.seul.org (Postfix) id 238C1146312; Thu, 13 Sep 2001 17:36:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by moria.seul.org (Postfix) with ESMTP id A7728146300 for ; Thu, 13 Sep 2001 17:36:47 -0400 (EDT) Received: from f-cpu.org (nas4-108.ras.club-internet.fr [195.36.203.108]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA09714; Thu, 13 Sep 2001 23:36:34 +0200 (MET DST) Message-ID: <3BA126DB.71991AAA@f-cpu.org> Date: Thu, 13 Sep 2001 23:36:27 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org, ff Subject: Re: [f-cpu] Cadence software helping me soon References: <3BA1229F.821A9F08@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N re-coucou, Yann Guidon wrote: > > hi, > > since i got new ethernet hardware, > Martyn from Cadence was able to send > me a key. Well, i have nothing installed > yet, a key without working SW is a wasted > cluster but i hope that it will change soon :-) je "charge" le logiciel actuellement. en fait, il fait dans ses 128MO. je passe par la fac de St Denis qui a un lien assez rapide. Le problème sera de récupérer le "fichier"... Quelqu'un pourra me mettre ça sur un CDROM ? Paul ? nicO ? qqn avec une ligne assez rapide et un graveur ? merci d'avance... sorry if it is not english. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 14 01:01:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiE-0000MN-01 for ; Fri, 14 Sep 2001 03:24:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:10 +0200 (CEST) Received: (qmail 6014 invoked by uid 0); 13 Sep 2001 23:04:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 13 Sep 2001 23:04:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DN47p20378 for ; Thu, 13 Sep 2001 19:04:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 23:03:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DN3Ct19774 for f-cpu-list; Thu, 13 Sep 2001 19:03:12 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DN3AC19771 for ; Thu, 13 Sep 2001 19:03:11 -0400 Received: by moria.seul.org (Postfix) id 490DE1462F7; Thu, 13 Sep 2001 19:03:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 344E81462E9 for ; Thu, 13 Sep 2001 19:03:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02487; Fri, 14 Sep 2001 01:01:33 +0200 Message-ID: <20010914010133.30271@thrai.stud.uni-hannover.de> Date: Fri, 14 Sep 2001 01:01:33 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] binary streams References: <3BA11B16.BAF60355@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA11B16.BAF60355@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 10:46:14PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 13, 2001 at 10:46:14PM +0200, Yann Guidon wrote: [...] > > There's a fundamental difference between the declarations > > > > type octet is range 0 to 255; -- i forgot the `range'... > > subtype other_octet is integer range 0 to 255; > > > > `other_octet' is a subtype of `integer', and must use the same (4-byte) > > encoding, IIRC, while `octet' is a new type that may use a single-byte > > representation (vanilla doesn't, unfortunately). > > i think that Vanilla trapped me with that... On the other hand, Vanilla groks this: -- same `entity blah' as in randex.vhdl architecture blah of blah is type cstream is file of character; file x : cstream open read_mode is "random"; begin process variable c : character; variable lout : line; begin while not endfile(x) loop read(x, c); write(lout, character'pos(c)); writeline(output, lout); end loop; wait; end process; end blah; And it doesn't stop at 0xff :) [...] > operator overloading in VHDL is nice but it can become misleading... IMHO, operator overloading is *always* misleading. Not only in VHDL, but also in Ada, C++, ... [...] > well this is plain simple. my newest idea is far ... better :-) > i'll code it before i shout victory :-) > however i still need some really random bytes for the "seed". 1-transistor noise generator + ADC? ;) > There is another problem though : When i reach the end of a file, > i would like to wrap around. i tried to explicitely calling file_close > and then file_open but the simulators complain :-/ the re-opening > is not possible because the file name is still associated, or something > like that. I don't know how to cheat/work around that. According to the comp.lang.vhdl FAQ, it works like this: file x : some_file_type; -- ... file_open(x, "a_file_name", read_mode); -- ... file_close(x); I guess the trick is not to open the file in the declaration, but explicitly. [...] > I think that i will use a LFSR for the next parts. > It still requires the possibility to input some bytes > but the pressure is much reduced : /dev/random is very slow > and not a continuous stream. This will also spread the randomness > if text files were used in the input. /dev/urandom is faster (but "less random"). > However, if the LSFR idea is used, some variables must be saved > between two function calls : i have to create "shared variables" > but Vanilla doesn't accept them. I really try hard not to use shared variables, impure functions and the like... What about this: define a record type that holds the LSFR's internal state, and an `update' procedure with the state (inout) and the random value (out) as parameters. You can export both the `lsfr state' type and the update procedure from a package, and you'll only have to declare a state variable in every architecture (or process) that uses an LSFR. *And* you can use multiple independent LSFRs, with different seeds :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 14 00:27:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiG-0000MN-00 for ; Fri, 14 Sep 2001 03:24:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:12 +0200 (CEST) Received: (qmail 23097 invoked by uid 0); 13 Sep 2001 23:04:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 13 Sep 2001 23:04:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DN4KD20507 for ; Thu, 13 Sep 2001 19:04:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 23:03:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DN3Ox19852 for f-cpu-list; Thu, 13 Sep 2001 19:03:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DN3LC19833 for ; Thu, 13 Sep 2001 19:03:21 -0400 Received: by moria.seul.org (Postfix) id C77111462F7; Thu, 13 Sep 2001 19:03:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 5BB931462E9 for ; Thu, 13 Sep 2001 19:03:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02375; Fri, 14 Sep 2001 00:27:46 +0200 Message-ID: <20010914002746.42863@thrai.stud.uni-hannover.de> Date: Fri, 14 Sep 2001 00:27:46 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> <3BA11B1B.DEF8B734@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA11B1B.DEF8B734@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 10:46:19PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 13, 2001 at 10:46:19PM +0200, Yann Guidon wrote: [...] > > Just because something is PD (or GPLed), it doesn't have to perform > > badly ;) > sure, but when you design something, you certainly have something in mind > and that influences the rest. wishbone was not designed with the same goals > as the Athlon FSB you describe below. I never intended to use wishbone as the FSB interface, but as a kind of "expansion slot" for SoC. [...] > > I like the FSB of the MP-Athlon... it's a fast point-to-point link > > (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional > > control buses. It somehow reminds me of the F-BUS ;) > really cool, but is it free ?... I guess not. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 14 00:23:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiG-0000MN-01 for ; Fri, 14 Sep 2001 03:24:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:12 +0200 (CEST) Received: (qmail 21758 invoked by uid 0); 13 Sep 2001 23:04:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 13 Sep 2001 23:04:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8DN4QE20553 for ; Thu, 13 Sep 2001 19:04:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 13 Sep 2001 23:03:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8DN3Un19921 for f-cpu-list; Thu, 13 Sep 2001 19:03:30 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8DN3QC19877 for ; Thu, 13 Sep 2001 19:03:26 -0400 Received: by moria.seul.org (Postfix) id 9EB7F1462F7; Thu, 13 Sep 2001 19:03:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id C8D601462E9 for ; Thu, 13 Sep 2001 19:03:28 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02361; Fri, 14 Sep 2001 00:23:01 +0200 Message-ID: <20010914002300.06105@thrai.stud.uni-hannover.de> Date: Fri, 14 Sep 2001 00:23:00 +0200 From: Michael Riepe To: f-cpu@seul.org Cc: "Haneef D. Mohammed" Subject: Re: [f-cpu] vanilla vs simili References: <3BA0F36E.18808BE2@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA0F36E.18808BE2@f-cpu.org>; from Yann Guidon on Thu, Sep 13, 2001 at 07:57:02PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 13, 2001 at 07:57:02PM +0200, Yann Guidon wrote: [...] > Simili gave me a surprise : first, it deals with bytes. > at least, this is what the old version i use does. > I think that it gives a little insight in how simili > works internally. I tried to raw-"write" some structures > and a std_ulogic_vector(N downto 0) outputs N bytes (not N-1). That should better be N+1... One byte per (std_ulogic) bit is ok, since std_ulogic can have 9 values. A packed (2 std_ulogic bits per byte) format would save some space but is harder to handle. > Second, given a binary input, it stops after N bytes. > I compared the hexdump of the input and the output : > input : 68 FF 7E > output : 68 68 > (that is : where the output stopped). I fear that it can be > worse that i thought. Well i SHOULD update my local copy of > simili. Maybe it was fixed long ago. But stopping on a 0xFF > is not a good sign for a C program. I know : Simili is written > in C++ and i don't know a damn about it. So i will let > the experts discuss about it. C/C++ programs stopping at 0xff usually suffer from the `getc() return type' problem (some programmers use C stdio in C++). But it could also be the C runtime library (getc() returning negative values if the char value goes beyond 127, which makes EOF and (char)255 indistinguishable). But I'm not a Windoze Quirks Expert (tm)... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 14 02:53:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15hhiJ-0000MN-00 for ; Fri, 14 Sep 2001 03:24:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Sep 2001 03:24:15 +0200 (CEST) Received: (qmail 14782 invoked by uid 0); 14 Sep 2001 00:54:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 14 Sep 2001 00:54:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8E0sfH24324 for ; Thu, 13 Sep 2001 20:54:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 00:53:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8E0rDc23897 for f-cpu-list; Thu, 13 Sep 2001 20:53:13 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8E0rBC23889 for ; Thu, 13 Sep 2001 20:53:11 -0400 Received: by moria.seul.org (Postfix) id D7D66146305; Thu, 13 Sep 2001 20:53:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.seul.org (Postfix) with ESMTP id 4CA641462F6 for ; Thu, 13 Sep 2001 20:53:16 -0400 (EDT) Received: from f-cpu.org (nas2-220.aub.club-internet.fr [195.36.133.220]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA06450 for ; Fri, 14 Sep 2001 02:53:03 +0200 (MET DST) Message-ID: <3BA154F3.F8B70F3F@f-cpu.org> Date: Fri, 14 Sep 2001 02:53:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> <3BA11B1B.DEF8B734@f-cpu.org> <20010914002746.42863@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Sep 13, 2001 at 10:46:19PM +0200, Yann Guidon wrote: > [...] > > > Just because something is PD (or GPLed), it doesn't have to perform > > > badly ;) > > sure, but when you design something, you certainly have something in mind > > and that influences the rest. wishbone was not designed with the same goals > > as the Athlon FSB you describe below. > I never intended to use wishbone as the FSB interface, but as a kind of > "expansion slot" for SoC. we can see that this way, right. "extension slot", a bit like the ISA or PCI slots. not too slow, not too fast, useful to hack stuff. semaphores, keyboard/USB/floppy/IrDa etc. OTOH we still need BANDWIDTH for the external memory. > [...] > > > I like the FSB of the MP-Athlon... it's a fast point-to-point link > > > (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional > > > control buses. It somehow reminds me of the F-BUS ;) > > really cool, but is it free ?... > I guess not. let's stop dreaming to code now :-) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Sep 15 03:09:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3t6-0002Ns-00 for ; Sat, 15 Sep 2001 03:04:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:52 +0200 (CEST) Received: (qmail 19075 invoked by uid 0); 14 Sep 2001 19:53:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 14 Sep 2001 19:53:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8EJrVx09351 for ; Fri, 14 Sep 2001 15:53:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 19:52:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8EJqnq09104 for f-cpu-list; Fri, 14 Sep 2001 15:52:49 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8EJqlC09101 for ; Fri, 14 Sep 2001 15:52:47 -0400 Received: by moria.seul.org (Postfix) id 8CB831462F6; Fri, 14 Sep 2001 15:52:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-21.vlt.club-internet.fr [194.158.109.21]) by moria.seul.org (Postfix) with ESMTP id 8E6FA1462E9 for ; Fri, 14 Sep 2001 15:52:52 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id A58121727 for ; Fri, 14 Sep 2001 21:09:05 -0400 (EDT) Message-ID: <3BA2AA31.9CF2DE31@ifrance.com> Date: Fri, 14 Sep 2001 21:09:05 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : <...> > > Otherwise, stick with LEON : having a lot of CPU power is not > > interesting if you're 'memory-bound' whatever you do. Cache miss > > rates and refill speed kills all CPU. So at least with LEON you > > are not too much memory bound. > > > > My current view for a "decent" F-CPU chip is : > > - SDRAM (DDR/whatever) direct interface with the core > > - onchip L1 cache (low latency) > > - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM, > > so we can do very wide SIMD computations > No, don't mix things. I think as leon. It's like a canonical cpu. Leon are core+L1 cache then it used AMBA bus to connect memory controleur and so on (UART...). You could what ever speed you by enlarge the bus. Wichbone coulb be extend 256 bits for internal use. So fcpu core will only be the core+cache(unified or separate). All others things could be include in a "plateforme". I think about controler, L2 cache but we can add interrupt controler and so on (IO quick link ). Imagine a router, it don't need SDRAM. So to the outside world, we could have coprocessor interface (as leon ?) + bus interface (wishbone). That's could clairly defined API. nicO > > - some kind of relatively fast interface to the outside, possibly > > with rather wide words (64-bit or 128-bit at a time) if it is on-chip. > > I like the FSB of the MP-Athlon... it's a fast point-to-point link > (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional > control buses. It somehow reminds me of the F-BUS ;) > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Sep 15 04:09:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3t7-0002Ns-00 for ; Sat, 15 Sep 2001 03:04:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:53 +0200 (CEST) Received: (qmail 18057 invoked by uid 0); 14 Sep 2001 19:58:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 14 Sep 2001 19:58:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8EJwgi09721 for ; Fri, 14 Sep 2001 15:58:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 19:58:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8EJw7f09465 for f-cpu-list; Fri, 14 Sep 2001 15:58:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8EJw5C09462 for ; Fri, 14 Sep 2001 15:58:05 -0400 Received: by moria.seul.org (Postfix) id 33EA21462F6; Fri, 14 Sep 2001 15:58:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-21.vlt.club-internet.fr [194.158.109.21]) by moria.seul.org (Postfix) with ESMTP id 0DA8E1462E9 for ; Fri, 14 Sep 2001 15:58:09 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 720CC1717 for ; Fri, 14 Sep 2001 22:09:37 -0400 (EDT) Message-ID: <3BA2B861.8E0A275A@ifrance.com> Date: Fri, 14 Sep 2001 22:09:37 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > Michael Riepe a écrit : > > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: > > > [...] > > > > A SoC is so specialised ! So there isn't any interrest to change the > > > > chip. It's a complete system so you could always create a compatible > > > > chip with a complete different SoC. Imagine a mp3 producer, there is so > > > > many manner to make it. You could do it with dedicated HW or with a DSP > > > > or a powerfull RISC cpu, or with many little cpu. > > > > > > > > I hope a convince you. > > > > > > I absolutely don't mind if somebody builds an F-CPU based SoC. > > > As long as users can get the complete source code under GPL ;) > > > > > > > I think that you forget that produice a complet chip cost a lot of > > money, a lot ! Do you think that a compagny will take 6 month to > > produice a chip that a direct concurrent could only use 2 month, because > > of the open source ? > > you fall in the same trap constantly. F-CPU's goal is not to let people > do "benefits" on it. It is here to "help" the industry as a whole and > harmonize some common stuff. Where people would use SUN/SPARC workstations, > they could find F-CPU/Linux boxes for 1/4 the price and a lot of third > parties. > > concerning the difficulty, here is the first opening quote from the > "supermen" book (about supercomputers, si tu veux l'emprunter yaka demander) > " > If a man can write a better book, preach a better sermon, or > make a better mousetrap than his neighbor, though he build > his house in the woods, the world will make a beaten path > to his door. > Ralph Waldo Emerson, 1871 > " > > comprenne qui voudra. On top of that, this quote has a special > meaning because Seymour Cray built lots of CRAY fabs in the isolated > woods. Thanks to him, a lot of people in the neighbourhood > have seen helicopters and journalists for the first time > in their life :-) > > > GPL was written for software in mind. They want to > > spread this kind of software, and make some attractive clauses (for > > example, we can not stole your code). > > i don't like the "attractive" thing. > Of course, the following text probably doesn't apply to your last comment > but i write anyway. > > Of course, i would like F-CPU to be used in big and small designs, > in the commercial or industrial world. However there is a limit to > attraction. i don't know if you understand what i will say, but > i encourage you to visit DATE (with me or alone) and preach for > the F-CPU. We are designers, not whores. Most people with whom > you will speak have no sense of what freedom means. the only > freedom they know is their "holy right to make profit" (sometimes > they think it can short-circuit other fundamental or constitutional > freedoms). > The only thing that they want is money, or profit. other words > are market shares, penetration (ouch !), growth... Nobody will speak > about advancement of the technology (except in the introduction > of very generalistic press releases), about encouraging competition > or our freedom to design and do our engineer's work. > Some university teachers are still idealistic enough to believe > in that, but that tends to disapear quickly as they get funded > by the industry. > > So here, i will draw (or more precisely, redraw and insist upon it) > a "line" : You have the right to use the F-CPU sources for any purposes > as long as it is "out of the tarball" (unmodified). In fact, most > IPs are like that. I remember of an example (unsure but it's a rough > figure) for the ARM (?) core IP : ie you get the "compiled IP" for $10K > and if you want to modify it, you have to pay $35K (?). If my memory > serves me well, i heard these numbers at DATE in Munich). > "please contact your local reseller for up-to-date pricing". > > Now, you get a kick-ass F-CPU with source code "for free". you get > the right to integrate it in your preferred washing machine as long as > you don't modify the provided sources or integrate stuff into the core. > The ARM (? was it ARM btw ?) guy told me that it is done this way > most of the time : few customers really want to modify the core's sources. > - first reason is that the compiled core is already compiled : the compiler > licence would cost more > - it is already optimized > - it is compatible with anything. > So that's fine for me. I don't know if Michael will agree to my POV but i am > open to any senseful and argumented discussion. > > The next step is : you want to modify the core. You don't need to pay more > because it is already "free" and it can't be "more free". If i take > the ARM guy's saying for true, this is not going to happen a lot. > The condition for modifying the code is to redistribute it (in F-CPUland). > Of course there is still the problem of where the "limit" of the core is, > but it's another discussion. > > What we "give" is the possibility to > "evaluate" the core, within the limits fixed (and slowly loosened) > by the m4 files' parameters. So if the company wants to implement, > say, a communication controller (SCSI RAID or IP router for example) > and wants to avoid the cost of an existing IP, a small team of > engineers can d/l the F-CPU tarball, the LEON's, anything else, > and make testbenches, comparisons, benchmarks... > If it chooses F-CPU, fine. If it needs some changes, > then it must release the new files. It is simple. > > Forcing to release the files is seen, by you and Juergen at least IIRC, > as a problem. It is also forcing companies to open their eyes : releasing > their specs and sources increases indirectly the customer's self-help > and augments the feedback (if the company is open enough). It is a garantee > of stability of the product family. And remember the ALPHA fiasco : > Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied > when purposedly saying that ALPHA would be continued during decades) have > now lost money and time porting their applications. Now, imagine ALPHA > was open-sourced : the companies would be able to continue the work, > probably through a joint-venture that spreads the costs. > You all right but you miss one very big point. If a compagny have a problem with an ARM7, ARM will have a lot of trouble and pay. For fcpu nothing !There is absolutely no garanty. A lot of compagny will be afraid of this risk. Look, it happen the same thing with linux : only Red Hat are supported by compagny as Cadence or other software compagny. Maybe, Turbo linux, Suse and Mandrake but never Debian. Never. There is no compagny to make the support, but every one have the right to do it ! Leon aren't "space qualified" nowdays and will be used "maybe" in few years, not before ! > I wish the microelectronics world was not such a dirty swamp ... > > Concerning nicO's remarks about integrating F-CPUs everywhere : > fine, but woudln't it be an overkill ??? there is no "short" > version of F-CPU (32 bit support is not under way and it is discouraged). > I know no 'portable' application that needs fast 32-b arithmetics. > When it is really required, a 16-b or 32-b µC does multi-precision > operations. 32-bit SIMD would be used for real-time imaging > and sound processing applications (ie digital handicams) > but the devices that do that are often made in Japan with > highly proprietary chips/ASICs. F-CPU would not help much. > ARM7 is a 32b device, so ? In few years, will have 0.07 um tech, 64 bits cpu could become common. > However, it is useful for small quantities > (around 1K-100K) runs concerning high-speed control, such as > the SCSI or IP router example. Small companies would adopt F-CPU > easily because the price tag and the independence from the toolset > are "attracting" (to reuse your word). I think that it is where > we can seek implementors. > Yep, if they can earn money, and there work will not be stolen as explain by Michael. But i think of another think of the GPL. Sources must be delivered with binaries but what happen with chips. Does a chip maker should release a chip with the HDL code ? It's not a binaries, so does the compagny _must_ distribiute this code ? or it must be done only in case of IP (no more SDF file only, IP), which is more directly link with the sources code ? nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 14 23:50:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3t9-0002Ns-01 for ; Sat, 15 Sep 2001 03:04:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:55 +0200 (CEST) Received: (qmail 16305 invoked by uid 0); 14 Sep 2001 21:51:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 14 Sep 2001 21:51:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ELpHc13727 for ; Fri, 14 Sep 2001 17:51:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 21:50:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ELoWt13251 for f-cpu-list; Fri, 14 Sep 2001 17:50:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ELoUC13248 for ; Fri, 14 Sep 2001 17:50:30 -0400 Received: by moria.seul.org (Postfix) id 74A611462F6; Fri, 14 Sep 2001 17:50:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.seul.org (Postfix) with ESMTP id 1473B1462E9 for ; Fri, 14 Sep 2001 17:50:36 -0400 (EDT) Received: from f-cpu.org (nas1-152.ras.club-internet.fr [195.36.192.152]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA19750 for ; Fri, 14 Sep 2001 23:50:26 +0200 (MET DST) Message-ID: <3BA27BA5.20012549@f-cpu.org> Date: Fri, 14 Sep 2001 23:50:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > Michael Riepe a écrit : > > > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: > > > > [...] > > Forcing to release the files is seen, by you and Juergen at least IIRC, > > as a problem. It is also forcing companies to open their eyes : releasing > > their specs and sources increases indirectly the customer's self-help > > and augments the feedback (if the company is open enough). It is a garantee > > of stability of the product family. And remember the ALPHA fiasco : > > Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied > > when purposedly saying that ALPHA would be continued during decades) have > > now lost money and time porting their applications. Now, imagine ALPHA > > was open-sourced : the companies would be able to continue the work, > > probably through a joint-venture that spreads the costs. > > > You all right but you miss one very big point. If a compagny have a > problem with an ARM7, ARM will have a lot of trouble and pay. For fcpu > nothing ! 1) companies can have "problems" when : - vendor goes out of business - vendor "hides" pages of documents that detail "errata" - vendor sells bogus stuff i don't remember a few others but i think that i have an "answer" for each of them : - out of business : we can't ;-) and if that happens, the user has the sources. - no secret is tolerated in the F-CPU. If an error is found it is immediately communicated and worked around/corrected. - at least, we don't sell anything. So if it's "bogus", read the 2) below :-P 2) even though there's "nobody to sue", how many companies do you know who do not take the minimum precaution of writing "no waranty for fitness etc." ??? Read a user licence from M$ or any "professional tool vendor" : they ALL remove their responsibility. We are no exception in fact. other case analysis can be discussed. > There is absolutely no garanty. excuse-me sir, but if your W95/98/NT/ME/2K freezes, will you sue M$ ? M$ will ask you to re-read your contract which says that there is no waranty of any kind. NOBODY today forgets this clause. Buying stuff does not mean that you have the right to sue. The reseller and manufacturer have rights and duties that are defined by the local law, such as replacing a faulty device. You can go to M$ to replace your badly-pressed Window$ CD but the contents is something else. > A lot of compagny will be afraid of this risk. companies are sheeps. look at the stock exchange rates these days if you are not convinced. > Look, it happen the same thing with linux : only > Red Hat are supported by compagny as Cadence or other software compagny. > Maybe, Turbo linux, Suse and Mandrake but never Debian. Never. There is > no compagny to make the support, but every one have the right to do it ! I don't think that this parallel can be really drawn, we are in a different position. > Leon aren't "space qualified" nowdays and will be used "maybe" in few > years, not before ! it's not my fault ;-) > > Concerning nicO's remarks about integrating F-CPUs everywhere : > > fine, but woudln't it be an overkill ??? there is no "short" > > version of F-CPU (32 bit support is not under way and it is discouraged). > > I know no 'portable' application that needs fast 32-b arithmetics. > > When it is really required, a 16-b or 32-b µC does multi-precision > > operations. 32-bit SIMD would be used for real-time imaging > > and sound processing applications (ie digital handicams) > > but the devices that do that are often made in Japan with > > highly proprietary chips/ASICs. F-CPU would not help much. > > ARM7 is a 32b device, so ? In few years, will have 0.07 um tech, 64 bits > cpu could become common. i simply wonder what application will use it. I'm simply puzzled. However if that happens, i don't know, but that could be really crazy :-) > > However, it is useful for small quantities > > (around 1K-100K) runs concerning high-speed control, such as > > the SCSI or IP router example. Small companies would adopt F-CPU > > easily because the price tag and the independence from the toolset > > are "attracting" (to reuse your word). I think that it is where > > we can seek implementors. > > Yep, if they can earn money, and there work will not be stolen as > explain by Michael. this means that we are in the case where the company's "central activity" is not making CPUs but using them. > But i think of another think of the GPL. Sources > must be delivered with binaries but what happen with chips. Does a chip > maker should release a chip with the HDL code ? It's not a binaries, so > does the compagny _must_ distribiute this code ? or it must be done only > in case of IP (no more SDF file only, IP), which is more directly link > with the sources code ? 1) If the company uses a F-CPU core 'out of the box' and surrounds it with its own "meat", then the SR_URL must simply point to where the source code was downloaded. Modulo the definition of what the core is. 2) If the F-CPU core he uses has been modified by this company, the company must upload the changes on his server and change SR_URL to point to the new address. I think that it's a reasonable deal. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 14 23:50:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3tA-0002Ns-00 for ; Sat, 15 Sep 2001 03:04:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:56 +0200 (CEST) Received: (qmail 2333 invoked by uid 0); 14 Sep 2001 21:51:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 14 Sep 2001 21:51:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ELpK913753 for ; Fri, 14 Sep 2001 17:51:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 21:50:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ELobn13288 for f-cpu-list; Fri, 14 Sep 2001 17:50:37 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ELoYC13272 for ; Fri, 14 Sep 2001 17:50:34 -0400 Received: by moria.seul.org (Postfix) id 07C7F1462F6; Fri, 14 Sep 2001 17:50:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by moria.seul.org (Postfix) with ESMTP id 8C31C1462E9 for ; Fri, 14 Sep 2001 17:50:40 -0400 (EDT) Received: from f-cpu.org (nas1-152.ras.club-internet.fr [195.36.192.152]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA26089 for ; Fri, 14 Sep 2001 23:50:30 +0200 (MET DST) Message-ID: <3BA27BA7.7C9B1BEC@f-cpu.org> Date: Fri, 14 Sep 2001 23:50:31 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <20010910232506.08553@thrai.stud.uni-hannover.de> <20010911194649.40695@thrai.stud.uni-hannover.de> <3BA00961.63249D21@f-cpu.org> <20010913162221.20357@thrai.stud.uni-hannover.de> <3BA2AA31.9CF2DE31@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Michael Riepe a écrit : > <...> > > > My current view for a "decent" F-CPU chip is : > > > - SDRAM (DDR/whatever) direct interface with the core > > > - onchip L1 cache (low latency) > > > - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM, > > > so we can do very wide SIMD computations > > > No, don't mix things. I think as leon. It's like a canonical cpu. Leon > are core+L1 cache then it used AMBA bus to connect memory controleur and > so on (UART...). You could what ever speed you by enlarge the bus. > Wichbone coulb be extend 256 bits for internal use. > > So fcpu core will only be the core+cache(unified or separate). All > others things could be include in a "plateforme". I think about > controler, L2 cache but we can add interrupt controler and so on (IO > quick link ). Imagine a router, it don't need SDRAM. > > So to the outside world, we could have coprocessor interface (as leon ?) > + bus interface (wishbone). That's could clairly defined API. we have no defined interface yet. I don't think it will be necessary before maybe 6 months (optimistic) because we have to completely design the "execution pipeline" before we can do the memory I/O. We have enough time to discuss this, obviously :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 14 23:54:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3tB-0002Ns-00 for ; Sat, 15 Sep 2001 03:04:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:57 +0200 (CEST) Received: (qmail 5149 invoked by uid 0); 14 Sep 2001 21:54:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 14 Sep 2001 21:54:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ELslY14001 for ; Fri, 14 Sep 2001 17:54:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 21:54:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ELsHk13771 for f-cpu-list; Fri, 14 Sep 2001 17:54:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ELsFC13768 for ; Fri, 14 Sep 2001 17:54:15 -0400 Received: by moria.seul.org (Postfix) id B70CF1462F6; Fri, 14 Sep 2001 17:54:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.seul.org (Postfix) with ESMTP id 4CE871462E9 for ; Fri, 14 Sep 2001 17:54:21 -0400 (EDT) Received: from f-cpu.org (nas1-152.ras.club-internet.fr [195.36.192.152]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA29165 for ; Fri, 14 Sep 2001 23:54:13 +0200 (MET DST) Message-ID: <3BA27C88.43DF7D09@f-cpu.org> Date: Fri, 14 Sep 2001 23:54:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] server problems ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N it seems that seul.org has some problems, the post are rejected but sometimes appear with "root", i don't understand. Seul.org changed the mailing server to Postfix (that's what Roger told me) and there might be still some problems in the next days, i don't know. If this post gets through, have a nice evening. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 15 00:32:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15i3tC-0002Ns-00 for ; Sat, 15 Sep 2001 03:04:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 15 Sep 2001 03:04:58 +0200 (CEST) Received: (qmail 3403 invoked by uid 0); 14 Sep 2001 22:33:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx22) with SMTP; 14 Sep 2001 22:33:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8EMXIt14752 for ; Fri, 14 Sep 2001 18:33:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 14 Sep 2001 22:32:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8EMWgD14502 for f-cpu-list; Fri, 14 Sep 2001 18:32:42 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8EMWdC14499 for ; Fri, 14 Sep 2001 18:32:39 -0400 Received: by moria.seul.org (Postfix) id BE2651462F6; Fri, 14 Sep 2001 18:32:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by moria.seul.org (Postfix) with ESMTP id 60ECC1462E9 for ; Fri, 14 Sep 2001 18:32:45 -0400 (EDT) Received: from f-cpu.org (nas2-19.aub.club-internet.fr [195.36.133.19]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA02501 for ; Sat, 15 Sep 2001 00:32:35 +0200 (MET DST) Message-ID: <3BA28587.5130BB38@f-cpu.org> Date: Sat, 15 Sep 2001 00:32:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] binary streams References: <20010914173149.F5212@seul.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Kim Enkovaara : > On Thu, 13 Sep 2001, Yann Guidon wrote: > > > > > by the following code : > > > ... > > > > variable c : character; > > > > > > I think this is the problem. Define this as bit_vector or > > > std_logic_vector. After that binary mode reading should work. Character is > > > defined differently. > > > > i am not sure to understand what you said. > > > > I have already tried (well, with simili) to output std-ulogic_vectors > > and it uses one byte per bit (each bytt represents the different possible > > states of the corresponding bit). i don't understand what you mean by > > "Character is defined differently." I have read two (rather exhaustive) VHDL > > books in the subject and they did not address that point. > > For character definition check the VHDL language definition. Character is > defined as: > > type character is ( nul,soh,stx,etx.....); yes, i have read that. also, i remember that VHDL'87 defines the 7'bit ASCII code while '93 uses the whole 256-code map (IIRC) > In some simulators I remeber seeing bug reports about the behavior of > character when considered as just byte. I just tried with Modelsim 5.5d > and the character version works just fine also. glad to know that :-) > On the other hand > the version I tought (type foo is range 0 to 255) was little odd. It read > whole integers and didn't even complain that the values were out of > range, but that might be OK, the files were identical. I don't have LRM in > my shelf. The bit_vector came from one of my old test benches and that > actually was reading bits directly, sorry. > > And about VHDL books, the only good one I have found is "The Designers > Guide to VHDL, Peter J Ashenden" There is a new edition of the book also, > that just came. Graham has the 2nd edition and it is very good :-) There's another one, i think the titke was "Designers's guide to VHDL" or something like that (dark green book with around 600 pages). This one is almost exhaustive and also helped me well. > And the Students guide to VHDL by the same writer is also > good book, but quite limited. For synthesis the best material is from > Synopsys training courses and FPGA tool manuals. these are not free or available to the non-customer, i presume :-/ > ============================================================================= > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian > Vasamatie 1 C 16 | IRC: embo | curved-space fault in > 02630 Espoo | | write-only file system WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 15 12:16:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGS-0000ee-01 for ; Sun, 16 Sep 2001 09:22:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:22:52 +0200 (CEST) Received: (qmail 31793 invoked by uid 0); 15 Sep 2001 10:17:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 15 Sep 2001 10:17:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FAHN926963 for ; Sat, 15 Sep 2001 06:17:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 10:16:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FAGqH26620 for f-cpu-list; Sat, 15 Sep 2001 06:16:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FAGpC26611 for ; Sat, 15 Sep 2001 06:16:51 -0400 Received: by moria.seul.org (Postfix) id 991F61462F6; Sat, 15 Sep 2001 06:16:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by moria.seul.org (Postfix) with ESMTP id 204861462E9 for ; Sat, 15 Sep 2001 06:16:57 -0400 (EDT) Received: from f-cpu.org (nas2-111.aub.club-internet.fr [195.36.133.111]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA19017 for ; Sat, 15 Sep 2001 12:16:48 +0200 (MET DST) Message-ID: <3BA32A96.4A7DBD5E@f-cpu.org> Date: Sat, 15 Sep 2001 12:16:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] news of today Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Simili15b17 is working ok, even with more than 160 characters in the command line. Compiling the current files is almost as fast as with Vanilla. I have added a set of script files that automate the compilations. They will be uploaded soon. I am now cleaning the random package and i will then finish the clock unit. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Sep 15 19:59:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGT-0000ee-00 for ; Sun, 16 Sep 2001 09:22:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:22:53 +0200 (CEST) Received: (qmail 26221 invoked by uid 0); 15 Sep 2001 11:48:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 15 Sep 2001 11:48:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FBmZl28261 for ; Sat, 15 Sep 2001 07:48:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 11:48:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FBmD628009 for f-cpu-list; Sat, 15 Sep 2001 07:48:13 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FBmCC28006 for ; Sat, 15 Sep 2001 07:48:12 -0400 Received: by moria.seul.org (Postfix) id 1245E1462F6; Sat, 15 Sep 2001 07:48:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas25-134.vlt.club-internet.fr [195.36.224.134]) by moria.seul.org (Postfix) with ESMTP id B76181462E9 for ; Sat, 15 Sep 2001 07:48:16 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 22F5F171D for ; Sat, 15 Sep 2001 13:59:48 -0400 (EDT) Message-ID: <3BA39714.E27DA471@ifrance.com> Date: Sat, 15 Sep 2001 13:59:48 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Yann Guidon a écrit : > > > nicO wrote: > > > > Michael Riepe a écrit : > > > > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote: > > > > > [...] > > > > Forcing to release the files is seen, by you and Juergen at least IIRC, > > > as a problem. It is also forcing companies to open their eyes : releasing > > > their specs and sources increases indirectly the customer's self-help > > > and augments the feedback (if the company is open enough). It is a garantee > > > of stability of the product family. And remember the ALPHA fiasco : > > > Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied > > > when purposedly saying that ALPHA would be continued during decades) have > > > now lost money and time porting their applications. Now, imagine ALPHA > > > was open-sourced : the companies would be able to continue the work, > > > probably through a joint-venture that spreads the costs. > > > > > You all right but you miss one very big point. If a compagny have a > > problem with an ARM7, ARM will have a lot of trouble and pay. For fcpu > > nothing ! > 1) companies can have "problems" when : > - vendor goes out of business > - vendor "hides" pages of documents that detail "errata" > - vendor sells bogus stuff > i don't remember a few others but i think that i have an "answer" for > each of them : > - out of business : we can't ;-) and if that happens, the user has the sources. > - no secret is tolerated in the F-CPU. If an error is found it is immediately > communicated and worked around/corrected. > - at least, we don't sell anything. So if it's "bogus", read the 2) below :-P > > 2) even though there's "nobody to sue", how many companies do you know > who do not take the minimum precaution of writing "no waranty for fitness etc." > ??? Read a user licence from M$ or any "professional tool vendor" : they ALL > remove their responsibility. We are no exception in fact. > I stop you immediately : you speak about mass public software. If you use "big compagny program" it's a little bit different (SAP,...). But for hardware world, it's completly different, i repeat one more time : there is no patch in HW world. > other case analysis can be discussed. > > > There is absolutely no garanty. > excuse-me sir, but if your W95/98/NT/ME/2K freezes, will you sue M$ ? > M$ will ask you to re-read your contract which says that there is You knows it's illegal but you know that they can't be sue up the price of the windows box. So you don't do anything. > no waranty of any kind. NOBODY today forgets this clause. > Buying stuff does not mean that you have the right to sue. > The reseller and manufacturer have rights and duties that are > defined by the local law, such as replacing a faulty device. > You can go to M$ to replace your badly-pressed Window$ CD > but the contents is something else. > > > A lot of compagny will be afraid of this risk. > companies are sheeps. look at the stock exchange rates these days > if you are not convinced. > Hmm, you mix so different thing... Stocks are bought by finance compagny not product compagny... > > Look, it happen the same thing with linux : only > > Red Hat are supported by compagny as Cadence or other software compagny. > > Maybe, Turbo linux, Suse and Mandrake but never Debian. Never. There is > > no compagny to make the support, but every one have the right to do it ! > I don't think that this parallel can be really drawn, we are in a different > position. > Not really : Debian are free and is good quality but there is no compagny behind them. It's the same for fcpu compare to ARM. > > Leon aren't "space qualified" nowdays and will be used "maybe" in few > > years, not before ! > it's not my fault ;-) > It's juste to say that Leon are free BUT it will be used "later". And it will cost a lot of money to do it. > > > Concerning nicO's remarks about integrating F-CPUs everywhere : > > > fine, but woudln't it be an overkill ??? there is no "short" > > > version of F-CPU (32 bit support is not under way and it is discouraged). > > > I know no 'portable' application that needs fast 32-b arithmetics. > > > When it is really required, a 16-b or 32-b µC does multi-precision > > > operations. 32-bit SIMD would be used for real-time imaging > > > and sound processing applications (ie digital handicams) > > > but the devices that do that are often made in Japan with > > > highly proprietary chips/ASICs. F-CPU would not help much. > > > > ARM7 is a 32b device, so ? In few years, will have 0.07 um tech, 64 bits > > cpu could become common. > > i simply wonder what application will use it. I'm simply puzzled. > However if that happens, i don't know, but that could be really crazy :-) > You know around 89, the programer of atari ST ask them self how to use the udge quantity of memory of the 5.25 inch DISK. Imagine what can we do with 1.44 Mo ! It's answer you're question ? > > > However, it is useful for small quantities > > > (around 1K-100K) runs concerning high-speed control, such as > > > the SCSI or IP router example. Small companies would adopt F-CPU > > > easily because the price tag and the independence from the toolset > > > are "attracting" (to reuse your word). I think that it is where > > > we can seek implementors. > > > > Yep, if they can earn money, and there work will not be stolen as > > explain by Michael. > this means that we are in the case where the company's "central activity" > is not making CPUs but using them. > ??? It's evident : how many compagny make cpu ? Few dosen ? How many use them ? thousand ? > > But i think of another think of the GPL. Sources > > must be delivered with binaries but what happen with chips. Does a chip > > maker should release a chip with the HDL code ? It's not a binaries, so > > does the compagny _must_ distribiute this code ? or it must be done only > > in case of IP (no more SDF file only, IP), which is more directly link > > with the sources code ? > > 1) If the company uses a F-CPU core 'out of the box' and surrounds > it with its own "meat", then the SR_URL must simply point to where > the source code was downloaded. Modulo the definition of what the core is. > 2) If the F-CPU core he uses has been modified by this company, > the company must upload the changes on his server and change SR_URL > to point to the new address. > > I think that it's a reasonable deal. Yep, but does GPL enought to do that ? nicO > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 15 15:58:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGZ-0000ee-00 for ; Sun, 16 Sep 2001 09:22:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:22:59 +0200 (CEST) Received: (qmail 31287 invoked by uid 0); 15 Sep 2001 18:08:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 15 Sep 2001 18:08:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FI8rP01801 for ; Sat, 15 Sep 2001 14:08:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 18:08:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FI8SC01550 for f-cpu-list; Sat, 15 Sep 2001 14:08:28 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FI8RC01547 for ; Sat, 15 Sep 2001 14:08:27 -0400 Received: by moria.seul.org (Postfix) id 00C6C1462F6; Sat, 15 Sep 2001 14:08:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a092.home.uni-hannover.de [130.75.232.92]) by moria.seul.org (Postfix) with ESMTP id 38A001462E9 for ; Sat, 15 Sep 2001 14:08:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00639; Sat, 15 Sep 2001 15:58:36 +0200 Message-ID: <20010915155836.47945@thrai.stud.uni-hannover.de> Date: Sat, 15 Sep 2001 15:58:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA39714.E27DA471@ifrance.com>; from nicO on Sat, Sep 15, 2001 at 01:59:48PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 15, 2001 at 01:59:48PM -0400, nicO wrote: [...] > > > > However, it is useful for small quantities > > > > (around 1K-100K) runs concerning high-speed control, such as > > > > the SCSI or IP router example. Small companies would adopt F-CPU > > > > easily because the price tag and the independence from the toolset > > > > are "attracting" (to reuse your word). I think that it is where > > > > we can seek implementors. > > > > > > Yep, if they can earn money, and there work will not be stolen as > > > explain by Michael. > > this means that we are in the case where the company's "central activity" > > is not making CPUs but using them. > > > > ??? It's evident : how many compagny make cpu ? Few dosen ? How many use > them ? thousand ? I guess the term `use' has to be clarified, too. IMHO, `using the F-CPU' can only mean `running the processor' -- no matter how it's implemented. This kind of use should not be restricted by us at all, and must not be restricted by others, in order to maintain users' freedom. This is what the GPL means when it says `you may use the program freely'. Implementing the F-CPU is another kind of `use', but not in the GPL sense. People can translate/compile/transform the F-CPU source code, with or without modifications, and create pieces of silicon (or GaAs, or GeSi, or something totally different in the future), bit-streams for loading into an FPGA, or programs that run on another processor (simulators/emulators). Most people can't do that on their kitchen table -- they will have to ask somebody else to do it. That's the big difference between the HW and SW worlds. Since the manufacturing company acts like a compiler in the SW world, it can't be considered a `user' of the F-CPU -- it's the company's client who will be responsible for changing SR_URL and releasing his modifications under the terms of the GPL. In particular, the manufacturing company will NOT be forced to release source code for their technology libraries or details of their manufacturing process. They are not bound by the GPL at all, as long as they ONLY build chips for somebody else. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:41:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGo-0000ee-00 for ; Sun, 16 Sep 2001 09:23:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:14 +0200 (CEST) Received: (qmail 5580 invoked by uid 0); 15 Sep 2001 22:42:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 15 Sep 2001 22:42:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMgm608800 for ; Sat, 15 Sep 2001 18:42:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:41:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMfuj08475 for f-cpu-list; Sat, 15 Sep 2001 18:41:56 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMfrC08472 for ; Sat, 15 Sep 2001 18:41:53 -0400 Received: by moria.seul.org (Postfix) id 0EACB1462F8; Sat, 15 Sep 2001 18:42:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.seul.org (Postfix) with ESMTP id 529821462F6 for ; Sat, 15 Sep 2001 18:41:59 -0400 (EDT) Received: from f-cpu.org (nas2-109.aub.club-internet.fr [195.36.133.109]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA18231; Sun, 16 Sep 2001 00:41:29 +0200 (MET DST) Message-ID: <3BA3D920.5F7A780E@f-cpu.org> Date: Sun, 16 Sep 2001 00:41:36 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm , "Haneef D. Mohammed" Subject: [f-cpu] new scripts Content-Type: multipart/mixed; boundary="------------B567AC28C68E47996EDBE8BA" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------B567AC28C68E47996EDBE8BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, I have enclosed the HOWTO and the new compilation scripts in this mail. I ask people to say what they think, if it is useful and help with them. The shell scripts perform the configuration detection for the known tools and store the configuration in an autogenerated script for further use (it's a bit like a mini 'configure'). I have also found a way to ease the file management using bash's array capability. There are many (nasty) tricks so read the files :-) Btw, i am still trying to write a code that closes and reopens the input file when EOF is reached. VHDL does not seem to provide a function that tests the status of a file, so i am forced to 'open' it all the time and check the result. Any better idea ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------B567AC28C68E47996EDBE8BA Content-Type: application/x-zip-compressed; name="scripts.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="scripts.zip" UEsDBBQAAgAIAJYjLyu6v8/+yjMAAG6BAAAQAAAAVkhETC1IT1dUTy5mLWNwda19aXMb2ZXl d0bwPzzDnhDRDYCillpYbbtZFCUxrJLUJFWKivFETQKZALIJZMK5kELFRP/2vufc+5akVHY5 emrCPRSZy3v33eXcNX98/eLN9PW7jzfvZsvpYtcfHiyaIuuK3H2U/531K/fkiXtycvrsm9Mn z92Tx49P3Hzv7tf7VVH8O++Y1c3q8OCuaNqyrtxPr6bfHj8/xoWHB4cHP/+D/3CNs/9evru6 +Pju6sX1b7vtTbkoqkXhTg8PbtZl65blpnDy/+dl2zXlvMce+iovGvfq5Ys3s8ODo7JabPq8 cFXdyb1uXTTFeIZH8f6u+NTpQ4pPu01WVq1r623h2q5fLluXzeu+c926cC+n5+8/TA4Pyg5X 9M2ikL9WuVvX966rXd8W7kehqvxcb1pXVnKTPH5RV3iDvO+ywzLrpiwqrLGr77Mmb928WJVV JWQU6tauLbe7jRA6q+SltZxKvd1hbViAvtR1TVFM+OZ2VyzKZbnINrhF7k5uq4wYWFpYvds1 9X8WC6zmY+Hu636Tu015y4uaIu8X+iJZYLM/PCiWy7qRzcofM7ctq3Lbb/leefoC1wi/ODn7 q5s38qu8rIQf5HdCX3lKVpEQuHZZrnr5vbDJzN3Utdtm1d7Vy+W0q3flwtlrDg+2RSbEl1s7 HNVanudWhbw/r6uC790V9U5oIb90y6ZvuYCcJ/lT3buskS0VmwUOT5b8kARCe/K7Um4tVx8e 7IWi7raq7zdFvtJ3CBMUOKJFMXNny072ItSd6P0lzijrDg+UmKXnjiPZqXLUVbHNmlt3SjLW c9Badpq+XX54++4GS9oUWVMdHpBn6satyrtCfte2ddXO3GX3SJ7u2oXscbGeLmShwl9CKFcV 99hiIwTDkWcbkdt879bZHQ6u7ldrHMgxHxu2Jot7h4O5L9sCmxERIL0yt6m5wlJ4sinaDkTH rXKSWIpyeV1xP2+LbsIlFJ+y7c6YUpbTrpq63zmw6uxunW8OD0BIiMnLs/+YuXm/x1Mztyzu 3aquczev61shZbnZyPLbWiRys9OlkIi/TQ+cr7MdjudENYHncO7bJEWYsvhtD7t5KCEuK7dy AB3+fVfmuoF1uVpPhT2EBsLD8gK5AbImhFSNA4K8evvBve/nG+Fsr6pkmfKwI6FcJuLeYdVt XwrvijYZvRRxdq9FFYg6KEYijrxn4sqlcLNbiBwVomTdfVNS2kR1OdyS11vlrMJYyB8WuNLJ HXsnqkQECyqhLUX96dVhgyIZhweBreXCNZjPXisi96gTdmr7plCJlFtbr4IOD/Kaxw21U3Zr PrescojkXhSnHD9U20xsicNvhNmVjHKnSBMvX2aLclN2ZWESD25sir/1ZUPdKDRrVe3mRVuu KqEUFGzZ6QvzcrkUfqW2g7YFw9kToZTAe1tR5Z38L8N68XfcLzbMlIicYSHP9erRqPIIChtb LrItVHblauozoY+o6lN56C0XUWTtnqLAP7dDfWNMfDI7GbuP672y5J/xq7N2cARCqQZcoFfc Zzi5KutEWYreXNcwVvNikcnCcVJFfEUtrwTBNvWCNluMzUXf1Dthm3vKNh9YioqoRYXJJjNR Cx0ua+W5QrCZv0IF0BhmV98Lc/ciwJusWmWiEe/X5WKtTPhpB40ADnSqm+Vp1OT32V4PAJox Hkw2h4JeQO2LWrsr8NIbYzfZkbwGa63I2DQdOPG58L4wWqplhN3lEGHhShpQIX0p/4DWy+Yb ocxRt6bW062K5dDTkSOhzIy5NtrPvTDEp39tRUdXggSEOqChGVGlomjcgvrw8uLiIuFkHB4p BlLMCyUXJaD4NHOvhW6QUVFEbuq2ddt5YfvsxLA8PkhMYq9kuy+IhaiORThoFkBfpU5hkq9v F4U24UuwFyGUqHN5sO58U25LFZlssSh24Avdsd1BUCM2fENTbIJD6/9jVokuzvQdFERacS5L wBO32QlvHR4Ir6hqEIGgYIs17xdrsVdLfQFWiFPCPuv5XVn3LSGTavt5AFmyOEUS2y3h0Mxd F7sMKEF2jj1s6lW5ACPuscNlI+qOBBWWv5Wb5dqujdYDLIUTb/UhJi8iZ8Ih2zYI5JOxe10W TdYs1nvKoymjgQLlQdxl5QbslSh2ot5jGDhRP43Ib93sZ5AwNe+7bHErIgPTzWMnkvTa7uri 7MUPF3repNMIO6+rEaFaBEjHebEUoMUDAiZtJ2636Q2R3ry6fHn8/trlTXYvZGrJ+oWbCc7Q i7l0/ApX+v1M5AcnQEcWBbjXFNv6Tq+SR/G28eHBRQYxB7MKZKPsFYueq+grFbtE1YgIiLIv RZ/3meiKtp8HekyiPcgEPixK3hMk25+5QFpuV25eNOWuE9WA43h5/thxS8uyERlSgwx9PKam att+q8ZhrhtY9A1VDVW2CJ/q6nhbG7gudQ6gBY1N/KHJ9uRfDflEYXq0nYTG22I7V1gry5JV rkVXt5B50dQj5dERxV9UfqQd13UkKleg9aZoJmLLIB/yw/eX1zcTd/FBOeL6CmfghDvlPUJF CrDo2qNlIeAP17+5/qC0k3MqcO3TsUK2pt+Rb4pPEHn8JEp3JzooLzbuiFrZWPDdtWLopu4K 1crq4QC4XlCfcR+BZHBEChVO3LSC9heIKqpXYbKonLzIRYeqTTNDaCZcFgDVWu9EMkTVKvin 9wZL4B4bM86pIYFOYPXtSaOBRIz8GQHuwhhRQgq99PL6zJlpb6b6B6GRYHuxO4Li8WpiaZrC TbHs1JcBjpOd0iqpJ6U8Pkr2PFJOzuBXwcqYXVAfxTt3QeZvPAXM1FES8VfyGzwyLLdvRWBc Ki9yBk2/EIsfQYOcbLA7Q2gaZXzXlOJnwAzCOED5y4qgxB59+9SZ7Ya67lsC15bQe+TdRfkX QEYhLCt/2tVyrtB0QpoIoUyBigzAu3E/CjVFI6d2We1qsEOyfjODEzUqgAZhKVSwFBooMsHT 9dZw3zYTTQxrMYfL3WRyNN1UXgPnmMARS1CbPzFALOZnJUcsp8RlAqTLRTQcdfraaHMED5C+ EY8W250sp/wluEDq4uT1osf5k/VMmWVwTfHYsppuhMO80WpT6ikbGcsMngJMFK3F4cF/CA+U 3R78tuwb8ozibICUhkhmVwg7N8VdKadGqW/kLdPO3DMeKhhS1c8DKCxeq0D71RTY6xaXt/u2 K7Z43bzgv4uu34muFPkXK1dV2dodvbx+6Xwkp16a5ZBDWMHb+AiiN+p80mFeivcxl6fzIcEy EnDj/2zwlo0In+gv/OHf26LfIFqkLvJlXgDNTZKoRGTsRBsElU0zDDBEnjRPd14A1gpFCqO6 J4chHOCtI+EMQVOykGuBRptS3QADOw/YVzavR6hkl6eKq+CfqS4DfOilU0/cAgJ5XbRgR2iF 4CZpMEmDKx0w3FzYFF6jMMEEbpcL6yrVy1dzJ3vZBS3wbDyMnAw1QeLfWjhIdaNFulp3zr1Q 6khcqun7ApEMjUnpk03sM7coGgAWVeudgDGIKWzkVoAfQg2Ge72OFeKoQoO4J+pfvTj57Z15 cXBPlT1Sv+rw4LqEY0yxigxsflHrUXZZLTc9vGG+ULC5cBZ0cVgYNQL5QdyatqA3p5GpDUXb TF8EVbIT2SV8GNPnCsOUSBAdRgPF05GlwAQLyx+Nts9GY/NaxN7JK1ZFVRA+mH8qYplFyOaM DTJ5hihqXEfwhNfP/DkqmBxivwgrPweQs+2zcJJysjOAGMV3swfPKmbtWoMAjCUWTiEW2fPw wC+9teANNpnJC3Xl8lR9mDHSsTs690wVsCJ97YCFj/njz/p2hn+GzhstY1Ou4MMJK/A1R3Mo F+JzvF9OdUzOuRUIE9cwJI7qb4gTsKzgm3IJlgBd5HWghwaCv3z3hLE+ZRUAur76EtUyxPvu NXQBFK/wciMGagT8l8Nguh+y24Kvos+/K9IICGLoNLlVT7xYL/2WVbVsStEocFWCP7OD1Akf 9rtcfZ+CUAw3HR7w567cwkhVYgvAtzjZXIDXbBZ0xfNxGoMuO7N0tH6V/EGBs2osH7o7JRn/ sxe9k9f31abOchogACVDNVwzrrKosngimcV7ym725ajZCma55V3YXQNrroRiGHvC94sGkfOQ M5gE9jb5u6wAQURL7i2eKxQQpVRB6cqKxEs8q3LKvyA7UfMN7MgOurRgQOBzG+5Op++x1HdQ N4EFwrXmK6wRh2nMXh2fvz67urm4mnWfOmN3v0zKC8TlAU6geyU6iwxtFimEbCIbOmCOwrRr sG/QC25LSiGwKzgXJBYdNDX5kAea3ECyOmg6nEWHMGTLdyEIvX0mi4V1KZd2eVuI3Rfib0v4 EsJnxwPhHoA5rrb6FcGwwA0ZaqD78GSCET0/ZnWEH2cnLok0HMNM0/Iv4wnQhxScu9kUeUyb REoyNJZwjlIzqLyfgEOYXwAKFzdfTNmeQYdR2+8AB4Hg90WnJNGYBQw9w4MIvtf1bVDUFkK3 GGVuGrP1Hgf33Vd3RalcUDcICQg99c9K7C1Eif4M16tpCduxRnAyr4kDkOIG6H7odRq30a0q Z27SCDKtnce062y3I5L1pwm5L6uEq1MGM5sbgj8WnkpDbsZcReLb0/mHyudLA5kZkVQk7yMs tgPbksEicbngCCReIGMBYmAvj9/RMlThvAMsxwoLxQ30vNyibBZ92XkaBReNa4UfrSGKo3hW Gko0TZq6sbxQdj9ioHPa70YCb9+KPyzq8MaeJk6TRTxkybJrISmiyQJFsmqx9yxDpSxEtOBl UMbk/icu4kr8Ut7AKBkdIAJXZrSEO0UVdKJTu74iw5zRTxvEDEEbiwaEZ1roDoxd1cZUgsWb B8rGJ0ZjLItv/BizZDwxhM+CKfkqmBK1sPjt92qsQfxcHMj8YXYNDGz2WENWia1VZAuIuUKa I5jKlDc9kx8eHGXuvN7t4aiPTbh8dNa8xYERL2JUJ+YVRJdXCOgQJWS3MfkXfPWrgfIXaGva H/xPpjbhoPFSy533TFT4fEt6QjP3IgmIRmWDPOKiCxFSV5R09U6T5CHUFY8gg5shBvfyvaLk gA7adb1zJtTyl8pCVODVc1v1MGnt5RoBegZE81rjyDnCEvVup5F2v3mFZ3pIScRLw/utErnl PojvH8ERkANSs66xPKbG2m6/8XbN8iuw3hYll7Nt1Gngq2G96rLqWn17W8gV+eClIAy9T7IO oVHIgODtHV5v2fwjQUNBJI/zLGa8i0+lOszwReF7ihFrchH1e6941BLh6G7NMwYBLe7a7wCK qFbNzf1YzIf5T/t9VtXVflsD1nU7aAjv8PKd4tpMPFG88vaOF/UUWYACZIEySFBRrZlhlOdr zn0Hyx7iFOc/Xrs5scTLbOsD7oLuLSySkxF91N2cO9HcTLRq0jtrtpmAozH46YWSPLWPdEAW PgNH3mGmQZ1wN3TsB15/0CVfjy2vBesnvONWvSgPRFDaX/dmsSkq390GWrgCke5rC/efAgGL lQtxQiRMqRfkV/DBOwsOR7c+T9zTcKcddCvk2Hhjr1miaA+DoNlraN/rebH37AXVs/BSUDF0 xbRN09NLgzi10VMe5GtOobfVnlBrM43kkzs1Dmq0toQw3EsukKFQXEKUvGNmbaG5fOSxFusS YV1E9bzzyETURgXQAuVMqgBbdTSJ5kzSDyl3PBphHHjjbUiaWUz9pYZnkJyCP+QD6DnUaRoc D6kbN8oFy6xHIe1sL5B7O0bc5SyoHyD4QhHEje+yjcaxRCi/mc6FAUS4S8MvbxLEdvXu/RO1 5hBHZidNIpcm+lBa8NaNuGW3n7nvNZDFzKM3RHIKAM8Bx0Bf/+7w4L247tlKPbLMYSWyqK+e CUOKHKpVBgZilHsEzTNiJLIKbyb9RutSXDWEsP3jtdgGhJJHHB6IPW3ovBBMZ59YYcMUFwyf PCWkES1ATIZMuHQUkoptr9Umyp1t4E+yYwzOOobQxK5Y+D2JH5NNCZdasrWcVLbEz/cCUSh6 Pvc677e7VoUTwXTs0cyTpcMso+bjsIEzhrHKiM1qhJjyMudOmHFjCFyXBAUnSxBVF1XvxIfx KNOWvmYCFPC9XnaUHZpuwaIPH5sRI4KUA2w6CiF0Llg53wBtDD9kPnzuTfiIdlPOd4QIot6V CmSgiWzUAr/B09DQpZzUblfkU3jiwhi7bG6lEbPPkpSJs+HFnGxcbzY1koJuTu45xY3TX/3v +4tXl2+neOD0zeX5xdvzi+nf+w+PUheQiaCM0eQlAJ0n9XcByKeoDBZI6H1cNwFOyoPKLkmq ammMEQilM6/oX24GJTRtwVA7fiM6W4GEPIgwBqu49gf+spYn04Z+5wGXD2s/8S+xJ05E9fIp R5mZ4JpKdmwZhC7eO8N1X6TBg7QiHr9GSEhtUkx6a73DhM+AZf54efP63Ycbd/b2J/fx7Orq 7O3NT98FT55BD3piwuooTJC9wa7vGU+SR/xwcXX+Wu45+/7yzeXNTzAiLy9v3l5cX6OY0p25 92dXN5fnH96cXbn3H67ev7u+mDl3XZhfJU/4O5Re8rRoeYS9Nm3cPYrsTHNYFGVRlAj0ZsRl //gU+ZRsU6O4QRVwJOd3cPBEeibmLfuyxfR8eX8844lYwsVs4p5/624Kqv/3mww28RrFVe7p 08cT973YQFz5w5l7/OTk5GR68vTx1+7D9dnfE4/pxdsXv106ppA1YkpzxckL5x5HRsEIifeQ QAIveCDKyLJ6L86NviSilpL0fwu/jnU1meps4ZSqUGgy2mS/7GGAUEdEb8u7E97sJIEGhi4p kfSKqpWCDa1jzSAzMahc5MfZ/e2xoMLNMYoiaVwswKFO+DzUI9KP2OFsFB9YUAOlBGn8D2AG tQ4CLTTPJfDE1ydakaish0WNmjnZiGnQjEo5CC2pDtaVomZl0yu7WKSwA+zbyt6oz0u5K3+4 xLX4iMx70BULeYRE3FURBxyB8KyAFS2RUjl4ef0SpS9yDZWWokDm4uiZQI+pZ306Pf7nyx6f +LJHrV15UNfz255lFdALeyQKvMiWVMyMMXioYkqMdDJ3IDLPzJ5j9rD4tM7EPqGcFUeDWMI+ KbLV4EoIJhH51AgQWlEYoL53TKKPMAiKaASgKal6jEFiHWBfgVX6Snhys58guRwRAd6smTiU Ijuo/RXr3pF/y3JxTYQL5QYfWlzV6jCHkpOREEkgTAO04MuSfQ6KZY4AxkldbUA8odRlwvvo RqLoBm/yAqz5A8vNmGsdqqPnVobOWk75LcBe2UZslZYvUX97WGIBGtRj8N/eK+WVVo66oLdp TzNhAsDNnK/+2uwfoDcL89xraDXEZFR7a+aCLr0d5aVeAy+y1nK+Lx6giUQpBOqB1Fgoy10I 1ZCB7RvvL7JqmaW4GkJHSMsyK+uu250eH9/f38/EHFcLQUdMrGnPgpZIahF0RI/YaFOsoQVR iF1qER9RTuQtLUZtlYRJXhGX/l9c+8hLAZ9pGNyKOGNhrep7xoW0zlPjhxY/UQoJHpGHY2Na ZH7Po3l0B90ragvFRv/iBBuWjBPIW9f9ysoQllmjdHhYUDEz6cMCQ1iQZX41KierqfhUn5Lc QiyNUTd0rlU6GcSg7upuvxPPWD1cPiUH93eMzm6oQRE7LTZLq8FRLlzWC6oSVCCEkCbfZIZD HtR2fb53/qAs5BlrGPQY5BlHLfPI/3o8Pfn228dj1rrdF1pUIo/pW+988HbDyj1Q+cTip51l XTf741BVMyNtL8Azcn7uQnxQEddTXcko06iw8ONInwuXklIbshVWQi8rUDPBNdwX5qr5FAqD A+tyqxS6WRdpaRzLgZEdhE6U1+iaAIescPdL4WmYNHBJqiG1rNg/KbY3cHlHZVxO615/eHVh ad5w9PJvFdcVeMZdX766vnj144x3n4U6Bq1a7XzwmDUmEN77bMcHMkAu639/eX4WPP96kw9d NAJfI6G2isyzXG8skyiWhQa1oUALDywAXzKacGtqTKmAB1uhyPXZj4KagSG0iiimCaiqJrHa ugwajVEpxFZVm/GnEopGmz5cmtRq+9UK1QAI4T3IOdGGIEwmPMmlDkpJvDYOJYVEiM2izDaq fEbO1P+e12nBrwAb1N+ZrkFRGwrDmB8TZirRZMBUGAv8LeRvcUFfoduLD7Sq+ZaYZv28chn2 r6eYb/nsNuhEvxhZx8JylfP98OYQv97uxGcHaPL6d8/QK9wXvQY2EuXpx6KG6Ht1Dy6nWvAr SIgkolsvUUkAxYlQzHBxyPeChaEhLROvVYohypY0u/huBF87P9CVoMRIbGamLIWqz0G1QyiB 43KNMqr82V2hNrlkAVgICnnzoPfsNL16JGRUNYdKTzbaIX4r76whsLUVjy+QgFrIARbVXdnU 1ZblOzextvsHVIIKPBQcRIguAIXZUbq5toTJcBPnormhVZGuqmnyifsQPE5zk4NDnu+TThkG rQmNaT4N7yf5fbHBvkLKGsaqohhUY4WbyLGh7k9VLdaOiJDiikZ7rkzHOtSl+lqIBMQyljp0 1+ei2Rqqk+0E7oqeQgkkeGcgDAVOBoK8XvbxZuUOYCKUIiDsfc6rQABFzBS4zFWwwLJEkfRB wx5o/qH6l0+xo2sS47ED4tqrNM8Uo9xz6j6VOBjvrlisKzwc9YqAdappzmu4pQyCnEJdvSmr /lPig+i2X52fq6nwrD6xY+aFBAC70qdhxE+6BeSBXIXGn6kvW/UqvGGyMQZEWuCdzN0yhl5v LK3s6RREzPRFVQDF0FabF1owxn+/ZnldxNx5DUiXeS6JPllIALHQ2dJTC3XmYMiLalUK38HZ HJlifESfcwfxTHgM/+8JunmuL3+4fHNp/8QvzGWyUhNiOF6S4Eo5CQbr72K0zHKbkC9zLQ8P QuD4b6wPLa0JRvEO8VLY17DkRiu/rfckqvYvtMO+f5NccxSqm8aOKYeHLQ/3ZfX0CS1VbBws tTYDKWuLcMmT9M2U9CPZ0Yg/zYWuozH/okjYnHH5t0k87cGi46+QQKk3xZQLIaY60iIYX5vM ukSwsCCTpq8q6z/K3It31yIHnxTMROMmCBW8OdJduGy321hybZyuYZm1ugBfyCmuoANykVPR tJzW48dKUl8kkWau2rFtQj2lB1eH/l69KtuwPyhxq3zQmb8qId7aAyHgJlT1h+YhbhSKnYTS QpBmK8hOny6yWOxQmF91MYssqCpnhN1pzDTruzVsrsEwpHhrej2MNmvFtTxb9YR3gh26d5Nq BfdiUGalcUEL+tCZzAOtRll+p7+BOkWjRGinrSs+PBhOjZdAJrQexPc0JVGKrYJAiw9aEVFs MLjR1JyY0NU+Ose2ZUicVYpqphmaj61e5bFokaVm47Z9RWaJYcpY6Yokb3ZXN75NKTHoIc5v TiIyzUXIz8zpz/pihFD5k+RyWBIHrygmHjQfdcRgl8UtAlUpP11pYEIrziwpMrDn41lQYOh/ +kiBuEzIRgHOxqEO0OoStQbwoTvd7re7dV3tizybyQoAvHJ/YzsTO6d9/UdqJQiwfQT+y6Uz OAhIgJZonzyfn3w9Kz6JrnnyzbOv//I92Ho+Fl3Nphqme+Pi6Osy8xF4Ad0UlBcGZGV12x3z gE59XAZKFg0caEvMpgwUFHSMqC6zstmoeS3FIvcQE3gki7ETL7art6gz1iIOsdVY5Wye2TyB pDhLzRG2EDxu2UW3nsCdBvaBRGmRXbbXmPEwsLIQ/XVrO9DbWxJMJAT+jne5NM0UkKCFmITi WHM+joWPFnAFx7FwBCdlBXz0RD2J79XJJI2Uelv8NKx/xE3DHcb8MRP6m3LeiGeNNypFmFe1 J0L+Jt71waNUX7mjl+9fnY0DZooP0dr2y5uzNwQYiosIIPFIFULy4VBZ71B/u1XMZzFM0ih4 VjHOCU+ZKSA8hZwUIxWkCMsTfSHnQBEePceohB7uNIg9TtN9eJpYrdc3P7xxGrhKZPPp2H1o QXKIo4ZLzEp91hZzGqxcd19Pd1nb+lJqed7jqXu3K7xtNMuaBqp9yXfKJ0eISSIhxmqL9C93 QnI9UVLY6ivAbDgzlLLUd9oLdHhwMiVDjVAFvnPbPT1//GOUxkbIRaHpVivGS4YlmQLy65sg ni67ePTN18E0LqBPV70uWWBALF/XtfuzHmv9tkZ2GURMWq6sSQf2VUyfQHfnq1fZxWou+Jer OidO92asQvERXxKZXWB6eQSfTrGjDqiQvUafONaub05SHvwz+4hgdkhDxyqM0OHAut1YSs3S 0/GgcMoaxamrWmVZcDSqjO7VA+b9J0++ns736EWASR1UgaZ8EglpK+J6hDZPBDvsBcnzcIuR 6d1Y4KIbHSS609pxK+wEkdkR0HcoaLLrk+wFAltWA2JuEJY1AcOzYoJUL/QwlR0z67fRU0WZ iTsa/WkEoo/+32g8+1Ktke+isyz8kRoLA5tjfdYcgzd8z4X1wScZdyNP+5Cz1fgH266l8jfr ItYZlWhiFRthnoJ/6EgV+ij4Pxm19lVfWREYh5FApxj2KBsdLlN1Udtan3GiVp6NrfvJYP1H sNep8joOSJyyhQm2V/P3KNAPeUtApPQJNjVFUZDw0weEjJcb+WffJBX8lkQIBueetT9Csh2q fwbtcpYA4GiQVnPzuPpROzDOoQfJZ4yi782c0SzsGI7Z+aAUFvsVvXhlnoOtR3DL8BXB6vmQ cHSFzOh6P4FxK+2nCmA/qFizzLrDqvAAqNVHpLFJjUuynB0x65gV86diVFTWl/9CVb4+2TDh Zj9zfymKHTpLNCXCcmIn+hj1tEmJY6y5tyNN1CJiCXcWitH70f6vC8jLHNsOy9LHBBD8gGwB A2qk5PRXnqIuHtJ9j8d6S6ClZ75lySSQPyzx9BSzPERuhqisMoPS0GRVu7Qqkxhxt7QtQ4ra pSL4Se9eIpA+lxOZGXEiAyII1N6m94WemL7zxxpAVVtrY82qDng/kvkosMn3pSInB1dqIu7W 3BXdYpYaq9JH4s1ZToLVPJ+Ktev6kMuYtVMBLhmd0M6f4Kz7cA9lGE/tDeVE3iZnsvx/Xtdd EtMc3GMdK5rJIh71zZJoztFImdiLVmDc2c3JV6lH0qp5RnW2yURVh+TiokiovOu7lLCkaoei 7oVatkh6DdRpoXxSuO09sqSxbs23aGDHiVVDdidoqC+U0KOy2qpGUdXF2RPduvXQPi7BN/nR ZMOmopF0nOyGhI0SGDYWXaamYD+ocMZAMGF7Eo5H8EShzdik9MbnMoWQ2MYM21C7OCw1S9Cw yezRvuj8Y9JcBhU3PIraaQkzuX5YTmyqqI4yIHw22jIGh+xYMopIMTUeOrFBBizEtEEupki8 jrPqGHQsiUQcxx3x/cmgMp+2RoFI09QMeLqnU3fN3Bh3HG72eHKUN+LDjYysWomOXe6ZDOFA Oi3QTw1DbOFOvDRVfeAF9dVWhacDiv7LTwh47KIriSgAIEPGUy3V8YCSYweGsxFmpggx2CQd h6RF8Dq24+zm9QCil1WyS9NlSZX6aRy1979x3f+J/34vq//j4vSv38n/TMcmP/5Vy1XwG4C+ v6pd+6tw53cUnmdTr9i9NvRAyDAZB0XEjh6D2xMFksmy/vAnFT5zHKLboJcQsnB2AosQWvQh thE38OTdFp7AyvIFIVGG4NhG/SIT0+DmITnWaMbKT3rAe7QK8Eurm+bFvF9t25WbAiV9abHP p4bM6Ysj0IGD8AHLZI8jdxQa1gnjW/fncTTzCnL7RaiPCC0LnsIDNwUZTVMuWoBmTDSocLc0 SN/VKJjQFASUQOs8cHoeoGJmCAdUeIMsUhKSmnjg2nYcsQKrqQfb2gSlxNk6PDga4UmIG43G wRAFzwyVKVml9eCsFEhKQy1ALeDbwEtiRP/w/uOLY//g4zE8cZDnkezWR0y89UVWMdsWD+8e P+RdhXTmRYQGU5wlA3tG6Ksk2ZT3oUwxOlWtb3gJOo2i4Cu/vKMT8LXoDTNbSalAMtuLTX1D SDBsQpnNjgMPshV6dmwVcGHH8QJ/1F+N5VzjkgdNDF0Y+Mfc9ykbB8kVbE9MJM/ajCBxacxS qx21Gh0Z48ODdzfvXqcFN6OpVsaMvLipMsYAQvy6TcZ1cZzlDmaGcdoYCTC3alFb81RSeI5o ekhGsenZz5wig/qAzeEBfKwc8Iut7N8+/RnGSNyudbcN5SK2+V8xB4cH5z6PMgmXsvWjZd7Q 0zQMGAlciLkNMetoqy8rnx2GZ6t84ftD1NQc+dA5amkOD4wHoVqO87q10MCgrwYv0kqxvg2B jJAdODxo6lAEg3UFyJR06B3Ffn9B6mdWYJlEEo60GqUpNlkXJj+4hPPHvlaNw8DMGqajZ2yz OqTGK7aRoFjVocd5cXcskD6vt3bwkNesYVRdY/mqVKCA9ltGRcsHJA9e8ZPxYOSZ/RJu4/vP 8nmhtDZsuus2mln2QzfaWI+EpeI4zVOmbwzhEjjoa6DYVMMeH82JjZwvUDXdx7wL6zq+FC73 sxMy72YyXYP32n1MTYtfzIAUTgQlhflYB9CGUhsfdQjRKBsJpFNRrG4kRFxtzI4pfj7kCMOS +kZRnjagWN/1cEiQ5eRQxtdqhkUjyEhQbzn5S5YV+1FixXAaVPGdmjpUilyN59rEORWPtJdZ D0YLGE1X2WU6xo/pNureUG0k2NfzRHpIWvUTfPBgJCYPzc19xr4GEYNA07SvDQksOYnKGsNf E1LbGwQUgFEEE2xwhOOQMWHomAzJ224sVuf/rFTDLvxEwqTalHS32Dgrpq2MplafuoyhZ8rD w4TQZRBSgFkj3kTDmHQzYzfNmuXYlEcb8Rga7YRBoAqHI3AnfKSVhZ5MRf0meSc2zqCIu0uz Tkgpi+6Z+YbD4zuoou7nk1m3+kVzv6YKnj5+/Jfv1b/0Tetwf8x7QY7MUN3vw3GfZzaB4Fpt tCcvWrm/Tq4/D52vR4uoQM7PXmi5jXYjuJNvv32OYsRvdFlpyXnPNnmvSPxrtP4hKbwYa7T1 PKizQfB6GLkA4WPc4vBAfJ9XX4o62Mi2xrd0ejJHmCsotxO48+nul6W+5FiuI3A4LtvP6f3H P+kr1CO0pVbpzJu0m9a0SgpiZLHiP3xQt4aRhT/QsRG/p+wSt2xoNHX7d0Z7P+SUYyrNrVZH ChAkNyqUlT5/Ns/adbP4gm80EoAAfYcF/PG/ju3xp1zQaNBbEF7D+/w6/BvWdYozh2CR8a+Y qQKqUaAverNoGL6wOY2DqxB30hPLt2V1fHnjVv1ehec5Ej0dS96saH44yFPZCkbwvvYB2tZ2 jBZQ8wFgKlGN27h8L3ho+Fum4OeL55Zx2GZWnxszfT7opiH1+ybbsVHYG0L1COiGoFNTNx0i 68d+mA4HWJmyF9S9EmqM7u6++Xqkla5+sVb9gKVRY3NtgxkHE1YThqhpiGmX6pofvSjmgh6t tsGUQ8tK1C/mKMlAGLqMaXpyvzgV2FnZ2QCdhw3dWv3uh1rylqR8JtzhjQbnaJA4yFu0GoT3 IcUsnVHFVAOyBKTK5IsOvogw/ur+LdzBP9yskyjQwCM0s+vNPerJQrA6MQ9Px5rKYOAEb0tq V5PoTXzJ+2t4dYggevrAUrNGC7EOThj29VZWx6xNtotmLxytIooGnZcAqTBecJisMkSnGRki 8cdMSxo9OJIBvxsSil50FxnZ3BUYN2Ih1tmPFBjQIilP7N0jMNqsrWfPH438WHidlfS3Hnl5 lAbUuZYeJMccwvnex0wT6fZsnx1SZwer5eJD9yvPyz4p0IZaKmH2ZqJZEC2lgxBpMlFAklb0 BBieTGL1ST3ZLV4TsIhWH+tnD4odGdHmnP+DEM8pTbi3OZ+r6gfTdXnTUQtvQCy2wEPzclVU 0vgjIWXRhSAbkqTrkmNcmHKepP2V7Cvw45hpPa96LytqEPyVafGYXMEZqr46D6QeWXRqBEbV +BOLK3znmnaFxFo5L2mzIGo28mRt8yhz1O8stSQPSXaF7+OHPgujJPq+B5lqDnFV/pZ/jge5 2XmB2pdgxO/+5La3d8JYFIWwovSBSgX/rQ91ODSubyMCktANdFAy/CqJT8RYsHGDjoaq1cdX TcvqY/MYuIUYIRgrUvlpOPsncBawQpmEDb34kuFG2/7T7G6k9L6oOj+cOTRAB21ptt1iYWIl 978Ip+BunogfMWZeIoCLPCtsfxyqbHQhDDbJz12pbgT+KMzk3/HaYhtdTG7L+//rf/bf4cHD E5V/D3ZyePB7d8ZfYOsPCPR7pVDZ7U99LDPZAP56lrSpnwKNaDoHfxokUE/xNpvxF17Z0tN0 T5+wRKDVwZJWAknOfWxB+Yn8dK9DzSEnsodfpervYZlv/UQlrOO4b5vj/cqDsuO2y499bOfL V5RFUeCynzmH4ueTk6+efflCvPw4vPznn+P28b8LEfBak4ZPfXkNwMHJYwdnPwPi/1ptIvMO R4+dVafKz09Onn397JunXz37mr/8/8AJhMtv6/uYmLeZS8rR8702GHtbbEkUz90bn/Xnf6Pp 1Ik7euv+7Y8aDJAftbzgCTbxncpMUJswwDYq59ljBDg5YmCxX7BLZxDLH8Ww+QM+9b/2MhMu 9p4a3sLcHtviqNEZ+zjy5VR/HhtkZvyD+YS+Ciw3aKOwJcrfdRqKPKHu241GgF4ozA0O2Klv vVK1gepdw2SsHhzbZH41tj6cPHsAq6y4wxCV6JB6VaE0ME3b5f6VWuZvasLme0DtpNbEg69n CazHXRYKif45yRWDL/uiS5p8tHzcV+TOMMwrEimsPpn4pjuPxPCAfsxJUuzW8aYIu3Ajgc6j dHawIaWJLeBBlwS7gTmVK4zDvi2Zp01Gwb8piAuzpH436WTih4iyTWjWSsM29jdO9Eho+Fxo +HfC3aFuNnwUwwrvbKBI/MBDuUwDO2oQE7OlFbw2IXMyGLVC0uloBQ7lQfeNb5NwNptXeUoj koYHaQv99ypCLXFSPB4O3uaa2U4etR6Bs6ArxS4JORGrs7jfzHefctCSXebntxAchlvo0vn2 1mFhItKiLJbaDCYCM9ZrzJY0VIhfUS3YmiT8jFiazUkkDNeJf6V+/Cb9uBGVAluNYzHMFhM7 dl29Ozz44598vv79+Q/nl2cal/K/1wYGU2Y/nJ37nv3h36PTmAwKQhQdrSu+O6rWOUmyEhu3 GKZk+f09G+scfu2+qjunYyY5ha9MOoF9Lti3ZrHe2PdmoWZdJ8G6erHgmHA/gtVdajxO+zx1 BiIHGrCPp3M/cLKO1WbS1/qVgtJJzM3wxUIQ5vWrh2HMIFNIFWJ6eIfPq4VjSmrJvFSU3Vjv +GqsHcxCjkI/hvPPzTt4anoaX19gRHU4YuefGHfAWEloa9DBD+j7CKFitguZg8kv5Oi5xVFJ co8W2glJWbKjpyfiF+tzoB3RQMQWWz6F38nhh5asNAyOONtGIXgKlcazB4vEnFIWS3cPvltg n1gbzOv0w4b9Bz+Y6GZ//3Cm0tbO8ensRC0l1+snE/aau9JhARMbuj3l6Fqzq6QMpsC3g0Gd jM7vq8W6qSs1t2ok/WgxG/ylriY9pNjvZh/JsIYAT/K2juF95kWTxx8e+KUjl75ZTsM/4UOL Z01ngOvl2sdhSl4cMj9zo4+cSqBLZCPYUebeTrlUnTBmU3kOD8I+VsxdG7LalnmOPIevNTc8 WUJeTfPyox1aceoTXjoYo04MowbMNEujnZE2C4aWsrJ5Jx1Kl2Icg9vDkBLWIMtf7iyCFRv3 ay2zlb+3gx4ZTuu3Rk4SSefCJ9/i8K6ymWAyH9ql4tv8dpLUVqPo7GF2DzZfp7mgV/XJJ3vn oO30PTnsb32WNzpfy69LlWfsBeNgp0mK9xrfTWofklBTIdQ3W5GXABeo/e848uK+KPzcLHF9 w1Rm9OsQn9Y6I94msRHte5toZIjLCeQIpA30tMACel9cU3K6TvjOIKc4Ikmr3eElG+fqXzAt jkbfRndY2QZbOELJbmfTV/gim8OxsCl4ZeVBp8g91t0Uq5KtylbWzPFJMN5MaA1OwCPjKFiN YAxt/tIF//DumuyPYtxdthBERQNUu3W9eTBIcJV1oSrbhgaVlahHWcqY+7U0pOe42HvvBSAA RaupDrNUzRubhl430yNfECgdWDPvV0kdY5aLSRkOQo3fcoubR8t/nQdMb6wlL9GvnGnXrwsH ro2m1niGqLXume3m9byH5Ig6C90sYfZdFvv7gjw9qFkP2VEfZgbM1NgPcj+BA/n5TQ4y+Czq mcS95LYpByATnVBLxcBouSkXdeUpbPoEd/3NPltylGYpQMHGuq/EGu/QcrD33zBNGqpDiBYL F3b+5vH/ilPxfOMrJx6mBQym4fk5Jv1oSFLI6yt1NPuwJWXev3kzibX6RjN/ha95IL4z2bi+ ssqFMDqbL4KV3uTjBwLt50LH4B+fl3wKwdSx1jdqg4jOlGK9v7ZSpeMiPC8g19NygvOg9MjP YYl8/jmnAX9hfDV7pZR2kUamv5KRbZl7DtJT400CDb0qY6+PtmEsEzc64S/4RlaYxs3rhxY5 t3JmaI3Tl8vEPtkoS99Kg48AbetaI7oJx1+mQ0sotdZIEY9Lztfa/C26Hj9KdXhg4ZCB7tM3 Y1gLR7YjnXZXl7l+6FD+Wt76D2qAC3Xyj/2tR8swKr783NHMvUdfS7+9vLwUyYGumNcMQqVB 0nmJCGSV15Bobfk02ZjNbOR5aIm4lGXiY6mxOZkF3a2PON+v97GSMfQ6DWZCGpE4p90TPfXm BylX/d5hiqEmyNDDjRwxVjbST4C1Q9yGXI3NhGW4tC2aZN6h2KKpAlJfUdxa1d3nWtGEQoEN ZQJuMI10QFnQGVRUWvBuhmf4Pbo24Ncn4vUiS8BSHXxElV+f6fz3T2i4BUEyOAp+lVdwflYY qsrqE9lDq8YgcA4X7z/b0Rad/3KV/3uedZlqVv95vPuZDQj1JTfuCFhhPImD6jWX2fjxsB4C LBTIVxyNq73X1u6qLCXC0vKrbvxKh44AxyxU5VRqG09qzA/j9JnBZq4uri9ujByUYXFK5aBz q1ehs/xGv8/VoHWNZaeCGQjBORFanDyGewaiqJ/J89P1Tfv4Bw2++coRssx/5Ry1mnYkeD9D yebjl/5F/A5x0cUqaiZRBupFu810qA5Awk6hWtZNbONBF9u5aATLmzxSUQEYOpBG2rucaIH9 lwlzV2/gJMBKvNciDx9XS4ogMLegMSbcyco1h6aJVP+xFWEUX9x8Ko+/OncLjcGhv9Gq6Vaq S9j4en4+AW6L7XfkzOvFWlyRDvpztSKg8mhLiwJLrcukAzQPLXfekFqKjtJpI5J/97vfkdF0 /NPEB73Zp7QUTkQzolJF2MjgKpmljR/rMjIyh57k4Xz6W9anKttcDB41j8ICokkBm/t4IZx1 9vLm4so9fLKKQ9JFGLrvrACpTb82NhdKxsYIHfhhqkvZEiPd+AEpTefEDlggL5Ygyu82Pb90 wKJKfr9NOVfuV6ZjkRy0MiN/cT/6oVwb2737/BNRM9NontyeVn4Ao9I2dr76KWaMPGjO9aj2 JQcuYOk5T4xvvTw3tRbaKHTmkCpJM/Vj4cUrr0r5YnjrYdpQ+KCVZdmp3ixj3JoAKxVb68/y /jGm9eig9A3KQIoHxsb/Ns67UIWObS43vY3/jSqVQDWP30/8Z0JKCK0zZebx1cI3l3t+WMeP xf62ANPR2fX5JStuW7bNjPXX/w1QSwMEFAACAAgAuE4vK/7Fi/UAAwAAEwYAAAoAAAB2YW5p bGxhLnNolVRtayIxEP6s4H8YraD94FalpUVuoaX3Vihnqb3CUYrE3VlNjYlks1qv1/9+M9ld tb2D4/wQN8kz8zzzkjmoH02kPpqIdFarHgD8+NJKIY2sXDpIjIXILJZSST0FN0P43Lm8+Q73 Xz9e04VFtlhLN/N3hFwIHXcIjHAvtFRKeGjAsMiicBjDZythhEuAU+geD/r9Qf8M+t1uDyYb WM82U8TzpBMts8DYKdut0KbSaBgJ5+16J9A9GRyfDY5PvV2t6r3PMJqDTLyQGB1Gjo1kCkIR cbyBJVoKZ0EKBrUqAR+gQ2hjVBqgXsFjrUqmulYF+gW7i1oVVYr7x+PI6EROM4sBpyyR+wqY 3mKaKVeQNJr3F9+urq8vxqO7i7urywaEITQab/kwmhloADkxmYpBGwc209scDkBMjHVUg6BR GDxLB70dudHYSaRLO0IpSDLto6fr4gtWhaf2Ya36ssfZgg4sxJyr22r2Wq38ygt/pxtItdFe N0NYO9SqFYKuxNkpdJ6h2YNfMLVUok+3t8PbHFdiCQo71uFweDOCOqRmgW7G7GvUDtbWUIhB 0NqiizBLTxyuP/clYXLvT2ihNj9xK2K1IkX/1PJfUkollVIC/79y8in9d1T0xChl1myfOkt/ 1HiWT33HbZ+IzRRSOWNpqUGN3Yy1WGDYTqTCHvDa9+tYH3qWstMEF5Fg/C6K9gtWs5hK7U/M MjIxpvlRpEw03wcd7qIH/0bZ1RQ1WhmNRRyjzQ0tvV2zKE04au8qbOceixb6wyVmY2uW/bDN 6/h5Ikp3vM20dFuLigeLNAvbknhzGG3fu3RmqXCFKmyXXyWCW13J1IEpHnqZR+A8poWL8lRi SuL3U1iEnwdWKs/95mMOgejsJm8EmhM8AJ9Aami+7Hl9OH98ZaIDmpNCA7+5v6qJTa5oHjaf yIbwH0ICWqQJK4DahETwtugo4lI5V33+6sG0y52y9jq8peNG2Y+7ZMu7U2HYaD4dNVU+VnRE w1eLfCxUynHQZFxprZEV8/obUEsDBBQAAgAIAHtMLysCQ6KqJgQAAFYNAAARAAAAdG9vbF9j b25maWd1cmUuc2i9Vmtv2zYU/SwD/g83TgElwyy3w4INBhogaIPNQNYOdpZiGIaAliiLMEV6 JKVWQ398Lx+KJXlO+8VTAksQr859nXvI87PZmonZmuhiPDrHf/jzl1iDThXbGcilglSKnG0q xcQGTEHh4de3d/iy3DFOlZ5pVlacGKk0UFEzJUVJhUksUqooMTSDFTGwojt4dQUvr+avXs5/ vIJcyRJqopisNOwQSArCIUdMHeL4nVOiKZBasgwqbd3H9BMzMTCBgbA2yMTZ27/zE102GhsZ pBiSqHan9GR9KaqpcbVua08MkyLkOx7RtJAQn+87F8M1GCm5TrAFT+vwgShhy3bmy+VSwDup jCwRMSWcN7ChgirXpnXjQB5bpzTRBZwhdg98PGI5/AXTDD5KtYW/xyMMVIxHgJd3bJ9sEqWs rXdrNou9gSphunRvxqOcDcES3ZTfCGhND0Ht2z4wBUVEJgewbu0MpkVn1b73FlHXq5BYKApz 1w5XQUFKLFb4EMuJFkAAPXMmtlgvD2WDoFzTwzzcVNg89h8Z6eADpt7RlIVhCGhcwFTDLKP1 rApW/tZme1ryX/xTsXTLm0vIqKGpsQXEuWeczT4yQV3tNcxPGQR6dK6mGV1Xm1JvYIr0hUld ZHw3gc+wUagwk1VT7gopGrh9ewMXy0uvVm+CWs1WrVhNcGJcOUXF+QHjJr5T3RR94jSbBLNP O6lQ1Ra/Le4Wjx8W725fy2231/9pMJylAUF6biGTVIvYgKa0tAxxBJ90CDwV8KKD3ycxhKsS Vks6Znt6/h/M2fOlJoJxTsD2w/Plwou6beNOas3WOFwlCqy+PC2VOnG1QZlCyWpTAJcpSqF1 7yv8L7y4CO/Kbc3Z+vK4Pj0ELMe4oAstawYOErhZIzsw+yQeNPTh5t3i7u7mcXV/c79481xP +5b7th6jVTc+3OF9PjbQpyCZmBzka/GCbhU03dpAmdkPvF0KSD9cg6xMSbUmG9p+huZ+MP+w b+etbcYUupSqebRqOul82J/LjiijynfheyJtxTNrECrsaVZUMZ8ajxV23/TRWmWOwlj2a/da 7lX/mMFwdKOQid/LXK1d1aOnjFNip5dLkmE8a0VUczzPKCQZtrNeokOefSXZnKDSZbi7MRRM HC2jGnwwhftOG7vvt7aWfFHokvPwGer6559aMY3r63gQZqcfx0qZ527xuWLm+UE1e+1keO6s ROYjZhtBDB5G3Fn0MAeQecvsBI9Lkvs+d/CmUJJte26w9yfywbRj2ulnPCjE7XL5ftl2wne5 xf/OXt7Y6rUb+p5gw72UsCbZ96Alnh8lnmhxSVdpig1OEteC6Jnpj1pqRMcnP4rs3EetAEQh xm8hU8jakyYBkjEZJuUrqtSlwvO6tI/L/gw3n9NuP16zLGsk/ihPOcAnetoN5gtQSwMEFAAC AAgAlk0vK8lr6Jh2AgAAqAQAAAkAAABzaW1pbGkuc2htVFGL2zAMfl6g/0GXK6x7aNeWjm1l gcHYjcK2lz6McRzBF6uNr44dbKe7Mu6/T7ITlmMLxcXKJ33SJynX8PPLSw++EVqDVC5cwFdO tQEO1kFlm1ZpZY4QaoSbT0v4pUINe9WQFToj0ZHF4CS7hsqhCChhLwLssQV4B8vNdvVmu1rD erlcMaZrZcTcOBUxqw0s32436+3mfcTAFoSUBGA64Zy4gD3AQWk0okE/ySJRjdUJ1CGCJAas grIGlAehKQd5gRYdZd9QnO0kI+AtzAltrfYLNGe4m2TkaiYZ0LP4+2KSofY4NpeVNQd17Bwu fD3JDmqcAdM79J0OPUk+3e++7b7uyh+7759zKArI8+dkWNUWcqAIttMSjA3gOjPoScXfWxdI 7kXe4x9VgNVATNQUyiP44AhE9TqEvtDYl5hRp5EiUStJF+suJStXzFjDVVRyHc/SvIoUQ4GC NSTYvGq7vurFuZYaksW2lZXok6nStjqNQSlU/9DMNBzqiAadqkpuqEuOThhpm39csCudbdfF jM/y8V4McL52RoXBg7XXygceitj8oUjoxyOGG6wKfTF7Vl+f20CYIhKioqE0CUGR8YzuEmqe ehofXoMHUAamv0eBbz/ePTHXNW2LMMDL89+EpE1JnYrpA/kQ/kNBQIe0cwKojTRHfE0o5tKJ 6+r0FMF0S0E5uSt4TseNHJfObC/Y6It8Gv9h+vB6qtPEjcoc4Ly56SQheBI5Kg9+mqcxj+e8 +MIaUh+pEWnvZ+JslfTxnWaG6gJBNeTlbBO/Dvx9wdC1pDdfYS7xvjs2/ghzZsi5uy3MjfWB RsXB3NOPtQmQqqBt+ANQSwECFAAUAAIACACWIy8rur/P/sozAABugQAAEAAAAAAAAAABACAA toEAAAAAVkhETC1IT1dUTy5mLWNwdVBLAQIUABQAAgAIALhOLyv+xYv1AAMAABMGAAAKAAAA AAAAAAEAIAC2gfgzAAB2YW5pbGxhLnNoUEsBAhQAFAACAAgAe0wvKwJDoqomBAAAVg0AABEA AAAAAAAAAQAgALaBIDcAAHRvb2xfY29uZmlndXJlLnNoUEsBAhQAFAACAAgAlk0vK8lr6Jh2 AgAAqAQAAAkAAAAAAAAAAQAgALaBdTsAAHNpbWlsaS5zaFBLBQYAAAAABAAEAOwAAAASPgAA AAA= --------------B567AC28C68E47996EDBE8BA-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:42:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGr-0000ee-00 for ; Sun, 16 Sep 2001 09:23:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:17 +0200 (CEST) Received: (qmail 21752 invoked by uid 0); 15 Sep 2001 22:43:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 15 Sep 2001 22:43:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMhsu09684 for ; Sat, 15 Sep 2001 18:43:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:42:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMgck08699 for f-cpu-list; Sat, 15 Sep 2001 18:42:38 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMgYC08682 for ; Sat, 15 Sep 2001 18:42:34 -0400 Received: by moria.seul.org (Postfix) id CB1171462FB; Sat, 15 Sep 2001 18:42:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by moria.seul.org (Postfix) with ESMTP id 2220D1462F6 for ; Sat, 15 Sep 2001 18:42:41 -0400 (EDT) Received: from f-cpu.org (nas2-109.aub.club-internet.fr [195.36.133.109]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA18527 for ; Sun, 16 Sep 2001 00:42:32 +0200 (MET DST) Message-ID: <3BA3D95F.F42B39A9@f-cpu.org> Date: Sun, 16 Sep 2001 00:42:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [Fwd: [whygee@f-cpu.org: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that these mails did not go to the list. sorry for the delay. ----- Forwarded message from Yann Guidon ----- From: Yann Guidon To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC hi, Michael Riepe wrote: > On Thu, Sep 13, 2001 at 10:46:19PM +0200, Yann Guidon wrote: > [...] > > > Just because something is PD (or GPLed), it doesn't have to perform > > > badly ;) > > sure, but when you design something, you certainly have something in mind > > and that influences the rest. wishbone was not designed with the same goals > > as the Athlon FSB you describe below. > I never intended to use wishbone as the FSB interface, but as a kind of > "expansion slot" for SoC. we can see that this way, right. "extension slot", a bit like the ISA or PCI slots. not too slow, not too fast, useful to hack stuff. semaphores, keyboard/USB/floppy/IrDa etc. OTOH we still need BANDWIDTH for the external memory. > [...] > > > I like the FSB of the MP-Athlon... it's a fast point-to-point link > > > (200/266 MHz, using DDR), 64-bit wide with separate, unidirectional > > > control buses. It somehow reminds me of the F-BUS ;) > > really cool, but is it free ?... > I guess not. let's stop dreaming to code now :-) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- End forwarded message ----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:42:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGs-0000ee-00 for ; Sun, 16 Sep 2001 09:23:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:18 +0200 (CEST) Received: (qmail 5699 invoked by uid 0); 15 Sep 2001 22:44:06 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 15 Sep 2001 22:44:06 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMi4A09807 for ; Sat, 15 Sep 2001 18:44:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:42:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMghm08746 for f-cpu-list; Sat, 15 Sep 2001 18:42:43 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMgdC08712 for ; Sat, 15 Sep 2001 18:42:39 -0400 Received: by moria.seul.org (Postfix) id 3FDB21462F8; Sat, 15 Sep 2001 18:42:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.seul.org (Postfix) with ESMTP id 26BA61462F6 for ; Sat, 15 Sep 2001 18:42:45 -0400 (EDT) Received: from f-cpu.org (nas4-109.bls.club-internet.fr [195.36.133.109]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08694 for ; Sun, 16 Sep 2001 00:42:34 +0200 (MET DST) Message-ID: <3BA3D962.130766EC@f-cpu.org> Date: Sun, 16 Sep 2001 00:42:42 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [Fwd: [whygee@f-cpu.org: Re: [f-cpu] binary streams]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that these mails did not go to the list. sorry for the delay. ----- Forwarded message from Yann Guidon ----- From: Yann Guidon To: f-cpu@seul.org, "Haneef D. Mohammed" Subject: Re: [f-cpu] binary streams hi ! Michael Riepe wrote: > On Thu, Sep 13, 2001 at 10:46:14PM +0200, Yann Guidon wrote: > [...] > > > There's a fundamental difference between the declarations > > > > > > type octet is range 0 to 255; -- i forgot the `range'... > > > subtype other_octet is integer range 0 to 255; > > > > > > `other_octet' is a subtype of `integer', and must use the same (4-byte) > > > encoding, IIRC, while `octet' is a new type that may use a single-byte > > > representation (vanilla doesn't, unfortunately). > > > > i think that Vanilla trapped me with that... > > On the other hand, Vanilla groks this: > > -- same `entity blah' as in randex.vhdl > architecture blah of blah is > type cstream is file of character; > file x : cstream open read_mode is "random"; > begin > process > variable c : character; > variable lout : line; > begin > while not endfile(x) loop > read(x, c); > write(lout, character'pos(c)); > writeline(output, lout); > end loop; > wait; > end process; > end blah; > > And it doesn't stop at 0xff :) yes, i tried it (i think i reported it yesterday). > [...] > > operator overloading in VHDL is nice but it can become misleading... > IMHO, operator overloading is *always* misleading. Not only in VHDL, > but also in Ada, C++, ... you know already : i'm really a "low level guy" :-) before Java and VHDL, i never used overloading. Who needs it after all ?... :-) > [...] > > well this is plain simple. my newest idea is far ... better :-) > > i'll code it before i shout victory :-) > > however i still need some really random bytes for the "seed". > 1-transistor noise generator + ADC? ;) hell, i don't want to use SPICE as back-end :-P > > There is another problem though : When i reach the end of a file, > > i would like to wrap around. i tried to explicitely calling file_close > > and then file_open but the simulators complain :-/ the re-opening > > is not possible because the file name is still associated, or something > > like that. I don't know how to cheat/work around that. > > According to the comp.lang.vhdl FAQ, it works like this: grrrr, i don't have the FAQ on my laptop, what a shame :-P > file x : some_file_type; > -- ... > file_open(x, "a_file_name", read_mode); > -- ... > file_close(x); > > I guess the trick is not to open the file in the declaration, but > explicitly. it should be something like that, sure. thanks :-) however, the fact that the file is initialised at initialisation is very practical : it is like a "shared variable" and consecutive reads yield different results, whether we read a normal file or a link to /dev/random. I don't know how to solve this problem ... let's think tonight. > [...] > > I think that i will use a LFSR for the next parts. > > It still requires the possibility to input some bytes > > but the pressure is much reduced : /dev/random is very slow > > and not a continuous stream. This will also spread the randomness > > if text files were used in the input. > /dev/urandom is faster (but "less random"). who cares ? :-) but thanks about the tip for urandom : it seems to work on my debian laptop :-) > > However, if the LSFR idea is used, some variables must be saved > > between two function calls : i have to create "shared variables" > > but Vanilla doesn't accept them. > > I really try hard not to use shared variables, impure functions and > the like... it's only for the simulation. and if you don't like it, just use the "dumb" version that makes no randomness at all. it's very easy. look at my latest snapshot : there is a file named "random_clear.vhdl" which "implements" the package but it just puts 0 all over the place. > What about this: define a record type that holds the LSFR's internal > state, and an `update' procedure with the state (inout) and the random > value (out) as parameters. You can export both the `lsfr state' type > and the update procedure from a package, and you'll only have to declare > a state variable in every architecture (or process) that uses an LSFR. > *And* you can use multiple independent LSFRs, with different seeds :) nice idea but a bit heavy... btw, it must be a function (not a procedure) so that we can write signal a : std_ulogic_vector(whatever range) := random(a); --> btw, there is a problem with Vanilla/simili differences : with Simili you can write the above line, but with vanilla you must write something like subtype suv : std_ulogic_vector(whatever range); signal a : suv := random(suv'(others=>'0')); Vanilla doesn't seem to recognize the element that is being declared. --> enf of aparte If you add an external record, it must be stored somewhere. preferably in the toplevel, but then we have to include a "port" to transmit this value to all the subcircuits. ugly ! The other way is to add a variable/signal in every entity that uses random but it's still rather heavy. Maybe we can try with the generics ? I definitely don't like to use 'local' records. it must be kept in the package for simplicity and clarity. BTW i have found a configurable LFSR package in one of Graham's books. it will be used for the BIST unit. look in eu_bist. in another mail, Michael Riepe wrote: > On Thu, Sep 13, 2001 at 07:57:02PM +0200, Yann Guidon wrote: > [...] > > Simili gave me a surprise : first, it deals with bytes. > > at least, this is what the old version i use does. > > I think that it gives a little insight in how simili > > works internally. I tried to raw-"write" some structures > > and a std_ulogic_vector(N downto 0) outputs N bytes (not N-1). > That should better be N+1... oops. well, for N bits it outputs N+1 bytes. > One byte per (std_ulogic) bit is ok, since std_ulogic can have 9 values. > A packed (2 std_ulogic bits per byte) format would save some space but > is harder to handle. certainly. But as Haneef told us, there were improvements in the latest versions. I am going to install 15b17 in the laptop and see what happens... > > Second, given a binary input, it stops after N bytes. > > I compared the hexdump of the input and the output : > > input : 68 FF 7E > > output : 68 68 > > (that is : where the output stopped). I fear that it can be > > worse that i thought. Well i SHOULD update my local copy of > > simili. Maybe it was fixed long ago. But stopping on a 0xFF > > is not a good sign for a C program. I know : Simili is written > > in C++ and i don't know a damn about it. So i will let > > the experts discuss about it. > > C/C++ programs stopping at 0xff usually suffer from the `getc() return > type' problem (some programmers use C stdio in C++). But it could also > be the C runtime library (getc() returning negative values if the char > value goes beyond 127, which makes EOF and (char)255 indistinguishable). > But I'm not a Windoze Quirks Expert (tm)... i feared something like what you said. i'll try the newer version. ok, good night. i'll have to wake up early and go to the tax office etc... > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE, professional VHDL newbie ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- End forwarded message ----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:42:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGt-0000ee-00 for ; Sun, 16 Sep 2001 09:23:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:19 +0200 (CEST) Received: (qmail 23590 invoked by uid 0); 15 Sep 2001 22:44:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 15 Sep 2001 22:44:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMi9X09869 for ; Sat, 15 Sep 2001 18:44:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:42:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMgrx08858 for f-cpu-list; Sat, 15 Sep 2001 18:42:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMgnC08812 for ; Sat, 15 Sep 2001 18:42:49 -0400 Received: by moria.seul.org (Postfix) id CAEBC1462F6; Sat, 15 Sep 2001 18:42:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by moria.seul.org (Postfix) with ESMTP id 3F9C41462F8 for ; Sat, 15 Sep 2001 18:42:55 -0400 (EDT) Received: from f-cpu.org (nas2-109.aub.club-internet.fr [195.36.133.109]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08742 for ; Sun, 16 Sep 2001 00:42:46 +0200 (MET DST) Message-ID: <3BA3D96D.238F4F9C@f-cpu.org> Date: Sun, 16 Sep 2001 00:42:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: [whygee@f-cpu.org: Re: vanilla vs simili]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that these mails did not go to the list. sorry for the delay. ----- Forwarded message from Yann Guidon ----- From: Yann Guidon To: Haneef Mohammed Cc: f-cpu@seul.org Subject: Re: vanilla vs simili hello, Haneef Mohammed wrote: > > simili. Maybe it was fixed long ago. But stopping on a 0xFF > > is not a good sign for a C program. I know : Simili is written > > in C++ and i don't know a damn about it. So i will let > > Dont worry about what other *experts* say. Simili does *NOT* > stop at 0xFF or at ^Z. The problem you say in the older version of the > Simili has to do with opening the file in text-mode (an OS > function) which does all kinds of translations like ^Z is EOF, > \r\n becomes \n, etc. and nothing to do with C/C++. Note that > Unix/Linux has no distinction between binary/text modes....all > files are binary....whereas in DOS the default mode is text. > > If you use the latest Simili, you will see no problems with > reading binrary files (you may still have a problem writing > a binrary file with respect to \n (will be written as \r\n). i understand that well, and i just started to test 15b17. I apologize for my laziness to update my files. --------------------------------------------------------------------- to my defense, all i brought to London was a set of old backup CDs with an old installed Simili. From experience, i saw that trying to install Simili from the original package was difficult so i couldn't update the files in London. And as you noted, file I/O is pretty ... undetermined in VHDL. I know i am pushing the enveloppe very far :-) --------------------------------------------------------------------- > Before I implemented binary files, I asked around about > the std. formats for binary output. Turns out that there is none. > So, binary files are all done differently by each of the > simulators and there is no compatibility standard. There is > not even a little-endian/big-endian requirement. So, doing > binary I/O on anything other than bytes (characters) will > not be portable. i know. In the case there is no capability for decent I/O, the F-CPU package provides a 'failsafe' file that does ... nothing. I am conscious of the limitations concerning the files and you just confirmed what i feared (i believe you _are_ an "expert" :-D) > Here is what simili does... > > 1. Enumerated types with <= 256 literals - 1 byte > 2. Other enumerated literals - 4 bytes (treated as integers) > 3. Integers (regardless of range) - 4 bytes and it goes (byte0 byte1 byte2 byte3)... > where byte0 is lsB and the 4 bytes concatenated in reverse order > will recreate the 32-bit integer > 4. Reals - 8 bytes (this is machine dependent) > 5. Physical types -- 8 bytes (High Integer, low integer) > 6. Arrays -- size, 'left item .... 'right item > 7. Records -- quite complicated :-) it seems to follow quite "obvious" rules. hmmm... what about the "character" mode ? from the previous paragraphs i guess it is an "enumerated" with "256 literals". > Also, the format above is subject to change (if I go to > 64-bit or for some other reason). You can however rely on rule#1 > above for the most part..... i wish i will _never_ have to rely on them. "binary" byte input is enough. Thank you for your precision anyway. > Regards, > Haneef > > PS: Suggestion: If you just want random numbers why not use an LFSR. > It works quite well, is portable, small, fast, etc. I thought about that, too, some time ago :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- End forwarded message ----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:42:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGu-0000ee-00 for ; Sun, 16 Sep 2001 09:23:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:20 +0200 (CEST) Received: (qmail 27814 invoked by uid 0); 15 Sep 2001 22:44:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 15 Sep 2001 22:44:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMiIB09961 for ; Sat, 15 Sep 2001 18:44:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:43:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMh2Y08990 for f-cpu-list; Sat, 15 Sep 2001 18:43:02 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMgvC08909 for ; Sat, 15 Sep 2001 18:42:57 -0400 Received: by moria.seul.org (Postfix) id 1A6711462FC; Sat, 15 Sep 2001 18:43:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by moria.seul.org (Postfix) with ESMTP id 2971F1462F8 for ; Sat, 15 Sep 2001 18:42:59 -0400 (EDT) Received: from f-cpu.org (nas2-109.aub.club-internet.fr [195.36.133.109]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA06504 for ; Sun, 16 Sep 2001 00:42:48 +0200 (MET DST) Message-ID: <3BA3D970.6FEAAA08@f-cpu.org> Date: Sun, 16 Sep 2001 00:42:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [Fwd: [kenkovaa@cc.hut.fi: Re: [f-cpu] binary streams]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that these mails did not go to the list. sorry for the delay. ----- Forwarded message from Kim Enkovaara ----- From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] binary streams In-Reply-To: <3BA11B16.BAF60355@f-cpu.org> On Thu, 13 Sep 2001, Yann Guidon wrote: > > > by the following code : > > ... > > > variable c : character; > > > > I think this is the problem. Define this as bit_vector or > > std_logic_vector. After that binary mode reading should work. Character is > > defined differently. > > i am not sure to understand what you said. > > I have already tried (well, with simili) to output std-ulogic_vectors > and it uses one byte per bit (each bytt represents the different possible > states of the corresponding bit). i don't understand what you mean by > "Character is defined differently." I have read two (rather exhaustive) VHDL > books in the subject and they did not address that point. For character definition check the VHDL language definition. Character is defined as: type character is ( nul,soh,stx,etx.....); In some simulators I remeber seeing bug reports about the behavior of character when considered as just byte. I just tried with Modelsim 5.5d and the character version works just fine also. On the other hand the version I tought (type foo is range 0 to 255) was little odd. It read whole integers and didn't even complain that the values were out of range, but that might be OK, the files were identical. I don't have LRM in my shelf. The bit_vector came from one of my old test benches and that actually was reading bits directly, sorry. And about VHDL books, the only good one I have found is "The Designers Guide to VHDL, Peter J Ashenden" There is a new edition of the book also, that just came. And the Students guide to VHDL by the same writer is also good book, but quite limited. For synthesis the best material is from Synopsys training courses and FPGA tool manuals. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ----- End forwarded message ----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 00:42:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGv-0000ee-00 for ; Sun, 16 Sep 2001 09:23:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:21 +0200 (CEST) Received: (qmail 14383 invoked by uid 0); 15 Sep 2001 22:44:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 15 Sep 2001 22:44:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FMiNs09997 for ; Sat, 15 Sep 2001 18:44:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 22:43:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FMh9u09077 for f-cpu-list; Sat, 15 Sep 2001 18:43:09 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FMh3C09009 for ; Sat, 15 Sep 2001 18:43:03 -0400 Received: by moria.seul.org (Postfix) id 1AF991462F8; Sat, 15 Sep 2001 18:43:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.seul.org (Postfix) with ESMTP id 18EF21462F6 for ; Sat, 15 Sep 2001 18:42:57 -0400 (EDT) Received: from f-cpu.org (nas2-109.aub.club-internet.fr [195.36.133.109]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA00662 for ; Sun, 16 Sep 2001 00:42:40 +0200 (MET DST) Message-ID: <3BA3D968.E831FA5B@f-cpu.org> Date: Sun, 16 Sep 2001 00:42:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [Fwd: [whygee@f-cpu.org: Re: OFF TOPIC: Chocolate Re: Re: [f-cpu] Re: Project short description]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it seems that these mails did not go to the list. sorry for the delay. ----- Forwarded message from Yann Guidon ----- From: Yann Guidon To: f-cpu@seul.org Subject: Re: OFF TOPIC: Chocolate Re: Re: [f-cpu] Re: Project short description hi, i did not see that message before... Andreas Romeyke wrote: > Hello, > > On Tue, 4 Sep 2001 whygee@club-internet.fr wrote: > > > how much chocolate could i buy with 100K DM ? > > At "Aldi"-Discounter you get 0,1 kg for 0,59 DM... means 16949 kg usually, the kind of chocolate (say : "cocoa") i buy is much more expensive but is of far better quality :-) it's around 100DM/kg and it comes from Madagascar, Venezuela, Java... > Have fun and a good smelling damnit, there's no chocolate left at home ! i'll have to buy some tomorrow or i'll be sick... :-) > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : i had fortunately brought some "real chocolate" in London ! i searched "decent" chocolate and only found stuff "made in Belgium" :-/ ----- End forwarded message ----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 01:43:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGx-0000ee-00 for ; Sun, 16 Sep 2001 09:23:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:23 +0200 (CEST) Received: (qmail 8869 invoked by uid 0); 15 Sep 2001 23:44:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 15 Sep 2001 23:44:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8FNiZN11113 for ; Sat, 15 Sep 2001 19:44:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 15 Sep 2001 23:43:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8FNhu310862 for f-cpu-list; Sat, 15 Sep 2001 19:43:56 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8FNhsC10859 for ; Sat, 15 Sep 2001 19:43:54 -0400 Received: by moria.seul.org (Postfix) id 710F01462F6; Sat, 15 Sep 2001 19:44:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.seul.org (Postfix) with ESMTP id C60981462E9 for ; Sat, 15 Sep 2001 19:44:00 -0400 (EDT) Received: from f-cpu.org (nas1-147.aub.club-internet.fr [195.36.202.147]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA26135; Sun, 16 Sep 2001 01:43:49 +0200 (MET DST) Message-ID: <3BA3E7BC.A4F45B59@f-cpu.org> Date: Sun, 16 Sep 2001 01:43:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm , Michael Riepe Subject: [f-cpu] genereic_adder patch Content-Type: multipart/mixed; boundary="------------E456092FC521C86EFDC8BEF1" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------E456092FC521C86EFDC8BEF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, Here is a tiny modification to Michael's generic adder package. The newest version of simili doesn't like the way the agregate was used, but it is not too difficult to work around it. Concerning the different way to initialize the signals with random, i search an elegant and cheap way to bypass the limitation imposed by Vanilla. As written before, Simili accepts this : Signal s : std_ulogic_vector(N downto M) := random(s); But i am forced to write this if i want to use Vanilla : Subtype t is std_ulogic_vector(N downto M); Signal s is t := random(t'(others=>'0')); I believe that it is due to the difference of parsing engine : Vanilla uses yacc and the symbol table management is maybe not perfect inside a single definition. However, i don't want to define a subtype for every signal. Is there a solution ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------E456092FC521C86EFDC8BEF1 Content-Type: application/x-unknown-content-type-diff_auto_file; name="generic_adder.vhdl.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="generic_adder.vhdl.diff" NDU4LDQ2NWM0NTgNCjwgLS0gWUc6U2F0IFNlcCAxNSAwNDo0Mjo1NCAyMDAxDQo8IC0tIFNp bWlsaSByZXBvcnRzIDogICJPVEhFUlMgbm90IGFsbG93ZWQgaW4gYW4gYWdncmVnYXRlIHdp dGggb3RoZXIgbmFtZWQNCjwgLS0gYXNzb2NpYXRpb25zIGJlY2F1c2UgdHlwZSAnJ3N0ZF91 bG9naWNfdmVjdG9yKCh3aWR0aCAtIDEpIERPV05UTyAwKScnDQo8IC0tIGlzIGEgbm9uLWxv Y2FsbHktc3RhdGljLWFycmF5LXR5cGUiDQo8IC0tIGkgaGF2ZSBzcGxpdCB0aGUgYWdyZWdh dGUgYXNzaWduYXRpb24gaW50byB0d28gcGFydHMuDQo8IC0tIG9yaWdpbmFsIHZlcnNpb24g OiB0bXAgOj0gKDAgPT4gJzEnLCBvdGhlcnMgPT4gJy0nKTsNCjwgCQl0bXAgOj0gKG90aGVy cyA9PiAnLScpOw0KPCAJCXRtcCgwKSA6PSAnMSc7DQotLS0NCj4gCQl0bXAgOj0gKDAgPT4g JzEnLCBvdGhlcnMgPT4gJy0nKTsNCg== --------------E456092FC521C86EFDC8BEF1-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 16 02:04:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGx-0000ee-01 for ; Sun, 16 Sep 2001 09:23:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:23 +0200 (CEST) Received: (qmail 18728 invoked by uid 0); 16 Sep 2001 00:05:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 16 Sep 2001 00:05:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8G05Zu11966 for ; Sat, 15 Sep 2001 20:05:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 00:04:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8G04w411697 for f-cpu-list; Sat, 15 Sep 2001 20:04:58 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8G04uC11694 for ; Sat, 15 Sep 2001 20:04:56 -0400 Received: by moria.seul.org (Postfix) id BC3FA1462F6; Sat, 15 Sep 2001 20:05:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 8790A1462E9 for ; Sat, 15 Sep 2001 20:05:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02665; Sun, 16 Sep 2001 02:04:42 +0200 Message-ID: <20010916020442.56119@thrai.stud.uni-hannover.de> Date: Sun, 16 Sep 2001 02:04:42 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Re: genereic_adder patch References: <3BA3E7BC.A4F45B59@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA3E7BC.A4F45B59@f-cpu.org>; from Yann Guidon on Sun, Sep 16, 2001 at 01:43:56AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 16, 2001 at 01:43:56AM +0200, Yann Guidon wrote: > Here is a tiny modification to Michael's generic adder package. > The newest version of simili doesn't like the way the agregate > was used, but it is not too difficult to work around it. Yep... I had to do this several times, too. > Concerning the different way to initialize the signals > with random, i search an elegant and cheap way to bypass > the limitation imposed by Vanilla. > > As written before, Simili accepts this : > Signal s : std_ulogic_vector(N downto M) := random(s); You mean, you use `s' before the definition is finished? That looks broken, somehow. > But i am forced to write this if i want to use Vanilla : > Subtype t is std_ulogic_vector(N downto M); > Signal s is t := random(t'(others=>'0')); Try to overload random, like this: function random (bits : natural) return std_ulogic_vector is constant tmp : std_ulogic_vector(bits-1 downto 0) := (others => '0'); begin return random(tmp); -- this is the original function end random; and then write signal s : std_ulogic_vector(N downto M) := random(N-M+1); or maybe signal s : std_ulogic_vector(N downto M) := random(s'length); if the tools grok it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 03:55:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWH0-0000ee-00 for ; Sun, 16 Sep 2001 09:23:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:26 +0200 (CEST) Received: (qmail 32236 invoked by uid 0); 16 Sep 2001 01:56:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 16 Sep 2001 01:56:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8G1u4G15151 for ; Sat, 15 Sep 2001 21:56:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 01:55:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8G1tOa14904 for f-cpu-list; Sat, 15 Sep 2001 21:55:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8G1tMC14901 for ; Sat, 15 Sep 2001 21:55:22 -0400 Received: by moria.seul.org (Postfix) id 4667A1462F6; Sat, 15 Sep 2001 21:55:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by moria.seul.org (Postfix) with ESMTP id B523A1462E9 for ; Sat, 15 Sep 2001 21:55:28 -0400 (EDT) Received: from f-cpu.org (nas3-38.ras.club-internet.fr [195.36.203.38]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA07422 for ; Sun, 16 Sep 2001 03:55:16 +0200 (MET DST) Message-ID: <3BA40687.3C2A8A10@f-cpu.org> Date: Sun, 16 Sep 2001 03:55:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] curious/interesting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Following several links, i arrived to this page : http://sequence.rutgers.edu/sequitur/ it's like a reverse-yacc :-) it might be useful to compress FSMs or BIST routines, for example. Yet another new tool to integrate in your swiss army computer :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 16 02:14:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15iWGy-0000ee-00 for ; Sun, 16 Sep 2001 09:23:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 09:23:24 +0200 (CEST) Received: (qmail 422 invoked by uid 0); 16 Sep 2001 00:15:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 16 Sep 2001 00:15:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8G0FY312801 for ; Sat, 15 Sep 2001 20:15:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 00:14:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8G0Ekx12385 for f-cpu-list; Sat, 15 Sep 2001 20:14:46 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8G0EgC12350 for ; Sat, 15 Sep 2001 20:14:42 -0400 Received: by moria.seul.org (Postfix) id 672BF1462F6; Sat, 15 Sep 2001 20:14:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by moria.seul.org (Postfix) with ESMTP id BE2991462E9 for ; Sat, 15 Sep 2001 20:14:48 -0400 (EDT) Received: from f-cpu.org (nas4-87.ras.club-internet.fr [195.36.203.87]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id CAA02692 for ; Sun, 16 Sep 2001 02:14:32 +0200 (MET DST) Message-ID: <3BA3EEEB.4081CFCB@f-cpu.org> Date: Sun, 16 Sep 2001 02:14:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: genereic_adder patch References: <3BA3E7BC.A4F45B59@f-cpu.org> <20010916020442.56119@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Sun, Sep 16, 2001 at 01:43:56AM +0200, Yann Guidon wrote: > > Here is a tiny modification to Michael's generic adder package. > > The newest version of simili doesn't like the way the agregate > > was used, but it is not too difficult to work around it. > Yep... I had to do this several times, too. i'm waiting for your updated "MR official" version :-) > > Concerning the different way to initialize the signals > > with random, i search an elegant and cheap way to bypass > > the limitation imposed by Vanilla. > > > > As written before, Simili accepts this : > > Signal s : std_ulogic_vector(N downto M) := random(s); > You mean, you use `s' before the definition is finished? > That looks broken, somehow. that #should# work. i don't remember why and how, or where i have read it. At least Simili does it. > > But i am forced to write this if i want to use Vanilla : > > Subtype t is std_ulogic_vector(N downto M); > > Signal s is t := random(t'(others=>'0')); > > Try to overload random, like this: > > function random (bits : natural) return std_ulogic_vector is > constant tmp : std_ulogic_vector(bits-1 downto 0) := (others => '0'); > begin > return random(tmp); -- this is the original function > end random; > > and then write > > signal s : std_ulogic_vector(N downto M) := random(N-M+1); > > or maybe > > signal s : std_ulogic_vector(N downto M) := random(s'length); > > if the tools grok it. mmmmm overloading comes to rescue us :-) that's what i call irony :-P [i mean : it is sad that a complex and misleading feature comes to relieve you from the non-implementation of a simple feature] i'll try your trick, thank you :-) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 16 14:23:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ieuo-0005Tm-00 for ; Sun, 16 Sep 2001 18:37:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 16 Sep 2001 18:37:06 +0200 (CEST) Received: (qmail 3590 invoked by uid 0); 16 Sep 2001 16:18:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 16 Sep 2001 16:18:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8GGIhU25710 for ; Sun, 16 Sep 2001 12:18:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 16:17:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8GGHqq25457 for f-cpu-list; Sun, 16 Sep 2001 12:17:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8GGHoC25454 for ; Sun, 16 Sep 2001 12:17:50 -0400 Received: by moria.seul.org (Postfix) id 81EAD1462F6; Sun, 16 Sep 2001 12:17:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a045.home.uni-hannover.de [130.75.232.45]) by moria.seul.org (Postfix) with ESMTP id 6C28B1462E9 for ; Sun, 16 Sep 2001 12:17:55 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00448; Sun, 16 Sep 2001 14:23:27 +0200 Message-ID: <20010916142327.25443@thrai.stud.uni-hannover.de> Date: Sun, 16 Sep 2001 14:23:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: genereic_adder patch References: <3BA3E7BC.A4F45B59@f-cpu.org> <20010916020442.56119@thrai.stud.uni-hannover.de> <3BA3EEEB.4081CFCB@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA3EEEB.4081CFCB@f-cpu.org>; from Yann Guidon on Sun, Sep 16, 2001 at 02:14:35AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 16, 2001 at 02:14:35AM +0200, Yann Guidon wrote: > hi, > > Michael Riepe wrote: > > On Sun, Sep 16, 2001 at 01:43:56AM +0200, Yann Guidon wrote: > > > Here is a tiny modification to Michael's generic adder package. > > > The newest version of simili doesn't like the way the agregate > > > was used, but it is not too difficult to work around it. > > Yep... I had to do this several times, too. > i'm waiting for your updated "MR official" version :-) That will take a while. I'm quite busy at the moment (next month's iX issue has to be finished), and I wanted to do a little more than just change one line before I make a new release. [...] > > > As written before, Simili accepts this : > > > Signal s : std_ulogic_vector(N downto M) := random(s); > > You mean, you use `s' before the definition is finished? > > That looks broken, somehow. > that #should# work. i don't remember why and how, or where i have > read it. At least Simili does it. And what is it supposed to do? [...] > mmmmm overloading comes to rescue us :-) > that's what i call irony :-P > [i mean : it is sad that a complex and misleading feature comes > to relieve you from the non-implementation of a simple feature] Isn't it great? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 17 00:06:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15itFN-0000EO-01 for ; Mon, 17 Sep 2001 09:55:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Sep 2001 09:55:17 +0200 (CEST) Received: (qmail 6008 invoked by uid 0); 16 Sep 2001 22:06:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 16 Sep 2001 22:06:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8GM6mT29675 for ; Sun, 16 Sep 2001 18:06:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 22:06:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8GM6BT29414 for f-cpu-list; Sun, 16 Sep 2001 18:06:11 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8GM68C29409 for ; Sun, 16 Sep 2001 18:06:08 -0400 Received: by moria.seul.org (Postfix) id E59221462F6; Sun, 16 Sep 2001 18:06:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by moria.seul.org (Postfix) with ESMTP id 815141462E9 for ; Sun, 16 Sep 2001 18:06:15 -0400 (EDT) Received: from f-cpu.org (nas1-243.aub.club-internet.fr [195.36.202.243]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA03325 for ; Mon, 17 Sep 2001 00:06:03 +0200 (MET DST) Message-ID: <3BA5224A.98191085@f-cpu.org> Date: Mon, 17 Sep 2001 00:06:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: genereic_adder patch References: <3BA3E7BC.A4F45B59@f-cpu.org> <20010916020442.56119@thrai.stud.uni-hannover.de> <3BA3EEEB.4081CFCB@f-cpu.org> <20010916142327.25443@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Sun, Sep 16, 2001 at 02:14:35AM +0200, Yann Guidon wrote: > > Michael Riepe wrote: > > > On Sun, Sep 16, 2001 at 01:43:56AM +0200, Yann Guidon wrote: > > > > Here is a tiny modification to Michael's generic adder package. > > > > The newest version of simili doesn't like the way the agregate > > > > was used, but it is not too difficult to work around it. > > > Yep... I had to do this several times, too. > > i'm waiting for your updated "MR official" version :-) > That will take a while. I'm quite busy at the moment (next month's iX > issue has to be finished), and I wanted to do a little more than just > change one line before I make a new release. so i assume that my patched version will hold until you release another. by the way, wouldn't it be great if you separated the testbench >from the ciadd package ? So if you can't compile the testbench at least you could compile the package... > [...] > > > > As written before, Simili accepts this : > > > > Signal s : std_ulogic_vector(N downto M) := random(s); > > > You mean, you use `s' before the definition is finished? > > > That looks broken, somehow. > > that #should# work. i don't remember why and how, or where i have > > read it. At least Simili does it. > And what is it supposed to do? Since at that point the compiler knows the new name and type, Signal s : std_ulogic_vector(N downto M) := random(s); means that you send a std_ulogic_vector(N downto M) to random(). So you don't have to repeat the declarations. Unfortunately there is no way that i know for a function to read the type and range of the final recipient. > [...] > > mmmmm overloading comes to rescue us :-) > > that's what i call irony :-P > > [i mean : it is sad that a complex and misleading feature comes > > to relieve you from the non-implementation of a simple feature] > Isn't it great? ;) a pity. but who am i to say that, i'm only a newbie. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : back at sound compression/processing, i am dusting off the 8-tap real Winograd FP FFT code i wrote 3 months ago. I am curious to see what i can do when i put a JPEG-like DCT on top of it :*) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 17 01:22:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15itFP-0000EO-00 for ; Mon, 17 Sep 2001 09:55:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Sep 2001 09:55:19 +0200 (CEST) Received: (qmail 31420 invoked by uid 0); 16 Sep 2001 23:23:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 16 Sep 2001 23:23:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8GNN7a31114 for ; Sun, 16 Sep 2001 19:23:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 16 Sep 2001 23:22:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8GNMRq30845 for f-cpu-list; Sun, 16 Sep 2001 19:22:27 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8GNMPC30842 for ; Sun, 16 Sep 2001 19:22:25 -0400 Received: by moria.seul.org (Postfix) id 6D21A1462F6; Sun, 16 Sep 2001 19:22:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a070.home.uni-hannover.de [130.75.232.70]) by moria.seul.org (Postfix) with ESMTP id 5DD081462E9 for ; Sun, 16 Sep 2001 19:22:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02592; Mon, 17 Sep 2001 01:22:20 +0200 Message-ID: <20010917012220.11972@thrai.stud.uni-hannover.de> Date: Mon, 17 Sep 2001 01:22:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: genereic_adder patch References: <3BA3E7BC.A4F45B59@f-cpu.org> <20010916020442.56119@thrai.stud.uni-hannover.de> <3BA3EEEB.4081CFCB@f-cpu.org> <20010916142327.25443@thrai.stud.uni-hannover.de> <3BA5224A.98191085@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA5224A.98191085@f-cpu.org>; from Yann Guidon on Mon, Sep 17, 2001 at 12:06:02AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 17, 2001 at 12:06:02AM +0200, Yann Guidon wrote: [...] > > > i'm waiting for your updated "MR official" version :-) > > That will take a while. I'm quite busy at the moment (next month's iX > > issue has to be finished), and I wanted to do a little more than just > > change one line before I make a new release. > > so i assume that my patched version will hold until you release another. > by the way, wouldn't it be great if you separated the testbench > from the ciadd package ? So if you can't compile the testbench > at least you could compile the package... Umh... file-o-mania ;( That reminds me that I also need to bring my local CVS repository in sync with your snapshots (I use a different directory structure here). [...] > > And what is it supposed to do? > Since at that point the compiler knows the new name and type, > Signal s : std_ulogic_vector(N downto M) := random(s); > means that you send a std_ulogic_vector(N downto M) to random(). > So you don't have to repeat the declarations. > Unfortunately there is no way that i know for a function > to read the type and range of the final recipient. AFAIK that's only possible with `out' or `inout' parameters. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 17 19:53:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15j47I-0004Eg-00 for ; Mon, 17 Sep 2001 21:31:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Sep 2001 21:31:40 +0200 (CEST) Received: (qmail 27540 invoked by uid 0); 17 Sep 2001 17:54:55 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 17 Sep 2001 17:54:55 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8HHsth20744 for ; Mon, 17 Sep 2001 13:54:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 17 Sep 2001 17:53:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8HHrqi20495 for f-cpu-list; Mon, 17 Sep 2001 13:53:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8HHroC20491 for ; Mon, 17 Sep 2001 13:53:50 -0400 Received: by moria.seul.org (Postfix) id A309F1462FA; Mon, 17 Sep 2001 13:53:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.seul.org (Postfix) with ESMTP id A5FC51462F6 for ; Mon, 17 Sep 2001 13:53:44 -0400 (EDT) Received: from f-cpu.org (nas2-131.aub.club-internet.fr [195.36.133.131]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA11101 for ; Mon, 17 Sep 2001 19:53:21 +0200 (MET DST) Message-ID: <3BA6389B.9E3B4810@f-cpu.org> Date: Mon, 17 Sep 2001 19:53:31 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] just for fun (or: maths can be useful) Content-Type: multipart/mixed; boundary="------------1DE4C924F4C9AD9592D9A617" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------1DE4C924F4C9AD9592D9A617 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, just a divagation from the F-CPU, sorry :-) The Winograd Fourier Transform is really powerful, the enclosed "real FFT" and "Real iFFT" transform an 8-tap data with 20 add/sub and 2 multiplies with a constant (in either way). The less computations, the faster and more stable the result. I have not "optimised" the scheduling however. Two goals for this algorithms : because it is ultimately oriented for real-time stuff it will certainly exist in "software" and "hardware". From what i have heard about other's experiments with the WFFT, it is not straight-forward to do because it is not a regular structure (unlike the Cooley-Tuckey version). I'm curious to see how one can design an "optimised" entity with a fixed number of add/sub units. According to the book "Understanding behavioural synthesis" the result is going to be rather ugly if we rely on automated design partition. I believe that our radar specialist (Richard) can give a hint about that :-) If you need to perform some small transforms, feel free to reuse this code. It is acurate to the 12th decimal digit with "double" numbers. I am now trying to translate it to the integer world. As again, comments and suggestions are welcome (as long as it is not concerning the way i write programs :-P) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------1DE4C924F4C9AD9592D9A617 Content-Type: application/x-unknown-content-type-C_auto_file; name="Rwft8_06.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Rwft8_06.c" LyogIHJ3ZnQ4LmMgYnkgd2h5Z2VlQGYtY3B1Lm9yZwoKY29kZSBmb3IgYSBGUCA4LXRhcCBG RlQgIlJlYWwgV2lub2dyYWQgRm91cmllciBUcmFuc2Zvcm0iCmFuZCBpbnZlcnNlIHRyYW5z Zm9ybSBhcyB3ZWxsLgpjb21waWxlIHdpdGggZ2NjIC1nIC1sbSByd2Z0OC5jCgogKi8KCiNp bmNsdWRlIDxtYXRoLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5o PgojaW5jbHVkZSA8c3RkaW8uaD4KCgovKiBGRlQgcmFkaXggOiAqLwojZGVmaW5lIE0gKDgp CgovKiBwcmVjaXNpb24gZm9yIGRpc3BsYXlpbmcgdGhlIHJlYWwgbnVtYmVycyAqLwojZGVm aW5lIE5CRElHSVRTIDE5CgovKiBpbnB1dHMgYW5kIG91dHB1dHMgOiAqLwpkb3VibGUgeFs4 XSwgeVs4XSwgWHJbOF0sIFhpWzhdOyAgLyogWGlbMF0gPSBYaVs0XSA9IDAgKi8KZG91Ymxl IEM7IC8qIHNxcnQoMikvMiAqLwoKCnZvaWQgZmZ0OCgpIHsgICAgLyogd2lub2dyYWQgcmFk aXgtOCAqLwogIGRvdWJsZSB0W01dLCBtW01dOwoKICB0WzBdID0geFswXSArIHhbNF0sCiAg dFsxXSA9IHhbMl0gKyB4WzZdLAogIHRbMl0gPSB4WzFdICsgeFs1XSwKICB0WzNdID0geFsx XSAtIHhbNV0sCiAgdFs0XSA9IHhbM10gKyB4WzddLAogIHRbNV0gPSB4WzNdIC0geFs3XTsK CiAgdFs2XSA9IHRbMF0gKyB0WzFdLAogIHRbN10gPSB0WzJdICsgdFs0XTsKCiAgWHJbMF0g PSB0WzZdICsgdFs3XSwKICBYcls0XSA9IHRbNl0gLSB0WzddLAogIFhyWzJdID0gdFswXSAt IHRbMV0sCiAgbVszXSA9IHhbMF0gLSB4WzRdLAogIG1bNF0gPSBDICogKHRbM10gLSB0WzVd KSwKCiAgWGlbMl0gPSB0WzJdIC0gdFs0XSwgICAgICAgLyogKmogKi8KICBtWzZdID0geFsy XSAtIHhbNl0sICAgICAgICAvKiAqaiAqLwogIG1bN10gPSBDICogKHRbM10gKyB0WzVdKTsg IC8qICpqICovCgogIFhyWzFdID0gbVszXSArIG1bNF0sCiAgWHJbM10gPSBtWzNdIC0gbVs0 XSwKCiAgWGlbMV0gPSBtWzZdICsgbVs3XSwKICBYaVszXSA9IG1bN10gLSBtWzZdOwoKICAv KiAgWGlbMF0gPSBYaVs0XSA9IDA7ICovCn0KCgp2b2lkIGlmZnQ4KCkgewogIGRvdWJsZSB0 cltNXSwgdGlbTV0sIG1yW01dLCBtaVtNXSwgc3JbTT4+MV0sIHNpW00+PjFdOwogIGludCBp OwoKICAvKiAganVzdCBmb3IgdGhvc2Ugd2hvIGdldCB0cmFwcGVkIHdpdGggaUZGVHMgOgog IGZvciAoaT0xOyBpPDQ7IGkrKykgewogICAgWHJbaV0gPSAyKiBYcltpXSA7CiAgICBYaVtp XSA9IDIqIC1YaVtpXTsKICAgIFhyW2krNF0gPSBYaVtpKzRdID0gMDsKICB9CiAgWHJbMF0g PSBYclswXTsKICBYcls0XSA9IFhyWzRdOwogIFhpWzBdID0gWGlbNF0gPSAwCiAgICAqLwoK ICAvKiB2ZXJzaW9uIDMgOiAqLwogIFhyWzBdID0gWHJbMF0vMjsKICBYcls0XSA9IFhyWzRd LzI7CgogIHRyWzBdID0gWHJbMF0gKyBYcls0XTsKCiAgdHJbNl0gPSB0clswXSArIFhyWzJd LAogIHRyWzddID0gWHJbMV0gKyBYclszXTsKCiAgeFswXSA9IHRyWzZdICsgdHJbN10sCiAg eFs0XSA9IHRyWzZdIC0gdHJbN10sCiAgbXJbMl0gPSB0clswXSAtIFhyWzJdLAogIG1yWzNd ID0gWHJbMF0gLSBYcls0XSwKICBtcls0XSA9IEMgKiAoWHJbMV0gLSBYclszXSksCiAgbXJb NV0gPSBYaVsxXSAtIFhpWzNdLCAgICAgICAgLyogKmogKi8KICBtcls2XSA9IFhpWzJdLCAg ICAgICAgICAgICAgICAvKiAqaiAqLwogIG1yWzddID0gQyAqIChYaVsxXSArIFhpWzNdKTsg IC8qICpqICovCgogIHNyWzBdID0gbXJbM10gKyBtcls0XSwKICBzclsxXSA9IG1yWzNdIC0g bXJbNF0sCiAgc3JbMl0gPSBtcls2XSArIG1yWzddLAogIHNyWzNdID0gbXJbNl0gLSBtcls3 XTsKCiAgeFsxXSA9IHNyWzBdICsgc3JbMl0sCiAgeFsyXSA9IG1yWzJdICsgbXJbNV0sCiAg eFszXSA9IHNyWzFdIC0gc3JbM10sCiAgeFs1XSA9IHNyWzFdICsgc3JbM10sCiAgeFs2XSA9 IG1yWzJdIC0gbXJbNV0sCiAgeFs3XSA9IHNyWzBdIC0gc3JbMl07CgogIC8qIGFkanVzdCB0 aGUgb3V0cHV0IDoqLwogIGZvciAoaT0wOyBpPE07IGkrKykgewogICAgeFtpXSA9ICAoeFtp XS80KTsKICB9Cn0KCnZvaWQgZGlzcGxheV94KCkgewogIGludCBqOwogIGZvciAoaj0wOyBq PDg7IGorKykgewogICAgcHJpbnRmKCJ4WyVkXT0gJSsuKmZcbiIsaixOQkRJR0lUUyx4W2pd KTsKICB9Cn0KCnZvaWQgZGlzcGxheV9YKCkgewogIGludCBqOwogIGZvciAoaj0wOyBqPDU7 IGorKykgewogICAgcHJpbnRmKCJYclslZF09ICUrLipmLCBYaVslZF09ICUrLipmLCBhbXBs aXR1ZGUgPSAlLipmXG4iLAogICAgICBqLE5CRElHSVRTLFhyW2pdLAogICAgICBqLE5CRElH SVRTLFhpW2pdLAogICAgICAgIE5CRElHSVRTLGh5cG90KFhyW2pdLFhpW2pdKSk7CiAgfQp9 CgppbnQgbWFpbiAoKSB7CiAgaW50IGksaixrOwogIEZJTEUgKmY7CgogIEM9IHNxcnQoMikv MjsKCiNpZmRlZiBBWkVSQVpFUkFaRVIKCiAgZm9yIChpPTA7IGk8TTsgaSsrKSB7CiAgICB4 W2ldID0gMDsKICAgIHlbaV0gPSAwOwogIH0KICB4WzNdID0gMTsKICBkaXNwbGF5X3goKTsK ICBmZnQ4KCk7CiAgZGlzcGxheV9YKCk7CiAgaWZmdDgoKTsKICBkaXNwbGF5X3goKTsKCiNl bHNlCgogIGY9Zm9wZW4oIi9kZXYvdXJhbmRvbSIsInJiIik7CiAgZm9yIChqPTA7IGo8Mzsg aisrKSB7CgogICAgZm9yIChpPTA7IGk8TTsgaSsrKSB7CiAgICAgIGZyZWFkKCZrLHNpemVv ZihrKSwxLGYpOwogICAgICB4W2ldID0geVtpXSA9IChrLyhSQU5EX01BWCsxLjApKTsKICAg ICAgLyogMyArIGNvcyg2Kk1fUEkqaS9NKSArIGNvcygxKyg0Kk1fUEkqaS9NKSkgKyAoc2lu KCAoMipNX1BJKihpKS9NKSkvMikqLwogICAgfQovKgogICAgeFswXSA9IDE7CgogICAgcHJp bnRmKCJcbiBpbiA6XG4iKTsKICAgIGRpc3BsYXlfeCgpOwoqLwogICAgZmZ0OCgpOwovKgog ICAgcHJpbnRmKCJcbiBmZnQgOlxuIik7CiAgICBkaXNwbGF5X1goKTsKKi8KCiAgICBpZmZ0 OCgpOwovKgogICAgcHJpbnRmKCJcbiBpZmZ0IDpcbiIpOwogICAgZGlzcGxheV94KCk7Ciov CgogICAgcHJpbnRmKCJcbiBlcnJvciA6XG4iKTsKICAgIGZvciAoaT0wOyBpPDg7IGkrKykg ewogICAgICBwcmludGYoIiAgICUrLipmIFxuIiwgTkJESUdJVFMsIHhbaV0gLSB5W2ldKTsK ICAgIH0KICB9CgojZW5kaWYKICByZXR1cm4gMDsKfQo= --------------1DE4C924F4C9AD9592D9A617-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 17 19:46:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jFhf-0000Me-01 for ; Tue, 18 Sep 2001 09:54:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Sep 2001 09:53:59 +0200 (CEST) Received: (qmail 19007 invoked by uid 0); 17 Sep 2001 21:57:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 17 Sep 2001 21:57:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8HLvUA25250 for ; Mon, 17 Sep 2001 17:57:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 17 Sep 2001 21:57:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8HLv5F25003 for f-cpu-list; Mon, 17 Sep 2001 17:57:05 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8HLv4C25000 for ; Mon, 17 Sep 2001 17:57:04 -0400 Received: by moria.seul.org (Postfix) id B140214630D; Mon, 17 Sep 2001 17:57:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id 0970C146306 for ; Mon, 17 Sep 2001 17:57:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01878; Mon, 17 Sep 2001 19:46:27 +0200 Message-ID: <20010917194627.01108@thrai.stud.uni-hannover.de> Date: Mon, 17 Sep 2001 19:46:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new scripts References: <3BA3D920.5F7A780E@f-cpu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" X-Mailer: Mutt 0.84e In-Reply-To: <3BA3D920.5F7A780E@f-cpu.org>; from Yann Guidon on Sun, Sep 16, 2001 at 12:41:36AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii On Sun, Sep 16, 2001 at 12:41:36AM +0200, Yann Guidon wrote: > hello, > > I have enclosed > the HOWTO and the new compilation scripts in this mail. > I ask people to say what they think, if it > is useful and help with them. I cleaned them up a little bit, and also made them more portable. They should now work with bash and (pd)ksh, and maybe also with POSIX-compatible versions of sh. > The shell scripts perform the configuration detection for > the known tools and store the configuration in an autogenerated > script for further use (it's a bit like a mini 'configure'). I guess I'll contribute a `real' autoconf-based configure script one day... > I have also found a way to ease the file management using > bash's array capability. There are many (nasty) tricks so read the > files :-) They were nasty, and now they're gone ;) File management is still as easy as before, though. Without arrays :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --pWyiEgJYm5f9v55/ Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="scripts-mr.tar.gz" H4sIANg1pjsCA+1ZbW/jNhLOV+tXTBSjiouT3+KNt8p5e0G62w2Q3Szi7RaHuyKgJdrWRhJ1 pOREl8t/vxlSsmUnQe+lzofWRBBZ1HA4nBnOPEOqMA6jsK3me9trvW73eDCAPQDolU/ol0/9 szsEGB696g2O+sdHA6TqHfeHe9Dde4GWq4xJgL049OeMR8/SIdl0uve7awf70JmESUfNrQP4 64+OAhWzKIIglFkBypdhmsFUSPBFnKKnJDPI5hzenXXhNszmMNb+A3kScIk9CUc2vuQs4wGM WQZjngK8hu7A673yen3od7s9JMnTQJO8k6Em6Q2gO/QGfW/wnSYBD1gQIAFNxqRkBYgpTMOI Jyzmqsbhg0gMhyH0vvN6Pe9oWHGIWcAhFpJDKmTGJhGHSQEfriwarni1cBQ+4krB2eXHd+c/ Xo/fv724gBAVwTPLg+Z9vX9UjnkgHv6c+zcQTrWQAc+4n4UoDQ5lEaogKCDlEnUXo5iehXR/ g31wkVyISLV5soBfLByaWLQL1ud50ETXvkim4SyXHDcovFkNtKYhzh8JFkBFwmhuqw3tzopq KSMJKLnKo8yIcWc378fnH84vzq9/Pv/41s0TXOyDDSO40z/rgnF/LuDNN31wANmJPAogERnI PKmMj7aaoILRN9qOGXIXZtAjIa0D5IOqVpnEz6gYNEapEe0+WrAcDeORx6EChSyuycQjh4zd 0ybv6//XiWa+tl6kcv00L/XUXsyDCEyPSH0RcGW6/Ej4N3UiI6Zp6NgxcZrxhMvQvya/k2ac ZEkg4s0RPL+WIu2PHPp/fTdhFTW95kmYlQPIQqHKyHG1g1TrA+PCmlfVGXI1ctaWVspVzUbs 8LuPPp+Y78iWL7gssjltSs8iHamRRXv1K4QJNGu8rUAYwyxYBDejvzfvm18fGgcoFzormobc WBG7BCY8y3Arey1wXdwqNIpYRprljX5HZg0zm93UT2h+7TQjW/tHTcSSGGOC/mcdkM+QKshD jf0p1FCPYROaz7Ry1DxqT4eTQ7YQYaD0p4iY+wVkYYyDpIh1zHH0Zs3TlkVv4AZ8ks9iNQOX +NtkjhTcRKgMTSvBVfhHq87AyG9be3/U9ijMvHz+Px5Qzjf5v4sPpDo6Oj7a5f+Xyf/L9L8E APWkbxyjSvtf3v9wUSIBLlVHhXGOO1JIjB3JIpQiiXmStZ+AAL1X0MX83/UGr8y2XTAZilxR hlQiwaikN+L/mdcPLAwyW2ooGomIuYSzJE+3Nw9OhKkac7AJhfWUYCxj6YzsLC3nVB3wM5MJ mWrfBHYtL6GRPBMxcvAxGhag85xWMSrtMcrYx0yjMYKLKVrIm2egADaSMxYLmpAIOyZFyhjc K92h83+dVVsV8X/MjogfsaTOGlteZug60wpmXay+Ubf+3ticEYFM6BP4qHKQzs1BNRR1R1CH AU6LyeiGlKMTYmjxSPEnF6E9nxaxGpUJg3MMU5VyPywd3rCLEkpJnYAvOnlJZB56qdv06MN/ 5Jj7o6JVwlfSntKgrqMzKelcIbbYmgg43/Mp24Z/wUxiDLDHRZzORVLA2x9O4fCqZQLRWRmI OuMqDtkIkrUekzyKnnA029iovkSzcB7YK0qH31FggRpCHokb5wmbr/FDqMNV4mSIRXhMRtce W+drsHWNrbN1C6/sumBJGEUMSHPGroe50o6KCk+FUiEF0hijm2pt0+S6cCGQWG2vKoi32+0K fQYCt0/KECAqzqQ/b5uSjc24p7sR+6ZSzCSLXdqwuOOp182Ea+hx0xuywxbcW8ZIOECrgqIg TqGzUC1rYaXEkhmC0An3GVWHt5RjgnBawPm7cVszObQa+HtkezYCYEyPqQbF933PbX46/fz+ 4URD42UUcu/AbqadZs+GX07KCISgeyqwWgaskLwWvmvPKMnwVSKOlQl0DRv0jobGzg0dq8qh HspR0vW0XC3rQYfE+GYRhZNR87DUkXlvPb8RvpQ+QdsJM7+hJ7tUu0Iv0HTbVqnIZdmLS6gC BH0pR78ReYb1DRkL+m++6VlVWDZb+SdjxZJ4veizoTa2vpOfj+C6sipwcJndKOCi2FgYKcqY Rj4M2421nf3l9OP5xcXp9fjz6efzs5HA0rJRSqRzHk5g9BUt5fYZbW1dciOZZLL47aWdMgxn AWavEKMiVUZYLC7LZASgmKwqWqy0G7SpF6+H8OfV3FXEdCrLnqG8OliOC5Xx2FkTtGGkfBT4 NtUznTo1qtp6wtIjtXzhDMu+3BT4T0hMBWspVRtxDVaA+09ydRHf3VQogJ6rwtmtD3BqBnNw 3VoV5HCVDt5eXV1eaVM2dOTenOtbamYYRW69wdZCN3wWAiYs+BMoQWcIiipXULnvo9ExWq1J Y2L7uuYcqpNLRyIBNtVXrsCYvQ0sCEXdWZ9mWcaFChhNa174PCqpb/RVJGnDB1ZMOBQil0AR rArJNK8vJOk9Kr53rF9bps5i20xjq2Msgf+kOQkD/MW3mKj+CPV/iQq2egHwa+f/x0fd5fn/ Uf+Yzv+Hu/r/xet/eKL8Xzvzd88+/VQdAdDGW+Wm8sTOpRO7tVhTPwuozvphSNcB/b7Xf20q eqxDb+fFjPO/6LPbtpAzHFaljfUjhMFrbzDcvEXY3QH8d3cAPsOV2831KG4j1tNSiARxKUtY VPyTE37GygFTpAazPfsEHqzGyYkhnE43KA2YLXtoCGFfk5rrA79t1XKh/ehaoXKg2r0CQuPy UoF4cMV8yypD1xLim8lX+IEAdQk9K4lsI88KHpw8AmqXl5efxmgjJWJujtZvqTq4xTJhZnJ+ KUiZh8kLPtPpgYgicUv0v4O7DsI1mtHIMfyqNPE/XoVAQ9MylY+cECc1VPi6wTATacQXPBo5 1a/f9C5Fr2X9RkWfIGxcpLzMDUpVj9vm8mTjsmRv13Zt13Zt13Zt13ZtS+3fuwlOBQAoAAA= --pWyiEgJYm5f9v55/-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 18 00:01:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jFhh-0000Me-00 for ; Tue, 18 Sep 2001 09:54:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Sep 2001 09:54:01 +0200 (CEST) Received: (qmail 4224 invoked by uid 0); 17 Sep 2001 22:01:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx01) with SMTP; 17 Sep 2001 22:01:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8HM1Ut25599 for ; Mon, 17 Sep 2001 18:01:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 17 Sep 2001 22:01:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8HM1Ba25349 for f-cpu-list; Mon, 17 Sep 2001 18:01:11 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8HM1AC25346 for ; Mon, 17 Sep 2001 18:01:10 -0400 Received: by moria.seul.org (Postfix) id 19D1A1462F6; Mon, 17 Sep 2001 18:01:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by moria.seul.org (Postfix) with ESMTP id 8F0041462E9 for ; Mon, 17 Sep 2001 18:01:18 -0400 (EDT) Received: from f-cpu.org (nas2-41.aub.club-internet.fr [195.36.133.41]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA19474 for ; Tue, 18 Sep 2001 00:01:07 +0200 (MET DST) Message-ID: <3BA672A6.73C54898@f-cpu.org> Date: Tue, 18 Sep 2001 00:01:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new scripts References: <3BA3D920.5F7A780E@f-cpu.org> <20010917194627.01108@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sun, Sep 16, 2001 at 12:41:36AM +0200, Yann Guidon wrote: > > I have also found a way to ease the file management using > > bash's array capability. There are many (nasty) tricks so read the > > files :-) > > They were nasty, and now they're gone ;) > File management is still as easy as before, though. > Without arrays :) i'll have a look, but be ready for more dusty things ;-P good night, > Michael "Tired" Riepe WHYGEE (seeking 8-tap real DCT code on the net) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From philippe.trbich@free.fr Tue Sep 18 21:27:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jWHw-0002Uk-00 for ; Wed, 19 Sep 2001 03:36:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Sep 2001 03:36:32 +0200 (CEST) Received: (qmail 10231 invoked by uid 0); 18 Sep 2001 19:27:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 18 Sep 2001 19:27:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8IJRgM21669 for ; Tue, 18 Sep 2001 15:27:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 18 Sep 2001 19:26:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8IJQuV21300 for f-cpu-list; Tue, 18 Sep 2001 15:26:56 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8IJQtC21284 for ; Tue, 18 Sep 2001 15:26:55 -0400 Received: by moria.seul.org (Postfix) id 161561462F8; Tue, 18 Sep 2001 15:27:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id ECE691462F6 for ; Tue, 18 Sep 2001 15:27:03 -0400 (EDT) Received: from linux (nantes-2-a7-42-10.dial.proxad.net [212.27.42.10]) by postfix1-2.free.fr (Postfix) with SMTP id 4225AAB6A1 for ; Tue, 18 Sep 2001 21:26:53 +0200 (CEST) Date: Tue, 18 Sep 2001 21:27:44 +0200 From: philippe.trbich@free.fr To: f-cpu@seul.org Subject: Re: [f-cpu] just for fun (or: maths can be useful) Message-Id: <20010918212744.0eb4f5ee.philippe.trbich@free.fr> In-Reply-To: <3BA6389B.9E3B4810@f-cpu.org> References: <3BA6389B.9E3B4810@f-cpu.org> X-Mailer: Sylpheed version 0.6.1claws (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 17 Sep 2001 19:53:31 +0200 Yann Guidon wrote: if you want to try some speed FFT, try http:/www.fftw.org. Cordially. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 19 04:26:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jWHx-0002Uk-00 for ; Wed, 19 Sep 2001 03:36:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Sep 2001 03:36:33 +0200 (CEST) Received: (qmail 28197 invoked by uid 0); 18 Sep 2001 20:14:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 18 Sep 2001 20:14:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8IKEii23282 for ; Tue, 18 Sep 2001 16:14:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 18 Sep 2001 20:14:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8IKEOa23037 for f-cpu-list; Tue, 18 Sep 2001 16:14:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8IKENC23034 for ; Tue, 18 Sep 2001 16:14:23 -0400 Received: by moria.seul.org (Postfix) id 6186214630E; Tue, 18 Sep 2001 16:14:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-159.vlt.club-internet.fr [194.158.107.159]) by moria.seul.org (Postfix) with ESMTP id 299E8146300 for ; Tue, 18 Sep 2001 16:14:31 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id AA772172B for ; Tue, 18 Sep 2001 22:26:17 -0400 (EDT) Message-ID: <3BA80249.4A960EB5@ifrance.com> Date: Tue, 18 Sep 2001 22:26:17 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Sep 15, 2001 at 01:59:48PM -0400, nicO wrote: > [...] > > > > > However, it is useful for small quantities > > > > > (around 1K-100K) runs concerning high-speed control, such as > > > > > the SCSI or IP router example. Small companies would adopt F-CPU > > > > > easily because the price tag and the independence from the toolset > > > > > are "attracting" (to reuse your word). I think that it is where > > > > > we can seek implementors. > > > > > > > > Yep, if they can earn money, and there work will not be stolen as > > > > explain by Michael. > > > this means that we are in the case where the company's "central activity" > > > is not making CPUs but using them. > > > > > > > ??? It's evident : how many compagny make cpu ? Few dosen ? How many use > > them ? thousand ? > > I guess the term `use' has to be clarified, too. IMHO, `using the F-CPU' > can only mean `running the processor' -- no matter how it's implemented. > This kind of use should not be restricted by us at all, and must not be > restricted by others, in order to maintain users' freedom. This is what > the GPL means when it says `you may use the program freely'. > That's true. But GPL means that the compagny should release it's own code, too. Imagine an fft bloc to make fast encoding for a communication system. 12 Months of work. If they want to use fcpu, they should release under the GPL code. Great for us ! But for them, do they want to take the risk that there opponent develop there chip with there work ? They just need to copy there work without adding any value. I stay at the VHDL level. For my part, i prefer that they use fcpu instead of an ARM. I prefer that they debug a fcpu rather than we try to keep another design because they choose to use an fcpu. > Implementing the F-CPU is another kind of `use', but not in the GPL sense. > People can translate/compile/transform the F-CPU source code, with or > without modifications, and create pieces of silicon (or GaAs, or GeSi, or > something totally different in the future), bit-streams for loading into > an FPGA, or programs that run on another processor (simulators/emulators). > > Most people can't do that on their kitchen table -- they will have to > ask somebody else to do it. That's the big difference between the HW > and SW worlds. Since the manufacturing company acts like a compiler > in the SW world, it can't be considered a `user' of the F-CPU -- it's > the company's client who will be responsible for changing SR_URL and > releasing his modifications under the terms of the GPL. In particular, > the manufacturing company will NOT be forced to release source code for > their technology libraries or details of their manufacturing process. > They are not bound by the GPL at all, as long as they ONLY build chips > for somebody else. > I know that and it's not the problem at all ! nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Sep 19 01:00:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jWHy-0002Uk-00 for ; Wed, 19 Sep 2001 03:36:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Sep 2001 03:36:34 +0200 (CEST) Received: (qmail 27779 invoked by uid 0); 18 Sep 2001 23:00:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 18 Sep 2001 23:00:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8IN0Td25768 for ; Tue, 18 Sep 2001 19:00:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 18 Sep 2001 22:59:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8IMxtu25278 for f-cpu-list; Tue, 18 Sep 2001 18:59:55 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8IMxrC25266 for ; Tue, 18 Sep 2001 18:59:53 -0400 Received: by moria.seul.org (Postfix) id 130901462F8; Tue, 18 Sep 2001 19:00:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id CD78F1462F6 for ; Tue, 18 Sep 2001 19:00:02 -0400 (EDT) Received: from f-cpu.org (nas2-62.aub.club-internet.fr [195.36.133.62]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 7C04A1686 for ; Wed, 19 Sep 2001 00:59:51 +0200 (CEST) Message-ID: <3BA7D1F2.1B09240A@f-cpu.org> Date: Wed, 19 Sep 2001 01:00:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> <3BA80249.4A960EB5@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, btw i bought Ashenden VHDL book today and i got the CD with the Cadence download from our french friend Olivier. Looks like i'm not going to sleep before next summer... ok, back to the discussion :-) nicO wrote: > Michael Riepe a écrit : > > On Sat, Sep 15, 2001 at 01:59:48PM -0400, nicO wrote: > > [...] > > > > > Yep, if they can earn money, and there work will not be stolen as > > > > > explain by Michael. > > > > this means that we are in the case where the company's "central activity" > > > > is not making CPUs but using them. > > > ??? It's evident : how many compagny make cpu ? Few dosen ? How many use > > > them ? thousand ? > > I guess the term `use' has to be clarified, too. IMHO, `using the F-CPU' > > can only mean `running the processor' -- no matter how it's implemented. > > This kind of use should not be restricted by us at all, and must not be > > restricted by others, in order to maintain users' freedom. This is what > > the GPL means when it says `you may use the program freely'. > > That's true. But GPL means that the compagny should release it's own > code, too. Imagine an fft bloc to make fast encoding for a communication > system. 12 Months of work. Ray Andraka (comp.fpga, comp.dsp...) developped a 16-tap Winograd complex FFT in 6 man/month. i don't remember the price for the bitstream licence or the source, but he was kind enough to send me the original transformation matrices he got from a book. i think that you (nicO) have seen the 3 matrices at the Sous-Bock. he did not send me the result of his work, but the beginning thereof. If Ray wants to integrate his core _inside_ the f-cpu core, he HAS to divulgue the source. However i believe he's smart enough to find a work-around, like mapping his I/O in uncachable memory so you access the functionality outside of the core. I believe that some people are smart, yes :-) at least enough to find solutions like that. > If they want to use fcpu, they should release under the GPL code. Great > for us ! release what ? the modified source. > But for them, do they want to take the risk that there opponent > develop there chip with there work ? They just need to copy there work > without adding any value. > > I stay at the VHDL level. For my part, i prefer that they use fcpu > instead of an ARM. I prefer that they debug a fcpu rather than we try to > keep another design because they choose to use an fcpu. btw, do you access a synthesiser currently ? Accessing Cadence ncsim is cool and sexy, but it's pretty useless if our source code doesn't synthesise... I'll start at Jussieu on the 28th and i'll have some ressources, but not everything. Other's (ie: Kim) help will still be precious. nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Sep 19 01:00:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15jWHz-0002Uk-00 for ; Wed, 19 Sep 2001 03:36:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Sep 2001 03:36:35 +0200 (CEST) Received: (qmail 32614 invoked by uid 0); 18 Sep 2001 23:00:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Sep 2001 23:00:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8IN0Rv25736 for ; Tue, 18 Sep 2001 19:00:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 18 Sep 2001 22:59:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8IMxq925251 for f-cpu-list; Tue, 18 Sep 2001 18:59:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8IMxpC25248 for ; Tue, 18 Sep 2001 18:59:51 -0400 Received: by moria.seul.org (Postfix) id B40FA1462F8; Tue, 18 Sep 2001 19:00:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id 7870A1462F6 for ; Tue, 18 Sep 2001 19:00:00 -0400 (EDT) Received: from f-cpu.org (nas2-62.aub.club-internet.fr [195.36.133.62]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 65C7F1686 for ; Wed, 19 Sep 2001 00:59:48 +0200 (CEST) Message-ID: <3BA7D1F2.8C4CBD0B@f-cpu.org> Date: Wed, 19 Sep 2001 01:00:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] just for fun (or: maths can be useful) References: <3BA6389B.9E3B4810@f-cpu.org> <20010918212744.0eb4f5ee.philippe.trbich@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, philippe.trbich@free.fr wrote: > On Mon, 17 Sep 2001 19:53:31 +0200 > Yann Guidon wrote: > > if you want to try some speed FFT, try http:/www.fftw.org. i know FFTW for a while but i do not need to analyze megasamples in a row or PVM or codelets... There are many reasons for me to not use it. it's rather a "mathematical tool", i need a small "real case" tool. btw, i found that i need more a DCT than a FFT : this is due to the fact that DCT can catch one lower frequency component, thus reducing the spectrum spread when there is a large difference between sample 0 and sample N-1. This is why the DCT is used in JPEG instead of FFT and i have a rather similar need. And FFT requires windowing, DCT doesn't. I could derive a 8-tap DCT from a 16-tap FFT (winograd if possible) but i don't have any 16-point winograd code :-( and i don't know yet how to derive the DCT from the 8-tap winograd code. The possibilities i know require too much overhead (require much more multiplies than needed). > Cordially. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Sep 20 02:47:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2xp-0001kX-00 for ; Thu, 20 Sep 2001 14:29:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:29:57 +0200 (CEST) Received: (qmail 18226 invoked by uid 0); 19 Sep 2001 18:35:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 19 Sep 2001 18:35:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8JIZmY15033 for ; Wed, 19 Sep 2001 14:35:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 19 Sep 2001 18:35:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8JIZJi14750 for f-cpu-list; Wed, 19 Sep 2001 14:35:19 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8JIZIC14747 for ; Wed, 19 Sep 2001 14:35:18 -0400 Received: by moria.seul.org (Postfix) id 63AB91462F8; Wed, 19 Sep 2001 14:35:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas25-42.vlt.club-internet.fr [195.36.224.42]) by moria.seul.org (Postfix) with ESMTP id 24BE11462F7 for ; Wed, 19 Sep 2001 14:35:27 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id A115C172B for ; Wed, 19 Sep 2001 20:47:18 -0400 (EDT) Message-ID: <3BA93C96.1BEC8D05@ifrance.com> Date: Wed, 19 Sep 2001 20:47:18 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> <3BA80249.4A960EB5@ifrance.com> <3BA7D1F2.1B09240A@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <..> > If Ray wants to integrate his core _inside_ the f-cpu core, he HAS to divulgue the > source. However i believe he's smart enough to find a work-around, like mapping > his I/O in uncachable memory so you access the functionality outside of the core. > I believe that some people are smart, yes :-) at least enough to find solutions > like that. > ??? Not really. If it's on the same chip, you loose the benefit of the HDL (Timing marging wider,...). That's not so smart. > > If they want to use fcpu, they should release under the GPL code. Great > > for us ! > release what ? the modified source. > No the code of the coprocessor. nicO <..> > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Sep 19 23:36:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2xs-0001kX-00 for ; Thu, 20 Sep 2001 14:30:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:30:00 +0200 (CEST) Received: (qmail 25322 invoked by uid 0); 19 Sep 2001 21:36:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Sep 2001 21:36:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8JLaiu20241 for ; Wed, 19 Sep 2001 17:36:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 19 Sep 2001 21:36:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8JLa2419990 for f-cpu-list; Wed, 19 Sep 2001 17:36:02 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8JLa1C19987 for ; Wed, 19 Sep 2001 17:36:01 -0400 Received: by moria.seul.org (Postfix) id 6A6001462FC; Wed, 19 Sep 2001 17:36:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 374A81462F7 for ; Wed, 19 Sep 2001 17:36:11 -0400 (EDT) Received: from f-cpu.org (nas10-209.kdl.club-internet.fr [213.44.4.209]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 233F516D1 for ; Wed, 19 Sep 2001 23:35:59 +0200 (CEST) Message-ID: <3BA90FD0.AC1E6046@f-cpu.org> Date: Wed, 19 Sep 2001 23:36:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: RE: MAC address] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i have started to install Cadence's software. After i solved some of the first (big) problems (i encourage you to start with simili and vanilla), and while i'm continuously writing the VHDL_HOWTO, some people have told me that they are interested by Cadence's offer. Here are some more informations (add to that your PC's MAC address). This topic came because of the "relatively large size" of the package (130MB), and other people asked me to copy the package on a CD. Of course I will send you the data only if you have been registered with Martyn. I don't want to have any problem of any kind. For more informations, please send a mail to mjp@cadence.com thanks, YG -------- Original Message -------- From: "Martyn Pollard" To: Subject: RE: MAC address Hi Yann, I'll need more information about the users. I have to be careful what licenses are given out. If you can ask them to complete this information, we can take it from there. > 1 It has to confirm the person has a background in electronics/computing. > 2 Full Name, Address, Phone number and email address of person applying for license. > 3 Full Name, Job Title, Work Address, Work Phone number and email address of person acting as a reference. > 4 Name of the university/college the person attended or current employer. > 5 What they intend to use the software for > -----Original Message----- > From: Yann Guidon [mailto:whygee@f-cpu.org] > Sent: Wednesday, September 19, 2001 11:40 AM > To: mjp > Subject: Re: MAC address > > ok it works. thanks ! i start configuring it. > > Some parisian contributors (those who came last year > with me in Berlin to present the project) have said > that they are interested by your offer but they can't > download the large file. Am i allowed to provide them > with the .pgp package ? They will request their own > keys of course. > > > Martyn > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 20 00:56:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2zD-0001kX-00 for ; Thu, 20 Sep 2001 14:31:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:31:23 +0200 (CEST) Received: (qmail 20180 invoked by uid 0); 19 Sep 2001 23:00:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 19 Sep 2001 23:00:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8JN03n22122 for ; Wed, 19 Sep 2001 19:00:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 19 Sep 2001 22:59:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8JMxgw21872 for f-cpu-list; Wed, 19 Sep 2001 18:59:42 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8JMxeC21869 for ; Wed, 19 Sep 2001 18:59:41 -0400 Received: by moria.seul.org (Postfix) id 979A6146692; Wed, 19 Sep 2001 18:59:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a209.home.uni-hannover.de [130.75.232.209]) by moria.seul.org (Postfix) with ESMTP id 529B7146691 for ; Wed, 19 Sep 2001 18:59:48 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA13032; Thu, 20 Sep 2001 00:56:00 +0200 Message-ID: <20010920005600.37529@thrai.stud.uni-hannover.de> Date: Thu, 20 Sep 2001 00:56:00 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: RE: MAC address] References: <3BA90FD0.AC1E6046@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA90FD0.AC1E6046@f-cpu.org>; from Yann Guidon on Wed, Sep 19, 2001 at 11:36:16PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 19, 2001 at 11:36:16PM +0200, Yann Guidon wrote: [...] > > 1 It has to confirm the person has a background in electronics/computing. > > 2 Full Name, Address, Phone number and email address of person applying for license. > > 3 Full Name, Job Title, Work Address, Work Phone number and email address of person acting as a reference. > > 4 Name of the university/college the person attended or current employer. > > 5 What they intend to use the software for [...] I'm surprised that they don't ask me to sell my soul, too. I guess I'll stick with vanilla and simili. Maybe I'll even drop vanilla -- simili seems to work great with linux/wine, and is much faster. I wrote this simple wrapper shell script that serves as both `vhdlp' and `vhdle', so I never have to mess with wine on the command line again: #! /bin/bash - name=${0##*/} wine=/where/wine/is/located/bin/wine # change this wineopts='-debugmsg -all' echo >&2 'starting wine... please be patient.' exec $wine $wineopts "$name $*" :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 20 04:16:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2zF-0001kX-00 for ; Thu, 20 Sep 2001 14:31:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:31:25 +0200 (CEST) Received: (qmail 9072 invoked by uid 0); 20 Sep 2001 02:16:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx22) with SMTP; 20 Sep 2001 02:16:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8K2GTx27405 for ; Wed, 19 Sep 2001 22:16:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 02:16:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8K2G6q27149 for f-cpu-list; Wed, 19 Sep 2001 22:16:06 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8K2G5C27146 for ; Wed, 19 Sep 2001 22:16:05 -0400 Received: by moria.seul.org (Postfix) id 705A2146301; Wed, 19 Sep 2001 22:16:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 54DA71462F7 for ; Wed, 19 Sep 2001 22:16:15 -0400 (EDT) Received: from f-cpu.org (nas10-129.kdl.club-internet.fr [213.44.4.129]) by relay-4v.club-internet.fr (Postfix) with ESMTP id BD5E616A7 for ; Thu, 20 Sep 2001 04:16:02 +0200 (CEST) Message-ID: <3BA95170.8B17AFB9@f-cpu.org> Date: Thu, 20 Sep 2001 04:16:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: RE: MAC address] References: <3BA90FD0.AC1E6046@f-cpu.org> <20010920005600.37529@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Wed, Sep 19, 2001 at 11:36:16PM +0200, Yann Guidon wrote: > [...] > > I'm surprised that they don't ask me to sell my soul, too. don't worry too much. They don't take too much risks because the licences last 2 months. > I guess I'll stick with vanilla and simili. Maybe I'll even drop vanilla > -- simili seems to work great with linux/wine, and is much faster. I'm glad that we're on the same brain wavelength but beware : Vanilla has some limitations and Simili can be too generous. I care for the portability of the source code and i don't want to be trapped by Simili or anything else. Checking with Vanilla from time to time is probably necessary, as it is the only "small" VHDL compiler/simulator that can work without too much problems. While installing Cadence (it's still unfinished !!!) i encounter a shared library problem for the 3rd time. I downgrade/upgrade this laptop all the time... > I wrote this simple wrapper shell script that serves as both `vhdlp' > and `vhdle', so I never have to mess with wine on the command line again: > > #! /bin/bash - > name=${0##*/} > wine=/where/wine/is/located/bin/wine # change this > wineopts='-debugmsg -all' > echo >&2 'starting wine... please be patient.' > exec $wine $wineopts "$name $*" > > :) lazy guy ;-P (heck, that means that you're a good programmer, in the PERL world) i even guess that you have made a function with it, that you included in your .bash_profile :-P If i survive to the installation of this ncstuff, i'll let you know... Ok, now, let's see if i have libc.so.6/GLIBC_2.2 available somewhere... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 20 09:11:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2zH-0001kX-00 for ; Thu, 20 Sep 2001 14:31:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:31:27 +0200 (CEST) Received: (qmail 32620 invoked by uid 0); 20 Sep 2001 07:12:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx26) with SMTP; 20 Sep 2001 07:12:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8K7CA601145 for ; Thu, 20 Sep 2001 03:12:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 07:11:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8K7BjF00901 for f-cpu-list; Thu, 20 Sep 2001 03:11:45 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8K7BiC00898 for ; Thu, 20 Sep 2001 03:11:44 -0400 Received: by moria.seul.org (Postfix) id 7F4CB146306; Thu, 20 Sep 2001 03:11:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 621781462FF for ; Thu, 20 Sep 2001 03:11:54 -0400 (EDT) Received: from f-cpu.org (nas10-186.kdl.club-internet.fr [213.44.4.186]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 8EC9016A6 for ; Thu, 20 Sep 2001 09:11:39 +0200 (CEST) Message-ID: <3BA996BE.B502B27D@f-cpu.org> Date: Thu, 20 Sep 2001 09:11:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) References: <15fd9G-0hL7vEC@fwd01.sul.t-online.com> <3B9C2CC3.8A6C190B@ifrance.com> <20010910151955.08892@thrai.stud.uni-hannover.de> <3B9EE111.CA428915@ifrance.com> <20010912013745.05028@thrai.stud.uni-hannover.de> <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> <3BA80249.4A960EB5@ifrance.com> <3BA7D1F2.1B09240A@f-cpu.org> <3BA93C96.1BEC8D05@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > <..> > > If Ray wants to integrate his core _inside_ the f-cpu core, he HAS to divulgue the > > source. However i believe he's smart enough to find a work-around, like mapping > > his I/O in uncachable memory so you access the functionality outside of the core. > > I believe that some people are smart, yes :-) at least enough to find solutions > > like that. > > ??? Not really. If it's on the same chip, you loose the benefit of the > HDL (Timing marging wider,...). That's not so smart. the limits are too fuzzy for me... i prefer to not have an opinion, instead of jumping into the debate and provoke damage. > > > If they want to use fcpu, they should release under the GPL code. Great for us ! > > release what ? the modified source. > No the code of the coprocessor. what is the difference ? if the coprocessor is inside the core, yes, if it is interfaced using the standard extensions, i see no problem. I hope that we will find some help soon. APRIL, GAOS, CCC ?... We will discuss about this next time we meet (soon). > <..> thanks :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Thu Sep 20 12:46:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15k2zL-0001kX-01 for ; Thu, 20 Sep 2001 14:31:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Sep 2001 14:31:31 +0200 (CEST) Received: (qmail 5881 invoked by uid 0); 20 Sep 2001 11:03:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 20 Sep 2001 11:03:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KB36u03919 for ; Thu, 20 Sep 2001 07:03:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 11:02:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KB2gK03672 for f-cpu-list; Thu, 20 Sep 2001 07:02:42 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KB2eC03669 for ; Thu, 20 Sep 2001 07:02:40 -0400 Received: by moria.seul.org (Postfix) id 566A9146697; Thu, 20 Sep 2001 07:02:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id F24BE1462FF for ; Thu, 20 Sep 2001 07:02:50 -0400 (EDT) Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 15k1M6-000627-00 for ; Thu, 20 Sep 2001 12:46:54 +0200 Date: Thu, 20 Sep 2001 12:46:54 +0200 From: Paul Marques Mota To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) Message-ID: <20010920124654.A22813@opium.april.org> References: <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> <3BA80249.4A960EB5@ifrance.com> <3BA7D1F2.1B09240A@f-cpu.org> <3BA93C96.1BEC8D05@ifrance.com> <3BA996BE.B502B27D@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA996BE.B502B27D@f-cpu.org>; from whygee@f-cpu.org on Thu, Sep 20, 2001 at 09:11:58AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 20, 2001 at 09:11:58AM +0200, Yann Guidon wrote: > hello, > Hi > > I hope that we will find some help soon. APRIL, GAOS, CCC ?... Don't forget the FSF and FSFeurope. > We will discuss about this next time we meet (soon). > Why not. > thanks :-) > > > nicO > WHYGEE -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 20 14:23:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcQ-0001Eb-01 for ; Fri, 21 Sep 2001 05:04:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:46 +0200 (CEST) Received: (qmail 12735 invoked by uid 0); 20 Sep 2001 13:44:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 20 Sep 2001 13:44:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KDim007287 for ; Thu, 20 Sep 2001 09:44:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 13:44:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KDiQu07018 for f-cpu-list; Thu, 20 Sep 2001 09:44:26 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KDiPC07015 for ; Thu, 20 Sep 2001 09:44:25 -0400 Received: by moria.seul.org (Postfix) id 0396F1466AC; Thu, 20 Sep 2001 09:44:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a233.home.uni-hannover.de [130.75.232.233]) by moria.seul.org (Postfix) with ESMTP id 70E8A1462FF for ; Thu, 20 Sep 2001 09:44:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00538; Thu, 20 Sep 2001 14:23:11 +0200 Message-ID: <20010920142311.21025@thrai.stud.uni-hannover.de> Date: Thu, 20 Sep 2001 14:23:11 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: RE: MAC address] References: <3BA90FD0.AC1E6046@f-cpu.org> <20010920005600.37529@thrai.stud.uni-hannover.de> <3BA95170.8B17AFB9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BA95170.8B17AFB9@f-cpu.org>; from Yann Guidon on Thu, Sep 20, 2001 at 04:16:16AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: RO X-Status: O On Thu, Sep 20, 2001 at 04:16:16AM +0200, Yann Guidon wrote: [...] > > I guess I'll stick with vanilla and simili. Maybe I'll even drop vanilla > > -- simili seems to work great with linux/wine, and is much faster. > I'm glad that we're on the same brain wavelength but beware : Vanilla > has some limitations and Simili can be too generous. I care for the portability > of the source code and i don't want to be trapped by Simili or anything else. I used to compile with both of them, and change all code that didn't work with either one. [...] > lazy guy ;-P > (heck, that means that you're a good programmer, in the PERL world) Also in the Unix world. "Do it only once, but do it right" ;) > i even guess that you have made a function with it, that you included in > your .bash_profile :-P No, functions belong in .bashrc -- because they're not exported to subshells automatically ;) > If i survive to the installation of this ncstuff, i'll let you know... > Ok, now, let's see if i have libc.so.6/GLIBC_2.2 available somewhere... Most distributions use that nowadays -- except debian, AFAIK. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Thu Sep 20 15:04:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcQ-0001Eb-00 for ; Fri, 21 Sep 2001 05:04:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:46 +0200 (CEST) Received: (qmail 31876 invoked by uid 0); 20 Sep 2001 13:11:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 20 Sep 2001 13:11:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KDBLA05369 for ; Thu, 20 Sep 2001 09:11:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 13:11:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KDB0W05120 for f-cpu-list; Thu, 20 Sep 2001 09:11:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KDAwC05117 for ; Thu, 20 Sep 2001 09:10:58 -0400 Received: by moria.seul.org (Postfix) id EDBFA1466A7; Thu, 20 Sep 2001 09:11:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 6A4381462FF for ; Thu, 20 Sep 2001 09:11:08 -0400 (EDT) Received: from art1.none.de (dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f8KDB0f04918 for ; Thu, 20 Sep 2001 15:11:00 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin233.pg4-nt.berlin.nikoma.de [213.54.67.233] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15k3VP-0000AI-00 for ; Thu, 20 Sep 2001 15:04:39 +0200 Date: Thu, 20 Sep 2001 15:04:01 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) In-Reply-To: <3BA996BE.B502B27D@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: RO X-Status: O -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > > > > If they want to use fcpu, they should release under the GPL code. Great for us ! > > > release what ? the modified source. > > No the code of the coprocessor. > what is the difference ? > if the coprocessor is inside the core, yes, if it is interfaced using the standard > extensions, i see no problem. Erm, the GPL forbids linking propritary content with GPL. But this can be defined in our interpretation in a way linux does. I suggest, we define a strict interface to f-cpu, which are similiar with a limes to our GPL-protected f-cpu-design. We should decide between feature-enhancements inside of f-cpu and feature-enhancements outside. Out side is a "zu weites Feld", but if we want include sources into the core, it must be GPL-ized. > I hope that we will find some help soon. APRIL, GAOS, CCC ?... > We will discuss about this next time we meet (soon). Do you meant these? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7qelFClxplZklbgERAvHtAJ4tiXg2jFN6QgVKDFAwJe72BHocrgCfTQL5 68MopPVL7GEc3f2KGmtWc+8= =B8nN -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 20 22:13:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcU-0001Eb-01 for ; Fri, 21 Sep 2001 05:04:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:50 +0200 (CEST) Received: (qmail 12119 invoked by uid 0); 20 Sep 2001 20:14:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 20 Sep 2001 20:14:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KKEAh14083 for ; Thu, 20 Sep 2001 16:14:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 20:13:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KKDFd13338 for f-cpu-list; Thu, 20 Sep 2001 16:13:15 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KKDEC13329 for ; Thu, 20 Sep 2001 16:13:14 -0400 Received: by moria.seul.org (Postfix) id B4182146303; Thu, 20 Sep 2001 16:13:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 98BCF1462F8 for ; Thu, 20 Sep 2001 16:13:24 -0400 (EDT) Received: from f-cpu.org (nas26-69.kdl.club-internet.fr [213.44.97.69]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 31A24169E for ; Thu, 20 Sep 2001 22:13:11 +0200 (CEST) Message-ID: <3BAA4DE8.AAA3788C@f-cpu.org> Date: Thu, 20 Sep 2001 22:13:28 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Andreas Romeyke wrote: > Hello, > > > > > > If they want to use fcpu, they should release under the GPL code. Great for us ! > > > > release what ? the modified source. > > > No the code of the coprocessor. > > what is the difference ? > > if the coprocessor is inside the core, yes, if it is interfaced using the standard > > extensions, i see no problem. > > Erm, the GPL forbids linking propritary content with GPL. But this can be > defined in our interpretation in a way linux does. i don't like to play with definitions and words : it's an endless game. I recently lit a discussion about GPL/FSF/Electronics/etc on the french FSF/APRIL mailing list and the people there prefer to discuss about the meaning of what i write, instead of finding solution. I start to be _really_ desperate :-// > I suggest, we define a strict interface to f-cpu, which are similiar with > a limes to our GPL-protected f-cpu-design. We should decide between > feature-enhancements inside of f-cpu and feature-enhancements outside. Out > side is a "zu weites Feld", but if we want include sources into the core, > it must be GPL-ized. i think that we will probably adopt this strategy (if everybody agrees, and principally Michael) But the problem of the GPL remains : we will have to "redefine" several terms of the licence, and it would be better to rewrite it completely to avoid any misunderstanding. > > I hope that we will find some help soon. APRIL, GAOS, CCC ?... > > We will discuss about this next time we meet (soon). > Do you meant these? I meant that i will speak with nicO this week-end (we sometimes meet in Paris). But of course, meeting you will be a pleasure (if you want). Except that unless you come to Paris, it will be difficult to meet you before several months. Going to the 18C3 would be a solution. > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 20 22:13:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcV-0001Eb-00 for ; Fri, 21 Sep 2001 05:04:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:51 +0200 (CEST) Received: (qmail 9349 invoked by uid 0); 20 Sep 2001 20:14:12 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 20 Sep 2001 20:14:12 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KKECD14101 for ; Thu, 20 Sep 2001 16:14:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 20:13:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KKDHq13345 for f-cpu-list; Thu, 20 Sep 2001 16:13:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KKDFC13333 for ; Thu, 20 Sep 2001 16:13:15 -0400 Received: by moria.seul.org (Postfix) id CA179146303; Thu, 20 Sep 2001 16:13:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id AFAAE1462F8 for ; Thu, 20 Sep 2001 16:13:25 -0400 (EDT) Received: from f-cpu.org (nas26-69.kdl.club-internet.fr [213.44.97.69]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B09CE1725 for ; Thu, 20 Sep 2001 22:13:12 +0200 (CEST) Message-ID: <3BAA4DEA.829271E5@f-cpu.org> Date: Thu, 20 Sep 2001 22:13:30 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: RE: MAC address] References: <3BA90FD0.AC1E6046@f-cpu.org> <20010920005600.37529@thrai.stud.uni-hannover.de> <3BA95170.8B17AFB9@f-cpu.org> <20010920142311.21025@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Thu, Sep 20, 2001 at 04:16:16AM +0200, Yann Guidon wrote: > [...] > > > I guess I'll stick with vanilla and simili. Maybe I'll even drop vanilla > > > -- simili seems to work great with linux/wine, and is much faster. > > I'm glad that we're on the same brain wavelength but beware : Vanilla > > has some limitations and Simili can be too generous. I care for the portability > > of the source code and i don't want to be trapped by Simili or anything else. > I used to compile with both of them, and change all code that didn't > work with either one. i want to continue in this direction. I believe that (if it EVER works) Cadence will not make much troubles but i will constantly check against all tools. > [...] > > lazy guy ;-P > > (heck, that means that you're a good programmer, in the PERL world) > Also in the Unix world. "Do it only once, but do it right" ;) what does "once" mean ? write or instanciate ? i prefer to write, rewrite and rerewrite many times : "do it again and do it better". Otherwise there would be no point to make yet another Nth CPU :-/ > > i even guess that you have made a function with it, that you included in > > your .bash_profile :-P > No, functions belong in .bashrc -- because they're not exported to > subshells automatically ;) thanks, now i understand some bugs.... :-) > > If i survive to the installation of this ncstuff, i'll let you know... > > Ok, now, let's see if i have libc.so.6/GLIBC_2.2 available somewhere... > Most distributions use that nowadays -- except debian, AFAIK. indeed. i have a debian on my laptop. shit ! Martyn wrote to me : > NCSim is tested against a REDHAT release. The version you have > will only work with [RH] version 7.0 or 7.1 GAAAAAAAAAAAHHHH !!!! i want to kill all the computers and all the computer makers and all the programers and.... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 20 22:13:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcU-0001Eb-00 for ; Fri, 21 Sep 2001 05:04:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:50 +0200 (CEST) Received: (qmail 11496 invoked by uid 0); 20 Sep 2001 20:14:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 20 Sep 2001 20:14:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KKE9S14069 for ; Thu, 20 Sep 2001 16:14:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 20:13:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KKDIx13369 for f-cpu-list; Thu, 20 Sep 2001 16:13:18 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KKDGC13344 for ; Thu, 20 Sep 2001 16:13:16 -0400 Received: by moria.seul.org (Postfix) id 4880B146303; Thu, 20 Sep 2001 16:13:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 2D1851462F8 for ; Thu, 20 Sep 2001 16:13:27 -0400 (EDT) Received: from f-cpu.org (nas26-69.kdl.club-internet.fr [213.44.97.69]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 4489816E6 for ; Thu, 20 Sep 2001 22:13:14 +0200 (CEST) Message-ID: <3BAA4DEC.4D98533C@f-cpu.org> Date: Thu, 20 Sep 2001 22:13:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC) References: <3BA022A3.B361E051@ifrance.com> <3BA0095C.3EE0ACA3@f-cpu.org> <3BA2B861.8E0A275A@ifrance.com> <3BA27BA5.20012549@f-cpu.org> <3BA39714.E27DA471@ifrance.com> <20010915155836.47945@thrai.stud.uni-hannover.de> <3BA80249.4A960EB5@ifrance.com> <3BA7D1F2.1B09240A@f-cpu.org> <3BA93C96.1BEC8D05@ifrance.com> <3BA996BE.B502B27D@f-cpu.org> <20010920124654.A22813@opium.april.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Paul Marques Mota wrote: > On Thu, Sep 20, 2001 at 09:11:58AM +0200, Yann Guidon wrote: > > I hope that we will find some help soon. APRIL, GAOS, CCC ?... > > Don't forget the FSF and FSFeurope. i don't forget but AFAIK electronics is not their goal. They prefer to concentrate on the GNU project. Unless RMS's POV has changed recently. > > We will discuss about this next time we meet (soon). > Why not. as again. > Paul WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Thu Sep 20 22:26:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcW-0001Eb-00 for ; Fri, 21 Sep 2001 05:04:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:52 +0200 (CEST) Received: (qmail 10996 invoked by uid 0); 20 Sep 2001 20:32:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 20 Sep 2001 20:32:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KKWpU14672 for ; Thu, 20 Sep 2001 16:32:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 20:32:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KKWWh14426 for f-cpu-list; Thu, 20 Sep 2001 16:32:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KKWVC14423 for ; Thu, 20 Sep 2001 16:32:31 -0400 Received: by moria.seul.org (Postfix) id 26068146305; Thu, 20 Sep 2001 16:32:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 855701462F8 for ; Thu, 20 Sep 2001 16:32:41 -0400 (EDT) Received: from art1.none.de (dialin37.pg4-nt.berlin.nikoma.de [213.54.67.37]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f8KKWaG25623 for ; Thu, 20 Sep 2001 22:32:36 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin37.pg4-nt.berlin.nikoma.de [213.54.67.37] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15kAOj-0000zG-00 for ; Thu, 20 Sep 2001 22:26:13 +0200 Date: Thu, 20 Sep 2001 22:26:09 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) In-Reply-To: <3BAA4DE8.AAA3788C@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Yann, On Thu, 20 Sep 2001, Yann Guidon wrote: > i don't like to play with definitions and words : it's an endless game. I agree. But in my opinion all license issues are well discussed months ago. Read the manual and you read our definition and license interpretation. > I meant that i will speak with nicO this week-end (we sometimes meet > in Paris). But of course, meeting you will be a pleasure (if you want). > Except that unless you come to Paris, it will be difficult to meet you > before several months. Going to the 18C3 would be a solution. Erm, I am not the godfather of free hardware license politics like RMS for software, I will never be. My point of view is similar with Debian Guide Lines, means: - - open, well documented source (code, documentation) - - well defined and documented interfaces - - no social/political restrictions of usage - - everybody can modify and redistribute - - the license must be redistributed But if we think we live in a good world, we should f-cpu distribute under terms of BSD - means everybody can do what ever he want (except a point to original authors). If we think like Marvin (Hitchhiker's Guide), then we should use the GPL with strikt conditions. The problem is that a proof of special license through lawyers are very difficult and expensive. GPL is well prooved and we should explain our interpretation of license in detail. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7qlDkClxplZklbgERAloVAJ9jtzYiVxEVix/SspbDfph5Qq6PuACfW/JO S/39t3JRawTKUVrdXf6toVY= =xtCr -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 21 01:23:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kGcd-0001Eb-00 for ; Fri, 21 Sep 2001 05:04:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Sep 2001 05:04:59 +0200 (CEST) Received: (qmail 2275 invoked by uid 0); 20 Sep 2001 23:24:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 20 Sep 2001 23:24:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8KNO1k20441 for ; Thu, 20 Sep 2001 19:24:02 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 20 Sep 2001 23:23:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8KNNV920188 for f-cpu-list; Thu, 20 Sep 2001 19:23:31 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8KNNUC20185 for ; Thu, 20 Sep 2001 19:23:30 -0400 Received: by moria.seul.org (Postfix) id C36251462FA; Thu, 20 Sep 2001 19:23:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a082.home.uni-hannover.de [130.75.232.82]) by moria.seul.org (Postfix) with ESMTP id 49F6B1462F8 for ; Thu, 20 Sep 2001 19:23:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02995; Fri, 21 Sep 2001 01:23:22 +0200 Message-ID: <20010921012322.04376@thrai.stud.uni-hannover.de> Date: Fri, 21 Sep 2001 01:23:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: RE: MAC address] References: <3BA90FD0.AC1E6046@f-cpu.org> <20010920005600.37529@thrai.stud.uni-hannover.de> <3BA95170.8B17AFB9@f-cpu.org> <20010920142311.21025@thrai.stud.uni-hannover.de> <3BAA4DEA.829271E5@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAA4DEA.829271E5@f-cpu.org>; from Yann Guidon on Thu, Sep 20, 2001 at 10:13:30PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 20, 2001 at 10:13:30PM +0200, Yann Guidon wrote: [...] > > I used to compile with both of them, and change all code that didn't > > work with either one. > > i want to continue in this direction. I believe that (if it EVER works) > Cadence will not make much troubles but i will constantly check against > all tools. Yep. The more the better. [...] > > > lazy guy ;-P > > > (heck, that means that you're a good programmer, in the PERL world) > > Also in the Unix world. "Do it only once, but do it right" ;) > what does "once" mean ? write or instanciate ? > i prefer to write, rewrite and rerewrite many times : "do it again and do it better". > Otherwise there would be no point to make yet another Nth CPU :-/ If something is good and useful -- use it. If you think you can do better -- do it ;) > > > i even guess that you have made a function with it, that you included in > > > your .bash_profile :-P > > No, functions belong in .bashrc -- because they're not exported to > > subshells automatically ;) > thanks, now i understand some bugs.... :-) *grin* > > > If i survive to the installation of this ncstuff, i'll let you know... > > > Ok, now, let's see if i have libc.so.6/GLIBC_2.2 available somewhere... > > Most distributions use that nowadays -- except debian, AFAIK. > indeed. i have a debian on my laptop. shit ! > > Martyn wrote to me : > > NCSim is tested against a REDHAT release. The version you have > > will only work with [RH] version 7.0 or 7.1 > > GAAAAAAAAAAAHHHH !!!! > i want to kill all the computers and all the computer makers and all the > programers and.... This seems to happen whenever you mix free and proprietary stuff. It's one of the reasons why I think that *any* additions to the F-CPU should be free as well. Otherwise, we might have the "works only with Red^H^H^HBlueHat F-CPU" experience one day. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sat Sep 22 10:42:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kqfQ-0000Ng-00 for ; Sat, 22 Sep 2001 19:34:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Sep 2001 19:34:16 +0200 (CEST) Received: (qmail 14621 invoked by uid 0); 22 Sep 2001 08:51:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 22 Sep 2001 08:51:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8M8pHP15872 for ; Sat, 22 Sep 2001 04:51:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 22 Sep 2001 08:50:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8M8oce15620 for f-cpu-list; Sat, 22 Sep 2001 04:50:38 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8M8obC15617 for ; Sat, 22 Sep 2001 04:50:37 -0400 Received: by moria.seul.org (Postfix) id BF18F1466FF; Sat, 22 Sep 2001 04:50:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 3B7F71466FE for ; Sat, 22 Sep 2001 04:50:48 -0400 (EDT) Received: from art1.none.de (dialin197.pg1-nt.berlin.nikoma.de [213.54.64.197]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f8M8oaV23793 for ; Sat, 22 Sep 2001 10:50:37 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin197.pg1-nt.berlin.nikoma.de [213.54.64.197] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15kiNu-00032V-00 for ; Sat, 22 Sep 2001 10:43:38 +0200 Date: Sat, 22 Sep 2001 10:42:38 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) In-Reply-To: <3BAA4DE8.AAA3788C@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Thu, 20 Sep 2001, Yann Guidon wrote: > i think that we will probably adopt this strategy (if everybody agrees, and > principally Michael) But the problem of the GPL remains : we will have to > "redefine" several terms of the licence, and it would be better to rewrite > it completely to avoid any misunderstanding. I discussed this topic a while back- and towards at GAOS. The meaning was "if you are the owner of intellectual property, you can explicitly describe in which context/topic you want to interprete the GPL (or another license). It's independend to that what other means (aka RMS), because he (or another) is not the owner of this intellectual property" It is easy, is not it? It is right, is not it? It is described in F-CPU-manual, is not it? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7rE8CClxplZklbgERAjnGAJ9UZ8XmIpoy7goG9euK+JSUZJqx6QCfeSvN KQ60rV0wb1IGSl1VxhSFkSo= =9Z+Q -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 22 18:55:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kqff-0000Ng-01 for ; Sat, 22 Sep 2001 19:34:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Sep 2001 19:34:31 +0200 (CEST) Received: (qmail 16833 invoked by uid 0); 22 Sep 2001 16:55:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 22 Sep 2001 16:55:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8MGtoJ24779 for ; Sat, 22 Sep 2001 12:55:50 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 22 Sep 2001 16:55:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8MGtHb24416 for f-cpu-list; Sat, 22 Sep 2001 12:55:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8MGtGC24409 for ; Sat, 22 Sep 2001 12:55:16 -0400 Received: by moria.seul.org (Postfix) id E21101467BF; Sat, 22 Sep 2001 12:55:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id BE9801467BE; Sat, 22 Sep 2001 12:55:27 -0400 (EDT) Received: from f-cpu.org (nas5-200.kdl.club-internet.fr [213.44.0.200]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 79B4D170A; Sat, 22 Sep 2001 18:55:13 +0200 (CEST) Message-ID: <3BACC287.8A41A7D@f-cpu.org> Date: Sat, 22 Sep 2001 18:55:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org, "hardlicense-discuss@seul.org" Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re:[f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello Andreas Romeyke wrote: > Hello, > > On Thu, 20 Sep 2001, Yann Guidon wrote: > > > i think that we will probably adopt this strategy (if everybody agrees, and > > principally Michael) But the problem of the GPL remains : we will have to > > "redefine" several terms of the licence, and it would be better to rewrite > > it completely to avoid any misunderstanding. > > I discussed this topic a while back- and towards at GAOS. The meaning was > "if you are the owner of intellectual property, you can explicitly > describe in which context/topic you want to interprete the GPL (or another > license). It's independend to that what other means (aka RMS), because he > (or another) is not the owner of this intellectual property" > > It is easy, is not it? > It is right, is not it? > It is described in F-CPU-manual, is not it? Of course it would be good to have a "serious legal advisor" because i don't think that the existing F-CPU charter fills this role "completely" and in a legally enforceable way. To answer your questions : - yes it seems easy. The manual gives some background and the place to define the exact meaning is the charter. - whether it is right, i do not know for certain : i'm not a specialist (otherwise the problem would be aleardy solved). - The description in the manual can be altered whenever needed. I won't do the licencing stuff alone : i count on you all (f-cpu and others) to participate in the discussion and find the most apropriate solution (that is : not too much compromises). I don't have the courage to do the chore of rereading the GPL and make a glossary that will help people interpret the GPL when applied to the F-CPU. If others want to help, please let us know. have a nice week-end, everybody. > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 22 16:12:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kwpc-0000Xr-00 for ; Sun, 23 Sep 2001 02:09:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Sep 2001 02:09:12 +0200 (CEST) Received: (qmail 4733 invoked by uid 0); 22 Sep 2001 19:37:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 22 Sep 2001 19:37:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8MJbWe28034 for ; Sat, 22 Sep 2001 15:37:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 22 Sep 2001 19:36:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8MJaef27549 for f-cpu-list; Sat, 22 Sep 2001 15:36:40 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8MJabC27536 for ; Sat, 22 Sep 2001 15:36:37 -0400 Received: by moria.seul.org (Postfix) id 3CB11146687; Sat, 22 Sep 2001 15:36:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a180.home.uni-hannover.de [130.75.232.180]) by moria.seul.org (Postfix) with ESMTP id DDE65146686 for ; Sat, 22 Sep 2001 15:36:46 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00592; Sat, 22 Sep 2001 16:12:05 +0200 Message-ID: <20010922161205.10939@thrai.stud.uni-hannover.de> Date: Sat, 22 Sep 2001 16:12:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <3BAA4DE8.AAA3788C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Sat, Sep 22, 2001 at 10:42:38AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 22, 2001 at 10:42:38AM +0200, Andreas Romeyke wrote: > -----BEGIN PGP SIGNED MESSAGE----- -----BEGIN PGP UNSIGNED MESSAGE----- ;) > Hash: SHA1 > > Hello, > > On Thu, 20 Sep 2001, Yann Guidon wrote: > > > i think that we will probably adopt this strategy (if everybody agrees, and > > principally Michael) But the problem of the GPL remains : we will have to > > "redefine" several terms of the licence, and it would be better to rewrite > > it completely to avoid any misunderstanding. > > I discussed this topic a while back- and towards at GAOS. The meaning was > "if you are the owner of intellectual property, you can explicitly > describe in which context/topic you want to interprete the GPL (or another > license). It's independend to that what other means (aka RMS), because he > (or another) is not the owner of this intellectual property" I tend to agree. But we will have to find a common interpretation for the whole project, not one for each developer, and we'll have to write it down (in a separate file, because we may not modify the GPL document without permission from the FSF). BTW: Since almost everybody on this planet seems to be preparing for war (some also call it "justice"), I've been thinking about some usage restrictions. I don't want my work to control a cruise missile that kills thousands of people. IMHO, the freedom to use the F-CPU can not be infinite. It must end at the point where F-CPU users actively take away other people's freedom to live (or any other freedoms / personal rights -- free speech, privacy, and so on). The GPL is a little too "blue-eyed" with respect to that. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 22 21:34:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15kwpc-0000Xr-01 for ; Sun, 23 Sep 2001 02:09:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Sep 2001 02:09:12 +0200 (CEST) Received: (qmail 3035 invoked by uid 0); 22 Sep 2001 19:37:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 22 Sep 2001 19:37:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8MJbWi28040 for ; Sat, 22 Sep 2001 15:37:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 22 Sep 2001 19:36:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8MJaXu27510 for f-cpu-list; Sat, 22 Sep 2001 15:36:33 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8MJaVC27506 for ; Sat, 22 Sep 2001 15:36:31 -0400 Received: by moria.seul.org (Postfix) id F0391146687; Sat, 22 Sep 2001 15:36:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a180.home.uni-hannover.de [130.75.232.180]) by moria.seul.org (Postfix) with ESMTP id 18118146686 for ; Sat, 22 Sep 2001 15:36:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01821; Sat, 22 Sep 2001 21:34:29 +0200 Message-ID: <20010922213429.21799@thrai.stud.uni-hannover.de> Date: Sat, 22 Sep 2001 21:34:29 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Something new to play with :) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mYCpIKhGyMATD0i+ X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mutta01817 Hi F-gang, here's a new toy: an updated bit shuffling unit. It performs the following operations: bitwise: shiftl, shiftr, shiftra, rotl, rotr, bitrev (shiftla would also be possible) bytewise: byterev, sdup, mixl, mixh, expandl, expandh That is, all defined bit-shuffling operations except bitop (which is IMHO better done in EU_ROP2) and widen[s] (I didn't add that because I'm not quite satisfied with its current form). List of files (in compilation order): f-cpu_config.vhdl eu_shl/bit_manipulation.vhdl # generic support package eu_shl/shuffle64.vhdl # the Shuffle64 entity eu_shl/shuffle64_test.vhdl # testbench Can someone (nico? Kim?) please try to synthesize it? I would like to hear how fast it runs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --mYCpIKhGyMATD0i+ Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-shl-mr-20010922.tar.gz" H4sIAKvjrDsCA+w9a3PayLL5av+KKdepCji8JDB2zDpnwbEdajH2AbOJ761bXCEGo1hIHD2M ya8/3T16wsgP7OScu9dUZY2knu6efk13z6Cd6HO/6E7N4swpqpWKUvmoquV3r/thtcr+3h57 xxhTajX6y9Tgr/hUGNuv7lWVulLfqwKUul9T3rG9d7/g47ue5jD2bmboU42bmXAANpm8+8t9 JjL9T4pwd6jb1sS4Kd1Nx+bLaCiVSj3Qu0T/qlJV9lH/YCXVaqWqAlRd3a+8Y5U3/f/0T7HI Tg2Ts9Pi8eUgqfJteJLT8+xasyx2Nmh/vugWmK17JVBYgYGpVBBiMV3ecP47GUzJdm5YmdH3 3/mNY/tzt6TbM4TDf3eVksoO2bkQNOsZfM4ZfLdu+JidDnvN7tlJAFcFuOsz5s65bkwMeOxN OfNd7hRn9hjuaCNgGZgFpVieyz6ws8tOMLSGJHps7thz24WRnYuz8+a3fvu/TgqIUhuPA3S9 i0s1xlEKhu/BcMu+KzFlX8wyMarfG7Z7/xi2mn3ABRdXvealuMLB4Qce9K/7x81OJ4Yc9DqM e3pIpB4SUesJIjP7Doi49ozDEOZ6/mTCPJuV//zyuVM+GQxdJxi+D8PHXC+xqiLjEaY7PP4y 6P4xxFkzzaK7V53WebvfJ55CjTCm+47DLY853OSay1cRh4BXU8Nlc02/1W44QEwMi7skxB3Q n6PpHncM1zN0tjDG3tTdYfYEhyGEYcFDSzOZbxkgZnYpCDkclesRCHz3HEP3DFAGiohY201o Dtjq2DcqYCX4vvGDh98dfgOUueMCITZaelxokh1rcMlh8kvi4IY7TBuBgJntMP5PH/gB0aqg ATABB5mxrTFMyabBGquqxZHhMWM2N/kMBKQhcwVWjaAJGADrNQK8Aw4AQtAmaRlCQDPbJTS2 g2YGMnS0GQd+C/R0YjjweGF4Uxq4mIJvMNsC2wb256a2LLEWXjh84ps4mQXeuoKRAYMBXUBh kseCWQE+27llS+4lZamAADuktrQsu/6sBbKBK13T4VrA5M4H/SuU38mfJ918PKmIfTAC+O+M gKf2gs1Q0B0lQGLSfeA6FiAfC9m0PTaDkIu4Px3VyDiH/I5bQ7ija+DiIWNACgzKNyE4d3oD NuMYKQyXogmGgjGbgCo94sqxPdtbznmJNU3TXsCzO830AxZqBVZHrR+wnDfVPFTMISFRwPnq NXyk7tUFzwW82lNUYUngA3+0aOgfrXyJnduAbWH75jhhM4SJLKGjitmXSiU28j2iDSHINTBW GRO2tH021cACuWX7N1O0etf2HZ2nbF5ptsiH2GFzPEYQ1vJd4VYFNHHUO/AGcdO39FvQVFX9 sHekqAdnrYSeEtpBWQqMgWC1AC9EZlSnZ5P2QQcOapBwxFpM2h+YrG0LTYPpuWxm3EwxcvzT N2CqIICLK8SUnhdjTbijubZFMZv0QprTmDvTTBNYdY0bK5ArWIVSZzn1vIWYNGIUxxGi+XTp Gjp47ozPbGeZLwCANgdBuyET4xL7qjmWYd2AlXspgxV+bbq21HJDmdC8SHEBLXO5asKBrq4C w7sB/GhSE4dziN0TbwHDG6Rs9GHgycDgBgYBRuChvZdh8rSKLREP3POtMXdINciYG+rprDtg Z9ziDsz40h+ZEF07hs4tcBGY8RzvuFMw9dEyDLWnyEM/4IGd2oCY4laDcYgwQCOMFpH3BwjR 7Gm9B/cAzsEg5jguT+HT1Lx4aClj+vEsx2iliHtqw/IuPM6j+ITaBcdFS0IU6CNf21dfLgZX rNm9Zl+bPUgBrq4bFA9teIpxQawhoALMAmBeDkTRZbC8nJ/0jr/AkGar3WlfXaOnnravuif9 Pju96IHhXTZ7V+3jQafZY5eD3uVF/6QE6zNHtsikHhDxhLTk4GrnaYYZ+eg1KNadkrGSMztc 5wau2xo41Hz5uPIQiWbaYKI4zSiAoSAbGCYggBfYwjHAXiCsrKkVh8eaLbC2pZcKbO8ju+Jo p7C8ajros+8jAkinC6wFKxBCnjehzlIVRSkq1Qok3IN+E+e03Wm3es3eNTM4541tzGAG/RO6 KrneeGjaN4Y+VJR6rQQpTWN7O0wDTuOEESxgG3Bt8iE9ptdISkUT2d3hpqgRN6xvIzDfT0dq cvUWa324eEc5BMw+JJvOPizN81GVh0es2iC8D+cgSURSLOrubkzgMYyYNyUxDmBcGl1IY5cd CGQ9zKophka4glUA8jsTwz45M2OuP8KVM8y/0ZdDvA7hQGJFhY3thQUSqzCBH1zA8XTwURHK afGABWUGwSWTwJ8nx1fglkAB7coXhnUHSaDt5ALy+QD9SgobCGFFqkmIlDRgUQc0LzDIPubg mqNPwYl0gTYyxwIbofuh+ZweVyBZgyXiJRa6KY+QbB3jMg0pgAvRERwIGHR8kUVTXgUhQsu/ xHc+A4Jk+mE7cSbBgXYiT8A8RJh+PuVEyucgnVkxf0i4hKY3yHJS+JtS/NhEEPg3yXVzIjOx ROgQaWaYq2ueB4HWW51mIrtOGiIL2cggjWEgGruCstsSafR64IipNV5iQVhG9LHCBsy9KOAc QhaAaRUm2I49g9KxNM0Hi99XXM3DUjxcBkUuA7ULLNZRroQpGALquIRSur2LRWh3cN466fWH kAaycDxmBXOwVVzfp2LBD8vpQAMgtUQShsWx6BqIBJMQnzbP251rgTdqG4jkl6IPCh5ZyYHP FsBxFSzH86WQUFixzTjKHlxbpCqixnChNtZpRomaRLfHEZsuD7yOsh3MvTB/mkE8Fwh0Dgsb WDVykOC5f3VyednunhHXaZ5nmnsLgfvOcGmRRyT8XkMZxMMHvQ6NBJNB7GJgm6ptDmtEr4Pi dCjXYSIhL7CI4zBJpDhh635U4xL7kDBA4spyEEixvgd27kuhDXy+YF1I9M8vPrdPrwm5Tbll vF77lokeTXTFrHRC7eJwobkS6/IFTMIViaE2n3Mg49qwZLC+py2Z51si3d44eJkaeCuYymHS q0BsnWb/agj36ZN2rbrw1djqkMFIp0kTpBQX7QWswFwhENi4hEClIQcVZpsCjRkVPIU5EfAh 2CuBecw0qPMPWeUeF6IjVqtU1TE7LOZXqAjfYBKGlIYUNHCjFCgiF6yEZllON0dWMIXGLRFz IwOUyK7yRzWSFdbjGlTUC6Ebb2FDVsdqK8gwL6CMYI1utZEBuk53PS+DsB8UcUoBEn9nvMBy E/P1JM3fjtjB6uSQgCITfq0hBZUJX5Fyom7AiSrjZE/KiSrjRJVyUt2Ak6qMk7qUk6rUIKWc 1DbgpCbjZF/KSU3GSZBy99vnn4OEhbnAVYKTksTyEsmrhPxB48EhMjbSELthIVD+WmB/UtcF y/Slpc0MHXMs3QmDmWj96EsdV5c01ePr407IX5raR4H+0rExRebjgqB0DIuRY5tu0MLDzr7o 1qxivmyehdFh1dgrAnW7948Cwxa76GCLljr77s/mzMOeEKYqmKZhbAbaGCXmITcUmFmRsvNV ymELX0JZaTBG9bXI+Eh/FPpxVXX8ueh2cTddigQ45VFHWQt30a7BOmxV0J9ovumJHN5dQlY2 Y0DddlwZopBqGtF6bEnsSKzA7gmiF/2QGLa9Moav11rKmssmNxpWYPcFKYBgMwNTBEebb4ep KGYscd0bNonFfg+nemtuGyI7EymS5WtmIUhtYG2Yax6VQ+E+y1WqjkY1Rv5IGdVM9IKb/eN2 m2Q9Fzso1JapuKtmg+wxqSso4GpAL0iWaDPEpZQpKI7TWwQFLE4Q0A0epzv5pZKE8BDjyROC RJgSBqDYksNW6BHbmXre/LBcXiwWJbFXN+Zl0Xkt72xcRERVBG2l4f4OtV25m9ybEyngMkzr 4w6MZukcNOwteNDlGxmWRm2EschLqVkN5bdGOxv2nAdNBSQJJLC8JbXq9hwNhJJdSrdt645b Bgf8NBBiQCqFDpvxiyDXn2m3SJBprstnEFgc8HcciPtuJXY85RDQRQFoiqnS/mjcITQsYU3h 9tWmSWtCl0hl2Ox+ltpbOo0MQbuPJ3gE+u2iJ8WqroPGkA9lUgTazcBakzAQwz6QhQQMdNnj aYJgIJbW6jq+zcGYEt1K7A2FTcyRPV5KOplk1YnNKMO0b9gElnZR52GTzMbFAFtegJ0qAtcQ FSHVPUsL/cCgzQtcliBCuRik4O5SbDA49p0xFgWi8IvIaINVS2S+YusSyGsOxKUZyznYfYJx /jzP/vu8F8aN/9kO2RPM5u5jOTTYSOztJtWdB/bhyopuGri+3AEZ4nmZGL49gjCKCf4ysqnF FJ3hnn0SqHd34Zlp23PqHxPYkn0QoCh9fITfA5LLBukEGW08aZ7XZ/E8EZwtbNo0MUg9DuU2 4MH2ZFIcLYuKWC9xI+7vabGoKbk8RwSJ+z8eFs0PiZB+ZAknAP8B1z/E4hjuHIGBGbqo3ndM w/NMvgOinGLUxLyNHdr5R4WrNl7cBRUbNmzhYI0OaxYEvdgP9LCBA+mk6YO2cJjQxyQ2dYuj 9WNox5CJm/3RHq9jf4d8bfM6f82z3719XuH8F/eHcOvVjgE+//xfTVUrb+f//t36h7R0CGm2 MfdNkXlteBTw4fN/yr5SD/WvVvYqoH/4U6u9nf/7Ref/pGqG4hlKNJ2bJtcs26ejESwJFS8D GPSP7fnSofMgueM8Hh1TVs75/RbI93fX88clqBWKsJRZNqzqUIp8ejtU8Xao4i9zqAKx/a09 PpQ7VuGOKSWFXKRc+VhWVYiJh9XqYfUjC1yEndzP2d+2t01j5GDW1D45OWlsYzWC31YPZWim mTiU0QKS50kvhZR2SzTtwda4OOAEtoRb9rjxvr0V5cfIbQiWa0KOC2BrG/VRyrz2pEF0sArT NVfXoBaKUQd3hljVb4wajC8bMxjWxoitQwX5TmCFAOPrz2c3RgdF9jq6+2cyGaOTYdsImckn HniaAf9dlPFcn7MsQvkSIzfFw0zMgAY/rCueR2WQuHu8Ouox0af4sV+PocfoiiKT44nlmIU1 qtrjZJ9JVyyRDynA+bUKSDNkvx5Hz9BAgoc1sq+rAiwXVyNkY6UZJI2grxUkCdlWfMgj3ZNp vje5deNNcWZRt0HTCmy5pG7u6qGpTuJcVh4GiV5EsTh3tJuZFjehhvZkAiixv+kg0U/YQpSB WQilESvIAy7XBq0W2ntxGIy6GCD05TJn5BFO03IdSBUV+GcgC1txQ2JrK2xILOEC7yeEB1J/ teVhQ6GORk8SajzoVimwWxX+VYlF6lilAFyPz5O9oZ+nkAqmMcoeSXpLHMcLOjHicDnqSHBz xGrYnTPIW/g9Zo14yIYefjpiHbqPeL9LFb11qyCO76Df75hgsxygo9F59kFgKWIni0BVBIUB 4kFws0o31dRNHXuGue+sHGBCxDWhRvgQg1V29Elcbo1Gue+hsX3P09YAfLtV4q9q/LWabySw qM/DkhyqPGFoEp5OwbhZgwQkOgHOXSgj4SmBkkejDBfStMCFEq4idaHN8qA3D/p/5UG47ShM P/imRt+e6j4SFE9znmjgv893MBN4ebK/kc88118KkJ5aP9UhCH9gxZERP8U5Yk9AFEeBCd8i MrxRxq2/rYTD3SYPkUfOAQqOEonarvGhEoVXvFJSV2rqKrDUlCWQVyD1lDtE3kCWF1O7TVG7 TVG7/RAadOQIj45OwCty+AREZPLM8k0zmkpk4YFecvj3A6vmQ4FKDTxHqPFRbMwyG39uBfqX t/Gq8jIbV59r46qw8XsRBlWy8UfsWE3Z8ZplqS+zLCUfTuNplnUvj55vhvWfETyFXQWxM75Q kxevFDlDhLdJUk+Mm8mx/0Fhc8W2f1kz7OnuoJmG5j7JF+hsW8ohntVFwBqfJBlL/JgUYUxg vr8Bj3DfCnoBCRTdqC1Q7K66Jh1LmMg6A0LSryD8R2Qczi0AEjRyzQLrFtj7yvv8Y+y8Zjvq UYaaueZ76o3l03xp6QD8ZqRPNdKUQUZmmjDdh43UWbcK5xcYqZNhpJns/GwjdVaNFFvo+TRb Wlaz9e3Ezf+d8x/u1J9MTF6vvfAdUA+f/6hWlUotOP+xV6upeP5nv6K+vf/pV53/SKuZ0VH2 Inhu8KMz/NYnEDxMPrAM7+3Ax9uBj7cDH5IDH2lPopMetdRJj4PDqnJY23/BSQ98iO93Kq0u rcFBEPztNai2H3JCC/gNyhCEl4NF/Gv789WX1fclbG/h8o0v4CAYCgqwinMOF1m5RI4wreb4 4VA8G2x5cKP13OHBDz1AtfQjrtzMx5+AmEvG73XTd8FM8gDYRyKdVdyN8Ekv+0lT9qhny5HB fSkqkL7D76RPluDo8kf9sT+X3T837mW3wTiwvyh5AlL63ykE3/dsYmo3wsuM+zIXA5IvggDg LwCYgYR+skhSRjwIPMjSlrqmJ9209duyw13ulbl4u5NhzX3PZTnfwh/Po5qOzVupWF1POmNL chcihrAL3wPs8P0agDCwPcGkyK4z+j1BVhs0fYRbCF+ARJdcYUfcDH+KVq/twDMXN7DRxSYQ 0HxYpTIaRZj+Rl4Ijpl4nQhnLY5hb6jQj8xTroohHSyouDDG+C6sQwXI3ydSfG00dCFw5Ki6 erpfYdJP23XPG0K/GpEOqcbAj5WMj9V2+9LKjjpSLg9aUdT8+bZT2cEaTxR9ULyxaGjIcwCn pOGUvQjuIAWnpuHUaFZKPQVXTcNVI1GptRRcbQXuYwhXVVNwe2m4WjSPWnoe9TTcXjSPWnoe +2m4ejSPvfQ8DhJwo1G2/D6m4TLl10zDZcqvlYbLlN/xClyW/D6n4TLld5KGy5TfaRouQ35x l2Gt7fD+G9TlmDqPbeu9R2/M2063Jle7CcKRsXxPu7wqXJ7lMKr7+KMbeu0IRoqR4RXFuhy+ 3CeOC1Nj47hwf//gkPLBW2T460eGpMcn7Pr+PqfkM105DVjNZ/poGnAvn+l8acD9/M/yPuEu a973Mel8Jr1q5CnOZ9obO9+bH/11V9ikhYq+7c8wZWF8oSlrLtR5YKsLA1+yHJ+sLTu2p3k8 /hk9gXcvrk7EWzTCIdFzl37/jIV1KWHprjEbD4Myl2ELuFVgg4ebzVuMsR6W4yf33sa7DYsN dxsW0t0GMSTj+ForwL06shWP9H3pyEHGyEF6I3v6OKfpAeYzB2REgewBI1eXjqhnwHueFDwO AivwnMsZWk8t4t371MZ9fH9qFMDipehqu4gxn4kSQ/Tho6XtI2cEisWgYFzQVvkBlIwVFtaL i6hW1OCb6RnYS4K1A4LCetkYnTdYUNkpQQIF50PjQkPFU4j1aHiL3jxu2+IVnQ8iGCQQVCME g0cRyAveREuB3ujM7z1uuRRpttAA0mFOEfEwOjXh+yvnJukwhIonL7+nz0JwHrBdvi2r0nMR xoSpu8bu7Qc8NvFbPCDaDUSGchEIbQXi+xx8P3XaUOwCpo4OJL/DZL99+3aILzih/6MASM2f /z15xjRt3xF/QFsc2xBfsGWDoRH/IhcQK8NzZQe7xof9tWP1QpiePfxWUXKc5xuB6KMMBWiP jTtjjG+5F6+jxbaFGRZpafcIHgTo4CrfeMIcMALIFzjPS8SBg3CblWYS3d01QtgEac/Lx0dR kKvkIZSdSkVkJmJIsAXpwapSKQg5Jk+JALQih1ak0EoGblUOnYG7KoNWsviuyaEzcO9JobP4 rsuhM3DvS6Bjxa5rWpqhpI/haNN1jZOq08YhYM1MWLa/foBEeEHQgtRMfBsnpDX0tth/tXd0 TW3kyGf4FRO/xCbmMvI3cZwrO5AiVXDZ8pLb8MTawReoM4bCDmuq+PGr7ta3NOOxw+6GRKoK saRujVqtbkkttUQXdYJT4xYf0cotLIaLU1ckqC/XMYeLuyMLAFSzjwiA1cBAA8EM4hkdmccw FTsyZFFHlpbxf3W2zV6dyp59cQll8Jlmq9mo1zhruzjQQVJHhFJXFMQnc2YxrFgxOsmqD2tZ FWJFKtTuNDv1Dit1XVRmob5r7zcH9T22ihazCqxYFVrtRrNWT60qsEAVNNyqdqjXTGJYsXZo 8XaoOe3AAu3Q4u1Qs9uh3epwXA+V2V99x3EHA4Azm7DN/9V9VOerHHfAcVe1vkk4K0Z4g6el DuEsQLiGU6hNnsZSm3AWIFzDaZ7zNF6Puo/q8FzBreI5mvu1Yi/K84bLcxbmecPnOaR5qAGe E5zFc0jzUX2eE5zFc0hzUVnqfpVw3e7C03xU76uI6/W0dstDZf5XAdfvpG0fNfBVjruqf5tM ZsWYnAaYzAJMTn0ms9RnMgswWcMp1JpI81Htr2o4hVoXaS6qy2QNp2VZpPmojiwrOEOWKc1D 9WRZwpmyjGk+qifLAi5blu2ZiDmBSXRR3hSGinOTLWuLufPIV46jL5MCc+P7+/CEhmyO5dEF zLeqPEqnsZXBiYNVhMlkaytBAyQhTGHJGwBe5W9rGmuAFvkUA+z4nuGv4FsMLDVnN9vaCHP8 Yf/g7NfD9+9OjuCWPV0M3DAp5iA4D+kGkYY+UspWIvV9JI3lIw0/nBzRJYAuksIKIg0zkCSW jzR4fzI8+G8YSWAFkE5PDgAriERYgYbY//hLVvXkhM1DOn7/6SgHCbCCSIf5SMxHOvj0S/8/ +0eZSClLs5AOc5DgS7zPXn6Bx+OO4ZCCAWtknZ7RuQ46wVHM9O6hDtdHVUdA1sXjSxU0tRbE FOZ6rofwpIa8twVb5HUPz+twieXqi47EVHk82VPxIcY7Ot7HhDYkQJNhrCViBNyEGFGH8QbG 6VgLJqBHCBxmwRj6eBxfLjGCHhx0cAXjWDE4gQIxS9Pi0YxtfV7oZSIs1C/BkME/tb0l7s1U duaqIoGqjlWumCY+3MosuPuyylyaj5RhAq4Fd1okkbfgr4s/RkQvLFWhzj1LV2t6kSeSaqyA 2WU595dL89DVlEqdmkmjpFzSl22U8L4TMhOhbRqfRJPP1KnaGDc1lOm7gVoul0Y1j9TZ9EAR y6VT9yOr7pLfekfidx4vzy+m5WWl8jzpJb/PL27LkAbx0LF/+W1gi1qIf9TLcJ5ubHMpaxIf qk0bg19vK7tir7dkCabZO1CCmV2xZ7SyhDrLLcHMrtjTJVlCq55bgpm9xj6Us/OkdB5nnppk CCE1tlJRudHzpeWxUBvJHNQFnFLjkx9UD5WQfEstQ9oFtYrUJqhFKkXs+e0Mkc1TDpYleWP1 IOUdZm1t5IMgSBhahUkKiJMpTUzhhMqEBiYQ0TKN7FXQADLFsVJ9zLbkOuZUwSOSN9t8RCJB 0utOsi1AZgFmGGJoCDcBG81WO2W1ugfIHEAAAmC9VucNZgpOoLrmjNABtAuHdRhLWQDQqQUQ 7zYAArrV9ZYjvJdfiJ+0Q/DH6IbORuoL6f9tqRJt8ZKFvmsftPabbxuOjUfbtxTgQbu1/7YZ AGQu4P5bzwyAYAHAQX+Pr6ETSQEcrodHf881hdM1KfQ4Nqj3a3usk7r18Tg26Ndrex0WAGQu 4F7H4xi2WCbHMikkJbUeGw3TmWajNIB6gD4bgVAfsBAbU7YJG4nI6ZpEepw8aL1t9GsuJ4lD FiD0U5+TxKECnKTOui4ns40DqpwV455a8Pvn4VYu+umYnxjh+Ei8ehVvrBCyx1lhksCzwWoY hSVB1VwPmZFhVa1ZqsYqxBpRr67sNda3jYJQmhqOoG56PLq6Mqdjpl3hwVjGi/tgaG5ikNUN YA4lprQaPBhL+4yChk5BYkXvQFObuaBiHf9grNAf9MJ7m469PBir6gd7sfxgL4PdbwruBKZq Btxax4ZOw70JvTTFaXS6i//ukjN6skgW816DqwP+B99Lv7n90iv972qR7LZrye7N7m7pVXKD b7lHn84f3f/zbDGZLzZ3As33/2zUG+22vP89bTQY3P+dtmvR//Pv9v/UbMZXmnhkPJl9vkD/ ougSGl1Co0voN7iEauFCv9C65Re69yptvUq9G8AzTiGu6y+KmbOvV+ADesaBdA5EFpMlp9iB 1kWZ2Z53KRLluZieHPx6ApOp397jC3Dj62t4RAAng7dfcTJCEHwOFQZB27DlQIcfcr3o+jzi +NDpCn2+vrq5nsFLOSqTf9isZpYrLPrCamfYNR1g13R4zXFkzfFkzXNlzfRlzXRmzfFmzXNn zfRnzXJozfFozfRSLeyRmuVqmuVrGnY2JW/T9VxMt+TVJ6rLWbumwV5mbm2Fz1I7Bl3f1i3Q aWV5Wmx1llsSNaBxSRsH5hAagFoyBwCb1Mlnz4FWXG+cg9CiBuZjWlKeqycKK44byxTa/hU+ LG+sJxGzDHnVZI48xxSAKtN6uIqYkh3yS/b3z6/PxEnn8nQ8VVVQzgqjs2WV/wkudzeoJxb+ vFz67fBDPzk55IvGZ8+elfiqP8mufLiEPu6PKkyR3d+gpEGwpMEGJR0HSzreoKTTYEmnxUvi zMwuXRbu5HNer+hHa3ziZcYn7gt0VdUp7b76Gd6ePBMjd7i/biXBXQ2dfW++d2d338XVTVBt LOkovr0NEu7rWEQvUMbi+uzrDNTC5Lx8T/dY7uwsxUH8aiJ/VeR1XUtoPyhNntFXTQJkc4Qq 5No3dKHONZso1HqkicKyniRwi3WOpJO7T3jfaCS9CqRDG+2nai+hsMVsHEQbF2hr4bWhvttL ZFlAj3TfGI/4lPn2C77yYrRA2BFEWTaXjvfFjM/66IJKvOmf6/Hd5107Y0kZkN8NM4x6vjiW 5Jg5Ne/E0Gsdc/gKO+y0euMafHvrCtsjNJG7Gt0kZXF5wxsaayty9oZ5NIPjeTBQ4kkG8FiD IwvmDKJqTMUwr16R++4Ub6h4nxKahIOTLUxoVWi/nmJtHhPTKox3CFxOpzBtr0IbnRRjohYw eaIEVpG7nyKhVqFtUBGtEwKM23Dz3fT/VRyi4SzHHPztZngYY1alGQ3/fUqTFWzl81u+urqV hkBlRbYcz+64dNxVM/VE/gkJOCtQJRdEeG/8fMJ7BDyPnuXZFe70XDVYywmpHo7BnKlPC6Xs 06dPpS56ICEX0XAqJgDl0s7ODvYkMFeIkxLGLSkJzy5VlJcRXzHO9A3B2q0ICMJnl5MdUGYA JjwmQuOB+cmS8q0wIXlxlZwC8FVoPPKD1TNBw0MVbZVOFlgyYcJzT5gDdGmiapooaGAk+E0y M/yjto7Lswo0Mc7fyGVqOp+4manK1P5S9sWyKNAjsFzAwkxfXXuX5T+0Nb7L2JIhKpB9Z3i7 kKIHCN5lBlHjuzIQ9cLeJhe1zx+sjPKr2DIvpF87fR9OVtxcz9W3pRDoj3PiygKqoqbAlCOG yyDdyAqJiCMm9hC49t8g+TVx1+AUFKrQLGD36yaTQClyDo7uulwr8h9j/uOPEe9xQCNLZnMJ ZihpPksr8TmZHokNksBzjf+UqfY7C4E2QmIvDTJfW2Sa9CGBtJumO5xLjd3pBHVQqdGmhLlc tPq6/pQVsxyUXB3FUltHDVfoqNuoo6KOeho66k0vU3pN7bT7ZLWTrYTf9Hwt/INoKZa6Wqq/ Sk2Nop6Keupp6Ckht/BgnSm7wGu4sgB6SS9hMlmpCVmQaICgOrPUh6kMmK0MTPE3ugEe6sG9 RKcSayvc4ho3oJz+KgUcuPrhG7mUPi6X0u+MS+kaXPqeBhA49KcGEDCOZI8e4KkQh444dPz9 QwedUhFuEiSArvAWG2VAiKmwF0nWGlyrA7sSj6RgN9MAYkL8F2kBPCJsaoFhrhaIC92oBX5E LUCTmJ9cGZDnh1IGA+nrl6EOyBcwKoSoEL7DFWVwhM8yyas1zG7yz9m/vk2UdaXMnTh5bM/f ihOOeVrYDU/DsLSL7dAo7k9T3FeLW6a0FR99ce9Yep8HwPT72RqUfuyK//GmTgGSK+TmSE6o L6zPdRwiiknpCiFdOWgXGLOz5LzIGC3df7XdV7rbho2+cGIhCuxPJ7C5grNyR4U3lN5PSbTU u6PmZe6w6JjmfgTxU3cZKfE7vlzmWM3A9TqK39MRv/SRxE8NbRmjpDhapfNfBsfQGuc/NvGO OIwlBroiQg4yjOW8FofajSZH2YVMp9qW+D6+vA5kZPy4wqsWKiuYIScJRlP/jE043lT/sbD+ O8zVfxdR/0X990/qvze9HOnlqw46hhwV4U/clhtrRONKTKUR6RB4zqRQXOQS9eIPohdrO75m NOyPgclDpt40KNR9sohcrRLfsq1oaW+jhu+hGPXKr7V5CsJb+BnHLpwjzmT0CVHgLxe/cz2x HlfTNbi6uhsHJ2SZ6udwlfqJ07Kofr4D9cM2Uz+wORPYmM3SQlH9PKL6sfaZQOAW1zfADfG0 +bard3QW+txPJ4uJ1jfQEqFbrui2iO521vNV8eqrGGKIIYYYYoghhhhiiCGGGGKIIYYYYogh hhhiiCGGGGKIIYYYYojhaYY/AVHDim4A8AAA --mYCpIKhGyMATD0i+-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 23 03:52:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15l11P-000523-01 for ; Sun, 23 Sep 2001 06:37:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Sep 2001 06:37:39 +0200 (CEST) Received: (qmail 9930 invoked by uid 0); 23 Sep 2001 01:53:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 23 Sep 2001 01:53:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8N1r7V02080 for ; Sat, 22 Sep 2001 21:53:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 01:52:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8N1qZb01836 for f-cpu-list; Sat, 22 Sep 2001 21:52:35 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8N1qYC01833 for ; Sat, 22 Sep 2001 21:52:34 -0400 Received: by moria.seul.org (Postfix) id AAEF11466F5; Sat, 22 Sep 2001 21:52:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 805471466F4 for ; Sat, 22 Sep 2001 21:52:46 -0400 (EDT) Received: from f-cpu.org (nas20-20.kdl.club-internet.fr [213.44.18.20]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B5A2916CB for ; Sun, 23 Sep 2001 03:52:31 +0200 (CEST) Message-ID: <3BAD4077.A9AB7C9B@f-cpu.org> Date: Sun, 23 Sep 2001 03:52:55 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <20010922213429.21799@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: thanks. I did not look at it (yet) though. When i was at Graham's library, her, home, i read a few books about networks and interco. In the F-CPU we have a very tough environment. I think that an Omega network would be the minimum degree of 'smartnes'. However i would like to design a network with an increased number of stages but "thinner" stages than Omega. The problem is that when you have a 64-bit wide omega network, the "critical datapath" can be represented as the lenght of the longest wire in the slice, and Omega needs to cross at least 32 wires in the CDP (and that's a lot). If what books say is true, the delay through an IC wire is roughly proportional to the square of the length (which can be modeled as a string of RC cells). If we adopt a "cell" composed of 4* 4-input multiplexers, we will "need" 3 Omega slices but it is not dangerous to increase the depth (to 5 or 6) if we reduce the crossings and wire lengths. If we reduce the length of one wire by two, there's a 4x win. However Omega has a very very interesting feature : it belongs to a family where the "address" (binary number that says how much you shift) needs almost no decoding before feeding the mux inputs. One hidden drawback that is inherent with the first naive approach of the transistor array is that the decoding of the individual 4096 transistor gates "takes" much time. I believe (warning : gut feeling ahead) that if we have more than 3 stages made of 16*4* 4-input muxes, the decoding will not be too hard. below that point (the "naive approach" being an example) we need a significant decoding logic (time and space). Food for thought. Once the MDK8.0 is installed on my laptop, i'll integrate Michael's latest files. And Cadence, too. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Sep 23 17:47:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lDfu-0000Mm-00 for ; Sun, 23 Sep 2001 20:08:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Sep 2001 20:08:18 +0200 (CEST) Received: (qmail 20258 invoked by uid 0); 23 Sep 2001 09:36:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 23 Sep 2001 09:36:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8N9aAI08716 for ; Sun, 23 Sep 2001 05:36:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 09:35:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8N9ZNc08469 for f-cpu-list; Sun, 23 Sep 2001 05:35:23 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8N9ZLC08466 for ; Sun, 23 Sep 2001 05:35:21 -0400 Received: by moria.seul.org (Postfix) id E31D014674A; Sun, 23 Sep 2001 05:35:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas25-220.vlt.club-internet.fr [195.36.224.220]) by moria.seul.org (Postfix) with ESMTP id DE23F146749 for ; Sun, 23 Sep 2001 05:35:32 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 86EFA1736 for ; Sun, 23 Sep 2001 11:47:40 -0400 (EDT) Message-ID: <3BAE041C.11FEAF86@ifrance.com> Date: Sun, 23 Sep 2001 11:47:40 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Sep 22, 2001 at 10:42:38AM +0200, Andreas Romeyke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > -----BEGIN PGP UNSIGNED MESSAGE----- ;) > > Hash: SHA1 > > > > Hello, > > > > On Thu, 20 Sep 2001, Yann Guidon wrote: > > > > > i think that we will probably adopt this strategy (if everybody agrees, and > > > principally Michael) But the problem of the GPL remains : we will have to > > > "redefine" several terms of the licence, and it would be better to rewrite > > > it completely to avoid any misunderstanding. > > > > I discussed this topic a while back- and towards at GAOS. The meaning was > > "if you are the owner of intellectual property, you can explicitly > > describe in which context/topic you want to interprete the GPL (or another > > license). It's independend to that what other means (aka RMS), because he > > (or another) is not the owner of this intellectual property" > > I tend to agree. But we will have to find a common interpretation for > the whole project, not one for each developer, and we'll have to write > it down (in a separate file, because we may not modify the GPL document > without permission from the FSF). > Before thinking of the legal word, we should defined exactly what we want to accept or not. And then try to put it in a licence. > BTW: Since almost everybody on this planet seems to be preparing for > war (some also call it "justice"), I've been thinking about some usage > restrictions. I don't want my work to control a cruise missile that > kills thousands of people. IMHO, the freedom to use the F-CPU can not > be infinite. It must end at the point where F-CPU users actively take > away other people's freedom to live (or any other freedoms / personal > rights -- free speech, privacy, and so on). The GPL is a little too > "blue-eyed" with respect to that. > No sorry, we can't do that. Thougth that an army is just here to kill people is far too simple. That's an other debate, i agree. But if we put such reduicing clause, our licence will not be GPL compatible and recognise as open source licence. cf. http://www.opensource.org/docs/definition.html http://www.gnu.org/philosophy/free-software-for-freedom.html > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Sep 24 05:31:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lHFd-0005xh-01 for ; Sun, 23 Sep 2001 23:57:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Sep 2001 23:57:25 +0200 (CEST) Received: (qmail 19338 invoked by uid 0); 23 Sep 2001 21:19:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Sep 2001 21:19:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8NLJjm15190 for ; Sun, 23 Sep 2001 17:19:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 21:19:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8NLJKW14946 for f-cpu-list; Sun, 23 Sep 2001 17:19:20 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8NLJJC14943 for ; Sun, 23 Sep 2001 17:19:19 -0400 Received: by moria.seul.org (Postfix) id 4B6311467DA; Sun, 23 Sep 2001 17:19:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas25-68.vlt.club-internet.fr [195.36.224.68]) by moria.seul.org (Postfix) with ESMTP id 770FC1467D9 for ; Sun, 23 Sep 2001 17:19:31 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 53C441740 for ; Sun, 23 Sep 2001 23:31:41 -0400 (EDT) Message-ID: <3BAEA91D.D2F46EC3@ifrance.com> Date: Sun, 23 Sep 2001 23:31:41 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] Compagnon cpu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just had a hard discussion with whygee about a new idea. I have speak with a guy who write code for HURD. Compare to Linux, context switch is a real problem for microkernel OS (usualy there is 3-4 task running in the same time). So i have a proposal to speed up such thing. I propose to introduice a very simple cpu which control the "main" fcpu. I think of kind of a simple LEON (wihtout mul and without div) or a fcpu without SIMD stuff, without FPU, without mul,... This cpu could be seen as a ressource for the kernel only. It's no seen by user. There is no virtual memory, and it receive all the interrupt and manage all DMA access. This compagnion could access to the register bank of the fcpu and it could freeze the fcpu pipeline. If the fcpu have a double register bank (shadow register), during each access to the kernel, an other task could be run during the kernel traitement immediately. The idea is that this chip is very small compare to a second fcpu and have a direct access to the (some) internals registers. So usualy, interrupt handler are as small as possible but there is some trash in the cache and the context switch. (usualy to reduice the CDP the L1 cache use virtual memory (no penalty to access the TLB in case of cache hit) but it that case in each context switch the entire L1 cache _must_ be invalidate ) So the interrupt handler could be run only by this compagnon cpu. In that case, we could reduice a lot the context switch penalty. What do you thing ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 23 19:51:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWan-0000MB-00 for ; Mon, 24 Sep 2001 16:20:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:17 +0200 (CEST) Received: (qmail 30447 invoked by uid 0); 23 Sep 2001 22:12:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Sep 2001 22:12:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8NMCrh17149 for ; Sun, 23 Sep 2001 18:12:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 22:10:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8NMAhj16645 for f-cpu-list; Sun, 23 Sep 2001 18:10:43 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8NMAXC16638 for ; Sun, 23 Sep 2001 18:10:34 -0400 Received: by moria.seul.org (Postfix) id 57D761467E7; Sun, 23 Sep 2001 18:10:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a044.home.uni-hannover.de [130.75.232.44]) by moria.seul.org (Postfix) with ESMTP id 09C7A1467E6 for ; Sun, 23 Sep 2001 18:10:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01150; Sun, 23 Sep 2001 19:51:32 +0200 Message-ID: <20010923195132.11917@thrai.stud.uni-hannover.de> Date: Sun, 23 Sep 2001 19:51:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> <3BAE041C.11FEAF86@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAE041C.11FEAF86@ifrance.com>; from nicO on Sun, Sep 23, 2001 at 11:47:40AM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 23, 2001 at 11:47:40AM -0400, nicO wrote: [...] > > BTW: Since almost everybody on this planet seems to be preparing for > > war (some also call it "justice"), I've been thinking about some usage > > restrictions. I don't want my work to control a cruise missile that > > kills thousands of people. IMHO, the freedom to use the F-CPU can not > > be infinite. It must end at the point where F-CPU users actively take > > away other people's freedom to live (or any other freedoms / personal > > rights -- free speech, privacy, and so on). The GPL is a little too > > "blue-eyed" with respect to that. > > > > No sorry, we can't do that. Thougth that an army is just here to kill > people is far too simple. That's an other debate, i agree. But if we put > such reduicing clause, our licence will not be GPL compatible and > recognise as open source licence. cf. > > http://www.opensource.org/docs/definition.html > > http://www.gnu.org/philosophy/free-software-for-freedom.html Does the F-CPU license really have to be compatible with the GPL? I really don't care about Open Source. It only guarantees that you can get the source code, not that you can modify and/or redistribute it freely (that's the reason why Micro$oft hates the GPL, and *only* the GPL). I don't like this "you may have a look at it, but don't touch it" kind of licenses. Or worse, "you may look at it and touch it, but all your modifications are automatically mine", which is also covered by the term Open Source, IIRC. No, thank you. I know that I may not be able to stop them, but I'd like to make clear that I neither agree with nor support people or organizations who harass, threaten, hurt, torture or kill other people. Freedom to use something does not include freedom to abuse it -- and we're responsible for drawing the line between them. In fact, all scientists, engineers and inventors are, but most of them tend to forget that fact, or ignore it. Like RMS and/or the FSF did. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 23 17:55:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWan-0000MB-01 for ; Mon, 24 Sep 2001 16:20:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:17 +0200 (CEST) Received: (qmail 9498 invoked by uid 0); 23 Sep 2001 22:13:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 23 Sep 2001 22:13:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8NMD0q17179 for ; Sun, 23 Sep 2001 18:13:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 22:10:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8NMAqX16661 for f-cpu-list; Sun, 23 Sep 2001 18:10:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8NMAgC16644 for ; Sun, 23 Sep 2001 18:10:42 -0400 Received: by moria.seul.org (Postfix) id 5B75B1467E7; Sun, 23 Sep 2001 18:10:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a044.home.uni-hannover.de [130.75.232.44]) by moria.seul.org (Postfix) with ESMTP id 3397C1467E6 for ; Sun, 23 Sep 2001 18:10:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00867; Sun, 23 Sep 2001 17:55:49 +0200 Message-ID: <20010923175549.48371@thrai.stud.uni-hannover.de> Date: Sun, 23 Sep 2001 17:55:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <20010922213429.21799@thrai.stud.uni-hannover.de> <3BAD4077.A9AB7C9B@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAD4077.A9AB7C9B@f-cpu.org>; from Yann Guidon on Sun, Sep 23, 2001 at 03:52:55AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 23, 2001 at 03:52:55AM +0200, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > > thanks. I did not look at it (yet) though. > > When i was at Graham's library, her, home, > i read a few books about networks and interco. > In the F-CPU we have a very tough environment. > I think that an Omega network would be the > minimum degree of 'smartnes'. However i would > like to design a network with an increased > number of stages but "thinner" stages than Omega. > The problem is that when you have a 64-bit wide > omega network, the "critical datapath" can be > represented as the lenght of the longest wire > in the slice, and Omega needs to cross at least > 32 wires in the CDP (and that's a lot). If what > books say is true, the delay through an IC wire > is roughly proportional to the square of the > length (which can be modeled as a string of RC cells). > > If we adopt a "cell" composed of 4* 4-input > multiplexers, we will "need" 3 Omega slices but > it is not dangerous to increase the depth (to 5 or 6) > if we reduce the crossings and wire lengths. > If we reduce the length of one wire by two, there's > a 4x win. > > However Omega has a very very interesting feature : > it belongs to a family where the "address" (binary number > that says how much you shift) needs almost no decoding > before feeding the mux inputs. That's right -- but how many different operations can it perform? > One hidden drawback that is inherent with the first > naive approach of the transistor array is that the > decoding of the individual 4096 transistor gates > "takes" much time. Not as much as it may seem. Every output bit is a copy of a single input bit, or is zero -- that is, you need one 65:1 mux (or 64:1 mux plus an AND gate) per bit. The control lines of the mux depend on the index of the result bit (which is a constant), the shift count, the chunk size, and the kind of operation to be performed. In the most complex case (64-bit left/right shift), you need a 6-bit unsigned add/subtract operation with saturation (with one constant and one variable operand). > I believe (warning : gut feeling ahead) that if we have more > than 3 stages made of 16*4* 4-input muxes, the decoding > will not be too hard. below that point (the "naive approach" > being an example) we need a significant decoding logic > (time and space). I used two stages because the decoding is easier to get right. Since SIMD is byte-oriented, the choice of 8x8 cells for the first stage was obvious. With 4x4 cells, both the second and third stage would need rather complex decoding logic. The approach I used is similar to the one I proposed half a year ago, but slightly improved. The first stage shifts individual bytes by [0;7] bits (using 8:1 muxes), the second stage combines the results of the first. Since at most two bytes of the intermediate result contribute to each result byte, the second stage is a pair of 16:1 muxes whose outputs are ORed. The decoding logic for the first stage (single-bit shifts) is pretty simple -- the least significant bits of the B operand drive the control lines of the mux directly. Stage 2 (byte shifts) needs more complex decoding logic, but does not depend on the results of stage 1 (i.e. it can be calculated while the bit-shifts are performed). Currently, I use muxes (case statement) to select one of 30 constant "byte selectors", but a ROM-based approach or discrete logic is also possible. In order to speed up the bitwise operations, left-shift and right-shift operations are handled separately. A third block (which is similar to the second stage used by the bitwise operands) performs the bytewise operations, and a final output mux selects the correct result. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Sun Sep 23 02:58:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWap-0000MB-01 for ; Mon, 24 Sep 2001 16:20:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:19 +0200 (CEST) Received: (qmail 31175 invoked by uid 0); 23 Sep 2001 22:29:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 23 Sep 2001 22:29:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8NMTjY17650 for ; Sun, 23 Sep 2001 18:29:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 22:29:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8NMTBK17398 for f-cpu-list; Sun, 23 Sep 2001 18:29:11 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8NMT8C17394 for ; Sun, 23 Sep 2001 18:29:09 -0400 Received: by moria.seul.org (Postfix) id A44361467EF; Sun, 23 Sep 2001 18:29:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from online.ln.cn (unknown [202.96.74.114]) by moria.seul.org (Postfix) with SMTP id B59A11467EE for ; Sun, 23 Sep 2001 18:29:19 -0400 (EDT) Received: from there([61.176.55.230]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jmd3bae6c91; Mon, 24 Sep 2001 06:25:08 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: [f-cpu] Far from the last word about license ;-) (long and rambling) Date: Sun, 23 Sep 2001 08:58:39 +0800 X-Mailer: KMail [version 1.3.1] References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> In-Reply-To: <20010922161205.10939@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Message-Id: <20010923222919.B59A11467EE@moria.seul.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f8NMT9C17395 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 22 Sep 2001 22:12, Michael Riepe wrote: > On Sat, Sep 22, 2001 at 10:42:38AM +0200, Andreas Romeyke wrote: > > BTW: Since almost everybody on this planet seems to be preparing for > war (some also call it "justice"), I've been thinking about some usage > restrictions. I don't want my work to control a cruise missile that > kills thousands of people. IMHO, the freedom to use the F-CPU can not > be infinite. It must end at the point where F-CPU users actively take > away other people's freedom to live (or any other freedoms / personal > rights -- free speech, privacy, and so on). The GPL is a little too > "blue-eyed" with respect to that. > I can sympathise with the sentiment. Trouble is: Who gets to define human rights? There is a convention but some (such as myself) find it lacking. For example, I believe that there is a basic human right to a productive life. To be denied this right is degrading and results in (socially expensive) mental problems - I have personal experience of this. Such a criteria would eliminate distribution in nearlty every country in the world today, particularly those in the West who have failed to provide near full employment in the face of technological-driven redundencies. And don't say it is a difficult problem to solve - it isn't, but it has been left so long that the solution would now take more than a 4 year term and measures would be unpopular until it was completed - most people can't think in terms of giving something now to get more later. The people on this list and the FREE community in general are an exceptional group and it is too easy to assume most people are like that (how I wish most people were like you all). But they aren't, though that is mostly a result of inadequate social education. It is a pleasure hanging around egalitarian people but it is, unfortunately, not the real world. I just have to step out the door into the debauched and unregulated capitalist anarchy of modern China to have all my idealistic fantasies of humanity blown away. (I recently switched my day job from teaching MBAs at a business college to science postgrads at the local Academy of Sciences. Things are looking up). Also, is there really any productive point in such restrictions? Do you think someone who designs weapons of mass destruction is going to care about the licence terms? The military isn't subject to patents, so why would they care about GPL or a derivative. You try getting permission for a software/hardware audit on the US defence arsenal! If a government can re-define copyright to flip the rights from the artist and consumer to the distributor, they can certainly exempt any department they like from it. Especially if it's 'for the children' or 'for national security'. Further, even if you could ban the use in places like China and the USA, who is penalised? Do the governments or the big businesses really care? It is the small developers and the users that would suffer. If this processor is for the people, that is a situation to avoid. OT: Did you know the constitutin of China includes the right to freedom of speech? - It just has a caevat that you cannot say anything to destabalise the country, which the goverment uses much more than they should or really need to. If used properly (which it isn't), this freedom would be quite appropriate. In the US, on the other hand, freedom of speech (when recognised at all) is used as an excuse to shout in other's faces with impunity, and to as a lame justification for UBE. On the other hand, the trade lockout on South Africa did eventually have an effect. So the idea certainly has merit. I Just don't see how it would work with just one instance of IP. I have recently recieved provisional patent approval on a fairly broad-reaching hardware technology and, if fully granted, will be implimenting a non-linear licencing scheme based on (among other things) what I think of the particular country's treatement of its people, but I will not be with-holding the technology, particularly from the world's poor and repressed (besides, developing countries are my key market as I can drive very high volumes and very low cost and still get a good returns). Actually, FCPU would make a good core for the device. In the mean time I'll likely use an Axis ETRAX MCM chip - It's heavily integrated enough that I can design the prototype boards myself (I come from the days of 40pin DILs, 8-bit busses and board design done in coloured tape on plastic sheets - though I use basic CAD now, I am unconfident with high-speed busses). -- What a long blah-blah. Sorry about that. I seldom have something to say, but when I start I have trouble stopping! :-/ -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.gnu.org / http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- I break for penguins! -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 24 01:18:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWar-0000MB-00 for ; Mon, 24 Sep 2001 16:20:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:21 +0200 (CEST) Received: (qmail 25704 invoked by uid 0); 23 Sep 2001 23:18:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 23 Sep 2001 23:18:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8NNIW918444 for ; Sun, 23 Sep 2001 19:18:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 23 Sep 2001 23:18:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8NNIAL18193 for f-cpu-list; Sun, 23 Sep 2001 19:18:10 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8NNI9C18190 for ; Sun, 23 Sep 2001 19:18:09 -0400 Received: by moria.seul.org (Postfix) id D402E146804; Sun, 23 Sep 2001 19:18:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a044.home.uni-hannover.de [130.75.232.44]) by moria.seul.org (Postfix) with ESMTP id B5EB1146803 for ; Sun, 23 Sep 2001 19:18:19 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02604; Mon, 24 Sep 2001 01:18:04 +0200 Message-ID: <20010924011804.64378@thrai.stud.uni-hannover.de> Date: Mon, 24 Sep 2001 01:18:04 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Far from the last word about license ;-) (long and rambling) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> <20010923222919.B59A11467EE@moria.seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20010923222919.B59A11467EE@moria.seul.org>; from Glenn Alexander on Sun, Sep 23, 2001 at 08:58:39AM +0800 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 23, 2001 at 08:58:39AM +0800, Glenn Alexander wrote: [...] > Trouble is: Who gets to define human rights? There is a convention but some > (such as myself) find it lacking. For example, I believe that there is a > basic human right to a productive life. To be denied this right is degrading > and results in (socially expensive) mental problems - I have personal > experience of this. Such a criteria would eliminate distribution in nearlty > every country in the world today, particularly those in the West who have > failed to provide near full employment in the face of technological-driven > redundencies. [...] Wait a minute... I didn't mean to forbid the use of the F-CPU in an entire country or state. Neither in the US, nor in Russia, China or Afghanistan. But I want people to recognize that they're responsible for what they do with it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 24 02:08:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWas-0000MB-01 for ; Mon, 24 Sep 2001 16:20:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:22 +0200 (CEST) Received: (qmail 8717 invoked by uid 0); 24 Sep 2001 00:08:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 24 Sep 2001 00:08:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8O08uO19206 for ; Sun, 23 Sep 2001 20:08:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 00:08:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8O08Yj18953 for f-cpu-list; Sun, 23 Sep 2001 20:08:34 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8O08XC18950 for ; Sun, 23 Sep 2001 20:08:33 -0400 Received: by moria.seul.org (Postfix) id 59699146817; Sun, 23 Sep 2001 20:08:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 3EFA5146816 for ; Sun, 23 Sep 2001 20:08:46 -0400 (EDT) Received: from f-cpu.org (nas15-14.kdl.club-internet.fr [213.44.9.14]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 0D51A16C0 for ; Mon, 24 Sep 2001 02:08:31 +0200 (CEST) Message-ID: <3BAE7998.F1EDDC93@f-cpu.org> Date: Mon, 24 Sep 2001 02:08:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Compagnon cpu References: <3BAEA91D.D2F46EC3@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > > I just had a hard discussion with whygee about a new idea. > > I have speak with a guy who write code for HURD. Compare to Linux, > context switch is a real problem for microkernel OS (usualy there is 3-4 > task running in the same time). So i have a proposal to speed up such > thing. > > I propose to introduice a very simple cpu which control the "main" fcpu. > I think of kind of a simple LEON (wihtout mul and without div) or a fcpu > without SIMD stuff, without FPU, without mul,... > > > What do you thing ? I have explained my arguments today. To say the truth, i am not convinced by Nico's advantages. - before we make more complex cores, we have to make FC0. - I will not stop the ongoing work to include that kind of "addition" because (despite your arguments) we have to make something that works, after 3 years of work. - Adding such stuff like that all the time will only make the CPU heavier, more difficult to program efficiently (this is an asymetric machine :-/) and it will never be ready at all. - Only with emulation (FPGA or dedicated machine) we can gather enough "real use" statistics and decide whether it is worth it to include a "kernel coprocessor". This "addition" must remain a user's choice, not a mandatory thing. - P&H's "QA" would say : "if you increase the die size by 10%, you need to have more than 10% of performance increase." However i don't remember that F-CPU was created as a "HURD CPU". - Other CPU architectures have showed that if you want to "speedup" context switch time too much, you will mess up the architecture (register set that explodes and reduces the cycle time for example). If nico, Cedric or anybody comes with a new working core and wants to put it besides FC0, fine. The current proposal is however difficult to scale up (there is no plan yet). I don't want to take this idea down but it will be difficult to find a solution for every problem. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jxmlisa@online.ln.cn Mon Sep 24 04:26:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWav-0000MB-00 for ; Mon, 24 Sep 2001 16:20:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:25 +0200 (CEST) Received: (qmail 4942 invoked by uid 0); 24 Sep 2001 02:25:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 24 Sep 2001 02:25:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8O2Psu21144 for ; Sun, 23 Sep 2001 22:25:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 02:25:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8O2PWG20894 for f-cpu-list; Sun, 23 Sep 2001 22:25:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8O2PVC20891 for ; Sun, 23 Sep 2001 22:25:31 -0400 Received: by moria.seul.org (Postfix) id 408ED14667F; Sun, 23 Sep 2001 22:25:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from online.ln.cn (unknown [202.96.74.85]) by moria.seul.org (Postfix) with SMTP id 4A8E814667E for ; Sun, 23 Sep 2001 22:25:42 -0400 (EDT) Received: from there([61.176.55.103]) by online.ln.cn(AIMC 2.9.5.2) with SMTP id jm183baf0769; Mon, 24 Sep 2001 10:21:27 +0800 Content-Type: text/plain; charset="iso-8859-1" From: Glenn Alexander To: f-cpu@seul.org Subject: Re: [f-cpu] Far from the last word about license ;-) (long and rambling) Date: Mon, 24 Sep 2001 10:26:47 +0800 X-Mailer: KMail [version 1.3.1] References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010923222919.B59A11467EE@moria.seul.org> <20010924011804.64378@thrai.stud.uni-hannover.de> In-Reply-To: <20010924011804.64378@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Message-Id: <20010924022542.4A8E814667E@moria.seul.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f8O2PVC20892 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 24 Sep 2001 07:18, you wrote: > > Wait a minute... I didn't mean to forbid the use of the F-CPU in an > entire country or state. Neither in the US, nor in Russia, China or > Afghanistan. But I want people to recognize that they're responsible > for what they do with it. > Fair enough, but again, the people who make guided missiles don't care anyway and those that do care choose not to make guided missiles. I feel it would be preaching to the converted and add complexity to the licence that would serve little purpose as it would be ignored by those it applied to. I would be happy to see a preamble to the licence talking about moral use of the IP. You then achieve the awareness aspect without obstuficating (sp?) the licence. The simpler the licence (within reason) the more solid it is, I feel. -------------------------------------------------------- Glenn Alexander - The man with no surname and a silly hat. (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) (Now avaliable in China!) http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) I use GNU/Linux: http://www.gnu.org / http://www.linux.org >from Debian: http://www.debian.org and KDE : http://www.kde.org -------------------------------------------------------- What would you expect from an MCSE? -------------------------------------------------------- The above message was bought to you by 'sigrot' ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Sep 24 08:27:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWaw-0000MB-00 for ; Mon, 24 Sep 2001 16:20:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:26 +0200 (CEST) Received: (qmail 12658 invoked by uid 0); 24 Sep 2001 06:35:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 24 Sep 2001 06:35:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8O6ZPR23857 for ; Mon, 24 Sep 2001 02:35:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 06:35:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8O6Z2R23613 for f-cpu-list; Mon, 24 Sep 2001 02:35:02 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8O6Z0C23605 for ; Mon, 24 Sep 2001 02:35:00 -0400 Received: by moria.seul.org (Postfix) id 6EAE71466D2; Mon, 24 Sep 2001 02:35:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id D5EB51466D1 for ; Mon, 24 Sep 2001 02:35:12 -0400 (EDT) Received: from art1.none.de (dialin38.pg2-nt.berlin.nikoma.de [213.54.65.38]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f8O6YxV05171 for ; Mon, 24 Sep 2001 08:34:59 +0200 X-Authentication-Warning: host-2.server.itns.de: Host dialin38.pg2-nt.berlin.nikoma.de [213.54.65.38] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15lPE1-0002DR-00 for ; Mon, 24 Sep 2001 08:28:17 +0200 Date: Mon, 24 Sep 2001 08:27:59 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) In-Reply-To: <20010923195132.11917@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Sun, 23 Sep 2001, Michael Riepe wrote: > I don't like this "you may have a look at it, but don't touch it" kind > of licenses. Or worse, "you may look at it and touch it, but all your > modifications are automatically mine", which is also covered by the term > Open Source, IIRC. No, thank you. You are on wrong way. There are two views to the world, an optimistic -> use BSD-like, a pessimistic -> use GPL-like. > I know that I may not be able to stop them, but I'd like to make clear > that I neither agree with nor support people or organizations who harass, > threaten, hurt, torture or kill other people. Freedom to use something > does not include freedom to abuse it -- and we're responsible for drawing > the line between them. In fact, all scientists, engineers and inventors > are, but most of them tend to forget that fact, or ignore it. Like RMS > and/or the FSF did. But in fact you cannot forbid a abuse use, because you cannot controll it. Will be there a bad guy, who reads and accepts your license? No. What is wrong, if the F-CPU "infect" ideas with their license? Nothing. On the one side, we have responsibility, but we must not include it in a license. Also there are different views in the world, what is moralistic. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7rtJyClxplZklbgERAg+1AJ4rApHTUT6NWeSWwx7Zd4aKzu6qrACeJJfV 49CHzyUiaA9qBoplFUyl4vg= =CSRk -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Mon Sep 24 09:16:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWaw-0000MB-01 for ; Mon, 24 Sep 2001 16:20:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:26 +0200 (CEST) Received: (qmail 22026 invoked by uid 0); 24 Sep 2001 07:16:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 24 Sep 2001 07:16:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8O7GSD24809 for ; Mon, 24 Sep 2001 03:16:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 07:16:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8O7G9224566 for f-cpu-list; Mon, 24 Sep 2001 03:16:09 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8O7G8C24563 for ; Mon, 24 Sep 2001 03:16:08 -0400 Received: by moria.seul.org (Postfix) id C700C1466D8; Mon, 24 Sep 2001 03:16:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 2FB0F1466D7 for ; Mon, 24 Sep 2001 03:16:21 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA07804 for ; Mon, 24 Sep 2001 10:16:06 +0300 (EET DST) Date: Mon, 24 Sep 2001 10:16:05 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: F-CPU Mailing List Subject: Re: [f-cpu] Something new to play with :) In-Reply-To: <20010922213429.21799@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 22 Sep 2001, Michael Riepe wrote: > Can someone (nico? Kim?) please try to synthesize it? I would like to > hear how fast it runs. We should take some chip as a reference and always synthesize for it. Otherwise the results are not comparable. But to even get some feeling I synthesized this block to Virte2 (XCV2V1000-BG575-6) and got following results: Speed: 66MHz (optimized for speed, no special tricks) Utilization: 30% btw. the muxes are quite huge :) FPGA architectures usually have some problems with complex multiplexer structures. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Sep 24 09:16:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWax-0000MB-00 for ; Mon, 24 Sep 2001 16:20:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:27 +0200 (CEST) Received: (qmail 8382 invoked by uid 0); 24 Sep 2001 07:42:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 24 Sep 2001 07:42:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8O7gae25204 for ; Mon, 24 Sep 2001 03:42:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 07:42:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8O7gHo24958 for f-cpu-list; Mon, 24 Sep 2001 03:42:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8O7gGC24955 for ; Mon, 24 Sep 2001 03:42:16 -0400 Received: by moria.seul.org (Postfix) id C576F1466F1; Mon, 24 Sep 2001 03:42:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 35D621466EE for ; Mon, 24 Sep 2001 03:42:29 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 15lPyI-0005vk-00 for f-cpu@seul.org; Mon, 24 Sep 2001 09:16:06 +0200 Date: Mon, 24 Sep 2001 09:16:05 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) In-Reply-To: <20010922161205.10939@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Seed trees, not war! JG On Sat, 22 Sep 2001, Michael Riepe wrote: > BTW: Since almost everybody on this planet seems to be preparing for > war (some also call it "justice"), I've been thinking about some usage > restrictions. I don't want my work to control a cruise missile that > kills thousands of people. IMHO, the freedom to use the F-CPU can not > be infinite. It must end at the point where F-CPU users actively take > away other people's freedom to live (or any other freedoms / personal > rights -- free speech, privacy, and so on). The GPL is a little too > "blue-eyed" with respect to that. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 24 12:59:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWaz-0000MB-00 for ; Mon, 24 Sep 2001 16:20:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:29 +0200 (CEST) Received: (qmail 26684 invoked by uid 0); 24 Sep 2001 11:00:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 24 Sep 2001 11:00:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8OB0Dg29026 for ; Mon, 24 Sep 2001 07:00:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 10:59:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8OAxJF28717 for f-cpu-list; Mon, 24 Sep 2001 06:59:19 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8OAxEC28713 for ; Mon, 24 Sep 2001 06:59:15 -0400 Received: by moria.seul.org (Postfix) id 70D49146716; Mon, 24 Sep 2001 06:59:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4EDFD146715 for ; Mon, 24 Sep 2001 06:59:27 -0400 (EDT) Received: from f-cpu.org (nas5-82.kdl.club-internet.fr [213.44.0.82]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C27BC16CF for ; Mon, 24 Sep 2001 12:59:11 +0200 (CEST) Message-ID: <3BAF121B.1219D33F@f-cpu.org> Date: Mon, 24 Sep 2001 12:59:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Kim Enkovaara wrote: > On Sat, 22 Sep 2001, Michael Riepe wrote: > > > Can someone (nico? Kim?) please try to synthesize it? I would like to > > hear how fast it runs. > > We should take some chip as a reference and always synthesize for it. > Otherwise the results are not comparable. But to even get some feeling I > synthesized this block to Virte2 (XCV2V1000-BG575-6) and got following > results: > > Speed: 66MHz (optimized for speed, no special tricks) wow :-) what is the fastest thing you have synthesised for this device ? > Utilization: 30% wow :-/ How big is it btw ? > btw. the muxes are quite huge :) FPGA architectures usually have some > problems with complex multiplexer structures. this is why i prefered to use 4-in muxes :-) Can you track where the critical datapaths are located ? Can you try on the (new) ROP2 unit ? > ============================================================================= > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 24 14:41:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWb0-0000MB-00 for ; Mon, 24 Sep 2001 16:20:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:30 +0200 (CEST) Received: (qmail 25192 invoked by uid 0); 24 Sep 2001 13:12:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx24) with SMTP; 24 Sep 2001 13:12:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ODCte02047 for ; Mon, 24 Sep 2001 09:12:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 13:11:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ODB7T01361 for f-cpu-list; Mon, 24 Sep 2001 09:11:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ODB6C01358 for ; Mon, 24 Sep 2001 09:11:06 -0400 Received: by moria.seul.org (Postfix) id 791E8146792; Mon, 24 Sep 2001 09:11:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id 7103114678D for ; Mon, 24 Sep 2001 09:11:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00735; Mon, 24 Sep 2001 14:41:35 +0200 Message-ID: <20010924144135.57848@thrai.stud.uni-hannover.de> Date: Mon, 24 Sep 2001 14:41:35 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAF121B.1219D33F@f-cpu.org>; from Yann Guidon on Mon, Sep 24, 2001 at 12:59:39PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 24, 2001 at 12:59:39PM +0200, Yann Guidon wrote: > hi ! > > Kim Enkovaara wrote: > > On Sat, 22 Sep 2001, Michael Riepe wrote: > > > > > Can someone (nico? Kim?) please try to synthesize it? I would like to > > > hear how fast it runs. > > > > We should take some chip as a reference and always synthesize for it. > > Otherwise the results are not comparable. But to even get some feeling I > > synthesized this block to Virte2 (XCV2V1000-BG575-6) and got following > > results: > > > > Speed: 66MHz (optimized for speed, no special tricks) > wow :-) > what is the fastest thing you have synthesised for this device ? That's nothing -- the multiplier was faster :) But I'm quite satisfied with that result. > > Utilization: 30% > wow :-/ > How big is it btw ? The multiplier also took something like 30%. The SHL EU is very space-consuming... > > btw. the muxes are quite huge :) FPGA architectures usually have some > > problems with complex multiplexer structures. > > this is why i prefered to use 4-in muxes :-) Too big for most FPGAs. All you can do with 4-input cells is a 2:1 mux. > Can you track where the critical datapaths are located ? I guess it's in the control logic for stage 2. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 24 14:24:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWb1-0000MB-00 for ; Mon, 24 Sep 2001 16:20:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:31 +0200 (CEST) Received: (qmail 3818 invoked by uid 0); 24 Sep 2001 13:12:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 24 Sep 2001 13:12:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ODCvJ02087 for ; Mon, 24 Sep 2001 09:12:57 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 13:11:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ODBIM01481 for f-cpu-list; Mon, 24 Sep 2001 09:11:18 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ODBGC01478 for ; Mon, 24 Sep 2001 09:11:16 -0400 Received: by moria.seul.org (Postfix) id 12720146793; Mon, 24 Sep 2001 09:11:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id D4FBF14678D for ; Mon, 24 Sep 2001 09:11:27 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00678; Mon, 24 Sep 2001 14:24:40 +0200 Message-ID: <20010924142439.12067@thrai.stud.uni-hannover.de> Date: Mon, 24 Sep 2001 14:24:39 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <20010922213429.21799@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Mon, Sep 24, 2001 at 10:16:05AM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 24, 2001 at 10:16:05AM +0300, Kim Enkovaara wrote: [...] > We should take some chip as a reference and always synthesize for it. > Otherwise the results are not comparable. But to even get some feeling I > synthesized this block to Virte2 (XCV2V1000-BG575-6) and got following > results: > > Speed: 66MHz (optimized for speed, no special tricks) > Utilization: 30% > > > btw. the muxes are quite huge :) FPGA architectures usually have some > problems with complex multiplexer structures. That's obvious if you have nothing but 4-input cells... And the code clearly wasn't written with FPGAs in mind. Would a big AND-OR be faster? I remember that some FPGAs have dedicated, fast `cascade chains' which could do the trick. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Sep 24 14:16:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lWb1-0000MB-01 for ; Mon, 24 Sep 2001 16:20:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Sep 2001 16:20:31 +0200 (CEST) Received: (qmail 29137 invoked by uid 0); 24 Sep 2001 13:13:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 24 Sep 2001 13:13:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ODD8F02154 for ; Mon, 24 Sep 2001 09:13:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 13:11:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ODBYc01736 for f-cpu-list; Mon, 24 Sep 2001 09:11:34 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ODBVC01708 for ; Mon, 24 Sep 2001 09:11:31 -0400 Received: by moria.seul.org (Postfix) id 8076D146793; Mon, 24 Sep 2001 09:11:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id A672014678D for ; Mon, 24 Sep 2001 09:11:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00655; Mon, 24 Sep 2001 14:16:28 +0200 Message-ID: <20010924141628.33359@thrai.stud.uni-hannover.de> Date: Mon, 24 Sep 2001 14:16:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <20010923195132.11917@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Mon, Sep 24, 2001 at 08:27:59AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Sep 24, 2001 at 08:27:59AM +0200, Andreas Romeyke wrote: [...] > > I don't like this "you may have a look at it, but don't touch it" kind > > of licenses. Or worse, "you may look at it and touch it, but all your > > modifications are automatically mine", which is also covered by the term > > Open Source, IIRC. No, thank you. > > You are on wrong way. > There are two views to the world, an optimistic -> use BSD-like, a > pessimistic -> use GPL-like. They're both too optimistic for this world. The only realistic license is the one M$ uses :( The BSD license gives users too many rights, while most other "Open Source" licenses are too restrictive. IMHO, the GPL is the only license that is "well-balanced". [...] > But in fact you cannot forbid a abuse use, because you cannot controll > it. Will be there a bad guy, who reads and accepts your license? No. I may have to get him away with it, right -- but I can at least state that he's wrong. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Sep 24 20:34:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx7c-0002Tx-00 for ; Tue, 25 Sep 2001 20:39:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:39:56 +0200 (CEST) Received: (qmail 13777 invoked by uid 0); 24 Sep 2001 18:29:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 24 Sep 2001 18:29:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8OITOl06274 for ; Mon, 24 Sep 2001 14:29:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 18:28:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8OISqb06026 for f-cpu-list; Mon, 24 Sep 2001 14:28:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8OISpC06023 for ; Mon, 24 Sep 2001 14:28:51 -0400 Received: by moria.seul.org (Postfix) id 7412B146864; Mon, 24 Sep 2001 14:29:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf00bis.bellsouth.net (mail100.mail.bellsouth.net [205.152.58.40]) by moria.seul.org (Postfix) with ESMTP id 40835146862 for ; Mon, 24 Sep 2001 14:29:04 -0400 (EDT) Received: from computer ([209.215.24.113]) by imf00bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010924182945.RXRJ11456.imf00bis.bellsouth.net@computer>; Mon, 24 Sep 2001 14:29:45 -0400 Message-ID: <000801c14527$ac2dac40$7118d7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Barrel Shifter Date: Mon, 24 Sep 2001 13:34:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C144FD.AD4E77A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C144FD.AD4E77A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The conversation today seems related to the Barrel Shifter. Keep in = mind that my design is M2M with a 32 Bit Shifter. The Shifter uses = 4-input Multiplexers and requires three logic levels, plus a 32 bit, two = input mux on both the input and output. The two input mux's are for Bit = Reversal to use the array for both left and right shifts. A Normalize = function is burried in there for BOTH the Normalize and Arithmetic Shift = Left. With the above in mind-----the array has an execute time of 13.0 NS. = This is 77 MHZ if talking about stand alone time. It requires 181 Logic Cells = including Buffers for circuit loading of Max 8 loads. =20 For your info - an And/Or function is a Two input mux. And - - -=20 An 8 Bit Shifter =3D 1 logic level An 16 Bit Shifter =3D 2 logic levels An 32 Bit Shifter =3D 3 logic levels An 64 Bit Shifter =3D 4 logic levels An 128 Bit Shifter =3D 5 logic levels The above uses the Quicklogic data from the QL6600 printout. Regards Dick Hartney ------=_NextPart_000_0005_01C144FD.AD4E77A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The conversation today seems related to = the Barrel=20 Shifter.  Keep in mind that my design is M2M with a 32 Bit=20 Shifter.  The Shifter uses 4-input Multiplexers and requires three = logic=20 levels, plus a 32 bit, two input mux on both the input and output.  = The two=20 input mux's are for Bit Reversal to use the array for both left and = right=20 shifts.  A Normalize function is burried in there for BOTH the = Normalize=20 and Arithmetic Shift Left.
 
With the above in mind-----the array = has an execute=20 time of 13.0 NS.  This is
77 MHZ if talking about stand alone = time.  It=20 requires 181 Logic Cells including Buffers for circuit loading of Max 8=20 loads. 
 
For your info - an And/Or function is a = Two input=20 mux.  And - - -
 
        = An 8 Bit=20 Shifter =3D 1 logic level
        = An 16 Bit=20 Shifter =3D 2 logic levels
        = An 32 Bit=20 Shifter =3D 3 logic levels
        = An 64 Bit=20 Shifter =3D 4 logic levels
        = An 128 Bit=20 Shifter =3D 5 logic levels
 
The above uses the Quicklogic data from = the QL6600=20 printout.
 
Regards
Dick Hartney
------=_NextPart_000_0005_01C144FD.AD4E77A0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 25 01:30:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx7w-0002Tx-01 for ; Tue, 25 Sep 2001 20:40:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:16 +0200 (CEST) Received: (qmail 3795 invoked by uid 0); 24 Sep 2001 23:30:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 24 Sep 2001 23:30:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ONUdg10727 for ; Mon, 24 Sep 2001 19:30:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 23:29:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ONTxk10194 for f-cpu-list; Mon, 24 Sep 2001 19:29:59 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ONTwC10191 for ; Mon, 24 Sep 2001 19:29:58 -0400 Received: by moria.seul.org (Postfix) id 070F61462FB; Mon, 24 Sep 2001 19:30:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E18081462FA for ; Mon, 24 Sep 2001 19:30:11 -0400 (EDT) Received: from f-cpu.org (nas25-5.kdl.club-internet.fr [213.44.96.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 28969168D for ; Tue, 25 Sep 2001 01:29:54 +0200 (CEST) Message-ID: <3BAFC20C.CC9625E0@f-cpu.org> Date: Tue, 25 Sep 2001 01:30:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Barrel Shifter References: <000801c14527$ac2dac40$7118d7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! > "Richard E. Hartny" wrote: > The conversation today seems related to the Barrel Shifter. right :-) But since Michael has done the first work, i will let him go on and concentrate on the synthesis problems. I will soon study where "Alliance" is written so i bet that i'll have a clue about how it works at the end of the year :-) > Keep in mind that my design is M2M with a 32 Bit Shifter. The Shifter > uses 4-input Multiplexers and requires three logic levels, plus a 32 bit, > two input mux on both the input and output. it sounds like your design is a regular array that shifts 0,1,2,3 on the first stage, 0,4,8,12 on the second and 0 or 16 at the last stage (+ bit reversing). I think that each gate has a fanout of 4. However it creates a problem with 64 bits and especially at the last stage (or first depending on the sense) : imagine all the wires crossing... it creates capacitive and inductive problems. I am seeking a different approach, probably in a different kind of litterature. I don't rely on compilers to do the work for me. A book by J. Ullman "Computational Aspects of VLSI" shows that the layout of this circuit creats problems with the surface. Yes, wires use surface and it is linear with the length and (by inference) it increases with the number of bit positions you want to skip. Shifting is O(n^2). It may still be sustainable at 32 bits but the complex 64-bit shuffler can't do that (unless you're not looking at the surface space and the speed of course). I am looking at a scheme that does the work with more steps than usually, hence faster and with less wires. > The two input mux's are for Bit Reversal to use the array for both > left and right shifts. A Normalize function is burried in there for > BOTH the Normalize and Arithmetic Shift Left. > > With the above in mind-----the array has an execute time of 13.0 NS. This is > 77 MHZ if talking about stand alone time. It requires 181 Logic Cells > including Buffers for circuit loading of Max 8 loads. it sounds ok. > For your info - an And/Or function is a Two input mux. however there is a problem : LUT-based FPGA with 4 inputs can't do certain things (i have had this problem at META systems). The alternative that Michael proposes (as long as it is an "alternative" only, that can be switched by the user) is senseful in that case : with 4-input LUT, and provided the clocking is "clean" you perform two AND plus one OR with the first gates (1-bit MUX) and the rest is a balanced tree of ORs. If we used multiplexors, the balanced tree would be 2x deeper (and slower). But there is still a problem : decoding ! you have to generate 1 select per input, adding to the delay. If you multiplex 8 inputs, it's OK : each 1st level LUT decodes the 3 bits address and the 1 bit data, and you have a balanced tree of 3 gates. But with wider MUX, the overhead is becoming meaningful. > And - - - > > An 8 Bit Shifter = 1 logic level > An 16 Bit Shifter = 2 logic levels > An 32 Bit Shifter = 3 logic levels > An 64 Bit Shifter = 4 logic levels > An 128 Bit Shifter = 5 logic levels > > The above uses the Quicklogic data from the QL6600 printout. >from the above, i presume that you use pseudo-TTL138 devices, not 4-input muxes. > Regards > Dick Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 25 01:30:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx7x-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:17 +0200 (CEST) Received: (qmail 13559 invoked by uid 0); 24 Sep 2001 23:30:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 24 Sep 2001 23:30:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8ONUdi10730 for ; Mon, 24 Sep 2001 19:30:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 24 Sep 2001 23:30:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8ONU7210282 for f-cpu-list; Mon, 24 Sep 2001 19:30:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8ONU6C10265 for ; Mon, 24 Sep 2001 19:30:06 -0400 Received: by moria.seul.org (Postfix) id 8B52F1462FB; Mon, 24 Sep 2001 19:30:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 720141462FA for ; Mon, 24 Sep 2001 19:30:19 -0400 (EDT) Received: from f-cpu.org (nas25-5.kdl.club-internet.fr [213.44.96.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id B810216AC for ; Tue, 25 Sep 2001 01:30:03 +0200 (CEST) Message-ID: <3BAFC217.A4C716AC@f-cpu.org> Date: Tue, 25 Sep 2001 01:30:31 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Mon, Sep 24, 2001 at 12:59:39PM +0200, Yann Guidon wrote: > > hi ! > > Kim Enkovaara wrote: > > > On Sat, 22 Sep 2001, Michael Riepe wrote: > > > Speed: 66MHz (optimized for speed, no special tricks) > > wow :-) > > what is the fastest thing you have synthesised for this device ? > That's nothing -- the multiplier was faster :) > But I'm quite satisfied with that result. does that mean that you have something better in mind ? :-) > > > Utilization: 30% > > wow :-/ > > How big is it btw ? > The multiplier also took something like 30%. The SHL EU is very > space-consuming... yep. From the other mail i wrote, i might come from the wires (which btw make P&R more difficult in a 2D frame). > > > btw. the muxes are quite huge :) FPGA architectures usually have some > > > problems with complex multiplexer structures. > > this is why i prefered to use 4-in muxes :-) > Too big for most FPGAs. All you can do with 4-input cells is a 2:1 mux. read my other mail that answers to Richard. This puts the pressure on the decoder, OTOH. With some smart thinking it maybe be possible to find a suitable trade of between the cascade of OR and the decoder complexity. > > Can you track where the critical datapaths are located ? > I guess it's in the control logic for stage 2. ggggrrrrrr i'll have to look at the sources :-) read you soon, > Michael "Tired" Riepe WHYGEE who got himself a 20-bit Flying Calf for a nice price :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Sep 25 02:42:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx7z-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:19 +0200 (CEST) Received: (qmail 30929 invoked by uid 0); 25 Sep 2001 00:36:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 25 Sep 2001 00:36:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P0aV512144 for ; Mon, 24 Sep 2001 20:36:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 00:36:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P0a3u11898 for f-cpu-list; Mon, 24 Sep 2001 20:36:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P0a0C11889 for ; Mon, 24 Sep 2001 20:36:00 -0400 Received: by moria.seul.org (Postfix) id B53F8146310; Mon, 24 Sep 2001 20:36:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf00bis.bellsouth.net (mail100.mail.bellsouth.net [205.152.58.40]) by moria.seul.org (Postfix) with ESMTP id 72BA114630F for ; Mon, 24 Sep 2001 20:36:13 -0400 (EDT) Received: from computer ([208.60.244.86]) by imf00bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010925003657.LYF11456.imf00bis.bellsouth.net@computer>; Mon, 24 Sep 2001 20:36:57 -0400 Message-ID: <001601c1455a$f84c2ec0$56f43cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Barrel Shifter Date: Mon, 24 Sep 2001 19:42:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C14531.0CBE59C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C14531.0CBE59C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No --- I dont use the equivalent of an SN74138 - a one of eight decoder. = I use the equivalent of the AMD 25S10, also the same as the SN74S350, = 74F350. The devices consist of four, 4-input Multiplexers. Regards Dick Hartney ------=_NextPart_000_0013_01C14531.0CBE59C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No --- I dont use the equivalent of an = SN74138 - a=20 one of eight decoder.  I use the equivalent of the AMD 25S10, also = the same=20 as the SN74S350, 74F350.
 
The devices consist of four, 4-input=20 Multiplexers.
 
Regards
Dick Hartney
------=_NextPart_000_0013_01C14531.0CBE59C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 25 02:41:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx7z-0002Tx-01 for ; Tue, 25 Sep 2001 20:40:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:19 +0200 (CEST) Received: (qmail 25194 invoked by uid 0); 25 Sep 2001 00:41:23 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 25 Sep 2001 00:41:23 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P0fM612455 for ; Mon, 24 Sep 2001 20:41:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 00:40:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P0ewR12213 for f-cpu-list; Mon, 24 Sep 2001 20:40:58 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P0evC12210 for ; Mon, 24 Sep 2001 20:40:57 -0400 Received: by moria.seul.org (Postfix) id 43791146311; Mon, 24 Sep 2001 20:41:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1E854146310 for ; Mon, 24 Sep 2001 20:41:11 -0400 (EDT) Received: from f-cpu.org (nas25-5.kdl.club-internet.fr [213.44.96.5]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 85458168D for ; Tue, 25 Sep 2001 02:40:54 +0200 (CEST) Message-ID: <3BAFD2AC.25B2A89F@f-cpu.org> Date: Tue, 25 Sep 2001 02:41:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Barrel Shifter References: <001601c1455a$f84c2ec0$56f43cd0@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! > "Richard E. Hartny" wrote: > No --- I dont use the equivalent of an SN74138 - a one of eight decoder. > I use the equivalent of the AMD 25S10, also the same as the SN74S350, 74F350. > The devices consist of four, 4-input Multiplexers. oops i didn't know this one :-) thanks for the correction. > Regards > Dick Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Sep 25 02:47:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx80-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:20 +0200 (CEST) Received: (qmail 2271 invoked by uid 0); 25 Sep 2001 00:47:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 25 Sep 2001 00:47:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P0lis12793 for ; Mon, 24 Sep 2001 20:47:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 00:47:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P0lOi12545 for f-cpu-list; Mon, 24 Sep 2001 20:47:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P0lNC12542 for ; Mon, 24 Sep 2001 20:47:23 -0400 Received: by moria.seul.org (Postfix) id 51C85146312; Mon, 24 Sep 2001 20:47:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a212.home.uni-hannover.de [130.75.232.212]) by moria.seul.org (Postfix) with ESMTP id DAF43146311 for ; Mon, 24 Sep 2001 20:47:34 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA04134; Tue, 25 Sep 2001 02:47:18 +0200 Message-ID: <20010925024718.06150@thrai.stud.uni-hannover.de> Date: Tue, 25 Sep 2001 02:47:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAFC217.A4C716AC@f-cpu.org>; from Yann Guidon on Tue, Sep 25, 2001 at 01:30:31AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 25, 2001 at 01:30:31AM +0200, Yann Guidon wrote: [...] > > > > Speed: 66MHz (optimized for speed, no special tricks) > > > wow :-) > > > what is the fastest thing you have synthesised for this device ? > > That's nothing -- the multiplier was faster :) > > But I'm quite satisfied with that result. > does that mean that you have something better in mind ? :-) It means: 66 MHz is pretty good (for an FPGA). Although, know you mentioned it... I *may* be able to do even better ;) > > > > Utilization: 30% > > > wow :-/ > > > How big is it btw ? > > The multiplier also took something like 30%. The SHL EU is very > > space-consuming... > yep. From the other mail i wrote, i might come from the wires > (which btw make P&R more difficult in a 2D frame). Or the number of cells required for the muxes. There are four of them for every bit, approximately -- and since left-shifts and right-shifts are handled separately, that number is doubled once more. That is, there are 512 multiplexers with 8...12 inputs. But that's nothing compared to the Xbar ;) > > > > btw. the muxes are quite huge :) FPGA architectures usually have some > > > > problems with complex multiplexer structures. > > > this is why i prefered to use 4-in muxes :-) > > Too big for most FPGAs. All you can do with 4-input cells is a 2:1 mux. > read my other mail that answers to Richard. This puts the pressure > on the decoder, OTOH. With some smart thinking it maybe be possible > to find a suitable trade of between the cascade of OR and the decoder > complexity. I guess my 2nd stage decoder is already pretty simple. Took me quite a while to find a solution that does not suffer from extreme elephantiasis ;) > > > Can you track where the critical datapaths are located ? > > I guess it's in the control logic for stage 2. > ggggrrrrrr i'll have to look at the sources :-) Good idea ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 25 03:00:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx81-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:21 +0200 (CEST) Received: (qmail 16996 invoked by uid 0); 25 Sep 2001 01:01:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 25 Sep 2001 01:01:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P110O13280 for ; Mon, 24 Sep 2001 21:01:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 01:00:26 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P10Pr13022 for f-cpu-list; Mon, 24 Sep 2001 21:00:25 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P10NC13019 for ; Mon, 24 Sep 2001 21:00:23 -0400 Received: by moria.seul.org (Postfix) id 3992D14666C; Mon, 24 Sep 2001 21:00:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 2020D14640F for ; Mon, 24 Sep 2001 21:00:37 -0400 (EDT) Received: from f-cpu.org (nas25-5.kdl.club-internet.fr [213.44.96.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id AEA011691 for ; Tue, 25 Sep 2001 03:00:20 +0200 (CEST) Message-ID: <3BAFD741.52CD7D40@f-cpu.org> Date: Tue, 25 Sep 2001 03:00:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Sep 25, 2001 at 01:30:31AM +0200, Yann Guidon wrote: > [...] > > > > > Speed: 66MHz (optimized for speed, no special tricks) > > > > wow :-) > > > > what is the fastest thing you have synthesised for this device ? > > > That's nothing -- the multiplier was faster :) > > > But I'm quite satisfied with that result. > > does that mean that you have something better in mind ? :-) > It means: 66 MHz is pretty good (for an FPGA). Although, know you > mentioned it... I *may* be able to do even better ;) i *knew* it ;-) i knew that you had something in mind and i know that it is possible to do better (hence my personal research) > > > > > Utilization: 30% > > > > wow :-/ > > > > How big is it btw ? > > > The multiplier also took something like 30%. The SHL EU is very > > > space-consuming... > > yep. From the other mail i wrote, i might come from the wires > > (which btw make P&R more difficult in a 2D frame). > Or the number of cells required for the muxes. There are four of them > for every bit, approximately -- and since left-shifts and right-shifts > are handled separately, that number is doubled once more. That is, > there are 512 multiplexers with 8...12 inputs. But that's nothing > compared to the Xbar ;) i don't think that the Xbar will be extremely annoying. Comparatively, it's not tough : there are already 8 inputs when only a few units are present. If there are more units, it goes up but not madly. This is 2*64-bits of course but i think it fits "right" into the pipeline stage depth. > > > > > btw. the muxes are quite huge :) FPGA architectures usually have some > > > > > problems with complex multiplexer structures. > > > > this is why i prefered to use 4-in muxes :-) > > > Too big for most FPGAs. All you can do with 4-input cells is a 2:1 mux. > > read my other mail that answers to Richard. This puts the pressure > > on the decoder, OTOH. With some smart thinking it maybe be possible > > to find a suitable trade of between the cascade of OR and the decoder > > complexity. > I guess my 2nd stage decoder is already pretty simple. Took me quite a > while to find a solution that does not suffer from extreme elephantiasis ;) > > > > Can you track where the critical datapaths are located ? > > > I guess it's in the control logic for stage 2. > > ggggrrrrrr i'll have to look at the sources :-) > Good idea ;) let's add an optical output to my flying calf first :-P > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Tue Sep 25 08:03:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx89-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:29 +0200 (CEST) Received: (qmail 11379 invoked by uid 0); 25 Sep 2001 06:04:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx12) with SMTP; 25 Sep 2001 06:04:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P649d18298 for ; Tue, 25 Sep 2001 02:04:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 06:03:50 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P63oY18056 for f-cpu-list; Tue, 25 Sep 2001 02:03:50 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P63nC18053 for ; Tue, 25 Sep 2001 02:03:49 -0400 Received: by moria.seul.org (Postfix) id A29DC1462F9; Tue, 25 Sep 2001 02:04:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 0EA661462F8 for ; Tue, 25 Sep 2001 02:04:03 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA23915 for ; Tue, 25 Sep 2001 09:03:48 +0300 (EET DST) Date: Tue, 25 Sep 2001 09:03:47 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) In-Reply-To: <20010924144135.57848@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 24 Sep 2001, Michael Riepe wrote: > > > Utilization: 30% > > wow :-/ > > How big is it btw ? > > The multiplier also took something like 30%. The SHL EU is very > space-consuming... I think I compiled the multiplier to a bigger chip (XC2V6000). It is quite much bigger chip. It was so big that the routing delays etc. become big factor if I try to compile too small things to it without constraining. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Sep 25 09:56:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx8A-0002Tx-01 for ; Tue, 25 Sep 2001 20:40:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:30 +0200 (CEST) Received: (qmail 2286 invoked by uid 0); 25 Sep 2001 07:56:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 25 Sep 2001 07:56:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P7ui420264 for ; Tue, 25 Sep 2001 03:56:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 07:56:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P7uOO20012 for f-cpu-list; Tue, 25 Sep 2001 03:56:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P7uNC20007 for ; Tue, 25 Sep 2001 03:56:23 -0400 Received: by moria.seul.org (Postfix) id E2994146309; Tue, 25 Sep 2001 03:56:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C6A8B146308 for ; Tue, 25 Sep 2001 03:56:36 -0400 (EDT) Received: from f-cpu.org (nas5-230.kdl.club-internet.fr [213.44.0.230]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 658F316AE for ; Tue, 25 Sep 2001 09:56:20 +0200 (CEST) Message-ID: <3BB038C1.E1601B00@f-cpu.org> Date: Tue, 25 Sep 2001 09:56:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, and btw, thank you for the log in the other message but i don't catch the meaning :-) if a graphical output was available... Kim Enkovaara wrote: > On Mon, 24 Sep 2001, Michael Riepe wrote: > > > > Utilization: 30% > > > wow :-/ > > > How big is it btw ? > > The multiplier also took something like 30%. The SHL EU is very > > space-consuming... > > I think I compiled the multiplier to a bigger chip (XC2V6000). It is quite > much bigger chip. It was so big that the routing delays etc. become big > factor if I try to compile too small things to it without constraining. I have no "education" with P&R tool design, but from what i have seen, what you describe is normal. Unlike humans which tend to optimize and make "round" things, synthesisers for this kind of "devices" will use up whatever ressource is available, and then start to "think" when it gets limited. Constraining the design, if you want to use the rest of the chip, is important. It will be interesting to compare individual units with the result when they are together. We might see density increases, for example. did you try the "new" ROP2 ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Sep 25 14:14:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx8D-0002Tx-01 for ; Tue, 25 Sep 2001 20:40:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:33 +0200 (CEST) Received: (qmail 9968 invoked by uid 0); 25 Sep 2001 12:09:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 25 Sep 2001 12:09:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8PC9Av24340 for ; Tue, 25 Sep 2001 08:09:10 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 12:08:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8PC8K724097 for f-cpu-list; Tue, 25 Sep 2001 08:08:20 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8PC8HC24094 for ; Tue, 25 Sep 2001 08:08:17 -0400 Received: by moria.seul.org (Postfix) id 8E8821462F8; Tue, 25 Sep 2001 08:08:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by moria.seul.org (Postfix) with ESMTP id 6632B1462F7 for ; Tue, 25 Sep 2001 08:08:31 -0400 (EDT) Received: from computer ([209.215.24.115]) by imf03bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010925120918.FQKB4526.imf03bis.bellsouth.net@computer>; Tue, 25 Sep 2001 08:09:18 -0400 Message-ID: <000801c145bb$b166f4c0$7318d7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Multiply, FYI Date: Tue, 25 Sep 2001 07:14:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C14591.C7A5F080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C14591.C7A5F080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As some of you might remember - I have implemented a Timed-Sequence = Multiply with Nibble Skip (4 Bits). Where one 4 x 4 Multiply, Add and Accumulate = requires 22 NS. Worst case is 8 x 22 =3D 176 NS. Best case =3D 22 NS. = I get around the variable timing by Enabling the Multiply Interrupt and = execute a HALT instruction. I also use an Interrupt to recognize a Divide termination. The divide = is variable because I skip One's and Zero strings. Regards Dick Hartney ------=_NextPart_000_0005_01C14591.C7A5F080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As some of you might remember - I have = implemented=20 a Timed-Sequence Multiply
with Nibble Skip (4 Bits).  Where = one 4 x 4=20 Multiply, Add and Accumulate requires 22 NS.  Worst case is 8 = x 22 =3D=20 176 NS.  Best case =3D 22 NS.  I get around the variable = timing by=20 Enabling the Multiply Interrupt and execute a HALT = instruction.
 
I also use an Interrupt to = recognize a Divide=20 termination.  The divide is variable because I skip One's and Zero=20 strings.
 
Regards
Dick Hartney
------=_NextPart_000_0005_01C14591.C7A5F080-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Tue Sep 25 08:01:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15lx87-0002Tx-00 for ; Tue, 25 Sep 2001 20:40:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Sep 2001 20:40:27 +0200 (CEST) Received: (qmail 14754 invoked by uid 0); 25 Sep 2001 06:02:10 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 25 Sep 2001 06:02:10 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8P629817967 for ; Tue, 25 Sep 2001 02:02:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 06:01:41 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8P61bL17697 for f-cpu-list; Tue, 25 Sep 2001 02:01:37 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8P61aC17691 for ; Tue, 25 Sep 2001 02:01:36 -0400 Received: by moria.seul.org (Postfix) id 0CA001462F9; Tue, 25 Sep 2001 02:01:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 2F5521462F8 for ; Tue, 25 Sep 2001 02:01:49 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA24084 for ; Tue, 25 Sep 2001 09:01:33 +0300 (EET DST) Date: Tue, 25 Sep 2001 09:01:31 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) In-Reply-To: <3BAF121B.1219D33F@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 24 Sep 2001, Yann Guidon wrote: > > We should take some chip as a reference and always synthesize for it. > > Otherwise the results are not comparable. But to even get some feeling I > > synthesized this block to Virte2 (XCV2V1000-BG575-6) and got following > > results: > > > > Speed: 66MHz (optimized for speed, no special tricks) > wow :-) > what is the fastest thing you have synthesised for this device ? That is quite difficult question to answer, but to give some ideas how fast it is (all one stage): 64-bit adder + reset: 143MHz (optimized by the synthesizer) 64-bit multiplier + reset: 62MHz (uses internal 16x16 multiplier macros) > > Utilization: 30% > wow :-/ > How big is it btw ? It's quite big, but it is easeir to check the architecture from the Xilinx manuals that are freely downloadable in the net. It would take too much space to explain the architecture. > this is why i prefered to use 4-in muxes :-) > > Can you track where the critical datapaths are located ? > Can you try on the (new) ROP2 unit ? I'll copy some bits of the long report. First the high loads and what was replicated during the synthesis. Net buffering Report for view:work.Shuffle64(behave_1): B_c[0] - loads: 185, segments 2, buffering source B_c[1] - loads: 240, segments 3, buffering source B_c[2] - loads: 230, segments 3, buffering source pin:O inst:hi_and3_0[6] of VIRTEX.LUT3(PRIM) - loads: 78, segments 2, replicating source pin:O inst:simd_shuffle.1.hi_sel_un1_hi of VIRTEX.LUT2(PRIM) - loads: 52, segments 2, replicating source pin:O inst:simd_shuffle.2.hi_sel_un1_hi_3 of VIRTEX.LUT2(PRIM) - loads: 113, segments 3, replicating source Added 8 Buffers Added 0 Registers via replication Added 4 LUTs via replication Here are few critical paths: A Critical Path with worst case slack = -10.0 ns: The start and the end point of this path are clocked by the System Instance/Net Pin Pin Arrival Delta Fan Name Type Name Dir Time Delay Out ----------------------------------------------------------------------------------------------------- Shuffle64 View B[63:0] Port B[0] Out 0.0 0.0 B[0] Net 1 B_ibuf[0] IBUF I In 0.0 B_ibuf[0] IBUF O Out 0.9 0.9 B_c[0] Net 2 B_c_0[0] BUF I In 0.9 B_c_0[0] BUF O Out 3.1 2.2 B_c_0[0] Net 111 tt_1_0[8] LUT3 I2 In 3.1 tt_1_0[8] LUT3 O Out 4.1 1.0 N_1396 Net 3 tt_6[4] MUXF5 S In 4.1 tt_6[4] MUXF5 O Out 5.4 1.4 N_791 Net 3 tt_7[8] LUT3 I0 In 5.4 tt_7[8] LUT3 O Out 6.7 1.3 tt[8] Net 8 simd_shuffle.1.hi_sel_yy_1_iv_0.G_2884_s LUT4 I2 In 6.7 simd_shuffle.1.hi_sel_yy_1_iv_0.G_2884_s LUT4 O Out 7.5 0.8 N_6301 Net 1 simd_shuffle.1.hi_sel_yy_1_iv_0.G_2884 LUT3 I0 In 7.5 simd_shuffle.1.hi_sel_yy_1_iv_0.G_2884 LUT3 O Out 8.3 0.8 N_4580 Net 1 simd_shuffle.1.hi_sel_yy_1_iv[0] MUXF5 S In 8.3 simd_shuffle.1.hi_sel_yy_1_iv[0] MUXF5 O Out 9.6 1.3 simd_shuffle.1.hi_sel_yy_1[0] Net 2 Y_iv_8.G_3830 LUT4 I2 In 9.6 Y_iv_8.G_3830 LUT4 O Out 10.3 0.8 N_5526 Net 1 Y_iv_8.G_3832 LUT4 I0 In 10.3 Y_iv_8.G_3832 LUT4 O Out 11.1 0.8 N_5528 Net 1 Y_iv[8] LUT4 I0 In 11.1 Y_iv[8] LUT4 O Out 11.6 0.4 Y_c[8] Net 1 Y_obuf[8] OBUF_F_24 I In 11.6 Y_obuf[8] OBUF_F_24 O Out 15.0 3.5 Y[8] Net 1 Y[63:0] Port Y[8] In 15.0 ===================================================================================================== This path has no setup requirement A Critical Path with worst case slack = -9.7 ns: The start and the end point of this path are clocked by the System Instance/Net Pin Pin Arrival Delta Fan Name Type Name Dir Time Delay Out ------------------------------------------------------------------------------------------- Shuffle64 View B[63:0] Port B[1] Out 0.0 0.0 B[1] Net 1 B_ibuf[1] IBUF I In 0.0 B_ibuf[1] IBUF O Out 0.9 0.9 B_c[1] Net 3 B_c_1[1] BUF I In 0.9 B_c_1[1] BUF O Out 3.1 2.2 B_c_1[1] Net 104 tt_51_3_sx_0[12] LUT4 I0 In 3.1 tt_51_3_sx_0[12] LUT4 O Out 4.0 0.9 tt_51_3_sx_0[12] Net 2 y_shiftrotr_1_12.G_2918_sx_x0 LUT4 I2 In 4.0 y_shiftrotr_1_12.G_2918_sx_x0 LUT4 O Out 4.8 0.8 N_8013 Net 1 y_shiftrotr_1_12.G_2918_sx MUXF5 I0 In 4.8 y_shiftrotr_1_12.G_2918_sx MUXF5 O Out 5.3 0.5 y_shiftrotr_1_12.G_2918_sx Net 1 y_shiftrotr_1_12.G_2918 MUXF5 S In 5.3 y_shiftrotr_1_12.G_2918 MUXF5 O Out 6.6 1.3 N_4614 Net 2 y_shiftrotr_1_12.G_2922_am LUT3 I2 In 6.6 y_shiftrotr_1_12.G_2922_am LUT3 O Out 7.4 0.8 N_6169 Net 1 y_shiftrotr_1_12.G_2922 MUXF5 I0 In 7.4 y_shiftrotr_1_12.G_2922 MUXF5 O Out 7.9 0.5 N_4618 Net 1 y_shiftrotr_1_12.G_2927 LUT4 I3 In 7.9 y_shiftrotr_1_12.G_2927 LUT4 O Out 8.7 0.8 N_4623 Net 1 y_shiftrotr_1_m[12] LUT4 I2 In 8.7 y_shiftrotr_1_m[12] LUT4 O Out 9.5 0.8 y_shiftrotr_1_m[12] Net 1 Y_iv_12.G_3859 LUT4 I0 In 9.5 Y_iv_12.G_3859 LUT4 O Out 10.5 1.0 N_5555 Net 1 Y_iv[12] MUXF5 S In 10.5 Y_iv[12] MUXF5 O Out 11.5 1.0 Y_c[12] Net 1 Y_obuf[12] OBUF_F_24 I In 11.5 Y_obuf[12] OBUF_F_24 O Out 15.0 3.5 Y[12] Net 1 Y[63:0] Port Y[12] In 15.0 =========================================================================================== This path has no setup requirement A Critical Path with worst case slack = -9.3 ns: The start and the end point of this path are clocked by the System Instance/Net Pin Pin Arrival Delta Fan Name Type Name Dir Time Delay Out ---------------------------------------------------------------------------- Shuffle64 View B[63:0] Port B[2] Out 0.0 0.0 B[2] Net 1 B_ibuf[2] IBUF I In 0.0 B_ibuf[2] IBUF O Out 0.9 0.9 B_c[2] Net 3 B_c_2[2] BUF I In 0.9 B_c_2[2] BUF O Out 3.1 2.2 B_c_2[2] Net 91 tt_7_sx[2] LUT2 I1 In 3.1 tt_7_sx[2] LUT2 O Out 3.9 0.8 tt_7_sx[2] Net 1 tt_7[2] LUT4 I3 In 3.9 tt_7[2] LUT4 O Out 5.2 1.3 tt[2] Net 8 yy_9_58.G_3720 LUT4 I3 In 5.2 yy_9_58.G_3720 LUT4 O Out 6.0 0.8 N_5416 Net 1 yy_9_58.G_3722 LUT3 I0 In 6.0 yy_9_58.G_3722 LUT3 O Out 7.0 1.0 N_5418 Net 1 yy_9_58.G_3724 LUT4 I2 In 7.0 yy_9_58.G_3724 LUT4 O Out 7.8 0.8 N_5420 Net 1 yy_9_58.G_3732 LUT4 I0 In 7.8 yy_9_58.G_3732 LUT4 O Out 8.7 0.9 N_5428 Net 2 yy_9[58] LUT4 I0 In 8.7 yy_9[58] LUT4 O Out 9.8 1.1 yy_9[58] Net 4 Y_0_iv_sx[26] LUT4 I1 In 9.8 Y_0_iv_sx[26] LUT4 O Out 10.6 0.8 Y_0_iv_sx[26] Net 1 Y_0_iv[26] LUT4 I3 In 10.6 Y_0_iv[26] LUT4 O Out 11.0 0.4 Y_c[26] Net 1 Y_obuf[26] OBUF_F_24 I In 11.0 Y_obuf[26] OBUF_F_24 O Out 14.5 3.5 Y[26] Net ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 26 02:54:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15m4NI-00087b-00 for ; Wed, 26 Sep 2001 04:24:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Sep 2001 04:24:36 +0200 (CEST) Received: (qmail 20379 invoked by uid 0); 25 Sep 2001 18:42:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 25 Sep 2001 18:42:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8PIgNx30645 for ; Tue, 25 Sep 2001 14:42:23 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 18:41:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8PIfpJ30378 for f-cpu-list; Tue, 25 Sep 2001 14:41:51 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8PIfoC30375 for ; Tue, 25 Sep 2001 14:41:50 -0400 Received: by moria.seul.org (Postfix) id 2AB481462FC; Tue, 25 Sep 2001 14:42:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-160.vlt.club-internet.fr [194.158.107.160]) by moria.seul.org (Postfix) with ESMTP id 558071462FB for ; Tue, 25 Sep 2001 14:42:03 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 7514F1433 for ; Tue, 25 Sep 2001 20:54:22 -0400 (EDT) Message-ID: <3BB1273E.2F2F169C@ifrance.com> Date: Tue, 25 Sep 2001 20:54:22 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> <3BAE041C.11FEAF86@ifrance.com> <20010923195132.11917@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : [...] > > http://www.opensource.org/docs/definition.html > > > > http://www.gnu.org/philosophy/free-software-for-freedom.html > > Does the F-CPU license really have to be compatible with the GPL? > > I really don't care about Open Source. It only guarantees that you can > get the source code, not that you can modify and/or redistribute it freely > (that's the reason why Micro$oft hates the GPL, and *only* the GPL). False ! RTFM see point 3 ! of the first url. > I don't like this "you may have a look at it, but don't touch it" kind > of licenses. Or worse, "you may look at it and touch it, but all your > modifications are automatically mine", which is also covered by the term > Open Source, IIRC. No, thank you. > > I know that I may not be able to stop them, but I'd like to make clear > that I neither agree with nor support people or organizations who harass, > threaten, hurt, torture or kill other people. Freedom to use something Who do it ? > does not include freedom to abuse it -- and we're responsible for drawing > the line between them. In fact, all scientists, engineers and inventors > are, but most of them tend to forget that fact, or ignore it. Like RMS > and/or the FSF did. I have not thought enought to such philosophical point. But i imagine that it make a lot of drawback, that could be dangerous for the future. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Sep 26 03:37:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15m4NL-00087b-00 for ; Wed, 26 Sep 2001 04:24:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Sep 2001 04:24:39 +0200 (CEST) Received: (qmail 7679 invoked by uid 0); 25 Sep 2001 19:35:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Sep 2001 19:35:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8PJZRW00947 for ; Tue, 25 Sep 2001 15:35:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 19:35:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8PJZ0D00555 for f-cpu-list; Tue, 25 Sep 2001 15:35:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8PJYwC00544 for ; Tue, 25 Sep 2001 15:34:58 -0400 Received: by moria.seul.org (Postfix) id 49DEC146305; Tue, 25 Sep 2001 15:35:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-75.vlt.club-internet.fr [194.158.109.75]) by moria.seul.org (Postfix) with ESMTP id 6790B146306 for ; Tue, 25 Sep 2001 15:35:11 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E1F561433 for ; Tue, 25 Sep 2001 21:37:00 -0400 (EDT) Message-ID: <3BB1313C.5CB9E3DC@ifrance.com> Date: Tue, 25 Sep 2001 21:37:00 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Far from the last word about license ;-) (long and rambling) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010923222919.B59A11467EE@moria.seul.org> <20010924011804.64378@thrai.stud.uni-hannover.de> <20010924022542.4A8E814667E@moria.seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Glenn Alexander a écrit : > > On Mon, 24 Sep 2001 07:18, you wrote: > > > > Wait a minute... I didn't mean to forbid the use of the F-CPU in an > > entire country or state. Neither in the US, nor in Russia, China or > > Afghanistan. But I want people to recognize that they're responsible > > for what they do with it. > > > Fair enough, but again, the people who make guided missiles don't care anyway > and those that do care choose not to make guided missiles. I feel it would be > preaching to the converted and add complexity to the licence that would serve > little purpose as it would be ignored by those it applied to. > > I would be happy to see a preamble to the licence talking about moral use of > the IP. You then achieve the awareness aspect without obstuficating (sp?) the > licence. The simpler the licence (within reason) the more solid it is, I feel. > I think so, too. A lot of commercial product are used in military product. If fcpu is not allowed in military product, they will choose an other CPU for there commercial product because they want to share cost of development. nicO > -------------------------------------------------------- > Glenn Alexander - The man with no surname and a silly hat. > (B.Teach, B.Ed Major IT Education, University of Wollongong Australia) > (Now avaliable in China!) > > http://members.ozemail.com.au/~glenalec (last update: 2001.07.29) > > I use GNU/Linux: http://www.gnu.org / http://www.linux.org > from Debian: http://www.debian.org > and KDE : http://www.kde.org > -------------------------------------------------------- > What would you expect from an MCSE? > -------------------------------------------------------- > The above message was bought to you by 'sigrot' > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 26 01:57:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15m4NN-00087b-00 for ; Wed, 26 Sep 2001 04:24:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Sep 2001 04:24:41 +0200 (CEST) Received: (qmail 29752 invoked by uid 0); 25 Sep 2001 23:57:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 25 Sep 2001 23:57:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8PNvVx07123 for ; Tue, 25 Sep 2001 19:57:31 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 25 Sep 2001 23:57:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8PNv8T06867 for f-cpu-list; Tue, 25 Sep 2001 19:57:08 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8PNv6C06864 for ; Tue, 25 Sep 2001 19:57:07 -0400 Received: by moria.seul.org (Postfix) id 45DAC14667F; Tue, 25 Sep 2001 19:57:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a072.home.uni-hannover.de [130.75.232.72]) by moria.seul.org (Postfix) with ESMTP id 7E45714667E for ; Tue, 25 Sep 2001 19:57:19 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA21239; Wed, 26 Sep 2001 01:57:08 +0200 Message-ID: <20010926015708.41895@thrai.stud.uni-hannover.de> Date: Wed, 26 Sep 2001 01:57:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] last word about license ;-) was Re: encore une couche (was: Re: [f-cpu] License issues GPL/LGPL andJuergen Goeritz' SoC) References: <3BAA4DE8.AAA3788C@f-cpu.org> <20010922161205.10939@thrai.stud.uni-hannover.de> <3BAE041C.11FEAF86@ifrance.com> <20010923195132.11917@thrai.stud.uni-hannover.de> <3BB1273E.2F2F169C@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB1273E.2F2F169C@ifrance.com>; from nicO on Tue, Sep 25, 2001 at 08:54:22PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 25, 2001 at 08:54:22PM -0400, nicO wrote: [...] > > I really don't care about Open Source. It only guarantees that you can > > get the source code, not that you can modify and/or redistribute it freely > > (that's the reason why Micro$oft hates the GPL, and *only* the GPL). > > False ! RTFM see point 3 ! of the first url. Oops, you're right. I must have mixed that up with something different (Debian Free Software Guidelines? I don't remember). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 26 02:47:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mKhZ-0000eg-01 for ; Wed, 26 Sep 2001 21:50:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Sep 2001 21:50:37 +0200 (CEST) Received: (qmail 23918 invoked by uid 0); 26 Sep 2001 11:48:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 26 Sep 2001 11:48:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8QBmQJ23375 for ; Wed, 26 Sep 2001 07:48:26 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 26 Sep 2001 11:47:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8QBldZ22942 for f-cpu-list; Wed, 26 Sep 2001 07:47:39 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8QBlbC22929 for ; Wed, 26 Sep 2001 07:47:37 -0400 Received: by moria.seul.org (Postfix) id A58451466CD; Wed, 26 Sep 2001 07:47:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a250.home.uni-hannover.de [130.75.232.250]) by moria.seul.org (Postfix) with ESMTP id 35C481466CC for ; Wed, 26 Sep 2001 07:47:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA21416; Wed, 26 Sep 2001 02:47:51 +0200 Message-ID: <20010926024750.48088@thrai.stud.uni-hannover.de> Date: Wed, 26 Sep 2001 02:47:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BAFD741.52CD7D40@f-cpu.org>; from Yann Guidon on Tue, Sep 25, 2001 at 03:00:49AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Sep 25, 2001 at 03:00:49AM +0200, Yann Guidon wrote: [...] > > It means: 66 MHz is pretty good (for an FPGA). Although, know you > > mentioned it... I *may* be able to do even better ;) > i *knew* it ;-) i knew that you had something in mind and i know that > it is possible to do better (hence my personal research) I'll have to investigate the 4x4 approach more closely. For an FPGA, 2x2 cells may make sense, too (especially when you have cells with 3-4 inputs and 2 outputs that can route the bits either parallel or crossed). Other things that may result in a speed-up: - separate sign extension from the right shifter - improve/rewrite stage 2 decoder - separate shift and rotate operations (beware! code duplication) [...] > > > ggggrrrrrr i'll have to look at the sources :-) > > Good idea ;) > let's add an optical output to my flying calf first :-P wtf is a "flying calf", and why does it need an optical output? .o( pigs don't fly, so why should calves? ) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Sep 26 17:23:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mKhb-0000eg-00 for ; Wed, 26 Sep 2001 21:50:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Sep 2001 21:50:39 +0200 (CEST) Received: (qmail 27315 invoked by uid 0); 26 Sep 2001 15:27:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx15) with SMTP; 26 Sep 2001 15:27:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8QFRWs29922 for ; Wed, 26 Sep 2001 11:27:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 26 Sep 2001 15:23:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8QFNAX29522 for f-cpu-list; Wed, 26 Sep 2001 11:23:10 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8QFN9C29519 for ; Wed, 26 Sep 2001 11:23:09 -0400 Received: by moria.seul.org (Postfix) id E8B8D1466E3; Wed, 26 Sep 2001 11:23:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CD9551466E1 for ; Wed, 26 Sep 2001 11:23:23 -0400 (EDT) Received: from f-cpu.org (nas20-223.kdl.club-internet.fr [213.44.18.223]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8A44316E5 for ; Wed, 26 Sep 2001 17:22:49 +0200 (CEST) Message-ID: <3BB1F2E7.61914AC7@f-cpu.org> Date: Wed, 26 Sep 2001 17:23:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! ... i just woke up ... Michael Riepe wrote: > On Tue, Sep 25, 2001 at 03:00:49AM +0200, Yann Guidon wrote: > [...] > > > It means: 66 MHz is pretty good (for an FPGA). Although, know you > > > mentioned it... I *may* be able to do even better ;) > > i *knew* it ;-) i knew that you had something in mind and i know that > > it is possible to do better (hence my personal research) > I'll have to investigate the 4x4 approach more closely. For an FPGA, > 2x2 cells may make sense, too (especially when you have cells with 3-4 > inputs and 2 outputs that can route the bits either parallel or crossed). > > Other things that may result in a speed-up: > - separate sign extension from the right shifter > - improve/rewrite stage 2 decoder > - separate shift and rotate operations (beware! code duplication) code duplication does not necessarily end up with faster silicon... > [...] > > > > ggggrrrrrr i'll have to look at the sources :-) > > > Good idea ;) > > let's add an optical output to my flying calf first :-P > wtf is a "flying calf", and why does it need an optical output? > .o( pigs don't fly, so why should calves? ) :-P "flying calf" is a 20-bit stereo A/D SPDIF (coax) converter from Midiman (i got two of them in a bargain). however, minidisc recorders have an optical input. so i have to hack an optical output to the Midiman converter. With this stuff, i finally can record with 60db SNR :-))) portable minidiscs suck when you push the sensitivity of the microphone input. My MZR-30 has decoupling problems, the internal A/D is not protected from the electric motor power noise. Now, all the conversion will be done externally, which removes the other limitation : once you started to record a track, you can't change the sensitivity. And the flying calf has a 6 LED level indicator per channel, it's more practical in the dark ;-) did i say i'm an audio freak ? > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Sep 27 01:50:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mSzs-00068d-00 for ; Thu, 27 Sep 2001 06:42:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Sep 2001 06:42:04 +0200 (CEST) Received: (qmail 21788 invoked by uid 0); 26 Sep 2001 23:56:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Sep 2001 23:56:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8QNuxt13157 for ; Wed, 26 Sep 2001 19:56:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 26 Sep 2001 23:56:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8QNuVH12910 for f-cpu-list; Wed, 26 Sep 2001 19:56:31 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8QNuTC12907 for ; Wed, 26 Sep 2001 19:56:30 -0400 Received: by moria.seul.org (Postfix) id EEB9514670E; Wed, 26 Sep 2001 19:56:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id 4A85B14670D for ; Wed, 26 Sep 2001 19:56:44 -0400 (EDT) Received: from jetnet.ab.ca (dialin47.jetnet.ab.ca [207.153.6.47]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA28962 for ; Wed, 26 Sep 2001 17:56:26 -0600 (MDT) Message-ID: <3BB269D5.B6B36C64@jetnet.ab.ca> Date: Wed, 26 Sep 2001 17:50:45 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Y> "flying calf" is a 20-bit stereo A/D SPDIF (coax) converter >from Midiman > (i got two of them in a bargain). > however, minidisc recorders have an optical input. so i have to hack > an optical output to the Midiman converter. With this stuff, i finally > can record with 60db SNR :-))) portable minidiscs suck when you push the > sensitivity of the microphone input. My MZR-30 has decoupling problems, > the internal A/D is not protected from the electric motor power noise. > Now, all the conversion will be done externally, which removes the > other limitation : once you started to record a track, you can't change > the sensitivity. And the flying calf has a 6 LED level indicator per channel, > it's more practical in the dark ;-) > did i say i'm an audio freak ? So do you have a TUBE amp too! Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 27 01:59:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mSzs-00068d-01 for ; Thu, 27 Sep 2001 06:42:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Sep 2001 06:42:04 +0200 (CEST) Received: (qmail 16806 invoked by uid 0); 26 Sep 2001 23:59:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 26 Sep 2001 23:59:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8QNxjT13459 for ; Wed, 26 Sep 2001 19:59:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 26 Sep 2001 23:59:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8QNxRG13210 for f-cpu-list; Wed, 26 Sep 2001 19:59:27 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8QNxQC13206 for ; Wed, 26 Sep 2001 19:59:26 -0400 Received: by moria.seul.org (Postfix) id 03ED114670F; Wed, 26 Sep 2001 19:59:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a244.home.uni-hannover.de [130.75.232.244]) by moria.seul.org (Postfix) with ESMTP id 016FA14670E for ; Wed, 26 Sep 2001 19:59:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00758; Thu, 27 Sep 2001 01:59:22 +0200 Message-ID: <20010927015922.43391@thrai.stud.uni-hannover.de> Date: Thu, 27 Sep 2001 01:59:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Something new to play with :) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB1F2E7.61914AC7@f-cpu.org>; from Yann Guidon on Wed, Sep 26, 2001 at 05:23:19PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 26, 2001 at 05:23:19PM +0200, Yann Guidon wrote: [...] > code duplication does not necessarily end up with faster silicon... Right. But that's no reason not to try it :) [...] > "flying calf" is a 20-bit stereo A/D SPDIF (coax) converter from Midiman > (i got two of them in a bargain). > however, minidisc recorders have an optical input. so i have to hack > an optical output to the Midiman converter. With this stuff, i finally > can record with 60db SNR :-))) portable minidiscs suck when you push the > sensitivity of the microphone input. My MZR-30 has decoupling problems, > the internal A/D is not protected from the electric motor power noise. *ouch* > Now, all the conversion will be done externally, which removes the > other limitation : once you started to record a track, you can't change > the sensitivity. And the flying calf has a 6 LED level indicator per channel, > it's more practical in the dark ;-) > did i say i'm an audio freak ? No, but I get the idea... ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 27 05:55:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mSzv-00068d-00 for ; Thu, 27 Sep 2001 06:42:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Sep 2001 06:42:07 +0200 (CEST) Received: (qmail 1996 invoked by uid 0); 27 Sep 2001 03:55:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 27 Sep 2001 03:55:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8R3tSK20943 for ; Wed, 26 Sep 2001 23:55:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 03:54:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8R3sp920686 for f-cpu-list; Wed, 26 Sep 2001 23:54:51 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8R3snC20683 for ; Wed, 26 Sep 2001 23:54:49 -0400 Received: by moria.seul.org (Postfix) id C3AB714671F; Wed, 26 Sep 2001 23:55:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8E2B214671E for ; Wed, 26 Sep 2001 23:55:04 -0400 (EDT) Received: from f-cpu.org (nas25-7.kdl.club-internet.fr [213.44.96.7]) by relay-3v.club-internet.fr (Postfix) with ESMTP id EE3A21687 for ; Thu, 27 Sep 2001 05:54:45 +0200 (CEST) Message-ID: <3BB2A322.DCD1CDB@f-cpu.org> Date: Thu, 27 Sep 2001 05:55:14 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Flying cows (was Re: [f-cpu] Something new to play with :)) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Ben Franchuk wrote: > Y> "flying calf" is a 20-bit stereo A/D SPDIF (coax) converter from Midiman > > (i got two of them in a bargain). > > however, minidisc recorders have an optical input. so i have to hack > > an optical output to the Midiman converter. With this stuff, i finally > > can record with 60db SNR :-))) portable minidiscs suck when you push the > > sensitivity of the microphone input. My MZR-30 has decoupling problems, > > the internal A/D is not protected from the electric motor power noise. > > Now, all the conversion will be done externally, which removes the > > other limitation : once you started to record a track, you can't change > > the sensitivity. And the flying calf has a 6 LED level indicator per channel, > > it's more practical in the dark ;-) > > did i say i'm an audio freak ? > So do you have a TUBE amp too! no, a bunch of LM741 connected in "impedance adapter" mode. well, that's the usual stuff i do : one 8-pin IC per channel, one pair of batteries and some capas for decoupling. However the analog stage of the "Flying calf" (that i'm turning into a real flying elephant :-D) has Motorola 33078 AOPs, and i am trying to find the correct resistors because the current setting eats up almost 30db. i need _very_ sensitive inputs :-) Up to now, i have sawed some part of the PCB away, so i could fit the TOTX173 (opto-electronic output module) in the slot of the metal case where the 9V power supply comes. i didn't want to make holes in the metal. I have also placed the LEDs in an individual PCB to avoid the stress on the pins (which can break easily). I removed the RCA connector and now i'm sawing away the location of the 2 JACK input connectors (i'm putting a stereo jack and a variable stereo resistor in the freed round slot of the metal case). One sad thing, however : there's no room in the case to fit one 9V battery :-( I'm doing this mad brain surgery on one piece, i got a spare device in stock (who knows what could happen). And IF it works, i'll put the PCB of the two devices inside ONE plastic case :-) [one 4-channel 20-bit A/D] mmmm yes, i know, i should be currently installing Cadence's soft, but when the soldering iron is hot, we have to use it ;-) > Ben. yeah :-) Michael Riepe wrote: > On Wed, Sep 26, 2001 at 05:23:19PM +0200, Yann Guidon wrote: > [...] > > My MZR-30 has decoupling problems, > > the internal A/D is not protected from the electric motor power noise. > *ouch* right. You can't even filter it out because the frequency changes with time and the spectrum is rather wide... What the point of going digital when the analog side is badly designed ? OTOH the "line in" is correctly decoupled but there is still the problem of the sensitivity tuning during the recording. An external converter is the best solution. > > Now, all the conversion will be done externally, which removes the > > other limitation : once you started to record a track, you can't change > > the sensitivity. And the flying calf has a 6 LED level indicator per channel, > > it's more practical in the dark ;-) > > did i say i'm an audio freak ? > No, but I get the idea... ;) hmmm and what if i say that i have a Aria Pro II bass guitar that i equiped with a pair of _big_ Bartolini pickups ($$$) and a mini internal amplifier (2*9V batt. + 2*LM741 + 1 stereo jack + 1 dual switch) ? Given the fretless handle and the flatwound strings, can you imagine the sound ? :-)))))))) And now do you understand why i could not resist hacking into the flying cow ? The next step in the audio path will be to have 4 synchronised tracks. I can do 2*2 tracks (i have a pair of MDs) but the synchro is not OK. having all converters in one box and a single push-button to make the "clap" will help the resynchronisation step. > Michael "Tired" Riepe WHYGEE, who has a life beyond F-CPU ;-P ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : i'll take pictures when the slaughter is over :-P ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 27 14:06:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mkVg-0000Dh-00 for ; Fri, 28 Sep 2001 01:24:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 01:24:04 +0200 (CEST) Received: (qmail 23662 invoked by uid 0); 27 Sep 2001 14:19:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx10) with SMTP; 27 Sep 2001 14:19:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8REJTG07077 for ; Thu, 27 Sep 2001 10:19:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 14:18:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8REIh706603 for f-cpu-list; Thu, 27 Sep 2001 10:18:43 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8REIeC06588 for ; Thu, 27 Sep 2001 10:18:40 -0400 Received: by moria.seul.org (Postfix) id 92618146730; Thu, 27 Sep 2001 10:18:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a058.home.uni-hannover.de [130.75.232.58]) by moria.seul.org (Postfix) with ESMTP id 1192014672F for ; Thu, 27 Sep 2001 10:18:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00477; Thu, 27 Sep 2001 14:06:54 +0200 Message-ID: <20010927140653.12005@thrai.stud.uni-hannover.de> Date: Thu, 27 Sep 2001 14:06:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Flying cows (was Re: [f-cpu] Something new to play with :)) References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB2A322.DCD1CDB@f-cpu.org>; from Yann Guidon on Thu, Sep 27, 2001 at 05:55:14AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 27, 2001 at 05:55:14AM +0200, Yann Guidon wrote: [...] > > > did i say i'm an audio freak ? > > So do you have a TUBE amp too! > no, a bunch of LM741 connected in "impedance adapter" mode. > well, that's the usual stuff i do : one 8-pin IC per channel, > one pair of batteries and some capas for decoupling. However > the analog stage of the "Flying calf" (that i'm turning into > a real flying elephant :-D) has Motorola 33078 AOPs, and i am > trying to find the correct resistors because the current setting > eats up almost 30db. i need _very_ sensitive inputs :-) Shouldn't you use a less ancient opamp, then? I won't suggest a 5534 (it draws too much power), but what about a TL071? [...] > > > My MZR-30 has decoupling problems, > > > the internal A/D is not protected from the electric motor power noise. > > *ouch* > right. You can't even filter it out because the frequency changes with time > and the spectrum is rather wide... What the point of going digital when the > analog side is badly designed ? OTOH the "line in" is correctly decoupled but > there is still the problem of the sensitivity tuning during the recording. > An external converter is the best solution. Yep. > > > did i say i'm an audio freak ? > > No, but I get the idea... ;) > hmmm and what if i say that i have a Aria Pro II bass guitar that i equiped > with a pair of _big_ Bartolini pickups ($$$) and a mini internal amplifier > (2*9V batt. + 2*LM741 + 1 stereo jack + 1 dual switch) ? Given the fretless > handle and the flatwound strings, can you imagine the sound ? :-)))))))) *ba-boom* > And now do you understand why i could not resist hacking into the flying cow ? Of course. [...] > PS : i'll take pictures when the slaughter is over :-P *hehehehehe* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 27 16:16:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mkVg-0000Dh-01 for ; Fri, 28 Sep 2001 01:24:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 01:24:04 +0200 (CEST) Received: (qmail 20950 invoked by uid 0); 27 Sep 2001 14:19:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 27 Sep 2001 14:19:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8REJWf07105 for ; Thu, 27 Sep 2001 10:19:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 14:18:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8REIdT06582 for f-cpu-list; Thu, 27 Sep 2001 10:18:39 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8REIbC06579 for ; Thu, 27 Sep 2001 10:18:37 -0400 Received: by moria.seul.org (Postfix) id 6CB10146730; Thu, 27 Sep 2001 10:18:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a058.home.uni-hannover.de [130.75.232.58]) by moria.seul.org (Postfix) with ESMTP id 2EDBD14672F for ; Thu, 27 Sep 2001 10:18:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00887; Thu, 27 Sep 2001 16:16:32 +0200 Message-ID: <20010927161632.14448@thrai.stud.uni-hannover.de> Date: Thu, 27 Sep 2001 16:16:32 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Bit Shuffler (Take 2) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=FCuugMFkClbJLl1L X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Hi! Here we go again... four bits at a time, this time. I also separated the sign extension code in the 4x4 version (that made the decoders even simpler). There are still both versions available; if you want the old (8x8) version, set the constant `FOUR_BY_FOUR' in shuffle64_config.vhdl to `false' and re-analyze everything (we can put a constant into the global config file later, and make the local constant a copy of it, if necessary). List of files (in compilation order as usual): f-cpu_config.vhdl # global configuration package eu_shl/bit_manipulation.vhdl # support package eu_shl/shuffle64_config.vhdl # local configuration package eu_shl/shuffle64.vhdl # entity eu_shl/shuffle64_test.vhdl # testbench Wondering whether it's faster now, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --FCuugMFkClbJLl1L Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-shl-mr-20010927.tar.gz" H4sIAEUwszsCA+w9a3PaSrL5av+KKddWBRxeEi8HjrMHHNuhDsZeMCfxvXWLK8RgFAuJ1cNA fv129+iN8AM72b3nmqokIPV09/RruntGylRduHl7pufnVl4ulaTSR7lefPe6H1Yp1atV9o4x JlUq9C+TvX/Fp8RYvVyt1MrAQBWg5Hql9I5V3/2Cj2s7isXYu7mmzhSub4UDsOn03V/uM03T /zQPV0eqaUy128L9bKK/jIZUKtU8vafoX5bKUh31D1ZSLpfKMkDV5Hr1HSu96f+nf/J5dqbp nJ3lT66GUZXvw52MmmU3imGw82Hn82Uvx0zVKYDCcgxMpYQQy9n6lvPfyWAKpnXLioy+/85v LdNd2AXVnCMc/rkvFWTWYBdC0Kyv8QVn8N245RN2Nuq3euenHlwZ4G7Omb3gqjbV4LYz48y1 uZWfmxO4ooyBZWAWlGI4NvvAzq+63tAKkuizhWUuTBtGdi/PL1rfBp3/Os0hSmUy8dD1L6/k EEfBG16F4YZ5X2BSXcwyMmrQH3X6/xi1WwPABT+u+60r8QsH+x+4MbgZnLS63RBy2O8y7qg+ kZpPRK5FiMzNeyBim3MOQ5jtuNMpc0xW/PPL527xdDiyLW94HYZPuFpgZSmNR5ju6OTLsPfH CGfNFIOuXnfbF53BgHjyNcKY6loWNxxmcZ0rNk8i9gGvZ5rNFop6p9xygJhqBrdJiAegP0tR HW5ptqOpbKlNnJl9wMwpDkMIzYCbhqIz19BAzOxKELI4KtchEPjuWJrqaKAMFBGxdhjRHLDV NW9lwErwA+0H979b/BYoc8sGQmy8drjQJDtR4CeHya+Jg1tuMWUMAmamxfg/XeAHRCuDBsAE LGTGNCYwJZMGK6ws58eaw7T5QudzEJCCzOVYOYAmYACsVQjwHjgACEGbpKUJAc1Nm9CYFpoZ yNBS5hz4zdHdqWbB7aXmzGjgcga+wUwDbBvYX+jKusDa+MPiU1fHySzx0jWM9Bj06AIKnTwW zArwmdYdW3MnKksJBNgltcVl2XPnbZAN/FIVFX4LmMzFcHCN8jv987SXDScVsA9GAH/PCXhm LtkcBd2VPCQ6XQeuQwHyiZBNx2FzCLmI+9NxhYxzxO+5MYIrqgIu7jMGpMCgXB2Cc7c/ZHOO kUKzKZpgKJiwKajSIa4s0zGd9YIXWEvXzSXcu1d012OhkmM11PoRyzgzxUHFNAiJBM5Xq+At uVoTPOfwV1WShSWBD/zRpqF/tLMFdmECtqXp6pOIzRAmsoSuLGZfKBTY2HWINoQgW8NYpU3Z 2nTZTAEL5Ibp3s7Q6m3TtVQes3mp1SYfYo3WZIIgrO3awq1yaOKod+AN4qZrqHegqbL8oXos yUfn7YieItpBWQqMnmAVDy9EZlSnY5L2QQcWapBwhFqM2h+YrGkKTYPp2Wyu3c4wcvzT1WCq IIDLa8QUnxdjLbii2KZBMZv0QppTmD1XdB1YtbVbw5MrWIVUYxn5oo2YFGIUxxGixWxtayp4 7pzPTWudzQGAsgBB2z4TkwL7qliGZtyClTsxgxV+rdtmquX6MqF5keI8Wvo6acKerq49w7sF /GhSU4tziN1TZwnDm6Rs9GHgScPgBgYBRuCgvRdh8rSKrREPXHONCbdINciY7evpvDdk59zg Fsz4yh3rEF27msoNcBGY8QKv2DMw9fHaD7VnyMPA44GdmYCY4laTcYgwQMOPFoH3ewjR7Gm9 B/cAzsEgFjguS+FTV5xwaGHL9MNZTtBKEffMhOVdeJxD8Qm1C46LloQo0Ee+dq6/XA6vWat3 w762+pACXN80KR6acBfjglhDQAWYBcC8LIiia295uTjtn3yBIa12p9u5vkFPPetc904HA3Z2 2QfDu2r1rzsnw26rz66G/avLwWkB1meObJFJPSDiKWnJwtXOUTQ98NEbUKw9I2MlZ7a4yjVc txVwqMX6ceUhEkU3wURxmkEAQ0E2MUxAAM+xpaWBvUBY2VArDg81m2MdQy3kWPUju+Zop7C8 Kiroc+AiAkinc6wNKxBCXrSgzpIlScpL5RIk3MNBC+e03+20+63+DdM45819zGCGg1P6VbCd yUg3bzV1JEm1SgFSmub+vp8GnIUJI1jAPuDa5UN6jK+RlIpGsrvGrqgRN6xvYzDfT8dydPUW a72/eAc5BMzeJxvPPgzFcVGVjWNWbhLeh3OQKKJULPLhYUjgMYyYN0UxDmFcHJ1P45AdCWR9 zKophga4vFUA8jsdwz45M2O2O8aV08+/0Zd9vBbhQGJ5iU3MpQESKzGBH1zAclTwURHKafGA BWUOwWUrgT9PT67BLYEC2pUrDOsekkDTynjksx76RArrCSEh1ShETBqwqAOaFxjkAHNwxVJn 4ESqQBuYY46N0f3QfM5OSpCswRLxEgvdlUdItk5wmYYUwIboCA4EDFquyKIpr4IQoWRf4juf AUE0/TCtMJPgQDuSJ2AeIkw/G3Mi6bOXziTMHxIuoekdspwY/lYqfmwiCPy75LoZkZkYInSI NNPP1RXHgUDrJKcZya6jhsh8NraQxjAQjE2g7LVFGr0ZOEJqzZdYEJYRA6ywAXM/CDgNyAIw rcIE2zLnUDoWZllv8fuKq7lfivvLoMhloHaBxTrIlTAFQ0AVl1BKtw+xCO0NL9qn/cEI0kDm j8esYAG2iuv7TCz4fjntaQCkFknCsDgWXQORYBLis9ZFp3sj8AZtA5H8UvRBwSMrGfDZHDiu hOV4tuAT8iu2OUfZg2uLVEXUGDbUxirNKFKTqOYkYNPmntdRtoO5F+ZPc4jnAoHKYWEDq0YO IjwPrk+vrjq9c+I6zvNcse8gcN9rNi3yiISvFJRBOHzY79JIMBnELgZ2qNrmsEb0uyhOi3Id JhLyHAs49pNEihOm6gY1LrEPCQMkriwDgRTre2BnVfBt4PMl60Gif3H5uXN2Q8hNyi3D9do1 dPRooitmpRJqG4cLzRVYjy9hErZIDJXFggMZ24Qlgw0cZc0c1xDp9s7BS1fAW8FUGlGvArF1 W4PrEVynT9y1asJXQ6tDBgOdRk2QUly0F7ACPUHAs/EUAqVmOqgw2xhoyKjgyc+JgA/BXgHM Y65And9gpRUuRMesUirLE9bIZxNUhG+wFIakZiqo50YxUEQuWPHNshhvjiQw+cadIubmFlAi m+SPaiTDr8cVqKiXQjfO0oSsjlUSyDAvoIxgg265uQV0k+5mXgZh3yvipBwk/tZkieUm5utR mr8ds6Pk5JCAlCb8SjMVNE34Uion8g6cyGmcVFM5kdM4kVM5Ke/ASTmNk1oqJ+VUg0zlpLID J5U0TuqpnFTSOPFS7kHn4rOXsDAbuIpwUkixvEjymkL+qPngkDQ24hCHfiFQ/Jpjf1LXBcv0 taHMNRVzLNXyg5lo/ahrFVeXONWTm5Ouz1+c2keB/soyMUXmk5ygdAKLkWXqttfCw86+6NYk MV+1zv3okDT2kkDd6f8jx7DFLjrYoqXOvrvzBXOwJ4SpCqZpGJuBNkaJhc8NBWaWp+w8Sdlv 4adQlpqMUX0tMj7SH4V+XFUtdyG6XdyOlyIezvSoI22Eu2DXYBO2LOhPFVd3RA5vryErmzOg blp2GiKfahzRZmyJ7EgkYKuC6OXAJ4Ztry3DN2stacNloxsNCdi6IAUQbK5himApi30/FcWM Jax7/Sax2O/hVG8tTE1kZyJFMlxFz3mpDawNC8WhcsjfZ7mO1dGoxsAfKaOai15wa3DS6ZCs F2IHhdoyJTtpNsgeS3UFCVwN6HnJEm2G2JQyecVxfIsgh8UJAtre7Xgnv1BIITzCePKEIOGn hB4otuSwFXrMDmaOs2gUi8vlsiD26ia8KDqvxYOdi4igiqCtNNzfobYrt6N7cyIFXPtpfdiB UQyVg4adJfe6fGPNUKiNMBF5KTWrofxWaGfDXHCvqYAkgQSWt6RW1VyggVCyS+m2adxzQ+OA nwZCDIil0H4zfunl+nPlDgkyxbb5HAKLBf6OA3HfrcBOZhwCuigAdTFV2h8NO4SaIazJ377a NWmN6BKpjFq9z6n2Fk8jfdDe4wkegX677KdilTdBQ8iHMikC7W3BWklhIIR9IAvxGOixx9ME wUAoreQ6vs/BmCLdSuwN+U3MsTlZp3Qyyaojm1Gabt6yKSztos7DJpmJiwG2vAA7VQS2JipC qnvWBvqBRpsXuCxBhLIxSMHVtdhgsMx7bSIKROEXgdF6q5bIfMXWJZBXLIhLc5axsPsE49xF lv33Rd+PG/+z77MnmM2sQjk02Vjs7UbVnQX24ZcRXNRwfbkHMsTzOjJ8fwxhFBP8dWBTyxk6 w4p9EqgPD+GebpoL6h8T2Jp9EKAofbyF3z2S6ybpBBltPmmeN+fhPBGcLU3aNNFIPRblNuDB 5nSaH6/zklgvcSPu73GxyDG5PEcEkes/HhbNjxQh/dgmHA/8B/z+IRZHf+cIDExTRfV+oGuO o/MDEOUMoybmbaxhZh8Vrtx8cRdUbNiwpYU1OqxZEPRCP1D9Bg6kk7oL2sJhQh/T0NQNjtaP oR1DJm72B3u8lvkd8rXd6/wNz3739nmF81/cHcGlVzsG+PzzfxVZqr+d//t36x/S0hGk2drC 1UXmteNRwIfP/0l1uVIT+pfKcqkswc1StVp7O//3i87/paoZimco0VSu61wxTJeORrAoVLgM YNA/MRdri86DZE6yeHRMSpzz+82T7++2404KUCvkYSkzTFjVoRT59Hao4u1QxV/mUAVi+1tn 0kh3rNw9kwoyuUix9LEoV5lUa1TKDVj3PBdhp6sF+9v+vq6NLcyaOqenp819rEbwW/JQhqLr kUMZbSB5EfVSSGn3RNMebI2LA05gS7hljxvv+3tBfozc+mCZFuS4ALaxUR+kzBt3mkQHqzBV sVUFaqEQtXdlhFX9zqjB+LZjBsPaGbHRkJDvCFYIMK76fHZDdFBkb6JbPZPJEF0atp2Q6Xzq gKdp8PeyiOf6rHUeypcQuS5ubsUMaPDDeuJ+UAaJqyfJUY+JPsaP+XoMPUZXFJkcTyyHLGxQ VR4n+0y6Yol8SAHWr1VAnCHz9Th6hgYiPGyQfV0VYLmYjJDNRDMoNYK+VpAkZHvhIY94T6b1 XufGrTPDmQXdBkXJsfWaurnJQ1PdyLmsLAwSvYh8fmEpt3MlbEKNzOkUUGJ/00Kin7CFmAZm IJRCrCAPuFxrtFoo78VhMOpigNDX64yWRThFyXQhVZTgj4Ys7IUNib09vyGxhh94PSI8kPqr LQ87CnU8fpJQw0F3Uo7dyfCnTCxSxyoGYDt8Ee0N/TyFlDCNkaok6T1xHM/rxIjD5agjwc0x q2B3TiNv4SvMGvGQDd38dMy6dB3xfk9V9N6dhDi+g36/Y4LNMoCORmfZB4Elj50sApURFAaI G97FMl2UYxdV7BlmvrOihwkRV4Qa4UMMltnxJ/FzbzzOfPeN7XuWtgbg250UfpXDr+VsM4JF fh6W6FDpCUOj8HQKxt42SECiE+DchTIinuIpeTze4kKK4rlQxFVSXWi3POjNg/5feRBuOwrT 977Jwbenuk8Kiqc5TzDw3+c7mAm8PNnfyWee6y85SE+Nn+oQhN+z4sCIn+IcoScgimPPhO8Q GV4o4tbfXsTh7qKHyAPnAAUHiUTlUPtQCsIr/pJiv+TYL89SY5ZAXoHUY+4QeANZXkjtLkbt Lkbt7oNv0IEjPDo6Ai+lw0cgApNnhqvrwVQCC/f0ksF/P7By1hdoqoFnCDXeCo05zcafW4H+ 5W28LL3MxuXn2rgsbHwlwqBMNv6IHcsxO96wLPllliVl/Wk8zbJW6dHzzbD+M4KnsCsvdoY/ 5OiPV4qcPsK7KKknxs3o2P+gsJmw7V/WDHu6Oyi6pthP8gU62xZziGd1EbDGJ0mGEj8hRWhT mO9vwCNcN7xeQARFL2gL5HtJ16RjCdO0zoCQ9CsI/xEZ+3PzgASNTCvHejn2vvQ++xg7r9mO epShVqb1nnpj2ThfSjwAvxnpU400ZpCBmUZM92EjtTatwvoFRmptMdKt7PxsI7WSRoot9Gyc LWVrsxVfYaKBirnDHPu4wuwl/EVv5FhYt8cH07nD8nWZ5Rf5/EGDLehtIW/Hev4t5z/smTud 6rxWeeGroB4+/8FkuSZ753/kWr1SxvMf5crb+59+1fmPVDWzPBv41/GpDrjuivPXb8c93o57 vB33SDnukepHdNyjHB73qDOp3KjUG9KrHPcIXHR0Ehxfp5qTHllm5TxELQA7qKwqB4mXWe2H qdzZ5bA/at+M8F/IC8amiYe+MEFyLJeLlTxJKbltuo0TfFh+vQ3DWy7wf2P9f+E7IB9e/+FW qRZf/6V6qVp6W/9/9frvLfz4KFseMnfvoXP8JnwXHyYbGprzlgG8ZQBvGcBDGUC49NdfeenH m/h+x0KytE7cTq62XuKAr2ZxIqs1LdO3KGKQbQZq/K+dz9dfkq9T2t/D6h7fz0UwFDOgyOcc fmxrNWQIU7IF6A/FR4cMBy60nzvcew4UNE/PeGfmLj4hqq8ZX6m6a4MVZQFwgES6SdxN/05/ +51W2q2+mY4MrqeiAuVY/D71zhriQPqtwcRdpF2/0FZpl8F2cPsx5Q5I6X9nEJvfs6mu3Aon 1FZFLgZE3xMFwF8AcAsSeqMBSRnxIPBwm7bkDT2puqneFS0OyV2Ri5c/asbCdWyWcQ18tw6q 6US/SxWr7aTO2Ei5CgFF2IXrAHb4fgNAGPeeYFJk11u2g7yml7cnJNxC+MKexckVDsRF/0n1 WuUA7tl4vg1dbArxzoVFbMs+UiwjBseMvG2MszbHqDiS6B00MVfFiA8WlF9qE3xVZkMC8qtI B1AZjyD3hyVIeZZfYU+QTvM8bwg9VJo6pBwCP9ZRfqz1W09t/NKGlc29nSraG/p2UDrAFrDo CStKhgVDfZ49OCkOBwHZhzuKwclxODmYlVSLwZXjcOVAVHIlBldJwH304cpyDK4ah6sE86jE 51GLw1WDeVTi86jH4WrBPKrxeRxF4Mbj7fL7GIfbKr9WHG6r/NpxuK3yO0nAbZPf5zjcVvmd xuG2yu8sDrdFfuEmxMauxPtv77NNzKwnpvHeoRfq7sd3LpObDcKRsbsfd3lZuDzLYFR38Zlc eisZRoqx5uTFuuy/+y+MCzNt57iwWj04pHj0Fhn++pEh6vERu16tMlJ2qyvHAcvZrT4aB6xm tzpfHLCe/VneJ9xlw/s+Rp1PpzeRPcX5dHNn53vzo7/uChu1ULGt+zNMWRifb8qKDXUe2OpS w/+DIXzwpmiZjuLw8C07BN67vD4VL9nyhwT3bXo9CtbdhYilewXw6Gh1xHCDuJ1jw4e3ovcY 62Otfrpydj6KsNzxKMIy9SiCGLLlbHvbw50c2Q5Hum7qyOGWkcP4KbfZ45zGB+jPHLAlBmwf MLbV1BG1LfCOkwoehoAEPOfpDG0mFuHRvtipvvD6TMuBvaeiqxwixuxWlBigG48Wto8cIMzn vXJxSefojqBgLDG/WlwGlaIC33RHw0YTrBwQEjaLxuAw4pKKzhQkUG4+NM43VHxEoRYMb9N/ S2Ka4v3dDyIYRhCUAwTDRxGkl7uRhgL9dw985XDDpjizhwYQD3KSiIbBkUrXTTxUQSclZXws 43v8oCTnHtvFu6KcemhSmzL5UDu8+4BnKn8LBwRHhZChTABC54TwZU+uG3sUQRwRip0rjH6H yX779q2Bbz+j/24IpOYu/h59ACVu3wF/QFuc6RRfsGGDoRH/RS4gVvqHzv/V3rE2tZEjP8Ov mOXDxQbnMprxK0eyVyYhRarC7Rab3MIn1iS+M3XDo7Ahpooff+rWW2qNZwwJeYyrdsNI3Xp0 q1vqltQabp5uDYI7d4KY84vjw5S1JpP2tiS9Xp/wuj+d3px+gidwRKx6cFoUykRzxUNmyOL4 V3u7Qh9AA9DT23xu6YGhOoOFPdGpm6cK1qp6Pm+bc6rQKvuE6kaainWJQJHnk+Z8Vkk7go72 EVIOzWhoRkKzSNkZDR0pO6egWazdXRo6UnaPhI61u09DR8oeENCGsSGnyfWJe0Z3PA05jqx2 B4eALaKwySA8XSqkQDogxwWE6uaLGgwlL7bEIeLBGp/RWn0shovTtkzQNeeYw8XdkwUAytzz g+AzsNBAMEk8ayDzL0zFgQxZYiArv/jfh+v2qE7VyJ6eQhl8ndnvdfOMs3YbJzpIGsrfxrYs iC/l7GJYtWJMktMe1ncaxKo0aDDsDfMh29j2UZmD+mbwureTP2fL+mI3gVVrQn/Q7WV56jSB EU0wcMvokGd2Z1g1OvQ5HTKPDoygQ5/TIXPpMOgPOW6Aytxa33DcnR2As0k44P/lIapXK8fd 4bjLqG93nFXreJenpV7HGdFxA6dRezyNpW7HGdFxA2d4ztN4O/IQ1eO5hlvGc3T2G8Veledd n+eM5nk35DmkBagEzwWcw3NIC1FDngs4h+eQ5qOy1K9V4PrDhaeFqEGtiBuMtEE/QGVhrYAb DtJBiErUynGXjW+byawak1OCyYxgchoymaUhkxnBZAOnUTOZFqK6tRo4jZrLNB/VZ7KBM7Is 00JUT5Y1nCXLIi1ADWRZwdmyjGkhaiDLEi4uy+5KxF7AJKaoYAkjivOTHV+Lve+Y4EG7Cmvj 21t6QSM8jq3xFNZbHf4prmppdxMHa0uPydpagu5HgVCAyUsALwvGYblqpHNoXOBLnfPTm0lF F1Hg9+kuul/e74PhdD9d4yt9nBFs6XUHXlf0mEHoc+XQe7EtZAPyLgbSliu6Kt6pVdxTEmc6 rYazZ+EURTUcEdJgmUPHW35bDiPadeZRWrmZ1xyXSTfB+NYmWZGLp3+20/ci6e+c9HUMJmAt v3farr/g87Mu6SWIm7BgwxpvsX390pE/K0wDb4ATmGFDal19g9FMYxG71AmWsBE1SD2wmCVK h16I2HJh7IW16TTsrrTJLMII2KKIwube+PFdKUK4kYeexGdc4rmtPkofWOyrnm75CkqCEVqi osSPmI1UUeRH6ePoluuIsnAoDhhmCMwKiIvdWvCZclFE+dsLWbYma6vK4rXkltdxW0TPE9mV KI7W9ShbinDtdhpVOrdFNMv10fEu2rrHcpXBFD/EpybgSFdHnsN7KQMhuPqJa5g76fqCfw9R 40iy3E6tjrMMxXnhpW1bsMza+lOwThrXxYsigl+EdVE/wGf+FiN22TTE2qvsqoY4aVajk9za 11SwTppoNI1fhHVFGu2UuV3Kpi6waeCyiUk2yX8PmccmivRVyVyXTX5dK7OJIn1VMtdlk19X PTaxfiVxklbWY4hPhVGv8Cm+PIAkVBXfOiQORUFao6sMfZpEtUi8bMSWkpgWvVokrih6dUg8 xCAmzF1PesOYpFsNGt1rFqhLY2I8fEWFTtKYZSJSjEtkbyCThPtaOrwmkR9ZHbuOnkhouXCN pa0capVFm0DoP4FlaNyQZf3AkmURk3WU3tvGvRZG7ocWp9vfxGEU28blw48ycrELrTEfJH0I GGRGBf9sd7jtQGcIYvEqO9xSiOAWNG6JpZdRll7eWHo/uqWX39PS6+c1Lb18BUuvn69i6eWP aOnJVwWJtak74aRMG3vK2mO+uWd639XzgpNmTfTmJGWu5yA3TcwBNH4R1hWZA5wyrfrNyVDW V/U7advUOpyaW818ReMXYV0xm6dHzlcki/i8gXEJPR5pS0/94dt6FN0r07gmj4K6avKIontl GtfkUVBXPR7JtzuXihELjLyvJzQVBr3Er8OQOkSuKrR1iEwJAgvsvOrDnqZSHSovHbalVKbF rg6Vq4pdHSrnaIN0B54N4o1linJ1qHSvCaAmlakR8RWVOknlLprT/dyjMou5hQzlvpoKr0nl R1bLl2N4PXp6peKplhp7i6lr3y2K78qk0yYJI227frfctuvD/psZBvApbDsyw7XtaNyCxi2x 7XLPtoMj4JPFvMrGfdyw61GmWk3LLjl65G38Va6Z3OOeiUStcgcEcI78jX1WZWffRsgqbYFZ CHklS8qcTUi7NRG4FFe5nmJh9Okq+tE6JgsWudKSPWVxpKzaxRwbJa+GQuuzfuXDFkfEoQpm H2o+scdAcMRiSB+xANZFLF15boLRByc4pmGwOK5tfcsY0uJ6RJs8YGHjZx5+VoLPiPqZh8/K 8In6Uw8/jeNbZzVC2kUOa/CxGDmBkXY9hS34mtkuhmvhUIS79oZe7YruRRS1cgZnD705zesM 3eBAA//Q3ZbxPANO4LpWOLmN89B7tKu21r9DI2Putvy8TnKvXno4aVCXnWfVterW6ArkWHWL cEXKewToJMs7vXQn7cGaMrz/htNDtYVlpe/7EJohqr4yciMBlRTrkxosdzWYu362r+x0Q1UW WU3jGqBcleX+XLXMscrLDM046C+xuN6yrDfAC8wvjWdy8NNYXRVdifdplcmVRqUeE35mxzYH V+yQh+erJz/TrpL02a3Yc9IzdQ8qep2gms3SL1RVHhwhZV+qV91hfXNelhOpMaI/chIWVUSf WgEdiSpyZcBKWxUzHyPiwOcvFWpgyrgpz2oGA5hmHCmri5RzpLwm0mxRCUGZNuK0cEs8S2hb Ix3ZUSxd7DS3RErHW9d2OD07socGOm+JlI43dUho7Jq4Ky0GimpCz24CgM4W6mkKOTcdXMzb fFZ+wp7ou+fy4sM0xxseYgwWM4OyuyhHmS0kysTJct61sC9/dBcQe25tdn0yv72c4HLhGP/i o4WwkVN3r1aLw/5vr3eP/9h7++b9u4RzzRTDZUPdP8U7qNsk0kGIlLKlSKMQyWCFSAe/QeOI mgwWiXQQQVJYIdLO2/cHu/+mkSQWgXT0fhewSCSBRRDi9YffY81Tl3UDpP23h+9KkHDdQiHt lSOxEGn38PfRv16/iyKlLI0h7ZUgQU3rKG5c++5DeEoL1so6OhYRPUXszmpBlwLUg/qoOvhn Xbzb+QQvXVXElKqPz58Yo/NGXm9Hirx4iZFaGXoTRDBU8O0mz/X3AX4PzfcIEwaQACTDr778 EsA9+BK9w+8ufouAppiAvhcIY4pf6EnZP13gB7pFRMhS/MaGQexR+HLsAAzKuW4ixT5L5MWz Z3ArjVe1LjzJfMmgrpp1dBdE07HJbXs2WSwq82NpqJxypMicnJGzlurkFTzkin+MRX+vxEzh ROZXGh/68tJW4YYMyCpFjLY9F7hIw8WwFEkHOLEFgY+pxcIO4luIthZ20jhpbZi33TcSeBtI BB7BJci4mF0klxez2Smn1bpqlvUweGukZsmKfV8srH680y8klXQ8iqF7HbZqISZvW6XY5FAD 0wTN+ot/t2bTorVot5/wKfuv2fSqBWnwTT1cpVoB40ebrx9MrAiebkVi0yFPbm8DD43bbie7 7QYFUCXYzm+iBOeei3vtWpWQs9ISckaXwEwJ/by0BOcEVvVQaV5wNK2cOfP0TVipTaxof6iF Z3M+ZJLWidRvyQz0GgRS7iQiknKbUkRKHQo1iOpPqT1Ud+0qQacGEd1SpsXCvYVV9JhSTHC1 eIB8kB2S0YBk3BTonErpYQrvqEoQrkXRaZUmvPRAAJXihVL5EA835B1vkzwS8ubGOBEiIaTX vwnuADIHMBItRKw1bMBurz9IWZYHgMwDBCAANgElOMHWHd9Q0Fx76eoBuoVDsACWMgLQawV0 3icAAvrNDe7M81E+lX+KMFafx5cifHdyxUfIjJN/9k9HlZiwLKrQN4Pd/uveq64XiMQEYdGA u4P+61c9ApD5gK9fBbEqEIwA3Bk9H25gKCLsATwP8Z/T88kn08OiZg8Dju3ko+w5G6Z+ewKO 7Yzy7PmQEYDMB3w+DDiGFItyLNpDoaTqsdGK72LYqKL0BIAhG6GjIWAlNqZsFTaKThY1Oxlw crf/qjvKfE4KDjmAME5DTgoOVeCkGKx1ORmPYKHLWTLvaQ93GLJ5aWQKEYlaznB8Jl4easIy ZeLzrIybgeHr9TS6j/sV1irL/jjoaOOqY5lLzox6duYag/ebBaE0PR1B28x8dHZmL8dsB8id 5W+QrkuxNrG6tU1gHihM5d64s3wQkYIOvIKk68GDFjTzQaXD4c5yJdwZD8G6OB9zZ5n/d65V f+fa636dkjvEUs2CqxXZ9ogeTfjOqHwwoXlT7Mu8/zmfzOarPwJW/v5XN+8OBv77n4x1m/e/ vvr7n5rNIIfv+cfJ5PzjFB+QaZ4Ea54Ea54Eu8+joFq48F2wXpV3wSKBpuu+F4aZ59dn8MjX MQcyOfAxnyx4jz1oU5SdHTwfhp0K3hB7v/vHe1iK/Pn2j13qPVEFwVcgNAi6gN03Q6Ei/5mk Ef/wHkkyDfp4cXZ5cc4bbDJ5xXYzY2+drYnNP/XaWc0Xzmq+aFbyUlnJU2Vlb5VFHyuLvlZW 8lxZ2Xtl0QfLYi+WlTxZFn2GrPKTY7G3xGKPidGviclQJLXeEMPxggtVNeSczVFylNk7WPR5 ZP+AaOAplujCLjuqZtuUliQIaEoBYA5hAAQlSwCQpF4+ewJ9NWf/UQPzOS1pzRD4ii8h2t47 JQXQ/h8JX11MLGsMMVuQ10lmyHNMAaiWsCY7iKnYoWpy6/90cSyD2beKk0I3Qd8JGB8vOvx/ pLG4Qjux8CetjT/3fhsl7/e4yfXLL79scJs5iTeeLmGE26AaU2aPVihphyxpZ4WS9smS9lco 6Ygs6ah6SZyZ8dJV4V4+5/WScVSjimeRKm4rDFU9KN2x+nE6+fi/Yzlz0+N1LSH3BKyb7Ub1 +MN3fnZJqo2FeG3B3USgxzoW8ZIoY35xfH2OR2I+tW7xukG2ubmQB5M6ifqrrXb7FkA/KE3t 9GmSQLc5Qgdy28FJFodEFPWEJqJlPUngrE6JpItjVvSuy1hdijDHS2GD05zOov1NJyTaSQVa y8sYY3MZQ5UlDvuIFzpOxnzJfPXfGUxtFgXotz60X3DhPbCB17PQbXMLz1BwPf70ybabsRAZ kL9NM0yMfHkMyXMSGt7Jqdc5zXANG+nCeuMafH3tDOlBLeTOxpdJS77O+auYa9tq9YZ5YgXH 82CixAMLEJsWTibYK4iOtRTDvLyttsTFd1d/j0RCT+DgYgsT+m2xlS6+BvxLLqvweyjA1XIK 0563xTah+GKyFbB4EgmsrfYOZQKcUcOFkvjMBQLM2zyB/9PBKRqObMwgtO45nrk474gVDf/7 SCxWkMqfrrh1daXcaNoH67wtdMOl46YT1RPlByFmp2efOiKAcAceHZnwEfFxen0ee7yHHvRc NTjmhFIP++AMNIeCUnZ4eLixjY/MIBfR7SgXAK2Nzc1NHEngrpBHF6xncBOevWGOgnOL8Rxk QlxXsK5U8g6Bshsmm6DMAEw+ikHNB3aVG/r5DBuSF9cuKUAf4BfNs0HpqUpsNE7mWLLA5EWI Q+nQL9OpzHQKCIwd/jU5t57AWdtvnbeBxLh+E6/iyAMVdmaqM82TOM5WgNhrG4PnAgwzXe34 Jnqe/uQmejcAeoHsO8bno3V/oMN8HJpOndy0oFNb7iazbH35ZGWV30HKbOX6FhbUD+cSLi9m um4lBKZy3rmWhGrrJbA8wSymS7LfyAqFiDMmjpBky+nyC8Fdi1NQqEZzgP3abSaBUuQcHN9s c63I/zjhf3we8xEHfWTJ+UyBWUqar9I2+JrMzMRWl+BxIv6nStUTS4xG2NlTq5svnG7a/cMO ir0oM+D83riDTvYOGjVetWM+F52xbqpyvtyj5J6OYqmrow6W6KirRkc1Our70FG/voxKr62d nn632slVwtBdXwv/IFqKpb6WGi1TU+NGTzV66vvQU1Jun3IRs2UXeA2vUsIoeZkwlazVhCpI EoBUZ476sJUBc5WBLf7WMMAjMbiX6DWitsKtrnEJ5fSlFDDxuuc9uZQ+LJfSb4xLaQ0ufUsT CByZ0xMIOEfiswdcHWimjmbq+PpThzilIi8ZCAH0hbfaLANCLArbSmI2uFEHbiMeSMGupgHk gvgLaQE8YGtrgYNSLdAYuo0W+BG1gFjE/OTKQNyb0MpgR92Ui6gDcZOuUQiNQvgGLUpyho+5 5LUN8zR5PP/X/UTZNMreiVPH9sKtOHmtzQi7dU+Plna5HdqI+/cp7svFLSpt1Wdf3DvGUyZC onwwEDIfVPzxVP4LkEMJUirk9kwuULec6oZeJ6pJ6RIhXTppV5izY3JeZY5Wl2eN31ddVqWd vnBioRHYn05gSwVn6Y4KJ5TZT0mM1Puz5mnptOi55n4E8dMhi7T47Z8uSrxmcHG5Eb/vR/zS BxI/PbVFZkl5tMrkPyPn0IzzH0m8KQ9jyYmuipCDDGM5L+ShdovkKLuQ6TXbEd+Hl9cd9XHy sMKrDZUlzFCLBIvUPyMJT1bVf4zWf3ul+m/a6L9G/z2m/vv1ZYn0cqtDHENuFOFPTMuVNaIV +VJrRHEIvGRRKMOgNHrxB9GL2WaoGS3/I7F4iOpNq4dmTFaRq2Xi23IVrdjbyESYf9Ou8lbb pyACw886duEdcRZOH6oHobn4jeuJelxNa3B1+TAmF2RR9bO3TP00y7JG/XwD6oetpn5gc4bY mI1poUb9PKD6cfaZQODmF5fAjesCg3Gs+3rHZOGd+2Iynxh9A5SgYkSJaBHbdFSN8yZwVPNr fs2v+TW/5tf8ml/za37Nr/k1vx/593/hDW/lABgBAA== --FCuugMFkClbJLl1L-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Thu Sep 27 20:26:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mkVk-0000Dh-00 for ; Fri, 28 Sep 2001 01:24:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 01:24:08 +0200 (CEST) Received: (qmail 26029 invoked by uid 0); 27 Sep 2001 18:20:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 27 Sep 2001 18:20:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8RIKqT17240 for ; Thu, 27 Sep 2001 14:20:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 18:19:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8RIJs316747 for f-cpu-list; Thu, 27 Sep 2001 14:19:54 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8RIJoC16726 for ; Thu, 27 Sep 2001 14:19:50 -0400 Received: by moria.seul.org (Postfix) id 394CF146733; Thu, 27 Sep 2001 14:20:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf05bis.bellsouth.net (mail205.mail.bellsouth.net [205.152.58.145]) by moria.seul.org (Postfix) with ESMTP id 029BF146732 for ; Thu, 27 Sep 2001 14:20:06 -0400 (EDT) Received: from computer ([209.214.154.140]) by imf05bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010927182051.NHQF29272.imf05bis.bellsouth.net@computer>; Thu, 27 Sep 2001 14:20:51 -0400 Message-ID: <001d01c14781$f0df3dc0$8c9ad6d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Who Shot John Date: Thu, 27 Sep 2001 13:26:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C14758.06A8BB60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C14758.06A8BB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John is the F-CPU that lost out to Audio Processes. A friend need; Is a friend indeed. Dick Hartney ------=_NextPart_000_001A_01C14758.06A8BB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
John is the F-CPU that lost out to = Audio=20 Processes.
 
A friend need;
Is a friend indeed.
Dick Hartney
------=_NextPart_000_001A_01C14758.06A8BB60-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 27 22:20:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mkVn-0000Dh-01 for ; Fri, 28 Sep 2001 01:24:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 01:24:11 +0200 (CEST) Received: (qmail 17878 invoked by uid 0); 27 Sep 2001 20:20:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 27 Sep 2001 20:20:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8RKKcE22127 for ; Thu, 27 Sep 2001 16:20:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 20:19:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8RKJqV21687 for f-cpu-list; Thu, 27 Sep 2001 16:19:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8RKJoC21684 for ; Thu, 27 Sep 2001 16:19:50 -0400 Received: by moria.seul.org (Postfix) id C6D0F146734; Thu, 27 Sep 2001 16:20:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id AB39D146733 for ; Thu, 27 Sep 2001 16:20:05 -0400 (EDT) Received: from f-cpu.org (nas11-246.kdl.club-internet.fr [213.44.5.246]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 22D8F16CF for ; Thu, 27 Sep 2001 22:19:47 +0200 (CEST) Message-ID: <3BB38A05.BF1EB1AF@f-cpu.org> Date: Thu, 27 Sep 2001 22:20:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > Hi! > > Here we go again... four bits at a time, this time. cool :-) > I also separated > the sign extension code in the 4x4 version (that made the decoders even > simpler). There are still both versions available; if you want the old > (8x8) version, set the constant `FOUR_BY_FOUR' in shuffle64_config.vhdl > to `false' and re-analyze everything (we can put a constant into the > global config file later, and make the local constant a copy of it, > if necessary). btw, you use an "old" version of f-cpu_config.vhdl. but the newer has more stuff, that's all. I think that you can keep the separate constant as long as we don't know what version performs best. > List of files (in compilation order as usual): > > f-cpu_config.vhdl # global configuration package > eu_shl/bit_manipulation.vhdl # support package > eu_shl/shuffle64_config.vhdl # local configuration package > eu_shl/shuffle64.vhdl # entity > eu_shl/shuffle64_test.vhdl # testbench > > Wondering whether it's faster now, me too :-) i compiled with simili, it seems ok but i didn't go further (time to eat). > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 27 22:20:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mkVo-0000Dh-00 for ; Fri, 28 Sep 2001 01:24:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 01:24:12 +0200 (CEST) Received: (qmail 18599 invoked by uid 0); 27 Sep 2001 20:20:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 27 Sep 2001 20:20:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8RKKng22213 for ; Thu, 27 Sep 2001 16:20:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 20:20:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8RKK0H21743 for f-cpu-list; Thu, 27 Sep 2001 16:20:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8RKJwC21731 for ; Thu, 27 Sep 2001 16:19:58 -0400 Received: by moria.seul.org (Postfix) id D329D146734; Thu, 27 Sep 2001 16:20:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id AF9A0146733 for ; Thu, 27 Sep 2001 16:20:13 -0400 (EDT) Received: from f-cpu.org (nas11-246.kdl.club-internet.fr [213.44.5.246]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 07FE41758 for ; Thu, 27 Sep 2001 22:19:53 +0200 (CEST) Message-ID: <3BB38A08.2D6E30A4@f-cpu.org> Date: Thu, 27 Sep 2001 22:20:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Flying Analog Elephants References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> <20010927140653.12005@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N it's getting furiously off-topic but i can't resist ;-P Michael Riepe wrote: > > On Thu, Sep 27, 2001 at 05:55:14AM +0200, Yann Guidon wrote: > [...] > > > > did i say i'm an audio freak ? > > > So do you have a TUBE amp too! > > no, a bunch of LM741 connected in "impedance adapter" mode. > > well, that's the usual stuff i do : one 8-pin IC per channel, > > one pair of batteries and some capas for decoupling. However > > the analog stage of the "Flying calf" (that i'm turning into > > a real flying elephant :-D) has Motorola 33078 AOPs, and i am > > trying to find the correct resistors because the current setting > > eats up almost 30db. i need _very_ sensitive inputs :-) > Shouldn't you use a less ancient opamp, then? I won't suggest a 5534 > (it draws too much power), but what about a TL071? i've had stability problems with newer chips. the 741 works even when no external R or C is used. I don't know the 33078, but i search the best resistor ratio to modify the sensitivity, instead of adding (yet) another analog amplifying stage. > [...] > > PS : i'll take pictures when the slaughter is over :-P > *hehehehehe* i don't think i can finish it tonight. Tomorrow is the first day at Jussieu (gaaah!) and i have to be fit... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: Richard, who is John ?... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 28 01:36:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mmzC-0002J1-00 for ; Fri, 28 Sep 2001 04:02:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 04:02:42 +0200 (CEST) Received: (qmail 25860 invoked by uid 0); 27 Sep 2001 23:38:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 27 Sep 2001 23:38:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8RNc6L25750 for ; Thu, 27 Sep 2001 19:38:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 27 Sep 2001 23:36:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8RNaEX25477 for f-cpu-list; Thu, 27 Sep 2001 19:36:14 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8RNaBC25471 for ; Thu, 27 Sep 2001 19:36:11 -0400 Received: by moria.seul.org (Postfix) id 0BEEF14673C; Thu, 27 Sep 2001 19:36:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a240.home.uni-hannover.de [130.75.232.240]) by moria.seul.org (Postfix) with ESMTP id 50D6214673B for ; Thu, 27 Sep 2001 19:36:25 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03548; Fri, 28 Sep 2001 01:36:07 +0200 Message-ID: <20010928013607.54972@thrai.stud.uni-hannover.de> Date: Fri, 28 Sep 2001 01:36:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> <20010927140653.12005@thrai.stud.uni-hannover.de> <3BB38A08.2D6E30A4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB38A08.2D6E30A4@f-cpu.org>; from Yann Guidon on Thu, Sep 27, 2001 at 10:20:24PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 27, 2001 at 10:20:24PM +0200, Yann Guidon wrote: > it's getting furiously off-topic but i can't resist ;-P Why off-topic? We were talking about "Something new to play with", weren't we? ;) SCNR. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.matringe@IPricot.com Fri Sep 28 11:29:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mw9v-0000Z6-00 for ; Fri, 28 Sep 2001 13:50:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 13:50:23 +0200 (CEST) Received: (qmail 10761 invoked by uid 0); 28 Sep 2001 09:29:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 28 Sep 2001 09:29:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8S9TYf03697 for ; Fri, 28 Sep 2001 05:29:34 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 09:27:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8S9RfV03439 for f-cpu-list; Fri, 28 Sep 2001 05:27:41 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8S9RdC03435 for ; Fri, 28 Sep 2001 05:27:39 -0400 Received: by moria.seul.org (Postfix) id 85B5C14674E; Fri, 28 Sep 2001 05:27:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by moria.seul.org (Postfix) with ESMTP id E5CE014674D for ; Fri, 28 Sep 2001 05:27:54 -0400 (EDT) Received: from IPricot.com (nmatringe.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id JAA05690 for ; Fri, 28 Sep 2001 09:27:37 GMT X-To: Message-ID: <3BB44300.97F72B54@IPricot.com> Date: Fri, 28 Sep 2001 11:29:36 +0200 From: Nicolas Matringe Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> <20010927140653.12005@thrai.stud.uni-hannover.de> <3BB38A08.2D6E30A4@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > i've had stability problems with newer chips. the 741 works > even when no external R or C is used. > I don't know the 33078, but i search the best resistor ratio > to modify the sensitivity, instead of adding (yet) another > analog amplifying stage. AD has some nice audio chips... I also have some audio schematics that might be of some interest to you (did I say i'm an electronics freak? ;o) -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Fri Sep 28 11:46:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mw9x-0000Z6-00 for ; Fri, 28 Sep 2001 13:50:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 13:50:25 +0200 (CEST) Received: (qmail 23780 invoked by uid 0); 28 Sep 2001 09:47:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 28 Sep 2001 09:47:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8S9lti04135 for ; Fri, 28 Sep 2001 05:47:56 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 09:46:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8S9k7B03887 for f-cpu-list; Fri, 28 Sep 2001 05:46:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8S9k5C03882 for ; Fri, 28 Sep 2001 05:46:06 -0400 Received: by moria.seul.org (Postfix) id 0C8BA14674E; Fri, 28 Sep 2001 05:46:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 70D5114674D for ; Fri, 28 Sep 2001 05:46:21 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id MAA25973 for ; Fri, 28 Sep 2001 12:46:03 +0300 (EET DST) Date: Fri, 28 Sep 2001 12:46:03 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: F-CPU Mailing List Subject: Re: [f-cpu] Bit Shuffler (Take 2) In-Reply-To: <20010927161632.14448@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 27 Sep 2001, Michael Riepe wrote: > Wondering whether it's faster now, I hate to dissapoint you, but this new version is slower. It got 56MHz in the synthesis run for the same chip. I'll try to run the whole Xilinx flow to the different versions at some point. But the synthesis results usually correlate quite well to the actual results. Especially if some floorplanning is done. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jtdesouza@yahoo.com Fri Sep 28 08:31:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mw9y-0000Z6-00 for ; Fri, 28 Sep 2001 13:50:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 13:50:26 +0200 (CEST) Received: (qmail 6002 invoked by uid 0); 28 Sep 2001 10:37:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 28 Sep 2001 10:37:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SAb7e07434 for ; Fri, 28 Sep 2001 06:37:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 10:35:25 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SAZP706976 for f-cpu-list; Fri, 28 Sep 2001 06:35:25 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SAZNC06970 for ; Fri, 28 Sep 2001 06:35:23 -0400 Received: by moria.seul.org (Postfix) id B2B0514674F; Fri, 28 Sep 2001 06:35:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by moria.seul.org (Postfix) with SMTP id 249BA14674E for ; Fri, 28 Sep 2001 06:35:39 -0400 (EDT) Received: from unknown (HELO jtd) (203.199.170.122) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Sep 2001 10:35:21 -0000 X-Apparently-From: Content-Type: text/plain; charset="iso-8859-1" From: jtd To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants Date: Fri, 28 Sep 2001 12:01:05 +0530 X-Mailer: KMail [version 1.2] References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> In-Reply-To: <3BB44300.97F72B54@IPricot.com> MIME-Version: 1.0 Message-Id: <01092812010600.02051@jtd> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Friday 28 September 2001 02:59 pm, Nicolas Matringe wrote: > AD has some nice audio chips... > I also have some audio schematics that might be of some interest to > you (did I say i'm an electronics freak? ;o) What sort of schematics. -- jtdesouza@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 28 13:29:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mw9z-0000Z6-00 for ; Fri, 28 Sep 2001 13:50:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 13:50:27 +0200 (CEST) Received: (qmail 23627 invoked by uid 0); 28 Sep 2001 11:30:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 28 Sep 2001 11:30:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SBUoh12577 for ; Fri, 28 Sep 2001 07:30:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 11:28:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SBSs111803 for f-cpu-list; Fri, 28 Sep 2001 07:28:54 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SBSiC11771 for ; Fri, 28 Sep 2001 07:28:44 -0400 Received: by moria.seul.org (Postfix) id C243114674F; Fri, 28 Sep 2001 07:29:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A8DD914674E for ; Fri, 28 Sep 2001 07:29:00 -0400 (EDT) Received: from f-cpu.org (nas5-114.kdl.club-internet.fr [213.44.0.114]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5073C16B7 for ; Fri, 28 Sep 2001 13:28:42 +0200 (CEST) Message-ID: <3BB45F0E.79F8A58C@f-cpu.org> Date: Fri, 28 Sep 2001 13:29:18 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Kim Enkovaara wrote: > On Thu, 27 Sep 2001, Michael Riepe wrote: > > Wondering whether it's faster now, > > I hate to dissapoint you, but this new version is slower. It got 56MHz in > the synthesis run for the same chip. I'll try to run the whole Xilinx flow > to the different versions at some point. But the synthesis results usually > correlate quite well to the actual results. Especially if some > floorplanning is done. so what is the cure, doctor ? > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 28 13:29:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15mwA0-0000Z6-00 for ; Fri, 28 Sep 2001 13:50:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 13:50:28 +0200 (CEST) Received: (qmail 552 invoked by uid 0); 28 Sep 2001 11:30:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 28 Sep 2001 11:30:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SBUq612596 for ; Fri, 28 Sep 2001 07:30:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 11:28:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SBSvA11813 for f-cpu-list; Fri, 28 Sep 2001 07:28:57 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SBSlC11782 for ; Fri, 28 Sep 2001 07:28:48 -0400 Received: by moria.seul.org (Postfix) id 679BE14674F; Fri, 28 Sep 2001 07:29:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 4E6A014674E for ; Fri, 28 Sep 2001 07:29:03 -0400 (EDT) Received: from f-cpu.org (nas5-114.kdl.club-internet.fr [213.44.0.114]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 724C6171A for ; Fri, 28 Sep 2001 13:28:45 +0200 (CEST) Message-ID: <3BB45F10.CA43614C@f-cpu.org> Date: Fri, 28 Sep 2001 13:29:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> <20010927140653.12005@thrai.stud.uni-hannover.de> <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Nicolas Matringe wrote: > Yann Guidon a écrit : > > i've had stability problems with newer chips. the 741 works > > even when no external R or C is used. > > I don't know the 33078, but i search the best resistor ratio > > to modify the sensitivity, instead of adding (yet) another > > analog amplifying stage. > > AD has some nice audio chips... yep. But Maxim and CS have a more agressive "sampling" strategy :-) i have Maxim MAX120, MAX 122 and MAX 198 (all in handy narrow DIP package), and Cristal CS4222(*2), CS5394(*2) and CS5396(*1). The 539x are in SMD package with a 50mil pin spacing but the 4222 is in 25mil, i can't solder something *that* thin. There's also a CS5524 but it is limited to 1KHz sampling :-) And a TI 8-bit 10MHz ADC, too. > I also have some audio schematics that might be of some interest to you they are often distributed for free along with the samples. I have a small pile of papers related to that (implementation notes, data sheets...) > (did I say i'm an electronics freak? ;o) you'll have to prove it ;-P do you have a SMD soldering station at home ? (i don't but that could be useful sometimes ;-D) > Nicolas MATRINGE IPricot European Headquarters WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.matringe@IPricot.com Fri Sep 28 15:24:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48h-0005C8-00 for ; Fri, 28 Sep 2001 22:21:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:39 +0200 (CEST) Received: (qmail 16550 invoked by uid 0); 28 Sep 2001 13:24:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 28 Sep 2001 13:24:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SDOQv27504 for ; Fri, 28 Sep 2001 09:24:27 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 13:22:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SDMqd27075 for f-cpu-list; Fri, 28 Sep 2001 09:22:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SDMhC27056 for ; Fri, 28 Sep 2001 09:22:43 -0400 Received: by moria.seul.org (Postfix) id 3328F146752; Fri, 28 Sep 2001 09:22:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by moria.seul.org (Postfix) with ESMTP id BAE27146751 for ; Fri, 28 Sep 2001 09:22:58 -0400 (EDT) Received: from IPricot.com (nmatringe.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id NAA08851 for ; Fri, 28 Sep 2001 13:22:41 GMT X-To: Message-ID: <3BB47A19.616AE30C@IPricot.com> Date: Fri, 28 Sep 2001 15:24:41 +0200 From: Nicolas Matringe Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (totally Off Topic) Flying Analog Elephants References: <3BAF121B.1219D33F@f-cpu.org> <20010924144135.57848@thrai.stud.uni-hannover.de> <3BAFC217.A4C716AC@f-cpu.org> <20010925024718.06150@thrai.stud.uni-hannover.de> <3BAFD741.52CD7D40@f-cpu.org> <20010926024750.48088@thrai.stud.uni-hannover.de> <3BB1F2E7.61914AC7@f-cpu.org> <3BB269D5.B6B36C64@jetnet.ab.ca> <3BB2A322.DCD1CDB@f-cpu.org> <20010927140653.12005@thrai.stud.uni-hannover.de> <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <3BB45F10.CA43614C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > > AD has some nice audio chips... > yep. But Maxim and CS have a more agressive "sampling" > strategy :-) I meant "analog" audio chips (sorry) > > I also have some audio schematics that might be of some > > interest to you > they are often distributed for free along with the samples. These are only app notes. Beware, they're often hiding some mistakes. Mys schematicds are only pure analog but they can be very usefull (want a nice microphone preamp, especially designed to be used with a DAT?) > > (did I say i'm an electronics freak? ;o) > you'll have to prove it ;-P Well at the moment my own private lab is a bit messy, I'm trying to repair my older-than-me Tek 531A scope (picture: http://www.helo.de/helo/museum/tek/tekold/531.htm) > do you have a SMD soldering station at home ? (i don't but > that could be useful sometimes ;-D) Good eyes and a fine tipped soldering iron are all I need to solder SMD, although I don't do it at home but often at work. Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Sep 28 03:59:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48j-0005C8-00 for ; Fri, 28 Sep 2001 22:21:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:41 +0200 (CEST) Received: (qmail 25107 invoked by uid 0); 28 Sep 2001 14:18:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx27) with SMTP; 28 Sep 2001 14:18:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SEIsU01596 for ; Fri, 28 Sep 2001 10:18:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 14:17:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SEHBk01106 for f-cpu-list; Fri, 28 Sep 2001 10:17:11 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SEH5C01089 for ; Fri, 28 Sep 2001 10:17:05 -0400 Received: by moria.seul.org (Postfix) id 7EC55146755; Fri, 28 Sep 2001 10:17:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id C849B146754 for ; Fri, 28 Sep 2001 10:17:20 -0400 (EDT) Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA03140 for ; Fri, 28 Sep 2001 08:17:02 -0600 (MDT) Message-ID: <3BB3D97E.5AA83FC4@jetnet.ab.ca> Date: Thu, 27 Sep 2001 19:59:26 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <01092812010600.02051@jtd> <3BB47A92.B70A8CC6@IPricot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Matringe wrote: > Mix table, microphone preamp, pick-up preamp, guitar preamp (I built it, > works fine :o), limiter, compressor/limiter, noise gate, VU-meter... > Unfortunately, they're all paper and I don't have a scanner. Tubes are easy to solder and works great for all of the above. :) -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.matringe@IPricot.com Fri Sep 28 16:42:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48k-0005C8-00 for ; Fri, 28 Sep 2001 22:21:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:42 +0200 (CEST) Received: (qmail 5437 invoked by uid 0); 28 Sep 2001 14:42:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 28 Sep 2001 14:42:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SEgaM04678 for ; Fri, 28 Sep 2001 10:42:37 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 14:40:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SEeSA04189 for f-cpu-list; Fri, 28 Sep 2001 10:40:28 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SEeHC04175 for ; Fri, 28 Sep 2001 10:40:18 -0400 Received: by moria.seul.org (Postfix) id C0688146755; Fri, 28 Sep 2001 10:40:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by moria.seul.org (Postfix) with ESMTP id 438FA146754 for ; Fri, 28 Sep 2001 10:40:33 -0400 (EDT) Received: from IPricot.com (nmatringe.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id OAA10090 for ; Fri, 28 Sep 2001 14:40:16 GMT X-To: Message-ID: <3BB48C48.283EED70@IPricot.com> Date: Fri, 28 Sep 2001 16:42:16 +0200 From: Nicolas Matringe Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <01092812010600.02051@jtd> <3BB47A92.B70A8CC6@IPricot.com> <3BB3D97E.5AA83FC4@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > Tubes are easy to solder and works great for all of the above. > :) I know but I'm sorry, I only have solid state schematics. My old Tek scope uses plenty of them, though :o) -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Sep 28 04:48:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48k-0005C8-01 for ; Fri, 28 Sep 2001 22:21:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:42 +0200 (CEST) Received: (qmail 23774 invoked by uid 0); 28 Sep 2001 15:08:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 28 Sep 2001 15:08:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SF8iN07117 for ; Fri, 28 Sep 2001 11:08:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 15:06:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SF60D06677 for f-cpu-list; Fri, 28 Sep 2001 11:06:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SF5hC06662 for ; Fri, 28 Sep 2001 11:05:43 -0400 Received: by moria.seul.org (Postfix) id A4101146755; Fri, 28 Sep 2001 11:05:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id E7406146754 for ; Fri, 28 Sep 2001 11:05:58 -0400 (EDT) Received: from jetnet.ab.ca (dialin61.jetnet.ab.ca [207.153.6.61]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA03959 for ; Fri, 28 Sep 2001 09:05:40 -0600 (MDT) Message-ID: <3BB3E4E5.B6DCB953@jetnet.ab.ca> Date: Thu, 27 Sep 2001 20:48:05 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <01092812010600.02051@jtd> <3BB47A92.B70A8CC6@IPricot.com> <3BB3D97E.5AA83FC4@jetnet.ab.ca> <3BB48C48.283EED70@IPricot.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Matringe wrote: > > Ben Franchuk a écrit : > > > > Tubes are easy to solder and works great for all of the above. > > :) > > I know but I'm sorry, I only have solid state schematics. My old Tek > scope uses plenty of them, though :o) > You can find them on the web with a little digging.Tubes are not expensive compared to power and good audio transformers. Woodelf. PS. Bootstrapping the F-CPU. Are there any ideas to help with hardware bootstrapping the F-cpu? -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.matringe@IPricot.com Fri Sep 28 15:26:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48h-0005C8-01 for ; Fri, 28 Sep 2001 22:21:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:39 +0200 (CEST) Received: (qmail 18061 invoked by uid 0); 28 Sep 2001 13:26:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 28 Sep 2001 13:26:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SDQK027999 for ; Fri, 28 Sep 2001 09:26:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 13:24:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SDOo027570 for f-cpu-list; Fri, 28 Sep 2001 09:24:50 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SDOiC27556 for ; Fri, 28 Sep 2001 09:24:44 -0400 Received: by moria.seul.org (Postfix) id 7C4C7146752; Fri, 28 Sep 2001 09:25:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by moria.seul.org (Postfix) with ESMTP id 0D5F8146751 for ; Fri, 28 Sep 2001 09:25:00 -0400 (EDT) Received: from IPricot.com (nmatringe.fr.ipricot.com [192.168.31.116]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id NAA08873 for ; Fri, 28 Sep 2001 13:24:43 GMT X-To: Message-ID: <3BB47A92.B70A8CC6@IPricot.com> Date: Fri, 28 Sep 2001 15:26:42 +0200 From: Nicolas Matringe Organization: IPricot European Headquarter (formerly DotCom SA) X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <01092812010600.02051@jtd> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N jtd a écrit : > > What sort of schematics. Mix table, microphone preamp, pick-up preamp, guitar preamp (I built it, works fine :o), limiter, compressor/limiter, noise gate, VU-meter... Unfortunately, they're all paper and I don't have a scanner. -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Sep 28 17:08:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48m-0005C8-00 for ; Fri, 28 Sep 2001 22:21:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:44 +0200 (CEST) Received: (qmail 28089 invoked by uid 0); 28 Sep 2001 18:00:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 28 Sep 2001 18:00:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SI03E24137 for ; Fri, 28 Sep 2001 14:00:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 17:59:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SHxQL23821 for f-cpu-list; Fri, 28 Sep 2001 13:59:26 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SHxPC23818 for ; Fri, 28 Sep 2001 13:59:25 -0400 Received: by moria.seul.org (Postfix) id 5A5B714675E; Fri, 28 Sep 2001 13:59:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a172.home.uni-hannover.de [130.75.232.172]) by moria.seul.org (Postfix) with ESMTP id A926214675D for ; Fri, 28 Sep 2001 13:59:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01089; Fri, 28 Sep 2001 17:08:37 +0200 Message-ID: <20010928170837.30463@thrai.stud.uni-hannover.de> Date: Fri, 28 Sep 2001 17:08:37 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Fri, Sep 28, 2001 at 12:46:03PM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii On Fri, Sep 28, 2001 at 12:46:03PM +0300, Kim Enkovaara wrote: [...] > I hate to dissapoint you, but this new version is slower. It got 56MHz in > the synthesis run for the same chip. I'll try to run the whole Xilinx flow > to the different versions at some point. But the synthesis results usually > correlate quite well to the actual results. Especially if some > floorplanning is done. Hmm... maybe I should try something different. Can you please synthesize the attached file? It's a self-contained 64-bit 'rotate right' entity with explicit and/or gates which may become the new Shuffle64 core -- if it's fast enough. I'm afraid we're hitting the `6 gates' rule with the bit shuffling unit, no matter how we implement it. Maybe we should add a second stage to the `bitwise' pipeline (shift/rot/bitrev operations). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rotate64.vhdl" -- rotate64.vhdl -- 64-Bit Rotate Right -- Copyright (C) 2001 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- $Id$ library IEEE; use IEEE.std_logic_1164.all; entity Rotate64 is port ( A : in std_ulogic_vector(63 downto 0); B : in std_ulogic_vector(5 downto 0); -- Y : out std_ulogic_vector(63 downto 0) ); end Rotate64; architecture Behave_1 of Rotate64 is function decode_3_8 (A : in std_ulogic_vector(2 downto 0)) return std_ulogic_vector is variable yy : std_ulogic_vector(7 downto 0); begin yy := ( 7 => A(2) and A(1) and A(0), 6 => A(2) and A(1) and not A(0), 5 => A(2) and not A(1) and A(0), 4 => A(2) and not A(1) and not A(0), 3 => not A(2) and A(1) and A(0), 2 => not A(2) and A(1) and not A(0), 1 => not A(2) and not A(1) and A(0), 0 => not A(2) and not A(1) and not A(0), others => 'X' ); return yy; end decode_3_8; function rotr64 (A : in std_ulogic_vector(63 downto 0); B : in std_ulogic_vector(5 downto 0)) return std_ulogic_vector is variable sel1 : std_ulogic_vector(7 downto 0); variable sel8 : std_ulogic_vector(7 downto 0); variable yy : std_ulogic_vector(63 downto 0); variable t : std_ulogic; variable k : natural; begin sel1 := decode_3_8(B(2 downto 0)); sel8 := decode_3_8(B(5 downto 3)); for i in yy'range loop t := '0'; for j in A'range loop k := (64 - i + j) rem 64; t := t or (A(j) and sel1(k rem 8) and sel8(k / 8)); end loop; yy(i) := t; end loop; return yy; end rotr64; begin Y <= rotr64(A, B); end Behave_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --J/dobhs11T7y2rNN-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Sep 28 06:10:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n48n-0005C8-00 for ; Fri, 28 Sep 2001 22:21:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 28 Sep 2001 22:21:45 +0200 (CEST) Received: (qmail 9792 invoked by uid 0); 28 Sep 2001 19:57:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 28 Sep 2001 19:57:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SJvPY06435 for ; Fri, 28 Sep 2001 15:57:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 19:56:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SJuxT06184 for f-cpu-list; Fri, 28 Sep 2001 15:56:59 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SJuwC06181 for ; Fri, 28 Sep 2001 15:56:58 -0400 Received: by moria.seul.org (Postfix) id AFE43146765; Fri, 28 Sep 2001 15:57:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id D0328146764 for ; Fri, 28 Sep 2001 15:57:13 -0400 (EDT) Received: from jetnet.ab.ca (dialin35.jetnet.ab.ca [207.153.6.35]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA09656 for ; Fri, 28 Sep 2001 13:56:55 -0600 (MDT) Message-ID: <3BB3F838.AEB99F0C@jetnet.ab.ca> Date: Thu, 27 Sep 2001 22:10:32 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> <20010928170837.30463@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > I'm afraid we're hitting the `6 gates' rule with the bit shuffling > unit, no matter how we implement it. Maybe we should add a second > stage to the `bitwise' pipeline (shift/rot/bitrev operations). Lets get the whole thing working, then aim for speed. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 28 22:45:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y0-0007KS-00 for ; Sat, 29 Sep 2001 02:00:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:00 +0200 (CEST) Received: (qmail 10212 invoked by uid 0); 28 Sep 2001 20:46:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 28 Sep 2001 20:46:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SKkp511499 for ; Fri, 28 Sep 2001 16:46:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 20:45:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SKjRd10545 for f-cpu-list; Fri, 28 Sep 2001 16:45:27 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SKjKC10522 for ; Fri, 28 Sep 2001 16:45:20 -0400 Received: by moria.seul.org (Postfix) id 5FB80146766; Fri, 28 Sep 2001 16:45:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 45889146765 for ; Fri, 28 Sep 2001 16:45:36 -0400 (EDT) Received: from f-cpu.org (nas25-67.kdl.club-internet.fr [213.44.96.67]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 2E5C716D3 for ; Fri, 28 Sep 2001 22:45:16 +0200 (CEST) Message-ID: <3BB4E17E.4957AAD2@f-cpu.org> Date: Fri, 28 Sep 2001 22:45:50 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> <20010928170837.30463@thrai.stud.uni-hannover.de> <3BB3F838.AEB99F0C@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk wrote: > Michael Riepe wrote: > > I'm afraid we're hitting the `6 gates' rule with the bit shuffling > > unit, no matter how we implement it. Maybe we should add a second > > stage to the `bitwise' pipeline (shift/rot/bitrev operations). > Lets get the whole thing working, then aim for speed. sure, but if we can get it "right" sooner, we will be able to have the whole circuit working faster sooner. And frankly i don't expect it to work before _at_least_ one year. I will be extremely busy until this summer. > Ben. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : whygee@linuxdude.com asks how to remove kapm-idled... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 28 22:45:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y1-0007KS-00 for ; Sat, 29 Sep 2001 02:00:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:01 +0200 (CEST) Received: (qmail 20111 invoked by uid 0); 28 Sep 2001 20:46:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 28 Sep 2001 20:46:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SKkwZ11566 for ; Fri, 28 Sep 2001 16:46:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 20:45:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SKjWf10564 for f-cpu-list; Fri, 28 Sep 2001 16:45:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SKjNC10532 for ; Fri, 28 Sep 2001 16:45:23 -0400 Received: by moria.seul.org (Postfix) id 65AFD146766; Fri, 28 Sep 2001 16:45:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 3AA15146765 for ; Fri, 28 Sep 2001 16:45:39 -0400 (EDT) Received: from f-cpu.org (nas25-67.kdl.club-internet.fr [213.44.96.67]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 62F3D173B for ; Fri, 28 Sep 2001 22:45:17 +0200 (CEST) Message-ID: <3BB4E181.D70AF6B6@f-cpu.org> Date: Fri, 28 Sep 2001 22:45:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Bootstrapping (was Re: [f-cpu] Flying Analog Elephants) References: <3BB38A08.2D6E30A4@f-cpu.org> <3BB44300.97F72B54@IPricot.com> <01092812010600.02051@jtd> <3BB47A92.B70A8CC6@IPricot.com> <3BB3D97E.5AA83FC4@jetnet.ab.ca> <3BB48C48.283EED70@IPricot.com> <3BB3E4E5.B6DCB953@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! i apologize for having triggered an analog audio frenzy, but fortunately, Ben saves the day :-) Ben Franchuk wrote: > Nicolas Matringe wrote: > > Ben Franchuk a écrit : > PS. Bootstrapping the F-CPU. Are there any ideas to help with > hardware bootstrapping the F-cpu? i am thinking about an internal ROM that contains instructions for autotesting the CPU (BIST) and then fetch the external instructions (bootstrap). It could be customized to detect the SDRAM interface and initialize it (for example). However, there must be a facility that switches the ROM addressing off, so it won't conflit with normal operation. This MUST remain invisible to the user, otherwise it will become a horrible mess. > Ben WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Sep 28 22:45:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y1-0007KS-01 for ; Sat, 29 Sep 2001 02:00:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:01 +0200 (CEST) Received: (qmail 20128 invoked by uid 0); 28 Sep 2001 20:47:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 28 Sep 2001 20:47:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SKkxg11576 for ; Fri, 28 Sep 2001 16:46:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 20:45:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SKjYf10574 for f-cpu-list; Fri, 28 Sep 2001 16:45:34 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SKjPC10540 for ; Fri, 28 Sep 2001 16:45:25 -0400 Received: by moria.seul.org (Postfix) id 822E2146766; Fri, 28 Sep 2001 16:45:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 656DF146765 for ; Fri, 28 Sep 2001 16:45:41 -0400 (EDT) Received: from f-cpu.org (nas25-67.kdl.club-internet.fr [213.44.96.67]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 9230F16AC for ; Fri, 28 Sep 2001 22:45:22 +0200 (CEST) Message-ID: <3BB4E184.E9DB25A1@f-cpu.org> Date: Fri, 28 Sep 2001 22:45:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> <20010928170837.30463@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Fri, Sep 28, 2001 at 12:46:03PM +0300, Kim Enkovaara wrote: > [...] > > I hate to dissapoint you, but this new version is slower. It got 56MHz in > > the synthesis run for the same chip. I'll try to run the whole Xilinx flow > > to the different versions at some point. But the synthesis results usually > > correlate quite well to the actual results. Especially if some > > floorplanning is done. > > Hmm... maybe I should try something different. Can you please synthesize > the attached file? It's a self-contained 64-bit 'rotate right' entity > with explicit and/or gates which may become the new Shuffle64 core -- > if it's fast enough. > > I'm afraid we're hitting the `6 gates' rule with the bit shuffling > unit, no matter how we implement it. Maybe we should add a second > stage to the `bitwise' pipeline (shift/rot/bitrev operations). it's clear that if it's not fast enough, pipelining is necessary. We'll keep the other strategies in stock, so the user can decide which version to use, if it synthesises better with its target implementation. However, good sense says that most often used operations must be faster : ROL, ROR, SHR, SLR and SHL are the most critical operations. It is not "critical" if SDUP takes two cycles instead of one. > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Sep 29 01:34:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y2-0007KS-00 for ; Sat, 29 Sep 2001 02:00:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:02 +0200 (CEST) Received: (qmail 30860 invoked by uid 0); 28 Sep 2001 20:47:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx02) with SMTP; 28 Sep 2001 20:47:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SKl4q11614 for ; Fri, 28 Sep 2001 16:47:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 20:45:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SKjpx10713 for f-cpu-list; Fri, 28 Sep 2001 16:45:51 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SKjfC10649 for ; Fri, 28 Sep 2001 16:45:41 -0400 Received: by moria.seul.org (Postfix) id CAE0E146766; Fri, 28 Sep 2001 16:45:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas7-182.vlt.club-internet.fr [194.158.109.182]) by moria.seul.org (Postfix) with ESMTP id 02D40146765 for ; Fri, 28 Sep 2001 16:45:57 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8B6661734 for ; Fri, 28 Sep 2001 19:34:37 -0400 (EDT) Message-ID: <3BB5090D.26512947@ifrance.com> Date: Fri, 28 Sep 2001 19:34:37 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <3BB45F0E.79F8A58C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > Kim Enkovaara wrote: > > On Thu, 27 Sep 2001, Michael Riepe wrote: > > > Wondering whether it's faster now, > > > > I hate to dissapoint you, but this new version is slower. It got 56MHz in > > the synthesis run for the same chip. I'll try to run the whole Xilinx flow > > to the different versions at some point. But the synthesis results usually > > correlate quite well to the actual results. Especially if some > > floorplanning is done. > so what is the cure, doctor ? > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity use very high level optimising schem (it doesn't try to simplify at the gate level but at the structure level, that's why it's faster and more performant than the other fpga compiler). Our [michael;p] SIMD 64 bits mul should be quicker with basic 8 bits bloc. But this could be only true with fpga. nicO > > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 29 00:35:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y3-0007KS-01 for ; Sat, 29 Sep 2001 02:00:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:03 +0200 (CEST) Received: (qmail 368 invoked by uid 0); 28 Sep 2001 22:35:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 28 Sep 2001 22:35:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SMZdu13428 for ; Fri, 28 Sep 2001 18:35:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 22:35:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SMZG113173 for f-cpu-list; Fri, 28 Sep 2001 18:35:16 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SMZEC13168 for ; Fri, 28 Sep 2001 18:35:14 -0400 Received: by moria.seul.org (Postfix) id B9818146767; Fri, 28 Sep 2001 18:35:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 9F737146766 for ; Fri, 28 Sep 2001 18:35:30 -0400 (EDT) Received: from f-cpu.org (nas15-26.kdl.club-internet.fr [213.44.9.26]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 45D9916C0 for ; Sat, 29 Sep 2001 00:35:02 +0200 (CEST) Message-ID: <3BB4FB2F.56C52614@f-cpu.org> Date: Sat, 29 Sep 2001 00:35:27 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <3BB45F0E.79F8A58C@f-cpu.org> <3BB5090D.26512947@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > Yann Guidon a écrit : > > hi, > > Kim Enkovaara wrote: > > > On Thu, 27 Sep 2001, Michael Riepe wrote: > > > > Wondering whether it's faster now, > > > I hate to dissapoint you, but this new version is slower. It got 56MHz in > > > the synthesis run for the same chip. I'll try to run the whole Xilinx flow > > > to the different versions at some point. But the synthesis results usually > > > correlate quite well to the actual results. Especially if some > > > floorplanning is done. > > so what is the cure, doctor ? > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity > use very high level optimising schem (it doesn't try to simplify at the > gate level but at the structure level, that's why it's faster and more > performant than the other fpga compiler). Our [michael;p] SIMD 64 bits > mul should be quicker with basic 8 bits bloc. But this could be only > true with fpga. probably. But ... what about the shifter ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: i don't want to start another off-topic thread but i can't resist to say that i have also acquired a SCSI recording rack (Yamaha CBX-D3) for 150FF :-) but Surcouf (the store where i got it) made me pay the necessary accessories for a very high price :-( (SCSI cables, AC adapter,...) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 29 01:02:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y4-0007KS-00 for ; Sat, 29 Sep 2001 02:00:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:04 +0200 (CEST) Received: (qmail 12636 invoked by uid 0); 28 Sep 2001 23:03:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx21) with SMTP; 28 Sep 2001 23:03:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SN3SP14041 for ; Fri, 28 Sep 2001 19:03:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 23:03:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SN30Z13794 for f-cpu-list; Fri, 28 Sep 2001 19:03:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SN2xC13789 for ; Fri, 28 Sep 2001 19:02:59 -0400 Received: by moria.seul.org (Postfix) id 7CCBF146767; Fri, 28 Sep 2001 19:03:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id 58055146766 for ; Fri, 28 Sep 2001 19:03:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA04763; Sat, 29 Sep 2001 01:02:51 +0200 Message-ID: <20010929010251.54444@thrai.stud.uni-hannover.de> Date: Sat, 29 Sep 2001 01:02:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <20010927161632.14448@thrai.stud.uni-hannover.de> <20010928170837.30463@thrai.stud.uni-hannover.de> <3BB4E184.E9DB25A1@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB4E184.E9DB25A1@f-cpu.org>; from Yann Guidon on Fri, Sep 28, 2001 at 10:45:56PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Sep 28, 2001 at 10:45:56PM +0200, Yann Guidon wrote: [...] > > I'm afraid we're hitting the `6 gates' rule with the bit shuffling > > unit, no matter how we implement it. Maybe we should add a second > > stage to the `bitwise' pipeline (shift/rot/bitrev operations). > > it's clear that if it's not fast enough, pipelining is necessary. > We'll keep the other strategies in stock, so the user can decide > which version to use, if it synthesises better with its target > implementation. Yep. > However, good sense says that most often used operations must be faster : > ROL, ROR, SHR, SLR and SHL are the most critical operations. > It is not "critical" if SDUP takes two cycles instead of one. Unfortunately, sdup/byterev/mix/expand are so easy to implement that they only need one cycle, while the bitwise operations are harder :( A 6-to-64 decoder alone (for the shift count) needs 50% of a 6-gate F-CPU pipeline stage... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 29 01:06:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y4-0007KS-01 for ; Sat, 29 Sep 2001 02:00:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:04 +0200 (CEST) Received: (qmail 3895 invoked by uid 0); 28 Sep 2001 23:06:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Sep 2001 23:06:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SN6nU14350 for ; Fri, 28 Sep 2001 19:06:49 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 23:06:30 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SN6UJ14103 for f-cpu-list; Fri, 28 Sep 2001 19:06:30 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SN6TC14100 for ; Fri, 28 Sep 2001 19:06:29 -0400 Received: by moria.seul.org (Postfix) id 39425146767; Fri, 28 Sep 2001 19:06:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id 3E2B1146766 for ; Fri, 28 Sep 2001 19:06:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA04780; Sat, 29 Sep 2001 01:06:31 +0200 Message-ID: <20010929010631.31148@thrai.stud.uni-hannover.de> Date: Sat, 29 Sep 2001 01:06:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <3BB45F0E.79F8A58C@f-cpu.org> <3BB5090D.26512947@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BB5090D.26512947@ifrance.com>; from nicO on Fri, Sep 28, 2001 at 07:34:37PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Sep 28, 2001 at 07:34:37PM -0400, nicO wrote: [...] > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity > use very high level optimising schem (it doesn't try to simplify at the > gate level but at the structure level, that's why it's faster and more > performant than the other fpga compiler). Our [michael;p] SIMD 64 bits > mul should be quicker with basic 8 bits bloc. But this could be only > true with fpga. The multiplier was fast enough -- more than 100 MHz (in an FPGA) -- and an 8x8 architecture would need more stages (my first version hat 8x8 building blocks, and 9 or 10 stages, while the current one has only 6). I don't worry about that, but the shifter gives me headaches. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 29 01:12:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n7Y5-0007KS-00 for ; Sat, 29 Sep 2001 02:00:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 02:00:05 +0200 (CEST) Received: (qmail 17412 invoked by uid 0); 28 Sep 2001 23:12:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 28 Sep 2001 23:12:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SNCHE14702 for ; Fri, 28 Sep 2001 19:12:17 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 23:11:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SNBvC14453 for f-cpu-list; Fri, 28 Sep 2001 19:11:57 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SNBuC14448 for ; Fri, 28 Sep 2001 19:11:56 -0400 Received: by moria.seul.org (Postfix) id 405EE146767; Fri, 28 Sep 2001 19:12:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2533F146766 for ; Fri, 28 Sep 2001 19:12:13 -0400 (EDT) Received: from f-cpu.org (nas15-26.kdl.club-internet.fr [213.44.9.26]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 949C216A3 for ; Sat, 29 Sep 2001 01:11:41 +0200 (CEST) Message-ID: <3BB503C9.C03DB0F3@f-cpu.org> Date: Sat, 29 Sep 2001 01:12:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <3BB45F0E.79F8A58C@f-cpu.org> <3BB5090D.26512947@ifrance.com> <20010929010631.31148@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, Michael Riepe wrote: > On Fri, Sep 28, 2001 at 07:34:37PM -0400, nicO wrote: > [...] > > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity > > use very high level optimising schem (it doesn't try to simplify at the > > gate level but at the structure level, that's why it's faster and more > > performant than the other fpga compiler). Our [michael;p] SIMD 64 bits > > mul should be quicker with basic 8 bits bloc. But this could be only > > true with fpga. > > The multiplier was fast enough -- more than 100 MHz (in an FPGA) -- > and an 8x8 architecture would need more stages (my first version hat 8x8 > building blocks, and 9 or 10 stages, while the current one has only 6). > I don't worry about that, but the shifter gives me headaches. i will let you work in peace with this unit. i will concentrate on the "control/scheduling" side. I trust you to do whatever is necessary, even if sdup must be 2* slower than shl :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sloyment@gmx.net Sat Sep 29 01:58:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15n9QV-00005i-00 for ; Sat, 29 Sep 2001 04:00:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 04:00:23 +0200 (CEST) Received: (qmail 29388 invoked by uid 0); 28 Sep 2001 23:42:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 28 Sep 2001 23:42:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8SNgpn15386 for ; Fri, 28 Sep 2001 19:42:51 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 28 Sep 2001 23:42:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8SNgVZ15138 for f-cpu-list; Fri, 28 Sep 2001 19:42:31 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8SNgUC15135 for ; Fri, 28 Sep 2001 19:42:30 -0400 Received: by moria.seul.org (Postfix) id B807E146767; Fri, 28 Sep 2001 19:42:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by moria.seul.org (Postfix) with SMTP id 5DF79146766 for ; Fri, 28 Sep 2001 19:42:46 -0400 (EDT) Received: (qmail 13115 invoked by uid 0); 28 Sep 2001 23:42:28 -0000 Received: from b90a2.pppool.de (HELO WintelPC) (213.7.144.162) by mail.gmx.net (mp007-rz3) with SMTP; 28 Sep 2001 23:42:28 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Thomas Uwe Gruettmueller To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants Date: Sat, 29 Sep 2001 01:58:00 +0200 X-Mailer: KMail [version 1.2] References: <3BB44300.97F72B54@IPricot.com> <3BB45F10.CA43614C@f-cpu.org> In-Reply-To: <3BB45F10.CA43614C@f-cpu.org> MIME-Version: 1.0 Message-Id: <01092901580007.02589@WintelPC> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! On Friday, 28. September 2001 13:29, Yann Guidon wrote: > There's also a CS5524 but it is limited to 1KHz sampling :-) > And a TI 8-bit 10MHz ADC, too. How can I sample at 15 MHz, and how do I get so much data into my PC? ;o) Bye, Thomas }:o{# ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jtdesouza@yahoo.com Sat Sep 29 03:58:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nF4s-0004b9-01 for ; Sat, 29 Sep 2001 10:02:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 10:02:26 +0200 (CEST) Received: (qmail 20404 invoked by uid 0); 29 Sep 2001 06:17:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 29 Sep 2001 06:17:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8T6H6r20934 for ; Sat, 29 Sep 2001 02:17:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 06:16:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8T6GjT20689 for f-cpu-list; Sat, 29 Sep 2001 02:16:45 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8T6GiC20686 for ; Sat, 29 Sep 2001 02:16:44 -0400 Received: by moria.seul.org (Postfix) id 16D551466A2; Sat, 29 Sep 2001 02:17:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by moria.seul.org (Postfix) with SMTP id 918A214668F for ; Sat, 29 Sep 2001 02:17:00 -0400 (EDT) Received: from unknown (HELO jtd) (202.149.210.92) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Sep 2001 06:16:41 -0000 X-Apparently-From: Content-Type: text/plain; charset="iso-8859-1" From: jtd To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants Date: Sat, 29 Sep 2001 07:28:21 +0530 X-Mailer: KMail [version 1.2] References: <01092812010600.02051@jtd> <3BB47A92.B70A8CC6@IPricot.com> In-Reply-To: <3BB47A92.B70A8CC6@IPricot.com> MIME-Version: 1.0 Message-Id: <01092907282100.06786@jtd> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Friday 28 September 2001 06:56 pm, Nicolas Matringe wrote: > jtd a écrit : > > What sort of schematics. > > Mix table, microphone preamp, pick-up preamp, guitar preamp (I > built it, works fine :o), limiter, compressor/limiter, noise gate, > VU-meter... Unfortunately, they're all paper and I don't have a > scanner. :-(. I am constructing a six channel power amp approx 200 W rms total (my 15 yr old amp finally departed in a cloud of smoke). Also a network audio appliance using 89C58 and ne2000 board to pipe music into four rooms from the pc. -- jtdesouza@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Sat Sep 29 08:18:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nF4t-0004b9-00 for ; Sat, 29 Sep 2001 10:02:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 29 Sep 2001 10:02:27 +0200 (CEST) Received: (qmail 26835 invoked by uid 0); 29 Sep 2001 06:18:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 29 Sep 2001 06:18:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8T6Id821208 for ; Sat, 29 Sep 2001 02:18:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 06:18:21 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8T6ILi20959 for f-cpu-list; Sat, 29 Sep 2001 02:18:21 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8T6IKC20956 for ; Sat, 29 Sep 2001 02:18:20 -0400 Received: by moria.seul.org (Postfix) id 021B91466A2; Sat, 29 Sep 2001 02:18:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 65B6714668F for ; Sat, 29 Sep 2001 02:18:36 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA01810 for ; Sat, 29 Sep 2001 09:18:18 +0300 (EET DST) Date: Sat, 29 Sep 2001 09:18:17 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) In-Reply-To: <3BB5090D.26512947@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 28 Sep 2001, nicO wrote: > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity > use very high level optimising schem (it doesn't try to simplify at the > gate level but at the structure level, that's why it's faster and more Synplify usually likes as high level descriptions as possible. But I think that optimizing for speed at this stage is not wise thing to do. First you need a working chip and testbenches around it. After that it is easy to recode some blocks for ASIC and FPGA for example. Of course it is necessary to check that the blocks are synthesizable and reasonable sized and the speed is reasonable. But targeting for maximal speed comes later. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 29 17:51:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nbH0-0000EX-01 for ; Sun, 30 Sep 2001 09:44:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Sep 2001 09:44:26 +0200 (CEST) Received: (qmail 14472 invoked by uid 0); 29 Sep 2001 15:51:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 29 Sep 2001 15:51:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8TFpk330117 for ; Sat, 29 Sep 2001 11:51:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 15:51:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8TFpAl29655 for f-cpu-list; Sat, 29 Sep 2001 11:51:10 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8TFp5C29626 for ; Sat, 29 Sep 2001 11:51:05 -0400 Received: by moria.seul.org (Postfix) id A5A4D1466EB; Sat, 29 Sep 2001 11:51:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 593001466EE for ; Sat, 29 Sep 2001 11:51:22 -0400 (EDT) Received: from f-cpu.org (nas26-11.kdl.club-internet.fr [213.44.97.11]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5A67A16B9 for ; Sat, 29 Sep 2001 17:51:00 +0200 (CEST) Message-ID: <3BB5EE07.7795C18F@f-cpu.org> Date: Sat, 29 Sep 2001 17:51:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Flying Analog Elephants References: <3BB44300.97F72B54@IPricot.com> <3BB45F10.CA43614C@f-cpu.org> <01092901580007.02589@WintelPC> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Thomas Uwe Gruettmueller wrote: > Hi! > > On Friday, 28. September 2001 13:29, Yann Guidon wrote: > > There's also a CS5524 but it is limited to 1KHz sampling :-) > > And a TI 8-bit 10MHz ADC, too. > How can I sample at 15 MHz, and how do I get so much data into my PC? ;o) There's a 40MHz 8-bit ADC from Ti, i am sure that other (more recent) types have more definition or bandwidth. The good news is that this speed grade requires a parallel interface on the chip (the usual serial interface would require a 320Mbps). The bad news is that you will have to design a specific PCI board if you want to fit into your PC. This includes controller and memory buffer (a large FIFO). If you can't do this, you can find "data acquisition" devices from many manufacturers (the most reknown is National Instruments). It depends on what you have in mind. > Bye, > Thomas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 29 17:51:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nbH1-0000EX-00 for ; Sun, 30 Sep 2001 09:44:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Sep 2001 09:44:27 +0200 (CEST) Received: (qmail 6002 invoked by uid 0); 29 Sep 2001 15:51:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 29 Sep 2001 15:51:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8TFplW30126 for ; Sat, 29 Sep 2001 11:51:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 15:51:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8TFp7929629 for f-cpu-list; Sat, 29 Sep 2001 11:51:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8TFp5C29622 for ; Sat, 29 Sep 2001 11:51:05 -0400 Received: by moria.seul.org (Postfix) id 786171466EF; Sat, 29 Sep 2001 11:51:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 535F51466EB for ; Sat, 29 Sep 2001 11:51:22 -0400 (EDT) Received: from f-cpu.org (nas26-11.kdl.club-internet.fr [213.44.97.11]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 1BC4516AA for ; Sat, 29 Sep 2001 17:51:00 +0200 (CEST) Message-ID: <3BB5EE06.D3EAA1FB@f-cpu.org> Date: Sat, 29 Sep 2001 17:51:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Kim Enkovaara wrote: > On Fri, 28 Sep 2001, nicO wrote: > > > Should i suggest to try to make the mul with mul 8*8 entity ? Synplicity > > use very high level optimising schem (it doesn't try to simplify at the > > gate level but at the structure level, that's why it's faster and more > > Synplify usually likes as high level descriptions as possible. But I think > that optimizing for speed at this stage is not wise thing to do. how do you tell Synplify to pipeline the multiplier ? and how do you instruct it to provide partial results ? > First you need a working chip and testbenches around it. After that it is easy to > recode some blocks for ASIC and FPGA for example. it won't be easy if we did not foresee the necessary requirements. > Of course it is > necessary to check that the blocks are synthesizable and reasonable sized > and the speed is reasonable. But targeting for maximal speed comes later. Today, now that i see that i can code something, i wonder : what is the best way to write stuff so it runs as fast as possible. I know that if i start to write VHDL "the usual way", the result might be disapointing. If a large part of the CPU is designed this way, it won't hold its promise. People will work on underefficient designs and it will be too late. This is particularly worrying in the control path (scheduler). I trust Michael for the rest. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Sat Sep 29 18:37:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nbH6-0000EX-00 for ; Sun, 30 Sep 2001 09:44:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Sep 2001 09:44:32 +0200 (CEST) Received: (qmail 3391 invoked by uid 0); 29 Sep 2001 16:37:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 29 Sep 2001 16:37:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8TGbWQ30860 for ; Sat, 29 Sep 2001 12:37:32 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 16:37:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8TGbBu30611 for f-cpu-list; Sat, 29 Sep 2001 12:37:11 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8TGbAC30608 for ; Sat, 29 Sep 2001 12:37:10 -0400 Received: by moria.seul.org (Postfix) id EA0031466EE; Sat, 29 Sep 2001 12:37:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 503C21466EB for ; Sat, 29 Sep 2001 12:37:27 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id TAA11024 for ; Sat, 29 Sep 2001 19:37:09 +0300 (EET DST) Date: Sat, 29 Sep 2001 19:37:08 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) In-Reply-To: <3BB5EE06.D3EAA1FB@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 29 Sep 2001, Yann Guidon wrote: > > Synplify usually likes as high level descriptions as possible. But I think > > that optimizing for speed at this stage is not wise thing to do. > how do you tell Synplify to pipeline the multiplier ? and how do you instruct it > to provide partial results ? Easiest way to do that is to write a*b in the VHDL and add as many fliflops after the operation as you need pipeline stages. Then just ask the Synplify to balance the registers. In that way it creates very well optimized pipelined multiplier. Also if the FPGA architecture includes HW multipliers it uses them during the synthesis. In VirtexII architecture synplify can't use the internal flipflops of the 18x18 multiplier, but those flipflops are not documented or characterized at the monent, but they are there. > > First you need a working chip and testbenches around it. After that it is easy to > > recode some blocks for ASIC and FPGA for example. > it won't be easy if we did not foresee the necessary requirements. Good rule of the thumb is that best ASIC processes are 10 times faster than the fastest FPGAs for normal logic. For example one vendor promises about 30 levels of logic at 600MHz with 0.13u process. And the fastest FPGAs are quite expensive, you can buy a small car with few of them :) > Today, now that i see that i can code something, i wonder : what is the best > way to write stuff so it runs as fast as possible. I know that if i start to > write VHDL "the usual way", the result might be disapointing. If a large part > of the CPU is designed this way, it won't hold its promise. People will work > on underefficient designs and it will be too late. This is particularly > worrying in the control path (scheduler). I trust Michael for the rest. I think the only way to see the results is to synthesize the results yourself and analyze the results from the shematics. It is very difficult to analyze the results if the code is not written by yourself. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 29 22:22:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nbHJ-0000EX-00 for ; Sun, 30 Sep 2001 09:44:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Sep 2001 09:44:45 +0200 (CEST) Received: (qmail 17216 invoked by uid 0); 29 Sep 2001 20:22:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 29 Sep 2001 20:22:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8TKM5102293 for ; Sat, 29 Sep 2001 16:22:05 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 20:21:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8TKLcC02044 for f-cpu-list; Sat, 29 Sep 2001 16:21:38 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8TKLbC02041 for ; Sat, 29 Sep 2001 16:21:37 -0400 Received: by moria.seul.org (Postfix) id 3E4A61462FB; Sat, 29 Sep 2001 16:21:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 215A91462FA for ; Sat, 29 Sep 2001 16:21:54 -0400 (EDT) Received: from f-cpu.org (nas5-41.kdl.club-internet.fr [213.44.0.41]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8C27316AA for ; Sat, 29 Sep 2001 22:21:33 +0200 (CEST) Message-ID: <3BB62D73.6F0466FA@f-cpu.org> Date: Sat, 29 Sep 2001 22:22:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Kim Enkovaara wrote: > On Sat, 29 Sep 2001, Yann Guidon wrote: > > > Synplify usually likes as high level descriptions as possible. But I think > > > that optimizing for speed at this stage is not wise thing to do. > > how do you tell Synplify to pipeline the multiplier ? and how do you instruct it > > to provide partial results ? > > Easiest way to do that is to write a*b in the VHDL and add as many > fliflops after the operation as you need pipeline stages. Then just ask > the Synplify to balance the registers. In that way it creates very well > optimized pipelined multiplier. Also if the FPGA architecture includes HW > multipliers it uses them during the synthesis. In VirtexII architecture > synplify can't use the internal flipflops of the 18x18 multiplier, but > those flipflops are not documented or characterized at the monent, but > they are there. coool ! i didn't know this trick :-) So we can try to "fit" the multiplier depth according to the clock speed and vice versa, simply by "tuning" one constant in the source ? i like that :-) > > > First you need a working chip and testbenches around it. After that it is easy to > > > recode some blocks for ASIC and FPGA for example. > > it won't be easy if we did not foresee the necessary requirements. > Good rule of the thumb is that best ASIC processes are 10 times faster > than the fastest FPGAs for normal logic. For example one vendor promises > about 30 levels of logic at 600MHz with 0.13u process. And the fastest > FPGAs are quite expensive, you can buy a small car with few of them :) i know. However F-CPU is "superpipelined" so the ratio is reduced a bit. The goal is more to "use whatever ressource we have" rather than competing at the high level (we would never win). > > Today, now that i see that i can code something, i wonder : what is the best > > way to write stuff so it runs as fast as possible. I know that if i start to > > write VHDL "the usual way", the result might be disapointing. If a large part > > of the CPU is designed this way, it won't hold its promise. People will work > > on underefficient designs and it will be too late. This is particularly > > worrying in the control path (scheduler). I trust Michael for the rest. > I think the only way to see the results is to synthesize the results > yourself and analyze the results from the shematics. It is very difficult > to analyze the results if the code is not written by yourself. I almost got the Cadence soft. In fact it still doesn't work, i have to configure the Linux kernel... But it's only a matter of time ! Now i am pretty sure that i will be doing F-CPU as doctorate project. This year is going to be VERY difficult but in the end the horizon is bright. I will be concentrating on synthesis this year so most tools will be ready next year. good night, > Mr. Kim Enkovaara WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: who knows how to disable the kapm-idled deamon from Linux ? it's eating up CPU power and heats the CPU of the laptop :-/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Sep 29 22:13:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15nbHL-0000EX-00 for ; Sun, 30 Sep 2001 09:44:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Sep 2001 09:44:47 +0200 (CEST) Received: (qmail 4848 invoked by uid 0); 29 Sep 2001 22:46:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx11) with SMTP; 29 Sep 2001 22:46:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f8TMk3X04149 for ; Sat, 29 Sep 2001 18:46:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 29 Sep 2001 22:44:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f8TMiET03887 for f-cpu-list; Sat, 29 Sep 2001 18:44:14 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f8TMiDC03884 for ; Sat, 29 Sep 2001 18:44:13 -0400 Received: by moria.seul.org (Postfix) id 6A2671462FA; Sat, 29 Sep 2001 18:44:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id B61481462F9 for ; Sat, 29 Sep 2001 18:44:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA02102; Sat, 29 Sep 2001 22:13:31 +0200 Message-ID: <20010929221331.01583@thrai.stud.uni-hannover.de> Date: Sat, 29 Sep 2001 22:13:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Bit Shuffler (Take 2) References: <3BB5EE06.D3EAA1FB@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Sat, Sep 29, 2001 at 07:37:08PM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 29, 2001 at 07:37:08PM +0300, Kim Enkovaara wrote: > On Sat, 29 Sep 2001, Yann Guidon wrote: > > > > Synplify usually likes as high level descriptions as possible. But I think > > > that optimizing for speed at this stage is not wise thing to do. > > how do you tell Synplify to pipeline the multiplier ? and how do you instruct it > > to provide partial results ? > > Easiest way to do that is to write a*b in the VHDL and add as many > fliflops after the operation as you need pipeline stages. Then just ask > the Synplify to balance the registers. In that way it creates very well > optimized pipelined multiplier. Also if the FPGA architecture includes HW > multipliers it uses them during the synthesis. In VirtexII architecture > synplify can't use the internal flipflops of the 18x18 multiplier, but > those flipflops are not documented or characterized at the monent, but > they are there. You may be able to get a 64-bit multiplier by writing `Y <= A * B' and letting the synthesis tool do the rest, but how do you handle signed/unsigned multiplication, SIMD chunks and so on? I doubt that there is any synthesizer out there who can do that automatically. [...] > I think the only way to see the results is to synthesize the results > yourself and analyze the results from the shematics. It is very difficult > to analyze the results if the code is not written by yourself. At least, you need a basic idea how it works (or how it's supposed to work). We can't optimize the F-CPU for every possible target -- we neither have the time nor the synthesis tools. We can only choose some `generic' targets, like a random FPGA with 4-input LUTs, write code that is suitable for them (although not necessarily optimal), and leave the target-dependent optimization to the implementor. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 2 02:16:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15oKaq-0000Ej-00 for ; Tue, 02 Oct 2001 10:07:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 02 Oct 2001 10:07:56 +0200 (CEST) Received: (qmail 28994 invoked by uid 0); 1 Oct 2001 23:16:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 1 Oct 2001 23:16:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f91NGJc17256 for ; Mon, 1 Oct 2001 19:16:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 1 Oct 2001 23:15:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f91NFak17004 for f-cpu-list; Mon, 1 Oct 2001 19:15:36 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f91NFZC17000 for ; Mon, 1 Oct 2001 19:15:35 -0400 Received: by moria.seul.org (Postfix) id 4E9471462F8; Mon, 1 Oct 2001 19:15:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 17B5B1462F7 for ; Mon, 1 Oct 2001 19:15:54 -0400 (EDT) Received: from f-cpu.org (nas5-48.kdl.club-internet.fr [213.44.0.48]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D9653168E for ; Tue, 2 Oct 2001 01:15:25 +0200 (CEST) Message-ID: <3BB90742.A08E8E27@f-cpu.org> Date: Tue, 02 Oct 2001 01:16:02 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] About Alliance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i got my first lessons about the alliance toolsuite developped at Jussieu/paris. It is certainly not going to be used for the early stages of F-CPU, at least not before synthesis : from what i have seen, ASIMUT uses a deviant form of VHDL that is not portable nor usable otherwise. In this month of October, i will learn all the basics about this toolsuite. It is probable that we use some parts of the toolsuite but at the cost of developping "translators" for varying file formats. I also met people who have heard about F-CPU :-) Stay tuned, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Oct 6 00:51:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ptCD-000074-01 for ; Sat, 06 Oct 2001 17:16:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Oct 2001 17:16:57 +0200 (CEST) Received: (qmail 14775 invoked by uid 0); 5 Oct 2001 21:51:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 5 Oct 2001 21:51:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f95LpaX10653 for ; Fri, 5 Oct 2001 17:51:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 5 Oct 2001 21:51:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f95Lp5W10403 for f-cpu-list; Fri, 5 Oct 2001 17:51:05 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f95Lp4C10400 for ; Fri, 5 Oct 2001 17:51:04 -0400 Received: by moria.seul.org (Postfix) id 3E3A71462F8; Fri, 5 Oct 2001 17:51:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 08C3B1462F6 for ; Fri, 5 Oct 2001 17:51:05 -0400 (EDT) Received: from f-cpu.org (nas20-42.kdl.club-internet.fr [213.44.18.42]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9E53B168D for ; Fri, 5 Oct 2001 23:50:58 +0200 (CEST) Message-ID: <3BBE3977.284C35D6@f-cpu.org> Date: Fri, 05 Oct 2001 23:51:35 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] "make menuconfig" for f-cpu sources Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, does anyone of you know how to reuse Linux's interactive config file generators ? it would be cool to put that in front of the existing m4 makefiles that already exist. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Oct 6 00:59:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ptCG-000074-00 for ; Sat, 06 Oct 2001 17:17:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Oct 2001 17:17:00 +0200 (CEST) Received: (qmail 12793 invoked by uid 0); 5 Oct 2001 23:05:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Oct 2001 23:05:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f95N5G613293 for ; Fri, 5 Oct 2001 19:05:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 5 Oct 2001 23:04:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f95N4qq13038 for f-cpu-list; Fri, 5 Oct 2001 19:04:52 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f95N4pC13035 for ; Fri, 5 Oct 2001 19:04:51 -0400 Received: by moria.seul.org (Postfix) id 245511462F8; Fri, 5 Oct 2001 19:04:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a192.home.uni-hannover.de [130.75.232.192]) by moria.seul.org (Postfix) with ESMTP id 558471462F6 for ; Fri, 5 Oct 2001 19:04:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA16459; Sat, 6 Oct 2001 00:59:39 +0200 Message-ID: <20011006005938.20697@thrai.stud.uni-hannover.de> Date: Sat, 6 Oct 2001 00:59:38 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "make menuconfig" for f-cpu sources References: <3BBE3977.284C35D6@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BBE3977.284C35D6@f-cpu.org>; from Yann Guidon on Fri, Oct 05, 2001 at 11:51:35PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Oct 05, 2001 at 11:51:35PM +0100, Yann Guidon wrote: > does anyone of you know how to reuse Linux's > interactive config file generators ? it would be cool > to put that in front of the existing m4 makefiles > that already exist. On the software side (compiler, tools and so on) I want to be able to just run `./configure; make; make install' -- people are already familiar with that. The VHDL part of the project is another beast, and we probably have to handle it differently. But I guess a menu driven configuration utility isn't useful (nor is it portable -- remember that we may have to do simulation and synthesis on non-Unix systems). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 7 03:13:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHij-0000pw-00 for ; Sun, 07 Oct 2001 19:28:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:09 +0200 (CEST) Received: (qmail 5977 invoked by uid 0); 7 Oct 2001 00:14:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 7 Oct 2001 00:14:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f970E7N08540 for ; Sat, 6 Oct 2001 20:14:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 00:13:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f970DMI08286 for f-cpu-list; Sat, 6 Oct 2001 20:13:22 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f970DKC08283 for ; Sat, 6 Oct 2001 20:13:20 -0400 Received: by moria.seul.org (Postfix) id 17F32146672; Sat, 6 Oct 2001 20:13:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D16C0146671 for ; Sat, 6 Oct 2001 20:13:21 -0400 (EDT) Received: from f-cpu.org (nas25-36.kdl.club-internet.fr [213.44.96.36]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 53248170C for ; Sun, 7 Oct 2001 02:13:15 +0200 (CEST) Message-ID: <3BBFAC53.B9025BE7@f-cpu.org> Date: Sun, 07 Oct 2001 02:13:55 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] 'make it work' or 'make it fast' ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, since i am studying at ASIME, i have learnt some basics about using the "homemade" Alliance toolchain. I can make several reproaches about it : it is "a bit heavy", does not comply to the VHDL standard coding practices, but i begin to realize that it is not really a VHDL tool : in fact it is more a synthesis tool. It has the advantage that you can design masks relatively easily and quickly. However, from what i can see, the use of their precharacterised library is not the best way to make a "fast" CPU, if you consider that if you want to make custom ASIC, you want to get all the power you expect from this. On one side, you reduce the pressure on the post-synthesis tools (timing/parasitics/etc) but on the other side, you can get almost the same speed (and probably more) with the latest FPGAs (who support the most recent synthesis algorithms with fully VHDL compliant sources). This is because, from what i have seen, their strategy is underefficient, particularly with P&R and post-layout compression (there's often wasted surface). This is maybe my PCB designer's eyes that tell me that. But i can't deny that having a working F-CPU sooner is attracting. So there's the old dilemma : do we sacrifice source portability, clock speed and high-level synthesis ? Or do we accept to go the route of early prototypes ? It would be cool if Alliance accepted VHDL'93 sources, or even FOR .. GENERATE loops !!! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Oct 7 04:37:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHij-0000pw-01 for ; Sun, 07 Oct 2001 19:28:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:09 +0200 (CEST) Received: (qmail 7499 invoked by uid 0); 7 Oct 2001 01:49:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 7 Oct 2001 01:49:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f971n0S11723 for ; Sat, 6 Oct 2001 21:49:00 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 01:48:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f971mS411465 for f-cpu-list; Sat, 6 Oct 2001 21:48:28 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f971mQC11462 for ; Sat, 6 Oct 2001 21:48:26 -0400 Received: by moria.seul.org (Postfix) id 597A8146672; Sat, 6 Oct 2001 21:48:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id 2EACE146671 for ; Sat, 6 Oct 2001 21:48:27 -0400 (EDT) Received: from jetnet.ab.ca (dialin33.jetnet.ab.ca [207.153.6.33]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA26949 for ; Sat, 6 Oct 2001 19:48:21 -0600 (MDT) Message-ID: <3BBFC004.E4982A3B@jetnet.ab.ca> Date: Sat, 06 Oct 2001 20:37:56 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > hi, > > since i am studying at ASIME, i have learnt some > basics about using the "homemade" Alliance toolchain. > > I can make several reproaches about it : it is "a bit heavy", > does not comply to the VHDL standard coding practices, > but i begin to realize that it is not really a VHDL tool : > in fact it is more a synthesis tool. It has the advantage > that you can design masks relatively easily and quickly. Has it been upgraded lately - the libraries may be outdated? I only problem with the tools I can think of is the fact that the timing calculation program is not free. Sure we can route the chip but we can't tell you what the delays are. :( > > However, from what i can see, the use of their precharacterised > library is not the best way to make a "fast" CPU, if you consider > that if you want to make custom ASIC, you want to get all > the power you expect from this. On one side, you reduce the > pressure on the post-synthesis tools (timing/parasitics/etc) > but on the other side, you can get almost the same speed > (and probably more) with the latest FPGAs (who support the > most recent synthesis algorithms with fully VHDL compliant sources). > This is because, from what i have seen, their strategy is > underefficient, particularly with P&R and post-layout compression > (there's often wasted surface). This is maybe my PCB designer's eyes > that tell me that. The only real way is design the cpu by hand to get the best use of space. Alliance looks to one of the better ( not that I have used many tools ) for routing. With the modern chips routing I guess is half the space used in a die. > But i can't deny that having a working F-CPU sooner is attracting. > So there's the old dilemma : do we sacrifice source portability, > clock speed and high-level synthesis ? Or do we accept to go the > route of early prototypes ? > It would be cool if Alliance accepted VHDL'93 sources, or even > FOR .. GENERATE loops !!! Nothing is portable -- schematics are often too low level. HDL's are too abstract to map well to hardware.FPGA's all have different logic cell functionality. I would personally go with schematics if there was a portable way of creating them. >From what little I have been playing with FPGA's is that they tend to routing bound rather than gate bound. About 25%-33% of a fpga needs to be free so you can route and place your design. If we get a FPGA working then hopefully one can use a FPGA to ASIC program to get prototypes, until one has the resources to do the whole ASIC BY HAND. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 7 05:59:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHil-0000pw-00 for ; Sun, 07 Oct 2001 19:28:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:11 +0200 (CEST) Received: (qmail 22911 invoked by uid 0); 7 Oct 2001 02:59:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx13) with SMTP; 7 Oct 2001 02:59:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f972xiH12957 for ; Sat, 6 Oct 2001 22:59:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 02:59:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f972xJT12705 for f-cpu-list; Sat, 6 Oct 2001 22:59:19 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f972xHC12702 for ; Sat, 6 Oct 2001 22:59:17 -0400 Received: by moria.seul.org (Postfix) id A28841462F8; Sat, 6 Oct 2001 22:59:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 87C5F1462F6 for ; Sat, 6 Oct 2001 22:59:19 -0400 (EDT) Received: from f-cpu.org (nas20-8.kdl.club-internet.fr [213.44.18.8]) by relay-3v.club-internet.fr (Postfix) with ESMTP id CFB9D168B for ; Sun, 7 Oct 2001 04:59:15 +0200 (CEST) Message-ID: <3BBFD33B.F21A20B3@f-cpu.org> Date: Sun, 07 Oct 2001 04:59:55 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] VHDL HOWTO for the F-CPU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i have uploaded a slightly updated version of the HOWTO i wrote about the tools and the VHDL code. http://f-cpu.seul.org/new/VHDL-HOWTO.f-cpu Because i might be extremely busy on non-F-CPU stuff (at least, not directly), it would be cool to include it in the GAOS CVS tree. I think that i will also commit the rest of my local files because my silence could last up to one year : i don't want to keep others from working on F-CPU sources. my latest snapshot (without the updated HOWTO) is also available from seul.org. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 7 02:29:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHit-0000pw-01 for ; Sun, 07 Oct 2001 19:28:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:19 +0200 (CEST) Received: (qmail 22457 invoked by uid 0); 7 Oct 2001 12:08:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx04) with SMTP; 7 Oct 2001 12:08:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97C8To21655 for ; Sun, 7 Oct 2001 08:08:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 12:07:46 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97C7kK21401 for f-cpu-list; Sun, 7 Oct 2001 08:07:46 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97C7jC21398 for ; Sun, 7 Oct 2001 08:07:45 -0400 Received: by moria.seul.org (Postfix) id 5C1C91462FF; Sun, 7 Oct 2001 08:07:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a078.home.uni-hannover.de [130.75.232.78]) by moria.seul.org (Postfix) with ESMTP id 0B25D1462FE for ; Sun, 7 Oct 2001 08:07:45 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00813; Sun, 7 Oct 2001 02:29:58 +0200 Message-ID: <20011007022957.07472@thrai.stud.uni-hannover.de> Date: Sun, 7 Oct 2001 02:29:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BBFAC53.B9025BE7@f-cpu.org>; from Yann Guidon on Sun, Oct 07, 2001 at 02:13:55AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Oct 07, 2001 at 02:13:55AM +0100, Yann Guidon wrote: [...] > But i can't deny that having a working F-CPU sooner is attracting. > So there's the old dilemma : do we sacrifice source portability, > clock speed and high-level synthesis ? Or do we accept to go the > route of early prototypes ? > It would be cool if Alliance accepted VHDL'93 sources, or even > FOR .. GENERATE loops !!! Or library clauses... *sigh* I guess I'm only dreaming, but can't we feed Alliance a netlist? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Oct 7 21:04:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHix-0000pw-00 for ; Sun, 07 Oct 2001 19:28:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:23 +0200 (CEST) Received: (qmail 9775 invoked by uid 0); 7 Oct 2001 12:55:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx06) with SMTP; 7 Oct 2001 12:55:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97Ctd423344 for ; Sun, 7 Oct 2001 08:55:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 12:55:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97Ct5622833 for f-cpu-list; Sun, 7 Oct 2001 08:55:05 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97Ct3C22823 for ; Sun, 7 Oct 2001 08:55:03 -0400 Received: by moria.seul.org (Postfix) id 84B261462F8; Sun, 7 Oct 2001 08:55:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-124.vlt.club-internet.fr [195.36.173.124]) by moria.seul.org (Postfix) with ESMTP id 57AC21462F6 for ; Sun, 7 Oct 2001 08:55:04 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id DBD3D171B for ; Sun, 7 Oct 2001 15:04:34 -0400 (EDT) Message-ID: <3BC0A742.382E34D7@ifrance.com> Date: Sun, 07 Oct 2001 15:04:34 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <3BBFC004.E4982A3B@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : <...> > Nothing is portable -- schematics are often too low level. HDL's > are too abstract to map well to hardware.FPGA's all have > different logic cell functionality. I would personally go with > schematics > if there was a portable way of creating them. !!!! HDl are very portable : almost 90% of todays chip are using HDL. That's the quickest way to change to one technologie to an other ! Only alpha use a design team to create there layout even TI use HDL for there quickest DSP ! There other raison not to use HDL is for historical reason : the use of old core. I think the debat is over since a long time. You can use HDL to describe exactly the same thing than with schematic, but you can do a lot more, too ! > Ben. > > -- > Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. > "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk > Now with schematics. > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Oct 7 21:08:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHix-0000pw-01 for ; Sun, 07 Oct 2001 19:28:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:23 +0200 (CEST) Received: (qmail 10168 invoked by uid 0); 7 Oct 2001 12:55:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 7 Oct 2001 12:55:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97Ctdb23343 for ; Sun, 7 Oct 2001 08:55:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 12:55:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97Ct4k22828 for f-cpu-list; Sun, 7 Oct 2001 08:55:04 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97Ct2C22819 for ; Sun, 7 Oct 2001 08:55:03 -0400 Received: by moria.seul.org (Postfix) id 242F81462F8; Sun, 7 Oct 2001 08:55:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-124.vlt.club-internet.fr [195.36.173.124]) by moria.seul.org (Postfix) with ESMTP id 270F0146300 for ; Sun, 7 Oct 2001 08:55:04 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 56376175B for ; Sun, 7 Oct 2001 15:08:00 -0400 (EDT) Message-ID: <3BC0A810.C889985F@ifrance.com> Date: Sun, 07 Oct 2001 15:08:00 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > since i am studying at ASIME, i have learnt some > basics about using the "homemade" Alliance toolchain. > > I can make several reproaches about it : it is "a bit heavy", > does not comply to the VHDL standard coding practices, > but i begin to realize that it is not really a VHDL tool : > in fact it is more a synthesis tool. It has the advantage > that you can design masks relatively easily and quickly. > > However, from what i can see, the use of their precharacterised > library is not the best way to make a "fast" CPU, if you consider > that if you want to make custom ASIC, you want to get all > the power you expect from this. On one side, you reduce the > pressure on the post-synthesis tools (timing/parasitics/etc) > but on the other side, you can get almost the same speed > (and probably more) with the latest FPGAs (who support the > most recent synthesis algorithms with fully VHDL compliant sources). > This is because, from what i have seen, their strategy is > underefficient, particularly with P&R and post-layout compression > (there's often wasted surface). This is maybe my PCB designer's eyes > that tell me that. > > But i can't deny that having a working F-CPU sooner is attracting. > So there's the old dilemma : do we sacrifice source portability, > clock speed and high-level synthesis ? Or do we accept to go the > route of early prototypes ? You need to use the library from a foundry. Does Alliance accept synopsys library file ? Could you create SDF file to simulate it with timing (after synthesys)? > It would be cool if Alliance accepted VHDL'93 sources, or even > FOR .. GENERATE loops !!! > Alliance doesn't support "process", too... On of your teacher M Jacome made a thesis to write a wrapper from "clean" synposys VHDL to dirty alliance VHDL. nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 7 16:44:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHiz-0000pw-00 for ; Sun, 07 Oct 2001 19:28:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:25 +0200 (CEST) Received: (qmail 4504 invoked by uid 0); 7 Oct 2001 13:44:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 7 Oct 2001 13:44:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97DiEu25327 for ; Sun, 7 Oct 2001 09:44:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 13:43:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97Dhse25074 for f-cpu-list; Sun, 7 Oct 2001 09:43:54 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97DhrC25071 for ; Sun, 7 Oct 2001 09:43:53 -0400 Received: by moria.seul.org (Postfix) id E99451462F8; Sun, 7 Oct 2001 09:43:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id BA1441462F6 for ; Sun, 7 Oct 2001 09:43:55 -0400 (EDT) Received: from f-cpu.org (nas10-197.kdl.club-internet.fr [213.44.4.197]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BB92816AA for ; Sun, 7 Oct 2001 15:43:50 +0200 (CEST) Message-ID: <3BC06A50.C36837B4@f-cpu.org> Date: Sun, 07 Oct 2001 15:44:32 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <3BC0A810.C889985F@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > hi, > > > > since i am studying at ASIME, i have learnt some > > basics about using the "homemade" Alliance toolchain. > > But i can't deny that having a working F-CPU sooner is attracting. > > So there's the old dilemma : do we sacrifice source portability, > > clock speed and high-level synthesis ? Or do we accept to go the > > route of early prototypes ? > > You need to use the library from a foundry. Does Alliance accept > synopsys library file ? i don't know. It seems that Alliance has its own "standard library" which can be "mapped" to another one if needed (you'll have to go through the renaming of a few hundreds of files and their port declaration). > Could you create SDF file to simulate it with timing (after synthesys)? i don't know. i'm here since one week only, but i have seen that it is possible to run post-synthesis simulations (gate delays, no wire delay) using their precharacterized cells. i'll know more about it within a few months. > > It would be cool if Alliance accepted VHDL'93 sources, or even > > FOR .. GENERATE loops !!! > > Alliance doesn't support "process", too... that, too. And they declare FlipFlops with ... guarded blok :-( > On of your teacher M Jacome made a thesis to write a wrapper from > "clean" synposys VHDL to dirty alliance VHDL. we will probably have to use such a "wrapper" technique one day. Alliance is modular and designed in this perspective. However, i still think that Alliance-generated masks are underefficient. One example : their cells are abutted linearly but doesn't take into account the upper and lower rows. One trick is to flip the cells of every odd rows, so you can merge the Vdd rail with the row below, and the Vss rail with the above row. You can also merge the wells to make a wider one. Oh btw, during nov/dec, i'll have to make a MIPS CPU (pseudo-R3000). i'm ashamed to say that it is the microprogrammed one ... > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Oct 7 22:03:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHiz-0000pw-01 for ; Sun, 07 Oct 2001 19:28:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:25 +0200 (CEST) Received: (qmail 10966 invoked by uid 0); 7 Oct 2001 13:50:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 7 Oct 2001 13:50:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97DoPS25667 for ; Sun, 7 Oct 2001 09:50:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 13:50:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97Do6Q25413 for f-cpu-list; Sun, 7 Oct 2001 09:50:06 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97Do5C25410 for ; Sun, 7 Oct 2001 09:50:05 -0400 Received: by moria.seul.org (Postfix) id 1AA611462F8; Sun, 7 Oct 2001 09:50:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-124.vlt.club-internet.fr [195.36.173.124]) by moria.seul.org (Postfix) with ESMTP id 6BA2E1462F6 for ; Sun, 7 Oct 2001 09:50:07 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id C6EE7171B for ; Sun, 7 Oct 2001 16:03:39 -0400 (EDT) Message-ID: <3BC0B51B.3CD08345@ifrance.com> Date: Sun, 07 Oct 2001 16:03:39 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <3BC0A810.C889985F@ifrance.com> <3BC06A50.C36837B4@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <..> > > > It would be cool if Alliance accepted VHDL'93 sources, or even > > > FOR .. GENERATE loops !!! > > > > Alliance doesn't support "process", too... > > that, too. > And they declare FlipFlops with ... guarded blok :-( > An complete unrecommended manner from synopsys point of view... > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Oct 7 17:32:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qHj5-0000pw-00 for ; Sun, 07 Oct 2001 19:28:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Oct 2001 19:28:31 +0200 (CEST) Received: (qmail 28098 invoked by uid 0); 7 Oct 2001 15:34:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 7 Oct 2001 15:34:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97FYrV27565 for ; Sun, 7 Oct 2001 11:34:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 15:34:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97FYCK27292 for f-cpu-list; Sun, 7 Oct 2001 11:34:12 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97FYAC27287 for ; Sun, 7 Oct 2001 11:34:10 -0400 Received: by moria.seul.org (Postfix) id 99F211462F8; Sun, 7 Oct 2001 11:34:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id BEC661462F6 for ; Sun, 7 Oct 2001 11:34:11 -0400 (EDT) Received: from jetnet.ab.ca (dialin50.jetnet.ab.ca [207.153.6.50]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA19543 for ; Sun, 7 Oct 2001 09:34:07 -0600 (MDT) Message-ID: <3BC0757D.AF78BF6C@jetnet.ab.ca> Date: Sun, 07 Oct 2001 09:32:13 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <20011007022957.07472@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Sun, Oct 07, 2001 at 02:13:55AM +0100, Yann Guidon wrote: > [...] > > But i can't deny that having a working F-CPU sooner is attracting. > > So there's the old dilemma : do we sacrifice source portability, > > clock speed and high-level synthesis ? Or do we accept to go the > > route of early prototypes ? > > It would be cool if Alliance accepted VHDL'93 sources, or even > > FOR .. GENERATE loops !!! > > Or library clauses... *sigh* > > I guess I'm only dreaming, but can't we feed Alliance a netlist? What about using a macro pre-processer for all that stuff. What about writing your own register-transfer-langage pre-processor for F-cpu. This way the output can be what ever format you want. It is not that I don't like high-level synthesis, it the fact that the two most popular languages are a bitch. Ben. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 7 23:19:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVw0-0003JT-00 for ; Mon, 08 Oct 2001 10:38:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:38:48 +0200 (CEST) Received: (qmail 17224 invoked by uid 0); 7 Oct 2001 20:19:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 7 Oct 2001 20:19:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97KJZ630725 for ; Sun, 7 Oct 2001 16:19:35 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 20:19:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97KJ0r30467 for f-cpu-list; Sun, 7 Oct 2001 16:19:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97KIxC30464 for ; Sun, 7 Oct 2001 16:18:59 -0400 Received: by moria.seul.org (Postfix) id A80D91462FF; Sun, 7 Oct 2001 16:19:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 81A1B1462FE for ; Sun, 7 Oct 2001 16:19:01 -0400 (EDT) Received: from f-cpu.org (nas5-25.kdl.club-internet.fr [213.44.0.25]) by relay-3v.club-internet.fr (Postfix) with ESMTP id EF72116DB for ; Sun, 7 Oct 2001 22:18:50 +0200 (CEST) Message-ID: <3BC0C6E4.FBDA8A60@f-cpu.org> Date: Sun, 07 Oct 2001 22:19:32 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <20011007022957.07472@thrai.stud.uni-hannover.de> <3BC0757D.AF78BF6C@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, This evening i can't escape the mediatic bombing in the living room. my family is almost hypnotized by tonight's events. Fortunately, i can still speak with people who can think, not only feel and react like trained animals. Ben Franchuk wrote: > Michael Riepe wrote: > > On Sun, Oct 07, 2001 at 02:13:55AM +0100, Yann Guidon wrote: > > [...] > > > It would be cool if Alliance accepted VHDL'93 sources, or even > > > FOR .. GENERATE loops !!! > > Or library clauses... *sigh* > > > > I guess I'm only dreaming, but can't we feed Alliance a netlist? > > What about using a macro pre-processer for all that stuff. it would become extremely heavy :-/ VHDL and RTL in general is already not straight-forward to learn. I have remarked that the work is easier when we stick to simple, fully-standard VHDL source. The minimum requirement is to pass the comilation with Vanilla, because it's the easiest to setup for newcomers (before Simili'2 is released). Maybe we could use m4 for generating the proper invocation for latches and flip-flop, but it would not be useful : VHDL already provides the necessary means with operator overloading and component instanciation (you can redefine the component without touching the interface). > What about writing your own register-transfer-langage > pre-processor for F-cpu. This way the output can be what ever > format you want. It is not that I don't like high-level > synthesis, it the fact that the two most popular languages are a > bitch. I agree with some of your points. However it is not our goal to define a new RTL langage, and we don't have time nor experience, i think. It is already great to have some of the basic building blocks such as the minimum VHDL tools and some execution units. > Ben. nicO wrote: > Yann Guidon a écrit : > <..> > > > > It would be cool if Alliance accepted VHDL'93 sources, or even > > > > FOR .. GENERATE loops !!! > > > Alliance doesn't support "process", too... > > that, too. > > And they declare FlipFlops with ... guarded block :-( > An complete unrecommended manner from synopsys point of view... I don't know what they had in mind when they did that. One "solution" if we want to use Alliance is to use external components but it would force us to adopt a very low-level approach (heavy and less readable). > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 7 19:07:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVwD-0003JT-00 for ; Mon, 08 Oct 2001 10:39:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:39:01 +0200 (CEST) Received: (qmail 26574 invoked by uid 0); 7 Oct 2001 22:39:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 7 Oct 2001 22:39:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97MdD131984 for ; Sun, 7 Oct 2001 18:39:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 22:38:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97Mcie31723 for f-cpu-list; Sun, 7 Oct 2001 18:38:44 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97MchC31720 for ; Sun, 7 Oct 2001 18:38:43 -0400 Received: by moria.seul.org (Postfix) id CCBF21462F9; Sun, 7 Oct 2001 18:38:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id B6C181462F8 for ; Sun, 7 Oct 2001 18:38:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA06100; Sun, 7 Oct 2001 19:07:06 +0200 Message-ID: <20011007190706.30335@thrai.stud.uni-hannover.de> Date: Sun, 7 Oct 2001 19:07:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 'make it work' or 'make it fast' ? References: <3BBFAC53.B9025BE7@f-cpu.org> <20011007022957.07472@thrai.stud.uni-hannover.de> <3BC0757D.AF78BF6C@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BC0757D.AF78BF6C@jetnet.ab.ca>; from Ben Franchuk on Sun, Oct 07, 2001 at 09:32:13AM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Oct 07, 2001 at 09:32:13AM -0600, Ben Franchuk wrote: [...] > > I guess I'm only dreaming, but can't we feed Alliance a netlist? > > What about using a macro pre-processer for all that stuff. > What about writing your own register-transfer-langage > pre-processor for F-cpu. This way the output can be what ever > format you want. It is not that I don't like high-level > synthesis, it the fact that the two most popular languages are a > bitch. Definitely not. A VHDL-to-Alliance converter, maybe -- if there is one. But I'm not going to write one. Nor do I want to define a new HDL and write a (pre-)processor for it. VHDL (the real one, not the crippled Alliance subset) is good enough for me. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Oct 8 01:33:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVwF-0003JT-00 for ; Mon, 08 Oct 2001 10:39:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:39:03 +0200 (CEST) Received: (qmail 20021 invoked by uid 0); 7 Oct 2001 23:27:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 7 Oct 2001 23:27:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97NR1R32667 for ; Sun, 7 Oct 2001 19:27:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 23:26:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97NQe932412 for f-cpu-list; Sun, 7 Oct 2001 19:26:40 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97NQdC32409 for ; Sun, 7 Oct 2001 19:26:39 -0400 Received: by moria.seul.org (Postfix) id 0BA231462F9; Sun, 7 Oct 2001 19:26:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by moria.seul.org (Postfix) with ESMTP id 842AF1462F8 for ; Sun, 7 Oct 2001 19:26:41 -0400 (EDT) Received: from computer ([209.215.11.103]) by imf08bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011007232741.GEYS17406.imf08bis.bellsouth.net@computer>; Sun, 7 Oct 2001 19:27:41 -0400 Message-ID: <000c01c14f88$85a7d580$670bd7d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Trained Animals Date: Sun, 7 Oct 2001 18:33:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C14F5E.9A019680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C14F5E.9A019680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This Retired Trained Animal and my ancestors saved your ass twice in the = last century - so rest easy - and you can - thanks to the good ole U.S. = of A. I have several times in the past year heard rumblings of Socialism. By - By ------=_NextPart_000_0009_01C14F5E.9A019680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This Retired Trained Animal and my = ancestors saved=20 your ass twice in the last century - so rest easy - and you can - thanks = to the=20 good ole U.S. of A.
 
I have several times in the past = year heard=20 rumblings of Socialism.
 
By - By
------=_NextPart_000_0009_01C14F5E.9A019680-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Oct 8 02:50:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVwL-0003JT-00 for ; Mon, 08 Oct 2001 10:39:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:39:09 +0200 (CEST) Received: (qmail 20896 invoked by uid 0); 7 Oct 2001 23:50:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 7 Oct 2001 23:50:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f97Nohu00577 for ; Sun, 7 Oct 2001 19:50:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 7 Oct 2001 23:50:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f97NoJv32759 for f-cpu-list; Sun, 7 Oct 2001 19:50:19 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f97NoIC32756 for ; Sun, 7 Oct 2001 19:50:18 -0400 Received: by moria.seul.org (Postfix) id 7C5131462F8; Sun, 7 Oct 2001 19:50:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id CC8EF1462F6 for ; Sun, 7 Oct 2001 19:50:19 -0400 (EDT) Received: from f-cpu.org (nas25-23.kdl.club-internet.fr [213.44.96.23]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9DE421688 for ; Mon, 8 Oct 2001 01:50:12 +0200 (CEST) Message-ID: <3BC0F86E.25AD002B@f-cpu.org> Date: Mon, 08 Oct 2001 01:50:54 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] ROP2 unit Content-Type: multipart/mixed; boundary="------------96149F3577BD76AB1561ADB2" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------96149F3577BD76AB1561ADB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, here is yet another ROP2 unit version :-) i have merged the MUX4 (which was done with explicit boolean operations) with the FANOUT loop. I will probably write another, more flexible testbench for the unit and maybe start to write vectors to put in the BIST unit. The rest doesn't change : rop2_xbar.vhdl and the other files are the same. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------96149F3577BD76AB1561ADB2 Content-Type: text/plain; charset=us-ascii; name="rop2_unit.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rop2_unit.vhdl" -------------------------------------------------------------------------- -- f-cpu/vhdl/eu_rop2/rop2_unit.vhdl - ROP2 Execution Unit for the F-CPU -- Copyright (C) 2000-2001 Yann GUIDON (whygee@f-cpu.org) -- -- v0.2: Michael Riepe reorganized the main for-generate loop -- + corrected the lookup table (wrong op for ORN) -- v0.3: YG replaced UMAX/8 with MAXSIZE :-) -- v0.4: 11/17/2000, YG wants to rewrite the unit with MR's gate library ... -- -> abandonned. we stick to high-level coding. -- v0.5: 8/12/2001, YG modifies the interface, the names, adds MUX,... -- Sun Aug 12 01:16:11 2001: still untested but it includes -- the latest updates to the FC0 core. -- Tue Aug 21 08:45:16 2001: trying to make something that works reasonably. -- Mon Sep 3 08:49:45 2001: YG fixed some silly compile bugs :-/ -- vanillaHDL script and testbench added. -- Sun Oct 7 05:39:23 2001: changed ROP2 function to MUX4 -- Mon Oct 8 01:39:45 2001: merged SELECT with the FANOUT loop. -- --------------------------BEGIN-VHDL-LICENCE----------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ---------------------------END-VHDL-LICENCE------------------------------ -- -- This is a first working and stable version for this unit. -- It should be easily synthetizable but it is not attempted yet. -- What matters most today is that it compiles and behaves correctly. -- Warning : this code is and should remain purely combinatorial, -- there is no latching here, it must be done at another level. -- Furthermore, the function lookup table is now moved earlier -- in the pipeline, in parallel with the Xbar cycle : look at the -- f-cpu/vhdl/eu_rop2/rop2_xbar.vhdl file -- The big fanout problems (propagation of the opcode from 1 to 64 bits) -- overlaps the Xbar cycle so we can make a nice "signal tree". -- Finally, only byte combines are possible yet. The COMBINE -- instruction is still not completely specified in the manual. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; LIBRARY work; USE work.FCPU_config.ALL; Entity EU_ROP2 is port( ROP2_in_A, ROP2_in_B, ROP2_in_C : in F_VECTOR; -- the 3 operands ROP2_function_bit0, ROP2_function_bit1, -- pre-buffered boolean function bits ROP2_function_bit2, ROP2_function_bit3 : in Std_ulogic_vector((MAXSIZE *2) downto 0); -- fanout=4 ROP2_mode : in Std_ulogic_vector(1 downto 0); -- 2 function bits from the instruction -- Combine_size : in Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. ROP2_out : out F_VECTOR -- the result ); end EU_ROP2; Architecture arch1 of EU_ROP2 is signal partial_ROP, partial_OR, partial_AND, partial_MUX : F_VECTOR; -- the partial results. begin -------------------------------------------------------------------------- -- ROP2 cycle : (combinational part only) -------------------------------------------------------------------------- -- 1 : last fanout for the function bits + the ROP2 operator itself : -- (the former loop is merged with the ROP2/MUX operation) mux_loop : for i in UMAX-1 downto 0 generate signal t: std_ulogic_vector(1 downto 0); begin t <= ROP2_in_A(i) & ROP2_in_B(i); with t select partial_ROP(i) <= ROP2_function_bit0(i/4) when "00", ROP2_function_bit1(i/4) when "10", ROP2_function_bit2(i/4) when "01", ROP2_function_bit3(i/4) when others; -- "11" end generate mux_loop; -- YG> i hope that this will be recognized as a MUX4 operator, -- instead of the decomposed version used before (kept for -- historical reasons) which is probably slower and heavier : -- partial_ROP <= -- ((not ROP2_in_A) and (not ROP2_in_B) and local_function_3) -- or ((not ROP2_in_A) and ( ROP2_in_B) and local_function_2) -- or (( ROP2_in_A) and (not ROP2_in_B) and local_function_1) -- or (( ROP2_in_A) and ( ROP2_in_B) and local_function_0); -- Btw, I have found an optimal nMOS circuit layout that performs this -- function in one of Graham's books : "Introduction to nMOS and CMOS -- Systems Design" by Amar Mukherjee, Prentice-Hall International Editions, -- ISBN 0-13-490939-9, see pages 42 (fig. 3.13) and p170 (fig. 5.18). -- However, it doesn't work for CMOS. -- 2 bis : the MUX partial_MUX <= (ROP2_in_A and ( ROP2_in_C)) or (ROP2_in_B and (not ROP2_in_C)); -- 3 : partial ORs and ANDs on the byte chuncks : BYTE_COMBINE : for i in MAXSIZE-1 downto 0 generate partial_OR(8*i+7 downto 8*i) <= "11111111" when partial_ROP(8*i+7 downto 8*i) /= "00000000" else "00000000"; partial_AND(8*i+7 downto 8*i) <= "11111111" when partial_ROP(8*i+7 downto 8*i) = "11111111" else "00000000"; end generate BYTE_COMBINE; -- YG> I'm still uncertain about the best way to write a multi-size version. -- YG> Plus, the latency might explode the ROP2 unit's performance. -- YG> So the multi-size version is dropped until it becomes necessary. -- YG> Let's stick to plain bytes... -- YG> Note : rop2.eps contains a trick to relieve the fanout (1->8) problem. -- 4 : final selection stage : with ROP2_mode select ROP2_out <= partial_ROP when ROP2_DIRECT_MODE, partial_AND when ROP2_AND_MODE, partial_OR when ROP2_OR_MODE, partial_MUX when others; -- MUX -- YG> warning : huge fanous ! 1->64 for 4 signals, i hope that the synthesiser -- will generate the proper buffer tree. end; --------------96149F3577BD76AB1561ADB2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Oct 8 03:08:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVwM-0003JT-00 for ; Mon, 08 Oct 2001 10:39:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:39:10 +0200 (CEST) Received: (qmail 8762 invoked by uid 0); 8 Oct 2001 00:08:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx09) with SMTP; 8 Oct 2001 00:08:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9808Jk01481 for ; Sun, 7 Oct 2001 20:08:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 00:08:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98080I01227 for f-cpu-list; Sun, 7 Oct 2001 20:08:00 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9807xC01224 for ; Sun, 7 Oct 2001 20:07:59 -0400 Received: by moria.seul.org (Postfix) id 951EC1462F8; Sun, 7 Oct 2001 20:08:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 78F9B1462F6 for ; Sun, 7 Oct 2001 20:08:01 -0400 (EDT) Received: from f-cpu.org (nas10-131.kdl.club-internet.fr [213.44.4.131]) by relay-4v.club-internet.fr (Postfix) with ESMTP id ADE5B1699 for ; Mon, 8 Oct 2001 02:07:54 +0200 (CEST) Message-ID: <3BC0FC94.7837D104@f-cpu.org> Date: Mon, 08 Oct 2001 02:08:36 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Trained Animals References: <000c01c14f88$85a7d580$670bd7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, > "Richard E. Hartny" wrote: > > This Retired Trained Animal and my ancestors saved your ass > twice in the last century - so rest easy - and you can - > thanks to the good ole U.S. of A. > > I have several times in the past year heard rumblings of Socialism. > > By - By i am sorry to have expressed myself badly. as you know, i am french and tired (or vice versa) and i hope that you will excuse me. what i meant is that members of my family, and a lot of people around me, let their instinct speak, rather than seat down and think. The recent soccer game France vs Algeria is another example. Because i feel so different and detached, i feel sorry for these "trained animals" that let the TV broadcast make their mind. i did not choose to live in a world of violence but i have chosen to use my brain for neutral, peaceful and positive purposes where everybody can have a place, on the spiritual Eden of the Internet (wow, i'm really tired). It's not about political or religious belief. It's about good sense and respect. I don't want to fall in the traps of either camp and i will let nobody involve me in this. I also pray and hope that nothing will disturb our work : we are (mostly) hackers, not fanatics. I will therefore never speak about this again, to avoid misunderstanding and off-topic discussions. hope you like the newest ROP2, regards, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Oct 8 02:48:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVwN-0003JT-00 for ; Mon, 08 Oct 2001 10:39:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:39:11 +0200 (CEST) Received: (qmail 18542 invoked by uid 0); 8 Oct 2001 00:48:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 8 Oct 2001 00:48:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f980meh02039 for ; Sun, 7 Oct 2001 20:48:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 00:48:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f980mFk01784 for f-cpu-list; Sun, 7 Oct 2001 20:48:15 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f980mDC01781 for ; Sun, 7 Oct 2001 20:48:13 -0400 Received: by moria.seul.org (Postfix) id E14F0146303; Sun, 7 Oct 2001 20:48:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id 506BC146302 for ; Sun, 7 Oct 2001 20:48:14 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA13536; Mon, 8 Oct 2001 02:48:09 +0200 Message-ID: <20011008024809.33354@thrai.stud.uni-hannover.de> Date: Mon, 8 Oct 2001 02:48:09 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Trained Animals References: <000c01c14f88$85a7d580$670bd7d1@computer> <3BC0FC94.7837D104@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BC0FC94.7837D104@f-cpu.org>; from Yann Guidon on Mon, Oct 08, 2001 at 02:08:36AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 02:08:36AM +0100, Yann Guidon wrote: [...] > i am sorry to have expressed myself badly. as you know, i am > french and tired (or vice versa) and i hope that you will excuse me. Don't worry, *I* understood pretty well what you meant. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From justina@cat.co.za Mon Oct 8 18:34:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qVxq-0003JT-01 for ; Mon, 08 Oct 2001 10:40:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Oct 2001 10:40:42 +0200 (CEST) Received: (qmail 3707 invoked by uid 0); 8 Oct 2001 07:49:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx17) with SMTP; 8 Oct 2001 07:49:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f987ncp07746 for ; Mon, 8 Oct 2001 03:49:38 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 07:49:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f987n8I07491 for f-cpu-list; Mon, 8 Oct 2001 03:49:08 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f987n7C07488 for ; Mon, 8 Oct 2001 03:49:07 -0400 Received: by moria.seul.org (Postfix) id D614F1462F8; Mon, 8 Oct 2001 03:49:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailer.cat.co.za (mail.cat.co.za [196.33.33.51]) by moria.seul.org (Postfix) with SMTP id 1B8D71462F6 for ; Mon, 8 Oct 2001 03:49:07 -0400 (EDT) Received: (qmail 22861 invoked from network); 8 Oct 2001 07:48:49 -0000 Received: from unknown (HELO CAT99) (196.33.33.52) by mail.cat.co.za with SMTP; 8 Oct 2001 07:48:49 -0000 From: justin anderson To: f-cpu@seul.org Date: Mon, 8 Oct 2001 09:34:43 -0700 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01100809481600.00337@CAT99> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi guys, from what I have seen you are wanting to produce an ASIC. Just wondering what would be involved if a person were to use a large high speed FPGA as a processor. Large devices are in the order of 10M gate running at 400MHz, from Xilinx. This allows you to design a computer which can be changed. The speed tracks fpga technology and as larger faster fpga's are release so to will the processor grow. With some of these fpga's sections can be reprogrammed in operation. This allows for possible software acceleration tailored to a specific application eq. graphics or sound processing. cheers Justin ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Oct 8 10:59:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqC-0001qj-00 for ; Tue, 09 Oct 2001 00:25:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:40 +0200 (CEST) Received: (qmail 776 invoked by uid 0); 8 Oct 2001 08:59:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 8 Oct 2001 08:59:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f988xsU08875 for ; Mon, 8 Oct 2001 04:59:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 08:59:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f988xWj08598 for f-cpu-list; Mon, 8 Oct 2001 04:59:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f988xVC08595 for ; Mon, 8 Oct 2001 04:59:31 -0400 Received: by moria.seul.org (Postfix) id CA7B01462F9; Mon, 8 Oct 2001 04:59:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A7C891462F8 for ; Mon, 8 Oct 2001 04:59:33 -0400 (EDT) Received: from club-internet.fr (flashmail-cv.cs.clubint.net [172.16.0.119]) by relay-2v.club-internet.fr (Postfix) with SMTP id 9300017D0 for ; Mon, 8 Oct 2001 10:59:28 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] Re: X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Oct 2001 10:59:28 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f988xVC08596 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: justin anderson >Hi guys, > from what I have seen you are wanting to produce an ASIC. not exactly. The goal is to design and make freely available a CPU architecture and one or several implementations in VHDL (and other langages if people want to translate VHDL...). It is out of our scope and possibility to "produce an ASIC". However, there are some means/way to get some silicium fabbed in low quantity or for prototyping :-) > Just wondering what would be involved if a person > were to use a large high speed FPGA as a processor. hmmm let me guess ... a large power supply ? :-) no, i'm just kidding. > Large devices are in the order of 10M gate running at 400MHz, from Xilinx. The F-CPU multiplier already runs above 100MHz, IIRC. > This allows you to design a computer which can be changed. it depends on what you want and what you can afford. If your application domain requires a lot of customization, you can probably make the effort to buy all the toolchain and the expensive devices (i could probably buy my weight in chocolate for this price). However, if you're less concerned by customization, you can prefer to buy a new version every 3 or 6 months (just like you change your Linux Kernel). > The speed tracks fpga technology and as larger faster > fpga's are release so to will the processor grow. However, do NOT forget some inherent laws of microelectronics; particularly about signal routing ! When your IC is larger, you can get higher frequencies but you are also limited by the decreasing I/O pad vs gates ratio. THis means that your system will starve. "size is not everything" ! Another detail is that today, a large part of a CPU is used by cache but FPGA do not have large enough cache blocks. you will always lag by 5x or 10x compared to state-of-the-art commercial CPUs. > With some of these fpga's sections can be reprogrammed in >operation. This allows for possible software acceleration tailored to a >specific application eq. graphics or sound processing. maybe, but it is out of the scope of this project. If you have particular suggestions, we can discuss about it. >cheers Justin read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Oct 8 11:08:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqC-0001qj-01 for ; Tue, 09 Oct 2001 00:25:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:40 +0200 (CEST) Received: (qmail 19901 invoked by uid 0); 8 Oct 2001 09:09:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx23) with SMTP; 8 Oct 2001 09:09:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9899PY09282 for ; Mon, 8 Oct 2001 05:09:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 09:09:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98996i09027 for f-cpu-list; Mon, 8 Oct 2001 05:09:06 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98995C09024 for ; Mon, 8 Oct 2001 05:09:05 -0400 Received: by moria.seul.org (Postfix) id 4ABCE1462F9; Mon, 8 Oct 2001 05:09:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 093891462F8 for ; Mon, 8 Oct 2001 05:09:08 -0400 (EDT) Received: from club-internet.fr (flashmail-av.cs.clubint.net [172.16.0.117]) by relay-3v.club-internet.fr (Postfix) with SMTP id D348D16F4 for ; Mon, 8 Oct 2001 11:08:52 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] 2R2W SHL X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Oct 2001 11:08:52 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f98995C09025 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, IIRC michael is designing the SHL unit. I have a little suggestion : what about an instruction that does a 2R2W shift ? that is : one register gets the "normal" output of the shift, and the 2nd register gets the "shifted out" bits. the ROR/ROL instructions would be a OR of the two results. This is useful when a lot of bitblt is done, for graphics and bit string insertion/extraction... And there is no need to specify the shift direction because it is swapped when the destination registers are swapped :-) any comment ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Mon Oct 8 11:46:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqD-0001qj-00 for ; Tue, 09 Oct 2001 00:25:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:41 +0200 (CEST) Received: (qmail 28335 invoked by uid 0); 8 Oct 2001 09:47:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 8 Oct 2001 09:47:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f989lKA10033 for ; Mon, 8 Oct 2001 05:47:20 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 09:46:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f989kx609776 for f-cpu-list; Mon, 8 Oct 2001 05:46:59 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f989kwC09773 for ; Mon, 8 Oct 2001 05:46:58 -0400 Received: by moria.seul.org (Postfix) id 27B671462F9; Mon, 8 Oct 2001 05:47:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by moria.seul.org (Postfix) with ESMTP id 824EA1462F8 for ; Mon, 8 Oct 2001 05:47:00 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id MAA21624 for ; Mon, 8 Oct 2001 12:46:52 +0300 (EEST) Date: Mon, 8 Oct 2001 12:46:51 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: [f-cpu] Re: your mail In-Reply-To: <01100809481600.00337@CAT99> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 8 Oct 2001, justin anderson wrote: > what would be involved if a person were to use a large high speed FPGA as a > processor. Large devices are in the order of 10M gate running at 400MHz, from > Xilinx. This allows you to design a computer which can be changed. The speed You have to distinguish real speed and marketing speed :) The FPGAs are faster than they used to be and have big capacity, but you can pack 10 times more stuff to ASIC and make it 10 times faster (of course everything depends on application). Biggest disadvantage of big FPGAs is the price. ~$1000 is quite good price estimate in volume for the state of the art FPGAs. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Oct 8 15:08:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqH-0001qj-01 for ; Tue, 09 Oct 2001 00:25:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:45 +0200 (CEST) Received: (qmail 1674 invoked by uid 0); 8 Oct 2001 13:03:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx19) with SMTP; 8 Oct 2001 13:03:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98D3D514126 for ; Mon, 8 Oct 2001 09:03:13 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 13:02:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98D2Mf13870 for f-cpu-list; Mon, 8 Oct 2001 09:02:22 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98D2JC13867 for ; Mon, 8 Oct 2001 09:02:19 -0400 Received: by moria.seul.org (Postfix) id 470CA1462FD; Mon, 8 Oct 2001 09:02:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf08bis.bellsouth.net (mail008.mail.bellsouth.net [205.152.58.28]) by moria.seul.org (Postfix) with ESMTP id 1121E1462F8 for ; Mon, 8 Oct 2001 09:02:22 -0400 (EDT) Received: from computer ([209.214.154.107]) by imf08bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011008130319.SUHQ17406.imf08bis.bellsouth.net@computer>; Mon, 8 Oct 2001 09:03:19 -0400 Message-ID: <001b01c14ffa$77ce1f60$6b9ad6d1@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Re: Trained Animals Date: Mon, 8 Oct 2001 08:08:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C14FD0.78C5B7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C14FD0.78C5B7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You will not receive any more of this type shit from me. I too am tired - very tired as my only son passed on to another world = yesterday. I have been reviewing my presentation for the Microprocessor Forum 2001 = over and over using an overhead projector. This represents the = culmination of 7 years of work. Time sure does fly. Over this time the = improvements of FPGA's has been astronomical since their introduction in = 1988-1989. The only thing I can say about Xilinx is their performance = gain has resulted from 0.18UM silicon. One of my fellow logic designers = selected them - he made far tooo many errors in his initial designs. I chose Actel because they were a faster family. He won that argument = because of re-programmable ability - same as PAL's at the time. =20 When I return from San Jose next week I will prepare for you fellows a = complete summary. Back to work. Regards Dick Hartney ------=_NextPart_000_0018_01C14FD0.78C5B7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You will not receive any more of this = type shit=20 >from me.
 
I too am tired - very tired as my only = son passed=20 on to another world yesterday.
 
I have been reviewing my = presentation for the=20 Microprocessor Forum 2001 over and over using an overhead = projector.  This=20 represents the culmination of 7 years of work.  Time sure does = fly. =20 Over this time the improvements of FPGA's has been astronomical since = their=20 introduction in 1988-1989.  The only thing I can say about Xilinx = is their=20 performance gain has resulted from 0.18UM silicon.  One of my = fellow logic=20 designers selected them - he made far tooo many errors in his initial=20 designs.
I chose Actel because they were a = faster=20 family.  He won that argument because of re-programmable ability - = same as=20 PAL's at the time. 
 
When I return from San Jose next week I = will=20 prepare for you fellows a complete summary.  Back to = work.
 
Regards
Dick Hartney
 
------=_NextPart_000_0018_01C14FD0.78C5B7E0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Oct 8 15:12:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqJ-0001qj-01 for ; Tue, 09 Oct 2001 00:25:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:47 +0200 (CEST) Received: (qmail 22542 invoked by uid 0); 8 Oct 2001 13:42:23 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx25) with SMTP; 8 Oct 2001 13:42:23 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98DgMp15059 for ; Mon, 8 Oct 2001 09:42:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 13:41:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98DfV014576 for f-cpu-list; Mon, 8 Oct 2001 09:41:31 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98DfTC14573 for ; Mon, 8 Oct 2001 09:41:29 -0400 Received: by moria.seul.org (Postfix) id 635261462F9; Mon, 8 Oct 2001 09:41:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a201.home.uni-hannover.de [130.75.232.201]) by moria.seul.org (Postfix) with ESMTP id A37AD1462F8 for ; Mon, 8 Oct 2001 09:41:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00534; Mon, 8 Oct 2001 15:12:44 +0200 Message-ID: <20011008151244.27037@thrai.stud.uni-hannover.de> Date: Mon, 8 Oct 2001 15:12:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: your mail References: <01100809481600.00337@CAT99> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Mon, Oct 08, 2001 at 12:46:51PM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 12:46:51PM +0300, Kim Enkovaara wrote: [...] > You have to distinguish real speed and marketing speed :) The FPGAs are > faster than they used to be and have big capacity, but you can pack 10 > times more stuff to ASIC and make it 10 times faster (of course everything > depends on application). Does that mean the F-CPU multiplier runs at >1GHz in an ASIC, and needs only 3% of the die area? ;) > Biggest disadvantage of big FPGAs is the price. ~$1000 is quite good price > estimate in volume for the state of the art FPGAs. When you say "volume", you probably mean 1000+ of them in a box, and $1000 for each of them, right? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Oct 8 15:06:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqK-0001qj-00 for ; Tue, 09 Oct 2001 00:25:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:48 +0200 (CEST) Received: (qmail 26812 invoked by uid 0); 8 Oct 2001 13:42:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 8 Oct 2001 13:42:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98DgSb15111 for ; Mon, 8 Oct 2001 09:42:28 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 13:41:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98DfeQ14624 for f-cpu-list; Mon, 8 Oct 2001 09:41:40 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98DfaC14605 for ; Mon, 8 Oct 2001 09:41:36 -0400 Received: by moria.seul.org (Postfix) id 6BA5B1462F9; Mon, 8 Oct 2001 09:41:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a201.home.uni-hannover.de [130.75.232.201]) by moria.seul.org (Postfix) with ESMTP id 38C251462F8 for ; Mon, 8 Oct 2001 09:41:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00516; Mon, 8 Oct 2001 15:06:39 +0200 Message-ID: <20011008150639.15644@thrai.stud.uni-hannover.de> Date: Mon, 8 Oct 2001 15:06:39 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 2R2W SHL References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Oct 08, 2001 at 11:08:52AM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 11:08:52AM +0200, whygee@club-internet.fr wrote: > hello, > > IIRC michael is designing the SHL unit. I have a little > suggestion : what about an instruction that does a 2R2W shift ? > that is : one register gets the "normal" output of the shift, > and the 2nd register gets the "shifted out" bits. > the ROR/ROL instructions would be a OR of the two results. That's the way I do rotates now -- I stuff the input vector with zeroes, do a double-size shift, and OR the upper and lower half (it's a little more complex when SIMD is involved, but that's it, basically). The alternative approach is to use rotates as the basic element, and mask the unused bits when you're doing a shift operation. In this case, you can get the `double width shift' result with two separate masks. BTW: did somebody synthesize the alternative SHL core (the Rotate64 entity) I postet on Sep 28? I'm still interested in some numbers... > This is useful when a lot of bitblt is done, for graphics and > bit string insertion/extraction... And there is no need to > specify the shift direction because it is swapped when the destination > registers are swapped :-) But the interpretation of the shift count is also changed ;) > any comment ? Yep... I like the idea. How do we call it, dshiftl? shiftd? shiftx? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Oct 8 15:42:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqL-0001qj-00 for ; Tue, 09 Oct 2001 00:25:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:49 +0200 (CEST) Received: (qmail 29078 invoked by uid 0); 8 Oct 2001 13:43:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 8 Oct 2001 13:43:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98Dhhx15389 for ; Mon, 8 Oct 2001 09:43:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 13:43:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98Dh9E15129 for f-cpu-list; Mon, 8 Oct 2001 09:43:09 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98Dh6C15126 for ; Mon, 8 Oct 2001 09:43:06 -0400 Received: by moria.seul.org (Postfix) id 0B5F91462F9; Mon, 8 Oct 2001 09:43:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from lh00.opsion.fr (lh00.opsion.fr [212.73.208.226]) by moria.seul.org (Postfix) with SMTP id C121A1462F8 for ; Mon, 8 Oct 2001 09:43:08 -0400 (EDT) Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Mon, 8 Oct 2001 13:42:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] freeze signal From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 8 Oct 2001 13:42:54 GMT Message-id: <200110081342.36f5@lh00.opsion.fr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f98Dh6C15127 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Is it possible to add a signal to the entities to completly freeze its output. It's different from enable. The freeze signal must stop the pipeline or at least the output port of the unit, no new data should get out in the result port. We absolutely need this kind of stuff to handel unit with a latency more than 1 (to manage the fact to have 2 data could be ready in the same time) Any comment ? nicO ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Oct 8 15:48:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqL-0001qj-01 for ; Tue, 09 Oct 2001 00:25:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:49 +0200 (CEST) Received: (qmail 3341 invoked by uid 0); 8 Oct 2001 13:49:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx16) with SMTP; 8 Oct 2001 13:49:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98Dn9015729 for ; Mon, 8 Oct 2001 09:49:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 13:48:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98Dma815472 for f-cpu-list; Mon, 8 Oct 2001 09:48:36 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98DmYC15469 for ; Mon, 8 Oct 2001 09:48:34 -0400 Received: by moria.seul.org (Postfix) id 0880A1462F9; Mon, 8 Oct 2001 09:48:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id D59541462F8 for ; Mon, 8 Oct 2001 09:48:36 -0400 (EDT) Received: from club-internet.fr (flashmail-bv.cs.clubint.net [172.16.0.118]) by relay-4v.club-internet.fr (Postfix) with SMTP id 07B001710 for ; Mon, 8 Oct 2001 15:48:32 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Trained Animals X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Oct 2001 15:48:32 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f98DmYC15470 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: "Richard E. Hartny" >You will not receive any more of this type shit from me. being "productive" is so much more rewarding :-) >I too am tired - very tired as my only son passed > on to another world yesterday. all my sympathy. >I have been reviewing my presentation for the Microprocessor > Forum 2001 over and over using an overhead projector. > This represents the culmination of 7 years of work. Time sure does fly. > Over this time the improvements of FPGA's has been astronomical > since their introduction in 1988-1989. The only thing I can say about > Xilinx is their performance gain has resulted from 0.18UM silicon. > One of my fellow logic designers selected them - he made far tooo > many errors in his initial designs. what happened ? >I chose Actel because they were a faster family. He won that > argument because of re-programmable ability - same as PAL's at the time. > >When I return from San Jose next week I will prepare for you fellows > a complete summary. Back to work. Good luck and good work, >Regards >Dick Hartney read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Oct 8 18:26:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqP-0001qj-00 for ; Tue, 09 Oct 2001 00:25:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:53 +0200 (CEST) Received: (qmail 6591 invoked by uid 0); 8 Oct 2001 16:27:27 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx05) with SMTP; 8 Oct 2001 16:27:27 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98GRMn21995 for ; Mon, 8 Oct 2001 12:27:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 16:26:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98GQtI21742 for f-cpu-list; Mon, 8 Oct 2001 12:26:55 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98GQsC21739 for ; Mon, 8 Oct 2001 12:26:54 -0400 Received: by moria.seul.org (Postfix) id CB5771462F9; Mon, 8 Oct 2001 12:26:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id B05981462F8 for ; Mon, 8 Oct 2001 12:26:57 -0400 (EDT) Received: from club-internet.fr (flashmail-gv.cs.clubint.net [172.16.0.123]) by relay-2v.club-internet.fr (Postfix) with SMTP id 4927E1878 for ; Mon, 8 Oct 2001 18:26:53 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Oct 2001 18:26:53 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f98GQsC21740 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, >De: >Is it possible to add a signal to the entities to >completly freeze its output. It's different from >enable. The freeze signal must stop the pipeline or >at least the output port of the unit, no new data >should get out in the result port. > >We absolutely need this kind of stuff to handel unit >with a latency more than 1 (to manage the fact to >have 2 data could be ready in the same time) > >Any comment ? it's useless : writeback hazards are detected at decode/issue stage. No instruction is issued (that is : freeze at decode) when we detect that we won't be able to writeback in the future. hope this refreshes some memory :-) >nicO YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Oct 8 18:31:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqP-0001qj-01 for ; Tue, 09 Oct 2001 00:25:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:53 +0200 (CEST) Received: (qmail 15537 invoked by uid 0); 8 Oct 2001 16:32:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 8 Oct 2001 16:32:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98GW7f22335 for ; Mon, 8 Oct 2001 12:32:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 16:31:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98GViR22062 for f-cpu-list; Mon, 8 Oct 2001 12:31:44 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98GVhC22059 for ; Mon, 8 Oct 2001 12:31:43 -0400 Received: by moria.seul.org (Postfix) id 0AAD51462F9; Mon, 8 Oct 2001 12:31:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id DDA261462F8 for ; Mon, 8 Oct 2001 12:31:45 -0400 (EDT) Received: from club-internet.fr (flashmail-gv.cs.clubint.net [172.16.0.123]) by relay-2v.club-internet.fr (Postfix) with SMTP id 8E74C17DB for ; Mon, 8 Oct 2001 18:31:41 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] 2R2W SHL X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Oct 2001 18:31:41 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f98GVhC22060 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, >De: Michael Riepe >On Mon, Oct 08, 2001 at 11:08:52AM +0200, whygee@club-internet.fr wrote: >> hello, >> >> IIRC michael is designing the SHL unit. I have a little >> suggestion : what about an instruction that does a 2R2W shift ? >> that is : one register gets the "normal" output of the shift, >> and the 2nd register gets the "shifted out" bits. >> the ROR/ROL instructions would be a OR of the two results. >That's the way I do rotates now -- I stuff the input vector with zeroes, >do a double-size shift, and OR the upper and lower half (it's a little >more complex when SIMD is involved, but that's it, basically). there's no secret :-) >The alternative approach is to use rotates as the basic element, ??? where do you fetch these ideas ?... > and mask the unused bits when you're doing a shift operation. In this case, >you can get the `double width shift' result with two separate masks. > >BTW: did somebody synthesize the alternative SHL core (the Rotate64 >entity) I postet on Sep 28? I'm still interested in some numbers... me too :-) >> This is useful when a lot of bitblt is done, for graphics and >> bit string insertion/extraction... And there is no need to >> specify the shift direction because it is swapped when the destination >> registers are swapped :-) >But the interpretation of the shift count is also changed ;) not that much... >> any comment ? >Yep... I like the idea. How do we call it, dshiftl? shiftd? shiftx? no idea... what about sh ? :-) [why make it complex ?] > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Oct 9 01:36:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqU-0001qj-00 for ; Tue, 09 Oct 2001 00:25:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:58 +0200 (CEST) Received: (qmail 16352 invoked by uid 0); 8 Oct 2001 17:23:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Oct 2001 17:23:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98HN4e24236 for ; Mon, 8 Oct 2001 13:23:04 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 17:22:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98HMie23978 for f-cpu-list; Mon, 8 Oct 2001 13:22:44 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98HMhC23975 for ; Mon, 8 Oct 2001 13:22:43 -0400 Received: by moria.seul.org (Postfix) id 5EDB61462F9; Mon, 8 Oct 2001 13:22:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-222.vlt.club-internet.fr [194.158.107.222]) by moria.seul.org (Postfix) with ESMTP id C7D801462F8 for ; Mon, 8 Oct 2001 13:22:45 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 04F181761 for ; Mon, 8 Oct 2001 19:36:22 -0400 (EDT) Message-ID: <3BC23876.4197A62@ifrance.com> Date: Mon, 08 Oct 2001 19:36:22 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ROP2 unit References: <3BC0F86E.25AD002B@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <..> > -- YG> warning : huge fanous ! 1->64 for 4 signals, i hope that the synthesiser > -- will generate the proper buffer tree. You never _never_ take care of such low level stuff. You will take care of it during problem at the synthesys stage. Keep the code simple and understandable. In such udge project it's the most important thing. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Oct 9 01:49:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqV-0001qj-00 for ; Tue, 09 Oct 2001 00:25:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:59 +0200 (CEST) Received: (qmail 3267 invoked by uid 0); 8 Oct 2001 17:35:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx08) with SMTP; 8 Oct 2001 17:35:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98HZq725570 for ; Mon, 8 Oct 2001 13:35:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 17:35:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98HZMI25312 for f-cpu-list; Mon, 8 Oct 2001 13:35:22 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98HZKC25309 for ; Mon, 8 Oct 2001 13:35:20 -0400 Received: by moria.seul.org (Postfix) id D37E21462F9; Mon, 8 Oct 2001 13:35:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-222.vlt.club-internet.fr [194.158.107.222]) by moria.seul.org (Postfix) with ESMTP id 43FD61462F8 for ; Mon, 8 Oct 2001 13:35:23 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6000C1761 for ; Mon, 8 Oct 2001 19:49:00 -0400 (EDT) Message-ID: <3BC23B6C.6F39FAF9@ifrance.com> Date: Mon, 08 Oct 2001 19:49:00 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 2R2W SHL References: <20011008150639.15644@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : ent ? > > Yep... I like the idea. How do we call it, dshiftl? shiftd? shiftx? > shift ? Who can the more, could do the less. If we can reduice the number of mnemonic, maybe i could remember all (but we can add infix and no create alias it just add confusing ). nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Oct 9 01:55:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqV-0001qj-01 for ; Tue, 09 Oct 2001 00:25:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:25:59 +0200 (CEST) Received: (qmail 25720 invoked by uid 0); 8 Oct 2001 17:47:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Oct 2001 17:47:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98Hlx727984 for ; Mon, 8 Oct 2001 13:47:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 17:47:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98HlSS27748 for f-cpu-list; Mon, 8 Oct 2001 13:47:28 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98HlPC27744 for ; Mon, 8 Oct 2001 13:47:25 -0400 Received: by moria.seul.org (Postfix) id A5DE21462F8; Mon, 8 Oct 2001 13:47:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-43.vlt.club-internet.fr [194.158.107.43]) by moria.seul.org (Postfix) with ESMTP id B100C1462F6 for ; Mon, 8 Oct 2001 13:47:27 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2CA861761 for ; Mon, 8 Oct 2001 19:55:33 -0400 (EDT) Message-ID: <3BC23CF5.345113BE@ifrance.com> Date: Mon, 08 Oct 2001 19:55:33 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr a écrit : > > hi, > > >De: > > >Is it possible to add a signal to the entities to > >completly freeze its output. It's different from > >enable. The freeze signal must stop the pipeline or > >at least the output port of the unit, no new data > >should get out in the result port. > > > >We absolutely need this kind of stuff to handel unit > >with a latency more than 1 (to manage the fact to > >have 2 data could be ready in the same time) > > > >Any comment ? > > it's useless : writeback hazards are detected at decode/issue stage. > No instruction is issued (that is : freeze at decode) when we detect that > we won't be able to writeback in the future. > > hope this refreshes some memory :-) > Maybe in your theoretical scheduler but i wait to see it in real code. Make a system which predict the future, why not ? But it will take (i think) a lot of area (some calculation to do ?). At least, i wait the algorythme. nicO > >nicO > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Mon Oct 8 20:15:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qiqY-0001qj-00 for ; Tue, 09 Oct 2001 00:26:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:26:02 +0200 (CEST) Received: (qmail 13961 invoked by uid 0); 8 Oct 2001 18:17:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 8 Oct 2001 18:17:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98IH8J29600 for ; Mon, 8 Oct 2001 14:17:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 18:16:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98IG3n29313 for f-cpu-list; Mon, 8 Oct 2001 14:16:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98IG0C29310 for ; Mon, 8 Oct 2001 14:16:00 -0400 Received: by moria.seul.org (Postfix) id AA94D1462F8; Mon, 8 Oct 2001 14:16:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 034561462F6 for ; Mon, 8 Oct 2001 14:16:03 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id VAA23485 for ; Mon, 8 Oct 2001 21:15:58 +0300 (EET DST) Date: Mon, 8 Oct 2001 21:15:57 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] Re: your mail In-Reply-To: <20011008151244.27037@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 8 Oct 2001, Michael Riepe wrote: > Does that mean the F-CPU multiplier runs at >1GHz in an ASIC, and needs > only 3% of the die area? ;) Well, Intel has managed to get >1GHz at 0.18u so 1GHz at 0.13u should not be impossible. And at 250kgate/mm^2 and 100mm^2 (quite small die) you can burn 750 kgates for 3% of the area. Cache memory takes most of the die area anyways. Have you ever opened FPGA packages, the dies are huge. Even something like 400mm^2 and over. > > Biggest disadvantage of big FPGAs is the price. ~$1000 is quite good price > > estimate in volume for the state of the art FPGAs. > > When you say "volume", you probably mean 1000+ of them in a box, and > $1000 for each of them, right? Yes, I meant that. FPGAs are expensive if you need the best performance and lots of gates. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Oct 8 21:43:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qirB-0001qj-00 for ; Tue, 09 Oct 2001 00:26:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 00:26:41 +0200 (CEST) Received: (qmail 32145 invoked by uid 0); 8 Oct 2001 19:43:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 8 Oct 2001 19:43:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98JhiU31834 for ; Mon, 8 Oct 2001 15:43:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 19:42:50 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98Jgnq31571 for f-cpu-list; Mon, 8 Oct 2001 15:42:49 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98JglC31568 for ; Mon, 8 Oct 2001 15:42:47 -0400 Received: by moria.seul.org (Postfix) id 1A8C01462F9; Mon, 8 Oct 2001 15:42:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 84BF11462F8 for ; Mon, 8 Oct 2001 15:42:49 -0400 (EDT) Received: from art1.none.de (m-dialin-448.addcom.de [62.96.170.216]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f98JgkE17742 for ; Mon, 8 Oct 2001 21:42:51 +0200 X-Authentication-Warning: host-2.server.itns.de: Host m-dialin-448.addcom.de [62.96.170.216] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15qgJ9-0004uj-00 for ; Mon, 08 Oct 2001 21:43:23 +0200 Date: Mon, 8 Oct 2001 21:43:05 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, In a lecture about uController I had the idea of following architecture: Controller <-> RAM | +--+--+-----+-----+ ... | | | | ALU1 ALU2 ALU3 ALU4 Every ALU is very simple, it has 2 connections to a fast 2-wired serial bus and 8 lines to hardwire the ALU-adress. Every ALU has a serial bus de/encoder, a queue/register-set of 16 entries with static length and contains basic functions like "add", "shift"/"ror"/"ashift", "xor", "and", "or", "not" on 8-bit basis. The controller delivers tasks to ALUs, there will be the tasks executed in a queue and results stored in queue. The controller has an Init, which checks which ALUs are on bus, it decodes instruction from RAM, check which ALU is jobless and put the queue. Than it asks if an ALU is ready, if so it delivers next tasks. There is a cycle through all ALUs on bus. The signals on serial bus are controlled by controller and are: "getAdress": to get the ALUs-Adress and store in abuffer if it exists or not "getQueue": ALU should deliver their queue "getReady": is ALU ready? Is Queue done? "putQueue": deliver Queue to ALU "Reset": make clear "setSleep": ALU should sleep/wakeup now The structure of the queue-entry (32bit) is: ID (8bit: the same as hardwired ALUs-Adress) C0N (3bit: Carry, Zero, Negation-flag of result) OPCODE (21bit: operation + data, pE. "add": 3bit->operation, 8+1-Bit->Data1, 8+1-Bit->Data2) the controller hold the tasks with an 16-bit id builded from ALU-adress and queue-id. On serial bus can be 256 ALUs, if the timing on bus is critical, the queue-size on ALUs should be enlarged. Through many simple, cheap ALUs it is possible to do a parallel sort, multiplication (parallel addition), speculative calculation of branches and so on, if there less the controller needs longer to calculate something (to collect all results) advantages: - - simple ALUs - - scalable - - simple 2-wired bus-system is not so critical as a parallel bus or a x-bar-system - - easy extensible disadvantages: - - complex controller and compiler - - timing of serial-bus Is this an extensible concept? Can we use the concept of 2-wired bus with serial de/encoder on every unit in f-cpu instead x-bar? Okay on the one hand, every unit is enlarged by serial de/encoder, on the other hand there is no problem with depth of logic-cells, path-ways and so on. For serial de/encoder we need a shiftregister plus less than more logic... Any hints? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7wgHMClxplZklbgERAqkPAJ43GDkm8uJtGLQhpPV1uAxl5YwgJgCcCg9B t1vIA0MXCQOLIeyAxjhEae0= =g5aq -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Oct 8 18:42:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qmdV-0004c7-00 for ; Tue, 09 Oct 2001 04:28:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 04:28:49 +0200 (CEST) Received: (qmail 29602 invoked by uid 0); 8 Oct 2001 22:47:31 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx14) with SMTP; 8 Oct 2001 22:47:31 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98MlUN04656 for ; Mon, 8 Oct 2001 18:47:30 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 22:46:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98MkHF04390 for f-cpu-list; Mon, 8 Oct 2001 18:46:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98MkDC04387 for ; Mon, 8 Oct 2001 18:46:13 -0400 Received: by moria.seul.org (Postfix) id 8E9B21462F8; Mon, 8 Oct 2001 18:46:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id 312781462F6 for ; Mon, 8 Oct 2001 18:46:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA02347; Mon, 8 Oct 2001 18:42:07 +0200 Message-ID: <20011008184207.39346@thrai.stud.uni-hannover.de> Date: Mon, 8 Oct 2001 18:42:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200110081342.36f5@lh00.opsion.fr>; from nicolas.boulay@ifrance.com on Mon, Oct 08, 2001 at 01:42:54PM +0000 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 01:42:54PM +0000, nicolas.boulay@ifrance.com wrote: > Is it possible to add a signal to the entities to > completly freeze its output. It's different from > enable. The freeze signal must stop the pipeline or > at least the output port of the unit, no new data > should get out in the result port. Currently, the EUs contain no input or output registers at all; they're supposed to be added at the next higher level. > We absolutely need this kind of stuff to handel unit > with a latency more than 1 (to manage the fact to > have 2 data could be ready in the same time) The scheduler has to take care of that. It must delay the instruction if there is no free "transport slot". -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Oct 9 01:06:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qmdZ-0004c7-00 for ; Tue, 09 Oct 2001 04:28:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 04:28:53 +0200 (CEST) Received: (qmail 17831 invoked by uid 0); 8 Oct 2001 23:11:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 8 Oct 2001 23:11:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f98NB7J05377 for ; Mon, 8 Oct 2001 19:11:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 8 Oct 2001 23:10:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f98NA7505084 for f-cpu-list; Mon, 8 Oct 2001 19:10:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f98NA3C05079 for ; Mon, 8 Oct 2001 19:10:03 -0400 Received: by moria.seul.org (Postfix) id 07C971462F9; Mon, 8 Oct 2001 19:10:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id 62AB61462F8 for ; Mon, 8 Oct 2001 19:10:04 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03763; Tue, 9 Oct 2001 01:06:49 +0200 Message-ID: <20011009010649.31399@thrai.stud.uni-hannover.de> Date: Tue, 9 Oct 2001 01:06:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] 2R2W SHL References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Oct 08, 2001 at 06:31:41PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 06:31:41PM +0200, whygee@club-internet.fr wrote: [...] > >The alternative approach is to use rotates as the basic element, > ??? > where do you fetch these ideas ?... *They* fetch *me* ;) [...] > >Yep... I like the idea. How do we call it, dshiftl? shiftd? shiftx? > no idea... > what about sh ? :-) [why make it complex ?] And the SIMD variant will be called `ssh'? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From justina@cat.co.za Tue Oct 9 19:21:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qzW0-0000Z9-02 for ; Tue, 09 Oct 2001 18:13:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 18:13:56 +0200 (CEST) Received: (qmail 6084 invoked by uid 0); 9 Oct 2001 08:39:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx30) with SMTP; 9 Oct 2001 08:39:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f998d7x14473 for ; Tue, 9 Oct 2001 04:39:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 08:37:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f998bW914203 for f-cpu-list; Tue, 9 Oct 2001 04:37:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f998bPC14193 for ; Tue, 9 Oct 2001 04:37:25 -0400 Received: by moria.seul.org (Postfix) id EFCEE1462FD; Tue, 9 Oct 2001 04:37:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailer.cat.co.za (mailer.cat.co.za [196.33.33.51]) by moria.seul.org (Postfix) with SMTP id 7F9F11462F9 for ; Tue, 9 Oct 2001 04:37:26 -0400 (EDT) Received: (qmail 4362 invoked from network); 9 Oct 2001 08:37:15 -0000 Received: from unknown (HELO CAT99) (196.33.33.52) by mail.cat.co.za with SMTP; 9 Oct 2001 08:37:15 -0000 From: justin anderson To: f-cpu@seul.org Date: Tue, 9 Oct 2001 10:21:27 -0700 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01100910363600.10009@CAT99> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi All, just a coment, I did a bit of testing on an Intel pentium III 700MHz in C using netBSD. A simple program to test the number of multiplies that can be done per unit time. the results were roughly as follows 100M/sec for int multiplies. 5M/sec for floating point.. a bit disapointing on the floating point side. An alcheapo TMS processor 40MHz can do 40MFLOPS(probably marketing speed though) This explains why it battles with simulation type packages. Matlab, and spice. cheers justin. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From justina@cat.co.za Tue Oct 9 19:45:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qzW1-0000Z9-00 for ; Tue, 09 Oct 2001 18:13:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 18:13:57 +0200 (CEST) Received: (qmail 3627 invoked by uid 0); 9 Oct 2001 08:48:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 9 Oct 2001 08:48:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f998mig14878 for ; Tue, 9 Oct 2001 04:48:44 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 08:47:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f998lZU14618 for f-cpu-list; Tue, 9 Oct 2001 04:47:35 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f998lTC14609 for ; Tue, 9 Oct 2001 04:47:29 -0400 Received: by moria.seul.org (Postfix) id 5A49B1462FE; Tue, 9 Oct 2001 04:47:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailer.cat.co.za (pop.cat.co.za [196.33.33.51]) by moria.seul.org (Postfix) with SMTP id 687401462F9 for ; Tue, 9 Oct 2001 04:47:29 -0400 (EDT) Received: (qmail 29379 invoked from network); 9 Oct 2001 08:47:23 -0000 Received: from unknown (HELO CAT99) (196.33.33.52) by mail.cat.co.za with SMTP; 9 Oct 2001 08:47:23 -0000 From: justin anderson To: f-cpu@seul.org Subject: Re: [f-cpu] Re: your mail Date: Tue, 9 Oct 2001 10:45:27 -0700 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: MIME-Version: 1.0 Message-Id: <01100910464501.10009@CAT99> Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 08 Oct 2001, you wrote: > On Mon, 8 Oct 2001, Michael Riepe wrote: > > > Does that mean the F-CPU multiplier runs at >1GHz in an ASIC, and needs > > only 3% of the die area? ;) > > Well, Intel has managed to get >1GHz at 0.18u so 1GHz at 0.13u should not > be impossible. And at 250kgate/mm^2 and 100mm^2 (quite small die) you can > burn 750 kgates for 3% of the area. Cache memory takes most of the die > area anyways. Have you ever opened FPGA packages, the dies are huge. Even > something like 400mm^2 and over. if you only run at 200Mhz or so cach can be external??? > > > > > Biggest disadvantage of big FPGAs is the price. ~$1000 is quite good price > > > estimate in volume for the state of the art FPGAs. > > > > When you say "volume", you probably mean 1000+ of them in a box, and > > $1000 for each of them, right? > > Yes, I meant that. FPGAs are expensive if you need the best performance > and lots of gates. > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Oct 9 03:46:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15qzW2-0000Z9-00 for ; Tue, 09 Oct 2001 18:13:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Oct 2001 18:13:58 +0200 (CEST) Received: (qmail 605 invoked by uid 0); 9 Oct 2001 12:25:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 9 Oct 2001 12:25:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99CPmR17125 for ; Tue, 9 Oct 2001 08:25:48 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 12:24:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99COgw16846 for f-cpu-list; Tue, 9 Oct 2001 08:24:42 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99COcC16841 for ; Tue, 9 Oct 2001 08:24:38 -0400 Received: by moria.seul.org (Postfix) id B9B481462FE; Tue, 9 Oct 2001 08:24:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a220.home.uni-hannover.de [130.75.232.220]) by moria.seul.org (Postfix) with ESMTP id 626271462F9 for ; Tue, 9 Oct 2001 08:24:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA04212; Tue, 9 Oct 2001 03:46:12 +0200 Message-ID: <20011009034612.35292@thrai.stud.uni-hannover.de> Date: Tue, 9 Oct 2001 03:46:12 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Mon, Oct 08, 2001 at 09:43:05PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Oct 08, 2001 at 09:43:05PM +0200, Andreas Romeyke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > In a lecture about uController I had the idea of following architecture: > > > Controller <-> RAM > | > +--+--+-----+-----+ ... > | | | | > ALU1 ALU2 ALU3 ALU4 > > Every ALU is very simple, it has 2 connections to a fast 2-wired serial > bus and 8 lines to hardwire the ALU-adress. Every ALU has a serial bus > de/encoder, a queue/register-set of 16 entries with static length and > contains basic functions like "add", "shift"/"ror"/"ashift", "xor", "and", > "or", "not" on 8-bit basis. I'd rather use an array of ALUs, with separate row and column buses and dedicated links to their neighbours (much like the cells in an FPGA). Or maybe a ring. The second point is: why do you want to use S/P and P/S converters? Those operations can be done bitwise, (including ADD/SUB if you send the least significant bit first and save the carry bit at each cycle). [...] > Can we use the concept of 2-wired bus with serial de/encoder on every unit > in f-cpu instead x-bar? That's too slow. Remember that the bus must be much faster than the EUs, since we'll only be able to issue one instruction every 64 bus clock ticks (if there are seperate buses for each operand). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Oct 9 19:23:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMD-0000G4-00 for ; Wed, 10 Oct 2001 23:57:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:41 +0200 (CEST) Received: (qmail 30023 invoked by uid 0); 9 Oct 2001 17:24:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Oct 2001 17:24:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99HOqF23178 for ; Tue, 9 Oct 2001 13:24:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 17:23:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99HNaS22898 for f-cpu-list; Tue, 9 Oct 2001 13:23:36 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99HNWC22895 for ; Tue, 9 Oct 2001 13:23:32 -0400 Received: by moria.seul.org (Postfix) id 33F7C1462FE; Tue, 9 Oct 2001 13:23:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id DD2FD1462F9 for ; Tue, 9 Oct 2001 13:23:35 -0400 (EDT) Received: from club-internet.fr (flashmail-cv.cs.clubint.net [172.16.0.119]) by relay-2v.club-internet.fr (Postfix) with SMTP id 316F417CC for ; Tue, 9 Oct 2001 19:23:28 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 9 Oct 2001 19:23:28 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f99HNXC22896 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe : >On Mon, Oct 08, 2001 at 09:43:05PM +0200, Andreas Romeyke wrote: >> Hello, >> >> In a lecture about uController I had the idea of following architecture: >> >> Controller <-> RAM >> | >> +--+--+-----+-----+ ... >> | | | | >> ALU1 ALU2 ALU3 ALU4 >> >> Every ALU is very simple, it has 2 connections to a fast 2-wired serial >> bus and 8 lines to hardwire the ALU-adress. Every ALU has a serial bus >> de/encoder, a queue/register-set of 16 entries with static length and >> contains basic functions like "add", "shift"/"ror"/"ashift", "xor", "and", >> "or", "not" on 8-bit basis. > >I'd rather use an array of ALUs, with separate row and column buses >and dedicated links to their neighbours (much like the cells in an >FPGA). Or maybe a ring. this remembers me of : Illiac IV MASPAR CM1 CM2 GAPP and of course : OpenRisc OR2K :-D >The second point is: why do you want to use S/P and P/S converters? yep. that's the central question... > Michael "Tired" Riepe YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Oct 9 19:46:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMD-0000G4-01 for ; Wed, 10 Oct 2001 23:57:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:41 +0200 (CEST) Received: (qmail 13136 invoked by uid 0); 9 Oct 2001 17:47:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 9 Oct 2001 17:47:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99HlOm23781 for ; Tue, 9 Oct 2001 13:47:25 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 17:46:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99HkEk23507 for f-cpu-list; Tue, 9 Oct 2001 13:46:14 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99Hk9C23501 for ; Tue, 9 Oct 2001 13:46:10 -0400 Received: by moria.seul.org (Postfix) id 4A29F1462FD; Tue, 9 Oct 2001 13:46:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 0F3D11462F9 for ; Tue, 9 Oct 2001 13:46:13 -0400 (EDT) Received: from club-internet.fr (flashmail-cv.cs.clubint.net [172.16.0.119]) by relay-1v.club-internet.fr (Postfix) with SMTP id 20BD916CA for ; Tue, 9 Oct 2001 19:46:07 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] Re: X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 9 Oct 2001 19:46:07 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f99HkAC23502 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! justin anderson : >Hi All, > >just a coment, I did a bit of testing on an Intel pentium III 700MHz in C using >netBSD. what compiler ? what options ? >A simple program to test the number of multiplies that can be done per unit >time. what kind of multiplies ? 8, 16, 32 or 64 bits ? >the results were roughly as follows >100M/sec for int multiplies. >5M/sec for floating point.. >a bit disapointing on the floating point side. on the int side too ! PIII has SSE2 : you can do multiplies in parallel and pipelined mode. >An alcheapo TMS processor 40MHz can do 40MFLOPS(probably > marketing speed though) probably : they will count non-arithmetic FP moves as 'OPS'. >This explains why it battles with simulation type packages. Matlab, and spice. BTW i have seen that Nico did an article (in french) on this matter :-) >cheers justin. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Oct 9 22:29:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRME-0000G4-00 for ; Wed, 10 Oct 2001 23:57:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:42 +0200 (CEST) Received: (qmail 9497 invoked by uid 0); 9 Oct 2001 20:30:45 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 9 Oct 2001 20:30:45 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99KUhU28083 for ; Tue, 9 Oct 2001 16:30:43 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 20:29:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99KTWf27797 for f-cpu-list; Tue, 9 Oct 2001 16:29:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99KTSC27794 for ; Tue, 9 Oct 2001 16:29:28 -0400 Received: by moria.seul.org (Postfix) id C5B431462FD; Tue, 9 Oct 2001 16:29:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 3DF0C1462F9 for ; Tue, 9 Oct 2001 16:29:31 -0400 (EDT) Received: from art1.none.de (f-dialin-1555.addcom.de [62.96.145.115]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f99KTVE31578 for ; Tue, 9 Oct 2001 22:29:31 +0200 X-Authentication-Warning: host-2.server.itns.de: Host f-dialin-1555.addcom.de [62.96.145.115] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15r3W0-0000T7-00 for ; Tue, 09 Oct 2001 22:30:12 +0200 Date: Tue, 9 Oct 2001 22:29:54 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: <20011009034612.35292@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by belegost.mit.edu id f99KTSC27795 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > I'd rather use an array of ALUs, with separate row and column buses > and dedicated links to their neighbours (much like the cells in an > FPGA). Or maybe a ring. No, the advantage comes with a 2-wired differential bus. A ring or an array complicates the bus-interface and increases the HF-function. > The second point is: why do you want to use S/P and P/S converters? Why not? S/P and vice versa is easy to build. Today, I have some discussions, a 2-wired bus with +high, low and -high levels are very fast, because we have signals like this: a: +high low -high +high -high low b: -high low +high -high +high low so the sum of levels on a and b are always zero. Also with 3 logic levels we have the the chance to reduce/compress bitrate with 4b3t-code like in ISDN-systems (remember: 4 clocks in binary code means 16 combinations, 3 clocks in ternary code means 27 combinations, there also some ternärcodes free to use as sync) > > Can we use the concept of 2-wired bus with serial de/encoder on every unit > > in f-cpu instead x-bar? > > That's too slow. Remember that the bus must be much faster than the > EUs, since we'll only be able to issue one instruction every 64 bus > clock ticks (if there are seperate buses for each operand). No, it is not, if we have a EUs-clock of 1ms, we have on serial bus a clock of: size_of_register - ---------------- * 3 => bits/1ms + overhead_of_headers 4 * (sum of EUs) But, one serial bus with 2 lines in above described technology is easier in handling than a parallel bus with 64 or more lines with a line clock less than serial. Remember, a parallel bus is a capacity and frequency-sensitive and costs many of logic (see X-bar or Shifting-unit). BTW, my english is quite rare, but I hope you understand me... Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7w15FClxplZklbgERAoYjAKCHHeTvTPGpLIeVgCV9D5mTscwtQQCdHbIm U7i7+6kvUfcgNfqdzAI8iq8= =f//E -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 9 23:33:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRME-0000G4-01 for ; Wed, 10 Oct 2001 23:57:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:42 +0200 (CEST) Received: (qmail 22740 invoked by uid 0); 9 Oct 2001 20:33:56 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Oct 2001 20:33:56 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99KXsp28829 for ; Tue, 9 Oct 2001 16:33:54 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 20:32:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99KWXN28115 for f-cpu-list; Tue, 9 Oct 2001 16:32:33 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99KWTC28109 for ; Tue, 9 Oct 2001 16:32:29 -0400 Received: by moria.seul.org (Postfix) id 1596D1462FD; Tue, 9 Oct 2001 16:32:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E7C6E1462F9 for ; Tue, 9 Oct 2001 16:32:32 -0400 (EDT) Received: from f-cpu.org (nas20-151.kdl.club-internet.fr [213.44.18.151]) by relay-2v.club-internet.fr (Postfix) with ESMTP id D7D4717E3 for ; Tue, 9 Oct 2001 22:32:26 +0200 (CEST) Message-ID: <3BC36D18.1483B15D@f-cpu.org> Date: Tue, 09 Oct 2001 22:33:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 2R2W SHL References: <20011009010649.31399@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Oct 08, 2001 at 06:31:41PM +0200, whygee@club-internet.fr wrote: > [...] > > >The alternative approach is to use rotates as the basic element, > > ??? > > where do you fetch these ideas ?... > *They* fetch *me* ;) i see :-) > [...] > > >Yep... I like the idea. How do we call it, dshiftl? shiftd? shiftx? > > no idea... > > what about sh ? :-) [why make it complex ?] > And the SIMD variant will be called `ssh'? ;) this would be logical :-) FYI, there's an instruction called "sex" in the MOT. 6809 :-) [FYI: "Sign EXtension] > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 9 23:33:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMF-0000G4-00 for ; Wed, 10 Oct 2001 23:57:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:43 +0200 (CEST) Received: (qmail 22898 invoked by uid 0); 9 Oct 2001 20:34:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 9 Oct 2001 20:34:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99KY3Y28883 for ; Tue, 9 Oct 2001 16:34:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 20:32:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99KWbM28132 for f-cpu-list; Tue, 9 Oct 2001 16:32:37 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99KWWC28113 for ; Tue, 9 Oct 2001 16:32:33 -0400 Received: by moria.seul.org (Postfix) id 7BEAF1462FE; Tue, 9 Oct 2001 16:32:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 4C72D1462F9 for ; Tue, 9 Oct 2001 16:32:36 -0400 (EDT) Received: from f-cpu.org (nas20-151.kdl.club-internet.fr [213.44.18.151]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 58B7717F4 for ; Tue, 9 Oct 2001 22:32:28 +0200 (CEST) Message-ID: <3BC36D1A.4106A67@f-cpu.org> Date: Tue, 09 Oct 2001 22:33:14 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ROP2 unit References: <3BC0F86E.25AD002B@f-cpu.org> <3BC23876.4197A62@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > <..> > > -- YG> warning : huge fanous ! 1->64 for 4 signals, i hope that the synthesiser > > -- will generate the proper buffer tree. > > You never _never_ take care of such low level stuff. You will take care > of it during problem at the synthesys stage. Keep the code simple and > understandable. In such udge project it's the most important thing. ok i anticipate, but i want to see where the problems will arise. propagating 1 bit to 64 or more wires can be a limiting factor for the operating frequency, and i am more sensitive to this problem now. However, speaking about simplicity, can you find a trick to remove the 't' signal ? simili and vanilla refuse to put an agregate as argument of a with..select. I also would like to get rid of the for-generate loop but it's likely to be impossible to make a vector version, since the MUX selectors are vectors themselves... > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 9 23:33:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMF-0000G4-01 for ; Wed, 10 Oct 2001 23:57:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:43 +0200 (CEST) Received: (qmail 12467 invoked by uid 0); 9 Oct 2001 20:34:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 9 Oct 2001 20:34:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99KY3f28886 for ; Tue, 9 Oct 2001 16:34:03 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 20:32:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99KWc228134 for f-cpu-list; Tue, 9 Oct 2001 16:32:38 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99KWXC28116 for ; Tue, 9 Oct 2001 16:32:33 -0400 Received: by moria.seul.org (Postfix) id 812C41462F9; Tue, 9 Oct 2001 16:32:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 56F901462FD for ; Tue, 9 Oct 2001 16:32:36 -0400 (EDT) Received: from f-cpu.org (nas20-151.kdl.club-internet.fr [213.44.18.151]) by relay-2v.club-internet.fr (Postfix) with ESMTP id A9DAC17A9 for ; Tue, 9 Oct 2001 22:32:29 +0200 (CEST) Message-ID: <3BC36D1B.86D57473@f-cpu.org> Date: Tue, 09 Oct 2001 22:33:15 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <3BC23CF5.345113BE@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > whygee@club-internet.fr a écrit : > > hi, > > >De: > > > > >Is it possible to add a signal to the entities to > > >completly freeze its output. It's different from > > >enable. The freeze signal must stop the pipeline or > > >at least the output port of the unit, no new data > > >should get out in the result port. > > > > > >We absolutely need this kind of stuff to handel unit > > >with a latency more than 1 (to manage the fact to > > >have 2 data could be ready in the same time) > > > > > >Any comment ? > > > > it's useless : writeback hazards are detected at decode/issue stage. > > No instruction is issued (that is : freeze at decode) when we detect that > > we won't be able to writeback in the future. > > > > hope this refreshes some memory :-) > > Maybe in your theoretical scheduler but i wait to see it in real code. > Make a system which predict the future, why not ? But it will take (i > think) a lot of area (some calculation to do ?). At least, i wait the > algorythme. i guess that you understand that it is not the best time to write the code now. Of course the system can predict the future : the scheduling of every instruction is specified in the manual and conditioned by the behaviour and structure of every execution unit. I and it knows that if a ADD instruction is emitted, the result will be available on the "Xbar" 3 cycles later for another instruction. If you find another instruction without dependency after the ADD, you know that you must not issue it if the EU latency is 1, because the result would conflit with the ADD result on the Xbar unless the results are both a single value (because there are 2 write buses). The latency of the instructions can be written into a lookup table (which is generated when compiling the EUs). As for the algorithm : * decode/R7 read stage : read/get all the flags, lookup the opcode and flags into the LUT, check if the registers are ready and if there are available write slots on the Xbar. * Xbar/issue stage : decide if we issue the instruction (big AND/OR), insert the instruction in the write slot. You see that you can construct this only when all other elements are available : Xbar mechanisms, some EUs, Registers, flags, ... I have no time nor free brain cells for this now. I am already trying to find a solution for the synthesis problem, and configuring my computers. sorry for not being allmighty, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Oct 10 04:51:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMG-0000G4-00 for ; Wed, 10 Oct 2001 23:57:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:44 +0200 (CEST) Received: (qmail 12558 invoked by uid 0); 9 Oct 2001 20:39:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 9 Oct 2001 20:39:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99Kd7V29222 for ; Tue, 9 Oct 2001 16:39:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 20:38:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99Kc3Z28974 for f-cpu-list; Tue, 9 Oct 2001 16:38:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99KbwC28969 for ; Tue, 9 Oct 2001 16:37:59 -0400 Received: by moria.seul.org (Postfix) id EDDD11462FD; Tue, 9 Oct 2001 16:38:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-139.vlt.club-internet.fr [194.158.107.139]) by moria.seul.org (Postfix) with ESMTP id 3127C1462F9 for ; Tue, 9 Oct 2001 16:38:02 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8D4DE171D for ; Tue, 9 Oct 2001 22:51:04 -0400 (EDT) Message-ID: <3BC3B798.4214C310@ifrance.com> Date: Tue, 09 Oct 2001 22:51:04 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Mon, Oct 08, 2001 at 01:42:54PM +0000, nicolas.boulay@ifrance.com wrote: > > Is it possible to add a signal to the entities to > > completly freeze its output. It's different from > > enable. The freeze signal must stop the pipeline or > > at least the output port of the unit, no new data > > should get out in the result port. > > Currently, the EUs contain no input or output registers at all; they're > supposed to be added at the next higher level. > So how do you make the pipeline, i miss some thing ! > > We absolutely need this kind of stuff to handel unit > > with a latency more than 1 (to manage the fact to > > have 2 data could be ready in the same time) > > The scheduler has to take care of that. It must delay the instruction > if there is no free "transport slot". Yep, you must insert a delay so you must at least stop the current flow or you could try to predict the cas e (but i wait an algorythme for that). In the first case, i need a signal to stop the pipeline (or stop to produice output) to insert an empty slot. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Oct 10 01:07:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMH-0000G4-00 for ; Wed, 10 Oct 2001 23:57:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:45 +0200 (CEST) Received: (qmail 6942 invoked by uid 0); 9 Oct 2001 22:08:16 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Oct 2001 22:08:16 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99M8DV30786 for ; Tue, 9 Oct 2001 18:08:14 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 22:07:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99M73230527 for f-cpu-list; Tue, 9 Oct 2001 18:07:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99M6xC30524 for ; Tue, 9 Oct 2001 18:06:59 -0400 Received: by moria.seul.org (Postfix) id B64D21462FD; Tue, 9 Oct 2001 18:07:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7C0B01462F9 for ; Tue, 9 Oct 2001 18:07:02 -0400 (EDT) Received: from f-cpu.org (nas25-74.kdl.club-internet.fr [213.44.96.74]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C22D21697 for ; Wed, 10 Oct 2001 00:06:55 +0200 (CEST) Message-ID: <3BC3833E.76F0C1B0@f-cpu.org> Date: Wed, 10 Oct 2001 00:07:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> <3BC3B798.4214C310@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Michael Riepe a écrit : > > > > On Mon, Oct 08, 2001 at 01:42:54PM +0000, nicolas.boulay@ifrance.com wrote: > > > Is it possible to add a signal to the entities to > > > completly freeze its output. It's different from > > > enable. The freeze signal must stop the pipeline or > > > at least the output port of the unit, no new data > > > should get out in the result port. > > Currently, the EUs contain no input or output registers at all; they're > > supposed to be added at the next higher level. > > So how do you make the pipeline, i miss some thing ! when you "assemble" the EU slices together, you implement the "glue" with registers in the top level. For example, the ROP2 EU is made of 2 main files : one does the predecoding (+ fanout) and overlaps the Xbar read stage, and the other file "does" the ROP2/mux operation. When you create a testbench, you can "stick" the units together with wires, to avoid the latency management. When you implement the pipeline, you simply put pipe registers in the middle. However, some code designed by Michael is not like that, but allows the specification of what pipeline depth is desired. > > > We absolutely need this kind of stuff to handel unit > > > with a latency more than 1 (to manage the fact to > > > have 2 data could be ready in the same time) > > > > The scheduler has to take care of that. It must delay the instruction > > if there is no free "transport slot". > > Yep, you must insert a delay so you must at least stop the current flow the "current flow" can't be stopped once it is "issued" (sent to the EUs and inserted in the writeback queue). The "slot" is detected at decode stage and delayed at issue stage and before (decode and stage). Otherwise, we would need to insert heavier and slower pipe registers all over the chip and reduce the frequency :-/ > or you could try to predict the cas e (but i wait an algorythme for > that). it's a simple lookup table. IE : - when you see opcode = OP_ADD with 64-bit data and no carry (2r1w) - when you see that all the required registers are available (either in R7 or on the Xbar) - when you see that there is at least one free slot available in 3 cycles in the future => then you can issue the instruction (ask another instruction from the fetcher + validate the ASU + mark the destination register as "dirty" + allocate the slot in the scheduling queue). IF opcode=OP_ADD AND ( source or destination register is not ready OR no free slot in 3 cycles) then : delay 1 cycle and try again. I don't know if you accept this as an "algorithm" but it's what it does and you can see that we need 1 LUT and 1 scheduling queue. For the first FC0s, i am merging the "register scoreboard" with the queue, but i will use another technique for superscalar cores. > In the first case, i need a signal to stop the pipeline (or stop > to produice output) to insert an empty slot. The "slot" is inserted at decode/issue stage. the rest of the units can do their work without caring, as long as their latency is deterministic (and can be encoded in the opcode LUT which also tells the issue stage which flags are meaningful for the decision whether to issue or not). > nicO WHYGEE, going to sleep, now :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 01:19:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMJ-0000G4-01 for ; Wed, 10 Oct 2001 23:57:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:47 +0200 (CEST) Received: (qmail 29837 invoked by uid 0); 9 Oct 2001 23:20:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 9 Oct 2001 23:20:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99NKL131895 for ; Tue, 9 Oct 2001 19:20:21 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 23:19:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99NJGK31611 for f-cpu-list; Tue, 9 Oct 2001 19:19:16 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99NJBC31606 for ; Tue, 9 Oct 2001 19:19:11 -0400 Received: by moria.seul.org (Postfix) id 5AA271462FD; Tue, 9 Oct 2001 19:19:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id 072D21462F9 for ; Tue, 9 Oct 2001 19:19:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05341; Wed, 10 Oct 2001 01:19:11 +0200 Message-ID: <20011010011911.11199@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 01:19:11 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? References: <20011009034612.35292@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Tue, Oct 09, 2001 at 10:29:54PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Oct 09, 2001 at 10:29:54PM +0200, Andreas Romeyke wrote: [...] > > The second point is: why do you want to use S/P and P/S converters? > > Why not? Latency. > S/P and vice versa is easy to build. Today, I have some discussions, a > 2-wired bus with +high, low and -high levels are very fast, because we > have signals like this: > > a: +high low -high +high -high low > b: -high low +high -high +high low > > so the sum of levels on a and b are always zero. Also with 3 logic levels > we have the the chance to reduce/compress bitrate with 4b3t-code like in > ISDN-systems (remember: 4 clocks in binary code means 16 combinations, 3 > clocks in ternary code means 27 combinations, there also some ternärcodes > free to use as sync) You'll have to decode two `tits' (Ternary digITS ;) into 3 bits, then. Everything else is too complex. > > > Can we use the concept of 2-wired bus with serial de/encoder on every unit > > > in f-cpu instead x-bar? > > > > That's too slow. Remember that the bus must be much faster than the > > EUs, since we'll only be able to issue one instruction every 64 bus > > clock ticks (if there are seperate buses for each operand). > > No, it is not, if we have a EUs-clock of 1ms, we have on serial bus a > clock of: > > size_of_register > - ---------------- * 3 => bits/1ms + overhead_of_headers > 4 * (sum of EUs) That's 6 times the EU clock if there are 8 EUs... and if an EU runs at 1 GHz, your serial bus will run at 6 GHz?! > But, one serial bus with 2 lines in above described technology is easier > in handling than a parallel bus with 64 or more lines with a line clock > less than serial. > > Remember, a parallel bus is a capacity and frequency-sensitive and costs > many of logic (see X-bar or Shifting-unit). Buses are evil anyway, whether they have 2 lines or 200 ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 01:29:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMK-0000G4-00 for ; Wed, 10 Oct 2001 23:57:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:48 +0200 (CEST) Received: (qmail 28940 invoked by uid 0); 9 Oct 2001 23:31:07 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 9 Oct 2001 23:31:07 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99NV6832268 for ; Tue, 9 Oct 2001 19:31:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 23:30:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99NU1931993 for f-cpu-list; Tue, 9 Oct 2001 19:30:01 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99NTvC31987 for ; Tue, 9 Oct 2001 19:29:57 -0400 Received: by moria.seul.org (Postfix) id 4428E1462FD; Tue, 9 Oct 2001 19:30:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id 27BE01462F9 for ; Tue, 9 Oct 2001 19:29:59 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05371; Wed, 10 Oct 2001 01:29:58 +0200 Message-ID: <20011010012958.36544@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 01:29:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> <3BC3B798.4214C310@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3BC3B798.4214C310@ifrance.com>; from nicO on Tue, Oct 09, 2001 at 10:51:04PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Oct 09, 2001 at 10:51:04PM -0400, nicO wrote: > Michael Riepe a écrit : [...] > > Currently, the EUs contain no input or output registers at all; they're > > supposed to be added at the next higher level. > > > > So how do you make the pipeline, i miss some thing ! Inside the EUs, the registers are already there. I can also add registers to the in/out ports, if that is more convenient. But it's IMHO better to add them at the outer level, in case they need special control lines. > > > We absolutely need this kind of stuff to handel unit > > > with a latency more than 1 (to manage the fact to > > > have 2 data could be ready in the same time) > > > > The scheduler has to take care of that. It must delay the instruction > > if there is no free "transport slot". > > Yep, you must insert a delay so you must at least stop the current flow > or you could try to predict the cas e (but i wait an algorythme for > that). In the first case, i need a signal to stop the pipeline (or stop > to produice output) to insert an empty slot. No, you just don't issue the instruction. The pipeline will contain a "bubble" -- meaningless data -- that is ignored. Or, if it's one of my EUs that has a clock enable input, the unused stages will be stopped (while the active stages still finish other instructions). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 01:33:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRML-0000G4-00 for ; Wed, 10 Oct 2001 23:57:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:57:49 +0200 (CEST) Received: (qmail 26129 invoked by uid 0); 9 Oct 2001 23:35:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 9 Oct 2001 23:35:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f99NYwN32583 for ; Tue, 9 Oct 2001 19:34:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 9 Oct 2001 23:33:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f99NXr832317 for f-cpu-list; Tue, 9 Oct 2001 19:33:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f99NXmC32314 for ; Tue, 9 Oct 2001 19:33:48 -0400 Received: by moria.seul.org (Postfix) id 907711462FD; Tue, 9 Oct 2001 19:33:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id BB4741462F9 for ; Tue, 9 Oct 2001 19:33:50 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA05386; Wed, 10 Oct 2001 01:33:50 +0200 Message-ID: <20011010013350.33487@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 01:33:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> <3BC3B798.4214C310@ifrance.com> <3BC3833E.76F0C1B0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BC3833E.76F0C1B0@f-cpu.org>; from Yann Guidon on Wed, Oct 10, 2001 at 12:07:42AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Oct 10, 2001 at 12:07:42AM +0100, Yann Guidon wrote: [...] > when you "assemble" the EU slices together, you implement > the "glue" with registers in the top level. For example, the > ROP2 EU is made of 2 main files : one does the predecoding > (+ fanout) and overlaps the Xbar read stage, and the other > file "does" the ROP2/mux operation. > > When you create a testbench, you can "stick" the units together > with wires, to avoid the latency management. When you implement > the pipeline, you simply put pipe registers in the middle. > > However, some code designed by Michael is not like that, > but allows the specification of what pipeline depth is desired. [...] I'm afraid that feature is gone forever. It's easier to rewrite the unit for a different pipeline depth than make it configurable. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 10 12:44:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMX-0000G4-01 for ; Wed, 10 Oct 2001 23:58:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:01 +0200 (CEST) Received: (qmail 15373 invoked by uid 0); 10 Oct 2001 10:45:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Oct 2001 10:45:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AAjXX12919 for ; Wed, 10 Oct 2001 06:45:33 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 10:44:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AAiWo12656 for f-cpu-list; Wed, 10 Oct 2001 06:44:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AAiSC12653 for ; Wed, 10 Oct 2001 06:44:29 -0400 Received: by moria.seul.org (Postfix) id 53F211462FD; Wed, 10 Oct 2001 06:44:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 38A681462F9 for ; Wed, 10 Oct 2001 06:44:33 -0400 (EDT) Received: from club-internet.fr (flashmail-cv.cs.clubint.net [172.16.0.119]) by relay-3v.club-internet.fr (Postfix) with SMTP id DDE96168D for ; Wed, 10 Oct 2001 12:44:27 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] freeze signal X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 10 Oct 2001 12:44:27 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f9AAiTC12654 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe : >On Wed, Oct 10, 2001 at 12:07:42AM +0100, Yann Guidon wrote: >[...] >> However, some code designed by Michael is not like that, >> but allows the specification of what pipeline depth is desired. >[...] > >I'm afraid that feature is gone forever. It's easier to rewrite the >unit for a different pipeline depth than make it configurable. will you be able to write a configuration file ? (m4 etc.) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jschemme@ix.urz.uni-heidelberg.de Wed Oct 10 14:33:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMa-0000G4-00 for ; Wed, 10 Oct 2001 23:58:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:04 +0200 (CEST) Received: (qmail 21069 invoked by uid 0); 10 Oct 2001 12:34:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx026-rz3) with SMTP; 10 Oct 2001 12:34:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9ACYrW13979 for ; Wed, 10 Oct 2001 08:34:53 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 12:33:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9ACXmw13714 for f-cpu-list; Wed, 10 Oct 2001 08:33:48 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9ACXiC13708 for ; Wed, 10 Oct 2001 08:33:44 -0400 Received: by moria.seul.org (Postfix) id 28FF81462FD; Wed, 10 Oct 2001 08:33:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by moria.seul.org (Postfix) with ESMTP id A82871462F9 for ; Wed, 10 Oct 2001 08:33:47 -0400 (EDT) Received: from hp01.kip.uni-heidelberg.de (hp01f.kip.uni-heidelberg.de [129.206.240.61]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f9ACXgf04411 for ; Wed, 10 Oct 2001 14:33:42 +0200 (MET DST) Received: from wega.kip.uni-heidelberg.de (root@wega10.kip.uni-heidelberg.de [129.206.39.253]) by hp01.kip.uni-heidelberg.de (8.11.2/8.11.2) with ESMTP id f9ACXei19787 for ; Wed, 10 Oct 2001 14:33:41 +0200 (METDST) Received: from terra.kip.uni-heidelberg.de (root@terra.kip.uni-heidelberg.de [129.206.239.237]) by wega.kip.uni-heidelberg.de (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id OAA10174 for ; Wed, 10 Oct 2001 14:33:39 +0200 (METDST) Received: from ix.urz.uni-heidelberg.de (schemmel@localhost [127.0.0.1]) by terra.kip.uni-heidelberg.de (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id OAA00932 for ; Wed, 10 Oct 2001 14:33:38 +0200 (METDST) Message-ID: <3BC44021.119B265B@ix.urz.uni-heidelberg.de> Date: Wed, 10 Oct 2001 14:33:37 +0200 From: Johannes Schemmel X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Re: References: <01100809481600.00337@CAT99> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi Justin, for a digital design you are right, but our ASICs are analog ones. We have already produced two versions of our analog neural network. In fact we are using Xilinx chips to implement the training algorithms. Regards, Johannes justin anderson wrote: > > Hi guys, > from what I have seen you are wanting to produce an ASIC. Just wondering > what would be involved if a person were to use a large high speed FPGA as a > processor. Large devices are in the order of 10M gate running at 400MHz, from > Xilinx. This allows you to design a computer which can be changed. The speed > tracks fpga technology and as larger faster fpga's are release so to will the > processor grow. With some of these fpga's sections can be reprogrammed in > operation. This allows for possible software acceleration tailored to a > specific application eq. graphics or sound processing. > > cheers Justin > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- Dr. Johannes Schemmel Kirchhoff Institut fuer Physik / Electronic Vision(s) Universtitaet Heidelberg Tel: ++49-6221-548927 Schroederstr. 90 Fax: ++49-6221-544917 D-69120 Heidelberg schemmel@asic.uni-heidelberg.de http://www.kip.uni-heidelberg.de/vision ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Wed Oct 10 15:14:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMb-0000G4-00 for ; Wed, 10 Oct 2001 23:58:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:05 +0200 (CEST) Received: (qmail 15052 invoked by uid 0); 10 Oct 2001 13:15:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Oct 2001 13:15:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9ADFgk14598 for ; Wed, 10 Oct 2001 09:15:42 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 13:14:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9ADEYE14326 for f-cpu-list; Wed, 10 Oct 2001 09:14:34 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9ADEUC14323 for ; Wed, 10 Oct 2001 09:14:30 -0400 Received: by moria.seul.org (Postfix) id A99511462FD; Wed, 10 Oct 2001 09:14:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 117361462F9 for ; Wed, 10 Oct 2001 09:14:34 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id QAA06550 for ; Wed, 10 Oct 2001 16:14:27 +0300 (EET DST) Date: Wed, 10 Oct 2001 16:14:23 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 10 Oct 2001 whygee@club-internet.fr wrote: > >You'll have to decode two `tits' (Ternary digITS ;) into 3 bits, then. > >Everything else is too complex. > > on top of that, "digital" CMOS is not suited to "analog" functions > (the tolerances and the library cells are not available). It is not well suited but there are analog cells that are used with digital processes. For example PLLs and higs speed LVDS links. Those are always full custom blocks and quite often provided by the vendor. I know that they are not fun to do with digital process :) For example 2.5Gbit/s LVDS link is quite normal stuff with 0.18u digital processes. Those blocks have even analog functionalities (pre-ephasis for the signal etc.) ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 10 15:42:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMc-0000G4-00 for ; Wed, 10 Oct 2001 23:58:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:06 +0200 (CEST) Received: (qmail 30526 invoked by uid 0); 10 Oct 2001 13:43:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Oct 2001 13:43:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9ADhe315001 for ; Wed, 10 Oct 2001 09:43:40 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 13:42:36 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9ADgZZ14744 for f-cpu-list; Wed, 10 Oct 2001 09:42:35 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9ADgVC14739 for ; Wed, 10 Oct 2001 09:42:31 -0400 Received: by moria.seul.org (Postfix) id 0A4F51462FD; Wed, 10 Oct 2001 09:42:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [195.36.216.171]) by moria.seul.org (Postfix) with ESMTP id E2D191462F9 for ; Wed, 10 Oct 2001 09:42:35 -0400 (EDT) Received: from club-internet.fr (flashmail-em.cs.clubint.net [172.16.4.121]) by relay-2m.club-internet.fr (Postfix) with SMTP id C496616CD for ; Wed, 10 Oct 2001 15:42:29 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 10 Oct 2001 15:42:29 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f9ADgWC14740 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Kim Enkovaara : >On Wed, 10 Oct 2001 whygee@club-internet.fr wrote: >> >You'll have to decode two `tits' (Ternary digITS ;) into 3 bits, then. >> >Everything else is too complex. >> >> on top of that, "digital" CMOS is not suited to "analog" functions >> (the tolerances and the library cells are not available). > >It is not well suited but there are analog cells that are used with >digital processes. For example PLLs and higs speed LVDS links. Those are >always full custom blocks and quite often provided by the vendor. I know >that they are not fun to do with digital process :) > >For example 2.5Gbit/s LVDS link is quite normal stuff with 0.18u digital >processes. Those blocks have even analog functionalities (pre-ephasis for >the signal etc.) You are certainly right but - i don't think that internal databuses can use LVDS :-) - three-level logic (or more) is not immune to all the R/C/L problems (Xtalk, power noise, etc) - we don't have any widespread library and support tool for this... And our goal is to develop a CPU, not a processing technology :-) read you soon, >Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Wed Oct 10 17:25:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMc-0000G4-01 for ; Wed, 10 Oct 2001 23:58:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:06 +0200 (CEST) Received: (qmail 6525 invoked by uid 0); 10 Oct 2001 15:28:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 10 Oct 2001 15:28:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AFS6x16775 for ; Wed, 10 Oct 2001 11:28:06 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 15:26:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AFQrS16280 for f-cpu-list; Wed, 10 Oct 2001 11:26:53 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AFQmC16262 for ; Wed, 10 Oct 2001 11:26:48 -0400 Received: by moria.seul.org (Postfix) id 577C01462FD; Wed, 10 Oct 2001 11:26:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id B8A691462F9 for ; Wed, 10 Oct 2001 11:26:51 -0400 (EDT) Received: from art1.none.de (m-dialin-469.addcom.de [62.96.170.237]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f9AFQpE27044 for ; Wed, 10 Oct 2001 17:26:51 +0200 X-Authentication-Warning: host-2.server.itns.de: Host m-dialin-469.addcom.de [62.96.170.237] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15rLEi-000260-00 for ; Wed, 10 Oct 2001 17:25:32 +0200 Date: Wed, 10 Oct 2001 17:25:12 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] question to shifting unit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Erm, why we use parallel shifting than use registers/acummulation instead? I see, that a shift of 3 or more needs more cycles than parallel-shifting, but often we need a shift of one or two. Is it not possible to use that shifts on registerbank directly? We have then an additional unit free for other operations. Or is it too worse and too complex? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7xGhcClxplZklbgERAnkIAJ40FXxgT7aBGreSN3Od3/0hQE38lgCfcHAM OOYOQ/assUYsMZlxJ0qdIrQ= =2iq8 -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Wed Oct 10 17:10:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMd-0000G4-00 for ; Wed, 10 Oct 2001 23:58:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:07 +0200 (CEST) Received: (qmail 3207 invoked by uid 0); 10 Oct 2001 15:28:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 10 Oct 2001 15:28:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AFS9716791 for ; Wed, 10 Oct 2001 11:28:09 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 15:26:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AFQlA16260 for f-cpu-list; Wed, 10 Oct 2001 11:26:47 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AFQgC16255 for ; Wed, 10 Oct 2001 11:26:42 -0400 Received: by moria.seul.org (Postfix) id 021B91462FD; Wed, 10 Oct 2001 11:26:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 70AA41462F9 for ; Wed, 10 Oct 2001 11:26:46 -0400 (EDT) Received: from art1.none.de (m-dialin-469.addcom.de [62.96.170.237]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f9AFQjE27039 for ; Wed, 10 Oct 2001 17:26:45 +0200 X-Authentication-Warning: host-2.server.itns.de: Host m-dialin-469.addcom.de [62.96.170.237] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15rL1E-00024z-00 for ; Wed, 10 Oct 2001 17:11:36 +0200 Date: Wed, 10 Oct 2001 17:10:36 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Wed, 10 Oct 2001 whygee@club-internet.fr wrote: > on top of all that, ternary coding is not suitable for CMOS. > read some electrical/electronical books about this subject > (i have some courses about it currently) : it is not possible > to have a third stable electrical level in complementary > process. Hmmh, If we cannot use 4b3t, because ternary logic with CMOS is impossible, what are the args against a highspeed serial bus with 2 wires? On every lecture about hf-technology or highspeed-data-transmissions you find a lot of problems with wider bus-topologies and the problems with "uebersprechen" and capacity on bus will increase if number of lines and frequency increase, and we want use a very wide bus aka x-bar... You know about impulses -> system -> reaction chain? > >> 2-wired bus with +high, low and -high levels are very fast, because we > >> have signals like this: > >> a: +high low -high +high -high low > >> b: -high low +high -high +high low > >> so the sum of levels on a and b are always zero. > so what ? There are less interaction with noises and less iradiation. > >> size_of_register > >> - ---------------- * 3 => bits/1ms + overhead_of_headers > >> 4 * (sum of EUs) > > > >That's 6 times the EU clock if there are 8 EUs... and if an EU runs at > >1 GHz, your serial bus will run at 6 GHz?! 1GHz on X-Bar is more complicated than 10 GHz on a serial bus. > we can't do that. F-CPU is meant to work at the maximum clock speed > already. The logic behind that is : if one part of the device runs faster > than the rest, why can't the others run faster ? Furthermore, having There are advantages, IMHO: - - more robustness than x-bar against noises and iradiation - - less logiccells - - less routing-problems - - less floor space - - easier to extend, if number of units wil grow or if registersize increase > everything fully synchronous and with one clock only is so much easier > to debug and understand. The serial protocol can be used to synchronize units too. To understand the protocol/serial bus, you need only a timing diagramm. To debug a serial bus, you must only add a serial/parallel-converter or use a logic-analyzer/protokoll-analyzer... Also if there is no need to use a serial bus between units, it could be a good way to interact with f-cpu, IMHO. > >> Remember, a parallel bus is a capacity and frequency-sensitive and costs > >> many of logic (see X-bar or Shifting-unit). > >Buses are evil anyway, whether they have 2 lines or 200 ;) > like evils, they are unfortunately necessary ... > "il faut de tout pour faire un monde"... Your/MRs opinion is not substantiated. Also remember serial bus in Firewire, USB, Serial-ATA, Maple-Protokoll (Dreamcast) and so on... Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7xGTvClxplZklbgERAnheAJ9PLN9wxwKOr/+4PbLDiZZo0Yg1hgCeN75D WAyor4/CYdiAmgiaUYcHXLg= =CHyW -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 14:32:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMe-0000G4-00 for ; Wed, 10 Oct 2001 23:58:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:08 +0200 (CEST) Received: (qmail 12556 invoked by uid 0); 10 Oct 2001 15:29:23 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Oct 2001 15:29:23 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AFTL617068 for ; Wed, 10 Oct 2001 11:29:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 15:28:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AFSMj16811 for f-cpu-list; Wed, 10 Oct 2001 11:28:22 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AFSIC16808 for ; Wed, 10 Oct 2001 11:28:19 -0400 Received: by moria.seul.org (Postfix) id 0B2081462FD; Wed, 10 Oct 2001 11:28:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a112.home.uni-hannover.de [130.75.232.112]) by moria.seul.org (Postfix) with ESMTP id 942381462F9 for ; Wed, 10 Oct 2001 11:28:20 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00588; Wed, 10 Oct 2001 14:32:23 +0200 Message-ID: <20011010143223.54223@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 14:32:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] freeze signal References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Wed, Oct 10, 2001 at 12:44:27PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Oct 10, 2001 at 12:44:27PM +0200, whygee@club-internet.fr wrote: > hello, > > Michael Riepe : > >On Wed, Oct 10, 2001 at 12:07:42AM +0100, Yann Guidon wrote: > >[...] > >> However, some code designed by Michael is not like that, > >> but allows the specification of what pipeline depth is desired. > >[...] > > > >I'm afraid that feature is gone forever. It's easier to rewrite the > >unit for a different pipeline depth than make it configurable. > > will you be able to write a configuration file ? (m4 etc.) I'm able to do a lot of things... but this doesn't make sense. It would be easier if synthesis tools (in particular, Synopsys) hadn't so many restrictions -- I can't put multiple registers inside a single process, for instance. I also can't make a procedure or function that instantiates a register (event expressions inside subprograms don't work with Synopsys, although they're perfectly legal in simulation). On the other hand, I don't want to cut all EUs in ultra-thin (2 gates deep) slices and paste them together with configurable registers just to keep the variable pipeline depth feature. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 10 12:41:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMX-0000G4-00 for ; Wed, 10 Oct 2001 23:58:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:01 +0200 (CEST) Received: (qmail 17483 invoked by uid 0); 10 Oct 2001 10:42:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 10 Oct 2001 10:42:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AAgaN12634 for ; Wed, 10 Oct 2001 06:42:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 10:41:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AAfHt12374 for f-cpu-list; Wed, 10 Oct 2001 06:41:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AAfDC12371 for ; Wed, 10 Oct 2001 06:41:13 -0400 Received: by moria.seul.org (Postfix) id 5E2101462FD; Wed, 10 Oct 2001 06:41:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 3F5901462F9 for ; Wed, 10 Oct 2001 06:41:17 -0400 (EDT) Received: from club-internet.fr (flashmail-cv.cs.clubint.net [172.16.0.119]) by relay-4v.club-internet.fr (Postfix) with SMTP id A382E16F4 for ; Wed, 10 Oct 2001 12:41:11 +0200 (CEST) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 10 Oct 2001 12:41:11 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id f9AAfDC12372 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, on top of all that, ternary coding is not suitable for CMOS. read some electrical/electronical books about this subject (i have some courses about it currently) : it is not possible to have a third stable electrical level in complementary process. Michael Riepe : >On Tue, Oct 09, 2001 at 10:29:54PM +0200, Andreas Romeyke wrote: >[...] >> > The second point is: why do you want to use S/P and P/S converters? >> Why not? >Latency. that is secondary, compared to the rest ;-) >> S/P and vice versa is easy to build. Today, I have some discussions, a >> 2-wired bus with +high, low and -high levels are very fast, because we >> have signals like this: >> a: +high low -high +high -high low >> b: -high low +high -high +high low >> so the sum of levels on a and b are always zero. so what ? >> Also with 3 logic levels >> we have the the chance to reduce/compress bitrate with 4b3t-code like in >> ISDN-systems (remember: 4 clocks in binary code means 16 combinations, 3 >> clocks in ternary code means 27 combinations, there also some ternärcodes >> free to use as sync) > >You'll have to decode two `tits' (Ternary digITS ;) into 3 bits, then. >Everything else is too complex. on top of that, "digital" CMOS is not suited to "analog" functions (the tolerances and the library cells are not available). >> > > Can we use the concept of 2-wired bus with serial de/encoder on every unit >> > > in f-cpu instead x-bar? >> > >> > That's too slow. Remember that the bus must be much faster than the >> > EUs, since we'll only be able to issue one instruction every 64 bus >> > clock ticks (if there are seperate buses for each operand). >> >> No, it is not, if we have a EUs-clock of 1ms, we have on serial bus a >> clock of: >> >> size_of_register >> - ---------------- * 3 => bits/1ms + overhead_of_headers >> 4 * (sum of EUs) > >That's 6 times the EU clock if there are 8 EUs... and if an EU runs at >1 GHz, your serial bus will run at 6 GHz?! we can't do that. F-CPU is meant to work at the maximum clock speed already. The logic behind that is : if one part of the device runs faster than the rest, why can't the others run faster ? Furthermore, having everything fully synchronous and with one clock only is so much easier to debug and understand. >> But, one serial bus with 2 lines in above described technology is easier >> in handling than a parallel bus with 64 or more lines with a line clock >> less than serial. >> >> Remember, a parallel bus is a capacity and frequency-sensitive and costs >> many of logic (see X-bar or Shifting-unit). >Buses are evil anyway, whether they have 2 lines or 200 ;) like evils, they are unfortunately necessary ... "il faut de tout pour faire un monde"... > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Wed Oct 10 19:38:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMh-0000G4-00 for ; Wed, 10 Oct 2001 23:58:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:11 +0200 (CEST) Received: (qmail 9853 invoked by uid 0); 10 Oct 2001 17:40:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 10 Oct 2001 17:40:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AHe7719040 for ; Wed, 10 Oct 2001 13:40:07 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 17:38:35 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AHcZK18775 for f-cpu-list; Wed, 10 Oct 2001 13:38:35 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AHcTC18772 for ; Wed, 10 Oct 2001 13:38:30 -0400 Received: by moria.seul.org (Postfix) id D11FB1462FD; Wed, 10 Oct 2001 13:38:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id F39821462F9 for ; Wed, 10 Oct 2001 13:38:32 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id UAA10440 for ; Wed, 10 Oct 2001 20:38:26 +0300 (EET DST) Date: Wed, 10 Oct 2001 20:38:26 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 10 Oct 2001, Andreas Romeyke wrote: > Hmmh, If we cannot use 4b3t, because ternary logic with CMOS is > impossible, what are the args against a highspeed serial bus with 2 wires? Everything is possible, but making those Serdes blocks is not a trivial task (read: full custom layout task). You do not just drop them to the silicon, also they are not trivial to design. There are all kinds of problems related to very high speed design. > On every lecture about hf-technology or highspeed-data-transmissions you > find a lot of problems with wider bus-topologies and the problems with > "uebersprechen" and capacity on bus will increase if number of lines and > frequency increase, and we want use a very wide bus aka x-bar... Also routing of those high speed serial links is very difficult. You should sometimes ask from a backplane designer about all the nice problems of high speed serial links. Same problems will be inside the ASIC also. > 1GHz on X-Bar is more complicated than 10 GHz on a serial bus. I'm not so sure. In fully synchonous logic the state of the art layout tools will automatically do all kinds of balancing. For example they can do rough P&R runs, add cells to buffer things and to slow them down, then do routing again and iterate that until the timing is correct. Think that as static timing analysis during P&R. Of course the busses are not easy to design at those speeds, but they are doable. > The serial protocol can be used to synchronize units too. > To understand the protocol/serial bus, you need only a timing diagramm. > To debug a serial bus, you must only add a serial/parallel-converter or > use a logic-analyzer/protokoll-analyzer... How do you by the way sychonize the byte alignment in the serial link. That needs some nice overhead to the protocol. I have seen serial protocols designed and they are nothing but trivial, especially the byte and frame alignment. 8b/10b coding is one nice solution but not the most efficient one. > Also if there is no need to use a serial bus between units, it could be a > good way to interact with f-cpu, IMHO. Good luck with 10GHz signal in FR4 substrate. I think the upper limits of that material is in the ballpark on 3.125GHz. You have better luck with teflon or ceramics. And when the data is splitted to many serial links the problem of byte alignment becomes even more difficult (each link have to be synchonized by itself and then all of the links bundled in correct order). ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Wed Oct 10 19:49:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMi-0000G4-00 for ; Wed, 10 Oct 2001 23:58:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:12 +0200 (CEST) Received: (qmail 29840 invoked by uid 0); 10 Oct 2001 17:49:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 10 Oct 2001 17:49:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AHnfb19799 for ; Wed, 10 Oct 2001 13:49:41 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 17:48:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AHmec19531 for f-cpu-list; Wed, 10 Oct 2001 13:48:40 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AHmZC19527 for ; Wed, 10 Oct 2001 13:48:35 -0400 Received: by moria.seul.org (Postfix) id 1C79B1462FD; Wed, 10 Oct 2001 13:48:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 650991462F9 for ; Wed, 10 Oct 2001 13:48:39 -0400 (EDT) Received: from art1.none.de (f-dialin-114.addcom.de [62.96.139.114]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id f9AHmXE10646 for ; Wed, 10 Oct 2001 19:48:35 +0200 X-Authentication-Warning: host-2.server.itns.de: Host f-dialin-114.addcom.de [62.96.139.114] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 15rNTg-0003Od-00 for ; Wed, 10 Oct 2001 19:49:08 +0200 Date: Wed, 10 Oct 2001 19:49:01 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Wed, 10 Oct 2001, Kim Enkovaara wrote: > Good luck with 10GHz signal in FR4 substrate. I think the upper limits of > that material is in the ballpark on 3.125GHz. You have better luck with > teflon or ceramics. And when the data is splitted to many serial links Thanks for your detailed explanation... Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7xIoQClxplZklbgERApp0AJ41gXyOcf6nvw9GcB0/QCIpnolHdACfdx3j m1j6p4eKTnerQiQcjRotjwg= =9LpZ -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Wed Oct 10 21:34:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rRMi-0000G4-01 for ; Wed, 10 Oct 2001 23:58:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Oct 2001 23:58:12 +0200 (CEST) Received: (qmail 10328 invoked by uid 0); 10 Oct 2001 19:35:47 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx031-rz3) with SMTP; 10 Oct 2001 19:35:47 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AJZk521375 for ; Wed, 10 Oct 2001 15:35:46 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 19:34:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AJYOl21093 for f-cpu-list; Wed, 10 Oct 2001 15:34:24 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AJYJC21090 for ; Wed, 10 Oct 2001 15:34:19 -0400 Received: by moria.seul.org (Postfix) id 571761462FD; Wed, 10 Oct 2001 15:34:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from studict.student.utwente.nl (studict.student.utwente.nl [130.89.220.2]) by moria.seul.org (Postfix) with ESMTP id CCBF11462F9 for ; Wed, 10 Oct 2001 15:34:22 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id VAA07932 for ; Wed, 10 Oct 2001 21:34:16 +0200 (METDST) Message-ID: <002c01c151c2$8d801010$29e65982@student.utwente.nl> From: "Marco Al" To: References: Subject: Re: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint Date: Wed, 10 Oct 2001 21:34:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: > - i don't think that internal databuses can use LVDS :-) For what its worth the Russians (Elbrus) were going to use it for the E2K :) (And although I cant find it right now I distinctly remember someone knowledgable downplay that fact on Ace's by pointing out it had been done before.) "Circuit Design Advanced circuit design has been developed in Elbrus project to support ex- tremely high clock frequency implementation.It introduces two new basic logic elements (besides traditional ones): - universal self-reset logic with the following outstanding features . No losses for latches . No losses for clock skew . Time borrowing . Low power dissipation - differential logic for high speed long distance signal transfer This logic supports 25-30%better clock frequency compared to existing most advanced microprocessors." Personally I think it might be well suited for a large X-bar, would require simulation to find it out for sure one way or the other, but you probably need to design your own cell's (standard I/O LVDS cell's wont do ... you dont need most of the signal conditioning and it doesnt need to drive nearly as much current as for an external connection Id guess). But for a high performance processor some custom work will always be necessary. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Oct 11 00:53:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rTmK-00027X-00 for ; Thu, 11 Oct 2001 02:32:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 02:32:48 +0200 (CEST) Received: (qmail 5547 invoked by uid 0); 10 Oct 2001 21:53:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 10 Oct 2001 21:53:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9ALras23450 for ; Wed, 10 Oct 2001 17:53:36 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 21:52:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9ALqQi23183 for f-cpu-list; Wed, 10 Oct 2001 17:52:26 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9ALqMC23180 for ; Wed, 10 Oct 2001 17:52:22 -0400 Received: by moria.seul.org (Postfix) id 4173C1462FE; Wed, 10 Oct 2001 17:52:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0BD941462FD for ; Wed, 10 Oct 2001 17:52:27 -0400 (EDT) Received: from f-cpu.org (nas15-101.kdl.club-internet.fr [213.44.9.101]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 90E39168A for ; Wed, 10 Oct 2001 23:52:18 +0200 (CEST) Message-ID: <3BC4D153.D5BF3296@f-cpu.org> Date: Wed, 10 Oct 2001 23:53:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint References: <002c01c151c2$8d801010$29e65982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Marco Al wrote: > > From: > > > - i don't think that internal databuses can use LVDS :-) > > For what its worth the Russians (Elbrus) were going to use it for the E2K :) > (And although I cant find it right now I distinctly remember someone > knowledgable downplay that fact on Ace's by pointing out it had been done > before.) > > "Circuit Design > Advanced circuit design has been developed in Elbrus project to support ex- > tremely high clock frequency implementation.It introduces two new basic > logic elements (besides traditional ones): > > - universal self-reset logic with the following outstanding features > . No losses for latches > . No losses for clock skew > . Time borrowing > . Low power dissipation > > - differential logic for high speed long distance signal transfer > > This logic supports 25-30%better clock frequency compared to existing most > advanced microprocessors." BTW i still have to see one to be convinced :-PP > Personally I think it might be well suited for a large X-bar, would require > simulation to find it out for sure one way or the other, but you probably > need to design your own cell's (standard I/O LVDS cell's wont do ... you > dont need most of the signal conditioning and it doesnt need to drive nearly > as much current as for an external connection Id guess). But for a high > performance processor some custom work will always be necessary. in the frame of the F-CPU, i don't think that we can develop this. First because the application range is too wide : sae-of-gates, FPGA, full-custom or cell library-based... we have to design one-fits-all source files in as high a description level as possible (Nico made this remark again recently to me ;-D). Second because it requires very high skills and technology-dependent ressources : it wouldn't be done and would not be portable. Unless a genius comes and provides them. If we can't get them, there's no time to loose on annex problems (we design a CPU, not a silicon process ...) : there are already too many things to do and too few people who "really" work :-( Third, the "Xbar" is implemented in FC0 as a 2-level MUX. However, there would be one solution to speed up this critical part : use 3.3V locally (if we use ie a 2.8 or 2.5V technology). I have "learnt" this morning that the rising/failing time of CMOS gates that load capacitive/resistive depends on the Vdd. The buses of the "Xbar" are long and very resistive : high current and high(er) voltage (than "core logic") is probably necessary to compensate... Of course this is not possible in FPGA or precharacterised sea-of-gates. I don't even think that we can use this with Alliance (at least without seriously hacking into the netlists :-(). ok i gotta sleep ... i can't answer everything tonight or i'll never wake up early enough tomorrow :-/ we will "synthesise" an Am2901 4-bit slice EU with alliance. a real mess but i have to go through that... > Marco WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 19:32:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rTmK-00027X-01 for ; Thu, 11 Oct 2001 02:32:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 02:32:48 +0200 (CEST) Received: (qmail 19176 invoked by uid 0); 10 Oct 2001 22:32:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Oct 2001 22:32:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AMWiD24289 for ; Wed, 10 Oct 2001 18:32:45 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 22:31:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AMVW323825 for f-cpu-list; Wed, 10 Oct 2001 18:31:32 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AMVSC23822 for ; Wed, 10 Oct 2001 18:31:28 -0400 Received: by moria.seul.org (Postfix) id D80691462FE; Wed, 10 Oct 2001 18:31:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a048.home.uni-hannover.de [130.75.232.48]) by moria.seul.org (Postfix) with ESMTP id 022AD1462FD for ; Wed, 10 Oct 2001 18:31:19 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA25329; Wed, 10 Oct 2001 19:32:43 +0200 Message-ID: <20011010193243.41366@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 19:32:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Wed, Oct 10, 2001 at 05:10:36PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Oct 10, 2001 at 05:10:36PM +0200, Andreas Romeyke wrote: [...] > Hmmh, If we cannot use 4b3t, because ternary logic with CMOS is > impossible, what are the args against a highspeed serial bus with 2 wires? We won't get the transfer clock far beyond 1 GHz, and it takes 64 clocks to move a single operand to/from an EU. That's 128ns of additional latency for *every* operation (assuming that multiple operands/results use separate buses), and 64ns before we can issue another instruction for the same EU. > On every lecture about hf-technology or highspeed-data-transmissions you > find a lot of problems with wider bus-topologies and the problems with > "uebersprechen" and capacity on bus will increase if number of lines and > frequency increase, and we want use a very wide bus aka x-bar... "crosstalk" is the word you were looking for :) You forgot another important factor: bus length. > You know about impulses -> system -> reaction chain? I guess I should ;) > > >> 2-wired bus with +high, low and -high levels are very fast, because we > > >> have signals like this: > > >> a: +high low -high +high -high low > > >> b: -high low +high -high +high low > > >> so the sum of levels on a and b are always zero. > > so what ? > > There are less interaction with noises and less iradiation. > > > >> size_of_register > > >> - ---------------- * 3 => bits/1ms + overhead_of_headers > > >> 4 * (sum of EUs) > > > > > >That's 6 times the EU clock if there are 8 EUs... and if an EU runs at > > >1 GHz, your serial bus will run at 6 GHz?! > > 1GHz on X-Bar is more complicated than 10 GHz on a serial bus. If the serial line is point-to-point, well-terminated (with a well-known, fixed impedance) and uses low-swing differential signalling with pulse shaping (to remove the higher-level harmonics of the digital signal). > > we can't do that. F-CPU is meant to work at the maximum clock speed > > already. The logic behind that is : if one part of the device runs faster > > than the rest, why can't the others run faster ? Furthermore, having > > There are advantages, IMHO: > - - more robustness than x-bar against noises and iradiation > - - less logiccells > - - less routing-problems > - - less floor space > - - easier to extend, if number of units wil grow or if registersize > increase > > > everything fully synchronous and with one clock only is so much easier > > to debug and understand. > > The serial protocol can be used to synchronize units too. > To understand the protocol/serial bus, you need only a timing diagramm. > To debug a serial bus, you must only add a serial/parallel-converter or > use a logic-analyzer/protokoll-analyzer... > > Also if there is no need to use a serial bus between units, it could be a > good way to interact with f-cpu, IMHO. I proposed a differential, unidirectional, point-to-point serial link (transputer-style) for the F-BUS interface months ago. And my arguments were very similar. > > >> Remember, a parallel bus is a capacity and frequency-sensitive and costs > > >> many of logic (see X-bar or Shifting-unit). > > >Buses are evil anyway, whether they have 2 lines or 200 ;) > > like evils, they are unfortunately necessary ... > > "il faut de tout pour faire un monde"... > > Your/MRs opinion is not substantiated. Also remember serial bus in > Firewire, USB, Serial-ATA, Maple-Protokoll (Dreamcast) and so on... That's an *external* serial "bus" (actually a point-to-point link, IIRC). I could also add Fiber Channel, Twisted Pair Ethernet, RS-232 and many others to that list. The only internal, serial, *real* bus (with an arbitrary number of members connected to the same wires) I remember is I²C, and it's pretty slow. Buses suffer from lots of problems, no matter whether they're serial or parallel. Pairs of unidirectional point-to-point links are much better, but you'll need hubs/switches/crossbars to connect more than two units. Anyway... I like your new architecture (if you remove the S/P and P/S converters and perform the operations on-the-fly ;), but it's unlikely to be used in the F-CPU. It just doesn't fit into the Grand Plan(tm). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Oct 10 17:53:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15rTmL-00027X-00 for ; Thu, 11 Oct 2001 02:32:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 02:32:49 +0200 (CEST) Received: (qmail 3387 invoked by uid 0); 10 Oct 2001 22:33:00 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx033-rz3) with SMTP; 10 Oct 2001 22:33:00 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9AMWx224356 for ; Wed, 10 Oct 2001 18:32:59 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 10 Oct 2001 22:31:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9AMVol23890 for f-cpu-list; Wed, 10 Oct 2001 18:31:50 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9AMVjC23874 for ; Wed, 10 Oct 2001 18:31:45 -0400 Received: by moria.seul.org (Postfix) id DE6661462FE; Wed, 10 Oct 2001 18:31:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a048.home.uni-hannover.de [130.75.232.48]) by moria.seul.org (Postfix) with ESMTP id 2CBEE1462FD for ; Wed, 10 Oct 2001 18:31:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA13825; Wed, 10 Oct 2001 17:53:25 +0200 Message-ID: <20011010175325.21787@thrai.stud.uni-hannover.de> Date: Wed, 10 Oct 2001 17:53:25 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] question to shifting unit References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Wed, Oct 10, 2001 at 05:25:12PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Oct 10, 2001 at 05:25:12PM +0200, Andreas Romeyke wrote: [...] > Erm, why we use parallel shifting than > use registers/acummulation instead? > > I see, that a shift of 3 or more needs more cycles than parallel-shifting, > but often we need a shift of one or two. Hmm... we could add single-bit shift instructions that need one cycle, and do the multi-bit shifts in 2 cycles. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Oct 11 00:41:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15raiM-0000FT-01 for ; Thu, 11 Oct 2001 09:57:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 09:57:10 +0200 (CEST) Received: (qmail 15475 invoked by uid 0); 11 Oct 2001 01:22:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 11 Oct 2001 01:22:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9B1MMq26442 for ; Wed, 10 Oct 2001 21:22:22 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 01:21:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9B1L3I26177 for f-cpu-list; Wed, 10 Oct 2001 21:21:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9B1KxC26174 for ; Wed, 10 Oct 2001 21:20:59 -0400 Received: by moria.seul.org (Postfix) id 232DC1462FD; Wed, 10 Oct 2001 21:21:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (jetnet.ab.ca [207.153.11.66]) by moria.seul.org (Postfix) with ESMTP id 25E981462F9 for ; Wed, 10 Oct 2001 21:21:03 -0400 (EDT) Received: from jetnet.ab.ca (dialin40.jetnet.ab.ca [207.153.6.40]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA18539 for ; Wed, 10 Oct 2001 19:20:55 -0600 (MDT) Message-ID: <3BC4CE82.2695E8BB@jetnet.ab.ca> Date: Wed, 10 Oct 2001 16:41:07 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] question to shifting unit References: <20011010175325.21787@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Hmm... we could add single-bit shift instructions that need one cycle, > and do the multi-bit shifts in 2 cycles. What about a pre-sifter unit? << 2 , << 4 , << 8 , << 16 , << 32 << 48 >> 0, >> 2, >> 16 ,>> 32, >> 48, sign bit (0/-1) Then a smaller 2'nd stage stage shifter is needed.Ben -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Thu Oct 11 08:33:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15raiN-0000FT-00 for ; Thu, 11 Oct 2001 09:57:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 09:57:11 +0200 (CEST) Received: (qmail 5325 invoked by uid 0); 11 Oct 2001 06:34:48 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx033-rz3) with SMTP; 11 Oct 2001 06:34:48 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9B6YlA29210 for ; Thu, 11 Oct 2001 02:34:47 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 06:33:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9B6Xdt28955 for f-cpu-list; Thu, 11 Oct 2001 02:33:39 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9B6XZC28952 for ; Thu, 11 Oct 2001 02:33:35 -0400 Received: by moria.seul.org (Postfix) id E0B4E1462FD; Thu, 11 Oct 2001 02:33:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 480EF1462F9 for ; Thu, 11 Oct 2001 02:33:39 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA04769 for ; Thu, 11 Oct 2001 09:33:33 +0300 (EET DST) Date: Thu, 11 Oct 2001 09:33:32 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint In-Reply-To: <3BC4D153.D5BF3296@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 10 Oct 2001, Yann Guidon wrote: > However, there would be one solution to speed up this critical part : > use 3.3V locally (if we use ie a 2.8 or 2.5V technology). > I have "learnt" this morning that the rising/failing time of CMOS > gates that load capacitive/resistive depends on the Vdd. > The buses of the "Xbar" are long and very resistive : high current > and high(er) voltage (than "core logic") is probably necessary > to compensate... I hate to dissapoint you, but usually only one core voltage is supported inside the digital logic. Only IO rings can have additional voltages. If you need faster gates you select some high performance cells that use more space and have bigger transistors in the layout. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Thu Oct 11 08:41:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15raiN-0000FT-01 for ; Thu, 11 Oct 2001 09:57:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Oct 2001 09:57:11 +0200 (CEST) Received: (qmail 13924 invoked by uid 0); 11 Oct 2001 06:42:09 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 11 Oct 2001 06:42:09 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9B6g8T29506 for ; Thu, 11 Oct 2001 02:42:08 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 06:41:11 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9B6fAP29245 for f-cpu-list; Thu, 11 Oct 2001 02:41:10 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9B6f6C29242 for ; Thu, 11 Oct 2001 02:41:06 -0400 Received: by moria.seul.org (Postfix) id 3C79A1462FD; Thu, 11 Oct 2001 02:41:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id 734921462F9 for ; Thu, 11 Oct 2001 02:41:10 -0400 (EDT) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id JAA06605 for ; Thu, 11 Oct 2001 09:41:04 +0300 (EET DST) Date: Thu, 11 Oct 2001 09:41:03 +0300 (EET DST) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? In-Reply-To: <20011010193243.41366@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 10 Oct 2001, Michael Riepe wrote: > > 1GHz on X-Bar is more complicated than 10 GHz on a serial bus. > > If the serial line is point-to-point, well-terminated (with a well-known, > fixed impedance) and uses low-swing differential signalling with pulse > shaping (to remove the higher-level harmonics of the digital signal). Actually I think they are usually amplifying the high-level harmonics to compensate their attentuation in the transfer line :) ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From guidon@messiaen.lip6.fr Thu Oct 11 18:30:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stMp-0001WO-00 for ; Mon, 15 Oct 2001 00:04:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:04:19 +0200 (CEST) Received: (qmail 28580 invoked by uid 0); 11 Oct 2001 16:32:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx027-rz3) with SMTP; 11 Oct 2001 16:32:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9BGWCc04476 for ; Thu, 11 Oct 2001 12:32:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 16:30:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9BGUHX04208 for f-cpu-list; Thu, 11 Oct 2001 12:30:17 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9BGU8C04203 for ; Thu, 11 Oct 2001 12:30:09 -0400 Received: by moria.seul.org (Postfix) id EA6DC1462FD; Thu, 11 Oct 2001 12:30:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by moria.seul.org (Postfix) with ESMTP id 0B78D1462F9 for ; Thu, 11 Oct 2001 12:30:13 -0400 (EDT) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id f9BGU6eZ014748 for ; Thu, 11 Oct 2001 18:30:06 +0200 X-pt: isis.lip6.fr Received: from enseig.lip6.fr (enseig.lip6.fr [132.227.67.130]) by asim.lip6.fr (8.11.3nb1/8.11.0) with ESMTP id f9BGU5s27304 for ; Thu, 11 Oct 2001 18:30:05 +0200 (MEST) Received: from duparc.lip6.fr (duparc.lip6.fr [132.227.67.63]) by enseig.lip6.fr (8.9.3+Sun/8.9.3) with ESMTP id SAA04745 for ; Thu, 11 Oct 2001 18:30:05 +0200 (MET DST) From: "Yann Guidon [systeme]" Received: (from guidon@localhost) by duparc.lip6.fr (8.11.2/8.9.3) id f9BGU5Q23079 for f-cpu@seul.org; Thu, 11 Oct 2001 18:30:05 +0200 Date: Thu, 11 Oct 2001 18:30:05 +0200 Message-Id: <200110111630.f9BGU5Q23079@duparc.lip6.fr> To: f-cpu@seul.org Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Content-Type: Status: R X-Status: N yet another new version ... i hope that it will synthesize a little bit better with "serious" compilers. i am hopeless for Alliance : it is definitely useless (at least what we learn here). I'm glad i learnt VHDL'93 on myself (and with Michael's hints :-D) YG -------------------------------------------------------------------------- -- f-cpu/vhdl/eu_rop2/rop2_unit.vhdl - ROP2 Execution Unit for the F-CPU -- Copyright (C) 2000-2001 Yann GUIDON (whygee@f-cpu.org) -- -- v0.2: Michael Riepe reorganized the main for-generate loop -- + corrected the lookup table (wrong op for ORN) -- v0.3: YG replaced UMAX/8 with MAXSIZE :-) -- v0.4: 11/17/2000, YG wants to rewrite the unit with MR's gate library ... -- -> abandonned. we stick to high-level coding. -- v0.5: 8/12/2001, YG modifies the interface, the names, adds MUX,... -- Sun Aug 12 01:16:11 2001: still untested but it includes -- the latest updates to the FC0 core. -- Tue Aug 21 08:45:16 2001: trying to make something that works reasonably. -- Mon Sep 3 08:49:45 2001: YG fixed some silly compile bugs :-/ -- vanillaHDL script and testbench added. -- Sun Oct 7 05:39:23 2001: changed ROP2 function to MUX4 -- Mon Oct 8 01:39:45 2001: merged SELECT with the FANOUT loop. -- Thu Oct 11 17:59:36 2001: modified with-select clause, replaced t signal with -- agregate+attribute. -- --------------------------BEGIN-VHDL-LICENCE----------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ---------------------------END-VHDL-LICENCE------------------------------ -- -- This is a first working and stable version for this unit. -- It should be easily synthetizable but it is not attempted yet. -- What matters most today is that it compiles and behaves correctly. -- Warning : this code is and should remain purely combinatorial, -- there is no latching here, it must be done at another level. -- Furthermore, the function lookup table is now moved earlier -- in the pipeline, in parallel with the Xbar cycle : look at the -- f-cpu/vhdl/eu_rop2/rop2_xbar.vhdl file -- The big fanout problems (propagation of the opcode from 1 to 64 bits) -- overlaps the Xbar cycle so we can make a nice "signal tree". -- Finally, only byte combines are possible yet. The COMBINE -- instruction is still not completely specified in the manual. -------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; LIBRARY work; USE work.FCPU_config.ALL; Entity EU_ROP2 is port( ROP2_in_A, ROP2_in_B, ROP2_in_C : in F_VECTOR; -- the 3 operands ROP2_function_bit0, ROP2_function_bit1, -- pre-buffered boolean function bits ROP2_function_bit2, ROP2_function_bit3 : in Std_ulogic_vector((MAXSIZE *2) downto 0); -- fanout=4 ROP2_mode : in Std_ulogic_vector(1 downto 0); -- 2 function bits from the instruction -- Combine_size : in Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. ROP2_out : out F_VECTOR -- the result ); end EU_ROP2; Architecture arch1 of EU_ROP2 is signal partial_ROP, partial_OR, partial_AND, partial_MUX : F_VECTOR; -- the partial results. begin -------------------------------------------------------------------------- -- ROP2 cycle : (combinational part only) -------------------------------------------------------------------------- -- 1 : last fanout for the function bits + the ROP2 operator itself : -- (the older fanout loop was merged with this ROP2 (MUX) operation) rop_loop : for i in F_RANGE generate -- begin with std_ulogic_vector(1 downto 0)'(ROP2_in_A(i) & ROP2_in_B(i)) select partial_ROP(i) <= ROP2_function_bit0(i/4) when "00", ROP2_function_bit1(i/4) when "10", -- the order must be verified !!! ROP2_function_bit2(i/4) when "01", ROP2_function_bit3(i/4) when others; -- "11" -- YG> i hope that this will be recognized as a MUX4 operator, -- instead of the decomposed version used before (boolean version) -- which is probably slower and heavier. -- 2 bis : the 'MUX' operation (in parallel with the ROP2 operation) with ROP2_in_C(i) select partial_MUX(i) <= ROP2_in_A(i) when '1', ROP2_in_B(i) when others; -- '0' end generate rop_loop; -- 3 : partial ORs and ANDs on the byte chuncks : BYTE_COMBINE : for i in MAXSIZE-1 downto 0 generate partial_OR(8*i+7 downto 8*i) <= "11111111" when partial_ROP(8*i+7 downto 8*i) /= "00000000" else "00000000"; partial_AND(8*i+7 downto 8*i) <= "11111111" when partial_ROP(8*i+7 downto 8*i) = "11111111" else "00000000"; end generate BYTE_COMBINE; -- YG> I'm still uncertain about the best way to write a multi-size version. -- YG> Plus, the latency might explode the ROP2 unit's performance. -- YG> So the multi-size version is dropped until it becomes necessary. -- YG> Let's stick to plain bytes... -- YG> Note : rop2.eps contains a trick to relieve the fanout (1->8) problem. -- 4 : final selection stage : with ROP2_mode select ROP2_out <= partial_ROP when ROP2_DIRECT_MODE, partial_AND when ROP2_AND_MODE, partial_OR when ROP2_OR_MODE, partial_MUX when others; -- MUX -- YG> warning : huge fanous ! 1->64 for 4 signals, i hope that the synthesiser -- will generate the proper buffer tree. end; ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Oct 11 14:00:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stMs-0001WO-00 for ; Mon, 15 Oct 2001 00:04:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:04:22 +0200 (CEST) Received: (qmail 25067 invoked by uid 0); 11 Oct 2001 20:16:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 11 Oct 2001 20:16:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9BKGtl07955 for ; Thu, 11 Oct 2001 16:16:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 20:14:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9BKEkc07687 for f-cpu-list; Thu, 11 Oct 2001 16:14:46 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9BKEeC07684 for ; Thu, 11 Oct 2001 16:14:40 -0400 Received: by moria.seul.org (Postfix) id 199AD146304; Thu, 11 Oct 2001 16:14:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 855BD146303 for ; Thu, 11 Oct 2001 16:14:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00636; Thu, 11 Oct 2001 14:00:44 +0200 Message-ID: <20011011140043.26868@thrai.stud.uni-hannover.de> Date: Thu, 11 Oct 2001 14:00:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints? References: <20011010193243.41366@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Thu, Oct 11, 2001 at 09:41:03AM +0300 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Oct 11, 2001 at 09:41:03AM +0300, Kim Enkovaara wrote: > On Wed, 10 Oct 2001, Michael Riepe wrote: > > > > 1GHz on X-Bar is more complicated than 10 GHz on a serial bus. > > > > If the serial line is point-to-point, well-terminated (with a well-known, > > fixed impedance) and uses low-swing differential signalling with pulse > > shaping (to remove the higher-level harmonics of the digital signal). > > Actually I think they are usually amplifying the high-level harmonics to > compensate their attentuation in the transfer line :) I guess that depends on the signal, the transfer encoding and the characteristics of the transport medium. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Oct 12 00:03:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stMs-0001WO-01 for ; Mon, 15 Oct 2001 00:04:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:04:22 +0200 (CEST) Received: (qmail 30055 invoked by uid 0); 11 Oct 2001 22:50:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 11 Oct 2001 22:50:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9BMoqF10906 for ; Thu, 11 Oct 2001 18:50:52 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 11 Oct 2001 22:49:20 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9BMnJf10637 for f-cpu-list; Thu, 11 Oct 2001 18:49:19 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9BMnDC10634 for ; Thu, 11 Oct 2001 18:49:13 -0400 Received: by moria.seul.org (Postfix) id 585D01462FD; Thu, 11 Oct 2001 18:49:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a087.home.uni-hannover.de [130.75.232.87]) by moria.seul.org (Postfix) with ESMTP id E02F21462F9 for ; Thu, 11 Oct 2001 18:49:04 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02409; Fri, 12 Oct 2001 00:03:47 +0200 Message-ID: <20011012000347.27984@thrai.stud.uni-hannover.de> Date: Fri, 12 Oct 2001 00:03:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Re: your mail References: <200110111630.f9BGU5Q23079@duparc.lip6.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200110111630.f9BGU5Q23079@duparc.lip6.fr>; from Yann Guidon [systeme] on Thu, Oct 11, 2001 at 06:30:05PM +0200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Oct 11, 2001 at 06:30:05PM +0200, Yann Guidon [systeme] wrote: > yet another new version ... [...] > -- 1 : last fanout for the function bits + the ROP2 operator itself : > -- (the older fanout loop was merged with this ROP2 (MUX) operation) > rop_loop : for i in F_RANGE generate > -- begin > with std_ulogic_vector(1 downto 0)'(ROP2_in_A(i) & ROP2_in_B(i)) select > partial_ROP(i) <= > ROP2_function_bit0(i/4) when "00", > ROP2_function_bit1(i/4) when "10", -- the order must be verified !!! > ROP2_function_bit2(i/4) when "01", > ROP2_function_bit3(i/4) when others; -- "11" > -- YG> i hope that this will be recognized as a MUX4 operator, > -- instead of the decomposed version used before (boolean version) > -- which is probably slower and heavier. Yep, it should. `with ... select' is the concurrent equivalent of the sequential `case ... end case' statement, which will result in a MUX. On the other hand, a boolean expression can be transformed to a more suitable, equivalent expression (DeMorgan), while a MUX probably can't. This may make a difference in an ASIC or full-custom chip. > -- 2 bis : the 'MUX' operation (in parallel with the ROP2 operation) > with ROP2_in_C(i) select > partial_MUX(i) <= > ROP2_in_A(i) when '1', > ROP2_in_B(i) when others; -- '0' > end generate rop_loop; > > > -- 3 : partial ORs and ANDs on the byte chuncks : > BYTE_COMBINE : for i in MAXSIZE-1 downto 0 generate > partial_OR(8*i+7 downto 8*i) <= "11111111" when > partial_ROP(8*i+7 downto 8*i) /= "00000000" > else "00000000"; > partial_AND(8*i+7 downto 8*i) <= "11111111" when > partial_ROP(8*i+7 downto 8*i) = "11111111" > else "00000000"; > end generate BYTE_COMBINE; > -- YG> I'm still uncertain about the best way to write a multi-size version. > -- YG> Plus, the latency might explode the ROP2 unit's performance. > -- YG> So the multi-size version is dropped until it becomes necessary. > -- YG> Let's stick to plain bytes... > -- YG> Note : rop2.eps contains a trick to relieve the fanout (1->8) problem. What about a second pipeline stage? The first one could do the direct and mux modes, while the second would perform the combine operations. That would also leave some room in the first stage where we can add a 6:64 decoder (or two 3:8, oder three 2:4 decoders) for the `bitop' instruction. I know that bitop is supposed to be handled by the SHL unit, but that won't work anyway (or will make the shifter even *more* complex), and I really don't care if combines need one or two cycles (IMHO we could also drop them completely -- it's still possible to do combines with the cmpl[e] instruction, at *any* chunk size). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Oct 13 19:09:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNk-0001WO-00 for ; Mon, 15 Oct 2001 00:05:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:16 +0200 (CEST) Received: (qmail 29881 invoked by uid 0); 13 Oct 2001 10:57:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 13 Oct 2001 10:57:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DAvC330082 for ; Sat, 13 Oct 2001 06:57:12 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 10:55:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DAtNI29809 for f-cpu-list; Sat, 13 Oct 2001 06:55:23 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DAtGC29804 for ; Sat, 13 Oct 2001 06:55:16 -0400 Received: by moria.seul.org (Postfix) id 0FFEB1462FD; Sat, 13 Oct 2001 06:55:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-91.vlt.n.club-internet.fr [195.36.173.91]) by moria.seul.org (Postfix) with ESMTP id 168751462F9 for ; Sat, 13 Oct 2001 06:55:22 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 8A4A1176D for ; Sat, 13 Oct 2001 13:09:21 -0400 (EDT) Message-ID: <3BC87541.8B935734@ifrance.com> Date: Sat, 13 Oct 2001 13:09:21 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> <3BC3B798.4214C310@ifrance.com> <3BC3833E.76F0C1B0@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <...> > > Yep, you must insert a delay so you must at least stop the current flow > the "current flow" can't be stopped once it is "issued" (sent to the EUs > and inserted in the writeback queue). The "slot" is detected at decode > stage and delayed at issue stage and before (decode and stage). > Otherwise, we would need to insert heavier and slower pipe registers > all over the chip and reduce the frequency :-/ > > > or you could try to predict the cas e (but i wait an algorythme for > > that). > it's a simple lookup table. > IE : > - when you see opcode = OP_ADD with 64-bit data and no carry (2r1w) > - when you see that all the required registers are available (either > in R7 or on the Xbar) > - when you see that there is at least one free slot available in 3 cycles > in the future > That's the last point the problem, how do you do that ? For me it's an allocation (schedule) algorythme, a typical np hard problem. > => then you can issue the instruction (ask another instruction from the > fetcher + validate the ASU + mark the destination register as "dirty" > + allocate the slot in the scheduling queue). > So you continue or stop the flow :D > IF opcode=OP_ADD AND ( source or destination register is not ready > OR no free slot in 3 cycles) then : delay 1 cycle and try again. > > I don't know if you accept this as an "algorithm" but it's what > it does and you can see that we need 1 LUT and 1 scheduling queue. > For the first FC0s, i am merging the "register scoreboard" with > the queue, but i will use another technique for superscalar cores. > Yes it's an algorythme but not enough precise ! > > In the first case, i need a signal to stop the pipeline (or stop > > to produice output) to insert an empty slot. > The "slot" is inserted at decode/issue stage. the rest of the > units can do their work without caring, as long as their latency > is deterministic (and can be encoded in the opcode LUT which > also tells the issue stage which flags are meaningful for the decision > whether to issue or not). > So you'r enter all the information in the lookup table (wich register are in use at what level, the different latency of the unit, the different thoughtput, the type of unit,... ). I think it's a bit to much ! > > nicO > WHYGEE, going to sleep, now :-) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Oct 13 19:19:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNl-0001WO-00 for ; Mon, 15 Oct 2001 00:05:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:17 +0200 (CEST) Received: (qmail 32342 invoked by uid 0); 13 Oct 2001 11:07:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Oct 2001 11:07:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DB7co30460 for ; Sat, 13 Oct 2001 07:07:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 11:06:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DB5wN30195 for f-cpu-list; Sat, 13 Oct 2001 07:05:58 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DB5qC30192 for ; Sat, 13 Oct 2001 07:05:52 -0400 Received: by moria.seul.org (Postfix) id 074881462FD; Sat, 13 Oct 2001 07:05:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-91.vlt.n.club-internet.fr [195.36.173.91]) by moria.seul.org (Postfix) with ESMTP id 3398A1462F9 for ; Sat, 13 Oct 2001 07:05:58 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1080F176D for ; Sat, 13 Oct 2001 13:19:57 -0400 (EDT) Message-ID: <3BC877BC.27849E98@ifrance.com> Date: Sat, 13 Oct 2001 13:19:56 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <20011010143223.54223@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : <...> > It would be easier if synthesis tools (in particular, Synopsys) hadn't > so many restrictions -- I can't put multiple registers inside a single > process, for instance. That's normal ! if you do that you introduice an underlying FSM. So you would use behavioural compiler (bc_shell, instead of dc_shell). It's much longer to compile but could work ! beaviroural compiler aren't cycle accurate, the compiler try to find a virtual clock which are big step of the real clock or completly free compare to it. nicO <...> > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Oct 13 19:23:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNl-0001WO-01 for ; Mon, 15 Oct 2001 00:05:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:17 +0200 (CEST) Received: (qmail 18649 invoked by uid 0); 13 Oct 2001 11:10:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 13 Oct 2001 11:10:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DBAcJ30761 for ; Sat, 13 Oct 2001 07:10:39 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 11:09:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DB94M30483 for f-cpu-list; Sat, 13 Oct 2001 07:09:04 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DB8wC30480 for ; Sat, 13 Oct 2001 07:08:58 -0400 Received: by moria.seul.org (Postfix) id D222F1462FD; Sat, 13 Oct 2001 07:09:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-91.vlt.n.club-internet.fr [195.36.173.91]) by moria.seul.org (Postfix) with ESMTP id 562A01462F9 for ; Sat, 13 Oct 2001 07:09:05 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 4C539176D for ; Sat, 13 Oct 2001 13:23:05 -0400 (EDT) Message-ID: <3BC87879.D770A8C3@ifrance.com> Date: Sat, 13 Oct 2001 13:23:05 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint References: <002c01c151c2$8d801010$29e65982@student.utwente.nl> <3BC4D153.D5BF3296@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <...> > However, there would be one solution to speed up this critical part : > use 3.3V locally (if we use ie a 2.8 or 2.5V technology). 2.5 V technologie will burn at 3.3 V ... nicO > > Marco > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Oct 13 19:32:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNm-0001WO-00 for ; Mon, 15 Oct 2001 00:05:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:18 +0200 (CEST) Received: (qmail 14962 invoked by uid 0); 13 Oct 2001 11:20:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Oct 2001 11:20:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DBKHY31093 for ; Sat, 13 Oct 2001 07:20:18 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 11:18:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DBImo30823 for f-cpu-list; Sat, 13 Oct 2001 07:18:48 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DBIgC30820 for ; Sat, 13 Oct 2001 07:18:42 -0400 Received: by moria.seul.org (Postfix) id 744271462FD; Sat, 13 Oct 2001 07:18:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas23-91.vlt.n.club-internet.fr [195.36.173.91]) by moria.seul.org (Postfix) with ESMTP id D565D1462F9 for ; Sat, 13 Oct 2001 07:18:48 -0400 (EDT) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 748F4176D for ; Sat, 13 Oct 2001 13:32:48 -0400 (EDT) Message-ID: <3BC87AC0.1FD8E88A@ifrance.com> Date: Sat, 13 Oct 2001 13:32:48 -0400 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] question to shifting unit References: <20011010175325.21787@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Wed, Oct 10, 2001 at 05:25:12PM +0200, Andreas Romeyke wrote: > [...] > > Erm, why we use parallel shifting than > > use registers/acummulation instead? > > > > I see, that a shift of 3 or more needs more cycles than parallel-shifting, > > but often we need a shift of one or two. > > Hmm... we could add single-bit shift instructions that need one cycle, > and do the multi-bit shifts in 2 cycles. > To extract bit field we need to do a shift then a mask (so a 3r1w operation), it could be done using 2 instructions but 1 instruction will reduice the register bank pressure and maybe reduice the overall latency, the last stage will be a simple and. s&m 4, 3, R1, R2 So r2(3 downto 0) = r1(7 downto 4) Comments ? nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Oct 13 16:10:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNo-0001WO-00 for ; Mon, 15 Oct 2001 00:05:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:20 +0200 (CEST) Received: (qmail 13687 invoked by uid 0); 13 Oct 2001 14:04:57 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 13 Oct 2001 14:04:57 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DE4tN00406 for ; Sat, 13 Oct 2001 10:04:55 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 14:03:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DE3Ix32606 for f-cpu-list; Sat, 13 Oct 2001 10:03:18 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DE3CC32603 for ; Sat, 13 Oct 2001 10:03:13 -0400 Received: by moria.seul.org (Postfix) id F3C0F1462FD; Sat, 13 Oct 2001 10:03:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by moria.seul.org (Postfix) with ESMTP id C14771462F9 for ; Sat, 13 Oct 2001 10:03:19 -0400 (EDT) Received: from computer ([208.60.244.161]) by imf13bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011013140416.RZMB20769.imf13bis.bellsouth.net@computer>; Sat, 13 Oct 2001 10:04:16 -0400 Message-ID: <000c01c153f0$d683c1a0$a1f43cd0@computer> From: "Richard E. Hartny" To: Cc: Subject: [f-cpu] Shifting Unit Date: Sat, 13 Oct 2001 09:10:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C153C6.ECD38640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C153C6.ECD38640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a comment that may or may not be of use. A shift of one to eight is one logic level; A shift of eight to sixteen requires an additional logic level; A shift of seventeen to 32 requires an additional logic level; And a shift of 33 tp 64 requires one additional logic level; As you can see; it is straight binary progression. Hope this helps some. Regards; Dick Hartney ------=_NextPart_000_0009_01C153C6.ECD38640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a comment that may or may not be = of=20 use.
 
A shift of one to eight is one logic=20 level;
 
A shift of eight to sixteen requires an = additional=20 logic level;
 
A shift of seventeen to 32 requires an = additional=20 logic level;
 
And a shift of 33 tp 64 requires one = additional=20 logic level;
 
As you can see; it is straight binary=20 progression.
 
Hope this helps some.
 
Regards;
Dick Hartney
------=_NextPart_000_0009_01C153C6.ECD38640-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Oct 13 15:34:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNs-0001WO-01 for ; Mon, 15 Oct 2001 00:05:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:24 +0200 (CEST) Received: (qmail 31668 invoked by uid 0); 13 Oct 2001 22:15:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx021-rz3) with SMTP; 13 Oct 2001 22:15:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DMFST07786 for ; Sat, 13 Oct 2001 18:15:29 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 22:13:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DMDdX07501 for f-cpu-list; Sat, 13 Oct 2001 18:13:39 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DMDXC07498 for ; Sat, 13 Oct 2001 18:13:33 -0400 Received: by moria.seul.org (Postfix) id 22369146671; Sat, 13 Oct 2001 18:13:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a091.home.uni-hannover.de [130.75.232.91]) by moria.seul.org (Postfix) with ESMTP id 2D3EF146670 for ; Sat, 13 Oct 2001 18:13:34 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00475; Sat, 13 Oct 2001 15:34:48 +0200 Message-ID: <20011013153448.31924@thrai.stud.uni-hannover.de> Date: Sat, 13 Oct 2001 15:34:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] question to shifting unit References: <20011010175325.21787@thrai.stud.uni-hannover.de> <3BC87AC0.1FD8E88A@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BC87AC0.1FD8E88A@ifrance.com>; from nicO on Sat, Oct 13, 2001 at 01:32:48PM -0400 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Oct 13, 2001 at 01:32:48PM -0400, nicO wrote: [...] > To extract bit field we need to do a shift then a mask (so a 3r1w > operation), it could be done using 2 instructions but 1 instruction will > reduice the register bank pressure and maybe reduice the overall > latency, the last stage will be a simple and. It's better to do that with two shifts (instead of shift+mask) because you can handle signed bit fields, too. Besides that, the F-CPU instruction format doesn't allow two immediate operands. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 14 02:56:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNt-0001WO-00 for ; Mon, 15 Oct 2001 00:05:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:25 +0200 (CEST) Received: (qmail 27027 invoked by uid 0); 13 Oct 2001 23:58:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 13 Oct 2001 23:58:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DNwGf09480 for ; Sat, 13 Oct 2001 19:58:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 23:56:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DNu8b08710 for f-cpu-list; Sat, 13 Oct 2001 19:56:08 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DNtpC08677 for ; Sat, 13 Oct 2001 19:55:51 -0400 Received: by moria.seul.org (Postfix) id A473D146307; Sat, 13 Oct 2001 19:55:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 1CECB146305 for ; Sat, 13 Oct 2001 19:55:53 -0400 (EDT) Received: from f-cpu.org (nas20-3.kdl.n.club-internet.fr [213.44.18.3]) by relay-1v.club-internet.fr (Postfix) with ESMTP id CCD8E169F for ; Sun, 14 Oct 2001 01:55:41 +0200 (CEST) Message-ID: <3BC8E2C4.3BC5957B@f-cpu.org> Date: Sun, 14 Oct 2001 01:56:36 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint References: <002c01c151c2$8d801010$29e65982@student.utwente.nl> <3BC4D153.D5BF3296@f-cpu.org> <3BC87879.D770A8C3@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > <...> > > However, there would be one solution to speed up this critical part : > > use 3.3V locally (if we use ie a 2.8 or 2.5V technology). > 2.5 V technologie will burn at 3.3 V ... i guess so, but i wouldn't forget to put a power regulator :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 14 02:56:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNt-0001WO-01 for ; Mon, 15 Oct 2001 00:05:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:25 +0200 (CEST) Received: (qmail 6472 invoked by uid 0); 13 Oct 2001 23:58:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Oct 2001 23:58:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DNwG609479 for ; Sat, 13 Oct 2001 19:58:16 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 23:56:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DNu3x08694 for f-cpu-list; Sat, 13 Oct 2001 19:56:03 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DNtsC08684 for ; Sat, 13 Oct 2001 19:55:55 -0400 Received: by moria.seul.org (Postfix) id 138FE146306; Sat, 13 Oct 2001 19:56:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 9E4E5146305 for ; Sat, 13 Oct 2001 19:56:00 -0400 (EDT) Received: from f-cpu.org (nas20-3.kdl.n.club-internet.fr [213.44.18.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B8EA71710 for ; Sun, 14 Oct 2001 01:55:46 +0200 (CEST) Message-ID: <3BC8E2CA.708ABAAC@f-cpu.org> Date: Sun, 14 Oct 2001 01:56:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifting Unit References: <000c01c153f0$d683c1a0$a1f43cd0@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, > "Richard E. Hartny" wrote: > > I have a comment that may or may not be of use. > > A shift of one to eight is one logic level; > > A shift of eight to sixteen requires an additional logic level; > > A shift of seventeen to 32 requires an additional logic level; > > And a shift of 33 tp 64 requires one additional logic level; > > As you can see; it is straight binary progression. > > Hope this helps some. Thank you. I will add some other facts : * if you use a 2-1 mux for each shift level, you need 2 levels of metal connexions and 6 levels. If you use a 4-1 mux, you need 3 levels but 4 metals. At this point, the first level (shift by 0 to 3) is relatively easy but the other stages are getting very large. * the surface used by a simple barrel shifter (like what we speak about) is proportional to O(n*log2(n)). Doing a small shift is relatively easy, but large amounts use a lot of room because the wires have a width. If you multiply the wire width (plus the minimum spacing between them) by the length, you realise that the surface is getting meaningful. The wire length is proportional to the shift amount and the 32-bit shift takes almost as much surface as all the preceding stages altogether. The signals are thus slower and weaker, more prone to alteration by interference. * I am still trying to figure a way to perform the 16-bit and 32-bit shifts with intermediate stages. The signals would be stronger and the propagation time reduced. Curiously, for a wide shifter, the more stages -> the faster... And maybe we can add a pipeline flip-flop if it's too slow. * Michael said he was designing the shifter as two shift units, one shifts left (by 32 bits i think) and the other shifts right. By playing with the recombinations step (yet another mux), we can shift 64-bit words left or right by any amount. * shift and memory : the instruction i recently proposed (simply called "sh") has another very important use : aligning words before/after memory access (explicitely, with explicit instructions). For example, if you want to store a 64-bit register to a non-aligned address, use the pointer's LSB as the shift amount for the data and issue the shift. Because the shift amount is truncated to the meaningful LSB (ie : 5 bits are kept if we shift 32-bit words), we have to shift the pointer left by 3 to get the byte aligned pointer. * The instruction i recently proposed was 2r2w : the result was an "expanded" version of the source data, without the OR of the two shifter's output (it is only swapped depending on the shift direction). If we are going to use this instruction for helping the store instruction with non-aligned data, we can dot the reverse : a 3r1w would do the reverse for a load instruction. This version would take two consecutive data (got with two consecutive loads), shift and combine the result. For example, if a 64-bit word is stored across a 8-byte boundary, we can reconstruct it with 2 loads and 1 shift. >From this point of view, these shifter instructionw can be named "align" and "unalign". What do you think about that ? > Regards; > Dick Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS; hope you're having/you had fun at the MPF ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 14 02:56:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stNu-0001WO-00 for ; Mon, 15 Oct 2001 00:05:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:26 +0200 (CEST) Received: (qmail 27842 invoked by uid 0); 13 Oct 2001 23:58:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 13 Oct 2001 23:58:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9DNwI409491 for ; Sat, 13 Oct 2001 19:58:19 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 13 Oct 2001 23:56:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9DNtxu08687 for f-cpu-list; Sat, 13 Oct 2001 19:55:59 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9DNtpC08678 for ; Sat, 13 Oct 2001 19:55:51 -0400 Received: by moria.seul.org (Postfix) id AC8B8146308; Sat, 13 Oct 2001 19:55:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 246B1146306 for ; Sat, 13 Oct 2001 19:55:54 -0400 (EDT) Received: from f-cpu.org (nas20-3.kdl.n.club-internet.fr [213.44.18.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id C984A16D7 for ; Sun, 14 Oct 2001 01:55:43 +0200 (CEST) Message-ID: <3BC8E2C7.6F7C8C6A@f-cpu.org> Date: Sun, 14 Oct 2001 01:56:39 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] freeze signal References: <200110081342.36f5@lh00.opsion.fr> <20011008184207.39346@thrai.stud.uni-hannover.de> <3BC3B798.4214C310@ifrance.com> <3BC3833E.76F0C1B0@f-cpu.org> <3BC87541.8B935734@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > <...> > > > or you could try to predict the case (but i wait an algorythme for > > > that). > > it's a simple lookup table. > > IE : > > - when you see opcode = OP_ADD with 64-bit data and no carry (2r1w) > > - when you see that all the required registers are available (either > > in R7 or on the Xbar) > > - when you see that there is at least one free slot available in 3 cycles > > in the future > > That's the last point the problem, how do you do that ? For me it's an > allocation (schedule) algorythme, a typical np hard problem for the current state of the core, the complexity is not overwhelming. If there are extremely long units (such as a 20-cycle multiply, for example), the problem gets heavy but the multiplier takes "only" 6 cycles, it's reasonable. I guess that we will introduce the FP units much later. > > => then you can issue the instruction (ask another instruction from the > > fetcher + validate the ASU + mark the destination register as "dirty" > > + allocate the slot in the scheduling queue). > > So you continue or stop the flow :D The flow is stopped at the decoding and issue stage if the issue conditions are not met. > > IF opcode=OP_ADD AND ( source or destination register is not ready > > OR no free slot in 3 cycles) then : delay 1 cycle and try again. > > > > I don't know if you accept this as an "algorithm" but it's what > > it does and you can see that we need 1 LUT and 1 scheduling queue. > > For the first FC0s, i am merging the "register scoreboard" with > > the queue, but i will use another technique for superscalar cores. > > Yes it's an algorythme but not enough precise ! the LUT contains data about : - whether the instruction requires 0, 1 or 2 write slots - the instruction "uses" the source registers 1, 2 and 3 - the latency - if the instruction uses the condition - *************************** pointer - ****************** is valid etc. You have 8 or 10 bits as input and it outputs some tens of wires, each selecting the associated ressource. During the issue cycle, all the conditions are ORed (combined) together and the result commands the issue signal. When this signal is active, - the next instruction is fetched - the slot is allocated in the scheduling FIFO/queue - the apropriate signal is sent to the EU i guess that it is still cryptic for you. Unfortunately i'm currently sick, tired and have a big headache, so i can't make drawings. I hope to meet you in a few weeks. > > > In the first case, i need a signal to stop the pipeline (or stop > > > to produice output) to insert an empty slot. > > The "slot" is inserted at decode/issue stage. the rest of the > > units can do their work without caring, as long as their latency > > is deterministic (and can be encoded in the opcode LUT which > > also tells the issue stage which flags are meaningful for the decision > > whether to issue or not). > > So you'r enter all the information in the lookup table (wich register > are in use at what level, the different latency of the unit, the > different thoughtput, the type of unit,... ). I think it's a bit to much > ! the LUT is hardwired : you can't say what registers are currently in use. It is the purpose of the scheduling queue. I don't think it's too much either because "if" the instruction set is well designed (when all the OPCODEs are allocated), the decoding must be rather easy (not more than 4 logic levels). > nicO WHYGEE (krank wie ein Tier) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: in the CD i last gave you, there is the file named distro/f-cpu/QDCPOC/qdcpoc2.h which contains the following descrition : /******************** The opcode LUT : ********************/ /* this structure describes the properties and needed informations for each opcode. IT is only a first preliminary version, a lot of things are missing. */ typedef struct { /* latency : indicates which queue entry will be filled */ unsigned int latency_zero : 1; /* nop (could be removed ?) */ unsigned int latency_direct : 1; /* move, loadcons */ unsigned int latency_cycle_1 : 1; /* rop2, inc */ unsigned int latency_cycle_2 : 1; /* ASU */ unsigned int latency_multiply : 1; /* imul (more ports ?) */ unsigned int latency_idiv : 1; /* idiv */ /* opcode format : indicates which fields are necessary before we issue the instruction */ unsigned int need_src0 : 1; unsigned int need_src1 : 1; unsigned int need_src2 : 1; unsigned int need_rw2 : 1; unsigned int need_cond : 1; /* queue reservation : */ unsigned int need_w1 : 1; /* indicate that we want 1 write slot (in this case, src2 is written to either slot0 or slot1) */ unsigned int need_w2 : 1; /* indicate that we want 2 simultaneous write slots (in this case, src2 and rw2 are written to the 2 slots) */ /* use of the constants : it directly drives the Xbar */ unsigned int op_imm8 : 1; unsigned int op_imm16 : 1; /* more will be added as special cases are discovered */ } opcode_lookup_type; opcode_lookup_type opcode_LUT[256], opcode_type; ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 14 05:07:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15stO1-0001WO-00 for ; Mon, 15 Oct 2001 00:05:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Oct 2001 00:05:33 +0200 (CEST) Received: (qmail 27804 invoked by uid 0); 14 Oct 2001 11:35:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 14 Oct 2001 11:35:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9EBZ0l16988 for ; Sun, 14 Oct 2001 07:35:01 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 14 Oct 2001 11:32:51 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9EBWns16710 for f-cpu-list; Sun, 14 Oct 2001 07:32:50 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9EBWgC16707 for ; Sun, 14 Oct 2001 07:32:42 -0400 Received: by moria.seul.org (Postfix) id CAF951462FD; Sun, 14 Oct 2001 07:32:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a058.home.uni-hannover.de [130.75.232.58]) by moria.seul.org (Postfix) with ESMTP id E93421462F9 for ; Sun, 14 Oct 2001 07:32:45 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA24487; Sun, 14 Oct 2001 05:07:58 +0200 Message-ID: <20011014050758.01852@thrai.stud.uni-hannover.de> Date: Sun, 14 Oct 2001 05:07:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifting Unit References: <000c01c153f0$d683c1a0$a1f43cd0@computer> <3BC8E2CA.708ABAAC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3BC8E2CA.708ABAAC@f-cpu.org>; from Yann Guidon on Sun, Oct 14, 2001 at 01:56:42AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Oct 14, 2001 at 01:56:42AM +0100, Yann Guidon wrote: [...] > * Michael said he was designing the shifter as two shift > units, one shifts left (by 32 bits i think) and the other > shifts right. By playing with the recombinations step > (yet another mux), we can shift 64-bit words left or right > by any amount. That's wrong, unfortunately. Both left and right shifters are full 64-bit devices (the reason for this is that I didn't want to add two more rows of 2:1 muxes, for bit reversal). When the core is a rotator instead of the shifter, we can probably drop the second subunit and negate the shift count to reverse the direction. > * shift and memory : the instruction i recently proposed > (simply called "sh") has another very important use : > aligning words before/after memory access (explicitely, > with explicit instructions). For example, if you want to > store a 64-bit register to a non-aligned address, use the > pointer's LSB as the shift amount for the data and issue > the shift. Because the shift amount is truncated to the > meaningful LSB (ie : 5 bits are kept if we shift 32-bit > words), we have to shift the pointer left by 3 to get the byte > aligned pointer. You'll still have to do some masking when the value is going to be stored. This is where the MUX instruction has its use... On the other hand, this kind of operation can also be done with a rotate instead of a double shift, at the same cost (or cheaper -- the double shift variant needs more registers). > * The instruction i recently proposed was 2r2w : the result > was an "expanded" version of the source data, without the OR > of the two shifter's output (it is only swapped depending on > the shift direction). If we are going to use this instruction > for helping the store instruction with non-aligned data, > we can dot the reverse : a 3r1w would do the reverse for > a load instruction. This version would take two consecutive > data (got with two consecutive loads), shift and combine the > result. For example, if a 64-bit word is stored across a > 8-byte boundary, we can reconstruct it with 2 loads and 1 shift. > >From this point of view, these shifter instructionw can be > named "align" and "unalign". What do you think about that ? It's basically the same operation both times (double width left shift), with different parameter and result usage. The only problem is that we need a third input, and an even bigger (and slower) shifter :( It makes more sense to do this in software (load two consecutive words, extract the correct parts with the MUX instruction, rotate the result into place -- et voilà). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Oct 19 02:43:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 15ud1u-0000G2-00 for ; Fri, 19 Oct 2001 19:01:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Oct 2001 19:01:54 +0200 (CEST) Received: (qmail 31938 invoked by uid 0); 18 Oct 2001 23:42:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 18 Oct 2001 23:42:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id f9INgwY07127 for ; Thu, 18 Oct 2001 19:42:58 -0400 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 18 Oct 2001 23:42:07 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id f9INg7n06870 for f-cpu-list; Thu, 18 Oct 2001 19:42:07 -0400 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id f9INg6C06867 for ; Thu, 18 Oct 2001 19:42:06 -0400 Received: by moria.seul.org (Postfix) id 48B7E146306; Thu, 18 Oct 2001 19:42:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 29BF4146305 for ; Thu, 18 Oct 2001 19:42:06 -0400 (EDT) Received: from f-cpu.org (nas25-37.kdl.n.club-internet.fr [213.44.96.37]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7ECDD16B3 for ; Fri, 19 Oct 2001 01:42:03 +0200 (CEST) Message-ID: <3BCF771E.D435132A@f-cpu.org> Date: Fri, 19 Oct 2001 01:43:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] ROP2 layout Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, as a "little exercise", i started to "synthesize" the ROP2 unit using Alliance. In fact, it's mostly a matter of placing and routing because i did the synthesis by hand long ago. I am using Alliance's "portable" cell library and i did some routing attempts : i can probably automate some part of it ("procedural placing" will ease the work). FFs take around one half of the surface (we need 4+1 FF and 5 "logic" cells per row), which corresponds approximately to the time ratio (one half is spent in the wires...). A "normal" ROP2 unit will be 64*50=3200 lambdas high and maybe 2500 lambdas wide. it's already getting big. BTW routing with Alliance is not "yet" OK because even though placing is almost ok (at least it yields working masks), the routing is still performed by a commercial tool (there's a script that wraps around "silicon ensemble"). Yagle seems to work, but parasitic extraction and the likes are not yet ok : i don't know what frequency the circuit can reach. WHYGEE, special reporter in a strange world... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Nov 2 22:00:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 1603vj-0004kF-01 for ; Sat, 03 Nov 2001 17:45:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 03 Nov 2001 17:45:59 +0100 (CET) Received: (qmail 12013 invoked by uid 0); 2 Nov 2001 23:21:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 2 Nov 2001 23:21:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA2NLO314260 for ; Fri, 2 Nov 2001 18:21:24 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 2 Nov 2001 23:20:13 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA2NKC913979 for f-cpu-list; Fri, 2 Nov 2001 18:20:12 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA2NKAj13974 for ; Fri, 2 Nov 2001 18:20:10 -0500 Received: by moria.seul.org (Postfix) id F19B514630A; Fri, 2 Nov 2001 18:20:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a167.home.uni-hannover.de [130.75.232.167]) by moria.seul.org (Postfix) with ESMTP id 6EFA7146309 for ; Fri, 2 Nov 2001 18:19:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA02311; Fri, 2 Nov 2001 22:00:31 +0100 Message-ID: <20011102220031.29936@thrai.stud.uni-hannover.de> Date: Fri, 2 Nov 2001 22:00:31 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Shifter Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=rwEMma7ioTxnRzrJ X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Hi! Here's another version of the shifter. It now uses a 6-stage omega network (in fact, a *reversed* omega network) for bitwise operations. Additional changes: - cleaner, more regular code - since the core is basically a rotate unit, shifts are now performed by `rotate-and-mask'. A second output holds the bits that were lost, giving us `double' shifts for free (but only the 2r2w ones; 3r1w double shifts are not supported). - as a consequence of the implementation, `bitrev' now has a SIMD counterpart, `sbitrev'. `bitrevo' isn't supported. - performs both mixl and mixh (or expandl and expandh) at the same time (2r2w). - can perform either byterev or sdup on two independent input operands (2r2w). I didn't test all extensions; I'd like to see synthesis reports before I go on (maybe this is even slower than the last one). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --rwEMma7ioTxnRzrJ Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-shl-mr-20011102.tar.gz" H4sIAOr/4jsCA+w8aXPiyJL91f4VFY4X0eDmkgC7x4x7B9y2hxiM/cBMj3djgxCiANlC4ukw pn/9ZmaVToQP7OmZmDUR7UZSVmZWXpWZVWiiL/yiOzOLc6eoViqKolTU8oe3/bBa5bBeZx8Y Y0qtRv8zVf4vPhXGDquHlfrh4WFdBSj1sKZ+YPUPP+Dju57mMPZhbugzjZsb4QBsMvnwj/tM svQ/KcLdoW5bE2Naup+NzdfRUCqVA6n3DP2rSlU5RP2DlVSrlSrq/0CtH35glXf9/+mfYpGd GSZnZ8WTq0Fc5bvwJKfn2Y1mWex80P562S0wW/dKoLACA1OpIMRytppy/gsZTMl2pqzM6Psv fOrY/sIt6fYc4fDffaWksiN2IQTNegZfcAbfrSkfs7Nhr9k9P5VwVYC7OWfuguvGxIDH3owz 3+VOcW6P4Y42ApaBWVCK5bnsEzu/6sihNSTRYwvHXtgujOxcnl80/+i3//u0gCi18Vii611e qRGOkhxeh+GWfV9iyqGYZWxUvzds9/49bDX7gAsurnvNK3GFg4MPPOjf9E+anU4EOeh1GPf0 gMhBQEQ9iBGZ2/dAxLXnHIYw1/MnE+bZrPz7r1875dPB0HXk8EMYPuZ6iVWVLB5husOTXwfd 34Y4a6ZZdPe607po9/vEU6ARxnTfcbjlMYebXHN5GnEAeD0zXLbQ9DttygFiYljcJSHugf4c Tfe4Y7ieobOlMfZm7h6zJzgMIQwLHlqayXzLADGzK0HI4ahcj0Dgu+cYumeAMlBExNp+THPA VseeqoCV4PvGdx58d/gUKHPHBUJstPK40CQ70eCSw+RXxMGUO0wbgYCZ7TD+Hx/4AdGqoAEw AQeZsa0xTMmmwRqrqsWR4TFjvjD5HASkIXMFVg2hCRgAD2oEeA8cAISgTdIyhIDmtktobAfN DGToaHMO/Bbo6cRw4PHS8GY0cDkD32C2BbYN7C9MbVViLbxw+MQ3cTJLvHUNIyWDki6gMMlj wawAn+3csRX34rJUQIAdUltSll1/3gLZwJWu6XAtYHIXg/41yu/099NuPppUyD4YAfydE/DM XrI5CrqjSCQm3QeuIwHysZBN22NzCLmI+8txjYxzyO+5NYQ7ugYuHjAGpMCgfBOCc6c3YHOO kcJwKZpgKBizCajSI64c27O91YKXWNM07SU8u9dMX7JQK7AD1PpnlvNmmoeKOSIkCjjfQQ0f qfUDwXMBr+qKKiwJfOC3Fg39rZUvsQsbsC1t3xzHbIYwkSV0VDH7UqnERr5HtCEEuQbGKmPC VrbPZhpYILdsfzpDq3dt39F5wuaVZot8iB01x2MEYS3fFW5VQBNHvQNvEDd9S78DTVXVT/Vj Rf183orpKaYdlKXAKAWrSbwQmVGdnk3aBx04qEHCEWkxbn9gsrYtNA2m57K5MZ1h5PiPb8BU QQCX14gpOS/GmnBHc22LYjbphTSnMXeumSaw6hpTS8oVrEI5YDn1ooWYNGIUxxGixWzlGjp4 7pzPbWeVLwCAtgBBuwET4xL7pjmWYU3Byr2EwQq/Nl0703IDmdC8SHGSlrlKm7DU1bU0vCng R5OaOJxD7J54SxjeIGWjDwNPBgY3MAgwAg/tvQyTp1VshXjgnm+NuUOqQcbcQE/n3QE75xZ3 YMZX/siE6NoxdG6Bi8CMF3jHnYGpj1ZBqD1DHvqSB3ZmA2KKWw3GIcIAjSBahN4vEaLZ03oP 7gGcg0EscFyewqepedHQ0obpR7Mco5Ui7pkNy7vwOI/iE2oXHBctCVGgj3xrX/96Obhmze4N +9bsQQpwfdOgeGjDU4wLYg0BFWAWAPNyIIqu5PJycdo7+RWGNFvtTvv6Bj31rH3dPe332dll Dwzvqtm7bp8MOs0euxr0ri77pyVYnzmyRSb1iIgnpCUHVztPM8zQR29Ase6MjJWc2eE6N3Dd 1sChFqunlYdINNMGE8VphgEMBdnAMAEBvMCWjgH2AmFlTa04PNJsgbUtvVRg9Z/YNUc7heVV 00GffR8RQDpdYC1YgRDyogl1lgoJflGpViDhHvSbOKfdTrvVa/ZumME5b+xiBjPon9JVyfXG Q9OeGvpQUQ5qJUhpGru7QRpwFiWMYAG7gGubD+kxuUZSKhrL7o62RY24YX0bgfl+OVbjq7dY 64PFO8whYPYB2WT2YWmej6o8OmbVBuF9PAeJI8rEou7vRwSewoh5UxzjAMYl0QU09tlngayH WTXF0BCXXAUgvzMx7JMzM+b6I1w5g/wbfTnA6xAOJFZU2NheWiCxChP4wQUcTwcfFaGcFg9Y UOYQXDYS+P305BrcEiigXfnCsO4hCbSdnCSfl+hTKawUQkqqcYiENGBRBzSvMMg+5uCao8/A iXSBNjTHAhuh+6H5nJ1UIFmDJeI1Frotj5BsneAyDSmAC9ERHAgYdHyRRVNeBSFCy7/Gd74C gnj6YTtRJsGBdixPwDxEmH4+4UTKV5nOpMwfEi6h6S2ynAT+ZiZ+bCII/NvkujmRmVgidIg0 M8jVNc+DQOulpxnLruOGyAI2NpDGMBCOTaHstkQavR44ImqN11gQlhF9rLABcy8MOEeQBWBa hQm2Y8+hdCzN8nLx+4areVCKB8ugyGWgdoHFOsyVMAVDQB2XUEq397EI7Q4uWqe9/hDSQBaM x6xgAbaK6/tMLPhBOS01AFKLJWFYHIuugUgwCfFZ86LduRF4w7aBSH4p+qDgkZUc+GwBHFfB cjxfCggFFduco+zBtUWqImoMF2pjnWYUq0l0exyy6XLpdZTtYO6F+dMc4rlAoHNY2MCqkYMY z/3r06urdvecuE7yPNfcOwjc94ZLizwi4Q8ayiAaPuh1aCSYDGIXA9tUbXNYI3odFKdDuQ4T CXmBhRwHSSLFCVv3wxqX2IeEARJXloNAivU9sPNQCmzg6yXrQqJ/cfm1fXZDyG3KLaP12rdM 9GiiK2alE2oXhwvNlViXL2ESrkgMtcWCAxnXhiWD9T1txTzfEun21sHL1MBbwVSO4l4FYus0 +9dDuE+fpGsdCF+NrA4ZDHUaN0FKcdFewArMFAFp4xkEKo1sUGG2CdCIUcFTkBMBH4K9EpjH XIM6/4hVHnAhOma1SlUds6NiPkVF+AbLYEhpZIJKN0qAInLBSmCW5WRzJIUpMO4MMTc2gBLZ NH9UI1lBPa5BRb0UuvGWNmR1rJZChnkBZQRrdKuNDaDrdNfzMgj7sohTCpD4O+MllpuYr8dp /nzMPqcnhwSULOHXGpmgWcJXMjlRt+BEzeKknsmJmsWJmslJdQtOqlmcHGRyUs00yExOaltw Usvi5DCTk1oWJzLl7rcvvsqEhbnAVYyTUoblxZLXDPKfG48OyWIjCbEfFALlbwX2O3VdsExf Wdrc0DHH0p0gmInWj77ScXVJUj25OekE/CWp/STQXzk2psh8XBCUTmAxcmzTlS087OyLbk0a 81XzPIgOaWOvCNTt3r8LDFvsooMtWurs1p8vmIc9IUxVME3D2Ay0MUosAm4oMLMiZedpykEL P4Oy0mCM6muR8ZH+KPTjqur4C9Ht4m6yFJE4s6OOshbuwl2DddiqoD/RfNMTOby7gqxszoC6 7bhZiAKqSUTrsSW2I5GCrQuil/2AGLa9Ngxfr7WUNZeNbzSkYA8FKYBgcwNTBEdb7AapKGYs Ud0bNInFfg+nemthGyI7EymS5WtmQaY2sDYsNI/KoWCf5TpRR6MaQ3+kjGouesHN/km7TbJe iB0UastU3LTZIHss0xUUcDWgJ5Ml2gxxKWWSxXFyi6CAxQkCuvJxspNfKmUQHmI8eUaQCFJC CYotOWyFHrO9mectjsrl5XJZEnt1Y14Wndfy3tZFRFhF0FYa7u9Q25W78b05kQKugrQ+6sBo ls5Bw96Syy7fyLA0aiOMRV5KzWoovzXa2bAXXDYVkCSQwPKW1KrbCzQQSnYp3bate24ZHPDT QIgBiRQ6aMYvZa4/1+6QINNcl88hsDjg7zgQ991K7GTGIaCLAtAUU6X90ahDaFjCmoLtq22T 1pgukcqw2f2aaW/JNDIA7T6d4BHoH5e9TKzqOmgE+VgmRaDdDVhrGQxEsI9kIZKBLns6TRAM RNJKr+O7HIwp1q3E3lDQxBzZ41VGJ5OsOrYZZZj2lE1gaRd1HjbJbFwMsOUF2KkicA1REVLd s7LQDwzavMBlCSKUi0EK7q7EBoNj3xtjUSAKvwiNVq5aIvMVW5dAXnMgLs1ZzsHuE4zzF3n2 Pxe9IG78727AnmA29xDJocFGYm83ru48sA9XVnjTwPXlHsgQz6vY8N0RhFFM8FehTS1n6AwP 7ItAvb8Pz0zbXlD/mMBW7JMARenjI/wuSa4apBNktPGsed6cR/NEcLa0adPEIPU4lNuAB9uT SXG0KipivcSNuP9KikVNyOUlIojd//64aL5nCOn7JuFI8O9w/V0sjsHOERiYoYvqfc80PM/k eyDKGUZNzNvYkZ1/Urhq49VdULFhw5YO1uiwZkHQi/xADxo4kE6aPmgLhwl9TCJTtzhaP4Z2 DJm42R/u8Tr2LeRr29f5a5794f3zBue/uD+EW292DPDl5/9qqqq8n//7q/UPaekQ0mxj4Zsi 89ryKODj5/+UQ7V2gPqv15SqWqkq8LBSr1Xez//9oPN/mWqG4hlKNJ2bJtcs26ejESwOFS0D GPRP7MXKofMguZM8Hh1TUuf8fpby/cX1/HEJaoUiLGWWDas6lCJf3g9VvB+q+MccqkBs/2qP j7Idq3DPlJJKLlKu/FRW60w5OKpVjyp1Jl2EnT4s2L92d01j5GDW1D49PW3sYjWC39KHMjTT jB3KaAHJi7iXQkq7I5r2YGtcHHACW8Ite9x4390J82PkNgDLNSHHBbC1jfowZV570iA6WIXp mqtrUAtFqOWdIVb1W6MG49uMGQxra8TWkYJ8x7BCgPH1l7MboYMiex3dwwuZjNBlYdsKmckn HniaAX+XZTzX56yKUL5EyE3xcCNmQIMf1hXPwzJI3D1Jj3pK9Al+7Ldj6Cm6osjkeGI5YmGN qvY02RfSFUvkYwpwfqwCkgzZb8fRCzQQ42GN7NuqAMvFdIRspJpBmRH0rYIkIduJDnkkezLN jya3pt4MZxZ2GzStwFYr6uamD011Yuey8jBI9CKKxYWjTeda1IQa2pMJoMT+poNEv2ALMQvM QiiNWEEecLk2aLXQPorDYNTFAKGvVjkjj3CalutAqqjAPwNZ2IkaEjs7QUNiBRd4PyY8kPqb LQ9bCnU0epZQo0F3SoHdqfCvSixSxyoB4Hp8Ee8N/XkKqWAao9RJ0jviOJ7sxIjD5agjwc0x q2F3ziBv4Q+YNeIhG3r45Zh16D7ivc1U9M6dgjhuQb+3mGCzHKCj0Xn2SWApYieLQFUEhQHi gbxZpZtq4qaOPcPcLStLTIi4JtQIH2Kwyo6/iMud0Sh3GxjbbZ62BuDbnRJ9VaOv1XwjhkV9 GZb4UOUZQ+PwdArG3TRIQKIT4NyFMmKeIpU8Gm1wIU2TLhRzlUwX2i4Peveg/1cehNuOwvTl NzX89lz3yUDxPOcJB/51voOZwOuT/a185qX+UoD01PpTHYLwSysOjfg5zhF5AqI4liZ8h8jw Rhm3/nZiDncXP0QeOgcoOEwkavvGp0oYXvFKSVypiStpqQlLIK9A6gl3CL2BLC+idpegdpeg dvcpMOjQEZ4cHYNXsuFjEKHJM8s3zXAqoYVLveTw/0+smg8EmmngOUKNjyJjzrLxl1ag/3gb ryqvs3H1pTauCht/EGFQJRt/wo7VhB2vWZb6OstS8sE0nmdZD9nR892w/h7BU9iVjJ3RhRq/ eKPIGSC8i5N6ZtyMj/0bhc2Ubf+wZtjz3UEzDc19li/Q2baEQ7yoi4A1PkkykvgJKcKYwHx/ Bh7hviV7ATEU3bAtUOymXZOOJUyyOgNC0m8g/CdkHMxNAgkauWaBdQvsY+Vj/il23rId9SRD zVzzI/XG8km+tGQAfjfS5xppwiBDM42Z7uNG6qxbhfMDjNTZYKQb2fmzjdRJGym20PNJtrSN zVZ8hYkBKuYe89zjGnOX8IfeyLFwpsd7k7nHiocqKy6Kxb0jtqC3hbwf6/lLzn+4M38yMflB 7ZXvgHr8/Ee1qhyG538OaqqCR0Iqyvv7n37U+Y+kmhkdZS+C58ofneG3PoHgYfKBZXjvBz7e D3y8H/jIOPCR9CQ66fFZnPRQlHIFD30cVQ6Paq856YEP8f1OpfTSKg+C4G+vQbX9gBNawKco QxBeDhbxb+2v17+m35ewu4PLN76Ag2AoKMAqzjlcbMolcoQpneMHQ/FssOXBjdZLh8sfeoBq 6UdcubmPPwExV4w/6KbvgpnkAbCPRDpp3I3gSW/zk2bWo56djQzuZ6IC6Tv8PvPJChw9+1F/ 7C+y7l8YD1m3wTiwv5jxJPi1IQloYmpTzMwHmwStrolYN239ruxwSMLKXLyYybAWvueynG/h 795RwifmXaZEXC+TWSvjLji7UKnvAXb4fgNAGJOebw2a6ZXkeJbDcDK2IRDwonjrA5mai9ze qM9HTda+oQskc13ZChLOIjwE0l9ykD1xM/iB2kFtD565uK2NjjeBMOfD2rWhfYRJceib4K6x l4xw1uIYDIcK/fQ84cDoVeARoCd7zqeA09Om8WNQdBcGYlLeeu3233LLym6ZWdmJIRu2ClsS d3pk6zk14XJj6++2wO62aPwFMwWFLxvRbZXts1bi0abWYHJ3EfkLenW39JsbFmwjwgp1C/Xp MqxPRe/vVvwsBJtapsvj94uCI4noLoILq1XE6dnDPypKDrfPsKubzwO7H5WPEZX4uY27fJJS /NltPoX9sWMd0vgSlSg55pBeY/H6/eiUQaq4Hftsq2xuMLHm60zM87IHlNUNnQpQT8y+KvHO hGhGQGlPkjbdJKgSB1XioNHYoJe5PlqNj66mR6vB6GjvS7ZbQ1r0cI1a2PLdQLYaJ3uYJnsQ bl6EZLMYqGeBBQ9rqYe5JFchXDWCW5u1aIvnUuTXBRC2zzMkEXuWFgn5FRrKccwfkFpok7Gl OZ/s+IsIQtYU9vuBLNz5JLzU89BdJdORkctmeejMAkwwloaKO/XmtlfEesLD8TAXFxnKU+0m 0f96Xq/pz1qGnvL07v5yg+OGKkmCZJ6FM8rdZ52CE4JL9u5sD0rEp1t3rSeeD5543uP3BSjR sXLftvX7d0kQxEjfzxw52DBy8Lq4//DwzLgfDdH1zCH1TStLAvrZycuS0tRY2hKmLF/oB9Ph /UHsfnVzLpMs5I5k4aCjwougLAj3wogowyjIJ/CAWvFLg4Ifvvjs8vr0iDnGAsrqIp0ujm2I TvAdTfJ1uPizUTQyXYZWSGKEYCh+CloYbPCH1+Gz0DcVDJf10CcBi/BJzIUMsd9OKMRXj5yB ECeQpo+wiimIF79Rys1yXHNX+IpDewz5OBYeaBCJHQgxA6LI7wmh2KSQaVIOT849POQD7OLt WYQdyi9qlsw0w0kS2TTPLOJGkriEgb94Nwo+udiShKPi5pvHl1SU1f19IZBYaolY00mlIBA7 3Juj6a1lpwZZXHoc/KU1JOlBOBffB66q+TVUSXGuVlKcj0ddEV5R6Ng0gxodK0h82/CRAqXc QywQa6Ohy03MCl7UucDYSkHsZUPod/mZQ6oxfTwRmZ8KZ4eZCxvt+btcbvbT9vofe5U9FL0Q MSxoLBwa8CzhlCScEkYz9jkBpybh1HBWykECrpqEq4aiUmsJuFoK7qcArqom4OpJuFo4j1py HgdJuHo4j1pyHof/197RNbWRI5/hV0z8Eg+YwmNjY59DrmxwilQtlS0WbiEvLjt4N67zBwUm 61D8+FN363uk8dgHCRAplcQz09KoW+pWq9XdY8LVJR41E4+GBsckipd+TRPOS7+2CeelX8eE 89Lv0ILz0e/IhPPSr2vCeen3wYTz0E8JstTB7tuLt3ELDieuZtO3c8xJvmk6f9gsT4ycZvkK sTyZk+4grQEmdgSrCxNiO2T5FOlTlVz4OlpbLiwWmVV2G0EyvH7JoHO8Nq8XC7Zz9LKyCViN vTxqAtZiL/OZgPvxU3EfsUuK+5o6840xmWMe5hvP1ma+wEevd4XVZyh5xjzFVKbJB1NZJDOH g5ce/nJmM2/qs2FTbZxPPh11e38cf/xw9hukqVKtQIq2pCxKoeWsc5quU06W1Wmn68hK6Tqn n85+oxRadh1RyVnn1FOHV0rX6Xw8O+3+x12HKjnqXJ51oZKzDlZy0ODo/Hdf36hSus7Jx4so ow6rlK7Tvfgd84/56pSTAk6f0d/wJaQTOLbTQLVHl73OaA6758gpZlxCTq/ZXcyjdWoy8Ywv XasmvjRnTS4ZGffh2aVIQoAUeXeAh89NYFI63i2xy4a8PIXLfXXZhus6XMPpLVzU+AVC7sEF ndPCJbox88NZuEbXZDiRhQt0PD4ZLeA37j3p7BUuDcGBJ4ebyjayK8x2u7B6sZY3N3iyNzqK K0XnJYGLQEL2nrqN/Y1zeLo7FzhZyWM/8xmZhsM13jGZrFHJY56rrGZfy36HZ1HOrnR/n7uS WM8xUx2ck5thAED7g6hjExswPxCGk3Nl8MET3Olwjp/pKuJBPnhQ7pI7FU0oZVmi6yLFW+J8 4nOazyOw7QvHBjD7wGwSr8LzN0xhj7NVptC8xU6r/laFxU2/A1aZc3ucYAoYpxmDgXwbfsdp uJgPp+DjpFutbJpK+9VwqGznja3iaLcRb+/TqzlOLoMc+T5QivzrMc8uD6GQdgdQ/2LDoOlf IJILItJwMjHVKugJuxft21oku6n0paQuAJOaA1ApLtWKAKzaeqnoS6L35XFfAcQ1lC0AZPfS ihVAGmoeh0yrdABpKJgcMq1MAqSh2nJIjxrLNBmDFE+AocJGYagghTK6GoYaNuU0pKGAFxIN wyfquHq16o5BSYeCjHVtbVgwuq028xd5HikdmgsE/HCGEjubuiWZVkXbmAwJbyCZ7hjyRN6N 58rey+3EYKmfTFocFtxJ/2K7SPo8ELt3f6/BEhydTfO3cr8tKTM16Wl3hSigm7Unk7iV3cmi 0Us6XR4OeWfiFXs9hE0K1y/UArGMSuIllBcV82/OfG/0jCHY2XXHrYjUPaio9FOmreEGaUMq nuzO/T3fMnEtSNv+YyX6qGlxwNWw6Bb0r2jCFK+ITiVilwIltDZS11BP4wqaoTeBgcC1otdf oqrBkOFuEhz7Fr9JThFACXGHPCEYVcQNWs67/IyZ7lXMyJdzfl/TUNgV9pobLcZ81QRvXcYZ fMiK7bgUXVa0G51YE3F8j0jGJWj7ovChe3TYaTcb+/XaXrUCm6cIp+8OaQB6xcSo2P1weNTu NJr1/b1apYo7KBM+MeEPj7ofGs12Z69W3y8nlaoNn1jwAAt1ABbqFFoaujAxFa54pSMqNrZG e7zoO3IT3nx/s0F/kjL9ScFb/QUiwl8gIhHShLfxW0J4jijjvTFymsCV3fhKNzjUxcUFm7z/ 9K9J91U59f9tKDLpgd/v1o9qh3udarvSTBpmfwlBq7/79aPD2l6nXa0AVVLwDvwAN0ETGz4f PRA7iB2AbxpfaYQheWTShu6tQx6yT5jkOap1qs2kWz/ca1ds8iC+KfIAaYBEafIgviuQB6iz NnlMVcGyt6WOpNPagb0zMM4/dL+axtZoWyo/7IK2Cnisw1eHxQJDmiOlDsGV8Ka6v8/fRLWm N8F0JacvgGtBFIubviJys4h/SeQN4dGzXPHADFJSNqCSNOqUNCNNSZld4tTuXLMp/YRFi1Qm vp4AMmpBmUz0XZhh0HvQbHUPygb3YJjWlKIqlQljOysUIEUnUlZJ0ZEUa5ld4LbYB8PKaly1 NzFeUtxEA+mDZvh8MAyaWi+5muTrJD22+ohjnV9Hd5u2tSZz6OjpCa3N44p7AmNkJ/dVDxGd v0D8Z28+vJ2vHwSaHf+5B2m/zfhP1pFaPcR//uj4TzXM+JUmdjEYTr98RQtiCAkNIaEhJPT/ CAlVzIVxofU8caEen99V40Xx4fRuAjGgPQaknsDFfLhgGFvQqin9cSq6FJFKhZiedf84A43o z4/4BbjBbAYfEUDV8OYOdR4BQee52QA9NPdnQDE10v0mPK0zIu6wv3bYXZtdWEF3Cq8vs8n1 bAof3JEP2Yt1bH0RtRhSq2JqV4yjXTFuNiMeNiMgNisi1hsS642JzQiKzYqK9YbF+uJiMwJj cwfB+qJbfeGt7vhWCnBdNap1xVjVDZFZRU5Fw6fEOft0ZwPnLi6x7IFpRxpenfbIl6Xoc77d YGZjRHQtDZwMC+MARP0MABwG63nyFtDF3ckV8DPKeLZqRsVb+RHE2HLjGgP5/4Wfrtf2r1iz CM9K0S2OFd4BqCJtlEpYU4yIeJP5/qtZj4cKF8eDseyCDIbq9xYl9o9zT75GP7Hxt8XCn8ef 2tHZMdtSv3nzphDHrcjfeXcLbfRZkTX54/YaLXWcLXXWaOnE2dLJGi1dOlu6zN8SG0x/66Jx 6zkb6yXzaIVX7Hpe8T3HVJWT0pyrX+Drlj2uG7jn60bkPCdRj7/rwX3m9J1Prp1iY0FJkk2D k3uuYxMHjjbms97dFMTC8Kr4nTJlbm0teHBTKRK/YpEQbAH0g9bEAZ8kCaDNKpTgqZkDDMWu TiIX9UgSuXk9isBvI4PTKYbNfRLVF5Fa4jwZA9j6KvTNbdYbOKsNctCaR4j1VRyvaAvwEfkP Bn2mlN/8jd+R0ShQiNJJEDRL78LKiz1leiWlwMT4SSbHdyg+WD1Y0IPvPC7LMWA087nDphUC pMaOL9eG79kduCbR/pBJ8M2NCdLDpeNN+tdRkSeCeE/LbSwUO3xGyh17hskXwMusFJ2jQ5mu dZQ0LQ2fVWPpwoPXe/K6TTdqVAf1MLxRj8lbjK72Y+EKRNcNAheaFt5rxnRoSlcJ7wXoVXQj icVJKr9RIQhYqCGZ3vi/JVyTwa3ulkkUtvyCc9y0RGoP+31JRyPvo8+kqSB9r27Yzu1GGAyl gdtwcvvG+OJbySshsm3Tt6PJVYk+HALfMr8asrkAn143sz4sm+5MKBhbFSEYTsDsqfluXlxc FFroeITDh/ZZvvIXC1tbWziFwBKCflFj+BYs236Q4zp7XFCh3WwzOlXJh1VkN+CDX3SOtkCK ARhPeupaCPRX8gXBgmTNxRkN4Aen0QETu6eDutco7s4xx5appvAkQLwUUhWFFNAXEX4fTVXU HyNvcRoDhVFxwzsyB4X2sCwfqsg/M2ctebiBUQQ2ayor7jefZ/jG4JvXYC695HoY7yrxAYT1 GHzWRhGQ2jYVaN777FVKa7+ElNkWAR30fvA1uZ7dyncLHlAvZ8gVOVQsdV96wtdJJ944FKIi LpU4Q+CLAhrK72h0tZGCRmU1A9h+uz5IIA3ZCPa/tZg4ZD8G7Mc/fTbjAMckmt4KME06M/Ws gNsMsQRrKIEzDfsp7popEhw0QmRHGprvDDR1/BDBkZGeIo2NOek4dtCp/rqI2aNozHX1KuPK OIm0RFRSNkXU6RIRdRNEVBBRL0NEvT/wMq8unHZerHAyZTCgawvh1yGkkrItpNrLpFQ/iKkg pl6GmOJsu6Nl6xJjDUEJMEsOokTcllJCNMQJ4JRmhvTQZUFiygKd+7VpoHKMWJ1YWd7mF7gO 2fRU8lcfpeRRRqn8uKNUfmajVF5hlJ7R+gH+k3L9AJOIf/G4mYU9eFg5fsbKQd4vPGqE+M/m 3XyLDPAwNbYd+TbgShqYnXgk+bqeAODq8NMIAfQx14XAaaYQCLvcIAReoxAgFeZXkwVGaJpm uQcXorThnuJzpKzo8OB8n7Sg4P0gL4K8eIbbzZQvnK7u4+GXLm1sGbPBz8V0eYSVXLsQu7V0 I2X3dgHSO2LdXEcK1Nq22o3xLv0EM95TCCXhkJgSSzw+UoklOqvNkEv8MDcIppcpmJYLBq9c yK9GSKbl7GSDqe+LK1DBbvQ/QDY4SKY40lUSwe/66xoWEvmYdAmPLtU+cigfPjbPsfEQ2bKU 9frq7jrDdA3uFoFffzl+zeSbpcdCmB5ZMqxienvlHGUuipaB8RVwn8xvJ7nvZLTIsP1BOHvg vpfDfeVH4r5lanBKCd51rqDwhR4k8VYkdFRdV87kcakCv+M++RrJkXXhodVtg3sfn1074mLw uLwrN1RLBkNuCRSpf0USDh5X/B1nir+vQfwF8fczxd/7gwzmZVsO8qB+XCb+zPju82MxMW/s OcjBV0rLtQWiypEsBSK5r2eohDyRTxCLr0QsVrbSgnH0lwRzqA5esalhqKZkHrZaxr1FU87S AU3F+O7f0l7rjhypXZ9ms7V8tMng48IgvVd85nrTaqNaXmFUl0/jlaTP8TLpE5SyIH2egfRJ 1pM+cCzjOFz2CaEfIX1+gJLyPKSPnZH1dj67htHgX33ftOWOeoT5AsbD+VDJG6CEK5kXZcBo bXo+BhgyfIUSSiihhBJKKKGEEkoooYQSSiihhBJKKKGEEkoooYQSSiihhBLK8y7/A+dlpJUA 8AAA --rwEMma7ioTxnRzrJ-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Nov 3 23:04:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 1603w3-0004kF-00 for ; Sat, 03 Nov 2001 17:46:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 03 Nov 2001 17:46:19 +0100 (CET) Received: (qmail 3222 invoked by uid 0); 3 Nov 2001 15:50:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 3 Nov 2001 15:50:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA3FokC28469 for ; Sat, 3 Nov 2001 10:50:46 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 3 Nov 2001 15:48:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA3FmtQ28145 for f-cpu-list; Sat, 3 Nov 2001 10:48:55 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA3Fmsj28142 for ; Sat, 3 Nov 2001 10:48:54 -0500 Received: by moria.seul.org (Postfix) id CEBE214630A; Sat, 3 Nov 2001 10:48:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas5-199.vlt.n.club-internet.fr [194.158.107.199]) by moria.seul.org (Postfix) with ESMTP id E093F146309 for ; Sat, 3 Nov 2001 10:48:52 -0500 (EST) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E8B731545 for ; Sat, 3 Nov 2001 17:04:42 -0500 (EST) Message-ID: <3BE469FA.D25D3498@ifrance.com> Date: Sat, 03 Nov 2001 17:04:42 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ------ elaborate Shuffle64 -gate_clock Error: Can't determine type of aggregate or concat in routine rotate line 181 in file '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20 011102/eu_shl/shuffle64.vhdl' called from Shuffle64 line 312 in file '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-m r-20011102/eu_shl/shuffle64.vhdl' (HDL-123) No designs were read 0 -------- nicO Michael Riepe a écrit : > > Hi! > > Here's another version of the shifter. It now uses a 6-stage omega > network (in fact, a *reversed* omega network) for bitwise operations. > Additional changes: > > - cleaner, more regular code > - since the core is basically a rotate unit, shifts are now > performed by `rotate-and-mask'. A second output holds the bits > that were lost, giving us `double' shifts for free (but only > the 2r2w ones; 3r1w double shifts are not supported). > - as a consequence of the implementation, `bitrev' now has a > SIMD counterpart, `sbitrev'. `bitrevo' isn't supported. > - performs both mixl and mixh (or expandl and expandh) at > the same time (2r2w). > - can perform either byterev or sdup on two independent > input operands (2r2w). > > I didn't test all extensions; I'd like to see synthesis reports before > I go on (maybe this is even slower than the last one). > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > > ------------------------------------------------------------------------ > Name: fcpu-shl-mr-20011102.tar.gz > fcpu-shl-mr-20011102.tar.gz Type: Unix Tape Archive (application/x-tar) > Encoding: base64 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 4 00:26:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.22 #1 (Debian)) id 160BTw-000095-00 for ; Sun, 04 Nov 2001 01:49:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 04 Nov 2001 01:49:48 +0100 (CET) Received: (qmail 853 invoked by uid 0); 3 Nov 2001 23:26:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 3 Nov 2001 23:26:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA3NQwT21403 for ; Sat, 3 Nov 2001 18:26:58 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 3 Nov 2001 23:25:28 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA3NPSH21001 for f-cpu-list; Sat, 3 Nov 2001 18:25:28 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA3NPPj20994 for ; Sat, 3 Nov 2001 18:25:25 -0500 Received: by moria.seul.org (Postfix) id 1E17814630A; Sat, 3 Nov 2001 18:25:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id C5B82146309 for ; Sat, 3 Nov 2001 18:25:24 -0500 (EST) Received: from f-cpu.org (nas20-23.kdl.n.club-internet.fr [213.44.18.23]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C959F16A7 for ; Sun, 4 Nov 2001 00:25:20 +0100 (CET) Message-ID: <3BE47D3F.6495F365@f-cpu.org> Date: Sun, 04 Nov 2001 00:26:55 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > ------ > elaborate Shuffle64 -gate_clock > Error: Can't determine type of aggregate or concat > in routine rotate line 181 in file > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20 > 011102/eu_shl/shuffle64.vhdl' > called from Shuffle64 line 312 in file > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-m > r-20011102/eu_shl/shuffle64.vhdl' (HDL-123) > No designs were read > 0 > -------- thank you :-D > nicO > > Michael Riepe a écrit : > > > > Hi! > > > > Here's another version of the shifter. It now uses a 6-stage omega > > network (in fact, a *reversed* omega network) for bitwise operations. i don't understand what this means. is a drawing available ? > > Additional changes: > > - cleaner, more regular code this helps ;-) > > - since the core is basically a rotate unit, shifts are now > > performed by `rotate-and-mask'. A second output holds the bits > > that were lost, giving us `double' shifts for free (but only > > the 2r2w ones; 3r1w double shifts are not supported). that's cool enough. > > - as a consequence of the implementation, `bitrev' now has a > > SIMD counterpart, `sbitrev'. `bitrevo' isn't supported. ok. > > - performs both mixl and mixh (or expandl and expandh) at > > the same time (2r2w). > > - can perform either byterev or sdup on two independent > > input operands (2r2w). great ! i'd like to see a "textual" architectural description. The choice of an omega network looks curious to me. > > I didn't test all extensions; I'd like to see synthesis reports before > > I go on (maybe this is even slower than the last one). you have nicO's answer :-) btw, i'm currently trying to (re)write some C code using the Xlib. i search a way to bypass the window manager when the user enters ALT + mouse button/drag ... > > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Nov 3 18:25:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160FNw-0003JU-00 for ; Sun, 04 Nov 2001 05:59:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 04 Nov 2001 05:59:52 +0100 (CET) Received: (qmail 10953 invoked by uid 0); 4 Nov 2001 03:24:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx032-rz3) with SMTP; 4 Nov 2001 03:24:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA43OVI09837 for ; Sat, 3 Nov 2001 22:24:32 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 03:24:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA43O6609556 for f-cpu-list; Sat, 3 Nov 2001 22:24:06 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA43O5j09551 for ; Sat, 3 Nov 2001 22:24:05 -0500 Received: by moria.seul.org (Postfix) id 9319214630A; Sat, 3 Nov 2001 22:24:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id E8655146309 for ; Sat, 3 Nov 2001 22:24:00 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA04452; Sat, 3 Nov 2001 18:25:44 +0100 Message-ID: <20011103182544.64870@thrai.stud.uni-hannover.de> Date: Sat, 3 Nov 2001 18:25:44 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE469FA.D25D3498@ifrance.com>; from nicO on Sat, Nov 03, 2001 at 05:04:42PM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Nov 03, 2001 at 05:04:42PM -0500, nicO wrote: > ------ > elaborate Shuffle64 -gate_clock > Error: Can't determine type of aggregate or concat > in routine rotate line 181 in file > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20 > 011102/eu_shl/shuffle64.vhdl' *argh* Synopsys caught me again :( Here's a quick-and-dirty fix that should work: ======= chainsaw ======= Index: f-cpu/eu_shl/shuffle64.vhdl =================================================================== RCS file: /home/michael/cvsroot/f-cpu/eu_shl/shuffle64.vhdl,v retrieving revision 1.8 diff -u -r1.8 shuffle64.vhdl --- shuffle64.vhdl 2001/11/02 20:07:45 1.8 +++ shuffle64.vhdl 2001/11/03 17:18:08 @@ -148,6 +148,7 @@ alias uu : std_ulogic_vector(U'length-1 downto 0) is U; variable yy : std_ulogic_vector(w-1 downto 0); variable xx : std_ulogic_vector(w/2-1 downto 0); + variable xt : std_ulogic_vector(w/2-1 downto 0); variable cc : std_ulogic_vector(5 downto 0); variable t : std_ulogic; begin @@ -178,7 +179,8 @@ xx := bit_reverse(xx); end if; if i >= 3 then - xx := xx and (w/2-1 downto 0 => uu(i-3)); + xt := (others => uu(i-3)); + xx := xx and xt; end if; yy := omega_1(yy, xx); end loop; ======= chainsaw ======= -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 4 04:43:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160FNx-0003JU-00 for ; Sun, 04 Nov 2001 05:59:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 04 Nov 2001 05:59:53 +0100 (CET) Received: (qmail 18620 invoked by uid 0); 4 Nov 2001 03:57:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 4 Nov 2001 03:57:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA43vVU12285 for ; Sat, 3 Nov 2001 22:57:31 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 03:57:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA43v2g11994 for f-cpu-list; Sat, 3 Nov 2001 22:57:02 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA43v0j11984 for ; Sat, 3 Nov 2001 22:57:00 -0500 Received: by moria.seul.org (Postfix) id 5F5DB14630A; Sat, 3 Nov 2001 22:56:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id 873AF146309 for ; Sat, 3 Nov 2001 22:56:57 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA00559; Sun, 4 Nov 2001 04:43:40 +0100 Message-ID: <20011104044340.52796@thrai.stud.uni-hannover.de> Date: Sun, 4 Nov 2001 04:43:40 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <3BE47D3F.6495F365@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE47D3F.6495F365@f-cpu.org>; from Yann Guidon on Sun, Nov 04, 2001 at 12:26:55AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Nov 04, 2001 at 12:26:55AM +0100, Yann Guidon wrote: [...] > > > Here's another version of the shifter. It now uses a 6-stage omega > > > network (in fact, a *reversed* omega network) for bitwise operations. > > i don't understand what this means. > is a drawing available ? I can also render you a small MPEG movie ;) [...] > i'd like to see a "textual" architectural description. > The choice of an omega network looks curious to me. Didn't you suggest that a while ago? [...] > btw, i'm currently trying to (re)write some C code using the Xlib. > i search a way to bypass the window manager when the user enters > ALT + mouse button/drag ... You mean, you want the events delivered to your client no matter where the pointer is, until the button is released? Use XGrabPointer(). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Nov 4 18:11:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wun-0000Fg-00 for ; Mon, 05 Nov 2001 00:42:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:42:57 +0100 (CET) Received: (qmail 19222 invoked by uid 0); 4 Nov 2001 10:56:14 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 4 Nov 2001 10:56:14 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4AuDo32345 for ; Sun, 4 Nov 2001 05:56:14 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 10:55:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4Atjx32068 for f-cpu-list; Sun, 4 Nov 2001 05:55:45 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4Athj32064 for ; Sun, 4 Nov 2001 05:55:43 -0500 Received: by moria.seul.org (Postfix) id 58B2A14630A; Sun, 4 Nov 2001 05:55:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas25-114.vlt.n.club-internet.fr [195.36.224.114]) by moria.seul.org (Postfix) with ESMTP id 643B1146309 for ; Sun, 4 Nov 2001 05:55:40 -0500 (EST) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0641A1791 for ; Sun, 4 Nov 2001 12:11:32 -0500 (EST) Message-ID: <3BE576C4.B8F349F0@ifrance.com> Date: Sun, 04 Nov 2001 12:11:32 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Humm, it's look like a patch... So how do you use it ? *<:-& (patch ...???) nicO Michael Riepe a écrit : > > On Sat, Nov 03, 2001 at 05:04:42PM -0500, nicO wrote: > > ------ > > elaborate Shuffle64 -gate_clock > > Error: Can't determine type of aggregate or concat > > in routine rotate line 181 in file > > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20 > > 011102/eu_shl/shuffle64.vhdl' > > *argh* Synopsys caught me again :( > Here's a quick-and-dirty fix that should work: > > ======= chainsaw ======= > Index: f-cpu/eu_shl/shuffle64.vhdl > =================================================================== > RCS file: /home/michael/cvsroot/f-cpu/eu_shl/shuffle64.vhdl,v > retrieving revision 1.8 > diff -u -r1.8 shuffle64.vhdl > --- shuffle64.vhdl 2001/11/02 20:07:45 1.8 > +++ shuffle64.vhdl 2001/11/03 17:18:08 > @@ -148,6 +148,7 @@ > alias uu : std_ulogic_vector(U'length-1 downto 0) is U; > variable yy : std_ulogic_vector(w-1 downto 0); > variable xx : std_ulogic_vector(w/2-1 downto 0); > + variable xt : std_ulogic_vector(w/2-1 downto 0); > variable cc : std_ulogic_vector(5 downto 0); > variable t : std_ulogic; > begin > @@ -178,7 +179,8 @@ > xx := bit_reverse(xx); > end if; > if i >= 3 then > - xx := xx and (w/2-1 downto 0 => uu(i-3)); > + xt := (others => uu(i-3)); > + xx := xx and xt; > end if; > yy := omega_1(yy, xx); > end loop; > ======= chainsaw ======= > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 4 05:42:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wus-0000Fg-00 for ; Mon, 05 Nov 2001 00:43:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:02 +0100 (CET) Received: (qmail 24806 invoked by uid 0); 4 Nov 2001 14:25:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx026-rz3) with SMTP; 4 Nov 2001 14:25:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4EPhE06787 for ; Sun, 4 Nov 2001 09:25:43 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 14:25:19 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4EPJD06509 for f-cpu-list; Sun, 4 Nov 2001 09:25:19 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4EPIj06506 for ; Sun, 4 Nov 2001 09:25:18 -0500 Received: by moria.seul.org (Postfix) id 63E3014630A; Sun, 4 Nov 2001 09:25:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id 32921146309 for ; Sun, 4 Nov 2001 09:25:15 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA00795; Sun, 4 Nov 2001 05:42:15 +0100 Message-ID: <20011104054215.64496@thrai.stud.uni-hannover.de> Date: Sun, 4 Nov 2001 05:42:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <3BE47D3F.6495F365@f-cpu.org> <20011104044340.52796@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20011104044340.52796@thrai.stud.uni-hannover.de>; from Michael Riepe on Sun, Nov 04, 2001 at 04:43:40AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Nov 04, 2001 at 04:43:40AM +0100, I wrote: [...] > You mean, you want the events delivered to your client no matter where > the pointer is, until the button is released? Use XGrabPointer(). Umh... sorry, 'twas late. XGrabButton() was the function I meant (so-called "passive grab"). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 4 17:20:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wuw-0000Fg-01 for ; Mon, 05 Nov 2001 00:43:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:06 +0100 (CET) Received: (qmail 27522 invoked by uid 0); 4 Nov 2001 16:19:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 4 Nov 2001 16:19:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4GJWw13390 for ; Sun, 4 Nov 2001 11:19:32 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 16:18:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4GIxq13086 for f-cpu-list; Sun, 4 Nov 2001 11:18:59 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4GIvj13081 for ; Sun, 4 Nov 2001 11:18:57 -0500 Received: by moria.seul.org (Postfix) id 542D914630A; Sun, 4 Nov 2001 11:18:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2A969146309 for ; Sun, 4 Nov 2001 11:18:56 -0500 (EST) Received: from f-cpu.org (nas20-6.kdl.n.club-internet.fr [213.44.18.6]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B218016C2 for ; Sun, 4 Nov 2001 17:18:53 +0100 (CET) Message-ID: <3BE56ACB.54EF728D@f-cpu.org> Date: Sun, 04 Nov 2001 17:20:27 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <3BE47D3F.6495F365@f-cpu.org> <20011104044340.52796@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Sun, Nov 04, 2001 at 12:26:55AM +0100, Yann Guidon wrote: > [...] > > > > Here's another version of the shifter. It now uses a 6-stage omega > > > > network (in fact, a *reversed* omega network) for bitwise operations. > > i don't understand what this means. > > is a drawing available ? > I can also render you a small MPEG movie ;) theold good PNG+HTML way are enough, i think, unless you have something really complex :-) > [...] > > i'd like to see a "textual" architectural description. > > The choice of an omega network looks curious to me. > Didn't you suggest that a while ago? I have analysed it a bit but the "routing" algorithm doesn't seem straightforward... I preferred to investigate networks that allow better signal integrity on the wire. Think about it : Omega network stages have 2 wires that cross 1/2 of the shift circuit. This means that every stage adds a "worst case" latency (concerning the timing). I tried to find a simpler network where each stage is regular, even if the stages are not like each others. > [...] > > btw, i'm currently trying to (re)write some C code using the Xlib. > > i search a way to bypass the window manager when the user enters > > ALT + mouse button/drag ... > You mean, you want the events delivered to your client no matter where > the pointer is, until the button is released? Use XGrabPointer(). i figured it out tonight. i d/l the docs for X11R6.6 while reading some online docs. however i still have to code it. > On Sun, Nov 04, 2001 at 04:43:40AM +0100, I wrote: > [...] > > You mean, you want the events delivered to your client no matter where > > the pointer is, until the button is released? Use XGrabPointer(). > Umh... sorry, 'twas late. XGrabButton() was the function I meant > (so-called "passive grab"). probably but i think that XGrabPointer() does the trick because i want to use all 3 buttons. i would like to rewrite the GNL interface (in Xlib) in a much cleaner way. so i also borrowed some books from the library in Jussieu : that's probably the only cool thing when you're a student ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 4 15:48:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wuy-0000Fg-01 for ; Mon, 05 Nov 2001 00:43:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:08 +0100 (CET) Received: (qmail 16719 invoked by uid 0); 4 Nov 2001 18:55:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx002-rz3) with SMTP; 4 Nov 2001 18:55:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4ItVS17740 for ; Sun, 4 Nov 2001 13:55:31 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 18:54:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4IsqD17321 for f-cpu-list; Sun, 4 Nov 2001 13:54:52 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4Ispj17316 for ; Sun, 4 Nov 2001 13:54:51 -0500 Received: by moria.seul.org (Postfix) id BB74914630A; Sun, 4 Nov 2001 13:54:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a233.home.uni-hannover.de [130.75.232.233]) by moria.seul.org (Postfix) with ESMTP id EF855146309 for ; Sun, 4 Nov 2001 13:54:48 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00635; Sun, 4 Nov 2001 15:48:38 +0100 Message-ID: <20011104154838.26446@thrai.stud.uni-hannover.de> Date: Sun, 4 Nov 2001 15:48:38 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE576C4.B8F349F0@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE576C4.B8F349F0@ifrance.com>; from nicO on Sun, Nov 04, 2001 at 12:11:32PM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Nov 04, 2001 at 12:11:32PM -0500, nicO wrote: > Humm, it's look like a patch... So how do you use it ? *<:-& > (patch ...???) It *is* a patch :) To apply it: save e-mail to disk cd to the directory where shuffle64.vhdl is patch -p0 "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 4 15:46:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wuz-0000Fg-00 for ; Mon, 05 Nov 2001 00:43:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:09 +0100 (CET) Received: (qmail 2494 invoked by uid 0); 4 Nov 2001 18:55:44 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 4 Nov 2001 18:55:44 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4Itj217881 for ; Sun, 4 Nov 2001 13:55:45 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 18:55:16 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4ItGb17511 for f-cpu-list; Sun, 4 Nov 2001 13:55:16 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4ItEj17498 for ; Sun, 4 Nov 2001 13:55:14 -0500 Received: by moria.seul.org (Postfix) id CA88014630A; Sun, 4 Nov 2001 13:55:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a233.home.uni-hannover.de [130.75.232.233]) by moria.seul.org (Postfix) with ESMTP id E0BD1146309 for ; Sun, 4 Nov 2001 13:54:53 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00625; Sun, 4 Nov 2001 15:46:13 +0100 Message-ID: <20011104154613.08306@thrai.stud.uni-hannover.de> Date: Sun, 4 Nov 2001 15:46:13 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Omega Network Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=6c2NcOVqGQ03X4Wi X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Hi y'all! To clarify the `reversed omega network' issue: it's just an omega network with inputs and outputs swapped (see picture 1). You may ask, "what's the difference?" It's not visible in the picture, but there is a one important difference -- if the "forward" omega net is used for bit shifting, the control logic for the last stage is minimal while that for the first stage is huge. So I reversed the net, and now I have minimal logic in the first stage, and the more hairy decoders at the end :) Both versions can do the basic operations we need: rotate left/right and/or bit reversal (see picture 2). In contrast to other implementations, the omega net also supports the SIMD versions of these operations, with almost no overhead. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --6c2NcOVqGQ03X4Wi Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="revomega.gif" R0lGODdhDQNkAfAAAAAAAP///ywAAAAADQNkAQAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHjIAqAIYLOY4OgCCaGIIBkjSYkItcjJiGO5wNmY eQCqYqq5QxqweulZ6RqxSvkqM1ubukSKaotbWdsKE+y7Epz76WvcAkr8SKL863zTCn08dJuj PNycSD35zG09s00jWvpQrZHOChweibsu7oONzEA+bukef7EvX9xMK9MuePnMsYPGaNYvgZ0Y eoJk0BFDA6jaYbqY0BxE/oevJHY0eM7fEXoUPTostTFjSVYob1UEmPHhx0cFMXJTGbIkR40n D37E2VOkMJgrRUWUyW6lUm1KWS5F+hRl1KJQndK8KjUpVa0DpyadqDWaUCJdswbMyhXpWbBs iWlTa3Lm16pgFdA1Szev17Nh3Y018Van4LQLO+K1N7jqXLRQ6RWkaI8g2rRynZYdWPne3yAN xeo03HSuXJyfJ5vGK7OxRdCEQyUOzbevV8pi/W4GF7np5YaY7DIVnLpT2MWtZ39tQK1y8a3D Bw8v6/n2PMW8gbYU7vJ659Cn946uzrolYuCfjbZr7ViybekiAvf97hs2aWlFucs/uLxu6dye /tNf9RgNdO/Fx950jLlFmjHJKaYbgvxBp99ssdF3XHP3AfgcgyAVeEoymcHnm3+uLWRfcxJZ JaJU7h1Ym4cJWVUcSZpxqEOKzpxHIImarchigyWCFGFOiTmoI4o4JmchjSXs+KFzLBH5m3j4 nbPglBlyF6SJygVpUouTCViikuUcqZCVZs4Hl0XdWQjhd8DAeNiIUuajZUxfasigmLjd2SN+ O2kHUI4YnghZoXFqeRqShyoopE9gcrmenv9ghaGh4unH16B58tknZpRhxouHl6aGYqN1KZqk pCFsaF5AoAKqWoh2FUZiTi7+9JOUsFxH6367wkkYq8L9quqY2flE/iGvyELm0mrVCOtqTLjC apyZlgJZJrBHeepksZxhVUU/o3irqmTkyuONFeLWsO651qTr7jG9YdFuLPEqOe+98m6obqS9 6CvmsAAPTHDBBh+McMIKL8xwww4/DHHEEk9MccUWX4xxxhpvzPEh4H0MMshThExyyfUCYXLK H/+gcsvbReFyzCezLLPL5/q7Ac5C6JwBzygXwzLQUvjMz8hCe0u0BUn3sDQFTatyNA9PSzB1 NlE/UfU35GaNjtGneJ0C1+1d7YTYyIGNgtmFqC3nJmQ3wfas87zNRNzJlk03vnkrYTexWO/N LuBI9N0o3l9vLfhIiRtBuKVQHw7z4kU0/g6snpRTnojkZGn+wuVon4A55+rcLPq3kLt9+uNh fw4Y60uSnrrhqw9deuaxw1170LdfUXPvvs+s9O/CDw98BcQf7/s/4ClfHfPIP5+y89BPL3KH 1F/vhee0765L7tyPvf3skX/Pofbji486+qqn7foz7Y8Q+h7mp89++PUz7T3+5A+e/7v9rw+6 94FPf+qT3f3oF0DE7U9xC2Tc/1rXwMk90GoR3Mz8/lbBa0zQfRnc2Qan8UGPhTBwHTRdASl4 wrqNsBwrJMQFDZjA8x0QgBCUYQwRWMNivRB3JfxZD1soNxvmEIMp1NsP53ZEAs6wRkC8RBOF 8URA7FCFSZRa/hRHV0Uavs5+NyzXFZfxRdsVsRFh/GL8xrgq2KGRf1lkYhu3uEYGxtGBb9TE FLtXRxDmcYBL5OEcJbhHQ9yRb2UM5HiU2EUYDlGRcNRhIf/IgTP2kYOIXKQfJ4lHSP5lkEng JBs1GYlHYpKPRBxl+USZyEaWMpWfQKUlKYlDVUrKk3I05SdtOQ5XynKXVARlL6W2Mus1bzrL EyZvaFbMsAVTmclM2zKB2UzQPVMV0wRMNVEYPCue7XvF46XjXhkmFm7Tl2IcpSQnEY5BnhMd 6dzbOh3QzXcesm2s9BsZx2lLedLzbt685xj1GUR81rNy4oSnO7WIgW6CQB+JU+gH/hi6QId6 AKLkNGPXpmEbTgI0nPbsJ0GHQkpbXPSPG6UoLr/pRIMa8qGAK+kENKpHWbQ0pu2Rp19ouaZy znOgOUqpSiu60oDutHP+8qRNiyq4o54UlgIFZ1N1OlSP7hOqU2WqG+O4Tp3RMqtKa6hIOwRF rflSosaTaQnJ6jSzAnWtaRXrMni2VZB2NaJypSpPCyfVp94VpVZ9aSjVutSwzjF+RMMpYXu2 uMPWdbDeQ+tIH7tX5GBuPTj16UknmzTDdgOLjJ1ULkl6PYEhFrSh5UVbl1pafmUjtf1oXNNY 29oqwjZSrsVoZAdnt43CL7cKy61uQ7qq36bRmleFH72c/spIliYsbsIFrnLVhdx/OXdoZmvu bo27sOpad7rq2O5wg+vDhXJBbN7lbkIZRt7xmleIkbxG1cp73Ylm770Oey981/vS+343kvrt 6Fy/8LT+4tet6O2AgPc7WgAbuJNLOzB4OQvgBkOswQ4Wb3fFQOFflpUMhS1DhyP24TGEGMMJ rhtczVCvCsd3wxPmh4oHDC4Ru5iLBOYwi1F84xafFsc79nCON0HZNezjxcQFrMQoS+S8pkrG skiykaPKY8iiIaMWozIbrCzkJ4ernW541hu8fLF0OnmgjmVvTsOl1zTcJA5rDnOap/zmM7Q5 wkLtcjLmMAyNiUoOe2ZzT8Hw/qY6BJoOg85Yofns3y4ner58/fJD7iAQjm0KDpP+MkcBPWZ7 4aHM8eK0FjydBVDrItOLtYOoy0Vqourh1J1sdH5Zq8fXwjbW/IU1MVPb3o++w9ZYLOmsc+bq MODovEHdMfAqe8Nj67LGSuZPsC3as0Nb9rahkLaN+Um1ZX9zxNReJLej+9mK3pmE4q6zYAN7 t1QvuNpFK3a22f1fdPd1yT+VNxjPGqiC2jtKXx1rvqNc1Xp3e97PNjfB7VpwbGO3ks3Gq8Pv DUouh1veEr82PJHqbmbHWOMLnza8383WgZcYnRyHNtVuqm9qr0PdxNYylDveOb+C3N4WdnnA YXzu/tvSduI6l7nHm71zJp/c5jiHOTuJjuC/Dr3kScfmXsX1zq1i/OcHP7PBt3BiKTe86M9G Ntd1nfB1M7zqYH95yGdu9jiLvOVqv/lxZ9x2+VKd5HEXe8zhnvaaa/OfPuMqN/veb3MCfu9k Z2c0rXn4pjvtmuBIvN5d7PjdRr6mkw9u5Zle62EyU/NslzznpXl5rT++x6Mv/cHZxtyDFn7k 4A782tFu+rDnevXtzvtzjX772ite7mhUW+rJ5/vW2x2huM+98RX+dZ/vXvbA3rryWT972kff 9j9evvXLHu/ia9+fNH/+8N0ee94fH/nXb374qw/h7Zefa7yl6/mnL/yc/sdf998H//jv33nq 1//96Id+/pNPf3WHefCnZPT1etlXXAcIe/53dQDofQxIfvxnfgRIgf0ngftnfwNYgTAWYGeH dCk3f/+HgAI4gc6XgdgnfibYgCUYgOp3gSgocNLHgjE4gg5ogeTWfaRXg/q3gfi3gCSYfjJ4 giL4gzaogzT4gC7ogysoekaYhDSlgE/4gRG4hCl4g0xYhRg4hT2IhE5YhED4cOVnhRo4hEGo gib3elp1Rd9Ghlw4hl8ohlT4hkqIhXWohXG4aGBIhF54hjv4dVnngW0YhnrYgkIIg3PIg26I iF2YiDNoiIcIiY5Ih3PHh1s4iIToh0U3eIEo/ohnNHWcyIhNWIaSCICfmINXyHMhaIaE6HWk aIev6Ip4eE5BhnAOSItomImXiIexmIp9WIiwKId3OGCZVUa3KH+jyIuLOICh04pUyIzaFoov KIyRGIyKWIUSlnF5yHxVp1hsZVLZSI3k142nSI5SyI3WiI6L+FqF9I2up42TmI4v54n/M2e1 uItKV4472IHgmGj7CIo291v/Zo/SqFfz2EYCiYsJqIoUODXNyJDKmIWK11zjho9RWDiS5JD7 hJHQiImoaHQG+I9PBpL5iIDbBQ/H+Ig7tZF1dJJ3F5IRGY8pmDUZWYIzKUotOVa62F2hN1GM N1K+xZMG5pM/BZSf/od4RrkkQ2l5SFlzcKWUC/WU5ueUQZl5x1RDgJiLrtF+jQiBJ7aVyLiH XklmHMmVYRlAWAmMXXmWvxiObMlbaOmRf2Z96pRQv9eRR7iNl+aKNPmSK8hcmwiWbNmWTWaW wFdkWRmNH7deMJVNZMeYxoN6griKUBhdqAeX1RiLlimYRpWUgmmJsFBdn7mXRROakgmB1Pgi +MWXJLmMxnWZ7wiRofmaOjmNsumZohke0ziYV4gzuamInHla7AeHBAlxl/VdvWmaewibPoec oiiGwsl8IwlZ0pmYsfl81HmX5hh2OGmNq2mRw0mbBBZ0znmB0jme1ambu+k359mdafmK/nEF e/4ompO5nBRJn+55m+7YcPK5nfN5mpg5VOxZlvmZl3UmoLyIkIgZnsmIZQCKmZqlcdionTDp kugmoc4InhC5nFDWoOiZjhf6junFcWxInlnYoRsKoBDahCTqoclIiffIoic6oAq6oP24ha0Y o/7JdO3on7Nljjxqmj4Kh0BaoiGCa7dWWgSah0RqpElKo4PIpDTBa3gZilE6mTLaouGFhc25 SiEalwPDpV2obmGaZmOKivU4XcZYpJtDfQeaSXXopgWWoWh6SUVKpxpWnXdaeqY4o0hUjViK p4cIqA0zqObGcgXHp+pJeALoFn1EpvippQtqpa0Gi5OaXWuK/lKHGmyPqqiLWqmB2WOzqamm 8ouj6jiiqmdgyJ3vg5am+lGtejRs6KqGIquhVqN4NauWhp++6TohlquN2nKTdaukaqsFeqqf NqzH2jGrymK5CifEaKyAlKylkjnrGK0OZK2d6kHZ6qx+dq1Pol7fmprIKq7a6lcd2K3MsmDp Cq7txa6Upqjjiqzo2gXyilgGmZ6xpJxUgJ3LSqHJpaRd+p+uua71Gq/m+i302jGgWbDqpbBY d7CHxa0OO3vpaq+1965twKtlZbHTqq4QW67PGK3Myq/TSrJgA60eezAnC3LOyrJq5bIOaiti VKtv15bAyjvJirOGFpgby16+Wqwy/kut6oOq0IWijeaqL1umqcqVShuoeem0b+qgUUuAnHq0 GvSpWYq1D4qpCGOpuIpmLbqzZiapoLqAiQqpfrqhhUqpf6qjAMO2HaWpcQu2AhSeY5umGYqw OCiHcdq2cDqhKxu4ekpIc5qdTpenhyuPuEm2dKuyiKuLVttbZ6q43DeFhHtLl1u54ti1UPtr SPe1VyukoNu5qPm50HSkXwqlazq6VBpnX9u6gcu5WtuaA6qGDQSoLLq5iTuiAyu0T1qRIZij GoijDEi3xUuEjjuhCaq6KoqEIJqc+Yml0Fu6+9qLMki92Kem85e9x8s53fu2+mefvvuty+t9 /Fm9tymg/uhLuwEbvPv5fX77uHp7sMGovC5av/VZnr9rv16Fdv1qtq7bn1crvmQZwLJrnuYb QQkMnpXFwOHLteULm8DJnM+ZVM1qwfzovr4LnZCIcrh7nLyZWCEswD26t9o7U11VmumbiWKp mgactiVsmy3sv2k0mxKsuWNzw/Rrdfd5wmnnlFL1mIsnxDDMvwKsmTS8P0l8gxRcUxtMwKAW uqTYd3bZp1RaxcjlnQu5mYdpgUP8xG6ZwnsCvKL7w2FIlyo8ltxEmmvcl/lKxWvph2n8OjdM x+6zw1rrsz1JlTkTlUFUlFa5eYIcnKDHlJ5HyIacyEe5yCQMmX28k4fMe1Mp/slL2chNCcX0 t5KBSLWVyMJCtcmsCY/4+3g2qcHEqqFwnHsmGcPWm8o1FsrfqS0oOcrvm5IsCMCefL7/Sr5J N5FXnMllXFX4mo/MK8rtC47ETMCtzMNv2JCPZMxzp8xcbKO2XMsBN82+eMy7C5Cq3Mv3x763 bLyUecTCHMybas1GOMXe7MovSpyjSco+bF7Zus3OqU/3G5PtbHsiu1b4HM/fnM73iKD/rM+1 SdDnnJVR18wHbc4oyM85uL2yHL3JXJzIvMWDK8+vrJuzWMK8XNBrO5AeLaghrdEB/c76rLsC 3cspfdJKms3I3NCqW7YJycPCesoyDdAZPawXzbgI/i27cPzQP83QOJ3HIl3GRV3SOU3S7LzB SM3UR+3TC/3RZ7yrFI3TOPzJHb3MtXXTWp3P5ny7b6yzMe3VOs3MLMzVmpSyEt21a03NV03T 1zzTYj2ycE3WUo3VAUw4yEbP2vzTfS3OZW3SRi3UQ8jTd4m2cm3Xeb3MjV3Y5BvOKk2gkd3S i13PBzzRtHnYwCy/lY3Xjg3MjH3WxEvYENzRuZzUU73UX/3YbfpEqD2/pp3ZoF3OtA3TMizZ n025np3VrR3XpY2hxdbBt+3bun3WIurXw4ncga2dy63Yd/3Wgm3ZTLjZta2N1W3btB18yU26 zz3bP8rc3Bza3P3d4r3O/kpt3EAMRNuN3uU93iUXmeQtivEd3rId3cXt3g2I3aLtavt9xiw9 1NUzyC8jzgLuTJC82AauyAS+4KLV4Kol3YuH4HU54bEdGRUePBhO1Rtu1tEx2r2t1GBG13oo 4ped2m4JmIONiCfjd3yn2gAbjf4dpPkN4lP9wSPe3iIM3S+ei07t3Ugc1X9LdzVO4zQaDzLe hkduxNm9jIlt1UeH36x9pk5OrpaI5Kwb5Vmu050N3Pett1zu5Vau5Tmu1WCes1Ce3mnuw1C3 bDdF5bwd5kl+4+4MkysHgvs550I3ilcO3zte5GI83Wpe35JZcXRe0oVOy1yH6CSmmGP+5zWY /mLaRhR+TuQ//tj8ZujejOmJLtCbrufGyuewTOaOHoQAfuJPXpKWy8Xjm+lfzeoWR2+PjtnR BwBuHecQVusdrusVTc25buG7zuO+zt+UbtHWdm2yVuvJruzLzuzN7uzKTmt+/OzTTu3PHu2R XO3ZXu3IpO3dbu3N52veLu7MnmvhPu7nbq0Zu3Sbpu49KWntLpSrBu9oDmnz7scLK+z1Lu9q 4Ov2Dnf+3pgAL2x6mWWxfmUEX+Ucbj8Cr3wMr2C/HrQKL0P2nu/DTl0f3i8Yr0Aermgb1/Ec D7KzbrQiH7YkjzTi3bjeavIos+hT1vJy9vIPI2a66mwHL1khT9wl/ivrT2vdJ7/zUvveZMvk wCToWBPRHHb09bXucEaY/L70Qr/yhUvqPB/0lhPoApvzWI/ymhbhF0/suBXkVt+YsJ5fAFf2 MF7pmdv1+mrfszTqVJ/2tXT1XB/2jJO9n3b3gnthA7/3gHbval/3bDrUUg/sG1/4cF/0gn/4 pbb4IwHbXv/Ubu/uBjv54RrvHpTbdATnmL/57OHcZ975kRr5ymTpnLHCvHP6XrtioA+VCf9Q rCzfxDf6oh/6m3Trsi/lJlT6rX/79dD7tvX7IuFbI0/Gdstf5DyJAKD8y8/8ze/8zw/9zZ/7 Xx791W/91T/9Vn7928/95dX934/9iX/F/uBP/s4/9eNf/ulv5oN//CN8RMpP0jQJ/+6P4zzu kZjV+BjtWfZ/2pvF6XRIAMgxdbnRXAxQVpuozJev3b9OfK5wLM80NdWIVd7WVWMZRm2xdvZ8 wn3AYAXQGx52RpvywQwmj7NRMSrkVRtO7HV7I3ZdWu3KMl6KwZhyOmuesrka+E83Z0DhTvdy nbef9kD6/kjq/L4ICwUP5RKR0qgcFeMgQQL5GtmUIiXppDQ7ByszJTlFwWouZUwRQUkdWYdU c2JmW29Da+eMbFdfu3qjginvQtWsgH9LOYazlGGFm8k+RzWkAZ+rkq7fqFGNs4XDCWOLGZ3B kfBciXNnuafR/tnbwV/gJ+XTH+mx7lv8PZnTt89bMn65cBnMpy9QuXoFt9gDaGihwjsTF1WM OFBgtY4DHRL06IFjE4j9ThoLmZBjEZcvVx6BObMkjJkvd910WRODzpiyfAIMKjQozyY+cyI1 OqFonqZGMT48t5TiSKrMdlEVehXbVK6nLH4Vqy3rWGQbzYJFC7Vs2nGy3LJEGZfuv7Z1SXrF K/Lb0q17884DzDfsYMOBrQL+ezhgX7Z69y4+LJlx5caFFd81TLkk58yQ8Xq2PFh0aM2kT7dM HXm1adCjXQtG/Zpu6XS2a7euixt2XN5uf6cNvoy2b925i/cWftx48uXOicv+LJ01/nTlX4eP zS52OznmwL8/p369+fjd4c12/6P+Knut6Mm3h899Pvb66+/Lt05/f/zH5pEDsLzEQMrvvf64 cs+/AhHUT0DwGjSwG8YU/I/ABbWT0ELHJtPwQnEqq5AnETFEKEK/PKyJRMzmojDFzl4sEZoT N2Qxtg+lelA8HAfkUMb0YmRQRyBp5PEJy1ZUrcgfZxwywyVhhHItI3f0cTYnSRtKyy257BKm pLwMU8wxdQKTzDPR5NJMmpxSSpM04YyzzDblrDPONe3Mc84FkxSSSiKx9E5KP62c7k8mCbXx vEEZCpIsRm9zNFJIET3UlxAlzdFSQQNNMFOVPq10ykKr/uvUwU3xoxRUVU00VdQmUT2V1Btn ndRVFFntpM9Xa5UJyVB1BZYWYWHttUdFeU101CtjPfDWZzPqMNfomk3Wjl1trbbGZZWEVkVi E8HWWhC9jbLcbrVNFytMpy0W2XFV0vOpyeR1k956b9IK33xD3JdNCv39Et6BCS7Y4IMRTljh hRlu2OGHIY5Y4okprtjiizHOWOONOe7Y449BDlnkkUku2eSTUU5Z5ZVZbtnll2GOWeaZaa7Z 5ptxzlnnnXnu2eefgQ5a6KGJLtroo5FOWumlmW7a6aehjlrqqamu2uqrsc5a66257trrr8EO W+yxyS7b7LPRTlvttdlu2+23/uGOW+656a7b7rvxzlvvvfnu2++/AQ9c8MEJL9zwwxFPXPHF GW/c8cchj1zyySmv3PLLMc9c880579zzz0EPXfTRSS/d9NNRT1311Vlv3fXXYY9d9tlpr932 23HPXffdee/d99+BD1744fUNeCe/jD8equR/cod54lkWF652Lz23RXWhl1j6I6m3q3sawM2+ 4O19IH/Y7+PBXvyHzcfE+kffJ1f99Rtuv/r54cdffmPp39h+7+PnK/R1JYD9O9j/wDfACelP gAU04PjCl0AHli+C6ePfAy+GQAu+q1UMnN4EMSgj5qEJTzh507xQMUIylVB5KURhCCemQUA0 jwYG/oiKDmh4v2+l8DIwZAa/ynfD/F2QODn8IT6iZEQCjggYFBBi7jjRwlU8sYEe5J46gugF CykxWjuMhhZ9OIUMcPEY7AKh+0xSw4+YK41V9OITQkDF25mCjFj8lQKr0hMxHiRbevwgE+HI xzCGwY/qiMTxEImTREKAFQKr4xA5GCwe9CAmcpSLHc+3rRm+ZZAXaSNT7BhFJ45xlEw5JCNL 2cdIUqsNhLykKj1wCUty0hpq6aQ1TIhJUIryk6JEJSZnuUZuKcuTNlmXJmOpQzbu8Sy3dCUd SQlKYEZzmsAE5BmV+UwmBFOQxtwguiyRR2fWspom4aUuzynNU17TihTE/uES31gCNOAqnAsc JzlDGc10QrONvuQmYojoLm2KE5xH7OIy8WnPe07Sj/zcJzWlGdF/auR68WSoN23ZKDU2U6NE 2MNEYdfIX6qTCsrbiQ1TKdFcPnJ/qxQoRotJS1Zu8pWaaiUaF9oGaKJyp6Y8iilRekqeKpKb MlRoIRMqTGIys5sdTKY7c+osXcKyogidahlYAFIwnqGpknzqFaO6vK3a1KXh+ipNx1pQrgIU oSztalhLEUWLDrOjEZ1iWpd61zKy060pgettcqnWqiqpr1/V6l6/SBjCcuOwf+UPNv9RWIY2 VrEysWHxIOvY3ahwTCyUrEdfGJHQamMonuWsor00OzCjEnSweXWjVVubWoSt9qB0pSokBYtb 2c62gvAsK6famcng7vaOmf1mbG/b0twql7gGo+0xh5tN5JLVts2F13M5yty6BtSseLTusaq7 KuP6NrxO/e13f4TdjGo3ua9drnvRe93eHnW64o0uAO8b380+D3n8XZ5/RzRC/Q6YwAU28IER nGAFL5jBDXbwgyEcYQlPmMIVtvCFMZxhDV+tAAA7 --6c2NcOVqGQ03X4Wi Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="omega-ops.gif" R0lGODdhhQGoAfIAAAAAAP////8AAAD/AAAA///XAAAAAAAAACwAAAAAhQGoAQAD/hi63P4w ykmrvTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv 2Kx2y+16v+CweEyWAc4OtOKsXgOo7PSb0Q7UofFGnT2396N5dH18g39Gd21qe4ZPiIaBbnCP f4SFknqWfplClJ10n4JOnguOd36ioaSjkKZIo5GkqbBAi7K1qk23s7K4TLqnsb27Sb+tu8Yp cYmBhMe8iDzKhct5exCtjDbSqtSKlBLQO9tu3XPW14zZK2jes7rFk9Fv7cD19cbY6jTs5v3C 9/rsCbzBD9YyW9kg/WvBbNUreJjkbQL2Tl0+if/oudNn/grZjIapKj7gIycGRHsHM8YT94ri Q4sJA5ppqRFghI4yTdL0JwyZQo8nTopUGZHlM54b0Y3MCUPoS6UljRJFOTHqQhZOER4tqiNr T5hL5W2lenXgMII7j1XlenZdWrLDvrHF4TVpWKs56trkurLr26FQy6pwtHHe3l44xYacZuew oMRSETOeV7VS37wrqTVOKRkv1p+gKSeSg03ipFKaBpH+aRoTapJrXMMO5rfU6dS0yZXOxbSt FKC8qgAXDKi32SPDfRe/kHxJ8+ZKnhunxRS68+rTr1ewHh37cnDZfcnkrh18F6Dky6hfz75E gQIaCBDQMGCABgECXLyPPz9D/v37+bWwXwby0WdfBvjpBx+B/WHwH4IBhjAgBgX6dyAGCQq4 IIUNXvAghhGuMOEFFTp44QUZsjCiBSV6eKIFKYKwYgUtWvAhiiGqMCMFNVZwI4w5prDjBD1S 8GMFMeq4IYkd2vgikkF2MKQERU5wJAVJCrkki036+CSWUZ4wZQRVSnDlBFmiMCYEZUZwpgRp crDmA21C8GYEcZowpwN1PnAnBHm6tyWNXRr5JZph6jkoj4VaeSiciWqwZwN9OvDnA4GSMCkD lTZwqQOZjrDpAp0y8GkDoYowqgKlLnAqA6lasGoArSrw6gKxyrgokY2a+SiekWq6K5W9uvkr oMGK/josmcXaeSymyV4wa60B3KpArh9M26yfz4IarYTLsrmtpd2i+q2u/BkIoLLpWriuhu2a +K6K4dI5rqflwnputvXyea+p+eK67wTaqguhgvG6OK+I/VL6r6sBXzuwlA1z+rCtEQeALcEV k3pxtRlvTHHCTi6sJMlemqwlyoaqPDKDBoOIMMzuHgwvzfLaTC/LjrosZ8esfmytxhP/zLOv Pit6tLFJC7q0s01nUHDNMt/MYcw4znw11VlbzSTWQLKLs8I6M/w0t1GLvXXOVe88dsll83s2 uWmrCjStQodc9AZTs92122uT3Ta6b6cc98qFt3y4mndTO7TIRife8+KR/gcO9+AnS4405Upr zjTnTnsONehSN5533eDOjS/qhFtuOOaIu6447C/LPjntYpoONpRaf8112F5zuTuYH/DxnmXI syFfM+icUV/yyePH/AjGHw99JcvPtlp9A1xfifTah1C999gTMP323ZPPB/gKgVB9Aeorb374 jwHAffxnsM9dH303dg3ECwvPBP7wnorJp0McAVi+8BMiAYJjAf1LIMYCWAICbuqAoBiJAnHU QA3wT3e50QMAy+bAmzSggIRqkgQh1i0GipAEH0zYCh/XQRiecE8YzGAa8NXCJIUnhmObod50 KD4HoJBYXVohCxEVpBL+TwERNOEESVhBI64p/odEzCL3mLjDDAAxcEKkoA2tOCwsZjGEGHuU C7tIPQiCMDZPBJkY20hGZhVKiUtEVpR+6EYZSlGOVBxjHf3VKDzm0VxhcqIGofhG/y0SkINT JBtvuCgznhGO5PrSGidpgS/6DpNspOElO6CPI3qsV4Y8pMQSJckXBiCKcRQlGosXAVMGDZV/ zCQic9nJPgbxj7IEZRFrOSFLupKTPBRYpFqZQVg+MpiOFEFATGnMUQZki6t8oBd9CUZgDnGW HpAJCqtpTUfZZ5NxlCY3PxlNV0KTmeB0I3zIGU+ZbBGdj2TOOoVXzxFGsoocK0CfUsnDUMET k84M5TeF6T4KFHCg/rzk1gAM6sF9EqqcU/ynICVgy4jGc4MUOKgjE+rOhbazoQ7dE0GTGdKK MtKPsTSpSHMin47m85jIwqY26fjKRoYxkDxllk2R+VGJ6dSjA7QoozAKyb+dlJZI7Gm4VprN o94UpT2F6TNlClA7SjWp6YRWfqxKVLBm9ZcxnaM6vcrIZVF1k2QdJQc8yU+G0uadXbVXg4ba T2BFKK5FfSRJM4jXjTqsSXx9ql2zCdKrQvWs3UwrUNeqV0oiVbFEyxFgMfvHwd6Vq4Y95QP4 SlB8pjGsWPUsJgsbVIsVirRINS3IDsXHl6J1q2od5mGJuahUyva0ZSWlUnnFVNZS1rW8/nWs XX87W+XuVLWONK5uRcvRGRmSucCV6wboetG+NhV4ixXubqs7qOtmiqy1hSw7f6rR1tKTAR3F I3ZVydntDpdYxQWteysVX17ON7vh7axPvZlbrOLtX7ZU4n9VOdP7Miu/BX7sgaU1IgXn6qg/ ZIP18HdA+nHDfunDn/5mKr/5xa+AHtYNA/EH4vOJT8PwY3GH2/fh57F4xBUsMYtRTGMVj9h7 Nu6xrO42YSeZVAXU+iqQJja0ynHoX5sFlguSnFhvMTljxOTAe+kL3hUkWclcHF7utFypKEu5 BV+usjI30GQIzIq6xsIy0ab8MXmGWcyd28CWzXxmFnwZzHrk/kCbR0tkOOuSA5DTc53tHGhB y1lShb5lnDuQaNW5eUoLHl3qPFBNPkOKzvxaVKY1bTZOF8nTffbyohm9yw4M2oogsCSqU43k VbOasa5+dOliXaNZIwvUoW51rtVm6gb5+tdotjWrR/05wBWby6z7wJ/hOyFmk1puIcDgsZHt Z2Xb2drXjp20C7RtaAFbV/ABN9rsNoIDvlpf50Z3pVcXvGK/W2DxDvW8AUZsXnsb38kWVqTp Vu9ni2Df7ET3CO7tYAtt2am1HgF+1Cy4UoegPg/vcsQPLgCKX651H9hixokX8BC40OOzs3jI /zNyROWb0glC+e1AnusLtZzWKZj2/prbCgKGV+DNhy6yBxBe16GnSObNpjmbf3Rzc5fc6DlC +rqd7egXNd1bLwdQ1IHuT6Vb6EtXh/fTEZ0mqdOb6gYC+7SJ3l2YR8ns/GZ3zdm6AbYv1e3J dXTv0k73aJsa6nlfer9NdKywz3nsEAoW3L8r7q/zatF2Jy7ZFQ90n6uX8Cms+94sLWzyCr7g XupW2COPX81HC+6Wf/Osr076B2udwnezPMeWni/Wb150jf75rN49PhbfT8h8yJ6IBeBi98mP xQBYMfBhHOP4BTk9N2G+758f/TPMOH44hqGOh0/85Z9hw84P8f4aPnXM9oFaMWpw0CIMSplj OK/uv5ES/luOTvVLeslM3f2J0qt/pqK/hjz1f0zFc4byIvZHgOaEU0SUcfh0gEIHKTmyQv0X WGw0geF1fh+Tfl0lgN51axIVXHM1SJOmgGi0ZablgA8oVsHFXSnHf7G3f3/EgQFmX+s3WSSY WHGFgoDGUiRoV/QkWzr4g2kigS+oXYJVhN4lg/XlUnjDfoo1VIClgzsIYAOIXFaGWhJmhZ2X f0g4g0eINSukhPYnhpfVUZslhTt4hpdlScyFhmyYJ0QIhkxogebnMU4YgjXYXiBoSlGGhmDW h5cldNjlh1g0iAImh9tkW34ThhkIgJRFhlhIbfBhZn74VZQYiBM2X5WIQZp4/ohc44KI+EiQ GICNWIWEVgCXUolSlYqYeGAUFVqE9Ipf+Ilz2IV1mIdONYal2IGBt1PH1YuXxRQZp4opGIkj ZYugSItxNIqPuIsXaCgUp4r1EY2tiB8Pp4rWCFFxRIfJuIgx6IxLmIhNaIPatUVqVonmuCZU lVnF2IPi5VftyIWhqE+KWHGMeIc0OI566I7NhYDOhYfOciFV9lYp8l5+uEkG6YneKI7c+I34 yITM6I5WlVhoOJFTslL4RE9omJFlEofKiAEsOHP3SI6PFZGXFFewBYv9aFnOpQ6yRU5S+JJV 4pELCZLkR3DPiItdpotOmA2bNVQ6+JM74lt5Uk06/shcRqmQ9liL8+hKJlmS4GhIZmZTKDiV 1hVR82VMKJiVPUKTS8mQyOiQJBlOdjiW7eRp/WVYaLki8pUqluSAC/aWSvlx3fiVohiVG4iX 6TRrCZZXfFlhuTRqZnSAgtkiXkmXHgRjyPd7PnF8N9Z9QjZXjsl9KZYajKk+4EdizvN85MNj jZk/P3Y9wgd9zZN8oQk918cRijl9xYcBqvcqtpd1YHIu28Z1vzNkFQNuOgdxXIJgdIhtfMco ddZ64jJ5occ3A+c3rrkn6rabGsck44J6unZDcxdVmiebUBIs5XZ5KTBoaqZu+rgClbZli5d6 A7dZhnd43QZ4AVk7K/Bq/okFnuGpAvNGT4vHeO5Je5UFc9iJf0GHnC7wbkMln/OZAvtWTfeJ n05WdePFn4hnejy4oN05nTtIoAWKAghnSQmqoADacx+SngC3niAAV/dmm8r5MxtioRd6AkSH RRvKoZAmAiLnnMRpLxw3VgxnohXnASikoitqAmyHQS8Ko7smowMAomInoiYnANsJay1gngUQ pP/GOyJQUzqaUV7XAUiapKpGAk3qpCwge0OqkwZ6eyLooYOnpfLhczXqLwtXH2x3pa8zoh0n p85JpeAiUFNqnlVKbgzXpg5jpOdEdHKacoA3pHdKcgq3pUS6nNlWIl8qMf3pIheiooU6c3jn /o9k5gKEWky7yafj1iSRCqgW46EvYqGXujns6YGcZ3QKp4V6J3dqWihfSqplWZ1bWKRhOp2y laCJ6nI8uiMgCqpk1itNaqtkinm5F6NPqmvMdZ+/+mkUU0Z/Rqz80Szbiaw/WoB3pqvv+Wjz tXjRinOw93ixumnXepx+p6YMOpsduqvGmVJENq7cVjr9EnbWCp2Uuq6bGpzZyazw+nq42aoO aq/6eptk2ardk49Y8XkoIkAi5Yu8STAQ+wICtCrmw7DtsbEc27Ee+7EgG7IiO7IkW7Ime7Io m7Iqu7Is27Iu+7IwG7MyO7M0W7M2e7M4m7M6u7M827M++7NAG7RC/ju0RFu0Rnu0SJu0Sru0 TNu0Tvu0UBu1Uju1VFu1Vnu1WJu1VqE9pIkcl9G1h9AJnKEF5UAcrpAJv3AFqBEcVrAIswG2 Q5ASIBEEOXEOwgS3HxFSp5EOEesCdesQLeEKeqtDaRsZ0TcVysEJf3sXbFsEwGG3cEEMixsY xxEUBaEbHyYa9zAWFMgQl4sbuqG5o8G4Rui3n/u2JDEOnBUOdHG6DSENlFFP6dAUsesSRFET aYu3xme7jnG5+BATfsG7Y+u7AUEYmCG8E0G8SwG8ppu8SKEJnCsQuls8w/u8rAAWnlEDc2sQ Ytu4ZzG94VS9ahG4mDsXg/EXgXsSZku7/mORu9hrvvuAvsHRmNkbv+2bvqp5GW5xv/P7Futr sfK7EL9LutoQwHHxvt47E/wrwMWrv+e7wAccvZWrExAsvQj8v6ZbwcYLvxPMvlPhvuaRwCag FxsMSnwbvB+Mv5SLwZ6rwQ48uiz8GS7MwRGcwYvBDZuhvzWRuB7cGeSQw/BLP+BLSpkxGRYs G6CBwj4MvbXLwN/bt8u7t64BumjkYVCcmLYxxeHDt1tcG1L8GFR8t5XAj7SbxWDcxfWTEKJg HENsuAN0xa3LHHCMFnK8xnWMBdKRBXmMx2w8xzI8uGTrHYG8HX5Mx4DcCONRyHEcwluAHops yIertZLssf3z/nHPyTgEC02ZYzuqOrFjhns46cnvmnBzesmfzMlJZ8p5RsqGiqcqV3SW7MrA ycqYKsuN13Y7asuYDMpnJ8qhg8rhpqhZWnonKsybTMudrMq/jMyprMunzMzBDKzoCs3lp8zC kslHdst3V8zS/Mq4HMvGHKzYzK+jDMul7MyrbM6tHM67DMzVjM4AS82hbM1pKnncLK1ot825 zM7PrM61zM/l/M3nDNDL7M/JDM/XzMtxhzvpLNDr3M2zbNDNTNAJ7c7zjND1TMz7DNHabM8b jc/D7Hr3TK797ND/zNHtLM+9TM+yqtIL7cveKtHRDNLHLNPvTNEZLdIfTdINrc/g/ozSEurT Aw3UPe3RP03THa3RR83TBW3SB43TFDbOpJPTxYmwRN3UQv3QSJ3SNn3RUD1kUs3QWG3UQ73V JZ3VJ23WRa3UZc3UMe3UE33VFe3SXcfS09zVK43RLY3XL23XuhfWME3VNmrVaj3WbK3Vbi3Y bkrYiR3VCl3Xen3XcD3TjS3ZaP3Ucq3YgcrY9RrRk33Tmb3Xn+3VoW3ZZI3YnZ3UOr3UqZ2f o53XXx3SVT3SrX3Wp53WlS3bg03bTmfah43btb3Wq93WwW3Yw43ave3Nlx3XhU3I39d88TOa +dtij9ma4fvc0E0+0l19ICZ+5JN91LOaHGZin0ndw2fd/kSM3TJG3tN9md8NmeNXj0XHXrkI fxdkmLk0a/XXVdDVB9JlYDI3mPn9KvsNllqlUA8pjpoqLirES57WgPw9YJK1jwY2hfvJiw/u Q0x5WwhulgDJqg3Kiyu5rF5o4BxeUglukyzZdznZWCQejq7U35AtzDqYWEmJhZsFhBF+4Cju 4Rq74IYm4iOeqzDeTBKOWz7OhCsOq6ZIhbhGxhseWUhO4VkI4jCJVHH1W3U53wSW5Aq+5PF4 ix+oL6y04ydOWPr1i5IY4u6oD1bVhlG+Xl1O5Ql7aRuSkMa4koYoSDKOpTuZVyKI5/+oU3uu 4typz/T95yppZ1u2jveUKfbX/ueNinWdS4/J1eiY+OjBsuW4nOiurIoPtS3rOFuySFmS/t9V Tkba+I9pVOq9JN+dPuf1vehr3lJ5Dm0gmI+nnubTBYzGyBSexumILuuK3lr2Qo23TjR8FulH 3uF0/o5CNSejjh/LHudcPuGzbuy7dY6Y6EKXyOfN3uPP/uGVxe237u1/Iuwe7ek0DugNOpCB SKK/wuw8juYpbukXDu95Lu8Sux03udktjup1Tkhg3uRPPuSla+i7fu+vfuFA3uJX6OJQXoHh bu9ebuhs/vCllSZRaOZS7uzZrub3V/AQT+Zjnuuz+PHiHvK9PvJnKuTMlYMeL+fYXuwib59D 6VEx/n8l6q7R7N7NKEieV4la84VeM3/tU87yFR7mC25e2nkkPa/TPw/SDphxaXlTC2ZV9H7m n8Xw/s7kdt7mRP6fRU4bC3/x+N5yfZlOo/Z+4F7vXY/2Dc/0S25htCl/WAwAmando8ndnPne 6C2Z1ifd3uOZ06184Rf42yXe0d33pfn33gPe0rR9JwZ+3I346sOZ4pyuRkbOBGvhL47cop15 nT/VfYqcuSky+XqwCej5j13r3brTc/1k6mr6j4qi/4pn8cwg2Npm2vpn35losldds9r6rm/R YQ+B56rb1nnyx0/XL2/yy1/TvD+C1/mgyzks8rn61U/2ts9rwRbx06/a/qQfoc/P18k/9qzt qKFq/uf/2p4n/cMGerQv8e+/3AMr/+Pv2opmbPf2+whAsdz+rUgmKrx4DMz7nZ5HjIy2hZyF rhfJfmBQCS+k1ViMN6Ni7g4VcOUaLiQFmXB4M6J0w17g51w6OUUjUklzNq/Q6OhrtF5bijPS vCOfYe+eG8h+89JgSb02B4bFeFVddmh2W2d9hEdJcVllg4oOjlp/bSd5bxpSV3uEk3QCh16X kRGMV5qfOJ12qquhlXyklIg3m4+lD64vMwGiTLO5sS8/t0OsjWe9v0CJOMMrVAHGO8hnuyu9 i6fNwaXQKNLUr7mSgaCDzDjONeAe0gvjvJDl/tgh2gzqxN6R7h3w0+x1sHZF4EAr+liwe+Ev Qx952ejlMogBnylussqZMgIwHkUIBJ18BMkmYTh+zzDuQwnxnsRSI4PsMfkOJaGGNpy19BDS SMwGFh3Q/GeTocpoC3emeBnp54KgD4Y61Jjv6MmiSisyVeSUSwepFxaywNmgI4SsJKl6rGYN 7AOxaqzWLOrxHIqeYthuvbiO7gqyC8yisctzbyvChQ3z3afWl1wOgs/GxAvkJ9QcgOFyAMAZ gITOoEOLNgEaA+gRolOHrhCa0GnUqlXPKH0B9OfYqjW0tmP7Nu7QpDub7tzjt2jWtN+8Nn4c OefhnJEwB607+QoA/lUzMsBem8FkSNyV30FMErzp7Iy3u14cAl74B+/RPl3y/kr47w3q52c/ d/+L8JmRop96a83jn3jjuUTPgAsA+FhYAq7Hn0OzMBhAfWgFZeEO95Gn1YHwCeUOQBt2t4h2 DZ5XIAv0SZjgUhJZ6CCKF7pY1YMdyagLNlCVWEOHNbRo4oRvzeFjiCeml+KQ+BGIoDnkXaZj kgpFyBsEJpk1JZRavXQkC0Aa6CSSIsql5Y/oVQmiA2GyaN6VkhF2WY1DBrimEwzqI9iWXD4w 55fXeefhBUJCkOcfe6JJJVJ3Otnkkk/ueM6cdBqaJqNj2ocZRpHx2ScFewCKQpsRNQpp/lRQ dKqoYzRu+WilZ2x4C6WwsnnpSaYCsaEokdWaa0B40CpqCKTe9aalm5bAzrCV2pnpga8y20GJ UtDqq5POnqopB1v0eq22knq1mYvRqpist8zOqOS3lZYLJxYjILNltuxy6AESYnkap7zkDprW swCXme+q9Lrqr5/HxhoCWvM+mNOvOBwJlr5xEttvkAnbeq876d7anpXIBoQxxKtqlVXDrdoI oVQUy3TyxWKCG3BZA7BMsMNF5lqsSyT/dxANSqG8rrTjQnbDUC2DCjQ2RJvrbsgQboD0zSkz ebBMPYMJo6AeCq3mzPZSeGPRUCM8yE5NWz3yzBtKQ1PHi+LK/raga8s8hIVBteQ1pnbrKjaR cxNqhd4wu6nz32MPGWjcHx++YqlgRyz4SxDtLXffYRfpTUItX1Z54ZD3zaBZnFM9tNNXA5Ux nuVhII/ljUdesrIo6UMxpa+DbqzjDkRmu+lfi053zPVKLpNh48BeU9aL01yUOvpam7zuPAfu /FdhwM3q6WoTn3bZ1talccgFq+ztNuOTOZ9iwKa/rcjemxsYXMxoX373hsvus9JEZKE8Ucwb 1fWeoAM+hY9rAbTY43ZnvSloxjHcSFdnfDMdAATnObUhDgEq2BnnYFA5HfQgc4ojnAxGpwAc 5Ex1SghCFa5wOtJhIXxCKIAUwkaG/vbRYAoBMBsc5qczF4QhCq3TDpxprn+pA1VjKNM+AhqR Zo15IOAmV4OuvMAyITkfqt4AmPn5RT5YUwsTm4i9J0JRLVKc4vFwYEUWOOWAWtxiXLqBlTey jxN3rBi3uujAKPoFBg86oGQa0xVrxVGOmKCj6wqZR1xUxhVueRga/wjILj2SkEk0G+KKyEUz 5sQbYPwXVcaIQFR5sneU5EgqsfQHQRZCLW28zCFZ2clRzCKUotQIKUuZuG740QnMcOUrqdJG cdGOFnO0JS9BscRGLhIPkZzKJPNwCmEOUyPFNOYs4ZBMZeJScM28BgmiKU2qpDFZ1rxmPTJp yW1yM5Go/hjAN8EpRmfCi5zl1Mg5N7XLO2DyDRVw5zuBeUp4sfND9TQEHyVpzlWWMRmwPOgm kQlPkYzBofQcpT03lc0+TlMZsCjoICOaCQ3002N+EGm4BIqwcFKTjMD4JR5pgM+RElOiR0wn LbsJiGM6UqMvFZ8qZfqIdCx0eDeN5yV0KqJa+sQRLFViQimBkXmesaGCoEdN/UlSVc6CqSjd wVFh6lO2uDSlR7Hq/IiqF1aqFH5JBYY3wLq9ilbRFVE9KQPFGgu17rMvx5jJQjsqApw6ECVg HetGdqAUluq1eil5kFX/SqN5GGarhO1AV7zFVMWGtbAHE+hjC8NXnM2Tsuty/hP7appZeFnC Lzr1LOMWRhF3jvYgkUViZXOxT1fis7WL7Asl0ylbzAVXIdL6ntY46cbkNqZ4GX2CcxsjrTTW 0HjPza52t8vd7nr3u+ANr3jHS97ymve86E2vetfL3va6973wja9850vf+tr3vvjNr373y9/+ +ve/AA6wgAdM4AIb+MAITrCCF8zgBjv4wRCOsIQnTOEKW/jCGM6whjfM4Q57+MMgDrGIR0zi Epv4xChOsYpXzOIWu/jFMI6xjGdM4xrbuL0f3M2FlOveD+44xzzGcX187GMBA5nIQQYvkBu0 5AEjOTlF/m+RcRhl/zYZyfgl8g+3HGAs/5jLAJ6y/g+rvF8tZ4rM70Wzl8P8nja72cgDijKa 89tkJoNZu8I5MnZow0IZ6SfJvHmOnn/MnT5vZsjozXN4SsPnHGewbONV9HYUjUFDT/rO0M2F oAvN6R1f2s4zjDOgQejpUm/606V+NKYjvedOe7rOZK7ynL17alO3GtVrTjWot9tnNzsa1T+U 86hjVWdCj0nNfx52Dhft60WvetfPDm+vg+1sYOda19l9cmsqHe0vd/u72mZ0obst7EQ3W9yn irWozU1tdMMq12Lu7rXtPG9Mz1reb56hrtVtKGXjKd9sujWwn31v7ta71tC+dsEjUe8aDXlD 8T5vw/cc8H6r2rwTrxW//vUtcYDb6uF3jjivfe0fKkMc5B0PdslFjuuKp3zSbWYyyjnucoyT nEAmT1+y8R1wgYMr4uV+Ocz3TXOZE3HheH64z30l6zH72whiXvrOuRz0pEcd0eojdJzNfXX3 aSs1Xhfv0akMadGEXdomn3LZfZhp9SId6fN9+9PRfp25KxlQcBe6B/IeX7nDue5/H5XdqVJw vsu38IO/O7ESD+4jGV7vFi/wrB9/+BJRvu+WZ/yNN59iwMTknLfd4113S1q1eJ6doN9oSkaf WsgSlPXBC51GTk963Jr+lJ93aOgxA3u+yZ6i/av9UhpD+9aXnirFj/1eZ4971Ote9Tt1o/Pr /sb83l/u98JovvARinztG9/2dqXt9qNbjuT7fvnl977yXZ9+68cuf+Ev7Phz2f4rTp949Zf+ /Ft6e/cvD/9DYH7Xh37Z538ABIDfoH7nx34FaH/7F0bxp1n3B3/V54DfN3z9Z4Hrd3wVqH8X yH2vp4ELyIH5F3wfSH4N6IEbCH4daIIriIER6FonSH8p6IIjyIIliAK5R305KH4zyH8xeFwv CII9KH8/CIEtqIMTiH0JaIBGw4MBqIADyIBNKIJTSII1qIQPqDrEJ4Xvx4R85YT5RIBVqII3 CINJ6INDiIJlaINXiINRKIYQAoVtqIVHyIUZaIZviIZFKIFbKFVB/qhOX0iG/eCF/0eBfSiD a0iDdaiGZ0iEcWiFg0iFhSiHDAWGiiCAk4iFjWiEiwiEIaiHmwiHneiHdwiIaeiJj8iGlSiJ h4iJzCWKr0iImWiIB4iIWeiIewiJpaiIq8iIYeiKtwiLCmWJOYOArSiLw0iLN2GLT4iMqyeM z4iLvSiEvwiKiWiNu8iKtWiMqESHYDJBFDRCG0RE1BZEzCFCriGOO3RDyOZCO6SOgXZCQ1RB 7uhnLjQAKSSPLeQZ9WiP5ch2RvdC08GPzQNButVAh2QRo6YuZrglqZdAe6dG4aKQD8SQLmJ+ EPl8ElkfYEENnqJFGpKRCriR1NeQZUJb/ucQknAxku+ikeYSkfrjdUMxPYrjRT+TdawzW6Yo PGsVP+/SS4Ohk8/CWWaAkjzpiyYJlMuVkkNJlDITGVJCkr23lBSIlE6pR2d3LVLJBlgJk0Mi k8YFaehTkVD5LWbxJ1QpglYpe1iZlS9ylqPTB2r5kiUZkxw5k7nCDIRzkwPEP34JdZ9ljW25 fG8Jl2TFO0ekOlvxlXcZlnk5lmeJkEIVmJgjDcKylg+JlyepMlmJNvKzmMZElnczmNdUmK6n PZUUNKGZU6zgmFXJmUypMHuUBKxpmcdkLbDJlrJ5lbPjVvaQNLTDL3YZm5DZmUEJSMHZmppD nE8CliEjlm3X/jMTw5yiSTa0WVc2iJoceJiVNJG4+ZfY+T7QSSbSqZpoYDPhOR/ns5ubeZyz +T6LpJ6kqTrtqZnb2Ztu+ZtcMjXr2Qvogp926JMe5ZvJGS7+WZ/rc1jTIqCOyJ0siJ6f8jbW uaA4WaGZU57jc56eGZcUGp740CvumZ/waaBNaZZlWZ94YwWqUpy8WaL7eaDLRJkqakniuZUZ +pjRGZnTGTDyUDqWKUuJMKIDyi7hwaEympg0upUMIqT8QKQPqp+GyZ8t8TuBSSln4qLvuaPI GSkzCji3swdZ+pw6ap48KqFKAT2taUhG4qCqCKFo6J1pmj1rygo54qY9aaTK0qUH/qmkpsSk a9QfEtmgSUmYUpqaKoMW9ROacOQGUPqmh9qdJQNGv2BAWUQGj5qncAqCb0mpBSQ/ruQeeKqU kRqhP6JBASlE/wgdPCRCxkGQ63hC7eiOrEqQ6VhD5gh1qJpCMfSOrYqrFQSr8+iPs5qqtaqP +wisl/cTkZROqDUWBQVGtgV90libEWFPz/oX0Vpb0vlUpaUggJWH9hdavUWtyrgxOKNT2UpA jCUQomWuXJVbWxOu3fdIg+JY8FqkRhFIY7SuITBY2ICvEPWtVGQJXdhTUcNMXUWwrWOw4npX 5JFX+bpARXQUdOWvG/NUhBFVSvBPUWixu4Sx2KOxnxRY/gOLVoHqSw/LRlD1rLsniBWbsg5b ryR7o+DIskE1mjObihBbVgobV1QFmDG1siyLBxw7Hyf7sTq7s9kofT6wri9rU0FLV3tKtEXL oIKQtB/7WCIreuJEAP4atTvSSQXAtRgVjQVxUSCltUpbCwfbCIaFhOukUG/1jVbbrnGLh2kL UCHltncrC2oltxORt6CyVcdIs/EUuHprUSBFU57VtbynVH4KjZ5AuF5huFfFs7KwAYqLtOI0 U0LJtLkoXF96s5ULuimqsogrV6VLudVqLFo1VpA7UK/1KWa1sOiAmH8Yiawbl7e7t4H1Epg7 u9FXuyhquodRVG41tKtLusfr/rrnCq7fSa+a+zEswUge21bTu7sp1btaibzRm5PWSr1NazR1 JFFiaw65O77cG4zO+0y/y7ivsFpdRLyItBIqSQ64q1r/Wr9nG4v4C1r6C7yWpa2nZL9NtbkJ SY1NcVC+RS/lW7JKyE799BqpeqvKyqq9Oh3C2o/jyBxBxKokVEEGuWwAcI8YnKtG98GviqwC qSvi+I8g/EIifMG3qmMHCUYYqTiRJKpa6nt8osOFkp1PQyb3Eyk9jKmow6cC5Ls22kBLOlGZ Oo166sQFq5dNDFcxSj4HDDLZmbpSvMTxqUBWLLMEGrrXKZlNecQ6qRQ9Qj2SWiddPKjjGcVp XMVa/jyl+2O7ZnzGaOyzWEzGbBx2LTGV71LE4zPIO6m7gEygiEzGfGyhcrm9jazGzaPIPvoJ dfkkj4wtcxzI4Pmnd+zIFLw6oXy8lJI0zNCiZFo19UkNqQzHpirHrvzFiMnKZNLJhPqUS6uY ooy16wk8QIyhs9IJWKnLzfLJlpzFy3uhuLkzcXyiFaObGIqQAfrD1yec7UPNh1zKvIPJpWmt 1xwyyFzNwOKck7kNA4PNX6jN56wYx+zN1gPOflNG60zO8rzMkskw5mzHCopd9Hwk/NzNTHwg 9Jw57FvHjpLPPTqWFfAywawB9JmdAV0YEM3JDP0/VOydRTLR41PO/2kB/rf5zz+QoBStzHhM RSNNxBltLgeNXQlr0h/d0nvcsJOb0qL5oa3MPQqKD6BJ0GPsybUsnzk9DAZT0Kdsxn1ZnwBh ElOcT0mTN64Qz0gNKS/Nn84MxrwD0qTpOarQMqRTCU89h1AstGXc0KGMzA45zEka1lZx1EG9 y4wJv5M8ylqN1rtc0ZrEy3QsxiZqxCjN0b7zB3D918wsyXztx8BMyXhNNno91waVzqui1qZ5 id7pLWqKP1vcpwcEkqGpRYvKzq/oKZ3tCFQd18k81Iuc1cmy1TR9oq5kDHxySJU6qlANqiEh 27Icpy4d2DZC25+q2XocjpzRQwBprCZkQbb6/hvjGKvEmkIhnNzGPR336NwobBzTrcEyPMM4 bMLoaBwbXMPxqKxpw0TSek7FNbIKDLveKL8F7ETtS77wPcHgS4x0TRQYld5eu97i+7psK70P Fd/x/ZFYxLf2it/uW70IPq/t7a3a29oCfoqMfNacGL89m7AJHsETBdk4u7/v3czyXQqoZRJq NVr9JA8cq9+Rq0h73a7Z++AUOYu89b93HbgmDq/UcLQqTrvvi9gdDrTr+8efGE8EVVWxNLEd a1FGm607Xrws3sv+/blZJeRDPgo527k3/rWL3b1/WyUbQLUUCxOWuwyPS+NV/lCdm+R4BLf+ 2uT361WPBVwwyxaY/pu55YCxSNBRWQ63TtW8XvXfXGG5dy26Im7mEz7AWVsLaa6dGu4SR4tU 2CToazCxCGznYlDnqPhTf57mbp7AU/7oeTy4cZEEYF6g+mTo4oPpap7of16ZXO7n81vJUU7A bQvlZ868COvP0Gvfgtq62vq2wYtKZi7nUsuwPh7ht/69us7rzGi9ym4UwA7jsq6vol7rHB7i kfCsP3pUe268z/7rXd7fdq2L1W7sfXyNRH7gjM3slOjskY22Cs7gGN7geWHuLS7hqnvhEL7r zb7h356x4X7F5vvjkW7vNp3shJ6/6Iromo4UlPRNnb5YH97rblju0PpEzorqoyiBqYNPVLdV Xau0QTCtEdKCF/o48uUgLWRxXVjNcAT/r9PFeTI/8zRf8zZ/8zif8zq/8zzf8z7/80Af9EI/ 9ERf9EZ/9Eif9Eq/9Ezf9E7/9FAf9VI/9RiWAAA7 --6c2NcOVqGQ03X4Wi-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Nov 5 06:28:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wv7-0000Fg-00 for ; Mon, 05 Nov 2001 00:43:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:17 +0100 (CET) Received: (qmail 7303 invoked by uid 0); 4 Nov 2001 23:12:53 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 4 Nov 2001 23:12:53 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4NCrE26317 for ; Sun, 4 Nov 2001 18:12:53 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 23:12:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4NCMW26029 for f-cpu-list; Sun, 4 Nov 2001 18:12:22 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4NCLj26026 for ; Sun, 4 Nov 2001 18:12:21 -0500 Received: by moria.seul.org (Postfix) id 6A84314630A; Sun, 4 Nov 2001 18:12:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas6-154.vlt.n.club-internet.fr [194.158.108.154]) by moria.seul.org (Postfix) with ESMTP id 3E121146309 for ; Sun, 4 Nov 2001 18:12:19 -0500 (EST) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D47D31794 for ; Mon, 5 Nov 2001 00:28:12 -0500 (EST) Message-ID: <3BE6236C.36AECE11@ifrance.com> Date: Mon, 05 Nov 2001 00:28:12 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I have just learn something todays ;p (But how do you create the diff file ?) First :) Something goes wrong ! ------ Warning: Variable 'Bitrev' is being read in routine Shuffle64 line 298 in file '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20011102/eu_shl/shuffle64.vhdl', but is not in the process sensitivity list of the block which begins there. (HDL-179) --------- Euuuuh ????: check_design Warning: In design 'Shuffle64', port 'Clk' is not connected to any nets. (LINT-28) Warning: In design 'Shuffle64', port 'Rst' is not connected to any nets. (LINT-28) Warning: In design 'Shuffle64', port 'En' is not connected to any nets. (LINT-28) 1 ---- I wait tomorow for the end of synthesys. nicO Michael Riepe a écrit : > > On Sat, Nov 03, 2001 at 05:04:42PM -0500, nicO wrote: > > ------ > > elaborate Shuffle64 -gate_clock > > Error: Can't determine type of aggregate or concat > > in routine rotate line 181 in file > > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20 > > 011102/eu_shl/shuffle64.vhdl' > > *argh* Synopsys caught me again :( > Here's a quick-and-dirty fix that should work: > > ======= chainsaw ======= > Index: f-cpu/eu_shl/shuffle64.vhdl > =================================================================== > RCS file: /home/michael/cvsroot/f-cpu/eu_shl/shuffle64.vhdl,v > retrieving revision 1.8 > diff -u -r1.8 shuffle64.vhdl > --- shuffle64.vhdl 2001/11/02 20:07:45 1.8 > +++ shuffle64.vhdl 2001/11/03 17:18:08 > @@ -148,6 +148,7 @@ > alias uu : std_ulogic_vector(U'length-1 downto 0) is U; > variable yy : std_ulogic_vector(w-1 downto 0); > variable xx : std_ulogic_vector(w/2-1 downto 0); > + variable xt : std_ulogic_vector(w/2-1 downto 0); > variable cc : std_ulogic_vector(5 downto 0); > variable t : std_ulogic; > begin > @@ -178,7 +179,8 @@ > xx := bit_reverse(xx); > end if; > if i >= 3 then > - xx := xx and (w/2-1 downto 0 => uu(i-3)); > + xt := (others => uu(i-3)); > + xx := xx and xt; > end if; > yy := omega_1(yy, xx); > end loop; > ======= chainsaw ======= > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 4 22:26:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160Wv8-0000Fg-01 for ; Mon, 05 Nov 2001 00:43:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 00:43:18 +0100 (CET) Received: (qmail 6849 invoked by uid 0); 4 Nov 2001 23:15:21 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx024-rz3) with SMTP; 4 Nov 2001 23:15:21 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4NFLl26659 for ; Sun, 4 Nov 2001 18:15:21 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 23:14:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4NErg26377 for f-cpu-list; Sun, 4 Nov 2001 18:14:53 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4NEpj26371 for ; Sun, 4 Nov 2001 18:14:51 -0500 Received: by moria.seul.org (Postfix) id 3597914630A; Sun, 4 Nov 2001 18:14:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id 7F917146309 for ; Sun, 4 Nov 2001 18:14:45 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01888; Sun, 4 Nov 2001 22:26:38 +0100 Message-ID: <20011104222637.24068@thrai.stud.uni-hannover.de> Date: Sun, 4 Nov 2001 22:26:37 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <3BE47D3F.6495F365@f-cpu.org> <20011104044340.52796@thrai.stud.uni-hannover.de> <3BE56ACB.54EF728D@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE56ACB.54EF728D@f-cpu.org>; from Yann Guidon on Sun, Nov 04, 2001 at 05:20:27PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Nov 04, 2001 at 05:20:27PM +0100, Yann Guidon wrote: [...] > > > i'd like to see a "textual" architectural description. > > > The choice of an omega network looks curious to me. > > Didn't you suggest that a while ago? > I have analysed it a bit but the "routing" algorithm > doesn't seem straightforward... It's pretty simple, once you figure out how the bits move in each stage. The bit index transformation is `x -> (x + p * N) / 2', or `x -> 2 * x % N + q' in the other direction (where N is the number of bits, and p and q are 0 or 1, depending on the source and/or destination index). That is, if you have 64 bits and want to route bit 17 to bit 23, the sequence is (using the second formula): stage 1: 17 -> 2 * 17 % 64 + 0 = 34 stage 2: 34 -> 2 * 34 % 64 + 1 = 5 stage 3: 5 -> 2 * 5 % 64 + 0 = 10 stage 4: 10 -> 2 * 10 % 64 + 1 = 21 stage 5: 21 -> 2 * 21 % 64 + 1 = 43 stage 6: 43 -> 2 * 43 % 64 + 1 = 23 Where I got the `q' values from? Have a look at them... if you take them and write them in a row, you get 010111, which is decimal 23 -- the index of the destination bit (one can prove that this is always true, no matter what the source index is). It's slightly more complex in the other direction, but we only need one direction in order to calculate all the switch settings :) > I preferred to investigate networks that allow better signal > integrity on the wire. Think about it : Omega network stages > have 2 wires that cross 1/2 of the shift circuit. This means > that every stage adds a "worst case" latency (concerning the timing). > I tried to find a simpler network where each stage is regular, > even if the stages are not like each others. A butterfly network, maybe? It's functionally equivalent to an omega net, but uses another layout. I don't like it because the final stage is *really* heavy -- in the last stage of the 64-bit version, there are more lines crossing each other than in the whole 6-stage omega net. The omega network uses the best wiring I've seen so far -- there are only 2976 crossing points (496 per stage; max. 31 / avg. 15.5 per individual line, control lines and post-processing not counted), and no triple crossings. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Nov 5 06:40:40 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160YZe-0001nk-00 for ; Mon, 05 Nov 2001 02:29:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 02:29:14 +0100 (CET) Received: (qmail 14882 invoked by uid 0); 4 Nov 2001 23:25:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 4 Nov 2001 23:25:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4NPUl28781 for ; Sun, 4 Nov 2001 18:25:30 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 23:24:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4NOv528389 for f-cpu-list; Sun, 4 Nov 2001 18:24:57 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4NOuj28386 for ; Sun, 4 Nov 2001 18:24:56 -0500 Received: by moria.seul.org (Postfix) id 4DB5614630B; Sun, 4 Nov 2001 18:24:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from localhost.localdomain (nas6-154.vlt.n.club-internet.fr [194.158.108.154]) by moria.seul.org (Postfix) with ESMTP id 04D8B146309 for ; Sun, 4 Nov 2001 18:24:46 -0500 (EST) Received: from ifrance.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 2DF611794 for ; Mon, 5 Nov 2001 00:40:40 -0500 (EST) Message-ID: <3BE62658.ED8E0D29@ifrance.com> Date: Mon, 05 Nov 2001 00:40:40 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> Content-Type: multipart/mixed; boundary="------------99E5611E3A874D1C7F3CDD28" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Il s'agit d'un message multivolet au format MIME. --------------99E5611E3A874D1C7F3CDD28 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A complete log, sorry nothing really interresting, there is something strange with Clk as said in my previous mail. nicO --------------99E5611E3A874D1C7F3CDD28 Content-Type: application/octet-stream; name="shl.log2.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="shl.log2.bz2" QlpoOTFBWSZTWcpbogAAL2N/gH9y//3W9//6P+/f+r/v//5gc794vg8tsUVQrbEqSQAHvR6t tOA8kAAB4d7YAAl3j6wFFBSgABGsUUAAABQC+w085nIaNjUAAAoBQiZAAYApVUEqqQAKlSVI UAiBRtqElAKFAJCKgSZACmQAUAAAUZGgBQAAAABEyABooopQCgFASGigAGgAAAACFTIU0aCg DIAImIoAAACgAAJAUAAAABq+sCQAAAzR7WhIDLtg2wF2rdDuooaHrToEigmgCAJkyZBNJ6aT NEp+mIm1IeUBpoDTJppoek0aP1QSQAqlQekDRo0DQBoGjQyGjIABoMQANBkCpRv/VVH5qoBp iaNGhpppgRiDQMgNMQwATEGQMgEhSEDU0aPUEmZTepg1E2k0YGgnqeiZPSDJmp5IZGgekaBF AQklSSQyGRkAA0AAAAAAAAAAApSQTQFI1TPVTE2piNqNDQNGg2iNAAAaBoekAyD9WfyfxSFI 0ynrCkofqzKkogbAAAEbqBNAUBtNte5qHq3er+/0U380t7ZDDs7pbuGWw+SqPm/KYs7ltqvY 3v+uyupa0so5OBrr4gO1XDlrMet3UCYCpO6kHg0BJgu8CKd+ITFvtsrCz9PFZHlNc6jI1tvV hN/2uwBC8AzvysLk6rnhYBnvQYB6jlSDCPLQgGq0GFLmkIQI9xYWt4pCF+6sAXFAQhUwJQEK Rgt6JAzPkS+gQhM8W4VhGDAC1OoUBgPvEOLqBc8CAhyOMGPEnvSGUwGoYCcgYdPvDFLlLIpU YMclOQDDpTODEq0XVoYxY/DA61FVzHCzXGGXXAvSC50ILY9AQFt91geDa0mxCsLt1DG2uixT eTO3VYaVv1osaETnAMJwqrExCCuYBhYKqxDGiL5gEOEsMraGN+4QBM+YdDVn1jBAmWJB0SUo tgCmudIBp4js2QMRYsIaCcEuaIXpQOe6kAWSGiRgwGgUWDoJJAYYQaBBoQ6Dm4ZMQollCOcA g8u9ogZAg45yAIMAkQ6JxnbIXrXQC95VWBCkKUpa1AG4GWy3tGR5Lv2dsMSIwblCHYgNuJQM TlC7HlbhKBgLU84mTRNOmQVK7FCyLO9chrBZUIzN1SAOB7hFWoFSIT2lAbcjoZxNfSi9cOQ6 fNdCgMqylnJ8kVZ1enPCwsDSVvQLUlSPEpCxAzOBh4S/VAFhtepWDpSMLUwp6wnUoC1neBvk pIKlK6FpXkrniRidckGrYVpAus6QkeGUu4GJCLgJahGIxA3IGQ1dyKerRQVChDvWt0YVZ9IE wspEpWUL0crRnbsmGuubK6to46ymLRx1jFb76xBi4SvMYoxOmhCpI4fHG1cQpdmMNJL5ikD1 TJkkYkSs2ll8DcYMBc8QOr5eJgEZKHdGEDyNg8zvCvIUxOrQnYwjSZ6BBPPZlCRImKE8VmHB vC00x4EMsHOEwGqigUZSY40jtG04CdthMK2sGEbwMBEWIYJpICsQo6hATYBo2naJ62zs+CAK nQYU5yTBN8DBPYDBLzIMK5dDAUeAgaHBKi1eh7RncAhGv9xgwFJd+SEM5IQFd6QN/VpAnc+G gIZjAxsh4EyNyZiNDHebFepPORC133eZawDQ9XEmpNZDFW4OWMgkK3kMPVMmUkBAENXKdes5 SQPtCAvUerraxywhnqldsg8HWEsxIDXA2dLfDIG3KDITSEoOsldMW/GvL6jq3QTI5nUiZpQ4 U8t1NjTz5b9YpbXttuW3dh+onKJubpqyadEM7sMUuSnqnSuJsfeui3vZzOm73Hdtx9IeMK3r iswzn2uGyoqDpaLbQZO/LlxAxFcz3zS+kcw76KQcCEaMSgbRiVKm9GLNGIfGGsClgQWtFqp8 GHdzSSxh9Z3Ulu1oiFIctWLVFsWRFp3Mdkxq5m+XccMsxkaDk3W6O/NdjREb3VY+7lZDM3hj 3V6X2dEts6NGF5bOO86bG49tEv0MSSo3p3tpjc6JbrZyGmLW3Pbzs9KpGIhVPPWZWpngoJie C21mx96Xvn5txmfd62d4S1GBAGBhgSYGcjsgZO+AaWrGtYWY3Nm5RPiPT8rxeQH7/KI/meTT 9Wy+6qhBnBgQDGwJ0JhAf/mz9nXJJ2IGljAi6NkjHThm5tdrqXDGDbbGMbWg/Fp64aQZJ0pG uPb3/o1aoWfmrlyL9h1y2HVaRqX/024PD2Qu4zjlXgEf36P4eiV1dbbbbbbeaH7rKhfjI29d h2FWGYgfP0kNFvrD1ePn5Urwh6kaTWHbeTOWvIjoOmAbX0ygxsaGQlD6n8btU/YwxhhkRSMZ WMxlRQkIL1p5dc+r84d1YYhhAWcaSEIEkj9QNO2SiQr9TkhSPeB94JQm2GlkqEkCQg9AegLf PUJJCSQTszOlNWrbnpie7lCkJuMpyj4Zs4c/1hfa9NJB7wlpZVVXGNtxeR22/Ynxl2x+fq/k MsmTBjMxzVJI1pfpB+ndop+Th8xricqwuCWkGibXZe57+3Cz4TQFvUbK4dRtWtbSagTCokBJ Jm1DkFRAOgmEgLDUalAfOGaml9mVMLSihmRiVirC+TC5hg01huFgjAwFiQYksEYCHHOhMhmQ 40HI4YZQw/A2rZUMlD4WWyVCITUaOaSWw1Kix1hJYuOVrRQYEJgIDRcLQViKMNRixHBotRis LCzjCjVatESSSdNYYryUUw7v3RnUnk5VjxW3Ga932lUq4OWm6aAag0FqB1U6p0ToJ4E8geAf InhDwh5E8q+FPI+QPAeE8ge8ePHm0ZLuOXAcizjkccBwHLg444S445HLgOS5mBccI4RwByA5 JHAcjyvlPInlfA+8J4TyPgfC+B8o+V8J4TwB4XyvlfK+U8gHkDyngfIp4Hy+BDwocR6AQDCP QYXwpaMCUqHlPI+UfI+AeCHFToD5TwLCeQlIF8sDAAeBfD4hIHg8TQ0PCU9HwkhiYAZgGJqQ lAEDaBKBI9Cx6Mj4GgCE8D0U8oeS1NEOCngA8i+ITpK+kCBlk8B4IAhTy+EPKeUPPUHz5API eRfIeF8j4U8PhTwJ5fC+U8B4Xwg+fIHhfAB5Q8qeUPAB4TyD5Q8A+U8K+QfKj4TwAeAPIvlD yh4Hyj5Hyh4U8oeBPCPlHyC+RPAPkXyPlPD5XyngDwPhfK+R8h4HyHgfK+V8j5V8j4DyHlPA HhXwHlDynlPCHlfAnhPKHkDwp4A8IeE8g+VPCPlQ8C+APAPkA8iHgTygeBfKPgB8CeUF6vgh 3BlM9BsMQcgOoG2IYMSWpdT5ZOwM5kqB70o2AwJ0cq5+5jJISQkhJCSEkKFbKjoLuOFYxGdY GIP4RwkIA9kE4KADZL2FgYr9e7YWOh/RglDZz71hOHX5vhqaOhX6gtD7ABpgxGqjV3m1ftUv j6OPHxzZTMNZ+Uv0BCJ4h/8/F9Mevx+IhMyUUsxUpGv2ej5xdB3dV73ZlpfaxEaMDBh0ghnB W6UQU2oIO4DoAT39Ov3xlc7CsGPy9MWX7pov+MucUG0nbQqRFXXEC4mbQsDjiGsKem1FcdJa ECRGOmXuxpOMdH7r6BVb9scgdY1ohh+HsCoqeyCEQ6qGduIcjusUcfdbf4sspfXmC+720U69 9XOpBBT0HQHfXQsrjlKWu3Qg8LjTeaJqsz1QfyWeCCJc6tOaC2XdMVcgdhnUC4jmUvqex7Cf Pnqh9f1+Hvbqry4rHJaACA+gAjlvFOO7P0oI5q9cyitv3SMY7a0pR2VmXAhXhSK41+GauaAp OmoPRX0XWV+bSlAA/vU+VqEUQdfRPMkZdYZs+3fjXCm4+ggwrNawpoV1bwM3E5fTHb1bo8y7 Dj3dGrPks+uwm9ChbF6ictarVez6buYBEQ52HXA9DOzLqjUsbACOn7+ryM3ldutOqiO5nyAn L6JdS/fy1vul2/GC9FKqOk6OpM5KlVHSdG4zcpTfn+2s3mg1AeZJ0yS2QETkaUmlMSSN4xJB 97SOaTXUOrq1/jjLwX+8FPf6mb6GOq1WMCyOmoik5vllu8S+iUAvQv+v5YcS385jD/k8NBkI /p8wC7wN+v+s9hxytIIMvsmAitDQIbSEMOBpAYWUDiMwB39bphNapBYcUVxnZd+07ZxwQ9QI RnjDHF5cPP1dXYpXSusFABlK0w+yE6KS7AAQkB2n1Hm7om89CiSCSCSkfaHk4/7ddDVpgskt OmGJrpbRQShTgHFFjYmWK1atSqEWaciFyIDRYWrUGkmnEkmlLAMvQcToZDDgw2sMw7PKSnQ7 uzqqqy8qSVywRgtrLzZmZmZFAAAAACshaMQAAABTSIjGlIpQNcK0gyTXiemZmZmUZuAyCMHE YJSud8LI4BAQw0HWktOW3ankMSFkSh4s8Cgoe6+eJSEthYWNt8cEsJShIZDBeB1tA8NvECx4 6uKSsg30cXqQnRoTi+TExCBeLo4riWPkOLCdHqGpq4Pk8nE4BidTq4mIa7VutVQEASOBgnEh LSkuQsAtJQtLEg14EPHrRwoDgpOaQkyDVRILUlJSLONMMLLMDTVNNUsF4wyeMfBQMoFrAhCP kcE54Do4vF1GwoHwHYCAbBpaU4uvVIMfHjTr488OPDgMKQcMXFrlBC0hQJcsMXCIBaDpwwMD g48QxSEkaAkXEJSBwXVgQwWAToV5hLSJOcSAChMTgljKW0HQJHr1OSEgEIFhCQBnR84OJXB4 PEkZGRer0eg4LQGAEscfUWNvE54wTdAgerwGgPAwrAHRdDq0mK3UOBx1xSsKEsDAbopEQJnF m+Lj0fD1sOVerCkPQ93uYLCNobOuSLgtLt8DMAOhXLE8hDgblCKW5KI24QOmrgzoFZ2SDInZ JakRPnzeUtdoKQsGFOKcXl849HwFNAa6BxShLfIeeLjxcAkh8hLS0h1CDHUJerXBPAScCUPP lzQMIDUIcXeDqHiwpDjQGnQZV6JAJwTGV4OvejjSOhSFOqdcE4nlxxCggOBS06hwJDy6hLaF h4derDqGo9XrqFodWQxG2ROAeSBeI4qeRKEIbBkHoYvh8upaQkNJb188ccePnz41t88cTXyW PHiB5LEpp6GvG3jrx49fPnz58+fPnwYksh58+S0xLbbDQGEbA1DikgEAHhZApDRJUpSVOLqv EOqSJKHBNA6hgPBKAkCAIEtU6D0TEYRpG0eI8R8rCPgDACQMQLAwCwDUToliarYloNI4LCPl aR4CdBKEeIPSkurhDAaQtFZQHKw4LLRdhIxYUBwSiErCCLbk2z11WbpIzEomwbcClaZiyixY qpgbtnpmZmIiJkme7n2I6Zla1ogAAAiIiAAxjGIAAAC1rRFAXfd07kRVRF7ERVTvc8xjZuRG SoLQJICBUB0AAdgGFUPAuKogj4FB4gzPGCeLzxw546CgohhybOI41AcBpIbXpiaOMtM35Y7I eJdVw4tTjMQA2Yw64MESkQirFEgtVHELdFKCMAwcMWUtgTwBbgGMizI0hOgStSpV7FNpjsSn UOY0X5SFMRpA0DmpnJU0GIXhSTTkBykBxEoO5bhaUoldhYWKIAUgW4XsMJGp4cQ1DE0Chp8h 0Jbe8EkWyzsNrr7ykT62UpgToWHHgHuIdDUoWEnolVj0Dt00rd6qYCba+SEbCgLrIInUTjzz YvgTHo93ZJxSWWIgdEtoOoV0XRmtbY4vQLR5acGc9YEGXXmFp8a+0IYtbWhnwYtBmXavVb2w 0iu4AajAliapkS2JIQGuh25CQ3uCZSnmkfNK3BHV7CGAdzO6LcoWkCQEeXTb4m0u8hKGdJlC vIVzEmlTgEr4xdEjgl8YD1BYspLSeGwkYqTEpm1IOD0l8hHFxgOHp4mGLIvOj1DQOBilhOJ2 elkvAcbHwdieoECbD1ZQkKAihGG0lGjEJDDDqMKsdhCxy08MUzihQ5GeCoEpJeuta2FOnBqk oJdXryGoCtaq7PGrrzwOyvaaNE6wtppxl48t9fcTATDoHR7aGvDUwSqW2WRqgbLsOB1CwJO1 xswbU0hDoVbR1DUeJkvNCkged6EBRQyus4u4wSke6J1DEhKMceJ0a4YwEDwTYJ8vVpQ54CWV pNUiWg0L4hTZrKQ2dKtqUuOgaL4nHq8RuE1ShIsfRSEJINcA9LQMWhrMIeOpXQ6htUnhZCQM s6J1CqUyNWgKgQuV7yKGEBhBnMtBajmJVrtQQFgQ6GYGRkAR3yVbDQyjoS5XggAyRdLKi3U1 hq+r1TE9nN8uBb0vaMb5ViRXJ7yKgXvk6gT0CxKtB3kR54hNRjScgy/KYul6spqSB7zd2PeN vXVOOpTg71rmJxnC0IKTikjgJ4eBDAHNY824IeCsXyvRNZgYsKw9K9BLDJpwGep3iEGYhqng qGUgJNEqF6UJayDPDtexvKx41aFicVK4qMzLvUh0JgVqQGFowmxCLDRMBmHaOtZV1pXYM7pn expcS5ZxYwu0KshuhKTo5eKciZqAaXqEXZx1xOBweYkgWBa4rBDqXzlUtpyWF8l8CLFkTcUw A0PBEDzIqoHEK4jmVw7EwrCJSOq9rY7R5OBmFxqMoApnpEYAbYahrwwZxDpOysYh1JMB33Bg Tq2mrDIOJZbZiO2HU66+DPauISE69fAeGV4rDGbSwEEiJU1NDgDJJqXw9y9eaWduEPOdx61r 8cr82dwy0XN6JEHLRplwNdGxuAfkDRn3MfQaDelE9QdKXEPF9m946bPsvqn3SfWX4U+xtZas n2m0vwp9ly4MyW0/Cdq325HNc6pynXetTzt6HJzqGC0L2BsCUPAEpgQEumrp5lDo+eoeTy6k pHBepVl1DSTRPK8UphuyuzmnXqes5KRGlFlkA9VW1kvNd24cMA/ujA92eOJISAQWCASIQAoE H8SR9X32KoiIfsNQg0NOliRWGVVIFiFmGGAGYJgOKYi4hihgBiGC4qYqOKGI4hiGAmCOKO1H qqQpEvsf8uAPx52Rf3QSh07Xx4err5zm/vfO3bV50ujeam8ylNvHWS2ho+BgMfD0WklE4BSW FO5c80lLhHyHFKQ0XoWuIyvBgcdcUwA6h1HqNgar5BgIKmcvtmdqbrwBJID6AIBIQf29P9cn iGvPEjveq2vS1NJ75+V+X6cHTtPy9t97rR4xhiymQ/d7T5tdt+a66V3NeY7H6+35kv3+I8c+ rPFnbrNes9z1cbZ9K7Lt53+7dc+fk1Xqb3XhzuOh+Tga0LoB+ZmOcd0TNQ/wc6h01Dqw8d9d YnctcW+vht2l4tlxht4PtKAoh/1gBYJ6vPPx4ZPEIxsC+H5d8PhY11P6Aol4L8nADGBCA86j 6gewhfJxwCUfk4FoHPmU8DDNSh/rgs6AQBwPPQTyUP7xib/CifxxIClgX+eI85oM/cT7A/kw OgSOBDky8hysElhTwF3YE9Kfw66xmgcHx9a/+QF60vuBD+/gFOf43Q4v5Dqfk8jIJKYE9mHi an8u7CmEqnF3TphRwHRe5YHE4HNAzTBsA7ML/OB14uBwHV8xqueI/AB07fUNtDV8L/h1G/CB hxCwn9U8Sp6sqdfyTwZeX73PAHwB62KRJWgNDrwYpPaESGT+RQg4rxfyHHUfg9nuABOo9SPr fwQEh4OWJgPkJwLuQCYTxz3wslpOcA75+RpE2FPCSMqRCBovyHDpMS2VoRdeI/Kgf9VH83zU P544NI/2gnniyuSugMu/fwNhDCQQl00tQRDqS+FgDTj/AUrqkCpPWhpISPkhkjAdPgKC4Ih8 BwPn5sNRtDgFgZ7+QA991IWA/e/CvUg/OxjDO80tVusaw1tGm2HjGqy660kD7tQQGJEIyjgB +CywCCGDHyyHlS2bLYZHykMIfBS3Xkxn35BLLx8cgIHWSzBS6Gg8BBAu2nm24aYNIfwkWMC4 hCyhCD1OjzGVtUyAA5xWRH8vhwChYWFwgDWBND8AbxTXofhRONvQkTqfgdc4i9zR+hxYZBht CIsZRqEtD6qEiBhgauVMRhbSB6/hk23pQTDJ2VlNZDVG+p3s0YOt7VwzLOJjwkDSEIxuS0dB o66LQtxoGflEPDNJ9J1EhGpQNep48BaQn1AzqFk0A0EElsNEyUvAJghZGKGSYQiIgIgiA96n hZdoa5CFoEmDrWVmOz9sFXOJmSisZUItVkQlgykmMELLEy9Nszj+B+pW7avxc4nlPacB8h7r xVmR8mFOglLYGMRj0SQPIUh/k91SeckLoCuAWkjAVQvQd76FJlXolKdGUzcAMyHFyKaQag1L mBamcN69qgrXnQOIRgwwVDM/M9zMPnHd1VA7BN72IDA48D6P9ZdCX3vvx2WyIboSwyyyQYSK uKynAcELHDBcEwHBMUxQcQDBcFMBxAMXFDEHEcRcRwDFcVMBev7n3+nGHToP5Piq+N7X93ft dF4kpbYeFwHyUlIaGpaWQp4NCFCkLcWUZXwPFpg8EoUOCyBXHyW8vZZ8nR0CkKnBlCA6JrqS 0vnW18Iyh5GAKFoepgc6G1znqquYyqiCP6okUlDq+a7QM/B8k003j8/WGBuixHyHRKDr/n/L 0LE+Qj3psIXj9QXY5IFON1BcIFocDU+eG81Snr20MFmfd6pY8YEyOp1YF2lxoXqPuCRFs4sC aFRz7C7Vt3ams56u/3n1VGOHWLeTi1HRWOn5PHVtma8d9bm+UYbmLTT1RkbOjeNXyfP3tFXp 47+LcTtnWEZcJoGzFZirMJzc3v95unGErMFbXpNVdZV+nYnGRswpZWLWI2e9DeYZb6dVlrFm X/rVeo8l91XV9Z84cnj6qT4W/Hw90Zdjrx4U3568Pdh0aMwszK7no8G7iYz5p4ZVd6ZLrZjj arWW9MuMWTy3a2VrVrGMwWsqLcEkQqFApSBWRhWkNJROwKb4jisqpxMg2xPQ2GpDMq2ylkwL DJ3nnUtzC3yl1TAEsAlQkjCdB/I0p3MEYYUKRylxenj6NxzMdGUaysmK+nZXJPD+aeXf37+D /MohaZsoSBimmgf5vWi3+W0Xh7Xupxkm0mGulqjtTEJiEAljAWHeNKFwqjBAp5WGmsKecZON Vtgsym2G1l2YN8rUyG6ZbZVu5OG1G+FZkWYV5mA2mA8sJvkbDCVa8ZTWyxTLKmRrRaMWWIc9 aJvhbmVYmtB4vNttQyYDemVWWKTADJCgQSnFPzjGyi/gM+9M/yI8b5K4Y8Ux6ofn8mwEQIH6 QkWWEbR8/QlxG9c0YawswrGXNa83h77Cgu4QsEKRDrIkn5sQP6kXMFrarayNVlLQyV8wtYMy 3waxRYPFeB/irQcYUdfJs0DaQJLAjFY1DC0soYWUfFIuyu8bZBP1IT/kxgi9fH5Pw6pYWCWh wDjeAVv+Fc1E1+EuhNfytv8EoS5Dperm3N4yxkyS8WlpVzTE1lGWJtT5tvvLVMVeVeV3WjOI 3TiNRqbxpWq2mExGVWJlbLfUbzC3WJldub4p+XJmVjCxkmZTi5yjlZWaTS0dnDiyYTJiP32E jihwYYsllNSmfIy2ssRkydtR9yiDwPc8G/01nvmU+6+HZ5Dm5Tfajuj0X61e0Xc1fnOR3p9e yfLqTDEeb6bHuXTzdqbrtVlhZ7p7TdOre4MVlcI2GlmVtiMTJgy+ldtq5pN7eMtjI8GLSsHO K8VfVULsrtuTky1gZYRhAgSVYd4BwFAeC83V4sjLFrI1DI2t6TS2WJlgxeoSEqfQn7+8AJwE TwfdUeLARCwDCBMj+DQXVFNQ64BxGhJWiuyan3KEO6cxl5vMaj3MfF0UWlwOi9A0DjXRSwP8 aj/Co8husDEyq+L5VIluVbIvhMq4rFWspamSd75XJRckuKamgpCEKmYg4qlA2LAkLAqEDCtr OWiNopSsAcWEBkckxbQalNRkDzPMMm8G0trCMJAJCQCQP8Uic1tDBGhanmvO17TtC5i5l55P BauKt6PiUh8DkvPoavPM387ba756uXcR3/I2xKXXU8oOgFB+ATwGP+SShSsJKNAdaA4/4D3E Q4H8hosgcH/GAjX9+pRrUwoFfigPlIUtsFCQMYA/GraqhdofqAZFwGP67AT+JzxMFlPdUh7r euadK0nc9eYf2xf3kQMf8fKfgeon2fgsB9ECsaH4X+BGhOPaVQr8wIfefCc1RcSiE1OFPiMA VvEIWEf4H9uAAFq9A5SKHQhVCoQToGEgJD+3xag4jgfKyhjT/Kh+A+R/P8UP4Cgkr+/j9svQ B/eKeHzSUJJHQYSyvQflQxP4QO2x8FALaFiSiwaMBKpholAwPUNRwRtwG6BaCnoOvR4eg5q5 OKzJqTWo7mza7lj5qPPjirhO05+ZPgd/VY247lafCe5fA1L5L2naO4cLe6uXyw3riuLYMIdN ggfh81x7HBgNhO6Hk8J5OpcCSFqEQvAh1p4uUd8EYJOITD4PMpKxnWwsODCGX3L2J7h5xxvk xl8zmd2GA97Ls8kewdWmwpuUhYHBi7tCkS0DEwwTFcVxAxBwAwHAcXHATAAwVxRwBxXEcEOI uKGN935P4czMzP29ccV2nkeLZ0349Ljzf9/QL14EuPRpfJ5DqELbIHWQMNBotSDokmrbR482 EMgytoXMJ0PBIHl83JqHROLbLjwDXWExSgWAOIhCZAMCHBzgO1ZVVl9VVU84UXvmtYtp2adb 6GU72rrA72G4EBQnhZB48U60HyQnLkEmD/ShJxZZxOhrauOTa4WVHSxgzfHRh0AilIDGG2G0 2XhFu60Ofsa+Eg0jXwz5Ilfp4apJ5h/RUHXCUMuXo2BLS4yHRISwkD8FcF7PIHiQPo8iQnmC RIyCFYxPuBoYgfWBqWO1b6m/Pj6KO/W12rKXMMXRuz6q9z7z61yWVPpPE5LavE1Oeab/K4r3 ygLC1zotgBbQRB+NsEtbSAJFZLgpGU4WKWXBj/lYLRrCJKBiaMXu13NTk2Wu9h346fEjs+e+ ridB2HUMAyWlTr+Ufg/caFKMIR9ClIMKZSlKFKEK1KHAClClKBkUxAl9NIDaWQtBv2CvRNNc gltUIBPzY/wkC5QoEH4/DDYGgeUoSkD+P7f5H+4Bf8gW4maDLap5Q+SUYaAwH5gAsBwDIVe/ CWDSDy7hJS1GwxYBSFgAgYA35JVzACVTIAkAgWQhd4WAUresYZbLNqMbefEXn1lYuOj1mTcv JYU/g6Kjym9eh+QkA8ZID5jn5Blf3jEgxTAT8JTdIyP3k/m0TuHT3hDFC3QT2CFghZwVgH4e WqFwrYM6T5LBqxxCaQI4jpKEPUL5lVe49KuctHr10yzmBi2q6/xjw6J+2Qf8J/CJ1IRYTiP5 +QsFP8YFfm0X4CzPS9DAGxWlkBhA8LIL/ztB1wT4RwQOCfNvgNB/jUTROg6ypD/Lx4JoIWJ/ gBPhccTvH/B+fxmYBnu3HgEf9Gkvyykh8jT8DHx9qjpIH4A/i1JQSwaZVGBeiQFg2HFxULab QYSQ13FQqwhNaEaA5ILonF0MZQ6LihtG1b9T5745qOVztTExWq7cuKjerjJwMj0Lze7yXqtT R427fTsSetQ6GJ5P4PjwOFAUHDVf8AmSgV/gFP8Kf6nyh8B7UhDUBsQ8hgXaKWIceo+D7jqg YAYJosq/pLUCpRIYTvT2AJbixyAIoAYWUZCZDbEsmksNRVgxPE2i22g4TK6sR6lR4ltG3bz2 5Kvv3+ku5YdqevRaw20tq68VsrW2hyZfNaAWrf91SkP751thH0EMEhduJaGFxXxbG6ZTvLAe wnad7e9DsP3u3f7tH3yif4HH+wfy/yfjwh8lD+sAniXYJ+YxSAeqSshjcQsP8JJZatj8mJ8M WJwkv5e5HW5TrGrgvQOvMWGLP4dAJfCefySB4Q6PvvKqf6f9213gWnz37FCs/pQD+fUlCwMB 4yRagQghIgT3ZWlCFF50kx/gkO5Zdfdxt1lLwmOsnb2S/Rb+f7T7Zj+FtvF5D5T6U80+6tTV mWe7a91stHSb2hLE0GFp0sOgGg3aBSmcX/ODWwfJ4OCQYwoeIK4NCTqQBaUuKcRyMsLtUHKk OmllKSy6fsW3MtijYuWOTJk5yMvB26pq8ZtuOc5nSgT63jaceejSyEjIdqPiQCQGxLAwwxEx RxAMBDAHBxRwHEHBTBcUwHETBcVcUwTASI1/0QzUh1088E61992tzmH5JxChI4hbA6Ji4Npq nEksgGVNXiHE4LUCSMIQD0XjZwTi+4vAwJ80uocUx4hC+WwIFoQwGGGHrrbqcdehqMIWCQji NAFCMF+DR2Oye3soOcJXUteSPBYDDEk1h6LG6CSdTvVpXixsQh0SSEzEKOBEaz5Dk026HvsV AWC1BBgWgxHJMK6BSCsRJa+XasWROPFNcT51fudwA6hAnGEvi5QlIcVlOhCFQH1owE069OBV 22+v1kfgvG/m9u7y4nHfiPSMON4ubt6nRfoNxtxXqaTb3Y83YnHGVMVg4XN1YLdQ0WbJzyH5 HE+eJoUuKebtbEgTieTKQ6FH+EG/CexYXgweLr++6Ah01NTyn5O/kITJsEhHokIQECMBqMh6 CkhT92/NK/keL9yXOiwFIaP3wlLiSyDQv1geBps4JDYwvVJGdde2H5egHy7xIH79Zzgix+X8 fnBIPcT8BgG4/fv9U6Ch/IwIoak9PxcAQfklGaHj1TAPkChN4QNJDxIgIgSSPhoSRxfOWJDI QVQ0BB+wSUiEOgHWv7fwkD0Zfv19+4Kp+T4dUtcQ0Qt+ZgCbJYmSwZ3uPFxVktzjS08qxZoE kjYnmUNJ9lg2B0a9akh+FO/FIeY0IF0NEgT954dQ7P0sfj4/HjyI18jgnRCRe8KUP2pGo/DR XmYBlPnrJ2HrDIEMgnY7x8joWIcCx5DEcQKAml7oFvApYUofkRN+/J+Qevl8yfgQ/3Fj/I+l Cz+AoQoGEIAgOhC2rCJ1Mf7VLxW1kR+oGRtSBPwSsr/Cdfcep/Mv2IZYe4iut/DmL0WQr6ET /WwIWfwv8hCMBg/ylh/UNxkAfBAeRj4IApc4Pr/eQylPgkRJUg+eKTYFg9ZGVcaWgMGQY8Fb /IoRnAwCRn3AmflfI0JocVl8dohJSWkNmR/aP5pbGBPlYAkOpr2uqd0oExTKc6W4GH+or8rg OA2HQICgf1Mfwq/x8fklSfKQmAGgZQNAFi0FfpQ/khM+F45bELoUJYfBmAwrCGHkLQoW06kP 5opplHQPqYoNJHAmwtoTWVcV3zgfP1/gQPjX8vTUJHRDwn6UdEpTjsgY/CaUYPcTE+7+eBgQ B4etPQp6BOI2nkLCQhkomUHGFaSDFkGGEMGUh/stEegWh4SRNfyfgTFSOqOMjxCZhFgG10Sj xbfHXjKOpUbo8xpXoypMdpONJwWEZXoJeRCfkLBuqknROAyGlBM1w4aFobcxE1j127OvcQ1m BwsWlLdGekVePmPfPMdSvGo3Ug8npJM7DYWukUTAQyhRbxwgMLQMAtwMRxTAcUwAMVMExISA cEDHBxAwBxQxBcBxHGcI4kc8PmnWX4MsyzMwu15bvN1eFw+NDeKfX0ZRwZ/cTnJHFPL5XEhO iYpbTISBwbEKBOr1AxITrw8LOYJwXReIYvQuTJrAPIQaBqtgnVxTqGhSFIYhgYmOtPXjjK+E pG0SxNV4jxDAvNu83m5md33cz/POsh8dA7qkjKbLn3k+6mJ5oD4KgOIcEoI08rQBAnGixpOi /KagWB442tcPoLejfA8tCUh8Fi6VI6wyh2dQhMIHHPB0MKB5xeA0yrxpMD3NHnE0aRgdKD7u +QYR7DSZ1vG84nbeufG3y+hR3vJl5uTsT6HO2InvLiHADskNP3Q9KOLTI2nWApD2BxgHz+po TQgGV+4B66DvWPn4orH35QSO+F8/IfBxtApCB+Rft7oQQh+E6Fhpacv88LSzQS2g8/ShDIWj q8aTEGxaDrSt2AUjTAPBLEzAhD76H34BS9YB4whCH573wKfDtAfmhMlGACOtAm2r3FtSkLZE +B6HUKDqELyEN1JCmEPfloG3R7iTzy/hRJc8px88H69RbZ+eCT8kI0vGVKNA+QMX0NH5Jahr rQcDQKaenXwckOIdSBdaBlt1sDyw/B1CgSJH7gvAgbHqe/Cq7g/B+/AlB16ifX8A4J9Am/vg KQiAyE+1JT0ISCEC/JirVLzh8krSdYaSEKYAp9joMAEUCYhuYRxN/CI3qGofuh1PKV4B5+AC OnA+V4sQHgTz1kwcExZdkGWkPMpNAQrAmC46LS6jqmC9WESghH8eQwg5Hb8/kRI/PhCE/D1G NkF/Jgdr4X8Z1SLB/AeQ154X5ElPhxLNkGUgcICDH74Sx0kxpcB86tngPkIHl0B2SCEnvvwI vwh8J3Q89WgLEevfUIFIiQJJ8galPAxtSSZE/Sg7YkrzXjxCG/pSwNZQxHBMcBiRpPfTQdXw nWaOlgnuz+FQ+TjfBROIwILAEP1oyvzYpEg0BJKFUUdWim18/B+fOqfaHB+RN32+XgU2aHg+ TB8dYpYApH3l+cxtA6HANCxOAfCxinV82flBeKldeFP63R6h1+AgTgwhAsKQgwAfDqH4LoPp QoOMtmOPySAaBaQuMMI4yBjQF3sw9oJHeiamj3OLrY9SA1KgSKWTSk7WFTDExgGWKsWKMspY wSxYkxhWMVJjIrGFTLEpdicS7KzlWs3GqcCwHz5m0ltttt+eodQ4hRxNSOofeEqBgjV2jhLS cwNAkeOlNEBosLGZhhD2iJSbcl37oLbkapQ7WsNAxA7bLiboNybWqnZyTkWoRYPY+E8VkTbE sWlf5b397h9P50JAsLq1okEhmwoZSj4mYsEhAkxsDFcFxXFBwQwTIEhSBgcADFDBTHFDFDFH ADFcUMAMQDoZ/kH2I84wktI/q/p5n9+nB4Fsh0KWger+SEy7A6lhxDx5CDxaOIPWGxKZWuJ3 wmwDwAqngM4NdQxi80TFpbDTz1kccW2mBxMfOPEbU8JqOuBxc4eK9PZ706+FQGLTnUaTzvHE dGhPLjoBaOKaNDbaHFTyHHw6D/l5Q681DepCNvyFC/AcQzA8Li/OP29fBIEh5oNXXOI9A8kA HcOOFkb7p0nNWV2jm3dOuPik+dPv7wxdU4BHv2LYBAjL/j88A+Aao6tLQUwjYUPLv+LTqPOJ zqcQxUggJA0cWXAtPwBQSBoGMqYvyP3M69Kps7Yb+fGRm7urLBjIxiZ03h6mgEYDj+Q6mJSJ D1/IFiUULYTjQRxCmg/Upgh1s4uCRzutB2elgxCEhYJCPw/BYHBs5mt/lEs3t2mXF4s80yym WUxlYyLivCpD0laccE40N/GB0e3B8+QLV/K88XT8HoBoCA1+R+Q6OjJaOLAlr8F533xD7v4B H0idF0JfkIIUggWMjDLymrfjs6v4eFeR2nVsdZXbpZIh+ANUkDkDvEGwraoKWn+X44Jfh7Kv A+l8ECQHwko4EP47+/Kz8OXoqZdq72hvO6b5ZW+YmVgxiEKQDApxDr1+/nHz+XyFAFJ/eDo8 cbQ14/YOPSFiHXgJ+DQwLTGElSv1oHwHB+dCyRIX5aCXgcVMfktxIBLQ16kS8ftf4EWUtF+e OCdREHgkJAEEARcAUQhIX9+ZUt0ICj8y8JkaIGhhIZ/NJ16hYQraFvft6488EBwB8nBPmShD ULW+p1MeGs7yU8r773E+fygkB5O3e5nZZTzc2R4rlULwMYmDEQ8G2eWJIfhTJZLR4m1Ywwwv 7i8toLRl6I8Q0OKw2POBIfL8vqZeIbaW/3hdmmxIQM/Yt2NpdCcatx+WXVzx+/lALvT9MiwM i+TnQxGAQgUh6DKH6n9/A2sjy2SEIF90Pm3MBkN80hTLq9NpSZPlMTwf3QDglAs2JGyhSQFL ClA0JqnbGzyXYX9ZX8or2zrmAeD578BLwz7bbhC7SwWSxTJYLFhzl3uA1JEpIIS4AySWkpSV rjEheI7zq5uhSdE0dF1cQkQ3hNg0X+E+Oi1iBTy6XcTFZAh0DQoKGhhecGe/kQCQr9rJ8HRy QEpGEUhGFWEYB9MifIHAZod9xJtHbMAkChPk6H8dcFP46TxPU5+RMBwDyP0oQnJU+5YFCaBK EpIEICB6yjGVVmWbGhGMSNYsYpqyoMjFMZVGGKE7o7y7QOo2oWwxDr5OMDb+YfmjpEI448Q6 BylgSZoDykepO+MFi2qBlMeAHVbAPEBSSaaxgYj1YPOOSEBHktCFdTTeN7QEBYTFpTgUmVPD 5tbGwiwHEcpHVBSbTqG3cjasGsSmW9hhZCO9bCRIJCGhKCmgpPVIWZjORQJiN4BgGJgOK4CG AOAYOCmKYjgg4g4i4I4piqgKEigFlx3BKoNUnJGLswvZQclaWNBQeSUkXRlCCDqkuoHRDmA8 GDBfBiWmL0CR0CQOq+TgT4MCW1o6NcU6pDpTxQp1CACFpx4HW0oOo9V0TwBIJ5JSAKHtVRm7 d8zM73ngUB8/5fE1q+YQtr5ME6BKvyJ5wDoTwKgSX5Y1OufccOFiQsjAk+eI44ynxlD9oECG pR3JE4BHVgWUxIBKELVteKQDNI78hxMA4n3PgjepI2jARYGkV8VwepQvyXglhqOzKr5WFGEY SACFdP0gECGh1DFMuaRlZTBtOyAaB5OB90nmC9AuakeCfK0HE5wawXVDjkHTxKOAYYyhwDqF KeIDvAzpNRCfWkCwhqydH5KXg2/XElEuQxMGUZDIwYDQPpE52qFIYELgE+9AEqw/Q8X+PL0H ujlDY5lGOe6AaY/DSnLkTjHIUJX4TvXmAT34DoWLCMA2hD+/JAm/c6OIatrIeXIXaxBRgCEY AIAIRIE8vg79FqUBCU1ImCEyBfpAIbAJEu00EpCYE6DIXSPm1sWRDgZRwMeLMdz7tpjqSWDo moSB4UNEgWBIRIV8jmpYMAmIeTmFp69Fh6AXLSBuj1pGx+AzOCYjWIEo0LCNU/NI2r0D520f 3JRMJS/lQ/OL+SO/j/jof0Ckiff0imC9AopfK9+hEsSFIEgAhWE6Fv4AvwU1D/WCajYsAHwZ lKvYAT3JArh/NAFkUWspE9QL6F3iJYfg6p1DjeujzVf5TySBsjBf5PvcyJS9TJoosS7atadz /PTw9RgWBYWEYHbOwjtgnwH1Ug2JjKGPzInXaQpX5clGLxe+Y1K0XRDclKR4ljx/fQ4nc8SB 2XK1NQKDa4h8uJ9CcVhIRgQgEhPhyVZKW1+teyYFIyvAT5btMOJKDPwFE8DyfHW6dXgjX3vh +S0mBd58mWjodkA0fkOzESHRZsPDg3wTTnEPhoaB8CQJQvvU9+lCO5JQjDIBBaMypxTgHyU8 bTA6nRMwDDqBIVS759AG/Dih1ITvO/JJpqzyYWj1r8yQmIwbKJ4RgFgPIwL70oncQaawA8xa /1iFKfuSp37Ev8BkNCn6BS+Jny0qdFwQiWVPhmVpPzCBr4OeaA+Q1KE9RMh41TXydXAceBLL r8j6xOIMJ6V+gbEp9L3FDETUkRrTfT5eIFu7LQHEnuJkIYDFNjp9mmnz0ALYVQYchGWCwyiy siysIxYDLKLGEYyIZlMyrGVYyrMVmJZiZMUsYljKmWUxhYMqwyTFlMJlWJkyrBlCFSAYQMA8 DSMSDwC0OKR8y/csZlbrlqzebFzVm0mxl4ZWd7JQyc6p5CQ7QzE2OJwOdAxbjgNjOjQ8Ti0c YE4aYpL5coAstO2lI2oISp3y9mQpLox72aiqzBgKWgw9jXtuNd9NOcEJ98czwowdFpJiSBxO hgtbLEsUsSwPnAMRxXFxHFMEwQwQwXBcEwAwExXAcFcQMAMUHL+g3r8dJD4X3sncz3cKDRIG wsTyBljwCp6PpEhoJJJV4BSKSLxLaFQLOQuwSvRGreBo4MQSJ4JGUwOui4PQQpll80L1TALA 4qSI9HElzydLv3vVU+0kG3Q4mS4LvX02jvvzYDb/3w2rqrJd0yjqcCUeEdT8yFCQD83qLxsH UOLoG8FxYB6BKlYgb+bEwaDguoWpgPUOCPRIdVhDCAXW2VDvOIy+kSYWFiW0sIiWANBMFpaJ wEj/DXyNcAsDAOPjqEb4fL9l8bFppDFLTQvPAG/CQLqaJTqkRLvfaH3+z9x/JKcfLdtsBxXK 5/mx/IQf38Bvw9+SEPkuEeIQBiVL8p4bpbsC3l1cUc/jpYOUJr4MhkORytb6cBi9RBAYEsFy FjIGVgHC3kOmQUi+QWh001gR4L6JcThwN6hUrIH3yXPkwK6AWnuDxp9BXgvgkpYhgSoWy7oI 39bC+Pkj0P0jlKb1S/vY81YZTrSGyh5k6hb4AtC344hL0TN98etl8P3yzAuMiai5329rjbIk sq2ox91YZQ+Qgnz9VCQp9wfKbYUmep+UrrbuBjbaErSTCyV9T4HyNjwp804v3+doK7SntXfy EBEj791MDP6EygJU7WNABLchx5Q2nVLbi54rvZ6urrkc8Lvtw2avzavxfj/P5O91d6YGp5vd tlN6e6udX3avl0nZdOOSjlP8vJ1D/LAIbfgPvrRKumwLDPq434eJp82toQLQEZJIGOBi0UwJ SvIsbxeUHXeWgdsOqfBYU6uI+VzyqhyZmnoeE449xMfSOp8582YsoWmgvBxKDJbD5WwZNRhs hHsJ8jxteHy8EkC7HtB197jaB8SDD1CcAegXwoLHiGjxeA4J8+ROJH3FDyPunumJxSnMWVqh KCFMBvwMcE110IEgP7yvk/b79eY3hEhL8h5hOYAn75DpOn5YOBIEtpS9DgnKUo+8l+TaXyyl ieZRNgWwgBiYmLIqxjDMmJkYyxjGZUxYmVgyshllJWMossLMjLEYxO1XaXZNVdFkYng3aevU kGbRIX5hDq8E8kHDjyPOjEVCnl3jhRYsL3eLARYk8TvWPLxRABojkKzgBkcGAUBifkp2uSyR cgxJ1AXYsuh0S3XcjzsO+PQMhla5a8aX19q3qxgooanHHAsrBSgdIOxghLmmVJVbLMTFTBMF wHFHAXEDFMXEMAwAMADFDBxDADFDAXAT3K0etvls1PGvnzprXX4VthAGp0WkWIzVgHIDhULg cFRYGBRbwHQ6pYFAwJCEJowM5diXctAYJ1dAwJSWUeCUnQdeJTTaWkgQA4pQNiaQRdOpw5nM zl+zM5zUBN8M9aC3EqBLQmxKIASWGyGwKZGUZljjQ05hIjgEIElYtiBiYJCwJjBiQQBBTBJY yawW9Ek0pHApkIVkSHjAUwyve1aWBOsKUkSQXBwEi4h2MfAyjbsMqR5YQMILbQvwUBQSj1KH JOvAPZTwbjqaDvEfIF2CPXhaPH6yw+F4B5xZV6lPzHcB6HpX5cZB7KyH+6MfuD78O/k6yH5/ OIS2rAEIYE2JXOz0qwaH3R4EL1VDOok62D4psRxkKCUO87+UsDHVI+AhDEPhJ4h5lJToMqzc gwdIfPwnOpiG0AfOPlp5IQkL1CHqVtVnZFptxgSn4GeQosfdWE+WjpNQ0kdTxxMSDGiMj47K Yn33WWkjBCF+XX4CAtSikIsMOqGkJQtPLujp2sOCdBKUPl54OoWj6S0FcPSh8pyV8UC0yY8H uKmIaj0WkaVgD54sJ5SXpYhDo3YeV8cU6hC0OpjxGHwNpKmkiTvx2XazqfafbKeQhSEOUAAe D3A+YQwDRYQMGrOM4nEsp4EAymokqyQAcepKRYiTbgCctws8GWpxGpcEqCwO5no+/0PyMh5Z NyoWV64HH/W+RQ+xxD+lp7J/MFqH0kjARCpKGvhT8tua6HWhbFyEG1ImvwUjLQRIRCB1wGST HEmBOObg/Bq2DqaBPqxVDD7x8dNFr4SIc8JVIYD4U+DrYNqy0lZBnVmxgbfJRNoUSmv0CWvE hTACMXvzRnSvml3RZVJegc55BKwWfl2ACIjyYyYIX08zfgeNBTRGzK09WfldotNbWAPsX64C II6JInRJJ6AnwHBymDwlcmnPg5PziOISPhbiJsCkC3Bp49AkLEhWDiMi0jC/AUrxpKENC1z7 YsgjonxcugT6XgcUGHweX5ZBtHwEBHHo8c8hHk4rlCGUhg+abBtgTr5M+VlsAo6nx8PXA1A+ VkKAODCp7qsgfIwj9SwhFq4AUgfMniIx1xJA4GoQGrQYWnwEwQmATYY8CwpKY4/ZtjTY22GJ olAdFkDoEC2sRqHAxxoixDQKIo8jotWkalwEVlWIcOSLFmnCeUt2L2lhScgdDZemw0Yzv1hA duitUSjUwNPIPDwLAsxxu8zKClSkSjEwxAwTADEUxHFQxEMTFcRcUxQwTBTFMBxTBMVDABzm bL3pBCHA008W9VO28qTOZ0J641gmtraYwJidSjpw4Ra6S08PDeA4BDpwPLthOUnkPcaunXoE PkMPODxCxlDwcDUTjSUuvXXr5WRDqPUU6ooLDETr5EVgJOYQDiLBYHBixPJxMApaEkYgKltC LRiBINUjAgyHVwZFhaG6HjplL18lBZsh5YXiw9IRMeIShvh6mFJKDxCnHwGYlBmMDaFCZ2UZ AMJbXrrzgnB1CQlDlX77rfUlJfvPzzRAjownwfJnww+XCiwoXm4uSEoT8Y1j8xKWOWtMfN2P 0yqZQyQjSfLCdBj15fg6nxqHyPzaHy5YnnOCH+lAoatJ+4fDiH4tT8HqM+7xvmgXSsJSEomC U+Sy0WgjBJGPLRYP60SnAtHC06cRw60npqwPJ0MT54i/JxXC3ILDoHkH4NvgRxGOnwaBVxnL aSudcoHEk6MiedG/X9LBUISNkktfHA40sJwSRJAPCWqSeKPgYIWh79KVC6DqQBQB9qEp7OUM Rmhvl0ND4DgUMSBSnmhIAJoT4eJR5atOdJDw/Kec6tHlcFInlCOgc+fPxU9flp46FCfD1qeZ CU4h09wCrOtyVQnFIQ9S2Ei8PDbhYnev3H76NGw2WNbaeGgsiePNHxURBT8EsjS7S0Nl/eTw elL4gV1JTwT4KXOBkAfW5AMuvwGJq1cp8n0SlB6Bk+dFkAxN/pKVwSG/h/VXfJmcXyyDxeNp juqRHBMtXgnLSa3EICixt0CBhGHr+YT9qeTnO666FUAZqJx6zh8J8DYfIeDmNJ1bBxEzqGA0 Y+AMkdt+PdDXPm2cot6UHyJd2l0uaP3IkljDDTcHMA0DBgTXifJnfGwcfmypAgHsdlDxguDa WkdDwQhbCba0WkGA9CVfL4sp0Ocmjyp1ApMdHiGFkQHKmpnu5Ntp4jqrDmbTJNVlxPEeMn2n yHDLAgbYHAJZG2OGjK0sBtTHRw8zJwMHhZWCZg/sPn9J+v/UtOAGDp59cID8MQHgQXwGtWgS fbVYVvC6UqnGfQ/B9+g+0fapfhS2Tji0nCuIuKShpuRJBsVsRsssbUsWwtG1bAbELLAsRtQs AvMAwDEHBSmlKEpA/0C0sFsALVNstULULBvcMRcVMBIczBcQC1DFYMpzCQCwAwQwssBsW1NF EGGwtUtApSxQQCcxwQpxQwUIayuNGy+0cjkW6LccpSHFy/B10OpdK6VdVKGXV05c0uQwA1UK aNN1LRtTVNAILLUsWkJDn+hhSg4uAa0tpCDYJaN6WvTpwCgQ4KcVeACzBQ6YyAFjiOAJJwMM dKopQbFNV0B64GGPA43YIWjxXiKhaWUOhQlLgtg4AJwxTAcQxDBt17JqKai6DoI8MIgwHEMQ xBuTidodU1AMR1dHEDEDHFcsZMCRMQDEGxbtbtCQJUlsXG1vE7y0C1eKHADgltlnHlo2ramq SYlikq2IWrNnMVaFxcGcNxEoAxXFM4cWRNENE0A1GbB5ghQmA4i6khSaO6iUra6A33AHFHAc ROBBaBYNiBSC9wCyjASRcAClGw5gJgOCmCOFFiQjYhYJ1QcDDYU0TVNUNBIacxUkTEsUwAfa agbqhqhqjwxwgGAcFMRwFuwIQhWwbUbUC2w2QCUTFHAcBKGyFLQLULRDQzAShhXBDFCkAuxJ DTbtNHUXQGlbIAsSwCwDLUMYVMQMADAXEsGQN0KQNRDRFaSD7MS3tqC2F6UHKHHxAcQb/YC3 NAYXWBtBakWv/EG3EG60qB1zj9YHUv3F6/96gduqVsD9lzbOc3pi+09fUfufucn5a3O5X8B3 OLEPh5oLHxhqh4Q/D8wtAvBUg9geUK6fEFM8sXR+Mnv2NYDk5yNOzbWRajwvbllyDTDw6Vwb geILAVd8DOBPAJF1NF4eQPmGERvAUTSnORuBbDPA2hiDQYgqruP8f/ce3QoA01qBbwrD8Akl bVqn5px8z++djR2Ph2G5s7h33zFhyOITQGxBzSGHYGITCgVir/hrDQEQ4AFpYXMl8IHIzpsO /twrdwaJhyFoRBWNIYTq5MI8x6dIVI9Ye0NtocwrtGJstSQ1Bh0hiFsA8qwvAJgoByDYCrD0 8NfhIwoNQSRQyDvCIlL46COuqCtrmKP5qwhb/sBzBLMEgOYaTiitC3fqgYfp+gPHV9aPpFgZ B3AihMofce4AwAuDyMovEpyFPYiqFfm06Vzy0CX0UaDAAPrcpVZVhPWMtR5qqId0Snttwf67 F7clL/pEJvBkGwsrtzTaoLGokfsgoGEB0iQ+KsMZ1JWtGFvjRe7mr4/Brzpyl/cASM2OFEEv Jlwpf4TX2I0QaYru6pTQv+FOcgGxUI4Bg/2+JKZq84Vx4reUXEbmdT3IKlRnzhGGtprg27yM EI4KBQ3GWqoSoDYHr6r0DXOn6GFAbUg9BGQMQ8EusgozQHkfriRbS9VDoSivC8RZsqrVUJ9U eizuPuVlUrFbYNiIoYjtJA2O4vGRVo5FkEEsIBOvaBnKt+NOE+OrVt61r1sbbLNZrM0GvtlL jG92f5vxbbX+92y7tufPLelv9Pf5m33btVZYZnq+L1T8JFpPtQQjQoc9esqct8gjGLR3RsUe acaGxc7YZCUfZ3b+6cc/2zFkUnJJEP9jJr/fb6Fg4PPeskcPX6LXnLro6l/X/wO5syue3uc9 J7GPG+qNEGF4BSRnXhh3ZiGkmiKwpWXedBpsHRIXBnnH1peg6FfusThlHI0VZtM0zsv0fl6A qCUdaW8ua6HFDaNqZsCcNXKiq6RSh4BjO+Rwq8UTRt1AzfeVvZaSYJoYhiZhq0TZf9p8jNpa EYiL6REa9fijbme/U0jv71KAqiEuPUSAmldHGPFICl/zY9Cn/XKBKpNKPwWtoH7pO84gxitn GHnh+M/NsOQ41v4682HhuWkkEJ0DDdtyPTskpQFAgPrAMeQcQOyaRUhrgMh10PORnehYJUFf wACS1yXEGDXem2JjjVPuIR4ROypxcgv3yJL5TsSQdFSVQcj7xpYmdhW0t+pI+lrXTN2rsgVu 9Y9lgq9Qz2PEeNoxsgNanFCq7UVR8eEgJrunlLb4WoU2vGrjxQZ9umOqR5oMY1DRcGDEmDAT YuzBZcl5I1AFLEjY1BMHUZ8TpC1MtstlQr2OK9PNQFjVmzJjOfefTHjjbr3TMamL8xc7to2b u9+dG22MaIEYQAZcVOVUkuQqKFHms0tzU0SpDSw595L21qANk480gIm4K0oJalykHeXnYmuL 0NZ92YdLMjQhjTkhpeMQ6XkB5MIjWRgGGm2grOFJBHKhdeXDCHRdvilMA4Mqi42B7muK2myy FVLhp7yzDjbo8X4POWq2+63N3cwc83QEiO0p0Ksz8AZ/t2CkJB/1aZCPv0jXGrx/ajbe3mjV /dfj53b3F+k1orF331xtu+mM32r6djtfiry473d63c8U2m71m5gz6pl9W3X1BvtYu8mVR3Dv o6j4G7c4/JpkznfNdsxNR08D3NJzn8zi/DnZ9+tPkL0oDo0wJC0MEKA8VdiDKCWPZCJCzB0o BiaRJiRV4BuSYwDOlMCsqIcO5EF1nudgggymXMlERBjSxg0ZzTaQHQ+esiC+iqYioGibbxLa I5HaVV4iR0ebUs0gA05JEBMbAwTd4jyDPkrUHfA2ab5qvrqeixGWrCjxMyGDTQ4Rt4cFwO4v 7eRpv2+9U6Q8vw0oOFaUIHS3pRpZAYwYaz0ENMyATGy1JkSsZjRtEdJsMG51SdAUYNMqZAAa D0MCbREabRgDg6B38o7kBOC3ZQsUBMIKSZGKAZKMBelowwLYKA59S+kMNm6aLCUIKXS7yubf Rl9bACJWAOgHJ2h2iCHYvVoz4qy1oLgG0A7Wjw2bNYxmsL9L8/fL7O3nhxOOOc/WjtpcTCpg VPTSa5ES2KDBVkZDCsfbUWYstJNVXdqyIOBCkjpNy+5hIlA3h2HYDTV2SEFHdwRojoDK+nwo FpS93DBs0fA0VBEtDK4xwqCO9FCmDYG5hGsd65QKr7kEFCkZSJVTpEJDUCIOwzPx5JaEWvel xa0dBC8YovwBi89t9ftp4AUa34oLLLnBefKgssBL31TwkqpEcgnNaXWlHsleWTszMycB+HKf tV/hsf7au3T6HX6PwayKg0VKohrER74ahysPDOIkjTKs+e9IDcofFK5WEkuPA6DxXszQ9YY6 99q+flx75i8GcKKyB7V0SmcaUu6jGRD0rKKoyAERz3r3d3XIGCyW3pmWJhXSSktOaIIi2AbI WD5gEAVL7Lze5sG2POw0RgXwyQRCCTImo+49hkor2myCLUsgPSmaWzwfD5fV+PJTP/xdyRTh QkMpbogA --------------99E5611E3A874D1C7F3CDD28-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 5 00:32:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160YZi-0001nk-00 for ; Mon, 05 Nov 2001 02:29:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 02:29:18 +0100 (CET) Received: (qmail 22757 invoked by uid 0); 4 Nov 2001 23:31:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx027-rz3) with SMTP; 4 Nov 2001 23:31:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA4NVnC29518 for ; Sun, 4 Nov 2001 18:31:49 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 4 Nov 2001 23:31:18 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA4NVIe29265 for f-cpu-list; Sun, 4 Nov 2001 18:31:18 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA4NVHj29262 for ; Sun, 4 Nov 2001 18:31:17 -0500 Received: by moria.seul.org (Postfix) id 89ED314630A; Sun, 4 Nov 2001 18:31:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 5CC1E146309 for ; Sun, 4 Nov 2001 18:31:16 -0500 (EST) Received: from f-cpu.org (nas20-22.kdl.n.club-internet.fr [213.44.18.22]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 005081684 for ; Mon, 5 Nov 2001 00:31:11 +0100 (CET) Message-ID: <3BE5D020.C9B1398C@f-cpu.org> Date: Mon, 05 Nov 2001 00:32:48 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Omega Network References: <20011104154613.08306@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > Hi y'all! > > To clarify the `reversed omega network' issue: it's just an omega network > with inputs and outputs swapped (see picture 1). > > You may ask, "what's the difference?" It's not visible in the picture, > but there is a one important difference -- if the "forward" omega net is > used for bit shifting, the control logic for the last stage is minimal > while that for the first stage is huge. So I reversed the net, and now > I have minimal logic in the first stage, and the more hairy decoders at > the end :) > > Both versions can do the basic operations we need: rotate left/right > and/or bit reversal (see picture 2). In contrast to other > implementations, the omega net also supports the SIMD versions of > these operations, with almost no overhead. i have only one thing to say : oh yeah :-) > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 5 01:06:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160YZj-0001nk-00 for ; Mon, 05 Nov 2001 02:29:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 02:29:19 +0100 (CET) Received: (qmail 12164 invoked by uid 0); 5 Nov 2001 00:06:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Nov 2001 00:06:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA506xG31651 for ; Sun, 4 Nov 2001 19:06:59 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 5 Nov 2001 00:06:39 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA506cJ31388 for f-cpu-list; Sun, 4 Nov 2001 19:06:38 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA506bj31385 for ; Sun, 4 Nov 2001 19:06:37 -0500 Received: by moria.seul.org (Postfix) id 12CD114630A; Sun, 4 Nov 2001 19:06:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id 187EF146309 for ; Sun, 4 Nov 2001 19:06:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02389; Mon, 5 Nov 2001 01:06:40 +0100 Message-ID: <20011105010639.33278@thrai.stud.uni-hannover.de> Date: Mon, 5 Nov 2001 01:06:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE6236C.36AECE11@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE6236C.36AECE11@ifrance.com>; from nicO on Mon, Nov 05, 2001 at 12:28:12AM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Nov 05, 2001 at 12:28:12AM -0500, nicO wrote: > I have just learn something todays ;p (But how do you create the diff > file ?) With `cvs diff -u' :) > First :) Something goes wrong ! > ------ > Warning: Variable 'Bitrev' is being read > in routine Shuffle64 line 298 in file > '/home/profelec/nboulay/perso/fcpu/shl/fcpu-shl-mr-20011102/eu_shl/shuffle64.vhdl', > but is not in the process sensitivity list of the block which > begins > there. (HDL-179) > --------- Harmless (except for simulation). > Euuuuh ????: > > check_design > Warning: In design 'Shuffle64', port 'Clk' is not connected to any nets. > (LINT-28) > Warning: In design 'Shuffle64', port 'Rst' is not connected to any nets. > (LINT-28) > Warning: In design 'Shuffle64', port 'En' is not connected to any nets. > (LINT-28) > 1 > ---- Also harmless -- this is still an unclocked unit (occupying a single pipeline stage). > I wait tomorow for the end of synthesys. Fine :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 5 01:29:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 160YZk-0001nk-00 for ; Mon, 05 Nov 2001 02:29:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 05 Nov 2001 02:29:20 +0100 (CET) Received: (qmail 13598 invoked by uid 0); 5 Nov 2001 00:30:11 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 5 Nov 2001 00:30:11 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA50UBP32309 for ; Sun, 4 Nov 2001 19:30:11 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 5 Nov 2001 00:29:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA50Tiu32027 for f-cpu-list; Sun, 4 Nov 2001 19:29:44 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA50Thj32024 for ; Sun, 4 Nov 2001 19:29:43 -0500 Received: by moria.seul.org (Postfix) id CCB2F14630A; Sun, 4 Nov 2001 19:29:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id 2E03A146309 for ; Sun, 4 Nov 2001 19:29:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02480; Mon, 5 Nov 2001 01:29:39 +0100 Message-ID: <20011105012939.51086@thrai.stud.uni-hannover.de> Date: Mon, 5 Nov 2001 01:29:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE62658.ED8E0D29@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BE62658.ED8E0D29@ifrance.com>; from nicO on Mon, Nov 05, 2001 at 12:40:40AM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Nov 05, 2001 at 12:40:40AM -0500, nicO wrote: > A complete log, sorry nothing really interresting, there is something > strange with Clk as said in my previous mail. 7.22ns delay is pretty bad (138 MHz)... Can you please try another run with set_max_delay (and no clock), and a little more delay optimization perhaps? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Nov 6 21:34:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 161GHQ-0000cw-01 for ; Wed, 07 Nov 2001 01:09:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 07 Nov 2001 01:09:20 +0100 (CET) Received: (qmail 32709 invoked by uid 0); 6 Nov 2001 20:26:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 6 Nov 2001 20:26:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA6KQYW07029 for ; Tue, 6 Nov 2001 15:26:34 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Tue, 6 Nov 2001 20:25:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA6KPqi06759 for f-cpu-list; Tue, 6 Nov 2001 15:25:52 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA6KPpj06753 for ; Tue, 6 Nov 2001 15:25:51 -0500 Received: by moria.seul.org (Postfix) id 1070414630A; Tue, 6 Nov 2001 15:25:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf00bis.bellsouth.net (mail100.mail.bellsouth.net [205.152.58.40]) by moria.seul.org (Postfix) with ESMTP id D718F146309 for ; Tue, 6 Nov 2001 15:25:50 -0500 (EST) Received: from computer ([209.214.154.211]) by imf00bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011106202656.REYJ29297.imf00bis.bellsouth.net@computer>; Tue, 6 Nov 2001 15:26:56 -0500 Message-ID: <000a01c16702$6785c4e0$d39ad6d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Shifter Date: Tue, 6 Nov 2001 14:34:15 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C166D0.1C112180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C166D0.1C112180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI -- As the result of implementing a TSB (Test Bit & Branch) = instruction; the software I intend to capture will NOT require single = SHIFT instruction. Regards Dick Hartney ------=_NextPart_000_0007_01C166D0.1C112180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FYI  --  As the result of = implementing a=20 TSB (Test Bit & Branch) = instruction; the=20 software I intend to capture will NOT require  single SHIFT=20 instruction.
 
Regards
Dick Hartney
------=_NextPart_000_0007_01C166D0.1C112180-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Nov 7 01:24:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 161Y0C-0000Fn-00 for ; Wed, 07 Nov 2001 20:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 07 Nov 2001 20:04:44 +0100 (CET) Received: (qmail 9474 invoked by uid 0); 7 Nov 2001 00:25:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 7 Nov 2001 00:25:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA70PJT12253 for ; Tue, 6 Nov 2001 19:25:19 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 7 Nov 2001 00:24:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA70OhN11976 for f-cpu-list; Tue, 6 Nov 2001 19:24:43 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA70Ogj11973 for ; Tue, 6 Nov 2001 19:24:42 -0500 Received: by moria.seul.org (Postfix) id 8320714630A; Tue, 6 Nov 2001 19:24:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id DBFAF146309 for ; Tue, 6 Nov 2001 19:24:40 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02449; Wed, 7 Nov 2001 01:24:38 +0100 Message-ID: <20011107012438.25080@thrai.stud.uni-hannover.de> Date: Wed, 7 Nov 2001 01:24:38 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter References: <000a01c16702$6785c4e0$d39ad6d1@computer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000a01c16702$6785c4e0$d39ad6d1@computer>; from richard hartny on Tue, Nov 06, 2001 at 02:34:15PM -0600 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Nov 06, 2001 at 02:34:15PM -0600, richard hartny wrote: > FYI -- As the result of implementing a TSB (Test Bit & Branch) instruction; the software I intend to capture will NOT require single SHIFT instruction. So what? Helpful as usual... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Nov 7 02:24:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 161Y0C-0000Fn-01 for ; Wed, 07 Nov 2001 20:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 07 Nov 2001 20:04:44 +0100 (CET) Received: (qmail 21581 invoked by uid 0); 7 Nov 2001 01:23:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Nov 2001 01:23:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA71N1813304 for ; Tue, 6 Nov 2001 20:23:01 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 7 Nov 2001 01:22:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA71Mex13039 for f-cpu-list; Tue, 6 Nov 2001 20:22:40 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA71Mdj13036 for ; Tue, 6 Nov 2001 20:22:39 -0500 Received: by moria.seul.org (Postfix) id 70E4C14630A; Tue, 6 Nov 2001 20:22:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 581D2146309 for ; Tue, 6 Nov 2001 20:22:39 -0500 (EST) Received: from f-cpu.org (nas20-13.kdl.n.club-internet.fr [213.44.18.13]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 89F7C169C for ; Wed, 7 Nov 2001 02:22:36 +0100 (CET) Message-ID: <3BE88D43.8516D8E1@f-cpu.org> Date: Wed, 07 Nov 2001 02:24:19 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter References: <000a01c16702$6785c4e0$d39ad6d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, > richard hartny wrote: > FYI -- As the result of implementing a TSB (Test Bit & Branch) > instruction; the software I intend to capture will NOT require > single SHIFT instruction. it's cool if you can remove one unit. However, multiple shift is often more than necessary ... i don't know about your software but bit field insertion/extraction is often used when dealing with compressed contents, for example. > Regards > Dick Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Nov 7 05:48:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 161Y0E-0000Fn-00 for ; Wed, 07 Nov 2001 20:04:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 07 Nov 2001 20:04:46 +0100 (CET) Received: (qmail 11807 invoked by uid 0); 7 Nov 2001 04:40:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 7 Nov 2001 04:40:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA74e2617317 for ; Tue, 6 Nov 2001 23:40:02 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 7 Nov 2001 04:39:40 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA74deM17054 for f-cpu-list; Tue, 6 Nov 2001 23:39:40 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA74ddj17049 for ; Tue, 6 Nov 2001 23:39:39 -0500 Received: by moria.seul.org (Postfix) id 1950214630A; Tue, 6 Nov 2001 23:39:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf01bis.bellsouth.net (mail301.mail.bellsouth.net [205.152.58.161]) by moria.seul.org (Postfix) with ESMTP id E06F3146309 for ; Tue, 6 Nov 2001 23:39:38 -0500 (EST) Received: from computer ([209.214.154.198]) by imf01bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011107044045.KAZN20670.imf01bis.bellsouth.net@computer>; Tue, 6 Nov 2001 23:40:45 -0500 Message-ID: <000c01c16747$63dab0e0$c69ad6d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Shift Date: Tue, 6 Nov 2001 22:48:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C16715.185544A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C16715.185544A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also added a CLB (Clear Bit, & a STB (Set Bit) Instruction. Regards Dick Hartney ------=_NextPart_000_0009_01C16715.185544A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I also added a CLB (Clear Bit, & a = STB (Set=20 Bit) Instruction.
 
Regards
Dick Hartney
------=_NextPart_000_0009_01C16715.185544A0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Fri Nov 9 14:07:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 162JiF-0000QX-00 for ; Fri, 09 Nov 2001 23:01:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 09 Nov 2001 23:01:23 +0100 (CET) Received: (qmail 5433 invoked by uid 0); 9 Nov 2001 13:07:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx001-rz3) with SMTP; 9 Nov 2001 13:07:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fA9D7rB22343 for ; Fri, 9 Nov 2001 08:07:53 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 9 Nov 2001 13:07:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fA9D78j22077 for f-cpu-list; Fri, 9 Nov 2001 08:07:08 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fA9D77j22074 for ; Fri, 9 Nov 2001 08:07:07 -0500 Received: by moria.seul.org (Postfix) id 95B5B14630A; Fri, 9 Nov 2001 08:07:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 7F624146309; Fri, 9 Nov 2001 08:07:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 7EA18FEC0D for ; Fri, 9 Nov 2001 08:07:07 -0500 (EST) Date: Fri, 9 Nov 2001 08:07:07 -0500 (EST) From: Graham Seaman X-X-Sender: To: F-CPU dev account Subject: [f-cpu] Re: Hello Graham In-Reply-To: <20011108170239.A4333@seul.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 8 Nov 2001, F-CPU dev account wrote: > Hello Graham, > I hope you are fine. > I am now studying CS at the EPITA engineering school > in Paris. > Regards, > Lionel (trollhunter@linuxfr.org) > > Hi Lionel, So, you changed uni? Hope this goes better for you than the last one! I wish I was back in a uni at the moment... access to a proper library, for a start :-( All the best, Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 11 04:39:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 162mCi-00033g-00 for ; Sun, 11 Nov 2001 05:26:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 11 Nov 2001 05:26:44 +0100 (CET) Received: (qmail 8423 invoked by uid 0); 11 Nov 2001 03:38:49 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 11 Nov 2001 03:38:49 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAB3cmZ31632 for ; Sat, 10 Nov 2001 22:38:48 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 11 Nov 2001 03:37:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAB3bxQ31362 for f-cpu-list; Sat, 10 Nov 2001 22:37:59 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAB3bwj31359 for ; Sat, 10 Nov 2001 22:37:58 -0500 Received: by moria.seul.org (Postfix) id 4F49D14630A; Sat, 10 Nov 2001 22:37:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id F19E5146309 for ; Sat, 10 Nov 2001 22:37:57 -0500 (EST) Received: from f-cpu.org (nas5-8.kdl.n.club-internet.fr [213.44.0.8]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D29B116BB for ; Sun, 11 Nov 2001 04:37:54 +0100 (CET) Message-ID: <3BEDF302.B5C6A184@f-cpu.org> Date: Sun, 11 Nov 2001 04:39:46 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] FC0 P&R : i finally got it ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, while thinking about the f*ck*d up pseudo-MIPS (microcoded !) project that my group is currently doing this week (as part of the diplom), i remembered of the "over-cell routing" stuffs and how the register set was routed by Alliance. How many metal layers do remain over a 3R2W register set ? This might be the solution to the P&R problem that i experienced while using Alliance for the ROP2 unit. First we have to optimise the register set for room saving and low latency. The current design of the register set (split into 5 subparts of 8,8,16,16 and 16 bits) is rather cool, we can optimize the subparts and copy/paste them. So we have the following preliminary layout : r r e e g g 1 63 +---------------------------+ | | bits 48 to 63 | | | | +---------------------------+ | | bits 32 to 47 | | | | +---------------------------+ | | bits 16 to 31 | | | | +---------------------------+ bits 8 to 15 | | +---------------------------+ bits 0 to 7 | | +---------------------------+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ||||||||||||||||||||||||||| R/W addresses (5*63 wires) Located at each separation, we can locate write and local decoders, as well as buffers that will amplify the address lines for the "jump" to the next cluster. The cool thing is that the buffer can be disabled if the write does not propagate to the last clusters (MSB). Nico will be happy because at first glance, it consumes less power if the writes occur on bytes or words. Next step : split the register set into two halves in the vertical axis so we can put the "bypass registers" of the "crossbar" at equal distance from all registers and all units : r r r r e e e e g g g g 1 3 3 6 1 2 3 +--------------+ +-------------+ | | B | | | | U | | | | F | | +--------------+ F +-------------+ | | E | | | | R | | | | S | | +--------------+ +-------------+ | | A | | | | N | | | | D | | +--------------+ +-------------+ | | F | | +--------------+ F +-------------+ | | s | | +--------------+ +-------------+ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ |||||||||||||| ||||||||||||| R/W addresses (5*63 wires) This way, we can put all the normal EUs on the left and the right of the register set. the "Xbar" will be routed over the register set and most units. From the sideview, it looks like this : +------+-----+------+--------+-------------+-----+-----+ | | | | | | | | +-POPC-+-SHL-+-ROP2-+ R1:31-B-R32:63 ASU-+-IDU-+-INC-+ It has drawbacks and good sides : it removes the need to design EUs which have the input and the output on the same side (as in the "original Xbar" design) and we can "chain" operators when a certain sequence is often used (such as shift then mask, so SHL and ROP2 are next to each others). The bad news is that if you want to make a shift then add, in the shown case study, the wire will take too much time to travel across the units and the R7's length. The bypass buffers of the register set will have to play the role of amplifiers and it may cost one cycle to travel through the remaining distance. So from one side we win one cycle, from the other it costs one more cycle. The designer's art will be to identify often-used operator sequences so the corresponding units will be located in the same sequence. Otherwise, instead of being "for free", it might cost two cycles... The next step is cool : given enough metal layers are present, we can draw vertical wires to feed the multiply unit, located "above" (from the upper side point of view) the other units and register set. Because this unit is long and has several outputs, vertical wires will be drawn wherever needed and meet the horizontal main buses. i have no patience or skill to draw that with ASCII stuffs but it seems to work on paper sketches. all the above study is based on the fact that F-CPU uses very wided data, so the aspect ratio of the units will look like a very fine column. For example, the ROP2 unit can be 10 times higher than large and this will increase when 128-bit (and more) registers are used. So (for manual P&R), the usual column datapath aproach is necessary (modulo the unavoidable clock and power problems). The behaviour of a software-P&R will be completely different and i'm not speaking about FPGA. The rest of the circuit layout doesn't change from the old layout pictures. i simply modified the "central hub" idea. I hope we'll get access to a decent synthesiser that allows floorplanning etc... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenkovaa@cc.hut.fi Sun Nov 11 09:53:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 163PtL-0000Fy-00 for ; Mon, 12 Nov 2001 23:49:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 12 Nov 2001 23:49:23 +0100 (CET) Received: (qmail 13301 invoked by uid 0); 11 Nov 2001 08:53:54 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 11 Nov 2001 08:53:54 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAB8rsJ01807 for ; Sun, 11 Nov 2001 03:53:54 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 11 Nov 2001 08:53:23 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAB8rMq01541 for f-cpu-list; Sun, 11 Nov 2001 03:53:22 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAB8rLj01538 for ; Sun, 11 Nov 2001 03:53:21 -0500 Received: by moria.seul.org (Postfix) id 6797F14630A; Sun, 11 Nov 2001 03:53:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by moria.seul.org (Postfix) with ESMTP id A5190146309 for ; Sun, 11 Nov 2001 03:53:20 -0500 (EST) Received: from gamma.hut.fi (kenkovaa@gamma.hut.fi [130.233.228.23]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id KAA25096 for ; Sun, 11 Nov 2001 10:53:19 +0200 (EET) Date: Sun, 11 Nov 2001 10:53:18 +0200 (EET) From: Kim Enkovaara X-Sender: kenkovaa@gamma.hut.fi To: fm Subject: Re: [f-cpu] FC0 P&R : i finally got it ! In-Reply-To: <3BEDF302.B5C6A184@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 11 Nov 2001, Yann Guidon wrote: > The next step is cool : given enough metal layers are present, > we can draw vertical wires to feed the multiply unit, located > "above" (from the upper side point of view) the other units and > register set. Because this unit is long and has several outputs, > vertical wires will be drawn wherever needed and meet the > horizontal main buses. i have no patience or skill to draw > that with ASCII stuffs but it seems to work on paper sketches. Have you tought about crosstalk problems? At least big bunch of vertical lines can be a problem unless you add extra wires that are grounded etc. This will not be a big problem at 0.18, but is beginning to be a real problem at 0.13. There are tools to analyze the crosstalk and fix the problems at layout, but they are very expensive tools. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 11 18:33:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 163PtN-0000Fy-00 for ; Mon, 12 Nov 2001 23:49:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 12 Nov 2001 23:49:25 +0100 (CET) Received: (qmail 31101 invoked by uid 0); 11 Nov 2001 17:32:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 11 Nov 2001 17:32:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fABHWdC08348 for ; Sun, 11 Nov 2001 12:32:39 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 11 Nov 2001 17:32:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fABHW8h08076 for f-cpu-list; Sun, 11 Nov 2001 12:32:08 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fABHW7j08072 for ; Sun, 11 Nov 2001 12:32:07 -0500 Received: by moria.seul.org (Postfix) id F01FE14630A; Sun, 11 Nov 2001 12:32:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id CDF54146309 for ; Sun, 11 Nov 2001 12:32:06 -0500 (EST) Received: from f-cpu.org (nas22-46.kdl.n.club-internet.fr [213.44.20.46]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B6FAB1741 for ; Sun, 11 Nov 2001 18:32:03 +0100 (CET) Message-ID: <3BEEB684.B30AD51C@f-cpu.org> Date: Sun, 11 Nov 2001 18:33:56 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] FC0 P&R : i finally got it ! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Kim Enkovaara wrote: > > On Sun, 11 Nov 2001, Yann Guidon wrote: > > > The next step is cool : given enough metal layers are present, > > we can draw vertical wires to feed the multiply unit, located > > "above" (from the upper side point of view) the other units and > > register set. Because this unit is long and has several outputs, > > vertical wires will be drawn wherever needed and meet the > > horizontal main buses. i have no patience or skill to draw > > that with ASCII stuffs but it seems to work on paper sketches. > > Have you tought about crosstalk problems? At least big bunch of vertical > lines can be a problem unless you add extra wires that are grounded etc. > This will not be a big problem at 0.18, but is beginning to be a real > problem at 0.13. There are tools to analyze the crosstalk and fix the > problems at layout, but they are very expensive tools. Of course, Xtalk is a big problem. i don't know a lot about it and i think that it is not a concern where i study (they have enough problems programming their own dumb P&R...). However, we will certainly have to do whatever is necessary (in the case where manual placement is done) and i don't think that extra grounded wires are too much. Btw, the vertical Xbar wires are only used to communicate with the multiplier so the wire density (for this part) is not too high. ok, now i have to finish the optimisation of the datapath of the f*ck*d *p microcoded MIPS for the university project. the kind of stuff where the critical datapath makes big zig-zags across the whole circuit :-( a first timing analysis for .35u gave 17MHz for the core and 3MHz with the pads : they "only" forgot to buffer the clock signal... now i have to redesign their add/sub unit using precharacterized 4-bit add blocks instead of their dumb 32-bit long carry chain. > ============================================================================= > Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Nov 13 02:49:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 163Ptf-0000Fy-00 for ; Mon, 12 Nov 2001 23:49:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 12 Nov 2001 23:49:43 +0100 (CET) Received: (qmail 32227 invoked by uid 0); 12 Nov 2001 19:34:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx026-rz3) with SMTP; 12 Nov 2001 19:34:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fACJYLF06231 for ; Mon, 12 Nov 2001 14:34:21 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 12 Nov 2001 19:32:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fACJWlK05944 for f-cpu-list; Mon, 12 Nov 2001 14:32:47 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fACJWjj05941 for ; Mon, 12 Nov 2001 14:32:45 -0500 Received: by moria.seul.org (Postfix) id 23A0D14630A; Mon, 12 Nov 2001 14:32:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E77A0146309 for ; Mon, 12 Nov 2001 14:32:44 -0500 (EST) Received: from ifrance.com (nas25-44.vlt.n.club-internet.fr [195.36.224.44]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 75AEC16A6 for ; Mon, 12 Nov 2001 20:32:39 +0100 (CET) Message-ID: <3BF07C1D.EA5CC6D6@ifrance.com> Date: Mon, 12 Nov 2001 20:49:17 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE62658.ED8E0D29@ifrance.com> <20011105012939.51086@thrai.stud.uni-hannover.de> Content-Type: multipart/mixed; boundary="------------58D0DF89C4FAEC5DD0FB1CA5" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Il s'agit d'un message multivolet au format MIME. --------------58D0DF89C4FAEC5DD0FB1CA5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 3 rd time ! The previous log was too big : >50ko 2.6 ns :D nicO Michael Riepe a écrit : > > On Mon, Nov 05, 2001 at 12:40:40AM -0500, nicO wrote: > > A complete log, sorry nothing really interresting, there is something > > strange with Clk as said in my previous mail. > > 7.22ns delay is pretty bad (138 MHz)... > > Can you please try another run with set_max_delay (and no clock), and > a little more delay optimization perhaps? > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ --------------58D0DF89C4FAEC5DD0FB1CA5 Content-Type: application/octet-stream; name="shl.log3.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="shl.log3.bz2" QlpoOTFBWSZTWYywcN4AAYf/gH9y//3W9//7P+/f+r/v//5gGz9HYxA6NBQFRFFU9JaKb2Oa 1WxQokUl1lR0UADgPAwDoAAUAFAAAAAKEJJBNNIMpspgmgSej0FPRpNPFMymJkA0GRo9TQxq PUaaNCKZNMf6qpQAAAAAAABoAAAAA0AADQj9KTRNFIyaAAANNNAANAAAAaNBoAAGif6qQkpi NAGRoABgIxBoAyaaBoGQDTAg0HAANBoaDQAaZBoZA00AABkAGQGQACpIQQEAAQTE9TSYJpiY g0E1PJpB4UzEj01HpHpqepnu+MkJuUJ7wqEkUqQHkCoS5MDJmGDpGTg/E4jiP4PB2e33jeOE hu4+QIYqzsFFhw725SPgOY9h6Hct2odBbiKyRVaMTj+lJQRDE4kPGHDjwsHwUpEGOggFY3dj slbpZuda65ue1UkX1Y2210iLp1erK5i98JaWxEyWtLsJXtmTGt5eumyfrelxdkf5vSXf6Hey s8XU6N2ei1TvoWjWMM2Isp/V1v4uXt9DybpHKo2KxVSyyn/1Zh+RZ7PL3fobeySqqlVSqVVS pScilPMarLMf3ZrAMYFx45xMtBuaZfnHJkf9tEYF+wyHWgYQ2iofI6WD/qGYL3ccX9qh9ZPC A82LfbwPe98C9T1SIIOogZdzMUhr7nCTNLrR4cDFwgQF/tAcfDvkaJGAcXyOidqe63rTJ7nV tL9zwtHbfwq9KtZZRU9lLL9ed/mejZB9CkClRKihFShSilSCSch0+n15Ond/2j3tkcg42kqR JyUREs/69JaSJIfwipPaokgntaoRzKiTplnvx2OrghHqPROhVN5sDFKRGCVP1x+uOV+rya9j bPp21vXysZMjeXX0j6c5nlhhUylOIvEWwnesRmi8RPRSiVJY5XlmzStmlWSGE4wzZTi+22lW +BzuiT2Nzpf+I4LtF4+uLsnVmua05ZunNx4zl08T/3Ikt5KVIooqKlKFVMpFrT+EUyfEllPB 04+zzv/6p6D1ajdGHXFRkqOvfbR2DBM5ioQqtqWTObWbKOHPIGaKioUUJ7SkzLO11YaS6+nc qtjWMNY12M1YuVpX9kdA9w4vPUH74piKUoKioSdVHRf5rW+eUsf7fV6QF6emoWqR3d6j6qs5 KknBmzkBRtk/1h+Ussr3ILRLULJrnQ9/XD3tPnU0rHtNqy56+XIr8j+j+zrc7len9kbo++RR UMgNWTK919X0qF29r6N+yuJgzB4C+YgcPPboMLH7qkagjf9/QcPgzTXPxux8PV7/x/H8ePna Q1bqVwostyI4qFD3RzLqTNZZey/vLTNUT6YpbLzeft+m+Nymw1ilPt9XyYpw8WcnD72HrXie LJuaGcLzfvWm5keA2D0uSOyNHybUarultLGF13Th9Di0ZLruf/XfpGe1+C7kFNVRzrcPzfPG cZq61geLQ5lKZJ6z3myX4vZ7N3D4qbde4Rx22tayHPHHh8+sz2eGfqZxLGTpO8e0KZE6X2Qh kKrjgLxpvq0iqTUosT3eEHuQnl4a4OVrOd3Xm88+RviU2zlnPLnBjE6voZt5kd+e7rb2/pH0 RdCiOu8JRZp2bCrLAtcNmeWGsKLzOYtA+2nHSqFSFV8zkDC8yzkmQRhlga40sBQ9bErrKYqR GRjDHiZuXNgKjUKuu3lCJsF4FJC2yxZihyS5fcHNz8dgQcNbu7XuUgPbKqVFShBsOo4tXhN+ tcXK669Dr9HdbKsmzc8PX2PE5+XjqEFOXp6mGdc5bfUut0s8dRsmx1lK+Le890lEzZJG8Mtu vQ+gMM2eavut4izivGaeu0he8x3wCJsvOxY+qj3lVKeBXs+9edU3zkzctST6gH4tbafX6Pn+ XdppfWzwqRJOFHDmSCPBUiR+ZRHmKdD+fZ8k/ksYfK+0p9bE3OLZNVDC/d2xkpgOLtK8woLW OJhGy3Ug0OGpjZI8WE8Y/p4WuDdX06QT2h8HZ/e+g+Xm2rRP1PsZSE9SKSJVIiZHiGQkXhhP BdJvHHwbPmO2D9aKFSKSzjwyOT3n4XF95/isinaWWU/Oci0/Q2+ju7nuXyuEGWUFqZTCpSa/ ZdnrMp4/J7LfFPBa8xR5Pryulytda402i8bKlyXNZmomKm1zjaTTTitt6r0ovGUqbKia1IKV C0xszmcwMkpSMrqpkVisrpkVKxaZSYGCqGNlqUzq0XKxdNcVvXlNDE2qrkuVvXNtJtpUzUu5 ma6XeNJnNXUTbF1dL20NdZcuXJpJrnDTaSY1loUpJFUSsrUuTGkxeF9BsmmrIzzs+Rz95HJZ DUZnO3zsHcRjOyRvmIxVvhDUtfbKTh9D3jqz55ljo8XVnVKqx+M5+bvpXac7whd9w8IeJtnW xG3VdxJzdVdNVccFhxnMSRgu5qpYqWs6ZiR0xi2ipEmdixM2yn4KdWw65oqBZF50AHlOk/U8 5AJDE/V6m9bOYZzhmgdHH63TpLXsqqwfc+8lrWJC06JHO60jtXkXujtSYSx/ecsZosXd0vJf nzNMMTPN4LL7LVEu74SvITTfZKNbmZuqbsM3rXCz8c0m6bqxW+iq8RCSmFSv/UKVNVh7bgA3 KbbY222VFvNVWqJThfYjkZPPROEyQqTcZzduW1lOTRu8+NI0m+VLtXPJkUlYc7fE+x/ROY5y jaaOGDFr20dOeZw5Mks5ZMsjXQz367dWiKKcR6Td8960ti4UwsjUfFGUnBfZMqBymyACYsEY zzmRsoJpBEz0J6JQutXpTEL+YaphFIawQUxxiVxUClKDm09sattttptttttt4SayjZWYhhBh JD5jPipp7KaMs5Qgm5oxjNk7Gu+UeSuNJh+LnutazWcvHccsmqNIo5kv1Tpwj2IUQirorC+A Mp2xf7Ig6oailxVsVwhIFUDtu6dbZfOKt1Z7qvlEb+TTgz4NMaHNqaw46zKSYYhmUMLKp2GQ YSsVngF/fyf4kkKYY51VwquooooooY5bbbbbbUqk553X25cxLCUSossqZnMZXM51YX2ZZbDT 8ujVUlNZtl8rblazqN30xw29blkrZHKbs2GRSW9fHQ1zN+jdaXK627TdU45mq0sWm95PyYOm ZNjVv2ZnlyTQ4vDdwy0M5laLxERx7TsKvy5PdttttttttttyqtXJY3tLUJ8GFRsqYLM3Pmxe ZrZVJJ4xNrLbpL5DO23GfGOaaw38DDSeM28c1ndoaRifGyYG2X+WaWYMuOrjL5JtzOOc0mGd LZFm3dpXH+nCv6SLRVQtKVQrOi0lUVVFNNU6OM282DjvbaKyWmHwgiBLPdckltETyMsAAAAA CcwyOjn2syo35cJtbJm03VDg8+uc3TGlJiXim+a7ct2rc3zGvJHE2JnrovWmczMYxMJgyWY6 Z8HGXxEkzLN1RrjBcs32LnDHDeYLpq1M2SyrqLYs4QkrvWyT0c76DAAAAAAvJvsuGI2SQLGK zF1KuuOLK+bxtCmJhKakKpKlFZa6XlbjbJGW7ZGDPJJGRWGDdcmJi9S7B9YeKokzlRuzl4zq Rt2zhSLyHKzvKi8Fyhwl5VTfRMqkkY3Vrx2+YcpJ1UKpqc204gAAAAAcmQb+lMcYla7LaLxu uxZwHDZD14WkxJSUqNVktU3VSl1mulbdF9k1Y0sWl5bfnnN2NuDkYb7u8QoVa0lEVtCmYioN EsbFlqoKsacM8gAAAAALb4qNBb7KJ11i8Nayqiym+ay0Q2aLZaZxN0qS9DTXklnQ3yspS26S 0vNyxVrZmdpdTEl6VcYxKl3W0Ylb2dLq2ypiF5ab6LYa6YRvqMTOxNE22SZ4s3GjLRwi0JTd KlU5L7gAAAAAcEtVdOrTjbXgotjC4RO0TpnakqcZRGhCWs62iyd7QYWt6h72eNdNLZy81vt2 GubbW7LXLDXS+KVtcCoZGCjSSrabgAAAAAeol2K81Lzl6EUl7SiVKlKX7UoV+T7a78cTUKSy Vd/lh+1oZ1tphfKzOnMcs5bdqrqlFi0t0WX6FMdi3Za16lVMLSqgWZVRSWUkkpkqMSp+rYT5 1HwjLgXQgxfsj0ctd/yCO4jn5Eb4oxRpQxxgAVxyK/qGixgDytItMR9D/N+xH4X1uw1a/ri0 fXhZwV+NmXZqYklSdo4OiT835c4/nJiP6xqMFIp+j7LScX7o7Y88fh/0j0N6NYyA0ZUdKJQ0 IeZAkmbzG3MHn17WcR0awshQaVastba8rZ9YdkfY6eqO2PyRnBtZ7HCCtsOq7npu/dHyFRaP svbvj3o4fOu5kdsczliwcsGvB6H5X+y/u9KWFSp1k8I1jZEwKy67ktQqndG/k0/TGsmIzR81 9qRsYUqRQ0jzxhl3B6iVHGMo0TUfR7u37cb/z90dUZR3ckbXYo3yEFJ/lU+JQ+/7bGSuuPO6 457cI4BmolRnp61C/ilOzsjNPmj7seG2PXGzZtWliWUtJJSPPHJG1aPnb8QeP3t0cz1x3k3R 8vudvxc2UVoUlohpOePgidEwkZPWs7etpebtkt+nUWbn8ic0Xh6o649EaEeD96xufv+CJzk7 93TJSopRQqqqClSKlSoKUJ5RUWSiqkiqKKgoqR7EkmfYkvytz12MgAKoAuGAQAM5zcznAAC5 IYWYXUkMAuqhgBnObrOcAAAAACAABUAAC4YAAAAAAAAVAAAAAAAD365XPnnS4uTEvly8Xa5j F1TGJdfBdZztJhciTEpSjSRTiZXv3Ll0gCxMBUYgZBQFBa1rVitQF0gCxMBUYgZBQFBS1rY4 VrKJVAXSALEwFRiBkFAUFLWtjWK1AXSALEwFRiBkFAUFrWtwetLDPiOvE/VGOGERhERn4YUn GXdjZ4xlPsYxFtZL1IkH0fvXyYbH8FK3R+nDAo81FklP5N2z+1Zn8eVc1/aFVscpSjZrtw5Z oOLOYP4rJY4WitC639psccsxtqTht+fSfhe/N6/4qn2ymOjL9eTmtyOLWJl9apvkw/bkfkjo WUUTd+fMyI/mZGTCKqGi+9OCn2vnYyR1fbGt3mnhonTGR56dzOaKf72vbqUUeNVTevYeKWaO 45OnOIQ0hVSJB9Tz7yVHpaf4qNBVJiT7i7EVK4Q9xYuykj637brqqI5ZGVA8vsbuBVY5E0UO I7D8tW4uQJlBAmqibFUol5KnrYhW43qLm1WGxaJxqMauwc7V9NMSTkmyWS/Cy3C4uXkpZVlK taOypJfKxabkfsede8/dNKjjtMTS+ZeYhRyzioIOm/MvLJFFCqb5xk+1dsMeyFl/z6OSersd jSseYYF171HldtL+qVdo7D1NtslQubctc2G1q0Mj1ymFXhpZY7rMzftbJmbtkKSJhv85bapu 1NZI/H/0NheoZ6OEmbWScCiqnFvzY2GsThvwc8+DPy5SzomUXG/Tg3e/I6NitIeapPfUhB64 fCds66cOjv3FX5ruY6dOfXIp6+HQ8O4ZjF7HXE726p3VeKqTtlOwZWdXoaJm6kYWfakIOOXB hPFm+GGUdnSVO9vaqdbbMKgpFQUlTh087Km/+5+c5XRROKJBv0XknX1fDHZOWu86VCeXlMWR mtjzPOYGUN13FfzIS45GU1LjoQlkWvBtkIMDE3atJdpbRCIpURdlRuye6O2UZ5Wxt13SptmC TkhJ0ZIwZjJWuExwRByHDhtvNWbItcDrUANJNtjSKXe5q8JXvYZ6ROMNZOGskjE6sTzJUlHl FVSUUuzZewtfxXepnV6YjetO/Cz8+WyRJ25Hof4FScYcyk0od/SfHSdTTl9aeqzWt49WsNOk p9xThK4NhSqWUdCryeuMlnwPFjZPZQQZccdb39pGVHwZvM80jmdbov3sPdWpSotz7jhSFCiV SPVwnJ6J8qOn0mu1DsqWlSmjn5HjJuNbNza3Zamzrq58LZLE458pyypTr9LanLTdnfY4hVKs lh0jPBdcxNs7i96KLFhZULU6mKsYva3VEvLS9e3Pc6Xl2dDKRIKhuz+bQ1Kpkv6UJc7zWFpO o9DCeTfPVKnnVz1Ob3ltvR7RWDjCJnOHFvgTDyS8hUsqJjC1WYitEoCeVtDdvNxUlu3c77jb n41NMVfafgUnmOx17Vs4MizistIQWUZL6janSN1FoX6uEyTI2yEFQ00KjJaJqXbJlj1xSy0H wrlhTZRLMWNf0RL4jBEFpLH+B5M8TCZHpWWkKTXFsr4nBRRi44aJonmhuZNibC8ywk5ZMG9W I55JUnOu15okxeVDYKkhI2bLRrI4iYYjL+5ZSKZsKWaUqSWkapwikmSvtMR1qzcyyxws0WvK uopFlm5Nllym3LOJ7iHGcXrLp748ZSVGKg08ieHPIyRqzlvM9klp8deT5ix6j1PbCyWkcYcU UnCpQQUknM+4yLb2kzqSZpUZVVcW3SPQ9bPXiO3y6TlxEIdDkgQsUUUk4RVb0nzPlHP4803y PbadvVxyNr1s+dZ07kc7rcrWnMdEKKiopZduefzx559vynB7rrnU4O/6k08xs/5uiHXqLLPW +Na6oSDmFFCk7acqVKcyLcab4UtJnTinYjwb3WUqss8UfDTVJiyijRRaofCpGdRdUqocSlq1 nt9K7vkjKyd/Ks2S0lCxgqL3lMXsj41I4cMzbcupm9ByC5wY6+6xEG1haxjwrhNjKinbyfdq IQumolNEeitp7C3qnyOfl4mxtKibpEgqiSpZZNsuuWpSrKknpd7Cp1TTcyZIyZZ18TSxMijO pM1dGjI9BdtvE4Gq7Ck1KetmbHGm1ikz3es5C1WLaYeDuLhBRS609zvKe4VKm3iJNKbXhDmv zRx36T6dDa03qblFU5veOZml22cm5x4Zl+6Ohqa8VKRIO2hfYpwTzrM+G+JYsaXwwxnk0umF Fi9lSUqza8GmhNI1xVNzVlrGi0JBdOVGRq1FM2nD7rZrkstE0p3cYmzZuqzqqeRytYcvEj7u eXHEzYX5ZMskdKmovokjeoaFVVJl10H34+zNpHJNHmcDql5ZSMzNZ1RLjG4NcmhM0lgZGFFF sZr3ZxApJwqlSPQaDwnWe2PjclvhHDWf7vieHs8R5Knh8GpsvPkOzGbxuv0ntopYU6M7phSO +U8ek+jxWjXO27Rb2zbRlfEYOjkvEl6V6VmwpnaBCm5qbjvrJKKqlOSjlvZus4xKCC8lQo8x HMFxhT1X2lc9F5HdZaiDeTEhmN1tb4+31bCif+LuSKcKEhGWDhvA --------------58D0DF89C4FAEC5DD0FB1CA5-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Nov 13 00:25:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 163RFU-0001c7-00 for ; Tue, 13 Nov 2001 01:16:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 13 Nov 2001 01:16:20 +0100 (CET) Received: (qmail 606 invoked by uid 0); 12 Nov 2001 23:24:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 12 Nov 2001 23:24:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fACNOMF16866 for ; Mon, 12 Nov 2001 18:24:22 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 12 Nov 2001 23:23:58 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fACNNw016603 for f-cpu-list; Mon, 12 Nov 2001 18:23:58 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fACNNvj16600 for ; Mon, 12 Nov 2001 18:23:57 -0500 Received: by moria.seul.org (Postfix) id 50FBC14630A; Mon, 12 Nov 2001 18:23:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 2C4FB146309 for ; Mon, 12 Nov 2001 18:23:57 -0500 (EST) Received: from f-cpu.org (nas25-23.kdl.n.club-internet.fr [213.44.96.23]) by relay-4v.club-internet.fr (Postfix) with ESMTP id A7D6916CB for ; Tue, 13 Nov 2001 00:23:52 +0100 (CET) Message-ID: <3BF05A7C.7B07AFED@f-cpu.org> Date: Tue, 13 Nov 2001 00:25:48 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE62658.ED8E0D29@ifrance.com> <20011105012939.51086@thrai.stud.uni-hannover.de> <3BF07C1D.EA5CC6D6@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > > 3 rd time ! > > The previous log was too big : >50ko > > 2.6 ns :D hmmm ... do i have to believe this ? it looks too good ;-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Nov 13 00:54:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 163mxh-0000Fo-00 for ; Wed, 14 Nov 2001 00:27:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 14 Nov 2001 00:27:25 +0100 (CET) Received: (qmail 18951 invoked by uid 0); 12 Nov 2001 23:55:17 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 12 Nov 2001 23:55:17 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fACNtGN18586 for ; Mon, 12 Nov 2001 18:55:16 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 12 Nov 2001 23:54:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fACNstx18316 for f-cpu-list; Mon, 12 Nov 2001 18:54:55 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fACNssj18313 for ; Mon, 12 Nov 2001 18:54:54 -0500 Received: by moria.seul.org (Postfix) id 8CC9F14630A; Mon, 12 Nov 2001 18:54:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a251.home.uni-hannover.de [130.75.232.251]) by moria.seul.org (Postfix) with ESMTP id EA073146309 for ; Mon, 12 Nov 2001 18:54:52 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA26149; Tue, 13 Nov 2001 00:54:50 +0100 Message-ID: <20011113005450.22633@thrai.stud.uni-hannover.de> Date: Tue, 13 Nov 2001 00:54:50 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shifter, like during the good old days ;p References: <20011102220031.29936@thrai.stud.uni-hannover.de> <3BE469FA.D25D3498@ifrance.com> <20011103182544.64870@thrai.stud.uni-hannover.de> <3BE62658.ED8E0D29@ifrance.com> <20011105012939.51086@thrai.stud.uni-hannover.de> <3BF07C1D.EA5CC6D6@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BF07C1D.EA5CC6D6@ifrance.com>; from nicO on Mon, Nov 12, 2001 at 08:49:17PM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Nov 12, 2001 at 08:49:17PM -0500, nicO wrote: > 3 rd time ! > > The previous log was too big : >50ko > > 2.6 ns :D Much better :) Thank you. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 14 13:50:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1645Fa-0000Dz-00 for ; Wed, 14 Nov 2001 19:59:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 14 Nov 2001 19:59:06 +0100 (CET) Received: (qmail 19621 invoked by uid 0); 14 Nov 2001 12:52:20 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 14 Nov 2001 12:52:20 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAECqJI07157 for ; Wed, 14 Nov 2001 07:52:19 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 14 Nov 2001 12:50:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAECoDr06857 for f-cpu-list; Wed, 14 Nov 2001 07:50:13 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAECoCj06852 for ; Wed, 14 Nov 2001 07:50:12 -0500 Received: by moria.seul.org (Postfix) id 850E714630A; Wed, 14 Nov 2001 07:50:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 6A1BC146309 for ; Wed, 14 Nov 2001 07:50:12 -0500 (EST) Received: from club-internet.fr (flashmail-av.cs.clubint.net [172.16.0.117]) by relay-1v.club-internet.fr (Postfix) with SMTP id 430B216EA for ; Wed, 14 Nov 2001 13:50:10 +0100 (CET) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] SourceForge problems X-Mailer: Medianet/v2.0 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 14 Nov 2001 13:50:10 +0100 (CET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by belegost.mit.edu id fAECoCj06855 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, please read http://www.fsfeurope.org/news/article2001-10-20-01.en.html i'm happy we do not depend on SourceForge, and fear of such a thing happening one day was the main motivation (beside my reluctance to use "modern tools" ;-D). However i did not expect that SourceForge asks people to give up ALL copyrights. Read you soon (and meet you on sunday for those in/near Paris), YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 19 19:44:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 165zZN-0003vM-00 for ; Tue, 20 Nov 2001 02:19:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 20 Nov 2001 02:19:25 +0100 (CET) Received: (qmail 6335 invoked by uid 0); 19 Nov 2001 18:43:04 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx026-rz3) with SMTP; 19 Nov 2001 18:43:04 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAJIh3G27327 for ; Mon, 19 Nov 2001 13:43:03 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 19 Nov 2001 18:42:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAJIghS27064 for f-cpu-list; Mon, 19 Nov 2001 13:42:43 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAJIggj27061 for ; Mon, 19 Nov 2001 13:42:42 -0500 Received: by moria.seul.org (Postfix) id 072E714630A; Mon, 19 Nov 2001 13:42:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D0DBF146309 for ; Mon, 19 Nov 2001 13:42:41 -0500 (EST) Received: from f-cpu.org (nas25-16.kdl.n.club-internet.fr [213.44.96.16]) by relay-2v.club-internet.fr (Postfix) with ESMTP id CD6F418F9 for ; Mon, 19 Nov 2001 19:42:39 +0100 (CET) Message-ID: <3BF95322.1F755B3B@f-cpu.org> Date: Mon, 19 Nov 2001 19:44:50 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 18c3 References: <3BF9A713.C1624D56@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > I found something about it ! > > Whygee, i write some thing to them ? if you don't want to sleep under Berlin's bridges, yes :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Nov 20 01:42:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 165zZL-0003vM-00 for ; Tue, 20 Nov 2001 02:19:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 20 Nov 2001 02:19:23 +0100 (CET) Received: (qmail 6737 invoked by uid 0); 19 Nov 2001 18:26:52 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Nov 2001 18:26:52 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAJIQnI26841 for ; Mon, 19 Nov 2001 13:26:49 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 19 Nov 2001 18:25:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAJIPs226578 for f-cpu-list; Mon, 19 Nov 2001 13:25:54 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAJIPrj26575 for ; Mon, 19 Nov 2001 13:25:53 -0500 Received: by moria.seul.org (Postfix) id 7C03E14630A; Mon, 19 Nov 2001 13:25:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3DEC0146309 for ; Mon, 19 Nov 2001 13:25:53 -0500 (EST) Received: from ifrance.com (nas6-99.vlt.n.club-internet.fr [194.158.108.99]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 7DF95168F for ; Mon, 19 Nov 2001 19:25:47 +0100 (CET) Message-ID: <3BF9A713.C1624D56@ifrance.com> Date: Mon, 19 Nov 2001 19:42:59 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] 18c3 References: Content-Type: multipart/mixed; boundary="------------45F0082438ED56F0D79E34AC" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Il s'agit d'un message multivolet au format MIME. --------------45F0082438ED56F0D79E34AC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I found something about it ! Whygee, i write some thing to them ? nicO --------------45F0082438ED56F0D79E34AC Content-Type: text/plain; charset=iso-8859-1; name="call4paper.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="call4paper.txt" >From - Mon Nov 19 19:40:27 2001 From: Peter Schwindt <18c3@schwindt-net.de> Newsgroups: de.org.ccc,alt.2600 Subject: CfP: 18th annual Chaos Communication Congress, Berlin, Germany Followup-To: de.org.ccc Date: 18 Nov 2001 18:02:34 GMT Organization: InterNetNews at News.BelWue.DE (Stuttgart, Germany) Lines: 193 Message-ID: NNTP-Posting-Host: marwin.ba-loerrach.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.7.2 (Linux) Xref: news.club-internet.fr de.org.ccc:146918 alt.2600:434948 [Our apologies if you receive multiple postings of this CfP] * Deutsche Fassung weiter unten * ************************************************************************* Call for papers: 18C3: 18. Chaos Communication Congress 27.-29. December 2001 Papers are being solicited for the eighteenth annual Congress of the Chaos Computer Club e.V., Germany, to be held in Berlin, Germany, from December 27th through 29th. The congress is intended to promote the technical, social and political interchange of ideas among hackers, security professionals, artists, nerds and other lifeforms, watching how technology affects society. Unlike earlier incarnations, this years congress will not only address the German speaking population. It is our goal to have at least the main track of the conference held in English and translated to German or held in German and translated to English. Topics of interest include, but are not limited to: - wrecked use of mainstream technology - obfuscating code, technology and user minds - IPv6 technology and security, practical experience, 6bone statistics etc. - Ttchnical developments and protocols in the Internet (e.g. Differentiated Services, constraint-based-routing, MPLS, traffic engineering, policing, COPS, TCPng, streaming protocols, Peer2Peer-Networks, ENUM etc.) - telephone networks (wired & wireless, GSM, GPRS, EDGE, UMTS) - access technology (cable modems, satellite, WLL etc.) - surveillance technology, LI, state of the art and how to trick it - security policy and privacy Issues - security infrastructure, architecture and standards (PKCS,CMA, CDSA etc.) - watching them watching us and how to sharpen the picture - eavesdropping on (streaming) protocols (e.g. internet telephony) - operating system/platform security (any OS you can think of) - internet, communications & networking security, including wireless technologies (WaveLAN, HiperLAN, etc.) - AAA - intrusion detection and monitoring - cryptograpic algorithms, technology, toolkits, applications, etc. (e.g. AES, elliptic curves, PGP, GnuPG etc.) - smartcards & embedded anything - biometrics - copyright, copyleft, copywrong, "interlec-duh-al capital", digital rights management and the street performer protocol, DMCA vs Freedom of Speech - privacy, private data and public data and the difference, if any - misuse of (multi)media technology, "secure" devices ... - art & beauty in the global village - reverse engineering technology how-to's - circumvention devices & security countermeasures - political and legislative trends, open and hidden, concerning the net and communication technology - crypto-politics in national security - German issues as TKÜV and equivalents in other countries - European issues as Cybercrime-Convention and equivalents - hacker ethics and history - Developments in Mobile Networking (e.g. Wireless LAN, Ad-Hoc Networking, Tracking of Persons, etc.) - activism, hacktivism and other forms of political work - Organisational structures of NGOs - Underground Banking - conspiracy theories - discordianism Lectures are expected to be highly relevant in practice or better be darn funny. Sales droids have been known to disappear without traces on past events. Interactive Workshops welcome. Hands-On anything even more welcome. Intelligent beings wishing to present a paper should submit title and an one- or two-paragraph abstract (in German or English), references and URLs, a short biography, and contact information to congress-crew@ccc.de RSN, no later than December 1st. Notice of acceptance will be sent out as soon as possible. Final presentations should be in English or German and be up to 45 or up to 100 minutes long, including a question-and-answer period. As this is a non-profit organisation and non-profit event, the CCC will not be able to compensate travel or hotel costs let alone a speaker honorar, well, maybe travel costs. We are, however, able to arrange accomodation for low or no cost. The preliminary agenda will be published on the web http://www.ccc.de/congress/ in the near future. Registration information will be posted, too. So, do you dare to speak in front of people who might have downloaded your script from your computer in advance and spotted all the logical errors? Do you read me, HAL? **************************************************************************** Call for Papers: 18C3: 18. Chaos Communication Congress 27.-29. Dezember 2001 Für den 18. jährlichen Congress des Chaos Computer Club e.V. werden Vortragende und Veröffentlichungen erbeten. Der Kongress findet zwischen dem 27. und dem 29. Dezember in Berlin, Deutschland, statt. Das Ziel des Kongresses ist es, den Austausch von technischen, gesellschaftlichen und politischen Ideen zwischen Hackern, Sicherheits-Experten, Künstlern, "Nerds" und anderen Lebensformen, die sich mit dem Einfluß von Technik auf die Gesellschaft beschäftigen, zu fördern. Im Gegensatz zu den Kongressen in der Vergangenheit soll dieser Kongress nicht in erster Linie nur die deutschprachige Bevölkerung ansprechen. Es ist unser erklärtes Ziel, zumindest die Hauptveranstaltungen der Konferenz auf deutsch mit englischer Simultanübersetzung bzw. auf englisch mit deutscher Simultanübersetzung anzubieten. Die Themen des Congresses sind u.a.: - kreative Nutzung von etablierter Technik - Verschleierung von Code, Technik und den Gedanken der Nutzer - IPv6 Technologie und Sicherheit, praktische Erfahrungen, 6bone Statistiken - Entwurf neuer Protokolle im Internet (z.B. Differentiated Services, Constraint based Routing, MPLS, Verkehrsplanung, Policing, COPS, TCPng, Streaming, eer2Peer-Netze, ENUM usw.) - Telefonnetze (drahtgebunden/drahlos, GSM, GPRS, EDGE, UMTS usw.) - Netzwerk-Zugangs-Technologie (z.B. Kabelmodems, Satelliten, WLL usw.) - Überwachungs-Technik, "Lawful Interception", Stand der Technik und wie man sie austrickst - Sicherheits-Strategien und Schutz der Privatsphäre - Sicherheits-Infrastruktur, -Architektur und Standards (PKCS, CMS, CDSA usw.) -- "watching them watching us" - Abhören von Daten- und Telefonverkehr - Betriebssysteme und Plattformen - Internet-, Datenübermittlungs- und Netzwerk-(Un)Sicherheit, insbesondere auch von drahtlosen Netze (WaveLAN, HiperLAN/2 usw.) - AAA - Eindringlingserkennung und -überwachung - Kryptoalgorithmen, -technik und -anwendungen (z.B. AES, elliptic curves, PGP, GnuPG usw.) - "Smartcards" und "Embedded Systems" - Biometrie - Urheberrecht, "Copyright vs. Copyleft", "interlec-duh-al capital", "Digital Rights Management" und "Street Performer Protocol", Gesetze (DMCA, EU) und Meinungsfreiheit - Informationale Selbstbestimmung, private und öffentliche Daten und deren Unterschied (falls vorhanden...) - Miß/Gebrauch von Multimedia, "sicheren" Geräten - Kunst und Schönheit im globalen Dorf - Die Kunst des Reverse Engineering - Geräte zur Umgehung von Kopierschutzmethoden, Sicherheits-Gegenmaßnahmen - Politische und gesetzgeberische Entwicklung, im Offenen und Verborgenen, Netz- und Kommunikationstechnik betreffend - Krypto-Politik als Element der sog. Nationalen Sicherheit - Themen, die Deutschland betreffen (z.B. TKÜV, "Otto-Katalog"), ähnliches in anderen Ländern - Themen, die Europa betreffen (z.B. Cyber-crime Convention usw.) - Hacker-Ethik und Geschichte - Entwicklungen in mobilen Netzen (z.B. FunkLAN, AdHoc-Netze, Standortbestimmung und Bewegungsprofile von Personen usw.) - Aktivismus, Hacktivismus und andere Arten politischer Arbeit - Struktur von Nichtregierungs-Organisationen - "Underground Banking" - Verschwörungstheorien, "Discordianism" Interaktive Workshops und praktische Vorführungen werden bevorzugt. Intelligente Wesen, die vortragen möchten, werden gebeten, bis zum 1. Dezember 2001 den Titel und eine einen oder zwei Absätze lange Zusammenfassung des Vortrags (auf englisch oder deutsch), Verweise und URLs, eine Kurzbiographie und Kontakt-Informationen an zu schicken. Die Benachrichtigung über die Annahme des Vortrags wird so schnell wie möglich verschickt. Die Vorträge sollten auf englisch oder deutsch gehalten werden und bis zu 45 oder bis zu 100 Minuten lang sein, inklusive Fragen aus dem Publikum. Da dies eine gemeinnützige und nicht gewinnverfolgende Veranstaltung ist, kann der CCC leider keine Kostenerstattung geschweige denn ein Honorar zahlen. Lediglich unter besonderen Umständen ist eine Reisekostenerstattung möglich. Wir können jedoch günstige Unterkünfte vermitteln. Die vorläufige Agenda wird im Web unter http://www.ccc.de/congress veröffentlicht. Das gleiche gilt für Informationen zur Teilnehmer-Registrierung. Also, traust Du Dich, vor Leuten zu sprechen, die möglicherweise im voraus Dein Vortragsskript aus Deinem Computer gezogen und alle logischen Fehler gefunden haben? Do you read me, HAL? --------------45F0082438ED56F0D79E34AC-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Nov 21 19:03:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 166hXJ-0000Fr-00 for ; Thu, 22 Nov 2001 01:16:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 22 Nov 2001 01:16:13 +0100 (CET) Received: (qmail 5949 invoked by uid 0); 21 Nov 2001 18:02:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx025-rz3) with SMTP; 21 Nov 2001 18:02:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fALI2R525475 for ; Wed, 21 Nov 2001 13:02:27 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 21 Nov 2001 18:01:33 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fALI1Su25208 for f-cpu-list; Wed, 21 Nov 2001 13:01:28 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fALI1Qo25205 for ; Wed, 21 Nov 2001 13:01:26 -0500 Received: by moria.seul.org (Postfix) id B55C0146661; Wed, 21 Nov 2001 13:01:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 9C478146660 for ; Wed, 21 Nov 2001 13:01:26 -0500 (EST) Received: from f-cpu.org (nas15-109.kdl.n.club-internet.fr [213.44.9.109]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 9E03E16EB; Wed, 21 Nov 2001 19:01:23 +0100 (CET) Message-ID: <3BFBEC7A.CD9FF8F1@f-cpu.org> Date: Wed, 21 Nov 2001 19:03:38 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Haneef Mohammed Cc: ff , fm Subject: [f-cpu] Re: Simili 2 References: <3BEDD56A.6EA8EDA0@f-cpu.org> <002f01c172ad$67b7ec20$2201a8c0@bvrtn1.or.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Haneef Mohammed wrote: > Hi YG, > > Sorry for the late reply. no worries :-) > Interesting idea of writing > out an elaborated netlist. However, there are some hurdles > because by the time I elaborate things, some information > (that may be critical to synthesis) is lost, expressions get > optimized and munged, and type information may get cloberred. > Let me think about it.... if you need help, you'll find it. however, all i was referring to was a simple "dirty hack" (a few hundreds lines of C code) and trying to make a synthesiser would make it more complex than everything. If we stick to the idea of a "pretty-printed dump", it will be easy. However you're the person who decides so i'll follow your choice. Btw i asked the same question to Cadence and the answer is less interested. > I have some news though. I have the linux version ready > for trial rides. The simulator/compiler are very stable > and the GUI is pretty mature.... congratulations ! > I have a few users using it now. I was wondering if you > were interested in giving it a try (You will need RedHat 7.1 > or compatible). of course i'm interested ! :-) on top of that, i am about to write a french article entitled "developping in VHDL under Linux". This would be a french, redacted version of the VHDL-HOWTO.f-cpu i wrote when installing VHDL tools. I will shortly describe how we design the F-CPU with Vanilla and Simili. If i can get my hands on S2 within the next few days, i'll simply bypass the part where Wine is configured :-) I forward this answer to the F-CPU lists because i think that other people would like to test S2 as well. Thank you for the good news : i needed them today (i have learnt today that i won't do the doctorate things at the department where i am now. too bad). If you want to upload S2, you can use our anonymous ftp (user= anonymous, password=emailaddress) at ftp.seul.org, in the pub/f-cpu/contrib directory. thank you for your help, > Regards, > Haneef WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Nov 23 11:57:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167QBB-00012o-01 for ; Sat, 24 Nov 2001 00:56:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 24 Nov 2001 00:56:21 +0100 (CET) Received: (qmail 16167 invoked by uid 0); 23 Nov 2001 10:57:06 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx014-rz3) with SMTP; 23 Nov 2001 10:57:06 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fANAv1s16457 for ; Fri, 23 Nov 2001 05:57:01 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 23 Nov 2001 10:55:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fANAtjb16186 for f-cpu-list; Fri, 23 Nov 2001 05:55:45 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fANAtfo16182 for ; Fri, 23 Nov 2001 05:55:41 -0500 Received: by moria.seul.org (Postfix) id 01054146661; Fri, 23 Nov 2001 05:55:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CF24E146660 for ; Fri, 23 Nov 2001 05:55:40 -0500 (EST) Received: from f-cpu.org (nas15-156.kdl.n.club-internet.fr [213.44.9.156]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 3052716F3 for ; Fri, 23 Nov 2001 11:55:38 +0100 (CET) Message-ID: <3BFE2BB1.888196F0@f-cpu.org> Date: Fri, 23 Nov 2001 11:57:53 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] (Code Review) Call for general/public code review Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, it's incredible, what i can think of when i'm not sitting before the computer (i won't speak about where i was sitting when this one struck). the idea is : everyday, a new file from the F-CPU VHDL code source tree is posted and discussed the following days on the list. The poster will be the one who wrote the file or modified it last. The original poster will write as many comment and explanations as possible. This way, we can synchronize our files and understanding of the project. We will be able to discuss about the overall and detailed coding strategy during a few months. I don't expect all files to trigger big discussions, so a good proportion of files will be hardly noticed. This will leave enough time/bandwidth for the discussions about important stuffs. Can anybody setup a CROND ? :-) btw: all posts related to the public code review should have a subject beginning with (CR) followed by the local path and name of the file in the f-cpu directory. This way, we will not get confused about the discussion if two files have the same name. any idea / suggestion / comment ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : Simili 2 is going to rock under Linux :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Nov 23 13:42:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167QBF-00012o-00 for ; Sat, 24 Nov 2001 00:56:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 24 Nov 2001 00:56:25 +0100 (CET) Received: (qmail 31363 invoked by uid 0); 23 Nov 2001 19:05:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx031-rz3) with SMTP; 23 Nov 2001 19:05:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fANJ5ZH31362 for ; Fri, 23 Nov 2001 14:05:35 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 23 Nov 2001 19:04:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fANJ4mY31086 for f-cpu-list; Fri, 23 Nov 2001 14:04:48 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fANJ4lo31083 for ; Fri, 23 Nov 2001 14:04:47 -0500 Received: by moria.seul.org (Postfix) id DDE71146661; Fri, 23 Nov 2001 14:04:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a194.home.uni-hannover.de [130.75.232.194]) by moria.seul.org (Postfix) with ESMTP id E60EF146660 for ; Fri, 23 Nov 2001 14:04:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00494; Fri, 23 Nov 2001 13:42:53 +0100 Message-ID: <20011123134253.35812@thrai.stud.uni-hannover.de> Date: Fri, 23 Nov 2001 13:42:53 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] (Code Review) Call for general/public code review References: <3BFE2BB1.888196F0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BFE2BB1.888196F0@f-cpu.org>; from Yann Guidon on Fri, Nov 23, 2001 at 11:57:53AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Nov 23, 2001 at 11:57:53AM +0100, Yann Guidon wrote: > it's incredible, what i can think of when i'm not sitting before > the computer (i won't speak about where i was sitting when this one > struck). I guess I know where ;) At least, I have my "special places" too. > the idea is : everyday, a new file from the F-CPU VHDL code source tree > is posted and discussed the following days on the list. > The poster will be the one who wrote the file or modified it last. Public review is a good idea (it's one of te core principles of the Open Source programming model). Doing it one file at a time is not so good, IMHO. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Nov 23 23:05:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167QBH-00012o-00 for ; Sat, 24 Nov 2001 00:56:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 24 Nov 2001 00:56:27 +0100 (CET) Received: (qmail 18031 invoked by uid 0); 23 Nov 2001 22:03:50 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Nov 2001 22:03:50 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fANM3nX05939 for ; Fri, 23 Nov 2001 17:03:49 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 23 Nov 2001 22:03:15 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fANM3EO05671 for f-cpu-list; Fri, 23 Nov 2001 17:03:14 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fANM3Do05668 for ; Fri, 23 Nov 2001 17:03:13 -0500 Received: by moria.seul.org (Postfix) id 2FACF146661; Fri, 23 Nov 2001 17:03:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 0B7F5146660 for ; Fri, 23 Nov 2001 17:03:13 -0500 (EST) Received: from f-cpu.org (nas20-210.kdl.n.club-internet.fr [213.44.18.210]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 5426F16D4 for ; Fri, 23 Nov 2001 23:03:09 +0100 (CET) Message-ID: <3BFEC825.DC002A85@f-cpu.org> Date: Fri, 23 Nov 2001 23:05:25 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (Code Review) Call for general/public code review References: <3BFE2BB1.888196F0@f-cpu.org> <20011123134253.35812@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Fri, Nov 23, 2001 at 11:57:53AM +0100, Yann Guidon wrote: > > the idea is : everyday, a new file from the F-CPU VHDL code source tree > > is posted and discussed the following days on the list. > > The poster will be the one who wrote the file or modified it last. > Public review is a good idea (it's one of te core principles of the > Open Source programming model). Doing it one file at a time is not so > good, IMHO. it was an idea. If you have a better, simpler, whatever, one, just tell us :-) Only a few subscribers of this mailing list have read most files and even less understand them. Posting one files a day on the list will expose and explain every file, so lurkers can have a better overview. This will also allow to detail stuffs that we once forgot, remember what and whys, enhance the documentation... A general code review becomes necessary because our code trees are getting rather anarchic, i think. it's slowly "rotting" and it requires continuous efforts. btw, on the french mailing list, we started speaking about the integer divider unit. Cedric has got an algorithm and he'll work on it during the next weeks, i guess, starting with behavioural dedfinitions. To simplify things, the clock will be halved locally to avoid pipelining the 64-bit substractor... > Michael "Tired" Riepe WHYGEE, programming where noone does... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Sat Nov 24 00:27:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167pGU-0000VI-00 for ; Sun, 25 Nov 2001 03:43:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 03:43:30 +0100 (CET) Received: (qmail 31241 invoked by uid 0); 23 Nov 2001 23:31:34 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 23 Nov 2001 23:31:34 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fANNVXx07509 for ; Fri, 23 Nov 2001 18:31:33 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Fri, 23 Nov 2001 23:30:56 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fANNUt907242 for f-cpu-list; Fri, 23 Nov 2001 18:30:55 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fANNUro07239 for ; Fri, 23 Nov 2001 18:30:54 -0500 Received: by moria.seul.org (Postfix) id C1535146661; Fri, 23 Nov 2001 18:30:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from studserv.stud.uni-hannover.de (mx.stud.uni-hannover.de [130.75.176.3]) by moria.seul.org (Postfix) with ESMTP id 633EF146660 for ; Fri, 23 Nov 2001 18:30:53 -0500 (EST) Received: from tribble.stud.uni-hannover.de (a125.home.uni-hannover.de [130.75.232.125]) by studserv.stud.uni-hannover.de (8.12.1/8.12.1/MX/check_local5.0) with ESMTP id fANNTfV1005474 for ; Sat, 24 Nov 2001 00:30:21 +0100 (MET) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00536; Sat, 24 Nov 2001 00:27:05 +0100 Message-ID: <20011124002705.21141@thrai.stud.uni-hannover.de> Date: Sat, 24 Nov 2001 00:27:05 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] (Code Review) Call for general/public code review References: <3BFE2BB1.888196F0@f-cpu.org> <20011123134253.35812@thrai.stud.uni-hannover.de> <3BFEC825.DC002A85@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3BFEC825.DC002A85@f-cpu.org>; from Yann Guidon on Fri, Nov 23, 2001 at 11:05:25PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Nov 23, 2001 at 11:05:25PM +0100, Yann Guidon wrote: [...] > > Public review is a good idea (it's one of te core principles of the > > Open Source programming model). Doing it one file at a time is not so > > good, IMHO. > it was an idea. If you have a better, simpler, whatever, one, > just tell us :-) Unit/module based. > Only a few subscribers of this mailing list have read most files > and even less understand them. Posting one files a day on the list > will expose and explain every file, so lurkers can have a better > overview. This will also allow to detail stuffs that we once forgot, > remember what and whys, enhance the documentation... I can post the files, but currently I have no time to write documentation -- for the next 6 months I will be very busy. > A general code review becomes necessary because our code trees > are getting rather anarchic, i think. it's slowly "rotting" > and it requires continuous efforts. Hmm... > btw, on the french mailing list, we started speaking about the > integer divider unit. Cedric has got an algorithm and he'll work > on it during the next weeks, i guess, starting with behavioural > dedfinitions. To simplify things, the clock will be halved locally > to avoid pipelining the 64-bit substractor... Can you (or cedric) please provide some details? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Nov 24 05:50:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167pGU-0000VI-01 for ; Sun, 25 Nov 2001 03:43:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 03:43:30 +0100 (CET) Received: (qmail 17930 invoked by uid 0); 24 Nov 2001 04:48:36 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx028-rz3) with SMTP; 24 Nov 2001 04:48:36 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAO4mZZ13928 for ; Fri, 23 Nov 2001 23:48:35 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 24 Nov 2001 04:47:54 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAO4ls613661 for f-cpu-list; Fri, 23 Nov 2001 23:47:54 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAO4lro13658 for ; Fri, 23 Nov 2001 23:47:53 -0500 Received: by moria.seul.org (Postfix) id 32686146661; Fri, 23 Nov 2001 23:47:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 01E2E146660 for ; Fri, 23 Nov 2001 23:47:52 -0500 (EST) Received: from f-cpu.org (nas20-16.kdl.n.club-internet.fr [213.44.18.16]) by relay-4v.club-internet.fr (Postfix) with ESMTP id EB2071690 for ; Sat, 24 Nov 2001 05:47:46 +0100 (CET) Message-ID: <3BFF26FB.74CE1C10@f-cpu.org> Date: Sat, 24 Nov 2001 05:50:03 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] whygee's Nth slaughtered ROP2 version Content-Type: multipart/mixed; boundary="------------BAFABB5A1D3F3774DB7F10F8" Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------BAFABB5A1D3F3774DB7F10F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, so i did it again... You know i can't keep myself from overdoing it... This time i checked wih Vanilla, Simili and ncvhdl. there are some french comments because i want to use these files as a tutorial for a french magazine... this is why i skipped the xbar buffer and LUT. btw, nicO, could you please check if synopsis groks it ? @+ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------BAFABB5A1D3F3774DB7F10F8 Content-Type: text/plain; charset=iso-8859-1; name="rop2_unit.vhdl" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="rop2_unit.vhdl" -------------------------------------------------------------------------- -- f-cpu/vhdl/eu_rop2/rop2_unit.vhdl - ROP2 Execution Unit for the F-CPU -- Copyright (C) 2000-2001 Yann GUIDON (whygee@f-cpu.org) -- -- v0.2: Michael Riepe reorganized the main for-generate loop -- + corrected the lookup table (wrong op for ORN) -- v0.3: YG replaced UMAX/8 with MAXSIZE :-) -- v0.4: 11/17/2000, YG wants to rewrite the unit with MR's gate library ... -- -> abandonned. we stick to high-level coding. -- v0.5: 8/12/2001, YG modifies the interface, the names, adds MUX,... -- Sun Aug 12 01:16:11 2001: still untested but it includes -- the latest updates to the FC0 core. -- Tue Aug 21 08:45:16 2001: trying to make something that works reasonably. -- Mon Sep 3 08:49:45 2001: YG fixed some silly compile bugs :-/ -- vanillaHDL script and testbench added. -- Sun Oct 7 05:39:23 2001: changed ROP2 function to MUX4 -- Mon Oct 8 01:39:45 2001: merged SELECT with the FANOUT loop. -- sam nov 24 04:40:35 2001: cleanup --------------------------BEGIN-VHDL-LICENCE----------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ---------------------------END-VHDL-LICENCE------------------------------ -- -- It should be easily synthetizable but it is not attempted yet. -- What matters most today is that it compiles and behaves correctly. -- Warning : this code is and should remain purely combinatorial, -- there is no latching here, it must be done at another level. -- Furthermore, the function lookup table is now moved earlier -- in the pipeline, in parallel with the Xbar cycle : look at the -- f-cpu/vhdl/eu_rop2/rop2_xbar.vhdl file -- The big fanout problems (propagation of the opcode from 1 to 64 bits) -- overlaps the Xbar cycle so we can make a nice "signal tree". -- Finally, only byte combines are possible yet. The COMBINE -- instruction is still not completely specified in the manual. -------------------------------------------------------------------------- -- inclusion des librairies standard LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; -- inclusion des définitions globales du F-CPU LIBRARY work; USE work.FCPU_config.ALL; -- définition de l'interface du circuit : Entity EU_ROP2 is port( ROP2_in_A, ROP2_in_B, ROP2_in_C : in F_VECTOR; -- the 3 operands ROP2_function_bit0, ROP2_function_bit1, -- pre-buffered boolean function bits ROP2_function_bit2, ROP2_function_bit3 : in Std_ulogic_vector((MAXSIZE *2) downto 0); -- fanout=4 ROP2_mode : in Std_ulogic_vector(1 downto 0); -- 2 function bits from the instruction -- Combine_size : in Std_ulogic_vector(1 downto 0); -- unused ATM. Byte chuncks only. ROP2_out : out F_VECTOR -- the result ); end EU_ROP2; Architecture arch1 of EU_ROP2 is -- signaux internes, "variables locales" : signal partial_ROP, partial_MUX : F_VECTOR; -- the partial results. signal partial_OR1, partial_OR2, partial_AND1, partial_AND2 : Std_ulogic_vector(MAXSIZE-1 downto 0); signal partial_OR, partial_AND : Std_ulogic_vector((MAXSIZE*2)-1 downto 0); -- these signals help for the fanout problem subtype sv2 is std_ulogic_vector(1 downto 0); -- this solves simili's syntax limit for the with .. select begin -- cette partie est en mode "concurrentiel" : -- l'ordre des parties n'importe pas puisqu'on ne fait que décrire -- les connexions ou les dépendances de données. Cela permet de -- ne faire que deux boucles au lieu de 3. -------------------------------------------------------------------------- -- ROP2 cycle : (combinational part only) -------------------------------------------------------------------------- -- 1 : last fanout for the function bits + the ROP2 operator itself : -- (the former loop was merged with the ROP2/MUX operation) mux_loop : for i in UMAX-1 downto 0 generate with sv2'(ROP2_in_A(i) & ROP2_in_B(i)) select partial_ROP(i) <= ROP2_function_bit0(i/4) when "00", ROP2_function_bit1(i/4) when "10", ROP2_function_bit2(i/4) when "01", ROP2_function_bit3(i/4) when others; -- "11" -- 2 bis : the "select" MUX with ROP2_in_C(i) select partial_MUX(i) <= ROP2_in_B(i) when '1', ROP2_in_A(i) when others; -- '0' -- 4 : final selection stage : with ROP2_mode select ROP2_out(i) <= partial_ROP(i) when ROP2_DIRECT_MODE, partial_AND(i/4) when ROP2_AND_MODE, partial_OR(i/4) when ROP2_OR_MODE, partial_MUX(i) when others; -- MUX -- YG> warning : huge fanous on ROP2_mode ! 1->64 for 4 signals, -- i hope that the synthesiser will generate the proper buffer tree. end generate mux_loop; -- 3 : partial ORs and ANDs on the byte chuncks : BYTE_COMBINE : for i in MAXSIZE-1 downto 0 generate partial_AND1(i) <= partial_ROP(8*i) and partial_ROP(8*i+1) and partial_ROP(8*i+2) and partial_ROP(8*i+3); partial_AND2(i) <= partial_ROP(8*i+4) and partial_ROP(8*i+5) and partial_ROP(8*i+6) and partial_ROP(8*i+7); partial_OR1(i) <= partial_ROP(8*i) or partial_ROP(8*i+1) or partial_ROP(8*i+2) or partial_ROP(8*i+3); partial_OR2(i) <= partial_ROP(8*i+4) or partial_ROP(8*i+5) or partial_ROP(8*i+6) or partial_ROP(8*i+7); partial_AND(i*2) <= partial_AND1(i) and partial_AND2(i); partial_AND(i*2+1) <= partial_AND1(i) and partial_AND2(i); partial_OR(i*2) <= partial_OR1(i) or partial_OR2(i); partial_OR(i*2+1) <= partial_OR1(i) or partial_OR2(i); -- YG> I'm still uncertain about the best way to write a multi-size version -- YG> because the latency might explode the ROP2 unit's performance. -- YG> So the multi-size version is dropped until it becomes necessary. -- YG> Let's stick to plain bytes... -- YG> Note : rop2.eps explains the trick to relieve the fanout (1->8) problem. end generate BYTE_COMBINE; end; --------------BAFABB5A1D3F3774DB7F10F8 Content-Type: application/x-sh; name="scripts.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scripts.sh" vhdlp -strict f-cpu_config.vhdl rop2_unit.vhdl mkvlib work va87 -x f-cpu_config.vhdl rop2_unit.vhdl ncvhdl -work worklib -cdslib /c/d/lm02/cds.lib -messages /c/d/lm02/f-cpu_config.vhdl /c/d/lm02/rop2_unit.vhdl --------------BAFABB5A1D3F3774DB7F10F8 Content-Type: text/plain; charset=us-ascii; name="f-cpu_config.vhdl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f-cpu_config.vhdl" ------------------------------------------------------------------------- -- WARNING ! This file is a manual, shortened version ! --------------------------BEGIN-VHDL-LICENCE----------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ---------------------------END-VHDL-LICENCE------------------------------ -- -- (c) Yann GUIDON, oct. 21, 2000 -- v0.2 : Michael Riepe changed F_RANGE -- v0.3 : YG specified the user-modifiable constants + GPL -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants. -- v0.5 : nov. 17, 2000, YG added SR_IRQ_BASE, SR_TRAP_BASE, -- SR_SYSCALL_BASE, SR_URL etc. -- v0.6 : nov. 26, 2000, YG moved some SR stuff to /VHDL/EU_sr -- v0.7 : aug. 19, 2001, YG hacked for m4 preprocessing. -- run f-cpu/configure.sh to update this file. -- v0.8 : aug. 28, 2001 : YG + MR modified some stuffs. -- MR hinted the "eval(radix)" trick, status is satisfying. -- -- This version is for demonstration only. -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. -- -- ************************************************************** -- WARNING : All the user-modifiable values are defined in the -- f-cpu/configuration/f-cpu_user.m4 file. -- ************************************************************** -- -- * LOGMAXSIZE : Log2 of the Size of the registers in bytes. -- Can be any integer above or equal to 2. 2 corresponds to -- a 32-bit implementation, 3 corresponds to a 64-bit version. -- This is the most important parameter, the first with -- which one can play. Be careful anyway. The 32-bit version will -- not work yet. -- LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ -- Number >=2, 3 corresponds to 64-bit registers constant LOGMAXSIZE : natural := 3; -- defined in f-cpu/configuration/f-cpu_user.m4 -- Size of the registers in bytes constant MAXSIZE : natural := 2**LOGMAXSIZE; -- Size of the registers in bits. constant UMAX : natural := MAXSIZE * 8; -- Range of a register width declaration. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- shortcut for a very common declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; ------------------------------------------------------- -- The ROP2 unit : these constants specify the -- correspondance between the binary code and the actual -- operation. These data are copied here for convenience -- only, for example if you want to make an assembler in -- VHDL. Check the file rop2_xbar.vhdl for more informations. -------------------------------------------------------- constant ROP2_DIRECT_MODE : std_ulogic_vector(1 downto 0) := "00"; constant ROP2_AND_MODE : std_ulogic_vector(1 downto 0) := "01"; constant ROP2_OR_MODE : std_ulogic_vector(1 downto 0) := "10"; constant ROP2_MUX_MODE : std_ulogic_vector(1 downto 0) := "11"; constant ROP2_AND : std_ulogic_vector(2 downto 0) := "000"; constant ROP2_ANDN : std_ulogic_vector(2 downto 0) := "001"; constant ROP2_XOR : std_ulogic_vector(2 downto 0) := "010"; constant ROP2_OR : std_ulogic_vector(2 downto 0) := "011"; constant ROP2_NOR : std_ulogic_vector(2 downto 0) := "100"; constant ROP2_XNOR : std_ulogic_vector(2 downto 0) := "101"; constant ROP2_ORN : std_ulogic_vector(2 downto 0) := "110"; constant ROP2_NAND : std_ulogic_vector(2 downto 0) := "111"; constant ROP2_VALUE_AND : std_ulogic_vector(3 downto 0) := "0001"; constant ROP2_VALUE_ANDN : std_ulogic_vector(3 downto 0) := "0010"; constant ROP2_VALUE_XOR : std_ulogic_vector(3 downto 0) := "0110"; constant ROP2_VALUE_OR : std_ulogic_vector(3 downto 0) := "0111"; constant ROP2_VALUE_NOR : std_ulogic_vector(3 downto 0) := "1000"; constant ROP2_VALUE_XNOR : std_ulogic_vector(3 downto 0) := "1001"; constant ROP2_VALUE_ORN : std_ulogic_vector(3 downto 0) := "1011"; constant ROP2_VALUE_NAND : std_ulogic_vector(3 downto 0) := "1110"; end FCPU_config; package body FCPU_config is -- vide pour cette version "courte". end FCPU_config; --------------BAFABB5A1D3F3774DB7F10F8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Sat Nov 24 19:21:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167pGc-0000VI-01 for ; Sun, 25 Nov 2001 03:43:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 03:43:38 +0100 (CET) Received: (qmail 32636 invoked by uid 0); 24 Nov 2001 18:23:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 24 Nov 2001 18:23:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAOINEh29467 for ; Sat, 24 Nov 2001 13:23:14 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 24 Nov 2001 18:21:55 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAOILtX29193 for f-cpu-list; Sat, 24 Nov 2001 13:21:55 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAOILro29190 for ; Sat, 24 Nov 2001 13:21:53 -0500 Received: by moria.seul.org (Postfix) id D0E7C146661; Sat, 24 Nov 2001 13:21:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.seul.org (Postfix) with ESMTP id 6E60D146660 for ; Sat, 24 Nov 2001 13:21:52 -0500 (EST) Received: from skule.ecf (fender@skule.ecf [128.100.8.6]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id NAA04184 for ; Sat, 24 Nov 2001 13:21:47 -0500 Received: from localhost (fender@localhost) by skule.ecf (SGI-8.9.3/8.9.3) with SMTP id NAA49451 for ; Sat, 24 Nov 2001 13:21:47 -0500 (EST) X-Authentication-Warning: skule.ecf: fender owned process doing -bs Date: Sat, 24 Nov 2001 13:21:47 -0500 (EST) From: Josh Fender X-Sender: fender@skule.ecf To: fm Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version In-Reply-To: <3BFF26FB.74CE1C10@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi YG, You may not remember me but I'm one of the lurkers who occationally runs your vhdl code through synthesis and place and route software. The code you attached to your previous message runs through Synplify Pro with no errors or warnings. Maybe a less useful, but more interesting, fact is that when placed in a Xilinx Virtex grade 6 chip it runs at 85MHz. This number is calculated based on driving the input/output signals directly from/to pins on the FPGA, so on a real intergrated system the timing would probably be closer to 100MHz or possibly even better. On a slightly different note, I could test the unit in a real FPGA if you have any test vectors. - Josh ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 25 03:47:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167pvW-0001IH-00 for ; Sun, 25 Nov 2001 04:25:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 04:25:54 +0100 (CET) Received: (qmail 4100 invoked by uid 0); 25 Nov 2001 02:46:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx035-rz3) with SMTP; 25 Nov 2001 02:46:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAP2kH121458 for ; Sat, 24 Nov 2001 21:46:17 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 02:45:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAP2j8220928 for f-cpu-list; Sat, 24 Nov 2001 21:45:08 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAP2j2o20916 for ; Sat, 24 Nov 2001 21:45:02 -0500 Received: by moria.seul.org (Postfix) id 3B910146663; Sat, 24 Nov 2001 21:45:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 17854146661 for ; Sat, 24 Nov 2001 21:45:02 -0500 (EST) Received: from f-cpu.org (nas15-11.kdl.n.club-internet.fr [213.44.9.11]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 54A7616AC for ; Sun, 25 Nov 2001 03:44:54 +0100 (CET) Message-ID: <3C005BAF.A85B32AE@f-cpu.org> Date: Sun, 25 Nov 2001 03:47:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (Code Review) Call for general/public code review References: <3BFE2BB1.888196F0@f-cpu.org> <20011123134253.35812@thrai.stud.uni-hannover.de> <3BFEC825.DC002A85@f-cpu.org> <20011124002705.21141@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Nov 23, 2001 at 11:05:25PM +0100, Yann Guidon wrote: > [...] > > > Public review is a good idea (it's one of te core principles of the > > > Open Source programming model). Doing it one file at a time is not so > > > good, IMHO. > > it was an idea. If you have a better, simpler, whatever, one, > > just tell us :-) > Unit/module based. then, a module will need one week or something like that. i am reworking on the ROP2 unit, along with trying to adapt the existing files for Simili2 and ncvhdl... > > Only a few subscribers of this mailing list have read most files > > and even less understand them. Posting one files a day on the list > > will expose and explain every file, so lurkers can have a better > > overview. This will also allow to detail stuffs that we once forgot, > > remember what and whys, enhance the documentation... > I can post the files, but currently I have no time to write > documentation -- for the next 6 months I will be very busy. i understand. > > btw, on the french mailing list, we started speaking about the > > integer divider unit. Cedric has got an algorithm and he'll work > > on it during the next weeks, i guess, starting with behavioural > > dedfinitions. To simplify things, the clock will be halved locally > > to avoid pipelining the 64-bit substractor... > Can you (or cedric) please provide some details? more on this subject in the middle of next week. most issues are still open and hot... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 25 03:47:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 167pvW-0001IH-01 for ; Sun, 25 Nov 2001 04:25:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 04:25:54 +0100 (CET) Received: (qmail 18467 invoked by uid 0); 25 Nov 2001 02:46:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 25 Nov 2001 02:46:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAP2kIt21468 for ; Sat, 24 Nov 2001 21:46:18 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 02:45:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAP2jGH20957 for f-cpu-list; Sat, 24 Nov 2001 21:45:16 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAP2j2o20914 for ; Sat, 24 Nov 2001 21:45:02 -0500 Received: by moria.seul.org (Postfix) id 3D53B146664; Sat, 24 Nov 2001 21:45:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 14D5C146660 for ; Sat, 24 Nov 2001 21:45:02 -0500 (EST) Received: from f-cpu.org (nas15-11.kdl.n.club-internet.fr [213.44.9.11]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D7CB216A2 for ; Sun, 25 Nov 2001 03:44:53 +0100 (CET) Message-ID: <3C005BB0.F7F04150@f-cpu.org> Date: Sun, 25 Nov 2001 03:47:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Josh Fender wrote: > > Hi YG, > You may not remember me but I'm one of the lurkers who occationally runs > your vhdl code through synthesis and place and route software. i think you posted a few times already :-) welcome back ! > The code you attached to your previous message runs through Synplify Pro > with no errors or warnings. pfiew. the contrary would have been a bit surprising because it's the most reworked unit i wrote :-) > Maybe a less useful, but more interesting, fact is > that when placed in a Xilinx Virtex grade 6 chip it runs at 85MHz. the little problem is that i don't know whether it's fas or slow. recently, nicO announced that the shifter ran at 2.6ns on a different technology, so it's difficult to compare. We can also test different "architectures", particularly concerning the "combine" strategy (whether my new method or Michael's is faster, and on what target etc...)... > This number is calculated based on driving the input/output signals > directly from/to pins on the FPGA, so on a real intergrated system the > timing would probably be closer to 100MHz or possibly even better. that's a good news, right :-) > On a slightly different note, I could test the unit in a real FPGA if > you have any test vectors. i am about to do it, it should be ready within a few days. however, i do test vectors for VHDL testbenches, not FPGA tests : will you be able to adapt them ? thank you again, > - Josh WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Nov 25 21:53:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1681Ca-0001T0-00 for ; Sun, 25 Nov 2001 16:28:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 16:28:16 +0100 (CET) Received: (qmail 26573 invoked by uid 0); 25 Nov 2001 14:55:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 25 Nov 2001 14:55:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPEtdO03260 for ; Sun, 25 Nov 2001 09:55:39 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 14:55:00 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPEt0N02985 for f-cpu-list; Sun, 25 Nov 2001 09:55:00 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPEsxo02982 for ; Sun, 25 Nov 2001 09:54:59 -0500 Received: by moria.seul.org (Postfix) id 75BE9146661; Sun, 25 Nov 2001 09:54:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 49B98146660 for ; Sun, 25 Nov 2001 09:54:59 -0500 (EST) Received: from ifrance.com (nas24-71.vlt.n.club-internet.fr [195.36.223.71]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2461616E6 for ; Sun, 25 Nov 2001 15:54:57 +0100 (CET) Message-ID: <3C015A4E.34F856CB@ifrance.com> Date: Sun, 25 Nov 2001 15:53:34 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Josh Fender a écrit : > > Hi YG, > You may not remember me but I'm one of the lurkers who occationally runs > your vhdl code through synthesis and place and route software. The code > you attached to your previous message runs through Synplify Pro with no > errors or warnings. Maybe a less useful, but more interesting, fact is > that when placed in a Xilinx Virtex grade 6 chip it runs at 85MHz. This > number is calculated based on driving the input/output signals > directly from/to pins on the FPGA, so on a real intergrated system the > timing would probably be closer to 100MHz or possibly even better. > > On a slightly different note, I could test the unit in a real FPGA if > you have any test vectors. > It will be nice to note the multiplier unit too. Because technologie or so much different : it's difficulte to make comparaison ! (on 0.18 µ, the mul unit run almost at 500 Mhz, i don't remember exactly the number) nicO > - Josh > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 25 16:17:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16867e-00054e-00 for ; Sun, 25 Nov 2001 21:43:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 21:43:30 +0100 (CET) Received: (qmail 9900 invoked by uid 0); 25 Nov 2001 15:15:33 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx035-rz3) with SMTP; 25 Nov 2001 15:15:33 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPFFWC03756 for ; Sun, 25 Nov 2001 10:15:32 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 15:15:12 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPFFCH03490 for f-cpu-list; Sun, 25 Nov 2001 10:15:12 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPFFBo03487 for ; Sun, 25 Nov 2001 10:15:11 -0500 Received: by moria.seul.org (Postfix) id 8033B146661; Sun, 25 Nov 2001 10:15:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4B4D7146660 for ; Sun, 25 Nov 2001 10:15:11 -0500 (EST) Received: from f-cpu.org (nas15-187.kdl.n.club-internet.fr [213.44.9.187]) by relay-3v.club-internet.fr (Postfix) with ESMTP id E9E0B16ED for ; Sun, 25 Nov 2001 16:15:08 +0100 (CET) Message-ID: <3C010B88.D2AA8AD@f-cpu.org> Date: Sun, 25 Nov 2001 16:17:28 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Turing Award rocks ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, as if i had only that to do, i just browsed through a pile of files i downloaded from the Net in september. I clicked here and there, until i found a document named cmicropipelines.pdf, a 19-pages paper written in 1989 by Ivan E. Sutherland (Turing Award) for the ACM (Communications of the ACM, Volume 32, number 6, pages 720-738). It describes a more or less interesting scheme for a sort of asynchronous logic (what he refers to "micropipelines"). Then at the bottom of page 727, i found the picture that i put at http://f-cpu.seul.org/new/FF.gif. I did not react to this the first time i saw this a few months ago. However now it is clear : Connect the Capture and Pass signals together (eventually inverting one signal, or swapping the MUX inputs), and you have a wonderful 2-edges flip-flop ! It stores a new value during every clock edge and still outputs the last values. This is perfect for a semi-custom F-CPU because the pipeline stages are already so thin that FF and clocks cause most of the problems. Clock skew is still not solved, but it's not the goal : if we can latch one value per clock edge, we don't need 2 edges for one "cycle", thus halving the power consumption :-))) on top of that, it looks like a good surface/speed compromise, compared to what i have seen with Alliance. This kind of cell requires three 2-input inverting mux gates, optionally with two additional inverters for the second version. This is close to optimal. Stop me before i design the cell's layout (and probably reinvent the wheel) ! :-P Important note : whether we use this kind of cells or not is completely independent from the F-CPU core. Whether a clock cycle contains one or two edges does not change anything from the logic side or even the scheduling. Sutherland describes a complete framework for asynchonous logic that solves nicolas' and other's questions about "contentions and bubbles in a long pipelined unit", i recommend nicO to read this paper (i put it at seul.org). This is not going to be used for FC0 but it is not yet possible to know what FC1 would look like. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Nov 25 17:31:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16867h-00054e-00 for ; Sun, 25 Nov 2001 21:43:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 21:43:33 +0100 (CET) Received: (qmail 1279 invoked by uid 0); 25 Nov 2001 16:29:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 25 Nov 2001 16:29:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPGTwM04743 for ; Sun, 25 Nov 2001 11:29:58 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 16:29:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPGTWe04475 for f-cpu-list; Sun, 25 Nov 2001 11:29:32 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPGTVo04472 for ; Sun, 25 Nov 2001 11:29:31 -0500 Received: by moria.seul.org (Postfix) id E0F67146663; Sun, 25 Nov 2001 11:29:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id BBBC6146661 for ; Sun, 25 Nov 2001 11:29:30 -0500 (EST) Received: from f-cpu.org (nas20-187.kdl.n.club-internet.fr [213.44.18.187]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 3848316F5 for ; Sun, 25 Nov 2001 17:29:25 +0100 (CET) Message-ID: <3C011CEF.F911E376@f-cpu.org> Date: Sun, 25 Nov 2001 17:31:43 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Turing Award rocks ! References: <3C010B88.D2AA8AD@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ps: i was not able to transfer Sutherland's paper on seul.org for some obscure reasons. however i did a wget from there to cs.utah.edu where it seems that the file is the same (but slightly smaller). http://www.cs.utah.edu/classes/cs5830/ has a lot of very interesting stuff, i'm currently loading AMI's .5u manual :-) read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Nov 25 14:40:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16867h-00054e-01 for ; Sun, 25 Nov 2001 21:43:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 21:43:33 +0100 (CET) Received: (qmail 31035 invoked by uid 0); 25 Nov 2001 17:17:58 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 25 Nov 2001 17:17:58 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPHHvo05789 for ; Sun, 25 Nov 2001 12:17:57 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 17:17:22 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPHHLC05521 for f-cpu-list; Sun, 25 Nov 2001 12:17:21 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPHHJo05518 for ; Sun, 25 Nov 2001 12:17:19 -0500 Received: by moria.seul.org (Postfix) id B3B78146663; Sun, 25 Nov 2001 12:17:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a030.home.uni-hannover.de [130.75.232.30]) by moria.seul.org (Postfix) with ESMTP id E5C77146660 for ; Sun, 25 Nov 2001 12:17:17 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00805; Sun, 25 Nov 2001 14:40:41 +0100 Message-ID: <20011125144041.33029@thrai.stud.uni-hannover.de> Date: Sun, 25 Nov 2001 14:40:41 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: <3C005BB0.F7F04150@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C005BB0.F7F04150@f-cpu.org>; from Yann Guidon on Sun, Nov 25, 2001 at 03:47:12AM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Nov 25, 2001 at 03:47:12AM +0100, Yann Guidon wrote: [...] > > Maybe a less useful, but more interesting, fact is > > that when placed in a Xilinx Virtex grade 6 chip it runs at 85MHz. > the little problem is that i don't know whether it's fas or slow. I guess 85 MHz in an FPGA is not bad (depends on the FPGA type, of course). I'd like to see the numbers for the add, mul and shl units, too (for the same target, as far as possible -- the multiplier probably won't fit, but the other EUs should). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Nov 25 18:22:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16867i-00054e-01 for ; Sun, 25 Nov 2001 21:43:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 21:43:34 +0100 (CET) Received: (qmail 1629 invoked by uid 0); 25 Nov 2001 18:10:43 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx033-rz3) with SMTP; 25 Nov 2001 18:10:43 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPIAge06848 for ; Sun, 25 Nov 2001 13:10:42 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 18:10:03 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPIA3X06584 for f-cpu-list; Sun, 25 Nov 2001 13:10:03 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPIA0o06580 for ; Sun, 25 Nov 2001 13:10:00 -0500 Received: by moria.seul.org (Postfix) id 9D6FB146661; Sun, 25 Nov 2001 13:10:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 055EC146660 for ; Sun, 25 Nov 2001 13:10:00 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-197.jetnet.ab.ca [207.34.60.197]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA26626 for ; Sun, 25 Nov 2001 11:09:49 -0700 (MST) Message-ID: <3C0128E9.F2D3E1A@jetnet.ab.ca> Date: Sun, 25 Nov 2001 10:22:49 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: <3C005BB0.F7F04150@f-cpu.org> <20011125144041.33029@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > I guess 85 MHz in an FPGA is not bad (depends on the FPGA type, of > course). I'd like to see the numbers for the add, mul and shl units, > too (for the same target, as far as possible -- the multiplier probably > won't fit, but the other EUs should). You really will not know the the clock speed until the final product is routed. I have seen with my designs clock speed endup 1/3 from what the modules run at when all routed together. -- Ben Franchuk --- Pre-historic Cpu's -- www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Fri Nov 23 19:36:29 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1689Mo-0007Uh-00 for ; Mon, 26 Nov 2001 01:11:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 01:11:22 +0100 (CET) Received: (qmail 15222 invoked by uid 0); 25 Nov 2001 20:42:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx034-rz3) with SMTP; 25 Nov 2001 20:42:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPKgFj09151 for ; Sun, 25 Nov 2001 15:42:15 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 20:41:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPKfVZ08883 for f-cpu-list; Sun, 25 Nov 2001 15:41:31 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPKfSo08880 for ; Sun, 25 Nov 2001 15:41:28 -0500 Received: by moria.seul.org (Postfix) id 400A0146661; Sun, 25 Nov 2001 15:41:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id AB8A0146660 for ; Sun, 25 Nov 2001 15:41:27 -0500 (EST) Received: from art1.none.de (f-dialin-1297.addcom.de [62.96.144.97]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id fAPKfVW29422 for ; Sun, 25 Nov 2001 21:41:32 +0100 X-Authentication-Warning: host-2.server.itns.de: Host f-dialin-1297.addcom.de [62.96.144.97] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.32 #1 (Debian)) id 167LCb-0001eo-00 for ; Fri, 23 Nov 2001 19:37:29 +0100 Date: Fri, 23 Nov 2001 19:36:29 +0100 (CET) From: Andreas Romeyke To: fm Subject: Re: [f-cpu] (Code Review) Call for general/public code review In-Reply-To: <3BFE2BB1.888196F0@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello YG, On Fri, 23 Nov 2001, Yann Guidon wrote: > the idea is : everyday, a new file from the F-CPU VHDL code source tree > is posted and discussed the following days on the list. > The poster will be the one who wrote the file or modified it last. IMHO the idea is wrong, because its the wrong way. We have a CVS-repository, but if nobody commits his changes and files, the development will be stalled. I have not enough time to check out all files coming with mailinglist. I don't like a patch-queue-system as Linus Torvalds has. The better idea is commit files into CVS, and commit mails additional for discussion... bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE7/pcwClxplZklbgERApH9AJ9Tj9t+C72Fz+vXP0sWz6T9UbHntQCglEDz ASXxIU4BIrmHDAl7MmrcuE8= =Vr3w -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Nov 25 22:20:05 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1689Mp-0007Uh-00 for ; Mon, 26 Nov 2001 01:11:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 01:11:23 +0100 (CET) Received: (qmail 28578 invoked by uid 0); 25 Nov 2001 22:07:51 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx031-rz3) with SMTP; 25 Nov 2001 22:07:51 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPM7oQ10988 for ; Sun, 25 Nov 2001 17:07:51 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 22:07:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPM79n10715 for f-cpu-list; Sun, 25 Nov 2001 17:07:09 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPM76o10710 for ; Sun, 25 Nov 2001 17:07:06 -0500 Received: by moria.seul.org (Postfix) id 7CA30146661; Sun, 25 Nov 2001 17:07:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id C79ED146660 for ; Sun, 25 Nov 2001 17:07:05 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-208.jetnet.ab.ca [207.34.60.208]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA06204 for ; Sun, 25 Nov 2001 15:07:04 -0700 (MST) Message-ID: <3C016085.F51F5D3F@jetnet.ab.ca> Date: Sun, 25 Nov 2001 14:20:05 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Performance References: <001101c175ec$b8dce320$de0bd7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N richard hartny wrote: > Very true Ben. It isn't that bad with Quicklogic QL6600-7 > because the device has Global Clock Networks and I use them all with the ERIN32. > I could not use them (quicklogic) since the new ones that have the speed don't have the macro-cells needed in 84 PLCC? package. With a onboard uart I need about 500 macro cells. Mind you once the design is stable I may look at Quicklogic again. Do you have a link for 'ERIN32'? -- Ben Franchuk --- Pre-historic Cpu's -- www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sun Nov 25 21:06:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16867l-00054e-00 for ; Sun, 25 Nov 2001 21:43:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 25 Nov 2001 21:43:37 +0100 (CET) Received: (qmail 23751 invoked by uid 0); 25 Nov 2001 20:08:22 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 25 Nov 2001 20:08:22 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAPK8LZ08386 for ; Sun, 25 Nov 2001 15:08:21 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 25 Nov 2001 20:07:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAPK7Ee08095 for f-cpu-list; Sun, 25 Nov 2001 15:07:14 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAPK7Co08092 for ; Sun, 25 Nov 2001 15:07:12 -0500 Received: by moria.seul.org (Postfix) id 3F1CE146661; Sun, 25 Nov 2001 15:07:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf24bis.bellsouth.net (mail124.mail.bellsouth.net [205.152.58.84]) by moria.seul.org (Postfix) with ESMTP id F213D146660 for ; Sun, 25 Nov 2001 15:07:11 -0500 (EST) Received: from computer ([209.215.11.222]) by imf24bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011125201723.LAHB23983.imf24bis.bellsouth.net@computer>; Sun, 25 Nov 2001 15:17:23 -0500 Message-ID: <001101c175ec$b8dce320$de0bd7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Performance Date: Sun, 25 Nov 2001 14:06:50 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C175BA.6D609EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: RO X-Status: O This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C175BA.6D609EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Very true Ben. It isn't that bad with Quicklogic QL6600-7 because the device has Global Clock Networks and I use them all with the = ERIN32. Move on Dick Hartney ------=_NextPart_000_000E_01C175BA.6D609EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject:
Very true Ben.  It isn't that bad = with=20 Quicklogic QL6600-7
because the device has Global Clock = Networks and I=20 use them all with the ERIN32.
 
Move on
Dick Hartney
------=_NextPart_000_000E_01C175BA.6D609EA0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 26 01:32:34 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168RvJ-0000HB-01 for ; Mon, 26 Nov 2001 21:00:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:13 +0100 (CET) Received: (qmail 14741 invoked by uid 0); 26 Nov 2001 00:30:46 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx015-rz3) with SMTP; 26 Nov 2001 00:30:46 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQ0UjL13146 for ; Sun, 25 Nov 2001 19:30:45 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 00:30:17 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQ0UHA12882 for f-cpu-list; Sun, 25 Nov 2001 19:30:17 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQ0UGo12879 for ; Sun, 25 Nov 2001 19:30:16 -0500 Received: by moria.seul.org (Postfix) id 257B6146661; Sun, 25 Nov 2001 19:30:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 00A60146660 for ; Sun, 25 Nov 2001 19:30:15 -0500 (EST) Received: from f-cpu.org (nas20-45.kdl.n.club-internet.fr [213.44.18.45]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7BB3816CB for ; Mon, 26 Nov 2001 01:30:12 +0100 (CET) Message-ID: <3C018DA2.F256D3DD@f-cpu.org> Date: Mon, 26 Nov 2001 01:32:34 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] 2-edges FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, so i started to analyse the layout of a 2-edge FF cell and it requires 2 metal levels and 28 transistors : this is roughly equivalent to the master-slave FF included with Alliance. Studying at LIP6 is not what i expected but it's worth it anyway :-) I have found a few optimisation tricks that i'm not ashamed of :-) more on this later. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Nov 26 13:55:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168RvY-0000HB-00 for ; Mon, 26 Nov 2001 21:00:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:28 +0100 (CET) Received: (qmail 29860 invoked by uid 0); 26 Nov 2001 12:56:37 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 26 Nov 2001 12:56:37 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQCuam23703 for ; Mon, 26 Nov 2001 07:56:36 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 12:55:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQCta723435 for f-cpu-list; Mon, 26 Nov 2001 07:55:36 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQCtXo23428 for ; Mon, 26 Nov 2001 07:55:33 -0500 Received: by moria.seul.org (Postfix) id 099A5146661; Mon, 26 Nov 2001 07:55:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf26bis.bellsouth.net (mail026.mail.bellsouth.net [205.152.58.66]) by moria.seul.org (Postfix) with ESMTP id C8FE6146660 for ; Mon, 26 Nov 2001 07:55:32 -0500 (EST) Received: from computer ([208.60.245.68]) by imf26bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20011126125622.BGZW29237.imf26bis.bellsouth.net@computer>; Mon, 26 Nov 2001 07:56:22 -0500 Message-ID: <000a01c17679$9780b700$44f53cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Link for ERIN32 ?? Date: Mon, 26 Nov 2001 06:55:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C17647.4C047280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C17647.4C047280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben: I'm not certain what you mean by LINK?? I do have a web site at egandaonline.com which is just a condensed = discription of what I intend to accomplish. I am currently doing a 5 year cost spreadsheet to submit with a Venture = Capital Request. Only have three designs to complete - Boot Load, CRT = Multiplexer, and a PCI interface to a Printer Controller, and Hard Drive = Disk of unknown vintage. Any questions - fire away. Regards Dick Hartney ------=_NextPart_000_0007_01C17647.4C047280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ben:  I'm not certain what you = mean by=20 LINK??
 
I do have a web site at = egandaonline.com which is=20 just a condensed discription of what I intend to = accomplish.
 
I am currently doing a 5 year cost = spreadsheet to=20 submit with a Venture Capital Request.  Only have three designs to = complete=20 - Boot Load, CRT Multiplexer, and a PCI interface to a Printer = Controller, and=20 Hard Drive Disk of unknown vintage.  Any questions - fire=20 away.
 
Regards
Dick Hartney
------=_NextPart_000_0007_01C17647.4C047280-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Mon Nov 26 18:22:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168Rvg-0000HB-00 for ; Mon, 26 Nov 2001 21:00:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:36 +0100 (CET) Received: (qmail 7187 invoked by uid 0); 26 Nov 2001 17:22:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Nov 2001 17:22:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQHMTc29801 for ; Mon, 26 Nov 2001 12:22:29 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 17:22:09 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQHM9v29533 for f-cpu-list; Mon, 26 Nov 2001 12:22:09 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQHM8o29530 for ; Mon, 26 Nov 2001 12:22:08 -0500 Received: by moria.seul.org (Postfix) id 2F1D7146661; Mon, 26 Nov 2001 12:22:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.seul.org (Postfix) with ESMTP id E2422146660 for ; Mon, 26 Nov 2001 12:22:07 -0500 (EST) Received: from skule.ecf (fender@skule.ecf [128.100.8.6]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id MAA23828 for ; Mon, 26 Nov 2001 12:22:07 -0500 Received: from localhost (fender@localhost) by skule.ecf (SGI-8.9.3/8.9.3) with SMTP id MAA15605 for ; Mon, 26 Nov 2001 12:22:06 -0500 (EST) X-Authentication-Warning: skule.ecf: fender owned process doing -bs Date: Mon, 26 Nov 2001 12:22:06 -0500 (EST) From: Josh Fender X-Sender: fender@skule.ecf To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version In-Reply-To: <20011125144041.33029@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 25 Nov 2001, Michael Riepe wrote: > On Sun, Nov 25, 2001 at 03:47:12AM +0100, Yann Guidon wrote: > [...] > > > Maybe a less useful, but more interesting, fact is > > > that when placed in a Xilinx Virtex grade 6 chip it runs at 85MHz. > > the little problem is that i don't know whether it's fas or slow. > > I guess 85 MHz in an FPGA is not bad (depends on the FPGA type, of > course). I'd like to see the numbers for the add, mul and shl units, > too (for the same target, as far as possible -- the multiplier probably > won't fit, but the other EUs should). If someone was to provide a working set of units, I could try them all out. I could try the multiplier unit aswell as the FPGAs I am using are relatively large (approximately 40000 Look up tables/ Flip Flops units). It might not fit but its always worth a try. I am curious about the target of the F-CPU. A lot of the design seems to be oriented towards FPGAs and their four input logic, yet the multiplier most certainly is not. So my question simply is: What is the current target platform for the first F-CPU? Is it an FPGA or a custom chip. - Josh ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Nov 26 17:33:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168Rvg-0000HB-01 for ; Mon, 26 Nov 2001 21:00:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:36 +0100 (CET) Received: (qmail 17230 invoked by uid 0); 26 Nov 2001 16:47:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx020-rz3) with SMTP; 26 Nov 2001 16:47:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQGlSk28736 for ; Mon, 26 Nov 2001 11:47:28 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 16:46:38 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQGkcp28419 for f-cpu-list; Mon, 26 Nov 2001 11:46:38 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQGkYo28416 for ; Mon, 26 Nov 2001 11:46:34 -0500 Received: by moria.seul.org (Postfix) id DB949146660; Mon, 26 Nov 2001 11:46:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 3B4DE146661 for ; Mon, 26 Nov 2001 11:46:33 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA06733 for ; Mon, 26 Nov 2001 09:46:31 -0700 (MST) Message-ID: <3C026ED6.D7142988@jetnet.ab.ca> Date: Mon, 26 Nov 2001 09:33:26 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Link for ERIN32 ?? References: <000a01c17679$9780b700$44f53cd0@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N richard hartny wrote: > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable Thanks for the basic information. This was just the information I was looking for. -- Ben Franchuk --- Pre-historic Cpu's -- www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Nov 27 01:15:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168Rvk-0000HB-00 for ; Mon, 26 Nov 2001 21:00:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:40 +0100 (CET) Received: (qmail 21592 invoked by uid 0); 26 Nov 2001 18:17:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 26 Nov 2001 18:17:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQIHTR30577 for ; Mon, 26 Nov 2001 13:17:29 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 18:17:02 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQIH1230308 for f-cpu-list; Mon, 26 Nov 2001 13:17:01 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQIH0o30305 for ; Mon, 26 Nov 2001 13:17:00 -0500 Received: by moria.seul.org (Postfix) id 03BE1146661; Mon, 26 Nov 2001 13:17:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CBC95146660 for ; Mon, 26 Nov 2001 13:16:59 -0500 (EST) Received: from ifrance.com (nas5-4.vlt.n.club-internet.fr [194.158.107.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D327A170A for ; Mon, 26 Nov 2001 19:16:54 +0100 (CET) Message-ID: <3C02DB2A.1C7EE8@ifrance.com> Date: Mon, 26 Nov 2001 19:15:38 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: <3C005BB0.F7F04150@f-cpu.org> <20011125144041.33029@thrai.stud.uni-hannover.de> <3C0128E9.F2D3E1A@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > Michael Riepe wrote: > > > I guess 85 MHz in an FPGA is not bad (depends on the FPGA type, of > > course). I'd like to see the numbers for the add, mul and shl units, > > too (for the same target, as far as possible -- the multiplier probably > > won't fit, but the other EUs should). > > You really will not know the the clock speed until the final product > is routed. I have seen with my designs clock speed endup 1/3 from > what the modules run at when all routed together. Yep, but it's almost always 1/3 so it's always easy to compare. nicO > -- > Ben Franchuk --- Pre-historic Cpu's -- > www.jetnet.ab.ca/users/bfranchuk/index.html > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Nov 27 01:20:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168Rvl-0000HB-00 for ; Mon, 26 Nov 2001 21:00:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:41 +0100 (CET) Received: (qmail 19024 invoked by uid 0); 26 Nov 2001 18:22:32 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx006-rz3) with SMTP; 26 Nov 2001 18:22:32 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQIMVB30946 for ; Mon, 26 Nov 2001 13:22:31 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 18:22:08 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQIM8T30672 for f-cpu-list; Mon, 26 Nov 2001 13:22:08 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQIM7o30667 for ; Mon, 26 Nov 2001 13:22:07 -0500 Received: by moria.seul.org (Postfix) id 086A9146661; Mon, 26 Nov 2001 13:22:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E4364146660 for ; Mon, 26 Nov 2001 13:22:06 -0500 (EST) Received: from ifrance.com (nas5-4.vlt.n.club-internet.fr [194.158.107.4]) by relay-2v.club-internet.fr (Postfix) with ESMTP id D7E181998 for ; Mon, 26 Nov 2001 19:22:04 +0100 (CET) Message-ID: <3C02DC60.F632CF50@ifrance.com> Date: Mon, 26 Nov 2001 19:20:48 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] [Fwd: Research about FSM file format] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Somebody could help ? -------- Original Message -------- From: "Christian Birchler" Subject: Research about FSM file format To: nicolas.boulay@ifrance.com I just found your name on http://www.seul.org/archives/f-cpu/f-cpu/Jun-2001/msg00042.html We are currentliy resarching about the FSM file format. The format which is used by GeoMedia a product from Intergraph saves Symbol information. Now we are seeking after information about these format. If you know something about these format I would be very glad if I could ask you some questions. Thank you, Regards Christian _ _ ___ ___ Christian Birchler; | || / __| _ \ HSR Hochschule Rapperswil; Oberseestrasse 10; | __ \__ \ / CH-8640 Rapperswil; Tel: +41 55 222 41 11; |_||_|___/_|_\ EMAIL: cbirchle@hsr.ch; WWW: www.hsr.ch ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Mon Nov 26 18:10:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168Rvf-0000HB-00 for ; Mon, 26 Nov 2001 21:00:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 26 Nov 2001 21:00:35 +0100 (CET) Received: (qmail 32111 invoked by uid 0); 26 Nov 2001 17:11:08 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 26 Nov 2001 17:11:08 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQHB7M29379 for ; Mon, 26 Nov 2001 12:11:07 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 17:10:47 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQHAlQ29110 for f-cpu-list; Mon, 26 Nov 2001 12:10:47 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQHAjo29107 for ; Mon, 26 Nov 2001 12:10:45 -0500 Received: by moria.seul.org (Postfix) id 675C5146661; Mon, 26 Nov 2001 12:10:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.seul.org (Postfix) with ESMTP id 217E7146660 for ; Mon, 26 Nov 2001 12:10:45 -0500 (EST) Received: from skule.ecf (fender@skule.ecf [128.100.8.6]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id MAA22870 for ; Mon, 26 Nov 2001 12:10:44 -0500 Received: from localhost (fender@localhost) by skule.ecf (SGI-8.9.3/8.9.3) with SMTP id MAA93633 for ; Mon, 26 Nov 2001 12:10:44 -0500 (EST) X-Authentication-Warning: skule.ecf: fender owned process doing -bs Date: Mon, 26 Nov 2001 12:10:44 -0500 (EST) From: Josh Fender X-Sender: fender@skule.ecf To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version In-Reply-To: <3C005BB0.F7F04150@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 25 Nov 2001, Yann Guidon wrote: > Josh Fender wrote: > > On a slightly different note, I could test the unit in a real FPGA if > > you have any test vectors. > > i am about to do it, it should be ready within a few days. > however, i do test vectors for VHDL testbenches, not FPGA tests : > will you be able to adapt them ? Sure it shouldn't be to hard. The test system I use allows automatic generation of circuit ports that can be written to and read from the attached sun. So long as the vectors are easily read from a C program then it will be no problem. - Josh ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Nov 27 00:06:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168YlA-0005EM-00 for ; Tue, 27 Nov 2001 04:18:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 27 Nov 2001 04:18:12 +0100 (CET) Received: (qmail 12248 invoked by uid 0); 26 Nov 2001 23:04:39 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx012-rz3) with SMTP; 26 Nov 2001 23:04:39 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQN4bk10805 for ; Mon, 26 Nov 2001 18:04:37 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 23:03:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQN3r410185 for f-cpu-list; Mon, 26 Nov 2001 18:03:53 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQN3po10175 for ; Mon, 26 Nov 2001 18:03:51 -0500 Received: by moria.seul.org (Postfix) id B155F146661; Mon, 26 Nov 2001 18:03:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 98819146660 for ; Mon, 26 Nov 2001 18:03:51 -0500 (EST) Received: from f-cpu.org (nas20-1.kdl.n.club-internet.fr [213.44.18.1]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 4A8B916DE for ; Tue, 27 Nov 2001 00:03:49 +0100 (CET) Message-ID: <3C02CAE3.8B86C97F@f-cpu.org> Date: Tue, 27 Nov 2001 00:06:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Josh Fender wrote: > On Sun, 25 Nov 2001, Yann Guidon wrote: > > Josh Fender wrote: > > > On a slightly different note, I could test the unit in a real FPGA if > > > you have any test vectors. > > > > i am about to do it, it should be ready within a few days. > > however, i do test vectors for VHDL testbenches, not FPGA tests : > > will you be able to adapt them ? > > Sure it shouldn't be to hard. The test system I use allows automatic > generation of circuit ports that can be written to and read from the > attached sun. So long as the vectors are easily read from a C program > then it will be no problem. ooops, i already forgot that point ;-) i was so excited about the 2-edge FF that the ROP2 unit got out of my mind. Hmm give me a few days again :-) > - Josh WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Nov 27 00:06:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168YlB-0005EM-00 for ; Tue, 27 Nov 2001 04:18:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 27 Nov 2001 04:18:13 +0100 (CET) Received: (qmail 8109 invoked by uid 0); 26 Nov 2001 23:04:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 26 Nov 2001 23:04:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQN4aW10800 for ; Mon, 26 Nov 2001 18:04:37 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 23:03:49 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQN3nm10155 for f-cpu-list; Mon, 26 Nov 2001 18:03:49 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQN3lo10152 for ; Mon, 26 Nov 2001 18:03:47 -0500 Received: by moria.seul.org (Postfix) id 2F20D146661; Mon, 26 Nov 2001 18:03:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 16CF1146660 for ; Mon, 26 Nov 2001 18:03:47 -0500 (EST) Received: from f-cpu.org (nas20-1.kdl.n.club-internet.fr [213.44.18.1]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 8B76A1710 for ; Tue, 27 Nov 2001 00:03:44 +0100 (CET) Message-ID: <3C02CADF.61F28572@f-cpu.org> Date: Tue, 27 Nov 2001 00:06:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Josh Fender wrote: > On Sun, 25 Nov 2001, Michael Riepe wrote: > > On Sun, Nov 25, 2001 at 03:47:12AM +0100, Yann Guidon wrote: > > [...] > > I guess 85 MHz in an FPGA is not bad (depends on the FPGA type, of > > course). I'd like to see the numbers for the add, mul and shl units, > > too (for the same target, as far as possible -- the multiplier probably > > won't fit, but the other EUs should). > If someone was to provide a working set of units, I could try them all > out. I could try the multiplier unit aswell as the FPGAs I am using are > relatively large (approximately 40000 Look up tables/ Flip Flops units). > It might not fit but its always worth a try. thank you ! > I am curious about the target of the F-CPU. A lot of the design seems > to be oriented towards FPGAs and their four input logic, yet the > multiplier most certainly is not. So my question simply is: What is the > current target platform for the first F-CPU? Is it an FPGA or a custom > chip. concerning the "target", it ranges from SRAM-based FPGA to semi-custom, depending on what tools are available. Of course if we wanted to compete with Intel, full-custom teams would have to work, but let's be realistic :-) but whatever step in any direction is apreciated. I hope it is not too fuzzy :-) > - Josh WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Nov 27 00:38:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168YlB-0005EM-01 for ; Tue, 27 Nov 2001 04:18:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 27 Nov 2001 04:18:13 +0100 (CET) Received: (qmail 6581 invoked by uid 0); 26 Nov 2001 23:38:35 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx033-rz3) with SMTP; 26 Nov 2001 23:38:35 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQNcYP14856 for ; Mon, 26 Nov 2001 18:38:34 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 23:38:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQNcEv14590 for f-cpu-list; Mon, 26 Nov 2001 18:38:14 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQNcDo14587 for ; Mon, 26 Nov 2001 18:38:13 -0500 Received: by moria.seul.org (Postfix) id 57B5D146661; Mon, 26 Nov 2001 18:38:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a245.home.uni-hannover.de [130.75.232.245]) by moria.seul.org (Postfix) with ESMTP id 72B38146660 for ; Mon, 26 Nov 2001 18:38:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA03040; Tue, 27 Nov 2001 00:38:16 +0100 Message-ID: <20011127003816.05471@thrai.stud.uni-hannover.de> Date: Tue, 27 Nov 2001 00:38:16 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version References: <20011125144041.33029@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Josh Fender on Mon, Nov 26, 2001 at 12:22:06PM -0500 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Nov 26, 2001 at 12:22:06PM -0500, Josh Fender wrote: [...] > If someone was to provide a working set of units, I could try them all > out. I could try the multiplier unit aswell as the FPGAs I am using are > relatively large (approximately 40000 Look up tables/ Flip Flops units). > It might not fit but its always worth a try. I just uploaded my latest versions of the ASU, IMU and SHL units to http://www.seul.org/~f-cpu/new/fcpu-mr-20011127.tar.gz -- feel free to grab the tarball and try them out. > I am curious about the target of the F-CPU. A lot of the design seems > to be oriented towards FPGAs and their four input logic, yet the > multiplier most certainly is not. So my question simply is: What is the > current target platform for the first F-CPU? Is it an FPGA or a custom > chip. AFAIR, we try to be as target-independent as possible. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Michael.Riepe@stud.uni-hannover.de Tue Nov 27 00:53:38 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168YlC-0005EM-00 for ; Tue, 27 Nov 2001 04:18:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 27 Nov 2001 04:18:14 +0100 (CET) Received: (qmail 10212 invoked by uid 0); 26 Nov 2001 23:54:05 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx035-rz3) with SMTP; 26 Nov 2001 23:54:05 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAQNs5H16961 for ; Mon, 26 Nov 2001 18:54:05 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 26 Nov 2001 23:53:43 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAQNrgL16687 for f-cpu-list; Mon, 26 Nov 2001 18:53:43 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAQNrfo16684 for ; Mon, 26 Nov 2001 18:53:42 -0500 Received: by moria.seul.org (Postfix) id CE0A6146661; Mon, 26 Nov 2001 18:53:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from studserv.stud.uni-hannover.de (mx.stud.uni-hannover.de [130.75.176.3]) by moria.seul.org (Postfix) with ESMTP id 7F644146660 for ; Mon, 26 Nov 2001 18:53:41 -0500 (EST) Received: from studserv.stud.uni-hannover.de (michael@localhost [127.0.0.1]) by studserv.stud.uni-hannover.de (8.12.1/8.12.1/MX/check_local5.0) with ESMTP id fAQNrdkr012820 for ; Tue, 27 Nov 2001 00:53:39 +0100 (MET) X-Spam-Filter: check_local@studserv.stud.uni-hannover.de by digitalanswers.org Received: (from michael@localhost) by studserv.stud.uni-hannover.de (8.12.1/8.12.1/Submit) id fAQNrc5d012816 for f-cpu@seul.org; Tue, 27 Nov 2001 00:53:38 +0100 (MET) Date: Tue, 27 Nov 2001 00:53:38 +0100 (MET) From: Michael Riepe Message-Id: <200111262353.fAQNrc5d012816@studserv.stud.uni-hannover.de> To: f-cpu@seul.org Subject: Re: [f-cpu] whygee's Nth slaughtered ROP2 version Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Content-Type: Status: R X-Status: N > I just uploaded my latest versions of the ASU, IMU and SHL units to > http://www.seul.org/~f-cpu/new/fcpu-mr-20011127.tar.gz -- feel free to > grab the tarball and try them out. Minor correction: it's http://f-cpu.seul.org/new/fcpu-mr-20011127.tar.gz -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Nov 28 04:26:59 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 168zO6-0000Zp-01 for ; Wed, 28 Nov 2001 08:44:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 28 Nov 2001 08:44:10 +0100 (CET) Received: (qmail 9778 invoked by uid 0); 28 Nov 2001 03:25:30 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 28 Nov 2001 03:25:30 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fAS3PTZ14555 for ; Tue, 27 Nov 2001 22:25:29 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Wed, 28 Nov 2001 03:24:37 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fAS3OaH14262 for f-cpu-list; Tue, 27 Nov 2001 22:24:36 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fAS3OZo14259 for ; Tue, 27 Nov 2001 22:24:35 -0500 Received: by moria.seul.org (Postfix) id 9AB561467E9; Tue, 27 Nov 2001 22:24:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7E0D91467E8 for ; Tue, 27 Nov 2001 22:24:35 -0500 (EST) Received: from f-cpu.org (nas5-7.kdl.n.club-internet.fr [213.44.0.7]) by relay-3v.club-internet.fr (Postfix) with ESMTP id AFDFD169F for ; Wed, 28 Nov 2001 04:24:33 +0100 (CET) Message-ID: <3C045983.5C1FA9F1@f-cpu.org> Date: Wed, 28 Nov 2001 04:26:59 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] VCI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i got a first presentation lesson about VCI (Virtual Component Interconnect) this monday. It looks rather ok for a communication bus (onchip) for the F-CPU, in parallel with the SDRAM controllers. nicO proposed AMBA but i have no detail. I think there is certainly a AMBA wrapper for VCI. I will tell you more as soon as i can, i hope that i can trigger a discussion on that (old) subject in the meanwhile :-) so i can know what to do as soon as possible (trying to implement something or not, and how). WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Nov 30 00:26:04 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 169dAO-0003oz-00 for ; Fri, 30 Nov 2001 03:12:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 30 Nov 2001 03:12:40 +0100 (CET) Received: (qmail 28151 invoked by uid 0); 29 Nov 2001 23:25:38 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx029-rz3) with SMTP; 29 Nov 2001 23:25:38 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fATNPbg09310 for ; Thu, 29 Nov 2001 18:25:37 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Thu, 29 Nov 2001 23:23:42 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fATNNg409025 for f-cpu-list; Thu, 29 Nov 2001 18:23:42 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fATNNfo09022 for ; Thu, 29 Nov 2001 18:23:41 -0500 Received: by moria.seul.org (Postfix) id E56DC1467E9; Thu, 29 Nov 2001 18:23:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id CD4D91467E8 for ; Thu, 29 Nov 2001 18:23:40 -0500 (EST) Received: from f-cpu.org (nas5-64.kdl.n.club-internet.fr [213.44.0.64]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 4B4651896 for ; Fri, 30 Nov 2001 00:23:38 +0100 (CET) Message-ID: <3C06C40C.6F44A346@f-cpu.org> Date: Fri, 30 Nov 2001 00:26:04 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] panic : off-by-one in ROP2 :-/ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i was reading the code (again and againg) and it suddenly appeared that some of the ports have one unused bit (i forgot the "-1" in the vector range). The lesson is : it is not because you work continuously on a piece of code that it is flawless. i'm sending a newer version ASAP. i am currently working on the previous layer (rop2_xbar), before doing a new and simpler testbench. Also ongoing : a "component" that does a buffered signal tree. @+ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 1 06:56:23 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHip-0000Td-01 for ; Sat, 01 Dec 2001 22:30:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:30:55 +0100 (CET) Received: (qmail 19229 invoked by uid 0); 1 Dec 2001 05:56:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 1 Dec 2001 05:56:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB15u1t09784 for ; Sat, 1 Dec 2001 00:56:01 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 05:53:59 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB15rsN08909 for f-cpu-list; Sat, 1 Dec 2001 00:53:54 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB15rqo08893 for ; Sat, 1 Dec 2001 00:53:52 -0500 Received: by moria.seul.org (Postfix) id 9C0C11467E9; Sat, 1 Dec 2001 00:53:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 83C411467E8 for ; Sat, 1 Dec 2001 00:53:52 -0500 (EST) Received: from f-cpu.org (nas15-121.kdl.n.club-internet.fr [213.44.9.121]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E1E80168C for ; Sat, 1 Dec 2001 06:53:49 +0100 (CET) Message-ID: <3C087107.84F0CC3E@f-cpu.org> Date: Sat, 01 Dec 2001 06:56:23 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] yet another bag of bugs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, http://f-cpu.seul.org/new/ROP2-YG-2001201.tgz i have added a binary tree component and a simpler testbench. there are still some problems with Vanilla but they will be solved one day or another... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 1 17:00:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHir-0000Td-00 for ; Sat, 01 Dec 2001 22:30:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:30:57 +0100 (CET) Received: (qmail 27258 invoked by uid 0); 1 Dec 2001 10:02:29 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 1 Dec 2001 10:02:29 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB1A2S517307 for ; Sat, 1 Dec 2001 05:02:28 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 10:01:14 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB1A1Eh17037 for f-cpu-list; Sat, 1 Dec 2001 05:01:14 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB1A1Co17034 for ; Sat, 1 Dec 2001 05:01:12 -0500 Received: by moria.seul.org (Postfix) id AFBA71467E9; Sat, 1 Dec 2001 05:01:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 977771467E8 for ; Sat, 1 Dec 2001 05:01:12 -0500 (EST) Received: from ifrance.com (nas25-252.vlt.n.club-internet.fr [195.36.224.252]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9772C174E for ; Sat, 1 Dec 2001 11:01:09 +0100 (CET) Message-ID: <3C08FE91.43A1091D@ifrance.com> Date: Sat, 01 Dec 2001 11:00:17 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N In the futur could it be possible to put txt file and .tgz file on the site ? It is small sized file, so it's not a problem. I begin to have a too big collection of file in my /fcpu directory. And it's more usefull when you want to have a very quick look. nicO Yann Guidon a écrit : > > hi, > > http://f-cpu.seul.org/new/ROP2-YG-2001201.tgz > > i have added a binary tree component and a simpler > testbench. there are still some problems with Vanilla > but they will be solved one day or another... > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 1 20:15:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHiu-0000Td-01 for ; Sat, 01 Dec 2001 22:31:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:31:00 +0100 (CET) Received: (qmail 30637 invoked by uid 0); 1 Dec 2001 13:17:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 1 Dec 2001 13:17:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB1DHBb20444 for ; Sat, 1 Dec 2001 08:17:11 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 13:16:34 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB1DGYT20173 for f-cpu-list; Sat, 1 Dec 2001 08:16:34 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB1DGWo20170 for ; Sat, 1 Dec 2001 08:16:32 -0500 Received: by moria.seul.org (Postfix) id 95ACB1467E9; Sat, 1 Dec 2001 08:16:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 655061467E8 for ; Sat, 1 Dec 2001 08:16:32 -0500 (EST) Received: from ifrance.com (nas6-15.vlt.n.club-internet.fr [194.158.108.15]) by relay-2v.club-internet.fr (Postfix) with ESMTP id CFCF319C8 for ; Sat, 1 Dec 2001 14:16:27 +0100 (CET) Message-ID: <3C092C58.4458489@ifrance.com> Date: Sat, 01 Dec 2001 14:15:36 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I wrote a french article (good for prior art proof and money) about the fcpu. This work will be used for the 18C3 conference, too. (if they respond to my email !!!) So the fcpu feature : - 64 bits SIMD (extensible by power of 2) - 64 registers - 32 bits instuctions word - superpipeline - none superscalare (4 ways max in the future) - no OOO (no needs) - so no register renaming (no needs too) - no branch prediction (for the moment) - associative memory between reg name and memory content to speed up memory featch and load (but there is an hard trend how do we handel memory alias ?) - intentive use of cmove and cjump required - RISCy instruction inst R1, R2, R3 - 2 adressing mode : immediat and register only. - no register windows (handel the trap is an overkill, but maybe too increase the number of register in the future, or we will used 64 bit instructions word to access 65535 register ? why not ? There is enough room ! ;p) - The SRB to speed up register saving for trap handler, it could be used for loading or saving memory from packet of register (packet of 8). But it used mix of special register, and i have a problem where to put return adresse (there is non stack in the fcpu !), we put it in R0 ? - TLB very close to the processor but we use L0 cache to precheck the TLB before effectively used the data.-> so L1 cache are physicaly cached My question are : does i forget something ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 1 15:56:26 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHj3-0000Td-00 for ; Sat, 01 Dec 2001 22:31:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:31:09 +0100 (CET) Received: (qmail 28449 invoked by uid 0); 1 Dec 2001 14:55:06 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 1 Dec 2001 14:55:06 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB1Et6B23228 for ; Sat, 1 Dec 2001 09:55:06 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 14:54:01 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB1Es0l22688 for f-cpu-list; Sat, 1 Dec 2001 09:54:00 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB1Erto22684 for ; Sat, 1 Dec 2001 09:53:55 -0500 Received: by moria.seul.org (Postfix) id 7EA4C1467E9; Sat, 1 Dec 2001 09:53:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 57ACA1467E8 for ; Sat, 1 Dec 2001 09:53:55 -0500 (EST) Received: from f-cpu.org (nas6-45.kdl.n.club-internet.fr [213.44.1.45]) by relay-1v.club-internet.fr (Postfix) with ESMTP id B83AF16FD for ; Sat, 1 Dec 2001 15:53:52 +0100 (CET) Message-ID: <3C08EF9A.4503D3E6@f-cpu.org> Date: Sat, 01 Dec 2001 15:56:26 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > In the futur could it be possible to put txt file and .tgz file on the site ? i don't understand what you mean exactly. what site is it about ? i checked the URL and it seems to work. > It is small sized file, so it's not a problem. I begin to have a > too big collection of file in my /fcpu directory. me too :-) it's a complete mess. > And it's more usefull when you want to have a very quick look. so you mean, a kind of "index.html" with the description of the files ? if i'm right, we'll need a webmaster AND a PHP-based forum engine... I know a few people who can do PHP/dynamic HTML but they are all extremely busy : Lionel, Graham, ... Concerning the ROP2 files, they are still beta and i ask for peer review before putting it on CVS. i recently discovered some "bug" and i am not sure that i didn't add new ones... hehe. Btw, could you please point us to the newest FreeHDL stuff ? thanks again, > nicO > > Yann Guidon a écrit : > > > > hi, > > > > http://f-cpu.seul.org/new/ROP2-YG-2001201.tgz > > > > i have added a binary tree component and a simpler > > testbench. there are still some problems with Vanilla > > but they will be solved one day or another... > > > > WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 1 15:56:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHj4-0000Td-00 for ; Sat, 01 Dec 2001 22:31:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:31:10 +0100 (CET) Received: (qmail 9848 invoked by uid 0); 1 Dec 2001 14:55:13 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx026-rz3) with SMTP; 1 Dec 2001 14:55:13 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB1EtC923267 for ; Sat, 1 Dec 2001 09:55:12 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 14:54:10 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB1Es9K22726 for f-cpu-list; Sat, 1 Dec 2001 09:54:09 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB1Es5o22709 for ; Sat, 1 Dec 2001 09:54:05 -0500 Received: by moria.seul.org (Postfix) id C1C781467E9; Sat, 1 Dec 2001 09:54:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id A8D201467E8 for ; Sat, 1 Dec 2001 09:54:04 -0500 (EST) Received: from f-cpu.org (nas6-45.kdl.n.club-internet.fr [213.44.1.45]) by relay-4v.club-internet.fr (Postfix) with ESMTP id D23B91720 for ; Sat, 1 Dec 2001 15:54:01 +0100 (CET) Message-ID: <3C08EFA3.5A9535E5@f-cpu.org> Date: Sat, 01 Dec 2001 15:56:35 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C092C58.4458489@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > I wrote a french article (good for prior art proof and money) about the fcpu. yummmy ! i'm eager to read it :-) but i hope that it is not written in english. if it is, then let me correct your grammar, at least :-) concernant l'antériorité, j'ai qqs enveloppes Soleau au cas où... > This work will be used for the 18C3 conference, too. (if they respond to my email !!!) > > So the fcpu feature : > - 64 bits SIMD (extensible by power of 2) > - 64 registers > - 32 bits instuctions word > - superpipeline > - none superscalare (4 ways max in the future) are we speaking about the "FC0" or "F-CPU family" ? do not forget to make a clear distinction between architecture and implementation. > - no OOO (no needs) > - so no register renaming (no needs too) > - no branch prediction (for the moment) <<-- no need. that's for FC0. > - associative memory between reg name and memory content to speed up > memory fetch and load (but there is an hard trend how do we handel > memory alias ?) --> memory aliases are coherent but the current implementation of FC0 makes a penalty of several cycles when 2 or more registers access the same 32-byte chunck. There is a way to solve that but it's heavier (at first, i had another idea then what is done now, but it is more "expensive"). > - intentive use of cmove and cjump required we are modern or we are not :-) > - RISCy instruction inst R1, R2, R3 you can reuse the EPF slides for this part. > - 2 adressing mode : immediat and register only. ??? immediate ? > - no register windows (handel the trap is an overkill, but maybe too > increase the number of register in the future, or we will used 64 bit > instructions word to access 65535 register ? why not ? There is enough > room ! ;p) can you image the size of the physical register bank ? however you forget about the other alternative we discussed : when memory is mapped to registers. > - The SRB to speed up register saving for trap handler, it could be used > for loading or saving memory from packet of register (packet of 8). oh i remember why it is 8 : each cache line can contain 4*64 bit registers, and it works with a "double-buffered" strategy, so there is a "sliding window" of 8 registers that can be saved at a time. > But it used mix of special register, and i have a problem where to put > return adresse (there is non stack in the fcpu !), we put it in R0 ? i should dust off the documents where we discuss the format of the CMB... don't worry too much anyway : your "PC" is stored to memory, at a location pointed to by the current CMB pointer, plus the offset that corresponds to the PC (i don't remember which). > - TLB very close to the processor but we use L0 cache to precheck the > TLB before effectively used the data.-> so L1 cache are physicaly cached > > My question are : does i forget something ? the problem is : when you start to scratch the surface, it never ends. i'm trapped here for a long time already and i don't know when i'll be released ;-) thank you, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Dec 1 16:22:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AHj6-0000Td-00 for ; Sat, 01 Dec 2001 22:31:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 01 Dec 2001 22:31:12 +0100 (CET) Received: (qmail 28985 invoked by uid 0); 1 Dec 2001 15:23:01 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx022-rz3) with SMTP; 1 Dec 2001 15:23:01 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB1FN0t23959 for ; Sat, 1 Dec 2001 10:23:00 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sat, 1 Dec 2001 15:22:24 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB1FMO323690 for f-cpu-list; Sat, 1 Dec 2001 10:22:24 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB1FMMo23687 for ; Sat, 1 Dec 2001 10:22:22 -0500 Received: by moria.seul.org (Postfix) id 937E01467EB; Sat, 1 Dec 2001 10:22:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id B9ADD1467E8 for ; Sat, 1 Dec 2001 10:22:17 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-2.free.fr (Postfix) with ESMTP id D8C0E5FB33 for ; Sat, 1 Dec 2001 16:22:16 +0100 (CET) Received: from imp1-1.free.fr (www-data@localhost [127.0.0.1]) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) with ESMTP id fB1FMGI5013283 for ; Sat, 1 Dec 2001 16:22:16 +0100 Received: (from www-data@localhost) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) id fB1FMGrp013282 for f-cpu@seul.org; Sat, 1 Dec 2001 16:22:16 +0100 To: f-cpu@seul.org Subject: [f-cpu] DivMod unit Message-ID: <1007220136.3c08f5a845efd@imp.free.fr> Date: Sat, 01 Dec 2001 16:22:16 +0100 (MET) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N So as Yann say last week, i was writing a divide/modulo unit for the F-CPU. I concentrate me on the creation of a component that can do all size of division. The principe of it is easy : For i form WIDTH-1 to 0 TmpB := B << i TmpResult := substraction(A, TmpB); if carry(TmpResult) = true then (test negativ result) Yl(i) := 0; else Yl(i) := 1; A := TmpResult; endif next i; Yh := A; So you have, in the same pass : Yl := A / B; Yh := A % B; As you can see all this unit need is a really good substraction function. The one that I want to write will normally work for all size of data (if it's a power of 4). The problem is that it doesn't work actually for a other size than 8 (I have some porblem with index, it will be solved next week). I think, that i will probably rewrite my substraction function. Because all the perfomance of this unit depend on it. I read a lot about the way to jump over 0, do SRT divide, and I think that for F-CPU this type of algorithm are perhaps not a good idea. Because if some case are accelerated a lot of others are really slow down. And this type of algorithm are not previsible, and the average speed of this unit is slower than this unit. It's why i think it's not a good solution to use them. Of course this component is not pipelined. And i am sure that we divide sometimes by something that take 64/32/16 bits, so only in really few case we need to have a pipelined unit (And in this case they will perhaps write a new div unit). But for 8bits it's not really the same problem, we use them in all conversion from changing base, in crypto and in some 2d graphical filter. In this case, that only represent a really few part of program, we will have better result, if we have a pipelined 8bits unit i think. So the question is : "Did we want to accelerate this application ?" Finally were division are needed, it's in game. But actually all this game (OpenGl and Direct3D games) use the FPU for all their number. So if we wan't a good software implementation of OpenGl, we will need a good FPU (i mean pipelined). And that's perhaps an other discussion ;-) A+ Cedric PS: I will finalise the divide unit during the next week. So if you have some idee to accelerate the soustraction, it will be a good idea to say them ;-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 2 17:13:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQa-0000G0-00 for ; Sun, 02 Dec 2001 21:41:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:32 +0100 (CET) Received: (qmail 15275 invoked by uid 0); 2 Dec 2001 10:14:40 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx019-rz3) with SMTP; 2 Dec 2001 10:14:40 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2AEdV02269 for ; Sun, 2 Dec 2001 05:14:39 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 10:13:53 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2ADrb02005 for f-cpu-list; Sun, 2 Dec 2001 05:13:53 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2ADpo02002 for ; Sun, 2 Dec 2001 05:13:52 -0500 Received: by moria.seul.org (Postfix) id C4FA11467FB; Sun, 2 Dec 2001 05:13:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 963021467F9 for ; Sun, 2 Dec 2001 05:13:51 -0500 (EST) Received: from ifrance.com (nas24-151.vlt.n.club-internet.fr [195.36.223.151]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 14EAA1690 for ; Sun, 2 Dec 2001 11:13:49 +0100 (CET) Message-ID: <3C0A530D.A54D2D72@ifrance.com> Date: Sun, 02 Dec 2001 11:13:02 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007220136.3c08f5a845efd@imp.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL a écrit : <...> > A+ > Cedric > > PS: I will finalise the divide unit during the next week. So if you have > some idee to accelerate the soustraction, it will be a good idea to say > them ;-) Soustraction are the same as adder so there is the same type of algorithme. > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 2 17:15:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQb-0000G0-00 for ; Sun, 02 Dec 2001 21:41:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:33 +0100 (CET) Received: (qmail 1619 invoked by uid 0); 2 Dec 2001 10:16:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx009-rz3) with SMTP; 2 Dec 2001 10:16:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2AGIP02575 for ; Sun, 2 Dec 2001 05:16:18 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 10:15:57 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2AFvK02303 for f-cpu-list; Sun, 2 Dec 2001 05:15:57 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2AFto02300 for ; Sun, 2 Dec 2001 05:15:56 -0500 Received: by moria.seul.org (Postfix) id CB8D11467FB; Sun, 2 Dec 2001 05:15:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id AB1B01467F9 for ; Sun, 2 Dec 2001 05:15:55 -0500 (EST) Received: from ifrance.com (nas24-151.vlt.n.club-internet.fr [195.36.223.151]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D59A1170F for ; Sun, 2 Dec 2001 11:15:53 +0100 (CET) Message-ID: <3C0A538B.2905535@ifrance.com> Date: Sun, 02 Dec 2001 11:15:07 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > In the futur could it be possible to put txt file and .tgz file on the site ? > i don't understand what you mean exactly. what site is it about ? > i checked the URL and it seems to work. > > > It is small sized file, so it's not a problem. I begin to have a > > too big collection of file in my /fcpu directory. > me too :-) it's a complete mess. > > > And it's more usefull when you want to have a very quick look. > > so you mean, a kind of "index.html" with the description of the files ? Nono, just the uncompress file to be quickly looked by a browser. > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > I know a few people who can do PHP/dynamic HTML but they are all > extremely busy : Lionel, Graham, ... > Maybe a wiki web server ? nicO <...> > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 15:17:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQe-0000G0-00 for ; Sun, 02 Dec 2001 21:41:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:36 +0100 (CET) Received: (qmail 1528 invoked by uid 0); 2 Dec 2001 14:15:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx016-rz3) with SMTP; 2 Dec 2001 14:15:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2EFH910371 for ; Sun, 2 Dec 2001 09:15:17 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 14:14:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2EEhq09844 for f-cpu-list; Sun, 2 Dec 2001 09:14:43 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2EEgo09841 for ; Sun, 2 Dec 2001 09:14:42 -0500 Received: by moria.seul.org (Postfix) id C24131467E9; Sun, 2 Dec 2001 09:14:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A61011467E8 for ; Sun, 2 Dec 2001 09:14:42 -0500 (EST) Received: from f-cpu.org (nas20-12.kdl.n.club-internet.fr [213.44.18.12]) by relay-2v.club-internet.fr (Postfix) with ESMTP id EB55019C8 for ; Sun, 2 Dec 2001 15:14:38 +0100 (CET) Message-ID: <3C0A37EC.6E3538B9@f-cpu.org> Date: Sun, 02 Dec 2001 15:17:16 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> <3C0A538B.2905535@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > > > hi ! > > > > nicO wrote: > > > In the futur could it be possible to put txt file and .tgz file on the site ? > > i don't understand what you mean exactly. what site is it about ? > > i checked the URL and it seems to work. > > > > > It is small sized file, so it's not a problem. I begin to have a > > > too big collection of file in my /fcpu directory. > > me too :-) it's a complete mess. > > > > > And it's more usefull when you want to have a very quick look. > > so you mean, a kind of "index.html" with the description of the files ? > Nono, just the uncompress file to be quickly looked by a browser. ok i got it. but i am not sure that we can do this everytime. > > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > > I know a few people who can do PHP/dynamic HTML but they are all > > extremely busy : Lionel, Graham, ... > Maybe a wiki web server ? i don't know. i'm not a professional :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 15:17:20 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQf-0000G0-00 for ; Sun, 02 Dec 2001 21:41:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:37 +0100 (CET) Received: (qmail 23981 invoked by uid 0); 2 Dec 2001 14:15:19 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx030-rz3) with SMTP; 2 Dec 2001 14:15:19 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2EFIr10386 for ; Sun, 2 Dec 2001 09:15:18 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 14:14:48 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2EEld09888 for f-cpu-list; Sun, 2 Dec 2001 09:14:47 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2EEko09876 for ; Sun, 2 Dec 2001 09:14:46 -0500 Received: by moria.seul.org (Postfix) id 51E451467E9; Sun, 2 Dec 2001 09:14:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 3A0691467E8 for ; Sun, 2 Dec 2001 09:14:46 -0500 (EST) Received: from f-cpu.org (nas20-12.kdl.n.club-internet.fr [213.44.18.12]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 6FF67176D for ; Sun, 2 Dec 2001 15:14:43 +0100 (CET) Message-ID: <3C0A37F0.D469D595@f-cpu.org> Date: Sun, 02 Dec 2001 15:17:20 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007220136.3c08f5a845efd@imp.free.fr> <3C0A530D.A54D2D72@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Cedric BAIL a écrit : > <...> > > A+ > > Cedric > > > > PS: I will finalise the divide unit during the next week. So if you have > > some idee to accelerate the soustraction, it will be a good idea to say > > them ;-) > > Soustraction are the same as adder so there is the same type of > algorithme. As noted before, there are a few boolean optimisations to do on a classical adder : tying the carry in to 1 can be propagated in the equations, as well as the negation of the input. As i also wrote, there is a very interesting document about arithmetic operators at http://www.iis.ee.ethz.ch/~zimmi/publications/comp_arith_notes.ps.gz (thank you michael !) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cms@pnetservice.de Sun Dec 2 15:19:03 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQf-0000G0-01 for ; Sun, 02 Dec 2001 21:41:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:37 +0100 (CET) Received: (qmail 29444 invoked by uid 0); 2 Dec 2001 14:19:26 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx018-rz3) with SMTP; 2 Dec 2001 14:19:26 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2EJPf10659 for ; Sun, 2 Dec 2001 09:19:25 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 14:19:06 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2EJ6f10418 for f-cpu-list; Sun, 2 Dec 2001 09:19:06 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2EJ5o10415 for ; Sun, 2 Dec 2001 09:19:05 -0500 Received: by moria.seul.org (Postfix) id 76DB11467E9; Sun, 2 Dec 2001 09:19:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by moria.seul.org (Postfix) with ESMTP id 0B6721467E8 for ; Sun, 2 Dec 2001 09:19:05 -0500 (EST) Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 16AXSS-0001fK-00 for f-cpu@seul.org; Sun, 2 Dec 2001 15:19:04 +0100 Received: from a09fc.pppool.de ([213.6.9.252] helo=apex) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 16AXSQ-0000ol-00 for f-cpu@seul.org; Sun, 2 Dec 2001 15:19:04 +0100 Date: Sun, 2 Dec 2001 15:19:03 +0100 From: "Christian M. Schubert" X-Mailer: The Bat! (v1.53d) X-Priority: 3 (Normal) Message-ID: <16067287465.20011202151903@pnetservice.de> To: Yann Guidon Subject: Re[2]: [f-cpu] yet another bag of bugs In-Reply-To: <3C08EF9A.4503D3E6@f-cpu.org> References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > so you mean, a kind of "index.html" with the description of the files ? > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > I know a few people who can do PHP/dynamic HTML but they are all > extremely busy : Lionel, Graham, ... Well, no need to reinvent the wheel: there are lots of freely available PHP-base forum engines out there (at least if you have access to a MySQL database, otherwise this will become much more difficult), e.g. http://sourceforge.net/projects/openbb For the file description stuff I think dHTML is not needed (I personally dislike active content), server side scripting (with PHP) should do the work with a minimum of work. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Dec 2 16:54:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQk-0000G0-00 for ; Sun, 02 Dec 2001 21:41:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:42 +0100 (CET) Received: (qmail 10471 invoked by uid 0); 2 Dec 2001 15:55:02 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx035-rz3) with SMTP; 2 Dec 2001 15:55:02 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2Ft2k11979 for ; Sun, 2 Dec 2001 10:55:02 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 15:54:32 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2FsW011711 for f-cpu-list; Sun, 2 Dec 2001 10:54:32 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2FsUo11708 for ; Sun, 2 Dec 2001 10:54:30 -0500 Received: by moria.seul.org (Postfix) id 6B68C1467EB; Sun, 2 Dec 2001 10:54:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 4151D1467E9 for ; Sun, 2 Dec 2001 10:54:30 -0500 (EST) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 7740F97 for ; Sun, 2 Dec 2001 16:54:29 +0100 (CET) Received: from imp2-2.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id fB2FsTpl020146 for ; Sun, 2 Dec 2001 16:54:29 +0100 Received: (from www-data@localhost) by imp2-2.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id fB2FsPGF020144 for f-cpu@seul.org; Sun, 2 Dec 2001 16:54:25 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs Message-ID: <1007308465.3c0a4eb11078b@imp.free.fr> Date: Sun, 02 Dec 2001 16:54:25 +0100 (MET) From: Cedric BAIL References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> <3C0A538B.2905535@ifrance.com> In-Reply-To: <3C0A538B.2905535@ifrance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Nono, just the uncompress file to be quickly looked by a browser. > > > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > > I know a few people who can do PHP/dynamic HTML but they are all > > extremely busy : Lionel, Graham, ... > > > > Maybe a wiki web server ? > nicO A better idea will to have a CVS web. A good question is did we have a CVS, and what is his CVS_ROOT variable ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Dec 2 17:17:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQl-0000G0-00 for ; Sun, 02 Dec 2001 21:41:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:43 +0100 (CET) Received: (qmail 30941 invoked by uid 0); 2 Dec 2001 16:17:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx023-rz3) with SMTP; 2 Dec 2001 16:17:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2GHRk12480 for ; Sun, 2 Dec 2001 11:17:27 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 16:17:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2GH5Z12212 for f-cpu-list; Sun, 2 Dec 2001 11:17:05 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2GH2o12209 for ; Sun, 2 Dec 2001 11:17:03 -0500 Received: by moria.seul.org (Postfix) id C1ADA1467E9; Sun, 2 Dec 2001 11:17:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 9D2F41467E8 for ; Sun, 2 Dec 2001 11:17:02 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix1-2.free.fr (Postfix) with ESMTP id 18113AB4BA for ; Sun, 2 Dec 2001 17:17:02 +0100 (CET) Received: from imp1-1.free.fr (www-data@localhost [127.0.0.1]) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) with ESMTP id fB2GH2I5025565 for ; Sun, 2 Dec 2001 17:17:02 +0100 Received: (from www-data@localhost) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) id fB2GH1An025564 for f-cpu@seul.org; Sun, 2 Dec 2001 17:17:01 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit Message-ID: <1007309821.3c0a53fd97ca2@imp.free.fr> Date: Sun, 02 Dec 2001 17:17:01 +0100 (MET) From: Cedric BAIL MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ10073098217d4ccbd7d02f03382e97cc407573b5e8" User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This message is in MIME format. ---MOQ10073098217d4ccbd7d02f03382e97cc407573b5e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > > Soustraction are the same as adder so there is the same type of > > algorithme. > > As noted before, there are a few boolean optimisations to do on a > classical adder : tying the carry in to 1 can be propagated in the > equations, as well as the negation of the input. > > As i also wrote, there is a very interesting document about > arithmetic operators at > http://www.iis.ee.ethz.ch/~zimmi/publications/comp_arith_notes.ps.gz > (thank you michael !) > > WHYGEE So you have now a new version, that will correctly work in 8, 16, 32 and 64 bits mod. I add a first release of what the eu_idiv unit will look like. The code is now clear and human readable. I remove all debugging line, and only the necessary code is present. The test best say some stupid thing when you are in mod > 16, I think that's my error but i don't know were I do it. (The modulo always say 0) If somebody know why simili say that... And what did you think about the pipelining of the 8bits part ? I know the core will perhaps not be more orthogonal. A+ Cedric ---MOQ10073098217d4ccbd7d02f03382e97cc407573b5e8 Content-Type: application/octet-stream; name="eu_idiv.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="eu_idiv.tar.bz2" ---MOQ10073098217d4ccbd7d02f03382e97cc407573b5e8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 17:55:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQn-0000G0-01 for ; Sun, 02 Dec 2001 21:41:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:45 +0100 (CET) Received: (qmail 11859 invoked by uid 0); 2 Dec 2001 16:53:28 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 2 Dec 2001 16:53:28 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2GrRk14136 for ; Sun, 2 Dec 2001 11:53:27 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 16:53:05 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2Gr5413864 for f-cpu-list; Sun, 2 Dec 2001 11:53:05 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2Gr4o13861 for ; Sun, 2 Dec 2001 11:53:04 -0500 Received: by moria.seul.org (Postfix) id 552E01467E9; Sun, 2 Dec 2001 11:53:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2B5821467E8 for ; Sun, 2 Dec 2001 11:53:04 -0500 (EST) Received: from f-cpu.org (nas6-29.kdl.n.club-internet.fr [213.44.1.29]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 97A50171F for ; Sun, 2 Dec 2001 17:52:55 +0100 (CET) Message-ID: <3C0A5D00.3DD99C8@f-cpu.org> Date: Sun, 02 Dec 2001 17:55:28 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> <3C0A538B.2905535@ifrance.com> <1007308465.3c0a4eb11078b@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > > > Nono, just the uncompress file to be quickly looked by a browser. > > > > > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > > > I know a few people who can do PHP/dynamic HTML but they are all > > > extremely busy : Lionel, Graham, ... > > > > > > > Maybe a wiki web server ? > > nicO > A better idea will to have a CVS web. A good question is did we have a CVS, > and what is his CVS_ROOT variable ? oh, and another question : a "CVSmail" would be quite useful. we send a mail to a specific address, the server strips the messages (to put it on the update field) and the attached file is uncompressed and put at the right place. Since i'm very busy, lazy and lame, i can't access to the CVS repository to update the GAOS CVS. a CVSmail would be a must, because there's a firewall at the university (only http and ftp downloads work). dreaming, dreaming... > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Dec 2 18:46:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQo-0000G0-01 for ; Sun, 02 Dec 2001 21:41:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:46 +0100 (CET) Received: (qmail 6649 invoked by uid 0); 2 Dec 2001 17:49:15 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx010-rz3) with SMTP; 2 Dec 2001 17:49:15 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2HnEJ16157 for ; Sun, 2 Dec 2001 12:49:14 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 17:48:27 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2HmQB15575 for f-cpu-list; Sun, 2 Dec 2001 12:48:26 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2HmPo15572 for ; Sun, 2 Dec 2001 12:48:25 -0500 Received: by moria.seul.org (Postfix) id 1F80B1467E9; Sun, 2 Dec 2001 12:48:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a242.home.uni-hannover.de [130.75.232.242]) by moria.seul.org (Postfix) with ESMTP id B0E311467E8 for ; Sun, 2 Dec 2001 12:48:22 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00671; Sun, 2 Dec 2001 18:46:08 +0100 Message-ID: <20011202184607.21015@thrai.stud.uni-hannover.de> Date: Sun, 2 Dec 2001 18:46:07 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C092C58.4458489@ifrance.com> <3C08EFA3.5A9535E5@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C08EFA3.5A9535E5@f-cpu.org>; from Yann Guidon on Sat, Dec 01, 2001 at 03:56:35PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 01, 2001 at 03:56:35PM +0100, Yann Guidon wrote: [...] > > - 2 adressing mode : immediat and register only. > ??? immediate ? [...] Loadcons and loadaddr are immediate instructions, aren't they? ;) In fact, we have at least four modes: register (most instructions) indirect (2-operand load/store) indirect with postincrement (loadi, storei, 3-operand load/store) immediate (loadcons, loadaddr) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Dec 2 18:39:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQp-0000G0-00 for ; Sun, 02 Dec 2001 21:41:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:47 +0100 (CET) Received: (qmail 25371 invoked by uid 0); 2 Dec 2001 17:49:18 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx008-rz3) with SMTP; 2 Dec 2001 17:49:18 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2HnH516181 for ; Sun, 2 Dec 2001 12:49:17 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 17:48:31 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2HmV615610 for f-cpu-list; Sun, 2 Dec 2001 12:48:31 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2HmTo15594 for ; Sun, 2 Dec 2001 12:48:29 -0500 Received: by moria.seul.org (Postfix) id C40EA1467E9; Sun, 2 Dec 2001 12:48:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a242.home.uni-hannover.de [130.75.232.242]) by moria.seul.org (Postfix) with ESMTP id 9ACA21467E8 for ; Sun, 2 Dec 2001 12:48:25 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00652; Sun, 2 Dec 2001 18:39:12 +0100 Message-ID: <20011202183912.40812@thrai.stud.uni-hannover.de> Date: Sun, 2 Dec 2001 18:39:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007220136.3c08f5a845efd@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1007220136.3c08f5a845efd@imp.free.fr>; from Cedric BAIL on Sat, Dec 01, 2001 at 04:22:16PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 01, 2001 at 04:22:16PM +0100, Cedric BAIL wrote: > So as Yann say last week, i was writing a divide/modulo unit for the F-CPU. > I concentrate me on the creation of a component that can do all size of > division. The principe of it is easy : > For i form WIDTH-1 to 0 > TmpB := B << i > TmpResult := substraction(A, TmpB); > if carry(TmpResult) = true then (test negativ result) > Yl(i) := 0; > else > Yl(i) := 1; > A := TmpResult; > endif > next i; > Yh := A; > > So you have, in the same pass : > Yl := A / B; > Yh := A % B; Yep... standard "restoring" division. Minor improvement: tmpB := B shl (WIDTH - 1); for i in WIDTH-1 downto 0 loop -- calculate result bit here tmpB := tmpB shr 1; end loop; This avoids the variable-size shift inside the loop (which would take at least 1 extra clock cycle). > As you can see all this unit need is a really good substraction function. > The one that I want to write will normally work for all size of data (if > it's a power of 4). The problem is that it doesn't work actually for a > other size than 8 (I have some porblem with index, it will be solved next > week). There's a general problem here: when the word size grows, the delay will increase as well (O(log(n))). A 64-bit divider will need 2 cycles for each result bit, larger units will be even slower. Another drawback is that this kind of algorithm doesn't work with signed operands. > I think, that i will probably rewrite my substraction function. Because > all the perfomance of this unit depend on it. I read a lot about the way > to jump over 0, do SRT divide, and I think that for F-CPU this type of > algorithm are perhaps not a good idea. Because if some case are accelerated > a lot of others are really slow down. And this type of algorithm are not > previsible, and the average speed of this unit is slower than this unit. > It's why i think it's not a good solution to use them. If operating on 8-bit bytes, the simple approach is faster -- it can perform an 8-bit division in 8 cycles --, but for larger word sizes, you need additional cycles for the subtract operation, which makes the SRT algorithm faster (1 cycle per bit, plus a few cycles for input preparation -- operand normalization -- and output postprocessing). > Of course this component is not pipelined. And i am sure that we divide > sometimes by something that take 64/32/16 bits, so only in really few case > we need to have a pipelined unit (And in this case they will perhaps write > a new div unit). But for 8bits it's not really the same problem, we use > them in all conversion from changing base, in crypto and in some 2d graphical > filter. In this case, that only represent a really few part of program, we will > have better result, if we have a pipelined 8bits unit i think. So the question > is : "Did we want to accelerate this application ?" Since we can calculate eight 8-bit quotients at a time (SIMD), pipelining doesn't seem really useful to me. > Finally were division are needed, it's in game. But actually all this game > (OpenGl and Direct3D games) use the FPU for all their number. So if we wan't > a good software implementation of OpenGl, we will need a good FPU (i mean > pipelined). And that's perhaps an other discussion ;-) Right, that's an entirely different playground. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 20:51:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQu-0000G0-00 for ; Sun, 02 Dec 2001 21:41:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:52 +0100 (CET) Received: (qmail 5375 invoked by uid 0); 2 Dec 2001 19:49:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx005-rz3) with SMTP; 2 Dec 2001 19:49:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2JnNn23558 for ; Sun, 2 Dec 2001 14:49:23 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 19:48:44 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2JmiW23018 for f-cpu-list; Sun, 2 Dec 2001 14:48:44 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2Jmho23015 for ; Sun, 2 Dec 2001 14:48:43 -0500 Received: by moria.seul.org (Postfix) id C98741467EB; Sun, 2 Dec 2001 14:48:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id B067F1467E9 for ; Sun, 2 Dec 2001 14:48:43 -0500 (EST) Received: from f-cpu.org (nas21-2.kdl.n.club-internet.fr [213.44.19.2]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 92F481699 for ; Sun, 2 Dec 2001 20:48:40 +0100 (CET) Message-ID: <3C0A8635.25C0B482@f-cpu.org> Date: Sun, 02 Dec 2001 20:51:17 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yet another bag of bugs References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C08EF9A.4503D3E6@f-cpu.org> <16067287465.20011202151903@pnetservice.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! "Christian M. Schubert" wrote: > > so you mean, a kind of "index.html" with the description of the files ? > > if i'm right, we'll need a webmaster AND a PHP-based forum engine... > > I know a few people who can do PHP/dynamic HTML but they are all > > extremely busy : Lionel, Graham, ... > > Well, no need to reinvent the wheel: there are lots of freely > available PHP-base forum engines out there (at least if you have access to a > MySQL database, otherwise this will become much more difficult), e.g. http://sourceforge.net/projects/openbb i don't know all the details (i am not into PHP or any database) but it is certainly possible to setup something at f-cpu.seul.org. > For the file description stuff I think dHTML is not needed (I > personally dislike active content), server side scripting (with PHP) > should do the work with a minimum of work. whatever floats the boat : any help is welcome ! thank in advance (just in case :-D) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 20:51:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AdQu-0000G0-01 for ; Sun, 02 Dec 2001 21:41:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 02 Dec 2001 21:41:52 +0100 (CET) Received: (qmail 16617 invoked by uid 0); 2 Dec 2001 19:49:25 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 2 Dec 2001 19:49:25 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2JnNq23557 for ; Sun, 2 Dec 2001 14:49:23 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 19:48:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2JmpR23098 for f-cpu-list; Sun, 2 Dec 2001 14:48:51 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2Jmno23082 for ; Sun, 2 Dec 2001 14:48:50 -0500 Received: by moria.seul.org (Postfix) id 67A891467EB; Sun, 2 Dec 2001 14:48:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 3F9D41467E9 for ; Sun, 2 Dec 2001 14:48:50 -0500 (EST) Received: from f-cpu.org (nas21-2.kdl.n.club-internet.fr [213.44.19.2]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 65C771741 for ; Sun, 2 Dec 2001 20:48:41 +0100 (CET) Message-ID: <3C0A8636.5501DC17@f-cpu.org> Date: Sun, 02 Dec 2001 20:51:18 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007309821.3c0a53fd97ca2@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Cedric BAIL wrote: > So you have now a new version, that will correctly work in 8, 16, 32 and 64 bits > mod. I add a first release of what the eu_idiv unit will look like. The code > is now clear and human readable. I remove all debugging line, and only the > necessary code is present. > > The test best say some stupid thing when you are in mod > 16, I think that's my > error but i don't know were I do it. (The modulo always say 0) If somebody > know why simili say that... > > And what did you think about the pipelining of the 8bits part ? I know the > core will perhaps not be more orthogonal. > > A+ > Cedric > > Name: eu_idiv.tar.bz2 > eu_idiv.tar.bz2 Type: unspecified type (application/octet-stream) > Encoding: base64 am i the only one who did not receive the file ? could you maybe upload it on a website ? thanks, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: i remember the subscribers that this mailing list server does not accept mails larger than 50KB. just in case. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 2 22:40:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AgvK-0002gz-00 for ; Mon, 03 Dec 2001 01:25:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 01:25:30 +0100 (CET) Received: (qmail 10076 invoked by uid 0); 2 Dec 2001 21:37:59 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx007-rz3) with SMTP; 2 Dec 2001 21:37:59 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2Lbx630624 for ; Sun, 2 Dec 2001 16:37:59 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 21:37:29 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2LbT830336 for f-cpu-list; Sun, 2 Dec 2001 16:37:29 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2LbRo30330 for ; Sun, 2 Dec 2001 16:37:28 -0500 Received: by moria.seul.org (Postfix) id E9B4A1467E9; Sun, 2 Dec 2001 16:37:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id D0D351467E8 for ; Sun, 2 Dec 2001 16:37:27 -0500 (EST) Received: from f-cpu.org (nas25-22.kdl.n.club-internet.fr [213.44.96.22]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 1E7D8174A for ; Sun, 2 Dec 2001 22:37:25 +0100 (CET) Message-ID: <3C0A9FB1.5CAD2F4C@f-cpu.org> Date: Sun, 02 Dec 2001 22:40:01 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C092C58.4458489@ifrance.com> <3C08EFA3.5A9535E5@f-cpu.org> <20011202184607.21015@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Sat, Dec 01, 2001 at 03:56:35PM +0100, Yann Guidon wrote: > [...] > > > - 2 adressing mode : immediat and register only. > > ??? immediate ? > [...] > > Loadcons and loadaddr are immediate instructions, aren't they? ;) > > In fact, we have at least four modes: > > register (most instructions) > indirect (2-operand load/store) > indirect with postincrement (loadi, storei, 3-operand load/store) > immediate (loadcons, loadaddr) > i'm sorry, but "addressing mode" is not "instruction format". loadcons and loadaddr are not considered as "addressing modes" because they don't access memory. furthermore, "indirect" is the same as "register" (in my own terminology). postincremented is not very different, there's only a bit more parallism. the thing that i want being remembered is that there is only one way to access the memory. The programmer must remember to prepare the pointers in the registers as soon as possible, before using the register to effectively access data. > Michael "Tired" Riepe WHYGEE, just being picky :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 3 05:52:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AgvQ-0002gz-00 for ; Mon, 03 Dec 2001 01:25:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 01:25:36 +0100 (CET) Received: (qmail 13625 invoked by uid 0); 2 Dec 2001 22:53:42 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx017-rz3) with SMTP; 2 Dec 2001 22:53:42 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB2Mreb03620 for ; Sun, 2 Dec 2001 17:53:40 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Sun, 2 Dec 2001 22:53:04 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB2Mr4n03345 for f-cpu-list; Sun, 2 Dec 2001 17:53:04 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB2Mr3o03342 for ; Sun, 2 Dec 2001 17:53:03 -0500 Received: by moria.seul.org (Postfix) id 0010B1467E9; Sun, 2 Dec 2001 17:53:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id DBED81467E8 for ; Sun, 2 Dec 2001 17:53:03 -0500 (EST) Received: from ifrance.com (nas23-84.vlt.n.club-internet.fr [195.36.173.84]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 440AE16FF for ; Sun, 2 Dec 2001 23:53:01 +0100 (CET) Message-ID: <3C0B0501.98091B8@ifrance.com> Date: Sun, 02 Dec 2001 23:52:17 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C092C58.4458489@ifrance.com> <3C08EFA3.5A9535E5@f-cpu.org> <20011202184607.21015@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Dec 01, 2001 at 03:56:35PM +0100, Yann Guidon wrote: > [...] > > > - 2 adressing mode : immediat and register only. > > ??? immediate ? > [...] > > Loadcons and loadaddr are immediate instructions, aren't they? ;) > > In fact, we have at least four modes: > > register (most instructions) > indirect (2-operand load/store) > indirect with postincrement (loadi, storei, 3-operand load/store) this 2 aren't really true because it's POST increment each time. It's more like usual register adressing. nicO > immediate (loadcons, loadaddr) > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 3 01:13:45 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16AjDD-00044C-00 for ; Mon, 03 Dec 2001 03:52:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 03:52:07 +0100 (CET) Received: (qmail 17334 invoked by uid 0); 3 Dec 2001 00:14:24 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx032-rz3) with SMTP; 3 Dec 2001 00:14:24 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB30EN812345 for ; Sun, 2 Dec 2001 19:14:23 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Dec 2001 00:13:52 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB30Dqd12041 for f-cpu-list; Sun, 2 Dec 2001 19:13:52 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB30Doo12038 for ; Sun, 2 Dec 2001 19:13:50 -0500 Received: by moria.seul.org (Postfix) id 288181467E9; Sun, 2 Dec 2001 19:13:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id B28E91467E8 for ; Sun, 2 Dec 2001 19:13:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01874; Mon, 3 Dec 2001 01:13:45 +0100 Message-ID: <20011203011345.00543@thrai.stud.uni-hannover.de> Date: Mon, 3 Dec 2001 01:13:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Resume of Fcpu features References: <3C087107.84F0CC3E@f-cpu.org> <3C08FE91.43A1091D@ifrance.com> <3C092C58.4458489@ifrance.com> <3C08EFA3.5A9535E5@f-cpu.org> <20011202184607.21015@thrai.stud.uni-hannover.de> <3C0A9FB1.5CAD2F4C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C0A9FB1.5CAD2F4C@f-cpu.org>; from Yann Guidon on Sun, Dec 02, 2001 at 10:40:01PM +0100 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Dec 02, 2001 at 10:40:01PM +0100, Yann Guidon wrote: [...] > > In fact, we have at least four modes: > > > > register (most instructions) > > indirect (2-operand load/store) > > indirect with postincrement (loadi, storei, 3-operand load/store) > > immediate (loadcons, loadaddr) > > > > i'm sorry, but "addressing mode" is not "instruction format". > loadcons and loadaddr are not considered as "addressing modes" > because they don't access memory. furthermore, > "indirect" is the same as "register" (in my own terminology). > postincremented is not very different, there's only a bit more parallism. This has always been a little bit confusing... In my vocabulary, "addressing mode" means "where the operands come from". "immediate" means: from the instruction, "register" means: it's stored in a register, and "indirect" means, of course, that its *address* is stored in a register, and the operand itself resides in memory. One the other hand, one could claim that there are only "immediate" and "register" modes (load/store take the address operand from a register, and no instruction fetches its operands from memory directly, like Intel CPUs do). > the thing that i want being remembered is that there is only > one way to access the memory. The programmer must remember to > prepare the pointers in the registers as soon as possible, > before using the register to effectively access data. Then let's not waste time talking about "addressing modes", but say what we mean: operands and results have to be moved from/to memory, using the load and store instructions, and the memory address has to be calculated explicitly. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Dec 3 11:28:41 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B1CR-0000BW-00 for ; Mon, 03 Dec 2001 23:04:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 23:04:31 +0100 (CET) Received: (qmail 21424 invoked by uid 0); 3 Dec 2001 10:29:41 -0000 Received: from belegost.mit.edu (18.244.0.114) by mx0.gmx.net (mx004-rz3) with SMTP; 3 Dec 2001 10:29:41 -0000 Received: from localhost (bin@localhost) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id fB3ATeB30624 for ; Mon, 3 Dec 2001 05:29:40 -0500 Received: by belegost.mit.edu (bulk_mailer v1.5); Mon, 3 Dec 2001 10:28:45 +0000 Received: (from majordomo@localhost) by belegost.mit.edu (8.11.6/8.11.6) id fB3ASj230343 for f-cpu-list; Mon, 3 Dec 2001 05:28:45 -0500 Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id fB3ASho30339 for ; Mon, 3 Dec 2001 05:28:43 -0500 Received: by moria.seul.org (Postfix) id 9BBD71467E9; Mon, 3 Dec 2001 05:28:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id CD79F1467E8 for ; Mon, 3 Dec 2001 05:28:42 -0500 (EST) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 45C1132B for ; Mon, 3 Dec 2001 11:28:42 +0100 (CET) Received: from imp2-2.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id fB3ASgpl003740 for ; Mon, 3 Dec 2001 11:28:42 +0100 Received: (from www-data@localhost) by imp2-2.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id fB3ASgDE003739 for f-cpu@seul.org; Mon, 3 Dec 2001 11:28:42 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit Message-ID: <1007375321.3c0b53d9e73fd@imp.free.fr> Date: Mon, 03 Dec 2001 11:28:41 +0100 (MET) From: Cedric BAIL References: <1007309821.3c0a53fd97ca2@imp.free.fr> <3C0A8636.5501DC17@f-cpu.org> In-Reply-To: <3C0A8636.5501DC17@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Name: eu_idiv.tar.bz2 > > eu_idiv.tar.bz2 Type: unspecified type > (application/octet-stream) > > Encoding: base64 > > am i the only one who did not receive the file ? > could you maybe upload it on a website ? So I put it on http://www.epita.fr:8000/~bail_c/ (I have some problem with sending binary file with the webmail of free, sorry) A+ Cedric > thanks, > > WHYGEE PS: It's only a 9Ko file ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 3 16:11:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B1Cd-0000BW-00 for ; Mon, 03 Dec 2001 23:04:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 23:04:43 +0100 (CET) Received: (qmail 28381 invoked by uid 0); 3 Dec 2001 15:08:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 3 Dec 2001 15:08:50 -0000 Received: by moria.seul.org (Postfix) id 8909C1467F8; Mon, 3 Dec 2001 10:08:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6202E1467FA; Mon, 3 Dec 2001 10:08:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 198701467F8 for ; Mon, 3 Dec 2001 10:08:47 -0500 (EST) Received: from f-cpu.org (nas15-43.kdl.n.club-internet.fr [213.44.9.43]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 376A91747 for ; Mon, 3 Dec 2001 16:08:44 +0100 (CET) Message-ID: <3C0B961A.A193808F@f-cpu.org> Date: Mon, 03 Dec 2001 16:11:22 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007309821.3c0a53fd97ca2@imp.free.fr> <3C0A8636.5501DC17@f-cpu.org> <1007375321.3c0b53d9e73fd@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > > > Name: eu_idiv.tar.bz2 > > > eu_idiv.tar.bz2 Type: unspecified type > > (application/octet-stream) > > > Encoding: base64 > > > > am i the only one who did not receive the file ? > > could you maybe upload it on a website ? > So I put it on http://www.epita.fr:8000/~bail_c/ > (I have some problem with sending binary file with > the webmail of free, sorry) mmm do they teach the virtues of chmod, in your school ? :-P L'accès à a cette page vous est interdit ...
Permission denied to get this page , sorry... > A+ > Cedric > PS: It's only a 9Ko file so when i saw that i got less than a kilobyte, i thought i'd look at the file dump... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: don't worry : one day we'll get it right. try the anonymous ftp at seul.org. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Dec 3 17:51:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B1Ce-0000BW-00 for ; Mon, 03 Dec 2001 23:04:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 23:04:44 +0100 (CET) Received: (qmail 29986 invoked by uid 0); 3 Dec 2001 16:51:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 3 Dec 2001 16:51:46 -0000 Received: by moria.seul.org (Postfix) id BB0081467FE; Mon, 3 Dec 2001 11:51:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7F621467FD; Mon, 3 Dec 2001 11:51:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 6CBCB1467FB for ; Mon, 3 Dec 2001 11:51:45 -0500 (EST) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-1.free.fr (Postfix) with ESMTP id B0FDF117 for ; Mon, 3 Dec 2001 17:51:44 +0100 (CET) Received: from imp1-2.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id fB3Gpi45028492 for ; Mon, 3 Dec 2001 17:51:44 +0100 Received: (from www-data@localhost) by imp1-2.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id fB3Gpiqm028490 for f-cpu@seul.org; Mon, 3 Dec 2001 17:51:44 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit Message-ID: <1007398304.3c0bada066f8e@imp.free.fr> Date: Mon, 03 Dec 2001 17:51:44 +0100 (MET) From: Cedric BAIL References: <1007309821.3c0a53fd97ca2@imp.free.fr> <3C0A8636.5501DC17@f-cpu.org> <1007375321.3c0b53d9e73fd@imp.free.fr> <3C0B961A.A193808F@f-cpu.org> In-Reply-To: <3C0B961A.A193808F@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > mmm do they teach the virtues of chmod, in your school ? :-P Gnagnagna... It's ok know (this apache server is so stupid ;-) > so when i saw that i got less than a kilobyte, i thought > i'd look at the file dump... > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > PS: don't worry : one day we'll get it right. > try the anonymous ftp at seul.org. I can't use it, lionel do a vary complicated system so that I have an account on seul but I can't use it, when i am at epita... A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 4 02:05:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B1Ck-0000BW-01 for ; Mon, 03 Dec 2001 23:04:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Dec 2001 23:04:50 +0100 (CET) Received: (qmail 30023 invoked by uid 0); 3 Dec 2001 19:06:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Dec 2001 19:06:42 -0000 Received: by moria.seul.org (Postfix) id 29341146800; Mon, 3 Dec 2001 14:06:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 086D6146803; Mon, 3 Dec 2001 14:06:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A548C146800 for ; Mon, 3 Dec 2001 14:06:40 -0500 (EST) Received: from ifrance.com (nas6-159.vlt.n.club-internet.fr [194.158.108.159]) by relay-3v.club-internet.fr (Postfix) with ESMTP id E3A841752 for ; Mon, 3 Dec 2001 20:06:33 +0100 (CET) Message-ID: <3C0C2172.69EE4969@ifrance.com> Date: Mon, 03 Dec 2001 20:05:54 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] Re: (forw) Paper proposal Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Andy Mueller-Maguhn a écrit : > > >I'm from the f-cpu team. We would to make a 2 hours speach about the > >fcpu technology and last development (we will try to make it less boring > >than last year ;p). > > That´s great. For planning the time-slot and announcement I need > > - titel > - short description (5 lines or so) > - references / URL´s > - coordinates of the people / phone # > > best regards, > > A. I believe that the short description will be display in there web site. It's like an advertising for us. So we must encourage them to see our presentation. I want to propose that : The F-cpu (Freedom CPU) project The goal of the project is to write a free cpu (free in the sense of the french "libre" not free of charge). The CPU is written in VHDL and will be at the disposition of what ever people want to build one. The main goal is to provide a free IP to create a new standard with a good ratio between cost and performance. Nowadays, almost all the instruction set are defined and most integer execution unit (blocs that make calcul) are under design. The main project problem are the lack of free synthesys tools (to translate code to chip) and good GPL-like licence (silicon are under specific law). We will present all the hard point in the design of a cpu and the global architecture of the Fcpu. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 3 23:51:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B2Vv-0001LK-00 for ; Tue, 04 Dec 2001 00:28:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Dec 2001 00:28:43 +0100 (CET) Received: (qmail 29074 invoked by uid 0); 3 Dec 2001 22:49:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 3 Dec 2001 22:49:03 -0000 Received: by moria.seul.org (Postfix) id F33A1146808; Mon, 3 Dec 2001 17:49:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D06FB146807; Mon, 3 Dec 2001 17:49:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3560E146807 for ; Mon, 3 Dec 2001 17:49:01 -0500 (EST) Received: from f-cpu.org (nas25-81.kdl.n.club-internet.fr [213.44.96.81]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 098AF16A9 for ; Mon, 3 Dec 2001 23:48:57 +0100 (CET) Message-ID: <3C0C01F8.FBD1487E@f-cpu.org> Date: Mon, 03 Dec 2001 23:51:36 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007309821.3c0a53fd97ca2@imp.free.fr> <3C0A8636.5501DC17@f-cpu.org> <1007375321.3c0b53d9e73fd@imp.free.fr> <3C0B961A.A193808F@f-cpu.org> <1007398304.3c0bada066f8e@imp.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Cedric BAIL wrote: > > mmm do they teach the virtues of chmod, in your school ? :-P > Gnagnagna... gnagna toi-même :-P > It's ok know (this apache server is so stupid ;-) ok i'll try in a few minutes. > > PS: don't worry : one day we'll get it right. > > try the anonymous ftp at seul.org. > I can't use it, lionel do a vary complicated system so that I have > an account on seul but I can't use it, when i am at epita... don't they allow the ssh port ? > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 3 23:51:42 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16B2Vv-0001LK-01 for ; Tue, 04 Dec 2001 00:28:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Dec 2001 00:28:43 +0100 (CET) Received: (qmail 12377 invoked by uid 0); 3 Dec 2001 22:49:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 3 Dec 2001 22:49:09 -0000 Received: by moria.seul.org (Postfix) id 8761E14680B; Mon, 3 Dec 2001 17:49:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D1E214680C; Mon, 3 Dec 2001 17:49:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B2324146807 for ; Mon, 3 Dec 2001 17:49:07 -0500 (EST) Received: from f-cpu.org (nas25-81.kdl.n.club-internet.fr [213.44.96.81]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 944041693 for ; Mon, 3 Dec 2001 23:49:03 +0100 (CET) Message-ID: <3C0C01FE.D29BC516@f-cpu.org> Date: Mon, 03 Dec 2001 23:51:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: (forw) Paper proposal References: <3C0C2172.69EE4969@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Andy Mueller-Maguhn a écrit : oh, Andy :-) > > >I'm from the f-cpu team. We would to make a 2 hours speach about the > > >fcpu technology and last development (we will try to make it less boring > > >than last year ;p). > > > > That´s great. For planning the time-slot and announcement I need > > > > - titel > > - short description (5 lines or so) > > - references / URL´s > > - coordinates of the people / phone # > > > > best regards, > > > > A. > > I believe that the short description will be display in there web site. right. look at the last years : you can find the description in the CCC's archives. > It's like an advertising for us. So we must encourage them to see our > presentation. that's not the most difficult : we have to keep them from leaving after 20 minutes ;-P > I want to propose that : > > The F-cpu (Freedom CPU) project > > The goal of the project is to write ******************************* ^ "design" > a free cpu (free in the sense of the french "libre" ***********************************^ " freedom" > not free of charge). The CPU is written in VHDL and will > be at the disposition of what ever people want to build one. *************************** "whoever wants" > The main goal is to provide a free IP ************************************^ this term is not known and will be confused with the network protocol. > to create a new standard with a good ratio ************************************** "compromise" > between cost and performance. > > Nowadays, almost all the instruction set are defined and most integer ******************************************* "is" > execution unit (blocs that make calcul) are under design. The main > project problem are the lack of free synthesys tools (to translate code > to chip) and good GPL-like licence (silicon are under specific law). > > We will present all the hard point in the design of a cpu and the global > architecture of the Fcpu. if you can keep this program, it's fine for me. In the end of the text there are many english errors so i prefer to copy and modify it. Here is the "cleaned" version : (Graham, or whoever, please correct me :-D) The F-cpu (Freedom CPU) project The goal of the project is to design a free cpu core (free in the sense of "freedom", not free of charge). The CPU is written in VHDL and all the source code and documentation will be available to whoever wants to build one under a GNU licence (or very close to). The contributors are mostly european and want to create a new standard with a good compromise between cost and performance. Nowadays, the instruction set is defined and most integer execution units (computational blocks) are in active design. Now that we have found VHDL simulators, the main problem today is the lack of free synthesis tools (to translate VHDL code into a chip mask) and an enforceable GPL-like licence (electronic circuits obey to specific laws). We will present all the key issues in the design of a cpu and the global architecture of the F-cpu. (FC0 ?) PS: during the presentation, please do not confuse "F-CPU" and "FC0". PS2: are you sure that you will have enough time to present ALL the "hard points" ? :-P PS3: geeez, if this program works, i wish i was at least in the audience :-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Dec 5 20:26:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16BiIe-0000Fn-00 for ; Wed, 05 Dec 2001 21:05:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Dec 2001 21:05:48 +0100 (CET) Received: (qmail 25954 invoked by uid 0); 5 Dec 2001 19:26:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 5 Dec 2001 19:26:15 -0000 Received: by moria.seul.org (Postfix) id 3E4DC146802; Wed, 5 Dec 2001 14:26:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D8EB14680A; Wed, 5 Dec 2001 14:26:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by moria.seul.org (Postfix) with ESMTP id A87D8146802 for ; Wed, 5 Dec 2001 14:26:12 -0500 (EST) Received: from computer ([208.60.244.41]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20011205192721.HJBE12394.imf03bis.bellsouth.net@computer>; Wed, 5 Dec 2001 14:27:21 -0500 Message-ID: <000a01c17dc2$b6ed0a80$29f43cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Add/Sub Date: Wed, 5 Dec 2001 13:26:17 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C17D90.6B818EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C17D90.6B818EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Write your logic equations such that you have carrys propagate over = eight bits or even sixteen as I have done in the ERIN32. Regards Dick Hartney ------=_NextPart_000_0007_01C17D90.6B818EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Write your logic equations such that = you have=20 carrys propagate over eight bits or even sixteen as I have done = in
the ERIN32.
 
Regards
Dick Hartney
------=_NextPart_000_0007_01C17D90.6B818EE0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Dec 6 01:58:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Bndx-0003tA-00 for ; Thu, 06 Dec 2001 02:48:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Dec 2001 02:48:09 +0100 (CET) Received: (qmail 9362 invoked by uid 0); 6 Dec 2001 00:55:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 6 Dec 2001 00:55:29 -0000 Received: by moria.seul.org (Postfix) id EB519146817; Wed, 5 Dec 2001 19:55:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C0FE314681A; Wed, 5 Dec 2001 19:55:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 6EE95146817; Wed, 5 Dec 2001 19:55:26 -0500 (EST) Received: from f-cpu.org (nas5-42.kdl.n.club-internet.fr [213.44.0.42]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7FAF7168C; Thu, 6 Dec 2001 01:55:23 +0100 (CET) Message-ID: <3C0EC29F.5367FE11@f-cpu.org> Date: Thu, 06 Dec 2001 01:58:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: Web server in VHDL? (vhdl-posix-0.1)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N you have to read it to believe it ! i mean : go fetch the source package and read the source :-) The sad side of it : it only works with Modelsim and Synopsys. not even with Cadence !! Maybe it's worth an entry in the OpenCollector database, and/or some coding/support efforts ?... (not in F-CPU but for those into coding simulators...) YG -------- Original Message -------- From: Marius Vollmer Newsgroups: comp.lang.vhdl Subject: Web server in VHDL? (vhdl-posix-0.1) Date: 05 Dec 2001 18:39:06 +0100 Organization: AG DT/IPL, EE, University of Dortmund Hi, I've just uploaded vhdl-posix-0.1.tar.gz to http://freesoftware.fsf.org/download/vhdl-posix/ This is mostly a proof-of-concept and to get feedback. It includes a (very minimal) HTTP server written in VHDL! >From the README: This is version 0.1 of the vhdl-posix package. It provides support for accessing POSIX features from VHDL. Currently, there is some useful support for Modelsim, and some initial code for the Synopsys implementations of VHPI. VHPI is largely untested. VHDL is a nice language for simulating hardware. It is not so nice for interacting with the environment of the simulator. Given that a simulation is just a program, after all, you might want to do things that other programs do: open network connections, launching processes, and reacting to outside events. VHDL itself does not provide the means for this, but each simulator likely offers support for doing things that are `out of the ordinary', by allowing calls to code written in C. This package aims to provide a portable way of accessing selected features of POSIX. It should be portable across different POSIX implementations, and across different simulators. - Marius ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Dec 6 14:25:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CISb-0000G2-01 for ; Fri, 07 Dec 2001 11:42:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 11:42:29 +0100 (CET) Received: (qmail 8874 invoked by uid 0); 6 Dec 2001 13:25:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 6 Dec 2001 13:25:51 -0000 Received: by moria.seul.org (Postfix) id 62C3014680C; Thu, 6 Dec 2001 08:25:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24836146834; Thu, 6 Dec 2001 08:25:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id A476014680C for ; Thu, 6 Dec 2001 08:25:49 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id A084F3CC for ; Thu, 6 Dec 2001 14:25:48 +0100 (CET) Received: from imp1-1.free.fr (www-data@localhost [127.0.0.1]) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) with ESMTP id fB6DPl4B022873 for ; Thu, 6 Dec 2001 14:25:47 +0100 Received: (from www-data@localhost) by imp1-1.free.fr (8.12.1/8.12.1/Debian -1) id fB6DPhff022858 for f-cpu@seul.org; Thu, 6 Dec 2001 14:25:43 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit Message-ID: <1007645143.3c0f71d7aac7b@imp.free.fr> Date: Thu, 06 Dec 2001 14:25:43 +0100 (MET) From: Cedric BAIL References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> In-Reply-To: <20011202183912.40812@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Yep... standard "restoring" division. > Minor improvement: > > tmpB := B shl (WIDTH - 1); > for i in WIDTH-1 downto 0 loop > -- calculate result bit here > tmpB := tmpB shr 1; > end loop; > This avoids the variable-size shift inside the loop (which would take > at least 1 extra clock cycle). Ok, that's change has been done. > > As you can see all this unit need is a really good substraction function. > > The one that I want to write will normally work for all size of data (if > > it's a power of 4). The problem is that it doesn't work actually for a > > other size than 8 (I have some porblem with index, it will be solved next > > week). > There's a general problem here: when the word size grows, the delay > will increase as well (O(log(n))). A 64-bit divider will need 2 cycles for > each result bit, larger units will be even slower. Another drawback > is that this kind of algorithm doesn't work with signed operands. It's sure. But i don't know if we need to do signed division, only a prestage to positive them and a postage to negative them back, if they are negative is needed. So i don't know, if we must do this in divide unit or not. > > I think, that i will probably rewrite my substraction function. Because > > all the perfomance of this unit depend on it. I read a lot about the way > > to jump over 0, do SRT divide, and I think that for F-CPU this type of > > algorithm are perhaps not a good idea. Because if some case are accelerated > > a lot of others are really slow down. And this type of algorithm are not > > previsible, and the average speed of this unit is slower than this unit. > > It's why i think it's not a good solution to use them. > If operating on 8-bit bytes, the simple approach is faster -- it can > perform an 8-bit division in 8 cycles --, but for larger word sizes, > you need additional cycles for the subtract operation, which makes the > SRT algorithm faster (1 cycle per bit, plus a few cycles for input > preparation -- operand normalization -- and output postprocessing). So, it's ok. I am know learning howto do a good SRT/RADIX division. The question that I have, is how big must I do it (I read some little things about 2-, 4-, 8-bits Raddix/SRT divider). Perhaps a solution is to do a C program that will generate the SRT/RADDIX divider that you want. > Since we can calculate eight 8-bit quotients at a time (SIMD), > pipelining doesn't seem really useful to me. I am really stupid, I forgot this ;-) An other things, I am currently looking to the divider unit (idiv.vhdl). And I thing that it's possible to do 8, 16, 32 and 64bits divisions in parallel. So I am curently redesigning this unit to do it, so I change the entity prototype. I had : - Some bits to say that the result is ready - Some others to say that's the result will be ready in LENGTH cycle (it's a quick approximation, for the scheduler) - And some non-interesting bits to say wich unit is currently used. I had the same bits for the divmod component (but not the non-intersting bits ;-) So what did you think about that ? A+ Cedric PS: the current eu_idiv on my account at epita did not work, I will finished it during the week end. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 6 19:51:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CISv-0000G2-01 for ; Fri, 07 Dec 2001 11:42:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 11:42:49 +0100 (CET) Received: (qmail 31927 invoked by uid 0); 6 Dec 2001 22:58:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 6 Dec 2001 22:58:14 -0000 Received: by moria.seul.org (Postfix) id 4ED6A1467F7; Thu, 6 Dec 2001 17:58:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3597E146800; Thu, 6 Dec 2001 17:58:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a157.home.uni-hannover.de [130.75.232.157]) by moria.seul.org (Postfix) with ESMTP id 8D9A81467F7 for ; Thu, 6 Dec 2001 17:58:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00749; Thu, 6 Dec 2001 19:51:29 +0100 Message-ID: <20011206195128.17819@thrai.stud.uni-hannover.de> Date: Thu, 6 Dec 2001 19:51:28 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1007645143.3c0f71d7aac7b@imp.free.fr>; from Cedric BAIL on Thu, Dec 06, 2001 at 02:25:43PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Dec 06, 2001 at 02:25:43PM +0100, Cedric BAIL wrote: [signed division] > > There's a general problem here: when the word size grows, the delay > > will increase as well (O(log(n))). A 64-bit divider will need 2 cycles for > > each result bit, larger units will be even slower. Another drawback > > is that this kind of algorithm doesn't work with signed operands. > It's sure. But i don't know if we need to do signed division, only a prestage > to positive them and a postage to negative them back, if they are negative is > needed. So i don't know, if we must do this in divide unit or not. Separate abs/neg stages are an option (at least for FC0). They'll take two more cycles, but I don't really care for it. [...] > > If operating on 8-bit bytes, the simple approach is faster -- it can > > perform an 8-bit division in 8 cycles --, but for larger word sizes, > > you need additional cycles for the subtract operation, which makes the > > SRT algorithm faster (1 cycle per bit, plus a few cycles for input > > preparation -- operand normalization -- and output postprocessing). > So, it's ok. I am know learning howto do a good SRT/RADIX division. The > question that I have, is how big must I do it (I read some little things > about 2-, 4-, 8-bits Raddix/SRT divider). Perhaps a solution is to do a C > program that will generate the SRT/RADDIX divider that you want. I've been playing with the SRT approach for quite a while, and my conclusion was to stick with radix-2 (one result bit at a time). You won't be able to calculate 2 or more bits in one F-CPU (6 gate) pipeline stage, and the decision logic becomes much more complex quickly when you increase the radix. Maybe there will be a speed improvement if you use radix-16 or greater, but you'll have to pay for it (complexity, area, and possibility of errors). On the other hand, a radix-2 SRT *can* do 1 result bit per cycle independent of the operand size, while most other algorithms can't. > > Since we can calculate eight 8-bit quotients at a time (SIMD), > > pipelining doesn't seem really useful to me. > I am really stupid, I forgot this ;-) > > An other things, I am currently looking to the divider unit (idiv.vhdl). And > I thing that it's possible to do 8, 16, 32 and 64bits divisions in parallel. Yes and no. You can do e.g. 8-but divisions with a 32-bit divider (just set the unused bits to zero), but it seems to be impossible (within the scope of the F-CPU) to split the divider and let both halves operate independently, because the split logic will increase the delay too much. I proposed a solution a while ago (YG said it was "crayzee as usual"), but it requires a lot of code duplication (150% overhead, compared to a "straight" 64-bit divider). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Dec 7 01:38:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CIT0-0000G2-01 for ; Fri, 07 Dec 2001 11:42:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 11:42:54 +0100 (CET) Received: (qmail 23704 invoked by uid 0); 7 Dec 2001 00:35:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 7 Dec 2001 00:35:19 -0000 Received: by moria.seul.org (Postfix) id A9C5F1467F7; Thu, 6 Dec 2001 19:35:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8AFC3146806; Thu, 6 Dec 2001 19:35:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3F4911467F7 for ; Thu, 6 Dec 2001 19:35:18 -0500 (EST) Received: from f-cpu.org (kdl16-1.n.club-internet.fr [213.44.18.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id EBE7716F7 for ; Fri, 7 Dec 2001 01:35:15 +0100 (CET) Message-ID: <3C100F69.59601BB3@f-cpu.org> Date: Fri, 07 Dec 2001 01:38:01 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: Re: [congress-crew] F-CPU@18C3] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, FYI i just got this. -------- Original Message -------- Date: Thu, 6 Dec 2001 15:07:00 +0100 To: whygee@f-cpu.org From: Andy Mueller-Maguhn Subject: Re: [congress-crew] F-CPU@18C3 Cc: congress-crew@lists.ccc.de >I do not know if Nicolas Boulay has already >requested a time slot. Yes, he has and got it. But anyhow thanx for your mail.. regards, A. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Dec 7 18:25:47 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CT74-0000G5-00 for ; Fri, 07 Dec 2001 23:04:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 23:04:58 +0100 (CET) Received: (qmail 30880 invoked by uid 0); 7 Dec 2001 17:25:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 7 Dec 2001 17:25:50 -0000 Received: by moria.seul.org (Postfix) id 81D94146819; Fri, 7 Dec 2001 12:25:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78B84146818; Fri, 7 Dec 2001 12:25:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 0D7F9146816 for ; Fri, 7 Dec 2001 12:25:49 -0500 (EST) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-2.free.fr (Postfix) with ESMTP id 140D96011D for ; Fri, 7 Dec 2001 18:25:47 +0100 (CET) Received: from imp2-1.free.fr (www-data@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id fB7HPlUM010948 for ; Fri, 7 Dec 2001 18:25:47 +0100 Received: (from www-data@localhost) by imp2-1.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id fB7HPlou010947 for f-cpu@seul.org; Fri, 7 Dec 2001 18:25:47 +0100 To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit Message-ID: <1007745947.3c10fb9b7cf62@imp.free.fr> Date: Fri, 07 Dec 2001 18:25:47 +0100 (MET) From: Cedric BAIL References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> In-Reply-To: <20011206195128.17819@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Separate abs/neg stages are an option (at least for FC0). They'll > take two more cycles, but I don't really care for it. So it's ok, only unsigned version will be done for the FC0. [...] > I've been playing with the SRT approach for quite a while, and my > conclusion was to stick with radix-2 (one result bit at a time). > You won't be able to calculate 2 or more bits in one F-CPU (6 gate) > pipeline stage, and the decision logic becomes much more complex I don't understood the problem, the division is not signed, so were is the problem with pipeline stage ? > quickly when you increase the radix. Maybe there will be a speed > improvement if you use radix-16 or greater, but you'll have to pay for it > (complexity, area, and possibility of errors). So, i think that i will write the C program to generate the radix division that we want, and we do the choice of wich version to use at the last moment. > On the other hand, a radix-2 SRT *can* do 1 result bit per cycle > independent of the operand size, while most other algorithms can't. > > An other things, I am currently looking to the divider unit (idiv.vhdl). > > And I thing that it's possible to do 8, 16, 32 and 64bits divisions in > > parallel. > Yes and no. You can do e.g. 8-but divisions with a 32-bit divider > (just set the unused bits to zero), but it seems to be impossible (within > the scope of the F-CPU) to split the divider and let both halves operate > independently, because the split logic will increase the delay too > much. So, if i correctly understand this, this is not the solution, right ? ;-) I currently instantiate 8 * 8bits divider, 4 * 16bits divider and so on. So we can use them in parallel. I dont know how it increase the size of the unit compared to the reuse of 32bits divider. > I proposed a solution a while ago (YG said it was "crayzee as usual"), > but it requires a lot of code duplication (150% overhead, compared to > a "straight" 64-bit divider). And what is the solution ? I am really interested by it. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 8 01:49:46 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CT75-0000G5-01 for ; Fri, 07 Dec 2001 23:04:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 23:04:59 +0100 (CET) Received: (qmail 31889 invoked by uid 0); 7 Dec 2001 18:50:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 7 Dec 2001 18:50:11 -0000 Received: by moria.seul.org (Postfix) id 10B0814681A; Fri, 7 Dec 2001 13:50:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB898146822; Fri, 7 Dec 2001 13:50:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 9605D14681A for ; Fri, 7 Dec 2001 13:50:09 -0500 (EST) Received: from ifrance.com (vlt6-138.n.club-internet.fr [194.158.109.138]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 56F9C195F for ; Fri, 7 Dec 2001 19:50:07 +0100 (CET) Message-ID: <3C1163AA.FCE1D041@ifrance.com> Date: Fri, 07 Dec 2001 19:49:46 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] System C References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N http://www.systemc.org/ Somebody knews something about it ? It's a c++ class for hardware and system design. You can download all the classes but i don't know if this class could be classified free. It's compile with g++. Is it possible that somebody analyse the licence... I don't know what to think about. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 8 01:50:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CT76-0000G5-00 for ; Fri, 07 Dec 2001 23:05:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Dec 2001 23:05:00 +0100 (CET) Received: (qmail 7535 invoked by uid 0); 7 Dec 2001 18:51:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 7 Dec 2001 18:51:06 -0000 Received: by moria.seul.org (Postfix) id 9119D146824; Fri, 7 Dec 2001 13:51:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 83F04146823; Fri, 7 Dec 2001 13:51:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 336DE14681E for ; Fri, 7 Dec 2001 13:51:06 -0500 (EST) Received: from ifrance.com (vlt6-138.n.club-internet.fr [194.158.109.138]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2E2901746 for ; Fri, 7 Dec 2001 19:51:04 +0100 (CET) Message-ID: <3C1163E4.EDC623A9@ifrance.com> Date: Fri, 07 Dec 2001 19:50:44 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Is there an url about the fcpu simulator ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 7 20:14:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CVbE-0002FX-00 for ; Sat, 08 Dec 2001 01:44:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Dec 2001 01:44:16 +0100 (CET) Received: (qmail 5560 invoked by uid 0); 7 Dec 2001 22:30:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Dec 2001 22:30:26 -0000 Received: by moria.seul.org (Postfix) id B0C5414681A; Fri, 7 Dec 2001 17:30:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A7C97146822; Fri, 7 Dec 2001 17:30:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id EA67C14681A for ; Fri, 7 Dec 2001 17:30:20 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00651; Fri, 7 Dec 2001 20:14:07 +0100 Message-ID: <20011207201407.55653@thrai.stud.uni-hannover.de> Date: Fri, 7 Dec 2001 20:14:07 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DivMod unit References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1007745947.3c10fb9b7cf62@imp.free.fr>; from Cedric BAIL on Fri, Dec 07, 2001 at 06:25:47PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Dec 07, 2001 at 06:25:47PM +0100, Cedric BAIL wrote: [...] > > I've been playing with the SRT approach for quite a while, and my > > conclusion was to stick with radix-2 (one result bit at a time). > > You won't be able to calculate 2 or more bits in one F-CPU (6 gate) > > pipeline stage, and the decision logic becomes much more complex > I don't understood the problem, the division is not signed, so were is the > problem with pipeline stage ? In a SRT divider, the remainder is signed (that is, it may have a negative value while the operation hasn't finished) even if the operands themselves aren't. But the real problem is that you have to fit too many things into a single stage. For radix-2, the list contains: #1 - input selector (for looping) #2 - decision logic #3 - divisor selection (positive, negative or zero) #4 - 3-operand adder (a row of full adders, normally) where all subunits depend on the one before. You may get away with duplicating #4, moving #3 to the end of the stage (making it a result selector), and merging it with the input mux of the "next" stage. But even then you'll have a 4:1 mux and at least four gates (including two XOR gates, which are slower than AND/OR) in the critical data path, which is already pretty close to the 6-gate limit. In a radix-4 divider, both #2 and #4 won't fit into a single stage any longer. You'll have to split the core into two separate stages, but that is nonsense -- why add extra circuitry to calculate 2 bits every other cycle if you can calculate 1 bit per cycle with less effort? [...] > > > An other things, I am currently looking to the divider unit (idiv.vhdl). > > > And I thing that it's possible to do 8, 16, 32 and 64bits divisions in > > > parallel. > > > Yes and no. You can do e.g. 8-but divisions with a 32-bit divider > > (just set the unused bits to zero), but it seems to be impossible (within > > the scope of the F-CPU) to split the divider and let both halves operate > > independently, because the split logic will increase the delay too > > much. > So, if i correctly understand this, this is not the solution, right ? ;-) Right -- unless you (or anybody else) can build a "split" SRT stage that fits into a single stage. > I currently instantiate 8 * 8bits divider, 4 * 16bits divider and so on. So > we can use them in parallel. I dont know how it increase the size of the unit > compared to the reuse of 32bits divider. > > > I proposed a solution a while ago (YG said it was "crayzee as usual"), > > but it requires a lot of code duplication (150% overhead, compared to > > a "straight" 64-bit divider). > And what is the solution ? I am really interested by it. I planned to re-use the wide units for smaller chunks. That is, the 64-bit divider also handles the uppermost chunk in all SIMD modes, and separate (smaller) units handle the rest. All you need is a 64-bit divider, a 32-bit divider, two 16-bit and four 8-bit ones (that's where the 150% overhead come from, btw). If we label the units like this: A : 64-bit unit B : 32-bit unit C-D : 16-bit units E-H : 8-bit units the operand bytes will be handled this way: 76543210 | =========#======= AAAAAAAA | 64-bit AAAABBBB | 32-bit AACCBBDD | 16-bit AECFBGDH | 8-bit Compared to "full" duplication, this saves one 32-bit unit, two 16-bit and four 8-bit ones. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 8 01:25:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16CVf2-0002G0-00 for ; Sat, 08 Dec 2001 01:48:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Dec 2001 01:48:12 +0100 (CET) Received: (qmail 31300 invoked by uid 0); 8 Dec 2001 00:22:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 8 Dec 2001 00:22:31 -0000 Received: by moria.seul.org (Postfix) id 4537514681A; Fri, 7 Dec 2001 19:22:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 28236146822; Fri, 7 Dec 2001 19:22:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E499C14681A for ; Fri, 7 Dec 2001 19:22:29 -0500 (EST) Received: from f-cpu.org (kdl16-15.n.club-internet.fr [213.44.18.15]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E3D4F1689 for ; Sat, 8 Dec 2001 01:22:27 +0100 (CET) Message-ID: <3C115DEB.4A32460A@f-cpu.org> Date: Sat, 08 Dec 2001 01:25:15 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Is there an url about the fcpu simulator ? i don't remember where there is one. some attemps have been done in the past but nothing successfull. btw, my current direction is to simply use the VHDL simulations, so we can have a cycle-acurate performance analysis without any code duplication (at the cost of performance but we don't aim real-time simulations yet). Our VHDL tools are flexible enough for this task, and C simulators can become overly complex and miss some HW-related problems (like, hmm, you write "+" and it ends up eating 2 cycles for nothing, or stuff like that). -o-O-o- Another topic : http://asim.lip6.fr/education/dea/stages/ i am in the "system" section and i will try to get the subject either on the VCI interface or the FPU generator. Guess why ;-) If i could over-pipeline the FPU, it would be even better ;-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Dec 8 15:26:35 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Cv14-0005c0-00 for ; Sun, 09 Dec 2001 04:52:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Dec 2001 04:52:38 +0100 (CET) Received: (qmail 14454 invoked by uid 0); 8 Dec 2001 20:03:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 8 Dec 2001 20:03:00 -0000 Received: by moria.seul.org (Postfix) id F227C1467FF; Sat, 8 Dec 2001 15:02:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E528E146830; Sat, 8 Dec 2001 15:02:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a174.home.uni-hannover.de [130.75.232.174]) by moria.seul.org (Postfix) with ESMTP id 23A1B1467FF for ; Sat, 8 Dec 2001 15:02:51 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00573; Sat, 8 Dec 2001 15:26:35 +0100 Message-ID: <20011208152635.44101@thrai.stud.uni-hannover.de> Date: Sat, 8 Dec 2001 15:26:35 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> <3C115DEB.4A32460A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C115DEB.4A32460A@f-cpu.org>; from Yann Guidon on Sat, Dec 08, 2001 at 01:25:15AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 08, 2001 at 01:25:15AM +0100, Yann Guidon wrote: > nicO wrote: > > Is there an url about the fcpu simulator ? > i don't remember where there is one. > some attemps have been done in the past but > nothing successfull. I started to write an emulator as a counterpart to my F-CPU assembler (for testing, porting and so on), but I was interrupted somehow and found myself coding in VHDL again ;) > btw, my current direction is to simply use > the VHDL simulations, so we can have a cycle-acurate > performance analysis without any code duplication > (at the cost of performance but we don't aim > real-time simulations yet). Our VHDL tools are > flexible enough for this task, and C simulators > can become overly complex and miss some HW-related > problems (like, hmm, you write "+" and it ends up > eating 2 cycles for nothing, or stuff like that). That's the other side of the medal. IMHO, we need both a cycle-accurate simulator and an instruction-level emulator. The former will be used for studying, debugging and improving the design, the latter supports early software development, and it probably also helps cleaning up the instruction set, clarifying open ends and so on. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Dec 8 20:32:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Cv14-0005c0-01 for ; Sun, 09 Dec 2001 04:52:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Dec 2001 04:52:38 +0100 (CET) Received: (qmail 29382 invoked by uid 0); 8 Dec 2001 20:28:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 8 Dec 2001 20:28:36 -0000 Received: by moria.seul.org (Postfix) id 6E0881467FF; Sat, 8 Dec 2001 15:28:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BA10146830; Sat, 8 Dec 2001 15:28:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 4CEE91467FF for ; Sat, 8 Dec 2001 15:28:35 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA04279 for ; Sat, 8 Dec 2001 13:28:33 -0700 (MST) Message-ID: <3C126AC9.927F6D5A@jetnet.ab.ca> Date: Sat, 08 Dec 2001 12:32:25 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> <3C115DEB.4A32460A@f-cpu.org> <20011208152635.44101@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > That's the other side of the medal. IMHO, we need both a cycle-accurate > simulator and an instruction-level emulator. The former will be used > for studying, debugging and improving the design, the latter supports > early software development, and it probably also helps cleaning up the > instruction set, clarifying open ends and so on. Are their any tools to keep things in sync? The last thing you need is two really different versions of the hardware description. -- Ben Franchuk --- Pre-historic Cpu's -- www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 9 17:50:01 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16D8sr-0000Fr-01 for ; Sun, 09 Dec 2001 19:41:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Dec 2001 19:41:05 +0100 (CET) Received: (qmail 18772 invoked by uid 0); 9 Dec 2001 10:50:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 9 Dec 2001 10:50:16 -0000 Received: by moria.seul.org (Postfix) id B9EC5146820; Sun, 9 Dec 2001 05:50:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FEA6146831; Sun, 9 Dec 2001 05:50:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 474FD146820 for ; Sun, 9 Dec 2001 05:50:15 -0500 (EST) Received: from ifrance.com (vlt11-123.n.club-internet.fr [195.36.224.123]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3AF1716B7 for ; Sun, 9 Dec 2001 11:50:13 +0100 (CET) Message-ID: <3C139639.81D93F6D@ifrance.com> Date: Sun, 09 Dec 2001 11:50:01 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> <3C115DEB.4A32460A@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > Is there an url about the fcpu simulator ? > i don't remember where there is one. > some attemps have been done in the past but > nothing successfull. > Yes, there is a graphical one in GTK !! We show me it just before HAL. It's run and is quite nice. I have it on one of your CD's. nicO > btw, my current direction is to simply use > the VHDL simulations, so we can have a cycle-acurate > performance analysis without any code duplication > (at the cost of performance but we don't aim > real-time simulations yet). Our VHDL tools are > flexible enough for this task, and C simulators > can become overly complex and miss some HW-related > problems (like, hmm, you write "+" and it ends up > eating 2 cycles for nothing, or stuff like that). > > -o-O-o- > > Another topic : > http://asim.lip6.fr/education/dea/stages/ > i am in the "system" section and i will > try to get the subject either on the VCI interface > or the FPU generator. Guess why ;-) > If i could over-pipeline > the FPU, it would be even better ;-) > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 9 16:14:36 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16D8su-0000Fr-00 for ; Sun, 09 Dec 2001 19:41:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Dec 2001 19:41:08 +0100 (CET) Received: (qmail 16244 invoked by uid 0); 9 Dec 2001 15:11:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Dec 2001 15:11:51 -0000 Received: by moria.seul.org (Postfix) id 5DDEC1467F8; Sun, 9 Dec 2001 10:11:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 252E9146808; Sun, 9 Dec 2001 10:11:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 9A7481467F8 for ; Sun, 9 Dec 2001 10:11:49 -0500 (EST) Received: from f-cpu.org (kdl16-122.n.club-internet.fr [213.44.18.122]) by relay-1v.club-internet.fr (Postfix) with ESMTP id A5E991703 for ; Sun, 9 Dec 2001 16:11:46 +0100 (CET) Message-ID: <3C137FDC.32DBD3A9@f-cpu.org> Date: Sun, 09 Dec 2001 16:14:36 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> <3C115DEB.4A32460A@f-cpu.org> <20011208152635.44101@thrai.stud.uni-hannover.de> <3C126AC9.927F6D5A@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Michael Riepe wrote: > > > That's the other side of the medal. IMHO, we need both a cycle-accurate > > simulator and an instruction-level emulator. The former will be used > > for studying, debugging and improving the design, the latter supports > > early software development, and it probably also helps cleaning up the > > instruction set, clarifying open ends and so on. > > Are their any tools to keep things in sync? The last thing you need > is two really different versions of the hardware description. concerning the instruction set and a certain set of constants, there is a way to keep things synchronized. but it's only superficial : architectural changes won't be kept synch'ed with m4. i prefer to work at VHDL level : with an assembler, we can generate binaries that will be executed by the VHDL simulator itself. This is a powerful way to verify that our RTL code is valid. when the RTL code is ok, we can re-write and simplify it in C, which will be certainly much faster ... > Ben Franchuk --- Pre-historic Cpu's -- > www.jetnet.ab.ca/users/bfranchuk/index.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 10 00:12:39 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16D8sv-0000Fr-00 for ; Sun, 09 Dec 2001 19:41:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Dec 2001 19:41:09 +0100 (CET) Received: (qmail 18670 invoked by uid 0); 9 Dec 2001 17:12:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 9 Dec 2001 17:12:54 -0000 Received: by moria.seul.org (Postfix) id 5C555146808; Sun, 9 Dec 2001 12:12:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3D4DF146821; Sun, 9 Dec 2001 12:12:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id ED952146808 for ; Sun, 9 Dec 2001 12:12:52 -0500 (EST) Received: from ifrance.com (vlt11-100.n.club-internet.fr [195.36.224.100]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B4E221725 for ; Sun, 9 Dec 2001 18:12:49 +0100 (CET) Message-ID: <3C13EFE7.FF824612@ifrance.com> Date: Sun, 09 Dec 2001 18:12:39 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulator References: <1007220136.3c08f5a845efd@imp.free.fr> <20011202183912.40812@thrai.stud.uni-hannover.de> <1007645143.3c0f71d7aac7b@imp.free.fr> <20011206195128.17819@thrai.stud.uni-hannover.de> <1007745947.3c10fb9b7cf62@imp.free.fr> <3C1163E4.EDC623A9@ifrance.com> <3C115DEB.4A32460A@f-cpu.org> <20011208152635.44101@thrai.stud.uni-hannover.de> <3C126AC9.927F6D5A@jetnet.ab.ca> <3C137FDC.32DBD3A9@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > Ben Franchuk wrote: > > Michael Riepe wrote: > > > > > That's the other side of the medal. IMHO, we need both a cycle-accurate > > > simulator and an instruction-level emulator. The former will be used > > > for studying, debugging and improving the design, the latter supports > > > early software development, and it probably also helps cleaning up the > > > instruction set, clarifying open ends and so on. > > > > Are their any tools to keep things in sync? The last thing you need > > is two really different versions of the hardware description. > > concerning the instruction set and a certain set of constants, > there is a way to keep things synchronized. but it's only superficial : > architectural changes won't be kept synch'ed with m4. > > i prefer to work at VHDL level : with an assembler, we can > generate binaries that will be executed by the VHDL simulator itself. > This is a powerful way to verify that our RTL code is valid. > > when the RTL code is ok, we can re-write and simplify it in C, > which will be certainly much faster ... > Humm, it will better to do the opposite. So you can compare a golden model to your much more long and complexe VHDL code. SystemC was build for such task (cf. www.systemc.org). Does anybody have a try ? Maybe i will try to write my vison of the pipeline with it. It could much simpler to write it that way and then porting it in VHDL. nicO > > Ben Franchuk --- Pre-historic Cpu's -- > > www.jetnet.ab.ca/users/bfranchuk/index.html > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 9 22:54:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16DHvq-0007HI-00 for ; Mon, 10 Dec 2001 05:20:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Dec 2001 05:20:46 +0100 (CET) Received: (qmail 24836 invoked by uid 0); 9 Dec 2001 21:52:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 9 Dec 2001 21:52:14 -0000 Received: by moria.seul.org (Postfix) id 849A51467FA; Sun, 9 Dec 2001 16:52:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A7DB1467FC; Sun, 9 Dec 2001 16:52:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id EAFD31467FA for ; Sun, 9 Dec 2001 16:52:11 -0500 (EST) Received: from f-cpu.org (kdl1-195.n.club-internet.fr [213.44.0.195]) by relay-1v.club-internet.fr (Postfix) with ESMTP id B69E61693 for ; Sun, 9 Dec 2001 22:52:07 +0100 (CET) Message-ID: <3C13DDB0.3E0DD7F4@f-cpu.org> Date: Sun, 09 Dec 2001 22:54:56 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] about 18C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, For the 3rd year in a row, F-CPU will be present in Berlin, for the annual Chaos Computer Club meeting. For budget reasons, i am not able to go there. Nicolas and Cedric, who came with me last year, have said they will go. They have seen what happened last year and i'm confident about their ability to deal fairly with the situation :-) I hope they have bought their tickets. Several things have changed since last year : first we have nice new flags :-) People will be able to find F-CPU people in the 'hackcenter'. Do not forget to print F-CPU A4 pages to publicize for the conference. i'm currently downloading files from : http://www.itee.uq.edu.au/~peters/xsvboard/ they will be integrated in the F-CPU CD-ROM. i'll try to update it with the freshest files before nicO and Cedric spread the data. We will have to meet in France/Paris before they go to Berlin. I hope they'll meet other F-CPU contributors. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: nicO, don't forget to get me a nice T-shirt (XXXL please) and try to find a "Werner" comics book :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 11 13:09:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Dt1Z-0000Q3-00 for ; Tue, 11 Dec 2001 20:57:09 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Dec 2001 20:57:09 +0100 (CET) Received: (qmail 16412 invoked by uid 0); 11 Dec 2001 12:09:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 11 Dec 2001 12:09:53 -0000 Received: by moria.seul.org (Postfix) id 34384146847; Tue, 11 Dec 2001 07:09:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2BDD7146849; Tue, 11 Dec 2001 07:09:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from lh00.opsion.fr (lh00.opsion.fr [212.73.208.226]) by moria.seul.org (Postfix) with SMTP id 8CE93146847 for ; Tue, 11 Dec 2001 07:09:51 -0500 (EST) Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Tue, 11 Dec 2001 12:09:43 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] F-cpu pipeline From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2001 12:09:43 GMT Message-id: <200112111209.2b45@lh00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N It's a paper about the next generation AMD cpu. I suggest you to analyse the pipe. 32 stage !!! But always only one for ALU/execute stage. I know that FCPU is much simpler but it's hard to imagine to have =E0 100 stage cpu... (look at 7 fetch stages divide in 2 fetch and 2 decode compare to 1 execute) I don't say to stop making the fcpu as it was said but we shoud be more flexible for the design of the scheduler. Have a nice read ! nicO http://www.amd.com/us-en/assets/content_type/Download ableAssets/MPF_Hammer_Presentation.PDF =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 11 16:06:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Dt1e-0000Q3-00 for ; Tue, 11 Dec 2001 20:57:14 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Dec 2001 20:57:14 +0100 (CET) Received: (qmail 22027 invoked by uid 0); 11 Dec 2001 15:06:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Dec 2001 15:06:13 -0000 Received: by moria.seul.org (Postfix) id 74CCB146852; Tue, 11 Dec 2001 10:06:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 28278146855; Tue, 11 Dec 2001 10:06:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from lh00.opsion.fr (lh00.opsion.fr [212.73.208.226]) by moria.seul.org (Postfix) with SMTP id 7B240146852 for ; Tue, 11 Dec 2001 10:06:11 -0500 (EST) Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Tue, 11 Dec 2001 15:06:00 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] A place to go ? From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2001 15:06:00 GMT Message-id: <200112111506.00be@lh00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N http://www.fosdem.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 11 17:24:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Dt1j-0000Q3-00 for ; Tue, 11 Dec 2001 20:57:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Dec 2001 20:57:19 +0100 (CET) Received: (qmail 25631 invoked by uid 0); 11 Dec 2001 16:21:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 11 Dec 2001 16:21:51 -0000 Received: by moria.seul.org (Postfix) id C0E39146852; Tue, 11 Dec 2001 11:21:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA0DF146855; Tue, 11 Dec 2001 11:21:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 16D33146852 for ; Tue, 11 Dec 2001 11:21:45 -0500 (EST) Received: from f-cpu.org (kdl17-132.n.club-internet.fr [213.44.19.132]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8973C169C for ; Tue, 11 Dec 2001 17:21:40 +0100 (CET) Message-ID: <3C163345.A5DAC9D9@f-cpu.org> Date: Tue, 11 Dec 2001 17:24:37 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] illustrations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i have just uploaded a couple of pictures at http://f-cpu.seul.org/new/gifs.zip these could be useful to nicO, for example. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 11 17:29:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Dt1j-0000Q3-01 for ; Tue, 11 Dec 2001 20:57:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Dec 2001 20:57:19 +0100 (CET) Received: (qmail 26895 invoked by uid 0); 11 Dec 2001 16:26:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 11 Dec 2001 16:26:26 -0000 Received: by moria.seul.org (Postfix) id 385CD146852; Tue, 11 Dec 2001 11:26:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C173146855; Tue, 11 Dec 2001 11:26:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B6EAB146852 for ; Tue, 11 Dec 2001 11:26:24 -0500 (EST) Received: from f-cpu.org (kdl17-132.n.club-internet.fr [213.44.19.132]) by relay-1v.club-internet.fr (Postfix) with ESMTP id A4A7916B5 for ; Tue, 11 Dec 2001 17:26:18 +0100 (CET) Message-ID: <3C163457.934113BE@f-cpu.org> Date: Tue, 11 Dec 2001 17:29:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] A place to go ? References: <200112111506.00be@lh00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicolas.boulay@ifrance.com wrote: > http://www.fosdem.org/ we could check, right. who would go there ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 12 00:29:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Dxwd-0004GH-01 for ; Wed, 12 Dec 2001 02:12:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Dec 2001 02:12:23 +0100 (CET) Received: (qmail 16232 invoked by uid 0); 11 Dec 2001 23:26:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 11 Dec 2001 23:26:27 -0000 Received: by moria.seul.org (Postfix) id D4AAA1468A6; Tue, 11 Dec 2001 18:26:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C003D1468BC; Tue, 11 Dec 2001 18:26:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4D06A1468A6 for ; Tue, 11 Dec 2001 18:26:26 -0500 (EST) Received: from f-cpu.org (kdl1-3.n.club-internet.fr [213.44.0.3]) by relay-1v.club-internet.fr (Postfix) with ESMTP id CCFBD169C for ; Wed, 12 Dec 2001 00:26:23 +0100 (CET) Message-ID: <3C1696CC.E081D66@f-cpu.org> Date: Wed, 12 Dec 2001 00:29:16 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] A place to go ? References: <200112111506.00be@lh00.opsion.fr> <3C163457.934113BE@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, Yann Guidon wrote: > hi, > > nicolas.boulay@ifrance.com wrote: > > http://www.fosdem.org/ > we could check, right. > who would go there ? in the speaker's list i found : Mathias Brossard IDX-PKI: Open Source RFC-Compliant Public Key Infrastructure. does this name remember you anything ?... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Dec 14 02:42:07 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16F0fC-0000Fv-00 for ; Fri, 14 Dec 2001 23:18:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Dec 2001 23:18:42 +0100 (CET) Received: (qmail 29472 invoked by uid 0); 14 Dec 2001 01:39:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 14 Dec 2001 01:39:10 -0000 Received: by moria.seul.org (Postfix) id 2B92114681B; Thu, 13 Dec 2001 20:39:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF336146821; Thu, 13 Dec 2001 20:39:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A420214681B for ; Thu, 13 Dec 2001 20:39:08 -0500 (EST) Received: from f-cpu.org (kdl16-2.n.club-internet.fr [213.44.18.2]) by relay-2v.club-internet.fr (Postfix) with ESMTP id C44C0171B for ; Fri, 14 Dec 2001 02:39:05 +0100 (CET) Message-ID: <3C1958EF.598F76E2@f-cpu.org> Date: Fri, 14 Dec 2001 02:42:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] VHDL scripts + OT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i am currently cleaning up and updating my local F-CPU files (i'll have to burn a CD for Cedric who goes to CCC). It seems that i have missed Michael's files, or did not succeed to integrate his marvelous scripts. I presume he now has newer versions that support Simili2. Can i get them ? Almost OT : i just got a copy of the CDROM that goes along the book entitle "The anatomy of a high-performance microprocessor : a system perspective". It deals mostly with x86 clones design (nextgen, amd, cyrix) but it is VERY VERY interesting. a must-buy. On top of that, the CDROM is filled with a lot of paper reprints, most of them are "classics" (ie 2-level branch prediction or von Neumann's paper on EDVAC...) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 14 12:08:15 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16F0fg-0000Fv-00 for ; Fri, 14 Dec 2001 23:19:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Dec 2001 23:19:12 +0100 (CET) Received: (qmail 17013 invoked by uid 0); 14 Dec 2001 17:43:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 14 Dec 2001 17:43:45 -0000 Received: by moria.seul.org (Postfix) id 18A49146835; Fri, 14 Dec 2001 12:43:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 128A1146839; Fri, 14 Dec 2001 12:43:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a227.home.uni-hannover.de [130.75.232.227]) by moria.seul.org (Postfix) with ESMTP id 0B0E1146835 for ; Fri, 14 Dec 2001 12:43:42 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00420; Fri, 14 Dec 2001 12:08:15 +0100 Message-ID: <20011214120815.13361@thrai.stud.uni-hannover.de> Date: Fri, 14 Dec 2001 12:08:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] VHDL scripts + OT References: <3C1958EF.598F76E2@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C1958EF.598F76E2@f-cpu.org>; from Yann Guidon on Fri, Dec 14, 2001 at 02:42:07AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Dec 14, 2001 at 02:42:07AM +0100, Yann Guidon wrote: > i am currently cleaning up and updating > my local F-CPU files (i'll have to burn a CD for > Cedric who goes to CCC). > It seems that i have missed Michael's files, > or did not succeed to integrate his marvelous > scripts. I presume he now has newer versions > that support Simili2. Can i get them ? I'm not sure which files you mean... My latest sources are on seul (new/fcpu-mr-20011127.tar.gz). The wrapper scripts for wine are no longer needed with Simili 2, and the wrappers I use for running Simili 2 on my (kinda unusual) system obviously aren't needed anywhere else. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 17 01:53:31 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Fs8Y-0001RI-00 for ; Mon, 17 Dec 2001 08:24:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Dec 2001 08:24:34 +0100 (CET) Received: (qmail 27307 invoked by uid 0); 16 Dec 2001 18:53:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Dec 2001 18:53:14 -0000 Received: by moria.seul.org (Postfix) id 92F5A1467FD; Sun, 16 Dec 2001 13:53:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C4C2146819; Sun, 16 Dec 2001 13:53:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 9B28B1467FD for ; Sun, 16 Dec 2001 13:53:11 -0500 (EST) Received: from ifrance.com (vlt10-184.n.club-internet.fr [195.36.223.184]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B0003173B for ; Sun, 16 Dec 2001 19:53:03 +0100 (CET) Message-ID: <3C1D420B.A0EB8433@ifrance.com> Date: Sun, 16 Dec 2001 19:53:31 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] last news about licence References: <3C1958EF.598F76E2@f-cpu.org> <20011214120815.13361@thrai.stud.uni-hannover.de> <3C1CFA4B.6059789F@ifrance.com> <3C1CBE7B.C108ACE9@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > Hello everybody, > > > > I just have a big conversation about the licende issue with Mélanie > > Clément Fontaine. She's a lawyer who make a thesis about the > > applicability of the GPL to the french law. > > how did you finally succeed ? i would love to be part of the discussion :-) It's mainly by phone. She's very busy (3 weeks to reach her !!) > > > It was hard (;p) to explain all the issue of the hardware compare to the > > software. But the result are there. So the source code is protected as > > in the software world. > > As authors, it is a minimum : our copyright and author rights can be enforced > and the project is protected. > > > There is also a protection on the mask file > > (GDS2) because you could only produice it with the previous code. So > > using GS2 file to by pass the licence, isn't really possible. > > this is where the story is getting more complex, right... > > > So if we use the GPL it's impossible to mix it with proprietary > > code (so we can't distribut it as an ip). > i thought that GPL was good only for software ? so the linking mechanisms > and some definitions of the GPL don't apply. > It's apply the same. It's about source code which produice binaries which describe hardware. So hardware is behind this step and does not bother us. > > If we use the LGPL, it's possible (as for library) to use with other > > type of code. > i am not particularly fond of this solution, as others know. > LGPL is often understood as "weak" GPL and it can be perceived as > a wrong signal. > Yep, but in software world. There is no OS in hardware. > let's remember that F-CPU was not started as an "IP core project" > in the beginning btw. > > > Or we can create all knew licence, with the definition of interface > > (API). But we will have problem to write it without a lawyer. > i prefer this way. This will be the occasion to define everything > in the right context and probably start from a new, non-GNU, ground. > One more ? I think there is far too much open sources licence and i beleive that's not a good point to write a good one one more time. I find 2 new licences ( www.systemc.org and www.testbuilder.org ) for tools for hardware design (c++ class) but i can't say if it's really free or BSD-like or MS-like. It will be the same for new comer : try to understand what is really our licence. > > As you should know i prefer to use a licence to distribut the fcpu as an IP. > can you be more precise about "a licence" ? > The right that you give to the other (GPL said some thing as : "i give you the same right as me but you take away my own right.") > > So i suggest to translate our current licence to LPGL. It's possible > > because only Michael, Whygee and Cedric had written code. They own the > > copyright on there code. So there knew code version could use LGPL > > licence. > > I do not think that it will magically solve our problem. > What's are the remaining problem ? The bad image of the LGPL ? > > Comments ? > > it is still a hot topic :-) > thanks for restarting this discussion, > de rien ;D nicO > > nicO > WHYGEE (trying to cleanup his f-cpu source file tree) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > PS: i CC: to the hardlicense-discuss mailing list, as it might be > of interest to others. > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 16 01:47:14 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Fs7r-0001RI-00 for ; Mon, 17 Dec 2001 08:23:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Dec 2001 08:23:51 +0100 (CET) Received: (qmail 3554 invoked by uid 0); 16 Dec 2001 00:44:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 16 Dec 2001 00:44:15 -0000 Received: by moria.seul.org (Postfix) id 0DE31146866; Sat, 15 Dec 2001 19:44:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 03EC514686A; Sat, 15 Dec 2001 19:44:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id B2A79146866 for ; Sat, 15 Dec 2001 19:44:14 -0500 (EST) Received: from f-cpu.org (kdl11-39.n.club-internet.fr [213.44.9.39]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5389816B7 for ; Sun, 16 Dec 2001 01:44:12 +0100 (CET) Message-ID: <3C1BEF12.BB2CC0C6@f-cpu.org> Date: Sun, 16 Dec 2001 01:47:14 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Understanding the FC0 pipeline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, I got a copy of the CDROM that is given with the book "The Anatomy of a Microprocessor: A Systems Perspective" by Shriver and Smith. I am currently reading the pile of paper re-prints including a lot of crucial and interesting stuff from the IEEE. I'm currently reading a paper from James E. Smith, written in 1985 while working for CDC on the CYBER 180/990. It deals with precise exception in an out-of-order completion pipelined machine and it will certainly be of greatest interest to nicolas because it also describes the scheduler which is almost identical to this in FC0. However it was written nearly 15 years before FC0 started and the principle is still the same :-) Note that some method diverge after a few pages, because we deal with precise exceptions (principally page miss) in a different way (split address computation and data fetch intructions). But it's funny anyway to read a nearly FC0 description from a CDC guy :-) They call "result shift register" what i call "scheduler queue" (or something like that). The difference is that FC0 has 2 result buses but the flags are the same : (here i copy from the paper) - "functional unit source" (it commands the MUX that selects which EU writes to the corresponding bus) - "Destination register" (it commands the register set's write address) - "valid bit" which says whether a "slot" is free or not. It even adds a new data which points to a sophisticated reordering table for renaming, but it's only at the end of the paper. I love reading those old papers : even though i tend to reinvent the wheel, at least it recomforts me in seeing that i was not obviously wrong :-) I am experiencing troubles uploading the PDF on the seul.org server at http://f-cpu.seul.org/new. This paper will also be on the CCC F-CPU CDROM. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 16 20:47:24 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Fs8H-0001RI-00 for ; Mon, 17 Dec 2001 08:24:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Dec 2001 08:24:17 +0100 (CET) Received: (qmail 23459 invoked by uid 0); 16 Dec 2001 13:47:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 16 Dec 2001 13:47:02 -0000 Received: by moria.seul.org (Postfix) id 1BCBD1467EF; Sun, 16 Dec 2001 08:47:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E3BC61467FD; Sun, 16 Dec 2001 08:47:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id F09541467EF for ; Sun, 16 Dec 2001 08:46:59 -0500 (EST) Received: from ifrance.com (vlt11-153.n.club-internet.fr [195.36.224.153]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 790A41784 for ; Sun, 16 Dec 2001 14:46:56 +0100 (CET) Message-ID: <3C1CFA4B.6059789F@ifrance.com> Date: Sun, 16 Dec 2001 14:47:24 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] last news about licence References: <3C1958EF.598F76E2@f-cpu.org> <20011214120815.13361@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello everybody, I just have a big conversation about the licende issue with Mélanie Clément Fontaine. She's a lawyer who make a thesis about the applicability of the GPL to the french law. It was hard (;p) to explain all the issue of the hardware compare to the software. But the result are there. So the source code is protected as in the software world. There is also a protection on the mask file (GDS2) because you could only produice it with the previous code. So using GS2 file to by pass the licence, isn't really possible. So if we use the GPL it's impossible to mix it with proprietary code (so we can't distribut it as an ip). If we use the LGPL, it's possible (as for library) to use with other type of code. Or we can create all knew licence, with the definition of interface (API). But we will have problem to write it without a lawyer. As you should know i prefer to use a licence to distribut the fcpu as an IP. So i suggest to translate our current licence to LPGL. It's possible because only Michael, Whygee and Cedric had written code. They own the copyright on there code. So there knew code version could use LGPL licence. Comments ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 16 16:32:11 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Fs8M-0001RI-01 for ; Mon, 17 Dec 2001 08:24:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Dec 2001 08:24:22 +0100 (CET) Received: (qmail 29447 invoked by uid 0); 16 Dec 2001 15:29:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 16 Dec 2001 15:29:15 -0000 Received: by moria.seul.org (Postfix) id 827871467F6; Sun, 16 Dec 2001 10:29:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 18271146812; Sun, 16 Dec 2001 10:29:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 941DE1467F6; Sun, 16 Dec 2001 10:29:12 -0500 (EST) Received: from f-cpu.org (kdl21-247.n.club-internet.fr [213.44.96.247]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 56CEB1709; Sun, 16 Dec 2001 16:29:09 +0100 (CET) Message-ID: <3C1CBE7B.C108ACE9@f-cpu.org> Date: Sun, 16 Dec 2001 16:32:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Cc: "hardlicense-discuss@seul.org" Subject: Re: [f-cpu] last news about licence References: <3C1958EF.598F76E2@f-cpu.org> <20011214120815.13361@thrai.stud.uni-hannover.de> <3C1CFA4B.6059789F@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > Hello everybody, > > I just have a big conversation about the licende issue with Mélanie > Clément Fontaine. She's a lawyer who make a thesis about the > applicability of the GPL to the french law. how did you finally succeed ? i would love to be part of the discussion :-) > It was hard (;p) to explain all the issue of the hardware compare to the > software. But the result are there. So the source code is protected as > in the software world. As authors, it is a minimum : our copyright and author rights can be enforced and the project is protected. > There is also a protection on the mask file > (GDS2) because you could only produice it with the previous code. So > using GS2 file to by pass the licence, isn't really possible. this is where the story is getting more complex, right... > So if we use the GPL it's impossible to mix it with proprietary > code (so we can't distribut it as an ip). i thought that GPL was good only for software ? so the linking mechanisms and some definitions of the GPL don't apply. > If we use the LGPL, it's possible (as for library) to use with other > type of code. i am not particularly fond of this solution, as others know. LGPL is often understood as "weak" GPL and it can be perceived as a wrong signal. let's remember that F-CPU was not started as an "IP core project" in the beginning btw. > Or we can create all knew licence, with the definition of interface > (API). But we will have problem to write it without a lawyer. i prefer this way. This will be the occasion to define everything in the right context and probably start from a new, non-GNU, ground. > As you should know i prefer to use a licence to distribut the fcpu as an IP. can you be more precise about "a licence" ? > So i suggest to translate our current licence to LPGL. It's possible > because only Michael, Whygee and Cedric had written code. They own the > copyright on there code. So there knew code version could use LGPL > licence. I do not think that it will magically solve our problem. > Comments ? it is still a hot topic :-) thanks for restarting this discussion, > nicO WHYGEE (trying to cleanup his f-cpu source file tree) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: i CC: to the hardlicense-discuss mailing list, as it might be of interest to others. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 17 18:48:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GGUN-0000QE-00 for ; Tue, 18 Dec 2001 10:24:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Dec 2001 10:24:43 +0100 (CET) Received: (qmail 29421 invoked by uid 0); 17 Dec 2001 17:45:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 17 Dec 2001 17:45:43 -0000 Received: by moria.seul.org (Postfix) id 09E9414681F; Mon, 17 Dec 2001 12:45:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E782B146824; Mon, 17 Dec 2001 12:45:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A608F14681F for ; Mon, 17 Dec 2001 12:45:41 -0500 (EST) Received: from f-cpu.org (kdl2-241.n.club-internet.fr [213.44.1.241]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 7FB011695 for ; Mon, 17 Dec 2001 18:45:38 +0100 (CET) Message-ID: <3C1E2FFC.2B5056B0@f-cpu.org> Date: Mon, 17 Dec 2001 18:48:44 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] FC0's RTL scheduler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, while trying to cleanup my source tree, i saw that i couldn't make anything work :-) otherwise i have to move files around, modify configurations, check that everything is ok... too much work for my sick brain. So, i'm finally biting the first files that describe the scheduler/decoder/issue stages. i'm only sketching the first outlines now and i try to to fall too much into very low-level things... wish me luck ! I see that we have most EUs going on or done so this is the best place to work. However i still have to figure how many output ports the IMU has. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 17 19:38:53 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GGUV-0000QE-00 for ; Tue, 18 Dec 2001 10:24:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Dec 2001 10:24:51 +0100 (CET) Received: (qmail 9840 invoked by uid 0); 17 Dec 2001 23:10:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Dec 2001 23:10:42 -0000 Received: by moria.seul.org (Postfix) id D24F4146843; Mon, 17 Dec 2001 18:10:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC0F2146847; Mon, 17 Dec 2001 18:10:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a120.home.uni-hannover.de [130.75.232.120]) by moria.seul.org (Postfix) with ESMTP id 97260146843 for ; Mon, 17 Dec 2001 18:10:34 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00536; Mon, 17 Dec 2001 19:38:53 +0100 Message-ID: <20011217193853.53095@thrai.stud.uni-hannover.de> Date: Mon, 17 Dec 2001 19:38:53 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C1E2FFC.2B5056B0@f-cpu.org>; from Yann Guidon on Mon, Dec 17, 2001 at 06:48:44PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Dec 17, 2001 at 06:48:44PM +0100, Yann Guidon wrote: > while trying to cleanup my source tree, > i saw that i couldn't make anything work :-) Shit happens :) > otherwise i have to move files around, > modify configurations, check that everything > is ok... too much work for my sick brain. > So, i'm finally biting the first files > that describe the scheduler/decoder/issue stages. > i'm only sketching the first outlines now > and i try to to fall too much into very low-level > things... wish me luck ! You mean, you try NOT to fall? Good luck, then. > I see that we have most EUs going on or done > so this is the best place to work. However i still > have to figure how many output ports the IMU has. Eight -- two for each chunk size (holding the high and low parts of the double-width product). We have to reorder the result bits for the original macl/mach instructions, however. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 18 15:31:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GWru-0000PI-00 for ; Wed, 19 Dec 2001 03:54:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 03:54:06 +0100 (CET) Received: (qmail 15925 invoked by uid 0); 18 Dec 2001 14:27:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 18 Dec 2001 14:27:59 -0000 Received: by moria.seul.org (Postfix) id BA738146808; Tue, 18 Dec 2001 09:27:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D710146832; Tue, 18 Dec 2001 09:27:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 672AC146808 for ; Tue, 18 Dec 2001 09:27:57 -0500 (EST) Received: from f-cpu.org (kdl21-190.n.club-internet.fr [213.44.96.190]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 065E11722 for ; Tue, 18 Dec 2001 15:27:55 +0100 (CET) Message-ID: <3C1F5326.2F15C402@f-cpu.org> Date: Tue, 18 Dec 2001 15:31:02 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Mon, Dec 17, 2001 at 06:48:44PM +0100, Yann Guidon wrote: > > while trying to cleanup my source tree, > > i saw that i couldn't make anything work :-) > Shit happens :) but why to me ? :-) > > otherwise i have to move files around, > > modify configurations, check that everything > > is ok... too much work for my sick brain. > > So, i'm finally biting the first files > > that describe the scheduler/decoder/issue stages. > > i'm only sketching the first outlines now > > and i try to to fall too much into very low-level > > things... wish me luck ! > You mean, you try NOT to fall? yup, 'xcuz, > Good luck, then. it seem to work :-) well, i am just writing stuff without much testing, but the overall structure is not too difficult : i think that i can make it. Using RTL description is not so difficult compared to behavioural because there are a lot of parallel things that are going on. Writing the QDCPOC this summer has helped me, but i finally prefer to use VHDL :-))) > > I see that we have most EUs going on or done > > so this is the best place to work. However i still > > have to figure how many output ports the IMU has. > Eight -- two for each chunk size (holding the high and low parts of > the double-width product). We have to reorder the result bits for the > original macl/mach instructions, however. can you be more precise ? does that mean that : 8-bits -> 2 cycles 16-bits -> 4 cycles 32-bits -> 6 cycles 64-bits -> 8 cycles plus an additional cycle for mach/macl ? Thanks for the answer, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fender@ecf.utoronto.ca Tue Dec 18 19:02:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GWsQ-0000PI-01 for ; Wed, 19 Dec 2001 03:54:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 03:54:38 +0100 (CET) Received: (qmail 25598 invoked by uid 0); 18 Dec 2001 18:02:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Dec 2001 18:02:36 -0000 Received: by moria.seul.org (Postfix) id 91A46146869; Tue, 18 Dec 2001 13:02:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4FD6414686C; Tue, 18 Dec 2001 13:02:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by moria.seul.org (Postfix) with ESMTP id C1185146869 for ; Tue, 18 Dec 2001 13:02:33 -0500 (EST) Received: from p22.ecf (p22.ecf [128.100.8.82]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id NAA08982 for ; Tue, 18 Dec 2001 13:02:28 -0500 Received: from localhost (fender@localhost) by p22.ecf (8.9.3/8.9.3) with ESMTP id NAA28829 for ; Tue, 18 Dec 2001 13:02:28 -0500 X-Authentication-Warning: p22.ecf: fender owned process doing -bs Date: Tue, 18 Dec 2001 13:02:28 -0500 (EST) From: Josh Fender X-X-Sender: To: fm Subject: [f-cpu] Synthesis Results In-Reply-To: <3C1E2FFC.2B5056B0@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Sorry about the slow results on the synthesized speed results but the system I use to synthesize has been very busy. I successfully synthesized both the eu_asu and the eu_shl, although it was more difficult then YG ROP unit. Some of the pragma statments had to be removed for synplicity to compile the VHDL files, but other then this change, the VHDL code compiled without difficulty. The timing results were a little more difficult to deal with. The shuffler unit reported in the neighbourhood of 40MHz. This number can be directly compared with my previous results for the ROP unit. The Adder results were not as clear cut. Due to the use of clocks on some signals, and not on others, my timing tool found several clock paths. These paths had timings between 10-40MHz. These numbers mean very little as I did not have the time to examine the vhdl files in detail to understand the different clocking methods. The multiplier was the main cause for my delays. I needed to find a timeblock of about 16 hours to synthesize it. Unfortunately my synthesizer crashed when it tried to dump the results (after 16 hours) so I don't have complete information. What I could extract was that the synthesizer predicts that the circuit will run at 17MHz. (I have found this number is accurate for most circuits assuming the FPGA isn't to congested). And from examining the EDF output file it appears that the multiplier uses > 30000 4 input LUTS. Obviously this multiplier is too big for an affordable FPGA implementation. A reasonable speed grade of an FPGA this big will run around $2000US. Overall I didn't learn much about the multiplier. To get more accurate results input and output registers for all signals need to be added and the EU resynthesized. Perhaps if I find more time in the future I will attempt it, but for now I am too busy. - Josh Fender ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Dec 18 21:49:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GWsX-0000PI-00 for ; Wed, 19 Dec 2001 03:54:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 03:54:45 +0100 (CET) Received: (qmail 31088 invoked by uid 0); 18 Dec 2001 23:00:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Dec 2001 23:00:20 -0000 Received: by moria.seul.org (Postfix) id 0512E14683D; Tue, 18 Dec 2001 18:00:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 99D1114686D; Tue, 18 Dec 2001 18:00:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a170.home.uni-hannover.de [130.75.232.170]) by moria.seul.org (Postfix) with ESMTP id E1E5D14683D for ; Tue, 18 Dec 2001 18:00:13 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00800; Tue, 18 Dec 2001 21:49:37 +0100 Message-ID: <20011218214937.25006@thrai.stud.uni-hannover.de> Date: Tue, 18 Dec 2001 21:49:37 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C1F5326.2F15C402@f-cpu.org>; from Yann Guidon on Tue, Dec 18, 2001 at 03:31:02PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Dec 18, 2001 at 03:31:02PM +0100, Yann Guidon wrote: > > > I see that we have most EUs going on or done > > > so this is the best place to work. However i still > > > have to figure how many output ports the IMU has. > > Eight -- two for each chunk size (holding the high and low parts of > > the double-width product). We have to reorder the result bits for the > > original macl/mach instructions, however. > can you be more precise ? > > does that mean that : > 8-bits -> 2 cycles > 16-bits -> 4 cycles > 32-bits -> 6 cycles > 64-bits -> 8 cycles > plus an additional cycle for mach/macl ? 8-bit low part -> 3 cycles 8-bit high part -> 4 cycles 16-bit low part -> 4 cycles 16-bit high part -> 5 cycles 32-bit low part -> 5 cycles 32-bit high part -> 5 cycles 64-bit low part -> 6 cycles 64-bit high part -> 6 cycles mach/macl work at the same speed, but the results don't appear at the bit positions that are documented in the manual. In the manual, there is a difference between mul and mac modes -- mul(h) places the high part of every result chunk in the secondary destination register, while mac[lh] pastes high and low parts together, doubling the chunk size of the result, and then selects one half of the result and puts it into the primary destination register (the secondary reg is never used). The final chunk-shuffling for mach/macl is currently not implemented (it can be handled by adding extra output ports for mach/macl, or by reordering the chunks in the Xbar, whichever is cheaper). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 19 03:56:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16GdoZ-0005Bb-01 for ; Wed, 19 Dec 2001 11:19:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 11:19:07 +0100 (CET) Received: (qmail 14608 invoked by uid 0); 19 Dec 2001 02:53:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 19 Dec 2001 02:53:03 -0000 Received: by moria.seul.org (Postfix) id 0C84E1467F4; Tue, 18 Dec 2001 21:53:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B810A1467FD; Tue, 18 Dec 2001 21:53:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 66B5A1467F4 for ; Tue, 18 Dec 2001 21:53:02 -0500 (EST) Received: from f-cpu.org (kdl11-165.n.club-internet.fr [213.44.9.165]) by relay-1v.club-internet.fr (Postfix) with ESMTP id A332D179B for ; Wed, 19 Dec 2001 03:52:56 +0100 (CET) Message-ID: <3C2001C6.23E0A46A@f-cpu.org> Date: Wed, 19 Dec 2001 03:56:06 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Tue, Dec 18, 2001 at 03:31:02PM +0100, Yann Guidon wrote: > > > > > I see that we have most EUs going on or done > > > > so this is the best place to work. However i still > > > > have to figure how many output ports the IMU has. > > > Eight -- two for each chunk size (holding the high and low parts of > > > the double-width product). We have to reorder the result bits for the > > > original macl/mach instructions, however. > > can you be more precise ? > > > > does that mean that : > > 8-bits -> 2 cycles > > 16-bits -> 4 cycles > > 32-bits -> 6 cycles > > 64-bits -> 8 cycles > > plus an additional cycle for mach/macl ? > > 8-bit low part -> 3 cycles > 8-bit high part -> 4 cycles > 16-bit low part -> 4 cycles > 16-bit high part -> 5 cycles > 32-bit low part -> 5 cycles > 32-bit high part -> 5 cycles > 64-bit low part -> 6 cycles > 64-bit high part -> 6 cycles > > mach/macl work at the same speed, but the results don't appear at > the bit positions that are documented in the manual. In the manual, > there is a difference between mul and mac modes -- mul(h) places the > high part of every result chunk in the secondary destination register, > while mac[lh] pastes high and low parts together, doubling the chunk > size of the result, and then selects one half of the result and puts it > into the primary destination register (the secondary reg is never used). > The final chunk-shuffling for mach/macl is currently not implemented > (it can be handled by adding extra output ports for mach/macl, or by > reordering the chunks in the Xbar, whichever is cheaper). maybe we can "cheat" with the scheduler : swap the register number, instead of the data, and validate one or another ? it can save one cycle at the "cost" of missing some issue opportunities but they can be recovered with a careful coding uideline. what do you think ? And can you explain a bit how the output ports work ? how many do you need ? And what about the normal operations ? (mul) I'm currently too lazy to read all your code, i hope you understand ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: big thank to Josh for his recent synthesis run ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 19 14:41:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Gkof-0000G6-01 for ; Wed, 19 Dec 2001 18:47:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 18:47:41 +0100 (CET) Received: (qmail 16866 invoked by uid 0); 19 Dec 2001 13:41:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 19 Dec 2001 13:41:27 -0000 Received: by moria.seul.org (Postfix) id 890861463AB; Wed, 19 Dec 2001 08:41:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5EF9B1467F8; Wed, 19 Dec 2001 08:41:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from lh00.opsion.fr (lh00.opsion.fr [212.73.208.226]) by moria.seul.org (Postfix) with SMTP id 83A8D1463AB for ; Wed, 19 Dec 2001 08:41:24 -0500 (EST) Received: from 10.1.1.6 [10.1.1.6] by lh00.opsion.fr; Wed, 19 Dec 2001 13:41:13 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Tr:18C3 From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Dec 2001 13:41:13 GMT Message-id: <200112191341.0dfa@lh00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: "ron (18C3 crew)" Date: 19/12/01 Objet: 18C3 Hi, thanks for your willingness to do a lecture at the 18C3! your lecture F-CPU Development status report is scheduled for=20 third day, Saturday,=20 10:00 hours,=20 1 hour(s) Workshopraum 2 the schedule could change in the next days by a hour sooner / later. For our web site, we need from you: - public email address - homepage link - short CV Same goes for your collegue Cedric B. Thanks & regards, ron 18C3 crew =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 19 17:13:00 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Gkok-0000G6-00 for ; Wed, 19 Dec 2001 18:47:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Dec 2001 18:47:46 +0100 (CET) Received: (qmail 14285 invoked by uid 0); 19 Dec 2001 16:13:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Dec 2001 16:13:04 -0000 Received: by moria.seul.org (Postfix) id 6CE911467F3; Wed, 19 Dec 2001 11:13:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E445146800; Wed, 19 Dec 2001 11:13:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id 92E2D1467F3 for ; Wed, 19 Dec 2001 11:13:02 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-1m.club-internet.fr (Postfix) with SMTP id BDF1516F4; Wed, 19 Dec 2001 17:13:00 +0100 (CET) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] FC0's RTL scheduler Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Dec 2001 17:13:00 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i redirect your answer to the right address ;-) >De: nicolas.boulay=40ifrance.com >A: > >De: Yann Guidon >A: f-cpu=40seul.org >Date: 19/12/01 >Objet: Re: =5Bf-cpu=5D FC0's RTL scheduler > >hi =21 > >Michael Riepe wrote: >> On Tue, Dec 18, 2001 at 03:31:02PM +0100, Yann >Guidon wrote: >> = >> > > > I see that we have most EUs going on or done >> > > > so this is the best place to work. However i still >> > > > have to figure how many output ports the IMU has. >> > > Eight -- two for each chunk size (holding the high and low parts of >> > > the double-width product). We have to reorder the result bits for t= he >> > > original macl/mach instructions, however. >> > can you be more precise ? >> > >> > does that mean that : >> > 8-bits -> 2 cycles >> > 16-bits -> 4 cycles >> > 32-bits -> 6 cycles >> > 64-bits -> 8 cycles >> > plus an additional cycle for mach/macl ? >> = >> 8-bit low part -> 3 cycles >> 8-bit high part -> 4 cycles >> 16-bit low part -> 4 cycles >> 16-bit high part -> 5 cycles >> 32-bit low part -> 5 cycles >> 32-bit high part -> 5 cycles >> 64-bit low part -> 6 cycles >> 64-bit high part -> 6 cycles >> = >> mach/macl work at the same speed, but the results don't appear at >> the bit positions that are documented in the manual. In the manual, >> there is a difference between mul and mac modes -- mul(h) places the >> high part of every result chunk in the secondary destination register, >> while mac=5Blh=5D pastes high and low parts together, doubling the chun= k >> size of the result, and then selects one half of the result and puts it >> into the primary destination register (the secondary reg is never used)= =2E >> The final chunk-shuffling for mach/macl is currently not implemented >> (it can be handled by adding extra output ports for mach/macl, or by >> reordering the chunks in the Xbar, whichever is cheaper). >maybe we can =22cheat=22 with the scheduler : swap the register number, > >>>>>>>>>>>>>>>>> O h yes =21 So you could support my >own ideas : the EU carry the written register adrress >(it's usefull for complexe unit as if you pipeline >the loop of the divider). But in that case, you only >need to swap adresses. let me finish the scheduler RTL code please ;-D >In other hand, we speak to transform 3r2w in 2r1w >with the trick of doubling virtually the number of >bits by regsiter (for user it change nothing for us >we will have 32 register of 128 bit with muxes to >separate it). ????????????????? > So we can use much more simple (and >quick) memory IP. ??? > Double port memory are really >common, more port need to be handmaid or realy slow. if i understand we need 3x 2W1R banks. This is going to use even more room ... i'm thinking about small chuncks which can do 3R2W, some chuncks are 8-bit wide and others are 16-bit wide, so we can control the write bit independently. >If we plane to fully synthetis it (as an IP) our cpui >will be much more popular. if we wanted to be popular, we would be at Big Brother, Star Academy or Pop Stars ;-P >nicO YG, hoping he's not completely messing everything ;-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 19 12:09:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16H35I-0000G5-00 for ; Thu, 20 Dec 2001 14:18:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Dec 2001 14:18:04 +0100 (CET) Received: (qmail 2274 invoked by uid 0); 19 Dec 2001 23:06:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Dec 2001 23:06:51 -0000 Received: by moria.seul.org (Postfix) id 7375D146801; Wed, 19 Dec 2001 18:06:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E6C6146812; Wed, 19 Dec 2001 18:06:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id 4609B146801 for ; Wed, 19 Dec 2001 18:06:38 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00456; Wed, 19 Dec 2001 12:09:09 +0100 Message-ID: <20011219120908.45949@thrai.stud.uni-hannover.de> Date: Wed, 19 Dec 2001 12:09:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C2001C6.23E0A46A@f-cpu.org>; from Yann Guidon on Wed, Dec 19, 2001 at 03:56:06AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Dec 19, 2001 at 03:56:06AM +0100, Yann Guidon wrote: [...] > maybe we can "cheat" with the scheduler : swap the register number, > instead of the data, and validate one or another ? it can save one cycle > at the "cost" of missing some issue opportunities but they can be recovered > with a careful coding uideline. what do you think ? Not sufficient. E.g. for a 16-bit operation, the result chunks come out like this: high part: 33221100 low part: 33221100 For `macl.16' the low part *should* be "11110000" ("33332222" for `mach.16'), according to the manual. That's one of the reasons why I never liked the original definition of the mac instruction. > And can you explain a bit how the output ports work ? > how many do you need ? And what about the normal operations ? You need one or two of them for each operation. The low part is used for both `mul' and `mulh', the high part for `mulh' only (and for `macl/`mach' you'll have to take both and mix them -- or I'll have to add more ports). Results always arrive on their corresponding ports, that is, 32-bit results will be available at the 32-bit outputs after 5 cycles. Due to the `forked' pipeline and the different latencies, multiple results may appear at the same time, e.g. at t=0 you may get a 64-bit result (instruction issued at t=-6), a 32-bit result (started at t=-5), and upper or lower parts of 16-bit and 8-bit computations. Of course the scheduler can avoid that if the Xbar is unable to handle the traffic. I guess I'll have to delay the 8- and 16-bit low parts by 1 cycle (to make high and low parts arrive at the same time). Otherwise, scheduling becomes a nightmare. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Dec 20 01:59:28 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16H35K-0000G5-00 for ; Thu, 20 Dec 2001 14:18:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Dec 2001 14:18:06 +0100 (CET) Received: (qmail 26637 invoked by uid 0); 20 Dec 2001 00:56:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 20 Dec 2001 00:56:23 -0000 Received: by moria.seul.org (Postfix) id 0BB2A14680D; Wed, 19 Dec 2001 19:56:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F39F7146814; Wed, 19 Dec 2001 19:56:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 8908414680D for ; Wed, 19 Dec 2001 19:56:22 -0500 (EST) Received: from f-cpu.org (kdl21-28.n.club-internet.fr [213.44.96.28]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 7863E1691 for ; Thu, 20 Dec 2001 01:56:19 +0100 (CET) Message-ID: <3C2137F0.F6A37910@f-cpu.org> Date: Thu, 20 Dec 2001 01:59:28 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Tr:18C3 References: <200112191341.0dfa@lh00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, thanks for the news ! good luck, be ready and keep cool :-) nicolas.boulay@ifrance.com wrote: > -----Message d'origine----- > De: "ron (18C3 crew)" Date: 19/12/01 > F-CPU Development status report > is scheduled for > third day, Saturday, > 10:00 hours, > 1 hour(s) > Workshopraum 2 it will be a difficult thing ! usually everybody is tired on the morning of the 3rd day. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : don't forget to take one or two T-shirts for me :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Thu Dec 20 13:50:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16HXDf-0000Fr-00 for ; Fri, 21 Dec 2001 22:28:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Dec 2001 22:28:43 +0100 (CET) Received: (qmail 7707 invoked by uid 0); 20 Dec 2001 12:49:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 20 Dec 2001 12:49:36 -0000 Received: by moria.seul.org (Postfix) id CBF0214680D; Thu, 20 Dec 2001 07:49:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C40B01467F8; Thu, 20 Dec 2001 07:49:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf05bis.bellsouth.net (mail305.mail.bellsouth.net [205.152.58.165]) by moria.seul.org (Postfix) with ESMTP id 64FBA1467E8 for ; Thu, 20 Dec 2001 07:49:33 -0500 (EST) Received: from computer ([209.215.11.36]) by imf05bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20011220125041.HMNU17507.imf05bis.bellsouth.net@computer>; Thu, 20 Dec 2001 07:50:41 -0500 Message-ID: <000d01c18954$dedd7c80$240bd7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] ERIN32 M2M Date: Thu, 20 Dec 2001 06:50:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C18922.93581040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C18922.93581040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After a considerable amount of juggling --- I have enough spare pins to = implement a pipeline depth of eight (8) which is now being accomplished. = 64 Bit Data impossible with current FPGA devices. This will give me an effective maximum clock rate of 566 MHZ. Merry Christmas to ALL. Dick Hartney ------=_NextPart_000_000A_01C18922.93581040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After a considerable amount of juggling = --- I have=20 enough spare pins to implement a pipeline depth of eight (8) which is = now being=20 accomplished.  64 Bit Data impossible with
current FPGA devices.
 
This will give me an effective maximum = clock rate=20 of
566 MHZ.
 
Merry Christmas to ALL.
 
Dick Hartney
------=_NextPart_000_000A_01C18922.93581040-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 22 01:28:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Hftx-0006Cm-00 for ; Sat, 22 Dec 2001 07:44:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 07:44:57 +0100 (CET) Received: (qmail 12815 invoked by uid 0); 22 Dec 2001 00:25:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 22 Dec 2001 00:25:17 -0000 Received: by moria.seul.org (Postfix) id CB31B14680A; Fri, 21 Dec 2001 19:25:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A8EF614680D; Fri, 21 Dec 2001 19:25:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 5E97E14680A for ; Fri, 21 Dec 2001 19:25:13 -0500 (EST) Received: from f-cpu.org (kdl21-78.n.club-internet.fr [213.44.96.78]) by relay-1v.club-internet.fr (Postfix) with ESMTP id BA6E8168C for ; Sat, 22 Dec 2001 01:25:09 +0100 (CET) Message-ID: <3C23D3A9.79C8362C@f-cpu.org> Date: Sat, 22 Dec 2001 01:28:25 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] FC0's RTL scheduler References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > > On Wed, Dec 19, 2001 at 03:56:06AM +0100, Yann Guidon wrote: > [...] > > maybe we can "cheat" with the scheduler : swap the register number, > > instead of the data, and validate one or another ? it can save one cycle > > at the "cost" of missing some issue opportunities but they can be recovered > > with a careful coding uideline. what do you think ? > > Not sufficient. E.g. for a 16-bit operation, the result chunks come out > like this: > > high part: 33221100 > low part: 33221100 > > For `macl.16' the low part *should* be "11110000" ("33332222" for > `mach.16'), according to the manual. That's one of the reasons why I > never liked the original definition of the mac instruction. if you can't make it, then don't worry : we'll modify the spec. however in some circumstances the overhead of the pack/unpack instructions that shuffle the subword can become a limiting factor... it's either one way or another and either way has limits... if we had both it would be cool :-) > > And can you explain a bit how the output ports work ? > > how many do you need ? And what about the normal operations ? > > You need one or two of them for each operation. The low part is used for > both `mul' and `mulh', the high part for `mulh' only (and for `macl/`mach' > you'll have to take both and mix them -- or I'll have to add more ports). > > Results always arrive on their corresponding ports, that is, 32-bit > results will be available at the 32-bit outputs after 5 cycles. Due to > the `forked' pipeline and the different latencies, multiple results > may appear at the same time, e.g. at t=0 you may get a 64-bit > result (instruction issued at t=-6), a 32-bit result (started at > t=-5), and upper or lower parts of 16-bit and 8-bit computations. > Of course the scheduler can avoid that if the Xbar is unable to handle > the traffic. of course. I'm dealing with that now. > I guess I'll have to delay the 8- and 16-bit low parts by 1 cycle (to > make high and low parts arrive at the same time). Otherwise, scheduling > becomes a nightmare. it IS possible and i don't think it will be a nightmare, but it will certainly be more complex. However, >from the programming point of view, it is more logical to have both results at the same time (IMHO). At the end of your design, could you please write an updated version of the programming model of the multiply unit ? (for the manual). > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 22 04:08:44 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Hftz-0006Cm-00 for ; Sat, 22 Dec 2001 07:44:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 07:44:59 +0100 (CET) Received: (qmail 22230 invoked by uid 0); 22 Dec 2001 03:05:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 22 Dec 2001 03:05:34 -0000 Received: by moria.seul.org (Postfix) id 9A4A91462FD; Fri, 21 Dec 2001 22:05:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E0AD146804; Fri, 21 Dec 2001 22:05:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 0A8B01462FD for ; Fri, 21 Dec 2001 22:05:32 -0500 (EST) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 857651692 for ; Sat, 22 Dec 2001 04:05:28 +0100 (CET) Message-ID: <3C23F93C.4F316937@f-cpu.org> Date: Sat, 22 Dec 2001 04:08:44 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] correction : no delay required for the multiplier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! while laying out the scheduler, it appeared to me that there is no need to delay one of the multiplier's outputs. The complexity is manageable in the decoder, when it comes to predict the latency. A side of the problem that i did not see is that there is no need for an additional port ! if we delay the multiplier, we'll require more HW for managing the additional instantaneous bandwidth, which is rather uncommon in real cases. I am still unsure about the difference between mac and mul (in your implementation) but i stick to the basics : we can insert up to two register writes per instructions in the scheduler queue (whatever the position). Think about the Load operations : the pointer update (addition) takes more time than transfering the data from the LSU to the register. Delaying the data load would seriously reduce the processor's performance... In the scheduler FIFO, i have two columns of N positions (N-deep FIFO) with each the following informations : - valid (1 bit) - register number (6 bits) -> used during the register write cycle - write mask (2 bits) -> used during the register write cycle - write port (3 or 4 bits) -> used during the Xbar cycle to select the data Each FIFO stage contains (for most bits) a register (that is clocked by the main clock), a few comparators (for the register numbers) and a MUX that selects either the previous stage's data OR the data coming >from the decoder's LUT. This is where it is possible to make a few sophisticated things : currently, each column can select its own destination register, write mask and write port, in independent positions from each others (still with the limit of 2 registers per instruction because one column can only insert 1 register). It is therefore possible to write one register in column 1 at cycle i and another register in column 2 at cycle j, as long as the decoder's LUT can predict i and j. Is it clear or you require a drawing ? :-) (i'm kidding, but if it's really unclear, i'm am currently drawing some stuffs that can help understand). I see the multiplier's "issue" as an unexpected solution to the Xbar port number problem :-) we could then spare 1/2 of the MUXes required for the multiplier on the Xbar ! I don't know precisely, but it would be ok to have 4 output ports for the multiplier (each with 64 bits). when two results are available in a single cycle, then two contiguous ports are used simultaneously. I am now waiting for Michael's deep explanations and ideas. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 22 20:18:19 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16HpAi-0000MP-00 for ; Sat, 22 Dec 2001 17:38:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 17:38:52 +0100 (CET) Received: (qmail 22871 invoked by uid 0); 22 Dec 2001 13:17:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 22 Dec 2001 13:17:24 -0000 Received: by moria.seul.org (Postfix) id D36181467E9; Sat, 22 Dec 2001 08:17:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 888C71467F2; Sat, 22 Dec 2001 08:17:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 003F91467E9 for ; Sat, 22 Dec 2001 08:17:21 -0500 (EST) Received: from ifrance.com (vlt11-164.n.club-internet.fr [195.36.224.164]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B5B72168F for ; Sat, 22 Dec 2001 14:17:19 +0100 (CET) Message-ID: <3C24DC7B.434A38F2@ifrance.com> Date: Sat, 22 Dec 2001 14:18:19 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Manual update References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> <3C23D3A9.79C8362C@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I reread the manual for fcpu presentation at 18c3 and i found a lot of little thing to change or discuss. How can we do that. Where is the on going latex version ? How can we do to change things ? I could imagine that i post the change to the list and then if every body agree, the personn in charge change the manual ? I know that there is a cvs somewhere. Micheal, it seems that you manage it. Or, maybe could we create an account an savannah ? To center things ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 22 16:32:25 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16HpAn-0000MP-00 for ; Sat, 22 Dec 2001 17:38:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 17:38:57 +0100 (CET) Received: (qmail 3863 invoked by uid 0); 22 Dec 2001 15:29:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 22 Dec 2001 15:29:12 -0000 Received: by moria.seul.org (Postfix) id 37A8B1467F2; Sat, 22 Dec 2001 10:29:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 16F321467F4; Sat, 22 Dec 2001 10:29:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 91BB81467F2 for ; Sat, 22 Dec 2001 10:29:10 -0500 (EST) Received: from f-cpu.org (kdl11-7.n.club-internet.fr [213.44.9.7]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 6A5BA1722 for ; Sat, 22 Dec 2001 16:29:08 +0100 (CET) Message-ID: <3C24A789.93BAF71E@f-cpu.org> Date: Sat, 22 Dec 2001 16:32:25 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual update References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> <3C23D3A9.79C8362C@f-cpu.org> <3C24DC7B.434A38F2@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > I reread the manual for fcpu presentation at 18c3 and i found a lot of > little thing to change or discuss. How can we do that. > Where is the on going latex version ? How can we do to change things ? Olivier doesn't answer my mails, i don't know why. > I could imagine that i post the change to the list and then if every > body agree, the personn in charge change the manual ? ideally, this is the procedure... > I know that there is a cvs somewhere. Micheal, it seems that you manage it. > Or, maybe could we create an account an savannah ? To center things ? i think there's already an account there but it's not used. however, the thing that matters most _now_ is the source code. a lot of things in the manual must be readjsuted, but it would take too much time to play catch-up... at least for me. i think that during this conference, you will have to concentrate more on "facts" than "theory", because now we have the chance to have more "meat" (source code) than ever. People will be less frustrated than last year. btw, did cedric give you my CD ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: merry Xmas, happy new year etc :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 22 23:03:06 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16HpAo-0000MP-00 for ; Sat, 22 Dec 2001 17:38:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 17:38:58 +0100 (CET) Received: (qmail 864 invoked by uid 0); 22 Dec 2001 16:02:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 22 Dec 2001 16:02:13 -0000 Received: by moria.seul.org (Postfix) id 624621467F7; Sat, 22 Dec 2001 11:02:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 413D41467FA; Sat, 22 Dec 2001 11:02:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id BE8051467F7 for ; Sat, 22 Dec 2001 11:02:09 -0500 (EST) Received: from ifrance.com (vlt10-238.n.club-internet.fr [195.36.223.238]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 3EDFB16AE for ; Sat, 22 Dec 2001 17:02:07 +0100 (CET) Message-ID: <3C25031A.A14970E7@ifrance.com> Date: Sat, 22 Dec 2001 17:03:06 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual update References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> <3C23D3A9.79C8362C@f-cpu.org> <3C24DC7B.434A38F2@ifrance.com> <3C24A789.93BAF71E@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > I reread the manual for fcpu presentation at 18c3 and i found a lot of > > little thing to change or discuss. How can we do that. > > Where is the on going latex version ? How can we do to change things ? > > Olivier doesn't answer my mails, i don't know why. > > > I could imagine that i post the change to the list and then if every > > body agree, the personn in charge change the manual ? > > ideally, this is the procedure... > > > I know that there is a cvs somewhere. Micheal, it seems that you manage it. > > Or, maybe could we create an account an savannah ? To center things ? > i think there's already an account there but it's not used. > > however, the thing that matters most _now_ is the source code. > a lot of things in the manual must be readjsuted, but it would take > too much time to play catch-up... at least for me. > I think that Cedric want to retake it to make it clean. Manuals are now more than 2 years old, and there are contradiction and strange thing in it. As the code, the guidelines must be much clear. > i think that during this conference, you will have to concentrate > more on "facts" than "theory", because now we have the chance to > have more "meat" (source code) than ever. People will be less frustrated > than last year. > > btw, did cedric give you my CD ? I don't think that VHDL code interrest a lot of people. There are a lot of software people so i will axed the conference about the ASM world and why we make such choice... nicO > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > PS: merry Xmas, happy new year etc :-) > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 23 03:10:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16HtOp-0003bo-00 for ; Sat, 22 Dec 2001 22:09:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Dec 2001 22:09:43 +0100 (CET) Received: (qmail 23502 invoked by uid 0); 22 Dec 2001 20:09:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 22 Dec 2001 20:09:22 -0000 Received: by moria.seul.org (Postfix) id 81A3F146804; Sat, 22 Dec 2001 15:09:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6C062146807; Sat, 22 Dec 2001 15:09:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 23C2F146804 for ; Sat, 22 Dec 2001 15:09:20 -0500 (EST) Received: from ifrance.com (vlt10-186.n.club-internet.fr [195.36.223.186]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 9220618C4 for ; Sat, 22 Dec 2001 21:09:17 +0100 (CET) Message-ID: <3C253D09.67D2F7FB@ifrance.com> Date: Sat, 22 Dec 2001 21:10:17 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] 3r2w -> 2r1w Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N We have soon speak about that. I beleive that Whygee was ok about it. But a recent post seems to say the opposite. So i propose to change all reference in the manual concerning register access as rn and rn+1 by rn with n even and rn+1. So why ? Because it became possible to have only 3 port to access the register bank instead of 5. Most of 3r2w instructions only need an access to a Rn+1 register, this add 2 complete new access port to the memory and a incrementer unit. If we align access, we can manage 128 bits data path. so in fact, each register are packed by 2. So all instruction which need more than a register will use the close one. If we want access to a single register we simply use a muxes. There is 2 main point to use less access port : -the speed of the regiter bank and -the avability of such memory. The more port you put on a memory, slower it run, that's physical. Usualy silicon foundry give memory generator for dual ported memory and nothing else (it the same for FPGA). So (as for leon), we could use 2 area of such memory to produice the 3 needed port for the memory (so we duplicat data). In fact, asking the foundry to give specific item cost a lot of money, so at least for the Fc0, i should consider that fact. I jnmy compagny they will use leon. And will never have money to ask to have multiported memory (don't even think of using array of flipflop if you want speed !!). So each EU could receive 2 128 bits data and write ONE 128 data. Write enable could be used to minimise power consumption when only one byte is written. Comments ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Dec 22 15:05:30 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9na-0001Dv-00 for ; Sun, 23 Dec 2001 15:40:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:22 +0100 (CET) Received: (qmail 20229 invoked by uid 0); 22 Dec 2001 23:05:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 22 Dec 2001 23:05:26 -0000 Received: by moria.seul.org (Postfix) id 2C6891467F4; Sat, 22 Dec 2001 18:05:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E51A0146805; Sat, 22 Dec 2001 18:05:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id 203EF1467F4 for ; Sat, 22 Dec 2001 18:05:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00676; Sat, 22 Dec 2001 15:05:30 +0100 Message-ID: <20011222150530.23102@thrai.stud.uni-hannover.de> Date: Sat, 22 Dec 2001 15:05:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] correction : no delay required for the multiplier References: <3C23F93C.4F316937@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C23F93C.4F316937@f-cpu.org>; from Yann Guidon on Sat, Dec 22, 2001 at 04:08:44AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 22, 2001 at 04:08:44AM +0100, Yann Guidon wrote: > while laying out the scheduler, it appeared to me that > there is no need to delay one of the multiplier's outputs. > The complexity is manageable in the decoder, when it comes > to predict the latency. A side of the problem that i did > not see is that there is no need for an additional port ! > if we delay the multiplier, we'll require more HW for > managing the additional instantaneous bandwidth, which > is rather uncommon in real cases. We need to delay the 8- and 16-bit low parts for macl/mach. > I am still unsure about the difference between mac and mul > (in your implementation) but i stick to the basics : > we can insert up to two register writes per instructions > in the scheduler queue (whatever the position). `mul' is 2r1w -- no second write needed, use the `low part' output for the corresponding chunk size. `mulh' is 2r2w -- same as `mul', but also write the high part to the second register. For 8- and 16-bit operations, the high part has an additional delay (+ 1 cycle). `mac' in its original (documented) form is 3r1w, but its results are scattered across both high and low parts of the IMU output (unless we route them to a third port). The alternative mac (`amac') instruction I proposed earlier is also 3r1w but otherwise equals the `mul' instruction. Its result is available at the `low part' outputs but is truncated to the chunk size. The current IMU supports this instruction, too. > Think about the Load operations : > the pointer update (addition) takes more time than transfering > the data from the LSU to the register. Delaying the data > load would seriously reduce the processor's performance... Yep. > In the scheduler FIFO, i have two columns of N positions > (N-deep FIFO) with each the following informations : > - valid (1 bit) > - register number (6 bits) -> used during the register write cycle > - write mask (2 bits) -> used during the register write cycle > - write port (3 or 4 bits) -> used during the Xbar cycle to select the data > Each FIFO stage contains (for most bits) a register (that is clocked > by the main clock), a few comparators (for the register numbers) > and a MUX that selects either the previous stage's data OR the data coming > from the decoder's LUT. > > This is where it is possible to make a few sophisticated things : > currently, each column can select its own destination register, > write mask and write port, in independent positions from each others > (still with the limit of 2 registers per instruction because one > column can only insert 1 register). It is therefore possible > to write one register in column 1 at cycle i and another register > in column 2 at cycle j, as long as the decoder's LUT can predict i and j. > > Is it clear or you require a drawing ? :-) > (i'm kidding, but if it's really unclear, i'm am currently > drawing some stuffs that can help understand). It's crystal clear :) And it looks good to me. I would probably store a pre-decoded write mask (5 bits) instead, but that's a minor issue. > I see the multiplier's "issue" as an unexpected solution > to the Xbar port number problem :-) we could then spare 1/2 of > the MUXes required for the multiplier on the Xbar ! > > I don't know precisely, but it would be ok to have 4 output > ports for the multiplier (each with 64 bits). > when two results are available in a single cycle, then > two contiguous ports are used simultaneously. The current timing may allow us to add MUXes after some of the outputs without increasing the number of stages. In particular, we could use a 4:1 mux for the low parts, and another one for the high parts, while maintaining the timing for `mulh' (4/5/5/6 cycles, depending on the chunk size). We'll lose the ability to schedule two `mul' instructions with different chunk sizes so that both results arrive at the same time, but I guess that doesn't matter much. `mach'/`macl' will need their own outputs (and 4:1 muxes). This will simplify the interface pretty much: - `mul' and `amac' use port #0 - `mulh' uses port #0 and #1 - `macl' uses port #2 - `mach' uses port #3 - all outputs have a delay of 4/5/5/6 cycles (for 8/16/32/64-bit chunks) The output mux selectors can be driven internally (by the chunk size control lines) or externally, whatever is more appropriate. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Dec 23 00:51:10 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9nc-0001Dv-01 for ; Sun, 23 Dec 2001 15:40:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:24 +0100 (CET) Received: (qmail 32514 invoked by uid 0); 22 Dec 2001 23:51:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 22 Dec 2001 23:51:16 -0000 Received: by moria.seul.org (Postfix) id 800EF1467E8; Sat, 22 Dec 2001 18:51:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EE6D146807; Sat, 22 Dec 2001 18:51:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id 85CB21467E8 for ; Sat, 22 Dec 2001 18:51:12 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00623; Sun, 23 Dec 2001 00:51:10 +0100 Message-ID: <20011223005110.32919@thrai.stud.uni-hannover.de> Date: Sun, 23 Dec 2001 00:51:10 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual update References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> <3C23D3A9.79C8362C@f-cpu.org> <3C24DC7B.434A38F2@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C24DC7B.434A38F2@ifrance.com>; from nicO on Sat, Dec 22, 2001 at 02:18:19PM -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 22, 2001 at 02:18:19PM -0500, nicO wrote: > I reread the manual for fcpu presentation at 18c3 and i found a lot of > little thing to change or discuss. How can we do that. More dark & dusty corners? ;) [...] > I know that there is a cvs somewhere. Micheal, it seems that you manage > it. Andreas set it up at gaos.org. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Dec 23 00:56:18 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9nd-0001Dv-01 for ; Sun, 23 Dec 2001 15:40:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:25 +0100 (CET) Received: (qmail 3155 invoked by uid 0); 22 Dec 2001 23:56:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 22 Dec 2001 23:56:23 -0000 Received: by moria.seul.org (Postfix) id 6CDE5146805; Sat, 22 Dec 2001 18:56:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69060146808; Sat, 22 Dec 2001 18:56:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id 8E3C4146805 for ; Sat, 22 Dec 2001 18:56:20 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00640; Sun, 23 Dec 2001 00:56:18 +0100 Message-ID: <20011223005618.20632@thrai.stud.uni-hannover.de> Date: Sun, 23 Dec 2001 00:56:18 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C253D09.67D2F7FB@ifrance.com>; from nicO on Sat, Dec 22, 2001 at 09:10:17PM -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Dec 22, 2001 at 09:10:17PM -0500, nicO wrote: > We have soon speak about that. I beleive that Whygee was ok about it. > But a recent post seems to say the opposite. > > So i propose to change all reference in the manual concerning register > access as rn and rn+1 by rn with n even and rn+1. So why ? Didn't we move to (rn; rn^1) already? That will effectively make the register bank a set of register pairs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 23 04:58:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9ne-0001Dv-00 for ; Sun, 23 Dec 2001 15:40:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:26 +0100 (CET) Received: (qmail 26549 invoked by uid 0); 23 Dec 2001 03:55:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 23 Dec 2001 03:55:42 -0000 Received: by moria.seul.org (Postfix) id 952631467FF; Sat, 22 Dec 2001 22:55:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88023146806; Sat, 22 Dec 2001 22:55:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C6C541467FF for ; Sat, 22 Dec 2001 22:55:39 -0500 (EST) Received: from f-cpu.org (kdl16-3.n.club-internet.fr [213.44.18.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5368316AC for ; Sun, 23 Dec 2001 04:55:35 +0100 (CET) Message-ID: <3C25567E.6BD0BE9C@f-cpu.org> Date: Sun, 23 Dec 2001 04:58:54 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > > We have soon speak about that. I beleive that Whygee was ok about it. > But a recent post seems to say the opposite. i think that it is not yet completely clear. > So i propose to change all reference in the manual concerning register > access as rn and rn+1 by rn with n even and rn+1. So why ? currently, i do rn and rn xor 1. this is handy and friendly when one unrolls his loop once (there is only one bit of difference between the 2 iterations of the code and no need to re-schedule all the instructions). > Because it became possible to have only 3 port to access the register > bank instead of 5. Most of 3r2w instructions only need an access to a > Rn+1 register, this add 2 complete new access port to the memory and a > incrementer unit. AFAIK there is no 3R2W instruction "as such". However this is true that the register set must sustain this rate, at least when it supports the 3R1W or the 2R2W operations. > If we align access, we can manage 128 bits data path. so in fact, each > register are packed by 2. So all instruction which need more than a > register will use the close one. If we want access to a single register > we simply use a muxes. > > There is 2 main point to use less access port : -the speed of the > regiter bank and -the avability of such memory. > > The more port you put on a memory, slower it run, that's physical. i won't contradict you on that point ;-) that's why there is one full clock cycle for the register reads. > Usualy silicon foundry give memory generator for dual ported memory and > nothing else (it the same for FPGA). So (as for leon), we could use 2 > area of such memory to produice the 3 needed port for the memory (so we > duplicat data). to be more precise, i have read that LEON uses 2 banks of 1R1W, the written data is sent to both the W ports and the R ports provide data in parallel. however, some arithmetics shows that S(2R1W) > 2*S(1R1W). > In fact, asking the foundry to give specific item cost a > lot of money, so at least for the Fc0, i should consider that fact. > > I jnmy compagny they will use leon. And will never have money to ask to > have multiported memory (don't even think of using array of flipflop if > you want speed !!). > > So each EU could receive 2 128 bits data and write ONE 128 data. Write > enable could be used to minimise power consumption when only one byte is > written. > > Comments ? there is a big problem if you can't write 2 different data (at different addresses). The 2R2W instructions are only one side of the problem and you have overlooked a detail : instructions such as "load post-incremented" (a 2R2W instruction) performs an addition and a load in parallel. The result of the load will be ready faster (3 cycle starting from the decoding stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., without even counting the TLB and the cache lookup). Do you see where it goes ? If you issue several loads in a row (say : 6), the last ones will be stalled even if all the data is ready, because your bus will not sustain the 2 writes per cycle at different addresses. It is not a solution to delay the fastest data because the situation would become even worse (you know that memory access speed is critical for computer performance). However, if you can't "pay" multiported SRAM (whatever the configuration, say 3*(2W1R)), you have the possibility to "downgrade" your implementation : you will not support any 2W operation and you will reduce the scheduler to 1 write per cycle. the other operations will have to be emulated and the performance will suffer a lot... but it is still possible. You will still be able to run "out of order completion" code but with limited features and a low tolerance for bus contention. As a side note, i'm realistic enough to see that we won't be able to "implement" the FC0 before a long time (how many years ?) so i am not concerned "directly" with this issue. This is interesting to see how we can modify the architecture with respect to this economic problem but you know that this industry evolves very quickly. Too quickly for us. my conclusion is : as long as you can sustain 2 writes per cycles, it's ok for me. Even if you have to use 4 register banks which are addressed with their 2LSB (i use the analogy with a 4-way set associative cache, so in this case there are 4 register banks of 16 registers each). 128-bit registers is not a "decent solution" IMHO : it's really too large and not useful in 80% of the cases where 2W/cycle is necessary. i hope we will be able to discuss this matter in depth. i am currently designing the scheduler so it's the right time. merry christmas everybody, btw ! > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 23 06:12:17 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9ng-0001Dv-00 for ; Sun, 23 Dec 2001 15:40:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:28 +0100 (CET) Received: (qmail 27568 invoked by uid 0); 23 Dec 2001 05:09:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Dec 2001 05:09:03 -0000 Received: by moria.seul.org (Postfix) id 9CE971467EE; Sun, 23 Dec 2001 00:09:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E490146802; Sun, 23 Dec 2001 00:09:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 26D261467EE for ; Sun, 23 Dec 2001 00:09:01 -0500 (EST) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-3v.club-internet.fr (Postfix) with ESMTP id A2165168A for ; Sun, 23 Dec 2001 06:08:57 +0100 (CET) Message-ID: <3C2567B1.A4EF668E@f-cpu.org> Date: Sun, 23 Dec 2001 06:12:17 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual update References: <3C1E2FFC.2B5056B0@f-cpu.org> <20011217193853.53095@thrai.stud.uni-hannover.de> <3C1F5326.2F15C402@f-cpu.org> <20011218214937.25006@thrai.stud.uni-hannover.de> <3C2001C6.23E0A46A@f-cpu.org> <20011219120908.45949@thrai.stud.uni-hannover.de> <3C23D3A9.79C8362C@f-cpu.org> <3C24DC7B.434A38F2@ifrance.com> <3C24A789.93BAF71E@f-cpu.org> <3C25031A.A14970E7@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > I know that there is a cvs somewhere. Micheal, it seems that you manage it. > > > Or, maybe could we create an account an savannah ? To center things ? > > i think there's already an account there but it's not used. > > > > however, the thing that matters most _now_ is the source code. > > a lot of things in the manual must be readjsuted, but it would take > > too much time to play catch-up... at least for me. > > I think that Cedric want to retake it to make it clean. does that mean he stopped working in the IDU ? > Manuals are now more than 2 years old, and there are contradiction > and strange thing in it. As the code, the guidelines must be much clear. i hope that Cedric's workload will be compatible with the time-consuming task of the manual's update. However, if he does this, i'm willing to help him from time to time, so we can discuss all 3 and clear up all the dark corners. > > i think that during this conference, you will have to concentrate > > more on "facts" than "theory", because now we have the chance to > > have more "meat" (source code) than ever. People will be less frustrated > > than last year. > > > > btw, did cedric give you my CD ? > > I don't think that VHDL code interrest a lot of people. There are a lot > of software people so i will axed the conference about the ASM world and > why we make such choice... I think that you make a mistake about the CD : it is not only source code, far from it ! it contains a lot of tools and documentations about a lot of various subjects. it also contains some "material" that could help you prepare the presentation in Berlin, such as recent illustrations. if you still have enough time, i can maybe send you my most recent .PS drawings (if my modem allows me to send emails containing binary streams...) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 23 19:19:49 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16I9ni-0001Dv-01 for ; Sun, 23 Dec 2001 15:40:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 15:40:30 +0100 (CET) Received: (qmail 26355 invoked by uid 0); 23 Dec 2001 12:18:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 23 Dec 2001 12:18:51 -0000 Received: by moria.seul.org (Postfix) id 71CD21467ED; Sun, 23 Dec 2001 07:18:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 68C4D1467F5; Sun, 23 Dec 2001 07:18:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0C8C21467ED for ; Sun, 23 Dec 2001 07:18:50 -0500 (EST) Received: from ifrance.com (vlt4-52.n.club-internet.fr [194.158.107.52]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 2392416F7 for ; Sun, 23 Dec 2001 13:18:46 +0100 (CET) Message-ID: <3C262045.4199EDAA@ifrance.com> Date: Sun, 23 Dec 2001 13:19:49 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> <3C25567E.6BD0BE9C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > > > We have soon speak about that. I beleive that Whygee was ok about it. > > But a recent post seems to say the opposite. > > i think that it is not yet completely clear. > > > So i propose to change all reference in the manual concerning register > > access as rn and rn+1 by rn with n even and rn+1. So why ? > > currently, i do rn and rn xor 1. this is handy and friendly It's not enought because you always need 5 port. > when one unrolls his loop once (there is only one bit of difference > between the 2 iterations of the code and no need to re-schedule > all the instructions). > > > Because it became possible to have only 3 port to access the register > > bank instead of 5. Most of 3r2w instructions only need an access to a > > Rn+1 register, this add 2 complete new access port to the memory and a > > incrementer unit. > > AFAIK there is no 3R2W instruction "as such". However this is > true that the register set must sustain this rate, at least when > it supports the 3R1W or the 2R2W operations. > > > If we align access, we can manage 128 bits data path. so in fact, each > > register are packed by 2. So all instruction which need more than a > > register will use the close one. If we want access to a single register > > we simply use a muxes. > > > > There is 2 main point to use less access port : -the speed of the > > regiter bank and -the avability of such memory. > > > > The more port you put on a memory, slower it run, that's physical. > i won't contradict you on that point ;-) that's why there is > one full clock cycle for the register reads. > > > Usualy silicon foundry give memory generator for dual ported memory and > > nothing else (it the same for FPGA). So (as for leon), we could use 2 > > area of such memory to produice the 3 needed port for the memory (so we > > duplicat data). > to be more precise, i have read that LEON uses 2 banks of 1R1W, > the written data is sent to both the W ports and the R ports > provide data in parallel. > Yep, ... to make a 2R1W register bank... as for us ! > however, some arithmetics shows that S(2R1W) > 2*S(1R1W). > > > In fact, asking the foundry to give specific item cost a > > lot of money, so at least for the Fc0, i should consider that fact. > > > > I jnmy compagny they will use leon. And will never have money to ask to > > have multiported memory (don't even think of using array of flipflop if > > you want speed !!). > > > > So each EU could receive 2 128 bits data and write ONE 128 data. Write > > enable could be used to minimise power consumption when only one byte is > > written. > > > > Comments ? > > there is a big problem if you can't write 2 different data > (at different addresses). The 2R2W instructions are only > one side of the problem and you have overlooked a detail : > instructions such as "load post-incremented" (a 2R2W instruction) > performs an addition and a load in parallel. The result of > the load will be ready faster (3 cycle starting from the decoding > stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., > without even counting the TLB and the cache lookup). Do you see > where it goes ? > Humm, an add slower than a load : look so odd ! Such instruction will be split at the decoder stage, one goes thought the alu, the other thought the load pipe. Load will be much (much) slower than the add, so the data will never be ready in the same time, so we could add a little delay, times to times. > If you issue several loads in a row (say : 6), the last > ones will be stalled even if all the data is ready, > because your bus will not sustain the 2 writes per cycle > at different addresses. It is not a solution to delay the > fastest data because the situation would become even worse > (you know that memory access speed is critical for computer > performance). > ??? The data will come even more slowly compare to the cor speed, so ? In an other point, i propose to add definitly the 8 register load instruction. This is a kind of preload for loop. To try to manage prefetch in x86, i can say that the timing is very complicated to have : you prefetch too early, the data could be scratch and it goes slower. If you make it too late, you add some instruction to be performed, so it goes slower... This instruction could use the SRB hardware. It will load in shunk of register ((R0)R1-R7,R8-R15,R16-R23,R24-R31,...). > However, if you can't "pay" multiported SRAM (whatever > the configuration, say 3*(2W1R)), you have the possibility to > "downgrade" your implementation : you will not support > any 2W operation and you will reduce the scheduler to 1 write > per cycle. the other operations will have to be emulated > and the performance will suffer a lot... but it is still > possible. You will still be able to run "out of order completion" > code but with limited features and a low tolerance for > bus contention. > ??? > As a side note, i'm realistic enough to see that we won't > be able to "implement" the FC0 before a long time (how many years ?) > so i am not concerned "directly" with this issue. This is interesting > to see how we can modify the architecture with respect to this > economic problem but you know that this industry evolves very quickly. > Too quickly for us. > Maybe, but will always have 20% time penalty, at least ! > my conclusion is : as long as you can sustain 2 writes per cycles, > it's ok for me. Even if you have to use 4 register banks which are > addressed with their 2LSB (i use the analogy with a 4-way set associative > cache, so in this case there are 4 register banks of 16 registers each). > 128-bit registers is not a "decent solution" IMHO : it's really too large > and not useful in 80% of the cases where 2W/cycle is necessary. > ?? Not usefull and you need 2 write ports only for one instruction: a post increment-load ! Do you remember the rules : if add 10% more silicium it must increase the speed by 10%, and i don't think that for the post incremental load. > i hope we will be able to discuss this matter in depth. > i am currently designing the scheduler so it's the right time. > I should write mine before you finish yours !! to compare. > merry christmas everybody, btw ! > The same ! nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 23 19:18:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IEJ9-0004tp-00 for ; Sun, 23 Dec 2001 20:29:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 23 Dec 2001 20:29:15 +0100 (CET) Received: (qmail 3429 invoked by uid 0); 23 Dec 2001 18:15:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Dec 2001 18:15:42 -0000 Received: by moria.seul.org (Postfix) id 3B2C21462FD; Sun, 23 Dec 2001 13:15:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2FAFB1467E9; Sun, 23 Dec 2001 13:15:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A63111462FD for ; Sun, 23 Dec 2001 13:15:40 -0500 (EST) Received: from f-cpu.org (kdl12-39.n.club-internet.fr [213.44.10.39]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 968F3180E for ; Sun, 23 Dec 2001 19:15:35 +0100 (CET) Message-ID: <3C26200F.E903B154@f-cpu.org> Date: Sun, 23 Dec 2001 19:18:55 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> <3C25567E.6BD0BE9C@f-cpu.org> <3C262045.4199EDAA@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > So i propose to change all reference in the manual concerning register > > > access as rn and rn+1 by rn with n even and rn+1. So why ? > > currently, i do rn and rn xor 1. this is handy and friendly > It's not enought because you always need 5 port. Either you have the 2 write ports, or the core (deespite the higher frequency) runs software slower because of the contention of the write bus. you have the choice... > > > Usualy silicon foundry give memory generator for dual ported memory and > > > nothing else (it the same for FPGA). So (as for leon), we could use 2 > > > area of such memory to produice the 3 needed port for the memory (so we > > > duplicat data). > > to be more precise, i have read that LEON uses 2 banks of 1R1W, > > the written data is sent to both the W ports and the R ports > > provide data in parallel. > Yep, ... to make a 2R1W register bank... as for us ! with the difference that we need 3 banks and this still does not solve the problem if you don't have 2 write ports. unless you find a better trick. i have the beginning of an idea, which is explained later in my post. > > > So each EU could receive 2 128 bits data and write ONE 128 data. Write > > > enable could be used to minimise power consumption when only one byte is > > > written. > > > > > > Comments ? > > > > there is a big problem if you can't write 2 different data > > (at different addresses). The 2R2W instructions are only > > one side of the problem and you have overlooked a detail : > > instructions such as "load post-incremented" (a 2R2W instruction) > > performs an addition and a load in parallel. The result of > > the load will be ready faster (3 cycle starting from the decoding > > stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., > > without even counting the TLB and the cache lookup). Do you see > > where it goes ? > > Humm, an add slower than a load : look so odd ! it is because "load" is the instruction, and not what it "really" does. "load" and "store" transfer data to and from the LSU. this is a _deterministic_ instruction because it goes throught the following units : - LSU - LSU alignment/shift - Xbar - R7 (Register set) (in the reverse order for "store"). i told it : forget about the other cores ! in FC0, the load and store instructions do NOT go to the memory ! it's the LSU's job and the decode stage only asks if a given pointer has the associated data ready, so if a loaded data is not ready, the instruction is stalled at the Xbar stage. On the other hand, for a load/store to work, it requires that the pointer goes through the validation and fetch process, which is completely hidden from the user, except concerning the time it takes. When updating the pointer, the other side of the "fork" goes through the following : - Dec (reads the pointer's value) - Xbar - ASU1 (compute the new pointer value) - ASU2 - TLB1 + Xbar - TLB2 + write R7 - cache and LSU lookup (may require more cycles if there's a cache miss) - allocate and update the LSU line the load/store instruction is both deterministic and exempt from exceptions inside the "execution core". When it arrives to the LSU, this unit takes the misses into account and manages the 8 buffers. It communicates with the decoder with flags that indicate if data is ready or not, or if a register has been validated as a pointer. This way, we can fire the TLB misses only at decode/xbar stage. > Such instruction will be split at the decoder stage, one goes thought > the alu, the other thought the load pipe. Load will be much (much) > slower than the add, so the data will never be ready in the same time, > so we could add a little delay, times to times. read above : there is no "load pipe", at least in the sense that you know for other CPUs. of course, accessing the memory is slower than doing an addition, but it is in the OTHER branch of the pipe. Otherwise, if your "load pipe" contains the TLB lookup, you introduce the possibility of an exception firing in the pipeline, while our design goal is to avoid it completely. > > If you issue several loads in a row (say : 6), the last > > ones will be stalled even if all the data is ready, > > because your bus will not sustain the 2 writes per cycle > > at different addresses. It is not a solution to delay the > > fastest data because the situation would become even worse > > (you know that memory access speed is critical for computer > > performance). > ??? The data will come even more slowly compare to the cor speed, so ? i will make you a little drawing so you can understand. in the last example, i assume that all the requested data is already present in the LSU's buffer (a kind of L0 cache and reorder buffer which contains 8*32 bytes). > In an other point, i propose to add definitly the 8 register load > instruction. ???? this means that you transfer 8*64=512 bits at once, while our maximal internal bus width is 256 bits currently ! > This is a kind of preload for loop. To try to manage prefetch in x86, i > can say that the timing is very complicated to have : you prefetch too > early, the data could be scratch and it goes slower. If you make it too > late, you add some instruction to be performed, so it goes slower... there is already a prefetch instruction in the f-cpu manual IIRC. > This instruction could use the SRB hardware. It will load in shunk of > register ((R0)R1-R7,R8-R15,R16-R23,R24-R31,...). why do you want to mix prefetch and register load ? i really don't understand your intention. remark that on another side, the LSU is also in charge of recognizing "memory streams", it will issue contiguous memory fetches if it sees that several contiguous fetches have triggered cache misses in the past. > > However, if you can't "pay" multiported SRAM (whatever > > the configuration, say 3*(2W1R)), you have the possibility to > > "downgrade" your implementation : you will not support > > any 2W operation and you will reduce the scheduler to 1 write > > per cycle. the other operations will have to be emulated > > and the performance will suffer a lot... but it is still > > possible. You will still be able to run "out of order completion" > > code but with limited features and a low tolerance for > > bus contention. > > ??? in simpler words : with only 1 write port (even if it's 128-bit wide) you won't be able to execute the following instruction chunck : add r1,r2,r3 and r4,r5,r6 because the add operates in 2 cycles and and is 1 cycle, it will create a contention ("hazard" if you prefer) on the write bus. the scheduler will have to delay the AND. Having 2 write ports not only helps with 2R2W operations, but also with badly scheduled instructions that finish at the same time, and the above example is a case that is statistically happening more often than 2R2W instructions. > > As a side note, i'm realistic enough to see that we won't > > be able to "implement" the FC0 before a long time (how many years ?) > > so i am not concerned "directly" with this issue. This is interesting > > to see how we can modify the architecture with respect to this > > economic problem but you know that this industry evolves very quickly. > > Too quickly for us. > Maybe, but will always have 20% time penalty, at least ! as long as we are conscious about it, it's ok. > > my conclusion is : as long as you can sustain 2 writes per cycles, > > it's ok for me. Even if you have to use 4 register banks which are > > addressed with their 2LSB (i use the analogy with a 4-way set associative > > cache, so in this case there are 4 register banks of 16 registers each). > > 128-bit registers is not a "decent solution" IMHO : it's really too large > > and not useful in 80% of the cases where 2W/cycle is necessary. > ?? Not usefull and you need 2 write ports only for one instruction: a > post increment-load ! no, as shown in the previous simple example. of course, you can decide to have only one write port but the compiler will be more complex (it will have to manage all the write hazards). > Do you remember the rules : if add 10% more silicium it must increase > the speed by 10%, and i don't think that for the post incremental load. i'm sorry but : - the load and store instructions are _critical_ instructions in RISC world. - IIRC the original remark was 10% more critical datapath, and not 10% more silicium. we can put datapaths in parallel. - the "10%" rule is valid for "classical" designs, while in the F-CPU case we are in another "extreme" situation : * silicon surface is not "expensive" (the package and the test is as expensive so 10% more silicon is not "mecanically" 10% higher price) * we consider that we are already at maximum speed and operations can't be "compressed" > > i hope we will be able to discuss this matter in depth. > > i am currently designing the scheduler so it's the right time. > I should write mine before you finish yours !! to compare. the comparison will certainly be interesting, sure :-) is it possible to meet you ? i have to draw some pictures that will be useful for you. > > merry christmas everybody, btw ! > The same ! > nicO > > > nicO > > WHYGEE > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 24 06:34:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IXk8-0001Xv-00 for ; Mon, 24 Dec 2001 17:14:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 17:14:24 +0100 (CET) Received: (qmail 879 invoked by uid 0); 23 Dec 2001 23:33:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Dec 2001 23:33:54 -0000 Received: by moria.seul.org (Postfix) id 323211467E8; Sun, 23 Dec 2001 18:33:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E4E21467F2; Sun, 23 Dec 2001 18:33:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 20B3F1467E8 for ; Sun, 23 Dec 2001 18:33:51 -0500 (EST) Received: from ifrance.com (vlt11-148.n.club-internet.fr [195.36.224.148]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3228016B2 for ; Mon, 24 Dec 2001 00:33:46 +0100 (CET) Message-ID: <3C26BE7A.47E111ED@ifrance.com> Date: Mon, 24 Dec 2001 00:34:50 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> <3C25567E.6BD0BE9C@f-cpu.org> <3C262045.4199EDAA@ifrance.com> <3C26200F.E903B154@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nicO wrote: > > Yann Guidon a écrit : > > > nicO wrote: > > > > So i propose to change all reference in the manual concerning register > > > > access as rn and rn+1 by rn with n even and rn+1. So why ? > > > currently, i do rn and rn xor 1. this is handy and friendly > > It's not enought because you always need 5 port. > Either you have the 2 write ports, or the core (deespite the higher > frequency) runs software slower because of the contention of the > write bus. you have the choice... > I don't think that you will balance the penalty time of 5th ported memory. > > > > Usualy silicon foundry give memory generator for dual ported memory and > > > > nothing else (it the same for FPGA). So (as for leon), we could use 2 > > > > area of such memory to produice the 3 needed port for the memory (so we > > > > duplicat data). > > > to be more precise, i have read that LEON uses 2 banks of 1R1W, > > > the written data is sent to both the W ports and the R ports > > > provide data in parallel. > > Yep, ... to make a 2R1W register bank... as for us ! > with the difference that we need 3 banks and this still does not > solve the problem if you don't have 2 write ports. > unless you find a better trick. i have the beginning of an idea, > which is explained later in my post. > > > > > So each EU could receive 2 128 bits data and write ONE 128 data. Write > > > > enable could be used to minimise power consumption when only one byte is > > > > written. > > > > > > > > Comments ? > > > > > > there is a big problem if you can't write 2 different data > > > (at different addresses). The 2R2W instructions are only > > > one side of the problem and you have overlooked a detail : > > > instructions such as "load post-incremented" (a 2R2W instruction) > > > performs an addition and a load in parallel. The result of > > > the load will be ready faster (3 cycle starting from the decoding > > > stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., > > > without even counting the TLB and the cache lookup). Do you see > > > where it goes ? > > > > Humm, an add slower than a load : look so odd ! > > it is because "load" is the instruction, and not what it "really" does. > "load" and "store" transfer data to and from the LSU. this is a > _deterministic_ instruction because it goes throught the following units : > - LSU > - LSU alignment/shift > - Xbar > - R7 (Register set) > (in the reverse order for "store"). > > i told it : forget about the other cores ! in FC0, the load and store > instructions do NOT go to the memory ! it's the LSU's job and the > decode stage only asks if a given pointer has the associated data ready, > so if a loaded data is not ready, the instruction is stalled at the Xbar > stage. > And what if the data aren't in "L0 cache", you always must create the hardware to handel that case. > On the other hand, for a load/store to work, it requires that the pointer > goes through the validation and fetch process, which is completely > hidden from the user, except concerning the time it takes. > When updating the pointer, the other side of the "fork" goes through > the following : > - Dec (reads the pointer's value) > - Xbar > - ASU1 (compute the new pointer value) > - ASU2 > - TLB1 + Xbar > - TLB2 + write R7 > - cache and LSU lookup (may require more cycles if there's a cache miss) > - allocate and update the LSU line > > the load/store instruction is both deterministic and exempt from > exceptions inside the "execution core". When it arrives to the LSU, > this unit takes the misses into account and manages the 8 buffers. > It communicates with the decoder with flags that indicate if data > is ready or not, or if a register has been validated as a pointer. > This way, we can fire the TLB misses only at decode/xbar stage. In case of miss, you have to handel it ! > > > Such instruction will be split at the decoder stage, one goes thought > > the alu, the other thought the load pipe. Load will be much (much) > > slower than the add, so the data will never be ready in the same time, > > so we could add a little delay, times to times. > read above : there is no "load pipe", at least in the sense that you know > for other CPUs. of course, accessing the memory is slower than doing > an addition, but it is in the OTHER branch of the pipe. > Otherwise, if your "load pipe" contains the TLB lookup, you > introduce the possibility of an exception firing in the pipeline, > while our design goal is to avoid it completely. > > > > If you issue several loads in a row (say : 6), the last > > > ones will be stalled even if all the data is ready, > > > because your bus will not sustain the 2 writes per cycle > > > at different addresses. It is not a solution to delay the > > > fastest data because the situation would become even worse > > > (you know that memory access speed is critical for computer > > > performance). > > ??? The data will come even more slowly compare to the cor speed, so ? > i will make you a little drawing so you can understand. > in the last example, i assume that all the requested data is already > present in the LSU's buffer (a kind of L0 cache and reorder buffer > which contains 8*32 bytes). > I know (but you must remember that this cache will be much more slow than register read). > > In an other point, i propose to add definitly the 8 register load > > instruction. > ???? this means that you transfer 8*64=512 bits at once, while our > maximal internal bus width is 256 bits currently ! > Yep ! You speak about something similar using SRB memory mecanism. So in that case, it will take several cycle, it will be great to manage burst access to the main memory. > > This is a kind of preload for loop. To try to manage prefetch in x86, i > > can say that the timing is very complicated to have : you prefetch too > > early, the data could be scratch and it goes slower. If you make it too > > late, you add some instruction to be performed, so it goes slower... > there is already a prefetch instruction in the f-cpu manual IIRC. > I know. And i know it's very difficult to use. That's why i prefer preload. > > This instruction could use the SRB hardware. It will load in shunk of > > register ((R0)R1-R7,R8-R15,R16-R23,R24-R31,...). > why do you want to mix prefetch and register load ? i really don't > understand your intention. No it's load, but i call them preload, because you effectivly do a load but 8 at a time, in advance. > remark that on another side, the LSU is also in charge of recognizing > "memory streams", it will issue contiguous memory fetches if it > sees that several contiguous fetches have triggered cache misses > in the past. > A predicator, hum, i have a doubt... a very big one ;p So easy to have the opposite effect ! > > > However, if you can't "pay" multiported SRAM (whatever > > > the configuration, say 3*(2W1R)), you have the possibility to > > > "downgrade" your implementation : you will not support > > > any 2W operation and you will reduce the scheduler to 1 write > > > per cycle. the other operations will have to be emulated > > > and the performance will suffer a lot... but it is still > > > possible. You will still be able to run "out of order completion" > > > code but with limited features and a low tolerance for > > > bus contention. > > > > ??? > > in simpler words : with only 1 write port (even if it's 128-bit wide) > you won't be able to execute the following instruction chunck : > > add r1,r2,r3 > and r4,r5,r6 > > because the add operates in 2 cycles and and is 1 cycle, > it will create a contention ("hazard" if you prefer) on the write bus. > the scheduler will have to delay the AND. > Having 2 write ports not only helps with 2R2W operations, but also > with badly scheduled instructions that finish at the same time, > and the above example is a case that is statistically happening > more often than 2R2W instructions. > That's true but you will be prettier with the cpu and schedule it an other way. And it will work . and r4,r5,r6 add r1,r2,r3 > > > As a side note, i'm realistic enough to see that we won't > > > be able to "implement" the FC0 before a long time (how many years ?) > > > so i am not concerned "directly" with this issue. This is interesting > > > to see how we can modify the architecture with respect to this > > > economic problem but you know that this industry evolves very quickly. > > > Too quickly for us. > > Maybe, but will always have 20% time penalty, at least ! > > as long as we are conscious about it, it's ok. > I think that it's an overkill. > > > my conclusion is : as long as you can sustain 2 writes per cycles, > > > it's ok for me. Even if you have to use 4 register banks which are > > > addressed with their 2LSB (i use the analogy with a 4-way set associative > > > cache, so in this case there are 4 register banks of 16 registers each). > > > 128-bit registers is not a "decent solution" IMHO : it's really too large > > > and not useful in 80% of the cases where 2W/cycle is necessary. > > ?? Not usefull and you need 2 write ports only for one instruction: a > > post increment-load ! > no, as shown in the previous simple example. Even with 2 port you will have contention. Imagine the use of divider which take 30 cycles or more. If you writte an horrible code : all data are ready in the same time. You could always need more port. But don't forget the bypass net, you always could read the data by this means (the R4 of your instruction could be read, but the add unit is freezed). > of course, you can decide to have only one write port but the compiler > will be more complex (it will have to manage all the write hazards). > You always have write hasard with multi cycle instruction and variable latency. You need one port by unit + the memory load/store latency. It will never end ! But that's not a problem most of the time. The problem is to immediatly reused the result, that could be done with the bypass net. > > Do you remember the rules : if add 10% more silicium it must increase > > the speed by 10%, and i don't think that for the post incremental load. > i'm sorry but : > - the load and store instructions are _critical_ instructions in RISC world. Sur it's critical but having a double write port to write a data when the second could be take almost 150 cycles seems really big. If you force to make load/store determinisc, it's as you force to make a load inside the L0 cache and you only slide the problem. > - IIRC the original remark was 10% more critical datapath, > and not 10% more silicium. we can put datapaths in parallel. mmh, ok! > - the "10%" rule is valid for "classical" designs, while in the F-CPU case > we are in another "extreme" situation : > * silicon surface is not "expensive" (the package and the test is as > expensive so 10% more silicon is not "mecanically" 10% higher price) !!!! All this kind of things are linked, but chips are sold in mm² so, only the size is important. > * we consider that we are already at maximum speed and operations > can't be "compressed" > > > > i hope we will be able to discuss this matter in depth. > > > i am currently designing the scheduler so it's the right time. > > I should write mine before you finish yours !! to compare. > the comparison will certainly be interesting, sure :-) > > is it possible to meet you ? > i have to draw some pictures that will be useful for you. > > > > merry christmas everybody, btw ! > > The same ! > > nicO > > > > nicO > > > WHYGEE I have well understood your cache which link register number and memory content. To speed up cache it's possible to use direct register 64 register of 256 bits. It will be as fast as bank register access. But i don't see how you handel alias for data (an old thread soon speak about that). nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 24 01:22:54 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IXkF-0001Xv-00 for ; Mon, 24 Dec 2001 17:14:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 17:14:31 +0100 (CET) Received: (qmail 22831 invoked by uid 0); 24 Dec 2001 00:19:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 24 Dec 2001 00:19:40 -0000 Received: by moria.seul.org (Postfix) id A72D81467E8; Sun, 23 Dec 2001 19:19:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 898591467F2; Sun, 23 Dec 2001 19:19:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1FB3C1467E8 for ; Sun, 23 Dec 2001 19:19:38 -0500 (EST) Received: from f-cpu.org (kdl1-32.n.club-internet.fr [213.44.0.32]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2BA6B16CE for ; Mon, 24 Dec 2001 01:19:35 +0100 (CET) Message-ID: <3C26755E.A1ED6C1C@f-cpu.org> Date: Mon, 24 Dec 2001 01:22:54 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] correction : no delay required for the multiplier References: <3C23F93C.4F316937@f-cpu.org> <20011222150530.23102@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sat, Dec 22, 2001 at 04:08:44AM +0100, Yann Guidon wrote: > > In the scheduler FIFO, i have two columns of N positions > > (N-deep FIFO) with each the following informations : > > - valid (1 bit) > > - register number (6 bits) -> used during the register write cycle > > - write mask (2 bits) -> used during the register write cycle > > - write port (3 or 4 bits) -> used during the Xbar cycle to select the data > > Each FIFO stage contains (for most bits) a register (that is clocked > > by the main clock), a few comparators (for the register numbers) > > and a MUX that selects either the previous stage's data OR the data coming > > from the decoder's LUT. > It's crystal clear :) And it looks good to me. I would probably > store a pre-decoded write mask (5 bits) instead, but that's a minor > issue. it is minor, and in fact only 2 bits are necessary. the other bits are added at the bottom of the FIFO because no "regular" operation writes to a specific 16-bit chunk. The added bits are needed _only_ for the loadimm instructions, which do not need to go through all the FIFO (they take only 2 cycles). WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 24 03:10:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IXkG-0001Xv-00 for ; Mon, 24 Dec 2001 17:14:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 17:14:32 +0100 (CET) Received: (qmail 25910 invoked by uid 0); 24 Dec 2001 02:07:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 24 Dec 2001 02:07:22 -0000 Received: by moria.seul.org (Postfix) id ABED01467E8; Sun, 23 Dec 2001 21:07:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6ED11467F2; Sun, 23 Dec 2001 21:07:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 188A21467E8 for ; Sun, 23 Dec 2001 21:07:20 -0500 (EST) Received: from f-cpu.org (kdl11-9.n.club-internet.fr [213.44.9.9]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B163916AC for ; Mon, 24 Dec 2001 03:07:12 +0100 (CET) Message-ID: <3C268E99.FCABC2AB@f-cpu.org> Date: Mon, 24 Dec 2001 03:10:33 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w References: <3C253D09.67D2F7FB@ifrance.com> <3C25567E.6BD0BE9C@f-cpu.org> <3C262045.4199EDAA@ifrance.com> <3C26200F.E903B154@f-cpu.org> <3C26BE7A.47E111ED@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > Yann Guidon a écrit : > > > > nicO wrote: > > > > > So i propose to change all reference in the manual concerning register > > > > > access as rn and rn+1 by rn with n even and rn+1. So why ? > > > > currently, i do rn and rn xor 1. this is handy and friendly > > > It's not enought because you always need 5 port. > > Either you have the 2 write ports, or the core (deespite the higher > > frequency) runs software slower because of the contention of the > > write bus. you have the choice... > I don't think that you will balance the penalty time of 5th ported > memory. FC0's register set was designed by taking into account that other CPUs of that time already had huge register sets. The IA64 was already at the "Merced" stage and you know that we can compare it's register set to a football stadium. You say that you can't directly use the "average" 2-port memory. To me it's the same thing as saying "Linux is not ready for the desktop", it is simply not correlated. In the beginning, we thought about F-CPU with comparisons to what was technically possible, in the present and in the future. We did not take "IP" into account because that did not exist at that time (at least in the same form as today). However it is still possible to use 1R1W memory blocks and assemble them to form any configuration. If you give me 16*16 bit registers with 1 read and 1 write port, i can assemble them into something that will work nicely in 75% of the cases. > > > > there is a big problem if you can't write 2 different data > > > > (at different addresses). The 2R2W instructions are only > > > > one side of the problem and you have overlooked a detail : > > > > instructions such as "load post-incremented" (a 2R2W instruction) > > > > performs an addition and a load in parallel. The result of > > > > the load will be ready faster (3 cycle starting from the decoding > > > > stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., > > > > without even counting the TLB and the cache lookup). Do you see > > > > where it goes ? > > > > > > Humm, an add slower than a load : look so odd ! > > > > it is because "load" is the instruction, and not what it "really" does. > > "load" and "store" transfer data to and from the LSU. this is a > > _deterministic_ instruction because it goes throught the following units : > > - LSU > > - LSU alignment/shift > > - Xbar > > - R7 (Register set) > > (in the reverse order for "store"). > > > > i told it : forget about the other cores ! in FC0, the load and store > > instructions do NOT go to the memory ! it's the LSU's job and the > > decode stage only asks if a given pointer has the associated data ready, > > so if a loaded data is not ready, the instruction is stalled at the Xbar > > stage. > > > > And what if the data aren't in "L0 cache", you always must create the > hardware to handel that case. yes, of course. But the stall is not inside the "execution pipeline" and an instruction that requests data that are pointed to by a register will be held in the decoder until the data is ready. This way, all delays inside the "execution pipeline" (that is : which communicate through the internal Xbar, from and to the register set and the execution units) are completely static. If there is a memory "miss" then the load instruction will be halted _before_ execution, and not in the middle (where it is harder to manage). > > the load/store instruction is both deterministic and exempt from > > exceptions inside the "execution core". When it arrives to the LSU, > > this unit takes the misses into account and manages the 8 buffers. > > It communicates with the decoder with flags that indicate if data > > is ready or not, or if a register has been validated as a pointer. > > This way, we can fire the TLB misses only at decode/xbar stage. > > In case of miss, you have to handel it ! yes but the only effect (for the program) is that the instruction is halted at decoding stage, while all other instructions before it continue to execute. When execution restarts, all the instruction ordering and latency is still deterministic. concerning the cache misses, i don't think we need to reinvent the wheel. > > > ??? The data will come even more slowly compare to the cor speed, so ? > > i will make you a little drawing so you can understand. > > in the last example, i assume that all the requested data is already > > present in the LSU's buffer (a kind of L0 cache and reorder buffer > > which contains 8*32 bytes). > > I know (but you must remember that this cache will be much more slow > than register read). i know. that's why the LSU uses 2 cycles. > > > In an other point, i propose to add definitly the 8 register load > > > instruction. > > ???? this means that you transfer 8*64=512 bits at once, while our > > maximal internal bus width is 256 bits currently ! > > Yep ! You speak about something similar using SRB memory mecanism. So in > that case, it will take several cycle, it will be great to manage burst > access to the main memory. considering that memroy fetches can be atomic, why do you want them to write to contiguous registers (on top of that ?) > > > This is a kind of preload for loop. To try to manage prefetch in x86, i > > > can say that the timing is very complicated to have : you prefetch too > > > early, the data could be scratch and it goes slower. If you make it too > > > late, you add some instruction to be performed, so it goes slower... > > there is already a prefetch instruction in the f-cpu manual IIRC. > > I know. And i know it's very difficult to use. That's why i prefer > preload. i see no difference : you can "preload" a L0 line simply by doing a load to R0, and you get 256 bits. there will be no penalty until you want to really use the data (with another "load" instruction). it's like a "touch" or "cache warming" with no incidence on the register set. On top of that, once you "consume" data (read or write in the line), a second line is allocated and prefetched by the LSU and the fetcher, thus implementing "double buffering" (a line is being used while another is being loaded from memory). > > > This instruction could use the SRB hardware. It will load in shunk of > > > register ((R0)R1-R7,R8-R15,R16-R23,R24-R31,...). > > why do you want to mix prefetch and register load ? i really don't > > understand your intention. > No it's load, but i call them preload, because you effectivly do a load > but 8 at a time, in advance. what is the purpose of writing to 8 registers ? > > remark that on another side, the LSU is also in charge of recognizing > > "memory streams", it will issue contiguous memory fetches if it > > sees that several contiguous fetches have triggered cache misses > > in the past. > > A predicator, hum, i have a doubt... a very big one ;p So easy to have > the opposite effect ! nobody forces you to use it. When it is written in the F-CPU source code, you can set a flag that removes its compilation if you want. > > > > > > ??? > > > > in simpler words : with only 1 write port (even if it's 128-bit wide) > > you won't be able to execute the following instruction chunck : > > > > add r1,r2,r3 > > and r4,r5,r6 > > > > because the add operates in 2 cycles and and is 1 cycle, > > it will create a contention ("hazard" if you prefer) on the write bus. > > the scheduler will have to delay the AND. > > Having 2 write ports not only helps with 2R2W operations, but also > > with badly scheduled instructions that finish at the same time, > > and the above example is a case that is statistically happening > > more often than 2R2W instructions. > > That's true but you will be prettier with the cpu and schedule it an > other way. And it will work . > and r4,r5,r6 > add r1,r2,r3 sure it will work, but you know that no operation is completely independent >from everything : all the instructions before and after can come from a global dataflow analysis. swapping two instructions can cause the re-analisis of all the instruction scheduling in the block. > > > > my conclusion is : as long as you can sustain 2 writes per cycles, > > > > it's ok for me. Even if you have to use 4 register banks which are > > > > addressed with their 2LSB (i use the analogy with a 4-way set associative > > > > cache, so in this case there are 4 register banks of 16 registers each). > > > > 128-bit registers is not a "decent solution" IMHO : it's really too large > > > > and not useful in 80% of the cases where 2W/cycle is necessary. > > > ?? Not usefull and you need 2 write ports only for one instruction: a > > > post increment-load ! > > no, as shown in the previous simple example. > Even with 2 port you will have contention. of course, but less in average. > Imagine the use of divider > which take 30 cycles or more. If you writte an horrible code : all data > are ready in the same time. You could always need more port. But don't > forget the bypass net, you always could read the data by this means (the > R4 of your instruction could be read, but the add unit is freezed). adding "write buffers" to the register set is close to register renaming. one of FC0's design goals is to not implement it. Concerning the write port number, 2 is satisfying for FC0. A 2-issue FC0 would be happy with 3 write ports. Btw, one of the reasons why the P6 core is so fucked up is because it can "retire" less instructions than it can emit. the morale of the P6 story is : you can always try to schedule everything perfectly, not only you'll never succeed (it's highly undeterministic and the register pressure is extreme), but on top of that the retirement unit will never sustain the flood. > > of course, you can decide to have only one write port but the compiler > > will be more complex (it will have to manage all the write hazards). > > You always have write hasard with multi cycle instruction and variable > latency. You need one port by unit + the memory load/store latency. It > will never end ! if even with only 2 ports it's not enough, then with only 1 port it's much worse :-/ > But that's not a problem most of the time. The problem > is to immediatly reused the result, that could be done with the bypass net. I agree in part with that, as long as the control logic remains human-readable... > > > Do you remember the rules : if add 10% more silicium it must increase > > > the speed by 10%, and i don't think that for the post incremental load. > > i'm sorry but : > > - the load and store instructions are _critical_ instructions in RISC world. > Sur it's critical but having a double write port to write a data when > the second could be take almost 150 cycles seems really big. unless you code comme une loutre, this must not happen for every instruction, right ? > If you force to make load/store determinisc, it's as you force to make a > load inside the L0 cache and you only slide the problem. of course, i push the problem where it's not a problem anymore. All design activity is like that. As for the L0, it acts as a fine-grained reorder buffer, or a "write buffer", or whatever, and current "big" CPUs have such things. i simply changed or added some more functions. > > - the "10%" rule is valid for "classical" designs, while in the F-CPU case > > we are in another "extreme" situation : > > * silicon surface is not "expensive" (the package and the test is as > > expensive so 10% more silicon is not "mecanically" 10% higher price) > > !!!! All this kind of things are linked, but chips are sold in mm² so, > only the size is important. however, when the size is proportional to the performance, what do you do ? :-) > I have well understood your cache which link register number and memory > content. To speed up cache it's possible to use direct register 64 > register of 256 bits. it would be REALLY too big... and not useful because not every register contains a "pointer". > It will be as fast as bank register access. But i don't see > how you handel alias for data (an old thread soon speak about that). i have found 3 strategies to handle aliases in the LSU and the fetcher. all have bad and good sides... please note that i avoid by all possible means the use of an intermediary LUT that transforms the register number into a L0 line number, because it creates an overhead. The mechanism must be an "associative memory" : you give the key and you get the data, not an index. 1) big and naughty : "copy everything." the idea is that there is still a 1-to-1 association between a register number and a physical line. But in this strategy, we allow the furiously silly strategy of having the same logical address mapped to several physical lines. This has the advantage that you can have as many aliases as there are lines, but you imagine the crazy mess that maintains the coherency between the lines... it _could_ be done but i don't like it because the coherency management can become too close to a non-associative memory. 2) working with pairs of lines. This sounds natural at first glance because the L0 buffers will certainly use a double-buffering strategy. If we work by pairs, there will be less problems with double-buffering. I have counted that given 2 registers and 2 lines, there are 8 legal associations, so it can be coded into 3 bits. This means that when the comparison with the register number is successful, we need a very low overhead to know which line is read. It is also reversible : given an address, we can determine which register(s) to deallocate (for example when we want to flush a line, we have to flush the associated registers). This is good (tm) but the alias is limited to 2 registers. 3) the '<=>' strategy This one is a bit more sophisticated but it is similar to 2). however here we now extend to 3 registers because we don't work with pair, but 3 consecutive lines and registers. register comparator number i can be associated to the line i-1, i or i+1. One line is associated exclusively to 1 address (like 2)). One register can be associated to one line, but one line can be linked up to 3 registers (except when i=0 or i=7, there are ony 2 neighbours). It more flexible for the double-buffering because there is more choice. I have not finished my analysis but i think i'll work on that strategy. Warning ! Augmenting the associativity will augment the overhead, so i think that the 3rd method is a good compromise between simplicity, fexibility and efficiency. using a 4-register neighbourhood will double the logic and the overhead. the 3rd method already requires 22 memory bits and the LRU and replacement strategy is more complex than the simple direct-associativity strategy. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 24 20:35:33 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IXkL-0001Xv-00 for ; Mon, 24 Dec 2001 17:14:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 17:14:37 +0100 (CET) Received: (qmail 10287 invoked by uid 0); 24 Dec 2001 13:34:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Dec 2001 13:34:34 -0000 Received: by moria.seul.org (Postfix) id 174731467E8; Mon, 24 Dec 2001 08:34:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 047A91467EC; Mon, 24 Dec 2001 08:34:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4C6AB1467E8 for ; Mon, 24 Dec 2001 08:34:32 -0500 (EST) Received: from ifrance.com (vlt5-185.n.club-internet.fr [194.158.108.185]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1DD9F16DF for ; Mon, 24 Dec 2001 14:34:26 +0100 (CET) Message-ID: <3C278385.2833B619@ifrance.com> Date: Mon, 24 Dec 2001 14:35:33 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 3r2w -> 2r1w, 8 loads inst, L0 coherency References: <3C253D09.67D2F7FB@ifrance.com> <3C25567E.6BD0BE9C@f-cpu.org> <3C262045.4199EDAA@ifrance.com> <3C26200F.E903B154@f-cpu.org> <3C26BE7A.47E111ED@ifrance.com> <3C268E99.FCABC2AB@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I would take more time to answer but it's hard ! debat : 3r2w vs 2r1w 3r2w 64 bits Less write contention In 2 years, the technology will grown 2r1w 128 bits Technologie soon used Faster access time Equal bandwith Smaller Dual ported memory used even in FPGA The big point concern the penalty due to write contention : is it an overkill in 2r1w or not ? - i think no - Whygee think yes. The following speak about the load of 8 reg in the same time, and how L0 should work to maintain coherency. Have a good read ! Yann Guidon a écrit : > > hello, > > nicO wrote: > > Yann Guidon a écrit : > > > nicO wrote: > > > > Yann Guidon a écrit : > > > > > nicO wrote: > > > > > > So i propose to change all reference in the manual concerning register > > > > > > access as rn and rn+1 by rn with n even and rn+1. So why ? > > > > > currently, i do rn and rn xor 1. this is handy and friendly > > > > It's not enought because you always need 5 port. > > > Either you have the 2 write ports, or the core (deespite the higher > > > frequency) runs software slower because of the contention of the > > > write bus. you have the choice... > > I don't think that you will balance the penalty time of 5th ported > > memory. > > > FC0's register set was designed by taking into account that > other CPUs of that time already had huge register sets. The IA64 > was already at the "Merced" stage and you know that we can compare > it's register set to a football stadium. > > Yes, at that time, the team speak about merced killer. Since the intel cpu as commit suicide and we are waiting for Mac Kinley. > You say that you can't directly use the "average" 2-port memory. > To me it's the same thing as saying "Linux is not ready for the desktop", > it is simply not correlated. In the beginning, we thought about F-CPU > with comparisons to what was technically possible, in the present > and in the future. We did not take "IP" into account because that > did not exist at that time (at least in the same form as today). > So now, we have some information : the fcpu can't begin to fight against well established cpu as x86. Everybody knows it's crap but it's compatible and cheap (if you don't beleive me look at the price of Sun Blade 1000 750 which didn't reach the speed of >1600 Mhz cpu from Intel or AMD), that's only why this line of cpu continue. To begin Fcpu must find an easiest way. x86/PowerPc concerne very very few chip maker. Everybody (Thomson, Nokia, Alcatel, Sony,...) which use a cpu in there chip could use an IP, usually they use those from ARM (and make the debugging for them...), but Fcpu (as Leon) could have a very great opportunities to win this market. Why ? Simplie because compagny don't like to show there source code ! > However it is still possible to use 1R1W memory blocks and assemble > them to form any configuration. If you give me 16*16 bit registers > with 1 read and 1 write port, i can assemble them into something > that will work nicely in 75% of the cases. > Yes, but it could be slow and large. But i'm curious to see how you create 2 write ports with many 1W ported memeory. > > > > > there is a big problem if you can't write 2 different data > > > > > (at different addresses). The 2R2W instructions are only > > > > > one side of the problem and you have overlooked a detail : > > > > > instructions such as "load post-incremented" (a 2R2W instruction) > > > > > performs an addition and a load in parallel. The result of > > > > > the load will be ready faster (3 cycle starting from the decoding > > > > > stage) than the addition (dec+xbar+asu1+asu2+xbar=5 cycles min., > > > > > without even counting the TLB and the cache lookup). Do you see > > > > > where it goes ? > > > > > > > > Humm, an add slower than a load : look so odd ! > > > > > > it is because "load" is the instruction, and not what it "really" does. > > > "load" and "store" transfer data to and from the LSU. this is a > > > _deterministic_ instruction because it goes throught the following units : > > > - LSU > > > - LSU alignment/shift > > > - Xbar > > > - R7 (Register set) > > > (in the reverse order for "store"). > > > > > > i told it : forget about the other cores ! in FC0, the load and store > > > instructions do NOT go to the memory ! it's the LSU's job and the > > > decode stage only asks if a given pointer has the associated data ready, > > > so if a loaded data is not ready, the instruction is stalled at the Xbar > > > stage. > > > > > > > And what if the data aren't in "L0 cache", you always must create the > > hardware to handel that case. > > yes, of course. But the stall is not inside the "execution pipeline" > and an instruction that requests data that are pointed to by a register > will be held in the decoder until the data is ready. > This way, all delays inside the "execution pipeline" (that is : which > communicate through the internal Xbar, from and to the register set and > the execution units) are completely static. If there is a memory "miss" > then the load instruction will be halted _before_ execution, and not > in the middle (where it is harder to manage). > Bof ! With my asynchronous pipeline it could be done (the unit say when there ready, you could freeze them if there contention at the write port, you absolutely don't mind how unit work (whygee: could you handel the case with your proposal when a multicycle instructions are pipelined (so "some" instruction could run in the same time) ? ), the cohenrency is maintain by register dependancies only) > > > the load/store instruction is both deterministic and exempt from > > > exceptions inside the "execution core". When it arrives to the LSU, > > > this unit takes the misses into account and manages the 8 buffers. > > > It communicates with the decoder with flags that indicate if data > > > is ready or not, or if a register has been validated as a pointer. > > > This way, we can fire the TLB misses only at decode/xbar stage. > > > > In case of miss, you have to handel it ! > > yes but the only effect (for the program) is that the instruction > is halted at decoding stage, while all other instructions before it > continue to execute. When execution restarts, all the instruction > ordering and latency is still deterministic. > So you don't make any write combining, any write buffering ? That's very often use and it's speed up execution too. L0 cache could be used to do this. I don't understand to block when there is L0 miss. In case of lot of load, you will kill the performance. In case of none blocking load/store you could add more transaction and use all the feature of DRAM buses (interlaced access to hide latency...) > concerning the cache misses, i don't think we need to reinvent the wheel. Comparre to the core, caches are sloooow. In moderne CPU, L1 cache are 3 stages pipeline, P4 use 2 stages caches that's why is only 8 Ko. As i can see, fcp will be much more pipelined than P4... > > > > ??? The data will come even more slowly compare to the cor speed, so ? > > > i will make you a little drawing so you can understand. > > > in the last example, i assume that all the requested data is already > > > present in the LSU's buffer (a kind of L0 cache and reorder buffer > > > which contains 8*32 bytes). > > > > I know (but you must remember that this cache will be much more slow > > than register read). > > i know. that's why the LSU uses 2 cycles. > :D lol ! It's always funny to determine such think without much more deffined things. I think that you make the work in the wrong way. > > > > In an other point, i propose to add definitly the 8 register load > > > > instruction. > > > ???? this means that you transfer 8*64=512 bits at once, while our > > > maximal internal bus width is 256 bits currently ! > > > > Yep ! You speak about something similar using SRB memory mecanism. So in > > that case, it will take several cycle, it will be great to manage burst > > access to the main memory. > > considering that memroy fetches can be atomic, why do you want them > to write to contiguous registers (on top of that ?) > Because burst access are aligned, and because you couldn't put so many information in instruction word and with 128 bit buses it's help ! > > > > This is a kind of preload for loop. To try to manage prefetch in x86, i > > > > can say that the timing is very complicated to have : you prefetch too > > > > early, the data could be scratch and it goes slower. If you make it too > > > > late, you add some instruction to be performed, so it goes slower... > > > there is already a prefetch instruction in the f-cpu manual IIRC. > > > > I know. And i know it's very difficult to use. That's why i prefer > > preload. > > i see no difference : you can "preload" a L0 line simply by doing > a load to R0, and you get 256 bits. there will be no penalty until you want > to really use the data (with another "load" instruction). it's like a > "touch" or "cache warming" with no incidence on the register set. > That's here where you make a mistake ! That's abslutely not the same ! If you use prefetch you make no load, you guess that your data will be ready (it's realy to know when ! and it change a lot between generation), when you ask them. With preload, the data are effectively load. With such instruction (and no blocking load/store) you could use double buffering technique (load 8 data, when calculating on 8 others, then swap !). So in case of prefetch, you have _2_ pseudo load perform instead of one. So you could kill your performance if you use to many prefetch not finished. The problem concerne the calculation to be done and the fact that umber will change with different version of the cpu (cache speed/core speed/SDRAM speed ...). Try the program of my first article and you will see, it could became horrible ! > On top of that, once you "consume" data (read or write in the line), > a second line is allocated and prefetched by the LSU and the fetcher, > thus implementing "double buffering" (a line is being used while another > is being loaded from memory). > Prefetch are theoricaly good, but bad behavior could kill your performance. > > > > This instruction could use the SRB hardware. It will load in shunk of > > > > register ((R0)R1-R7,R8-R15,R16-R23,R24-R31,...). > > > why do you want to mix prefetch and register load ? i really don't > > > understand your intention. > > No it's load, but i call them preload, because you effectivly do a load > > but 8 at a time, in advance. > > what is the purpose of writing to 8 registers ? > Double buffering, and use of maximum memory bandwith and i think 8 is a good number. > > > remark that on another side, the LSU is also in charge of recognizing > > > "memory streams", it will issue contiguous memory fetches if it > > > sees that several contiguous fetches have triggered cache misses > > > in the past. > > > > A predicator, hum, i have a doubt... a very big one ;p So easy to have > > the opposite effect ! > > nobody forces you to use it. When it is written in the F-CPU source code, > you can set a flag that removes its compilation if you want. > > > > > > > > > ??? > > > > > > in simpler words : with only 1 write port (even if it's 128-bit wide) > > > you won't be able to execute the following instruction chunck : > > > > > > add r1,r2,r3 > > > and r4,r5,r6 > > > > > > because the add operates in 2 cycles and and is 1 cycle, > > > it will create a contention ("hazard" if you prefer) on the write bus. > > > the scheduler will have to delay the AND. > > > Having 2 write ports not only helps with 2R2W operations, but also > > > with badly scheduled instructions that finish at the same time, > > > and the above example is a case that is statistically happening > > > more often than 2R2W instructions. > > > > That's true but you will be prettier with the cpu and schedule it an > > other way. And it will work . > > and r4,r5,r6 > > add r1,r2,r3 > > sure it will work, but you know that no operation is completely independent > from everything : all the instructions before and after can come from a global > dataflow analysis. swapping two instructions can cause the re-analisis of all > the instruction scheduling in the block. > Yep ! 2 port will always be faster than 1 but i don't think that the difference will be so important. > > > > > my conclusion is : as long as you can sustain 2 writes per cycles, > > > > > it's ok for me. Even if you have to use 4 register banks which are > > > > > addressed with their 2LSB (i use the analogy with a 4-way set associative > > > > > cache, so in this case there are 4 register banks of 16 registers each). > > > > > 128-bit registers is not a "decent solution" IMHO : it's really too large > > > > > and not useful in 80% of the cases where 2W/cycle is necessary. > > > > ?? Not usefull and you need 2 write ports only for one instruction: a > > > > post increment-load ! > > > no, as shown in the previous simple example. > > Even with 2 port you will have contention. > of course, but less in average. > > > Imagine the use of divider > > which take 30 cycles or more. If you writte an horrible code : all data > > are ready in the same time. You could always need more port. But don't > > forget the bypass net, you always could read the data by this means (the > > R4 of your instruction could be read, but the add unit is freezed). > adding "write buffers" to the register set is close to register renaming. > one of FC0's design goals is to not implement it. ???? Bypass net as nothing to do with register renaming ! > Concerning the write port number, 2 is satisfying for FC0. > A 2-issue FC0 would be happy with 3 write ports. > > Btw, one of the reasons why the P6 core is so fucked up is because > it can "retire" less instructions than it can emit. the morale of > the P6 story is : you can always try to schedule everything perfectly, > not only you'll never succeed (it's highly undeterministic and the > register pressure is extreme), but on top of that the retirement unit > will never sustain the flood. > I just reread the intel spec. Retirment unit in P6 could retire 3 µop and the scheduler could send 3 µop. So i don't understand you're point of view. Register pressure in P6 aren't the same because of the register renaming. If you introduice dependancies other than read after write, it will be renamed, so ? > > > of course, you can decide to have only one write port but the compiler > > > will be more complex (it will have to manage all the write hazards). > > > > You always have write hasard with multi cycle instruction and variable > > latency. You need one port by unit + the memory load/store latency. It > > will never end ! > if even with only 2 ports it's not enough, then with only 1 port it's much worse :-/ > i beleive that you want avoid all contention that way. > > But that's not a problem most of the time. The problem > > is to immediatly reused the result, that could be done with the bypass net. > I agree in part with that, as long as the control logic remains > human-readable... > That's super easy, beside the register bank you read another unit (beside the scoreboard) to send a hit if the data is present. > > > > Do you remember the rules : if add 10% more silicium it must increase > > > > the speed by 10%, and i don't think that for the post incremental load. > > > i'm sorry but : > > > - the load and store instructions are _critical_ instructions in RISC world. > > Sur it's critical but having a double write port to write a data when > > the second could be take almost 150 cycles seems really big. > unless you code comme une loutre, this must not happen for every instruction, right ? > I don't know that une loutre could code ! > > If you force to make load/store determinisc, it's as you force to make a > > load inside the L0 cache and you only slide the problem. > of course, i push the problem where it's not a problem anymore. > All design activity is like that. So will reintroduice latency, that is usually hide by buffer, assynchronous operation,... > > As for the L0, it acts as a fine-grained reorder buffer, or a "write buffer", > or whatever, and current "big" CPUs have such things. i simply changed > or added some more functions. > This write buffer are inside the load/store unit and don't work as you describe it at all. > > > - the "10%" rule is valid for "classical" designs, while in the F-CPU case > > > we are in another "extreme" situation : > > > * silicon surface is not "expensive" (the package and the test is as > > > expensive so 10% more silicon is not "mecanically" 10% higher price) > > > > !!!! All this kind of things are linked, but chips are sold in mm² so, > > only the size is important. > however, when the size is proportional to the performance, what do you do ? > :-) > It's not really true ! And we look for the best ratio between mm²/E ... If you want more power put ... 2 fcpu :p > > I have well understood your cache which link register number and memory > > content. To speed up cache it's possible to use direct register 64 > > register of 256 bits. > it would be REALLY too big... and not useful because not every register > contains a "pointer". > You avoid the flag memory, big mixes and control. It's only 2KByte memory : very common, even in FPGA (in contrary of multiported memory...) > > It will be as fast as bank register access. But i don't see > > how you handel alias for data (an old thread soon speak about that). > > i have found 3 strategies to handle aliases in the LSU and the fetcher. > all have bad and good sides... please note that i avoid by all possible > means the use of an intermediary LUT that transforms the register > number into a L0 line number, because it creates an overhead. > The mechanism must be an "associative memory" : you give the key > and you get the data, not an index. > It's called CAM, it's used for TLB, it's sloooow and very big because you need an "xor" array to check egality of the key for each line. > 1) big and naughty : "copy everything." > the idea is that there is still a 1-to-1 association between a register > number and a physical line. But in this strategy, we allow the furiously > silly strategy of having the same logical address mapped to several physical > lines. This has the advantage that you can have as many aliases as there > are lines, but you imagine the crazy mess that maintains the coherency > between the lines... it _could_ be done but i don't like it because the > coherency management can become too close to a non-associative memory. > I'm sorry but i understand nothing. The problem is to have 2 or more registers which point to the same memory place. One could be coherent, so the others no. What happen if i try to access the memory thought the none coherent register. We must use the adress somewhere (as for typical write buffer). Or how to be sure to access to a good data without the use of that information. > 2) working with pairs of lines. > This sounds natural at first glance because the L0 buffers will > certainly use a double-buffering strategy. If we work by pairs, > there will be less problems with double-buffering. > I have counted that given 2 registers and 2 lines, there are 8 legal > associations, so it can be coded into 3 bits. This means that when > the comparison with the register number is successful, we need a very low > overhead to know which line is read. It is also reversible : given > an address, we can determine which register(s) to deallocate (for > example when we want to flush a line, we have to flush the associated > registers). This is good (tm) but the alias is limited to 2 registers. > So each line is assiociated to 2 registers. How do you do that ? with a double entry CAM ? And what if a stupid compiler create 3 aliases ? > 3) the '<=>' strategy > This one is a bit more sophisticated but it is similar to 2). > however here we now extend to 3 registers because we don't work > with pair, but 3 consecutive lines and registers. > register comparator number i can be associated to the line i-1, i or i+1. > One line is associated exclusively to 1 address (like 2)). > One register can be associated to one line, but one line can be linked > up to 3 registers (except when i=0 or i=7, there are ony 2 neighbours). > It more flexible for the double-buffering because there is more choice. > I have not finished my analysis but i think i'll work on that strategy. > > Warning ! > Augmenting the associativity will augment the overhead, so i think that > the 3rd method is a good compromise between simplicity, fexibility > and efficiency. using a 4-register neighbourhood will double the logic > and the overhead. the 3rd method already requires 22 memory bits and the > LRU and replacement strategy is more complex than the simple > direct-associativity strategy. > Sure ! But you don't solve the general cases (in fact the worst cases). This cache could work very well for jump but for data, there is so many coherency problem. Adding associativity aren't a good solution because you limit the number of possible aliases. I have understood that programmer don't like having such coding rules (they qualidied them "stupid" because they don't understand there usefullness) nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 24 20:49:27 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IXkO-0001Xv-00 for ; Mon, 24 Dec 2001 17:14:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 17:14:40 +0100 (CET) Received: (qmail 4965 invoked by uid 0); 24 Dec 2001 13:48:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 24 Dec 2001 13:48:24 -0000 Received: by moria.seul.org (Postfix) id 90AA01467EB; Mon, 24 Dec 2001 08:48:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 797111467ED; Mon, 24 Dec 2001 08:48:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id EF0A81467EB for ; Mon, 24 Dec 2001 08:48:22 -0500 (EST) Received: from ifrance.com (vlt5-185.n.club-internet.fr [194.158.108.185]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 67BA116D6 for ; Mon, 24 Dec 2001 14:48:20 +0100 (CET) Message-ID: <3C2786C7.F92702@ifrance.com> Date: Mon, 24 Dec 2001 14:49:27 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] EU precision, use of Q1,Q2,Q4, number inside the core References: <3C23F93C.4F316937@f-cpu.org> <20011222150530.23102@thrai.stud.uni-hannover.de> <3C26755E.A1ED6C1C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N An idea come to me few days ago. I hope it's not too late. I have followed a little the ffmpeg development : it's video compressor suite. The 40% of the time is taken inside a IDCT routine in mmx ASM. They were a flame war because the current IDCT have rounding problem and the image goes darker. An other routine as been written but was slower. My idea is to do as DSP do : create register with more bit than expected. For example, we could use 1 bit more for 8 bit operation, so 2 for 16 bit (signal processing), 4 in 32 bits. Its became Q1, Q2 and Q4 numbers. During write to memory there are dismiss. Comments ? nicO Yann Guidon a écrit : > > hi ! > > Michael Riepe wrote: > > On Sat, Dec 22, 2001 at 04:08:44AM +0100, Yann Guidon wrote: > > > > In the scheduler FIFO, i have two columns of N positions > > > (N-deep FIFO) with each the following informations : > > > - valid (1 bit) > > > - register number (6 bits) -> used during the register write cycle > > > - write mask (2 bits) -> used during the register write cycle > > > - write port (3 or 4 bits) -> used during the Xbar cycle to select the data > > > Each FIFO stage contains (for most bits) a register (that is clocked > > > by the main clock), a few comparators (for the register numbers) > > > and a MUX that selects either the previous stage's data OR the data coming > > > from the decoder's LUT. > > > It's crystal clear :) And it looks good to me. I would probably > > store a pre-decoded write mask (5 bits) instead, but that's a minor > > issue. > it is minor, and in fact only 2 bits are necessary. > the other bits are added at the bottom of the FIFO because > no "regular" operation writes to a specific 16-bit chunk. > The added bits are needed _only_ for the loadimm instructions, > which do not need to go through all the FIFO (they take only 2 cycles). > > > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 24 20:48:12 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IbrT-0004lQ-00 for ; Mon, 24 Dec 2001 21:38:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Dec 2001 21:38:15 +0100 (CET) Received: (qmail 23451 invoked by uid 0); 24 Dec 2001 19:44:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 24 Dec 2001 19:44:53 -0000 Received: by moria.seul.org (Postfix) id 51E3E1467F2; Mon, 24 Dec 2001 14:44:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 33A641467F5; Mon, 24 Dec 2001 14:44:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id E1E8B1467F2 for ; Mon, 24 Dec 2001 14:44:52 -0500 (EST) Received: from f-cpu.org (kdl11-19.n.club-internet.fr [213.44.9.19]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 6DBC0169F for ; Mon, 24 Dec 2001 20:44:50 +0100 (CET) Message-ID: <3C27867C.41BB54FE@f-cpu.org> Date: Mon, 24 Dec 2001 20:48:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] EU precision, use of Q1,Q2,Q4, number inside the core References: <3C23F93C.4F316937@f-cpu.org> <20011222150530.23102@thrai.stud.uni-hannover.de> <3C26755E.A1ED6C1C@f-cpu.org> <3C2786C7.F92702@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > > An idea come to me few days ago. I hope it's not too late. I have > followed a little the ffmpeg development : it's video compressor suite. > > The 40% of the time is taken inside a IDCT routine in mmx ASM. They were > a flame war because the current IDCT have rounding problem and the image > goes darker. An other routine as been written but was slower. can't they use dithering to offset the rounding loss ? > My idea is to do as DSP do : create register with more bit than > expected. For example, we could use 1 bit more for 8 bit operation, so 2 > for 16 bit (signal processing), 4 in 32 bits. Its became Q1, Q2 and Q4 > numbers. During write to memory there are dismiss. > > Comments ? yep :-) DCT requires some minimal amount of precision, sure. the little problem is that adding one bit or two or even four might not be enough. PLus, the necessary precision depends on the number of operations (the depth of the dataflow). "the way i would do it" is : - use larger registers. good news : the f-cpu instruction set is much handy and useful than MMX. the little loss in performance will be balanced by the ease of coding. Imagine : not 8 but 64 registers ! :-) you can nearly fit a whole 8*8 DCT inside the registers. the time that MMX spends laoding/storing data can be compared to the loss of performance when larger data chunks are used (32 bits instead of 16 bits). - use one of the alternate data representations : either LNS or fractional. LNS is not yet easy to implement but fractional data support is reduced to a MUX that shifts the results by one bit (or two depending on the operation). Usually, the shift is performed by the operator but that could be performed by the Xbar (?) on FC0. We still have one reserved bit in the opcodes, so implementing fractional (1Qx) data format is not a problem, when looking at the whole F-CPU ISA. In fact, i have reserved this bit from the beginning, like a "souvenir" >from the days i hacked DSPs. i knew it would be useful :-) However, adding "hidden bits" is a big no-no for the simple reason that it requires special handling and it breaks the symmetry of the ISA. Using large registers and fractional format is enough IMHO. Unless there's a detail i missed... But this summer, i worked on FFT/DCT so i should not be completely wrong. Just in case of doubt, nicO can read the CD i gave him, it contains a lot of implementation notes of FFT, DCT, MMX, .... merry Xmas eve ! > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Dec 25 10:23:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IuH0-0000G9-00 for ; Tue, 25 Dec 2001 17:17:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Dec 2001 17:17:50 +0100 (CET) Received: (qmail 8336 invoked by uid 0); 25 Dec 2001 09:23:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 25 Dec 2001 09:23:54 -0000 Received: by moria.seul.org (Postfix) id 57B871467EC; Tue, 25 Dec 2001 04:23:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CBCF1467F4; Tue, 25 Dec 2001 04:23:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id D321D1467EC for ; Tue, 25 Dec 2001 04:23:50 -0500 (EST) Received: from art1.none.de (f-dialin-257.addcom.de [62.96.140.17]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id fBP9NqV29255 for ; Tue, 25 Dec 2001 10:23:52 +0100 X-Authentication-Warning: host-2.server.itns.de: Host f-dialin-257.addcom.de [62.96.140.17] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.33 #1 (Debian)) id 16Inou-0000Ca-00 for ; Tue, 25 Dec 2001 10:24:24 +0100 Date: Tue, 25 Dec 2001 10:23:58 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] CCC-CD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Is there a chance to get the F-CPU-CD from the upcoming CCC? I must be at home. Any hints? Thanks Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8KEWyClxplZklbgERAgxkAKCLPSIzjD8BrzUsQh56moE5tCi2ngCfVrX9 UZGRaGoJxzsh1y/5Xp7vX7o= =37jS -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 25 15:43:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16IuH3-0000G9-01 for ; Tue, 25 Dec 2001 17:17:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Dec 2001 17:17:53 +0100 (CET) Received: (qmail 8050 invoked by uid 0); 25 Dec 2001 14:40:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 25 Dec 2001 14:40:40 -0000 Received: by moria.seul.org (Postfix) id 1345C1467EF; Tue, 25 Dec 2001 09:40:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B87931467F5; Tue, 25 Dec 2001 09:40:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 1358B1467EF for ; Tue, 25 Dec 2001 09:40:36 -0500 (EST) Received: from f-cpu.org (kdl1-106.n.club-internet.fr [213.44.0.106]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 45675169E for ; Tue, 25 Dec 2001 15:40:33 +0100 (CET) Message-ID: <3C2890AC.530213C7@f-cpu.org> Date: Tue, 25 Dec 2001 15:43:56 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] snapshot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i am currently uploading two files, one is my most up-to-date snapshot and the other is another version with the illustrations only. I recently added a few .eps files that illustrate how the scheduler works. look at http://f-cpu.seul.org/new and merry Xmas ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 25 17:50:21 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16J0Hd-0004fZ-00 for ; Tue, 25 Dec 2001 23:42:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Dec 2001 23:42:53 +0100 (CET) Received: (qmail 26450 invoked by uid 0); 25 Dec 2001 16:47:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 25 Dec 2001 16:47:13 -0000 Received: by moria.seul.org (Postfix) id ABBDA1467F6; Tue, 25 Dec 2001 11:47:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66CA41467F9; Tue, 25 Dec 2001 11:47:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id A4B421467F6 for ; Tue, 25 Dec 2001 11:47:06 -0500 (EST) Received: from f-cpu.org (kdl1-207.n.club-internet.fr [213.44.0.207]) by relay-1v.club-internet.fr (Postfix) with ESMTP id C002516A7 for ; Tue, 25 Dec 2001 17:47:01 +0100 (CET) Message-ID: <3C28AE4D.123C5910@f-cpu.org> Date: Tue, 25 Dec 2001 17:50:21 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CCC-CD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Andreas Romeyke wrote: > Is there a chance to get the F-CPU-CD from the upcoming CCC? > I must be at home. do you mean that you live in Berlin ? > Any hints? this dependend on Cedric and nicO. if you go to HAKP, you can't miss them : there are not many french people there ;-) hint : for nicO, search pink hair... :-P > Thanks i simply hope that the CD burners will work and (more important) nobody will "keep the master CD for himself" like it happened last year... > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Dec 25 19:06:09 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16J0Hd-0004fZ-01 for ; Tue, 25 Dec 2001 23:42:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Dec 2001 23:42:53 +0100 (CET) Received: (qmail 23625 invoked by uid 0); 25 Dec 2001 18:02:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 25 Dec 2001 18:02:55 -0000 Received: by moria.seul.org (Postfix) id D900B1467F9; Tue, 25 Dec 2001 13:02:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD2101467FE; Tue, 25 Dec 2001 13:02:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id F328A1467F9 for ; Tue, 25 Dec 2001 13:02:52 -0500 (EST) Received: from f-cpu.org (kdl16-153.n.club-internet.fr [213.44.18.153]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 4CD3616A6 for ; Tue, 25 Dec 2001 19:02:50 +0100 (CET) Message-ID: <3C28C011.3631BCE3@f-cpu.org> Date: Tue, 25 Dec 2001 19:06:09 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] upload finally succeeded Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, http://f-cpu.seul.org/new/snapshot_yg_12_25_2001.tgz is finally up and complete. It seems that there are some upload problems that interrupted the process... the third attempt was the right one. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 26 04:57:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16J8Z1-00027r-00 for ; Wed, 26 Dec 2001 08:33:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Dec 2001 08:33:23 +0100 (CET) Received: (qmail 8847 invoked by uid 0); 26 Dec 2001 03:54:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 26 Dec 2001 03:54:33 -0000 Received: by moria.seul.org (Postfix) id C84591467FF; Tue, 25 Dec 2001 22:54:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C255C1467FE; Tue, 25 Dec 2001 22:54:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 680D71467EA for ; Tue, 25 Dec 2001 22:54:30 -0500 (EST) Received: from f-cpu.org (kdl21-50.n.club-internet.fr [213.44.96.50]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 0DFDF16C7 for ; Wed, 26 Dec 2001 04:54:27 +0100 (CET) Message-ID: <3C294ABF.F45B4A3A@f-cpu.org> Date: Wed, 26 Dec 2001 04:57:51 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] "stable" source package Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i have started to "cleanup" my local files in a separate directory and i am preparing a "stable" release, with all the development hacks and temporary stuffs removed. I hope that it will be useful to newcomers (that is : most of the subscribers :-D). I'll upload it probably tomorrow on seul.org. I have already cleaned all the root files and i am entering the VHDL directory, where most files are located... There are still hours of work ahead :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 26 05:29:13 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16J8Z1-00027r-01 for ; Wed, 26 Dec 2001 08:33:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Dec 2001 08:33:23 +0100 (CET) Received: (qmail 20910 invoked by uid 0); 26 Dec 2001 04:25:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 26 Dec 2001 04:25:56 -0000 Received: by moria.seul.org (Postfix) id 0736C1467EA; Tue, 25 Dec 2001 23:25:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E24471467FE; Tue, 25 Dec 2001 23:25:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 5E6F51467EA for ; Tue, 25 Dec 2001 23:25:54 -0500 (EST) Received: from f-cpu.org (kdl11-6.n.club-internet.fr [213.44.9.6]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B930616A9 for ; Wed, 26 Dec 2001 05:25:49 +0100 (CET) Message-ID: <3C295219.6E349B11@f-cpu.org> Date: Wed, 26 Dec 2001 05:29:13 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] CHARTER.txt Content-Type: multipart/mixed; boundary="------------E2BCA62F409B832BB11C81EE" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------E2BCA62F409B832BB11C81EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ooops, i have forgotten to write that, during the file update process, i have added some precisions in the charter. I do not consider this as definitive but it addresses the requests from nicO and Michael. I have enclosed the new proposed version. The additions are at the bottom. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------E2BCA62F409B832BB11C81EE Content-Type: text/plain; charset=us-ascii; name="CHARTER.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CHARTER.txt" ~~~~~~~~~~~~~~~~~~~~~~~~~~~HEADER~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CHARTER.txt Revision : file created : nov. 23, 2000 by YG current version : dec. 26, 2001 by YG (preliminary) Like everything in the F-CPU project, it is a basis and subject for constructive discussions and it should not be considered as definitive. Everybody is asked to contribute to this decisive, non-technical side of the project. I have cut&pasted some parts of the previous "F-CPU licence proposal". It is still incomplete. ~~~~~~~~~~~~~~~~~~~~~~~~~INTRODUCTION~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Freedom CPU project (F-CPU for short) is the only fully parametised 64-bit SIMD CPU core available today in source code form. Not only it is intended to be able to replace (one day) the best existing RISC processors in workstations, but it is being developped in a net-community environment by students as well as professionals as a hobby. Because their work is performed for free, they want it to remain free, just like Linux or the GNU project. Unfortunately, this is not a "software-only" project. The purpose of this file is to introduce newcomers to the F-CPU design philosophy and basic rules. More about this can be read on the F-CPU mailing list(s) and manual. Because the GNU Public Licence covers most of the needs of the project, it is the only licence that you have to comply with. It determines the rights and duties concerning the distribution, modification, compilation etc. of the "source code" of the processor (that is : the VHDL sources contained in this tarball). However, the GPL doesn't apply to the "electronic" world and the implementors are completely free to do whatever they want with the derived physical devices. You don't have to read the rest of this file if you only want to use the files without modification. For example, it is not revelant if you just install the bundle and try to compile the files. However, if you modify a file, add a new file, adapt a file for compilation with a tool, build the circuit or add features, you should carefully read this text. This charter is intended to provide developpers with guidelines, "do and don't" rules that should be followed to keep the project up and running. If a chip is built from the F-CPU sources then distributed, the respect of these rules will determine if the chip can be labelled as "a F-CPU". The use of the F-CPU source files is completely free under the terms of the GPL, the implementation is not bound in any way, but the F-CPU development team follows some basic rules. Finally, one can say that the F-CPU project is subject to the laws of thermodynamics : "you don't get anything for free" and "you don't get what you want the way you want". It's a bit far fetched but we have some entropy, too ... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~GUIDELINES~~~~~~~~~~~~~~~~~~~~~~~~~ o - "The name of the game is freedom". - "It is forbidden to forbid others". - "One's freedom ends where others' freedom starts". These three well-known basic rules favor reciprocal respect and positive ununcumbered work. o We promote collaborative work, free communication and unconstrained sharing of knowledge and know-how. This project is not a way to earn money quickly and easily, but a mean to learn technics in a community, with the goal of redistributing the knowledge evenly. If you remember how you learnt things, you'll be happy that what you redistribute helps others in the same way. o The distribution, modification and knowledge of the sources (non physical forms of the design, as opposed to the "physical implementation" of this design) must not be bound or restricted in ANY way. This is a TINY but crucial modification to the GPL. o In particular, you need not be a customer of a F-CPU vendor in order to access the sources of any F-CPU version or derived work. The privacy rights (as promoted in the GPL) are opposed to the authors' rights in this case. o Similarly, in-progress works must be available upon a single request. An attempt to over-delay the transmission of the requested files can be interpreted as a "guilty" behaviour. Ususally, you don't need two weeks to email a file to a co-worker. This measure is necessary to prevent people from arguing that "i can't send it to you, it's an ongoing work". Blocking/stalling development through obfuscation and delay is not welcome. o The reason for this break from the GPL principle is simple : the F-CPU is not the property of an individual or a company, but it belongs to everybody. Anybody must be able to examine, use or modify any version of any document because it is not the exclusive property of a single person. If you have your kid in a kindergarten, you think it is normal to visit the location and see if your kid is safe or if nothing wrong can happen. Same goes with software that we write in community. o Do not promote secrecy. Just as the sources came to you openly, you should not promote secrets or hidden features. It is forbidden to patent existing features used in the F-CPU. The F-CPU forums and mailing lists provide you with different ways to share your remarks, additions, propositions, etc. Secrecy has no advantage in the F-CPU community and corresponds to a self-exclusion from the group. o Do not bind the files to a proprietary software or obscure file format. Anybody should be able to reuse your work without being forced to acquire a specific software. Standard formats are highly recommended (ISO, ANSI etc), GNU software is preferred, freeware or public domain is ok, too. If you use a "specific" software, you can add the required scripts or configuration files that interface the F-CPU source with said software. o When a source file is modified, the developer must update the comments and indicate his name, the date, and a short description of the modifications. It is the easiest way to keep track of the project's evolution. It is often overlooked in CVS environment, read QUALITY.TXT for the rationale. o When a source file is added to the F-CPU file pool, it must be distributed under the same terms as the others in this package. o Whenever a file is created or modified, the developper has to include his personal copyright notice. It is a crucial legal protection mechanism because different copyrights get thus inter-mixed. This strengthens the relationships and dependencies between the developpers. If a legal problem arises, a single developper will not be attacked alone. Similarly, more programers have more weight than an isolated one, if a problem arises. o Please : document and comment your modifications or additions, because/as you can read and understand the existing sources. The lack of decent documentation, just like obfuscated source code, slows down the development team's work. o All documentations written about the F-CPU and the associated software must be distributed under the terms of the GFDL (GNU Free Documentation Licence). This applies to manuals, technical books, drafts or requests for comments (RFCs). o Personal opinions, articles or other individual expressions about the F-CPU are well covered by the copyright laws (that means that an article or conference doesn't need to be bound by the GFDL). o Even though the GLP allows to sell physical media containing GPL'd files, the present guidelines only allow it if the same files are available for free on the Internet with the conditions described here. This is consistent with the fact that the packaging of the files on a physical medium is a service only, it is not an exception to the present guidelines. o The modification of the F-CPU design is allowed under the sole condition that you agree to and respect these guidelines. o You do not have to register yourself in a database, you do not need any authorization of any kind and you can do whatever you want with the F-CPU design, except : changing the copyright notices, altering these guidelines or use them against their intent (explained in this document). o Unlike some "Open" standards and initiatives, you do not need to fill in a form, pay a fee or a licence to use the F-CPU design. In return, you may not restrict the direct access to the design that you have modified, even for the sake of collecting statistics or polling (or, in general, collecting individual/personal data or going through advertising pages). You can apply the privacy rights here. o Binding : As long as the files are not altered, it is possible to "compile"/"synthesise" the F-CPU source code for any platform or technology. It is the same thing as compiling C sources (under GPL) for different CPUs, whatever their implementation. This means that you can use "proprietary" memory modules or cell libraries if their behaviour matches exactly the F-CPU specifications and if the necessary support files are provided. Usually, when the modules are automatically mapped by a synthesiser, there is no problem. o Extension of the licence terms : The GPL and this charter apply to all the files (and documents, but under GFDL) that constitute the F-CPU project, which is aimed at designing a CPU core, an Instruction Set Architecture and the necessary support software. * This includes all the components inside the core : the execution pipeline, the scheduler, the memory buffers, the L1 cache, the BIST, the Special Registers, ... * This does not include components that are connected to the core through the F-CPU-defined interfaces (including clock, reset and memory signals). The F-CPU core communicates with other components through its memory interface, it can communicate with other other "external components" without requiring them to be available under GPL. One can draw an analogy with the GNU EMACS software that can run under Microsoft Windows without requiring Microsoft to release its source code. In all cases, the problems boil down to the openness of the chosen interface. F-CPU must only use unencumbered standards and protocols. o to be continued... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DISCLAIMERS : Nobody will endorse or encourage the use of the F-CPU's work in any critical environment or where life is at sake, including (but not limited to) space, medical or military equipment. The Freedom CPU project is a pacific research effort and can not be held responsible for the misuse of its material. This is an ever-evolving collection of documents and source code where bugs can hide easily. We count on your good sense and your responsibility. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These recommendations can be enforced through the copyright laws and are added to the terms of the GPL. If we get enough legal advices, a F-CPU licence will probably be written. Remember : the Freedom Project is not the GNU project and is not bound to the FSF. Furthermore, the GPL is not perfect. Stay tuned for any licence modification or refinement. --------------E2BCA62F409B832BB11C81EE-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 26 19:37:52 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JDke-0005ay-00 for ; Wed, 26 Dec 2001 14:05:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 26 Dec 2001 14:05:44 +0100 (CET) Received: (qmail 22314 invoked by uid 0); 26 Dec 2001 12:36:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 26 Dec 2001 12:36:39 -0000 Received: by moria.seul.org (Postfix) id 7D9B31467FE; Wed, 26 Dec 2001 07:36:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60362146805; Wed, 26 Dec 2001 07:36:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 034491467FE for ; Wed, 26 Dec 2001 07:36:38 -0500 (EST) Received: from ifrance.com (vlt11-112.n.club-internet.fr [195.36.224.112]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 57654169E for ; Wed, 26 Dec 2001 13:36:34 +0100 (CET) Message-ID: <3C2A1900.8C9267C@ifrance.com> Date: Wed, 26 Dec 2001 13:37:52 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CCC-CD References: <3C28AE4D.123C5910@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello ! > > Andreas Romeyke wrote: > > Is there a chance to get the F-CPU-CD from the upcoming CCC? > > I must be at home. > do you mean that you live in Berlin ? > > > Any hints? > this dependend on Cedric and nicO. > if you go to HAKP, you can't miss them : there > are not many french people there ;-) > hint : for nicO, search pink hair... :-P Vendu ! I don't know if she come ! > > > > Thanks > i simply hope that the CD burners will work and > (more important) nobody will "keep the master CD > for himself" like it happened last year... > > > Bye Andreas > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 26 20:32:57 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXch-0001kW-00 for ; Thu, 27 Dec 2001 11:18:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:51 +0100 (CET) Received: (qmail 27420 invoked by uid 0); 26 Dec 2001 13:31:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 26 Dec 2001 13:31:52 -0000 Received: by moria.seul.org (Postfix) id 2AA42146801; Wed, 26 Dec 2001 08:31:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 13A8A146806; Wed, 26 Dec 2001 08:31:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 572A1146801 for ; Wed, 26 Dec 2001 08:31:46 -0500 (EST) Received: from ifrance.com (vlt11-55.n.club-internet.fr [195.36.224.55]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5BE9F18F0 for ; Wed, 26 Dec 2001 14:31:39 +0100 (CET) Message-ID: <3C2A25E9.1F8A8CEA@ifrance.com> Date: Wed, 26 Dec 2001 14:32:57 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] cachemm instruction References: <3C28AE4D.123C5910@f-cpu.org> <3C2A1900.8C9267C@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just reread the instruction description of cachemm : beark ! (compression/decompression flag, virtual memory hint (!)) Even the description isn't so good. (base+offset). What does it means ? Must we do a loops to count all the cache line ? Must we calculate the end of the bloc ? So i propose to use a base + a mask or just a management paged based. And how many of this instruction could taken into account (1 ,8 ?) ? All locks and things like that are far to much implementation dependant. The same cpu with different implementaton could lose a lot of performance (imagine a lock then the use of a L1 data cache one-way instead of the 2-way cache that you use before). Maybe we could find someway to said what we want to do instead of say what the processor must do. We could exprime : this bloc will be used often, this bloc is only used one time, ... This instruction manage prefetch and are supposed to fill L0 cache. Comments ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 26 20:41:43 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXch-0001kW-01 for ; Thu, 27 Dec 2001 11:18:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:51 +0100 (CET) Received: (qmail 3330 invoked by uid 0); 26 Dec 2001 13:40:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 26 Dec 2001 13:40:33 -0000 Received: by moria.seul.org (Postfix) id 3374C146805; Wed, 26 Dec 2001 08:40:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19B69146807; Wed, 26 Dec 2001 08:40:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id A726E146805 for ; Wed, 26 Dec 2001 08:40:31 -0500 (EST) Received: from ifrance.com (vlt11-55.n.club-internet.fr [195.36.224.55]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 245B01694 for ; Wed, 26 Dec 2001 14:40:25 +0100 (CET) Message-ID: <3C2A27F7.5CF31902@ifrance.com> Date: Wed, 26 Dec 2001 14:41:43 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] PC management ? References: <3C28AE4D.123C5910@f-cpu.org> <3C2A1900.8C9267C@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Why the PC isn't mapped inside the register bank ? Is there is specific reason ? Because cJump/cmove are really similar. And there is some instruction to produice hit in specific adresse. Concerning the gestion of the L0. I propose to say that the alias aren't manage at all. BUT we must see how a c compiler could handel pointer. I'm really afraid that that it's almost impossible to be sure that some C code use to much pointer to the same area. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 26 16:21:16 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXcj-0001kW-00 for ; Thu, 27 Dec 2001 11:18:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:53 +0100 (CET) Received: (qmail 32448 invoked by uid 0); 26 Dec 2001 15:17:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 26 Dec 2001 15:17:56 -0000 Received: by moria.seul.org (Postfix) id A2A01146806; Wed, 26 Dec 2001 10:17:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 82B9F146808; Wed, 26 Dec 2001 10:17:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id EA497146806 for ; Wed, 26 Dec 2001 10:17:53 -0500 (EST) Received: from f-cpu.org (kdl16-222.n.club-internet.fr [213.44.18.222]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C3E5916B7 for ; Wed, 26 Dec 2001 16:17:50 +0100 (CET) Message-ID: <3C29EAEC.E458AD1B@f-cpu.org> Date: Wed, 26 Dec 2001 16:21:16 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PC management ? References: <3C28AE4D.123C5910@f-cpu.org> <3C2A1900.8C9267C@ifrance.com> <3C2A27F7.5CF31902@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Why the PC isn't mapped inside the register bank ? because it would become a limiting factor, a "bottleneck", just as "flags" would be. > Is there is specific reason ? Because cJump/cmove are really similar. > And there is some instruction to produice hit in specific adresse. I can think of at least one specific and good reason : the pipeline. During the first stages (specifically fetch, decode and Xbar), there are 3 different values of PC. Having one "logical" PC would cause some problems. If you have no "PC" then you have no problem. Of course, the scheduler selects the right PC value upon IRQ or fault, and writes it to the LSU for the backup. > Concerning the gestion of the L0. I propose to say that the alias aren't > manage at all. BUT we must see how a c compiler could handel pointer. > I'm really afraid that that it's almost impossible to be sure that some > C code use to much pointer to the same area. One has to live dangerously, or nothing gets ever done :-) i'll try to work on a better aliasing system, which would allow up to 4 registers to use a single L0 line. Then it should be enough for common cases. Note that when a program is compiled, the allocation of the global and local addresses is performed at the end, when we know the access patterns. In an adapted compiler, we can modify the allocation rules with a better algorithm. HOWEVER, because the jump takes one cycle instead of none, we could change the memory system (sorry, i call "memory system" the LSU+fetcher+TLB block) into a 2-level LUT system, as i first envisioned it. then all the aliasing problems are gone. the 64-entry LUT will become very difficult to manage, however :-( [this is the reason why i developped the system as we now know it). what do you think ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Dec 26 16:21:22 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXck-0001kW-00 for ; Thu, 27 Dec 2001 11:18:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:54 +0100 (CET) Received: (qmail 6551 invoked by uid 0); 26 Dec 2001 15:18:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 26 Dec 2001 15:18:00 -0000 Received: by moria.seul.org (Postfix) id ABD5A146808; Wed, 26 Dec 2001 10:17:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C58714680A; Wed, 26 Dec 2001 10:17:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 235DD146808 for ; Wed, 26 Dec 2001 10:17:59 -0500 (EST) Received: from f-cpu.org (kdl16-222.n.club-internet.fr [213.44.18.222]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 24C0216F9 for ; Wed, 26 Dec 2001 16:17:56 +0100 (CET) Message-ID: <3C29EAF2.C432486F@f-cpu.org> Date: Wed, 26 Dec 2001 16:21:22 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CCC-CD References: <3C28AE4D.123C5910@f-cpu.org> <3C2A1900.8C9267C@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > Yann Guidon a écrit : > > hint : for nicO, search pink hair... :-P > Vendu ! I don't know if she come ! i'm just teasing you, i don't even know her email address :*) whether she comes or not, don't forget to have fun, too, and mind your mobile phone. ok, i just woke up, it's now time to work... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Dec 26 18:13:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXck-0001kW-01 for ; Thu, 27 Dec 2001 11:18:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:54 +0100 (CET) Received: (qmail 21490 invoked by uid 0); 26 Dec 2001 17:11:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 26 Dec 2001 17:11:57 -0000 Received: by moria.seul.org (Postfix) id EFC2714680A; Wed, 26 Dec 2001 12:11:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D776E14680D; Wed, 26 Dec 2001 12:11:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0922B14680A for ; Wed, 26 Dec 2001 12:11:55 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16JHcl-0001fD-00 for f-cpu@seul.org; Wed, 26 Dec 2001 18:13:51 +0100 Date: Wed, 26 Dec 2001 18:13:51 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] PC management ? In-Reply-To: <3C2A27F7.5CF31902@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 26 Dec 2001, nicO wrote: > Why the PC isn't mapped inside the register bank ? > > Is there is specific reason ? Because cJump/cmove are really similar. > And there is some instruction to produice hit in specific adresse. > > Concerning the gestion of the L0. I propose to say that the alias aren't > manage at all. BUT we must see how a c compiler could handel pointer. > I'm really afraid that that it's almost impossible to be sure that some > C code use to much pointer to the same area. Usually most pointers are computed out of base pointers and offset when it's needed, e.g. array/structure/class access. But this should only affect data cache access. Is it also setup in lines? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Dec 25 19:24:37 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16JXcn-0001kW-01 for ; Thu, 27 Dec 2001 11:18:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 27 Dec 2001 11:18:57 +0100 (CET) Received: (qmail 31609 invoked by uid 0); 26 Dec 2001 19:45:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 26 Dec 2001 19:45:07 -0000 Received: by moria.seul.org (Postfix) id 94FF514680E; Wed, 26 Dec 2001 14:45:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5C43A146811; Wed, 26 Dec 2001 14:45:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 3376414680E for ; Wed, 26 Dec 2001 14:45:02 -0500 (EST) Received: from art1.none.de (d-dialin-650.addcom.de [62.96.161.178]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id fBQJj6V00862 for ; Wed, 26 Dec 2001 20:45:06 +0100 X-Authentication-Warning: host-2.server.itns.de: Host d-dialin-650.addcom.de [62.96.161.178] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.33 #1 (Debian)) id 16IwGK-0001Ye-00 for ; Tue, 25 Dec 2001 19:25:16 +0100 Date: Tue, 25 Dec 2001 19:24:37 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] CCC-CD In-Reply-To: <3C28AE4D.123C5910@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello YG, On Tue, 25 Dec 2001, Yann Guidon wrote: > hello ! > > Andreas Romeyke wrote: > > Is there a chance to get the F-CPU-CD from the upcoming CCC? > > I must be at home. > do you mean that you live in Berlin ? Nope, God save me. I am a Saxon. :) I come from Leipzig, Germany... I cannot be at CCC. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8KMRoClxplZklbgERArqdAJ99li8z7BHM7HVIjrS0HajbEgK3TQCbB1tz lJyhgmbl2HQnoUfeuzq9GRY= =kJBX -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Dec 31 00:24:48 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16KoGr-0000Fr-00 for ; Sun, 30 Dec 2001 23:17:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 30 Dec 2001 23:17:33 +0100 (CET) Received: (qmail 2895 invoked by uid 0); 30 Dec 2001 19:34:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 30 Dec 2001 19:34:53 -0000 Received: by moria.seul.org (Postfix) id 8847D146836; Sun, 30 Dec 2001 14:34:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6469714683B; Sun, 30 Dec 2001 14:34:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 7E629146836 for ; Sun, 30 Dec 2001 14:34:51 -0500 (EST) Received: from art1.none.de (f-dialin-1925.addcom.de [62.96.147.5]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id fBUJYtV03980 for ; Sun, 30 Dec 2001 20:34:55 +0100 X-Authentication-Warning: host-2.server.itns.de: Host f-dialin-1925.addcom.de [62.96.147.5] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.33 #1 (Debian)) id 16KpKa-0005Hu-00 for ; Mon, 31 Dec 2001 00:25:28 +0100 Date: Mon, 31 Dec 2001 00:24:48 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] Is there anybody interested in writing an article about f-cpu/fc0? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, GAOS commits periodically a free available brochure about free technologies (in German, in case of freedom, not free beer). Is anybody interested in writing an article (English or German, is equal) there? The target group is advanced, with a more technical than political view. Wanted is a technical overview about f-cpu and its first implementation fc0, the current state of development, methods and techniques which makes programmers life easier. My sparetime is limited and my technical comprehension in this case is similiar with amateur/hobbyist, but I would cowriting the article. Bye Andreas PS.: The article could be reuseable used -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8L6JDClxplZklbgERAiQNAKCQEHao+N7YaCmO9z3lZSCdtVsNMgCeN9R8 xMWh4IkwGNo6ErNsyBQyyyE= =jPGp -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 31 03:11:56 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCU-0000d0-01 for ; Tue, 01 Jan 2002 01:54:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:42 +0100 (CET) Received: (qmail 1561 invoked by uid 0); 31 Dec 2001 02:08:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 31 Dec 2001 02:08:47 -0000 Received: by moria.seul.org (Postfix) id 22B1A1467EA; Sun, 30 Dec 2001 21:08:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD65C1467EC; Sun, 30 Dec 2001 21:08:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4D0C91467EA for ; Sun, 30 Dec 2001 21:08:37 -0500 (EST) Received: from f-cpu.org (kdl1-31.n.club-internet.fr [213.44.0.31]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7CCBD16BC for ; Mon, 31 Dec 2001 03:08:31 +0100 (CET) Message-ID: <3C2FC96C.549EDCED@f-cpu.org> Date: Mon, 31 Dec 2001 03:11:56 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Is there anybody interested in writing an article about f-cpu/fc0? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Andreas Romeyke wrote: > Hello, > > GAOS commits periodically a free available brochure about free > technologies (in German, in case of freedom, not free beer). Is anybody > interested in writing an article (English or German, is equal) there? The > target group is advanced, with a more technical than political view. > Wanted is a technical overview about f-cpu and its first implementation > fc0, the current state of development, methods and techniques which makes > programmers life easier. I can start to write a part, as an english translation of an article i have to write for a french magazine. What is the expected size ? is it for a paper issue or electronic publication ? Can you point us to past issues ? > My sparetime is limited and my technical comprehension in this case is > similiar with amateur/hobbyist, but I would cowriting the article. At least you can reread and correct (grammatical/edition) errors, i hope :-) > Bye Andreas > > PS.: > The article could be reuseable used i hope so :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 31 05:52:55 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCV-0000d0-00 for ; Tue, 01 Jan 2002 01:54:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:43 +0100 (CET) Received: (qmail 6338 invoked by uid 0); 31 Dec 2001 04:49:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 31 Dec 2001 04:49:39 -0000 Received: by moria.seul.org (Postfix) id D7C1B1467EA; Sun, 30 Dec 2001 23:49:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B75FB1467EC; Sun, 30 Dec 2001 23:49:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 593B11467EA for ; Sun, 30 Dec 2001 23:49:36 -0500 (EST) Received: from f-cpu.org (kdl21-1.n.club-internet.fr [213.44.96.1]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 80AC5168D for ; Mon, 31 Dec 2001 05:49:33 +0100 (CET) Message-ID: <3C2FEF27.8DF81818@f-cpu.org> Date: Mon, 31 Dec 2001 05:52:55 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] about the ongoing work for the "stable" release Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, since a week i started to cleanup my files so they look better and can live together... some stats : * the .tgz is larger than 280KB, including the ygasm, some EPS and their sources, the VHDL-HOWTO and some deprecated files. * it works for simili and vanilla VHDL but the full detection script is not updated. i'm currently running in "raw script mode", where i assume va87 and vhdlp work. * the "core" contains currently 24 VHDL files, i estimate that it is the quarter or the fifth of the total size, NOT including the testbenches. It looks promising but i fear that the remaining week of vacations will not be enough. I'll upload the tarball on seul in a few days, so other people can reuse it and start to work on the INC, POPC, IDU, TLB... However i have still some difficulties to work with Michael's files. I hope i'll find the courage to read his files ;-) @+ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 31 10:47:51 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCY-0000d0-00 for ; Tue, 01 Jan 2002 01:54:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:46 +0100 (CET) Received: (qmail 12895 invoked by uid 0); 31 Dec 2001 09:45:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 31 Dec 2001 09:45:02 -0000 Received: by moria.seul.org (Postfix) id 4F7FF1467EA; Mon, 31 Dec 2001 04:45:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4631B1467EC; Mon, 31 Dec 2001 04:45:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C94501467EA for ; Mon, 31 Dec 2001 04:45:00 -0500 (EST) Received: from f-cpu.org (kdl11-142.n.club-internet.fr [213.44.9.142]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9A4D51696 for ; Mon, 31 Dec 2001 10:44:44 +0100 (CET) Message-ID: <3C303447.CF1BBBC2@f-cpu.org> Date: Mon, 31 Dec 2001 10:47:51 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] your new year's gift :-P Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, there is a first "preliminary/candidate" "stable" FC0 source package. it weights 301099 bytes and i'm uploading it on seul.org at the usual address. Please have a look, correct, comment, etc., and have fun while i sleep ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Dec 31 14:40:32 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCY-0000d0-01 for ; Tue, 01 Jan 2002 01:54:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:46 +0100 (CET) Received: (qmail 5838 invoked by uid 0); 31 Dec 2001 10:42:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 31 Dec 2001 10:42:37 -0000 Received: by moria.seul.org (Postfix) id 84DF01467EA; Mon, 31 Dec 2001 05:42:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66A021467EC; Mon, 31 Dec 2001 05:42:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 9EBB91467EA for ; Mon, 31 Dec 2001 05:42:34 -0500 (EST) Received: from art1.none.de (d-dialin-1634.addcom.de [62.96.165.202]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id fBVAgaV24750 for ; Mon, 31 Dec 2001 11:42:36 +0100 X-Authentication-Warning: host-2.server.itns.de: Host d-dialin-1634.addcom.de [62.96.165.202] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.33 #1 (Debian)) id 16L2gi-0002bv-00 for ; Mon, 31 Dec 2001 14:41:12 +0100 Date: Mon, 31 Dec 2001 14:40:32 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] Is there anybody interested in writing an article about f-cpu/fc0? In-Reply-To: <3C2FC96C.549EDCED@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Mon, 31 Dec 2001, Yann Guidon wrote: > I can start to write a part, as an english translation of an article > i have to write for a french magazine. What is the expected size ? > is it for a paper issue or electronic publication ? Can you point us > to past issues ? There is an TeX-Style, the brochure will be available in printed and online form. The size of an article is 6 A4-pages in average, multi-column and boxes are possible. An previous issue is on cvs at cvs.gaos.org -> gaosjournal (i think)... > At least you can reread and correct (grammatical/edition) errors, i hope :-) I'll do my best. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8MGrUClxplZklbgERArDKAJ9BfzZ4Alqq7VeEEnnTMqkHAhGqzACfRiW+ LSg0xB2iV12ma3faqdI3O2g= =01YT -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 31 13:38:08 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCd-0000d0-00 for ; Tue, 01 Jan 2002 01:54:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:51 +0100 (CET) Received: (qmail 15679 invoked by uid 0); 31 Dec 2001 22:04:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 31 Dec 2001 22:04:21 -0000 Received: by moria.seul.org (Postfix) id 82CEC1467EF; Mon, 31 Dec 2001 17:04:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63D261467F2; Mon, 31 Dec 2001 17:04:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a104.home.uni-hannover.de [130.75.232.104]) by moria.seul.org (Postfix) with ESMTP id 100981467EF for ; Mon, 31 Dec 2001 17:04:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00428; Mon, 31 Dec 2001 13:38:08 +0100 Message-ID: <20011231133808.38340@thrai.stud.uni-hannover.de> Date: Mon, 31 Dec 2001 13:38:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C2FEF27.8DF81818@f-cpu.org>; from Yann Guidon on Mon, Dec 31, 2001 at 05:52:55AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Dec 31, 2001 at 05:52:55AM +0100, Yann Guidon wrote: [...] > However i have still some difficulties > to work with Michael's files. I hope i'll find > the courage to read his files ;-) What's the problem? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jan 1 00:33:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LDCd-0000d0-01 for ; Tue, 01 Jan 2002 01:54:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 01:54:51 +0100 (CET) Received: (qmail 23465 invoked by uid 0); 31 Dec 2001 23:30:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 31 Dec 2001 23:30:24 -0000 Received: by moria.seul.org (Postfix) id 38D141467F0; Mon, 31 Dec 2001 18:30:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 20EF51467F3; Mon, 31 Dec 2001 18:30:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B76FD1467F0 for ; Mon, 31 Dec 2001 18:30:22 -0500 (EST) Received: from f-cpu.org (kdl16-8.n.club-internet.fr [213.44.18.8]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D0E7B168F for ; Tue, 1 Jan 2002 00:30:17 +0100 (CET) Message-ID: <3C30F5D5.A242E58B@f-cpu.org> Date: Tue, 01 Jan 2002 00:33:41 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Michael Riepe wrote: > On Mon, Dec 31, 2001 at 05:52:55AM +0100, Yann Guidon wrote: > [...] > > However i have still some difficulties > > to work with Michael's files. I hope i'll find > > the courage to read his files ;-) > What's the problem? the lack of courage ;-) however, with a bit of good sense, i have successfully run some of your testbenches. I have currently integrated your files (ASU, IMU and SHL) in my source tree. I was forced to modify your Makefiles a bit, since i have moved f-cpu_config.vhdl to ../configuration. I have also modified this file a bit : it seems that i have used a bad version of f-cpu_config.vhdl when doing the m4 transition, things are now currently ok. finally (?) i have moved misc.vhdl to ../common. Have a look at f-cpu.seul.org/new/stable*.tgz and tell me if it's ok. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jan 1 14:50:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LXdE-0000Fe-01 for ; Tue, 01 Jan 2002 23:43:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 23:43:40 +0100 (CET) Received: (qmail 14108 invoked by uid 0); 1 Jan 2002 13:47:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 1 Jan 2002 13:47:00 -0000 Received: by moria.seul.org (Postfix) id 509CC1467F3; Tue, 1 Jan 2002 08:46:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 376F91467F8; Tue, 1 Jan 2002 08:46:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id C32681467F3 for ; Tue, 1 Jan 2002 08:46:58 -0500 (EST) Received: from f-cpu.org (kdl11-65.n.club-internet.fr [213.44.9.65]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 6D06816B6 for ; Tue, 1 Jan 2002 14:46:56 +0100 (CET) Message-ID: <3C31BE9D.8FC2BBA8@f-cpu.org> Date: Tue, 01 Jan 2002 14:50:21 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] the hitorical f-cpu mailing list archive Content-Type: multipart/mixed; boundary="------------4E2EE303194332173B072F88" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------4E2EE303194332173B072F88 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello ! http://f-cpu.lphalt.com/ this is a repository of the old egroups/yahoogroups (now closed) mailing list. Carlos has put it online. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------4E2EE303194332173B072F88 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Base: "http://f-cpu.lphalt.com/" Content-Location: "http://f-cpu.lphalt.com/" Listing of / Powered by Roxen /

  Name     Size     Type     Last modified  
FCPU-yahoogroups.tar.gz   20.7 Mb   application/unix-tar   2002-01-01  
fcpu-yahoogroups.tar   66.2 Mb   application/unix-tar   2002-01-01  
historical     directory   2002-01-01  
old     directory   2002-01-01  
test     directory   2001-07-23  
--------------4E2EE303194332173B072F88-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 1 13:47:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LXdN-0000Fe-00 for ; Tue, 01 Jan 2002 23:43:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 01 Jan 2002 23:43:49 +0100 (CET) Received: (qmail 12897 invoked by uid 0); 1 Jan 2002 20:29:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 1 Jan 2002 20:29:01 -0000 Received: by moria.seul.org (Postfix) id C83571467FA; Tue, 1 Jan 2002 15:28:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA61C146801; Tue, 1 Jan 2002 15:28:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a247.home.uni-hannover.de [130.75.232.247]) by moria.seul.org (Postfix) with ESMTP id 4E5C51467FA for ; Tue, 1 Jan 2002 15:28:58 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00495; Tue, 1 Jan 2002 13:47:01 +0100 Message-ID: <20020101134701.35619@thrai.stud.uni-hannover.de> Date: Tue, 1 Jan 2002 13:47:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C30F5D5.A242E58B@f-cpu.org>; from Yann Guidon on Tue, Jan 01, 2002 at 12:33:41AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jan 01, 2002 at 12:33:41AM +0100, Yann Guidon wrote: [...] > however, with a bit of good sense, i have successfully run > some of your testbenches. I have currently integrated your > files (ASU, IMU and SHL) in my source tree. > I was forced to modify your Makefiles a bit, since > i have moved f-cpu_config.vhdl to ../configuration. That's what the Makefiles are for (and in particular, the variables named `confdir' and `CONF'). > I have also modified this file a bit : it seems that > i have used a bad version of f-cpu_config.vhdl when > doing the m4 transition, things are now currently ok. I've been using a manually edited version. > finally (?) i have moved misc.vhdl to ../common. I didn't do it yet because it's only used in the IMU. But I guess it's a good idea anyway. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 2 04:14:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUQ-0005mQ-01 for ; Thu, 03 Jan 2002 04:24:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:22 +0100 (CET) Received: (qmail 13995 invoked by uid 0); 2 Jan 2002 03:11:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 2 Jan 2002 03:11:12 -0000 Received: by moria.seul.org (Postfix) id 264D5146801; Tue, 1 Jan 2002 22:11:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 06740146805; Tue, 1 Jan 2002 22:11:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 86479146801 for ; Tue, 1 Jan 2002 22:11:10 -0500 (EST) Received: from f-cpu.org (kdl11-7.n.club-internet.fr [213.44.9.7]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 28DD316DB for ; Wed, 2 Jan 2002 04:11:08 +0100 (CET) Message-ID: <3C327B1A.CBFB998A@f-cpu.org> Date: Wed, 02 Jan 2002 04:14:34 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! and happy new year (again ?) everybody :-) Michael Riepe wrote: > On Tue, Jan 01, 2002 at 12:33:41AM +0100, Yann Guidon wrote: > [...] > > I was forced to modify your Makefiles a bit, since > > i have moved f-cpu_config.vhdl to ../configuration. > That's what the Makefiles are for (and in particular, the variables named > `confdir' and `CONF'). i changed 'confdir' iirc. verify in the archive... i think it's ok but nobody can be sure about me :-) > > I have also modified this file a bit : it seems that > > i have used a bad version of f-cpu_config.vhdl when > > doing the m4 transition, things are now currently ok. > I've been using a manually edited version. yes i saw, and it's ok, but can you test with the last generated one ? the diff should now be ok. > > finally (?) i have moved misc.vhdl to ../common. > I didn't do it yet because it's only used in the IMU. > But I guess it's a good idea anyway. and maybe it can be augmented, with new useful functions... can anybody have a look at "fanout_linear.vhdl" ? who can figure why it doesn't work with vanilla ? who can make a recursive version ? > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 2 08:04:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUT-0005mQ-00 for ; Thu, 03 Jan 2002 04:24:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:25 +0100 (CET) Received: (qmail 21687 invoked by uid 0); 2 Jan 2002 07:00:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 2 Jan 2002 07:00:37 -0000 Received: by moria.seul.org (Postfix) id 60A68146805; Wed, 2 Jan 2002 02:00:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D52B146807; Wed, 2 Jan 2002 02:00:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8FF7A146805 for ; Wed, 2 Jan 2002 02:00:36 -0500 (EST) Received: from f-cpu.org (kdl16-30.n.club-internet.fr [213.44.18.30]) by relay-3v.club-internet.fr (Postfix) with ESMTP id F33B416A9 for ; Wed, 2 Jan 2002 08:00:33 +0100 (CET) Message-ID: <3C32B0E0.2925548B@f-cpu.org> Date: Wed, 02 Jan 2002 08:04:00 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] yahoogroups archive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, tonight, after i woke up at 3AM, i decided to power my modem on and download the F-CPU archive >from Carlos' site at f-cpu.lphalt.com. This is a huge archive that almost spans the 3 years of this project's activity. I took a lot of time... probably 2 hours download. But this archive is realy worth it ! it contains posts, RFCs, miscellaneous source files, most early files, it's a real time-travelling machine ;-) Now that i have downloaded it, it will be included in the next F-CPU CDROMs. However the archive contains ALL Carlos' site files, including the compressed and uncompressed files. maybe he'll make a smaller version. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lphalt@gmx.de Wed Jan 2 09:20:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUe-0005mQ-00 for ; Thu, 03 Jan 2002 04:24:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:36 +0100 (CET) Received: (qmail 32572 invoked by uid 0); 2 Jan 2002 08:20:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 2 Jan 2002 08:20:11 -0000 Received: by moria.seul.org (Postfix) id 577D1146806; Wed, 2 Jan 2002 03:20:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4EF06146808; Wed, 2 Jan 2002 03:20:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by moria.seul.org (Postfix) with SMTP id 79102146806 for ; Wed, 2 Jan 2002 03:20:09 -0500 (EST) Received: (qmail 30710 invoked by uid 0); 2 Jan 2002 08:20:08 -0000 Date: Wed, 2 Jan 2002 09:20:08 +0100 (MET) From: Carlos De Urresti Hannoh To: f-cpu@seul.org MIME-Version: 1.0 References: <3C32B0E0.2925548B@f-cpu.org> Subject: Re: [f-cpu] yahoogroups archive X-Priority: 3 (Normal) X-Authenticated-Sender: #0006153040@gmx.net X-Authenticated-IP: [200.57.128.65] Message-ID: <20675.1009959608@www54.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hello, > > tonight, after i woke up at 3AM, i decided to > power my modem on and download the F-CPU archive > >from Carlos' site at f-cpu.lphalt.com. > This is a huge archive that almost spans the 3 years > of this project's activity. I took a lot of time... > probably 2 hours download. > But this archive is realy worth it ! it contains > posts, RFCs, miscellaneous source files, most > early files, it's a real time-travelling machine ;-) > > Now that i have downloaded it, it will be included > in the next F-CPU CDROMs. However the archive contains > ALL Carlos' site files, including the compressed and > uncompressed files. maybe he'll make a smaller version. new urls: http://f-cpu.lphalt.com/pub/FCPU_attachments-yahoogroups.tar.gz http://f-cpu.lphalt.com/pub/FCPU_plaintext-yahoogroups.tar.gz http://f-cpu.lphalt.com/pub/FCPU_full-yahhogroups.tar (both files and this is 17.6MB only). > > WHYGEE Orage > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 2 11:35:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUj-0005mQ-00 for ; Thu, 03 Jan 2002 04:24:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:41 +0100 (CET) Received: (qmail 15256 invoked by uid 0); 2 Jan 2002 11:15:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 2 Jan 2002 11:15:50 -0000 Received: by moria.seul.org (Postfix) id D218F146807; Wed, 2 Jan 2002 06:15:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B605F146809; Wed, 2 Jan 2002 06:15:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a048.home.uni-hannover.de [130.75.232.48]) by moria.seul.org (Postfix) with ESMTP id E1768146807 for ; Wed, 2 Jan 2002 06:15:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00463; Wed, 2 Jan 2002 11:35:27 +0100 Message-ID: <20020102113527.14485@thrai.stud.uni-hannover.de> Date: Wed, 2 Jan 2002 11:35:27 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C327B1A.CBFB998A@f-cpu.org>; from Yann Guidon on Wed, Jan 02, 2002 at 04:14:34AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: [...] > > > finally (?) i have moved misc.vhdl to ../common. > > I didn't do it yet because it's only used in the IMU. > > But I guess it's a good idea anyway. > and maybe it can be augmented, with new useful functions... Yep. > can anybody have a look at "fanout_linear.vhdl" ? > who can figure why it doesn't work with vanilla ? > who can make a recursive version ? I guess I can, if I find the time (gotta work again today). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bougardb@imec.be Wed Jan 2 14:34:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUk-0005mQ-01 for ; Thu, 03 Jan 2002 04:24:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:42 +0100 (CET) Received: (qmail 891 invoked by uid 0); 2 Jan 2002 13:31:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 2 Jan 2002 13:31:49 -0000 Received: by moria.seul.org (Postfix) id D4AD91467FC; Wed, 2 Jan 2002 08:31:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B63A014680A; Wed, 2 Jan 2002 08:31:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id D6D921467FC for ; Wed, 2 Jan 2002 08:31:46 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id OAA25568 for ; Wed, 2 Jan 2002 14:31:46 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 14:31:46 +0100 Message-ID: <3C330C79.B90C2409@imec.be> Date: Wed, 02 Jan 2002 14:34:49 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] System C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2002 13:31:46.0431 (UTC) FILETIME=[D319D0F0:01C19391] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I recently discover your project and I guess I can contribute a little bit to it. I am working in an interuniversitary microelectronics research center in belgium (imec) and we are active in different field including SoC design technologies. We are developping some EDA tools to support it, including a C++ class library that can be seen as 'the basis of System C'. This is exactly the same philosophy: It enable integrated HW/SW (co-)simulation with different refinement level (from data flow to RTL) and it can also be used to generate synthetizable vhdl or verilog code. The library is really stable (more than System C ;-) and has already been used internally for several high-ends designs (inclusing a cable-modem, a 802.11a-like (it was before the standard) baseband transceiver, ...). You can have more information on http://www.imec.be/desics/design_technology_top.html It can be used freely even it is not really under GPL. Regards and best wishes Bruno ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 2 20:14:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUs-0005mQ-00 for ; Thu, 03 Jan 2002 04:24:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:50 +0100 (CET) Received: (qmail 25205 invoked by uid 0); 2 Jan 2002 19:11:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 2 Jan 2002 19:11:35 -0000 Received: by moria.seul.org (Postfix) id 623C114680A; Wed, 2 Jan 2002 14:11:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 098D414680E; Wed, 2 Jan 2002 14:11:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 455B214680A for ; Wed, 2 Jan 2002 14:11:29 -0500 (EST) Received: from f-cpu.org (kdl21-8.n.club-internet.fr [213.44.96.8]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 21D3F18B3 for ; Wed, 2 Jan 2002 20:11:24 +0100 (CET) Message-ID: <3C335C28.A0FED9C2@f-cpu.org> Date: Wed, 02 Jan 2002 20:14:48 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] yahoogroups archive References: <3C32B0E0.2925548B@f-cpu.org> <20675.1009959608@www54.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Carlos De Urresti Hannoh wrote: > > Now that i have downloaded it, it will be included > > in the next F-CPU CDROMs. However the archive contains > > ALL Carlos' site files, including the compressed and > > uncompressed files. maybe he'll make a smaller version. > new urls: > http://f-cpu.lphalt.com/pub/FCPU_attachments-yahoogroups.tar.gz > http://f-cpu.lphalt.com/pub/FCPU_plaintext-yahoogroups.tar.gz > http://f-cpu.lphalt.com/pub/FCPU_full-yahhogroups.tar (both files and this > is 17.6MB only). Thank you !! > > WHYGEE > Orage WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 2 20:14:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyUs-0005mQ-01 for ; Thu, 03 Jan 2002 04:24:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:24:50 +0100 (CET) Received: (qmail 25879 invoked by uid 0); 2 Jan 2002 19:11:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 2 Jan 2002 19:11:45 -0000 Received: by moria.seul.org (Postfix) id 410D814680E; Wed, 2 Jan 2002 14:11:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E2764146813; Wed, 2 Jan 2002 14:11:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id B6DEE14680E for ; Wed, 2 Jan 2002 14:11:37 -0500 (EST) Received: from f-cpu.org (kdl21-8.n.club-internet.fr [213.44.96.8]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 8D36616C7 for ; Wed, 2 Jan 2002 20:11:32 +0100 (CET) Message-ID: <3C335C31.5F6C7393@f-cpu.org> Date: Wed, 02 Jan 2002 20:14:57 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020102113527.14485@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: > [...] > > > > finally (?) i have moved misc.vhdl to ../common. > > > I didn't do it yet because it's only used in the IMU. > > > But I guess it's a good idea anyway. > > and maybe it can be augmented, with new useful functions... > Yep. > > > can anybody have a look at "fanout_linear.vhdl" ? > > who can figure why it doesn't work with vanilla ? > > who can make a recursive version ? > I guess I can, if I find the time (gotta work again today). don't you have Christmas vacations ? :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 3 02:29:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16LyV5-0005mQ-01 for ; Thu, 03 Jan 2002 04:25:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 04:25:03 +0100 (CET) Received: (qmail 25173 invoked by uid 0); 3 Jan 2002 01:26:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 3 Jan 2002 01:26:04 -0000 Received: by moria.seul.org (Postfix) id 23A3E146818; Wed, 2 Jan 2002 20:26:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDC29146834; Wed, 2 Jan 2002 20:26:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 16972146818 for ; Wed, 2 Jan 2002 20:26:00 -0500 (EST) Received: from f-cpu.org (kdl1-31.n.club-internet.fr [213.44.0.31]) by relay-1v.club-internet.fr (Postfix) with ESMTP id F283216A5 for ; Thu, 3 Jan 2002 02:25:55 +0100 (CET) Message-ID: <3C33B3F1.25CB9195@f-cpu.org> Date: Thu, 03 Jan 2002 02:29:21 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] System C References: <3C330C79.B90C2409@imec.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Bruno Bougard wrote: > > Hello, > > I recently discover your project how ? :-) > and I guess I can contribute a little > bit to it. I am working in an interuniversitary microelectronics > research center in belgium (imec) and we are active in different field > including SoC design technologies. It is nice to see someone from IMEC again on the list ! I know this institute because i have seen the presentation booths during the DATA exhibitions and they are always interesting. And guess what ? I have a collector ! it's a IMEC mouse pad made from a recycled PCB :-) one or two years ago (?) i saw that someone from IMEC was subscribed but i don't remember any conversation with him. > We are developping some EDA tools to > support it, including a C++ class library that can be seen as 'the basis > of System C'. This is exactly the same philosophy: It enable integrated > HW/SW (co-)simulation with different refinement level (from data flow to > RTL) and it can also be used to generate synthetizable vhdl or verilog > code. The library is really stable (more than System C ;-) and has > already been used internally for several high-ends designs (inclusing a > cable-modem, a 802.11a-like (it was before the standard) baseband > transceiver, ...). You can have more information on > http://www.imec.be/desics/design_technology_top.html > It can be used freely even it is not really under GPL. We are already full-steam into VHDL coding. In fact the largest part of the work is dealing with low-level things. When i tried to make some C simulations, when i tried to analyse the scheduler, it appeared that C is not adapted to this task. Or maybe i wanted to write VHDL code in C. More generally, i do not believe that SystemC-like development is useful now because it's a low-level thing, mostly bit manipulations on a cycle by cycle basis on an already partitioned design. SystemC is mostly used for "SoC" where the designer must trade-off between HW and SW, but there is no SW needed here :-) It would be useful for a communication protocol analyser, for a MPEG/JPEG stream compressor/decompressor, for specific applications requiring some complex and heavy load where the HW optimisation must be balanced with the latency and costs. This is not the case with F-CPU. However it is certainly very interesting to learn from the newest design concepts and particularly from IMEC. Maybe F-CPU could find a place, not as a user but as component of new technologies ? Or at least there can be a way to cooperate on implementing a chip ... > Regards and best wishes thank you, happy new year and please post often, > Bruno WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 3 03:01:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MBvt-0000Fr-01 for ; Thu, 03 Jan 2002 18:45:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 03 Jan 2002 18:45:37 +0100 (CET) Received: (qmail 22374 invoked by uid 0); 3 Jan 2002 10:45:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 3 Jan 2002 10:45:01 -0000 Received: by moria.seul.org (Postfix) id 2D3371467ED; Thu, 3 Jan 2002 05:45:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 208F41467F1; Thu, 3 Jan 2002 05:45:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a103.home.uni-hannover.de [130.75.232.103]) by moria.seul.org (Postfix) with ESMTP id 53A6E1467ED for ; Thu, 3 Jan 2002 05:44:54 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA01886; Thu, 3 Jan 2002 03:01:01 +0100 Message-ID: <20020103030100.51944@thrai.stud.uni-hannover.de> Date: Thu, 3 Jan 2002 03:01:00 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" X-Mailer: Mutt 0.84e In-Reply-To: <3C327B1A.CBFB998A@f-cpu.org>; from Yann Guidon on Wed, Jan 02, 2002 at 04:14:34AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: [...] > can anybody have a look at "fanout_linear.vhdl" ? > who can figure why it doesn't work with vanilla ? It says: # -- Failure: t: signal has multiple drivers with no resolution function. This is not true, of course - but vanilla doesn't grok it. This happens when certain combinations of range attributes are used (in particular, 'high and 'low seem to cause problems). If you use explicit ranges, e.g. `WIDTH-1 downto 0', everything is fine again. I'll attach a fixed version that works for me. But the recursive version will have to wait (BTW: did you mean a recursive entity, or a recursive version of the binary_tree_index function?) CU, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fanout_linear.vhdl" -------------------------------------------------------------------------- -- f-cpu/vhdl/common/fanout_linear.vhdl - fanout tree (2**n) for the F-CPU -- Copyright (C) 2001 Yann GUIDON (whygee@f-cpu.org) -- -- created sam dec 1 00:39:05 GMT 2001 -- version jeu dec 6 16:28:31 GMT 2001 : stripped from fanout_tree.vhdl -- -- changed Thu Jan 3 02:49:09 CET 2002 (Michael Riepe): -- added workaround for broken 'low and 'high attributes in Vanilla VHDL -- --------------------------BEGIN-VHDL-LICENCE----------------------------- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ---------------------------END-VHDL-LICENCE------------------------------ -- -- This component implements a balanced fanout tree, for use when a signal -- must be sent to more than 2**n inputs, where n > 2. -- -- This version is a binary tree for synthesis. It tries to trick the -- "dumb" optimizers into thinking that the whole tree contains different -- signals and values, so that the nets won't be tied dumbly together -- (which would void the use of this component). Using inverters, -- which are somewhat faster than buffers that are probably not inferred, -- we can break the net into sub-levels. This means that one inverter -- level must be added if log2_width is odd. -- Depending on the software, this will be more or less efficient. Try each -- implementation to be sure. -- -- This code is not yet suitable for Vanilla VHDL and is taken apart. -- With Simili or other tools, compile this architecture AFTER work.fanout -- in order to replace the default "simple" architecture. -- -------------------------------------------------------------------------- -- some standard librairies LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.all; -- text i/o use IEEE.std_logic_textio.all; use std.textio.all; -- where the component interface is declared : use work.fanout; -- more sophisticated version : Architecture linear of fanout is constant verbose : natural := 0; constant WIDTH : natural := 2 ** log2_width; signal t : Std_ulogic_vector(WIDTH-1 downto 0); function binary_tree_index ( index : integer) return integer is variable i, j : integer; variable lout : line; begin -- binary_tree_index -- 1 ) count the number of LSB that are set to 1 -- (the loop could be avoided but requires a XOR which -- is not defined for integers :-( ) i := index; j := 4; while (i mod 2) = 1 loop i := i / 2; j := j * 2; end loop; -- 2) the incredible magic formula ! -- don't ask me where it comes, it was built from observation. i := (j - 1) / 2; if verbose > 0 then write(lout, string'(" * index : ")); write(lout, index); write(lout, string'(" * result : ")); write(lout, i); writeline(output,lout); end if; return ((index / j)*j) + i; end binary_tree_index; -- avoid the ugly `if ... generate / if not ... generate' function invert_if (A : in std_ulogic; F : boolean) return std_ulogic is variable Y : std_ulogic; begin if F then Y := not A; else Y := A; end if; return Y; end invert_if; begin assert (log2_width > 2) and (log2_width < 10) report "wrong size range for the binary tree" severity FAILURE; assert (leaf'low) = 0 report "array index should start with 0" severity FAILURE; -- compensation for the odd/even cases. t(WIDTH-1) <= invert_if(root, log2_width mod 2 = 0); -- build nodes saturate: for i in WIDTH-2 downto 0 generate t(i) <= not t(binary_tree_index(i)); -- map the binary tree to a linear vector. end generate saturate; -- add leaves i_loop: for i in leaf'range generate leaf(i) <= not t((i/2) *2); -- connect to the even numbered temporary nodes. end generate i_loop; end; --yrj/dFKFPuw6o+aM-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 4 02:06:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MK9y-0006EW-00 for ; Fri, 04 Jan 2002 03:32:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 04 Jan 2002 03:32:42 +0100 (CET) Received: (qmail 18256 invoked by uid 0); 4 Jan 2002 01:02:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 4 Jan 2002 01:02:47 -0000 Received: by moria.seul.org (Postfix) id BD15C146807; Thu, 3 Jan 2002 20:02:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8AB1914680E; Thu, 3 Jan 2002 20:02:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id BB36A146807 for ; Thu, 3 Jan 2002 20:02:44 -0500 (EST) Received: from f-cpu.org (kdl21-16.n.club-internet.fr [213.44.96.16]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 974EF16A7 for ; Fri, 4 Jan 2002 02:02:41 +0100 (CET) Message-ID: <3C350001.9940C5A7@f-cpu.org> Date: Fri, 04 Jan 2002 02:06:09 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Michael Riepe wrote: > On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: > [...] > > can anybody have a look at "fanout_linear.vhdl" ? > > who can figure why it doesn't work with vanilla ? > > It says: > # -- Failure: t: signal has multiple drivers with no resolution function. > This is not true, of course - but vanilla doesn't grok it. obviously ! but if the error message is inacurate, how could i find the error ? > This happens > when certain combinations of range attributes are used (in particular, > 'high and 'low seem to cause problems). If you use explicit ranges, > e.g. `WIDTH-1 downto 0', everything is fine again. This is surprising but this can explains a lot of things. How did you figure that ? > I'll attach a fixed version that works for me. But the recursive version > will have to wait (BTW: did you mean a recursive entity, or a recursive > version of the binary_tree_index function?) At least the linear version is a good start, but a "template" for recursive functions would be a good start. It's not a high priority, though. Thank you for your help ! I quickly looked at the new code and it seems to be ok. i'll have to update my "stable" tree and the HOWTO. Other tasks before i do a 0.1 version : - clear up ALL the licence issues. I met Mélanie Clément Fontaine today, who explained me a few things. - add the INC unit : I found an old "MR" version in the archive and now i have enough VHDL skills to understand it :-) - find a way to integrate the manual in the source tree. Any request/remark/idea/suggestion ?... > CU, > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bougardb@imec.be Fri Jan 4 09:06:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MdIi-0000G8-01 for ; Fri, 04 Jan 2002 23:59:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 04 Jan 2002 23:59:00 +0100 (CET) Received: (qmail 31286 invoked by uid 0); 4 Jan 2002 08:03:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 4 Jan 2002 08:03:27 -0000 Received: by moria.seul.org (Postfix) id DAB91146814; Fri, 4 Jan 2002 03:03:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C095F146816; Fri, 4 Jan 2002 03:03:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id 0F5EE146814 for ; Fri, 4 Jan 2002 03:03:25 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id JAA21925 for ; Fri, 4 Jan 2002 09:03:24 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Fri, 4 Jan 2002 09:03:23 +0100 Message-ID: <3C35628E.67921BA2@imec.be> Date: Fri, 04 Jan 2002 09:06:38 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] System C References: <3C330C79.B90C2409@imec.be> <3C33B3F1.25CB9195@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2002 08:03:24.0008 (UTC) FILETIME=[485E2680:01C194F6] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, > > We are developping some EDA tools to > > support it, including a C++ class library that can be seen as 'the basis > > of System C'. This is exactly the same philosophy: It enable integrated > > HW/SW (co-)simulation with different refinement level (from data flow to > > RTL) and it can also be used to generate synthetizable vhdl or verilog > > code. The library is really stable (more than System C ;-) and has > > already been used internally for several high-ends designs (inclusing a > > cable-modem, a 802.11a-like (it was before the standard) baseband > > transceiver, ...). You can have more information on > > http://www.imec.be/desics/design_technology_top.html > > It can be used freely even it is not really under GPL. > > We are already full-steam into VHDL coding. > In fact the largest part of the work is dealing with > low-level things. > When i tried to make some C simulations, when i tried > to analyse the scheduler, it appeared that C is not adapted > to this task. Or maybe i wanted to write VHDL code in C. > > More generally, i do not believe that SystemC-like development > is useful now because it's a low-level thing, mostly bit manipulations > on a cycle by cycle basis on an already partitioned design. > SystemC is mostly used for "SoC" where the designer must > trade-off between HW and SW, but there is no SW needed here :-) > It would be useful for a communication protocol analyser, > for a MPEG/JPEG stream compressor/decompressor, for specific > applications requiring some complex and heavy load where > the HW optimisation must be balanced with the latency and costs. That's true, and that's the kind of system I am used to cope with ... Anyway, System-C or SysC-like libraries can also make your life easier when you try to model and simulate a 'system' (it can be a CPU) which is not completely refined. The idea is to start the design by discribing a 'data flow' model (that sound DSP-like but it can be extented). The interest is that you can model a collection of concurrent processes (exactly like in vhdl) that are described in high level C. You don't need to be cycle-true at that level. Then, you refined your model process by process (fixed-point quantization, timed behavior ...) using the support of the library. The output is a FSMD model that can be automatically translated into vdhl or verilog for synthesis. At any time in the development, you can 'run' (simulate) the complete system, even if it is not completely refined. Now, this is 'our methodology', I don't say it is the best ... > This is not the case with F-CPU. I don't know it enough to judge fairly > However it is certainly very interesting to learn from the > newest design concepts and particularly from IMEC. Maybe F-CPU > could find a place, not as a user but as component of new > technologies ? Or at least there can be a way to cooperate > on implementing a chip ... Sure that I would like to have a look at your code. Do you have a cvs server ? Regards Bruno ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 4 10:27:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MdIk-0000G8-00 for ; Fri, 04 Jan 2002 23:59:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 04 Jan 2002 23:59:02 +0100 (CET) Received: (qmail 16352 invoked by uid 0); 4 Jan 2002 09:24:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 4 Jan 2002 09:24:27 -0000 Received: by moria.seul.org (Postfix) id 617A2146815; Fri, 4 Jan 2002 04:24:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38455146818; Fri, 4 Jan 2002 04:24:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id BB4F9146815 for ; Fri, 4 Jan 2002 04:24:24 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16MQdP-0003f4-00 for f-cpu@seul.org; Fri, 4 Jan 2002 10:27:31 +0100 Date: Fri, 4 Jan 2002 10:27:30 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] System C In-Reply-To: <3C35628E.67921BA2@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 4 Jan 2002, Bruno Bougard wrote: > > More generally, i do not believe that SystemC-like development > > is useful now because it's a low-level thing, mostly bit manipulations > > on a cycle by cycle basis on an already partitioned design. > > SystemC is mostly used for "SoC" where the designer must > > trade-off between HW and SW, but there is no SW needed here :-) > > It would be useful for a communication protocol analyser, > > for a MPEG/JPEG stream compressor/decompressor, for specific > > applications requiring some complex and heavy load where > > the HW optimisation must be balanced with the latency and costs. > > That's true, and that's the kind of system I am used to cope with ... Anyway, > System-C or SysC-like libraries can also make your life easier when you try > to model and simulate a 'system' (it can be a CPU) which is not completely > refined. The idea is to start the design by discribing a 'data flow' model > (that sound DSP-like but it can be extented). The interest is that you can > model a collection of concurrent processes (exactly like in vhdl) that are > described in high level C. You don't need to be cycle-true at that level. > Then, you refined your model process by process (fixed-point quantization, > timed behavior ...) using the support of the library. The output is a FSMD > model that can be automatically translated into vdhl or verilog for > synthesis. At any time in the development, you can 'run' (simulate) the > complete system, even if it is not completely refined. > > Now, this is 'our methodology', I don't say it is the best ... Hi, would the tool really help to decide during or after development where to draw the border between hardware and software? To my experience it's not this way because you have to program 'hardware style' to make it synthesizable. Also VHDL has that type of problem - not all constructs from the standard can be synthesized. It always depends on the synthesizer you use... Could you provide a link to download the tool for evaluation? Regards JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 4 02:37:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MdIn-0000G8-00 for ; Fri, 04 Jan 2002 23:59:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 04 Jan 2002 23:59:05 +0100 (CET) Received: (qmail 26129 invoked by uid 0); 4 Jan 2002 11:00:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Jan 2002 11:00:47 -0000 Received: by moria.seul.org (Postfix) id D55EF146815; Fri, 4 Jan 2002 06:00:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE15D146818; Fri, 4 Jan 2002 06:00:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a156.home.uni-hannover.de [130.75.232.156]) by moria.seul.org (Postfix) with ESMTP id 087D3146815 for ; Fri, 4 Jan 2002 06:00:42 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA04085; Fri, 4 Jan 2002 02:37:20 +0100 Message-ID: <20020104023720.45475@thrai.stud.uni-hannover.de> Date: Fri, 4 Jan 2002 02:37:20 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C350001.9940C5A7@f-cpu.org>; from Yann Guidon on Fri, Jan 04, 2002 at 02:06:09AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jan 04, 2002 at 02:06:09AM +0100, Yann Guidon wrote: > hello ! > > Michael Riepe wrote: > > On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: > > [...] > > > can anybody have a look at "fanout_linear.vhdl" ? > > > who can figure why it doesn't work with vanilla ? > > > > It says: > > # -- Failure: t: signal has multiple drivers with no resolution function. > > This is not true, of course - but vanilla doesn't grok it. > > obviously ! but if the error message is inacurate, how could i find the error ? That's the problem... you can't, normally. > > This happens > > when certain combinations of range attributes are used (in particular, > > 'high and 'low seem to cause problems). If you use explicit ranges, > > e.g. `WIDTH-1 downto 0', everything is fine again. > This is surprising but this can explains a lot of things. > How did you figure that ? I had the same problem months ago (fixed it by trial-and-error). > > I'll attach a fixed version that works for me. But the recursive version > > will have to wait (BTW: did you mean a recursive entity, or a recursive > > version of the binary_tree_index function?) > At least the linear version is a good start, but a "template" for > recursive functions would be a good start. It's not a high priority, though. -- BEWARE! UNTESTED CODE! function spread (A : in std_ulogic; log2_width : in natural) return std_ulogic_vector is constant L : natural := 2 ** log2_width; variably yy : std_ulogic_vector(L-1 downto 0); variable tt : std_ulogic; begin if log2_width >= 2 then -- L >= 2**2 = 4 tt := not A; yy(L-1 downto L/2) := spread(tt, log2_width - 1); yy(L/2-1 downto 0) := spread(tt, log2_width - 1); elsif log2_width = 1 then -- L = 2**1 = 2 yy := (others => not A); else -- L = 2**0 = 1 yy := (others => A); end if; return yy; end spread; Note: this needs an extra input inverter when log2_width is odd. And I don't know what synthesis tools will do with it; they'll probably optimize all the inverters away. Note #2: I should have made the `fanout factor' a function argument, or at least a modifiable constant, instead of just using `2' (I guess a 1:3 or 1:4 tree will be much better). With that modification, the function might be another candidate for inclusion in `package misc'. Provided that it works, of course. [...] > - add the INC unit : I found an old "MR" version in the archive and > now i have enough VHDL skills to understand it :-) Where did you find that (filename)? Must have been a pretty early version, I don't even remember that I wrote it. Welcome to the `f-cpu stone ages' ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 5 01:42:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCN-0003rb-01 for ; Sat, 05 Jan 2002 05:12:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:47 +0100 (CET) Received: (qmail 13333 invoked by uid 0); 5 Jan 2002 00:38:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 5 Jan 2002 00:38:59 -0000 Received: by moria.seul.org (Postfix) id 41A11146824; Fri, 4 Jan 2002 19:38:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E7A5146827; Fri, 4 Jan 2002 19:38:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B4CE6146824 for ; Fri, 4 Jan 2002 19:38:57 -0500 (EST) Received: from f-cpu.org (kdl16-33.n.club-internet.fr [213.44.18.33]) by relay-1v.club-internet.fr (Postfix) with ESMTP id DC6A11697 for ; Sat, 5 Jan 2002 01:38:53 +0100 (CET) Message-ID: <3C364BED.DBACF05@f-cpu.org> Date: Sat, 05 Jan 2002 01:42:21 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Fri, Jan 04, 2002 at 02:06:09AM +0100, Yann Guidon wrote: > > Michael Riepe wrote: > > > On Wed, Jan 02, 2002 at 04:14:34AM +0100, Yann Guidon wrote: > > > [...] > > > > can anybody have a look at "fanout_linear.vhdl" ? > > > > who can figure why it doesn't work with vanilla ? > > > It says: > > > # -- Failure: t: signal has multiple drivers with no resolution function. > > > This is not true, of course - but vanilla doesn't grok it. > > obviously ! but if the error message is inacurate, how could i find the error ? > That's the problem... you can't, normally. # WHAM ! # > > > This happens > > > when certain combinations of range attributes are used (in particular, > > > 'high and 'low seem to cause problems). If you use explicit ranges, > > > e.g. `WIDTH-1 downto 0', everything is fine again. > > This is surprising but this can explains a lot of things. > > How did you figure that ? > I had the same problem months ago (fixed it by trial-and-error). wow !... > > > I'll attach a fixed version that works for me. But the recursive version > > > will have to wait (BTW: did you mean a recursive entity, or a recursive > > > version of the binary_tree_index function?) > > At least the linear version is a good start, but a "template" for > > recursive functions would be a good start. It's not a high priority, though. > > -- BEWARE! UNTESTED CODE! thank you for the warnin : i have the tendency to trst whatever you do :-D > function spread (A : in std_ulogic; > log2_width : in natural) > return std_ulogic_vector is > constant L : natural := 2 ** log2_width; > variably yy : std_ulogic_vector(L-1 downto 0); > variable tt : std_ulogic; > begin > if log2_width >= 2 then > -- L >= 2**2 = 4 > tt := not A; > yy(L-1 downto L/2) := spread(tt, log2_width - 1); > yy(L/2-1 downto 0) := spread(tt, log2_width - 1); > elsif log2_width = 1 then > -- L = 2**1 = 2 > yy := (others => not A); > else > -- L = 2**0 = 1 > yy := (others => A); > end if; > return yy; > end spread; your use of a function is curious to me, i have the tendency to prefer generates. however i slowly start to understand why. > Note: this needs an extra input inverter when log2_width is odd. And I > don't know what synthesis tools will do with it; they'll probably optimize > all the inverters away. my idea is that if the synthesiser is smart enough to optimise the not, the it must be smart enough to infer the balanced tree again. Besides this assumption, the "behavioural" and default definition is pretty clear, it is possible to run the synthesiser with different options and keep the best ones, so we are not limited by bad tools and the good tools have some more choices. > Note #2: I should have made the `fanout factor' a function argument, > or at least a modifiable constant, instead of just using `2' (I guess > a 1:3 or 1:4 tree will be much better). With that modification, the > function might be another candidate for inclusion in `package misc'. > Provided that it works, of course. certainly. however 2 is a choice when the circuit is very wide because the wires are longer. a 4-tree would have more load per node and the setup time would be longer. > [...] > > - add the INC unit : I found an old "MR" version in the archive and > > now i have enough VHDL skills to understand it :-) > > Where did you find that (filename)? Must have been a pretty early > version, I don't even remember that I wrote it. Welcome to the > `f-cpu stone ages' ;) Welcome everybody :-) it's called "inc.vhdl" in the message #5926, the tag is $Id: inc.vhdl,v 1.2 2000/10/24 00:39:25 michael Exp $ the header is > Message-ID: <20001024145325.57558@t...> > Date: Tue, 24 Oct 2000 14:53:25 +0200 > To: f-cpu@egroups.com > Subject: Re: [f-cpu] (v) F-CPU configuration file > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 5 01:42:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCO-0003rb-00 for ; Sat, 05 Jan 2002 05:12:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:48 +0100 (CET) Received: (qmail 7911 invoked by uid 0); 5 Jan 2002 00:39:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 5 Jan 2002 00:39:02 -0000 Received: by moria.seul.org (Postfix) id C4E88146828; Fri, 4 Jan 2002 19:39:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A015B14682A; Fri, 4 Jan 2002 19:39:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5F8BB146827 for ; Fri, 4 Jan 2002 19:39:00 -0500 (EST) Received: from f-cpu.org (kdl16-33.n.club-internet.fr [213.44.18.33]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 01F7216D7 for ; Sat, 5 Jan 2002 01:38:56 +0100 (CET) Message-ID: <3C364BEF.444B55DF@f-cpu.org> Date: Sat, 05 Jan 2002 01:42:23 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] ADD/SUB unit, v2 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, while reading through the ASU code, i read that there is no "time" for a 1-bit most-shift (which would be useful for fractional operations). I thought about the following solution : 1) duplicate the unit 2) drop the input xors and propagate the change in the rest of one of the unit. We thus get one sub and one add operation 3) add the post-shift Since there is a provision for a simultaneous add/sub instruction, this is fine :-) The new form of ASU (optional) would have the same 2 write ports and the simultaneous add/sub will disallow carry/borrow. I am thinking about this because i'm currently working on a 8-bin DCT and most adds are paired with subsractions. Since i use a derivative of the Winogrgad version, this is not completely true but the first stages start like a normal butterfly FFT. The rest is a matter of scheduling and register allocation... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 5 01:42:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCP-0003rb-00 for ; Sat, 05 Jan 2002 05:12:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:49 +0100 (CET) Received: (qmail 24287 invoked by uid 0); 5 Jan 2002 00:39:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 5 Jan 2002 00:39:04 -0000 Received: by moria.seul.org (Postfix) id 2A208146827; Fri, 4 Jan 2002 19:39:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E3C5D14682B; Fri, 4 Jan 2002 19:39:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 78265146829 for ; Fri, 4 Jan 2002 19:39:00 -0500 (EST) Received: from f-cpu.org (kdl16-33.n.club-internet.fr [213.44.18.33]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 0DBCB16BD for ; Sat, 5 Jan 2002 01:38:57 +0100 (CET) Message-ID: <3C364BF0.A3060BA2@f-cpu.org> Date: Sat, 05 Jan 2002 01:42:24 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] System C References: <3C330C79.B90C2409@imec.be> <3C33B3F1.25CB9195@f-cpu.org> <3C35628E.67921BA2@imec.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Bruno Bougard wrote: > Hello, > > More generally, i do not believe that SystemC-like development > > is useful now because it's a low-level thing, mostly bit manipulations > > on a cycle by cycle basis on an already partitioned design. > > SystemC is mostly used for "SoC" where the designer must > > trade-off between HW and SW, but there is no SW needed here :-) > > It would be useful for a communication protocol analyser, > > for a MPEG/JPEG stream compressor/decompressor, for specific > > applications requiring some complex and heavy load where > > the HW optimisation must be balanced with the latency and costs. > > That's true, and that's the kind of system I am used to cope with ... Anyway, > System-C or SysC-like libraries can also make your life easier when you try > to model and simulate a 'system' (it can be a CPU) which is not completely > refined. The idea is to start the design by discribing a 'data flow' model > (that sound DSP-like but it can be extented). The interest is that you can > model a collection of concurrent processes (exactly like in vhdl) that are > described in high level C. You don't need to be cycle-true at that level. This is one of the main problem. Though i use constrained DFG for programming, a superpipelined CPU has more to do with queuing networks or something like that. Furthermore, in FC0, the OOOC pipeline has different latencies, depending on the operation, which makes the DFG a bit more complex... > Then, you refined your model process by process (fixed-point quantization, > timed behavior ...) This has more to do with data characterization and algorithm range exploration (or something like that, i don't know the exact words). Of course this is very very useful when you have a specific application in mind and you want to map it to a FPGA/ASIC and you have to determine the algorithm's behaviour, stability and the bus width. The design of a general purpose CPU has other constraints, i think. > using the support of the library. The output is a FSMD > model that can be automatically translated into vdhl or verilog for > synthesis. At any time in the development, you can 'run' (simulate) the > complete system, even if it is not completely refined. > > Now, this is 'our methodology', I don't say it is the best ... It is very good for the examples IMEC demonstrated, anyway. > > This is not the case with F-CPU. > I don't know it enough to judge fairly don't worry, it's difficult to learn everything within a day... however Carlos has recently made available the mail archive that he extracted from Yahoogroups before we abandonned it. There are almost 3 years of intense discussions and a lot of attachements that, when sorted by date, show how the project evolved. There is also a "F-CPU manual" but it lags by at least a year. > > However it is certainly very interesting to learn from the > > newest design concepts and particularly from IMEC. Maybe F-CPU > > could find a place, not as a user but as component of new > > technologies ? Or at least there can be a way to cooperate > > on implementing a chip ... > Sure that I would like to have a look at your code. Do you have > a cvs server ? there is one at gaos.org but it's not much used. You can find the manual there. There's also a weekly generated tarball of the CVS tree at f-cpu.gaos.org IIRC. look at http://www.f-cpu.org for more URLs. however the latest source tree was the "stable" released a few days ago. it is available from http://f-cpu.seul.org/new and it's a 300KB tgz named "table_yg"something. Please forgive my naughty hacks and the bad style :-) > Regards read you soon, > Bruno WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 5 01:42:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCQ-0003rb-00 for ; Sat, 05 Jan 2002 05:12:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:50 +0100 (CET) Received: (qmail 20006 invoked by uid 0); 5 Jan 2002 00:39:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 5 Jan 2002 00:39:07 -0000 Received: by moria.seul.org (Postfix) id B48F014682C; Fri, 4 Jan 2002 19:39:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B11E714682B; Fri, 4 Jan 2002 19:39:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4BC9D146829 for ; Fri, 4 Jan 2002 19:39:03 -0500 (EST) Received: from f-cpu.org (kdl16-33.n.club-internet.fr [213.44.18.33]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 0A8EE16BD for ; Sat, 5 Jan 2002 01:39:01 +0100 (CET) Message-ID: <3C364BF2.B7E04DDC@f-cpu.org> Date: Sat, 05 Jan 2002 01:42:26 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] System C References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Juergen Goeritz wrote: > On Fri, 4 Jan 2002, Bruno Bougard wrote: > > Now, this is 'our methodology', I don't say it is the best ... > > Hi, > > would the tool really help to decide during or after development > where to draw the border between hardware and software? that's what it is meant to achieve :-) and i have seen some working examples from IMEC and others. By the way i will do my best to attend the DATE2002 exhibition. My university lab will present his work, Mentor Graphics will be there too (so i'll meet Meta Systems employees and past colleagues :-)) and IMEC is usually present. > To my experience it's not this way because you have to program > 'hardware style' to make it synthesizable. Also VHDL has that > type of problem - not all constructs from the standard can be > synthesized. It always depends on the synthesizer you use... by the way, i have been surprised by the ability of some "expensive" VHDL synthesisers to "grok" apparently unsynthesisable things. OTOH we can't rely on it : GPL'd tools don't have all this intelligence. I try to write in RTL style but Micheal now uses more advanced constructs, for example in the multiplier or the shifter. At least that works in simulation and some synthesis runs have succeeded. And it usually takes one year before i start to use Michael's techniques ;-) > Could you provide a link to download the tool for evaluation? the past mail indicated : http://www.imec.be/desics/design_technology_top.html i have not looked yet, though. > Regards > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 5 01:50:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCQ-0003rb-01 for ; Sat, 05 Jan 2002 05:12:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:50 +0100 (CET) Received: (qmail 22237 invoked by uid 0); 5 Jan 2002 00:50:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 5 Jan 2002 00:50:59 -0000 Received: by moria.seul.org (Postfix) id 8FE18146820; Fri, 4 Jan 2002 19:50:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88D5A146829; Fri, 4 Jan 2002 19:50:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a117.home.uni-hannover.de [130.75.232.117]) by moria.seul.org (Postfix) with ESMTP id 29583146820 for ; Fri, 4 Jan 2002 19:50:57 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01778; Sat, 5 Jan 2002 01:50:55 +0100 Message-ID: <20020105015055.03027@thrai.stud.uni-hannover.de> Date: Sat, 5 Jan 2002 01:50:55 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C364BED.DBACF05@f-cpu.org>; from Yann Guidon on Sat, Jan 05, 2002 at 01:42:21AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jan 05, 2002 at 01:42:21AM +0100, Yann Guidon wrote: [...] > > Where did you find that (filename)? Must have been a pretty early > > version, I don't even remember that I wrote it. Welcome to the > > `f-cpu stone ages' ;) > Welcome everybody :-) > > it's called "inc.vhdl" in the message #5926, the tag is > $Id: inc.vhdl,v 1.2 2000/10/24 00:39:25 michael Exp $ Whee, that's old. *blowing-the-dust-off* But it's not a complete INC EU, just a 64-bit incrementer. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 5 02:09:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCR-0003rb-00 for ; Sat, 05 Jan 2002 05:12:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:51 +0100 (CET) Received: (qmail 27683 invoked by uid 0); 5 Jan 2002 01:09:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 5 Jan 2002 01:09:05 -0000 Received: by moria.seul.org (Postfix) id 105FE146825; Fri, 4 Jan 2002 20:09:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A14014682A; Fri, 4 Jan 2002 20:09:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a117.home.uni-hannover.de [130.75.232.117]) by moria.seul.org (Postfix) with ESMTP id 93AB8146825 for ; Fri, 4 Jan 2002 20:09:02 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01827; Sat, 5 Jan 2002 02:09:01 +0100 Message-ID: <20020105020901.36832@thrai.stud.uni-hannover.de> Date: Sat, 5 Jan 2002 02:09:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] ADD/SUB unit, v2 ? References: <3C364BEF.444B55DF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C364BEF.444B55DF@f-cpu.org>; from Yann Guidon on Sat, Jan 05, 2002 at 01:42:23AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jan 05, 2002 at 01:42:23AM +0100, Yann Guidon wrote: > while reading through the ASU code, i read that > there is no "time" for a 1-bit most-shift > (which would be useful for fractional operations). Since fractional operands are in sign-magnitude (rather than 2's complement) form, we'll need more pre- and postprocessing than a single shift. > I thought about the following solution : > 1) duplicate the unit > 2) drop the input xors and propagate the change in the > rest of one of the unit. We thus get one sub and one > add operation > 3) add the post-shift > > Since there is a provision for a simultaneous add/sub > instruction, this is fine :-) The new form of ASU > (optional) would have the same 2 write ports > and the simultaneous add/sub will disallow carry/borrow. If addsub is required to perform both operations simultaneously, we'll need to duplicate the unit anyway. On the other hand, there probably are many programs that perform lots of ADD operations but no SUB (address calculations, for example). Therefore, I'd rather keep the ASU as-is and add an ADD-only unit. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 5 03:54:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16MiCR-0003rb-01 for ; Sat, 05 Jan 2002 05:12:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 05:12:51 +0100 (CET) Received: (qmail 30151 invoked by uid 0); 5 Jan 2002 02:50:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Jan 2002 02:50:49 -0000 Received: by moria.seul.org (Postfix) id 344C0146834; Fri, 4 Jan 2002 21:50:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 315BE146830; Fri, 4 Jan 2002 21:50:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id DD95A14682E for ; Fri, 4 Jan 2002 21:50:46 -0500 (EST) Received: from f-cpu.org (kdl11-14.n.club-internet.fr [213.44.9.14]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D6D6A16B8 for ; Sat, 5 Jan 2002 03:50:43 +0100 (CET) Message-ID: <3C366AD2.35DAAAA5@f-cpu.org> Date: Sat, 05 Jan 2002 03:54:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Error with the fractional flag References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sat, Jan 05, 2002 at 01:42:21AM +0100, Yann Guidon wrote: > [...] > > > Where did you find that (filename)? Must have been a pretty early > > > version, I don't even remember that I wrote it. Welcome to the > > > `f-cpu stone ages' ;) > > Welcome everybody :-) > > > > it's called "inc.vhdl" in the message #5926, the tag is > > $Id: inc.vhdl,v 1.2 2000/10/24 00:39:25 michael Exp $ > Whee, that's old. > *blowing-the-dust-off* come on :-) at that time, it was sophisticated ... > But it's not a complete INC EU, just a 64-bit incrementer. that's the heart of the unit so it's good. I think i'm going to update it a bit and include it in a "EU wrapper" with more stuff. In another mail, > On Sat, Jan 05, 2002 at 01:42:23AM +0100, Yann Guidon wrote: > > while reading through the ASU code, i read that > > there is no "time" for a 1-bit most-shift > > (which would be useful for fractional operations). > Since fractional operands are in sign-magnitude (rather than 2's > complement) form, we'll need more pre- and postprocessing than a single > shift. the definition i have is not sign-magnitude... what, then ? .... My Analog Devices DSP manual says : "Q16 is a special case of fractional number where all the bits lie to the left of the radix point." OOOPS ! I understand where i was mistaken... it says : "In addition and substraction, both operands must be in the same format (signed or unsigned, radix point in the same location) and the result format is the same as the input format. Additions and substrations are performed the same way whether the inputs are signed or unsigned". I think i have mistaken with the multiply where 1Q15 * 1Q15 makes 2Q30, so we have to shift the duplicate sign bit out. This means that only the IDU and IMU have a fractional mode bit in the instruction ... All my excuses ... there is no modification required in the ASU for supporting fractional mode. So we can drop the fractional flag. sorry. > > I thought about the following solution : > > 1) duplicate the unit > > 2) drop the input xors and propagate the change in the > > rest of one of the unit. We thus get one sub and one > > add operation > > 3) add the post-shift > > > > Since there is a provision for a simultaneous add/sub > > instruction, this is fine :-) The new form of ASU > > (optional) would have the same 2 write ports > > and the simultaneous add/sub will disallow carry/borrow. > > If addsub is required to perform both operations simultaneously, we'll > need to duplicate the unit anyway. On the other hand, there probably > are many programs that perform lots of ADD operations but no SUB > (address calculations, for example). Therefore, I'd rather keep the > ASU as-is and add an ADD-only unit. This is not consistent with the fact that no operation triggers 2 adds per cycle... And the ASU is pipelined. however i would still like an ASU with the duplicated (mirored) units, one being specialized for add and the other for sub. It leaves some headroom in the timing and is DSP-friendly :-) I'll soon release a little "programming course" which shows how i optimised an already optimised DCT. It's not yet finished, i have to make a testbench to verify that i have made no error. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Jan 5 11:35:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Moqg-0002b5-00 for ; Sat, 05 Jan 2002 12:18:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 12:18:50 +0100 (CET) Received: (qmail 24852 invoked by uid 0); 5 Jan 2002 10:41:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 5 Jan 2002 10:41:48 -0000 Received: by moria.seul.org (Postfix) id 5071114682F; Sat, 5 Jan 2002 05:41:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E6C5E146835; Sat, 5 Jan 2002 05:41:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0F1DD14682F for ; Sat, 5 Jan 2002 05:41:47 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16MoAf-0000sI-00 for f-cpu@seul.org; Sat, 5 Jan 2002 11:35:25 +0100 Date: Sat, 5 Jan 2002 11:35:25 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] System C In-Reply-To: <3C364BF2.B7E04DDC@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 5 Jan 2002, Yann Guidon wrote: > > would the tool really help to decide during or after development > > where to draw the border between hardware and software? > > that's what it is meant to achieve :-) and i have seen some > working examples from IMEC and others. Really! :-) > By the way i will do my best to attend the DATE2002 exhibition. > My university lab will present his work, Mentor Graphics > will be there too (so i'll meet Meta Systems employees and > past colleagues :-)) and IMEC is usually present. :-) > > Could you provide a link to download the tool for evaluation? > the past mail indicated : > http://www.imec.be/desics/design_technology_top.html > i have not looked yet, though. I didn't find a download section. Just papers. But I didn't spend much time to search this site either. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 5 04:27:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Mq9T-0003ow-01 for ; Sat, 05 Jan 2002 13:42:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 05 Jan 2002 13:42:19 +0100 (CET) Received: (qmail 22021 invoked by uid 0); 5 Jan 2002 11:39:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Jan 2002 11:39:17 -0000 Received: by moria.seul.org (Postfix) id 1BD4B146830; Sat, 5 Jan 2002 06:39:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CB6DF146838; Sat, 5 Jan 2002 06:39:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a250.home.uni-hannover.de [130.75.232.250]) by moria.seul.org (Postfix) with ESMTP id 9EB89146830 for ; Sat, 5 Jan 2002 06:39:13 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA02419; Sat, 5 Jan 2002 04:27:58 +0100 Message-ID: <20020105042757.35029@thrai.stud.uni-hannover.de> Date: Sat, 5 Jan 2002 04:27:57 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Error with the fractional flag References: <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> <3C366AD2.35DAAAA5@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C366AD2.35DAAAA5@f-cpu.org>; from Yann Guidon on Sat, Jan 05, 2002 at 03:54:10AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jan 05, 2002 at 03:54:10AM +0100, Yann Guidon wrote: [...] > > > while reading through the ASU code, i read that > > > there is no "time" for a 1-bit most-shift > > > (which would be useful for fractional operations). > > Since fractional operands are in sign-magnitude (rather than 2's > > complement) form, we'll need more pre- and postprocessing than a single > > shift. > the definition i have is not sign-magnitude... > what, then ? I referred to Reto Zimmermann's definition, where it is (Lecture notes on Computer Arithmetic: Principles, Architectures, and VLSI Design; page 19). More precisely, the number represented is x = (-1)^S * 2^(E-bias) with S being the most significant ("sign") bit and E being the rest of the chunk (bias depends on chunk size). If you multiply two of these, you get x1 * x2 = (-1)^S1 * 2^(E1-bias) * (-1)^S2 * 2^(E2-bias) = (-1)^S1 * (-1)^S2 * 2^(E1+E2-2*bias) = (-1)^(S1 xor S2) * 2^((E1+E2-bias)-bias) The components of the result, S = S1 xor S2 E = E1 + E2 - bias can't be calculated with a single ASU operation, no matter how you tune it :( > .... > > My Analog Devices DSP manual says : > "Q16 is a special case of fractional number where all the bits lie to the > left of the radix point." > > > OOOPS ! I understand where i was mistaken... > > it says : "In addition and substraction, both operands must be in the same > format (signed or unsigned, radix point in the same location) and the result > format is the same as the input format. Additions and substrations are > performed the same way whether the inputs are signed or unsigned". > > I think i have mistaken with the multiply where 1Q15 * 1Q15 makes 2Q30, > so we have to shift the duplicate sign bit out. This means that only the > IDU and IMU have a fractional mode bit in the instruction ... > > All my excuses ... there is no modification required in the ASU for > supporting fractional mode. So we can drop the fractional flag. sorry. Applying the IMU/IDU to LNS numbers doesn't make much sense anyway. What's that supposed to do, mathematically? For exponentiation, you need one LNS and one conventional (integer or fractional) operand. > > > I thought about the following solution : > > > 1) duplicate the unit > > > 2) drop the input xors and propagate the change in the > > > rest of one of the unit. We thus get one sub and one > > > add operation > > > 3) add the post-shift > > > > > > Since there is a provision for a simultaneous add/sub > > > instruction, this is fine :-) The new form of ASU > > > (optional) would have the same 2 write ports > > > and the simultaneous add/sub will disallow carry/borrow. > > > > If addsub is required to perform both operations simultaneously, we'll > > need to duplicate the unit anyway. On the other hand, there probably > > are many programs that perform lots of ADD operations but no SUB > > (address calculations, for example). Therefore, I'd rather keep the > > ASU as-is and add an ADD-only unit. > This is not consistent with the fact that no operation triggers > 2 adds per cycle... And the ASU is pipelined. In FC0, yes :) > however i would still like an ASU with the duplicated > (mirored) units, one being specialized for add and the other > for sub. It leaves some headroom in the timing and is DSP-friendly :-) And it's future-proof :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Jan 6 05:56:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16N7Z6-0007LJ-00 for ; Sun, 06 Jan 2002 08:17:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 06 Jan 2002 08:17:56 +0100 (CET) Received: (qmail 20232 invoked by uid 0); 5 Jan 2002 22:53:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 5 Jan 2002 22:53:52 -0000 Received: by moria.seul.org (Postfix) id 6352114683B; Sat, 5 Jan 2002 17:53:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57B2114683D; Sat, 5 Jan 2002 17:53:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 0C8C814683B for ; Sat, 5 Jan 2002 17:53:52 -0500 (EST) Received: from ifrance.com (vlt6-204.n.club-internet.fr [194.158.109.204]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BF44016B3 for ; Sat, 5 Jan 2002 23:53:49 +0100 (CET) Message-ID: <3C37D8E4.3C8089FA@ifrance.com> Date: Sat, 05 Jan 2002 23:56:04 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release, autoconf ? References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N So i understood that Whygee will make a good distribution. I know he try to use m4 tools. But what about using automake/autoconf ? It's very powerfull and much more "standard". nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jan 6 18:45:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16NHoN-0006m6-00 for ; Sun, 06 Jan 2002 19:14:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 06 Jan 2002 19:14:23 +0100 (CET) Received: (qmail 28386 invoked by uid 0); 6 Jan 2002 17:42:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 6 Jan 2002 17:42:20 -0000 Received: by moria.seul.org (Postfix) id C4108146850; Sun, 6 Jan 2002 12:42:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 986A5146852; Sun, 6 Jan 2002 12:42:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 05371146850 for ; Sun, 6 Jan 2002 12:42:15 -0500 (EST) Received: from f-cpu.org (kdl2-175.n.club-internet.fr [213.44.1.175]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BB511175B for ; Sun, 6 Jan 2002 18:42:11 +0100 (CET) Message-ID: <3C388D47.9C0FA05B@f-cpu.org> Date: Sun, 06 Jan 2002 18:45:43 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Error with the fractional flag References: <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> <3C366AD2.35DAAAA5@f-cpu.org> <20020105042757.35029@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Sat, Jan 05, 2002 at 03:54:10AM +0100, Yann Guidon wrote: > [...] > > > > while reading through the ASU code, i read that > > > > there is no "time" for a 1-bit most-shift > > > > (which would be useful for fractional operations). > > > Since fractional operands are in sign-magnitude (rather than 2's > > > complement) form, we'll need more pre- and postprocessing than a single > > > shift. > > the definition i have is not sign-magnitude... > > what, then ? > > I referred to Reto Zimmermann's definition, where it is (Lecture notes on > Computer Arithmetic: Principles, Architectures, and VLSI Design; page 19). > More precisely, the number represented is > > x = (-1)^S * 2^(E-bias) > > with S being the most significant ("sign") bit and E being the rest of > the chunk (bias depends on chunk size). If you multiply two of these, > you get > > x1 * x2 > = (-1)^S1 * 2^(E1-bias) * (-1)^S2 * 2^(E2-bias) > = (-1)^S1 * (-1)^S2 * 2^(E1+E2-2*bias) > = (-1)^(S1 xor S2) * 2^((E1+E2-bias)-bias) > > The components of the result, > > S = S1 xor S2 > E = E1 + E2 - bias > > can't be calculated with a single ASU operation, no matter how you > tune it :( The advantage of ADi's definition is that there is no such problem. the multiply's result is simply shifted left. > > .... > > > > My Analog Devices DSP manual says : > > "Q16 is a special case of fractional number where all the bits lie to the > > left of the radix point." > > > > > > OOOPS ! I understand where i was mistaken... > > > > it says : "In addition and substraction, both operands must be in the same > > format (signed or unsigned, radix point in the same location) and the result > > format is the same as the input format. Additions and substrations are > > performed the same way whether the inputs are signed or unsigned". > > > > I think i have mistaken with the multiply where 1Q15 * 1Q15 makes 2Q30, > > so we have to shift the duplicate sign bit out. This means that only the > > IDU and IMU have a fractional mode bit in the instruction ... > > > > All my excuses ... there is no modification required in the ASU for > > supporting fractional mode. So we can drop the fractional flag. sorry. > > Applying the IMU/IDU to LNS numbers doesn't make much sense anyway. > What's that supposed to do, mathematically? For exponentiation, you > need one LNS and one conventional (integer or fractional) operand. i don't remember and i have to search the archives, but multiply and divide has a meaning in LNS world. However, dues to some EU program's idiosynchrasies, the people who made the 32-bit LNS unit will refuse to open-source it, so i don't think they'll GPL it. However it could be possible to rewrite it from scratch, with the help from their papers (i have the full description of the LNS +/- unit) but i guess they could have some patents pending. That's the problem with so-called state-funded research : (in France, EU and even US) they give money to universities to do the tough work and it is then monopolized by a company. I currently leave the LNS side apart but i don't want to abandon it. We might need the extra bits later, or find a good LNS solution. > > > If addsub is required to perform both operations simultaneously, we'll > > > need to duplicate the unit anyway. On the other hand, there probably > > > are many programs that perform lots of ADD operations but no SUB > > > (address calculations, for example). Therefore, I'd rather keep the > > > ASU as-is and add an ADD-only unit. > > This is not consistent with the fact that no operation triggers > > 2 adds per cycle... And the ASU is pipelined. > In FC0, yes :) what do you mean ? > > however i would still like an ASU with the duplicated > > (mirored) units, one being specialized for add and the other > > for sub. It leaves some headroom in the timing and is DSP-friendly :-) > And it's future-proof :) if i had to implement a dual-issue FC0 it would have dual LSU, dual ASU and dual ROP2 (at least). There would be 1 IMU and 1 IDU but the first mentioned units are often critical. From my experience with MMX, a single SHL can lead to problems, too. OTOH it is probably easier to duplicate the FC0 core ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jan 6 18:45:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16NHoR-0006m6-00 for ; Sun, 06 Jan 2002 19:14:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 06 Jan 2002 19:14:27 +0100 (CET) Received: (qmail 1970 invoked by uid 0); 6 Jan 2002 17:42:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 6 Jan 2002 17:42:25 -0000 Received: by moria.seul.org (Postfix) id 6B74B146852; Sun, 6 Jan 2002 12:42:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DDE2E146854; Sun, 6 Jan 2002 12:42:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 72EE9146852 for ; Sun, 6 Jan 2002 12:42:20 -0500 (EST) Received: from f-cpu.org (kdl2-175.n.club-internet.fr [213.44.1.175]) by relay-1v.club-internet.fr (Postfix) with ESMTP id AD2381743 for ; Sun, 6 Jan 2002 18:42:14 +0100 (CET) Message-ID: <3C388D49.CE06806E@f-cpu.org> Date: Sun, 06 Jan 2002 18:45:45 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] System C References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Juergen Goeritz wrote: > On Sat, 5 Jan 2002, Yann Guidon wrote: > > > would the tool really help to decide during or after development > > > where to draw the border between hardware and software? > > that's what it is meant to achieve :-) and i have seen some > > working examples from IMEC and others. > Really! :-) I don't know if this one uses SystemC but i received the brochure for DATE2002 and they will demonstrate a wireless-LAN basestation (and certainly other stuffs). This year is going to be even more interesting than past exhibitions because we will see the result of the past year's efforts. > > By the way i will do my best to attend the DATE2002 exhibition. > > My university lab will present his work, Mentor Graphics > > will be there too (so i'll meet Meta Systems employees and > > past colleagues :-)) and IMEC is usually present. > :-) it's certainly a place where F-CPU enthusiasts are going to be happy. > > > Could you provide a link to download the tool for evaluation? > > the past mail indicated : > > http://www.imec.be/desics/design_technology_top.html > > i have not looked yet, though. > I didn't find a download section. Just papers. But I > didn't spend much time to search this site either. i didn't even click :-P > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jan 6 18:45:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16NHoT-0006m6-00 for ; Sun, 06 Jan 2002 19:14:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 06 Jan 2002 19:14:29 +0100 (CET) Received: (qmail 12555 invoked by uid 0); 6 Jan 2002 17:42:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 6 Jan 2002 17:42:28 -0000 Received: by moria.seul.org (Postfix) id 2F206146854; Sun, 6 Jan 2002 12:42:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1DC9146857; Sun, 6 Jan 2002 12:42:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 98512146854 for ; Sun, 6 Jan 2002 12:42:23 -0500 (EST) Received: from f-cpu.org (kdl2-175.n.club-internet.fr [213.44.1.175]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E810F17C2 for ; Sun, 6 Jan 2002 18:42:19 +0100 (CET) Message-ID: <3C388D4D.8F7826FA@f-cpu.org> Date: Sun, 06 Jan 2002 18:45:49 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] about the ongoing work for the "stable" release, autoconf ? References: <3C2FEF27.8DF81818@f-cpu.org> <20011231133808.38340@thrai.stud.uni-hannover.de> <3C30F5D5.A242E58B@f-cpu.org> <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> <3C37D8E4.3C8089FA@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! it's good to see nicO writing again on the list, i wondered if you were still in Berlin :-) nicO wrote: > So i understood that Whygee will make a good distribution. or more precisely : a package that should be rather ok and not too dirty. Until now, Michael and me have "published" our files but this time i wanted to make sure someone else could use it. My further developments will be based on this package, i hope that others will be able to work on it. > I know he try to use m4 tools. But what about using automake/autoconf ? > It's very powerfull and much more "standard". IIRC autoconf uses m4. We use it lile a "super cpp". OTOH i can't know every tool. m4 is enough currently, we don't use a lot of its possibilities and it fits our needs : there is no need for something else that is even more complex, more powerful and that we would have to learnt. Maintainability is easier when a reduced number of simple tools is used, right ? :-) Finally, this is not the "usual" kind of source code : there are both C/flex/bison and VHDL files. Concerning the flex/bison/c sources, they are used to generate binaries for the VHDL simulated CPU, this is not a "complex/heavy" program and it should run anywhere gcc is installed, because i probably use malloc/fread/fwrite as sole external references. If the file doesn't compile it is easy to find why and there is no autoconf file to modify, only a very small script (4 lines ?). The VHDL compilation/synthesis part is more complex but i know no autoconf/automake version for VHDL. We can detect tools and compile/simulate with a set of scipts (even probably Makefiles) but all the functions done by autoconf (detection of machine-dependent parameters such as size of ints, compiler version etc) has close to no meaning in VHDL and on top of that, we use the "least common denominator" approach so we are sure that the VHDL sources will compile/run "as is", with no modification. Of course, all this rants hides/means that i don't know how to use autoconf ;-) > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: nicO, is it possible for you (or Cedric) to tell us about your Berlin trip ? i'm excited to hear it ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jan 8 03:51:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Nn7F-0000Ef-00 for ; Tue, 08 Jan 2002 04:39:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 04:39:57 +0100 (CET) Received: (qmail 9436 invoked by uid 0); 7 Jan 2002 20:49:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 7 Jan 2002 20:49:38 -0000 Received: by moria.seul.org (Postfix) id 333A41467FD; Mon, 7 Jan 2002 15:49:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E85D8146803; Mon, 7 Jan 2002 15:49:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8A5CD1467FD for ; Mon, 7 Jan 2002 15:49:36 -0500 (EST) Received: from ifrance.com (vlt4-21.n.club-internet.fr [194.158.107.21]) by relay-3v.club-internet.fr (Postfix) with ESMTP id DC4DC1711 for ; Mon, 7 Jan 2002 21:49:33 +0100 (CET) Message-ID: <3C3A5ECE.DE286092@ifrance.com> Date: Mon, 07 Jan 2002 21:51:58 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] "Tree" References: <3C294ABF.F45B4A3A@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I have just read the package from Whygee and i have found an horror : specific entities for trees. We don't need that. Synthetiser could recognise the loop and transforme it using a tree. It's automatic and balanced depending of the time used for the signal to come. I know that synopsys write a whipe paper on it. But it's old ! I have verified it. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jan 8 00:34:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Nn7J-0000Ef-00 for ; Tue, 08 Jan 2002 04:40:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 04:40:01 +0100 (CET) Received: (qmail 21608 invoked by uid 0); 7 Jan 2002 23:31:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 7 Jan 2002 23:31:07 -0000 Received: by moria.seul.org (Postfix) id 6830A146811; Mon, 7 Jan 2002 18:31:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5D1DE146816; Mon, 7 Jan 2002 18:31:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 11F5E146811 for ; Mon, 7 Jan 2002 18:31:06 -0500 (EST) Received: from f-cpu.org (kdl11-34.n.club-internet.fr [213.44.9.34]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 36E2F169C for ; Tue, 8 Jan 2002 00:31:03 +0100 (CET) Message-ID: <3C3A308E.B5C6A47A@f-cpu.org> Date: Tue, 08 Jan 2002 00:34:38 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C294ABF.F45B4A3A@f-cpu.org> <3C3A5ECE.DE286092@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nicO wrote: > I have just read the package from Whygee and i have found an horror : > specific entities for trees. a binary balanced tree for buffering signals, yes. > We don't need that. it is indeed useful in certain circumstances. > Synthetiser could recognise the loop and transforme > it using a tree. It's automatic and balanced depending of the time used > for the signal to come. I know that synopsys write a whipe paper on it. > But it's old ! I have verified it. 1) never trust a compiler/synthesiser, unles you can look at the output 2) if you don't like it, you are not forced to use it : don't compile it and the default architecture will be fine. 3) Synopsys is not the only compiler on earth. We try to be as open as possible to other EDA toolchains which may not contain smart optimisations. If we design code only for Synopsys then it could be useless with other tools. On top of that, it is not even monetarily free... which explains why few people have ever accessed it. 4) if the compiler is smart enough to understand what the fanout tree does, then it is able to do a better work. Otherwise, we have a minimal failsafe. I am thinking of the "extreme case" if we have to use Alliance as a last resort... 5) Evaluating the fanout's "cost" is necessary, otherwise our "time budget" will not hold. When writing in RTL/HDL, one does not necessarily "see" that an operation requires a large fanout and this counts in the design budget. A "hidden" fanout tree can slow the clock frequency down if it is not identified. At least we can hint the synthesiser to balance the fanout before or after a pipeline stage bareer. I know that "advanced" tools can do they work nicely but we have almost no chance to use one. If i can skip the "pseudo-VHDL" part of Alliance, a lot of thing will remain to do manually, such as place/route through C files... It's probably the ugliest thing ever, but Alliance has (only) 2 good sides : it works and it's free. The rest is horrible but at least i can use Alliance. Does anyone know another solution ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jan 7 11:54:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Nn7J-0000Ef-01 for ; Tue, 08 Jan 2002 04:40:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 04:40:01 +0100 (CET) Received: (qmail 733 invoked by uid 0); 7 Jan 2002 23:44:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 7 Jan 2002 23:44:17 -0000 Received: by moria.seul.org (Postfix) id 2BB19146815; Mon, 7 Jan 2002 18:44:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 16CA2146818; Mon, 7 Jan 2002 18:44:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a035.home.uni-hannover.de [130.75.232.35]) by moria.seul.org (Postfix) with ESMTP id D1667146815 for ; Mon, 7 Jan 2002 18:44:14 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00508; Mon, 7 Jan 2002 11:54:45 +0100 Message-ID: <20020107115445.34046@thrai.stud.uni-hannover.de> Date: Mon, 7 Jan 2002 11:54:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Error with the fractional flag References: <20020101134701.35619@thrai.stud.uni-hannover.de> <3C327B1A.CBFB998A@f-cpu.org> <20020103030100.51944@thrai.stud.uni-hannover.de> <3C350001.9940C5A7@f-cpu.org> <20020104023720.45475@thrai.stud.uni-hannover.de> <3C364BED.DBACF05@f-cpu.org> <20020105015055.03027@thrai.stud.uni-hannover.de> <3C366AD2.35DAAAA5@f-cpu.org> <20020105042757.35029@thrai.stud.uni-hannover.de> <3C388D47.9C0FA05B@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C388D47.9C0FA05B@f-cpu.org>; from Yann Guidon on Sun, Jan 06, 2002 at 06:45:43PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jan 06, 2002 at 06:45:43PM +0100, Yann Guidon wrote: [LNS numbers] > The advantage of ADi's definition is that there is no such problem. > the multiply's result is simply shifted left. Now you're talking about *fractional* numbers, not LNS. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From guidon@messiaen.lip6.fr Tue Jan 8 11:02:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Nv46-0006BR-00 for ; Tue, 08 Jan 2002 13:09:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 13:09:14 +0100 (CET) Received: (qmail 19960 invoked by uid 0); 8 Jan 2002 10:02:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 8 Jan 2002 10:02:51 -0000 Received: by moria.seul.org (Postfix) id 102CE1467F3; Tue, 8 Jan 2002 05:02:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D96AA14681E; Tue, 8 Jan 2002 05:02:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by moria.seul.org (Postfix) with ESMTP id 31D261467F3 for ; Tue, 8 Jan 2002 05:02:49 -0500 (EST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g08A2iAC004378 ; Tue, 8 Jan 2002 11:02:44 +0100 X-pt: isis.lip6.fr Received: from enseig.lip6.fr (enseig.lip6.fr [132.227.67.130]) by asim.lip6.fr (8.11.3nb1/8.11.0) with ESMTP id g08A2it17580; Tue, 8 Jan 2002 11:02:44 +0100 (MET) Received: from chopin.lip6.fr (chopin.lip6.fr [132.227.67.62]) by enseig.lip6.fr (8.9.3+Sun/8.9.3) with ESMTP id LAA09979; Tue, 8 Jan 2002 11:02:43 +0100 (MET) From: "Yann Guidon [systeme]" Received: (from guidon@localhost) by chopin.lip6.fr (8.11.6/8.9.3) id g08A2hV16897; Tue, 8 Jan 2002 11:02:43 +0100 Date: Tue, 8 Jan 2002 11:02:43 +0100 Message-Id: <200201081002.g08A2hV16897@chopin.lip6.fr> To: f-cpu@seul.org Subject: Re: [f-cpu] Error with the fractional flag Cc: whygee@f-cpu.org Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! MR: >On Sun, Jan 06, 2002 at 06:45:43PM +0100, Yann Guidon wrote: >[LNS numbers] >> The advantage of ADi's definition is that there is no such problem. >> the multiply's result is simply shifted left. > >Now you're talking about *fractional* numbers, not LNS. As the subject says, yes. it looks like there was a quid pro quo... > Michael "Tired" Riepe YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Ste Partners-store <> Tue Jan 8 16:26:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16O0XW-0000Fy-00 for ; Tue, 08 Jan 2002 18:59:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 18:59:58 +0100 (CET) Received: (qmail 24162 invoked by uid 0); 8 Jan 2002 15:25:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 8 Jan 2002 15:25:25 -0000 Received: by moria.seul.org (Postfix) id 979721467FE; Tue, 8 Jan 2002 10:25:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B744146804; Tue, 8 Jan 2002 10:25:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mel-rto1.wanadoo.fr (smtp-out-1.wanadoo.fr [193.252.19.188]) by moria.seul.org (Postfix) with ESMTP id CE0361467FE for ; Tue, 8 Jan 2002 10:25:23 -0500 (EST) Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto1.wanadoo.fr; 8 Jan 2002 16:25:22 +0100 Received: from mitac (195.6.101.86) by mel-rta8.wanadoo.fr; 8 Jan 2002 16:25:22 +0100 Message-ID: <3c3b0f623c3e0355@mel-rta8.wanadoo.fr> (added by mel-rta8.wanadoo.fr) From: Ste Partners-store <> To: Pour vous <> Subject: [f-cpu] =?ISO-8859-1?Q?90 mod=E8les de portables MITAC, =E0 vous de choisir !?= Date: Tue, 8 jan 2002 16:26:01 +0100 Importance: normal X-Mailer: GOTO Software Sarbacane Vs P1.13b Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3847625033358668" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multipart message in MIME format --3847625033358668 Content-Type: multipart/related; boundary="3032823044421384" --3032823044421384 Content-Type: multipart/alternative; boundary="5337865482084817" --5337865482084817 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable --5337865482084817 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: Quoted-Printable Janvier 2002 - N° 1

Nous vous souhaitons une bonne et heureuse année 2002=


PARTNERS est spécialisé dans le destockage de grandes marques info= rmatiques.
Nous sommes importateur de Mitac, industriel qui fabrique pour de nombreuses= grandes marques informatiques.
Nos produits sont neufs, performants à des tarifs séduisants
<= br>
Mitac a obtenu 18/20 dans Micro achat sur un comparatif, c'est aussi le choi= x de la rédaction.

= Vous trouverez dans le fichier joint, l'ensemble des 90 modèles propos&= #233;s.

A partir de 1323,27€ hors frais de port
(Soit 8680,08 F hors frais de port)


Configuration de base valable pour tous les modèles
Lecteur disquette
Carte vidéo 64 MO SDRAM en mémoire graphique, mémoire partag&= #233;e
Carte 3D compatible Sound Blaster Pro, Full dupleix
Haut-parleur, microphone, 1 sortie VGA, 1 RJ11, 1 RJ45
2 ports USB, 1 port Infra-rouge, sortie TV
Carte réseau 10/100 Base TX
Modem 56000 Bauds
2 port PCMCIA de type II
Batterie Li-Ion 8-Cell
Compatible Win 98, Win Me, Win 2000, Win XP, Linux
Garantie 1 an enlevement et retour sur site


Pour toute commande effectuée avant le 15 janvier 2002, nous vous offro= ns la sacoche Mitac
d'une valeur de 220 F

Vous pouvez joindre David
Par téléphone au 04 91 47 17 48
Par mail en répondant à ce mail
Tous nos produits sont avec un réglement comptant à la commande, p= ar CB ou chèque bancaire


 Si vous souhaitez vous désinscrire de cette news, il vous suffit d'envo= yer un mail à
DESINSCRIRE= + votre adresse ou vos adresses à retirer.
Si vous souhaitez vous inscrire à cette news, il vous suffit d'envoyer = un mail à
INSCRIRE + votr= e adresse ou vos adresses à ajouter.

--5337865482084817-- --3032823044421384 Content-Type: image/gif; name="microachat.gif" Content-Transfer-Encoding: Base64 Content-ID: Content-Location: microachat.gif R0lGODlhyABGANUAAP///4SEhKWlpa0AANZaUq1aUtYYAK0YAP+9rXtaUnsYANY5ANZ7Uq05ANa9 ra17Uv/erf//93t7Utbera29rcbexnu9rdb//87//3ucraXO91J7rdbe/87O/3t7rWNjzmNaxmNS tWNKtWNKjGNCjIQxlK2crf/e///O//+9/617rdZardZ7rXs5Uq0YUtYYUtacra05UtY5UgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAyABGAAAG/8CPcEgsGo/IpFIY IsAIBQajAK1SqVWCVYu9bguyWCwsJpfP4rR6zW43Qsu4fE6v2+2kWDRGiB1iDS4HLw1phYAuCy6B BzJ/hQaCBwaPgIAyhQ2YlpmbmZyAnw2ioi4jd6ipqqt0IWIEEAEPBXoFCQljh4e3tre3YzG+vmGH lmKFxGTFC4aIzS7HMdDGcKzW19h1eQcFHBQCAhbgAhQPf2QyEhnkAibg5QcNAe0mFCbxYZv6ndG5 nNOIAln6AyrQqWwIEyp0xQBGAA4nIHKAeEEFtE8BTEg8EYEDgALQBFTgCAAGwWK6zmi6FIiWMlAw i10UobCmzVUkqMQQGaGnz/+SBIFlqADgJwAAfgoI8HiURdCVMZhFNcatWSBkLY25KFBokbEYJG6K HSsnBNedTI+qNQmsQQIKJ9SSBBDordoITr+mTCOVWTExBU5a8ipQYMBqZBMrFjIijYC4HDlGAOCg kosAFHrOBXDij1IHCCacCIwOq56r0ZA1+qR1YOrAlsIunj3WlZjMk+UC4AANTIMMHXoejQBZ8AFB KQ81SgTMT5iL/Zx9CkPJaxposmlrV9jYLdzhRY+e0JXgsXjOkyv8WfDiT9BjMgxEWzSJVqEFjQ6s H8RtJf1gtvgRjyWIbWfgNSIAlhlnDErm1QuY5ZZbUSn80UICBWQ41UoHtCD/QQAZzOMBLQS9kEAA GAYAWwEqQhMPi+t88w2JYhx04I2rjFCAid+Fl9sFugRAFINFxcVWjAJoIABBi4AoUgUcVNBBBRTE IF8DHohEQQUCqCBOBU4VkmUFDkA5EQcYUHBVgTi2WYcr8nRw3pxnZOBRXEQCFUMGDkwUAVvMJDAU RHj2xIEAi7gg0gmMRulABxjAts5EcfkUAQqH/pGdm5zK0VgMQqrFYG6WlLcZkXktJZxTYYDowKmi CmBACwJIeBcAjmSwpXByCVfRAWx2KuwRtgUg56h3pRGhqHcFVgAFaTGwSHlDMitqBLelde1OFHSA p7WVchCDjcOWW0QIhfA0/9xkeCZlrHjsqiXNW4Wq8IcHPR7lhLV6LMgscTFQ4MCE48VQwQXgfbSp uQw3ptS3DjggKiDlcTBZnxNi20ABI+VGwAHzWKyWftwwhUJgQn4rngMEiJSWSZK8SiQDNDFs8weu KBWvAzCkBdKyALAwEoMONDn0UWLoOvE0BxyMgH4yhCoXA/oZHNzIBJU82WQwLHyzsI299bIKE36c MgAIdDNhZRBWMOEfIq1VSS0nvSvvANI8+y1bakBLtNdfcxrCZf7i9YDPAcuJVzcv/2E3ZwfQqxbV +TTQ3hlSQ36MkBJKA8p3FwMeeJt5PHA0Uod7TO9kMZger1MsigyAeovKG/+dGFJlAPEjL6hb1IC4 o5WbAyWMXq4robZrOp4FqDB0BAc4/22qsiOg6NVIE+TXS0PJfYwA2KMwNzRbMti18cPmweddl1UL g9+UDeA7AB+bqhYLDSwl19zNyFDehHkRg3mOUhl/FAJ0QRMd+gzkCvANR3x6K5LFJoM/8H0LJG+Z EC161BGCEGMqVpLcUWDDDH/p6RBbgR8AGKDABWonD3GLi3oKoAEJ/USA1UIKyAQgqj5AKzfq+aAZ MIGZbxEAID8k4FMWkDJS1cyFbTJLEkuSwm/hSXxomRgTKTCxZ00Ii6kxAC3aNrH7BGxCbEEh59rV QiguhgT2OwpbapUnvET/Ll+dad/+WoDH9QBjAwW4UuYAALwzqqUDQTHAW45FGWC5sU0ieJbI7Biw tDBvh+wijuOGpMmdTEiHmxNJAPTjgaN1Jhr5ImR+dlIrj7mgjY8kCwmaeJQHhER2pKqiWgq4PiVW MlaTcIvLOKCCnVRLPW2ho9z+IAFVxYUDfyBXLLVjltPBRlVEQiZmzkO93LDlIfECgABONJRKUU1/ R7GectB5lAsIYB61m8zHYhCsaS5GBJxTCy2yKCr8gapadlQKUTjCgkRwTGXeqF1RyLe7S+hhSHhy VHCIo7lx2dNAs4SI7eThNiIdInm15MYAV0gQE8qlUElRIavScAATWAs9/6Kq2hsuup0QYPMoXglA oaiYNOwhJYWIiwoNX6qWj/nPhAGUisFEpTLO+CEN0qRpYkZgAV5FABIBwEA/PSMArY5MHjUsatYO R1RB+CEAGhCVOQzhiKW+VHyCeaJUFSMCFTSEBQ5JQ/MYwIKG2EcPDAgAXxkAjAc8QAqETYMjCiA0 8SCAaocIwxZewtKtwAABFUCAA1jw1K9Eda5i2YYkGlHZ4xSSEZJIQyRMyxIxSII+ZjWgHwRBGH9I hWS4HRBK6glam9hmDZqoBEoUq4a/tGEBzKiOMSJbhr9swhhKbUM/YNlbbOShDRiiBYaIyxrTfGJ7 heBFgCzhiedqQhT+KP8IIAhRH6/wtroJ+a0u1EGB+tYXJtF4LjDMoIYYbYk0e3FoMT5oDDK84HaH +Cx8E9KdZnjAARg4QYQxEED4AFe9ftnTSOKygqAwIwxSQQYnzJDhQnBDHPaVxkwXLJbflkFQRJlQ BaCTnP2qgcT8BMBalZoV5YBhGlfZp481MBIMiKsQ1GWxKj5liIehB0/M5S4oMqzUuB2lwxYmLwhZ wwctS+WgPnnqe5VsDdsUI2RFyg1s1Cvd4u6EkdJKDjGgQ14uF4MbHc0eWMhsEyYry23E2VrQpgNc TCwgkOcFoZUjYK8xyEc+1lHNGI5DifbweCunEzOfa+LidEkMTyQpmlX/MEFgljYnf3daId5i0AL7 VC4MQcmQhp66EjGG9Sj6eeWmubMGSW4t0LvhMks/tA5whOipzLAy/cpTbAuMchnBCACK7UuBADz1 Fg/wKQwMO+Zdo8I2JMJMqjVzlEaDMFBjqgCUyiSANbNzSgKLEgc60GhmuKCZZELTRIx8KEHMQ91E 4gCRFeztVOThzANLzwR9yZdgDIpRooqSJZTdkUoNBwM7hvFOLfWnAyxKZenpdsHf1GT9xQWv8TpB dKiFgk+KCpnsTJioYOCCVuULBTncjce1RaQTJHnkcfCz2EiVOn2aJmQuZxYtlE3U2RGke+nUDwyY ZczcgPoEFZAr0FXh/+IiDkcMecbLNMIwFAlxlgEabQqq57QvlX3MyUgza57pp58CIOzr+iH41unw qULkE9cG88jFThJHoOjnAQijJNMLgLeOXlKS8joE/Oy4FdmBUuR7X4KLwUdRmEdmN8ZYI+BdC6V5 5hiLDXCeqEBilUTo56bmwPS3nvrzzB+h76YSDs3lgUtaMCNzBUxvJRbNFv/lcJ72jgRghNTyprwo 04XAvO2R8Ftxe/MPy/Pem3c5tyizM4DlWb0H3TIPC2wp7E7B9IRoP/1UMJlzFN2nwXZmIWcCZYig yBygntXDPxhAHuQgJYSiQZ6hARcEDdLXfudiCcBBURojQILnVBvTSv/OlxpocFPgx0P6VHMtMCkT lHTpxzHrF00KeAef8jDDcxE7p0Fb8X0e1FxTITWUtAAiRHeg8kMSMnWiQjUPNXtIVoJ2YBsZxCtc kgG6oi1zhEakJWzGNBwBpBR3oQKKVHbLZHlOwQ0mBBsJCIQfcF2iBxlSgjEOiAHpAhGD9xWkBgiP U3zhJ1ZnUxSz9UtFkRcHJS8kyIVzACcOFB5pVhQOOEIrSEBjF16LQHYDFTTr0Yb6oihHkxcHVC1U o0sjhB14OAdhY38UdR5WJ0cgY3mjgDuCUiVwIzGcqCDfck5pMU9hkC90CCV2SE+VWBY3uFMv9S0R gEgcQyS7JwaYQSX/XGE3lGQiGTAh9sJObAEyR2NHBzQhDDAADVB7QNgYy8IuEAAl1eiKMAU9NPQt 7uR3JjdjvgMo/yNWKqRD88BIiAh2tqgCArCFQNhAhxg0CvBULiAfOecH2PRMArAOefYxe6gnArRV NzU74ABoajFKt2FFUeKOJagjnEcqbHAAP4QnJpGL1+InxdGEpUiDyqRqFqkWZvhJATRFasGQCigC q7M1pyUGqqcWGHAcZEUkVvVUMQSQMWAB0/MHqcQrd3GMTFcUJtl+szR3wXdng/QRcHN3/PIIwCE3 i2UBW/VQ4KKDSrQJORcBIBCLcRACAQADMMAzDsB6N6YHKsAzXukAWgEAawVAimshEGHwAF2JV32g V32FV/vEDQMjHmzBAAQgBStgajDQMVgXlNPnCqYVW1YBCMehAO6hBsdRC4pZWwZACbnWCQ1gWlAz aUEhU7QlU2KQW/oBjbQRBAA7 --3032823044421384-- --3847625033358668 Content-Type: application/octet-stream; name="TARIF DIRECT MITAC au 05 01 2002.pdf" Content-Transfer-Encoding: Base64 Content-Disposition: Attachment; filename="TARIF DIRECT MITAC au 05 01 2002.pdf" JVBERi0xLjINNCAwIG9iag08PCAvVHlwZSAvQW5ub3QgL1N1YnR5cGUgL0xpbmsNL1JlY3QgWzAg ODExIDU5NSA4NDFdIC9Cb3JkZXIgWzAgMCAwXQ0vQSA8PCAvVHlwZSAvQWN0aW9uIC9TIC9VUkkg L1VSSSAoaHR0cDovL3d3dy5wZGZtYWlsLmNvbSkgPj4NPj4NZW5kb2JqDTUgMCBvYmoNPDwgL0xl bmd0aCA2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pg1zdHJlYW0NeF6dm11v2zYUhn+B/4Mu W4CVefitXTZJgQIrug1Gd9ObLHXSDM1HMwfB/v1IWe5c6aV0jlHAaEQ9h6Qe84ikJWp0/kf959Xd 6n7lY0umiVG3rnHWtqZ5Q6ntQvO0XeXT2qBNPvXpZnW90s3N6u1mtX4XG6JWu2ZzXU7p44XQRO/b GJrNXT5xc5WPbl6aVx8e7m932+en183m79XFZvU9V0lGtzHXGUKrUxNMSyFXavaVNn8299VaSKfW JVzT2fn6/NP5+uzjh7cfD7X9vq8vuVLRoT5qu9JJVn0Dieojk9bGh7VN7v/qaoHyia2vXCLSa6PX Vh+i1GLYfNlSpTFnF7+uf3v//v04hi9yj2PErnUOx9g87C6/Ndv75uL56eGfcaRxa0j7NnfIhjaN +/PjelTZ4FuL4bPzJdiYasUmLcKdK9ohvSzA7b99AM7Xf0yPL73L+oyDNFljlYnNYohsz+AGfDZ6 sf2DMoptcuMWsJ0hmi0NwQJrCDeL3T5oQ7TAG8LJhqhyglyMMYhDMfjmQpdKAjjRHKS55iDMNwdx Rsbbm4M03xzEyfmgouWagzEE5nKUfNMZN2ERHswhmm0Owfl2tEgP5hDOTpWQFphDOFlvVerY5lAM gbmgy2U41Ryi2eYQLDAH8cVuH8whWmAO4WS7qIJjm0MxBObc2Dpf2wRlO5uQAmETlp8hJ6hA1YQl l6Kynu1pEkAgydj++ImeEM1WheCjyXyVHmwhnJ8YES1whnCyMarcssUYgzYUQ2BO90ujU80hmm0O wQJzCOcnRkQLzCGcnCEViW0OxeCb82kf9zRzkOaagzDfHMYXuz2YgzTfHMTJEynHXgDAGAJzLrZj mi8OwGxvgOXP/iG92GXrXW8NwJydjoM1gOe5v1OePQ9BIQTOTCrtGLdgER6kIZptDcECbQhn5MnB G6Il4hBPrkvKsOf+MIZAne6jjJuwCA/qEM1Wh2CBOoQzEuWgDtESdYgnn5LSmq0OxeCrc51u7XjQ stVBmqsOwvxVAMTZ2RLSAnWQz+sBr4g9sYQxBOoiFQfjJizCgzpEs9UhWKAO4ovdPqhDtEQd4imn QNWxZ5YwhkCdN60bt4BtDsBscYAVeAM0O1kiWGIN4BQoqcCeVKIQAmfWll+ETpWGaLY1BPNXAxDn Z0pES8QhnvJtSxn2rjKMIVBHfU9OVYdotjoEC9QhnJ8pES1Rh3jy3qgusdWhGHx1tvOtH98j2eog zVUHYb46jC92e1AHaYE6yFNwRgX2qgDGEKjzsR3fIhnmMtUZCJ9/4poDMH9NAOnFPg97Jwjmb50g mnKZYOcEhRA4s6kNbtKCRXiQhmi+NUQLtCGckSoHb4gWiEM4ueAUsZ9WgDEE6qhrwzjR8tUhmq8O 0QJ1CGekykEdogXqEJ5vclYl9k0OxhCo0/1zXqeqQzRfHaL5SwKI87MlogXqEE7Ok9LsTUsYg6/O JJo+IMZWB2m2Okjz1WF8sd+DOkjz1UGcXOdUZM9PYAyBumAmT4fxzQGYLw7AAm+AZidLBAusAZp8 csqz9ytRCIEzZ6cPhvGlIZpvDdH89QDE2ZkS0gJxCCcXvSL2nheMIVBn3PTJML46RPPVIVqgDuH8 TIlogTqEk6ekEnunGcYQqMufk0fD+OoQzVeHaIE6iC/2+6AO0QJ1CKegk/LsVQGMwVdHk2kp29sU ZUubovzFAGAX+zpsmkxRwY7JFM6LABJsl0wDCDS5rj9+oilE82UhWuAL4YzkOChDtMQa4sl3Xjn2 EgDGELizevqUEd8dovnuEC1wh3BGdhzcIVriDvF5FOVJCfuZShhD4C4fL3FPdIdovjtE85cBEOen SkRL3CE+LwWMsuwJJYzBd9f178OdqA7BbHMI5ouD9GKfB28IFmhDOAUTlGbPJVGIY2n3Kx/KPmZ5 UzLPOfvdlTch2cI+bVfX5T1D6srCPYb+jYPDGaY8DHE4I/+VypuI1TOMmw1gdVeaP3dGNOWKzJzh UlcWPDNn9HvtQ0ed7V+UfNOf91O571+krJfvC+rlVH5ErRSGzpcvSr089u9y1st9/1prvdymorte nlXO4Xr/Q2Kt3Ccq34t6eegvd708r0n7X9dr5XnhM1d9TiRuptylUAZdvTzE8gtZvTwvI/xM85zp yme1mHQZSdVy21HZdq6X5694nGme9baMw3q5zcvGmeKcItJM80wXZgeGiX0qrpf7/v3qernTM4Wm z6D1cm1mBwbljDU3MCi42YFBzs8NDDJhdmCQjrMDIyU8LvINrmQqX15Ev88pOhE1eTbcWL0vz8n9 x53QxCaZYe50k3N+OVQS/lFiP9s2Xx6unu+297vmsvlsPe3KR3N9+dfT7ffn/v+Plz9eWj+KbhId ou8P5QYd37PO391d3n4DoM1NPWrW8V3m1dnD479Ptzdfd80fm4vmw/O33e3d9svt5efXIJCxLnd/ mNeXAz+34Otu9/jLev3y8tI+frkujWmvHu4Ocf4DWMk3AmVuZHN0cmVhbQ1lbmRvYmoNNiAwIG9i ag0xODczDWVuZG9iag04IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMyAwIFINL01lZGlh Qm94IFswIDAgNTk1IDg0MV0NL1JvdGF0ZSAwDS9Db250ZW50cyBbNSAwIFJdDS9Bbm5vdHMgWzQg MCBSXQ0+Pg1lbmRvYmoNOSAwIG9iag08PCAvTGVuZ3RoIDEwIDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+Pg1zdHJlYW0NeF6dml1v2zYUhn+B/4MuW4BlePjN3W1NOhTYgKEwetWbLE3aDE2TBSmC /fuRtlw40ivxHKOA0Zh6XpN6rCMdWTSY+o92r1d3m9+2m7N3aSDSxg/bm81+gAYyQcchhaBTHLZ3 GzNsr+rA9nl4Rf71sP1nc7FdhkPSxWL6/ON5D7d28bNtiF26eF0WcGd6tAte+4zpv96/fz/lgyZ7 zHtrtPWYp0RBpTR0M1LRdmEOn6zprmF056LO0xmw1QGYbw7ALnc/+iAO0NRd88EbgCXaAE7RROUy 2xqIEEijpLOfzqC76w7WEM3XhmiBN4Tb7roP4hAtMYd4isEocmx1KIPvLpas81Q92x2k2e4gzXeH 8e66R3eQFriDPCVXVLXRzdi7gxkCd9G0/SB2Z512C3R1N/z+4dePvYxRIIogm7v0KBDi3cU7n3cC Ef324o8pPtv3oz+EU3RG5cL2hzIE/rydfj5b3gwVmpvxAm0zllEwR2czVCBsxlJMXkX+0TYLEKiq u729f6ItRAuFoQiBM4QzauWoDdECcwinFL1ygS0PZQj8Ga/NtNLy/SFa6A9F8BsDiPNLJaIF/hBO MZIKxPaHMvj+Qt7nnuYP0jJ/MILvD+PdxY/+IM33B3FKJigbuf5ghsBfjJqmZ0q+P0QL/aEIgT+E s+snpAX+EE6peFXYfTnMEPjzSU/t8/UBWGgPJPAbBUSzayeCBeoATTEHFdi9OYoQiLO5zeNUc4gW qkMRAncI5xdORAvsIZySLcqx+3OYIfBndimn+kO00B+KEPiDeHfxB3+IFvhDuNQfyuD784maiBP9 QVrmD0bwGweMdxc/3mSBtOAmC+Rr52AVsa9cYIZAYLB6evjy/QFYqA8kCOwBmlE8R3kAlrgDOOV6 0VnYTQOKEJhzTvspzleHaKE7FCGQh3BG6RztIVqiD/GUS1DRsv2hDIFA2q3kVIGIFgpEEfymAeL8 2oloiUDE167BqsS+9oQZfIGuBB2m165sgZCWCYQRfIEY7y5+FAhpgUDIU3ZRBfbVC8wQCExRh+m5 ky8Q0UKBKEIgEOHsEgppiUDEU7FRWfZNa5ghEBiSntJ8fwAW6gMJ/N4B0ezyiWCJO4BTpqgy+5Y1 ihCYc1lHP51Bd9cd1CFa6A5FCOQhnF87ES3Rh3jK0aho2P5QhkAgFR2n506+QEQLBaIIgUCIdxd/ EIhoiUDEUwlGOXb7ADP4Am2m+aNMFLrw/tEISJ9zH42ANL91wHh33eNdF0jz77pAnEK2yrE7B5gh UBft7HkmvjkA88UBWOAN0IyaOWoDsMAaoCnWaxXD/o0BRQiceTd/kIkvDdF8a4gWaEM4o1SO3hAt EIfw/VOb7D4PZgjUWT9/jomvDtF8dYjmdwgQ51dKRAvUIZwiWVXYDQLMEKirr9XBqeoQzVeHaIE6 iHfXfVCHaIE6hFMMUUX242Mwg6+uXs623XCiOkiz1UGarw7i7IIJab46iFPyUXl2bwAzBOpml6V8 bzOUL22G8ruBOcsuknNU4GrGUnRJGXYPMA8QWPJl9/6JohDNd4VogS6Es2sjpAXSEF5FGJXYv9rB DIE6Z+aPm/HVIZqvDtECdRDvrvugDtECdQinlIzy7DYAZnDUhT1e32+5L/DZZ0/ZvfZi5w85sa0j mC0dwfwGAtLd/TXeakGw4E4Lwmv74FRgX8igiGPh3zchtltp9XvUrlWNTnZ4E7Nr7OP15qZuQFRa w59iaSoOW1jt7M8t6l8VXtnC+tUAZ0qb/toWybY9srKFz6U1Sitb7G76jgv1zja7b3bbvRgP1Pjl 8f3A8ji1H2gXBmMJ7YuyPJ5iOz6Xx+srrUwuutx0L49XlWu42f88uTQeMrXvxfJ43O3u5XE//n6/ NF4bprWPr4XEr4z7euXnV6bnY2q/uC2P1zodVqbnbWmvi8Nk2pG0OO4KtXuey+P1K55WpueCa8fh 8rir7ebKcC0ReWV6tsTVA8OmXSleHg+5DSyP10v45UG7q6DL48auHhhUK9bagUHRrx4Y5MPagUE2 rh4YZNLqgZEzPi7qCa5VqjA8fqmbmiFTO9WGwZn9eC3uP8+ENg3ZjufuL7Xmt7dawT8q7G+vh8/3 Vz/urr8/DZfDJxfoqb0MN5d/P97++2P3/4fLx6NTx8+TXaZD+v6tOqHjc9b5u7vL228AdHWqR9M6 Psu8env/8N/j7ZevT8OH7cXw549vT7d3159vLz+9BkHW+br88bKyvfFyBl+fnh5+OTt7fn7WD59v 2mT01f3dIed//5vsqmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNMTcwOA1lbmRvYmoNMTEgMCBv YmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAzIDAgUg0vTWVkaWFCb3ggWzAgMCA1OTUgODQxXQ0v Um90YXRlIDANL0NvbnRlbnRzIFs5IDAgUl0NL0Fubm90cyBbNCAwIFJdDT4+DWVuZG9iag0xMiAw IG9iag08PCAvTGVuZ3RoIDEzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pg1zdHJlYW0NeF6d mttu3DYQhp9g30GXCaDQHJ7Zu9Z2CgMtUASLXPnG9SkusrFrrGH07UtK2nYt/ZJmjACLYEffb0qf NSJpUaPLP+o+r3ebX7abk8+xIVLaNdu7TV+ghrRXoYneqxia7W6jm+11KWxfmw/kPzbbvzbn23nY R5UNps++nq3hxsz/bJNW6exUnsGNXqOtd8olTP9xcXEx5r0ic8w7o5VxmKfoY2tds5oRszIzY7g0 evUcBnc2qDQeAVsdgPnmACwQB2i7es4HbwCWaAM4JRdb7dnWQIRAGkWV3HgEbGuI5mtDtPFhlR68 IZxWz/sgDtESc4in6FxriK0OZfDdhZxUGqtnu4M02x2k+e4wvnregztIC9xBnmKKbRnaakbvDmYI 3JWUIuG97hDNd4dogTuEsxsmpCXuEE8pxjZEtjuUIXAXdL0O73WHaL47RNvkVunBHcLZPRPSEneI pxhSW6SsZgzuUIbAnRt754uboHxrE1SgbMLy++QElciawJTItNqyTU0CBJqM7b5/pylE82UhWuAL 4qvnfVCGaIk1xFPW1Eb2OgBmcNz5HtdO6fGTcfKzx2zv3ad+TFLvZcR2hi7em1+//Px1LaOXDyP4 awmMr14461KVD+nT89/G+MRb7x7iFLNpE3tKCjM47gd/ISgad2e+P0QL/aEIgT+EM/rt4A/RAn8I p2RD69nTUpgh8OeiGtvn6wOw0B5IEMgDNKPxDu4ALFAHaMomtIY9KUURAnEm1XG81xyihepQBH9R AXF+40S0wB7CKRnbOvZsB2YI/Oku5b3+EC30hyIE/iC+evIHf4gW+EM4pRBbYq8rYAbfn8ta2fHt y/YHaZk/GMH3B3F284Q03x/EKfvQpsz1BzME/iJVEe/1h2ihPxTBX3VAnN0/IS3wh/BuG9uxH38w Q+DPG+XGI2DrA7DQHkgQyAM0u3ciWKAO0JQytYb9BwgUIRBnrXJjnG8O0UJ1KELgDuKrJ3+Qh2iB PYRTTlqwkQ0zOP761b6jbt/iLT752WO2d2+zV37cs9nuIS1zDyP4Cw6Mr164YasH0oKtHsiXRYdr NXvWAzM48geBMSg/btp8gYgWCkQRAoEIZ3TeQSCiJQIRT7lMWxN72QEzBAJ9VGOa7w/AQn0gQWAP 0IzOO8gDsMQdwI32sfXsbVYUITBnkwpufO3Y6hAtdIci+AsOiPN7J6Il+hBfVhyujZrtD2UIBFJW Yfzg5AtEtFAgihAIhPjqyR8EIloiEPGUc2ode+IKMwQCtVZx/OzkC0S0UCCKEAhEOL9/IloiEPFG p9QSe+oKM/gCTaLp+25sgZCWCYQR/KUHxNktFNICgZCnHFMb2Yt+mCEQGMzk1Te+PwAL9YEEgT1A s9sngiXuAG60MW1ZC6xGDOpAhMCcs9M33/jqEC10hyIE8iC+evIHe4iW6EO8ITKtYS8cYMaxwB8b H+r8JkZdX3TrOu0nb6lcvOfbzV2pU3l+lrs3hu5tqsMBukKHI5Kp7MIRxi0GWJ3r8JeOiKZekoUj XMr1TBeO6Cbiw3k6a6rgT91xb+qeKj9f7wvzdar7NTPFUNbheqlelnl6YXChfNLC4EKZq9LC4EJR uYTrYbtppu5LH++2kubqpVnYhXzvht28ubop981CufQUt1B3KfSbbXP1EOsuyHzdpbrInq+bXD9n y9T9ss3WbaY6D52vl1/xuDA86229D+fr1qml+NIi0sLwTA6LN4aJ3UtX83WfamG+7jQolmZf71Xf PN+XA3WTqO44+jLn6+ulvf3/VIhNOvzt7r50vfpVbXlHne30trl5vH7Z3f7YN1fNpfW0rx/N3dWf zw9/v3T/f7p6Pmqe/3X8RIf0/qsyoOO2ffZ5d/XwHYC2DPVoWMdt9sPp49M/zw/33/bNl+158/vL 9/3D7vbm4eryIwgy1pXTH3p1/eLtCL7t908/nZy8vr6qp5u7Ohh1/bg75PwLB6mpkWVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmoNMTQ3Nw1lbmRvYmoNMTQgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1Bh cmVudCAzIDAgUg0vTWVkaWFCb3ggWzAgMCA1OTUgODQxXQ0vUm90YXRlIDANL0NvbnRlbnRzIFsx MiAwIFJdDS9Bbm5vdHMgWzQgMCBSXQ0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwgL0xlbmd0aCAxNiAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Nc3RyZWFtDXhenVdNTxsxEP0F+x98hAODZ/zdYync qiK0Ry5pSEIqAmkUhPrvO+MlbQjMNrUirSK/eePZ8fOzF43lH9bndNU9diEBkknJgjfRyf8zzFCi 2cw6DoNsJXiz6OadNYvuc9+dXyWDCNabfi4hNV9yELNJIUCKpl9xbD9loH8xJ9ffbvpT0//oLnuV jjZA5CQR8gGb6EguJsi+kRxLhtw6c0wFCrWSo5VmN5J987Tk6ngb2Xqwrd0KOYjI/puMXvoUYgQ8 bJf5J3mY2SdomHjgUgZq7VewBai1X75YcK1l+4TgDtt1NDkQtL6ydw58M5nX2rf2y5UAoaFfg75c ihAOG3akvhxb6SH1iIkHrssQW/vlsIj5NpKthdTQr0qmjO/9/mhypGa3J+/a3Z7It7s98bPF7Qd9 YY7v7f5IfWHzGqMvdbyN7Gy72yOPt7h9JRd67/V/uXx1ibJn5OrCq1lVfBazE6vlu8ucA5A3Bssz xXpA7yJI/PQ1om7Z1wwix2zOatgbOKDQVdiRLKkKo1exyF5lR2A2I6vXFYermwqzpaBeV+TejJDZ FUivLPC+J72yEGuPVZg3r9MrC7w9R6ZmaXgd9rzBvF6Zj0lOBxX2WexfhalIbzQUrehRg11BcWkV TiRDKhycSFmFHVuajmIQt9RgKlEAFU5pTP8U6ueCCnurY1Q3vgpbGtM/5vq5osLRj+kffRjRP1Ic 0z/aNKb/nD+UP/uamFCQr6lHNrWMaEIJfAQPOLvhHwOkZPLuzrhgk5Qhccg9K7yYmbun6fNq9rg1 E3PrAm7lYeaT75vlz+f6fz3Z7HntLjsf27vswxAXtJf4+svVarJ8+IDouNS9svY4tycXT+tfm+Xi fmtu+kvz9flhu1zN7paT29MPEpHz/PqvR5IMvK3gfrtdfzo/f3l5gfXdXIqB6dNql+c37cQQmGVu ZHN0cmVhbQ1lbmRvYmoNMTYgMCBvYmoNNzA1DWVuZG9iag0xNyAwIG9iag08PA0vVHlwZSAvUGFn ZQ0vUGFyZW50IDMgMCBSDS9NZWRpYUJveCBbMCAwIDU5NSA4NDFdDS9Sb3RhdGUgMA0vQ29udGVu dHMgWzE1IDAgUl0NL0Fubm90cyBbNCAwIFJdDT4+DWVuZG9iag0xOCAwIG9iag08PCAvTGVuZ3Ro IDE5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pg1zdHJlYW0NeF6dVk1PGzEQ/QX7H3yEA4Nn 7PFHj6Vwq1RVe+SS5gNSEUijoKj/vmMvqULASxhFsiI/P/vt7JvnRWPlh3WcrrqvfXd5Ew0iWG/6 RTcAaNAyBBOZIQbTrzpr+qkA/c6cEZ2b/nd33X9EdgGSlosRkleSQ06QFCejhyzsmCHTEdt8SB5O DrZs8emTB7I/PvVkJrk6ryNbD1ZRrUrmxIBa2RwCoLZa7COoD6YEpK0X2wykqNfgLp8tuGPdJ7rL RwSnrZdnAu0je+fAq8ny4F5Rr0p2mYGPy3UyOQZgbb0cR1BzXYKgrZfDDEFRr8FfzlqIxwU70V+U UJ/2FEid9uSdPu2JvCrtB7KMb8L+VDKmoE971LzjgelzndeRnVWl/eAuFOBN3J/orkxjYf/YcSg9 E6Mtb7Oa+CIkV6J2M+8WsgClMcSeMdT7eb+CSpy+rKgt+7JDsWMyF3XZK5ix0Juwo/oR0ILRN7Eg WWVHYEkj29YVZMS2riCRgm1dQWozQpZQoLYylr6ntjIOtcZNWJrXtZWxtOfI0WIN34a9dJhvK/Mh ltuhCftU8r8JUy61aaFoix9bsMtYUroJRypTTZhdsXITdhJpbRS5pGULphwK0IRjHPM/cRrzP3nb xqg2fhO2NOZ/lF4f8T8GP+Z/9Dzif6Qw5n+0ccz/Kb1rf8m1EkJsNney0pqEaDiz3MADLmn4PwAp mrT/ZryTkCxTJSEPovBqbmZP0+fV/HFrJubWMW7LYBaTX5vln+f6fz3ZHGTtfne5tve7D1Mi6GDj H99uVpPlwztEJ1IPZB1wbs+untZ/N8u7+6352V+b788P2+VqPltObs/f2Yicl8d/uZLKxGsF99vt +svl5W63g/VsUcTA9Gm13+cfYKQFwmVuZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmoNNjY3DWVuZG9i ag0yMCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDMgMCBSDS9NZWRpYUJveCBbMCAwIDU5 NSA4NDFdDS9Sb3RhdGUgMA0vQ29udGVudHMgWzE4IDAgUl0NL0Fubm90cyBbNCAwIFJdDT4+DWVu ZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDIyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pg1z dHJlYW0NeF6dVctu2zAQ/AL9A4/JIRvukrukemya3AoUhY6+uH7FRRS7hgyjf9+lZBeOGyouIYAy OJzlcLQco7H6YD/O2upzU90/BYMI1ptmWQ0AGrQMYgIzBDFNW1nTzBRoDuaG6NY0P6vH5iOyE4il XAwQfSFZ6gixdGcJNdRUShYLdalf4ou3JdfP/y8ZfVIr1oO9tMt8SO535siApbJZBLDULfYBijem CFTg10C2NdClXdeSfW3Blcr2AcGV+uWZoPTI3jnwBeShv7y+/KVhV/aXqxm41C8XBLjUL8cBirku ghT4NZCxBrm062qytRBK/aKI5WlPQsVpT96Npf1rxZL8DMGmXO9PeMcOlblbVEvFUT1T5UH67D4t sIl0XNF/zWOBpDSau37ZG5gx0bOwoz4uczD6LCbaxnYE1ka1eV2iI+Z1iXYb5nWJejNC1oahvDLW lqC8MlbA5YuzfleXV8akwZBHtTV8HvZRUqpkYQkpOLKwjykasjDVyZscin1n5WBXY7rAWThQmsrC 7FIrZ2HnYaQ2crpIOZhqSUAWDmGs/4njWP+Tt/9iesPTdWSzW+k6ayKi4Zo1pwZcc+FvFFAw8fTH utK4SFMpK84y4WFh5pvZvl28dmZqJo6xS4NZTn/s1r/2/e/tdHeWOqfqmm2n6sOUCjor/O3LUztd v7xDdCr1TNYZZ3LzsNn+3q1Xz5353jyar/uXbt0u5uvp5PadQuS8Hv+YcmnirYLnrtt+ur8/HA6w nS+TGJht2lOdP80IcQNlbmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqDTU3OA1lbmRvYmoNMjMgMCBv YmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAzIDAgUg0vTWVkaWFCb3ggWzAgMCA1OTUgODQxXQ0v Um90YXRlIDANL0NvbnRlbnRzIFsyMSAwIFJdDS9Bbm5vdHMgWzQgMCBSXQ0+Pg1lbmRvYmoNMjQg MCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMQ0vQmFzZUZv bnQgL1RpbWVzTmV3Um9tYW4NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNPj4NZW5kb2JqDTcg MCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GNw0vQmFzZUZv bnQgL0FyaWFsLEJvbGQNL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZpcnN0Q2hhciAzMA0v TGFzdENoYXIgMjU1DS9XaWR0aHMgWyANNDIwIDQyMCAyODYgNDIwIDQyMCA0MjAgNDIwIDQyMCA0 MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCAyODYgNDIwIDQyMCAyODIgNTY1IDU2NSA1NjUgNTY1IDU2 NSA1NjUgNTY1IDU1NSA1NjUgNTU1IDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA2NzQgNzE3 IDcxNyA3MTcgNjc0IDQyMCA3ODIgNDIwIDI2MSA0MjAgNDIwIDYwOCA4MDQgNDIwIDc4MiA2NzQg NDIwIDcxNyA0MjAgNjAzIDQyMCA2NzQgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIA00MjAg NDIwIDQyMCA1NTUgNDIwIDQyMCA0MjAgNTY1IDQyMCA0MjAgNDIwIDI2MSA0MjAgNDIwIDI4NiA0 MjAgNjA4IDYwOCA0MjAgNDIwIDM5MSA1NTUgMzI2IDYwOCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQy MCA0MjAgNDIwIDQyMCA0MjAgNTU1IDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIw IDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAg NDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgDTQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAg NDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0 MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQy MCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIw IDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCANNDIw IDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAg NDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0MjAgNDIwIDQyMCA0 MjAgNDIwIDQyMCA0MjAgNDIwIF0NL0ZvbnREZXNjcmlwdG9yIDI1IDAgUg0+Pg1lbmRvYmoNMjUg MCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvQXJpYWwsQm9sZA0vRmxh Z3MgMzINL0ZvbnRCQm94IFsgLTYyOCAtMzc2IDIwMzQgMTA0OCBdDS9NaXNzaW5nV2lkdGggNzYw DS9TdGVtViA4MA0vU3RlbUggODANL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA4MjANL1hIZWln aHQgNTc0DS9Bc2NlbnQgODIwDS9EZXNjZW50IDIyMA0vTGVhZGluZyA0MA0vTWF4V2lkdGggMTAy MA0vQXZnV2lkdGggNDIwDT4+DWVuZG9iag0zIDAgb2JqDTw8DS9UeXBlIC9QYWdlcw0vQ291bnQg Ng0vS2lkcyBbOCAwIFIgMTEgMCBSIDE0IDAgUiAxNyAwIFIgMjAgMCBSIDIzIDAgUl0NL1Jlc291 cmNlcyA8PA0vUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0NL0Nv bG9yU3BhY2UgPDwgL0NTMSBbL1BhdHRlcm4gL0RldmljZUdyYXldIC9DUzIgWy9QYXR0ZXJuIC9E ZXZpY2VSR0JdID4+DS9Gb250IDw8IC9GMSAyNCAwIFIgL0Y3IDcgMCBSICA+Pg0NPj4NPj4NZW5k b2JqDTIgMCBvYmoNPDwNL1R5cGUgL0NhdGFsb2cNL1BhZ2VzIDMgMCBSDT4+DWVuZG9iag0xIDAg b2JqDTw8DS9UaXRsZSAoVEFSSUYgRElSRUNUIE1JVEFDIGF1IDA1IDAxIDIwMDIueGxzKQ0vUHJv ZHVjZXIgKFBERm1haWwgLSBSVEUgTXVsdGltZWRpYSkNL1ZlcnNpb24gKDEuNSkNL0NyZWF0aW9u RGF0ZSAoNC8xLzIwMDIgMTI6Mjg6NDApDT4+DWVuZG9iag14cmVmDTAgMjYNMDAwMDAwMDAwMCA2 NTUzNSBmIA0wMDAwMDEwMTk5IDAwMDAwIG4gDTAwMDAwMTAxNTAgMDAwMDAgbiANMDAwMDAwOTg4 NyAwMDAwMCBuIA0wMDAwMDAwMDA5IDAwMDAwIG4gDTAwMDAwMDAxNTcgMDAwMDAgbiANMDAwMDAw MjEwMyAwMDAwMCBuIA0wMDAwMDA4NTQ4IDAwMDAwIG4gDTAwMDAwMDIxMjMgMDAwMDAgbiANMDAw MDAwMjIzOCAwMDAwMCBuIA0wMDAwMDA0MDIwIDAwMDAwIG4gDTAwMDAwMDQwNDEgMDAwMDAgbiAN MDAwMDAwNDE1NyAwMDAwMCBuIA0wMDAwMDA1NzA5IDAwMDAwIG4gDTAwMDAwMDU3MzAgMDAwMDAg biANMDAwMDAwNTg0NyAwMDAwMCBuIA0wMDAwMDA2NjI3IDAwMDAwIG4gDTAwMDAwMDY2NDcgMDAw MDAgbiANMDAwMDAwNjc2NCAwMDAwMCBuIA0wMDAwMDA3NTA2IDAwMDAwIG4gDTAwMDAwMDc1MjYg MDAwMDAgbiANMDAwMDAwNzY0MyAwMDAwMCBuIA0wMDAwMDA4Mjk2IDAwMDAwIG4gDTAwMDAwMDgz MTYgMDAwMDAgbiANMDAwMDAwODQzMyAwMDAwMCBuIA0wMDAwMDA5NjMwIDAwMDAwIG4gDXRyYWls ZXINPDwNL1NpemUgMjYNL1Jvb3QgMiAwIFINL0luZm8gMSAwIFINPj4Nc3RhcnR4cmVmDTEwMzUy DSUlRU9GDQ0= --3847625033358668-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jan 9 02:23:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16O371-0002Bi-00 for ; Tue, 08 Jan 2002 21:44:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 08 Jan 2002 21:44:47 +0100 (CET) Received: (qmail 6580 invoked by uid 0); 8 Jan 2002 19:21:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 8 Jan 2002 19:21:30 -0000 Received: by moria.seul.org (Postfix) id 96A341467F1; Tue, 8 Jan 2002 14:21:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 677581467FD; Tue, 8 Jan 2002 14:21:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4F3061467F1 for ; Tue, 8 Jan 2002 14:21:27 -0500 (EST) Received: from ifrance.com (vlt4-152.n.club-internet.fr [194.158.107.152]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 8B1F1179C for ; Tue, 8 Jan 2002 20:21:23 +0100 (CET) Message-ID: <3C3B9BAA.E91BEA8E@ifrance.com> Date: Tue, 08 Jan 2002 20:23:54 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C294ABF.F45B4A3A@f-cpu.org> <3C3A5ECE.DE286092@ifrance.com> <3C3A308E.B5C6A47A@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > nicO wrote: > > I have just read the package from Whygee and i have found an horror : > > specific entities for trees. > a binary balanced tree for buffering signals, yes. > > > We don't need that. > it is indeed useful in certain circumstances. > > > Synthetiser could recognise the loop and transforme > > it using a tree. It's automatic and balanced depending of the time used > > for the signal to come. I know that synopsys write a whipe paper on it. > > But it's old ! I have verified it. > > 1) never trust a compiler/synthesiser, unles you can look at the output You could always look at the output but try to analyse design with 100 000 gates ! You're "credo" became a little bit boring ! 99,9% of the time, synthetiser handel this very well (fanin, fanout, setup&hold timing...)! This kind of coding uglify the code and make it so heavy ! This kind of "bibouilles" must be used AFTER the functionnal part are ready. > 2) if you don't like it, you are not forced to use it : > don't compile it and the default architecture will be fine. I'm afraid of code bloat. > 3) Synopsys is not the only compiler on earth. We try to be as open > as possible to other EDA toolchains which may not contain smart > optimisations. If we design code only for Synopsys then it could be > useless with other tools. On top of that, it is not even monetarily > free... which explains why few people have ever accessed it. No there is the one from Synplifigy but i beleive that is frontend are much better than those from Synopsys. Fanout problem are very basic problem ! > 4) if the compiler is smart enough to understand what the fanout > tree does, then it is able to do a better work. Otherwise, we have > a minimal failsafe. I am thinking of the "extreme case" if we have > to use Alliance as a last resort... Yep, but it slow down compile time and synthetise time. You can't negligeagle this (20 min test are really annoying when we try to debug things!). > 5) Evaluating the fanout's "cost" is necessary, otherwise our > "time budget" will not hold. When writing in RTL/HDL, > one does not necessarily "see" that an operation requires a large > fanout and this counts in the design budget. A "hidden" fanout > tree can slow the clock frequency down if it is not identified. > At least we can hint the synthesiser to balance the fanout before > or after a pipeline stage bareer. > It so basic things! It's the base of the base of the work of compiler ! You couldn't imagine how it sound "amateurs" to read that ! At least, write that Alliance couldn't do it properly ! > I know that "advanced" tools can do they work nicely but > we have almost no chance to use one. If i can skip the "pseudo-VHDL" > part of Alliance, a lot of thing will remain to do manually, such > as place/route through C files... It's probably the ugliest thing > ever, but Alliance has (only) 2 good sides : it works and it's free. > The rest is horrible but at least i can use Alliance. > Does anyone know another solution ? > I prefer that. But start to code compact and clear and then ported thing for Alliance ! Not the opposite. nicO > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Tue Jan 8 21:48:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCE-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:14 +0100 (CET) Received: (qmail 32675 invoked by uid 0); 8 Jan 2002 20:48:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Jan 2002 20:48:05 -0000 Received: by moria.seul.org (Postfix) id F31321467EC; Tue, 8 Jan 2002 15:48:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E882B146821; Tue, 8 Jan 2002 15:48:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 10F5D1467EC for ; Tue, 8 Jan 2002 15:48:04 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id WAA06742 for ; Tue, 8 Jan 2002 22:48:03 +0200 Date: Tue, 8 Jan 2002 22:48:03 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3A308E.B5C6A47A@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I have just read the package from Whygee and i have found an horror : > > specific entities for trees. > a binary balanced tree for buffering signals, yes. You should never do buffering at RTL stage. Let synthesizer do it, and if really necessary do it manually for the few places that need it during synthesis. Manual tree building consumes quite much simulation resources and slows down synthesis. I think DC can rip out the buffers and rebuild the tree fortunately, but it needs more time for that. > 1) never trust a compiler/synthesiser, unles you can look at the output Usually synthesizers do much better job at tree building than the designer (and usually in many other places also). In physical synthesis the syntheziser even places the buffers and balances the delay in whole tree. I doubt you plan to manually place all the buffers to balance the trees. Some branches might need more than one buffer to create extra delay to keep skew low etc. In the beginning of 90s the synthesizers were so buggy that you needed always manual checking, but nowadays they are very good. > 3) Synopsys is not the only compiler on earth. We try to be as open > as possible to other EDA toolchains which may not contain smart > optimisations. If we design code only for Synopsys then it could be > useless with other tools. On top of that, it is not even monetarily > free... which explains why few people have ever accessed it. Synopsys is almost the only Synthesizer for ASIC. There is Synplify ASIC, but it can do even higher level optimization than Synopsys DC. > 4) if the compiler is smart enough to understand what the fanout > tree does, then it is able to do a better work. Otherwise, we have > a minimal failsafe. I am thinking of the "extreme case" if we have > to use Alliance as a last resort... Problem is that this makes synthesis times longer in many cases. > 5) Evaluating the fanout's "cost" is necessary, otherwise our > "time budget" will not hold. When writing in RTL/HDL, > one does not necessarily "see" that an operation requires a large > fanout and this counts in the design budget. A "hidden" fanout I think during HDL coding the coder should check the synthesis results and identify places with huge fanout. But not balance the signal trees. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jan 8 21:46:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCG-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:16 +0100 (CET) Received: (qmail 790 invoked by uid 0); 8 Jan 2002 21:11:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 8 Jan 2002 21:11:03 -0000 Received: by moria.seul.org (Postfix) id 7DED3146803; Tue, 8 Jan 2002 16:11:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A45C14681C; Tue, 8 Jan 2002 16:11:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 18AD8146803 for ; Tue, 8 Jan 2002 16:11:01 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-193.jetnet.ab.ca [207.34.60.193]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA17359 for ; Tue, 8 Jan 2002 14:10:59 -0700 (MST) Message-ID: <3C3B5AA6.6060EC5C@jetnet.ab.ca> Date: Tue, 08 Jan 2002 13:46:31 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > > I think during HDL coding the coder should check the synthesis results and > identify places with huge fanout. But not balance the signal trees. Like the computers of star trek I think we need more 'manual overides' with the software. Much of the design is now so invisible, that a digital systems engineer can not see the true logic design and make 'architectural' judgments on how to design a system. --- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jan 8 22:23:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCH-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:17 +0100 (CET) Received: (qmail 31742 invoked by uid 0); 8 Jan 2002 21:23:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 8 Jan 2002 21:23:20 -0000 Received: by moria.seul.org (Postfix) id 5F6021467F0; Tue, 8 Jan 2002 16:23:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3DCE3146804; Tue, 8 Jan 2002 16:23:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 9D5681467F0 for ; Tue, 8 Jan 2002 16:23:16 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16O3iF-0002t9-00 for f-cpu@seul.org; Tue, 8 Jan 2002 22:23:15 +0100 Date: Tue, 8 Jan 2002 22:23:15 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3B9BAA.E91BEA8E@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, me think the thought behind this is a completely good one. I don't quite understand the uproar - in software programming it's in wide use to use define switches for certain compilers, operating systems and hardware and nobody would throw away a part of the code just because some compiler could build/handle it better by its own. How about a simple switch that enables/disables that balancing? JG On Tue, 8 Jan 2002, nicO wrote: > Yann Guidon a =E9crit : > >=20 > > hello, > >=20 > > nicO wrote: > > > I have just read the package from Whygee and i have found an horror : > > > specific entities for trees. > > a binary balanced tree for buffering signals, yes. > >=20 > > > We don't need that. > > it is indeed useful in certain circumstances. > >=20 > > > Synthetiser could recognise the loop and transforme > > > it using a tree. It's automatic and balanced depending of the time us= ed > > > for the signal to come. I know that synopsys write a whipe paper on i= t. > > > But it's old ! I have verified it. > >=20 > > 1) never trust a compiler/synthesiser, unles you can look at the output >=20 > You could always look at the output but try to analyse design with 100 > 000 gates ! You're "credo" became a little bit boring ! 99,9% of the > time, synthetiser handel this very well (fanin, fanout, setup&hold > timing...)! >=20 > This kind of coding uglify the code and make it so heavy ! This kind of > "bibouilles" must be used AFTER the functionnal part are ready. >=20 > > 2) if you don't like it, you are not forced to use it : > > don't compile it and the default architecture will be fine. >=20 > I'm afraid of code bloat. >=20 > > 3) Synopsys is not the only compiler on earth. We try to be as open > > as possible to other EDA toolchains which may not contain smart > > optimisations. If we design code only for Synopsys then it could be > > useless with other tools. On top of that, it is not even monetarily > > free... which explains why few people have ever accessed it. >=20 > No there is the one from Synplifigy but i beleive that is frontend are > much better than those from Synopsys. Fanout problem are very basic > problem ! >=20 > > 4) if the compiler is smart enough to understand what the fanout > > tree does, then it is able to do a better work. Otherwise, we have > > a minimal failsafe. I am thinking of the "extreme case" if we have > > to use Alliance as a last resort... >=20 > Yep, but it slow down compile time and synthetise time. You can't > negligeagle this (20 min test are really annoying when we try to debug > things!). >=20 > > 5) Evaluating the fanout's "cost" is necessary, otherwise our > > "time budget" will not hold. When writing in RTL/HDL, > > one does not necessarily "see" that an operation requires a large > > fanout and this counts in the design budget. A "hidden" fanout > > tree can slow the clock frequency down if it is not identified. > > At least we can hint the synthesiser to balance the fanout before > > or after a pipeline stage bareer. > > >=20 > It so basic things! It's the base of the base of the work of compiler ! > You couldn't imagine how it sound "amateurs" to read that ! At least, > write that Alliance couldn't do it properly ! > =20 > > I know that "advanced" tools can do they work nicely but > > we have almost no chance to use one. If i can skip the "pseudo-VHDL" > > part of Alliance, a lot of thing will remain to do manually, such > > as place/route through C files... It's probably the ugliest thing > > ever, but Alliance has (only) 2 good sides : it works and it's free. > > The rest is horrible but at least i can use Alliance. > > Does anyone know another solution ? > > >=20 > I prefer that. But start to code compact and clear and then ported thing > for Alliance ! Not the opposite. > nicO >=20 > > > nicO > > WHYGEE ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 8 19:43:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCI-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:18 +0100 (CET) Received: (qmail 17076 invoked by uid 0); 8 Jan 2002 23:02:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 8 Jan 2002 23:02:52 -0000 Received: by moria.seul.org (Postfix) id 5C0E81467FE; Tue, 8 Jan 2002 18:02:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 477C214680D; Tue, 8 Jan 2002 18:02:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 8103C1467FE for ; Tue, 8 Jan 2002 18:02:45 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00507; Tue, 8 Jan 2002 19:43:09 +0100 Message-ID: <20020108194309.38495@thrai.stud.uni-hannover.de> Date: Tue, 8 Jan 2002 19:43:09 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Re: =?iso-8859-1?Q?=5Bf-cpu=5D_90_mod=E8les_de_portables_MITAC=2C_=E0_vous_d?= =?iso-8859-1?Q?e_choisir_!?= References: <3c3b0f623c3e0355@mel-rta8.wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3c3b0f623c3e0355@mel-rta8.wanadoo.fr>; from Ste Partners-store on Tue, Jan 08, 2002 at 04:26:01PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N *sigh* they have found us (again). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 9 01:04:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCI-0000PJ-01 for ; Wed, 09 Jan 2002 14:55:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:18 +0100 (CET) Received: (qmail 8681 invoked by uid 0); 9 Jan 2002 00:04:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 9 Jan 2002 00:04:39 -0000 Received: by moria.seul.org (Postfix) id 7C3D61467F0; Tue, 8 Jan 2002 19:04:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F3A314680D; Tue, 8 Jan 2002 19:04:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 7A1FE1467F0 for ; Tue, 8 Jan 2002 19:04:33 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01444; Wed, 9 Jan 2002 01:04:32 +0100 Message-ID: <20020109010431.23650@thrai.stud.uni-hannover.de> Date: Wed, 9 Jan 2002 01:04:31 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C3B9BAA.E91BEA8E@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Jan 08, 2002 at 10:23:15PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jan 08, 2002 at 10:23:15PM +0100, Juergen Goeritz wrote: > I don't quite understand the uproar - in software programming > it's in wide use to use define switches for certain compilers, > operating systems and hardware and nobody would throw away a > part of the code just because some compiler could build/handle > it better by its own. > > How about a simple switch that enables/disables that balancing? It's not good to have too many switches. It makes the code less and less readable -- especially VHDL code (the language doesn't support conditional compilation well). But even in C, one should not use too many #defines. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 9 02:26:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCJ-0000PJ-01 for ; Wed, 09 Jan 2002 14:55:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:19 +0100 (CET) Received: (qmail 18140 invoked by uid 0); 9 Jan 2002 01:22:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 9 Jan 2002 01:22:47 -0000 Received: by moria.seul.org (Postfix) id 9860E1467EC; Tue, 8 Jan 2002 20:22:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 919C91467FE; Tue, 8 Jan 2002 20:22:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 215691467EC for ; Tue, 8 Jan 2002 20:22:42 -0500 (EST) Received: from f-cpu.org (kdl16-16.n.club-internet.fr [213.44.18.16]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 8837116DB for ; Wed, 9 Jan 2002 02:22:39 +0100 (CET) Message-ID: <3C3B9C37.BBA07106@f-cpu.org> Date: Wed, 09 Jan 2002 02:26:15 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Juergen Goeritz wrote: > Hi, > > me think the thought behind this is a completely good one. > > I don't quite understand the uproar - in software programming > it's in wide use to use define switches for certain compilers, > operating systems and hardware and nobody would throw away a > part of the code just because some compiler could build/handle > it better by its own. > > How about a simple switch that enables/disables that balancing? this was my point #2. Even better : when the compilation script recognizes the synthesizer, it sets an environment variable. Then, during the file selection, it's a simple (ba)sh line which can select whether to use the "manual" version or not. ok ? > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jan 9 08:57:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCS-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:28 +0100 (CET) Received: (qmail 18257 invoked by uid 0); 9 Jan 2002 08:06:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 9 Jan 2002 08:06:37 -0000 Received: by moria.seul.org (Postfix) id A4A071462FD; Wed, 9 Jan 2002 03:06:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74E2C1467F2; Wed, 9 Jan 2002 03:06:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 333F21462FD for ; Wed, 9 Jan 2002 03:06:34 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ODc7-00036x-00 for f-cpu@seul.org; Wed, 9 Jan 2002 08:57:35 +0100 Date: Wed, 9 Jan 2002 08:57:34 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <20020109010431.23650@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Michael Riepe wrote: > > How about a simple switch that enables/disables that balancing? > > It's not good to have too many switches. It makes the code less and less > readable -- especially VHDL code (the language doesn't support conditional > compilation well). But even in C, one should not use too many #defines. Then there also is another way - Source generation. You tell your tool which compiler you want to use and your sources will be generated out of some meta-sources which contain the switches. Since this peculiar balance switch is just needed in the connection level and not in the functional blocks of the design itself (correct me if I'm wrong here) it should be possible to implement this type of preprocessing, e.g. some "make balanced_trees" or "make no_trees_please". Comments? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jan 9 09:04:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCT-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:29 +0100 (CET) Received: (qmail 17764 invoked by uid 0); 9 Jan 2002 08:06:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 9 Jan 2002 08:06:39 -0000 Received: by moria.seul.org (Postfix) id 4454D1467F2; Wed, 9 Jan 2002 03:06:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 140E1146803; Wed, 9 Jan 2002 03:06:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0E54A1467F2 for ; Wed, 9 Jan 2002 03:06:36 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ODjC-0003A1-00 for f-cpu@seul.org; Wed, 9 Jan 2002 09:04:54 +0100 Date: Wed, 9 Jan 2002 09:04:54 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3B9C37.BBA07106@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Yann Guidon wrote: > > How about a simple switch that enables/disables that balancing? > > this was my point #2. > > Even better : when the compilation script recognizes the synthesizer, > it sets an environment variable. Then, during the file selection, > it's a simple (ba)sh line which can select whether to use > the "manual" version or not. ok ? Automatic recognition of the synthesizer may not be an issue since you want to stay independent of them. When you take a look at the LEON project you see that need to always produce new versions due to new synthesizers/libraries supported. Of course there are also bug fixes but once you start working with a release you have to check the main tree and include the new fixes manually. That's not what I would want here. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bougardb@imec.be Wed Jan 9 10:29:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCW-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:32 +0100 (CET) Received: (qmail 29366 invoked by uid 0); 9 Jan 2002 09:25:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Jan 2002 09:25:20 -0000 Received: by moria.seul.org (Postfix) id 102261462FD; Wed, 9 Jan 2002 04:25:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8C8E1467F2; Wed, 9 Jan 2002 04:25:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id EA4851462FD for ; Wed, 9 Jan 2002 04:25:17 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id KAA28777 for ; Wed, 9 Jan 2002 10:25:17 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 10:25:17 +0100 Message-ID: <3C3C0D5F.A7AF143F@imec.be> Date: Wed, 09 Jan 2002 10:29:03 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C3B9C37.BBA07106@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2002 09:25:17.0225 (UTC) FILETIME=[8CF05190:01C198EF] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi All, I have some remarks about this 'Tree story': You give me the feeling that you apply some kind of bottom-up methodology. Building your design from the lowest level to the highest. Professional IC designers always work top-down, from spec to gate level, through different abstraction level. It seems that you are now busy with the RTL description, RTL is your 'abstraction level'. Your concern about synthesis is a positive think, anyway, regarding my experience in this field, I can tell you that you go too far ! Fan out tree have nothing to do ar RTL level, that's for sure, that's the kind of think that should be abstracted here. Your concern about synthesis should be translated in your coding style, but not in your architecture. You have to write synthezable code, you have to 'think hardware', you should know what the synthesizer will do with your VHDL code, that's a matter of experience and if you don't have it, don't worry, experiment, that's the way to get it. Not trusting completely the tools is also a good thing, but that doesn't mean that you should do its work manually. Moreover, you can always check the results of synthesis, not manually (even if some synthesis specialists are able to do it) but by netlist simulation. You replace your top entity by the netlist in your testbench and run the simulation with the same test patterns, then check if the outputs match with your RTL simulation outputs. That validate the synthesis regarding the functionality. Regarding timing, because your fan out tree problem is a timing problem. You have in a first time your synthesis reports. Considering a 'wire load model' provided by the fab, the synthesizer analyses the fan out ... and tell you where are your timing bottleneck. If you detect something wrong, you can fix it in your RT code or, if it is too hidden, in your netlist. You can also use 'timing analyzer' that are independent >from the synthesizer. After P&R, when you have your back annotations, you can run again the annotated netlist simulations (for the functionality) and the timing analysis with the wire load model extracted from the lay out. That's it ! So, my advise, is simply to do the things in the right order. I think you want to develop some kind of 'soft IP', the first step is to have a clean synthesable VHDL code. Think hardware, yes, but keep the abstraction level to RTL (not gate level). I agree with Kim about DC, I think it is the only 'professional' synthesizer for IC and it is quite reliable. I think other more or less 'exotic' tools such Alliance focus more on FPGA and other toy devices. Synopsys is quite expensive but some universities get 'educational licenses', if there are student amongst you ... Best Regards Bruno The > hello, > > Juergen Goeritz wrote: > > Hi, > > > > me think the thought behind this is a completely good one. > > > > I don't quite understand the uproar - in software programming > > it's in wide use to use define switches for certain compilers, > > operating systems and hardware and nobody would throw away a > > part of the code just because some compiler could build/handle > > it better by its own. > > > > How about a simple switch that enables/disables that balancing? > > this was my point #2. > > Even better : when the compilation script recognizes the synthesizer, > it sets an environment variable. Then, during the file selection, > it's a simple (ba)sh line which can select whether to use > the "manual" version or not. ok ? > > > JG > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Jan 9 13:46:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCg-0000PJ-00 for ; Wed, 09 Jan 2002 14:55:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:42 +0100 (CET) Received: (qmail 6592 invoked by uid 0); 9 Jan 2002 12:46:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 9 Jan 2002 12:46:51 -0000 Received: by moria.seul.org (Postfix) id 0F5BF146805; Wed, 9 Jan 2002 07:46:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F37AB14681A; Wed, 9 Jan 2002 07:46:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id AF088146805 for ; Wed, 9 Jan 2002 07:46:49 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-2v.club-internet.fr (Postfix) with SMTP id 1D43F1A35; Wed, 9 Jan 2002 13:46:48 +0100 (CET) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] "Tree" Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2002 13:46:48 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >Juergen Goeritz >On Wed, 9 Jan 2002, Yann Guidon wrote: >> > How about a simple switch that enables/disables that balancing? >> = >> this was my point =232. >> = >> Even better : when the compilation script recognizes the synthesizer, >> it sets an environment variable. Then, during the file selection, >> it's a simple (ba)sh line which can select whether to use >> the =22manual=22 version or not. ok ? > >Automatic recognition of the synthesizer may not be an issue >since you want to stay independent of them. When you take a >look at the LEON project you see that need to always produce >new versions due to new synthesizers/libraries supported. Of >course there are also bug fixes but once you start working >with a release you have to check the main tree and include >the new fixes manually. That's not what I would want here. You have a point, but i didn't mean to be =5Fthat=5F specific. At least we can recognize =5Fonly=5F the synthesiser families which do not know tree balancing (for example). i think i'll keep the =22optional manual trees=22 away from the main compilation script but i won't deprecate it : it might be useful at any ti= me. >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jan 9 13:47:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OJCg-0000PJ-01 for ; Wed, 09 Jan 2002 14:55:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 14:55:42 +0100 (CET) Received: (qmail 18499 invoked by uid 0); 9 Jan 2002 12:47:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 9 Jan 2002 12:47:50 -0000 Received: by moria.seul.org (Postfix) id 767C9146815; Wed, 9 Jan 2002 07:47:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 669EC14681C; Wed, 9 Jan 2002 07:47:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0DF08146815 for ; Wed, 9 Jan 2002 07:47:48 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OI8x-0003Q2-00; Wed, 9 Jan 2002 13:47:47 +0100 Date: Wed, 9 Jan 2002 13:47:47 +0100 (MET) From: Juergen Goeritz To: Bruno Bougard Cc: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C0D5F.A7AF143F@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Bruno Bougard wrote: > Hi All, > > I have some remarks about this 'Tree story': > > You give me the feeling that you apply some kind of bottom-up > methodology. Building your design from the lowest level to the highest. > Professional IC designers always work top-down, from spec to gate level, > through different abstraction level. Hi Bruno, thank you very much for this explanation. Since I am from both worlds (hardware and software) I do not completely agree to your statement though. Let me take you (all) onto a short excursion: The top-down approach reflects the division of the complete problem into smaller pieces. The bottom-up process means the implementation and integration of small pieces to build a whole. Only both parts together will ever be able to produce a result. I don't know of any development, where the spec wasn't changed during the development process (or held incomplete) or the technology was adapted to reach the specified goal. I am not talking about imitation (re-implement of existing chip) here. But let's go back to top-down. You have to define the outer interface and function of your 'whole' system first, then you can start fill it with something - the division into smaller parts for which you also define the interfaces and some idea about their functionality. This is a recursive process until you end up with trivial entities. In our case - macros or gates. There a quite a few possibilities to divide the functionality. The last part of this process is handed over to the synthesizer. And as you stated above, professional IC designers know how their synthesizer works and let it do the rest (optimization) for ease of design description. They adapt their writing to the synthesizer to get the best result. I see this as symbiosis with and focusing on the synthesizer. Why is it such a problem to optimize the design? This is due to the two-dimensional structure of the problem (inputs vs. one output). There are ways to reduce such a table into an AND/OR/NOT representation in a really short time (this is PLD talking) - optimzers like FACT (single bit) or ESPRESSO (multi bit) do it very nicely. By the way I also worked with a multi bit optimizer called BRUNO in those days. Now come to ASICs and FPGAs: Since n-input AND(OR) gates are not available (or hard to implement with a good timing) on the ASIC other algorithms were developed. These algorithms try to find other patterns inside the table. XOR detection is one of these. Most very small gates do have some negated inputs or outputs. When you can use them in the design the size will be less than with the other non-inverting gates. Thus the synthesizer tries (and I mean it!) to find an optimal solution. But there is a pitty - the gate fanout (the power to drive other gates). The smallest gates only got low fanout. Higher fanout costs additional size. AND - the gate delay is fanout dependent. This multiplies another 2 dimensions into the problem. And we are still talking about a single output bit. Similar patterns may be used by multiple output bits though... Delay and size optimization is the way, but where is the optimum? And after that you still have to place those gates onto the chip and wiring does also take size and adds delays and crosstalk... When I started in 1987 I did most optimization by hand. ;-) Meanwhile these days are gone. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From guidon@messiaen.lip6.fr Wed Jan 9 15:03:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR40-0000G7-01 for ; Wed, 09 Jan 2002 23:19:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:16 +0100 (CET) Received: (qmail 30859 invoked by uid 0); 9 Jan 2002 14:03:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 9 Jan 2002 14:03:57 -0000 Received: by moria.seul.org (Postfix) id BE3AC1467F3; Wed, 9 Jan 2002 09:03:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B51ED1467FC; Wed, 9 Jan 2002 09:03:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by moria.seul.org (Postfix) with ESMTP id 2B5DC1467F3 for ; Wed, 9 Jan 2002 09:03:56 -0500 (EST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g09E3tAC013049 ; Wed, 9 Jan 2002 15:03:55 +0100 X-pt: isis.lip6.fr Received: from enseig.lip6.fr (enseig.lip6.fr [132.227.67.130]) by asim.lip6.fr (8.11.3nb1/8.11.0) with ESMTP id g09E3st18004; Wed, 9 Jan 2002 15:03:54 +0100 (MET) Received: from adam.lip6.fr (adam [132.227.67.15]) by enseig.lip6.fr (8.9.3+Sun/8.9.3) with ESMTP id PAA21111; Wed, 9 Jan 2002 15:03:54 +0100 (MET) From: "Yann Guidon [systeme]" Received: (from guidon@localhost) by adam.lip6.fr (8.11.6/8.9.3) id g09E3sV01999; Wed, 9 Jan 2002 15:03:54 +0100 Date: Wed, 9 Jan 2002 15:03:54 +0100 Message-Id: <200201091403.g09E3sV01999@adam.lip6.fr> To: f-cpu@seul.org Subject: Re: Re: [f-cpu] "Tree" Cc: whygee@f-cpu.org* Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, and thanks for your constructive comments. i agree with them but unfortunately our situation is not this of a normal company :-( >De: Bruno Bougard >Hi All, > >I have some remarks about this 'Tree story': > >You give me the feeling that you apply some kind of bottom-up >methodology. Building your design from the lowest level to the highest. >Professional IC designers always work top-down, from spec to gate level, >through different abstraction level. This all started a long while ago. On top of that, when people ask "how many gates does that count ?" we have no means to answer. Simply because we have no synthesiser. So we have to do it "manually". The availability of VHDL tools under Linux marks a new milestone in the F-CPU project, the next one will be to have a synthesiser : no more naugthy hack and endless discussions... But this is going to be even more difficult to get it. >It seems that you are now busy with the RTL description, RTL is your >'abstraction level'. Your concern about synthesis is a positive think, >anyway, regarding my experience in this field, I can tell you that you >go too far ! Fan out tree have nothing to do ar RTL level, that's for >sure, that's the kind of think that should be abstracted here. i can't help it, i'm paranoid ;-) but i slowly learn. Though my comments may seem harsh to some, my position has progressively evolved during the last 3 years. But i can't resist to make the discussion last :-) And before i make a point of view mine, i have to verify and experience and think about it... For example, it took a while before i really became concerned about wire delays. Now it is one of my design concerns. And do not worry : if a design criterium is meaningful and jsutified and coherent, it will be adopted. But there is some entropy and ineria... >Your concern about synthesis should be translated in your coding style, >but not in your architecture. You have to write synthezable code, you >have to 'think hardware', you should know what the synthesizer will do >with your VHDL code, that's a matter of experience and if you don't have >it, don't worry, experiment, that's the way to get it. How could i get experience with the necessary tool ? the only tool i have is a few VHDL compilers/simulators. We are seeking synthesis tools for a long long time and if there was a simple and easy answer, we would have known it. >Not trusting completely the tools is also a good thing, but that doesn't >mean that you should do its work manually. Moreover, you can always >check the results of synthesis, not manually (even if some synthesis >specialists are able to do it) but by netlist simulation. You replace >your top entity by the netlist in your testbench and run the simulation >with the same test patterns, then check if the outputs match with your >RTL simulation outputs. That validate the synthesis regarding the >functionality. sure. >Regarding timing, because your fan out tree problem is a timing problem. >You have in a first time your synthesis reports. Considering a 'wire >load model' provided by the fab, the synthesizer analyses the fan out >.... and tell you where are your timing bottleneck. If you detect >something wrong, you can fix it in your RT code or, if it is too hidden, >in your netlist. You can also use 'timing analyzer' that are independent >>from the synthesizer. not only the timing is dependent from the tool, we also need fab parameters. But we have none ! :-( furthermore we try to keep the design as portable as possible so design styles will not suit for everything. It's a really annoying problem ! >After P&R, when you have your back annotations, you can run again the >annotated netlist simulations (for the functionality) and the timing >analysis with the wire load model extracted from the lay out. > >That's it ! that works if you work for a "big" company (that can afford the licence costs), with a specific design/application and workflow. >So, my advise, is simply to do the things in the right order. I think >you want to develop some kind of 'soft I do the things in the right order. I think >you want to develop some kind of 'soft IP', the first step is to have a >clean synthesable VHDL code. Think hardware, yes, but keep the >abstraction level to RTL (not gate level). I believe that our coding style will stabilize and get better and cleaner once we find a suitable toolset. F-CPU is still a big sandbox and we're not even much playing in it (with closed eyes). >I agree with Kim about DC, I think it is the only 'professional' >synthesizer for IC and it is quite reliable. I think other more or less >'exotic' tools such Alliance focus more on FPGA and other toy devices. AFAIK Alliance is not about FPGA. I don't remember having seen a FPGA at ASIME, except for a reconfigurable router protocol project, but this is exceptional... In fact, the FPGA domain is too fragmented for justifying academic effort for a new tool. >Synopsys is quite expensive but some universities get 'educational >licenses', if there are student amongst you ... There are both students and professionals here but the point of F-CPU is to allow anybody (with a linux box) to participate without constraint. The synthesis problem is one of those we have to solve now. >Best Regards read you soon >Bruno YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jan 9 15:26:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR44-0000G7-01 for ; Wed, 09 Jan 2002 23:19:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:20 +0100 (CET) Received: (qmail 32530 invoked by uid 0); 9 Jan 2002 14:28:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 9 Jan 2002 14:28:43 -0000 Received: by moria.seul.org (Postfix) id 951CD1462FD; Wed, 9 Jan 2002 09:28:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74D151467F6; Wed, 9 Jan 2002 09:28:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id AD80B1462FD for ; Wed, 9 Jan 2002 09:28:41 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OJg6-0003U7-00; Wed, 9 Jan 2002 15:26:06 +0100 Date: Wed, 9 Jan 2002 15:26:05 +0100 (MET) From: Juergen Goeritz To: Bruno Bougard Cc: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C0D5F.A7AF143F@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N By the way, one could see bottom-up design as a growth process. Since the design has to stay on that 2 dimensional flat plain on the chip it is not to bad to use a growth process for development. Remember, today's chip technology is a flat technology. Any design you do that actually builds a 3 dimensional wiring can hardly be implemented. Therefore designs that fit on a piece of paper without overlapping wires will always be fine for implementation. The world is flat. Do pipelined designs. :-)) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jan 9 16:10:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR48-0000G7-00 for ; Wed, 09 Jan 2002 23:19:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:24 +0100 (CET) Received: (qmail 28897 invoked by uid 0); 9 Jan 2002 15:11:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Jan 2002 15:11:24 -0000 Received: by moria.seul.org (Postfix) id 0C8F41467F3; Wed, 9 Jan 2002 10:11:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE4D21467F6; Wed, 9 Jan 2002 10:11:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id E20941467F3 for ; Wed, 9 Jan 2002 10:11:20 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OKMx-0003b8-00; Wed, 9 Jan 2002 16:10:24 +0100 Date: Wed, 9 Jan 2002 16:10:23 +0100 (MET) From: Juergen Goeritz To: Bruno Bougard Cc: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C4B59.AB3BFC6C@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > > thank you very much for this explanation. Since I am from both > > worlds (hardware and software) I do not completely agree to your > > statement though. Let me take you (all) onto a short excursion: > > The top-down approach reflects the division of the complete > > problem into smaller pieces. The bottom-up process means the > > implementation and integration of small pieces to build a whole. > > Only both parts together will ever be able to produce a result. > > I don't know of any development, where the spec wasn't changed > > during the development process (or held incomplete) or the > > technology was adapted to reach the specified goal. I am not > > talking about imitation (re-implement of existing chip) here. > > Ok for that, it is not incompatible with what I told, in fact. I've never > told that you shouldn't iterate in the design process. This is often > necessary, but that stay top-down. But ok, don't make it too philosophical, > it depends how you see it. Why? If you look at the design of man. You got one half of the brain working in top-down (analyze) and the other half in bottom-up (integrate). There has been a lot of experiments going on to get an idea how the brain works. If you don't use both halves you be nothing and hardly achieve anything. Okay, now I somehow got philosophical ;-) > My main message is : 'keep the abstraction level well separated' and > do the things step by step. The abstraction inside a design is only needed as long as you don't overlook it as a whole. That's why you have to use top-down as long as you exceed your own possibilities i.e. imagination and use bottom-up when you can grasp it. > > But let's go back to top-down. You have to define the outer > > interface and function of your 'whole' system first, then you > > can start fill it with something - the division into smaller > > parts for which you also define the interfaces and some idea > > about their functionality. This is a recursive process until > > you end up with trivial entities. In our case - macros or gates. > > There a quite a few possibilities to divide the functionality. > > The last part of this process is handed over to the synthesizer. > > And as you stated above, professional IC designers know how > > their synthesizer works and let it do the rest (optimization) > > for ease of design description. They adapt their writing to the > > synthesizer to get the best result. I see this as symbiosis > > with and focusing on the synthesizer. > > More or less ... > > > Why is it such a problem to optimize the design? > > This is due to the two-dimensional structure of the problem > > (inputs vs. one output). There are ways to reduce such a table > > into an AND/OR/NOT representation in a really short time (this > > is PLD talking) - optimzers like FACT (single bit) or ESPRESSO > > (multi bit) do it very nicely. By the way I also worked with > > a multi bit optimizer called BRUNO in those days. > > I didn't know that I have the same name than an optimizer ;-) Maybe you can get a LOG/iC PLA package from somewhere to test it. ;-) > > Now come to ASICs and FPGAs: > > Since n-input AND(OR) gates are not available (or hard to > > implement with a good timing) on the ASIC other algorithms > > were developed. These algorithms try to find other patterns > > inside the table. XOR detection is one of these. Most very > > small gates do have some negated inputs or outputs. When you > > can use them in the design the size will be less than with > > the other non-inverting gates. > > Thus the synthesizer tries (and I mean it!) to find an optimal > > solution. But there is a pitty - the gate fanout (the power to > > drive other gates). The smallest gates only got low fanout. > > Higher fanout costs additional size. AND - the gate delay is > > fanout dependent. This multiplies another 2 dimensions into > > the problem. And we are still talking about a single output bit. > > Similar patterns may be used by multiple output bits though... > > Delay and size optimization is the way, but where is the optimum? > > And after that you still have to place those gates onto the chip > > and wiring does also take size and adds delays and crosstalk... > > Ok, that's a nice talk. I think your message is 'synthesis is a complex > problem', isn't it ? I fully agree. > Just one remark. The synthesizer doesn't try to find an 'optimal' solution > but a solution that match with the constrains you give to him. This is quite > different in the mathematical point of view. Yes you are right. But the constraints give the definition of an optimum solution ;-) I don't think that meanwhile anybody prooved that there may be an optimal solution where size and delay both are minimal. By the way that reminds me of the relation between mass and time. But this one must have got some sort of a minimum. Off-topic again ;-) > In fact, what you tell is the best justification for what I try to say: the > problem is complex, the best way to handle this complexity is to work in > abstraction layers. One after the other and with feed back when needed. Yeah. But why do you think it's impossible to write another optimizer fitted for F-CPU? The biggest problems, like automatic state assignment or the automatic computation with different flipflop types are not yet solved because of the high computation time with existing tools. And is there a tool available at all to verify design flatness? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Jan 9 18:37:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4F-0000G7-01 for ; Wed, 09 Jan 2002 23:19:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:31 +0100 (CET) Received: (qmail 14156 invoked by uid 0); 9 Jan 2002 17:35:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Jan 2002 17:35:44 -0000 Received: by moria.seul.org (Postfix) id 179521467F5; Wed, 9 Jan 2002 12:35:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D80F71467FC; Wed, 9 Jan 2002 12:35:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf07bis.bellsouth.net (mail207.mail.bellsouth.net [205.152.58.147]) by moria.seul.org (Postfix) with ESMTP id 8AA3F1467F5 for ; Wed, 9 Jan 2002 12:35:42 -0500 (EST) Received: from computer ([209.214.154.222]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20020109173654.NUQ18093.imf07bis.bellsouth.net@computer>; Wed, 9 Jan 2002 12:36:54 -0500 Message-ID: <000a01c19934$4833fbc0$de9ad6d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] ERIN32 Date: Wed, 9 Jan 2002 11:37:15 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C19901.FCBF5860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C19901.FCBF5860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see some points made on circuit loading. While at Sanders = Associates Inc several years back; it was determined that a Logic design = having a maximum fan-out of 7 loads had a good chance of surviving = temperature testing over the military temperature range of -55 to +125c. = In my design of the Erin32 I took special care to have a maximum load = of 8. In the chip design process; there is an Auto-buffer option - I = always use it. The End-item Processor is a Quicklogic Corp QL6600-7 672 pin Plastic = Ball Grid Array device of the Eclipse Family. The current useage of the = device is as follows: Utilized cells (no buffers) 3048 of 4032 Utilized cells (buffered) 3537 of 4032 Clock only Cells 1 of 9 Bi Directional cells 502 of 506 PLL cells 1 of 4X Flip-flop of IO cells 224 of 508 1st Flip-flop of Logic cells 981 of 4032 2nd Flip-flop of Logic cells 982 of 4032 Routing resources 83167 of 293995 ViaLink resources 73301 of 7957982 Global Clock Nets 9 of 9 OSC1 Clock 93 MHz This design is of the M2M variety that you people are steering clear = of. A modified Harvard Architecture is used - that is separate Program and Data memory also having an 18 bit Source = and Destination address, and ONE ACCUMULATOR REGISTER. Eight (8) = Instructions and eight (8) operands are fetched and executed in parallel = if Data Waits do not interfer. This function was also shot down by you = people - since I have used this feature some time ago (before most of = you were born); I used it again, instead of using Cache. To me it = appears that 8 instructions is a good number because one of eight is = probably of the Jump or Conditional variety anyway. This is borne out = of the analysis I did a couple years back - and the numbers are = approximately correct. The design is all Schematic Level, so I have complete visability of = every GATE. Although the Two and Four Port SSRAM's have an access time = of 4.5 NS; I round this to 5, and 5 NS setup, and 5 NS Ram to CPU I/O = pin. Multiply and Divide are included; however Square Root had to be = abanded due to an insufficient number of Logic cells. This will require = a separate optional Chip. This will fit very well in the Optional = Floating Point Processor. I will be very happy to answer any questions of the design. Regards Richard E. Hartney Research Director Erin Greene & Associates E-mail rhartney@bellsouth.net =20 ------=_NextPart_000_0007_01C19901.FCBF5860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    I see some points = made on=20 circuit loading.  While at Sanders Associates Inc several years = back; it=20 was determined that a Logic design having a maximum fan-out of 7 loads = had a=20 good chance of surviving temperature testing over the military = temperature range=20 of -55 to +125c.  In my design of the Erin32 I took special care to = have a=20 maximum load of 8.  In the chip design process; there is an = Auto-buffer=20 option - I always use it.
 
    The End-item = Processor is a=20 Quicklogic Corp QL6600-7 672 pin Plastic Ball Grid Array device of the = Eclipse=20 Family.  The current useage of the device is as = follows:
 
       =20     Utilized cells (no buffers)   =20     3048 of    4032
       =20     Utilized cells=20 (buffered)          &nb= sp;3537=20 of    4032
       =20     Clock only=20 Cells           &n= bsp;           &nb= sp;=20 1 of         9
       =20     Bi=20 Directional cells        &nb= sp;         502=20 of      506
       =20     PLL cells       =20             =    =20            1=20 of         4X
       =20     Flip-flop of IO=20 cells           &n= bsp;      224=20 of      508
       =20     1st Flip-flop of Logic cells   =20     981 of    4032
       =20     2nd Flip-flop of Logic=20 cells       982 of   =20 4032
       =20     Routing=20 resources          &nbs= p;    83167=20 of    293995
       =20     ViaLink=20 resources          &nbs= p;    73301=20 of   7957982
       =20     Global Clock Nets    =    =20     =           9=20 of         9
       =20     OSC1 Clock       =20             =     93=20 MHz
 
    This design is of = the M2M=20 variety that you people are steering clear of.  A modified Harvard=20 Architecture is used -
that is separate Program and Data = memory also=20 having an 18 bit Source and Destination address, and ONE ACCUMULATOR=20 REGISTER.  Eight (8) Instructions and eight (8) operands are = fetched and=20 executed in parallel if Data Waits do not interfer.  This function = was also=20 shot down by you people - since I have used this feature some time ago = (before=20 most of you were born); I used it again, instead of using Cache.  = To me it=20 appears that 8 instructions is a good number because one of eight is = probably of=20 the Jump or Conditional variety anyway.  This is borne out of the = analysis=20 I did a couple years back - and the numbers are approximately=20 correct.
    The design is all = Schematic=20 Level, so I have complete visability of every GATE. Although the Two and = Four=20 Port SSRAM's have an access time of 4.5 NS; I round this to 5, and = 5 NS=20 setup, and 5 NS Ram to CPU I/O pin.
    Multiply and Divide = are=20 included; however Square Root had to be abanded due to an insufficient = number of=20 Logic cells. This will require a separate optional Chip. This will fit = very well=20 in the Optional Floating Point Processor.
 
    I will be very happy = to answer=20 any questions of the design.
 
Regards
Richard E. Hartney
Research Director
Erin Greene & = Associates
E-mail  = rhartney@bellsouth.net
    =
------=_NextPart_000_0007_01C19901.FCBF5860-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jan 9 20:02:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4J-0000G7-01 for ; Wed, 09 Jan 2002 23:19:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:35 +0100 (CET) Received: (qmail 3911 invoked by uid 0); 9 Jan 2002 19:09:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 9 Jan 2002 19:09:21 -0000 Received: by moria.seul.org (Postfix) id 388121467EC; Wed, 9 Jan 2002 14:09:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 247301467FC; Wed, 9 Jan 2002 14:09:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id A99781467EC for ; Wed, 9 Jan 2002 14:09:17 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA28111 for ; Wed, 9 Jan 2002 12:09:15 -0700 (MST) Message-ID: <3C3C93CD.765926D9@jetnet.ab.ca> Date: Wed, 09 Jan 2002 12:02:37 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C3B9C37.BBA07106@f-cpu.org> <3C3C0D5F.A7AF143F@imec.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Bruno Bougard wrote: > > Hi All, > > I have some remarks about this 'Tree story': > > You give me the feeling that you apply some kind of bottom-up > methodology. Building your design from the lowest level to the highest. > Professional IC designers always work top-down, from spec to gate level, > through different abstraction level. I would expect that all levels of development Top-down , bottom-up , middle out , low level software - user code , high level software - OS code , I/O interfacing , network topology are important. I would suspect most IC designers don't have the time or freedom to fully develop the design -- if it works 99% ship it! What I think what the F-cpu needs now is the documentation revised and a software emulator written for the ISA. Until you write software you really don't know if your architecture is sound. For my own small CPU's I like developing between the ISA and the RTL levels. I developed a nice 9 bit CPU on the ISA level only to discover at the software level the design sucked and at the RTL level it used more FPGA logic cells than my other 12 bit CPU's. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Wed Jan 9 20:27:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4K-0000G7-00 for ; Wed, 09 Jan 2002 23:19:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:36 +0100 (CET) Received: (qmail 5386 invoked by uid 0); 9 Jan 2002 19:28:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 9 Jan 2002 19:28:04 -0000 Received: by moria.seul.org (Postfix) id 332681467F6; Wed, 9 Jan 2002 14:28:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F19B41467FE; Wed, 9 Jan 2002 14:28:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 5CF701467F6 for ; Wed, 9 Jan 2002 14:27:58 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id VAA17168 for ; Wed, 9 Jan 2002 21:27:57 +0200 Date: Wed, 9 Jan 2002 21:27:56 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C0D5F.A7AF143F@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Professional IC designers always work top-down, from spec to gate level, > through different abstraction level. That is also my impression. I'm currently part of a huge chip project and always the works start from specifications at top level by systems people and ASIC chief designers. After that chief designers try to partition the design to meaningful and reasonable sized blocks. Then designers can take that abstraction level and divide their own blocks to smaller blocks. Only after that should even coding start. If you start from the bottom the top level picture is very difficult to achieve especially in very complex chips. CPU is not usually very complex chip compared to some telecom chips, there top-down design is a necessity. Of course this top-down approach needs experience about what is possible and some experiments during planning. Also some blocks need to be defined at least at pipeline and clock cycle level to see if something is even possible with given start parameters. > After P&R, when you have your back annotations, you can run again the > annotated netlist simulations (for the functionality) and the timing > analysis with the wire load model extracted from the lay out. Also in todays advanced flows P&R software can automatically change some cells in critical paths to faster ones and do all kinds of trickery to achieve the timing. You don't have that visibility during synthesis. The netlist after P&R is not usually the same you gave to the vendor. > synthesizer for IC and it is quite reliable. I think other more or less > 'exotic' tools such Alliance focus more on FPGA and other toy devices. I think Yann is not talking about Xilinx Alliance. He is talking about a tool made in french university. It has some resemblance to first versions of Synopsys in the beginning of 90s. Very small subset of VHDL87 supported and very limited capabilities. > Synopsys is quite expensive but some universities get 'educational > licenses', if there are student amongst you ... As far as I know the educational licenses are very cheap. It should not be a big problem for universities. Of course problem is to teach people to use them. Synopsys DC for example is pain in * to use. Synplify ASIC is much nicer and very easy to use. But it has to make some track record first, it seems to be a very good tool. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jan 9 20:32:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4L-0000G7-00 for ; Wed, 09 Jan 2002 23:19:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:37 +0100 (CET) Received: (qmail 22520 invoked by uid 0); 9 Jan 2002 19:39:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 9 Jan 2002 19:39:27 -0000 Received: by moria.seul.org (Postfix) id C3FF0146804; Wed, 9 Jan 2002 14:39:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A44D7146805; Wed, 9 Jan 2002 14:39:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id E0DB7146804 for ; Wed, 9 Jan 2002 14:39:16 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA29275 for ; Wed, 9 Jan 2002 12:38:53 -0700 (MST) Message-ID: <3C3C9ABB.BF895012@jetnet.ab.ca> Date: Wed, 09 Jan 2002 12:32:11 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <200201091403.g09E3sV01999@adam.lip6.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "Yann Guidon [systeme]" wrote: > There are both students and professionals here but the point of F-CPU > is to allow anybody (with a linux box) to participate without constraint. > The synthesis problem is one of those we have to solve now. Ignoring the problem with graphics, why not a Windows or Unix Box. It would be nice not to be tied to just one OS if possible. Also is not the FPGA version a stepping stone to the ASIC version. Since we don't have 'free' FPGA's in architecture or software why worry if you use linux or windows for development if the F-CPU is in source and portable. Lets get a FPGA hardware design out to learn with as speed can come later. Once the FPGA version has been debugged drop the FPGA code and write new stuff for ASIC's as you have learned about the inside and outside F-CPU and then can build a a real version. BTW does the F-cpu handle threads will , as HURD really needs a well designed CPU to run right. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jan 9 20:37:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4L-0000G7-01 for ; Wed, 09 Jan 2002 23:19:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:37 +0100 (CET) Received: (qmail 3694 invoked by uid 0); 9 Jan 2002 19:44:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 9 Jan 2002 19:44:36 -0000 Received: by moria.seul.org (Postfix) id A4F031467F6; Wed, 9 Jan 2002 14:44:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8587D146805; Wed, 9 Jan 2002 14:44:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 4BEBC1467F6 for ; Wed, 9 Jan 2002 14:44:31 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA29643 for ; Wed, 9 Jan 2002 12:44:15 -0700 (MST) Message-ID: <3C3C9BEB.69FEAF89@jetnet.ab.ca> Date: Wed, 09 Jan 2002 12:37:15 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > The world is flat. Do pipelined designs. :-)) The WORLD is round! Pipelines add latency to a system and can bog down your speed when the ratio of logic gates to the the flip flop gates become equal. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jan 9 20:46:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OR4N-0000G7-00 for ; Wed, 09 Jan 2002 23:19:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 09 Jan 2002 23:19:39 +0100 (CET) Received: (qmail 20813 invoked by uid 0); 9 Jan 2002 19:53:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Jan 2002 19:53:59 -0000 Received: by moria.seul.org (Postfix) id 6871A1467F6; Wed, 9 Jan 2002 14:53:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63046146805; Wed, 9 Jan 2002 14:53:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 901C0146804 for ; Wed, 9 Jan 2002 14:53:20 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA00226 for ; Wed, 9 Jan 2002 12:53:07 -0700 (MST) Message-ID: <3C3C9E14.E4A1990A@jetnet.ab.ca> Date: Wed, 09 Jan 2002 12:46:28 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Why? If you look at the design of man. You got one half > of the brain working in top-down (analyze) and the other > half in bottom-up (integrate). There has been a lot of > experiments going on to get an idea how the brain works. > If you don't use both halves you be nothing and hardly > achieve anything. Okay, now I somehow got philosophical ;-) Lets not forget the brain is layered with primeval brains handling the 'OS' kernel and user stuff more recently evolved. The real difference (other than physical stuff) is the higher degree of redundancy and re-programing in living things. Byte magazine had a good bit on brains many years back. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 9 12:06:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEb-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:09 +0100 (CET) Received: (qmail 16116 invoked by uid 0); 9 Jan 2002 22:58:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Jan 2002 22:58:09 -0000 Received: by moria.seul.org (Postfix) id 397561467FC; Wed, 9 Jan 2002 17:58:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 18DA5146811; Wed, 9 Jan 2002 17:58:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a124.home.uni-hannover.de [130.75.232.124]) by moria.seul.org (Postfix) with ESMTP id 63E851467FC for ; Wed, 9 Jan 2002 17:58:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00546; Wed, 9 Jan 2002 12:06:32 +0100 Message-ID: <20020109120631.23549@thrai.stud.uni-hannover.de> Date: Wed, 9 Jan 2002 12:06:31 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <20020109010431.23650@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Jan 09, 2002 at 08:57:34AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jan 09, 2002 at 08:57:34AM +0100, Juergen Goeritz wrote: > On Wed, 9 Jan 2002, Michael Riepe wrote: > > > How about a simple switch that enables/disables that balancing? > > > > It's not good to have too many switches. It makes the code less and less > > readable -- especially VHDL code (the language doesn't support conditional > > compilation well). But even in C, one should not use too many #defines. > > Then there also is another way - Source generation. You tell > your tool which compiler you want to use and your sources > will be generated out of some meta-sources which contain the > switches. Since this peculiar balance switch is just needed > in the connection level and not in the functional blocks of > the design itself (correct me if I'm wrong here) it should be > possible to implement this type of preprocessing, e.g. some > "make balanced_trees" or "make no_trees_please". Comments? Source generation is even worse. It works fine in some places (e.g. the configuration stuff), but not for the whole package. And yes, you're wrong -- there are high fan-outs inside some modules. Mode lines, for example, are used a lot. The input operands in the IMU are used 64 times, too. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 09:07:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEe-0000Ft-01 for ; Thu, 10 Jan 2002 14:27:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:12 +0100 (CET) Received: (qmail 20539 invoked by uid 0); 10 Jan 2002 08:12:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 10 Jan 2002 08:12:57 -0000 Received: by moria.seul.org (Postfix) id BF294146834; Thu, 10 Jan 2002 03:12:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD2E014683B; Thu, 10 Jan 2002 03:12:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id AE02C146834 for ; Thu, 10 Jan 2002 03:12:55 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OaFH-0004A8-00 for f-cpu@seul.org; Thu, 10 Jan 2002 09:07:31 +0100 Date: Thu, 10 Jan 2002 09:07:31 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C9E14.E4A1990A@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > Why? If you look at the design of man. You got one half > > of the brain working in top-down (analyze) and the other > > half in bottom-up (integrate). There has been a lot of > > experiments going on to get an idea how the brain works. > > If you don't use both halves you be nothing and hardly > > achieve anything. Okay, now I somehow got philosophical ;-) > > Lets not forget the brain is layered with primeval brains > handling the 'OS' kernel and user stuff more recently evolved. > The real difference (other than physical stuff) is the higher > degree of redundancy and re-programing in living things. > Byte magazine had a good bit on brains many years back. But is it a real bottom-up design by evolution - or did some whatever do a top-down design? :-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 09:05:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEf-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:13 +0100 (CET) Received: (qmail 22829 invoked by uid 0); 10 Jan 2002 08:13:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 10 Jan 2002 08:13:02 -0000 Received: by moria.seul.org (Postfix) id 2924314683B; Thu, 10 Jan 2002 03:12:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E435146841; Thu, 10 Jan 2002 03:12:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 47A7C14683B for ; Thu, 10 Jan 2002 03:12:57 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OaDA-0004A3-00 for f-cpu@seul.org; Thu, 10 Jan 2002 09:05:20 +0100 Date: Thu, 10 Jan 2002 09:05:20 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C9BEB.69FEAF89@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Ben Franchuk wrote: > Juergen Goeritz wrote: > > The world is flat. Do pipelined designs. :-)) > The WORLD is round! Pipelines add latency to a system and > can bog down your speed when the ratio of logic gates to the the flip > flop gates become equal. What's your definition of a pipeline? I am seeing it always related to the data that needs the computing. Most systems I know of could use some pipeline design in hardware to not touch the data several times at the same instance which requires much more bandwidth at a single point. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bougardb@imec.be Thu Jan 10 09:26:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEh-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:15 +0100 (CET) Received: (qmail 32143 invoked by uid 0); 10 Jan 2002 08:22:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Jan 2002 08:22:52 -0000 Received: by moria.seul.org (Postfix) id 97B5A146836; Thu, 10 Jan 2002 03:22:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90152146841; Thu, 10 Jan 2002 03:22:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id E6909146836 for ; Thu, 10 Jan 2002 03:22:50 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id JAA32313 for ; Thu, 10 Jan 2002 09:22:50 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 09:22:49 +0100 Message-ID: <3C3D5041.70A3EC09@imec.be> Date: Thu, 10 Jan 2002 09:26:41 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2002 08:22:49.0978 (UTC) FILETIME=[FDD18DA0:01C199AF] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > > Professional IC designers always work top-down, from spec to gate level, > > through different abstraction level. > > That is also my impression. I'm currently part of a huge chip project and > always the works start from specifications at top level by systems people > and ASIC chief designers. After that chief designers try to partition the > design to meaningful and reasonable sized blocks. Then designers can take > that abstraction level and divide their own blocks to smaller blocks. Only > after that should even coding start. If you start from the bottom the top > level picture is very difficult to achieve especially in very complex > chips. CPU is not usually very complex chip compared to some telecom > chips, there top-down design is a necessity. It seems that we come from the same world ;-) > Of course this top-down approach needs experience about what is possible > and some experiments during planning. Also some blocks need to be defined > at least at pipeline and clock cycle level to see if something is even > possible with given start parameters. > > > After P&R, when you have your back annotations, you can run again the > > annotated netlist simulations (for the functionality) and the timing > > analysis with the wire load model extracted from the lay out. > > Also in todays advanced flows P&R software can automatically change some > cells in critical paths to faster ones and do all kinds of trickery to > achieve the timing. You don't have that visibility during synthesis. The > netlist after P&R is not usually the same you gave to the vendor. > > > synthesizer for IC and it is quite reliable. I think other more or less > > 'exotic' tools such Alliance focus more on FPGA and other toy devices. > > I think Yann is not talking about Xilinx Alliance. He is talking about a > tool made in french university. It has some resemblance to first versions > of Synopsys in the beginning of 90s. Very small subset of VHDL87 supported > and very limited capabilities. You are right, I was confused by 'Xilink Alliance'. I don't now this French university tool > > Synopsys is quite expensive but some universities get 'educational > > licenses', if there are student amongst you ... > > As far as I know the educational licenses are very cheap. It should not be > a big problem for universities. Of course problem is to teach people to > use them. Synopsys DC for example is pain in * to use. Synplify ASIC is > much nicer and very easy to use. But it has to make some track record > first, it seems to be a very good tool. I also knew synplify as fpga synthesizer. I've just discovered it as ASIC synthesizer. It looks nice. I'll try to convince my boss to go for a trial with one of our design. Bye Bruno ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 09:50:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEi-0000Ft-01 for ; Thu, 10 Jan 2002 14:27:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:16 +0100 (CET) Received: (qmail 26546 invoked by uid 0); 10 Jan 2002 08:49:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 10 Jan 2002 08:49:54 -0000 Received: by moria.seul.org (Postfix) id 5743D146834; Thu, 10 Jan 2002 03:49:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5174814683B; Thu, 10 Jan 2002 03:49:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 57C26146834 for ; Thu, 10 Jan 2002 03:49:52 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OauX-0004CP-00 for f-cpu@seul.org; Thu, 10 Jan 2002 09:50:09 +0100 Date: Thu, 10 Jan 2002 09:50:08 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Why? If you look at the design of man. You got one half > > > of the brain working in top-down (analyze) and the other > > > half in bottom-up (integrate). There has been a lot of > > > experiments going on to get an idea how the brain works. > > > If you don't use both halves you be nothing and hardly > > > achieve anything. Okay, now I somehow got philosophical ;-) > > > > Lets not forget the brain is layered with primeval brains > > handling the 'OS' kernel and user stuff more recently evolved. > > The real difference (other than physical stuff) is the higher > > degree of redundancy and re-programing in living things. > > Byte magazine had a good bit on brains many years back. > > But is it a real bottom-up design by evolution > - or did some whatever do a top-down design? :-) Hey, let's not get religious here. What I simply wanted to say is that top-down works when you know exactly what you want to achieve. Bottom-up works if you have some pieces and want to build a new whole. I hope we can stop this discussion about best ways to do something now. F-CPU is on it's way... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 11:23:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEq-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:24 +0100 (CET) Received: (qmail 27857 invoked by uid 0); 10 Jan 2002 10:22:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 10 Jan 2002 10:22:30 -0000 Received: by moria.seul.org (Postfix) id 75DAA146834; Thu, 10 Jan 2002 05:22:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54D6C14683B; Thu, 10 Jan 2002 05:22:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 21C1C146834 for ; Thu, 10 Jan 2002 05:22:28 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OcMm-0004Ev-00 for f-cpu@seul.org; Thu, 10 Jan 2002 11:23:24 +0100 Date: Thu, 10 Jan 2002 11:23:24 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3C93CD.765926D9@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Jan 2002, Ben Franchuk wrote: > What I think what the F-cpu needs now is the documentation revised > and a software emulator written for the ISA. Until you write software > you really don't know if your architecture is sound. For my own small > CPU's I like developing between the ISA and the RTL levels. I developed > a nice 9 bit CPU on the ISA level only to discover at the software level > the design sucked and at the RTL level it used more FPGA logic cells > than my other 12 bit CPU's. > -- > Ben Franchuk - Dawn * 12/24 bit cpu * Hi Ben, since two years my brain is thinking back and forth how one can integrate the design process of software together with the design of the hardware to begin to build 'real' systems. SystemC does not really bring a solution to the problem because one is still on a hardware type programming style. And hardware type programming in software sucks. There seems to be a need for a more high sophisticated description language that is a superset of hardware and software implementation but without forcing the style to either of them. I would call this a 'system definition language'. This language must also contain some means to simulate the system on its highest level. If you look at hardware development, there is e.g. VHDL high level description and the netlist/gate level. I am looking for that level above VHDL that can be generated into hardware (e.g. VHDL) and software (e.g. C, C++). Only with that independent level you are really free to move the border between hardware and software during the development process to achieve a maximum performance of the system in design. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 10 11:52:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEr-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:25 +0100 (CET) Received: (qmail 30732 invoked by uid 0); 10 Jan 2002 10:49:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 10 Jan 2002 10:49:00 -0000 Received: by moria.seul.org (Postfix) id CD9D0146834; Thu, 10 Jan 2002 05:48:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B641514683B; Thu, 10 Jan 2002 05:48:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 644CF146834 for ; Thu, 10 Jan 2002 05:48:58 -0500 (EST) Received: from f-cpu.org (kdl16-15.n.club-internet.fr [213.44.18.15]) by relay-2v.club-internet.fr (Postfix) with ESMTP id DDE7C19D6 for ; Thu, 10 Jan 2002 11:48:53 +0100 (CET) Message-ID: <3C3D7274.8DD9B689@f-cpu.org> Date: Thu, 10 Jan 2002 11:52:36 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Juergen Goeritz wrote: > > > > Why? If you look at the design of man. You got one half > > > > of the brain working in top-down (analyze) and the other > > > > half in bottom-up (integrate). There has been a lot of > > > > experiments going on to get an idea how the brain works. > > > > If you don't use both halves you be nothing and hardly > > > > achieve anything. Okay, now I somehow got philosophical ;-) > > > > > > Lets not forget the brain is layered with primeval brains > > > handling the 'OS' kernel and user stuff more recently evolved. > > > The real difference (other than physical stuff) is the higher > > > degree of redundancy and re-programing in living things. > > > Byte magazine had a good bit on brains many years back. > > > > But is it a real bottom-up design by evolution > > - or did some whatever do a top-down design? :-) > > Hey, let's not get religious here. What I simply wanted > to say is that top-down works when you know exactly what > you want to achieve. Bottom-up works if you have some > pieces and want to build a new whole. > > I hope we can stop this discussion about best ways to do > something now. F-CPU is on it's way... i don't think it's time to stop now : this discussion has brought some interesting points and there may be some others to bring. I also believe that we are responsible enough to avoid "really off-topic" subjects, even though the evolutionary side of the F-CPU project is a meaningful element because there are not only technical constraint : there are social and economical aspects in our group. It's not much "top-down" but my "development method" is : while (1) { analyse what we have; analyse what we need; work on what we need most and can obtain; } This is going to last a long time because we are not a company with paid engineers, fixed budget and professional tools. Everybody here is free. For example, nicO wants to make his own scheduler : fine. If i fail to make mine, F-CPU will have another one. As long as we know where we're going, this is ok. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 10 12:04:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEt-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:27 +0100 (CET) Received: (qmail 11202 invoked by uid 0); 10 Jan 2002 11:01:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 10 Jan 2002 11:01:04 -0000 Received: by moria.seul.org (Postfix) id 4CB28146834; Thu, 10 Jan 2002 06:01:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4528E14683B; Thu, 10 Jan 2002 06:01:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 87C28146834 for ; Thu, 10 Jan 2002 06:01:02 -0500 (EST) Received: from f-cpu.org (kdl21-101.n.club-internet.fr [213.44.96.101]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 923A61683 for ; Thu, 10 Jan 2002 12:00:59 +0100 (CET) Message-ID: <3C3D7549.E778ABBF@f-cpu.org> Date: Thu, 10 Jan 2002 12:04:41 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > > On Wed, 9 Jan 2002, Ben Franchuk wrote: > > What I think what the F-cpu needs now is the documentation revised > > and a software emulator written for the ISA. Until you write software > > you really don't know if your architecture is sound. For my own small > > CPU's I like developing between the ISA and the RTL levels. I developed > > a nice 9 bit CPU on the ISA level only to discover at the software level > > the design sucked and at the RTL level it used more FPGA logic cells > > than my other 12 bit CPU's. > > -- > > Ben Franchuk - Dawn * 12/24 bit cpu * > > Hi Ben, > > since two years my brain is thinking back and forth how one > can integrate the design process of software together with > the design of the hardware to begin to build 'real' systems. > > SystemC does not really bring a solution to the problem > because one is still on a hardware type programming style. > And hardware type programming in software sucks. I agree on this last sentence ! This is one reason why i don't program a F-CPU simulator and prefer to do it with the "real stuff", in VHDL. > There seems to be a need for a more high sophisticated > description language that is a superset of hardware and > software implementation but without forcing the style to > either of them. I would call this a 'system definition > language'. This language must also contain some means > to simulate the system on its highest level. > > If you look at hardware development, there is e.g. VHDL > high level description and the netlist/gate level. I am > looking for that level above VHDL that can be generated > into hardware (e.g. VHDL) and software (e.g. C, C++). > > Only with that independent level you are really free to > move the border between hardware and software during the > development process to achieve a maximum performance of > the system in design. The highest level i know is an algorithm. This is what defines the rest. But there's a trap here ! I don't know a way to define an algorithm without defining an implementation at the same time. I guess it's a burden that is inherited from the "langages". My solution is to not use langages and moving the HW/SW border becomes easier. Don't underestimate the power of your brain :-) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 12:36:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEv-0000Ft-01 for ; Thu, 10 Jan 2002 14:27:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:29 +0100 (CET) Received: (qmail 6245 invoked by uid 0); 10 Jan 2002 11:36:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 10 Jan 2002 11:36:45 -0000 Received: by moria.seul.org (Postfix) id 6086C146836; Thu, 10 Jan 2002 06:36:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BD6A146840; Thu, 10 Jan 2002 06:36:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0047C146836 for ; Thu, 10 Jan 2002 06:36:42 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OdVV-0004KV-00 for f-cpu@seul.org; Thu, 10 Jan 2002 12:36:29 +0100 Date: Thu, 10 Jan 2002 12:36:29 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3D7549.E778ABBF@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, Yann Guidon wrote: > > since two years my brain is thinking back and forth how one > > can integrate the design process of software together with > > the design of the hardware to begin to build 'real' systems. > > > > There seems to be a need for a more high sophisticated > > description language that is a superset of hardware and > > software implementation but without forcing the style to > > either of them. I would call this a 'system definition > > language'. This language must also contain some means > > to simulate the system on its highest level. > > > > If you look at hardware development, there is e.g. VHDL > > high level description and the netlist/gate level. I am > > looking for that level above VHDL that can be generated > > into hardware (e.g. VHDL) and software (e.g. C, C++). > > > > Only with that independent level you are really free to > > move the border between hardware and software during the > > development process to achieve a maximum performance of > > the system in design. > > The highest level i know is an algorithm. This is what > defines the rest. But there's a trap here ! I don't know > a way to define an algorithm without defining an > implementation at the same time. I guess it's a burden > that is inherited from the "langages". My solution is > to not use langages and moving the HW/SW border becomes > easier. Don't underestimate the power of your brain :-) I think you are not too far apart. And my idea is to rely on the dataflow of the sytem, not the algorithm itself. Why? Because to me it seems that a numerical algorithm is a means to describe a dataflow together with the data modification (what I would call the functional part). And most interesting are those algorithms that change their way of behaving depending on history, data input or output. Thus I want to separate a system into its dataflow part and its functional parts (data modification and data storage). The dataflow part usually defines the maximum performance of the system. The functional part adds/subtracts value to/from the data. The storage part knows about the history. And when you look into those devices/macros/whatever on the market you will find that they all rely on dataflow. It is the basic principle beyond everything else (beside energy to work - and maybe energy needs to be taken into account too). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 10 13:42:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEx-0000Ft-01 for ; Thu, 10 Jan 2002 14:27:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:31 +0100 (CET) Received: (qmail 15003 invoked by uid 0); 10 Jan 2002 12:38:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 10 Jan 2002 12:38:57 -0000 Received: by moria.seul.org (Postfix) id 9040A146808; Thu, 10 Jan 2002 07:38:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 866F114683B; Thu, 10 Jan 2002 07:38:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 285A9146808 for ; Thu, 10 Jan 2002 07:38:56 -0500 (EST) Received: from f-cpu.org (kdl16-153.n.club-internet.fr [213.44.18.153]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 875C716B7 for ; Thu, 10 Jan 2002 13:38:53 +0100 (CET) Message-ID: <3C3D8C3B.792EB80D@f-cpu.org> Date: Thu, 10 Jan 2002 13:42:35 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <3C3C9BEB.69FEAF89@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk wrote: > Juergen Goeritz wrote: > > The world is flat. Do pipelined designs. :-)) > The WORLD is round! Pipelines add latency to a system and > can bog down your speed when the ratio of logic gates to the the flip > flop gates become equal. FC0 is tuned to work at that point. > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 10 13:42:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16OfEy-0000Ft-00 for ; Thu, 10 Jan 2002 14:27:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 10 Jan 2002 14:27:32 +0100 (CET) Received: (qmail 9066 invoked by uid 0); 10 Jan 2002 12:39:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 10 Jan 2002 12:39:03 -0000 Received: by moria.seul.org (Postfix) id 51AB6146842; Thu, 10 Jan 2002 07:39:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F496146841; Thu, 10 Jan 2002 07:39:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1C22E14683B for ; Thu, 10 Jan 2002 07:39:03 -0500 (EST) Received: from f-cpu.org (kdl16-153.n.club-internet.fr [213.44.18.153]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 75AEC1699 for ; Thu, 10 Jan 2002 13:38:59 +0100 (CET) Message-ID: <3C3D8C3D.894CBD9@f-cpu.org> Date: Thu, 10 Jan 2002 13:42:37 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <200201091403.g09E3sV01999@adam.lip6.fr> <3C3C9ABB.BF895012@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > "Yann Guidon [systeme]" wrote: > > There are both students and professionals here but the point of F-CPU > > is to allow anybody (with a linux box) to participate without constraint. > > The synthesis problem is one of those we have to solve now. > > Ignoring the problem with graphics, why not a Windows or Unix Box. It > would be nice not to be tied to just one OS if possible. that is one other problem, too. For example, i started to use Simili when only the Win32 version was available. Fortunately the sources are portable across other platforms, but compilation scripts are not. > Also is not the FPGA version a stepping stone to the ASIC version. it's useful, but i don't know if we can base everything on that. i have never practiced FPGA so i can't speak. > Since we don't have 'free' FPGA's in architecture or software why > worry if you use linux or windows for development if the F-CPU is > in source and portable. true but compilation scripts are maybe a problem, particularly when using a proprietary "integrated development suite" with specific file formats and requirements. I have this kind of problem with ncsim, which introduces several classes of files for different purposes (note that ncsim is ideally not OS-dependent). We don't have this problem with Vanilla and Simili. > Lets get a FPGA hardware design out to learn with as speed > can come later. Once the FPGA version has been debugged drop > the FPGA code and write new stuff for ASIC's as you have learned > about the inside and outside F-CPU and then can build a a real > version. As you noted before, the project must not be bound to an OS or even a SW. but why bind us to a FPGA vendor, its tools and HW ? it is also difficult to allow people to contribute if they can't access the target HW and we can't force them to buy it. > BTW does the F-cpu handle threads will , as HURD really > needs a well designed CPU to run right. i'm not a HURD expert and the OS-side is not definitively defined. However, i think that if SRB is implemented, it should be ok, as for ANY OS. > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bougardb@imec.be Thu Jan 10 15:53:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1aS-0000GB-01 for ; Fri, 11 Jan 2002 14:19:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:12 +0100 (CET) Received: (qmail 5996 invoked by uid 0); 10 Jan 2002 14:49:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 10 Jan 2002 14:49:58 -0000 Received: by moria.seul.org (Postfix) id E30A5146840; Thu, 10 Jan 2002 09:49:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8865146842; Thu, 10 Jan 2002 09:49:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id 43554146840 for ; Thu, 10 Jan 2002 09:49:56 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id PAA19637 for ; Thu, 10 Jan 2002 15:49:55 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 15:49:55 +0100 Message-ID: <3C3DAAFC.4BF040DD@imec.be> Date: Thu, 10 Jan 2002 15:53:49 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: multipart/alternative; boundary="------------B8CE97455629D5F0A3177526" X-OriginalArrivalTime: 10 Jan 2002 14:49:55.0408 (UTC) FILETIME=[1140ED00:01C199E6] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------B8CE97455629D5F0A3177526 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Goeritz wrote: > On Wed, 9 Jan 2002, Ben Franchuk wrote: > > What I think what the F-cpu needs now is the documentation revised > > and a software emulator written for the ISA. Until you write software > > you really don't know if your architecture is sound. For my own small > > CPU's I like developing between the ISA and the RTL levels. I developed > > a nice 9 bit CPU on the ISA level only to discover at the software level > > the design sucked and at the RTL level it used more FPGA logic cells > > than my other 12 bit CPU's. > > -- > > Ben Franchuk - Dawn * 12/24 bit cpu * > > Hi Ben, > > since two years my brain is thinking back and forth how one > can integrate the design process of software together with > the design of the hardware to begin to build 'real' systems. You should look at target compiler technologies ... http://www.retarget.com/ > SystemC does not really bring a solution to the problem > because one is still on a hardware type programming style. > And hardware type programming in software sucks. > > There seems to be a need for a more high sophisticated > description language that is a superset of hardware and > software implementation but without forcing the style to > either of them. I would call this a 'system definition > language'. This language must also contain some means > to simulate the system on its highest level. > > If you look at hardware development, there is e.g. VHDL > high level description and the netlist/gate level. I am > looking for that level above VHDL that can be generated > into hardware (e.g. VHDL) and software (e.g. C, C++). > > Only with that independent level you are really free to > move the border between hardware and software during the > development process to achieve a maximum performance of > the system in design. > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- ____________________________________________________ Bruno Bougard IMEC vzw Associate Researcher Kapeldreef 75 DESICS/WISE division B-3001 Leuven Belgium E-Mail : Bruno.Bougard@imec.be Phone : (+32)(0)16 28 8350 Fax : (+32)(0)16 28 1515 ____________________________________________________ --------------B8CE97455629D5F0A3177526 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Goeritz wrote:
On Wed, 9 Jan 2002, Ben Franchuk wrote:
> What I  think what the F-cpu needs now is the documentation revised
> and a software emulator written for the ISA. Until you write software
> you really don't know if your architecture is sound. For my own small
> CPU's I like developing between the ISA and the RTL levels. I developed
> a nice 9 bit CPU on the ISA level only to discover at the software level
> the design sucked and at the RTL level it used more FPGA logic cells
> than my other 12 bit CPU's.
> --
> Ben Franchuk - Dawn * 12/24 bit cpu *

Hi Ben,

since two years my brain is thinking back and forth how one
can integrate the design process of software together with
the design of the hardware to begin to build 'real' systems.

You should look at target compiler technologies ...

http://www.retarget.com/
 

SystemC does not really bring a solution to the problem
because one is still on a hardware type programming style.
And hardware type programming in software sucks.

There seems to be a need for a more high sophisticated
description language that is a superset of hardware and
software implementation but without forcing the style to
either of them. I would call this a 'system definition
language'. This language must also contain some means
to simulate the system on its highest level.

If you look at hardware development, there is e.g. VHDL
high level description and the netlist/gate level. I am
looking for that level above VHDL that can be generated
into hardware (e.g. VHDL) and software (e.g. C, C++).

Only with that independent level you are really free to
move the border between hardware and software during the
development process to achieve a maximum performance of
the system in design.

JG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

-- 
____________________________________________________

  Bruno Bougard                      IMEC vzw
  Associate Researcher               Kapeldreef 75
  DESICS/WISE division               B-3001 Leuven
                                     Belgium
  E-Mail : Bruno.Bougard@imec.be
  Phone  : (+32)(0)16 28 8350
  Fax    : (+32)(0)16 28 1515
____________________________________________________
  --------------B8CE97455629D5F0A3177526-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jan 10 17:30:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1aV-0000GB-00 for ; Fri, 11 Jan 2002 14:19:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:15 +0100 (CET) Received: (qmail 6635 invoked by uid 0); 10 Jan 2002 16:30:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 10 Jan 2002 16:30:55 -0000 Received: by moria.seul.org (Postfix) id BD0B1146809; Thu, 10 Jan 2002 11:30:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BD30146840; Thu, 10 Jan 2002 11:30:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id EB987146809 for ; Thu, 10 Jan 2002 11:30:53 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Thu, 10 Jan 2002 16:30:43 GMT Send-By: 140.94.82.17 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Tr:Rep:Re: [f-cpu] "Tree" From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jan 2002 16:30:43 GMT Message-id: <200201101630.2b88@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N A answer error... -----Message d'origine----- De: A: Date: 10/01/02 Objet: Rep:Re: [f-cpu] "Tree" -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 10/01/02 Objet: Re: [f-cpu] "Tree" <...> Hi Ben, since two years my brain is thinking back and forth how one can integrate the design process of software together with the design of the hardware to begin to build 'real' systems. SystemC does not really bring a solution to the problem because one is still on a hardware type programming style. And hardware type programming in software sucks. >>>>> You speak about SystemC 1.0 not 2.0. 1.0 is a crapy C-style VHDL : to much heavy ! SystemC 2.0 is quite nice and intriduice concept as channel, interface, port and events. This stuff are really usefull for specification for Hardware as for software. You could create your simulator then refine it until to understand what is better to put in hardware or software (for example : how much automative must be the SRB). There seems to be a need for a more high sophisticated description language that is a superset of hardware and software implementation but without forcing the style to either of them. I would call this a 'system definition language'. This language must also contain some means to simulate the system on its highest level. >>>>SystemC 2.0 ? i will prefer UML-RT but it's only a static representation. It will not be executed until a few month but there is some formal proof on it.=20 If you look at hardware development, there is e.g. VHDL high level description and the netlist/gate level. I am looking for that level above VHDL that can be generated into hardware (e.g. VHDL) and software (e.g. C, C++). Only with that independent level you are really free to move the border between hardware and software during the development process to achieve a maximum performance of the system in design. >>>> I'm ok with that but i don't understand you're point of view with SystemC. nicO JG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 _____________________________________________________ _________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jan 10 18:06:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1aX-0000GB-00 for ; Fri, 11 Jan 2002 14:19:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:17 +0100 (CET) Received: (qmail 25439 invoked by uid 0); 10 Jan 2002 17:35:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 10 Jan 2002 17:35:46 -0000 Received: by moria.seul.org (Postfix) id 946FE14680E; Thu, 10 Jan 2002 12:35:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 790E0146840; Thu, 10 Jan 2002 12:35:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id A75C514680E for ; Thu, 10 Jan 2002 12:35:44 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA09639 for ; Thu, 10 Jan 2002 10:35:43 -0700 (MST) Message-ID: <3C3DCA15.FECE99D7@jetnet.ab.ca> Date: Thu, 10 Jan 2002 10:06:29 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Wed, 9 Jan 2002, Ben Franchuk wrote: > > Juergen Goeritz wrote: > > > > > Why? If you look at the design of man. You got one half > > > of the brain working in top-down (analyze) and the other > > > half in bottom-up (integrate). There has been a lot of > > > experiments going on to get an idea how the brain works. > > > If you don't use both halves you be nothing and hardly > > > achieve anything. Okay, now I somehow got philosophical ;-) > > > > Lets not forget the brain is layered with primeval brains > > handling the 'OS' kernel and user stuff more recently evolved. > > The real difference (other than physical stuff) is the higher > > degree of redundancy and re-programing in living things. > > Byte magazine had a good bit on brains many years back. > > But is it a real bottom-up design by evolution > - or did some whatever do a top-down design? :-) It is both ... the primeval brains evolved bottom up, but each brain works top down. If I remember this right, you got the nervous system, then a fish brain,then a mammal brain, then a primate brain, then a human brain. ( Some organs like the Eye/ears are extensions of the brain ) Brains are complex and just the latest FAD in evolution. Who knows what next years model will be like? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 18:45:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1aX-0000GB-01 for ; Fri, 11 Jan 2002 14:19:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:17 +0100 (CET) Received: (qmail 21174 invoked by uid 0); 10 Jan 2002 17:44:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Jan 2002 17:44:24 -0000 Received: by moria.seul.org (Postfix) id 39E06146826; Thu, 10 Jan 2002 12:44:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2164A146841; Thu, 10 Jan 2002 12:44:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 61F14146826 for ; Thu, 10 Jan 2002 12:44:20 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OjGb-0004k8-00 for f-cpu@seul.org; Thu, 10 Jan 2002 18:45:29 +0100 Date: Thu, 10 Jan 2002 18:45:29 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3DAAFC.4BF040DD@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, Bruno Bougard wrote: > Juergen Goeritz wrote: > > since two years my brain is thinking back and forth how one > > can integrate the design process of software together with > > the design of the hardware to begin to build 'real' systems. > > You should look at target compiler technologies ... > > http://www.retarget.com/ I am focusing on highest performance with shortest network delay - 64bit+ for a start and 2Gbps network. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jan 10 18:55:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1aX-0000GB-02 for ; Fri, 11 Jan 2002 14:19:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:17 +0100 (CET) Received: (qmail 5959 invoked by uid 0); 10 Jan 2002 17:54:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 10 Jan 2002 17:54:45 -0000 Received: by moria.seul.org (Postfix) id 3A861146807; Thu, 10 Jan 2002 12:54:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA9CA146840; Thu, 10 Jan 2002 12:54:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 76164146807 for ; Thu, 10 Jan 2002 12:54:37 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OjQV-0004l2-00 for f-cpu@seul.org; Thu, 10 Jan 2002 18:55:43 +0100 Date: Thu, 10 Jan 2002 18:55:43 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <200201101630.2b88@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002 nicolas.boulay@ifrance.com wrote: > A answer error... that happens :-) > >>>> I'm ok with that but i don't understand you're > point of view with SystemC. > nicO Did you ever program drivers, operating systems and really big programs in C? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jan 10 18:38:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ac-0000GB-00 for ; Fri, 11 Jan 2002 14:19:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:22 +0100 (CET) Received: (qmail 22486 invoked by uid 0); 10 Jan 2002 18:07:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Jan 2002 18:07:52 -0000 Received: by moria.seul.org (Postfix) id 99D451467F4; Thu, 10 Jan 2002 13:07:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84743146840; Thu, 10 Jan 2002 13:07:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 628381467F4 for ; Thu, 10 Jan 2002 13:07:50 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA11197 for ; Thu, 10 Jan 2002 11:07:48 -0700 (MST) Message-ID: <3C3DD19B.84E34840@jetnet.ab.ca> Date: Thu, 10 Jan 2002 10:38:35 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Only with that independent level you are really free to > move the border between hardware and software during the > development process to achieve a maximum performance of > the system in design. The problem is that both C and hardware HDL's are just shit for programing this stuff. Nobody has a good RTL language developed. I don't want to have * / in a RTL language if I can't specify addc and overflow and carry out from addition if I want it. I once had a old yellow book on RTL languages ( now lost ) from the days of punched cards. That language still was better I think than today's stuff as it was clear to read. I don't like operator overloading because you are never sure what operator like '+' is. I would sooner type addc(...) than have '+' overloaded. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 01:22:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ae-0000GB-00 for ; Fri, 11 Jan 2002 14:19:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:24 +0100 (CET) Received: (qmail 17539 invoked by uid 0); 10 Jan 2002 18:20:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 10 Jan 2002 18:20:11 -0000 Received: by moria.seul.org (Postfix) id 119491467F4; Thu, 10 Jan 2002 13:20:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F01F2146840; Thu, 10 Jan 2002 13:20:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id A9FBC1467F4 for ; Thu, 10 Jan 2002 13:20:09 -0500 (EST) Received: from ifrance.com (vlt5-67.n.club-internet.fr [194.158.108.67]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 2887D17FF for ; Thu, 10 Jan 2002 19:20:07 +0100 (CET) Message-ID: <3C3E3058.BED88B3@ifrance.com> Date: Thu, 10 Jan 2002 19:22:48 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz a écrit : > > On Thu, 10 Jan 2002 nicolas.boulay@ifrance.com wrote: > > > A answer error... > > that happens :-) > > > >>>> I'm ok with that but i don't understand you're > > point of view with SystemC. > > nicO > > Did you ever program drivers, operating systems and > really big programs in C? > No but somebody else do it (linux, gnome). So what is the point ? nicO > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Thu Jan 10 19:35:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ae-0000GB-01 for ; Fri, 11 Jan 2002 14:19:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:24 +0100 (CET) Received: (qmail 12830 invoked by uid 0); 10 Jan 2002 18:35:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 10 Jan 2002 18:35:11 -0000 Received: by moria.seul.org (Postfix) id E649B146844; Thu, 10 Jan 2002 13:35:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E2713146843; Thu, 10 Jan 2002 13:35:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 25159146840 for ; Thu, 10 Jan 2002 13:35:10 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id UAA27486 for ; Thu, 10 Jan 2002 20:35:09 +0200 Date: Thu, 10 Jan 2002 20:35:09 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <200201101630.2b88@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > crapy C-style VHDL : to much heavy ! SystemC 2.0 is > quite nice and intriduice concept as channel, > interface, port and events. This stuff are really > usefull for specification for Hardware as for > software. You could create your simulator then refine > it until to understand what is better to put in > hardware or software (for example : how much > automative must be the SRB). I think biggest problem with SystemC style approach is that it is quite different compared to the real design process of many products. It's quite academic thinking that the product is first defined with some system language and only after that the implementation starts. For example if the product has an ASIC the ASIC design starts quite much before other designers even know about the product. ASIC design usually takes that 1.5-2 years. USW/higher level SW guys are still in their old projects during the start of ASIC phase. And ASIC is the critical path usually in products. If you design the system at system SW level before ASIC project it usually means substantial amount of system level code. Even if that code is directly usable in the end product the TTM is longer. ASIC project can be started later because the system description takes so long time. On the other hand if the ASIC is specified in done with traditional means and system SW design for example starts at the same time, time is saved. I think the real question is can the time used in system interface optimization saved in later stages of design. Usually competent designers can do quite good HW/SW interface (fortunately this list has HW guys :)). Can you really save the time needed to fix some HW quirks in SW by using much more time to design the interface. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Thu Jan 10 19:44:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1af-0000GB-00 for ; Fri, 11 Jan 2002 14:19:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:25 +0100 (CET) Received: (qmail 24846 invoked by uid 0); 10 Jan 2002 18:44:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Jan 2002 18:44:29 -0000 Received: by moria.seul.org (Postfix) id 79159146841; Thu, 10 Jan 2002 13:44:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74B9B146845; Thu, 10 Jan 2002 13:44:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id AFDAC146841 for ; Thu, 10 Jan 2002 13:44:27 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id UAA27672 for ; Thu, 10 Jan 2002 20:44:27 +0200 Date: Thu, 10 Jan 2002 20:44:27 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3DD19B.84E34840@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > for programing this stuff. Nobody has a good RTL language > developed. I don't want to have * / in a RTL language if > I can't specify addc and overflow and carry out from addition > if I want it. I once had a old yellow book on RTL languages Why do you normally need to specify how the arithmetic is performed. Isn't it enough to tell the synthesizer what are the timing constraints and synthesizer selects from its arithmetic toolbox "optimal" solution that meets the timing. Currently some hints (pragmas etc. in the code) might be needed to instruct the synthesizers if they get confused. And I think synthesizers are in their infancy still at higher level optimization. I think same applies to state machines. I consider state machines done even with RTL level. And if the SM is done in RTL I think the synthesizer should select the coding of the state vectors etc. Usually it has better knowledge about the constraits of the architecture and what creates fastest solution. Optimal solution I think is higher level SM description where you only draw states and tell state transition rules etc. The problem is how to rely that high level description directly to synthesis level. Usually that high level SM is converted to RTL code, after that the synthesizer reads the RTL code and sees that it is a SM, and optimizes it at high level again. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 02:04:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1af-0000GB-01 for ; Fri, 11 Jan 2002 14:19:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:25 +0100 (CET) Received: (qmail 12296 invoked by uid 0); 10 Jan 2002 19:01:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Jan 2002 19:01:44 -0000 Received: by moria.seul.org (Postfix) id C6309146843; Thu, 10 Jan 2002 14:01:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B5EEA146845; Thu, 10 Jan 2002 14:01:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C7478146843 for ; Thu, 10 Jan 2002 14:01:41 -0500 (EST) Received: from ifrance.com (vlt10-135.n.club-internet.fr [195.36.223.135]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 5B15517DF for ; Thu, 10 Jan 2002 20:01:38 +0100 (CET) Message-ID: <3C3E3A14.1F64A023@ifrance.com> Date: Thu, 10 Jan 2002 20:04:20 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Execution unit input/output References: <200201091403.g09E3sV01999@adam.lip6.fr> <3C3C9ABB.BF895012@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I try to write all the needed ios for an EU. -> 2(3?) data's, register wide (or twice this size if we transform 3r2w in 2r1w) <- 1 (2?) data write, reg wide or twice register wide <-write adress, if the unit are crazy, the release data must be followed by his register bank adress, it will too complicated to duplicat this in the scheduler. -> write adress, to be release with the data <- Running, to know that calcul are on going, for power management, it could be usefull for deguging too. -> freeze, to stop the unit from releasing data (used to avoid contention on the register bank write port) -> enable, used to say to take the input into account (all 2 or3 data's will be connected to all unit but only one should be run). <- Ready, to say that the unit could receive more input. It's used by the scheduler, it allow the use of crazy timed unit like pipelined loop (imagine 4 datas runnning in the same time but the first data will be release after 30 cycles, all multicycle unit could be done as this) The most controversial (and new) part. The idea is to ease the canceling of instructions. Why doing so ? 90 % the code is straitforward for that work (good code). But a lot cases are tricky but should considered. A long time ago, i have read that future processor must done all possible work outside the main stream asynchronously (prefetch,...). Then the in-order core could be as short as possible (it is done with things as the LSU,....). So the idea behind that is to do the most work it is possible and in case of error go back to the good part. The behavior of the core must be simple to be easly predict, so good code could be easier to write. The main point is the jump prediction. The usual hint (branch taken is backward, not taken if foreward) will do a correct job 70% of the time (with today's compiler). If we had the cmove instruction to handel "if" clauses, and if the compiler take this into account (and it should !) we could be very clause to the 100% branch prediction. The problem with branch prediction are the miss. So we must handel carrefully the canceling job. Whygee clame everywhere that he found a means to use only 1 cycle with branches. I doesn't understand how it could be possible. I see 7 stages DSP, the first 2 stage are only to wait the data from the memory (pipelined access), then we need a cycle to write or not the program counter. So we lose at least 3 cycles. The other point is regarding what must be done by the cache controler before releasing a data (read in a ~64 Kbyte memory then check + some muxes, i think we are far way frome 6 gate deep (far from 12, too !) ) So i propose to number the intruction with "few" bits counter (6-8?). Then we could ask the unit to cancel all data previous to a point. So the scheduler doesn't need to stop all unit at the decoding stage to prevent "possible" problem that come very rarely. -> instruction_number -> discard_instruction -> ° of discarded instruction Hope this help ! nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 02:25:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ag-0000GB-00 for ; Fri, 11 Jan 2002 14:19:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:26 +0100 (CET) Received: (qmail 27673 invoked by uid 0); 10 Jan 2002 19:22:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Jan 2002 19:22:25 -0000 Received: by moria.seul.org (Postfix) id 9E343146805; Thu, 10 Jan 2002 14:22:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6205C146810; Thu, 10 Jan 2002 14:22:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E7D5F146805 for ; Thu, 10 Jan 2002 14:22:22 -0500 (EST) Received: from ifrance.com (vlt11-155.n.club-internet.fr [195.36.224.155]) by relay-1v.club-internet.fr (Postfix) with ESMTP id EA820171D for ; Thu, 10 Jan 2002 20:22:19 +0100 (CET) Message-ID: <3C3E3EED.4B89E454@ifrance.com> Date: Thu, 10 Jan 2002 20:25:01 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] LSU or cache L0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On of the idea to speed up memory access is the use of a kind of L0 cache (called LSU unit by whygee). It's a kind of associative memory like any cache. But here the idea is to cache REGISTER number with memory content bypassing the memory address. So in case of taken jump, the data is still there and access to memory could be hiden. For program flot, there is no problem. But for data there is a very big one : aliases. 2 differents register could point the same data location but the 2 could became uncoherent ! Wygee propose that each line of the L0 caches could be associated with 2 or 4 registers. But i thing it's not enough. I will introduice a very strong and dangerous coding rules : no more than 2 or 4 aliases ! Compiler writer will have headack to guaranty that ! One of the easiest way to manage this cache it a simple memory bank, 64 line (one for each reg) of 2 lines of caches (so double buffering and prefetech could be done). It's only 2 Ko of memory, it's not a lot and we don't need too much access port on it ;p But an other trick could be used. In the manual, we can read that each Load & store operation are made with "stream" number (3bits, 8 streams). It's "à la" Cray. But without further explanation. In fact Cray computer are ncc-numa (nonr coherent memory access). So the data coherency should be handel by soft, it hard to manage it correctly but it speed up a lot the job. So each stream aren't coherent between them. The order of the access to the main memory with different stream could exchange, invert and so one. We guaranty to the hardware that they will not have stupid thing as read after write to the same memory location (before caches are coherent, the load&store must compare all adresse to have incoherent behavior). So in our case, instead of using 64 lines memory, we need only 8 lines memory (with longuest line if you want). So there is no more coherency problem. If compiler have problem with pointer analysis, it will use the same stream to avoid aliases problem. It was for handel data. For program code, the previous trick could be used safely. Comments ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jan 10 19:58:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ah-0000GB-00 for ; Fri, 11 Jan 2002 14:19:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:27 +0100 (CET) Received: (qmail 25895 invoked by uid 0); 10 Jan 2002 19:27:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 10 Jan 2002 19:27:51 -0000 Received: by moria.seul.org (Postfix) id EA27D146805; Thu, 10 Jan 2002 14:27:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5AD0146810; Thu, 10 Jan 2002 14:27:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id B4BF2146805 for ; Thu, 10 Jan 2002 14:27:48 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA14954 for ; Thu, 10 Jan 2002 12:27:47 -0700 (MST) Message-ID: <3C3DE45B.A65D7BAB@jetnet.ab.ca> Date: Thu, 10 Jan 2002 11:58:35 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > > > for programing this stuff. Nobody has a good RTL language > > developed. I don't want to have * / in a RTL language if > > I can't specify addc and overflow and carry out from addition > > if I want it. I once had a old yellow book on RTL languages > > Why do you normally need to specify how the arithmetic is performed. Isn't > it enough to tell the synthesizer what are the timing constraints and > synthesizer selects from its arithmetic toolbox "optimal" solution that > meets the timing. Currently some hints (pragmas etc. in the code) might be > needed to instruct the synthesizers if they get confused. And I think > synthesizers are in their infancy still at higher level optimization. But the user can't get at or view the fine details. 99% of the time I can let the synthesiser do what it whats. It is that 1% of the time you have no control of the system. BTW is still want ADC! -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 03:39:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1ai-0000GB-01 for ; Fri, 11 Jan 2002 14:19:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:28 +0100 (CET) Received: (qmail 26809 invoked by uid 0); 10 Jan 2002 20:37:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Jan 2002 20:37:08 -0000 Received: by moria.seul.org (Postfix) id 06D02146805; Thu, 10 Jan 2002 15:37:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D9C60146815; Thu, 10 Jan 2002 15:37:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 952F3146805 for ; Thu, 10 Jan 2002 15:37:07 -0500 (EST) Received: from ifrance.com (vlt11-113.n.club-internet.fr [195.36.224.113]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C12C316C4 for ; Thu, 10 Jan 2002 21:37:04 +0100 (CET) Message-ID: <3C3E5072.19E70B21@ifrance.com> Date: Thu, 10 Jan 2002 21:39:46 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara a écrit : > > > crapy C-style VHDL : to much heavy ! SystemC 2.0 is > > quite nice and intriduice concept as channel, > > interface, port and events. This stuff are really > > usefull for specification for Hardware as for > > software. You could create your simulator then refine > > it until to understand what is better to put in > > hardware or software (for example : how much > > automative must be the SRB). > > I think biggest problem with SystemC style approach is that it is quite > different compared to the real design process of many products. It's quite > academic thinking that the product is first defined with some system > language and only after that the implementation starts. > > For example if the product has an ASIC the ASIC design starts quite much > before other designers even know about the product. ASIC design usually > takes that 1.5-2 years. USW/higher level SW guys are still in their old > projects during the start of ASIC phase. And ASIC is the critical path > usually in products. If you design the system at system SW level before > ASIC project it usually means substantial amount of system level code. > Even if that code is directly usable in the end product the TTM is longer. > ASIC project can be started later because the system description takes so > long time. On the other hand if the ASIC is specified in done > with traditional means and system SW design for example starts at the same > time, time is saved. > > I think the real question is can the time used in system interface > optimization saved in later stages of design. Usually competent designers > can do quite good HW/SW interface (fortunately this list has HW guys :)). > Can you really save the time needed to fix some HW quirks in SW by using > much more time to design the interface. > Humm :D Juste one question, are you a quite young designer with 5 or 10 years of experiences, no ? The typical design is made more or less as follow : - specification : mainly with hand and paper - then design partition hard/soft - then you start to code the HW - and then the SW (but you could start the soft ware more or less in the same time and the following funny point is the merge ;) Codesign aren't only simulated SW with HW, it's a way of design. The idea is to clearly describe your specification. Formal language are the best for that because it will proove some properties. Todays tool's maker try to implement "runnable specification". SystemC is born with that idea in mind. I don't thing it the best idea because to run something, you _must_ allmost finish a kind of simulation of your system. But at least, you don't need to write synthetisable stuff. So you try to push the SW/HW split as far as you can to find the best cut. So you avoid redesign or late problem. It's well know that later a problem is found, more costly it is. I have even read that cost are 10x at each level. So, by using SystemC, you are supposed to win a lot of time, the feed back are quicker and much more efficient. nicO > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Jan 10 22:10:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1al-0000GB-00 for ; Fri, 11 Jan 2002 14:19:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:31 +0100 (CET) Received: (qmail 1597 invoked by uid 0); 10 Jan 2002 21:10:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 10 Jan 2002 21:10:27 -0000 Received: by moria.seul.org (Postfix) id C3D0F146805; Thu, 10 Jan 2002 16:10:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF7E5146815; Thu, 10 Jan 2002 16:10:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7BD94146805 for ; Thu, 10 Jan 2002 16:10:25 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id 135AB16AD; Thu, 10 Jan 2002 22:10:23 +0100 (CET) From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Tr:Rep:Re: [f-cpu] "Tree" Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jan 2002 22:10:23 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 this is not a troll but ... >nicO >Kim Enkovaara a =E9crit : = >> Can you really save the time needed to fix some HW quirks in SW by usin= g >> much more time to design the interface. >Humm :D Juste one question, are you a quite young designer with 5 or 10 >years of experiences, no ? here, i guess that you (nico) started to design ASICs at the age of 14. >nicO YG (still droolling and rolling and trolling and...) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 10 19:48:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1as-0000GB-00 for ; Fri, 11 Jan 2002 14:19:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:38 +0100 (CET) Received: (qmail 30812 invoked by uid 0); 10 Jan 2002 23:04:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 10 Jan 2002 23:04:23 -0000 Received: by moria.seul.org (Postfix) id 438701467EB; Thu, 10 Jan 2002 18:04:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23F12146804; Thu, 10 Jan 2002 18:04:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a202.home.uni-hannover.de [130.75.232.202]) by moria.seul.org (Postfix) with ESMTP id BD23D1467EB for ; Thu, 10 Jan 2002 18:04:20 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00495; Thu, 10 Jan 2002 19:48:08 +0100 Message-ID: <20020110194808.59191@thrai.stud.uni-hannover.de> Date: Thu, 10 Jan 2002 19:48:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" References: <200201091403.g09E3sV01999@adam.lip6.fr> <3C3C9ABB.BF895012@jetnet.ab.ca> <3C3D8C3D.894CBD9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C3D8C3D.894CBD9@f-cpu.org>; from Yann Guidon on Thu, Jan 10, 2002 at 01:42:37PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jan 10, 2002 at 01:42:37PM +0100, Yann Guidon wrote: > hi, > > Ben Franchuk wrote: > > "Yann Guidon [systeme]" wrote: > > > There are both students and professionals here but the point of F-CPU > > > is to allow anybody (with a linux box) to participate without constraint. > > > The synthesis problem is one of those we have to solve now. > > > > Ignoring the problem with graphics, why not a Windows or Unix Box. It > > would be nice not to be tied to just one OS if possible. > that is one other problem, too. For example, i started to use Simili > when only the Win32 version was available. Fortunately the sources > are portable across other platforms, but compilation scripts are not. [...] Of course they are - if you have the Cygwin stuff (GNU make, bash, m4...) installed, scripts and Makefiles will work on NT/2K, too. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 11 02:01:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1b0-0000GB-00 for ; Fri, 11 Jan 2002 14:19:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:46 +0100 (CET) Received: (qmail 21921 invoked by uid 0); 11 Jan 2002 00:58:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 11 Jan 2002 00:58:24 -0000 Received: by moria.seul.org (Postfix) id 3E9B21462FD; Thu, 10 Jan 2002 19:58:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 394851467EB; Thu, 10 Jan 2002 19:58:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E7C591462FD for ; Thu, 10 Jan 2002 19:58:23 -0500 (EST) Received: from f-cpu.org (kdl11-54.n.club-internet.fr [213.44.9.54]) by relay-1v.club-internet.fr (Postfix) with ESMTP id C77001699 for ; Fri, 11 Jan 2002 01:58:15 +0100 (CET) Message-ID: <3C3E3980.6218B21@f-cpu.org> Date: Fri, 11 Jan 2002 02:01:52 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ERIN32 References: <000a01c19934$4833fbc0$de9ad6d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, though your posts sometimes look off-topic, this one raised a question. I hope that others will give their advices and share their experience. > richard hartny wrote: > > I see some points made on circuit loading. While at Sanders > Associates Inc several years back; it was determined that a Logic > design having a maximum fan-out of 7 loads had a good chance of > surviving temperature testing over the military temperature range which chance ? 100% or less ? > of -55 to +125c. In my design of the Erin32 I took special > care to have a maximum load of 8. In the chip design process; > there is an Auto-buffer option - I always use it. > I will be very happy to answer any questions of the design. so here we go. When i did some ACTEL FPGA design, several years ago, the manual said that a fanout higher than 8 was not recommended. On top of that, the "compiler" (which processes the DesignArchitect hierarchical drawings) would probably modify this but i wasn't told to what extent. Currently, i try to limit fanout to 4. I think that it is a good balance if we consider that the cell would get otherwise even larger (with a larger output buffer) and the wire loading comes into play. I prefer to duplicate the cell, like i did in the ROP2 unit (in the AND/OR combine operation). I have read the discusion about the fanout trees and want to know how this translates in this case. In the end of this call for comment, it would be cool if a specification or design rule could be drafted/proposed, addressing the widest range of tools and technologies. > Regards > Richard E. Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 09:01:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1b6-0000GB-00 for ; Fri, 11 Jan 2002 14:19:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:52 +0100 (CET) Received: (qmail 13323 invoked by uid 0); 11 Jan 2002 08:15:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 11 Jan 2002 08:15:30 -0000 Received: by moria.seul.org (Postfix) id 202FA1467F7; Fri, 11 Jan 2002 03:15:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E26791467FE; Fri, 11 Jan 2002 03:15:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A2F7D1467F7 for ; Fri, 11 Jan 2002 03:15:26 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OwcW-0005JY-00 for f-cpu@seul.org; Fri, 11 Jan 2002 09:01:00 +0100 Date: Fri, 11 Jan 2002 09:01:00 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, Kim Enkovaara wrote: > I think biggest problem with SystemC style approach is that it is quite > different compared to the real design process of many products. It's quite > academic thinking that the product is first defined with some system > language and only after that the implementation starts. Yes, up to now you are right. But does it need to be like this? > For example if the product has an ASIC the ASIC design starts quite much > before other designers even know about the product. ASIC design usually > takes that 1.5-2 years. USW/higher level SW guys are still in their old > projects during the start of ASIC phase. And ASIC is the critical path > usually in products. If you design the system at system SW level before > ASIC project it usually means substantial amount of system level code. > Even if that code is directly usable in the end product the TTM is longer. > ASIC project can be started later because the system description takes so > long time. On the other hand if the ASIC is specified in done > with traditional means and system SW design for example starts at the same > time, time is saved. I rather have the opinion that after the chip is ready and the software starts to use it the problems show up - 2 years lost. And imagine - who can spend more than 2 years time to market? After 2 years time the premiss may have changed completely. Some ASICs were cancelled right when they were finished and working. > I think the real question is can the time used in system interface > optimization saved in later stages of design. Usually competent designers > can do quite good HW/SW interface (fortunately this list has HW guys :)). > Can you really save the time needed to fix some HW quirks in SW by using > much more time to design the interface. Why use more time? If one has HW quirks either the definition was sh.. or one has overlooked something fundamental or one tried to save time from simulation (pressing schedule). And - and that is my biggest concern - one didn't know how the software will use the interface later. If you look at e.g. IDTs 79RC32355 or NECs uPD98501 they both have the errata that you can't use transmit queues for ethernet. You have to individually setup every frame for transmission. This one can only happen if the simulation does not have a real driver for the device and/or few simulation time. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 09:13:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1b7-0000GB-00 for ; Fri, 11 Jan 2002 14:19:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:53 +0100 (CET) Received: (qmail 4857 invoked by uid 0); 11 Jan 2002 08:15:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jan 2002 08:15:17 -0000 Received: by moria.seul.org (Postfix) id F008A1467F3; Fri, 11 Jan 2002 03:15:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E81CF1467F6; Fri, 11 Jan 2002 03:15:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 2D6841467F3 for ; Fri, 11 Jan 2002 03:15:15 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16Owop-0005Ju-00 for f-cpu@seul.org; Fri, 11 Jan 2002 09:13:43 +0100 Date: Fri, 11 Jan 2002 09:13:43 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <3C3E3058.BED88B3@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, nicO wrote: > Juergen Goeritz a =E9crit : > > > >>>> I'm ok with that but i don't understand you're > > > point of view with SystemC. > > > nicO > >=20 > > Did you ever program drivers, operating systems and > > really big programs in C? > >=20 >=20 > No but somebody else do it (linux, gnome). So what is the point ? Oh! Then it's hard to explain. Let me say it this way, the abstraction level is too low. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 09:09:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1b7-0000GB-01 for ; Fri, 11 Jan 2002 14:19:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:53 +0100 (CET) Received: (qmail 5477 invoked by uid 0); 11 Jan 2002 08:15:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jan 2002 08:15:32 -0000 Received: by moria.seul.org (Postfix) id 1AA451467F6; Fri, 11 Jan 2002 03:15:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0826F1467FD; Fri, 11 Jan 2002 03:15:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A6797146802 for ; Fri, 11 Jan 2002 03:15:28 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16Owkx-0005Jp-00 for f-cpu@seul.org; Fri, 11 Jan 2002 09:09:43 +0100 Date: Fri, 11 Jan 2002 09:09:43 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, Kim Enkovaara wrote: > I think same applies to state machines. I consider state machines done > even with RTL level. And if the SM is done in RTL I think the > synthesizer should select the coding of the state vectors etc. Usually it > has better knowledge about the constraits of the architecture and what > creates fastest solution. Optimal solution I think is higher level SM > description where you only draw states and tell state transition rules Igitt! My experience is that drawings should only be an output but not an input to the design. Otherwise it's real SM and it costs you nerves without end to include those changes into the design. > etc. The problem is how to rely that high level description directly to > synthesis level. Usually that high level SM is converted to RTL code, > after that the synthesizer reads the RTL code and sees that it is a SM, > and optimizes it at high level again. Why convert to RTL code. Every synchronous statemachine can directly be translated into a function table without thinking. The only statemachines I have great respect of are those that treat each input signal as a clock and remember the contence by the device delay feedback only (no registers). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 08:33:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1b8-0000GB-00 for ; Fri, 11 Jan 2002 14:19:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:54 +0100 (CET) Received: (qmail 2461 invoked by uid 0); 11 Jan 2002 08:15:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 11 Jan 2002 08:15:26 -0000 Received: by moria.seul.org (Postfix) id 263A41467F5; Fri, 11 Jan 2002 03:15:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E4A11467F7; Fri, 11 Jan 2002 03:15:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id E7DC91467F5 for ; Fri, 11 Jan 2002 03:15:24 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OwBo-0005JL-00 for f-cpu@seul.org; Fri, 11 Jan 2002 08:33:24 +0100 Date: Fri, 11 Jan 2002 08:33:24 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] "Tree" In-Reply-To: <3C3DD19B.84E34840@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > Only with that independent level you are really free to > > move the border between hardware and software during the > > development process to achieve a maximum performance of > > the system in design. > > The problem is that both C and hardware HDL's are just shit > for programing this stuff. Nobody has a good RTL language > developed. I don't want to have * / in a RTL language if > I can't specify addc and overflow and carry out from addition > if I want it. I once had a old yellow book on RTL languages > ( now lost ) from the days of punched cards. That language > still was better I think than today's stuff as it was clear > to read. I agree completely! When I look at VHDL code it doesn't hit my eye directly how it works. The same with C in bigger designs. I recently found some very old tool that has table driven input. With this you see directly what the design does - and the best of all, it really supports 'don't care' X statements for inputs AND ouputs to provide the full possibility range to the optimizers. That's especially great for statemachines, decoders and such stuff. > I don't like operator overloading because you are > never sure what operator like '+' is. I would sooner type > addc(...) than have '+' overloaded. You are right again! When I recently analyzed that loading control system (written in C++) it took most of the time to figure out how they disarranged the normal C operators. After that it showed up that the system wasn't a great composition at all - lots of bottle necks. But it was very complex to read. Probably a new kind of copy protection? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 09:43:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bA-0000GB-00 for ; Fri, 11 Jan 2002 14:19:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:56 +0100 (CET) Received: (qmail 6002 invoked by uid 0); 11 Jan 2002 08:42:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 11 Jan 2002 08:42:11 -0000 Received: by moria.seul.org (Postfix) id DE7E51467FE; Fri, 11 Jan 2002 03:42:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DBE951467FD; Fri, 11 Jan 2002 03:42:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 633311467F6 for ; Fri, 11 Jan 2002 03:42:09 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OxHp-0005LG-00 for f-cpu@seul.org; Fri, 11 Jan 2002 09:43:41 +0100 Date: Fri, 11 Jan 2002 09:43:41 +0100 (MET) From: Juergen Goeritz To: "f-cpu@seul.org" Subject: Re: [f-cpu] LSU or cache L0 In-Reply-To: <3C3E3EED.4B89E454@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, nicO wrote: > On of the idea to speed up memory access is the use of a kind of L0 > cache (called LSU unit by whygee). >=20 > It's a kind of associative memory like any cache. But here the idea is > to cache REGISTER number with memory content bypassing the memory > address. So in case of taken jump, the data is still there and access to > memory could be hiden. >=20 > For program flot, there is no problem. But for data there is a very big > one : aliases. >=20 > 2 differents register could point the same data location but the 2 could > became uncoherent ! Wygee propose that each line of the L0 caches could > be associated with 2 or 4 registers. But i thing it's not enough. I will > introduice a very strong and dangerous coding rules : no more than 2 or > 4 aliases ! Compiler writer will have headack to guaranty that ! >=20 > One of the easiest way to manage this cache it a simple memory bank, 64 > line (one for each reg) of 2 lines of caches (so double buffering and > prefetech could be done). It's only 2 Ko of memory, it's not a lot and > we don't need too much access port on it ;p >=20 > But an other trick could be used. In the manual, we can read that each > Load & store operation are made with "stream" number (3bits, 8 streams). > It's "=E0 la" Cray. But without further explanation.=20 >=20 > In fact Cray computer are ncc-numa (nonr coherent memory access). So the > data coherency should be handel by soft, it hard to manage it correctly > but it speed up a lot the job. >=20 > So each stream aren't coherent between them. The order of the access to > the main memory with different stream could exchange, invert and so one. > We guaranty to the hardware that they will not have stupid thing as read > after write to the same memory location (before caches are coherent, the > load&store must compare all adresse to have incoherent behavior). >=20 > So in our case, instead of using 64 lines memory, we need only 8 lines > memory (with longuest line if you want). So there is no more coherency > problem. If compiler have problem with pointer analysis, it will use the > same stream to avoid aliases problem. >=20 > It was for handel data. For program code, the previous trick could be > used safely. >=20 > Comments ? It looks like someone should setup some compiler directive paper. The more complex the compiler will get, the longer you will wait for one to come that is capable of doing all this stuff. A new processor is nothing without the compiler/debugger support. The lastest example was one coming from Germany called Hyperstone which got mixed size instruction length thus being able to not have a pipeline stall at context switch with just a 2 word cache. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 09:36:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bB-0000GB-00 for ; Fri, 11 Jan 2002 14:19:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:57 +0100 (CET) Received: (qmail 19648 invoked by uid 0); 11 Jan 2002 08:42:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 11 Jan 2002 08:42:10 -0000 Received: by moria.seul.org (Postfix) id BEE971467F3; Fri, 11 Jan 2002 03:42:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF1271467F6; Fri, 11 Jan 2002 03:42:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 9F6CA1467F3 for ; Fri, 11 Jan 2002 03:42:07 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OxB8-0005LE-00 for f-cpu@seul.org; Fri, 11 Jan 2002 09:36:46 +0100 Date: Fri, 11 Jan 2002 09:36:46 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <3C3E5072.19E70B21@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 10 Jan 2002, nicO wrote: > Codesign aren't only simulated SW with HW, it's a way of design. The > idea is to clearly describe your specification. Formal language are the > best for that because it will proove some properties. Todays tool's > maker try to implement "runnable specification". SystemC is born with > that idea in mind. > > I don't thing it the best idea because to run something, you _must_ > allmost finish a kind of simulation of your system. But at least, you > don't need to write synthetisable stuff. > > So you try to push the SW/HW split as far as you can to find the best > cut. So you avoid redesign or late problem. It's well know that later a > problem is found, more costly it is. I have even read that cost are 10x > at each level. > > So, by using SystemC, you are supposed to win a lot of time, the feed > back are quicker and much more efficient. Ohh! But even with SystemC you can't really co-design. You can't just write your software and move the sw/hw split later BECAUSE you already have to write those parts hardware level C that you want to be able to put into hardware later. This means you aren't really using a new method but a new language - the division is done also in relatively early stages of the design. What I would want is to write just a normal program and have a tool that extracts me the parts of my complete functionality that can be put into hardware. I don't like restrictions on the programming style side. And I want a tool that tells me about the achievable performance at every step of the development process. Only then you can make intelligent decisions. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 10:03:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bD-0000GB-00 for ; Fri, 11 Jan 2002 14:19:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:19:59 +0100 (CET) Received: (qmail 16640 invoked by uid 0); 11 Jan 2002 09:04:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 11 Jan 2002 09:04:21 -0000 Received: by moria.seul.org (Postfix) id 6E37A1467E8; Fri, 11 Jan 2002 04:04:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52C301467F3; Fri, 11 Jan 2002 04:04:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id ACABE1467E8 for ; Fri, 11 Jan 2002 04:04:18 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Fri, 11 Jan 2002 09:03:57 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Codesign and SystemC From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2002 09:03:57 GMT Message-id: <200201110903.39b5@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i answer to JG, but my mailer didn't want to copy it's mail. On Thu, 10 Jan 2002, nicO wrote: > Codesign aren't only simulated SW with HW, it's a way of design. The > idea is to clearly describe your specification. Formal language are the > best for that because it will proove some properties. Todays tool's > maker try to implement "runnable specification". SystemC is born with > that idea in mind. >=20 > I don't thing it the best idea because to run something, you _must_ > allmost finish a kind of simulation of your system. But at least, you > don't need to write synthetisable stuff. >=20 > So you try to push the SW/HW split as far as you can to find the best > cut. So you avoid redesign or late problem. It's well know that later a > problem is found, more costly it is. I have even read that cost are 10x > at each level. >=20 > So, by using SystemC, you are supposed to win a lot of time, the feed > back are quicker and much more efficient. Ohh! But even with SystemC you can't really co-design. You can't just write your software and move the sw/hw split later BECAUSE you already have to write those parts hardware level C that you want to be able to put into hardware later. This means you aren't really using a new method but a new language - the division is done also in relatively early stages of the design. >>>> The split must NOT be done at early stage. It will be done at the LATER point. Why because dependanding of performance you want, you could do to choose to put thing inside a pure static hardware engine, a application specific cpu or in pure software. This choice could only be "well" done after fine analysys of the algorythme. Todays a choice is made and the algorythme sould feet in it. So you take udge DSP to have enough marges, in case of problem. SystemC are C++ so your could always start to write things in pure software style and then you refine your model to have working hardware (after split) (an other advantage is the speed 1000 x quicker than VHDL simulation !) What I would want is to write just a normal program and have a tool that extracts me the parts of my complete functionality that can be put into hardware. I don't like restrictions on the programming style side. And I want a >>>>There isn't any restriction ! They come when you want to synthetis things after the split, when performance requirement are well known and specification fixed. tool that tells me about the achievable performance at every step of the development process. Only then you can make intelligent decisions. >>>> Some tools exist to do that : eArchitect from i don't know which compagny, ... They call that : Architecture exploration. nicO JG =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 10:20:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bJ-0000GB-00 for ; Fri, 11 Jan 2002 14:20:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:05 +0100 (CET) Received: (qmail 10670 invoked by uid 0); 11 Jan 2002 09:20:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 11 Jan 2002 09:20:51 -0000 Received: by moria.seul.org (Postfix) id 985DA1467E8; Fri, 11 Jan 2002 04:20:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D78D1467F3; Fri, 11 Jan 2002 04:20:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id B02021467E8 for ; Fri, 11 Jan 2002 04:20:48 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Fri, 11 Jan 2002 09:20:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Tr:Rep:Re: [f-cpu] "Tree" From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2002 09:20:28 GMT Message-id: <200201110920.1cca@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: A: Date: 11/01/02 Objet: Rep:Re: [f-cpu] "Tree" -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 11/01/02 Objet: Re: [f-cpu] "Tree" On Thu, 10 Jan 2002, Kim Enkovaara wrote: > I think same applies to state machines. I consider state machines done > even with RTL level. And if the SM is done in RTL I think the > synthesizer should select the coding of the state vectors etc. Usually it > has better knowledge about the constraits of the architecture and what > creates fastest solution. Optimal solution I think is higher level SM > description where you only draw states and tell state transition rules Igitt! My experience is that drawings should only be an output but not an input to the design. Otherwise it's real SM and it costs you nerves without end to include those changes into the design.=20 > etc. The problem is how to rely that high level description directly to > synthesis level. Usually that high level SM is converted to RTL code, > after that the synthesizer reads the RTL code and sees that it is a SM,=20 > and optimizes it at high level again. Why convert to RTL code. Every synchronous statemachine can directly be translated into a function table without thinking. The only statemachines I have great respect of are those that treat each input signal as a clock and remember the contence by the device delay feedback only (no registers). >>>> A nice feed back asynchronous loop ! I don't think that a verifing tools could handel that. (static timming analyser,...). I don't that will be allow to produice such design by a foundry. It could be done only by hand with a very specific technology, so it will not be portable at all. >>>>>>Maybe you should read about F21. It's a complete assynchonous design. It run at 2 ns for a cycle for a 0.8um technology. It doesn't use neither double rail logic nor hand checking. I was in contact with one of the guy from the team who write it. But i don't know how they time there cpu. nicO JG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 _____________________________________________________ _________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 11 10:20:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bK-0000GB-00 for ; Fri, 11 Jan 2002 14:20:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:06 +0100 (CET) Received: (qmail 28984 invoked by uid 0); 11 Jan 2002 09:21:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Jan 2002 09:21:15 -0000 Received: by moria.seul.org (Postfix) id 525951467E9; Fri, 11 Jan 2002 04:21:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 360921467F5; Fri, 11 Jan 2002 04:21:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id A9D4A1467E9 for ; Fri, 11 Jan 2002 04:21:13 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Fri, 11 Jan 2002 09:20:52 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Tr:Rep:Re: Tr:Rep:Re: [f-cpu] "Tree" From: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2002 09:20:52 GMT Message-id: <200201110920.34db@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: A: Date: 11/01/02 Objet: Rep:Re: Tr:Rep:Re: [f-cpu] "Tree" -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 11/01/02 Objet: Re: Tr:Rep:Re: [f-cpu] "Tree" On Thu, 10 Jan 2002, nicO wrote: > Juergen Goeritz a =E9crit : > > > >>>> I'm ok with that but i don't understand you're > > > point of view with SystemC. > > > nicO > >=20 > > Did you ever program drivers, operating systems and > > really big programs in C? > >=20 >=20 > No but somebody else do it (linux, gnome). So what is the point ? Oh! Then it's hard to explain. Let me say it this way, the abstraction level is too low. >>>> So there is "some" millions C lines project. C++ are a quite bad design OO language but if you restrict your self to a sub set of it it could be great. SystemC are c++ class to rease the level of abstraction because it's runnable you must be enought precise.=20 Which kind of concept do you want to be implemented in such language ? (my last year at university was made inside a laboratorie which try to design such kind of language, and todays SystemC are very close to what was espected)=20 nicO JG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 _____________________________________________________ _________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 12:06:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bP-0000GB-01 for ; Fri, 11 Jan 2002 14:20:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:11 +0100 (CET) Received: (qmail 26752 invoked by uid 0); 11 Jan 2002 11:06:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 11 Jan 2002 11:06:42 -0000 Received: by moria.seul.org (Postfix) id 88D991462FD; Fri, 11 Jan 2002 06:06:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B3221467E9; Fri, 11 Jan 2002 06:06:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id D90891462FD for ; Fri, 11 Jan 2002 06:06:39 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OzWH-0005U7-00 for f-cpu@seul.org; Fri, 11 Jan 2002 12:06:45 +0100 Date: Fri, 11 Jan 2002 12:06:45 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Codesign and SystemC In-Reply-To: <200201110903.39b5@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002 nicolas.boulay@ifrance.com wrote: > > >>>> The split must NOT be done at early stage. It > will be done at the LATER point. Why because > dependanding of performance you want, you could do to > choose to put thing inside a pure static hardware > engine, a application specific cpu or in pure > software. This choice could only be "well" done after > fine analysys of the algorythme. Todays a choice is > made and the algorythme sould feet in it. So you take > udge DSP to have enough marges, in case of problem. > SystemC are C++ so your could always start to write > things in pure software style and then you refine > your model to have working hardware (after split) (an > other advantage is the speed 1000 x quicker than VHDL > simulation !) I agree with the first sentence. But can you really extract a part of a complex C function and put it into the hardware and SystemC generates the software drivers you need from the rest? No? Do I have to rewrite the code each time I want to try another split - until I am satisfied or f*#!$*ed? (sorry! :-) What I'd like to have is the faster simulation speed. But it's still to slow to simulate the complete software too. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 11:50:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bQ-0000GB-00 for ; Fri, 11 Jan 2002 14:20:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:12 +0100 (CET) Received: (qmail 26133 invoked by uid 0); 11 Jan 2002 11:06:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 11 Jan 2002 11:06:45 -0000 Received: by moria.seul.org (Postfix) id 8A0CA1467E9; Fri, 11 Jan 2002 06:06:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B3501467F3; Fri, 11 Jan 2002 06:06:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 99ECB1467F2 for ; Fri, 11 Jan 2002 06:06:41 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16OzGn-0005Tn-00 for f-cpu@seul.org; Fri, 11 Jan 2002 11:50:45 +0100 Date: Fri, 11 Jan 2002 11:50:45 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re[4]: [f-cpu] "Tree" In-Reply-To: <200201110920.34db@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002 nicolas.boulay@ifrance.com wrote: > On Thu, 10 Jan 2002, nicO wrote: > > Juergen Goeritz a =E9crit : > > > Did you ever program drivers, operating systems and > > > really big programs in C? > >=20 > > No but somebody else do it (linux, gnome). So what > > is the point ? >=20 > Oh! Then it's hard to explain. Let me say it this > way, the abstraction level is too low. >=20 > >>>> So there is "some" millions C lines project. C++ > are a quite bad design OO language but if you > restrict your self to a sub set of it it could be > great. > SystemC are c++ class to rease the level of > abstraction because it's runnable you must be enought > precise.=20 > Which kind of concept do you want to be implemented > in such language ? (my last year at university was > made inside a laboratorie which try to design such > kind of language, and todays SystemC are very close > to what was espected)=20 The problem is that with C you have an implementation already. This means you have already translated from the concept you had in mind. You strip information about your design when you translate it to C and you add 'noise'. A good language would resemble the way of thinking of mans brain regarding digital design. Therefore C isn't a good language. Some problem solutions can be easily formed with C, others are hard to implement. Most of them are hard to check (time consuming) for correctness. Simulation is a means to look at the same issue from another point of view - you go to the outside of your design and look how it reacts. Testvectors that are defined also describe the design functionality. If you have a 100% testvector coverage you wouldn't need the source of the design any more - the testvectors would do because they also completely define your design from it's reactions. And they have to because you need them to check the final chip. It's like a double bookkeeping. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 11:26:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bR-0000GB-00 for ; Fri, 11 Jan 2002 14:20:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:13 +0100 (CET) Received: (qmail 17953 invoked by uid 0); 11 Jan 2002 11:06:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 11 Jan 2002 11:06:49 -0000 Received: by moria.seul.org (Postfix) id 2B6FC1467F2; Fri, 11 Jan 2002 06:06:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0411C1467F4; Fri, 11 Jan 2002 06:06:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 951191467F2 for ; Fri, 11 Jan 2002 06:06:43 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16Oytc-0005Tl-00 for f-cpu@seul.org; Fri, 11 Jan 2002 11:26:48 +0100 Date: Fri, 11 Jan 2002 11:26:48 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <200201110920.1cca@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002 nicolas.boulay@ifrance.com wrote: > Why convert to RTL code. Every synchronous > statemachine can > directly be translated into a function table without > thinking. > > The only statemachines I have great respect of are > those > that treat each input signal as a clock and remember > the > contence by the device delay feedback only (no > registers). > > >>>> A nice feed back asynchronous loop ! I don't > think that a verifing tools could handel that. > (static timming analyser,...). I don't that will be > allow to produice such design by a foundry. It could > be done only by hand with a very specific technology, > so it will not be portable at all. You are right - it is very much technology dependent and I stated above that I have great respect of these designs. I would not want to use any if there are other possibilities. > >>>>>>Maybe you should read about F21. It's a > complete assynchonous design. It run at 2 ns for a > cycle for a 0.8um technology. It doesn't use neither > double rail logic nor hand checking. I was in contact > with one of the guy from the team who write it. But > i don't know how they time there cpu. Do you have a URL or email address? I am just curious. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jan 11 12:42:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16P1bU-0000GB-00 for ; Fri, 11 Jan 2002 14:20:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 11 Jan 2002 14:20:16 +0100 (CET) Received: (qmail 25356 invoked by uid 0); 11 Jan 2002 11:41:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 11 Jan 2002 11:41:08 -0000 Received: by moria.seul.org (Postfix) id 646131467F4; Fri, 11 Jan 2002 06:41:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 606021467F3; Fri, 11 Jan 2002 06:41:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0E8941467E8 for ; Fri, 11 Jan 2002 06:41:05 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16P04y-0005Wt-00 for f-cpu@seul.org; Fri, 11 Jan 2002 12:42:36 +0100 Date: Fri, 11 Jan 2002 12:42:36 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re[4]: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002, Juergen Goeritz wrote: > On Fri, 11 Jan 2002 nicolas.boulay@ifrance.com wrote: > > On Thu, 10 Jan 2002, nicO wrote: > > > Juergen Goeritz a =E9crit : > > > > Did you ever program drivers, operating systems and > > > > really big programs in C? > > >=20 > > > No but somebody else do it (linux, gnome). So what > > > is the point ? > >=20 > > Oh! Then it's hard to explain. Let me say it this > > way, the abstraction level is too low. > >=20 > > >>>> So there is "some" millions C lines project. C++ > > are a quite bad design OO language but if you > > restrict your self to a sub set of it it could be > > great. > > SystemC are c++ class to rease the level of > > abstraction because it's runnable you must be enought > > precise.=20 > > Which kind of concept do you want to be implemented > > in such language ? (my last year at university was > > made inside a laboratorie which try to design such > > kind of language, and todays SystemC are very close > > to what was espected)=20 >=20 > The problem is that with C you have an implementation > already. This means you have already translated from > the concept you had in mind. You strip information > about your design when you translate it to C and you > add 'noise'. >=20 > A good language would resemble the way of thinking of > mans brain regarding digital design. Therefore C isn't > a good language. Some problem solutions can be easily > formed with C, others are hard to implement. Most of > them are hard to check (time consuming) for correctness. >=20 > Simulation is a means to look at the same issue from > another point of view - you go to the outside of your > design and look how it reacts. Testvectors that are > defined also describe the design functionality. If you > have a 100% testvector coverage you wouldn't need the > source of the design any more - the testvectors would > do because they also completely define your design from > it's reactions. And they have to because you need them > to check the final chip. Oops, forget that writing here about complete definition. It's only true when you take a complete simulation as testvectors which is done fairly often. A 100% coverage should test every path inside the design to work as expected on LH and HL edges. Normally more things are checked in parallel in a single teststep to optimize the time to test. That's what those scanpath flipflops are for. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jan 11 17:23:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB86-0000ru-00 for ; Sat, 12 Jan 2002 00:30:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:30:34 +0100 (CET) Received: (qmail 24236 invoked by uid 0); 11 Jan 2002 16:50:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 11 Jan 2002 16:50:52 -0000 Received: by moria.seul.org (Postfix) id 863641467F6; Fri, 11 Jan 2002 11:50:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63F601467FD; Fri, 11 Jan 2002 11:50:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from raul.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 1928B1467F6 for ; Fri, 11 Jan 2002 11:50:52 -0500 (EST) Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by raul.munge.net (Postfix) with ESMTP id 4F84811538 for ; Fri, 11 Jan 2002 10:50:50 -0600 (CST) Received: from jetnet.ab.ca (gc-jet-214.jetnet.ab.ca [207.34.60.214] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA22226 for ; Fri, 11 Jan 2002 09:48:07 -0700 (MST) Message-ID: <3C3F117F.B29F68FE@jetnet.ab.ca> Date: Fri, 11 Jan 2002 09:23:27 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > It looks like someone should setup some compiler directive paper. > The more complex the compiler will get, the longer you will wait > for one to come that is capable of doing all this stuff. A new > processor is nothing without the compiler/debugger support. The > lastest example was one coming from Germany called Hyperstone > which got mixed size instruction length thus being able to not > have a pipeline stall at context switch with just a 2 word cache. Lets not to forget to write a Assembler too. :) -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jan 11 17:40:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB88-0000ru-00 for ; Sat, 12 Jan 2002 00:30:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:30:36 +0100 (CET) Received: (qmail 10821 invoked by uid 0); 11 Jan 2002 17:04:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 11 Jan 2002 17:04:57 -0000 Received: by moria.seul.org (Postfix) id E23C41467F6; Fri, 11 Jan 2002 12:04:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C49951467FD; Fri, 11 Jan 2002 12:04:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id ED1631467F6 for ; Fri, 11 Jan 2002 12:04:54 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-214.jetnet.ab.ca [207.34.60.214] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA22884 for ; Fri, 11 Jan 2002 10:04:53 -0700 (MST) Message-ID: <3C3F156E.DBE857C3@jetnet.ab.ca> Date: Fri, 11 Jan 2002 09:40:14 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" References: <200201110920.1cca@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicolas.boulay@ifrance.com wrote: > >>>>>>Maybe you should read about F21. It's a > complete assynchonous design. It run at 2 ns for a > cycle for a 0.8um technology. It doesn't use neither > double rail logic nor hand checking. I was in contact > with one of the guy from the team who write it. But > i don't know how they time there cpu. > nicO Hmm A Forth machine pops back up again? .8um how fast is that? How many real gates in the pipeline. This includes the gates in the pipeline flipflops. How is the logic partitioned. What is the architecture? What is the latency? In 2 ns what the % of gate delay time, transmission time % and fixed overhead like clock skew %? What logic is used - bipolar, nmos , cmos , ecl , tube? Yes tubes could make a comeback for tiny structures. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jan 11 20:23:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB8M-0000ru-00 for ; Sat, 12 Jan 2002 00:30:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:30:50 +0100 (CET) Received: (qmail 22004 invoked by uid 0); 11 Jan 2002 19:23:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jan 2002 19:23:09 -0000 Received: by moria.seul.org (Postfix) id 073911462FD; Fri, 11 Jan 2002 14:23:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA1FC1467F4; Fri, 11 Jan 2002 14:23:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id C5D401462FD for ; Fri, 11 Jan 2002 14:23:05 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id VAA05098 for ; Fri, 11 Jan 2002 21:23:04 +0200 Date: Fri, 11 Jan 2002 21:23:04 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: <3C3E5072.19E70B21@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Humm :D Juste one question, are you a quite young designer with 5 or 10 > years of experiences, no ? Yes, but I have seen few very big projects already from the ASIC side:) > The typical design is made more or less as follow : > - specification : mainly with hand and paper > - then design partition hard/soft > - then you start to code the HW > - and then the SW (but you could start the soft ware more or less in the > same time and the following funny point is the merge ;) Yes that is the flow I was trying to explain. All projects I have seen have been like this. I have been in tfew projects that described ASIC at behavioral level and I think that took quite big amount of resources. That helped verification but not the whole process. > Codesign aren't only simulated SW with HW, it's a way of design. The > idea is to clearly describe your specification. Formal language are the > best for that because it will proove some properties. Todays tool's > maker try to implement "runnable specification". SystemC is born with > that idea in mind. I think the problem is how to describe the system. Think about a system that has tens of thousands of pages of text describing the functionality. It is not easy to describe system like that with any description language. In what phase can you start real HW implementation? I think it is quite futuristic still to think that you can create some working HW from very high level system descriptions. Todays tools are very far from that. Even simple behavioral synthesis didn't really work (Synopsys BC). And if you have read SystemC for example at RTL level it is very ugly. Even ABEL is easier to read :) > So you try to push the SW/HW split as far as you can to find the best > cut. So you avoid redesign or late problem. It's well know that later a > problem is found, more costly it is. I have even read that cost are 10x > at each level. I don't think system description languages really help the HW/SW interface. It still needs much manual labor and talented SW and HW guys fighting what should be done in each side. SW and HW people just have so different way of thinking the solutions. What is easy in SW might be impossible in HW and other way around. I don't really see how automatic tools could have more kowledge than humans in that work phase. I have not seen any real benefits from SystemC style design and I have tried to find them. And many other designers have not found the benefits either (read for example deepchip.com). Of course I hope that someone founds the silver bullet to speed up the design, but I don't think it has been found yet, > So, by using SystemC, you are supposed to win a lot of time, the feed > back are quicker and much more efficient. That is the theoretical view. But is it really true. At least I think it is not. I'd like to see real examples how time was really spared and talk to engineers that managed to do that. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jan 11 20:37:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB8P-0000ru-00 for ; Sat, 12 Jan 2002 00:30:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:30:53 +0100 (CET) Received: (qmail 660 invoked by uid 0); 11 Jan 2002 19:37:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 11 Jan 2002 19:37:27 -0000 Received: by moria.seul.org (Postfix) id E45221467E9; Fri, 11 Jan 2002 14:37:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCB271467F6; Fri, 11 Jan 2002 14:37:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id CA2711467E9 for ; Fri, 11 Jan 2002 14:37:25 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id VAA05378 for ; Fri, 11 Jan 2002 21:37:25 +0200 Date: Fri, 11 Jan 2002 21:37:25 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I rather have the opinion that after the chip is ready and the > software starts to use it the problems show up - 2 years lost. > And imagine - who can spend more than 2 years time to market? If that happens then there is something wrong in the organization. The normal way to work succesfully is to have SW people in ASIC design reviews to give input how they would want the interface. "Half" of my job currently is to discuss with SW guys about ASIC configuration and pinpoint their needs also. If they have good suggestions that are easy to do then they should be part of the ASIC. If the interface fails, I think it usually pinpoints problems in the communication between USW and HW. > After 2 years time the premiss may have changed completely. > Some ASICs were cancelled right when they were finished and > working. Cancellation might not mean that HW/SW interface is bad. It might mean that the whole product is not needed. The world needed other things than what was an edugated guess from the upper level management. Products are always gambling, not all of them succeed. I think it is better to cancel product if there is no need for it. > Why use more time? If one has HW quirks either the definition > was sh.. or one has overlooked something fundamental or one > tried to save time from simulation (pressing schedule). > And - and that is my biggest concern - one didn't know how > the software will use the interface later. If HW side doesn=E4t know how SW wants to use the chip then there is a problem in communication. Company like that can't survive, you can't fix that with new description language. I'm verification guy and at least in my projects we try to verify the interfaces SW wants to use and in the same way SW uses the interfaces. But my team uses advanced OO verification tools to write test benches that are quite comples, more like SW. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jan 11 20:42:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB8R-0000ru-00 for ; Sat, 12 Jan 2002 00:30:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:30:55 +0100 (CET) Received: (qmail 28777 invoked by uid 0); 11 Jan 2002 19:42:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 11 Jan 2002 19:42:27 -0000 Received: by moria.seul.org (Postfix) id BA6F81467F6; Fri, 11 Jan 2002 14:42:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD5511467FC; Fri, 11 Jan 2002 14:42:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id BA9961467F6 for ; Fri, 11 Jan 2002 14:42:26 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id VAA05507 for ; Fri, 11 Jan 2002 21:42:26 +0200 Date: Fri, 11 Jan 2002 21:42:26 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] Codesign and SystemC In-Reply-To: <200201110903.39b5@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > SystemC are C++ so your could always start to write > things in pure software style and then you refine > your model to have working hardware (after split) (an > other advantage is the speed 1000 x quicker than VHDL > simulation !) But when you add notion of time and concurrent execution to systemC then the simulation speed dramatically drops. The experiences I have heard is that the simulation speed is comparable to normal RTl tools. And I think that is the level where the simulation bottleneck really is. If you change the abstraction level you have to verify each abstraction level. I have not seen any formal tools that verify that higher level SystemC description matches with lower level description. If you have tool like that and it works with 5M gate designs then I'm interested :) --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 11 19:55:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PB8c-0000ru-00 for ; Sat, 12 Jan 2002 00:31:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 00:31:06 +0100 (CET) Received: (qmail 30745 invoked by uid 0); 11 Jan 2002 22:59:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 11 Jan 2002 22:59:22 -0000 Received: by moria.seul.org (Postfix) id E2EE61467FE; Fri, 11 Jan 2002 17:59:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2B70146808; Fri, 11 Jan 2002 17:59:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a148.home.uni-hannover.de [130.75.232.148]) by moria.seul.org (Postfix) with ESMTP id 39AE31467FE for ; Fri, 11 Jan 2002 17:59:20 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00771; Fri, 11 Jan 2002 19:55:27 +0100 Message-ID: <20020111195527.63412@thrai.stud.uni-hannover.de> Date: Fri, 11 Jan 2002 19:55:27 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: <3C3F117F.B29F68FE@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C3F117F.B29F68FE@jetnet.ab.ca>; from Ben Franchuk on Fri, Jan 11, 2002 at 09:23:27AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jan 11, 2002 at 09:23:27AM -0700, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > > It looks like someone should setup some compiler directive paper. > > The more complex the compiler will get, the longer you will wait > > for one to come that is capable of doing all this stuff. A new > > processor is nothing without the compiler/debugger support. The > > lastest example was one coming from Germany called Hyperstone > > which got mixed size instruction length thus being able to not > > have a pipeline stall at context switch with just a 2 word cache. > > Lets not to forget to write a Assembler too. :) I posted a semi-complete Unix-style assembler four months ago, and Yann was working on another one. I also started writing a simulator (for assembler testing and instruction set re-evaluation), but I was interrupted by other things :( -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jan 11 21:56:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PNTj-0000EP-00 for ; Sat, 12 Jan 2002 13:41:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 13:41:43 +0100 (CET) Received: (qmail 29638 invoked by uid 0); 11 Jan 2002 23:09:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 11 Jan 2002 23:09:23 -0000 Received: by moria.seul.org (Postfix) id 1F0521467FA; Fri, 11 Jan 2002 18:09:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E6B04146804; Fri, 11 Jan 2002 18:09:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 1C9211467FA for ; Fri, 11 Jan 2002 18:09:21 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-199.jetnet.ab.ca [207.34.60.199]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA10114 for ; Fri, 11 Jan 2002 16:09:19 -0700 (MST) Message-ID: <3C3F5160.3FACD680@jetnet.ab.ca> Date: Fri, 11 Jan 2002 13:56:00 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: <3C3F117F.B29F68FE@jetnet.ab.ca> <20020111195527.63412@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > I posted a semi-complete Unix-style assembler four months ago, and > Yann was working on another one. I also started writing a simulator > (for assembler testing and instruction set re-evaluation), but I was > interrupted by other things :( What is a Unix-style assembler? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Jan 12 09:33:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PNTw-0000EP-00 for ; Sat, 12 Jan 2002 13:41:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 13:41:56 +0100 (CET) Received: (qmail 29725 invoked by uid 0); 12 Jan 2002 08:31:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Jan 2002 08:31:52 -0000 Received: by moria.seul.org (Postfix) id 4ACA314680A; Sat, 12 Jan 2002 03:31:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3AD3914680C; Sat, 12 Jan 2002 03:31:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 6769A14680A for ; Sat, 12 Jan 2002 03:31:50 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16PJbd-0006O7-00 for f-cpu@seul.org; Sat, 12 Jan 2002 09:33:37 +0100 Date: Sat, 12 Jan 2002 09:33:37 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Codesign and SystemC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002, Kim Enkovaara wrote: > If you have tool like that and it works with 5M gate designs then I'm > interested :) Only a real cluster implementation could improve it. But that is distributed system thinking and you hardly find any guys who can design real distributed systems. And I am not talking of the master type distributed systems like CORBA or client/server which are basically trivial. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Jan 12 09:29:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PNTw-0000EP-01 for ; Sat, 12 Jan 2002 13:41:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 13:41:56 +0100 (CET) Received: (qmail 30087 invoked by uid 0); 12 Jan 2002 08:31:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Jan 2002 08:31:54 -0000 Received: by moria.seul.org (Postfix) id 9DA2314680C; Sat, 12 Jan 2002 03:31:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D6C614680E; Sat, 12 Jan 2002 03:31:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 19F1C14680C for ; Sat, 12 Jan 2002 03:31:53 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16PJY6-0006O5-00 for f-cpu@seul.org; Sat, 12 Jan 2002 09:29:58 +0100 Date: Sat, 12 Jan 2002 09:29:58 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 11 Jan 2002, Kim Enkovaara wrote: > > I rather have the opinion that after the chip is ready and the > > software starts to use it the problems show up - 2 years lost. > > And imagine - who can spend more than 2 years time to market? >=20 > If that happens then there is something wrong in the organization. The > normal way to work succesfully is to have SW people in ASIC design review= s > to give input how they would want the interface. "Half" of my job > currently is to discuss with SW guys about ASIC configuration and pinpoin= t > their needs also. If they have good suggestions that are easy to do then > they should be part of the ASIC. If the interface fails, I think it > usually pinpoints problems in the communication between USW and HW. >=20 > > After 2 years time the premiss may have changed completely. > > Some ASICs were cancelled right when they were finished and > > working. >=20 > Cancellation might not mean that HW/SW interface is bad. It might mean > that the whole product is not needed. The world needed other things > than what was an edugated guess from the upper level management. Products > are always gambling, not all of them succeed. I think it is better to > cancel product if there is no need for it. >=20 > > Why use more time? If one has HW quirks either the definition > > was sh.. or one has overlooked something fundamental or one > > tried to save time from simulation (pressing schedule). > > And - and that is my biggest concern - one didn't know how > > the software will use the interface later. >=20 > If HW side doesn=E4t know how SW wants to use the chip then there is a > problem in communication. Company like that can't survive, you can't fix > that with new description language. I'm verification guy and at least in > my projects we try to verify the interfaces SW wants to use and in the > same way SW uses the interfaces. But my team uses advanced OO > verification tools to write test benches that are quite comples, more lik= e > SW. I have seldom read an answer which is so true! There are lots of communication problems between HW and SW. Only few of the companies I worked for didn't have them. There always seemed to be that ravine between hardware and software thinking and talking. Somehow I was always standing in the middle - building the bridge - taking a look at the problem and finding the source of it. But neither software guys nor hardware guys were happy about the solution when the cause was on their side. They didn't really work together. And that's exactly what I mean, hardware and software guys aren't usually building ONE team. They are foolishly divided into company divisions in all big companies (that I worked for). This produces a concurrency where you don't need it at all. I hope this is better within your company. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 12 02:21:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PSXA-0003ey-00 for ; Sat, 12 Jan 2002 19:05:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 12 Jan 2002 19:05:36 +0100 (CET) Received: (qmail 6886 invoked by uid 0); 12 Jan 2002 12:51:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 12 Jan 2002 12:51:17 -0000 Received: by moria.seul.org (Postfix) id 27D7D1467F4; Sat, 12 Jan 2002 07:51:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A6B71467F7; Sat, 12 Jan 2002 07:51:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a103.home.uni-hannover.de [130.75.232.103]) by moria.seul.org (Postfix) with ESMTP id A02AD1467F4 for ; Sat, 12 Jan 2002 07:51:15 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01844; Sat, 12 Jan 2002 02:21:21 +0100 Message-ID: <20020112022121.61730@thrai.stud.uni-hannover.de> Date: Sat, 12 Jan 2002 02:21:21 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: <3C3F117F.B29F68FE@jetnet.ab.ca> <20020111195527.63412@thrai.stud.uni-hannover.de> <3C3F5160.3FACD680@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C3F5160.3FACD680@jetnet.ab.ca>; from Ben Franchuk on Fri, Jan 11, 2002 at 01:56:00PM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jan 11, 2002 at 01:56:00PM -0700, Ben Franchuk wrote: > Michael Riepe wrote: > > > I posted a semi-complete Unix-style assembler four months ago, and > > Yann was working on another one. I also started writing a simulator > > (for assembler testing and instruction set re-evaluation), but I was > > interrupted by other things :( > > What is a Unix-style assembler? It uses a similar syntax (all pseudo-ops begin with a dot, e.g. .org or .fill), supports the usual segments (.text/.data/.bss) and so on. Output files are in relocatable format. They can't be executed directly, but are supposed to be linked/relocated with ld(1) first. It's pretty much like GNU as, in case you know that (part of the binutils package nowadays). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 12 20:09:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PjMw-0000Fs-00 for ; Sun, 13 Jan 2002 13:04:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 13 Jan 2002 13:04:10 +0100 (CET) Received: (qmail 11435 invoked by uid 0); 12 Jan 2002 19:05:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 12 Jan 2002 19:05:38 -0000 Received: by moria.seul.org (Postfix) id 557F91467F2; Sat, 12 Jan 2002 14:05:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 465F21467F7; Sat, 12 Jan 2002 14:05:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E20B31467F2 for ; Sat, 12 Jan 2002 14:05:36 -0500 (EST) Received: from f-cpu.org (kdl21-32.n.club-internet.fr [213.44.96.32]) by relay-2v.club-internet.fr (Postfix) with ESMTP id D63091811 for ; Sat, 12 Jan 2002 20:05:33 +0100 (CET) Message-ID: <3C4089D9.D96BB7CD@f-cpu.org> Date: Sat, 12 Jan 2002 20:09:13 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: <3C3F117F.B29F68FE@jetnet.ab.ca> <20020111195527.63412@thrai.stud.uni-hannover.de> <3C3F5160.3FACD680@jetnet.ab.ca> <20020112022121.61730@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Fri, Jan 11, 2002 at 01:56:00PM -0700, Ben Franchuk wrote: > > What is a Unix-style assembler? > It uses a similar syntax (all pseudo-ops begin with a dot, e.g. .org > or .fill), supports the usual segments (.text/.data/.bss) and so on. > Output files are in relocatable format. They can't be executed directly, > but are supposed to be linked/relocated with ld(1) first. It's pretty > much like GNU as, in case you know that (part of the binutils package > nowadays). in short : the kind of asm that is not easy to read or write and requires a handful of tools to make it work ;-) i belong to the crowd of people who use(d) NASM and couldn't use anything else afterwards, because it's so much more practical and readable than (g)as or TASM/MASM. No loader, no linker, plain binary output that doesn't require extra handling when you want to test an execution unit in VHDL... (i don't imagine Michael willing to program an ELF loader in VHDL :-P). Instead of segments, files are included (either binary or source). And i have even "programmed" a EXE file header (look at the contributors in the NASM package). Maybe that, given the spec, it would be possible to write an ELF header in asm syntax. Given a few symbolic and labelling capabilities, such as what i have already programmed in ygasm, i don't see the problem (unless ELF requires more sophisticated computations than just label manipulations ?) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jan 13 01:17:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PjN4-0000Fs-01 for ; Sun, 13 Jan 2002 13:04:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 13 Jan 2002 13:04:18 +0100 (CET) Received: (qmail 25927 invoked by uid 0); 13 Jan 2002 00:17:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 13 Jan 2002 00:17:28 -0000 Received: by moria.seul.org (Postfix) id EB0561467FA; Sat, 12 Jan 2002 19:17:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C989B1467FD; Sat, 12 Jan 2002 19:17:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a140.home.uni-hannover.de [130.75.232.140]) by moria.seul.org (Postfix) with ESMTP id 09EEB1467FA for ; Sat, 12 Jan 2002 19:17:24 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA08508; Sun, 13 Jan 2002 01:17:22 +0100 Message-ID: <20020113011722.09204@thrai.stud.uni-hannover.de> Date: Sun, 13 Jan 2002 01:17:22 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] LSU or cache L0 References: <3C3F117F.B29F68FE@jetnet.ab.ca> <20020111195527.63412@thrai.stud.uni-hannover.de> <3C3F5160.3FACD680@jetnet.ab.ca> <20020112022121.61730@thrai.stud.uni-hannover.de> <3C4089D9.D96BB7CD@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C4089D9.D96BB7CD@f-cpu.org>; from Yann Guidon on Sat, Jan 12, 2002 at 08:09:13PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jan 12, 2002 at 08:09:13PM +0100, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > On Fri, Jan 11, 2002 at 01:56:00PM -0700, Ben Franchuk wrote: > > > What is a Unix-style assembler? > > It uses a similar syntax (all pseudo-ops begin with a dot, e.g. .org > > or .fill), supports the usual segments (.text/.data/.bss) and so on. > > Output files are in relocatable format. They can't be executed directly, > > but are supposed to be linked/relocated with ld(1) first. It's pretty > > much like GNU as, in case you know that (part of the binutils package > > nowadays). > > in short : the kind of asm that is not easy to read or write > and requires a handful of tools to make it work ;-) Yes... and it's the kind of assembler we need to port Linux. > i belong to the crowd of people who use(d) NASM and couldn't use anything > else afterwards, because it's so much more practical and readable than > (g)as or TASM/MASM. No loader, no linker, plain binary output > that doesn't require extra handling when you want to test an execution > unit in VHDL... (i don't imagine Michael willing to program an ELF > loader in VHDL :-P). Instead of segments, files are included (either > binary or source). And i have even "programmed" a EXE file header > (look at the contributors in the NASM package). I've been using several versions of masm, tasm, as86, gas, and nasm. So what? No I'm not going to write an ELF loader in VHDL. I'll write a linker in C :) > Maybe that, given the spec, it would be possible to write an ELF > header in asm syntax. Given a few symbolic and labelling capabilities, > such as what i have already programmed in ygasm, i don't see the problem > (unless ELF requires more sophisticated computations than just label > manipulations ?) Nothing special. But it's a pretty big piece of work to build all the ELF structures manually. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jan 14 04:56:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PvRh-0004pm-00 for ; Mon, 14 Jan 2002 01:57:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 14 Jan 2002 01:57:53 +0100 (CET) Received: (qmail 19655 invoked by uid 0); 13 Jan 2002 21:53:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Jan 2002 21:53:33 -0000 Received: by moria.seul.org (Postfix) id CD8B114686F; Sun, 13 Jan 2002 16:53:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B03B3146873; Sun, 13 Jan 2002 16:53:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E78BB14686F for ; Sun, 13 Jan 2002 16:53:29 -0500 (EST) Received: from ifrance.com (vlt11-219.n.club-internet.fr [195.36.224.219]) by relay-1v.club-internet.fr (Postfix) with ESMTP id CA96816AB for ; Sun, 13 Jan 2002 22:53:26 +0100 (CET) Message-ID: <3C4256EA.1A61CBC@ifrance.com> Date: Sun, 13 Jan 2002 22:56:26 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:Rep:Re: [f-cpu] "Tree" References: <200201110920.1cca@th00.opsion.fr> <3C3F156E.DBE857C3@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > nicolas.boulay@ifrance.com wrote: > > > >>>>>>Maybe you should read about F21. It's a > > complete assynchonous design. It run at 2 ns for a > > cycle for a 0.8um technology. It doesn't use neither > > double rail logic nor hand checking. I was in contact > > with one of the guy from the team who write it. But > > i don't know how they time there cpu. > > nicO > > Hmm A Forth machine pops back up again? > .8um how fast is that? How many real gates in the pipeline. > This includes the gates in the pipeline flipflops. > How is the logic partitioned. What is the architecture? > What is the latency? In 2 ns what the % of gate delay time, > transmission time % and fixed overhead like clock skew %? > What logic is used - bipolar, nmos , cmos , ecl , tube? > Yes tubes could make a comeback for tiny structures. it was 0.8 um CMOS process. There is no flipflop nether pipeline : it's fully asynchronous ! To be more precise the adder take 4 "slot" time. That's why i give the period time and not the frequency : because there is no clock ! > > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jan 14 05:04:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16PvRh-0004pm-01 for ; Mon, 14 Jan 2002 01:57:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 14 Jan 2002 01:57:53 +0100 (CET) Received: (qmail 4851 invoked by uid 0); 13 Jan 2002 22:01:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 13 Jan 2002 22:01:40 -0000 Received: by moria.seul.org (Postfix) id 51082146872; Sun, 13 Jan 2002 17:01:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B340146874; Sun, 13 Jan 2002 17:01:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E3375146872 for ; Sun, 13 Jan 2002 17:01:38 -0500 (EST) Received: from ifrance.com (vlt11-219.n.club-internet.fr [195.36.224.219]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 829CF16AA for ; Sun, 13 Jan 2002 23:01:35 +0100 (CET) Message-ID: <3C4258D2.9AC57F50@ifrance.com> Date: Sun, 13 Jan 2002 23:04:34 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Codesign flow and systemC References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara a écrit : > > > Humm :D Juste one question, are you a quite young designer with 5 or 10 > > years of experiences, no ? > > Yes, but I have seen few very big projects already from the ASIC side:) > > > The typical design is made more or less as follow : > > - specification : mainly with hand and paper > > - then design partition hard/soft > > - then you start to code the HW > > - and then the SW (but you could start the soft ware more or less in the > > same time and the following funny point is the merge ;) > > Yes that is the flow I was trying to explain. All projects I have seen > have been like this. I have been in tfew projects that described ASIC at > behavioral level and I think that took quite big amount of resources. That > helped verification but not the whole process. > > > Codesign aren't only simulated SW with HW, it's a way of design. The > > idea is to clearly describe your specification. Formal language are the > > best for that because it will proove some properties. Todays tool's > > maker try to implement "runnable specification". SystemC is born with > > that idea in mind. > > I think the problem is how to describe the system. Think about a system > that has tens of thousands of pages of text describing the functionality. > It is not easy to describe system like that with any description language. > In what phase can you start real HW implementation? I think it is quite > futuristic still to think that you can create some working HW from very > high level system descriptions. Todays tools are very far from that. Even > simple behavioral synthesis didn't really work (Synopsys BC). > > And if you have read SystemC for example at RTL level it is very ugly. > Even ABEL is easier to read :) > Sur ! But look at SystemC 2.0 it's far more interresting than SystemC 1.0 (which is purely horrible VHDL in C) > > So you try to push the SW/HW split as far as you can to find the best > > cut. So you avoid redesign or late problem. It's well know that later a > > problem is found, more costly it is. I have even read that cost are 10x > > at each level. > > I don't think system description languages really help the HW/SW > interface. It still needs much manual labor and talented SW and HW guys > fighting what should be done in each side. SW and HW people just have so > different way of thinking the solutions. What is easy in SW might be > impossible in HW and other way around. I don't really see how automatic > tools could have more kowledge than humans in that work phase. I have not > seen any real benefits from SystemC style design and I have tried to find > them. And many other designers have not found the benefits either (read > for example deepchip.com). > > Of course I hope that someone founds the silver bullet to speed up the > design, but I don't think it has been found yet, > The code written in SystemC (or what ever language of that level : Esterel, SDL, ...). You always describe communication channel, object, interface, port and so on. All that could be software or hardware : it's only task to do. So with such "high level" language, you start very soon to code, much bevore specification are stable. So you could reach problem much faster, and redefined thing earlier. SystemC could not make the split HW/SW but help the designer to do it. There is "some" architecture explorer tools in the market to help to do that. > > So, by using SystemC, you are supposed to win a lot of time, the feed > > back are quicker and much more efficient. > > That is the theoretical view. But is it really true. At least I think it > is not. I'd like to see real examples how time was really spared and talk > to engineers that managed to do that. > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From guidon@messiaen.lip6.fr Thu Jan 17 22:43:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgez-0004Vp-00 for ; Fri, 18 Jan 2002 22:34:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:34:53 +0100 (CET) Received: (qmail 17183 invoked by uid 0); 17 Jan 2002 21:43:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 17 Jan 2002 21:43:50 -0000 Received: by moria.seul.org (Postfix) id AC6251467EF; Thu, 17 Jan 2002 16:43:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BD9814681C; Thu, 17 Jan 2002 16:43:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by moria.seul.org (Postfix) with ESMTP id 16A5A1467EF for ; Thu, 17 Jan 2002 16:43:49 -0500 (EST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g0HLhikB007885 ; Thu, 17 Jan 2002 22:43:44 +0100 X-pt: isis.lip6.fr Received: from enseig.lip6.fr (enseig.lip6.fr [132.227.67.130]) by asim.lip6.fr (8.11.3nb1/8.11.0) with ESMTP id g0HLhit17263; Thu, 17 Jan 2002 22:43:44 +0100 (MET) Received: from anerio.lip6.fr (anerio.lip6.fr [132.227.67.72]) by enseig.lip6.fr (8.9.3+Sun/8.9.3) with ESMTP id WAA18120; Thu, 17 Jan 2002 22:43:44 +0100 (MET) From: "Yann Guidon [systeme]" Received: (from guidon@localhost) by anerio.lip6.fr (8.11.6/8.9.3) id g0HLhib17086; Thu, 17 Jan 2002 22:43:44 +0100 Date: Thu, 17 Jan 2002 22:43:44 +0100 Message-Id: <200201172143.g0HLhib17086@anerio.lip6.fr> To: f-cpu@seul.org Subject: [f-cpu] Use of VCI for F-CPU core Cc: whygee@f-cpu.org Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The VCI interface protocol is defined by the VSI Alliance (vsi.org). I am investigating whether it can be used in the frame of F-CPU. Why not Wishbone ? Could be, but VCI is very simple and does not define a bus or whatever, just the interface. Exactly what is needed to define a core, without caring for the fine prints of the reference manuals. I like VCI to the same point i dislike PCI. VSIA membership for individuals seems to be free. It is the way to obtain the VSI documents/specs. My university is already registered so i already got the VCI spec for my diplom's work of this year. Non-individual membership is at least $1000 so (unless the VSIA board makes an exception) we can't subscribe the F-CPU team as a group. http://www.vsi.org/library/specs/deliver011502.pdf in the last pages, it describes the compliance claim conditions which seem to be fair. The VCI documents seem to be available free of charge (but after heavy subscription), a few people in F-CPUland can get them and write GPL'd source code that can be reused by other people free of charge (i'm still investigating however). Note : The goal of VCI is to determine an interface, completely independently from the interconnexion with other parts. This point-to-point definition avoids any allocation/grant/sharing stuff, which is a good reason why i like it. Then, making "bridges" for other specifications is rather easy (a bridge to Wishbone or AMBA is left as exercise for those who want to train themselves). Although the VSI owns a little restrictive copyright on the spec, nothing keeps one to document the code and describe the protocol. Hints and discussion welcome YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From guidon@messiaen.lip6.fr Thu Jan 17 22:56:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgf1-0004Vp-00 for ; Fri, 18 Jan 2002 22:34:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:34:55 +0100 (CET) Received: (qmail 8817 invoked by uid 0); 17 Jan 2002 21:56:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 17 Jan 2002 21:56:50 -0000 Received: by moria.seul.org (Postfix) id 9642B14681D; Thu, 17 Jan 2002 16:56:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B632146827; Thu, 17 Jan 2002 16:56:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by moria.seul.org (Postfix) with ESMTP id 00EDC14681D for ; Thu, 17 Jan 2002 16:56:49 -0500 (EST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g0HLulkB008100 ; Thu, 17 Jan 2002 22:56:48 +0100 X-pt: isis.lip6.fr Received: from enseig.lip6.fr (enseig.lip6.fr [132.227.67.130]) by asim.lip6.fr (8.11.3nb1/8.11.0) with ESMTP id g0HLult17933; Thu, 17 Jan 2002 22:56:47 +0100 (MET) Received: from anerio.lip6.fr (anerio.lip6.fr [132.227.67.72]) by enseig.lip6.fr (8.9.3+Sun/8.9.3) with ESMTP id WAA19254; Thu, 17 Jan 2002 22:56:47 +0100 (MET) From: "Yann Guidon [systeme]" Received: (from guidon@localhost) by anerio.lip6.fr (8.11.6/8.9.3) id g0HLulU17498; Thu, 17 Jan 2002 22:56:47 +0100 Date: Thu, 17 Jan 2002 22:56:47 +0100 Message-Id: <200201172156.g0HLulU17498@anerio.lip6.fr> To: f-cpu@seul.org Subject: [f-cpu] PS Cc: whygee@f-cpu.org Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Looks like we'll need a separate, low-latency and simple protocol for both interrupts and semaphores. Something located in an independent address space (if any), with no caching quirks and which communicates almost directly (but point-to-point) with other cores. That's not difficult to do but i have to make sure this doesn't already exist. The VCI stuff is more important now because the memory interface must be designed, the IRQ and semaphore machinery is to be designed a bit later. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jan 17 20:34:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgf2-0004Vp-00 for ; Fri, 18 Jan 2002 22:34:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:34:56 +0100 (CET) Received: (qmail 23905 invoked by uid 0); 17 Jan 2002 22:22:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 17 Jan 2002 22:22:11 -0000 Received: by moria.seul.org (Postfix) id 31F48146859; Thu, 17 Jan 2002 17:22:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2DFF314687D; Thu, 17 Jan 2002 17:22:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 95069146859 for ; Thu, 17 Jan 2002 17:22:09 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA04477 for ; Thu, 17 Jan 2002 15:22:04 -0700 (MST) Message-ID: <3C47272E.483E4A0E@jetnet.ab.ca> Date: Thu, 17 Jan 2002 12:34:06 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PS References: <200201172156.g0HLulU17498@anerio.lip6.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "Yann Guidon [systeme]" wrote: > > Looks like we'll need a separate, low-latency and simple protocol for both interrupts and semaphores. > Something located in an independent address space (if any), with no caching quirks and which communicates > almost directly (but point-to-point) with other cores. That's not difficult to do but i have to make sure > this doesn't already exist. The VCI stuff is more important now because the memory interface must > be designed, the IRQ and semaphore machinery is to be designed a bit later. But would not the memory interface still need to be partially defined as semaphores are atomic functions? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 18 01:00:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgf3-0004Vp-00 for ; Fri, 18 Jan 2002 22:34:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:34:57 +0100 (CET) Received: (qmail 648 invoked by uid 0); 18 Jan 2002 00:00:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 18 Jan 2002 00:00:40 -0000 Received: by moria.seul.org (Postfix) id 27E0714687F; Thu, 17 Jan 2002 19:00:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 228F214687D; Thu, 17 Jan 2002 19:00:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id D1A65146811 for ; Thu, 17 Jan 2002 19:00:37 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01015; Fri, 18 Jan 2002 01:00:31 +0100 Message-ID: <20020118010031.40806@thrai.stud.uni-hannover.de> Date: Fri, 18 Jan 2002 01:00:31 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Use of VCI for F-CPU core References: <200201172143.g0HLhib17086@anerio.lip6.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200201172143.g0HLhib17086@anerio.lip6.fr>; from Yann Guidon [systeme] on Thu, Jan 17, 2002 at 10:43:44PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jan 17, 2002 at 10:43:44PM +0100, Yann Guidon [systeme] wrote: > The VCI interface protocol is defined by the VSI Alliance (vsi.org). > I am investigating whether it can be used in the frame > of F-CPU. Why not Wishbone ? Could be, but VCI > is very simple and does not define a bus or whatever, just the interface. > Exactly what is needed to define a core, without caring for the fine prints > of the reference manuals. I like VCI to the same point i dislike PCI. It has its quirks, though. An asynchronous VAL/ACK cycle seems to be pretty unreliable -- you never know whether the ACK arrives in time --, while synchronous handshakes are slow (2 cycles per cell). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 18 01:57:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16RgfC-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:06 +0100 (CET) Received: (qmail 23254 invoked by uid 0); 18 Jan 2002 00:53:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 18 Jan 2002 00:53:30 -0000 Received: by moria.seul.org (Postfix) id 7E9F4146881; Thu, 17 Jan 2002 19:53:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B35D14687D; Thu, 17 Jan 2002 19:53:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4837E14681A for ; Thu, 17 Jan 2002 19:53:29 -0500 (EST) Received: from f-cpu.org (kdl16-14.n.club-internet.fr [213.44.18.14]) by relay-3v.club-internet.fr (Postfix) with ESMTP id A595216F7 for ; Fri, 18 Jan 2002 01:53:26 +0100 (CET) Message-ID: <3C4772EF.84214BAC@f-cpu.org> Date: Fri, 18 Jan 2002 01:57:19 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PS References: <200201172156.g0HLulU17498@anerio.lip6.fr> <3C47272E.483E4A0E@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Ben Franchuk wrote: > "Yann Guidon [systeme]" wrote: > > Looks like we'll need a separate, low-latency and > > simple protocol for both interrupts and semaphores. > > Something located in an independent address space > > (if any), with no caching quirks and which communicates > > almost directly (but point-to-point) with other cores. > > That's not difficult to do but i have to make sure > > this doesn't already exist. The VCI stuff is more > > important now because the memory interface must > > be designed, the IRQ and semaphore machinery is > > to be designed a bit later. > But would not the memory interface > still need to be partially defined > as semaphores are atomic functions? I am not sure to fully understand your question but i presume that you mean that semaphores are locked load/store instructions. This would break all the underlying machine which is designed for managing 256-bit words (both for the instructions and normal data) with up to 16 simultaneous transactions. If you want to use a semaphore, you force all the system to work with blocking, atomic transactions and the system is almost stalling. >From that point of view, it is "better" to use a "blocking" instruction ["get" for requesting a semaphore and "put" for releasing it, all through the Special Register system] which will stop the execution pipeline only, and will leave the memory system work at full speed in parallel. Furthermore, the SR space allows us to freely define an implementation. For example, you can define that "get SR_SEMAPHORE, rN" will ask the semaphore which number is SR_SEMAPHORE-SR_BASE, the yes/no flag (or a handle, or the semaphore's value) will be returned in register N. The instruction decoder will stall during a few cycles (all the instructions in the execution pipeline will complete in the background) and the result will be returned to the program without disturbing the L/S unit. This is "safe" because the get and put instructions are "safe" and "atomic" (they are the only ones that stop the decoder until completion so it is completely risk-free and scheduler-safe). You can also decide to simulate the semaphores in SW, so you give the SW a SR_BASE value which points to a forbidden range : when accessing the semaphore, the application will trap and the kernel can safely use implementation-dependent mechanisms (or go through memory stuff if you want). BTW i have already used semaphores in a dual CPU system and i can say that memory-mapped semaphores s*ck. Furthermore, the load/store unit, the fetcher unit, the cache memory and the rest are so much simpler when semaphores are not taken into account :-D good night everybody, > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From robfinch@sympatico.ca Fri Jan 18 05:43:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16RgfN-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:17 +0100 (CET) Received: (qmail 2056 invoked by uid 0); 18 Jan 2002 04:44:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 18 Jan 2002 04:44:46 -0000 Received: by moria.seul.org (Postfix) id 15FA114681E; Thu, 17 Jan 2002 23:44:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B9B5146866; Thu, 17 Jan 2002 23:44:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by moria.seul.org (Postfix) with ESMTP id B246914681E for ; Thu, 17 Jan 2002 23:44:45 -0500 (EST) Received: from birdcomputer ([65.92.33.209]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20020118044444.WLRA1750.tomts13-srv.bellnexxia.net@birdcomputer> for ; Thu, 17 Jan 2002 23:44:44 -0500 Message-ID: <001d01c19fda$9d64cb40$d1215c41@birdcomputer> From: "Rob Finch" To: References: <200201172156.g0HLulU17498@anerio.lip6.fr> <3C47272E.483E4A0E@jetnet.ab.ca> <3C4772EF.84214BAC@f-cpu.org> Subject: Re: [f-cpu] PS Date: Thu, 17 Jan 2002 23:43:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I've been following the F-CPU project for a few months now, I think it's an interesting idea. Anyway, regarding semaphores. Semaphores don't have to be implemented using atomic read-modify-write memory operations or blocking instructions. I believe there are software algorithms for handling semaphores for example, Dekker's algorithm. You can also implement semaphores using an address reservation system in hardware. An address reservation system is used in the PowerPC for example, and is my current favorite method. Rob http://www.birdcomputer.ca/ ----- Original Message ----- From: "Yann Guidon" To: Sent: Thursday, January 17, 2002 7:57 PM Subject: Re: [f-cpu] PS > hello, > > Ben Franchuk wrote: > > "Yann Guidon [systeme]" wrote: > > > Looks like we'll need a separate, low-latency and > > > simple protocol for both interrupts and semaphores. > > > Something located in an independent address space > > > (if any), with no caching quirks and which communicates > > > almost directly (but point-to-point) with other cores. > > > That's not difficult to do but i have to make sure > > > this doesn't already exist. The VCI stuff is more > > > important now because the memory interface must > > > be designed, the IRQ and semaphore machinery is > > > to be designed a bit later. > > But would not the memory interface > > still need to be partially defined > > as semaphores are atomic functions? > I am not sure to fully understand your question > but i presume that you mean that semaphores are > locked load/store instructions. This would break > all the underlying machine which is designed for > managing 256-bit words (both for the instructions > and normal data) with up to 16 simultaneous transactions. > If you want to use a semaphore, you force all the > system to work with blocking, atomic transactions > and the system is almost stalling. > > From that point of > view, it is "better" to use a "blocking" instruction > ["get" for requesting a semaphore and "put" for > releasing it, all through the Special Register system] > which will stop the execution pipeline only, and will > leave the memory system work at full speed in parallel. > Furthermore, the SR space allows us to freely define > an implementation. For example, you can define that > "get SR_SEMAPHORE, rN" will ask the semaphore which number > is SR_SEMAPHORE-SR_BASE, the yes/no flag (or a handle, > or the semaphore's value) will be returned in register N. > The instruction decoder will stall during a few cycles > (all the instructions in the execution pipeline will > complete in the background) and the result will be > returned to the program without disturbing the L/S unit. > This is "safe" because the get and put instructions > are "safe" and "atomic" (they are the only ones that > stop the decoder until completion so it is completely > risk-free and scheduler-safe). You can also decide to > simulate the semaphores in SW, so you give the SW a > SR_BASE value which points to a forbidden range : when > accessing the semaphore, the application will trap and > the kernel can safely use implementation-dependent > mechanisms (or go through memory stuff if you want). > > BTW i have already used semaphores in a dual CPU system > and i can say that memory-mapped semaphores s*ck. > > Furthermore, the load/store unit, the fetcher unit, the > cache memory and the rest are so much simpler when > semaphores are not taken into account :-D > > good night everybody, > > > Ben Franchuk - Dawn * 12/24 bit cpu * > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 18 02:24:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16RgfE-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:08 +0100 (CET) Received: (qmail 22749 invoked by uid 0); 18 Jan 2002 01:20:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 18 Jan 2002 01:20:36 -0000 Received: by moria.seul.org (Postfix) id 7B0CC14681A; Thu, 17 Jan 2002 20:20:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 774F0146885; Thu, 17 Jan 2002 20:20:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 41B8514681A for ; Thu, 17 Jan 2002 20:20:21 -0500 (EST) Received: from f-cpu.org (kdl21-6.n.club-internet.fr [213.44.96.6]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 537F71AB1 for ; Fri, 18 Jan 2002 02:20:18 +0100 (CET) Message-ID: <3C47793B.BB612B34@f-cpu.org> Date: Fri, 18 Jan 2002 02:24:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Use of VCI for F-CPU core References: <200201172143.g0HLhib17086@anerio.lip6.fr> <20020118010031.40806@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Thu, Jan 17, 2002 at 10:43:44PM +0100, Yann Guidon [systeme] wrote: > > The VCI interface protocol is defined by the VSI Alliance (vsi.org). > > I am investigating whether it can be used in the frame > > of F-CPU. Why not Wishbone ? Could be, but VCI > > is very simple and does not define a bus or whatever, just the interface. > > Exactly what is needed to define a core, without caring for the fine prints > > of the reference manuals. I like VCI to the same point i dislike PCI. > > It has its quirks, though. An asynchronous VAL/ACK cycle seems to be > pretty unreliable -- you never know whether the ACK arrives in time --, > while synchronous handshakes are slow (2 cycles per cell). VCI (any version) is fully synchronous. It is clearly specified in the documentation. As to whether it is slow, just consider that F-CPU is meant to run at a higher frequency than usual circuits. This can also involve crossing a clock domain. Although the minimum latency is 1 cycle, just consider that the addressed circuits will probably require much more cycles before they give an answer. This is where it becomes interesting (or awful depending on how you see it). While in "Peripheral VCI" (a VCI subset for dumb I/O for example) this is a limit, "Basic VCI" and "Advanced VCI" provide 4 bits for Transaction ID (a TID from 0 to 15) so the answers can come back in order or not, after a variable number of cycles. In a way, VCI's design makes the FC0's design easier, or if you prefer, it removes some burdens. I think i'll start with designing an interface that looks like VCI (but without the name, hehe ;-D, so people are not too disturbed). I'll then add the "VCI interface" (connector) and people can replace it with their own interface instead. If the desired interface does not exist (for example you want to plug an AMBA bus to the FC0 but there is no such connector ready), then you can use existing "wrappers" (ie a VCI/AMBA). At ASIME we write such bridges and that's pretty easy. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Jan 18 14:25:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgfs-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:48 +0100 (CET) Received: (qmail 11691 invoked by uid 0); 18 Jan 2002 13:23:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Jan 2002 13:23:30 -0000 Received: by moria.seul.org (Postfix) id C85AF146892; Fri, 18 Jan 2002 08:23:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C22E2146899; Fri, 18 Jan 2002 08:23:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf18bis.bellsouth.net (mail018.mail.bellsouth.net [205.152.58.38]) by moria.seul.org (Postfix) with ESMTP id 740B6146892 for ; Fri, 18 Jan 2002 08:23:29 -0500 (EST) Received: from computer ([209.215.24.58]) by imf18bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20020118132441.FLK23623.imf18bis.bellsouth.net@computer>; Fri, 18 Jan 2002 08:24:41 -0500 Message-ID: <003201c1a023$968b5de0$3a18d7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] ERIN32 Interrupt Handling Date: Fri, 18 Jan 2002 07:25:23 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C19FF1.4B1FE240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C19FF1.4B1FE240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For what it's worth.... I have provision for 8 Vectored Priority Interrupts; with individual = Mask; and a common Enable/Disable. An interrupt functions exactly the = same as an JST (Jump & Store Return) Instruction. The interrupt does = its necessary processing, and waits for an Instruction Fetch before = making the Break. I use 8 pairs of dedicated addresses (hard wired). I = have used this implementation in other designs and have never had the = software people complain. After all, what I do is hope to make things = easier for the Software guys -=20 never jam things down their throat without proper consultation. Regards Dick Hartney ------=_NextPart_000_002F_01C19FF1.4B1FE240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For what it's worth....
 
I have provision for 8 Vectored = Priority=20 Interrupts; with individual Mask; and a common Enable/Disable.  An=20 interrupt functions exactly the same as an JST (Jump & Store Return) = Instruction.  The interrupt does its necessary processing, and = waits for an=20 Instruction Fetch before making the Break.  I use 8 pairs of = dedicated=20 addresses (hard wired).  I have used this implementation in other = designs=20 and have never had the software people complain.  After all, what I = do is=20 hope to make things easier for the Software guys -
never jam things down their throat = without proper=20 consultation.
 
Regards
Dick Hartney
 
------=_NextPart_000_002F_01C19FF1.4B1FE240-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Jan 18 14:33:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgft-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:49 +0100 (CET) Received: (qmail 19190 invoked by uid 0); 18 Jan 2002 13:31:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 18 Jan 2002 13:31:08 -0000 Received: by moria.seul.org (Postfix) id 5D051146898; Fri, 18 Jan 2002 08:31:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5906214689C; Fri, 18 Jan 2002 08:31:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf22bis.bellsouth.net (mail022.mail.bellsouth.net [205.152.58.62]) by moria.seul.org (Postfix) with ESMTP id 0D784146898 for ; Fri, 18 Jan 2002 08:31:07 -0500 (EST) Received: from computer ([209.215.24.58]) by imf22bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20020118133220.BMLQ22265.imf22bis.bellsouth.net@computer>; Fri, 18 Jan 2002 08:32:20 -0500 Message-ID: <004901c1a024$a83384e0$3a18d7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] More on Interrupts Date: Fri, 18 Jan 2002 07:33:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C19FF2.5CC80940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C19FF2.5CC80940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have also made provision for Interrupting if the processor has executed an HLT (halt) instruction. Regards Dick Hartney ------=_NextPart_000_0046_01C19FF2.5CC80940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have also made provision for = Interrupting if the=20 processor
has executed an HLT  (halt)=20 instruction.
 
Regards
Dick Hartney
------=_NextPart_000_0046_01C19FF2.5CC80940-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jan 18 16:28:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgfw-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:52 +0100 (CET) Received: (qmail 29604 invoked by uid 0); 18 Jan 2002 15:36:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 18 Jan 2002 15:36:54 -0000 Received: by moria.seul.org (Postfix) id 7B2BC1468A4; Fri, 18 Jan 2002 10:36:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63DE51468A6; Fri, 18 Jan 2002 10:36:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id C6B131468A4 for ; Fri, 18 Jan 2002 10:36:52 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA03431 for ; Fri, 18 Jan 2002 08:36:51 -0700 (MST) Message-ID: <3C483F32.14BC0099@jetnet.ab.ca> Date: Fri, 18 Jan 2002 08:28:50 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More on Interrupts References: <004901c1a024$a83384e0$3a18d7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N richard hartny wrote: Nowdays 32 interrupt vectors should be standard. Also since most modern OS do a task swap after a interrupt a fast way of of setting task priorities and getting the next sorted task would be useful. Rather than having OS system semaphores in main memory you could have fixed block of flags 256? that are set local in the cpu. A serial bus would update all changes made between processors. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 19 00:21:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgfw-0004Vp-01 for ; Fri, 18 Jan 2002 22:35:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:52 +0100 (CET) Received: (qmail 2070 invoked by uid 0); 18 Jan 2002 17:18:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 18 Jan 2002 17:18:33 -0000 Received: by moria.seul.org (Postfix) id 418D41468A8; Fri, 18 Jan 2002 12:18:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37F301468A7; Fri, 18 Jan 2002 12:18:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CC7241468A5 for ; Fri, 18 Jan 2002 12:18:31 -0500 (EST) Received: from ifrance.com (vlt6-243.n.club-internet.fr [194.158.109.243]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 0426E17DE for ; Fri, 18 Jan 2002 18:18:28 +0100 (CET) Message-ID: <3C48AE0E.7F916802@ifrance.com> Date: Fri, 18 Jan 2002 18:21:50 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PS References: <200201172156.g0HLulU17498@anerio.lip6.fr> <3C47272E.483E4A0E@jetnet.ab.ca> <3C4772EF.84214BAC@f-cpu.org> <001d01c19fda$9d64cb40$d1215c41@birdcomputer> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Rob Finch a écrit : > > Hi, > > I've been following the F-CPU project for a few months now, I think it's an > interesting idea. > > Anyway, regarding semaphores. Semaphores don't have to be implemented using > atomic read-modify-write memory operations or blocking instructions. I > believe there are software algorithms for handling semaphores for example, > Dekker's algorithm. You can also implement semaphores using an address > reservation system in hardware. An address reservation system is used in the > PowerPC for example, and is my current favorite method. > > Rob http://www.birdcomputer.ca/ Could you explain the algorythme or have you URL ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 19 00:43:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgfy-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:54 +0100 (CET) Received: (qmail 1493 invoked by uid 0); 18 Jan 2002 17:40:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Jan 2002 17:40:21 -0000 Received: by moria.seul.org (Postfix) id 6CC971468A7; Fri, 18 Jan 2002 12:40:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B6E11468A9; Fri, 18 Jan 2002 12:40:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 287081468A7 for ; Fri, 18 Jan 2002 12:40:20 -0500 (EST) Received: from ifrance.com (vlt11-228.n.club-internet.fr [195.36.224.228]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 849471ADD for ; Fri, 18 Jan 2002 18:40:17 +0100 (CET) Message-ID: <3C48B32B.381ACA86@ifrance.com> Date: Fri, 18 Jan 2002 18:43:39 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PS References: <200201172156.g0HLulU17498@anerio.lip6.fr> <3C47272E.483E4A0E@jetnet.ab.ca> <3C4772EF.84214BAC@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N What ever fixed number of semaphore you will put they will never have enought. So hardware semaphore must be designed to handel software semaphore. (I just remind you that a posix semaphore is a counter not a flag.) This HW semaphore will be used to protect memory area of the true semaphore .So we will need only _one_ semphore to handel that. Or we can use an other kind of sync things. Have you ever hurd about super step model ? It could represent by a wait&sync instruction. This instruction wait that every core are stoped with this instruction before releasing them in the same time (in NUMA system, caches are updated just before). It's much easier to programme multi-cpu application that way (a compiler that compile for 2 or more cpu). nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 18 12:11:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16Rgfz-0004Vp-00 for ; Fri, 18 Jan 2002 22:35:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 18 Jan 2002 22:35:55 +0100 (CET) Received: (qmail 14735 invoked by uid 0); 18 Jan 2002 18:18:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 18 Jan 2002 18:18:25 -0000 Received: by moria.seul.org (Postfix) id CCC6E1468A6; Fri, 18 Jan 2002 13:18:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9CA8F1468AE; Fri, 18 Jan 2002 13:18:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a232.home.uni-hannover.de [130.75.232.232]) by moria.seul.org (Postfix) with ESMTP id D71FD1468A6 for ; Fri, 18 Jan 2002 13:18:21 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00547; Fri, 18 Jan 2002 12:11:47 +0100 Message-ID: <20020118121147.53800@thrai.stud.uni-hannover.de> Date: Fri, 18 Jan 2002 12:11:47 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Use of VCI for F-CPU core References: <200201172143.g0HLhib17086@anerio.lip6.fr> <20020118010031.40806@thrai.stud.uni-hannover.de> <3C47793B.BB612B34@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C47793B.BB612B34@f-cpu.org>; from Yann Guidon on Fri, Jan 18, 2002 at 02:24:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jan 18, 2002 at 02:24:11AM +0100, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > On Thu, Jan 17, 2002 at 10:43:44PM +0100, Yann Guidon [systeme] wrote: > > > The VCI interface protocol is defined by the VSI Alliance (vsi.org). > > > I am investigating whether it can be used in the frame > > > of F-CPU. Why not Wishbone ? Could be, but VCI > > > is very simple and does not define a bus or whatever, just the interface. > > > Exactly what is needed to define a core, without caring for the fine prints > > > of the reference manuals. I like VCI to the same point i dislike PCI. > > > > It has its quirks, though. An asynchronous VAL/ACK cycle seems to be > > pretty unreliable -- you never know whether the ACK arrives in time --, > > while synchronous handshakes are slow (2 cycles per cell). > > VCI (any version) is fully synchronous. It is clearly specified in the > documentation. As to whether it is slow, just consider that F-CPU is > meant to run at a higher frequency than usual circuits. This can also > involve crossing a clock domain. Although the minimum latency is 1 cycle, just consider > that the addressed circuits will probably require much more cycles before > they give an answer. This is where it becomes interesting (or awful > depending on how you see it). While in "Peripheral VCI" (a VCI subset for dumb I/O > for example) this is a limit, "Basic VCI" and "Advanced VCI" provide > 4 bits for Transaction ID (a TID from 0 to 15) so the answers can come back > in order or not, after a variable number of cycles. In a way, VCI's design > makes the FC0's design easier, or if you prefer, it removes some burdens. Right. I guess I didn't express myself clearly enough. The problem is in the handshake protocol. The initiator raises VAL, the target responds with ACK, and when both lines are active at a rising clock edge, the transfer is done. When ACK is generated asynchronously, and the timing is too tight, the target might see an active ACK while the initiator still thinks it's inactive (transmission delay!). Now let the clock signal rise exactly at this point, et voila, they're out of sync. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 18 19:35:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16SpTn-0004NF-01 for ; Tue, 22 Jan 2002 02:12:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 22 Jan 2002 02:12:03 +0100 (CET) Received: (qmail 1039 invoked by uid 0); 18 Jan 2002 23:24:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 18 Jan 2002 23:24:21 -0000 Received: by moria.seul.org (Postfix) id 2CDC31468B3; Fri, 18 Jan 2002 18:24:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 236A91468B6; Fri, 18 Jan 2002 18:24:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a228.home.uni-hannover.de [130.75.232.228]) by moria.seul.org (Postfix) with ESMTP id AB39F1468B3 for ; Fri, 18 Jan 2002 18:24:18 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00557; Fri, 18 Jan 2002 19:35:34 +0100 Message-ID: <20020118193534.23286@thrai.stud.uni-hannover.de> Date: Fri, 18 Jan 2002 19:35:34 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More on Interrupts References: <004901c1a024$a83384e0$3a18d7d1@computer> <3C483F32.14BC0099@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C483F32.14BC0099@jetnet.ab.ca>; from Ben Franchuk on Fri, Jan 18, 2002 at 08:28:50AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jan 18, 2002 at 08:28:50AM -0700, Ben Franchuk wrote: > richard hartny wrote: > Nowdays 32 interrupt vectors should be standard. For 32-bit CPUs, yes. > Also since most modern OS do a task swap after > a interrupt a fast way of of setting task priorities > and getting the next sorted task would be useful. Since interrupts tend to arrive frequently, interrupt service routines should return to the interrupted task as soon as possible. A task switch, on the other hand, is rather expensive -- a lot of state has to be saved and reloaded, even with SRB. Most interrupts deal with I/O - they indicate that data has arrived or can be sent, or that some device has changed its state. Usually, none of these events triggers an automatic task switch. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 19 01:55:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16SpTo-0004NF-01 for ; Tue, 22 Jan 2002 02:12:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 22 Jan 2002 02:12:04 +0100 (CET) Received: (qmail 7681 invoked by uid 0); 19 Jan 2002 00:51:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Jan 2002 00:51:41 -0000 Received: by moria.seul.org (Postfix) id A981E1468B6; Fri, 18 Jan 2002 19:51:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A49951468B9; Fri, 18 Jan 2002 19:51:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 6FAE91468B6 for ; Fri, 18 Jan 2002 19:51:40 -0500 (EST) Received: from f-cpu.org (kdl11-14.n.club-internet.fr [213.44.9.14]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3E0C81767 for ; Sat, 19 Jan 2002 01:51:37 +0100 (CET) Message-ID: <3C48C3FE.F1C98013@f-cpu.org> Date: Sat, 19 Jan 2002 01:55:26 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More on Interrupts References: <004901c1a024$a83384e0$3a18d7d1@computer> <3C483F32.14BC0099@jetnet.ab.ca> <20020118193534.23286@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Fri, Jan 18, 2002 at 08:28:50AM -0700, Ben Franchuk wrote: > > richard hartny wrote: > > Nowdays 32 interrupt vectors should be standard. > > For 32-bit CPUs, yes. >from the core's point of view, the IRQ controller has to send a "IRQ signal" along with a IRQ vector number (encoded on N bits). >From this point, when the IRQ is acknowleged, IRQs are disabled (to avoid interruption of the interrupt process) and the core starts to load the instructions located at SR_IRQ_BASE + IRQ_VEC*64. When it's loaded, SRB begins and the handler starts. If the IRQ wants to become reentering (or allow higher priorities), it has to configure the SR_IRQ special register where the IRQs are re-enabled. Before that, it has to prepare itself a frame for storing its own context, in case SRB occurs again. The process is reversed when the handler stops : disable IRQ, free the backup frame (also called 'CMB' for Context Memory Buffer), trigger reverse SRB. Is that simple enough ? :-) This means that the IRQ controller can implement whatever policy it wants : round-robin, priorities etc. as long as they can still be controlled by the SR instructions (get and put). > > Also since most modern OS do a task swap after > > a interrupt a fast way of of setting task priorities > > and getting the next sorted task would be useful. > > Since interrupts tend to arrive frequently, interrupt service routines > should return to the interrupted task as soon as possible. A task > switch, on the other hand, is rather expensive -- a lot of state has > to be saved and reloaded, even with SRB. > > Most interrupts deal with I/O - they indicate that data has arrived or > can be sent, or that some device has changed its state. Usually, none > of these events triggers an automatic task switch. However, the basic SRB can be triggered, even if no context is swapped. SRB was and is still meant to reduce the latencies of ISRs by performing the register backup almost "hand in hand" with the ISR. With some smart design (but not tonight because i'm really too tired), it could be possible to make an exception to the "atomicity" rule of the SRB mechanism, if the SRB is stopped to restore the instruction stream that is currently being backed up. This way, "very short" ISRs (like 16 instructions) could remain short, without even having to contain context backup/restore instructions. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 19 01:55:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16SpTp-0004NF-00 for ; Tue, 22 Jan 2002 02:12:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 22 Jan 2002 02:12:05 +0100 (CET) Received: (qmail 9125 invoked by uid 0); 19 Jan 2002 00:51:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 19 Jan 2002 00:51:44 -0000 Received: by moria.seul.org (Postfix) id 619211468BC; Fri, 18 Jan 2002 19:51:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E7ED1468BB; Fri, 18 Jan 2002 19:51:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 278921468B9 for ; Fri, 18 Jan 2002 19:51:43 -0500 (EST) Received: from f-cpu.org (kdl11-14.n.club-internet.fr [213.44.9.14]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 45DC41716 for ; Sat, 19 Jan 2002 01:51:39 +0100 (CET) Message-ID: <3C48C3FF.673CBE28@f-cpu.org> Date: Sat, 19 Jan 2002 01:55:27 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] PS References: <200201172156.g0HLulU17498@anerio.lip6.fr> <3C47272E.483E4A0E@jetnet.ab.ca> <3C4772EF.84214BAC@f-cpu.org> <3C48B32B.381ACA86@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO wrote: > > What ever fixed number of semaphore you will put they will never have > enought. So hardware semaphore must be designed to handel software > semaphore. > > (I just remind you that a posix semaphore is a counter not a flag.) > This HW semaphore will be used to protect memory area of the true > semaphore .So we will need only _one_ semphore to handel that. > > Or we can use an other kind of sync things. Have you ever hurd about > super step model ? > > It could represent by a wait&sync instruction. This instruction wait > that every core are stoped with this instruction before releasing them > in the same time (in NUMA system, caches are updated just before). It's > much easier to programme multi-cpu application that way (a compiler that > compile for 2 or more cpu). i think you'll have to explain that to me by voice and in french... i seem to miss the deep implication of your idea. When do we meet again ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 19 01:55:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16SpTq-0004NF-00 for ; Tue, 22 Jan 2002 02:12:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 22 Jan 2002 02:12:06 +0100 (CET) Received: (qmail 10299 invoked by uid 0); 19 Jan 2002 00:51:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 19 Jan 2002 00:51:46 -0000 Received: by moria.seul.org (Postfix) id 455D31468BB; Fri, 18 Jan 2002 19:51:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42A271468BA; Fri, 18 Jan 2002 19:51:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0D1411468B8 for ; Fri, 18 Jan 2002 19:51:46 -0500 (EST) Received: from f-cpu.org (kdl11-14.n.club-internet.fr [213.44.9.14]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9539B1816 for ; Sat, 19 Jan 2002 01:51:42 +0100 (CET) Message-ID: <3C48C402.5A9BF1CC@f-cpu.org> Date: Sat, 19 Jan 2002 01:55:30 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Use of VCI for F-CPU core References: <200201172143.g0HLhib17086@anerio.lip6.fr> <20020118010031.40806@thrai.stud.uni-hannover.de> <3C47793B.BB612B34@f-cpu.org> <20020118121147.53800@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Fri, Jan 18, 2002 at 02:24:11AM +0100, Yann Guidon wrote: > > hi ! > > Michael Riepe wrote: > > > On Thu, Jan 17, 2002 at 10:43:44PM +0100, Yann Guidon [systeme] wrote: > > VCI (any version) is fully synchronous. It is clearly specified in the > > documentation. As to whether it is slow, just consider that F-CPU is > > meant to run at a higher frequency than usual circuits. This can also > > involve crossing a clock domain. Although the minimum latency is 1 cycle, just consider > > that the addressed circuits will probably require much more cycles before > > they give an answer. This is where it becomes interesting (or awful > > depending on how you see it). While in "Peripheral VCI" (a VCI subset for dumb I/O > > for example) this is a limit, "Basic VCI" and "Advanced VCI" provide > > 4 bits for Transaction ID (a TID from 0 to 15) so the answers can come back > > in order or not, after a variable number of cycles. In a way, VCI's design > > makes the FC0's design easier, or if you prefer, it removes some burdens. > > Right. > > I guess I didn't express myself clearly enough. looks lile we are both tired ;-) > The problem is in the > handshake protocol. The initiator raises VAL, the target responds with > ACK, and when both lines are active at a rising clock edge, the transfer > is done. When ACK is generated asynchronously, and the timing is too > tight, the target might see an active ACK while the initiator still > thinks it's inactive (transmission delay!). Now let the clock signal > rise exactly at this point, et voila, they're out of sync. in the VCI spec, they are clear about these cases (hey, the ones who designed this are older than us all ;-D) and in no way should the interface itself cross a clock domain (the wrapper has to do it, it more than one domain exists, but not the interface). A VCI interface must NOT be asynchronous. The little examples i had in course at the university showed the simple FSMs that realize the necessary protocol, but this often depends on your needs so one FSM does not fit all cases. Just in case you wanted to know ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Jan 19 14:54:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16SpTy-0004NF-00 for ; Tue, 22 Jan 2002 02:12:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 22 Jan 2002 02:12:14 +0100 (CET) Received: (qmail 21869 invoked by uid 0); 19 Jan 2002 13:52:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 19 Jan 2002 13:52:26 -0000 Received: by moria.seul.org (Postfix) id 230411463AB; Sat, 19 Jan 2002 08:52:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1ABDF1467EF; Sat, 19 Jan 2002 08:52:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf20bis.bellsouth.net (mail120.mail.bellsouth.net [205.152.58.80]) by moria.seul.org (Postfix) with ESMTP id C9BCA1463AB for ; Sat, 19 Jan 2002 08:52:21 -0500 (EST) Received: from computer ([208.60.244.35]) by imf20bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with SMTP id <20020119135335.GKLU12031.imf20bis.bellsouth.net@computer>; Sat, 19 Jan 2002 08:53:35 -0500 Message-ID: <003401c1a0f0$cc0a3220$23f43cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Interrupts, Misquote Date: Sat, 19 Jan 2002 07:54:20 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C1A0BE.80958EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C1A0BE.80958EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I did not say 32 Interrupts should be Standard for 32 Bit Processors. Again---I have implemented 8 Vectored Priority Interrupts. For an Encoder, I use the equivalent of an SN74148 Priority Encoder. = Each Interrupt has a dedicated Memory address Pair. The first is used = to store the incremented Program Address, and the second is used to = start the context switch. Since my architecture is M2M; only the = A-Register(Accumulator) has to be saved. I use 3.5 NS SSRAM. My Language Processor uses 5 of the 8. They are used for Multiply, = Divide, FBC (Fully Buffered Channel) termination Interrupt, IPI = (Inter-Processor Interrupt), and one of 128 CRT Monitors from my CICU = (Console Interrupt Control Unit).=20 The IPI is used with a Mailbox in Memory for message passing with my = Peripheral Processor. The Mailbox address will be assigned by Software. The CICU contains a 7 Bit Counter (0 - 127) doing a scan of 128 data = lines from a CRT Monitor at a 100 MHz rate. A Compare stops the = scanner, and a controlled serial shift is performed. When the required = number of shifts is performed - the CICU sends an Interrupt Pulse to the = Language Processor. When the Interrupt is permitted, an INA (Input to = A-reg) instruction will read data from the CICU and all interrupts are = disabled. The Data contains the Terminal Number and keyboard = data/function or mouse address. Completing the CICU read, the counter is = released looking for another input. The interrupts will be re-enabled = upon completion of the requested task. Each of the 128 terminals have a = dedicated Memory Block. Etc., Etc. For the nay-sayers,,,,,,this design has been used on 5 major projects = over the years. Regards Dick Hartney ------=_NextPart_000_0031_01C1A0BE.80958EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I did not say 32 Interrupts should be = Standard for=20 32 Bit Processors.
 
Again---I have implemented 8 Vectored = Priority=20 Interrupts.
For an Encoder, I use the equivalent of = an SN74148=20 Priority Encoder.  Each Interrupt has a dedicated Memory address=20 Pair.  The first is used to store the incremented Program Address, = and the=20 second is used to start the context switch.  Since my architecture = is M2M;=20 only the A-Register(Accumulator) has to be saved.  I use 3.5 NS=20 SSRAM.
 
My Language Processor uses 5 of = the 8. =20 They are used for Multiply, Divide, FBC (Fully Buffered Channel) = termination=20 Interrupt, IPI (Inter-Processor Interrupt), and one of 128 CRT Monitors = >from my=20 CICU (Console Interrupt Control Unit).
 
The IPI is used with a Mailbox in = Memory for=20 message passing with my Peripheral Processor. The Mailbox address will = be=20 assigned by Software.
 
The CICU contains a 7 Bit Counter (0 - = 127) doing a=20 scan of 128 data lines from a CRT Monitor at a 100 MHz rate.  A = Compare=20 stops the scanner, and a controlled serial shift is performed.  = When the=20 required number of shifts is performed - the CICU sends an Interrupt = Pulse to=20 the Language Processor.  When the Interrupt is permitted, an INA = (Input to=20 A-reg) instruction will read data from the CICU and all interrupts are=20 disabled.  The Data contains the Terminal Number and keyboard = data/function=20 or mouse address. Completing the CICU read, the counter is released = looking for=20 another input. The interrupts will be re-enabled upon completion of the=20 requested task.  Each of the 128 terminals have a dedicated Memory=20 Block.  Etc., Etc.
 
For the nay-sayers,,,,,,this design has = been used=20 on 5 major projects over the years.
 
Regards
Dick Hartney
 
 
------=_NextPart_000_0031_01C1A0BE.80958EC0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From e-lottoticket@columbus.rr.com Sun Jan 27 01:12:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16VB3I-0000PE-01 for ; Mon, 28 Jan 2002 13:38:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 28 Jan 2002 13:38:24 +0100 (CET) Received: (qmail 32391 invoked by uid 0); 27 Jan 2002 00:13:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 27 Jan 2002 00:13:17 -0000 Received: by moria.seul.org (Postfix) id BB5E5146832; Sat, 26 Jan 2002 19:13:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7710C146840; Sat, 26 Jan 2002 19:13:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from arwen.bravenet.com (unknown [63.147.25.152]) by moria.seul.org (Postfix) with ESMTP id A444A146832 for ; Sat, 26 Jan 2002 19:13:12 -0500 (EST) Received: from largo.sf.bravenet.com (largo.sf.bravenet.com [172.16.0.10]) by arwen.bravenet.com (Postfix) with ESMTP id A0D296275 for ; Sat, 26 Jan 2002 16:13:10 -0800 (PST) Received: by largo.sf.bravenet.com (Postfix, from userid 1010) id 6590282F; Sat, 26 Jan 2002 16:12:41 -0800 (PST) To: f-cpu@seul.org Subject: [f-cpu] Confirm your subscription Received: from [24.93.118.204] by bravenet.com with HTTP; Sat, 26 Jan 2002 16:12:41 -0800 From: e-lottoticket@columbus.rr.com X-Usernum: 118107732 X-IPAddy: 24.93.118.204 Message-Id: <20020127001241.6590282F@largo.sf.bravenet.com> Date: Sat, 26 Jan 2002 16:12:41 -0800 (PST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mailing List Subscription Confirmation *** Confirmation required *** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You have been invited to join our mailing list. This list has a double optin feature so you must go to the URL listed below to finish joining this list. This is a safeguard for you. PLEASE CLICK THE LINK BELOW TO CONFIRM YOUR SUBSCRIPTION: http://pub2.bravenet.com/elist/add.php?usernum=118107732&id=4211478 IF YOU DO NOT WISH TO SUBSCRIBE DO NOT CLICK THE LINK: If this message was sent in error, please disregard it and no further email will be sent to you on this subject. ----------------------------------------------------------------------- Bravenet.com ~ free webtools for webmasters ~ http://www.bravenet.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jan 27 01:32:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16VB3J-0000PE-00 for ; Mon, 28 Jan 2002 13:38:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 28 Jan 2002 13:38:25 +0100 (CET) Received: (qmail 28246 invoked by uid 0); 27 Jan 2002 00:28:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 27 Jan 2002 00:28:41 -0000 Received: by moria.seul.org (Postfix) id E857D14681F; Sat, 26 Jan 2002 19:28:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBCF514683B; Sat, 26 Jan 2002 19:28:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 8DF1614681F for ; Sat, 26 Jan 2002 19:28:39 -0500 (EST) Received: from f-cpu.org (kdl11-25.n.club-internet.fr [213.44.9.25]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 3CF1D1691 for ; Sun, 27 Jan 2002 01:28:35 +0100 (CET) Message-ID: <3C534AA8.5730402E@f-cpu.org> Date: Sun, 27 Jan 2002 01:32:40 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Confirm your subscription References: <20020127001241.6590282F@largo.sf.bravenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N how did THAT go though ????? please do not answer anything to this mass-mailing. e-lottoticket@columbus.rr.com wrote: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Mailing List Subscription Confirmation > *** Confirmation required *** > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > You have been invited to join our mailing list. > > This list has a double optin feature so you must go to the URL listed below > to finish joining this list. This is a safeguard for you. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From e-lottoticket@columbus.rr.com Mon Jan 28 08:31:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16VB3a-0000PE-00 for ; Mon, 28 Jan 2002 13:38:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 28 Jan 2002 13:38:42 +0100 (CET) Received: (qmail 28507 invoked by uid 0); 28 Jan 2002 07:31:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 28 Jan 2002 07:31:49 -0000 Received: by moria.seul.org (Postfix) id 0C53C146856; Mon, 28 Jan 2002 02:31:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE720146858; Mon, 28 Jan 2002 02:31:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from arwen.bravenet.com (unknown [63.147.25.152]) by moria.seul.org (Postfix) with ESMTP id 6945E146856 for ; Mon, 28 Jan 2002 02:31:48 -0500 (EST) Received: from drago.sf.bravenet.com (drago.sf.bravenet.com [172.16.0.7]) by arwen.bravenet.com (Postfix) with ESMTP id 46A515DAC for ; Sun, 27 Jan 2002 23:31:46 -0800 (PST) Received: by drago.sf.bravenet.com (Postfix, from userid 1010) id 669481DEF78; Sun, 27 Jan 2002 23:31:46 -0800 (PST) To: f-cpu@seul.org Subject: [f-cpu] Welcome to e-lottoticket.com Mailing List Received: from [194.3.30.157] by bravenet.com with HTTP; Sun, 27 Jan 2002 23:31:46 -0800 From: e-lottoticket@columbus.rr.com X-Usernum: 118107732 X-IPAddy: 194.3.30.157 Message-Id: <20020128073146.669481DEF78@drago.sf.bravenet.com> Date: Sun, 27 Jan 2002 23:31:46 -0800 (PST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N You have successfully been added to the mailing list at: http://e-lottoticket.com Where I will keep you up-dated on the Big Jackpots. Thank you for joining the list. Good Luck ----------------------------------------------------------------------- Your .biz and .info package is waiting for you! http://www.bravenet.com/out.php?id=1821 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jan 28 08:53:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16VB3m-0000PE-00 for ; Mon, 28 Jan 2002 13:38:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 28 Jan 2002 13:38:54 +0100 (CET) Received: (qmail 24074 invoked by uid 0); 28 Jan 2002 07:49:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 28 Jan 2002 07:49:06 -0000 Received: by moria.seul.org (Postfix) id 6E1AF146855; Mon, 28 Jan 2002 02:49:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 53C99146858; Mon, 28 Jan 2002 02:49:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 13F01146855 for ; Mon, 28 Jan 2002 02:49:05 -0500 (EST) Received: from f-cpu.org (kdl21-148.n.club-internet.fr [213.44.96.148]) by relay-4v.club-internet.fr (Postfix) with ESMTP id AFDC21688; Mon, 28 Jan 2002 08:49:02 +0100 (CET) Message-ID: <3C550367.736DC6DC@f-cpu.org> Date: Mon, 28 Jan 2002 08:53:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org, Roger Dingledine Subject: Re: [f-cpu] Welcome to e-lottoticket.com Mailing List References: <20020128073146.669481DEF78@drago.sf.bravenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N SHIT !!! is there a way to blacklist these guys ? or anything with 'lotto' in it ? e-lottoticket@columbus.rr.com wrote: > You have successfully been added to the mailing list at: > > http://e-lottoticket.com > > Where I will keep you up-dated on the Big Jackpots. > Thank you for joining the list. Good Luck > > ----------------------------------------------------------------------- > Your .biz and .info package is waiting for you! > http://www.bravenet.com/out.php?id=1821 > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From arma@mit.edu Mon Jan 28 09:09:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16VB3n-0000PE-01 for ; Mon, 28 Jan 2002 13:38:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 28 Jan 2002 13:38:55 +0100 (CET) Received: (qmail 31947 invoked by uid 0); 28 Jan 2002 08:09:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 28 Jan 2002 08:09:58 -0000 Received: by moria.seul.org (Postfix) id 88D4C146858; Mon, 28 Jan 2002 03:09:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8412B146859; Mon, 28 Jan 2002 03:09:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 506) id 4BB12146857; Mon, 28 Jan 2002 03:09:57 -0500 (EST) Date: Mon, 28 Jan 2002 03:09:57 -0500 From: Roger Dingledine To: Yann Guidon Cc: f-cpu@seul.org Subject: Re: [f-cpu] Welcome to e-lottoticket.com Mailing List Message-ID: <20020128030957.I6832@moria.seul.org> References: <20020128073146.669481DEF78@drago.sf.bravenet.com> <3C550367.736DC6DC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C550367.736DC6DC@f-cpu.org>; from whygee@f-cpu.org on Mon, Jan 28, 2002 at 08:53:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jan 28, 2002 at 08:53:11AM +0100, Yann Guidon wrote: > SHIT !!! > > is there a way to blacklist these guys ? > or anything with 'lotto' in it ? Heh. :) I've added /^from:.*lottoticket/i to the taboo_headers list. Let me know if it's still a problem. --Roger ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From e-lottoticket@columbus.rr.com Sun Feb 3 16:50:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16XSZL-0000G3-00 for ; Sun, 03 Feb 2002 20:44:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Feb 2002 20:44:55 +0100 (CET) Received: (qmail 27770 invoked by uid 0); 3 Feb 2002 15:50:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 3 Feb 2002 15:50:26 -0000 Received: by moria.seul.org (Postfix) id 6F334146801; Sun, 3 Feb 2002 10:50:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4E040146804; Sun, 3 Feb 2002 10:50:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from list2.bravenet.com (unknown [63.147.25.147]) by moria.seul.org (Postfix) with ESMTP id D8F86146801 for ; Sun, 3 Feb 2002 10:50:24 -0500 (EST) Received: from bravenet.com (localhost [127.0.0.1]) by list2.bravenet.com (Postfix) with SMTP id 93A8A1A7EFB for ; Sun, 3 Feb 2002 07:50:22 -0800 (PST) To: f-cpu@seul.org Received: from [24.93.118.204] by bravenet.com with HTTP From: e-lottoticket@columbus.rr.com Subject: [f-cpu] e-lottoticket.com News Letter. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--bravenet_list_id__" X-IPAddy: 24.93.118.204 X-Usernum: 118107732 Message-Id: <20020203155022.93A8A1A7EFB@list2.bravenet.com> Date: Sun, 3 Feb 2002 07:50:22 -0800 (PST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ----bravenet_list_id__ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Update....Multi state Lotteries.....Update Six Friends in Ariz. strike it rich.............. Go to e-lottoticket.com for details. e-lottoticket.com does not sell, share, or give out e-mail addresses for any reason, you can rest assured that we will not send junk mail trying to sell you something. New .us Domain Names! Check them Out Today! http://www.bravenet.com/out.php?id=3D1894 ----bravenet_list_id__ Content-Transfer-Encoding: quoted-printable Content-Type: text/html
3D"Keeping
Keeping You on Top of The Big Jackpots
 
">February 3, 2002   Keeping you up-to-date on the Big Jackpots!
The Big Game Jackpot moves to 23 Million......
There was no winner in the seven state "The Big Game" drawing friday night, Jackpot jumps to 23 Million for Tues Night Drawing.



 

PowerBall, Six friends in the East Valley, Collect the 92 Million
A year ago over suds and shuffleboard, six friends in the East Valley decided to have a little fun and indulge a collective dream of striking it rich. Their flights of fantasies have now...............(cont., link at right) New Jackpot goes to 14 Million. Wouldn't it be nice to have a friend that could get you a shot at the next big Jackpot!!!!



 

........Visit e-lottoticket.com for your chance to win........
Why be left out.......click on the e-lottoticket.com link to get your shot at the nations huge Jackpots. Check it out!

Get Your Chance today!


 
3D""
The Big Game News

No Jackpot winner Friday, click here for drawing results.

Powerball Update

Their flights of fantasies have now landed them a $95.3 million fortune in the latest Powerball Jackpot,
Each pocketing about $5.2 million.
Click Here for details

Get your Shot at The Big Jackpots........

Get your chances here for Powerball or The Big Game
Click Here

You don't have to be left out anymore!!!!!

  http://e-lottoticket.com
----bravenet_list_id__-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Feb 8 22:05:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLPy-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:10 +0100 (CET) Received: (qmail 6970 invoked by uid 0); 8 Feb 2002 21:02:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Feb 2002 21:02:32 -0000 Received: by moria.seul.org (Postfix) id 171D2146813; Fri, 8 Feb 2002 16:02:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F285C146847; Fri, 8 Feb 2002 16:02:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by moria.seul.org (Postfix) with ESMTP id 694FA146813 for ; Fri, 8 Feb 2002 16:02:30 -0500 (EST) Received: from computer ([209.215.11.6]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020208210348.OAEA2160.imf13bis.bellsouth.net@computer>; Fri, 8 Feb 2002 16:03:48 -0500 Message-ID: <000801c1b0e4$52baf220$060bd7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin64 Date: Fri, 8 Feb 2002 15:05:21 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1B0B2.074F7680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1B0B2.074F7680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Erin64 will be hot off the presses middle nxt week. =20 Regards Dick Hartney ------=_NextPart_000_0005_01C1B0B2.074F7680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Erin64 will be hot off the presses = middle nxt=20 week. 
 
Regards
Dick Hartney
------=_NextPart_000_0005_01C1B0B2.074F7680-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 10 02:17:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQL-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:33 +0100 (CET) Received: (qmail 25871 invoked by uid 0); 10 Feb 2002 01:13:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Feb 2002 01:13:17 -0000 Received: by moria.seul.org (Postfix) id 4C912146857; Sat, 9 Feb 2002 20:13:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45026146859; Sat, 9 Feb 2002 20:13:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E9D27146857 for ; Sat, 9 Feb 2002 20:13:14 -0500 (EST) Received: from f-cpu.org (kdl21-33.n.club-internet.fr [213.44.96.33]) by relay-1v.club-internet.fr (Postfix) with ESMTP id ED37F168E for ; Sun, 10 Feb 2002 02:13:10 +0100 (CET) Message-ID: <3C65CA3E.72CDB6C@f-cpu.org> Date: Sun, 10 Feb 2002 02:17:50 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] back to VHDL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello ! I just finished one of the building blocks of the register set, namely a "slice" (8 or 16-b wide) of 63 registers. It is a generic stuff that now simulates correclty. I also updated my "stable" tree with Michael's modified version of "fanout_linear" that works with Vanilla. I have one question however : Can we "link" the SHL unit to the LSU ? This would allow us to perform both endian and alignment with few overhead and some flexibility : it would even allow us to do "signed" loads, where the data is first aligned and then sign-extended... This is often used for CPUs like ALPHA and MIPS where data are handled only in a word-sized way. what do people think ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 10 03:16:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQM-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:34 +0100 (CET) Received: (qmail 15989 invoked by uid 0); 10 Feb 2002 02:12:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 10 Feb 2002 02:12:22 -0000 Received: by moria.seul.org (Postfix) id D7381146858; Sat, 9 Feb 2002 21:12:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CABEE14685A; Sat, 9 Feb 2002 21:12:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 88F42146858 for ; Sat, 9 Feb 2002 21:12:20 -0500 (EST) Received: from f-cpu.org (kdl21-36.n.club-internet.fr [213.44.96.36]) by relay-4v.club-internet.fr (Postfix) with ESMTP id C3FDA16C0 for ; Sun, 10 Feb 2002 03:12:17 +0100 (CET) Message-ID: <3C65D819.F2230868@f-cpu.org> Date: Sun, 10 Feb 2002 03:16:57 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] vhdl2c 0.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, a few days ago, Cedric spoke about converting VHDL to C for simulating the F-CPU faster than with a normal simulator, though i do not agree with this strategy. However, the opencollector database contains some tooms which could help, such as vhdl2c. This would be probably better to make this work, rather than writing a gcc frontend ... http://www.opencollector.org/get_details.php3?uid=97&src=summary WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Feb 10 03:00:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQQ-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:38 +0100 (CET) Received: (qmail 8092 invoked by uid 0); 10 Feb 2002 12:54:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 10 Feb 2002 12:54:16 -0000 Received: by moria.seul.org (Postfix) id CB0D81467F1; Sun, 10 Feb 2002 07:54:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9961D14684A; Sun, 10 Feb 2002 07:54:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a112.home.uni-hannover.de [130.75.232.112]) by moria.seul.org (Postfix) with ESMTP id 7B8A51467F1 for ; Sun, 10 Feb 2002 07:54:12 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02710; Sun, 10 Feb 2002 03:00:45 +0100 Message-ID: <20020210030045.04033@thrai.stud.uni-hannover.de> Date: Sun, 10 Feb 2002 03:00:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C65CA3E.72CDB6C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C65CA3E.72CDB6C@f-cpu.org>; from Yann Guidon on Sun, Feb 10, 2002 at 02:17:50AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Feb 10, 2002 at 02:17:50AM +0100, Yann Guidon wrote: [...] > I have one question however : Can we "link" the SHL unit to the > LSU ? This would allow us to perform both endian and alignment > with few overhead and some flexibility : it would even allow > us to do "signed" loads, where the data is first aligned and > then sign-extended... This is often used for CPUs like ALPHA > and MIPS where data are handled only in a word-sized way. That's not very RISCy, isn't it? We should duplicate the byterev part and add it to the LSU (for loade/storee), but the rest is IMHO overkill. In general, data should be properly aligned. Applications that violate this rule are supposed to do their bit fiddling on their own. Sign-extension (that is, the `widen' instruction) is currently not handled by the SHL unit (sign-extended right shifts are, but that's a totally different operation). We can implement it in the SHL, the LSU, or both. Or in another, separate unit. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 10 15:31:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQS-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:40 +0100 (CET) Received: (qmail 348 invoked by uid 0); 10 Feb 2002 14:27:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Feb 2002 14:27:08 -0000 Received: by moria.seul.org (Postfix) id 33A8B146854; Sun, 10 Feb 2002 09:27:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A45B146853; Sun, 10 Feb 2002 09:27:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id D770314684E for ; Sun, 10 Feb 2002 09:27:06 -0500 (EST) Received: from f-cpu.org (kdl11-4.n.club-internet.fr [213.44.9.4]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C1F2216B0 for ; Sun, 10 Feb 2002 15:27:04 +0100 (CET) Message-ID: <3C66844F.A8930F23@f-cpu.org> Date: Sun, 10 Feb 2002 15:31:43 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] register set Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, the register set is almost finished. I still have to make an exhaustive testbench and add the zero detector. I have based the design on transparent latches, they ensure that the cells are not too large and slow. It's almost completely asynchronous : reading is just combinational (the address is driven by the fetcher's output register) while writing is driven by the scheduler queue's output. the write command of each cell is given by the address decoder ANDed with the write mask, so writing is allowed when the mask is enabled and the data remain when the mask goes low. There are certainly some setup&hold conditions to ensure but it looks interesting. Now i'm seeking real implementations and VHDL "wrappers" of such a bank. I have looked a bit at the latest LEON sources but they look too messy for me... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: yes, i know, some people will shout at me because i don't use fully synchronous logic, but the register set would otherwise be larger and consume more power ... and i'm not afraid of semi-custom optimisations ;-P ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 10 17:30:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQT-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:41 +0100 (CET) Received: (qmail 10559 invoked by uid 0); 10 Feb 2002 16:25:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Feb 2002 16:25:38 -0000 Received: by moria.seul.org (Postfix) id C6D44146855; Sun, 10 Feb 2002 11:25:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C414F146853; Sun, 10 Feb 2002 11:25:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8D3CE146849 for ; Sun, 10 Feb 2002 11:25:36 -0500 (EST) Received: from f-cpu.org (kdl11-248.n.club-internet.fr [213.44.9.248]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 22DC416D8 for ; Sun, 10 Feb 2002 17:25:34 +0100 (CET) Message-ID: <3C66A014.302C5F35@f-cpu.org> Date: Sun, 10 Feb 2002 17:30:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C65CA3E.72CDB6C@f-cpu.org> <20020210030045.04033@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Sun, Feb 10, 2002 at 02:17:50AM +0100, Yann Guidon wrote: > [...] > > I have one question however : Can we "link" the SHL unit to the > > LSU ? This would allow us to perform both endian and alignment > > with few overhead and some flexibility : it would even allow > > us to do "signed" loads, where the data is first aligned and > > then sign-extended... This is often used for CPUs like ALPHA > > and MIPS where data are handled only in a word-sized way. > > That's not very RISCy, isn't it? it is, depending on what you want to do. All i was thinking was : to not duplicate functionalities. The LSU provides / takes a "word" (64 bit now) and we can reuse the shifter to : - sign extend - align - bit-reverse the word during load or store. by "align", i mean : we get a N-bit word from memory but when we request a smaller chunk (a byte, for example), it needs to be "aligned" so the requested data appears on the LSB, whether or not the address is aligned on N bits. I have no intention to provide "unaligned" access (when a word of 2^N bits has a pointer with the N LSB not cleared) because what would happen if the word crosses a page boundary ?... > We should duplicate the byterev part and add it to the LSU (for > loade/storee), but the rest is IMHO overkill. if byterev is already done in one unit, we could spare the duplication... > In general, data should be properly aligned. Applications that violate > this rule are supposed to do their bit fiddling on their own. of course, but what happens if we request one byte, half-word or word >from a 64-bit word ? this is where the SHL can help. Maybe i was not specific enough... > Sign-extension (that is, the `widen' instruction) is currently not handled > by the SHL unit (sign-extended right shifts are, but that's a totally > different operation). We can implement it in the SHL, the LSU, or both. > Or in another, separate unit. sign-extension of loaded words is not a priority because the CPU can handle most operand sizes. Usually, load+sext ("signed load") is required when only one data size is allowed in the CPU (such as in MIPS and ALPHA). let's keep that as an option for a future enhancement but first, we have to get the LSU right, and if possible not duplicate units (it's already large enough ;-D) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Feb 10 14:19:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQY-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:46 +0100 (CET) Received: (qmail 23129 invoked by uid 0); 10 Feb 2002 23:04:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 10 Feb 2002 23:04:10 -0000 Received: by moria.seul.org (Postfix) id 303F814685A; Sun, 10 Feb 2002 18:04:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2B6C146859; Sun, 10 Feb 2002 18:04:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a219.home.uni-hannover.de [130.75.232.219]) by moria.seul.org (Postfix) with ESMTP id 85F5D14684A for ; Sun, 10 Feb 2002 18:04:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00738; Sun, 10 Feb 2002 14:19:45 +0100 Message-ID: <20020210141945.53796@thrai.stud.uni-hannover.de> Date: Sun, 10 Feb 2002 14:19:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 References: <3C65D819.F2230868@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C65D819.F2230868@f-cpu.org>; from Yann Guidon on Sun, Feb 10, 2002 at 03:16:57AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Feb 10, 2002 at 03:16:57AM +0100, Yann Guidon wrote: > a few days ago, Cedric spoke about converting VHDL to C for > simulating the F-CPU faster than with a normal simulator, > though i do not agree with this strategy. Some simulators do that internally. Others use a virtual machine (like VHDL Simili). I can't tell which one is faster; that depends on the implementation. If the VM is well-designed, it may actually be faster than pure C. And it will probably need less memory, which is the more important factor in our case. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 11 01:07:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQc-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:50 +0100 (CET) Received: (qmail 6507 invoked by uid 0); 11 Feb 2002 00:07:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 11 Feb 2002 00:07:15 -0000 Received: by moria.seul.org (Postfix) id EF7F714684D; Sun, 10 Feb 2002 19:07:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDB58146859; Sun, 10 Feb 2002 19:07:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a219.home.uni-hannover.de [130.75.232.219]) by moria.seul.org (Postfix) with ESMTP id EE2C414684D for ; Sun, 10 Feb 2002 19:07:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02579; Mon, 11 Feb 2002 01:07:10 +0100 Message-ID: <20020211010710.36106@thrai.stud.uni-hannover.de> Date: Mon, 11 Feb 2002 01:07:10 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C65CA3E.72CDB6C@f-cpu.org> <20020210030045.04033@thrai.stud.uni-hannover.de> <3C66A014.302C5F35@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C66A014.302C5F35@f-cpu.org>; from Yann Guidon on Sun, Feb 10, 2002 at 05:30:12PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Feb 10, 2002 at 05:30:12PM +0100, Yann Guidon wrote: [...] > by "align", i mean : we get a N-bit word from memory > but when we request a smaller chunk (a byte, for example), > it needs to be "aligned" so the requested data appears > on the LSB, whether or not the address is aligned on N bits. That will only work in a load instruction, not in a store. On the other hand, if we have the hardware to do byte stores (that is, select lines for every single byte and so on), we can use it for byte loads as well. > I have no intention to provide "unaligned" access > (when a word of 2^N bits has a pointer with the N LSB not cleared) > because what would happen if the word crosses a page boundary ?... *boom* Yes, I know. > > We should duplicate the byterev part and add it to the LSU (for > > loade/storee), but the rest is IMHO overkill. > if byterev is already done in one unit, we could spare the duplication... We could also move the bytewise stuff (byterev, mix, expand and sdup) out of the SHL unit. That will make the bitwise operations faster (they're more timing-critical anyway) because the output mux can become smaller. > > In general, data should be properly aligned. Applications that violate > > this rule are supposed to do their bit fiddling on their own. > of course, but what happens if we request one byte, half-word or word > from a 64-bit word ? this is where the SHL can help. Maybe i was not > specific enough... But using the bit-shifter would be overkill. And it would slow down the SHL -- we need an additional input mux if we want to use it for both `sub-word' loads and generic shift operations. And it doesn't help with sub-word stores at all. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 11 06:26:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQl-0000Qf-00 for ; Mon, 11 Feb 2002 19:43:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:59 +0100 (CET) Received: (qmail 26181 invoked by uid 0); 11 Feb 2002 05:21:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 11 Feb 2002 05:21:33 -0000 Received: by moria.seul.org (Postfix) id 90F73146850; Mon, 11 Feb 2002 00:21:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8788114685B; Mon, 11 Feb 2002 00:21:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 22680146850 for ; Mon, 11 Feb 2002 00:21:32 -0500 (EST) Received: from f-cpu.org (kdl16-3.n.club-internet.fr [213.44.18.3]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 534D31688 for ; Mon, 11 Feb 2002 06:21:29 +0100 (CET) Message-ID: <3C6755F1.4C131A39@f-cpu.org> Date: Mon, 11 Feb 2002 06:26:09 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C65CA3E.72CDB6C@f-cpu.org> <20020210030045.04033@thrai.stud.uni-hannover.de> <3C66A014.302C5F35@f-cpu.org> <20020211010710.36106@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sun, Feb 10, 2002 at 05:30:12PM +0100, Yann Guidon wrote: > [...] > > by "align", i mean : we get a N-bit word from memory > > but when we request a smaller chunk (a byte, for example), > > it needs to be "aligned" so the requested data appears > > on the LSB, whether or not the address is aligned on N bits. > > That will only work in a load instruction, not in a store. On the other > hand, if we have the hardware to do byte stores (that is, select lines for > every single byte and so on), we can use it for byte loads as well. here we speak about the bi-directionality of the unit, which is another problem. One way to design the LSU is to use byte-wide write enables and "dirty" bits, so what we have to do is shift the written word so that it appears on the correct "alignment". If we don't use the SHL, the shift spans 256 bits (with a maximum of 32 positions). It becomes a rather large unit, and it can't be bidirectional, >from what i remember from my old first attempts. So it's going to be large (use some surface) and not very fast. That's why i always counted LSU accesses as 2 cycles (1 for shift and 1 for actual read/write). > > I have no intention to provide "unaligned" access > > (when a word of 2^N bits has a pointer with the N LSB not cleared) > > because what would happen if the word crosses a page boundary ?... > > *boom* Yes, I know. Jo gojl, hä hä hä ... > > > We should duplicate the byterev part and add it to the LSU (for > > > loade/storee), but the rest is IMHO overkill. > > if byterev is already done in one unit, we could spare the duplication... > > We could also move the bytewise stuff (byterev, mix, expand and sdup) > out of the SHL unit. That will make the bitwise operations faster (they're > more timing-critical anyway) because the output mux can become smaller. So there are 3 different units ? - 1 bytewise SIMD (word-slices) - 1 bitwise (shifts, rotations...) - 1 for the LSU (in fact 2 : one for each direction) it's going to take some room... But if you can make SDUP/EXPAND ect last 1 cycle only, why not. > > > In general, data should be properly aligned. Applications that violate > > > this rule are supposed to do their bit fiddling on their own. > > of course, but what happens if we request one byte, half-word or word > > from a 64-bit word ? this is where the SHL can help. Maybe i was not > > specific enough... > > But using the bit-shifter would be overkill. And it would slow down the > SHL -- we need an additional input mux if we want to use it for both > `sub-word' loads and generic shift operations. And it doesn't help > with sub-word stores at all. i agree that, if we want to use SHL for the LSU, we need MUXes at the SHL input. The result will go both to Xbar and LSU, too (so it works both for load and store). but i don't see why "it doesn't help with sub-word stores at all." @+ > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 11 06:26:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQl-0000Qf-01 for ; Mon, 11 Feb 2002 19:43:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:43:59 +0100 (CET) Received: (qmail 30946 invoked by uid 0); 11 Feb 2002 05:21:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 11 Feb 2002 05:21:38 -0000 Received: by moria.seul.org (Postfix) id 823AF14685B; Mon, 11 Feb 2002 00:21:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A1B614685D; Mon, 11 Feb 2002 00:21:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id DF91F14685B for ; Mon, 11 Feb 2002 00:21:33 -0500 (EST) Received: from f-cpu.org (kdl16-3.n.club-internet.fr [213.44.18.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 996B3168A for ; Mon, 11 Feb 2002 06:21:30 +0100 (CET) Message-ID: <3C6755F2.4A71AEFF@f-cpu.org> Date: Mon, 11 Feb 2002 06:26:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 References: <3C65D819.F2230868@f-cpu.org> <20020210141945.53796@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > > On Sun, Feb 10, 2002 at 03:16:57AM +0100, Yann Guidon wrote: > > > a few days ago, Cedric spoke about converting VHDL to C for > > simulating the F-CPU faster than with a normal simulator, > > though i do not agree with this strategy. > > Some simulators do that internally. Others use a virtual machine (like > VHDL Simili). I can't tell which one is faster; that depends on the > implementation. If the VM is well-designed, it may actually be faster > than pure C. And it will probably need less memory, which is the more > important factor in our case. Add to that : "real" VHDL software come with "optimised" libraries ! it means that there are hand-optimised versions of std_ulogic_vector functions, which even a compiler can't compete with. Simili does that, which alone justifies the 30% performance difference with Vanilla on running your adder test suite :-) ncsim goes much further in the optimisation frenzy, according to the docs it compiles down to strips of machine code. However the CPU's instruction cache might well appreciate less... Back to the original reason of my post : Cedric claims that he can do full-system simulations in his school, given the hundreds of 1GHz Athlon on a 100mbps network. I however claim that - the network is the bottleneck - VHDL simulations are not easily parallelisable. A globaly adressable, distributed memory multiprocessor might give better results thanks to faster synchronisation, better internal bandwidth and smaller OS overhead. But franckly, if we do our job correctly, we wouln't even need that ... a good management of the events can half the simulator's activity (and even the power consumption due to the decrease of activity). A good example is the multiplier : the input data latch should memorise operands only when a multiply operation is wanted. This prevents the whole multiply pipeline to oscillate with the Xbar's value. This thus avoids the simulator's event queue to fill uselessly. And the day we will need real speed, we'll ask Meta Systems or Quickturn to use one of their machines... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 11 08:54:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQn-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:01 +0100 (CET) Received: (qmail 22671 invoked by uid 0); 11 Feb 2002 07:50:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 11 Feb 2002 07:50:36 -0000 Received: by moria.seul.org (Postfix) id D3E9514685C; Mon, 11 Feb 2002 02:50:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAA5F14685E; Mon, 11 Feb 2002 02:50:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-101-63.ras.tesion.net [195.226.101.63]) by moria.seul.org (Postfix) with ESMTP id D578A14685C for ; Mon, 11 Feb 2002 02:50:33 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aBHs-0001WH-00 for f-cpu@seul.org; Mon, 11 Feb 2002 08:54:08 +0100 Date: Mon, 11 Feb 2002 08:54:07 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL In-Reply-To: <3C6755F1.4C131A39@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 11 Feb 2002, Yann Guidon wrote: > > > I have no intention to provide "unaligned" access > > > (when a word of 2^N bits has a pointer with the N LSB not cleared) > > > because what would happen if the word crosses a page boundary ?... > >=20 > > *boom* Yes, I know. >=20 > Jo gojl, h=E4 h=E4 h=E4 ... Hope you don't bring that restriction to the rest of the system. When DMA devices also come with that restriction it may be hard to implement some applications in speed mode without heavy use of memcpy() which may egalize the gain completely ;-) Beside multiplexer complexity I see no problem to allow an unaligned access within a cache line. Problems only occur when you cross the border of the cache line. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 11 09:16:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQo-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:02 +0100 (CET) Received: (qmail 7253 invoked by uid 0); 11 Feb 2002 08:12:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 11 Feb 2002 08:12:16 -0000 Received: by moria.seul.org (Postfix) id 27FB214685D; Mon, 11 Feb 2002 03:12:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23A8714685F; Mon, 11 Feb 2002 03:12:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D337D14685D for ; Mon, 11 Feb 2002 03:12:14 -0500 (EST) Received: from f-cpu.org (kdl21-119.n.club-internet.fr [213.44.96.119]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 7700C1694 for ; Mon, 11 Feb 2002 09:12:11 +0100 (CET) Message-ID: <3C677DEF.5C9B40AF@f-cpu.org> Date: Mon, 11 Feb 2002 09:16:47 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > On Mon, 11 Feb 2002, Yann Guidon wrote: > > > > I have no intention to provide "unaligned" access > > > > (when a word of 2^N bits has a pointer with the N LSB not cleared) > > > > because what would happen if the word crosses a page boundary ?... > > > > > > *boom* Yes, I know. > > > > Jo gojl, hä hä hä ... > Hope you don't bring that restriction to the rest of the system. quoting more or less Michael : "is it RISC, ja oder nein ?" > When DMA devices also come with that restriction it may be hard > to implement some applications in speed mode without heavy use > of memcpy() which may egalize the gain completely ;-) when doing DMA, the HW works in "linear" physical addressing mode. it's not a good thing (TM) to let the user directly access DMA. However, the paging mechanism can make things complex, not the RISC side. And we can limit the DMA transfer size to the page lengths. it shouldn't be complex... > Beside multiplexer complexity I see no problem to allow an > unaligned access within a cache line. Problems only occur > when you cross the border of the cache line. that's totally right. pages ARE aligned on cache line boundaries. It just depends on how much HW you can throw in. In the beginning i won't allow this because things are already complex enough to keep me busy during the next century, but in theory it's possible. however, if you organise your data layout correctly, it shouldn't even be necessary. All compilers (today) align data on their natural boundaries, we can further compress the memory footprint by performing data lifelength analysis and sorting the resulting patterns with the size (thus filling the holes). ie, the following declarations : char a; int b; long long int c; char d; int *e; should be sorted to : long long int c; int *e; /* here we don't know if a pointer is 32 or 64 bits, so putting it here is a way to avoid any problem */ int b; char a; char d; If all data are aligned, there is no hole between them. The problem with unaligned data in a cache line is to determine whether the reference crosses a line boundary and whether this will harm future architectural developments. I prefer to play it "safe" now. have fun, > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 11 11:15:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQp-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:03 +0100 (CET) Received: (qmail 12843 invoked by uid 0); 11 Feb 2002 10:10:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 11 Feb 2002 10:10:32 -0000 Received: by moria.seul.org (Postfix) id 725271462FD; Mon, 11 Feb 2002 05:10:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E04514684A; Mon, 11 Feb 2002 05:10:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 161D51462FD for ; Mon, 11 Feb 2002 05:10:30 -0500 (EST) Received: from f-cpu.org (kdl21-185.n.club-internet.fr [213.44.96.185]) by relay-2v.club-internet.fr (Postfix) with ESMTP id EABF016EE for ; Mon, 11 Feb 2002 11:10:26 +0100 (CET) Message-ID: <3C6799AB.7F183154@f-cpu.org> Date: Mon, 11 Feb 2002 11:15:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] [Fwd: Date'02] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Bonjour, Tout d'abord je souhaite la bienvenue au plus récent inscrit de la liste, Bruno, et à qui je transmets des informations qui vont intéresser d'autres personnes. Pour ceux qui ne le savent pas, DATE est LE salon de la microélectronique. Si vous le ratez cette année, il vous faudra aller à Munich l'année prochaine ;-) D'autres le disent mieux que moi : -------- Original Message -------- Date: Mon, 11 Feb 2002 10:47:14 +0100 From: Marie-Minerve LOUERAT Subject: Date'02 Bonjour a tous, La conference Date'02 (Design, Automation and Test in Europe) aura lieu la premiere semaine de mars 2002 au Palais des Congres de Paris, metro Porte maillot. Le salon-exposition est, comme les annees passees, ouvert a tous, a condition de d'inscrire. Les horaires d'ouvertures du salon-exposition sont : mardi 5: 10h00 a 20h00 mercredi 6: 10h00 a 18h30 jeudi 7: 10h00 a 16h30 Pour eviter les files d'attente a l'entree, vous pouvez vous pre-enregistrer sur le site web de la conference : http://www.date-conference.com et suivez registration/exhibition Je vous precise que les etudiants de DEA et DESS sont libres le mercredi 6 mars 2002 pour leur permettre d'aller toute la journee a Date'02. Je vous recommande en particulier le stand "University Booth", organise par LIP6/ASIM, ou toutes les universites presentent des demonstrations d'outils CAO et de Hardware. Mais vous trouverez aussi Avant!, Avertec, Cadence, CMP, Design&Reuse, Dolphin, Mentor, Neolinear, Simplex, Synopsys, Silvaco, Temento, Helwet Packard, Sun, TIMA !!! et bien d'autres. Si ce n'est pas clair, n'hesitez a me poser des questions, Marie-Minerve Marie-Minerve LOUERAT University Booth Chair at DATE'2002 www.date-conference.com --------------------------------------------------------------------------- LIP6/ASIM Laboratory, CNRS-UPMC (University of Paris 6), BP 167 4,place Jussieu, 75252 Paris Cedex 05, FRANCE tel : 33 (0)1 44 27 70 12 Fax : 33 (0)1 44 27 72 80 e-mail : marie-minerve.louerat@lip6.fr ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 11 14:07:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLQu-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:08 +0100 (CET) Received: (qmail 23392 invoked by uid 0); 11 Feb 2002 13:06:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 11 Feb 2002 13:06:21 -0000 Received: by moria.seul.org (Postfix) id 0B67A146859; Mon, 11 Feb 2002 08:06:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFB0A146860; Mon, 11 Feb 2002 08:06:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-102-13.ras.tesion.net [195.226.102.13]) by moria.seul.org (Postfix) with ESMTP id 4654C146859 for ; Mon, 11 Feb 2002 08:06:18 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aGAs-0001oX-00 for f-cpu@seul.org; Mon, 11 Feb 2002 14:07:14 +0100 Date: Mon, 11 Feb 2002 14:07:14 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL In-Reply-To: <3C677DEF.5C9B40AF@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! > > > > > I have no intention to provide "unaligned" access > > > > > (when a word of 2^N bits has a pointer with the N LSB not cleared= ) > > > > > because what would happen if the word crosses a page boundary ?..= =2E > > > > *boom* Yes, I know. > > > Jo gojl, h=E4 h=E4 h=E4 ... > > > Hope you don't bring that restriction to the rest of the system. > quoting more or less Michael : "is it RISC, ja oder nein ?" Is SIMD equal to RISC? =20 > > When DMA devices also come with that restriction it may be hard > > to implement some applications in speed mode without heavy use > > of memcpy() which may egalize the gain completely ;-) >=20 > when doing DMA, the HW works in "linear" physical addressing mode. > it's not a good thing (TM) to let the user directly access DMA. > However, the paging mechanism can make things complex, not the RISC side. > And we can limit the DMA transfer size to the page lengths. it shouldn't = be > complex... Just imagine some DMA communication device filling the data you want to process into memory by some obscure network protocol (e.g. TCP/IP). Since you don't want to copy the data hence and forth it must be put already properly aligned by the DMA device. And this is where you may get stuck if your data format is 64bit wide and the packet headers (which have been thrown away during receive) had a variable length. My quick solution was to define a new network packet format. :-(=20 Any hints for improvements? > > Beside multiplexer complexity I see no problem to allow an > > unaligned access within a cache line. Problems only occur > > when you cross the border of the cache line. > that's totally right. pages ARE aligned on cache line boundaries. > It just depends on how much HW you can throw in. > In the beginning i won't allow this because things are > already complex enough to keep me busy during the next century, > but in theory it's possible. however, if you organise your data layout > correctly, it shouldn't even be necessary. All compilers (today) > align data on their natural boundaries, we can further compress the > memory footprint by performing data lifelength analysis and sorting > the resulting patterns with the size (thus filling the holes). >=20 > ie, the following declarations : > char a; > int b; > long long int c; > char d; > int *e; > =20 > should be sorted to : > long long int c; > int *e; /* here we don't know if a pointer is 32 or 64 bits, > so putting it here is a way to avoid any problem */ > int b; > char a; > char d; >=20 > If all data are aligned, there is no hole between them.=20 Yes, I agree as long as you have complete control over the data structures. But what if the data structure is something you cannot change and is not fitting to the compiler rules? Hardware registers and DMA structures sometimes do not fit and it may get about a bit tedious to program around this. > The problem with unaligned data in a cache line is to determine whether > the reference crosses a line boundary and whether this will harm=20 > future architectural developments. I prefer to play it "safe" now. I see what you mean and I agree for 'now'. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Feb 11 17:14:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLR0-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:14 +0100 (CET) Received: (qmail 21457 invoked by uid 0); 11 Feb 2002 16:12:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 11 Feb 2002 16:12:02 -0000 Received: by moria.seul.org (Postfix) id 5F14E14686F; Mon, 11 Feb 2002 11:12:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5640E14686E; Mon, 11 Feb 2002 11:12:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id A027B1467FF for ; Mon, 11 Feb 2002 11:11:59 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-216.jetnet.ab.ca [207.34.60.216] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA21364 for ; Mon, 11 Feb 2002 09:11:58 -0700 (MST) Message-ID: <3C67EDD4.321044B8@jetnet.ab.ca> Date: Mon, 11 Feb 2002 09:14:12 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C677DEF.5C9B40AF@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > should be sorted to : > long long int c; > int *e; /* here we don't know if a pointer is 32 or 64 bits, > so putting it here is a way to avoid any problem */ > int b; > char a; > char d; > > If all data are aligned, there is no hole between them. > > The problem with unaligned data in a cache line is to determine whether > the reference crosses a line boundary and whether this will harm > future architectural developments. I prefer to play it "safe" now. The problem is char foobar[71] or struct { char foo[3] } foofoo[29]; If you are going to sort ... sort arrays and structures last as you keep local references local. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 11 17:21:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLR1-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:15 +0100 (CET) Received: (qmail 27996 invoked by uid 0); 11 Feb 2002 16:21:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 11 Feb 2002 16:21:58 -0000 Received: by moria.seul.org (Postfix) id 51B0B1467FF; Mon, 11 Feb 2002 11:21:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 428BF146863; Mon, 11 Feb 2002 11:21:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id DBA781467FF for ; Mon, 11 Feb 2002 11:21:56 -0500 (EST) Received: from club-internet.fr (flashmail-bm.cs.clubint.net [172.16.4.118]) by relay-1m.club-internet.fr (Postfix) with SMTP id 2F2DA171A; Mon, 11 Feb 2002 17:21:55 +0100 (CET) Received: from [132.227.86.2] by flashmail-bm.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] back to VHDL Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Feb 2002 17:21:55 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >Yann Guidon wrote: >> should be sorted to : >> If all data are aligned, there is no hole between them. >The problem is char foobar=5B71=5D or struct =7B char foo=5B3=5D =7D foof= oo=5B29=5D; your two examples can be reduced to a number of variables of the same size, so they are sorted as others. >If you are going to sort ... sort arrays and structures last as you keep >local references local. = now if you mix different sizes, the problem is a bit more complex but you = got the taste. then, the compiler writer has to do his job ;-) >Ben Franchuk - Dawn * 12/24 bit cpu * YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 11 12:28:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLR8-0000Qf-00 for ; Mon, 11 Feb 2002 19:44:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:22 +0100 (CET) Received: (qmail 14337 invoked by uid 0); 11 Feb 2002 18:13:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 11 Feb 2002 18:13:28 -0000 Received: by moria.seul.org (Postfix) id AED2A1467E8; Mon, 11 Feb 2002 13:13:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA20414680B; Mon, 11 Feb 2002 13:13:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a102.home.uni-hannover.de [130.75.232.102]) by moria.seul.org (Postfix) with ESMTP id 2AA9F1467E8 for ; Mon, 11 Feb 2002 13:13:25 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00525; Mon, 11 Feb 2002 12:28:03 +0100 Message-ID: <20020211122803.09701@thrai.stud.uni-hannover.de> Date: Mon, 11 Feb 2002 12:28:03 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C6755F1.4C131A39@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Feb 11, 2002 at 08:54:07AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 11, 2002 at 08:54:07AM +0100, Juergen Goeritz wrote: > On Mon, 11 Feb 2002, Yann Guidon wrote: > > > > > I have no intention to provide "unaligned" access > > > > (when a word of 2^N bits has a pointer with the N LSB not cleared) > > > > because what would happen if the word crosses a page boundary ?... > > > > > > *boom* Yes, I know. > > > > Jo gojl, hä hä hä ... > > Hope you don't bring that restriction to the rest of the system. > When DMA devices also come with that restriction it may be hard > to implement some applications in speed mode without heavy use > of memcpy() which may egalize the gain completely ;-) DMA doesn't use the paging mechanism of the CPU. That's why it's called *direct* memory access ;) > Beside multiplexer complexity I see no problem to allow an > unaligned access within a cache line. Problems only occur > when you cross the border of the cache line. That's exactly where things become complicated. And slow. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 11 12:23:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16aLR8-0000Qf-01 for ; Mon, 11 Feb 2002 19:44:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Feb 2002 19:44:22 +0100 (CET) Received: (qmail 30951 invoked by uid 0); 11 Feb 2002 18:13:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 11 Feb 2002 18:13:32 -0000 Received: by moria.seul.org (Postfix) id 6CE78146870; Mon, 11 Feb 2002 13:13:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A80D146848; Mon, 11 Feb 2002 13:13:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a102.home.uni-hannover.de [130.75.232.102]) by moria.seul.org (Postfix) with ESMTP id 4386914680B for ; Mon, 11 Feb 2002 13:13:27 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00510; Mon, 11 Feb 2002 12:23:43 +0100 Message-ID: <20020211122343.08881@thrai.stud.uni-hannover.de> Date: Mon, 11 Feb 2002 12:23:43 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 References: <3C65D819.F2230868@f-cpu.org> <20020210141945.53796@thrai.stud.uni-hannover.de> <3C6755F2.4A71AEFF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C6755F2.4A71AEFF@f-cpu.org>; from Yann Guidon on Mon, Feb 11, 2002 at 06:26:10AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 11, 2002 at 06:26:10AM +0100, Yann Guidon wrote: [...] > Back to the original reason of my post : Cedric claims that he can do > full-system simulations in his school, given the hundreds of 1GHz Athlon on > a 100mbps network. I however claim that > - the network is the bottleneck > - VHDL simulations are not easily parallelisable. It may be possible to parallelize simulation of large, modular circuits. The trick might be to use separate global and local state, and multiple event queues. But that's a special solution that can't be generalized. And we would have to write our own cluster-enabled simulator. > A globaly adressable, distributed memory multiprocessor might give better > results thanks to faster synchronisation, better internal bandwidth and > smaller OS overhead. Yep. > But franckly, if we do our job correctly, we wouln't even need that ... > a good management of the events can half the simulator's activity > (and even the power consumption due to the decrease of activity). > A good example is the multiplier : the input data latch should memorise > operands only when a multiply operation is wanted. This prevents the > whole multiply pipeline to oscillate with the Xbar's value. This thus > avoids the simulator's event queue to fill uselessly. Already implemented (except the input register). The pipeline registers will not switch unless they have to (that is, unless there is valid data in that particular stage). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Mon Feb 11 21:15:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzn-0004lH-01 for ; Wed, 13 Feb 2002 00:05:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:05:55 +0100 (CET) Received: (qmail 19964 invoked by uid 0); 11 Feb 2002 20:15:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 11 Feb 2002 20:15:46 -0000 Received: by moria.seul.org (Postfix) id 6026F146800; Mon, 11 Feb 2002 15:15:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 464C6146809; Mon, 11 Feb 2002 15:15:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 23536146800 for ; Mon, 11 Feb 2002 15:15:43 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id WAA14230 for ; Mon, 11 Feb 2002 22:15:40 +0200 Date: Mon, 11 Feb 2002 22:15:40 +0200 (EET) From: Kim Enkovaara To: fm Subject: Re: [f-cpu] register set In-Reply-To: <3C66844F.A8930F23@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I have based the design on transparent latches, > they ensure that the cells are not too large and slow. > It's almost completely asynchronous : reading is just > combinational (the address is driven by the fetcher's Have you tought about test structures for ASIC manufacturing? Latches are never fun thing to test. D-flipflops are so much easier to test with normal scan paths. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Mon Feb 11 21:20:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzn-0004lH-02 for ; Wed, 13 Feb 2002 00:05:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:05:55 +0100 (CET) Received: (qmail 28840 invoked by uid 0); 11 Feb 2002 20:20:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 11 Feb 2002 20:20:14 -0000 Received: by moria.seul.org (Postfix) id F21091467EE; Mon, 11 Feb 2002 15:20:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D46D8146804; Mon, 11 Feb 2002 15:20:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 151441467EE for ; Mon, 11 Feb 2002 15:20:10 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id WAA14330 for ; Mon, 11 Feb 2002 22:20:09 +0200 Date: Mon, 11 Feb 2002 22:20:08 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 In-Reply-To: <3C6755F2.4A71AEFF@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > - VHDL simulations are not easily parallelisable. > A globaly adressable, distributed memory multiprocessor might give better > results thanks to faster synchronisation, better internal bandwidth and > smaller OS overhead. There has been many startups that have tried to create parallel simulators, but none of them have succeded in it well enough to create any real demand. And I'm quite sure that the big companies have also tried to make parallel simulators. I heard from one manufacturer that the memory latency and bandwidth needs negate the effects of parallelization.. It's more wise to run one simulator on each individual processor and just run many simulations in one machine, and not try to make one simulation faster. --Kim ps. I would love to have a good parallel simulator :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Feb 11 22:03:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzo-0004lH-00 for ; Wed, 13 Feb 2002 00:05:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:05:56 +0100 (CET) Received: (qmail 18165 invoked by uid 0); 11 Feb 2002 21:01:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 11 Feb 2002 21:01:23 -0000 Received: by moria.seul.org (Postfix) id 6F19D146804; Mon, 11 Feb 2002 16:01:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 67C2E146809; Mon, 11 Feb 2002 16:01:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 66B0F146804 for ; Mon, 11 Feb 2002 16:01:20 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA06466 for ; Mon, 11 Feb 2002 14:01:18 -0700 (MST) Message-ID: <3C6831A3.43AEEA49@jetnet.ab.ca> Date: Mon, 11 Feb 2002 14:03:31 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > > > I have based the design on transparent latches, > > they ensure that the cells are not too large and slow. > > It's almost completely asynchronous : reading is just > > combinational (the address is driven by the fetcher's > > Have you tought about test structures for ASIC manufacturing? Latches are > never fun thing to test. D-flipflops are so much easier to test with > normal scan paths. How ever Latches are 1/2 the size of flip-flops.I like latches as data flows through them but flip-flops stop the data flow until a good bit after the clock. Regardless scan paths are hard to test and design as your scan logic messes up your data logic. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 11 23:21:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzq-0004lH-01 for ; Wed, 13 Feb 2002 00:05:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:05:58 +0100 (CET) Received: (qmail 9112 invoked by uid 0); 11 Feb 2002 22:17:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 11 Feb 2002 22:17:08 -0000 Received: by moria.seul.org (Postfix) id 9A9FA146805; Mon, 11 Feb 2002 17:17:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 936A0146809; Mon, 11 Feb 2002 17:17:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 339E5146805 for ; Mon, 11 Feb 2002 17:17:06 -0500 (EST) Received: from f-cpu.org (kdl16-36.n.club-internet.fr [213.44.18.36]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 8C95B1698 for ; Mon, 11 Feb 2002 23:17:03 +0100 (CET) Message-ID: <3C6843F9.F33A1D6F@f-cpu.org> Date: Mon, 11 Feb 2002 23:21:45 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Fwd: Date'02] References: <3C6799AB.7F183154@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > Bonjour, > > Tout d'abord je souhaite la bienvenue au plus récent > inscrit de la liste, Bruno, et à qui je transmets > des informations qui vont intéresser d'autres personnes. > > Pour ceux qui ne le savent pas, DATE est LE salon > de la microélectronique. Si vous le ratez cette année, > il vous faudra aller à Munich l'année prochaine ;-) > D'autres le disent mieux que moi : > > -------- Original Message -------- ooops sorry i sent this to the wrong address.... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 11 20:22:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzr-0004lH-01 for ; Wed, 13 Feb 2002 00:05:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:05:59 +0100 (CET) Received: (qmail 7870 invoked by uid 0); 11 Feb 2002 22:57:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 11 Feb 2002 22:57:39 -0000 Received: by moria.seul.org (Postfix) id 520BD146806; Mon, 11 Feb 2002 17:57:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4053B14680B; Mon, 11 Feb 2002 17:57:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a192.home.uni-hannover.de [130.75.232.192]) by moria.seul.org (Postfix) with ESMTP id 5EA1B146806 for ; Mon, 11 Feb 2002 17:57:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00643; Mon, 11 Feb 2002 20:22:30 +0100 Message-ID: <20020211202230.32796@thrai.stud.uni-hannover.de> Date: Mon, 11 Feb 2002 20:22:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] back to VHDL References: <3C65CA3E.72CDB6C@f-cpu.org> <20020210030045.04033@thrai.stud.uni-hannover.de> <3C66A014.302C5F35@f-cpu.org> <20020211010710.36106@thrai.stud.uni-hannover.de> <3C6755F1.4C131A39@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C6755F1.4C131A39@f-cpu.org>; from Yann Guidon on Mon, Feb 11, 2002 at 06:26:09AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 11, 2002 at 06:26:09AM +0100, Yann Guidon wrote: [...] > here we speak about the bi-directionality of the unit, which is another > problem. One way to design the LSU is to use byte-wide write enables > and "dirty" bits, so what we have to do is shift the written word > so that it appears on the correct "alignment". If we don't > use the SHL, the shift spans 256 bits (with a maximum of 32 positions). It's not necessary to shift the word-to-write. First duplicate the least significant chunk (i.e., perform an SDUP), then duplicate the word until the cache line size is reached. After that, do a partial write. Reading is slightly different - get the correct word from the cache line, then do a little byte-shuffling (since we have alignment constraints, a word will not cross an 8-byte boundary). [...] > So there are 3 different units ? > - 1 bytewise SIMD (word-slices) > - 1 bitwise (shifts, rotations...) These two are currently implemented in the SHL, but I can separate them if necessary. > - 1 for the LSU (in fact 2 : one for each direction) > it's going to take some room... Not really. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Feb 12 01:02:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzv-0004lH-00 for ; Wed, 13 Feb 2002 00:06:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:03 +0100 (CET) Received: (qmail 16546 invoked by uid 0); 11 Feb 2002 23:57:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 11 Feb 2002 23:57:45 -0000 Received: by moria.seul.org (Postfix) id 9BEB9146809; Mon, 11 Feb 2002 18:57:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 977DD14681A; Mon, 11 Feb 2002 18:57:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C4200146809 for ; Mon, 11 Feb 2002 18:57:42 -0500 (EST) Received: from f-cpu.org (kdl11-19.n.club-internet.fr [213.44.9.19]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 58269169E for ; Tue, 12 Feb 2002 00:57:36 +0100 (CET) Message-ID: <3C685B8A.BE2B4341@f-cpu.org> Date: Tue, 12 Feb 2002 01:02:18 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Kim Enkovaara wrote: > > I have based the design on transparent latches, > > they ensure that the cells are not too large and slow. > > It's almost completely asynchronous : reading is just > > combinational (the address is driven by the fetcher's > > Have you tought about test structures for ASIC manufacturing? Latches are > never fun thing to test. D-flipflops are so much easier to test with > normal scan paths. concerning the R7 testing, i have an algorithm in mind that does not use scanpaths. It is implemented inside the BIST unit but before i go into details, it is : - faster - better - full speed (will catch HF-related faults like unwanted Xtalk or capacitance) - not dependent on an external scan controller On the production line, the BIST will detect a lot of faults but after bonding/packaging, some special software will have to run anyway, to catch faults that can't be detected otherwise, for specific control signals for example... But yes, i design with 100% testability in mind. We even learn the basics at the university, but what BIST will implement is derived from my work at a previous position... > --Kim then, Ben Franchuk wrote: > Kim Enkovaara wrote: > How ever Latches are 1/2 the size of flip-flops. certainly but ... the size of a "memory cell" (a set of 4 transistors) is small compared to the rest of the control logic that will read from 2 signals and select where to write (3 tristate buffers). One latch is almost the size of one tristate buffer so the important difference is in latching latency and "timing" (the sequence of signal levels). first, compared to a D flip-flop, a latch requires less transitions of the control signal. This is "good" for the operating frequency and the power consumption. Sencond, the written data is ready sooner than for a D flip-flop (the latch is transparent). So for me it doesn't look "evil". One of my worries is the design of a single cell. while i can layout a single latch, a 3R2W cell is a bit more complex... By the way, if people are "eager" to have a D-ff, i could probably reuse the dual-edge flip-flop idea and adapt it a bit... > I like latches as data > flows through them but flip-flops stop the data flow until a good bit > after the clock. Regardless scan paths are hard to test and design as > your scan logic messes up your data logic. The BIST unit is designed for this task. It seems that a scanpath is only needed for those bits that are out of the classical datapath, such as protection and configuration bits, cache and memory control... > Ben Franchuk - Dawn * 12/24 bit cpu * * and still running * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Feb 12 01:02:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16alzv-0004lH-01 for ; Wed, 13 Feb 2002 00:06:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:03 +0100 (CET) Received: (qmail 26905 invoked by uid 0); 11 Feb 2002 23:57:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 11 Feb 2002 23:57:52 -0000 Received: by moria.seul.org (Postfix) id 2CBFA14686E; Mon, 11 Feb 2002 18:57:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A55D146863; Mon, 11 Feb 2002 18:57:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B789614681A for ; Mon, 11 Feb 2002 18:57:45 -0500 (EST) Received: from f-cpu.org (kdl11-19.n.club-internet.fr [213.44.9.19]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 56FDA168A for ; Tue, 12 Feb 2002 00:57:41 +0100 (CET) Message-ID: <3C685B8F.1C0B9A76@f-cpu.org> Date: Tue, 12 Feb 2002 01:02:23 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Kim Enkovaara wrote: > > > - VHDL simulations are not easily parallelisable. > > A globaly adressable, distributed memory multiprocessor might give better > > results thanks to faster synchronisation, better internal bandwidth and > > smaller OS overhead. > > There has been many startups that have tried to create parallel > simulators, but none of them have succeded in it well enough to create > any real demand. And I'm quite sure that the big companies have also tried > to make parallel simulators. I heard from one manufacturer that the memory > latency and bandwidth needs negate the effects of parallelization.. It's > more wise to run one simulator on each individual processor and just run > many simulations in one machine, and not try to make one simulation > faster. Cedric also thinks that if we can translate VHDL to C, we can "speed up the simulation" (but i showed a counter example) and make it run on a non-PC platform. He mentionned Alpha, PPC and SUN examples but i would like to have an account on such a multiprocessor machine AND have the optimising, parallelizing compiler :-) I would like him to speak about his own ideas on the list, instead of me telling what he said... And in the end i remark that his suggestions were already though about by a lot of companies and the specialists (like Kim) know the results... Frankly, i'm still happy with Vanilla and Simili. When we will need speed, i'll dust off ncsim's documentations and that's already a good start for running some BIOS or things like that. Then, if we want to run mostly real-frequency sims, we'll ask sponsors and friends for FPGAs and/or emulators... Otherwise, like Cedric said, we can run the simulation on a 1GHz Athlon all week long at his school ;-) I guess i could also ask some CPU and quota from my university's admin on our largest computer. i think it's a 4-CPU SUN but then we'd need another ncsim licence :-( But before we can think about that, we have to finish the code. I say "we" because i'm not alone ! Though sometimes, i think that if Michael was more "active" i would feel less lonely ;-) it's not against Michael but directed to all those who do not write code :-( Damned, i think we're 80 on this list... > --Kim > ps. I would love to have a good parallel simulator :) now you understand why i was so excited when i was hired at Meta Systems :-) I hope i could still contact people there in the future. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Feb 12 02:01:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am01-0004lH-00 for ; Wed, 13 Feb 2002 00:06:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:09 +0100 (CET) Received: (qmail 28398 invoked by uid 0); 12 Feb 2002 01:01:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Feb 2002 01:01:10 -0000 Received: by moria.seul.org (Postfix) id D086914681A; Mon, 11 Feb 2002 20:01:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84EBB146863; Mon, 11 Feb 2002 20:01:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a192.home.uni-hannover.de [130.75.232.192]) by moria.seul.org (Postfix) with ESMTP id 97A9E14681A for ; Mon, 11 Feb 2002 20:01:04 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01638; Tue, 12 Feb 2002 02:01:02 +0100 Message-ID: <20020212020101.23502@thrai.stud.uni-hannover.de> Date: Tue, 12 Feb 2002 02:01:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 References: <3C685B8F.1C0B9A76@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C685B8F.1C0B9A76@f-cpu.org>; from Yann Guidon on Tue, Feb 12, 2002 at 01:02:23AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Feb 12, 2002 at 01:02:23AM +0100, Yann Guidon wrote: [...] > Cedric also thinks that if we can translate VHDL to C, we can "speed up > the simulation" (but i showed a counter example) and make it run > on a non-PC platform. He mentionned Alpha, PPC and SUN examples > but i would like to have an account on such a multiprocessor machine > AND have the optimising, parallelizing compiler :-) You can't afford such a beast. A dual UltraSPARC-III (750 MHz) with lots of RAM costs more than an average car (and I'm not talking about a 2CV, Fiat 500 or Volkswagen). And it's slower than a dual Pentium III. Alpha might be an option, but I haven't seen one that had enough memory. > I would like him to speak about his own ideas on the list, > instead of me telling what he said... And in the end i remark that > his suggestions were already though about by a lot of companies > and the specialists (like Kim) know the results... Why doesn't Cedric join us? If he's got something to say, I want to hear it. Maybe he's the one who triggers my imagination and makes me produce one of my crazy ideas. Or vice versa. [...] > But before we can think about that, we have to finish the code. Amen. > I say "we" because i'm not alone ! Though sometimes, i think that > if Michael was more "active" i would feel less lonely ;-) Too much activity is the root of all evil ;) > it's not against Michael but directed to all those who do not write code :-( > Damned, i think we're 80 on this list... I guess it's hard to jump into a project like this... you have to understand all the design issues of the F-CPU architecture in order to produce something useful. And you have to learn VHDL, which isn't easy either. Apropos lonely: what's going on in France? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bruno.bougard@imec.be Tue Feb 12 08:49:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am09-0004lH-00 for ; Wed, 13 Feb 2002 00:06:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:17 +0100 (CET) Received: (qmail 10815 invoked by uid 0); 12 Feb 2002 07:45:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 12 Feb 2002 07:45:57 -0000 Received: by moria.seul.org (Postfix) id 40359146849; Tue, 12 Feb 2002 02:45:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B195146853; Tue, 12 Feb 2002 02:45:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (dmz2.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id B1700146849 for ; Tue, 12 Feb 2002 02:45:53 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id IAA20867 for ; Tue, 12 Feb 2002 08:45:46 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 08:45:46 +0100 Message-ID: <3C68C8F1.DD1F3C64@imec.be> Date: Tue, 12 Feb 2002 08:49:05 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: <3C66844F.A8930F23@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2002 07:45:46.0764 (UTC) FILETIME=[484FC4C0:01C1B399] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > hello, > > the register set is almost finished. I still have to make > an exhaustive testbench and add the zero detector. > I have based the design on transparent latches, > they ensure that the cells are not too large and slow. Ouille ! Please don't do that ! latches are almost not-testable. For FF, you have scan-test. > It's almost completely asynchronous : Ouille 2 : to be avoided as much as possible. > reading is just > combinational (the address is driven by the fetcher's > output register) while writing is driven by the scheduler > queue's output. the write command of each cell is given > by the address decoder ANDed with the write mask, > so writing is allowed when the mask is enabled and the > data remain when the mask goes low. There are certainly > some setup&hold conditions to ensure but it looks interesting. > > Now i'm seeking real implementations and VHDL "wrappers" > of such a bank. I have looked a bit at the latest LEON sources > but they look too messy for me... Generally, optimized register-bank is provided by the technology vendor. I work currently with UMC and I have a RAM/register-bank compiler. This one generate behavioral description for the simulation and a 'blackbox' for the final layout. If you want to see how to implement such a structure efficiently, check e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. This is also a good book to learn design. Also, for what you want to do, a SRAM instance should be more efficient, notably regarding power consumption Bruno ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Feb 12 09:22:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0A-0004lH-00 for ; Wed, 13 Feb 2002 00:06:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:18 +0100 (CET) Received: (qmail 19514 invoked by uid 0); 12 Feb 2002 08:17:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 12 Feb 2002 08:17:52 -0000 Received: by moria.seul.org (Postfix) id 8AB24146861; Tue, 12 Feb 2002 03:17:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 886B9146860; Tue, 12 Feb 2002 03:17:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-101-80.ras.tesion.net [195.226.101.80]) by moria.seul.org (Postfix) with ESMTP id EEEA914685E for ; Tue, 12 Feb 2002 03:17:48 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aYCP-0002aw-00 for f-cpu@seul.org; Tue, 12 Feb 2002 09:22:01 +0100 Date: Tue, 12 Feb 2002 09:22:01 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: <3C68C8F1.DD1F3C64@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Bruno Bougard wrote: > Yann Guidon wrote: > > > hello, > > > > the register set is almost finished. I still have to make > > an exhaustive testbench and add the zero detector. > > I have based the design on transparent latches, > > they ensure that the cells are not too large and slow. > > Ouille ! Please don't do that ! latches are almost not-testable. For FF, > you have scan-test. It's harder to add failsafe approaches later when the storage parts have to keep their contence for quite a while and may not be clocked again during storage. > > It's almost completely asynchronous : > > Ouille 2 : to be avoided as much as possible. > > > reading is just > > combinational (the address is driven by the fetcher's > > output register) while writing is driven by the scheduler > > queue's output. the write command of each cell is given > > by the address decoder ANDed with the write mask, > > so writing is allowed when the mask is enabled and the > > data remain when the mask goes low. There are certainly > > some setup&hold conditions to ensure but it looks interesting. > > > > Now i'm seeking real implementations and VHDL "wrappers" > > of such a bank. I have looked a bit at the latest LEON sources > > but they look too messy for me... > > Generally, optimized register-bank is provided by the technology vendor. > I work currently with UMC and I have a RAM/register-bank compiler. This > one generate behavioral description for the simulation and a 'blackbox' > for the final layout. > If you want to see how to implement such a structure efficiently, check > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > This is also a good book to learn design. I can remember that they want to stay independent of technology vendor libraries and structure compilers that are not freely available. > Also, for what you want to do, a SRAM instance should be more efficient, > notably regarding power consumption Usually you can't read and write in the same clock. You may be forced to use multiport SRAM. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bruno.bougard@imec.be Tue Feb 12 10:00:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0C-0004lH-01 for ; Wed, 13 Feb 2002 00:06:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:20 +0100 (CET) Received: (qmail 22938 invoked by uid 0); 12 Feb 2002 08:57:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 12 Feb 2002 08:57:04 -0000 Received: by moria.seul.org (Postfix) id 8CAE814685F; Tue, 12 Feb 2002 03:57:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89D3114685E; Tue, 12 Feb 2002 03:57:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (dmz2.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id A580C14684A for ; Tue, 12 Feb 2002 03:56:59 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id JAA30708 for ; Tue, 12 Feb 2002 09:56:56 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 09:56:56 +0100 Message-ID: <3C68D99F.4F3832D@imec.be> Date: Tue, 12 Feb 2002 10:00:15 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2002 08:56:56.0037 (UTC) FILETIME=[38FF2150:01C1B3A3] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > Yann Guidon wrote: > > > > > hello, > > > > > > the register set is almost finished. I still have to make > > > an exhaustive testbench and add the zero detector. > > > I have based the design on transparent latches, > > > they ensure that the cells are not too large and slow. > > > > Ouille ! Please don't do that ! latches are almost not-testable. For FF, > > you have scan-test. > > It's harder to add failsafe approaches later when the storage > parts have to keep their contence for quite a while and may > not be clocked again during storage. > > > > It's almost completely asynchronous : > > > > Ouille 2 : to be avoided as much as possible. > > > > > reading is just > > > combinational (the address is driven by the fetcher's > > > output register) while writing is driven by the scheduler > > > queue's output. the write command of each cell is given > > > by the address decoder ANDed with the write mask, > > > so writing is allowed when the mask is enabled and the > > > data remain when the mask goes low. There are certainly > > > some setup&hold conditions to ensure but it looks interesting. > > > > > > Now i'm seeking real implementations and VHDL "wrappers" > > > of such a bank. I have looked a bit at the latest LEON sources > > > but they look too messy for me... > > > > Generally, optimized register-bank is provided by the technology vendor. > > I work currently with UMC and I have a RAM/register-bank compiler. This > > one generate behavioral description for the simulation and a 'blackbox' > > for the final layout. > > If you want to see how to implement such a structure efficiently, check > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > > This is also a good book to learn design. > > I can remember that they want to stay independent of technology > vendor libraries and structure compilers that are not freely > available. In that case, the best is to write a common interface in which you will encapsule the module provided by the technology vendor when you will process the chip. Meanwhile, you can work with a behavioral model that you can write easily looking at the spec of a 'typical' register bank. > Also, for what you want to do, a SRAM instance should be more efficient, > > notably regarding power consumption > > Usually you can't read and write in the same clock. You may > be forced to use multiport SRAM. just 2-port SRAM which are quite efficient now. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Feb 12 10:19:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0D-0004lH-00 for ; Wed, 13 Feb 2002 00:06:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:21 +0100 (CET) Received: (qmail 20251 invoked by uid 0); 12 Feb 2002 09:15:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Feb 2002 09:15:25 -0000 Received: by moria.seul.org (Postfix) id 94983146843; Tue, 12 Feb 2002 04:15:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E5DB146853; Tue, 12 Feb 2002 04:15:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 5CD09146843 for ; Tue, 12 Feb 2002 04:15:23 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aZ65-0002fe-00 for f-cpu@seul.org; Tue, 12 Feb 2002 10:19:33 +0100 Date: Tue, 12 Feb 2002 10:19:33 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: <3C68D99F.4F3832D@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Bruno Bougard wrote: > Juergen Goeritz wrote: > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > > Generally, optimized register-bank is provided by the technology vendor. > > > I work currently with UMC and I have a RAM/register-bank compiler. This > > > one generate behavioral description for the simulation and a 'blackbox' > > > for the final layout. > > > If you want to see how to implement such a structure efficiently, check > > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > > > This is also a good book to learn design. > > > > I can remember that they want to stay independent of technology > > vendor libraries and structure compilers that are not freely > > available. > > In that case, the best is to write a common interface in which you will > encapsule the module provided by the technology vendor when you will process > the chip. Meanwhile, you can work with a behavioral model that you can write > easily looking at the spec of a 'typical' register bank. Here we are again. Do we use pre-made modules in our design or do we use a behavioural description? It reminds me a lot of the 74xx ttl devices which were formerly used heavily on PCBs and a lot of hardware guys never quit thinking this way. I would rather prefer a tool that automatically detects regular structures in a behavioural model and replaces them during compilation by vendor type things. But why force the designer to use this stuff or take care of this stuff by wrappers already in the design process??? Those tools suck! Hoops, this is one of the topics that can really make me upset! ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Feb 12 10:28:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0F-0004lH-00 for ; Wed, 13 Feb 2002 00:06:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:23 +0100 (CET) Received: (qmail 26447 invoked by uid 0); 12 Feb 2002 09:24:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Feb 2002 09:24:21 -0000 Received: by moria.seul.org (Postfix) id C1D76146860; Tue, 12 Feb 2002 04:24:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF02714685E; Tue, 12 Feb 2002 04:24:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 6D3A014684A for ; Tue, 12 Feb 2002 04:24:18 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aZF9-0002gd-00 for f-cpu@seul.org; Tue, 12 Feb 2002 10:28:55 +0100 Date: Tue, 12 Feb 2002 10:28:55 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Juergen Goeritz wrote: > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > Juergen Goeritz wrote: > > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > > > Generally, optimized register-bank is provided by the technology vendor. > > > > I work currently with UMC and I have a RAM/register-bank compiler. This > > > > one generate behavioral description for the simulation and a 'blackbox' > > > > for the final layout. > > > > If you want to see how to implement such a structure efficiently, check > > > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > > > > This is also a good book to learn design. > > > > > > I can remember that they want to stay independent of technology > > > vendor libraries and structure compilers that are not freely > > > available. > > > > In that case, the best is to write a common interface in which you will > > encapsule the module provided by the technology vendor when you will process > > the chip. Meanwhile, you can work with a behavioral model that you can write > > easily looking at the spec of a 'typical' register bank. > > Here we are again. Do we use pre-made modules in our design > or do we use a behavioural description? It reminds me a lot > of the 74xx ttl devices which were formerly used heavily on > PCBs and a lot of hardware guys never quit thinking this way. > > I would rather prefer a tool that automatically detects regular > structures in a behavioural model and replaces them during > compilation by vendor type things. But why force the designer > to use this stuff or take care of this stuff by wrappers > already in the design process??? Those tools suck! > > Hoops, this is one of the topics that can really make me upset! ;-) BTW, don't you have a generator tool for creating the behavioural model out of your optimized macros? A lot of designers would love to take a close look into these behavioural models... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bruno.bougard@imec.be Tue Feb 12 10:35:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0I-0004lH-00 for ; Wed, 13 Feb 2002 00:06:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:26 +0100 (CET) Received: (qmail 9208 invoked by uid 0); 12 Feb 2002 09:32:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Feb 2002 09:32:39 -0000 Received: by moria.seul.org (Postfix) id 38267146853; Tue, 12 Feb 2002 04:32:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 33F8A146862; Tue, 12 Feb 2002 04:32:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (dmz2.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id 5240D146853 for ; Tue, 12 Feb 2002 04:32:37 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id KAA02256 for ; Tue, 12 Feb 2002 10:32:36 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 10:32:36 +0100 Message-ID: <3C68E1FC.6D18F723@imec.be> Date: Tue, 12 Feb 2002 10:35:56 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2002 09:32:36.0893 (UTC) FILETIME=[350BD4D0:01C1B3A8] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > Juergen Goeritz wrote: > > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > > > Generally, optimized register-bank is provided by the technology vendor. > > > > I work currently with UMC and I have a RAM/register-bank compiler. This > > > > one generate behavioral description for the simulation and a 'blackbox' > > > > for the final layout. > > > > If you want to see how to implement such a structure efficiently, check > > > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > > > > This is also a good book to learn design. > > > > > > I can remember that they want to stay independent of technology > > > vendor libraries and structure compilers that are not freely > > > available. > > > > In that case, the best is to write a common interface in which you will > > encapsule the module provided by the technology vendor when you will process > > the chip. Meanwhile, you can work with a behavioral model that you can write > > easily looking at the spec of a 'typical' register bank. > > Here we are again. Do we use pre-made modules in our design > or do we use a behavioural description? It reminds me a lot > of the 74xx ttl devices which were formerly used heavily on > PCBs and a lot of hardware guys never quit thinking this way. That's archeology for me ... > I would rather prefer a tool that automatically detects regular > structures in a behavioural model and replaces them during > compilation by vendor type things. But why force the designer > to use this stuff or take care of this stuff by wrappers > already in the design process??? Those tools suck! I agree with you but, unfortunatelly, those tools does not work so good, they are affected by the coding style. Trial with the xilinx FPGA tools for instance which support both approach. And on the philosophical point of view I agree with you but on the practical point of view, do you really want to redesign basics blocs such RAM, filebuffer ??? Do you really want to redesign the whole library ? And after all, your design is finally based on so-called 'standard cell'. Is this so far from the 74xx approach, ? ;) > > > Hoops, this is one of the topics that can really make me upset! ;-) > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Feb 12 12:05:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0P-0004lH-01 for ; Wed, 13 Feb 2002 00:06:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:33 +0100 (CET) Received: (qmail 5214 invoked by uid 0); 12 Feb 2002 11:04:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 12 Feb 2002 11:04:08 -0000 Received: by moria.seul.org (Postfix) id 36EB114684A; Tue, 12 Feb 2002 06:04:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C678146863; Tue, 12 Feb 2002 06:04:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 28C8A14684A for ; Tue, 12 Feb 2002 06:04:04 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16aakG-0002lK-00 for f-cpu@seul.org; Tue, 12 Feb 2002 12:05:08 +0100 Date: Tue, 12 Feb 2002 12:05:08 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: <3C68E1FC.6D18F723@imec.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Bruno Bougard wrote: > Juergen Goeritz wrote: > > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > > Juergen Goeritz wrote: > > > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > > > > Generally, optimized register-bank is provided by the technology vendor. > > > > > I work currently with UMC and I have a RAM/register-bank compiler. This > > > > > one generate behavioral description for the simulation and a 'blackbox' > > > > > for the final layout. > > > > > If you want to see how to implement such a structure efficiently, check > > > > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley. > > > > > This is also a good book to learn design. > > > > > > > > I can remember that they want to stay independent of technology > > > > vendor libraries and structure compilers that are not freely > > > > available. > > > > > > In that case, the best is to write a common interface in which you will > > > encapsule the module provided by the technology vendor when you will process > > > the chip. Meanwhile, you can work with a behavioral model that you can write > > > easily looking at the spec of a 'typical' register bank. > > > > Here we are again. Do we use pre-made modules in our design > > or do we use a behavioural description? It reminds me a lot > > of the 74xx ttl devices which were formerly used heavily on > > PCBs and a lot of hardware guys never quit thinking this way. > > That's archeology for me ... I worked with it and with real behavioural description later. > > I would rather prefer a tool that automatically detects regular > > structures in a behavioural model and replaces them during > > compilation by vendor type things. But why force the designer > > to use this stuff or take care of this stuff by wrappers > > already in the design process??? Those tools suck! > > I agree with you but, unfortunatelly, those tools does not work so > good, they are affected by the coding style. Trial with the xilinx > FPGA tools for instance which support both approach. They may not have a good intermediate representation to find them their macros? Or is it that they don't find the parts of their macros spreaded over the designers behavioural modules? But for Xilinx it may be also due to the different possible use of their cells, logic vs. ram. > And on the philosophical point of view I agree with you but on the > practical point of view, do you really want to redesign basics blocs > such RAM, filebuffer ??? Do you really want to redesign the whole > library ? God beware! No, that wasn't the point. The point is to extract basic macro functions out of the behavioural design to save both space and layout cost (and delay time of course). And to give backannotation hints to the designer which specialities of his design prevent from using them. This would give more freedom to the designers. But on the other hand this may also be an indication that a lot of the design already gets lost when you write it down in VHDL, i.e. translation from mind to VHDL to compiler to gates/cells. The designer knows what he wants, the VHDL implementation does not because you can't implement the different possibilities of views and dependencies. The compiler only extracts parts from the implementation and converts or optimizes it for real gates/cells. Most of the time I can imagine more than one way to implement a design. BUT there is no tool on the market which makes it possible to describe these ways alltogether easily and checks for plausibility between them and the final behaviour seen >from outside of the unit (expected behaviour). Something like a multi-parallel path design description. Sometimes it's a pity that one is forced to an implementation already in the early stages of a design. > And after all, your design is finally based on so-called 'standard cell'. Is > this so far from the 74xx approach, ? ;) Ha, ha, ha - that one really got to me! Oh, and they are all based on transistors. Welcome back to the old days in new clothes. ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Tue Feb 12 13:53:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0R-0004lH-01 for ; Wed, 13 Feb 2002 00:06:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:35 +0100 (CET) Received: (qmail 4241 invoked by uid 0); 12 Feb 2002 12:53:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 12 Feb 2002 12:53:50 -0000 Received: by moria.seul.org (Postfix) id F230D146862; Tue, 12 Feb 2002 07:53:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE284146871; Tue, 12 Feb 2002 07:53:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 27D56146862 for ; Tue, 12 Feb 2002 07:53:49 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id OAA11645 for ; Tue, 12 Feb 2002 14:53:48 +0200 Date: Tue, 12 Feb 2002 14:53:47 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I would rather prefer a tool that automatically detects regular > structures in a behavioural model and replaces them during > compilation by vendor type things. But why force the designer > to use this stuff or take care of this stuff by wrappers > already in the design process??? Those tools suck! There are such tools, but they are for FPGAs. Good FPGA synthesizers (Synplify and Leonardo) can find for example all memories even if they are written in behavioral style and convert them to vendor macros. Some pragmas might be needed to give some hints what kind of memory is really wanted (distributed, block etc.). Of course you can't code with any style, but the tools are quite good. They know things like 2-port memories etc. Also those tools find quite funny vendor blocks from the designs sometimes to speed up things (shift registers for example are a good example). Unfortunately Synopsys DC doesn't support this with links to vendor libraries and block generators. That would be fantastic feature :) --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Feb 12 18:55:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0e-0004lH-00 for ; Wed, 13 Feb 2002 00:06:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:48 +0100 (CET) Received: (qmail 830 invoked by uid 0); 12 Feb 2002 17:53:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Feb 2002 17:53:29 -0000 Received: by moria.seul.org (Postfix) id E8EFE146880; Tue, 12 Feb 2002 12:53:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DEBF0146882; Tue, 12 Feb 2002 12:53:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 2EFE8146880 for ; Tue, 12 Feb 2002 12:53:27 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA12699 for ; Tue, 12 Feb 2002 10:53:24 -0700 (MST) Message-ID: <3C695711.A78CC712@jetnet.ab.ca> Date: Tue, 12 Feb 2002 10:55:29 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: <3C66844F.A8930F23@f-cpu.org> <3C68C8F1.DD1F3C64@imec.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Bruno Bougard wrote: > Ouille ! Please don't do that ! latches are almost not-testable. For FF, > you have scan-test. Strange every FF I have seen is made up of latches.Scan testing is only one way of testing a device. Testing however has to be designed with a architecture in mind not as a add on feature. Cmos - circuit design, layout and simulation ISBN 0-7803-3416-7 also is a nice book. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Feb 12 19:07:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0e-0004lH-01 for ; Wed, 13 Feb 2002 00:06:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:48 +0100 (CET) Received: (qmail 13072 invoked by uid 0); 12 Feb 2002 18:03:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 12 Feb 2002 18:03:48 -0000 Received: by moria.seul.org (Postfix) id 4C4D6146885; Tue, 12 Feb 2002 13:03:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 49DE1146884; Tue, 12 Feb 2002 13:03:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 3DCF7146881 for ; Tue, 12 Feb 2002 13:03:40 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ahL7-0002wy-00 for f-cpu@seul.org; Tue, 12 Feb 2002 19:07:37 +0100 Date: Tue, 12 Feb 2002 19:07:37 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Kim Enkovaara wrote: > > I would rather prefer a tool that automatically detects regular > > structures in a behavioural model and replaces them during > > compilation by vendor type things. But why force the designer > > to use this stuff or take care of this stuff by wrappers > > already in the design process??? Those tools suck! > > There are such tools, but they are for FPGAs. Good FPGA synthesizers > (Synplify and Leonardo) can find for example all memories even if they are > written in behavioral style and convert them to vendor macros. Some > pragmas might be needed to give some hints what kind of memory is really > wanted (distributed, block etc.). Of course you can't code with any style, > but the tools are quite good. They know things like 2-port memories etc. > Also those tools find quite funny vendor blocks from the designs sometimes > to speed up things (shift registers for example are a good example). Think I may try Synplify on my some new designs. I heard they also have an ASIC generator now but I didn't hear about the quality of the generated gates so far. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Feb 12 19:24:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0g-0004lH-00 for ; Wed, 13 Feb 2002 00:06:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:50 +0100 (CET) Received: (qmail 30995 invoked by uid 0); 12 Feb 2002 18:22:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 12 Feb 2002 18:22:43 -0000 Received: by moria.seul.org (Postfix) id 08FCC146881; Tue, 12 Feb 2002 13:22:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0433F146884; Tue, 12 Feb 2002 13:22:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 5C217146881 for ; Tue, 12 Feb 2002 13:22:41 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA14178 for ; Tue, 12 Feb 2002 11:22:40 -0700 (MST) Message-ID: <3C695DED.F7927780@jetnet.ab.ca> Date: Tue, 12 Feb 2002 11:24:45 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > And on the philosophical point of view I agree with you but on the > > practical point of view, do you really want to redesign basics blocs > > such RAM, filebuffer ??? Do you really want to redesign the whole > > library ? > > God beware! No, that wasn't the point. The point is to extract > basic macro functions out of the behavioural design to save > both space and layout cost (and delay time of course). And to > give backannotation hints to the designer which specialities of > his design prevent from using them. This would give more freedom > to the designers. I see all HDL as F**King useless as being portable and free because 1) Hardware feature sets are not portable like FPGA's. Brand X has dual port ram , Brand A has block ram 2) Useful operations like addition with carry in,out and overflow are not supported in the language. You end up reinventing the wheel. 3) The source luke ... use the source ... what source for the libraries? 4) You still have to have two versions of source, 1 for simulation and 1 for real gates. Easy to get them out of sync. 5) Hard to get at real transistors! > But on the other hand this may also be an indication that a lot > of the design already gets lost when you write it down in VHDL, > i.e. translation from mind to VHDL to compiler to gates/cells. > > Sometimes it's a pity that one is forced to an implementation > already in the early stages of a design. I think a RTL style language is best, not vhdl or verlog. Mind you the last nice RTL language I saw was for punched cards computer and output to FORTRAN as simulation. (A yellow book if I remember right with a title like Register transfer language and simulation ) -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nomorespamx@lycos.com Tue Feb 12 21:41:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16am0o-0004lH-00 for ; Wed, 13 Feb 2002 00:06:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 00:06:58 +0100 (CET) Received: (qmail 16645 invoked by uid 0); 12 Feb 2002 20:42:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 12 Feb 2002 20:42:08 -0000 Received: by moria.seul.org (Postfix) id 23766146882; Tue, 12 Feb 2002 15:42:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 17856146886; Tue, 12 Feb 2002 15:42:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by moria.seul.org (Postfix) with SMTP id 0DC55146882 for ; Tue, 12 Feb 2002 15:42:04 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Feb 12 12:41:51 2002 To: f-cpu@seul.org Date: Tue, 12 Feb 2002 15:41:51 -0500 From: "no spam" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Priority: 3 Subject: [f-cpu] Question and Ideas X-Sender-Ip: 202.134.2.133 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi I have several question and ideas: 1. What is the present status of F-CPU? 2. Can the webmaster create an easy to navigate, multiple pages website? 3. Is it possible to create F-CPU documents using PDF format? (easy to read and print). 4. Is it possible to create Prototype of F-CPU in co-operation with local universities and EUROPRACTICE, TIMA-CMP, ALBA, etc? 5. Where is the evaluation board for F-CPU? 6. Is there any LINUX port to F-CPU? 7. Is it possible to port BOCHS (X86 emulator), and portability tools, such as ANDF (ESPRIT), AMIGA DE, or JUICE (FTH Swiss)? 8. Can F-CPU compete with Pentium IV 2.2 GHz, PowerPC G5, AMD CLAWHAMMER, Transmeta Crusoe, ITANIUM, ARM 10 etc? 9. What is the implementation of F-CPU, is it FPGA, ASIC, VARICORE or something else? 10. I have idea about creating hand crank Wireless PDA for low cost Internet access device in Africa, similar to SIMPUTER project in INDIA (fund from UN / EU). Is it possible to use F-CPU on this project? Thank you. http://www.info-france-usa.org/news/statmnts/africa.asp http://www.europa.eu.int/comm/dgs/europeaid/index_en.htm http://www.un.org/esa/coordination/ecosoc/itforum/icttaskforce.htm http://www.un.org/esa/coordination/ecosoc/itforum/expert.htm http://www.freeplay.net/new/newsite/news/fintimes.html http://www.simputer.org Go Get It! Send FREE Valentine eCards with Lycos Greetings http://greetings.lycos.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Feb 13 08:04:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16atrl-0001ll-00 for ; Wed, 13 Feb 2002 08:30:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 08:30:09 +0100 (CET) Received: (qmail 11025 invoked by uid 0); 13 Feb 2002 06:59:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 13 Feb 2002 06:59:29 -0000 Received: by moria.seul.org (Postfix) id C85E3146812; Wed, 13 Feb 2002 01:59:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9EBB3146822; Wed, 13 Feb 2002 01:59:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 3BE64146812 for ; Wed, 13 Feb 2002 01:59:27 -0500 (EST) Received: from f-cpu.org (kdl21-90.n.club-internet.fr [213.44.96.90]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 0660816B9 for ; Wed, 13 Feb 2002 07:59:21 +0100 (CET) Message-ID: <3C6A0FE7.3B17CCE8@f-cpu.org> Date: Wed, 13 Feb 2002 08:04:07 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Question and Ideas References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello and welcome, whoever you are. Though you don't seem to come from another planet :-) no spam wrote: > Hi > I have several question and ideas: > > 1. What is the present status of F-CPU? * writing VHDL sources for the "execution pipeline". Next stages will then be the scheduler, then the memory interface (including L1 caches) and finally the exception/irq handlers+IRQ controller. * the manual is too old now, it should be deeply updated but we write VHDL and now "the source is the documentation". * website update : someone volunteered in france, he made a prototype of the new design at http://geeno.free.fr (from memory). * We are still trying to create an "association" in France. We are in contact with a CS school in Paris where we can have some support. * the F-CPU community is invited in Bordeaux in July for the LSM (Libre Software Meeting) by the organisers. i am waiting for the official invitation to appear on the f-cpu lists. > 2. Can the webmaster create an easy to navigate, multiple pages website? who ? a webmaster ? "We're electronicians" ;-) Making websites is not as cool as in the beginning, mainly because there are a lot of F-CPU ressources scattered around the Web, some of them are even abandonned and the password disappeared. If you want to help, or know volunteers, we'll be very very happy. > 3. Is it possible to create F-CPU documents using PDF format? (easy to read and print). Officially, the F-CPU manual is now written in LaTeX format. This makes it easy for diffusion in PS and PDF formats, for example. > 4. Is it possible to create Prototype of F-CPU in co-operation with local > universities and EUROPRACTICE, TIMA-CMP, ALBA, etc? (you forgot MOSIS ;-)) it should be. But the economics and politics of these programs are not fun. for this to work we'd need support from at least ONE client university, leaning that one or more doctorate level student spends 100% time on it, thus money etc... I am currently in a university department where they design chips and let me tell you : it's not a supermarket. Even if the university shares the price of the waffers, it's still VERY expensive to make a chip and from experience it is also not likely to work on the first power-up... > 5. Where is the evaluation board for F-CPU? none yet. however you can have a look at the first f-cpu sources at http://f-cpu.seul.org/new > 6. Is there any LINUX port to F-CPU? not yet. some f-cpu enthusiasts and subscribers are good at kernels but the core of the Freedom CPU project is about CPU architecture, not SW or kernels : this is to avoid losing energy with useless discussions. If a kernel port is to take place, a "parallel" project must be created. The operating system interface is not yet fully determined so we are still open about what features must or must not be implemented. > 7. Is it possible to port BOCHS (X86 emulator), and portability tools, > such as ANDF (ESPRIT), AMIGA DE, or JUICE (FTH Swiss)? if you can port GCC, why not. but F-CPU is an architecture oriented towards performance for low price and GCC is not designed for this, so a GCC port is as difficult as making a wafer... > 8. Can F-CPU compete with Pentium IV 2.2 GHz, PowerPC G5, AMD CLAWHAMMER, > Transmeta Crusoe, ITANIUM, ARM 10 etc? sorry, F-CPU is an architecture. You are speaking about implementations. When F-CPU started, the computer at that time were Pentium II at 300MHz, btw... F-CPU leaves certain options open _on_purpose_ so the implementor can define a price/performance/scalability point. Frequency is explicitely not our point because we already chose superpipeline, meaning that the operating frequency depends on your EDA tool's optimisation capabilities and the silicon process you can access. > 9. What is the implementation of F-CPU, is it FPGA, ASIC, VARICORE or something else? it's... VHDL :-) theoretically you can "synthesise" VHDL to any electronic platform, whether FPGA, full-custom, semi-custom, sea-of-gates... in practice, the recent discussions on this group (about the register set) showed that it's not so simple. But VHDL is a langage which allows us to NOT duplicate most parts of the design, whatever the target implementation is. nd by the way, implementing the current F-CPU core ("FC0") on a FPGA requires a pretty huge FPGA which is extremely expensive... > 10. I have idea about creating hand crank Wireless PDA for low cost Internet > access device in Africa, I'm not a specialist but the wireless infrastructure varies wildly from region to region... > similar to SIMPUTER project in INDIA (fund from UN / EU). > Is it possible to use F-CPU on this project? it is not impossible, but you may loose a lot of time waiting for F-CPU to become a real chip. You can probably reuse the simputer and/or Leon. Other projects (mostly unfinished) can be found on the database of http://www.opencollector.org > Thank you. I hope this helps, read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Feb 13 08:23:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV3-0006UD-00 for ; Wed, 13 Feb 2002 14:31:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:05 +0100 (CET) Received: (qmail 32185 invoked by uid 0); 13 Feb 2002 07:18:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Feb 2002 07:18:47 -0000 Received: by moria.seul.org (Postfix) id 65A5A146822; Wed, 13 Feb 2002 02:18:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54591146825; Wed, 13 Feb 2002 02:18:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-101-61.ras.tesion.net [195.226.101.61]) by moria.seul.org (Postfix) with ESMTP id CF934146822 for ; Wed, 13 Feb 2002 02:18:43 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16atlM-0003Kz-00 for f-cpu@seul.org; Wed, 13 Feb 2002 08:23:32 +0100 Date: Wed, 13 Feb 2002 08:23:31 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: <3C695DED.F7927780@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 12 Feb 2002, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > And on the philosophical point of view I agree with you but on the > > > practical point of view, do you really want to redesign basics blocs > > > such RAM, filebuffer ??? Do you really want to redesign the whole > > > library ? > > > > God beware! No, that wasn't the point. The point is to extract > > basic macro functions out of the behavioural design to save > > both space and layout cost (and delay time of course). And to > > give backannotation hints to the designer which specialities of > > his design prevent from using them. This would give more freedom > > to the designers. > > I see all HDL as F**King useless as being portable and free because > 1) Hardware feature sets are not portable like FPGA's. Brand X has dual > port ram , Brand A has block ram > 2) Useful operations like addition with carry in,out and overflow are > not supported in the language. You end up reinventing the wheel. > 3) The source luke ... use the source ... what source for the libraries? > 4) You still have to have two versions of source, 1 for simulation and 1 > for real gates. Easy to get them out of sync. > 5) Hard to get at real transistors! Yes, that's what I see all the time. Changing vendors isn't really easy. There is a need to define an own process down to the layout of cells or transistors. Simulation has to be consistent on all levels. And I rather want to simulate the software too before I go for silicon. > > But on the other hand this may also be an indication that a lot > > of the design already gets lost when you write it down in VHDL, > > i.e. translation from mind to VHDL to compiler to gates/cells. > > > > Sometimes it's a pity that one is forced to an implementation > > already in the early stages of a design. > > I think a RTL style language is best, not vhdl or verlog. Mind you the > last nice RTL language I saw was for punched cards computer and output > to FORTRAN as simulation. > (A yellow book if I remember right with a title like Register transfer > language and simulation ) I worked a lot with table driven input languages. Contrary to VHDL you see at the first view how the signals behave. With VHDL you first have to activate your inner interpreter to analyse the code before you have the essence. With tables you take one look and you have the essence. With tables the outputs are not hidden behind a program structure. That's what I think of being the most disadvantage of VHDL. You write a program to create a table that the optimizer must extract >from the written code. The complexity does not lead to best results. It's like writing all your email using SMS on a wireless phone. Which means one has to concentrate on the input process and hardly the contence. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 10:09:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV6-0006UD-01 for ; Wed, 13 Feb 2002 14:31:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:08 +0100 (CET) Received: (qmail 15745 invoked by uid 0); 13 Feb 2002 09:11:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 13 Feb 2002 09:11:33 -0000 Received: by moria.seul.org (Postfix) id 8B4A81463AB; Wed, 13 Feb 2002 04:11:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6E47B14680A; Wed, 13 Feb 2002 04:11:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 918D21463AB for ; Wed, 13 Feb 2002 04:11:30 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 09:09:48 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] No latches, please ! From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 09:09:48 GMT Message-id: <200202130909.3083@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I have miss that : please NO LATCH in our design !!!! It's almost useless compare to classique flip-flop. I have said nothing for the register set because of the speed. But latch are generaly a very very bad idea. It's almost impossible to test correctly and a lot of tools have problem with them (static timing analysis, compiler ...). -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 11/02/02 Objet: Re: [f-cpu] vhdl2c 0.1 A good example is the multiplier : the input data latch should memorise =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 10:32:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV6-0006UD-02 for ; Wed, 13 Feb 2002 14:31:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:08 +0100 (CET) Received: (qmail 27321 invoked by uid 0); 13 Feb 2002 09:32:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 13 Feb 2002 09:32:44 -0000 Received: by moria.seul.org (Postfix) id A6E5F1467F7; Wed, 13 Feb 2002 04:32:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9E028146824; Wed, 13 Feb 2002 04:32:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 914331467F7 for ; Wed, 13 Feb 2002 04:32:42 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 09:32:19 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] register set, latches From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 09:32:19 GMT Message-id: <200202130932.13d1@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 12/02/02 Objet: Re: [f-cpu] register set hello, <..> By the way, if people are "eager" to have a D-ff, i could probably reuse the dual-edge flip-flop idea and adapt it a bit... ---- >>>> Dual-edge ???? No, we will use normal cell find in every technology and not a special thing that could only be manualy implemented. Please, think only on rising edge D-flipflop (or RS). Even using falling edge flipflop is a very bad idea, some technology used a not gate before the clock entrance to simulate the right beaviour. For large "storage" area like register bank, memories,caches, TLB, ... we need to create specific entites that could used specific macrobloc of the technology (internal memory in Xilinx, compiled SRAM for semi-custom chip,...) nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 11:16:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV7-0006UD-00 for ; Wed, 13 Feb 2002 14:31:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:09 +0100 (CET) Received: (qmail 9587 invoked by uid 0); 13 Feb 2002 10:16:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 13 Feb 2002 10:16:34 -0000 Received: by moria.seul.org (Postfix) id E01F714680A; Wed, 13 Feb 2002 05:16:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CACCC146825; Wed, 13 Feb 2002 05:16:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 1320E14680A for ; Wed, 13 Feb 2002 05:16:31 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 10:16:06 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] register set From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 10:16:06 GMT Message-id: <200202131016.06e7@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 12/02/02 Objet: Re: [f-cpu] register set On Tue, 12 Feb 2002, Bruno Bougard wrote: > Yann Guidon wrote: > Usually you can't read and write in the same clock. You may be forced to use multiport SRAM. >>> Double ported SRAM are common. (2 read ports and 2 write ports). That's why i don't like the idea to have a 3r2w register bank, so we must used "usual" vhdl and it will be slow and fat on the silicium. nicO JG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Feb 13 11:34:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV8-0006UD-01 for ; Wed, 13 Feb 2002 14:31:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:10 +0100 (CET) Received: (qmail 5154 invoked by uid 0); 13 Feb 2002 10:30:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 13 Feb 2002 10:30:00 -0000 Received: by moria.seul.org (Postfix) id A44E1146824; Wed, 13 Feb 2002 05:29:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89F50146826; Wed, 13 Feb 2002 05:29:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CE2D3146824 for ; Wed, 13 Feb 2002 05:29:56 -0500 (EST) Received: from f-cpu.org (kdl21-141.n.club-internet.fr [213.44.96.141]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2848916D1 for ; Wed, 13 Feb 2002 11:29:52 +0100 (CET) Message-ID: <3C6A413D.5D7E6643@f-cpu.org> Date: Wed, 13 Feb 2002 11:34:37 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: <3C695DED.F7927780@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i did not step into this discussion mainly because of lack of time. And also because i don't have the intention to argue (everybody has a point), i simply search a way to design a portable register set in VHDL. Fortunately, VHDL provides a way to decouple the interface >from the implementation : the "entity" and the "architectures" so when someone targets a specific technology, he adds a new architecture and respects the interface that was defined in the "entity". If his technology provides a 1-to-1 mapping of the desired function : fine :-) otherwise, a certain amount of code is necessary to "wrap" the physical entity. Ben Franchuk wrote: > Juergen Goeritz wrote: > > > And on the philosophical point of view I agree with you but on the > > > practical point of view, do you really want to redesign basics blocs > > > such RAM, filebuffer ??? Do you really want to redesign the whole > > > library ? it didn't take long to write the 3R2W buffers, btw. but it's only a "behavioural" description. > > God beware! No, that wasn't the point. The point is to extract > > basic macro functions out of the behavioural design to save > > both space and layout cost (and delay time of course). And to > > give backannotation hints to the designer which specialities of > > his design prevent from using them. This would give more freedom > > to the designers. > > I see all HDL as F**King useless as being portable and free because > 1) Hardware feature sets are not portable like FPGA's. Brand X has dual > port ram , Brand A has block ram that's why VHDL is used : to hide these implementation details. whether bad or good, i won't argue. Concerning F-CPU which is to be retargetable, it is a nice thing. Currently there is no target technology, so we can write our code freely and concentrate on the function and behaviour rather than focusing on performance right now. It's like writing in C : i hate it but it's used almost everywhere (except that i don't hate VHDL and VHDL is not a widespread langage, but it's another troll ;-D). > 2) Useful operations like addition with carry in,out and overflow are > not supported in the language. You end up reinventing the wheel. i agree with you here. but you know, "design by committee"... like here, they have to stop talking before they can do things, and then maybe they are good. > 3) The source luke ... use the source ... what source for the libraries? what do you mean by libraries ? btw, we use only IEEE libraries. When we need something else, we write a new package that holds the F-CPU copyright. > 4) You still have to have two versions of source, 1 for simulation and 1 > for real gates. Easy to get them out of sync. in theory yes. In practice, the "behavioural" rules over the "real gates" and the "entity" files do not change often. > 5) Hard to get at real transistors! yup, but in reality, if you get that low, you end up stuck with a fab house :-( F-CPU, for those who don't know (there are newbies here) is about freedom, so being restricted to only one fab is not good, and would render our work useless when the process evolves. And it's not only about geometric design rules ! 6 months ago, i would still have designed logic gates using several pass transistors... But today's rules have to deal with ultra-low voltages and pass transistors are much more restricted. > > But on the other hand this may also be an indication that a lot > > of the design already gets lost when you write it down in VHDL, > > i.e. translation from mind to VHDL to compiler to gates/cells. Fortunately, unlike C or other langages, VHDL provides a lot of levels of description. > > Sometimes it's a pity that one is forced to an implementation > > already in the early stages of a design. > I think a RTL style language is best, not vhdl or verlog. I agrgee on one side but this creates new problems when dealing with multiple targets with different architectures and granularities... imagine FPGA1 with 3-input gates and FPGA2 with 4-input gates (or anything like this difference). How do you code RTL for best efficiency for both platforms ? > Mind you the last nice RTL language I saw was for punched cards > computer and output to FORTRAN as simulation. (A yellow book if > I remember right with a title like Register transfer language > and simulation ) Damnit, i'll have to dust off my IBM 7080 :-P what was the langage's name, btw ? > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 11:30:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azV9-0006UD-00 for ; Wed, 13 Feb 2002 14:31:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:11 +0100 (CET) Received: (qmail 1225 invoked by uid 0); 13 Feb 2002 10:30:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Feb 2002 10:30:49 -0000 Received: by moria.seul.org (Postfix) id 04CED146829; Wed, 13 Feb 2002 05:30:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDDBB146827; Wed, 13 Feb 2002 05:30:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 404A7146825 for ; Wed, 13 Feb 2002 05:30:47 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 10:30:22 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] register set From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 10:30:22 GMT Message-id: <200202131030.16fe@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 12/02/02 Objet: Re: [f-cpu] register set On Tue, 12 Feb 2002, Bruno Bougard wrote: > Juergen Goeritz wrote: I would rather prefer a tool that automatically detects regular structures in a behavioural model and replaces them during compilation by vendor type things. But why force the designer to use this stuff or take care of this stuff by wrappers already in the design process??? Those tools suck! >>>> With Dc_compiler, it's called multi-bit entities for the use of an array of flipflop (during the synthesys of the multiplier bloc of 256 bits has been used ).The problem is to extract the protocole to access this memory bloc (read/write, enable...) and some tiomes there is problem with size, automatic tools will provide too big results. nicO JG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Feb 13 12:10:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azVB-0006UD-00 for ; Wed, 13 Feb 2002 14:31:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:13 +0100 (CET) Received: (qmail 20403 invoked by uid 0); 13 Feb 2002 11:05:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 13 Feb 2002 11:05:22 -0000 Received: by moria.seul.org (Postfix) id 43095146825; Wed, 13 Feb 2002 06:05:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E016146827; Wed, 13 Feb 2002 06:05:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id ED5F7146825 for ; Wed, 13 Feb 2002 06:05:19 -0500 (EST) Received: from f-cpu.org (kdl21-58.n.club-internet.fr [213.44.96.58]) by relay-3v.club-internet.fr (Postfix) with ESMTP id E7DC916AC for ; Wed, 13 Feb 2002 12:05:15 +0100 (CET) Message-ID: <3C6A498A.3E00E2F1@f-cpu.org> Date: Wed, 13 Feb 2002 12:10:02 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] register set, latches References: <200202130932.13d1@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, again, nicolas.boulay@ifrance.com wrote: > -----Message d'origine----- > De: Yann Guidon > A: f-cpu@seul.org > Date: 12/02/02 > Objet: Re: [f-cpu] register set > > hello, > <..> > By the way, if people are "eager" to have a D-ff, > i could probably reuse the dual-edge flip-flop idea > and adapt it a bit... > ---- > >>>> Dual-edge ???? No, we will use normal cell find > in every technology and not a special thing that > could only be manualy implemented. once you have designed the dual-edge cell, you can reuse it instead of the standard cell. The problem might come from static timing analysis but the effect is that it will return an operating frequency that is 2x that of the real frequeny. You seem to like power consumption reduction : dual-edga flip-flops require almost as many room as a normal one, at least with the sxlib of Alliance. However, you can drop the clock tree's frequency which is likely to reduce the power consumption by 25% (granted 50% of the power is drawn from the clock and its frequency is reduced by 50%). > Please, think only on rising edge D-flipflop (or RS). i do that all the time. But dual-edge comes as a replacement cell which does not change the timing (just halve the clock frequency). > Even using falling > edge flipflop is a very bad idea, some technology > used a not gate before the clock entrance to simulate > the right beaviour. "if the tool is broken..." > For large "storage" area like register bank, > memories,caches, TLB, ... we need to create specific > entites that could used specific macrobloc of the > technology (internal memory in Xilinx, compiled SRAM > for semi-custom chip,...) "show me the code" :-) I looked at LEON specifically for that, and it's poorly explained. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Feb 13 12:10:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azVC-0006UD-00 for ; Wed, 13 Feb 2002 14:31:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:14 +0100 (CET) Received: (qmail 7519 invoked by uid 0); 13 Feb 2002 11:05:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 13 Feb 2002 11:05:26 -0000 Received: by moria.seul.org (Postfix) id E5005146827; Wed, 13 Feb 2002 06:05:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C906F14682B; Wed, 13 Feb 2002 06:05:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 706C9146827 for ; Wed, 13 Feb 2002 06:05:22 -0500 (EST) Received: from f-cpu.org (kdl21-58.n.club-internet.fr [213.44.96.58]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 52A0616D5 for ; Wed, 13 Feb 2002 12:05:19 +0100 (CET) Message-ID: <3C6A498D.106702E2@f-cpu.org> Date: Wed, 13 Feb 2002 12:10:05 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] register set References: <200202131016.06e7@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello again, nicolas.boulay@ifrance.com wrote:> > -----Message d'origine----- > De: Juergen Goeritz > A: f-cpu@seul.org > Date: 12/02/02 > Objet: Re: [f-cpu] register set > > On Tue, 12 Feb 2002, Bruno Bougard wrote: > > Yann Guidon wrote: > > > Usually you can't read and write in the same clock. > You may be forced to use multiport SRAM. I didn't answer before to this one, sorry. No, there are ways (in the FC0 scheduler) to prevent the same register from being written at the same time from different ports. > >>> Double ported SRAM are common. (2 read ports and > 2 write ports). That's why i don't like the idea to > have a 3r2w register bank, so we must used "usual" > vhdl and it will be slow and fat on the silicium. we have one cycle to perform a read or a write. "superpipeline" is a way of going at least as fast as the slowest elementary stage. But if anyone has VHDL code that instanciates a multiport SRAM, i'll happily use it. this was the purpose of this thread, btw. > nicO > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Feb 13 12:10:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azVC-0006UD-01 for ; Wed, 13 Feb 2002 14:31:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:14 +0100 (CET) Received: (qmail 18749 invoked by uid 0); 13 Feb 2002 11:05:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 13 Feb 2002 11:05:30 -0000 Received: by moria.seul.org (Postfix) id 874A014682B; Wed, 13 Feb 2002 06:05:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 68626146831; Wed, 13 Feb 2002 06:05:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 0CF6E14682B for ; Wed, 13 Feb 2002 06:05:26 -0500 (EST) Received: from f-cpu.org (kdl21-58.n.club-internet.fr [213.44.96.58]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 70B061691 for ; Wed, 13 Feb 2002 12:05:23 +0100 (CET) Message-ID: <3C6A4991.5CCEBB0F@f-cpu.org> Date: Wed, 13 Feb 2002 12:10:09 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] No latches, please ! References: <200202130909.3083@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N after your "no outlook", the "no latches" outcry :-) nicolas.boulay@ifrance.com wrote: > I have miss that : please NO LATCH in our design !!!! hey, these are only electrons flowing in computers... no death, no harm, no anger... :-) > It's almost useless compare to classique flip-flop. as i explained in another message the size argument is not a problem because a 4-T cell is not orders of magnitude smaller than a FF. Most of the size is taken by the wires (5 in each direction, 2 for the write ports and 3 for the read ports). however the problem comes from the timing... > I have said nothing for the register set because of the speed. i don't get this. Can you explain ? > But latch are generaly a very very bad idea. really ? > It's almost impossible to test correctly and a lot of > tools have problem with them (static timing analysis, > compiler ...). "if the tools are broken, it ain't the design" ;-P btw, i care for the 100% testing, if you were still not reassured by previous messages. > -----Message d'origine----- > De: Yann Guidon > A: f-cpu@seul.org > Date: 11/02/02 > Objet: Re: [f-cpu] vhdl2c 0.1 > A good example is the multiplier : the input data > latch should memorise oooops ! now i get it : it's only an abuse of langage here. i was just speaking about timing issues... please forgive me ! clock gating or write enables will do fine here, but now that you speak about it... why use clock gating when latches are smaller and do the same ? :-P ok i stop here, it becomes difficult to differenciate between humor and trolling. However, if someone can write a portable "multiport ram block" that can be reused in F-CPU (and maybe even for other things than registers), everybody will be happy ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bruno.bougard@imec.be Wed Feb 13 12:10:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azVD-0006UD-00 for ; Wed, 13 Feb 2002 14:31:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:15 +0100 (CET) Received: (qmail 23838 invoked by uid 0); 13 Feb 2002 11:07:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 13 Feb 2002 11:07:27 -0000 Received: by moria.seul.org (Postfix) id 215D8146826; Wed, 13 Feb 2002 06:07:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A42814682D; Wed, 13 Feb 2002 06:07:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id 5C637146826 for ; Wed, 13 Feb 2002 06:07:24 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id MAA03935 for ; Wed, 13 Feb 2002 12:07:22 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 12:07:22 +0100 Message-ID: <3C6A49B8.87D695EB@imec.be> Date: Wed, 13 Feb 2002 12:10:48 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: <3C695DED.F7927780@jetnet.ab.ca> <3C6A413D.5D7E6643@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2002 11:07:22.0533 (UTC) FILETIME=[9C5D6550:01C1B47E] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Fortunately, VHDL provides a way to decouple the interface > from the implementation : the "entity" and the "architectures" > so when someone targets a specific technology, he adds a new > architecture and respects the interface that was defined > in the "entity". If his technology provides a 1-to-1 mapping > of the desired function : fine :-) otherwise, a certain amount > of code is necessary to "wrap" the physical entity. Yes, I also think it is the best. Define a good entity that could be frozen if everybody agree on it and keep a (dummy) behaviorial architecture that could be replaced be a real stuff (two port SRAM, register bank IP or synthetized FF ...) later on. About two-port and dual-port RAMs, with UMC techno for instance, you can have two-port SRAM which have separe read port (RADDR, DOUT, RCLK, REN) and write port (RADDR, DOUT, RCLK, REN). You can do 1 read and 1 write in the same cycle (eq. to register) but this is not a dual-port since read/read is not possible. I'm using those memories a lot in my current design, I have plenty of models for them (but I cannot disclose them, sorry) and I can tell you that they will beat any other solutions as well for power than for area ... For instance, a 16x64 two-port module in UMC CMOS .18u as a access time of 2.2ns, an area of 34 um^2 and consumes max 28 uW/MHz (full load in rd and wr) ... Bruno PS: and about the troll about latches, I hope that NicO have more authority than me and Kim to convice some of you ... Avoiding latches is one of the first rule you learn when you start doing design ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bruno.bougard@imec.be Wed Feb 13 12:14:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16azVD-0006UD-01 for ; Wed, 13 Feb 2002 14:31:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 14:31:15 +0100 (CET) Received: (qmail 17295 invoked by uid 0); 13 Feb 2002 11:11:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 13 Feb 2002 11:11:32 -0000 Received: by moria.seul.org (Postfix) id 339E714682A; Wed, 13 Feb 2002 06:11:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2369C146831; Wed, 13 Feb 2002 06:11:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dmz2.imec.be (ns.imec.be [146.103.254.12]) by moria.seul.org (Postfix) with ESMTP id 642F414682A for ; Wed, 13 Feb 2002 06:11:29 -0500 (EST) Received: from e2k01.imec.be (e2k01 [146.103.0.4]) by dmz2.imec.be (8.9.3/8.9.3) with ESMTP id MAA04638 for ; Wed, 13 Feb 2002 12:11:28 +0100 Received: from imec.be ([146.103.9.173]) by e2k01.imec.be with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 12:11:28 +0100 Message-ID: <3C6A4AAE.6AB7FD82@imec.be> Date: Wed, 13 Feb 2002 12:14:54 +0100 From: Bruno Bougard Organization: IMEC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] No latches, please ! References: <200202130909.3083@th00.opsion.fr> <3C6A4991.5CCEBB0F@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2002 11:11:28.0895 (UTC) FILETIME=[2F3540F0:01C1B47F] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > after your "no outlook", the "no latches" outcry :-) > > nicolas.boulay@ifrance.com wrote: > > I have miss that : please NO LATCH in our design !!!! > > hey, these are only electrons flowing in computers... > no death, no harm, no anger... :-) Except is this untestable latch is in the command chain of a nuclear unit ... ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 14:33:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b0Vr-0007GD-00 for ; Wed, 13 Feb 2002 15:35:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 15:35:59 +0100 (CET) Received: (qmail 25776 invoked by uid 0); 13 Feb 2002 13:34:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 13 Feb 2002 13:34:06 -0000 Received: by moria.seul.org (Postfix) id 2162514682D; Wed, 13 Feb 2002 08:34:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 02A42146834; Wed, 13 Feb 2002 08:34:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 290FC14682D for ; Wed, 13 Feb 2002 08:34:04 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 13:33:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] non standard cell From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 13:33:54 GMT Message-id: <200202131333.363b@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, again, nicolas.boulay@ifrance.com wrote: > -----Message d'origine----- > De: Yann Guidon=20 > A: f-cpu@seul.org > Date: 12/02/02 > Objet: Re: [f-cpu] register set >=20 > hello, > <..> > By the way, if people are "eager" to have a D-ff, > i could probably reuse the dual-edge flip-flop idea > and adapt it a bit... > ---- > >>>> Dual-edge ???? No, we will use normal cell find > in every technology and not a special thing that > could only be manualy implemented. once you have designed the dual-edge cell, you can reuse it instead of the standard cell. The problem might come from static timing analysis but the effect is that it will return an operating frequency that is 2x that of the real frequeny. You seem to like power consumption reduction : dual-edga flip-flops require almost as many room as a normal one, at least with the sxlib of Alliance. However, you can drop the clock tree's frequency which is likely to reduce the power consumption by 25% (granted 50% of the power is drawn from the clock and its frequency is reduced by 50%). >>>>> Only one compagny could create a new cells for their technology, the one who maid it. If an other compagny, want to create such new things it will pay ... a lot ! (because ST, IBM, UMC, TEMIC,... should relance a complete series of teste before you could used it !)=20 Failling edge flipflop could be usefull to send data to the outside of the chip, so with such thing it will become much complicated. Maybe if somebody create such flipflop we could use it. We will see at that time ! > Please, think only on rising edge D-flipflop (or RS). i do that all the time. But dual-edge comes as a replacement cell which does not change the timing (just halve the clock frequency). > Even using falling > edge flipflop is a very bad idea, some technology > used a not gate before the clock entrance to simulate > the right beaviour. "if the tool is broken..." > For large "storage" area like register bank, > memories,caches, TLB, ... we need to create specific > entites that could used specific macrobloc of the > technology (internal memory in Xilinx, compiled SRAM > for semi-custom chip,...) "show me the code" :-) >>>> As you try to explain there is no "generic" SRAM entites, that's why we need to create a fixed entites and then fill it with technological dependant things when we want to use it.(as does by leon for there register bank) But we need a "generic" pure VHDL synthetisable code, that work but will be slow and big! =20 I looked at LEON specifically for that, and it's poorly explained. >>>"Read the code." ;p > nicO WHYGEE >>>>nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Wed Feb 13 15:18:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b3zk-0000Fb-00 for ; Wed, 13 Feb 2002 19:19:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 19:19:04 +0100 (CET) Received: (qmail 796 invoked by uid 0); 13 Feb 2002 14:18:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 13 Feb 2002 14:18:22 -0000 Received: by moria.seul.org (Postfix) id 2125B146834; Wed, 13 Feb 2002 09:18:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1314414685E; Wed, 13 Feb 2002 09:18:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 318D9146834 for ; Wed, 13 Feb 2002 09:18:20 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id QAA28457 for ; Wed, 13 Feb 2002 16:18:19 +0200 Date: Wed, 13 Feb 2002 16:18:19 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] register set, latches In-Reply-To: <3C6A498A.3E00E2F1@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > once you have designed the dual-edge cell, you can reuse it instead > of the standard cell. The problem might come from static timing analysis > but the effect is that it will return an operating frequency that is > 2x that of the real frequeny. I'm little lost, what is going to be the design methodology with FCPU for ASIC. Is it full manual layout and GDSII signoff or standard cell based technology and possibility for netlist signoffs. There is no way you can get your own cells to vendor libraries without big amounts of money (and timeframes are long for new cells). And how about dual-edge cells in FPGAs etc. If the flow is done from the start to the end the tools are astronomically expensive, synthesizers are cheap compared to tools needed for layout (library compilers, layout tools, memory compilers etc.). Also for manual layout all PLLs etc. need to be designed and characterized for the process.Count few rounds of silicon just for cell testing to verify the own cell library, My advise is to use standard cells and nothing too fancy. Many vendors have many exotic cells available, but they are not very portable (4- and 8-port memories, special register banks, CAM, special I/O, 1T-SRAM, eDRAM etc.) --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Wed Feb 13 15:26:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b3zl-0000Fb-00 for ; Wed, 13 Feb 2002 19:19:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 19:19:05 +0100 (CET) Received: (qmail 26184 invoked by uid 0); 13 Feb 2002 14:26:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 13 Feb 2002 14:26:34 -0000 Received: by moria.seul.org (Postfix) id 9A88214685E; Wed, 13 Feb 2002 09:26:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9835D146835; Wed, 13 Feb 2002 09:26:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from studict.student.utwente.nl (studict.student.utwente.nl [130.89.220.2]) by moria.seul.org (Postfix) with ESMTP id 97368146835 for ; Wed, 13 Feb 2002 09:26:32 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id PAA23775 for ; Wed, 13 Feb 2002 15:26:30 +0100 (MET) Message-ID: <001d01c1b49a$7235db60$29e65982@student.utwente.nl> From: "Marco Al" To: References: <200202131333.363b@th00.opsion.fr> Subject: Re: [f-cpu] non standard cell Date: Wed, 13 Feb 2002 15:26:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: >>>>> Only one compagny could create a new cells for their technology, the one who maid it. If an other compagny, want to create such new things it will pay ... a lot ! (because ST, IBM, UMC, TEMIC,... should relance a complete series of teste before you could used it !) What do you call cell's? A quick google search turned up that UMC provides something they call Pcell's for instance (http://www.cadence.com/datasheets/umc_foundry_process_design_kits.html). Of course there's plenty of other tools out there which let you do custom cell design, are you saying physical simulation using transistor level process characterization has become so poor you have no hope of getting custom designs right in one go anymore? Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Feb 13 17:48:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b3zm-0000Fb-01 for ; Wed, 13 Feb 2002 19:19:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 19:19:06 +0100 (CET) Received: (qmail 31601 invoked by uid 0); 13 Feb 2002 16:49:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 13 Feb 2002 16:49:02 -0000 Received: by moria.seul.org (Postfix) id AA6D8146831; Wed, 13 Feb 2002 11:48:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 920BC14687A; Wed, 13 Feb 2002 11:48:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id B5ECD146831 for ; Wed, 13 Feb 2002 11:48:58 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Wed, 13 Feb 2002 16:48:46 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] non standard cell From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 16:48:46 GMT Message-id: <200202131648.2e9d@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: "Marco Al" A: Date: 13/02/02 Objet: Re: [f-cpu] non standard cell From: >>>>> Only one compagny could create a new cells for their technology, the one who maid it. If an other compagny, want to create such new things it will pay ... a lot ! (because ST, IBM, UMC, TEMIC,... should relance a complete series of teste before you could used it !) What do you call cell's? A quick google search turned up that UMC provides >>>> I said "cells" for what is often called gate but it's more generic(and, nand gate, muxes, complete adder, 2-bits adder, flipflop,... ). A gate level design (produice by synthetiser) is the connection between a collection of such cells. nicO something they call Pcell's for instance (http://www.cadence.com/datasheets/umc_foundry_proces s_design_kits.html). >>>>That's the tools to create new cells. Of course there's plenty of other tools out there which let you do custom cell design, are you saying physical simulation using transistor level process characterization has become so poor you have no hope of getting custom designs right in one go anymore? Marco ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Feb 13 17:55:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b3zn-0000Fb-00 for ; Wed, 13 Feb 2002 19:19:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 19:19:07 +0100 (CET) Received: (qmail 19427 invoked by uid 0); 13 Feb 2002 16:54:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 13 Feb 2002 16:54:09 -0000 Received: by moria.seul.org (Postfix) id 0DD49146808; Wed, 13 Feb 2002 11:54:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F085E14687A; Wed, 13 Feb 2002 11:54:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (unknown [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 39717146808 for ; Wed, 13 Feb 2002 11:54:06 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA24384 for ; Wed, 13 Feb 2002 09:53:44 -0700 (MST) Message-ID: <3C6A9A8F.E0A539E@jetnet.ab.ca> Date: Wed, 13 Feb 2002 09:55:43 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] No latches, please ! References: <200202130909.3083@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicolas.boulay@ifrance.com wrote: > > I have miss that : please NO LATCH in our design !!!! > > It's almost useless compare to classique flip-flop. I > have said nothing for the register set because of the > speed. But latch are generaly a very very bad idea. > It's almost impossible to test correctly and a lot of > tools have problem with them (static timing analysis, > compiler ...). > Time for better tools? Latches have their place in design, but require more care with design and clock generation. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Feb 13 18:21:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b3zn-0000Fb-01 for ; Wed, 13 Feb 2002 19:19:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 19:19:07 +0100 (CET) Received: (qmail 29516 invoked by uid 0); 13 Feb 2002 17:21:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 13 Feb 2002 17:21:06 -0000 Received: by moria.seul.org (Postfix) id D33F7146876; Wed, 13 Feb 2002 12:21:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3BE314687B; Wed, 13 Feb 2002 12:21:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 4D43C146876 for ; Wed, 13 Feb 2002 12:21:03 -0500 (EST) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id BE2B65F943 for ; Wed, 13 Feb 2002 18:21:01 +0100 (CET) Received: by imp3-1.free.fr (Postfix, from userid 33) id A996BFD9C; Wed, 13 Feb 2002 18:21:01 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl2c 0.1 Message-ID: <1013620861.3c6aa07d3294f@imp3-1.free.fr> Date: Wed, 13 Feb 2002 18:21:01 +0100 (MET) From: Cedric BAIL References: <3C685B8F.1C0B9A76@f-cpu.org> <20020212020101.23502@thrai.stud.uni-hannover.de> In-Reply-To: <20020212020101.23502@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I would like him to speak about his own ideas on the list, > > instead of me telling what he said... And in the end i remark that > > his suggestions were already though about by a lot of companies > > and the specialists (like Kim) know the results... > Why doesn't Cedric join us? If he's got something to say, I want to > hear it. Maybe he's the one who triggers my imagination and makes me > produce one of my crazy ideas. Or vice versa. Sorry, but I have currently a lot of work, and I have really not time to discuss about this idea. This idea came because of a guy that we meet last week with whygee, that want to create is own EDA tools under the GPL licence. So I am currently thinking that for him, because he start from scratch, a vhdl2c (or perhaps a vhdl2c++) will be more easy. And that will give me the possibility to run some a EDA at school. (They have more better computer than me ;-). > Apropos lonely: what's going on in France? So, I am currently discuting with my school to create an association, the goals of this association will be to help us for all the organisation part of the project. (And perhaps to work on the software part). We will define the status of this association this week-end. So, I must go A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Feb 13 18:58:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b5qT-0001d7-00 for ; Wed, 13 Feb 2002 21:17:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 21:17:37 +0100 (CET) Received: (qmail 6042 invoked by uid 0); 13 Feb 2002 17:58:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 13 Feb 2002 17:58:14 -0000 Received: by moria.seul.org (Postfix) id 101D814683F; Wed, 13 Feb 2002 12:58:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC9F914687B; Wed, 13 Feb 2002 12:58:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id 61C9E14683F for ; Wed, 13 Feb 2002 12:58:12 -0500 (EST) Received: from club-internet.fr (flashmail-3m.cs.clubint.net [172.16.4.124]) by relay-1m.club-internet.fr (Postfix) with SMTP id E8C2C16C1; Wed, 13 Feb 2002 18:58:04 +0100 (CET) Received: from [132.227.86.2] by flashmail-3m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Rep:Re: [f-cpu] register set, latches Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 18:58:04 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >> once you have designed the dual-edge cell, you can reuse it instead >> of the standard cell. The problem might come from static timing analysi= s >> but the effect is that it will return an operating frequency that is >> 2x that of the real frequeny. > >I'm little lost, what is going to be the design methodology with FCPU for >ASIC. Is it full manual layout and GDSII signoff or standard cell based >technology and possibility for netlist signoffs. There is no way you can >get your own cells to vendor libraries without big amounts of money (and >timeframes are long for new cells). And how about dual-edge cells in FPGA= s >etc. The dual-edge thing is obviously =22technology-dependent=22. It can be possible to simulate it easily in VHDL and even make a cell for it with existing cells (take 3 muxes and 2 inverters). But let me state is clearly =21 this is independent from the F-CPU or any known implementation. I even do believe that such cells exist for some =22custom=22 designs such as for the P4 and might be a problem for the patents. BUT i know that in theory it is possible. I'm such an =22itch scratcher=22... >If the flow is done from the start to the end the tools are astronomicall= y >expensive, synthesizers are cheap compared to tools needed for layout >(library compilers, layout tools, memory compilers etc.). Also for manual >layout all PLLs etc. need to be designed and characterized for the >process.Count few rounds of silicon just for cell testing to verify the >own cell library, I am aware... Even though they don't say that, in our courses in the unive= rsity ;-) >My advise is to use standard cells and nothing too fancy. Many vendors >have many exotic cells available, but they are not very portable (4- and >8-port memories, special register banks, CAM, special I/O, 1T-SRAM, eDRAM >etc.) my problem now is to have a generic interface for them. Is there a public library of portable cells ? >--Kim YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Feb 13 19:00:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b5qU-0001d7-00 for ; Wed, 13 Feb 2002 21:17:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 21:17:38 +0100 (CET) Received: (qmail 5061 invoked by uid 0); 13 Feb 2002 17:59:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 13 Feb 2002 17:59:00 -0000 Received: by moria.seul.org (Postfix) id 36E2C14687F; Wed, 13 Feb 2002 12:59:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E9C514687C; Wed, 13 Feb 2002 12:59:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 5BDC114687A for ; Wed, 13 Feb 2002 12:58:59 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA27226 for ; Wed, 13 Feb 2002 10:58:52 -0700 (MST) Message-ID: <3C6AA9D4.1CEB1CF5@jetnet.ab.ca> Date: Wed, 13 Feb 2002 11:00:52 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] register set, latches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > I'm little lost, what is going to be the design methodology with FCPU for > ASIC. Is it full manual layout and GDSII signoff or standard cell based > technology and possibility for netlist signoffs. There is no way you can > get your own cells to vendor libraries without big amounts of money (and > timeframes are long for new cells). And how about dual-edge cells in FPGAs > etc. Lets not forget here that FPGA's could be quite useful as hardware emulators of standard cell libraries. Until you start coding real programs and building hardware even if it is 100x slower than the real thing you will not be able to correct the architecture for unforeseen problems. On my own FPGA cpu design I found I made 25% more changes after I had a mostly working cpu to correct for logic bugs, architectural improvements and added features, ( like a fast interrupt for floppy disk or byte swaps ), or better ways of doing things. It is only after your major 30'th revision do you get things right.:) -- Ben Frantic - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Feb 13 19:09:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b5qU-0001d7-01 for ; Wed, 13 Feb 2002 21:17:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 21:17:38 +0100 (CET) Received: (qmail 11373 invoked by uid 0); 13 Feb 2002 18:09:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 13 Feb 2002 18:09:44 -0000 Received: by moria.seul.org (Postfix) id A794F14687A; Wed, 13 Feb 2002 13:09:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 693E514687C; Wed, 13 Feb 2002 13:09:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 6BE9D14687A for ; Wed, 13 Feb 2002 13:09:40 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16b3qS-00043h-00 for f-cpu@seul.org; Wed, 13 Feb 2002 19:09:28 +0100 Date: Wed, 13 Feb 2002 19:09:28 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] No latches, please ! In-Reply-To: <3C6A9A8F.E0A539E@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 13 Feb 2002, Ben Franchuk wrote: > nicolas.boulay@ifrance.com wrote: > > > > I have miss that : please NO LATCH in our design !!!! > > > > It's almost useless compare to classique flip-flop. I > > have said nothing for the register set because of the > > speed. But latch are generaly a very very bad idea. > > It's almost impossible to test correctly and a lot of > > tools have problem with them (static timing analysis, > > compiler ...). > > > Time for better tools? Latches have their place in design, but require > more care with design and clock generation. Usually you only use latches to synchonize input signals to keep input setup times of other circuitry. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Feb 13 19:39:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b5qV-0001d7-00 for ; Wed, 13 Feb 2002 21:17:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 21:17:39 +0100 (CET) Received: (qmail 16319 invoked by uid 0); 13 Feb 2002 18:37:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 13 Feb 2002 18:37:14 -0000 Received: by moria.seul.org (Postfix) id 5645214687B; Wed, 13 Feb 2002 13:37:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E044146883; Wed, 13 Feb 2002 13:37:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 790A114687B for ; Wed, 13 Feb 2002 13:37:11 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA29048 for ; Wed, 13 Feb 2002 11:37:07 -0700 (MST) Message-ID: <3C6AB2CB.C391B248@jetnet.ab.ca> Date: Wed, 13 Feb 2002 11:39:07 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] No latches, please ! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Usually you only use latches to synchonize input signals > to keep input setup times of other circuitry. With a single phase clock found in modern designs you don't have the non-overlaping clock needed by a latch. Older CPU's like the 6800,6502 used latches internally and needed a two phase clock. With my cpu I use a 4x clock like 6809 to give me a clean memory interface. Internally I could use latches or flip/flops for storage but use flip/flops because of a slightly cleaner design. Some FPGA configurations favor latches over flip/flops. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Feb 13 20:07:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16b5qV-0001d7-01 for ; Wed, 13 Feb 2002 21:17:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Feb 2002 21:17:39 +0100 (CET) Received: (qmail 14904 invoked by uid 0); 13 Feb 2002 19:07:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Feb 2002 19:07:52 -0000 Received: by moria.seul.org (Postfix) id 62E0814687C; Wed, 13 Feb 2002 14:07:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6095C146884; Wed, 13 Feb 2002 14:07:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id DF28A14687C for ; Wed, 13 Feb 2002 14:07:50 -0500 (EST) Received: from club-internet.fr (flashmail-3m.cs.clubint.net [172.16.4.124]) by relay-1m.club-internet.fr (Postfix) with SMTP id 884E7168C; Wed, 13 Feb 2002 20:07:46 +0100 (CET) Received: from [132.227.86.2] by flashmail-3m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] No latches, please ! Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2002 20:07:46 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The latches nightmare continues here ;-P Don't read if you're easily technically offended >On Wed, 13 Feb 2002, Ben Franchuk wrote: >> nicolas.boulay=40ifrance.com wrote: >> > = >> > I have miss that : please NO LATCH in our design =21=21=21=21 >> > = >> > It's almost useless compare to classique flip-flop. I >> > have said nothing for the register set because of the >> > speed. But latch are generaly a very very bad idea. >> > It's almost impossible to test correctly and a lot of >> > tools have problem with them (static timing analysis, >> > compiler ...). >> > = >> Time for better tools? Latches have their place in design, but require >> more care with design and clock generation. = > >Usually you only use latches to synchonize input signals >to keep input setup times of other circuitry. If we were SURE that the number of pipeline stages was EVEN, we could do something really... CRAZY =21 Remember : a FlipFlop is a pair of transparent latches that are activated with an opposite signal. Under the following conditions : - setup/hold times respected (more difficult because of the distance and phase shift/delay) - even number of stages it would be possible to use only latches in a pipeline... The above is only pure speculation. I know some people will like while others will love it. It's funny but is not part of the F-CPU pr= oject. have fun, >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Feb 13 12:21:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bBhB-0005gr-00 for ; Thu, 14 Feb 2002 03:32:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 03:32:25 +0100 (CET) Received: (qmail 10736 invoked by uid 0); 13 Feb 2002 21:29:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 13 Feb 2002 21:29:23 -0000 Received: by moria.seul.org (Postfix) id 65E98146816; Wed, 13 Feb 2002 16:29:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5DD1814688C; Wed, 13 Feb 2002 16:29:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a048.home.uni-hannover.de [130.75.232.48]) by moria.seul.org (Postfix) with ESMTP id A5012146816 for ; Wed, 13 Feb 2002 16:29:16 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00631; Wed, 13 Feb 2002 12:21:05 +0100 Message-ID: <20020213122105.11549@thrai.stud.uni-hannover.de> Date: Wed, 13 Feb 2002 12:21:05 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] register set References: <3C695DED.F7927780@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Feb 13, 2002 at 08:23:31AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Feb 13, 2002 at 08:23:31AM +0100, Juergen Goeritz wrote: [...] > I worked a lot with table driven input languages. Contrary to > VHDL you see at the first view how the signals behave. With VHDL > you first have to activate your inner interpreter to analyse the > code before you have the essence. With tables you take one look > and you have the essence. With tables the outputs are not hidden > behind a program structure. Did you ever write a transition table for a 64-bit multiplier? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Feb 14 07:37:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bLuT-0000Fz-00 for ; Thu, 14 Feb 2002 14:26:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 14:26:49 +0100 (CET) Received: (qmail 1428 invoked by uid 0); 14 Feb 2002 07:39:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 14 Feb 2002 07:39:34 -0000 Received: by moria.seul.org (Postfix) id 02B90146895; Thu, 14 Feb 2002 02:39:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EEFF8146897; Thu, 14 Feb 2002 02:39:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-217.ras.tesion.net [195.226.100.217]) by moria.seul.org (Postfix) with ESMTP id E1BF0146895 for ; Thu, 14 Feb 2002 02:39:32 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16bFW4-0004b7-00 for f-cpu@seul.org; Thu, 14 Feb 2002 07:37:12 +0100 Date: Thu, 14 Feb 2002 07:37:12 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] No latches, please ! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 13 Feb 2002 whygee@club-internet.fr wrote: > The latches nightmare continues here ;-P > Don't read if you're easily technically offended > > > >On Wed, 13 Feb 2002, Ben Franchuk wrote: > >> nicolas.boulay@ifrance.com wrote: > >> > > >> > I have miss that : please NO LATCH in our design !!!! > >> > > >> > It's almost useless compare to classique flip-flop. I > >> > have said nothing for the register set because of the > >> > speed. But latch are generaly a very very bad idea. > >> > It's almost impossible to test correctly and a lot of > >> > tools have problem with them (static timing analysis, > >> > compiler ...). > >> > > >> Time for better tools? Latches have their place in design, but require > >> more care with design and clock generation. > > > >Usually you only use latches to synchonize input signals > >to keep input setup times of other circuitry. > > > > If we were SURE that the number of pipeline stages was EVEN, > we could do something really... CRAZY ! > > Remember : a FlipFlop is a pair of transparent latches > that are activated with an opposite signal. Under the following > conditions : > - setup/hold times respected (more difficult because of the distance > and phase shift/delay) > - even number of stages > it would be possible to use only latches in a pipeline... > > > > > The above is only pure speculation. I know some people will > like while others will love it. It's funny but is not part of the F-CPU project. > It may not work because if you invert the clock inside the pipeline stages using latches the 'filling logic' must fit the delay of less than half a clock (clk/2 - prev-latch-delay - latch-setup) in all (!) stages. And you have to stop the clock to freeze the contence of the pipeline stages. But how to keep from floating in the transparent stages because of changing pipeline input signals then? The whole cores clock would have to be stopped. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Feb 14 07:23:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bLuU-0000Fz-00 for ; Thu, 14 Feb 2002 14:26:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 14:26:50 +0100 (CET) Received: (qmail 32674 invoked by uid 0); 14 Feb 2002 07:39:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 14 Feb 2002 07:39:38 -0000 Received: by moria.seul.org (Postfix) id 8008214689C; Thu, 14 Feb 2002 02:39:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76C3714689B; Thu, 14 Feb 2002 02:39:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-217.ras.tesion.net [195.226.100.217]) by moria.seul.org (Postfix) with ESMTP id AA700146897 for ; Thu, 14 Feb 2002 02:39:34 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16bFJC-0004b5-00 for f-cpu@seul.org; Thu, 14 Feb 2002 07:23:54 +0100 Date: Thu, 14 Feb 2002 07:23:54 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] register set In-Reply-To: <20020213122105.11549@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 13 Feb 2002, Michael Riepe wrote: > On Wed, Feb 13, 2002 at 08:23:31AM +0100, Juergen Goeritz wrote: > [...] > > I worked a lot with table driven input languages. Contrary to > > VHDL you see at the first view how the signals behave. With VHDL > > you first have to activate your inner interpreter to analyse the > > code before you have the essence. With tables you take one look > > and you have the essence. With tables the outputs are not hidden > > behind a program structure. > > Did you ever write a transition table for a 64-bit multiplier? No, god beware! But I worked with a tool where you could make small units and connect several with local variables. The compiler could keep or flatten these local variables in the optimization process afterwards, depending whether you wanted to have them physically available for testing or not. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Feb 14 11:11:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bLuX-0000Fz-00 for ; Thu, 14 Feb 2002 14:26:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 14:26:53 +0100 (CET) Received: (qmail 4226 invoked by uid 0); 14 Feb 2002 10:12:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 14 Feb 2002 10:12:11 -0000 Received: by moria.seul.org (Postfix) id 45EF014681E; Thu, 14 Feb 2002 05:12:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E6E2146897; Thu, 14 Feb 2002 05:12:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 7158014681E for ; Thu, 14 Feb 2002 05:12:09 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Thu, 14 Feb 2002 10:11:58 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] No latches, please ! From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Feb 2002 10:11:58 GMT Message-id: <200202141011.3a23@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N That's not crazy it's called multiphased logic. You could use 2 or 4 clock phased to synchronise things but i imagine what a nightmarre it could be to debug and to test. nicO -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 13/02/02 Objet: Re: Re: [f-cpu] No latches, please ! X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu The latches nightmare continues here ;-P Don't read if you're easily technically offended >On Wed, 13 Feb 2002, Ben Franchuk wrote: >> nicolas.boulay@ifrance.com wrote: >> >=20 >> > I have miss that : please NO LATCH in our design !!!! >> >=20 >> > It's almost useless compare to classique flip-flop. I >> > have said nothing for the register set because of the >> > speed. But latch are generaly a very very bad idea. >> > It's almost impossible to test correctly and a lot of >> > tools have problem with them (static timing analysis, >> > compiler ...). >> >=20 >> Time for better tools? Latches have their place in design, but require >> more care with design and clock generation.=20 > >Usually you only use latches to synchonize input signals >to keep input setup times of other circuitry. If we were SURE that the number of pipeline stages was EVEN, we could do something really... CRAZY ! Remember : a FlipFlop is a pair of transparent latches that are activated with an opposite signal. Under the following conditions : - setup/hold times respected (more difficult because of the distance and phase shift/delay) - even number of stages it would be possible to use only latches in a pipeline... The above is only pure speculation. I know some people will like while others will love it. It's funny but is not part of the F-CPU project. have fun, >JG YG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Feb 14 12:26:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bLuf-0000Fz-00 for ; Thu, 14 Feb 2002 14:27:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 14:27:01 +0100 (CET) Received: (qmail 29149 invoked by uid 0); 14 Feb 2002 11:26:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 14 Feb 2002 11:26:56 -0000 Received: by moria.seul.org (Postfix) id 7A56D1467F2; Thu, 14 Feb 2002 06:26:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59F4F146897; Thu, 14 Feb 2002 06:26:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CBD891467F2 for ; Thu, 14 Feb 2002 06:26:53 -0500 (EST) Received: from club-internet.fr (flashmail-3v.cs.clubint.net [172.16.0.153]) by relay-3v.club-internet.fr (Postfix) with SMTP id 5625916F2; Thu, 14 Feb 2002 12:26:52 +0100 (CET) Received: from [132.227.86.2] by flashmail-3v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: test (was: Re: Rep:Re: Re: [f-cpu] No latches, please !) Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Feb 2002 12:26:52 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi nicO =21 >That's not crazy it's called multiphased logic. my second name is =22reinvent the wheel=22 ;-) > You could use 2 or 4 clock phased to synchronise things >but i imagine what a nightmarre it could be to debug >and to test. Concerning the test, remember that there is a BIST unit that takes control of the whole datapath and takes care to test all the execution units and the memory arrays. If the =22latch=22 (those you like and/or those you don't) is in the datapath, it -will- be tested. Those that can't be tested without complex stuff will use a classical scanpath but the scan chain will be kept as short as possible. By the way, one of the optional units (popcount) will certainly be used for signature compaction. How much do i have to emphasize on this ? Yes, this will be custom-designed test but - we don't need ATPG - we couldn't afford it anyway - always trust your nose and make meaningful measurements. >nicO YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Feb 14 13:14:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bLuk-0000Fz-00 for ; Thu, 14 Feb 2002 14:27:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Feb 2002 14:27:06 +0100 (CET) Received: (qmail 15422 invoked by uid 0); 14 Feb 2002 12:14:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 14 Feb 2002 12:14:14 -0000 Received: by moria.seul.org (Postfix) id 90A6A14682E; Thu, 14 Feb 2002 07:14:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 87EE414689A; Thu, 14 Feb 2002 07:14:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id CC5B614682E for ; Thu, 14 Feb 2002 07:14:11 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Thu, 14 Feb 2002 12:14:01 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Teste From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Feb 2002 12:14:01 GMT Message-id: <200202141214.0136@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Bist will never be enought. scan path is used to propagated teste (to find stuck-at-one and stuck-at-zero fault) in every corner of the chip. It's almost impossible to cover all case from the outside, to have a cover of 95 % you will need 10^9 pattern or even more, it will take days to teste a cpu and the BIST will be bigger than the core ! -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 14/02/02 Objet: test (was: Re: Rep:Re: Re: [f-cpu] No latches, please !) hi nicO ! >That's not crazy it's called multiphased logic. my second name is "reinvent the wheel" ;-) > You could use 2 or 4 clock phased to synchronise things >but i imagine what a nightmarre it could be to debug >and to test. Concerning the test, remember that there is a BIST unit that takes control of the whole datapath and takes care to test all the execution units and the memory arrays. If the "latch" (those you like and/or those you don't) is in the datapath, it -will- be tested. Those that can't be tested without complex stuff will use a classical scanpath but the scan chain will be kept as short as possible. By the way, one of the optional units (popcount) will certainly be used for signature compaction. How much do i have to emphasize on this ? Yes, this will be custom-designed test but - we don't need ATPG - we couldn't afford it anyway - always trust your nose and make meaningful measurements. >nicO YG ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Feb 14 18:20:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bydg-0000Gc-01 for ; Sat, 16 Feb 2002 07:48:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:04 +0100 (CET) Received: (qmail 25609 invoked by uid 0); 14 Feb 2002 17:18:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 14 Feb 2002 17:18:36 -0000 Received: by moria.seul.org (Postfix) id 434CF146818; Thu, 14 Feb 2002 12:18:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38E0E1468A2; Thu, 14 Feb 2002 12:18:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 53579146818 for ; Thu, 14 Feb 2002 12:18:31 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-196.jetnet.ab.ca [207.34.60.196]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA11056 for ; Thu, 14 Feb 2002 10:18:29 -0700 (MST) Message-ID: <3C6BF1D0.9EF8DC74@jetnet.ab.ca> Date: Thu, 14 Feb 2002 10:20:16 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicolas.boulay@ifrance.com wrote: > > That's not crazy it's called multiphased logic. You > could use 2 or 4 clock phased to synchronise things > but i imagine what a nightmarre it could be to debug > and to test. > But it has two advantages ... 1) A latch is quicker than a flip/flop. 2) You need less clock buffering. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Feb 15 01:39:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bydj-0000Gc-01 for ; Sat, 16 Feb 2002 07:48:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:07 +0100 (CET) Received: (qmail 8893 invoked by uid 0); 14 Feb 2002 18:34:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 14 Feb 2002 18:34:02 -0000 Received: by moria.seul.org (Postfix) id DC8B014681B; Thu, 14 Feb 2002 13:33:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD3561468A2; Thu, 14 Feb 2002 13:33:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 969E614681B for ; Thu, 14 Feb 2002 13:33:59 -0500 (EST) Received: from ifrance.com (vlt10-15.n.club-internet.fr [195.36.223.15]) by relay-2v.club-internet.fr (Postfix) with ESMTP id C52611709 for ; Thu, 14 Feb 2002 19:33:55 +0100 (CET) Message-ID: <3C6C58C9.CAF60299@ifrance.com> Date: Thu, 14 Feb 2002 19:39:37 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > nicolas.boulay@ifrance.com wrote: > > > > That's not crazy it's called multiphased logic. You > > could use 2 or 4 clock phased to synchronise things > > but i imagine what a nightmarre it could be to debug > > and to test. > > > But it has two advantages ... 1) A latch is quicker than > a flip/flop. 2) You need less clock buffering. > 1) it's the only advantage over all the disadvantage. 2) depend completly of the design of the latch !! And in the common case, false ! You could find flip-flop with the clock connected to 1 to many transistor gate ! nicO > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Feb 15 03:49:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bydo-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:12 +0100 (CET) Received: (qmail 31150 invoked by uid 0); 14 Feb 2002 20:44:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 14 Feb 2002 20:44:07 -0000 Received: by moria.seul.org (Postfix) id 545B51468A8; Thu, 14 Feb 2002 15:44:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C73C1468AA; Thu, 14 Feb 2002 15:44:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 0264E1468A8 for ; Thu, 14 Feb 2002 15:44:06 -0500 (EST) Received: from ifrance.com (vlt10-230.n.club-internet.fr [195.36.223.230]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 9802D1703 for ; Thu, 14 Feb 2002 21:44:01 +0100 (CET) Message-ID: <3C6C7747.7E486379@ifrance.com> Date: Thu, 14 Feb 2002 21:49:43 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <3C6C58C9.CAF60299@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Some example : http://www.cse.psu.edu/~cg577/hw1s98.html nicO a écrit : > > Ben Franchuk a écrit : > > > > nicolas.boulay@ifrance.com wrote: > > > > > > That's not crazy it's called multiphased logic. You > > > could use 2 or 4 clock phased to synchronise things > > > but i imagine what a nightmarre it could be to debug > > > and to test. > > > > > But it has two advantages ... 1) A latch is quicker than > > a flip/flop. 2) You need less clock buffering. > > > > 1) it's the only advantage over all the disadvantage. > > 2) depend completly of the design of the latch !! And in the common > case, false ! > > You could find flip-flop with the clock connected to 1 to many > transistor gate ! > > nicO > > > -- > > Ben Franchuk - Dawn * 12/24 bit cpu * > > www.jetnet.ab.ca/users/bfranchuk/index.html > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Feb 14 23:32:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byds-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:16 +0100 (CET) Received: (qmail 3572 invoked by uid 0); 14 Feb 2002 22:31:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 14 Feb 2002 22:31:16 -0000 Received: by moria.seul.org (Postfix) id 544911468A2; Thu, 14 Feb 2002 17:31:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A8541468A9; Thu, 14 Feb 2002 17:31:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 7777C1468A2 for ; Thu, 14 Feb 2002 17:31:14 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id PAA25922 for ; Thu, 14 Feb 2002 15:31:11 -0700 (MST) Message-ID: <3C6C3B17.C2C91B31@jetnet.ab.ca> Date: Thu, 14 Feb 2002 15:32:55 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <3C6C58C9.CAF60299@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO wrote: > 1) it's the only advantage over all the disadvantage. > > 2) depend completly of the design of the latch !! And in the common > case, false ! > > You could find flip-flop with the clock connected to 1 to many > transistor gate ! I meant that a master clock would drive 1/n of the latches compared to 1 clock driving them all. Mind you I don't believe in massive pipe lining, RISC or other modern designs and High level languages and hardware compilers. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Feb 14 20:06:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16bydt-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:17 +0100 (CET) Received: (qmail 20328 invoked by uid 0); 14 Feb 2002 23:11:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Feb 2002 23:11:02 -0000 Received: by moria.seul.org (Postfix) id 508BB1468A7; Thu, 14 Feb 2002 18:11:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 481CD1468AA; Thu, 14 Feb 2002 18:11:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a113.home.uni-hannover.de [130.75.232.113]) by moria.seul.org (Postfix) with ESMTP id 97ED01468A7 for ; Thu, 14 Feb 2002 18:10:58 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00611; Thu, 14 Feb 2002 20:06:12 +0100 Message-ID: <20020214200612.44670@thrai.stud.uni-hannover.de> Date: Thu, 14 Feb 2002 20:06:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C6BF1D0.9EF8DC74@jetnet.ab.ca>; from Ben Franchuk on Thu, Feb 14, 2002 at 10:20:16AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Feb 14, 2002 at 10:20:16AM -0700, Ben Franchuk wrote: > nicolas.boulay@ifrance.com wrote: > > > > That's not crazy it's called multiphased logic. You > > could use 2 or 4 clock phased to synchronise things > > but i imagine what a nightmarre it could be to debug > > and to test. > > > But it has two advantages ... 1) A latch is quicker than > a flip/flop. 2) You need less clock buffering. A latch is quicker in terms of what? Delay time? Setup time? Clock frequency? Latches have one big disadvantage: they can become transparent. In a pipeline, you don't want that (unless you're willing to work with two or more different clocks). But they are useful for large memories (e.g. the caches) where FFs would be too large. The register set may be either one; personally, I vote for FFs. IMHO there should be no latches at all in the core (caches excluded) -- otherwise, it would be a complete mess. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Feb 15 02:48:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeD-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:37 +0100 (CET) Received: (qmail 22590 invoked by uid 0); 15 Feb 2002 01:44:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 15 Feb 2002 01:44:09 -0000 Received: by moria.seul.org (Postfix) id D600C14680E; Thu, 14 Feb 2002 20:44:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBF241468AD; Thu, 14 Feb 2002 20:44:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 60A7614680E for ; Thu, 14 Feb 2002 20:44:08 -0500 (EST) Received: from f-cpu.org (kdl11-36.n.club-internet.fr [213.44.9.36]) by relay-2v.club-internet.fr (Postfix) with ESMTP id EA29816A4 for ; Fri, 15 Feb 2002 02:44:04 +0100 (CET) Message-ID: <3C6C6906.925E389F@f-cpu.org> Date: Fri, 15 Feb 2002 02:48:54 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Thu, Feb 14, 2002 at 10:20:16AM -0700, Ben Franchuk wrote: > > nicolas.boulay@ifrance.com wrote: > > > > > > That's not crazy it's called multiphased logic. You > > > could use 2 or 4 clock phased to synchronise things > > > but i imagine what a nightmarre it could be to debug > > > and to test. > > > > > But it has two advantages ... 1) A latch is quicker than > > a flip/flop. 2) You need less clock buffering. > > A latch is quicker in terms of what? Delay time? Setup time? Clock > frequency? first, it's a bit smaller. Depending on the amount of control logic, the gain varies. The memory cell (4 transistors) requires decoding and clock buffering, IIRC the sxlib FF uses around 20 transistors. Setup time + hold are the same or not, depending on the kind of gates you use. For example, in sxlib, they use a couple of 4T cells which are overwritten by using a buffer with high driving capability. On of the inverters of the 4T cell has a low drive and the buffer can overwrite the previous value. I guess that because there is no problem of clock and transmitting the data from one latch to another, the setup+hold requirements disappear (but certainly arise in another form). Setup+hold depend on the cell's ability to treat the clock signal (input buffer, composed of two inverters and wire delays for transmitting the clock through the whole cell (often not using metal...)). I am pretty sure better cells exist in industrial libraries, so i wouldn't bet on perfectness. correct me if i'm wrong or if what they told me in the university is crap (both options have equal probabilities). > Latches have one big disadvantage: they can become transparent. and sometimes, they do it :-) This is both an advantage and a drawback so you have to choose where to use them. For example, the register set uses latches, both for the registers and their "showdow flags" because we want to know the flag's value, EVEN during a cycle when it is being written to... > In a > pipeline, you don't want that (unless you're willing to work with two > or more different clocks). But they are useful for large memories (e.g. > the caches) where FFs would be too large. The register set may be either > one; personally, I vote for FFs. IMHO there should be no latches at all > in the core (caches excluded) -- otherwise, it would be a complete mess. the mess comes in when we want to make a portable design (VHDL accept almost anything). I still have no answer to my problem, btw. in another mail Bruno spoke about a 16*64 cell that can work at 2.2ns, this puts the maximum operating frequency (.18u) at around 300 or 400MHz. read you soon and meet nicO at FOSDEM, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Feb 15 08:16:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeN-0000Gc-01 for ; Sat, 16 Feb 2002 07:48:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:47 +0100 (CET) Received: (qmail 18109 invoked by uid 0); 15 Feb 2002 07:16:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 15 Feb 2002 07:16:11 -0000 Received: by moria.seul.org (Postfix) id B3F9A1468B0; Fri, 15 Feb 2002 02:16:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A327F1468B3; Fri, 15 Feb 2002 02:16:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id C09641468B0 for ; Fri, 15 Feb 2002 02:16:09 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id JAA01941 for ; Fri, 15 Feb 2002 09:16:08 +0200 Date: Fri, 15 Feb 2002 09:16:08 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: test (was: Re: Rep:Re: Re: [f-cpu] No latches, please !) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Concerning the test, remember that there is a BIST unit that > takes control of the whole datapath and takes care to test > all the execution units and the memory arrays. If the "latch" > (those you like and/or those you don't) is in the datapath, > it -will- be tested. Those that can't be tested without complex > stuff will use a classical scanpath but the scan chain will be > kept as short as possible. > By the way, one of the optional units (popcount) will certainly > be used for signature compaction. How many patterns have you tought to use. Datapath style BIST takes very long times, probably many days. Each second in ASIC tester costs real money. You need very quick results in ASIC tster to notify if the chip is OK (IDDQ tests, ATPG patterns, quick RAM bists etc.) > How much do i have to emphasize on this ? > Yes, this will be custom-designed test but > - we don't need ATPG > - we couldn't afford it anyway > - always trust your nose and make meaningful measurements. I doubt that you can make the BIST to cover the whole chip without sacrificin performance and the test times will be huge. Also "all" the commercial Logic BIST testers work by hooking into the scan chains and they generate patterns to those chains. Also to minimise the test time Logic BIST needs quite complex things (reseedable pattern generators, randomness distribution changes based on feedback, random generator optimization based on scanpath and design etc.) BIST is only a small part of testing. It is good for memories and fullspeed logic testing but to get >95% coverage for logic with BIST is very challenging. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Feb 15 08:32:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeP-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:49 +0100 (CET) Received: (qmail 20150 invoked by uid 0); 15 Feb 2002 07:32:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 15 Feb 2002 07:32:08 -0000 Received: by moria.seul.org (Postfix) id 118661468B1; Fri, 15 Feb 2002 02:32:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CBE61468B4; Fri, 15 Feb 2002 02:32:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 3C5AB1468B1 for ; Fri, 15 Feb 2002 02:32:06 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id JAA02550 for ; Fri, 15 Feb 2002 09:32:05 +0200 Date: Fri, 15 Feb 2002 09:32:05 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! In-Reply-To: <3C6C6906.925E389F@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > first, it's a bit smaller. Depending on the amount of control logic, > the gain varies. The memory cell (4 transistors) requires decoding > and clock buffering, IIRC the sxlib FF uses around 20 transistors. Is the logic size anymore a problem? At 0.13u you can get about 200kgates/mm^2, and minimum size silicon for reasonable packages is around 100mm^2. Usually the logic in current generation chips is small grain in some corner of the chip and rest is memory. And memory is done quite differently layoutwise depeding on memory technology and speed (about 300-1600kbit/mm^2). Optimizing few transistors/gates is not worth the job anymore. The problem is becoming power usage, yield, design sizes etc. And to attack power use usually gate counts rise quite dramatically (sounds odd but this is the truth). For example some power saving cells have twice the amount of transistors to fight with power leakage in the cell. Efficient signaling between blocks also adds more logic, block level clock management also is quite complex thing. > in another mail Bruno spoke about a 16*64 cell that can work at 2.2ns, > this puts the maximum operating frequency (.18u) at around 300 or 400MHz. You have to remember that there are also different cell libraries for commercial processes. Some libraries are geared for maximum performance and consume more power and the yield might be lower. Then there are lopower cells that are slower. These things are very difficult to predict without real data and libraries. And those who have access to the data have NDAs so we have to be very careful what we speak (no excact numbers only ballpark figures, no manufacturer names etc.). --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Feb 15 08:46:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeQ-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:50 +0100 (CET) Received: (qmail 26068 invoked by uid 0); 15 Feb 2002 07:44:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 15 Feb 2002 07:44:53 -0000 Received: by moria.seul.org (Postfix) id C820C1468B3; Fri, 15 Feb 2002 02:44:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE3601468B5; Fri, 15 Feb 2002 02:44:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 229211468B3 for ; Fri, 15 Feb 2002 02:44:52 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id AAA20284 for ; Fri, 15 Feb 2002 00:44:50 -0700 (MST) Message-ID: <3C6CBCDC.A57D017D@jetnet.ab.ca> Date: Fri, 15 Feb 2002 00:46:36 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] testing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N With all this talk of testing -- why not a have nice 12 bit micro - micro computer add,nor,store,jc - instructions and have it test out the main F-cpu. If you really want to be sneaky have a core logic block tested by normal means of a minimal F-cpu that then tests out the rest of system. All that cache and main register file is a good bit of program space. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Feb 15 10:18:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeS-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:52 +0100 (CET) Received: (qmail 23393 invoked by uid 0); 15 Feb 2002 09:17:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 15 Feb 2002 09:17:28 -0000 Received: by moria.seul.org (Postfix) id B60691468B9; Fri, 15 Feb 2002 04:17:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B368B1468B8; Fri, 15 Feb 2002 04:17:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-101-47.ras.tesion.net [195.226.101.47]) by moria.seul.org (Postfix) with ESMTP id 9D06B1468B6 for ; Fri, 15 Feb 2002 04:17:26 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16beVk-00062q-00 for f-cpu@seul.org; Fri, 15 Feb 2002 10:18:32 +0100 Date: Fri, 15 Feb 2002 10:18:32 +0100 (MET) From: Juergen Goeritz To: "f-cpu@seul.org" Subject: Re: [f-cpu] testing In-Reply-To: <3C6CBCDC.A57D017D@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 15 Feb 2002, Ben Franchuk wrote: > With all this talk of testing -- why not a have nice 12 bit micro - > micro computer add,nor,store,jc - instructions and have it test out the > main F-cpu. If you really want to be sneaky have a core logic block > tested by normal means of a minimal F-cpu that then tests out the rest > of system. All that cache and main register file is a good bit of > program space. Hi Ben, do really want to create a recursive problem? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Feb 15 12:45:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeW-0000Gc-00 for ; Sat, 16 Feb 2002 07:48:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:48:56 +0100 (CET) Received: (qmail 21389 invoked by uid 0); 15 Feb 2002 11:45:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 15 Feb 2002 11:45:14 -0000 Received: by moria.seul.org (Postfix) id 5FC511468B7; Fri, 15 Feb 2002 06:45:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BE071468BA; Fri, 15 Feb 2002 06:45:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 322801468B7 for ; Fri, 15 Feb 2002 06:45:12 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id NAA16511 for ; Fri, 15 Feb 2002 13:45:11 +0200 Date: Fri, 15 Feb 2002 13:45:11 +0200 (EET) From: Kim Enkovaara To: "f-cpu@seul.org" Subject: Re: [f-cpu] testing In-Reply-To: <3C6CBCDC.A57D017D@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > With all this talk of testing -- why not a have nice 12 bit micro - > micro computer add,nor,store,jc - instructions and have it test out the > main F-cpu. If you really want to be sneaky have a core logic block > tested by normal means of a minimal F-cpu that then tests out the rest > of system. All that cache and main register file is a good bit of > program space. The problem is still the speed of testing. To get good coverage from the edges of the chip huge amount of vectors is needed. This is same problem that is visible between block and toplevel verification of chips. If blocks are not well verified on their own it is almost impossible to verify them from the toplevel. Also normal tool flows do not fit into this kind of design. How do you for example optimize the vectors this small CPU feeds into the design. There are some formal tools (model checkers etc.) that can be used to deduct the needed steps on chip edge to get it into certain state, but those tools are slow and they can't optimize the vectors. If you create one vector for each node first and then optimize them it would take years of CPU time to first create the vectors :) Some scripting and Solidify could do the vectors, but it can take minutes for each node and if we have about 500kgates that means little over and year of calculation. And then the duplicated patterns need to be found etc. What if we just use the existing ATPG methodology with scan chains. That is known technology and well tested. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Feb 15 16:58:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byef-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:05 +0100 (CET) Received: (qmail 32321 invoked by uid 0); 15 Feb 2002 15:58:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 15 Feb 2002 15:58:24 -0000 Received: by moria.seul.org (Postfix) id 0326C1468BD; Fri, 15 Feb 2002 10:58:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F295D1468C0; Fri, 15 Feb 2002 10:58:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 6AC551468BD for ; Fri, 15 Feb 2002 10:58:22 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Fri, 15 Feb 2002 15:58:11 GMT Send-By: 140.94.197.181 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Feb 2002 15:58:11 GMT Message-id: <200202151558.0b12@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 15/02/02 Objet: Re: Rep:Re: Re: [f-cpu] No latches, please ! On Thu, Feb 14, 2002 at 10:20:16AM -0700, Ben Franchuk wrote: > nicolas.boulay@ifrance.com wrote: > >=20 > > That's not crazy it's called multiphased logic. You > > could use 2 or 4 clock phased to synchronise things > > but i imagine what a nightmarre it could be to debug > > and to test. > >=20 > But it has two advantages ... 1) A latch is quicker than > a flip/flop. 2) You need less clock buffering. A latch is quicker in terms of what? Delay time? Setup time? Clock frequency? >>> yep delay time to cross them. Latches have one big disadvantage: they can become transparent. In a pipeline, you don't want that (unless you're willing to work with two or more different clocks). But they are useful for large memories (e.g. the caches) where FFs would be too large. The register set=20 >>>For large memory SRAM are much better !! may be either one; personally, I vote for FFs. IMHO there should be no latches at all in the core (caches excluded) -- otherwise, it would be a complete mess. >>>I completly agree ! nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Feb 15 20:20:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeh-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:07 +0100 (CET) Received: (qmail 22455 invoked by uid 0); 15 Feb 2002 19:18:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 15 Feb 2002 19:18:34 -0000 Received: by moria.seul.org (Postfix) id 0B1881467F3; Fri, 15 Feb 2002 14:18:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01EFA1467FE; Fri, 15 Feb 2002 14:18:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 56BAC1467F3 for ; Fri, 15 Feb 2002 14:18:32 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA02372 for ; Fri, 15 Feb 2002 12:18:30 -0700 (MST) Message-ID: <3C6D5F78.28EDFFD@jetnet.ab.ca> Date: Fri, 15 Feb 2002 12:20:24 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] testing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > > > With all this talk of testing -- why not a have nice 12 bit micro - > > micro computer add,nor,store,jc - instructions and have it test out the > > main F-cpu. If you really want to be sneaky have a core logic block > > tested by normal means of a minimal F-cpu that then tests out the rest > > of system. All that cache and main register file is a good bit of > > program space. > > The problem is still the speed of testing. To get good coverage from the > edges of the chip huge amount of vectors is needed. This is same problem > that is visible between block and toplevel verification of chips. If > blocks are not well verified on their own it is almost impossible to > verify them from the toplevel. Very true and more so since the F-CPU is vector style computer. Now if you had a front panel with lights and switches like a real machine you could do real testing.:) > Also normal tool flows do not fit into this kind of design. How do you > for example optimize the vectors this small CPU feeds into the design. > There are some formal tools (model checkers etc.) that can be used to > deduct the needed steps on chip edge to get it into certain state, but > those tools are slow and they can't optimize the vectors. If you create > one vector for each node first and then optimize them it would take years > of CPU time to first create the vectors :) All my testing of computers has been done with a logic probe and a brain! I still feel if you can't design by hand the system may be too complex to work properly. If you have system of X alu's and Y thing-a-bobs and Z do-dads expect longer testing if you can't test in parallel. From what little I read vector testing is that it is a go-no-go style check good for testing a chip before packaging. Yet even then you your modules with proper testing signals as to make gates more visible and break feed back loops or long logic paths like carry signals. With FPGA's you don't have the gate level testing so for the first round design the sub-modules don't need a low level test mode like real silicon would. > Some scripting and Solidify could do the vectors, but it can take minutes > for each node and if we have about 500kgates that means little over and > year of calculation. And then the duplicated patterns need to be found > etc. I have never used it, can't afford it. You may have 500k gates but a module may have 5k. Divide and conquer, start small and work out. The problem is you have serial testing of each node,you need to parallel the testing as you well know. > What if we just use the existing ATPG methodology with scan chains. That > is known technology and well tested. Never heard of it so I can't comment on it. I can understand scan chains as serial access of internal sub systems but I think direct tri-stating of control and module outputs from a test module or internal test pads would make more sense. How did the big machines like CRAY's test their subsystems and modules. > --Kim Don't get discouraged testing people, here is a nice quote I read on the net "The difficult we do immediately, the impossible takes a bit longer" Philo T. Farnsworth Inventor of television. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Feb 15 20:34:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byei-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:08 +0100 (CET) Received: (qmail 30432 invoked by uid 0); 15 Feb 2002 19:30:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 15 Feb 2002 19:30:06 -0000 Received: by moria.seul.org (Postfix) id 9D57E1467F9; Fri, 15 Feb 2002 14:30:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98194146802; Fri, 15 Feb 2002 14:30:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3A4451467F9 for ; Fri, 15 Feb 2002 14:30:05 -0500 (EST) Received: from f-cpu.org (kdl21-174.n.club-internet.fr [213.44.96.174]) by relay-1v.club-internet.fr (Postfix) with ESMTP id DBD2C16C9 for ; Fri, 15 Feb 2002 20:30:01 +0100 (CET) Message-ID: <3C6D62DC.5252F497@f-cpu.org> Date: Fri, 15 Feb 2002 20:34:52 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] testing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > On Fri, 15 Feb 2002, Ben Franchuk wrote: > > > With all this talk of testing -- why not a have nice 12 bit micro - > > micro computer add,nor,store,jc - instructions and have it test out the > > main F-cpu. If you really want to be sneaky have a core logic block > > tested by normal means of a minimal F-cpu that then tests out the rest > > of system. All that cache and main register file is a good bit of > > program space. > > Hi Ben, > > do [you] really want to create a recursive problem? ROTFLMAO ... > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: to answer Kim, there must be a dedicated "BIST" unit in the pipeline, which overrides the scheduler and performs the integrity check of most of the ressources (let's say : 80%). The rest is done with a scan chain for the ressources which are not directly addressable by the execution pipeline. BIST could be extended later to include a L2 and SDRAM check routine (it's not difficult). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Feb 15 21:04:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byei-0000Gc-01 for ; Sat, 16 Feb 2002 07:49:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:08 +0100 (CET) Received: (qmail 9592 invoked by uid 0); 15 Feb 2002 20:04:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 15 Feb 2002 20:04:52 -0000 Received: by moria.seul.org (Postfix) id AB0F5146801; Fri, 15 Feb 2002 15:04:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6FD8146803; Fri, 15 Feb 2002 15:04:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 9535A146801 for ; Fri, 15 Feb 2002 15:04:49 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id WAA02917 for ; Fri, 15 Feb 2002 22:04:48 +0200 Date: Fri, 15 Feb 2002 22:04:48 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] testing In-Reply-To: <3C6D5F78.28EDFFD@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I still feel if you can't design by hand the system may be too complex > to work properly. If you have system of X alu's and Y thing-a-bobs and Z I hope I could say so. I have to live with >50M transistor designs :) > for testing a chip before packaging. Yet even then you your modules with > proper testing signals as to make gates more visible and break feed back > loops or long logic paths like carry signals. With FPGA's you don't have > the gate level testing so for the first round design the sub-modules > don't need a low level test mode like real silicon would. The problem is that you have to think about testability during design. At least the normal rules should be followed: try to minimise clock domains, clock gating creates problems, don't create reset from internal logic, do all clock generation at toplevel, avoid latches etc. > > What if we just use the existing ATPG methodology with scan chains. That > > is known technology and well tested. > > Never heard of it so I can't comment on it. I can understand scan chains > as serial access of internal sub systems but I think direct tri-stating ATPG (Automatic Test Pattern Generation) is the way all ASICs currently are tested. The tools for this are for example Mentor FastScan, Synopsys TetraMax, Synopsys TestCompiler etc. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Feb 15 21:09:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byei-0000Gc-02 for ; Sat, 16 Feb 2002 07:49:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:08 +0100 (CET) Received: (qmail 29195 invoked by uid 0); 15 Feb 2002 20:09:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 15 Feb 2002 20:09:58 -0000 Received: by moria.seul.org (Postfix) id 36B38146802; Fri, 15 Feb 2002 15:09:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2FE3F146848; Fri, 15 Feb 2002 15:09:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 20ED4146802 for ; Fri, 15 Feb 2002 15:09:56 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id WAA02995 for ; Fri, 15 Feb 2002 22:09:55 +0200 Date: Fri, 15 Feb 2002 22:09:55 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] testing In-Reply-To: <3C6D62DC.5252F497@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > PS: to answer Kim, there must be a dedicated "BIST" unit in the pipeline, > which overrides the scheduler and performs the integrity check of most > of the ressources (let's say : 80%). The rest is done with a scan chain > for the ressources which are not directly addressable by the execution > pipeline. BIST could be extended later to include a L2 and SDRAM check > routine (it's not difficult). Why is is a must to have BIST in the pipeline? It would be much easier to test it with normal scanchains. For memories MemoryBIST is needed, but that is quite different story. Also dividing the work between atpg and bist is quite difficult, how do you calculate real fault coverage? If the test coverage is not in the ballpark of 95% the chip is not usable for mass production, you just get too much broken chips to end products. Also remeber that in ASIC tester you have about 5-10s of time for the testing. Each second costs real money in the tester, there is no time to run minutes of tests. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Feb 15 12:15:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byek-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:10 +0100 (CET) Received: (qmail 20743 invoked by uid 0); 15 Feb 2002 20:41:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 15 Feb 2002 20:41:29 -0000 Received: by moria.seul.org (Postfix) id 26D3A14688E; Fri, 15 Feb 2002 15:41:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 22F5E14687E; Fri, 15 Feb 2002 15:41:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a152.home.uni-hannover.de [130.75.232.152]) by moria.seul.org (Postfix) with ESMTP id 68D02146848 for ; Fri, 15 Feb 2002 15:41:25 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00561; Fri, 15 Feb 2002 12:15:05 +0100 Message-ID: <20020215121505.37724@thrai.stud.uni-hannover.de> Date: Fri, 15 Feb 2002 12:15:05 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C6C6906.925E389F@f-cpu.org>; from Yann Guidon on Fri, Feb 15, 2002 at 02:48:54AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Feb 15, 2002 at 02:48:54AM +0100, Yann Guidon wrote: [...] > > A latch is quicker in terms of what? Delay time? Setup time? Clock > > frequency? > > first, it's a bit smaller. Depending on the amount of control logic, > the gain varies. The memory cell (4 transistors) requires decoding > and clock buffering, IIRC the sxlib FF uses around 20 transistors. > > Setup time + hold are the same or not, depending on the kind > of gates you use. For example, in sxlib, they use a couple of 4T cells > which are overwritten by using a buffer with high driving capability. > On of the inverters of the 4T cell has a low drive and the buffer can > overwrite the previous value. Master-slave-FF with the cheapest latches available? [...] > > Latches have one big disadvantage: they can become transparent. > and sometimes, they do it :-) That's the problem ;) > This is both an advantage and a drawback so you have to choose > where to use them. For example, the register set uses latches, > both for the registers and their "showdow flags" because we want > to know the flag's value, EVEN during a cycle when it is being > written to... Horror! As long as the latch is transparent, you can't be sure that its outputs are correct (and stable), so using them is absolutely pointless. If you need the value of the flag before the register is written, grab it at the input. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Feb 15 21:52:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byek-0000Gc-01 for ; Sat, 16 Feb 2002 07:49:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:10 +0100 (CET) Received: (qmail 25091 invoked by uid 0); 15 Feb 2002 20:50:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 15 Feb 2002 20:50:26 -0000 Received: by moria.seul.org (Postfix) id 3A587146848; Fri, 15 Feb 2002 15:50:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 34A8714687D; Fri, 15 Feb 2002 15:50:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 69ED4146848 for ; Fri, 15 Feb 2002 15:50:24 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA06708 for ; Fri, 15 Feb 2002 13:50:22 -0700 (MST) Message-ID: <3C6D7502.D2AD2547@jetnet.ab.ca> Date: Fri, 15 Feb 2002 13:52:18 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] testing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > I hope I could say so. I have to live with >50M transistor designs :) But since what cpu design I do is a hobby I have 0M transistor designs. None the less what I have seen of modern cpu designs it still it is hard work to design something with out all the other factors that come into play like deadlines and people in suits and it just don't fit in silicon. > The problem is that you have to think about testability during design. At > least the normal rules should be followed: try to minimise clock domains, > clock gating creates problems, don't create reset from internal logic, > do all clock generation at toplevel, avoid latches etc. What is with this fear of latches that everybody has? It is my design if I want to gate my clocks. :) With what little I have read on CMOS design see harder to design a single master clock and route to all the flipflops with clock skew than it is have a multi-phase gated clock and use latches where clock skew is less critical. But then again my philosophy is different in design, that a cpu has to share a memory bus, and making a CPU fast with the price that it is the only thing that can the use bus seems counter productive to overall speed of the system. > ATPG (Automatic Test Pattern Generation) is the way all ASICs currently > are tested. The tools for this are for example Mentor FastScan, Synopsys > TetraMax, Synopsys TestCompiler etc. Well when somebody has several K$ to give me for real proto-type production of a chip I will refrain from further comments on chip testing. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Feb 15 22:32:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byel-0000Gc-01 for ; Sat, 16 Feb 2002 07:49:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:11 +0100 (CET) Received: (qmail 13875 invoked by uid 0); 15 Feb 2002 21:30:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 15 Feb 2002 21:30:10 -0000 Received: by moria.seul.org (Postfix) id 9569514687E; Fri, 15 Feb 2002 16:30:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 764A41468CD; Fri, 15 Feb 2002 16:30:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 99A8414687E for ; Fri, 15 Feb 2002 16:30:08 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA08596 for ; Fri, 15 Feb 2002 14:30:07 -0700 (MST) Message-ID: <3C6D7E53.A66B368@jetnet.ab.ca> Date: Fri, 15 Feb 2002 14:32:03 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Horror! As long as the latch is transparent, you can't be sure that > its outputs are correct (and stable), so using them is absolutely > pointless. If you need the value of the flag before the register is > written, grab it at the input. I say massive pipelining is useless and multi-instruction processing at a time really are not the way to design general purpose systems. I see a CPU as a computing engine... In a Car it is not how many RPM the engine runs at but the Torque on the rear wheels that move the Car. You have a transmission to provide for things like hills or starting off. In a computer to process data you need 4 things 1) where to get the information 2) what to do with the information 3) the information itself 4) what to do with the information when you are done with it. Like a 4 stroke engine this is the basic computing cycle.If you want a faster machine like a 2 stroke engine you have speed but you burn oil or lose torque or something in the process. The slowest item memory is really what gives the speed so how to use memory efficiently is the problem not how many mips you have. To me a RISC machine still looks like a old computer with a single accumulator and paged memory and indirect addressing, because of the way it is used. While things are faster are they more efficient? I read some where a version of the Pentuim had 4 adders but decoding only could generate instructions to the pipeline for 3 adders. One never got used. My grumbles and gripes for today. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Feb 16 06:00:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byem-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:12 +0100 (CET) Received: (qmail 25159 invoked by uid 0); 15 Feb 2002 22:54:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 15 Feb 2002 22:54:54 -0000 Received: by moria.seul.org (Postfix) id 3405B1467EA; Fri, 15 Feb 2002 17:54:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 266BC1468CD; Fri, 15 Feb 2002 17:54:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B94E31467EA for ; Fri, 15 Feb 2002 17:54:52 -0500 (EST) Received: from ifrance.com (vlt10-29.n.club-internet.fr [195.36.223.29]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 17A3B16CB for ; Fri, 15 Feb 2002 23:54:46 +0100 (CET) Message-ID: <3C6DE771.9B7189AB@ifrance.com> Date: Sat, 16 Feb 2002 00:00:33 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> <3C6D7E53.A66B368@jetnet.ab.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk a écrit : > > Michael Riepe wrote: > > > Horror! As long as the latch is transparent, you can't be sure that > > its outputs are correct (and stable), so using them is absolutely > > pointless. If you need the value of the flag before the register is > > written, grab it at the input. > > I say massive pipelining is useless and multi-instruction processing at > a time really are not the way to design general purpose systems. I see a > CPU as a computing engine... In a Car it is not how many RPM the engine > runs at but the Torque on the rear wheels that move the Car. You have a > transmission to provide for things like hills or starting off. In a > computer to process data you need 4 things 1) where to get the > information 2) what to do with the information 3) the information itself > 4) what to do with the information > when you are done with it. Like a 4 stroke engine this is the basic > computing cycle.If you want a faster machine like a 2 stroke engine you > have speed but you burn oil or lose torque or something in the process. > The slowest item memory is really what gives the speed so how to use > memory efficiently is the problem not how many mips you have. To me a > RISC machine still looks like a old computer with a single accumulator > and paged memory and indirect addressing, because of the way it is used. > While things are faster are they more efficient? I read some where a > version of the Pentuim had 4 adders but decoding only could generate > instructions to the pipeline for 3 adders. One never got used. My > grumbles and gripes for today. And you really beleive that intel scientist are so stupid ??? You really beleive that ? P4 as ONE decoder over 5 entry port BUT there is µop cache between unit and decoder, so it work ! nicO > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Feb 15 23:58:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byem-0000Gc-01 for ; Sat, 16 Feb 2002 07:49:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:12 +0100 (CET) Received: (qmail 15170 invoked by uid 0); 15 Feb 2002 23:04:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 15 Feb 2002 23:04:28 -0000 Received: by moria.seul.org (Postfix) id 3D69A1468CF; Fri, 15 Feb 2002 18:04:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B0BC1468CE; Fri, 15 Feb 2002 18:04:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a181.home.uni-hannover.de [130.75.232.181]) by moria.seul.org (Postfix) with ESMTP id 6768D1468B6 for ; Fri, 15 Feb 2002 18:04:24 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01073; Fri, 15 Feb 2002 23:58:15 +0100 Message-ID: <20020215235815.55103@thrai.stud.uni-hannover.de> Date: Fri, 15 Feb 2002 23:58:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202151558.0b12@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200202151558.0b12@th00.opsion.fr>; from nicolas.boulay@ifrance.com on Fri, Feb 15, 2002 at 03:58:11PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Feb 15, 2002 at 03:58:11PM +0000, nicolas.boulay@ifrance.com wrote: [...] > >>>For large memory SRAM are much better !! An SRAM cell is a kind of latch, essentially. At least that's true for the ones I know. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Feb 16 00:30:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byen-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:13 +0100 (CET) Received: (qmail 24561 invoked by uid 0); 15 Feb 2002 23:28:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 15 Feb 2002 23:28:38 -0000 Received: by moria.seul.org (Postfix) id C80071467F8; Fri, 15 Feb 2002 18:28:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB5921468B6; Fri, 15 Feb 2002 18:28:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id B625F1467F8 for ; Fri, 15 Feb 2002 18:28:34 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-209.jetnet.ab.ca [207.34.60.209]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id QAA13984 for ; Fri, 15 Feb 2002 16:28:30 -0700 (MST) Message-ID: <3C6D9A14.A5B4FC9B@jetnet.ab.ca> Date: Fri, 15 Feb 2002 16:30:28 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> <3C6D7E53.A66B368@jetnet.ab.ca> <3C6DE771.9B7189AB@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO wrote: > And you really beleive that intel scientist are so stupid ??? You really > beleive that ? P4 as ONE decoder over 5 entry port BUT there is µop > cache between unit and decoder, so it work ! I read that a few years ago when they had CPU wars out with who had a better 586. I thought I read that here http://x86.ddj.com/secrets/intelsecrets.htm but web sites really change around often. If I remember right some parts of the cpu did not not meet timing or size specs forcing them to be removed before the chip hit production leaving a alu that was under used. > nicO > -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 16 02:12:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byeq-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:16 +0100 (CET) Received: (qmail 3901 invoked by uid 0); 16 Feb 2002 01:07:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 16 Feb 2002 01:07:22 -0000 Received: by moria.seul.org (Postfix) id D33DF1468CB; Fri, 15 Feb 2002 20:07:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CC5251468CA; Fri, 15 Feb 2002 20:07:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 570B2146803 for ; Fri, 15 Feb 2002 20:07:20 -0500 (EST) Received: from f-cpu.org (kdl21-28.n.club-internet.fr [213.44.96.28]) by relay-4v.club-internet.fr (Postfix) with ESMTP id EAEC41692 for ; Sat, 16 Feb 2002 02:07:16 +0100 (CET) Message-ID: <3C6DB1E8.1C493B82@f-cpu.org> Date: Sat, 16 Feb 2002 02:12:08 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello again, Kim Enkovaara wrote: > > first, it's a bit smaller. Depending on the amount of control logic, > > the gain varies. The memory cell (4 transistors) requires decoding > > and clock buffering, IIRC the sxlib FF uses around 20 transistors. > > Is the logic size anymore a problem? it remains and always will be ! IIRC most of the problems arise in the wires. If your cells require X times more transistors, the overall wire length will roughly increase by X. Since most of the power is consumed when loading/unloading the wires, and wire resistance is roughly proportional L^2, your power dissipation will increase for less functionality. > At 0.13u you can get about > 200kgates/mm^2, and minimum size silicon for reasonable packages is > around 100mm^2. Usually the logic in current generation chips is small > grain in some corner of the chip and rest is memory. And memory is done > quite differently layoutwise depeding on memory technology and speed > (about 300-1600kbit/mm^2). nice. It's the promise of a nice and wide L2 cache. but let's not think like Microsoft ("let's consume whatever new ressource appears"). The end user might want to use the remaining surface for including peripherals, coprocessors, other CPUs... and everything must be testable ;-) > Optimizing few transistors/gates is not worth the job anymore. i don't agree here. Though we all (?) know it's difficult and heavy, it's worth some attention ! just remember that, according to a first approximation, one half of the circuit (surface and time) will be used by pipeline FF. If you make a smaller FF cell, the circuit will be directly impacted in speed and power consumption. just by optimising _one_ gate. > The problem is becoming power usage, yield, design sizes etc. considering that FF might use 1/2 of the surface, yield will be impacted as the surface will be reduced, which also reduces the size of the clock tree (fanout, power, speed etc...) > And to attack power use > usually gate counts rise quite dramatically (sounds odd but this is the > truth). For example some power saving cells have twice the amount of > transistors to fight with power leakage in the cell. FC0 was not designed for ultra-low power, rather for getting the best performance for a given technology. This implies a good MIPS/Watt ratio but in a higher Watt range. and higher MIPS too :-) > Efficient signaling between blocks also adds more logic, > block level clock management also is quite complex thing. For the FC0 i don't see where it can be modified. > > in another mail Bruno spoke about a 16*64 cell that can work at 2.2ns, > > this puts the maximum operating frequency (.18u) at around 300 or 400MHz. > > You have to remember that there are also different cell libraries for > commercial processes. Some libraries are geared for maximum performance > and consume more power and the yield might be lower. Then there are > lopower cells that are slower. These things are very difficult to predict > without real data and libraries. And those who have access to the data > have NDAs so we have to be very careful what we speak (no excact numbers > only ballpark figures, no manufacturer names etc.). NDAs hurt :-( However, it would be cool if a lot of people asked their foundry rep. for public-domain generic interfaces to their meory array cores. > --Kim WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 16 02:12:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byer-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:17 +0100 (CET) Received: (qmail 31831 invoked by uid 0); 16 Feb 2002 01:07:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 16 Feb 2002 01:07:25 -0000 Received: by moria.seul.org (Postfix) id D645D1468CE; Fri, 15 Feb 2002 20:07:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D30B61468CD; Fri, 15 Feb 2002 20:07:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 7A5661468C1 for ; Fri, 15 Feb 2002 20:07:23 -0500 (EST) Received: from f-cpu.org (kdl21-28.n.club-internet.fr [213.44.96.28]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 56468168F for ; Sat, 16 Feb 2002 02:07:18 +0100 (CET) Message-ID: <3C6DB1E9.2EE8ED93@f-cpu.org> Date: Sat, 16 Feb 2002 02:12:09 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: test (was: Re: Rep:Re: Re: [f-cpu] No latches, please !) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! the discussion about the register set has forked to this of testing the chip. If this is to continue, we will have to agree on common definitions that will ease the discussion. Testing is performed during chip power-on (on-site) when it is not a FPGA (which has a technology-dependent verification and must be shipped without any defect). This is also the BIST that initialises the chip to a known state (empty TLB entries, empty cache, register set zeroed...). Because a reset can be forced in "real-time" constrained situations, it should last during a specified time, usually not more than a fraction of second : from a few thousand cycles to millions of cycles, which at 50MHz requires less than a second. A Pentium CPU takes 5 millions cycles IIRC, mainly because the microcode ROM and all the complex features must be tested. I hope that F-CPU will not reach this level. Testing is also required in another situation : during fabrication, just before the dies are packaged. As Kim mentions, it's a cost-sensitive place because each second the test equipment is used must be paid (i don't remember the prices however). Given a wafer whith 100 dies and if the tester uses 1 second to move from one dies to another, it is already 1 minute and 40 seconds to pay. correct me if i'm wrong. The tester must verify that the pads are working at the specified frequency, power is correctly applied, the clock tree works... up to the point where it is certain that the chip is valid. There are different means and fortunately some are parallelisable. This become critical when the CPU is part of a larger chip with peripherals and other devices that contain their own BIST. Scan chains are simple and easy means to test a circuits but - the FF cells are larger - the testing time is somewhere near O(n^2) for n FF (the testing time for a N I/O circuit is roughly proportional to N and a scan chain requires N cycles to be replaced) So it is only good for specific parts of the circuit where other means to bring data and verify it do not exist. Whenever there is a simple and fast way to test a part of the circuit, it must be used, particularly because generating the "vectors" of the scan chain is complicated and these vectors must be stored somewhere (more surface). If the scan vectors can't be stored onchip, the external tester must provide them and the test can't work at full circuit speed (there is a risk that high-frequency specific errors [such as those due to crosstalk] can't be detected). Using LFSR is another possibility for faster testing. It still requires modified FF for initialising the state and switching between test/functioning mode and the fault coverage is high with no vector ROM. However it's not easy to tune and depends on the used technology. There are tools for this but usually a good hand-designed LFSR can do very good results. Testing time however can take a similar time as a simple scan chain because the LFSR must explore enough states (goes as 2^N). The problem is to know when enough states are explored, how many cycles are necessary until 100% coverage is reached. Once again, correct me if i'm wrong. The other advantage is that because the test "vectors" are internally generated, there is no need to provide them through an external test interface and the freqency can be the real operating frequency, thus catching errors that could not be detected at lower frequencies. The previous means are used for logic stages. For example, a 16-bit LFSR can be used to test the opcode part of the instruction decoder and a signature is collected with another (much larger) LFSR at the other end. When the signature does not match, there is an error which is forwarded to the tester or the rest of the circuit which does not boot. For non-boolean stages, such as storage cell, another method must be used because we can't implement a scan chain inside the cells of the register set or the caches ! the circuit surface would bloat and it would thus run slowly. * For the execution pipeline, the BIST unit "hijacks" the control of the scheduler and the control signals are autogenerated and sent to the apropriate units. It works with full width vectors (64 bits at once) and we can "chain" several units together. * For the memory arrays, another method is useful, which i used already. The vectors are very easy to generate and scales well with the cell number (O(log2 N)) but we are limited by the bus width so a multicycle unit is necessary. For the register set, for example, we need 2*(63*Log2(63*64)+1)=1512 R+W cycles per write and read port. This can be reduced by not sending identical/duplicate vectors because since the access bus is not 4032 bits wide, it would send duplicate data. Remark that this method catches ALL coupling between any wire, on top of the usual stuck at 0 or 1. The same method can be applied to the caches. Another remark is that the result of a read, instead of being sent back to the BIST unit, can be chained with other units before the usual verification in a MISR. The BIST unit generates the vectors and the control signals that allow these tests to occur in parallel when necessary, but always at full operating speed. Kim Enkovaara wrote: > > Concerning the test, remember that there is a BIST unit that > > takes control of the whole datapath and takes care to test > > all the execution units and the memory arrays. If the "latch" > > (those you like and/or those you don't) is in the datapath, > > it -will- be tested. Those that can't be tested without complex > > stuff will use a classical scanpath but the scan chain will be > > kept as short as possible. > > By the way, one of the optional units (popcount) will certainly > > be used for signature compaction. > > How many patterns have you tought to use. Datapath style BIST takes very > long times, probably many days. Each second in ASIC tester costs real > money. You need very quick results in ASIC tster to notify if the chip is > OK (IDDQ tests, ATPG patterns, quick RAM bists etc.) The above rant partially answers your questions. Remember that i have designed a testing equipment for Mentor Graphics ;-) And i currently have testing courses and practice in the university. i know it's not directly related but the methods i will integrate in the BIST unit are a sophisticated version of the "logarithmic" test method that is used for routing equipment : exhaustive, simple and fast. In order to speed the fundry tests, parallel verifications have to take place : first the circuit is powered (+ clocked) and the BIST runs internal verifications while the tester checks the IO pads. a specific "test" pad must be used to decouple the pads in order to use a parallel test path. When it's ok (half a second), the circuit must verify that it can access the outside pins, so the tester starts to communicate with the circuit, uploading executable code and data in the memory. The code starts, executes additional tests (i guess it's necessary) and the tester can act as a "swap" for the code chunks that don't fit in the cache. One thing to keep in mind is that the tester, for cost reasons, might not provide as many pins as there are on the chip and the tester speed is probably lower than what the tested circuit can run. For example an old, second-hand or cheap tester can provide only 64 I/O pins and work at 10MHz while the chip could run at 100MHz (just an example, not reality ;-D). So the power is applied on the chip and the PLL starts : it must be configured to have a 10x ratio with the external clock, then the BIST starts. Only the power planes are connected, as well as a few control signals, so the interactivity is reduced and a lot of things rely on the internal ressources of the chip. Usually, when the number of pads is larger than what the tester can do, several passes are done on different sections of the circuit. > > How much do i have to emphasize on this ? > > Yes, this will be custom-designed test but > > - we don't need ATPG > > - we couldn't afford it anyway > > - always trust your nose and make meaningful measurements. > > I doubt that you can make the BIST to cover the whole chip without > sacrificin performance and the test times will be huge. i don't want to make any sacrifice :-) > Also "all" the > commercial Logic BIST testers work by hooking into the scan chains and > they generate patterns to those chains. Also to minimise the test time > Logic BIST needs quite complex things (reseedable pattern generators, > randomness distribution changes based on feedback, random generator > optimization based on scanpath and design etc.) argh. > BIST is only a small part of testing. It is good for memories and > fullspeed logic testing but to get >95% coverage for logic with BIST is > very challenging. i know but fortunately we're still at an early stage of the design so it's still time to correct wrong design techniques. Of course, i count on your expertise to detect our errors :-) > --Kim WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 16 04:27:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byes-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:18 +0100 (CET) Received: (qmail 18484 invoked by uid 0); 16 Feb 2002 03:22:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 16 Feb 2002 03:22:27 -0000 Received: by moria.seul.org (Postfix) id 35BB71467FE; Fri, 15 Feb 2002 22:22:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29B761468C1; Fri, 15 Feb 2002 22:22:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 8C2A21467FE for ; Fri, 15 Feb 2002 22:22:24 -0500 (EST) Received: from f-cpu.org (kdl16-12.n.club-internet.fr [213.44.18.12]) by relay-4v.club-internet.fr (Postfix) with ESMTP id AD7DC168E for ; Sat, 16 Feb 2002 04:22:21 +0100 (CET) Message-ID: <3C6DD191.10C99010@f-cpu.org> Date: Sat, 16 Feb 2002 04:27:13 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] testing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N GOOOOOOooooood evening, F-CPUers ! :-) Kim Enkovaara wrote: > > PS: to answer Kim, there must be a dedicated "BIST" unit in the pipeline, > > which overrides the scheduler and performs the integrity check of most > > of the ressources (let's say : 80%). The rest is done with a scan chain > > for the ressources which are not directly addressable by the execution > > pipeline. BIST could be extended later to include a L2 and SDRAM check > > routine (it's not difficult). > > Why is is a must to have BIST in the pipeline? for me it's obvious : access the register set and all the units in a single cycle ! FC0 is a modular design and there is no performance hit to add another unit, even though it is not an "execution" unit. > It would be much easier to test it with normal scanchains. "easy" ? hmmm then please calculate how many cycles it will take to fully verify (100% or 95%, whatever you want) the multiplier unit, for example. By having the BIST unit tied to the Xbar, it IS 64x faster. then comes the algorithm, but 64x is already nice, no ? > For memories MemoryBIST is needed, but > that is quite different story. Also dividing the work between atpg and > bist is quite difficult, how do you calculate real fault coverage? i'll use HILO at the university ;-) seriously, it is impossible to know because fault coverage tools work on already synthesized designs, where all the wires and gates are flattened. unless you know another method that directly works at the behavioural VHDL level ? However, "divide and conquer" (quote from another post) works well during tests (in fact, it's often the only way to find where and what an error is). Remember, every Execution Unit has a testbench that verifies that the unit works as expected : at that level, we can start to think about the best way to ensure that the BIST will work. Currently, the ASU and IMU use an "exhaustive" approach (around 15 minutes of VHDL simulation :-/) but we can find a better way from the start. When applied to all the modules, and with a well designed BIST unit, we can already cut a large portion of the ATPG's effort, right ? > If the test coverage is not in the ballpark of 95% the chip is not usable for > mass production, you just get too much broken chips to end products. right. But i hope that with this thread, you are reassured that we won't get to F-CPU rev. 0.5 before 99% coverage is achieved. There is reasonably no silicon before Rev. 1, btw. > Also remeber that in ASIC tester you have about 5-10s of time for the > testing. Each second costs real money in the tester, there is no time to > run minutes of tests. 10 seconds ? that's long ! :-) oh yes, i have forgotten that F-CPU can be mixed with other modules on the same chip and that you design 50M+ circuits, sorry... i'm such a naive guy, sometimes :-) > --Kim WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 16 04:27:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16byet-0000Gc-00 for ; Sat, 16 Feb 2002 07:49:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 07:49:19 +0100 (CET) Received: (qmail 17191 invoked by uid 0); 16 Feb 2002 03:22:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Feb 2002 03:22:31 -0000 Received: by moria.seul.org (Postfix) id 960D8146803; Fri, 15 Feb 2002 22:22:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 790E21468CA; Fri, 15 Feb 2002 22:22:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2CD3D1468C1 for ; Fri, 15 Feb 2002 22:22:30 -0500 (EST) Received: from f-cpu.org (kdl16-12.n.club-internet.fr [213.44.18.12]) by relay-3v.club-internet.fr (Postfix) with ESMTP id DFBB216AE for ; Sat, 16 Feb 2002 04:22:26 +0100 (CET) Message-ID: <3C6DD197.832801BD@f-cpu.org> Date: Sat, 16 Feb 2002 04:27:19 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Feb 15, 2002 at 02:48:54AM +0100, Yann Guidon wrote: > [...] > > > A latch is quicker in terms of what? Delay time? Setup time? Clock > > > frequency? > > > > first, it's a bit smaller. Depending on the amount of control logic, > > the gain varies. The memory cell (4 transistors) requires decoding > > and clock buffering, IIRC the sxlib FF uses around 20 transistors. > > > > Setup time + hold are the same or not, depending on the kind > > of gates you use. For example, in sxlib, they use a couple of 4T cells > > which are overwritten by using a buffer with high driving capability. > > On of the inverters of the 4T cell has a low drive and the buffer can > > overwrite the previous value. > > Master-slave-FF with the cheapest latches available? i don't understand what you mean. > [...] > > > Latches have one big disadvantage: they can become transparent. > > and sometimes, they do it :-) > That's the problem ;) if you are in a situation where it is, i can do nothing for you ;-) > > This is both an advantage and a drawback so you have to choose > > where to use them. For example, the register set uses latches, > > both for the registers and their "showdow flags" because we want > > to know the flag's value, EVEN during a cycle when it is being > > written to... > > Horror! As long as the latch is transparent, you can't be sure that > its outputs are correct (and stable), so using them is absolutely > pointless. If you need the value of the flag before the register is > written, grab it at the input. i'll have to be more precise. there are "shadow flags" which indicate whether a register is zero or not. This is one of the hottest/nastiest things in the register set "entity". in the 64-bit implementation, it takes 5 bits, one bit per "slice" (there are 2*8 bit slices and 3*16-bit slices). the bits are updated depending on the write mask, it is read on every cycle so we know whether a condition is true or false : it is a 2W1R bank. The problem arises when there is a buble in the pipeline, which stalls waiting for a result which conditions the issue of the currently decoded instruction. During the R7 writeback cycle, the bits in a slice are ORed together and sent to the 2W1R bank of 5*63 bits (each of the 5 bits are conditionned by the write mask). The 1R output of the 5-bit vector is ORed and gives the needed bit. If we use a transparent latch, the flow-through time of the cell uses one gate delay. Otherwise, using a FF, there is the need to create a bypass path : it introduces a MUX for each of the 5 bits because we have to choose which of the old or new flag is read, depending on the write mask and other flags. Although you might not like it, using a transparent latch is an elegant solution and compromise. Using synchronous logic increases the complexity of the logic and my brain has limited computational power :-( > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Feb 16 09:00:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16c1Zt-0002kV-00 for ; Sat, 16 Feb 2002 10:56:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 10:56:21 +0100 (CET) Received: (qmail 28815 invoked by uid 0); 16 Feb 2002 08:09:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 16 Feb 2002 08:09:38 -0000 Received: by moria.seul.org (Postfix) id DD2A31468D5; Sat, 16 Feb 2002 03:09:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D51421468D4; Sat, 16 Feb 2002 03:09:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-17.ras.tesion.net [195.226.100.17]) by moria.seul.org (Postfix) with ESMTP id F22321468D2 for ; Sat, 16 Feb 2002 03:09:35 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16bzmD-0006vm-00 for f-cpu@seul.org; Sat, 16 Feb 2002 09:00:57 +0100 Date: Sat, 16 Feb 2002 09:00:56 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) In-Reply-To: <3C6DB1E9.2EE8ED93@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi guys, very, very intersting discussion. Let me add another thing: The test strategy of a device is very important. But also very important is WHEN you are able to start a test. The computer world is moving to cluster designs. It may be a very good idea to implement a test strategy that can be activated anytime! I.e. my suggestion is to make selftest a part of the normal operation of the device that can be activated by software! JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Feb 16 09:04:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16c1Zu-0002kV-00 for ; Sat, 16 Feb 2002 10:56:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 10:56:22 +0100 (CET) Received: (qmail 23639 invoked by uid 0); 16 Feb 2002 08:09:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 16 Feb 2002 08:09:39 -0000 Received: by moria.seul.org (Postfix) id 06DFF1468D3; Sat, 16 Feb 2002 03:09:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E14361468D6; Sat, 16 Feb 2002 03:09:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-17.ras.tesion.net [195.226.100.17]) by moria.seul.org (Postfix) with ESMTP id D57E21468D3 for ; Sat, 16 Feb 2002 03:09:37 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16bzph-0006vo-00 for f-cpu@seul.org; Sat, 16 Feb 2002 09:04:33 +0100 Date: Sat, 16 Feb 2002 09:04:33 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! In-Reply-To: <3C6D7E53.A66B368@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 15 Feb 2002, Ben Franchuk wrote: > Michael Riepe wrote: > > > Horror! As long as the latch is transparent, you can't be sure that > > its outputs are correct (and stable), so using them is absolutely > > pointless. If you need the value of the flag before the register is > > written, grab it at the input. > > I say massive pipelining is useless and multi-instruction processing at > a time really are not the way to design general purpose systems. I see a > CPU as a computing engine... In a Car it is not how many RPM the engine > runs at but the Torque on the rear wheels that move the Car. You have a > transmission to provide for things like hills or starting off. In a > computer to process data you need 4 things 1) where to get the > information 2) what to do with the information 3) the information itself > 4) what to do with the information > when you are done with it. Like a 4 stroke engine this is the basic > computing cycle.If you want a faster machine like a 2 stroke engine you > have speed but you burn oil or lose torque or something in the process. > The slowest item memory is really what gives the speed so how to use > memory efficiently is the problem not how many mips you have. To me a > RISC machine still looks like a old computer with a single accumulator > and paged memory and indirect addressing, because of the way it is used. > While things are faster are they more efficient? I read some where a > version of the Pentuim had 4 adders but decoding only could generate > instructions to the pipeline for 3 adders. One never got used. My > grumbles and gripes for today. Hi, perfectly understand what you want to say. I am a system designer and when you do system design you know that the key feature for performance is where you put your data and how you manage to move it as little as possible. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Sat Feb 16 09:41:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16c1Zx-0002kV-00 for ; Sat, 16 Feb 2002 10:56:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 10:56:25 +0100 (CET) Received: (qmail 14358 invoked by uid 0); 16 Feb 2002 08:41:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 16 Feb 2002 08:41:54 -0000 Received: by moria.seul.org (Postfix) id 45F231468D2; Sat, 16 Feb 2002 03:41:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A0591468D6; Sat, 16 Feb 2002 03:41:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 788DA1468D2 for ; Sat, 16 Feb 2002 03:41:52 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id KAA13484 for ; Sat, 16 Feb 2002 10:41:51 +0200 Date: Sat, 16 Feb 2002 10:41:51 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: test (was: Re: [f-cpu] No latches, please !) In-Reply-To: <3C6DB1E9.2EE8ED93@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Testing is also required in another situation : during fabrication, > just before the dies are packaged. As Kim mentions, it's a cost-sensitive > place because each second the test equipment is used must be paid > (i don't remember the prices however). Given a wafer whith 100 dies I doubt that you have heard the excact figures. These figures are almost as sensitive as real yeild figures. FABs don't want to give the customer too much information about their financial parameters of the process. Of course the testing time can be seen in the chip costs, but usually they are embedded to the total cost. And when memory testing is usually the dominating factor some maximum times can be calculated. > and if the tester uses 1 second to move from one dies to another, > it is already 1 minute and 40 seconds to pay. correct me if i'm wrong. Also tester reloads are expensive if the vectorset doesn't fit into the tester memory. But that is a problem for very complex and huge chips. For that vector packing is used. > Scan chains are simple and easy means to test a circuits but > - the FF cells are larger Not very much fortunately. Bigger problem is the extra routing needed, but current processes have enough metal layers and this is not so big problem. > - the testing time is somewhere near O(n^2) for n FF > (the testing time for a N I/O circuit is roughly proportional to N > and a scan chain requires N cycles to be replaced) Actually the time is not that big. First trick is to cut the scan chains to many parts, usually 8-16 chains are supported in the testers. Also the vectors can be optimized, not all combinations need to be tested. Scan chains are used for chips that have millions of gates and testing time is still reasonable (in order of seconds). > So it is only good for specific parts of the circuit where other > means to bring data and verify it do not exist. Whenever there > is a simple and fast way to test a part of the circuit, it must be used, > particularly because generating the "vectors" of the scan chain > is complicated and these vectors must be stored somewhere (more surface). The vectors are usually in the testers. Chip testing is part of the whole manufacturing process, the vendor does this part of testing. If you start to store vectors to chip that is LogicBIST already. > If the scan vectors can't be stored onchip, the external tester > must provide them and the test can't work at full circuit speed > (there is a risk that high-frequency specific errors [such as > those due to crosstalk] can't be detected). These are problems that are not detected, but they should be attacked during design. Crosstalk can be minimised with special tools and that is part of the layout process. The manufacturer can check process goodness with their own proprietary structures in the chip. In processor business after the first test for manufacturing fauls the chips are run at different speeds and separated to different lots. But this part might not be supported by the fabs, they are only interested that manufacturing was correct and minimum requirements were met. > Using LFSR is another possibility for faster testing. It still requires > modified FF for initialising the state and switching between test/functioning > mode and the fault coverage is high with no vector ROM. However it's not Actually LFSR style LogicBIST is good for fullspeed testing of the chip. But it is not good for manufacturing test that needs good coverage. LogicBIST is usually used to test chip integrity by running it in redundant parts over night in missin critical solutions. Actually this is what vendor of LogicBIST tools said :) > Testing time however can take a similar time as a simple scan chain > because the LFSR must explore enough states (goes as 2^N). The problem is The problem is bigger with LFSR because the vector space can't be optimized. You just use random vectors and hope that they catch errors. The coverage can be simulated but that is quite slov job. > to know when enough states are explored, how many cycles are necessary until > 100% coverage is reached. Once again, correct me if i'm wrong. 100% coverage is not usually possible because of monetary reasons. That would take too much tester time. Usually >95% coverage is adequate, in huge volume chips this figure might be >97%. > The other advantage is that because the test "vectors" are internally > generated, there is no need to provide them through an external test interface > and the freqency can be the real operating frequency, thus catching errors > that could not be detected at lower frequencies. The external interface is usually muxed to existing IO. You just have few test pins that change the I/O functionality. > The previous means are used for logic stages. For example, a 16-bit LFSR > can be used to test the opcode part of the instruction decoder and a signature > is collected with another (much larger) LFSR at the other end. When the > signature does not match, there is an error which is forwarded to the tester > or the rest of the circuit which does not boot. How have you tought to change this information to test coverage. Manufacturers won't manufacture a chip if they doubt that the test coverage is not good enough. There are tools to simulate test coverage, but again they are quite expensive stuff. > * For the memory arrays, another method is useful, which i used already. > The vectors are very easy to generate and scales well with the cell number > (O(log2 N)) but we are limited by the bus width so a multicycle unit is necessary. > For the register set, for example, we need 2*(63*Log2(63*64)+1)=1512 R+W cycles > per write and read port. This can be reduced by not sending identical/duplicate vectors > because since the access bus is not 4032 bits wide, it would send duplicate data. > Remark that this method catches ALL coupling between any wire, on top of the > usual stuck at 0 or 1. The same method can be applied to the caches. > Another remark is that the result of a read, instead of being sent back > to the BIST unit, can be chained with other units before the usual verification > in a MISR. For memory testing there are huge pile of algorithms to choose how the memory is tested. Memories have quite often faults that come from the neighbouring cells and simple tests wont detect those. Good book about memory testing is Van de Goor: Testing Semiconductor Memories. In short good algorithm for memory testing is some form of the March algorithms. I guess that google search rteturns quite much about this. Also IEEE library has good papers about memory testing. > Remember that i have designed a testing equipment for Mentor Graphics ;-) Hmm.. I tought that those were just simulation accelerators that are made in France. Isn't FastScan, LogicBIST, MemBIST etc. US products. And as far as I know Mentor doesn't do manufacturing testers :) > And i currently have testing courses and practice in the university. > i know it's not directly related but the methods i will integrate in the > BIST unit are a sophisticated version of the "logarithmic" test method > that is used for routing equipment : exhaustive, simple and fast. Actually what I learned at university about testing was something from the 80s, unfortunately, I hope you have better lectureres. Most of what I know comes from matrial by Ben Bennets (http://www.dft.co.uk/). > When it's ok (half a second), the circuit must verify that it can access > the outside pins, so the tester starts to communicate with the circuit, Functional vectors are not so common in testing, but of course they can be used. In normal testflows they are fed in after normal ATPG tests to make few additional checks. > One thing to keep in mind is that the tester, for cost reasons, might > not provide as many pins as there are on the chip and the tester speed > is probably lower than what the tested circuit can run. For example an > old, second-hand or cheap tester can provide only 64 I/O pins > and work at 10MHz while the chip could run at 100MHz (just an example, Actually that is not usually the case. When you select packages etc. for the chip the manufacturer has to allocate tester for manufacturing of the chip (decide what manufacturing and tester lines are used and if they are free). If there is no such tester manufacturer is forced to get a new one. That is part of NREs and testing costs of the chip. Of course this is different if some chip is very low volume, then long testing times are not so hughe problem. > Usually, when the number of pads is larger than what the tester > can do, several passes are done on different sections of the circuit. This is possible, but I doubt that this is very common. --Kim ps. I'm not an testing expert, I have just seen few ASICs done :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Sat Feb 16 09:53:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16c1Zy-0002kV-00 for ; Sat, 16 Feb 2002 10:56:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 10:56:26 +0100 (CET) Received: (qmail 6161 invoked by uid 0); 16 Feb 2002 08:53:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 16 Feb 2002 08:53:47 -0000 Received: by moria.seul.org (Postfix) id 7BAE11468D4; Sat, 16 Feb 2002 03:53:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54FA61468D7; Sat, 16 Feb 2002 03:53:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 87CF41468D4 for ; Sat, 16 Feb 2002 03:53:45 -0500 (EST) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id KAA13652 for ; Sat, 16 Feb 2002 10:53:44 +0200 Date: Sat, 16 Feb 2002 10:53:44 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] testing In-Reply-To: <3C6DD191.10C99010@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > It would be much easier to test it with normal scanchains. > "easy" ? hmmm then please calculate how many cycles it will take to > fully verify (100% or 95%, whatever you want) the multiplier unit, > for example. By having the BIST unit tied to the Xbar, it IS 64x faster. > then comes the algorithm, but 64x is already nice, no ? How many cycles does it take to test the multiplier with BIST that goes trough all the possible states :) With logic BIST you are also restricting the state space by simulating the fault coverage during design. You don't have to run all the possible states of the flipflops with vectors. You just have to guarantee that each flipflop has been tested for both 0 and 1 values (and the transitions). Then you need vectors that test the combinatorial logic in between, one vector can detect quite big amount of errors because errors paropagate. It is hard to say the needes amount of vectors but it is not very big. > seriously, it is impossible to know because fault coverage tools > work on already synthesized designs, where all the wires and gates > are flattened. unless you know another method that directly > works at the behavioural VHDL level ? There are tools that quickly synthesize the design and tell possible problems that affect the test coverage. That is the first phase. > and what an error is). Remember, every Execution Unit has a testbench > that verifies that the unit works as expected : at that level, > we can start to think about the best way to ensure that the BIST will work. I doubt that the test bench can test all possible combinations of the functionality either so that is guarantees reuirement that in synthesized design each node is tested for common fault types :) > Currently, the ASU and IMU use an "exhaustive" approach (around 15 minutes > of VHDL simulation :-/) but we can find a better way from the start. Hmm.. can you actually loop trough all combinations at that time. I just woke up and Espresso machine is warming up but isnt that already with 32 bits 2^64 cycles :) > When applied to all the modules, and with a well designed BIST unit, > we can already cut a large portion of the ATPG's effort, right ? Maybe, combining ATPG and BIST coverage is not trivial, it is possible :) > 10 seconds ? that's long ! :-) That time can be spent easily with 64k depth memory even if the test is running at full speed. The memory space need to be marched trough many times. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 16 15:23:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cAX7-0002uv-00 for ; Sat, 16 Feb 2002 20:30:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Feb 2002 20:30:05 +0100 (CET) Received: (qmail 24153 invoked by uid 0); 16 Feb 2002 14:18:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 16 Feb 2002 14:18:57 -0000 Received: by moria.seul.org (Postfix) id CF1321468D9; Sat, 16 Feb 2002 09:18:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C18E61468DB; Sat, 16 Feb 2002 09:18:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 628CD1468D9 for ; Sat, 16 Feb 2002 09:18:55 -0500 (EST) Received: from f-cpu.org (kdl21-105.n.club-internet.fr [213.44.96.105]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 4DA46169C for ; Sat, 16 Feb 2002 15:18:52 +0100 (CET) Message-ID: <3C6E6B71.B93110F0@f-cpu.org> Date: Sat, 16 Feb 2002 15:23:45 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > > Hi guys, > > very, very intersting discussion. my feeling, too :-) > Let me add another thing: > > The test strategy of a device is very important. But also > very important is WHEN you are able to start a test. The > computer world is moving to cluster designs. It may be a > very good idea to implement a test strategy that can be > activated anytime! I.e. my suggestion is to make selftest > a part of the normal operation of the device that can be > activated by software! so this boils down to be able to trigger a "hard reset" with SW. that's pretty easy to do, no ? > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Feb 16 21:36:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5a-00080b-00 for ; Sun, 17 Feb 2002 04:34:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:10 +0100 (CET) Received: (qmail 23175 invoked by uid 0); 16 Feb 2002 20:35:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 16 Feb 2002 20:35:50 -0000 Received: by moria.seul.org (Postfix) id E10A51468D7; Sat, 16 Feb 2002 15:35:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D0AD11468DD; Sat, 16 Feb 2002 15:35:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-106.ras.tesion.net [195.226.100.106]) by moria.seul.org (Postfix) with ESMTP id ADF1C1468D7 for ; Sat, 16 Feb 2002 15:35:48 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16cBZp-0007DN-00 for f-cpu@seul.org; Sat, 16 Feb 2002 21:36:57 +0100 Date: Sat, 16 Feb 2002 21:36:57 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) In-Reply-To: <3C6E6B71.B93110F0@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 16 Feb 2002, Yann Guidon wrote: > hi ! > > Juergen Goeritz wrote: > > > > Hi guys, > > > > very, very intersting discussion. > my feeling, too :-) > > > Let me add another thing: > > > > The test strategy of a device is very important. But also > > very important is WHEN you are able to start a test. The > > computer world is moving to cluster designs. It may be a > > very good idea to implement a test strategy that can be > > activated anytime! I.e. my suggestion is to make selftest > > a part of the normal operation of the device that can be > > activated by software! > > so this boils down to be able to trigger a "hard reset" with SW. > that's pretty easy to do, no ? Why do you want to do a hard reset? Just because Intel & Co. didn't think of other ways of doing a system test? My opinion is that it's not the state of the art any more. Just imagine you have a dual processor on a single SoC and you want this system to keep running if one of its components is tested. The hard reset wouldn't do it - you need a new test strategy. Other example: imagine a 500 processor cluster in an orbit around Jupiter at high rad doses (I love these examples :) 1/2 of your cluster sleeps to recover from radiation, the other half is operating. Before sleep you test, after sleep you test and during operation you test at regular intervals. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Feb 16 22:26:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5a-00080b-01 for ; Sun, 17 Feb 2002 04:34:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:10 +0100 (CET) Received: (qmail 31585 invoked by uid 0); 16 Feb 2002 21:25:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 16 Feb 2002 21:25:21 -0000 Received: by moria.seul.org (Postfix) id 9DEA81468DB; Sat, 16 Feb 2002 16:25:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 964D21468DE; Sat, 16 Feb 2002 16:25:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id C95FA1468DB for ; Sat, 16 Feb 2002 16:25:12 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id OAA18427 for ; Sat, 16 Feb 2002 14:25:02 -0700 (MST) Message-ID: <3C6ECE9A.6B925917@jetnet.ab.ca> Date: Sat, 16 Feb 2002 14:26:50 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Other example: imagine a 500 processor cluster in an orbit > around Jupiter at high rad doses (I love these examples :) > 1/2 of your cluster sleeps to recover from radiation, the > other half is operating. Before sleep you test, after sleep > you test and during operation you test at regular intervals. Nah... I would have the 500 cluster in orbit around the sun running a anti-matter production plant using solar energy. Anti-matter takes a hell a lot of energy to produce but could make inter-planetary travel possible. The problem is that transistor size of modern logic is it too small to not glitch or fry from radiation. A machine with a 250 ns memory cycle and 1 Meg of ram could be a practical size and speed limit for hard radiation. While I have not looked a 'Leon' I would expect to have error checking of some kind in the alu and memory circuits. That was one advantage the old decimal machines had, error checking codes.A parity bit may be a good feature to consider with transistor sizes getting smaller and the mean time between soft errors goes down. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Feb 16 14:32:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5b-00080b-00 for ; Sun, 17 Feb 2002 04:34:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:11 +0100 (CET) Received: (qmail 25021 invoked by uid 0); 17 Feb 2002 00:11:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 17 Feb 2002 00:11:42 -0000 Received: by moria.seul.org (Postfix) id 582D514683C; Sat, 16 Feb 2002 19:11:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 455CE146845; Sat, 16 Feb 2002 19:11:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a161.home.uni-hannover.de [130.75.232.161]) by moria.seul.org (Postfix) with ESMTP id D222D14683C for ; Sat, 16 Feb 2002 19:11:37 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00500; Sat, 16 Feb 2002 14:32:13 +0100 Message-ID: <20020216143213.64156@thrai.stud.uni-hannover.de> Date: Sat, 16 Feb 2002 14:32:13 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> <3C6DD197.832801BD@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C6DD197.832801BD@f-cpu.org>; from Yann Guidon on Sat, Feb 16, 2002 at 04:27:19AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Feb 16, 2002 at 04:27:19AM +0100, Yann Guidon wrote: [...] > there are "shadow flags" which indicate whether a register is zero or > not. This is one of the hottest/nastiest things in the register set "entity". > in the 64-bit implementation, it takes 5 bits, one bit per "slice" > (there are 2*8 bit slices and 3*16-bit slices). the bits are updated > depending on the write mask, it is read on every cycle so we know > whether a condition is true or false : it is a 2W1R bank. Yep, I remember. The shadow flags are used when we have to check an operand for zero-ness, i.e. the scheduler will read it when it encounters a CJUMP, CMOVE or DIV instruction. If the register's value is being calculated at that time, the scheduler has to wait until the result is ready. Bypassing the register write isn't possible because it's not yet clear whether the next instruction is executed at all -- the condition may be false, or there might be a division-by-zero exception. > The problem arises when there is a buble in the pipeline, which stalls > waiting for a result which conditions the issue of the currently decoded > instruction. During the R7 writeback cycle, the bits in a slice are ORed > together and sent to the 2W1R bank of 5*63 bits (each of the 5 bits are > conditionned by the write mask). The 1R output of the 5-bit vector is ORed > and gives the needed bit. If we use a transparent latch, the flow-through > time of the cell uses one gate delay. I'd love to see a timing diagram. > Otherwise, using a FF, there is the need to create a bypass path : > it introduces a MUX for each of the 5 bits because we have to choose > which of the old or new flag is read, depending on the write mask > and other flags. Although you might not like it, using a transparent latch > is an elegant solution and compromise. Using synchronous logic increases > the complexity of the logic and my brain has limited computational power :-( IMHO, it's just the opposite: a mix of FFs and latches will increase the complexity. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 17 01:45:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5b-00080b-01 for ; Sun, 17 Feb 2002 04:34:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:11 +0100 (CET) Received: (qmail 16965 invoked by uid 0); 17 Feb 2002 00:40:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 17 Feb 2002 00:40:29 -0000 Received: by moria.seul.org (Postfix) id 49253146840; Sat, 16 Feb 2002 19:40:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3ADF8146847; Sat, 16 Feb 2002 19:40:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D1A41146840 for ; Sat, 16 Feb 2002 19:40:27 -0500 (EST) Received: from f-cpu.org (kdl21-15.n.club-internet.fr [213.44.96.15]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 8311916A5 for ; Sun, 17 Feb 2002 01:40:22 +0100 (CET) Message-ID: <3C6EFD1C.BCDDD237@f-cpu.org> Date: Sun, 17 Feb 2002 01:45:16 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <3C6C58C9.CAF60299@ifrance.com> <3C6C7747.7E486379@ifrance.com> Content-Type: multipart/mixed; boundary="------------7465AEC098E7149C8EFFAB01" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------7465AEC098E7149C8EFFAB01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, nicO wrote: > > Some example : > http://www.cse.psu.edu/~cg577/hw1s98.html i have looked and i was surprised by the first drawing (first attachment) : there is no feedback loop that memorizes the data :-/ is it precharged logic ? :-( The last one (IBM Power) looks more classical but i am surprised by the input buffer(s) at the source/drain and not the gate of the transistors. And in the last attachment, i have drawn a transparent latch with two inputs with the nice side effect that there is no oscillation if both write signals are set at the same time :-D WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------7465AEC098E7149C8EFFAB01 Content-Type: image/gif; name="hw1s98-1.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hw1s98-1.gif" R0lGODlh1wEHAfcAAP///wAAALOzs76+vl9fX4fO63CAkENndb3//wAAjJmZmUxMTNfX12Zm Zv/43GpazTUtZpR+/9nZ2X9/f5CAkMqzykhASDJlZf7+ADMzMxEREf9mZt3d3bu7u/j8+MDE wLi8uAAgOAA4UBhYYCh4iPD08AhYaAhweMjEyFCkqDicoJicmIBwcP//AEhQUCgoKAD/AP// 4P8AAHJ3hdK0jL+/v01NTYyMjBkZcLAwYPXes3Nzc8DAwOfn529vbwAAfwCAgAAA/4AAAICA AICAgGZmzDMzZgCAAJmZ/0KapyIiIv9mMwAAgAD//wA3PP9mzJkAZuXl5f7+/mZmywAA/v4A AJgAZoAAgEKZpv8A/y9PT/+lAOLi4re3t35+fpiYmMPDw8zMzAAAAAAAPwAAfwAAvwAA/wA/ AAA/PwA/fwA/vwA//wB/AAB/PwB/fwB/vwB//wC/AAC/PwC/fwC/vwC//wD/AAD/PwD/fwD/ vwD//z8AAD8APz8Afz8Avz8A/z8/AD8/Pz8/fz8/vz8//z9/AD9/Pz9/fz9/vz9//z+/AD+/ Pz+/fz+/vz+//z//AD//Pz//fz//vz///38AAH8AP38Af38Av38A/38/AH8/P38/f38/v38/ /39/AH9/P39/f39/v39//3+/AH+/P3+/f3+/v3+//3//AH//P3//f3//v3///78AAL8AP78A f78Av78A/78/AL8/P78/f78/v78//79/AL9/P79/f79/v79//7+/AL+/P7+/f7+/v7+//7// AL//P7//f7//v7////8AAP8AP/8Af/8Av/8A//8/AP8/P/8/f/8/v/8///9/AP9/P/9/f/9/ v/9///+/AP+/P/+/f/+/v/+/////AP//P///f///v////wAAABERESIiIjMzM0RERFVVVWZm Znd3d4iIiJmZmaqqqru7u8zMzN3d3e7u7v////8A//8A//8A//8A//8A//8A/3Kf/8TX/z5X jGGH2QB/AAB/fwB//wD/f38AAH8Af38A/yH5BAAAAAAALAAAAADXAQcBAAj+AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4cdsAjiNLTgl5suXL HgNoxsy5c0XNlT2LHq0QNOnTqAWC3py6defVoV3Llgx7tm3HsFnf3n04d2zEv3mjDp6YuPDR xg2bPp46eeHlzE87Jww9OvLGta1fZ5xdO27fuhX+d/cOfOB08bnJFzfP2bf68qpFn3/vN/T8 xffp77UvXz919vF5lp9/cm1mIICvEQgYf/wJqGB9Bek24F/ghfdgXr9JiB+CF4I1YIUg2tfg egF26CFEEzLIYW8rmrhVdQulyN6I8AEwoYtOwViaRMvRyGKJOL5o4Y4W+ahci0FaNR6RnyG5 III3JpnUkglFSZCRFEJ2IJBSKrmaQ1ZCWSFfKnLZ5VTuMRSmmQatWVaGWJ4JVZoxkuSmTCHm qeeecDopZ1Qf2jllTH2y+SegKAqK1J0alWnjoVcFOhKjMFGKkaOWQrqTpCJl2pKnRbIWp6ZN cRoSqCuhmtGopC5lKkj+qlKGE6utAgViopMOepOI4NW66ZWrKnpUrBedR6yvlwKbbK6dlnRs s8jOqmyxwsLqbFHPRktRbIw+S6yOmWGr7Uw0dlttZkOGS1S248aopZbTFnluR+DSK267Ljn6 6LLQfkSlvevi+2mE3AbLrL9f9isUuwK3SXC8TR6Mbr0bMawujnxmrLHGVxbM76mwpgdywEFa TG18Hp+sMEd0+nsvxj/pa67ELs8bc5ImFysqxNvazPK1JMMc9L4qj2z0yrbi/DLR8tJ8MdI3 l7z0zFD/7HNPOVuWdaM8T+St0zUPtTVtU4/50Nermg22T2NH1nbRVeJaNZh+Ai220lK9Grb+ 13VfzdPb2KEp99E89r021ngjerbfaho+99+Jzzm4tREzrRLglbuI+eMOH04krZ7/KnXek+/d kIEaDjy0iZsTXmfondsIOuc6tU6i4nRPml+Gjrtu062j4366nekexLuhJtmOkPJkA7rx89Dz GWHvlP9O/YXMA5z7qQk3rtrsvhN6/YPZW70997ubB371Na2PveCL6x6Rae4/TVP9CpZfcen2 zz++9u37H4H0x7X40Y5JbSsf/gYIv/Oxr3DIs5v4SkTADZHOgOHbHvBgl7x3Ea2C4mng8DgY t9eRUFjwimDwJIfBB/bPdCwplOXkBEK4mTCDBTwhjzimPgH6p4b+TXMgDAGIQxuWsIcqFJrw vHfAIDaRbwZM4QzPBMTMMbGIH8OiFU0oxSoe6YJCfKH5ngjBs+0siZoT4RVdSEQ25hCKU+yS F2O3wRGSEY535F8U1ZbGl1FNi04EJB7LeMQ+Bu2Pbtwf4wLpvxuyzigLjJ0ge7bILbbxfX40 WB7nFz0eDnGMj8xkFj+pSB02cpLemeP00LhGUr4RlXospSHvxkpHulKTmwwjKDukymkh8paj BKYld4lJ9HUyT7VkEixPmUs7JpKBzbTjL8Uoy2Xqspq8NOUpp3lJYlIzmN6slMj2o025cTOc r3ymEdFZKSQqhWKVZKT5zonNbtoTnPX+JFfXIJmvckYRl+rEJzvlOdB+7nN1soomE+mZznvm E6ATO6ZE03W8d35Pdic51rd8uEqFtlKYlLRm8jqqK4wW75sQnWdKHSrQh7b0pQbl6K6g1KaJ tgykIa3jR1kKJj6KdKcubadMZ0rBkXp0ncuLJ1AlyFOC4smdFi0qU1Gq1DgWNKlDRSpMnfqS m5Y0koTEaUAPGlRlJvCnzgQO6t6VLY12NZZlLeRZx8rVH/ozrlld6g3nKtZBZvOodSUpXY1H 1qoys6/acWtM04pYDvGVqlq1K2CHidVmpixVaNWrfhSrumvilbB5pexW1eTTv2Y2soJtLJAe 29TK9lIwnL3+nE1nO9HC3lWzCCRVbDHbQtUyjbVXda1ub7vSyor0spf7KVjps9vk9hayxgXu Z0Fr1cj5tqGFHKwkpYtdDQ53siFlLHSpW13DwnWh3z1tYG072u0utrXUfW1gmptQz3b3ijrV 7mG3mV79jre8xcVtW5Ub2sQSt71o8yt5P0PbBiMzmeQ7MGrZO+H16jVWa1rue+iLEr39V8Fh lSR86djf6wZYxCbG7YUJDOH8SdjCLQ7xiI274ODGt8Qf/m+C/Vvj1E6XxJricEbPe+L2ZhfF P+6ofJ8E3tKUVpk8JrJ4KQxiDT45wk1WcpGNLOMuFxjJz/UxltUrXC57+b5h/rL+mJNsHSFr kqFbhjGUwRxn0UqWzDc2835n3GMqn7nO5HEzv+Cs5zSfF8Mvto2gVUboCtvZvojOcmsWHcRG y7nKh8Zzn10saZoW2tCAPvKaPz1lTmtay6QuNZohfepR3znK3k21ik/nSVUD+NGODrSDdx2i GNOZzc4V9apz3bCN+trVoY6hLYEN6oYhu9LJ/vNT58xs+zrbz2W0NK57mrFMw9ra1z62NKO9 Z+tRe9iXFpixbz3rbb/13ORudrjZndN4y1uowra3redNbzjmF97VHjLAiS3tea8735sOuFER TvBy81vNBYf4r/U58HQ7/OH9FuuOczKdSLf6T2/zMJ/+g01jG2P64SGXcsNJnvCV3/vaKX+5 u987cYurHObvBrfLO7xsdM+82Dnft6wZ5/FvRyvmOrd5fUuu8O/1CuNM57nMw8vxnttbwzin ecWHHrqiZxvqF5/q1ncucIYr/YNgv7l2Ny6tsZ+ci2mfuo6Jx+sGW/3TWHc20oUeFq/zN+58 n+SSpX7dvANd62YXi9/NCfjAX6rWEn/K4v/Z+Lubmy2Tj3XlE09xzLM441D34uAzWneJRh5Z FttYzf9TudHPRvTNq/fmOT9t3EB79lFvu+1bj/vcE3X3su/9szsfuNZfOfRJc1tgXe+gqAHf 6KhP/vNT7CvYK7/TNJR+8T/+nn3nbx/61dc+dxKN49rFHvy1sv70c4wv9X+f+ukXvwW5T0X5 hxD79ff++PEvR/vfDv2t4n77R3/9p3/zB4DlV3XXR4CPIXn+VyOP121fVCoP+COv5ioVOIHM dVJLAzkLuGGPwnynB392YSmqNxiVIYLYFnQDqB4paDylF4MyOIM0WIM2eEybJW4KKHyuAS8q yIO3AU9AOIQ/OIRBaIRI2HJJuIRM2IRO+IRQGIVSOIVUWIVWeIVYmIVauIVc2IVe+IVgGIZi OIZkWIZmeIZomIZquIZs2IZu+IZwGIdyOId0WId2eId4mId6uId82Id++IeAGIiCOIiEWIjt EhAAOw== --------------7465AEC098E7149C8EFFAB01 Content-Type: image/gif; name="2mux_latch.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="2mux_latch.gif" R0lGODlhdwCqAIAAAAAAAP///ywAAAAAdwCqAAAC/oyPqcvtD6OctNqLs968+w+GYgQAR3ma 48o6qPEGcUvT8Vuq9c6ieM4Ljnwq00yI3BARt5zzCY1Ko0nNMlXVVS1XmDb43VKAzPDOLCYd jzx0+kHGJt3vuoRuzzfw+j7TDwgXOLjAR2hnePiWqCjG2JgFSfgo6cGmQFnJYXQJoymkFXfy CVYYStq254N6BiHKOjTxCmvJ1Ul7kSmn94Sp66J0iwSVIJxr+QvyozOr9JH8zFzUbPVc1+Rp zGW9KF2WMhVOXNu9KwNdyJ2Gbd6B/ld+HvperO7Y+61sv4Wfv1+Naxu5gGP+ERQ08CAJgwoZ 0PPUhlqphC3G8ePWL9q0/nXWvjw0p61HtHQj24EqWQ/lOUcqwYkT52/lRWQkHVbAITMSTUzA bm5kWcsjwjEW52B04ioXkJCxKN5xNxOqQFYfdX3UKfUmrarHYHGdiuqrVq8Mh4Yt2/Pey3Bo 9ywCmLUgxwxi5QLFUFfWW7o7x97tSpdpzaiAbW3ai9fWw6uFwcIR/HRu4seMR0luXKZyyr+O vaS6DFZiU85aRYsE7RP1sK2Iz6qupNmua9JzfsXWy28V5tXDZthuXePS79chJA6nrTHp7pMi TMPrzBtZpuOErSSjjhUv5MGys6eO293oZPC4kS90Gtm8cvLpq4cPvJYK8fWHZ0Mf/+l620l8 /tFD0u9fIwCy919/BApoYH2kDKhgfncgJcN+gxgiVF6w0WdSgprwYcZ2aeW3likSUiVigAF1 aGFDFY7oFYQpNsQdXDB+6MyMZtVoo1sm5vhijhAd6GOPwbzi3GlSZQRfHEhOBJVQwXjBiWfe WRfjdyv94F5gVRLVjoc7culLfP2wI+WUWvJEZZlFrlBVh09KuSabHW12JhleKrMYlHcWg09R taET25hLZsGgj654eFtYgiXaIoeGVmPcowkKJyl+UD5X6XuXMkrWY5ne9ymOobI4anulNniq qKnKuKqGrS73anmxwnqGN/IgeA8Wg/bBqQvSYHlIr75e+RN/60QZIlMgYi4boq7zzOppE8Ju hWycryo57YnLWJuqnbtCC24NBQAAOw== --------------7465AEC098E7149C8EFFAB01-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 17 02:44:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5d-00080b-01 for ; Sun, 17 Feb 2002 04:34:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:13 +0100 (CET) Received: (qmail 15312 invoked by uid 0); 17 Feb 2002 01:39:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 17 Feb 2002 01:39:33 -0000 Received: by moria.seul.org (Postfix) id 08845146845; Sat, 16 Feb 2002 20:39:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01BE91468E1; Sat, 16 Feb 2002 20:39:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 9DB7E146845 for ; Sat, 16 Feb 2002 20:39:31 -0500 (EST) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 2345C16A1 for ; Sun, 17 Feb 2002 02:39:28 +0100 (CET) Message-ID: <3C6F0AF6.C0CD8C6A@f-cpu.org> Date: Sun, 17 Feb 2002 02:44:22 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <20020214200612.44670@thrai.stud.uni-hannover.de> <3C6C6906.925E389F@f-cpu.org> <20020215121505.37724@thrai.stud.uni-hannover.de> <3C6DD197.832801BD@f-cpu.org> <20020216143213.64156@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > > On Sat, Feb 16, 2002 at 04:27:19AM +0100, Yann Guidon wrote: > [...] > > there are "shadow flags" which indicate whether a register is zero or > > not. This is one of the hottest/nastiest things in the register set "entity". > > in the 64-bit implementation, it takes 5 bits, one bit per "slice" > > (there are 2*8 bit slices and 3*16-bit slices). the bits are updated > > depending on the write mask, it is read on every cycle so we know > > whether a condition is true or false : it is a 2W1R bank. > > Yep, I remember. > > The shadow flags are used when we have to check an operand for zero-ness, > i.e. the scheduler will read it when it encounters a CJUMP, CMOVE or DIV > instruction. If the register's value is being calculated at that time, > the scheduler has to wait until the result is ready. Bypassing the > register write isn't possible because it's not yet clear whether the > next instruction is executed at all -- the condition may be false, > or there might be a division-by-zero exception. it is not exactly this way but rather close. just like the register set, the flags are speculatively read, accessed by any instruction. The opcode decoding (performed in parallel) will tell to the next stage (decode) whether the flag is useful or not. The bypass (which is one worrying part) for the z-flag has to provide the issue logic with the value of all the slices' values and OR them. The slice values have to be selected, so a MUX is necessary. > > The problem arises when there is a buble in the pipeline, which stalls > > waiting for a result which conditions the issue of the currently decoded > > instruction. During the R7 writeback cycle, the bits in a slice are ORed > > together and sent to the 2W1R bank of 5*63 bits (each of the 5 bits are > > conditionned by the write mask). The 1R output of the 5-bit vector is ORed > > and gives the needed bit. If we use a transparent latch, the flow-through > > time of the cell uses one gate delay. > > I'd love to see a timing diagram. i'll start with a structural diagram so we are sure that everybody speaks about the same thing. > > Otherwise, using a FF, there is the need to create a bypass path : > > it introduces a MUX for each of the 5 bits because we have to choose > > which of the old or new flag is read, depending on the write mask > > and other flags. Although you might not like it, using a transparent latch > > is an elegant solution and compromise. Using synchronous logic increases > > the complexity of the logic and my brain has limited computational power :-( > > IMHO, it's just the opposite: a mix of FFs and latches will increase > the complexity. why ? it is bound to the decode/issue logic stages, where the execution pipeline is synchronised with the instruction flow. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 17 02:44:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cI5e-00080b-00 for ; Sun, 17 Feb 2002 04:34:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 04:34:14 +0100 (CET) Received: (qmail 32645 invoked by uid 0); 17 Feb 2002 01:39:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 17 Feb 2002 01:39:41 -0000 Received: by moria.seul.org (Postfix) id D72F61468DF; Sat, 16 Feb 2002 20:39:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0C471468E2; Sat, 16 Feb 2002 20:39:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 74A2C1468DF for ; Sat, 16 Feb 2002 20:39:40 -0500 (EST) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id C3EE0168C for ; Sun, 17 Feb 2002 02:39:37 +0100 (CET) Message-ID: <3C6F0AFF.F243802E@f-cpu.org> Date: Sun, 17 Feb 2002 02:44:31 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) References: <3C6ECE9A.6B925917@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! so here goes the Science Fiction again :-DDD I respect you all but sometimes, you look more like children than me :-P Ben Franchuk wrote: > Juergen Goeritz wrote: > > Other example: imagine a 500 processor cluster in an orbit > > around Jupiter at high rad doses (I love these examples :) hmmm i didn't know Jupiter was made of uranium/plutonium... > > 1/2 of your cluster sleeps to recover from radiation, the > > other half is operating. Before sleep you test, after sleep > > you test and during operation you test at regular intervals. hey ! in my example i did not mean a multi-cpu system. In this case, of course you wouldn't forward the hard reset signal to all the other cpus. i guess it was discussed (is it the word ?...) months ago... by the way, how do you want to verify the system's integrity without reset ? Because its seems obvious to me that the BIST will erase the memory it wants to test : you will loose all the program's current state. > Nah... I would have the 500 cluster in orbit around the sun > running a anti-matter production plant using solar energy. Pffff... btw, it remembers me a talk that was recently given in my university : they want to send clusters of micro-satellites in space, in gravitational-neutral "holes" that would allow the stuff to stay there without propulsion. I have no idea what the goal is. it looks completely dumb to me, very expensive, useless and unrepairable. ask the NASA's JPL for details. at least, sending people to the moon made more sense to me. > Anti-matter > takes a hell a lot of energy to produce but could make inter-planetary > travel possible. The problem is that transistor size of modern logic is > it too small to not glitch or fry from radiation. A machine with a 250 ns > memory cycle and 1 Meg of ram could be a practical size and speed limit > for hard radiation. While I have not looked a 'Leon' I would expect to have > error checking of some kind in the alu and memory circuits. That was one > advantage the old decimal machines had, error checking codes.A parity bit > may be a good feature to consider with transistor sizes getting smaller > and the mean time between soft errors goes down. >From the leon website, the radiation tests were satisfying. they use specific hardened cells as well as a self-recovering architecture but i did not care. have a look ! > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Feb 17 04:21:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cJWv-0000VE-00 for ; Sun, 17 Feb 2002 06:06:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Feb 2002 06:06:29 +0100 (CET) Received: (qmail 18733 invoked by uid 0); 17 Feb 2002 03:19:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 17 Feb 2002 03:19:33 -0000 Received: by moria.seul.org (Postfix) id 9B18A146846; Sat, 16 Feb 2002 22:19:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 95C1A1468E1; Sat, 16 Feb 2002 22:19:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id E473B146846 for ; Sat, 16 Feb 2002 22:19:31 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-216.jetnet.ab.ca [207.34.60.216] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id UAA03238 for ; Sat, 16 Feb 2002 20:19:29 -0700 (MST) Message-ID: <3C6F21AA.A64441CA@jetnet.ab.ca> Date: Sat, 16 Feb 2002 20:21:14 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) References: <3C6ECE9A.6B925917@jetnet.ab.ca> <3C6F0AFF.F243802E@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > so here goes the Science Fiction again :-DDD > I respect you all but sometimes, you look more > like children than me :-P Check here and... http://www.fnal.gov/pub/ferminews/ferminews02-01-02/p1.html http://www.synergistictech.com/projects.html http://www.engr.psu.edu/antimatter/ Now back to our scheduled program. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Feb 17 11:50:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0H-0000G4-00 for ; Mon, 18 Feb 2002 00:45:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:45:57 +0100 (CET) Received: (qmail 31094 invoked by uid 0); 17 Feb 2002 10:48:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 17 Feb 2002 10:48:07 -0000 Received: by moria.seul.org (Postfix) id 240091468E1; Sun, 17 Feb 2002 05:48:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E8FB1468E3; Sun, 17 Feb 2002 05:48:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (stu1ir200-100-149.ras.tesion.net [195.226.100.149]) by moria.seul.org (Postfix) with ESMTP id DA9B41468E1 for ; Sun, 17 Feb 2002 05:48:02 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16cOtV-0007c7-00 for f-cpu@seul.org; Sun, 17 Feb 2002 11:50:09 +0100 Date: Sun, 17 Feb 2002 11:50:09 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: test (was: [f-cpu] No latches, please !) In-Reply-To: <3C6ECE9A.6B925917@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 16 Feb 2002, Ben Franchuk wrote: > Juergen Goeritz wrote: > > > Other example: imagine a 500 processor cluster in an orbit > > around Jupiter at high rad doses (I love these examples :) > > 1/2 of your cluster sleeps to recover from radiation, the > > other half is operating. Before sleep you test, after sleep > > you test and during operation you test at regular intervals. > > Nah... I would have the 500 cluster in orbit around the sun > running a anti-matter production plant using solar energy. Anti-matter > takes a hell a lot of energy to produce but could make inter-planetary > travel possible. Why do you think it may be possible to produce anti-matter? Hasn't there been detected an asymmetry in favour of matter lately? > The problem is that transistor size of modern logic is > it too small to not glitch or fry from radiation. A machine with a 250 > ns > memory cycle and 1 Meg of ram could be a practical size and speed limit > for hard radiation. While I have not looked a 'Leon' I would expect to > have > error checking of some kind in the alu and memory circuits. That was one > advantage the old decimal machines had, error checking codes.A parity > bit > may be a good feature to consider with transistor sizes getting smaller > and the mean time between soft errors goes down. Yes, but one has to distinct between the size and energy levels of the parts hitting the device. It was pretty much analyzed by some ESA (and probably NASA) activities. Around the earth this effect is not the real big problem. But near the sun or jupiter it will be a problem. Think there was an article stating some of the defects caused to the sonde currently circling around jupiter which also took interesting pictures about vulcanism on the moons. One effect in the transistor is the buildup of a load in the substrate layers that may damage the transistor. Think this is caused by gammaray in combination with electric fields and is building up constantly. When you remove the electrical field the load slowly decreases again. But since I do not want to crawl through the pile of documents again I have no figures. Alpha & Beta radiation may be better shielded by other means since they can really blow your chip structure. But maybe one of the guys working directly at ASIC centers could tell me whether it is possible to control the power branches in SoC designs to really shut-down parts of it directly onchip. And I mean a completely powerless state not the usual idle power-down mode used to save power. AND if it is possible to intermix coarse transistors from 1.3u or even heavier ones with the latest 0.08u techniques on a single chip. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bombe@informatik.tu-muenchen.de Sun Feb 17 16:27:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0H-0000G4-01 for ; Mon, 18 Feb 2002 00:45:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:45:57 +0100 (CET) Received: (qmail 2183 invoked by uid 0); 17 Feb 2002 15:29:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 17 Feb 2002 15:29:43 -0000 Received: by moria.seul.org (Postfix) id 708661468E4; Sun, 17 Feb 2002 10:29:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 416DE1468E8; Sun, 17 Feb 2002 10:29:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.netsurf.de (mehlwurm.netsurf.de [194.195.64.32]) by moria.seul.org (Postfix) with ESMTP id 76F2A1468E4 for ; Sun, 17 Feb 2002 10:29:41 -0500 (EST) Received: from storm.local ([195.179.191.204]) by mail.netsurf.de (Netscape Messaging Server 4.1) with ESMTP id GROOBP00.9PO for ; Sun, 17 Feb 2002 16:28:37 +0100 Received: from andreasb by storm.local with local (Exim 3.34 #1 (Debian)) id 16cTDU-0000en-00 for ; Sun, 17 Feb 2002 16:27:04 +0100 Date: Sun, 17 Feb 2002 16:27:04 +0100 From: Andreas Bombe To: f-cpu@seul.org Subject: [f-cpu] [OT] Re: test (was: No latches, please !) Message-ID: <20020217152703.GA2432@storm.local> References: <3C6ECE9A.6B925917@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok, this is offtopic, but... On Sun, Feb 17, 2002 at 11:50:09AM +0100, Juergen Goeritz wrote: > On Sat, 16 Feb 2002, Ben Franchuk wrote: > > > Juergen Goeritz wrote: > > > > > Other example: imagine a 500 processor cluster in an orbit > > > around Jupiter at high rad doses (I love these examples :) > > > 1/2 of your cluster sleeps to recover from radiation, the > > > other half is operating. Before sleep you test, after sleep > > > you test and during operation you test at regular intervals. > > > > Nah... I would have the 500 cluster in orbit around the sun > > running a anti-matter production plant using solar energy. Anti-matter > > takes a hell a lot of energy to produce but could make inter-planetary > > travel possible. > > Why do you think it may be possible to produce anti-matter? Hm? Antimatter is coming down as cosmic radiation, the sun produces antineutrinos in every single nuclear fusion and scientists produce them in particle accelerators for many decades now. The only problem is that takes a lot of energy to create, but it's a very high density energy storage and very useful if you can't stop for a refuel somewhere (starships...). > Hasn't there been detected an asymmetry in favour of matter > lately? I'm not sure about what was detected exactly, but an asymmetry was long suspected and is about the most probable event to explain why there is matter in the universe at all. The asymmetry is something like 1:1000000 (or I may remember wrong) so that in every millionth case matter is produced instead of matter/antimatter. So in the early universe radiation turned into matter/antimatter with a slight advantage for matter. 99.9999% os the mass turned back into radiation when colliding with their anti-parts, the rest is what fills the universe today. -- Andreas Bombe DSA key 0x04880A44 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Feb 17 17:37:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0I-0000G4-00 for ; Mon, 18 Feb 2002 00:45:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:45:58 +0100 (CET) Received: (qmail 11819 invoked by uid 0); 17 Feb 2002 16:35:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 17 Feb 2002 16:35:52 -0000 Received: by moria.seul.org (Postfix) id A59BF1468E5; Sun, 17 Feb 2002 11:35:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E4341468E9; Sun, 17 Feb 2002 11:35:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id CAF7B1468E5 for ; Sun, 17 Feb 2002 11:35:50 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-193.jetnet.ab.ca [207.34.60.193]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA14536 for ; Sun, 17 Feb 2002 09:35:49 -0700 (MST) Message-ID: <3C6FDC49.B887B3D0@jetnet.ab.ca> Date: Sun, 17 Feb 2002 09:37:29 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Re:Cmos fab. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Why do you think it may be possible to produce anti-matter? > Hasn't there been detected an asymmetry in favour of matter > lately? *** Off topic *** Been done for the anti-electron since the 1930's. The anti-electron from the 1970's. With a efficiency of something like 10^-9 and m=e/(c^2) and the stuff going 'poof' if hits ordinary matter your yearly production is small. It may soon have some real use of production of radioactive isotopes for things like cat-scans where you can produce short lived radioactive materials on site. *** On Topic *** > One effect in the transistor is the buildup of a load in the > substrate layers that may damage the transistor. Think this is > caused by gammaray in combination with electric fields and is > building up constantly. When you remove the electrical field > the load slowly decreases again. But since I do not want to > crawl through the pile of documents again I have no figures. > Alpha & Beta radiation may be better shielded by other means > since they can really blow your chip structure. I think they have been doing that since 16K dram came out.They changed from ceramic to plastic because the natural radioactivity of the clay was too high back then. > But maybe one of the guys working directly at ASIC centers > could tell me whether it is possible to control the power > branches in SoC designs to really shut-down parts of it > directly onchip. And I mean a completely powerless state > not the usual idle power-down mode used to save power. I think you might if you used a Bi-Cmos fabrication. I am not sure if you could turn off CMOS that has latched up that way? > AND if it is possible to intermix coarse transistors from > 1.3u or even heavier ones with the latest 0.08u techniques > on a single chip. Yes you can use BIGGER transistors! The catch is the poly-silicon and other metallic layers may have changed thickness as well as the transistor gains so you may have to check if the old design still works. ---- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Feb 17 18:27:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0J-0000G4-00 for ; Mon, 18 Feb 2002 00:45:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:45:59 +0100 (CET) Received: (qmail 22656 invoked by uid 0); 17 Feb 2002 17:25:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 17 Feb 2002 17:25:27 -0000 Received: by moria.seul.org (Postfix) id 77B6D1468EB; Sun, 17 Feb 2002 12:25:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F4701468EA; Sun, 17 Feb 2002 12:25:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id AC59C1468E8 for ; Sun, 17 Feb 2002 12:25:24 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-193.jetnet.ab.ca [207.34.60.193]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA16398 for ; Sun, 17 Feb 2002 10:25:23 -0700 (MST) Message-ID: <3C6FE7E8.33CEBDB@jetnet.ab.ca> Date: Sun, 17 Feb 2002 10:27:04 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re:Cmos fab. References: <3C6FDC49.B887B3D0@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk wrote: > *** Off topic *** > Been done for the anti-electron since the 1930's. > The anti-electron from the 1970's. With a efficiency of err anti-proton from the 1970's Also I assume the F-CPU is going to be a CMOS design as it is too large for other technologies like ECL. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Feb 17 17:16:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0K-0000G4-01 for ; Mon, 18 Feb 2002 00:46:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:46:00 +0100 (CET) Received: (qmail 19996 invoked by uid 0); 17 Feb 2002 20:45:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 17 Feb 2002 20:45:46 -0000 Received: by moria.seul.org (Postfix) id C90C514684B; Sun, 17 Feb 2002 15:45:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD25D1468EA; Sun, 17 Feb 2002 15:45:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a241.home.uni-hannover.de [130.75.232.241]) by moria.seul.org (Postfix) with ESMTP id 4DA6A14684B for ; Sun, 17 Feb 2002 15:45:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00930; Sun, 17 Feb 2002 17:16:09 +0100 Message-ID: <20020217171608.60013@thrai.stud.uni-hannover.de> Date: Sun, 17 Feb 2002 17:16:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] No antimatter, please References: <3C6ECE9A.6B925917@jetnet.ab.ca> <20020217152703.GA2432@storm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020217152703.GA2432@storm.local>; from Andreas Bombe on Sun, Feb 17, 2002 at 04:27:04PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Can you please leave outer space now and return to earth? There's plenty of F-CPU matter to deal with down here. On Sun, Feb 17, 2002 at 04:27:04PM +0100, Andreas Bombe wrote: > Ok, this is offtopic, but... Worauf Du einen lassen kannst... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Feb 17 23:19:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0O-0000G4-00 for ; Mon, 18 Feb 2002 00:46:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:46:04 +0100 (CET) Received: (qmail 26356 invoked by uid 0); 17 Feb 2002 22:14:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 17 Feb 2002 22:14:20 -0000 Received: by moria.seul.org (Postfix) id BA35714684C; Sun, 17 Feb 2002 17:14:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B66461468E9; Sun, 17 Feb 2002 17:14:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 715D414684C for ; Sun, 17 Feb 2002 17:14:18 -0500 (EST) Received: from f-cpu.org (kdl21-157.n.club-internet.fr [213.44.96.157]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 4AAE71686 for ; Sun, 17 Feb 2002 23:14:15 +0100 (CET) Message-ID: <3C702C5E.74A5B2C0@f-cpu.org> Date: Sun, 17 Feb 2002 23:19:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] new manual version Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Cedric has recently made a new version of the F-CPU manual rev. 0.2.3, seeing that Olivier was really, really slow. There is only the english version currently. And a lot of work is still required ! but it's better than nothing. You'll find the archive at http://f-cpu.seul.org/new under the name F-CPU_manual-0.2.4-en.tgz (i have not yet reviewed it) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 18 00:20:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cb0O-0000G4-01 for ; Mon, 18 Feb 2002 00:46:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 00:46:04 +0100 (CET) Received: (qmail 6662 invoked by uid 0); 17 Feb 2002 23:15:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 17 Feb 2002 23:15:35 -0000 Received: by moria.seul.org (Postfix) id 1424B1468ED; Sun, 17 Feb 2002 18:15:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D6B61468EF; Sun, 17 Feb 2002 18:15:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id C2DBF1468ED for ; Sun, 17 Feb 2002 18:15:32 -0500 (EST) Received: from f-cpu.org (kdl16-36.n.club-internet.fr [213.44.18.36]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 204D6169A for ; Mon, 18 Feb 2002 00:15:30 +0100 (CET) Message-ID: <3C703AB8.8648EC71@f-cpu.org> Date: Mon, 18 Feb 2002 00:20:24 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re:Cmos fab. References: <3C6FDC49.B887B3D0@jetnet.ab.ca> <3C6FE7E8.33CEBDB@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Ben Franchuk wrote: > > *** Off topic *** > Also I assume the F-CPU is going to be a CMOS design as it is > too large for other technologies like ECL. I only assume that Boole's laws are valid. It is up to the implementor to decide what technology to use. And frankly i don't see how one could prevent the use of any technology, when VHDL is correctly written and synthesised. > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Feb 18 07:20:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ccCr-0001PP-00 for ; Mon, 18 Feb 2002 02:03:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 02:03:01 +0100 (CET) Received: (qmail 28594 invoked by uid 0); 18 Feb 2002 00:14:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 18 Feb 2002 00:14:28 -0000 Received: by moria.seul.org (Postfix) id 08D3814684F; Sun, 17 Feb 2002 19:14:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 02EEC146856; Sun, 17 Feb 2002 19:14:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9CD1D14684F for ; Sun, 17 Feb 2002 19:14:21 -0500 (EST) Received: from ifrance.com (unknown [194.158.119.177]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B5014169F for ; Mon, 18 Feb 2002 01:14:17 +0100 (CET) Message-ID: <3C709D20.560366E8@ifrance.com> Date: Mon, 18 Feb 2002 01:20:16 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202151558.0b12@th00.opsion.fr> <20020215235815.55103@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N SRAM cells are quite an analog things, bit are coded by differential mlogique around 300 mv to detect one or zero. That's why i said it's very different of latch. There are sense amplifier, decoding... nicO Michael Riepe a écrit : > > On Fri, Feb 15, 2002 at 03:58:11PM +0000, nicolas.boulay@ifrance.com wrote: > [...] > > >>>For large memory SRAM are much better !! > > An SRAM cell is a kind of latch, essentially. > At least that's true for the ones I know. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Feb 18 07:37:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ccCr-0001PP-01 for ; Mon, 18 Feb 2002 02:03:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 02:03:01 +0100 (CET) Received: (qmail 2809 invoked by uid 0); 18 Feb 2002 00:31:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Feb 2002 00:31:22 -0000 Received: by moria.seul.org (Postfix) id 01682146852; Sun, 17 Feb 2002 19:31:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B68D71468EE; Sun, 17 Feb 2002 19:31:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 57863146852 for ; Sun, 17 Feb 2002 19:31:20 -0500 (EST) Received: from ifrance.com (unknown [194.158.119.177]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 568321694 for ; Mon, 18 Feb 2002 01:31:18 +0100 (CET) Message-ID: <3C70A11C.71274290@ifrance.com> Date: Mon, 18 Feb 2002 01:37:16 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <3C6C58C9.CAF60299@ifrance.com> <3C6C7747.7E486379@ifrance.com> <3C6EFD1C.BCDDD237@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nicO wrote: > > > > Some example : > > http://www.cse.psu.edu/~cg577/hw1s98.html > > i have looked and i was surprised by the first drawing > (first attachment) : there is no feedback loop that memorizes > the data :-/ is it precharged logic ? :-( > Of course not ! You just discover the difference between a flipflop and rs bascule. nicO > The last one (IBM Power) looks more classical > but i am surprised by the input buffer(s) at > the source/drain and not the gate of the transistors. > > And in the last attachment, i have drawn a transparent > latch with two inputs with the nice side effect that > there is no oscillation if both write signals > are set at the same time :-D > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ------------------------------------------------------------------------ > [Image] [Image] ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 18 02:18:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cf8L-0003XI-01 for ; Mon, 18 Feb 2002 05:10:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 05:10:33 +0100 (CET) Received: (qmail 18444 invoked by uid 0); 18 Feb 2002 01:13:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 18 Feb 2002 01:13:15 -0000 Received: by moria.seul.org (Postfix) id 522C71468EF; Sun, 17 Feb 2002 20:13:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DD221468F1; Sun, 17 Feb 2002 20:13:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id B4EBF1468EF for ; Sun, 17 Feb 2002 20:13:12 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3B6AB1689 for ; Mon, 18 Feb 2002 02:13:09 +0100 (CET) Message-ID: <3C70564C.2F74D725@f-cpu.org> Date: Mon, 18 Feb 2002 02:18:04 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202141011.3a23@th00.opsion.fr> <3C6BF1D0.9EF8DC74@jetnet.ab.ca> <3C6C58C9.CAF60299@ifrance.com> <3C6C7747.7E486379@ifrance.com> <3C6EFD1C.BCDDD237@f-cpu.org> <3C70A11C.71274290@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > Yann Guidon a écrit : > > nicO wrote: > > > Some example : > > > http://www.cse.psu.edu/~cg577/hw1s98.html > > > > i have looked and i was surprised by the first drawing > > (first attachment) : there is no feedback loop that memorizes > > the data :-/ is it precharged logic ? :-( > > Of course not ! > > You just discover the difference between a flipflop and rs bascule. ???????????????????????? both flip flop and latches (modified R/S) have a storage element, usually in the form of at least two inverting cells that are tied together. A set-reset is just a form of a modified dual-inverter memory loop, where it is possible to change the state of the memorised bit (without using driver strength tricks). A "transparent latch" is a modified RS with some control logic. A FF is a set of 2 chained Transparent Latches with opposite clock sensitivity. unless people lied to me "à l'insu de mon plein gré" ? Now, if the latching cell has no "feedback loop", and it is not precharged, i wonder how it can memorize any data... maybe using the gate's capacitance ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 18 02:18:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cf8M-0003XI-00 for ; Mon, 18 Feb 2002 05:10:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 05:10:34 +0100 (CET) Received: (qmail 18444 invoked by uid 0); 18 Feb 2002 01:13:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 18 Feb 2002 01:13:17 -0000 Received: by moria.seul.org (Postfix) id 3C6B41468F1; Sun, 17 Feb 2002 20:13:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1ED4F1468F4; Sun, 17 Feb 2002 20:13:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7F5EE1468F1 for ; Sun, 17 Feb 2002 20:13:13 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-3v.club-internet.fr (Postfix) with ESMTP id CE41D1692 for ; Mon, 18 Feb 2002 02:13:08 +0100 (CET) Message-ID: <3C70564D.C96E4181@f-cpu.org> Date: Mon, 18 Feb 2002 02:18:05 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202151558.0b12@th00.opsion.fr> <20020215235815.55103@thrai.stud.uni-hannover.de> <3C709D20.560366E8@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nicO wrote: > SRAM cells are quite an analog things, bit are coded by differential > mlogique around 300 mv to detect one or zero. That's why i said it's > very different of latch. There are sense amplifier, decoding... hmmm it sounds logical at first sight but i am not sure now : the main difference between a "transparent latch" and a "flip-flop" is the timing (or the clocking from another point of view). >From your description above, i don't see that. The function does not change when implemented differently. Whether you need a sensor or not has nothing to do with clocking. Can you elaborate ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Feb 18 02:21:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cf8M-0003XI-01 for ; Mon, 18 Feb 2002 05:10:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 05:10:34 +0100 (CET) Received: (qmail 13085 invoked by uid 0); 18 Feb 2002 01:20:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 18 Feb 2002 01:20:09 -0000 Received: by moria.seul.org (Postfix) id 5D84B1468F0; Sun, 17 Feb 2002 20:20:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 525801468F4; Sun, 17 Feb 2002 20:20:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 9597C1468F0 for ; Sun, 17 Feb 2002 20:20:07 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-219.jetnet.ab.ca [207.34.60.219] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA04436 for ; Sun, 17 Feb 2002 18:20:06 -0700 (MST) Message-ID: <3C70572A.818862BB@jetnet.ab.ca> Date: Sun, 17 Feb 2002 18:21:46 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > hello, > > Cedric has recently made a new version of the F-CPU manual rev. 0.2.3, > seeing that Olivier was really, really slow. There is only the > english version currently. And a lot of work is still required ! > but it's better than nothing. You'll find the archive at > http://f-cpu.seul.org/new under the name F-CPU_manual-0.2.4-en.tgz > (i have not yet reviewed it) > > WHYGEE It looks good. Now that I have docs to read; Is the logic function decoding for the ROP2 fixed at this time. It looked messy to me so I have what may be cleaner version. FABN LLLL A and B LLLH A nand B LLHL A and ~B LLHH A nand ~B LHLL ~A and B LHLH ~A nand B LHHL ~A and ~B LHHH ~A nand ~B HHLL 0 xnor 0 (1) HLLH 0 xor 0 (0) HLHL 0 xnor B ~B HLHH 0 xor B B HHLL A xnor 0 A HHLH A xor 0 B HHHL A xnor B HHHH A xor B TempA = InA * A + /InA * /A * /F ; pre process bit A TempB = InB * B + /InB * /B * /F ; pre process bit B TempC = / TempA * / TempB * F + TempA * TempB ; xnor , and selection Out = TempC xor N ; Negate output if needed -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Feb 18 09:56:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16cmSw-0000RO-00 for ; Mon, 18 Feb 2002 13:00:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 13:00:18 +0100 (CET) Received: (qmail 555 invoked by uid 0); 18 Feb 2002 08:56:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 18 Feb 2002 08:56:57 -0000 Received: by moria.seul.org (Postfix) id 107AA146858; Mon, 18 Feb 2002 03:56:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 067311468F4; Mon, 18 Feb 2002 03:56:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 5B213146858 for ; Mon, 18 Feb 2002 03:56:55 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Mon, 18 Feb 2002 08:56:40 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2002 08:56:40 GMT Message-id: <200202180856.286b@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 18/02/02 Objet: Re: Rep:Re: Re: [f-cpu] No latches, please ! hi, nicO wrote: > Yann Guidon a =E9crit : > > nicO wrote: > > > Some example : > > > http://www.cse.psu.edu/~cg577/hw1s98.html > > > > i have looked and i was surprised by the first drawing > > (first attachment) : there is no feedback loop that memorizes > > the data :-/ is it precharged logic ? :-( >=20 > Of course not ! >=20 > You just discover the difference between a flipflop and rs bascule. ???????????????????????? both flip flop and latches (modified R/S) have a storage element, usually in the form of at least two inverting cells that are=20 tied together. A set-reset is just a form of a modified dual-inverter memory loop, where it is possible to change the state of the memorised bit (without using driver strength tricks). A "transparent latch" is a modified RS with some control logic. A FF is a set of 2 chained Transparent Latches with opposite clock sensitivity. unless people lied to me "=E0 l'insu de mon plein gr=E9" ? >>>> BIP ! Nop ! That's the common mistake. An rs bascule is composed by 2 latches with the second used inversed clock. A fliflop use a pulse generator to trigger a single latch (so it's transparent only few times, that's create the setup and hold time, that's why IBM prohibite flipflop). Beside this 2 idea you could change a little bit by adding storage element as SRAM cell (wich could be used instead of the loop). nicO Now, if the latching cell has no "feedback loop", and it is not precharged, i wonder how it can memorize any data... maybe using the gate's capacitance ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 18 01:06:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16coT7-0001wz-00 for ; Mon, 18 Feb 2002 15:08:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 15:08:37 +0100 (CET) Received: (qmail 19630 invoked by uid 0); 18 Feb 2002 10:52:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 18 Feb 2002 10:52:57 -0000 Received: by moria.seul.org (Postfix) id 63EAE1468F4; Mon, 18 Feb 2002 05:52:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45AC21468F6; Mon, 18 Feb 2002 05:52:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a038.home.uni-hannover.de [130.75.232.38]) by moria.seul.org (Postfix) with ESMTP id B328C1468F4 for ; Mon, 18 Feb 2002 05:52:54 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02470; Mon, 18 Feb 2002 01:06:26 +0100 Message-ID: <20020218010626.32347@thrai.stud.uni-hannover.de> Date: Mon, 18 Feb 2002 01:06:26 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C702C5E.74A5B2C0@f-cpu.org>; from Yann Guidon on Sun, Feb 17, 2002 at 11:19:10PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Feb 17, 2002 at 11:19:10PM +0100, Yann Guidon wrote: > Cedric has recently made a new version of the F-CPU manual rev. 0.2.3, > seeing that Olivier was really, really slow. There is only the > english version currently. And a lot of work is still required ! Great news anyway :) Merci Cedric. > but it's better than nothing. You'll find the archive at > http://f-cpu.seul.org/new under the name F-CPU_manual-0.2.4-en.tgz > (i have not yet reviewed it) Maybe I'll find an hour or two this week... when the CeBIT issues are done. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 18 12:43:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16coTB-0001wz-00 for ; Mon, 18 Feb 2002 15:08:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 15:08:41 +0100 (CET) Received: (qmail 10672 invoked by uid 0); 18 Feb 2002 11:38:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 18 Feb 2002 11:38:52 -0000 Received: by moria.seul.org (Postfix) id E46271468F6; Mon, 18 Feb 2002 06:38:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D56D31468FA; Mon, 18 Feb 2002 06:38:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 661D81468F6 for ; Mon, 18 Feb 2002 06:38:49 -0500 (EST) Received: from f-cpu.org (kdl21-155.n.club-internet.fr [213.44.96.155]) by relay-4v.club-internet.fr (Postfix) with ESMTP id DAFF916BC for ; Mon, 18 Feb 2002 12:38:46 +0100 (CET) Message-ID: <3C70E8ED.3229C7A6@f-cpu.org> Date: Mon, 18 Feb 2002 12:43:41 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> <3C70572A.818862BB@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Ben Franchuk wrote: > It looks good. Now that I have docs to read; remark : it is the same as the version from 1 year ago ! the files have been moved around etc. but there is not change in the contents. > Is the logic function decoding for the ROP2 fixed at this time. it is not "fixed" because you can change it in f-cpu_config.vhdl and it is synthesized automatically. > It looked messy to me so I have what may be cleaner version. > > FABN > LLLL A and B > LLLH A nand B > LLHL A and ~B > LLHH A nand ~B > LHLL ~A and B > LHLH ~A nand B > LHHL ~A and ~B > LHHH ~A nand ~B > HHLL 0 xnor 0 (1) > HLLH 0 xor 0 (0) > HLHL 0 xnor B ~B > HLHH 0 xor B B > HHLL A xnor 0 A > HHLH A xor 0 B > HHHL A xnor B > HHHH A xor B > > TempA = InA * A > + /InA * /A * /F ; pre process bit A > > TempB = InB * B > + /InB * /B * /F ; pre process bit B > > TempC = / TempA * / TempB * F > + TempA * TempB ; xnor , and selection > > Out = TempC xor N ; Negate output if needed ??? in the most recent version, i simply use a 4-input MUX :-) the "logic" transformation is performed by a LUT during the decoding or Xbar cycle. look at the "stable" source code. > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 18 12:43:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16coTB-0001wz-01 for ; Mon, 18 Feb 2002 15:08:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Feb 2002 15:08:41 +0100 (CET) Received: (qmail 1176 invoked by uid 0); 18 Feb 2002 11:39:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 18 Feb 2002 11:39:02 -0000 Received: by moria.seul.org (Postfix) id 0908E1468F7; Mon, 18 Feb 2002 06:38:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DFC6E1468FA; Mon, 18 Feb 2002 06:38:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 6E9E41468F7 for ; Mon, 18 Feb 2002 06:38:49 -0500 (EST) Received: from f-cpu.org (kdl21-155.n.club-internet.fr [213.44.96.155]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 7048E16BD for ; Mon, 18 Feb 2002 12:38:46 +0100 (CET) Message-ID: <3C70E8EE.AF78A12D@f-cpu.org> Date: Mon, 18 Feb 2002 12:43:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> <20020218010626.32347@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Sun, Feb 17, 2002 at 11:19:10PM +0100, Yann Guidon wrote: > > > Cedric has recently made a new version of the F-CPU manual rev. 0.2.3, > > seeing that Olivier was really, really slow. There is only the > > english version currently. And a lot of work is still required ! > > Great news anyway :) Merci Cedric. > > > but it's better than nothing. You'll find the archive at > > http://f-cpu.seul.org/new under the name F-CPU_manual-0.2.4-en.tgz > > (i have not yet reviewed it) > > Maybe I'll find an hour or two this week... when the CeBIT issues > are done. beware : as i checked it yesterday, it appears that a version regression has probably occured ! :-( i'll have to pach like crazy :-( > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 18 12:26:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d3QA-0000G8-00 for ; Tue, 19 Feb 2002 07:06:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 07:06:34 +0100 (CET) Received: (qmail 10748 invoked by uid 0); 18 Feb 2002 19:26:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 18 Feb 2002 19:26:55 -0000 Received: by moria.seul.org (Postfix) id 9824D1468FF; Mon, 18 Feb 2002 14:26:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 93F451468FE; Mon, 18 Feb 2002 14:26:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a184.home.uni-hannover.de [130.75.232.184]) by moria.seul.org (Postfix) with ESMTP id 2577B1467E9 for ; Mon, 18 Feb 2002 14:26:52 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00468; Mon, 18 Feb 2002 12:26:12 +0100 Message-ID: <20020218122612.19039@thrai.stud.uni-hannover.de> Date: Mon, 18 Feb 2002 12:26:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! References: <200202180856.286b@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200202180856.286b@th00.opsion.fr>; from nicolas.boulay@ifrance.com on Mon, Feb 18, 2002 at 08:56:40AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 18, 2002 at 08:56:40AM +0000, nicolas.boulay@ifrance.com wrote: [...] > >>>> BIP ! Nop ! That's the common mistake. An rs > bascule is composed by 2 latches with the second used > inversed clock. A fliflop use a pulse generator to > trigger a single latch (so it's transparent only few > times, that's create the setup and hold time, that's > why IBM prohibite flipflop). The `rs bascule' (whatever that is supposed to mean) is also called `master-slave-FF'. The latches `lock out' each other; ideally, there is no transparent phase (depends on the timing). But it's almost twice as big as the pulse generator version. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 18 19:06:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d3QF-0000G8-00 for ; Tue, 19 Feb 2002 07:06:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 07:06:39 +0100 (CET) Received: (qmail 6682 invoked by uid 0); 18 Feb 2002 18:06:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 18 Feb 2002 18:06:57 -0000 Received: by moria.seul.org (Postfix) id 63735146900; Mon, 18 Feb 2002 13:06:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60FE21468FF; Mon, 18 Feb 2002 13:06:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id ECBEB1467EB for ; Mon, 18 Feb 2002 13:06:54 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 7427016F7; Mon, 18 Feb 2002 19:06:51 +0100 (CET) Received: from [132.227.86.2] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] new manual version Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2002 19:06:51 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 Ben Franchuk : >Yann Guidon wrote: >> in the most recent version, i simply use a 4-input MUX :-) >> the =22logic=22 transformation is performed by a LUT during the >> decoding or Xbar cycle. look at the =22stable=22 source code. >Hmm I see where I got confused. Looking at the well written >but un-readable VHDL code thank you ;-) if you have remarks, i'm ready to include your enhancements. > I can see where I got confused. >Your logic is still simpler than mine but had you written > >Out =3D F1 * /A * /B > + F2 * /A * B > + F3 * A * /B > + F4 * A * B That is what i wrote long ago, at the beginning. However, this summer, i finally realized that it was indeed a MUX :-) >I would have got less confused. This is a problem : if it is =22human readable=22 the synthesier creates bloated logic, while the =22optimized=22 version makes a compact and efficient version (that can be easily inferred by the synthesiser) but it is less =22obvious=22 for the reader. = At a time, i had left the original version in comments. It is probably erased now. > The logic I had does look >like it would make a nice generic ALU ( but not for the F-CPU) >if I add carry logic. i see. >Would modified INC/DEC unit be useful for +2,4,8 -2,4,8 constants >and another INC/DEC instruction. I am thinking of a language like >FORTH where they pop and push stuff on a stack like mad and use = >of the general adder could be a bottle neck on this kind of address >calculation. for push and pop, use post-incremented pointers. have fun, >Ben Franchuk - Dawn * 12/24 bit cpu * YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Feb 18 17:50:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d3QG-0000G8-00 for ; Tue, 19 Feb 2002 07:06:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 07:06:40 +0100 (CET) Received: (qmail 15000 invoked by uid 0); 18 Feb 2002 16:49:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 18 Feb 2002 16:49:18 -0000 Received: by moria.seul.org (Postfix) id 81D04146855; Mon, 18 Feb 2002 11:49:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 792581467EB; Mon, 18 Feb 2002 11:49:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id C25071467EB for ; Mon, 18 Feb 2002 11:49:16 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-210.jetnet.ab.ca [207.34.60.210] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA21755 for ; Mon, 18 Feb 2002 09:49:14 -0700 (MST) Message-ID: <3C7130EA.354CB161@jetnet.ab.ca> Date: Mon, 18 Feb 2002 09:50:50 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> <3C70572A.818862BB@jetnet.ab.ca> <3C70E8ED.3229C7A6@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > in the most recent version, i simply use a 4-input MUX :-) > the "logic" transformation is performed by a LUT during the > decoding or Xbar cycle. look at the "stable" source code. Hmm I see where I got confused. Looking at the well written but un-readable VHDL code I can see where I got confused. Your logic is still simpler than mine but had you written Out = F1 * /A * /B + F2 * /A * B + F3 * A * /B + F4 * A * B I would have got less confused. The logic I had does look like it would make a nice generic ALU ( but not for the F-CPU) if I add carry logic. Would modified INC/DEC unit be useful for +2,4,8 -2,4,8 constants and another INC/DEC instruction. I am thinking of a language like FORTH where they pop and push stuff on a stack like mad and use of the general adder could be a bottle neck on this kind of address calculation. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Feb 19 02:26:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d3QI-0000G8-00 for ; Tue, 19 Feb 2002 07:06:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 07:06:42 +0100 (CET) Received: (qmail 3360 invoked by uid 0); 19 Feb 2002 01:21:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Feb 2002 01:21:52 -0000 Received: by moria.seul.org (Postfix) id 14C2F1467E9; Mon, 18 Feb 2002 20:21:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EFFFF14684D; Mon, 18 Feb 2002 20:21:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 629051467E9 for ; Mon, 18 Feb 2002 20:21:50 -0500 (EST) Received: from f-cpu.org (kdl11-25.n.club-internet.fr [213.44.9.25]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 119DA1694 for ; Tue, 19 Feb 2002 02:21:47 +0100 (CET) Message-ID: <3C71A9D4.7BAAE6A1@f-cpu.org> Date: Tue, 19 Feb 2002 02:26:44 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> <3C70572A.818862BB@jetnet.ab.ca> <3C70E8ED.3229C7A6@f-cpu.org> <3C7130EA.354CB161@jetnet.ab.ca> <20020218203704.12088@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > > On Mon, Feb 18, 2002 at 09:50:50AM -0700, Ben Franchuk wrote: > [...] > > Would modified INC/DEC unit be useful for +2,4,8 -2,4,8 constants > > and another INC/DEC instruction. I am thinking of a language like > > FORTH where they pop and push stuff on a stack like mad and use > > of the general adder could be a bottle neck on this kind of address > > calculation. > We still have the option to do that with the original instruction > (there are some free bits because the instruction is 1r1w). > And we don't need a separate unit either, we just have to leave the > least significant bits alone. you're right but, on the wider perspective, it is about memory addressing, so post-incremented pointers are the rule in that case. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 18 20:37:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d3QK-0000G8-00 for ; Tue, 19 Feb 2002 07:06:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 07:06:44 +0100 (CET) Received: (qmail 29422 invoked by uid 0); 18 Feb 2002 21:20:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 18 Feb 2002 21:20:06 -0000 Received: by moria.seul.org (Postfix) id 03EAD146903; Mon, 18 Feb 2002 16:20:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EFF6E146905; Mon, 18 Feb 2002 16:20:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a127.home.uni-hannover.de [130.75.232.127]) by moria.seul.org (Postfix) with ESMTP id 0854C146903 for ; Mon, 18 Feb 2002 16:20:02 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00656; Mon, 18 Feb 2002 20:37:04 +0100 Message-ID: <20020218203704.12088@thrai.stud.uni-hannover.de> Date: Mon, 18 Feb 2002 20:37:04 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new manual version References: <3C702C5E.74A5B2C0@f-cpu.org> <3C70572A.818862BB@jetnet.ab.ca> <3C70E8ED.3229C7A6@f-cpu.org> <3C7130EA.354CB161@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C7130EA.354CB161@jetnet.ab.ca>; from Ben Franchuk on Mon, Feb 18, 2002 at 09:50:50AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 18, 2002 at 09:50:50AM -0700, Ben Franchuk wrote: [...] > Would modified INC/DEC unit be useful for +2,4,8 -2,4,8 constants > and another INC/DEC instruction. I am thinking of a language like > FORTH where they pop and push stuff on a stack like mad and use > of the general adder could be a bottle neck on this kind of address > calculation. We still have the option to do that with the original instruction (there are some free bits because the instruction is 1r1w). And we don't need a separate unit either, we just have to leave the least significant bits alone. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Feb 19 09:25:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16d77W-000394-00 for ; Tue, 19 Feb 2002 11:03:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 11:03:34 +0100 (CET) Received: (qmail 15809 invoked by uid 0); 19 Feb 2002 08:26:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 19 Feb 2002 08:26:24 -0000 Received: by moria.seul.org (Postfix) id EA1C81467F1; Tue, 19 Feb 2002 03:26:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0F2E14685B; Tue, 19 Feb 2002 03:26:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 63FD21467F1 for ; Tue, 19 Feb 2002 03:26:20 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr; Tue, 19 Feb 2002 08:25:55 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! From: X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Feb 2002 08:25:55 GMT Message-id: <200202190825.3746@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 18/02/02 Objet: Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! On Mon, Feb 18, 2002 at 08:56:40AM +0000, nicolas.boulay@ifrance.com wrote: [...] > >>>> BIP ! Nop ! That's the common mistake. An rs > bascule is composed by 2 latches with the second used > inversed clock. A fliflop use a pulse generator to > trigger a single latch (so it's transparent only few > times, that's create the setup and hold time, that's > why IBM prohibite flipflop). The `rs bascule' (whatever that is supposed to mean) is also called >>> Sorry, i didn't know how to translate it. `master-slave-FF'. The latches `lock out' each other; ideally, there is no transparent phase (depends on the timing). But it's almost twice as big as the pulse generator version. >>> I don't think so. When you see the powerPC version of this device, it's pretty small compare to the one from AMD K6 for exemple. Nowdays, there are very different design for flipflop Master slave or not. It's a ratio between speed, size and power consumption. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ***************************************************** ******** To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Feb 19 16:18:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16dDPV-0008NC-00 for ; Tue, 19 Feb 2002 17:46:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Feb 2002 17:46:33 +0100 (CET) Received: (qmail 31310 invoked by uid 0); 19 Feb 2002 15:18:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 19 Feb 2002 15:18:56 -0000 Received: by moria.seul.org (Postfix) id 1A84E146859; Tue, 19 Feb 2002 10:18:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DFB3114685D; Tue, 19 Feb 2002 10:18:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from studict.student.utwente.nl (studict.student.utwente.nl [130.89.220.2]) by moria.seul.org (Postfix) with ESMTP id 91997146859 for ; Tue, 19 Feb 2002 10:18:52 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.230.41]) by studict.student.utwente.nl (8.9.3/MQT) with SMTP id QAA16306 for ; Tue, 19 Feb 2002 16:18:48 +0100 (MET) Message-ID: <001001c1b958$bbeb38a0$29e65982@student.utwente.nl> From: "Marco Al" To: References: <200202190825.3746@th00.opsion.fr> Subject: Re: Rep:Re: Rep:Re: Rep:Re: Re: [f-cpu] No latches, please ! Date: Tue, 19 Feb 2002 16:18:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: >>> I don't think so. When you see the powerPC version of this device, it's pretty small compare to the one from AMD K6 for exemple. Nowdays, there are very different design for flipflop Master slave or not. It's a ratio between speed, size and power consumption. There are some amazing designs out there for sure, and the difference in performance has been limited ... but how highly advanced can you expect the FF's to be at "run of the mill" foundries? What are they licensed to use? Whats in their standard cell libraries? Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Feb 20 18:12:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16df9E-0001VQ-00 for ; Wed, 20 Feb 2002 23:23:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Feb 2002 23:23:36 +0100 (CET) Received: (qmail 21886 invoked by uid 0); 20 Feb 2002 17:25:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 20 Feb 2002 17:25:11 -0000 Received: by moria.seul.org (Postfix) id 8AED2146842; Wed, 20 Feb 2002 12:25:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 82D21146832; Wed, 20 Feb 2002 12:25:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 1C833146817 for ; Wed, 20 Feb 2002 12:25:06 -0500 (EST) Received: from ifurita (212.194.236.121) by mail.laposte.net (5.5.044) id 3C4C3539001F3FA1 for f-cpu@seul.org; Wed, 20 Feb 2002 18:25:05 +0100 Message-ID: <005601c1ba31$c91efe60$79ecc2d4@ifurita> From: "Christophe" To: Subject: [f-cpu] Forget, just a test for my effective registering Date: Wed, 20 Feb 2002 18:12:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Feb 21 16:20:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16dxtF-0005Wq-00 for ; Thu, 21 Feb 2002 19:24:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 21 Feb 2002 19:24:21 +0100 (CET) Received: (qmail 16162 invoked by uid 0); 21 Feb 2002 15:21:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Feb 2002 15:21:07 -0000 Received: by moria.seul.org (Postfix) id A1B681467F6; Thu, 21 Feb 2002 10:21:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BF651467F5; Thu, 21 Feb 2002 10:21:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id DCBC91467F0 for ; Thu, 21 Feb 2002 10:21:05 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200202211520.3ac1; Thu, 21 Feb 2002 15:20:58 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] document From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Feb 2002 15:20:58 GMT Message-id: <200202211520.3ac1@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just find a nice place about different topic on cpu design= : http://www.cs.washington.edu/education/courses/471/00au/ nice read ! =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Feb 21 18:44:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16dxtK-0005Wq-00 for ; Thu, 21 Feb 2002 19:24:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 21 Feb 2002 19:24:26 +0100 (CET) Received: (qmail 6844 invoked by uid 0); 21 Feb 2002 17:44:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 21 Feb 2002 17:44:43 -0000 Received: by moria.seul.org (Postfix) id 6EBCB1463AB; Thu, 21 Feb 2002 12:44:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5743D1467F4; Thu, 21 Feb 2002 12:44:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id E4F3A1463AB for ; Thu, 21 Feb 2002 12:44:41 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id 8CC4416D2 for ; Thu, 21 Feb 2002 18:44:39 +0100 (CET) Received: from [132.227.86.2] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] document Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Feb 2002 18:44:39 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: =22Nicolas Boulay=22 >I just find a nice place about different topic on cpu design : >http://www.cs.washington.edu/education/courses/471/00au/ >nice read =21 yes, thanks =21 YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 23 01:28:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16edLD-0000SH-00 for ; Sat, 23 Feb 2002 15:39:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 23 Feb 2002 15:39:59 +0100 (CET) Received: (qmail 31754 invoked by uid 0); 23 Feb 2002 00:23:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 23 Feb 2002 00:23:40 -0000 Received: by moria.seul.org (Postfix) id 63E05146806; Fri, 22 Feb 2002 19:23:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5BAD2146808; Fri, 22 Feb 2002 19:23:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id BFB7E146806 for ; Fri, 22 Feb 2002 19:23:38 -0500 (EST) Received: from f-cpu.org (kdl11-15.n.club-internet.fr [213.44.9.15]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 820C416B0 for ; Sat, 23 Feb 2002 01:23:34 +0100 (CET) Message-ID: <3C76E23A.B3919F61@f-cpu.org> Date: Sat, 23 Feb 2002 01:28:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] F-CPU invited at the Libre Software Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Pierre Jarillon, president of ABUL (http://www.abul.org/, Linux User Group of Bordeaux) invites the worldwide F-CPU community to the yearly Libre Software Meeting (http://lsm.abul.org/ or http://lsm2002.abul.org/ if the first doesn't work). Last year, hundreds of Free Software developpers from all countries gathered and organised conferences and meetings. This year, F-CPU has a place because of its indirect impact on Free Software and we could meet GNU developpers that could help port GCC for example. I also hope that we will be able to make a big family photograph of a large portion of the worldwide F-CPU team. Some practical details : - LSM takes place in July, from 9th to 13th. - no subscription fee - infrastructure is provided by ABUL : rooms, internet, projectors... - small fees for the sleeping rooms (10 euros ?) OTOH, ABUL asks how many people will come and how many presentations and conferences will be held. We have to give a first estimation to ease their work. We need to know whether you come, yes, maybe or not, what you propose to do there etc... If you don't come, then, huh, you gotta have a really good excuse anyway... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Sat Feb 23 03:43:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16edLG-0000SH-00 for ; Sat, 23 Feb 2002 15:40:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 23 Feb 2002 15:40:02 +0100 (CET) Received: (qmail 10011 invoked by uid 0); 23 Feb 2002 02:47:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 23 Feb 2002 02:47:26 -0000 Received: by moria.seul.org (Postfix) id A8CFE146807; Fri, 22 Feb 2002 21:47:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3BA8146809; Fri, 22 Feb 2002 21:47:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from lvdi.net (unknown [216.24.138.2]) by moria.seul.org (Postfix) with SMTP id 36405146807 for ; Fri, 22 Feb 2002 21:47:25 -0500 (EST) Received: from wyrm ([151.201.26.52]) by lvdi.net ; Fri, 22 Feb 2002 18:47:20 2000 PDT Received: from lee by wyrm with local (Exim 3.34 #1 (Debian)) id 16eS9c-0006vK-00 for ; Fri, 22 Feb 2002 21:43:16 -0500 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Message-Id: From: Lee Salzman Date: Fri, 22 Feb 2002 21:43:16 -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Last year, hundreds of Free Software developpers from all countries > gathered and organised conferences and meetings. This year, > F-CPU has a place because of its indirect impact on Free Software > and we could meet GNU developpers that could help port GCC for > example. I also hope that we will be able to make a big family > photograph of a large portion of the worldwide F-CPU team. I thought I already ported GCC to the F-CPU? :) > WHYGEE Lee Salzman ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 23 14:15:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16edLM-0000SH-00 for ; Sat, 23 Feb 2002 15:40:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 23 Feb 2002 15:40:08 +0100 (CET) Received: (qmail 925 invoked by uid 0); 23 Feb 2002 13:10:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 23 Feb 2002 13:10:23 -0000 Received: by moria.seul.org (Postfix) id DFD4C1467F7; Sat, 23 Feb 2002 08:10:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCD4714680C; Sat, 23 Feb 2002 08:10:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8B8941467F7 for ; Sat, 23 Feb 2002 08:10:21 -0500 (EST) Received: from f-cpu.org (kdl11-106.n.club-internet.fr [213.44.9.106]) by relay-3v.club-internet.fr (Postfix) with ESMTP id A085B1708 for ; Sat, 23 Feb 2002 14:10:18 +0100 (CET) Message-ID: <3C7795EF.2C7845B9@f-cpu.org> Date: Sat, 23 Feb 2002 14:15:27 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Lee Salzman wrote: > > > Last year, hundreds of Free Software developpers from all countries > > gathered and organised conferences and meetings. This year, > > F-CPU has a place because of its indirect impact on Free Software > > and we could meet GNU developpers that could help port GCC for > > example. I also hope that we will be able to make a big family > > photograph of a large portion of the worldwide F-CPU team. > > I thought I already ported GCC to the F-CPU? :) i didn't mean to offense youn Lee :-) however, from the little i know, there are still a lot of problems and unsupported, useful features such as SIMD... There are many optimisation techniques that F-CPU requires and that GCC is completely unaware of. For example, the branches are treated with absolute or relative addresses in GCC while F-CPU uses registers only. With the "hack" that i remember, each branch requires a prefetch+branch, while in theory, the prefetch is not always necessary : a part of the register is used to store the "return stack" and other things, for example. Making GCC "understand" that is not in my current list of things to do, otherwise i would have to rewrite everything and i don't have enough time for that :-/ however, it's nice to read you again, Lee ! will you manage to come to Bordeaux this summer ? > > WHYGEE > > Lee Salzman WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Feb 23 12:22:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16emfj-0007B1-00 for ; Sun, 24 Feb 2002 01:37:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 24 Feb 2002 01:37:47 +0100 (CET) Received: (qmail 11302 invoked by uid 0); 23 Feb 2002 22:46:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Feb 2002 22:46:47 -0000 Received: by moria.seul.org (Postfix) id DA4341467F3; Sat, 23 Feb 2002 17:46:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CE69B146802; Sat, 23 Feb 2002 17:46:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a152.home.uni-hannover.de [130.75.232.152]) by moria.seul.org (Postfix) with ESMTP id 6C85E1467F3 for ; Sat, 23 Feb 2002 17:46:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00439; Sat, 23 Feb 2002 12:22:52 +0100 Message-ID: <20020223122252.56286@thrai.stud.uni-hannover.de> Date: Sat, 23 Feb 2002 12:22:52 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Lee Salzman on Fri, Feb 22, 2002 at 09:43:16PM -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Feb 22, 2002 at 09:43:16PM -0500, Lee Salzman wrote: > I thought I already ported GCC to the F-CPU? :) Not until it's tested :) That reminds me... I should finish my assembler/emulator couple. But first we need to bring some light into the dark and dusty corners of the ISA description. Fiat lux, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Feb 24 12:17:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEG-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:12 +0100 (CET) Received: (qmail 26237 invoked by uid 0); 24 Feb 2002 20:13:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 24 Feb 2002 20:13:49 -0000 Received: by moria.seul.org (Postfix) id 76C44146812; Sun, 24 Feb 2002 15:13:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 65FEB146817; Sun, 24 Feb 2002 15:13:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 876EB146812 for ; Sun, 24 Feb 2002 15:13:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00458; Sun, 24 Feb 2002 12:17:16 +0100 Message-ID: <20020224121716.21537@thrai.stud.uni-hannover.de> Date: Sun, 24 Feb 2002 12:17:16 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C7795EF.2C7845B9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C7795EF.2C7845B9@f-cpu.org>; from Yann Guidon on Sat, Feb 23, 2002 at 02:15:27PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Feb 23, 2002 at 02:15:27PM +0100, Yann Guidon wrote: [...] > i didn't mean to offense youn Lee :-) however, from the little > i know, there are still a lot of problems and unsupported, useful > features such as SIMD... There are many optimisation techniques > that F-CPU requires and that GCC is completely unaware of. Sorry to interrupt, but: We don't need a highly optimizing compiler at the beginning. We just need a compiler that generates correct code (may also be bad code, as long as it's correct). It doesn't have to support SIMD, either -- most compilers don't grok that anyway. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Feb 25 04:49:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEL-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:17 +0100 (CET) Received: (qmail 8295 invoked by uid 0); 24 Feb 2002 21:43:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 24 Feb 2002 21:43:04 -0000 Received: by moria.seul.org (Postfix) id 7B0AC146818; Sun, 24 Feb 2002 16:43:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71F9014681B; Sun, 24 Feb 2002 16:43:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 24982146818 for ; Sun, 24 Feb 2002 16:43:03 -0500 (EST) Received: from ifrance.com (vlt3-187.n.club-internet.fr [194.158.108.187]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 37BCB172B for ; Sun, 24 Feb 2002 22:43:00 +0100 (CET) Message-ID: <3C79B44E.7C76FE5B@ifrance.com> Date: Sun, 24 Feb 2002 22:49:34 -0500 From: nicO X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C7795EF.2C7845B9@f-cpu.org> <20020224121716.21537@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Feb 23, 2002 at 02:15:27PM +0100, Yann Guidon wrote: > [...] > > i didn't mean to offense youn Lee :-) however, from the little > > i know, there are still a lot of problems and unsupported, useful > > features such as SIMD... There are many optimisation techniques > > that F-CPU requires and that GCC is completely unaware of. > > Sorry to interrupt, but: We don't need a highly optimizing compiler at > the beginning. We just need a compiler that generates correct code > (may also be bad code, as long as it's correct). It doesn't have to > support SIMD, either -- most compilers don't grok that anyway. > Hmm! That's un interesting question. Have something working quickly or have something powerfull ? I imagine that use SIMD code are quite difficult so it's intersting to see if it miss some instructions to use all the power of the SIMD stuff. i know that one of the most problematic things are the instruction that pack the data, maybe we miss some. nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sun Feb 24 22:49:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEO-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:20 +0100 (CET) Received: (qmail 10172 invoked by uid 0); 24 Feb 2002 22:06:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 24 Feb 2002 22:06:43 -0000 Received: by moria.seul.org (Postfix) id B24A5146822; Sun, 24 Feb 2002 17:06:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF25A146820; Sun, 24 Feb 2002 17:06:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id D91F614681E for ; Sun, 24 Feb 2002 17:06:40 -0500 (EST) Received: from art1.none.de ([62.144.176.15]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g1OM6kL11685 for ; Sun, 24 Feb 2002 23:06:46 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.176.15] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16f6XA-0002L2-00 for ; Sun, 24 Feb 2002 22:50:16 +0100 Date: Sun, 24 Feb 2002 22:49:37 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: <3C79B44E.7C76FE5B@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Sun, 24 Feb 2002, nicO wrote: > I imagine that use SIMD code are quite difficult so it's intersting to > see if it miss some instructions to use all the power of the SIMD stuff. > i know that one of the most problematic things are the instruction that > pack the data, maybe we miss some. Why not use a temporary bytecode generated with some higher level functions (between assembler and libc, I think on a level as forth is). First the higher level functions will be assembled with easier machine depended code, later they will be substituted by optimized SIMD-Code... Any hints? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8eV/0ClxplZklbgERAqufAJ0SLRgjpB/K7jr7sSLj1o3v0JCLYQCeInkn R33OTU7HaQnAnL0f1K9Idv4= =zzl6 -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 25 00:13:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhER-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:23 +0100 (CET) Received: (qmail 31428 invoked by uid 0); 24 Feb 2002 23:14:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 24 Feb 2002 23:14:00 -0000 Received: by moria.seul.org (Postfix) id A69C114681F; Sun, 24 Feb 2002 18:13:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A2804146824; Sun, 24 Feb 2002 18:13:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a040.home.uni-hannover.de [130.75.232.40]) by moria.seul.org (Postfix) with ESMTP id 3AC6D14681F for ; Sun, 24 Feb 2002 18:13:57 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02783; Mon, 25 Feb 2002 00:13:55 +0100 Message-ID: <20020225001354.10560@thrai.stud.uni-hannover.de> Date: Mon, 25 Feb 2002 00:13:54 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C7795EF.2C7845B9@f-cpu.org> <20020224121716.21537@thrai.stud.uni-hannover.de> <3C79B44E.7C76FE5B@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C79B44E.7C76FE5B@ifrance.com>; from nicO on Sun, Feb 24, 2002 at 10:49:34PM -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Feb 24, 2002 at 10:49:34PM -0500, nicO wrote: [...] > Hmm! That's un interesting question. Have something working quickly or > have something powerfull ? IMHO, it's easier to optimize if it's already working. Cross development simply sucks. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Feb 25 00:47:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhET-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:25 +0100 (CET) Received: (qmail 14011 invoked by uid 0); 24 Feb 2002 23:42:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 24 Feb 2002 23:42:25 -0000 Received: by moria.seul.org (Postfix) id CF313146813; Sun, 24 Feb 2002 18:42:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C931C146824; Sun, 24 Feb 2002 18:42:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 79E91146813 for ; Sun, 24 Feb 2002 18:42:23 -0500 (EST) Received: from f-cpu.org (kdl11-13.n.club-internet.fr [213.44.9.13]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 696431716 for ; Mon, 25 Feb 2002 00:42:20 +0100 (CET) Message-ID: <3C797B93.29C4FA28@f-cpu.org> Date: Mon, 25 Feb 2002 00:47:31 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Andreas Romeyke wrote: > Hello, > > On Sun, 24 Feb 2002, nicO wrote: > > > I imagine that use SIMD code are quite difficult so it's intersting to > > see if it miss some instructions to use all the power of the SIMD stuff. > > i know that one of the most problematic things are the instruction that > > pack the data, maybe we miss some. which ? the existing ones are rather complete AFAIK. > Why not use a temporary bytecode generated with some higher level > functions (between assembler and libc, I think on a level as forth > is). > > First the higher level functions will be assembled with easier > machine depended code, later they will be substituted by optimized > SIMD-Code... > > Any hints? i am not sure to understand. however, in the race for performance, one of worst the problems is to get rid of of the intermediate levels of representation, because we lose data and semantics during each conversion. What matters most is "what does the program do" rather than "how does it do it" because we can find better ways. I have the feeling that GCC will make really slow programs. while the superpipeline can reach a somewhat higher frequency, an inadequate compiler makes the system work really slow. i fear that this constatation can be used as an argument against the project. > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: anybody knows whether he comes to the LSM ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 25 08:07:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEa-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:32 +0100 (CET) Received: (qmail 27958 invoked by uid 0); 25 Feb 2002 07:06:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Feb 2002 07:06:05 -0000 Received: by moria.seul.org (Postfix) id 55BEF146829; Mon, 25 Feb 2002 02:06:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4CBF714682B; Mon, 25 Feb 2002 02:06:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 3A485146829 for ; Mon, 25 Feb 2002 02:06:03 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16fFEM-0002hg-00 for f-cpu@seul.org; Mon, 25 Feb 2002 08:07:26 +0100 Date: Mon, 25 Feb 2002 08:07:25 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: <3C797B93.29C4FA28@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi there, >from my experience the software stuff always is at least one or two generations behind hardware things. My concerns about f-cpu are also related to development of the compiler tool kit. Is there a document where the compiler writers can get an idea about the rules for generation of good and efficient code? JG On Mon, 25 Feb 2002, Yann Guidon wrote: > Andreas Romeyke wrote: > > On Sun, 24 Feb 2002, nicO wrote: > > > I imagine that use SIMD code are quite difficult so it's intersting to > > > see if it miss some instructions to use all the power of the SIMD stuff. > > > i know that one of the most problematic things are the instruction that > > > pack the data, maybe we miss some. > > which ? the existing ones are rather complete AFAIK. > > > Why not use a temporary bytecode generated with some higher level > > functions (between assembler and libc, I think on a level as forth > > is). > > > > First the higher level functions will be assembled with easier > > machine depended code, later they will be substituted by optimized > > SIMD-Code... > > > > Any hints? > > i am not sure to understand. > > however, in the race for performance, one of worst the problems is to > get rid of of the intermediate levels of representation, because we > lose data and semantics during each conversion. What matters most is > "what does the program do" rather than "how does it do it" because we > can find better ways. > > I have the feeling that GCC will make really slow programs. > while the superpipeline can reach a somewhat higher frequency, > an inadequate compiler makes the system work really slow. > i fear that this constatation can be used as an argument > against the project. > > > Bye Andreas > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > PS: anybody knows whether he comes to the LSM ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Feb 25 09:57:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEc-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:34 +0100 (CET) Received: (qmail 22224 invoked by uid 0); 25 Feb 2002 08:57:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 25 Feb 2002 08:57:06 -0000 Received: by moria.seul.org (Postfix) id 1214514682A; Mon, 25 Feb 2002 03:57:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D2BEE14682D; Mon, 25 Feb 2002 03:57:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 3F90014682A for ; Mon, 25 Feb 2002 03:57:03 -0500 (EST) Received: from art1.none.de ([62.27.156.174]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g1P8v4L29888 for ; Mon, 25 Feb 2002 09:57:04 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.156.174] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16fGwg-0000Bj-00 for ; Mon, 25 Feb 2002 09:57:18 +0100 Date: Mon, 25 Feb 2002 09:57:05 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: <3C797B93.29C4FA28@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, On Mon, 25 Feb 2002, Yann Guidon wrote: > > Any hints? > > i am not sure to understand. I meant: - - we need a compiler which generates temporary code at a level between assembler/machinecode and C + libc like Forth does. At this level we had basic functions, which first: - - can be compiled/assembled automatically by a stupid Compiler/assembler, so we have first the issue of functionality second: - - can be assembled/substituted by handoptimized SIMD-assembler, so we have then the issue of higher speed (BTW. I know about that there is only a local optimization possible, but it depends on abstraction level of the basic functions in temporary code) > however, in the race for performance, one of worst the problems is to > get rid of of the intermediate levels of representation, because we > lose data and semantics during each conversion. What matters most is > "what does the program do" rather than "how does it do it" because we > can find better ways. IMHO we should use a simpler language than C because a Compiler with SIMD and superpipelining should be easier to developed. > I have the feeling that GCC will make really slow programs. > while the superpipeline can reach a somewhat higher frequency, > an inadequate compiler makes the system work really slow. > i fear that this constatation can be used as an argument > against the project. The problem is that softwaredevelopers thinking more in serial than parallel. You can verify this thesis comparing your code-writing with VHDL and with C/C++. > PS: anybody knows whether he comes to the LSM ? I will not be there, but I want. BTW.: Anybody would send me the F-CPU-CDROM from last CCC, any hints? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8efxlClxplZklbgERArroAJ9XFTpy97gVy+nyhSBmeCDDZPwbQgCfbeqb z0bTIqytuXmsRd0iYGM13/Q= =RNt2 -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Feb 25 09:58:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEc-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:34 +0100 (CET) Received: (qmail 8911 invoked by uid 0); 25 Feb 2002 09:02:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 25 Feb 2002 09:02:56 -0000 Received: by moria.seul.org (Postfix) id 575AF146829; Mon, 25 Feb 2002 04:02:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2EC0614682D; Mon, 25 Feb 2002 04:02:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 5FB85146829 for ; Mon, 25 Feb 2002 04:02:53 -0500 (EST) Received: (qmail 96242 invoked by uid 85); 25 Feb 2002 09:03:05 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.480475 secs); 25 Feb 2002 09:03:05 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 25 Feb 2002 09:03:04 -0000 Message-ID: <3C79FC9B.6070707@yahoo.fr> Date: Mon, 25 Feb 2002 09:58:03 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C76E23A.B3919F61@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am a newbie on this ML and this project. I haven't yet ready all your archives about the F-CPU, then I think it's too early to me to propose something on an International Meeting ; but maybe I can come. To quick present me : I am a generalist engineer for telecom and signal treatment, with a specialization on electronic design. I work actually in a society specialized into formal verification methods, codesign and embedded software. I follow the CPC NG project in parallel. Yann Guidon wrote: >hello, > >Pierre Jarillon, president of ABUL (http://www.abul.org/, >Linux User Group of Bordeaux) invites the worldwide F-CPU community >to the yearly Libre Software Meeting (http://lsm.abul.org/ or >http://lsm2002.abul.org/ if the first doesn't work). >Last year, hundreds of Free Software developpers from all countries >gathered and organised conferences and meetings. This year, >F-CPU has a place because of its indirect impact on Free Software >and we could meet GNU developpers that could help port GCC for >example. I also hope that we will be able to make a big family >photograph of a large portion of the worldwide F-CPU team. > >Some practical details : >- LSM takes place in July, from 9th to 13th. >- no subscription fee >- infrastructure is provided by ABUL : rooms, internet, projectors... >- small fees for the sleeping rooms (10 euros ?) > >OTOH, ABUL asks how many people will come and how many presentations >and conferences will be held. We have to give a first estimation >to ease their work. We need to know whether you come, yes, maybe or not, >what you propose to do there etc... > >If you don't come, then, huh, you gotta have a really good excuse anyway... > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 25 11:25:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEd-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:35 +0100 (CET) Received: (qmail 2741 invoked by uid 0); 25 Feb 2002 10:23:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 25 Feb 2002 10:23:40 -0000 Received: by moria.seul.org (Postfix) id ABD4F146812; Mon, 25 Feb 2002 05:23:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9887D146822; Mon, 25 Feb 2002 05:23:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 61C1B146812 for ; Mon, 25 Feb 2002 05:23:38 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16fIKV-0002mx-00 for f-cpu@seul.org; Mon, 25 Feb 2002 11:25:59 +0100 Date: Mon, 25 Feb 2002 11:25:59 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > IMHO we should use a simpler language than C because a Compiler with > SIMD and superpipelining should be easier to developed. Interesting thought. > > I have the feeling that GCC will make really slow programs. > > while the superpipeline can reach a somewhat higher frequency, > > an inadequate compiler makes the system work really slow. > > i fear that this constatation can be used as an argument > > against the project. > > The problem is that softwaredevelopers thinking more in serial than > parallel. You can verify this thesis comparing your code-writing with VHDL > and with C/C++. Guess what, it's caused by the processor which serializes the code :-) Parallel in software has a lot to do with Interrupts or with multiprocessor systems. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 11:34:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEe-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:36 +0100 (CET) Received: (qmail 28034 invoked by uid 0); 25 Feb 2002 10:34:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 25 Feb 2002 10:34:24 -0000 Received: by moria.seul.org (Postfix) id E50C5146812; Mon, 25 Feb 2002 05:34:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C4861146822; Mon, 25 Feb 2002 05:34:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [195.36.216.171]) by moria.seul.org (Postfix) with ESMTP id 69B79146812 for ; Mon, 25 Feb 2002 05:34:22 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-2m.club-internet.fr (Postfix) with SMTP id E424916A6; Mon, 25 Feb 2002 11:34:17 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 11:34:17 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Juergen Goeritz = >Hi there, > >>from my experience the software stuff always is at least >one or two generations behind hardware things. My concerns >about f-cpu are also related to development of the compiler >tool kit. Is there a document where the compiler writers >can get an idea about the rules for generation of good and >efficient code? grmblgrmblgrmbl.... i know i should write one but don't have time :-( i will probably write articles containing the =22useful stuff=22 and make the complete document slowly with the useful pieces from the articles. it's the path to the least effort... >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 11:52:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEe-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:36 +0100 (CET) Received: (qmail 16316 invoked by uid 0); 25 Feb 2002 10:52:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 25 Feb 2002 10:52:29 -0000 Received: by moria.seul.org (Postfix) id 350CB146812; Mon, 25 Feb 2002 05:52:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1CEE1146822; Mon, 25 Feb 2002 05:52:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id B2B35146812 for ; Mon, 25 Feb 2002 05:52:27 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-1m.club-internet.fr (Postfix) with SMTP id D2B4C169D; Mon, 25 Feb 2002 11:52:25 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 11:52:25 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: Andreas Romeyke >Hallo, mojn, >On Mon, 25 Feb 2002, Yann Guidon wrote: >> > Any hints? >> i am not sure to understand. >I meant: > >- - we need a compiler which generates temporary code at a level between >assembler/machinecode and C + libc like Forth does. At this level we had >basic functions, which = > >first: >- - can be compiled/assembled automatically by a stupid Compiler/assemble= r, >so we have first the issue of functionality > >second: >- - can be assembled/substituted by handoptimized SIMD-assembler, so we h= ave >then the issue of higher speed > >(BTW. I know about that there is only a local optimization possible, but >it depends on abstraction level of the basic functions in temporary code) usually, scheduling optimisation requires a block of around 100 instructio= ns to be worth the effort and the result. it is usally performed with dataflo= w analysis. i presume that GCC's internal temporary representation is intere= sting but it seems too complex for me to do a quick hack ... >> however, in the race for performance, one of worst the problems is to >> get rid of of the intermediate levels of representation, because we >> lose data and semantics during each conversion. What matters most is >> =22what does the program do=22 rather than =22how does it do it=22 beca= use we >> can find better ways. > >IMHO we should use a simpler language than C because a Compiler with >SIMD and superpipelining should be easier to developed. C clearly lacks some modern and useful features such as returning multiple data through the registers (and not by reference) for example. the pointer management is awful. SIMD is of course a big pain but superpipelining should not be a problem because a dataflow analysis should do the trick on most codes. Unfortunately, most code today is written in C :-( >> I have the feeling that GCC will make really slow programs. >> while the superpipeline can reach a somewhat higher frequency, >> an inadequate compiler makes the system work really slow. >> i fear that this constatation can be used as an argument >> against the project. > >The problem is that softwaredevelopers thinking more in serial than >parallel. You can verify this thesis comparing your code-writing with VHD= L >and with C/C++. sure. modularity and laziness are other negative factors... you know, =22if it compiles then i can leave it as is=22... >> PS: anybody knows whether he comes to the LSM ? >I will not be there, but I want. please keep us informed =21 it would be cool if you could come. >BTW.: Anybody would send me the F-CPU-CDROM from last CCC, any hints? i could. send me your address (private email). >Bye Andreas YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@example.com Mon Feb 25 11:50:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEf-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:37 +0100 (CET) Received: (qmail 10989 invoked by uid 0); 25 Feb 2002 10:55:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 25 Feb 2002 10:55:05 -0000 Received: by moria.seul.org (Postfix) id 41F4A146812; Mon, 25 Feb 2002 05:55:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F6E9146822; Mon, 25 Feb 2002 05:55:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from fork.recoil.org (unknown [195.40.6.163]) by moria.seul.org (Postfix) with SMTP id E8208146812 for ; Mon, 25 Feb 2002 05:55:02 -0500 (EST) Received: (qmail 51100 invoked by uid 80); 25 Feb 2002 10:50:46 -0000 Received: from alisier.astrium-space.com ( [alisier.astrium-space.com]) as user nicolas.boulay@pop.ifrance.com by demo.horde.org with HTTP; Mon, 25 Feb 2002 10:50:46 +0000 Message-ID: <1014634246.3c7a1706b5c3d@demo.horde.org> Date: Mon, 25 Feb 2002 10:50:46 +0000 From: nicolas.boulay@example.com To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1-cvs X-Originating-IP: 140.94.82.18 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Surlignage Andreas Romeyke : -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, On Mon, 25 Feb 2002, Yann Guidon wrote: > > Any hints? > > i am not sure to understand. I meant: - - we need a compiler which generates temporary code at a level between assembler/machinecode and C + libc like Forth does. At this level we had basic functions, which first: - - can be compiled/assembled automatically by a stupid Compiler/assembler, so we have first the issue of functionality second: - - can be assembled/substituted by handoptimized SIMD-assembler, so we have then the issue of higher speed >>>If you write it it would be nice. But SIMD performance are related to the data structure. C are very poor in that domain. That's why we need vectorising compiler code ala SSE vector compiler from intel. C is too poor in semantic to easly introcuice such powerfull fonction. Or we can simply rewrite C or C++ librairy for the Fcpu (STL, Boost, libc). It could be easier but if we have a true vector compilier all old C code could be reused without rework. nicO <...> ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 11:56:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEg-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:38 +0100 (CET) Received: (qmail 11501 invoked by uid 0); 25 Feb 2002 10:56:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 25 Feb 2002 10:56:49 -0000 Received: by moria.seul.org (Postfix) id CB916146812; Mon, 25 Feb 2002 05:56:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B378F146822; Mon, 25 Feb 2002 05:56:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id 6EF24146812 for ; Mon, 25 Feb 2002 05:56:48 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-1m.club-internet.fr (Postfix) with SMTP id D8C3716E0; Mon, 25 Feb 2002 11:56:46 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 11:56:46 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Just an Illusion = >Hi, > >I am a newbie on this ML and this project. I haven't yet ready all your = >archives about the F-CPU, then I think it's too early to me to propose = >something on an International Meeting ; but maybe I can come. i hope as many people as possible could come. Such an occasion happens only once in a year :-) you're not forced to propose something but you are welcome to discuss with us and meet the other people from the project. >To quick present me : >I am a generalist engineer for telecom and signal treatment, with a = >specialization on electronic design. >I work actually in a society specialized into formal verification = >methods, codesign and embedded software. >I follow the CPC NG project in parallel. mmmm djrom ? regards, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Feb 25 12:04:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEg-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:38 +0100 (CET) Received: (qmail 23231 invoked by uid 0); 25 Feb 2002 11:09:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 25 Feb 2002 11:09:33 -0000 Received: by moria.seul.org (Postfix) id 424E0146812; Mon, 25 Feb 2002 06:09:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 39369146818; Mon, 25 Feb 2002 06:09:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 38561146812 for ; Mon, 25 Feb 2002 06:09:30 -0500 (EST) Received: (qmail 2432 invoked by uid 85); 25 Feb 2002 11:09:43 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.150443 secs); 25 Feb 2002 11:09:43 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 25 Feb 2002 11:09:43 -0000 Message-ID: <3C7A1A4A.5010403@yahoo.fr> Date: Mon, 25 Feb 2002 12:04:42 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr wrote: >mmmm djrom ? > Sorry, but what is a djrom ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 12:25:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEg-0004Cz-02 for ; Tue, 26 Feb 2002 14:01:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:38 +0100 (CET) Received: (qmail 14874 invoked by uid 0); 25 Feb 2002 11:25:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 25 Feb 2002 11:25:16 -0000 Received: by moria.seul.org (Postfix) id DCCEC146812; Mon, 25 Feb 2002 06:25:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2B47146818; Mon, 25 Feb 2002 06:25:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id 707EF146812 for ; Mon, 25 Feb 2002 06:25:14 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-1m.club-internet.fr (Postfix) with SMTP id 9A7E916F9; Mon, 25 Feb 2002 12:25:11 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 12:25:11 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Juergen Goeritz >> IMHO we should use a simpler language than C because a Compiler with >> SIMD and superpipelining should be easier to developed. >Interesting thought. yup but utopic :-( >> > I have the feeling that GCC will make really slow programs. >> > while the superpipeline can reach a somewhat higher frequency, >> > an inadequate compiler makes the system work really slow. >> > i fear that this constatation can be used as an argument >> > against the project. >> = >> The problem is that softwaredevelopers thinking more in serial than >> parallel. You can verify this thesis comparing your code-writing with V= HDL >> and with C/C++. > >Guess what, it's caused by the processor which serializes the code :-) >Parallel in software has a lot to do with Interrupts or with >multiprocessor systems. = however this triggers a thought (ouch =21) usually, a =22dumb=22 program is not optimised by the programmer who leaves the compiler do the whole work. Introducing parallelism, even inside a sequential program, can maybe help the programmer partition the software in such a way that the software can better optimise the code. This can help for example for loop merging and stuff like that ? >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 12:32:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEh-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:39 +0100 (CET) Received: (qmail 31292 invoked by uid 0); 25 Feb 2002 11:32:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 25 Feb 2002 11:32:19 -0000 Received: by moria.seul.org (Postfix) id 0B9AD146812; Mon, 25 Feb 2002 06:32:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 03288146818; Mon, 25 Feb 2002 06:32:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [195.36.216.171]) by moria.seul.org (Postfix) with ESMTP id A8322146812 for ; Mon, 25 Feb 2002 06:32:17 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-2m.club-internet.fr (Postfix) with SMTP id 65317168D; Mon, 25 Feb 2002 12:32:15 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 12:32:15 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, >De: Just an Illusion >whygee wrote: >>mmmm djrom ? >Sorry, but what is a djrom ? sorry, i thought aloud.... some people from CPCNG have come in contact with F-CPU and i thought that someone nicknamed djrom was among them. YG, really tired... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 25 13:07:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEh-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:39 +0100 (CET) Received: (qmail 13098 invoked by uid 0); 25 Feb 2002 12:05:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 25 Feb 2002 12:05:59 -0000 Received: by moria.seul.org (Postfix) id D5AE6146813; Mon, 25 Feb 2002 07:05:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CC1D414681F; Mon, 25 Feb 2002 07:05:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 9A06D146813 for ; Mon, 25 Feb 2002 07:05:56 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16fJvB-0002wl-00 for f-cpu@seul.org; Mon, 25 Feb 2002 13:07:57 +0100 Date: Mon, 25 Feb 2002 13:07:57 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 25 Feb 2002 whygee@club-internet.fr wrote: > >> > I have the feeling that GCC will make really slow programs. > >> > while the superpipeline can reach a somewhat higher frequency, > >> > an inadequate compiler makes the system work really slow. > >> > i fear that this constatation can be used as an argument > >> > against the project. > >> > >> The problem is that softwaredevelopers thinking more in serial than > >> parallel. You can verify this thesis comparing your code-writing with VHDL > >> and with C/C++. > > > >Guess what, it's caused by the processor which serializes the code :-) > >Parallel in software has a lot to do with Interrupts or with > >multiprocessor systems. > > however this triggers a thought (ouch !) > > usually, a "dumb" program is not optimised by the programmer > who leaves the compiler do the whole work. > Introducing parallelism, even inside a sequential program, can > maybe help the programmer partition the software in such > a way that the software can better optimise the code. > This can help for example for loop merging and stuff like that ? Now you are talking DSP. :-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 25 13:52:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEi-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:40 +0100 (CET) Received: (qmail 4802 invoked by uid 0); 25 Feb 2002 12:50:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 25 Feb 2002 12:50:29 -0000 Received: by moria.seul.org (Postfix) id A76A7146818; Mon, 25 Feb 2002 07:50:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 92AB3146822; Mon, 25 Feb 2002 07:50:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 817D9146818 for ; Mon, 25 Feb 2002 07:50:26 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16fKci-0002xk-00 for f-cpu@seul.org; Mon, 25 Feb 2002 13:52:56 +0100 Date: Mon, 25 Feb 2002 13:52:55 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ... and that leads me to another idea. Has anybody ever thought about data triggered software concepts? If a single processor today has to do a thing twice, it must run the programm sequentially two times, one after another with different data. In this case instruction caches will only bring additional power (beside burst loading) if the code completely fits into the cache. Otherwise it may be faster without cache, since reload always adds penalty. The processors usually run a program that has to fetch data, modify it and store it somewhere. This is a code (program) focused solution. The other way I can imagine is a data focused solution. The availability of data triggers the execution of a code part for that data to modify it. That could lead to a completely event triggered software scheme, i.e. data triggers software, which generates data, which triggers software a.s.o. Since this is a very basic mechanism it could be run on a single processor and on multiple processors. Or on the nearest processor available... It's not the same as task switching because it takes place on a much lower level. And it may obsolete task switching concepts like they exist today. comments? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Feb 25 14:00:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEi-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:40 +0100 (CET) Received: (qmail 20962 invoked by uid 0); 25 Feb 2002 13:00:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 25 Feb 2002 13:00:44 -0000 Received: by moria.seul.org (Postfix) id 5552F146818; Mon, 25 Feb 2002 08:00:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4EAFB146822; Mon, 25 Feb 2002 08:00:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [195.36.216.170]) by moria.seul.org (Postfix) with ESMTP id B1C59146818 for ; Mon, 25 Feb 2002 08:00:42 -0500 (EST) Received: from club-internet.fr (flashmail-am.cs.clubint.net [172.16.4.117]) by relay-1m.club-internet.fr (Postfix) with SMTP id 4DD921712; Mon, 25 Feb 2002 14:00:40 +0100 (CET) Received: from [132.227.86.2] by flashmail-am.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2002 14:00:40 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Juergen Goeritz >.... and that leads me to another idea. > > > >Has anybody ever thought about data triggered software >concepts? > >If a single processor today has to do a thing twice, it >must run the programm sequentially two times, one after >another with different data. In this case instruction >caches will only bring additional power (beside burst >loading) if the code completely fits into the cache. >Otherwise it may be faster without cache, since reload >always adds penalty. > >The processors usually run a program that has to fetch >data, modify it and store it somewhere. This is a code >(program) focused solution. > >The other way I can imagine is a data focused solution. >The availability of data triggers the execution of a >code part for that data to modify it. That could lead >to a completely event triggered software scheme, i.e. >data triggers software, which generates data, which >triggers software a.s.o. > >Since this is a very basic mechanism it could be run >on a single processor and on multiple processors. Or >on the nearest processor available... >It's not the same as task switching because it takes >place on a much lower level. And it may obsolete task >switching concepts like they exist today. > > > >comments? one usually calls this : a dataflow machine. on a lower level, it's simply a TTA execution core (like the previous F-CPU core idea that never succeeded). Look also at the CRAY MTA. >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Feb 25 14:12:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEj-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:41 +0100 (CET) Received: (qmail 20751 invoked by uid 0); 25 Feb 2002 13:09:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Feb 2002 13:09:52 -0000 Received: by moria.seul.org (Postfix) id 8307E14681F; Mon, 25 Feb 2002 08:09:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79015146829; Mon, 25 Feb 2002 08:09:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A497E14681F for ; Mon, 25 Feb 2002 08:09:50 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16fKva-0002zu-00 for f-cpu@seul.org; Mon, 25 Feb 2002 14:12:26 +0100 Date: Mon, 25 Feb 2002 14:12:26 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 25 Feb 2002 whygee@club-internet.fr wrote: > hi ! > > >comments? > > one usually calls this : a dataflow machine. > > on a lower level, it's simply a TTA execution core > (like the previous F-CPU core idea that never > succeeded). What was the problem with it? > Look also at the CRAY MTA. > > YG JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Feb 25 17:52:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEp-0004Cz-01 for ; Tue, 26 Feb 2002 14:01:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:47 +0100 (CET) Received: (qmail 10070 invoked by uid 0); 25 Feb 2002 16:52:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 25 Feb 2002 16:52:20 -0000 Received: by moria.seul.org (Postfix) id 8BFE1146811; Mon, 25 Feb 2002 11:52:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 859B114680C; Mon, 25 Feb 2002 11:52:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id B400D146807 for ; Mon, 25 Feb 2002 11:52:18 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-206.jetnet.ab.ca [207.34.60.206]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA15193 for ; Mon, 25 Feb 2002 09:52:16 -0700 (MST) Message-ID: <3C7A6BDF.8261733C@jetnet.ab.ca> Date: Mon, 25 Feb 2002 09:52:47 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] Compilers for the F-CPU. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Lets not bash C too hard, since was developed for use with computers that had a rather small amount of memory and limited data types. While I am not too impressed with ANSI C none the less that is what linux is written in and that is one of the goals of the F-Cpu is to run linux. wait... wait wait ... wait wait wait ... No F-cpu chip yet or even a simulator at the instruction level I don't see any way compiler or assembler development can go forward. A instruction emulator still needs parts of the f-cpu documentation to finish. Now if you want a nice new language here is one. http://pliant.cx/ I am not sure if can self compile however. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From djrom@altern.org Tue Feb 26 21:16:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEy-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:56 +0100 (CET) Received: (qmail 16489 invoked by uid 0); 25 Feb 2002 20:16:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 25 Feb 2002 20:16:36 -0000 Received: by moria.seul.org (Postfix) id 9BAFE1467FA; Mon, 25 Feb 2002 15:16:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91A1D146807; Mon, 25 Feb 2002 15:16:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cracken (ADijon-101-1-2-17.abo.wanadoo.fr [193.252.183.17]) by moria.seul.org (Postfix) with ESMTP id 1421F1467FA for ; Mon, 25 Feb 2002 15:16:34 -0500 (EST) Received: from cracken ([127.0.0.1] helo=localhost.localdomain) by cracken with esmtp (Exim 3.34 #1 (Debian)) id 16fo1s-0000zP-00 for ; Tue, 26 Feb 2002 21:16:52 +0100 Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting From: djrom To: f-cpu@seul.org In-Reply-To: <3C7A1A4A.5010403@yahoo.fr> References: <3C7A1A4A.5010403@yahoo.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6hvu1K0UDEuDQUKzTBX7" X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 21:16:52 +0100 Message-Id: <1014754612.600.3.camel@cracken> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --=-6hvu1K0UDEuDQUKzTBX7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Simple ! A djrom it's just me :-). Nothing to worry about :-) le lun 25-02-2002 =E0 12:04, Just an Illusion a =E9crit : >=20 >=20 > whygee@club-internet.fr wrote: >=20 > >mmmm djrom ? > > > Sorry, but what is a djrom ? >=20 >=20 > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >=20 --=-6hvu1K0UDEuDQUKzTBX7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Pour information voir http://www.gnupg.org iD8DBQA8e+00ipQKqugj2WQRAuTwAJ9ieR+N2Ubjrss2PuzNIQv3l4EQGQCdG9yr 49301wUVHu3wEN/OtLq+4a8= =rdzp -----END PGP SIGNATURE----- --=-6hvu1K0UDEuDQUKzTBX7-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From djrom@altern.org Tue Feb 26 21:17:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhEz-0004Cz-00 for ; Tue, 26 Feb 2002 14:01:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:01:57 +0100 (CET) Received: (qmail 31531 invoked by uid 0); 25 Feb 2002 20:17:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 25 Feb 2002 20:17:12 -0000 Received: by moria.seul.org (Postfix) id 5C5F3146809; Mon, 25 Feb 2002 15:17:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A1F3146807; Mon, 25 Feb 2002 15:17:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from cracken (ADijon-101-1-2-17.abo.wanadoo.fr [193.252.183.17]) by moria.seul.org (Postfix) with ESMTP id D9B261467FE for ; Mon, 25 Feb 2002 15:17:10 -0500 (EST) Received: from cracken ([127.0.0.1] helo=localhost.localdomain) by cracken with esmtp (Exim 3.34 #1 (Debian)) id 16fo2T-0000zi-00 for ; Tue, 26 Feb 2002 21:17:29 +0100 Subject: Re: Re: [f-cpu] F-CPU invited at the Libre Software Meeting From: djrom To: f-cpu@seul.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dfUu3Kg/xg//u67IKD/Z" X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 21:17:29 +0100 Message-Id: <1014754649.601.5.camel@cracken> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --=-dfUu3Kg/xg//u67IKD/Z Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable You were right. le lun 25-02-2002 =E0 12:32, whygee@club-internet.fr a =E9crit : > hello, >=20 > >De: Just an Illusion > >whygee wrote: > >>mmmm djrom ? > >Sorry, but what is a djrom ? > sorry, i thought aloud.... > some people from CPCNG have come in contact with F-CPU > and i thought that someone nicknamed djrom was among them. >=20 > YG, really tired... >=20 > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >=20 --=-dfUu3Kg/xg//u67IKD/Z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Pour information voir http://www.gnupg.org iD8DBQA8e+1ZipQKqugj2WQRArJlAJ4ssK9P/BZtkWBoNG9nYcyo/5xtSgCfVOAb J/RWQc1C+UOhoHlkclgDzR0= =Iezy -----END PGP SIGNATURE----- --=-dfUu3Kg/xg//u67IKD/Z-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 25 12:26:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhF8-0004Cz-00 for ; Tue, 26 Feb 2002 14:02:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:02:06 +0100 (CET) Received: (qmail 32625 invoked by uid 0); 25 Feb 2002 22:53:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 25 Feb 2002 22:53:32 -0000 Received: by moria.seul.org (Postfix) id A1CA71467FE; Mon, 25 Feb 2002 17:53:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 94F31146811; Mon, 25 Feb 2002 17:53:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a067.home.uni-hannover.de [130.75.232.67]) by moria.seul.org (Postfix) with ESMTP id 525251467FE for ; Mon, 25 Feb 2002 17:53:28 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00514; Mon, 25 Feb 2002 12:26:02 +0100 Message-ID: <20020225122602.19101@thrai.stud.uni-hannover.de> Date: Mon, 25 Feb 2002 12:26:02 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C797B93.29C4FA28@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Mon, Feb 25, 2002 at 09:57:05AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 25, 2002 at 09:57:05AM +0100, Andreas Romeyke wrote: [...] > - - we need a compiler which generates temporary code at a level between > assembler/machinecode and C + libc like Forth does. At this level we had > basic functions, which > > first: > - - can be compiled/assembled automatically by a stupid Compiler/assembler, > so we have first the issue of functionality > > second: > - - can be assembled/substituted by handoptimized SIMD-assembler, so we have > then the issue of higher speed The compiler can substitute the `macro words' on its own. If you just put the optimization burden on the assembler, you gain nothing. > (BTW. I know about that there is only a local optimization possible, but > it depends on abstraction level of the basic functions in temporary code) Why shouldn't an assembler be able to do file-global optimization? On the other hand, it's not its job to do things like that - an assembler should take whatever you feed it, and translate it to machine code *literally*. Everything else leads to insanity. > > however, in the race for performance, one of worst the problems is to > > get rid of of the intermediate levels of representation, because we > > lose data and semantics during each conversion. What matters most is > > "what does the program do" rather than "how does it do it" because we > > can find better ways. > > IMHO we should use a simpler language than C because a Compiler with > SIMD and superpipelining should be easier to developed. C *is* a very simple language. > > I have the feeling that GCC will make really slow programs. > > while the superpipeline can reach a somewhat higher frequency, > > an inadequate compiler makes the system work really slow. > > i fear that this constatation can be used as an argument > > against the project. > > The problem is that softwaredevelopers thinking more in serial than > parallel. You can verify this thesis comparing your code-writing with VHDL > and with C/C++. That's right. Software -- at least as we know it today -- *is* serial, with very few exceptions. On the other hand, we can easily see that in an expression like p = a * a + b * b + c * c + d * d; there is quite a bit of parallelism: you can calculate the products simultaneously, and parts of the sum as well. But most languages don't let us specify that we want things done this way. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 25 12:05:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhF9-0004Cz-00 for ; Tue, 26 Feb 2002 14:02:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:02:07 +0100 (CET) Received: (qmail 360 invoked by uid 0); 25 Feb 2002 22:53:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 25 Feb 2002 22:53:35 -0000 Received: by moria.seul.org (Postfix) id 41CD5146811; Mon, 25 Feb 2002 17:53:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26C9514681B; Mon, 25 Feb 2002 17:53:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a067.home.uni-hannover.de [130.75.232.67]) by moria.seul.org (Postfix) with ESMTP id 4EAA7146811 for ; Mon, 25 Feb 2002 17:53:31 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00464; Mon, 25 Feb 2002 12:05:29 +0100 Message-ID: <20020225120529.24605@thrai.stud.uni-hannover.de> Date: Mon, 25 Feb 2002 12:05:29 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C797B93.29C4FA28@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Feb 25, 2002 at 08:07:25AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 25, 2002 at 08:07:25AM +0100, Juergen Goeritz wrote: [...] > from my experience the software stuff always is at least > one or two generations behind hardware things. My concerns > about f-cpu are also related to development of the compiler > tool kit. Is there a document where the compiler writers > can get an idea about the rules for generation of good and > efficient code? It's all in the manual. If it's not there, it's currently nowhere (except in someones head, maybe). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Feb 25 12:03:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16fhF9-0004Cz-01 for ; Tue, 26 Feb 2002 14:02:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Feb 2002 14:02:07 +0100 (CET) Received: (qmail 10603 invoked by uid 0); 25 Feb 2002 22:53:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 25 Feb 2002 22:53:39 -0000 Received: by moria.seul.org (Postfix) id 636D9146820; Mon, 25 Feb 2002 17:53:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6132214681D; Mon, 25 Feb 2002 17:53:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a067.home.uni-hannover.de [130.75.232.67]) by moria.seul.org (Postfix) with ESMTP id CC69414681B for ; Mon, 25 Feb 2002 17:53:33 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00455; Mon, 25 Feb 2002 12:03:13 +0100 Message-ID: <20020225120313.47501@thrai.stud.uni-hannover.de> Date: Mon, 25 Feb 2002 12:03:13 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU invited at the Libre Software Meeting References: <3C797B93.29C4FA28@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C797B93.29C4FA28@f-cpu.org>; from Yann Guidon on Mon, Feb 25, 2002 at 12:47:31AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Feb 25, 2002 at 12:47:31AM +0100, Yann Guidon wrote: [...] > I have the feeling that GCC will make really slow programs. Yep. Just compare gcc with Intel's compilers for Linux on i386. Then add the fact that gcc is unable to exploit parallelism, and you'll get the idea... > while the superpipeline can reach a somewhat higher frequency, > an inadequate compiler makes the system work really slow. > i fear that this constatation can be used as an argument > against the project. The same argument can be used against a lot of CPUs. E.g. an UltraSPARC-III really dies in benchmarks when the compiler isn't optimizing well (the only usable one seems to be Suns Forte 6 Update 2). > PS: anybody knows whether he comes to the LSM ? Depends on time, money and the way I feel. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 12:20:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVa-0000dN-01 for ; Thu, 28 Feb 2002 18:38:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:22 +0100 (CET) Received: (qmail 31374 invoked by uid 0); 28 Feb 2002 11:34:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 28 Feb 2002 11:34:55 -0000 Received: by moria.seul.org (Postfix) id EDB43146809; Thu, 28 Feb 2002 06:34:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFDC7146820; Thu, 28 Feb 2002 06:34:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 4CC75146809 for ; Thu, 28 Feb 2002 06:34:54 -0500 (EST) Received: from ifurita (212.194.213.223) by mail.laposte.net (5.5.044) id 3C4C02590026FC16 for f-cpu@seul.org; Thu, 28 Feb 2002 12:34:53 +0100 Message-ID: <001d01c1c049$fc10f580$dfd5c2d4@ifurita> From: "Christophe" To: Subject: [f-cpu] Why the Hell didn't I get those emails whereas I'm registered on this mailing-list !? Date: Thu, 28 Feb 2002 12:20:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 12:21:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVb-0000dN-00 for ; Thu, 28 Feb 2002 18:38:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:23 +0100 (CET) Received: (qmail 5023 invoked by uid 0); 28 Feb 2002 11:35:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 28 Feb 2002 11:35:33 -0000 Received: by moria.seul.org (Postfix) id A55E2146816; Thu, 28 Feb 2002 06:35:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EC2E14684E; Thu, 28 Feb 2002 06:35:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 5889E146816 for ; Thu, 28 Feb 2002 06:35:32 -0500 (EST) Received: from ifurita (212.194.213.223) by mail.laposte.net (5.5.044) id 3C4C02590026FC3F for f-cpu@seul.org; Thu, 28 Feb 2002 12:35:31 +0100 Message-ID: <002301c1c04a$12fbf6a0$dfd5c2d4@ifurita> From: "Christophe" To: References: <001d01c1c049$fc10f580$dfd5c2d4@ifurita> Subject: Re: [f-cpu] Why the Hell didn't I get those emails whereas I'm registered on this mailing-list !? Date: Thu, 28 Feb 2002 12:21:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Humm, good it works now ! ----- Original Message ----- From: Christophe To: Sent: Thursday, February 28, 2002 12:20 PM Subject: [f-cpu] Why the Hell didn't I get those emails whereas I'm registered on this mailing-list !? > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 15:09:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVj-0000dN-00 for ; Thu, 28 Feb 2002 18:38:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:31 +0100 (CET) Received: (qmail 2246 invoked by uid 0); 28 Feb 2002 14:23:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 28 Feb 2002 14:23:30 -0000 Received: by moria.seul.org (Postfix) id F2AEF146816; Thu, 28 Feb 2002 09:23:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB3FA14684E; Thu, 28 Feb 2002 09:23:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 9BF50146816 for ; Thu, 28 Feb 2002 09:23:28 -0500 (EST) Received: from ifurita (212.194.225.177) by mail.laposte.net (5.5.044) id 3C4C353900280BCF for f-cpu@seul.org; Thu, 28 Feb 2002 15:23:28 +0100 Message-ID: <000901c1c061$872082a0$b1e1c2d4@ifurita> From: "Christophe" To: Subject: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 15:09:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Virtual or physical addressing ? ------------------------------------------- (1) virtually-addressed caches (virtual tags) + do address translation only on a cache miss + faster for hits because no address translation - cache flushing on a context switch (example : local data segments will get an erronous hit for virtual addresses already cached after changing virtual address space, if no cache flushing). - synonym problem (several different virtual addresses cannot span the same physical addresses without being dupplicated in cache). (2) physically-addressed caches (physical tags) - do virtual-to-physical address translation on every access - increase in hit time because must translate the virtual address before access the cache + no cache flushing on a context switch + no synonym problem (several different virtual addresses can span the same physical addresses : a much better hit ratio between processes) (3) virtually-addressed caches (physical tags) + address translation in parallel with cache access + same fast hit time as a virtual cache : increase in hit time can be avoided because address translation is done in parallel with the cache access - restrict cache size so that cache index bits shall be in the page offset (page offset bits are the same for virtual & physical addresses) - compare the physical tag from the cache to the physical address (page frame #) from the TLB - If the cache is too small, only can increase cache size, but still use page offset bits for the index, by increasing associativity + no cache flushing on a context switch + no synonym problem (several different virtual addresses can span the same physical addresses : a much better hit ratio between processes) Conclusion - which one is better ? ---------------------------------------------- Well, for a FCPU-based machine where there are plenty of processes using a lot of copy-on-write data segment (same virtual addresses but maybe-different physically addresses) and dynamic library code segment (same physically addresses, different virtually addresses), (2)-type and (3)-type caches would have globally a better hit ratio than (1)-type cache. (2)-type cache is simpler than (3)-type cache but the latter offers the best we can find in (1)-type and (2)-type caches. /christophe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Thu Feb 28 15:58:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVp-0000dN-00 for ; Thu, 28 Feb 2002 18:38:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:37 +0100 (CET) Received: (qmail 13702 invoked by uid 0); 28 Feb 2002 14:58:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 28 Feb 2002 14:58:26 -0000 Received: by moria.seul.org (Postfix) id ABF9114685B; Thu, 28 Feb 2002 09:58:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A813814684E; Thu, 28 Feb 2002 09:58:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id DF0EB146816 for ; Thu, 28 Feb 2002 09:58:23 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g1SEwMT29624 for ; Thu, 28 Feb 2002 15:58:22 +0100 Message-ID: <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 15:58:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > Virtual or physical addressing ? > ------------------------------------------- > (1) virtually-addressed caches (virtual tags) > > + do address translation only on a cache miss > + faster for hits because no address translation Another plus to this method, its the only way to go with software managed address translation AFAICS. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 16:58:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVt-0000dN-00 for ; Thu, 28 Feb 2002 18:38:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:41 +0100 (CET) Received: (qmail 31509 invoked by uid 0); 28 Feb 2002 16:12:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 28 Feb 2002 16:12:54 -0000 Received: by moria.seul.org (Postfix) id 992AF1467E8; Thu, 28 Feb 2002 11:12:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80615146814; Thu, 28 Feb 2002 11:12:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 24AD61467E8 for ; Thu, 28 Feb 2002 11:12:52 -0500 (EST) Received: from ifurita (212.194.213.70) by mail.laposte.net (5.5.044) id 3C4C0259002758FA for f-cpu@seul.org; Thu, 28 Feb 2002 17:12:51 +0100 Message-ID: <001e01c1c070$d0e7b200$46d5c2d4@ifurita> From: "Christophe" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 16:58:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Marco Al To: Sent: Thursday, February 28, 2002 3:58 PM Subject: Re: [f-cpu] virtually or physically-addressed cache ? > Another plus to this method, its the only way to go with software managed > address translation AFAICS. > What does AFAICS stand for ? /christophe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Thu Feb 28 17:17:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVt-0000dN-02 for ; Thu, 28 Feb 2002 18:38:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:41 +0100 (CET) Received: (qmail 29136 invoked by uid 0); 28 Feb 2002 16:17:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 28 Feb 2002 16:17:19 -0000 Received: by moria.seul.org (Postfix) id B71E11467E8; Thu, 28 Feb 2002 11:17:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A5DE2146814; Thu, 28 Feb 2002 11:17:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id D70ED1467E8 for ; Thu, 28 Feb 2002 11:17:17 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g1SGHHX03287 for ; Thu, 28 Feb 2002 17:17:17 +0100 Message-ID: <003101c1c073$63fb4c30$bca45982@student.utwente.nl> From: "Marco Al" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <001e01c1c070$d0e7b200$46d5c2d4@ifurita> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 17:17:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > What does AFAICS stand for ? As Far As I Can See you could have looked it up faster on the web than composing that and pressing send :) Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Feb 28 17:21:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVu-0000dN-00 for ; Thu, 28 Feb 2002 18:38:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:42 +0100 (CET) Received: (qmail 22144 invoked by uid 0); 28 Feb 2002 16:21:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 28 Feb 2002 16:21:43 -0000 Received: by moria.seul.org (Postfix) id 2CD42146816; Thu, 28 Feb 2002 11:21:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 28EAA146814; Thu, 28 Feb 2002 11:21:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 5442D1467E8 for ; Thu, 28 Feb 2002 11:21:41 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200202281621.1d88; Thu, 28 Feb 2002 16:21:29 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Feb 2002 16:21:29 GMT Message-id: <200202281621.1d88@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I miss the first post from christophe. Where it is ? nicO -----Message d'origine----- De: "Marco Al" A: Date: 28/02/02 Objet: Re: [f-cpu] virtually or physically-addressed cache ?= =20 From: "Christophe" > Virtual or physical addressing ? > ------------------------------------------- > (1) virtually-addressed caches (virtual tags) > > + do address translation only on a cache miss > + faster for hits because no address translation Another plus to this method, its the only way to go with sof= tware managed address translation AFAICS. Marco ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Feb 28 17:38:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gUVu-0000dN-01 for ; Thu, 28 Feb 2002 18:38:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Feb 2002 18:38:42 +0100 (CET) Received: (qmail 8770 invoked by uid 0); 28 Feb 2002 16:33:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 28 Feb 2002 16:33:35 -0000 Received: by moria.seul.org (Postfix) id E204E146814; Thu, 28 Feb 2002 11:33:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE0831467EE; Thu, 28 Feb 2002 11:33:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 28BDA1467E8 for ; Thu, 28 Feb 2002 11:33:34 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16gTZO-0006CD-00 for f-cpu@seul.org; Thu, 28 Feb 2002 17:38:14 +0100 Date: Thu, 28 Feb 2002 17:38:14 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? In-Reply-To: <001e01c1c070$d0e7b200$46d5c2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 28 Feb 2002, Christophe wrote: > ----- Original Message ----- > From: Marco Al > To: > Sent: Thursday, February 28, 2002 3:58 PM > Subject: Re: [f-cpu] virtually or physically-addressed cache ? > > > Another plus to this method, its the only way to go with software managed > > address translation AFAICS. > > What does AFAICS stand for ? AFAIK as far as I know AFAICS as far as I can say hope this is correct JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Feb 28 18:32:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5B-0004nq-01 for ; Fri, 01 Mar 2002 00:35:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:29 +0100 (CET) Received: (qmail 32507 invoked by uid 0); 28 Feb 2002 17:27:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 28 Feb 2002 17:27:08 -0000 Received: by moria.seul.org (Postfix) id 3F57C1467E8; Thu, 28 Feb 2002 12:27:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A9D21467EE; Thu, 28 Feb 2002 12:27:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C89791467E8 for ; Thu, 28 Feb 2002 12:27:06 -0500 (EST) Received: from f-cpu.org (kdl16-15.n.club-internet.fr [213.44.18.15]) by relay-2v.club-internet.fr (Postfix) with ESMTP id A6BF5174D for ; Thu, 28 Feb 2002 18:27:03 +0100 (CET) Message-ID: <3C7E69A7.3C2576A1@f-cpu.org> Date: Thu, 28 Feb 2002 18:32:23 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <001e01c1c070$d0e7b200$46d5c2d4@ifurita> <003101c1c073$63fb4c30$bca45982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Marco Al wrote: > From: "Christophe" > > What does AFAICS stand for ? > As Far As I Can See you could have looked it up faster on the web than > composing that and pressing send :) but OTOH (On The Other Hand) you have the inner satisfaction to have contributed to the enhancement of our edducation :-) > Marco WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Feb 28 18:32:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5C-0004nq-00 for ; Fri, 01 Mar 2002 00:35:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:30 +0100 (CET) Received: (qmail 18259 invoked by uid 0); 28 Feb 2002 17:27:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 28 Feb 2002 17:27:11 -0000 Received: by moria.seul.org (Postfix) id C98BB146816; Thu, 28 Feb 2002 12:27:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C621C146814; Thu, 28 Feb 2002 12:27:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 6EABB1467EE for ; Thu, 28 Feb 2002 12:27:09 -0500 (EST) Received: from f-cpu.org (kdl16-15.n.club-internet.fr [213.44.18.15]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 92D69171E for ; Thu, 28 Feb 2002 18:27:06 +0100 (CET) Message-ID: <3C7E69AA.AC15B611@f-cpu.org> Date: Thu, 28 Feb 2002 18:32:26 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Marco Al wrote: > From: "Christophe" > > Virtual or physical addressing ? > > ------------------------------------------- > > (1) virtually-addressed caches (virtual tags) > > > > + do address translation only on a cache miss > > + faster for hits because no address translation > > Another plus to this method, its the only way to go with software managed > address translation AFAICS. ????? Currently i plan and design a physically-addressed cache (2). It adds a translation cycle but i don't see any other problem. And since it is pipelined and the pipeline splits the operation (access and addressing), the TLB lookup is not inside the visible software latency (unless you program badly). i do not understand the (3) version. I prefer to stick with (2) because in case of simultaneous access of the memories by different devices, the overhead is reduced. More precisely, the memory hierarchy in a multi-CPU system is globally/physically addressed but distributed among the CPU : each CPU has a "private" RAM range (allocated during bootup) and when it wants to access a location outside of its private range, it goes through the interconnexion network. The CPU can thus be seen as a "node" where there is a concentration of several data flows : interco, L1, L2, private RAM, CPU and even (why not ?) HDD interface or some kind of I/O. All these flows must work with the same addressing system or it is going to introduce problems. In the SMP (usually, dual-CPU) PCs, it makes sense to have snooped caches because one CPU can be master of the SMP bus at a time. But when there are tens or thousands of CPUs (some HPC monsters have 10K CPUs), it is not possible to have MESI-like protocol because there is no bus to snoop ! A bus is impossible to setup : we need a "network", with packets containing the destination address in the header, so we can route the packet through the network. Usually, it is a "flat tree" or "omega network" or "hypercube" or whatever. When the CPU node receives a packet that requests a memory access (read or write), the CPU knows that he is the destination because otherwise, the packet would be routed elsewhere. Then it has to know where the requested address is mapped : L1, L2, SDRAM ? working with "physical" addresses removes a TLB and all the risks of aliasing, as well as removing all need to take countermeasures. Concerning the cost of physical addressing from the CPU point of view, i think i have found a way to reduce the cost to this of flat addressing (ie in "kernel mode" when there is no TLB access). This also simplifies the pipeline scheduler because there is no need to modify the timing : kernel mode and vritual-addessed mode take the same time. The big disadvantage is that it works better with only one page granularity :-/ more on this later. > Marco WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Thu Feb 28 18:55:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5E-0004nq-00 for ; Fri, 01 Mar 2002 00:35:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:32 +0100 (CET) Received: (qmail 16551 invoked by uid 0); 28 Feb 2002 17:55:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 28 Feb 2002 17:55:44 -0000 Received: by moria.seul.org (Postfix) id 95442146819; Thu, 28 Feb 2002 12:55:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8FC3A146816; Thu, 28 Feb 2002 12:55:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id C82A21467E8 for ; Thu, 28 Feb 2002 12:55:42 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g1SHtgM12170 for ; Thu, 28 Feb 2002 18:55:42 +0100 Message-ID: <001101c1c081$23b56850$bca45982@student.utwente.nl> From: "Marco Al" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <3C7E69AA.AC15B611@f-cpu.org> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 18:55:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Yann Guidon" > Marco Al wrote: > > From: "Christophe" > > > Virtual or physical addressing ? > > > ------------------------------------------- > > > (1) virtually-addressed caches (virtual tags) > > > > > > + do address translation only on a cache miss > > > + faster for hits because no address translation > > > > Another plus to this method, its the only way to go with software managed > > address translation AFAICS. > > ????? > > Currently i plan and design a physically-addressed cache (2). > It adds a translation cycle but i don't see any other problem. > And since it is pipelined and the pipeline splits the operation > (access and addressing), the TLB lookup is not inside the visible > software latency (unless you program badly). Sotfware managed address translation does not need to use a TLB as such (if you think about it a bit you will see that thats possible, given the 2 first plus's). I would think that would appeal to your minimalistic side :) There will always be algorithms which can not avoid deep pointer chasing, however well implemented. Im sure there are plenty of other realistic cases where the latency of memory access even on cache hit can be a bottleneck, numerical computations with nice straightforward structure is not exactly something most desktop processors spend much time doing ... Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 19:49:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5F-0004nq-00 for ; Fri, 01 Mar 2002 00:35:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:33 +0100 (CET) Received: (qmail 17450 invoked by uid 0); 28 Feb 2002 19:05:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 28 Feb 2002 19:05:20 -0000 Received: by moria.seul.org (Postfix) id 067A414680F; Thu, 28 Feb 2002 14:05:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0D75146816; Thu, 28 Feb 2002 14:05:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 82BB014680F for ; Thu, 28 Feb 2002 14:05:18 -0500 (EST) Received: from ifurita (212.194.222.184) by mail.laposte.net (5.5.044) id 3C4BFED40028E13B for f-cpu@seul.org; Thu, 28 Feb 2002 20:05:18 +0100 Message-ID: <000401c1c088$e74db7c0$b8dec2d4@ifurita> From: "Christophe" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <3C7E69AA.AC15B611@f-cpu.org> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 19:49:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Thursday, February 28, 2002 6:32 PM Subject: Re: [f-cpu] virtually or physically-addressed cache ? > hi, > > Marco Al wrote: > > From: "Christophe" > > > Virtual or physical addressing ? > > > ------------------------------------------- > > > (1) virtually-addressed caches (virtual tags) > > > > > > + do address translation only on a cache miss > > > + faster for hits because no address translation > > > > Another plus to this method, its the only way to go with software managed > > address translation AFAICS. But what happens if we have a L1 hit and get in fact a TLB miss (invalidation, read-only, etc.) ? our TBL would need to flush L1 to be synched with TLB before resuming the faulty instruction after a TLB exception. An exception must occur to validate our TLB with the right physical address for the faulty virtual address; at the end of exception, the faulty code may resume to access the virtual address back with success this time. So I don't see any difficulties with software managed address translation since L1 is not valid until the faulty code resumes. > > ????? > > Currently i plan and design a physically-addressed cache (2). > It adds a translation cycle but i don't see any other problem. > And since it is pipelined and the pipeline splits the operation > (access and addressing), the TLB lookup is not inside the visible > software latency (unless you program badly). I'm rather looking first for a physically-addressed cache with physical tags. A virtually-addressed cache but with physical tags (TLB translation works in parallel way to give us physical tags if any) could be very interesting and apparently a lot of race-cpu use it. But there is one thing I'm not sure : what happens with different virtual addresses spanning the same physical address ? I must find more info about this third cache type. > I prefer to stick with (2) because in case of simultaneous access > of the memories by different devices, the overhead is reduced. > More precisely, the memory hierarchy in a multi-CPU system is > globally/physically addressed but distributed among the CPU : > each CPU has a "private" RAM range (allocated during bootup) > and when it wants to access a location outside of its private range, > it goes through the interconnexion network. I aggree. > Concerning the cost of physical addressing from the CPU point of view, > i think i have found a way to reduce the cost to this of flat addressing > (ie in "kernel mode" when there is no TLB access). This also simplifies > the pipeline scheduler because there is no need to modify the timing : > kernel mode and vritual-addessed mode take the same time. > The big disadvantage is that it works better with only one page granularity :-/ Kernel mode is only no-paging !? oh bad !!!!! how can I transfer data to user memory (virtual addresses) when i'm in kernel mode !? Must I use a function to translate a virtual address to a physical address !? hey !!! if I have 16 pages to copy I must translate 16 times !?! whereas if kernel mode can handle virtual address space (so it should be able to use TLB), I would just need to do a memcpy (or user_memcpy for Linux hacker). /christophe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Feb 28 20:04:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5G-0004nq-00 for ; Fri, 01 Mar 2002 00:35:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:34 +0100 (CET) Received: (qmail 10728 invoked by uid 0); 28 Feb 2002 19:18:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 28 Feb 2002 19:18:19 -0000 Received: by moria.seul.org (Postfix) id CD7021467E9; Thu, 28 Feb 2002 14:18:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1FF514680F; Thu, 28 Feb 2002 14:18:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 5A0D41467E9 for ; Thu, 28 Feb 2002 14:18:18 -0500 (EST) Received: from ifurita (212.194.222.184) by mail.laposte.net (5.5.044) id 3C4BFED40028E4F5 for f-cpu@seul.org; Thu, 28 Feb 2002 20:18:17 +0100 Message-ID: <000e01c1c08a$b879e2a0$b8dec2d4@ifurita> From: "Christophe" To: Subject: [f-cpu] TLB,L1 Date: Thu, 28 Feb 2002 20:04:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N For example, I read for one pdf I donwloaded : Alpha 21164 virtual index virtual tags (icache), physical tags (dcache) TLB in parallel write-back (dcache) Pentium Pro virtual index physical tags (icache,dcache) TLB in parallel write-back (dcache) UltraSparc 1 virtual index virtual tags (icache), physical tags (dcache) TLB in parallel write-through,store compression (dcache) It looks like they prefer the virtually-addressed cache with physical tags for dcache. /christophe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Feb 28 21:18:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga5I-0004nq-00 for ; Fri, 01 Mar 2002 00:35:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:35:36 +0100 (CET) Received: (qmail 3994 invoked by uid 0); 28 Feb 2002 20:18:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 28 Feb 2002 20:18:08 -0000 Received: by moria.seul.org (Postfix) id 93E7814680F; Thu, 28 Feb 2002 15:18:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7DE1C146819; Thu, 28 Feb 2002 15:18:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 2056D14680F for ; Thu, 28 Feb 2002 15:18:07 -0500 (EST) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-2.free.fr (Postfix) with ESMTP id 890145F7C6 for ; Thu, 28 Feb 2002 21:18:06 +0100 (CET) Received: by imp2-2.free.fr (Postfix, from userid 33) id 8201B8C187; Thu, 28 Feb 2002 21:18:06 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? Message-ID: <1014927486.3c7e907e77ed4@imp.free.fr> Date: Thu, 28 Feb 2002 21:18:06 +0100 (MET) From: Cedric BAIL References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <3C7E69AA.AC15B611@f-cpu.org> <000401c1c088$e74db7c0$b8dec2d4@ifurita> In-Reply-To: <000401c1c088$e74db7c0$b8dec2d4@ifurita> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 193.251.4.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > > Concerning the cost of physical addressing from the CPU point of view, > > i think i have found a way to reduce the cost to this of flat addressing > > (ie in "kernel mode" when there is no TLB access). This also simplifies > > the pipeline scheduler because there is no need to modify the timing : > > kernel mode and vritual-addessed mode take the same time. > > The big disadvantage is that it works better with only one page > > granularity :-/ > Kernel mode is only no-paging !? oh bad !!!!! how can I transfer data to > user memory (virtual addresses) when i'm in kernel mode !? Must I use a > function to translate a virtual address to a physical address !? hey !!! if > I have 16 pages to copy I must translate 16 times !?! whereas if kernel > mode can handle virtual address space (so it should be able to use TLB), I > would just need to do a memcpy (or user_memcpy for Linux hacker). And what about a SR that active/unactivate the TLB when you are in kernel mode ? That should be enough and not to difficult to implement, no ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Feb 28 21:58:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga6U-0004nq-00 for ; Fri, 01 Mar 2002 00:36:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:36:50 +0100 (CET) Received: (qmail 4475 invoked by uid 0); 28 Feb 2002 20:58:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 28 Feb 2002 20:58:03 -0000 Received: by moria.seul.org (Postfix) id 07F9214680F; Thu, 28 Feb 2002 15:58:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0040146816; Thu, 28 Feb 2002 15:58:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 8EFA814680F for ; Thu, 28 Feb 2002 15:58:02 -0500 (EST) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-1.free.fr (Postfix) with ESMTP id EE38F347 for ; Thu, 28 Feb 2002 21:58:01 +0100 (CET) Received: by imp2-1.free.fr (Postfix, from userid 33) id DBC865829C; Thu, 28 Feb 2002 21:58:01 +0100 (MET) To: f-cpu@seul.org Message-ID: <1014929881.3c7e99d9aa752@imp.free.fr> Date: Thu, 28 Feb 2002 21:58:01 +0100 (MET) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 193.251.4.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi I think that it was not too obvious for the lsm in Bordeau. The idea is to have some conferences for newbee, but that's not all. We can do some really technical discussion about some parts of the F-CPU like an LSU conference, IRQ, DMA or whatever you wan't about the F-CPU (software or hardware). Theses conference's topic can be some parts that are not actually decided and it can be a start for a finishing the manual ;-) We must provide a list of conferences that will be done, and the number of people that could came. I have started to write down an up to date manual, so I download the CVS... Well, it take too much time for my modem, it's why I think that it could be a good idea to split the CVS in some module like : VHDL, manual, www-org, www-de, ... (if we are not alone on this CVS, we could add a f-cpu prefix). I think it would be more easy to maintain and we can assigne a maintainer for each part of the CVS's module so that it could dynamise the use of the CVS. What do you thing about this idea ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Thu Feb 28 22:00:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga6W-0004nq-00 for ; Fri, 01 Mar 2002 00:36:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:36:52 +0100 (CET) Received: (qmail 6024 invoked by uid 0); 28 Feb 2002 21:00:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 28 Feb 2002 21:00:23 -0000 Received: by moria.seul.org (Postfix) id 5044A146844; Thu, 28 Feb 2002 16:00:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4DE44146820; Thu, 28 Feb 2002 16:00:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 33573146816 for ; Thu, 28 Feb 2002 16:00:21 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g1SL0KM21425 for ; Thu, 28 Feb 2002 22:00:20 +0100 Message-ID: <003401c1c09a$ef119cd0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <3C7E69AA.AC15B611@f-cpu.org> <000401c1c088$e74db7c0$b8dec2d4@ifurita> Subject: Re: [f-cpu] virtually or physically-addressed cache ? Date: Thu, 28 Feb 2002 22:00:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > Marco Al wrote: > > From: "Christophe" > > > Virtual or physical addressing ? > > > ------------------------------------------- > > > (1) virtually-addressed caches (virtual tags) > > > > > > + do address translation only on a cache miss > > > + faster for hits because no address translation > > > > Another plus to this method, its the only way to go with software > > managed address translation AFAICS. > > But what happens if we have a L1 hit and get in fact a TLB miss > (invalidation, read-only, etc.) ? our TBL would need to flush L1 to be > synched with TLB before resuming the faulty instruction after a TLB > exception. There would not be a TLB as such, it wouldnt be software managed address translation otherwise. For protection you probably want per cacheline protection bits. Invalidation is simular to changing protection I guess ... see section 5.6 of the paper "Uniprocessor virtual memory without TLBs." at http://www.ee.umd.edu/~blj/ A naive implementation would have some "issues" obviously. For instance without a shared global address space you have to flush the cache on context switches, and even with it you probably wouldnt want to walk the cache to change protection bits every time you made a switch. The paper mentions a lot of problems and potential solutions. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Feb 28 22:11:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ga6X-0004nq-00 for ; Fri, 01 Mar 2002 00:36:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 00:36:53 +0100 (CET) Received: (qmail 10662 invoked by uid 0); 28 Feb 2002 21:06:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 28 Feb 2002 21:06:32 -0000 Received: by moria.seul.org (Postfix) id 0E0AB14680F; Thu, 28 Feb 2002 16:06:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E29D4146819; Thu, 28 Feb 2002 16:06:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id EDA7B14680F for ; Thu, 28 Feb 2002 16:06:28 -0500 (EST) Received: from f-cpu.org (kdl16-205.n.club-internet.fr [213.44.18.205]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 5869916F1 for ; Thu, 28 Feb 2002 22:06:24 +0100 (CET) Message-ID: <3C7E9D0F.6AA6FB38@f-cpu.org> Date: Thu, 28 Feb 2002 22:11:43 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <006e01c1c068$5de4c4d0$bca45982@student.utwente.nl> <3C7E69AA.AC15B611@f-cpu.org> <000401c1c088$e74db7c0$b8dec2d4@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Christophe wrote: > From: Yann Guidon > > Marco Al wrote: > > > From: "Christophe" > > > > Virtual or physical addressing ? > > > > ------------------------------------------- > > > > (1) virtually-addressed caches (virtual tags) > > > > > > > > + do address translation only on a cache miss > > > > + faster for hits because no address translation > > > > > > Another plus to this method, its the only way to go with software managed > > > address translation AFAICS. > > But what happens if we have a L1 hit and get in fact a TLB miss > (invalidation, read-only, etc.) ? our TBL would need to flush L1 to be > synched with TLB before resuming the faulty instruction after a TLB > exception. > > An exception must occur to validate our TLB with the right physical address > for the faulty virtual address; at the end of exception, the faulty code may > resume to access the virtual address back with success this time. So I don't > see any difficulties with software managed address translation since L1 is > not valid until the faulty code resumes. fortunately, with the split address/access method in FC0, this is not a big problem. > > ????? > > > > Currently i plan and design a physically-addressed cache (2). > > It adds a translation cycle but i don't see any other problem. > > And since it is pipelined and the pipeline splits the operation > > (access and addressing), the TLB lookup is not inside the visible > > software latency (unless you program badly). > > I'm rather looking first for a physically-addressed cache with physical > tags. i presume that i have a _little_ (hmmm) vocabulary problem. what is the difference between physical tags and physical addressing ?... currently i work in the following way : the application SW works with "virtual/logical" addresses that are translated by the TLB to "physical" addresses when going outside of the execution pipeline. So the L1 tags are physical. > A virtually-addressed cache but with physical tags (TLB translation works in > parallel way to give us physical tags if any) could be very interesting and > apparently a lot of race-cpu use it. i don't understand exactly what it means... > But there is one thing I'm not sure : > what happens with different virtual addresses spanning the same physical > address ? I must find more info about this third cache type. and i'll gladly read your links and comments. > > Concerning the cost of physical addressing from the CPU point of view, > > i think i have found a way to reduce the cost to this of flat addressing > > (ie in "kernel mode" when there is no TLB access). This also simplifies > > the pipeline scheduler because there is no need to modify the timing : > > kernel mode and vritual-addessed mode take the same time. > > The big disadvantage is that it works better with only one page > > granularity :-/ > > Kernel mode is only no-paging !? oh bad !!!!! i didn't write "only". it just runs in "physical addressing mode/no TLB" for the bootstrap and the IRQ. no big problem about that. If you have a HURD or Linux kernel, you can still create tasks (TLB entries) for specific code sections of the kernel, so you can swap them out. However, the bootstrap is later overwritten, and the IRQ/trap/syscall handlers are not likely to be swapped easily, otherwise the system could crash... > how can I transfer data to > user memory (virtual addresses) when i'm in kernel mode !? as simply as in creating a TLB entry that points to the physical location of the data, give the pointer to the task/process and voilà. why do you seek complex problems ? :-) > Must I use a > function to translate a virtual address to a physical address !? hey !!! it's the other direction : kernel will give the pointer, the userland process will access the data through the new TLB entry. If the kernel pre-loads the TLB entry, it's even faster (no trap on access). > if I have 16 pages to copy I must translate 16 times !?! you mean copy "as in block copy" ? why would you do that ? > whereas if kernel mode > can handle virtual address space (so it should be able to use TLB), I would > just need to do a memcpy (or user_memcpy for Linux hacker). kernel parts can be "virtualised", of course : their CMB (process descriptor) would have all the enable bits on, or at least those which are necessary (to help prevent security problems or bug propagation). but this is not necessary. > /christophe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Fri Mar 1 00:08:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gagI-0005Hk-00 for ; Fri, 01 Mar 2002 01:13:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 01:13:50 +0100 (CET) Received: (qmail 24004 invoked by uid 0); 28 Feb 2002 23:12:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Feb 2002 23:12:59 -0000 Received: by moria.seul.org (Postfix) id 7256D146814; Thu, 28 Feb 2002 18:12:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 581FB146819; Thu, 28 Feb 2002 18:12:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id 98A24146814 for ; Thu, 28 Feb 2002 18:12:56 -0500 (EST) Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 16gZfO-0007ix-00; Fri, 01 Mar 2002 00:08:50 +0100 Date: Fri, 1 Mar 2002 00:08:50 +0100 From: Paul Marques Mota To: f-cpu@seul.org Subject: [f-cpu] Re: your mail Message-ID: <20020301000850.B1439@opium.april.org> Mail-Followup-To: Paul Marques Mota , f-cpu@seul.org References: <1014929881.3c7e99d9aa752@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014929881.3c7e99d9aa752@imp.free.fr>; from cedric.bail@free.fr on Thu, Feb 28, 2002 at 09:58:01PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Feb 28, 2002 at 09:58:01PM +0100, Cedric BAIL wrote: > Hi > > I think that it was not too obvious for the lsm in Bordeau. > The idea is to have some conferences for newbee, but that's not all. Does that mean you will manage the conferences? > We can do some really technical discussion about some parts of the > F-CPU like an LSU conference, IRQ, DMA or whatever you wan't > about the F-CPU (software or hardware). Theses conference's topic > can be some parts that are not actually decided and it can be a start > for a finishing the manual ;-) > We must provide a list of conferences that will be done, and the > number of people that could came. > a couple of random thoughts: - is it worthwhile to call it "Free Hardware" instead of F-CPU and invite other projects as well? (I'm thinking about geda but there are certainly more) - there have been a lot of discutions on the french mailing-list about creating a french association. I think it should be delayed after the LSM so that foreign developpers can be involved too. > I have started to write down an up to date manual, so I download > the CVS... Well, it take too much time for my modem, You should ask for an account on seul.org; they are _not_ on a modem link :) > it's why I think > that it could be a good idea to split the CVS in some module like : > VHDL, manual, www-org, www-de, ... (if we are not alone on this CVS, We are. > we could add a f-cpu prefix). I think it would be more easy to maintain > and we can assigne a maintainer for each part of the CVS's module so that IMHO, I think it would slow down development; and cvs gives you the oportunity to recreate the previous state of the file if you make mistakes. > it could dynamise the use of the CVS. What do you thing about this idea ? > Just do it. Ask the cvs admin (Andreas Romeyke, IIRC) an account and then update the file CVSROOT/modules > A+ > Cedric -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 1 11:48:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gvWV-0000G5-00 for ; Fri, 01 Mar 2002 23:29:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 01 Mar 2002 23:29:07 +0100 (CET) Received: (qmail 7139 invoked by uid 0); 1 Mar 2002 20:05:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 1 Mar 2002 20:05:05 -0000 Received: by moria.seul.org (Postfix) id 46CEC146819; Fri, 1 Mar 2002 15:05:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A69114685B; Fri, 1 Mar 2002 15:05:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a220.home.uni-hannover.de [130.75.232.220]) by moria.seul.org (Postfix) with ESMTP id 261B5146819 for ; Fri, 1 Mar 2002 15:05:02 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00604; Fri, 1 Mar 2002 11:48:07 +0100 Message-ID: <20020301114807.18096@thrai.stud.uni-hannover.de> Date: Fri, 1 Mar 2002 11:48:07 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c061$872082a0$b1e1c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000901c1c061$872082a0$b1e1c2d4@ifurita>; from Christophe on Thu, Feb 28, 2002 at 03:09:23PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Feb 28, 2002 at 03:09:23PM +0100, Christophe wrote: > Virtual or physical addressing ? > ------------------------------------------- > (1) virtually-addressed caches (virtual tags) > > + do address translation only on a cache miss > + faster for hits because no address translation > - cache flushing on a context switch (example : local data segments will get > an erronous hit for virtual addresses already cached after changing virtual > address space, if no cache flushing). > - synonym problem (several different virtual addresses cannot span the same > physical addresses without being dupplicated in cache). Abgelehnt. This one causes severe problems. > (2) physically-addressed caches (physical tags) > > - do virtual-to-physical address translation on every access Not necessarily. The TLB lookup can be started as soon as loadaddr (or one of its variants) is called, and doesn't have to be repeated in all cases (e.g. with a postincremented pointer, you'll perform a range check first and only do a full lookup if the range check fails). > - increase in hit time because must translate the virtual address before > access the cache See above - the LSU may cache the results of the TLB lookup. > + no cache flushing on a context switch > + no synonym problem (several different virtual addresses can span the same > physical addresses : a much better hit ratio between processes) Looks fine. > (3) virtually-addressed caches (physical tags) > > + address translation in parallel with cache access > + same fast hit time as a virtual cache : increase in hit time can be > avoided because address translation is done in parallel with the cache > access > - restrict cache size so that cache index bits shall be in the page offset > (page offset bits are the same for virtual & physical addresses) > - compare the physical tag from the cache to the physical address (page > frame #) from the TLB > - If the cache is too small, only can increase cache size, but still use > page offset bits for the index, by increasing associativity This may become *very* hairy with variable page size. We'd have to use the minimum page size (1K? 4K?) on order to keep it simple. That's only 10...12 index bits (and probably 128-way or more). > + no cache flushing on a context switch > + no synonym problem (several different virtual addresses can span the same > physical addresses : a much better hit ratio between processes) > > Conclusion - which one is better ? I prefer (2), for the moment. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 1 23:18:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gwhr-0001Io-01 for ; Sat, 02 Mar 2002 00:44:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 02 Mar 2002 00:44:55 +0100 (CET) Received: (qmail 19235 invoked by uid 0); 1 Mar 2002 22:13:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 1 Mar 2002 22:13:16 -0000 Received: by moria.seul.org (Postfix) id 83EDE1467FF; Fri, 1 Mar 2002 17:13:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78EFC146849; Fri, 1 Mar 2002 17:13:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4FDAC1467FF for ; Fri, 1 Mar 2002 17:13:13 -0500 (EST) Received: from f-cpu.org (kdl21-39.n.club-internet.fr [213.44.96.39]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5253A1683 for ; Fri, 1 Mar 2002 23:13:09 +0100 (CET) Message-ID: <3C7FFE32.A41C6BD0@f-cpu.org> Date: Fri, 01 Mar 2002 23:18:26 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c061$872082a0$b1e1c2d4@ifurita> <20020301114807.18096@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael Riepe wrote: > On Thu, Feb 28, 2002 at 03:09:23PM +0100, Christophe wrote: > > Virtual or physical addressing ? > > ------------------------------------------- > > (1) virtually-addressed caches (virtual tags) > > > > + do address translation only on a cache miss > > + faster for hits because no address translation > > - cache flushing on a context switch (example : local data segments will get > > an erronous hit for virtual addresses already cached after changing virtual > > address space, if no cache flushing). > > - synonym problem (several different virtual addresses cannot span the same > > physical addresses without being dupplicated in cache). > Abgelehnt. This one causes severe problems. however it is interesting to see that it is a characteristic divergence between the SW and the HW guys. > > (2) physically-addressed caches (physical tags) > > > > - do virtual-to-physical address translation on every access > > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > one of its variants) is called, and doesn't have to be repeated in all > cases (e.g. with a postincremented pointer, you'll perform a range check > first and only do a full lookup if the range check fails). right. > > - increase in hit time because must translate the virtual address before > > access the cache > See above - the LSU may cache the results of the TLB lookup. The caching does not reduce the latency, so you can be proved wrong. However, you are right in saying that the LSU caches the TLB lookup : the Load/Store Unit has to store both the physical and logical addresses of each line. But one can remark that the logical and physical addresses differ only by the MSB, so we only store the diverging parts. And this part is necessarily also present in the TLB ! This means that there is a link of some sort between the LSU and the TLB, both reducing the amount of memory (and address comparators) and the latency. -------------------------------------------------------------------------------- Here i will explain how the LSU and the TLB work hand in hand, both in physical and virtual mode. I will assume (for simplicity) that we have a 4KB page system only (it's only for the explanation, because several page sizes are wanted). When a new address is available (from the Xbar or the ASU output), it is sent to both the LSU and the TLB. The new address (physical or virtual does not matter, with this scheme) is split into 2 parts : the index in the page (a 12-bit number) and the page number (the rest of the address field, which is configurable and implementation-dependent [you can configure it to 16 bits, 32 bits or anything you need]). The index is truncated because the LSU lines are 256-bit long, only 7 bits are kept. This part of the address is compared with the corresponding parts in the LSU (this means : the 8 lines). This is a rather simple part, no ? Then it becomes a bit more complex. The remaining part of the address is sent to both the LSU and TLB for comparison. - For the LSU lines, it is simple : if there is a hit on both the LSB (compared above) and the MSB, there is a hit on the line. - For the TLB : if there is a hit on a TLB entry, then we have to know which LSU line is "connected" to this entry. There are 8 flags, one for each LSU line. Each of these flags will validate the corresponding LSB hit on the LSU lines. Finally, there is a MUX that selects the "hit" output, depending on the operating mode (virtual or physical addressing). You understand that where several page sizes are necessary, the mechanism is a bit more complex, but it's still feasible (but at what cost ?) I should make a drawing, now. -------------------------------------------------------------------------------- > > + no cache flushing on a context switch > > + no synonym problem (several different virtual addresses can span the same > > physical addresses : a much better hit ratio between processes) > Looks fine. these are also important factors for me. > > Conclusion - which one is better ? > I prefer (2), for the moment. i'll stick with that, too. but of course, this could evolve at an unknown rate. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Mar 2 00:27:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gzHE-0003CA-00 for ; Sat, 02 Mar 2002 03:29:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 02 Mar 2002 03:29:36 +0100 (CET) Received: (qmail 31560 invoked by uid 0); 1 Mar 2002 23:27:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 1 Mar 2002 23:27:32 -0000 Received: by moria.seul.org (Postfix) id E6EC414684E; Fri, 1 Mar 2002 18:27:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCA8D146849; Fri, 1 Mar 2002 18:27:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 232EC1467FF for ; Fri, 1 Mar 2002 18:27:30 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203012327.0dec; Fri, 1 Mar 2002 23:27:13 GMT Send-By: 194.158.98.37 with Mozilla/4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) To: Subject: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Mar 2002 23:27:13 GMT Message-id: <200203012327.0dec@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 01/03/02 Objet: Re: [f-cpu] virtually or physically-addressed cache ? On Thu, Feb 28, 2002 at 03:09:23PM +0100, Christophe wrote: > Virtual or physical addressing ? > ------------------------------------------- > (1) virtually-addressed caches (virtual tags) >=20 > + do address translation only on a cache miss > + faster for hits because no address translation > - cache flushing on a context switch (example : local data= segments will get > an erronous hit for virtual addresses already cached after= changing virtual > address space, if no cache flushing). > - synonym problem (several different virtual addresses can= not span the same > physical addresses without being dupplicated in cache). Abgelehnt. This one causes severe problems. >>> Not really, it causes waste space, only ! > (2) physically-addressed caches (physical tags) >=20 > - do virtual-to-physical address translation on every acce= ss Not necessarily. The TLB lookup can be started as soon as lo= adaddr (or one of its variants) is called, and doesn't have to be repea= ted in all cases (e.g. with a postincremented pointer, you'll perform a= range check first and only do a full lookup if the range check fails). >>> Consider that the LSU is a kind of virtually addressed c= aches. > - increase in hit time because must translate the virtual = address before > access the cache See above - the LSU may cache the results of the TLB lookup. >>>See above, too ;p > + no cache flushing on a context switch > + no synonym problem (several different virtual addresses = can span the same > physical addresses : a much better hit ratio between proce= sses) Looks fine. > (3) virtually-addressed caches (physical tags) >=20 > + address translation in parallel with cache access > + same fast hit time as a virtual cache : increase in hit = time can be > avoided because address translation is done in parallel wi= th the cache > access > - restrict cache size so that cache index bits shall be in= the page offset > (page offset bits are the same for virtual & physical addr= esses) > - compare the physical tag from the cache to the physical = address (page > frame #) from the TLB > - If the cache is too small, only can increase cache size,= but still use > page offset bits for the index, by increasing associativit= y This may become *very* hairy with variable page size. We'd h= ave to use the minimum page size (1K? 4K?) on order to keep it simple. = That's only 10...12 index bits (and probably 128-way or more). > + no cache flushing on a context switch > + no synonym problem (several different virtual addresses = can span the same > physical addresses : a much better hit ratio between proce= sses) >=20 > Conclusion - which one is better ? I prefer (2), for the moment. >>> We should look more closely to the (3), too. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Mar 2 02:07:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16gzHJ-0003CA-00 for ; Sat, 02 Mar 2002 03:29:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 02 Mar 2002 03:29:41 +0100 (CET) Received: (qmail 28648 invoked by uid 0); 2 Mar 2002 01:02:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 2 Mar 2002 01:02:23 -0000 Received: by moria.seul.org (Postfix) id 07E711463AB; Fri, 1 Mar 2002 20:02:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00CCB1467FF; Fri, 1 Mar 2002 20:02:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 8C8E61463AB for ; Fri, 1 Mar 2002 20:02:20 -0500 (EST) Received: from f-cpu.org (kdl21-23.n.club-internet.fr [213.44.96.23]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 9440B16AB for ; Sat, 2 Mar 2002 02:02:15 +0100 (CET) Message-ID: <3C8025D4.86B47163@f-cpu.org> Date: Sat, 02 Mar 2002 02:07:32 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > > - synonym problem (several different virtual addresses cannot span the same > > physical addresses without being dupplicated in cache). > Abgelehnt. This one causes severe problems. > >>> Not really, it causes waste space, only ! i do not agree with "only". > > (2) physically-addressed caches (physical tags) > > - do virtual-to-physical address translation on every access > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > one of its variants) is called, and doesn't have to be repeated in all > cases (e.g. with a postincremented pointer, you'll perform a range check > first and only do a full lookup if the range check fails). > > >>> Consider that the LSU is a kind of virtually addressed caches. that's one perspective. > > (3) virtually-addressed caches (physical tags) > > > > + address translation in parallel with cache access > > + same fast hit time as a virtual cache : increase in hit time can be > > avoided because address translation is done in parallel with the cache access > > - restrict cache size so that cache index bits shall be in the page offset > > (page offset bits are the same for virtual & physical addresses) > > - compare the physical tag from the cache to the physical address (page > > frame #) from the TLB > > - If the cache is too small, only can increase cache size, but still use > > page offset bits for the index, by increasing associativity > > This may become *very* hairy with variable page size. We'd have to use > the minimum page size (1K? 4K?) on order to keep it simple. That's only > 10...12 index bits (and probably 128-way or more). > I prefer (2), for the moment. > > >>> We should look more closely to the (3), too. >from another point of view, the LSU+fetcher+TLB block works a bit with (3) unless i really have understood nothing at all. After having read some documents yesterday about VM, i'm thinking about how to enhance the current version. I think that we'll have something better in a few weeks. Some ideas are floating around my head, i just have to catch them (at last)... > nicO > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Mar 2 12:49:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hMoh-0000G8-00 for ; Sun, 03 Mar 2002 04:37:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 04:37:43 +0100 (CET) Received: (qmail 3902 invoked by uid 0); 3 Mar 2002 00:37:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 3 Mar 2002 00:37:21 -0000 Received: by moria.seul.org (Postfix) id 841191462F9; Sat, 2 Mar 2002 19:37:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57A9C1467F2; Sat, 2 Mar 2002 19:37:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a112.home.uni-hannover.de [130.75.232.112]) by moria.seul.org (Postfix) with ESMTP id 123851462F9 for ; Sat, 2 Mar 2002 19:37:17 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00558; Sat, 2 Mar 2002 12:49:10 +0100 Message-ID: <20020302124910.23541@thrai.stud.uni-hannover.de> Date: Sat, 2 Mar 2002 12:49:10 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C8025D4.86B47163@f-cpu.org>; from Yann Guidon on Sat, Mar 02, 2002 at 02:07:32AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Mar 02, 2002 at 02:07:32AM +0100, Yann Guidon wrote: > hi, > > Nicolas Boulay wrote: > > > - synonym problem (several different virtual addresses cannot span the same > > > physical addresses without being dupplicated in cache). > > Abgelehnt. This one causes severe problems. > > >>> Not really, it causes waste space, only ! > i do not agree with "only". Neither do I (unless we're talking about the I-cache only). > > > (2) physically-addressed caches (physical tags) > > > - do virtual-to-physical address translation on every access > > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > > one of its variants) is called, and doesn't have to be repeated in all > > cases (e.g. with a postincremented pointer, you'll perform a range check > > first and only do a full lookup if the range check fails). > > > > >>> Consider that the LSU is a kind of virtually addressed caches. > that's one perspective. I'm not sure if I fully understand what exactly the LSU is supposed to do. In my mental picture, its job was to keep the data cache filled, not cache things itself. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Mar 3 11:53:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hduZ-0004gy-01 for ; Sun, 03 Mar 2002 22:52:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:52:55 +0100 (CET) Received: (qmail 28960 invoked by uid 0); 3 Mar 2002 11:07:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 3 Mar 2002 11:07:17 -0000 Received: by moria.seul.org (Postfix) id C783C1462F9; Sun, 3 Mar 2002 06:07:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AAD891467F2; Sun, 3 Mar 2002 06:07:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 25BBD1462F9 for ; Sun, 3 Mar 2002 06:07:15 -0500 (EST) Received: from ifurita (212.194.221.13) by mail.laposte.net (5.5.044) id 3C4C02590029DD12 for f-cpu@seul.org; Sun, 3 Mar 2002 12:07:13 +0100 Message-ID: <000901c1c2a1$991e2f60$0dddc2d4@ifurita> From: "Christophe" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 11:53:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Saturday, March 02, 2002 12:49 PM Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? > On Sat, Mar 02, 2002 at 02:07:32AM +0100, Yann Guidon wrote: > > hi, > > > > Nicolas Boulay wrote: > > > > - synonym problem (several different virtual addresses cannot span the same > > > > physical addresses without being dupplicated in cache). > > > Abgelehnt. This one causes severe problems. > > > >>> Not really, it causes waste space, only ! > > i do not agree with "only". > > Neither do I (unless we're talking about the I-cache only). > Why might there be severe problems ? well, caches both contains a tag and a data associated to a virtual address. If there are two different virtual addresses which span the same physical address and are present in the cache, it means that two entries in the cache might also have their data to be different and so coherency would be broken : which data to keep and update into the external memory ? > > > > (2) physically-addressed caches (physical tags) > > > > - do virtual-to-physical address translation on every access > > > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > > > one of its variants) is called, and doesn't have to be repeated in all > > > cases (e.g. with a postincremented pointer, you'll perform a range check > > > first and only do a full lookup if the range check fails). > > > > > > >>> Consider that the LSU is a kind of virtually addressed caches. > > that's one perspective. > > I'm not sure if I fully understand what exactly the LSU is supposed to do. > In my mental picture, its job was to keep the data cache filled, not > cache things itself. I thought LSU is "Load Store Unit" and was like a functional unit to handle LOAD and STORE ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 17:54:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hdue-0004gy-01 for ; Sun, 03 Mar 2002 22:53:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:00 +0100 (CET) Received: (qmail 9225 invoked by uid 0); 3 Mar 2002 16:54:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Mar 2002 16:54:04 -0000 Received: by moria.seul.org (Postfix) id 13FF61467EF; Sun, 3 Mar 2002 11:54:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A95D51467F6; Sun, 3 Mar 2002 11:54:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 94D851467EF for ; Sun, 3 Mar 2002 11:54:01 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23Gs0904113 for ; Sun, 3 Mar 2002 17:54:00 +0100 Message-ID: <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 17:54:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > Why might there be severe problems ? well, caches both contains a tag and > a data associated to a virtual address. If there are two > different virtual addresses which span the same physical address and are > present in the cache, it means that two entries in the > cache might also have their data to be different and so coherency would be > broken : which data to keep and update into the external > memory ? There is a simple software solution to this, dont allow the OS to let that happen :) With 64 bit's to go around you dont really need per process memory spaces (you still need per process memory protection of course, but you dont need to go to external memory to change that). Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Mar 3 18:53:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hduk-0004gy-00 for ; Sun, 03 Mar 2002 22:53:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:06 +0100 (CET) Received: (qmail 28455 invoked by uid 0); 3 Mar 2002 17:54:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 3 Mar 2002 17:54:00 -0000 Received: by moria.seul.org (Postfix) id 7F9CB1467F2; Sun, 3 Mar 2002 12:53:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 72CAE1467F7; Sun, 3 Mar 2002 12:53:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 93EA21467F2 for ; Sun, 3 Mar 2002 12:53:58 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203031753.2917; Sun, 3 Mar 2002 17:53:41 GMT Send-By: 194.158.98.37 with Mozilla/4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) To: Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Mar 2002 17:53:41 GMT Message-id: <200203031753.2917@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 03/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed= cache ? On Sat, Mar 02, 2002 at 02:07:32AM +0100, Yann Guidon wrote: > hi, >=20 > Nicolas Boulay wrote: > > > - synonym problem (several different virtual addresses= cannot span the same > > > physical addresses without being dupplicated in cache)= . > > Abgelehnt. This one causes severe problems. > > >>> Not really, it causes waste space, only ! > i do not agree with "only". Neither do I (unless we're talking about the I-cache only). >>> I understand that write-back cache policy could cause pr= oblem without a flush. > > > (2) physically-addressed caches (physical tags) > > > - do virtual-to-physical address translation on every = access > > Not necessarily. The TLB lookup can be started as soon a= s loadaddr (or > > one of its variants) is called, and doesn't have to be r= epeated in all > > cases (e.g. with a postincremented pointer, you'll perfo= rm a range check > > first and only do a full lookup if the range check fails= ). > >=20 > > >>> Consider that the LSU is a kind of virtually address= ed caches. > that's one perspective. I'm not sure if I fully understand what exactly the LSU is s= upposed to do. In my mental picture, its job was to keep the data cache fil= led, not cache things itself. >>> I see it as a simple bubble buffer that act as caches (l= ink to the register number for I-caches and to the memory tags for the = D-caches)) nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Mar 3 18:41:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hduk-0004gy-01 for ; Sun, 03 Mar 2002 22:53:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:06 +0100 (CET) Received: (qmail 17851 invoked by uid 0); 3 Mar 2002 17:56:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 3 Mar 2002 17:56:03 -0000 Received: by moria.seul.org (Postfix) id D6D111467F6; Sun, 3 Mar 2002 12:56:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C83FA1467F8; Sun, 3 Mar 2002 12:56:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 51A181467F6 for ; Sun, 3 Mar 2002 12:56:02 -0500 (EST) Received: from ifurita (212.194.239.235) by mail.laposte.net (5.5.044) id 3C4C3539002B07C8 for f-cpu@seul.org; Sun, 3 Mar 2002 18:56:01 +0100 Message-ID: <001301c1c2da$b47f8680$ebefc2d4@ifurita> From: "Christophe" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 18:41:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Marco Al To: Sent: Sunday, March 03, 2002 5:54 PM Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? > From: "Christophe" > > > Why might there be severe problems ? well, caches both contains a tag and > > a data associated to a virtual address. If there are two > > different virtual addresses which span the same physical address and are > > present in the cache, it means that two entries in the > > cache might also have their data to be different and so coherency would be > > broken : which data to keep and update into the external > > memory ? > > There is a simple software solution to this, dont allow the OS to let that > happen :) With 64 bit's to go around you dont really need per process memory > spaces (you still need per process memory protection of course, but you dont > need to go to external memory to change that). Lazy solution for my opinion. Not viable for micro kernel or exo kernel which really counts upon sharing some physical pages in different virtual addresses with different access rights. Anyway, if an OS programmer wants to use per process address spaces, he should be able to do so. Having it doesn't prevent us from being able to use a unique address space if we like. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 19:46:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hdul-0004gy-00 for ; Sun, 03 Mar 2002 22:53:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:07 +0100 (CET) Received: (qmail 10230 invoked by uid 0); 3 Mar 2002 18:46:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 3 Mar 2002 18:46:08 -0000 Received: by moria.seul.org (Postfix) id 3577E1467F7; Sun, 3 Mar 2002 13:46:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3106B1467FF; Sun, 3 Mar 2002 13:46:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 30D281467F7 for ; Sun, 3 Mar 2002 13:46:06 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23Ik5908245 for ; Sun, 3 Mar 2002 19:46:05 +0100 Message-ID: <003901c1c2e3$af77e700$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 19:46:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > Lazy solution for my opinion. So? > Not viable for micro kernel or exo kernel which really counts upon sharing > some physical pages in different virtual addresses with different access > rights. You only need per process memory protection, the actual location in memory is entirely arbitrary. In fact sharing data at different addresses in different memory spaces is a big pain in the ass ... you cant share data with embedded non relative pointers. There's a lot of microkernels meant for 64 bit architectures which use a global address space in fact. > Anyway, if an OS programmer wants to use per process address spaces, he > should be able to do so. Why? Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Mar 3 20:14:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hdum-0004gy-00 for ; Sun, 03 Mar 2002 22:53:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:08 +0100 (CET) Received: (qmail 27088 invoked by uid 0); 3 Mar 2002 19:15:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 3 Mar 2002 19:15:12 -0000 Received: by moria.seul.org (Postfix) id 111E01467F8; Sun, 3 Mar 2002 14:15:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EBF4E146804; Sun, 3 Mar 2002 14:15:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 58B991467F8 for ; Sun, 3 Mar 2002 14:15:10 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-217.jetnet.ab.ca [207.34.60.217] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id MAA15531 for ; Sun, 3 Mar 2002 12:15:08 -0700 (MST) Message-ID: <3C827630.1CD9AA4@jetnet.ab.ca> Date: Sun, 03 Mar 2002 12:14:56 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Marco Al wrote: > > Anyway, if an OS programmer wants to use per process address spaces, he > > should be able to do so. > > Why? Virtual OS's like windows and linux together? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 20:31:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hdup-0004gy-00 for ; Sun, 03 Mar 2002 22:53:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:11 +0100 (CET) Received: (qmail 31404 invoked by uid 0); 3 Mar 2002 19:31:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 3 Mar 2002 19:31:00 -0000 Received: by moria.seul.org (Postfix) id 0832C1467FF; Sun, 3 Mar 2002 14:30:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6F14146805; Sun, 3 Mar 2002 14:30:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 6DB901467FF for ; Sun, 3 Mar 2002 14:30:56 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23JUt910083 for ; Sun, 3 Mar 2002 20:30:55 +0100 Message-ID: <000501c1c2e9$f3449090$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <3C827630.1CD9AA4@jetnet.ab.ca> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 20:31:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Ben Franchuk" > Marco Al wrote: > > > > Anyway, if an OS programmer wants to use per process address spaces, he > > > should be able to do so. > > > > Why? > Virtual OS's like windows and linux together? Did FCPU turn into a x86 while I wasnt looking? :) Once you start doing emulation efficiency is not of greatest concern ... flushing parts of the cache hurts (you'd only have to flush parts, because you would detect synonyms through memory protection exceptions ... kernel space stuff would not get flushed) but its not going to be unusable. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Mar 3 20:44:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hduq-0004gy-01 for ; Sun, 03 Mar 2002 22:53:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:53:12 +0100 (CET) Received: (qmail 11043 invoked by uid 0); 3 Mar 2002 19:58:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 3 Mar 2002 19:58:39 -0000 Received: by moria.seul.org (Postfix) id 0F568146804; Sun, 3 Mar 2002 14:58:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA57B146808; Sun, 3 Mar 2002 14:58:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id A4813146804 for ; Sun, 3 Mar 2002 14:58:38 -0500 (EST) Received: from ifurita (213.44.154.244) by mail.laposte.net (5.5.044) id 3C4C0259002A2ECB for f-cpu@seul.org; Sun, 3 Mar 2002 20:58:38 +0100 Message-ID: <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> From: "Christophe" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 20:44:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok, lookup at this case (something like a memory pipe) in the same address space : - a thread wants to share a memory space where it could only read. - another thread wants to share the same memory space where it could only write. The only solution is having two different virtual addresses with different access rights pointing upon the same physical addresses. With virtual-addressed cache and virtual tags, the thread wouldn't read the right value after the other thread write because they use different entries in the cache. So even with your lazy solution, it is still impossible to do so. The only solution is having two TLB entries but just one cache entry for both. An extended case : 1 provider, n consumers - a thread wants to share a memory space where it could read and write. - n threads wants to share the same memory space where it could only read. Same topo. Etc. My opinion is that we should never try to put anything in the sofware corner. The end user is not an hardware person but a software person who would like to have choice to use a unique address space or seperate address spaces for his/her processes. Your software solution happens not to fullfil all the requirements that a hardware solution (virtual/physical-addressed cache but with physical tags) can fullfil. ----- Original Message ----- From: Marco Al To: Sent: Sunday, March 03, 2002 7:46 PM Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? > From: "Christophe" > > > Lazy solution for my opinion. > > So? > > > Not viable for micro kernel or exo kernel which really counts upon sharing > > some physical pages in different virtual addresses with different access > > rights. > > You only need per process memory protection, the actual location in memory > is entirely arbitrary. In fact sharing data at different addresses in > different memory spaces is a big pain in the ass ... you cant share data > with embedded non relative pointers. > > There's a lot of microkernels meant for 64 bit architectures which use a > global address space in fact. > > > Anyway, if an OS programmer wants to use per process address spaces, he > > should be able to do so. > > Why? > > Marco > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bombe@informatik.tu-muenchen.de Sun Mar 3 21:41:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hdvc-0004gy-00 for ; Sun, 03 Mar 2002 22:54:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 03 Mar 2002 22:54:00 +0100 (CET) Received: (qmail 23177 invoked by uid 0); 3 Mar 2002 20:45:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 3 Mar 2002 20:45:14 -0000 Received: by moria.seul.org (Postfix) id 3A020146805; Sun, 3 Mar 2002 15:45:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3546214680A; Sun, 3 Mar 2002 15:45:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.netsurf.de (mehlwurm.netsurf.de [194.195.64.32]) by moria.seul.org (Postfix) with ESMTP id E94B8146805 for ; Sun, 3 Mar 2002 15:45:11 -0500 (EST) Received: from storm.local ([195.179.191.228]) by mail.netsurf.de (Netscape Messaging Server 4.1) with ESMTP id GSF0C000.KPQ for ; Sun, 3 Mar 2002 21:45:36 +0100 Received: from andreasb by storm.local with local (Exim 3.34 #1 (Debian)) id 16hcnp-0004rV-00 for ; Sun, 03 Mar 2002 21:41:53 +0100 Date: Sun, 3 Mar 2002 21:41:53 +0100 From: Andreas Bombe To: f-cpu@seul.org Subject: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ? Message-ID: <20020303204153.GA3206@storm.local> References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> User-Agent: Mutt/1.3.27i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Mar 03, 2002 at 05:54:05PM +0100, Marco Al wrote: > From: "Christophe" > > > Why might there be severe problems ? well, caches both contains a tag and > > a data associated to a virtual address. If there are two > > different virtual addresses which span the same physical address and are > > present in the cache, it means that two entries in the > > cache might also have their data to be different and so coherency would be > > broken : which data to keep and update into the external > > memory ? > > There is a simple software solution to this, dont allow the OS to let that > happen :) With 64 bit's to go around you dont really need per process memory > spaces It would mean that all executables (not only shared libraries) would have to be position independent code. Besides, how are you going to implement a Unix fork(), then? -- Andreas Bombe DSA key 0x04880A44 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 22:40:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhwv-0007ab-00 for ; Mon, 04 Mar 2002 03:11:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:37 +0100 (CET) Received: (qmail 835 invoked by uid 0); 3 Mar 2002 21:40:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 3 Mar 2002 21:40:54 -0000 Received: by moria.seul.org (Postfix) id B547014680A; Sun, 3 Mar 2002 16:40:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 68931146849; Sun, 3 Mar 2002 16:40:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 7FB6414680A for ; Sun, 3 Mar 2002 16:40:52 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23Lep916214 for ; Sun, 3 Mar 2002 22:40:51 +0100 Message-ID: <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 22:40:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > Ok, lookup at this case (something like a memory pipe) in the same address > space : > > - a thread wants to share a memory space where it could only read. > - another thread wants to share the same memory space where it could only > write. > > The only solution is having two different virtual addresses with different > access rights pointing upon the same physical addresses. > > With virtual-addressed cache and virtual tags, the thread wouldn't read > the right value after the other > thread write because they use different entries in the cache. > > So even with your lazy solution, it is still impossible to do so. Threads are scheduled by the OS, if you really wanted to the OS could just change the protection when it switches between threads (with the method described in the section in the paper I pointed out before). As I conceded before you need individual protection spaces, but that does not equal individual memory spaces. Alternatively/additionally you could use a segment based approach with per segment protection flags and just change the segment registers when switching threads ... with variable sized segments that would work out pretty well IMO, an important aspect is that it can work with SMT. > An extended case : 1 provider, n consumers > > - a thread wants to share a memory space where it could read and write. > - n threads wants to share the same memory space where it could only read. The same solution as above applies. What I dont understand is why you would want to use memory mapped to two seperate memory ranges within the same process, because the memory isnt really protected ... the thread which is only supposed to read can still just write to the page through the other mapping ... shrug, anyway Ill just repeat that if you really wanted to you could do it even with a global address space. > My opinion is that we should never try to put anything in the sofware > corner. The end user is not an > hardware person but a software person who would like to have choice to use > a unique address space or > seperate address spaces for his/her processes. The set of users who could not get over it probably share a good number of people with the set of users who want machine's with lots of speculation, instruction reordering, huge caches and automatic prefetch mechanisms ... all there to mitigate the performance hit poorly targeted and implemented software gets. FCPU is not the processor for that second set of people, and I doubt very many of the first group remain afterwards. You would hope that the average user which is already ready to accept the FCPU would also recognise it when this mechanism would provide him with everything he needed, which is still open for debate, even if it means doing some things differently ... and is more appreciative what allowing simplification of the hardware and removal of the TLB bottleneck gives him in performance and cost terms. >Your software solution happens not to fullfil all the > requirements that a hardware solution (virtual/physical-addressed cache > but with physical tags) can fullfil. Maybe, but you have yet to come up with a realistic scenario where it would be a problem :) (apart from people having to change their way's a bit, which is always a problem ... but unfortunately unavoidable, the FCPU architecture stray's from the usual superscalar RISC approach regardless of how it implements virtual memory) Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 22:45:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhww-0007ab-00 for ; Mon, 04 Mar 2002 03:11:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:38 +0100 (CET) Received: (qmail 8118 invoked by uid 0); 3 Mar 2002 21:45:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 3 Mar 2002 21:45:42 -0000 Received: by moria.seul.org (Postfix) id 5BB3414680E; Sun, 3 Mar 2002 16:45:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4746B1468D3; Sun, 3 Mar 2002 16:45:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 87C5314680E for ; Sun, 3 Mar 2002 16:45:40 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23Ljd916390 for ; Sun, 3 Mar 2002 22:45:39 +0100 Message-ID: <002601c1c2fc$c5dd5b10$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <20020303204153.GA3206@storm.local> Subject: Re: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 22:45:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Andreas Bombe" > It would mean that all executables (not only shared libraries) would > have to be position independent code. Small loss, but if its really a problem segments provide an alternative solution. > Besides, how are you going to implement a Unix fork(), then? The Mungi people solved that if my memory serves me (look it up yourself :). I think they added an extra layer of indirection during compilation, slightly messy but you only have to use it for programs which actually use fork (again, segments could provide an alternative solution). Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Sun Mar 3 23:38:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhww-0007ab-01 for ; Mon, 04 Mar 2002 03:11:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:38 +0100 (CET) Received: (qmail 23441 invoked by uid 0); 3 Mar 2002 22:38:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 3 Mar 2002 22:38:41 -0000 Received: by moria.seul.org (Postfix) id C6DFC146849; Sun, 3 Mar 2002 17:38:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BEC341468D5; Sun, 3 Mar 2002 17:38:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 0F031146849 for ; Sun, 3 Mar 2002 17:38:40 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g23Mcd919489 for ; Sun, 3 Mar 2002 23:38:39 +0100 Message-ID: <000f01c1c304$2cf12050$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <20020303204153.GA3206@storm.local> <002601c1c2fc$c5dd5b10$bca45982@student.utwente.nl> Subject: Re: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ? Date: Sun, 3 Mar 2002 23:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Marco Al" > From: "Andreas Bombe" > > > It would mean that all executables (not only shared libraries) would > > have to be position independent code. > > Small loss, but if its really a problem segments provide an alternative > solution. Hell, come to think of it the loader could just rewrite them during start up. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Mar 3 17:10:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhwx-0007ab-00 for ; Mon, 04 Mar 2002 03:11:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:39 +0100 (CET) Received: (qmail 22740 invoked by uid 0); 3 Mar 2002 23:05:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 3 Mar 2002 23:05:02 -0000 Received: by moria.seul.org (Postfix) id 94FD11468D3; Sun, 3 Mar 2002 18:05:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F0801468D8; Sun, 3 Mar 2002 18:05:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id CA8731468D3 for ; Sun, 3 Mar 2002 18:04:59 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00543; Sun, 3 Mar 2002 17:10:54 +0100 Message-ID: <20020303171054.12987@thrai.stud.uni-hannover.de> Date: Sun, 3 Mar 2002 17:10:54 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000901c1c2a1$991e2f60$0dddc2d4@ifurita>; from Christophe on Sun, Mar 03, 2002 at 11:53:04AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Mar 03, 2002 at 11:53:04AM +0100, Christophe wrote: [...] > > > > > - synonym problem (several different virtual addresses cannot span the same > > > > > physical addresses without being dupplicated in cache). > > > > Abgelehnt. This one causes severe problems. > > > > >>> Not really, it causes waste space, only ! > > > i do not agree with "only". > > > > Neither do I (unless we're talking about the I-cache only). > > > > Why might there be severe problems ? well, caches both contains a tag and a data associated to a virtual address. If there are two > different virtual addresses which span the same physical address and are present in the cache, it means that two entries in the > cache might also have their data to be different and so coherency would be broken : which data to keep and update into the external > memory ? Yep. The results will become unpredictable. > > > > > (2) physically-addressed caches (physical tags) > > > > > - do virtual-to-physical address translation on every access > > > > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > > > > one of its variants) is called, and doesn't have to be repeated in all > > > > cases (e.g. with a postincremented pointer, you'll perform a range check > > > > first and only do a full lookup if the range check fails). > > > > > > > > >>> Consider that the LSU is a kind of virtually addressed caches. > > > that's one perspective. > > > > I'm not sure if I fully understand what exactly the LSU is supposed to do. > > In my mental picture, its job was to keep the data cache filled, not > > cache things itself. > > I thought LSU is "Load Store Unit" and was like a functional unit to handle LOAD and STORE ? With the exception that it has an unknown (and probably high) latency. In order to reduce that, we start to cache data when the address is loaded (via loadaddr and friends) and hope that data will be ready when the load/store instruction is executed (which is just a data move operation -- i.e. lots of wires -- plus a little bit of byte shuffling if endian conversion is needed). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 4 00:36:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhwx-0007ab-01 for ; Mon, 04 Mar 2002 03:11:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:39 +0100 (CET) Received: (qmail 29209 invoked by uid 0); 3 Mar 2002 23:31:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 3 Mar 2002 23:31:36 -0000 Received: by moria.seul.org (Postfix) id 49F7E1468D5; Sun, 3 Mar 2002 18:31:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37F9C1468DC; Sun, 3 Mar 2002 18:31:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id AF6D71468D5 for ; Sun, 3 Mar 2002 18:31:34 -0500 (EST) Received: from f-cpu.org (kdl21-1.n.club-internet.fr [213.44.96.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id F3DB316B2 for ; Mon, 4 Mar 2002 00:31:29 +0100 (CET) Message-ID: <3C82B392.BBF9FBA0@f-cpu.org> Date: Mon, 04 Mar 2002 00:36:50 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Christophe wrote: > From: Michael Riepe > > On Sat, Mar 02, 2002 at 02:07:32AM +0100, Yann Guidon wrote: > > > Nicolas Boulay wrote: > > > > > - synonym problem (several different virtual addresses cannot span the same > > > > > physical addresses without being dupplicated in cache). > > > > Abgelehnt. This one causes severe problems. > > > > >>> Not really, it causes waste space, only ! > > > i do not agree with "only". > > Neither do I (unless we're talking about the I-cache only). > Why might there be severe problems ? well, caches both contains > a tag and a data associated to a virtual address. If there are two > different virtual addresses which span the same physical address > and are present in the cache, it means that two entries in the > cache might also have their data to be different and so coherency > would be broken : which data to keep and update into the external memory ? this problem is "solved" by using physical tags, that's all :-) > > > > > (2) physically-addressed caches (physical tags) > > > > > - do virtual-to-physical address translation on every access > > > > Not necessarily. The TLB lookup can be started as soon as loadaddr (or > > > > one of its variants) is called, and doesn't have to be repeated in all > > > > cases (e.g. with a postincremented pointer, you'll perform a range check > > > > first and only do a full lookup if the range check fails). > > > > > > > > >>> Consider that the LSU is a kind of virtually addressed caches. > > > that's one perspective. > > I'm not sure if I fully understand what exactly the LSU is supposed to do. > > In my mental picture, its job was to keep the data cache filled, not > > cache things itself. > I thought LSU is "Load Store Unit" and was like a functional unit to handle LOAD and STORE ? This is the programmer's point of view. it is correct but the LSU (and its symmetric : the instruction fetcher) do much more than that because "handle" implies many things. Marco Al wrote: > From: "Christophe" > > Why might there be severe problems ? well, caches both contains a tag and > > a data associated to a virtual address. If there are two > > different virtual addresses which span the same physical address and are > > present in the cache, it means that two entries in the > > cache might also have their data to be different and so coherency would be > > broken : which data to keep and update into the external > > memory ? > > There is a simple software solution to this, dont allow the OS to let that > happen :) i don't know if it is wise to put that kind of pressure on the OS. > With 64 bit's to go around you dont really need per process memory spaces i don't think that this argument is valid. F-CPU defines 64-bt pointers but might implement a small subset thereof. For example, a dumb prototype might use 5+16 address bits (5 bits for the LSU index (each cache line is 32 byte wide) and 16 bits for the remaining comparators (address comparators of the LSU, for example). A first commercial might increase that to 5+32=37 bits, and others might chose to reduce or increase the physically addressable space, for ranging from "embedded" versions to mainframes... I think that the VMID (named ASID in MIPS) is still necessary and overlapping pages might help communication between processes from different VMIDs, thus reducing the cost of copying pages from one process to another. > (you still need per process memory protection of course, but you dont > need to go to external memory to change that). > > Marco Christophe wrote: > From: Marco Al > > From: "Christophe" > Lazy solution for my opinion. Not viable for micro kernel > or exo kernel which really counts upon sharing > some physical pages in different virtual addresses with different access rights. > > Anyway, if an OS programmer wants to use per process address spaces, > he should be able to do so. Having it > doesn't prevent us from being able to use a unique address space if we like. that's more or less the point i made above :-) Let's implement just enough, but not too much, so that if it's unused, there is no waste of silicon surface... nicO: > michael : > > I'm not sure if I fully understand what exactly the LSU is supposed to do. > In my mental picture, its job was to keep the data cache filled, not > cache things itself. > > >>> I see it as a simple bubble buffer that act as caches (link to the > register number for I-caches and to the memory tags for the D-caches)) > nicO * it is indeed a buffer that has the same behaviour as a small cache, but reduced to 8 lines of 256 bits. * The fetcher and the LSU are symmetrical, with the _only_ difference in structure that the fetcher handles 32-bit data only (8 per line) and does not have to handle writes from the pipeline. * Each line is "linked" to zero, one or more register numbers, to ease decoding and static scheduling. So there is a constant number of cycles for transfering the data from the buffer to the pipeline, and for the other direction (to the LSU). * Upon accessing a line, there is a 3-bit LRU counter which is updated, so the LSU and the fetcher work in almost-ideal Least Recently Used fashion. * A pair of lines (could be non-contiguous but it's not clear yet how) will be formed to handle "streams" (contiguous memory access to/from memory) with a double-buffering scheme. These were the behaviours from the pipeline point of view but these are not the only characteristics of the LSU and the fetcher ! * The LSU and the fetcher are the only devices connected to their associated L1 cache : this simplifies the layout and protocol, because there is a unique 256 bit bus for (simultaneous) reading or writing a line. * The design of the LSU and the fetcher is tightly coupled to their associated L1 caches, which can be considered like a "reservoir" or "swap space" for the memory buffers. * The L1 strategy is to write back on cache line replacement : this is logical in a system where there is no "main memory" but a "private memory range". In a sense, the L1 is like a large FIFO from which one element can be taken and put in front again, while the line arriving at the end of the FIFO is written to memory * All memory reads and writes to/from L1 go through the corresponding memory buffer (LSU or fetchers). This is both a cause and a consequence >from the fact that the L1 must be kept as simple as possible but must handle multi-word transactions on 32-bit and 64-bit words. The cache line's "scatter and gather" of the word is handled only by the LSU or the fetcher. * nicO doen't agree on this : the LSU and the fetcher are connected to their own L1, as well as the other memory system buses : L2, I/O bus, private (SD)RAM bus. I justify this with several facts and desirable things : - perform the line split (256 bits to and from 8, 16, 32 and 64 bits) in a single location. This increases the local density but simplifies all the rest. - having a single location where data is considered coherent. If the CPU can have a direct access to all the memory cache layers, it simplifies the invalidation problem. When an external system asks for data read or write to our CPU, all there is to do is hand the address to the LSU and fetcher, which then do their work like it usually does for the execution pipeline. - reducing the overall memory latency. Having all (or most) layers connected to a single point might be a small overhead but avoids the "avalanche" effect on a cache miss, and this becomes particularly important when the code works mostly with uncached or scattered data. OTOH, the LSU and the fetcher are designed so that the minimum latency is hidden when consecutive accesses are performed (with a streaming detection which automatically enables double buffering). Damn looking like a patent claim list :-/ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bombe@informatik.tu-muenchen.de Mon Mar 4 00:37:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhwz-0007ab-00 for ; Mon, 04 Mar 2002 03:11:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:41 +0100 (CET) Received: (qmail 18341 invoked by uid 0); 3 Mar 2002 23:36:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 3 Mar 2002 23:36:58 -0000 Received: by moria.seul.org (Postfix) id 118B21468D8; Sun, 3 Mar 2002 18:36:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C6331468DD; Sun, 3 Mar 2002 18:36:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.netsurf.de (mehlwurm.netsurf.de [194.195.64.32]) by moria.seul.org (Postfix) with ESMTP id 59DAE1468D8 for ; Sun, 3 Mar 2002 18:36:55 -0500 (EST) Received: from storm.local ([195.179.189.201]) by mail.netsurf.de (Netscape Messaging Server 4.1) with ESMTP id GSF8AA00.JX5 for ; Mon, 4 Mar 2002 00:37:22 +0100 Received: from andreasb by storm.local with local (Exim 3.34 #1 (Debian)) id 16hfXS-0005YT-00 for ; Mon, 04 Mar 2002 00:37:10 +0100 Date: Mon, 4 Mar 2002 00:37:10 +0100 From: Andreas Bombe To: f-cpu@seul.org Subject: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ? Message-ID: <20020303233710.GA21174@storm.local> References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <20020303204153.GA3206@storm.local> <002601c1c2fc$c5dd5b10$bca45982@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c1c2fc$c5dd5b10$bca45982@student.utwente.nl> User-Agent: Mutt/1.3.27i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Mar 03, 2002 at 10:45:44PM +0100, Marco Al wrote: > From: "Andreas Bombe" > > > It would mean that all executables (not only shared libraries) would > > have to be position independent code. > > Small loss, but if its really a problem segments provide an alternative > solution. Segments? Oh, ye gods, no... > > Besides, how are you going to implement a Unix fork(), then? > > The Mungi people solved that if my memory serves me (look it up yourself :). > I think they added an extra layer of indirection during compilation, What I found is that Mungi is an OS using a single flat address space over all processes. They likely simply don't have a fork() equivalent. So it's an OS that uses a subset of the CPU's capabilities. What you propose is making a CPU that provides a subset of the OS's requirements. > slightly messy but you only have to use it for programs which actually use > fork Which is any program that is not a leaf in the process tree. Starting an executable is in fact a fork()+exec(). That said, it is possible to implement a Unix on a system where there is only a flat address space (systems without a MMU). Minix did this by copying data in shared addresses to backup buffers on context switch IIRC. uCLinux simply doesn't have that, but it's also not compatible with standard Unix applications. -- Andreas Bombe DSA key 0x04880A44 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 4 01:27:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhx0-0007ab-00 for ; Mon, 04 Mar 2002 03:11:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:42 +0100 (CET) Received: (qmail 28334 invoked by uid 0); 4 Mar 2002 00:22:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 4 Mar 2002 00:22:25 -0000 Received: by moria.seul.org (Postfix) id 372641467F9; Sun, 3 Mar 2002 19:22:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1AA991468DD; Sun, 3 Mar 2002 19:22:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A37A51467F9 for ; Sun, 3 Mar 2002 19:22:19 -0500 (EST) Received: from f-cpu.org (kdl21-25.n.club-internet.fr [213.44.96.25]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B24D51698 for ; Mon, 4 Mar 2002 01:22:16 +0100 (CET) Message-ID: <3C82BF79.70695273@f-cpu.org> Date: Mon, 04 Mar 2002 01:27:37 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i have just woken up and saw this thread degenerate without bringing a single solution. i don't want to walk in this, though i seem to agree with Christophe, but i just wanted to point a few details that were apparently misinterpreted. Marco Al wrote: > From: "Christophe" > > > Ok, lookup at this case (something like a memory pipe) in the same address > > space : > > > > - a thread wants to share a memory space where it could only read. > > - another thread wants to share the same memory space where it could only > > write. > > > > The only solution is having two different virtual addresses with different > > access rights pointing upon the same physical addresses. > > > > With virtual-addressed cache and virtual tags, the thread wouldn't read > > the right value after the other > > thread write because they use different entries in the cache. > > > > So even with your lazy solution, it is still impossible to do so. > > Threads are scheduled by the OS, if you really wanted to the OS could just > change the protection when it switches between threads (with the method > described in the section in the paper I pointed out before). As I conceded > before you need individual protection spaces, but that does not equal > individual memory spaces. changing the protection when switching the processes/tasks/threads looks ugly for me. > Alternatively/additionally you could use a segment based approach with per > segment protection flags and just change the segment registers when > switching threads ... with variable sized segments that would work out > pretty well IMO, an important aspect is that it can work with SMT. i think that F-CPU is already complex enough with only paged/virtual memory, adding segments woud be a mess. Unless you mean a "fence" mechanism, but then only a fence or a few shoud be active at a time. > > An extended case : 1 provider, n consumers > > > > - a thread wants to share a memory space where it could read and write. > > - n threads wants to share the same memory space where it could only read. > > The same solution as above applies. > > What I dont understand is why you would want to use memory mapped to two > seperate memory ranges within the same process, because the memory isnt > really protected ... it's only a problem of terminology, i think. What if your threads belong to different tasks or processes or whatever ? in short : Virtual Memory IDs... > > My opinion is that we should never try to put anything in the sofware > > corner. The end user is not an > > hardware person but a software person who would like to have choice to use > > a unique address space or seperate address spaces for his/her processes. > > The set of users who could not get over it probably share a good number of > people with the set of users who want machine's with lots of speculation, > instruction reordering, huge caches and automatic prefetch mechanisms ... > all there to mitigate the performance hit poorly targeted and implemented > software gets. FCPU is not the processor for that second set of people, and > I doubt very many of the first group remain afterwards. it took a lot of time before i was able to use the 386 protected mode, and i did not even use the virtual memory. I don't know what part i belong to. If i was alone with F-CPU, there would be no paging, just a few sets of fences. there would have been no debate, porting any OS (except UNICOS) would be a mess but F-CPU would probably work. Don't you think that a CPU with a decent number of TLB entries and a physical tagged cache is enough to make an OS that is not too hairy ? > You would hope that the average user which is already ready to accept the > FCPU would also recognise it when this mechanism would provide him with > everything he needed, which is still open for debate, even if it means doing > some things differently ... and is more appreciative what allowing > simplification of the hardware and removal of the TLB bottleneck gives him > in performance and cost terms. Considering that all the sources are copylefted, anybody is free to make his own version in case one doesn't like it. However, for this to ever happen, we have to write these sources... Good night everybody, > Marco WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 4 01:36:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhx1-0007ab-00 for ; Mon, 04 Mar 2002 03:11:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:43 +0100 (CET) Received: (qmail 11494 invoked by uid 0); 4 Mar 2002 00:36:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 4 Mar 2002 00:36:55 -0000 Received: by moria.seul.org (Postfix) id 27AD41468DC; Sun, 3 Mar 2002 19:36:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C99E1468DE; Sun, 3 Mar 2002 19:36:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 8D0481468DC for ; Sun, 3 Mar 2002 19:36:52 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02049; Mon, 4 Mar 2002 01:36:51 +0100 Message-ID: <20020304013650.21980@thrai.stud.uni-hannover.de> Date: Mon, 4 Mar 2002 01:36:50 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C82BF79.70695273@f-cpu.org>; from Yann Guidon on Mon, Mar 04, 2002 at 01:27:37AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 04, 2002 at 01:27:37AM +0100, Yann Guidon wrote: [...] > Don't you think that a CPU with a decent number of TLB entries and a physical > tagged cache is enough to make an OS that is not too hairy ? Sounds good - if the number of TLB entries is high enough. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon Mar 4 01:51:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhx2-0007ab-00 for ; Mon, 04 Mar 2002 03:11:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:44 +0100 (CET) Received: (qmail 22347 invoked by uid 0); 4 Mar 2002 00:51:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 4 Mar 2002 00:51:22 -0000 Received: by moria.seul.org (Postfix) id 1FC911468DD; Sun, 3 Mar 2002 19:51:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BDE11468DF; Sun, 3 Mar 2002 19:51:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 4A14B1468DD for ; Sun, 3 Mar 2002 19:51:21 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g240pK924540 for ; Mon, 4 Mar 2002 01:51:20 +0100 Message-ID: <001501c1c316$b667fe50$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <20020303204153.GA3206@storm.local> <002601c1c2fc$c5dd5b10$bca45982@student.utwente.nl> <20020303233710.GA21174@storm.local> Subject: Re: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ? Date: Mon, 4 Mar 2002 01:51:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Andreas Bombe" > On Sun, Mar 03, 2002 at 10:45:44PM +0100, Marco Al wrote: > > From: "Andreas Bombe" > > > > > It would mean that all executables (not only shared libraries) would > > > have to be position independent code. > > > > Small loss, but if its really a problem segments provide an alternative > > solution. > > Segments? Oh, ye gods, no... :) > > > Besides, how are you going to implement a Unix fork(), then? > > > > The Mungi people solved that if my memory serves me (look it up yourself :). > > I think they added an extra layer of indirection during compilation, > > What I found is that Mungi is an OS using a single flat address space > over all processes. They likely simply don't have a fork() equivalent. Ok then ... yes first link from google for "mungi fork" shows they do in fact have a fork equivalent. I was wrong though, its not their method ... they borrowed it from a much earlier SASOS angel (http://citeseer.nj.nec.com/wilkinson93compiling.html which they cite, as can be seen on the 4th link on the search). > So it's an OS that uses a subset of the CPU's capabilities. > > What you propose is making a CPU that provides a subset of the OS's > requirements. Not exactly, it can support traditional virtual memory ... just slightly less efficiently. It supports everything necessary to efficiently support SASOS's, just as long as you have a 64 bit address space (with less, fragmentation would be a huge problem ... Ill readily admit defragmenting the virtual->physical memory mapping, while possible if code was compiled to make all data movable, is not something you really want to do). Everything thats necessary turns out not to include a TLB. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon Mar 4 02:14:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16hhx2-0007ab-01 for ; Mon, 04 Mar 2002 03:11:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 04 Mar 2002 03:11:44 +0100 (CET) Received: (qmail 26565 invoked by uid 0); 4 Mar 2002 01:14:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Mar 2002 01:14:06 -0000 Received: by moria.seul.org (Postfix) id B33581468DE; Sun, 3 Mar 2002 20:14:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 937B91468E0; Sun, 3 Mar 2002 20:14:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id B1E841468DE for ; Sun, 3 Mar 2002 20:14:03 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g241E3925180 for ; Mon, 4 Mar 2002 02:14:03 +0100 Message-ID: <002e01c1c319$e27d3660$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Mon, 4 Mar 2002 02:14:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Yann Guidon" > changing the protection when switching the processes/tasks/threads > looks ugly for me. It is, if you use a process ID it only needs to happen for the shared memory though. > > Alternatively/additionally you could use a segment based approach with per > > segment protection flags and just change the segment registers when > > switching threads ... with variable sized segments that would work out > > pretty well IMO, an important aspect is that it can work with SMT. > > i think that F-CPU is already complex enough with only paged/virtual memory, > adding segments woud be a mess. Unless you mean a "fence" mechanism, > but then only a fence or a few shoud be active at a time. With segments Im thinking of a set of registers which are indexed by the MSB's of the address, the content of which replaces the "top" part of the address. Each segment would have its own set of protection flags. > Don't you think that a CPU with a decent number of TLB entries and a physical > tagged cache is enough to make an OS that is not too hairy ? Of course. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 4 03:23:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5WO-00068B-00 for ; Tue, 05 Mar 2002 04:21:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:21:48 +0100 (CET) Received: (qmail 32669 invoked by uid 0); 4 Mar 2002 02:18:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 4 Mar 2002 02:18:24 -0000 Received: by moria.seul.org (Postfix) id DB35B1468E1; Sun, 3 Mar 2002 21:18:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D376B1468E3; Sun, 3 Mar 2002 21:18:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 77EB31468E1 for ; Sun, 3 Mar 2002 21:18:22 -0500 (EST) Received: from f-cpu.org (kdl21-16.n.club-internet.fr [213.44.96.16]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 54A8216BB for ; Mon, 4 Mar 2002 03:18:19 +0100 (CET) Message-ID: <3C82DAAA.71938B0A@f-cpu.org> Date: Mon, 04 Mar 2002 03:23:38 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> <002e01c1c319$e27d3660$bca45982@student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! i thought i'd sleep but... Marco Al wrote: > From: "Yann Guidon" > > changing the protection when switching the processes/tasks/threads > > looks ugly for me. > It is, if you use a process ID it only needs to happen for the shared memory > though. the problem with this kind of trrick is that there are always cases when the simplifying trick doesn't apply, so only remain the drawbacks :-( > > > Alternatively/additionally you could use a segment based approach with per > > > segment protection flags and just change the segment registers when > > > switching threads ... with variable sized segments that would work out > > > pretty well IMO, an important aspect is that it can work with SMT. > > > > i think that F-CPU is already complex enough with only paged/virtual memory, > > adding segments woud be a mess. Unless you mean a "fence" mechanism, > > but then only a fence or a few shoud be active at a time. > > With segments Im thinking of a set of registers which are indexed by the > MSB's of the address, the content of which replaces the "top" part of the > address. Each segment would have its own set of protection flags. Don't pages do already do that ? ... huh ? > > Don't you think that a CPU with a decent number of TLB entries and a physical > > tagged cache is enough to make an OS that is not too hairy ? > Of course. i wish i could find THE trick that would solve all our problems... life's fun when you find solutions. > Marco PS: i just found a page about the "CRAY/TERA MTA" computer : http://www.sdsc.edu/~allans/wave.html http://www.sdsc.edu/~allans/papers.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon Mar 4 06:14:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5WO-00068B-01 for ; Tue, 05 Mar 2002 04:21:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:21:48 +0100 (CET) Received: (qmail 9674 invoked by uid 0); 4 Mar 2002 05:14:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 4 Mar 2002 05:14:44 -0000 Received: by moria.seul.org (Postfix) id 7ADCF1467EF; Mon, 4 Mar 2002 00:14:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 788B21467F6; Mon, 4 Mar 2002 00:14:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 9869C1467EF for ; Mon, 4 Mar 2002 00:14:41 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g245Ee323651 for ; Mon, 4 Mar 2002 06:14:40 +0100 Message-ID: <001101c1c33b$801b63d0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203012327.0dec@th00.opsion.fr> <3C8025D4.86B47163@f-cpu.org> <20020302124910.23541@thrai.stud.uni-hannover.de> <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> <002e01c1c319$e27d3660$bca45982@student.utwente.nl> <3C82DAAA.71938B0A@f-cpu.org> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Mon, 4 Mar 2002 06:14:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Yann Guidon" > > With segments Im thinking of a set of registers which are indexed by the > > MSB's of the address, the content of which replaces the "top" part of the > > address. Each segment would have its own set of protection flags. > > Don't pages do already do that ? ... huh ? At a different granularity, a couple of segments would make up the entire memory space for the process, and pages have physical memory beneath them ... the address after the segment has been prepended would still be pointing to the global address space. http://www.ee.umd.edu/~blj/papers/ieeetc50-5.pdf http://www.ee.umd.edu/~blj/papers/computer31-6.pdf Explain it "better" than me ... actually I only just realised that I was a little hung up on the SASOS idea (for which you dont need segments). With the example mechanism in the first paper normal per process memory spaces are actually pretty trivial. The underlying global memory space still has to be larger than with a standard scheme, because it has to accomodate the total size of all the process spaces put together, but I doubt the costs are something simplification of the caches and removal of the TLB wont cover. Also because segment id's can be expanded (creating larger addresses) instead of replaced (which you would do in the 64 bit situation) it would still be usuable when the architecture only used small pointers. Mea culpa ... if you forget my ramblings and just read the first paper you'll see its quite elegant apart from having to walk the cache for invalidation and changing protection (the costs for either arent really relevant as explained in the paper ... but even so when memory were to be shared you would usually share it through the segment mechanism, if you have per segment protection flags which can override the per cacheline one's you cover 99% of the applications). Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Mar 4 13:54:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5WU-00068B-00 for ; Tue, 05 Mar 2002 04:21:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:21:54 +0100 (CET) Received: (qmail 5566 invoked by uid 0); 4 Mar 2002 12:54:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Mar 2002 12:54:47 -0000 Received: by moria.seul.org (Postfix) id A0DB11467F3; Mon, 4 Mar 2002 07:54:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 96AE01467F7; Mon, 4 Mar 2002 07:54:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id AE9E41467F3 for ; Mon, 4 Mar 2002 07:54:46 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203041254.243f; Mon, 4 Mar 2002 12:54:36 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Mar 2002 12:54:36 GMT Message-id: <200203041254.243f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 04/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed= cache ? hello, Christophe wrote: > From: Michael Riepe > > On Sat, Mar 02, 2002 at 02:07:32AM +0100, Yann Guidon wr= ote: > > > Nicolas Boulay wrote: > > > > > - synonym problem (several different virtual addre= sses cannot span the same > > > > > physical addresses without being dupplicated in ca= che). > > > > Abgelehnt. This one causes severe problems. > > > > >>> Not really, it causes waste space, only ! > > > i do not agree with "only". > > Neither do I (unless we're talking about the I-cache onl= y). > Why might there be severe problems ? well, caches both con= tains > a tag and a data associated to a virtual address. If there= are two > different virtual addresses which span the same physical a= ddress > and are present in the cache, it means that two entries in= the > cache might also have their data to be different and so co= herency > would be broken : which data to keep and update into the e= xternal memory ? this problem is "solved" by using physical tags, that's all = :-) >>> Sure ! But you should put the TLB in the critical data p= ath of the memory system. So you slow done every memory access. > > > > > (2) physically-addressed caches (physical tags) > > > > > - do virtual-to-physical address translation on ev= ery access > > > > Not necessarily. The TLB lookup can be started as so= on as loadaddr (or > > > > one of its variants) is called, and doesn't have to = be repeated in all > > > > cases (e.g. with a postincremented pointer, you'll p= erform a range check > > > > first and only do a full lookup if the range check f= ails). > > > > > > > > >>> Consider that the LSU is a kind of virtually add= ressed caches. > > > that's one perspective. > > I'm not sure if I fully understand what exactly the LSU = is supposed to do. > > In my mental picture, its job was to keep the data cache= filled, not > > cache things itself. > I thought LSU is "Load Store Unit" and was like a function= al unit to handle LOAD and STORE ? This is the programmer's point of view. it is correct but th= e LSU (and its symmetric : the instruction fetcher) do much more than that because "han= dle" implies many things. Marco Al wrote: > From: "Christophe" > > Why might there be severe problems ? well, caches both c= ontains a tag and > > a data associated to a virtual address. If there are two > > different virtual addresses which span the same physical= address and are > > present in the cache, it means that two entries in the > > cache might also have their data to be different and so = coherency would be > > broken : which data to keep and update into the external > > memory ? >=20 > There is a simple software solution to this, dont allow th= e OS to let that > happen :) i don't know if it is wise to put that kind of pressure on t= he OS. > With 64 bit's to go around you dont really need per proces= s memory spaces i don't think that this argument is valid. F-CPU defines 64-= bt pointers but might implement a small subset thereof. For example, a d= umb prototype might use 5+16 address bits (5 bits for the LSU index (each = cache line is 32 byte wide) and 16 bits for the remaining comparators (add= ress comparators of the LSU, for example). A first commercial might increase = that to 5+32=3D37 bits, >>>> All of this are details ! and others might chose to reduce or increase the physically = addressable space, for ranging from "embedded" versions to mainframes... I think that the VMID (named ASID in MIPS) is still necessar= y and overlapping pages might help communication between processes from different VM= IDs, thus reducing the cost of copying pages from one process to another. > (you still need per process memory protection of course, b= ut you dont > need to go to external memory to change that). >=20 > Marco Christophe wrote: > From: Marco Al > > From: "Christophe" > Lazy solution for my opinion. Not viable for micro kernel > or exo kernel which really counts upon sharing > some physical pages in different virtual addresses with di= fferent access rights. >=20 > Anyway, if an OS programmer wants to use per process addre= ss spaces, > he should be able to do so. Having it > doesn't prevent us from being able to use a unique address= space if we like. that's more or less the point i made above :-) Let's implement just enough, but not too much, so that if it= 's unused, there is no waste of silicon surface... nicO: > michael : > > I'm not sure if I fully understand what exactly the LSU is= supposed to do. > In my mental picture, its job was to keep the data cache f= illed, not > cache things itself. >=20 > >>> I see it as a simple bubble buffer that act as caches = (link to the > register number for I-caches and to the memory tags for th= e D-caches)) > nicO * it is indeed a buffer that has the same behaviour as a sma= ll cache, but reduced to 8 lines of 256 bits. * The fetcher and the LSU are symmetrical, with the _only_ d= ifference in structure that the fetcher handles 32-bit data only (8 pe= r line) and does not have to handle writes from the pipeline. * Each line is "linked" to zero, one or more register number= s, to ease decoding and static scheduling. So there is a consta= nt number of cycles for transfering the data from the buffer to the pi= peline, and for the other direction (to the LSU). >>> Away from details, the only interresting things here is = that a data should be in the LSU. Otherwise the entire cpu is frozen, so= there isn't any variables cycles instructions in the pipeline.=20 * Upon accessing a line, there is a 3-bit LRU counter which = is updated, so the LSU and the fetcher work in almost-ideal Least Recent= ly Used fashion. >>> So you speak about the replacement policy of the cache. = Nothing new ? * A pair of lines (could be non-contiguous but it's not clea= r yet how) will be formed to handle "streams" (contiguous memory access to/f= rom memory) with a double-buffering scheme. These were the behaviours from the pipeline point of view bu= t these are not the only characteristics of the LSU and the fetcher ! >>> So it's a cache were the data should be present otherwis= e the pipeline is frozen.=20 * The LSU and the fetcher are the only devices connected to = their associated L1 cache : this simplifies the layout and protoco= l, because there is a unique 256 bit bus for (simultaneous) rea= ding or writing a line. * The design of the LSU and the fetcher is tightly coupled t= o their associated L1 caches, which can be considered like a "reserv= oir" or "swap space" for the memory buffers. * The L1 strategy is to write back on cache line replacement= : this is logical in a system where there is no "main memory" but a "p= rivate memory range". >>> in case of distributed memory you could NOT use write ba= ck, but write thought or write invalidate. Otherwise, you will have = coherency problem. In a sense, the L1 is like a large FIFO from which one eleme= nt can be taken and put in front again, while the line arriving at the= end of the FIFO is written to memory >>> That's the typical goal of a cache ! * All memory reads and writes to/from L1 go through the corr= esponding memory buffer (LSU or fetchers). This is both a cause and a = consequence >from the fact that the L1 must be kept as simple as possible= but must handle multi-word transactions on 32-bit and 64-bit words. T= he cache line's "scatter and gather" of the word is handled only by t= he LSU or the fetcher. * nicO doen't agree on this : the LSU and the fetcher are co= nnected to their own L1, as well as the other memory system buses : L2, I/O b= us, private (SD)RAM bus. >>> That's only a strange manner to present that. Usually, t= he memory hierarchy is ... hierachical. You don't mix things. But it's= black box, so you could introduice how many connexion you want between = the bloc. I justify this with several facts and desirable things : - perform the line split (256 bits to and from 8, 16, 32 an= d 64 bits) in a single location. This increases the local density but s= implifies all the rest. >>> So it simplify the layout ? i(m not sure because you onl= y change the upper level point of view but not the fonctionnality. - having a single location where data is considered coheren= t. If the CPU can have a direct access to all the memory cache layers,= it simplifies the invalidation problem. When an external system= asks for data read or write to our CPU, all there is to do is hand th= e address to the LSU and fetcher, which then do their work like it usuall= y does for the execution pipeline. >>>> Ouch ! If an external access occur to the memory why bo= thering the cpu of the node !!! The system could provide access to the d= ata very easly without problems. - reducing the overall memory latency. Having all (or most)= layers connected to a single point might be a small overhead but av= oids the "avalanche" effect on a cache miss, and this becomes particu= larly important when the code works mostly with uncached or scatte= red data. OTOH, the LSU and the fetcher are designed so that the minim= um latency is hidden when consecutive accesses are performed (with a st= reaming detection which automatically enables double buffering). >>> So you want a cache that give immediately the result of = there fetch. You didn't want to wait the complete load of a cache line. N= othing new ! cf : http://www.cs.washington.edu/education/courses/471/00au/Lect= ures/cacheAd v.pdf When you speak of the avalanche effect does that means that = you iniate an access to every memory at each demand (LSU,L1,L2, main me= mory) ? So each time you must canceled all the access for very littl= e gain in the common case. Most of the time there is a penalty for can= celed burst transfert. In SMP system (with cpus on the same die) it's an= overkill !=20 I think that the use of flag in the instruction world could = help to bypass the L1 cache in case of none cacheable access to the = memory. nicO Damn looking like a patent claim list :-/ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Mon Mar 4 23:06:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5We-00068B-01 for ; Tue, 05 Mar 2002 04:22:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:04 +0100 (CET) Received: (qmail 27457 invoked by uid 0); 4 Mar 2002 22:06:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 4 Mar 2002 22:06:41 -0000 Received: by moria.seul.org (Postfix) id E9E71146804; Mon, 4 Mar 2002 17:06:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E252A14680E; Mon, 4 Mar 2002 17:06:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 9E3B0146804; Mon, 4 Mar 2002 17:06:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 9DA08FEDD8 for ; Mon, 4 Mar 2002 17:06:38 -0500 (EST) Date: Mon, 4 Mar 2002 17:06:38 -0500 (EST) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: [f-cpu] elbrus In-Reply-To: <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Anything interesting/rlevant in this article on the elbrus? http://www.rons.net.cn/english/FSM/english/FSM/ISSUE02/e2k.pdf Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 4 23:24:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wf-00068B-00 for ; Tue, 05 Mar 2002 04:22:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:05 +0100 (CET) Received: (qmail 2748 invoked by uid 0); 4 Mar 2002 22:19:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 4 Mar 2002 22:19:29 -0000 Received: by moria.seul.org (Postfix) id 10AE514680E; Mon, 4 Mar 2002 17:19:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4389146805; Mon, 4 Mar 2002 17:19:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 2E56B14680E for ; Mon, 4 Mar 2002 17:19:26 -0500 (EST) Received: from f-cpu.org (kdl11-172.n.club-internet.fr [213.44.9.172]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 48FF616C4 for ; Mon, 4 Mar 2002 23:19:20 +0100 (CET) Message-ID: <3C83F42C.9C3C5CB5@f-cpu.org> Date: Mon, 04 Mar 2002 23:24:44 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] elbrus References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Graham Seaman wrote: > Anything interesting/rlevant in this article on the elbrus? > http://www.rons.net.cn/english/FSM/english/FSM/ISSUE02/e2k.pdf i can only say when i have downloaded all the 11MB through my modem :-( > Graham WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 4 12:08:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wg-00068B-01 for ; Tue, 05 Mar 2002 04:22:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:06 +0100 (CET) Received: (qmail 19183 invoked by uid 0); 4 Mar 2002 22:55:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Mar 2002 22:55:48 -0000 Received: by moria.seul.org (Postfix) id 170B4146805; Mon, 4 Mar 2002 17:55:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EFDD146817; Mon, 4 Mar 2002 17:55:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a232.home.uni-hannover.de [130.75.232.232]) by moria.seul.org (Postfix) with ESMTP id 22647146805 for ; Mon, 4 Mar 2002 17:55:43 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00502; Mon, 4 Mar 2002 12:08:11 +0100 Message-ID: <20020304120811.00180@thrai.stud.uni-hannover.de> Date: Mon, 4 Mar 2002 12:08:11 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> <002e01c1c319$e27d3660$bca45982@student.utwente.nl> <3C82DAAA.71938B0A@f-cpu.org> <001101c1c33b$801b63d0$bca45982@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001101c1c33b$801b63d0$bca45982@student.utwente.nl>; from Marco Al on Mon, Mar 04, 2002 at 06:14:46AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 04, 2002 at 06:14:46AM +0100, Marco Al wrote: [...] > http://www.ee.umd.edu/~blj/papers/ieeetc50-5.pdf > http://www.ee.umd.edu/~blj/papers/computer31-6.pdf > > Explain it "better" than me ... actually I only just realised that I was a > little hung up on the SASOS idea (for which you dont need segments). With > the example mechanism in the first paper normal per process memory spaces > are actually pretty trivial. The underlying global memory space still has to > be larger than with a standard scheme, because it has to accomodate the > total size of all the process spaces put together, but I doubt the costs are > something simplification of the caches and removal of the TLB wont cover. The main drawback is that you'll have to know the number of processes and the maximum total memory size in advance. You can do that in an embedded system (works pretty well there), but not in a general-purpose OS. I'll have a look at those papers anyway :) Maybe they trigger something... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 5 00:05:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wh-00068B-00 for ; Tue, 05 Mar 2002 04:22:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:07 +0100 (CET) Received: (qmail 19809 invoked by uid 0); 4 Mar 2002 22:59:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 4 Mar 2002 22:59:58 -0000 Received: by moria.seul.org (Postfix) id C4279146815; Mon, 4 Mar 2002 17:59:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9CB8414681A; Mon, 4 Mar 2002 17:59:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A6E07146815 for ; Mon, 4 Mar 2002 17:59:54 -0500 (EST) Received: from f-cpu.org (kdl21-59.n.club-internet.fr [213.44.96.59]) by relay-3v.club-internet.fr (Postfix) with ESMTP id CDD2916B3 for ; Mon, 4 Mar 2002 23:59:47 +0100 (CET) Message-ID: <3C83FDA7.AFB7844E@f-cpu.org> Date: Tue, 05 Mar 2002 00:05:11 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> <002e01c1c319$e27d3660$bca45982@student.utwente.nl> <3C82DAAA.71938B0A@f-cpu.org> <001101c1c33b$801b63d0$bca45982@student.utwente.nl> <20020304120811.00180@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Mar 04, 2002 at 06:14:46AM +0100, Marco Al wrote: > [...] > > http://www.ee.umd.edu/~blj/papers/ieeetc50-5.pdf > > http://www.ee.umd.edu/~blj/papers/computer31-6.pdf > > I'll have a look at those papers anyway :) > Maybe they trigger something... the links appears shaded so i have already donwloaded them. hmm, seems that's all i could ever do ;-) btw tomorrow is the first day of DATE ! who will attend the exhibition ? i will be there all days. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Mar 5 00:56:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wj-00068B-00 for ; Tue, 05 Mar 2002 04:22:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:09 +0100 (CET) Received: (qmail 2292 invoked by uid 0); 4 Mar 2002 23:56:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 4 Mar 2002 23:56:59 -0000 Received: by moria.seul.org (Postfix) id 800BC1468D5; Mon, 4 Mar 2002 18:56:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 777CA1468E4; Mon, 4 Mar 2002 18:56:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id EC80E1468D5 for ; Mon, 4 Mar 2002 18:56:53 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g24NupY15679 for ; Tue, 5 Mar 2002 00:56:51 +0100 Message-ID: <001401c1c3d8$416820e0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <000901c1c2a1$991e2f60$0dddc2d4@ifurita> <001e01c1c2d4$0726c080$bca45982@student.utwente.nl> <001301c1c2da$b47f8680$ebefc2d4@ifurita> <003901c1c2e3$af77e700$bca45982@student.utwente.nl> <001501c1c2eb$d53f8ee0$f49a2cd5@ifurita> <001401c1c2fc$1a2edaf0$bca45982@student.utwente.nl> <3C82BF79.70695273@f-cpu.org> <002e01c1c319$e27d3660$bca45982@student.utwente.nl> <3C82DAAA.71938B0A@f-cpu.org> <001101c1c33b$801b63d0$bca45982@student.utwente.nl> <20020304120811.00180@thrai.stud.uni-hannover.de> Subject: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Tue, 5 Mar 2002 00:56:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Michael Riepe" > The main drawback is that you'll have to know the number of processes and > the maximum total memory size in advance. You can do that in an embedded > system (works pretty well there), but not in a general-purpose OS. There is a difference between what you can do and what you can efficiently do. In such a scheme if you have say a 48 bit global address space and you are using 32 bit addresses with byte addressing you can efficiently run 65K processes with 2 GB address spaces each, that is not to say you cant run more you will just have to make changes in the global address space and either flush the cache or walk it to invalidate affected cachelines each time a process not on the list is "swapped" in. Would even a hard limit of 65K 4GB address spaces really present any issue for a general purpose OS though? :) Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 5 01:08:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wk-00068B-00 for ; Tue, 05 Mar 2002 04:22:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:10 +0100 (CET) Received: (qmail 16880 invoked by uid 0); 5 Mar 2002 00:03:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 5 Mar 2002 00:03:27 -0000 Received: by moria.seul.org (Postfix) id D182C1468D3; Mon, 4 Mar 2002 19:03:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3A9E1468E4; Mon, 4 Mar 2002 19:03:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4F2A01468D3 for ; Mon, 4 Mar 2002 19:03:24 -0500 (EST) Received: from f-cpu.org (kdl21-40.n.club-internet.fr [213.44.96.40]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1624B168D for ; Tue, 5 Mar 2002 01:03:15 +0100 (CET) Message-ID: <3C840C86.683438E6@f-cpu.org> Date: Tue, 05 Mar 2002 01:08:38 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] elbrus References: <3C83F42C.9C3C5CB5@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, Yann Guidon wrote: > Graham Seaman wrote: > > Anything interesting/rlevant in this article on the elbrus? > > http://www.rons.net.cn/english/FSM/english/FSM/ISSUE02/e2k.pdf > > i can only say when i have downloaded all the 11MB through my modem :-( after several attempts, i finally downloaded the whole file (my modem has hicups and the chinese server has no support for transmission recovery, so all the file has to be d/l again). Fortunately, the file compresses 2x during transmission. Frankly, from what i have read, ELBRUS looked to me like "good vaporware" and i'm still skeptic. really. They keep claiming things but i have never seen it "work". This "paper" (14 pages) gives some insights into the architecture philosophy. It is authored by Boris Babayan himself and copylefted, it appeared on a chines publication of some sort. However, i have not read it yet completely and it looks like the babbling that F-CPU did during its 6 first months of life... historical background, groundbreaking ideas... I have read the end a bit and have found some stuff which kernel gurus might laugh at. It seems ELBRUS is not designed for a Unix-like kernel, even BSD or HURD, maybe a russian OS. Particularly, the problem of the virus is described in a way which is ... "holé holé" and this surprises me, Boris being considered as the "Russian Seymour Cray". I still have to read the whole stuff with a fresh brain, after some days of sleep, but the link is interesting anyway. It both remembers me of F-CPU in the early stages and shows a bit from the russian computing culture. i'm puzzled but i didn't expect a miracle... > > Graham > WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Mar 5 01:43:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wl-00068B-00 for ; Tue, 05 Mar 2002 04:22:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:11 +0100 (CET) Received: (qmail 23216 invoked by uid 0); 5 Mar 2002 00:43:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 5 Mar 2002 00:43:15 -0000 Received: by moria.seul.org (Postfix) id 3175A146823; Mon, 4 Mar 2002 19:43:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C67C1468E4; Mon, 4 Mar 2002 19:43:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by moria.seul.org (Postfix) with ESMTP id 3238F146823 for ; Mon, 4 Mar 2002 19:43:06 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id g250h5Y17335 for ; Tue, 5 Mar 2002 01:43:05 +0100 Message-ID: <003e01c1c3de$b69aaa30$bca45982@student.utwente.nl> From: "Marco Al" To: References: <3C83F42C.9C3C5CB5@f-cpu.org> <3C840C86.683438E6@f-cpu.org> Subject: Re: [f-cpu] elbrus Date: Tue, 5 Mar 2002 01:43:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Yann Guidon" > I have read the end a bit and have found some stuff which kernel gurus > might laugh at. It seems ELBRUS is not designed for a Unix-like kernel, > even BSD or HURD, maybe a russian OS. Why do you say that? > Particularly, the problem > of the virus is described in a way which is ... "holé holé" and this > surprises me, Boris being considered as the "Russian Seymour Cray". They obviously need an English technical writer for proofreading, but this to me has always seemed one of their bigger features ... support for efficient hardware bounds checking to me seems a fine feature (this kind of µgrained protection is impossible to do with virtual memory, even with tagged TLB's ... well maybe virtual caches with 32 bit ID's and per cacheline tagging :). The filesystem they suggest is a bit out of the ordinary, seems some sort of memory mapped monstrosity, but you dont have to use it ... only if you want to use their security mechanism. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From robfinch@sympatico.ca Tue Mar 5 02:55:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16i5Wm-00068B-00 for ; Tue, 05 Mar 2002 04:22:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 04:22:12 +0100 (CET) Received: (qmail 24063 invoked by uid 0); 5 Mar 2002 01:55:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 5 Mar 2002 01:55:06 -0000 Received: by moria.seul.org (Postfix) id 0774B1468E5; Mon, 4 Mar 2002 20:55:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0429E1468E7; Mon, 4 Mar 2002 20:55:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by moria.seul.org (Postfix) with ESMTP id A5EF01468E5 for ; Mon, 4 Mar 2002 20:55:03 -0500 (EST) Received: from birdcomputer ([65.92.40.4]) by tomts22-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020305015554.BBRK2765.tomts22-srv.bellnexxia.net@birdcomputer> for ; Mon, 4 Mar 2002 20:55:54 -0500 Message-ID: <003401c1c3e8$c75eeac0$04285c41@birdcomputer> From: "Rob Finch" To: References: Subject: Re: [f-cpu] elbrus Date: Mon, 4 Mar 2002 20:55:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N It's a good article. As the article itself states most of what it says has been known for a few years already. I'm not sure I agree with it's prediction of future hardware / software scalability. Certainly, scheduling instructions in a superscaler architecture is a problem, but the architecture is able to make use of most of the available ILP. It may be true that a superscaler architecture does not scale well beyond a low ILP; however is it true that the ILP of general purpose apps will suddenly magically increase in the future? As I understand it: 1) Many general purpose algorithms have limited ILP by thier nature. Until we learn how to implement these algorithms in a parallel fashion, the ILP will not change. (In fact many apps are mandated to a certain level of ILP). No amount of software or hardware scheduling can fix this problem. The ILP will probably generally remain within bounds for which a superscaler architecture can provide good performance (my own prediction). 2) for general purpose applications the instruction level parallelism averages between two and three instructions( ie, its low). Yes, it is possible to implement a zillion functional units nowadays, but it does no good to have 25 functional units when only three of them are likely to be active at any one time. 3) As I see it, a program cannot execute faster than it can update the state of the machine and fetch operands. Are there processors out there with say 32 read ports and 16 write ports, in order to support issuing instructions to more functional units and completing several instructions at once ? (I really am curious). The other alternative is to build something like a barrel processor supporting SMT, but this isn't any better than a multiprocessor. I could go on... Rob ----- Original Message ----- From: "Graham Seaman" To: Sent: Monday, March 04, 2002 5:06 PM Subject: [f-cpu] elbrus > Anything interesting/rlevant in this article on the elbrus? > > > http://www.rons.net.cn/english/FSM/english/FSM/ISSUE02/e2k.pdf > > Graham > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 5 09:17:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iEcA-0003so-00 for ; Tue, 05 Mar 2002 14:04:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 14:04:22 +0100 (CET) Received: (qmail 28326 invoked by uid 0); 5 Mar 2002 08:17:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 5 Mar 2002 08:17:45 -0000 Received: by moria.seul.org (Postfix) id 3B9E6146805; Tue, 5 Mar 2002 03:17:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 316771468D5; Tue, 5 Mar 2002 03:17:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 8CE56146805 for ; Tue, 5 Mar 2002 03:17:42 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203050817.12d8; Tue, 5 Mar 2002 08:17:18 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Mar 2002 08:17:18 GMT Message-id: <200203050817.12d8@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nowadays isn't possible to create long term computer which m= anage only 4 Gb (it's the current physical limit of the pc)! 64 K process= it's far enough but it should address 1 To at least ! (nowdays big ma= chine address 64 Go) nicO -----Message d'origine----- De: "Marco Al" A: Date: 05/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed= cache ? From: "Michael Riepe" > The main drawback is that you'll have to know the number o= f processes and > the maximum total memory size in advance. You can do that = in an embedded > system (works pretty well there), but not in a general-pur= pose OS. There is a difference between what you can do and what you c= an efficiently do. In such a scheme if you have say a 48 bit global address= space and you are using 32 bit addresses with byte addressing you can effi= ciently run 65K processes with 2 GB address spaces each, that is not to say = you cant run more you will just have to make changes in the global addres= s space and either flush the cache or walk it to invalidate affected cac= helines each time a process not on the list is "swapped" in. Would even a= hard limit of 65K 4GB address spaces really present any issue for a genera= l purpose OS though? :) Marco ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 5 10:27:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iEcD-0003so-00 for ; Tue, 05 Mar 2002 14:04:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 14:04:25 +0100 (CET) Received: (qmail 11437 invoked by uid 0); 5 Mar 2002 09:28:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 5 Mar 2002 09:28:18 -0000 Received: by moria.seul.org (Postfix) id 2A77A1467FF; Tue, 5 Mar 2002 04:28:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 17E4E146815; Tue, 5 Mar 2002 04:28:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 66EF11467FF for ; Tue, 5 Mar 2002 04:28:15 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203050927.305e; Tue, 5 Mar 2002 09:27:48 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] elbrus From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Mar 2002 09:27:48 GMT Message-id: <200203050927.305e@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: "Rob Finch" A: Date: 05/03/02 Objet: Re: [f-cpu] elbrus It's a good article. As the article itself states most of wh= at it says has been known for a few years already. I'm not sure I agree wit= h it's prediction of future hardware / software scalability. Certai= nly, scheduling instructions in a superscaler architecture is a problem, but= the architecture is able to make use of most of the available IL= P. It may be true that a superscaler architecture does not scale well bey= ond a low ILP; however is it true that the ILP of general purpose apps will= suddenly magically increase in the future? As I understand it: 1) Man= y general purpose algorithms have limited ILP by thier nature. Until w= e learn how to >>> It's true and false. Average is about 3. BUT i have read= an article about compiling that show that the main point of bottelneck = is the dependance with the stack pointer. Without this kind of depe= ndance some program, from i don't remember which benchmark, could reach = an ilp of 100 ! implement these algorithms in a parallel fashion, the ILP wi= ll not change. (In fact many apps are mandated to a certain level of ILP). = No amount of software or hardware scheduling can fix this problem. The IL= P will probably generally remain within bounds for which a superscaler archi= tecture can provide good performance (my own prediction). 2) for general= purpose applications the instruction level parallelism averages betw= een two and three instructions( ie, its low). Yes, it is possible to imp= lement a zillion functional units nowadays, but it does no good to have 25 fu= nctional units when only three of them are likely to be active at any one t= ime. 3) As I see it, a program cannot execute faster than it can update the s= tate of the machine and fetch operands. Are there processors out there w= ith say 32 read ports and 16 write ports, in order to support issuing instru= ctions to more >>> 6w6r are common but in custom maid processor not in usua= l semi-custom design. functional units and completing several instructions at once= ? (I really am curious). The other alternative is to build something like a= barrel processor supporting SMT, but this isn't any better than a multiprocessor. >>> From the software point of view, it is not better BUT yo= u reach a far better use of the availaible silicon. Look at : http://www.cs.washington.edu/education/courses/471/00au/ the= re is a lot of slide quickly read and very easy to understand. nicO I could go on... Rob ----- Original Message ----- From: "Graham Seaman" To: Sent: Monday, March 04, 2002 5:06 PM Subject: [f-cpu] elbrus > Anything interesting/rlevant in this article on the elbrus= ? > > > http://www.rons.net.cn/english/FSM/english/FSM/ISSUE02/e2k= .pdf > > Graham > > **********************************************************= *** > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org= / > ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Mar 5 13:22:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iEcF-0003so-01 for ; Tue, 05 Mar 2002 14:04:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 05 Mar 2002 14:04:27 +0100 (CET) Received: (qmail 7067 invoked by uid 0); 5 Mar 2002 12:22:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 5 Mar 2002 12:22:29 -0000 Received: by moria.seul.org (Postfix) id 5692914680E; Tue, 5 Mar 2002 07:22:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 39EC2146815; Tue, 5 Mar 2002 07:22:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 6269014680E for ; Tue, 5 Mar 2002 07:22:27 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g25CMQM17117 for ; Tue, 5 Mar 2002 13:22:26 +0100 Message-ID: <000a01c1c440$69558d50$bca45982@student.utwente.nl> From: "Marco Al" To: References: <003401c1c3e8$c75eeac0$04285c41@birdcomputer> Subject: Re: [f-cpu] elbrus Date: Tue, 5 Mar 2002 13:22:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Rob Finch" > The other alternative is to build something like a barrel > processor supporting SMT, but this isn't any better than a multiprocessor. Define better ... its trivial to come up with situations where SMT gets you extra performance essentially for free as far as extra transistors is concerned, and in that respect a multiprocessor could never hope to match it. Hell the Hyperthreading benchmarks pretty much proove it in the real world! Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 5 10:54:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqP-0006v0-00 for ; Wed, 06 Mar 2002 08:28:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:13 +0100 (CET) Received: (qmail 10485 invoked by uid 0); 5 Mar 2002 14:18:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 5 Mar 2002 14:18:27 -0000 Received: by moria.seul.org (Postfix) id A894D1468E8; Tue, 5 Mar 2002 09:18:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B44E1468E5; Tue, 5 Mar 2002 09:18:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 467E41468D3 for ; Tue, 5 Mar 2002 09:18:26 -0500 (EST) Received: from ifurita (212.194.234.19) by mail.laposte.net (5.5.044) id 3C4C3539002D007E for f-cpu@seul.org; Tue, 5 Mar 2002 15:18:25 +0100 Message-ID: <000201c1c446$3e45c840$13eac2d4@ifurita> From: "Christophe" To: References: <200203050817.12d8@th00.opsion.fr> Subject: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Tue, 5 Mar 2002 10:54:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 64 KB process is not enough but threads can surely use less than 64 KB. I prefer to speak about teams and threads. I consider a team as a collection of threads sharing the same address space and resources. The minimal process (without pthread) is quite like a team in fact with one thread. If you take a big application a 64 KB space would be largely insufficient even if using several threads because code can exceed 64 KB ! ----- Original Message ----- From: Nicolas Boulay To: Sent: Tuesday, March 05, 2002 9:17 AM Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Nowadays isn't possible to create long term computer which manage only 4 Gb (it's the current physical limit of the pc)! 64 K process it's far enough but it should address 1 To at least ! (nowdays big machine address 64 Go) nicO -----Message d'origine----- De: "Marco Al" A: Date: 05/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Michael Riepe" > The main drawback is that you'll have to know the number of processes and > the maximum total memory size in advance. You can do that in an embedded > system (works pretty well there), but not in a general-purpose OS. There is a difference between what you can do and what you can efficiently do. In such a scheme if you have say a 48 bit global address space and you are using 32 bit addresses with byte addressing you can efficiently run 65K processes with 2 GB address spaces each, that is not to say you cant run more you will just have to make changes in the global address space and either flush the cache or walk it to invalidate affected cachelines each time a process not on the list is "swapped" in. Would even a hard limit of 65K 4GB address spaces really present any issue for a general purpose OS though? :) Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 5 15:32:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqQ-0006v0-01 for ; Wed, 06 Mar 2002 08:28:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:14 +0100 (CET) Received: (qmail 7603 invoked by uid 0); 5 Mar 2002 14:32:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 5 Mar 2002 14:32:31 -0000 Received: by moria.seul.org (Postfix) id 9C38C1468EA; Tue, 5 Mar 2002 09:32:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 998621468E5; Tue, 5 Mar 2002 09:32:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 63DC51468D5 for ; Tue, 5 Mar 2002 09:32:28 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203051432.1134; Tue, 5 Mar 2002 14:32:17 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Mar 2002 14:32:17 GMT Message-id: <200203051432.1134@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I wrote 64 K process, not 64 KB. It's just because i'm lazy = to write 65535 as Marco suggest it. Sorry, Christophe. nicO -----Message d'origine----- De: "Christophe" A: Date: 05/03/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-a= ddressed cache ? 64 KB process is not enough but threads can surely use less = than 64 KB. I prefer to speak about teams and threads. I consider a team= as a collection of threads sharing the same address space and resources. The mi= nimal process (without pthread) is quite like a team in fact with one thre= ad. If you take a big application a 64 KB space would be largely insufficient = even if using several threads because code can exceed 64 KB ! ----- Original Message ----- From: Nicolas Boulay To: Sent: Tuesday, March 05, 2002 9:17 AM Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-add= ressed cache ? Nowadays isn't possible to create long term computer which m= anage only 4 Gb (it's the current physical limit of the pc)! 64 K process= it's far enough but it should address 1 To at least ! (nowdays big ma= chine address 64 Go) nicO -----Message d'origine----- De: "Marco Al" A: Date: 05/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed= cache ? From: "Michael Riepe" > The main drawback is that you'll have to know the number o= f processes and > the maximum total memory size in advance. You can do that = in an embedded > system (works pretty well there), but not in a general-pur= pose OS. There is a difference between what you can do and what you c= an efficiently do. In such a scheme if you have say a 48 bit global address= space and you are using 32 bit addresses with byte addressing you can effi= ciently run 65K processes with 2 GB address spaces each, that is not to say = you cant run more you will just have to make changes in the global addres= s space and either flush the cache or walk it to invalidate affected cac= helines each time a process not on the list is "swapped" in. Would even a= hard limit of 65K 4GB address spaces really present any issue for a genera= l purpose OS though? :) Marco ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= ____________ ______ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Mar 5 15:45:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqR-0006v0-00 for ; Wed, 06 Mar 2002 08:28:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:15 +0100 (CET) Received: (qmail 2058 invoked by uid 0); 5 Mar 2002 14:45:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 5 Mar 2002 14:45:38 -0000 Received: by moria.seul.org (Postfix) id 58C4D1468D5; Tue, 5 Mar 2002 09:45:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52E691468EB; Tue, 5 Mar 2002 09:45:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 8B6741468D5 for ; Tue, 5 Mar 2002 09:45:36 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g25EjZY26723 for ; Tue, 5 Mar 2002 15:45:35 +0100 Message-ID: <000d01c1c454$69227f50$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203050817.12d8@th00.opsion.fr> <000201c1c446$3e45c840$13eac2d4@ifurita> Subject: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Date: Tue, 5 Mar 2002 15:45:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > 64 KB process is not enough but threads can surely use less than 64 KB. Not processes with 64 KB memory space :) 64K processes which can share the global address space at the same time, in the example 65536 processes can have 4 GB address spaces (half that would be kernel space of course). Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Mar 5 16:19:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqT-0006v0-00 for ; Wed, 06 Mar 2002 08:28:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:17 +0100 (CET) Received: (qmail 16745 invoked by uid 0); 5 Mar 2002 15:19:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 5 Mar 2002 15:19:49 -0000 Received: by moria.seul.org (Postfix) id 7CD761468F1; Tue, 5 Mar 2002 10:19:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A6ED1468EF; Tue, 5 Mar 2002 10:19:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 825D31468E5 for ; Tue, 5 Mar 2002 10:19:46 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-208.jetnet.ab.ca [207.34.60.208]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA01486 for ; Tue, 5 Mar 2002 08:19:44 -0700 (MST) Message-ID: <3C84E1F0.1F496746@jetnet.ab.ca> Date: Tue, 05 Mar 2002 08:19:12 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? References: <200203050817.12d8@th00.opsion.fr> <000201c1c446$3e45c840$13eac2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > There is a difference between what you can do and what you can > efficiently > do. In such a scheme if you have say a 48 bit global address space and > you > are using 32 bit addresses with byte addressing you can efficiently run > 65K > processes with 2 GB address spaces each, that is not to say you cant run > more you will just have to make changes in the global address space and > either flush the cache or walk it to invalidate affected cachelines each > time a process not on the list is "swapped" in. Would even a hard limit > of > 65K 4GB address spaces really present any issue for a general purpose OS > though? :) But really what runs 65K processes at once? In all fairness to the CPU really should run 1 process. Need another process ... buy a second , third... A large system while it does have need for large taskes and addresses space is really a network of interconnected computers and would not the network define what process runs where and addressing. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Mar 5 18:17:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqX-0006v0-00 for ; Wed, 06 Mar 2002 08:28:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:21 +0100 (CET) Received: (qmail 26339 invoked by uid 0); 5 Mar 2002 17:46:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 5 Mar 2002 17:46:24 -0000 Received: by moria.seul.org (Postfix) id AAC421468E3; Tue, 5 Mar 2002 12:46:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 558FE1468EA; Tue, 5 Mar 2002 12:46:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 910B81468E3 for ; Tue, 5 Mar 2002 12:46:19 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16iIZN-0001cP-00 for f-cpu@seul.org; Tue, 5 Mar 2002 18:17:45 +0100 Date: Tue, 5 Mar 2002 18:17:44 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] virtually or physically-addressed cache ? In-Reply-To: <3C84E1F0.1F496746@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 5 Mar 2002, Ben Franchuk wrote: > Christophe wrote: > > > There is a difference between what you can do and what you can > > efficiently > > do. In such a scheme if you have say a 48 bit global address space and > > you > > are using 32 bit addresses with byte addressing you can efficiently run > > 65K > > processes with 2 GB address spaces each, that is not to say you cant run > > more you will just have to make changes in the global address space and > > either flush the cache or walk it to invalidate affected cachelines each > > time a process not on the list is "swapped" in. Would even a hard limit > > of > > 65K 4GB address spaces really present any issue for a general purpose OS > > though? :) > > But really what runs 65K processes at once? In all fairness to the CPU > really should run 1 process. Need another process ... buy a second , > third... A large system while it does have need for large taskes and > addresses space is really a network of interconnected computers and > would not the network define what process runs where and addressing. :-) Yes, this is one way. Optimize a single execution unit for max performance with limited number of tasks. But you get a price to pay for communication performance when things grow bigger. It's always a problem to optimize the data use, i.e. data exchange between the tasks/processes. And you also get some restrictions from the max execution performance. I go for pipelined operation with only few tasks per processor with my new product. But these tasks get a fully optimized fast network support in hardware. BTW this discussion seems to be a continuation of the mainframe vs. PC discussion that was held some years ago. And the basic theme beyond is 'have all in one instance' (master concept) or 'divide into many independent instances' (distributed concept). I believe the distributed concept will beat the master concept anyway because it is better regarding failsafe of the whole and further development of the components. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 5 17:39:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqY-0006v0-00 for ; Wed, 06 Mar 2002 08:28:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:22 +0100 (CET) Received: (qmail 30348 invoked by uid 0); 5 Mar 2002 17:53:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Mar 2002 17:53:27 -0000 Received: by moria.seul.org (Postfix) id 155941468E5; Tue, 5 Mar 2002 12:53:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC3231468EA; Tue, 5 Mar 2002 12:53:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id A03EF1468E5 for ; Tue, 5 Mar 2002 12:53:22 -0500 (EST) Received: from ifurita (212.194.252.1) by mail.laposte.net (5.5.044) id 3C4BFED4002DD3C8 for f-cpu@seul.org; Tue, 5 Mar 2002 18:53:20 +0100 Message-ID: <001c01c1c464$448009a0$01fcc2d4@ifurita> From: "Christophe" To: References: <200203051432.1134@th00.opsion.fr> Subject: [f-cpu] 64 K processes Date: Tue, 5 Mar 2002 17:39:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ok ok I misunderstood :) Well suppose that 64 K processES are running, do you compute how much it takes as physical memory for all 64 K processes if we use a hierachical paging for example ? Ok take an example from ia32 : paging is 2-level : pde = pdbr[virtaddr(31..22)].pde; pte = pde[virtaddr(21..12)].pte; physaddr = pte.pfn + virtaddr(11..0); So for 64 K processes we need 64 K pdbrs, i.e, 64 K x 4 KB = 256 MB (ouch ! our pdbrs will take 256 MB). Now if each process has, say, a 16 MB virtual space, we also need 16 MB / 4 MB for pdes, i.e, 4 pdes and 16 MB / 4 KB for ptes, i.e, 4 K ptes. I'm speaking about the worst case where all page frames are not shared !!! So for 64 K processes we get at least 256 MB + (64 K x 4 x 4 KB) = 512 MB + 1024 MB = 1,5 MB if we suppose all ptes have invalid page frame ! quite impressive isn't it ? well my computer can handle only a max of 1,5 MB so using 64 K processes with an average of 16 MB virtal space is impossible on my computer. ----- Original Message ----- From: Nicolas Boulay To: Sent: Tuesday, March 05, 2002 3:32 PM Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? I wrote 64 K process, not 64 KB. It's just because i'm lazy to write 65535 as Marco suggest it. Sorry, Christophe. nicO -----Message d'origine----- De: "Christophe" A: Date: 05/03/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? 64 KB process is not enough but threads can surely use less than 64 KB. I prefer to speak about teams and threads. I consider a team as a collection of threads sharing the same address space and resources. The minimal process (without pthread) is quite like a team in fact with one thread. If you take a big application a 64 KB space would be largely insufficient even if using several threads because code can exceed 64 KB ! ----- Original Message ----- From: Nicolas Boulay To: Sent: Tuesday, March 05, 2002 9:17 AM Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? Nowadays isn't possible to create long term computer which manage only 4 Gb (it's the current physical limit of the pc)! 64 K process it's far enough but it should address 1 To at least ! (nowdays big machine address 64 Go) nicO -----Message d'origine----- De: "Marco Al" A: Date: 05/03/02 Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? From: "Michael Riepe" > The main drawback is that you'll have to know the number of processes and > the maximum total memory size in advance. You can do that in an embedded > system (works pretty well there), but not in a general-purpose OS. There is a difference between what you can do and what you can efficiently do. In such a scheme if you have say a 48 bit global address space and you are using 32 bit addresses with byte addressing you can efficiently run 65K processes with 2 GB address spaces each, that is not to say you cant run more you will just have to make changes in the global address space and either flush the cache or walk it to invalidate affected cachelines each time a process not on the list is "swapped" in. Would even a hard limit of 65K 4GB address spaces really present any issue for a general purpose OS though? :) Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ________________________________________________________________________ ______ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 5 17:43:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqZ-0006v0-00 for ; Wed, 06 Mar 2002 08:28:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:23 +0100 (CET) Received: (qmail 21796 invoked by uid 0); 5 Mar 2002 17:57:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 5 Mar 2002 17:57:58 -0000 Received: by moria.seul.org (Postfix) id 680B91468E5; Tue, 5 Mar 2002 12:57:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 309171468EA; Tue, 5 Mar 2002 12:57:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 985381468E5 for ; Tue, 5 Mar 2002 12:57:56 -0500 (EST) Received: from ifurita (212.194.252.1) by mail.laposte.net (5.5.044) id 3C4C0259002C6150 for f-cpu@seul.org; Tue, 5 Mar 2002 18:57:54 +0100 Message-ID: <002a01c1c464$e7d5b280$01fcc2d4@ifurita> From: "Christophe" To: References: <200203051432.1134@th00.opsion.fr> <001c01c1c464$448009a0$01fcc2d4@ifurita> Subject: Re: [f-cpu] 64 K processes Date: Tue, 5 Mar 2002 17:43:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Mistake : 1,5 MB must be read 1,5 GB !!! ----- Original Message ----- From: Christophe To: Sent: Tuesday, March 05, 2002 5:39 PM Subject: [f-cpu] 64 K processes > ok ok I misunderstood :) > > Well suppose that 64 K processES are running, do you compute how much it takes > as physical memory for all 64 K processes if we use a hierachical paging for > example ? > > Ok take an example from ia32 : > > paging is 2-level : > > pde = pdbr[virtaddr(31..22)].pde; > pte = pde[virtaddr(21..12)].pte; > physaddr = pte.pfn + virtaddr(11..0); > > So for 64 K processes we need 64 K pdbrs, i.e, 64 K x 4 KB = 256 MB (ouch ! our > pdbrs will take 256 MB). > > Now if each process has, say, a 16 MB virtual space, we also need 16 MB / 4 MB > for pdes, i.e, 4 pdes and 16 MB / 4 KB for ptes, i.e, 4 K ptes. I'm speaking > about the worst case where all page frames are not shared !!! > > So for 64 K processes we get at least 256 MB + (64 K x 4 x 4 KB) = 512 MB + > 1024 MB = 1,5 MB if we suppose all ptes have invalid page frame ! quite > impressive isn't it ? > > well my computer can handle only a max of 1,5 MB so using 64 K processes with > an average of 16 MB virtal space is impossible on my computer. > > ----- Original Message ----- > From: Nicolas Boulay > To: > Sent: Tuesday, March 05, 2002 3:32 PM > Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed > cache ? > > > I wrote 64 K process, not 64 KB. It's just because i'm lazy to write > 65535 as Marco suggest it. > Sorry, Christophe. > > nicO > > -----Message d'origine----- > De: "Christophe" > A: > Date: 05/03/02 > Objet: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed > cache ? > > 64 KB process is not enough but threads can surely use less than 64 KB. > > I prefer to speak about teams and threads. I consider a team as a > collection of > threads sharing the same address space and resources. The minimal > process > (without pthread) is quite like a team in fact with one thread. If you > take a > big application a 64 KB space would be largely insufficient even if > using > several threads because code can exceed 64 KB ! > > ----- Original Message ----- > From: Nicolas Boulay > To: > Sent: Tuesday, March 05, 2002 9:17 AM > Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache > ? > > > Nowadays isn't possible to create long term computer which manage only 4 > Gb (it's the current physical limit of the pc)! 64 K process it's far > enough but it should address 1 To at least ! (nowdays big machine > address 64 Go) > > nicO > > -----Message d'origine----- > De: "Marco Al" > A: > Date: 05/03/02 > Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ? > > From: "Michael Riepe" > > > The main drawback is that you'll have to know the number of processes > and > > the maximum total memory size in advance. You can do that in an > embedded > > system (works pretty well there), but not in a general-purpose OS. > > There is a difference between what you can do and what you can > efficiently > do. In such a scheme if you have say a 48 bit global address space and > you > are using 32 bit addresses with byte addressing you can efficiently run > 65K > processes with 2 GB address spaces each, that is not to say you cant run > more you will just have to make changes in the global address space and > either flush the cache or walk it to invalidate affected cachelines each > time a process not on the list is "swapped" in. Would even a hard limit > of > 65K 4GB address spaces really present any issue for a general purpose OS > though? :) > > Marco > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > ________________________________________________________________________ > ______ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > ______________________________________________________________________________ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Mar 5 19:42:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqd-0006v0-00 for ; Wed, 06 Mar 2002 08:28:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:27 +0100 (CET) Received: (qmail 29965 invoked by uid 0); 5 Mar 2002 18:42:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 5 Mar 2002 18:42:35 -0000 Received: by moria.seul.org (Postfix) id C45891468E3; Tue, 5 Mar 2002 13:42:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BFC591468E8; Tue, 5 Mar 2002 13:42:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id C51981468E3 for ; Tue, 5 Mar 2002 13:42:32 -0500 (EST) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g25IgWa08922 for ; Tue, 5 Mar 2002 19:42:32 +0100 Message-ID: <001a01c1c475$82b91570$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200203051432.1134@th00.opsion.fr> <001c01c1c464$448009a0$01fcc2d4@ifurita> Subject: Re: [f-cpu] 64 K processes Date: Tue, 5 Mar 2002 19:42:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N From: "Christophe" > ok ok I misunderstood :) > > Well suppose that 64 K processES are running, do you compute how much it takes > as physical memory for all 64 K processes if we use a hierachical paging for > example ? As I said, even a hard limit of that many processes would not be a problem. It was just to show that needing a global memory space to which segments provide windows which build up the per process memory spaces does not present any significant problem (it shouldnt, PowerPC uses it after all ... although they still use a hardware TLB) not even for a general purpose OS. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 6 00:49:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqt-0006v0-00 for ; Wed, 06 Mar 2002 08:28:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:43 +0100 (CET) Received: (qmail 32166 invoked by uid 0); 5 Mar 2002 23:43:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 5 Mar 2002 23:43:56 -0000 Received: by moria.seul.org (Postfix) id 828841467F2; Tue, 5 Mar 2002 18:43:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78D8C1468E8; Tue, 5 Mar 2002 18:43:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 495CA1467F2 for ; Tue, 5 Mar 2002 18:43:53 -0500 (EST) Received: from f-cpu.org (kdl11-1.n.club-internet.fr [213.44.9.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id DB7591691 for ; Wed, 6 Mar 2002 00:43:48 +0100 (CET) Message-ID: <3C85597A.A39A22D2@f-cpu.org> Date: Wed, 06 Mar 2002 00:49:14 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] elbrus References: <3C83F42C.9C3C5CB5@f-cpu.org> <3C840C86.683438E6@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N mostly an update : i spoken to a russian design company (who actually produced working chips : http://www.module.ru, i got theirs CDROM) and asked : "what do you think about Elbrus ?" the answer was : "i would like to see one." I believe that they know more about it than me, so i think that their opinion is more valuable than mine, but we seem to agree. I don't want to justify, but it's easier for this company to speak this way about Elbrus, whatever it is, since Module has working products and a business :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 6 00:49:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqt-0006v0-01 for ; Wed, 06 Mar 2002 08:28:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:43 +0100 (CET) Received: (qmail 21860 invoked by uid 0); 5 Mar 2002 23:44:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 5 Mar 2002 23:44:01 -0000 Received: by moria.seul.org (Postfix) id 70345146801; Tue, 5 Mar 2002 18:43:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 522111468EA; Tue, 5 Mar 2002 18:43:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 28CFB146801; Tue, 5 Mar 2002 18:43:54 -0500 (EST) Received: from f-cpu.org (kdl11-1.n.club-internet.fr [213.44.9.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 0EE5416AA; Wed, 6 Mar 2002 00:43:47 +0100 (CET) Message-ID: <3C855978.C0725D63@f-cpu.org> Date: Wed, 06 Mar 2002 00:49:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] DATE2002, day 1 report Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, The DATE2002 exhibition started today in Paris. This european (and in fact, second worldwide ?) EDA and microelectronics company gathering is 2x larger than last year (in Munich), it took me a whole day before i saw most booths. It is also very positive from the point of view of F-CPU and "open source HW designs" : i have a lot of good news. First i was nicely helped by Cadence engineers on their booth, they quickly gave me some insights on ncsim (that is installed on my laptop, which i brought) and they don't seem afraid of helping an "open source project made by hobbyists" : they were enthusiastic about their product and tried to share some knowledge. It is good to see such a large company having this behaviour with someone who is not a "customer" and i apreciated it. Thanks to Martyn Pollard's help, i was welcome and i hope to continue to work in such good terms. I have also met someone from a company called "bridges2silicon" (using Aptix hardware) who uses Wishbone as a demo application. He is interested by the "free hardware movement" so i pointed him to the Opencollector.org site. I was surprised by his reaction, the opposite from the ARM representatives in Munich last year ;-) I hope we can partner in a way or another. I have seeked help from most emulator makers : too early. this is a way of saying that making F-CPU run on a FPGA or a dedicated machine which is connected to a dedicated online development server is not going to become a reality soon. Look at http://www.f-cpu.org/EDAserver.html for more background about what was thought a year ago. One company's representative was not "disturbed" by this idea, though. He works for ISYTEC (a german company which is represented in France by Answer Systems). There are still two problems : it depends on "heavy proprietary software" to synthesise the FPGA bitstreams, and the HW is very expensive too. Concerning the sharing and hosting of VHDL synthesis ressources, i think that it could be possible if we team with a french VHDL club that is currently being created in a french computer school (epita.fr). They have "suitable" machine rooms (cooled, with enough electric power and internet connexion) and thousands of students from which at least a few might help 24/7 (server configuration/administration, maintainance etc.) but now the problem is to get an emulator/FPGA board with the corresponding licences and support software. The shared emulator problem is still being discussed by the french F-CPU team. There might be a solution at a time or another. I would be happy to get help from my last employer, because even an "old" machine should be enough for fitting a whole F-CPU. Unfortunately, experience shows that if it was possible, we would have had it already. Later, while discussing with a sales/marketing manager, the old synthesis problem popped up and he directed me straight to someone from Synopsys. It was the end of the day so i was not surprised anymore (after all what happened). I have the address of a person to contact and i wish that the good star will continue to shine, because synthesis is currently the #1 problem for F-CPU. OTOH, being in contact with the 3 leading EDA companies makes my personal situation difficult. Having worked for Meta Systems (the emulator branch of Mentor Graphics), i have to be very careful because these companies are always in court against each others. I wish we could work together in good terms and avoid any useless tension. "Design and let design". I did not have time to say "hello" on all the booths, so the panorama is not finished. For example, i have to return to some booths, such as this of EUROPRACTIVE where they will explain me the issue of the fundrie's design kits. This day was very tiring but unexpectedly positive, in a period of economic degradation. i thought that my F-CPU lobbying would look misplaced but in contrary, i was more helped in a single day than during months. What looked like an utopia 3 years ago (and it was one) is now becoming a tangible reality : LEON and OPENCORES are now credible and F-CPU should follow, since we have some good code now. I'll be at DATE tomorrow, where i meet Nicole Ciry (from APRIL/FSF Europe, who helps us setting up the french F-CPU association) at 12, near the entrance. If you want to join, be there :-) [for those in/around Paris] WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: ok for publication. PS2: i found a new/better barrel shifter structure this morning in the metro :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 6 00:55:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqu-0006v0-00 for ; Wed, 06 Mar 2002 08:28:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:44 +0100 (CET) Received: (qmail 3089 invoked by uid 0); 5 Mar 2002 23:55:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 5 Mar 2002 23:55:51 -0000 Received: by moria.seul.org (Postfix) id DB5971468E5; Tue, 5 Mar 2002 18:55:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C4F3A1468EA; Tue, 5 Mar 2002 18:55:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a107.home.uni-hannover.de [130.75.232.107]) by moria.seul.org (Postfix) with ESMTP id 5F2801468E5 for ; Tue, 5 Mar 2002 18:55:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01838; Wed, 6 Mar 2002 00:55:39 +0100 Message-ID: <20020306005539.39607@thrai.stud.uni-hannover.de> Date: Wed, 6 Mar 2002 00:55:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DATE2002, day 1 report References: <3C855978.C0725D63@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C855978.C0725D63@f-cpu.org>; from Yann Guidon on Wed, Mar 06, 2002 at 12:49:12AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 06, 2002 at 12:49:12AM +0100, Yann Guidon wrote: [...] > PS2: i found a new/better barrel shifter structure > this morning in the metro :-) Faster? Details? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 6 02:32:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16iVqy-0006v0-00 for ; Wed, 06 Mar 2002 08:28:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 06 Mar 2002 08:28:48 +0100 (CET) Received: (qmail 27888 invoked by uid 0); 6 Mar 2002 01:26:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Mar 2002 01:26:52 -0000 Received: by moria.seul.org (Postfix) id 36D1C1467FE; Tue, 5 Mar 2002 20:26:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A99014680C; Tue, 5 Mar 2002 20:26:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A42891467FE for ; Tue, 5 Mar 2002 20:26:48 -0500 (EST) Received: from f-cpu.org (kdl21-2.n.club-internet.fr [213.44.96.2]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 2C5021693 for ; Wed, 6 Mar 2002 02:26:44 +0100 (CET) Message-ID: <3C85719A.2979C21C@f-cpu.org> Date: Wed, 06 Mar 2002 02:32:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: <3C855978.C0725D63@f-cpu.org> <20020306005539.39607@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Wed, Mar 06, 2002 at 12:49:12AM +0100, Yann Guidon wrote: > [...] > > PS2: i found a new/better barrel shifter structure > > this morning in the metro :-) > > Faster? Details? :-D what a quick answer ! btw, i met people from the Hannover university, i talked about you with someone :-) For the shifter idea, it is very simple, maybe easier to understand than the reversed Omega network. My constraints are : reduce crosstalk problems, have a simple routing algorithm (which easily supports SIMD) have a simple building block from which i can make a scalable (64+) unit without wire lenght problems. The solution does not involve 2-mux gates but 3-mux gates. It does not solve Xtalk problems but routing is very simple, too (full-custom version is really easy). The principle is that there are 3 wiring layers : one with does not shift, the other shifts right and the other shifts left, 16 bits at a time (which is a reasonable wire length). Because it is highly regular, place and route is straight-forward (though there are exceptions with the rightmost and leftmost versions with a 2-mux only). The problem is that the speed of the circuit depends on the wire length so having a wire that crosses a lot of wires can become a problem. I think that the Omega network is not optimal because the longest wire wross 32 wires for the 64 bit version. if it scales up, it increases to 64... Furthermore, some permutations make the path much longer than the shortest geometrical path (a line) from the input to the output, the signal zig-zags through it. I use a more straight-forward (naive ?) way, but the unit is split into three : one performs SDUP (so one register operand can serve to control the shift amount), the other part is a 2-stage 4-mux shift/rotate for doing 8-bit and 16-bit shifts/rotates, and the last part is a series of 16-bit (only 16 bits left, 16-bits right or no shift) blocks. Because we have still to shift 64-16 bits, there are 48/16=3 16-bit shift block layers. But i'll have to rest a bit before i write documentation, code and draw stuffs. be patient, DATE has only begun :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Wed Mar 6 18:47:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ir9s-0004Pk-00 for ; Thu, 07 Mar 2002 07:13:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 07:13:44 +0100 (CET) Received: (qmail 10616 invoked by uid 0); 6 Mar 2002 17:50:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Mar 2002 17:50:08 -0000 Received: by moria.seul.org (Postfix) id 2F1611467EF; Wed, 6 Mar 2002 12:50:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24FB11467F6; Wed, 6 Mar 2002 12:50:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 343531467EF for ; Wed, 6 Mar 2002 12:50:06 -0500 (EST) Received: from art1.none.de ([62.144.176.132]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g26Ho8t10800 for ; Wed, 6 Mar 2002 18:50:09 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.176.132] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16ifW8-0000iT-00 for ; Wed, 06 Mar 2002 18:47:56 +0100 Date: Wed, 6 Mar 2002 18:47:08 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) In-Reply-To: <3C85719A.2979C21C@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello YG, > For the shifter idea, it is very simple, maybe easier > to understand than the reversed Omega network. Could be an additional solution a convolution network, means a network with bidirectional stages? Example: 6 stages (3 physically) 9 nodes I/O (left) # -> nodes or switches # # # - -#----------#----------#----+ # # # | - -#-\ /-#-\ /-#---+| # \ / # \ / # || - -#-\ \ / /-#-\ \ / /-#--+|| # \ \/ / # \ \/ / #-+||| \/\| |/\/ |||| /\ \ / /\ |||| # / | |\ # /| | \ #-+||| - -#-/ | | \-#-/ | | \-#--+|| # | | # | | # || - -#----------#----------# || # | | # | | # || - -#-\ | / /-#-\ | | /-#--+|| # \ \/ / # \ \/ / #-+||| \/\/ \/\/ |||| /\/\ /\/\ |||| # / /\ \ # / /\ \ #-+||| - -#-/ / \ \-#-/ / \ \-#--+|| # / \ # / \ # || - -#-/ \-#-/ \-#---+| # # # | - -#----------#----------#----+ # # # Any hints? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8hlYgClxplZklbgERAi40AJ9evcZfI2WCXQqDFbdpUoeELCX1ZQCfcm2w 9AHdLsvGdR13tuTODfrMmLo= =nLBQ -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Mar 6 20:02:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ir9s-0004Pk-01 for ; Thu, 07 Mar 2002 07:13:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 07:13:44 +0100 (CET) Received: (qmail 27306 invoked by uid 0); 6 Mar 2002 19:07:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 6 Mar 2002 19:07:08 -0000 Received: by moria.seul.org (Postfix) id E5C381467EF; Wed, 6 Mar 2002 14:07:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCCC81467F6; Wed, 6 Mar 2002 14:07:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 064931467EF for ; Wed, 6 Mar 2002 14:07:04 -0500 (EST) Received: (qmail 67698 invoked by uid 85); 6 Mar 2002 19:06:09 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.146281 secs); 06 Mar 2002 19:06:09 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 6 Mar 2002 19:06:09 -0000 Message-ID: <3C8667B2.2020002@yahoo.fr> Date: Wed, 06 Mar 2002 20:02:10 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] About DATE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I am enjoy to contact every body of the group on my society booth : TNI-Valiosys (C7) Demand Renaud. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 6 12:18:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16irA0-0004Pk-00 for ; Thu, 07 Mar 2002 07:13:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 07:13:52 +0100 (CET) Received: (qmail 8027 invoked by uid 0); 6 Mar 2002 23:13:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Mar 2002 23:13:31 -0000 Received: by moria.seul.org (Postfix) id 95C0614640E; Wed, 6 Mar 2002 18:13:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7681B1467F0; Wed, 6 Mar 2002 18:13:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a045.home.uni-hannover.de [130.75.232.45]) by moria.seul.org (Postfix) with ESMTP id DFD7414640E for ; Wed, 6 Mar 2002 18:13:25 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00575; Wed, 6 Mar 2002 12:18:39 +0100 Message-ID: <20020306121839.30684@thrai.stud.uni-hannover.de> Date: Wed, 6 Mar 2002 12:18:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: <3C855978.C0725D63@f-cpu.org> <20020306005539.39607@thrai.stud.uni-hannover.de> <3C85719A.2979C21C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C85719A.2979C21C@f-cpu.org>; from Yann Guidon on Wed, Mar 06, 2002 at 02:32:10AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 06, 2002 at 02:32:10AM +0100, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > On Wed, Mar 06, 2002 at 12:49:12AM +0100, Yann Guidon wrote: > > [...] > > > PS2: i found a new/better barrel shifter structure > > > this morning in the metro :-) > > > > Faster? Details? > > :-D what a quick answer ! After all those off-topic discussions, I'm glad to hear something about f-cpu development again ;) > btw, i met people from the Hannover university, > i talked about you with someone :-) He probably didn't know me, did he? > For the shifter idea, it is very simple, maybe easier > to understand than the reversed Omega network. [...] > I use a more straight-forward (naive ?) way, but the unit is > split into three : one performs SDUP (so one register operand can > serve to control the shift amount), the other part is a 2-stage > 4-mux shift/rotate for doing 8-bit and 16-bit shifts/rotates, > and the last part is a series of 16-bit (only 16 bits left, 16-bits > right or no shift) blocks. Because we have still to shift 64-16 bits, > there are 48/16=3 16-bit shift block layers. How do you build the bit-shifter - full 16x16 matrix? > But i'll have to rest a bit before i write > documentation, code and draw stuffs. be patient, DATE has only begun :-) Please let me know when you have some code to look at. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Mar 7 01:39:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16irA1-0004Pk-01 for ; Thu, 07 Mar 2002 07:13:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 07:13:53 +0100 (CET) Received: (qmail 768 invoked by uid 0); 7 Mar 2002 00:34:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 7 Mar 2002 00:34:07 -0000 Received: by moria.seul.org (Postfix) id 82C141467F0; Wed, 6 Mar 2002 19:34:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79CE71467F6; Wed, 6 Mar 2002 19:34:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 1D77C1467F0 for ; Wed, 6 Mar 2002 19:34:05 -0500 (EST) Received: from f-cpu.org (kdl16-3.n.club-internet.fr [213.44.18.3]) by relay-4v.club-internet.fr (Postfix) with ESMTP id ADEA016F6 for ; Thu, 7 Mar 2002 01:34:02 +0100 (CET) Message-ID: <3C86B6C2.6511B43B@f-cpu.org> Date: Thu, 07 Mar 2002 01:39:30 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] About DATE References: <3C8667B2.2020002@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Just an Illusion wrote: > Hello, > > I am enjoy to contact every body of the group on my society booth : > TNI-Valiosys (C7) > > Demand Renaud. i'll do. if i knew about that before, i would have done it yesterday :-) see you soon this afternoon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Mar 7 02:37:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16irA1-0004Pk-02 for ; Thu, 07 Mar 2002 07:13:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 07:13:53 +0100 (CET) Received: (qmail 25170 invoked by uid 0); 7 Mar 2002 01:31:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 7 Mar 2002 01:31:52 -0000 Received: by moria.seul.org (Postfix) id 7ACEF1467F0; Wed, 6 Mar 2002 20:31:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69A301467F7; Wed, 6 Mar 2002 20:31:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id DA9A81467F0 for ; Wed, 6 Mar 2002 20:31:46 -0500 (EST) Received: from f-cpu.org (kdl16-7.n.club-internet.fr [213.44.18.7]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 7F7F616B1 for ; Thu, 7 Mar 2002 02:31:43 +0100 (CET) Message-ID: <3C86C448.CD53CF96@f-cpu.org> Date: Thu, 07 Mar 2002 02:37:12 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: <3C855978.C0725D63@f-cpu.org> <20020306005539.39607@thrai.stud.uni-hannover.de> <3C85719A.2979C21C@f-cpu.org> <20020306121839.30684@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Michael Riepe wrote: > On Wed, Mar 06, 2002 at 02:32:10AM +0100, Yann Guidon wrote: > > hi ! > > > > Michael Riepe wrote: > > > On Wed, Mar 06, 2002 at 12:49:12AM +0100, Yann Guidon wrote: > > > [...] > > > > PS2: i found a new/better barrel shifter structure > > > > this morning in the metro :-) > > > Faster? Details? > > :-D what a quick answer ! > After all those off-topic discussions, I'm glad to hear something > about f-cpu development again ;) same with me ;-) > > btw, i met people from the Hannover university, > > i talked about you with someone :-) > He probably didn't know me, did he? he said he did, but you don't belong to the same part of the university. If he meets you, i told him to say "hi" :-) > > For the shifter idea, it is very simple, maybe easier > > to understand than the reversed Omega network. > [...] > > I use a more straight-forward (naive ?) way, but the unit is > > split into three : one performs SDUP (so one register operand can > > serve to control the shift amount), the other part is a 2-stage > > 4-mux shift/rotate for doing 8-bit and 16-bit shifts/rotates, > > and the last part is a series of 16-bit (only 16 bits left, 16-bits > > right or no shift) blocks. Because we have still to shift 64-16 bits, > > there are 48/16=3 16-bit shift block layers. > > How do you build the bit-shifter - full 16x16 matrix? not "full" because these shifter only shift 16|0|-16 bits, so there's a stage that performs the fine shifts. However having limited-length wires (crossing a maximum of 16 bits, whatever the size) certainly helps from the signal point of view. Since the propagation delay is roughly proportional to the square of the distance, having a minimal-stage barrel shifter is not the best solution anymore because some wires are very long. So i designed the shifter with that idea in mind. My mistake was maybe to want to reuse existing networks and modify them. Instead, the solution appeared logical to me when i wasn't influenced by the self-routing properties and the limitation to 2-port routers. A 3-port switch element requires 3 metal levels but the signal routing (the control's design) is not a real problem either. > > But i'll have to rest a bit before i write > > documentation, code and draw stuffs. be patient, DATE has only begun :-) > Please let me know when you have some code to look at. before that, i have to install and test some demo software that exhibitors from DATE have given to me. Soon, there is potential support of 3 other tools. The existing software are Simili and Vanilla under Linux (hmmmm, un*x) and the new ones are : ncsim (from Cadence, the exhibitors shown me how to use the tools), ALDEC's Riviera (i saw a live demo today and i have to install it), and another tool (not synthesis or compilation but an entry tool, i would be curious to see it "understand" our code and verify that the vendor is right ...) Then comes the register set problem ! i have some beginnings of answers and EUROPRACTICE proposed to integrate F-CPU in their design kit CDROM : this way, universities and laboratories who have the proper software can do the synthesis themselves and report the results. It's a bit far fetched (feedback or even attempts are not 100% probable) but worth trying and we could reach a very specific target at no cost. Before this happens, let's just stick to the "least common denominator" and make something clean. oh, and i have to sleep tonight, too :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Mar 7 14:06:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16izBV-0002PB-00 for ; Thu, 07 Mar 2002 15:47:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 07 Mar 2002 15:47:57 +0100 (CET) Received: (qmail 29710 invoked by uid 0); 7 Mar 2002 13:01:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 7 Mar 2002 13:01:01 -0000 Received: by moria.seul.org (Postfix) id 3FFE61467F6; Thu, 7 Mar 2002 08:00:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 25ED41467FA; Thu, 7 Mar 2002 08:00:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id AA6361467F6 for ; Thu, 7 Mar 2002 08:00:58 -0500 (EST) Received: from f-cpu.org (kdl16-10.n.club-internet.fr [213.44.18.10]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B9F8716F7 for ; Thu, 7 Mar 2002 14:00:55 +0100 (CET) Message-ID: <3C8765D1.63194EEF@f-cpu.org> Date: Thu, 07 Mar 2002 14:06:25 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Andreas Romeyke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello YG, > > > For the shifter idea, it is very simple, maybe easier > > to understand than the reversed Omega network. > > Could be an additional solution a convolution network, means > a network with bidirectional stages? > > Example: > > 6 stages (3 physically) > 9 nodes > > I/O (left) > # -> nodes or switches > > > # # # > - -#----------#----------#----+ > # # # | > - -#-\ /-#-\ /-#---+| > # \ / # \ / # || > - -#-\ \ / /-#-\ \ / /-#--+|| > # \ \/ / # \ \/ / #-+||| > \/\| |/\/ |||| > /\ \ / /\ |||| > # / | |\ # /| | \ #-+||| > - -#-/ | | \-#-/ | | \-#--+|| > # | | # | | # || > - -#----------#----------# || > # | | # | | # || > - -#-\ | / /-#-\ | | /-#--+|| > # \ \/ / # \ \/ / #-+||| > \/\/ \/\/ |||| > /\/\ /\/\ |||| > # / /\ \ # / /\ \ #-+||| > - -#-/ / \ \-#-/ / \ \-#--+|| > # / \ # / \ # || > - -#-/ \-#-/ \-#---+| > # # # | > - -#----------#----------#----+ > # # # > > Any hints? i don't get th idea because it seems that you have not made the drawing with a fixed font :-/ > Bye Andreas btw, you should receive a CD soon. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 8 03:13:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jDLQ-0000GP-01 for ; Fri, 08 Mar 2002 06:55:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 08 Mar 2002 06:55:08 +0100 (CET) Received: (qmail 22510 invoked by uid 0); 8 Mar 2002 02:08:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 8 Mar 2002 02:08:18 -0000 Received: by moria.seul.org (Postfix) id 1F6691467ED; Thu, 7 Mar 2002 21:08:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 197121467F0; Thu, 7 Mar 2002 21:08:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 88B1D1467ED for ; Thu, 7 Mar 2002 21:08:16 -0500 (EST) Received: from f-cpu.org (kdl11-25.n.club-internet.fr [213.44.9.25]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8D4A916A8; Fri, 8 Mar 2002 03:08:11 +0100 (CET) Message-ID: <3C881E56.A7E2B3AA@f-cpu.org> Date: Fri, 08 Mar 2002 03:13:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] another DATE report Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, The DATE exhibition closed today in Paris. There were a lot of good news, too. Yesterday, i went there with Nicole. I also met ex-co-workers from Mentor Graphics, some of them are working in other companies. We met a journalist from a parisian magazine in arabic langage, a belgian small company who assists other EDA users on Linux (mind.be), and we picked the last noise-making tuxes from the HP booth :-) I also chatted on other booths, for example at DOLPHIN INTEGRATION, AXIS, ALDEC, Design and Reuse, or Virtual Silicon Technology. I met again with Europractice (like every year). They don't have a direct solution to the design style + synthesis problem BUT John Morris has a very interesting idea : including the F-CPU source packages in their CDROMs (one issue every 6 months, i guess) which are distributed to universities. With some luck, several universities, using a wide range of synthesisers and design kits from different fundries, will attempt to synthesise the F-CPU and maybe give some feedback. This is an additional and very targetted distribution channel. Ooops, it seems i said that yesterday already. Today, i met Renaud (who should also subscribe to the french mailing list ;-D) at his booth. I told him to come to the "First Jeudi" meeting that just ended, now (i'm back home and type this). I also met someone i hadn't dreamt to see : Larry Rosenberg, >from the VSI Alliance (vsi.org). We talked mainly about using the VCI standard interface for F-CPU and the discussions were very positive, they confort us in thinking that the deesign committee has done a very good work because large european companies like Alcatel and ST are using it (though they don't publicize on it). Though the work on VCI is stopped and the committe is dissolved (?), the standard is not frozen because a company had reopened the debate. Larry told me there is a possibility of reaching an agreement and even creating a "VCI User Group", where the F-CPU can have a place. Larry confirmed that, apart from paying for the copyrighted specification document, there is no tie of any kind by using the VCI interface in any design. It can be extended in different ways (data bus size, for example) and it provides a direct connexion to existing industrial IP cores. To "bypass" the copyright issue, it is possible to "rewrite" the spec. Since all F-CPU documentations are available under the GNU Free Documentation Licence, and because it will mainly describe the implementation in F-CPU, there is no problem or risk. I have access to some old version specs in the university, which uses VCI too, and i can write a scratch course. I also want to create a 4th level in the specification where the interface protocol is completely symmetrical : both sides can be initiators and targets, thus allowing a CPU to access the private memory range of another CPU. This could be later versed back to the "official" VCI standard. Then tonight, F-CPU people met at the "first jeudi", like every month. Renaud came (for the first time), i was also present with Cédric, Amaury, Nicole, Trollhunter. nicO did not come :-( As again, what i write here is subject to the kind of incidents that happen when one is tired, so forgive me in advance for any inaccuracy :-) things that i have to do : - install RH7.2 on the new 20GB HDD of my laptop (i got a couple CD tonight because the First Jeudi is mainly populated by linux geeks) - try all the tricks i learnt about ALDEC's Riviera and Cadence's ncsim, install Riviera and Translogic's Ease5 and request their demo keys - read the new issue of Linux Magazine France - update the scripts, (re)write some VHDL and make a new F-CPU snapshot ? WHYGEE, whishes to have a time machine... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 8 03:08:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jLOr-0005e6-01 for ; Fri, 08 Mar 2002 15:31:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 08 Mar 2002 15:31:13 +0100 (CET) Received: (qmail 7677 invoked by uid 0); 8 Mar 2002 10:31:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 8 Mar 2002 10:31:25 -0000 Received: by moria.seul.org (Postfix) id 76B831467EF; Fri, 8 Mar 2002 05:31:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F95B1467F1; Fri, 8 Mar 2002 05:31:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a135.home.uni-hannover.de [130.75.232.135]) by moria.seul.org (Postfix) with ESMTP id 3523F1467EF for ; Fri, 8 Mar 2002 05:31:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA24312; Fri, 8 Mar 2002 03:08:01 +0100 Message-ID: <20020308030801.10380@thrai.stud.uni-hannover.de> Date: Fri, 8 Mar 2002 03:08:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: <3C8765D1.63194EEF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C8765D1.63194EEF@f-cpu.org>; from Yann Guidon on Thu, Mar 07, 2002 at 02:06:25PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Mar 07, 2002 at 02:06:25PM +0100, Yann Guidon wrote: [...] > > # / /\ \ # / /\ \ #-+||| > > - -#-/ / \ \-#-/ / \ \-#--+|| > > # / \ # / \ # || > > - -#-/ \-#-/ \-#---+| > > # # # | > > - -#----------#----------#----+ > > # # # > > > > Any hints? > > i don't get th idea because it seems that > you have not made the drawing with a fixed font :-/ Oh, he did... but PGP messed it up. It replaced "-" at the beginning of a line with "- -". If you revert that, the picture becomes clearer. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Fri Mar 8 19:10:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jTSP-0002o4-01 for ; Sat, 09 Mar 2002 00:07:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 09 Mar 2002 00:07:25 +0100 (CET) Received: (qmail 6154 invoked by uid 0); 8 Mar 2002 18:03:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 8 Mar 2002 18:03:23 -0000 Received: by moria.seul.org (Postfix) id 311D71462FD; Fri, 8 Mar 2002 13:03:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 119F71467FC; Fri, 8 Mar 2002 13:03:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8BB5C1462FD for ; Fri, 8 Mar 2002 13:03:19 -0500 (EST) Received: from seul.org (vlt4-237.n.club-internet.fr [194.158.109.237]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 490EB1708 for ; Fri, 8 Mar 2002 19:03:14 +0100 (CET) Message-ID: <3C88FEAC.BAFC02A7@seul.org> Date: Fri, 08 Mar 2002 19:10:52 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry, i couldn't be at first jeudi. For the story about VCI, i have contacted tghe guy from wishbone. He is very please that we introduice new type of cycle in there buses. Maybe such cycle could come from VCI ideas. Wisbone is very (to much ?) simple. i propose to introduice 3 things : - a cycle take only one cycle, so it's means that the signal must make the following travel : master-arbiter-master-slave-master ! There is an extention to introduce waiting cycle but you loose bandwith. I propose to introduice interleave multi-cycle access. It look like the new low latency DRAM from Infineon with a synchronous SRAM interface. So, you send the adress to receive the grant from the arbitrer but then you have n cycle bevore receiving or sending the data. But you could rebegin an other transaction in between. - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic ! If there is problems, writes could not occur. - maybe things to manage cache L2 (from my point of view L2 is tied to the DRAM controller, the L1 is tied to the CPU). None caching access for example to avoid cache trashing. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 8 21:40:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jTSQ-0002o4-00 for ; Sat, 09 Mar 2002 00:07:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 09 Mar 2002 00:07:26 +0100 (CET) Received: (qmail 25435 invoked by uid 0); 8 Mar 2002 20:35:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Mar 2002 20:35:14 -0000 Received: by moria.seul.org (Postfix) id 44E9E1462FD; Fri, 8 Mar 2002 15:35:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2EE791467FC; Fri, 8 Mar 2002 15:35:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id A3C131462FD for ; Fri, 8 Mar 2002 15:35:12 -0500 (EST) Received: from f-cpu.org (kdl12-109.n.club-internet.fr [213.44.10.109]) by relay-1v.club-internet.fr (Postfix) with ESMTP id CB944171A for ; Fri, 8 Mar 2002 21:35:08 +0100 (CET) Message-ID: <3C8921BD.9BAEEC9B@f-cpu.org> Date: Fri, 08 Mar 2002 21:40:29 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SHL II (Re: [f-cpu] DATE2002, day 1 report) References: <3C8765D1.63194EEF@f-cpu.org> <20020308030801.10380@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Mar 07, 2002 at 02:06:25PM +0100, Yann Guidon wrote: > [...] > > > > > > Any hints? > > > > i don't get th idea because it seems that > > you have not made the drawing with a fixed font :-/ > > Oh, he did... but PGP messed it up. It replaced "-" at the beginning > of a line with "- -". If you revert that, the picture becomes clearer. ?????? > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 8 21:40:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jTSQ-0002o4-01 for ; Sat, 09 Mar 2002 00:07:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 09 Mar 2002 00:07:26 +0100 (CET) Received: (qmail 29005 invoked by uid 0); 8 Mar 2002 20:35:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 8 Mar 2002 20:35:20 -0000 Received: by moria.seul.org (Postfix) id 4548F1467E8; Fri, 8 Mar 2002 15:35:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 27C661467F7; Fri, 8 Mar 2002 15:35:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A628A1467E8 for ; Fri, 8 Mar 2002 15:35:12 -0500 (EST) Received: from f-cpu.org (kdl12-109.n.club-internet.fr [213.44.10.109]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 9F7CD16ED for ; Fri, 8 Mar 2002 21:35:08 +0100 (CET) Message-ID: <3C8921B4.21F31303@f-cpu.org> Date: Fri, 08 Mar 2002 21:40:20 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, nico wrote: > Sorry, i couldn't be at first jeudi. without you, it's less interesting ;-) > For the story about VCI, i have contacted tghe guy from wishbone. He is > very please that we introduice new type of cycle in there buses. Maybe > such cycle could come from VCI ideas. VCI is looking even more simple, i think. VCI's protocol is : an initiator sends a packet (address+data+command word) and the target answers with a reply packet (data+status word). Such things can be interleaved with a TID (transaction number, 16 by default). Multiword packets have a protocol that ensures that over-simplified targets (without internal state machines) can still work : the address bus is incremented, a "end of packet" signal is raised when the last word is sent, a "contiguous" flag announces that the addresses are contiguous. All this is managed with a simple "FIFO" interface (Data Enable - ACKnowlege) and since it is only an interface, there is NO constraint on latency, interconnect topology, number of initiators and targets... And "wrapper"s already exist to "plug" VCI 'components' to most other existing buses and networks. > Wisbone is very (to much ?) simple. if it's simple, then why do you want to make it more complex than necessary ? > i propose to introduice 3 things : > - a cycle take only one cycle, huh ? a cycle is a cycle, i don't understand what you mean. maybe i should read the wishbone specs more carefully, i have printed it but haven't had enough time to read everything. > so it's means that the signal must make > the following travel : master-arbiter-master-slave-master ! There is an > extention to introduce waiting cycle but you loose bandwith. VCI is not complex like that because it's a point to point connexion between two elements. One of the elements can be the interconnect itself, providing multiple ports at wish. > I propose to introduice interleave multi-cycle access. It look like the > new low latency DRAM from Infineon with a synchronous SRAM interface. URL ? > So, you send the adress to receive the grant from the arbitrer but then > you have n cycle bevore receiving or sending the data. But you could > rebegin an other transaction in between. VCI already can do that easily :-) > - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic ! > If there is problems, writes could not occur. ugly. > - maybe things to manage cache L2 (from my point of view L2 is tied to > the DRAM controller, the L1 is tied to the CPU). None caching access for > example to avoid cache trashing. what do you mean by "things to manage cache L2" ? what things ? see you soon, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Fri Mar 8 23:17:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jTSW-0002o4-00 for ; Sat, 09 Mar 2002 00:07:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 09 Mar 2002 00:07:32 +0100 (CET) Received: (qmail 17194 invoked by uid 0); 8 Mar 2002 22:09:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 8 Mar 2002 22:09:28 -0000 Received: by moria.seul.org (Postfix) id B46AD1467F7; Fri, 8 Mar 2002 17:09:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1EA41467EE; Fri, 8 Mar 2002 17:09:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 25EDB1462FD; Fri, 8 Mar 2002 17:09:26 -0500 (EST) Received: from seul.org (vlt10-244.n.club-internet.fr [195.36.224.244]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 6092F1683; Fri, 8 Mar 2002 23:09:22 +0100 (CET) Message-ID: <3C89385E.CE9CFC0D@seul.org> Date: Fri, 08 Mar 2002 23:17:02 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > nico wrote: > > Sorry, i couldn't be at first jeudi. > without you, it's less interesting ;-) > > > For the story about VCI, i have contacted tghe guy from wishbone. He is > > very please that we introduice new type of cycle in there buses. Maybe > > such cycle could come from VCI ideas. > > VCI is looking even more simple, i think. > VCI's protocol is : an initiator sends a packet (address+data+command word) > and the target answers with a reply packet (data+status word). > > Such things can be interleaved with a TID (transaction number, 16 by default). > > Multiword packets have a protocol that ensures that over-simplified targets > (without internal state machines) can still work : the address bus is incremented, > a "end of packet" signal is raised when the last word is sent, a "contiguous" > flag announces that the addresses are contiguous. > > All this is managed with a simple "FIFO" interface (Data Enable - ACKnowlege) > and since it is only an interface, there is NO constraint on latency, > interconnect topology, number of initiators and targets... > And "wrapper"s already exist to "plug" VCI 'components' to most other existing > buses and networks. > > > Wisbone is very (to much ?) simple. > if it's simple, then why do you want to make it more complex than necessary ? > > > i propose to introduice 3 things : > > - a cycle take only one cycle, > > huh ? a cycle is a cycle, i don't understand what you mean. > maybe i should read the wishbone specs more carefully, i have printed it but haven't > had enough time to read everything. > Oups ! i means a read or write cycle take only a clock cycle.(to be comparre to the 2 clock cycle from AMBa wich pipeline data and address) > > so it's means that the signal must make > > the following travel : master-arbiter-master-slave-master ! There is an > > extention to introduce waiting cycle but you loose bandwith. > VCI is not complex like that because it's a point to point connexion > between two elements. One of the elements can be the interconnect itself, > providing multiple ports at wish. > > > I propose to introduice interleave multi-cycle access. It look like the > > new low latency DRAM from Infineon with a synchronous SRAM interface. > URL ? > > > So, you send the adress to receive the grant from the arbitrer but then > > you have n cycle bevore receiving or sending the data. But you could > > rebegin an other transaction in between. > > VCI already can do that easily :-) > > > - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic ! > > If there is problems, writes could not occur. > > ugly. Nop, absolutely necessary to handel very easly synchronous problem. Christophe convince me, if he could resend it's URl about the paper that speak about. Such technic, in the common case, where there is no collision the only lose is this CAS2 instruction, there is no OS call overhead, no task switch, nothing. Only 4 atomic transactions ! We must have that ! > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > example to avoid cache trashing. > what do you mean by "things to manage cache L2" ? what things ? > For example, caching or no caching data (imagine the FCPu as the core of the Geoforce 8, rendered image didn't need to be cached). To extend that, i would try to apply distributed memory in some control logic to make invalidate some cache line... > see you soon, Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! nicO > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 8 23:55:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16jU0D-0003R6-00 for ; Sat, 09 Mar 2002 00:42:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 09 Mar 2002 00:42:21 +0100 (CET) Received: (qmail 14259 invoked by uid 0); 8 Mar 2002 22:50:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 8 Mar 2002 22:50:11 -0000 Received: by moria.seul.org (Postfix) id 2E7601462FD; Fri, 8 Mar 2002 17:50:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C9961467EE; Fri, 8 Mar 2002 17:50:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A14051462FD for ; Fri, 8 Mar 2002 17:50:09 -0500 (EST) Received: from f-cpu.org (kdl16-46.n.club-internet.fr [213.44.18.46]) by relay-2v.club-internet.fr (Postfix) with ESMTP id E8F0116AF for ; Fri, 8 Mar 2002 23:50:06 +0100 (CET) Message-ID: <3C89416B.2E7662E7@f-cpu.org> Date: Fri, 08 Mar 2002 23:55:39 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nico wrote: > Yann Guidon a écrit : > > nico wrote: > > > Wisbone is very (to much ?) simple. > > if it's simple, then why do you want to make it more complex than necessary ? > > > > > i propose to introduice 3 things : > > > - a cycle take only one cycle, > > > > huh ? a cycle is a cycle, i don't understand what you mean. > > maybe i should read the wishbone specs more carefully, i have printed it but haven't > > had enough time to read everything. > > Oups ! i means a read or write cycle take only a clock cycle.(to be > comparre to the 2 clock cycle from AMBa wich pipeline data and address) i remember that PI-BUS has a pipelined address-data system, too (but not multiplexed like PCI ;-D) > > > - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic ! > > > If there is problems, writes could not occur. > > > > ugly. > > Nop, absolutely necessary to handel very easly synchronous problem. > Christophe convince me, if he could resend it's URl about the paper that > speak about. > Such technic, in the common case, where there is no collision the only > lose is this CAS2 instruction, there is no OS call overhead, no task > switch, nothing. Only 4 atomic transactions ! We must have that ! i agree that CAS-like operations are interesting, no doubt about that. However, what you propose is uglier than what i heard before, and you know that we have discussed a lot ;-) * first, there must be an instruction that supports this kind of transaction. there is none and this instrruction would block the pipeline. you couldn't for example "pipeline" the CASes. * second, probably no device would support this operation. I don't know how you would like to implement that but F-CPU is not alone in the system (otherwise there would be no use for an I/O bus :-D) and the other elements must support the same protocol. If there is only one memory block, ok, but if other CPUs of a different sort are present, there might be risks. * third, and more difficult for me (because i'm one of the people who code), your feature requires a more complex state machine than needed. Generally such a complex thing is not used 99.95% of the time, so i think it's an overhead on my shoulders, unless you want to do it. > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > > example to avoid cache trashing. > > what do you mean by "things to manage cache L2" ? what things ? > > For example, caching or no caching data (imagine the FCPu as the core of > the Geoforce 8, rendered image didn't need to be cached). there's a flag in the Load and Store instructions which specify if the data is to be cached. > To extend that, i would try to apply distributed memory in some control logic to > make invalidate some cache line... if we work with private and public memory spaces, there is no invalidation logic required. > > see you soon, > Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! send me a postcard ;-) if you go in vacations, take some time to write a white paper about how to use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make that for the VCI interface. Some VHDL code would be nice, too. > nicO > > > nicO > > WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 11 17:30:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kTEX-0004Y5-01 for ; Mon, 11 Mar 2002 18:05:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 11 Mar 2002 18:05:13 +0100 (CET) Received: (qmail 15815 invoked by uid 0); 11 Mar 2002 16:25:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 11 Mar 2002 16:25:04 -0000 Received: by moria.seul.org (Postfix) id 10F151467ED; Mon, 11 Mar 2002 11:25:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 007091467FD; Mon, 11 Mar 2002 11:25:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 6EE171467ED for ; Mon, 11 Mar 2002 11:25:03 -0500 (EST) Received: from f-cpu.org (kdl16-227.n.club-internet.fr [213.44.18.227]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 407F416A0 for ; Mon, 11 Mar 2002 17:25:00 +0100 (CET) Message-ID: <3C8CDBAD.21606279@f-cpu.org> Date: Mon, 11 Mar 2002 17:30:37 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Re: help with linux from scratch References: <3C8A44C0.822EC572@f-cpu.org> <20020310001335.49983@thrai.stud.uni-hannover.de> <3C8AD0F9.89C04DA5@f-cpu.org> <20020310160501.56954@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! I switch to the main F-CPU mailing list because it might trigger some useful answers from others. Michael Riepe wrote: > Hi! > > > > I did not install LFS, I built my system (and a bunch of others) from > > > scratch. That's a difference... and it means that our systems differ > > > substantially :( > > > > apart from the documentation, i don't see a difference ;-) > > - different software packages > - different versions > - different file placement / directory layout well, the principle remains the same, i guess. except that LFS is currently very poorly automated. a few scripts would help to divide the installation time by 2 at least. A few tricks would even reduce the overhead from running ./configure multiple times with the same configuration (making a link to a central cache directory for example). If you have ideas, i will be happy. Of course, the manual installation is very instructive, despite the length, and it was not a pain as i expected. however it is very long and having to check all the scripts manually, decompressing by hand, running the make distclean by hand etc on all packages is sometimes boring. It successsfuly booted, giving some error messages and receiving unhandled signals, but it booted anyway. Last time i compiled a kernel, i was forced to reinstall everything :-) With a bit of sleep (i just woke up after 11 hours, the installation was more than 18 hours long) and calm, i presume that the kernel unstability might come from the use of hdparm. I have read that there are corruption risks for certain options, but not coming from kernel unstability (receiving signals it doesn't know how to handle ?). if you have a "stable" .configuration file for a 2.4.17 kernel, i'll happily use it ;-) > > > If you use the latest LFS, Simili will probably run like a charm. > > i guess. > > > > > For Vanilla, you can use the same workaround as you do now (use the > > > statically linked vv87 binary). > > wouldn't a simple copy of the correct file (a library) do the trick ? > Almost (you may need one or two configuration files as well). there's one in /etc (ld.so.something) for the directories, but what else ? I have identified the compatibility library to use and where to put it, but i don't remember the rest... > > > For the kernel, choose `Pentium-III'. > > > > it should do the trick :-) but the documentation > > warns about too much optimisations which could make > > the system unstable : not more than -O2 for the libraries... > > I've been using `-O2 -march=xyz' for my do-it-yourself systems. most of the compilation were done with "686" by the makefiles. i saw one or two tools with 486 ... but it's not a problem, as long as it works. I probably should not have followed the advice to run strip for removing the debug symbols. Of course it removes megabytes of useless stuffs but it maybe touched files it shouldn't touch... > > > > Additionally, when the F-CPU simulator and the GCC patches > > > > are ready, do you think that LFS is suitable for testing > > > > and booting a simulated F-CPU ? (cross-compiled binaries > > > > and simulated by a streamlined ncsim) > > > > > > I'm plan to use Linux for {si,e}mulation myself. > > > I guess it's as suitable as any other 32-bit Unix ;) > > > > yes but i meant : LFS as a Linux flavour that could be first compiled > > to F-CPU executables. Since LFS exposes all the sources > > from a minimal working system, it is a good target > > for attempting ports to F-CPU, no ? LFS as a first > > distro for F-CPU would be rather easy, no ? > > If LFS is 64-bit clean, yes (has it been tested on Alpha?). it's not a problem because F-CPU also handles 32-bit and 16-bits as well. The compiler has to do a clean work, however. > The really hard part is porting the kernel... yup. Anyway, LFS was a very interesting experience and i also thank Etienne for his help. Without his guidance it wouldn't have worked :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Mar 12 08:18:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kktk-0000G2-01 for ; Tue, 12 Mar 2002 12:56:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 12 Mar 2002 12:56:56 +0100 (CET) Received: (qmail 5159 invoked by uid 0); 12 Mar 2002 07:18:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 12 Mar 2002 07:18:52 -0000 Received: by moria.seul.org (Postfix) id 8A9F61462F9; Tue, 12 Mar 2002 02:18:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8515C1463AB; Tue, 12 Mar 2002 02:18:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 7A7FB1462F9 for ; Tue, 12 Mar 2002 02:18:49 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16kgYE-0001FQ-00 for f-cpu@seul.org; Tue, 12 Mar 2002 08:18:26 +0100 Date: Tue, 12 Mar 2002 08:18:26 +0100 (MET) From: Juergen Goeritz To: fm Subject: Re: [f-cpu] Re: help with linux from scratch In-Reply-To: <3C8CDBAD.21606279@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 11 Mar 2002, Yann Guidon wrote: > hi ! > > I switch to the main F-CPU mailing list because it might > trigger some useful answers from others. > > I probably should not have followed the advice to run strip > for removing the debug symbols. Of course it removes megabytes > of useless stuffs but it maybe touched files it shouldn't touch... :-) I don't think it touched something it shouldn't. But you lack a lot of information to locate the problem which may hide itself in the LFS code or in the libraries or in the kernel you use. Or your hardware may be a little bit incompatible - smelled like embedded system... > > The really hard part is porting the kernel... > yup. ... and don't forget the libraries! JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fcpu@guerrier.com Tue Mar 12 16:51:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytQ-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:32 +0100 (CET) Received: (qmail 15759 invoked by uid 0); 12 Mar 2002 15:51:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Mar 2002 15:51:03 -0000 Received: by moria.seul.org (Postfix) id 1854E1462F9; Tue, 12 Mar 2002 10:51:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 07D8A1467ED; Tue, 12 Mar 2002 10:51:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id A8B121462F9 for ; Tue, 12 Mar 2002 10:51:01 -0500 (EST) Received: from imp1-1.pro.proxad.net (imp1-1.pro.proxad.net [212.27.35.86]) by postfix1-2.free.fr (Postfix) with ESMTP id B733FAB2F0 for ; Tue, 12 Mar 2002 16:51:00 +0100 (CET) Received: by imp1-1.pro.proxad.net (Postfix, from userid 33) id 7D799780F1; Tue, 12 Mar 2002 16:51:00 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] Re: help with linux from scratch Message-ID: <1015948260.3c8e23e46f47c@imp.pro.proxad.net> Date: Tue, 12 Mar 2002 16:51:00 +0100 (MET) From: fcpu@guerrier.com References: <3C8A44C0.822EC572@f-cpu.org> <20020310001335.49983@thrai.stud.uni-hannover.de> <3C8AD0F9.89C04DA5@f-cpu.org> <20020310160501.56954@thrai.stud.uni-hannover.de> <3C8CDBAD.21606279@f-cpu.org> In-Reply-To: <3C8CDBAD.21606279@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 194.183.212.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N En réponse à Yann Guidon : > I switch to the main F-CPU mailing list because it might > trigger some useful answers from others. > except that LFS is currently very poorly automated. > a few scripts would help to divide the installation > time by 2 at least. A few tricks would even reduce > the overhead from running ./configure multiple times > with the same configuration (making a link to a central > cache directory for example). > > If you have ideas, i will be happy. take a look at http://www.sunsetsystems.com/lfsmake.php3 it builds my LFS box in 6 hours (PII 400) Take care if you're connected to the Internet, as it try to download missing or outdated files (usefull for *patch*, not for downloading the new kernel) > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Mar 12 18:22:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytR-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:33 +0100 (CET) Received: (qmail 15127 invoked by uid 0); 12 Mar 2002 17:22:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Mar 2002 17:22:31 -0000 Received: by moria.seul.org (Postfix) id F164C1463AB; Tue, 12 Mar 2002 12:22:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC7231467EE; Tue, 12 Mar 2002 12:22:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id B1ED51463AB for ; Tue, 12 Mar 2002 12:22:27 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 8A73818B4; Tue, 12 Mar 2002 18:22:22 +0100 (CET) Received: from [132.227.86.2] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: help with linux from scratch Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2002 18:22:22 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >En r=E9ponse =E0 Yann Guidon : >> except that LFS is currently very poorly automated. >> a few scripts would help to divide the installation >> time by 2 at least. A few tricks would even reduce >> the overhead from running ./configure multiple times >> with the same configuration (making a link to a central >> cache directory for example). >> = >> If you have ideas, i will be happy. > >take a look at = >http://www.sunsetsystems.com/lfsmake.php3 >it builds my LFS box in 6 hours (PII 400) :-) >Take care if you're connected to the Internet, = >as it try to download missing or outdated files >(usefull for *patch*, not for downloading the new kernel) thanks, it looks nice =21 i'll have a look at ALFS too, when i need to recompile everything. i have discussed a bit with the maintainer of LFS and he prefers to concentrate on the core, and leave the automation to the other contributors. I'm digging in the idea of making a small monitor in FLASH, which does all the HW detection and setup, and later downloads the kernel from a peripheral (or simply from the remaining but that would take more room and be more difficult to update). BTW i just read a CMP magazine i got in DATE, called =22Embedded Systems=22 (http://www.allembedded.com) and there are some very interesting things, explaining for example how uClinux works (a MMU-less system). Another page is a product announcement for a very ... sexy product : the ProASICPlus FLASH-FPGA from ACTEL is a see of 3-input gates with a hierarchical interconnect, PLLs, up to 712 I/O, up to 198Kbits of dual/ported RAM, up to 1 million gates... it boots up instantly because it's not a SRAM but FLASH configuration (no download from external EPROM) and it can work at around 100MHz (max. internal clock speed : 240MHz). I WANT ONE =21=21=21=21=21 YG :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 13 00:14:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytT-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:35 +0100 (CET) Received: (qmail 2583 invoked by uid 0); 12 Mar 2002 23:15:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 12 Mar 2002 23:15:10 -0000 Received: by moria.seul.org (Postfix) id B33DF1462FD; Tue, 12 Mar 2002 18:15:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8750A1467F3; Tue, 12 Mar 2002 18:15:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 05B111462FD for ; Tue, 12 Mar 2002 18:15:09 -0500 (EST) Received: from f-cpu.org (kdl16-12.n.club-internet.fr [213.44.18.12]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 9FBAE1922 for ; Wed, 13 Mar 2002 00:09:02 +0100 (CET) Message-ID: <3C8E8BE2.65E67E6F@f-cpu.org> Date: Wed, 13 Mar 2002 00:14:42 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] F-ROFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, The recent installation of the Linux From Scratch system on my new HDD triggered a lot of question, including : how will we get this damn CPU boot such a complex system ? Constraints : - The CPU boots at address 0. It's not a problem, because usually the page that maps to NULL triggers a trap and VM is not enabled during bootup. The RAM address is detected and relocated by our boot code so the real address of the RAM is not a problem either. And because the addressable range is potentially unlimited, it's not a good idea to boot with the address MSB set to 1 because then our code couldn't boot on different implementations. - We have to simulate our system using a VHDL simulator which is by definition very limited from the I/O point of view : file open, close, read and write, that's all. not even a file seek. All I/O will have to go through that, before we're able to simulate more than a character input/output (a virtual console). That's very poor : no HDD or video frame buffer, almost nothing. All we can do is : open/read an image of the Flash EPROM and map it to address O of our CPU. For the "virtual console" i consider the creation of a new SR (called something like SR_VIRTUAL_CONSOLE) which will get or put a character with the get and put instruction. simple. Later this could be synthesised as a port to a parallel port or an UART for command-line debugging... So it's a really bare system, we have a FLASH EPROM and a console I/O, no HDD, no video (yet) and we have to start developping stuff on this like primitive programs, run a kernel and make a boot loading manager (multi-boot menu etc...)... And this must be done with very, very simple tools (not even the heavy GNU toolsuite) that are "linked" to a static library provided in the Flash (kind of BIOS). So i started thinking about a really simple "Read-Only File System" (not exactly a RomFS but you get the idea). This must be handled with simple structures and algorithms but allow the direct execution of binaries, allow the loading of drivers and giver some functionalities that allow a kernel to be configured and started. I'll start writing code soon, because the idea is fresh and juicy in my head. What i have in mind solves several problems without requiring more tools than an assembler (and probably another tool like mkrofs) and preserves some flexibility. If you have pointers or ideas, i'll be interested. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 13 01:01:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytU-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:36 +0100 (CET) Received: (qmail 23856 invoked by uid 0); 12 Mar 2002 23:55:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 12 Mar 2002 23:55:46 -0000 Received: by moria.seul.org (Postfix) id 56CAB1463AB; Tue, 12 Mar 2002 18:55:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2CC531467F4; Tue, 12 Mar 2002 18:55:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C2FC31463AB for ; Tue, 12 Mar 2002 18:55:44 -0500 (EST) Received: from f-cpu.org (kdl11-16.n.club-internet.fr [213.44.9.16]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 71B741AA7 for ; Wed, 13 Mar 2002 00:55:41 +0100 (CET) Message-ID: <3C8E96CD.F2355223@f-cpu.org> Date: Wed, 13 Mar 2002 01:01:17 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] rom-fs (update) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i just looked up at rom-fs on the web and found a struture rather similar to what i thought but i won't use it exactly like that. however the idea is mostly there, except that romfs is not developped the same way... ok, now, i should code a bit :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 13 01:15:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytU-0001OQ-01 for ; Wed, 13 Mar 2002 03:53:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:36 +0100 (CET) Received: (qmail 9550 invoked by uid 0); 13 Mar 2002 00:15:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 13 Mar 2002 00:15:44 -0000 Received: by moria.seul.org (Postfix) id 8262E1467F3; Tue, 12 Mar 2002 19:15:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A5401467F5; Tue, 12 Mar 2002 19:15:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id B384A1467F3 for ; Tue, 12 Mar 2002 19:15:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00799; Wed, 13 Mar 2002 01:15:39 +0100 Message-ID: <20020313011539.22862@thrai.stud.uni-hannover.de> Date: Wed, 13 Mar 2002 01:15:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: <3C8E8BE2.65E67E6F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C8E8BE2.65E67E6F@f-cpu.org>; from Yann Guidon on Wed, Mar 13, 2002 at 12:14:42AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 13, 2002 at 12:14:42AM +0100, Yann Guidon wrote: > Hello, > > The recent installation of the Linux From Scratch system > on my new HDD triggered a lot of question, including : > how will we get this damn CPU boot such a complex system ? By writing a decent BIOS? ;) > Constraints : > > - The CPU boots at address 0. It's not a problem, > because usually the page that maps to NULL triggers > a trap and VM is not enabled during bootup. The RAM > address is detected and relocated by our boot code > so the real address of the RAM is not a problem either. > And because the addressable range is potentially > unlimited, it's not a good idea to boot with the address > MSB set to 1 because then our code couldn't boot > on different implementations. Yep. > - We have to simulate our system using a VHDL simulator > which is by definition very limited from the I/O point of > view : file open, close, read and write, that's all. > not even a file seek. All I/O will have to go through that, > before we're able to simulate more than a character input/output > (a virtual console). That's very poor : no HDD or video frame > buffer, almost nothing. All we can do is : open/read an image > of the Flash EPROM and map it to address O of our CPU. > For the "virtual console" i consider the creation of a new SR > (called something like SR_VIRTUAL_CONSOLE) which will get or > put a character with the get and put instruction. simple. > Later this could be synthesised as a port to a parallel port > or an UART for command-line debugging... Better use memory mapped I/O. The real one will have to do that anyway. > So it's a really bare system, we have a FLASH EPROM > and a console I/O, no HDD, no video (yet) and we have > to start developping stuff on this like primitive programs, > run a kernel and make a boot loading manager (multi-boot > menu etc...)... And this must be done with very, very simple > tools (not even the heavy GNU toolsuite) that are "linked" > to a static library provided in the Flash (kind of BIOS). I'd rather start with something different: an instruction-level emulator that directs system calls to the host OS (via a syscall/trap instruction, or some memory mapping tricks). That way, you can use almost any system call of the host OS. You just can't port the kernel itself. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 13 01:47:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytV-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:37 +0100 (CET) Received: (qmail 10572 invoked by uid 0); 13 Mar 2002 00:42:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 13 Mar 2002 00:42:19 -0000 Received: by moria.seul.org (Postfix) id 28C411467F3; Tue, 12 Mar 2002 19:42:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 247DE1467F5; Tue, 12 Mar 2002 19:42:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CD2C11467F3 for ; Tue, 12 Mar 2002 19:42:16 -0500 (EST) Received: from f-cpu.org (kdl16-20.n.club-internet.fr [213.44.18.20]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 6E1F7169B for ; Wed, 13 Mar 2002 01:42:13 +0100 (CET) Message-ID: <3C8EA1B8.30F981D9@f-cpu.org> Date: Wed, 13 Mar 2002 01:47:52 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: <3C8E8BE2.65E67E6F@f-cpu.org> <20020313011539.22862@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N g'night, Michael Riepe wrote: > On Wed, Mar 13, 2002 at 12:14:42AM +0100, Yann Guidon wrote: > > Hello, > > > > The recent installation of the Linux From Scratch system > > on my new HDD triggered a lot of question, including : > > how will we get this damn CPU boot such a complex system ? > > By writing a decent BIOS? ;) argh, who would believe in that ? :-P > > Constraints : > > - We have to simulate our system using a VHDL simulator > > which is by definition very limited from the I/O point of > > view : file open, close, read and write, that's all. > > not even a file seek. All I/O will have to go through that, > > before we're able to simulate more than a character input/output > > (a virtual console). That's very poor : no HDD or video frame > > buffer, almost nothing. All we can do is : open/read an image > > of the Flash EPROM and map it to address O of our CPU. > > For the "virtual console" i consider the creation of a new SR > > (called something like SR_VIRTUAL_CONSOLE) which will get or > > put a character with the get and put instruction. simple. > > Later this could be synthesised as a port to a parallel port > > or an UART for command-line debugging... > > Better use memory mapped I/O. The real one will have to do that > anyway. I had thought about this but i don't really agree. I remember of the SPIM (a MIPS simulator) which does this, but it's done in C only. In the case of F-CPU, we have several targets with different constraints : VHDL (really limited), C sim (much better but some stuff may be unrealistic) and HW. It would be nice to have our code reused without modification on all versions and the memory mapped character I/O creates some unanswearable questions like how to handle multiple platforms with different memory layouts, how to intercept the memory access if it falls in the range of some other I/O, how to handle the timing problems in a real implementation ? using a SR is simple, safe and easily configurable, without interfering with the caches and can trap depending on the condition... > > So it's a really bare system, we have a FLASH EPROM > > and a console I/O, no HDD, no video (yet) and we have > > to start developping stuff on this like primitive programs, > > run a kernel and make a boot loading manager (multi-boot > > menu etc...)... And this must be done with very, very simple > > tools (not even the heavy GNU toolsuite) that are "linked" > > to a static library provided in the Flash (kind of BIOS). > > I'd rather start with something different: an instruction-level emulator > that directs system calls to the host OS (via a syscall/trap instruction, > or some memory mapping tricks). That way, you can use almost any system > call of the host OS. You just can't port the kernel itself. I also thought about using the trap/syscall instructions but it creates a little problem. I don't have the instruction map in hand but syscall has an immediate data word which indicates the service to request. So it jumps in kernel mode to service*64 + sr_syscall_base, and does its things. So it implies that the character is present in a previously specified register which must be read later. It also implies that the syscall mechanism is setup but what happens if there's an error at that time ?... OTOH, get and put can be configured to trap, too, so we can get back to your situation, but not the other way as easily... mmmm i also have to update the assembler and add some features like including immediate words (like "dd 01243567h"). that's useful. i should sleep, sometimes, too :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bombe@informatik.tu-muenchen.de Wed Mar 13 01:51:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytW-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:38 +0100 (CET) Received: (qmail 5588 invoked by uid 0); 13 Mar 2002 00:52:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 13 Mar 2002 00:52:59 -0000 Received: by moria.seul.org (Postfix) id CFE281467F4; Tue, 12 Mar 2002 19:52:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B79FF1467F7; Tue, 12 Mar 2002 19:52:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.netsurf.de (mehlwurm.netsurf.de [194.195.64.32]) by moria.seul.org (Postfix) with ESMTP id 27E181467F4 for ; Tue, 12 Mar 2002 19:52:58 -0500 (EST) Received: from storm.local ([195.179.191.140]) by mail.netsurf.de (Netscape Messaging Server 4.1) with ESMTP id GSVZQQ00.TA0 for ; Wed, 13 Mar 2002 01:52:02 +0100 Received: from andreasb by storm.local with local (Exim 3.35 #1 (Debian)) id 16kwz7-0002fb-00 for ; Wed, 13 Mar 2002 01:51:17 +0100 Date: Wed, 13 Mar 2002 01:51:17 +0100 From: Andreas Bombe To: f-cpu@seul.org Subject: [f-cpu] Re: F-ROFS Message-ID: <20020313005117.GA8705@storm.local> References: <3C8E8BE2.65E67E6F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C8E8BE2.65E67E6F@f-cpu.org> User-Agent: Mutt/1.3.27i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 13, 2002 at 12:14:42AM +0100, Yann Guidon wrote: > - We have to simulate our system using a VHDL simulator > which is by definition very limited from the I/O point of > view : file open, close, read and write, that's all. > not even a file seek. All I/O will have to go through that, > before we're able to simulate more than a character input/output > (a virtual console). That's very poor : no HDD or video frame > buffer, almost nothing. I fail to see the problem of not having a video frame buffer. Unless you want to run X11 in the simulation, which I doubt. What's so important about video? All you need is a simulated serial port and then put the Linux console on that. Serial consoles are well supported and VHDL I/O is sufficient for that. Hook up an xterm or Linux text console to that I/O and you can even run programs needing a powerful terminal. HDD also isn't important, they aren't anything special and there are ram disks. > So i started thinking about a really simple "Read-Only File System" > (not exactly a RomFS but you get the idea). This must be handled > with simple structures and algorithms but allow the direct > execution of binaries, allow the loading of drivers and giver some > functionalities that allow a kernel to be configured and started. Isn't this way too complicated at this stage? You need to define the startup protocol for Linux (where are the args, where is the initrd, what is the CPU state), then you should write a simple loader that just implements that and boots one kernel from a fixed ROM address with fixed args (like none). That should do for some months, until you get a kernel to boot to the point where it wants to mount a root fs and exec init. -- Andreas Bombe DSA key 0x04880A44 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Mar 13 02:13:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16kytX-0001OQ-00 for ; Wed, 13 Mar 2002 03:53:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 03:53:39 +0100 (CET) Received: (qmail 3824 invoked by uid 0); 13 Mar 2002 01:14:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 13 Mar 2002 01:14:43 -0000 Received: by moria.seul.org (Postfix) id 3132D1467F4; Tue, 12 Mar 2002 20:14:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C6AC1467F7; Tue, 12 Mar 2002 20:14:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 4F28A1467F4 for ; Tue, 12 Mar 2002 20:14:41 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215] (may be forged)) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA08853 for ; Tue, 12 Mar 2002 18:14:39 -0700 (MST) Message-ID: <3C8EA7A0.F1E1A03F@jetnet.ab.ca> Date: Tue, 12 Mar 2002 18:13:04 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: <3C8E8BE2.65E67E6F@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > Hello, > The recent installation of the Linux From Scratch system > on my new HDD triggered a lot of question, including : > how will we get this damn CPU boot such a complex system ? > If you have pointers or ideas, i'll be interested. One option may be to design several versions of the F-cpu starting with a simple controller to the full featured system. A 8 bit memory bus and simple I/O devices on the FPGA could make a prototype simpler to develop.While simulation is useful now a debugged hardware FPGA can also be developed at the same time. In my case I am using the programmability of the FPGA and real hardware for development, as my system consists of 6 LED's, 2 push button switches,some inputs pulled up to +5 volts, some memory , a RS232 level converter chip, and a FPGA with a byte blaster cable to a PC. I developed a uart chip first to test the leds and serial lines. Then I developed a simple controller controlled by the uart to read/write memory. Then I moved on step by step to my full featured CPU adding features step by step. The last major feature was a single channel DMA for a floppy disk since the CPU architecture is a 1.33 Mhz machine something like the 6809 and polled I/O was just too slow. Soon I will have a PCB made that will I have a limited front panel - address lines & data bus display. Later I can add on a real front panel or bootstrap prom using the same logic in the cpu as the serial bootstrap. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 13 05:06:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16l5rP-0005zp-00 for ; Wed, 13 Mar 2002 11:19:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 11:19:55 +0100 (CET) Received: (qmail 8887 invoked by uid 0); 13 Mar 2002 04:00:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Mar 2002 04:00:27 -0000 Received: by moria.seul.org (Postfix) id E69931462F9; Tue, 12 Mar 2002 23:00:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C79951467ED; Tue, 12 Mar 2002 23:00:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 5FF671462F9 for ; Tue, 12 Mar 2002 23:00:25 -0500 (EST) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 5C85D1685 for ; Wed, 13 Mar 2002 05:00:20 +0100 (CET) Message-ID: <3C8ED029.D4B4BDAA@f-cpu.org> Date: Wed, 13 Mar 2002 05:06:01 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] more about f-romfs Content-Type: multipart/mixed; boundary="------------98D218F992B6603B012F273E" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------98D218F992B6603B012F273E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit here are some more thoughts and contextual stuff. it's preliminary and moving, there's no code yet. however i think it is a good answer to the people who want a "BIOS" for F-CPU. First it is impossible to do that on a platform where there is only a CPU and then i understand that in the past years, the PC BIOSes have increased in complexity to a point where it's unmanageable. Having a small boot routine with a romfs-like support is a cool solution. i have to sleep now, after i read the comments that i just got. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------98D218F992B6603B012F273E Content-Type: text/plain; charset=us-ascii; name="F-ROMFS.TXT" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="F-ROMFS.TXT" f-romfs.txt created mer mar 13 03:30:43 GMT 2002 by whygee@f-cpu.org A discussion about a "file format", the associated algorithm and the context of using a romfs-like system. -------------------------------------------------------- BIOS/Monitor/extensions : The F-CPU processor is designed to boot at address 0 after reset. It will fetch its instructions from a non-volatile memory or an image of this data if the system is simulated in VHDL or C. The boot code will detect and initialize all the fundamental devices such as the memory controllers. For example, the refresh rate will be tuned, the bank size will be adjusted and the base address of the private memory range will be set to an unused range (if the system is comprised of several CPU with their own private address ranges, but they must not overlap). The boot memory also contains very low-level and primitive routines for doing basic stuff, such as sending error messages (to a virtual console that is mapped somewhere in the CPU, probably the SR). When done, we have to initialise a lot of other things which are independent >from the F-CPU project and we don't have the means to work on the HDD controller, the keyboard driver, the video framebuffer... You'll understand that we don't want to mess with it, a single CPU is already complex enough. We would like to let the user configure his system and install only the necessary drivers, or customize it with his driver for his prototype peripheral, etc. But we don't have access to a file system because the HDD is not yet setup ! this would bloat the code or make it too complex. OTOH we would like to let the user interact with the HW. The solution is to use something that looks like romfs : we have access to user-provided data and code modules and we have to provide a few functions that allow the modules to interact in a read-only way : - locate : return the physical address of the requested block - open : returns a handle to the specified block - close : close handle - read : get a word - seek : goto a specified offset in the "file" - exec : specify a file and run it since the additional modules are meant to provide development or debug tools, it is useful to use "directories" and "symbolic links". This is done with the help of "flags", just like a normal FS. we can add other flags : executable (so a user won't attempt to execute raw data), and compressed (in case we have some room for the decompression tables and code, when the Flash will be completely filled with tux pictures etc...) The Flash image will be built with a simple $ cp bareboot.bin newimage.bin $ cat modules.romfs >> newimage.bin $ installflash newimage.bin (science fictious) The bareboot.bin file is built from an assembly langage source containing : - the startup code - RAM initialisation code - the minimum libraries : decompression, romfs utilities and some additional stuff as needed The modules in modules.romfs are built from an utility (kind of mkromfs) with a set of specified files which are also assembled, using symbols extracted >from the startup/library code. The modules' code must be position-independently coded because when executed, the code (which can be decompacted) will be copied and aligned in private/fast memory. When all the minimal setup is performed (RAM and IRQ, for example) then the boot code uses the romfs functions to access the romfs part of the Flash, seeking a "startup" binary which will then initialise the rest, using internal scripts or facilities that the user can customize at will. The file could be named "runfirst" for example. If no romfs is found (starting at the end of the boot block) or if the startup file is absent, the CPU sends an error code to the virtual console and enters an infinite loop or in shutdown state. Granularity : F-CPU is a byte-addressing machine but the architecture does not like unaligned instructions or data access. * Concerning the instructions, the code blocks should be copied to the main memory and the starting address must be aligned to the 256 bit boundary imposed by the cache lines. In fact, code that is optimized for F-CPU aligns loop entries to 32 byte boundaries and it would not be wise to break this. Furthermore, the Flash memory is a rather slow device and is likely to be uncacheable (though its contents doesn't change, but you get the idea...). The SDRAM memory has much more bandwidth and can cope with prefetching so one can concentrate on code efficiency. * Concerning data : their access is often in a random order (or no order at all) so the caching debate is not the same. If all data accesses are done "in place" with "read" function calls, all we have to do is to align the data blocks on 64-bit boundaries (8 bytes). This is the minimal and mandatory register size for the whole F-CPU family so any compliant CPU can boot our system. So the block alignment is 64 bits (8 bytes) and we have to pack several data in the headers. Scenario : 1) the system boots a single kernel (Linux 4.8 for example) -> the kernel is compiled and the file is renamed "runfirst" so the boot code starts the kernel directly, thus benefitting >from all the kernel's facilities such as device drivers ... 2) multiple kernels : -> a multiboot binary is installed so the user can select which kernel he wants today. However the user interface is reduced to close to nothing : it has to first run the primary user I/O setup code (a call to exec with a keyboard driver then a video driver). When a kernel is selected, the manager "exec"s the corresponding "file". 3) development platform : -> it is possible to implement a bare shell (not as complex as bash but useful anyway). This interface must load the keyboard and screen modules as well as some romfs extensions to provide directories, for example. This is going to be useful in a simulated environment where the kernel must be rebuilt, for example. An editor, an assembler, a compiler, etc. are going to be provided and a "flasher" can generate a new flash image. 4) unsupported HW or old kernel : imagine you install a new HDD or a sound peripheral device which is not yet recognized by the kernel. or it's simply in development phase, or simply there's no kernel at all. Device dependent modules can be managed outside the bare boot process, simply by providing an "exec" function. All the decisions are left to the user. This is nice because we have no time to write a monolithic "BIOS" such as in the PC world, and it's so much more flexible. File format (no name yet) : * the boot/setup/library code is assembled and its size is rounded up to 8 bytes. The symbols are output to a file which is #include'd by the other modules so they can be assembled with the physical address of the basic functions. * all the modules are assembled and the binaries (and possibly, data files) are gathered by a "mkromfs" and the result is concatenated at the end of the bare boot image. This way it is possible change the modules without touching the boot code. * a "directory" contains a header followed by N data blocks. These blocks are copied "as is" (unless compressed) and aligned to 8 bytes (zero padded). The header contains : - size (4 bytes) - number of blocks/entries for each entry : - size of entry, size of the name, attributes (exec, compress, directory, link...) -> 64 bits - ASCIIZ file name - size of the block (in bytes) - index of the block (relative to the start of the romfs block, 8-byte aligned) The variable file names are a problem. It could be possible to limit it to 16 chars and use a fixed-size header structure so we can also get rid of the entry size field. ideas welcome. the "original" romfs format is a good idea (the file name is merged with the variable sized block) but i don't like to walk all around the ROM anyway (if the Flash works with page modes, then we're in troubles and contiguous accesses are better). It's not meant to be a high performance system but who ever knows, i don't like to make crap. I have not yet addressed the need for a CRC of the image. This is a heavy and slow process, but it might be needed in some conditions anyway. The locate, read and seek functions are pretty easy to implement, even in asm. Managing internal structures such as the read() buffers and handlers will also require a sort of "malloc()". This becomes even more important for exec or modules which need to expand data. exec requires a call to open, read, close, malloc and even a decompression code if the instructions are compressed. However most flags are unused and not likely to be useful before more development is done. directories, links etc are not yet supported and are not even necessary but the functionality is available and reserved. -------------------------------------------------------- Conclusion : this is slowly looking more like an "operating system" but with some strong constraints like footprint and (more difficult) the reduced I/O capabilities. Unlike the PC there is no "default" I/O at a fixed address and this makes the simulations inside a VHDL tool much more difficult. It remembers me that in the "early" computer ages, computers ran with small "monitors" and no BIOS. Today and in the future, the platforms evolve extremely fast and become so different >from each others that it is not possible to make any assumptions as before. One solution is to rely on the Linux or Hurd kernels because most of the necessary I/O handling is already provided. The problem is to provide enough basic I/O capabilities so that the kernel can boot properly, display its messages, get the minimum memory etc... This can be done with "modules" that are also stored in a romfs-like system. OTOH a read-only file system for a bare CPU is very easy to implement. Only a reduced set of functions must be coded so it's a good candidate for assembly coding, which in turn gives a "live" example of how to write code for the F-CPU. --------------98D218F992B6603B012F273E-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Mar 13 08:38:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16l5rX-0005zp-00 for ; Wed, 13 Mar 2002 11:20:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 11:20:03 +0100 (CET) Received: (qmail 32143 invoked by uid 0); 13 Mar 2002 07:40:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 13 Mar 2002 07:40:58 -0000 Received: by moria.seul.org (Postfix) id 818EF1462FD; Wed, 13 Mar 2002 02:40:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7DB9E14640E; Wed, 13 Mar 2002 02:40:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 885181462FD for ; Wed, 13 Mar 2002 02:40:56 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16l3LH-0002jM-00 for f-cpu@seul.org; Wed, 13 Mar 2002 08:38:35 +0100 Date: Wed, 13 Mar 2002 08:38:35 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS In-Reply-To: <20020313011539.22862@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 13 Mar 2002, Michael Riepe wrote: > On Wed, Mar 13, 2002 at 12:14:42AM +0100, Yann Guidon wrote: > > Hello, > > > > The recent installation of the Linux From Scratch system > > on my new HDD triggered a lot of question, including : > > how will we get this damn CPU boot such a complex system ? > > By writing a decent BIOS? ;) Oh - come on! Do you really want to copy the PC strategy? Keep it more simple instead. Update of the boot part all the time for new devices is a sh%&! I loved that MAC approach where you plugged in a card and it worked with the operating system - no installation of drivers a.s.o. The operating system and the boot loader should only be managing. The devices itself should bring the devices functionality in. With device I mean software as well as hardware approaches/add-ons. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Mar 13 09:14:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16l5rX-0005zp-01 for ; Wed, 13 Mar 2002 11:20:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 11:20:03 +0100 (CET) Received: (qmail 32478 invoked by uid 0); 13 Mar 2002 08:16:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 13 Mar 2002 08:16:18 -0000 Received: by moria.seul.org (Postfix) id 6DFA81463AB; Wed, 13 Mar 2002 03:16:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 369811467ED; Wed, 13 Mar 2002 03:16:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 9B0DD1463AB for ; Wed, 13 Mar 2002 03:16:16 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id BAA27682 for ; Wed, 13 Mar 2002 01:16:15 -0700 (MST) Message-ID: <3C8F0A6B.DAFB2EE4@jetnet.ab.ca> Date: Wed, 13 Mar 2002 01:14:35 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > I loved that MAC approach where you plugged in a card and > it worked with the operating system - no installation of > drivers a.s.o. > > The operating system and the boot loader should only be > managing. The devices itself should bring the devices > functionality in. With device I mean software as well > as hardware approaches/add-ons. Forget the MAC ... look at the apple. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Mar 13 15:23:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lCRA-00027L-00 for ; Wed, 13 Mar 2002 18:21:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 18:21:16 +0100 (CET) Received: (qmail 18360 invoked by uid 0); 13 Mar 2002 14:23:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 13 Mar 2002 14:23:36 -0000 Received: by moria.seul.org (Postfix) id 7AEE5146802; Wed, 13 Mar 2002 09:23:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 67089146806; Wed, 13 Mar 2002 09:23:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3395B146802 for ; Wed, 13 Mar 2002 09:23:35 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id 0B40D1764; Wed, 13 Mar 2002 15:23:33 +0100 (CET) Received: from [132.227.86.2] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Re: help with linux from scratch Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Mar 2002 15:23:33 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 Juergen Goeritz wrote to me : >On Tue, 12 Mar 2002 whygee=40club-internet.fr wrote: >> BTW i just read a CMP magazine i got in DATE, called =22Embedded System= s=22 >> (http://www.allembedded.com) and there are some very interesting >> things, explaining for example how uClinux works (a MMU-less system). >> Another page is a product announcement for a very ... sexy product : >> the ProASICPlus FLASH-FPGA from ACTEL is a see of 3-input >> gates with a hierarchical interconnect, PLLs, up to 712 I/O, >> up to 198Kbits of dual/ported RAM, up to 1 million gates... >> it boots up instantly because it's not a SRAM but FLASH configuration >> (no download from external EPROM) and it can work at around >> 100MHz (max. internal clock speed : 240MHz). I WANT ONE =21=21=21=21=21 >> = >> YG :-) > >Hi, > >why don't you just ask Atmel application engineers if >they would give you an evaluation board and software >for a limited time to check? > >Fragen kostet nichts - as we Germans tend to say. i'd rather have some =22real=22 source code to simulate and synthesize, no= ? going after them for running some Kgates on a Mgates circuit is a bit... adventurous. but i'll ask as soon as possible :-) >read you soon :-) >JG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Mar 13 17:22:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lCRC-00027L-01 for ; Wed, 13 Mar 2002 18:21:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 18:21:18 +0100 (CET) Received: (qmail 26333 invoked by uid 0); 13 Mar 2002 16:22:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 13 Mar 2002 16:22:46 -0000 Received: by moria.seul.org (Postfix) id 97E6E1467FA; Wed, 13 Mar 2002 11:22:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8760E146804; Wed, 13 Mar 2002 11:22:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 3E4A21467FA for ; Wed, 13 Mar 2002 11:22:44 -0500 (EST) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix3-2.free.fr (Postfix) with ESMTP id A6E3317FA6 for ; Wed, 13 Mar 2002 17:22:43 +0100 (CET) Received: by imp3-1.free.fr (Postfix, from userid 33) id 991C7FD96; Wed, 13 Mar 2002 17:22:43 +0100 (MET) To: f-cpu@seul.org Subject: [f-cpu] Shift and rotate instruction Message-ID: <1016036563.3c8f7cd3865e1@imp3-1.free.fr> Date: Wed, 13 Mar 2002 17:22:43 +0100 (MET) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Because I find some wrong latex code in rotl.tex, I wasn't able to understand how shift and rotate are done when you are in a SIMD mode ? I mean, is each chunk of the register who indicate how many bits to shift specifing each chunk of the register who contain the bits to shift, or we only use the first chunk of R2 to specifie this number ? A second question, that is only for logical reason, is for all 3 members shift and rotate instructions R2 means the number of bits to shift, and R3 the bits to shift, right ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Mar 13 17:24:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lCRD-00027L-00 for ; Wed, 13 Mar 2002 18:21:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 13 Mar 2002 18:21:19 +0100 (CET) Received: (qmail 5035 invoked by uid 0); 13 Mar 2002 16:25:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 13 Mar 2002 16:25:00 -0000 Received: by moria.seul.org (Postfix) id 42CAF146800; Wed, 13 Mar 2002 11:24:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E1C8146807; Wed, 13 Mar 2002 11:24:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id EC5F2146800 for ; Wed, 13 Mar 2002 11:24:58 -0500 (EST) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id 660175FA2A for ; Wed, 13 Mar 2002 17:24:58 +0100 (CET) Received: by imp1-2.free.fr (Postfix, from userid 33) id 5440487436; Wed, 13 Mar 2002 17:24:58 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs Message-ID: <1016036698.3c8f7d5a3cab2@imp.free.fr> Date: Wed, 13 Mar 2002 17:24:58 +0100 (MET) From: Cedric BAIL References: <3C8ED029.D4B4BDAA@f-cpu.org> In-Reply-To: <3C8ED029.D4B4BDAA@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I didn't agry with your vision of a bios that his really like a PC BIOS. But first what are the possibility for a boot process actually : - Stupid BIOS, who is only doing the initialisation of the needed peripheric and give the hand to the first code on the specified disk (it could be a cdrom, or whatever you wan't, but local). - A firmware, what you're wanting to do,that mean that he will select which kernel to boot and so on. I think, that we need to reflash the ROM every time we update our kernel... And it will be very complicated for booting OS like hurd... - Directly boot a linux, like in the linuxBIOS project. I think, that not a so bad idea, but you need a big ROM to boot... This solution give you to easily boot over NFS with out having any HD. The only problem, is that we need to port Linux on it first, a job that will be done a day however. Personnaly I prefer the first solution, because more complex a bios, more time it take for a boot, and to be stable. An other think is that in a lot of case the kernel will redo what it has been done by it... A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Mar 13 18:08:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lHk6-0005sP-00 for ; Thu, 14 Mar 2002 00:01:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 00:01:10 +0100 (CET) Received: (qmail 3692 invoked by uid 0); 13 Mar 2002 17:09:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 13 Mar 2002 17:09:49 -0000 Received: by moria.seul.org (Postfix) id 0FE6D146807; Wed, 13 Mar 2002 12:09:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 09959146809; Wed, 13 Mar 2002 12:09:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 715E0146807 for ; Wed, 13 Mar 2002 12:09:47 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-209.jetnet.ab.ca [207.34.60.209]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA01771 for ; Wed, 13 Mar 2002 10:09:46 -0700 (MST) Message-ID: <3C8F8772.9A6E22A3@jetnet.ab.ca> Date: Wed, 13 Mar 2002 10:08:02 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <1016036698.3c8f7d5a3cab2@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL wrote: > Personnaly I prefer the first solution, because more complex a bios, more > time it take for a boot, and to be stable. An other think is that in a lot of > case the kernel will redo what it has been done by it... The bios needs well thought out boot virtual devices. I think it may be wise to have F-CPU I/O devices in FPGA to handle disk, and one for User interface and one for Video display as very little I/O nowadays is open source. The PC's bios is a good example of how not to write a BIOS. While CPU's have been streamlined I/O devices still need too much software hand holding to run. Take a floppy disk drive , you need to program 1) floppy controller 2) DMA channel 3) timer for motor 4) IRQ devices 5) Memory management 6) I/O ports for things like disk in drive, eject. Ideally I would like a bios to have floppy.status(),floppy.seek(),floppy.r/w(),floppy.initialize() as standard calls with medium level abstraction. You get a cleaner interface I hope. You get a HD ... oh that is just a floppy with more sectors! Why write a New OS for every new device... we got a REAL BIOS it does all the work. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Mar 13 19:57:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lHk7-0005sP-00 for ; Thu, 14 Mar 2002 00:01:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 00:01:11 +0100 (CET) Received: (qmail 24008 invoked by uid 0); 13 Mar 2002 18:57:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 13 Mar 2002 18:57:34 -0000 Received: by moria.seul.org (Postfix) id DEF47146808; Wed, 13 Mar 2002 13:57:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DA6B114680C; Wed, 13 Mar 2002 13:57:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 92CE3146808 for ; Wed, 13 Mar 2002 13:57:32 -0500 (EST) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-2v.club-internet.fr (Postfix) with SMTP id 2CBB11863; Wed, 13 Mar 2002 19:57:30 +0100 (CET) Received: from [132.227.86.2] by flashmail-2v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] more about f-romfs Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Mar 2002 19:57:30 +0100 (CET) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote : >I didn't agry with your vision of a bios that his really like a PC BIOS. i think you are a bit mistaken. What i want to do (others can still do their own thing) is a minimalistic =22monitor=22 that provides some utlra-basic functions and then hands the rest of the device-specific management to other modules. The =22usual=22 romfs is a very simple protocol that is explained at http://www.linuxhq.com/kernel/v2.2/doc/filesystems/romfs.txt.html for example. i want to do something silimar which can be easily programmed in asm and simulated in VHDL environment. >But first what are the possibility for a boot process actually : > - Stupid BIOS, who is only doing the initialisation of the needed >peripheric and give the hand to the first code on the specified disk (it = could >be a cdrom, or whatever you wan't, but local). There is a problem here : we don't have any HW, I/O or any protocol yet. How can you program a BIOS if there is no IO ? > - A firmware, what you're wanting to do,that mean that he will >select which kernel to boot and so on. I think, that we need to reflash >the ROM every time we update our kernel... And it will be very complicate= d >for booting OS like hurd... ??? Today's flash can be reprogrammed 10K+ times and rather quickly. I have a bunch of 1Mb EEPROMs (coming from broken PCs) and a single pair can give 256 K bytes with a 16-bit bus. Controlling them is rather easy. And if your Hurd does not fit in the EPROM, even compressed, put a HDD setup module and a Hurd loader in EPROM. > - Directly boot a linux, like in the linuxBIOS project. I think, that >not a so bad idea, but you need a big ROM to boot... If your kernel is <1MB i see no problem (that's 8Mbits which is still decent). > This solution give you >to easily boot over NFS with out having any HD. The only problem, is that= we = >need to port Linux on it first, a job that will be done a day however. but to develop it, we need tools that allow us to =22play=22 with it. a simple monitor with a romfs can do the trick with negligible overhead. >Personnaly I prefer the first solution, because more complex a bios, more >time it take for a boot, and to be stable. in order to boot the kernel, you have to read the HDD. But you have to detect it and initialize it, and we're not in a PC where most I/O have fixed addresses (ie kbd and screen) so using HW-specific =22modules=22 is =22safe=22, =22simple=22, =22fast=22 and =22configurable=22= =2E After all, if the boot routine is accessible in Flash, then anyone can write his own version. = > An other think is that in a lot of >case the kernel will redo what it has been done by it... right, so why spend time reinventing the wheel when = the Linux team has done all the work ? ;-) when can we meet soon ? >A+ > Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 13 22:11:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lHkS-0005sP-00 for ; Thu, 14 Mar 2002 00:01:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 00:01:32 +0100 (CET) Received: (qmail 20572 invoked by uid 0); 13 Mar 2002 22:26:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 13 Mar 2002 22:26:32 -0000 Received: by moria.seul.org (Postfix) id 7B50914680C; Wed, 13 Mar 2002 17:26:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 748BE146811; Wed, 13 Mar 2002 17:26:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 036A814680C for ; Wed, 13 Mar 2002 17:26:31 -0500 (EST) Received: from ifurita (212.194.228.160) by mail.laposte.net (5.5.044) id 3C8F23910000F77A for f-cpu@seul.org; Wed, 13 Mar 2002 23:26:29 +0100 Message-ID: <005501c1cad3$afe95820$a0e4c2d4@ifurita> From: "Christophe" To: References: <3C8ED029.D4B4BDAA@f-cpu.org> Subject: Re: [f-cpu] more about f-romfs Date: Wed, 13 Mar 2002 22:11:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N There is also CRAMFS which is basicaly a zip compressed ROMFS. ----- Original Message ----- From: Yann Guidon To: fm Sent: Wednesday, March 13, 2002 5:06 AM Subject: [f-cpu] more about f-romfs > > here are some more thoughts and contextual stuff. > it's preliminary and moving, there's no code yet. > > however i think it is a good answer to the people > who want a "BIOS" for F-CPU. First it is impossible > to do that on a platform where there is only a CPU > and then i understand that in the past years, the > PC BIOSes have increased in complexity to a point > where it's unmanageable. Having a small boot routine > with a romfs-like support is a cool solution. > > i have to sleep now, after i read the comments that > i just got. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------- - > f-romfs.txt > created mer mar 13 03:30:43 GMT 2002 by whygee@f-cpu.org > > A discussion about a "file format", the associated algorithm > and the context of using a romfs-like system. > > -------------------------------------------------------- > > BIOS/Monitor/extensions : > > The F-CPU processor is designed to boot at address 0 > after reset. It will fetch its instructions from a > non-volatile memory or an image of this data if the > system is simulated in VHDL or C. The boot code will detect and > initialize all the fundamental devices such as the memory > controllers. For example, the refresh rate will be tuned, > the bank size will be adjusted and the base address of the > private memory range will be set to an unused range > (if the system is comprised of several CPU with their own > private address ranges, but they must not overlap). > > The boot memory also contains very low-level and primitive > routines for doing basic stuff, such as sending error > messages (to a virtual console that is mapped somewhere > in the CPU, probably the SR). When done, we have to > initialise a lot of other things which are independent > from the F-CPU project and we don't have the means > to work on the HDD controller, the keyboard driver, > the video framebuffer... You'll understand that we don't > want to mess with it, a single CPU is already complex enough. > > We would like to let the user configure his system > and install only the necessary drivers, or customize it with > his driver for his prototype peripheral, etc. > But we don't have access to a file system because > the HDD is not yet setup ! this would bloat the code > or make it too complex. OTOH we would like to let the > user interact with the HW. > > The solution is to use something that looks like > romfs : we have access to user-provided data and > code modules and we have to provide a few functions > that allow the modules to interact in a read-only way : > - locate : return the physical address of the requested block > - open : returns a handle to the specified block > - close : close handle > - read : get a word > - seek : goto a specified offset in the "file" > - exec : specify a file and run it > > since the additional modules are meant to > provide development or debug tools, it is useful > to use "directories" and "symbolic links". > This is done with the help of "flags", just like > a normal FS. we can add other flags : executable > (so a user won't attempt to execute raw data), > and compressed (in case we have some room for > the decompression tables and code, when the > Flash will be completely filled with tux > pictures etc...) > > The Flash image will be built with a simple > $ cp bareboot.bin newimage.bin > $ cat modules.romfs >> newimage.bin > $ installflash newimage.bin > (science fictious) > > The bareboot.bin file is built from an assembly > langage source containing : > - the startup code > - RAM initialisation code > - the minimum libraries : decompression, romfs utilities > and some additional stuff as needed > > The modules in modules.romfs are built from > an utility (kind of mkromfs) with a set of specified > files which are also assembled, using symbols extracted > from the startup/library code. The modules' code must > be position-independently coded because when executed, > the code (which can be decompacted) will be copied > and aligned in private/fast memory. > > When all the minimal setup is performed (RAM and IRQ, > for example) then the boot code uses the romfs functions > to access the romfs part of the Flash, seeking a "startup" > binary which will then initialise the rest, using > internal scripts or facilities that the user can customize > at will. The file could be named "runfirst" for example. > If no romfs is found (starting at the end > of the boot block) or if the startup file is absent, > the CPU sends an error code to the virtual console > and enters an infinite loop or in shutdown state. > > Granularity : F-CPU is a byte-addressing machine > but the architecture does not like unaligned instructions > or data access. > * Concerning the instructions, the code > blocks should be copied to the main memory and > the starting address must be aligned to the 256 > bit boundary imposed by the cache lines. In fact, > code that is optimized for F-CPU aligns loop entries > to 32 byte boundaries and it would not be wise > to break this. Furthermore, the Flash memory is > a rather slow device and is likely to be uncacheable > (though its contents doesn't change, but you get > the idea...). The SDRAM memory has much more bandwidth > and can cope with prefetching so one can concentrate > on code efficiency. > * Concerning data : their access is often in a random > order (or no order at all) so the caching debate is > not the same. If all data accesses are done "in place" > with "read" function calls, all we have to do is to > align the data blocks on 64-bit boundaries (8 bytes). > This is the minimal and mandatory register size for > the whole F-CPU family so any compliant CPU can boot > our system. > > So the block alignment is 64 bits (8 bytes) and we > have to pack several data in the headers. > > > Scenario : > 1) the system boots a single kernel (Linux 4.8 for example) > -> the kernel is compiled and the file is renamed "runfirst" > so the boot code starts the kernel directly, thus benefitting > from all the kernel's facilities such as device drivers ... > > 2) multiple kernels : > -> a multiboot binary is installed so the user can select > which kernel he wants today. However the user interface > is reduced to close to nothing : it has to first run the > primary user I/O setup code (a call to exec with a keyboard > driver then a video driver). When a kernel is selected, > the manager "exec"s the corresponding "file". > > 3) development platform : > -> it is possible to implement a bare shell (not as complex > as bash but useful anyway). This interface must load > the keyboard and screen modules as well as some romfs > extensions to provide directories, for example. > This is going to be useful in a simulated environment where > the kernel must be rebuilt, for example. An editor, > an assembler, a compiler, etc. are going to be provided > and a "flasher" can generate a new flash image. > > 4) unsupported HW or old kernel : > imagine you install a new HDD or a sound peripheral device > which is not yet recognized by the kernel. or it's simply > in development phase, or simply there's no kernel at all. > Device dependent modules can be managed outside the bare > boot process, simply by providing an "exec" function. All the > decisions are left to the user. > > This is nice because we have no time to write a monolithic > "BIOS" such as in the PC world, and it's so much more flexible. > > > File format (no name yet) : > > * the boot/setup/library code is assembled and its > size is rounded up to 8 bytes. The symbols are output > to a file which is #include'd by the other modules > so they can be assembled with the physical address of > the basic functions. > > * all the modules are assembled and the binaries > (and possibly, data files) are gathered by a "mkromfs" > and the result is concatenated at the end of the bare > boot image. This way it is possible change the modules > without touching the boot code. > > * a "directory" contains a header followed > by N data blocks. These blocks are copied > "as is" (unless compressed) and aligned to 8 bytes > (zero padded). The header contains : > > - size (4 bytes) > - number of blocks/entries > for each entry : > - size of entry, size of the name, > attributes (exec, compress, directory, link...) > -> 64 bits > - ASCIIZ file name > - size of the block (in bytes) > - index of the block (relative to the start of > the romfs block, 8-byte aligned) > > The variable file names are a problem. It could be possible > to limit it to 16 chars and use a fixed-size header structure > so we can also get rid of the entry size field. > ideas welcome. the "original" romfs format is a good idea > (the file name is merged with the variable sized block) > but i don't like to walk all around the ROM anyway > (if the Flash works with page modes, then we're in troubles > and contiguous accesses are better). It's not meant to > be a high performance system but who ever knows, i don't > like to make crap. > > > I have not yet addressed the need for a CRC of the > image. This is a heavy and slow process, but it might > be needed in some conditions anyway. > > The locate, read and seek functions are pretty easy > to implement, even in asm. Managing internal structures > such as the read() buffers and handlers will also require > a sort of "malloc()". This becomes even more important > for exec or modules which need to expand data. > > exec requires a call to open, read, close, malloc > and even a decompression code if the instructions > are compressed. However most flags are unused > and not likely to be useful before more development > is done. directories, links etc are not yet supported > and are not even necessary but the functionality is > available and reserved. > > -------------------------------------------------------- > > Conclusion : this is slowly looking more like an "operating > system" but with some strong constraints like footprint > and (more difficult) the reduced I/O capabilities. > Unlike the PC there is no "default" I/O at a fixed address > and this makes the simulations inside a VHDL tool much > more difficult. > > It remembers me that in the "early" computer ages, computers > ran with small "monitors" and no BIOS. Today and in the future, > the platforms evolve extremely fast and become so different > from each others that it is not possible to make any > assumptions as before. > > One solution is to rely on the Linux or Hurd kernels because > most of the necessary I/O handling is already provided. > The problem is to provide enough basic I/O capabilities > so that the kernel can boot properly, display its messages, > get the minimum memory etc... This can be done with "modules" > that are also stored in a romfs-like system. > > OTOH a read-only file system for a bare CPU is very easy > to implement. Only a reduced set of functions must be coded > so it's a good candidate for assembly coding, which in turn > gives a "live" example of how to write code for the F-CPU. > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 13 22:14:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lHkT-0005sP-00 for ; Thu, 14 Mar 2002 00:01:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 00:01:33 +0100 (CET) Received: (qmail 9689 invoked by uid 0); 13 Mar 2002 22:29:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 13 Mar 2002 22:29:19 -0000 Received: by moria.seul.org (Postfix) id 75C7614680E; Wed, 13 Mar 2002 17:29:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CDC4146812; Wed, 13 Mar 2002 17:29:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id E26AD14680E for ; Wed, 13 Mar 2002 17:29:17 -0500 (EST) Received: from ifurita (212.194.228.160) by mail.laposte.net (5.5.044) id 3C4BFED40037F2C1 for f-cpu@seul.org; Wed, 13 Mar 2002 23:29:16 +0100 Message-ID: <005d01c1cad4$135e28e0$a0e4c2d4@ifurita> From: "Christophe" To: References: <3C8ED029.D4B4BDAA@f-cpu.org> Subject: Re: [f-cpu] more about f-romfs Date: Wed, 13 Mar 2002 22:14:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Because ROMFS is read-only, directory names are never changed, so you'd better to have a offset and size name, and all name strings would be in a large block. ----- Original Message ----- From: Yann Guidon To: fm Sent: Wednesday, March 13, 2002 5:06 AM Subject: [f-cpu] more about f-romfs > > here are some more thoughts and contextual stuff. > it's preliminary and moving, there's no code yet. > > however i think it is a good answer to the people > who want a "BIOS" for F-CPU. First it is impossible > to do that on a platform where there is only a CPU > and then i understand that in the past years, the > PC BIOSes have increased in complexity to a point > where it's unmanageable. Having a small boot routine > with a romfs-like support is a cool solution. > > i have to sleep now, after i read the comments that > i just got. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------- - > f-romfs.txt > created mer mar 13 03:30:43 GMT 2002 by whygee@f-cpu.org > > A discussion about a "file format", the associated algorithm > and the context of using a romfs-like system. > > -------------------------------------------------------- > > BIOS/Monitor/extensions : > > The F-CPU processor is designed to boot at address 0 > after reset. It will fetch its instructions from a > non-volatile memory or an image of this data if the > system is simulated in VHDL or C. The boot code will detect and > initialize all the fundamental devices such as the memory > controllers. For example, the refresh rate will be tuned, > the bank size will be adjusted and the base address of the > private memory range will be set to an unused range > (if the system is comprised of several CPU with their own > private address ranges, but they must not overlap). > > The boot memory also contains very low-level and primitive > routines for doing basic stuff, such as sending error > messages (to a virtual console that is mapped somewhere > in the CPU, probably the SR). When done, we have to > initialise a lot of other things which are independent > from the F-CPU project and we don't have the means > to work on the HDD controller, the keyboard driver, > the video framebuffer... You'll understand that we don't > want to mess with it, a single CPU is already complex enough. > > We would like to let the user configure his system > and install only the necessary drivers, or customize it with > his driver for his prototype peripheral, etc. > But we don't have access to a file system because > the HDD is not yet setup ! this would bloat the code > or make it too complex. OTOH we would like to let the > user interact with the HW. > > The solution is to use something that looks like > romfs : we have access to user-provided data and > code modules and we have to provide a few functions > that allow the modules to interact in a read-only way : > - locate : return the physical address of the requested block > - open : returns a handle to the specified block > - close : close handle > - read : get a word > - seek : goto a specified offset in the "file" > - exec : specify a file and run it > > since the additional modules are meant to > provide development or debug tools, it is useful > to use "directories" and "symbolic links". > This is done with the help of "flags", just like > a normal FS. we can add other flags : executable > (so a user won't attempt to execute raw data), > and compressed (in case we have some room for > the decompression tables and code, when the > Flash will be completely filled with tux > pictures etc...) > > The Flash image will be built with a simple > $ cp bareboot.bin newimage.bin > $ cat modules.romfs >> newimage.bin > $ installflash newimage.bin > (science fictious) > > The bareboot.bin file is built from an assembly > langage source containing : > - the startup code > - RAM initialisation code > - the minimum libraries : decompression, romfs utilities > and some additional stuff as needed > > The modules in modules.romfs are built from > an utility (kind of mkromfs) with a set of specified > files which are also assembled, using symbols extracted > from the startup/library code. The modules' code must > be position-independently coded because when executed, > the code (which can be decompacted) will be copied > and aligned in private/fast memory. > > When all the minimal setup is performed (RAM and IRQ, > for example) then the boot code uses the romfs functions > to access the romfs part of the Flash, seeking a "startup" > binary which will then initialise the rest, using > internal scripts or facilities that the user can customize > at will. The file could be named "runfirst" for example. > If no romfs is found (starting at the end > of the boot block) or if the startup file is absent, > the CPU sends an error code to the virtual console > and enters an infinite loop or in shutdown state. > > Granularity : F-CPU is a byte-addressing machine > but the architecture does not like unaligned instructions > or data access. > * Concerning the instructions, the code > blocks should be copied to the main memory and > the starting address must be aligned to the 256 > bit boundary imposed by the cache lines. In fact, > code that is optimized for F-CPU aligns loop entries > to 32 byte boundaries and it would not be wise > to break this. Furthermore, the Flash memory is > a rather slow device and is likely to be uncacheable > (though its contents doesn't change, but you get > the idea...). The SDRAM memory has much more bandwidth > and can cope with prefetching so one can concentrate > on code efficiency. > * Concerning data : their access is often in a random > order (or no order at all) so the caching debate is > not the same. If all data accesses are done "in place" > with "read" function calls, all we have to do is to > align the data blocks on 64-bit boundaries (8 bytes). > This is the minimal and mandatory register size for > the whole F-CPU family so any compliant CPU can boot > our system. > > So the block alignment is 64 bits (8 bytes) and we > have to pack several data in the headers. > > > Scenario : > 1) the system boots a single kernel (Linux 4.8 for example) > -> the kernel is compiled and the file is renamed "runfirst" > so the boot code starts the kernel directly, thus benefitting > from all the kernel's facilities such as device drivers ... > > 2) multiple kernels : > -> a multiboot binary is installed so the user can select > which kernel he wants today. However the user interface > is reduced to close to nothing : it has to first run the > primary user I/O setup code (a call to exec with a keyboard > driver then a video driver). When a kernel is selected, > the manager "exec"s the corresponding "file". > > 3) development platform : > -> it is possible to implement a bare shell (not as complex > as bash but useful anyway). This interface must load > the keyboard and screen modules as well as some romfs > extensions to provide directories, for example. > This is going to be useful in a simulated environment where > the kernel must be rebuilt, for example. An editor, > an assembler, a compiler, etc. are going to be provided > and a "flasher" can generate a new flash image. > > 4) unsupported HW or old kernel : > imagine you install a new HDD or a sound peripheral device > which is not yet recognized by the kernel. or it's simply > in development phase, or simply there's no kernel at all. > Device dependent modules can be managed outside the bare > boot process, simply by providing an "exec" function. All the > decisions are left to the user. > > This is nice because we have no time to write a monolithic > "BIOS" such as in the PC world, and it's so much more flexible. > > > File format (no name yet) : > > * the boot/setup/library code is assembled and its > size is rounded up to 8 bytes. The symbols are output > to a file which is #include'd by the other modules > so they can be assembled with the physical address of > the basic functions. > > * all the modules are assembled and the binaries > (and possibly, data files) are gathered by a "mkromfs" > and the result is concatenated at the end of the bare > boot image. This way it is possible change the modules > without touching the boot code. > > * a "directory" contains a header followed > by N data blocks. These blocks are copied > "as is" (unless compressed) and aligned to 8 bytes > (zero padded). The header contains : > > - size (4 bytes) > - number of blocks/entries > for each entry : > - size of entry, size of the name, > attributes (exec, compress, directory, link...) > -> 64 bits > - ASCIIZ file name > - size of the block (in bytes) > - index of the block (relative to the start of > the romfs block, 8-byte aligned) > > The variable file names are a problem. It could be possible > to limit it to 16 chars and use a fixed-size header structure > so we can also get rid of the entry size field. > ideas welcome. the "original" romfs format is a good idea > (the file name is merged with the variable sized block) > but i don't like to walk all around the ROM anyway > (if the Flash works with page modes, then we're in troubles > and contiguous accesses are better). It's not meant to > be a high performance system but who ever knows, i don't > like to make crap. > > > I have not yet addressed the need for a CRC of the > image. This is a heavy and slow process, but it might > be needed in some conditions anyway. > > The locate, read and seek functions are pretty easy > to implement, even in asm. Managing internal structures > such as the read() buffers and handlers will also require > a sort of "malloc()". This becomes even more important > for exec or modules which need to expand data. > > exec requires a call to open, read, close, malloc > and even a decompression code if the instructions > are compressed. However most flags are unused > and not likely to be useful before more development > is done. directories, links etc are not yet supported > and are not even necessary but the functionality is > available and reserved. > > -------------------------------------------------------- > > Conclusion : this is slowly looking more like an "operating > system" but with some strong constraints like footprint > and (more difficult) the reduced I/O capabilities. > Unlike the PC there is no "default" I/O at a fixed address > and this makes the simulations inside a VHDL tool much > more difficult. > > It remembers me that in the "early" computer ages, computers > ran with small "monitors" and no BIOS. Today and in the future, > the platforms evolve extremely fast and become so different > from each others that it is not possible to make any > assumptions as before. > > One solution is to rely on the Linux or Hurd kernels because > most of the necessary I/O handling is already provided. > The problem is to provide enough basic I/O capabilities > so that the kernel can boot properly, display its messages, > get the minimum memory etc... This can be done with "modules" > that are also stored in a romfs-like system. > > OTOH a read-only file system for a bare CPU is very easy > to implement. Only a reduced set of functions must be coded > so it's a good candidate for assembly coding, which in turn > gives a "live" example of how to write code for the F-CPU. > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 13 10:49:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lMHO-0000Su-00 for ; Thu, 14 Mar 2002 04:51:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 04:51:50 +0100 (CET) Received: (qmail 5057 invoked by uid 0); 13 Mar 2002 23:24:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 13 Mar 2002 23:24:54 -0000 Received: by moria.seul.org (Postfix) id 7B9451467ED; Wed, 13 Mar 2002 18:24:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B27A146814; Wed, 13 Mar 2002 18:24:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a057.home.uni-hannover.de [130.75.232.57]) by moria.seul.org (Postfix) with ESMTP id AD6461467ED for ; Wed, 13 Mar 2002 18:24:51 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id KAA00513; Wed, 13 Mar 2002 10:49:32 +0100 Message-ID: <20020313104932.27004@thrai.stud.uni-hannover.de> Date: Wed, 13 Mar 2002 10:49:32 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: <20020313011539.22862@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Mar 13, 2002 at 08:38:35AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 13, 2002 at 08:38:35AM +0100, Juergen Goeritz wrote: [...] > > By writing a decent BIOS? ;) > > Oh - come on! Do you really want to copy the PC strategy? > Keep it more simple instead. Update of the boot part all > the time for new devices is a sh%&! I never said "PC", did I? It might be a good idea to adopt something like EFI or OpenBoot. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 13 10:31:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lMHO-0000Su-01 for ; Thu, 14 Mar 2002 04:51:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 04:51:50 +0100 (CET) Received: (qmail 9394 invoked by uid 0); 13 Mar 2002 23:25:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 13 Mar 2002 23:25:00 -0000 Received: by moria.seul.org (Postfix) id 68F5E146816; Wed, 13 Mar 2002 18:25:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 660A0146815; Wed, 13 Mar 2002 18:25:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a057.home.uni-hannover.de [130.75.232.57]) by moria.seul.org (Postfix) with ESMTP id 56A56146814 for ; Wed, 13 Mar 2002 18:24:54 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id KAA00462; Wed, 13 Mar 2002 10:31:21 +0100 Message-ID: <20020313103121.05554@thrai.stud.uni-hannover.de> Date: Wed, 13 Mar 2002 10:31:21 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-ROFS References: <3C8E8BE2.65E67E6F@f-cpu.org> <20020313011539.22862@thrai.stud.uni-hannover.de> <3C8EA1B8.30F981D9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C8EA1B8.30F981D9@f-cpu.org>; from Yann Guidon on Wed, Mar 13, 2002 at 01:47:52AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 13, 2002 at 01:47:52AM +0100, Yann Guidon wrote: [...] > I also thought about using the trap/syscall instructions but it > creates a little problem. I don't have the instruction map in hand > but syscall has an immediate data word which indicates the service > to request. So it jumps in kernel mode to service*64 + sr_syscall_base, > and does its things. So it implies that the character is present in a > previously specified register which must be read later. It also > implies that the syscall mechanism is setup but what happens if > there's an error at that time ?... You can also encode the character in the syscall number ;-) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Mar 14 01:20:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lMHP-0000Su-00 for ; Thu, 14 Mar 2002 04:51:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 14 Mar 2002 04:51:51 +0100 (CET) Received: (qmail 24376 invoked by uid 0); 14 Mar 2002 00:20:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 14 Mar 2002 00:20:43 -0000 Received: by moria.seul.org (Postfix) id 72CB01467F3; Wed, 13 Mar 2002 19:20:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 70B3D146815; Wed, 13 Mar 2002 19:20:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a057.home.uni-hannover.de [130.75.232.57]) by moria.seul.org (Postfix) with ESMTP id 0B9A01467F3 for ; Wed, 13 Mar 2002 19:20:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01439; Thu, 14 Mar 2002 01:20:39 +0100 Message-ID: <20020314012038.28470@thrai.stud.uni-hannover.de> Date: Thu, 14 Mar 2002 01:20:38 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Shift and rotate instruction References: <1016036563.3c8f7cd3865e1@imp3-1.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1016036563.3c8f7cd3865e1@imp3-1.free.fr>; from Cedric BAIL on Wed, Mar 13, 2002 at 05:22:43PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 13, 2002 at 05:22:43PM +0100, Cedric BAIL wrote: > Because I find some wrong latex code in rotl.tex, I wasn't able to > understand how shift and rotate are done when you are in a SIMD mode ? > > I mean, is each chunk of the register who indicate how many bits to shift > specifing each chunk of the register who contain the bits to shift, or we > only use the first chunk of R2 to specifie this number ? In the current implementation, there is a common shift count for all chunks, taken from the least significant 3...6 bits. > A second question, that is only for logical reason, is for all 3 members > shift and rotate instructions R2 means the number of bits to shift, and > R3 the bits to shift, right ? The syntax should be: shiftxy shift_count, source, destination where shift_count may be a register or an immediate operand. That is, r3 is the shift count, and the contents of r2 are shifted and the result placed into r1. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Mar 15 15:29:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16lvhg-0007XC-01 for ; Fri, 15 Mar 2002 18:41:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 15 Mar 2002 18:41:20 +0100 (CET) Received: (qmail 12463 invoked by uid 0); 15 Mar 2002 14:25:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 15 Mar 2002 14:25:30 -0000 Received: by moria.seul.org (Postfix) id E49C6146800; Fri, 15 Mar 2002 09:25:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5314146808; Fri, 15 Mar 2002 09:25:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf01bis.bellsouth.net (mail301.mail.bellsouth.net [205.152.58.161]) by moria.seul.org (Postfix) with ESMTP id 52C74146800 for ; Fri, 15 Mar 2002 09:25:28 -0500 (EST) Received: from computer ([209.215.11.31]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020315142639.UHAR13425.imf01bis.bellsouth.net@computer>; Fri, 15 Mar 2002 09:26:39 -0500 Message-ID: <000801c1cc2d$d778d720$1f0bd7d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin64 Boot-Load Process Date: Fri, 15 Mar 2002 08:29:38 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1CBFB.8C0433C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1CBFB.8C0433C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Erin64 has a very simple process using "Flash Memory" as = follows: 1. Issue Global Reset 2. Clear Program & Local Memory, Language Processor and Peripheral Processor 3 Write Program & Local Memory, both processors 4. Initialize Character Generators 5. Issue "RUN" to both Processors 6. Both Processors commence an "Initialize Routine" starting at address Zero. Upon completion both Processors execute a HLT Instruction with Interrupts Enabled. The Processors have nothing to process untill a USER at a one of 128 Terminals makes either a Keyboard entry or a Mouse Click selection. Or if an Inter-system Interrupt (ISI) request comes via the Expansion Port to the Peripheral Processor for a Hard Disk operation. For what it's worth Dick Hartney =20 ------=_NextPart_000_0005_01C1CBFB.8C0433C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    The Erin64 has a = very simple=20 process using "Flash Memory" as follows:
 
    1.  Issue = Global=20 Reset
    2.  Clear = Program &=20 Local Memory, Language Processor
        =20 and Peripheral Processor
    3   Write = Program=20 & Local Memory, both processors
    = 4.  Initialize=20 Character Generators
    5.  Issue "RUN" = to both=20 Processors
    6.  Both = Processors=20 commence an "Initialize Routine"
        = starting at=20 address Zero.  Upon completion both
        = Processors=20 execute a HLT Instruction with Interrupts
       =20 Enabled.  The Processors have nothing to process
        = untill a USER=20 at a one of 128 Terminals makes either
        a = Keyboard=20 entry or a Mouse Click selection.  Or if an
        = Inter-system=20 Interrupt (ISI) request comes via the
        = Expansion=20 Port to the Peripheral Processor for=20 a
         Hard Disk = operation.
 
For what it's worth
 
Dick = Hartney    
 
------=_NextPart_000_0005_01C1CBFB.8C0433C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Mar 15 19:51:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mJfr-0007OI-00 for ; Sat, 16 Mar 2002 20:17:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Mar 2002 20:17:03 +0100 (CET) Received: (qmail 8381 invoked by uid 0); 15 Mar 2002 18:47:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 15 Mar 2002 18:47:00 -0000 Received: by moria.seul.org (Postfix) id 67FA6146810; Fri, 15 Mar 2002 13:46:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57F1D146813; Fri, 15 Mar 2002 13:46:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by moria.seul.org (Postfix) with ESMTP id D2A69146810 for ; Fri, 15 Mar 2002 13:46:58 -0500 (EST) Received: from computer ([208.60.245.54]) by imf08bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020315184819.TSMJ29627.imf08bis.bellsouth.net@computer>; Fri, 15 Mar 2002 13:48:19 -0500 Message-ID: <000e01c1cc52$654fd5c0$36f53cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Power Loss Date: Fri, 15 Mar 2002 12:51:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C1CC20.19E2D380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C1CC20.19E2D380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When the Processor power fails - the 128 DUMB Terminals are also dead. I use one Processor to serve all 128 Terminals. That = brings up the question - are they all on the same power distribution = network? Solution - use a power back-up system depending on the System = Application. The system also receives a "Power ON Reset". This is excellent as far as = the FPGA I am using - this resets all of the FF's in the device. =20 I also use a centralized Hard Disk(s) File - one for the entire system. = The Peripheral Processor monitors Disk useage to flag when to add an additional Drive. I hope this answers your question satisfactorily. If not - do it again. Dick Hartney ------=_NextPart_000_000B_01C1CC20.19E2D380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When the Processor power fails - the = 128 DUMB=20 Terminals
are also dead.  I use one = Processor to serve=20 all 128 Terminals. That brings up the question - are they all on the = same power=20 distribution network?  Solution - use a power back-up system = depending on=20 the System Application.
The system also receives a "Power ON = Reset". This=20 is excellent as far as the FPGA I am using - this resets all = of
the FF's in the device.  =
 
I also use a centralized Hard Disk(s) = File - one=20 for the entire system.  The Peripheral Processor monitors Disk=20 useage
to flag when to add an additional=20 Drive.
 
I hope this answers your question = satisfactorily.=20 If not -
do it again.
 
Dick Hartney
------=_NextPart_000_000B_01C1CC20.19E2D380-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Mar 16 02:02:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mJfw-0007OI-01 for ; Sat, 16 Mar 2002 20:17:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Mar 2002 20:17:08 +0100 (CET) Received: (qmail 6275 invoked by uid 0); 16 Mar 2002 00:57:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 16 Mar 2002 00:57:02 -0000 Received: by moria.seul.org (Postfix) id 47750146815; Fri, 15 Mar 2002 19:57:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 40FC414681A; Fri, 15 Mar 2002 19:57:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 0CEE4146815 for ; Fri, 15 Mar 2002 19:57:02 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5D4A016B7 for ; Sat, 16 Mar 2002 01:56:58 +0100 (CET) Message-ID: <3C9299B6.81F19CC6@f-cpu.org> Date: Sat, 16 Mar 2002 02:02:46 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Erin64 Boot-Load Process References: <000801c1cc2d$d778d720$1f0bd7d1@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, thank you for your description. One must however point that Erin64 is pretty different >from F-CPU because - Erin uses a pre-defined software with a specific task and goal (F-CPU is a "general purpose CPU") - Erin does not handle memory the same way (F-CPU uses virtual memory, user and superuser attributes, ...) so the comparison is not straight-forward. This is why your description seems unclear in certain parts, at least to me. > richard hartny wrote: > The Erin64 has a very simple process using "Flash Memory" as follows: > > 1. Issue Global Reset that is : an electric signal (as opposed to "signals" in UNIX jargon) > 2. Clear Program & Local Memory, Language Processor > and Peripheral Processor i understand that RESET can flush the program counter, for example, but there is usually no "clear memory" signal in the RAM chips. Does that mean that there's a software routine that flushes memory ? This also means that the instruction decoding has already started, unless you have a specific state machine for this task. > 3 Write Program & Local Memory, both processors write with what ? copy from the Flash ? > 4. Initialize Character Generators with a SW routine ? > 5. Issue "RUN" to both Processors what is this "issue" mechanism ? Is it HW or SW ? > 6. Both Processors commence an "Initialize Routine" > starting at address Zero. Upon completion both > Processors execute a HLT Instruction with Interrupts > Enabled. The Processors have nothing to process > untill a USER at a one of 128 Terminals makes either > a Keyboard entry or a Mouse Click selection. Or if an > Inter-system Interrupt (ISI) request comes via the > Expansion Port to the Peripheral Processor for a > Hard Disk operation. > > For what it's worth best regards, > Dick Hartney WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Mar 16 04:09:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mJfx-0007OI-00 for ; Sat, 16 Mar 2002 20:17:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 16 Mar 2002 20:17:09 +0100 (CET) Received: (qmail 1401 invoked by uid 0); 16 Mar 2002 03:04:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 16 Mar 2002 03:04:55 -0000 Received: by moria.seul.org (Postfix) id 8F70114681A; Fri, 15 Mar 2002 22:04:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6004614681E; Fri, 15 Mar 2002 22:04:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf28bis.bellsouth.net (mail028.mail.bellsouth.net [205.152.58.68]) by moria.seul.org (Postfix) with ESMTP id 9ECF014681A for ; Fri, 15 Mar 2002 22:04:52 -0500 (EST) Received: from computer ([209.214.154.40]) by imf28bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020316030607.VHLS9692.imf28bis.bellsouth.net@computer>; Fri, 15 Mar 2002 22:06:07 -0500 Message-ID: <000a01c1cc97$efe254c0$289ad6d1@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin64 Boot-Load Process Date: Fri, 15 Mar 2002 21:09:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1CC65.A37372E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1CC65.A37372E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To Yann Guidon's questions. The Power ON Reset clears all all functions in the SSRAM. The "Boot Processor" clears the Instruction Memory and Local Memory = (Write Zero's) There is NO Software routine. There is no SOFTWARE to = perform this Function. The Instruction Decoding has NOT started untill = a "RUN" is issued to both Processors; an Instruction of zero's is a = NOP(No Operation) The Erin36 processor performs the Boot Process. I guess you could = call it a State Machine. It accumilates one byte at a time (8 Bytes) = >from Flash Memory then performs a Write to wherever; then accumulates = another 8 Bytes The Character Generator is loaded from Flash in same manner as = Instruction and Operand Memory (Local Memory). The issuing of the "RUN" is a simple function in Hardware. Once = the Instruction/Operand load is complete a (counter) the Run FF in the Boot Processor is set. The Erin64 IS a General Purpose CPU; TIPS is my operating system. = The F-CPU will require an Operating System also. I am not trying to compare the F-CPU with the ERIN64; = however; I have a user slot for each Terminal. I am not familar with virtual memoy; however I can Directly Address the entire memory with 18 Bits Source and Destination addresses More questions?????? Dick Hartney ------=_NextPart_000_0007_01C1CC65.A37372E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To Yann Guidon's = questions.
 
The Power ON Reset clears all all = functions in the=20 SSRAM.
The "Boot Processor" clears the = Instruction Memory=20 and Local Memory (Write Zero's) There is NO Software routine.  = There is no=20 SOFTWARE to perform this Function.  The Instruction Decoding has = NOT=20 started untill a "RUN" is issued to = both=20 Processors; an Instruction of zero's is a NOP(No Operation)
    The Erin36 processor = performs=20 the Boot Process.  I guess you could call it a State Machine. = It=20 accumilates one byte at a time (8 Bytes) from Flash Memory then = performs a=20 Write to wherever; then accumulates another 8 Bytes
    The Character = Generator is=20 loaded from Flash in same manner as Instruction and Operand Memory = (Local=20 Memory).
    The issuing of the = "RUN" =20 is a simple function in = Hardware.  Once the=20 Instruction/Operand load is complete
a (counter) the Run FF in the Boot = Processor is=20 set.
    The Erin64 IS a = General Purpose=20 CPU; TIPS is my operating system.  The F-CPU will require an=20 Operating
System also.  I am not trying to = compare the=20 F-CPU with the ERIN64; however; I have a user slot for each=20 Terminal.
I am not familar with virtual memoy; = however I can=20 Directly
Address the entire memory with 18 Bits = Source and=20 Destination addresses
 
More questions??????
Dick Hartney
------=_NextPart_000_0007_01C1CC65.A37372E0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Sat Mar 16 21:29:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftb-0006g4-00 for ; Sun, 17 Mar 2002 20:00:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:43 +0100 (CET) Received: (qmail 31067 invoked by uid 0); 16 Mar 2002 20:21:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 16 Mar 2002 20:21:34 -0000 Received: by moria.seul.org (Postfix) id 884DD146820; Sat, 16 Mar 2002 15:21:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6BC34146807; Sat, 16 Mar 2002 15:21:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 1488E1467F6; Sat, 16 Mar 2002 15:21:31 -0500 (EST) Received: from seul.org (vlt6-238.n.club-internet.fr [194.158.119.238]) by relay-4v.club-internet.fr (Postfix) with ESMTP id A1BC416CB; Sat, 16 Mar 2002 21:21:26 +0100 (CET) Message-ID: <3C93AB3E.4DFA65BA@seul.org> Date: Sat, 16 Mar 2002 21:29:50 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr a écrit : > > hi, > > Cedric BAIL wrote : > >I didn't agry with your vision of a bios that his really like a PC BIOS. > i think you are a bit mistaken. What i want to do (others can still > do their own thing) is a minimalistic "monitor" that provides some > utlra-basic functions and then hands the rest of the device-specific > management to other modules. So it isn't a "boot code". It's a monitor that you want to use to debug the fcpu. > > The "usual" romfs is a very simple protocol that is explained at > http://www.linuxhq.com/kernel/v2.2/doc/filesystems/romfs.txt.html > for example. i want to do something silimar which can be easily > programmed in asm and simulated in VHDL environment. > > >But first what are the possibility for a boot process actually : > > - Stupid BIOS, who is only doing the initialisation of the needed > >peripheric and give the hand to the first code on the specified disk (it could > >be a cdrom, or whatever you wan't, but local). > There is a problem here : we don't have any HW, I/O or any protocol yet. > How can you program a BIOS if there is no IO ? > Yhe idea is to keep things minimal. Mapped io are good for this, it used fixed adresse. You just need to write the good number inside a generic boot manager. Minimal things are just "copy" program from somewhere (RS232 line, HD, ...) to the main memory and then execute it, that's all. To begin, we could also used jtag to program memory at the adress 0. nicO <...> > when can we meet soon ? > > >A+ > > Cedric > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Sat Mar 16 21:29:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftb-0006g4-01 for ; Sun, 17 Mar 2002 20:00:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:43 +0100 (CET) Received: (qmail 8417 invoked by uid 0); 16 Mar 2002 20:21:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 16 Mar 2002 20:21:39 -0000 Received: by moria.seul.org (Postfix) id B9718146814; Sat, 16 Mar 2002 15:21:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B66E2146807; Sat, 16 Mar 2002 15:21:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2A1EC1467F6; Sat, 16 Mar 2002 15:21:38 -0500 (EST) Received: from seul.org (vlt6-238.n.club-internet.fr [194.158.119.238]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 06BF4172B; Sat, 16 Mar 2002 21:21:34 +0100 (CET) Message-ID: <3C93AB45.5E83EC24@seul.org> Date: Sat, 16 Mar 2002 21:29:57 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N All this kind of thing are really to simillar to the x86 ! Todays, boot rom does one thing : jump to the good piece of code. It must be really small. When need juste something to boot from somewhere and that's all ! Driver and stuff like that are in memory with the kernel. Yann Guidon a écrit : > > here are some more thoughts and contextual stuff. > it's preliminary and moving, there's no code yet. > > however i think it is a good answer to the people > who want a "BIOS" for F-CPU. First it is impossible > to do that on a platform where there is only a CPU > and then i understand that in the past years, the > PC BIOSes have increased in complexity to a point > where it's unmanageable. Having a small boot routine > with a romfs-like support is a cool solution. > > i have to sleep now, after i read the comments that > i just got. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ------------------------------------------------------------------------ > f-romfs.txt > created mer mar 13 03:30:43 GMT 2002 by whygee@f-cpu.org > > A discussion about a "file format", the associated algorithm > and the context of using a romfs-like system. > > -------------------------------------------------------- > > BIOS/Monitor/extensions : > > The F-CPU processor is designed to boot at address 0 > after reset. It will fetch its instructions from a > non-volatile memory or an image of this data if the > system is simulated in VHDL or C. The boot code will detect and > initialize all the fundamental devices such as the memory > controllers. For example, the refresh rate will be tuned, > the bank size will be adjusted and the base address of the > private memory range will be set to an unused range > (if the system is comprised of several CPU with their own > private address ranges, but they must not overlap). > > The boot memory also contains very low-level and primitive > routines for doing basic stuff, such as sending error > messages (to a virtual console that is mapped somewhere > in the CPU, probably the SR). When done, we have to Yet an other way to get out of the cpu : beark !!! there only the vci/wishbone/amba interface connected to the outside world nothing else or it will be a lot of pain in the as ! > initialise a lot of other things which are independent > from the F-CPU project and we don't have the means > to work on the HDD controller, the keyboard driver, > the video framebuffer... You'll understand that we don't > want to mess with it, a single CPU is already complex enough. > > We would like to let the user configure his system > and install only the necessary drivers, or customize it with > his driver for his prototype peripheral, etc. > But we don't have access to a file system because > the HDD is not yet setup ! this would bloat the code > or make it too complex. OTOH we would like to let the > user interact with the HW. > > The solution is to use something that looks like > romfs : we have access to user-provided data and > code modules and we have to provide a few functions > that allow the modules to interact in a read-only way : > - locate : return the physical address of the requested block > - open : returns a handle to the specified block > - close : close handle > - read : get a word > - seek : goto a specified offset in the "file" > - exec : specify a file and run it > > since the additional modules are meant to > provide development or debug tools, it is useful > to use "directories" and "symbolic links". > This is done with the help of "flags", just like > a normal FS. we can add other flags : executable > (so a user won't attempt to execute raw data), > and compressed (in case we have some room for > the decompression tables and code, when the > Flash will be completely filled with tux > pictures etc...) > > The Flash image will be built with a simple > $ cp bareboot.bin newimage.bin > $ cat modules.romfs >> newimage.bin > $ installflash newimage.bin > (science fictious) > > The bareboot.bin file is built from an assembly > langage source containing : > - the startup code > - RAM initialisation code > - the minimum libraries : decompression, romfs utilities > and some additional stuff as needed > > The modules in modules.romfs are built from > an utility (kind of mkromfs) with a set of specified > files which are also assembled, using symbols extracted > from the startup/library code. The modules' code must > be position-independently coded because when executed, > the code (which can be decompacted) will be copied > and aligned in private/fast memory. > > When all the minimal setup is performed (RAM and IRQ, > for example) then the boot code uses the romfs functions > to access the romfs part of the Flash, seeking a "startup" > binary which will then initialise the rest, using > internal scripts or facilities that the user can customize > at will. The file could be named "runfirst" for example. > If no romfs is found (starting at the end > of the boot block) or if the startup file is absent, > the CPU sends an error code to the virtual console > and enters an infinite loop or in shutdown state. > > Granularity : F-CPU is a byte-addressing machine > but the architecture does not like unaligned instructions > or data access. > * Concerning the instructions, the code > blocks should be copied to the main memory and > the starting address must be aligned to the 256 > bit boundary imposed by the cache lines. In fact, > code that is optimized for F-CPU aligns loop entries > to 32 byte boundaries and it would not be wise > to break this. Furthermore, the Flash memory is > a rather slow device and is likely to be uncacheable ??? Why put it uncacheable ? > (though its contents doesn't change, but you get > the idea...). The SDRAM memory has much more bandwidth ??? It depend on the memory (for reading not writing of course) For me, all of the following are much too early. This is system designer problem not ours. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Sat Mar 16 21:30:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftc-0006g4-00 for ; Sun, 17 Mar 2002 20:00:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:44 +0100 (CET) Received: (qmail 26146 invoked by uid 0); 16 Mar 2002 20:22:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 16 Mar 2002 20:22:11 -0000 Received: by moria.seul.org (Postfix) id 642D7146823; Sat, 16 Mar 2002 15:22:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 61324146807; Sat, 16 Mar 2002 15:22:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 0BD561467F6; Sat, 16 Mar 2002 15:22:10 -0500 (EST) Received: from seul.org (vlt6-238.n.club-internet.fr [194.158.119.238]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C6D3616BB; Sat, 16 Mar 2002 21:22:07 +0100 (CET) Message-ID: <3C93AB66.3379EA1@seul.org> Date: Sat, 16 Mar 2002 21:30:30 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, I'm back from vacation ! Yann Guidon a écrit : > > hi ! > > nico wrote: <...> > > Nop, absolutely necessary to handel very easly synchronous problem. > > Christophe convince me, if he could resend it's URl about the paper that > > speak about. > > Such technic, in the common case, where there is no collision the only > > lose is this CAS2 instruction, there is no OS call overhead, no task > > switch, nothing. Only 4 atomic transactions ! We must have that ! > > i agree that CAS-like operations are interesting, no doubt about that. > However, what you propose is uglier than what i heard before, and > you know that we have discussed a lot ;-) > > * first, there must be an instruction that supports this kind of > transaction. there is none and this instrruction would block the pipeline. > you couldn't for example "pipeline" the CASes. > That's not a problem ! Most of the other technique are much more costly (call to the os, trap,...) > * second, probably no device would support this operation. I don't know > how you would like to implement that but F-CPU is not alone in the system > (otherwise there would be no use for an I/O bus :-D) and the other elements > must support the same protocol. If there is only one memory block, ok, > but if other CPUs of a different sort are present, there might be risks. > If the arbitrer of the bus does it's not a problem any more ! It's it that grant the devices. > * third, and more difficult for me (because i'm one of the people who code), > your feature requires a more complex state machine than needed. Generally > such a complex thing is not used 99.95% of the time, so i think it's an > overhead on my shoulders, unless you want to do it. > ?? it's only a 4 straits state machine, you're scheduler will be much more paintfull ! > > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > > > example to avoid cache trashing. > > > what do you mean by "things to manage cache L2" ? what things ? > > > > For example, caching or no caching data (imagine the FCPu as the core of > > the Geoforce 8, rendered image didn't need to be cached). > there's a flag in the Load and Store instructions which specify if the > data is to be cached. > Grrr! I speak about the bus that connect device internally. I know there is such flag. But there is no interreset if ouer internal bus does handel it to informe the DRAM controler. > > To extend that, i would try to apply distributed memory in some control logic to > > make invalidate some cache line... > > if we work with private and public memory spaces, there is no invalidation > logic required. > ????? I think you miss completly one thing. Invalidate is one of 4 technics but none of one of them are superior to the other it depend much on the application. > > > see you soon, > > Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! > send me a postcard ;-) > > if you go in vacations, take some time to write a white paper about how to > use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make > that for the VCI interface. Some VHDL code would be nice, too. > Too late! nicO > > nicO > > > > nicO > > > WHYGEE > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Mar 16 21:39:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftd-0006g4-00 for ; Sun, 17 Mar 2002 20:00:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:45 +0100 (CET) Received: (qmail 19238 invoked by uid 0); 16 Mar 2002 21:17:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 16 Mar 2002 21:17:00 -0000 Received: by moria.seul.org (Postfix) id 532C81467FE; Sat, 16 Mar 2002 16:16:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4E877146828; Sat, 16 Mar 2002 16:16:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 28FAD1467FE for ; Sat, 16 Mar 2002 16:16:59 -0500 (EST) Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by bettik.munge.net (Postfix) with ESMTP id 5CCA34F75F for ; Sat, 16 Mar 2002 14:42:47 -0600 (CST) Received: from jetnet.ab.ca (gc-jet-221.jetnet.ab.ca [207.34.60.221]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id NAA22369 for ; Sat, 16 Mar 2002 13:42:06 -0700 (MST) Message-ID: <3C93AD9F.4CF3CF34@jetnet.ab.ca> Date: Sat, 16 Mar 2002 13:39:59 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <3C93AB45.5E83EC24@seul.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nico wrote: > For me, all of the following are much too early. This is system designer > problem not ours. But what about the F-CPU chip set with all the bla-bla-bla features.:) If the F-cpu was a Microcoded machine I would favor a built in serial diagnostic console built in like on some versions of the PDP-11. If the prototype FPGA version of the F-CPU uses a small cpu for loading the configuration it could also handle bootstrapping the system or at least flashing the PROMS. Alot can be done off the printer port too. Just remember Keep It Simple. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 03:14:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftg-0006g4-01 for ; Sun, 17 Mar 2002 20:00:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:48 +0100 (CET) Received: (qmail 27607 invoked by uid 0); 17 Mar 2002 02:09:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 17 Mar 2002 02:09:12 -0000 Received: by moria.seul.org (Postfix) id 8191B146833; Sat, 16 Mar 2002 21:09:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 72B63146849; Sat, 16 Mar 2002 21:09:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id EE1EC146833 for ; Sat, 16 Mar 2002 21:09:09 -0500 (EST) Received: from f-cpu.org (kdl11-31.n.club-internet.fr [213.44.9.31]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 30EF516B9 for ; Sun, 17 Mar 2002 03:09:06 +0100 (CET) Message-ID: <3C93FC20.643FDD74@f-cpu.org> Date: Sun, 17 Mar 2002 03:14:56 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nico wrote: > hi, > I'm back from vacation ! oh yeah ! :-) let's got back to the synchro primitives :-) And remember that i still don't agree with using the memory address space for doing that... > Yann Guidon a écrit : > > > > hi ! > > > > nico wrote: > <...> > > > Nop, absolutely necessary to handel very easly synchronous problem. > > > Christophe convince me, if he could resend it's URl about the paper that > > > speak about. > > > Such technic, in the common case, where there is no collision the only > > > lose is this CAS2 instruction, there is no OS call overhead, no task > > > switch, nothing. Only 4 atomic transactions ! We must have that ! > > > > i agree that CAS-like operations are interesting, no doubt about that. > > However, what you propose is uglier than what i heard before, and > > you know that we have discussed a lot ;-) > > > > * first, there must be an instruction that supports this kind of > > transaction. there is none and this instrruction would block the pipeline. > > you couldn't for example "pipeline" the CASes. > > That's not a problem ! excuse me ? if you can't pipeline an instruction, there is no reason for using a "RISC" architecture and the scalability is compromised. Do not imagine that a computer with 2048 CPU is science fiction, the largest computers have around 10K CPU i remember. Communication and synchronisation grow _at_best_ as the log of the number of CPU, so if you can't sustain several simultaneously ongoing synchs, your mega computer will spend its life waiting for "semaphores" or other signals. pipelining the synchro primitives is a way to enhance the communications inside the system. This way, a CPU can send a synchro request to N other CPU, then request the answer from all CPUs. An external memory reference uses tens of cycles so you understand that if you request the answer immediately, the CPU will stall during tens of cycles. thank you. > Most of the other technique are much more costly > (call to the os, trap,...) costly in what ? It's always a matter of "HW/SW Interface" (cf P&H's book) if it's not done in HW, it's in SW (and vice versa), so we're always moving the cost around, here and there... > > * second, probably no device would support this operation. I don't know > > how you would like to implement that but F-CPU is not alone in the system > > (otherwise there would be no use for an I/O bus :-D) and the other elements > > must support the same protocol. If there is only one memory block, ok, > > but if other CPUs of a different sort are present, there might be risks. > > If the arbitrer of the bus does it's not a problem any more ! It's it > that grant the devices. who speaks about a "bus" ? i speak about a "system", whether "on a chip" or not. The interconnexion between the different (active and passive) elements of the system might have any topology and use heterogeneous protocols which won't all comply to our little specification. And sorry, when i wrote "(otherwise there would be no use for an I/O bus :-D)" i meant "I/O interface". my apologies. > > * third, and more difficult for me (because i'm one of the people who code), > > your feature requires a more complex state machine than needed. Generally > > such a complex thing is not used 99.95% of the time, so i think it's an > > overhead on my shoulders, unless you want to do it. > > ?? it's only a 4 straits state machine, you're scheduler will be much > more paintfull ! i wouldn't describe the design of the scheduler as a "state machine", even though there are always people who think about everything as state machines. It's not about theory : the scheduler works with a very simple principle (despite its complex implementation) : "if all the necessary ressources are available, then issue the instruction". The "state" is not "inside" a monolithic state machine like people usually see. In fact, a stateless machine is just a boolean operation, even if the result is memorised by pipeline latches. it can be interrupted without problem because there is no "single state" but a more complex cooperation. However, putting Compare And Swap as an instruction creates a wholy CISC situation. What you describe is a pure RISC vs CISC problem. !!!!!!!!!!!!!!!!!! I propose to create a device, looking like a RAM module that is plugged in the system and acts as a "mailbox". This way, using the already existing instructions (load and store), and a simple mechanism inside the "mailbox", the "CAS" operation is performed by the external device and NOT by the CPUs. With a single access port, one can ensure that all accesses are serialised and coherency is thus ensured. I still don't like this idea because it uses the general memory addressing space for doing things that don't work with cache line granularity (-> waste of bandwidth) but i hope that this compromise will help keep the F-CPU simple and working. At least, this solution does not create artificial limits on the CPI and operating frequency. !!!!!!!!!!!!!!!!!! > > > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > > > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > > > > example to avoid cache trashing. > > > > what do you mean by "things to manage cache L2" ? what things ? > > > > > > For example, caching or no caching data (imagine the FCPu as the core of > > > the Geoforce 8, rendered image didn't need to be cached). > > there's a flag in the Load and Store instructions which specify if the > > data is to be cached. > > Grrr! I speak about the bus that connect device internally. I know there > is such flag. But there is no interreset if ouer internal bus does > handel it to informe the DRAM controler. maybe things are not clear. I thought that this need was already addressed anyway. > > > To extend that, i would try to apply distributed memory in some control logic to > > > make invalidate some cache line... > > > > if we work with private and public memory spaces, there is no invalidation > > logic required. > > ????? I think you miss completly one thing. Invalidate is one of 4 > technics but none of one of them are superior to the other it depend > much on the application. why can't we keep it simple in the beginning ? If we continuously add features here and there, because a paper you read says it wins 1%, F-CPU will always remain vaporware. Unless you have some hidden code somewhere. I try to write code now, and i hope you understand that i can't answer to all questions and trolls (though i don't dislike it). Without code, all our blabla is lost time. Some people have alread written code, i hope to see yours one day. really. > > > > see you soon, > > > Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! > > send me a postcard ;-) > > > > if you go in vacations, take some time to write a white paper about how to > > use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make > > that for the VCI interface. Some VHDL code would be nice, too. > > Too late! no code, no glory ;-P > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 03:27:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mfti-0006g4-00 for ; Sun, 17 Mar 2002 20:00:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:50 +0100 (CET) Received: (qmail 11162 invoked by uid 0); 17 Mar 2002 02:22:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 17 Mar 2002 02:22:11 -0000 Received: by moria.seul.org (Postfix) id 2A503146844; Sat, 16 Mar 2002 21:22:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2600D14684D; Sat, 16 Mar 2002 21:22:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B4899146844 for ; Sat, 16 Mar 2002 21:22:09 -0500 (EST) Received: from f-cpu.org (kdl11-5.n.club-internet.fr [213.44.9.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 32AEB16A0 for ; Sun, 17 Mar 2002 03:22:07 +0100 (CET) Message-ID: <3C93FF2E.4318AC17@f-cpu.org> Date: Sun, 17 Mar 2002 03:27:58 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <3C93AB45.5E83EC24@seul.org> <3C93AD9F.4CF3CF34@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Ben Franchuk wrote: > nico wrote: > > For me, all of the following are much too early. This is system designer > > problem not ours. > But what about the F-CPU chip set with all the bla-bla-bla features.:) come on ;-) i think that you remember that the goal of f-cpu is not to design a whole "chipset" and there are already existing suitable designs (even without PCI ;-D) Those who desire certain features can go to the "OpenCores supermarket" and hack the code to connect it to F-CPU. > If the F-cpu was a Microcoded machine I would favor a built in serial > diagnostic console built in like on some versions of the PDP-11. mmmm.... no :-) i already used a serial port on a SHARC DSP kit and it's not the most comfortable solution. It has even forced me to buy an additional serial port ISA card because both my serial ports are already used (modem+mouse). And don't want to use USB either. > If the prototype FPGA version of the F-CPU uses a small cpu for loading the > configuration it could also handle bootstrapping the system or at least > flashing the PROMS. this can be done with the Flash-resident monitor. otherwise adding yet another CPU will create problems that i won't want to resolve and that have already been addressed here... > Alot can be done off the printer port too. Just remember Keep It Simple. I can finally agree with you ;-) // LPT port rocks, and this is consistent with KISS. And there might even be a simple hack that allows the core to boot directly off the LPT port with a simple - press reset button (or activate the RESET with a LPT wire) - type "$ cat boot.img > /dev/lpt" and that's all (no funky protocol, no host software, no ...) U like it ? :-) > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE (64+ bit CPUs) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 03:28:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mfti-0006g4-01 for ; Sun, 17 Mar 2002 20:00:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:50 +0100 (CET) Received: (qmail 5673 invoked by uid 0); 17 Mar 2002 02:22:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 17 Mar 2002 02:22:20 -0000 Received: by moria.seul.org (Postfix) id 27167146849; Sat, 16 Mar 2002 21:22:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0130214684E; Sat, 16 Mar 2002 21:22:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 95F52146849 for ; Sat, 16 Mar 2002 21:22:19 -0500 (EST) Received: from f-cpu.org (kdl11-5.n.club-internet.fr [213.44.9.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id BCD4216E7 for ; Sun, 17 Mar 2002 03:22:16 +0100 (CET) Message-ID: <3C93FF38.8C214119@f-cpu.org> Date: Sun, 17 Mar 2002 03:28:08 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <3C93AB45.5E83EC24@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! nico wrote: > All this kind of thing are really to simillar to the x86 ! why are people so x86-centric ? there are other CPUs on Earth. Even DSP and microcontrollers, whatever. All computing machines don't have the exact same operating mechanisms. > Todays, boot rom does one thing : jump to the good piece of code. sorry, when was the last time you read the Ralph Brown Interrupt List ? :-) > It must be really small. When need juste something to boot from somewhere > and that's all ! it's a bit more complex than that... Simply because PCs have generally documented I/O and memory addresses for most devices. So ANY software can hit a specific hardcoded location and do its stuff. F-CPU has 3 things : - Flash starts at address 0 - there is the SR address range where authorised code can read / write configuration words - there is a private SDRAM range that is defined in the SR space. that's all and there is no way to know where to send data to/from I/O. Unless we define a SR-mapped I/O channel. > Driver and stuff like that are in memory with the kernel. I hope that we can get a sufficiently large EEPROM space. Linux Magazine France (february issue) shows a uClinux implementation with a EEPROM of 2MB (16Mb). > Yann Guidon a écrit : > > The boot memory also contains very low-level and primitive > > routines for doing basic stuff, such as sending error > > messages (to a virtual console that is mapped somewhere > > in the CPU, probably the SR). When done, we have to > > Yet an other way to get out of the cpu : beark !!! there only the > vci/wishbone/amba interface connected to the outside world nothing else > or it will be a lot of pain in the as ! why ? Don't forget that during VHDL simulations, we have to debug both the CPU and the boot code. We need a simple and safe interface that will not change (from the SW point of view) when FC0 is implemented. In HW, the SR can be wired to zero. But in SW, the SR will be interpreted as a message to the user. And what if there is no I/O in the system, for example when developping the CPU alone ? > > Granularity : F-CPU is a byte-addressing machine > > but the architecture does not like unaligned instructions > > or data access. > > * Concerning the instructions, the code > > blocks should be copied to the main memory and > > the starting address must be aligned to the 256 > > bit boundary imposed by the cache lines. In fact, > > code that is optimized for F-CPU aligns loop entries > > to 32 byte boundaries and it would not be wise > > to break this. Furthermore, the Flash memory is > > a rather slow device and is likely to be uncacheable > > ??? Why put it uncacheable ? simply because the FLASH is likely to reside outside the private addressing range. this means that all memory references are uncachable. Trying to make exceptions to this rule of thumb will certainly make the system more complex and slower to design. but there's not much "loss" because EEPROM latency is often around 100ns (?) and the data are not very wide, the bandwidth is largely below the CPU's working point. > > (though its contents doesn't change, but you get > > the idea...). The SDRAM memory has much more bandwidth > ??? It depend on the memory (for reading not writing of course) sorry, but 16 bits with even the optimistic 50ns latency can't be compared to 64 bits with a 10ns burst cycle (pessimistic). there's at least a 20x bandwidth difference. Unless you are ready to pay specifc and expensive devices for your own purpose. > For me, all of the following are much too early. This is system designer > problem not ours. Not exactly : the "BIOS problem" comes back often. We have to find a solution that allows anybody to start hacking, without creating new problems or diverting us from our core project (CPU design, not BIOS or kernel design). now, i have to finish debugging some code, good night everybody. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Mar 17 06:00:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftk-0006g4-00 for ; Sun, 17 Mar 2002 20:00:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:52 +0100 (CET) Received: (qmail 6935 invoked by uid 0); 17 Mar 2002 05:02:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 17 Mar 2002 05:02:46 -0000 Received: by moria.seul.org (Postfix) id BEA7114684E; Sun, 17 Mar 2002 00:02:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B726D146859; Sun, 17 Mar 2002 00:02:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 8CFD014684E for ; Sun, 17 Mar 2002 00:02:43 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-210.jetnet.ab.ca [207.34.60.210]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id WAA13360 for ; Sat, 16 Mar 2002 22:02:41 -0700 (MST) Message-ID: <3C9422F0.47E9DF7C@jetnet.ab.ca> Date: Sat, 16 Mar 2002 22:00:32 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <3C93AB45.5E83EC24@seul.org> <3C93AD9F.4CF3CF34@jetnet.ab.ca> <3C93FF2E.4318AC17@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > i think that you remember that the goal of f-cpu is not to design a whole > "chipset" and there are already existing suitable designs (even without PCI ;-D) > Those who desire certain features can go to the "OpenCores supermarket" > and hack the code to connect it to F-CPU. The Fcpu chip set was made in jest. How ever it does look like a chip set is playing a bigger part in computer system design than a few years ago. > i already used a serial port on a SHARC DSP kit and it's not the most comfortable > solution. It has even forced me to buy an additional serial port ISA card > because both my serial ports are already used (modem+mouse). And don't want > to use USB either. I needed a second card for a printer port to run the FPGA software for my prototype board. > > If the prototype FPGA version of the F-CPU uses a small cpu for loading the > > configuration it could also handle bootstrapping the system or at least > > flashing the PROMS. > > Alot can be done off the printer port too. Just remember Keep It Simple. > I can finally agree with you ;-) > // LPT port rocks, and this is consistent with KISS. > and that's all (no funky protocol, no host software, no ...) > U like it ? :-) One option might be read in 1024 bytes from a 8 bit bootstrap port after reset to memory and jump to 0. If the interface is kept simple almost any thing could drive the port,printer, prom, hard disk , network. Speed is not a problem because you write to fast memory from a slow i/o device. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sun Mar 17 11:07:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftl-0006g4-00 for ; Sun, 17 Mar 2002 20:00:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:53 +0100 (CET) Received: (qmail 16100 invoked by uid 0); 17 Mar 2002 10:04:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 17 Mar 2002 10:04:45 -0000 Received: by moria.seul.org (Postfix) id 20693146850; Sun, 17 Mar 2002 05:04:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0012B146865; Sun, 17 Mar 2002 05:04:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 21CD0146850 for ; Sun, 17 Mar 2002 05:04:39 -0500 (EST) Received: from art1.none.de ([62.144.184.6]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g2HA4dm20388 for ; Sun, 17 Mar 2002 11:04:40 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.184.6] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16mXZD-0007qA-00 for ; Sun, 17 Mar 2002 11:07:07 +0100 Date: Sun, 17 Mar 2002 11:07:06 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs In-Reply-To: <3C93FF38.8C214119@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, > F-CPU has 3 things : > - Flash starts at address 0 > - there is the SR address range where authorised code > can read / write configuration words > - there is a private SDRAM range that is defined in the SR space. > that's all and there is no way to know where to send data to/from I/O. > Unless we define a SR-mapped I/O channel. Par example the Motorola 68302 (communication-processor) init-process is in short: 1. set BAR (basis adress register) 2. define with base and mask the RAM/ROM/Port-areas, means the chip-selects 3. Code will be executed from CS0, means ROM at adress 0 4. define the stackpointer 5. define IRQ-tables 6. test RAM The M68302 has a internal dual-port RaM of 2K, first 500 Bytes (plusminus) are user-defined, then there were basis registers for communication with parport, risc-stuff, processor-configuration... In that way, we should have also an init, we need registers to define a chipselect for a port-memory-range to use this as an interaction with external peripherie, to define, where boot-ROM start etc. If the CPU exists in this way, there is really not a problem to test the CPU and to develop a mainboard or some other funny stuff... Or I am misunderstood something... Bye Andreas ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Sun Mar 17 12:03:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftm-0006g4-00 for ; Sun, 17 Mar 2002 20:00:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:54 +0100 (CET) Received: (qmail 21673 invoked by uid 0); 17 Mar 2002 10:54:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 17 Mar 2002 10:54:57 -0000 Received: by moria.seul.org (Postfix) id D2EE514686B; Sun, 17 Mar 2002 05:54:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCA85146868; Sun, 17 Mar 2002 05:54:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 62834146859; Sun, 17 Mar 2002 05:54:54 -0500 (EST) Received: from seul.org (vlt9-141.n.club-internet.fr [195.36.223.141]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 836F01768; Sun, 17 Mar 2002 11:54:50 +0100 (CET) Message-ID: <3C9477F5.F3A68CFF@seul.org> Date: Sun, 17 Mar 2002 12:03:17 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > nico wrote: > > hi, > > I'm back from vacation ! > > oh yeah ! :-) > let's got back to the synchro primitives :-) > > And remember that i still don't agree with using the memory > address space for doing that... > > > Yann Guidon a écrit : > > > > > > hi ! > > > > > > nico wrote: > > <...> > > > > Nop, absolutely necessary to handel very easly synchronous problem. > > > > Christophe convince me, if he could resend it's URl about the paper that > > > > speak about. > > > > Such technic, in the common case, where there is no collision the only > > > > lose is this CAS2 instruction, there is no OS call overhead, no task > > > > switch, nothing. Only 4 atomic transactions ! We must have that ! > > > > > > i agree that CAS-like operations are interesting, no doubt about that. > > > However, what you propose is uglier than what i heard before, and > > > you know that we have discussed a lot ;-) > > > > > > * first, there must be an instruction that supports this kind of > > > transaction. there is none and this instrruction would block the pipeline. > > > you couldn't for example "pipeline" the CASes. > > > > That's not a problem ! > > excuse me ? > > if you can't pipeline an instruction, there is no reason > for using a "RISC" architecture and the scalability is compromised. > Do not imagine that a computer with 2048 CPU is science fiction, > the largest computers have around 10K CPU i remember. Communication > and synchronisation grow _at_best_ as the log of the number of CPU, > so if you can't sustain several simultaneously ongoing synchs, > your mega computer will spend its life waiting for "semaphores" > or other signals. > CAS2 is the fastest synchro primitive that you can find. SR style semaphore are simply impossible. I said to Christophe to write is demonstration but he's shy in english. You want to pipiline something more than the div instruction ! But you use such instruction each time you want to update a data so very few for each processor. If tousand processor communicate with each other it's not a problem at all. A part, i don't beleive that we will refind 10k chip computer, is far too expensive and "outside" communication became far more too costly. > pipelining the synchro primitives is a way to enhance the communications > inside the system. This way, a CPU can send a synchro request to N other CPU, > then request the answer from all CPUs. An external memory reference uses > tens of cycles so you understand that if you request the answer immediately, > the CPU will stall during tens of cycles. thank you. > There isn't any answer from other cpus, never. That's just the good thing of this primitive ! > > Most of the other technique are much more costly > > (call to the os, trap,...) > > costly in what ? > It's always a matter of "HW/SW Interface" (cf P&H's book) > if it's not done in HW, it's in SW (and vice versa), so we're > always moving the cost around, here and there... > Nop ! Sorry, traping in kernel mode is much more costly than the slowest cpu instruction. > > > * second, probably no device would support this operation. I don't know > > > how you would like to implement that but F-CPU is not alone in the system > > > (otherwise there would be no use for an I/O bus :-D) and the other elements > > > must support the same protocol. If there is only one memory block, ok, > > > but if other CPUs of a different sort are present, there might be risks. > > > > If the arbitrer of the bus does it's not a problem any more ! It's it > > that grant the devices. > > who speaks about a "bus" ? i speak about a "system", whether "on a chip" or not. > The interconnexion between the different (active and passive) elements of > the system might have any topology and use heterogeneous protocols which > won't all comply to our little specification. > And sorry, when i wrote "(otherwise there would be no use for an I/O bus :-D)" > i meant "I/O interface". my apologies. > It doesn't change anything ! There is always in any case an arbitrer so if the arbitrer support CAS2, there is no problem for Fcpus connected together. A IO device doesn't have CAS2 instruction. So, they does not use it ! What's the problem ? > > > * third, and more difficult for me (because i'm one of the people who code), > > > your feature requires a more complex state machine than needed. Generally > > > such a complex thing is not used 99.95% of the time, so i think it's an > > > overhead on my shoulders, unless you want to do it. > > > > ?? it's only a 4 straits state machine, you're scheduler will be much > > more paintfull ! > > i wouldn't describe the design of the scheduler as a "state machine", > even though there are always people who think about everything as state > machines. It's not about theory : the scheduler works with a very simple > principle (despite its complex implementation) : "if all the necessary > ressources are available, then issue the instruction". The "state" is > not "inside" a monolithic state machine like people usually see. In fact, > a stateless machine is just a boolean operation, even if the result is > memorised by pipeline latches. it can be interrupted without problem > because there is no "single state" but a more complex cooperation. > > However, putting Compare And Swap as an instruction creates a wholy CISC > situation. What you describe is a pure RISC vs CISC problem. > > !!!!!!!!!!!!!!!!!! Not at all. CAS2 operation are found in powerPC for example. Because such instructions are atomic you can't compare it to a usual "CISC" operation. An other way to say that is : how do you make a difference in a ciscy instruction and a riscy one ? I'm glade to know it ! The only thing that i can see is that ciscy operation could use an arbitrary number of clock cycle. We could add that an riscy operation has a fixed size instruction word (to ease decoding) (but for code density some dsp use variable size operation 8-16-32-48 instructions with "wide decoder" so "many" instructions could be decode in the same time and code is denser ). For me that's all ! > > I propose to create a device, looking like a RAM module that is plugged > in the system and acts as a "mailbox". This way, using the already existing > instructions (load and store), and a simple mechanism inside the "mailbox", > the "CAS" operation is performed by the external device and NOT by the CPUs. > With a single access port, one can ensure that all accesses are serialised > and coherency is thus ensured. > I'm not sure it could work. > I still don't like this idea because it uses the general memory addressing space > for doing things that don't work with cache line granularity (-> waste of bandwidth) > but i hope that this compromise will help keep the F-CPU simple and working. > At least, this solution does not create artificial limits on the CPI and > operating frequency. > > !!!!!!!!!!!!!!!!!! > > > > > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > > > > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > > > > > example to avoid cache trashing. > > > > > what do you mean by "things to manage cache L2" ? what things ? > > > > > > > > For example, caching or no caching data (imagine the FCPu as the core of > > > > the Geoforce 8, rendered image didn't need to be cached). > > > there's a flag in the Load and Store instructions which specify if the > > > data is to be cached. > > > > Grrr! I speak about the bus that connect device internally. I know there > > is such flag. But there is no interreset if ouer internal bus does > > handel it to informe the DRAM controler. > > maybe things are not clear. > I thought that this need was already addressed anyway. > > > > > To extend that, i would try to apply distributed memory in some control logic to > > > > make invalidate some cache line... > > > > > > if we work with private and public memory spaces, there is no invalidation > > > logic required. > > > > ????? I think you miss completly one thing. Invalidate is one of 4 > > technics but none of one of them are superior to the other it depend > > much on the application. > > why can't we keep it simple in the beginning ? > If we continuously add features here and there, because a paper you > read says it wins 1%, F-CPU will always remain vaporware. > Unless you have some hidden code somewhere. > > I try to write code now, and i hope you understand that i can't answer > to all questions and trolls (though i don't dislike it). Without code, > all our blabla is lost time. Some people have alread written code, > i hope to see yours one day. really. > > > > > > see you soon, > > > > Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! > > > send me a postcard ;-) > > > > > > if you go in vacations, take some time to write a white paper about how to > > > use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make > > > that for the VCI interface. Some VHDL code would be nice, too. > > > > Too late! > > no code, no glory ;-P > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Sun Mar 17 12:21:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftn-0006g4-00 for ; Sun, 17 Mar 2002 20:00:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:55 +0100 (CET) Received: (qmail 10686 invoked by uid 0); 17 Mar 2002 11:13:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 17 Mar 2002 11:13:19 -0000 Received: by moria.seul.org (Postfix) id 6A9BD146865; Sun, 17 Mar 2002 06:13:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6244E146868; Sun, 17 Mar 2002 06:13:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id EA30E146859; Sun, 17 Mar 2002 06:13:16 -0500 (EST) Received: from seul.org (vlt9-141.n.club-internet.fr [195.36.223.141]) by relay-2v.club-internet.fr (Postfix) with ESMTP id F1D4316F1; Sun, 17 Mar 2002 12:13:13 +0100 (CET) Message-ID: <3C947C44.EFC9E708@seul.org> Date: Sun, 17 Mar 2002 12:21:40 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C8ED029.D4B4BDAA@f-cpu.org> <3C93AB45.5E83EC24@seul.org> <3C93FF38.8C214119@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello ! > > nico wrote: > > All this kind of thing are really to simillar to the x86 ! > > why are people so x86-centric ? The critisicsm was not about people but about you whygee. > there are other CPUs on Earth. Even DSP and microcontrollers, > whatever. All computing machines don't have the exact same > operating mechanisms. > > > Todays, boot rom does one thing : jump to the good piece of code. > sorry, when was the last time you read the Ralph Brown Interrupt List ? :-) > Never ! But don't forget that my work (the real one) is to develop "calculateur" which are basicaly computers, that's how it's work. > > It must be really small. When need juste something to boot from somewhere > > and that's all ! > > it's a bit more complex than that... Simply because PCs have generally > documented I/O and memory addresses for most devices. So ANY software > can hit a specific hardcoded location and do its stuff. > Software are written for a specific system. you can use general code but you parameterise it. > F-CPU has 3 things : > - Flash starts at address 0 > - there is the SR address range where authorised code > can read / write configuration words ??? configuration word in SR. Come on ! stop with SR it's not a magic word. Use memory maped things, it's simple and easy to use (and it soon work !). > - there is a private SDRAM range that is defined in the SR space. It's define at the TLB level. > that's all and there is no way to know where to send data to/from I/O. > Unless we define a SR-mapped I/O channel. STOP SR ! Such general piece of SW never existe ! Build a computer is far more than a cpu. Changing the cpu is maybe the easiest thing to do ! You just have to change the compiler ! But all other things are much harder to change (interrupt system, io system (HD,serial,PCI,...)). From the software point of view, it's simply fixed adress in adress space. This kind of fixed adress and the cpu defined the computer. > > > Driver and stuff like that are in memory with the kernel. > I hope that we can get a sufficiently large EEPROM space. > Linux Magazine France (february issue) shows a uClinux > implementation with a EEPROM of 2MB (16Mb). > I really never mind. We are far from a prototype. I have seen how it's hard to port µcLinux to Leon, so we are far from a linuxbox with linux ! > > Yann Guidon a écrit : > > > The boot memory also contains very low-level and primitive > > > routines for doing basic stuff, such as sending error > > > messages (to a virtual console that is mapped somewhere > > > in the CPU, probably the SR). When done, we have to > > > > Yet an other way to get out of the cpu : beark !!! there only the > > vci/wishbone/amba interface connected to the outside world nothing else > > or it will be a lot of pain in the as ! > > why ? Because ! It's not clean ! Nobody do that for interconnections properties. And simply, because we do not need it ! > Don't forget that during VHDL simulations, we have to debug > both the CPU and the boot code. We need a simple and safe > interface that will not change (from the SW point of view) > when FC0 is implemented. In HW, the SR can be wired to zero. > But in SW, the SR will be interpreted as a message to the user. > We don't need that at all ! You can simpli add none syntetisable variable inside you're design to check how it's work. No need to put that in SR. > And what if there is no I/O in the system, for example when > developping the CPU alone ? > ;p So you can't interract with it ? So you can't see if it work or not ;p If you doing so it's the job of JTAG or specific debug feature control by jtag (as for PowerPC). > > > Granularity : F-CPU is a byte-addressing machine > > > but the architecture does not like unaligned instructions > > > or data access. > > > * Concerning the instructions, the code > > > blocks should be copied to the main memory and > > > the starting address must be aligned to the 256 > > > bit boundary imposed by the cache lines. In fact, > > > code that is optimized for F-CPU aligns loop entries > > > to 32 byte boundaries and it would not be wise > > > to break this. Furthermore, the Flash memory is > > > a rather slow device and is likely to be uncacheable > > > > ??? Why put it uncacheable ? > > simply because the FLASH is likely to reside outside the private > addressing range. this means that all memory references are uncachable. ??? It's not because it isn't local memory that you can't cache it !(reread my article about distributed system ;p) > Trying to make exceptions to this rule of thumb will certainly make > the system more complex and slower to design. > but there's not much "loss" because EEPROM latency is > often around 100ns (?) and the data are not very wide, > the bandwidth is largely below the CPU's working point. > > > > (though its contents doesn't change, but you get > > > the idea...). The SDRAM memory has much more bandwidth > > ??? It depend on the memory (for reading not writing of course) > > sorry, but 16 bits with even the optimistic 50ns latency can't be compared > to 64 bits with a 10ns burst cycle (pessimistic). there's at least a 20x > bandwidth difference. Unless you are ready to pay specifc and expensive > devices for your own purpose. > It depend on your EEPROM, sorry ! You're last sentence is a lapalissade ? > > For me, all of the following are much too early. This is system designer > > problem not ours. > Not exactly : the "BIOS problem" comes back often. We have to find a > solution that allows anybody to start hacking, without creating new problems > or diverting us from our core project (CPU design, not BIOS or kernel design). > > now, i have to finish debugging some code, good night everybody. > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Mar 17 13:02:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftp-0006g4-00 for ; Sun, 17 Mar 2002 20:00:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:00:57 +0100 (CET) Received: (qmail 27816 invoked by uid 0); 17 Mar 2002 13:17:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 17 Mar 2002 13:17:04 -0000 Received: by moria.seul.org (Postfix) id 99F3F146859; Sun, 17 Mar 2002 08:17:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 734381468D2; Sun, 17 Mar 2002 08:17:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 202DF146859 for ; Sun, 17 Mar 2002 08:17:02 -0500 (EST) Received: from ifurita (212.194.249.206) by mail.laposte.net (5.5.044) id 3C9102D700026A8B for f-cpu@seul.org; Sun, 17 Mar 2002 14:17:01 +0100 Message-ID: <003001c1cdab$9209c4e0$cef9c2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> Subject: Re: [f-cpu] another DATE report Date: Sun, 17 Mar 2002 13:02:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well, it's true i'm shy in english :-) More seriously, I think the issue about the time penality about using CAS and CAS2 is overstated. The solution offered by Yann to replace it with a fix array of semaphores through the SR mechanisms is an evidence that either he don't know about what we are really talking or he misunderstands the real purposes of CAS2. Yann, let me tell you that your solution is really clumsy (I will explain why). Personnaly, I think that you are too more confident about yourself - especially since you states everytime that you are the only one who code. Please, stop with that !!! you shouldn't speak that way simply because you don't want to hear about something you regard as a crap. You will exasperate too many people with such a behavior. Ok, take easy. Let us try a more constructed debate : Why I find your solution clumsy compared with the non-blocking synchro primitives : - To access SR, we have two instructions : PUT and GET. The first one is just a WRITE operation. The second one is just a READ operation. - If you are speaking about a range of SR as mutex - BLOCKING synchro primitives by the way - how do you proceed to stop a task in a processor to swith another one ? the only way I see is : GET to acquire a semaphore and PUT to release a semaphore. Checking if a task must wait can be reading the value after a GET execution. But what the heck if there is another process or a task switching between the GET instruction and the code checking if we must stop the task and this other processor or task releases a semaphore ? device-side hardware GET : atomic { r1 = sr[r2]; sr[r2] = 1; } device-side hardware PUT : atomic { sr[r2] = 0; } task A :- executes GET for mutex #1 << task switch >> task B :- executes PUT for mutex #1 : releasing mutex #1. task B :- awakes a task waiting for mutex #1 : no task in list indeed. task B :- ... << task switch >> task A :- Our early GET stated that mutex #1 is already acquired by task B, so task A must stop and go in the semaphore #1 wait list. << task switch >> task B :- ... << task switch >> task B :- ... << task switch >> task B :- ... task B :- termination of task task A will never be awaken, because no other task will release mutex #1 ! Please, as you can see it is a BLOCKING synchro-primitive which doesn't prevent us from the necessity to stop a task when demanded. So you will need to call a trap which is a very costly operation especially the way you intend to handle your traps (CMB saving)... - If you are speaking about a range of SR as semaphores, there is no way : PUT cannot tell us if we must awake a task in the semaphore list because it is a WRITE operation. Or you must have two ranges instead of one and only use GET. - fixed-range semaphores : very limitive ressource. I need a semaphore for a structure, so I must allocate a semaphore and get its SR as ID if available (oh bad ! ressource is critical !). Now I got it, I must recorder it in the structure so the latter can access it when acquiring or releasing : everytime I will do a GET or a PUT i will first access in the structure (in memory) to get the semaphore ID, so you cannot avoid the memory access indeed. I cannot figure out how to use your semaphores in a Linux for your F-CPU... So the best solution is using CAS and CAS2 when the external BUS supports something like a READ-CHECK-MODIFY transaction : - semaphores and mutexes can be done with them without the synchronisation problem I spoke above - the most elegant way to have the fastest spinlocks both in UP and SMP architecture - the memory slot for synchronisation is embedded in structure so there is no extra memory access - no range limit - cpu locking regards only for those which try to access concurrently the same memory slot. - no need for blocking synchro when using them in stack, queue, dequeu, etc. - etc. etc. etc. ----- Original Message ----- From: nico To: Sent: Sunday, March 17, 2002 12:03 PM Subject: Re: [f-cpu] another DATE report > Yann Guidon a écrit : > > > > hi ! > > > > nico wrote: > > > hi, > > > I'm back from vacation ! > > > > oh yeah ! :-) > > let's got back to the synchro primitives :-) > > > > And remember that i still don't agree with using the memory > > address space for doing that... > > > > > Yann Guidon a écrit : > > > > > > > > hi ! > > > > > > > > nico wrote: > > > <...> > > > > > Nop, absolutely necessary to handel very easly synchronous problem. > > > > > Christophe convince me, if he could resend it's URl about the paper that > > > > > speak about. > > > > > Such technic, in the common case, where there is no collision the only > > > > > lose is this CAS2 instruction, there is no OS call overhead, no task > > > > > switch, nothing. Only 4 atomic transactions ! We must have that ! > > > > > > > > i agree that CAS-like operations are interesting, no doubt about that. > > > > However, what you propose is uglier than what i heard before, and > > > > you know that we have discussed a lot ;-) > > > > > > > > * first, there must be an instruction that supports this kind of > > > > transaction. there is none and this instrruction would block the pipeline. > > > > you couldn't for example "pipeline" the CASes. > > > > > > That's not a problem ! > > > > excuse me ? > > > > if you can't pipeline an instruction, there is no reason > > for using a "RISC" architecture and the scalability is compromised. > > Do not imagine that a computer with 2048 CPU is science fiction, > > the largest computers have around 10K CPU i remember. Communication > > and synchronisation grow _at_best_ as the log of the number of CPU, > > so if you can't sustain several simultaneously ongoing synchs, > > your mega computer will spend its life waiting for "semaphores" > > or other signals. > > > > CAS2 is the fastest synchro primitive that you can find. SR style > semaphore are simply impossible. I said to Christophe to write is > demonstration but he's shy in english. > > You want to pipiline something more than the div instruction ! But you > use such instruction each time you want to update a data so very few for > each processor. If tousand processor communicate with each other it's > not a problem at all. > > A part, i don't beleive that we will refind 10k chip computer, is far > too expensive and "outside" communication became far more too costly. > > > pipelining the synchro primitives is a way to enhance the communications > > inside the system. This way, a CPU can send a synchro request to N other CPU, > > then request the answer from all CPUs. An external memory reference uses > > tens of cycles so you understand that if you request the answer immediately, > > the CPU will stall during tens of cycles. thank you. > > > > There isn't any answer from other cpus, never. That's just the good > thing of this primitive ! > > > > Most of the other technique are much more costly > > > (call to the os, trap,...) > > > > costly in what ? > > It's always a matter of "HW/SW Interface" (cf P&H's book) > > if it's not done in HW, it's in SW (and vice versa), so we're > > always moving the cost around, here and there... > > > > Nop ! Sorry, traping in kernel mode is much more costly than the slowest > cpu instruction. > > > > > * second, probably no device would support this operation. I don't know > > > > how you would like to implement that but F-CPU is not alone in the system > > > > (otherwise there would be no use for an I/O bus :-D) and the other elements > > > > must support the same protocol. If there is only one memory block, ok, > > > > but if other CPUs of a different sort are present, there might be risks. > > > > > > If the arbitrer of the bus does it's not a problem any more ! It's it > > > that grant the devices. > > > > who speaks about a "bus" ? i speak about a "system", whether "on a chip" or not. > > The interconnexion between the different (active and passive) elements of > > the system might have any topology and use heterogeneous protocols which > > won't all comply to our little specification. > > And sorry, when i wrote "(otherwise there would be no use for an I/O bus :-D)" > > i meant "I/O interface". my apologies. > > > > It doesn't change anything ! There is always in any case an arbitrer so > if the arbitrer support CAS2, there is no problem for Fcpus connected > together. A IO device doesn't have CAS2 instruction. So, they does not > use it ! What's the problem ? > > > > > * third, and more difficult for me (because i'm one of the people who code), > > > > your feature requires a more complex state machine than needed. Generally > > > > such a complex thing is not used 99.95% of the time, so i think it's an > > > > overhead on my shoulders, unless you want to do it. > > > > > > ?? it's only a 4 straits state machine, you're scheduler will be much > > > more paintfull ! > > > > i wouldn't describe the design of the scheduler as a "state machine", > > even though there are always people who think about everything as state > > machines. It's not about theory : the scheduler works with a very simple > > principle (despite its complex implementation) : "if all the necessary > > ressources are available, then issue the instruction". The "state" is > > not "inside" a monolithic state machine like people usually see. In fact, > > a stateless machine is just a boolean operation, even if the result is > > memorised by pipeline latches. it can be interrupted without problem > > because there is no "single state" but a more complex cooperation. > > > > However, putting Compare And Swap as an instruction creates a wholy CISC > > situation. What you describe is a pure RISC vs CISC problem. > > > > !!!!!!!!!!!!!!!!!! > > Not at all. CAS2 operation are found in powerPC for example. Because > such instructions are atomic you can't compare it to a usual "CISC" > operation. > > An other way to say that is : how do you make a difference in a ciscy > instruction and a riscy one ? I'm glade to know it ! The only thing that > i can see is that ciscy operation could use an arbitrary number of clock > cycle. We could add that an riscy operation has a fixed size instruction > word (to ease decoding) (but for code density some dsp use variable size > operation 8-16-32-48 instructions with "wide decoder" so "many" > instructions could be decode in the same time and code is denser ). For > me that's all ! > > > > > I propose to create a device, looking like a RAM module that is plugged > > in the system and acts as a "mailbox". This way, using the already existing > > instructions (load and store), and a simple mechanism inside the "mailbox", > > the "CAS" operation is performed by the external device and NOT by the CPUs. > > With a single access port, one can ensure that all accesses are serialised > > and coherency is thus ensured. > > > > I'm not sure it could work. > > > I still don't like this idea because it uses the general memory addressing space > > for doing things that don't work with cache line granularity (-> waste of bandwidth) > > but i hope that this compromise will help keep the F-CPU simple and working. > > At least, this solution does not create artificial limits on the CPI and > > operating frequency. > > > > !!!!!!!!!!!!!!!!!! > > > > > > > > > - maybe things to manage cache L2 (from my point of view L2 is tied to > > > > > > > the DRAM controller, the L1 is tied to the CPU). None caching access for > > > > > > > example to avoid cache trashing. > > > > > > what do you mean by "things to manage cache L2" ? what things ? > > > > > > > > > > For example, caching or no caching data (imagine the FCPu as the core of > > > > > the Geoforce 8, rendered image didn't need to be cached). > > > > there's a flag in the Load and Store instructions which specify if the > > > > data is to be cached. > > > > > > Grrr! I speak about the bus that connect device internally. I know there > > > is such flag. But there is no interreset if ouer internal bus does > > > handel it to informe the DRAM controler. > > > > maybe things are not clear. > > I thought that this need was already addressed anyway. > > > > > > > To extend that, i would try to apply distributed memory in some control logic to > > > > > make invalidate some cache line... > > > > > > > > if we work with private and public memory spaces, there is no invalidation > > > > logic required. > > > > > > ????? I think you miss completly one thing. Invalidate is one of 4 > > > technics but none of one of them are superior to the other it depend > > > much on the application. > > > > why can't we keep it simple in the beginning ? > > If we continuously add features here and there, because a paper you > > read says it wins 1%, F-CPU will always remain vaporware. > > Unless you have some hidden code somewhere. > > > > I try to write code now, and i hope you understand that i can't answer > > to all questions and trolls (though i don't dislike it). Without code, > > all our blabla is lost time. Some people have alread written code, > > i hope to see yours one day. really. > > > > > > > > see you soon, > > > > > Yep ! I leave Paris for 1 weeks. Don't blow my mail box ! > > > > send me a postcard ;-) > > > > > > > > if you go in vacations, take some time to write a white paper about how to > > > > use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make > > > > that for the VCI interface. Some VHDL code would be nice, too. > > > > > > Too late! > > > > no code, no glory ;-P > > > > > nicO > > WHYGEE > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 18:04:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mfts-0006g4-00 for ; Sun, 17 Mar 2002 20:01:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:01:00 +0100 (CET) Received: (qmail 4849 invoked by uid 0); 17 Mar 2002 16:58:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 17 Mar 2002 16:58:15 -0000 Received: by moria.seul.org (Postfix) id 6F6CA1468D5; Sun, 17 Mar 2002 11:58:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A13A1468D7; Sun, 17 Mar 2002 11:58:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 374C71468D5 for ; Sun, 17 Mar 2002 11:58:14 -0500 (EST) Received: from f-cpu.org (kdl11-18.n.club-internet.fr [213.44.9.18]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 132DE16D6 for ; Sun, 17 Mar 2002 17:58:12 +0100 (CET) Message-ID: <3C94CC84.C07DD596@f-cpu.org> Date: Sun, 17 Mar 2002 18:04:04 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Andreas Romeyke wrote: > Hello, > > > F-CPU has 3 things : > > - Flash starts at address 0 > > - there is the SR address range where authorised code > > can read / write configuration words > > - there is a private SDRAM range that is defined in the SR space. > > that's all and there is no way to know where to send data to/from I/O. > > Unless we define a SR-mapped I/O channel. > > Par example the Motorola 68302 (communication-processor) init-process is > in short: > > 1. set BAR (basis adress register) > 2. define with base and mask the RAM/ROM/Port-areas, means the > chip-selects > 3. Code will be executed from CS0, means ROM at adress 0 > 4. define the stackpointer > 5. define IRQ-tables > 6. test RAM i don't understand : you start executing code (1 and 2) but 3 means that code starts execution somewhere else (?) or i have missed a point. > Bye Andreas WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Mar 17 17:08:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mfts-0006g4-01 for ; Sun, 17 Mar 2002 20:01:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:01:00 +0100 (CET) Received: (qmail 10827 invoked by uid 0); 17 Mar 2002 17:23:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 17 Mar 2002 17:23:34 -0000 Received: by moria.seul.org (Postfix) id 6C5461467ED; Sun, 17 Mar 2002 12:23:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 677DE1468D7; Sun, 17 Mar 2002 12:23:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 044C51467ED for ; Sun, 17 Mar 2002 12:23:33 -0500 (EST) Received: from ifurita (213.44.155.187) by mail.laposte.net (5.5.044) id 3C9102D700028B26 for f-cpu@seul.org; Sun, 17 Mar 2002 18:23:32 +0100 Message-ID: <001301c1cdce$03d48160$bb9b2cd5@ifurita> From: "Christophe" To: References: <3C94CC84.C07DD596@f-cpu.org> Subject: Re: [f-cpu] more about f-romfs Date: Sun, 17 Mar 2002 17:08:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Par example the Motorola 68302 (communication-processor) init-process is > > in short: > > > > 1. set BAR (basis adress register) > > 2. define with base and mask the RAM/ROM/Port-areas, means the > > chip-selects > > 3. Code will be executed from CS0, means ROM at adress 0 > > 4. define the stackpointer > > 5. define IRQ-tables > > 6. test RAM > > i don't understand : you start executing code (1 and 2) > but 3 means that code starts execution somewhere else (?) > or i have missed a point. > Not very clear in fact... I think it would be better something like that : 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal or external space memory. 2.sets BAR, selects the right chip-selects for RAM/ROM/Ports areas. 3.tests RAM. 4.defines the stack pointer and IRQ-tables. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 18:54:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftt-0006g4-00 for ; Sun, 17 Mar 2002 20:01:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:01:01 +0100 (CET) Received: (qmail 31622 invoked by uid 0); 17 Mar 2002 17:48:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 17 Mar 2002 17:48:39 -0000 Received: by moria.seul.org (Postfix) id C32F11468D6; Sun, 17 Mar 2002 12:48:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE7EF1468D8; Sun, 17 Mar 2002 12:48:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 374E61468D6 for ; Sun, 17 Mar 2002 12:48:38 -0500 (EST) Received: from f-cpu.org (kdl17-46.n.club-internet.fr [213.44.19.46]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8A970174F for ; Sun, 17 Mar 2002 18:48:34 +0100 (CET) Message-ID: <3C94D853.8CA1BE62@f-cpu.org> Date: Sun, 17 Mar 2002 18:54:27 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, just a quick, incomplete answer. More answers later, if i find more time (i'm currently trying to make YGASM more useful). Christophe wrote: > Well, it's true i'm shy in english :-) obviously not ;-) > More seriously, I think the issue about the time penality about using CAS and > CAS2 is overstated. The solution offered by Yann to replace it with a fix array > of semaphores through the SR mechanisms is an evidence that either he don't > know about what we are really talking or he misunderstands the real purposes of > CAS2. Yann, let me tell you that your solution is really clumsy (I will explain why). So maybe your problem was not clearly stated in the beginning. My position is simple : separate the different kinds of problems to solve them all in the most simple, suitable and efficient way. This is not something Descartes will disagree with. I see nicO's position ("everything is memory mapped") as the contrary because it makes the memory system so much complex by mixing all problems together. In the end, the problem is not solved and the memory system is too complex to be implemented. The SR were designed to separate the configuration registers (which have very important side effects on security, scheduling and memory coherency, but which are not accessed often, so the bandwidth is not a problem) from the general streams (data and instructions, which eat up 100% of the bandwidth). The LSU, fetcher and the remaining of the FC0 memory system are designed to handle 256 bit words as a base granularity. Putting either configuration registers or synch primitives (which are 32-bit or 64-bits) in the memory range is a waste of bandwidth (it takes an average of 4 cycles in the optimistic scenario to load or store a whole line and using only one word means that there are at least 3 lost cycles). Modifying the LSU to handle smaller lines is also a bad "solution" because it makes the design more complex and the feature is not going to be used often. As far as i can imagine, CAS and CAS2 were designed on _exsting_ computers, with the limitations of the existing platforms. Now we are designing a new platform and we can find better solutions to the problems. Not a better implementation of the previous solution, but a rewording of the initial question. All i read in the current thread is : "let's make a CPU like what already exists" and this is not going to help make better computers. > Personnaly, I think that you are too more confident about yourself - It is not about confidence. You, nicO or any other people who has once posted in a F-CPU thread was confident enough to speak in this list. It's about opinions and if i was not confident in my own opinions, i wouldn't speak or write about it. This list is also a medium that works by convincing people, by finding good reasons but not forcing people. Everybody here is free to think what he wants. I respect your opinions and i have the right to have my own. My only work as one of the maintainers of this list is to receive error messages and help people to subscribe and unsubscribe, it is not a moderated list and i encourage the technical discussions, even when no agreement is found. If somebody want to manage this list in my place, no problem (my mailbox will get less messages). If you have a magic solution, then speak about it. Not only the theory, but also the implementation and this has to fit in the existing framework. You have to find the way to integrate your idea in what others have done during the last 3 years. > especially since you states everytime that you are the only one who code. I am not the only one : Mathias Brossard, Michael Riepe, Cedric Bail and Etienne Labarre have also contributed with code, or are contributing. I am just pointing out that some people prefer to speak rather than implement. Implementation is better because it's a tangible proof. I also tease you because _i_want_you_to_code_, too. nicO, you and all the other lurkers (80 ?) in this list. I am not going to make everything myself, otherwise it would not be F-CPU bu YGCPU. > Please, stop with that !!! you shouldn't speak that way simply because you > don't want to hear about something you regard as a crap. You will exasperate > too many people with such a behavior. I don't say that what you think or propose is crap. I say that it is not adapted to the existing framework/architecture. I am really sorry if you are exasperated and it is not my intention, far from it. However, if your method is as good as you say, you will certainly find a way to convince me with a solution or a compromise, and some code to backup your affirmations. Otherwise, this thread will last forever and make everybody angry :-( This thread seriously lacks sense of humor, too ... read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Mar 17 18:55:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftu-0006g4-00 for ; Sun, 17 Mar 2002 20:01:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:01:02 +0100 (CET) Received: (qmail 28712 invoked by uid 0); 17 Mar 2002 17:52:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 17 Mar 2002 17:52:38 -0000 Received: by moria.seul.org (Postfix) id 9F1E31468D7; Sun, 17 Mar 2002 12:52:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 944A11468D9; Sun, 17 Mar 2002 12:52:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id C4FF51468D7 for ; Sun, 17 Mar 2002 12:52:36 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16mesf-0007sS-00 for f-cpu@seul.org; Sun, 17 Mar 2002 18:55:41 +0100 Date: Sun, 17 Mar 2002 18:55:41 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs In-Reply-To: <001301c1cdce$03d48160$bb9b2cd5@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 17 Mar 2002, Christophe wrote: > > Not very clear in fact... I think it would be better something like that : > > 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal > or external space memory. 1a. evaluate hardware configuration structure of BIST ROM (this is a software structure reflecting the chip HW structure) 1b. run internal selftest BIST 1c. verify outer bus interface (i960 has an interesting check, boot structure with crc) 1e. start code of external bus > 2.sets BAR, selects the right chip-selects for RAM/ROM/Ports areas. > 3.tests RAM. > 4.defines the stack pointer and IRQ-tables. this is just needed for a monitor in external ROM. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 19:06:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mftu-0006g4-01 for ; Sun, 17 Mar 2002 20:01:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 17 Mar 2002 20:01:02 +0100 (CET) Received: (qmail 25791 invoked by uid 0); 17 Mar 2002 18:00:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 17 Mar 2002 18:00:41 -0000 Received: by moria.seul.org (Postfix) id 416F31468D8; Sun, 17 Mar 2002 13:00:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E80D1468DA; Sun, 17 Mar 2002 13:00:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id CB4731468D8 for ; Sun, 17 Mar 2002 13:00:39 -0500 (EST) Received: from f-cpu.org (kdl16-155.n.club-internet.fr [213.44.18.155]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 69CC0177E for ; Sun, 17 Mar 2002 19:00:36 +0100 (CET) Message-ID: <3C94DB25.D9106721@f-cpu.org> Date: Sun, 17 Mar 2002 19:06:29 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: <3C94CC84.C07DD596@f-cpu.org> <001301c1cdce$03d48160$bb9b2cd5@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe wrote: > > > Par example the Motorola 68302 (communication-processor) init-process is > > > in short: > > > > > > 1. set BAR (basis adress register) > > > 2. define with base and mask the RAM/ROM/Port-areas, means the > > > chip-selects > > > 3. Code will be executed from CS0, means ROM at adress 0 > > > 4. define the stackpointer > > > 5. define IRQ-tables > > > 6. test RAM > > > > i don't understand : you start executing code (1 and 2) > > but 3 means that code starts execution somewhere else (?) > > or i have missed a point. > > Not very clear in fact... I think it would be better something like that : > > 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal > or external space memory. sure but then, how do you define the ROM address ? Andreas says that this range is defined by a set of registers which must be programmed ... yet another chicken-and-egg problem :-) > 2.sets BAR, selects the right chip-selects for RAM/ROM/Ports areas. > 3.tests RAM. > 4.defines the stack pointer and IRQ-tables. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sun Mar 17 19:15:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mkuV-0001Yt-01 for ; Mon, 18 Mar 2002 01:22:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 01:21:59 +0100 (CET) Received: (qmail 19023 invoked by uid 0); 17 Mar 2002 19:39:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 17 Mar 2002 19:39:07 -0000 Received: by moria.seul.org (Postfix) id 5CED31467E9; Sun, 17 Mar 2002 14:39:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5345314685C; Sun, 17 Mar 2002 14:39:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 510741467E9 for ; Sun, 17 Mar 2002 14:39:04 -0500 (EST) Received: from art1.none.de ([62.144.184.101]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g2HJd8m29877 for ; Sun, 17 Mar 2002 20:39:08 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.184.101] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16mfCr-0000UZ-00 for ; Sun, 17 Mar 2002 19:16:33 +0100 Date: Sun, 17 Mar 2002 19:15:53 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs In-Reply-To: <3C94CC84.C07DD596@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > > 1. set BAR (basis adress register) > > 2. define with base and mask the RAM/ROM/Port-areas, means the > > chip-selects > > 3. Code will be executed from CS0, means ROM at adress 0 ^^^^^^^^ That was a mistake, I meant this as an explanation... > > 4. define the stackpointer > > 5. define IRQ-tables > > 6. test RAM Correct it should be: Code will be executed from CS0, means ROM at adress 0 1. set BAR (basis adress register) 2. define with base and masks the range of RAM/ROM/Port-areas, means the chip-selects will be defined 3. define the stackpointer 4. define IRQ-tables/-vectors 5. test RAM 6. load OS or something else... Bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8lN1cClxplZklbgERAtpCAJ9hEeJHFjU5JO75yKuMNTNzedc+dQCfZ+86 ZMTkZ9yMo6h/PXBC7pr9jy8= =10x/ -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sun Mar 17 20:51:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mkuW-0001Yt-00 for ; Mon, 18 Mar 2002 01:22:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 01:22:00 +0100 (CET) Received: (qmail 7483 invoked by uid 0); 17 Mar 2002 19:49:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 17 Mar 2002 19:49:21 -0000 Received: by moria.seul.org (Postfix) id C059314685B; Sun, 17 Mar 2002 14:49:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC3FD1468D9; Sun, 17 Mar 2002 14:49:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 0F84A14685B for ; Sun, 17 Mar 2002 14:49:19 -0500 (EST) Received: from art1.none.de ([62.144.178.127]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g2HJnNm30140 for ; Sun, 17 Mar 2002 20:49:23 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.178.127] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16mgh4-0000gk-00 for ; Sun, 17 Mar 2002 20:51:50 +0100 Date: Sun, 17 Mar 2002 20:51:34 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs In-Reply-To: <3C94DB25.D9106721@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > > > > 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal > > or external space memory. > > sure but then, how do you define the ROM address ? Andreas says that this > range is defined by a set of registers which must be programmed ... > yet another chicken-and-egg problem :-) Where is the problem? On 68302 pE. you have the CS0, is this line active, the external/internal controller switch to a ROM, With register BR0 and OR0 which corresponends with CS0, you define the adress-lines, which are represent the external ROM-start and Size. With BR1 and OR1 you set and masks the range of a external RAM via CS1, ditto BR2 and OR2 the range of external Ports via CS2, the BR3 and OR3 the range of internal RAM via CS3 or whatever ou want. Remember, on 68302 you have the CS0-3-lines, the adress-lines, which are programmable via BR0-3 and OR0-3... In my opinion we should go the sam way, because it is easy a) to debug, b) easy to configure c) easy to implement... Where is the problem? Bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8lPPVClxplZklbgERAv3PAJ9X8zfmI1aYPsNijjpYO5Zcrqg/SgCeMcXy A8+/wpQzAdfBfoXa1OcnjXU= =Ll9S -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 17 21:21:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mkuZ-0001Yt-00 for ; Mon, 18 Mar 2002 01:22:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 01:22:03 +0100 (CET) Received: (qmail 10719 invoked by uid 0); 17 Mar 2002 20:15:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 17 Mar 2002 20:15:33 -0000 Received: by moria.seul.org (Postfix) id 730B514685C; Sun, 17 Mar 2002 15:15:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 573451468DA; Sun, 17 Mar 2002 15:15:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 13B1C14685C for ; Sun, 17 Mar 2002 15:15:31 -0500 (EST) Received: from f-cpu.org (kdl16-27.n.club-internet.fr [213.44.18.27]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 79DA117AC for ; Sun, 17 Mar 2002 21:15:28 +0100 (CET) Message-ID: <3C94FAC1.16D511A9@f-cpu.org> Date: Sun, 17 Mar 2002 21:21:21 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] more about f-romfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Andreas Romeyke wrote: > Hello, > > > > > > > 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal > > > or external space memory. > > > > sure but then, how do you define the ROM address ? Andreas says that this > > range is defined by a set of registers which must be programmed ... > > yet another chicken-and-egg problem :-) > > Where is the problem? On 68302 pE. you have the CS0, is this line active, > the external/internal controller switch to a ROM, With register BR0 and > OR0 which corresponends with CS0, you define the adress-lines, which are > represent the external ROM-start and Size. > > With BR1 and OR1 you set and masks the range of a external RAM via CS1, > ditto BR2 and OR2 the range of external Ports via CS2, the BR3 and OR3 the > range of internal RAM via CS3 or whatever ou want. > > Remember, on 68302 you have the CS0-3-lines, the adress-lines, which are > programmable via BR0-3 and OR0-3... Now it seems clear : the CPU starts with CS0 (configured as base=0 and mask=-1) and executes code which modifies this default setting. > In my opinion we should go the sam way, because it is easy a) to debug, > b) easy to configure c) easy to implement... > > Where is the problem? extensibility. using a fixed, limited set of CS is a potential risk of later hacks to circumvent this limitation (for example, extending the number of interrupts of a 68000 is possible but not always clean and always application dependent). Furthermore, F-CPU doesn't use a CPU-centric point of view like in a microcontroller environment. There is a direct SDRAM interface with a configurable base address but otherwise, there is no direct connection to the I/O or the booting ROM, it goes through a generic I/O interface (VCI/AMBA/Wishbone...). good evening, > Bye Art1 WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 18 00:41:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mkub-0001Yt-01 for ; Mon, 18 Mar 2002 01:22:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 01:22:05 +0100 (CET) Received: (qmail 20240 invoked by uid 0); 17 Mar 2002 23:42:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 17 Mar 2002 23:42:24 -0000 Received: by moria.seul.org (Postfix) id BAC071468DC; Sun, 17 Mar 2002 18:42:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A52001468DE; Sun, 17 Mar 2002 18:42:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a178.home.uni-hannover.de [130.75.232.178]) by moria.seul.org (Postfix) with ESMTP id F18721468DC for ; Sun, 17 Mar 2002 18:42:21 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA11436; Mon, 18 Mar 2002 00:41:28 +0100 Message-ID: <20020318004128.11722@thrai.stud.uni-hannover.de> Date: Mon, 18 Mar 2002 00:41:28 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <003001c1cdab$9209c4e0$cef9c2d4@ifurita>; from Christophe on Sun, Mar 17, 2002 at 01:02:10PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Mar 17, 2002 at 01:02:10PM +0100, Christophe wrote: > Well, it's true i'm shy in english :-) > > More seriously, I think the issue about the time penality about using CAS and > CAS2 is overstated. The solution offered by Yann to replace it with a fix array > of semaphores through the SR mechanisms is an evidence that either he don't > know about what we are really talking or he misunderstands the real purposes of > CAS2. Yann, let me tell you that your solution is really clumsy (I will explain > why). Personnaly, I think that you are too more confident about yourself - > especially since you states everytime that you are the only one who code. Wrong. But I haven't seen much VDHL from anybody except Yann, either. Ok, let's forget that for the moment. In order to get the big picture and be able to have an opinion of my own: what the heck *is* CAS/CAS2? I suppose it's not the Column Address Strobe signal found in DRAMS... URLs welcome. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 00:08:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1K-00037Y-00 for ; Mon, 18 Mar 2002 03:37:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:10 +0100 (CET) Received: (qmail 1865 invoked by uid 0); 18 Mar 2002 00:23:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 18 Mar 2002 00:23:50 -0000 Received: by moria.seul.org (Postfix) id A90821468DD; Sun, 17 Mar 2002 19:23:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4DDC1468DE; Sun, 17 Mar 2002 19:23:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 490291468DD for ; Sun, 17 Mar 2002 19:23:46 -0500 (EST) Received: from ifurita (212.194.255.87) by mail.laposte.net (5.5.044) id 3C9102D70002CC04 for f-cpu@seul.org; Mon, 18 Mar 2002 01:23:45 +0100 Message-ID: <004601c1ce08$b78e48a0$57ffc2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 00:08:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N CAS : Compare-And-Swap is a READ-MODIFY-WRITE operation which is atomic and allow us to update value in memory without unconsistancy. in C : int CAS (int *pointer,int requested_value,int new_value) { if (requested_value == *pointer) { *pointer = new_value; return true; } return false; } Example of a CAS application : TAS, Test-And-Set, wellknown: int TAS (int *pointer) { return CAS (pointer,0,1); } A spinlock : void spinlock (int *pointer) { while (TAS (pointer)); } void spinunlock (int *pointer) { *pointer = 0; } A CAS2 is in fact two atomic CAS : int CAS (int *pointer1,int *pointer2,int requested_value1,int requested_value2,int new_value1,int new_value2) { if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { *pointer1 = new_value1; *pointer2 = new_value2; return true; } return false; } Examples : How to push a element in a stack : void atomic_push (struct stack *stack,struct stack_node *element) { struct stack_node *requested_top; int requested_version; do { requested_top = stack->top; requested_version = stack->version; element->link = requested_top; } while (CAS2 (&stack->top,&stack->version,requested_top,requested_version,element,requested_ version+1)); } How to pop a element in a stack : struct stack_node *atomic_pop (struct stack *stack) { struct stack_node *requested_top,*next_element; int requested_version; do { requested_top = stack->top; requested_version = stack->version; next_element = requested_top->link; } while (requested_top && CAS2 (&stack->top,&stack->version,requested_top,requested_version,next_element,reque sted_version+1)); return requested_top; } they work as well in UP mode as in SMP mode in a user code. No need of blocking syncronisation, so no need to enter kernel mode if necessary, etc. ----- Original Message ----- From: Michael Riepe To: Sent: Monday, March 18, 2002 12:41 AM Subject: Re: [f-cpu] another DATE report > On Sun, Mar 17, 2002 at 01:02:10PM +0100, Christophe wrote: > > Well, it's true i'm shy in english :-) > > > > More seriously, I think the issue about the time penality about using CAS and > > CAS2 is overstated. The solution offered by Yann to replace it with a fix array > > of semaphores through the SR mechanisms is an evidence that either he don't > > know about what we are really talking or he misunderstands the real purposes of > > CAS2. Yann, let me tell you that your solution is really clumsy (I will explain > > why). Personnaly, I think that you are too more confident about yourself - > > especially since you states everytime that you are the only one who code. > > Wrong. But I haven't seen much VDHL from anybody except Yann, either. > > Ok, let's forget that for the moment. In order to get the big picture > and be able to have an opinion of my own: what the heck *is* CAS/CAS2? > I suppose it's not the Column Address Strobe signal found in DRAMS... > > URLs welcome. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 00:10:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1L-00037Y-00 for ; Mon, 18 Mar 2002 03:37:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:11 +0100 (CET) Received: (qmail 14881 invoked by uid 0); 18 Mar 2002 00:25:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 18 Mar 2002 00:25:32 -0000 Received: by moria.seul.org (Postfix) id 4641D1468DE; Sun, 17 Mar 2002 19:25:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2EAB61468E0; Sun, 17 Mar 2002 19:25:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 9594D1468DE for ; Sun, 17 Mar 2002 19:25:30 -0500 (EST) Received: from ifurita (212.194.255.87) by mail.laposte.net (5.5.044) id 3C9101C80002E2F3 for f-cpu@seul.org; Mon, 18 Mar 2002 01:25:29 +0100 Message-ID: <005201c1ce08$f586d8c0$57ffc2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 00:10:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry, you must read do { ... } while (! CAS (...)); and not do { ... } while (CAS (...)); same thing for CAS2 ----- Original Message ----- From: Christophe To: Sent: Monday, March 18, 2002 12:08 AM Subject: Re: [f-cpu] another DATE report > CAS : Compare-And-Swap is a READ-MODIFY-WRITE operation which is atomic and > allow us to update value in memory without unconsistancy. > > in C : > > int CAS (int *pointer,int requested_value,int new_value) { > if (requested_value == *pointer) { > *pointer = new_value; return true; > } > return false; > } > > Example of a CAS application : TAS, Test-And-Set, wellknown: > > int TAS (int *pointer) { > return CAS (pointer,0,1); > } > > A spinlock : > > void spinlock (int *pointer) { > while (TAS (pointer)); > } > > void spinunlock (int *pointer) { > *pointer = 0; > } > > A CAS2 is in fact two atomic CAS : > > int CAS (int *pointer1,int *pointer2,int requested_value1,int > requested_value2,int new_value1,int new_value2) { > if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { > *pointer1 = new_value1; *pointer2 = new_value2; return true; > } > return false; > } > > Examples : > > How to push a element in a stack : > > void atomic_push (struct stack *stack,struct stack_node *element) { > struct stack_node *requested_top; > int requested_version; > do > { > requested_top = stack->top; > requested_version = stack->version; > element->link = requested_top; > } > while (CAS2 > (&stack->top,&stack->version,requested_top,requested_version,element,requested_ > version+1)); > } > > How to pop a element in a stack : > > struct stack_node *atomic_pop (struct stack *stack) { > struct stack_node *requested_top,*next_element; > int requested_version; > do > { > requested_top = stack->top; > requested_version = stack->version; > next_element = requested_top->link; > } > while (requested_top && CAS2 > (&stack->top,&stack->version,requested_top,requested_version,next_element,reque > sted_version+1)); > return requested_top; > } > > they work as well in UP mode as in SMP mode in a user code. No need of blocking > syncronisation, so no need to enter kernel mode if necessary, etc. > > ----- Original Message ----- > From: Michael Riepe > To: > Sent: Monday, March 18, 2002 12:41 AM > Subject: Re: [f-cpu] another DATE report > > > > On Sun, Mar 17, 2002 at 01:02:10PM +0100, Christophe wrote: > > > Well, it's true i'm shy in english :-) > > > > > > More seriously, I think the issue about the time penality about using CAS > and > > > CAS2 is overstated. The solution offered by Yann to replace it with a fix > array > > > of semaphores through the SR mechanisms is an evidence that either he don't > > > know about what we are really talking or he misunderstands the real > purposes of > > > CAS2. Yann, let me tell you that your solution is really clumsy (I will > explain > > > why). Personnaly, I think that you are too more confident about yourself - > > > especially since you states everytime that you are the only one who code. > > > > Wrong. But I haven't seen much VDHL from anybody except Yann, either. > > > > Ok, let's forget that for the moment. In order to get the big picture > > and be able to have an opinion of my own: what the heck *is* CAS/CAS2? > > I suppose it's not the Column Address Strobe signal found in DRAMS... > > > > URLs welcome. > > > > -- > > Michael "Tired" Riepe > > "All I wanna do is have a little fun before I die" > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 18 01:33:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1M-00037Y-00 for ; Mon, 18 Mar 2002 03:37:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:12 +0100 (CET) Received: (qmail 21962 invoked by uid 0); 18 Mar 2002 00:27:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 18 Mar 2002 00:27:46 -0000 Received: by moria.seul.org (Postfix) id AF73A1468E2; Sun, 17 Mar 2002 19:27:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD0AD1468E1; Sun, 17 Mar 2002 19:27:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5ABD31468DF for ; Sun, 17 Mar 2002 19:27:45 -0500 (EST) Received: from f-cpu.org (kdl16-65.n.club-internet.fr [213.44.18.65]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 49CB316AE for ; Mon, 18 Mar 2002 01:27:37 +0100 (CET) Message-ID: <3C9535C6.9718EF25@f-cpu.org> Date: Mon, 18 Mar 2002 01:33:10 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe wrote: > > CAS : Compare-And-Swap is a READ-MODIFY-WRITE operation which is atomic and > allow us to update value in memory without unconsistancy. > > in C : can we integrate your code in the manual ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 00:17:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1M-00037Y-01 for ; Mon, 18 Mar 2002 03:37:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:12 +0100 (CET) Received: (qmail 10903 invoked by uid 0); 18 Mar 2002 00:32:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 18 Mar 2002 00:32:25 -0000 Received: by moria.seul.org (Postfix) id 975C01468E4; Sun, 17 Mar 2002 19:32:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9357F1468E3; Sun, 17 Mar 2002 19:32:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 492BC1468DF for ; Sun, 17 Mar 2002 19:32:24 -0500 (EST) Received: from ifurita (212.194.255.87) by mail.laposte.net (5.5.044) id 3C9101C80002E4C2 for f-cpu@seul.org; Mon, 18 Mar 2002 01:32:23 +0100 Message-ID: <000701c1ce09$ecbcaca0$57ffc2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <3C9535C6.9718EF25@f-cpu.org> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 00:17:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Which manual ? ----- Original Message ----- From: Yann Guidon To: Sent: Monday, March 18, 2002 1:33 AM Subject: Re: [f-cpu] another DATE report > hi, > > Christophe wrote: > > > > CAS : Compare-And-Swap is a READ-MODIFY-WRITE operation which is atomic and > > allow us to update value in memory without unconsistancy. > > > > in C : > > > can we integrate your code in the manual ? > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 18 01:39:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1N-00037Y-00 for ; Mon, 18 Mar 2002 03:37:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:13 +0100 (CET) Received: (qmail 24137 invoked by uid 0); 18 Mar 2002 00:34:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 18 Mar 2002 00:34:22 -0000 Received: by moria.seul.org (Postfix) id 23E711468E3; Sun, 17 Mar 2002 19:34:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 218011468E1; Sun, 17 Mar 2002 19:34:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id BC0F41468DF for ; Sun, 17 Mar 2002 19:34:20 -0500 (EST) Received: from f-cpu.org (kdl16-65.n.club-internet.fr [213.44.18.65]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 96F081701 for ; Mon, 18 Mar 2002 01:34:11 +0100 (CET) Message-ID: <3C95375F.6BDB9158@f-cpu.org> Date: Mon, 18 Mar 2002 01:39:59 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <3C9535C6.9718EF25@f-cpu.org> <000701c1ce09$ecbcaca0$57ffc2d4@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe wrote: > > > in C : > > > > > > can we integrate your code in the manual ? > > Which manual ? the (in)famous "F-CPU manual" :-) Cédric is currently updating it. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 00:21:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1N-00037Y-01 for ; Mon, 18 Mar 2002 03:37:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:13 +0100 (CET) Received: (qmail 7357 invoked by uid 0); 18 Mar 2002 00:36:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Mar 2002 00:36:27 -0000 Received: by moria.seul.org (Postfix) id C28AE1468DF; Sun, 17 Mar 2002 19:36:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A824F1468E1; Sun, 17 Mar 2002 19:36:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 2489B1468DF for ; Sun, 17 Mar 2002 19:36:25 -0500 (EST) Received: from ifurita (212.194.255.87) by mail.laposte.net (5.5.044) id 3C9102D70002CE12 for f-cpu@seul.org; Mon, 18 Mar 2002 01:36:23 +0100 Message-ID: <001501c1ce0a$7bdd9ac0$57ffc2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 00:21:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Example of a CAS application : TAS, Test-And-Set, wellknown: > > int TAS (int *pointer) { > return CAS (pointer,0,1); > } > > A spinlock : > > void spinlock (int *pointer) { > while (TAS (pointer)); > } Must be : void spinlock (int *pointer) { while (! TAS (pointer)); } ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 00:22:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1O-00037Y-00 for ; Mon, 18 Mar 2002 03:37:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:14 +0100 (CET) Received: (qmail 16304 invoked by uid 0); 18 Mar 2002 00:36:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 18 Mar 2002 00:36:58 -0000 Received: by moria.seul.org (Postfix) id C025B1468E0; Sun, 17 Mar 2002 19:36:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A303D1468E4; Sun, 17 Mar 2002 19:36:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id B5F581468E0 for ; Sun, 17 Mar 2002 19:36:54 -0500 (EST) Received: from ifurita (212.194.255.87) by mail.laposte.net (5.5.044) id 3C9101C80002E512 for f-cpu@seul.org; Mon, 18 Mar 2002 01:36:52 +0100 Message-ID: <001b01c1ce0a$8ccb19c0$57ffc2d4@ifurita> From: "Christophe" To: References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <3C9535C6.9718EF25@f-cpu.org> <000701c1ce09$ecbcaca0$57ffc2d4@ifurita> <3C95375F.6BDB9158@f-cpu.org> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 00:22:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yes of course. ----- Original Message ----- From: Yann Guidon To: Sent: Monday, March 18, 2002 1:39 AM Subject: Re: [f-cpu] another DATE report > hi, > > Christophe wrote: > > > > in C : > > > > > > > > > can we integrate your code in the manual ? > > > > Which manual ? > > the (in)famous "F-CPU manual" :-) > Cédric is currently updating it. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 18 01:49:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1O-00037Y-01 for ; Mon, 18 Mar 2002 03:37:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:14 +0100 (CET) Received: (qmail 31359 invoked by uid 0); 18 Mar 2002 00:43:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 18 Mar 2002 00:43:43 -0000 Received: by moria.seul.org (Postfix) id 7527A1468E4; Sun, 17 Mar 2002 19:43:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 72E771468E6; Sun, 17 Mar 2002 19:43:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id D84E31468E4 for ; Sun, 17 Mar 2002 19:43:40 -0500 (EST) Received: from f-cpu.org (kdl11-42.n.club-internet.fr [213.44.9.42]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 783A316A6 for ; Mon, 18 Mar 2002 01:43:31 +0100 (CET) Message-ID: <3C95398B.5FDF5598@f-cpu.org> Date: Mon, 18 Mar 2002 01:49:15 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C881E56.A7E2B3AA@f-cpu.org> <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Sun, Mar 17, 2002 at 01:02:10PM +0100, Christophe wrote: > > Well, it's true i'm shy in english :-) > > > > More seriously, I think the issue about the time penality about using CAS and > > CAS2 is overstated. The solution offered by Yann to replace it with a fix array > > of semaphores through the SR mechanisms is an evidence that either he don't > > know about what we are really talking or he misunderstands the real purposes of > > CAS2. Yann, let me tell you that your solution is really clumsy (I will explain > > why). Personnaly, I think that you are too more confident about yourself - > > especially since you states everytime that you are the only one who code. > > Wrong. But I haven't seen much VDHL from anybody except Yann, either. in fact, it's not a statement, but a complaint. Fortunately, Michael has done some incredible work too. > Ok, let's forget that for the moment. In order to get the big picture > and be able to have an opinion of my own: what the heck *is* CAS/CAS2? > I suppose it's not the Column Address Strobe signal found in DRAMS... right ;-) > URLs welcome. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 18 02:20:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16mn1P-00037Y-01 for ; Mon, 18 Mar 2002 03:37:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 03:37:15 +0100 (CET) Received: (qmail 16426 invoked by uid 0); 18 Mar 2002 01:21:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 18 Mar 2002 01:21:01 -0000 Received: by moria.seul.org (Postfix) id 628891468E5; Sun, 17 Mar 2002 20:21:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 604341468E7; Sun, 17 Mar 2002 20:21:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a178.home.uni-hannover.de [130.75.232.178]) by moria.seul.org (Postfix) with ESMTP id 904331468E5 for ; Sun, 17 Mar 2002 20:20:58 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA11742; Mon, 18 Mar 2002 02:20:57 +0100 Message-ID: <20020318022057.49806@thrai.stud.uni-hannover.de> Date: Mon, 18 Mar 2002 02:20:57 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <004601c1ce08$b78e48a0$57ffc2d4@ifurita>; from Christophe on Mon, Mar 18, 2002 at 12:08:56AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 18, 2002 at 12:08:56AM +0100, Christophe wrote: > CAS : Compare-And-Swap is a READ-MODIFY-WRITE operation which is atomic and > allow us to update value in memory without unconsistancy. Ah... *click* > in C : > > int CAS (int *pointer,int requested_value,int new_value) { > if (requested_value == *pointer) { > *pointer = new_value; return true; > } > return false; > } Except that this function is NOT atomic. There's no way to specify an atomic operation in standard C (but it's ok, I know this is only for demonstration). We could easily do this kind of operation in hardware, btw. [...] > A CAS2 is in fact two atomic CAS : > > int CAS (int *pointer1,int *pointer2,int requested_value1,int > requested_value2,int new_value1,int new_value2) { > if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { > *pointer1 = new_value1; *pointer2 = new_value2; return true; > } > return false; > } > > Examples : > > How to push a element in a stack : > > void atomic_push (struct stack *stack,struct stack_node *element) { > struct stack_node *requested_top; > int requested_version; > do > { > requested_top = stack->top; > requested_version = stack->version; > element->link = requested_top; > } > while (CAS2 > (&stack->top,&stack->version,requested_top,requested_version,element,requested_ > version+1)); > } I'm not sure whether the latency will be better than with a simple spinlock around the update operation: void atomic_push (struct stack *stack,struct stack_node *element) { while (!CAS(&stack->spinlock, 0, 1)); element->link = stack->top; stack->top = element; stack->version++; stack->spinlock = 0; } -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 03:49:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16msCA-0008KZ-00 for ; Mon, 18 Mar 2002 09:08:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 18 Mar 2002 09:08:42 +0100 (CET) Received: (qmail 30194 invoked by uid 0); 18 Mar 2002 04:04:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 18 Mar 2002 04:04:00 -0000 Received: by moria.seul.org (Postfix) id 6019D1468E0; Sun, 17 Mar 2002 23:03:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 32DE71468E7; Sun, 17 Mar 2002 23:03:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id B7C921468E0 for ; Sun, 17 Mar 2002 23:03:58 -0500 (EST) Received: from ifurita (212.194.244.77) by mail.laposte.net (5.5.044) id 3C9101C80002F308 for f-cpu@seul.org; Mon, 18 Mar 2002 05:03:58 +0100 Message-ID: <000901c1ce27$79b47300$4df4c2d4@ifurita> From: "Christophe" To: References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 03:49:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > We could easily do this kind of operation in hardware, btw. Oh fine. > [...] > > A CAS2 is in fact two atomic CAS : > > > > int CAS (int *pointer1,int *pointer2,int requested_value1,int > > requested_value2,int new_value1,int new_value2) { > > if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { > > *pointer1 = new_value1; *pointer2 = new_value2; return true; > > } > > return false; > > } > > > > Examples : > > > > How to push a element in a stack : > > > > void atomic_push (struct stack *stack,struct stack_node *element) { > > struct stack_node *requested_top; > > int requested_version; > > do > > { > > requested_top = stack->top; > > requested_version = stack->version; > > element->link = requested_top; > > } > > while (CAS2 > > (&stack->top,&stack->version,requested_top,requested_version,element,requested_ > > version+1)); > > } > > I'm not sure whether the latency will be better than with a simple > spinlock around the update operation: well, there is a problem with the spinlock version : what happens if a task switch occurs between the locking and the unlocking ? especially if other tasks will try to acquire the same spinlock, they all shall be blocked until the owner task may release the spinlock, which - not speaking about the invert priority problem of tasks - is in fact a real degradation. Such a thing cannot happen with CAS2 because the first to be serviced is the first to write, not the first to read - the other tasks would just need a retry - which takes basically less time to execute than waiting for owner task to unlock. Indeed, to avoid this problem when task switching, the usual workaround is to disable interrupts before acquiring and after releasing the spinlock. But such a thing is acceptable if time is very short between locking and unlocking, that is, not using a blocking function in-between. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 10:43:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNp-00071g-00 for ; Tue, 19 Mar 2002 09:54:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:17 +0100 (CET) Received: (qmail 8301 invoked by uid 0); 18 Mar 2002 10:58:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 18 Mar 2002 10:58:15 -0000 Received: by moria.seul.org (Postfix) id D98D91467E8; Mon, 18 Mar 2002 05:58:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF31E1467F0; Mon, 18 Mar 2002 05:58:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 57EFC1467E8 for ; Mon, 18 Mar 2002 05:58:14 -0500 (EST) Received: from ifurita (213.44.147.251) by mail.laposte.net (5.5.044) id 3C9101C8000348EB for f-cpu@seul.org; Mon, 18 Mar 2002 11:58:13 +0100 Message-ID: <000901c1ce61$58c2de40$fb932cd5@ifurita> From: "Christophe" To: References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 10:43:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Indeed, to avoid this problem when task switching, the usual workaround is to > disable interrupts before acquiring and after releasing the spinlock. But such > a thing is acceptable if time is very short between locking and unlocking, that > is, not using a blocking function in-between. ... is to disable interrupts JUST before acquiring and to ENABLE interrupts JUST after releasing the spinlock. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 18 12:41:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNq-00071g-00 for ; Tue, 19 Mar 2002 09:54:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:18 +0100 (CET) Received: (qmail 12724 invoked by uid 0); 18 Mar 2002 11:35:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 18 Mar 2002 11:35:54 -0000 Received: by moria.seul.org (Postfix) id 56CE81467ED; Mon, 18 Mar 2002 06:35:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 44A031467F0; Mon, 18 Mar 2002 06:35:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C85761467ED for ; Mon, 18 Mar 2002 06:35:52 -0500 (EST) Received: from f-cpu.org (kdl11-208.n.club-internet.fr [213.44.9.208]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 6A3B61699 for ; Mon, 18 Mar 2002 12:35:49 +0100 (CET) Message-ID: <3C95D275.A52926C3@f-cpu.org> Date: Mon, 18 Mar 2002 12:41:41 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: spinlocks (was Re: [f-cpu] another DATE report) References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Christophe wrote: > > We could easily do this kind of operation in hardware, btw. > Oh fine. just a question : "how" ? > > [...] > > > A CAS2 is in fact two atomic CAS : > > > > > > int CAS (int *pointer1,int *pointer2,int requested_value1,int > > > requested_value2,int new_value1,int new_value2) { > > > if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { > > > *pointer1 = new_value1; *pointer2 = new_value2; return true; > > > } > > > return false; > > > } and don't tell me "We could easily do this kind of operation in hardware, btw." ! there are 2 pointers and 4 values with CAS2 ! Unless you use several instructions, the instruction itself would require at least 36 bits for the operands. > > > Examples : > > > > > > How to push a element in a stack : > > > > > > void atomic_push (struct stack *stack,struct stack_node *element) { > > > struct stack_node *requested_top; > > > int requested_version; > > > do > > > { > > > requested_top = stack->top; > > > requested_version = stack->version; > > > element->link = requested_top; > > > } > > > while (CAS2 (&stack->top,&stack->version,requested_top, > > > requested_version,element,requested_version+1)); > > > } > > > > I'm not sure whether the latency will be better than with a simple > > spinlock around the update operation: > > well, there is a problem with the spinlock version : what happens if a task > switch occurs between the locking and the unlocking ? especially if other tasks > will try to acquire the same spinlock, they all shall be blocked until the > owner task may release the spinlock, which - not speaking about the invert > priority problem of tasks - is in fact a real degradation. Such a thing cannot > happen with CAS2 because the first to be serviced is the first to write, not > the first to read - the other tasks would just need a retry - which takes > basically less time to execute than waiting for owner task to unlock. I do not doubt that what you say is true, here. the problem is still : "how do you think it can be implemented in the existing framework" ? > Indeed, to avoid this problem when task switching, the usual workaround is to > disable interrupts before acquiring and after releasing the spinlock. But such > a thing is acceptable if time is very short between locking and unlocking, that > is, not using a blocking function in-between. huh ? if CAS2 requires the task to turn off IRQs, then i don't see why it is superior to CAS. Are you sure there is no such routine that does what you describe with a series of simple CAS and without touching the IRQs ? later, Christophe wrote: > > > Indeed, to avoid this problem when task switching, the usual workaround is to > > disable interrupts before acquiring and after releasing the spinlock. But such > > a thing is acceptable if time is very short between locking and unlocking, that > > is, not using a blocking function in-between. > > ... is to disable interrupts JUST before acquiring and to ENABLE interrupts > JUST after releasing the spinlock. Now i think : you enter a critical section (playing with the IRQ enable bit is nothing else, i guess). This means that you request ownership of the data. A simple "semaphore" (sorry, i know you don't lile this word) would do the trick, no ? * acquire semaphore * swap stack top (or any operation, whatever the complexity) * release semaphore You say that CAS2 is the best of all but i don't understand this statement if you need to call the kernel to enter in a critical section. what did i miss ? have a nice day, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 13:03:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNr-00071g-00 for ; Tue, 19 Mar 2002 09:54:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:19 +0100 (CET) Received: (qmail 4806 invoked by uid 0); 18 Mar 2002 13:20:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 18 Mar 2002 13:20:23 -0000 Received: by moria.seul.org (Postfix) id 80FA21467EE; Mon, 18 Mar 2002 08:20:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 551D41467F1; Mon, 18 Mar 2002 08:20:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id D6CA11467EE for ; Mon, 18 Mar 2002 08:20:21 -0500 (EST) Received: from ifurita (213.44.155.111) by mail.laposte.net (5.5.044) id 3C9102D700035873 for f-cpu@seul.org; Mon, 18 Mar 2002 14:20:20 +0100 Message-ID: <000201c1ce75$32c43720$6f9b2cd5@ifurita> From: "Christophe" To: Subject: [f-cpu] Preemption-safe locking and non-blocking (lock-free) algorithms Date: Mon, 18 Mar 2002 13:03:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Please read this attached PDF file if you want have a global sight of what are preemption-safe locking and non-blocking algorithms. Some notes about the ABA problem : if a process reads a value A in a shared location, computes a new value, and then attempts a compare-and-swap operation, the compare-and-swap may succeed when it should not, if between the read and the compare-and-swap some other process(es) change the A to a B and then back to an A. A common solution is to use a version stamp, that is a counter of modification along with the data to be modified. It is the reason why I use it in my example of push and pop functions in my last email. But if you use a stack for free elements for example (i.e, contents of element don't matter), a simple CAS for "top" is enough in so far the ABA problem doesn't invalidate. Intel pentium have : - a single word compare-and-swap : cmpxchg reg1,[reg2] atomic { if (eax == *reg2) { *reg2 = reg1; zf = 1; /* zero flag */ } else { eax = *reg2; // update the requested value since it has changed zf = 0; } } As you can see, it chooses in fact to update either the memory location when the requested value matches or update the requested value if not so you don't need to reread it for the next try and save a read memory access bu reusing the one in the READ-MODIFY-WRITE operation : if requested value is equals to memory content so an atomic push function for free integer location would be shorter because we don't need to reread requested value : void atomic_push (int *top,int *node) { // we suppose %top and %node are registers register int requested_top asm ("%eax"); asm { mov (%top),%eax // requested_top = *top; 0: mov %eax,(%top) // *((int **)node) = requested_top cmpxchg %node,(%top) jnz 0b } } but a spinlock would be if used in a kernel mode (in a user mode, it is impossible to disable interrupt so we would need to enter a kernel trap) : void spinlock (int *pointer) { // we suppose %pointer is a register register int requested_value asm ("%eax"); register int new_value; register int eflags; asm { pushfd mov $1,%new_value cli // disable interrupts 0: mov $0,%eax // requested_value = 0; cmpxchg %new_value,(%pointer) jnz 0b popfd // reenable interrupts } } - a limited double word compare-and-swap : cmpxchg8b [reg1] atomic { if (eax == ecx && edx == ebx) { *(reg1+0) = ecx; *(reg1+1) = ebx; zf = 1; /* zero flag */ } else { // update the requested values since they have changed eax = *(reg1+0); edx = *(reg1+1); zf = 0; } } so an atomic push function would be shorter because we don't need to reread requested value : struct stack { struct stack_node *top; int version; }; void atomic_push (struct stack *stack,struct stack_node *node) { // we suppose %stack and %node are registers register int requested_top asm ("%eax"); register int requested_version asm ("%edx"); register int new_top asm ("%ecx"); register int new_version asm ("%ebx"); asm { mov 0(%stack),%eax // requested_top = stack->node; mov 4(%stack),%edx // requested_version = stack->version; mov %node,%ecx 0: mov %eax,(%node) // node->link = requested_top lea 1(%edx),%ebx // new_version = 1 + requested_version cmpxchg8b (%stack) jnz 0b } } - a word fetch-and-add : xadd reg1,[reg2] atomic { eax == *reg2; *reg2 = eax + reg1; } What could be my proposal for a modified CAS : cas r1,r2,[r3] : IN : r1 : requested value, r2 : new value, r3 : pointer OUT : r1 : new requested value, r2 : 0 if CAS successes READ: - read the actual value in memory location. MODIFY: - if the actual value equals to the requested value, set the requested value with the new value else set the requested value with the actual value - new value is set to true if it equals to requested value. WRITE: - write the requested value in memory location. atomic { *pointer = (requested_value = ((actual_value = *pointer) == requested_value) ? new_value : actual_value); new_value ^= request_value; // new_value set to 0 will tell us that CAS successes } which looks as if you do : atomic { if (*pointer == requested_value) *pointer = requested_value = new_value; else requested_value = *pointer; new_value ^= requested_value; } That way, we do not need to reread the requested value. The new value if not changing between retries can be saved in another register : move top,r3 move node,r4 load [r3],r1 // requested_top = *top; loadaddr 0f,r16 0: move r4,r2 store r1,[r3] // *((int **)node) = requested_top cas r1,r2,[r3] jump.nz r2,r0,r16 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 13:54:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNt-00071g-00 for ; Tue, 19 Mar 2002 09:54:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:21 +0100 (CET) Received: (qmail 24885 invoked by uid 0); 18 Mar 2002 14:09:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Mar 2002 14:09:22 -0000 Received: by moria.seul.org (Postfix) id 793481467F1; Mon, 18 Mar 2002 09:09:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5085A1467FC; Mon, 18 Mar 2002 09:09:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id E10051467F1 for ; Mon, 18 Mar 2002 09:09:20 -0500 (EST) Received: from ifurita (213.44.155.111) by mail.laposte.net (5.5.044) id 3C9101F2000395B2 for f-cpu@seul.org; Mon, 18 Mar 2002 15:09:20 +0100 Message-ID: <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> From: "Christophe" To: References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) Date: Mon, 18 Mar 2002 13:54:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > and don't tell me "We could easily do this kind of operation in hardware, btw." ! > there are 2 pointers and 4 values with CAS2 ! Unless you use several instructions, > the instruction itself would require at least 36 bits for the operands. > Yes i know for CAS2 is not very easy... using pairs of Rn and Rn+1 maybe ? Or using pairable CAS, dunno. Anyway the single CAS wouldn't be a problem since you need only three operands. > > > I'm not sure whether the latency will be better than with a simple > > > spinlock around the update operation: > > > > well, there is a problem with the spinlock version : what happens if a task > > switch occurs between the locking and the unlocking ? especially if other tasks > > will try to acquire the same spinlock, they all shall be blocked until the > > owner task may release the spinlock, which - not speaking about the invert > > priority problem of tasks - is in fact a real degradation. Such a thing cannot > > happen with CAS2 because the first to be serviced is the first to write, not > > the first to read - the other tasks would just need a retry - which takes > > basically less time to execute than waiting for owner task to unlock. > > I do not doubt that what you say is true, here. > the problem is still : "how do you think it can be implemented in the existing framework" ? I'm sure you would find a solution if you wanted to storm your brain ;-). > > Indeed, to avoid this problem when task switching, the usual workaround is to > > disable interrupts before acquiring and after releasing the spinlock. But such > > a thing is acceptable if time is very short between locking and unlocking, that > > is, not using a blocking function in-between. > > huh ? if CAS2 requires the task to turn off IRQs, then i don't see why it is superior > to CAS. Are you sure there is no such routine that does what you describe with a > series of simple CAS and without touching the IRQs ? !?!? what is this absurdity !? noooooooooo !!! I never told that !!!! Im not speaking about CAS2 !!!! but the SPINLOCK as a replacement for CAS2 as PROPOSED by M.Rieppe !!!!!!! Please reread above : "well, there is a problem with the spinlock version". So the problem comes from spinlock not from CAS2 since i stated : "Such a thing cannot happen with CAS2". by the way, spinlock is a BLOCKING synchronisation and CAS/CAS2 is a non-blocking synchronisation. indeed, I explain how to make a spinlock with a CAS, that is turning a non-blocking synchronisation in a preemption-safe lock (if we disable interrupts too in the loop). in M.Rieppe version, no task switching must occur (because of the problem above) so unless using a more complicated preemption-safe mechanism, we disable all interrupts - even the IRQs which are not concerned by this synchronisation : void atomic_push (struct stack *stack,struct stack_node *element) { disable_interrupts (); while (!CAS(&stack->spinlock, 0, 1)); // unknown delay element->link = stack->top; stack->top = element; stack->version++; stack->spinlock = 0; enable_interrupts (); } In my CAS version, a task switch can occur without any problem and all IRQs can run freely too. void atomic_push (struct stack *stack,struct stack_node *element) { struct stack_node *requested_top; int requested_version; do { requested_top = stack->top; requested_version = stack->version; element->link = requested_top; } while (CAS2 (&stack->top,&stack->version,requested_top,requested_version,element,requested_ version+1)); } I use the name "atomic_push" but I should have chosen "safe_push" or "consistent_push" indeed. > > later, Christophe wrote: > > > > > Indeed, to avoid this problem when task switching, the usual workaround is to > > > disable interrupts before acquiring and after releasing the spinlock. But such > > > a thing is acceptable if time is very short between locking and unlocking, that > > > is, not using a blocking function in-between. > > > > ... is to disable interrupts JUST before acquiring and to ENABLE interrupts > > JUST after releasing the spinlock. Stop it ! where the heck can you see I disable interrupts in my CAS2 primitive !? i'm speaking about the spinlock version of M.Rieppe, not my CAS2 version. If you use a spinlock you need to disable interrupts to avoid degradation as i was speaking above. In the CAS2 version, we don't need to do so. In fact if we don't need a version stamping to prevent us from the ABA problem, a CAS would be enough and more efficient than a spinlock. Spinlocks are used when you need to update consistently larger data than non-blocking primitives like CAS or CAS2 can do. > Now i think : you enter a critical section (playing with the IRQ enable bit is > nothing else, i guess). This means that you request ownership of the data. > A simple "semaphore" (sorry, i know you don't lile this word) would do the trick, no ? > * acquire semaphore > * swap stack top (or any operation, whatever the complexity) > * release semaphore berrrrrk ! when contention it degrades too much you F-CPU performance, because you need to use a kernel trap to make your task waiting or awaken. > > You say that CAS2 is the best of all but i don't understand this statement if > you need to call the kernel to enter in a critical section. what did i miss ? What can I say more ? my examples should be enough to understand what you stated here is absurd... sure you miss a lot. :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 18 15:48:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNv-00071g-00 for ; Tue, 19 Mar 2002 09:54:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:23 +0100 (CET) Received: (qmail 5502 invoked by uid 0); 18 Mar 2002 14:42:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 18 Mar 2002 14:42:17 -0000 Received: by moria.seul.org (Postfix) id 5EEE11467F3; Mon, 18 Mar 2002 09:42:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 58240146819; Mon, 18 Mar 2002 09:42:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id F40C61467F3 for ; Mon, 18 Mar 2002 09:42:15 -0500 (EST) Received: from f-cpu.org (kdl11-132.n.club-internet.fr [213.44.9.132]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 43F5E16CA for ; Mon, 18 Mar 2002 15:42:13 +0100 (CET) Message-ID: <3C95FE24.6C0B49E0@f-cpu.org> Date: Mon, 18 Mar 2002 15:48:04 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Preemption-safe locking and non-blocking (lock-free) algorithms References: <000201c1ce75$32c43720$6f9b2cd5@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe wrote: > > Please read this attached PDF file if you want have a global sight of what are > preemption-safe locking and non-blocking algorithms. notice : this list is limited to 50K long message and your next post was refused. You can upload the file to ftp.seul.org or give an URL. read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 15:08:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNw-00071g-01 for ; Tue, 19 Mar 2002 09:54:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:24 +0100 (CET) Received: (qmail 13670 invoked by uid 0); 18 Mar 2002 15:23:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Mar 2002 15:23:27 -0000 Received: by moria.seul.org (Postfix) id C97741467F3; Mon, 18 Mar 2002 10:23:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C34DE146819; Mon, 18 Mar 2002 10:23:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 570201467F3 for ; Mon, 18 Mar 2002 10:23:24 -0500 (EST) Received: from ifurita (212.194.246.159) by mail.laposte.net (5.5.044) id 3C9101C80003A682 for f-cpu@seul.org; Mon, 18 Mar 2002 16:23:23 +0100 Message-ID: <002d01c1ce86$63d30d80$9ff6c2d4@ifurita> From: "Christophe" To: References: <000201c1ce75$32c43720$6f9b2cd5@ifurita> Subject: Re: [f-cpu] Preemption-safe locking and non-blocking (lock-free) algorithms Date: Mon, 18 Mar 2002 15:08:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Please read this attached PDF file if you want have a global sight of what are > preemption-safe locking and non-blocking algorithms. hope this URL is right : http://citeseer.nj.nec.com/rd/82520068,61189,1,0.25,Download/http%253A%252F%252 Fciteseer.nj.nec.com/cache/papers/cs/2206/ftp%253AzSzzSzftp.cs.rochester.eduzSz pubzSzpaperszSzsystemszSz98.JPDC.Non-blocking_algorithms_and_preemption-safe_lo cking.pdf/michael98nonblocking.pdf ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Mar 18 17:05:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFNy-00071g-00 for ; Tue, 19 Mar 2002 09:54:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:26 +0100 (CET) Received: (qmail 19475 invoked by uid 0); 18 Mar 2002 16:08:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 18 Mar 2002 16:08:24 -0000 Received: by moria.seul.org (Postfix) id C93EF146816; Mon, 18 Mar 2002 11:08:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABF45146865; Mon, 18 Mar 2002 11:08:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id C5AB4146816 for ; Mon, 18 Mar 2002 11:08:20 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id JAA28507 for ; Mon, 18 Mar 2002 09:08:19 -0700 (MST) Message-ID: <3C961063.E8D878F9@jetnet.ab.ca> Date: Mon, 18 Mar 2002 09:05:55 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] another DATE report References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <000901c1ce61$58c2de40$fb932cd5@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > > > Indeed, to avoid this problem when task switching, the usual workaround is to > > disable interrupts before acquiring and after releasing the spinlock. But > such > > a thing is acceptable if time is very short between locking and unlocking, > that > > is, not using a blocking function in-between. > > ... is to disable interrupts JUST before acquiring and to ENABLE interrupts > JUST after releasing the spinlock. I have to check a book on real time programing, but this style of task locking may not work on multiprocessors. I think the critical section algorithms for multi-tasking favor normal instructions over atomic ones. Looking at software all you are doing is emulating edge triggered flip/flops in software and running asynchronous logic from them. The task switching and real time clock sync up the tasks. Synchronous logic is good for hardware, why not software? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 16:43:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFO0-00071g-00 for ; Tue, 19 Mar 2002 09:54:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:28 +0100 (CET) Received: (qmail 2345 invoked by uid 0); 18 Mar 2002 16:58:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 18 Mar 2002 16:58:52 -0000 Received: by moria.seul.org (Postfix) id 0CD2B146819; Mon, 18 Mar 2002 11:58:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE8731468E5; Mon, 18 Mar 2002 11:58:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 9A88F146819 for ; Mon, 18 Mar 2002 11:58:51 -0500 (EST) Received: from ifurita (212.194.227.202) by mail.laposte.net (5.5.044) id 3C9102D70003A567 for f-cpu@seul.org; Mon, 18 Mar 2002 17:58:51 +0100 Message-ID: <002901c1ce93$b93299a0$cae3c2d4@ifurita> From: "Christophe" To: References: <3C88FEAC.BAFC02A7@seul.org> <3C8921B4.21F31303@f-cpu.org> <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <000901c1ce61$58c2de40$fb932cd5@ifurita> <3C961063.E8D878F9@jetnet.ab.ca> Subject: Re: [f-cpu] another DATE report Date: Mon, 18 Mar 2002 16:43:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Ben Franchuk To: Sent: Monday, March 18, 2002 5:05 PM Subject: Re: [f-cpu] another DATE report > Christophe wrote: > > > > > Indeed, to avoid this problem when task switching, the usual workaround is to > > > disable interrupts before acquiring and after releasing the spinlock. But > > such > > > a thing is acceptable if time is very short between locking and unlocking, > > that > > > is, not using a blocking function in-between. > > > > ... is to disable interrupts JUST before acquiring and to ENABLE interrupts > > JUST after releasing the spinlock. > > I have to check a book on real time programing, but this style of task > locking > may not work on multiprocessors. It is for avoiding task switch ONLY for the first processor which ACQUIRES the spinlock. So it works for multiprocessors too, provided that other cpus are really locked when they try to CAS the same location that the first processor is being to CAS. > I think the critical section algorithms for multi-tasking > favor normal instructions over atomic ones. Which critical session ? what are you speaking about ? spinlocks ? or non-blocking primitives ? there is no critical sessions in non-blocking primtives. > Looking at software all you are doing is emulating Which one ? > edge triggered flip/flops in software and running > asynchronous logic from them. > The task switching and real time clock > sync up the tasks. > Synchronous logic is good for hardware, why not software? Sorry, I don't understand at all what you mean :( could you be more explicit or give me an example ? > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 18 12:07:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFO3-00071g-00 for ; Tue, 19 Mar 2002 09:54:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:31 +0100 (CET) Received: (qmail 9246 invoked by uid 0); 18 Mar 2002 18:55:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 18 Mar 2002 18:55:42 -0000 Received: by moria.seul.org (Postfix) id 317411468E7; Mon, 18 Mar 2002 13:55:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BB2A1468F0; Mon, 18 Mar 2002 13:55:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a037.home.uni-hannover.de [130.75.232.37]) by moria.seul.org (Postfix) with ESMTP id 6CFB71468E7 for ; Mon, 18 Mar 2002 13:55:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00541; Mon, 18 Mar 2002 12:07:36 +0100 Message-ID: <20020318120736.54471@thrai.stud.uni-hannover.de> Date: Mon, 18 Mar 2002 12:07:36 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000901c1ce27$79b47300$4df4c2d4@ifurita>; from Christophe on Mon, Mar 18, 2002 at 03:49:07AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 18, 2002 at 03:49:07AM +0100, Christophe wrote: [...] > well, there is a problem with the spinlock version : what happens if a task > switch occurs between the locking and the unlocking ? especially if other tasks > will try to acquire the same spinlock, they all shall be blocked until the > owner task may release the spinlock, which - not speaking about the invert > priority problem of tasks - is in fact a real degradation. Such a thing cannot > happen with CAS2 because the first to be serviced is the first to write, not > the first to read - the other tasks would just need a retry - which takes > basically less time to execute than waiting for owner task to unlock. A spinlock protected piece of code should be as short as possible, and not contain blocking functions at all. Spinlocks are just a way to make a sequence of simple instructions atomic -- like the update operations in the stack example, or a software implementation of CAS2 (which would be too heavy as a machine instruction -- remember that it has six operands). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Mon Mar 18 20:21:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFO4-00071g-00 for ; Tue, 19 Mar 2002 09:54:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:32 +0100 (CET) Received: (qmail 24156 invoked by uid 0); 18 Mar 2002 19:13:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 18 Mar 2002 19:13:01 -0000 Received: by moria.seul.org (Postfix) id E3B601468F0; Mon, 18 Mar 2002 14:12:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E15951468EF; Mon, 18 Mar 2002 14:12:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id AC17C1468ED; Mon, 18 Mar 2002 14:12:59 -0500 (EST) Received: from seul.org (vlt10-220.n.club-internet.fr [195.36.224.220]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 733111705; Mon, 18 Mar 2002 20:12:56 +0100 (CET) Message-ID: <3C963E37.FDD3313B@seul.org> Date: Mon, 18 Mar 2002 20:21:27 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Mon, Mar 18, 2002 at 03:49:07AM +0100, Christophe wrote: > [...] > > well, there is a problem with the spinlock version : what happens if a task > > switch occurs between the locking and the unlocking ? especially if other tasks > > will try to acquire the same spinlock, they all shall be blocked until the > > owner task may release the spinlock, which - not speaking about the invert > > priority problem of tasks - is in fact a real degradation. Such a thing cannot > > happen with CAS2 because the first to be serviced is the first to write, not > > the first to read - the other tasks would just need a retry - which takes > > basically less time to execute than waiting for owner task to unlock. > > A spinlock protected piece of code should be as short as possible, and > not contain blocking functions at all. Spinlocks are just a way to make a > sequence of simple instructions atomic -- like the update operations in > the stack example, or a software implementation of CAS2 (which would be > too heavy as a machine instruction -- remember that it has six operands). > This instruction are used inside PowerPC. Maybe it's possible to "link" few instructions together to defined a CAS2 operation. Imagine a flag set, if something happen between the fetch, CAS2 are canceled. I know it look like CISC but here the state machine is simple : if the 3 or 4 instructions or fetch one after an other the CAS2 op are made on the bus (never forget that we need this type of cycle for our internal bus), if something else happen it's cancelled, if the fetch begin in the "middle" of the 3 instructions (as after a switch) nothing happen. I thing it simple, no ? nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Mar 18 22:32:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOB-00071g-00 for ; Tue, 19 Mar 2002 09:54:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:39 +0100 (CET) Received: (qmail 8435 invoked by uid 0); 18 Mar 2002 22:47:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 18 Mar 2002 22:47:04 -0000 Received: by moria.seul.org (Postfix) id 93D61146805; Mon, 18 Mar 2002 17:47:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 77A2F1468EF; Mon, 18 Mar 2002 17:47:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 13325146805 for ; Mon, 18 Mar 2002 17:47:03 -0500 (EST) Received: from ifurita (213.44.151.5) by mail.laposte.net (5.5.044) id 3C9101C800042B81 for f-cpu@seul.org; Mon, 18 Mar 2002 23:47:02 +0100 Message-ID: <004901c1cec4$5d8391a0$05972cd5@ifurita> From: "Christophe" To: References: <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) Date: Mon, 18 Mar 2002 22:32:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Monday, March 18, 2002 12:07 PM Subject: CAS and spinlocks (was: Re: [f-cpu] another DATE report) > A spinlock protected piece of code should be as short as possible, and > not contain blocking functions at all. Spinlocks are just a way to make a > sequence of simple instructions atomic -- like the update operations in > the stack example, or a software implementation of CAS2 (which would be > too heavy as a machine instruction -- remember that it has six operands). Yes but do you agree that you still need to disable interrupts (something you forget to do in your example) to prevent your sequence from an undesirable preemptive task switch ? it is not a hazard that Linux does it for its spinlocks. I think to have a single CAS is a minimum. To have a CAS2 can really boost compared with its software implementation. But, ok, let us first to try to have an efficient CAS. Afterward we can try the impossible :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 18 21:53:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOB-00071g-01 for ; Tue, 19 Mar 2002 09:54:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:39 +0100 (CET) Received: (qmail 6999 invoked by uid 0); 18 Mar 2002 23:26:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Mar 2002 23:26:47 -0000 Received: by moria.seul.org (Postfix) id D24421468F1; Mon, 18 Mar 2002 18:26:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFE1F1468EF; Mon, 18 Mar 2002 18:26:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a245.home.uni-hannover.de [130.75.232.245]) by moria.seul.org (Postfix) with ESMTP id 4C09C1467F1 for ; Mon, 18 Mar 2002 18:26:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00736; Mon, 18 Mar 2002 21:53:40 +0100 Message-ID: <20020318215339.47919@thrai.stud.uni-hannover.de> Date: Mon, 18 Mar 2002 21:53:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) References: <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita>; from Christophe on Mon, Mar 18, 2002 at 01:54:27PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 18, 2002 at 01:54:27PM +0100, Christophe wrote: [...] > > > Indeed, to avoid this problem when task switching, the usual workaround is > to > > > disable interrupts before acquiring and after releasing the spinlock. But > such > > > a thing is acceptable if time is very short between locking and unlocking, > that > > > is, not using a blocking function in-between. > > > > huh ? if CAS2 requires the task to turn off IRQs, then i don't see why it is > superior > > to CAS. Are you sure there is no such routine that does what you describe > with a > > series of simple CAS and without touching the IRQs ? > > !?!? what is this absurdity !? noooooooooo !!! I never told that !!!! Im not > speaking about CAS2 !!!! but the SPINLOCK as a replacement for CAS2 as PROPOSED > by M.Rieppe !!!!!!! With a single "p", please. On the other hand, you may also call me Michael. > Please reread above : "well, there is a problem with the spinlock version". So > the problem comes from spinlock not from CAS2 since i stated : "Such a thing > cannot happen with CAS2". > > by the way, spinlock is a BLOCKING synchronisation and CAS/CAS2 is a > non-blocking synchronisation. indeed, I explain how to make a spinlock with a > CAS, that is turning a non-blocking synchronisation in a preemption-safe lock > (if we disable interrupts too in the loop). > > in M.Rieppe version, no task switching must occur (because of the problem > above) so unless using a more complicated preemption-safe mechanism, we disable > all interrupts - even the IRQs which are not concerned by this synchronisation > : > > void atomic_push (struct stack *stack,struct stack_node *element) { > disable_interrupts (); > while (!CAS(&stack->spinlock, 0, 1)); // unknown delay With the CAS2 solution, the delay isn't known either -- you never know how many times the CPU has to process the retry loop. > element->link = stack->top; > stack->top = element; > stack->version++; > stack->spinlock = 0; > enable_interrupts (); > } > > In my CAS version, a task switch can occur without any problem and all IRQs can > run freely too. At the cost of having to retry the update operation if the CAS2 fails. [...] > In fact if we > don't need a version stamping to prevent us from the ABA problem, a CAS would > be enough and more efficient than a spinlock. [...] Depends. Consider the following examples: with_spinlock() { disable_irq_and_lock(); // may delay indefinitely long x = long_computation(x); unlock_and_enable_irq(); } with_cas() { do { oldx = x; newx = long_computation(oldx); } while (!CAS(&x, oldx, newx)); // may repeat indefinite times } First of all, in with_cas() we silently assume that `oldx = x;' is itself an atomic operation, and that the probably complex data structures pointed to by `x' don't change while long_computation() runs -- which may not be the case. That is, you may need to turn off IRQs and, in case you have an MP system, put a spinlock around the loop body -- even with CAS (or CAS2). And of course you must not schedule. Second, the delay argument: with_spinlock() runs for t(lock) + t(compute) + t(unlock), where t(lock) is indefinite. with_cas() takes n * (t(compute) + t(cas)), where n (the number of tries) is indefinite. In the optimal case (no lock/miscompare), n becomes 1, and the times are: spinlock: t = t(lock) + t(compute) + t(unlock) cas: t = t(compute) + t(cas) Assuming that t(lock) >= t(cas), the spinlock is slightly slower. But that doesn't matter much if t(compute) is one or more orders of magnitude bigger than t(cas). If n equals 2, the times are spinlock: t = t(lock) + t(compute) + t(unlock) cas: t = 2*(t(compute) + t(cas)) Assuming that all tasks perform similar computations, we get 0 < t(lock) <= t(compute) or an average of t(lock) = t(compute) / 2. That is, the spinlock variant may be faster in this case, because it checks the lock more frequently than the CAS solution. Note that this does not mean that I don't like CAS. Au contraire -- we definitely need an atomic read-modify-write operation, and this one looks pretty good to me, although it doesn't solve all problems. CAS2, on the other hand, is too heavy for a hardware implementation. We can't handle 6 input operands, no matter how hard we try. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 18 20:15:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOC-00071g-00 for ; Tue, 19 Mar 2002 09:54:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:40 +0100 (CET) Received: (qmail 12223 invoked by uid 0); 18 Mar 2002 23:26:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 18 Mar 2002 23:26:51 -0000 Received: by moria.seul.org (Postfix) id 11C4B1468ED; Mon, 18 Mar 2002 18:26:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC49A1468F2; Mon, 18 Mar 2002 18:26:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a245.home.uni-hannover.de [130.75.232.245]) by moria.seul.org (Postfix) with ESMTP id 1AAB31468ED for ; Mon, 18 Mar 2002 18:26:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00509; Mon, 18 Mar 2002 20:15:15 +0100 Message-ID: <20020318201514.06861@thrai.stud.uni-hannover.de> Date: Mon, 18 Mar 2002 20:15:14 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) References: <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C95D275.A52926C3@f-cpu.org>; from Yann Guidon on Mon, Mar 18, 2002 at 12:41:41PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 18, 2002 at 12:41:41PM +0100, Yann Guidon wrote: > hello, > > Christophe wrote: > > > We could easily do this kind of operation in hardware, btw. > > Oh fine. > > just a question : "how" ? repeat pull the requested memory location into the cache make the executing CPU the owner of the cache line (SMP) read data and compare if (the line is still valid and owned by us) if (the result was true) write data end if return (result) end if end repeat > > > [...] > > > > A CAS2 is in fact two atomic CAS : > > > > > > > > int CAS (int *pointer1,int *pointer2,int requested_value1,int > > > > requested_value2,int new_value1,int new_value2) { > > > > if ((requested_value1 == *pointer1) && (requested_value2 == *pointer2)) { > > > > *pointer1 = new_value1; *pointer2 = new_value2; return true; > > > > } > > > > return false; > > > > } > > and don't tell me "We could easily do this kind of operation in hardware, btw." ! Of course not. > there are 2 pointers and 4 values with CAS2 ! Unless you use several instructions, > the instruction itself would require at least 36 bits for the operands. Right -- we'll have to emulate CAS2 in software. But that's not a problem if we have at least one atomic read-modify-write instruction. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 00:10:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOE-00071g-00 for ; Tue, 19 Mar 2002 09:54:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:42 +0100 (CET) Received: (qmail 25446 invoked by uid 0); 19 Mar 2002 00:25:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Mar 2002 00:25:26 -0000 Received: by moria.seul.org (Postfix) id 12FFD1468F9; Mon, 18 Mar 2002 19:25:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 092CB1468F8; Mon, 18 Mar 2002 19:25:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id B93091467F1 for ; Mon, 18 Mar 2002 19:25:24 -0500 (EST) Received: from ifurita (212.194.228.180) by mail.laposte.net (5.5.044) id 3C9102D7000412EC for f-cpu@seul.org; Tue, 19 Mar 2002 01:25:24 +0100 Message-ID: <000201c1ced2$12537d40$b4e4c2d4@ifurita> From: "Christophe" To: References: <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> <20020318215339.47919@thrai.stud.uni-hannover.de> Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) Date: Tue, 19 Mar 2002 00:10:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Monday, March 18, 2002 9:53 PM Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) > With a single "p", please. On the other hand, you may also call me Michael. Sorry, Michael :-) > With the CAS2 solution, the delay isn't known either -- you never know > how many times the CPU has to process the retry loop. > For the case there is no IRQ or task switch which can disturb : while (1) { new++; do { old = *pointer; } while (! CAS (pointer,old,new)); } --- A : read old --- --- B : read old --- --- A : CAS --- HIT ! --- B : CAS --- MISS ! --- A : new++ --- B : read old --- --- B : CAS --- HIT ! --- A : read old --- --- A : CAS --- MISS ! ... - For 2 concurrent processors, the first processor to write always passed, so the second do a retry and have a hit the second time because it would have time to write before the former processor had time enough to pass a second time. So both processors finally share their hits near 1/2. - For n concurrent processors, the first processor to write always passed, so others will do a retry. the unluckier would do n-1 retries at max in fact. So both processors finally share their hits near 1/n. Even with disturbance like IRQ or task switch, the time for each processor to have a hit could be shorter than a delay between two task switchs or IRQ and be enough to allow all processors finally to have a hit. As a benefit, if one processor is interrupted by an IRQ, another processor will hit anyway. > At the cost of having to retry the update operation if the CAS2 fails. for n concurrent processors, n-1 failures is the raisonnable maximum we get in reality for the very worst case. > [...] > > In fact if we > > don't need a version stamping to prevent us from the ABA problem, a CAS would > > be enough and more efficient than a spinlock. > [...] > > Depends. Consider the following examples: > with_cas() { > do { > oldx = x; > newx = long_computation(oldx); > } > while (!CAS(&x, oldx, newx)); // may repeat indefinite times > } Why ? if cycles for long_computation are the same for both processors, both processors would hit each after other. By the way if you don't call this with_cas in an eternal loop so your statement "repeat indefinite times" becomes false, because there is a time when a processor hits, it wouldn't be back until a very long moment (at least I hope so!) so it should not be any longer a possible contention for other processors waiting for their hits. But okay, if long_computation is undeterministic, I wouldn't use CAS nor CAS2 ! Anyway, using CAS shouldn't be a thing which occurs at 99% of running code, so such a situation should be avoided. > Note that this does not mean that I don't like CAS. Au contraire -- we > definitely need an atomic read-modify-write operation, and this one > looks pretty good to me, although it doesn't solve all problems. Of course, it doesn't solve all problems. But I prefer them to semaphores when possible. > CAS2, on the other hand, is too heavy for a hardware implementation. > We can't handle 6 input operands, no matter how hard we try. I know, I know. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 01:40:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOF-00071g-00 for ; Tue, 19 Mar 2002 09:54:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:43 +0100 (CET) Received: (qmail 26644 invoked by uid 0); 19 Mar 2002 00:40:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 19 Mar 2002 00:40:47 -0000 Received: by moria.seul.org (Postfix) id 897F41467F1; Mon, 18 Mar 2002 19:40:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 858371468F2; Mon, 18 Mar 2002 19:40:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a245.home.uni-hannover.de [130.75.232.245]) by moria.seul.org (Postfix) with ESMTP id E11151467F1 for ; Mon, 18 Mar 2002 19:40:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01742; Tue, 19 Mar 2002 01:40:43 +0100 Message-ID: <20020319014043.54866@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 01:40:43 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <004901c1cec4$5d8391a0$05972cd5@ifurita>; from Christophe on Mon, Mar 18, 2002 at 10:32:10PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Mar 18, 2002 at 10:32:10PM +0100, Christophe wrote: [...] > Yes but do you agree that you still need to disable interrupts (something you > forget to do in your example) to prevent your sequence from an undesirable > preemptive task switch ? it is not a hazard that Linux does it for its > spinlocks. I was in kernel mode for a moment... things are a little different there. You don't need to turn off interrupts in certain cases, for instance, because a task switch can not happen (but another task, on another CPU, can modify your data). > I think to have a single CAS is a minimum. To have a CAS2 can really boost > compared with its software implementation. But, ok, let us first to try to have > an efficient CAS. Afterward we can try the impossible :-) That comes second. First, let's build something that *works*. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 02:26:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOF-00071g-01 for ; Tue, 19 Mar 2002 09:54:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:43 +0100 (CET) Received: (qmail 16835 invoked by uid 0); 19 Mar 2002 01:26:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 19 Mar 2002 01:26:24 -0000 Received: by moria.seul.org (Postfix) id CCFA71468EF; Mon, 18 Mar 2002 20:26:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B32161468F5; Mon, 18 Mar 2002 20:26:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a245.home.uni-hannover.de [130.75.232.245]) by moria.seul.org (Postfix) with ESMTP id 4C0511468EF for ; Mon, 18 Mar 2002 20:26:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01855; Tue, 19 Mar 2002 02:26:17 +0100 Message-ID: <20020319022617.12493@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 02:26:17 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) References: <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> <20020318215339.47919@thrai.stud.uni-hannover.de> <000201c1ced2$12537d40$b4e4c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000201c1ced2$12537d40$b4e4c2d4@ifurita>; from Christophe on Tue, Mar 19, 2002 at 12:10:03AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 12:10:03AM +0100, Christophe wrote: [...] > - For 2 concurrent processors, the first processor to write always passed, so > the second do a retry and have a hit the second time because it would have time > to write before the former processor had time enough to pass a second time. So > both processors finally share their hits near 1/2. Without conflict, best case: time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CPU A R--------------W CPU B R--------------W With conflict (first write attempt on CPU B fails), worst case: time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CPU A R--------------W CPU B R--------------R--------------W The final (succeeding) operations, counted from the initial read, will never overlap. The same is true for the spinlock variant, except that the `worst case' situation is much better (less delay in case of failure): Spinlock, worst case: time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CPU A LR--------------WU CPU B LR--------------WU The letters mean: R(ead), W(rite), L(ock), U(nlock) [...] > By the way if you don't call this > with_cas in an eternal loop so your statement "repeat indefinite times" becomes > false, because there is a time when a processor hits, it wouldn't be back until > a very long moment (at least I hope so!) so it should not be any longer a > possible contention for other processors waiting for their hits. Things like push/pop operations on a stack happen all the time, not once in a millenium :) > But okay, if long_computation is undeterministic, I wouldn't use CAS nor CAS2 ! I wouldn't use a spinlock either, then. Never block if you have no idea how long the block will persist. > Anyway, using CAS shouldn't be a thing which occurs at 99% of running code, so > such a situation should be avoided. > > > Note that this does not mean that I don't like CAS. Au contraire -- we > > definitely need an atomic read-modify-write operation, and this one > > looks pretty good to me, although it doesn't solve all problems. > > Of course, it doesn't solve all problems. But I prefer them to semaphores when > possible. Semaphores are slightly different, and usually not present in hardware. When a task requests a semaphore that is in use, it is suspended (there will be a task switch). As soon as the semaphore is freed, the first process waiting for it is woken up, or maybe all of them, and probably another task switch is performed. A simple semaphore can be written using CAS: down(struct sem *sem) { while (!CAS(&sem->count, 1, 0)) { wait_on_semaphore(sem); // does a task switch /* we come back here when the task is woken up again */ } } up(struct sem *sem) { sem->count = 1; } A real semaphore (with an initial count > 1) is a little harder... We'd need another instruction in order to implement that efficiently, like `atomic test-for-zero-and-decrement-otherwise'. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 19 03:26:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOG-00071g-00 for ; Tue, 19 Mar 2002 09:54:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:44 +0100 (CET) Received: (qmail 9134 invoked by uid 0); 19 Mar 2002 02:20:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Mar 2002 02:20:51 -0000 Received: by moria.seul.org (Postfix) id 0E61E1468F2; Mon, 18 Mar 2002 21:20:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE6D41468F5; Mon, 18 Mar 2002 21:20:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 9A7771468F2 for ; Mon, 18 Mar 2002 21:20:49 -0500 (EST) Received: from f-cpu.org (kdl16-36.n.club-internet.fr [213.44.18.36]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 9AD9B168B for ; Tue, 19 Mar 2002 03:20:45 +0100 (CET) Message-ID: <3C96A1DE.6EBF899A@f-cpu.org> Date: Tue, 19 Mar 2002 03:26:38 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Mar 18, 2002 at 10:32:10PM +0100, Christophe wrote: > [...] > > I think to have a single CAS is a minimum. To have a CAS2 can really boost > > compared with its software implementation. But, ok, let us first to try to have > > an efficient CAS. Afterward we can try the impossible :-) > > That comes second. First, let's build something that *works*. i like you more and more, Michael :-P i don't like to read "we can try the impossible :-)" when _they_ speak about it and _we_ do it. F-CPU is also about responsibility and educating people to respect of each other's work. Not making a Babel tower, not making "throw away code"... Of course we need input and discussions with a wide range of people and cultures, different points of view, but if it's only talks, it's useless. instead of "try" i would like to read "do" and "impossible" i would like to read "detailed plan". Some people and me are currently following a plan and we would like other people to find a place in it, not modifying everything (and jeopardizing the work that was already done) that's all. i hope it's my last rant for today. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 19 04:28:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOJ-00071g-00 for ; Tue, 19 Mar 2002 09:54:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:47 +0100 (CET) Received: (qmail 22177 invoked by uid 0); 19 Mar 2002 03:22:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 19 Mar 2002 03:22:35 -0000 Received: by moria.seul.org (Postfix) id F007A1467FF; Mon, 18 Mar 2002 22:22:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BEEB51468D5; Mon, 18 Mar 2002 22:22:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 315B41467FF for ; Mon, 18 Mar 2002 22:22:32 -0500 (EST) Received: from f-cpu.org (kdl16-60.n.club-internet.fr [213.44.18.60]) by relay-1v.club-internet.fr (Postfix) with ESMTP id EBA40168F for ; Tue, 19 Mar 2002 04:22:28 +0100 (CET) Message-ID: <3C96B054.622E9E83@f-cpu.org> Date: Tue, 19 Mar 2002 04:28:20 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) References: <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> <20020318215339.47919@thrai.stud.uni-hannover.de> <000201c1ced2$12537d40$b4e4c2d4@ifurita> <20020319022617.12493@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N g'night, Michael Riepe wrote: > On Tue, Mar 19, 2002 at 12:10:03AM +0100, Christophe wrote: > [...] > > > Note that this does not mean that I don't like CAS. Au contraire -- we > > > definitely need an atomic read-modify-write operation, and this one > > > looks pretty good to me, although it doesn't solve all problems. > > > > Of course, it doesn't solve all problems. But I prefer them to semaphores when > > possible. > > Semaphores are slightly different, and usually not present in hardware. > When a task requests a semaphore that is in use, it is suspended (there > will be a task switch). As soon as the semaphore is freed, the first > process waiting for it is woken up, or maybe all of them, and probably > another task switch is performed. > > A simple semaphore can be written using CAS: > > down(struct sem *sem) { > while (!CAS(&sem->count, 1, 0)) { > wait_on_semaphore(sem); // does a task switch > /* we come back here when the task is woken up again */ > } > } > > up(struct sem *sem) { > sem->count = 1; > } > > A real semaphore (with an initial count > 1) is a little harder... > We'd need another instruction in order to implement that efficiently, > like `atomic test-for-zero-and-decrement-otherwise'. using load_lock and store_conditional, it's easy : just do a substraction with saturation, instead of the xor in my latest example. that's all. voilà. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 03:52:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOK-00071g-01 for ; Tue, 19 Mar 2002 09:54:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:48 +0100 (CET) Received: (qmail 17469 invoked by uid 0); 19 Mar 2002 04:07:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 19 Mar 2002 04:07:48 -0000 Received: by moria.seul.org (Postfix) id 624BA146823; Mon, 18 Mar 2002 23:07:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37E141468ED; Mon, 18 Mar 2002 23:07:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 73FD8146823 for ; Mon, 18 Mar 2002 23:07:43 -0500 (EST) Received: from ifurita (212.194.211.243) by mail.laposte.net (5.5.044) id 3C9101F2000465CA for f-cpu@seul.org; Tue, 19 Mar 2002 05:07:40 +0100 Message-ID: <001c01c1cef1$1a65bd80$f3d3c2d4@ifurita> From: "Christophe" To: References: <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> <20020318215339.47919@thrai.stud.uni-hannover.de> <000201c1ced2$12537d40$b4e4c2d4@ifurita> <20020319022617.12493@thrai.stud.uni-hannover.de> Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) Date: Tue, 19 Mar 2002 03:52:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Tuesday, March 19, 2002 2:26 AM Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) > Without conflict, best case: > > time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > CPU A R--------------W > CPU B R--------------W Sorry, it should be : CPU A CR--------------W CPU B CR--------------W > With conflict (first write attempt on CPU B fails), worst case: > CPU A R--------------W CPU B R--------------R--------------W That's true. > The final (succeeding) operations, counted from the initial read, will > never overlap. The same is true for the spinlock variant, except that > the `worst case' situation is much better (less delay in case of > failure): > > Spinlock, worst case: > > time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > CPU A LR--------------WU > CPU B LR--------------WU > I don't agree on one point : if you use a CAS for spinlock so we have something like it : CPU A L-----R-------------------WU CPU B L-----L-----L-----L-----L-----R------------------>WU So it is an illusion to think spinlock is shorter in worst case because you forget that L (locking) is in fact a CAS and so have the same default as CAS2 in worst case since CPU B read should not happen until CPU A unlocks ! But anyway preemption-safe locking and non-blocking (free-lock) primitives are those who give best results, so I think we nearly agree indeed. > The letters mean: R(ead), W(rite), L(ock), U(nlock) > > [...] > > By the way if you don't call this > > with_cas in an eternal loop so your statement "repeat indefinite times" becomes > > false, because there is a time when a processor hits, it wouldn't be back until > > a very long moment (at least I hope so!) so it should not be any longer a > > possible contention for other processors waiting for their hits. > > Things like push/pop operations on a stack happen all the time, not once > in a millenium :) Do you think to use push and pop a billion times per second !? I don't think so. Allocation and releasing ressources shared between processors and tasks should not be done a billion times per second. We should not abuse the synchronisation if not necessary. > > But okay, if long_computation is undeterministic, I wouldn't use CAS nor CAS2 ! > > I wouldn't use a spinlock either, then. Never block if you have no idea > how long the block will persist. So we are definately blocked :) > > Anyway, using CAS shouldn't be a thing which occurs at 99% of running code, so > > such a situation should be avoided. > > > > > Note that this does not mean that I don't like CAS. Au contraire -- we > > > definitely need an atomic read-modify-write operation, and this one > > > looks pretty good to me, although it doesn't solve all problems. > > > > Of course, it doesn't solve all problems. But I prefer them to semaphores when > > possible. > > Semaphores are slightly different, and usually not present in hardware. > When a task requests a semaphore that is in use, it is suspended (there > will be a task switch). As soon as the semaphore is freed, the first > process waiting for it is woken up, or maybe all of them, and probably > another task switch is performed. Yes I know, it is why I asked for Yann not to use the semaphore term which leads to a misunderstanding since F-CPU has no way to determine hardwardly which tasks to stop or wake up. > A simple semaphore can be written using CAS: > > down(struct sem *sem) { > while (!CAS(&sem->count, 1, 0)) { > wait_on_semaphore(sem); // does a task switch > /* we come back here when the task is woken up again */ > } > } Not a semaphore for me but a mutex indeed :). Oh by the way, what happens if a task switch occurs just before wait_on_semaphore and another task releases this mutex ? :) > > up(struct sem *sem) { > sem->count = 1; > } !? How do you wake up tasks waiting for mutex releasing !? > A real semaphore (with an initial count > 1) is a little harder... > We'd need another instruction in order to implement that efficiently, > like `atomic test-for-zero-and-decrement-otherwise'. something like : int test_and_dec (int *counter) { do { old = *counter; if (!old) return old; } while (! CAS (counter,old,old-1)); return old; } I suppose ? well, it is not enough too... for the same reason as in mutex. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 03:56:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOL-00071g-00 for ; Tue, 19 Mar 2002 09:54:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:49 +0100 (CET) Received: (qmail 23207 invoked by uid 0); 19 Mar 2002 04:12:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 19 Mar 2002 04:12:05 -0000 Received: by moria.seul.org (Postfix) id BB8221468ED; Mon, 18 Mar 2002 23:12:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 981B81468F3; Mon, 18 Mar 2002 23:12:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 3FADC1468ED for ; Mon, 18 Mar 2002 23:12:03 -0500 (EST) Received: from ifurita (212.194.211.243) by mail.laposte.net (5.5.044) id 3C9101C800044ECA for f-cpu@seul.org; Tue, 19 Mar 2002 05:12:02 +0100 Message-ID: <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita> From: "Christophe" To: References: <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> <3C96A1DE.6EBF899A@f-cpu.org> Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) Date: Tue, 19 Mar 2002 03:56:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well there is a lot of missing things in VHDL source so it would be quite difficult for me to do something since I don't have the slight idea of implementation you want to make, especially regarding with memory. And please don't forget, I'm a programmer, not a VHDL guru. I can read VHDL but don't think for you. If you want me to do something I first need more materials than I can find in your source to be able to figure out how to proceed (a lot of details about the implementation of your F-CPU sound fuzzy to my ears for the moment). ----- Original Message ----- From: Yann Guidon To: Sent: Tuesday, March 19, 2002 3:26 AM Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) > hi, > > Michael Riepe wrote: > > On Mon, Mar 18, 2002 at 10:32:10PM +0100, Christophe wrote: > > [...] > > > I think to have a single CAS is a minimum. To have a CAS2 can really boost > > > compared with its software implementation. But, ok, let us first to try to have > > > an efficient CAS. Afterward we can try the impossible :-) > > > > That comes second. First, let's build something that *works*. > > i like you more and more, Michael :-P > > i don't like to read "we can try the impossible :-)" Oh come on. I really know it is very difficult but I would wait to see how we can code a CAS before deciding if a CAS2 cannot be done. That's all. Yourself you said : "impossible is not french". Anyway, I'm not speaking about to have an instruction CAS2 but something like two CAS linked IF IT IS POSSIBLE. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 04:00:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOM-00071g-00 for ; Tue, 19 Mar 2002 09:54:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:50 +0100 (CET) Received: (qmail 23461 invoked by uid 0); 19 Mar 2002 04:15:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Mar 2002 04:15:20 -0000 Received: by moria.seul.org (Postfix) id E2A5A146823; Mon, 18 Mar 2002 23:15:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCF171468EF; Mon, 18 Mar 2002 23:15:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 987CC146823 for ; Mon, 18 Mar 2002 23:15:18 -0500 (EST) Received: from ifurita (212.194.211.243) by mail.laposte.net (5.5.044) id 3C9101C800044EFE for f-cpu@seul.org; Tue, 19 Mar 2002 05:15:18 +0100 Message-ID: <002701c1cef2$2b76d4a0$f3d3c2d4@ifurita> From: "Christophe" To: References: <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <3C95D275.A52926C3@f-cpu.org> <001701c1ce7c$0a85ec20$6f9b2cd5@ifurita> <20020318215339.47919@thrai.stud.uni-hannover.de> <000201c1ced2$12537d40$b4e4c2d4@ifurita> <20020319022617.12493@thrai.stud.uni-hannover.de> <3C96B054.622E9E83@f-cpu.org> Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) Date: Tue, 19 Mar 2002 04:00:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yes, that's true. Load_lock and store_conditional is another way to have the CAS capability. I don't know if a CAS is easier to implement than a pair ll/sc. > > A real semaphore (with an initial count > 1) is a little harder... > > We'd need another instruction in order to implement that efficiently, > > like `atomic test-for-zero-and-decrement-otherwise'. > > using load_lock and store_conditional, it's easy : just do a substraction > with saturation, instead of the xor in my latest example. that's all. voilà. > > > Michael "Tired" Riepe > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Mar 19 09:05:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFON-00071g-00 for ; Tue, 19 Mar 2002 09:54:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:51 +0100 (CET) Received: (qmail 31323 invoked by uid 0); 19 Mar 2002 08:01:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 19 Mar 2002 08:01:58 -0000 Received: by moria.seul.org (Postfix) id DF030146807; Tue, 19 Mar 2002 03:01:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D964A1468F4; Tue, 19 Mar 2002 03:01:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 1ED71146807 for ; Tue, 19 Mar 2002 03:01:54 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16nEcA-0001dj-00 for f-cpu@seul.org; Tue, 19 Mar 2002 09:05:02 +0100 Date: Tue, 19 Mar 2002 09:05:02 +0100 (MET) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) In-Reply-To: <20020318201514.06861@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 18 Mar 2002, Michael Riepe wrote: > On Mon, Mar 18, 2002 at 12:41:41PM +0100, Yann Guidon wrote: > > hello, > > > > Christophe wrote: > > > > We could easily do this kind of operation in hardware, btw. > > > Oh fine. > > > > just a question : "how" ? > > repeat > pull the requested memory location into the cache > make the executing CPU the owner of the cache line (SMP) Ain't that exactly the problem? How do you become exclusive owner? > read data and compare > if (the line is still valid and owned by us) > if (the result was true) > write data > end if > return (result) > end if > end repeat JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 19 03:29:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nFOH-00071g-00 for ; Tue, 19 Mar 2002 09:54:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 09:54:45 +0100 (CET) Received: (qmail 15293 invoked by uid 0); 19 Mar 2002 02:23:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Mar 2002 02:23:42 -0000 Received: by moria.seul.org (Postfix) id 389D71468F3; Mon, 18 Mar 2002 21:23:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 143F71468F6; Mon, 18 Mar 2002 21:23:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id AB2181468F3 for ; Mon, 18 Mar 2002 21:23:40 -0500 (EST) Received: from f-cpu.org (kdl11-3.n.club-internet.fr [213.44.9.3]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 4B121168F for ; Tue, 19 Mar 2002 03:23:37 +0100 (CET) Message-ID: <3C96A288.4D0EDB4@f-cpu.org> Date: Tue, 19 Mar 2002 03:29:28 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] CAS in FC0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Christophe wrote : > > I do not doubt that what you say is true, here. the problem > > is still : "how do you think it can be implemented in the existing framework" ? > I'm sure you would find a solution if you wanted to storm your brain ;-). i do not like this kind of answer, even though i know this is humorous (and we lack from it here). The allusion that i'm not doing my best to find a solution is a lie and i hope everybody notice the smiley. Come on : you and others ask for something, debate from it etc. But nothing "more". You speak about "simple state machines" and other abstract things and you take its realisation as granted, no plan, no code, just words. If you rely on me for finding solutions to YOUR problems, we won't get very far. i'm a bit tired from being the "F-CPU man" and this kind of behaviour doesn't help. The rule is usually : if you want something, you have to find the solution, not ask others to do the dirty work, otherwise it's not fair and too easy for those who add bells and whistles at no effort. But you're lucky this time. As if i had no late work for the university and not enough work on the F-CPU VHDL source code, manual and utilities (i just finished a first version of FROMFS and started rebuilding YGASM).... ° ° °° °°°° °° °° °°°° °° °° °° ° °°° °° ° ° I have to read and reread what Christophe has already written (thank you for your patience). I may have a beginning of a solution for the CAS (not CAS2) instruction in F-CPU and the implementation in FC0. However it is (still) ugly and has some drawbacks. **** Concerning the format : It must be an "optional" opcode because it requires some specific fields (using R1 as an operand fetched from the register set). here is a copy/paste of one of your posts : _______________________________________________________ cas r1,r2,[r3] : IN : r1 : requested value, r2 : new value, r3 : pointer OUT : r1 : new requested value, r2 : 0 if CAS successes _______________________________________________________ this should more look like _______________________________________________________ cas r1,[r2],r3 : IN : r1 : requested value, r2 : pointer, r3 : new value OUT : r3 : new requested value, r2 : 0 if CAS successes _______________________________________________________ - the pointer must be in the middle - the main destination register must be on the right (we have the choice of using r1 and r3 (load format), or r3 and r3^1 (standard format)) **** Concerning the scheduling : if CAS becomes an instruction, it is pipelined. This means that there is a "schedule" for each operation. For CAS, there is a problem : ALL WRITES occur during the 5th cycle of the pipeline (after the instruction was decoded). It makes things easier and there is nothing to worry about. But with a CAS, there is a read then a write, so the write cycles occurs several cycles later ! So the scheduler must be modified to verify that no store instruction enters the pipeline when CAS is finishing. Nothing impossible here but it adds yet another condition to check and the instruction issue logic is already pretty fat :-/ OTOH there is only one pointer and it requires only one check during the first cycles, so the "late" store is not "much dangerous" (as long as CAS is the only exception to the rule). You describe it like this : > READ: > - read the actual value in memory location. In fact it works like this : - decode opcode + register read + check pointer validity - Xbar + issue + LSU read - At this point, there is a problem : the register's value must now enter the execution units but the LSU has not yet aligned and shifted the 256-bit line, so the 2 operands have not entered the pipeline at the same time : HEADACHE #1 ! There is no clean solution to this problem. Adding a delay is not a good thing. reducing the LSU depth will slow down the clock. h*l* sh*t. > MODIFY: > - if the actual value equals to the requested value, set the requested value > with the new value else set the requested value with the actual value > - new value is set to true if it equals to requested value. Usually this would be done in the (extended) INC unit, where an unsigned comparison can be performed and a MUX can be switched from the result (min/max instruction, but not yet implemented). But here the dataflow is a bit different because one operand of the swap is not the operand of the comparison. > WRITE: > - write the requested value in memory location. So the result of the CAS operation goes to Xbar, then to the R7 and LSU shifter, and finally (if validated) the last cycle is a LSU write. I don't think it's impossible but it's a smelling worm can. ° ° °° °°°° °° °° °°°° °° °° °° ° °°° °° ° ° **** Concerning data locking : In the pipelined (and hypothetical) example, the write occurs depending on the result of the comparison and the possible access to our local memory was not addressed. Now, i will examine the conditions that interrupt the write-back : - IRQ or trap : in this case, the CAS instruction continues its way through the pipeline. It finishes soon enough to avoid any interference with the IRQ routine's code (or so i hope). - Another CPU writes to the currently used LSU line. Or worse ! our own code makes a write to the same location, an hypothetical code like : CAS r3,[r1],r4 store [r1],r2 As we know, the store will complete before CAS. But in the general case, the CAS must fail when the line that is pointed to by [r1] is modified since the read. This is nothing more than the "dirty" flag, but in practice we need a "real" dedicated flag anyway because each LSU byte can have a lot of "dirty" bits already on, as the result of normal operation. More generally : the "lock" flag of the pointed line is set when we read, and it is reset when _any_ write occurs. Not difficult to do. So here i point this fact : there is a way to perform CAS (and other "locked" operations) without a "flag" (like what nicO said) but a collection of flags, one per LSU line. This is important because it allows several simultaneous locks to be done at a time. It is not a bottleneck either, as would a single "flag" be (remember : "whygee's scalability rants"). It is another "hidden" flag that depends on the implemented HW and the theoretical limit is the number of registers itself (if there is one day a version which can have 63 pointers at a time). I would have liked something better but it's already a win. However, if we "lock" the LSU line, there is a problem : only one CAS can occur at a time in a LSU line. This means that a large part of the line is wasted, unless there are other read-only variables in the same line (during the lifelength of the CAS). Those who don't like this can modify the source and increase the LSU complexity (and decrease the clock speed), those who put several CAS variables in the same line can either enter in a deadlock (in the worst case) or read the manual (you get what you pay for). That said, and by remembering that the I/O interface is connected only to the LSU/fetcher, you get the picture : if a CPU writes data to the same LSU line as this of the "reserved" line, CAS will fail to write back. Simple, doable with existing gates, and it validates my architecture (no need for MESI, LSU is connected to L1, L2, SDRAM and I/O). ° ° °° °°°° °° °° °°°° °° °° °° ° °°° °° ° ° Now that we can "tag" the LSU lines, there is still the scheduling problem. in fact, the real problem is to think of CAS as an "instruction". Things become _so_easy_ if we use a combination of instructions !!! We do not need any "CAS instruction" but a variant of the usual load and store instructions, just like the locked versions in ALPHA (and other CPUs). * "load locked" will "tag" the line it selected for reading. it's just a bit that the issue logic has to set after decoding the instruction. * "store conditional" will proceed if two conditions are met : the specified condition is true (we can check for LSB, MSB, zero...) and the "tag" is still set. I often wondered if it was worth it to add a conditional store, but now i'm convinced. Except that we need a version that checks the "tag". What about the scheduling ? it's almost as fast, if there are all the bypass networks ! load_tag [r1],r2 xor r2,r3,r4 if r4==0 store_locked [r1],r3 (or something like that) >>From the scheduling point of view, there is no change to the existing structure :-) and it executes as fast as a single instruction because there are bypass nets. You can also check whatever condition you want, not only egality but superiority or any funky stuff. I am not sure it's possible to do a CAS2 with that, simply because it's not possible to check 2 pointers at a time in a single cycle (because the instructions are not decoded at the same time). ° ° °° °°°° °° °° °°°° °° °° °° ° °°° °° ° ° The previous code is interruptible, nice, i hope you like it. But i still have to find how an external device can do a store_locked in another CPU's LSU :-/ Because it is where things become REALLY annoying and you wish there was a central mailbox, as i proposed before. I hope that Christophe will let me explain that when i find time to do it. enough babbling, good night. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 19 11:02:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPfq-0005hT-00 for ; Tue, 19 Mar 2002 20:53:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:34 +0100 (CET) Received: (qmail 15672 invoked by uid 0); 19 Mar 2002 10:02:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Mar 2002 10:02:39 -0000 Received: by moria.seul.org (Postfix) id AC7E8146812; Tue, 19 Mar 2002 05:02:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8D80F1468D8; Tue, 19 Mar 2002 05:02:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 6723B146812 for ; Tue, 19 Mar 2002 05:02:36 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203191002.0871; Tue, 19 Mar 2002 10:02:08 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: spinlocks (was Re: [f-cpu] another DATE report) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2002 10:02:08 GMT Message-id: <200203191002.0871@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 19/03/02 Objet: Re: spinlocks (was Re: [f-cpu] another DATE report) On Mon, 18 Mar 2002, Michael Riepe wrote: > On Mon, Mar 18, 2002 at 12:41:41PM +0100, Yann Guidon wrot= e: > > hello, > >=20 > > Christophe wrote: > > > > We could easily do this kind of operation in hardwar= e, btw. > > > Oh fine. > >=20 > > just a question : "how" ? >=20 > repeat > pull the requested memory location into the cache > make the executing CPU the owner of the cache line (SMP) Ain't that exactly the problem? How do you become exclusive = owner? >>> Thats why the bus that we used must have CAS2 cycle and = there is no more problem. Shared or not shared data information should o= nly be used to manage caches. nicO > read data and compare > if (the line is still valid and owned by us) > if (the result was true) > write data > end if > return (result) > end if > end repeat JG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 10:36:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPft-0005hT-00 for ; Tue, 19 Mar 2002 20:53:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:37 +0100 (CET) Received: (qmail 15539 invoked by uid 0); 19 Mar 2002 10:51:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 19 Mar 2002 10:51:55 -0000 Received: by moria.seul.org (Postfix) id 903AC1467F4; Tue, 19 Mar 2002 05:51:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7FD301468DE; Tue, 19 Mar 2002 05:51:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 3DFE01467F4 for ; Tue, 19 Mar 2002 05:51:54 -0500 (EST) Received: from ifurita (213.44.157.145) by mail.laposte.net (5.5.044) id 3C9101F20004B93C for f-cpu@seul.org; Tue, 19 Mar 2002 11:51:53 +0100 Message-ID: <001c01c1cf29$9e5d2dc0$919d2cd5@ifurita> From: "Christophe" To: Subject: [f-cpu] Emulator with System C Date: Tue, 19 Mar 2002 10:36:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Well, in a monolisthic kernel where we have two rings : user and kernel, we can have such a flag when in kernel mode to prevent any preemptive task switch. But, what happens if an IRQ wants to access a shared ressource locked by a spinlock ? it sounds very bad. With a CAS or a CAS2, it would always hit the first time (except if another IRQ wanting to access the same ressource is nested) and have access on ressource. The interrupted code will just have to retry because - after all - IRQ was more prioritized. For user code, there is no way to disable interrupts because it is considered as a kernel priviledge to do so. So the spinlock cannot be fairly handled without using a kernel trap. Of course, we can use a flag for temporally disabling task switch (i.e, our scheduler first checks this flag is off before switching another task. It sounds like a useless overhead when flag is set). For operating systems which use 99,9% user code and reduce at maximum the usage of kernel code for critical part, it becomes a nightmare. That's why, I prefer to avoid spinlocks if possible. Ok, let us forget all those details... I'm really impatient that you advanced in your VHDL source. It would be easier for me to understand anything if those damned VHDL sources are really written. I was planning to do an emulator with System C but I lack a lot of details about implementation. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 19 13:06:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPfx-0005hT-00 for ; Tue, 19 Mar 2002 20:53:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:41 +0100 (CET) Received: (qmail 3269 invoked by uid 0); 19 Mar 2002 12:06:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Mar 2002 12:06:15 -0000 Received: by moria.seul.org (Postfix) id 419161468D8; Tue, 19 Mar 2002 07:06:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3C6341468E0; Tue, 19 Mar 2002 07:06:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 8315A1468D8 for ; Tue, 19 Mar 2002 07:06:13 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203191206.06e3; Tue, 19 Mar 2002 12:06:06 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Emulator with System C From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2002 12:06:06 GMT Message-id: <200203191206.06e3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: "Christophe" A: Date: 19/03/02 Objet: [f-cpu] Emulator with System C I was planning to do an emulator with System C but I lack a = lot of details about implementation. >>I'll be curious to help you ! I don't have enought patient= to look more precisely [code] using system C but i'm glade to imple= ment "my" version of the scheduler (the thing that decide if the instr= uction could start). nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 19 16:14:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPg6-0005hT-00 for ; Tue, 19 Mar 2002 20:53:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:50 +0100 (CET) Received: (qmail 25270 invoked by uid 0); 19 Mar 2002 15:08:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 19 Mar 2002 15:08:37 -0000 Received: by moria.seul.org (Postfix) id 5B76F146930; Tue, 19 Mar 2002 10:08:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F3FE146932; Tue, 19 Mar 2002 10:08:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E1379146930 for ; Tue, 19 Mar 2002 10:08:34 -0500 (EST) Received: from f-cpu.org (kdl16-109.n.club-internet.fr [213.44.18.109]) by relay-4v.club-internet.fr (Postfix) with ESMTP id C460D16DF for ; Tue, 19 Mar 2002 16:08:31 +0100 (CET) Message-ID: <3C9755D0.78F835CF@f-cpu.org> Date: Tue, 19 Mar 2002 16:14:24 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <3C963E37.FDD3313B@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > Michael Riepe a écrit : > > > > On Mon, Mar 18, 2002 at 03:49:07AM +0100, Christophe wrote: > > [...] > > > well, there is a problem with the spinlock version : what happens if a task > > > switch occurs between the locking and the unlocking ? especially if other tasks > > > will try to acquire the same spinlock, they all shall be blocked until the > > > owner task may release the spinlock, which - not speaking about the invert > > > priority problem of tasks - is in fact a real degradation. Such a thing cannot > > > happen with CAS2 because the first to be serviced is the first to write, not > > > the first to read - the other tasks would just need a retry - which takes > > > basically less time to execute than waiting for owner task to unlock. > > > > A spinlock protected piece of code should be as short as possible, and > > not contain blocking functions at all. Spinlocks are just a way to make a > > sequence of simple instructions atomic -- like the update operations in > > the stack example, or a software implementation of CAS2 (which would be > > too heavy as a machine instruction -- remember that it has six operands). > > > > This instruction are used inside PowerPC. ??? i thought it was the locked load / conditional store. > Maybe it's possible to "link" > few instructions together to defined a CAS2 operation. not possible in a single issue processor. > Imagine a flag set, if something happen between the fetch, CAS2 are canceled. CAS2 requires 2 writes, and if there is only one instruction per cycle, there is a risk of being interrupted between the 2 consecutive instructions. > I know it > look like CISC but here the state machine is simple : if the 3 or 4 > instructions or fetch one after an other the CAS2 op are made on the bus > (never forget that we need this type of cycle for our internal bus), if > something else happen it's cancelled, if the fetch begin in the "middle" > of the 3 instructions (as after a switch) nothing happen. I thing it > simple, no ? if it's so simple, "just do it". > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Mar 19 16:54:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPg9-0005hT-01 for ; Tue, 19 Mar 2002 20:53:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:53 +0100 (CET) Received: (qmail 18741 invoked by uid 0); 19 Mar 2002 15:57:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Mar 2002 15:57:31 -0000 Received: by moria.seul.org (Postfix) id 43B7914693F; Tue, 19 Mar 2002 10:57:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29B93146941; Tue, 19 Mar 2002 10:57:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 7E1A914693F for ; Tue, 19 Mar 2002 10:57:29 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-214.jetnet.ab.ca [207.34.60.214]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id IAA12025 for ; Tue, 19 Mar 2002 08:57:25 -0700 (MST) Message-ID: <3C975F50.F9657AF2@jetnet.ab.ca> Date: Tue, 19 Mar 2002 08:54:56 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Emulator with System C References: <001c01c1cf29$9e5d2dc0$919d2cd5@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > Well, in a monolisthic kernel where we have two rings : user and kernel, we can > have such a flag when in kernel mode to prevent any preemptive task switch. > But, what happens if an IRQ wants to access a shared ressource locked by a > spinlock ? it sounds very bad. With a CAS or a CAS2, it would always hit the > first time (except if another IRQ wanting to access the same ressource is > nested) and have access on ressource. The interrupted code will just have to > retry because - after all - IRQ was more prioritized. > > For user code, there is no way to disable interrupts because it is considered > as a kernel priviledge to do so. So the spinlock cannot be fairly handled > without using a kernel trap. Of course, we can use a flag for temporally > disabling task switch (i.e, our scheduler first checks this flag is off before > switching another task. It sounds like a useless overhead when flag is set). The problem is the IRQ service has become a catch all for stuff. With buffering now days lets just delete it and solve all the problems and go back to polled I/O. BTW the really old computers like the IBM 1130 had a keyboard lockout so you could not press a key until the computer 'unlocked' the keyboard. Could not some hardware IRQ's like timer ticks have lower priority than the CAS instructions? I remember reading about one old machine , interrupts were only allowed after a successful branch instruction. Good system design here is needed and not having software do all the work. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Mar 19 17:13:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPgA-0005hT-00 for ; Tue, 19 Mar 2002 20:53:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:54 +0100 (CET) Received: (qmail 16481 invoked by uid 0); 19 Mar 2002 16:10:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 19 Mar 2002 16:10:19 -0000 Received: by moria.seul.org (Postfix) id B3288146946; Tue, 19 Mar 2002 11:10:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF159146949; Tue, 19 Mar 2002 11:10:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 1DC38146946 for ; Tue, 19 Mar 2002 11:10:17 -0500 (EST) Received: (qmail 28424 invoked by uid 85); 19 Mar 2002 16:12:21 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.33739 secs); 19 Mar 2002 16:12:21 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 19 Mar 2002 16:12:21 -0000 Message-ID: <3C9763A8.1020800@yahoo.fr> Date: Tue, 19 Mar 2002 17:13:28 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Emulator with System C References: <200203191206.06e3@th00.opsion.fr> Content-Type: multipart/alternative; boundary="------------050607040703020004030707" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------050607040703020004030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Which type of details you are looking for ? Nicolas Boulay wrote: >-----Message d'origine----- >De: "Christophe" >A: >Date: 19/03/02 >Objet: [f-cpu] Emulator with System C > >I was planning to do an emulator with System C but I lack a lot of >details >about implementation. > >>>I'll be curious to help you ! I don't have enought patient to look >>> >more precisely [code] using system C but i'm glade to implement "my" >version of the scheduler (the thing that decide if the instruction could >start). >nicO > > >______________________________________________________________________________ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > --------------050607040703020004030707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Which type of  details you are looking for ?

Nicolas Boulay wrote:
-----Message d'origine-----
De: "Christophe" <christophe.avoinne@laposte.net>
A: <f-cpu@seul.org>
Date: 19/03/02
Objet: [f-cpu] Emulator with System C

I was planning to do an emulator with System C but I lack a lot of
details
about implementation.

I'll be curious to help you ! I don't have enought patient to look
more precisely [code] using system C but  i'm glade to implement "my"
version of the scheduler (the thing that decide if the instruction could
start).
nicO

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


--------------050607040703020004030707-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 11:52:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPgB-0005hT-01 for ; Tue, 19 Mar 2002 20:53:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:55 +0100 (CET) Received: (qmail 11796 invoked by uid 0); 19 Mar 2002 18:19:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 19 Mar 2002 18:19:50 -0000 Received: by moria.seul.org (Postfix) id 7BE921462FD; Tue, 19 Mar 2002 13:19:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7506E1467ED; Tue, 19 Mar 2002 13:19:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id F26361462FD for ; Tue, 19 Mar 2002 13:19:45 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00510; Tue, 19 Mar 2002 11:52:30 +0100 Message-ID: <20020319115230.30983@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 11:52:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: spinlocks (was Re: [f-cpu] another DATE report) References: <20020318201514.06861@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Tue, Mar 19, 2002 at 09:05:02AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 09:05:02AM +0100, Juergen Goeritz wrote: > On Mon, 18 Mar 2002, Michael Riepe wrote: > > > On Mon, Mar 18, 2002 at 12:41:41PM +0100, Yann Guidon wrote: > > > hello, > > > > > > Christophe wrote: > > > > > We could easily do this kind of operation in hardware, btw. > > > > Oh fine. > > > > > > just a question : "how" ? > > > > repeat > > pull the requested memory location into the cache > > make the executing CPU the owner of the cache line (SMP) > > Ain't that exactly the problem? How do you become exclusive owner? Cache coherency protocol. (talking MESI now) After thinking it over, I guess it's not necessary to get the line into E state. The only thing we have to check for is whether another CPU modified the cache line behind our back (which invalidates our copy). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 12:04:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPgC-0005hT-00 for ; Tue, 19 Mar 2002 20:53:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:56 +0100 (CET) Received: (qmail 21142 invoked by uid 0); 19 Mar 2002 18:19:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 19 Mar 2002 18:19:50 -0000 Received: by moria.seul.org (Postfix) id 5C9201467F3; Tue, 19 Mar 2002 13:19:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A2BC1467F1; Tue, 19 Mar 2002 13:19:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id D5C7D1467ED for ; Tue, 19 Mar 2002 13:19:47 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00539; Tue, 19 Mar 2002 12:04:31 +0100 Message-ID: <20020319120431.34391@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 12:04:31 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> <3C96A1DE.6EBF899A@f-cpu.org> <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita>; from Christophe on Tue, Mar 19, 2002 at 03:56:47AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 03:56:47AM +0100, Christophe wrote: > Well there is a lot of missing things in VHDL source so it would be quite > difficult for me to do something since I don't have the slight idea of > implementation you want to make, especially regarding with memory. And please > don't forget, I'm a programmer, not a VHDL guru. I can read VHDL but don't > think for you. If you want me to do something I first need more materials than > I can find in your source to be able to figure out how to proceed (a lot of > details about the implementation of your F-CPU sound fuzzy to my ears for the > moment). Please go ahead... which details? [...] > Anyway, I'm not speaking about to have an instruction CAS2 but something like > two CAS linked IF IT IS POSSIBLE. Since two CAS don't make a CAS2, that wouldn't make much sense. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 19 16:14:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nPg8-0005hT-00 for ; Tue, 19 Mar 2002 20:53:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 19 Mar 2002 20:53:52 +0100 (CET) Received: (qmail 31469 invoked by uid 0); 19 Mar 2002 15:08:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Mar 2002 15:08:43 -0000 Received: by moria.seul.org (Postfix) id 21BAB146934; Tue, 19 Mar 2002 10:08:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1EC9A146933; Tue, 19 Mar 2002 10:08:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C4750146931 for ; Tue, 19 Mar 2002 10:08:41 -0500 (EST) Received: from f-cpu.org (kdl16-109.n.club-internet.fr [213.44.18.109]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 6BC8A1774 for ; Tue, 19 Mar 2002 16:08:38 +0100 (CET) Message-ID: <3C9755D7.A06C75EC@f-cpu.org> Date: Tue, 19 Mar 2002 16:14:31 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <3C89385E.CE9CFC0D@seul.org> <3C89416B.2E7662E7@f-cpu.org> <3C93AB66.3379EA1@seul.org> <3C93FC20.643FDD74@f-cpu.org> <3C9477F5.F3A68CFF@seul.org> <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <3C963E37.FDD3313B@seul.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nico wrote: > > Michael Riepe a écrit : > > > > On Mon, Mar 18, 2002 at 03:49:07AM +0100, Christophe wrote: > > [...] > > > well, there is a problem with the spinlock version : what happens if a task > > > switch occurs between the locking and the unlocking ? especially if other tasks > > > will try to acquire the same spinlock, they all shall be blocked until the > > > owner task may release the spinlock, which - not speaking about the invert > > > priority problem of tasks - is in fact a real degradation. Such a thing cannot > > > happen with CAS2 because the first to be serviced is the first to write, not > > > the first to read - the other tasks would just need a retry - which takes > > > basically less time to execute than waiting for owner task to unlock. > > > > A spinlock protected piece of code should be as short as possible, and > > not contain blocking functions at all. Spinlocks are just a way to make a > > sequence of simple instructions atomic -- like the update operations in > > the stack example, or a software implementation of CAS2 (which would be > > too heavy as a machine instruction -- remember that it has six operands). > > > > This instruction are used inside PowerPC. Maybe it's possible to "link" > few instructions together to defined a CAS2 operation. Imagine a flag > set, if something happen between the fetch, CAS2 are canceled. I know it > look like CISC but here the state machine is simple : if the 3 or 4 > instructions or fetch one after an other the CAS2 op are made on the bus > (never forget that we need this type of cycle for our internal bus), if > something else happen it's cancelled, if the fetch begin in the "middle" > of the 3 instructions (as after a switch) nothing happen. I thing it > simple, no ? > > nicO > > > -- > > Michael "Tired" Riepe > > "All I wanna do is have a little fun before I die" > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ -- WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Mar 19 22:36:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nTEp-00087M-00 for ; Wed, 20 Mar 2002 00:41:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 00:41:55 +0100 (CET) Received: (qmail 10048 invoked by uid 0); 19 Mar 2002 21:19:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 19 Mar 2002 21:19:59 -0000 Received: by moria.seul.org (Postfix) id 273181467E9; Tue, 19 Mar 2002 16:19:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1B9301467FF; Tue, 19 Mar 2002 16:19:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 7AECD1467E9 for ; Tue, 19 Mar 2002 16:19:57 -0500 (EST) Received: from ikad54cl193 (nas-cbv-2-133-101.dial.proxad.net [62.147.133.101]) by postfix2-1.free.fr (Postfix) with SMTP id 470B4755 for ; Tue, 19 Mar 2002 22:19:52 +0100 (CET) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 19 Mar 2002 22:36:00 +0100 Date: Tue, 19 Mar 2002 22:36:00 +0100 From: Etienne LABARRE To: f-cpu english ML Subject: [f-cpu] vhdl code for R7 Message-ID: <20020319213600.GA170@free.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Excuse my poor english, it's not my first language (i'm french...) I'm currently coding the register set (R7 unit) for the f-cpu. I sent here my first version (with some YG remarks), and i whould like you to say your opinion. It works with Simili and Vanilla, but it's not perfect. It's only a valid model for simulation, and i think that we can perfect it. For example, the 5-blocks organisation of R7 is bit 00 to 07 = block 0 = 8 bits bit 08 to 15 = block 1 = 8 bits bit 16 to 31 = block 2 = 16 bits bit 32 to 47 = block 3 = 16 bits bit 48 to 63 = block 4 = 16 bits This organisation has no signification for me today if the registers aren't 64 bits wide. What's about if 128 bits ? add 4 16-bits blocks, or increase block width ? I'm not in f-cpu team for long time, and i don't understand all the subject... Etienne LABARRE --2B/JsCI69OhZNC5r Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="r7_el.tar.gz" Content-Transfer-Encoding: base64 H4sICCaklzwAA3I3X2VsLnRhcgDtPWtz2ziS8zX6FVhP1UTKyDZByXbGjqfWSewZV+V1irNz c49y0RJlcyNRLlKy4637UfeT9uv9i+vGGyRIUS8ns0NszcYCGo1Go9FoNIFG72Dn7mYw+m6T yaOet9/tfud5Hj3YO8B/Pcp/Q+p43QPvO++g29078OkBpQBPOwf73xFvo1SJNEunQULId9Hn YFAGF0+G0ShMH4Okx0zba0uN7W0y3O7fznZRoHaT8DpKp2GS7va4iJFt0jsg5Jj0RAn5GE7J cJKQ6U1IzrZfffiEKF5Nbh+S6PpmSpqvWsT3PJ+cTqMwjkPyJrgKkiQkzZBn7Ix4xl+vg8E/ dibJdQsRnCUReYtD+pz4/mFn75D+RF6dXjBUDUZmUXp5+sv5u+2//fr6zfab81en716dzu3w xU2Ukttkcp0EYwJ/DpMwJOlkOL0PkvCIPExmpB/EJAkH0OUkuppNQxJNSRAPdqHj48kgGj4g HsibxYOQ8wJ4M07JZMh+/PLuE/kljMMkGJEPs6tR1Cdvon4YpyEJoGnMSW/CAblieBgrkYaP ggZyNgHEwTSaxEckjKA8IXcwKvCb+LINgbBNJgkiaQZTpDwhk1us1wJyH8gomOqqOw1393Uv BySKGe6byS306AZQQh/vo9GIXIVklobD2aiNKACY/HZ+8ev7Txfk5N3v5LeTXu/k3cXvRwA8 vZlAaXgXclTR+HYUAWboVxLE0wcgHzG8Pe29+hWqnLw8f3N+8Tt0gpydX7w7/fiRnL3vkRPy 4aR3cf7q05uTHvnwqffh/cfTHQLCh2SFiKCExUM2SsDGQTgNolEqO/47DGwK1I0G5Ca4C2GA +2F0B7QFpA8CPH/wEEkwmsTXrJsArBl5RKIhiSfTNrlPIpCX6SQ/rEzQ1ci2yXnc32mTvZ/I RQhMCsmHUdCH8fw4QwSdjtcmLyfpFCHfnhDPp5Ru0453QD59PCmZENun715Xnw/bgjcwyz/F 0ZT9aU71Q9I7/eXy3ae3L097RKmHNmeA/A2/BvDzmHx6e/LviEJghNkdxFHKuksOZUsK3zYF jiVjYLOBWOH0UDbffXrzBmYJjFcykCw8DfpG0wAEczVI00k/4g3BMPbe/yZpvhpN+p/ZxLyK pqmg4QwkBGkFkve7rKBtExuljFSN5pjsMcGH+eB5OLowDsccOVB6DHoLsRAF8xxh6J6CoQpG gtB9BOlQBeLDX5Bp4en4CNTVbXUcQF3W2H5HAXVtICa2M5iXSfQPkPb+ZHwVxUGUTuKUNFPI g2k/xIHgimNoMgfrsqWfDKMknRLZURL0+2GaimLqkTTsT+JBQbGqLakyi8HQkLUdxVDq4UxL Bq7aWOoBxbME5M+JXLcNvMzWZshF265irC2SkBNdjBC/sbmODAtRKDn3Ads0mYyYeufa4HIc pJ9J05RKQMUWPugUzDGuM25hCYnSlOkGD3LjCenfBPF1iAqMnExB6IMB6HfQTFyBIN0R/pmS NLqOgxGQB2oPBvgWtTnH/+bjSyKKAWcKc/r+BnQzZsOkMOcRljWx8igCTc2nuBIPQe1bN7a3 y2Fj01thS0KFz0TEgEoxITJcGpLJPbdacESE8hfqaF2pwRb+uD+aDcBmmIJNAJqJjKKrJEii MG28OX/ZO+n9TqIwDI8anz6esr920ungcjS5jvqXlO53d07evDEK49k4TKAIgHaC0ejIauN6 NLkC7gzCYRSzsWad45aXbOx+knzm+PCvnTMouwTZGEbXvCUTX+/gEthEwngawWLcnICJxsS2 petzEF5t8H+qXag8ehrFMCpDWKfIAKykKOnDYgWq/fTdBa7ioPNBc17j4hn1mw0YYUAB3buC kUQNjA1hrjETCAp6MJ3hansIWvYoV0stDqQJLGwB/D45/hknpCphOMEQ/Hhx2rt88/4XG+c+ FreOGreTBERS4O/w2RQMEpzOWB96DTmXPOfSazsyqSvTJ08O0XDCMZ7xQb4L+9NJ0jRJgsVu MLmPceUAUmwikDCLBszIUMCyaD5LtI4219nl305fXbzvHTWeCPy+0CxWL7lKynbTyqXLd0k2 afaJ47Y7ZeTJ1jT9ChcqzpRJfFZF7pD3KLogfZBnSJbEjDWzrbE8Wtg1JZQFHdPE2Ip4R0AY 2qzN9Kv8G7QE05BC05k6moi6TKn1J2Dpw8wk2UXZHHW7YzqL5rP8Jbuq1hW5rAjMo/Tq0sMJ i9KmsR4ZxbS82C8uHpcjH5cjH5cjj2ejURl2Vl6CnpU78WuW4aKfYZjI5UOixszKpc7cvE45 yoBxic7h5Nn5+auqMxPlSbZYaMgQBLV3AJ06Sfo3gKgPOhSWuWg8u0RzfigUPO+ysSRJ3Z4S vuzMEiW2APiMJ3IXjCKYNvHoATdL2v5+ppOogf9MH3APeonbxgdm5eMfTanWE7SLyIufW9i2 yGR9BAJwWZ6yNebl+cVHGDOBpckMdy37LVwcGty8a3rt52263+747e7z9n63lUf28fw/TouR bVOGrinwydabtLWt/vZa7WyxbxTTfHHHKPbzxV2juJMv3jOKuy3Z1daRcwDF6EillpqDR35j GzyAkiosHmjmoLE3hUp9phv7kwQ21txM203DEf6tsBJjkDnm8+nTFDfObLt8FYKhPg5hqzKw 2P/y94vTS+/y/QecgXl11tU6DMdgi21Yto7yKOgiKKiXQfHb+97rxaigWSoYikWogB2KC4Vf HQXucVwoOpVRsE1WBsVrzYyKHcnx4rVmRiUqHB35N4YC+1ERhaJCyHF6582raYPTxcD9+eBi NjDDmlXSK4hAE2WVvhNp0ZpejMfdlzLbQCES6+mydIjldqXqbtYWV280rmC7INeknImj7Tq2 TfBYgyAdL44zlhcnBQQhW0JFiZ8r8Tn3+Mb1Dj0OqBWltpZ21YvjhnQ2ZDYCTWMFafENstKI 7fmVqFWJVqukWlITvUIl36pUsaWOVcmvVqlrVeos2KfXi3SqY9dalH9SR7UbT0hReuo95cAT 9PWnlrhQp7jQYnGhy4gLXUZcXC3N5SxdRlzoMuJClxEXV5/mi4uLvvni4mprVXHxneLiF4uL v4y4+MuIi6uluZz1lxEXfxlx8ZcRF1ef5ouLi7754uJqa1VxyS9G48qLEWxt6BLLkZ+pVlGh GtUW0952tYqtdTPVKi5Le5lqFRcmg8iFlqa9bL2KvTPqVRGgRReoceUFahERosuJkLvaYhq9 ugjR5USILidCbiIXWq4WEiF3vdVFKL9ojSsvWouIkL+cCLmrLablq4uQv5wI+cuJkJvIhZaw hUTIXW91EcovZGKPasqQ3LjC+lksMQqoTD5MINg4Atm5ai4WKiC/RBoUUKdk7BVQt2Skzf7m qczk+GVjb9KUqdctG/tFKcjkFLfmkpjFVinhhHDIB60iH7SKfNBcL2kV+aBV5INWkQ9aRT5o bnRcdFeRD5obMVpJPipTkMkpbm1R+cgvQcLL5JAPv4p8+FXkw8/10q8iH34V+fCryIdfRT78 3Oi46K4iH35uxPxK8lGZgkxOcWuV5QMPKwafQzKE+vpcCjupgpJjHGUQRyvw0+4kDuNpyj4M Q9blaDK5JYfMxRjhhzenl5KwcxPBNGw0ZN8zft9m1BK+xaxDGBDjN5TM12+APyrARYtwUTcu ynAJZNilGPojDpHwfusxE+c/yDi4bepcwj9M/Xb++uJXPL8hP6kBYjEGeDIQD29goXHMgBe2 NCbmoGXIn0hqjF0Oq16w74l+RGtRclxntyQJNi6aw0WXxuXncPnVcGlk5jEKgc3MWpA06wBG DtsiHc10V54sMTusT5s4YakDlhbA+g5YP8+mDBXZQy9uaOqCxi/0lhhjNfvLvqiW+dw/pxZ1 1aLzavmuWn6mlu5eVlFAZZdaaRfVoK4alNXI0SkMblZBWGtRq+0GowYYLQbzDTCft6oJZUcZ BDfY+R+uKJjKw5MMUp+C3oKf8P9f+97GutIgHM++bPgKUPn9H2+P/S3v/3T2AN73O/X9n0dJ azzOiofhgUXuS0Bazsg2eQ0/RtPodhR+AfsHTRlWp77+U1//qa///NGv/2QmdzIZE//Zs5hd YhGXfWLyM6Hlk3HR9GiH6V9bJ91AqYmtS0PsYJiiEycb5el1canJPkkurAt9khwSq3wZxbcg 98R17FLBiNNwDMZxdoU1mDv1omrDvMImskdQZW0Yr3kI2K42S6IAEac/GSQwjXMt7SfRrYNt QeZ4KIovQCg2iqM2iHocRPElzJI+tIv/gEVNmiY9bZOBbYtTLYaL03cHIhFcQTtTmFOXVwFM dNaTaXgdJkdOIDmACigLxdtCWOI+QKaY2nrm5/gq+iiQmmQdw+QxxkMNg0kVwCiCNB1NhYad WDM4o4CVE4EdQJVDjh4GbUIjzN8VjG5215egzFSOhha70SVwzJwgMDCx8ou4qNvWOH/8e4sQ TawNB4VHVRHt+ohKIZI+GFY7HIH6XQ7P8gRlemYTBHMlGuIP/AtZeoRbE1sK9K9tYxCOJJyS BP3rmS9lxUDrGndjtttDb+oK4eMxuqkdQjZ+/CVm5xHfLH1tG7dOxWnzu7+5+7/uQbdj7P88 jP9w4Hfr/d9jpDVaYHL/l9n5Gfu+t/Wur9711bu+f8Vd39s/855vhR3fKnu57F5xwZ1cyUbQ 3sitsI2ruIkzNm2Pt2Vbw4ZtIXPasJxRHFSfCy3p3FbQK9j9iRbXvK8jRuojCfb2DgZHbn7Y h27c7LF0/DNxbJbsvZDofwbGf2ZuqThWug6sP9IsXuHAqIwXemds15AdbJNWacf2Y8Ud227x js2Yqy9cndQf1Bfcfsk4F5u0Mcvtfx/s/n0j/ts+s/87tf3/KGmNq3FR/DcVSmWbfAhg6cO7 30ZcqLXY/xezkNn/1Ce0e0j3D7vd2v6v7f/a/n8s+/8lLnS3cnofgGBjMB8WV4y8c8TfMYPB gcGhC34k+hcLg8JQfMQoJhYCNNrUITBBxIcEowOAnkhZiDjyvR0Vh8WJsuOtcGPAjrhBwNDi te0ANKw6z6hUn2DULQ7PoKb3ExHyiwQ8RkEajGVAnR3Cm+SaMYG+x//r8V7IRlkUr3A4xJOl uiuQfaz49D15NxGxrzgtPBNmZcgj3WGYIkZCG4RWkCtPyMjWPBTFAOcsBikzQ3GhakHIHRHA K4B919UDgfmmGQKCa9bFboK8BswQZd3gdZsvT2Genmb5uQMjzYhip3Bw2uNEQQSMaSIEEeuB iPt1DAac6AgLmqMC34iwgkDjgFPABuHqYfs2gBFQLQpyBOYpb5jEbcEslfEjdYyaoOGPuKeV bYAtyQ9nOBrJBANj+0D1S37eA1xiG2wE9NIbZiOgFzvSmg/qpQKCoM7YYafP9OlOawf9XIYb cWkUFtGLVRZnPzPhwKqF7sodPWy7cqkztzR6V+XAXZkzqO18HnXksbbdX3MVM+3miwN75U8+ tp3ZpaG9qkf1yp5HbTsyS5py904Kio6jlQnLgEsEMQ8btq2f1P7pszhH1QI2ccR6ZHGhwn+1 EkqiNAIjIBxchyz8TczPgwOM0No2pw5FcMg5CDiwhYEK7SX74ggilT9L6s4uCCPlOBiaq18a SEofvyyPJCXiCOajSaFSYTaHVC+i77bTTq1hPBggwuiITMoSeWJpDP/ZMyHIhaFVtEyJYJ7E iC2SncUiRbmp7Chg7F5U2o34ul8MHcrWYoBE1xsYtDFpDkfR7fZwNLltGQQDi9DHUN7uM8ts K4k9Yx4Cms8sHuBk9uXSW7J5Byq6PlT+mpgyCIvYYlo2BgV86vCv7quzxsS2LHdy6PrT0dpI Q1xrIyxzUimjd3LtKo/goUvHOyc+W12Go+A6zUwjbk4XLIxzIyIZB+CLyDaAaBUg39Erw/zX K63bF16gdqxOM/XKe57lIbHCWJnJ1ZjNGO1pZ7MRdJnzClSWOn0DijcEQ8g0j1GXx1mGbWqT qAB8Ek2rjaY+LDGwQ9cYAkurGdp2e/tnDL6sIdVnGSMGOTYVaRCVFAgtBNnZ2SmraElVBof+ S33rMdYZAa2BcCOAx+/Q1DDChxHugvYY/yN9XwsynZe1iLhQJaK5/yyN8sILWLKC8U0Laokl qckuDjlnfmTkwqBpJKK37M6HeYErsqDEpzdsKnfnSN0BMRhA/+gMoJUZQJ0M8P/oDPArM8C3 GWBeA7J1kVokxOSxNh2iaGJEGFbzFtWGUIyoNxtqlon1I8fiLH8dzJWcNdiqWJ1nLTZUsCjh Pa4cG43d0pN5EwiJwc9dslv02+8Wnd8tmu2W/+13y5/fLZ93S1k7EXPkbpk21JaUVeYfB1HX t5OxmsPoeiG+m6pSy87CUvqUt8mrLbaw60WL+6+A3nu1TxaFwnLOKi2WvV61ZR2sh3qW5b6o +rLuAYjRsu7nRhlQe2AzzhsLUrA/QyHPzSp8sVP4ytyja+YeXYR7dHnuydv+qPpFCyrGPPyL G/JwzB5SMS1H5n2XzvI22ITsu5B4vcMaF7bxKhwV98AUjo09PI4RKhwkRsaiQ1QwSjlPkg1c RcoLh0rrHt3jjKSz7ee3wdGFhb4SR+kCHKUrcNSylbRut6NgmC+2qP2Yso2aGDhC755aeYcu uQkw3Df7FQ2jvnhuiX9zugLCOJnSAFPRyNlnLMcXOEcL41k6xU/Xsi8D8b2P+SvxE/WU1RKB el2X5H9wjQJfEZ3BYjK78RfHxm38XOAGRsyWR7fahUBUAFHPBCJNPZawQrfyoUomiVyNxWGi po24ZeyM9bm7cHyb3/qrWMmQOIQ2C6yWytd9+0yaRMT+RbeiRZ3zSJ3gj+WpeMExqHv+6uQU wSjPXCDO8rIpTykY8tkW0GR2O0CpZ7r9IeeuF1DotFeTSPlrUrUNMBAZXyxyvn8DGzPm3Mg4 IjD3rjPD2eev9WTGiPnOpyzW/jBLOmE3vXTlp2wScAJ0HAW061r85pceMUD7KdsjXaqwZoJh cPFkqExdmg3UAuNobfOPdGwH+V4HJg6mMo80TnkJq5wgWpEgmiWIZgmiLoLowgT5FQnyswT5 WYJ8F0G+gyBrRHth7ok9NSfMt/ZUnZ63zGwnRDkCrMXP3GFoKq2Tk5bkiUlpeJOt7VSLfyph T36hAwzF2lqA+RuC7ME1hf11dZ9krlOvcVKaddmJXNea7ziTK2TCtMJM5uDB1SLhKGYp1gKm 2ruXDACIzhOiN6S8hqVXj7Kt5aTZRT/dDP05tGuiP7uyuKTPqGctL99MFJk0GkejaCe92WAb eP73YG+v6P6f19lT7z/7nsfiv3jdTn3+9zHS938hu1dRvHsVpDeNBh7TvSU7O7vW20u77Fiv fAaQHeX94Yf/EsDqet80TKeX6pcGMCK/MBDjtwZSZ4TlY9EMVP6QcKFqJJvFPUCZzN4BzLP+ zYRsbX0DM+3bTCafN9VG+fn/7p7vGef/97s4/7ugEur5/whpjScXi87/W1N5m1zAz6swhv2U fPsd5umcOwAnL096vdMF7gD4h373sFPfAa7vANR3AB7rDsBaT0Hb55zRlC4962wB5M474/wI v0zJ+e57BglSSM5PT08NVFgeTTi4BMH6Zj6gGU366K2cxX3+sKF9UlpS4X462SplT2Oecj+z UJD8CjEepx7fsrvFA1mSPfeIl20pEzWzpnT8xPhRQD+AaxTQogLfKtAlk1kBrsmMFlS5xxi/ lV7CMytUegtPnjVatIVkqRaqvbcnawQDN0V77gaCgZueQnA3NXtuau4Xo+a+EjUannv5cgfK JLH5U2uyJH9UTZY4zqdJ4grR3WfR6SL+Cl5BPf7mWUlhlhhVOC5DOy5DOy5DG89cR/2MwkK0 WJhjnTgxx0wq8YFe2hj4Jir71tg7uIziS/5bx97On1swjiMY0cmPfyZ7+CXJeicd31HX0NmD DSYiK6I2O6oQmwek7SjZvJwWlfOovjGP2pyJYo1FoMHauRLKS6islIs1jdO5nS+joow6ynxR lqHExHqvseZDRd8ztLw0HxE6kRXzYZ8T6iri5PhZjEbs5vssSiNK8z21e8FjwLMSpnzbuUKq Cm2u6pqJWVOXUVVGc2W+KlMdEe+GQz77q61zqcqlRq6vcn2RO1YYxgaGscIwNjCMFYaxgUEH p2Yz18ylMpeaub7M9c1Q1+oJbSiUQaf1ERw2N7keFjdKpmrjpCNnRPITivoGN5rwg6ejKA5z gTGEwPXBgJxWWSD0FyHW4ACND+bijvtJOGZfftStIZzsCggAQLoHpGl8vuR5LCKH+6KS0Thp 6a6ZHZiObzmOOaQ/0VVgH5YkD7aSlFRZYTyQxQL9sSDWcO1yLOzbJX1qO4KtLw3Ya8pMd4YL KLEjbezZQRM5WobUDpWI37EZhubfnaEUFbVNEaCCPj0yCwW9hNjRK0gmAGIOjVeGxmxDhy3M 4lyYdNbmk/k0P3H2ubyiRaU70qIUzGOBPR9LA2X6qNEomg58u3b1YLz3S8zZILWusQjyeVNF kNmXKGJY28QMjMMl+Ak3+V4cC7xHPId9hsx86sciNOtZNEdAzUDxa6Q4joffvbEybNqxa5TE HJsnQDhzc+Vck1UCoC4AxRjVkBOsYGAqjQstGBe64XGhuXHxCseF2uNi8KJgWOTIbXxYDBFZ dVjY9//i2SKsnoUHxcn/JDMvXDxIDNkmG+ViUkW4iTgt28SlvE3QsRZfP21usUukuE/YarWO 3LDiVnpBqcJUioPZVauhGK+OgllWq6GAXUWuCK2iJj9v12amkiNwEhdenllJhPOKRVjnaxNh OleEDT2wYRGuoghKRZg+igjT1UV4RRRsG7CqCOcRVBfhSsLru4XXX5/w+nOF13804ZUtLS28 /qMIr7+68K6Igu1WVxXePII1CW9gvJ+XlpgSd2ESDR/EAWu0KYy9GroV5rl4zW2oeUSykB/P SI+d5sXGOU3kGSQXl0pYQUhmp35MtvjH8i02X7gDHAMBwh9sTqlzZ/ud0jN0aFk1TdwyLqLY sOfLsqecnMskmbNSuscrv27a40W/wnjRTY0XXXa86FrHa4lhyq8Q9jD5X2GY/E0Nk7/sMPnr HibGGHOshJvNzSHNikIulLAXWInHYKbym2JKLO6WM1beF2TfJGZfyCCUEXH4ud97Ty257Ce1 fypltiWHQmXTbDYvyi/utoEwF4i6gRrlElLOQJbIK+h4GM+AB6lmJKaVhgfo+78+FKH4/5OM nnIaQ5DF5tnZzk5r1cHntJ/KJm6DxFy8VqZdkJvyTsC//wTMYYynYELynPBD1972waO083yb 7m20IbovO/RIDdH97Q59lJY6/nZ3s6MkW+o+397vbLSlji+HacPMkw116Ka7tN+VXVqxoWKN QGuNUGuEWiPUGuERbISzR9II+XY2pBHOHksj5BvalEbIt7QpjZBvaVMa4eyxNEK+oU1phLN/ DRuh1gi1Rqg1wlfVCFmfDcW0ZVTK+JfbX7a8TNoSbRT4xlxeofW2kG+AeptuYMM9oN5me0C9 zTZAvQ03gEOw0TGgG2fRBmcaLZhpdF1doAUzbQMNbLgH2Zm27gZyYrTmBvIzbf0s2uwY5Gfa 2htYdw+WWNPOMmnta9rqDWy4B3PXtBUbmK+wV2ugwpq2Mos2OwYV1rRVG1h3D5ZY05btQuU1 bfUGNtyDuWvaig3MV9irNVBhTVuZRZsdgwpr2qoNrLsHy9in1O909/YPnv908vLV69MNKIvT 169envz0/GB/r9vx6fot7JNMWnsDe5m0kR4gYvnvRnpgNvK1dzlLNUDVf/C/DTRg4V90n7b+ ubxUA6fqP/jf17aw6wbqBta1Tyvwo/bCdDaaBvhyXDWHbOb0cVMYoyWlWhU4S8vqUq+kLvVK SqlXVspNn8K65ZipqMt5FURTBHQEQvzaUbD+vCkTkm8jbZTHf6Ned9/X8d/2KMB3/AO/jv/2 GGmNMZtK478ZUR9dIeB4qP01RIGro7zVUd7qKG+bfOndnrw88OohD1cCbAkyb1xS9siV/+zZ Oz67xZOrF6cfL8TrpHhXIIjilNwFoxl75P0de1+8DicnqbCe2zZjxnHmF4SNkxWsyHEqhsyl ejPJxtQw3sU1Bsl+SdsOETcVN3yct35g5DWa7OuR8lHIcFSGYm79KJbVi+Jk8VALBVDGE5Ol MbNYLHH36zBmxCz9HIzBv3w4rCe5F1g0G4xgV9k3XVRf2wrDRD0fo8fCKFVRJiwm5GMNidBC mPUYkYaKR9XCw6TTNW4VBEzgWiF6kR6HucGL3EQsEceonDEmEldkIw2WjW1ESsMbkVyEI6uM 3fGSXFORjSDZwY0s2nWcI1Ie6ohUChlE5gQ8ImVhgEg+7FEOnzcHX6Y9K7JQ9rcVX4ho8Zkb Ykix2xbZFM1MvJ7JJZYk+BoYQeF/BzolTaOraBSBWaweptDVg9vb0YOcQk1TjHC5NYXHcYG/ 7JK8PcWdAW3U/UkmHdmpqgXEWAFUrACOWPCz6EI/KXDXJMxXI6+nP8nCaUVplbocOQtc43QP qSK08eh3Oj8ufafTwe+GoJstFsyqDfDVFxjbsj5gm44apPIBYb24m9c77QXdLDHFvcnl0EU5 XZhyuhrldF2UMw7ShXlON8BzugTPF6KcrkZ5Mc9LKEdBL3ZVkn8xX6X1aseG2pjn/9vvHmj/ X7eD7z8c7B/U/r/HSGvcZJf6/0q9f7Xvr/b91b6/P5zvL+v5M/1+bGeCrj9a+/1W8vvlvX4l Pr9Sj5/p71vW21fgantMb1+Bw3FpP96KXrwKPrwSD16R/652z9Xuudo994dxz7FtJOFzPGBV IhgIPrFz4msdk2GPwYPWIO7pUyK2xPLU8bDdth8NfjmjZRZ6woxOW0R+Zb/kXF3iclxq2TVd Agx5aejPuV5NBVnJ8VjBA2qKtMX2ZSPKPSn1kfz5vJQ8zqS5VBWNqwHT9Fq2rq0+kpZTyUCp Z5jWyzYevzDKYDS0iONq2NbUmXJbZ1qFP1JLRWceN7ZDE2aeNM46I+exlpaw1vuGWevNYy0t Z623IGu/ltPxLohh4x5sDD+mcv+f53UO9vT7zxT9f3QPsmr/3yOk8ee7UXTFtpqNALZXD/8I yfaXCk9Am9DKuadP+ZnFtgMwcxzQBCx9BbqRRuMZuqr4vlgibSSz2FXEj2cUFPYOWMnXZv43 kMT83+gD8PPef/d84/13fx/9/75Xv//8KOnu7vkBeUGEGDTqKfEnS3r+79BNtTFn/tODbm7+ d/ZoPf8fI33/F7J7FcW7V0F602h8T4gWCPzVT8IAv/iMAzzq2yekS+hPh/7BYZeSX96yt9Up Boq/v3m4DsO/MisBP8cxTOJbFH7jwbq0Szx62PUO/a6qi3CjaDodhQQpIGk/iW6n/KNSfzK+ RZYzjwrfG+LHkvBLwL6DzOJoCpt+sN7/k/yFbA/Y8k7+mxxxw50Q07QZRti59/HogeHYSiOG Q5C4JT/qDAPmPpzi9xisl0IlttP5m+AKOYdtRPx0Sj7Hk3tyA//BjuIm6H+GDYf4mIOVoRps QCYJczxPgHuf2bdB7BGYU+gctLA2GncBqGGwgCoYXsxnbP7+4QdVHYr2uwqq46s/6X4OlhlI Epr9kPDsh6OGNLkuZS2VIWuqjKLa/EyqVZ9nWRh4lgOHyy7E8rB/MyFbYNJtkf8hdykAWzYi NFgFquNXgaL786BkJ6vBzW9VsmMeXO8AIQTIMIqjrXo9r1Od6lSnOtWpTnWqU53qVKc61alO dapTnepUpz9r+n85Z8FBABgBAA== --2B/JsCI69OhZNC5r-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Mar 19 22:21:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nTEs-00087M-00 for ; Wed, 20 Mar 2002 00:41:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 00:41:58 +0100 (CET) Received: (qmail 8400 invoked by uid 0); 19 Mar 2002 22:36:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Mar 2002 22:36:37 -0000 Received: by moria.seul.org (Postfix) id E11A61467ED; Tue, 19 Mar 2002 17:36:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DD1CB1467F3; Tue, 19 Mar 2002 17:36:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 9CFDA1467ED for ; Tue, 19 Mar 2002 17:36:35 -0500 (EST) Received: from ifurita (212.194.240.221) by mail.laposte.net (5.5.044) id 3C9102D700055335 for f-cpu@seul.org; Tue, 19 Mar 2002 23:36:33 +0100 Message-ID: <005101c1cf8c$0eaeeac0$ddf0c2d4@ifurita> From: "Christophe" To: References: <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> <3C96A1DE.6EBF899A@f-cpu.org> <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita> <20020319120431.34391@thrai.stud.uni-hannover.de> Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) Date: Tue, 19 Mar 2002 22:21:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Tuesday, March 19, 2002 12:04 PM Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) > On Tue, Mar 19, 2002 at 03:56:47AM +0100, Christophe wrote: > > Well there is a lot of missing things in VHDL source so it would be quite > > difficult for me to do something since I don't have the slight idea of > > implementation you want to make, especially regarding with memory. And please > > don't forget, I'm a programmer, not a VHDL guru. I can read VHDL but don't > > think for you. If you want me to do something I first need more materials than > > I can find in your source to be able to figure out how to proceed (a lot of > > details about the implementation of your F-CPU sound fuzzy to my ears for the > > moment). > > Please go ahead... which details? There is no LSU source for example. What are its signals, its internals ? how are the register set and other functional units connected ? etc. > [...] > > Anyway, I'm not speaking about to have an instruction CAS2 but something like > > two CAS linked IF IT IS POSSIBLE. > > Since two CAS don't make a CAS2, that wouldn't make much sense. I mean something a normal CAS and a linked CAS like we can find for ll/sc and llp/scp : 0: ll [r1],r3 ; load linked llp [r2],r4 ; load linked pipelined ... scp r6,[r2] ; r6 written into [r2] only if last memory slots of ll and llp not modified jnz 0b sc r5,[r1] ; r5 written into [r1] only if last memory slot of ll not modified jnz 0b But forget. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 21:43:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nTEt-00087M-00 for ; Wed, 20 Mar 2002 00:41:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 00:41:59 +0100 (CET) Received: (qmail 32588 invoked by uid 0); 19 Mar 2002 23:09:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 19 Mar 2002 23:09:37 -0000 Received: by moria.seul.org (Postfix) id F1DC11467ED; Tue, 19 Mar 2002 18:09:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DDAC01467FF; Tue, 19 Mar 2002 18:09:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 3204F1467ED for ; Tue, 19 Mar 2002 18:09:34 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00802; Tue, 19 Mar 2002 21:43:12 +0100 Message-ID: <20020319214312.62465@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 21:43:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Emulator with System C References: <001c01c1cf29$9e5d2dc0$919d2cd5@ifurita> <3C975F50.F9657AF2@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C975F50.F9657AF2@jetnet.ab.ca>; from Ben Franchuk on Tue, Mar 19, 2002 at 08:54:56AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 08:54:56AM -0700, Ben Franchuk wrote: [...] > The problem is the IRQ service has become a catch all for stuff. With > buffering now days lets just delete it and solve all the problems and go > back to polled I/O. [...] The *real* problem is that computers have become a catch all for stuff. Let's go back to pencil and paper - no wait, let's cast everything in stone - no wait, let's climb back onto the trees where we once came from. Anybody else who wants to waste my time? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 19 21:34:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16nTEu-00087M-00 for ; Wed, 20 Mar 2002 00:42:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 00:42:00 +0100 (CET) Received: (qmail 31670 invoked by uid 0); 19 Mar 2002 23:09:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 19 Mar 2002 23:09:43 -0000 Received: by moria.seul.org (Postfix) id 3798D146812; Tue, 19 Mar 2002 18:09:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3514B146810; Tue, 19 Mar 2002 18:09:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 625CE1467FF for ; Tue, 19 Mar 2002 18:09:36 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00776; Tue, 19 Mar 2002 21:34:45 +0100 Message-ID: <20020319213445.40817@thrai.stud.uni-hannover.de> Date: Tue, 19 Mar 2002 21:34:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3C96A288.4D0EDB4@f-cpu.org>; from Yann Guidon on Tue, Mar 19, 2002 at 03:29:28AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 03:29:28AM +0100, Yann Guidon wrote: [...] > in fact, the real problem is to think of CAS as an "instruction". > Things become _so_easy_ if we use a combination of instructions !!! > We do not need any "CAS instruction" but a variant of the usual > load and store instructions, just like the locked versions in ALPHA > (and other CPUs). > > * "load locked" will "tag" the line it selected for reading. it's just a bit > that the issue logic has to set after decoding the instruction. Or a bunch of bits (e.g. one per byte, or maybe 64-bit word, inside the line). > * "store conditional" will proceed if two conditions are met : the specified > condition is true (we can check for LSB, MSB, zero...) and the "tag" is still > set. I often wondered if it was worth it to add a conditional store, but now > i'm convinced. Except that we need a version that checks the "tag". > What about the scheduling ? it's almost as fast, if there are all the > bypass networks ! > > load_tag [r1],r2 > xor r2,r3,r4 > if r4==0 store_locked [r1],r3 > > (or something like that) If a task switch (or IRQ service) occurs between load_tag and store_locked, the tag may change behind the program's back (it might be cleared and set again - the ABA problem). In order to avoid that, a task switch should reset all tags. Oh btw: store_locked must return an indication that the store succeeded (that is, it's a 3r1w instruction), and of course it has to clear the tag. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 20 02:05:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8d-00088S-00 for ; Wed, 20 Mar 2002 14:28:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:23 +0100 (CET) Received: (qmail 11360 invoked by uid 0); 20 Mar 2002 00:59:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 20 Mar 2002 00:59:19 -0000 Received: by moria.seul.org (Postfix) id D622B146807; Tue, 19 Mar 2002 19:59:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B9BC146816; Tue, 19 Mar 2002 19:59:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 1A547146807 for ; Tue, 19 Mar 2002 19:59:10 -0500 (EST) Received: from f-cpu.org (kdl11-37.n.club-internet.fr [213.44.9.37]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 753C41709 for ; Wed, 20 Mar 2002 01:59:06 +0100 (CET) Message-ID: <3C97E03D.D880DF0F@f-cpu.org> Date: Wed, 20 Mar 2002 02:05:01 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Mar 19, 2002 at 03:29:28AM +0100, Yann Guidon wrote: > [...] > > in fact, the real problem is to think of CAS as an "instruction". > > Things become _so_easy_ if we use a combination of instructions !!! > > We do not need any "CAS instruction" but a variant of the usual > > load and store instructions, just like the locked versions in ALPHA > > (and other CPUs). > > > > * "load locked" will "tag" the line it selected for reading. it's just a bit > > that the issue logic has to set after decoding the instruction. > Or a bunch of bits (e.g. one per byte, or maybe 64-bit word, inside the line). maybe 64-bits, but not bytes. byte-wise "dirty" bits are already heavy enough :-/ Plus, if the narrowest external interface is 32-bits, then the LSU needs only 32-bit-wise dirty bits. Write enables will still be byte-wise, however, because we can't always avoid byte operations. > > What about the scheduling ? it's almost as fast, if there are all the > > bypass networks ! > > > > load_tag [r1],r2 > > xor r2,r3,r4 > > if r4==0 store_locked [r1],r3 > > > > (or something like that) I should have been more precise : it is as fast (in terms of cycle count) as a "CAS" instruction that does everything itself. This is not because there are more instructions that the overall operation is slower : because all units communicate through the "Xbar", issuing the right instructions at the right time does the same thing. More specifically : load_tag [r1],r2 xor r2,r3,r4 *** at least 1 unused cycle in FC0 *** if r4==0 store_locked [r1],r3 if you remember the last email, i pointed that there is a little problem with the hypothetical CAS instruction : the loaded data needs an additional cycle (alignment/shift/endianness) and the data from the register set is already in ROP2 (or whatever) when the loaded data finally arrives on the Xbar. Inserting a buffer on one of ROP2's operands is not a solution. The problem disappears by itself when we use the split version : the loaded data and the register (for comparison) appear at the same time on the Xbar and ROP2 needs no modification, there is no bizarre scheduling rule to implement. However, ROP2 takes at least 1 cycle before completion and the data must be ORed so we know whether the result is zero. The OR is performed during the register write-back cycle and influences the decoding and issue of the next instruction, so i think that the gap is around 3 cycles between the xor and the store. > If a task switch (or IRQ service) occurs between load_tag and > store_locked, the tag may change behind the program's back (it might > be cleared and set again - the ABA problem). In order to avoid that, > a task switch should reset all tags. i get it, it sounds obvious... > Oh btw: store_locked must return an indication that the store succeeded > (that is, it's a 3r1w instruction), and of course it has to clear the tag. as i wrote before, _all_ stores clear the tag, so it's not a problem :-) Concerning the tag write : i should reread my post more before hitting "send". I still have to make clear how we are going to support CAS from a remote CPU throught the I/O interface. It's not as easy as some people would think. However, i might have "yet another brilliant idea" which will help solve some remaining problems... but you'll have to wait a bit, i want to be _really_ sure that i'm not writing or thinking shit. who knows ;-) However i hope i reassured Christophe about my "understanding" of the problem. I wish i don't look too much displaced and off-topic as i was before, according to some of his past posts :-)) I wish that some people now understand that if i seem to contradict them, it's not because i'm hiding in an ivory tower. I can find some solutions and compromises but it can only happen if the others have the same desire and patience. 'nacht, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 20 02:05:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8d-00088S-01 for ; Wed, 20 Mar 2002 14:28:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:23 +0100 (CET) Received: (qmail 4138 invoked by uid 0); 20 Mar 2002 00:59:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 20 Mar 2002 00:59:24 -0000 Received: by moria.seul.org (Postfix) id E8508146815; Tue, 19 Mar 2002 19:59:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A57F7146819; Tue, 19 Mar 2002 19:59:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 50BB3146815 for ; Tue, 19 Mar 2002 19:59:17 -0500 (EST) Received: from f-cpu.org (kdl11-37.n.club-internet.fr [213.44.9.37]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7DD5E16E7 for ; Wed, 20 Mar 2002 01:59:13 +0100 (CET) Message-ID: <3C97E044.796DD21A@f-cpu.org> Date: Wed, 20 Mar 2002 02:05:08 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] vhdl code for R7 References: <20020319213600.GA170@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Etienne LABARRE wrote: > Hi all, > > Excuse my poor english, it's not my first language (i'm french...) it's just a matter of ... practice ? :-) > I'm currently coding the register set (R7 unit) for the f-cpu. I sent > here my first version (with some YG remarks), and i whould like you to say your opinion. so here we are back to the problem of the physical mapping of functions by a synthesizer. As far as i remember, Etienne used a different approach from mine, using multiplexors instead of my behavioural code with direct indices. Who knows. One of them will maybe work ? :-) > It works with Simili and Vanilla, but it's not perfect. It's only a > valid model for simulation, and i think that we can perfect it. we'll do it. > For example, the 5-blocks organisation of R7 is > bit 00 to 07 = block 0 = 8 bits > bit 08 to 15 = block 1 = 8 bits > bit 16 to 31 = block 2 = 16 bits > bit 32 to 47 = block 3 = 16 bits > bit 48 to 63 = block 4 = 16 bits you got it right. > This organisation has no signification for me today if > the registers aren't 64 bits wide. What's about if 128 bits ? add 4 > 16-bits blocks, or increase block width ? We add 16-bit blocks up to 256 bits because the loadimm instruction can manage this size : there is a 4-bit "address" and a 16-bit immediate data so the maximum width allowed by the instruction is 16*2^4=256. Above that, either use constants in memory (a pointer requires 32 or 48 bits in practice, so you can spare some size if you load a pointer to the large data). Above 256 bits, there is no constant but "wide" and "SIMD" operations can take place, such as load/stores etc. so a 512-bit register has a wide 256-bit part plus 15x16-bit "slices" and 2x8-bit. And so on (a 1024-bit register adds a 512-bit wide slice). But i doubt we need to care because 256-bits is already a challenge. We can already put a ASSERT SIZE <= 256 in the early versions. > I'm not in f-cpu team for long time, and i don't understand all the > subject... don't worry... ok, now i have to integrate your work in my source tree... > Etienne LABARRE WHYGEE who promised to burn a F-CDROM to Etienne ... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 20 00:47:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8g-00088S-00 for ; Wed, 20 Mar 2002 14:28:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:26 +0100 (CET) Received: (qmail 18980 invoked by uid 0); 20 Mar 2002 01:03:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 20 Mar 2002 01:03:39 -0000 Received: by moria.seul.org (Postfix) id 9BD5A146816; Tue, 19 Mar 2002 20:03:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B64914681A; Tue, 19 Mar 2002 20:03:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id F1150146816 for ; Tue, 19 Mar 2002 20:03:37 -0500 (EST) Received: from ifurita (212.194.231.19) by mail.laposte.net (5.5.044) id 3C9102D700056967 for f-cpu@seul.org; Wed, 20 Mar 2002 02:03:37 +0100 Message-ID: <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] CAS in FC0 Date: Wed, 20 Mar 2002 00:47:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Tuesday, March 19, 2002 9:34 PM Subject: Re: [f-cpu] CAS in FC0 > On Tue, Mar 19, 2002 at 03:29:28AM +0100, Yann Guidon wrote: > [...] > > in fact, the real problem is to think of CAS as an "instruction". > > Things become _so_easy_ if we use a combination of instructions !!! > > We do not need any "CAS instruction" but a variant of the usual > > load and store instructions, just like the locked versions in ALPHA > > (and other CPUs). > > > > * "load locked" will "tag" the line it selected for reading. it's just a bit > > that the issue logic has to set after decoding the instruction. > > Or a bunch of bits (e.g. one per byte, or maybe 64-bit word, inside the line). > > > * "store conditional" will proceed if two conditions are met : the specified > > condition is true (we can check for LSB, MSB, zero...) and the "tag" is still > > set. Which condition ? your tag should tell us if someone else has written to this line before your store conditional. So there is no condition to test beforehand. Your tag is set with the instruction "load tag", but when someone write at the same word, you must clear this tag so the "store conditional" would be warned that someone else takes priority. Any "store" (conditional or not) at this word must clear this tag. > > I often wondered if it was worth it to add a conditional store, but now > > i'm convinced. Except that we need a version that checks the "tag". I'm pleased to hear you :). What you are speaking about is in fact "ll/sc" (load-linked/store-conditional), what i spoke about in the french mailing-list. > > What about the scheduling ? it's almost as fast, if there are all the > > bypass networks ! > > > > load_tag [r1],r2 > > xor r2,r3,r4 > > if r4==0 store_locked [r1],r3 > > > > (or something like that) And store_locked should return the tag in a register to know if store has be done. This register can be zero if tag is clear (someone else has already modified our word). how to implement a software CAS : // int CAS (int * /* pointer */ r1,int /* old value */ r2,int /* new value */ r3) loadaddr 0f,r5 0: move r2,r4 load_tagged [r1],r2 // r2 : read value and set tag for [r1] xor r2,r4,r6 jump.nz r6,r0,r5 // the value is not that we expect ! store_tagged r3,[r1],r6 // r3 : value to write into [r1] if tag still set (tag is cleared afterward) jump.z r6,r0,r5 // tag was cleared before our store ! nxor r2,r0,r3 // r3 != 0 if [r1] == r2 until writing r3 into [r1] jump r0,r63 // return to caller with result in R1 how to implement a PUSH : loadaddr 0f,r5 move r2,r3 // our node address to push 0: load_tagged [r1],r2 // read top store r2,[r3] // node->link = top store_tagged r3,[r1],r4 // top = node jump.nz r4,r0,r63 // return to caller if ok jump r0,r5 > If a task switch (or IRQ service) occurs between load_tag and > store_locked, the tag may change behind the program's back (it might > be cleared and set again - the ABA problem). In order to avoid that, > a task switch should reset all tags. Yes, that's the main backdraft. > Oh btw: store_locked must return an indication that the store succeeded > (that is, it's a 3r1w instruction), and of course it has to clear the tag. :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Mar 20 02:15:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8g-00088S-01 for ; Wed, 20 Mar 2002 14:28:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:26 +0100 (CET) Received: (qmail 29448 invoked by uid 0); 20 Mar 2002 01:18:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 20 Mar 2002 01:18:01 -0000 Received: by moria.seul.org (Postfix) id 1F0B2146819; Tue, 19 Mar 2002 20:18:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01B57146833; Tue, 19 Mar 2002 20:17:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 474D7146819 for ; Tue, 19 Mar 2002 20:17:59 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-192.jetnet.ab.ca [207.34.60.192]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id SAA07634 for ; Tue, 19 Mar 2002 18:17:57 -0700 (MST) Message-ID: <3C97E2AF.6ABB87B5@jetnet.ab.ca> Date: Tue, 19 Mar 2002 18:15:27 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Emulator with System C References: <001c01c1cf29$9e5d2dc0$919d2cd5@ifurita> <3C975F50.F9657AF2@jetnet.ab.ca> <20020319214312.62465@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > The *real* problem is that computers have become a catch all for > stuff. Let's go back to pencil and paper - no wait, let's cast > everything in stone - no wait, let's climb back onto the trees where > we once came from. > > Anybody else who wants to waste my time? I guess you have never used DOS on the PC or CP/M! really bad hardware and software that never had interrupts. Windows does have interrupts ( random ones at that -- look at the blue screen of death ). I like old computers for many reasons , one being that they are simple in design. My the F-CPU is only good for BIG, POWER HUNGARY OS'S like u**x or DOZE. I bet over 2/3's of all the computers used are hidden in some product or use 16 bits or less. A good system has hardware/software balanced and all this talk of CAS instructions seems to stray from the KISS principle. SPEED SPEED SPEED is not the only thing important in a CPU- design,what about programming (like assembly) and user interfaces.The best OS I have seen was OS/9 for the 6809 none of this BLOATED stuff like LINUX.** Right now having a design working is more important, I will leave now so Michael can get back to work. ** LINUX is good as command line OS , but never was ment as interactive desktop as the current trend is today with OS's. -- Ben Frantic - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 20 03:18:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8h-00088S-00 for ; Wed, 20 Mar 2002 14:28:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:27 +0100 (CET) Received: (qmail 22749 invoked by uid 0); 20 Mar 2002 02:12:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 20 Mar 2002 02:12:37 -0000 Received: by moria.seul.org (Postfix) id E95D1146807; Tue, 19 Mar 2002 21:12:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1967146814; Tue, 19 Mar 2002 21:12:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 913CD146807 for ; Tue, 19 Mar 2002 21:12:33 -0500 (EST) Received: from f-cpu.org (kdl16-2.n.club-internet.fr [213.44.18.2]) by relay-3v.club-internet.fr (Postfix) with ESMTP id A186716D7 for ; Wed, 20 Mar 2002 03:12:30 +0100 (CET) Message-ID: <3C97F171.CE11BED6@f-cpu.org> Date: Wed, 20 Mar 2002 03:18:25 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <003001c1cdab$9209c4e0$cef9c2d4@ifurita> <20020318004128.11722@thrai.stud.uni-hannover.de> <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> <3C96A1DE.6EBF899A@f-cpu.org> <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita> <20020319120431.34391@thrai.stud.uni-hannover.de> <005101c1cf8c$0eaeeac0$ddf0c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe wrote: > From: Michael Riepe > > > On Tue, Mar 19, 2002 at 03:56:47AM +0100, Christophe wrote: > > > Well there is a lot of missing things in VHDL source so it would be quite > > > difficult for me to do something since I don't have the slight idea of > > > implementation you want to make, especially regarding with memory. And please > > > don't forget, I'm a programmer, not a VHDL guru. I can read VHDL but don't > > > think for you. If you want me to do something I first need more materials than > > > I can find in your source to be able to figure out how to proceed (a lot of > > > details about the implementation of your F-CPU sound fuzzy to my ears for the > > > moment). > > > > Please go ahead... which details? > > There is no LSU source for example. What are its signals, its internals ? how > are the register set and other functional units connected ? etc. concerning the LSU, there is a strong disagreement between nicO and me... i have a personal opinion and method, while nicO's point of view is more academic. Currently, i try to finish the R7, integrate new VHDL tools (make the ncsim simulator work, not only the compiler, plus add Riviera support), add some old simple EU (INC, POPC), make another version of SHL... and make a major update to the YGASM, update the websites, not counting all the non-F-CPU duties of everyday... starting to code from the LSU side is not very wise (i tried and failed). the plan is more : do all EU, add the R7 and Xbar, then the scheduler and the instruction decoder. These parts make the "execution pipeline" which can be more or less taken apart. Then add the TLB, LSU and fetcher (three units which are very closely tied). The L1 cache comes on top of it, as well as the other memory interfaces and I/O. I insist on plugging the local SDRAM controller directly to the LSU/fetcher, as well as the L2 and the I/O bus (so the LSU has 4 ports from the external side and 1 port from the pipeline side). nicO wants all cache levels to be "unfolded" or "chained" (L1 plugged to L2 which is plugged to SDRAM...) but the management is very different and creates some coherency problems and increases the latency. just make your choice. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 20 03:18:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8i-00088S-00 for ; Wed, 20 Mar 2002 14:28:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:28 +0100 (CET) Received: (qmail 8581 invoked by uid 0); 20 Mar 2002 02:12:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 20 Mar 2002 02:12:39 -0000 Received: by moria.seul.org (Postfix) id 54202146816; Tue, 19 Mar 2002 21:12:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 50E8C146815; Tue, 19 Mar 2002 21:12:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id F2BB0146814 for ; Tue, 19 Mar 2002 21:12:37 -0500 (EST) Received: from f-cpu.org (kdl16-2.n.club-internet.fr [213.44.18.2]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9A0481692 for ; Wed, 20 Mar 2002 03:12:34 +0100 (CET) Message-ID: <3C97F175.26554F1C@f-cpu.org> Date: Wed, 20 Mar 2002 03:18:29 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Christophe wrote: > From: Michael Riepe > > On Tue, Mar 19, 2002 at 03:29:28AM +0100, Yann Guidon wrote: > > [...] > > > in fact, the real problem is to think of CAS as an "instruction". > > > Things become _so_easy_ if we use a combination of instructions !!! > > > We do not need any "CAS instruction" but a variant of the usual > > > load and store instructions, just like the locked versions in ALPHA > > > (and other CPUs). > > > > > > * "load locked" will "tag" the line it selected for reading. it's just a bit > > > that the issue logic has to set after decoding the instruction. > > Or a bunch of bits (e.g. one per byte, or maybe 64-bit word, inside the line). > > > > > * "store conditional" will proceed if two conditions are met : the specified > > > condition is true (we can check for LSB, MSB, zero...) and the "tag" is still > > > set. > > Which condition ? your tag should tell us if someone else has written to this > line before your store conditional. So there is no condition to test > beforehand. you forget the purpose of the comparison. On monday, you wrote : > - a single word compare-and-swap : cmpxchg reg1,[reg2] > > atomic { > if (eax == *reg2) { > *reg2 = reg1; > zf = 1; /* zero flag */ > } else { > eax = *reg2; // update the requested value since it has changed > zf = 0; > } > } so the store to memory is conditioned by the result of the comparison AND the integrity of the dirty flag. Unless i don't understand your C code. > Your tag is set with the instruction "load tag", but when someone write at the > same word, you must clear this tag so the "store conditional" would be warned > that someone else takes priority. Any "store" (conditional or not) at this word > must clear this tag. yes, that's it. but the store for this case has to check 2 conditions, instead of only one. > > > I often wondered if it was worth it to add a conditional store, but now > > > i'm convinced. Except that we need a version that checks the "tag". > > I'm pleased to hear you :). What you are speaking about is in fact "ll/sc" > (load-linked/store-conditional), what i spoke about in the french mailing-list. I was thinking aloud about the rationale Intel gave about the agressive predication in the IA64 family. They say that it reduces the pressure on the loops (no need to unroll), but the prolog and epilog require some special treatment. Having a conditional store simplifies the design of the prolog and epilog (just use the loop counter as a condition for the store), because it removes the risk of triggering traps or page misses at the extremities of the loop. OTOH, if someone uses post-incremented instructions, there is not much risk either but the increment field is the same as the condition, so we can't use them at the same time. But it's useful anyway in some "tight" cases (reduces the need for jumps) Using a more sophisticated conditional store makes the initial idea plausible and even useful. > > > What about the scheduling ? it's almost as fast, if there are all the > > > bypass networks ! > > > > > > load_tag [r1],r2 > > > xor r2,r3,r4 > > > if r4==0 store_locked [r1],r3 > > > > > > (or something like that) > > And store_locked should return the tag in a register to know if store has be > done. This register can be zero if tag is clear (someone else has already > modified our word). yup. However, notice that most fields in the locked store are used :-/ > how to implement a software CAS : > > // int CAS (int * /* pointer */ r1,int /* old value */ r2,int /* new value */ > r3) > loadaddr 0f,r5 > 0: this can be also written as : loopentry r5 > move r2,r4 > load_tagged [r1],r2 // r2 : read value and set tag for [r1] > xor r2,r4,r6 > jump.nz r6,r0,r5 // the value is not that we expect ! oops, the pointers are in the middle, so it should be if r6==0 jump r5; /* YG "clear" syntax */ There is also another form : loop is more useful for creating a timeout, with other parameters. > store_tagged r3,[r1],r6 // r3 : value to write into [r1] if tag still set > (tag is cleared afterward) > jump.z r6,r0,r5 // tag was cleared before our store ! so r6 is the result ? And you spare a conditional store by inserting another jump in the middle of the loop ? > nxor r2,r0,r3 // r3 != 0 if [r1] == r2 until writing r3 > into [r1] what is this instruction ? > jump r0,r63 // return to caller with result in R1 > > how to implement a PUSH : > > loadaddr 0f,r5 > move r2,r3 // our node address to push > 0: idem : "loopentry r5" is here for this purpose. > load_tagged [r1],r2 // read top > store r2,[r3] // node->link = top > store_tagged r3,[r1],r4 // top = node > jump.nz r4,r0,r63 // return to caller if ok > jump r0,r5 mmm to me, it looks more like an element that is inserted in a linked list, but who cares, it seems to do the job. > > If a task switch (or IRQ service) occurs between load_tag and > > store_locked, the tag may change behind the program's back (it might > > be cleared and set again - the ABA problem). In order to avoid that, > > a task switch should reset all tags. > > Yes, that's the main backdraft. but there is certainly a nice solution. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ np : Bill Laswell / Jah Wobble / Nils Peter Molvaer in RADIOAXOM. wow maaan...... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 20 10:13:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8l-00088S-00 for ; Wed, 20 Mar 2002 14:28:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:31 +0100 (CET) Received: (qmail 15955 invoked by uid 0); 20 Mar 2002 10:28:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 20 Mar 2002 10:28:44 -0000 Received: by moria.seul.org (Postfix) id 35727146828; Wed, 20 Mar 2002 05:28:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2982E146849; Wed, 20 Mar 2002 05:28:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 338DE146828 for ; Wed, 20 Mar 2002 05:28:40 -0500 (EST) Received: from ifurita (213.44.148.117) by mail.laposte.net (5.5.044) id 3C9101F200061FA0 for f-cpu@seul.org; Wed, 20 Mar 2002 11:28:13 +0100 Message-ID: <000b01c1cfef$77fa24a0$75942cd5@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <3C97F175.26554F1C@f-cpu.org> Subject: Re: [f-cpu] CAS in FC0 Date: Wed, 20 Mar 2002 10:13:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Wednesday, March 20, 2002 3:18 AM Subject: Re: [f-cpu] CAS in FC0 > hello, > > Christophe wrote: > > From: Michael Riepe > > > On Tue, Mar 19, 2002 at 03:29:28AM +0100, Yann Guidon wrote: > > > [...] > > > > in fact, the real problem is to think of CAS as an "instruction". > > > > Things become _so_easy_ if we use a combination of instructions !!! > > > > We do not need any "CAS instruction" but a variant of the usual > > > > load and store instructions, just like the locked versions in ALPHA > > > > (and other CPUs). > > > > > > > > * "load locked" will "tag" the line it selected for reading. it's just a bit > > > > that the issue logic has to set after decoding the instruction. > > > Or a bunch of bits (e.g. one per byte, or maybe 64-bit word, inside the line). > > > > > > > * "store conditional" will proceed if two conditions are met : the specified > > > > condition is true (we can check for LSB, MSB, zero...) and the "tag" is still > > > > set. > > > > Which condition ? your tag should tell us if someone else has written to this > > line before your store conditional. So there is no condition to test > > beforehand. Sorry ! it was too late when I wrote that. In fact I didn't realize your were writing a CAS implementation so you're right for the comparison :). And I did another mistake in my example of implementation of CAS, here the right one without the loop (i forget to remove the loop when I transform my TAS example into CAS example) : r1 : pointer, r2 : requested value, r3 : new value move r2,r4 move r1,r6 load_tagged [r1],r2 // r2 : read value and set tag for [r1] xor r2,r4,r1 if r1 != 0 jump r0,r63 // the value is not that we expect so return to our caller ! store_tagged [r6],r3,r1 // r3 : value to write into [r6] if tag still set (tag is cleared afterward) jump r0,r63 // return to our caller Now note that I expect this implementation returns 0 if success instead of !0. "store_tagged" returns 0 if tag is set now. > you forget the purpose of the comparison. On monday, you wrote : > > - a single word compare-and-swap : cmpxchg reg1,[reg2] > > > > atomic { > > if (eax == *reg2) { > > *reg2 = reg1; > > zf = 1; /* zero flag */ > > } else { > > eax = *reg2; // update the requested value since it has changed > > zf = 0; > > } > > } The main difference between the acadimical CAS and the Intel cmpxchg is that the latter updates the register which would contain the requested value. But implementing cmpxchg finally looks like our CAS implementation since r2 contains the actual read value when not maching with the requested value. Good. > so the store to memory is conditioned by the result of the comparison > AND the integrity of the dirty flag. > Unless i don't understand your C code. It's the case for CAS implementation. I did a mistake so you're okay :). > > > > What about the scheduling ? it's almost as fast, if there are all the > > > > bypass networks ! > > > > > > > > load_tag [r1],r2 > > > > xor r2,r3,r4 > > > > if r4==0 store_locked [r1],r3 > > > > > > > > (or something like that) > > > > And store_locked should return the tag in a register to know if store has be > > done. This register can be zero if tag is clear (someone else has already > > modified our word). > > yup. However, notice that most fields in the locked store are used :-/ > Or use the register which holds the new value to be set according the tag just after writing this register in memory if you don't have enough place ? store_tagged [r1],r2 { if ([r1].tag == 1) { *r1 = r2; r2 = 0; } else { r2 = 1; } } > > how to implement a software CAS : Oh forget this one, it is buggy :). > this can be also written as : > loopentry r5 oh yes that's true. > > jump.nz r6,r0,r5 // the value is not that we expect ! > > oops, the pointers are in the middle, so it should be > if r6==0 jump r5; /* YG "clear" syntax */ ok ok i will remember to use this syntax for the next time > > nxor r2,r0,r3 // r3 != 0 if [r1] == r2 until writing r3 > > into [r1] > what is this instruction ? r3 = ~(r2 ^ r0); It may be a mistake but forget we can use only xor if we decide that we return 0 when success. > > how to implement a PUSH : > > > > loadaddr 0f,r5 > > move r2,r3 // our node address to push > > 0: > > idem : "loopentry r5" is here for this purpose. > > > load_tagged [r1],r2 // read top > > store r2,[r3] // node->link = top > > store_tagged r3,[r1],r4 // top = node > > jump.nz r4,r0,r63 // return to caller if ok > > jump r0,r5 > > mmm to me, it looks more like an element that is inserted > in a linked list, but who cares, it seems to do the job. I'm speaking about a stack implemented as a list, you want a version using an array ? I would need something like a CAS2 to do so safely so I'm not bothering to show it. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 20 10:16:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8l-00088S-01 for ; Wed, 20 Mar 2002 14:28:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:31 +0100 (CET) Received: (qmail 19535 invoked by uid 0); 20 Mar 2002 10:31:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 20 Mar 2002 10:31:44 -0000 Received: by moria.seul.org (Postfix) id 17247146859; Wed, 20 Mar 2002 05:31:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 14BDD146850; Wed, 20 Mar 2002 05:31:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id B5695146828 for ; Wed, 20 Mar 2002 05:31:43 -0500 (EST) Received: from ifurita (213.44.148.117) by mail.laposte.net (5.5.044) id 3C9101C800063044 for f-cpu@seul.org; Wed, 20 Mar 2002 11:31:43 +0100 Message-ID: <001701c1cfef$f5b99c40$75942cd5@ifurita> From: "Christophe" To: Subject: [f-cpu] url to get a pdf file speaking about blocking versus nonblocking synchronisation Date: Wed, 20 Mar 2002 10:16:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ftp://ftp.seul.org/pub/f-cpu/contrib/michael98nonblocking.pdf ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 20 02:53:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8m-00088S-00 for ; Wed, 20 Mar 2002 14:28:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:32 +0100 (CET) Received: (qmail 18710 invoked by uid 0); 20 Mar 2002 10:40:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 20 Mar 2002 10:40:32 -0000 Received: by moria.seul.org (Postfix) id EB879146828; Wed, 20 Mar 2002 05:40:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D82E146849; Wed, 20 Mar 2002 05:40:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a212.home.uni-hannover.de [130.75.232.212]) by moria.seul.org (Postfix) with ESMTP id EC756146828 for ; Wed, 20 Mar 2002 05:40:29 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01957; Wed, 20 Mar 2002 02:53:54 +0100 Message-ID: <20020320025354.04283@thrai.stud.uni-hannover.de> Date: Wed, 20 Mar 2002 02:53:54 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) References: <004601c1ce08$b78e48a0$57ffc2d4@ifurita> <20020318022057.49806@thrai.stud.uni-hannover.de> <000901c1ce27$79b47300$4df4c2d4@ifurita> <20020318120736.54471@thrai.stud.uni-hannover.de> <004901c1cec4$5d8391a0$05972cd5@ifurita> <20020319014043.54866@thrai.stud.uni-hannover.de> <3C96A1DE.6EBF899A@f-cpu.org> <001d01c1cef1$b6b8f760$f3d3c2d4@ifurita> <20020319120431.34391@thrai.stud.uni-hannover.de> <005101c1cf8c$0eaeeac0$ddf0c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <005101c1cf8c$0eaeeac0$ddf0c2d4@ifurita>; from Christophe on Tue, Mar 19, 2002 at 10:21:38PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Mar 19, 2002 at 10:21:38PM +0100, Christophe wrote: [...] > > Please go ahead... which details? > > There is no LSU source for example. What are its signals, its internals ? how > are the register set and other functional units connected ? etc. That's something we still have to work on. I have to admit that I don't have an exact picture either, so we will have to talk about it, preferably on this mailing list. The LSU will probably have - an interface to the Xbar, similar to the execution units: - a 64-bit address input port - a 64-bit data input port (write port) - a 64-bit data output port (read port) - mode control lines coming directly from the opcode (load/store, operand size, endian, stream hints, flush) - an `enable' line indicating that the inputs are valid - an interface to the data cache (this is not yet clear at all) - a number of additional control lines (not clear either) Feel free to add more details... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 20 10:26:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8m-00088S-01 for ; Wed, 20 Mar 2002 14:28:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:32 +0100 (CET) Received: (qmail 1694 invoked by uid 0); 20 Mar 2002 10:41:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Mar 2002 10:41:46 -0000 Received: by moria.seul.org (Postfix) id F38DE146859; Wed, 20 Mar 2002 05:41:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1388146850; Wed, 20 Mar 2002 05:41:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id AF00C146844 for ; Wed, 20 Mar 2002 05:41:45 -0500 (EST) Received: from ifurita (213.44.148.117) by mail.laposte.net (5.5.044) id 3C91041D0006325D for f-cpu@seul.org; Wed, 20 Mar 2002 11:41:44 +0100 Message-ID: <003301c1cff1$5c66e640$75942cd5@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <3C97F175.26554F1C@f-cpu.org> <000b01c1cfef$77fa24a0$75942cd5@ifurita> Subject: Re: [f-cpu] CAS in FC0 Date: Wed, 20 Mar 2002 10:26:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Oh sorry i didn't read well you email : "if r4==0 store_locked [r1],r3" is in fact a single instrustion as does "if r4==0 jump r0,r63" ? Is that so, okay what I wrote can be shorter : r1 : pointer, r2 : requested value, r3 : new value move r2,r4 move r1,r6 load_tagged [r1],r2 xor r2,r4,r1 if r1 == 0 store_tagged [r6],r3,r1 jump r0,r63 To push in a FIFO list : move r2,r3 // our node address to push loopentry r5 load_tagged [r1],r2 // read top store r2,[r3] // node->link = top if r0 == 0 store_tagged r3,[r1],r4 // top = node if r4 == 0 jump r0,r63 // return to caller if ok jump r0,r5 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Mar 20 13:40:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8n-00088S-00 for ; Wed, 20 Mar 2002 14:28:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:33 +0100 (CET) Received: (qmail 9748 invoked by uid 0); 20 Mar 2002 12:40:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 20 Mar 2002 12:40:44 -0000 Received: by moria.seul.org (Postfix) id 1338E1467F0; Wed, 20 Mar 2002 07:40:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E870714681A; Wed, 20 Mar 2002 07:40:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 515771467F0 for ; Wed, 20 Mar 2002 07:40:26 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203201240.07e3; Wed, 20 Mar 2002 12:40:07 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: CAS and spinlocks (was: Re: [f-cpu] another DATE report) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Mar 2002 12:40:07 GMT Message-id: <200203201240.07e3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N It's my turn ! -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 20/03/02 Objet: Re: CAS and spinlocks (was: Re: [f-cpu] another DATE = report) On Tue, Mar 19, 2002 at 10:21:38PM +0100, Christophe wrote: [...] > > Please go ahead... which details? >=20 > There is no LSU source for example. What are its signals, = its internals ? how > are the register set and other functional units connected = ? etc. That's something we still have to work on. I have to admit = that I don't have an exact picture either, so we will have to talk = about it, preferably on this mailing list. The LSU will probably have - an interface to the Xbar, similar to the execution units: >>>I don't like the use of Xbar, we will not use Xbar but bu= ses. Whygee agree but continue to use the word. I repeat that a Xbar is = a matrix of wire connected by pass-transistor. The 2 main drawback are t= he slow speed and the very udge size. Such design are used for routi= ng but we haven't any routing to do here. - a 64-bit address input port - a 64-bit data input port (write port) - a 64-bit data output port (read port) >>>Hum. It's depend how you react with it. >From the core point of view, you access it as a "cache" (Why= gee(TM)) or as memory adresse by the register field of instruction for I= cache and by the stream flag for the Dcache (we need that to fight agains= t alias). Dcache (LSU or L0) could use to 2 line of the L1 cache. So d= ouble buffernig/prefetching could be done. >>>With this kind of implementation, i don't beleive that we= need the adress of the cached data. It will depend on the invalidatin= g system for coherency. >>>>From the memory system point of view, the data buses with= has the size of the cache line of the L1 cache. There is a mecanism = to give the adresse from instructions word (prefetch,...) and/or the loa= d and store unit. - mode control lines coming directly from the opcode (load/store, operand size, endian, stream hints, flush) - an `enable' line indicating that the inputs are valid - an interface to the data cache (this is not yet clear at all) - a number of additional control lines (not clear either) Feel free to add more details... >>> Done ! nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 20 12:41:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ng8o-00088S-00 for ; Wed, 20 Mar 2002 14:28:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 14:28:34 +0100 (CET) Received: (qmail 26731 invoked by uid 0); 20 Mar 2002 12:49:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 20 Mar 2002 12:49:00 -0000 Received: by moria.seul.org (Postfix) id 3D2A114680E; Wed, 20 Mar 2002 07:48:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 33179146828; Wed, 20 Mar 2002 07:48:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id D75BD14680E for ; Wed, 20 Mar 2002 07:48:58 -0500 (EST) Received: from ifurita (212.194.241.173) by mail.laposte.net (5.5.044) id 3C91041D00065E5C for f-cpu@seul.org; Wed, 20 Mar 2002 13:48:58 +0100 Message-ID: <000101c1d00b$806058a0$adf1c2d4@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <3C97F175.26554F1C@f-cpu.org> <000b01c1cfef$77fa24a0$75942cd5@ifurita> <003301c1cff1$5c66e640$75942cd5@ifurita> Subject: Re: [f-cpu] CAS in FC0 Date: Wed, 20 Mar 2002 12:41:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N oh yes the fields operands is now 4 bad ! well another proposal ? "if r1 == 0 store_tagged [r2],r3" { if (r1 == 0 && !(r1 = (lsu(r2).tag != 1))) *r2 = r3; } instead of : "if r1 == 0 store_tagged [r2],r3" { if (r1 == 0 && lsu(r2).tag == 1) *r2 = r3; r3 = (lsu(r2).tag != 1); } ----- Original Message ----- From: Christophe To: Sent: Wednesday, March 20, 2002 10:26 AM Subject: Re: [f-cpu] CAS in FC0 > Oh sorry i didn't read well you email : > > "if r4==0 store_locked [r1],r3" is in fact a single instrustion as does "if > r4==0 jump r0,r63" ? > > Is that so, okay what I wrote can be shorter : > > r1 : pointer, r2 : requested value, r3 : new value > > move r2,r4 > move r1,r6 > load_tagged [r1],r2 > xor r2,r4,r1 > if r1 == 0 store_tagged [r6],r3,r1 > jump r0,r63 > > > To push in a FIFO list : > > move r2,r3 // our node address to push > loopentry r5 > load_tagged [r1],r2 // read top > store r2,[r3] // node->link = top > if r0 == 0 store_tagged r3,[r1],r4 // top = node > if r4 == 0 jump r0,r63 // return to caller if ok > jump r0,r5 > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 20 14:27:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16no5U-00057J-00 for ; Wed, 20 Mar 2002 22:57:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 22:57:40 +0100 (CET) Received: (qmail 27502 invoked by uid 0); 20 Mar 2002 13:21:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 20 Mar 2002 13:21:29 -0000 Received: by moria.seul.org (Postfix) id BA6B91467F0; Wed, 20 Mar 2002 08:21:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A356C146828; Wed, 20 Mar 2002 08:21:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4FEA31467F0 for ; Wed, 20 Mar 2002 08:21:25 -0500 (EST) Received: from f-cpu.org (kdl11-195.n.club-internet.fr [213.44.9.195]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3609C169B for ; Wed, 20 Mar 2002 14:21:22 +0100 (CET) Message-ID: <3C988E32.9D0D39B7@f-cpu.org> Date: Wed, 20 Mar 2002 14:27:14 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <3C97F175.26554F1C@f-cpu.org> <000b01c1cfef$77fa24a0$75942cd5@ifurita> <003301c1cff1$5c66e640$75942cd5@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, just a quick post before we meet at la Médiathèque : Christophe wrote: > > Oh sorry i didn't read well you email : > > "if r4==0 store_locked [r1],r3" is in fact a single instrustion as does "if > r4==0 jump r0,r63" ? yes, it is my "version" of the syntax so it appears clearly. there are usually two conditional intructions : jump and move. i propose to add another one : store. > Is that so, okay what I wrote can be shorter : > > r1 : pointer, r2 : requested value, r3 : new value > > move r2,r4 > move r1,r6 > load_tagged [r1],r2 > xor r2,r4,r1 > if r1 == 0 store_tagged [r6],r3,r1 it can't work because we only have 3 register fields. This means that if you want to write to a register, the register number is implicit or something like that. > jump r0,r63 > > To push in a FIFO list : > > move r2,r3 // our node address to push > loopentry r5 > load_tagged [r1],r2 // read top > store r2,[r3] // node->link = top > if r0 == 0 store_tagged r3,[r1],r4 // top = node > if r4 == 0 jump r0,r63 // return to caller if ok > jump r0,r5 same problem. it seems that we have to better define the conditional store format. later you corrected yourself : > oh yes the fields operands is now 4 bad ! > > well another proposal ? > > "if r1 == 0 store_tagged [r2],r3" { > if (r1 == 0 && !(r1 = (lsu(r2).tag != 1))) > *r2 = r3; > } note : with conditional instructions, we can use whatever register (even register 0) and 3 conditions (LSB, MSB, zero). So it is not limited to checking zero :-) concerning the difference between "lsu(r2).tag == 1" and "!(r1 = (lsu(r2).tag != 1))", i think i understand. but i wouldn't write it this way (move the assignation inside the loop). > instead of : > > "if r1 == 0 store_tagged [r2],r3" { > if (r1 == 0 && lsu(r2).tag == 1) > *r2 = r3; > r3 = (lsu(r2).tag != 1); > } WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Mar 20 16:55:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16no5V-00057J-00 for ; Wed, 20 Mar 2002 22:57:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 20 Mar 2002 22:57:41 +0100 (CET) Received: (qmail 8616 invoked by uid 0); 20 Mar 2002 15:55:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 20 Mar 2002 15:55:31 -0000 Received: by moria.seul.org (Postfix) id 9F0DC1467FA; Wed, 20 Mar 2002 10:55:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98E19146800; Wed, 20 Mar 2002 10:55:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 5893B1467FA for ; Wed, 20 Mar 2002 10:55:29 -0500 (EST) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 89E4780 for ; Wed, 20 Mar 2002 16:55:28 +0100 (CET) Received: by imp2-2.free.fr (Postfix, from userid 33) id DC2BA8C184; Wed, 20 Mar 2002 16:55:22 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 Message-ID: <1016639722.3c98b0ea8267f@imp.free.fr> Date: Wed, 20 Mar 2002 16:55:22 +0100 (MET) From: Cedric BAIL References: <3C96A288.4D0EDB4@f-cpu.org> In-Reply-To: <3C96A288.4D0EDB4@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 193.251.4.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > What about the scheduling ? it's almost as fast, if there are all the > bypass networks ! > > load_tag [r1],r2 > xor r2,r3,r4 > if r4==0 store_locked [r1],r3 I have one question, what append when we do a normal store and the data are not present into the cache ? Does it force a load before doing the store. Because if it doesn't, what append when a first CPU do a CAS operation on a data that is only writed by the second CPU (So not in cache when the load_tag is done) and when the second CPU is the owner of the memory. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 20 12:18:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ntfI-00010U-01 for ; Thu, 21 Mar 2002 04:55:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 21 Mar 2002 04:55:00 +0100 (CET) Received: (qmail 16829 invoked by uid 0); 21 Mar 2002 01:07:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 21 Mar 2002 01:07:26 -0000 Received: by moria.seul.org (Postfix) id B0552146805; Wed, 20 Mar 2002 20:07:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 96D4B14680E; Wed, 20 Mar 2002 20:07:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a159.home.uni-hannover.de [130.75.232.159]) by moria.seul.org (Postfix) with ESMTP id 7CDFC146805 for ; Wed, 20 Mar 2002 20:07:22 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00542; Wed, 20 Mar 2002 12:18:14 +0100 Message-ID: <20020320121813.03166@thrai.stud.uni-hannover.de> Date: Wed, 20 Mar 2002 12:18:13 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita>; from Christophe on Wed, Mar 20, 2002 at 12:47:39AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Mar 20, 2002 at 12:47:39AM +0100, Christophe wrote: [...] > Your tag is set with the instruction "load tag", but when someone write at the > same word, you must clear this tag so the "store conditional" would be warned > that someone else takes priority. Any "store" (conditional or not) at this word > must clear this tag. That's it, in a nutshell. > > > I often wondered if it was worth it to add a conditional store, but now > > > i'm convinced. Except that we need a version that checks the "tag". > > I'm pleased to hear you :). What you are speaking about is in fact "ll/sc" > (load-linked/store-conditional), what i spoke about in the french mailing-list. Where does this ll/sc nomenclature come from? [...] > how to implement a software CAS : > > // int CAS (int * /* pointer */ r1,int /* old value */ r2,int /* new value */ > r3) > loadaddr 0f,r5 > 0: loopentry r5 // ;-) > move r2,r4 > load_tagged [r1],r2 // r2 : read value and set tag for [r1] > xor r2,r4,r6 > jump.nz r6,r0,r5 // the value is not that we expect ! > store_tagged r3,[r1],r6 // r3 : value to write into [r1] if tag still set > (tag is cleared afterward) > jump.z r6,r0,r5 // tag was cleared before our store ! > nxor r2,r0,r3 // r3 != 0 if [r1] == r2 until writing r3 > into [r1] > jump r0,r63 // return to caller with result in R1 I agree, with one exception: this is already a `CAS in a loop'. A single CAS probably looks like this: loadaddr fail,r5 load_tagged [r1],r4 xor r4,r2,r6 jump.nz r6,r5 store_tagged r3,[r1],r6 jump.z r6,r5 loadconsx $1,r1 // return true jump r63 fail: move r0,r1 // return false jump r63 There's one problem left here: when the compare fails, the tag is not cleared before the function returns (due to the jump before store_tagged). > how to implement a PUSH : > > loadaddr 0f,r5 > move r2,r3 // our node address to push > 0: > load_tagged [r1],r2 // read top > store r2,[r3] // node->link = top > store_tagged r3,[r1],r4 // top = node > jump.nz r4,r0,r63 // return to caller if ok > jump r0,r5 Yep. But beware! `store r2,[r3]' must not clear the tag, or else this function will loop forever. > > If a task switch (or IRQ service) occurs between load_tag and > > store_locked, the tag may change behind the program's back (it might > > be cleared and set again - the ABA problem). In order to avoid that, > > a task switch should reset all tags. > > Yes, that's the main backdraft. > > > Oh btw: store_locked must return an indication that the store succeeded > > (that is, it's a 3r1w instruction), and of course it has to clear the tag. > > :) I guess we're going to get it right :) One more point to consider: Do we really need an extra load_tag? Tagging could as well be done for all loads. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Mar 21 04:53:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr7g-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:24 +0100 (CET) Received: (qmail 2149 invoked by uid 0); 21 Mar 2002 04:09:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Mar 2002 04:09:08 -0000 Received: by moria.seul.org (Postfix) id C6958146815; Wed, 20 Mar 2002 23:09:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FD6C146828; Wed, 20 Mar 2002 23:09:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 14A7C146815 for ; Wed, 20 Mar 2002 23:09:05 -0500 (EST) Received: from ifurita (212.194.225.105) by mail.laposte.net (5.5.044) id 3C9102D700071BB7 for f-cpu@seul.org; Thu, 21 Mar 2002 05:09:02 +0100 Message-ID: <003501c1d08c$083e8b40$69e1c2d4@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <20020320121813.03166@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] CAS in FC0 Date: Thu, 21 Mar 2002 04:53:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Where does this ll/sc nomenclature come from? > See http://swig.stanford.edu/pub/summaries/osstruc/nbs.html http://www-dsg.stanford.edu/papers/non-blocking-osdi/node11.html http://www.cs.berkeley.edu/~culler/cs258-s99/slides/lec09/sld013.htm http://www.cs.berkeley.edu/~culler/cs258-s99/slides/lec10/sld023.htm http://www.sgi.com/processors/r10k/manual/t5.Ver.2.0.book_43.html www.cs.wisc.edu/~rajwar/papers/hpca00-talk.pdf (For PowerPC : lwarx and stwcx) > [...] > > how to implement a software CAS : > > > > // int CAS (int * /* pointer */ r1,int /* old value */ r2,int /* new value */ > > r3) > > loadaddr 0f,r5 > > 0: > > loopentry r5 // ;-) > > > move r2,r4 > > load_tagged [r1],r2 // r2 : read value and set tag for [r1] > > xor r2,r4,r6 > > jump.nz r6,r0,r5 // the value is not that we expect ! > > store_tagged r3,[r1],r6 // r3 : value to write into [r1] if tag still set > > (tag is cleared afterward) > > jump.z r6,r0,r5 // tag was cleared before our store ! > > nxor r2,r0,r3 // r3 != 0 if [r1] == r2 until writing r3 > > into [r1] > > jump r0,r63 // return to caller with result in R1 > Forget this one, it is buggy ! > > how to implement a PUSH : > > > > loadaddr 0f,r5 > > move r2,r3 // our node address to push > > 0: > > load_tagged [r1],r2 // read top > > store r2,[r3] // node->link = top > > store_tagged r3,[r1],r4 // top = node > > jump.nz r4,r0,r63 // return to caller if ok > > jump r0,r5 > > Yep. But beware! `store r2,[r3]' must not clear the tag, or else this > function will loop forever. r3 is the address of our node which becomes our top node r1 is the address of a pointer where to store the address of our top node so it should not be a problem unless you fear that our LSU entry which contains the address of r1 is discarded by our "store [r3],r2" ? > One more point to consider: Do we really need an extra load_tag? > Tagging could as well be done for all loads. It is what I said to Yann. If we have no equivalent of llp/scp, I suppose we don't need an extra load_tag in fact. One pdf file si speaking about a load conditional, that is a load which can fails if locked (like our store conditional). I don't know the advantage. I should reread this pdf. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Mar 21 12:05:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr7r-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:35 +0100 (CET) Received: (qmail 18576 invoked by uid 0); 21 Mar 2002 18:57:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 21 Mar 2002 18:57:53 -0000 Received: by moria.seul.org (Postfix) id 8FA3D14686B; Thu, 21 Mar 2002 13:57:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88AEF1468D5; Thu, 21 Mar 2002 13:57:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a213.home.uni-hannover.de [130.75.232.213]) by moria.seul.org (Postfix) with ESMTP id CB56814686B for ; Thu, 21 Mar 2002 13:57:48 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA01001; Thu, 21 Mar 2002 12:05:22 +0100 Message-ID: <20020321120522.15248@thrai.stud.uni-hannover.de> Date: Thu, 21 Mar 2002 12:05:22 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CAS in FC0 References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <20020320121813.03166@thrai.stud.uni-hannover.de> <003501c1d08c$083e8b40$69e1c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <003501c1d08c$083e8b40$69e1c2d4@ifurita>; from Christophe on Thu, Mar 21, 2002 at 04:53:58AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Mar 21, 2002 at 04:53:58AM +0100, Christophe wrote: [...] > > > loadaddr 0f,r5 > > > move r2,r3 // our node address to push > > > 0: > > > load_tagged [r1],r2 // read top > > > store r2,[r3] // node->link = top > > > store_tagged r3,[r1],r4 // top = node > > > jump.nz r4,r0,r63 // return to caller if ok > > > jump r0,r5 > > > > Yep. But beware! `store r2,[r3]' must not clear the tag, or else this > > function will loop forever. > > r3 is the address of our node which becomes our top node > r1 is the address of a pointer where to store the address of our top node > > so it should not be a problem unless you fear that our LSU entry which contains > the address of r1 is discarded by our "store [r3],r2" ? Exactly. It's not really our problem, as long as our implementation of tags is correct, but it may become a common pitfall for programmers. > > One more point to consider: Do we really need an extra load_tag? > > Tagging could as well be done for all loads. > > It is what I said to Yann. If we have no equivalent of llp/scp, I suppose we > don't need an extra load_tag in fact. > > One pdf file si speaking about a load conditional, that is a load which can > fails if locked (like our store conditional). I don't know the advantage. I > should reread this pdf. Me too. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Mar 21 23:07:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr7w-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:40 +0100 (CET) Received: (qmail 27024 invoked by uid 0); 21 Mar 2002 22:27:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 21 Mar 2002 22:27:09 -0000 Received: by moria.seul.org (Postfix) id 54E1C1467FF; Thu, 21 Mar 2002 17:27:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4AE70146850; Thu, 21 Mar 2002 17:27:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id EA94E1467FF for ; Thu, 21 Mar 2002 17:27:07 -0500 (EST) Received: from ifurita (212.194.232.13) by mail.laposte.net (5.5.044) id 3C91041D0008C3D1 for f-cpu@seul.org; Thu, 21 Mar 2002 23:27:07 +0100 Message-ID: <001d01c1d125$1726d2e0$0de8c2d4@ifurita> From: "Christophe" To: References: <3C96A288.4D0EDB4@f-cpu.org> <20020319213445.40817@thrai.stud.uni-hannover.de> <006901c1cfa0$7545a4e0$ddf0c2d4@ifurita> <20020320121813.03166@thrai.stud.uni-hannover.de> <003501c1d08c$083e8b40$69e1c2d4@ifurita> <20020321120522.15248@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] CAS in FC0 Date: Thu, 21 Mar 2002 23:07:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Thursday, March 21, 2002 12:05 PM Subject: Re: [f-cpu] CAS in FC0 > > > One more point to consider: Do we really need an extra load_tag? > > > Tagging could as well be done for all loads. > > > > It is what I said to Yann. If we have no equivalent of llp/scp, I suppose we > > don't need an extra load_tag in fact. > > > > One pdf file si speaking about a load conditional, that is a load which can > > fails if locked (like our store conditional). I don't know the advantage. I > > should reread this pdf. > > Me too. > Here is the extract where I heard about a load conditionnal : --- Hardware Contention Control As a further extension, a processor can provide a conditional load instruction or Cload. The Cload instruction is a load instruction that succeeds only if the location being loaded does not have an advisory lock set on it, setting the advisory lock when it does succeed. With Cload available, the version number is loaded initially using Cload rather than a normal load. If the Cload operation fails, the thread waits and retries, up to some maximum, and then uses the normal load instruction and proceeds. This waiting avoids performing the update concurrently with another process updating the same data structure. It also prevents potential starvation when one operation takes significantly longer than other operations, causing these other frequently occuring operations to perpetually abort the former. It appears particularly beneficial in large-scale shared memory systems where the time to complete a DCAS-governed operation can be significantly extended by wait times on memory because of contention, increasing the exposure time for another process to perform an interfering operation. Memory references that miss can take 100 times as long, or more, because of contention misses. Without Cload, a process can significantly delay the execution of another process by faulting in the data being used by the other process and possibly causing its DCAS to fail as well. The cost of using Cload in the common case is simply testing whether the Cload succeeded, given that a load of the version number is required in any case. Cload can be implemented using the cache-based advisory locking mechanism implemented in ParaDiGM [8]. Briefly, the processor advises the cache controller that a particular cache line is ``locked''. Normal loads and stores ignore the lock bit, but the Cload instruction tests and sets the cache-level lock for a given cache line or else fails if it is already set. A store operation clears the bit. This implementation costs an extra 3 bits of cache tags per cache line plus some logic in the cache controller. Judging by our experience with ParaDiGM, Cload is quite feasible to implement. --- Ok, so using a load conditional allows us to know if someone is already using our memory place, it seems good between two processors, one can wait for the other to end but for different tasks in the same processor ? task A -: load_locked [r1],r2,r3 ; ok [r1] is not locked so we lock it <<< task switch >>> task B -: loopentry r4 task B -: load_locked [r1],r2,r3 ; failure ! some else is using it task B -: if r3 == 0 jump r0,r4 I dislike it. In fact to handle it well, we would need two tags : one for a lock inter-processor and another one for a lock intra-processor. The load conditional will test the inter-processor lock and set both inter and intra-processor locks. The normal load just sets the intra-processor lock The normal store clears both inter and intra-processor lock The store conditional will test both inter and intra-processor locks and clears both I'm not sure of what I'm speaking about :) so don't flame me ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Mar 22 10:19:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr7y-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:42 +0100 (CET) Received: (qmail 22379 invoked by uid 0); 22 Mar 2002 09:19:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 22 Mar 2002 09:19:56 -0000 Received: by moria.seul.org (Postfix) id D7CCF146803; Fri, 22 Mar 2002 04:19:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 75D0E146817; Fri, 22 Mar 2002 04:19:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 15397146803 for ; Fri, 22 Mar 2002 04:19:53 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203220919.1c7e; Fri, 22 Mar 2002 09:19:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] CAS in FC0 From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Mar 2002 09:19:28 GMT Message-id: <200203220919.1c7e@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: "Christophe" A: Date: 21/03/02 Objet: Re: [f-cpu] CAS in FC0 ----- Original Message ----- From: Michael Riepe To: Sent: Thursday, March 21, 2002 12:05 PM Subject: Re: [f-cpu] CAS in FC0 > > > One more point to consider: Do we really need an extra= load_tag? > > > Tagging could as well be done for all loads. > > > > It is what I said to Yann. If we have no equivalent of l= lp/scp, I suppose we > > don't need an extra load_tag in fact. > > > > One pdf file si speaking about a load conditional, that = is a load which can > > fails if locked (like our store conditional). I don't kn= ow the advantage. I > > should reread this pdf. > > Me too. > Here is the extract where I heard about a load conditionnal = : --- Hardware Contention Control As a further extension, a processor can provide a conditiona= l load instruction or Cload. The Cload instruction is a load instruction that s= ucceeds only if the location being loaded does not have an advisory lock set on = it, setting the advisory lock when it does succeed. With Cload available, the version number is loaded initially= using Cload rather than a normal load. If the Cload operation fails, the thread= waits and retries, up to some maximum, and then uses the normal load instructio= n and proceeds. This waiting avoids performing the update concurrently with = another process updating the same data structure. It also prevents potential= starvation when one operation takes significantly longer than other operatio= ns, causing these other frequently occuring operations to perpetually abort th= e former. It appears particularly beneficial in large-scale shared memory= systems where the time to complete a DCAS-governed operation can be significan= tly extended by wait times on memory because of contention, increasing the e= xposure time for another process to perform an interfering operation. Memory = references that miss can take 100 times as long, or more, because of content= ion misses. Without Cload, a process can significantly delay the execution of an= other process by faulting in the data being used by the other process and pos= sibly causing its DCAS to fail as well. The cost of using Cload in the common case is simply testing= whether the Cload succeeded, given that a load of the version number is requir= ed in any case. Cload can be implemented using the cache-based advisory lock= ing mechanism implemented in ParaDiGM [8]. Briefly, the processor advises = the cache controller that a particular cache line is ``locked''. Norma= l loads and stores ignore the lock bit, but the Cload instruction tests and set= s the cache-level lock for a given cache line or else fails if it is already s= et. A store operation clears the bit. This implementation costs an extra= 3 bits of cache tags per cache line plus some logic in the cache controller.= Judging by our experience with ParaDiGM, Cload is quite feasible to impleme= nt. --- Ok, so using a load conditional allows us to know if someone= is already using our memory place, it seems good between two processors, one = can wait for the other to end but for different tasks in the same processor ? task A -: load_locked [r1],r2,r3 ; ok [r1] is not locked so = we lock it <<< task switch >>> task B -: loopentry r4 task B -: load_locked [r1],r2,r3 ; failure ! some else is us= ing it task B -: if r3 =3D=3D 0 jump r0,r4 I dislike it. In fact to handle it well, we would need two tags : one for = a lock inter-processor and another one for a lock intra-processor. The load conditional will test the inter-processor lock and = set both inter and intra-processor locks. The normal load just sets the intra-processor lock The normal store clears both inter and intra-processor lock The store conditional will test both inter and intra-process= or locks and clears both I'm not sure of what I'm speaking about :) so don't flame me= ;) >>> I don't like to count one the memory subsystem to handel= state of some memory place. Usually, the VM is used to hgandel it. Bu= t it's too slow most of the time. If we use it, it will be diffcult to = implement it with a NUMA syst=E8me (for exemple, with 2 fcpu and each hav= e it's own private DRAM). In that case, we will need some wire on the b= us to give the information to the other syst=E8me. We could implement s= uch things in wishbone BUT it will become impossible to create bridge with= ohter bus which didn't have those line. With CAS cycle (CAS2), it's more easy because the bridge hav= e to lock the bus to made it's 2 (4) transfers.=20 nicO ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Mar 22 19:06:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr86-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:50 +0100 (CET) Received: (qmail 20383 invoked by uid 0); 22 Mar 2002 18:09:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 22 Mar 2002 18:09:54 -0000 Received: by moria.seul.org (Postfix) id 154F61468DB; Fri, 22 Mar 2002 13:09:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 023981468D7; Fri, 22 Mar 2002 13:09:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 6B0AB146859 for ; Fri, 22 Mar 2002 13:09:52 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id LAA00327 for ; Fri, 22 Mar 2002 11:09:45 -0700 (MST) Message-ID: <3C9B72BA.1DCD394A@jetnet.ab.ca> Date: Fri, 22 Mar 2002 11:06:50 -0700 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "f-cpu@seul.org" Subject: [f-cpu] forwarded -- hardware task switching Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Two sites that have hardware task switching in FPGA's. http://www.realfast.se/rfos/products/s16.shtml http://www.xyronsemi.com. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 22 21:32:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16pr8B-0000iQ-00 for ; Tue, 26 Mar 2002 14:36:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 26 Mar 2002 14:36:55 +0100 (CET) Received: (qmail 19974 invoked by uid 0); 22 Mar 2002 22:52:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 22 Mar 2002 22:52:44 -0000 Received: by moria.seul.org (Postfix) id 6BA94146803; Fri, 22 Mar 2002 17:52:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A2951468DC; Fri, 22 Mar 2002 17:52:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a183.home.uni-hannover.de [130.75.232.183]) by moria.seul.org (Postfix) with ESMTP id F2D22146803 for ; Fri, 22 Mar 2002 17:52:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00568; Fri, 22 Mar 2002 21:32:02 +0100 Message-ID: <20020322213201.29677@thrai.stud.uni-hannover.de> Date: Fri, 22 Mar 2002 21:32:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] CAS in FC0 References: <200203220919.1c7e@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200203220919.1c7e@th00.opsion.fr>; from Nicolas Boulay on Fri, Mar 22, 2002 at 09:19:28AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Will people ever learn how to quote e-mails correctly? *sigh* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 27 14:53:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qIMg-0002jv-00 for ; Wed, 27 Mar 2002 19:41:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 27 Mar 2002 19:41:42 +0100 (CET) Received: (qmail 26760 invoked by uid 0); 27 Mar 2002 13:53:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 27 Mar 2002 13:53:26 -0000 Received: by moria.seul.org (Postfix) id BEA55146832; Wed, 27 Mar 2002 08:53:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9F40E146844; Wed, 27 Mar 2002 08:53:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id CA371146832 for ; Wed, 27 Mar 2002 08:53:23 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16qDrd-0006BL-00 for f-cpu@seul.org; Wed, 27 Mar 2002 14:53:21 +0100 Date: Wed, 27 Mar 2002 14:53:21 +0100 (CET) From: Martin Devera To: f-cpu@seul.org Subject: [f-cpu] usage of 64 registers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I'm fairly new in this area as I focus mainly on linux kernel developement. But this project impressed me and I started to learn more about it. I've some question and I hope someone can answer them (and yes I looked archives first to not repeat FAQ). First during my developement days I never seen algorithm (except unrolled loops) which can use 64 regs in one stack frame range. Why didn't you consider register rotation ala ia-64 which allows you to simply generate function calls without memory ops and to do sw pipelining ? Also I've heard that there are problems with SPARC's register window usage, can someone clearify it ? Second question is, how can be the XBar constructed in CMOS ? Is 4*64 to 4*64 xbar simply 1024 pass-thru gates (N-P mos pair) plus tree of invertors to accomodate this fanout ? Or will it consist of latches per port ? Thanks, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Mar 27 15:24:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qIMh-0002jv-00 for ; Wed, 27 Mar 2002 19:41:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 27 Mar 2002 19:41:43 +0100 (CET) Received: (qmail 23853 invoked by uid 0); 27 Mar 2002 14:25:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 27 Mar 2002 14:25:05 -0000 Received: by moria.seul.org (Postfix) id 59819146833; Wed, 27 Mar 2002 09:25:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5535014684D; Wed, 27 Mar 2002 09:25:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 913CA146833 for ; Wed, 27 Mar 2002 09:25:03 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200203271424.3166; Wed, 27 Mar 2002 14:24:49 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Tr:[f-cpu] usage of 64 registers From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Mar 2002 14:24:49 GMT Message-id: <200203271424.3166@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Martin Devera A: f-cpu@seul.org Date: 27/03/02 Objet: [f-cpu] usage of 64 registers Hello, I'm fairly new in this area as I focus mainly on linux kernel developement. But this project impressed me and I started to learn more about it. I've some question and I hope someone can answer them (and yes I looked archives first to not repeat FAQ). First during my developement days I never seen algorithm (except unrolled loops) which can use 64 regs in one stack frame range. >>> Most of the time, if you want to put n (pipeline depth) = cycles between the write of a register and it's read and if you use= cmove trick (to avoid jump), you will have great pressure on the registe= r set, so you will need so much register (there is no OOO in fcpu).=20 Why didn't you consider register rotation ala ia-64 which allows you to simply generate function calls without memory ops and to do sw pipelining ? Also I've heard that there are problems with SPARC's registe= r window usage, can someone clearify it ? >>> I beleive it's the same problem : the handler to make ro= om in case of overflow in the stack of register. In the future, we must= consider such rolling fence. Second question is, how can be the XBar constructed in CMOS = ? Is 4*64 to 4*64 xbar simply 1024 pass-thru gates (N-P mos pa= ir) plus tree of invertors to accomodate this fanout ? Or will it consist of latches per port ? >>> From my point of view, we can't use that. We will use si= mples buses, we don't need a true Xbar ! nicO Thanks, devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Wed Mar 27 17:30:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qIMm-0002jv-00 for ; Wed, 27 Mar 2002 19:41:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 27 Mar 2002 19:41:48 +0100 (CET) Received: (qmail 13326 invoked by uid 0); 27 Mar 2002 16:27:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 27 Mar 2002 16:27:02 -0000 Received: by moria.seul.org (Postfix) id 2ED77146850; Wed, 27 Mar 2002 11:27:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26671146865; Wed, 27 Mar 2002 11:27:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 62049146850 for ; Wed, 27 Mar 2002 11:27:00 -0500 (EST) Received: from art1.none.de ([62.144.185.208]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g2RGR3m11097 for ; Wed, 27 Mar 2002 17:27:03 +0100 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.185.208] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.34 #1 (Debian)) id 16qGJs-0007bF-00 for ; Wed, 27 Mar 2002 17:30:40 +0100 Date: Wed, 27 Mar 2002 17:30:27 +0100 (CET) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] usage of 64 registers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Wed, 27 Mar 2002, Martin Devera wrote: > Second question is, how can be the XBar constructed in CMOS ? > Is 4*64 to 4*64 xbar simply 1024 pass-thru gates (N-P mos pair) > plus tree of invertors to accomodate this fanout ? > Or will it consist of latches per port ? XBar is a wrecked name of this thing. We mean with XBar really a network for connecting ports and units. I prefer a convolved network, like Convolved Benes. Hope to help you... Bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8ofOmClxplZklbgERAsKrAJ9e0PJLfOnrs+qcdJL8HBq5Vp7MtgCfVMFJ K7Cz1oLX+lQpbMTh/tSX5AU= =76WK -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 27 19:27:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qMPj-0005Rq-00 for ; Thu, 28 Mar 2002 00:01:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Mar 2002 00:01:07 +0100 (CET) Received: (qmail 32256 invoked by uid 0); 27 Mar 2002 18:21:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 27 Mar 2002 18:21:30 -0000 Received: by moria.seul.org (Postfix) id 2FA961468D8; Wed, 27 Mar 2002 13:21:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 281861468D5; Wed, 27 Mar 2002 13:21:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id CE6A8146865 for ; Wed, 27 Mar 2002 13:21:29 -0500 (EST) Received: from f-cpu.org (kdl16-232.n.club-internet.fr [213.44.18.232]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 61757173C for ; Wed, 27 Mar 2002 19:21:27 +0100 (CET) Message-ID: <3CA20F12.1E0415CA@f-cpu.org> Date: Wed, 27 Mar 2002 19:27:30 +0100 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] usage of 64 registers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi all, i thought that i could be quiet two or three weeks, away from the computer and enjoying all the gigs that take place currently in Paris, but it seems i have to get back to duty sooner as expected... please be patient and tolerant with me ;-) Andreas Romeyke wrote: > Hello, > > On Wed, 27 Mar 2002, Martin Devera wrote: > > > Second question is, how can be the XBar constructed in CMOS ? > > Is 4*64 to 4*64 xbar simply 1024 pass-thru gates (N-P mos pair) > > plus tree of invertors to accomodate this fanout ? > > Or will it consist of latches per port ? > > XBar is a wrecked name of this thing. We mean with XBar really a network > for connecting ports and units. I prefer a convolved network, like > Convolved Benes. in fact, the "Xbar" name is just a name, its realisation depends on many problems and the used technology. Currently, the "Xbar" stage of the pipeline is two things : - a big buffered line which sends the data from the R7 unit to all the EU inputs (the fanout is to be taken into account) - a big "MUX" which selects the data from the EU outputs and sends it to the R7. in the middle, there is another MUX which selects the real source of the data : it's the bypass thing, which deals with partial writes and reads... For example, you want add.b r1,r2,r3 add.w r3,r4,r5 so the problem is to select the right words to bypass. but it's possible to do that without pulling your hair. > Hope to help you... thanks ;-) i'm late for the gig tonight, forgive my short intervention :-) i'll post in a week or two. > Bye Art1 WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas@seul.org Wed Mar 27 19:43:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qMPj-0005Rq-01 for ; Thu, 28 Mar 2002 00:01:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 28 Mar 2002 00:01:07 +0100 (CET) Received: (qmail 18621 invoked by uid 0); 27 Mar 2002 18:33:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 27 Mar 2002 18:33:52 -0000 Received: by moria.seul.org (Postfix) id 7384C1468DA; Wed, 27 Mar 2002 13:33:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 70E901468D5; Wed, 27 Mar 2002 13:33:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 24972146865; Wed, 27 Mar 2002 13:33:50 -0500 (EST) Received: from seul.org (vlt9-19.n.club-internet.fr [195.36.223.19]) by relay-1m.club-internet.fr (Postfix) with ESMTP id DB914182D; Wed, 27 Mar 2002 19:33:47 +0100 (CET) Message-ID: <3CA212BC.2944176D@seul.org> Date: Wed, 27 Mar 2002 19:43:08 +0100 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] usage of 64 registers References: <3CA20F12.1E0415CA@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi all, > > i thought that i could be quiet two or three weeks, > away from the computer and enjoying all the gigs that > take place currently in Paris, but it seems i have > to get back to duty sooner as expected... > please be patient and tolerant with me ;-) > > Andreas Romeyke wrote: > > Hello, > > > > On Wed, 27 Mar 2002, Martin Devera wrote: > > > > > Second question is, how can be the XBar constructed in CMOS ? > > > Is 4*64 to 4*64 xbar simply 1024 pass-thru gates (N-P mos pair) > > > plus tree of invertors to accomodate this fanout ? > > > Or will it consist of latches per port ? > > > > XBar is a wrecked name of this thing. We mean with XBar really a network > > for connecting ports and units. I prefer a convolved network, like > > Convolved Benes. > > in fact, the "Xbar" name is just a name, its realisation depends on > many problems and the used technology. > > Currently, the "Xbar" stage of the pipeline is two things : > - a big buffered line which sends the data from the R7 unit > to all the EU inputs (the fanout is to be taken into account) It's gate level design ! > - a big "MUX" which selects the data from the EU outputs and > sends it to the R7. It's the decoder of a multiported memory, nothing special. nicO > in the middle, there is another MUX which selects the real source > of the data : it's the bypass thing, which deals with partial > writes and reads... > For example, you want > add.b r1,r2,r3 > add.w r3,r4,r5 > so the problem is to select the right words to bypass. > but it's possible to do that without pulling your hair. > > > Hope to help you... > thanks ;-) > > i'm late for the gig tonight, forgive my short intervention :-) > i'll post in a week or two. > > > Bye Art1 > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hungmin@21cn.com Fri Mar 29 05:03:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16qt1t-0001nY-00 for ; Fri, 29 Mar 2002 10:50:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 29 Mar 2002 10:50:41 +0100 (CET) Received: (qmail 13852 invoked by uid 0); 29 Mar 2002 04:01:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 29 Mar 2002 04:01:44 -0000 Received: by moria.seul.org (Postfix) id 7A805146800; Thu, 28 Mar 2002 23:01:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 638A7146828; Thu, 28 Mar 2002 23:01:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id A98361467FE; Thu, 28 Mar 2002 23:01:41 -0500 (EST) Received: from oemcomputer (unknown [218.66.143.210]) by bettik.munge.net (Postfix) with SMTP id C05B04F776; Thu, 28 Mar 2002 21:58:56 -0600 (CST) From: =?gb2312?q?=B3=C2=B9=FA=C7=BF_ , ?=@munge.net Subject: [f-cpu] =?gb2312?q?=C5=E4=BC=FE=C5=FA=B7=A2=C9=CC?= Date: Fri, 29 Mar 2002 12:03:59 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="92b7699b-ddaf-45fe-b1fc-e7e149eccf13" Message-Id: <20020329035856.C05B04F776@bettik.munge.net> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format --92b7699b-ddaf-45fe-b1fc-e7e149eccf13 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =CE=D2=CB=BE=F4=E9=CC=A8=CD=E5=F6=CE=B4=EF=C3=B3=D2=D7=B9=AB=CB=BE=D7=A4=CF=C3= =C3=C5=B0=EC=CA=C2=B4=A6=A3=AC=B3=A4=C6=DA=B4=D3=CA=C2=CF=C3=C3=C5=D3=EB=B8=DF= =D0=DB=B8=DB=D6=AE=BC=E4=B5=C4=D2=B5=CE=F1=CD=F9=C0=B4=A3=AC=C0=FB=D3=C3 =CE=D2=C3=C7=B5=C4=C7=FE=B5=C0=BA=CD=D4=AD=B3=A7=BD=F8=BB=F5=B5=C4=BC=DB=B8=F1= =D3=C5=CA=C6=A3=AC=D7=DF=CB=BD=D2=BB=D0=A9=B0=B2=B7=C0=A3=BA=C8=E7=C9=E3=CF=F1= =BB=FA=A3=BB=D3=B2=C5=CC=C2=BC=CF=F3=BB=FA=B5=C8=BA=CD=B5=E7=C4=D4=B2=FA=C6=B7= =BC=B0=CF=E0=B9=D8=C5=E4=BC=FE=A3=AC=BD=F1=C4=EA=CE=D2=C3=C7=D2=AA=D4=DA=B9=F3= =B5=D8=C0=A9=D5=B9 =D2=B5 =CE=F1=A3=AC=D1=B0=D5=D2=D2=BB=BC=D2=D3=D0=CA=B5=C1=A6=B5=C4=BE=AD=CF=FA=B5=E3= =A3=AC=BE=DF=CC=E5=B2=D9=D7=F7=B7=BD=B0=B8=C8=E7=CF=C2=A3=BA1=C2=F2=B6=CF=A3= =AC=CE=D2=B7=BD=B0=B4=B9=F3=B7=BD=CB=F9=CC=E1=B9=A9=C7=E5=B5=A5=B9=A9=D3=A6=C9= =CC=C6=B7 =A3=AC=B2=A2=B8=BA=D4=F0=D6=CA=B1=A3=D2=BB=C4=EA=A3=AC=B9=F3=B7=BD=B1=D8=D0=EB= =D6=A7=B8=B6=CF=E0=D3=A6=B5=C4=D7=CA=BD=F0=A3=AC=CA=D7=B4=CE=BF=C9=C1=F410%=CE= =AA=D6=CA=B1=A3=BD=F0=A3=AC=B2=A2=D0=E8=B5=BD=CE=D2=CB=BE=C7=A9=B6=A9=D3=D0=B9= =D8 =B5=C4=CF=FA=CA=DB=BA=CF=CD=AC=A1=A32=A3=AC=C8=E7=D0=E8=D1=F9=C6=B7=A3=AC=D4= =DA=B9=F3=B7=BD=B2=BB=C4=DC=C5=C9=C8=CB=C7=B0=C0=B4=B5=C4=C7=E9=BF=F6=CF=C2=A3= =AC=B8=F9=BE=DD=BF=CD=BB=A7=D2=AA=C7=F3=A3=AC=BF=C9=CA=D3=C7=E9 =BF=F6=A3=AC=CF=C8=B8=B640%=A1=AA80%=B5=C4=B6=A8=BD=F0=A3=AC=CE=D2=B7=BD=B2=C9= =D3=C3=BA=BD=BF=D5=BF=EC=B5=DD=B5=C4=B7=BD=B7=A8=D3=CA=BC=C4=A3=AC=D3=CA=BC=C4= =D1=F9=C6=B7=BD=F0=B6=EE=D7=EE=B8=DF5=CD=F2=D4=AA=D2=D4=C4=DA=A1=A3 3=A3=AC=B4=FA=C0=ED=A3=BA=B3=FD=C1=CB=D2=AA=B5=BD=CE=D2=CB=BE=C7=A9=B6=A9=B4= =FA=C0=ED=BA=CF=D4=BC=A3=AC=C3=BF=D4=C2=D7=EE=B5=CD=CF=FA=CA=DB=BD=F0=B6=EE=B2= =BB=C4=DC=B5=CD=D3=DA50=CD=F2=D4=AA=A3=AC=C9=CF=B2=BB=B7=E2=B6=A5=A3=AC=B2=A2= =CC=E1 =B9=A930%=D7=F7=CE=AA=B1=A3=D6=A4=BD=F0=A3=AC=C8=F4=B4=FA=C0=ED=B2=FA=C6=B7=B3= =AC=B3=F650=CD=F2=D4=AA=A3=AC=D4=F2=B0=B4=CA=B5=BC=CA=BD=F0=B6=EE=B5=C430%=D7= =F7=CE=AA=B1=A3=D6=A4=BD=F0=A3=AC=BB=F5=BF=EE=C3=BF=D4=C2=BD=E1=CB=E3 =D2=BB =B4=CE=A3=AC=B1=A3=D6=A4=BD=F0=B3=A4=C6=DA=D1=BA=D4=DA=CE=D2=CB=BE=A3=AC=C8=E7= =B4=FA=C0=ED=BA=CF=CD=AC=C6=DA=C2=FA=A3=AC=B1=A3=D6=A4=BD=F0=D3=EB=CE=B4=BD=E1= =CB=E3=BB=F5=BF=EE=CF=E0=BF=DB=A3=AC=B6=E0=CD=CB=C9=D9=B2=B9=A1=A3=BA=CD=CE=D2= =CB=BE =BA=CF =D7=F7=C0=FB=C8=F3=B9=B2=CF=ED=A3=AC=B7=E7=CF=D5=B9=B2=B5=A3=A3=AC=C8=E7=D3=D0= =D2=E2=BA=CF=D7=F7=A3=AC=BE=DF=CC=E5=B2=D9=D7=F7=B7=BD=B0=B8=C7=EB=BA=CD=CE=D2= =CB=BE=B3=C2=B9=FA=C7=BF=BE=AD=C0=ED =C1=AA=CF=B5=A3=AC=B5=E7=BB=B0=A3=BA05953117594=A3=AC013850735096 =C1=ED=B8=BD=D2=BB=B7=DD=BC=DB=B8=F1=B1=ED=B9=A9=B2=CE=D4=C4=A3=A825=CC=EC=CE= =AA=D2=BB=B1=A8=BC=DB=A3=A9 =F6=CE=B4=EF=B9=AB=CB=BE=D0=C5=CF=A2=BF=C6 =CD=B6 =D3=B0 =BB=FA =B1=A8 =BC=DB =B1=ED=A3=A8=C8=FD=C1=E2=A3=A9 =D0=F2=BA=C5 =D0=CD =BA=C5 =C3=FB =B3=C6 =BC=B0 =B9=E6 =B8=F1 =B5=A5 =BC=DB 1 LVP-SA51U 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3 9700.00=D4=AA 2 LVP-S50UX 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3 10000.00=D4=AA 3 LVP-XD200U 2000ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 21500.00=D4=AA 4 LVP-SL1U 1200ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12000.00=D4=AA 5 LVP-XL1U 1200ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 14000.00=D4=AA 6 LVP-S290U 1800ANSI 800=A1=C1600 =CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12500.00=D4=AA 7 LVP-X70BU 1300ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 12000.00=D4=AA 8 LVP-X80U 1800ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 15000.00=D4=AA 9 LVP-X400BU 3200ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 27000.00=D4=AA 10 LVP-S490U 2600ANSI 800=A1=C1600=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 19000.00=D4=AA 11 LVP-X490U 2600ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 22000.00=D4=AA 12 LVP-X500BU 3700ANSI 1024=A1=C1768=CF=F1=CB=D8540=CF=DF =CA=FD=C2=EB=B7=C5=B4=F3=CB=AB=D1= =B6=BA=C5=D4=B4=CF=D4=CA=BE(=BB=AD=D6=D0=BB=AD) 38000.00=D4=AA =C3=C0=B9=FA =B2=A8=CC=D8=A3=A8BOTER=A3=A9=B2=FA=C6=B7=B1=A8=BC=DB=B5=A5 =D0=F2=BA=C5 =D0=CD=BA=C5 =B9=E6 =B8=F1 =B5=A5=BC=DB =B2=CA=C9=AB=C9=E3=CF=F1=BB=FA 1 BTC-220 1/3=A1=E5420=CF=DF0.3LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC DC12V/AC24V 1100.00=D4=AA 2 BTC-222 1/3=A1=E5480=CF=DF0.3LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC DC12V/AC24V 1700.00=D4=AA 3 BTC-230 1/3=A1=E5420=CF=DF0.1LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 = 85~265VAC DC12V/AC24V 1280.00=D4=AA 4 BTC-232 1/3=A1=E5480=CF=DF0.1LuxF1.2=B3=AC=B1=B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA= =C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 = 85~265VAC DC12V/AC24V 2050.00=D4=AA 5 BTC-250 1/3=A1=E5420=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9=E2= =B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0= =C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA 85~265VAC = DC12V/AC24V 1640.00=D4=AA 6 BTC-252 1/3=A1=E5480=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9=E2= =B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=ACY/C=D0= =C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA 85~265VAC = DC12V/AC24V 1960.00=D4=AA 7 BTC-270/IR 1/3=A1=E5420=CF=DF0~0.01LuxF1.2=B3=AC=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1= =B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6= =ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA = 85~265VAC DC12V/AC24V 3000.00=D4=AA 8 BTC-272/IR 1/3=A1=E5480=CF=DF0~0.01LuxF1.2=B3=AC=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1= =B3=B9=E2=B2=B9=B3=A5=B9=A6=C4=DC=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6= =ACY/C=D0=C5=BA=C5=CA=E4=B3=F6 =B4=F8VD=CD=E2=CD=AC=B2=BD=BD=D3=BF=DA = 85~265VAC DC12V/AC24V 3100.00=D4=AA =BA=DA=B0=D7=C9=E3=CF=F1=BB=FA 1 BTC-130 1/3=A1=E5420=CF=DF0~0.01LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 700.00=D4=AA 2 BTC-132 1/3=A1=E5570=CF=DF0~0.01LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1020.00=D4=AA 3 BTC-150 1/3=A1=E5420=CF=DF0~0.001LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1050.00=D4=AA 4 BTC-152 1/3=A1=E5570=CF=DF0~0.001LuxF1.2=B5=CD=D5=D5=B6=C8=CA=B5=CA=B1=B3=AC=B1=B3=B9= =E2=B2=B9=B3=A5=BA=DA=B0=D7=C9=E3=CF=F1=BB=FA SONY=D0=BE=C6=AC85~265VAC = DC12V/AC24V 1800.00=D4=AA =B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA 1 BTD-420CP 1/3=A1=E5420=CF=DF0.3LuxF1.2=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 800.00=D4=AA 2 BTD-422CP 1/3=A1=E5480=CF=DF0.3LuxF1.2=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 1200.00=D4=AA 3 BTD-440CP 1/3=A1=E5420=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3= =CF=F1=BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1000.00=D4=AA 4 BTD-442CP 1/3=A1=E5480=CF=DF0.05LuxF1.2=B5=CD=D5=D5=B6=C8=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3= =CF=F1=BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1570.00=D4=AA =BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA 1 BTD-410BP 1/3=A1=E5420=CF=DF0.1LuxF1.2=BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 500.00=D4=AA 2 BTD-412BP 1/3=A1=E5570=CF=DF0.1LuxF1.2=BA=DA=B0=D7=B0=EB=C7=F2=C9=E3=CF=F1=BB=FA SONY=D0= =BE=C6=ACDC12V/AC24V 700.00=D4=AA 3 BTD-430BP 1/3=A1=E5420=CF=DF0.05LuxF1.2=BA=DA=B0=D7=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1= =BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 598.00=D4=AA 4 BTD-432BP 1/3=A1=E5570=CF=DF0.05LuxF1.2=BA=DA=B0=D7=B2=CA=C9=AB=B0=EB=C7=F2=C9=E3=CF=F1= =BB=FA SONY=D0=BE=C6=ACDC12V/AC24V 1090.00=D4=AA =B2=CA=C9=AB=BC=E0=CA=D3=C6=F7 1 BTM-140A 14=A1=E5450=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 1700.00=D4=AA 2 BTM-142A 14=A1=E5600=CF=DF4=C2=B7=D2=F4=CA=D3=C6=B5=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3= =C6=F7 2200.00=D4=AA 3 BTM-142B 14=A1=E5720=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 S-Video=D0=C5=BA= =C5=CA=E4=C8=EB 3000.00=D4=AA 4 BTM-210A 21=A1=E5450=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 3400.00=D4=AA 5 BTM-212A 21=A1=E5600=CF=DF=B2=CA=C9=AB=CA=FD=C2=EB=BC=E0=CA=D3=C6=F7 S-Video=D0=C5=BA= =C5=CA=E4=C8=EB 4100.00=D4=AA =C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB=FA 1 BTV-410 4=C2=B7=D2=F4=CA=D3=C6=B5=CD=AC=B2=BD=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF= =F1=BB=FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C340GB=D3=B2=C5=CC =B4=F8=D2=A3=BF= =D8=C6=F7 36000.00=D4=AA 2 BTV-420 4=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB= =FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C330GB=D3=B2=C5=CC 20000.00=D4=AA 3 BTV-1600 16=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB=C7=B6=C8=EB=CA=BD=D3=B2=C5=CC=C2=BC=CF=F1=BB= =FA =D3=A2=CE=C4=B2=CB=B5=A5=C4=DA=D6=C345GB=D3=B2=C5=CC 41000.00=D4=AA =CD=BC=CF=F1=CD=F8=C2=E7=B7=FE=CE=F1=C6=F7 1 BTN-4100 4=C2=B7=CA=D3=C6=B5=CA=E4=C8=EB =B4=AB=CA=E4=CB=D9=C2=CA=BF=C9=B4=EF25=D6=A1= /=C3=EB =D4=B6=B3=CC=BF=D8=D6=C6=D4=C6=CC=A8=BE=B5=CD=B7 8000.00=D4=AA =B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 1 AG-TL350 24=D0=A1=CA=B1=B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 3500.00=D4=AA 2 HS-1024E(H) 24=D0=A1=CA=B1=B3=A4=CA=B1=BC=E4=C2=BC=CF=F1=BB=FA 3300.00=D4=AA =D6=B8=CE=C6=BF=BC=C7=DA=BB=FA 1 FDA-01 =B5=A5=BB=FA=D0=CD=D6=B8=CE=C6=BF=BC=C7=DA=BB=FA(720=C3=B6/=CC=A8) 7000.00=D4=AA =BB=AD=C3=E6=B7=D6=B8=EE=C6=F7 1 SLT-401 =CB=C4=C2=B7=B2=CA=C9=AB=BB=AD=D6=D0=BB=AD=B7=D6=B8=EE=C6=F7 =B4=F8=B6=FE=A1= =A2=C8=FD=A1=A2=CB=C4=B7=D6=B8=EE =B4=F8=BB=D8=B7=C5(=CB=AB=B9=A6) 2200.00=D4=AA 2 SLT-4D =CB=C4=C2=B7=BA=DA=B0=D7=BB=AD=D6=D0=BB=AD=B7=D6=B8=EE=C6=F7 =B4=F8=BB=D8=B7= =C5(=CB=AB=B9=A6) 700.00=D4=AA 3 MV-96e 16=C2=B7=BB=AD=C3=E6=B4=A6=C0=ED=C6=F7(ROBOT) 2400.00=D4=AA =BA=AB=B9=FA=C8=FD=D0=C7=BA=BD=BF=D5=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA=A3=BA SDZ-160R/L 1/4=A1=B1=BF=ED=B6=AF=CC=AC=BA=CD=B3=AC=BC=B6=B1=B3=B9=E2=B2=B9=B3= =A516XCCD=B2=CA=C9=AB=C9=E3=CF=F1=BB=FA 1500=D4=AA SDC-250PA 1/3=A1=B1=A3=A8=CD=AC=C9=CF=A3=A9 = 1050=D4=AA SDC-450PA1/3=A1=B1=A3=A8=CD=AC=C9=CF=A3=A9 = 1450=D4=AA SPD-16001/4=A1=B1=B4=F8=D4=C6=CC=A8=B5=C4=BF=ED=B6=AF=CC=AC=BA=CD=B3=AC=BC=B6= =B1=B3=B9=E2=B2=B9=B3=A5=B2=CA=C9=AB=C7=F2=D0=CE=C9=E3=CF=F1=BB=FA 6500=D4=AA= =BA=AB=B9=FA=CA=FD=D7=D6=D3=B2=C5=CC=B2=CA=C9=AB=C2=BC=CF=F3=CF=B5=CD=B3 SVR-400 4=C2=B7=C2=BC=CF=F3=BB=FA=A3=A8=B4=F845G=D3=B2=C5=CC=A3=A9 = 10500=D4=AA SVR-1600 16=C2=B7=C2=BC=CF=F3=BB=FA=A3=A8=B4=F8=CD=B745G=D3=B2=C5=CC=A3=A9 = 19500=D4=AA =B5=E7=C4=D4=C5=E4=BC=FE=A3=BA=BB=AA=CB=B6=A3=A8=D6=F7=B0=E5=A3=A9 TUSL2-C/WOA 815EP-B=D0=BE=C6=AC/ATA100/AGP4X/=D6=A7=B3=D6.13P=A2=F3(Tualatin) = 400 =D4=AA TUSL2-M/SWA(=D0=A1=B0=E5) 815EP-B=D0=BE=C6=AC/ATA100/AGP4X/=BA=ACI752=CF=D4=BF= =A8/AC97=C9=F9=BF=A8/=D6=A7=B3=D6(Tualatin)470 =D4=AA TUEP2-M/SWA 815EP=D0=BE=C6=AC/ATA100/AGP4X/=CE=DE=CF=D4=BF=A8/AC97=C9=F9=BF=A8= 350 =D4=AA P4T-F/PA Intel 850=D0=BE=C6=AC/Socket423/AGP4X/4=CC=F5RDRAM/AC97=C9=F9=BF=A8 = 700 =D4=AA P4T-F Intel 850=D0=BE=C6=AC/Socket423 P4/AGP4X/4=CC=F5RDRAM/=CE=DE=C9=F9=BF=A8= 550 =D4=AA A7V266 VIA KT266=D0=BE=C6=AC=D7=E9/=D6=A7=B3=D6UDMA100=A3=ACAGP 4X/=D6=A7=B3= =D6200.266FSB=C0=D7=C4=F1=D7=EA=C1=FASOCKET 462/ATX=BD=E1=B9=B9 460 =D4=AA A7VL-VM KL133=D0=BE=C6=AC/ATA100/SVAGAE4=CF=D4=BF=A8/AC97=C9=F9=BF=A8 240 =D4= =AA TUV4X/PA VIA 694T=D0=BE=C6=AC/ATA100/AGP4X/=BA=AC8738=D3=B2=C9=F9=BF=A8/=D6=A7= =B3=D6Tualatin 300 =D4=AA TUV4X/WOA VIA 694T=D0=BE=C6=AC/ATA100/AGP4X/=D6=A7=B3=D6Tualatin/=CE=DE=C9=F9= =BF=A8 360 =D4=AA CUVL-VM PL133=D0=BE=C6=AC/ATA100/SAVAGAE4=CF=D4=BF=A8/AC97=C9=F9=BF=A8 300 =D4= =AA CUSI-M/LAN SIS 630E=D0=BE=C6=AC/ATA66/=B4=F8SIS300=CF=D4=BF=A8/SIS900=CD=F8=BF= =A8/8378=D3=B2=C9=F9=BF=A8 330 =D4=AA P4S333 SIS645/DDR/CMI8738 6-CH S4700 =D4=AA P4B266-M/SWALAN 845D/DDR/S478/AC97630 =D4=AA =CE=A2=D0=C7 MS-6532 Intel850/400MHz=D7=DC=CF=DF/423=BD=E1=B9=B9/=D6=A7=B3=D6P4 2G=CB=AB=CD= =A8=B5=C0/4=CC=F5RAMBUS=C4=DA=B4=E6/AC97=C9=F9=BF=A8/4=CC=F5PCI/1=CC=F5= AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR 500 =D4=AA 850 Pro5 Intel850/400MHz=D7=DC=CF=DF/P4 478=BD=E1=B9=B9/4=CC=F5RAMBUS=C4=DA=B4= =E6/8378=C9=F9=BF=A8/AGP4X/2X 600 =D4=AA MS-6529 Intel845/400MHz=D7=DC=CF=DF/P4 423=BD=E1=B9=B9/3=CC=F5SDRAM=C4=DA=B4= =E6/AC97=C9=F9=BF=A8/5=CC=F5PCI/1=CC=F5AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR = 420 =D4=AA MS-6528 Intel845/P4 478=BD=E1=B9=B9/SDRAM=C4=DA=B4=E6/8738=C9=F9=BF=A8/6=CC=F5= PCI/1=CC=F5AGP/4=B8=F6USB=BD=D3=BF=DA/1=B8=F6CNR 600 =D4=AA Pro266 Plus VIA266/100/133/Socket 370/3=CC=F5DDR=C4=DA=B4=E6/=D6=A7=B3=D6= PCT2PC/AC97=C9=F9=BF=A8/ATA100/6=CC=F5PCI/1=CC=F5AGP 260 =D4=AA MS-6337-50B Intel 815EP/=D6=A7=B3=D6P=A2=F3=A1=A2=C8=FC=D1=EF=CF=B5=C1=D0/=D6= =A7=B3=D6133MHzCPU/PC133=C4=DA=B4=E6/Socket 370/ATA100/AC97=C9=F9=BF=A8/6=CC= =F5PCI/1=CC=F5AGP/ATX=BD=E1=B9=B9 300 =D4=AA MS-6337-50B-Raid Intel 815EP/ATX=BD=E1=B9=B9/Socket 370=BD=D3=BF=DA/133CPU=CD= =E2=C6=B5/ATA100/AC97=C9=F9=BF=A8/=D6=A7=B3=D6PC2PC=CD=F8=C2=E7=B9=A6=C4=DC= /6=CC=F5PCI/1=CC=F5AGP/=B4=F8=B4=C5=C5=CC=D5=F3=C1=D0 400 =D4=AA MS-6315EP Intel 815EP/ATX=BD=E1=B9=B9/Socket 370/AC97=C9=F9=BF=A8/3=CC=F5= PCI/1=CC=F5AGP 290 =D4=AA MS-6315E Intel 815/ATX=BD=E1=B9=B9/Socket 370/AC97=C9=F9=BF=A8/3=CC=F5PCI/1=CC= =F5AGP/1=CC=F5CNR 370 =D4=AA MS-6337 Intel 815E B-Step/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8= /=D6=A7=B3=D6PC2PC=CD=F8=C2=E7=B9=A6=C4=DC/6=CC=F5PCI/1=CC=F5AGP/4=CC=F5=C4=DA= =B4=E6=B2=DB 400 =D4=AA 6368 VIA PLE133/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8/=B4=F8= 9880=CF=D4=BF=A8 180 =D4=AA 6368 VIA PLE133/ATX=BD=E1=B9=B9/Socket 370/ATA100/AC97=C9=F9=BF=A8/=B4=F8= 9880=CF=D4=BF=A8/=B4=F88139C=CD=F8=BF=A8 200 =D4=AA 694T Pro VIA 694T/686B/ATX=BD=E1=B9=B9/Socket370/=D6=A7=B3=D6P=A2=F3=BC=B0=C8= =FC=D1=EFCPU/AC97=C9=F9=BF=A8/1=CC=F5AGP/5=CC=F5PCI/1=CC=F5AMR 300 =D4=AA 6330 VIA KT133/ATX 200MHz=D7=DC=CF=DF/=D5=EC=B4=ED=B5=C6/=CB=CD=D7=D4=B6=AF=B3= =AC=C6=B5=C8=ED=BC=FE/1=CC=F5AGP/6=CC=F5PCI/=B2=BB=D6=A7=B3=D6Athlon XP 200 = =D4=AA K7T Turbo-NL VIA KT133A/266MHz=D7=DC=CF=DF/AC97=C9=F9=BF=A8/=D7=D4=B6=AF=C9=CF= =CD=F8=CB=A2=D0=C2BIOS/1=CC=F5AGP/5=CC=F5PCI/1=CC=F5CNR/ATX/=B2=BB=D6=A7=B3=D6= Athlon XP 290 =D4=AA K7T Turbo-R Limited VIA KT133A/266MHz=D7=DC=CF=DF/AC97=C9=F9=BF=A8/=D7=D4=B6= =AF=C9=CF=CD=F8=CB=A2=D0=C2BIOS/1=CC=F5AGP/6=CC=F5PCI/1=CC=F5CNR/ATX/=B2=BB=D6= =A7=B3=D6Athlon XP/=CF=DE=C1=BF=B7=A2=D0=D0=BA=EC=C4=A7=B0=E5/=D6=A7=B3=D6= PC2PC=CD=F8=C2=E7=B9=A6=C4=DC/=B4=F8=B4=C5=C5=CC=D5=F3=C1=D0 300=D4=AA Intel =A3=A8=D6=D0=D1=EB=B4=A6=C0=ED=C6=F7=A3=A9 =B1=BC=CC=DA4 2.2G Socket 478/512KB/400MHz /=BA=D0=D7=B0 3500 =D4=AA =B1=BC=CC=DA4 2.0A Socket 478/512KB/400MHz /=BA=D0=D7=B0 2000 =D4=AA =B1=BC=CC=DA4 2.0G Socket 478/256KB/400MHz /=BA=D0=D7=B0 2000 =D4=AA =B1=BC=CC=DA4 1.9G Socket 478/256KB/400MHz /=BA=D0=D7=B0 1050 =D4=AA =B1=BC=CC=DA4 1.8A Socket 478/512KB/400MHz /=BA=D0=D7=B0 900 =D4=AA =B1=BC=CC=DA4 1.7G Socket 478/256KB/400MHz /=BA=D0=D7=B0 750 =D4=AA =B1=BC=CC=DA4 1.6A Socket 478/512KB/400MHz /=BA=D0=D7=B0 700 =D4=AA =B1=BC=CC=DA4 1.5G Socket 478/256KB/400MHz /=BA=D0=D7=B0 590 =D4=AA =B1=BC=CC=DA=A2=F3 1G Socket 370/256K/133=D5=D7/=BA=D0=D7=B0 570=D4=AA =B1=BC=CC=DA=A2=F3 933 Socket 370/256K/133=D5=D7/=BA=D0=D7=B0 520 =D4=AA =C8=FC=D1=EF=A2=F3 1.3G Socket 370/256KB/100MHz/=BA=D0=D7=B0 700 =D4=AA =C8=FC=D1=EF=A2=F3 1.2G Socket 370/256k/100=D5=D7/0.13=A6=CCm/=BA=D0=D7=B0 = 650=D4=AA =C8=FC=D1=EF=A2=F31000A Socket370/.13um/256K/100=D5=D7/=BA=D0=D7=B0 400 =D4=AA= =C8=FC=D1=EF=A2=F31000A Socket370/.13um/256K/100=D5=D7/=C9=A2=D7=B0 330 =D4=AA= =C8=FC=D1=EF=A2=F21000 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 345 =D4=AA =C8=FC=D1=EF=A2=F2950 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 300 =D4=AA =C8=FC=D1=EF=A2=F2900 Socket 370/128k/100=D5=D7/=BA=D0=D7=B0 240 =D4=AA =C8=FC=D1=EF=A2=F2 850 Socket 370/128k/100=D5=D7/=C9=A2=D7=B0250=D4=AA =C8=FC=D1=EF=A2=F2800 Socket370/128K/100=D5=D7/=C9=A2=D7=B0 270 =D4=AA =C8=FC=D1=EF=A2=F2 733 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 220 =D4=AA =C8=FC=D1=EF=A2=F2 667 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 200=D4=AA =C8=FC=D1=EF=A2=F2 633 Socket 370/128k/66=D5=D7/=C9=A2=D7=B0180=D4=AA =C8=FC=D1=EF=A2=F2 566 Socket 370/128K/66=D5=D7/=C9=A2=D7=B0 170=D4=AA =C4=DA=B4=E6=CC=F5 Hy 128M T-H/168PIN SDRAM/PC133(=CB=AB=C3=E6) 150 =D4=AA 128M T-H/168PIN SDRAM/PC133(=B5=A5=C3=E6) 150 =D4=AA 256M T-H/168PIN SDRAM/PC133 330 =D4=AA 128M DDR 184PIN DDR RAM/=D4=AD=B3=A7=C4=DA=B4=E6 160 =D4=AA 256M DDR 184PIN DDR RAM/=D4=AD=B3=A7=C4=DA=B4=E6 350 =D4=AA 512M T-S/168PIN SDRAM/PC133 520 =D4=AA Kingmax 128M 6ns/168PIN SDRAM/PC150 150 =D4=AA 256M 6ns/168PIN SDRAM/PC-150 340 =D4=AA 256M 6ns/168PIN SDRAM/PC150(2.0=B0=E6) 345=D4=AA 128MB 128MB DDR RAM/PC2700 190 =D4=AA 256MB 256MB DDR RAM/PC2700 380 =D4=AA IBM(=D3=B2=C5=CC=A3=A9 =CC=DA=C1=FA=C8=FD=B4=FA60GXP/40AV 40GB/ATA/100/2MB/7200rpm/IDE 430 =D4=AA =CC=DA=C1=FA=C8=FD=B4=FA60GXP/60AV 60GB/ATA/100/2MB/7200rpm/IDE 570 =D4=AA =CC=DA=C1=FA=CB=C4=B4=FA120GXP/40AVV 40GB/ATA/100/2MB/7200rpm/IDE 500 =D4=AA =CC=DA=C1=FA=CB=C4=B4=FA120GXP/80AVV 80GB/ATA/100/2MB/7200rpm/IDE 700 =D4=AA DMDM-10340 340M/128K/3600rpm/IBM =D0=A1=D3=B2=C5=CC/=CA=CA=D3=C3=D3=DA=BF=A8= =CE=F7=C5=B7=A1=A2=BF=C2=B4=EF=B5=C8=CA=FD=C2=EB=CF=E0=BB=FA/=BF=C9=D3=EB=B1= =CA=BC=C7=B1=BE=B5=E7=C4=D4=C1=AC=BD=D3 800 =D4=AA DMDM-11000 1G/128K/3600rpm/IBM =D0=A1=D3=B2=C5=CC/=CA=CA=D3=C3=D3=DA=BF=A8=CE= =F7=C5=B7=A1=A2=BF=C2=B4=EF=B5=C8=CA=FD=C2=EB=CF=E0=BB=FA/=BF=C9=D3=EB=B1=CA= =BC=C7=B1=BE=B5=E7=C4=D4=C1=AC=BD=D3 1500 =D4=AA =D7=EA=CA=AF =C3=C0=D7=EA=B6=FE=B4=FA/2B020H1 20GB/UDMA 100/5400rpm/2M/IDE 300 =D4=AA =D0=C7=D7=EA=B6=FE=B4=FA/4W060H4 60GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 30GB/ 600 =D4=AA =D0=C7=D7=EA=B6=FE=B4=FA/4W080H4 80GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 30GB/ 700=D4=AA =D0=C7=D7=EA=C8=FD=B4=FA/4D040H2 40GB/UDMA 100/5400rpm/2M/IDE/=B5=A5=B5=FA= 40GB 300 =D4=AA =BD=F0=D7=EA=C1=F9=B4=FA/AS20 20G/UDMA 100/2MB/7200rpm/IDE/3.5=B4=E7 310=D4=AA= =BD=F0=D7=EA=C1=F9=B4=FA/AS30 30G/UDMA 100/2MB/7200rpm/IDE/3.5=B4=E7 390=D4=AA= =BD=F0=D7=EA=C6=DF=B4=FA/6L020J/L1 20GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB420=D4=AA =BD=F0=D7=EA=C6=DF=B4=FA/6L040J/L2 40GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB 510=D4=AA =BD=F0=D7=EA=C6=DF=B4=FA/6L060J/L3 60GB/UDMA 133/7200rpm/2M/IDE/=B5=A5=B5=FA= 40GB600=D4=AA =B4=BF=C6=BD=CF=D4=CA=BE=C6=F7 =C8=FD=D0=C7 755DF 17=A1=B1800 450B 14=A1=B1500 550B 15=A1=B1620 750S 17=A1=B1 900 950P 19=A1=B1 1400 =B7=C9=C0=FB=C6=D1 105S 15=A1=B1320 105B 15=A1=B1 500 105G 15=A1=B1 580 107E 17=A1=B1 700 107T 17=A1=B1 900 107P 17=A1=B1 105 0 --92b7699b-ddaf-45fe-b1fc-e7e149eccf13-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 29 13:36:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16r9v5-0004zK-01 for ; Sat, 30 Mar 2002 04:52:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 30 Mar 2002 04:52:47 +0100 (CET) Received: (qmail 23468 invoked by uid 0); 30 Mar 2002 00:16:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 30 Mar 2002 00:16:02 -0000 Received: by moria.seul.org (Postfix) id B43761467F1; Fri, 29 Mar 2002 19:16:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9EFA11467F7; Fri, 29 Mar 2002 19:16:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a185.home.uni-hannover.de [130.75.232.185]) by moria.seul.org (Postfix) with ESMTP id 10F8A1467F1 for ; Fri, 29 Mar 2002 19:16:00 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00447; Fri, 29 Mar 2002 13:36:48 +0100 Message-ID: <20020329133648.03556@thrai.stud.uni-hannover.de> Date: Fri, 29 Mar 2002 13:36:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Re: =?iso-8859-1?Q?=5Bf-cpu=5D_=C5=E4=BC=FE=C5=FA=B7=A2=C9=CC?= References: <20020329035856.C05B04F776@bettik.munge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020329035856.C05B04F776@bettik.munge.net>; from =?gb2312?q?=B3=C2=B9=FA=C7=BF_ on Fri, Mar 29, 2002 at 12:03:59PM +0800 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ni3 hao3, <-- that's "hello" in chinese... On Fri, Mar 29, 2002 at 12:03:59PM +0800, =?gb2312?q?=B3=C2=B9=FA=C7=BF_ wrote: [...] I guess we can filter out messages that contain "=?gb2312?q?=" in their subjects. Most of us can't read them anyway. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 3 19:37:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16syjR-0001OI-00 for ; Thu, 04 Apr 2002 06:20:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Apr 2002 06:20:17 +0200 (CEST) Received: (qmail 26920 invoked by uid 0); 3 Apr 2002 17:37:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 3 Apr 2002 17:37:48 -0000 Received: by moria.seul.org (Postfix) id 26AD6146808; Wed, 3 Apr 2002 12:37:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0766714686B; Wed, 3 Apr 2002 12:37:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id A1FA0146808 for ; Wed, 3 Apr 2002 12:37:46 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16sohc-0001wz-00 for f-cpu@seul.org; Wed, 03 Apr 2002 19:37:44 +0200 Date: Wed, 3 Apr 2002 19:37:44 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP In-Reply-To: <200203271424.3166@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > First during my developement days I never seen algorithm > (except unrolled loops) which can use 64 regs in one stack > frame range. > > >>> Most of the time, if you want to put n (pipeline depth) cycles > between the write of a register and it's read and if you use cmove trick > (to avoid jump), you will have great pressure on the register set, so > you will need so much register (there is no OOO in fcpu). Ok so that is assumption below true ? - To keep pipeline full the program must exhibit ILP at least 5 at each place. If so, does it mean that binary tree or linked list handling will cause about 4 cycles big bubbles in the pipeline ? :-0 I have had hard time optimizing QoS queue in linux kernel for gigabit flow eth the code is full of list and tree searches ... By the way anybody knows granularity of IA32,IA64 amd 21256 pipeline ? have a nice day, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Apr 3 21:51:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16syjX-0001OI-00 for ; Thu, 04 Apr 2002 06:20:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Apr 2002 06:20:23 +0200 (CEST) Received: (qmail 7696 invoked by uid 0); 3 Apr 2002 19:45:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 3 Apr 2002 19:45:26 -0000 Received: by moria.seul.org (Postfix) id C919E1468DE; Wed, 3 Apr 2002 14:45:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C62721468DD; Wed, 3 Apr 2002 14:45:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 8ACF614681E for ; Wed, 3 Apr 2002 14:45:17 -0500 (EST) Received: from f-cpu.org (kdl12-77.n.club-internet.fr [213.44.10.77]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 9AFAB16D6 for ; Wed, 3 Apr 2002 21:45:19 +0200 (CEST) Message-ID: <3CAB5D38.8784B2B4@f-cpu.org> Date: Wed, 03 Apr 2002 21:51:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Martin Devera wrote: > > First during my developement days I never seen algorithm > > (except unrolled loops) which can use 64 regs in one stack > > frame range. > > > > >>> Most of the time, if you want to put n (pipeline depth) cycles > > between the write of a register and it's read and if you use cmove trick > > (to avoid jump), you will have great pressure on the register set, so > > you will need so much register (there is no OOO in fcpu). > > Ok so that is assumption below true ? > - To keep pipeline full the program must exhibit ILP at > least 5 at each place. not exactly. We are currently working on a single-issue superpipeline core where each operation (except a few exceptions) can be pipelined. If most units have 2 cycles of latency (for example now), it's a bit like working with a 3-issue superscalar CPU. In FC0, the ILP depends on the kind of operations to perform. Fortunately, most code is a mix of different operation types. Currently, there is only integer arithmetic operations, so an addition requires 2 cycles and a multiply up to 8 cycles. An average necessary ILP is around 3 or 4 for safety. For FP, this is going to increase (2 or 3x ?) but let's concentrate on what works. And thanks to the large number of registers and the pipeline units, if the latency of a single operation does not fit inside a simple loop, you can "software pipeline" the loop : duplicate each instruction and rename each register of the copy (something like adding 32 to each register number). The loop size increases but the stalls are filled with useful operations. This is one very good reason for having a large register set. > If so, does it mean that binary tree or linked list handling > will cause about 4 cycles big bubbles in the pipeline ? :-0 not exactly. In reality, it will take even more : today's memory latencies are huge because the core speed increases much faster than the memory speed. However, you can handle up to 8 data pointers and 8 jump locations at a time (leaving us with 48 "data" registers, but there is no restriction on their allocation) and you can pipeline data accesses ! so instead of having a single linked list (where you have a miss on most accesses), you can maybe manage severa interleaved lists and trees at a time, a bit like in the previous example of loop unrolling/interleaving. I hope that you understand that it is unavoidable : if you think that the number of bubbles is critical, then you force the core to decrease its working speed and it become as slow as the memory (even the L1 cache must be considered as "slow"). However, todays memories can sustain pipelined (or "transactional") requests, so you can issue several requests and get the result later. The peak bandwidth remains proportional to the core's processor, but the latency does not increase as fast. pipelined memories is a means to compensate, but you have to adapt your algos. > I have had hard time optimizing QoS queue in linux kernel > for gigabit flow eth the code is full of list and tree searches ... argh... i don't know much about this subject (i guess Jürgen can give his salt grain ;-D) but interleaved trees are probably possible... > By the way anybody knows granularity of IA32,IA64 amd 21256 > pipeline ? bad question : IA32 and IA64 are programming models, not "architectures". each implementation has radically differing strategies : Merced and Itanium have different issue widths (6 vs 9, IIRC) and the Pentium 3 can issue up to 3 instructions per cycle with very specific coding rules, while Pentium 4's rules are totally different and it decodes 1 instruction per cycle only (but can execute up to 4 after that). You see, it's not that simple (and even worse when we deal with Intel's idiosynchrasies). Concerning 21256... are you referring to Dec/Compaq/HP(?) Alpha 21264 ? if so, it can decode up to 4 instructions (128 bits) at a time (with specific rules) and execute up to 6 operations (2 FP, 2 int and 2 memory, with one branch or something like that). Check each CPU's doc. > have a nice day, you too, and good luck for your code ! > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 3 23:40:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16syjm-0001OI-00 for ; Thu, 04 Apr 2002 06:20:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Apr 2002 06:20:38 +0200 (CEST) Received: (qmail 2071 invoked by uid 0); 3 Apr 2002 21:40:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 3 Apr 2002 21:40:13 -0000 Received: by moria.seul.org (Postfix) id 28D3F146808; Wed, 3 Apr 2002 16:40:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 170AC1468DD; Wed, 3 Apr 2002 16:40:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 7E79E146808 for ; Wed, 3 Apr 2002 16:40:09 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16ssU9-0003Ut-00 for f-cpu@seul.org; Wed, 03 Apr 2002 23:40:05 +0200 Date: Wed, 3 Apr 2002 23:40:04 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP In-Reply-To: <3CAB5D38.8784B2B4@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > We are currently working on a single-issue superpipeline core > where each operation (except a few exceptions) can be pipelined. > If most units have 2 cycles of latency (for example now), it's a > bit like working with a 3-issue superscalar CPU. > > In FC0, the ILP depends on the kind of operations to perform. > Fortunately, most code is a mix of different operation types. > > Currently, there is only integer arithmetic operations, > so an addition requires 2 cycles and a multiply up to 8 cycles. > An average necessary ILP is around 3 or 4 for safety. ohh yes I read all docs and all old mailing list issues about f-cpu ;-) Sometimes I have had a hard time to orientate in some terms (I have to learn Tomasu... - can't remember - and other similar algorithms to keep track). Maybe I musunderstand FC0 scheduler - I've thought that decode part of pipeline can stall simply when there is RAW/WAW - scoreboard bit of source register is set. So that when you do i1:add r1,r2,r3 i2:add r4,r1,r3 it would produce: cycle: 1 2 3 4 5 6 7 8 i1: fetch decd xbar asu1 asu2 xbar rwrt i2: fetch ------- stall--------------------- decd so that there would be latency 6 and you will have to find appropriate ILP in code. Or am I totally wrong ? I'd expect the stall to occur later say just after xbar at cycle 3 .. > pipeline units, if the latency of a single operation does not fit inside > a simple loop, you can "software pipeline" the loop : > duplicate each instruction and rename each register of the copy > (something like adding 32 to each register number). > The loop size increases but the stalls are filled with useful > operations. This is one very good reason for having a large register set. like: (assume that r1 == 8) loadi 8,r2,r10 add r9,r5,r20 storei 8,r3,r19 loadi 8,r2,r11 add r10,r5,r21 storei 8,r3,r20 ..... ? Would it be very complex to add special 5bit register and add it's value to register number >32 in decode stage ? Like: -- initialize prolog manualy -- l1: loadi 8,r2,r32 add r33,r5,r34 storei 8,r3,r35 loop.c r3,r4 ; r3==l1 and r4 is loop kernel counter -- unrolled loop epilog here --- where loop.c would simply increment the register add number with overflow (no saturation) ? With simple circuit is could be also used to create function call prolog/epilog by testing the add number for overflow and calling spilling handler ... The added register number coudd be computed in paralel during decode stage and would affect registers > 32 only. The result is support for sw pipelining without need to unroll it - thus less pressure at instruction fetch. Does make it sense ? > > If so, does it mean that binary tree or linked list handling > > will cause about 4 cycles big bubbles in the pipeline ? :-0 > not exactly. > In reality, it will take even more : today's memory latencies > are huge because the core speed increases much faster than the > memory speed. yes it is true > I hope that you understand that it is unavoidable : if you think that > the number of bubbles is critical, then you force the core > to decrease its working speed and it become as slow as the memory no I only wanted to kill avoidable bubbles - these which results >from register interdependency without much ILP in the algorithm. If it is possible of course :) Parking lots for instruction seems to limit these latencies to shortest posible time. But maybe I don't understand the problem correctly ;) > but the latency does not increase as fast. pipelined memories is > a means to compensate, but you have to adapt your algos. the distributed tree is nice idea ;) By the way for splay tree you will often have what you want in some cache (but as you said even L1 is slow)... > > By the way anybody knows granularity of IA32,IA64 amd 21256 > > pipeline ? > bad question : > IA32 and IA64 are programming models, not "architectures". yes, sorry you are right. > each implementation has radically differing strategies : > Merced and Itanium have different issue widths (6 vs 9, IIRC) [snip] but I vas interested in information on circuit complexity like depth of ten transistors in fcpu ... > Concerning 21256... are you referring to Dec/Compaq/HP(?) Alpha 21264 ? uhh again it seems like if I have had some Vodka or so ;) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 4 02:46:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16syk0-0001OI-00 for ; Thu, 04 Apr 2002 06:20:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Apr 2002 06:20:52 +0200 (CEST) Received: (qmail 1416 invoked by uid 0); 4 Apr 2002 00:40:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 4 Apr 2002 00:40:38 -0000 Received: by moria.seul.org (Postfix) id 509921468DF; Wed, 3 Apr 2002 19:40:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 437A61468E6; Wed, 3 Apr 2002 19:40:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id E85B11468DF for ; Wed, 3 Apr 2002 19:40:36 -0500 (EST) Received: from f-cpu.org (kdl16-11.n.club-internet.fr [213.44.18.11]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 0D7D21694 for ; Thu, 4 Apr 2002 02:40:31 +0200 (CEST) Message-ID: <3CABA274.488BBD38@f-cpu.org> Date: Thu, 04 Apr 2002 02:46:44 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Martin Devera wrote: > > We are currently working on a single-issue superpipeline core > > where each operation (except a few exceptions) can be pipelined. > > If most units have 2 cycles of latency (for example now), it's a > > bit like working with a 3-issue superscalar CPU. > > > > In FC0, the ILP depends on the kind of operations to perform. > > Fortunately, most code is a mix of different operation types. > > > > Currently, there is only integer arithmetic operations, > > so an addition requires 2 cycles and a multiply up to 8 cycles. > > An average necessary ILP is around 3 or 4 for safety. > > ohh yes I read all docs and all old mailing list issues about > f-cpu ;-) Sometimes I have had a hard time to orientate in some > terms (I have to learn Tomasu... - can't remember - and other > similar algorithms to keep track). FC0 doesn't use Tomasulo (?) but a scoreboard system : a ressource is free or not, and the instruction is "issued" (enters the "execution pipeline" and executes in straight line) if all the necessary ressources are available. it's like you want to send a letter by mail and you can't post until you have the stamp, so you have to prepare the stamp etc... it's static scheduling, which doesn't pull the most out of the machine but is simple, RISC and eases compiler design. And the latency is mostly predictible (as long as memory doesn't interfere too much, but there are techniques...) > Maybe I musunderstand FC0 scheduler - I've thought that decode part > of pipeline can stall simply when there is RAW/WAW - scoreboard bit > of source register is set. So that when you do > i1:add r1,r2,r3 > i2:add r4,r1,r3 > > it would produce: > > cycle: 1 2 3 4 5 6 7 8 > i1: fetch decd xbar asu1 asu2 xbar rwrt > i2: fetch ------- stall--------------------- decd i presume you want to write : i1:add r3,r2,r1 i2:add r3,r1,r4 so there is a dependence on R1 (this is because the destination register is at the last position) if so, the actual stall is somewhat reduced for several reasons : - fetch is done automatically by the fetcher. it's like a collection of instruction FIFOs. Compared to a Pentium with a 16-byte FIFO (and a FIFO between decode and fetch), there are 8 independent 32-byte lines which automatically fetch the next instruction and also form a user-manageable return stack. So you can mostly forget the "fetch" stage unless you jump (there is a 1-cycle stall on a taken branch when all data is ready). - decode : all fields are examined in parallel, and all the ressources are deduced. The register set is read and all the other flags are fetched. Only this stage and the fetch stage are allowed to stall (otherwise the amount of logic would bloat the whole CPU). Though the register's value or the opcode doesn't change during a stall, different flags can be updated : pointer, zero flags... so it just sits here until the necessary flags are ready. This means that when there is a stall, decoding has already started (fortunately, otherwise we wouldn't know whether to stall or not ;-D). This removes yet another cycle from your stall scenario. - xbar (read) is also a "issue" stage : all the flags are gathered and the CPU decides whether to fetch the next opcode, stall or trap. The data will be put "on hold" on the Xbar until the instruction can start. - the last Xbar stage provides the result to the other units, it's a kind of bypass net. So the next instruction doesn't have to wait too much before being able to start : the Xbar and R7 write stages can be bypassed. So from the code point of view, this is equivalent to : i1:add r3,r2,r1 // asu1 stall // asu2 stall i2:add r3,r1,r4 i made a PS about that, i should integrate it in the next manual revision, but i'm so tired ... and i prefer to code... > so that there would be latency 6 and you will have to find > appropriate ILP in code. Or am I totally wrong ? > I'd expect the stall to occur later say just after xbar at > cycle 3 .. This is not documented much (except during some threads on this list) but you now get the picture. It would have been suicidal to do what you first describe. However, we can't avoid the memory latency. > > pipeline units, if the latency of a single operation does not fit inside > > a simple loop, you can "software pipeline" the loop : > > duplicate each instruction and rename each register of the copy > > (something like adding 32 to each register number). > > The loop size increases but the stalls are filled with useful > > operations. This is one very good reason for having a large register set. > > like: (assume that r1 == 8) > loadi 8,r2,r10 > add r9,r5,r20 > storei 8,r3,r19 > loadi 8,r2,r11 > add r10,r5,r21 > storei 8,r3,r20 > ..... ? is it a copy loop ? i don't understand it well. > Would it be very complex to add special 5bit register and add > it's value to register number >32 in decode stage ? Like: it would add a "status bit" and make the programming model more complex... it's better done by external software. > -- initialize prolog manualy -- > l1: loadi 8,r2,r32 > add r33,r5,r34 > storei 8,r3,r35 > loop.c r3,r4 ; r3==l1 and r4 is loop kernel counter > -- unrolled loop epilog here --- > > where loop.c would simply increment the register add number > with overflow (no saturation) ? > With simple circuit is could be also used to create function > call prolog/epilog by testing the add number for overflow and > calling spilling handler ... > The added register number coudd be computed in paralel during > decode stage and would affect registers > 32 only. > The result is support for sw pipelining without need to > unroll it - thus less pressure at instruction fetch. > Does make it sense ? usually, instruction fetch should not be a problem, except for the first execution (because the loop body must be fetched) but it's not relevant after you loop several times. The problem comes from making a simple, extensible, stable and context-switch safe programming model. Adding another "status" bit can create problems further than you'd think (browse the mailing list archive from 3 years ago ;-D) If you look at today's coding rules and compiler outputs, you'll see that in fact loop unrolling is not such a problem for small loop kernels. The loop speed might be limited by the load and store instructions' latency but in fact, if we unroll more than once, there is almost no return because the memory system can keep up anyway. After a bit of head scratching, i just understood that your code is in fact a vector add loop, which is in fact simple to do. I am however puzzled by your register allocation. Here is a code that performs [r1] + r2 -> [r3] : load [r1], r4; add r4, r2, r5; store [r3], r5; However : - load has a 1-cycle latency (due to data alignment). - ASU (>8 bits) has 2 cycles of latency - no pointer update is done yet So the ASU forces us to unroll the loop at least 3x, but it's done simply with copy/paste/update. 1) Transformation into loop : loadimm loopcount,r7; loopentry r6; // loop starts in the next instruction loadi 8, [r1], r4; add r4, r2, r5; storei 8, [r3], r5; loop r6,r7; // when r7 is already zero, exit the loop. 2) loop unrolling : for convenience, i'll unroll 4x, so we deal with (hopefully) aligned lines of 256 bits. loadimm loopcount>>2,r7; loopentry r6; // loop starts in the next instruction // copy/paste/interleave : loadi [r1], r4; loadi [r1+16], r4+16; loadi [r1+32], r4+32; loadi [r1+48], r4+48; add r4, r2, r5; add r4+16, r2, r5+16; add r4+32, r2, r5+32; add r4+48, r2, r5+48; storei [r3], r5; storei [r3+16], r5+16; storei [r3+32], r5+32; storei [r3+48], r5+48; loop r6,r7; // when r7 is already zero, exit the loop. In fact, i just used 16, 32 and 48 for convenience, the register numbers should be consecutive as much as possible. The loop body uses 4 register per thread so it's possible to do better but i don't have enough neurons tonight. I also use distinct source and result registers. It's not mandatory but can be critical in some situations, for example if FP was used (eases the FP trap handling for example). 3) version with renamed registers : loadimm loopcount>>2,r7; loopentry r6; // loop starts in the next instruction // copy/paste/interleave : loadi 32, [r1], r4; loadi 32, [r17], r20; loadi 32, [r33], r36; loadif 32, [r49], r52; add r4, r2, r5; add r20, r2, r21; add r36, r2, r37; add r52, r2, r53; storei 32, [r3], r5; storei 32, [r19], r21; storei 32, [r35], r37; storeif 32, [r51], r53; loop r6,r7; // when r7 is already zero, exit the loop. I have set a 'f' after the last loads and store to indicate that the value of the corresponding line is not needed anymore, the line can be flushed from the LSU and the L1 cache. It should do the job nicely for FC0, but might cause problems in a superscalar CPU. In that case, the interleaving must be modified : A1 A2 A3 A4 B1 B2 B3 B4 C1 C2 C3 C4 should become something like A1 B2 C3 A4 B1 C2 A3 B4 C1 A2 B3 C4 because the execution units might not be all available at the same time... This means that a prolog and epilog must be added. And don't forget that it's just a short loop. > > > If so, does it mean that binary tree or linked list handling > > > will cause about 4 cycles big bubbles in the pipeline ? :-0 > > not exactly. > > In reality, it will take even more : today's memory latencies > > are huge because the core speed increases much faster than the > > memory speed. > > yes it is true > > > I hope that you understand that it is unavoidable : if you think that > > the number of bubbles is critical, then you force the core > > to decrease its working speed and it become as slow as the memory > > no I only wanted to kill avoidable bubbles - these which results > from register interdependency without much ILP in the algorithm. > If it is possible of course :) Parking lots for instruction seems > to limit these latencies to shortest posible time. > But maybe I don't understand the problem correctly ;) i think we're on the same wavelength now. > > but the latency does not increase as fast. pipelined memories is > > a means to compensate, but you have to adapt your algos. > > the distributed tree is nice idea ;) By the way for splay tree > you will often have what you want in some cache (but as you said > even L1 is slow)... at least in FC0. When the data is properly prefetched, there is 1 alignment cycle of latency from the L0 (Load/Story Unit's buffer of 8*32 bytes). it requires a few more cycles for fetching from L1 (256 bits per cycle) and even more from L2 (might be limited to 64 or 128 bits per cycle). > > > By the way anybody knows granularity of IA32,IA64 amd 21256 > > > pipeline ? > > bad question : > > IA32 and IA64 are programming models, not "architectures". > yes, sorry you are right. argh, again :-/ > > each implementation has radically differing strategies : > > Merced and Itanium have different issue widths (6 vs 9, IIRC) > [snip] > > but I vas interested in information on circuit complexity > like depth of ten transistors in fcpu ... this number is not valid these days, because the gates tend to increase the transistor count. I based my early approximations on very old technologies where pass transistors were usual, and now they are forbidden... ultra-low voltage and noise are becoming a very important issue today. But as rule-of-thumb, the 6 gates limit of the critical datapath remains as a central guideline. Of course if there is a specific implementation issue, this can be locally modified (it also depends on the technology and the synthesiser and all the other options) but the general design is still simple with this rule (despite all the bypass nightmares). It ensures that we don't get caught in endless "what if we add this and that and other stuffs", where the CDP increases and the overall performance decreases... > > Concerning 21256... are you referring to Dec/Compaq/HP(?) Alpha 21264 ? > uhh again it seems like if I have had some Vodka or so ;) don't drink and code ;-) i don't have this problem, because i'm only chocoholic ;-) > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Apr 4 12:06:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tFRQ-00050R-00 for ; Fri, 05 Apr 2002 00:10:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Apr 2002 00:10:48 +0200 (CEST) Received: (qmail 965 invoked by uid 0); 4 Apr 2002 10:06:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 4 Apr 2002 10:06:10 -0000 Received: by moria.seul.org (Postfix) id 75537146819; Thu, 4 Apr 2002 05:06:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 462101468F7; Thu, 4 Apr 2002 05:06:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3E7E3146819 for ; Thu, 4 Apr 2002 05:06:08 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16t486-0000Dr-00 for f-cpu@seul.org; Thu, 04 Apr 2002 12:06:06 +0200 Date: Thu, 4 Apr 2002 12:06:05 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP In-Reply-To: <3CABA274.488BBD38@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello Yann, first I'd like to say thanks for your verbose and helpful replies. > > terms (I have to learn Tomasu... - can't remember - and other > > similar algorithms to keep track). > > FC0 doesn't use Tomasulo (?) but a scoreboard system : > a ressource is free or not, and the instruction is "issued" > (enters the "execution pipeline" and executes in straight line) > if all the necessary ressources are available. ohh here was one of my misunderstanding :o) So that RAW/WAW dependency causes stall just before issue .. so that all my fears was void ;) > The problem comes from making a simple, extensible, stable > and context-switch safe programming model. Adding another "status" > bit can create problems further than you'd think (browse the > mailing list archive from 3 years ago ;-D) I'd like to do it but the archive is not available ;( It said: Oops... There is no group called f-cpu. > After a bit of head scratching, i just understood that your code > is in fact a vector add loop, which is in fact simple to do. > I am however puzzled by your register allocation. ;) I'm not experienced in asm coding conventions .. I asm I coded only IA32, IA64, PIC and AVR cpus and it is a year ago .. > // copy/paste/interleave : heh ? maybe I missed just next cpu-techie term :) > loadi 32, [r1], r4; > loadi 32, [r17], r20; > loadi 32, [r33], r36; > loadif 32, [r49], r52; > add r4, r2, r5; would the cpu benefit from prefetch instruction here: load [r1],r0 so loadi in the next round would not stall ? BTW when the quad of loadi is encountered and data are not in the L1, will the first loadi stall or will the load continue in "background" until the r4 is really needed (accessed) ? > It should do the job nicely for FC0, but might cause problems in a superscalar > CPU. In that case, the interleaving must be modified : It leads me to another question, is not FC0 in fact superscalar too ? It has several execution pipelines .. well these are not complete .. final xbar+register write is sungular only. Do you think that it will be possible to change scheduler of FCPU to decode/issue two ins per cycle ? Because when fcpu already has multiple EUs and probably it might be simple to change ins positions to exploit it. So that when two (or more) consecutive ins are independent then issue both (assuming that there is big enough xbar)... > > but I vas interested in information on circuit complexity > > like depth of ten transistors in fcpu ... > > a very important issue today. But as rule-of-thumb, > the 6 gates limit of the critical datapath remains as a central > guideline. Of course if there is a specific implementation issue, > this can be locally modified (it also depends on the technology > and the synthesiser and all the other options) but the general design > is still simple with this rule (despite all the bypass nightmares). seems reasonable. And because of it I asked the original question. I was interested how complex could be one pipeline stage in Pentium4 for example and compare it with fcpu's 6 gates to get rough approximation of what frequency could it do given we have Intel's technology ;) > > uhh again it seems like if I have had some Vodka or so ;) > don't drink and code ;-) > > i don't have this problem, because i'm only chocoholic ;-) me too ;-) well it was overkill (that with vodka) - I can drink only tee/milk/beer/blue-bols/tonic ;) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 4 15:06:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tFRU-00050R-00 for ; Fri, 05 Apr 2002 00:10:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Apr 2002 00:10:52 +0200 (CEST) Received: (qmail 28194 invoked by uid 0); 4 Apr 2002 13:01:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 4 Apr 2002 13:01:03 -0000 Received: by moria.seul.org (Postfix) id 26B2F1468FB; Thu, 4 Apr 2002 08:01:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F193314690E; Thu, 4 Apr 2002 08:01:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 658851468FB for ; Thu, 4 Apr 2002 08:01:00 -0500 (EST) Received: from f-cpu.org (kdl11-50.n.club-internet.fr [213.44.9.50]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A629316BC for ; Thu, 4 Apr 2002 15:00:43 +0200 (CEST) Message-ID: <3CAC4FEC.238D5C74@f-cpu.org> Date: Thu, 04 Apr 2002 15:06:52 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Tr:[f-cpu] usage of 64 registers & ILP References: Content-Type: multipart/mixed; boundary="------------1E53C4C866990F593255AAFB" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------1E53C4C866990F593255AAFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, i'll answer in greater depth later, but here's a GIF that shows how load/store ops work. A better version (and verbose) exists in the source tree but it's too large for the list's 50KB/post limit ;-) i also included a small overview of the integer pipeline. Hope it helps you understand the machine :-) There's a Linux/BSD/Open source/F-CPU meeting tonight in Paris, i hope to see as many people there as possible :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------1E53C4C866990F593255AAFB Content-Type: image/gif; name="sched_load.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sched_load.gif" R0lGODdhHQLHAfcAAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0N DQ4ODg8PDxAQEBERERISEhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8f HyAgICEhISIiIiMjIyQkJCUlJSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDEx MTIyMjMzMzQ0NDU1NTY2Njc3Nzg4ODk5OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkND Q0REREVFRUZGRkdHR0hISElJSUpKSktLS0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVV VVZWVldXV1hYWFlZWVpaWltbW1xcXF1dXV5eXl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdn Z2hoaGlpaWpqamtra2xsbG1tbW5ubm9vb3BwcHFxcXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5 eXp6ent7e3x8fH19fX5+fn9/f4CAgIGBgYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouL i4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOTk5SUlJWVlZaWlpeXl5iYmJmZmZqampubm5ycnJ2d nZ6enp+fn6CgoKGhoaKioqOjo6SkpKWlpaampqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+v r7CwsLGxsbKysrOzs7S0tLW1tba2tre3t7i4uLm5ubq6uru7u7y8vL29vb6+vr+/v8DAwMHB wcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvLy8zMzM3Nzc7Ozs/Pz9DQ0NHR0dLS0tPT 09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl 5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v7/Dw8PHx8fLy8vPz8/T09PX19fb29vf3 9/j4+Pn5+fr6+vv7+/z8/P39/f7+/v///yH5BAAAAAAALAAAAAAdAscBQAj/AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKVAjgY0mPJzumnAigpcuRAl8mbAmzJs2a Dm8ilInzn86eNn8CHcpw5UajGpFmVBpRaEGnTmOmFBp14E+qU6tiNbhVKkmjOqFmfcrUq9WV aNOSXTsT7EmxZwl2NUuXblW5bvGynctVbVy9RDGWBTx1psnDFV0qXpxW7Fi8NLXKVHz25uKD k3lClurWMefOoCsPjvm071XLPCnvLKkZcmifqTW3Vv25YeaxrUXDrvyXM9m7gZvaflu3NMrh pJNjDs68ufPn0KNLn150OeDeXBEvtFxcLvXtSkdf/18qnu33tnl7Aoe4/rx7m8jHG1dZPbvh 9/b7dpcftizf/34Vh1Vu+mG3W1vm2VVeb3PddZp8EGIn2VsL4heceP7tpN197FnoYWC0Efjh iCR+x9iJKHKHUoossqgchz55h9mJJdZo44045liUiDnVZ11+HFXYYYI6FmnkkUg2RxtLGx7l I1gaEjmkclB6h5SQSWap5ZYwLSkRhjK+GGaQTR7I5ZlopqmmbomVCVuLKYrpmos/GhileWiN OVhYa/bp559ftUcSjHfOZ6dwx0kJ6KKMNqokj7aVKeigiUbo6KWYZqoSpD6SqeiUnlqq6aik lrrjpIU6+elDWPa4qqmwxk5KqpfuoeqcrbLmqmuJcPbq66/ABivssMRetuuxyN5I43DAZdVq UqM5m+y01CKLJa1mQidZtdx2++eznb4JrpxLFdhmpaE6Oi6l9KGrqrf/db5b27m/0Ulotky6 m1Sm695brr7ixskuvIbKK65FGBJHrlXmUtRvqvti+nC8Ebf7FZUDE8xwxhunii2rOybXbMP5 WpxuoxMDaXDFCMaIb8Eau9zxdhl/7OqMenKMq8pjwuyzYCeHhC2qKf8sM89GI9zyi3vGnHSG hNocKXr13rtz0v72zDKJDlZYtNZTZ33RngNC7fTCY1dNb9BXg91xYTQDDDHScrtN8b93ws0x 3kFr3PTcohVr7NeBCz6ZSYYzhjbdRH2duOJHH/W4aoQv3m3lkUsdbk4Okvyl2NG66THjJ18J ct1me8xp3E11fvbiec6ssuass90v5rjzK3ra/64pXbe3ufe+9t1Ma9227ICL7XvYdgtN/OZ8 Kx8v7XvbHbvl3IYH899sOizp7bsvr274w1MvvfevR761+ckXjzzyx2Nfct+ABm/ywcMDeT3p nTJlep1Vupna3Dc/g7HvedCTU/zUF72tMcp+pVtd9ZiHtew16YB0+9/7FAi+3+VvURA0oASz pkG0hVBvr0KUAvknQBHGL4QvUyH9eHcpGEYPgxUsYPpEgkMQYW6Hsxohr4xVKyLaqIeN+yEQ NYXE6AjxUUq81ROZs8Al5qqJQ5nihao4RC52KYpWVJcWvwhGaJXRQ1iE4QJtCDQPou9+XVwX G2k4QxCOcYNjQxEdVyjWwD62sV4CO9970ki+N9axfneU3+fcqEM/7tGBBUIhCweZSAb+8ZCG /5RYJecoPj5e0pOPjOR+8IjGTRaykZ+soSkZuUg4OjJ1CPxgXfY3ySK+8JStxKSfCMm/0KEu gZyUHidnw6MzgoSXo/NZMJVnzFLe0jSBFGQuK+i/8OkNTKyUYY2QGUsGLhOVDzTcwgIIu8kd 7mKtM6fCNqVORWozjsRy59zUqaKClbCW0/rmNCGZSjz60pWnkqbQOAU5R1oSbPp8p98ymcN9 GqY8CQUVKDvpw8xRyCxV5J6/GtMgylylmxp1WkRPB9BQ4lOeJE3e/ppZqw0ZMYbtkyW8RtpC fpr0phQ1aJ9oSkGbAg+XCu2nUHEqUwIelKXn4WkCiWrBbErUp0WNKv9DU9pQNCm1dhO9HFCf qtOpDjWn6iNnVc901QmCdaZbpSpUvcpUcJ51l2mtaVeZqNa5ujOhSA2jXvdaVoFytXVA8WJA R1LJJKaHknllyYIKm8W6frWqeF0NOgkTIL40zLK8EdCVDtsszm7WQOuJDEYTZNnO7uWzszxs tkwLHtKmp6PjedCRsGnU5knVrXstlWAttNsieQ2ov60dLUk5VsKec7DkEZJswNhbxorKuc7N LXGPGlO2vhU/RmQtg16rWgDFtrsBwhloyUak/qzKvNfBbGqXFjLfkKy3vHJsW+8K1uAqaV4z Ok1/ypZf1nTGvZS7jbM4+rEA75dsFDrwAPstWzX+bgajBCXmY17aPU3+E3TV/Q1W1yrdDnuY waVZVnFJ+VsR21ZmYoWf9j7M/2K+rnLD1HWqWuF72xbbWEe0si86JXni6fp4NlZbcaDci983 GVl4N07ybF+841Ee9Ky03R5ElUzl7OVGx6SDZQz/y7goG0/I5FppzmTnHzDzlmtornKRHfoZ e0l5vu+ksZrnHE6oyJeiUcGyA/Oc5g8l1rrU+XOsuLmyNX6PzogmWI5NZGZtNXqQfUZjpKmM RfUIGrCJzrQq03lP0wT20Q++1aSxO2pIA/GABS5oRVdDYU27uqn3W7RcU8nnWcNZz429r61P emfIAtdaF2Ty87RsaBnveqdx7alOtexjap3wyr1maK2V/dgeo9TYJcVnZI8NaGtLLNjPhNFw VQznv92Wm0t9zTCbZzbua+8qpFSVNbUfOe2lXtfbl34yfLjd7KB2s9/m5jXKwC3HZFrPc/4O M4yrLb8yVrPfwQQ1wB2bYmYreoIhlbe981fvhd862oQVNb/dvXF8//pYz56Qx/Fc5gsbqt0T J6gu9z1vVntczGbN78prnE9oRlN1djbxxGvKZ6GXM4X6tpKqh55tmlfH6E9Wrz2hDfVtv7u1 KMYqoffcQcmKiuklD1OnnbdCkK8bX+15TbdxC2uvX7Rm0D52ryjWcZ2RN+cmR1g9zT5YXKs7 rHePWtxrHjA9av8b2AKferg3+nKEP1W7fw+4MvdOdg0nHewbhvz0hH03cuZbSxIn8YLpyzqY o9bX2fS7ekROeG9LVOM7z7o/+T5kBC42x6I98h1TXnBmpd3xtA/+yK2a7HBtndW/z6OnD0zg zQjK8P5VO9sLCPvqmW7KilL9vSHO+gvxnfeHp/vltS983I797OXjPPaI3fWZJxzZ2Da++pNu 8bRdWb8Tu03gLI/dwUun7qbmZ6UGReeXVMgnZ2YUXYb1efHxarqlgFLEgMi1ZHYWaKEXaANo gNNRfRbIGryFgP8HgQPlgKZSacYlgeCBglnkf7GnQwAYed9XfmFHek3nekFRga03fTT/6H5q cny01n5ZtXboB2j1p4Kctn1DqIPv9y0siHdKSH5CeHkk14I7GISYd0xN6FcxOHySx4SLZ4VJ GIZLqISSh3P/Zku9V4NkKINbwoEwOHxQ+IRs6IRVyGFTiIU4OINjWId2tSY+eG5cOIfCFEts VHFauIHzB4jKBoSqlIdUmGVbOD0ZFInuF4diaIRuaHvbc4ZS6E32ZoRUJCIyJ2OjqIahplJj poWlyIMd6D+hlVarWGG0A4omUniPZogCFX1Do1h0GCNVN1lOxn2/mHpoNozVdYFK12oPZ1GP mCzKJTVz5GVXyEyq9YY5KIYhZy6XkVGBYiutsnQkB2+DVle+UNKLqudf+rGMenh64pWLvTZ3 4RckniWH57NiKoIa6HggH8VC4nhx8deMgggxmpd4JWdmMAdX+vIw6eaHAcmJlriHnWh1Bclu 7jgiD9mF3PeP/7KykAQJkIH4kdfYaiMGesXnkdf4bSC5jg0Zj3qIkXwYVuO3kk5nkiqZkjR5 RSXZiy4JkTv5V9I4jUbCkSPZkuNjkRlYi0aZlAJIghF5cie5k7TIlFKplKxokzo5lVjZdmDI kwEJgsCXkz3pREinLX6mXGQFltZIlO1oc0cGYY1BZGsZGV6CGvwRfZqVXuglIfioFyJ5l9tV lwGTgnCpf3oZmIC5XqIIXgn2YMs1mPP4fzKZd09JiV8HF7yRl8EoW3pJTFICW+xlJpaJdoGX j+BVXoEHYdoYXqulmkjnXZRlmvm4XrOFlpwYlmspI5q5X98FjA2CJ9XYlst1Pa4pm/+Hwn/3 d5jFSZyruZvMmVlUkjDSUpjSCZqaOZjK0j9uI5Q2mJVcE5Ur8lPClZ202ZHcWZ4IOZlwGG1m iHrm2Z6wkoZDGXvruZ2P8pVjySrX4p1w92nQkpU/OU7jGZ9b1DXOKZecmVqLOV7NuRsURpe8 qYvRkhcvhZmXtZd/+ReNuTSx4ZjE6ZVJ8p+WVFbqiCOZAYzU+ZnVuZzTqZyQJ3V+eaGco6DB aGQp+nU02nzJOXBWWZHoKZ47Sh4VKpyKKXbhFRtFqpo1+qCvUlpv6U9Heopv15YwZZ3UKUm6 CZTwh3XJeVX154Ba4Z4ot1QjaodcCaZmmibGaKKug5/KiFwlkKKfZxqnyVUsd4ge5rR+ZCaQ yCinfBqCKueEEpefLsemetqnhv+qLIk4e7UZmeR2qI5qkYkKSDcJqG8TZA5jl/znGwImgo+q aZlInjw6kWIypi/YeJbjgQLaqdz5hxS5QdrZqKoaq614b/OJpaBaqLKaq04UqVHoaV0GTPap kboKpp9KTVD3ZZsHOV0KoNmnTD0zl1fZic8Bp/TpfXP2h//JjmtIdNQ6rHGKrcB6n4fYUx7q reYKYr06Y4zYQOV6ru66Zk2ZkHtap7iaqoF1lBhIlZTGqy64rj/4rgB7gvBZaP5Kb90asKvK r/tUbHDUrgg7rMW6avb6nbe6evpKahebZCYYFJD6sB4rOQ6rdx37sSSrdyGbGAd7siXLlLgS sVLKQ3styqllSkX4uoE1CzyC+ox51bIqu7Ir25fQZKc9m6Pg6LNGixNPlGobK7IHeLBH/7uq BMeSBOuQTqmWplh5NXm1F0mZGxm1PPd4BYuEM5slr0qvi/qjJei1RNg+2oqNjGq2OBag1bpz Yzq3XesurBpjdBe2X/u22yS3too1RbhD4Mee1ti28aq1fmubiou2Uptzz7K1OhprChtnfJuu jpsjZSutfuu0S0m5X6g/ByeuaTmp40q2gAu3gpuKFatb1iV96FersIq5PWq1qCuspQu5rDux rnu6sJu4tkO1xJi5tFuJncu1fei51ro3GVe5YItT4LK58fU70Zu6nBumeDt/uLi30BtT2nlG 22u7K1e3dktCm5i742inNvq75sZj8MawvxqtJwmiM7RO4otxg//4S2WHvu+Jv4LniPK7OaXa uoZrugzHQ8h7wMC7lcoLIlo6o+x7vKR7tvqGVy1iaW5WuyY5qH3IuLpSuMWbeQUru+XLvyVM ptG4uwR8witMV+YLdxOyi/IqtAMsnACZpnSLtM2YswSiUTxWXDhMps7ov02bOKo7J49zxIVj xNd7tXh4p018KlAskTjpu6PnnCbMM13DwSZ0w6+Inyo8gq0aiLE4uv/rilysiB+sttv6ssgK ZfnbuPAzkwXYwl3svVfMuMVEuANzkBFMvLM7P4tlwIsqYc1kyBKsSC6XtyF8t4Xix1dMfpGL cHpGvwscwG9IxebIj1qXhXh8iYgHugMa23nPGqyZxyDENVKpMaBgp0aofKp5rJ4AxLv/s4Ku 2pS3qTNc8PuclYrJm7zKjQXMbkt0r1zBsSx34sbCtZwf2QXDo3yAAsyIlvy9YgnI+xvH8OqS QKvEuuNzP6d4ddxQwsy9j5u8i3vO6WnNFgXA0jTO5dy/2Ru6pnrHNnq/p0vIcYu7yfrMrLus tWekjXZ/qCpXNox5IMx212R3aozPtEyi1vvHrZfQ9ywyKqyOKdbHBHSQDP2szquuC+3LEz2b +jw7Ha3ONcTGLwmva3ookju/6KzBKJzIKn1nuBeqVSzK9fW4uyzELy1pIw3OOV3AQBqcssWN EiapfdtCPliO9drIIZ3FmvvQx0xtTE3Bxueq6dJp+YfSYyvC0x/91Fb9oVKNZG1sz1C9kZ5c n3aMtWeWsQS41sfUgB+IqEOLaU/rpw2cgkuLONvcf3XNHnntrnvtaFHKaIV9RDJLsXe9q39t RmUZ2N0I10zb0Nn4uT6N15Itj92a2Iy92ZBtroNNRo+9S5wtj4uN2R/o2Z99qY0do6dN2FFZ 2iBrYeGszG8s1Oaszg+pyRFY24ErmWYd1qBX0uR6uWW90b+d3NyMwfz81Wet3CRK3NHs3MIN 1mvNxf342M0tth6M3Jor3V7N3TK9lWWIYdEtzwrc3SD//aFpfd0J/HG6/d7u1tIwy87PndLu PSqMfNzrXd33HcXeDeDTCt79nd9MRODWTdnLvbkXZnrfjd7UbeD8guD/zeBjncyKStfbndQw neC+1d4KfskenpEd/nf0/YiYCOK2TeLBndlxJN7x/dPNU70yDt1IS+H+neMu3p0QDuMlruNP 88kAFb4hfuM9zuEtXuSILc/GPcwimcJCXr9zPOKfduTAuccAk8bLreHv/Invna3yzXMnvsmI aN+aaDzCW7vZbUdM7uX6O+US/o4XvuTbTeQL3l+GV+BBieNxztO2RsLQLb03uOFOXeFBFMM9 bMuzyGmJbsqqWLQ+nMqMPsBI/w7bRVzd87rExCNWa87m8eSJaE7DTOw1t9dOAi7q4nTqJm7Y n97p3kRPChfq/41uX8zMKSSopmvmbGnehJhOAb7atcdM0IPrer7i3ezE421Ty8pTWD6tu56j yd7BQAvsNutWKQwX5EtHg1zsgU7Yvjla3Qtj53ec1erqLryIbu7SPYJ96n5iWo7b9DnmGkoa dPkSKz2+ww7uFuqg41bVQK7fIMXt9PzCDVvM795tYHbRHVjPu9bXuKkw/G6XVGG9J13jd56Q Bv/rNxfG9SMpVGMngj65VfnjfT7NuNTX1O7jSW7sqs6QMd7uxvvyWSuYsNPTDFy1Gp8+Fm7x Ld/n8wast0WJ7DL/L1JzTt7RXm0SPes3O8wkr+Qib/RD7+dNz/IpX+kC3/NOjyTyvupRb9Mx 3fDknuaXvfIsnvOvs/NCP/XdLn4mvfRdffVVT5Y8j/YjD0zw+O/XOfcUH/R1b/Z9D/d779YR HuJxH9eCj5SW3daJj7Gv3fiOf5acQ09Ew6aSb/OP/61HL/Y3f/mcD/h63/mgr/J+D/WhX/pY T/VoGbIDiaiI+MAcS+sA//lpP8HKd+Ov3520n0RlCcboVvRSP5ZDE/yx6au6l2cG5lH1rl8+ 12YGGrSM2VkKdjCbGvERiqnOX6AWyvwc9fw6h/3Wr2FlM2BEHdWy//cQ/KQseppGKiF1/0ma 3fXtC6r8cGmaeoKkV+p16f9d0Skgvjn8APFP4D8AAAYKLHgw4cCFCA0yfOgQosKICA8SrHhR 40aOHT1a/Mgw5EiNGT2a7IiS5MmVKhtufCnxYsGGMWPOrGgz502MOEtmrKlS5sShRHtSPLlT IVKjRY9y1On06cuoTWleDRqyqtOFWylS3YmV50qyI4WWLEvy7MyWac22hXn2ZtahXn8ybeoQ rE++RsdyjTg3MNC1XY8Sxgs4KV/BVhE7XvzRa9XJgxP/dZtZM9vNUDt7/oy281iDjZ9OfQxV aeK+dk+jFrrV9GvMPQMTvJvXNeuuJukqdhx7Le3VRGUXP00z9HzyzcMh3gbNHKR03KNR9n6o XG9CsNkx78X7+7BUjMq7X2Xq/ate3sO1l88tUz1rnN7Dsod8Ofv2969Vm78PvufwK4+71exD jzoFo2NpuupEo865tCRcsEILL8Qww89q07BDDjsEcTn3lhIJpgUpJAvFEFdksUUXzVLxxQ1j /5SxRhIbdNClE3e0sUcffwQxQSAVFHJII2/EEToTiWypppSOhDJKKaekssrm4IKxvyXfUovL B79EUjIrxySzTDPPDI1CGrXCkk0xS3QwTBzRpLNOO+/EM86ydGTyzRwZrDKoD8nTbND8LDS0 Sem+WzO+PB/d8iuxJgVURC+VhDDQ6xRlLlH/qNwN0Ub7grRUOMPctNI0m9QyU1A/xCo90lqF T9D1/LJVwJ9ijWsw+5LiFbv/5BKsNN9a5TWvXnVCtsjtTEXUzUjlXLXPMp2NM1ddwRQPvEOT 0xbcyAikVbdwU3PUW24tK+q71thNDtVRoVWVs2lP7ZRHNIVk9F1Kif9rT7+Av00XXUcB5g9b XP0Va1fkSE2pv2b/pTdfaanVs1pgJ+XTzt7GrUs4UisTeODa1P3U3HdThDfkcVGmL7xjxau4 TT+1Uhjje5+8WWc1bXTpV9X8Hbrkb1EONa6Bi1aZQJyb3tbolKMmWNZ5If3Z2ot73rPenVfk l7BkEU44QC1jVRfpsHImuN/qKhu7YKHLfs7AmOt+D214zyu35szUZDvjDa/82u87ZzM8ccW9 nBNfnQnfOG57Fz/8uqspx7zOEeu93NXCec688sBDJ73izb/ufHKLS2e9ddd9lNzxnWPbk+3U H389d913Z5lj33Ni9eTfh29YdggxVZ135ZdNZx5v4n8/8XnpY7cXqGFjv7157beHEltjOcb9 77agN/5G6+/lKXvu12dfxpypB3PZu+OXzPYsk3fc0/b35z/K0bn2nPHUR7/BQax/B0T/4Kv0 Fz7afa5Q+lJWAiU4Qdj1jXFe69iiIEgoCnbQg0Gy4NaYxsEBuidcnltghQb4QRbS63+Ns5TW GAQ89DXKSXA6H7dauMPtec9mMbwgDI+Hv/ilj3G+8mEAebhE1yUxiBFDXvjKp0TzEfFYDvzT qWiowyky0YuGeyHokoSxEv6NNAf7YhrVCMVRne5LGVydBg24RjrSMYxe0yIZNwjECNbRj168 IxYfFMUuik+GU/tjIlkYSCo6rDB7LCQcEVnIHyrSkqYLIQAL6Ja4NVCIRSxMYyaGnSIBaIWX RGWGnChCjTlvevBzo5yMSK0tEtCWt8TjkE55SP+l8llE/NysnsRIHrHZZJioQyMXJ+fJW8Zo lxEa0zPlmEpGAjOW+ZtXGefoygHpSnKl/KY0fTlOTmbyk7gk4BUhN80+ktOdPTTnMSNZqRRS ckLJfGc+mVdNn7ESlKPZYz31OVDF8bN819STQNHJSXwS1KGtM6jgALrNSm6ynQ/FaOZWqcmJ xixr0JyjOPk4JZG2kqTj3Og510nMinY0giW16EmtBFOX/14yogu9J0W7dEiFZtSnomtjQLMp 1J8WNXQ31eb8dgpSpRrVqaVCKlFXOtJJPtWqQJ2qSavK0an29KpfPVJUeTrUsYLVrI9KKRtf +bxkAm6t0mtrNOU607lSE1lGmiWQ8gqquvKVrr68KQhnStOzFpZI8ayRVzWkWMM2FmyIdR9h zehYykYTsi9iLIYyW1nORm+zKpRsOTs72rBe1kWfBS1pVQvat7bWta+FbWxlm6pA9VWmtd2h p9JaH8E20mmnta2UQsvQv7ZQt5c1rXUmhNrVNnexFKufoZI7o94517pngu7GFjPdNIWSatcF rwKl2zf4eYhY3A1vek+bqPdlNxJEfwGfeuV7W7XQKrCdChpz57v/X7XO9mx3ra9/wynIsvm3 pY4UcIIVHN8nXi/BB67PgiH8uqT+UooS7Spt/VlTlQLTQ4mdsD27ttQNZzWXFN6gWJl60QZz WKuYq3AcZUxVCcZYxezkIIln/GLKxZjGMf0xAm2M3jXJpaE6DrKJF+djHru4xThl35AF+kgM HvnJD+RljyEJ5CZLlJkUlHJQz/nlrXbYkCs+6padvGYvyzOBYVay4Iys0yufGccaVXOcsezm OXsQzh4GNI3UCegLj7jOIlYhiJHsZjYTuouCDjFEUwzgQ+fUo5E2dIkdfaHhYnjTUE4Rppl8 4iZOespS3fOdu5y4UTfazjt+s6nFjDNC/2LT1cRFM56zfGtLR3eKnTbVn1+9pVomT6Gt1jMY 85xqWFfxoIuUtZ5rSeZjL3vYMLY2rlWNpGIXen1FbtyNI9VtWydb280uaLZ7je439vODJnSv vE7tp1onlKy5XrWyd23udRP719BmdJ8tLGIJldfeBAa1qDGdaPcpfN+fLvj/Pto8gYdaUr71 9g/3ylVmmxnR6o7Wokndb0Zj/Nwel/QnKy5uqlb74dfW8stPnu+Zx1pSxAs3kYd1cRi6HOEm J3nH/YpvT6M80zwf+M+5l0OuFlPJTLfloGEedY5PveYr1nDVr07mT1t8WlDPeA+jLXRlPpvO JZZk1yM9PVV+fQnhB0572BsMdq7/29zrw2R5tqgo9a2Tr+Rkx6I0PTnxZg9P60Gn+9/5R+VA R/jp+HLX2Tla94+LPPCLZQnhg0z5om8d8hWfIOj/jXSCo7rQyIa4ojHrcKIjHPVyx3bAcz6X tyN540a/++ETLnNOs37brgc5sHErT8Yn/egtv3fugX58xX+Y3Vb/++uvfkDnGDxbOi+rtBk8 cubnUqTF1zT0fad75dO8fcKefsd9nilyw5784Xd+pbvf7keDvPx2x3Hegbz+ZeJO+rVnOPm7 P/rztP+bP+pLP6dbFs5TP+EgrzGqv96BrwkTJ4TiPv4oOUwBP1qbQN6LsjGLnNhyvxCELW/L pAcjOMMz/y+/C7DZMkEOQcHOCzohA8H+EjDPkrDDWjBg48EdLCEfDL6lU7me8SEW9DEjMkIO LLjxGb/Ka734Y5MkjK5BUcClkMInVLs0a76vKxdYMr0I47ysUzovbEHS0yyJQa7aeUDi25r2 WkMsXLyxg75h4z9328IDdBWwC0C9s7zH8z7HAzx++0AZ0j9fo6fks6b360PV8Q3MkyUA3DAG rML0+487/Lb7KUBAnMOTq0Nagr8ZzMPlW6lGXESrE8M8xD443B/Ga7/rm7dcW79XUkQBRB79 GqKmysIjYrvZm7XfQ0AxasV1ecU7i8VFNEAXgqAl5EVBHMBfnKHHmUQZ3L0gunQ9S/S9WfRF R5Q/9JNGAxS+oYuOenNFUrwySAspjdM0zbNGKALFclJH7iPH6NPE0sM9etSe6nuhaMRDsjEm yes5/+AObMTGUmIRgixFTgTI0iDCVIyYlRlB5eFGPGSmbutEtkARb4xH8xLFhzwxhbSZQmyz PP96NzlMQGCUJUQ0kYsMvox8ro10wvDzSB0DSaoTST9TOlQcxsKZNisTIWO5iw00vzeSGG0s kNMLqITEJX1sRprMIpt0SUZkyBFCJL7rNwt8SYHkrcSSrqPkOKWkQIPJRYpzOw/zyoOsSpQM yqXUN1Vct5ncxPMbS2icx278Qrr0wHcMEtX7xGlsQ0rbS7W8yiW7PLzzy6ozDAyjSijzRkh8 Ps26xpHarcDbD8RkzJayxSRjtpncyUPktX2kRL85xo+MSvazw/f6TNnZG/eLyKXczBrqTMBs x7XMxlfTTG5bR9tsSgGqHpVUomDESsLMSdI0O1z8zQusTDwJTZkczf7/G05DKiaWzE1QIzcN DMTMXE7GyLHEhE3PjE3QtD/RDM7cmA/jVBrzgU5lYi8SuSEC7M62vE4Oq8jXPM7D+U7lDE8u wz8Zc0tOREv8lM9gq88L2s/2HEQ0i8ynDMlLM0vuVEy9bBG8RNCFpL0F3bv5lE39LMwanI6T iSsKfczbnE3HXNCIxMst4lAPxSygTEvw7MWTtL3+/E8BhJbkFNDr1M4Ifcv/vJzVrKjzdE1m tFAcRc4A7cv79FEhZZr288hsiqIjDVKoNNJQ5EwgRVEZBVAPzD39y0gGpE3djCOW3FGSRLxI 5MnivEkrhSoildAWnSfyhJGa9M1MA9Or5NEqUu1JGKVSNMUaNV3G6szR7UxTQnzPDIvRv3zS feFT4GTTFc2Sb3ysHZxLxQTCc2xBBRM1H8RUSB3RSa2b5cPUQ62xDAWaU+ye4OolvRLVUlUr krr/rwdFr97iL+F6VV3avh9pQjNpVVVy1Fhlo2CzvsjKVVe9TBHZVV6VH6z51RQNVmEt1oY0 1u6ZVVsd1u5q1uaIVl19VmidVl2t1l6Bqms9w2wtrW0VlW7dlRlN1cg6U+AqLnDskQNFVXPN SnSdUFRd1wc1VVWV1nr1H3AtV9D0V1ERV7wKWG7VFHldlIKNnoGlVXKdEYTtJlZT2MNi2HiF 2N/SVhib2Ai5WP5aVs862KPa2ISt2H2V15HFr45lrY512JLVLoJl2ZaFWSe9uRh8qeCx1E3V 1G3kVEPlVpp1pRvk2Z4tHXjlyB9NvbsEVbvUU91rVqMNzDuEUD8tqEFte8BCNVMkvdd6tNN3 tdo/XVq+9NX7hE88pVoCBdSwVdljBduu5dqm/VayJdQ89Vm4BdGBfNsKktuzZdC0xaS9pUOz bVu7ddN0lL19+drT7Nuwxa7EPUuszdusDcuuPNzGBVzF9VvCzZMBPb74pFvJPVrfijtpnNnP jdzTvf/buAVa0sVZhZnaHH1dxZ1ac9TchOVX0LXHutXdsV1dsTW62CVQ4GVQ4d3Op01XrfVU tc0dzs3c3UXdwsVd1nVbrbxctFVeCnPcxZ1e6H3erd3CvOne9ape7a3dyVVd003d9OVe9fXe jqxJ5GVW9F3f+W3fzc3e5o1e32Vf+PU/3Kxf8V1U/5Tf/8UqvsXf8DXf/U3gP3zfBVbWAIZc BQ7dAh5c55XgqKVf/m3TQULggrzf62VLMDpeB07e7QU+Ey7hSrM+4n2u2+3g3M3ftT1DF75g prVgeAThvVxMi03hELXhxpTY8T3gGtbfDCbhI55gDxbiHAZiEV5iFEZiDNb/SQPuUTQ8UcuF 4AHWYOl1oQ+G4iSW4gpl4NaDOi7t1ycuXzDmYnrNYir+4jAmyzHetsQzYiVu4wqO4eX14jSG YzWOOhYkYD16xDp+1DvG3ErCufzF4qxK5Bf2sjeM4gQVXTWrRdEbrL29DSWFJKssYvulYVXh ZOHl0tHt4SZm4RFt2N5duQASZVPU409eV0s+YWIzyFJ25AZ94x8eVVhuJDpOWj2VZY1F42ai ZGMjZC5W0Qg+ZhCSW1/2Y1KNwCZazmRe48ljq0B+tFrd4k7e5hXMYrjaZmjOZcQNT8H1PE1q tdZcZhrV229mJXZWZFzd4xvG5mrWUPasZ26OZGY2A2TrHf9nGea0LrQfLC0QM7ZeMgzH/pVA gybfdr6e28QeNezAdFFoaXYtMlLnBRTBgyoyoSXdE/RoffZjb36rh7QcA0NNYyZiLN5oRuxl opXKKcxZjt1ZHxZpapUtF/tUKZVLsbtCVOllJtw+FYFBoYYueKNCoy4ee5ZaufppjBNni7zV dMqfeFbdumvS90Po5TLOrWZlQ/VqzNScgXYwbU64sI5Y4xtp0nHASH3mRK0yOW7iIe6u1VO8 qMbjWy5auM7ndJZHgsbYPiau82IxJhbrQxY7wG4xC0Q2vIZnvUY8UjZsRqXMkZy+dCaWda5Z QA5nvn5Y8QwWAQY3sqQZvgzm/hn/bc0ORyWRbDtTRiJ+bGJdF5cp4tOmn/M8I09sOiFctFD+ 0O/97c485W1cWHE5jMmcZY02a8vwSeMI7ZTe7cR+It9G5dXGIRy2PcOtbohe2vOQDwOx7dET ovkgb7uRD91WKYCmrw3ua2eNaaamJ6SkZj89jn0m2ZArXPL+7v0uO/buZrYeTNUO8H0eEd7E wolca5oG16QKSPAwpc627BCm6/YWEwPPRgQXbFzlyjK9afjendgWcGKU7zy+5zj1Tp6SabxG 7Hv0bALf8L+Gw6Tp8Gtp8beOcJuecAiX8MmOuR3/Z97mY12G7eAWxOHW4XylcOJW7NgLclxu 8lZW2lI8KkxiHuc9JHEl93EWX/Irx3Eef1+GRsYtv2X1Fq4az/AZB3EHyugEH74u/+XxG59r L9diF5+TViRzN39yM0+5LKdnHcdzmJzMyNtrMR9yOD9sf85zQg9xLeRzLgczPUdzSE/z/27X OH9zLU90LLdpI3daxmToteX035Xz5R11o4zyTD/yZ8wxJ3fXMSdyN8b0P3f0Q29odObwO7d0 VM91sVT0JJd1V0cfxkXyObdxp2x0YD/2QkehRGSdSadzY/91ZY/2RfdvNm91yu5z+wbwXvfz XZ91bEcrSYf0QU92agd3ZJ92jxF3bq8Zt8rBoX13HYZpqZ33ZbZyEkRpeJ9pXm/z9S7zSv/3 fnfZgSd46ggIADs= --------------1E53C4C866990F593255AAFB Content-Type: image/gif; name="FC0-pipeline.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="FC0-pipeline.gif" R0lGODlhpQIoAoAAAAAAAP///ywAAAAApQIoAgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o1PwM73/g8MCofEovGITCqXzKbzl4tKp9SqlQa4are4LPcLDovHMi/5jN6Y 0+y2+y1ew+dvOf2Oz+tF9r3/2vcnOEioZ+azwGPQs4iwxigRyIAIcrjT2KB4cOgYoOl5uRiK 2Vmq8akgJ5la2Or62saZuelJ+2i6qsZHixkoWwvqyDnMO4rL8fuQawrb7PwslZxgR8xLCvyp 6XWZBTktbLkNanycaN7bKN1ty973qw1Prgpcu70+Lmq8DM3f77+bjxqrdMxuVauH7R49awe7 3XNn7VuiUeLU0VMojR0p/owXmTFEGKxhxH8kS5o8NdLjOHERDUKi2DFjuFCMWEK8prIjyGQs Qeo8t0mRSIbc2mn0mfGk0kFPmjp1ykJdUYktCy4sxVHmyGo9yw2kWvHlR4IbZ30cijNrzKNJ l7o11Grfh7Zl51VFRxahvZ9jdz7Eee0dUIV4F6KVdCskW7C91u09/DbyH7lwKHegmw+wt4Dg gtp0nPIRRdDYgGZOedquvXiec6YljTSVPtJTtfWVjJuOZTe7dQF6sap3P+G5i1shjgb5BeUn NrfwZRx19OlgmI+xTgE79bjbu4fRXj2qd9zgx5svUZ5LemXn365vDx8Z9xXv49exjx8LOEqV /sXnJ1nffwI6YBdc9A3oT4AILhjaHgp+xV828jiHQVcQiHXhVcpkg8JuFublwoMMIihiNP5p iJaGvlWAGVU6SAdQdgQCpkKJI/4nEIxn2FiWSjwxhk9qnj1EEyprOdSaXhIW6Jclegnp3DDh pCOUkDR2eGOWlZhDDm8nYujVShXVtdiYeSWm5JlPqlmVWiH1hGRXTsZGk5otksCjlvBBh0ee FgFJ40yErUVnS7ZJWWVWmxnE2UErlWbYWDUV06iO6OmJKUpDUsiGn1tBmNOfZ9l5V5nfuPnV moWSCWmPq5aW4oGZzsrifDU2yKZmrbpZG6GRdlInMaiiaWZtHCnW/upFxR5LJF+y0gpthgPl eWIKSS05zaSNTSlKPUTC6ZFj3MK2WrYwIVuUaDsFZouTGDV77HPRzjujRIPGUq1uNTD34Yry 0guwi2RRe+uzdxA85GUqZoDwlQFDK1C/aXj6cJ9xPIVxxhojMd1NDWNpcMX9fXfcb9F9XIaY UJkl8hwoM1xyzMa5w+nECy9H4MY678xzzz7/XEQcMlPxcnKs3IsveEW37N7QUyxNRsQO73iz BVAzrdTVk5g889FTR111rViLrLVpT3fMZZedhi3j2BWXnerZJ3OntNtvO23i3JsamfRcdj8M t8B5dy2Mg2y/+DfAgbvWBdqyLa5w3YnT/gv51/s6PlHlMEs+ebSaa364SdSo7SXnndP6OdfF MWmx6ac7wzGeeEcBehWiQeFy6BHU/rrC7Ek7QuqzR8Z7CEhX2LsffDPOvL+DE425pWu7nry+ wZi9tey2q55bjnkcj3P13xcO1rm6Wz1843rvR7rR1It/X7ZYUWo5zNun75a6hr8fFdD+NyEZ X9gEWNKzH/Twt5TRtc9m/AuZIIp3uUzUiXznE9sB70e4SUDwRQ0sWJAqGB7iAa9AARIeBlen wdb5LWU62aAF8we8egUPgRHM4GlU6IGXyQmEX3AhC2X4Kx5Ggob6WZ8QSdZBa71mfCL8XRAK iLwTys2GHzzY/hHjFqJPWcxq/+tiEmLIpxlK8XndS6EVkwgylo3shUwBY/bEeME4llGC+kJj c36XO/TZSo1hjNEU5Uiex/lwiHY0QS4GGUPEFWIZt+OQ9gBJu+gtsHQrjMEhrajHRSbyjX4k oycDSLdKwuCS1mPjAxO5qEuNMZJGPGUhVanG+JlyMm68jfGIOANE1rCNr3wkIYSjS00BkViw /KMxA6nJXsLxiiGcpfJq6apOsnKVTfwlM5uXxvqtLZPWxCNnoBg+SOYgmLkMZQ7LuTcmOtNw 3ozllqipPirSUpnSpCU324jH5ZUQlz9EYTJFCZyA1Axf9zylE3G1zE+OU5JAqCNA/rM4v4mZ D5iuYGQ0tRnOY07Tn+CkGj1vWarr0I+H5IxivbTiS4XGk6MdFelH38kuqi2moPY8aUMxStOV arSavHzovxJmNApSdI+c5FIxVXqDkloSi7l7qbky18c82nKIRMXeqY660Z02TXBN9akFvZe9 J25xnQYColFTmlWkJlCQk3SpV9t2FYtG1GZT3V1FN3lVtC6UnwAyp++EqYrlxRSn0bgpSe/a Tq/pVadqzRr7BOu+tyoSMZxEk0yZitdnJjavCU2rZ3l6UUqec0WwKcxr2rqFqFJVk5vF7F+1 mtToDfY+TrWlYFoqNNea9TpMkJZYr+nOvcIThi5SKmfl/oMMtRmpLagFRIQyCjayDtaypzAs bG1g3IAK8oySNaRmslvU1V5WkXwMkzBx+1NxbtWatdXFlLKbypw2k7yVNa8B0Zuvxp6kkQP1 qE+9uEOChtaudIVrLOOLXGyi8zLmcx4y7du30XJ1F+/1Ul0zO1/xhteq0AWuyprb2kxKTL7E tUpXJaxg34zOwgPGcA9JfNoGn5ewu33tecEnXccW16Eoxu9kzShRfXQ4twauL2G0A9YEd5e+ IA5xiffD3R7T2MDgpa+GRZpjRjnrvlPOL5eRLNt5/veoq+FP1JTLYR8z1sXsApeNPZzmIut3 lEfop2x4/GY4o7LL8Uyyjkra/hu5tutOV96nkkF6aAfqVs2J7laU88wjywYTpWkGNIwPh53l YnXIUjbpcxa4D5QFFseR7XSkTRxdFNVYz0vNsvz4uzJGrzrHXK51wUgX6n5Sl7Zj9uA3d2RY Uk6Yzl10o5vVII8cWtfWneZ0NruU61a3pspHafSp4wLA2Do7uDs+toNNiGzcNVqJ8iugqIF8 YkiHzMwXE7ew1evkDXe7xQVF8rI9fd1NXy/ao8wZnq1tsNIGddcpXjCth70VVIAZ4dtuuA7u XaGmMDs1wbazmE0d8GSlesuy9rWc2YxpKadn5Ihe8qxBTpdzM3x6vSb3wLbZ4uIRJ9AjnJOH /ezg/pzPOM9W7vmO45xNPqsHzjdxOZV4o3CgC/fg2Bwg62pNcpg2e+cfv/KihZ5ocfMa4x43 6HirfnK8QFvkytb6xPHNc6urHdUcDzi1Fatuj0+lU94g58wvPcCrF5qvOTP72UEuUMgWo+LS Buq/c37tlzMwiBsHO7cjWvRvV7LJYd/lpXXlTdV6OSiHp3ri17X4tr/Y4Vcvc93J/tcRO/6r tZULzn+ud31T/sXv+/xfQk9oXGKMzaS28sI1jnaTqn718UZoeZXu3c6Mr/brFnx4hBzUPbt6 Rr/v+K7S/lWsq9n1pX+s9T39drgDvOs1bfyB8c6e6mu/MJkebe4B/3jB/gm68slPEg7j7nLo S5TxWJY+8S+pfkT3fsVHVQNIf/HnI6iUdIVHQek2fuQWFhFmgHP2dCiXfqgHbywygQhIgKqW eRCmaJzngIgnK3shWhu4dGZFc/HWe3s3XNhFddgzf8TEgI/yaA8IMsOHRPQ2dASGW/PHgRoU NC9oeQf3emyHgig2e0LDfLe2fuO0gF93ftN3JXeXgERYRMEngwqof9rFXi2XgxDHYuZXVCs4 TPLmf9+3WGvmc3vDbsincl/IdUbnMjQohWWIfunUZU8HbvkWdh8iaPpkcc8ETKcXe9g3cNfz hINoNmYYhFZofHPGiGtnWpbjbYtIeiPog1z1/nkjM3bR106OWIaGeE9HCIN8x3CA6FuRmF6u lFORd0eYBIvHAWBiaBVHhm+mWISfRYnAJ1eU5oU95UyzqG/bRIyQxH0FJz1ahoJ8iIoQpYUj tYyBJ2OteHHZ8VyHOG50526jt3JpkYeKJ0TOiIUGB2OqyIKsxnRbh39B53VacIxxI4qN+EGQ iHkZuIttWIlsA4C6Zov+xUVdqIYdKFXwiHxxFY4HKI/aGIx+iIDo+IfqWGThR0AvdC0hyE6p dZAVWHyjRnCb6IH4mIUNB5EPKZG+tz/cdJHkp1kaGXscWXmShl/kKJLmKF0liYYgAo3CSGWo 0YnvyD3aBJMcKJN7/ih/z2iNq4eTQNeCWPWRpaaBAomJBLlGBvmS37hydjiOR1mOkwiSbviP 9ROHH0ZtTfmVJ3mQBRmUoTOUObkt2ViKDLmTDilvedd0r6aM0kSROpl+cJmXMZiRVomVbal0 /MZGujiSdMlhdjmNGpGEb7aXPoGDschaDFaLtbiKgHKYcpmUKTiM+ziD11eDkWmWpRKPAPFb pbSNYKiC4VgkfwmOWFmDvHiWkIKYzDiQpuR3LPdw3ciZwodPiNiOrUmFjgabCCmb/YaUVQia XPiUdHiNPneaJReZ3yci06lF/wdlx0mTiqmcWsiYllib5NdfACk2BPeTyemNqzmHoeia/mw3 kb+JkdoGns35gRcmnGBVliCklblpkqqpc1IHRYSpW7ahmfGpnnMpiYtpnzblm2t4j2iZMo64 ktCZoC4pnJM5hVU3QVQZLvLJkmyoduHJj67xIMGRKvtJoT45nxLaHISXoSQIkvMolWkpMIhp k7SZWST6iyrjn8NGM0tokIVYo+l5nKdoox46ZMn4gw0olrkIohbqmRzaoI8YkFT6T+1JmW65 lkTnjmyZoCaod/YYkt7ZkIf5RffJVpf5VMsXkI50odFYVuw5nBvam/RHpjjqlUgKXXl3myZ6 pdIJghEGfkl6YwX5mHH6cUxKY0DIpXioqCFKn30qdt2nh4fV/ob92R/8wqJyh3QPSqcaCqnG U2eUGqlSKqIzWqlZaZycSRkoip+8aUBC4HbliaGneqQ9x6guap1cWZN76p62aam/NmW7mqJh 6VZRWaObN4a5iqt4taslUprE6axfOqVMtqp3ORHoZZiPqol/F4a7KVBW10DYqY9aaqeP1H5X +Kuzia3Cyqrlxq0YeH+Cameq95xKym2gGqCsma6dZB3duaDfaao8WnPmGqWs+K3QanBPmRgS 0iRBcihtig/O96xTaVXRakipaarVuqVm+qHwqq2wuo67Ja5Q2ZtwSrAOCybwQihSwhiOYi75 SnyiSo+oGpcXW4yTmrMGm09odnmb/iikzzcXaVpyNhhWm/KysoAINKO0fZSoHrtZGouzm6mz EMqnPVul4ZVsQbtJtgo2K4pRClRfhtpCMQt5QBqbKdqrHyuUV+upcFtP16phfjqs8jpUqzm0 22MZv/WqB6qIuEaNlMV+CbEqMusrx6Op4GqzC6lE66qwqZq159lbmadpXttae1sy8zi2amsm jkuyCeEuoutoBkqx8CCENHuudTqqdwS5ETqwZ9o2dlumYQURees8FouyiKO6MVa2bGt9gdNe Z0m1wRMsQiewOpqPBbiqf0p9mQhNcLGC8eJ/kQe1uQq26AG0Mep5dauuqgKlcnu0sZu2ItuY s4C7M6a7/ubJQRsxhMipKg97o+uLQTiXvp0FplK7kJoLvz9qcjnKu817t2dVsvtKpM2FsF85 raAXNqJivSG1Rq/HueObvz86Dwt8ownrtsp7UgIcr+gLvU5Geb1rtlyLqfkqE4JrmuhGZEfo IV9avIgGGpzKriDbmcwLr84LwphrsvRrYhD7LRJ7vMpXscmWRFE7VyKYHDBqo9e5keILJcjr qzbMrARGuzqskFKrPwzTsobLK+2CtnyJwX45GLdUYSrWtcoyLhRccE58lfq7bhpcf+06LR6s rczJw0E4u0/rmEyrLXj7x9U2oj+7M7MVPu9QLkPhIcFmtN7avaqaYXrqrpJ7/lA5fLeaB3+Z vFoW4ijhSbjOOMHvZsbTBlhwN2IbGGAsI8r4G8O3WrscDMC70yvmK56Xer9yGk7g8hgvK8iJ q2qhbF31AYjKMROO6S2z8ZeLC8FyXGOtLJiwC8vAKkFPAHi3HMJCe0PpQnFWcrqvWZHYSIrL nHos/GPiaFtNip9t6caDCcVz/Mp0y7PgbMnvPL8qu7q9uMGP+1AkTF7rIRjs5sDLEYVTXMKL 6r2RzMxYu7xWbMfnC77WnMfJxb+bIyP8yn+HZno+7BW7Bhno2sAwfNDrSc/xHM3ncMWXLJoF 7MjsmHVwfLPIcTucOBr8rLSdm8XB58zcI8kES8Xz/ryUbHuJ+CzUC9thNK2SR/oeFIWLvbjO KUagKahAlynVPKMpJ/3BVILKU+em9Hqi8KnSN23MNq3Hj5yGrrzTsgvPmUm7dwzWN+dXLe2/ vsub77fK9ZTTTnPWClrSdTzPbI20mBqqIHW5apwkNCe2ZdrV0kvCdU3Bdy1FeX3DJB3Afe3Q yqyvBR1FiJwZilwrfcvEhgyw2dt/vAfSkCzSkF3Fk7vHlF3L03XNYz3OnHXKHbXAqmXUFimZ S3zR/+nOb+vSdIjaLbrQap2tlS3OmtzWs8ohY7Io/DzG4Qza1Al8TMiDqVjaZf3MI63aaV3J a92YfvvaK51gXAEqg0rA/vbq1dKtg0Na3c3T1APazmSW0PjL3VBFzQQI0Wgq2ps8aGlMQhX9 isAr3xN9OUHN25vm2HIU3JK63d3d0LXsPfndk1d7W/cYL33LnyYc17yKBQOdjhuc4Ma04FU7 3Enr08PqzcWqhAkd06Ey08pY22S82wI6d5g0nhjLVCFORiNurZRs0h6MxYo4r6/F4+L7wtRz 2z253rRo3tYN4iHdg5Er2T7O11bN1lES3o34htw71N+MjRed5P083aOHJODE2ALq2xueUEXe 23sN5Ft7uumN3LAtWgC+ZWEuXrcXXZ9447yKsE+tU2y+sw3ewSc+YRMU4VmORXgOPYYdWozu /px0lcBn7q+ta9bzPbdUbi9vLn+qK+G6KuQsTUiP/tvxjU6TftkGbdpRDs31HcuFbuWGMqaK fuhbraw1nNhCPmmfHZFPvuqXbuqBLc1VjtW+2KoK9ul5jqzUzdWxGIHqRNq+jt06jemkOtXX PstEDIe0Xuq/EcoCrj1iCu0f3uY6nlWCrtCJicNhoecOTedP6DE3COqwF+44LomU7tE3e9rV juZubuhLPrNEwO24gsHe/qbVCOkO3pLRXu5QDuzd/r/DvumGPuW6Oea7u3MJ76Bb3qy93vC/ nt3oTt+aXr7eXeJ7B/C0F+D0PvJzSu4I7vAhz+8RP8mwjg5VQvLN/mzv+nHL+pnPgfnyemXu UD3zZYftR8/hNdvn8i7L0D3jNC9LDA/zIE/twd6vhG4WdovzFb+o+z10SA7xO89P+M66+s7q 2n3yr571nM71KFnwBq+sCB/2SR/NZN+4GYzQVg+Ybf/jFI/1bi/2S0XMuP7zLu/xUz/teF30 XM7T6/7g6o527V7nwMnymW74By70MV/1cy/sNb/2fp/2DKvRGknDiF344374mU/1iq/3jKv2 Jh7roZ/q7BsJCHbcUF8dZva3ya3qif/Yi9/5jc/QoA/5GcWxhArXgR9+ic7U1x2s1v6+Vsv5 Vy/79BP7xV+KpFlBRSnnuH/2ordo753m/o1azeE7/Xv/931//a9PrgRuIhgOuBr/7t9P17NP rpq/IaE7//0b+MGP1gQQHwNsld/FNGm1dza8ZQaaC8WRdMDtlFIwLbHWjWXxq1n6ncMWzpLe 0vhUgIdi8OfTLXNMJ9ElhEgjx+fOuRpeucuF1ajsQMhdsm1rVpfAY/Gah0W0w8YVhz5P7tfe fjZqSrDqjw1QrzAxJ++mDrHMjOpRUa3RDekiL/Atkw/nx7Jz05GUckTTFFKOilU1lVOGBS3t te+LrcazDPVUlbeWaFajrej3UxezFC/YFVZO2TgxWnqzlfASuNkwO/v2cHK66Y77GzkZ6i9u efKZIldBWLnd/i3clnydxFr/3nxUnv+KNybjtH2bBdCPu2Po7DlTyA5fsh68ThBE2O8iqn3X 6j2pZ/FiQGz+dqVrEjLfw4gq4bAU9e/lORgUkXWshNKhuEHWEH70YAOnn44WbbrMGfTnu5FH l5aDqUvTESs0IRbtYvVqtZ2DepajhVSoxzdYIWIEuzKm0axMS0VFAe5pWpAoyYrctlESQJ+g vp5NOXSsybR+3SltOkdYYsWLGTd2/NjxW3gHC8plS66u2Ltbr3UdmClzt8MLSzY8Rzhw5V6C zbJzexIbVWhnQ3/ezJGrXqd2UAcC7Cl0sd4MVWg2Xdbl65gzY1S8zK12wpS4qXuW/s6g7/Bl v+Ee195umPGWz51PX0589Wyw0XVo5MxTt23V36FwJxUcOX3EtOzfJN9aLeDQiOu0uUJibwb3 qIOPn73sQBAYga4rbTwC9XsOrbUAhES509AjzcCM/FIQr/lMcRCUC9/qrwP8HjRMPxhNzJAL dSSzEMCKDJPNF9pG1GrBGRVB0QMVkWAxlEiMfClEkpT8Lz8PUzujuf02hO7H20oUUb4XlzxS PAr9S8zI8MxR0DsTy0tPpkd4VMzHOKfbEkIat8HuyxXDbJG13GJUD0McEwyQkw6Js+TNr+q8 EykS3xOSmi7z3G7PJDXkU0UytWGkEBthGy1Hviydp8n4/rxIg8V16Dxwt0k7QTLKLkedFAg6 avPUMvOkDNQ1XoOIZ8Iq/RxUy0e5DNZVMHebNUygygS2KWI6JRQqRhmSEdRCfd21PVmzvXG1 VY/tNllKly1LiOxMcPbKTHeBjN12Y6G2V13RMTPWArfldt4J1XVS1cmCHJfYcheptCqBtEAu XcrKdPPT2KaFUlACJSk113wxc2ooeBkb2DpyDX4V4bbGcG7W8hb1j0opmesTxzVJewjfiuvV GA+HRW5Uq1w2Crlg7OJ1VcKdxTRZjIm6WzJepQO8lV6k2bwXWh7pqTDoWHRGVjJxge63x3KL zhpT4K5t02btXn564itlnofe/rFJ3dfOqfcEO1xjVx5M2LCTlbvv+1QKz8wkdfz3uwFdqfXD S2OWVzXhrMaYbIAlrbzrB3wedmNvIUcNcCdHzUsJmfem5BZmd4WaYkgPkzzwq1nGnOsoPI6M wXuI3JrWbyMefbLsSC+usC+9qRlu161V83OpDiaJ8h14j/1u6gNe93jl07R+ZD1gTXuVIvPM 3vW1sX4c53xhh57uIQeaHu9PvDbVaN/pC3151bsdZojTleRvedqzG6hkwamIJWFy7eMD4gbI qmKBjH5k85/7vie028HraAYzFPjsxbwXeQxc/MoYB5MmwPSdhIEdvN6WvkY9+D2sgibhH/4S J6EN/poweWAooAr3oCn7cUiBjhie5cwzRO7pZGATDCIO/xTD8SxsfJ254Q9VqMPmgatmCfzc vUh4QokwEXziUuIWWeJDolHRKKyLzRjDQrwGqhFnb6ubmJAHoiVK8XJAQuO2xOjAYNUxik68 FBtbcrEA7jGHc+Ph0txor+hJr4te5CIYlddHgsWvbGcUpF3qYMZM7eiQcERf2py3H/3pi4yo ywIgMblCY7VQdJIkDA3tBiGVda98jatR1IC4SAtpUZY5y6Mf85ZEYlZuaL3bJNZOOSJEhbJt cbzipxRHRTlaJYUze1/1kMjCCLYSl5ormfsE5651SdJ8sxtlLmGTumBe/tMj/eNmc4riKGNe MnCeDOQ4I+Wlh8HDV+l8ktumeR5Dsi+VZmuV7WjpS0zMr0HnoiRdEFmVE3VviFMUpQdJiUU8 IjSYhWlo8hhVTyB5M6KXa2biKgqoflqQkMLCFY02ii1tOfRkAtMePGuUKoa2VJaWhGX+Qroe oMqOnOKMKT0dptFowvSCtwuhLkP4SFwMU2u7fODPvmm9ZO5Tokk1wURx4lSY6ZSah3SNDX/q 0rJGwqfdfGVXiYjLkaLFlt4jK0V5uFECFrRNF4vqY+TEs61yZqi+zCZLl6nOLyzVcTR9KkfZ adCW5QOACX1pUOyJUt0tdLH3O6pVsRpOs27P/oro9OhBrUXaWkCWj3qrJGHV6kh5juyuU80r Yo7KWWie9a+qpSYoQRrJyfJ1TrIN1VTnuJCViraxAx1rb5GrTeqqJbUdPeC+eGpYox62Og/i W2wltTncjvaO4OmMBn+LWkU20E3842B3fVtY+SkXEeqaSl3fCFtARHeQ6xVbe89HWfuVUgpy fK9xgXvM8N0THNFDU/14O2AAa9WfGCWwOg08xfziiYz0fat9H+xZKJ6hmj8kUjjDcGFOshiw RU3kSjzcycXFzrWv8G9QlRuiLQyPldslqmnRq9kiPle0fT3uVDILXxtfApgM3p6DXQnBgryD IBOWIItz+7uLEiK0/n9SMnCZPNiv9rBqOE4vh6t7XwhbzG9axuQL3eVizaQLxqct8GiI6+TK dFlqUt4zlTP35sh9EMlSlkWeiyzj5F63vm9c8oJJGitA99LRDcZnoU3MXPL+0abGa7Sgq8zl DUt3nQf2dIvVbGRNJ/ahj4JRKSkk5yMC1ML8nJg+zzhm99K4tn+2Zk1I3OYSbwVO4khzsK0b ZrWNeq9CJrKv95zdyorw0jl19ZQ3LVfczNqjvLzj4Yhs51WaGd3pRvepIxtc7Y6X1cWNNoa9 W8xOt5Oq8NbVjndpbhjPk6R+tbaqpT1fYn8X4fae66H/YWvoOZuxuv63DCkM6TNRurkp/mt1 prkN60neeznVdHgo+b0/iU+cZcYQaLsHXuMM7vTg9Y60wq38uuaKe9W4/hu0LY7ym7E7IH1p ObMLqJQoz/vFM3czyAvUZz/P7Myi9rfPcQEtasNV3esuOMwtmnClH7vmtC7byPdd8v+enOrt vvpVhI7xnHOIXUfv+UK7LQqI2rycKqa7XXlu9iRjTuBu3/oN2CrvuZeWrt7mKsNrzV/rlhvt aSd04IGNU8Jf1pFrRvWIH8109DTN8ZXm+9QlbwiV57tVQ7e8Xhs5tRynwuyd3cli3l7JvWuY 9KXvxelx3krVPx1lqNo4qTdv7CqTjnIz7L2i057tNOo+6Am2/v3yAfb7x/9y+EgHeEo776fk Y376tRt95KFfxLFajfjYFby+4d7kzG970HWPdXiROv/6X9/1KdYk+ctvR4g3fNIqD/iWRu5K LvZOyvvYgrXCyCs0Tzdyr/+qJdtWjt5SzeUyKcjSCv7YjNAUD9PgLHjiLvQi4vV+BAIjUIjO j3sor6qIDmIMrutkjvNoDvkU8HlwSr02sCtOEAWFRpz0jvoCyPpEbwqWrbUcsAJncOkScLmU BQdpTP+Uif96EPY+JOuuMOtqb9hi8OuMj9OYUH1u8OmI8Lx4kAqT0G9Sb/1ESMBaz450UO3k 7+PAEASdcAzxiuNYxQzPsHpK0GXW/hD1VADPYNCtvFAOaQax0hD1Lg1FeI1p+o4PuS/m1FAA 8e9kSlDEDNHjEJH+vo9kmA1u/M7kwioSReP5kq7DXDDDuK4QO3ATS2f2GkMLya6WTG0PS7Hi /LBxhrBujI6RXA8JUVET58+IPJE3Eo2SdBF0IPHfsPCCTs2kWofgxAfICFERh1ESl1BimnC6 MpANQzEKpW4KeydCoBENeVG3mqkAi80VibEZjLEbGRDxynAco6gc1y4aCUq4QExj1tHrlBDs BErsyAcIkSXqYKgeRe0eJU0HZ+rz7oICQ2wSARIbObEYbdCUeEyl8lBEbnEZ4UD/9GyvHDI5 qo79WPEa/tsxGwPSCmdxBHWLI3cwIR+Rw5BRIM8REKNmvwzPALOk+7YxDPOOFvlsSvaPFKdN 7byRbRpS3BRM/Kzx/iqyc37yJpWtqUJP7FbRKDeyGU2RIWOSJG+qpyKDJ9nxEGGxDVNSoT6t 4ESx32bynyoBW0SSusKyWjYra5TxuFTSIt8RIx9LBEHxyvgC8o6S72Ynx6rybtAxK3YnGLfv s8ALFrJyF//FVtDm8DbGI2epJmOsFZEpJ6UjHDKRL6eSBjEI30TKGVET/HZuM30yCZ1yvPTy 4ioR1aaBNM8SSx7IQwayMp2m0p4J9+DSnCJLNldH8+zy59jO6sryH6Wyh4SN/huvklqkRSaa E6y4ktGwLiTNURgZMw6PEA7RsDSjM1r+EjjNYuAe06he0yz3cjaTsynHMwgfkj4h0zS1sTex CNyqM+PY8wGJ80LIwpPoMh+lKSY3izY7LvHsTjqDUnyAUifxsDC109Tk8iQdYkHlATzf0l8A 9ClXstRa8necknFUKhwf0T2fM/qoTzEpsQWpYTQnEjq9kub2E4WEJ98a0S0HZUVlEEP3kUYp rEPb48fS8g0TlDx188POc7lO9ChW7CAR0jA1zBZ0FB9x0jaNw52iITdfcTd/EkeZBEujdO/+ zwQFVMwYSnigtNnkUxoJFIFwc0iZdCFvlEQHQ1F2/hS0evQv1PTv/pQHmtNAtTRGHced8jIp VpNRG1XdEFBPPU34/LO80LQ3nG8yJ44mjGjrNBRO9TH9qCRR42dDOTA/T+oZ26k/zdRzbBFQ Wco3fIFQvXMxQ5OpfpD3PhNMVclLDQzvdDQigYrcxq9Kz6tK0LRQv9NWCaZUiy9MeW89KROB +HSYLDVNi5W9Ui4x8xRGNXA4vrRBdSyVOLVOLU1Cxw002OtHu5AES0jbvpL4lDPQPlJXw/VE HLHQYLItz3XbtMBafWRdKfIFsLNwPFMtfW9ZgaZZw9NGZSoU3w5w3DRo/nUZA7ZGzbX1krVW txQ2o7I8v4xYohVi+ZXj/vz07LB1wJiq7TKWVrt1hOj1YO1VzES2U4N1xRjNYj9Wr2aijjTW ZVHpW8tVZsUVWh82NT31G28u11B252K1IN+UKeMUVutVRD+raCn0PJYyEMlQXV/12Zx2KJEW LOdTSWFmYZcU9o6UXO3Py1Q1MFk1RLuWaXvNN9BPUj8VQUPVbEG04qpQqbZQ6zLUZm+PHueW HF+rZfOoSJXwbIVRXL3nFwwIQmEKAJNWC5fWQpESs0LLF7NUWTnWvhoXP/d2AjvINwsPbvuW WDP3MFPEfOx2u5pVXj8QZj3WTlNOBV8yZktiAaPkZl3VcO2R9eYibPtBdslWb71DdAl3SNQ2 /vyM1rLccDDnUW5Z10qHN1NLZ2XhdSSRV/vOZ3mpN1CxVl86N3UTxFHT91Fz9pIIshB712cV N2EjKHzjdnz1VXCpNf4O9480VTVVM5ngN3ENcn6zsX5Vtziht+ncz3ftwWSfkHw11y6QJ34J GHS97oBpJy4V+FBe8Hw56YEtEer8F9EsM2KjsIKJtIAjk2pZuGlH+GildynktGyrNpa6Ei0V Ym231njx1gKndnddmG45uIzyTj25M0Vp0nqN9RfjrXgZxodT8Wtb+FSNJ8w80YcGl0EVcomz tYlxVXf9MmpB9Xsdi281eECzsGb111T5t35CuPpCLXgAeFWhdmyl/naKg7iKmeaK/9JdPxgX eTiCW5dhUxg0L1jmMhiclJiIk2YQxViQj5WQ35iERQUzj9hX9XiAFrfNFPnWEniQC8XHMtRH J3nLmDgN/TWJszZ2o9jdyvg2z3iRNziUBWRPKbVF4zFlu5iL6y9YTeltpNV2ERaRlc6Tw/hS TRc0sgiKLfcZuhSVKbl1ieJXbEpinTR7N/ZQk5kLBZaRa/lIkUqLm0Xndrl/p21QLXO6cLmB T1GbvZWbqThMX5iIGViXrtloRpWepblC/3SNhsYZXZmTj+mYBROIyXd749OZ8QGavRjU1Bei WbNJdRiS1c9yD/SH83iYh/ag9VW/JGuh/nNG+jITcZm3eo14TuENY6zznV+WM7v5YuMZHPFZ bOuzB+PqMKlZawCaGzt1k1c4PwsagjUaf79xnAOZlJWWbnUacqe0gy+3Lr2XpCtQqO+wo31a VD6GnZE6krFaeKFMjqVnVdczpA9ooJlVlj95QIf6TLnaq9+alqMCO6fXqjFaioMWpnVWppV6 nuB4V+F6iI/RQdmYa7sXj/FanhvWjaG6r6suoh97sATNr/v3IhuuOyHYrl95qpOuqkX4fgFb dS9wO3kO5e6gsis6oDxbm85aYdMamWuXsds686C5obkYpy8Ue4MBcdKzsKP6sPe6s3ubqEFb g0Ubt29bgi3I/kh5GrMNFZ5rN7j5GrGFW7aBkboRDrlNmQZKt7k/d5vJEDKyb7PVek2vW/yM e7JRaHQdWrmVxbQvu66d26VRYLele17H+7VfWrUb+/2mtYYfl7Qr+eXA2KAFJbNZuwi31h+B tJft+7xVEb9VaaLSe2I9dYdddL8zBMFbJMtSbMHZ9Ztju7QMJZiTF8Cz+3qH2am7OlsOvIBP rA2V0j7/W3yvOqn528mSbanX25wxUTi6u6WBttlyR8aTY65vF7aJe5ZJnFvjEsVRGV9T9KuM 27fJeBpFKs7UuifZW8Qf/An9Z21l48m5nLpvOb69+7n/E6reqctBdp/bvLjF08Ed/vbGPdh+ oznDMdy8+WbDhVkilRwvv3rO4/zLRwIwlc8H5zjRffCxxCusz8ak8VysH13PB30XXzzcWhO8 3xOU4XzJ5dy/3wXM4m2dFSa/RnqdzS/SydzSrw3QnaHPu8YIV49FQ/zVa8vDsCzGBUFxgKJw xuHXb+tOxtyc2Tq19/wPi3lCKxfCQZyWPf3WmLw4ErURUF1UUdqQCKdviP3NJ71N0erdoB3W MT2G2fzWt7i8W72uRLLR+1LbAerdMeXdhV3Va5zVE4KCDdrFlR0jUdsSt7zYxR3XxRNl1ksf UGVUG8Z1Oyl10ERH0ofCZ3lgZUSAgfxnZ/zfgbnI+93Z/jv93HO8vWr7cKu9nAV+rfmr4s88 yDF+09vczzl6uOt8xOVc163dyU+9wAMevAHz2NW9Nr9bzVcRdmn8zmO+rEM755mY5JM+sLd7 xXve5DmU3FlZhmsP4Ltd5r0cGGk7d217oq363n0avlV734He6glQyzn95PNc69l+l4vu6SMc yRmv0qP+xvh9Ou18AGv92T/++qh8mnkc6+n7zGg6qcs+zc8+I6HSpq1kwiU965H+/W7oxy8d 59Zk6Vtc9zJja6gc8ed78Ob85Z/58cO+8aOd4IXwkDEE8yeapZvPsQtf5iGb9iX6WsqU1iuc 25M88gmdTTYH4RdG4bHslvvT/md+TG0RHd4XyPXdXtDjkPPlW8hbvmfTPp93X7+R/dMnH9Wr 3dQX0NRJnSDb/fv5EfN6t/cbfCzrmGFVH++Dsvodb0bzMOJ5ZVEMH5UIB/SKUNj3f2UJAEZg BrPuMcs1al08dfPHPxiKI1ma05mSnlqybfe9IDuPdqU8L36vMBDYCxKLOdXQKBMlY0cUwraD TqYNT42q20yzl0vTFFaSy1/zNcJFr82zsDeV1GUk59NcqWGP2f4n3h/TIFJb19WTBF0VxpEV xeIWJOJhQhxW3VifIKePYM9moduSS5vcz2DonRPRY5lqJ9kmbCvhaU4UoiVPriVEZKKdrqLv LhjG/k6vLgrgbewzDG1piDTqK6n1qqctDbMztZGrLDT5sli5djo4Ovu0t/p6u7ypXx09H9rb efM+9xJsniLi9MzrNIsdqBbVCo5apWohQ4GcEn7Kh20bvIvdUgnJJiTTtYj1RJWj+E2kvIHv 3KFEB9EfP4sN78XLyKrmv44YW+LK5PMn0KBChxIlihCmR54lzfkMpHTppww0Z4676S9UQHAA k34UVvVpOLBTzfUTC02lTrMG573cGHKsVaxcrYrxqjHtyiBtle79Y9Kp2mfisJwMjG+kvZhU CdJ1axPuMJCPuRiVCJmkYcxi/5Y9y1JvP8KXFWf+erTi4sdxANd09dBu/mPNeaOVVmiY82fB uWm7E036bm3Gh1n1HS179j25GH1v3cn7t+3grDcjdb7HynUIZLMbQ2ahhh3s4b279U22unTQ fm8Wh/7c/fbo3Jjjdax+8u70wPmix1lJOySSMHPIf7lcogUlVGCzWh/t1eYgMnucl5plxnmj 3FUSItcffkxoKJx+HIqEm0dSASgVYasBuGIjNPWShYnEdfDhXCHKd9p6FMJhIXxNNCciQxAG eRuQycUg4BfKnKGMkiy+8+IaWbUlJJEpTSSThSrmx0+MP+L0EXzT2RgbTyTu9AiaF8rIJIIH HjMJWq7VMmaFOI6kY2cYtsail/bxFsVeVLJV/qWfSWmICZIrcSfhopSZt6gwbnbII500FHVp UVfi+ZmejkE5aUYLLYJlpZRa+WWN9elWIaIxplrqiHaCOKFGnV706YaomkpKe4KeqpaZRXa2 Kqth6gprrL4aK2auS95oH6BovdqsJ70iu6usuyobmJz3XduStHe+ZSyixxnX535ySDYrstt6 S+ax324zpbzgYqtqnbSyhymNcSm5rnPwxlqvu/jqSw2/CSu8sMJMvbllvSU1RaxpBzfTr4gp PqzatEMSTGi68Ua8YCIWLztyLAVTy+yOJ4fqyMbUZkXdx9wKazLKy4gW7r05k+rZpiU+eysj zkIMKlTyqjy0y4qq/uHgzE0KtzPOSPtMZ1/6cMp0codm2XFBS1NMc6EBxzyupzkOCLDZV5Mj taZoc9z0zP4NK3BEYqcMMt5kdpEML4BHaMyL4yWoBnndzSu320u5m3XIXHINSKSD3d0z0Erz rW0843W7Ipuj/qddgQraYt7kjdfjudWF5Tt31T1+pya5YA9aM7A3p5OmqwdWwjvMf1/X8oCg 6j0ygSu/vjzxkwY0quRHK9/O8XGbFeyxwNea4CSm/wt6Xj46PH3rqp8E6Ns/w+48KokaPW31 tksXf6q26sx98d2DL+DoBuLP5uKG8R7zoeZwmcNDpGKCMSOZq2SK+lrbUEI/cV1Pd7NJ/pPi 0iA4LfzLcHCKzAYvyBS2WZCA8vGfsg4yu/MwrGHVWpeWytY0l0Rsgv2xXw07xzgT5oN15Btg Nr7nqK010GJNap4MJZhDm4ksctfCAc9kABsb8lBteULd+shXtyNBsIRJ+xYVk4hD80XRFDGs YruehUWZcS6CTkKiEz2mOSYmsY5uKyPlMIdGOlYsi2M0Iu3gx8cnbo5uezxbAGN3yOBArm+B ZNZljni5GX6RkINs4x7xqEEThXGR7GJenlIHjyO20FVg6WQfn4I9aJUvdlpLjSbl58nMNLKL 7HMj0rbIH9xVsIlxaeVkXim3WO6Ck7O0ZHRiiMQ/JsmOdkQl/iULuUtn0kMD6EucBrP5C236 InTkISUdKvckReLymA/6U/5sqcUgUhNv0CTnOS9pyGDojz5/q2cVvHnPPP6OB/DM3zvNWUSt NNORZ8xYTxhlsGgeEJm9bGd8OPihBPLzaf/7hTWlSAx8mhEJkgmoQCHpAyQJE2FrxKX4gOjI 280xd75k4Oh41VHfGVCBFx0IMR0S0ko1R5kuKCVs/KVQlepxb7wkWxxhetH7la6f+dyfEzZ6 In/mEnEg5dbC1hI0D50UoTXNpSyzBaurrrJWAKQRozwYzjQ8tXDu66aCpHo/pl3VpaIMCzoV s8y7asx0A/1hJdMoT3jW1ag/LOlO/l+60oUSQojqZGbx+MdYYFrPoUhdLGWx9k/EJjapmL1r TtJZu3leRXHo+iwNj3pKCxZWq4c1ZmfL6dnJdoOkST1oE1PK18HyVJq3zOQ/ISrQ01JoGj4l ouu65hXiMnRsgrXrbDM7ppw2grpVxK0XRYqvvf71UcHVZZmWCN3PtjZuDylaeQcG1soi0GsG xeSe5rrb8T73odHdEGfh9dZq9Yy6n0qvepmbyh9I8r2kja9ok9tcw4LRt+tECngFKAp6GQ+9 sd2IgD9J4II+dr4TA2yElahaVbKWm99RhF2GB55obfObUCCG59KaT/pEY6gX5iJRdzhSMEwx lN2V3jN5/qtZIStHTjHFzkxbFDovsM6pGASsRoEq5SlTOSi0XV4p0lrlhHUsw1BuaH0vi0nE 4dNNNJWoXFdIuqWmeLP39STcgDwnWfQYudpVs3x/TN+xOrjIDjuyhJl6DC1J1psc9ivLbhzV K8/Zo202MGGtEZ6uolTI0+1zMltU5o4GEleGduCauyfVJ6vLqorOY44HvBy9+ljB26HqfO1r 2dUqVmdCHN4Q74Br8bhv1OCDawat+2Y0Ujq7k5wPq+187CRNlLYgBfCy1XtfaC/Uv8PmIXZr nWodJltoRbRxgu/8Zefymcigne4CEX03aov43O+qS2Ly+0tzGQ7WXn62eGUN/t/rbha2p74X lWo5WkqQkIXFXq+xyV0qspb4kMJG7Sy9jOUbSOG2hmBNnWXrTkvbiOHaHne5X2vqfwPctQqB 9cARyauKh/Vle144pv96tYer+98Sb3SNVcLdUgPp3hwPkceFC/JC7PdiahOVdAl483fDO9Ap fzBXheLsn+sn6NOmnsuTnmedsFvartZw2+TNQAZPPLjpG/E0r26pLaw119EKp1XFmaINurU3 Oacoyb9r8k/uvGjXeEmIvR5mWgud5S3+HPrYbmFRY6LMkk0kXvOOcCuW+rjeZgSFhx74vOVb zAd2FJPIjCDMo9eiHH576NOtcmRrXXVLZ3Q1u30m/u4Bvqibl2ODzU3vpa5pdv/l9KCBb/fC FP3Gr9922ia0c1y14sNTf3lvdZ9cYGzsdx/0e+H4yXspyab4Fz6+u1Gt/Fb7Xcex9jzMpS9S GPdkRpJQPIoTJ1deM1taxKRq1zmP/LJHWfRijx7Z4dy1gVnI6dvnYVukbR3JgZ/MuU7feR/u CV1qtZQBJiBwGY97SR6I7V3kPR2SQQ5E3F7YdB7hqd0FDl3rNQ4Dfh1dtRrzEUQItlxgFSD6 Oc+W3SAOdon5fR/s9eBuLF/5dYWoCSDEnR0F1iDUEZvZFeEiraC4rV1WbY/TpQUK8R8KFlDu QV8S8ltm5V8Eooj/cWC0/lVHttXHNRFhUYlh+mkhZI1PMxneumFJ5kmeisAhBbEgGVaT6A2Q /6Dhgqlh9LGhu5XOWKiQa81h3tWhBOLhANph8hRLHzJdGrIXDZYged0ClBiIigUINzUKCLkf YCDiAoLe4PyhFwUOijWbFJ5IOPiQNIggS2VhBf6WcWGe4nHQpl0f79UcyTgaEzrc2E3ix+ka XDgi7c3iEipcICJjG97U6KEICJFSVL2B6ikg5F2hCSniAMoZXRyUMRKcFqbgDnZczDHiplmf 9umPOiYYHt1fRGmgNv6iDKJiKZJGGaYdFOZgKZEgiX2cIaqZpxVD9j3iLkLPNUqaMGZjMJri /jCO0298Yz1aYml4ITfG4iWez6C13RlulCeeGC+wUYdMDEVa5BP6oXUUIysdGj7SEjYiYbuZ oBJ2oQZO3h2KiTemZLjZCyMlIz6QGXfMmDwG4AEqZEh+1ExuICXmxk2uYhCu5HhREUeO3q/x pFBaYExe4Uj+SgNKogxqwyUUnP7RkvN5zC2SXjHd4wj6YxO62RSO4v6ZpLFBZDzND62V5S1C UTmWZM7cn1HOpBOOYSPiZFD1I132o13KF1qS5FAqHVsmJGO+JVdq3H7UIb4dpQO1Xf21JWHC 5Ckk5pfpgyGel2YmlmdS5Sm2EE62n0SyZFZenPoBJo6R0yuGVihy/p1pqiAlBRzT/d87ahoq QVucRZ/VXaRtUJ+WsdWKvQmklGVo6MXBDZfeJeWGTcXy1VVhZQcEAl1ewuY6+JpTCdo5mp11 PZ5b/mVFbh1vvs9c2lUV8qNTWiUVnuXgfM4xOsIeOoNo4pnNISUWkl96PtJ9hhffnKEPimJO victxueZhdsLBid+voI+RqiEVkb4QWaE6CCkVR8y6uRXWSgK4qU4ml8zNpahcSSNec9UnhCY 0By/AYSE7qbFiV9LFtc0tSfXVU4yAOU3HSeK6udqwueKyt9A5lpm6mh8FqePGh9NCih1+meI diCwuCJoNFV1OWMuqmN2RuC+bWYBndf7/iVidK5n1cAIWAqe68VVRq0jIeKd0QznljLpIdLG l+5nmJKY5c1eYSIglappQapnU3Lpmz4miIEbD+ZmBd1paeWpXhKJk1XplX4anzwp2G0hAsqk X/qgQUjpAykbS1ZoL8mYceKocqrVXLnpYpKRbPYlPGJql4bapl6emC4qdJbHdp6neFUDi17l VpIdgf5naYalpx6TMJkqkCYpAHKjKArbch2leS5GJPqqYyqjrdKpIO4efsElQ9pbjQUlFwbr 0bkqtDLk20wouZarudYqV2SUqLoXWsVYJ9Zdj4KqjFjrqnpopt6lTnHqXlrmMhKnIRwmjLjh NZVoiZrlVM1r/nv5Gx2yalp2GG7y65AVHoZFI+0EFd7BnVTC34z5mvBZYWc16wR64MNC7KWp pUxdqUoG2qedVahJijUyLJzBrFaOabS6JMl2qsSe7MEG7Ok945A+jPZknIGeGsjOYN8hz832 a6ByLIztzBSRKrCZ6ImaltTkqqSiTNEaocgmbcwi4Yhi7W22plhNa8NuLdee4I8maKViJbPK LNZl6IyeraKmLaUSJdteqr1qKUjeptymB7Gqrd1WGbNGYazu7dX2LaDS7dciLbbKLUVSo7lG ruROLuVWruWWFbdGrJwibm0prTlyrnvu5Le1YtSELEmILXtqrreC7uDNLcTgKiDx/i3Z/iqY iuvYcifrot1Eps7Avhpe+uT3kOpGiio2zdBPgO7xamdk5u7MkeO3HebLEiwuON6j1hzsMq/t zuyuYu8RHm7jQsYHup/WEKJyYl8pLheILm/fPu73cu8d4ax2ha+MAq1fyS/5PlL2um/Juq3+ VqLN6hd5RkbsMd70es9druw2Oqjjxu0Mymr/du+GhkyvStHapGlb2WdFIaeQ2iGScq8CO1hX PrDnRrC/Jo3ANR0rrq+m+u3ltrALvzAMxzBQVajYPOfntgkDr+UHoa4IxxYP56/fagaBni2Z 9rARv23onilGfjDedugRPzEgjjCqPmgkErEB/TAUZ7Fg/shw5Z4cvqrwF2uxGI8xGZexGZ8x GqexGq8xG7exG78xHK9hFqNc2ybcAmcu2gIx/B7xfxaqHSctB9crHpvu6t7xINvtH99s+jbx IWst/5LsIguyZHIu5vpwIhPyI1vmEGCxtDayW14yIm+j9qov4g5mzTbv9gIyHCkaLMIplDJv g9RuITMy2eoqKHfytsIyVnCyG7wiL5fJa7CyJrgunf1y2PjyxwKeKUPsMv9UMs9yA/cyESvz cPWKMbvElFyzujgnVo2rNkdFcTSzCgacOH9fOZ8cnMXg/67ON+tBNQrEOStNPLtzO5OuoLwz wcxzCPcn9eiz0vlzK7re8eDz/nUBdECPs1/YkEEnNEHvZUOz8w8HaEpI9D8vNIRadJRidC3T qASZEvJ49IhQtFg+dD+L9BOBdEiTNDCrdPOxBYAlBk+hdEZrdMqY9G3I9Pzg9PXYdN7wdKZi 81jpNLgIdU6zNB/4NNARdUob9U4zdS87NUPfK9ai5grs4zjzC8VhSkEzzE9R9VVrddRlykTS tGr6sNSxrpVh71DocvI6NFCA3ljGsVzPdRsrNV3fNV7ntV7vNV/3tV//9RqD5uvQcQ7HcZm+ chDHpnPCtCTS7sIddh2P5nQUmCizC2Gv8g1XnSezL6jBKBo6thTX5BTz4jc4VmVDKWULzPWC bSOP/iSpbRconfIeRzEqS1RCgaPRUU3TThpZl/aBjpLHqi6PoS9xlwvgACdTFTduj19E+l+a EWNzg9tx764UOjebvl1E+kwHOZ1BIqYAA6Qep41uayJvC89tb5Ibzlr52RZAsdVv507j4Vl3 5yvVqCxisXd9y/dsl2pn43d6a/cAuybCIpnKhncvommBf/d6F5TVJq5/sweDG3h/rtF+fRiF p+z4Akd+F/ZF62C3DKuGvq93obcIxdX4HHdvN2f5Jrh+L5qLjxjceZDRAZRdh9eIn2/ybZJy M+iCfOSMM/aGtoqMn7iOXzOpYdDvRgmRe+/Egrd9j1z9vRUTO6+Ay96DzVM54o0mg9Aqj/vL jCy56CKYla8ea9dvhHcuzJw5h09nn1qv+En5lGv2i495e+/vh3f2sYJ4lzfpnGepKyt5vg5w g4sp9PBP8em5kzM5n955oC/4q0Y0wjp6fst4ejEZgQuknzA6pmuaV6o59rE3b126pLs3ffIj ebffoRPNJxbTKI/4h186pZM5upmSdbcKqpN44Z56NlV4jxP3i6U25RyKsKfedYKEpe+4d2gk VO81ouuoTwbbqEk3YE87tVe7tV87tme7tm87twtCAQAAOw== --------------1E53C4C866990F593255AAFB-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Apr 5 18:28:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tiCG-0001JK-00 for ; Sat, 06 Apr 2002 06:53:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Apr 2002 06:53:04 +0200 (CEST) Received: (qmail 8092 invoked by uid 0); 5 Apr 2002 17:18:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 5 Apr 2002 17:18:17 -0000 Received: by moria.seul.org (Postfix) id DA1701468E7; Fri, 5 Apr 2002 12:18:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B540D1468EE; Fri, 5 Apr 2002 12:18:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 78ABC1468E7 for ; Fri, 5 Apr 2002 12:18:15 -0500 (EST) Received: from seul.org (vlt6-242.n.club-internet.fr [194.158.119.242]) by relay-1m.club-internet.fr (Postfix) with ESMTP id A16B916A6 for ; Fri, 5 Apr 2002 19:18:12 +0200 (CEST) Message-ID: <3CADD0A6.3E9415DA@seul.org> Date: Fri, 05 Apr 2002 18:28:22 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Most instruction are defined as "optional". If a fcpu is release without such instruction it must give an interrupt handler to handel such instruction. Imagine that FMUL r1 r2 r3 are supported. So the instruction trap and ... - "something" (a register?) point on the faulty instruction. - The handler try to extract the register number to emulate the instruction - by using some others registers ? - We need to save some of them (slow?) - How to access indirectly the register set ? (to extract data) So ? I propose to define (later, much later) the subgroup of instructions. It will depend on space used and the impact on performance. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Apr 5 22:55:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tiCH-0001JK-00 for ; Sat, 06 Apr 2002 06:53:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Apr 2002 06:53:05 +0200 (CEST) Received: (qmail 31365 invoked by uid 0); 5 Apr 2002 20:50:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Apr 2002 20:50:30 -0000 Received: by moria.seul.org (Postfix) id 0A6831463AB; Fri, 5 Apr 2002 15:50:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F312C1467F1; Fri, 5 Apr 2002 15:50:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf20bis.bellsouth.net (mail120.mail.bellsouth.net [205.152.58.80]) by moria.seul.org (Postfix) with ESMTP id 9385E1463AB for ; Fri, 5 Apr 2002 15:50:28 -0500 (EST) Received: from computer ([208.60.244.105]) by imf20bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020405205026.PTKD1154.imf20bis.bellsouth.net@computer>; Fri, 5 Apr 2002 15:50:26 -0500 Message-ID: <000801c1dce4$412236a0$69f43cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin64 Date: Fri, 5 Apr 2002 14:55:43 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1DCB1.F5B53460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1DCB1.F5B53460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For those of you that are interested in M2M architecture; have a look at the attached ZIP file. Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C1DCB1.F5B53460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For those of you that are interested in = M2M=20 architecture;
have a look at the attached ZIP = file.
 
Richard E. Hartney
Research Director
Erin Greene &=20 Associates
------=_NextPart_000_0005_01C1DCB1.F5B53460-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Apr 5 23:00:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tiCH-0001JK-01 for ; Sat, 06 Apr 2002 06:53:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Apr 2002 06:53:05 +0200 (CEST) Received: (qmail 15565 invoked by uid 0); 5 Apr 2002 21:16:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 5 Apr 2002 21:16:15 -0000 Received: by moria.seul.org (Postfix) id 40E311467E8; Fri, 5 Apr 2002 16:16:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00D9E1467F7; Fri, 5 Apr 2002 16:16:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 7574B1467E8 for ; Fri, 5 Apr 2002 16:16:12 -0500 (EST) Received: from ifurita (212.194.224.49) by mail.laposte.net (5.5.044) id 3C9FA10C001F1836 for f-cpu@seul.org; Fri, 5 Apr 2002 23:16:08 +0200 Message-ID: <001601c1dce4$e0a44240$31e0c2d4@ifurita> From: "Christophe" To: References: <000801c1dce4$412236a0$69f43cd0@computer> Subject: Re: [f-cpu] Erin64 Date: Fri, 5 Apr 2002 23:00:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Which attached ZIP file ? ----- Original Message ----- From: richard hartny To: Cc: Richard E. Hartny Sent: Friday, April 05, 2002 10:55 PM Subject: [f-cpu] Erin64 For those of you that are interested in M2M architecture; have a look at the attached ZIP file. Richard E. Hartney Research Director Erin Greene & Associates ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 5 23:30:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tiCI-0001JK-00 for ; Sat, 06 Apr 2002 06:53:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Apr 2002 06:53:06 +0200 (CEST) Received: (qmail 16460 invoked by uid 0); 5 Apr 2002 21:24:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 5 Apr 2002 21:24:18 -0000 Received: by moria.seul.org (Postfix) id 5095D1467F1; Fri, 5 Apr 2002 16:24:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 312D414680E; Fri, 5 Apr 2002 16:24:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id B9D6F1467F1 for ; Fri, 5 Apr 2002 16:24:15 -0500 (EST) Received: from f-cpu.org (kdl16-31.n.club-internet.fr [213.44.18.31]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 9682F1688 for ; Fri, 5 Apr 2002 23:24:12 +0200 (CEST) Message-ID: <3CAE1770.BEEBE54C@f-cpu.org> Date: Fri, 05 Apr 2002 23:30:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > Most instruction are defined as "optional". If a fcpu is release without > such instruction it must give an interrupt handler to handel such > instruction. > > Imagine that FMUL r1 r2 r3 are supported. So the instruction trap and ... _________________________________| "not" supported, i guess... > - "something" (a register?) point on the faulty instruction. in the CMB (the instruction pointer). After the instruction is "simulated", the IP must be incremented... > - The handler try to extract the register number to emulate the instruction use the IP from the CMB, fetch the 4-byte data and extract the fields. > - by using some others registers ? these are in the new "task". SRB is certainly triggered. > - We need to save some of them (slow?) why "slow" ? > - How to access indirectly the register set ? (to extract data) fetch them from the CMB. > So ? as you say :-) > I propose to define (later, much later) the subgroup of instructions. It > will depend on space used and the impact on performance. time to wait ;-) read you soon, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Apr 5 23:37:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tiCJ-0001JK-00 for ; Sat, 06 Apr 2002 06:53:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Apr 2002 06:53:07 +0200 (CEST) Received: (qmail 9856 invoked by uid 0); 5 Apr 2002 21:32:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 5 Apr 2002 21:32:41 -0000 Received: by moria.seul.org (Postfix) id EAA2C1467F7; Fri, 5 Apr 2002 16:32:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E05A3146812; Fri, 5 Apr 2002 16:32:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf02bis.bellsouth.net (mail002.mail.bellsouth.net [205.152.58.22]) by moria.seul.org (Postfix) with ESMTP id 17FA71467F7 for ; Fri, 5 Apr 2002 16:32:39 -0500 (EST) Received: from computer ([208.60.244.205]) by imf02bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020405213342.QYDP1180.imf02bis.bellsouth.net@computer>; Fri, 5 Apr 2002 16:33:42 -0500 Message-ID: <001f01c1dcea$1a9adfe0$cdf43cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin 64 Description ZIP file Date: Fri, 5 Apr 2002 15:37:35 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001B_01C1DCB7.CF263C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C1DCB7.CF263C80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C1DCB7.CF263C80" ------=_NextPart_001_001C_01C1DCB7.CF263C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For those of you that are interested in M2M architecture' see thr attached ZIP file. Dick Hartney ------=_NextPart_001_001C_01C1DCB7.CF263C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For those of you that are interested in = M2M=20 architecture'
see thr attached ZIP file.
 
Dick Hartney
------=_NextPart_001_001C_01C1DCB7.CF263C80-- ------=_NextPart_000_001B_01C1DCB7.CF263C80 Content-Type: application/x-zip-compressed; name="hpcsdoc.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hpcsdoc.zip" UEsDBBQAAAAIAEx2hSwi7zs4FmUAAAByAQALAAAASFBDU0RPQy5kb2PsvQd8XFeVP35VLEuxJ3bs xOnw0oyUSLIky3JL8Wg0suSoRTNygRDyNPMkTTyamUyxrSy7OBBCyFISx2RD/rvA7rL7C+yPkIWl BFhqEkoINcvSlhLgTwjNQAgQin/fc869r2hmbMUJdf38+Vrzyr3vlnNPu+fe95lPn/SNf/z3M76p 5h2Xqjr1u8NNqsF3rRb4D3OyXKl34k8N8LvDhw/TpbcBbwcOHz/+bI4f/MuH1HqrqV6pQys+4PYs DlxZdadSJ6rJayavmVg1sUqVHU31q9S5n1Nq/QsFdx+U66fPe26kRv4ePrzMvVbttznS/P9IvXL/ +n/TsWdR+d+TfTncrK9vX1f+dwP+vgp/z8fft60TqjbPX3CNUl0ocb5Hzunvufh7UJ/P/1vaVPnv G1MyYv41JecL+Uvl2bFbKQsJ986iRXH+CVw/RZUfpt7mffOP129U6guqevk+od/7k175O799Tf3M QedL6pT6OtKt8qWb/5fyv6FG8nnYl48przl/Y0oFDpP+qR7+9qaD8rm73svv9VvRtyjP0JRSZ+Hv uShHXHnlOdbDvM/UZwp/l+LvBxs+ff23vvqhGqKnT67x6O5Xm5X6Iso1My30ND+fn+NvhxL6o+Nm PHcG6OCCjJx/dovQhTl/47z+M/Rr/s7vz/l/a9WX8H8oFB0fHLG2jkejI1FrtRWOxUYjg+F4NBbq nYgNjkRjMWtwpH90fDgcHxwdsYbDI+Gt0eHoSNyK7YrFo8OxUFdP51prJJsvzlidnfgvVsw7TjE0 mnDsjBXL5VOZ6UKrNRyz1m5c19PdtmFtT3coFBqbyWacTVZX14a2DevXtfV0dKwN9dv7LDo2ydWu to0bO7pD0Vk7ld5k5WfsfDHjzFlbrEknnS5kS8WZ9gxe5DukSNbo9uj49sHojlDEziScvBWfcfJ2 bs6K7rHTJbuYymassXx2Om/PHiiEwpmkFcnO5kpFPBkr5XKoSSg2OmSNdHS1RYbbOtd3dHW2da0N lR3Ddj4xY3V1dHThZHAkPj7aNxGhVkKjotbWVrRDxrFsvCBcKGQTKbvoFKxUwcqlHbvgJK1i1iqU JmdTRas441hOJpHO0uVCaXbWzs9Z2SkrW8pbvaVCKuMUCtZgZiqbn5XyD9sZe9qZdTJFKzZXKDqz 7dYOhxom5exxLOS4N5VO49yyrelsNmlN4oUhJLdms3vQIVYqg5fTW5N4Pp3NcU65GTzF5eXU03nH LqbnrLyTLCUca44K4xSKKRTBocJ1da2zcvksbhZTeGl/PHqg0B5qCqG5rQRaFB2cKRasvY41Y+N+ wUk7iSLqZ+cdEAkyactOtaEMbeF80eof2xo+ULCa+1NOOmm6Z9aeTDvWVnpfOJ+35wotXLqB1PSM NebkuTnQw1Z8b5Zv9FMRx9CBViw2Hh4ONcfmMomZfDaTLRX4lamENY4Hs7NWOJGgNh12ZrP5uZZ2 yyI6QFFt1NpBy9hFfx0KjjNL3cUVAVl3bkBDZkDsRScxk8mms9NzVmIugcLaBWooq0D1a5W21PV3 9uWcfAq97CTxuh2mVXLU8nYODbmPWxYNvs6ac+w8SCVjuoe6bC+ViUqI5svlnQLS4XIrfiNdPoV0 k07CLhW4b6hrU7PIdI8QCbKiFqb8Uqg4CjCKpprO2mlrKo/moOcnnelUJsOvQi3c2rqjoy2babPb IjOp3GZ+HmUopYtE0HRGfAQjGz1HDZvN4xVECNwR5rUmx+72ddZIzGoesTPZtoKTyGaS6FnpEdCX 0x6K7nEyVkrqoW9QoZ4bHR9tpcrMZgvoIJCrNPfebAlUw7mj3HY6nd1r8SvcyoWTyTzlAr6RT+ie CT5B5UTiFLo7SWSe4ZEm1ShIsydS+UQJg2sya+eTeCoNkuQHbG6Gzg7OEKPMtp7r5LNBIsODA9m9 6M/8ZgsjGmSLzizxgMPQLhTzNI4wtKlkoyAV+ot+bptyiomZzVYGpCg9m5JGojeCblCuTJGG3Q4p Y6E0Pc3Fn+auw3tyRavPKaSmM9Y4usHZa6EIc2gIetcUcT08VczbiaIV3kv1QrObseoj1GtKaHEq Q9JJpApUUDTWrL0bby36CnW7lcyailGrjkUGrWaM1VSOmHBa3pVNp/HawQxePmUnnBYLTcaEC5rM 7iWqp+LKy5kVgZAnwQvmAk9h1GE8y7P+wYm2zRODJTrJeVwC2WnmNFlKTjtFjzExDybOhJTpEjJE y3X2WHEnPwsqSLscFh2NaoJap1LTpbwwYi5eYQb0xkPITjNDSrGEkYFAQ9xJtlppDO5MYo77dxL/ 7U0lizOhvTMpCJEEig1mDZ6SKmbBb9tDoSYq6Qi/hIrgJEr5VBGpkVuCqc0WiiaGihx1DhgrGK3p VGGGq4OO3MPNvlcoNWxFqIfHHTuJDkAm1KG4t5naLZxDwkRAPvI4WcMETe9NTaHBi7pZNnv30Cvg u3ahsDebTzIvrZQZl9GG5LaETXFXgewNMfkbgOvEQ1MayPRFO8o+hZfh8RwEILqJmmoXsQDqiEwW LF6zb5t7ZCpLzIBGA/o1kcqRqCrwQLEK6Ksii2EmexvjNIkipyGJ96QgNIhxojL92TyohQcU5buZ pCvGl1DlnhSTC9UEZDhT5NFvOHVhBpzI1yWGgpAuly3gRdSL1B6TDuWumbooBn2jfZqTkLQjtmrk rLBjSmDoEi0wyKwyLyzAzsxBQYB0miplmKcUdIvgHlrIkHkSfCgrkor7knKY04WedNyn2pvkMGpP fCBqjYmuE+LhlJ28xpGipVhsiE5AfJ7YcAKcutWaIZHtG4ytQjNZ4nNU4+EsUUTCMAcMF6svVciB wc4fhhapQ+gKiHxndtJJooRa9nhDrsDVcahDQtwQkWybdxMUM5ItQvm0dsyk0iTH7KT0LsqfzCZK 1PGbrd2Ok2NRk5Km0Y1bnGEFYS6Hfgc7LnChQpbvoJoVNnHTRDPJtgmqaPPlzpxIDSqZ1DabSc+1 hCoMlFlKEB8ci7WEdJ39N4btxAwUQmvIzkyXMAZapBdEGlM9pEjgzaQRUGmYE4CkiyV07RyTB0gS mUElBfOaxdU1aRtUboUmjbJp+4ollEBZT5aKTEHpFDimEGq/kyQOs4Y1ujVDWRpAW6F25Hn8tGIw UMuFaCxqAreSNjFyGr5ad4B8KDCbcxXx5rFIC4Y0uo7GE/5C3beGwiOtdD7ioPfzu61QzMnjRdYA 2hVD2FkTy04V6QcGWgzaD+qaTBUS1Or0ljikb36NpFmDvCR/GqzEJIX6iQLtVAbmhkN/tZ4DCyQj LITVmE3cibl0abpNP5KBVNUERs+ZAonuX97BBcMJdFcRI4Ye2OZkktKo4aEhj8R80rNPq2+hUJju M7fy91SC9SD0OmXQ50A5KM6yAssFwTXbGCJJH3NAJcBmsoVcqoj80MBb89lSjl5tLrLCmGfW576C CYt0CEipPXNWGLoR1AkSMNBy88K80unQbYakDvpLiqqXwNah0knfZ5y01Y/BCEuxn+yVwQwUQEiC uVa2ydCTXm28m1wt8DBW0yzwQNIF7cJu7pNrS6QGoYC3WxF09mAcPPUynNBgsTOFvSIAd0VjL22X EeR1Rs4Mt6S0TVoPNQguYk4WjU3qQvxhHo5nEhAYc7Nc63iWmtFvrZnh62fag0VSG0xbouPzhSJb anNcemaPtliGoP2CU9wUCnHZYXsPjketiZFBmLmxKBWgf3AoioaDld5qjcE+53YZC4/H0ZkpFint lNgrbopULwxH5tpu7UTUulKN1ebK3IlHDt1P2Dl7MpVOFVMO8/4Ice8Ehn2MxHgr2ampXCnNxlCM VdxSXmvf404xz9bqZDqb2M2UnrSLtrYb3EIJi8g7aE2HSYQoJA/NZAx3JacxEIZXU4ualqrJBlza IWOVxYyPN4rSKGNtBlmkHT3Sry2l8o4MGepKujhrqoA2IPYzjfPr9BnTn64WZe/Wgdua9B0t4Xig ZNDPhnMmpKGoXUmKmKZJ+tugkLrONeZ8z6NuJhcSIYZiZtnK4B5JkKaoExIhHTCcBhmPgFWBK+7G O7N5oWnRHJOa9xS9oWAYrz01Re9mGel4hSVWYbiIrn3R13WGyWEIOZwBGajZWVavZ0rUeTCJ0YJs 5IPGbCj0lMdUKs0Dzxs/rL3MgFlMOk7GNIVWEnWHOIGRY+qJTMvq5+xLiXlE7wEvJ97NP82TZD0U SQVxUkR5TAgZnRvLH7oAwwy6rsO97uboPoFqTmoDkgl7Mlsk7a/PVx6QGaQk3gLSTrHGw7n6KEGP fhJhNFKFUtwatoeYxtxWMfo5i3g/fZseElY2S0pCG+XQqn+Tw8uv8oo5UcqTXYmssolEKUejm2mt s6O1o6MDTV0U2SSmLbjqLA3PQBlutza2buxZ77dtSYxYQVbrLylryrPZJI0X1v076Wpn1waLdSh2 4EgmYWj/eeLFaaEhNiG4IsK9iYEluZ9uGzlIBl6bvLGgW82vGxFJTKHQKamv9jZQI7gj3xFKYv8Z aU+s4VH/kPnEDgvLijhkRKeN7HCpaW+ebMuMZq5speRLGeYH+GmMqQL1Pq4VMD5MN7v3mDRc+6va C1APk7F5mGrnGk7ENtFaNvHEVpLkuhGg8kCcUu1NFjzI7VnHvMoUNlPKs3pTKOphaQrIPZIINoAp ntvB1HrsRABPKTiBxJDc3JJG00cnzjowzjgNN0kiDc2FGiaXT+3BcJlGhtwLMCQyKYj6smbxE5a0 CxGz5iW+VokbYUvpkhiLKMiMpwP4mzUzV9Y1lic1QFsDwk2dfWw5Ua9pI0rSskLkZsFaQqYEGybP 1zxKmPLxYG5aedbPEQO6ilC7EBh5ZAqs3qNdtOCehL5MLIJy3WPnU+QNRY3FJZciNYc0QiZ5KMKg G+LI3DQltC8XFjTelran3ayozuBVIiXdvCgHsUO4FqSkt5Vy7POGrpMHlbLkw3Alm2EyPdfOihcP LvJQUyKwKG2GV64vFcd/Z9pm9QCCU0SwaCV5ziuHR0iWy2tmPZ857pm35CGT8kkuo1ASyGQKEhQ6 DavJkCpa3SvTK4jRzmXsWQxKIzC5DwxBQGqIBLGNYwPGU95iCnESJVK+WA/MUdejyahvWBhK7Vw1 lF2yWhQz/88kS44uxT4S9aWCtuw87V5raCjvFKQZCWvXa2psLMMS53EG27UsZoxJkLYnoSuwxk3y BpwQ4nAGxeB2T0G459muS9nTGbyCnUREHPYeO5XWxDSKcaX7gzmPbiQZl2TNs7oF25r9R1lut0rP oyjUDHtxfc7V9bKTe4iqkRM5vW0IGyo/iZQCewenUvuIA9HcQsFYJrqMJFYzpsmNUp+lKpFRJhI8 D42GNQYSSrpPZ9mGF0epdrHAapqGTYNuL1AXQGcXdYbfWsoUU2kR6OBM1HBud9Pw0A5XZvXU/pqS da2TurBGJzUNw8x+itXhalpHyG+IeF5C8RxyhVik5bKpjIxachG3B0nCkHE6XTb85pMcGxdJ8Ohk iWSBlLPV50LI2aBBm6aFyDdWcJ0CdnI2VSiwVo0h5bCfwpcVVFgZqa2eAiX2g7QZSwlXRh6xhKir 0ef9TGJ+43jZBnJj8tMNYhTGgELqufF4VgcCS2Z1XHtCM55snpUYcypqq8dykynofCi3dJp+BV+F 9u+nBREOhiK8ugkpUU7ZBLEeykaYpduRPl5tG24tNDWdogkYnWm7FfKRA88usuFaJO//FLnjedCw J1FsJ4w8U2Kbi8uvwFtn7bTjtbhfMIE1c0HWciOuawX15llnjRCHC7dK50EZZtf+LrG9iqKq63v5 0rS1k9tlRKbnCtKgm6miDs/WyngyurpIL9JmCsIxaJ4hDZ7Y6ronRFmZYnmXSaSkjKQTk36ccK0n I4Vk4LAyTL5tksCOm+u8TEVYpDJ7suk9WsNh5bmMMFkhRzMX5O1caRZjVHxx3HndjrIHzB4z1I0A 0VYDzwJTN3EL8gQM+BMZnFqu4E62UGjDCISMcS1nbtFUwQjiqVQefauFn7h+SRkRweP6BuZE6RIj sKBLXOAisHWoLdF2orJZIexUBjLKtanY8Yp+p0lObZ1Z7OEnXSKbFilKohlNnGIa5V+SgUwFzOUc UpSJ+NGaoocKmzVS1WUeNNhdxutyI/20dvjNiM9Y+sY3zpGLzfOrZk4QRN8O2cfucM7YM2NNRTJJ 1xDhavv5DSvq6EpyulJvpous66CFaI4yn52jEhay0sCm38XHbyehzBXFqEHSNARzO2u7btl52HOh xLHtcF1FzbbzRdclIywhxyZ9GLKCr2nqLVgj4eFonysjcuyLmdLPeznk511pnU+g5ITzHFTRzDTN mOjp2jbjUiB3Mg2dMoeOa6UKf9Zmaq8xU2f1DGzY74F0LQb21JIWq4e3+3KXobUGtGsuZxoMJSPi O4NOTVOVkzY0WjoGM24Uh0+f2BRqunA7zb3m7Vwq6U54y1SW19qkqHF58XhkJksTWrh123Q6O2mn D1JTptnL7qWnZHi4TyujGT3/m53Sjg0WS/QOPBRz0syKsx6jMZ4gcElubnpsOJsEQ8lrR5Ju5YRM J+N2uFTMEoUm5ru/hIJ1gWIyGE17Vmp9Vm73oDCT9DqqctQY4yQHYY2gBNq1JRyK0+O50Uxbmoy1 YVGt9fvJQ2j1YeSSzEtxVbwHkwH+qudW9CQ99HxUClYK+5LEK+2ky99DKdmP00tyaNzXZEd7T4V5 AGu1FdedxTIh1AQzw9zkzsok14w7CYf8tEwcxewaVtrG0SRgNzGwtOZCC3X+6I4RENtwtI3mC1CE hLbL3I5xtbKxPPt/IRdHRuM87qNQTvP8diks8huLhi+3xqLjg6N91kQsSl7lHYNDQ5wkEsYV2KXb B2Ph3iHcCA/GQ6FYfHwiEp8Yj1qj/ZaeJdw6Hh4eHhzZqqPFZPaQ3NWW+zTbZkSnfsfiVEAP115J NtPFASM2P1icnSkSYbfrGTh0irifWIkyU3Y0V5j2VBPm9uZdm0I87xDiPh3jQRKfmVcW0lzcDEj6 JfGL3iOqGpswxgxKsD4vYiKV5wklMUFFRDnc0mlSuCHuJ9NmsjpjXiCygK0spuWU2CepDLgRZT7L 08zGecXPMWEwcyUXn9hO4HUUmKBHdqrgmt0iaCbJdJmeFT2Vg8HYRGpLO5lpqFLikhdxoS9lxSvB d8RxJx4Lx3W8JmZsMr1AfaRNuX6MefYmCRM9p6/ZPTMJKUp7qCks1dYTcQXrtoh4hgsHRS4xp/T7 fJl0XJnGmqB+E9s0DgdSJXnkaaPKz/vEmiIKsvSbydjklNROYocyhUipW1m1KPEPIi0jxAteL+ia 07xMinQTX75odvZpZqxemfRIZzPTXGmvD92aF41rRBeTK9oMDsRMvcVMX7IY1uqPsXSk96Uws6Tr 4MUjZqKF3qmnZUeYJEFZkzpkpGJXmgL4ZxpJSQt2owQxlFiUN0Vt3PHqJFQjsR+mevM7SQ/MpMe7 /RUXIWZ0FPcOKS++dgiMbJF5WqYGW0eia6ArgK1q/0jBDY+QEpABKvXlQZqd3wK+WcK8jucSYteO N2So3Yik+1vBeUQe8zRJnndn2gIzU0bStlsDZL85bPyyEOAx6GScqRSrWWS0GfcQ2XAwqtvc0dEq 5+LUTLoORap6QBRP83RvxsEzWs/k1+czxrLiHsqXcuySKpJV55o0ZMXKNTO66OFpV3HQ8UfBqV9Q l3ma/cyu4mH6dcZMoAeCrbg1xBrOiLe5KL5aYarQ9InV8sDOlBGszCE5AYaT4sEX82kwhlig/Bdp dENk2uymmLLzYrlpMSQcVRqpVfd/wOvq6XNFCU51Aw11T3Mcp0TEmHbmoeTNywtN20bVYhcfh075 eIPm5S7Nh9pZxA6FR7ZOQGbzzLZPDM5mk9LKVFYOkhFPJDVufMYYdNq6k4HAaciDiqv0UyRJoejP hruAZYt/+tqdPkT5nBwYYH43WQg04bVPPO8mviWlJ3kn54xnWcQUCCOXRSldJzUZYnooyqRWQby0 2izTxYESHhVnxaZQ36joG2E9Nd7bKjPjkdAObhlfj0gsX5EsGN0smkj1SA/FJDYtlRFejCyzGWEy vWRmsu3TzC4FJ9eCN4T6BmNjQ+FdPDVvjUcjo+N9VV6b1NFOLlcjNpe0bpNEB2HhZvx9YrqPO8RX c+FiblhVCa1n+Sf7yeUeaoK8kahbSV+JHAwNFKTKpmGteFa6et4N38gQBYUM7goF3kRvb2rqiw6H R/qkY0hL7NSdQ7/j0VicnorPayFDC5NzprFYs5VmiaBHbYgZO7Obm0+o2TRqopSnQEwTE8/yX1wI rLB3tnuzQPwMcswYQqDK0ouI/GkW2MwLTc7xHJXLsqgEu3WQF8Rv0fQKzRQYXYNdCK1uUx3wZplM 0bR0dDiyhomMm0eIzLSOr7jEDTMUZccRlfPmrSYd3Z96XPLrN0kHjD61xp8/Kvxv0vPU2hdkbGbT M/NKThzcC9b2DXb2ELnUx7HolLNMiBJz8Gc95R+W7WJVREaHx1ClcVfR3sNhyiZvH1diYnLDu0w1 9CmPFpvjGUN6eIHk8/lsvi0x4yQktoiEmgmy4Dgu11PQbu0g4pkRrz55Fnkaltm7v9FmRJIxpUnn +csinUfUw7EQbudVHFFNIV31I3Zp3Je9R+S+twhV6bO8qPjeFCr7emftfanZ0qxndwVUUxOBE7Sd PEanm8a8T8ZBQRyrjlYkvOKZwBk0EgdaUF6z9jRscJpPnbILxITQs8Hpata1PJkAxR/ab57DHIsU apJPcigq7BzwQstzK6XanXaOoIqPU5BhZLQ3PGQ5xcRLXXena6+JrPc5u0VP0V3FBpnnSiKhzapt hVBcO6N1JXbfi9tMphrjvOLAS0JPm2l+NvFImXVmJ6mfEppEaa5qlvy33iDiwHOJZEhl5Kbn6vEi ndr92rBbEW+0SXeQg23O6un2Yj+MU01HxVM6UbVMOEVizp1hYPWXqIk9I8hU3L8+72+wSOxGrxSt UqTwPn+0CsVZOw77gvNaRCBj6An+t/mXBMh8iWZuXlF9ju18iXRsHaTuOtjzho37YuE1F+dCaX+m 671jx3NmTk+lGPtdN3bQqPYGXbFA7jkUQtZo0KS50S7pQV5uxK4PCetl0iL3KXRZTz20HLK+vA4U buKqAY43GWCb4HgexB6JBmSHGJPeXVJwxHdQcB01TM+ThWy6xDpanpYrFHh+O87qDglPCr0io4a1 cVLicDFfYgu5oH35mhm0ssclSP9sPOadNtb7dZSSa5fIHPNoxuM4vs53DbxUwRUFpkjseSFDjBwI soIl52TsdFHm63SsudtFfGb6wFvaliDfXQZyCIyYFZvozvDw2FA0Fgq1W2PufKAoflnw1dksBUUR e+O8/UGU/hbVM250MWQm5Q2T9IscHi0J7a7Vcqzo7Cua394iCJNjq1anYEuEpmFOirqolXfPUUNn pNjQKh1XR5nM7mPu2i5hWW5GVrPRf0hrIg7YwrWQ4NYEr2uxhrMFV357KYMvphe1ilZKk16t9FJv VjVrFGHR7czkhx3wKLvKEcutMnnFyxGEPZKVJlmhUWZkgVarXxjDvl/jZqepkLUWeW+1SkySuEw6 rhokPlfYUWaWx5bIQyirm0KNIaMRk6EQHhobCJOWxj+soUEIcP/vsCzICId65UdvKCI/IqE++dEX ovdQZ5N+a3tv8dsjFV9jsm4yWTeZrJv8WZsqmMnCStUQ06WpiSaINoXk/3Bf33g0Ftskb9EnIagq uNIXjtOfJt8ZChzeOjIaG6QUvPjEe3VOHCkm6CIwfQczI2BihOOD0ZF4TGtF8dFha9voSBTngyMB 2ww1kFpKafWJW0596iufbhO3lCHKws3/ws4OaziMd8TiF4a6Nly4YU1X15qN3RfitbGJIbo+MBq5 XL/NK9a811peLr4SdG2QIug8y0oSfAfK1eebFaa1UPnUpJP0IkgM+bq8AnVp9HcnvS1k+sjUn0vu azFpG1PGKt3t79T5rReLxqXPkL822TsvOXInhgZH2twStloujc/LxevcSg0n5Z/fBbql3TNdA69D 2t0sqzd8PMCBUwUJAJNYCmZy0FhIzoG5g4eTe6fdGnKMmJrk8ZsyEwVIPqIdu+w7drUW/VDWjRtw I9tMw0kGeylT461x5QP6X4aAjzT0zINx/rJ6aOQHLzeXKJB0arfjiyTwykEyfG2HXsucTSe9gIa9 rgtEh4xJFaAjldKkEc5kE7vb/cRANox0Y/Oulkrk0LyzBYO5v9Jw51vs8nH76JKDgT46GCIin596 XmKcXLK2A3Rm7bykc1PnppEtIT3nRCupwcp9sQnUAq3SuGSJ6r6W5tLeM27WvXrqV5N0P2yPy4X+ WL3hi9tGQcWj4ctjaJABsOjR8V1mfi3g5POcy0aDwKsneZ8B9gJtG43FrOZtowMjI4PhCK0wzrTF ZrI5PePXolei0iprvejcUwhozbwVyeZzWb3qVdMNepZiwjf2dBzwraozKzQ38Ts3WWGrLxob3DoS HT8Qs2hfBip/eARKEk0v0l4SsLVGR9rQH2LFT8Sj43rC0OrdZW1rj7RbsRl7ryHF+cVptWIk3nmG NmHDerPTKZB0JkXyKUfmt+t7hUEciUb7Bke2xqzbrX5aErVtdHAk7r03MjrSHx2PjkTASlCz7vbQ KA1EshQ4vjxDISawdPKBrROo2VjPIX0jY9ptIgMVGHqwOArGYMAVJkt5iKtmmOst/guD/gU5ZmUf EwGqRuqTfwuJwUxCVx5Va+4fHYu1UGVo2I0aG3yswpIjNvAlPxgtukJioXm8ILCUMXiELg8PxtBE lhVBXw22RdB8F+qOQvePDvWZXguPRwYG41GZ3w15r3XfSu3FPiV5McfYo7XXySyPhELre50b13e1 +5cNhCRaBoNnAPxpjgMJycA1E40FimHt6xtrW9fZI/E5fNbd2aOzwS/o7XRdtrZIsnVm1t9T2Cat c2Sn094UGY1mutf4nte5WQWMSV0pb2MLMuq160mvEhimCDBfGyRlbld848WUF2Bk1iJX2fTDZwFv 5gnFrATb0vr7krBjUrRvd2fN9BSJbxUdvz5VoKXosuC8KWamoLRNTOaIWRK/KTSYgTp7bYl6KkLx bXrphwlDdIl2zF34vlpEGJ5wNoVkCUc6Wyz4V49y9GBzd0vw2T5en7TXzsnGFzZ5XilPiqcpf9C3 P8TGDlBCOp3Sm0pQBLLDzoVAqlhqn9Xcw7sOcKTeBC/nwAiVuJwhcmDn2AOcT+3muTdviMgKc7I3 QwUj0TOuEWC62V3ty8pqQYRuhpeZ2sZNpT0BhdS+IoWDNXeiRJMpX3w2kahpKr3Yn17nC6vjaaVs nih4MKPdglnaWCHpkIkW9hJRL+kOY/bMLjf/yhzxjGQlvMI4K8i0HMunsnnxCPAEmaGYVlZjXKaI kSQzl5pHm/FHvZKDFVciaaJXD5v4eZoo7vMvRaOHfcTBC7it5g0tFO9RNPNhObPgoae92xoWbxRV r2J8DbUQKb68jIKXvcUciYZ1He1ru6zOnrZejmqFuuSPVXYdA81mlrpV60c55FFowai50GOF1mAM LxmPboWUhgTps+LjYVKgxy8ngReDjhEdj/l2WCKWOjgSabVGwrGBCaipI+0DmijI5tbxRpp4cjNz OrKFVYY219lKNaR2Y7IQxcs3PdLZ0bnRm80v+OombEVWGVOMwm3jsPFpG5DdB70ElvYN0OQJSbgC r68kdxBNi5vBqSmvCGZJJcrZqXybuz6LZik3QwWhDu2koLwpxymi4da1N41AFagiMFzvM7vRtcAt yu4sOaI1zWLIkdUuM5v2NRyjrD1MOniFVSzftgB5Pzf374ijA0f0mwZjYavZvylLDEIhnE/MpGim u5R3WsxksKZztEpMT3Wn/KOK+04vQtedVaj6nLdEMTPDsT48w+tff6pDgT2DoSjRY1oaYaDlsuLl lAkO472i+oiz0PUEo48zZEWQqLBz7K2P7gTlcrDWaH98R3g8qrOV6Rdp4GCYE+VdknU7stHPgndc 4sUJtHGTrD+kevHuTTn2eJJKkHJKlC8ziKmsTDgy/5OliUce77z+mFgKpWR36ARpLs0TQoddG1rM Fit8PRaX7c38U9s2jcI1/Wh4a8ym9el6QLa63L1VNnJoNQF1sED6LNlbpVUrHry5gvHWu9sLUDXc 3W+sIdrHRje1+yQ7mnJmKXaCVsgnmBsYeSsxoAlvjyp6IWkT+lntZSUdhyMFI0ashPUrmCXqNZUc nKRF/RqzfI3eomvGmbuVk6FlljSlqvEeGfNdHd0b/BzIi93a0OG/nsNbeDaWXqWTrmvv4Wt6/iAu QaI0+TOTMlszuVeNQ5BMah/D8+sOLAV53Q69xBXSOpo4a3YlkLlIIprtaP2shPvbmuTd6KC8k7a1 oLJJqELUzhgZq8W1rIs0q9ADAdGpgKTr7tjY4yu12TUjlqDdUKgtTRAXq75TLL90rntSBa0OGIpm 4UGTJeSZc/K+BcA82nXZxJIKFluCq8OxyOBgqDk869D6hQzRiMycRWiqaYoVDE8pZToWZtJCsfQc wF6Q0BvHXVDuD5GPuNJlq5Euuisr3LGaI1tbuOS0BJEih0iR0OtGPAXBLzBNZtwM++ZFnVFhPIKg KTOtHfk0LHomsvVAQbeHxOC5NZNlDBxLgY5fb+2zNsKS2+fQ4hYojPu8yHiaqCjoraVoSpCl954U BXbSok/Ulve9SObZSjQWhSTipVBE0xL16RmwrnbtRjHiTTJeaPQ3d7ZYl6fS2VkKz2ynLcfyqeuo 8mmm+e2wUFn2TdHKIxgumYQ3u+Ivb/ViaiqbRzooBPHvNm/3PU3DfKGbC2lot783ArO1hNYI9ZZY nCTNW1os5jFrdtBaDas5CkHX4hufuo0oA5OhmaiD/saBcjynk4cizdMrLNX9gtydHd3MQ5BYL3dL wMaDwTgc3qwdVK68YwXYDE2JuDRDS7Lwx7GGmrikvVkUZygLFZK5PI8MIh5bz2SM0Z40bRNjrNuA fEEjJJxZZvtKbdhKhvKhQuoL4CYiSIsz89wGvk1jxrydj6T5PGekO/vO3jd6PcoFU68Afd3aygsO eO1UMRSh9Q7uTl6rA8XYfPRXh6RDq6XnOnh6GmxNtykq8ISCLuBt4xMjB9k0oeReNUO9wew4VIKr CW52my/v8SxFszgHxRVBDUITSZo/0g5+aLAJcp55cTyt819mpklBNAND8YAnQROfnqOkkBSSkklZ jewrHs8hUtg2Mx9XYdVLRm1RUfRuA+hx2hAh7q4WlyUp7kLjy/1TcLLmXIu8CLQlMn/0glVakpun vf5szcP1FglegaEBxwZb3NmuBG/dQXyBiM3bdoEHuGbzvq536yfclfdEEmXOHc7tobBeLIHBgPt7 6BG/lu0OclmDtVnK6jXwrDcsbE1Rs55XggIOMtNQS2IcXCrKt1zp8zZ4DGSo9100A6XCEEz5NZj1 XVYvWSSTc9Qpl7vOlsAYDaQI9XQHkugX6aFWKYUkoOfXdXZdbmnua7p5DfftmsH2vnbL7OrnKpa6 UyKDkQmI0SwvlfN1b0R2WyMvZZFFrMgon3eeU+oYVT1Fr/dns6CBTYFCIhTY3ZbKrJEfGE8tIe0B iHHIGMrOajFVulVzHsd1LCdtd7Mb93GZZ56x00WvDDFa1ebkN4fMlCbdIdsOOU+mtPIrRdL+M3fh tLfDAj1YPqDdiAFK3eq9UrbA1VPj7iDhhjMN63I9n1RutmFR8moDh6Qt6ewtraYN0YQxIcAdWb0N o+sv8dbUBXQVdpuNcB3IrelywzX9RqtjrQxvnieQzYanOn8fD+BKZjymmHM3LjOaE9U/RX4vO5nS MltsQO3OKlVuQqoPsujLlsgY4HfpGS9xfZk+0a+RInnNyjZ/jvZAo1UwOT1xzlMZ8iiPTtIJ2S8u 3Gq7XkRfsIbGOlvxXxf9t1ZE5Vg3sQ/bLIypZDIadcY1blhEZ/TSf4wG8Q9wG0xr081beKdZprxE V8snYA5aHJ3FQytTDIxHDDLjD+QN6lK0LbQtvmi3MR2jGN8WS01nOIrlCFlSYKyT8yuxfq17tzNn YhECexHqSBlHx8aYoHIZqboxBlk5cte0EcW1V93lU8KZzeoga8fAKL9nx0B0PKp/heNWfNdYlM37 cDzMheJWKMkKrzlual876zYxcYQSDM2Gpw6cnDAJYSPRbqDM/ssX3hV8m5hRz4fNMz77QcS258H1 bbHibbVM5NDnTJamp70JFstsP0j1Msthfdshh12OK/4EaluflS/jTPhDW6zo5HTApwlwMAQrFOFT QOiNBRSaYr5Yurvbtzi+6nLrzJK0nTOFMz1mlMl8UHD53e46O9rPchBVbXN3OOTepjWBsvlycN03 VbrALgjeKfp2rTUPDo+NxmKDtHKQqrx9cHwiJm4vUvN8HW12thQHhpmhC8di0eHeoV0SkOPbM6pk nDvB/aLcaDfPdw/6RM2T7mSm57/PCg2a/W10vWezJV4tYpF/1GPQdqVZD9FGKinBlrttniudnqrX zFspI3a450JsDXSe+J8CaoWxL4/kEdUbqQYco3qvAO8hv1YE04C9HAE6TonoEo2PrEbW+5oLNJVO 9o7e0rEV4yHL3o0pL6IVV6PDg9YQsY7+VFpP54nX0+8C07Yps36pWcFhp7RTcHf3qmwUs3ORwy9l rbb2QBufZygUZhez2VBGgonFGBx1l53rEe/3F+rtzuZ1SsjzuFfQgAuuZxM0tEbvaGKnXS8RVbzK /qHzMzLReXpfOc9jUI1E02YZRLnu7qNYb9cyWmZAG6Fy4LxZYS3Kt17fSJpnRtwV2kkpJGkWPLmO Pb0pm1yX7kuxq65/Ygjj2oQyk1GQYbcTuxNZrBFXn50E2SSMIxM9ertY/ezjpDja9sAuczmPB+IV 8dF4mF8ymU5xH1vu8oBZvbMu+xFQA9ef4EDTyc5ZY6mcwy5KPTUh5nh2d1uYJona4m5gKNlWJmRX U8pYoBBT5PyotDxA53y7cNIcr0Jn5UXP/rtmJay6VCKfbfNVjntpqpRn3u6Gg7NsJZXBi2Wlt5cF ndKN+fso02xUVhdWb41Gj7mr8wL7ZQbykPHiORoCVltqnzHsJICudzw8EhloaursuYDPKcgl2tSE ESXn4fHB+MCaodGtg5Gm7nVybWg0TLGOXSbJwGB/vInSdF9Acp06x07PUWCRLlf5ZoStnqfO+0pG yvWwF3h5Hq0zlBAd2uTdI5Y5cZsFvtvAEeiJIot60w9uMWiizL87e6uWisxbMyaSsCkwJzsuX94o Zun2tuExNNHazg14SrqE/XXyAQC6H4tT/df3dFd5YGR0jF9R6d5QX3hNLB5G+rUbO3gGr9DUhJ/6 VrivD7c6O3vMLfw0qSZ6adMCa4N7j36bdCOUZWf3Bjdd9wZ9Kzoe5nRrfenWuulG5Wan76b7xsiw 3MR7vLs40bfjEZ22w5fWVCQSjvHN9d3ezfXd+uagzriry7vZ1aVvDm0dl2zX+l/qNtD4uC5TxdtD W4ck8bqKiYdiR0ocHje3O/n2/MTmzV0V39y3k3uuO3iTDo5hkW0aItFYbHQ8FLICn7GJV2AJMlp6 utsoVIF2G8ub/WDIohV7OW0mIkPupJPmWess3yc/rEpaD2tDpBS1BNUWw5v9+++aLYuoROKKEaYY 4Dae/LX5uy30lM8hpK/4HUJhd/LGja00gS/EGvRs97z5Ah1fE1CgTcCm3zFsedMp3roEs0mkNUUb +smeMl4N8jCK88VsSgyLnh5mUwnLrLyUBso7ev26nztP04Q87fMh0+KuWIZSWZqlKeVsPtQcbhvX D9JncGL+cJQ9LOOdpN+JKeptjvQ4MBJrcM0ofaHIt+bLbzBxC1BEKzW+5/a3yt3+3LJsexJfmnLE YKog67XkIDXC9c4Y4mA5p/VVlyQCHln6PoUY/JqwXZmr7S/27vJm7AUKjizwTjQcVx5Ywk6tkHfs dBsvGcnqnV9kwwNvH3itt5LNx9WZzNNMAO3750hIYCBPHZsN/Sqd1dt0GMrgjDlYjR5t9b9D59+q 60lkpoMiC6lZ/1Zwett/s0OglosFWpFklBNDzF7b+EIvcr6H9IJM8WX5P6mjL/k+oOP6093wPMv9 gsOBgvYicUAaNC1xC2uCnuIdxDMmtMObiZFvsIBxiNrmV4FmsuJu2mu0WqlKO60HiEXGB8c8xgZT NqU1Mz9ru6KUSuyWT8v4I16vGOrp6ehog37fA7qCaR4aS9u8OUYvzfBvzaeS8o0q4zAy6lAincpB lei30ZBzeo2ljmCQbyDoB3UyKkNBK060YVTThPA4EBJ99cxqRntM8ugptJB42rC2g40PObo71nZV SDOphxulWLu2u7s8BbtvZSObCKXZ1NRknuj0PS3HRiToTWkbQLxk/CJJs65jbSDFug4S3GNDQ+ah I+TcvROP9qPF2qbSWf4CweCoP+8usOtg3iT1OwtFK5BI5tokHV7T1bmxvMZdZLccKVFXhYaVCaNp zwzf5FaGlIyutV2mTl0b127cuA5JtqdsGLO7JUmRkzRt7OrokE5Yv3Hd+o0bKGttq0tHjMCs9tpp Y6DOfAUJRmORTnncNOm6DssaHrgOtM5fphLuK3u3axJj48IBh89nbDeaVVMeiQyJFxc3YYGjUUqz JpxKXBXaJ3eJtW4k1uqO7YJTpK0j+apYniQXchxTyDIdP1vNt8C0h1HW8dAznMw14qkcFT+0Faqu kGSsqOF1Zjx5scEmFHHYFyMcUBHmB3fRxFeYhOGOmTnYfrwD+GX06YiiFyvFazhk2/dWdxcWzYno IxP6CxFeq7MUjCVmHNk2bZBrzwPudgzp7QN9Q3g+FBYX3VEnxLw5Gq8hZGtePcHgE/GWke9k76RN OJerHfhcQJ4tWsnMNlY1hRDbvslc4vs8fWH8hnmZ926jeW8hp9vE7zMxdlAvCOUPj7WaCvi9kKjh bTwxMoq2OdhK85tsIhV9X7CBQmVWY5PMvo09iAdBUVO0lxHLkFCoYjyeXSnMjhXH+VF2cTeyLpwm 9yH7YHttcO60FaO5ItFFPFUn6+l51pAzVVwzztEp/CxUMPnUml76E5TBkKDiOBarWabaUag1RJjz VBhyhxe5ETLOtMxMzZkQPJ7CSrnTOPxm/ZU0vekB+Wi4ySiFnoOr5PdppzCMWYdnzm6v8AEabkde QhLl6HHLkkUSVdpa3sgRvrJHcKi/Pw4lsEgzlRTRKu/lz9qUTYXm/O5x7SIjiriNnbzGI3aQO415 i+v5mueARCmHyZtNq7ltUZ5SQZvc+JjMjLg3tvyT4mODLVoLHoaqNpndR8TmV5u3G7WZY6cpUNuv P+cdr0pmT1v6wAOpsRTNnpFNVbK0CSb5M9f0UYQXe/Qpwka/prvFVeCkoQs+JRZFpPDVorTP/CrQ SimuXqzihH+rCR6ba0Wz8XauQa+JmeU2X9byvMneajTXwW3Cc4q8G563N4H5gqHZBFvTrHl1QGsn rx1Ff8V0tEqy1eq29lndek/gkdQkcYLY7hTLcXdJwXVOPquLy+XVlQms9UAa8JtYkb9SyzvMjWYc Ue8p/sP4/62U14GlgjdJV9FnSt0xr/F1i4tDspV98MFAqHKLqJVmANNccZHybpipftbEgIiCHwpF 3WC4gA+JqiJxcia4gQvYT1+VdPTef+R+900Vkp+zjT3wruSgXLRb3d1SJkV7H+ko7zna5FzMLndb 8wSrMhKGRRPOdibQ9r5ZFJYefe7crzZpmPU1Q3qTKHYpizdGcGPwtElL49jnJr/d2zJB28Ujo9bW 8HCUp5k4SpQqBLlbytAkNxd3MDI6wvf30t4iwkp4N1/Z/2AbNCGredvwGHqGf6+WbxzhWiyOayOj Ywc0tflGu942wygGnN9ms8x8sxs7hKakT5vq5SNxn1QcyrqTriXu/OaxoQhHaxj3vSbFCrEqrG+x 4en3jrQNBoeWT58QZ4gQiPaRmDACz1citys6TKjgImRoIp0eM6a61i8C45qDYCL8YQ8ex+7A5YgO k0L8o75EXF8otrxhNk3i8l6DWpKOeYZx1GzY2TwWbXEtaX7I+PENeRda5YPE2gaIc1QortGeBTrS myeu7VRRP8IhEd7ki7eteN6/pbqZRvKFPFlc2rGotw+0zHnQV6i0rPamP253wwyDTn2307Xqrh0h 1BeaGbsbFos2KRNy3m5LbkhwUe+eoJtPKkcWYChmHDpMQLx9AYX3sMg0n3UwycTGcPjTzjbxzFDI Gg7HB6zIaJvrXbREf/erw5Q2m2mDfpuzxm35etq4p5fyUPJ6XnhxKMjd8o4vVqprXQ/kQs9aV0Qx Y3GZmGzjSUnWdXZZOym0ynX50NNhTteLJ6ZLZmcNb3n1ERVzLSf8/K087tgOhuRkZIcONwUHjcpB efklK5WA4lRlpDIrdYNh3E+xUJ6egGUCJBHt6M0DiTR4eyRXP+JpO9ryVq/t0l/cdAN0ZAve+Vtt syrpbVl125hkK4GYtC6BlX4TJwgR519R5QVgFh3YAtWCsXRRxUBI+BuieliWLjSMBxqBB9nxKltF kF+qNCmxrhS5n3Tr6TY4mU2uwEjxZjXuhlFEIzoKrx+147YYo/Vgm2kDGC4QBzJFo1Fr/brukM1f u9nLu1By63a7er75PhbVdTPaf5psui6Mcx0z1c9h9Zv14JUZJzLpMGA4kK6zUzgwFSm6T1Z+yLdb 13V5d2DLFFNQdNtlqZbYe8HddCB9JlEKDn9qGp4YavINzVQh4AcAe9/DZpL41sUCsJrDw30tIZqc G+5aF+uQhbvzQqxoPThPXoIaZPuVzo3raWKiiTptWtYvR7Spj0KX6INMvoJ4kYcZayLTFmMFlyIo 91F/zFcJDVdPyk5RUCLXYMCVq4jN+uQS9AtJmha9nEUS0acrzWILs4ZBb4qZ8cKlqZUr2HG+cMa8 +3F0myNSiHrG5CO+1ryvBFGEwvDo9gDzoBd430CgvIdjY1Yz754T8+1tpLM0BomeWBnO7vE8LMzX KfGQY1dJ3R7QHnzDUat81Bt22vUN+Acd0U/f4Pamo3WbZbrN6ybej9xpDVGvyJcYKB6uILq4VsUP eLq4f4sBIms2P+bTalzvenRb3JVmyMhb+wRrbGaWPqxykJSPwT00LUHedtqCIc8BLk7bgE3bDw1m Eu3Cf4ZSk3lbgu0j2cw0s3C9KbV8TlvCMyF32jq713etd8OWPArQ7OOKUla25qA66WsRmTR2KBxU a06ahMheIZZnyJHmoNhph2vTvNOEbwM8MW4yySppg6RM1GVjeILZmA31jebE+dN6J7Lpec2LS4Hm FX4JQJ43KpbJJVchlwrk7bcQKdhQDzBDroF2KrLAc0kbOQVIO+G2X97Xfk+LnkfjA9Fx3gImhrrl aZ1Atoiz/nBfU1ACkOpLzxGB4UF6JtY7/5lYaZLW1RZdxke2W1ZkCRIMj81PYIxgSsC3qMY6Ja70 bZ+fQHqGCzw4EqU5/sgo/aIr8fDI1ugIxUZEd46NjtDXY2kjH5z3Do6Ex3dZ8VGrN9KH00gf/+ar 1AzyuW8kjo6Hhyj8jrbqiPGmSLyWGgN1sqT3mnBnvMiMtCWognV/dzbOhCGFXKN4c5UwOe1hgI3c 3NVSwcuwOUT3JZLIdvekzE55y8G04JPzQFo9yRaiT/rpqB/eOpLdEfpC+Qc3aQEGq8F6emueY8lU srvD2urujuh9XlV/j9UEaAUmk/mLbCY+yjcZyG+7rddO0CeZDspb3A0GC0VRBVNTPj+L3rgd4z07 a5Zouu9OFcxyTe/Rir4Lb/0jZKdZZMw1dcPqKr6fttHW/ta8407T6QkGLwQ/YMg1c0hOC0fGBB/r 7GHWWK78a2veLKHmiGnzsQWZ/dWrs/zhRv7PcQQ27/PZp3kdaeMVg9lSkTmEzt8zexLysVP2DbgW AlRG2pHJ8W3xQFN5sEkuDxhN1LVEv2wjIxHPdczqDReESgb1JwF5008xgIMuhFat1DH7n6Q1ZqR2 07bXZgl332hkgrfW4QnPkIjCvpTNztLWslmUsgfMsKv+xIKWlZSlOpLLSz4A5EZRD5nplbzDvg5q vFYTT3d5D2lbZPOttcKlaRJzUC47QxWp2mT51LKq/O1risoyKwJFZ7Waqdwt0M57OvR+TiEdxk1f 3EiGzATUkTIJHfENJnCDN5t4gey7Q5HzoeHwSHhrlDra7KQw7uxpt7ayqTAChYppuXNjz8ZQaEN7 Uz81Bu3N6VjbxassJnLU205GxqIXueexrSTF6/UO0R5VVnORLk9keMft0MSIuRyny710sSUUGYqG xy1zRxuXFHfa4u5DOP+mfAwS7+csHIospY8ntoRkJTQtiCaXCWnM7MCZGAtNtbP5Vvk+fRQnxKTs yShXibxtAJyS7USuMesg3s4XuWwh5ZcBcp9yBa8jGdgUsgJb7fOuXCCE0Ea/+TyEERmhEehe8T4m 7wse9r6AZHYhcd2osm2+6ME5MuJKttZl8rvdbwT4WBnp3lbamabAW61La9eBb89iMWDc3bb9O1d6 25jGfDPOo2PQAuKj49614dG+wf7BqLmyPTw+GB7qjVq04QmpT2PjtK9W1YP3Wqt8mE0ZA8dtOw+2 DdEH3Oy0bhJ6w+j4YHxXhSx467RqB23iVn5cvPPStu12ukSDjrM3RFrh4B3hqh6D/WWXnrfz+W0w E3hFfdqjLV0Rvc1ihaO8HdwDREX74x3puKg5ly4VWirdio5cMVHeQmMTI5H4hOyFQf0YQ9GGovEq TdnWPJzKlOevGZH/WMMLWkzDmu3Ky49LmtmamJ8l01bvUFST2qa2cdpugMcNdVjBtOOO8GD1Brnk 0qq36Bga66x4fXNbzNtIWc+4QBpCUz7icfElR7w9NNZV8XprG0k9injgzSHy9PmKIxzj0XBftBIx 0xK4CseWtuDOVP4a9cE4qJQGx9Dg1oH4WHRk/uWx7oqPt7c1R2QtT1+22EK+t6mUy8hAtJVJnQ4Q zli1e/RtswqXL2yL8ELGoqGu8WgkOri9/NHtg33RKo0ZGaKdOpvHHfpimpOcT9CrScuhyRbt7dFH L4Tx5SHjh5VExp/o7qJHopEeO8K2egs/zt+583xazPLM5BbvfIby6QqFyNzq9knPPe6yTG9pPU1E 8ubsYnafTx4Sbm+RRvSJBZ4GSZun9ULK60xER2ilsPVTvJ8nd9FJYHfkUDjUG4qE+qpdnbcTsX/z 4VBgK9oFPzh/+95KG/dSYsvs2WuZvWer7xrr2143FNhKN/jqYHb0+GZ/QWT32grlaT/Cq0Mhdfz4 33LUK3UmMAaMA58CvgacukipQWAHcOcSpe5fqlTriUptAe5eqdRjwA+AQ8DOU5R6PjB7qlLvAd4H fAi46DSlrgUuOBu/gRXPVmoVsPVcpS4HfnqeUk8Ar1yt1K3AuucotRGYBKaA17co9TBwGKi7UKkz gG3AEHAtcCfweuCFrUpdD0TalRoAajvxPPAw8Agw3aVUAXgE+A3wgrVK5YG93UrdAfxynVKn9Sj1 UeDzwC0blXoNELkYZQVGL0Ea4DXAncDLLlPqJuBO4C7gTcCbgXcC7wc+AHwU+K36tfrFT9QvnpF/ 31ZfV7/4svoyuqxpXeP1l15Yc2Xj9fJL4ddpdddQb0a2nawmGmtmB1R9Big11qgT8Exkm0UPqQb8 pr91AxfW1Ee2dajt1P81QK2mgwjwXGAvsA+YA14J/DPwEeA+4H7gAeCjwMeAjwOfAB4EPgk85KOj 2kVCSxcBrcCTftr7ZdWTJ/wnP/lfc/LjhT32Q//J91WFo4bQBNTwCK87v8Y+v0bVrMCVZbiyDFeU fT66nO7efQf6EjjlTtDsb39bKb/jx1/cUV8P6qijMdkGtANrgA6gE+gC1gLdwDqgB1gPbAA2ApuA zcDFwFZgQMuL7Vpm/BAYb1AqDnwNuKKR+KHv+As4qc6+Aic/rXryqP/kkaon1R/TB9p62Q2fqb0K UE3y+yR9fjVdw/2TzG8fN0DKM6hf7gA+jnQPAj8+AbwGuB4y/7VLRPbft1Tk/13QCx8APhoSXaAN aAfWAB1AJ9AFrAUu07rCI8ATwC+AX/nLXP0kwAQXeOf3ePK939/Jt/0ngY4NPFb9jj5qmAROWK2W 9NeqQG9XoQaXWs6gfhmASHge8GLgDcD9wAPA8uVKpYD3A+8+Sal7gUmIkMXQ+RqBt6z0dMHvrxS9 76fQ90bOBP2cBboFvgV9rxm63qvOP1IbP76wkx/5TwKj4v9f2EkgTfUMqj/2zJ487ZfOO2hE+3uf ezrXeBVg6GNpkFucQf3yitWig8egc8eBCWA7sAPIAq8DHgQOAac2QxYAVwK3AvcCjwDnQEffBtwC /APwMeBE6OanAZdrnT134R9u1P6Jnfys6snTzjowKAJHkCe4fe6nkDNz2pa6AfgEUH8REgGnALuB W2FX3dgGWoBd9ct2sas+p22rb2r76kLYVPuBLwJf8tlZ7WuPNMwD5f6B/+S7VU++6T8JpHlmT75a 9c6X/ScPVz0JPBao6af9Jx9XFQ7uqy82XQWYHlyMqytxVamrAFWzUvq2Zn7fmucbXF6w7IY3LLoK WFQffH6m5ipAnUp9dNVasYkLwOPAz8k+hl1c0Pbxa4HHYSOfAtt4FfCAtpUfBp61HvoB8ADwKPA9 oGET0m6GHLhEbOerAfuSBfP/6o9V16R+jycBYytAjdXTfGdhjx1LCb7uP5G+3FB/FaBqFgV73KMQ n36wOEBf6gzqlzcD9Zeizy8T38bLtU/jHdqfQb6MzwBfAr4M/BD4MbB8i1KnA+cCFwHdwDpgBBgD rgFywI1b5vXjL6qeBOodGHiP+U8CitMCTwIZLPClgQy+5j+pXoXfY+XmHQ3LVeiBhtpvLP/gOUEO X9MQGOWm7xvLuII6nfr2Y8Bndf9S3/5I92/NFunLUWByi/Tnvi3SnzcDrwBuBd4AvBlYHoZkAWJA HNgN3AA8q1epZwMdwDpgCxAFxoA48AJgGigBLwJuBX4I/Aj4MXB3FDQIXNmv1POBkwagawCXAw5w xSD4C3DhNtAhcOuwUgeAfSNKzQHXAQeB1wC3Ay8aw1/gx8CTQO0VaBHg4RjaG3hoAsMM2LQdujFQ AvYBV++APgRc/1zoRMC3nweeBzS9QKklwNIXkH/r51DRngR+/qSSf4/qC096//77SfX5Bf+jntZ+ u3PEyyf+P+3rw3Wfu6+6H9DzFXr+QxW7UfffW4C7gbcC9wBfAr4MLAtLv66gfgSeDbQDW4ArgHHd 3xO6v28H7gE+AXwPeAz4PnB2r9BBdeYeGCoLlAHVB1H1UfiHUvkCxXlms67eBnIsYPxrTnHms/S4 3KLH4wv0OHw1cIsei/cDP9BjksZjXQR8H3gO0AtMAgkgCfx9H/R/4HXAYozZS4BLgbdE5zlPjoWB Bk5+/oyeBFwLz2zWC2TujyzsJJC1PmpOqdLfAQkxv++JSs6gfiH++oDmsUvAX4eAYeD8rUqtBH9t 17x2CEhqnvsO4ATw2iWa514D3A58APg5cPHlSv01sH8ItDV8JMdZ4E6AshfohquuxgcarnoJqmte CyzB/zzdk//2n1R/j+6/1YuvAkwv1ynx8uQaxcuTa/R8fjM1V5OW7+t1k6pW6OF06puwlpdGVho5 +RvIxt8Cn4JM/DRwRhw6HuTgOmA/sAuy8LnAqp1KtQAp4O+AdwFfAPbsgqyFnLwWMvJtz5tXl1/7 T6pXOUDugamOwMkz69g9lpMFeqCqn1TP+htV76iAv8f0bZOmiJmakzRH8KhA2301q6T/z6B+eTsQ vxJyG6iDDlMP/PZqpX4HvH4S+gFwOImnHSQCaoE6YCVwMjAJWDPQi4BbgX8E3gHcB/wX8AXg5tQf qV8CMuNY5uQCHOVYuu/3eDLvqDjO51sJru+H+5901hXA5NXoXuAaIAsUgX3AHPDXwPXAS4EaG3Id aASWAEuBlUAJNPJy4I3Am4F/A94O/AfwPmBLAroisAvIAI8khaaIjlYAQ0AMePuUUu8F3gfcP+XR z62gnzcBv9mtVCit1InA2cBjOfAI4IE87Bjgl8CTwK+B3wLv3KPUB4EPAfcBDwAPAg8BXwQO7FPq DuC1wOuBgTnYO8AVQAyYAJ4PXAVMAdPAtcDf/xV0GuBB4HFg137UCzjtJWhU4EzgPKAZuBC4CGgH 1gDrgQ3AJcDlwCgwBsSA3zzlf09qLPwfzf5riyJxs27XjwOPAQ0wH84BLgZ2AUXgVuBu4CHgMWAx +uB8oBewgRcBrwPeB3wF+CXwK+BJ4Ne7pc+ov5bpPvujDJX/PScB3Wb+YfhCvfD/s6g/XgDUZjCO gEUYS9/Lybh6Ath8Lfg/8DDQgPG0HpgGDgAf0eOtrQDbGLgJuBf4L+ALwFuKoJvikRTtYzkJqNOP Vn3sz+Yk4FYKOJ6PeFDvNYlPWPQ+9AFz9ZXkKjZ97Pca89OkE9DTpBPg6dOof24pwdYHL/wKsA88 8NXALcDWOeGHn9B87sN/gz4Hztiv1M79wvNm9wvfezvwquuRFlDgY3GgFm+tAy4Dijccm6l7LKZ7 gN6q3zkWo/OQ/6S6Yfe0jdsFnviORT5PcAU9gMb7yeUzhGfEdD81AdEblRoE3gW8B3gv8AHglJcr 9Wzg9JvR98C5wHrgHcA7gQ8DHwc+AXwSeAj4HPB54L+B1X8L+Qe88BVK3QDsf6VSLwZeAtwCfAZ4 FPjBq6FP3qJUJ7Ae6AdGgSuBGWAv8FLgLuCdwAeADwEfBr4AfB34FvBt4GfA48DPgcytSuWBVQeU ehbQAnQBm4E+YBvwPGDZQcg+IA48F/hX4D8OSnzUW4F3AO8E3gXcC7wH+CDwIeDDwEeA+4BVd6pj EeTmXzDu79APD/2Q/vvOocA0QPmxrGPbScrn8KuncxUSfyD9nmis8Tx/Wv5P0Lh8O9CLfo4ANwBv Be4Btr9MqR3ACvT9SuAsoA+YBV4HPAR8HfiVjzbOBp4FPBuwgHM0vawFum+eJ6kCtFxdoD3tYfKX JuEDlBC44z+aqsV+SEQA84IzqU8Kehz/EtiG8flpPSa/q8dl06swfgEbeBXwWeAsjNWdgAPcDHwQ +P6rZQx36rFL4/Zpd2Qgg+qOz+pzxk/75H8W9ljAhxM4+az/5JNVTwKH4duhsrn7ZTc0Lr4KkP59 wyKx8d+w6Grj+atZ0r+ooj/QXNVzP9T/p16p+epdmo9+28c3e8AzNwCXAJcBcSAFXAOcckD4KfHN /wTOuk2pG4H33yY8tHRwXqxv9ZOATA14db7jP/mW/yTQJ1+pevIl/0mgTwKPBTqoem99pOqdBZ4E MvAfTT4bfUXyGzpqV/8K2Ozkw1/s8+VuWXIVQFqff2ybHj+xIhfw0dYq6qdPARtfo9Q/AktuBz8A Pg8s/TvIBWAXkAKuAd4FvBs4DCjIuq3AAPB/gbfcIbKS5OO771hw/x/LScDGqR4WFjgJpFngScCD HLgToMBA7MeD/pMP+08+qMqPmuVKNS5Xp93wm8On31Cjzlx99Xnn16pG0eaEAlina5SRa67o+X30 4gkV5oGXn3gV4HEI6nviENrr49HWqndrXYb0lvuBB+6QWPDPAw8DXwC+CHwZ+CrwP8D3gMeAHwA/ Ag4BPwV+BjxO/Q7UvRbvBs4AzgTOAs4GznvtPJYeCP04Fuf78ZMjnfBRmcbY/qf+aAU2ABGgD4gC E0AKeBFwB/Ba4PXAvwBvBt4OvB/4APBB4FPA14DvAE8CK6EDn3ynrCkgffh4XxzbSWB4PJ2jnKPw /I8FbW2m5tn3fGaNdc83LjnnnsbF5wLn3bK//vxbli+64J6j5nv8+LM+TlanqhNACim1TNW5Vzco teUnh2vxd6lqUCMqq/JqVtkqjXu1wGkqsu009YKBmnobf2cHmuoLQBHoUTVbavBMD1I2qQHlIFUS uWfUtAKtIe2JeFvd+TUN59dsWa3s82vqkdf5eJ4YUrV0XZyu1k1Xo9PRnTpO11Ux3VpFhF+nOFFt gxKjd5Oq5zJuqpimG2mWQ0QiDSlOW1bXkd7kpV10hLTrOO0iSfuGRVtW15PcNWkvVQ2c9tKKaXs4 bYP33kX03iblBetsUIs5/YaK6ddzGy1226gBbWTe3KMaj9ArG7iVGqWVFvvfeLFq4nQXV0y3kd/Y 5L6xEW88QfFyw/MpzuhiFd7y08P/yKlXqT6knkL6EqioiNRj+J0Hpvn/nJrBtX5QWgZ3/UezuhRl +Cn+LkXLxvH2InJwuMzL9FoWoaFWZVFpa1qZaimvLJ51kL9SIUVKUqNiLamGaHi1atnyT+qkmtV4 egmXZhrPWqD2Emh9UqdTqkNtQ67n1nTguUYVw91J5OovxQpdCtPaF6sIUnTVUL2Xq16UIqnmkHMc z+/jug+ilkmcSV1PUCs9q0xtUeNI3VuzBalXHDW1jI0TMI5dG0FtUzHkMF6zbYE5rOUcTnHL4KeA VtWLvCa5TZsq5EX8YJUyNaf2WgW0AhPAXwOfU+KEHSZ183YxXeQ4jKOuXn4Hr9ZXvLqo4tWmildP qHh1ScWrS+u936ricaQ6jZnMGvlHYy3/z7y0kTMmawz/N/D/3huoLeolK/fNlAOlPxOIAM8F9gL7 gDnglcA/KzEk7wPuBx4APgp8TEk8+SeUmCBkeT4EfErJHEMtMj8VuAhoBdqAdmAN0AF0Al3AWqAb WAf0AOuBDcBGYBOwGbgY2AoMAIPAdmAH8ENgHBWIA18DrkAF7wA+jiZ4EPgxGuEnwPUwYV8L3Anc B83kfuAuWCsPAB8FWk9A+YB2YA3QAXQCXcBa4DJgC/AI8ATwC2BgiVLPA14MvAG4H3gAWL4Umizw fuDdMHnvBSZhGC9ehu4A3gLcDTwGfB94H0zpn56s1MipKOdpsCGBb6FDmp+l1KsspV5xLvoBiJ2H egITwHZgB5AFXgc8CBwCTj0fbQhcCdwK3As8ApxzAUYpcAvwD8DHgBNXQ64ClwNDQA64FrgB+ARQ /xyMUuAUYPdzZPXNjS1474WwTIG6NhAT8DDwTeAR4MJ2pfYDXwS+BDwC/AZoX6PUVcALgALwOPBz IN+Bc+AO4LXA4xDYp4DBrAIeAD4KPAw8CyzjPuAB4FHge0ADBFgBQmgEYmEUuBqwgTcD9ZuQ92al Xga8HHgT8A7g/cBHgc8AXwK+DPwQ+DGw/GKop8C5wEVAN7AOGAHGgGuAHHAj8AbgLcDdwFuBe4Av AV8Gll2CvIAVwLOAZwPtwBbgCmAciAETwG7gduAe4BPA94DHgO8DZ1+K9EAHsAUYA14AlIBXA7cA twL3Az8Afgj8GKi7DPUAngP0ApNAAkgCf78F/Q+8DlgcVuoS4FLgLcDdwAPAR4ElvaAJYBg4H4xh ZR/qAFwODAFJwAHeAZzQL1F8FwHXALcDHwB+Dly8FfwL2D+AOgwqFQYOAHPblLoOeM02ieL7zRDM EOBTo0p9GjhjDO0/jvYH9gO7YuBNwKq4Ui1ACvg74F3AF4A9YJQv2g763aHU24C3A/GdaFeg7nmg B4oGu1Kp3wGvvwr9Bxy+GkzKlgiTWqDOlsiSk4FJwEpiPAK3Av8IvAO4D/gv4AvAzRDGbwI+DjwG NExhnAEXA7uAInArcDfwEPAYsHga7Qn0AjbwIuB1wPuArwC/BH4FPAn8GvgNcOIMaAo4G3gBUHsN 2hZYBOX4exSRAjwBbJ5FvYCHgYYM+CgwDRwAPgL8EmjLYpwANwH3Av8FfAF4Sw7lBG65FjQMNeQr wD4I21fTbC2wtQR+B3wCwuFB4MPXIU/gjBcqtRPYBcwCGeDtwKsgtF5NgutF6Aegdj/aF7gMKO6X 2dveF0PmADcAbwXuAba/BPwFWPFS9AVwFtAHzAKvAx4Cvg78Cjj9RrwfOBt4FvBswALOAc4F1gLd QAF4J/BLYNtNoK+XY/wD3wUeBZpuBu0CNvAq4LPAWX+LegEOcDPwQeD7wA+Azlco1Q9cCewF7gI+ DHwbeBz4OdADwbkBuAS4DIgDKeAa4JRXgY6B5wH/qWc2bgTeD5xzC8Y38Clg462gO2DJAdQB+Dyw 9Da0G7ALSAHXAO8C3g0cBtRB9BUwAPxf4C00mwjcC9wH3A98FPg88DDwBeCLwJeBrwL/A3wPeAz4 AfAj4BDwU+BnwOPAk0Dda0CTwBnAmcBZwNnAeUArsAGIAH1AFJgAUsCLgDuA1wKvB/4FeDPwduD9 wAeADwKfAr4GfAd4ElgJ3eXU29kBrJZBTvCxn7DQKyvKrqjjV57WFahQquYIz5AeWH4FA1A1HeEZ 0hiPXzl+5fiVZ+5KrfXHfPvSsrfTlZqyK7VPOefjV45fOX5lIVeIA9Qc8ZkNNbVWPV8hX0C5XCbP QKUrDValKzWBKwvJ5w94pca0BtW0eqqVz9CV+TkvLmux8mcWcmXxn3o7H9sV7h2SBUfunaNdGcCP RUd4hjxJz9gVLjN5YKnMz2jOqtE62jM78aPhCM+Q/+vYrhwt589sNiWsCVwpf6bSleULeOZYrjRa ni5R+Zmj1Yu8fX/YK42afqo/c7Qyf7ks1Z/ilaPVgnyiv88r1M71R3zmaCUkj+yf65Xlf8S3U8sv OoZ8TjmmK0fP2UiZp5bqj3vFSJlnPufyK3VWpSs1ZVdqy67UlV2pD1wpf9exXln1J95ff9wrTWU9 2FTWg01lPdhU1oNNv8ce/HO8Us5Fj+VK7fFWPX7lz/ZKvVX+zMo/2JV6a+U8PvaHfPuf55U/fRo7 +Rl65ljp+c9NGzx+5fiV3/eVRdZRn6kxz1BMhXelpuxKbdmVurIr9WVXFpVdafBfqVKexWWpGo+c akFXQmWtEbLma9Qhaz4nCVnzNeqQdXTd78Sjt7x6Zvj8DH4sDlzZhx+N7hWKXwmmij+tK8ufoXz+ kDn/ZVw5evucYB0pH0L5lTu3VLqyPJiq7MoJypeKj4W865m6cucxpTr+9qd65S/1XX8CNV3uv6IW cCxRtI7KA8X8q3rZbZt2ZaOdWWjl5IgSL/hVwKR+hr7aQ19uoa930BccaBd/2smddvO+cYvstEs7 e9LujrTDH+3yRTs90W4/tOMH7fpAK/9p9TetAKZVoPSuUWR/BTAOxIC4kjUP24EdwC4laxKQpboS eD6AoqqrFYfuqgSQVLxRoJoCppXIMyozrQQdU3KQPkD1X6FoBZrUfeU5rwFOPvya/cuUOrSBn2s4 RC1T2yirIpYqWSFBCClaKfOsn1Czy9qJw2r//v20d8RytUzVHvpwLf1qPESKBoEWeSxTdYeurqW/ 9YeaOaOmQ6bf/EetOoHTUbFJ4aHnaQLzn5bKdV60Ao55nlpyiAq1n/O6Wa6r5Yfq3ZxO4t+ikoT0 9Zqy/Oor5FeL/Op9+dVUza+2LL9FFfKrQ36LfPnVVs2vriy/pgr51SO/Jl9+dVXzqy/L74QK+S1C fif48quvmt+isvyWVMivAfkt8eW3qGp+DWX5La2Q32Lkt9SXX0PV/BZzfhiBIG/Jjz6wp06kIbXk 0LPw8wM1RJsPcrLDNUSf9XVN+H1ZnXyVycv1ZXpBBC16WK4XKpBKSIsLaAERUdxvMIo+hGff+Gyl Po6RVeSU9fpOp76z0b2zSN8Z0HfG3DtN+s7V+s6Me+cEfec7+L30HH9uS/SdN+k7v20wd5b63kN3 vPfQ8WbgbcDLQYivBv4GT78Y+D4a7AlgG9rrCuAlK8G+gNMuUMoC3g/O8CDwuX6l/hs4eatSZwEX gHe1Ax8GPgl8EfgW8HXwnEeA08HXzga+Cf71XaAfPGwIuBb8qQSsmEU+wGRWqRRwDVAAts3JhpBf uF6pLwFjL5ONkf4FLPQe4BDwa+DJv0WPvUKpS4EokDyg1G7gH8Bi36zDvh/Q4d4UOr1YnfVHwmKM /cXcB9AoFTg/L9s6VCNLtmjl2vo6okWl/g39cXe9LNe6EfgF+oUItQtY2yRLtu4D7sBY+SfgdPD0 M4A4sEsvvTptqSy/SgMJ9Odu4BJw+D7gOuDfgB8APwPuRT+/d6UswboPeA64/xrgpcCrTpOlWC2n g6KAOPBdDKZfAXtAq9cD685Fuc+V5VkHAfrAaM35SvU8B8IC+C5QD8a/ugXjArhkDfoLeDZE53nA 1m7k2y1Llv5dL1sKbZKlSu8E7sXoex9wIkT0CuA8YDWwDthwmWyi/zbgrLBS54Rl2c7yXlmy8/2I LNnZ1ifLdO7tk+U4EeCVwAHg/2CovA145aBStwAPbMOIBoZBt7uAWyCX/w74AGTzR4G3QC7frZfZ XK+X2GwH7gbeulOW29BmzBdBbm8AHobM/m9gAgN8BzBgY4zZsrxmN7AK+sUFk7Ks5Z+B2DV4FujA uOiZlSUtOeCFGBcvAx4CHgbar8Uz18oSlVcB39qD+gLn7QWtAL/Saxh/hHF0GBi/Du8AvgccAppf iP4AQn+DMgCXvAj9opeqbAf27lfqVmAW4+864L0vRhu8WJaR3HujLCX5NfA1jMtlNyl1A/AyYPrl oD3gvSD0B4Bvv1qp3wF9UH2eC/wd8FbgB0DoVlwD/oo2PMK43XEgOGa/+Rqkf40Zu2uP408KwtPo Fx3/A6yqkeWuFwK/Ba6olWWphAf1ctT3QVZ9ErhjsSxH/fdGWY76VY3ng7dNAq/VfO7+JlmiSktS CWZJqlkG+sKtghcNCGiJ3a3AIMbmEJDbIWP1wxhD9wE/A54AYhnQOfBW4G3Ad4BHgTMxts4GeoFx YA/wV3rcfRoI3wD+AXz1paD9l8pSKLMcyiyJMsuizNIoszzqY6+QJVJmmRTBLE9650FZovQRTftf OSjLkcySpJP18p86aGl/ujBUUeu7uhjGAhkcp8Ckoe0sSjBVkspSW3FGWwXsxV9a3h7BvZReIH8m zjbB3BnmO30qCzOHtgiQuwXcGYBhE4F21wcDKqLakSM9c/wdx99xpHdcrt+xQw3CyKd8diC/K1VY 5fCPnktw6hRvikGloDObS0X38rheAKZwlXKhTVqSnL6EK1kY8Q6eyqo9irayoLcXkJrOLE5lldXB xhPJ4+30J9ROJ6qTemprZ+6566eHl83/t1zt67rx1BsO/O6fKt37/553xdnjv+3NVbp3xaoDZ194 8ISLKt1rivZc8IqH62cq3Tul4fMb33bDNx6qdO+N/c+99NELMv9W6d7XNv5z+PybbuivdO9vl+XG 3nPo8ZZK9xZFunamWybvqnTvQedHVz4Sv/1fK9077+z32o//zYVfqXTvr/rem3n8Pfe9vtK9Xz3/ P3Pbesbjle6RZlHv2zjEHA2nyZacJ91wx+9OeWCRqmlc3EDbc16N83WNNdlm9rS0i02+vzy94vRf bHLTf7GpgT7NR+lpSyRJWfviainvWnrSDUOHOeVdS5HyrqVX47wWb5WUquo79y1z37lvGVLuWybv rDtqaQdWuCkHViDlwApJWX/U0p52ilva005BytNOkdIuOmppHz3VfeejpyLlo6fKOxuOWtp3n+Gm fPcZSPnuMyTl4qOW9qaz3dLedDZS3nS2lLbRlLYCPdQdgR6OE0Mg5XFiUMeJQf2FEkNtWUIhhtUg huvknauJGFaDGK4jYqhTzXio5Tg5/AWSQyXF4ThvOM4b3EOIgbbp1u/8TG2DbNd9x8J5A+30rJO/ YVGD7Pi8MHKgbwfqIucaG+Qbggsjhy1L3HduWdJAe5EvlByWn+imXH5iA+1XvVBy+MZyt7TfWI6U 31i+UHK4Z6X7zntWIuU9KxdKDvtXuSn3r0LK/asWSg5jp7ulHTsdKcdOD5JDXVXesKHefeeG+gba s/cp8IbKjGUhxEBcRRfY5SoLIwbiKvqdLldZGDFU4ypHJwbiKrq0LldZGDEQV9HvdLnKwoihGlc5 OjEQV9GldbmKIQbxXT8dYqiQeIHEUHucGP60iIHCAU4tT6dWHoEYRrfVqLFtSl2Bv1fhL4ijRr2L JnbVqfvLs1pyBNIY3VaHbOoki6w6chaV1ZDRbfXIol6y+D9HKUVlYqEKUWUWVJHKVPOUKlJZQ3lK FalMR0+pIpUJ6ilVpLLyUqEi1flNVV3E4zfVJVdlTYQTG5ZTXQu6AuS0WxJfQeR0Bchpt9GCarUW dFwj+f1pJNXdnJVH+rpGpeniaBpqNZlwdKWERrcuszu6FyaHqpkdR6eHajLh6PRAQ1iX1h3CC6OH ambH0emBzA6d0jU7FkYPOy23tDstpNxpLdSztQAmcdxc+ctiDtX59hNNrmfrCWIOTzQ9Jc/Wcd7w 58gbnvaUWIX06giy5rhzy0v5p+bcOhEP0XSuPxFN4frPaerZf07Txv5zmir2n9M0tv+cpn395zTV 6z+nKXH/OU1Z+89pett/TtPB/nOaAvaf0/S7//zwMR8nqiMf8sQK1XPT/o+drprqzwSWAZV+r1Cb HrrxnUd/6vzTVn/26E+d8fmv/uzoT43vuyZx9Kd6bn7i00d/6oP1X7746E+NfOhf/30BpZ+574k6 /FoE1ACVfq9QlObJnrt+dNbw615dPa9Vd+657ehvrHYn+NTnZt7zpaM/taIpfv3Rnjq8pQ4jmYIU CfEl4XpaJnCH+Ivcv7VmJQutC9hCiwq2EFHRQF6sJlRG7Qayai/+p6uNAdKr0X9JuuvlNL7ftHZi 66pbashR1FC3qH5RbV39yzapwHFY/6UP9FBcS0HRp3QoGsZS43gvfT6KRto65APmtqimtmZxQ+0i XXh3+RQd++m/mJrjz/Bk+aNTa1fz25c01NfSUfXtYZXH++VDVZet4zSL65pqaxfV1ldNE8E7SpyO 4n9MqZXa3MAlVfOOspLu0B9EMh9GKuDauWD81zbedJo6RB/kmeHmrf/bRMPbLkr+a/+bEzcOqDfV KXX9Kei+60i9Jh5Yr+qWL/LxXVkLYi6cU6cqrlU6fizkaFy8v/4/1H+o66/v6qAuPJ2XqZ0OvPL2 o6X1H3cuVhUOT0I0dr3kCuon/+iqdBw+vEL/Ok1FmfYocm0rfjkcE0axZ6uBMKipwJFgKR1dVtDp nkr02VN59vjxv+r4Hbhg/QnlJh2xnW+89PU//dXozPJ/u7VRXfSct3+JFr3eUyOrNun+HUpI/w1K lv/dp4iJKfUZJSLjkJJlcr9RsuKTPpBFA+O0Gv4sMX9VivLqq+HVdurqGlkVmq6RtZ77amSd5w01 vHpOETtfRu+tES78Bvxdib931Ug5vo2X0/I6GtbRfCpjbc3/v/bOJKaJKIzjX0FIIMagB2IQsRoX olgNKkvUuEtQ0YNGzwWGWKVMbIsGxX3fF1wObrhrVFyi0cQL3CUaE27Gi/HA3YsHo///fDPS1FJb vWh8/+THG5hp35vhzZv+3/v4sKwWyz/RvyAatRtCwZgV5Z/ulrjtFxzDbf53r7XB5lar0V+DY7YE 2/yLmkNWC26R6I9jsT9xm+e00o6Eg81Sk8778BpVlovzWra7LtQQsaN2U8y/zo40+qsD06VlPt+/ 4tWnPeI8xEXai/v73/b4nO3SOaM/9Lrbr59FP77v8WW7bWLJxwlLPlLcDBdGRkZGRkZGRkZGRkZG Ro5S+f+svt6+S4FRBR0X4P/LvnTR/w/xDeRhWi/qx7lgQr+/S9TvHwLDwSnRGDbOE9DXd4r69rui /vexqGd+Kerzu0Xfm0lm4v085wxcQ+34Wk6SsuSkKcvj57XszM9z6hG3vmRlSYG2PeUcwdACbQAr 5wmtCcWaLfGstpGRkZGRkZGRkZGRkZHRPyfH54v6Z67d08fT8jrr9aLr9Fybp3+mN6dP51o8fT+9 PH0+1/Dp5zWxmnp6+v6Roj67SDTDczFgMCdt9RjgB2OFwVJMtSsyHjA4cyKYBDRqXGQymALKwFRh 5LDINNEk3ExvWw5mgJlgFqgAlaAKMPiTcV+zwRwwV3TeYJ7o+voCsFAYBCayGCwBS0GNaOLaWrAM LAcrQJ1oRu5VotmsU2XLZuBrsozZzOQdnzW7XgbPnB0SztF8+7YRJYPawoBhdLbovMsmEAEMC2Lw TivYDNyMm9IGtoJtoB1sBzvATtH5mt2AsQZ7wT6wHxwAB0XncQ6DI+AoOCaaMvYEOCk6v3ManAEd 4Cw4BxhRdUF03ofpZZkf/SK4BC6DK+Cq6HzQNdHzu4HyJrgFboM7ovNE99z991E+AA9BF3gkOn/0 xN3/1eW5+72HUWoxNNNGz/Gj5zP8K+L0mPRVKDk+7704huTm6Vxit+5eGn9sd+6b3YxZeSFu5KTw /l2De6AefduS39EwJ0h1QL9+hcgGMMGN+vbSwSWmZEtXRZLl45iZSf3UuHda5mDkYK0Mj+W1r0Xt TU6bwnFJ7QZXKernFefYnW791/nFjSXN+enMM2tPFerP9Poz9bdXv88Jvw1jLFuFXrAh1cuSagTq 5zOMz6xMrr9Xk9bKBIAxjOe2G26cvgpxBr86f6/fe2WyY/5EmV7/eLExZpz8f+XDbz87X/tQ4tjN z28JMYqL7YbWMCMa+ZmwbjV/hh85NzO3A97+QJV8rn66KXmfM/p79B1QSwECFAAUAAAACABMdoUs Iu87OBZlAAAAcgEACwAAAAAAAAAAACAAtoEAAAAASFBDU0RPQy5kb2NQSwUGAAAAAAEAAQA5AAAA P2UAAAAA ------=_NextPart_000_001B_01C1DCB7.CF263C80-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Apr 6 13:31:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tyax-0004ud-00 for ; Sun, 07 Apr 2002 00:23:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 00:23:39 +0200 (CEST) Received: (qmail 25215 invoked by uid 0); 6 Apr 2002 12:21:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 6 Apr 2002 12:21:08 -0000 Received: by moria.seul.org (Postfix) id 3AD50146844; Sat, 6 Apr 2002 07:21:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C11E14685B; Sat, 6 Apr 2002 07:21:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id D9BC4146844 for ; Sat, 6 Apr 2002 07:21:05 -0500 (EST) Received: from ifrance.com (vlt3-113.n.club-internet.fr [194.158.108.113]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 2191816E4; Sat, 6 Apr 2002 14:21:03 +0200 (CEST) Message-ID: <3CAEDC84.94408F85@ifrance.com> Date: Sat, 06 Apr 2002 13:31:16 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > nico wrote: > > Most instruction are defined as "optional". If a fcpu is release without > > such instruction it must give an interrupt handler to handel such > > instruction. > > > > Imagine that FMUL r1 r2 r3 are supported. So the instruction trap and ... > _________________________________| > > "not" supported, i guess... > Yep ! > > - "something" (a register?) point on the faulty instruction. > in the CMB (the instruction pointer). > After the instruction is "simulated", the IP must be incremented... > > > - The handler try to extract the register number to emulate the instruction > use the IP from the CMB, fetch the 4-byte data and extract the fields. > So the hardware extract such fields ? Other wise it will be a true overkill ! > > - by using some others registers ? > these are in the new "task". SRB is certainly triggered. > > > - We need to save some of them (slow?) > why "slow" ? > If there is a context switch ! > > - How to access indirectly the register set ? (to extract data) > fetch them from the CMB. > So you must manipulate the instruction world and then manipulate the CMB. But it will be really slow !! Is it usefull ? > > So ? > as you say :-) > > > I propose to define (later, much later) the subgroup of instructions. It > > will depend on space used and the impact on performance. > time to wait ;-) > > read you soon, > > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 6 19:02:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tyb5-0004ud-00 for ; Sun, 07 Apr 2002 00:23:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 00:23:47 +0200 (CEST) Received: (qmail 18498 invoked by uid 0); 6 Apr 2002 16:56:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 6 Apr 2002 16:56:43 -0000 Received: by moria.seul.org (Postfix) id 1D1781467F0; Sat, 6 Apr 2002 11:56:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0FA331468D3; Sat, 6 Apr 2002 11:56:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id C9EAF1467F0 for ; Sat, 6 Apr 2002 11:56:41 -0500 (EST) Received: from f-cpu.org (kdl16-179.n.club-internet.fr [213.44.18.179]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E5A3716CB for ; Sat, 6 Apr 2002 18:56:38 +0200 (CEST) Message-ID: <3CAF2A3B.230C77FE@f-cpu.org> Date: Sat, 06 Apr 2002 19:02:51 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > Yann Guidon a écrit : > > nico wrote: > > > - "something" (a register?) point on the faulty instruction. > > in the CMB (the instruction pointer). > > After the instruction is "simulated", the IP must be incremented... > > > > > - The handler try to extract the register number to emulate the instruction > > use the IP from the CMB, fetch the 4-byte data and extract the fields. > > So the hardware extract such fields ? ? the emulation must be done in SW, so a few shifts and masks do the job. I wonder why you imagined. > Other wise it will be a true overkill ! draw your own conclusion > > > - by using some others registers ? > > these are in the new "task". SRB is certainly triggered. > > > > > - We need to save some of them (slow?) > > why "slow" ? > > If there is a context switch ! remember, at a time when the 80287 was overpriced... people lived with that : SW emulation, libraries or coprocessor. and they survived. If you use a FPU-less core, then you usually take care to not use floats, and if it's FPU-intensive, then the handler is in the cache. and if it's really FPU intensive and your application is customized for you fpu-less core, then you compile the code with emulation code : it will remove the traps, perform the operations in integer world and the register allocation will be much better. you don't have anything for nothing. > > > - How to access indirectly the register set ? (to extract data) > > fetch them from the CMB. > > So you must manipulate the instruction world and then manipulate the > CMB. But it will be really slow !! Is it usefull ? FP itself is at maybe 10x faster than emulated instructions, and FP is pipelinable. so if you don't have a FPU, it's _necessarily_ slow. come on. You know that i refuse to design "naughty hacks" that will not be useful (or that will harm us) in future architectures. You can maybe find an idea but keep in mind that it must be compatible with all known architecture and execution schemes. Triggering the SRB to get the register set's image and instruction pointer is a simple and portable way to perform the task. If you want to speed it up too much, you will make the architecture and programming model too complex and not implementable. And don't forget your P&H books :-) (you know, "what is the definition of RISC"...) Do you have an idea ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Apr 6 19:07:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tyb9-0004ud-00 for ; Sun, 07 Apr 2002 00:23:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 00:23:51 +0200 (CEST) Received: (qmail 4133 invoked by uid 0); 6 Apr 2002 17:10:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 6 Apr 2002 17:10:42 -0000 Received: by moria.seul.org (Postfix) id 170B714685B; Sat, 6 Apr 2002 12:10:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 122891468E7; Sat, 6 Apr 2002 12:10:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 093F114685B for ; Sat, 6 Apr 2002 12:10:41 -0500 (EST) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ttho-0006EL-00 for f-cpu@seul.org; Sat, 6 Apr 2002 19:10:24 +0200 Date: Sat, 6 Apr 2002 19:07:16 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <3CAF2A3B.230C77FE@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 6 Apr 2002, Yann Guidon wrote: >nico wrote: >> Yann Guidon a =E9crit : >> > nico wrote: > >> > > - How to access indirectly the register set ? (to extract data) >> > fetch them from the CMB. >> >> So you must manipulate the instruction world and then manipulate the >> CMB. But it will be really slow !! Is it usefull ? > >FP itself is at maybe 10x faster than emulated instructions, and FP is >pipelinable. so if you don't have a FPU, it's _necessarily_ slow. >come on. Hi, I think 10 times is a much to low assumption. I would see it around 1:100. JG >You know that i refuse to design "naughty hacks" that will not be useful >(or that will harm us) in future architectures. You can maybe find an >idea but keep in mind that it must be compatible with all known >architecture and execution schemes. Triggering the SRB to get the >register set's image and instruction pointer is a simple and portable >way to perform the task. If you want to speed it up too much, you >will make the architecture and programming model too complex and >not implementable. And don't forget your P&H books :-) (you know, >"what is the definition of RISC"...) >Do you have an idea ? Run Imitated Softcode from Cache? :) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sat Apr 6 18:01:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tybL-0004ud-00 for ; Sun, 07 Apr 2002 00:24:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 00:24:03 +0200 (CEST) Received: (qmail 13148 invoked by uid 0); 6 Apr 2002 19:02:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Apr 2002 19:02:46 -0000 Received: by moria.seul.org (Postfix) id 661A31467F0; Sat, 6 Apr 2002 14:02:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 598A01468ED; Sat, 6 Apr 2002 14:02:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 31C091467F0 for ; Sat, 6 Apr 2002 14:02:43 -0500 (EST) Received: from art1.none.de ([62.27.156.125]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g36J2km30710 for ; Sat, 6 Apr 2002 21:02:46 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.156.125] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16tsdG-0001zw-00 for ; Sat, 06 Apr 2002 18:01:38 +0200 Date: Sat, 6 Apr 2002 18:01:18 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Speeding up slow/missed things... Re: [f-cpu] Supported Instructions In-Reply-To: <3CAF2A3B.230C77FE@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Sat, 6 Apr 2002, Yann Guidon wrote: > way to perform the task. If you want to speed it up too much, you > will make the architecture and programming model too complex and > not implementable. And don't forget your P&H books :-) (you know, > "what is the definition of RISC"...) In my mind there bubbles the idea of protected Cacheareas. If we have a special opcode to lock/unlock a range on the cache with emulation code... ...than it is possible that an OS use it for a fast software-emulation of FP or somewhat... Another advantage is that we transform the coding-hardware-process into coding-software. Coding software can do a wider range of developers as conding hardware like VHDL and so. Is this a possible way to do this? Any hints? Bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8rxvXClxplZklbgERAqtEAJ91Z0Wbamy3FRJ0EqDwtKHvUKXCpQCdEZGo W99T86VQiXe1zN5Yi29WHA0= =pvdz -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 6 21:02:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16tybU-0004ud-00 for ; Sun, 07 Apr 2002 00:24:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 00:24:12 +0200 (CEST) Received: (qmail 1985 invoked by uid 0); 6 Apr 2002 19:18:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 6 Apr 2002 19:18:14 -0000 Received: by moria.seul.org (Postfix) id 1DAE21468E7; Sat, 6 Apr 2002 14:18:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 05A5F1468F1; Sat, 6 Apr 2002 14:18:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 943371468E7 for ; Sat, 6 Apr 2002 14:18:12 -0500 (EST) Received: from ifurita (212.194.220.10) by mail.laposte.net (5.5.044) id 3C9FA0F0002204BE for f-cpu@seul.org; Sat, 6 Apr 2002 21:18:11 +0200 Message-ID: <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> From: "Christophe" To: References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> Subject: Re: [f-cpu] Supported Instructions Date: Sat, 6 Apr 2002 21:02:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Saturday, April 06, 2002 7:02 PM Subject: Re: [f-cpu] Supported Instructions > the emulation must be done in SW, so a few shifts and masks > do the job. I wonder why you imagined. Are you really sure ? you are too optimistic about such a thing. Well, let us try an example : mac r1,r2,r3 // r3 = r3 + r1*r2 So you think to get such fields is only a matter of a few shifts and masks ? now I get their fields, what am I supposed to do with them ? A code with a switch with direct registers access like it ? switch (reg3) case 0: switch (reg2) { case 0; switch (reg3) { case 0: { save r1; r1 = r0*r0; r0 += r1; restore r1; break; } } case 1: switch (reg3) { case 0: { save r2; r2 = r0*r1; r0 += r2; restore r2; break; } } ... // 64 registers !!!! } case 1: switch (reg1) { case 0; switch (reg3) { case 0: { save r2; r2 = r0*r0; r1 += r2; restore r2; break; } } case 1: switch (reg3) { case 0: { save r2; r2 = r0*r1; r1 += r2; restore r2; break; } } ... } ... Of course not ! Ok, you said registers are in fact saved in CMB, so we should get something like : cmb->r[reg3] += cmb->r[reg1] * cmb->r[reg2]; where cmb is the pointer of CMB of the task which triggers the invalid instruction trap and reg1, reg2 and reg3 the three fields for register for our "mac" instruction. But don't forget we must also read the opcode first to know what we must to do. Of course, if our opcode has few fixed bits it will help much more the job with a lookup table. > FP itself is at maybe 10x faster than emulated instructions, and FP is > pipelinable. Anyway, there's plenty of memory accesses and branching so don't think FPU will just be 10x faster than a FPU emulator !!! > so if you don't have a FPU, it's _necessarily_ slow. > come on. NECESSARILY, so we should aggree about the fact that FCPU brings us nothing new or wonderful for emulation of missing instructions (in fact I don't see the interest for an emulation, if you need some float operations, use a FCPU with a FPU embedded). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 6 16:10:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16u2T6-0007Xq-00 for ; Sun, 07 Apr 2002 04:31:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 04:31:48 +0200 (CEST) Received: (qmail 10306 invoked by uid 0); 6 Apr 2002 23:30:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 6 Apr 2002 23:30:47 -0000 Received: by moria.seul.org (Postfix) id C54D01468F1; Sat, 6 Apr 2002 18:30:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC9211468F8; Sat, 6 Apr 2002 18:30:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a132.home.uni-hannover.de [130.75.232.132]) by moria.seul.org (Postfix) with ESMTP id D84C71468F1 for ; Sat, 6 Apr 2002 18:30:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA08576; Sat, 6 Apr 2002 16:10:09 +0200 Message-ID: <20020406161008.64201@thrai.stud.uni-hannover.de> Date: Sat, 6 Apr 2002 16:10:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CAE1770.BEEBE54C@f-cpu.org>; from Yann Guidon on Fri, Apr 05, 2002 at 11:30:24PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 05, 2002 at 11:30:24PM +0200, Yann Guidon wrote: [...] > > - "something" (a register?) point on the faulty instruction. > in the CMB (the instruction pointer). > After the instruction is "simulated", the IP must be incremented... How do we find the address of the CMB? Remember that we're in another context now. > > - The handler try to extract the register number to emulate the instruction > use the IP from the CMB, fetch the 4-byte data and extract the fields. > > > - by using some others registers ? > these are in the new "task". SRB is certainly triggered. > > > - We need to save some of them (slow?) > why "slow" ? > > > - How to access indirectly the register set ? (to extract data) > fetch them from the CMB. That will become difficult if the SRB is still in progress. You don't know if that particular register value has already been written to the CMB... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 7 02:18:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16u2T7-0007Xq-00 for ; Sun, 07 Apr 2002 04:31:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 04:31:49 +0200 (CEST) Received: (qmail 4159 invoked by uid 0); 7 Apr 2002 00:11:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 7 Apr 2002 00:11:55 -0000 Received: by moria.seul.org (Postfix) id 8D5B11468F1; Sat, 6 Apr 2002 19:11:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 886371468F8; Sat, 6 Apr 2002 19:11:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 2F5001468F1 for ; Sat, 6 Apr 2002 19:11:53 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 832C31691 for ; Sun, 7 Apr 2002 02:11:50 +0200 (CEST) Message-ID: <3CAF903C.5B325678@f-cpu.org> Date: Sun, 07 Apr 2002 02:18:04 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Speeding up slow/missed things... Re: [f-cpu] Supported Instructions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Andreas Romeyke wrote: > Hello, > On Sat, 6 Apr 2002, Yann Guidon wrote: > > way to perform the task. If you want to speed it up too much, you > > will make the architecture and programming model too complex and > > not implementable. And don't forget your P&H books :-) (you know, > > "what is the definition of RISC"...) > > In my mind there bubbles the idea of protected Cacheareas. If we have a > special opcode to lock/unlock a range on the cache with emulation > code... ...than it is possible that an OS use it for a fast > software-emulation of FP or somewhat... and TLB misses. > Another advantage is that we transform the coding-hardware-process into > coding-software. Coding software can do a wider range of developers as > conding hardware like VHDL and so. > > Is this a possible way to do this? Any hints? Cache locking was an issue some time ago and is often used in real-time chips (ie TI DSPs). However, there is still the problem of allowing users to use it (protection issue which is not found in DSPs and embedded CPUs). But this is certainly a desirable issue, at least for the L2 cache (if it's used often, it will be cached in L1 too). There is an old entry about this in the F-CPU manual, but there is no agreement for the interface (some misunderstandings.) > Bye Art1 WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 7 02:18:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16u2T8-0007Xq-00 for ; Sun, 07 Apr 2002 04:31:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 04:31:50 +0200 (CEST) Received: (qmail 3944 invoked by uid 0); 7 Apr 2002 00:11:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 7 Apr 2002 00:11:58 -0000 Received: by moria.seul.org (Postfix) id D8E9C1468F8; Sat, 6 Apr 2002 19:11:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2EE21468FB; Sat, 6 Apr 2002 19:11:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 91BFA1468F8 for ; Sat, 6 Apr 2002 19:11:57 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 7C42C168F for ; Sun, 7 Apr 2002 02:11:55 +0200 (CEST) Message-ID: <3CAF9042.D4FDB3B9@f-cpu.org> Date: Sun, 07 Apr 2002 02:18:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > On Sat, 6 Apr 2002, Yann Guidon wrote: > >nico wrote: > >> Yann Guidon a écrit : > >> > nico wrote: > > > >> > > - How to access indirectly the register set ? (to extract data) > >> > fetch them from the CMB. > >> > >> So you must manipulate the instruction world and then manipulate the > >> CMB. But it will be really slow !! Is it usefull ? > > > >FP itself is at maybe 10x faster than emulated instructions, and FP is > >pipelinable. so if you don't have a FPU, it's _necessarily_ slow. > >come on. > > Hi, I think 10 times is a much to low assumption. I would > see it around 1:100. for the numbers : you're probably closer : - FP can be pipelined and interleaved, traps are serialising. - SRB has some overhead however, F-CPU's operations are quite useful : they are in 64 bits format, and alignment requires only a few cycles. 32-bit FP should be relatively easy. > >And don't forget your P&H books :-) (you know, > >"what is the definition of RISC"...) > >Do you have an idea ? > > Run Imitated Softcode from Cache? :) among other useful things :-) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 7 02:18:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16u2T8-0007Xq-01 for ; Sun, 07 Apr 2002 04:31:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 04:31:50 +0200 (CEST) Received: (qmail 15965 invoked by uid 0); 7 Apr 2002 00:12:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 7 Apr 2002 00:12:08 -0000 Received: by moria.seul.org (Postfix) id 1D14B1468FF; Sat, 6 Apr 2002 19:12:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1933E1468FB; Sat, 6 Apr 2002 19:12:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id D9F951468F6 for ; Sat, 6 Apr 2002 19:12:07 -0500 (EST) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 1067A168F for ; Sun, 7 Apr 2002 02:12:05 +0200 (CEST) Message-ID: <3CAF904C.25B11E58@f-cpu.org> Date: Sun, 07 Apr 2002 02:18:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Christophe wrote: > ----- Original Message ----- > From: Yann Guidon > To: > Sent: Saturday, April 06, 2002 7:02 PM > Subject: Re: [f-cpu] Supported Instructions > > > the emulation must be done in SW, so a few shifts and masks > > do the job. I wonder why you imagined. > > Are you really sure ? you are too optimistic about such a thing. > > Well, let us try an example : > > mac r1,r2,r3 // r3 = r3 + r1*r2 > > So you think to get such fields is only a matter of a few shifts and masks ? > now I get their fields, what am I supposed to do with them ? > > A code with a switch with direct registers access like it ? > > switch (reg3) > > case 0: > switch (reg2) { > case 0; > switch (reg3) { > case 0: { save r1; r1 = r0*r0; r0 += r1; restore r1; > break; } > } > case 1: > switch (reg3) { > case 0: { save r2; r2 = r0*r1; r0 += r2; restore r2; > break; } > } > ... // 64 registers !!!! > } > case 1: > switch (reg1) { > case 0; > switch (reg3) { > case 0: { save r2; r2 = r0*r0; r1 += r2; restore r2; > break; } > } > case 1: > switch (reg3) { > case 0: { save r2; r2 = r0*r1; r1 += r2; restore r2; > break; } > } > ... > } > ... > > Of course not ! i apreciate your good sense :-) > Ok, you said registers are in fact saved in CMB, so we should get something > like : > > cmb->r[reg3] += cmb->r[reg1] * cmb->r[reg2]; so you understand how it works : cool :-) > where cmb is the pointer of CMB of the task which triggers the invalid > instruction trap and reg1, reg2 and reg3 the three fields for register for our > "mac" instruction. the "shifts" i was speaking about were the ones used to extract reg3, reg2 and reg1 >from the instruction word. (mixed C/asm, sorry) inst = *trap_IP; reg1 = (inst >> 12) & 63; reg2 = (inst >> 6) & 63; reg3 = reg3 & 63; data1 = fp(0); data2 = fp(0); // clear the registers data3 = fp(0); if reg1!=0 load [reg1+CMB], data1; // i'm lazy to do the prefetch if reg2!=0 load [reg2+CMB], data2; // i'm lazy to do the prefetch if reg3!=0 load [reg3+CMB], data3; // i'm lazy to do the prefetch so now we have the data and we can start the emulation code. and we must not forget to increment the IP. there is a problem, however : if the code is faster than the SRB mechanism, we'll read the old value from the CMB. worst, we could interrupt the SRB to resume the task, but the result can reside in a register which has not been "touched" by our routine. The effect is that upon return, the result might not be updated. This means that if SRB is used, there must be a mean to control the SRB tags : on entry, the tags must synchronize the reg1/reg2/reg3 entries of the CMB, so we don't read the old value. This could be avoided in a "elegant" way (these values are known at decode stage, so we just have to "latch" them somewhere) but the "where" is a problem (there is not enough "bandwidth" for communicating with the SRs or the LSU). Updating the SRB tags to force the read of the result register is not as difficult. > But don't forget we must also read the opcode first to know what we must to do. > Of course, if our opcode has few fixed bits it will help much more the job with > a lookup table. good sense again :-) > > FP itself is at maybe 10x faster than emulated instructions, and FP is > > pipelinable. > > Anyway, there's plenty of memory accesses and branching so don't think FPU will > just be 10x faster than a FPU emulator !!! i was just being "conservative" ;-) > > so if you don't have a FPU, it's _necessarily_ slow. come on. > > NECESSARILY, so we should aggree about the fact that FCPU brings us nothing new > or wonderful for emulation of missing instructions this was not the intent. emulation is a mean to provide binary compatibility between different implementations, not a mean to increase speed. And have a look at other CPU families and look at how they handle traps. in the case of MIPS, it's "rather bare" and it works anyway. > (in fact I don't see the interest for an emulation, if you need some > float operations, use a FCPU with a FPU embedded). good sense rules forever :-) but this becomes more a problem during TLB misses. let me think about this for a while, when i'm installing a new LFS :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 7 10:17:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNV-0000GG-00 for ; Sun, 07 Apr 2002 22:35:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:09 +0200 (CEST) Received: (qmail 31084 invoked by uid 0); 7 Apr 2002 08:33:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 7 Apr 2002 08:33:56 -0000 Received: by moria.seul.org (Postfix) id 9CE8B1467F0; Sun, 7 Apr 2002 04:33:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 75FA51468E7; Sun, 7 Apr 2002 04:33:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 050F71467F0 for ; Sun, 7 Apr 2002 04:33:55 -0400 (EDT) Received: from ifurita (213.44.159.87) by mail.laposte.net (5.5.044) id 3CA06D470022BA2A for f-cpu@seul.org; Sun, 7 Apr 2002 10:33:54 +0200 Message-ID: <000d01c1de0c$b78f9a20$579f2cd5@ifurita> From: "Christophe" To: References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> <3CAF904C.25B11E58@f-cpu.org> Subject: Re: [f-cpu] Supported Instructions Date: Sun, 7 Apr 2002 10:17:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Sunday, April 07, 2002 2:18 AM Subject: Re: [f-cpu] Supported Instructions > there is a problem, however : if the code is faster than the SRB mechanism, > we'll read the old value from the CMB. worst, we could interrupt the SRB > to resume the task, but the result can reside in a register which has not > been "touched" by our routine. The effect is that upon return, the result > might not be updated. Sorry, but it is an issue for a programmer : he/she shouldn't try to resume the task before setting the result. Anyway I supposed that your registers were really saved in the CMB when computing them to get the result. > This means that if SRB is used, there must be a mean to control the > SRB tags : on entry, the tags must synchronize the reg1/reg2/reg3 > entries of the CMB, so we don't read the old value. > This could be avoided in a "elegant" way (these values are known > at decode stage, so we just have to "latch" them somewhere) > but the "where" is a problem (there is not enough "bandwidth" > for communicating with the SRs or the LSU). Well, instead of just having the IP, we can also get the values of the concerned registers. For example, if we have : "mac r16,r4,r5", three SRs would have the contents of r16, r4 and r5 while triggering the invalid instruction interruption. Or three fields in our CMB to get those contents. Those SRs could have names like SR_REG1, SR_REG2 and SR_REG3. (hopefully there is only register operands for other instructions than "load" or "store") ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 7 16:10:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNa-0000GG-00 for ; Sun, 07 Apr 2002 22:35:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:14 +0200 (CEST) Received: (qmail 14127 invoked by uid 0); 7 Apr 2002 14:10:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 7 Apr 2002 14:10:28 -0000 Received: by moria.seul.org (Postfix) id 9F0111467F0; Sun, 7 Apr 2002 10:10:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7BAFD1468E7; Sun, 7 Apr 2002 10:10:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 1D5431467F0 for ; Sun, 7 Apr 2002 10:10:26 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uDN0-0006g2-00 for f-cpu@seul.org; Sun, 7 Apr 2002 16:10:14 +0200 Date: Sun, 7 Apr 2002 16:10:14 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <000d01c1de0c$b78f9a20$579f2cd5@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 7 Apr 2002, Christophe wrote: > >----- Original Message ----- From: Yann Guidon >To: >Sent: Sunday, April 07, 2002 2:18 AM >Subject: Re: [f-cpu] Supported Instructions > > >> there is a problem, however : if the code is faster than the SRB mechanism, >> we'll read the old value from the CMB. worst, we could interrupt the SRB >> to resume the task, but the result can reside in a register which has not >> been "touched" by our routine. The effect is that upon return, the result >> might not be updated. > >Sorry, but it is an issue for a programmer : he/she shouldn't try to resume the >task before setting the result. >Anyway I supposed that your registers were really saved in the CMB when >computing them to get the result. > >> This means that if SRB is used, there must be a mean to control the >> SRB tags : on entry, the tags must synchronize the reg1/reg2/reg3 >> entries of the CMB, so we don't read the old value. >> This could be avoided in a "elegant" way (these values are known >> at decode stage, so we just have to "latch" them somewhere) >> but the "where" is a problem (there is not enough "bandwidth" >> for communicating with the SRs or the LSU). > >Well, instead of just having the IP, we can also get the values of the >concerned registers. > >For example, if we have : "mac r16,r4,r5", three SRs would have the contents of >r16, r4 and r5 while triggering the invalid instruction interruption. Or three >fields in our CMB to get those contents. > >Those SRs could have names like SR_REG1, SR_REG2 and SR_REG3. > >(hopefully there is only register operands for other instructions than "load" >or "store") Do you think this is a good idea? IMO then you need to know (i.e. implement) about parts of the opcode already. The best method would be to just treat it as 'unknown' and let the emulation take control. In that case you are also free to add opcodes later that have not been thought of today, e.g. additional application specific opcodes that may only be implemented in few members of the f-cpu family or offsprings. In leon for example I use some of the coprocessor opcodes for completely different things. It was not intended by the SPARC definition that way but helps me to get faster execution and debugging capabilities for my application. With f-cpu I would wish for such free opcode blocks just to be able to add e.g. special opcodes for grafical use when f-cpu is controlling a 3D grafic human interface in the future. Keep it free to be extendable even in ways that may not be very common today but may get very much wanted in the next 30 years (didn't YG intended that?). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 7 18:00:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNa-0000GG-01 for ; Sun, 07 Apr 2002 22:35:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:14 +0200 (CEST) Received: (qmail 4396 invoked by uid 0); 7 Apr 2002 16:03:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 7 Apr 2002 16:03:06 -0000 Received: by moria.seul.org (Postfix) id 0E1EA146844; Sun, 7 Apr 2002 12:03:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5CCF1468F6; Sun, 7 Apr 2002 12:03:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 1936C146844 for ; Sun, 7 Apr 2002 12:03:03 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-214.jetnet.ab.ca [207.34.60.214]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id KAA09045 for ; Sun, 7 Apr 2002 10:03:18 -0600 (MDT) Message-ID: <3CB06D39.C40CD655@jetnet.ab.ca> Date: Sun, 07 Apr 2002 10:00:57 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > With f-cpu I would wish for such free opcode blocks just > to be able to add e.g. special opcodes for grafical use > when f-cpu is controlling a 3D grafic human interface in > the future. Keep it free to be extendable even in ways > that may not be very common today but may get very much > wanted in the next 30 years (didn't YG intended that?). Other than getting into the wheel of computer graphics, is not 3D graphics better handled by a 3d video processor? Now bit fiddling for muli-media conversion may be a useful special logic unit for packing/unpacking operations. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Apr 7 17:35:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNb-0000GG-00 for ; Sun, 07 Apr 2002 22:35:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:15 +0200 (CEST) Received: (qmail 31173 invoked by uid 0); 7 Apr 2002 16:25:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 7 Apr 2002 16:25:09 -0000 Received: by moria.seul.org (Postfix) id 8D5FA1468FA; Sun, 7 Apr 2002 12:25:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 889561468FF; Sun, 7 Apr 2002 12:25:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 2AD091468FA for ; Sun, 7 Apr 2002 12:25:08 -0400 (EDT) Received: from ifrance.com (vlt9-62.n.club-internet.fr [195.36.223.62]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 4AAF616B8 for ; Sun, 7 Apr 2002 18:25:06 +0200 (CEST) Message-ID: <3CB0673C.A8980D0D@ifrance.com> Date: Sun, 07 Apr 2002 17:35:24 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Speeding up slow/missed things... Re: [f-cpu] Supported Instructions References: <3CAF903C.5B325678@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > Andreas Romeyke wrote: > > > Cache locking was an issue some time ago and is often used in real-time > chips (ie TI DSPs). However, there is still the problem of allowing > users to use it (protection issue which is not found in DSPs and > embedded CPUs). But this is certainly a desirable issue, at least for > the L2 cache (if it's used often, it will be cached in L1 too). > I don't like such loking in any way. Prefetch instruction are those kind of cache manipulation instruction. PII introduice 3 type of locking (L1,L2 only, L1 + L2). But PIV use the 3 instruction as the same (L2 only load). Those kind of manipulation are realy close to the cpu architecture so compatibility for future cpu will became a nightmare. The calculation of the good prefectching distance are realy hard : too soon and your data are trashing by following load, too late and when the needed data are requested the data aren't ready. In both case, you lose time by consuming data bandwith. Locking cache could slow down things. Imagine how a one way cache could slow done the data fetch, if a large page are locked. I prefere preload data, immediately usefull. nicO > > Bye Art1 > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 7 18:18:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNb-0000GG-01 for ; Sun, 07 Apr 2002 22:35:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:15 +0200 (CEST) Received: (qmail 28019 invoked by uid 0); 7 Apr 2002 16:34:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 7 Apr 2002 16:34:58 -0000 Received: by moria.seul.org (Postfix) id 48E091468FA; Sun, 7 Apr 2002 12:34:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29BDA1468FF; Sun, 7 Apr 2002 12:34:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id CB98A1468FA for ; Sun, 7 Apr 2002 12:34:56 -0400 (EDT) Received: from ifurita (212.194.218.46) by mail.laposte.net (5.5.044) id 3CA06FFD0022E93B for f-cpu@seul.org; Sun, 7 Apr 2002 18:34:56 +0200 Message-ID: <001501c1de4f$e9d1ada0$2edac2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Supported Instructions Date: Sun, 7 Apr 2002 18:18:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >Well, instead of just having the IP, we can also get the values of the > >concerned registers. > > > >For example, if we have : "mac r16,r4,r5", three SRs would have the contents of > >r16, r4 and r5 while triggering the invalid instruction interruption. Or three > >fields in our CMB to get those contents. > > > >Those SRs could have names like SR_REG1, SR_REG2 and SR_REG3. > > > >(hopefully there is only register operands for other instructions than "load" > >or "store") > > Do you think this is a good idea? IMO then you need to know > (i.e. implement) about parts of the opcode already. The > best method would be to just treat it as 'unknown' and > let the emulation take control. In that case you are also > free to add opcodes later that have not been thought of > today, e.g. additional application specific opcodes that > may only be implemented in few members of the f-cpu family > or offsprings. In fact, whatever is the opcode, F-CPU just extracts the three fields and give us their contents. The opcode could never use one or two of those registers (one or two operands instructions) so it doesn't make a difference. It is the software to do whatever it wants with this info. So F-CPU really lets the emulation take control, because it is only the emulation code which knows what to do with. Such a feature could be disabled or better thought. > > > In leon for example I use some of the coprocessor opcodes > for completely different things. It was not intended by > the SPARC definition that way but helps me to get faster > execution and debugging capabilities for my application. > We are okay > With f-cpu I would wish for such free opcode blocks just > to be able to add e.g. special opcodes for grafical use > when f-cpu is controlling a 3D grafic human interface in > the future. Keep it free to be extendable even in ways > that may not be very common today but may get very much > wanted in the next 30 years (didn't YG intended that?). Do such free opcode blocks trigger an exception anyhow ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Apr 7 23:57:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNc-0000GG-00 for ; Sun, 07 Apr 2002 22:35:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:16 +0200 (CEST) Received: (qmail 29430 invoked by uid 0); 7 Apr 2002 17:00:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Apr 2002 17:00:11 -0000 Received: by moria.seul.org (Postfix) id 78BAF1468E7; Sun, 7 Apr 2002 13:00:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FFEC1468FF; Sun, 7 Apr 2002 13:00:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 7FE891468E7 for ; Sun, 7 Apr 2002 13:00:09 -0400 (EDT) Received: from there (nas-cbv-7-62-147-155-156.dial.proxad.net [62.147.155.156]) by postfix2-1.free.fr (Postfix) with SMTP id 6B13CAB for ; Sun, 7 Apr 2002 18:59:56 +0200 (CEST) From: cedric To: f-cpu@seul.org Subject: [f-cpu] RC5, F-CPU and srotl Date: Sun, 7 Apr 2002 23:57:35 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_ZZW7JAG32IESSE9WSPXL" Message-Id: <20020407165956.6B13CAB@postfix2-1.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------Boundary-00=_ZZW7JAG32IESSE9WSPXL Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Hi, Last week, Michael Riepe explain me how the rot and shift simd instruction currently work in the FC0. He answers that it wasn't really a simd shift and rotation operation. So I ask some friend to find algorithm that need rotation and that can be easily port on a simd processor. The answer whas the rc5 algorithm from the distributed.net project (If you don't know this project look at www.distributed.net) . I started to port it on the FC-0 (The file that is attached to this post contain the C ansi version of this algorithm). I selected the rc5ansi_4-rg.cpp version who work on 4 keys in a single pass and approximatively need 62 registers. My code is currently not finished, but I have some little think to say. First I did'nt see the need of the currently srotl.* instruction. If you prefer, in this code, we need a srotl instruction, but I must use this version : %macro simdrotl 3 shiftri 32, %1, %3 rotl.q %2, %1, %1 shiftri 32, %2, %2 rotl.q %2, %3, %3 shiftri 32, %3, %3 or %3, %1, %1 %endmacro The other rotation operation need only immediate. And as you can see, for the srotl, I will need more register if I want to compute 16 bits data, or if the size of the register became bigger. (And I currently didn't find an algorithm that use srotl as we design it). An other thing about the srotl, it currently double the asm code. It mean that, if we have a real srotl operation, we will have the same or better performance than the K7 core (who is actually the best for this algorithm). So my question is what is the cost of having a real srotl instruction ? The second point, is about the storem and loadm operation, for this algorithm that saturate all the register bank, we need before the start of the loop to save all the registers. The problem is that the storem and loadm need actually a register that contain the number of registers to save... That stupid, to save all the register we need to do : storei 8, R1, R63 loadconsx.0 62, R1 storem R1, R2, R63 The solution is easy : storem 63, R1, R3 ... And now, I have a question about a not really clear feature, the size register. I didn't really understand what they say. Did they say how many chunk divide the register ? Did they say how big the chunk are (but in that case how many are they ?) ? Or some thing else. Why this question, only because the rc5 algorithm is really the typical algorithm that can use big simd register (If you have 128bits registers, you can compute 8 keys in the same pass...). But if we work in 128 bits the srotl operation will be abolutly needed ! A good news for the end, 63 registers is enough (I only need one more ;-), I think that I will find it). And our RC5 algorithm only use register and never do any operation in memory... that really great, no other core can compute in the same time 4 keys directly in registers. A+ Cedric PS1: I hope that I will finish the rc5_f-cpu core for next week. I think that coding real algorithm on F-CPU is a good start to see what we does wrong or good. I think that I must design an other version for a F-CPU that will have 128 bits or 256 bits registers. PS2: Actually the main loop need 1200 instructions with a real srotl instruction, and without it need 2300 instructions... --------------Boundary-00=_ZZW7JAG32IESSE9WSPXL Content-Type: application/x-gzip; name="rc5-ansi.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rc5-ansi.tar.gz" H4sIAFFYsDwAA+xde3PbOJLPv9anwGQyY8uWbQHUw4/11coZz6xrs45jJ7d1NZtT0RJt8SKLKlKy x5vKB95vcd0NPkCAIOVHXrtSJbJNdgPdje4GwB8ADsa+N5lth4P2tjuJ/O1nn+HTbLaa3XYbfjab 3U4n9zP+PGt2W+1WE/51+bMmFx3uPGPtzyGM/plHMzdk7Nnl5mA6L6Gruv+dfgZa+8Mv+LPPN8Or rcF0+hR1NHmz2Wm1LO3PO9jY2P6C82a7ie3fbjfFM9Z8isqrPv/h7b+9XmPr7GUwvQv9q9GMDf1o FvoX85k33Jp4M8Z3d7tsk/XGY3aGBBE78yIvvPGGyPdrELJ55DF/YjBOw+D/vAHQB5Px3RYS9yZ3 LJiNvDCj9YMJi4sILtls5EcsCubhwGM3fjB2Z17EBoloWAYWs/m4DxYxnLvjzQ/eXYNd+394QxYG 88mQOcyFb28yCO+mKFmD9fh2T5B0lyDl2I1m7MYdz70GFjIJJptuGLp3UMA53z4XbOZejL2owcL5 ZHPmX3vsypt4oSu1vGTnzd/fxzp4f8y8cMKev3zOIkcwCLr+fOLP+pfzyaAv468fXq2xs5ftd3D9 70H4ga3fwjfVXPiZQznrWGs09gdeg90E/pCtRwOofzDqu6HnMlbf19m3t0NvNg8n0KxH5+9eve3/ +vrdyS+N+I+/vz776/HJb9hEm7zxFMZf367VfvQv2doPQ+/Sn3jDtbE/mdXZzz+z5EK/H42CW38Y 9fv1em0QTMDqgxHE6Hqam8A2fchNbA2VrLOPNakEe/7ntR/rL46He0xPY40bxrf4ltjiTEDO2W7y 7WaHcb7Xau2JFpu64I+DD+zojyl78Xyffar96E2G/iUIK8Vip8enR6+OT476L8FAb9kB4+mtd+dH /d7J+XH/+OTl2dHfjk7eoo6TwXg+9NhziAPwiuut0XPlYhjMwLnxWm17m53Z/YXtAQH8W9lk48Ad +pMr5oIjhlceI8u4kxkEGDs7Pn/JJh544uw2gGiE8JoPsJxoC5kZW/PBJYAwmrrhgO3V8epK5EHE sZ9G/hpvwafTbjmdeuOnK0F3odHh18ZP46DgthQpkRekImHdGfo+I11IGox9+PJUkaRAEdjCQ67J ezAm/tzk79kGe6PIu8cG8zCE7um8yTYO2BtWT2sehu7thQsttsduvUzz6yD0WOhdQX7xwkgWhdVj +K6mha1SoKfX36zKYtnbkceuXchllAEwK8ywfbH0SGkI0cmqoBLOm82trXPRTikcjaDHG6/GAXyN fJ4VoxENQEuU603xba/HZX465KTXJJh5kDHB5JBS7xjEzHwMSt144didslt/NsqXGFsciNmlH0aQ mCEnyAaCBDfEFC7ToCwe+ZAWk56V1EmV4XnTk8Rnr9++YmuoOLRrD79Q/0b2a72h+oILGWAA7QOO fT31x1BIrNMwIOOvrMyup/ygxzdiM66sYNkbB3g5/fMAa6VKG3i9HrsTdS1uFM3BM8FhRu4NVijD UHXO2MPYeZD6lehsOBtig4ObOjznXEj4esL+dnx63mB/Od087ZHZToNbLzx92WA+6oIaXGBlV+hZ s4BRf5K4DNXtuUOM99UeX0WLxPaA+m996HZJCKepuEPcNlDMYORPI6mNozgMBj1bGwaT1Rn7MAlu GWTcW2wddwxtKGVCKXKlgnQuww5I9n1SiGM2cLGUK2+GZcou+s8//QAhEkTR5tVggCrFLcZ+qGdW OadMA7Wi70BLhjPUMSci5b5/Xfvst/ldcA3kIxhp7Ha3m91tvlvLcm//tA8d4Qpr/nHYPeJt3nGy W2/w8u6R0+3uHu6ml8/7EB5rkzpbk7wb/Tfr0LYy20ovh0hHHfCK1kclhZxhV8iP/vvoZO2cn9RX Vlb+URvEqWh/hf6E6+AWPfQN9DuHraXODT+AuL4PVBQCBwvEw36mc1z7619+uXflsoK0cpQlrVwK ltI1sl+x8tQ6YkHriLx1ys2BZI8zh8iZo1z/tLaH6O8sqL+j6g+VlauOFF4vkwZ//19M6A38qpNg +ysPtJCURzFQoTiqbUicw2Jxejlx7mFCHNxlI7nBdDyP8H+99pghb8VngaEviJaM6LBNk9plhr3C 6Qp0DpBn3QkKgJWjEEluG3szD9ko+8G/W5jEQGIDVuwi3cFsTokVpWXBAMYZMAnI094FcxbArOLa /6dH2Rmru74Apqt5OI9w1gHzHvcKJk/khXJQvseakBEhlY1wiHWJrtmAzLUpf8Xx3NSfemNsfk49 B4PITe6mt0QD/HmTbW1tMW82wJ9ZJ0NSDrDr9uUww8UbV5DLU3bs97Evi0emETs4YDB3imbBYOTB COyHWu2eDao3WGUD65+iBq59rElPOOf9ZrOB35y+BX079N2i7zZ9d+i7S9879L2bSAJ/cCqCUxGc iuBUBKciOBXBqQhORXAqgqtFCCpCUBGCihBUhKAiRBuihWUjJhQdxolxTGGU0X28/AGNDwHY3E8u eHfgLjBUOlDMSOS3I+yH11KKzU1WZ+i5CRXzrybQ3BF57mR+fQElQ7+ctHZE4n+sSS3iPARNiy2L bbf5X6+aW+NgP74vE4N+f+TTfUnzMa8idEsN6MGy+zAHXWeHQJKOP1EekB8myVN0I/BymDXm6WF0 4Q18dwyjExjGSKXl4OuQxhs46KHBFoy8/umFwRaLy8APdqMH8aBiP7n4Bv7DxTfpBXKjXP+yRl1q cl/J0VmKxmRYzymXduMwCCWfzErIxhfyltBvZVyOnatl52rbuTp2rq6da8fOtWvl4k0rF7dbg9ut we3W4HZrcLs1uN0a3G4NbrcGt1tD2K0h7NYQdmsIuzWE3RoitcanzFu1QBTlgZgNAKUHpIqlQzXd 5XUOYeNwbBwtG0fbxtGxcXRtHDs2jl0LB7dpzm2ac5vm3KY5t2nObZpzm+bcpjm3ac5tmgub5sKm ubBpLmyaC5vmiQtbuhHH9N61/PNdSVjPObXWW3k9OTbPVSSH8LlObzqGyT30i9AJrCkdhuxDlLF7 vaL/KBziJ9UeWqod+QXV5sboarXZWL5iKM+0Tsyx91SOvady7D2VY++pHHtP5dh7KsfeUzn2nsqx 91SOvady7D2VY++pHHtP5dh7KsfeUzn2nsqx91SOvady7D2VY++pHHtP5RghvpIPJHJFcyqsObRo FcRRWhIiCrnIGNxNYd6FEQmzFSz855+JAYmLCCGGDhJRDkmUXjoNThmZIk47EacygOt1VltZuYBJ yge1y0XshT2/dnGytQlzsdC79iaz5zQux7QVj80v7kpH6kwW0E8LUM2QtIScP2wcaCAG3kVR0HjJ HEOdUMDM4SNm1ZkH+XBI091sEM1iyCVGik5ev/3L8clvVCTzxggJZqX+SSs0LUO5fCBp96Vl1lmE zzRHwS0qeEePEZNZ9hDnfjY5CL5KFEPZ5fwWQZf4YeoNGpWehcL0dUhzBiC5DqIZlA0zhghmudGl tHr6JJrqy803D3J/7mNd8wk9HXfDqy0WjdzhcD7VSohl3eRE74VhQDfkEKz2VfBfC/4vNi/EU8H/ Mf7ftOH/Dm8Z+L8QnSX+/yU+kIQeBP4D3+LgPxA/GvyXcMGLV8FViu4mTtq4YS/kU7MbnwZ6fKvD UPgdhBKaO0yIvfbuXquDEXjtI+mrAIW7ZC+Ohy9YNJtfXqaARFZIOymks81brLmzJ7p7Ypexy9D3 hheuT5DI6vFwlc3cq4hBxEtwLAiHoCfmkvl0isDHqj+EIFvFbHBN4E2AVoDR2x1z2QXmpeASy7oG pUN8rEH28ODWxA1xBOsN5rS4wJSxpcvInb1WV5cRrLaKvQr0CsNEUBACwc4ZwlLufBZA5f4AkfbJ FWReaKQgvJP14TPTdcbeYgtd4qMWfLIpoewhVBRcY4NgQ0D7YaoeuBNq1T50S9hV9fvy+cujkX/R vxCLAf+Ka6AzFPkCukIR4L8wci/V0RYG/HDARB0Ko9z+HIqHMMCHt+njVPngDhpYPFfqvJyAEVj/ 5em7viMOj9/20yKww7qTD4Alfgntxxxx4c8YUG9tbWXFZIsVqGcsgMvexDdSwMxEzOhzuvFmfVIr QsJO6uwf1PfS8Oyc/37yPhumURkn9dxIbT/up2MugVzCxiUkl9C4Fp4r6VxC4RJqBQ21rkLU7V6K 0ozp3oqCTLrIi87OdC6hcAm1goZaV60IvStVlP4qas4SNUXMYzTmg1rzkW0pKtsyp6Jq3EVVVJvx Qe34uFZ0klbMtWkRMAg0OaNkNEcnL8/+5/Tt2kkDpj0wCeuJxqHIGY3EokkaztHkFI1Mt69ZShIK JASxsZQNab19o7pEcEv1OnmigkKOtMAhgAPR/SW0t1WrwXgWO/Ks863NdXhOA+XUGXEMpMWFSDzt d9F538BGhJ84t5ITuFLkyiQQjdiT0bf3a2pUV8BMcWCsWdEmdLHmHzjLwE9c9kKoUkL5cDwJrNN8 n4eJZJ5vJg/dKoAitKssQZSUYCY/TAn1WNfs4f4arytXKMBEXadxDJqWQdM2aDoGTdeg2TFodg0a 3jSIuCk1N8XmptzcFJybknNTdG7Kzk3huSm9MKUXBTY3pRem9MKUXoD0Re5rxWLUrK+KJgxvEIY3 CMMbhOENwvAGYXiDMLxBGN4gDG8QpjcI0xuE6Q3C9AZheoMwvUGY3iBMbxCmNwjTG4TpDcL0BmF6 gzC9QZjeIEq9oQDbSJKZMiRQZXMMd3AMd3AMd3AMd3AMd3AMd3AMd3AMd3AMd3BMd3BMd3BMd3BM d3BMd3BMd3BMd3BMd3BMd3BMd3BMd3BMd3BMd3BMd3BSdyjsnhpMLuyUi57lKGY+89hhA5+mDIM5 TFpxDOJfUY/Vy/VVop0b+eKfGzrqQz19OzfajenUMah8xPox7544ZlIAtrheY6RwaBshHCYjg1KI jfrc/WzIaaUTKV0pdgbl8YTOUp6kE0RHhOoQNm7PbJiaRpFK1TKp2iZVx6TqmlQ7JtWuSZUEk0qW RFOOrkABXqABL1CBF+jAC5TgBVrwAjV4gR6iQA9RoIco0EMU6EGhlTguTAtW/ctVHM+PvSjClOpB Sr2hxfWTZJE4LYmGceFgxG49YoVhM80wXFqM5l9mK+thwhHO2KXrj6OtmDROzuUwVYpSxZ8KnIpg qngkKZ0YorSeYAxxhFXUKO5XI87q4pGnDAe1RpHENP3VlCDMp9pXwjWWn8U+FvwH9009GQBUgf+0 O6Kt4z8t4Szxny/x2d5+gt2QUIh9N+TQD73BLIF5FLZ0nyTyF2yVrH3P2FQaQIuCU62nAKd2vgNw qv2NglNU2vq7yEv3vUk/ZbhSQO5pVDZr9eKNfOslm32Xmze/3OZNKBaEJPeQj1T30GJyax7uUos8 7zpCt1pNntWuknvjg2Coej4YxZsR4cowDKZRtnuyQT+wBdNmwz14d7cQIfjkde0qDMNYu/XlHtJv fg8pPa3NbyJFD4U72d/q5qsG3irYSBotd5J+JztJH7vuADcyLbjwQO33i1cetD7fygO+2MoD/vlW HnwTW3Ub53waejd1657ZeEukJFtsvy4yJskn+92+Y/f+MlRv243rpZSU/f64jbuqnKXGKdu9u6hx RIFxSq1Rtol3AWsst/E+dBvvEkh/IiD9O9+Rqu1GLUXqS3aD1qz7QIvgrc+F1ZsbP/O7PpMtn/pu zwIEXzYpS/a9aTBuvO+toW6Ly7qoeA9NQ90bp/NK5xAWXuk0joVXOlPLwiudrG3hlc7XsfBKp+xa eHcb6s4bjVd6b7r5RuONvdpiq9jbLbaKo8Biqzg6LLaKo8ZiqziaLLaKo8xiqzj6LLbiuw11X47G K8OUW2wVh6/FVnFYW2wVh7vFVnEasNhKtBvZdrxP6PILrVGoqSB3vFO0kW3fy9BuM2h0PjVkdD41 YHQ+NVx0PjVYdD41VHQ+NVB0PjVMdD41SDS+XIhofLkA0fnU8ND51ODQ+dTQ0PnUwND51LDQ+dSg 0PnUkND51IDQ+HLhoPHlgkHnU0NB51MDQedTw0Dny4KgqOe616ZTs1OM95zFW06pgvtvNj2Pd6ep +03vt9n0CXaaLr7NVFv3kN9gmi2RyO8u1elbFvq2hb5joe9a6Hcs9LvF9PmOrGAXqU5v0Zdb9OUW fblFX27Rl1v05RZ9uUVfYdFXWPQVFn0p5lYUv3/o3tCVBcDveFfow7aEPm4/aIbRryiA+crXQMzL zv99KgC44vzfblsI4/zfTmuJ/36Jz/L83wch3lCI/yjIGwp45OnAYnk88JMcDyzKzwfu7PHdr3s+ 8BKWXsLSS1h6CUsvYel/N1h6CZouQdMlaPpvA5o+8uxjy4C+4rM8/PjbPfy4sEWXpx+fL4Q1f82T j6t3pNvPPZbl2E49jg204JnHGfVjTjwuOvBYP+/43IJ9L4J+p3KWI+BVGHgVCl6Fg1ch4VVYeBUa XoWHVyHiVZh4FSpehYtXIeNV2HgVOl6Fj1ch5FUYeRVKXoWTVyHlVVh5FVpehZeXI+Zyv2wRaGjb 258hJBbsvBw9L8fPyxH0cgy9HEUvx9HLkfRyLL0cTS/H08sR9XJMvRxVL8fVy5H1cmy9HF0vx9fL EfZyjL0cZS/H2cuR9nKsvQxtt/Wc9zzmuahzzqPuaUVPg7zf/6DnJznn+T7HPKvJq/CQZxsKb8fh 7Ui8HYu3o/F2PN6OyNsxeTsqb8fl7ci8HZu3o/N2fN6O0NsxejtKb8fp7Ui9HasvRuuzQ5gfe5pz Us6CZzk/9Cjnx57krBzkLM9xfopjnBc4xbnkEGcSZHmS8zdwknPtE/vOjjuwnv/8dK9/rtj/L7jj tPT1H3hpuf7jC3w+//7/srch177nLf4ie7ewvsN/hza+7243W9vNXcZ39nibNudHE/dDsk/+koyN pkyfNtJef7K73GZHzxj9yVUCJWUVdJMK+DbnTPC9Jt+DX5KFCvSQlTbS/3L0K/QV+BgSlyC8fH12 hPvgCVxNVh7gUgmZUoMZC10fDOJOZE4zKy46u6DdLDy7oMhQaJoiy5Bh5PKKe5144LS+/RMP2vyb PfFgffnq6W9imQi01HUCdks8ehhQqdHIv8RFCmjqgScFIOA5kr/3xtORm0D1wZwgaOnve5JgOh10 mi35+xmdkCp/P+3tyN+zCIk5cHRIqTJ6igPbF12Kdb8c8dB90wqMBbGhJkB8fh5RBoRAzCdBthZn 1exEYiWd6jB+PJgtxPLTe3ZAX8HzF4TzbXg+Oxcn9RV5MrMKpqeHOsMFuK5cEuYloiJIRiOjU3xV umR2h+faKqTpZZFdTl7cm/Hjq7rlIbobSW0xqSBSkSMV8rTcjUQI5VhxuWBGKVmel0tXRe5q7pkM raXhhJqnTMqBu3TbdlD8E9sapDFsDSJ8JlvL2haytRRCOd/ctDWdWm7YWnsUpdtaO/Y8s/VCCzRs KzTUFok1hsvlnh2rC5yV3m7o3ivQ/LuPivKgoHayrlZZsAFy7l7SAHoIfPkG+BqhUh4pcQMssnLH snTnWw4Teoh4QA/lVypazsP3DSCpUmr+cWQDn0PuK+TpLQG3hHKLhFadwJMya41dHJhfLQxxy1Ph aqhvOQ7p8Sw90q1u4UPZwmorZOu38EFvw+spLXyYtfAhtHBPaeFDs4UPy1tYjfyvFufLQzn+kw/l IIkFSSxIYkESC5JYkMSCJBYksSCJBUksVIkFSSxIYkESC5JYkMSCJBYksSCJBUksVIkFSSxIYkES C5JYkMRioRfbV7wcRLuN0SGHhckhJJVvDXnIO0MWPYXkIys/yuRpDyiRi7TiAUr2Svp4GBJfyJJm 6aklufeO3OOtIsniEqowf7SEurqEbufPllCXl9Btx8LdkrdbFu62vN22cHfk7Y6Fuytvdy3cO/L2 joV7V97eLebmzYYMq2JuLq3GLVbj0mrcYjUurcYtVuPSatxiNS6txi1W49Jq3GI1Lq3GLVbj0mrc YjUurcYtVhPSasJiNSGtJixWE9JqwmI1Ia0mLFYT0mrCYjUhrRavsfpUW/ikE1x3XlNXuMQLtmSY UmnZ+hYzojS+XDhpfLlY0vhygaTx5aJI48uFkMaXix+NLxc8Gl8ucvJ8+bDJ8+VjRuPLBYzGl4sW jS8XKhpfLk40vlyQaHy5CNH4cuGh8eViI8+XD4w8Xz4qNL5cSGh8uXjQ+HLBoPEpkVArfO1XsmwK 11eIBk3Akl7wMceiPGTxVbrKKVkE5ZW+G2RNfd2WSIuQveDDjk25xzsKs+nLfdZ5pSKkKpa+rkRX MS5CU/EeC8Xu847COBmqy4msowSnOLEZvEVjBKc4uRm8RSMEpzjBGbxF4wOnOMnpvIWjA6c40Rm8 RWMDpzjZGbxFIwOnOOEZvEXjAqc46Rm8RaMCpzjx6byFYwKnOPkZvEUjAqcoASrp5eFr1fRnSFSC TIB1M/JkCWn817+j82kWEVMsLiYZinoKeoWMJqaIxRSKmNYsWldfPPPVj9H5bj+283+SF2g/RR0V 5/+0u53/b+9bu9u4kUQ/S7+i4xmvRYuWCKBJvaLZkRPP2Hc8ihNlzu6eTJaHomiJa4rUkpQdXY9/ 8P0XF1VAo/Eo9IOiZSlmnxmH6i4AVSigAFQVqsL8L632yv/rLp6vMf5PtRg7kGx+FWKHDrEDfVMx xE4mSCIRdvh+q7Pfbi8SYYcvKcJO3gIyhPDc+FF/MG4bod8GPm820W2DcMiolU0+TGVfJZu8nWl9 kUTrt061jt4QtQgNU9lXIdTOt75IuvXbJlzn5Rx1csrbXVw1p7zNzIW4eUte8lJeOiTanVuVRJuN C/HxdlwUGRcdnlIxJSDnvN0pQR57L2994hk9N/CE8RzznupMjce/Hng9pQBhf/wc86DqBIvHvx4E zWWIR5r3wTMSLHCAlSW4LNG4VdiK+BpZ8qyiViwzagV48JvCBeEqtnlBwIoYLz9XvAq80wMxnuBW 0iwPJHUG3rGSixDNajrQt3emEFBxDPlZtS/2WW/e29d7OfdmFdCLowADdFz0ZtrU1ksur0fzoRwZ WR30bSzYG1nXmR57Gw+4A2bd/sH2J8nlDZr1RoOzc4Xy3178l+TDbDB6C2xCz/rB/14Pp8rT+60c qN9A2e1opAubiVb3b/vXv9bz0Bd5EQx+AYzSN7S01VzZvX/hnV+bmL21o7Me5xe5Sqy2BExgus3u k1ay0yaWCK9urLUaqRhIw4a/TSgNlXta22CdDUorv3xbanpNEpWb2jXdkvVETbQWTbkBK8vwbl6q fMcNAlJQkCkF2aYgOxTkDgW5S0HuUZBZvmqPJJImRhLFSKoYSRYj6WIkYYykjJGkMZI2TtLGaX6R tHGSNk7SxhVtkUkSCziR16K2Qx7KnBphnBphnBphnBphnBphnBphnBphnBphnBphnBxhnBxhnBxh nBxhnBxhnBxhnBxhnBxhnBxhnBxhnBxhnBxhnBxhnBxhnBxhvMIIIwx+rhi2tuAe2oIaZYIaZYIa ZYIaZYIaZYIaZYIaZYIaZYIaZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIcZYIc ZYIcZcIeZbFlupmoYJ/qupXa4l/PB8nzJqjGzibXp3IRlzvG4Tmu3Ef+ms3bztEV/twMrJtJonPa 2ydWDWqdIw2an7zNk5kEsAG0bNs5JsH26nnBtuq5u50qtIjjtsRUVWj5xp2HAS00QstamQVaZGyW tWrQDNw+reYDIT+U2lPXhk1J2DYJ2yFhd0jYXRJ2j4S1ZrANbE1hB5omj9H0MZpARlPIaBIZTSOj iWQ0lZymktNUcppKTlNpzWdresiz+pPh2ydwJBrBYU4uDwO5PLzHcM/jLGAx3jaX+/L+RfJhkJWW 5yw8+ffwODl8m4d7Tq5603nytjcczbZyaGe5KTZhZiFFrKfEkon2Vr2lV/NEiolGYsUGKW+U124U tEN6/69mHDb6cX1tDU+Pm5vgdqFxWPvkyKhlBCmpEqWkNEzJVxCi5F5HKPkEs8Ky/0Xjf5xO2HLt v7H4H0zwDlvZf7/Qs6z4H1Tsj4ce3kNPASK+BxUFI90ho2DUjGcRxIq4f/Es0t17Gs/i9tEKJMer hivIBwed5n3n86V559XSvPPPl+Z9ZSnXpVaW8pWl/KuxlFMXqwt9Z33eSnSoG9iF3rM+r00dNefs wmx2HQGoq8eu721BH6gQraYO+46y6xhb0AfAobwPak7nRcbCyvq+tHvHBWZY5Eqp9bXQ9GoP8PIE BrWvx1a/IHtLK2u5ibXMvlpuXK1x+TWzRYQG1dCaGppSQztqaEQNLaih+TS0nRKGU8JqSphMCXsp YSwlLKWEmZSwkRIGUsI6SphGCbsoYRQlLKKEOdSzhVLDN24FDU2gof0zNH6Gls/Q7BnaPEODZ2jt DE2doZ2TMHISFk7CvEnYNgnDJmHVJEyahD2TMGYSlkzCjEnYMAkDJmG9JEyXnt1y/f7eZQS5Fb1t VO0uo67Cvm4UlZnUdqnmPgnRq3GV8Rfm74es3VC1q4y6Cms7VG8zVHcHZIaQCOa7COa7COa7COa7 COa7COa7COa7COa7COe7COe7COe7COe7COe7COe7COe7COe7COe7COe7COe7COe7COd7bkeufSDh acH8qnYe0VXQ1/mK7/M1lnahz7ZgL3ajr/hKXw1MS+702Qb01aW+e/cU2H+WfP8vav9pC94J7D+M r+w/d/F87vjvD98GxOvYgHaXYQPiD8AGtPc7tgFVvNpoDw7aBrS7sgEtZgPC5MQqdKWrWD/2FDpV bEF0mftkCVqE3KhFqIDc+2EPKqcVE1OXmYQseH58v8xBtSiMW4RoCu+FNcinsMYZzOXtIiYhl9tf 0CCU90J9u5A7ABaxCrlDYmUTepg2oVUs2vsdi3b9ywecvYU1zQ4ZS1nCii1pRHxZv3SRFc02+6hs 4SbgpfmqtHvqq4kN55YV6quJDeeWTdVXExvOLdtWX01sOLdsR301seHcsjvqq4kN55bdVV9NbDi3 7J76amLDuWWZSp6eB4fzOkv1Vh4dziutuisPD+eVVv2Vx4fzSqsOywPEeaVVj+UR4rzSqsvyEHFe adVneYw4r7TqtDxInFda9VoeJc4bJarX8jBxbmmuei2PE+eVVr2WB4rzSqteyyPFeaVVr+XRMr3S qtfygJmVg8Y69ionXuy6taP0wsWGpYKpQwSLDUsFk4YIFRuWCqYLESg2LBVMFCJMbFAqnCFEkNiw VDAziBCxYalgRhABYsNSwUwgwsOGpYIZQASHDUqFI58IDRuWCkY8ERg2LBWMdCIs7Pr9NaSqiK63 MqTqKu6rITWS+7t+TNgvZkj1BZdj3vNFV1DSFl5BSVt8BSVtARaUtEVYUNIWYkFJW4z5JR1B5pd0 RFlQ0hZmQUlbnAUlbYEWlLRFWlDSFmpBSVusBSVtwRaUtEWbX9IRbn5JR7wFJW0BF5TMRVxdRcUq 8usq8uvv/imw/4q7sf+m7RZb2X+/1FPD/ns2hCBcmTX1q7H/ijr2371l2H/F/bf/Qsrv3639V1S3 /4pC++/eyv5bbv9dmRKWZUrAI/YbOOzNB7/NUX5/N4StGP4JE1N263A6y/zcoQkEfz1pqh8vhwfm y3e4i4NP6pf9zb+Xot/ZUQDx3QuEe+HAvUC4F/mVldtaQELTh95dVreAVDV93N74EVo9MmQrGz+q WT0QW83dmMrjIAd6OYxpDTTh2XDwwcyR4MACC2uzwGy9yNLvKVGapohhJQO9zU0lZR+pekkp0++y LB9YbmKpektJjT2tIrbyAvr2HR2XRic2yrU1SulDwXIDy+N6oEztpASA/VdcG5TpmZSAsP+yCfBN TLxhN5cr1HDCkbDcwPJiFnBz9rX/Ku7z/CBq/2UTIDykRMNuzuUADcsNbAkHhMMBUYkDwuGAIDiQ ekilDbs5lwM0LDewJRxIHQ6klTiQOhxICQ60PaTaDbs5lwM0LDewJRxoOxxoV+JA2+FAm+BAx0Oq 07CbczlAw3IDW8KBjsOBTiUOdBwOdAgO7HhI7TTs5lwO0LDcwJZwYMfhwE4lDuw4HNghOLDrIbXb sJtzOUDDcgNbwoFdhwO7lTiw63Bgl+DAnofUXsNuzuUADcsNbAkH9hwO7FXiwJ7DgT23HdzI+WtT q2E353AgBswNcDELWMtmgfmrkAUZlNbKt9x2cBPqI5UtxSxcimPA3AAX84A5azGrtBYzZy1mLOSB v7yybC1m4VocA+YGuIQHzmLMKi3GzFmMGQ954K+vLFuMWbgYx4C5AS7hgbMas0qrMXNWYyZCHvgL LMtWYxauxjFgboBLeOAsx6zScsyc5ZilIQ/8FZZlyzELl+MYMDfAJTxw1mNWaT1mznrM2iEP/CWW ZesxC9fjGDA3wCU8cBZkVmlBZs6CzDohD/w1lmULMgsX5BgwN8AlPHBWZFZpRWbOisx2Qh74iyzL VmQWrsgxYG6AS3jgLMms0pLMnCWZ7YY88FdZli3JLFySY8DcAJfwwFmTWaU1mTlrMgvXZO4vszxb k1m4JseAuQEu5gF31mReaU3mzprMwzWZ+8ssz9ZkHq7JMWBugIt5wJ01mVdak7mzJvNwTebBkTdb k3m4JseAuQEu4YGzJvNKazJ31mQersncX2Z5tibzcE2OAXMDXMIDZ03mldZk7qzJPFyTub/M8mxN 5uGaHAPmBriEB86azCutydxZk3m4JnN/meXZmszDNTkGzA1wCQ+cNZlXWpO5syZz/4wMT+UoLp5y TqvCDCruWc4C1How037pQc6RWK1KEqvlSKxWKLFsHZ3WgZUr87QC7Atp8jLMuYM5t5uKavG05usL qfAyzIWDubCbiqrvtMrrC+nuMsxTB/PUbiqqt9O6ri+ktMswbzuYt+2mogo7reT6Qtq6DPOOg3nH biqqqdParS+kpssw33Ew37GbiqrotFrrC+nnMsx3Hcx37aaiujmtz/pCirkM8z0H8z27qahSTuux 7o9GTuuwyrVxWn91fzRxWndVroXTeqv7o4HTOqty7ZvWV90fzZvWVZVr3bSe6v5o3LSOqlzbpvVT 90fTpnVT5Vo2rZe6Pxo2rZMq165pfdT90axpXVS5Vk3roe6PRk3roMq1aVr/dH80aVr3VK5F03qn +6NB0zqncu2Z1jfdH82Z1jWVa820nun+aMy0jqlcW6b1S/dHU6Z1S+VaMq1Xuj8aMq1TOinVjml9 0sm90YxpDdFJqVZMa4hO7pdGLJp7MwNWXv4fhvMLL0khAr1QnZ55DrrPZqIVaYVqNU3QC8WKeE3l erc7Vry9UGzLHCJJ2ksUc3lNvLCmcs3dHavuXlh9jL//G7tDee82aM4Hyj2X81ldXNWlvX4bNO8D /d+X4b3CGX7/d+a9DP1Kc18Ucz+ri6u6ONaV0+/yXzxA/qdL5H/6APnfXiL/2w+Q/50l8r/zAPm/ s0T+7zxA/u8ukf+7D5D/e0vk/97D479RBi+B/0Zf/ID4z9jy+J9pnR8U/5e4/2MPcP/Hlrj/Yw9w /8eWuP9jD3D/x5a4/2MPcP/Hlrj/Yw9w/8eWuP9jD3D/x5a4/2MPcP/Hlrj/Yw9w/8eXuP/jD3D/ x9ny+J9ZTB4U/5e4/+MPcP/Hl7j/4w9w/8eXuP/j1P4PK4P4J3nwgUPFD/zy0Vg1cpiXGHRsI87G HHt791ZxeMnHtAmPGy7tUwxfXhnfcKjkPWTvECsObRvfPGZajqt+twGhBFZx077GJxL/jT07XVr6 r7L8XykXLT/+G+diFf/tLp7tp4tFZ0ue1ojOJoFvHZ0teQrVZFGRYIx2WfeUd6fneYikpCBGUhPL DueDaQ9aniUNqA+iXCUQ5kpi3B/MZhIfiYaKgQVErj/dvnVIMUSzUkSxbNapgGJbfIsBC/a2Gd9u 8aTF9tut/VYn6d9c1Y8pJkfv/OZqMItFGjNhvdxQYww8BrLYWZLO5LInOQlhtvqT6QBDbM2ULwE4 EGxvU1HG5NvqccYAWBPkBBqLRxqrEWrMzTXVxRwux80kT9QjtyQndAIltVuys6xYO6wcoGkg/cZU uNoarV0M7dQ21n42B2gaSD/TUtacastv6Thoo0ILXgOq80rqNz1Wob+8BDsuBYOjrLj8BTF3IeSu irhLk7UgXcKha/DctPocA9hC/Npoq5KIGtQGId+SIORbkTzTMd+cyOsnEJYMgpJBSDIISAbhyCAY GYQig0BkEIYMI6ZBsDMIdcab2gMKYp1BpDOIkQYR0iA+GkRHg3BjEGwMQo1BoDEIMwZBxqjEKk1F 4muIGZb1fDRbCvFNxxqrFL1LjzkydhbBdNnxeDbJJ748g0BCBWa/ViMOYpJzAlo0E0FAp80kJaDb zaRNQHeaSYeA3mkmOwT0bjPZJaD3msleCC2ZylohtOQzI6iUrGcElXIgMIJKOTYYQaUcLoygUo4g RlApBxUjqJTjjBFUyqHHCCrlaOQElXKAcoJKOWY5QaUcxpygUo5sTlDJ203eblBjszinR8ZFC11u hp79Lht3BJwg4FICrk3AdQi4HQJul4DbC+EYQQcj6GAEHYyggxF0MIIORtDBCDoYQQcj6OAEHZyg gxN0cIIOTtCRjZeP+pjtpMeApUudwpeQEsOXo046i1w4qlwWZm2suKtQcLgKxjNKWI0wZymsuFFy EkO4c8G8dWaDD5uSsG0StkPC7pCwuyTsHgXLWhQsYyQsSRsjaWMkbYykjZG0MZI2RtLGSNo4SRsn aeMkbThr8vFato1TWRPysbrm6KqKEhLUSFtvb+f8bARt3X7R1EA6MduAnMTPlvBk4avx9CTPi6Pr Gfx/ffCblBzysPjdo5qnX3XilXhmB6qlHp4/JiXPugqW+w5KSd62oL/k2RnkmwpPfWhVmH3MgiR3 MxD3OApgsApvv56cn/Sng8FYHs0f2bviw+Rxa/c/9+GfZOPxfzb+OX7UtCnZwn1m8ArkUYYYclaF gd0wLyV/GrJduw+G52N5BJ7hYXh8fXkqyZTiO6NgZqQ/dvtgdj2aKzFqh3R2NvQHRn+cwbt6Y9WV m4f66zOtdk6S0+mg987W6w5Gs4FTVI5RuTse7EPs9Jk8rvcvEG0VRv7pNvZqsFLNB5dXkn5yHy/3 6kVlyP19FtU3Ib4kh0ZRvbGRN/ynPyUQOOXfIMgvPn/5y+tG8q/yoUdWJTfTpqq//KXVWrSqb7+1 qoKKblVVRqCqCKo6KKrGqipkiuz1sBn5eln9qKpaSj/KqpbVj6qq5fUjSPxDTxZlQzfIiaPgv5XY yPHfcAvZ5peAV5ubWZ0VJ9pqbtWuajW3vvTcMosWNZ0+rav/670dwh6sf5KFv7Rd5Gt5Iva/LiQ3 YUuyACr7Xxqz/7Xb7cD+126v7H938myjWe0hmQBvecyCKqpmvDpi20ccsXsrsbQzXoHpkMp2pVC0 jmwzX6evTl9cnr688xaes6A0+cDe+ul8eDmYjYb9QTMBU2LydNaXh5H+RbcnDwAJHiDc4tvbSrJK rr04+cfrn7t/gWN5U//xHz/89LdXx38FDjxjzWX07TIyMEHfTFg1g2kuptBkytBkyqVQ2W6x7VYn YXw/5fsiTa56csD131FmU9rueZhw8+kfJy+6R8cnr7qvjr/76cXfXxz/XCeD07LzJblmRVS75BZF cOE6Yb8c/0paFfPgB3p86FLgrHXCY6XyCAVOKcIxj86D65eqmA/XEKopBbtcLULRH642oegR56Ic euDR6XD9UlXT4rqG1XKO4l8UOwvI5LpMwMyFuHlLXvJSXjok2p1blUSbjQvx8XZcFC4Xa2Sd9Xlr fABq5J31eW37EdSZswuz2eTghS7I8H+e94GftbagD5Rbrakj7wM/pWxBHyh32gWn8yJjARfBfMUz ytzGeqWtwYTRe4OSp8IewdIGr/LuYRMzuWYPFJbo0QQJKOWGqIebRFO4aSt+Dw9BLTybT/oXg/67 bZ58s75el5k+s0qZ6z8Uc9c/rmfeWnLrPIc0kKMzSFt2NpH0SyaC09V0kLlvQTrX8WA2y3KBXvWm l7N9vYd1tdpAL44CoDi56M10PrRecnk9mg/lyMgqoTXhsCfMqU0ee9utwEsZddtPMYHoDSZgGw3O zhXif3vxX5IZs8HoLfBKDgpZ5n+vh1OVb/StHK3frGv7aGB/8KwYhxYHtkNLg/bQUfkJf+GdX8G7 Gv6rjVmu9wtrahECQuWAAOBNLSpAeGAVmZEhRwnMDI7iXgtfLbjjWj8tnKpnyjMKmoruNjn04vny wNHolxYs2ba4d3PeRRYpkMwGQnJB1eIHundrCVctENMNi3azs0w2WMN5h+s3b4RwgoBLCbg2Adch 4HYIuF0Cbo+AYy0CkFGUMIoURtHCKGIYRQ2jyGEUPYwiiFEUcYoiTvKGoohTFHGKIo4U0VMgHlM+ 279ivS6qnBhFnBhFnBhFnBhFnBhFnBhFnBhFnBhFnBhFnBpFnBpFnBpFnBpFnBpFnBpFnBpFnBpF nBpFnBpFnBpFnBpFnBpFnBpFnBpF3B9FmcD2fH3UNr+pN6rP+QE95Gp5/phxq44VcfcfZ0/d8s8V phJeWImzqW75B4simU0dLIqkM3mm0Eg+j1CqfZAcSpl/ejCVRCjVlTiUMv/4kC+01Y4P7sJc4dQA 0PYQE4T0EIT0EIT0EIT0EIT0EIT0EIT0EIT0EJT0EJT0EJT0EJT0EJT0EJT0EJT0EJT0EJT0EJT0 EJT0EJT0EJT0EJb0cGZotYM/TwtnaLWTv67EnaFruiLYhRf6TzF0oJIFALrUhco7xGflEouktiGp VDQ0GrYfSwVkeS1kPW1BgCzPkOWJe72SlEsN0EqvreHhAuz4a2sa9zXlgKP+lcfLR5e98flo8Eye MqeDy8F4/ggPMSDq9Unp9Kbg3JQkqnzXlLe7RI8QY2INjzCf9NkrOwbZJ55E0oC3e+RREY788hhv BQrVBzFtKjj+4eeXr47/ilWid5Fd67depaYO6/WhNu7ie9norPd+kN8n+mBpD87gXBvDA+0XGWHZ Wbc/ORsoDcYYLhjBuUMyQx5Vz/BUIiEuJ7O5rFqeSWbynDV7m91gurySh5epas45Sh86fx5AU9fj a9SMTM+3ktlF7+zs+sqrIT+7Ary68gQH0ft8szaw/2rDxTLbKLv/2dnx7b8pb7dW9t+7eKSIWsj4 K8tVN/5K4Fsbf2Ud8P8/vp6c7yfZKG2+T/6o9ITvh7hpZlvtLb4lEjACsu0W327tJa10n3X22zty ivcuryYAP5I4DnudFBvvja4uerpKKY7600kzabceJ7OrwUBOcglPNMGT3M64C1czZRNiVzYx7r1D Henf5X9nCcwp1CvOZFNgIkblYmf3XXI8mD8/+X6WbFz2bqTAetvDQ8P8ojdO+tPrcf8CizXo1lli LoYKMHjut9r7rTTJzJyqEKpXz85QCs6G+QqCKOR/DeVHKT9zTIkmsbndbca22U7S2sP+5CDwLoca dDCFNQS1iFNZcHI9A6vu+HzQTKajyyEK4uloCL+mA7CiSyn/5of/ePETtD+fXveVRk4pZb3mU6v5 dtLagWuw7Xbe/Kt5MhsMLsETtzdHHFTNvWn/Qi46cmGZggp0MBs/mScXsPDAmvNkOhmNnkB5G4Nm hiXiq9H9Hykk1MgAPfZQ8gZU5XhUg+5VKzjUpNtVOm25A0lewRIB3SzBJtcKuelgNHjfw55HvTRo ixX1qItWCnZrderLIQFG5h6oyU8HcxgnmQ5ddflYDlT5c3YxfDuXFEymTUvD7XWm0J3Z6myzNGnt 7jOBnfl2OhycnfaGc4B/ImfZE9ikyF3G2UyPIlDGytPSXP4/6V3PJ5eoHVVcTuTsnU+mN7o9NICo e8BduZc6+vlF92W3a8xDzku0lXyTG0v+evyP77rdhgVsLkiqH9aNZ3SWJ8zzt914ZTYO3FSADFM2 DZg4V5MPgymqzHm2u/jQu8nmr4RAo8Il7KZUzTM1qbv5BOxKJDYaeR+52zaz88kuTb/47UqOYbB8 GFOGUq7OBmiZmU0uB2gZeRQ4NQC1niqYuniKtgRXSHg2C8dPXe/wZOXKK3JD/5KHEd+NQrkOZr6D 6snd3L/JStquhcZn1ri9h+2geySqsnMPx7xqovLMBdJyyM23qbEGsAnbGzNvgGxCNeKEiPlo/Y43 Ixty/UfzZuRg+gDCCw0dMM/VNJy9S8Ce1pRjb6asO73TyfuB1ZqNnxe15qPzF4Cg57H+4ZsJqCol GMkyugWrjQ27kUIWRhslWBlrNt5wIWsLmiZYHG+8qPkClufPp+Cd/8b92/4r/539gstKf7hGiSOx 0bICBhjt3wQhil6/kn9AKAc4OUJEh5M3Rz99Z13VP3n5euO3ZjJraPd3+Z/fGjDrN+SrRsOC+4mA +9Ofkg0BlloJjeASKbi5UqF6qP/fEgFqg8qNWGWwKbOKUJS+Oer+9OrkO893LVucIrf3UW8AP35T Bt4bMMmuOSphucE6WF9f63Z7s0tZqtt9D3tdudBvrK+tPbqcz+Rp5DH/5/if8/ezi7PkMWvC/1rw 4pGE2E8eHU4fJRuymob6E/76rdFUP5DQG/gC9+b0gRSb/FSEs1BI18U2R5DvVcCRQEnyO9L9sJN6 s4zuz6YBQVf2iSLPn3mPpqMP48vkcQv5wZutpmCKYB9y36I+/Oaw68ZEOVMY1mfXEqkbGvLELakr IKqE49X5DbcFI/wm+wJ7wRD+CPf2kloYv3K+NRP5UzBDLkElxbrFeEZNMR9BwHBooSh8DElGWAyo 0fOd3b/F+t0Wjj+cQIEfTron/zj+4aSR/Otf4afjFz/LUy0gZFzBvmuDo/H3QKuRuWE3GTDkqfnr ppl/ccZ7tUEtT3jA3Ew0EWP5DFlJfGnhB8nsM+zRpHHgD+kb6NYSSsQGjb4ZAebzInMWyPuDKCMv MlVbZVM1Ol7+/urNyVIEczgPiGkwGVnz9G4maH3MRBXEKHyinfyfu5073nuo2fK4P7KX8keH59ZK rgeN7OH+b2riwEv5G4bRZ99uIIJ/FKXoUchE+/no9ZuXRyDLwk+vjjppA/wk5R75Z+3GeNoDI8Bk rFRdk9k8+y1PyMlIUgJqhcth/6KXbFyeTq/77/48HM+e9SfD8dYZqvNQYfVEUqLcJMeojPr+xXfJ EeohryTBbyfTS1QuKN0g6k1BKZG710pWv28mY9ji4lZ3Y+O93hePsz2uPGvIImv5Z2sjPM43ws7R HPBbW4Dg/zPpTZK/D8+vB6PkePAeNSjohrkxnfX6057shX7vcjKYbU3Hoy1ZaOt6Ptq6mjv90RvN JrfsFAGSeiM7JAi475idAfheI1OmZqS9nU4uk79Me+N3ycvJdPJhOP+/ybdv4e8/yxkn2XW51Z8N p5Ot3vWfmpmyZzq4moCucwS6roS1HmeqH0AakJ0lG9BN6qQuO+kZmKemsz+PRj15bkf1+A/9ecL4 9t4OIFRtNs98uTQGdd7H6/FseC6RTUaT8bn6p6cWKqXSzAFgv3QxPHD+Hk0OPp0efIKbnlAI/rsF ti85poJ6G0l49LLkmX7w1ujWqdJu6N/y2NtYTPZ+MRpFXdLUuXVt3Zmh7lkUzrIoO/Gw+y88rZq/ G431YBxndQjrsGp+LMv+E7//OT1fVgDY4vufvN1mwf3PdGdnZf+7i+fh3f8cDz4k76VAxbLK51xu ohNQYCUwatGItSXRlItGX1agRvJWgnT2xqA416aVM9kwqNXPNze3kpdScJ9K9JLJSLkNQDvj3iUA 9Cfj93KWgI3mvt1CHU/Gz6ibqM1kej1+Bv4XyflgrN3Lob9OWr/8Gr+minNfRQV6OxycdWHRrXVP VT3VbqK4ddS8q+oREMTOzO5fTM/JsEiWw0ocEQO0pLuxS7gaK3lT9WasEuB4MVagUdy+GJuC3Y8V XIzFrdLTn+KDKNlXMGvP5NrZO8OYvnJ0Ts9hfknUwcIpoUGJqg0XHyaOqRWMk2tyXR3KASIBZ1e9 aT/Zxy3o2gwsWsnji+EGS+XTaaei02g+Puf4VQ4C+bP5eDQhPiuUMnwlVohsbw4TAjmqsEGrHhhO LJQUQupGkCw1/hVDjP4yfobOoD9a+O4n/evpVMqEkxY4Xv2YNEzLZ9Peh1O5400w2JKh/BIuF2Vb m5mqCpqHOf3EVPYEZ795/+MTvWUFG58cC8OrGZiDn8zBIgS1KpMvUDdRpmOJwAl05Ez9xu1zZtEH A7Rkngr6tK8Arq76nVaqfv+E5hj1+83RrvoNst0pAZZNvfmOXZ5e9tXp7psuiHj1EDeouz+ab+YS dXCHWlWy2cVL1GAT19ddlF0f3ngTlrppfcKO4RLQcWNN3Qnsa/4frK2tmdus8oV8b73i4SuEwptC HhheDrLhMudOuP9igZrXPH8tscO7NXn5+eUVU9dtNrPWNChHUO6AcnWnZjNDwro0KjGDuuyXXL/0 IC0v8CaWkfjRF0nxc+yq95J7WmIT9LRE4TP1tGqtUk8rJKyrqUFPo9O439OeF7rf057Ted7T+cjn VUc+J0e+ple+Lh7VmlhZsnSk55Q7cJrw38eMKJ4Q9Hzg1Hwo6H9nrBf0vz/+777/736eFE+TrP/N JBFVJ4l4CJMEryAcwvUDpzjFOLxocIg3ltbs4vllhibcYjiwwPMrCk24m3Bgldp0x8BA4ezxmp6W X2wSrhHRDO75JMQrGXiPo5y/zxV/bR64ERqagyOLv07ghebgyOLv85C/z4v5a0/7LzrJv/b4B1XC VFQ/WQcBg+fmhO2HIF64MqUiJi/2W4GFFWz2AVO4NTFRHf7L8V+B/6b4bxv/7eC/O/jvLv67l8Vl wGznTcz5jf9iFZg0o4tpM7qYOKOLqTO6mDyji+kzusyugmMVHKvgWAXHKjhWoXNqIMYcMeaIMUeM OWLMEWOOGHPEmCPGHDHmNsYcMeaIMUeMOWLMEWOOGHPEmCPGHDHmNsYcMeaIMUeMOWLMEWPeJbOA BHEQCqMg+OGD5cxVm1UnQIIfhTnX3pQHYc4886pFUlg0jkKdKAofPaLleaUpDzbrywqyAEelQ33e zbwWfoQ3dhtZNkdYSnJ+q1f5kiGrqhGXoWbMBZ1SU6ejNLXkx20FoJMacg8gr0EoABGtIVUAabSG tgJoR2voKIBOtIYdBbATrWFXAexGa9hTAHuxGuRsVpM6VgNTPcmiPclUT7JoTzLVkyzak0z1JIv2 JFM9yaI9yVRPsmhPMtWTLNqTTPUki/YkUz3Joj3JVU/yaE9y1ZM82pNc9SSP9iRXPcmjPclVT/Jo T3LVkzzryU9qBlHCJhavQm6+1M1f5xgPK4ua6naqBq4zQATz0SvrTUavrDcTvbLeNPTKenPQK+tN QK+sN/u8st7U88p6884t6086t6w/47yy3nTzynpzzSvrTTSvrDfLvLLeFPPKevPLK+tNLq+sN7Pc sv60csv6c8or600or6w3m7yy3lTyyjrzyNoP3N9QHXnCYVxiFwvVkWcBxlX4bkJ1ZHjWiNaRJ6/2 ia0RrSPPZu0T+xmjdRjx6sSEiO9YRExMBuXp/YqIicqgPL1bETFxGZSn9yoiJjL98pGdioiJzaA8 vU8RMdEZlKd3KSImPoPy9B5FxERoUJ7eoYiYGPXLR/YnIiZKg/L07kTQ4tQRUJUilahk7bcLVKLr iMcpKQxTstQoJSqzeuUgJW6ugmoI86VGKtEIVw1UohHe3LRQXl58Eu/aaO3oJF7qh3qhU3OniAKH leRzRE+t7zBT3rgVVJRuPtd9SUiEG5ypyKSy3BlqMEB1AG09TUxk00HS743gIjlcgcd7pH3QIPRO wR/AhGAxXAWvBbgk39TVwN7GCpIK6bGT41yrCN5WTX1HFVSKqpB+QNeYB7fszifdM5wRuf5mm7j9 /FRX8mqedIezrkXCE/C/nV3Juoanw9FwjiFdBmMMamr1XnJ0/L2uA8qChx96gsCo/gOqT3rjZPB+ MHail7qIZJT8DI2jk2Ryft2b9sbzAaqbwDX6RsM8A6wGc2wDlb9yCGMw2T/g5dwnEDxActFAI8YA jAELnliYP8H+HX3o3cxIHHlqOnhDRSLoT8AZDpXQboYV2VfarWR0k2x8P+hv7+01wJvjejaAqwm4 OzVjB3Re9gAMGNPAoDZmuORc/Xezz8WITXmNT/0akm8OnUHegBovh7PeCP1wv8k0WFQcndNBvwcu cBs2jkEYWWihpaqRJVX4W3QrV/DhYGgmp3ISYHyHee/dQDFE7uDPJ5Oz5G0vy2ue2DMuOYyrsJW6 Ou8Ddb0GOsapwO+HSBwmOgYTwBp/OJid2Rcc2bOb8WR8cwkBONDiYIVSwgdiL+FsRgcoSzqARhHN FOiiOcfCGDppivEGgKFQlRX+ySbpW58ibNUZUYd2Jx5UDgJFBYCyiZkopn0YqEAZE3D6lvj+/PIF slghDVz4bAGe5DJ2b+M7lT0R/2/wHuTL9f+OxX/iLZ52Av9vtvL/vpNHbgFv74csK4n7IZ8NIc54 5uNtFTMeylCecFJef0CxqazQVN4EIkJUdbIQPDsQO4rz/faeE07p9WSOAWb++Orsj3K9un77lojj 0/bj+PCdfdHx4/i8OnsiGXGehfAxvpwQNub6Cm4yJU+GZ1ICPMFARcBykPVDueXu3ciN3ikGwAFv YNjCDKZgkdJO96fDcW8KWrBB/xp5HQ/c5MQa4suNNbSOCXjVna63YCWDParyJT1TN7wkR4ARsFLo RQLYmt9CUqYz8HYucJlfeTvflbfzrb3kYSfGq3nJ27MU5iU1LWFWUnmjKnsxK4I8F2m5UeWN9YIQ T8qVAbb8j+xQJSqoFtxOFfz5q5+7pgoIwXajHEQgy8MlBJ9LBD8dzuEuqzyIPbIukYV+1XGvajsx 1eKO0+A3pZ2n4BcEiYM/4L/gTGW8e5N/riufQWN/zlXhqhgmclHOgh4MKD10lQBDKLqh6kypk//O oH01NzSSaVTy3w0/z43KTHUr+jLsiujLcMrpC3XbmiZUbue/M2hfs61pQtV2/nspXsJUH9h0550f pzvv8jvnK+F3W5GiQk7mnXxnnFyGJ2sN1bDF1SOdt6mGUtji95HO2FQ9YxXJ6uqJqhyCq6eqsphu CK6epMoaDobgyumpyJEQzUi18nYkLqCH/oi+7tgJfBiGBinwdPNy/TjfluCRaJ4luCbadVXyUXSJ ub2zYo7A7b0W7boquS9WcQys7Ra4XtklkPRGoFz4HADYmymPvvU12VBtb0ErI5Ny+suc/1A0JYWO f5uZExHLnYhCP4FNNS6Mq5FtilQ5eBKm6sg8jnSNfsXWLhJmtW1gd8sTrlQbEDjLNrm75ck2UgWT GeHd8mQbbQWTmeXd8mQbHQWTGerd8mQbOwomM9275ck2dhVMZsx3y5Nt7CmYzLzvlqfaYIpZxuDv lqfaYIrLxgXALU+2obhsnALc8mQbisvGTcAtT7ahuGwcB9zyZBuKy8aVwC1PtqG4bJwL3PJkG4rL xt3ALU+2obhsHBDc8mQbisvGJcEtT7XBFZeNk4JbnmqDKy4btwW3PNmG4rJxZHDLk20oLhvXBrc8 2YbisvEec8uTbSguG48yt3zjIDM0VHLP1N5DEddMtyGsOuKmmQtN49IZcdkkhGXEfZMQkhFXTkI4 Rtw6CaEYcfEkhGHE3ZMQghHXT0L4RdxACaEXcQklhF3EPZQQchFXUUK4RdxGCaEWcSElhFnEnZQQ YhHXUkJ4RdxMCaEVcTklhFXE/ZQQUhFXVEI4RdxSCaEUcVElhFHEXZUQQhHXVUL4RNxYA6FjtpCE O+uRdmJ1P6nTO/UJL3TAvT21W7uN5ytWsLDXK1KcOZYt7PaqhKeupZ7faw1dAqJ4e4/XJfi71vN2 raE9MAth1Me12MO12L+12Lu12Le12LO12K+12Ku12Ke12KO12J+12Ju12Je12JO12I+12Iu12Ie1 2IO12H+12Hu12Hc17rlqCZjbeK3ezmdVeaxW8lddzFt1Kb6qOh11JS/VxXxUl+KhalYk/Kt1sLau khbc3+xpD//x/X9U2LDltlHi/9Nupczz/xHtVmfl/3MXz8OL/7h4CD5l7XrgkReText60XHGJ60p XzD04lK8SkqcSpTsRFeS1Aq4yNGdhO230UGr1J1Eipn5zdVg5vqT9MGffDiJOpngPIa+Ko7YiDC3 8GGShQkfJvm2wIcJvhb4MGUoLebDhAjFfZhyfAkfpqzlaj5MWFUVHybFh4oRGxEBHbERf+uIjaoS L2IjAuiIjfhbR2zE3zpioyxlRWzEL1bERpwJvvdP7vtzXRRS8bospuJTzzUI1ADb/uxNbBQsdewq suIqsmKFnr7PkRWfej5TFcf/Kr7iEudFhdBuq/CKXzTymjVRRL2JsoqxaGmqVjEWVzEWH0CMxVsf 3ixZUCNYYflZtEawwkUqy8+4dMBCuKWYRbU73IDTqClysL4KW/h7DFv4tHrYQtszcBW3cBW3MFbD Km7hKm7hKm7hKm5hUHYVt5B0HCPLruIWruIWajxXcQuJHcsqbuEqbuEqbuEqbuE9ilv49FZxC7MT p6xmg4O1FB1P4MDaSJ5B6Ckw146G7zDulY45AlV9uJiMMAre+DyrIlNfQrvemRu/y/fYSRgsS68A ct/77beJXPbd3NvXuZPeNxm0+q6O7NeNhrMLIKqW5/uWOuGrqlstVbXNbqduAEDwLFd9Vnm8emwg q141cGAKEQ2oJkwDdhNFjchm8kagjgPwMZQcU5EGIYqhMtRDoJjZO4x11kw+9DDgHgY3fO/FPrNx s9BxEVIowfDPfvhaE6pCCUZxim7AamLDbqOQc9E2Aw7GGo03W8jRgoYDzsabLmqc4LRf+NN60d/2 X/nv7NcnLTfUdMxikeIm+SsKP5qUtF+ldVRkg4ovjwMKDi1eJNDZpFLUTw4IPS1GCk4nXl04uaEu ybf3vZGsASp6ul3Wu+uWCr6Z/KY18RtPHZRwLS+LEkhFBlxPjHI/ai9QbFAtY0NW24e6+FM1LtfV dNNY6o8Nc8vHDoeoffNwNOeBGVXJb4sKqjiKWGx9vSCy4cr1+vf9ROI/Mp09eiltFPt/s7Sdcj/+ oxAr/+87eT5//Mcib+gHHeKR5RnWq0R4TMUSIjzynfsf4TFN722ExxLv6FWEx7vKZw9R1YH9CYoX EDlz2EJC7TOLEbyTN4E1nLRaW1snvG0ghAdwxJqoIwWtR16NBwSGZsDrR/ozKGpQ+D1nSJc8bOrI 4HJW3MgdIMYVh7jro95V8gGChDs1WpH33w6nM/D2nup42xhhOre2IzROSQkLEjUKKgwxzO16xBjU KUmhAqhpj4WePOH0IaK92cRqmuQ+fR9HJDg0HB6xTd2Na2sY9+cQXps/Dz1nLz2cUJKqEJRZKgHZ oLqqYA9OPcKSk4kZV7yzKTb5JujsBHMGFwD+ME7+/urNSTN5+ebZG+VT8GbyYTB98x1EXNfR3k+h sXMYWVLAoBjIhgy2PeidwXx/csSe4LKl+kO2jyHREAnRsoaD5s0sc+VHaoQ1YHB12VBB/sG3Afbf H4A7GBtN4QRYOLWCyEvgWKAWVoXEK31P4HyAQlOtSH9+/E0CHpKzZ+f9fhaYDWTgN428V/D6AIZP h/jvFyDyJY0Oiij7/t/lMPnr9Y0UtdP+hVxY93ZggWJ7t78cw8ovx4SLJhlwNRWfL+AqqxZwlX3u gKtrdLTVNTvUanDVYsO6a9GoGIiVvmbRQIdB2+vfhLLM1eWoOjfGPHSnWXOiMRaLm+jNg1qNqwZM 47lNLCkxilWKX0o74TcqdAeA3a47uNMdxfSb1hahvyDsJ+1b3VAsKSZ9zYkKmhCWlyPlT7pIDzmu wFF07L5Zc2J2uugcOejU68JVwMxlBMx8eL6shZ6h60mxL2bUA1OF6qFdKDN7VLkvZga5uKNl6GaZ B5PUvWQ8LAN3yiJnytyLxXaTtL1bbO9I573lFBmBTyPw7Qh8JwK/E4HfjcDv0fCuZ5XtzBiBj9DL IvSyCL0sQi+L0Msi9LIIvSxCL4/QyyP08gi9PEIvj9Cr/Z+qx9Vbt92sFAvtaF7+wPRhOQkrSNiU hG2TsB0SdoeE3SVh9yhYRtLGSNoYSRsjaWMkbYykjZG0MZI2RtLGSNo4SRsnaeMkbZykjZO04UCj xHDdqGcfaf+8g0UjogX+KvUc4er7tOW7oKzBys5o+QwWEUkvIpJeRCS9iEh6EZH0IiLpRUTSi4ik FxFJLyKSXkQkvYhIehGR9CIi6UVE0ouIpBcRSS8ikl5EJL2ISHoRkfTCnXxr1qBf1EfrwcTYWnuA sasi9r8ue3a65Pxvacz+x9OOH/+pLXb4yv53F8/XGP8pEoHJS+jJuqeczuT7dG1trYLDTBjeqG6g pXsR+Ag7oppy10gN1O6yLb7FdAwktt3qJIztp2JfiOSqJ9nff0cpebUOyFPeHibMfPrHyYvu0fHJ q+6r4+9+evH3F8c/19ENmwYUQwhF7I/ZlzztVaCMxefNJoa9cZWsXdRbHTeT40aiL4eD0c3KAYR1 HKNSSm2cMJWL3mdZ26wcoGkg/caU0q5GaxfDvDV0x8tWuBygaSD9OCVZc6otv6XjoI0KLXgNqM4r qd/0WIX+8pSKLgWDo3xXgpsS2JOoLQlN1oJ0CYeuwfP8lj9uRGAfEm1VElGH2hrOixXFXYKR6ut5 J650p1u5cVE5l09UNmUw1vbgw/lokBeHJbJpuTmi05+VOfmb3OGzKtd8hiEX19aifp1uRh/Q1YKm FvS0oKUFHS1oaEE/C9pZ0M229ponqJAFXSpvatUhKFNBlQq6WNDEgh4WtLASGC/lw5V8uJAP1/Hh Mj6lcG2qYf1aq0yD2An4Ql+tl++eWpET1iOX7z/C0Kp6+15pi9Usj92319OR0vLCVwVT8XJ9Jrbz /Dtabrdg7ofSRs747OpKvujIMxdcgWXeFyXw4GYXp8sIOXTpMmkzSeky7WbSpst0mkmHLrPTTHbo MrvNZJcus9dM9sgyctzlt7ScMnI0MroP5BhldB/IQcvoPpBDmdF9IAc4o/tADntG94GcDIzuAzlF GN0HcuIwug/kdOJ0H8hJxuk+kFOP030gJySn+0BOU073AW83zTVvcsDHLnhnFWU7ipZLBzfj2Xud DWYaWtDQKQ3dpqE7NPQODb1LQ++R0IymktFUMppKRlPJaCoZTSWjqWQ0lYymktFUcppKTlPJaSo5 TSWnqcwGofr0Uf0nuCYNm7uD7Nvt7kab2xS4g4wrc3NxrjS5ZhuZlS/fSRpQ3DbG1bhWU8zZO5qm SrePBzZlzn7ZuhFs7WidOeeXSGMl2rESnViJnViJ3ViJvUgJ62avW8K60uuViFHOYpSzGOUsRjmL Uc5ilLMY5SxGOY9RzmOU8xjl2dx05kDZKUppdZ3xn12aLdXsNtQl1Iq3UO0jlSlllLtKtWtpdqk5 1wBN7qncG787WFuTG0e12e+BgFA461uo27e6hYp1qPJdU97uCN3/5s6aqxPBj5/W1f+hC7M9sr0h hp0vBp4aSEF4hscpSD3mXgU6/uHnl+EdIl3dt15t62vhvaUDyEA5A8/Ii8kHIOkGnRGzM9sZHDmC Vu0LSCiP9TkJFDbaGfM99B/6Uspj0Bn6NkiQy8lsLmsF/3Z5Wpq9VR1sX8cqv8R1PUbv2t70fIu8 0FVwIepLK2yX/MT0/+kSLwAV3/8RO1y0fP1/urOz0v/fxfPw9P/jwYdESoaZvroBkx/CmINKGCPw o65lS6Ip90d9WYGKyr+FeRO+641BouipDp7ZoPU539zcSl72ZsmpRC+ZjJSogXbGvUsA6E/G7+Us yULgr7JQNO9tEgpPPwa3cO9PEopbm2LSyn72RoAbUwwHUwyDdBRsN+FiX7D9dFeuoZdXk9AQgzcG nq5uS92P21IVc0kgAjqXBP7WuSRUJV4uCQTQuSTwt84lgb91LglZysolgV+sXBIxY126ZFOdyVMB D3lzwnyLX59wM1VUuDtRlKNC/iPgn/T2ORRE+CpdPKeF0O+EX518ly4aZF7Wal4L63Wav04/d0YA 2d/wXjigAl8pUJGDpgiaOqApvlKg6WLhzYV+KeyXqX7p1Vk/Uwd8s5rKIQRCCLuC1Pqc4mfof3/E 2rHUv9CALU8NIvS7cMBK0u7FgF0wh0LJgFUUVxqwqiMWiNdODFg5+MMBu1jCE2vAQlM5RDBgodH8 sz1gK13TKkqWEo7rZWeD0FyTzRSLWc0yiUmp6K2WfcDmnlOfZt6XnxlfnyivktMiJsWLhbiaEoWZ aWqN9YUyYxSMdUdCF4x1X2r/Xsb617cKVMnvEVsAiuV/Ntar3FEtSgC0Ev6fJwVRZOIM5HsEdZGi JtNAvkdQC9dFExuJ/JOQn4T1Kc0/pfJTWjMd0kB1sz07B6qXvVlYM2lSdDn7nS9eRcmcVovX50kn FZurz9VcPaowV5+ruWqP+UWTVOVz9bmcq0fWXH2ez9Xncq4eWXO1UmorqNufq8+L52qlBFjR5fgr WHy/dg/dOvnEPLNCGpoVauQTW7iySC4xzx92vsoidodZxBBjgRgLxFggxgIxFoixQIwFYiwQY4EY CxtjgRgLxFggxgIxFoixQIwFYiwQY4EYCxtjgRgLxFggxgIxFoixcDBOEeMUMU4R4xQxThHjFDFO EeMUMU4R49TGOEWMU8Q4RYxTxDhFjFPEOEWMU8Q4RYxTG+MUMU4R4xQxThHjFDFObYzDBG10XjZ8 K/CtaKr9V/Y2xbdpU22+9Ns8dZvSWyn1VEEat7qO5B/tTZPeWb2umtMNymxoEb/xul6Ot6K/oAFs o2b+t3ub9i2fA+qdsN6l+l2+AVpmejgN4WyYAUKOpCNhQzibZoCQI/FIeQtqIKO491LMNRMlW5CU 8oRzCpwr8PL0cwpcKPDyZHQKPFXg5anpFHhbgZcnqlPgHQVenrZOge8o8PIkdgp8V4GXp7RT4HsK vDzBXVNLcSUaY7WbLDIKXHG1QvI7Ba64WiEVngJXXK2QGE+BK65WSJOnwBVXKyTNU+CKqxVS6Clw xdUKCfUUuOJqhfR6ClxxtUKyvaZeWNVqFavd5LZR4IqrFRLxKXDF1Qpp+RS44mqFJH0KXHG1Qso+ Ba64upQEfkHsFZPDr6k3TUo6u5jxehKQ15OAvJ4E5PUkIK8nAXk9CcjrSUBeTwLyehKQ15OAvJ4E 5PUkIK8nAXk9CcjrSUBeTwLyehKQ15OAvJ4E5PUkIK8nAXk9CcjrSUBeTwLyShLQ2sQnkYyL8EvA L/gHtnWg+c43x7+nLIxKIR+vJNdHqq34plaDwV7YqiQtrCTfqKu9+6ZWm8F2uXjfHg2DVS8fpIYP 9/Sanmb+s3iHr1Fv5j/t/f79yTepdLfxSly26koCtj6PsFVX4rJVVxKw9TNmvtTwjr7UsBX1Bean De9oUA1bUZNgfiK8v+8R9XYmot7ORNTbmYh6OxNRb2ci6u1MRL2diai3MxH1diai3s5E1NuZiHo7 E1FvZyLq7UxEvZ2JqLczEfV2JqLezkTU25mIejsTUW9nIirtTJzle9H4d1kdt8tRquqwrelYh9q2 NEIhr+owq5y3dmdmd6xDbXgaoYznziK4ypV6t7lSy1EWdVDG8YLb3CNBoSw0ysJCObppylHeQIw3 8+lVhnRaB2kcoLgjP0oppFONdGohHd25BUhnont594HRILjgbeDlpLNMv3g6yzIMqiCAzVshlAoy Wmrr6QzhBmcqDpMsd4ZWGLBtQFtPEyurT783govCZ5PBDDPR9sHE0TuFGzbmBnSebVgnwWnqauC0 Z0WGwjyax34WTZXlFqzUiZ0ms0pmTXdgYHldyat50h3OuhYJT2ZyxMyuZF3D0+FoOMdr1YPx7Ho6 cAJQHR1/r+uAsnBjFu9Wwbj+A9p3euNk8H4wTi6vR/Ph1Qivc7qIZJRA5id16Tg5v+5Ne+P5AA1o sh9ObzTMM8BqMMc20J9ADmKMoPUHTO/7ZA6pyvoXBhoxBmBM0vTEwvwJ9u/oQ+9mRuLIU9PBGx8u hv0L2c57TPwzGhmedNH6J/tKX9Qa3SQb3w/623t7DbgfdT0bQA5cPK+bsQN2OnsABoxp4MVyM1xy rv67OfmDJNzIa3zq1wA5bew2GlDj5XDWGw3P5Xz/JjOxUXfZTwf9Hlwp3bBxfEy10FLVyJIqm1Fv NIOs2AAfDoZmcionwf9cz+bJvPdOZ82ajJPzyeQseduDVFk6X2o+49SZkfaKUB4QeR800DALHeNU 4PcDEfTA6ggv7gHAmvulMDuzLyqf0s14Mr65nFzPMMe0m1M6wX5RsxmvFFrSAUye6PmCV57nWBjD F0wxrzgwFKqyQi7YJH3rU4StOiPq0O5ElZu2LAZD2AkqDINNzEQxTSfSu5oMx+gC9PPLF8hihTRw 4TMGWUh+b2EWVs/qWT2rZ/WsntWzelbP6lk9q2f1rJ7Vs3pWz+pZPatn9ayeO33+PyIT1boAqAIA --------------Boundary-00=_ZZW7JAG32IESSE9WSPXL-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 7 19:02:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNh-0000GG-00 for ; Sun, 07 Apr 2002 22:35:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:21 +0200 (CEST) Received: (qmail 17153 invoked by uid 0); 7 Apr 2002 17:03:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 7 Apr 2002 17:03:05 -0000 Received: by moria.seul.org (Postfix) id 780D5146906; Sun, 7 Apr 2002 13:03:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7416A1468FF; Sun, 7 Apr 2002 13:03:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 5FA721468E7 for ; Sun, 7 Apr 2002 13:03:02 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uG40-0006pz-00 for f-cpu@seul.org; Sun, 7 Apr 2002 19:02:48 +0200 Date: Sun, 7 Apr 2002 19:02:48 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <001501c1de4f$e9d1ada0$2edac2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 7 Apr 2002, Christophe wrote: >> Do you think this is a good idea? IMO then you need to know >> (i.e. implement) about parts of the opcode already. The >> best method would be to just treat it as 'unknown' and >> let the emulation take control. In that case you are also >> free to add opcodes later that have not been thought of >> today, e.g. additional application specific opcodes that >> may only be implemented in few members of the f-cpu family >> or offsprings. > >In fact, whatever is the opcode, F-CPU just extracts the three fields and = give >us their contents. The opcode could never use one or two of those register= s >(one or two operands instructions) so it doesn't make a difference. It is = the >software to do whatever it wants with this info. So F-CPU really lets the >emulation take control, because it is only the emulation code which knows = what >to do with. Such a feature could be disabled or better thought. My idea is to implement nothing at all for unimplemented opcodes to be free for future changes. And unimplemented opcodes should always generate an exception. >> With f-cpu I would wish for such free opcode blocks just >> to be able to add e.g. special opcodes for grafical use >> when f-cpu is controlling a 3D grafic human interface in >> the future. Keep it free to be extendable even in ways >> that may not be very common today but may get very much >> wanted in the next 30 years (didn't YG intended that?). > >Do such free opcode blocks trigger an exception anyhow ? H=E4h? What else? Any unimplemented opcode should trigger an exception. Otherwise it would be implemented. Shrug, maybe I didn't quite understand your question? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 7 18:55:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uJNh-0000GG-01 for ; Sun, 07 Apr 2002 22:35:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Apr 2002 22:35:21 +0200 (CEST) Received: (qmail 31857 invoked by uid 0); 7 Apr 2002 17:03:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 7 Apr 2002 17:03:07 -0000 Received: by moria.seul.org (Postfix) id 8DFD41468FB; Sun, 7 Apr 2002 13:03:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CDF5146908; Sun, 7 Apr 2002 13:03:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 6DE871468FB for ; Sun, 7 Apr 2002 13:03:04 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uFwv-0006pH-00 for f-cpu@seul.org; Sun, 7 Apr 2002 18:55:29 +0200 Date: Sun, 7 Apr 2002 18:55:29 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <3CB06D39.C40CD655@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 7 Apr 2002, Ben Franchuk wrote: >Juergen Goeritz wrote: > >> With f-cpu I would wish for such free opcode blocks just >> to be able to add e.g. special opcodes for grafical use >> when f-cpu is controlling a 3D grafic human interface in >> the future. Keep it free to be extendable even in ways >> that may not be very common today but may get very much >> wanted in the next 30 years (didn't YG intended that?). > >Other than getting into the wheel of computer graphics, is not 3D >graphics better handled by a 3d video processor? Now bit fiddling for >muli-media conversion may be a useful special logic unit for >packing/unpacking operations. Ain't f-cpu perfect as the 3D video processor base? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 7 23:24:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOC-0006XI-00 for ; Mon, 08 Apr 2002 08:12:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:28 +0200 (CEST) Received: (qmail 21334 invoked by uid 0); 7 Apr 2002 21:18:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 7 Apr 2002 21:18:45 -0000 Received: by moria.seul.org (Postfix) id 0AA471468FA; Sun, 7 Apr 2002 17:18:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EFA18146906; Sun, 7 Apr 2002 17:18:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 796CF1468FA for ; Sun, 7 Apr 2002 17:18:43 -0400 (EDT) Received: from f-cpu.org (kdl11-49.n.club-internet.fr [213.44.9.49]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A081C1711 for ; Sun, 7 Apr 2002 23:18:39 +0200 (CEST) Message-ID: <3CB0B928.865D54EF@f-cpu.org> Date: Sun, 07 Apr 2002 23:24:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! cedric wrote: > Hi, > > Last week, Michael Riepe explain me how the rot and shift simd > instruction currently work in the FC0. He answers that it wasn't really a simd > shift and rotation operation. what does that mean ? > So I ask some friend to find algorithm that need rotation and that can be > easily port on a simd processor. The answer whas the rc5 algorithm from the > distributed.net project (If you don't know this project look at > www.distributed.net) . I started to port it on the FC-0 (The file that is > attached to this post contain the C ansi version of this algorithm). I > selected the rc5ansi_4-rg.cpp version who work on 4 keys in a single pass > and approximatively need 62 registers. thanks for the code ! however, i don't know if i have enough time to read it tonight (i have to setup my homebrewed LFS). > My code is currently not finished, but I have some little think to say. > First I did'nt see the need of the currently srotl.* instruction. If you > prefer, in this code, we need a srotl instruction, but I must use this > version : > %macro simdrotl 3 > shiftri 32, %1, %3 > rotl.q %2, %1, %1 > shiftri 32, %2, %2 > rotl.q %2, %3, %3 > shiftri 32, %3, %3 > or %3, %1, %1 > %endmacro i am puzzled. first i am surprised that you have to use this kind of code, i would have expected that a SIMD rotation already existed. you shouldn't have to write this kind of macro. second, i would have written this differently (remember that there is at least 1 cycle of latency for the shifts) shiftri 32, %1, %3 shiftri 32, %2, %2 // swapping this one saves some cycles rotl.q %2, %1, %1 rotl.q %2, %3, %3 shiftri 32, %3, %3 // or %3, %1, %1 // would a packing operation work here ? i am almost sure that a packing operation would avoid the last 2 instructions. But the first problem is still the most annoying : i had expected that Michael supported "real" SIMD operation. This comforts me in thinking that i have to write my on shift unit. > The other rotation operation need only immediate. And as you can see, > for the srotl, I will need more register if I want to compute 16 bits data, or > if the size of the register became bigger. (And I currently didn't find an > algorithm that use srotl as we design it). The problem is not to prove that there is (or not) an algorithm that uses a specific opcode variant, it is more : we have to design an "orthogonal" instruction set which allows all (or as many as possible) combinations of parameters. This eases the design of the core, the compiler and the applications. > An other thing about the srotl, it currently double the asm code. > It mean that, if we have a real srotl operation, we will have the same or > better performance than the K7 core (who is actually the best for this > algorithm). So my question is what is the cost of having a real srotl > instruction ? >From my point of view, it would not be really expensive. I wonder what Michael thinks about this but after all, the SHL unit is "just a bunch of multiplexers"... > The second point, is about the storem and loadm operation, > for this algorithm that saturate all the register bank, we need before the > start of the loop to save all the registers. The problem is that the storem > and loadm need actually a register that contain the number of registers to > save... That stupid, to save all the register we need to do : > storei 8, R1, R63 > loadconsx.0 62, R1 > storem R1, R2, R63 > The solution is easy : storem 63, R1, R3 ... do you mean that 2 forms of the storem instruction are needed ? if an immediate and a register form are enough, why not, though the scheduling is quite different... This is why the operands must be _all_ immediate or _all_ registers_ (otherwise it becomes really complex). don't forget however that the pointer must be in the middle position, so you would write either storem/loadm r1,[r2],r3 or storem/loadm imm8,[r2],imm6 but this forces to add an imm6 field where there is nothing yet. that's ugly. > And now, I have a question about a not really clear feature, the > size register. I didn't really understand what they say. Did they say how > many chunk divide the register ? Did they say how big the chunk are (but in > that case how many are they ?) ? Or some thing else. There are two things to consider : the size of the register and the size of the sub-parts. * When the SIMD flag is set, the register is implicitely considered as being the widest. The size attributes specify the size of the chunks. More specificly : the whole register is written back. * When there is no SIMD flag, the register size is defined by the size flags. Only the LSB of the register is written, depending on the attributes. > Why this question, only because the rc5 algorithm is really the > typical algorithm that can use big simd register (If you have 128bits > registers, you can compute 8 keys in the same pass...). But if we work in 128 > bits the srotl operation will be abolutly needed ! obviously ! > A good news for the end, 63 registers is enough (I only need one > more ;-), I think that I will find it). And our RC5 algorithm only use > register and never do any operation in memory... that really great, no other > core can compute in the same time 4 keys directly in registers. are you sure ? I'd consider IA64 as a tough competitor, here. > A+ > Cedric > > PS1: I hope that I will finish the rc5_f-cpu core for next week. I think that > coding real algorithm on F-CPU is a good start to see what we does wrong > or good. I think that I must design an other version for a F-CPU that will > have 128 bits or 256 bits registers. can you make a "generic" version that scales easily with the core's size ? by using the size flags, you should be able to find a way to do that. > PS2: Actually the main loop need 1200 instructions with a real srotl > instruction, and without it need 2300 instructions... As you can see, an instruction can influence other things : 1K2 instructions requires almost 5 Kbytes of code and a 8KB instruction cache is enough. But 2300 instructions require 9200 bytes and there would be some cache thrashing with only 8KB of cache... However, i wonder if there is a way to "factor" some code from the core and reduce the code size. there _should_ be a way to minimize this code. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : looks like i'll have to read Bruce Schneier's book for remembering how RC5 works. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 7 23:24:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOC-0006XI-01 for ; Mon, 08 Apr 2002 08:12:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:28 +0200 (CEST) Received: (qmail 11511 invoked by uid 0); 7 Apr 2002 21:18:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 7 Apr 2002 21:18:50 -0000 Received: by moria.seul.org (Postfix) id 598B1146906; Sun, 7 Apr 2002 17:18:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 483C7146910; Sun, 7 Apr 2002 17:18:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 023D9146906 for ; Sun, 7 Apr 2002 17:18:46 -0400 (EDT) Received: from f-cpu.org (kdl11-49.n.club-internet.fr [213.44.9.49]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 6B3BD1710 for ; Sun, 7 Apr 2002 23:18:43 +0200 (CEST) Message-ID: <3CB0B92B.F12C2AD2@f-cpu.org> Date: Sun, 07 Apr 2002 23:24:59 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > On Sun, 7 Apr 2002, Christophe wrote: > >In fact, whatever is the opcode, F-CPU just extracts the three fields and give > >us their contents. The opcode could never use one or two of those registers > >(one or two operands instructions) so it doesn't make a difference. It is the > >software to do whatever it wants with this info. So F-CPU really lets the > >emulation take control, because it is only the emulation code which knows what > >to do with. Such a feature could be disabled or better thought. > > My idea is to implement nothing at all for unimplemented > opcodes to be free for future changes. And unimplemented > opcodes should always generate an exception. good sense is with us this evening :-) > >> With f-cpu I would wish for such free opcode blocks just > >> to be able to add e.g. special opcodes for grafical use > >> when f-cpu is controlling a 3D grafic human interface in > >> the future. Keep it free to be extendable even in ways > >> that may not be very common today but may get very much > >> wanted in the next 30 years (didn't YG intended that?). > > > >Do such free opcode blocks trigger an exception anyhow ? > > Häh? What else? Any unimplemented opcode should trigger > an exception. Otherwise it would be implemented. Shrug, > maybe I didn't quite understand your question? i think you're ok, because - there are at least 100 free opcodes left - as you say, any unimplemented opcode traps. so it should be relatively easy to reserve 32 opcodes for later stuffs, but as a rule of thumb, it is better to do "generic" instructions that can be used many in different contexts. If it's too specific, it must be either tagged as "optional" or handed to a coprocessor... Or it must be so simple to implement that there is almost no overhead. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 7 23:23:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOD-0006XI-00 for ; Mon, 08 Apr 2002 08:12:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:29 +0200 (CEST) Received: (qmail 13404 invoked by uid 0); 7 Apr 2002 21:40:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 7 Apr 2002 21:40:48 -0000 Received: by moria.seul.org (Postfix) id 528781462F9; Sun, 7 Apr 2002 17:40:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38574146911; Sun, 7 Apr 2002 17:40:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id B36A51462F9 for ; Sun, 7 Apr 2002 17:40:46 -0400 (EDT) Received: from ifurita (213.44.156.73) by mail.laposte.net (5.5.044) id 3C9FA0F000251ACA for f-cpu@seul.org; Sun, 7 Apr 2002 23:40:45 +0200 Message-ID: <001f01c1de7a$80e740e0$499c2cd5@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Supported Instructions Date: Sun, 7 Apr 2002 23:23:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N In my mind, invalid instruction always triggers a trap. If you want to emulate some instructions (whatever you want) and be able to access the F-CPU registers to read, you can have a speed up using the possibility that an invalid instruction traps updates three SRs which will contain the contents of three registers fields of an opcode (valid or not for this opcode). So when we execute the handler it can quickly have the contents it needs to compute without need to get them from CMB. Of course we still need to update those registers in CMB if necessary. If you want to emulate an instruction without registers fields, well, just let the emulation ignores those three register operands. But okay, it is just a suggestion for the problem of a CMB not totally saved (when our three registers are not saved yet in the CMB), but, I must admit, I'm not totally convinced with this suggestion :). ----- Original Message ----- From: Juergen Goeritz To: Sent: Sunday, April 07, 2002 7:02 PM Subject: Re: [f-cpu] Supported Instructions My idea is to implement nothing at all for unimplemented opcodes to be free for future changes. And unimplemented opcodes should always generate an exception. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 7 15:29:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOD-0006XI-01 for ; Mon, 08 Apr 2002 08:12:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:29 +0200 (CEST) Received: (qmail 4636 invoked by uid 0); 7 Apr 2002 22:52:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 7 Apr 2002 22:52:16 -0000 Received: by moria.seul.org (Postfix) id E7A311462F9; Sun, 7 Apr 2002 18:52:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C563C146906; Sun, 7 Apr 2002 18:52:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a115.home.uni-hannover.de [130.75.232.115]) by moria.seul.org (Postfix) with ESMTP id CAB0E1462F9 for ; Sun, 7 Apr 2002 18:52:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00856; Sun, 7 Apr 2002 15:29:42 +0200 Message-ID: <20020407152942.33204@thrai.stud.uni-hannover.de> Date: Sun, 7 Apr 2002 15:29:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> <3CAF904C.25B11E58@f-cpu.org> <000d01c1de0c$b78f9a20$579f2cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000d01c1de0c$b78f9a20$579f2cd5@ifurita>; from Christophe on Sun, Apr 07, 2002 at 10:17:52AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 07, 2002 at 10:17:52AM +0200, Christophe wrote: [...] > > there is a problem, however : if the code is faster than the SRB mechanism, > > we'll read the old value from the CMB. worst, we could interrupt the SRB > > to resume the task, but the result can reside in a register which has not > > been "touched" by our routine. The effect is that upon return, the result > > might not be updated. > > Sorry, but it is an issue for a programmer : he/she shouldn't try to resume the > task before setting the result. Of course not - but that's not the point. When a task generates an `invalid instruction' trap, the SRB is triggered and a task switch is performed. When the interrupt handler is going to access a register for the first time, the SRB must save its contents to the CMB of the interrupted task. On return, the SRB starts again and restores all registers that have been saved/modified by the interrupt handler. If the new task reads the register's value (or performs a partial write), the SRB must also fetch the value from the current tasks CMB before the instruction is executed. That is, register values persist between handler invocations. It might be reasonable to provide two versions of the `return from exception' instruction, i.e. one that saves the handler's registers to the handler's CMB, and one that discards all changes and just restores the register values of the interrupted task. Alternatively, we could implement only the second one und use an explicit `srb_save' instruction if we need persistency. In either case, an interrupt handler must never interrupt itself, directly or indirectly, unless each invocation has its own CMB. You have to make sure that the SRB has completed (i.e. that all registers have been saved) before you can read arbitrary registers from the interrupted task. Otherwise, the CMB may contain wrong values. A register that has not been saved won't be restored either when the interrupted task resumes. For this reason, writing a new value into the CMB only works when the register has been saved; otherwise, the new value will simply be lost. That is, our hypothetical `invalid instruction' handler will have to cause the SRB to save (on entry) and reload (on return) at least all registers that are affected by the emulated instruction. Personally, I think that performing a task switch *every time* the CPU enters or leaves an interrupt/trap handler is inefficient. But I already stated that a while ago. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Apr 8 01:05:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOE-0006XI-00 for ; Mon, 08 Apr 2002 08:12:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:30 +0200 (CEST) Received: (qmail 11759 invoked by uid 0); 7 Apr 2002 23:11:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 7 Apr 2002 23:11:51 -0000 Received: by moria.seul.org (Postfix) id 6D0DC146819; Sun, 7 Apr 2002 19:11:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 58D691468FA; Sun, 7 Apr 2002 19:11:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 1325F146819 for ; Sun, 7 Apr 2002 19:11:48 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-199.jetnet.ab.ca [207.34.60.199]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id RAA25005 for ; Sun, 7 Apr 2002 17:07:44 -0600 (MDT) Message-ID: <3CB0D0B3.4AABA24E@jetnet.ab.ca> Date: Sun, 07 Apr 2002 17:05:23 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> <3CAF904C.25B11E58@f-cpu.org> <000d01c1de0c$b78f9a20$579f2cd5@ifurita> <20020407152942.33204@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Personally, I think that performing a task switch *every time* the CPU > enters or leaves an interrupt/trap handler is inefficient. But I already > stated that a while ago. I say don't use IRQ lines as HIGH SPEED DMA! instead. Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Apr 8 01:21:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOE-0006XI-01 for ; Mon, 08 Apr 2002 08:12:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:30 +0200 (CEST) Received: (qmail 20792 invoked by uid 0); 7 Apr 2002 23:21:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 7 Apr 2002 23:21:16 -0000 Received: by moria.seul.org (Postfix) id 38F0E146909; Sun, 7 Apr 2002 19:21:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 355A4146906; Sun, 7 Apr 2002 19:21:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 8F9201468EC for ; Sun, 7 Apr 2002 19:21:14 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-1.free.fr (Postfix) with ESMTP id 27458217 for ; Mon, 8 Apr 2002 01:21:14 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 0C841582A5; Mon, 8 Apr 2002 01:21:14 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018221673.3cb0d469f0a2e@imp.free.fr> Date: Mon, 08 Apr 2002 01:21:13 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> In-Reply-To: <3CB0B928.865D54EF@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 62.147.134.218 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, > what does that mean ? That mean that currently only the low part of the rotation parameter define all the rotation of the different chunk. > thanks for the code ! however, i don't know if i have enough time > to read it tonight (i have to setup my homebrewed LFS). ;-) > > %macro simdrotl 3 > > shiftri 32, %1, %3 > > rotl.q %2, %1, %1 > > shiftri 32, %2, %2 > > rotl.q %2, %3, %3 > > shiftri 32, %3, %3 > > or %3, %1, %1 > > %endmacro > > i am puzzled. > > first i am surprised that you have to use this kind of code, > i would have expected that a SIMD rotation already existed. > you shouldn't have to write this kind of macro. So you understand the problem. > second, i would have written this differently (remember > that there is at least 1 cycle of latency for the shifts) > shiftri 32, %1, %3 > shiftri 32, %2, %2 // swapping this one saves some cycles > rotl.q %2, %1, %1 > rotl.q %2, %3, %3 > shiftri 32, %3, %3 // > or %3, %1, %1 // would a packing operation work here ? Ok, not so much different. > i am almost sure that a packing operation would avoid the > last 2 instructions. What did you mean by a packing operation ? > But the first problem is still the most annoying : i had expected that > Michael supported "real" SIMD operation. This comforts me in thinking > that i have to write my on shift unit. > The problem is not to prove that there is (or not) an algorithm that uses > a specific opcode variant, it is more : we have to design an "orthogonal" > instruction set which allows all (or as many as possible) combinations > of parameters. This eases the design of the core, the compiler and the > applications. I real agry with you > From my point of view, it would not be really expensive. I wonder > what Michael thinks about this but after all, the SHL unit is "just > a bunch of multiplexers"... > > The second point, is about the storem and loadm operation, > > for this algorithm that saturate all the register bank, we need before the > > start of the loop to save all the registers. The problem is that the storem > > and loadm need actually a register that contain the number of registers to > > save... That stupid, to save all the register we need to do : > > storei 8, R1, R63 > > loadconsx.0 62, R1 > > storem R1, R2, R63 > > The solution is easy : storem 63, R1, R3 ... > do you mean that 2 forms of the storem instruction are needed ? I think, that only the immediate form is needed. > if an immediate and a register form are enough, why not, though > the scheduling is quite different... This is why the operands > must be _all_ immediate or _all_ registers_ (otherwise it becomes > really complex). > > don't forget however that the pointer must be in the middle position, > so you would write either > storem/loadm r1,[r2],r3 > or > storem/loadm imm8,[r2],imm6 "Oups", I have done a error, I mean this : storem/loadm imm6(1), imm6(2), [r3] I think that it will do : for i := imm6(1) to imm6(1) + imm6(2) do store 8, ri, [r3] done or some think like that. > but this forces to add an imm6 field where there is nothing yet. > that's ugly. A I don't understand where the imm8 came from ? We only have 63 registers, right ? > > And now, I have a question about a not really clear feature,the > > size register. I didn't really understand what they say. Did they say how > > many chunk divide the register ? Did they say how big the chunk are (but in > > that case how many are they ?) ? Or some thing else. > There are two things to consider : the size of the register and the > size of the sub-parts. > * When the SIMD flag is set, the register is implicitely considered as > being the widest. The size attributes specify the size of the chunks. > More specificly : the whole register is written back. > * When there is no SIMD flag, the register size is defined by the size flags. > Only the LSB of the register is written, depending on the attributes. Ok, it's clearer now. > > A good news for the end, 63 registers is enough (I only need one > > more ;-), I think that I will find it). And our RC5 algorithm only use > > register and never do any operation in memory... that really great, no > > other core can compute in the same time 4 keys directly in registers. > are you sure ? I'd consider IA64 as a tough competitor, here. I didn't find a specially designed core for IA64. (I must say that during a scope we need 64 registers, and not only a part of them). > > PS1: I hope that I will finish the rc5_f-cpu core for next week. I think > > that coding real algorithm on F-CPU is a good start to see what we does > > wrong or good. I think that I must design an other version for a F-CPU > > that will have 128 bits or 256 bits registers. > can you make a "generic" version that scales easily with the core's size ? > by using the size flags, you should be able to find a way to do that. I think that is not the good way to have performance, because every n keys we will call a core detect function to know on wich platform we are and then adapt our code to this platform. I think, that it's preferable to detect on wich CPU we are at start and then select the good core. (like what the current dnetc client do on x86). But why not, I didn't think to the question, but it is perhaps possible to do that easily (I only ask me about the test function, but I will see). > > PS2: Actually the main loop need 1200 instructions with a real srotl > > instruction, and without it need 2300 instructions... > As you can see, an instruction can influence other things : 1K2 > instructions requires almost 5 Kbytes of code and a 8KB instruction cache > is enough. > But 2300 instructions require 9200 bytes and there would be some cache > thrashing with only 8KB of cache... > However, i wonder if there is a way to "factor" some code from the > core and reduce the code size. there _should_ be a way to minimize this > code. I think that it is not possible, because I use all the registers and each line are different. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 8 01:47:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOG-0006XI-00 for ; Mon, 08 Apr 2002 08:12:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:32 +0200 (CEST) Received: (qmail 15566 invoked by uid 0); 7 Apr 2002 23:41:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 7 Apr 2002 23:41:24 -0000 Received: by moria.seul.org (Postfix) id C1839146833; Sun, 7 Apr 2002 19:41:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 934E61468FA; Sun, 7 Apr 2002 19:41:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 03346146833 for ; Sun, 7 Apr 2002 19:41:23 -0400 (EDT) Received: from f-cpu.org (kdl11-5.n.club-internet.fr [213.44.9.5]) by relay-2m.club-internet.fr (Postfix) with ESMTP id C1A2A16B0 for ; Mon, 8 Apr 2002 01:41:19 +0200 (CEST) Message-ID: <3CB0DA98.66C975CC@f-cpu.org> Date: Mon, 08 Apr 2002 01:47:36 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <001f01c1de7a$80e740e0$499c2cd5@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, it becomes difficult for me to keep up with the discussion. i just received posts from Michael that were sent yesterday... Christophe wrote: > In my mind, invalid instruction always triggers a trap. so we are all on the same wavelength now :-) > If you want to emulate some instructions (whatever you want) and be able to > access the F-CPU registers to read, you can have a speed up using the > possibility that an invalid instruction traps updates three SRs which will > contain the contents of three registers fields of an opcode (valid or not for > this opcode). That's a difficult thing to do because there are 5 necessary SRs (reg1 val, reg2 val, reg3 val, IP and instruction) and updating the register set upon return is not straight forward. Maybe IP is useless. For the SRs, there is only 1 port to the SR "unit" so we can't write all the fields in a single clock cycle. generating 4 write cycles to the SRs would be possible but how ugly... After the new register value is computed, we have to update the register set and it's not really easy. Self-modifying code would be better than creating an instruction that is difficult to implement and schedule : get SR_TRAP_VAL1,val1; get SR_TRAP_VAL2,val2; get SR_TRAP_VAL3,val3; get SR_TRAP_INST,rinst; get SR_TRAP_IP,IP; // jump to the routine that corresponds to the opcode // compute rs prefetch smc+2, rsmc; andi 63,rinst,rinst; // mask out all but the destination register loadcons (rs<<6),rrd; // load the immediate value that // corresponds to the instruction to overwite or rinst, rrd, rrd; // build the last part of the instruction store.16 [rsmc],rrd; // smc (expect some cycles of latency // put a jump here, just in case, to update the fetcher's buffer addi 4,IP,IP: put SR_TRAP_IP,IP; // increment the IP smc: move rs, rd; return_from_trap rrd; // restore all the dirty regs, except rrd; (here i use symbolic names for the registers). > So when we execute the handler it can quickly have the contents > it needs to compute without need to get them from CMB. it's possible and faster, but can become very difficult to implement in an architecture that doesn't look like FC0. Do you see the challenge ? > Of course we still need > to update those registers in CMB if necessary. If you want to emulate an > instruction without registers fields, well, just let the emulation ignores > those three register operands. > > But okay, it is just a suggestion for the problem of a CMB not totally saved > (when our three registers are not saved yet in the CMB), but, I must admit, I'm > not totally convinced with this suggestion :). it's still a problem and we have at least 2 means to solve it, altough they are both not pretty. But it's a beginning. i'd like to have some "code", however, before we start to hack into it. >From what Cedric said, Michael's shuffler is not a panacea... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and now ... let's go back to LFS. what compiler will we use for F-CPU ? GCC 2.95.3 or 3.0.1 ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 8 02:35:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uSOG-0006XI-01 for ; Mon, 08 Apr 2002 08:12:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:12:32 +0200 (CEST) Received: (qmail 1950 invoked by uid 0); 8 Apr 2002 00:28:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 8 Apr 2002 00:28:56 -0000 Received: by moria.seul.org (Postfix) id 4BF8F146911; Sun, 7 Apr 2002 20:28:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 48BA9146906; Sun, 7 Apr 2002 20:28:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id E477D146833 for ; Sun, 7 Apr 2002 20:28:54 -0400 (EDT) Received: from f-cpu.org (kdl11-15.n.club-internet.fr [213.44.9.15]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 16A9516AF for ; Mon, 8 Apr 2002 02:28:50 +0200 (CEST) Message-ID: <3CB0E5BB.878D4945@f-cpu.org> Date: Mon, 08 Apr 2002 02:35:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! i just read the chapter about RC5 in Bruce Schneier's book : it looks very interesting and i wonder why the code size can't be reduced ... Cedric BAIL wrote: > hi, > > > what does that mean ? > That mean that currently only the low part of the rotation parameter > define all the rotation of the different chunk. ok i see here the problem is. i think it can be solved, at least with my own SHL unit structure. > > thanks for the code ! however, i don't know if i have enough time > > to read it tonight (i have to setup my homebrewed LFS). > ;-) and i don't speak about the efforts and time required to read the list ;-P i still haven't rebooted... btw, i'm angry because KUDZU has thrashed my X configuration on the laptop. i won't' be able to use ANY graphic application before i have rebuilt LFS and X. btw, who has ever used DirectFB ? it's a small, simple and fast alternative to X11. > > > %macro simdrotl 3 > > > shiftri 32, %1, %3 > > > rotl.q %2, %1, %1 > > > shiftri 32, %2, %2 > > > rotl.q %2, %3, %3 > > > shiftri 32, %3, %3 > > > or %3, %1, %1 > > > %endmacro > > > > i am puzzled. > > > > first i am surprised that you have to use this kind of code, > > i would have expected that a SIMD rotation already existed. > > you shouldn't have to write this kind of macro. > So you understand the problem. yup and i thought that Michael had implemented a more general version. > > second, i would have written this differently (remember > > that there is at least 1 cycle of latency for the shifts) > > > shiftri 32, %1, %3 > > shiftri 32, %2, %2 // swapping this one saves some cycles > > rotl.q %2, %1, %1 > > rotl.q %2, %3, %3 > > shiftri 32, %3, %3 // > > or %3, %1, %1 // would a packing operation work here ? > Ok, not so much different. yup but from the performance point of view, there is a difference ;-) > > i am almost sure that a packing operation would avoid the > > last 2 instructions. > What did you mean by a packing operation ? look at page 129 (?) of your PDF F-CPU manual : " 2.3.4 mix MIX mixl r3, r2, r1 mixh r3, r2, r1 Mix two halves of r3 and r2 and puts the result into r1. [here is a little drawing that shows how it works] Depending on the h ag, the lower or higher part of r3 and r2 are interleaved. The size of the source chunks is determined by the size ags. This instruction is useful to interleave words in a butter y" fashion or reverse a little matrix. Or simply it can be used to create an extended form of the result of an addition with carry. " > > But the first problem is still the most annoying : i had expected that > > Michael supported "real" SIMD operation. This comforts me in thinking > > that i have to write my on shift unit. > > > The problem is not to prove that there is (or not) an algorithm that uses > > a specific opcode variant, it is more : we have to design an "orthogonal" > > instruction set which allows all (or as many as possible) combinations > > of parameters. This eases the design of the core, the compiler and the > > applications. > I real agry with you but this will solved one day, don't worry. > > > The second point, is about the storem and loadm operation, > > > for this algorithm that saturate all the register bank, we need before the > > > start of the loop to save all the registers. The problem is that the storem > > > and loadm need actually a register that contain the number of registers to > > > save... That stupid, to save all the register we need to do : > > > storei 8, R1, R63 > > > loadconsx.0 62, R1 > > > storem R1, R2, R63 > > > The solution is easy : storem 63, R1, R3 ... > > > do you mean that 2 forms of the storem instruction are needed ? > I think, that only the immediate form is needed. mmmm and what about using them for the function prolog and epilog ? two registers would contain the range of used registers and they would be saved on the stack or restored. This would make the compiler happier because there would be no determined register allocation. only the stack pointer and the low and high bounds are "fixed" (then the instruction would need automatic post-increment)... but please forget this, because it's optional and SRB must work before. We don't have a LSU yet, so it's really difficult to speak about this. > > if an immediate and a register form are enough, why not, though > > the scheduling is quite different... This is why the operands > > must be _all_ immediate or _all_ registers_ (otherwise it becomes > > really complex). > > > > don't forget however that the pointer must be in the middle position, > > so you would write either > > storem/loadm r1,[r2],r3 > > or > > storem/loadm imm8,[r2],imm6 > "Oups", I have done a error, I mean this : > storem/loadm imm6(1), imm6(2), [r3] yep, but pointers are hardwired to the middle position. > I think that it will do : > for i := imm6(1) to imm6(1) + imm6(2) do > store 8, ri, [r3] > done > > or some think like that. no, because - please don't add an adder in the Critical DataPath - your store is likely to create a trap, but storem/loadm uses the SRB which is specified to not trap. - the SRB will "snoop" the Xbar, in case a register is to be saved AND used > > but this forces to add an imm6 field where there is nothing yet. > > that's ugly. > A I don't understand where the imm8 came from ? We only have 63 registers, > right ? sure but the field in this location is an imm8 (with sign extension). the value can be truncated, however. > > > And now, I have a question about a not really clear feature,the > > > size register. I didn't really understand what they say. Did they say how > > > many chunk divide the register ? Did they say how big the chunk are (but in > > > that case how many are they ?) ? Or some thing else. > > There are two things to consider : the size of the register and the > > size of the sub-parts. > > * When the SIMD flag is set, the register is implicitely considered as > > being the widest. The size attributes specify the size of the chunks. > > More specificly : the whole register is written back. > > * When there is no SIMD flag, the register size is defined by the size flags. > > Only the LSB of the register is written, depending on the attributes. > Ok, it's clearer now. i thought it was as clear in the manual :-) > > > A good news for the end, 63 registers is enough (I only need one > > > more ;-), I think that I will find it). And our RC5 algorithm only use > > > register and never do any operation in memory... that really great, no > > > other core can compute in the same time 4 keys directly in registers. > > are you sure ? I'd consider IA64 as a tough competitor, here. > I didn't find a specially designed core for IA64. it's just a matter of time... > (I must say that during > a scope we need 64 registers, and not only a part of them). what is the block size you use ? 64-bits ? and how many rounds ? If you store the coeffs in registers, then no wonder you need so many registers. However, using postincremented loads, you can sustain your throughput. What Bruce Schneier describes is pretty simple so your implementation is probably too hairy... or optimized for a CPU which is not at all adapted to this task (and there is not only one). but i'm sure that even a SHARC DSP can do the job wihout heating. > > > PS1: I hope that I will finish the rc5_f-cpu core for next week. I think > > > that coding real algorithm on F-CPU is a good start to see what we does > > > wrong or good. I think that I must design an other version for a F-CPU > > > that will have 128 bits or 256 bits registers. > > can you make a "generic" version that scales easily with the core's size ? > > by using the size flags, you should be able to find a way to do that. > I think that is not the good way to have performance, because every n keys > we will call a core detect function to know on wich platform we are and then > adapt our code to this platform. ???? using the size flags wisely with the SIMD flag on, you SHOULD be able to do a core-width-independent code. i'm sure you can but this probably requires you to start from scratch, not from ansi or distributed.net sources. > I think, that it's preferable to detect on wich CPU we are at start and > then select the good core. (like what the current dnetc client do on x86). F-CPU can do even better. > But why not, I didn't think to the question, but it is perhaps possible to > do that easily (I only ask me about the test function, but I will see). i'm SURE RC5 can work in SIMD mode on F-CPU, including FC0. with 128-bit or 256-bit cores, it could even be able to process 2 or 4 blocks at once. a 64-bit core can code/decode a 128-bit block. i have no source code but i'm pretty confident with this gut feeling. > > > PS2: Actually the main loop need 1200 instructions with a real srotl > > > instruction, and without it need 2300 instructions... > > As you can see, an instruction can influence other things : 1K2 > > instructions requires almost 5 Kbytes of code and a 8KB instruction cache > > is enough. > > But 2300 instructions require 9200 bytes and there would be some cache > > thrashing with only 8KB of cache... > > > However, i wonder if there is a way to "factor" some code from the > > core and reduce the code size. there _should_ be a way to minimize this > > code. > I think that it is not possible, because I use all the registers and each > line are different. héhé :-P >from what my book says, you're trying to grok an already optimised code. if we restart from the definition, you'll see it's almost straight-forward. good night Petit Scarabée, > A+ > Cedric WHYGEE :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ when can we meet again and work on the manual ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 8 07:31:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uT3X-0006zu-00 for ; Mon, 08 Apr 2002 08:55:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:55:11 +0200 (CEST) Received: (qmail 23407 invoked by uid 0); 8 Apr 2002 05:43:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 8 Apr 2002 05:43:33 -0000 Received: by moria.seul.org (Postfix) id 09EE31462F9; Mon, 8 Apr 2002 01:43:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EECD81467EF; Mon, 8 Apr 2002 01:43:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B44921462F9 for ; Mon, 8 Apr 2002 01:43:28 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uRkU-0007Dh-00 for f-cpu@seul.org; Mon, 8 Apr 2002 07:31:26 +0200 Date: Mon, 8 Apr 2002 07:31:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <001f01c1de7a$80e740e0$499c2cd5@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yes, I see what you mean! But actually you could already start with f-cpu prototyping when you just have basic instructions running. Some while ago I read in an article that it would be enough to start with a bit test, a bit modify and a jump instruction. You may be able to emulate everything else with them. So why not (at least) think about this way? JG On Sun, 7 Apr 2002, Christophe wrote: >In my mind, invalid instruction always triggers a trap. > >If you want to emulate some instructions (whatever you want) and be able to >access the F-CPU registers to read, you can have a speed up using the >possibility that an invalid instruction traps updates three SRs which will >contain the contents of three registers fields of an opcode (valid or not for >this opcode). So when we execute the handler it can quickly have the contents >it needs to compute without need to get them from CMB. Of course we still need >to update those registers in CMB if necessary. If you want to emulate an >instruction without registers fields, well, just let the emulation ignores >those three register operands. > >But okay, it is just a suggestion for the problem of a CMB not totally saved >(when our three registers are not saved yet in the CMB), but, I must admit, I'm >not totally convinced with this suggestion :). > >----- Original Message ----- From: Juergen Goeritz >To: >Sent: Sunday, April 07, 2002 7:02 PM >Subject: Re: [f-cpu] Supported Instructions > >My idea is to implement nothing at all for unimplemented >opcodes to be free for future changes. And unimplemented >opcodes should always generate an exception. > > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 8 07:42:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uT3X-0006zu-01 for ; Mon, 08 Apr 2002 08:55:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:55:11 +0200 (CEST) Received: (qmail 21673 invoked by uid 0); 8 Apr 2002 05:43:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 8 Apr 2002 05:43:35 -0000 Received: by moria.seul.org (Postfix) id 9D5811467EF; Mon, 8 Apr 2002 01:43:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E9581467F5; Mon, 8 Apr 2002 01:43:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id D49501467EF for ; Mon, 8 Apr 2002 01:43:30 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uRvE-0007Dj-00 for f-cpu@seul.org; Mon, 8 Apr 2002 07:42:32 +0200 Date: Mon, 8 Apr 2002 07:42:32 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <3CB0B92B.F12C2AD2@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, On Sun, 7 Apr 2002, Yann Guidon wrote: >Juergen Goeritz wrote: >> >> With f-cpu I would wish for such free opcode blocks just >> >> to be able to add e.g. special opcodes for grafical use >> >> when f-cpu is controlling a 3D grafic human interface in >> >> the future. Keep it free to be extendable even in ways >> >> that may not be very common today but may get very much >> >> wanted in the next 30 years (didn't YG intended that?). >> > >> >Do such free opcode blocks trigger an exception anyhow ? >>=20 >> H=E4h? What else? Any unimplemented opcode should trigger >> an exception. Otherwise it would be implemented. Shrug, >> maybe I didn't quite understand your question? > >i think you're ok, because > - there are at least 100 free opcodes left > - as you say, any unimplemented opcode traps. >so it should be relatively easy to reserve 32 opcodes for later >stuffs, but as a rule of thumb, it is better to do "generic" >instructions that can be used many in different contexts. >If it's too specific, it must be either tagged as "optional" or >handed to a coprocessor... Or it must be so simple to implement >that there is almost no overhead. The coprocessor idea was e.g. used in the sparc architecture. There are two optional blocks for that purpose (co + fpu). But what I want to suggest is that there could be more 'blocks of opcodes'. As I posted in a previus reply, a simple opcode block may come with very few instructions (but don't take it as if I want you to have it implemented this way though ;) What about arranging the f-cpu opcodes in several blocks, each with the necessary functionality to run already? I do not mean by that to make the hardware inefficient. You could always implement opcodes from different 'blocks' in the same functional blocks later. It's just for the start with a 'real' running f-cpu. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 8 08:02:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uT3Y-0006zu-00 for ; Mon, 08 Apr 2002 08:55:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 08:55:12 +0200 (CEST) Received: (qmail 28990 invoked by uid 0); 8 Apr 2002 05:56:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 8 Apr 2002 05:56:56 -0000 Received: by moria.seul.org (Postfix) id BF6091462F9; Mon, 8 Apr 2002 01:56:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0CB81467F3; Mon, 8 Apr 2002 01:56:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 58AEE1462F9 for ; Mon, 8 Apr 2002 01:56:54 -0400 (EDT) Received: from f-cpu.org (kdl11-251.n.club-internet.fr [213.44.9.251]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 87EF716B4 for ; Mon, 8 Apr 2002 07:56:44 +0200 (CEST) Message-ID: <3CB1328F.92D8BE2B@f-cpu.org> Date: Mon, 08 Apr 2002 08:02:55 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 'Mojn ! Juergen Goeritz wrote: > Hi, > > On Sun, 7 Apr 2002, Yann Guidon wrote: > >Juergen Goeritz wrote: > >> >Do such free opcode blocks trigger an exception anyhow ? > >> > >> Häh? What else? Any unimplemented opcode should trigger > >> an exception. Otherwise it would be implemented. Shrug, > >> maybe I didn't quite understand your question? > > > >i think you're ok, because > > - there are at least 100 free opcodes left > > - as you say, any unimplemented opcode traps. > >so it should be relatively easy to reserve 32 opcodes for later > >stuffs, but as a rule of thumb, it is better to do "generic" > >instructions that can be used many in different contexts. > >If it's too specific, it must be either tagged as "optional" or > >handed to a coprocessor... Or it must be so simple to implement > >that there is almost no overhead. > > The coprocessor idea was e.g. used in the sparc architecture. > There are two optional blocks for that purpose (co + fpu). > > But what I want to suggest is that there could be more 'blocks > of opcodes'. As I posted in a previus reply, a simple opcode > block may come with very few instructions (but don't take it > as if I want you to have it implemented this way though ;) > > What about arranging the f-cpu opcodes in several blocks, > each with the necessary functionality to run already? > > I do not mean by that to make the hardware inefficient. You > could always implement opcodes from different 'blocks' in > the same functional blocks later. It's just for the start > with a 'real' running f-cpu. The current approach is to use ONLY symbolic names before F-CPU v.1 These opcode/name bindings are defined in a specific, user-modifiable file of the main source tree so everybody can try his definitions, test, compare, measure, propose etc... This decouples the function from the implementation. There are a lot of constraints on the opcode encoding and grouping, mainly concerning how the other fields are decoded (immediates, registers...) so we leave that to a final census and a testing script (running different boolean optimisers in parallel with different settings and proposed encodings). It is probable that a human-made, straight-forward encoding of the opcodes is under-efficient. I don't want to use the Alliance toolchain but they have a few tools (bool/boom/boog) which can give some numbers before we ask "big iron" synthesisers to make some attempts (on the best candidates found by Alliancee). But before doing that, we need the complete census of the opcodes, no ? This domain evolves quickly so speaking about that now is really premature. But keep your idea for the pre-v1 debate :-) @+ > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 8 08:54:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uTuu-0007SU-00 for ; Mon, 08 Apr 2002 09:50:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 09:50:20 +0200 (CEST) Received: (qmail 11840 invoked by uid 0); 8 Apr 2002 06:53:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 8 Apr 2002 06:53:58 -0000 Received: by moria.seul.org (Postfix) id 59C121462F9; Mon, 8 Apr 2002 02:53:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3C8781467ED; Mon, 8 Apr 2002 02:53:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id CE6F51462F9 for ; Mon, 8 Apr 2002 02:53:56 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uT2P-0007GN-00 for f-cpu@seul.org; Mon, 8 Apr 2002 08:54:01 +0200 Date: Mon, 8 Apr 2002 08:54:01 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: <3CB1328F.92D8BE2B@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 8 Apr 2002, Yann Guidon wrote: >> >i think you're ok, because >> > - there are at least 100 free opcodes left >> > - as you say, any unimplemented opcode traps. >> >so it should be relatively easy to reserve 32 opcodes for later >> >stuffs, but as a rule of thumb, it is better to do "generic" >> >instructions that can be used many in different contexts. >> >If it's too specific, it must be either tagged as "optional" or >> >handed to a coprocessor... Or it must be so simple to implement >> >that there is almost no overhead. >> >> The coprocessor idea was e.g. used in the sparc architecture. >> There are two optional blocks for that purpose (co + fpu). >> >> But what I want to suggest is that there could be more 'blocks >> of opcodes'. As I posted in a previus reply, a simple opcode >> block may come with very few instructions (but don't take it >> as if I want you to have it implemented this way though ;) >> >> What about arranging the f-cpu opcodes in several blocks, >> each with the necessary functionality to run already? >> >> I do not mean by that to make the hardware inefficient. You >> could always implement opcodes from different 'blocks' in >> the same functional blocks later. It's just for the start >> with a 'real' running f-cpu. > >The current approach is to use ONLY symbolic names before F-CPU v.1 >These opcode/name bindings are defined in a specific, user-modifiable file >of the main source tree so everybody can try his definitions, test, >compare, measure, propose etc... Ok. >This decouples the function from the implementation. There are a lot >of constraints on the opcode encoding and grouping, mainly concerning >how the other fields are decoded (immediates, registers...) so we leave >that to a final census and a testing script (running different boolean >optimisers in parallel with different settings and proposed encodings). >It is probable that a human-made, straight-forward encoding of the opcodes >is under-efficient. I don't want to use the Alliance toolchain but they >have a few tools (bool/boom/boog) which can give some numbers before >we ask "big iron" synthesisers to make some attempts (on the best candidates >found by Alliancee). > >But before doing that, we need the complete census of the opcodes, no ? >This domain evolves quickly so speaking about that now is really premature. >But keep your idea for the pre-v1 debate :-) Actually I think it's a NO here. You need a basic set of opcodes running to start. Why? Because from the history of todays processors you can extract that they did never finish their opcode range completely. Just imagine they would have waited with 8086 implementation until they had defined the MMX extension? (oops, no uproar please for mentioning that architecture again). So for when is the pre-v1 debate targeted? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 8 09:46:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uVJM-0008NI-00 for ; Mon, 08 Apr 2002 11:19:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 11:19:40 +0200 (CEST) Received: (qmail 6334 invoked by uid 0); 8 Apr 2002 07:46:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 8 Apr 2002 07:46:35 -0000 Received: by moria.seul.org (Postfix) id 7AE691467ED; Mon, 8 Apr 2002 03:46:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 543CE1467F5; Mon, 8 Apr 2002 03:46:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id EBB981467ED for ; Mon, 8 Apr 2002 03:46:31 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16uTrT-0007L2-00 for f-cpu@seul.org; Mon, 8 Apr 2002 09:46:47 +0200 Date: Mon, 8 Apr 2002 09:46:47 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >>The current approach is to use ONLY symbolic names before F-CPU v.1 >>These opcode/name bindings are defined in a specific, user-modifiable file >>of the main source tree so everybody can try his definitions, test, >>compare, measure, propose etc... > >Ok. > >>This decouples the function from the implementation. There are a lot >>of constraints on the opcode encoding and grouping, mainly concerning >>how the other fields are decoded (immediates, registers...) so we leave >>that to a final census and a testing script (running different boolean >>optimisers in parallel with different settings and proposed encodings). >>It is probable that a human-made, straight-forward encoding of the opcodes >>is under-efficient. I don't want to use the Alliance toolchain but they >>have a few tools (bool/boom/boog) which can give some numbers before >>we ask "big iron" synthesisers to make some attempts (on the best candidates >>found by Alliancee). >> >>But before doing that, we need the complete census of the opcodes, no ? >>This domain evolves quickly so speaking about that now is really premature. >>But keep your idea for the pre-v1 debate :-) > >Actually I think it's a NO here. You need a basic set of >opcodes running to start. Why? Because from the history >of todays processors you can extract that they did never >finish their opcode range completely. Just imagine they >would have waited with 8086 implementation until they had >defined the MMX extension? (oops, no uproar please for >mentioning that architecture again). > >So for when is the pre-v1 debate targeted? BTW why not implement a v0 version to evaluate these things? With use of FPGA you could already evaluate some information about the 'perfectness' of the functional blocks and opcode encodings. And just one last thought before I have to leave the house. What about using 2 stage decoding (or two clock decoding stage) to be able to convert any software side opcode view to a hardware internal opcode view? Actually it would just add another pipeline stage... ;) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 8 04:01:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGD-0003H9-00 for ; Mon, 08 Apr 2002 16:36:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:45 +0200 (CEST) Received: (qmail 23300 invoked by uid 0); 8 Apr 2002 09:29:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Apr 2002 09:29:28 -0000 Received: by moria.seul.org (Postfix) id 27B4F1467F3; Mon, 8 Apr 2002 05:29:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0DBC01467F6; Mon, 8 Apr 2002 05:29:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a072.home.uni-hannover.de [130.75.232.72]) by moria.seul.org (Postfix) with ESMTP id 289761467F3 for ; Mon, 8 Apr 2002 05:29:22 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA01055; Mon, 8 Apr 2002 04:01:07 +0200 Message-ID: <20020408040107.00515@thrai.stud.uni-hannover.de> Date: Mon, 8 Apr 2002 04:01:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> <3CAF904C.25B11E58@f-cpu.org> <000d01c1de0c$b78f9a20$579f2cd5@ifurita> <20020407152942.33204@thrai.stud.uni-hannover.de> <3CB0D0B3.4AABA24E@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CB0D0B3.4AABA24E@jetnet.ab.ca>; from Ben Franchuk on Sun, Apr 07, 2002 at 05:05:23PM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 07, 2002 at 05:05:23PM -0600, Ben Franchuk wrote: > Michael Riepe wrote: > > > Personally, I think that performing a task switch *every time* the CPU > > enters or leaves an interrupt/trap handler is inefficient. But I already > > stated that a while ago. > > I say don't use IRQ lines as HIGH SPEED DMA! instead. Fine, Ben... here is your cookie... now go back to sleep. No wait... please explain to me how to use DMA for an `invalid opcode' trap, will you? Besides that, a DMA engine will have to tell the CPU that it has finished its job - via an interrupt, unless you're willing to waste CPU time with polling status bits (in that case, you could also do the data transfer in software and use that precious silicon for something more useful). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 8 03:54:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGD-0003H9-01 for ; Mon, 08 Apr 2002 16:36:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:45 +0200 (CEST) Received: (qmail 1922 invoked by uid 0); 8 Apr 2002 09:29:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 8 Apr 2002 09:29:35 -0000 Received: by moria.seul.org (Postfix) id 1FD701467FA; Mon, 8 Apr 2002 05:29:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D96C1467F8; Mon, 8 Apr 2002 05:29:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a072.home.uni-hannover.de [130.75.232.72]) by moria.seul.org (Postfix) with ESMTP id 564DD1467F5 for ; Mon, 8 Apr 2002 05:29:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA01033; Mon, 8 Apr 2002 03:54:08 +0200 Message-ID: <20020408035408.64001@thrai.stud.uni-hannover.de> Date: Mon, 8 Apr 2002 03:54:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CB0B928.865D54EF@f-cpu.org>; from Yann Guidon on Sun, Apr 07, 2002 at 11:24:56PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 07, 2002 at 11:24:56PM +0200, Yann Guidon wrote: [...] > But the first problem is still the most annoying : i had expected that > Michael supported "real" SIMD operation. This comforts me in thinking that > i have to write my on shift unit. We already talked about the semantics of SIMD shift/rotate operations. Quoting myself (from Jan 20, 2001): BTW, I encountered another open question: when doing SIMD shifts, is the second operand a SIMD operand, too? Or will all chunks be shifted by the same number of bits? My unit will do the latter, but the former might be interesting, too. And your reply was: This question has been raised long ago, during a discussion with Thilo Reichelt. I think that the operation was called "permute" or something like that. In fact that possibilities are so large that it's difficult to make a good first decision. In particular, the SIMD words are not fixed-size and the extension to 1024 or even 65536 bits is not often straight-forward. We'll have to complete the Instruction Set Census and examine the possibilities. We have enough free room in the ISA anyway so we can add interesting extensions :-) So I decided to build the simple version first. [...] > > An other thing about the srotl, it currently double the asm code. > > It mean that, if we have a real srotl operation, we will have the same or > > better performance than the K7 core (who is actually the best for this > > algorithm). So my question is what is the cost of having a real srotl > > instruction ? > > >From my point of view, it would not be really expensive. I wonder > what Michael thinks about this but after all, the SHL unit is "just > a bunch of multiplexers"... I'll have to investigate whether the omega network shifter can perform that kind of operation at all. If it can, we'll need another set of input muxes and some additional control logic. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 8 03:37:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGE-0003H9-00 for ; Mon, 08 Apr 2002 16:36:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:46 +0200 (CEST) Received: (qmail 2983 invoked by uid 0); 8 Apr 2002 09:29:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 8 Apr 2002 09:29:43 -0000 Received: by moria.seul.org (Postfix) id BCF201467FE; Mon, 8 Apr 2002 05:29:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9ABE1467FD; Mon, 8 Apr 2002 05:29:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a072.home.uni-hannover.de [130.75.232.72]) by moria.seul.org (Postfix) with ESMTP id A62771467F6 for ; Mon, 8 Apr 2002 05:29:35 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA00985; Mon, 8 Apr 2002 03:37:11 +0200 Message-ID: <20020408033711.00830@thrai.stud.uni-hannover.de> Date: Mon, 8 Apr 2002 03:37:11 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020407165956.6B13CAB@postfix2-1.free.fr>; from cedric on Sun, Apr 07, 2002 at 11:57:35PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 07, 2002 at 11:57:35PM +0200, cedric wrote: > Hi, > > Last week, Michael Riepe explain me how the rot and shift simd > instruction currently work in the FC0. He answers that it wasn't really a simd > shift and rotation operation. Depends on your definitions of `really' and `simd' ;) > So I ask some friend to find algorithm that need rotation and that can be > easily port on a simd processor. The answer whas the rc5 algorithm from the > distributed.net project (If you don't know this project look at > www.distributed.net) . I started to port it on the FC-0 (The file that is > attached to this post contain the C ansi version of this algorithm). I > selected the rc5ansi_4-rg.cpp version who work on 4 keys in a single pass > and approximatively need 62 registers. > > My code is currently not finished, but I have some little think to say. > First I did'nt see the need of the currently srotl.* instruction. If you > prefer, in this code, we need a srotl instruction, but I must use this > version : > %macro simdrotl 3 > shiftri 32, %1, %3 > rotl.q %2, %1, %1 > shiftri 32, %2, %2 > rotl.q %2, %3, %3 > shiftri 32, %3, %3 > or %3, %1, %1 > %endmacro I guess that should read `shiftli 32, %3, %3', right? > The other rotation operation need only immediate. And as you can see, > for the srotl, I will need more register if I want to compute 16 bits data, or > if the size of the register became bigger. (And I currently didn't find an > algorithm that use srotl as we design it). Here's a 16-bit version, using slightly less than 3 instructions per slice, and only 2 registers: rotl.d %2, %1, %1 shiftri 16, %2, %2 rotri 16, %1, %1 rotl.d %2, %1, %1 shiftri 16, %2, %2 rotri 16, %1, %1 rotl.d %2, %1, %1 shiftri 16, %2, %2 rotri 16, %1, %1 rotl.d %2, %1, %1 rotr 16, %1, %1 > An other thing about the srotl, it currently double the asm code. > It mean that, if we have a real srotl operation, we will have the same or > better performance than the K7 core (who is actually the best for this > algorithm). So my question is what is the cost of having a real srotl > instruction ? A more complex shifter unit, with more delay. > The second point, is about the storem and loadm operation, > for this algorithm that saturate all the register bank, we need before the > start of the loop to save all the registers. The problem is that the storem > and loadm need actually a register that contain the number of registers to > save... That stupid, to save all the register we need to do : > storei 8, R1, R63 > loadconsx.0 62, R1 > storem R1, R2, R63 > The solution is easy : storem 63, R1, R3 ... A while ago (precisely: Aug 15, 2001), I wrote this: - The loadm/storem has a surprising operand order (start,src/dest,count), and it's not clear whether the register *numbers* or the register *contents* serve as the start/count values. I suggest the former, and I would also change the operands to (firstreg, lastreg, memaddr) which is much easier to grok for humans. Two days later, Yann replied: - whether it is the contents or the value of the address does not change much except that the value is know 2 cycles before or after. i'd prefer to use the register number than its value, though, if possible. though using the register contents might also help. That is, the first and third operand can be considered immediate operands in disguise. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Apr 8 11:51:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGF-0003H9-00 for ; Mon, 08 Apr 2002 16:36:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:47 +0200 (CEST) Received: (qmail 16840 invoked by uid 0); 8 Apr 2002 10:07:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 8 Apr 2002 10:07:15 -0000 Received: by moria.seul.org (Postfix) id 9323D146803; Mon, 8 Apr 2002 06:07:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90AE71467FD; Mon, 8 Apr 2002 06:07:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 1D3CC1467F5 for ; Mon, 8 Apr 2002 06:07:13 -0400 (EDT) Received: from ifurita (212.194.221.114) by mail.laposte.net (5.5.044) id 3CA06FFD0024E0F6 for f-cpu@seul.org; Mon, 8 Apr 2002 12:07:12 +0200 Message-ID: <002701c1dee2$e8a6b860$72ddc2d4@ifurita> From: "Christophe" To: References: <001f01c1de7a$80e740e0$499c2cd5@ifurita> <3CB0DA98.66C975CC@f-cpu.org> Subject: Re: [f-cpu] Supported Instructions Date: Mon, 8 Apr 2002 11:51:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Monday, April 08, 2002 1:47 AM Subject: Re: [f-cpu] Supported Instructions > > But okay, it is just a suggestion for the problem of a CMB not totally saved > > (when our three registers are not saved yet in the CMB), but, I must admit, I'm > > not totally convinced with this suggestion :). > > it's still a problem and we have at least 2 means to solve it, altough they > are both not pretty. But it's a beginning. It is why i'm not totally convinced by my suggestion !!! > i'd like to have some "code", however, before we start to hack into it. > From what Cedric said, Michael's shuffler is not a panacea... In fact, it doesn't matter for me to have this or not. So don't mind :). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Apr 8 14:04:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGI-0003H9-00 for ; Mon, 08 Apr 2002 16:36:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:50 +0200 (CEST) Received: (qmail 6345 invoked by uid 0); 8 Apr 2002 12:04:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 8 Apr 2002 12:04:47 -0000 Received: by moria.seul.org (Postfix) id 552FC1467F8; Mon, 8 Apr 2002 08:04:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A1F8146808; Mon, 8 Apr 2002 08:04:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 382921467F8 for ; Mon, 8 Apr 2002 08:04:44 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204081204.2300; Mon, 8 Apr 2002 12:04:35 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] SIMD register From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Apr 2002 12:04:35 GMT Message-id: <200204081204.2300@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N After reading a idct MMX code i don't think it really easy t= o use simd register without knowing there size. Such idct use 8 word ch= unk because it fill the right data. A study on theoretical cpu on a new and simple algorythme of= compiling to use vector instruction on spec program give it's maximum = around 128-256 bits register (4*64 bits float). With bigger registe= r inter register dependancies increase and code speed DECREASE. So size independant code will slow done even more the code. nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Apr 8 15:46:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uaGK-0003H9-00 for ; Mon, 08 Apr 2002 16:36:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Apr 2002 16:36:52 +0200 (CEST) Received: (qmail 32229 invoked by uid 0); 8 Apr 2002 13:48:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 8 Apr 2002 13:48:47 -0000 Received: by moria.seul.org (Postfix) id 5D212146811; Mon, 8 Apr 2002 09:48:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 39972146814; Mon, 8 Apr 2002 09:48:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 28219146811 for ; Mon, 8 Apr 2002 09:48:45 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id HAA10640 for ; Mon, 8 Apr 2002 07:48:54 -0600 (MDT) Message-ID: <3CB19F3D.7D172897@jetnet.ab.ca> Date: Mon, 08 Apr 2002 07:46:37 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Supported Instructions References: <3CAC4FEC.238D5C74@f-cpu.org> <3CADD0A6.3E9415DA@seul.org> <3CAE1770.BEEBE54C@f-cpu.org> <3CAEDC84.94408F85@ifrance.com> <3CAF2A3B.230C77FE@f-cpu.org> <001501c1dd9d$8f5682e0$0adcc2d4@ifurita> <3CAF904C.25B11E58@f-cpu.org> <000d01c1de0c$b78f9a20$579f2cd5@ifurita> <20020407152942.33204@thrai.stud.uni-hannover.de> <3CB0D0B3.4AABA24E@jetnet.ab.ca> <20020408040107.00515@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Fine, Ben... here is your cookie... now go back to sleep. I had meant using a irq with a single byte I/O device that runs at a very high speed. For example a Floppy disk controller connected to the FIRQ line of a 6809. > No wait... please explain to me how to use DMA for an `invalid opcode' > trap, will you? That is easy ... design a cpu will no invalid opcodes. :) > Besides that, a DMA engine will have to tell the CPU that it has finished > its job - via an interrupt, unless you're willing to waste CPU time with > polling status bits (in that case, you could also do the data transfer > in software and use that precious silicon for something more useful). It seems today more time is spent converting asynchronous signals from irq's/ I/O devices to synchronized virtual tasks than I/O polling every clock tick would be and having synchronization guaranteed. This might even require (Gasp) double buffering on I/O devices. Speaking of I/O devices ,a extended opcode could be a block move command with checksum generation/testing done auto - magically at the same time. More and more I think the Open-Source movement needs to start with data base/ character set formats and I/O devices as Information as well as Hardware needs to open and revised with a world wide aspect in mind. Take the assumption with the byte ( given to us by IBM in the 60's) is a good size for character data. Is that still true today? would 12, or 16 bits be better today? What about separating say computer symbols , word processing , character information , graphic and general control like NAPLPS. Now I can go back to sleep Zzz. No wait I want milk to go with that cookie. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 9 00:42:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16upsz-0005BT-01 for ; Tue, 09 Apr 2002 09:17:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:17:49 +0200 (CEST) Received: (qmail 19907 invoked by uid 0); 8 Apr 2002 22:43:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 8 Apr 2002 22:43:04 -0000 Received: by moria.seul.org (Postfix) id 2F93A1467F7; Mon, 8 Apr 2002 18:43:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 27B6A1467F0; Mon, 8 Apr 2002 18:43:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 69D601467E8 for ; Mon, 8 Apr 2002 18:43:01 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix1-2.free.fr (Postfix) with ESMTP id E324CAB22F for ; Tue, 9 Apr 2002 00:42:59 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id CBDE9FD9B; Tue, 9 Apr 2002 00:42:59 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018305779.3cb21cf3b6b10@imp3-1.free.fr> Date: Tue, 09 Apr 2002 00:42:59 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> In-Reply-To: <3CB0E5BB.878D4945@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 62.147.147.166 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > i just read the chapter about RC5 in Bruce Schneier's book : > it looks very interesting and i wonder why the code size > can't be reduced ... It's easy, we have two solutions : - or we reduce the code, we only use 31 registers and we are around 600 instructions before doing something in memory. - or we use all the register, compute 2 more keys before doing something in memory and having better performance I thing. > > > i am almost sure that a packing operation would avoid the > > > last 2 instructions. > > What did you mean by a packing operation ? > look at page 129 (?) of your PDF F-CPU manual : Ok, I look at this page, and it's exactly what I want, so I will use it for my final code. > mmmm and what about using them for the function prolog and epilog ? > two registers would contain the range of used registers and they > would be saved on the stack or restored. This would make the compiler > happier because there would be no determined register allocation. > only the stack pointer and the low and high bounds are "fixed" > (then the instruction would need automatic post-increment)... > > but please forget this, because it's optional and SRB must work before. > We don't have a LSU yet, so it's really difficult to speak about this. Ok, we will speak about it later. > > I think that it will do : > > for i := imm6(1) to imm6(1) + imm6(2) do > > store 8, ri, [r3] > > done > > or some think like that. > no, because > - please don't add an adder in the Critical DataPath The add operation is needed, and we must check if he can do is save before starting the storem/loadm, I see the problem, and the difference with the srb mechanism. > - your store is likely to create a trap, but storem/loadm uses the SRB > which is specified to not trap. Yes, but that mean that your storem/loadm only work on physical address, right? > - the SRB will "snoop" the Xbar, in case a register is to be saved AND used > i thought it was as clear in the manual :-) Yes, but not so clear. So I really ask me how to know the number of chunk, or the real size of the register. > > I didn't find a specially designed core for IA64. > it's just a matter of time... Or because nobody have this type of hardware... > what is the block size you use ? 64-bits ? and how many rounds ? > If you store the coeffs in registers, then no wonder you need so many > registers. However, using postincremented loads, you can sustain your > throughput. What Bruce Schneier describes is pretty simple so your > implementation is probably too hairy... or optimized for a CPU > which is not at all adapted to this task (and there is not only one). > but i'm sure that even a SHARC DSP can do the job wihout heating. > using the size flags wisely with the SIMD flag on, you SHOULD be able to > do a core-width-independent code. i'm sure you can but this probably > requires you to start from scratch, not from ansi or distributed.net > sources. hum, the objectif is not to recode a client from scratch, but to have the same base client and have only the specific code that perform the calcul in F-CPU asm and the core selection system perhaps. But you have at least one problem if you want to do a generic rc5 code for F-CPU you need to know how many keys you compute in a pass and how big the register are. It's really hard to do a generic algorithm (look at nicolas post). > > I think, that it's preferable to detect on wich CPU we are at start and > > then select the good core. (like what the current dnetc client do on x86). > F-CPU can do even better. So be clear : We will lost time to detect the CPU at each time the function is called (around 100 000 call). So it's not the good way to solved the problem, I will look for a good answer but at the start not during the call. > i'm SURE RC5 can work in SIMD mode on F-CPU, including FC0. with 128-bit > or 256-bit cores, it could even be able to process 2 or 4 blocks at once. > a 64-bit core can code/decode a 128-bit block. i have no source code but > i'm pretty confident with this gut feeling. I am sure too, but I wan't to see what is the difference with the 64 bits version. > > > > PS2: Actually the main loop need 1200 instructions with a real srotl > > > > instruction, and without it need 2300 instructions... > > > As you can see, an instruction can influence other things : 1K2 > > > instructions requires almost 5 Kbytes of code and a 8KB instruction cache > > > is enough. > > > But 2300 instructions require 9200 bytes and there would be some cache > > > thrashing with only 8KB of cache... > > > However, i wonder if there is a way to "factor" some code from the > > > core and reduce the code size. there _should_ be a way to minimize this > > > code. > > I think that it is not possible, because I use all the registers and each > > line are different. > héhé :-P > from what my book says, you're trying to grok an already optimised code. > if we restart from the definition, you'll see it's almost straight-forward. > good night Petit Scarabée, So, ok if we want to reduce the code needed, we will need to put data in memory and manipulate some stupid table... So I prefer to have a big code (but smaller than 8KB), than to do stupid operation in memory and not use all the register and forgot that I am not on an x86 CPU and that I have 63 registers ! A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 9 00:52:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16upt1-0005BT-00 for ; Tue, 09 Apr 2002 09:17:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:17:51 +0200 (CEST) Received: (qmail 6835 invoked by uid 0); 8 Apr 2002 22:52:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 8 Apr 2002 22:52:22 -0000 Received: by moria.seul.org (Postfix) id CA4C11467E8; Mon, 8 Apr 2002 18:52:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD7051467F0; Mon, 8 Apr 2002 18:52:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 0EA731467E8 for ; Mon, 8 Apr 2002 18:52:20 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-2.free.fr (Postfix) with ESMTP id D84B15F9E6 for ; Tue, 9 Apr 2002 00:52:16 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id BB616584AA; Tue, 9 Apr 2002 00:52:16 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018306336.3cb21f20acde6@imp.free.fr> Date: Tue, 09 Apr 2002 00:52:16 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020408033711.00830@thrai.stud.uni-hannover.de> In-Reply-To: <20020408033711.00830@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.147.147.166 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > Depends on your definitions of `really' and `simd' ;) I think that you have understand what I mean. > > version : > > %macro simdrotl 3 > > shiftri 32, %1, %3 > > rotl.q %2, %1, %1 > > shiftri 32, %2, %2 > > rotl.q %2, %3, %3 > > shiftri 32, %3, %3 > > or %3, %1, %1 > > %endmacro > > I guess that should read `shiftli 32, %3, %3', right? Oups again, yes you have right (but I will now use mix instruction) > Here's a 16-bit version, using slightly less than 3 instructions per > slice, and only 2 registers: > > rotl.d %2, %1, %1 > shiftri 16, %2, %2 > rotri 16, %1, %1 > rotl.d %2, %1, %1 > shiftri 16, %2, %2 > rotri 16, %1, %1 > rotl.d %2, %1, %1 > shiftri 16, %2, %2 > rotri 16, %1, %1 > rotl.d %2, %1, %1 > rotr 16, %1, %1 Well, we lost what %2 and %1 contain after the call. I know in my call too, but it can be a problem. > > An other thing about the srotl, it currently double the asm code. > > It mean that, if we have a real srotl operation, we will have the same or > > better performance than the K7 core (who is actually the best for this > > algorithm). So my question is what is the cost of having a real srotl > > instruction ? > A more complex shifter unit, with more delay. It was what I was thinking, but is it so important ? > A while ago (precisely: Aug 15, 2001), I wrote this: > > - The loadm/storem has a surprising operand order > (start,src/dest,count), and it's not clear whether the > register *numbers* or the register *contents* serve as the > start/count values. I suggest the former, and I would also > change the operands to (firstreg, lastreg, memaddr) which is > much easier to grok for humans. > > Two days later, Yann replied: > > - whether it is the contents or the value of the address does > not change much except that the value is know 2 cycles > before or after. i'd prefer to use the register number than > its value, though, if possible. though using the register > contents might also help. > > That is, the first and third operand can be considered immediate > operands in disguise. So, we need to patch the manual. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pgagnon30@hotmail.com Tue Apr 9 02:17:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16upt2-0005BT-01 for ; Tue, 09 Apr 2002 09:17:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:17:52 +0200 (CEST) Received: (qmail 20872 invoked by uid 0); 9 Apr 2002 00:16:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 9 Apr 2002 00:16:52 -0000 Received: by moria.seul.org (Postfix) id 257951467FC; Mon, 8 Apr 2002 20:16:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F406114680A; Mon, 8 Apr 2002 20:16:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by moria.seul.org (Postfix) with ESMTP id E81F61467FC for ; Mon, 8 Apr 2002 20:16:48 -0400 (EDT) Received: from b1eqpc42 ([65.94.73.242]) by tomts14-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020409001644.BHYC21410.tomts14-srv.bellnexxia.net@b1eqpc42> for ; Mon, 8 Apr 2002 20:16:44 -0400 From: Falkkor To: f-cpu@seul.org Subject: [f-cpu] Hello ;o) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Apr 2002 20:17:10 -0400 Message-Id: <20020409001644.BHYC21410.tomts14-srv.bellnexxia.net@b1eqpc42> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N MAKE 50,000$$$ IN LESS THAN 90 DAYS! Thank you for your time and Interest. The following income opportunity is one that can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read the enclosed program... THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ LEGITIMATE AND LEGAL THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This e-mail marketing program works perfectly...100%, EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this program now! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last few years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman Show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response - "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Ellie Gilbert. Two years ago, the corporation I worked for, the past twelve years, down-sized and my position was eliminated. After many unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $40,000.. I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life, FINANCIALLY, FOREVER!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a best selling book to make it! But, as I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725- 2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I'm telling you as it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. If you don't, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a business owner and in financial trouble, as I was, or you want to start your own business, consider this a good luck sign. I DID! Sincerely, Ellie Gilbert P.S. Do you have any idea what $58,000 looks like piled up on a kitchen table? IT'S AWESOME! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports you should have concluded that such a program, one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich". You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 16,000 programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS NOW UP TO YOU! HOW THIS AMAZING PROGRAM WORKS HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS INSTRUCTIONS: This method of raising capital REALLY WORKS 100 %, EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi- Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00CAN, or $5.00US, or $5.00EURO CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this letter and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLD WIDE WEB! SEND OUT THIS LETTER (with your name added) TO AS MANY PEOPLE AS YOU CAN, EVEN FRIENDS AND FAMILY. Advertising on the WEB can be very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/20,000 addresses or you can pay someone to take care of it for you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME- DAY SERVICE ON ALL ORDERS! This will help guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! To grow fast be prompt and courteous. ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5CAN, or $5US, or $5EURO CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA THE QUICKEST DELIVERY - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. ________________________________________________ REPORT #1 "THE INSIDER’S GUIDE TO ADVERTISING FOR FREE ON THE INTERNET " ORDER REPORT #1 FROM: De: P.Gagnon 590 De Cloridan #8 Terrebonne Qc (Canada) J6X 3A9 ---------------------------------------------------------------------------- REPORT #2 "THE INSIDER’S GUIDE TO SENDING BULK E-MAIL ON THE INTERNET « ORDER REPORT #2 FROM: De: S.Gravel 12620 Ave. Des Glaïeuls Bécancour Qc (Canada) G9H 2P2 _______________________________________________ REPORT #3 " THE SECRETS TO MULTILEVEL MARKETING ON THE INTERNET " ORDER REPORT #3 FROM: DE : D.Auger 2448 ave perrault # 4 Québec QC (Canada) G1J 3X4 ________________________________________________ REPORT #4 "HOW TO BECOME A MILLIONAIRE UTULIZING THE POWER OF MULTILEVEL MARKETING ON THE INTERNET " ORDER REPORT #4 FROM: De :N. Tajdin 26 Séville Montreal, Qc (Canada) H9B 2S5 ----------------------------------------------------------------------- HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$ ----------------------------------------------------------------------- Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5.....................$50 2nd level--10 members from those 10 ($5 x 100)........$500 3rd level--10 members from those 100 ($5 x 1,000)...$5,000 4th level--10 members from those 1,000 ($5x10,000).$50,000 THIS TOTALS ------> $55,550 Remember, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Lots of people get 100s of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE! REPORT #3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! Over 50,000, new people, get on the internet EVERYDAY (CBS NEWS)! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product (report) to comply with the U.S. Postal & Lottery Laws, Title 18, Sections 1302 and 1341 or Title 18, Section 3005 in the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Follow these guidelines to help assure your success: If you don't receive 10 to 20 orders for REPORT #1 within two weeks, continue advertising until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash can continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails and start the whole process again! There is no limit to the income you will generate from this business! PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Doris totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For a while, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this plan is that it doesn't matter where in the U.S. people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME ! DECISIVE ACTION YIELDS POWERFUL RESULTS ! NEVER SEND SPAM. IT IS BAD. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 9 04:25:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uptD-0005BT-01 for ; Tue, 09 Apr 2002 09:18:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:18:03 +0200 (CEST) Received: (qmail 18644 invoked by uid 0); 9 Apr 2002 02:19:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 9 Apr 2002 02:19:17 -0000 Received: by moria.seul.org (Postfix) id 5E69D146823; Mon, 8 Apr 2002 22:19:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3799914684E; Mon, 8 Apr 2002 22:19:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id E48C6146823 for ; Mon, 8 Apr 2002 22:19:14 -0400 (EDT) Received: from f-cpu.org (kdl16-1.n.club-internet.fr [213.44.18.1]) by relay-1m.club-internet.fr (Postfix) with ESMTP id BE5051682 for ; Tue, 9 Apr 2002 04:19:11 +0200 (CEST) Message-ID: <3CB2511A.F96F586E@f-cpu.org> Date: Tue, 09 Apr 2002 04:25:30 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020408033711.00830@thrai.stud.uni-hannover.de> <1018306336.3cb21f20acde6@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Cedric BAIL wrote: > > Here's a 16-bit version, using slightly less than 3 instructions per > > slice, and only 2 registers: > > > > rotl.d %2, %1, %1 > > shiftri 16, %2, %2 > > rotri 16, %1, %1 > > rotl.d %2, %1, %1 > > shiftri 16, %2, %2 > > rotri 16, %1, %1 > > rotl.d %2, %1, %1 > > shiftri 16, %2, %2 > > rotri 16, %1, %1 > > rotl.d %2, %1, %1 > > rotr 16, %1, %1 > Well, we lost what %2 and %1 contain after the call. I know in my call too, > but it can be a problem. another problem is that if the SHL unit has 2 cycles of latency, you'll have to find 2 other srotl macro_instructions to interleave it. I have not checked all the data dependencies, but it's going to stall the pipeline 2/3 of the time... > > > An other thing about the srotl, it currently double the asm code. > > > It mean that, if we have a real srotl operation, we will have the same or > > > better performance than the K7 core (who is actually the best for this > > > algorithm). So my question is what is the cost of having a real srotl > > > instruction ? > > A more complex shifter unit, with more delay. > It was what I was thinking, but is it so important ? if the SHL unit is still multi-purpose and othogonal, it's ok. i don't think that a shift is going to be only one cycle long, anyway. > > A while ago (precisely: Aug 15, 2001), I wrote this: > > > > - The loadm/storem has a surprising operand order > > (start,src/dest,count), and it's not clear whether the > > register *numbers* or the register *contents* serve as the > > start/count values. I suggest the former, and I would also > > change the operands to (firstreg, lastreg, memaddr) which is > > much easier to grok for humans. > > > > Two days later, Yann replied: > > > > - whether it is the contents or the value of the address does > > not change much except that the value is know 2 cycles > > before or after. i'd prefer to use the register number than > > its value, though, if possible. though using the register > > contents might also help. > > > > That is, the first and third operand can be considered immediate > > operands in disguise. > So, we need to patch the manual. hmmm yes, marking a big "don't read this silliness !" i think i shouldn't have put these instructions in the manual, it creates too many problems and misunderstandings. at least, not yet for FC0. > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 9 04:25:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uptE-0005BT-00 for ; Tue, 09 Apr 2002 09:18:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:18:04 +0200 (CEST) Received: (qmail 26282 invoked by uid 0); 9 Apr 2002 02:19:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 9 Apr 2002 02:19:22 -0000 Received: by moria.seul.org (Postfix) id 1E6E41468D3; Mon, 8 Apr 2002 22:19:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BD9614686B; Mon, 8 Apr 2002 22:19:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id CBD6314684E for ; Mon, 8 Apr 2002 22:19:19 -0400 (EDT) Received: from f-cpu.org (kdl16-1.n.club-internet.fr [213.44.18.1]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 581A11687 for ; Tue, 9 Apr 2002 04:19:16 +0200 (CEST) Message-ID: <3CB2511F.4EF1AA3A@f-cpu.org> Date: Tue, 09 Apr 2002 04:25:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] SIMD register References: <200204081204.2300@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > After reading a idct MMX code i don't think it really easy to use simd > register without knowing there size. Such idct use 8 word chunk because > it fill the right data. if you read Intel's documents, or code designed for Intel computers, i understand your doubts. However, some Zen, a clear and clean mind and some patience will help you read the "basic" books in a different way. I have already started writing a DCT code, optimised for F-CPU. It is surprisingly easy when you know a few tricks. And more importantly, i had started from an already good-looking code, so it was almost straight-forward. > A study on theoretical cpu on a new and simple algorythme of compiling > to use vector instruction on spec program give it's maximum around > 128-256 bits register (4*64 bits float). With bigger register inter > register dependancies increase and code speed DECREASE. > > So size independant code will slow done even more the code. I don't agree with you because you assume that the study is perfect. It is based on prototype code, in very specific conditions and the algo is probably badly chosen. Add to that that the memory system is probably not adapted, and you see that this is probably a misleading result. Don't forget that in the past, most people said "32-bit registers are too wide, we don't need all these bits" or "8 registers are enough for any algorithm". Since then , the balance and architecture of the computers have radically changed : it's not wise to say that we won't need 256-bit registers in the future. If the use of embedded DRAM increases, your study might well become a geek's joke. Most importantly, nobody today writes code that is independent from the platform (except in C where the size of the ints is unknown). So it's easy to say now that size-independent code is not worth. However, with a few programming habits, you could write once a code that can be executed as is and as fast as possible on any compliant platform. It's "just" a matter of complying with a programming model, so you don't have to touch old code. I think that FC0 is easily scalable to 256-bits and 2 instructions per cycle. when such a CPU will be implemented, we will have already started FC1, i guess. But we will have to deal with 3 kinds of codes, if i follow your idea correctly. There is however a simpler solution : in computation-intensive code (or bandwidth-stressing code), use the maximum width register (in SIMD mode). execute a "get SR_MAX_SIZE, rd" and divide your loop counter by rd (or play with the loop counter, substracting rd instead of just 1). This way, your code can compile and execute on any version of the CPU. I don't think it's too complex to do. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 9 04:25:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uptF-0005BT-00 for ; Tue, 09 Apr 2002 09:18:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 09:18:05 +0200 (CEST) Received: (qmail 1694 invoked by uid 0); 9 Apr 2002 02:19:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Apr 2002 02:19:27 -0000 Received: by moria.seul.org (Postfix) id F15CA14686B; Mon, 8 Apr 2002 22:19:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDE8A146865; Mon, 8 Apr 2002 22:19:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 4A45C146844 for ; Mon, 8 Apr 2002 22:19:25 -0400 (EDT) Received: from f-cpu.org (kdl16-1.n.club-internet.fr [213.44.18.1]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 9AC121682 for ; Tue, 9 Apr 2002 04:19:21 +0200 (CEST) Message-ID: <3CB25124.AF25C366@f-cpu.org> Date: Tue, 09 Apr 2002 04:25:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! This mailing list becomes difficult to follow... but here i am anyway. I don't know if i can answer other posts. Cedric BAIL wrote: > > i just read the chapter about RC5 in Bruce Schneier's book : > > it looks very interesting and i wonder why the code size > > can't be reduced ... > It's easy, we have two solutions : > - or we reduce the code, we only use 31 registers and we are around 600 > instructions before doing something in memory. it''s NOT about not using memory or not using registers. In an usual case, you would have 4KB of dedicated instruction and data caches. maybe more, maybe less. If you put some data (the added constants generated by the key) in L1, you free some registers that can be used for pointing memory "streams", so there is a _continuous_ flow of data through the CPU, _NOT_ "bursts" every 600 cycles or so. usually, the memory system won't keep up and you'll slow down all the system. I think it's possible to find a compromise with maybe 500 or 800 instructions, leaving enough space in L1 for some other useful code. > - or we use all the register, compute 2 more keys before doing something > in memory and having better performance I thing. today, performance is also (like in the 70s) constrained by the memory. in today's systems, you can have a bandwidth of less than one byte per instruction (provided the instruction is already in Icache and we hit L2 or the local SDRAM). You HAVE to interleave memory accesses (by small chunks) and computations. Otherwise, your nicely optimised code will runn during 600 cycles and stall almost completely another 600 cycles. > > > > i am almost sure that a packing operation would avoid the > > > > last 2 instructions. > > > What did you mean by a packing operation ? > > look at page 129 (?) of your PDF F-CPU manual : > Ok, I look at this page, and it's exactly what I want, so I will > use it for my final code. do you trust me, now ? :-P > > but please forget this, because it's optional and SRB must work before. > > We don't have a LSU yet, so it's really difficult to speak about this. > Ok, we will speak about it later. so ... > > i thought it was as clear in the manual :-) > Yes, but not so clear. So I really ask me how to know the number of chunk, > or the real size of the register. you can also look at some examples in the manual (instruction set part). > > > I didn't find a specially designed core for IA64. > > it's just a matter of time... > Or because nobody have this type of hardware... or because when you can afford one, you can afford a dedicated RC5 HW ;-) > > what is the block size you use ? 64-bits ? and how many rounds ? > > If you store the coeffs in registers, then no wonder you need so many > > registers. However, using postincremented loads, you can sustain your > > throughput. What Bruce Schneier describes is pretty simple so your > > implementation is probably too hairy... or optimized for a CPU > > which is not at all adapted to this task (and there is not only one). > > but i'm sure that even a SHARC DSP can do the job wihout heating. > > > using the size flags wisely with the SIMD flag on, you SHOULD be able to > > do a core-width-independent code. i'm sure you can but this probably > > requires you to start from scratch, not from ansi or distributed.net > > sources. > hum, the objectif is not to recode a client from scratch, but to have the > same base client and have only the specific code that perform the calcul > in F-CPU asm and the core selection system perhaps. i'm not speaking about recoding the *client*, only the decoding algo. > But you have at least one problem if you want to do a generic rc5 code for > F-CPU you need to know how many keys you compute in a pass and how big > the register are. It's really hard to do a generic algorithm (look at nicolas > post). if you start from the inner loop, there should be no problem. You then propagate all the constraints to the client : platform detection, tuning of the keys... and since you have the sources, you can make your own f-cpu patch. > > > I think, that it's preferable to detect on wich CPU we are at start and > > > then select the good core. (like what the current dnetc client do on x86). > > F-CPU can do even better. > So be clear : We will lost time to detect the CPU at each time the function > is called (around 100 000 call). So it's not the good way to solved the > problem, I will look for a good answer but at the start not during the call. heh, i thought you were wiser ;-) there is a simple way to do your thing in C : void compute_1() { **** } void compute_2() { **** } void compute_3() { **** } void compute_ptr() = &compute_1; int main () { // detect platform version if (CPU_TYPE == TYPE_2) compute_ptr = &compute_2; else { if (CPU_TYPE == TYPE_3) compute_ptr = &compute_3; // else : default code } for (i=0; i > i'm SURE RC5 can work in SIMD mode on F-CPU, including FC0. with 128-bit > > or 256-bit cores, it could even be able to process 2 or 4 blocks at once. > > a 64-bit core can code/decode a 128-bit block. i have no source code but > > i'm pretty confident with this gut feeling. > I am sure too, but I wan't to see what is the difference with the 64 bits > version. version of what ? RC5 or F-CPU ? > > > > However, i wonder if there is a way to "factor" some code from the > > > > core and reduce the code size. there _should_ be a way to minimize this > > > > code. > > > I think that it is not possible, because I use all the registers and each > > > line are different. > > héhé :-P > > from what my book says, you're trying to grok an already optimised code. > > if we restart from the definition, you'll see it's almost straight-forward. > > good night Petit Scarabée, > So, ok if we want to reduce the code needed, we will need to put data in > memory and manipulate some stupid table... if you mean "simple" table, it's ok. If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of cache. for 128-bit blocks, you need 2KB of data cache. Because the rounds use sequential, linear access, there is no cache penalty (there should be some auto-prefetching of the next cache line). Furthermore, if you decode several blocks at once (for example, a 64-bit core with 64-bit blocks), you can do : loadi.64 8, [rp], rd; sdupi.32 0, rd, r1; sdupi.32 1, rd, r2; // or something like that --> you execute only one load and you get 4 32-bit values in 2 registers with 3 instructions. > So I prefer to have a big code (but > smaller than 8KB), than to do stupid operation in memory and not use all the > register and forgot that I am not on an x86 CPU and that I have 63 registers ! i think you are mistaken : the goal is not to use ALL the registers. There are other things that come into the game, such as the time it takes to load and store the whole damn register set. Some computations are less memory intensive and might be happy to spread in the whole register set. RC5 is not "intensive" but this becomes a bottleneck if you don't take care of the steadiness of the memory streams. It takes quite a while to dump/flush 512 bytes. Don't forget that the core often runs 10x faster than the memory system. If we ever find some time to meet, we'll read the documents and draft some code together, i'll show you some tricks. read you soon, > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Apr 9 14:53:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uwyh-0001vR-00 for ; Tue, 09 Apr 2002 16:52:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 16:52:11 +0200 (CEST) Received: (qmail 30519 invoked by uid 0); 9 Apr 2002 12:53:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Apr 2002 12:53:29 -0000 Received: by moria.seul.org (Postfix) id C57441468D8; Tue, 9 Apr 2002 08:53:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9F691468DB; Tue, 9 Apr 2002 08:53:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 0C39A1468D8 for ; Tue, 9 Apr 2002 08:53:25 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204091253.0db0; Tue, 9 Apr 2002 12:53:13 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] SIMD register From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Apr 2002 12:53:13 GMT Message-id: <200204091253.0db0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 09/04/02 Objet: Re: [f-cpu] SIMD register hi, Nicolas Boulay wrote: > After reading a idct MMX code i don't think it really easy= to use simd > register without knowing there size. Such idct use 8 word = chunk because > it fill the right data. if you read Intel's documents, or code designed for Intel co= mputers, i understand your doubts. However, some Zen, a clear and cle= an mind and some patience will help you read the "basic" books in a = different way. >>> nop ! It's from the ffmpeg project. I have already started writing a DCT code, optimised for F-C= PU. It is surprisingly easy when you know a few tricks. And more importantly, i had started from an already good-looking code, so it was a= lmost straight-forward. > A study on theoretical cpu on a new and simple algorythme = of compiling > to use vector instruction on spec program give it's maximu= m around > 128-256 bits register (4*64 bits float). With bigger regis= ter inter > register dependancies increase and code speed DECREASE. >=20 > So size independant code will slow done even more the code= . I don't agree with you because you assume that the study is = perfect. It is based on prototype code, in very specific conditions a= nd the algo is probably badly chosen. Add to that that the memory system= is probably not adapted, and you see that this is probably a misleading = result. Don't forget that in the past, most people said "32-bit regi= sters are too wide, we don't need all these bits" or "8 registers = are enough for any algorithm". Since then , the balance and architectur= e of the computers have radically changed : it's not wise to say that we won't = need 256-bit >>>That's the all pupose argument. registers in the future. If the use of embedded DRAM increas= es, your study might well become a geek's joke. >>> ??? If you use embedded DRAM, you will increase memory b= andwith (comparre to external one) so i don't understand you're poin= t. Most importantly, nobody today writes code that is independe= nt from the platform (except in C where the size of the ints is unkn= own). >>> You should say exactly the opposit : nobody write a code= for a specific plateforme. That's the success of Java. That's the = marketing of .net. When you write in C you try to be as portable as possible. You always think about asm but it's only for the core of som= e codec to increase speed. Nowadays, even DSP code are written in C bec= ause of the complexity of the traitements. A good C compiler that could = vectorise as for the next version of gcc or the future compiler based on = Trimaran will do the job. So you won't need to write code by hand any= more. So it's easy to say now that size-independent code is not wo= rth. However, with a few programming habits, you could write once= a code that can be executed as is and as fast as possible on a= ny compliant platform. It's "just" a matter of complying with a programmi= ng model, so you don't have to touch old code. I think that FC0 is easily scalable to 256-bits and 2 instru= ctions per cycle. when such a CPU will be implemented, we will have already st= arted FC1, i guess. But we will have to deal with 3 kinds of codes, if i follow = your idea correctly. There is however a simpler solution : in computation-intensi= ve code (or bandwidth-stressing code), use the maximum width registe= r (in SIMD mode). >>> That's the binary compatibility. With a good C compiler = you don't need it. Binary compatibility aren't usefull in the world of= free software and open-sources. ;p execute a "get SR_MAX_SIZE, rd" and divide your loop counter= by rd (or play with the loop counter, substracting rd instead of j= ust 1). This way, your code can compile and execute on any version o= f the CPU. I don't think it's too complex to do. >>> It is ! You suggest that's all application have this for= m : for i c[i]=3Df(a[i],b[i]) But the general case are : for i c[g(i)]=3Df(a[h(i)],b[k(i)]) This case could be diffucult or impossible to vectorise. Dep= ending on g() h() and k() it could add some dependancies (for example = if a=3D=3Dc !!). In the mathematical traitement look at the problem of small = matrix, if you manipulate 8x8 of them and 8 words fit on a register wha= t happen to the algorithme when the register size double ? You lose the = coherency ! If you read each time the SR to know how many register you g= et, you will lose lot of time ! nicO > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Apr 9 15:14:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uwyi-0001vR-00 for ; Tue, 09 Apr 2002 16:52:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 16:52:12 +0200 (CEST) Received: (qmail 32484 invoked by uid 0); 9 Apr 2002 13:14:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 9 Apr 2002 13:14:42 -0000 Received: by moria.seul.org (Postfix) id AD57C1467F9; Tue, 9 Apr 2002 09:14:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C9731468D9; Tue, 9 Apr 2002 09:14:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id E98701467F9 for ; Tue, 9 Apr 2002 09:14:40 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204091314.1dc5; Tue, 9 Apr 2002 13:14:29 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] RC5, F-CPU and srotl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Apr 2002 13:14:29 GMT Message-id: <200204091314.1dc5@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I think that it will do : > > for i :=3D imm6(1) to imm6(1) + imm6(2) do > > store 8, ri, [r3] > > done > > or some think like that. > no, because > - please don't add an adder in the Critical DataPath The add operation is needed, and we must check if he can do = is save before starting the storem/loadm, I see the problem, and the differ= ence with the srb mechanism. >>> I forget to speak about that in my later email. Firstly,= i had argred with Whygee to remove all adder in the critical data = path to reduice at the minimum this cdp. So the latency for common i= nstructions will be reduice. BUT without such adder in "many" case it signify adding a ne= w instruction to do the jobs. So it's increase the code size (= i have understood that it's the main fear of Christophe about Fcpu = ISA). But it add a RAW dependancies, too, the worst one. And it increase = the register pressure (because a temporary register is needed). >From an other point of view, we could see that we reduice th= e average cpi of the fcpu compare to other cpu. That's not really the = good way to add mips to our core. The question is to quantify how many times we will see such = construct in typical code compare to the gain of 1 pipeline stage. nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 9 17:10:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uzQT-0003kv-00 for ; Tue, 09 Apr 2002 19:29:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 19:29:01 +0200 (CEST) Received: (qmail 6554 invoked by uid 0); 9 Apr 2002 15:10:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 9 Apr 2002 15:10:38 -0000 Received: by moria.seul.org (Postfix) id 735A3146806; Tue, 9 Apr 2002 11:10:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69F811468DC; Tue, 9 Apr 2002 11:10:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id D5F8A146806 for ; Tue, 9 Apr 2002 11:10:36 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-2.free.fr (Postfix) with ESMTP id DFABF5FBC6 for ; Tue, 9 Apr 2002 17:10:35 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id D1F948C195; Tue, 9 Apr 2002 17:10:35 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018365035.3cb3046bc7646@imp.free.fr> Date: Tue, 09 Apr 2002 17:10:35 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> In-Reply-To: <3CB25124.AF25C366@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > hi ! > > This mailing list becomes difficult to follow... but here i am > anyway. I don't know if i can answer other posts. Sorry ;-) > Cedric BAIL wrote: > > > i just read the chapter about RC5 in Bruce Schneier's book : > > > it looks very interesting and i wonder why the code size > > > can't be reduced ... > > It's easy, we have two solutions : > > - or we reduce the code, we only use 31 registers and we are around 600 > > instructions before doing something in memory. > it''s NOT about not using memory or not using registers. > In an usual case, you would have 4KB of dedicated instruction and data caches. > maybe more, maybe less. If you put some data (the added constants generated > by the key) in L1, you free some registers that can be used for pointing > memory "streams", so there is a _continuous_ flow of data through the CPU, > _NOT_ "bursts" every 600 cycles or so. usually, the memory system won't > keep up and you'll slow down all the system. I think it's possible to find > a compromise with maybe 500 or 800 instructions, leaving enough space in L1 > for some other useful code. So ok, I wasn't clear. I code my rc5 functions so that we do something like 20000 cycles (computes 40 keys) before doing any operation in DCache and the core must stay during the main loop in ICache. So the presure on memory will be very small and I imagin that will increase speed. I will save the registers at start and restore them at the end. In each case I will lost a lot of time, but the data will style stay in DCache so it's not a problem. At least, I think that you must look to the _4.cpp rc5 ansi core. You will more easily understand what I mean. > > - or we use all the register, compute 2 more keys before doing something > > in memory and having better performance I thing. > today, performance is also (like in the 70s) constrained by the memory. > in today's systems, you can have a bandwidth of less than one byte per > instruction (provided the instruction is already in Icache and we hit L2 or > the local SDRAM). > You HAVE to interleave memory accesses (by small chunks) and computations. > Otherwise, your nicely optimised code will runn during 600 cycles and > stall almost completely another 600 cycles. Don't forget, my main loop will take 1200 instructions... And a loop is for looping ;-) > > > > I didn't find a specially designed core for IA64. > > > it's just a matter of time... > > Or because nobody have this type of hardware... > or because when you can afford one, you can afford a dedicated RC5 HW > ;-) The objectif of the distributed.net project is not to say : buy a new core, but use your cpu to do... > i'm not speaking about recoding the *client*, only the decoding algo. It's what I speak about... > if you start from the inner loop, there should be no problem. > You then propagate all the constraints to the client : platform detection, > tuning of the keys... and since you have the sources, you can make > your own f-cpu patch. The problem is in the test. You must do a test for each chunk... > there is a simple way to do your thing in C : Grrr, I know howto use pointer on function ;-) > Is it too difficult to do ? > > I am sure too, but I wan't to see what is the difference with the 64 > > bits version. > version of what ? RC5 or F-CPU ? A the RC5 version never change, it came from the dnetc projet ;-) > > So, ok if we want to reduce the code needed, we will need to put data in > > memory and manipulate some stupid table... > if you mean "simple" table, it's ok. Yes, nut it's not ok. I didn't wan't to access to memory when I can stay in register. > If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of > cache. for 128-bit blocks, you need 2KB of data cache. > Because the rounds use sequential, linear access, there is no cache > penalty (there should be some auto-prefetching of the next cache line). I think that you didn't look to the file I gave to you... > Furthermore, if you decode several blocks at once (for example, a 64-bit > core with 64-bit blocks), you can do : > loadi.64 8, [rp], rd; > sdupi.32 0, rd, r1; > sdupi.32 1, rd, r2; // or something like that > --> you execute only one load and you get 4 32-bit values > in 2 registers with 3 instructions. euh, sory but what are you doing here ? > > So I prefer to have a big code (but smaller than 8KB), than to do stupid > > operation in memory and not use all the > > register and forgot that I am not on an x86 CPU and that I have 63 > > registers ! > i think you are mistaken : the goal is not to use ALL the registers. > There are other things that come into the game, such as the time it > takes to load and store the whole damn register set. Some computations are > less memory intensive and might be happy to spread in the whole register > set. If I save and restore this register only after 20000 cycles or more, and if I didn't use the L1 cache during all this cycle, where is the problem ? > RC5 is not "intensive" but this becomes a bottleneck if you don't take > care of the steadiness of the memory streams. It takes quite a while > to dump/flush 512 bytes. Don't forget that the core > often runs 10x faster than the memory system. It's why I want to stay in register. > If we ever find some time to meet, we'll read the documents and draft > some code together, i'll show you some tricks. And me too ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 9 17:12:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16uzQU-0003kv-00 for ; Tue, 09 Apr 2002 19:29:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 19:29:02 +0200 (CEST) Received: (qmail 29222 invoked by uid 0); 9 Apr 2002 15:12:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Apr 2002 15:12:10 -0000 Received: by moria.seul.org (Postfix) id 72A041468DB; Tue, 9 Apr 2002 11:12:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 578071468E0; Tue, 9 Apr 2002 11:12:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id D59091468DB for ; Tue, 9 Apr 2002 11:12:08 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 76C0E6F1 for ; Tue, 9 Apr 2002 17:12:05 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id DDB848C195; Tue, 9 Apr 2002 17:12:04 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018365124.3cb304c4c79df@imp.free.fr> Date: Tue, 09 Apr 2002 17:12:04 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> In-Reply-To: <3CB25124.AF25C366@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.42 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > hi ! > > This mailing list becomes difficult to follow... but here i am > anyway. I don't know if i can answer other posts. Sorry ;-) > Cedric BAIL wrote: > > > i just read the chapter about RC5 in Bruce Schneier's book : > > > it looks very interesting and i wonder why the code size > > > can't be reduced ... > > It's easy, we have two solutions : > > - or we reduce the code, we only use 31 registers and we are around 600 > > instructions before doing something in memory. > it''s NOT about not using memory or not using registers. > In an usual case, you would have 4KB of dedicated instruction and data caches. > maybe more, maybe less. If you put some data (the added constants generated > by the key) in L1, you free some registers that can be used for pointing > memory "streams", so there is a _continuous_ flow of data through the CPU, > _NOT_ "bursts" every 600 cycles or so. usually, the memory system won't > keep up and you'll slow down all the system. I think it's possible to find > a compromise with maybe 500 or 800 instructions, leaving enough space in L1 > for some other useful code. So ok, I wasn't clear. I code my rc5 functions so that we do something like 20000 cycles (computes 40 keys) before doing any operation in DCache and the core must stay during the main loop in ICache. So the presure on memory will be very small and I imagin that will increase speed. I will save the registers at start and restore them at the end. In each case I will lost a lot of time, but the data will style stay in DCache so it's not a problem. At least, I think that you must look to the _4.cpp rc5 ansi core. You will more easily understand what I mean. > > - or we use all the register, compute 2 more keys before doing something > > in memory and having better performance I thing. > today, performance is also (like in the 70s) constrained by the memory. > in today's systems, you can have a bandwidth of less than one byte per > instruction (provided the instruction is already in Icache and we hit L2 or > the local SDRAM). > You HAVE to interleave memory accesses (by small chunks) and computations. > Otherwise, your nicely optimised code will runn during 600 cycles and > stall almost completely another 600 cycles. Don't forget, my main loop will take 1200 instructions... And a loop is for looping ;-) > > > > I didn't find a specially designed core for IA64. > > > it's just a matter of time... > > Or because nobody have this type of hardware... > or because when you can afford one, you can afford a dedicated RC5 HW > ;-) The objectif of the distributed.net project is not to say : buy a new core, but use your cpu to do... > i'm not speaking about recoding the *client*, only the decoding algo. It's what I speak about... > if you start from the inner loop, there should be no problem. > You then propagate all the constraints to the client : platform detection, > tuning of the keys... and since you have the sources, you can make > your own f-cpu patch. The problem is in the test. You must do a test for each chunk... > there is a simple way to do your thing in C : Grrr, I know howto use pointer on function ;-) > Is it too difficult to do ? > > I am sure too, but I wan't to see what is the difference with the 64 > > bits version. > version of what ? RC5 or F-CPU ? A the RC5 version never change, it came from the dnetc projet ;-) > > So, ok if we want to reduce the code needed, we will need to put data in > > memory and manipulate some stupid table... > if you mean "simple" table, it's ok. Yes, nut it's not ok. I didn't wan't to access to memory when I can stay in register. > If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of > cache. for 128-bit blocks, you need 2KB of data cache. > Because the rounds use sequential, linear access, there is no cache > penalty (there should be some auto-prefetching of the next cache line). I think that you didn't look to the file I gave to you... > Furthermore, if you decode several blocks at once (for example, a 64-bit > core with 64-bit blocks), you can do : > loadi.64 8, [rp], rd; > sdupi.32 0, rd, r1; > sdupi.32 1, rd, r2; // or something like that > --> you execute only one load and you get 4 32-bit values > in 2 registers with 3 instructions. euh, sory but what are you doing here ? > > So I prefer to have a big code (but smaller than 8KB), than to do stupid > > operation in memory and not use all the > > register and forgot that I am not on an x86 CPU and that I have 63 > > registers ! > i think you are mistaken : the goal is not to use ALL the registers. > There are other things that come into the game, such as the time it > takes to load and store the whole damn register set. Some computations are > less memory intensive and might be happy to spread in the whole register > set. If I save and restore this register only after 20000 cycles or more, and if I didn't use the L1 cache during all this cycle, where is the problem ? > RC5 is not "intensive" but this becomes a bottleneck if you don't take > care of the steadiness of the memory streams. It takes quite a while > to dump/flush 512 bytes. Don't forget that the core > often runs 10x faster than the memory system. It's why I want to stay in register. > If we ever find some time to meet, we'll read the documents and draft > some code together, i'll show you some tricks. And me too ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 9 19:16:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16v1jO-0005T2-00 for ; Tue, 09 Apr 2002 21:56:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Apr 2002 21:56:42 +0200 (CEST) Received: (qmail 24057 invoked by uid 0); 9 Apr 2002 17:10:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 9 Apr 2002 17:10:20 -0000 Received: by moria.seul.org (Postfix) id 9C466146865; Tue, 9 Apr 2002 13:10:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85D5A1468E0; Tue, 9 Apr 2002 13:10:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 35C13146865 for ; Tue, 9 Apr 2002 13:10:18 -0400 (EDT) Received: from f-cpu.org (kdl11-27.n.club-internet.fr [213.44.9.27]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 511FE1737 for ; Tue, 9 Apr 2002 19:10:13 +0200 (CEST) Message-ID: <3CB321F0.93FCD9BE@f-cpu.org> Date: Tue, 09 Apr 2002 19:16:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, Cedric BAIL wrote: > Hi, > > hi ! > > > > This mailing list becomes difficult to follow... but here i am > > anyway. I don't know if i can answer other posts. > Sorry ;-) but finally i prefer to answer your posts, they are more instructive than others ;-) > > Cedric BAIL wrote: > > > > i just read the chapter about RC5 in Bruce Schneier's book : > > > > it looks very interesting and i wonder why the code size > > > > can't be reduced ... > > > It's easy, we have two solutions : > > > - or we reduce the code, we only use 31 registers and we are around 600 > > > instructions before doing something in memory. > > it''s NOT about not using memory or not using registers. > > In an usual case, you would have 4KB of dedicated instruction and data caches. > > maybe more, maybe less. If you put some data (the added constants generated > > by the key) in L1, you free some registers that can be used for pointing > > memory "streams", so there is a _continuous_ flow of data through the CPU, > > _NOT_ "bursts" every 600 cycles or so. usually, the memory system won't > > keep up and you'll slow down all the system. I think it's possible to find > > a compromise with maybe 500 or 800 instructions, leaving enough space in L1 > > for some other useful code. > So ok, I wasn't clear. I code my rc5 functions so that we do something like > 20000 cycles (computes 40 keys) before doing any operation in DCache and the > core must stay during the main loop in ICache. So the presure on memory > will be very small and I imagin that will increase speed. I will save the > registers at start and restore them at the end. In each case I will lost > a lot of time, but the data will style stay in DCache so it's not a problem. > > At least, I think that you must look to the _4.cpp rc5 ansi core. You will > more easily understand what I mean. i see things like ROUND3EVEN (S1_02, S2_02, S3_02, S4_02); ROUND3ODD (S1_03, S2_03, S3_03, S4_03); ROUND3EVEN (S1_04, S2_04, S3_04, S4_04); ROUND3ODD (S1_05, S2_05, S3_05, S4_05); ROUND3EVEN (S1_06, S2_06, S3_06, S4_06); ROUND3ODD (S1_07, S2_07, S3_07, S4_07); ROUND3EVEN (S1_08, S2_08, S3_08, S4_08); ROUND3ODD (S1_09, S2_09, S3_09, S4_09); ROUND3EVEN (S1_10, S2_10, S3_10, S4_10); ROUND3ODD (S1_11, S2_11, S3_11, S4_11); ROUND3EVEN (S1_12, S2_12, S3_12, S4_12); ROUND3ODD (S1_13, S2_13, S3_13, S4_13); ROUND3EVEN (S1_14, S2_14, S3_14, S4_14); ROUND3ODD (S1_15, S2_15, S3_15, S4_15); ROUND3EVEN (S1_16, S2_16, S3_16, S4_16); ROUND3ODD (S1_17, S2_17, S3_17, S4_17); ROUND3EVEN (S1_18, S2_18, S3_18, S4_18); ROUND3ODD (S1_19, S2_19, S3_19, S4_19); ROUND3EVEN (S1_20, S2_20, S3_20, S4_20); ROUND3ODD (S1_21, S2_21, S3_21, S4_21); ROUND3EVEN (S1_22, S2_22, S3_22, S4_22); ROUND3ODD (S1_23, S2_23, S3_23, S4_23); and this reinforces my belief that it is possible to use the memory (it fits in L1) for storing the coefs. This means that we can loop several with a loop core containing 4 rounds (either parallel or sequential) or less. I see no particular reason why we would be forced to use ALL the registers for a single key. The macros for the rounds seem to be rather well designed and suitable for FC0, the loop size is not too small or too large, the instructions seem correctly interleaved and the average distance of 3 instructions between computation and use is "good". To further my remark about using the L1 cache, here is some code : #define ROUND2ODD(S1N, S2N, S3N, S4N) \ * tmp1 = S1N; \ <-- instead of using a register, we can use a load instead. A1 += Llo1; \ * tmp2 = S2N; \ A2 += Llo2; \ * tmp3 = S3N; \ A3 += Llo3; \ * tmp4 = S4N; \ A4 += Llo4; \ A1 += tmp1; \ A2 += tmp2; \ ..... rest of the code look, there are 32 instructions (i presume that it could be possible to re-optimise the code to remove some "temp"s !) and only 4 loads. it is a perfectly sustainable bandwidth. However, i miss the signification of this code : > if (rc5unitwork->cypher.lo == eA1 && > rc5unitwork->cypher.hi == ROTL(eB1 ^ eA1, eA1) + > ROTL3(S1_25 + A1 + ROTL(Llo1 + A1 + Lhi1, A1 + Lhi1))) return kiter; > > > - or we use all the register, compute 2 more keys before doing something > > > in memory and having better performance I thing. > > today, performance is also (like in the 70s) constrained by the memory. > > in today's systems, you can have a bandwidth of less than one byte per > > instruction (provided the instruction is already in Icache and we hit L2 or > > the local SDRAM). > > You HAVE to interleave memory accesses (by small chunks) and computations. > > Otherwise, your nicely optimised code will runn during 600 cycles and > > stall almost completely another 600 cycles. > Don't forget, my main loop will take 1200 instructions... And a loop is for > looping ;-) if you say so... > > > > > I didn't find a specially designed core for IA64. > > > > it's just a matter of time... > > > Or because nobody have this type of hardware... > > or because when you can afford one, you can afford a dedicated RC5 HW > > ;-) > The objectif of the distributed.net project is not to say : buy a new core, > but use your cpu to do... that's cool if we want to heat up the room while we're away ;-P > > i'm not speaking about recoding the *client*, only the decoding algo. > It's what I speak about... > > > if you start from the inner loop, there should be no problem. > > You then propagate all the constraints to the client : platform detection, > > tuning of the keys... and since you have the sources, you can make > > your own f-cpu patch. > The problem is in the test. You must do a test for each chunk... where is this test ? > > there is a simple way to do your thing in C : > Grrr, I know howto use pointer on function ;-) > > > > Is it too difficult to do ? ok you reassure me. but then i don't see the point of your previous remark. > > > I am sure too, but I wan't to see what is the difference with the 64 > > > bits version. > > version of what ? RC5 or F-CPU ? > A the RC5 version never change, it came from the dnetc projet ;-) who knows ... > > > So, ok if we want to reduce the code needed, we will need to put data in > > > memory and manipulate some stupid table... > > if you mean "simple" table, it's ok. > Yes, nut it's not ok. I didn't wan't to access to memory when I can stay > in register. programming is an exercise on balancing register vs memory usage, speed vs memory footprint, unrolling vs factoring... in fewer words, as someone on usenet write in his sig, it's an exercise on caching. If your program footprint explodes, i don't see the point of "not accessing memory at all costs". The larger the program/code, the more bugs. If your bloated code does always do the _same_ thing all over the cache, then there's something really dumb happening. Frankly, you can reduce the code size by 4 or 8, which is reasonable and safe. What to do with the extra registers ? more computations, of course ! Imagine a 256-bit, 4-issue F-CPU where there is only one unit per instruction slot (1 slot for boolean ops, 2 slots for additions, 1 slot for register move or memory store/load, or something like that). The exta registers will allow to compute even more stuff and still execute with no pipeline stall or empty issue slot. You can simply copy-paste the code, interleave it and rename the registers so you are sure that every execution unit is working all the time. > > If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of > > cache. for 128-bit blocks, you need 2KB of data cache. > > Because the rounds use sequential, linear access, there is no cache > > penalty (there should be some auto-prefetching of the next cache line). > I think that you didn't look to the file I gave to you... not quite, but it shows that there are 12 rounds and the blocks are 64-bits, so the "working set" uses 32-bit integers. > > Furthermore, if you decode several blocks at once (for example, a 64-bit > > core with 64-bit blocks), you can do : > > > loadi.64 8, [rp], rd; > > sdupi.32 0, rd, r1; > > sdupi.32 1, rd, r2; // or something like that > > --> you execute only one load and you get 4 32-bit values > > in 2 registers with 3 instructions. > euh, sory but what are you doing here ? if we use F-CPU for enciphering or deciphering a message (in a real-world communication application, for example), i presume that the keys for each round don't change across the blocks --> we can use each round's value several times, once for each block, and we can store several blocks in the register set with the SIMD operations. > > > So I prefer to have a big code (but smaller than 8KB), than to do stupid > > > operation in memory and not use all the > > > register and forgot that I am not on an x86 CPU and that I have 63 > > > registers ! > > i think you are mistaken : the goal is not to use ALL the registers. > > There are other things that come into the game, such as the time it > > takes to load and store the whole damn register set. Some computations are > > less memory intensive and might be happy to spread in the whole register > > set. > If I save and restore this register only after 20000 cycles or more, and > if I didn't use the L1 cache during all this cycle, where is the problem ? i need some more explanations, i'm not a distributed.net specialist. and i don't have much time to crawl inside their code (which would not be more difficult to read with some more comments, say 3x more). > > RC5 is not "intensive" but this becomes a bottleneck if you don't take > > care of the steadiness of the memory streams. It takes quite a while > > to dump/flush 512 bytes. Don't forget that the core > > often runs 10x faster than the memory system. > It's why I want to stay in register. except that here, - the required bandwidth is well below the maltong point - the footprint is well below the thrashing point - with the extra registers, you can perform more computations, such as testing stuff in parallel or compute larger blocks per round. > > If we ever find some time to meet, we'll read the documents and draft > > some code together, i'll show you some tricks. > And me too ;-) i *like* that mutual misunderstanding that ends up learning stuffs :-))) > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: i got your post twice, c'est encore un coup à la VM à Rik ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Apr 10 18:15:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16vLzJ-0000I8-00 for ; Wed, 10 Apr 2002 19:34:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Apr 2002 19:34:29 +0200 (CEST) Received: (qmail 19843 invoked by uid 0); 10 Apr 2002 16:15:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Apr 2002 16:15:03 -0000 Received: by moria.seul.org (Postfix) id F2EDA1468E3; Wed, 10 Apr 2002 12:15:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC70714680E; Wed, 10 Apr 2002 12:15:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 3DB821467EF for ; Wed, 10 Apr 2002 12:15:01 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id 649CD495 for ; Wed, 10 Apr 2002 18:15:00 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 3DFDD64110; Wed, 10 Apr 2002 18:15:00 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-ID: <1018455300.3cb4650422e05@imp.free.fr> Date: Wed, 10 Apr 2002 18:15:00 +0200 (MEST) From: Cedric BAIL References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> In-Reply-To: <3CB321F0.93FCD9BE@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > hi again, > but finally i prefer to answer your posts, they are more instructive > than others ;-) Thanks ;-) I must add something before repplying to your post. The objectif of the dnetc project is to break the rc5 keys. So you increment the keys and you verify if it decrypt the bloc they give to you. > i see things like > > ROUND3EVEN (S1_02, S2_02, S3_02, S4_02); > ROUND3ODD (S1_03, S2_03, S3_03, S4_03); > ROUND3EVEN (S1_04, S2_04, S3_04, S4_04); > ROUND3ODD (S1_05, S2_05, S3_05, S4_05); > ROUND3EVEN (S1_06, S2_06, S3_06, S4_06); > ROUND3ODD (S1_07, S2_07, S3_07, S4_07); > ROUND3EVEN (S1_08, S2_08, S3_08, S4_08); > ROUND3ODD (S1_09, S2_09, S3_09, S4_09); > ROUND3EVEN (S1_10, S2_10, S3_10, S4_10); > ROUND3ODD (S1_11, S2_11, S3_11, S4_11); > ROUND3EVEN (S1_12, S2_12, S3_12, S4_12); > ROUND3ODD (S1_13, S2_13, S3_13, S4_13); > ROUND3EVEN (S1_14, S2_14, S3_14, S4_14); > ROUND3ODD (S1_15, S2_15, S3_15, S4_15); > ROUND3EVEN (S1_16, S2_16, S3_16, S4_16); > ROUND3ODD (S1_17, S2_17, S3_17, S4_17); > ROUND3EVEN (S1_18, S2_18, S3_18, S4_18); > ROUND3ODD (S1_19, S2_19, S3_19, S4_19); > ROUND3EVEN (S1_20, S2_20, S3_20, S4_20); > ROUND3ODD (S1_21, S2_21, S3_21, S4_21); > ROUND3EVEN (S1_22, S2_22, S3_22, S4_22); > ROUND3ODD (S1_23, S2_23, S3_23, S4_23); > and this reinforces my belief that it is possible > to use the memory (it fits in L1) for storing the coefs. I know, it's possible to use memory, but you will not reduce the use of the ICache and you will add a lot of access to the DCache, and I don't see why you absolutely want to use the DCache. (If you want some example that use simple table for their S1..4 look in the other file I have posted). > This means that we can loop several with a loop core containing > 4 rounds (either parallel or sequential) or less. Well, where did this 4th round came from ? > I see no particular reason why we would be forced to use ALL > the registers for a single key. Not for a single key, but for 4 keys. > The macros for the rounds seem to be rather well designed > and suitable for FC0, the loop size is not too small or too > large, the instructions seem correctly interleaved and the average > distance of 3 instructions between computation and use is "good". It's why I select this algo. > To further my remark about using the L1 cache, here is some code : > #define ROUND2ODD(S1N, S2N, S3N, S4N) \ > * tmp1 = S1N; \ <-- instead of using a register, we can use a > load instead. > A1 += Llo1; \ > * tmp2 = S2N; \ > A2 += Llo2; \ > * tmp3 = S3N; \ > A3 += Llo3; \ > * tmp4 = S4N; \ > A4 += Llo4; \ > A1 += tmp1; \ > A2 += tmp2; \ > ..... rest of the code The question is why did you absolutly want to use the DCache ? The register are quicker than the DCache, so why ? > look, there are 32 instructions (i presume that it could be possible to > re-optimise the code to remove some "temp"s !) and only 4 loads. it is a > perfectly sustainable bandwidth. > However, i miss the signification of this code : > > > if (rc5unitwork->cypher.lo == eA1 && > > rc5unitwork->cypher.hi == ROTL(eB1 ^ eA1, eA1) + > > ROTL3(S1_25 + A1 + ROTL(Llo1 + A1 + Lhi1, A1 + Lhi1))) return > > kiter; It compare if the decrypted block equal the block they give to you. It's for checking if the key his the one your are looking for ! > > The problem is in the test. You must do a test for each chunk... > where is this test ? The code you include in your post ;-) (The one you didn't understand) > ok you reassure me. but then i don't see the point of your previous > remark. Perhaps, because I don't understand where you want to use this code. > programming is an exercise on balancing register vs memory usage, speed vs > memory footprint, unrolling vs factoring... in fewer words, as someone > on usenet write in his sig, it's an exercise on caching. Yes but if you look to the optimised core for K7, you will see that they use table, but not unrolling loop. I don't know why, but I am not a K7 "gourou". > If your program footprint explodes, i don't see the point of > "not accessing memory at all costs". The larger the program/code, > the more bugs. > If your bloated code does always do the _same_ thing all over > the cache, then there's something really dumb happening. > Frankly, you can reduce the code size by 4 or 8, which is reasonable and > safe. You can't reduce the code much more than 600 instructions. If you use small loop to compute the different round, you will use too much bandwich only to reduce the use of instruction. I think that it's preferable to use all the ICache and nothing for the DCache. > What to do with the extra registers ? more computations, of course ! > Imagine a 256-bit, 4-issue F-CPU where there is only one unit per > instruction slot (1 slot for boolean ops, 2 slots for additions, 1 slot > for register move or memory store/load, or something like that). > The exta registers will allow to compute even more stuff and still > execute with no pipeline stall or empty issue slot. You can simply > copy-paste the code, interleave it and rename the registers so you > are sure that every execution unit is working all the time. ... Well I actually compute 4 keys in the same pass. If we have a 256 bits F-CPU, we only need to rewrite the test and we will compute 16 keys per pass. No register renaming, nothing complicated to do... > > > If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of > > > cache. for 128-bit blocks, you need 2KB of data cache. > > > Because the rounds use sequential, linear access, there is no cache > > > penalty (there should be some auto-prefetching of the next cache line). > > I think that you didn't look to the file I gave to you... > not quite, but it shows that there are 12 rounds and the blocks are > 64-bits, so the "working set" uses 32-bit integers. euh, I see only 3 rounds. For the rest it's ok. > > > Furthermore, if you decode several blocks at once (for example, a 64-bit > > > core with 64-bit blocks), you can do : > > > > > loadi.64 8, [rp], rd; > > > sdupi.32 0, rd, r1; > > > sdupi.32 1, rd, r2; // or something like that > > > --> you execute only one load and you get 4 32-bit values > > > in 2 registers with 3 instructions. > > euh, sory but what are you doing here ? > if we use F-CPU for enciphering or deciphering a message (in a real-world > communication application, for example), i presume that the keys for each > round don't change across the blocks --> we can use each round's value > several times, once for each block, and we can store several blocks > in the register set with the SIMD operations. oups, you want to do brute force attack in a communication application... I don't understand. > > > > So I prefer to have a big code (but smaller than 8KB), than to do stupid > > > > operation in memory and not use all the > > > > register and forgot that I am not on an x86 CPU and that I have 63 > > > > registers ! > > > i think you are mistaken : the goal is not to use ALL the registers. > > > There are other things that come into the game, such as the time it > > > takes to load and store the whole damn register set. Some computations are > > > less memory intensive and might be happy to spread in the whole register > > > set. > > If I save and restore this register only after 20000 cycles or more, and > > if I didn't use the L1 cache during all this cycle, where is the problem ? > i need some more explanations, i'm not a distributed.net specialist. > and i don't have much time to crawl inside their code (which would > not be more difficult to read with some more comments, say 3x more). ok, if you want all the source code for this project go to their web site. But they have a lot of different project and RC5 his the one of the oldest. > > > RC5 is not "intensive" but this becomes a bottleneck if you don't take > > > care of the steadiness of the memory streams. It takes quite a while > > > to dump/flush 512 bytes. Don't forget that the core > > > often runs 10x faster than the memory system. > > It's why I want to stay in register. > except that here, > - the required bandwidth is well below the maltong point What is a maltong point ? > - the footprint is well below the thrashing point Same question, but with thrashing. > - with the extra registers, you can perform more computations, It's what I do, with 31 registers I computes 2 keys, with 62... 4 keys. > such as testing stuff in parallel or compute larger blocks per round. A+ Cedric > PS: i got your post twice, c'est encore un coup à la VM à Rik ? No : "c'est un coup a netscape" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 10 12:32:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16vR5M-00042P-00 for ; Thu, 11 Apr 2002 01:01:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Apr 2002 01:01:04 +0200 (CEST) Received: (qmail 13188 invoked by uid 0); 10 Apr 2002 22:01:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 10 Apr 2002 22:01:19 -0000 Received: by moria.seul.org (Postfix) id A19561468E8; Wed, 10 Apr 2002 18:01:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 994841468EA; Wed, 10 Apr 2002 18:01:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a074.home.uni-hannover.de [130.75.232.74]) by moria.seul.org (Postfix) with ESMTP id 0FD611468E8 for ; Wed, 10 Apr 2002 18:01:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00556; Wed, 10 Apr 2002 12:32:14 +0200 Message-ID: <20020410123214.06958@thrai.stud.uni-hannover.de> Date: Wed, 10 Apr 2002 12:32:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020408033711.00830@thrai.stud.uni-hannover.de> <1018306336.3cb21f20acde6@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1018306336.3cb21f20acde6@imp.free.fr>; from Cedric BAIL on Tue, Apr 09, 2002 at 12:52:16AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 09, 2002 at 12:52:16AM +0200, Cedric BAIL wrote: > > Depends on your definitions of `really' and `simd' ;) > I think that you have understand what I mean. Didn't you see the smiley? > > Here's a 16-bit version, using slightly less than 3 instructions per > > slice, and only 2 registers: > > [...] > Well, we lost what %2 and %1 contain after the call. I know in my call too, > but it can be a problem. You can use more registers if you want. > > > An other thing about the srotl, it currently double the asm code. > > > It mean that, if we have a real srotl operation, we will have the same or > > > better performance than the K7 core (who is actually the best for this > > > algorithm). So my question is what is the cost of having a real srotl > > > instruction ? > > A more complex shifter unit, with more delay. > It was what I was thinking, but is it so important ? If you don't mind that shift operations take more than 1 cycle... [...] > So, we need to patch the manual. In many places. I made a long list of ambiguities and errors months ago (e.g. look for the phrase "Dark and Dusty Corners", September 2001). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 11 02:38:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16vTum-00061L-00 for ; Thu, 11 Apr 2002 04:02:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Apr 2002 04:02:20 +0200 (CEST) Received: (qmail 10923 invoked by uid 0); 11 Apr 2002 00:32:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 11 Apr 2002 00:32:44 -0000 Received: by moria.seul.org (Postfix) id 7EFD71463AB; Wed, 10 Apr 2002 20:32:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7710F1467F0; Wed, 10 Apr 2002 20:32:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 119801463AB for ; Wed, 10 Apr 2002 20:32:43 -0400 (EDT) Received: from f-cpu.org (kdl11-11.n.club-internet.fr [213.44.9.11]) by relay-1m.club-internet.fr (Postfix) with ESMTP id D56731681 for ; Thu, 11 Apr 2002 02:32:36 +0200 (CEST) Message-ID: <3CB4DB20.F2572054@f-cpu.org> Date: Thu, 11 Apr 2002 02:38:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Cedric BAIL wrote: > Hi, > > hi again, > > I must add something before repplying to your post. The objectif of the > dnetc project is to break the rc5 keys. So you increment the keys and you > verify if it decrypt the bloc they give to you. fine, however i don't see where the verification is performed. >From my point of view, the dnet project is a specific part of the application domain of F-CPU. Can i point that crypto is used in communication (like in SSH) and storage (encrypted filesystems) ? This means that if we find something interesting when examining dnet, it can also enhance the performance of a normal computer that works in a secured environment, such as an internet server. It is maybe worth noting it and may explain why i don't focus exclusively on RC5 cracking (though i know it's a good entry point and a "cool way" to make others think about F-CPU). > > i see things like > > > > ROUND3EVEN (S1_02, S2_02, S3_02, S4_02); > > ROUND3ODD (S1_03, S2_03, S3_03, S4_03); > > ROUND3EVEN (S1_04, S2_04, S3_04, S4_04); > > ROUND3ODD (S1_05, S2_05, S3_05, S4_05); > > ROUND3EVEN (S1_06, S2_06, S3_06, S4_06); > > ROUND3ODD (S1_07, S2_07, S3_07, S4_07); > > ROUND3EVEN (S1_08, S2_08, S3_08, S4_08); > > ROUND3ODD (S1_09, S2_09, S3_09, S4_09); > > ROUND3EVEN (S1_10, S2_10, S3_10, S4_10); > > ROUND3ODD (S1_11, S2_11, S3_11, S4_11); > > ROUND3EVEN (S1_12, S2_12, S3_12, S4_12); > > ROUND3ODD (S1_13, S2_13, S3_13, S4_13); > > ROUND3EVEN (S1_14, S2_14, S3_14, S4_14); > > ROUND3ODD (S1_15, S2_15, S3_15, S4_15); > > ROUND3EVEN (S1_16, S2_16, S3_16, S4_16); > > ROUND3ODD (S1_17, S2_17, S3_17, S4_17); > > ROUND3EVEN (S1_18, S2_18, S3_18, S4_18); > > ROUND3ODD (S1_19, S2_19, S3_19, S4_19); > > ROUND3EVEN (S1_20, S2_20, S3_20, S4_20); > > ROUND3ODD (S1_21, S2_21, S3_21, S4_21); > > ROUND3EVEN (S1_22, S2_22, S3_22, S4_22); > > ROUND3ODD (S1_23, S2_23, S3_23, S4_23); > > > and this reinforces my belief that it is possible > > to use the memory (it fits in L1) for storing the coefs. > I know, it's possible to use memory, but you will not reduce the use > of the ICache and you will add a lot of access to the DCache, no because it will reside in a smaller loop, with maybe do { ROUND3EVEN (S1[i], S2[i], S3[i], S4[i]); ROUND3ODD (S1[i+1], S2[i+1], S3[i+1], S4[i+1]); i+=2; } while (i<12); in asm, we will need 4 pointer registers (renamed S1 to S4) and they use post-incremented addressing. The time to execute the block is enough to pre-load the LSU for the next "round" (loop cycle). > and I don't see why you absolutely want to use the DCache. This frees a lot of registers that can be used for other computing purposes. In the case of a stream encryption, the "S" are stored in L1 and the encrypted data are stored in the remaining registers. This provides enough work so that it can be rescheduled easily, and even execute on superscalar versions. The case of dnet is looking different but i can't involve myself in this now. The case of the SIMD shift has been proved and there does not seem to be any difficulty in implementing it with F-CPU, we simply disagree on a "small" implementation detail :-) > (If you want some example that use simple table for their S1..4 look > in the other file I have posted). "the other file" ? which ? there is a lot of them :-/ > > This means that we can loop several with a loop core containing > > 4 rounds (either parallel or sequential) or less. > Well, where did this 4th round came from ? look at the code i copied at the top of the mail : i count 12 "ROUND3EVEN" and "ROUND3ODD" : these are "rounds" as the name says. Look at a crypto book, it's the Feistel structure denomination). and you can remark that 24/2=12. Now if we put 2*"ROUND3EVEN" and 2*"ROUND3ODD" in the loop body, we can loop 6* and spare some number of registers that can be assigned to other duties, such as searching other keys. > > I see no particular reason why we would be forced to use ALL > > the registers for a single key. > Not for a single key, but for 4 keys. ok, ok, but what if there was a mean to search 8 keys or maybe even 12 or 16 ? i don't think it's impossible or even impracticable, and i give a proof later in this post. > > The macros for the rounds seem to be rather well designed > > and suitable for FC0, the loop size is not too small or too > > large, the instructions seem correctly interleaved and the average > > distance of 3 instructions between computation and use is "good". > It's why I select this algo. you have better tastes than i thought ;-P however, i don't like the code which tries to pre-optimize the code for 2-address operations. > > To further my remark about using the L1 cache, here is some code : > > > #define ROUND2ODD(S1N, S2N, S3N, S4N) \ > > * tmp1 = S1N; \ <-- instead of using a register, we can use a > > load instead. > > A1 += Llo1; \ > > * tmp2 = S2N; \ > > A2 += Llo2; \ > > * tmp3 = S3N; \ > > A3 += Llo3; \ > > * tmp4 = S4N; \ > > A4 += Llo4; \ > > A1 += tmp1; \ > > A2 += tmp2; \ > > ..... rest of the code > > The question is why did you absolutly want to use the DCache ? > The register are quicker than the DCache, so why ? in this case, the difference does not appear because - the data set fits in Dcache - the access pattern is deterministic and linear (that is : ideal) In the ideal case, the distance between LSU operations on a give register must be spaced (at least half a dozen cycles) but the result of a load is usable _immediately_ (at first glance) after the instruction. This means that even without auto-prefetch, there is no latency if the distance between loads is respected. If you use all LSU lines (8 currently, this number corresponds to the average L1 latency) you can sustain the maximum throughput. You can also think about the quantity of memory that is available : - a L1 would contain 4 or 8 KB of memory - the register set can contain 512 bytes (maximum) A RC5 core computation seems to require around 6 registers, so it seems possible to compute at least 8 simultaneous scalar operations (6*8=48, still leaving some registers for other duties) and thus 16 "keys" with a SIMD 64-bit F-CPU. This means however that the loop will contain only one Feistel round (both even and odd), but for all 8(16) keys in parallel. Clearly, this means that if we implement a FC3 with 4 or 6 instructions decoded per cycle, RC5 will still fly. > > look, there are 32 instructions (i presume that it could be possible to > > re-optimise the code to remove some "temp"s !) and only 4 loads. it is a > > perfectly sustainable bandwidth. > > > However, i miss the signification of this code : > > > > > if (rc5unitwork->cypher.lo == eA1 && > > > rc5unitwork->cypher.hi == ROTL(eB1 ^ eA1, eA1) + > > > ROTL3(S1_25 + A1 + ROTL(Llo1 + A1 + Lhi1, A1 + Lhi1))) return > > > kiter; > It compare if the decrypted block equal the block they give to you. > It's for checking if the key his the one your are looking for ! well, nothing worth fussing about, then ;-) > > > The problem is in the test. You must do a test for each chunk... > > where is this test ? > The code you include in your post ;-) (The one you didn't understand) may one forgive me. i thought they knew how to write comments. > > ok you reassure me. but then i don't see the point of your previous > > remark. > Perhaps, because I don't understand where you want to use this code. RC5 is RC5, you use it to encode and decode streams (files, network packets...). DNET uses both and performs extra stuff, so it first needs a good understanding of RC5, and then a good overview of their cracking strategy. So i start with the simplest things : RC5 stream coding. > > programming is an exercise on balancing register vs memory usage, speed vs > > memory footprint, unrolling vs factoring... in fewer words, as someone > > on usenet write in his sig, it's an exercise on caching. > Yes but if you look to the optimised core for K7, you will see that > they use table, but not unrolling loop. I don't know why, but I am > not a K7 "gourou". i have not seen their code (there's no mention about AMD or K7 in your ANSI codes) but from my , ... hmmmm...., "knowledge" of the architecture, it is due to... register pressure. However, there is no loss in using memory in this case (as i explained : linear access pattern and dataset size) so the strategy for F-CPU would be to use a similar code in a loop, but the 8* unrolling will be just cut-paste-rename and the computations will be done in parallel. Given the 8 "general purpose registers" of x86 and the 32 regs of other RISC platforms (see the _4-rg source), you see that it is possible to compute at least 8 keys in scalar mode and much more in SIMD mode. > > If your program footprint explodes, i don't see the point of > > "not accessing memory at all costs". The larger the program/code, > > the more bugs. > > If your bloated code does always do the _same_ thing all over > > the cache, then there's something really dumb happening. > > Frankly, you can reduce the code size by 4 or 8, which is reasonable and > > safe. > You can't reduce the code much more than 600 instructions. If you > use small loop to compute the different round, you will use too much > bandwich only to reduce the use of instruction. I think that it's preferable > to use all the ICache and nothing for the DCache. hey, you can sustain 256 bits per cycle of bandwidth from and to L1 ! the bandwidth is here to be used :-) If you have a "core" that fits in 1000 instructions, it's ok (fits in 4KB of Icache). But the LSU is here to relieve the register set from temporarily unused data and it's dumb to not use it because as long as it fits in L1, you feel no latency. > > What to do with the extra registers ? more computations, of course ! > > Imagine a 256-bit, 4-issue F-CPU where there is only one unit per > > instruction slot (1 slot for boolean ops, 2 slots for additions, 1 slot > > for register move or memory store/load, or something like that). > > The exta registers will allow to compute even more stuff and still > > execute with no pipeline stall or empty issue slot. You can simply > > copy-paste the code, interleave it and rename the registers so you > > are sure that every execution unit is working all the time. > ... Well I actually compute 4 keys in the same pass. If we have a > 256 bits F-CPU, we only need to rewrite the test and we will compute > 16 keys per pass. No register renaming, nothing complicated to do... >from what is written above, it's possible to do 16 keys with a 64-bit CPU. Mega-quote : ----> "Use the cache, Luke" ;-P <----- > > > > If you have 16 rounds and a 64-bit block, you need 16*2*32=1KB of > > > > cache. for 128-bit blocks, you need 2KB of data cache. > > > > Because the rounds use sequential, linear access, there is no cache > > > > penalty (there should be some auto-prefetching of the next cache line). > > > I think that you didn't look to the file I gave to you... > > not quite, but it shows that there are 12 rounds and the blocks are > > 64-bits, so the "working set" uses 32-bit integers. > euh, I see only 3 rounds. For the rest it's ok. a "round" in the Feistel structure is the thing that is defined in the macro (where the computation is performed). The main code instanciates the macro 12x, this means that there are 12 "rounds" (plaintext attack on RC5 is the only known solution when 16 rounds are used, according to Schneier). What you seem to call "round" is the higher level of the DNET code, where the S variables are generated, then text is encrypted and finally decrypted. maybe i missed a few thousands stuffs, but "ROUND3xxx" means that it's the 3rd kind of round, not the 3rd round. > > > > Furthermore, if you decode several blocks at once (for example, a 64-bit > > > > core with 64-bit blocks), you can do : > > > > > > > loadi.64 8, [rp], rd; > > > > sdupi.32 0, rd, r1; > > > > sdupi.32 1, rd, r2; // or something like that > > > > --> you execute only one load and you get 4 32-bit values > > > > in 2 registers with 3 instructions. > > > euh, sory but what are you doing here ? > > if we use F-CPU for enciphering or deciphering a message (in a real-world > > communication application, for example), i presume that the keys for each > > round don't change across the blocks --> we can use each round's value > > several times, once for each block, and we can store several blocks > > in the register set with the SIMD operations. > oups, you want to do brute force attack in a communication application... > I don't understand. i'm just contemplating using FC0 in a secured environment where lots of data must be encrypted. because we don't have to recompute S all the time, the stream can be really fast (a 1st generation FC0 could at least not blush when compared to faster CPUs). > > > > > So I prefer to have a big code (but smaller than 8KB), than to do stupid > > > > > operation in memory and not use all the > > > > > register and forgot that I am not on an x86 CPU and that I have 63 > > > > > registers ! > > > > i think you are mistaken : the goal is not to use ALL the registers. > > > > There are other things that come into the game, such as the time it > > > > takes to load and store the whole damn register set. Some computations are > > > > less memory intensive and might be happy to spread in the whole register > > > > set. > > > If I save and restore this register only after 20000 cycles or more, and > > > if I didn't use the L1 cache during all this cycle, where is the problem ? > > i need some more explanations, i'm not a distributed.net specialist. > > and i don't have much time to crawl inside their code (which would > > not be more difficult to read with some more comments, say 3x more). > ok, if you want all the source code for this project go to their web site. > But they have a lot of different project and RC5 his the one of the oldest. ??? is there a recommended URL for the source ? > > > > RC5 is not "intensive" but this becomes a bottleneck if you don't take > > > > care of the steadiness of the memory streams. It takes quite a while > > > > to dump/flush 512 bytes. Don't forget that the core > > > > often runs 10x faster than the memory system. > > > It's why I want to stay in register. > > except that here, > > - the required bandwidth is well below the maltong point > What is a maltong point ? ooops i should not type with my mittens on ;-) "melting" point, or "it's not a bottleneck" because L1 bandwidth is not a problem when data is accessed with regular patterns. > > - the footprint is well below the thrashing point > Same question, but with thrashing. it's the same as when your computer "swaps" to the hard disk : it is because it requires more memory than physically available, so it uses some slower, larger temporary storage. The same goes with L1, L2 etc... > > - with the extra registers, you can perform more computations, > It's what I do, with 31 registers I computes 2 keys, with 62... 4 keys. mmmmm from what i read, with 32 registers it's possible to compute 4 keys : what did i miss ? maybe the compiler automatically maps the S variables to memory, don't you think ? let's count : > u32 kiter = 0; > u32 keycount = tslice; 2 > u32 S1_00,S1_01,S1_02,S1_03,S1_04,S1_05,S1_06,S1_07,S1_08,S1_09, > S1_10,S1_11,S1_12,S1_13,S1_14,S1_15,S1_16,S1_17,S1_18,S1_19, > S1_20,S1_21,S1_22,S1_23,S1_24,S1_25; 26 > u32 S2_00,S2_01,S2_02,S2_03,S2_04,S2_05,S2_06,S2_07,S2_08,S2_09, > S2_10,S2_11,S2_12,S2_13,S2_14,S2_15,S2_16,S2_17,S2_18,S2_19, > S2_20,S2_21,S2_22,S2_23,S2_24,S2_25; 26 > u32 S3_00,S3_01,S3_02,S3_03,S3_04,S3_05,S3_06,S3_07,S3_08,S3_09, > S3_10,S3_11,S3_12,S3_13,S3_14,S3_15,S3_16,S3_17,S3_18,S3_19, > S3_20,S3_21,S3_22,S3_23,S3_24,S3_25; 26 > u32 S4_00,S4_01,S4_02,S4_03,S4_04,S4_05,S4_06,S4_07,S4_08,S4_09, > S4_10,S4_11,S4_12,S4_13,S4_14,S4_15,S4_16,S4_17,S4_18,S4_19, > S4_20,S4_21,S4_22,S4_23,S4_24,S4_25; 26 this part is more interesting : > u32 A1, Llo1, Lhi1; > u32 A2, Llo2, Lhi2; > u32 A3, Llo3, Lhi3; > u32 A4, Llo4, Lhi4; > u32 tmp1, tmp2, tmp3, tmp4; 12+4=16 the total number is 16 + 26*4 + 2 = 122 So if i count correctly, you can fit this in the F-CPU register set simply because a 64-bit SIMD register can contain 2*u32. Then you can remove some of the code that loads the S, but you have to re-schedule the macros because temp1 to temp4 may be useless. at least "tmp1 = S1N;" etc. can be removed (register name inference). Later, i see : "u32 cS0, Q;" and "u32 eA1, eB1, eA2, eB2, eA3, eB3, eA4, eB4;" so it adds 5 more registers : argh. > A+ > Cedric > > > PS: i got your post twice, c'est encore un coup à la VM à Rik ? > No : "c'est un coup a netscape" "finally, when netscape freezes, it's rock stable." :-P WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ np : Die Toten Hosen, "Opium für's Volk". ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 11 12:02:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16vk38-0000G1-00 for ; Thu, 11 Apr 2002 21:16:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Apr 2002 21:16:02 +0200 (CEST) Received: (qmail 3067 invoked by uid 0); 11 Apr 2002 17:53:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 11 Apr 2002 17:53:13 -0000 Received: by moria.seul.org (Postfix) id D98F3146816; Thu, 11 Apr 2002 13:53:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2DB8146819; Thu, 11 Apr 2002 13:53:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a241.home.uni-hannover.de [130.75.232.241]) by moria.seul.org (Postfix) with ESMTP id E5CE2146816 for ; Thu, 11 Apr 2002 13:53:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00494; Thu, 11 Apr 2002 12:02:41 +0200 Message-ID: <20020411120241.01935@thrai.stud.uni-hannover.de> Date: Thu, 11 Apr 2002 12:02:41 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CB4DB20.F2572054@f-cpu.org>; from Yann Guidon on Thu, Apr 11, 2002 at 02:38:56AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Apr 11, 2002 at 02:38:56AM +0200, Yann Guidon wrote: [...] > >From my point of view, the dnet project is a specific part of the > application domain of F-CPU. Can i point that crypto is used in > communication (like in SSH) and storage (encrypted filesystems) ? > This means that if we find something interesting when examining dnet, > it can also enhance the performance of a normal computer that works > in a secured environment, such as an internet server. It is maybe > worth noting it and may explain why i don't focus exclusively on > RC5 cracking (though i know it's a good entry point and a "cool way" > to make others think about F-CPU). Crypto stuff may be "cool", but something that fits into the L1 cache doesn't qualify as a real application, IMHO :) Besides that, many crypto algorithms can be done better (and faster) in dedicated hardware. What's a 64-bit CPU good for, compared to a 32-bit one? It's not necessarily faster, but it can handle large working sets. Therefore I'd rather focus on scientific applications, databases and so on. [...] > The case of dnet is looking different but i can't involve myself > in this now. The case of the SIMD shift has been proved and there > does not seem to be any difficulty in implementing it with F-CPU, > we simply disagree on a "small" implementation detail :-) Huh? No difficulty? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 12 07:07:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16w0L2-0000GK-01 for ; Fri, 12 Apr 2002 14:39:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Apr 2002 14:39:36 +0200 (CEST) Received: (qmail 25787 invoked by uid 0); 12 Apr 2002 05:01:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 12 Apr 2002 05:01:20 -0000 Received: by moria.seul.org (Postfix) id EA0851468D2; Fri, 12 Apr 2002 01:01:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC71A1468D5; Fri, 12 Apr 2002 01:01:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 6CC5D1468D2 for ; Fri, 12 Apr 2002 01:01:17 -0400 (EDT) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8F3741686 for ; Fri, 12 Apr 2002 07:01:13 +0200 (CEST) Message-ID: <3CB66B99.F0B2658A@f-cpu.org> Date: Fri, 12 Apr 2002 07:07:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB0B928.865D54EF@f-cpu.org> <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 'mojn, Michael Riepe wrote: > > On Thu, Apr 11, 2002 at 02:38:56AM +0200, Yann Guidon wrote: > [...] > > >From my point of view, the dnet project is a specific part of the > > application domain of F-CPU. Can i point that crypto is used in > > communication (like in SSH) and storage (encrypted filesystems) ? > > This means that if we find something interesting when examining dnet, > > it can also enhance the performance of a normal computer that works > > in a secured environment, such as an internet server. It is maybe > > worth noting it and may explain why i don't focus exclusively on > > RC5 cracking (though i know it's a good entry point and a "cool way" > > to make others think about F-CPU). > > Crypto stuff may be "cool", if you know the CCC guys, you will understand what i mean ;-) they are the one who introduced to this field and if F-CPU holds its promises, they will continue to help us. > but something that fits into the L1 cache > doesn't qualify as a real application, IMHO :) i have read on comp.sys.super : "cache memory is for the people who can't afford lots of fast main memory" ;-) > Besides that, many crypto > algorithms can be done better (and faster) in dedicated hardware. yup but they often do only 1 algo. > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > necessarily faster, it can be, as it treats wider data. > but it can handle large working sets. Therefore > I'd rather focus on scientific applications, databases and so on. don't worry, this will follow naturally, but how many scientists do you know around F-CPU ?... > [...] > > The case of dnet is looking different but i can't involve myself > > in this now. The case of the SIMD shift has been proved and there > > does not seem to be any difficulty in implementing it with F-CPU, > > we simply disagree on a "small" implementation detail :-) > > Huh? No difficulty? huh, i'll try to make my own shifter... whenever i can :-) have a nice day, everybody > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 12 12:16:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wAv2-0007PI-00 for ; Sat, 13 Apr 2002 01:57:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Apr 2002 01:57:28 +0200 (CEST) Received: (qmail 2881 invoked by uid 0); 12 Apr 2002 22:59:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 12 Apr 2002 22:59:53 -0000 Received: by moria.seul.org (Postfix) id CFD821467F6; Fri, 12 Apr 2002 18:59:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A999A1467FD; Fri, 12 Apr 2002 18:59:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a042.home.uni-hannover.de [130.75.232.42]) by moria.seul.org (Postfix) with ESMTP id CA5BD1467F6 for ; Fri, 12 Apr 2002 18:59:48 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00514; Fri, 12 Apr 2002 12:16:43 +0200 Message-ID: <20020412121643.07872@thrai.stud.uni-hannover.de> Date: Fri, 12 Apr 2002 12:16:43 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <3CB66B99.F0B2658A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CB66B99.F0B2658A@f-cpu.org>; from Yann Guidon on Fri, Apr 12, 2002 at 07:07:37AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 12, 2002 at 07:07:37AM +0200, Yann Guidon wrote: [...] > > Crypto stuff may be "cool", > if you know the CCC guys, you will understand what i mean ;-) I know some of them. But I don't think what they do is "cool", sorry. > they are the one who introduced to this field and if F-CPU holds its promises, > they will continue to help us. You mean, invite us to this year's CCC? > > but something that fits into the L1 cache > > doesn't qualify as a real application, IMHO :) > i have read on comp.sys.super : "cache memory is for the people who > can't afford lots of fast main memory" ;-) Well, unfortunately... ;) > > Besides that, many crypto > > algorithms can be done better (and faster) in dedicated hardware. > yup but they often do only 1 algo. FPGA? > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > necessarily faster, > it can be, as it treats wider data. That's wrong in many cases. Wider data types don't buy you anything if the range or precision of your numbers doesn't grow. But you need more memory to store a variable (which will slow down the program), or you'll have to work with partial registers (which may slow down the CPU). In some cases, SIMD can make the CPU perform better (numeric kernels, multimedia stuff), but a more general application with lots of (integer) add, shift, compare and pointer operations won't run faster on a 64-bit machine. > > but it can handle large working sets. Therefore > > I'd rather focus on scientific applications, databases and so on. > don't worry, this will follow naturally, but how many scientists do you > know around F-CPU ?... Do I have to *know* them? ;) > > [...] > > > The case of dnet is looking different but i can't involve myself > > > in this now. The case of the SIMD shift has been proved and there > > > does not seem to be any difficulty in implementing it with F-CPU, > > > we simply disagree on a "small" implementation detail :-) > > > > Huh? No difficulty? > huh, i'll try to make my own shifter... whenever i can :-) With all operations performed in one cycle? I already violated the 6G/10T rule in my design. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 12 23:19:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wAv2-0007PI-01 for ; Sat, 13 Apr 2002 01:57:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Apr 2002 01:57:28 +0200 (CEST) Received: (qmail 9145 invoked by uid 0); 12 Apr 2002 22:59:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Apr 2002 22:59:57 -0000 Received: by moria.seul.org (Postfix) id 4D4671462F9; Fri, 12 Apr 2002 18:59:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 363261467FD; Fri, 12 Apr 2002 18:59:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a042.home.uni-hannover.de [130.75.232.42]) by moria.seul.org (Postfix) with ESMTP id 964C91462F9 for ; Fri, 12 Apr 2002 18:59:48 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01976; Fri, 12 Apr 2002 23:19:46 +0200 Message-ID: <20020412231946.23497@thrai.stud.uni-hannover.de> Date: Fri, 12 Apr 2002 23:19:46 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] `real' SIMD shifts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Today I examined the omega network again, and I think it's able to perform the `real' SIMD rotate operations. But I'll have to rewrite the control and masking logic, which will take some time. Don't expect a new version until the end of june (this year, of course). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 13 05:03:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wFp5-0002Jx-01 for ; Sat, 13 Apr 2002 07:11:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Apr 2002 07:11:39 +0200 (CEST) Received: (qmail 8267 invoked by uid 0); 13 Apr 2002 02:56:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 13 Apr 2002 02:56:59 -0000 Received: by moria.seul.org (Postfix) id D87A11467F6; Fri, 12 Apr 2002 22:56:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C67161467FD; Fri, 12 Apr 2002 22:56:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 2740A1467FC for ; Fri, 12 Apr 2002 22:56:56 -0400 (EDT) Received: from f-cpu.org (kdl16-6.n.club-internet.fr [213.44.18.6]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 0AC65168E for ; Sat, 13 Apr 2002 04:56:48 +0200 (CEST) Message-ID: <3CB79FEE.65926D13@f-cpu.org> Date: Sat, 13 Apr 2002 05:03:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <3CB66B99.F0B2658A@f-cpu.org> <20020412121643.07872@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Fri, Apr 12, 2002 at 07:07:37AM +0200, Yann Guidon wrote: > [...] > > > Crypto stuff may be "cool", > > if you know the CCC guys, you will understand what i mean ;-) > I know some of them. But I don't think what they do is "cool", sorry. i don't say that everybody at CCC is "cool". I meant that some of them are really insterested by F-CPU because they see that they can program efficient "DNET" clusters and have all the garanties of the absence of backdoors or flaws. > > they are the one who introduced to this field and if F-CPU holds its promises, > > they will continue to help us. > You mean, invite us to this year's CCC? xC3 is a big party where we can meet and evaluate each others and we currently are not advanced enough. However, if f-cpu becomes a reality, they can help promote the chips. They won't drop their VAX or ACORN but will make a place for a computer they can hack deeper than anything they know. that's something "cool" in their eyes, i think. > > > Besides that, many crypto > > > algorithms can be done better (and faster) in dedicated hardware. > > yup but they often do only 1 algo. > FPGA? then that's half-dedicated. I read articles about RSA accelerators in ASICs or full-custom designs. DES or RC5 cores might be available but not much else. > > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > > necessarily faster, > > it can be, as it treats wider data. > That's wrong in many cases. Wider data types don't buy you anything if > the range or precision of your numbers doesn't grow. But you need more > memory to store a variable (which will slow down the program), or you'll > have to work with partial registers (which may slow down the CPU). In some > cases, SIMD can make the CPU perform better (numeric kernels, multimedia > stuff), but a more general application with lots of (integer) add, shift, > compare and pointer operations won't run faster on a 64-bit machine. then, computation time can be reduced by grouping CPUs. > > > but it can handle large working sets. Therefore > > > I'd rather focus on scientific applications, databases and so on. > > don't worry, this will follow naturally, but how many scientists do you > > know around F-CPU ?... > Do I have to *know* them? ;) that can help. For example, a CFD scientist has explained me how the newest algos work, and they WILL benefit from very wide SIMD cores (contrarily to what nicO said). the limiting factor is of course the RAM bandwidth, as it deals with gigabytes of 3D data... but i have developped a strip-mining stategy that helps :-) > > > [...] > > > > The case of dnet is looking different but i can't involve myself > > > > in this now. The case of the SIMD shift has been proved and there > > > > does not seem to be any difficulty in implementing it with F-CPU, > > > > we simply disagree on a "small" implementation detail :-) > > > Huh? No difficulty? > > huh, i'll try to make my own shifter... whenever i can :-) > With all operations performed in one cycle? I already violated the > 6G/10T rule in my design. if you can't fit, just pipeline. SHL has some pretty long wires and they get longer as the register width increases : you can't stand the frequency if the shifting distance is too long. Maybe a 2-speed shifter is possible ? below 32 bits, it will work in 1 cycle, and need 2 cycles for 32 and 64 bits ? this will obviously depend on the SIMD+SIZE bits, so it is deterministic at decode time and possible (like the add and multiply instructions). In another post, you wrote : > Today I examined the omega network again, and I think it's able to perform > the `real' SIMD rotate operations. But I'll have to rewrite the control > and masking logic, which will take some time. Don't expect a new version > until the end of june (this year, of course). I have a simple strategy in mind but have almost no decent computer environment : i'm making a Linux "personal distro" (based on LFS) because i need to better control my working environment. Before i have a working X display, i can't develop much :-( > Michael "Tired" Riepe WHYGEE (who's still doing his Linux Factory System ;-P) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 13 14:06:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wWM8-00058E-00 for ; Sun, 14 Apr 2002 00:50:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Apr 2002 00:50:52 +0200 (CEST) Received: (qmail 28927 invoked by uid 0); 13 Apr 2002 21:46:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 13 Apr 2002 21:46:46 -0000 Received: by moria.seul.org (Postfix) id 77B801467FD; Sat, 13 Apr 2002 17:46:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59B951467FF; Sat, 13 Apr 2002 17:46:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a119.home.uni-hannover.de [130.75.232.119]) by moria.seul.org (Postfix) with ESMTP id 155201467FD for ; Sat, 13 Apr 2002 17:46:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00558; Sat, 13 Apr 2002 14:06:31 +0200 Message-ID: <20020413140631.35618@thrai.stud.uni-hannover.de> Date: Sat, 13 Apr 2002 14:06:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <3CB66B99.F0B2658A@f-cpu.org> <20020412121643.07872@thrai.stud.uni-hannover.de> <3CB79FEE.65926D13@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CB79FEE.65926D13@f-cpu.org>; from Yann Guidon on Sat, Apr 13, 2002 at 05:03:10AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 13, 2002 at 05:03:10AM +0200, Yann Guidon wrote: [...] > I read articles about RSA accelerators in ASICs or full-custom designs. > DES or RC5 cores might be available but not much else. I guess AES (Rijndael) will follow soon. > > > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > > > necessarily faster, > > > it can be, as it treats wider data. > > That's wrong in many cases. Wider data types don't buy you anything if > > the range or precision of your numbers doesn't grow. But you need more > > memory to store a variable (which will slow down the program), or you'll > > have to work with partial registers (which may slow down the CPU). In some > > cases, SIMD can make the CPU perform better (numeric kernels, multimedia > > stuff), but a more general application with lots of (integer) add, shift, > > compare and pointer operations won't run faster on a 64-bit machine. > > then, computation time can be reduced by grouping CPUs. In the general case, no -- because you can't parallelize most of these applications. Grouping works fine only if you can divide a problem in `partitions' that can be solved independently (like rc5, seti, rendering and the like). [...] > > > > > The case of dnet is looking different but i can't involve myself > > > > > in this now. The case of the SIMD shift has been proved and there > > > > > does not seem to be any difficulty in implementing it with F-CPU, > > > > > we simply disagree on a "small" implementation detail :-) > > > > Huh? No difficulty? > > > huh, i'll try to make my own shifter... whenever i can :-) > > With all operations performed in one cycle? I already violated the > > 6G/10T rule in my design. > if you can't fit, just pipeline. SHL has some pretty long wires and they > get longer as the register width increases : you can't stand the frequency > if the shifting distance is too long. I know. But my first (two-stage) shifter version had more and even longer lines, and more crossings. The omega shifter is more regular, and it will scale much better. > Maybe a 2-speed shifter is possible ? below 32 bits, it will work in 1 cycle, > and need 2 cycles for 32 and 64 bits ? this will obviously depend on the > SIMD+SIZE bits, so it is deterministic at decode time and possible (like the > add and multiply instructions). The omega net can be pipelined, but I dont think that adding a `tap' output is a good idea. It will duplicate the amount of postprocessing logic, and spoil the regular structure. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Apr 14 00:44:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wmb9-0000Ha-01 for ; Sun, 14 Apr 2002 18:11:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Apr 2002 18:11:27 +0200 (CEST) Received: (qmail 3769 invoked by uid 0); 14 Apr 2002 11:47:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 14 Apr 2002 11:47:33 -0000 Received: by moria.seul.org (Postfix) id CFFAA1467FE; Sun, 14 Apr 2002 07:47:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C50FE146800; Sun, 14 Apr 2002 07:47:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 458801467FE for ; Sun, 14 Apr 2002 07:47:30 -0400 (EDT) Received: from there (nas-cbv-8-62-147-159-122.dial.proxad.net [62.147.159.122]) by postfix2-1.free.fr (Postfix) with SMTP id B8E8F3CF for ; Sun, 14 Apr 2002 13:47:28 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Sun, 14 Apr 2002 00:44:31 +0200 X-Mailer: KMail [version 1.3.2] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <1018306336.3cb21f20acde6@imp.free.fr> <20020410123214.06958@thrai.stud.uni-hannover.de> In-Reply-To: <20020410123214.06958@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414114728.B8E8F3CF@postfix2-1.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Depends on your definitions of `really' and `simd' ;) > > I think that you have understand what I mean. ;-) > Didn't you see the smiley? I forgot to put one, so I correct the past ;-) > > > > An other thing about the srotl, it currently double the asm code. > > > > It mean that, if we have a real srotl operation, we will have the > > > > same or better performance than the K7 core (who is actually the best > > > > for this algorithm). So my question is what is the cost of having a > > > > real srotl instruction ? > > > A more complex shifter unit, with more delay. > > It was what I was thinking, but is it so important ? > If you don't mind that shift operations take more than 1 cycle... > > So, we need to patch the manual. > In many places. I made a long list of ambiguities and errors months > ago (e.g. look for the phrase "Dark and Dusty Corners", September 2001). Did you post something ? (If yes give me the title of your post and I will do the update). I currently scheduled to do : - Verify all the instruction set, that they didn't have any error like the rotl instruction. - Add the new load and store operation that whas asked by christophe - Update loadm/storem to be up to date with what we say on the mailing-list - Add the dnetc-rc5 F-CPU code sample - Find a way to add an index (if some one know howto to do that in latex) - Put all the different manual (english, french, german) in the same package If someone want to add something, only ask. When I finished to do that I will use a cvs so that we can work more easily. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Apr 14 01:00:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wmbA-0000Ha-00 for ; Sun, 14 Apr 2002 18:11:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Apr 2002 18:11:28 +0200 (CEST) Received: (qmail 28115 invoked by uid 0); 14 Apr 2002 11:47:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 14 Apr 2002 11:47:35 -0000 Received: by moria.seul.org (Postfix) id BC5AA146804; Sun, 14 Apr 2002 07:47:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9B28146802; Sun, 14 Apr 2002 07:47:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 36761146800 for ; Sun, 14 Apr 2002 07:47:31 -0400 (EDT) Received: from there (nas-cbv-8-62-147-159-122.dial.proxad.net [62.147.159.122]) by postfix2-1.free.fr (Postfix) with SMTP id D9E1F41D for ; Sun, 14 Apr 2002 13:47:29 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Sun, 14 Apr 2002 01:00:58 +0200 X-Mailer: KMail [version 1.3.2] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> In-Reply-To: <20020411120241.01935@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414114729.D9E1F41D@postfix2-1.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > >From my point of view, the dnet project is a specific part of the > > application domain of F-CPU. Can i point that crypto is used in > > communication (like in SSH) and storage (encrypted filesystems) ? > > This means that if we find something interesting when examining dnet, > > it can also enhance the performance of a normal computer that works > > in a secured environment, such as an internet server. It is maybe > > worth noting it and may explain why i don't focus exclusively on > > RC5 cracking (though i know it's a good entry point and a "cool way" > > to make others think about F-CPU). > Crypto stuff may be "cool", but something that fits into the L1 cache > doesn't qualify as a real application, IMHO :) Besides that, many crypto > algorithms can be done better (and faster) in dedicated hardware. Ok, DNETC-RC5 is a real application, it's why I decided to implement it. When I will finished to port in, I will perhaps look to cryptographic algorithm (like AES), but that an other discussion. What I want to do by the port of the dnetc client is to see where we can have problem with our instruction set on high parellisable algorithm. The conclusion of this discussion is that we will have a "real" simd rotl, but not because of this algorithm, but because we want a "clean" CPU. > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > necessarily faster, but it can handle large working sets. Therefore > I'd rather focus on scientific applications, databases and so on. Yes, but we need to start from a point, if you have some idee of which algorithm or part of program to port, say it here, and if some one have time he can start to port them. > > The case of dnet is looking different but i can't involve myself > > in this now. The case of the SIMD shift has been proved and there > > does not seem to be any difficulty in implementing it with F-CPU, > > we simply disagree on a "small" implementation detail :-) > Huh? No difficulty? I see your last post, so you find a solution, no ? ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Apr 14 06:40:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wmbB-0000Ha-00 for ; Sun, 14 Apr 2002 18:11:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Apr 2002 18:11:29 +0200 (CEST) Received: (qmail 24974 invoked by uid 0); 14 Apr 2002 11:47:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 14 Apr 2002 11:47:38 -0000 Received: by moria.seul.org (Postfix) id DF235146807; Sun, 14 Apr 2002 07:47:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DAD35146805; Sun, 14 Apr 2002 07:47:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 198ED146801 for ; Sun, 14 Apr 2002 07:47:34 -0400 (EDT) Received: from there (nas-cbv-8-62-147-159-122.dial.proxad.net [62.147.159.122]) by postfix2-1.free.fr (Postfix) with SMTP id 560CA3CF for ; Sun, 14 Apr 2002 13:47:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Sun, 14 Apr 2002 06:40:50 +0200 X-Mailer: KMail [version 1.3.2] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> In-Reply-To: <3CB4DB20.F2572054@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414114731.560CA3CF@postfix2-1.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I must add something before repplying to your post. The objectif of the > > dnetc project is to break the rc5 keys. So you increment the keys and you > > verify if it decrypt the bloc they give to you. > fine, however i don't see where the verification is performed. > > From my point of view, the dnet project is a specific part of the > application domain of F-CPU. Can i point that crypto is used in > communication (like in SSH) and storage (encrypted filesystems) ? > This means that if we find something interesting when examining dnet, > it can also enhance the performance of a normal computer that works > in a secured environment, such as an internet server. It is maybe > worth noting it and may explain why i don't focus exclusively on > RC5 cracking (though i know it's a good entry point and a "cool way" > to make others think about F-CPU). Hum, the objectif is not to implement a RC5 cracking client, but to see what are the problem with our special F-CPU stuff (variable SIMD). > no because it will reside in a smaller loop, with maybe > do { > ROUND3EVEN (S1[i], S2[i], S3[i], S4[i]); > ROUND3ODD (S1[i+1], S2[i+1], S3[i+1], S4[i+1]); > i+=2; > } while (i<12); I think that to solve this discussion the best way is to code a virtual machin for FC-0, with cycle count, so that we can see what is the best implementation. > in asm, we will need 4 pointer registers (renamed S1 to S4) > and they use post-incremented addressing. The time to execute the > block is enough to pre-load the LSU for the next "round" (loop cycle). > > > This means that we can loop several with a loop core containing > > > 4 rounds (either parallel or sequential) or less. > > Well, where did this 4th round came from ? > look at the code i copied at the top of the mail : > i count 12 "ROUND3EVEN" and "ROUND3ODD" : these are "rounds" > as the name says. Look at a crypto book, it's the Feistel > structure denomination). and you can remark that 24/2=12. > Now if we put 2*"ROUND3EVEN" and 2*"ROUND3ODD" in the loop body, > we can loop 6* and spare some number of registers that can be > assigned to other duties, such as searching other keys. Perhaps, perhaps not, because you will need more memory bandwith to use this register to compute other keys. The second problem is that you will have a bigger loop to attack all the register. I think that your solution need to much band with for data and instruction... > > > I see no particular reason why we would be forced to use ALL > > > the registers for a single key. > > Not for a single key, but for 4 keys. > ok, ok, but what if there was a mean to search 8 keys or maybe even 12 or > 16 ? i don't think it's impossible or even impracticable, and i give a > proof later in this post. The problem is that you use more memory bandwith, with latency and you will compute less key than me in the same time. The objectif is not to test 16 or more key in the same pass but to test them as quick as possible. > in this case, the difference does not appear because > - the data set fits in Dcache > - the access pattern is deterministic and linear (that is : ideal) > > In the ideal case, the distance between LSU operations on a give register > must be spaced (at least half a dozen cycles) but the result of a load is > usable _immediately_ (at first glance) after the instruction. > This means that even without auto-prefetch, there is no latency if the > distance between loads is respected. If you use all LSU lines (8 currently, > this number corresponds to the average L1 latency) you can sustain the > maximum throughput. Ok, don't forget we need to save and restore all the register. I have a suggestion about them. On x86, if you use register to put your param when you do a function call you really optimise your application. I propose to use the first 8 registers to put the return address (R1), and the first params (R2 to R8). For the returned value we put the result in R1. If we have variable number of parameter (like print) we detect it and put them on stack (R63). So with this spec we can start to work on the main calcul of the function without the need to first save them and in many case we will have enough register to work (I think that the majority of the function only use 8 registers). If the used language is C, we know that the parameter will be lost, but for language like Pascal (or one who use byRef call), that is great, you can code a function like swap for example in very few instruction : move R2, R4 move R3, R2 move R4, R3 That as quick as a macro without is border effect. (I thing that I have perhaps forgot something about this problem, because why didn't people use this type of call ?) > You can also think about the quantity of memory that is available : > - a L1 would contain 4 or 8 KB of memory > - the register set can contain 512 bytes (maximum) > A RC5 core computation seems to require around 6 registers, so it seems > possible to compute at least 8 simultaneous scalar operations (6*8=48, > still leaving some registers for other duties) and thus 16 "keys" with > a SIMD 64-bit F-CPU. This means however that the loop will contain > only one Feistel round (both even and odd), but for all 8(16) keys in > parallel. > Clearly, this means that if we implement a FC3 with 4 or 6 instructions > decoded per cycle, RC5 will still fly. > > > ok you reassure me. but then i don't see the point of your previous > > > remark. > > Perhaps, because I don't understand where you want to use this code. > RC5 is RC5, you use it to encode and decode streams (files, network > packets...). DNET uses both and performs extra stuff, so it first needs a > good understanding of RC5, and then a good overview of their cracking > strategy. > So i start with the simplest things : RC5 stream coding. False, this is not the same problem. In one case you have a big amount of random data to crypt (your stream). And in the other case you 64 bits crypted data and the 64 bits uncrypted data, and the only thing that is changing is the key (Only incremented). > > > programming is an exercise on balancing register vs memory usage, speed > > > vs memory footprint, unrolling vs factoring... in fewer words, as > > > someone on usenet write in his sig, it's an exercise on caching. > > Yes but if you look to the optimised core for K7, you will see that > > they use table, but not unrolling loop. I don't know why, but I am > > not a K7 "gourou". > i have not seen their code (there's no mention about AMD or K7 in your ANSI > codes) but from my , ... hmmmm...., "knowledge" of the architecture, it is > due to... register pressure. Sorry, but the optimised version for different core are present on their web site. I think you don't understand me, they use unrolled loop, and I don't find any core that use a "rolled" loop, so why ? > hey, you can sustain 256 bits per cycle of bandwidth from and to L1 ! > the bandwidth is here to be used :-) If you have a "core" that fits in 1000 > instructions, it's ok (fits in 4KB of Icache). But the LSU is here to > relieve the register set from temporarily unused data and it's dumb to not > use it because as long as it fits in L1, you feel no latency. Ok, I now understand your point of view. I think that only a good virtual machin can say who as the best solution. > from what is written above, it's possible to do 16 keys with a 64-bit CPU. > Mega-quote : ----> "Use the cache, Luke" ;-P <----- I understood, master ;-) But I think that you too much cache. > a "round" in the Feistel structure is the thing that is defined in the > macro (where the computation is performed). The main code instanciates the > macro 12x, this means that there are 12 "rounds" (plaintext attack on RC5 > is the only known solution when 16 rounds are used, according to Schneier). > What you seem to call "round" is the higher level of the DNET code, > where the S variables are generated, then text is encrypted and finally > decrypted. maybe i missed a few thousands stuffs, but "ROUND3xxx" means > that it's the 3rd kind of round, not the 3rd round. Ok, I speak about the DNET round, and you the Schneier round. > i'm just contemplating using FC0 in a secured environment where lots of > data must be encrypted. because we don't have to recompute S all the time, > the stream can be really fast (a 1st generation FC0 could at least not > blush when compared to faster CPUs). Ok, but that's not our current problem. > > ok, if you want all the source code for this project go to their web > > site. But they have a lot of different project and RC5 his the one of the > > oldest. > ??? is there a recommended URL for the source ? www.distributed.net ;-) > ooops i should not type with my mittens on ;-) > "melting" point, or "it's not a bottleneck" because L1 bandwidth > is not a problem when data is accessed with regular patterns. Ok, I understand. > it's the same as when your computer "swaps" to the hard disk : > it is because it requires more memory than physically available, > so it uses some slower, larger temporary storage. > The same goes with L1, L2 etc... Ok, I understand this too. > mmmmm from what i read, with 32 registers it's possible to compute 4 keys : > what did i miss ? maybe the compiler automatically maps the S variables > to memory, don't you think ? > let's count : > > u32 kiter = 0; > > u32 keycount = tslice; > > 2 > > > u32 S1_00,S1_01,S1_02,S1_03,S1_04,S1_05,S1_06,S1_07,S1_08,S1_09, > > S1_10,S1_11,S1_12,S1_13,S1_14,S1_15,S1_16,S1_17,S1_18,S1_19, > > S1_20,S1_21,S1_22,S1_23,S1_24,S1_25; > > 26 > > > u32 S2_00,S2_01,S2_02,S2_03,S2_04,S2_05,S2_06,S2_07,S2_08,S2_09, > > S2_10,S2_11,S2_12,S2_13,S2_14,S2_15,S2_16,S2_17,S2_18,S2_19, > > S2_20,S2_21,S2_22,S2_23,S2_24,S2_25; > > 26 > > > u32 S3_00,S3_01,S3_02,S3_03,S3_04,S3_05,S3_06,S3_07,S3_08,S3_09, > > S3_10,S3_11,S3_12,S3_13,S3_14,S3_15,S3_16,S3_17,S3_18,S3_19, > > S3_20,S3_21,S3_22,S3_23,S3_24,S3_25; > > 26 > > > u32 S4_00,S4_01,S4_02,S4_03,S4_04,S4_05,S4_06,S4_07,S4_08,S4_09, > > S4_10,S4_11,S4_12,S4_13,S4_14,S4_15,S4_16,S4_17,S4_18,S4_19, > > S4_20,S4_21,S4_22,S4_23,S4_24,S4_25; > > 26 > > this part is more interesting : > > u32 A1, Llo1, Lhi1; > > u32 A2, Llo2, Lhi2; > > u32 A3, Llo3, Lhi3; > > u32 A4, Llo4, Lhi4; > > u32 tmp1, tmp2, tmp3, tmp4; > > 12+4=16 you forgot eA1, eA2, eA3, eA4, eB1, eB2, eB3 and eB4 > the total number is 16 + 26*4 + 2 = 122 total number = 130... > So if i count correctly, you can fit this in the F-CPU register set > simply because a 64-bit SIMD register can contain 2*u32. > Then you can remove some of the code that loads the S, but you have > to re-schedule the macros because temp1 to temp4 may be useless. > at least "tmp1 = S1N;" etc. can be removed (register name inference). Of course, I reschedule the macro to complain with F-CPU coding rules. > Later, i see : "u32 cS0, Q;" > and "u32 eA1, eB1, eA2, eB2, eA3, eB3, eA4, eB4;" > so it adds 5 more registers : argh. Ah, you see them (cS0 and Q are constant so that not realy a problem). So you understand my current problem. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Apr 14 14:48:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wmbC-0000Ha-00 for ; Sun, 14 Apr 2002 18:11:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Apr 2002 18:11:30 +0200 (CEST) Received: (qmail 26722 invoked by uid 0); 14 Apr 2002 13:37:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 14 Apr 2002 13:37:49 -0000 Received: by moria.seul.org (Postfix) id DBE69146800; Sun, 14 Apr 2002 09:37:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C7667146802; Sun, 14 Apr 2002 09:37:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 4D159146800 for ; Sun, 14 Apr 2002 09:37:46 -0400 (EDT) Received: from ifrance.com (vlt10-146.n.club-internet.fr [195.36.224.146]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 5EC2E16FC for ; Sun, 14 Apr 2002 15:37:44 +0200 (CEST) Message-ID: <3CB97AA8.40D40B2@ifrance.com> Date: Sun, 14 Apr 2002 14:48:40 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <1018221673.3cb0d469f0a2e@imp.free.fr> <3CB0E5BB.878D4945@f-cpu.org> <1018305779.3cb21cf3b6b10@imp3-1.free.fr> <3CB25124.AF25C366@f-cpu.org> <1018365035.3cb3046bc7646@imp.free.fr> <3CB321F0.93FCD9BE@f-cpu.org> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <3CB66B99.F0B2658A@f-cpu.org> <20020412121643.07872@thrai.stud.uni-hannover.de> <3CB79FEE.65926D13@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : <...> > > > > but it can handle large working sets. Therefore > > > > I'd rather focus on scientific applications, databases and so on. > > > don't worry, this will follow naturally, but how many scientists do you > > > know around F-CPU ?... > > Do I have to *know* them? ;) > that can help. > > For example, a CFD scientist has explained me how the newest algos > work, and they WILL benefit from very wide SIMD cores (contrarily > to what nicO said). the limiting factor is of course the RAM bandwidth, > as it deals with gigabytes of 3D data... but i have developped > a strip-mining stategy that helps :-) > I don't know what you mean about CFD scientist. I imagine that it is always possible to change dependancies inside an algorythme by using a temporary array. So you break a strong dependancies, but you increase (double ?) the memory bandwith demand. Never forget that fcpu need to performe well in a vast majority of task and writing specific code for fcpu will represente less than 1% of the code. If your compiler didn't know how to change your algorythme to use special trick, this trick aren't usefull at all. Nobody will rewrite millions man.hours of code soon made. The limit of ~256 bit (paquet of 64 bit floating point register) are fixed by using a new vectorising technique on the programme used in the spec benchmark. This program are real world one and fcpu will be judged in front of such benchmark. If the couple compiler+fcpu couldn't use efficently more than 256 bits, it will be unreallistic to use it from an economical point of view for only very few specific program. (If you ever used scp instead of ftp to transfert datas you will understood why fast encryption are needed.) nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 14 21:15:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX2-000504-00 for ; Mon, 15 Apr 2002 01:35:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:40 +0200 (CEST) Received: (qmail 26954 invoked by uid 0); 14 Apr 2002 22:11:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 14 Apr 2002 22:11:09 -0000 Received: by moria.seul.org (Postfix) id 373F8146801; Sun, 14 Apr 2002 18:11:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D08E146808; Sun, 14 Apr 2002 18:11:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a137.home.uni-hannover.de [130.75.232.137]) by moria.seul.org (Postfix) with ESMTP id E9DEE146801 for ; Sun, 14 Apr 2002 18:11:03 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01904; Sun, 14 Apr 2002 21:15:55 +0200 Message-ID: <20020414211555.54638@thrai.stud.uni-hannover.de> Date: Sun, 14 Apr 2002 21:15:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <20020414114729.D9E1F41D@postfix2-1.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020414114729.D9E1F41D@postfix2-1.free.fr>; from cedric on Sun, Apr 14, 2002 at 01:00:58AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 14, 2002 at 01:00:58AM +0200, cedric wrote: [...] > What I want to do by the port of the dnetc client is to see where we can have > problem with our instruction set on high parellisable algorithm. The > conclusion of this discussion is that we will have a "real" simd rotl, but > not because of this algorithm, but because we want a "clean" CPU. Who is "we" in this case? I tend to agree with you, but in general, we have to consider carefully what we include and how we do it. If the cost/benefit ratio of a particular feature is too high, we'd better drop it. > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > necessarily faster, but it can handle large working sets. Therefore > > I'd rather focus on scientific applications, databases and so on. > Yes, but we need to start from a point, if you have some idee of which > algorithm or part of program to port, say it here, and if some one have time > he can start to port them. In assembler? > > > The case of dnet is looking different but i can't involve myself > > > in this now. The case of the SIMD shift has been proved and there > > > does not seem to be any difficulty in implementing it with F-CPU, > > > we simply disagree on a "small" implementation detail :-) > > Huh? No difficulty? > I see your last post, so you find a solution, no ? ;-) Yes. But I'm still unsure what it will cost (in terms of delay time and die area). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 14 23:13:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX3-000504-00 for ; Mon, 15 Apr 2002 01:35:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:41 +0200 (CEST) Received: (qmail 25343 invoked by uid 0); 14 Apr 2002 22:11:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 14 Apr 2002 22:11:06 -0000 Received: by moria.seul.org (Postfix) id CEB48146800; Sun, 14 Apr 2002 18:11:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FE8D146802; Sun, 14 Apr 2002 18:11:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a137.home.uni-hannover.de [130.75.232.137]) by moria.seul.org (Postfix) with ESMTP id 78A91146800 for ; Sun, 14 Apr 2002 18:11:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02373; Sun, 14 Apr 2002 23:13:13 +0200 Message-ID: <20020414231312.27259@thrai.stud.uni-hannover.de> Date: Sun, 14 Apr 2002 23:13:12 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <1018455300.3cb4650422e05@imp.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020414114731.560CA3CF@postfix2-1.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020414114731.560CA3CF@postfix2-1.free.fr>; from cedric on Sun, Apr 14, 2002 at 06:40:50AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 14, 2002 at 06:40:50AM +0200, cedric wrote: [...] > I propose to use the first 8 registers to put the return address (R1), and the > first params (R2 to R8). For the returned value we put the result in R1. > If we have variable number of parameter (like print) we detect it and put > them on stack (R63). As a first guess, I'd reserve r1...r15 for arguments (r1 also holds the return value), r16...r31 for temporary use (unsaved), r32...r47 for local use (saved by the callee), and r48...r63 for special purposes (stack pointer, frame pointer, global pointers). If a function has more than 13 parameters, r14/r15 hold the number and address of additional arguments, respectively. The return address should either be stored in the `local' or in the `special purpose' register area (that is, r32...r63), in order to avoid copying in `leaf' functions (i.e. functions that don't call other functions). If it is stored in r1, you'll have to move it away in order to make room for the return value. Note that these rules do not apply if a function is only called from inside the same translation unit (in C: if the function is declared `static' and its address is not passed to other functions), or is an inline function. Local functions in Pascal-style languages may also fall into this category. [...] > If the used language is C, we know that the parameter will be lost, but for > language like Pascal (or one who use byRef call), that is great, you can code > a function like swap for example in very few instruction : > > move R2, R4 > move R3, R2 > move R4, R3 > > That as quick as a macro without is border effect. > > (I thing that I have perhaps forgot something about this problem, because why > didn't people use this type of call ?) You overlooked the fact that `var' parameters in Pascal are actually pointers, although they don't look that way. The same is true for reference types in C++. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 14 20:32:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX3-000504-01 for ; Mon, 15 Apr 2002 01:35:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:41 +0200 (CEST) Received: (qmail 12561 invoked by uid 0); 14 Apr 2002 22:11:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 14 Apr 2002 22:11:12 -0000 Received: by moria.seul.org (Postfix) id 064CE146807; Sun, 14 Apr 2002 18:11:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5F44146810; Sun, 14 Apr 2002 18:11:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a137.home.uni-hannover.de [130.75.232.137]) by moria.seul.org (Postfix) with ESMTP id 01EA9146807 for ; Sun, 14 Apr 2002 18:11:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01806; Sun, 14 Apr 2002 20:32:52 +0200 Message-ID: <20020414203252.59258@thrai.stud.uni-hannover.de> Date: Sun, 14 Apr 2002 20:32:52 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <1018306336.3cb21f20acde6@imp.free.fr> <20020410123214.06958@thrai.stud.uni-hannover.de> <20020414114728.B8E8F3CF@postfix2-1.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020414114728.B8E8F3CF@postfix2-1.free.fr>; from cedric on Sun, Apr 14, 2002 at 12:44:31AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 14, 2002 at 12:44:31AM +0200, cedric wrote: [...] > > > So, we need to patch the manual. > > In many places. I made a long list of ambiguities and errors months > > ago (e.g. look for the phrase "Dark and Dusty Corners", September 2001). > Did you post something ? (If yes give me the title of your post and I will > do the update). There's a lot of stuff in two of my mails, and the following threads. Look for Date: Wed, 15 Aug 2001 23:12:27 +0200 Subject: Re: [f-cpu] Re: Floating-Point? or Date: Mon, 3 Sep 2001 17:33:23 +0200 Subject: More Dark and Dusty Corners for details. Some points may not apply to the current version of the manual any more, however (I had no time to check that). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 15 00:26:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX4-000504-00 for ; Mon, 15 Apr 2002 01:35:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:42 +0200 (CEST) Received: (qmail 19585 invoked by uid 0); 14 Apr 2002 22:20:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 14 Apr 2002 22:20:23 -0000 Received: by moria.seul.org (Postfix) id 1865B146800; Sun, 14 Apr 2002 18:20:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B019146802; Sun, 14 Apr 2002 18:20:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 7D924146800 for ; Sun, 14 Apr 2002 18:20:20 -0400 (EDT) Received: from f-cpu.org (kdl16-34.n.club-internet.fr [213.44.18.34]) by relay-1m.club-internet.fr (Postfix) with ESMTP id B0FAE16FC for ; Mon, 15 Apr 2002 00:20:16 +0200 (CEST) Message-ID: <3CBA0226.6217BA75@f-cpu.org> Date: Mon, 15 Apr 2002 00:26:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <3CB4DB20.F2572054@f-cpu.org> <20020411120241.01935@thrai.stud.uni-hannover.de> <20020414114729.D9E1F41D@postfix2-1.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! cedric wrote: > What I want to do by the port of the dnetc client is to see where we can have > problem with our instruction set on high parellisable algorithm. The > conclusion of this discussion is that we will have a "real" simd rotl, but > not because of this algorithm, but because we want a "clean" CPU. you can write that in the README for your example :-) > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > necessarily faster, but it can handle large working sets. Therefore > > I'd rather focus on scientific applications, databases and so on. > Yes, but we need to start from a point, if you have some idee of which > algorithm or part of program to port, say it here, and if some one have time > he can start to port them. i had a first version of a 8-tap Winograd FFT that was optimised for FC0. The code is more or less ready but i wanted to add more stuff like demonstration code and a verification program (to check whether there was no error done during the algorithm's modification). > > > The case of dnet is looking different but i can't involve myself > > > in this now. The case of the SIMD shift has been proved and there > > > does not seem to be any difficulty in implementing it with F-CPU, > > > we simply disagree on a "small" implementation detail :-) > > Huh? No difficulty? > I see your last post, so you find a solution, no ? ;-) didn't i show you what i wanted to do ? - 1 SDUP stage (to propagate the control signals and/or perform sdup) - 1 shift-16 stage (made of mux-4) - 3 levels of shift-16 (made of mux-3) => we can split the pipeline after the first shift-16 I can't develop now because i'm deep into LFS problems. i wish to solve all my OS problems for good in the near future so i'll be back at VHDL programming before my own brain coredumps... > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Apr 15 05:46:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX5-000504-00 for ; Mon, 15 Apr 2002 01:35:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:43 +0200 (CEST) Received: (qmail 11368 invoked by uid 0); 14 Apr 2002 22:30:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 14 Apr 2002 22:30:24 -0000 Received: by moria.seul.org (Postfix) id C0444146800; Sun, 14 Apr 2002 18:30:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 99250146802; Sun, 14 Apr 2002 18:30:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 1BE2D146800 for ; Sun, 14 Apr 2002 18:30:21 -0400 (EDT) Received: from there (nas-cbv-8-62-147-157-210.dial.proxad.net [62.147.157.210]) by postfix3-2.free.fr (Postfix) with SMTP id 6C20E182F5 for ; Mon, 15 Apr 2002 00:30:15 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-15" From: cedric To: f-cpu@seul.org Subject: [f-cpu] RC5, last test Date: Mon, 15 Apr 2002 05:46:09 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414223015.6C20E182F5@postfix3-2.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi every body, I am currently finalising my code for the RC5 DNETC core, but I have a problem. At the end of the process I must test every chunck of two register to know if I have found the solution. The solution is easy if I know the number of the chunk, and not their size. Because during all the process I only use 32 bits chunks. So I know that every chunk has been computed well, but I don't know how to test each chunck and return the number of the chunck (to determine the key that decrypt the message). So my question is easy ;-) How can I do a test on each chunk to find the one that is null ? A+ Cedric PS: If we have this we can do in certain case algorithm that can easily change the number of data that they compute in one pass, only with changing the CPU ;-). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Apr 15 06:14:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX5-000504-01 for ; Mon, 15 Apr 2002 01:35:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:43 +0200 (CEST) Received: (qmail 3642 invoked by uid 0); 14 Apr 2002 22:58:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 14 Apr 2002 22:58:35 -0000 Received: by moria.seul.org (Postfix) id CB6E0146800; Sun, 14 Apr 2002 18:58:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC1E4146802; Sun, 14 Apr 2002 18:58:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 37539146800 for ; Sun, 14 Apr 2002 18:58:33 -0400 (EDT) Received: from there (nas-cbv-8-62-147-157-210.dial.proxad.net [62.147.157.210]) by postfix3-2.free.fr (Postfix) with SMTP id EF71017FF1 for ; Mon, 15 Apr 2002 00:58:25 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Mon, 15 Apr 2002 06:14:06 +0200 X-Mailer: KMail [version 1.3.2] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114728.B8E8F3CF@postfix2-1.free.fr> <20020414203252.59258@thrai.stud.uni-hannover.de> In-Reply-To: <20020414203252.59258@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414225825.EF71017FF1@postfix3-2.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > There's a lot of stuff in two of my mails, and the following threads. > Look for > > Date: Wed, 15 Aug 2001 23:12:27 +0200 > Subject: Re: [f-cpu] Re: Floating-Point? > > or > > Date: Mon, 3 Sep 2001 17:33:23 +0200 > Subject: More Dark and Dusty Corners > > for details. Some points may not apply to the current version of the > manual any more, however (I had no time to check that). I noted this post and I will check the manual about that. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 15 01:01:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wtX6-000504-00 for ; Mon, 15 Apr 2002 01:35:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 01:35:44 +0200 (CEST) Received: (qmail 12196 invoked by uid 0); 14 Apr 2002 23:01:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 14 Apr 2002 23:01:38 -0000 Received: by moria.seul.org (Postfix) id 2C2AE146805; Sun, 14 Apr 2002 19:01:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29A69146802; Sun, 14 Apr 2002 19:01:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a137.home.uni-hannover.de [130.75.232.137]) by moria.seul.org (Postfix) with ESMTP id 8A31C146800 for ; Sun, 14 Apr 2002 19:01:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02904; Mon, 15 Apr 2002 01:01:32 +0200 Message-ID: <20020415010131.26823@thrai.stud.uni-hannover.de> Date: Mon, 15 Apr 2002 01:01:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, last test References: <20020414223015.6C20E182F5@postfix3-2.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020414223015.6C20E182F5@postfix3-2.free.fr>; from cedric on Mon, Apr 15, 2002 at 05:46:09AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 15, 2002 at 05:46:09AM +0200, cedric wrote: > Hi every body, > > I am currently finalising my code for the RC5 DNETC core, but I have a > problem. At the end of the process I must test every chunck of two register > to know if I have found the solution. > > The solution is easy if I know the number of the chunk, and not their size. > Because during all the process I only use 32 bits chunks. So I know that > every chunk has been computed well, but I don't know how to test each chunck > and return the number of the chunck (to determine the key that decrypt the > message). > > So my question is easy ;-) How can I do a test on each chunk to find the > one that is null ? For a quick test whether *any* of the chunks of is zero, use one of these: scmple.32 r0, , r1 scmpli.32 $1, , r1 After that, you can use lsb1/msb1 to find the first/last chunk. Another option is to tear the chunks apart and test them separately, e.g. via and, mix/expand or shift instructions, whatever fits your needs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Apr 15 06:20:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wuZF-0005l5-00 for ; Mon, 15 Apr 2002 02:42:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 02:42:01 +0200 (CEST) Received: (qmail 13459 invoked by uid 0); 14 Apr 2002 23:04:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 14 Apr 2002 23:04:33 -0000 Received: by moria.seul.org (Postfix) id 54C1A146800; Sun, 14 Apr 2002 19:04:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F01A146802; Sun, 14 Apr 2002 19:04:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id D1E87146800 for ; Sun, 14 Apr 2002 19:04:30 -0400 (EDT) Received: from there (nas-cbv-8-62-147-157-210.dial.proxad.net [62.147.157.210]) by postfix3-2.free.fr (Postfix) with SMTP id 079E718232 for ; Mon, 15 Apr 2002 01:04:29 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Mon, 15 Apr 2002 06:20:20 +0200 X-Mailer: KMail [version 1.3.2] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114729.D9E1F41D@postfix2-1.free.fr> <20020414211555.54638@thrai.stud.uni-hannover.de> In-Reply-To: <20020414211555.54638@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020414230429.079E718232@postfix3-2.free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > What I want to do by the port of the dnetc client is to see where we can > > have problem with our instruction set on high parellisable algorithm. The > > conclusion of this discussion is that we will have a "real" simd rotl, > > but not because of this algorithm, but because we want a "clean" CPU. > Who is "we" in this case? ;-) > I tend to agree with you, but in general, we have to consider carefully > what we include and how we do it. If the cost/benefit ratio of a > particular feature is too high, we'd better drop it. I agree with you, but I think that about the particular case on wich we discuss it's not a bad add (I agree that will depend a lot about your SHL unit). > > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not > > > necessarily faster, but it can handle large working sets. Therefore > > > I'd rather focus on scientific applications, databases and so on. > > > > Yes, but we need to start from a point, if you have some idee of which > > algorithm or part of program to port, say it here, and if some one have > > time he can start to port them. > In assembler? Yes, for example, ffmepg or whatever you thing it will be a good idea to look at this code to see where we can have problem with our instruction set. > > > > The case of dnet is looking different but i can't involve myself > > > > in this now. The case of the SIMD shift has been proved and there > > > > does not seem to be any difficulty in implementing it with F-CPU, > > > > we simply disagree on a "small" implementation detail :-) > > > Huh? No difficulty? > > I see your last post, so you find a solution, no ? ;-) > Yes. But I'm still unsure what it will cost (in terms of delay time and > die area). I understand that not an easy task, but you will, I am sure, find a solution ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 15 02:04:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16wuZG-0005l5-00 for ; Mon, 15 Apr 2002 02:42:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 02:42:02 +0200 (CEST) Received: (qmail 29216 invoked by uid 0); 15 Apr 2002 00:04:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 15 Apr 2002 00:04:15 -0000 Received: by moria.seul.org (Postfix) id B7A00146801; Sun, 14 Apr 2002 20:04:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85885146800; Sun, 14 Apr 2002 20:04:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a137.home.uni-hannover.de [130.75.232.137]) by moria.seul.org (Postfix) with ESMTP id 43A92146800 for ; Sun, 14 Apr 2002 20:04:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA03068; Mon, 15 Apr 2002 02:04:07 +0200 Message-ID: <20020415020407.26879@thrai.stud.uni-hannover.de> Date: Mon, 15 Apr 2002 02:04:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114729.D9E1F41D@postfix2-1.free.fr> <20020414211555.54638@thrai.stud.uni-hannover.de> <20020414230429.079E718232@postfix3-2.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020414230429.079E718232@postfix3-2.free.fr>; from cedric on Mon, Apr 15, 2002 at 06:20:20AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 15, 2002 at 06:20:20AM +0200, cedric wrote: [...] > > > Yes, but we need to start from a point, if you have some idee of which > > > algorithm or part of program to port, say it here, and if some one have > > > time he can start to port them. > > In assembler? > Yes, for example, ffmepg or whatever you thing it will be a good idea to look > at this code to see where we can have problem with our instruction set. Lots of things... - common (de)compression algorithms (LZW/LZ77, BWT) - audio and image manipulation (digital filters) - arbitrary-precision integer math (e.g. libgmp) - string operations (strlen, strcpy, strcmp, strspn and so on) - floating-point emulation (in case we do not implement an FPU in FC0) - alle those nifty functions from - vector and matrix operations - basic graphics drawing operations (points, lines, arcs, splines, ...) - C and Pascal style function entry/exit frames and function calls - basic framework for interrupt and exception handlers - a simple garbage collector (stop-and-copy or something like that) - a more sophisticated GC (incremental, with fences) - a TLB miss handler - digest functions - 16/32-bit CRC, MD5, TCP/IP compatible checksum - DES and AES cores - a Mandelbrot engine - a FORTH interpreter - binary search - tree search - quicksort ... and probably much more. On the other hand, you could also get a copy of `The Art Of Computer Programming' and port everything to the F-CPU :) [...] > > > I see your last post, so you find a solution, no ? ;-) > > Yes. But I'm still unsure what it will cost (in terms of delay time and > > die area). > I understand that not an easy task, but you will, I am sure, find a solution > ;-) Don't I always? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 15 08:38:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xBSQ-0000G2-00 for ; Mon, 15 Apr 2002 20:44:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 20:44:06 +0200 (CEST) Received: (qmail 3192 invoked by uid 0); 15 Apr 2002 06:31:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 15 Apr 2002 06:31:56 -0000 Received: by moria.seul.org (Postfix) id 3D44B14681F; Mon, 15 Apr 2002 02:31:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 355E1146819; Mon, 15 Apr 2002 02:31:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 7CDBB146810 for ; Mon, 15 Apr 2002 02:31:49 -0400 (EDT) Received: from f-cpu.org (kdl11-65.n.club-internet.fr [213.44.9.65]) by relay-1m.club-internet.fr (Postfix) with ESMTP id CF1B716DB for ; Mon, 15 Apr 2002 08:31:45 +0200 (CEST) Message-ID: <3CBA7556.F1498D7D@f-cpu.org> Date: Mon, 15 Apr 2002 08:38:14 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114729.D9E1F41D@postfix2-1.free.fr> <20020414211555.54638@thrai.stud.uni-hannover.de> <20020414230429.079E718232@postfix3-2.free.fr> <20020415020407.26879@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Mon, Apr 15, 2002 at 06:20:20AM +0200, cedric wrote: > [...] > > > > Yes, but we need to start from a point, if you have some idee of which > > > > algorithm or part of program to port, say it here, and if some one have > > > > time he can start to port them. > > > In assembler? > > Yes, for example, ffmepg or whatever you thing it will be a good idea to look > > at this code to see where we can have problem with our instruction set. > > Lots of things... > > - common (de)compression algorithms (LZW/LZ77, BWT) > - audio and image manipulation (digital filters) > - arbitrary-precision integer math (e.g. libgmp) > - string operations (strlen, strcpy, strcmp, strspn and so on) > - floating-point emulation (in case we do not implement an FPU in FC0) > - alle those nifty functions from > - vector and matrix operations > - basic graphics drawing operations (points, lines, arcs, splines, ...) > - C and Pascal style function entry/exit frames and function calls > - basic framework for interrupt and exception handlers > - a simple garbage collector (stop-and-copy or something like that) > - a more sophisticated GC (incremental, with fences) > - a TLB miss handler > - digest functions - 16/32-bit CRC, MD5, TCP/IP compatible checksum > - DES and AES cores > - a Mandelbrot engine > - a FORTH interpreter > - binary search > - tree search > - quicksort only ? > ... and probably much more. On the other hand, you could also get a copy > of `The Art Of Computer Programming' and port everything to the F-CPU :) hmmmm i have a limited life length, you know ;-) and i have only completed the 5th chapter of the LFS book. give me some time before i can hack again :-) > [...] > > > > I see your last post, so you find a solution, no ? ;-) > > > Yes. But I'm still unsure what it will cost (in terms of delay time and > > > die area). > > I understand that not an easy task, but you will, I am sure, find a solution > > ;-) > Don't I always? ;) your _real_ value is that you choose your challenges carefully ;-) not like me ... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 15 08:38:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xBSR-0000G2-00 for ; Mon, 15 Apr 2002 20:44:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Apr 2002 20:44:07 +0200 (CEST) Received: (qmail 23345 invoked by uid 0); 15 Apr 2002 06:31:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 15 Apr 2002 06:31:59 -0000 Received: by moria.seul.org (Postfix) id 6700F146812; Mon, 15 Apr 2002 02:31:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BD47146817; Mon, 15 Apr 2002 02:31:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id EA8BF146812 for ; Mon, 15 Apr 2002 02:31:50 -0400 (EDT) Received: from f-cpu.org (kdl11-65.n.club-internet.fr [213.44.9.65]) by relay-1m.club-internet.fr (Postfix) with ESMTP id EA43016E8 for ; Mon, 15 Apr 2002 08:31:47 +0200 (CEST) Message-ID: <3CBA7558.F25EA952@f-cpu.org> Date: Mon, 15 Apr 2002 08:38:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, last test References: <20020414223015.6C20E182F5@postfix3-2.free.fr> <20020415010131.26823@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Apr 15, 2002 at 05:46:09AM +0200, cedric wrote: > > Hi every body, > > > > I am currently finalising my code for the RC5 DNETC core, but I have a > > problem. At the end of the process I must test every chunck of two register > > to know if I have found the solution. > > > > The solution is easy if I know the number of the chunk, and not their size. > > Because during all the process I only use 32 bits chunks. So I know that > > every chunk has been computed well, but I don't know how to test each chunck > > and return the number of the chunck (to determine the key that decrypt the > > message). > > > > So my question is easy ;-) How can I do a test on each chunk to find the > > one that is null ? > > For a quick test whether *any* of the chunks of is zero, use > one of these: > > scmple.32 r0, , r1 > scmpli.32 $1, , r1 > > After that, you can use lsb1/msb1 to find the first/last chunk. > Another option is to tear the chunks apart and test them separately, > e.g. via and, mix/expand or shift instructions, whatever fits your needs. with 8-bit chunks, there is also a way to do this, using the "combine" option of the ROP2 unit. but the critical datapath of ROP2 is too tight to allow 32-bit version of this. However the idea is simple : for each chunk, mask out the corresponding field and do a conditional jump. in the current case, the masks are less straight-forward so i'll simply shift ... r1 = SIMD input (2*32) move r1, r2; shli 32, r1, r3; shri 32, r2, r4; if r3==0 jmp [rX]; (cjump) if r4==0 jmp [rX]; yes, it's far easier with the combine instructions but it's just a matter of time and efforts before it is implemented. It would simply look like and.or.32 r0,r1,r2; // i'm not sure about the syntax // 1 or 2 cycle stall (depends on the operand size) if r2==0 jmp [rX]; but the target of the jump would have to test each chunk individually. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@none.de Mon Apr 15 23:36:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqJ-0002Xv-00 for ; Tue, 16 Apr 2002 00:20:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:20:59 +0200 (CEST) Received: (qmail 16091 invoked by uid 0); 15 Apr 2002 19:36:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 15 Apr 2002 19:36:18 -0000 Received: by moria.seul.org (Postfix) id E1E011468D4; Mon, 15 Apr 2002 15:36:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D99BE1468D6; Mon, 15 Apr 2002 15:36:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id BAEB81468D4 for ; Mon, 15 Apr 2002 15:36:14 -0400 (EDT) Received: from art1.none.de ([62.27.157.62]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g3FJaGr05292 for ; Mon, 15 Apr 2002 21:36:17 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.157.62] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16xE93-0000KR-00 for ; Mon, 15 Apr 2002 23:36:17 +0200 Date: Mon, 15 Apr 2002 23:36:13 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl In-Reply-To: <20020415020407.26879@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > - a FORTH interpreter That is a very well idea. forth is easy to learn, forth-programs are easy to debug and a forth-interpreter is easy to write. And forth is a good point to start experiments with development on F-CPU... But, could we really map a stack-based language to a register-machine like F-CPU is? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8u0fRClxplZklbgERAqlNAJ4uhhFgJJP5mUJ4qOP8lr2rDzzQigCgl4kb ucM6H4XSu4zKa8RJSafGxpI= =yn/E -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@none.de Mon Apr 15 23:40:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqJ-0002Xv-01 for ; Tue, 16 Apr 2002 00:21:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:20:59 +0200 (CEST) Received: (qmail 22733 invoked by uid 0); 15 Apr 2002 19:40:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 15 Apr 2002 19:40:50 -0000 Received: by moria.seul.org (Postfix) id D681D1468D5; Mon, 15 Apr 2002 15:40:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BB82D1468D7; Mon, 15 Apr 2002 15:40:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 2856D1468D5 for ; Mon, 15 Apr 2002 15:40:46 -0400 (EDT) Received: from art1.none.de ([62.27.157.62]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g3FJeor05757 for ; Mon, 15 Apr 2002 21:40:50 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.157.62] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16xEDT-0000Km-00 for ; Mon, 15 Apr 2002 23:40:51 +0200 Date: Mon, 15 Apr 2002 23:40:47 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: [f-cpu] Assembler short reference? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, is there anywhere a short reference to code in f-cpu-assembler? Because, we need this thing to feed all the waiting mad folks inventing things like brainfuck and so on.... Are there? Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8u0jiClxplZklbgERAp+WAJ9XLY9kxSNSWxeBb9Npa1U70l1mLgCeI22Y L8oF3KohUxtOP4tdCSec7H0= =I7Yl -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 16 04:09:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqM-0002Xv-01 for ; Tue, 16 Apr 2002 00:21:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:02 +0200 (CEST) Received: (qmail 3119 invoked by uid 0); 15 Apr 2002 20:53:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 15 Apr 2002 20:53:39 -0000 Received: by moria.seul.org (Postfix) id 5A0A91468D6; Mon, 15 Apr 2002 16:53:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 549671468D8; Mon, 15 Apr 2002 16:53:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id D45661468D6 for ; Mon, 15 Apr 2002 16:53:37 -0400 (EDT) Received: from gaia (nas-cbv-6-62-147-150-85.dial.proxad.net [62.147.150.85]) by postfix1-2.free.fr (Postfix) with ESMTP id 3B06CAB13D for ; Mon, 15 Apr 2002 22:53:36 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Assembler short reference? Date: Tue, 16 Apr 2002 04:09:34 +0200 X-Mailer: KMail [version 1.4] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204160409.34879.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Hello, > is there anywhere a short reference to code in f-cpu-assembler? > Because, we need this thing to feed all the waiting mad folks inventing > things like brainfuck and so on.... I don't really understand what you want. An up-to-date manual is it enough ? > Are there? > Bye Andreas A+ Cedric PS: Is it you that maintain our CVS ? If it's you, can I have an account on it ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 16 04:12:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqN-0002Xv-00 for ; Tue, 16 Apr 2002 00:21:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:03 +0200 (CEST) Received: (qmail 23741 invoked by uid 0); 15 Apr 2002 20:56:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 15 Apr 2002 20:56:35 -0000 Received: by moria.seul.org (Postfix) id 78F361468D7; Mon, 15 Apr 2002 16:56:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69A5D1468DA; Mon, 15 Apr 2002 16:56:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id DEF0C1468D7 for ; Mon, 15 Apr 2002 16:56:32 -0400 (EDT) Received: from gaia (nas-cbv-6-62-147-150-85.dial.proxad.net [62.147.150.85]) by postfix1-2.free.fr (Postfix) with ESMTP id 7BD7AAB562 for ; Mon, 15 Apr 2002 22:56:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Tue, 16 Apr 2002 04:12:30 +0200 X-Mailer: KMail [version 1.4] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414230429.079E718232@postfix3-2.free.fr> <20020415020407.26879@thrai.stud.uni-hannover.de> In-Reply-To: <20020415020407.26879@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204160412.30204.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well, that an interesting list. I think that we must put it on a web page and ask for software developper. I think, it's time. A+ Cedric > Lots of things... > > - common (de)compression algorithms (LZW/LZ77, BWT) > - audio and image manipulation (digital filters) > - arbitrary-precision integer math (e.g. libgmp) > - string operations (strlen, strcpy, strcmp, strspn and so on) > - floating-point emulation (in case we do not implement an FPU in FC0) > - alle those nifty functions from > - vector and matrix operations > - basic graphics drawing operations (points, lines, arcs, splines, ...) > - C and Pascal style function entry/exit frames and function calls > - basic framework for interrupt and exception handlers > - a simple garbage collector (stop-and-copy or something like that) > - a more sophisticated GC (incremental, with fences) > - a TLB miss handler > - digest functions - 16/32-bit CRC, MD5, TCP/IP compatible checksum > - DES and AES cores > - a Mandelbrot engine > - a FORTH interpreter > - binary search > - tree search > - quicksort > > ... and probably much more. On the other hand, you could also get a copy > of `The Art Of Computer Programming' and port everything to the F-CPU :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 16 04:37:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqN-0002Xv-01 for ; Tue, 16 Apr 2002 00:21:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:03 +0200 (CEST) Received: (qmail 28593 invoked by uid 0); 15 Apr 2002 21:21:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 15 Apr 2002 21:21:25 -0000 Received: by moria.seul.org (Postfix) id 85C9B1468D8; Mon, 15 Apr 2002 17:21:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D6951468DD; Mon, 15 Apr 2002 17:21:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 9CC411468D8 for ; Mon, 15 Apr 2002 17:21:22 -0400 (EDT) Received: from gaia (nas-cbv-6-62-147-150-85.dial.proxad.net [62.147.150.85]) by postfix3-2.free.fr (Postfix) with ESMTP id 354E21800B for ; Mon, 15 Apr 2002 23:21:20 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Register allocation when calling a function Date: Tue, 16 Apr 2002 04:37:18 +0200 X-Mailer: KMail [version 1.4] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114731.560CA3CF@postfix2-1.free.fr> <20020414231312.27259@thrai.stud.uni-hannover.de> In-Reply-To: <20020414231312.27259@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204160437.18048.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nobody reply to your post, but I think it's very important to include this recommandation into the manual for those who want to implement a compiler or code in F-CPU ASM. > > I propose to use the first 8 registers to put the return address (R1), > > and the first params (R2 to R8). For the returned value we put the result > > in R1. If we have variable number of parameter (like print) we detect it > > and put them on stack (R63). > As a first guess, I'd reserve r1...r15 for arguments (r1 also holds > the return value), r16...r31 for temporary use (unsaved), r32...r47 > for local use (saved by the callee), and r48...r63 for special purposes > (stack pointer, frame pointer, global pointers). If a function has more > than 13 parameters, r14/r15 hold the number and address of additional > arguments, respectively. I never see a function with more than 10 arguments, and the one who have more must be put in memory (like print). I think that r1 to r10 will be enough. But it's really important, because this register are in the same case as the r16..r31 unsaved register. > The return address should either be stored in the `local' or in the > `special purpose' register area (that is, r32...r63), in order to avoid > copying in `leaf' functions (i.e. functions that don't call other > functions). If it is stored in r1, you'll have to move it away in > order to make room for the return value. Oups, you are right. > Note that these rules do not apply if a function is only called from > inside the same translation unit (in C: if the function is declared > `static' and its address is not passed to other functions), or is an > inline function. Local functions in Pascal-style languages may also fall > into this category. Of course if a function is in the same translation unit (like static), it will be included into the calling function. > > If the used language is C, we know that the parameter will be lost, but > > for language like Pascal (or one who use byRef call), that is great, you > > can code a function like swap for example in very few instruction : > > move R2, R4 > > move R3, R2 > > move R4, R3 > > That as quick as a macro without is border effect. > > (I thing that I have perhaps forgot something about this problem, because > > why didn't people use this type of call ?) > You overlooked the fact that `var' parameters in Pascal are actually > pointers, although they don't look that way. The same is true for > reference types in C++. That depend on your compiler, no ? So who disagree with adding this recommandation into the manual ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From djrom@altern.org Mon Apr 15 23:21:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqO-0002Xv-00 for ; Tue, 16 Apr 2002 00:21:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:04 +0200 (CEST) Received: (qmail 23224 invoked by uid 0); 15 Apr 2002 21:22:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 15 Apr 2002 21:22:06 -0000 Received: by moria.seul.org (Postfix) id 4447A1468DA; Mon, 15 Apr 2002 17:22:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 30BE91468DE; Mon, 15 Apr 2002 17:22:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-1-76.abo.wanadoo.fr [193.251.185.76]) by moria.seul.org (Postfix) with ESMTP id 50C501468DA for ; Mon, 15 Apr 2002 17:22:04 -0400 (EDT) Received: from maturin ([127.0.0.1] helo=localhost.localdomain) by maturin with esmtp (Exim 3.35 #1 (Debian)) id 16xDuy-0001zD-00 for ; Mon, 15 Apr 2002 23:21:44 +0200 Subject: [Fwd: Re: [f-cpu] RC5, F-CPU and srotl] From: djrom To: f-cpu@seul.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EPeMBY0sDOul627VV8T5" X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 23:21:44 +0200 Message-Id: <1018905704.28887.3.camel@maturin> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --=-EPeMBY0sDOul627VV8T5 Content-Type: multipart/mixed; boundary="=-EUTf5M0R6njbHaL8YKnh" --=-EUTf5M0R6njbHaL8YKnh Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable --=20 PGP keyserver: pgp.mit.edu "Ne laissons pas les chacals brouter nos id=E9als" -- T=EAtes Raides --=-EUTf5M0R6njbHaL8YKnh Content-Disposition: inline Content-Description: Message suivi - Re: [f-cpu] RC5, F-CPU and srotl Content-Type: message/rfc822 Return-Path: Delivered-To: djrom@altern.org Received: (qmail 1294 invoked by alias); 15 Apr 2002 21:20:38 -0000 Received: from unknown (HELO maturin) (193.251.185.76) by altern.org with SMTP; 15 Apr 2002 21:20:38 -0000 Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16xDtq-0001yr-00 for ; Mon, 15 Apr 2002 23:20:34 +0200 Date: Mon, 15 Apr 2002 23:20:34 +0200 From: djrom To: djrom Subject: Re: [f-cpu] RC5, F-CPU and srotl Message-Id: <20020415232034.6f59cc4b.pash.cracken@free.fr> In-Reply-To: <1018905303.5112.1.camel@maturin> References: <1018905303.5112.1.camel@maturin> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: Content-Transfer-Encoding: quoted-printable I've already implemented some Forth for x86 and I tell you, it's going to b= e a real pleasure to implement a Forth on the F-Cpu. With so many registers, you can have stack pointers, A register, TOS ans SO= S mapped to registers without brainstorms like in x86. No, it will be reall= y nice to write a Forth for F0.=20 BTW, is there any way to compile & execute code for the F0 ? I might be int= errested in doing some assembler coding, why not a Forth interpreter, but i= t's gonna to be hard if I must do hand-testing for the code :-) --=-EUTf5M0R6njbHaL8YKnh-- --=-EPeMBY0sDOul627VV8T5 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Pour information voir http://www.gnupg.org iD8DBQA8u0RoPjsv8VTg8fURAlVqAKCvrnI3J6mLEwseuflNtJnVVo1e7gCfWEOe l96EWITWx8Yxi2erKpEddAQ= =t60o -----END PGP SIGNATURE----- --=-EPeMBY0sDOul627VV8T5-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 16 04:41:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqP-0002Xv-00 for ; Tue, 16 Apr 2002 00:21:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:05 +0200 (CEST) Received: (qmail 16505 invoked by uid 0); 15 Apr 2002 21:25:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 15 Apr 2002 21:25:33 -0000 Received: by moria.seul.org (Postfix) id 8BAE11468E1; Mon, 15 Apr 2002 17:25:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 892341468DF; Mon, 15 Apr 2002 17:25:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 06A5D1468DD for ; Mon, 15 Apr 2002 17:25:31 -0400 (EDT) Received: from gaia (nas-cbv-6-62-147-150-85.dial.proxad.net [62.147.150.85]) by postfix3-2.free.fr (Postfix) with ESMTP id D7E11181F8 for ; Mon, 15 Apr 2002 23:25:29 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, last test Date: Tue, 16 Apr 2002 04:41:28 +0200 X-Mailer: KMail [version 1.4] References: <20020414223015.6C20E182F5@postfix3-2.free.fr> <20020415010131.26823@thrai.stud.uni-hannover.de> In-Reply-To: <20020415010131.26823@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204160441.28241.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > So my question is easy ;-) How can I do a test on each chunk to find the > > one that is null ? > For a quick test whether *any* of the chunks of is zero, use > one of these: > > scmple.32 r0, , r1 > scmpli.32 $1, , r1 > > After that, you can use lsb1/msb1 to find the first/last chunk. > Another option is to tear the chunks apart and test them separately, > e.g. via and, mix/expand or shift instructions, whatever fits your needs. Ok, that ok to quickly detect if in the key that I have tested I have the solution. But I want to know wich key is the right. For that I must add the number of 32 bits chunk that contain a register to the current position of the chunk that is null in the second register. For example, in the FC0, I know that I have only 2 chunks of 32 bits, then I must only add 2 to the base key to know it's value. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 16 04:51:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xEqQ-0002Xv-01 for ; Tue, 16 Apr 2002 00:21:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 00:21:06 +0200 (CEST) Received: (qmail 13527 invoked by uid 0); 15 Apr 2002 21:35:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 15 Apr 2002 21:35:59 -0000 Received: by moria.seul.org (Postfix) id C5A301468DD; Mon, 15 Apr 2002 17:35:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B71D21468DF; Mon, 15 Apr 2002 17:35:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 3A6201468DD for ; Mon, 15 Apr 2002 17:35:57 -0400 (EDT) Received: from gaia (nas-cbv-6-62-147-150-85.dial.proxad.net [62.147.150.85]) by postfix1-2.free.fr (Postfix) with ESMTP id C8F85AB2C6 for ; Mon, 15 Apr 2002 23:35:55 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-15" From: cedric To: f-cpu@seul.org Subject: Re: [Fwd: Re: [f-cpu] RC5, F-CPU and srotl] Date: Tue, 16 Apr 2002 04:51:51 +0200 X-Mailer: KMail [version 1.4] References: <1018905704.28887.3.camel@maturin> In-Reply-To: <1018905704.28887.3.camel@maturin> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204160451.51363.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I've already implemented some Forth for x86 and I tell you, it's going to be > a real pleasure to implement a Forth on the F-Cpu. > With so many registers, you can have stack pointers, A register, TOS ans SOS > mapped to registers without brainstorms like in x86. No, it will be really > nice to write a Forth for F0. > BTW, is there any way to compile & execute code for the F0 ? I might be > interrested in doing some assembler coding, why not a Forth interpreter, but > it's gonna to be hard if I must do hand-testing for the code :-) Hum, it's where we have a problem, we have a small not all function virtual machin with a GTK interface. I think that YG is coding an ASM an michael too (I am not sure). And when I will have the necessary time, I will code one. And we will need a good virtual machine that can emulate all the F-CPU asm, it must be able to simulate the latency and give us some statistic about the CPU. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 16 00:51:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xHG7-0004CI-00 for ; Tue, 16 Apr 2002 02:55:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 02:55:47 +0200 (CEST) Received: (qmail 7748 invoked by uid 0); 15 Apr 2002 22:51:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 15 Apr 2002 22:51:21 -0000 Received: by moria.seul.org (Postfix) id BECE81468DE; Mon, 15 Apr 2002 18:51:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B19341468E2; Mon, 15 Apr 2002 18:51:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a168.home.uni-hannover.de [130.75.232.168]) by moria.seul.org (Postfix) with ESMTP id 23C1E1468DE for ; Mon, 15 Apr 2002 18:51:18 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01621; Tue, 16 Apr 2002 00:51:14 +0200 Message-ID: <20020416005114.50349@thrai.stud.uni-hannover.de> Date: Tue, 16 Apr 2002 00:51:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020415020407.26879@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Mon, Apr 15, 2002 at 11:36:13PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 15, 2002 at 11:36:13PM +0200, Andreas Romeyke wrote: [...] > > - a FORTH interpreter > > That is a very well idea. forth is easy to learn, forth-programs are easy > to debug and a forth-interpreter is easy to write. And forth is a good > point to start experiments with development on F-CPU... It's also a good starting point for writing a BIOS and a bootloader (see Sun SPARC). > But, could we really map a stack-based language to a register-machine like > F-CPU is? The question is: can we do it *efficiently*? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 16 01:19:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xHG9-0004CI-00 for ; Tue, 16 Apr 2002 02:55:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 02:55:49 +0200 (CEST) Received: (qmail 12573 invoked by uid 0); 15 Apr 2002 23:19:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 15 Apr 2002 23:19:12 -0000 Received: by moria.seul.org (Postfix) id 4227C1468DF; Mon, 15 Apr 2002 19:19:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3277A1468E3; Mon, 15 Apr 2002 19:19:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a168.home.uni-hannover.de [130.75.232.168]) by moria.seul.org (Postfix) with ESMTP id EBBFA1468DF for ; Mon, 15 Apr 2002 19:19:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01691; Tue, 16 Apr 2002 01:19:06 +0200 Message-ID: <20020416011906.12436@thrai.stud.uni-hannover.de> Date: Tue, 16 Apr 2002 01:19:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114731.560CA3CF@postfix2-1.free.fr> <20020414231312.27259@thrai.stud.uni-hannover.de> <200204160437.18048.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204160437.18048.cedric.bail@free.fr>; from cedric on Tue, Apr 16, 2002 at 04:37:18AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 16, 2002 at 04:37:18AM +0200, cedric wrote: [...] > I never see a function with more than 10 arguments, and the one who have > more must be put in memory (like print). I think that r1 to r10 will be > enough. But it's really important, because this register are in the same > case as the r16..r31 unsaved register. I think there were some functions in the X Toolkit Intrinsics... Plus any function which takes a variable number of arguments. I picked these values because they divide the register space in four almost equally-sized parts, which gives code and compiler developers a maximum of freedom. If the partitioning turns out to be suboptimal, we can still move the borders around a little. On the other hand, compilers can support several different calling conventions (see the `regparm', `cdecl' and `stdcall' attributes in gcc), so we could define additional `special-purpose' models for applications that suffer from register pressure in one area or another. BTW: argument registers are unsaved, too -- or should I say `caller-saved'? In either case, the callee is free to modify them as it sees fit (that includes using them as temporary registers). [...] > > Note that these rules do not apply if a function is only called from > > inside the same translation unit (in C: if the function is declared > > `static' and its address is not passed to other functions), or is an > > inline function. Local functions in Pascal-style languages may also fall > > into this category. > Of course if a function is in the same translation unit (like static), it will > be included into the calling function. Not in any case. If there is a big static function which is called >from several places, inline substitution is probably not a good thing. [...] > > You overlooked the fact that `var' parameters in Pascal are actually > > pointers, although they don't look that way. The same is true for > > reference types in C++. > That depend on your compiler, no ? It depends on nothing but our F-CPU API definition :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Apr 16 02:59:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7s-0000G5-00 for ; Tue, 16 Apr 2002 22:00:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:28 +0200 (CEST) Received: (qmail 5363 invoked by uid 0); 16 Apr 2002 01:02:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 16 Apr 2002 01:02:02 -0000 Received: by moria.seul.org (Postfix) id 6FD681468E2; Mon, 15 Apr 2002 21:02:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 613C41468E5; Mon, 15 Apr 2002 21:02:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from main.jetnet.ab.ca (main.jetnet.ab.ca [207.34.60.66]) by moria.seul.org (Postfix) with ESMTP id 6B7DC1468E2 for ; Mon, 15 Apr 2002 21:01:59 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-196.jetnet.ab.ca [207.34.60.196]) by main.jetnet.ab.ca (8.9.1/8.9.1) with ESMTP id TAA29924 for ; Mon, 15 Apr 2002 19:01:22 -0600 (MDT) Message-ID: <3CBB7783.F2AC1A8F@jetnet.ab.ca> Date: Mon, 15 Apr 2002 18:59:47 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Andreas Romeyke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > > - a FORTH interpreter > > That is a very well idea. forth is easy to learn, forth-programs are easy > to debug and a forth-interpreter is easy to write. And forth is a good > point to start experiments with development on F-CPU... > > But, could we really map a stack-based language to a register-machine like > F-CPU is? Easy answer maybie. The F-cpu has no problems with stacks, the problem is that most machines have deep pipelines (like the F-cpu) and Forth is known for bouncy code flow and data access that really mess up a cache. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 08:14:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7t-0000G5-00 for ; Tue, 16 Apr 2002 22:00:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:29 +0200 (CEST) Received: (qmail 12817 invoked by uid 0); 16 Apr 2002 06:08:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 16 Apr 2002 06:08:29 -0000 Received: by moria.seul.org (Postfix) id AF644146805; Tue, 16 Apr 2002 02:08:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9468F1468ED; Tue, 16 Apr 2002 02:08:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 0B25F146805 for ; Tue, 16 Apr 2002 02:08:23 -0400 (EDT) Received: from f-cpu.org (kdl16-8.n.club-internet.fr [213.44.18.8]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A0AE2169D for ; Tue, 16 Apr 2002 08:08:20 +0200 (CEST) Message-ID: <3CBBC15C.F217A462@f-cpu.org> Date: Tue, 16 Apr 2002 08:14:52 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114731.560CA3CF@postfix2-1.free.fr> <20020414231312.27259@thrai.stud.uni-hannover.de> <200204160437.18048.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, cedric wrote: > Nobody reply to your post, but I think it's very important to include this > recommandation into the manual for those who want to implement a compiler > or code in F-CPU ASM. > > You overlooked the fact that `var' parameters in Pascal are actually > > pointers, although they don't look that way. The same is true for > > reference types in C++. > That depend on your compiler, no ? > > So who disagree with adding this recommandation into the manual ? I don't disagree (if it is needed, then it's not a bad thing to put it). However, i wouldn't make this mandatory. My reasoning behind this is : call/return conventions are designed for computers of the 80's and 90's with 16 or 32 registers, F-CPU has twice more. It sounds simple to simply double all numbers but this sounds like using old methods for new computers : you can't win much there. Today's most advanced compilers can perform in-depth analysis of the programs and find the (mostly) optimal register allocation : they examine the data life length and their usage statistics, decide whether and how long to put (swap) them in memory and even modify other parts of the program to enhance the register reuse. If there was a mandatory allocation, these advanced compilers (something that looks like a "synthesiser" in the ASIC world) won't be able to compile anything more than leaf functions. That would be pretty useless. I hope to be not too much misunderstood, > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 08:15:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7u-0000G5-00 for ; Tue, 16 Apr 2002 22:00:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:30 +0200 (CEST) Received: (qmail 12533 invoked by uid 0); 16 Apr 2002 06:08:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 16 Apr 2002 06:08:44 -0000 Received: by moria.seul.org (Postfix) id D98501468F1; Tue, 16 Apr 2002 02:08:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D75DE1468EE; Tue, 16 Apr 2002 02:08:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 671141468EC for ; Tue, 16 Apr 2002 02:08:43 -0400 (EDT) Received: from f-cpu.org (kdl16-8.n.club-internet.fr [213.44.18.8]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 5216D1698 for ; Tue, 16 Apr 2002 08:08:40 +0200 (CEST) Message-ID: <3CBBC16F.A0D0A808@f-cpu.org> Date: Tue, 16 Apr 2002 08:15:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [Fwd: Re: [f-cpu] RC5, F-CPU and srotl] References: <1018905704.28887.3.camel@maturin> <200204160451.51363.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: > > I've already implemented some Forth for x86 and I tell you, it's going to be > > a real pleasure to implement a Forth on the F-Cpu. > > With so many registers, you can have stack pointers, A register, TOS ans SOS > > mapped to registers without brainstorms like in x86. No, it will be really > > nice to write a Forth for F0. Forth is also nice on a 6809 or a 68000 too :-) but there is no push or pop, at least the way Forth intends it (it's only post-incremented loads and store, while a "normal" push is updated after and a pop is updated before, or the contrary). You'll have to fiddle a bit. But if FC0 is probably suitable for a not-so-difficult Forth engine, it is probably much better at doing "multistack" programs (look at Chuck Moore's F21 or Bernd Paysan's "multistack") > > BTW, is there any way to compile & execute code for the F0 ? I might be > > interrested in doing some assembler coding, why not a Forth interpreter, but > > it's gonna to be hard if I must do hand-testing for the code :-) > Hum, it's where we have a problem, we have a small not all function virtual > machin with a GTK interface. I think that YG is coding an ASM an michael too > (I am not sure). And when I will have the necessary time, I will code one. is there a contest ? :-) it seems that everyone makes his own version, thus addressing different needs, no ? > And we will need a good virtual machine that can emulate all the F-CPU asm, it > must be able to simulate the latency and give us some statistic about the CPU. i'll use ncsim for that purpose. I better trust super-optimised VHDL simulators (which genererate target-machine code) rather than a poorly designed C code (even if there is a "price" difference). At least we won't have to deal with 2 code trees that do the same things. > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 09:53:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7w-0000G5-00 for ; Tue, 16 Apr 2002 22:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:32 +0200 (CEST) Received: (qmail 24542 invoked by uid 0); 16 Apr 2002 07:47:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 16 Apr 2002 07:47:22 -0000 Received: by moria.seul.org (Postfix) id 4DB641468EE; Tue, 16 Apr 2002 03:47:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B7381468F2; Tue, 16 Apr 2002 03:47:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 7736D1468ED for ; Tue, 16 Apr 2002 03:47:19 -0400 (EDT) Received: from f-cpu.org (kdl16-113.n.club-internet.fr [213.44.18.113]) by relay-1m.club-internet.fr (Postfix) with ESMTP id D70F4172C for ; Tue, 16 Apr 2002 09:47:15 +0200 (CEST) Message-ID: <3CBBD88B.ACD6F6A7@f-cpu.org> Date: Tue, 16 Apr 2002 09:53:47 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <3CBB7783.F2AC1A8F@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! just a few quick notes... Ben Franchuk wrote: > Andreas Romeyke wrote: > > Hello, > > > > > - a FORTH interpreter > > That is a very well idea. forth is easy to learn, forth-programs are easy > > to debug and a forth-interpreter is easy to write. And forth is a good > > point to start experiments with development on F-CPU... > > > > But, could we really map a stack-based language to a register-machine like > > F-CPU is? > Easy answer maybie. The F-cpu has no problems with stacks, the problem > is that most machines have deep pipelines (like the F-cpu) i don't think that FC0's pipeline is such a deeply pipelined computer. In some situations, the pipeline is shorter than a plain Pentium and it's much simpler than a P2 or P3. This makes me think that adding register renaming or even register bank switch/rotation to FC0 will add a pipeline stage or two, break the schedules and explode the jump latencies. This is one of the reasons why i want to keep the core as simple as possible, without bells and whistles (such as loadm and storem). If "indirect" register bank accesses are necessary, the bank access is performed only at the fetch stage (so the fetched instruction is blocked for a cycle). > and Forth is > known for bouncy code flow and data access that really mess up a cache. it is also known for requiring a small footprint :-) so if your cache is large enough (and if your L2 can sustain the load), the problems will come from somewhere else (but we'll have to measure this). > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 09:53:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7w-0000G5-01 for ; Tue, 16 Apr 2002 22:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:32 +0200 (CEST) Received: (qmail 3645 invoked by uid 0); 16 Apr 2002 07:47:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 16 Apr 2002 07:47:26 -0000 Received: by moria.seul.org (Postfix) id 657EA1468F5; Tue, 16 Apr 2002 03:47:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BED41468F4; Tue, 16 Apr 2002 03:47:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 376FD1468ED for ; Tue, 16 Apr 2002 03:47:20 -0400 (EDT) Received: from f-cpu.org (kdl16-113.n.club-internet.fr [213.44.18.113]) by relay-1m.club-internet.fr (Postfix) with ESMTP id B587F16BC for ; Tue, 16 Apr 2002 09:47:16 +0200 (CEST) Message-ID: <3CBBD88C.CBE4E2C6@f-cpu.org> Date: Tue, 16 Apr 2002 09:53:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114731.560CA3CF@postfix2-1.free.fr> <20020414231312.27259@thrai.stud.uni-hannover.de> <200204160437.18048.cedric.bail@free.fr> <20020416011906.12436@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Apr 16, 2002 at 04:37:18AM +0200, cedric wrote: > [...] > > I never see a function with more than 10 arguments, and the one who have > > more must be put in memory (like print). I think that r1 to r10 will be > > enough. But it's really important, because this register are in the same > > case as the r16..r31 unsaved register. > > I think there were some functions in the X Toolkit Intrinsics... argh... but i'll try to used DirectFB now so i hope i'm safe ;-) > Plus any function which takes a variable number of arguments. > > I picked these values because they divide the register space in four > almost equally-sized parts, which gives code and compiler developers > a maximum of freedom. If the partitioning turns out to be suboptimal, > we can still move the borders around a little. i like this way of thinking ;-) > On the other hand, compilers can support several different calling > conventions (see the `regparm', `cdecl' and `stdcall' attributes in gcc), > so we could define additional `special-purpose' models for applications > that suffer from register pressure in one area or another. good idea. > BTW: argument registers are unsaved, too -- or should I say > `caller-saved'? In either case, the callee is free to modify them as > it sees fit (that includes using them as temporary registers). i have no idea about it. > [...] > > > Note that these rules do not apply if a function is only called from > > > inside the same translation unit (in C: if the function is declared > > > `static' and its address is not passed to other functions), or is an > > > inline function. Local functions in Pascal-style languages may also fall > > > into this category. > > Of course if a function is in the same translation unit (like static), it will > > be included into the calling function. > > Not in any case. If there is a big static function which is called > from several places, inline substitution is probably not a good thing. This is a compile-time tradeoff. If you compile with -O3 and have enough cache, it shouldn't be a problel. > [...] > > > You overlooked the fact that `var' parameters in Pascal are actually > > > pointers, although they don't look that way. The same is true for > > > reference types in C++. > > That depend on your compiler, no ? > It depends on nothing but our F-CPU API definition :) one has 63 usable registers, 8 can point to instructions and 8 to data (at least, and for FC0). It's everyone's job to find his own optimal register allocation, depending on the application. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 09:53:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7x-0000G5-00 for ; Tue, 16 Apr 2002 22:00:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:33 +0200 (CEST) Received: (qmail 5009 invoked by uid 0); 16 Apr 2002 07:47:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 16 Apr 2002 07:47:31 -0000 Received: by moria.seul.org (Postfix) id 78BF31468ED; Tue, 16 Apr 2002 03:47:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 55B201468F6; Tue, 16 Apr 2002 03:47:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 6511D1468ED for ; Tue, 16 Apr 2002 03:47:21 -0400 (EDT) Received: from f-cpu.org (kdl16-113.n.club-internet.fr [213.44.18.113]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8F94C1726 for ; Tue, 16 Apr 2002 09:47:18 +0200 (CEST) Message-ID: <3CBBD88D.2F8F743E@f-cpu.org> Date: Tue, 16 Apr 2002 09:53:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <20020415020407.26879@thrai.stud.uni-hannover.de> <20020416005114.50349@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Mon, Apr 15, 2002 at 11:36:13PM +0200, Andreas Romeyke wrote: > [...] > > > - a FORTH interpreter > > > > That is a very well idea. forth is easy to learn, forth-programs are easy > > to debug and a forth-interpreter is easy to write. And forth is a good > > point to start experiments with development on F-CPU... > > It's also a good starting point for writing a BIOS and a bootloader > (see Sun SPARC). If you can get a 16Mbit EEPROM you can certainly fit a tiny boot manager (that will select your boot devices and load the necessary drive) and a working linux kernel (or a minimal Hurd). > > But, could we really map a stack-based language to a register-machine like > > F-CPU is? > The question is: can we do it *efficiently*? ;) if you can write a recompiler, sure. However, the more registers, the more efforts your recompiler will have to do : it will have to track data dependencies with a much much wider window (if you consider our 64 registers). If you don't write self-modifying Forth code, it should work, then ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Apr 16 12:59:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ7y-0000G5-00 for ; Tue, 16 Apr 2002 22:00:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:34 +0200 (CEST) Received: (qmail 26061 invoked by uid 0); 16 Apr 2002 11:18:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 16 Apr 2002 11:18:02 -0000 Received: by moria.seul.org (Postfix) id 1A9E31468EC; Tue, 16 Apr 2002 07:17:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F41B01468F2; Tue, 16 Apr 2002 07:17:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 49C151468EC for ; Tue, 16 Apr 2002 07:17:57 -0400 (EDT) Received: from ifurita (212.194.221.160) by mail.laposte.net (5.5.044) id 3CB2AF0B000F5B52 for f-cpu@seul.org; Tue, 16 Apr 2002 13:17:53 +0200 Message-ID: <000201c1e536$0c693260$a0ddc2d4@ifurita> From: "Christophe" To: References: <3CBB7783.F2AC1A8F@jetnet.ab.ca> <3CBBD88B.ACD6F6A7@f-cpu.org> Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Tue, 16 Apr 2002 12:59:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I knew FORTH as being in fact a mix of compiled and interpretable code : Usually, a FORTH code is a sequence of call addresses (there is no opcode but just address), so it is more compact than a native code. Everytime you create a FORTH function (I'm not sure about the exact term to use), there are two possibilities : a native code (ASM) or a FORTH code. So you still need a monitor : loadaddr 0f,r62 movi $4, r58 movi $2, r57 loadaddr 1f,r56 loopentry r54 0:sub r58,r60,r60 // --rsp load r61,[r60] // ip = *rsp if (r61 == 0) jump r0,r55 // if (ip == 0) goto 0 1: load r59,[r61+] // next_ip = *ip++ and r59,r57,r54 // not_native = next_ip & 2 if (r55 == 0) jump r0,r59 // call next_ip sub r57,r59,r61 // ip = next_ip - 2 add r57,r59,r59 // next_ip = next_ip + 2 store r59,[r60+] // *rsp++ = next_ip jump r0,r62 // goto 1 2:... (here I suppose we code a native code to terminate a forth code, so I don't check for return stack boundary) r63 = sp (stack pointer - used by both native and forth code) r62 = rp (return pointer - used only by native code) r61 = ip (instruction pointer - used only by forth code) r60 = rsp (return stack pointer - used only by forth code) I did create a virtual machine, that is, a FORTH-like CPU. That was great but not the point for F-CPU. Of course we could in fact generate only native code but it will generate (without registers optimization) at least two instructions (if I'm not wrong) to call one forth address : loadaddr $function1,r61 jump r62,r61 loadaddr $function2,r61 jump r62,r61 loadaddr $function3,r61 jump r62,r61 loadaddr $function4,r61 jump r62,r61 ... ----- Original Message ----- From: Yann Guidon To: Sent: Tuesday, April 16, 2002 9:53 AM Subject: Re: [f-cpu] RC5, F-CPU and srotl > hi ! > > just a few quick notes... > > Ben Franchuk wrote: > > Andreas Romeyke wrote: > > > Hello, > > > > > > > - a FORTH interpreter > > > That is a very well idea. forth is easy to learn, forth-programs are easy > > > to debug and a forth-interpreter is easy to write. And forth is a good > > > point to start experiments with development on F-CPU... > > > > > > But, could we really map a stack-based language to a register-machine like > > > F-CPU is? > > Easy answer maybie. The F-cpu has no problems with stacks, the problem > > is that most machines have deep pipelines (like the F-cpu) > i don't think that FC0's pipeline is such a deeply pipelined computer. > In some situations, the pipeline is shorter than a plain Pentium > and it's much simpler than a P2 or P3. > > This makes me think that adding register renaming or even register bank > switch/rotation to FC0 will add a pipeline stage or two, break the schedules > and explode the jump latencies. This is one of the reasons why i want to keep the > core as simple as possible, without bells and whistles (such as loadm and storem). > If "indirect" register bank accesses are necessary, the bank access is > performed only at the fetch stage (so the fetched instruction is blocked for a cycle). > > > > and Forth is > > known for bouncy code flow and data access that really mess up a cache. > it is also known for requiring a small footprint :-) so if your cache is > large enough (and if your L2 can sustain the load), the problems will > come from somewhere else (but we'll have to measure this). > > > > Ben Franchuk - Dawn * 12/24 bit cpu * > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Apr 16 16:57:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ84-0000G5-00 for ; Tue, 16 Apr 2002 22:00:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:40 +0200 (CEST) Received: (qmail 19734 invoked by uid 0); 16 Apr 2002 14:57:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 16 Apr 2002 14:57:36 -0000 Received: by moria.seul.org (Postfix) id 4D8A31468F3; Tue, 16 Apr 2002 10:57:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 160FD1468F7; Tue, 16 Apr 2002 10:57:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id EC1071468F3 for ; Tue, 16 Apr 2002 10:57:31 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204161457.1115; Tue, 16 Apr 2002 14:57:17 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Register allocation when calling a function From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Apr 2002 14:57:17 GMT Message-id: <200204161457.1115@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: cedric A: f-cpu@seul.org Date: 16/04/02 Objet: [f-cpu] Register allocation when calling a function Nobody reply to your post, but I think it's very important t= o include this=20 recommandation into the manual for those who want to impleme= nt a compiler or code in F-CPU ASM.=20 > > I propose to use the first 8 registers to put the return= address (R1), > > and the first params (R2 to R8). For the returned value = we put the result > > in R1. If we have variable number of parameter (like pri= nt) we detect it > > and put them on stack (R63). > As a first guess, I'd reserve r1...r15 for arguments (r1 a= lso holds > the return value), r16...r31 for temporary use (unsaved), = r32...r47 > for local use (saved by the callee), and r48...r63 for spe= cial purposes > (stack pointer, frame pointer, global pointers). If a func= tion has more > than 13 parameters, r14/r15 hold the number and address of= additional > arguments, respectively. I never see a function with more than 10 arguments, and the = one who have more must be put in memory (like print). I think that r1 to = r10 will be=20 enough. But it's really important, because this register are= in the same case as the r16..r31 unsaved register. >>>> !! Be carefull, if you use struct in c it could be very= usefull to use large register set. The old sparc use 8 register for thi= s ! > The return address should either be stored in the `local' = or in the > `special purpose' register area (that is, r32...r63), in o= rder to avoid > copying in `leaf' functions (i.e. functions that don't cal= l other > functions). If it is stored in r1, you'll have to move it = away in > order to make room for the return value. Oups, you are right. > Note that these rules do not apply if a function is only c= alled from > inside the same translation unit (in C: if the function is= declared > `static' and its address is not passed to other functions)= , or is an > inline function. Local functions in Pascal-style languages= may also fall > into this category. Of course if a function is in the same translation unit (lik= e static), it will=20 be included into the calling function. > > If the used language is C, we know that the parameter wi= ll be lost, but > > for language like Pascal (or one who use byRef call), th= at is great, you > > can code a function like swap for example in very few in= struction : > > move R2, R4 > > move R3, R2 > > move R4, R3 > > That as quick as a macro without is border effect. > > (I thing that I have perhaps forgot something about this= problem, because > > why didn't people use this type of call ?) > You overlooked the fact that `var' parameters in Pascal ar= e actually > pointers, although they don't look that way. The same is t= rue for > reference types in C++. That depend on your compiler, no ? So who disagree with adding this recommandation into the man= ual ? >>> Nop ! but you must say how we came to this conclusion. I= t must be change if somebody have a better idea. nicO A+ Cedric ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Apr 16 17:07:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ85-0000G5-00 for ; Tue, 16 Apr 2002 22:00:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:41 +0200 (CEST) Received: (qmail 2333 invoked by uid 0); 16 Apr 2002 15:08:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 16 Apr 2002 15:08:14 -0000 Received: by moria.seul.org (Postfix) id 7BD081468F6; Tue, 16 Apr 2002 11:08:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 566111468F8; Tue, 16 Apr 2002 11:08:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id E26FB1468F6 for ; Tue, 16 Apr 2002 11:08:09 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204161507.37a3; Tue, 16 Apr 2002 15:07:55 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] RC5, F-CPU and srotl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Apr 2002 15:07:55 GMT Message-id: <200204161507.37a3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 16/04/02 Objet: Re: [f-cpu] RC5, F-CPU and srotl hi ! just a few quick notes... Ben Franchuk wrote: > Andreas Romeyke wrote: > > Hello, > > > > > - a FORTH interpreter > > That is a very well idea. forth is easy to learn, forth-= programs are easy > > to debug and a forth-interpreter is easy to write. And f= orth is a good > > point to start experiments with development on F-CPU... > > > > But, could we really map a stack-based language to a register-machine like > > F-CPU is? > Easy answer maybie. The F-cpu has no problems with stacks,= the problem > is that most machines have deep pipelines (like the F-cpu) i don't think that FC0's pipeline is such a deeply pipelined= computer. In some situations, the pipeline is shorter than a plain Pen= tium and it's much simpler than a P2 or P3. >>> Most of EU aren't pipelined in the pentium. But our mul = unit need 6 cycles... This makes me think that adding register renaming or even re= gister bank switch/rotation to FC0 will add a pipeline stage or two, bre= ak the schedules and explode the jump latencies. This is one of the reasons w= hy i want to keep the core as simple as possible, without bells and whistles (such= as loadm and storem). If "indirect" register bank accesses are necessary, the bank= access is performed only at the fetch stage (so the fetched instructio= n is blocked for a cycle). > and Forth is > known for bouncy code flow and data access that really mes= s up a cache. it is also known for requiring a small footprint :-) so if y= our cache is large enough (and if your L2 can sustain the load), the prob= lems will come from somewhere else (but we'll have to measure this). > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 19:12:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ85-0000G5-01 for ; Tue, 16 Apr 2002 22:00:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:41 +0200 (CEST) Received: (qmail 1447 invoked by uid 0); 16 Apr 2002 17:05:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 16 Apr 2002 17:05:51 -0000 Received: by moria.seul.org (Postfix) id AF05C1468D4; Tue, 16 Apr 2002 13:05:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A3EA1468D7; Tue, 16 Apr 2002 13:05:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 0B27D1468D4 for ; Tue, 16 Apr 2002 13:05:49 -0400 (EDT) Received: from f-cpu.org (kdl11-220.n.club-internet.fr [213.44.9.220]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E1E2E1700 for ; Tue, 16 Apr 2002 19:05:45 +0200 (CEST) Message-ID: <3CBC5B72.1A66A316@f-cpu.org> Date: Tue, 16 Apr 2002 19:12:18 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <3CBB7783.F2AC1A8F@jetnet.ab.ca> <3CBBD88B.ACD6F6A7@f-cpu.org> <000201c1e536$0c693260$a0ddc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Christophe wrote: > I knew FORTH as being in fact a mix of compiled and interpretable code : forth is always more than one can think of, one reason is because the coding density is extremely high : the code is both the source and the executable, it is highly reflective (in a certain way, it codes itself) and there are a lot of sophisticated techniques that are mixed at every levels. It gave me some headaches and sleepless nights when i was young and i stayed with Turbo Pascal instead :-P IIRC, when Forth "compiles" code, it's often a "condensed" representation of the existing modules, something like : putting each code module together (copy and paste) and remove the jumps at the ends, or something like that. The "win" is because the linked list search is not performed all the time. Today, one would use gperf and sophisticated hash tables instead... > Usually, a FORTH code is a sequence of call addresses (there is no opcode but > just address), so it is more compact than a native code. it is certainly faster than looking up all the symbols in the linked lists :-) > Everytime you create a > FORTH function (I'm not sure about the exact term to use), there are two > possibilities : a native code (ASM) or a FORTH code. So you still need a > monitor : > > loadaddr 0f,r62 > movi $4, r58 > movi $2, r57 > loadaddr 1f,r56 > loopentry r54 > 0:sub r58,r60,r60 // --rsp > load r61,[r60] // ip = *rsp > if (r61 == 0) jump r0,r55 // if (ip == 0) goto 0 > 1: load r59,[r61+] // next_ip = *ip++ > and r59,r57,r54 // not_native = next_ip & 2 > if (r55 == 0) jump r0,r59 // call next_ip > sub r57,r59,r61 // ip = next_ip - 2 > add r57,r59,r59 // next_ip = next_ip + 2 > store r59,[r60+] // *rsp++ = next_ip > jump r0,r62 // goto 1 > 2:... i don't understand your asm code. There is probably a misunderstanding with the jumps : the destination address is the 2nd operand. I see for example > if (r61 == 0) jump r0,r55 which means that you jump to the address stored in register zero, which contains zero, and you save IP+4 to R55. The "trick" to remember is that - the condition is at the left - the pointers are in the middle - the destination is at the right > (here I suppose we code a native code to terminate a forth code, so I don't > check for return stack boundary) i am not sure to understand the context :-/ Forth is very old to me. i had a small book about it ("Guide Marabout") but i have lost it more than 8 years ago... > r63 = sp (stack pointer - used by both native and forth code) > r62 = rp (return pointer - used only by native code) > r61 = ip (instruction pointer - used only by forth code) > r60 = rsp (return stack pointer - used only by forth code) > > I did create a virtual machine, that is, a FORTH-like CPU. That was great but > not the point for F-CPU. i don't understand (i know i should sleep but you know me :-D) you did this now, or you have done this in another context ? i remember when i was 16 : i wanted to make a Forth machine using Turbo Pascal and it soon became a nightmare. it's certainly easier to do this in F-CPU asm. But a "synthesised" Forth code (not just a play with the code entry addresses) will be much more efficient because it will unwind the data dependencies and allocate more registers, jump much less and make parallel things. > Of course we could in fact generate only native code but it will generate > (without registers optimization) at least two instructions (if I'm not wrong) > to call one forth address : > > loadaddr $function1,r61 > jump r62,r61 > loadaddr $function2,r61 > jump r62,r61 > loadaddr $function3,r61 > jump r62,r61 > loadaddr $function4,r61 > jump r62,r61 > ... This looks ugly, sure. and i'm not sure it's any thing like efficient. it will work but be even slower than GCC-generated code ;-P WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 19:12:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ86-0000G5-00 for ; Tue, 16 Apr 2002 22:00:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:42 +0200 (CEST) Received: (qmail 22541 invoked by uid 0); 16 Apr 2002 17:05:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 16 Apr 2002 17:05:55 -0000 Received: by moria.seul.org (Postfix) id AA1CF1468E1; Tue, 16 Apr 2002 13:05:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A77531468DF; Tue, 16 Apr 2002 13:05:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 2AEE61468D7 for ; Tue, 16 Apr 2002 13:05:51 -0400 (EDT) Received: from f-cpu.org (kdl11-220.n.club-internet.fr [213.44.9.220]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 06A351702 for ; Tue, 16 Apr 2002 19:05:49 +0200 (CEST) Message-ID: <3CBC5B74.A6B5597@f-cpu.org> Date: Tue, 16 Apr 2002 19:12:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] RC5, F-CPU and srotl References: <200204161507.37a3@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Nicolas Boulay wrote: > De: Yann Guidon > > > But, could we really map a stack-based language to a > > > register-machine like F-CPU is? > > Easy answer maybie. The F-cpu has no problems with stacks, the problem > > is that most machines have deep pipelines (like the F-cpu) > i don't think that FC0's pipeline is such a deeply pipelined computer. > In some situations, the pipeline is shorter than a plain Pentium > and it's much simpler than a P2 or P3. > >>> Most of EU aren't pipelined in the pentium. But our mul unit need 6 > cycles... >from memory, imul took 12 cycles for 32-bit operands on a P53. i remember that i measured this in 1996 and i was surprised that 16-bit mul was slower than 32-bit mul. Other operations like add and logic are 1 cycle. So just compare the 2-cycle 64-bit addition of FC0 to the 1-cycle add of the Pentium (and other similar CPUs) on one hand, and the 6-cycle 32-bit MAC compared to the 12-cycle, 32-bit IMUL of the P53 on the other hand... (FC0 is 2x "faster" on multiplies and "slower" on more common operations, if clocked at the same frequency) and there is a last detail : when mul executes on P5, the rest of the pipeline stalls. decode is frozen so you can't make other work in parallel ... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 16 19:12:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ87-0000G5-00 for ; Tue, 16 Apr 2002 22:00:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:43 +0200 (CEST) Received: (qmail 3515 invoked by uid 0); 16 Apr 2002 17:06:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Apr 2002 17:06:16 -0000 Received: by moria.seul.org (Postfix) id 35EB01468D6; Tue, 16 Apr 2002 13:06:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 25DBD1468DD; Tue, 16 Apr 2002 13:06:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 9FAFB1468D6 for ; Tue, 16 Apr 2002 13:06:15 -0400 (EDT) Received: from f-cpu.org (kdl11-220.n.club-internet.fr [213.44.9.220]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 6C2BD1709 for ; Tue, 16 Apr 2002 19:06:08 +0200 (CEST) Message-ID: <3CBC5B89.F45C9AC@f-cpu.org> Date: Tue, 16 Apr 2002 19:12:41 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Some code to play with Content-Type: multipart/mixed; boundary="------------886E41FEECDD1F508ACB9474" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------886E41FEECDD1F508ACB9474 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, i have finally decided to unveil (?) some code i made in January. It's based on an algorithm i found in a paper about an ASIC/FPGA architecture for encoding/decoding JPEG/MPEG. I immediately jumped into it because the original code is simple, efficient and useful. It can be reused as is for other duties and i worked only in C code so it can be tested with a C compiler. It is not finished and i submit it for a preliminary review. I have the intention to modify the presentation and add it to the F-CPU file pool and web site. I'll make a nice HTML presentation with illustrations, a kind of technical paper, but it is only the first raw material. Please be tolerant with it :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------886E41FEECDD1F508ACB9474 Content-Type: application/x-unknown-content-type-WinZip; name="yg_dct.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="yg_dct.tgz" H4sIAMIJvDwAA+xb3ZYbt5H2bfAUCG88Iw85/KciWTnxT2Q7J5toZ5zN7lUO2I0msWp2c/tn RtwH2efd7ysAzeZoJNnOWonPso/HYqMBFFBVqPqqAKRJc/3Jz/yMx/PxarXAv+Pxajk/+Tc8 n4xX88VqPJ5Nl5NPxpPJdDL/RC9+7oHxaevGVFp/cr89bKx9d70Pff+FPinkj79JOmreND8T jfFkPF5Sxo/Lf7qazyn/yXy6mq2mM9SfrhazT/T4ZxrPyfP/XP7XT5SaPNFPh2tX6K+/+l5n ZaWNHqxNbXNX2IH+w6tvdFLu9pWt67IaKVVWbuMKk+cHnbSNNkWq96ZubKqzqtzpZ6peJ4n7 Gzqbfj3ap5kavHJ76SzVL1FRT4dfC6kvqmTrGps0bWWF7h9e/f4b/d3ObKz+KlB0ZTFQf2wT Z4pS/1uZJ6bQX2zKunGF0/pzE37+zhXZqM2qTT1aV79V392h2q2pjLsz+tbl+L9/PkdB8bvU 7cye1QupfWurjSv1l2a3d7r/fL5m0YO+1fdmnVs91f+jv3SNvndps9WpyzJb2SKxtV7b5t7a Qjdbq5v7Uk3CdE1vurWKPNH6pavAlFhL61ublOBpKFD6tiFD5Fl3BPWDAqX15GTsv9Gnz2SG KtOTkvHDKnNUmZ2UTB5WWaDK/MNVFicl08eqLD9URb34rfAwNY0B86yGhk7+dbKgquxMo5Te TfQL6GZ9Md+768nyEiXTULLsSmahZOpL9PDB9/np989OPqsn10pdP4EM7B4Mxtt6jPpmrD/T ZvVcrTkCM+HbEm+kbqYgYeZ4m/lvQ/9t7r+h5gJvC77N+Maay64dv608haFQ6KhPST0h9TWp r1EzIfU1KazRS0Lqa1JYg14y898+89/mvt3QtyP1NamvQSFZdm9sR+rrPuEZCacknJBwMnuu 0ol/G/o3YfoUP4TXpJmAZiqc5awS0ExJU4pJTkpIKQHJ9Cl/9EnOSdKSZDp+riyppRP8ICEI 9IlOQc2SGlQAb2hrSQ3CxBu6tKSWgohddpUwUkuS0BG8YSSWdNOnPboL0s1I14JuRroWdDPS RZefaYu+s5l/G/o30rXknkVPGemiX3wDuYzELSViMcKMxDFM/9bRXJLmLWlmoHlLmhkrZah0 S8IZ5npLmhlpZqB5S5oZBna78MWf+WKSy0D3duU7GUon6n32v/P/fxsv/jYeJT+HjxH//8Dv H/3/dLIaT73/Xyxnq9US9WeT6fjs/z/GQ/8PLzP5GvIfJerOVnS5egee/Cd8KGze+Omz+eLZ YqW/+Zfv9RTyUp4Vv8uGyb4dldXmRyOIP+8bt3O1aUjqGdBD1WhqcmU3DkCiwg/AizKRCqgO t3r0BKnd2yKFq3XwtXQLWWWtQA+1jz4VMs3z+krfW03AMCg9QYwF3aiOzJHISH/XaFfrogSg 0UnlGpeYXEamMK2Xw69e/QWOPTFtLUMBWZJezrsx1wA+rvm0Bs0817Yo281WN6U2d6VLZfq5 fQOKG8CnZrurwYa/YnRlm6fagC9AOI3V1iTbIxvYXDd2ty8rUx3UnamcYI81YFezxXDvpXll 0zZwyNwZl7OOEma3FQEJBcKPKGp0mcnvfVVuKrO7kim6pM1NlR9UrAlR3bmyrQXcFfZNg4Gm oAt2va5HGgPfmjurML7XFiZM5LIvXUE+XKFuAQEUTa0vHCSFWadAXYlV7K0BXEkxh8wkTVnV l0KiLnfo0pq0KkuMCRxPoD0qL8u9bouqzCHVjTb7vTVgdGExqxocYUUON2uJqUbqJYZv3xiy +gqcS1uTD11dt1a//GocmIWJr8GgAxj0X62jHHW9t+B+rqdvesSeeY1r97kLegjOWawPUq2b qk1Eey+oMWDbxjYNm4ElgIFmB+YIx4NyXF4JamGNva0ygMCc/URdFhSt6mQLSeaWeBqYcKS/ p4zxH7uqHacFAdZl3gppl6lD2eq0LD4FCAS/PXHoLcUJZYJ6d8tGBVLJAViV0qFiiDx6w9RF u1tjtCP154yqWdXgoyhaWWC892X1Gjq3BbaNXds3NpHRqLZwjV+PkWeYRySwa/PG7dEFaynO qCwp77uD6HiS2H1DrNxnbU1O6eSQ5JDsLRWEizXHYMsqtRVZ6SXacEBr21OL9UEN6q3LKBFZ 8l590bU1O3zlErdVY6A+Zle2RUPZ9klfgctoZ5qw1sUyUK8zzKzB0v3SJK89uzuLNexZEyWS 6xY724vmeCHqi5IWjcKTZdRCLggByjLVrrkc6ZdtRbK7srIn9CMxJZaUQRNGGUxcBrUt79Fe Q6sttAuD/B4ThxV2CZTewV6StPBeO+qcy8AIBeVoseQkdJOIxYHTToxhAnZRimCQE3GrnOEb TCBVE8KHdME4o6UPmL7cZaSgQvcObUVbxDJFG5ce50ELBgY1rFJeeYaj7Jlv5QdxbEdzgyiQ HPEUwcdKC5ew6LmirqAGWGZc/FhOoriphZhzmm5oUK131hRQiqzNNZdIdQk29awGbLjGfACA iWFDKPL5EAiWwqfCYEA6k4DtzuStVUN8NMUBtKCPfJHqwsS09Uq6dbDpCefSFuBdChIJgSeB 4LtIFPbeE9BejEdVQg+sMKgTTHRdmiod0DBWJTwHPDO15dSJbI2MOTcbfWGdcC9oKoYiC7QM Yyzzo2yuNLhCzwoOfVewg7K6BzFdQ9vA3zra3ldLzZHAnu8cJCBm7zg2KAVUgTYT6pRbdkDZ 0o6eGEh9ogrwxlkQPxkWpKrWlvws0TZUDcaJQq275RoE45rIT3RAHqQuGKR7771QtxX9gDEm JzotTqH1Wwyh0GJoyB9fy1OjZ7pSfnRe+bLMAYwE+9sGdY8CU93KCsuFP8WR6os1rAiZCveg RK/vnYcXPVRx72Bqw0yiAskM66hgcGBuU2C5JfQBWWW8Z/KkVHD0R2cCY+GIKOihe3kLdY/R 6rJthmU29BOnFGtdt1ANU0dhi4qJ7PpuMKPx2QFL0xDDy8DcwpgVviOBFeXaIwrYlBoWVsyT q99hQCHSZktzCM9D6GZyFQ3JW9ZQd9aQwoVTjPY+PTXAJgfp9KAjFkyh2FkPy9GRB9h25L5g WbVxdyB+hECid8XGu7vo+XfgkxKFIFMJqZoOMZaFFR2Eggzqe7MfKIFMeN1ZNDlwsdXwms11 DQdjjzoC8IlKEdcK+Eu2bUEQ1i0RDFzty7p2a8KeUNb5woZ+iy7Or/EumbIrvSmX9S8oDkTB qKKDxxGA9MTSZ6gS5NMWBbxII4AgzpZAIABe1xwCYK9V6VdGX21qS8QMXdyWm7IwYMBhNIJq /Kn0akewlmNUIqRn3cp9KCYVbJGH6WEVQs8txSYiifib/7ZNcNJ/pUoB5fTsFRhn02iAveWi VgW4o1gSw47Buq0Pgy7GENd+CD6z3wGmIya8H9P0GLkp2V8dHHgNBzQZeiytgz3r2Y0T3gma UXo6PLpzMb6C+qHmtsLQpe9BeqCGUvYDrfRsKHotbuLkE70fn3nnITCRbp11bQRPSsULCDDg qwqrcF8WKXvr8VNYcBn6XWC2FM9JiNGbU6i2xCqOwLXd9VyDitnBlcaw9rkJS8U7rmDItBgy SuuYTaQwjiCX6Dx+earhlcQZgIzEGxdND3UH3stA4ix+09GmWgR2d+Trt+m/RV1fJNAggBAq zNYmr8G0rvZbsNODcvI1AtA4ksnYD3kd0OgCygPtgWWIK6WiwKwH4WsMoSjEhWYqkLInVo3r 1XPi6L70BAr21z7mT2BroZ09uX1a9+bvu+YKCWxKr97SXS4YOIoBluOOkk0HIxCCXr5fP/RF u2dQEJa7XwFgxmT+YA0cbNPZ+6Nj6UNPz8DjqEl/MaTixWnG6JkziX11HV2FkU4maLccdo3a 4kir30F/mcW2M7ELXswmWGzaS+INx12NTevqLbUn71FWPU3roEXckum70+PMfGqjNpkHMzTR 0e8jnDzs1iWUShSTgQ/dGCHjZGhWXeqgIyC1xCbeTIY3y1msoajk8nEEbXG5faBHHAE8/yE6 KJPXpWKBOEHzmgCyQf+2qkrmEPppCUoFwZIiI+scrmoIl1LBJ6dwFvo/EEbxC4AUod4zzxX7 BoriBNg4b5/NIQQYjbxvEWT5oEz+tzVVvZWoSX3byaTeUa4xNvCgTSKEcZf1n8IITrgezaTL 789QNpWy6THLj7KZlEnmf8myCcrml5IHYhKyb/CvPM46rR2j6aN5ZQTlEFI7vxtHgA2msFVY YXEJStAbwxTDeBBiuVK5+F+y5mYiMV1BywGvuzcbWn9S6wQrsd7kxc3Uu8Tli5uZuoiGJsaK rP3A/MNhXh5jyDoAdFkXanAM7wad4XSVrzJC8KMxshfk3s30BRl2M3thluoRGXxK5t5MT4Xw 6WNS8DUprhsW3rD5HIVAHfdeReJq7i21vj2L9qdnma4UGIFl3e59PstCH9nTgx4ImWibYk+I 9ctKhXhNinbgmGAKGPbXnaE7MpTLzUcBkbfQSEzG1T4PelE7+kC/yGJE5UNd6Zb4RjChxynM uUBkEdj4uL5HTnIrXVz67B3ywD/zF+T4zeKFmT4qnQfiuZmLeHwpdfyGWx43E5EPZfG9z1HS Jgp9V1BlvBZRPCeJIrI2VCas/7a8Z4B5DPTKritXAP55+4VQR35fgDc72rb6UnVmEavpmUed GG4XhiJG05Lk9Lvf7MW+ia8j9bUAXXGwXm4SKgZZ7MzhJEfFZMYRZFEG0XaPfhCXu2Ff6psl 3+PALk/5f7P0/D8K4GbZEwB5zXlkfkf/KiaKGb0A4/+dI0GNlW/29IUZS2/cc7tZ9Qf27pE9 rhuPL14JVU4Ndr0FoNZbnxbzyUtmzl3TpYO60F1CVDibjYS9Xar7qot+GSZwcyP0PdJfErqZ YkPo5gP+Dtzv6U8PXWQQE80SiJAMFfEYu8DiFB3agRpJ4iFQC04AxsAn7uNWgI5bAbU4RWpn yIVIumAQd1t88tMDSK/Dx+BOeZhYAoDp3WS4m18Fn091uB0Pb1edwUC73qGP2bgXIsJ7we9K wtyLYGeK1uSnjp9mrxcUy6GRg3f1Yrjo+SNMqSysFXw7CEV4IEnTnWBOwk4Aq6y557zZU1Gq AMHDGpdsHkZX09KO9Lcxvpc9BpPeuURsph5KlIiZhGMm4C4bxaRKcAHRcHRJICJHD1KoFnXJ YK7WMf5mt7WPJ7plJOndEBEK+sfwmbtyvQSTye/NQaCzWCwDnriciM1nrKC7Elf5iVJBR6QU w3YJgPxWzX30rnQd95KzriVFj16ZQqivSIT5CJ9NIwIHZ63Yw6BDW5vvZcYhMS1DgDfzwwMC L7wFvXN1KxoR0mOeLSN/aKI57KE4meSmCIa3iPJpPMEeivO5Uv4HOt1NrvRuir8Z/uZXYr6o jPhDqUGpoXIu8LfEH/RSXz8JHlhMOOhpvUabNdqs0WaNNmu0WaPNGm3WK/aaoEaCGglqJKiR oEaCGsmSX1N8TfGVT4qvqYwkPhZtLErt3New6NWu+jUy1MhQI0ONDL1mqJFJjVv0fIueb1Hj FjVuUeMWNW5R43b1vJtN9Ehkn7p+osQBySIESmp39u3QsPM3DPZjBC21UguH5hGV+Xcoyy/3 HMvp6ZT3nWM5OfFyenzleFZEDpy855zKgzMo3YkTnm85njGRmu87W3J7cl5GDmx052UeHDfp DpBwEnKABJzzB0hQkUtVkF1NJxASYSd7asHA+ggVHbJ3OZEz9wdW6MFBBA48W9F/gwTcd7a8 xuTgwDEpuG2MHq4aTeCp7dKvqNNu2O/JgZaf3u/NvPPqS6/+qBaMtrfpMCbTEcm5OhoqH2CM eiuu96Az1iRA6200wYShiwtYRb/NjIFdwFRevqMTxmF7ugry/CRp03Puv1a/+pXUDihT7PhX r/4SFpuj402YxrdvuKt5zGo9eC6++OOrb7/wSTWPKS699QUQR5gZzyIwKShbRo88x+yyfvnq L3AZ9DZ+VzaQhrku0pyYxhSfNo/38roAQPLJYb/jRBYRpwjbTjZpYiAwimq29PoxfJ+afUjH lh4QDlHqdax/TOoHdRqUShDkwivVg+NVfOmfoHpnt2FMM48vMaa5jOnknNWHGi86cBoa9490 nTQODQTNClaf+gb941uPNVj5BkNp8Ped/+md/5r8PKe/Pnj+ez6ZTfz5r+VkNh4veP57OVuc z399jKd3/mvy0c5/nU+Q+xPkz84nyN9Z5SOcIBfFy23WDE0uUYoKCdhup2T0cQ6ZP3ogkmS7 E38SN0KLwl69+iKmBBga6ntz3N5OCV7qMmSdQgitJPwaJq5KWm7xvJ1HGOnfMwuZA9Lk6kK2 pm8v43EBBBl3jqfpdG4OwAG136KBsZBTBwJyKlNsrA/geRoxDWFgF+T9c4Znz3+pUdFPPN1/ /SSe7+8HhB884X/NE/f+kL9UfU/8dP0knvQX3BVP+/uXcOLfv/hT/2+PZu4RWzz+71/CFYCT kAx94PeTax+bdRGep8PiZT9k82NhsYxShysCGoBUJvW+aA4DCHcF+gNd+IGG+wK90YaLA92Q sxBHoZsFBtC7RnAsfHibwJPEhy4q7JX8tPsFkDAKec/gyfWPuWkAXfDtuET+Ly4dnJ9/mqeH /6c/K/5/5/2P8XyxWEb8P12spoL/V+f7nx/l6eH/6Rn/n/F/7znj/38o/heHLILluY6i3QP1 d6eMevvI79gTrOyu5AkZ/YVObFG3dTxDOCjK1NYDvyfNjaRbF+5XuXgBxGddeaR3Ob86SQGq XiaU+60NFshm2wzD6XCepj9eXrg6PTrk72BYu5O9pbVVoItgwa15tYSXpo4nc71G+/aDHVbn Du3jvZWBiuuj2/ao+/2KrUEx15jkZF9+NcYsZU3IbryvG7fs4pEo2ZaVzVh1euLJs+Tx7VfY KpM3W3/Zi4MVWQ30DnPFiG3GLTc9Gx9bxKPjAznpmw5kQ1M2mRHGhSNK/qzAZKnixt/xQLKc IonCH+k/8mQHd4i476vkvCuEm1QO7bdynMUewtkVicrkzNr4HJv9gNiM+xJP+nD/x4VosfkP jtS6Bv2A7a1BvB2qxSonEVtX+NN2utg8mT7cN5PSJUv7+2BSuvhAAPVgy+tke4rt5yyd9XcT utL+9hhL1yuW9rfJjqU/Nh56HhQQseGYpT8iJOo1nbDpLzQoOrn/Pf9H3P+ejaerkP9frFaz 2cLf/56c8f/HeM73v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3 v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v8/3v3v3v/0GAS+QWZ8jFvtidFr+ty1C /HhMz6gUMYILfqWP6/o5XQlT5WiIYapL0o4us7ktNkxQZH6z4HieQu7HEhk0kinJy9oGDKnk 5Ei743EH/aeyiTcnK/tIeoCT8FFiY/ODKtdZW3sc92uBGMJY2m+sYhOPjRzvRzve86ZkJSfP HH9Z7Zhnjhs/Yiu2iI/lKrYBKw+1gxTCyKbP9GmeLyZTdmXqM6khJmKEuzW1mg5NmlbepvVM 4YWz+s3T5aVsaMmtPxnwfp+zD2+X1NthpA5zCLpK8LN1G+YK5UYAI4ayt2l3BWWKeFZSP5vK 7LfHWcVkk2JS5DQCj0mCnnFmdo0WxOpjjkLF+Sfl3nUpwNPdCmaHjslAgTjKmy6Zvf8picpu No8mjZTB+K3xxZItk42aLo1DVPh1qY87PR4lxPy93wcwqX4s05f9b3tX2hu5cUS/81dwJwgs 7Uri8Bxpd2XACeLYHxIbMwmMwDYMzqHVxHMIwxkLSuD89tTR3eziXJJWxx5FQPYs2WwWm81m VfV7r8EVDth/dXM0XrfhCIwo+FX45vjwveUU4JEHfeNM20nNO0gqBEy/DXdKKnx1sSQSCDLS UQsAbtVIC/CnDtOLNbaKJ0AxA4aRAvgb1sXHS9nsW6DqDE+lzgCW1U+fmr31DnPQLe7VNM7h Neqk96g+N7RfJzfNyo+cWEfWf3eDM8QW0KTcm+FU0zvgQ/mOZteRnj3GUIIbfjKGKLA1yggS dyPzcng6ZYBvTLQH78X4Cqc5adIVsxs2iWEHmFFmJ4zxZHKB2Te/pFlDfInoafYRSWjZ5Wtf LDjVvef48s/NFAWG6AP0kMfL+r2X9uJbsygrk32Z8PhGsSU3GYEDhzTRgo+BYzNMWeLJjUQy ftAWmHLCVA89QzsTZp0dnJ2mEYAfmwFo8mTtrJlkwyFzVDG+oEYbmOk3bBkcHjnJs+HGHPzA ASZa1gVsqfqHqn/s5bnBPwSO0vDaJbYSC/nwSltIQC6xkEBdmkKCLIeFBKjSFGow40IBzrSF BGATCwnMJgRHYDXERmAWhEZQJURGA9K/gIIQDoGlTvMAmqR7dt7PrGABxTYkWHD6BnuBlwKA y0T9NIKjb5E+R4BhM0a1sIPjbCZ+QjsQoCx+g89HZdvVh5vex7xBGtUWnrmg7IwshNoblmQ0 pkI1YFC4BlRFmp1AkK4ZFMHxhk2Ux1izyprkquum642G1UVde2kBfvUvHcERuPpdL00hKmUv OuuXxkqjru3eAmlbX/p+1y04Bj6G8nTdYRbBPuwBosUz2+ICybv32mDq1itntqZuRleu8Dtd VgwJ4y8ajjGjJBokUdcZIODBGw2wEjHRfhtyW5m5+202YF34wpgmEWjk2ohREW2yY58Riet1 yU4jCtELBAbat2GzAaNOtMuGwlaGojncx+TLiPOuDm3hZ36hpImsKMdnO41Akd/Cuq2mUU2s YMLjBPom+GUCj9dpxfgSSO93tSy08idmVGq7aVsUSTriQJZuv4IP8gknpTGHYrPUmO3h+ppk 3lDizZ34yi3tNI+qzk+d8ge+G0dQj708J01cE4X1JDtOYGxROMIhtrIQyA0up7VfIOMb9l/k 0W1vgSRwcCGzLgPssWJzdfSFzAeom0qMFjFwME3KxjykeJW9g63me5pVnGBM3lezStWq7PYJ q1X5/WqjWtWaThV/AuC8epDp2LfvIcSrQq7IH9wN0pNJfVtiTjGcqeyVbrfZfP7P8/D/07jT SSz/Py6KlPn/hfJ/nmJT/o/yf5T/o/wf5f8o/0f5P8r/Uf6P8n+U/6P8H+X/KP9H+T/K/1H+ j/J/Ho3/QzGRkoCUBKQkICUBKQlISUAfAAmIMp23YAIpA2gXAwg805JYAji2XGImGa2/LMnV NelRL21zW15QIHhB4e15QeCelOzJGE4QnnCGj9MOj2aUdY6O81yUPaTsIWUPKXtI2UPKHlL2 0JOwh2pyUDc+AvcOcabwB/5JN4e/Av7ANemewt8Z/MVtA8evcy+1n1Q7KgSI28MTCjFbjXPo S56new7Zc4Pje1wCEPxDcIBwX7fjk4KwhM8LohKFTxTCEj5XiEpkPnkIS/j8ISqR+zugBL5W pmd/QQkXniSvVn3wdpaMdXh9fGit9hlIVN+ZT0nCEj4riUrEbZ+nhEV8qhIVSX3uEpYQUvBY 4vQOfCYIlw4G7UOCLxK1Iz3vE/emTzBjaBPHvYFzfGoQ2HrezwWOnOIk08fhMvRJprUdIgsP PcIrEw8nt3wga5ZgUDnU/cEgPry3USZIq+H3sWcT8ZViH7uK7xsblzWNE8ytBjWob7hK0R2t q8Ha6/ygvuWpvCVyToPKlFhSVbFGqhLssXUOU9/jVd3a0NQhfjcSmfoFEpne0nWtOWQbGzko fISGMVPw13Zwv3wbB1m008yOgz27YdazE0+O4PBbQlY3GtT1ScMNuxt7LpJWKoFOCXRKoFMC nRLolECnBDol0CmBTgl0SqB7bwKdx/9Kn2v916KTu/Vfi7ij/K8n3Dz+V/qs/C98dSwzRa4s H/xpffbGYjEw9TsMD4bza0qrlov5ajYM4kIwb7zJIkLb1VBxO9sXcLKe8pYLjAUddcaSzTza zIlBB13TtCvP0xB4k1ZqXE1GZqnN1bSPvsjLsBwOxwzJXnBWy0K0X/tTCQbJC++pI3HZeauE aTAVVmY+/KZxoIoW7LlsWXzCUchwHpwbGA8Z6GYRT8vyV7CtMJWZ2ziCMZL+3aIm9WaLG5yY gKqpRvC0GBWEQov0EfQZeQRm8ekUHpsCInE2ob6fIY72OMIF4Tv4eQk/x0H4K/ycYLaOzinZ G0f/Br5dYLaDbRM+y4IixXNGkDXYCv0IH65bJpRQ0zTow3FELZazd4YTM+dJfyIwmKpn+CQm 8MwvCeSP0xluksK/ZwOthkc14LQ4Qg5pMnPEjDF2VJeXC4Qt43zhZN7HBU3N/Ocxz396k90E xpiUOFvAq9B+y3OAzPW6tJNQSNHClX1xQmFu+2w1CphZVd/2EUN47OwHGUp0musSuoWZFaMZ MUGgPHFOD2K9Tf6ZeFDTq/GEp1DtZLa5PhgUmElHb3HWcrWcT0uiVCKm5vj7j2f90U9KhusW S5raJrF5dPuqwkAzgTF7ifD80KAJCG/pv4KEd6H5Meqi+JJdIQcMG2AQkxspE9LexfCOMnsx LLhhMdXNBUXCzlQHj4XnwPAFX8yJ6OPRhtF2NkekTO0KrPdclrW3YVlWTvqd83ERwYvj5CTL dFvdNoPMHBc5Me94zscfdUHX0Lvg0Bgs0zN+gaxhESUHZFxqFnjlSOA8hg723T///E344sUL KitiDVkWF05H0O/LLavDUrH0nJea3bRQrClAnreMbr17GHX4HmREIgvkm0IGu7bsy+aCsnDI LCmLh8SisnDILCv7srmWLBwyq8niIbGe7AP4f57//0irv+71/4uk7fQfkjhuk/+fddT/f4rN 8/+zZ/X/sftDAabAI6QSaQs2Wye/uaXjhdVY+cBnVh6B/WPEIrqUyYVImn1RBYjoQK+eUOxh NcFV7EMbBYjKHW0GL1HRYOYUENjZM0ify5Hn8wR0xOkyzMkTZdIxXBba4C+zITItmU9AyBJE /9e7MPmCjBasq2QE3HQ+8zUo5CfNwANPgu8wErriWy7BK/5hPENUGlJx1wjpgSNDGlhGI+Ip Ec5mI5PqZjodYboKEWWO/7tCnBCS4cBZXVxMblrh11//48RCt6khGU6/GFfmy2uzXdVqcQV7 sWk33Rb4+0tMfc7KxWJ+jfEKEZFbiPNoGVh1Td9kPIvhZS7nAeGPmduF/keN353My2FULZHb esTUSIiSoMsa/QoPG4QBw4lzgtG5QXhT4D9wgZ5kx5f4Iz8YFgVjKBEy+ps5Y4K8S/ZeDFna 6TkwNb+2m+BVfF8taJyL1SRAtFiLoU8WxCY1T07Cr6hxHeiRL8KU9evyZv0qxAjFrBhOw2FD QHg6qxCAarx3lylrCIHwQ2b7DhDBi31/dOhdhdU0zG1Dn8TMfHyIoMyb46uyWvpE1zBMDk1A 71EvbLRvkUTQkDhbas5ID/0bwQIIi2PANuES6ZEjgG9cZ2Zd8M8NxhERtCYnm7M18zg8Rwef X0xsfGicmkFHL66N2mwscOHuGgrmhyZyswBQBID9BuF53TTUEXGqCe6AJAmWq1mJWOIje++D 1YIIWz6fwEETiT/FvS/c1j8J0LlERkkZXoyucXWE1dKQuaC66gpha9RPSwuAp5HZH1kZq468 qsHSDBoE+sYUOnXqkGiUlcN+IY3JxMfmra+lcf6NcOaLm1DKvBh0+BDxjxRBYHtK3LfLUK8q CH8DHsPhltjn34CRZ96NpV0cBczDSNqYkUkSaiWE4MK/4oL+e3p3HesPNIjdqC/9+cW1MvDc GF02Q7za02dk093CxbWotFmXjB0bcVl9QsrhijttY5BoCm6OEO3BW4SH+P/OtngQ/49h4Za4 0Fxlc0xoDjYi5PpgZz08rg+erkWSu8K+031h39m951Z3BbB5I4DdFVfmB4Wlx9jv0OG+oNfJ V/y6LyiVJb3o9MB8GUZDvpqY2fLquMAQG593KEPRRhnOaYhJKr9AhyqREWujANXw3BHQ5735 +o+/xI+TAdgd/ydpnJn5v7zADcqncZJr/P8Um+o/qv6j6j+q/qPqP6r+I2dQVP8xVP1H1X9U /UfVf1T9R9V/VP1H1X9U/UfVf1T9x4fXf1TpR5V+VOlHlX4MVfpRpR83WPbE0o+3UH20dav6 o63lsbTtalGrhxC2w+GRRO2CO4vaGYpysFPU7hubRVAluqdSorsrPmsaH4XTBP5S+CNsVdnG Lg9/sLeEvSW+Ajn8FfCHWmAGOWU+GkSi/TBRXliiBzX3oOYelOhBiR6U6EGJHpTobcGBfWpA sPsiwCT0S8K8JL5LArt2gbgkUktCs/ZoztDbL3Y0RWGohNixJtlCRcSOpqAKlRA71lRNnDiJ 2/HeSiRNDZJBehsNEpUaUakRlRpRqRGVGvlopUZ0+wA3gf+kLOTDY0D34D/bcZ5Z/GectpH/ mbU7qeI/n2JT/KfiPxX/qfhPxX8q/lPxn4r/VPyn4j8V/6n4T8V/Kv5T8Z+K/1T8p+I/Ff+p +E/Ffyr+U/Gfiv9U/OfHh/8UwE+XIDhRUKWCKhVUiZuCKj9mdb0HAmFu0UvfqIwuJfCk5p0U uZOqdreRsdusXfeAgnVSmm6z6JwUmGtAlaR0uVQrl4rnDy5XrtsDbwL/kzyL/luWO/xPp01r QaH+m67/9CSb4n8U/6P4H8X/KP5H8T+K/1H8j+J/FP+j+B/F/yj+R/E/iv9R/I/ifxT/o/gf xf8o/kfxP4r/UfyP4n8+PvyP6r8pVEmhSgpV+vShSs+s/0brS/roI3yEYmFPKIGl5CKeTkEN djvhsoEncgUW+Kpf3bPzQSrEiMil6lD1FS2gXPGsLU2G0+MZxNEwjbqJMVMuFPpeBhT8hT62 akjbDMijYRZ1C9FHNqrf7TcHrN9qTmZr6ma7zBkl0SCJus4AAfPaaIBVHYuwMXbbkNvKuvlO G7CuqJvbJpHrqnq6etEmO/YZkdjKjAbWNiMK0THk8q230PaLdtlQ2MpM3xhmQinriFLFboLI D1ahpElYU1hiO41YP/auyoO+aVQTK1qdkWmexp8TIXsvnUNxNad2aK62R+3whONodPtsYI0O KtenMogqg6gyiCqDqDKIKoP43luN/8XA9Dnwv+00S9uI/0067bydMP43izuK/32KDQJA//EH 9ns/HRkAcBLG6es8fx0nNQAY/LN/lbNZ+NfVeAhj4NsmIPjLILCTqGXYul7gR3jRqieTCISE +Z/KoBJoFKZkAJpBSIQTnoe5puxW2LqYzMtly4fgUoIiGM5HFeIfLUKGxheE/nHyAPMCAU1O m1SxScaRj4l5ynejRVBSCmm0HA8wrYC5M5y/oq/Nu8EgPJ5MQ7+NwuMfwF7OP/xhPBtMVsNR +LZaDsfzk8svvV1TxBHBHhwp9iUqcMCwZYbzFQI99qYw1j81eCGJr+WB6D6ZjvvkEyqEVgxC gjwbVHl8cBj+12uolmEbxCeDVhD8vvGcfMs5uT0HG24Kj5vKhaalwsmPpz9jzI1Hx28CajD8 fs6rg+zl3375/tsoLg6xwDQxuwu5OzW7E7cbff/1ctl6uVdr5aAgdviD8Xn7TTh+C171+NUr tjcEU8c/QyUV3MLBGOIjPO0wOqXqf+cE/vnkxzbdThnDz5h/JvAz4Z8p/Ez5ZwY/M/6Zw8+c fxbws+CfHfjZ+Zlsqh8L/RORocuLg9ZPhN0/xbaDpwkur7/REX7O4eufZj8FPL/wx1cncX4R mmCK/8VHY3E0bhxNxNGkcTQVR9PG0UwczRpHc3E0bxwtxNGicbQjjnb8o7OWTRf2zIvUMy9T z7xQPfNS9cyL1TMvV8+8YL0ON3evfd6Lz3vJeS8972Xnvfy8V5z3OtBFvGeT67N5jmezGC1X i1mIj+L3D9JXe4xN8L/SZ+F/FW32/5D/lSRFh/hfca7+31Nsyv9S/pfyv5T/pfwv5X8p/0v5 X8r/Uv6X8r+U/6X8L+V/Kf9L+V/K/1L+l/K/lP+l/C/lfyn/S/lfyv9S/pfH/zK44GuqCXPE NL6U4XD+n9HMxI91eiYYQowwNt8V36/zc7oUpsIghomCUcVpx/HFaDKavcMExQVPFrgGYOYK egZLypRM5tXI+JAB9MrxdDU9Cf8+h4temmHBJYoa7LFrEyUuR5ObYN6/WFXsx70gF4MaFsdv eIspDpfMpTEysPDJUk4ec/zzxRTzzHbih8aKS4iPiSRVQlPeVONH5M+xb0+0q0opdEqhUwqd 3ZRCdwcKHXNVPBZdGDZ2YAnBrMMSYgeWEGw7LCF2YAnBwMMSYgeWEKw8LCF2YAnB1MMSUjyc t+pqjikHM6wZJtYLOt/n9tWEH7gbcHvAntuz4mRNXLVkPsHjwVezjxyZkXjqG6mE69ZEd6Pp ucqQHLODpof1Rl1rwxaiIrEJlauoXEXlKipXUbmKylVUrqJyFZWrqFxF3T6yrcn//N8jXGM/ /zMh/H+nk3WyNuH/i7St+P+n2JT/qfxP5X8+L//zZaIM0M+GZagM0A/32XyWDFDddNPtc93+ D+ZrWvMAkAEA --------------886E41FEECDD1F508ACB9474-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Apr 16 20:52:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xZ89-0000G5-00 for ; Tue, 16 Apr 2002 22:00:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Apr 2002 22:00:45 +0200 (CEST) Received: (qmail 21189 invoked by uid 0); 16 Apr 2002 19:09:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 16 Apr 2002 19:09:16 -0000 Received: by moria.seul.org (Postfix) id D38CA1468D4; Tue, 16 Apr 2002 15:09:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D68B1468E2; Tue, 16 Apr 2002 15:09:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 1E5C21468D4 for ; Tue, 16 Apr 2002 15:09:11 -0400 (EDT) Received: from ifurita (212.194.220.171) by mail.laposte.net (5.5.044) id 3C9FA0F0003A7C4E for f-cpu@seul.org; Tue, 16 Apr 2002 21:09:09 +0200 Message-ID: <005901c1e577$e18456a0$abdcc2d4@ifurita> From: "Christophe" To: References: <3CBB7783.F2AC1A8F@jetnet.ab.ca> <3CBBD88B.ACD6F6A7@f-cpu.org> <000201c1e536$0c693260$a0ddc2d4@ifurita> <3CBC5B72.1A66A316@f-cpu.org> Subject: Re: [f-cpu] RC5, F-CPU and srotl Date: Tue, 16 Apr 2002 20:52:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Tuesday, April 16, 2002 7:12 PM Subject: Re: [f-cpu] RC5, F-CPU and srotl > hi ! > > Christophe wrote: > > I knew FORTH as being in fact a mix of compiled and interpretable code : > forth is always more than one can think of, one reason is because the > coding density is extremely high : the code is both the source and the > executable, it is highly reflective (in a certain way, it codes itself) > and there are a lot of sophisticated techniques that are mixed at every levels. > It gave me some headaches and sleepless nights when i was young and i stayed > with Turbo Pascal instead :-P IIRC, when Forth "compiles" code, it's often a > "condensed" representation of the existing modules, something like : > putting each code module together (copy and paste) and remove the jumps > at the ends, or something like that. The "win" is because the linked list > search is not performed all the time. Today, one would use gperf and > sophisticated hash tables instead... > :-) > > Usually, a FORTH code is a sequence of call addresses (there is no opcode but > > just address), so it is more compact than a native code. > it is certainly faster than looking up all the symbols in the linked lists :-) I'm not speaking about a text interpretor but a code interpretor. My code is a FORTH code interpretor (when you run your FORTH code) but it seems to have some error so i will reput it when errors are gone :) > > i don't understand your asm code. There is probably a misunderstanding with > the jumps : the destination address is the 2nd operand. I see for example > > if (r61 == 0) jump r0,r55 > which means that you jump to the address stored in register zero, which contains zero, > and you save IP+4 to R55. The "trick" to remember is that > - the condition is at the left > - the pointers are in the middle > - the destination is at the right > ok sorry, i invert the thing > > I did create a virtual machine, that is, a FORTH-like CPU. That was great but > > not the point for F-CPU. > > i don't understand (i know i should sleep but you know me :-D) > you did this now, or you have done this in another context ? when i was in University. I simulate in C a FORTH-like CPU. Not exactly a FORTH langage but a machine code working with data and code stacks instead of registers... > i remember when i was 16 : i wanted to make a Forth machine using Turbo Pascal > and it soon became a nightmare. it's certainly easier to do this in F-CPU asm. > But a "synthesised" Forth code (not just a play with the code entry addresses) > will be much more efficient because it will unwind the data dependencies and > allocate more registers, jump much less and make parallel things. Sure, making it for a traditionnal CPU is not the best thing to do ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 16 21:55:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xbe1-00025A-00 for ; Wed, 17 Apr 2002 00:41:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 00:41:49 +0200 (CEST) Received: (qmail 17966 invoked by uid 0); 16 Apr 2002 19:55:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 16 Apr 2002 19:55:30 -0000 Received: by moria.seul.org (Postfix) id 565041468D4; Tue, 16 Apr 2002 15:55:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 369BB1468E2; Tue, 16 Apr 2002 15:55:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 774E21468D4 for ; Tue, 16 Apr 2002 15:55:27 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16xZ2s-0002XL-00 for f-cpu@seul.org; Tue, 16 Apr 2002 21:55:18 +0200 Date: Tue, 16 Apr 2002 21:55:18 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl In-Reply-To: <005901c1e577$e18456a0$abdcc2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, interesting thoughts. I would be interested in a parallel (multi-threaded) forth version or another threaded like language with a fast execution engine that uses more compact code than normally and runs multi-threads with low overhead on a single machine in hardware. And if the compiler could make best use of the registers to give each thread a max of performance... Why ain't there any multi-thread processor-pool SOCs around? JG On Tue, 16 Apr 2002, Christophe wrote: >----- Original Message ----- From: Yann Guidon >To: >Sent: Tuesday, April 16, 2002 7:12 PM >Subject: Re: [f-cpu] RC5, F-CPU and srotl > > >> hi ! >> >> Christophe wrote: >> > I knew FORTH as being in fact a mix of compiled and interpretable code : >> forth is always more than one can think of, one reason is because the >> coding density is extremely high : the code is both the source and the >> executable, it is highly reflective (in a certain way, it codes itself) >> and there are a lot of sophisticated techniques that are mixed at every >levels. >> It gave me some headaches and sleepless nights when i was young and i stayed >> with Turbo Pascal instead :-P IIRC, when Forth "compiles" code, it's often a >> "condensed" representation of the existing modules, something like : >> putting each code module together (copy and paste) and remove the jumps >> at the ends, or something like that. The "win" is because the linked list >> search is not performed all the time. Today, one would use gperf and >> sophisticated hash tables instead... >> > >:-) > >> > Usually, a FORTH code is a sequence of call addresses (there is no opcode >but >> > just address), so it is more compact than a native code. >> it is certainly faster than looking up all the symbols in the linked lists >:-) > >I'm not speaking about a text interpretor but a code interpretor. > > >My code is a FORTH code interpretor (when you run your FORTH code) but it seems >to have some error so i will reput it when errors are gone :) > >> >> i don't understand your asm code. There is probably a misunderstanding with >> the jumps : the destination address is the 2nd operand. I see for example >> > if (r61 == 0) jump r0,r55 >> which means that you jump to the address stored in register zero, which >contains zero, >> and you save IP+4 to R55. The "trick" to remember is that >> - the condition is at the left >> - the pointers are in the middle >> - the destination is at the right >> > >ok sorry, i invert the thing > >> > I did create a virtual machine, that is, a FORTH-like CPU. That was great >but >> > not the point for F-CPU. >> >> i don't understand (i know i should sleep but you know me :-D) >> you did this now, or you have done this in another context ? > >when i was in University. I simulate in C a FORTH-like CPU. Not exactly a FORTH >langage but a machine code working with data and code stacks instead of >registers... > >> i remember when i was 16 : i wanted to make a Forth machine using Turbo >Pascal >> and it soon became a nightmare. it's certainly easier to do this in F-CPU >asm. >> But a "synthesised" Forth code (not just a play with the code entry >addresses) >> will be much more efficient because it will unwind the data dependencies and >> allocate more registers, jump much less and make parallel things. > >Sure, making it for a traditionnal CPU is not the best thing to do ;) > > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 17 03:12:02 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xbe2-00025A-00 for ; Wed, 17 Apr 2002 00:41:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 00:41:50 +0200 (CEST) Received: (qmail 31492 invoked by uid 0); 16 Apr 2002 21:46:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Apr 2002 21:46:37 -0000 Received: by moria.seul.org (Postfix) id D5CAC1468EC; Tue, 16 Apr 2002 17:46:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A9B6D1468F5; Tue, 16 Apr 2002 17:46:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 2106D1468EC for ; Tue, 16 Apr 2002 17:46:34 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-153-160.dial.proxad.net [62.147.153.160]) by postfix2-2.free.fr (Postfix) with ESMTP id CF1775F9DC for ; Tue, 16 Apr 2002 23:46:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function Date: Tue, 17 Apr 2001 03:12:02 +0200 X-Mailer: KMail [version 1.4] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <200204160437.18048.cedric.bail@free.fr> <3CBBC15C.F217A462@f-cpu.org> In-Reply-To: <3CBBC15C.F217A462@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200104170312.02479.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > > > You overlooked the fact that `var' parameters in Pascal are actually > > > pointers, although they don't look that way. The same is true for > > > reference types in C++. > > That depend on your compiler, no ? > > So who disagree with adding this recommandation into the manual ? > I don't disagree (if it is needed, then it's not a bad thing to put it). > However, i wouldn't make this mandatory. > My reasoning behind this is : call/return conventions are designed for > computers of the 80's and 90's with 16 or 32 registers, F-CPU has twice > more. It sounds simple to simply double all numbers but this sounds like > using old methods for new computers : you can't win much there. Euh, I hope that I didn't understand what you say. Did you mean that we must continu to use the normal stack call + save all the registers ? Or did you have an other idea ? (Don't forget that we must have a call convention so that we can start to write F-CPU asm and compiler). > Today's most advanced compilers can perform in-depth analysis of the > programs and find the (mostly) optimal register allocation : they examine > the data life length and their usage statistics, decide whether and how > long to put (swap) them in memory and even modify other parts of the > program to enhance the register reuse. It really depend on the language and it's capacity to explain how the application work. I think for example that in eiffel we can have a more quicker application than in a pure C program, because you know all the world and in one case and only a part of it in the second case. So fixing some call convention will be needed, so that we can discuss from a language to an other. > If there was a mandatory allocation, these advanced compilers (something > that looks like a "synthesiser" in the ASIC world) won't be able to compile > anything more than leaf functions. That would be pretty useless. > I hope to be not too much misunderstood, Euh,... I think that I didn't understand what you mean ! ;-( A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 17 03:24:50 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xbe2-00025A-01 for ; Wed, 17 Apr 2002 00:41:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 00:41:50 +0200 (CEST) Received: (qmail 24899 invoked by uid 0); 16 Apr 2002 21:46:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 16 Apr 2002 21:46:41 -0000 Received: by moria.seul.org (Postfix) id 7E8F71468F5; Tue, 16 Apr 2002 17:46:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4CE4E1468F7; Tue, 16 Apr 2002 17:46:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 690EB1468F5 for ; Tue, 16 Apr 2002 17:46:35 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-153-160.dial.proxad.net [62.147.153.160]) by postfix2-2.free.fr (Postfix) with ESMTP id C68375F76A for ; Tue, 16 Apr 2002 23:46:33 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function Date: Tue, 17 Apr 2001 03:24:50 +0200 X-Mailer: KMail [version 1.4] References: <20020407165956.6B13CAB@postfix2-1.free.fr> <200204160437.18048.cedric.bail@free.fr> <20020416011906.12436@thrai.stud.uni-hannover.de> In-Reply-To: <20020416011906.12436@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200104170324.50465.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > > I never see a function with more than 10 arguments, and the one who have > > more must be put in memory (like print). I think that r1 to r10 will be > > enough. But it's really important, because this register are in the same > > case as the r16..r31 unsaved register. > I think there were some functions in the X Toolkit Intrinsics... > Plus any function which takes a variable number of arguments. I think that variable size register can not be use directly mapped into the register, because in C, we use them like a vector and we can pass them >from a function to an other without any problem. So it's why I think that in case of variable number of argument only r14/r15 will be used. For example, in print, you will have the first register that point to the char* and in r15 a pointer to the parameter list. The problem is that, in C, we never use, and never specify a number of parameter. > I picked these values because they divide the register space in four > almost equally-sized parts, which gives code and compiler developers > a maximum of freedom. If the partitioning turns out to be suboptimal, > we can still move the borders around a little. I agree with you, we can only do now a first specification for the border because we didn't have any asm code or compiler to see a result. The most logical is to equally divide the register bank. > On the other hand, compilers can support several different calling > conventions (see the `regparm', `cdecl' and `stdcall' attributes in gcc), > so we could define additional `special-purpose' models for applications > that suffer from register pressure in one area or another. If they suffer from register pressure, that mean that they are doing a big complex calcul (like RC5), and in that case the best way is to save all the register and to say that the function can do all what she want. The cost of saving the register will not be so important because the code of the function will be really big (it's hard to use 63 registers). > BTW: argument registers are unsaved, too -- or should I say > `caller-saved'? In either case, the callee is free to modify them as > it sees fit (that includes using them as temporary registers). I think that saying caller-saved is a good way to mean that temporary register that would be destroy after the call. And I think that coding a register allocation algorithm that can detect this type of dependency will not be very hard and we can have some good result. > > > Note that these rules do not apply if a function is only called from > > > inside the same translation unit (in C: if the function is declared > > > `static' and its address is not passed to other functions), or is an > > > inline function. Local functions in Pascal-style languages may also > > > fall into this category. > > > > Of course if a function is in the same translation unit (like static), it > > will be included into the calling function. > > Not in any case. If there is a big static function which is called > from several places, inline substitution is probably not a good thing. It depend on the memory cost you want to pay. Always a choice : reduce the necessary memory or have better performance. > > > You overlooked the fact that `var' parameters in Pascal are actually > > > pointers, although they don't look that way. The same is true for > > > reference types in C++. > > > > That depend on your compiler, no ? > > It depends on nothing but our F-CPU API definition :) A right to. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 17 03:28:58 2001 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xbe3-00025A-00 for ; Wed, 17 Apr 2002 00:41:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 00:41:51 +0200 (CEST) Received: (qmail 26969 invoked by uid 0); 16 Apr 2002 21:46:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 16 Apr 2002 21:46:46 -0000 Received: by moria.seul.org (Postfix) id CC5E51468F8; Tue, 16 Apr 2002 17:46:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD8921468F9; Tue, 16 Apr 2002 17:46:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 640001468F8 for ; Tue, 16 Apr 2002 17:46:36 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-153-160.dial.proxad.net [62.147.153.160]) by postfix2-2.free.fr (Postfix) with ESMTP id 109C45F7F9 for ; Tue, 16 Apr 2002 23:46:35 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [Fwd: Re: [f-cpu] RC5, F-CPU and srotl] Date: Tue, 17 Apr 2001 03:28:58 +0200 X-Mailer: KMail [version 1.4] References: <1018905704.28887.3.camel@maturin> <200204160451.51363.cedric.bail@free.fr> <3CBBC16F.A0D0A808@f-cpu.org> In-Reply-To: <3CBBC16F.A0D0A808@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200104170328.58220.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > BTW, is there any way to compile & execute code for the F0 ? I might be > > > interrested in doing some assembler coding, why not a Forth > > > interpreter, but it's gonna to be hard if I must do hand-testing for > > > the code :-) > > Hum, it's where we have a problem, we have a small not all function > > virtual machin with a GTK interface. I think that YG is coding an ASM an > > michael too (I am not sure). And when I will have the necessary time, I > > will code one. > is there a contest ? :-) You want one ? ;-) > it seems that everyone makes his own version, thus addressing different > needs, no ? I think, I have some idea that can be useful for an human assembler, but not for a GCC backend. (macro, dependency detection, code coherency). > > And we will need a good virtual machine that can emulate all the F-CPU > > asm, it must be able to simulate the latency and give us some statistic > > about the CPU. > > i'll use ncsim for that purpose. > I better trust super-optimised VHDL simulators (which genererate > target-machine code) rather than a poorly designed C code (even if there is > a "price" difference). At least we won't have to deal with 2 code trees > that do the same things. ... That not the same problem, in one case we need VHDL coder and a final version of the FC0, and in the other case we need C coder with the manual... If we respect the manual, we can do something useful before we have the FC0. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 16 11:54:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xfAw-0004Nz-00 for ; Wed, 17 Apr 2002 04:28:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 04:28:02 +0200 (CEST) Received: (qmail 26687 invoked by uid 0); 16 Apr 2002 23:05:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 16 Apr 2002 23:05:26 -0000 Received: by moria.seul.org (Postfix) id 15FA51468F7; Tue, 16 Apr 2002 19:05:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EAA151468FA; Tue, 16 Apr 2002 19:05:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a210.home.uni-hannover.de [130.75.232.210]) by moria.seul.org (Postfix) with ESMTP id 1B9541468F7 for ; Tue, 16 Apr 2002 19:05:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00504; Tue, 16 Apr 2002 11:54:03 +0200 Message-ID: <20020416115403.10358@thrai.stud.uni-hannover.de> Date: Tue, 16 Apr 2002 11:54:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <20020414114731.560CA3CF@postfix2-1.free.fr> <20020414231312.27259@thrai.stud.uni-hannover.de> <200204160437.18048.cedric.bail@free.fr> <3CBBC15C.F217A462@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CBBC15C.F217A462@f-cpu.org>; from Yann Guidon on Tue, Apr 16, 2002 at 08:14:52AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 16, 2002 at 08:14:52AM +0200, Yann Guidon wrote: [...calling conventions...] > However, i wouldn't make this mandatory. No, it's a recommendation. But a necessary one. [...] > If there was a mandatory allocation, these advanced compilers (something that > looks like a "synthesiser" in the ASIC world) won't be able to compile anything > more than leaf functions. That would be pretty useless. Inside an application, you (or your compiler) can (and should) choose an appropriate calling convention. But if you're using binary modules (e.g. system libraries), you need a well-defined interface -- because you can't change them. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 17 02:12:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xfAx-0004Nz-00 for ; Wed, 17 Apr 2002 04:28:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 04:28:03 +0200 (CEST) Received: (qmail 16147 invoked by uid 0); 17 Apr 2002 00:12:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 17 Apr 2002 00:12:49 -0000 Received: by moria.seul.org (Postfix) id A904814680F; Tue, 16 Apr 2002 20:12:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9E0341468FA; Tue, 16 Apr 2002 20:12:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a210.home.uni-hannover.de [130.75.232.210]) by moria.seul.org (Postfix) with ESMTP id 78B0314680F for ; Tue, 16 Apr 2002 20:12:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00839; Wed, 17 Apr 2002 02:12:34 +0200 Message-ID: <20020417021234.16341@thrai.stud.uni-hannover.de> Date: Wed, 17 Apr 2002 02:12:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] RC5, F-CPU and srotl References: <3CBB7783.F2AC1A8F@jetnet.ab.ca> <3CBBD88B.ACD6F6A7@f-cpu.org> <000201c1e536$0c693260$a0ddc2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000201c1e536$0c693260$a0ddc2d4@ifurita>; from Christophe on Tue, Apr 16, 2002 at 12:59:30PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 16, 2002 at 12:59:30PM +0200, Christophe wrote: > I knew FORTH as being in fact a mix of compiled and interpretable code : > > Usually, a FORTH code is a sequence of call addresses (there is no opcode but > just address), so it is more compact than a native code. Everytime you create a > FORTH function (I'm not sure about the exact term to use), there are two > possibilities : a native code (ASM) or a FORTH code. [...] The `1 address per word' approach doesn't really work any longer since Forth has been ported to 32-bit machines (64 bit will be even worse, because you waste 8 bytes for every word -- the name of the word is shorter in most cases). Modern implementations use native code or virtual machine code -- or both. For native code, you need a pretty good compiler that does inline substitution, loop unrolling and the like. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 17 02:59:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xfAy-0004Nz-00 for ; Wed, 17 Apr 2002 04:28:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 04:28:04 +0200 (CEST) Received: (qmail 10739 invoked by uid 0); 17 Apr 2002 00:59:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 17 Apr 2002 00:59:35 -0000 Received: by moria.seul.org (Postfix) id 2B0FE1468F7; Tue, 16 Apr 2002 20:59:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E1811468FB; Tue, 16 Apr 2002 20:59:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a210.home.uni-hannover.de [130.75.232.210]) by moria.seul.org (Postfix) with ESMTP id AC3781468F7 for ; Tue, 16 Apr 2002 20:59:27 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00986; Wed, 17 Apr 2002 02:59:26 +0200 Message-ID: <20020417025925.32166@thrai.stud.uni-hannover.de> Date: Wed, 17 Apr 2002 02:59:25 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <200204160437.18048.cedric.bail@free.fr> <20020416011906.12436@thrai.stud.uni-hannover.de> <200104170324.50465.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200104170324.50465.cedric.bail@free.fr>; from cedric on Tue, Apr 17, 2001 at 03:24:50AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 17, 2001 at 03:24:50AM +0200, cedric wrote: > Hi, > > > > I never see a function with more than 10 arguments, and the one who have > > > more must be put in memory (like print). I think that r1 to r10 will be > > > enough. But it's really important, because this register are in the same > > > case as the r16..r31 unsaved register. > > > I think there were some functions in the X Toolkit Intrinsics... > > Plus any function which takes a variable number of arguments. > I think that variable size register can not be use directly mapped into the > register, because in C, we use them like a vector and we can pass them > from a function to an other without any problem. So it's why I think that > in case of variable number of argument only r14/r15 will be used. No, the calling conventions must be compatible with regular functions. Otherwise, the ISO C standard will be violated now and then. > For example, in print, you will have the first register that point to the > char* and in r15 a pointer to the parameter list. The problem is that, in C, > we never use, and never specify a number of parameter. We could - but it would make the function entry code more complex. [...] > > On the other hand, compilers can support several different calling > > conventions (see the `regparm', `cdecl' and `stdcall' attributes in gcc), > > so we could define additional `special-purpose' models for applications > > that suffer from register pressure in one area or another. > If they suffer from register pressure, that mean that they are doing a big > complex calcul (like RC5), and in that case the best way is to save all the > register and to say that the function can do all what she want. If the computation takes long enough to justify the save/restore overhead, this is a reasonable option. > The cost of saving the register will not be so important because the code of > the function will be really big (it's hard to use 63 registers). > > > BTW: argument registers are unsaved, too -- or should I say > > `caller-saved'? In either case, the callee is free to modify them as > > it sees fit (that includes using them as temporary registers). > I think that saying caller-saved is a good way to mean that temporary register > that would be destroy after the call. And I think that coding a register > allocation algorithm that can detect this type of dependency will not be very > hard and we can have some good result. I think the gcc terminus was `call-clobbered'. > > > > Note that these rules do not apply if a function is only called from > > > > inside the same translation unit (in C: if the function is declared > > > > `static' and its address is not passed to other functions), or is an > > > > inline function. Local functions in Pascal-style languages may also > > > > fall into this category. > > > > > > Of course if a function is in the same translation unit (like static), it > > > will be included into the calling function. > > > > Not in any case. If there is a big static function which is called > > from several places, inline substitution is probably not a good thing. > > It depend on the memory cost you want to pay. Always a choice : > reduce the necessary memory or have better performance. Don't forget the cache size. Inline code isn't always the fastest. BTW: ISO C99 says that `Making a function an inline function suggests that calls to the function be as fast as possible.' That means that you don't have to substitute every call, but that you're free to choose a different calling convention, or something similar (you can also ignore the `inline' specifier if you want). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 17 03:05:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xfAy-0004Nz-01 for ; Wed, 17 Apr 2002 04:28:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Apr 2002 04:28:04 +0200 (CEST) Received: (qmail 25036 invoked by uid 0); 17 Apr 2002 01:05:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 17 Apr 2002 01:05:39 -0000 Received: by moria.seul.org (Postfix) id 489091468FA; Tue, 16 Apr 2002 21:05:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3381C1468FC; Tue, 16 Apr 2002 21:05:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a210.home.uni-hannover.de [130.75.232.210]) by moria.seul.org (Postfix) with ESMTP id 480B91468FA for ; Tue, 16 Apr 2002 21:05:34 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA01008; Wed, 17 Apr 2002 03:05:32 +0200 Message-ID: <20020417030532.46621@thrai.stud.uni-hannover.de> Date: Wed, 17 Apr 2002 03:05:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function References: <20020407165956.6B13CAB@postfix2-1.free.fr> <200204160437.18048.cedric.bail@free.fr> <3CBBC15C.F217A462@f-cpu.org> <200104170312.02479.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200104170312.02479.cedric.bail@free.fr>; from cedric on Tue, Apr 17, 2001 at 03:12:02AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 17, 2001 at 03:12:02AM +0200, cedric wrote: [...] > > Today's most advanced compilers can perform in-depth analysis of the > > programs and find the (mostly) optimal register allocation : they examine > > the data life length and their usage statistics, decide whether and how > > long to put (swap) them in memory and even modify other parts of the > > program to enhance the register reuse. > It really depend on the language and it's capacity to explain how the > application work. I think for example that in eiffel we can have a more > quicker application than in a pure C program, because you know all the world > and in one case and only a part of it in the second case. There are also C/C++ and Fortran compilers out there that can compile a whole program in one step (i.e. read all sources first, and do global optimization). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Apr 17 07:49:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1E-000089-00 for ; Thu, 18 Apr 2002 00:35:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:16 +0200 (CEST) Received: (qmail 23092 invoked by uid 0); 17 Apr 2002 05:54:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 17 Apr 2002 05:54:40 -0000 Received: by moria.seul.org (Postfix) id 3D6CF146815; Wed, 17 Apr 2002 01:54:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DE7E1468D4; Wed, 17 Apr 2002 01:54:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 94046146815 for ; Wed, 17 Apr 2002 01:54:36 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16xiJX-00035j-00; Wed, 17 Apr 2002 07:49:07 +0200 Date: Wed, 17 Apr 2002 07:49:07 +0200 (MEST) From: Juergen Goeritz To: Michael Riepe Cc: f-cpu@seul.org Subject: Re: [f-cpu] Register allocation when calling a function In-Reply-To: <20020417030532.46621@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 17 Apr 2002, Michael Riepe wrote: > >There are also C/C++ and Fortran compilers out there that can compile >a whole program in one step (i.e. read all sources first, and do global >optimization). Which ones are you talking about? And does it also work with an application of about e.g. 1MB machine code? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 17 14:12:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1G-000089-00 for ; Thu, 18 Apr 2002 00:35:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:18 +0200 (CEST) Received: (qmail 23707 invoked by uid 0); 17 Apr 2002 12:12:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 17 Apr 2002 12:12:54 -0000 Received: by moria.seul.org (Postfix) id EB7F9146815; Wed, 17 Apr 2002 08:12:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0DE0146844; Wed, 17 Apr 2002 08:12:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 568EA146815 for ; Wed, 17 Apr 2002 08:12:51 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16xoIr-00028T-00 for f-cpu@seul.org; Wed, 17 Apr 2002 14:12:49 +0200 Date: Wed, 17 Apr 2002 14:12:48 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: [f-cpu] F-CPU vs. Itanium Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, in docs there is stated that f-cpu was at first meant to be itanium killer. I was thinking what makes it better than Itanium in terms of performance: - = better for Itanium + = better for f-cpu = register count (let's ignore FPU splitted bank) - IA64 defines twice more registers which are used as cache during subroutine calls -> less push/pop to memory + f-cpu saves 3bits here ->shorter opcode + maybe less registers -> less expensive to add next ports to reg-file (due to fanout) ? = register renaming - f-cpu has to do more register saves during calls because of fixed register allocation (call-presistent vs. call-clobbered) - itanium can do sw pipelining with less code size + f-cpu is simpler -> higher clock ? = multi issue & groups - Itanium uses stop-marks to denote parts of machine code where is no RAW->WAW between regs -> simpler multiissue logic - 6/9 issue at this time for Itanium/Merced + f-cpu saves 1bit per op here = simd + f-cpu can do simd on every op while Itanium has dedicated ops = pipeline depth + shorter pipeline is always better - if f-cpu will want to be multiissue maybe xbar stage will have to be larger ? like using 5x 4-stage omega network to do full mesh between each register and each of 63 EU's ;-] = address disambiguation - Itanium can do it (explicitly) so that you can exploit more ILP - move loads before potential overwrites of the same address + Itanium spends instruction slot for it (while Alpha does it automaticaly AFAIK) So where is the key for f-cpu to be faster ? Will it run at higher clocks ? Or did I miss something ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Apr 17 14:52:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1J-000089-00 for ; Thu, 18 Apr 2002 00:35:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:21 +0200 (CEST) Received: (qmail 7499 invoked by uid 0); 17 Apr 2002 12:53:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 17 Apr 2002 12:53:16 -0000 Received: by moria.seul.org (Postfix) id 4B10A14681E; Wed, 17 Apr 2002 08:53:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 426EB1468E1; Wed, 17 Apr 2002 08:53:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 4119B14681E for ; Wed, 17 Apr 2002 08:53:13 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204171252.39f2; Wed, 17 Apr 2002 12:52:57 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] RC5, F-CPU and srotl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Apr 2002 12:52:57 GMT Message-id: <200204171252.39f2@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I think you should sleep ! ;p The 12 cycle of the mul come from the bandwith (one result e= very 12 cycle) of the unit. This unit aren't pipeline at all ! Currently PIII have 1 cycle bandwith AND 1 clock latency (PI= V have 2 clock latency) nicO -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 17/04/02 Objet: Re: Rep:Re: [f-cpu] RC5, F-CPU and srotl hi ! Nicolas Boulay wrote: > De: Yann Guidon > > > But, could we really map a stack-based language to a > > > register-machine like F-CPU is? > > Easy answer maybie. The F-cpu has no problems with stack= s, the problem > > is that most machines have deep pipelines (like the F-cp= u) > i don't think that FC0's pipeline is such a deeply pipelin= ed computer. > In some situations, the pipeline is shorter than a plain P= entium > and it's much simpler than a P2 or P3. > >>> Most of EU aren't pipelined in the pentium. But our mu= l unit need 6 > cycles... >from memory, imul took 12 cycles for 32-bit operands on a P5= 3. i remember that i measured this in 1996 and i was surprised that 16-bit mul was slower than 32-bit mul. Other operations like add and logic are 1 cycle. So just compare the 2-cycle 64-bit addition of FC0 to the 1-cycle add of the Pentium (and other similar CPUs) on one hand, and the 6-cycle 32-bit MAC compared to th= e 12-cycle, 32-bit IMUL of the P53 on the other hand... (FC0 is 2x "faster" on multiplies and "slower" on more commo= n operations, if clocked at the same frequency) and there is a last detail : when mul executes on P5, the rest of the pipeline stalls. decode is frozen so you can't make other work in parallel ... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 17 14:58:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1K-000089-00 for ; Thu, 18 Apr 2002 00:35:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:22 +0200 (CEST) Received: (qmail 17963 invoked by uid 0); 17 Apr 2002 12:58:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 17 Apr 2002 12:58:37 -0000 Received: by moria.seul.org (Postfix) id 57B99146844; Wed, 17 Apr 2002 08:58:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 382F71468EC; Wed, 17 Apr 2002 08:58:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id BEF18146844 for ; Wed, 17 Apr 2002 08:58:33 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16xp15-0002bt-00 for f-cpu@seul.org; Wed, 17 Apr 2002 14:58:31 +0200 Date: Wed, 17 Apr 2002 14:58:31 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] RC5, F-CPU and srotl In-Reply-To: <200204171252.39f2@th00.opsion.fr> Message-ID: References: <200204171252.39f2@th00.opsion.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > The 12 cycle of the mul come from the bandwith (one result every 12 > cycle) of the unit. This unit aren't pipeline at all ! > > Currently PIII have 1 cycle bandwith AND 1 clock latency (PIV have 2 > clock latency) Ouch .. you say that P3 can do one mul per cycle ? It seems that P4 makes multiplier two stage .. it lead me to conclusion that Intel's NetBurst mean: pipeline everything to be able to raise clock .. It seems that current Pentiums are not so slow machines .. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 17 12:07:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1P-000089-00 for ; Thu, 18 Apr 2002 00:35:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:27 +0200 (CEST) Received: (qmail 11916 invoked by uid 0); 17 Apr 2002 17:54:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 17 Apr 2002 17:54:54 -0000 Received: by moria.seul.org (Postfix) id 5D73A1468DA; Wed, 17 Apr 2002 13:54:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BB3D1468E8; Wed, 17 Apr 2002 13:54:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id CDBF31468DA for ; Wed, 17 Apr 2002 13:54:50 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00494; Wed, 17 Apr 2002 12:07:11 +0200 Message-ID: <20020417120711.64843@thrai.stud.uni-hannover.de> Date: Wed, 17 Apr 2002 12:07:11 +0200 From: Michael Riepe To: Juergen Goeritz Cc: F-CPU Mailing List Subject: Re: [f-cpu] Register allocation when calling a function References: <20020417030532.46621@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Wed, Apr 17, 2002 at 07:49:07AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Apr 17, 2002 at 07:49:07AM +0200, Juergen Goeritz wrote: > On Wed, 17 Apr 2002, Michael Riepe wrote: > > > >There are also C/C++ and Fortran compilers out there that can compile > >a whole program in one step (i.e. read all sources first, and do global > >optimization). > > Which ones are you talking about? And does it also work > with an application of about e.g. 1MB machine code? It should (but you probably need a lot of RAM). I don't know how aggressive they optimize, but the C/C++/Fortran compilers >from Intel perform what they call "inter-procedural optimization". Some older DEC/Compaq Fortran compiler for the Alpha did it, too. I'm not sure about Suns Forte (formerly known as Sun Workshop) compilers. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Apr 17 21:27:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16xy1R-000089-00 for ; Thu, 18 Apr 2002 00:35:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 00:35:29 +0200 (CEST) Received: (qmail 16415 invoked by uid 0); 17 Apr 2002 19:21:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 17 Apr 2002 19:21:38 -0000 Received: by moria.seul.org (Postfix) id 0103B1468EC; Wed, 17 Apr 2002 15:21:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D62901468F1; Wed, 17 Apr 2002 15:21:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 49A531468EC for ; Wed, 17 Apr 2002 15:21:35 -0400 (EDT) Received: from f-cpu.org (kdl16-220.n.club-internet.fr [213.44.18.220]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 7639B17AD for ; Wed, 17 Apr 2002 21:21:25 +0200 (CEST) Message-ID: <3CBDCCBF.154EBA86@f-cpu.org> Date: Wed, 17 Apr 2002 21:27:59 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] RC5, F-CPU and srotl References: <200204171252.39f2@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Nicolas Boulay wrote: > I think you should sleep ! ;p to your big astonishment... i just woke up now :-) I was being advandcing an article this morning and i couldn't sleep before i solved a problem. > The 12 cycle of the mul come from the bandwith (one result every 12 > cycle) of the unit. This unit aren't pipeline at all ! obviously. > Currently PIII have 1 cycle bandwith AND 1 clock latency (PIV have 2 > clock latency) how could they perform a 32-bit multiply in 1 cycle or two ??? Do they have such a large MUL unit ? > nicO then, Martin Devera wrote: > > The 12 cycle of the mul come from the bandwith (one result every 12 > > cycle) of the unit. This unit aren't pipeline at all ! > > > > Currently PIII have 1 cycle bandwith AND 1 clock latency (PIV have 2 > > clock latency) > Ouch .. you say that P3 can do one mul per cycle ? It seems that > P4 makes multiplier two stage .. it lead me to conclusion that > Intel's NetBurst mean: pipeline everything to be able to raise > clock .. > It seems that current Pentiums are not so slow machines .. > devik Now that i read this, it strikes : nicO is not speaking about the multiply but the add. it becomes obvious now ! Yes, P3 does a 32-bit add/sub in 1 cycle and P4 does it with 2 "minor" cycles (in the "2x" clocked pipeline). I don't have the new numbers for the multiplies, though. Concerning their speed... don't you realize that the chips are getting very expensive these days ? you usually pay for your performance, so if your system is well balanced (enough memory bandwidth) it should be ok... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 18 00:19:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16y3S4-0005Cf-00 for ; Thu, 18 Apr 2002 06:23:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Apr 2002 06:23:20 +0200 (CEST) Received: (qmail 13741 invoked by uid 0); 17 Apr 2002 22:12:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 17 Apr 2002 22:12:32 -0000 Received: by moria.seul.org (Postfix) id F3FFE146803; Wed, 17 Apr 2002 18:12:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0852146817; Wed, 17 Apr 2002 18:12:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 8F331146803 for ; Wed, 17 Apr 2002 18:12:30 -0400 (EDT) Received: from f-cpu.org (kdl16-96.n.club-internet.fr [213.44.18.96]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 74F8616F4; Thu, 18 Apr 2002 00:12:27 +0200 (CEST) Message-ID: <3CBDF4D5.6B34F0ED@f-cpu.org> Date: Thu, 18 Apr 2002 00:19:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Goeritz Cc: fm Subject: [f-cpu] Re: Navier-Stokes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Juergen Goeritz wrote: > Ji YG, > > are you also thinking about several caching strategies > for f-cpu? I can think of LRU data cache as not being > always the best strategy when computing big arrays, e.g. > big array mult. What's your opinion, could there also be > a PCL (partially cache lock) or a ULA (update last again) > or a UR (update randomly) strategy? i don't know why you called this cache-related post "Navier-Stokes", unless you have an idea ;-) FC0 controls the L1 cache and uses 2 means to control the data locality : - L1 works with LRU or whatever strategy the user implements. Personally i have better confidence in LRU because it's more predictive than others. - cache hinting flags : the load/store instructions have a flag that indicates whether the accessed line can be stored in L1 or directly flushed outside of FC0. So if you know that you won't reuse this data, this bypasses the L1 "buffer" (because it acts as a huge FIFO for the write back). Together and with some adaptative algorithms, this is enough AFAIK. Adaptative strip-mining is an efficient way to process large data sets at the speed of the L1. I think that multi-level strip-mining is also possible, though a bit more complex, but if i think what you think correctly, this will do the trick. readU, > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Apr 18 07:47:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcS-0000Dn-00 for ; Fri, 19 Apr 2002 02:51:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:20 +0200 (CEST) Received: (qmail 11546 invoked by uid 0); 18 Apr 2002 05:49:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Apr 2002 05:49:07 -0000 Received: by moria.seul.org (Postfix) id 7E3C31467EE; Thu, 18 Apr 2002 01:49:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60A5D1467F6; Thu, 18 Apr 2002 01:49:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A75371467EE for ; Thu, 18 Apr 2002 01:49:02 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16y4lx-0003sk-00; Thu, 18 Apr 2002 07:47:57 +0200 Date: Thu, 18 Apr 2002 07:47:57 +0200 (MEST) From: Juergen Goeritz To: Yann Guidon Cc: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi again, On Thu, 18 Apr 2002, Yann Guidon wrote: >hello, > >Juergen Goeritz wrote: >> Ji YG, >> >> are you also thinking about several caching strategies >> for f-cpu? I can think of LRU data cache as not being >> always the best strategy when computing big arrays, e.g. >> big array mult. What's your opinion, could there also be >> a PCL (partially cache lock) or a ULA (update last again) >> or a UR (update randomly) strategy? > >i don't know why you called this cache-related post "Navier-Stokes", >unless you have an idea ;-) :-) just some control change for heavy data reuse on large scale where normal LRU strategy always results in miss. >FC0 controls the L1 cache and uses 2 means to control the data locality : > - L1 works with LRU or whatever strategy the user implements. > Personally i have better confidence in LRU because it's more > predictive than others. But if I want to use a switchable strategy I need some means to control this beast, don't I? Are there any registers where I could add those control bits or do I have to make a separate set? > - cache hinting flags : the load/store instructions have a flag > that indicates whether the accessed line can be stored in L1 > or directly flushed outside of FC0. So if you know that you won't > reuse this data, this bypasses the L1 "buffer" (because it acts > as a huge FIFO for the write back). >From this I understand that the load/store opcodes each have a flag telling the cache what to do with the data, i.e. keep or forget immediately after use. >Together and with some adaptative algorithms, this is enough AFAIK. >Adaptative strip-mining is an efficient way to process large data sets >at the speed of the L1. I think that multi-level strip-mining is also >possible, though a bit more complex, but if i think what you think correctly, >this will do the trick. Yes, this would do the trick. It's still open though how the high level language developer (f,c,c++) could use/influence this option manually. readU2 JG >readU, >WHYGEE ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 18 09:41:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcT-0000Dn-00 for ; Fri, 19 Apr 2002 02:51:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:21 +0200 (CEST) Received: (qmail 7859 invoked by uid 0); 18 Apr 2002 07:35:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 18 Apr 2002 07:35:27 -0000 Received: by moria.seul.org (Postfix) id EA1E71467EE; Thu, 18 Apr 2002 03:35:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD5D21467F4; Thu, 18 Apr 2002 03:35:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id F27EE1467EE for ; Thu, 18 Apr 2002 03:35:23 -0400 (EDT) Received: from f-cpu.org (kdl11-182.n.club-internet.fr [213.44.9.182]) by relay-2m.club-internet.fr (Postfix) with ESMTP id C3BC716EE for ; Thu, 18 Apr 2002 09:35:18 +0200 (CEST) Message-ID: <3CBE78BB.4D6AA430@f-cpu.org> Date: Thu, 18 Apr 2002 09:41:47 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N mojn', i'm now finishing this paper about DCT. A few hours and i'll upload it on seul.org. But in the meantime....... Juergen Goeritz wrote: > Hi again, jop. > On Thu, 18 Apr 2002, Yann Guidon wrote: > >i don't know why you called this cache-related post "Navier-Stokes", > >unless you have an idea ;-) > > :-) > just some control change for heavy data reuse on large scale > where normal LRU strategy always results in miss. this happens but LRU (which creates a kind of "FIFO" before the "dirty" data are written back to the main memory system) has a more predictable behaviour than other strategies. With this method, for example, you don't have problems like with 2-way caches which thrash all the time if your "stride" is a multiple of the block granularity. ouch. > >FC0 controls the L1 cache and uses 2 means to control the data locality : > > - L1 works with LRU or whatever strategy the user implements. > > Personally i have better confidence in LRU because it's more > > predictive than others. > > But if I want to use a switchable strategy I need some means > to control this beast, don't I? Are there any registers where > I could add those control bits or do I have to make a separate > set? At this time, there is nothing prepared yet. At least a few SRs should be present to give the programmer the HW configuration (block size, line width, replacement strategy) at least in a hardwired way, so the user can select the proper algorithm. But a configurable setup is not excluded, as long as it doesn't hurt the cooperation of tasks (like the MTRRs, it must be accessed only by the superuser). > > - cache hinting flags : the load/store instructions have a flag > > that indicates whether the accessed line can be stored in L1 > > or directly flushed outside of FC0. So if you know that you won't > > reuse this data, this bypasses the L1 "buffer" (because it acts > > as a huge FIFO for the write back). > >>From this I understand that the load/store opcodes each have > a flag telling the cache what to do with the data, i.e. keep > or forget immediately after use. yup. that's in the manual since... huh... a long time. > >Together and with some adaptative algorithms, this is enough AFAIK. > >Adaptative strip-mining is an efficient way to process large data sets > >at the speed of the L1. I think that multi-level strip-mining is also > >possible, though a bit more complex, but if i think what you think correctly, > >this will do the trick. > > Yes, this would do the trick. It's still open though how the > high level language developer (f,c,c++) could use/influence > this option manually. Adaptative strip-mining is a very high-level construct which requires the user to read the system clock so he can dynamically adapt a set of parameters (usually a buffer size, which will converge to the size of the the L1 minus the most used global variables). It's not often straight-forward but highly portable across platforms, because it will adapt to it automatically. For example, i had designed a program on a PMMX and found different performances when run on a PII because the cache strategy is completely different. However, the LSU hints are not "portable" and not accessible from portable C code. Intrinsics or macros are probably necessary, but it's as ugly as using MMX intrinsics in C code, so go figure... But if a compiler is "smart" (?) enough, it should do the job. This goes along with the same process that is used to globally allocate the registers, because program-wise statistics (and even profiling) are necessary to set the good flags at the right place. > readU2 > JG > >readU, > >WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Apr 18 10:25:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcU-0000Dn-00 for ; Fri, 19 Apr 2002 02:51:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:22 +0200 (CEST) Received: (qmail 16847 invoked by uid 0); 18 Apr 2002 08:24:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 18 Apr 2002 08:24:51 -0000 Received: by moria.seul.org (Postfix) id 6A4F41462FD; Thu, 18 Apr 2002 04:24:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FBD51467F4; Thu, 18 Apr 2002 04:24:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id E2CD01462FD for ; Thu, 18 Apr 2002 04:24:48 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16y7ES-0003yH-00; Thu, 18 Apr 2002 10:25:32 +0200 Date: Thu, 18 Apr 2002 10:25:32 +0200 (MEST) From: Juergen Goeritz To: Yann Guidon Cc: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes In-Reply-To: <3CBE78BB.4D6AA430@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 18 Apr 2002, Yann Guidon wrote: >mojn', moin, >i'm now finishing this paper about DCT. >A few hours and i'll upload it on seul.org. >But in the meantime....... > >Juergen Goeritz wrote: >> just some control change for heavy data reuse on large scale >> where normal LRU strategy always results in miss. >this happens but LRU (which creates a kind of "FIFO" before the "dirty" >data are written back to the main memory system) has a more predictable >behaviour than other strategies. With this method, for example, >you don't have problems like with 2-way caches which thrash all the >time if your "stride" is a multiple of the block granularity. ouch. I didn't want to argue about LRU, did I? Its purpose and benefit is proven. Only if your data size exceeds cache size it may be less performant - if you must access each value multiple times and you can't find a clever order of sequential access in your algorithm. >> But if I want to use a switchable strategy I need some means >> to control this beast, don't I? Are there any registers where >> I could add those control bits or do I have to make a separate >> set? >At this time, there is nothing prepared yet. At least a few SRs should >be present to give the programmer the HW configuration (block size, line >width, replacement strategy) at least in a hardwired way, so the user >can select the proper algorithm. But a configurable setup is not excluded, >as long as it doesn't hurt the cooperation of tasks (like the MTRRs, it >must be accessed only by the superuser). How about special register access methodology opcodes? This way you define the entry point how to access them but do not need to fix everything (layout, number, etc.) >from the beginning. Just have it read/write for superuser only, one parameter being SR#. >>>From this I understand that the load/store opcodes each have >> a flag telling the cache what to do with the data, i.e. keep >> or forget immediately after use. >yup. that's in the manual since... huh... a long time. ... JG at his high desk carefully blowing the dust off the ancient manual nearly falling apart. Carefully turning each page to not have them crumbling to dust. Only by the contrast enhancer glasses he is able to read the fading letters from the yellowed surface... :-D >> >Together and with some adaptative algorithms, this is enough AFAIK. >> >Adaptative strip-mining is an efficient way to process large data sets >> >at the speed of the L1. I think that multi-level strip-mining is also >> >possible, though a bit more complex, but if i think what you think correctly, >> >this will do the trick. >> >> Yes, this would do the trick. It's still open though how the >> high level language developer (f,c,c++) could use/influence >> this option manually. > >Adaptative strip-mining is a very high-level construct which >requires the user to read the system clock so he can dynamically >adapt a set of parameters (usually a buffer size, which will converge >to the size of the the L1 minus the most used global variables). >It's not often straight-forward but highly portable across platforms, >because it will adapt to it automatically. For example, i had >designed a program on a PMMX and found different performances >when run on a PII because the cache strategy is completely different. Anyway, who wants to end up programming around hardware cache strategies? :-/ Could probably be easier to change the cache strategy on the fly? >However, the LSU hints are not "portable" and not accessible from >portable C code. Intrinsics or macros are probably necessary, >but it's as ugly as using MMX intrinsics in C code, so go figure... >But if a compiler is "smart" (?) enough, it should do the job. >This goes along with the same process that is used to globally >allocate the registers, because program-wise statistics (and even >profiling) are necessary to set the good flags at the right place. Jo, jo. But there ain't no PD compilers around that could do the job, are there? The gcc 2stage profiling optimization features are not thaaat convenient to use for global... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 18 22:27:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcZ-0000Dn-01 for ; Fri, 19 Apr 2002 02:51:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:27 +0200 (CEST) Received: (qmail 28583 invoked by uid 0); 18 Apr 2002 20:20:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 18 Apr 2002 20:20:44 -0000 Received: by moria.seul.org (Postfix) id B46891467FE; Thu, 18 Apr 2002 16:20:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7545B146803; Thu, 18 Apr 2002 16:20:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 5D8C31467FE for ; Thu, 18 Apr 2002 16:20:39 -0400 (EDT) Received: from f-cpu.org (kdl16-23.n.club-internet.fr [213.44.18.23]) by relay-1m.club-internet.fr (Postfix) with ESMTP id D735D170D for ; Thu, 18 Apr 2002 22:20:36 +0200 (CEST) Message-ID: <3CBF2C19.90922B6F@f-cpu.org> Date: Thu, 18 Apr 2002 22:27:05 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] new files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello everybody, i have put an "old" more-or-less broken snapshot at http://f-cpu.seul.org/new/snapshot_yg_3-2002.tar.bz (just in case people wondered if i was still active ;-D) but the really interesting part is : http://f-cpu.seul.org/new/dct_fc0.tar.gz which you are highly recommended to read and give feedback. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 18 23:28:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMca-0000Dn-00 for ; Fri, 19 Apr 2002 02:51:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:28 +0200 (CEST) Received: (qmail 31057 invoked by uid 0); 18 Apr 2002 21:22:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 18 Apr 2002 21:22:37 -0000 Received: by moria.seul.org (Postfix) id 685501462F9; Thu, 18 Apr 2002 17:22:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B80F146803; Thu, 18 Apr 2002 17:22:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id A4A121462F9 for ; Thu, 18 Apr 2002 17:22:29 -0400 (EDT) Received: from f-cpu.org (kdl16-49.n.club-internet.fr [213.44.18.49]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 11A8516FC for ; Thu, 18 Apr 2002 23:22:26 +0200 (CEST) Message-ID: <3CBF3A8D.B8FA750@f-cpu.org> Date: Thu, 18 Apr 2002 23:28:45 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > On Thu, 18 Apr 2002, Yann Guidon wrote: > >mojn', > moin, jo gojl, > >Juergen Goeritz wrote: > >> But if I want to use a switchable strategy I need some means > >> to control this beast, don't I? Are there any registers where > >> I could add those control bits or do I have to make a separate > >> set? > >At this time, there is nothing prepared yet. At least a few SRs should > >be present to give the programmer the HW configuration (block size, line > >width, replacement strategy) at least in a hardwired way, so the user > >can select the proper algorithm. But a configurable setup is not excluded, > >as long as it doesn't hurt the cooperation of tasks (like the MTRRs, it > >must be accessed only by the superuser). > > How about special register access methodology opcodes? > This way you define the entry point how to access them > but do not need to fix everything (layout, number, etc.) > from the beginning. Just have it read/write for superuser > only, one parameter being SR#. i don't understand exactly, but just in case, here is the current method : - there are only get, put, geti and puti as means to access the SRs. This instruction stalls the pipeline until it is sure that there is no access violation. - the SRs are either hardwired (read-only, for example : the mask revision), supervisor (read-only too, if you are not running with a suitable privilege) or user-contolled (for example your private size registers). - the hardwired registers provide informations to the running system, they are defined during the CPU design and say how many SRs there are, what kind of CPU, what is the register size, what opcodes and what units are provided... - The "superuser" registers control those features that have any impact on the running system, for example the trap handler addesses, the TLB, the memory mapping... Note that when it is possible, an individual "authorisation" is allowed to every ressource so a pice of code can deal only with one ressource at a time. A task can only reset this bit (when it is set), but not set it, to enforce the system's protection. This is a bit similar to the Hurd tokens but can be used in other places such as Linux as well. - The "user" registers are those which have no protection bit, for example the task's private performance counters or size attributes. A user can be "granted" access to a SR-controlled ressource if the super-user modifies the associated SR enable bit, but otherwise all the task has is a virtual address range to play with. There is no specific opcode for managing that, it's all done with get/put and it traps if the necessary rights are not granted, that's all. > >>From this I understand that the load/store opcodes each have > >> a flag telling the cache what to do with the data, i.e. keep > >> or forget immediately after use. > >yup. that's in the manual since... huh... a long time. > > ... JG at his high desk carefully blowing the dust off > the ancient manual nearly falling apart. Carefully turning > each page to not have them crumbling to dust. Only by the > contrast enhancer glasses he is able to read the fading > letters from the yellowed surface... :-D just in case you have not found, it's almost at the end ;-) > >> >Together and with some adaptative algorithms, this is enough AFAIK. > >> >Adaptative strip-mining is an efficient way to process large data sets > >> >at the speed of the L1. I think that multi-level strip-mining is also > >> >possible, though a bit more complex, but if i think what you think correctly, > >> >this will do the trick. > >> > >> Yes, this would do the trick. It's still open though how the > >> high level language developer (f,c,c++) could use/influence > >> this option manually. > > > >Adaptative strip-mining is a very high-level construct which > >requires the user to read the system clock so he can dynamically > >adapt a set of parameters (usually a buffer size, which will converge > >to the size of the the L1 minus the most used global variables). > >It's not often straight-forward but highly portable across platforms, > >because it will adapt to it automatically. For example, i had > >designed a program on a PMMX and found different performances > >when run on a PII because the cache strategy is completely different. > > Anyway, who wants to end up programming around hardware cache > strategies? :-/ nobody "wants" but there are cases (yours ?) where this becomes necessary. Fortunately, the cache has become quantitatively and qualitatively better with the PII because the L2 cache was much closer to the core. The bandwidth and the response time got better and they probably implemented a speculative prefetching mechanism. So my code ran at L1 speed from L2-size buffers with a PII when it only ran at L1 speed and size with a PMMX. > Could probably be easier to change the cache strategy on the fly? if you want to change the cache strategy, there must be more than one in HW. Intel's MTRR (and the competitor's equivalents) provide a mean to modify the cache strategy for a fixed number of memory ranges (for example, the video memory can be set as write-combine and multi-CPU shared memory space can be set as uncachable). This is usually possible to modify this when the system is "alive" but there's still a risk of loosing data if you switch from one policy to another when you forget to properly flush the caches etc... But that's for the x86 world. This is possible to do this for F-CPU but i don't see the point of a MTRR-like system, at least for the first-generation F-CPUs. I am not exactly sure of what you have in mind but if it's simply changing the cache >from write-through to write-back, do not forget that F-CPU is a multitasking system and a user task doesn't have to change an environmental variable that might impact the rest of the task's performance. So as a rule of thumb, the FC0 has a private memory range (as fast as possible) and public range (uncached), and the task can specify whether to keep in cache or not with the "hint bit" (flush) in the load and store instructions. This does not impact mullti-tasking systems at all and is very simple to implement. > >However, the LSU hints are not "portable" and not accessible from > >portable C code. Intrinsics or macros are probably necessary, > >but it's as ugly as using MMX intrinsics in C code, so go figure... > >But if a compiler is "smart" (?) enough, it should do the job. > >This goes along with the same process that is used to globally > >allocate the registers, because program-wise statistics (and even > >profiling) are necessary to set the good flags at the right place. > > Jo, jo. But there ain't no PD compilers around that could > do the job, are there? you mean, profiling compiler ? > The gcc 2stage profiling optimization > features are not thaaat convenient to use for global... profiling is not often used, but it is useful in constrained real-time applications, such as if you want to track where your soft DVD player wastes time. If you have a relatively coherent program you can attempt to do some auto-tuning (adaptative programs) which has the advantage to be portable, but you often forget what "convenience" means when you are CPU-bound, memory-bound and ressource-bound, no ? > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 18 20:06:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcb-0000Dn-00 for ; Fri, 19 Apr 2002 02:51:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:29 +0200 (CEST) Received: (qmail 3707 invoked by uid 0); 18 Apr 2002 22:10:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 18 Apr 2002 22:10:13 -0000 Received: by moria.seul.org (Postfix) id 1BF101467F5; Thu, 18 Apr 2002 18:10:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE200146803; Thu, 18 Apr 2002 18:10:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id EA60E1467F5 for ; Thu, 18 Apr 2002 18:10:08 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00542; Thu, 18 Apr 2002 20:06:28 +0200 Message-ID: <20020418200628.14566@thrai.stud.uni-hannover.de> Date: Thu, 18 Apr 2002 20:06:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes References: <3CBE78BB.4D6AA430@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Thu, Apr 18, 2002 at 10:25:32AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Apr 18, 2002 at 10:25:32AM +0200, Juergen Goeritz wrote: [...] > >However, the LSU hints are not "portable" and not accessible from > >portable C code. Intrinsics or macros are probably necessary, > >but it's as ugly as using MMX intrinsics in C code, so go figure... > >But if a compiler is "smart" (?) enough, it should do the job. > >This goes along with the same process that is used to globally > >allocate the registers, because program-wise statistics (and even > >profiling) are necessary to set the good flags at the right place. > > Jo, jo. But there ain't no PD compilers around that could > do the job, are there? The gcc 2stage profiling optimization > features are not thaaat convenient to use for global... gcc (I suppose you mean 3.0.x) doesn't optimize globally, and the profiling feature only has an effect on branch prediction. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 19 01:27:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yMcb-0000Dn-01 for ; Fri, 19 Apr 2002 02:51:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 02:51:29 +0200 (CEST) Received: (qmail 8130 invoked by uid 0); 18 Apr 2002 23:21:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 18 Apr 2002 23:21:56 -0000 Received: by moria.seul.org (Postfix) id 2BF7C1462F9; Thu, 18 Apr 2002 19:21:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFF7B146800; Thu, 18 Apr 2002 19:21:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 61F781462F9 for ; Thu, 18 Apr 2002 19:21:51 -0400 (EDT) Received: from f-cpu.org (kdl16-63.n.club-internet.fr [213.44.18.63]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 6BEDE1686 for ; Fri, 19 Apr 2002 01:21:32 +0200 (CEST) Message-ID: <3CBF567E.302CDF7B@f-cpu.org> Date: Fri, 19 Apr 2002 01:27:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: Content-Type: multipart/mixed; boundary="------------03ED80715F6060887E1CDCD3" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------03ED80715F6060887E1CDCD3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, sorry for the delay... i have glibc problems ;-) Martin Devera wrote: > Hello, > in docs there is stated that f-cpu was at first meant to > be itanium killer. hell, that was loooong loooooong ago ;-) before we can whip Intel's ass, we have to make a first proof-of concept for a lot of things, build a name, design a complete working workflow and user base... FC0 is not yet the ia64 basher people expected, but it's a nice core anyway :-) > I was thinking what makes it better > than Itanium in terms of performance: > > - = better for Itanium > + = better for f-cpu > > = register count (let's ignore FPU splitted bank) > - IA64 defines twice more registers which are used > as cache during subroutine calls -> less push/pop > to memory > + f-cpu saves 3bits here ->shorter opcode > + maybe less registers -> less expensive to add next > ports to reg-file (due to fanout) ? the register set is still a big issue. And it is already huge. I had plans for a 128-register core with some particular "tricks" so 64 registers would be implemented as a normal set. Other people wanted the usual 32 int regs. So we found a compromise with a unified 64-register bank. A 64-bit 64-register bank is 4x larger than what is found in a MIPS R3000 and this can cause electronic problems if the technology is not suited. However, as you can read in the document i just released, 64 registers is not too much in some critical circumstances... I have not looked deeply into IA64 and though there are 128 physical int and fp regs, i am still unsure whether the opcode is limited to 32 registers (then the "window" moves through user-controlled register renaming). F-CPU can't afford all the latency and the huge hardware it requires. OTOH 64 registers is equivalent to the agregated number of int and fp registers in most RISC architectures, so it's realistic. But the number of ports is already a problem for us. > = register renaming > - f-cpu has to do more register saves during calls > because of fixed register allocation (call-presistent > vs. call-clobbered) > - itanium can do sw pipelining with less code size > + f-cpu is simpler -> higher clock ? * register renaming adds at least a pipeline stage so the jumps are slower. We can't afford that now. * FC0 has been designed in the beginning to have "very short pipeline stages", allowing the core to reach a higher clock frequency than a traditional design. It also prepares the rest of the project to very-high performance design habits, for example it creates a pressure on the compiler from the start. We also try to not "bloat" it and avoid hidden critical datapaths, at the cost of more software latency, but this keeps the overall frequency and performance high. * function call/returns are often a big deal, but the large number of registers and modern compilers should help avoid unnecessary work. One ongoing discussion deals with global-wise optimisations that analyse the call tree and keep only the most important things in the registers, avoiding the silly spills on the stack. The object code is probably larger but it should execute pretty fast. > = multi issue & groups > - Itanium uses stop-marks to denote parts of machine code > where is no RAW->WAW between regs -> simpler multiissue logic > - 6/9 issue at this time for Itanium/Merced > + f-cpu saves 1bit per op here yep but FC0 is single-issue now, we will examine the issue logic problems for a later core (FC1 ? FC2 ?). There were several threads in the past about this... > = simd > + f-cpu can do simd on every op while Itanium has dedicated ops experience with MMX coding has helped here ;-) > = pipeline depth > + shorter pipeline is always better > - if f-cpu will want to be multiissue maybe xbar stage will have > to be larger ? like using 5x 4-stage omega network to do full > mesh between each register and each of 63 EU's ;-] that's pretty far fetched... and i doubt that there will be such a large interconnect between the execution units. The plans i have for designing FC0 don't use such a method because the units have a very specific form factor. > = address disambiguation > - Itanium can do it (explicitly) so that you can exploit more > ILP - move loads before potential overwrites of the same address > + Itanium spends instruction slot for it (while Alpha does it > automaticaly AFAIK) The memory system that i have designed (i know that nicO is not very hot about it and if he feels angry enough, he'll design his own ;-D) is very unusual. it keeps everything coherent at the cost of a bit more latency, which can be hidden by the usual methods (such as software pipelining). the F-CPU programming model is simpler and maybe more naive than IA64's but it makes its implementation mush easier, as well as code generation. OTOH the coding guidelines are pretty strange, too, for the unexperienced, because the way loads and stores are performed is very different. > So where is the key for f-cpu to be faster ? Will it run at higher > clocks ? Or did I miss something ? F-CPU is designed to be and remain fast, rather simple (or at least manageable by a small team), predictible (that is : allow static scheduling during compilation and warrant that software can run in a give time) and long-lasting. It is much simpler than IA64 (just look at the Instruction Set and the registers) so F-CPU will suffer less from enhancements in the coming decades. did i forget something ? :-) > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------03ED80715F6060887E1CDCD3 Content-Type: image/gif; name="ia64-isa.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ia64-isa.gif" R0lGODlhsQIiA7MAAJyYnGVjZQEBAf///8zJzOTj5PLz8trX2oJ/grezt/v8++vt6/Hs8fv1 +z0+Pff49yH5BAAAAAAALAAAAACxAiIDAAT/cMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/AbQhQI DBaCEH62j/v/gIGCGgh5IQ52Aw4eBBOLM48WB4OUlZaXWg4CACEIiR+GPgGNmKWmp6g/AAkB oZoJAnkEm5qGdYqurQUDdQJzrQGsuQK7mrOhEq0NAgfCjwYOAALBrckBiLCIiq2cysR12qni 4+TlFoahBQILuAOFEr68iejwo/QDoff48AbyFYbQ4HEyFA3eAAKPFhEbAIDTvocFEpqb+OST BAMIPDmYIwGAp2sT/zB6SlCBFQKHyRA5IMBxQoJJE+oEAACOnUmU20BKeHDLZQAE/SiYvEbS 58c67GKqXNVx5IRZdTjK/OiA5FCZNn8S1QD1p4SrSAckQKS155eILwU8mjUhj1exbucNUGfB QLWHD/PNMeTpX8dpP0nylYsvkoBGDsgi2JUvEsXHSgQUpbDwLr45syYfvvCu7adp/xw/WthQ Qmd4RQ0gi0XBIoXOrCecPtm2ZbjLE+jeIQhvjl3ToWi7Q4eMgu4+w2V369fZcZeVCRJIk8DW YM8DcQ3C+jfQoMHq+OzYcj2+wq18jjarJ3UHLy72kOMPKVQcH8zY8ZLDg1nhtGUJzsUmwf99 MJFyWmJChSJNKK7Jls9kpw0QVH6O1BbTJ4ncxxFMEQZ1mmQXmPVJhwNwaAh/Xli0yUHovUWT OxyhUxQiDtHDDjqk3JORXwMoEBxDzVDG0Fd5CMCAfgD0Y4hD28nnZBBF7kKZlGr1BlxbKDrY 1mQSKCDkiv9k+SF8+BQl3iMNXqmfmu50WR9lLWH3yAP/tMRmS51FSIGcO2lpWn9vbqFaAF5K GAsAeNgDnHR54JGHNJzAwhp2J4EWSwGQDsCAZBsxtGIsSXnKUS3ExbKINGmhNdxAsdghDWbE VPXkrD0k8EuAABzT1kqFsMcMZ4bMIiUGizRJmZjB/gpnMqjxgkH/IQgg+BpgoK0pVh1FUVji oefYOVwvI/oiLQbYgQkcuICywRZKMwW5wWQF7DIsBjiBwB8nBBwAQCTMYVBAoRT0S+vAOjDD aJgvUbZKvcqmy+K85q2CHZf2OYwHxPklAgsD3mqp7Zoc6flhx9IE6O1sHndsQcl+tjktG9j1 p7IQVSYTFME4O1FVWipmids5KBqYT72UEZAAAf9V/LJAPDr7l3N+btZyj/DAN7JLUy67dJdq Sm0BlwtZC7C1ZyjQCnsROQAxEa1Mc3POcCfhGHj4rG0uZTcn7OnUipgGn5FZUzAddathSIEm 9Bpi7N4V8oLM4Pig5JgAY9/NOIB/EUks/2WFQt73BJ7HLfroX2jCX9sLKCBNAChKCp8BC4KT LIjAIWDrI7CgpM6vsE/D3zGT5Q7VU77c/CbwAMZzjEzVDmf76kRK3Yrtt8Hl9fLoIo8LAnS2 5stYiWAPDPG0k27++eWU9gIBRNewQK4aePl+qDHIjyj6+Oev//789+///wAMoAAHSMACGvCA CEygKOYAizQ9QV/tU6AEJwgZByRFMFbIgwO6R8EOepAc6mDKQY5EhRch5IMoTGEpHDAJyl1O Cqy4lgpnSENAzIQXpBhFFRYRjBr68Ids4JQibGWFkzgQiEhMohKXyMQmOtEJ4NtIBE1glhF0 6olYlALUstiWUP/QLQUGWJwIEEAm6nDxjEWIhRrXyMY2uvGNcIyjHOf4xiP6QU9bPMEXVRAo NPoxB33UwscEUb4KIGJFxohN2vIwMdAcknDGmQZrHgmgfV1DHYk4pKQCUIAFJKZRkmQGJf9I yhUEkgQe6SFN1IY0jXCJZS4YJCCENYED/OR53hFAP86TkshVzR9fjJaEHhGzngxGEY2Ijmq8 AxJh+ghzpYwmCk5JgvzErGuKy8NYYjkzP+CBhBKgS2KiwhjT7GUq+IDP9FhknhgdxR8PucUs OFIdwHjlLZcCgkhkEowHsFAP1CzBOmAwUBfYUiNTlMQtkFOEfW7lBDyx4weE+QRoVCP/UQLS QEBFEA/dsAlEytooCGQJiOZtK50TuFEyEHDNtpBiO335ojHPwZBE9GR37BSjWQohURuE7QAK KSMG2JPHFBRVqCDII8VGoJuMbiAcRa0AUmcQNqeOQIwkYMkFpvqDzdxCmFxtywsk01I1wcZC LCDpH+i2KSQpyZy+dFZI4VpWGMHDFh2x2i8AxDp0OMQOO3KZSGXQMC95bQODHev6esqBlqq1 P4wVUsH4E7YS7DGtSljnWzqQWA+o0QLQkhZ4HjsC0sYBKkfDT6s8xSrr5UEdowmlRxrmqKSo MVJrFIxbmIGOYn1WNQOVzGZ9ADjBkuKQUllnq3iiTXHRjir//yTcvgR0yF3AggALmB5rgIGS RtrhkxeJxjRWASJLCuABpqpplbxhtFFWwLG2EsAymtEK3ElyDog7SGIS0grdctKT+TXvWMEJ yrZto7nRop0mWUSfSBr4kA6JhkraceBNFqMag5pkf28AUzuYpSpF7SxnaVKcd+RntN2sZooD ob7cjO0CS+3IRTwwGTscra39wUCMxbI2HqhlfCjFp9Ho4VF0wCqXoDUyXnB00rq5h2nxVEgl f8mbHSlgNN3xTh6xQwBdPSQgZXrIFe9xGG3ErKm95E0sVRKcRfioEec5sqymU895CRNTNXIH YWK2ErEkYJmfi5kwPZnMhLaAL3MIbP9fhivZQ+MXGbDJkUsdPUHswKQAK45CcWPUCGXl1y6y QE/F2NIkEB2NJG/Zjl5QWs9OnyNH6DwmSvPpD54GZsmVlcSjJLu6nwA1ZHJhNEMQV89Y5zqt JBzccJU7CbYUp9WtGZVi4JksBkPyMjLhBT1Ne2jZggqZ+sWAiDkAJtNlDi4AyhY3KThdk2ah YVQmxXQ+xc5cNqLO+zjGOvqyLRyHh9VMrs9mdCqeSX/LH1V0D0/JJXBrKMzh+9DJTl4banQD KrIhaNh2NZaHvmzG2RPwErQv9MsZPyp8hsBpPc3zCZziwCFvA7i4XeC6u+oyFjOKB2/Hmmlp bnXAYfq3Imj/kuftlLNi1wTAAXrsIvFIGunoaGF7sARlV7lrP4LVtnfa9KMn56bhPVLQXQKb B/QOSBpeilmp/5r1WBI40TGC669iVrNFXBPeil4SneBXS7fw9Zr5BaxU+Aqlewdq3C7oeWkV 7/NGq6B3auv7PGayiHlCr0qQShRzGaNG1xTiYJri1Byw42FiYBIfXuOTa21eJdKXySvDI5Wo UCPsEnHjZq9KnmrpgylEppenmtiLb/FjkhZA/hrxqC3q28bTzaN+oLrAZKGU/3wb59ZxoL57 bD8F/Z0H4Z4ORLwTuH3GRC4J+Y674YJnAIBhxWsuHyDJAggQEZy0i2KGBsFk8KUv/+ckoMcl omMA+AGtIyEXUAD8URQ+IxZCMYA0AHMZsGMb8C/McmP1MTMSyHg1UCQZIH5NQH5npEv+ICNi VmhMYC7OEVg0UDO8EHMdZGnhpIFPkGIeeIIyiEWyNhyuZm1NAFTpZRyJ4YAs0DYB4IIe1G4Y xwU1uAQgyEXlARLq8XVLmAGYxhQKwG/RdAsNlD901IVe+IVgGEc36AZa6G5TIB3tg2hm52R4 tQ0xcA/VUwaYMoZiABDC1wUquARJmAJ7iAJxaAl2WBhWsB2yIjjcVxgLgnrZ5X0EhV+m0YdX oE2QCAbHRodJoA9KEFUvoIku8IeUUIlX0GcnxAGN8GJ/Qv9VDDKJJRR3fiBKCTGFQ4CJcpMD nNgCMVQKrpg8kWh4TEhhCTcGMxUHpQYToTOIJLgEtcgCybgCnigIw3huVCCKy7gDK2dXZ0B2 f4CJsAglW5eJtEiLqpgG2lhEHmaJNiBFnOAo4jgX23gF0UJEwtUFsogE02hUOXCLmPCOe4GP O7RNB5QAHJMFEWUKLaaHORCOVoSQjacBJFZaYfiQEBmREslGV4BVGTeRGJmRD8mEGtmRHqlG 5ngGHzmSGhkDEaFnHPWJgORGJnBZI6UG7RhLY9CEbRCTafQPbzQCtedZKokDYJdVvsAaGbZR NtmLkTGTIWkGRZkBqlGPJlAcb9L/WUSIB1vIk0AAS4ZUEIAkArPQbttSlR1IU5ZFEB1XeVaJ BkvJRy6QSiSxSgXQSg91EFORfxmXlB84TwFAlWY4cz7ZjYTVNI43UTHCCUIYmDaAE9vhj46A XxJIUCMAG3tBmIiFkn4ZAqOldaAAk0ZJaU2mH/jhCYVQmHVJBr+yL0wjml4nA2Nml+TWNHOY mhxgTERFRBq1A5NzHzwCaDcgYqlWJLOpMs0lVmMpVh9Gm3yJlpuZVnPgUWtyGG8TkzQ5BZtx d6SQXXlZm7vJIU5ZWk2jTcXYAbLZLKeUlhmgImjVnFtJBxnim+J5ARVXmSBQHWxBdhgUlus4 AxZVYFbl/55jlRYOoycvwpliQIg58nSBRJ5BRzaOyWsxImJkh5vWeJw1cA3AQBSr9lFhdWg6 yREvMlcRKlaX+ZQNAUrBBVcSqpQrCGeAZZatGUtWFVpQY5PRKQWw8zcQeqA+KSV6sqDCaUyd dQwKAFvMZEcIGiLEc55j0pdjJBnToXrl4RchagJ8xyO/KJzIOaHxsFmdd6J81JAvM0gyypqZ uEYPIKSlJoFF2hYRJqbYKZxkB4s5yJ86YJ4lV2+w+YY6qXQxFqcG4Vh4SplyeqUy0GHwRE/h x3MU1jXwEaACGgY21mXI0FQDmKamMRo+1Z1zkTRPCQ8OSKmHczjqxmvbualj1P9N6GA3jtM9 S3mq9imof7ojeXinMhphyjI4i1OUMwoF+cUQFDOPhgkJY0GXKQCVsrFNsHiS4wklfjoA6GWR VCUCaQOAyBqoVuoC09qqIrmC3lZQ8NmtJlBzzwdcOYcAhtWIZEAfhfga0UGDOmCKf/mr7Zh/ nsoVGZChivUCEfSTXBldGWBo88qNDzhjKzNF/3oBC0A/ygkHB7CAlEGSDhuRgFmtIOClF/mw Fnux+0lYLClQ9qpRGPuxYQgEUVWwPsmmYUCyu4mTGxsCJ4mFmTkI86qvHMWwL+uqPtamlGiy lDiTEeutGrCTnCUEOmQBiSGsmGWZtDApkrGXhil+m8D/Ld7QmL/Ksz7wftj6Bbl6nyfbs3da nq2ilxhXsPVyXUTLmOnZCUq2IkIos6OJD3RiCBw0mVqLBCBbt2+ks0dwGL6Ql0sbWSh7qfD6 mIMJf2eJAzFaRgARsxuqOYd1tV1LbjDBS+HUjBJbBn8LngcJjqQ5CabpS6h5uSvItbw5D6Rg NtRUsA3SuB9ytiBwHezZI5pamU5rIAUnGxIFugWDjN+IA/xIiY1AnZN7u1RbuY+LAeE5IKeL AxQKGNGluvnQsWpJBxwqHvxRV5XrtFTSjVU6tXWou4aruWNAoHXqstSKtaIruFh3bTh7A6lL Jkmaskt6MKpnpz0rfmfTKbkH/3GOS5reewOjWgKUKyhTqjTwtL9KeL5ISzlCqr4GPAPtK1Wi Br8hcH9DdXhiWQKqU57CO7dH8L8k4MFXpZBMQCrntcAFzKXyiMAq4JLcq5pAI5adK8EgEKsQ zKVpScNcO7z0uLv+K8IGeTR7tL3Ee8CBuwLWe8E+kA3C2az/2lnRmgFH7HVLqY7ra7n9e47g Gwa7KkKvsWK4+67EC4umG7flewRGe7QsMMZlfLlfrKSz+L2868NKgK5LRcUdaLd4/FlFLAIU +5Iwu5JtZFn8Wk15XMiB7I1w3MO4qMPPd8gsuwjky1mGPMlfyLo+S27Qi8KMbAQgLAKdfAhy 3L2iHP/Gi1tNPSnDl4xYNFu4KIrI/nuPoby1owyfUvm1fVuzgfCjSctIt1zFTrsg3SBfhVTF /JtZmWu4sUy3eAm2rOwFxIrEgnmauFxSj5m2kunLTxkjb9snQcvBRkDJdYu3acS5WEa4LSrL pKyeJUcfYdXGNym9jCs0jSu7Txm5tYsLItjA6Ey3SEmav8tk0+zMKty6pCsheUbMcTC6yItS sEPL0JxxtPsQIYOj3vzOJyvORCC+KIXPRjjEW/DMObwBDxrSqRxEpdyhWRKVDz1S2ftkQIXQ s5y3/TwGNXosLrOjLfxuA80IsRCkLMgL/nrKM8ykvOwYN/TQ9ltmc5C/l+z/zoArA/m5GwZ2 zo+XEdl2ONdARo6Q1cmctU9AwmX60y+tzzq9xylwknJLSHl6dRWA1kh9AhlsvFLr1BuYorXG ommdVrsgDTliW43gOdCJ0UPwqJeVrDGt0ipwZWZE1jWJvhig2Afx1jAgHJOqmVj6C4wnozCR X6GQwbnGxXwk2EGwxUvVQzAtSDuNwWvkrh79Bk4chBfgI2pkimyrAguSsSWdwjNAqGbhOYhA WUD3M7HAHjuKsNMk2kFAx6DlEJV92GUcun+svETbVZb9rrBqJ89L0gK1frp3VyuI3Epw24HU NuBssb363Ltd3uqdkzhAH2v0yU+53nisrW2zIKES/yzpmtsZp6CbUiTwrVHgjQVnPAXOAVxs xD48HAjJ/FQr8wMLbpABa4Bi2Snlo9mJSlRVgaBena0JTgMBEiL/7QEhzgUjzgEx+gMlPsJA EHV2KqNUQhih9zNfIbUcFeCRqAMpngEfbgESh8WjXQQ5ruMrncg4zgNB/rI9NNbFGwK9wzp3 5SMrATnDzQoDzlk2bgVV7odEPiQ8TuMtcORJBeQdzuU9AOYaYOab4wOoYhCrkQMFyawDnLCY 8K9o3jjE2+M1UOcmLuZbvuQubOSATgTeQteNWgl0vuVvguceLgR6LuJjfrmNbkiBfokzfQlZ fgKN7hztY9qv/ONEEOlQc//pzFjmk0638v2wV14Fh97pdw7qjM7nrN7aeU7qtpmcWJvqVLDq Pt7qY17qnh7r+g0Dkf6ptX6UdYjrZzin37tGjRwTXq6Mr/7pYy7qKjDsdt7rRBCTB1UTxBMV MJLV5vrRuO1Zp+6w0x3BDOLqvx7twO7nMWDt0FTk+PlIGBVQNnkcHWUIfVAZYaqE497N+4w5 6K4U2C7vQ6DuOb3ovt7usaSi7oDXp10CLUUXIpK+/754/u6BhI7GFaIgVsrpu47isB7yMuYD 8P45Bu/AWZrZL9BSTVozqkolJb7haURdlmRBvazJH33uVpruBf/zxd7ukE7rKQ8DvP0JUr5a wU7/gHu7q+WCEpvgZYUeibERjGob8VhQH/dsGKCD8CIv7X0+9AtP8vd63ZJlqLJOAtcEDY9T Mwazytmc8RAH0KZ7OHtxDuVOkrjmRnDfiez+97NeAdRuj2Mf+Bpb39/ml21uUKvBUlkDb+tG AzitARHR9/rVQgJycnW6rFLMsxFMGV5v8iNv+GkPCUQP9LYtsBG7+C3AnEZCp8c29TwKCh2r HgIywA1THT9x0Al/459PdX1e+KdP+iU//MFP/DvwODih7dNT345DPa7iO28Y4J01z+LWabEh KTiHB5EAbRyo3Vm/ZO4Z+sb/9UJv/kXP8Ky74zVgP8Y9/T61O40Q1QWg/11MBtujJDvYj1cW CAFDTiKkHQHgOXgHQ3EkS/McLe6bBAeF4Tem62G2c1nn8ZYHdnxB25AYMx5pm8Svw1JGjwKE tCQgDBKqbCAwOGAEBY8h8b1Jwhk01iOwhA+SQhW09kgQlRDU+rdRcQIRmAMkSTo0SVQ8YTw0 AmhEeZysVLycBCkge9L8vLLTXMnKoBrg88hywaHy+iq8WIWTAHCAQ+tQCBB4GCh4ESQEJe7L uxBxKU5bHsksfo4y8oNunoi2wraG4+72/gYPFx8nLw8XnVwx4EP4SnUT2Bq8YJB9ozYpaDr2 tCZW6ZZMG5GBkPwhWjbtoISCShoSXIgCX8Qop/8+rTiGoAqeWAIavMMAa8aYe0HCUUw3rI8h Yg+zoRSyLNeEfTkIOGCpwyXMIjxT+ARkcVSACgbe8BIAAMGYAgICGHD6RhI3SR4cLAU4UYdW oDlY+FFWDeXOP2RrnOThBsjMrofYdp1oQKMXBzVvBLh6QCldIXgRHEjgwEs7LxIWCHZQdS9e X2ACEMZrtw+6SQSq1pJgNIZkSY25/eHalsZXgQlhmpUysIItWmG2vFXZb2tOr+Zs38adG7fo eSk60fKwwN6pCk0ECPdw4OmApQwHbGgxssqDqL84PHgklPdo4GmNbSdCeqXpsUALNvdQJekv E1BCk0gKRxKvBvFgvAf/fxY811gXyHBQYCo7mgMQAOTQ+48QASVIBQ8JFAglP+7w+4kQ3S7E MMNvYnsCNSROMy+HxySQR61dONjgOH56O8uOXo5p7AQKJZRIEwMEs2ABp7q7QsZ6kHmjFKMs IlAtzZjjgBcQlFzvDTU4oGwyGu/j0avvioFNEbbE8XCH8nwqqDAwuJjAQXTcA6K/wmacccoe 0+niCwReKKU9GRH74JYVHCBgqVL0BAE9JzuADo6lLguDMK20czOFKgMJ4bKWxKJJBAQk06RL IDSFyIYRn4OFpVR4aeVKr0pphx+kVKywUZNA4aWKT5/joK6Z+PsRugkYgOM/ABKQdABeSdJj /wUWCp3qxzEniJKQZv9wLSocW6gg1bQe1Y9DUDgtYQg/8CKPIm43zWEpYOMIC5UPgEMzrd+A NKCqidp01dRD5ElVTCD5RKXU9liipc5b0gNBYChRZMGBYKqQ58lN4HsWtKpmWCMWW0zCdjR7 PxnXGW0lAJfSiDrWSUQAABshlRbmaFcHXm6qYgPKsqv31ZSYq0KjfvjwAdcW1NtVhWA54HUC XS+49YKJMWgqJohBUcuVNbNwcKuMY4AiWI5Ffk6EADC1BEQwy4142Q4CSPDjGgIsAe03a95q lB3jY5WfhlnsIF4X8LLIBcss2EKtC/g8ugL7WvgavcBLwWUpwZCK8P8ixkGQh980r75v40y5 /pZkETz/cOwagHGgkxBO9MUBM+TVXIpF4fZOk6qO7KcAWGTLAQCtI91dBAOtYFSR/oD7It46 L6fXznC3xn2CkCf9kifPF0AAQiCbtwI75WGHNCIx5ggMb+6d/SSMVuS7oRvkrE6+hN4bAd1p o70GG36xpV+mZUAciLHV8bGOCBOe84LlXO9/yShbI2ryhQQQQGW1ad89vIEVDenGcBVECwiC wQ0KJil+8htZiP4hDkXUD3sHfBtMKINBFrZwHAnMFIpMKBHMySgZzRiXH4IxCA/mTkk9id79 YrAaQEUrSxcg4UEiWLMljgKFKYChJrBSF4z/YYAwCvMA5ODjOxweQof8uEySZjgCYDDniAgJ YhphgJ5TrMd0/jPgNlw4RzqCYz9PROATP3MMK9IpheKzX1A+xw+MgGwgs/IUTM5ojUWO4FMl Ot4W1YZHSjqxkj/TIy0aZp9PHeAWdgDG7ULwwbN50Wv88NcAa4CUAOjoNVirYyxlWQ4RoaFi pTiREBAwpNZd0pfA+yXBULhHkoQEDS5iligtNEtm7sZY4KANCnTmAUm8cXvB7N4q7QCAUJWp kHFcETbFOYUjyAUyEniAvrTwmCMlwBCBGcwrwhPFKe3xZKab5vxApswT6pGQpVllGyJpw3Fm qwbmgo75KBASBISx/5cFreSNlKQjLV7TJGTYAOM+sKUZLAc9ZAke7IjJDViwijq5WNMNfymM cA7OUwKtBRzmkMuHQrSmjjxZ/d6xCnA20aY0ckNh5oSKGimhPwOjVZIspIZiMdUk9ASqJgew AAIAY3fESulNucdSsETzBNPsTxUaBJafZs4G+RTBO/bZUp+WVUKxygBU2+qBH1lEJCDzRJOa alSoSugzek2E23DWUsL685sdqoHhFNAUHySgMQ8EpFsjS0aFWbMDHNHDVLQqWbjh6wv6Olpd elYRHC3wAk2YyQvuhqSK9DU/n/EkHIygOtsZhhZkXek/++ChLewDsuDkbD+BgLpf7JCtwf+9 pBVzdiaQzUcUc7WAoDJAIgEwQBQacOfhWMvXTHJlASdT6SSHqVtCeDVNDMItcjcLBH2waK4w UI5GaHeIodIgvnh531V4gwv5wGF9YiCDg6A7B6RON6atIEADf7jdKbh2PzW0KHANG5DdAtNs 4g3ue4sqXEU0DQUDhYFvHezhjO2BBOYtxuxUCq67Qfc3aEitFY9X3Zi2Vr0n1DBcJAgW1Ki2 CsTFMGdz3B47LqNqf4QBARpZAgG7lih3BFm1JgsDvQXAEHCAyi5/sIXLNGUMYdDuU2/cggwm V239IUKfrIfkGw+5bSEYIyDWUAEv2NUvS0mcR7BgAQVgkQ1UgIr/MpDaDizSGa6XXYEkcCRW ae3ZAhsQDKiUQZ8wb4NDbuZJSMc85a2euSDcpBemO821wjYCD2zsl3O+iYE1cBMZ05yzGOQk hjtgwXBxPa0ZL2CUNZGhz0qD0UIESKsgj0/Tmy71AcVTXhuU0VoTama0Z0nq9ykCD58SQyoL yQc0swG9N7CDPLBd665dwBADE5MVYZEFPD/GOEAhQDSlPe8XIttR9Ma3N3B8SAeTOd//1hCp RT2Ca7fhGvDg4bfDLCZuo6Fp6Sb3E0oBHYh7O6hbkhBaNbHk1HA8wwD/9xPCoQ1WurI6G0b2 wEe53ih4GKzlLtFUdYuvkKTTDmtAz8Ve/94BDyOOIcsFks5ozA+g5Uedm4OGx4UczGU/AcUk AGs1AWjvZO8vUkbmBQC8TKvsAsM4Y5AZEh9jHw6q67Md2fNUabEBRGWddk65mI4evR5aHCp9 az82T44etmKcgeosr1fTo/NSe2iM6irXIOAnYRQYai3OCQaC1nPw9LbsPZAtUTrc9twOk3Mc 8QsRvEsDWvgUzQErA/28q1LvnGL//ZeWx0RCMh/4OVyMmuxBeSVDn5yzusgQjC63/ja9emYQ yvWS1fgkZh8E5WDTDRwBsSR9uft0JRkOi62+Y7FH/HouT8IJacIrxwesaosG5P/ud6Mqx7g/ Aef0rRepp6PQW//naY37QPV+1TVBncyoh5T3sgAqcpP7y5/0cxPjcbqpQq0XYB0O+x/qo7zu KSPFGyfiiwTvCQEDlJ4suIlGIcBiyLsD0hM4eADG6oAVgj/Nkz/XGYBfIyoHlCwLpMAomJPV YIgPrAgOxEErYToNpBEGciAoWLAMGBqmW0GIABYJWrPvy7D8w8FxqzHY4ZcOHEDn88H8KLBf sRSmUYjcwrEITLLqISh7k0EQKL9JIDEYBI98ucL8+QNzeoWvIRHEUIoEuKL+cZ02XEPZMiE+ m4EZM8J9y5/zI0TbcMKR4SbhiIfl6wrR8geJypG5GUPg6QRPSh+jUYHpOLk85CxLdJv/bljC Qpy3I4QVRQIKRuyBGTw+lLg45vCjCDOqnICshfk20NBDuFGKE4izP0BFEVmmbwDD1BAiNeI7 41tFuIErRGKzKfgR9WALCGkSCPOKW/RCUrs81jPD/yu+EBId6FHDEpKDcCwEcTwAcjTH4xjH dCxHdTzHdXRHcdSRd2THefQHz/I267CIo9G/rcARWLgqKtAr4KHG6esibwSu59mWYRSXQzwI eXTIdjzHeIzIeDyMBZDIeZTHi3xIerS0wZqmNrCedfGiZry9PkgWLxrISzrDsuCa3ZFDa7QG bXSE/FtJ4SEG29mDB7gUL4g+JahJ0JibFFkf8tpHr8iJ6sOk/9XixGPkvv/zFq/RRpn0mG5M yBQEhJ4EBAQRA0z7QBUbJANys6HrDX+8waBISd0ryKrEG4RknoWkyrbkNEXAyj9AjyYzpbYQ ybikAb0pnQ7gla8Jn8VBooEMwRv7SWloSfrJP3+Qym6hSdArhrpMtEM4zH9wqrwkBsuwrEYo TPVqSs6BysWMSREySCbUhLm0AskMQq6EC5LiOr3UvLOkpM8szc4RzbRUyGKEzT9ATSmQzHKz SQ8URWmTTTyqzCNwSjNUTJjETWK8RsxQoshkNcQ7TpRIvkboxcnLzgpsTt0kLLZEOrfEH4Fb iN6MAl3pOc6sl+vUkoSozp+iTbU8yP+ozM2FoE+r5M3MhIMEWAC3uxnhHM5mOkbgLE3vdMld FEbnPIj7NEZ/2EHZCTznG9D4hMvvZFBuHM8CxUHzVEHVk1Cm7M7ntE3mvE3GZEh/OACoMAAV ZVEBWFEXbdEXlVGoKIMYtVEYxdEZzVEa3dEe1dEIDcRVfE9yKc0DLVESHU1qA71CkKkmZdIn BbModVI5mNIqhVIrlVImzdItddIhhUwdgMNX+IvHiMP40jI4iyZ4ugovfVC/CtHYOyHw9M4F JU35NM0B7QpIVLuKgsXRMJ0XEJTowgek7I7fMrxVpNDwnM8jLVAMtdOixFOYaMWhMs8lQjMI kS4G64MPyFT/l2jT/PDSkinS5WzUJM3QRw3VSG2GZBwQOJgxu7DUXNmrqsjUH9CrSrMZRH1T g4jTMhTP+oTTb1RVirDHwoiX63kZYU2Bx7Eip/ihWnWOhqkA0zHT2BHSXbW6Bj0bBEVMBTVR JR3W19IDoOuHkxEcSE0BWd0uWv2WX3ENtVMW6zgvEGXUBF3LC7XPOq1QdF0LxOiTRghTL+BW +FLGdSo/2DOqoPSv+sMrYrnTfwkUFpCuK0swJZM1RJtXXa3Xbr3XjVVUb81WZU2LXNjEI8AU YrFEKyiOpVqE7TQBr+Q56XCc/zKJI/kufSQ252GOGauHByoaaz2+VAUiOzVSJC1V/zoFV+xM GClQsvF4EN4cwjr7KpfNARcsx+xiLjBNEboAiJownFeIBxukA5kyuwaSRuk7vkT1zhE9Wo99 1DlVOVxtjj4jIIBcivoADFLRAiq4haqSLUIgSUrTC77Z25tIisBpAtJhgeyqiXgwplMQ3FTJ qLtYD0ob2BNQAFCkFpFdBt0JjwnFVpaMU3xF2lPd14GbVpVag9U9hhsBNuKIrijZm+ooJLJr A6PgNkPqgAbSFSuDDl2hNZCpghnwXD5Cp46sxqAN3ZfQVue53E75VZAV3eblTYfdGQtQGQzY gMEwjjngg70bOmQ6QXi4MoUT0901jncTFAP4ISgpMIUZjP+0cdAP1VijtddFtd99ddTTHYWr +rbsXSuJU5d7TEDZABd4mBx1SU/05bomYCPNIrqlcJE6UcQlDVBmAl23hV78bdv87eDp3c1y WVoMkAcBexAo4b01KFixBJJ3+I/yXZYmmYkE2AfggI7EABIomQp2015eis4gVV4NDoIhKNoP ftt8TdpGkGA7HAmnMBdzoRU7GMExCYB0+rKT40vTCTurgLTM/QK2M4UFCJwP8CScyAAdxIKm aCin2IIqkDtTUA9ciOIfTl7XU1sRDU0PntP9/Vh+jbxg+clgHKIWDLFmI4PNFIECWMIv/QM1 zUVXfAwDIVO84FCDStvlvV8LFWL/XjXdPv7UcFXPskCYe4y0njtbS3Y9oa2B5KTeDHjeIQbW by1QVQZlgJ0WipLGHJtFDzCtqimwishgPd5gTRbmYI3lkA3hWs6fOHHFF+zTNHlGJKkKXzgy XM3VS97kVBzdbAZh6bWCt2hMZaYBVh1boaioHAtIQnFVh3kCwhxQWg4doiXVI8bkYiai1nDc RSoz8Mhc7aWKtiiAR26GYoWxC4AQBaANdK62W5CEanZnei1mIu3YiEZmb85AMVAPqUOyTz6B WTMw/sHLdepIndG4rcxa10mCOinhD1BKcoJoI+ZYDqZnbubkcQ43MpnEh/UJyEtm2RHfQUQK oZQfE9Rp/1TmJwtIT2u+5lSuZ4dQzhB4SZjuYz5GATG5JV1KKhjm3IWgPzWg2m82OGuA2e3r aRP4SxpWHakoDvZ1hVsQ5EPFZooW1YmW6j1GYm2qhW66HuA7Lg8s60nYOZ9gNdnANM0sGHjO vb+7Y2Mm5rp+zuhdo3hIqLCI5N31DFWk43C2oQWmiG74AkAFGPoNYrnOASKeZ/011WPGKZTp A57a2xrGbPcEAOsp3ra4FM0OQ/wE0vp1bFjeZtLOZMiWpogxJicQvu1ginQsAHjESIhs7nnU SOcWYyYSbTtuauRUGzl9bFlW7RAgHUS2Iofqa7/ayHWMbnWsyMM4AGCwSAdYgP+meG92DIby NkcmumAMPkbEpoTEhOpXlmiqvuuW2yEf66kpSVUybSjmOAMyBYy/iBTX4mi4NrOXnuluZtsK 7227DoL2QgUxLHD84wF9BDA12KCIRWQSqGTBpi/BSHCzG5G5wK/g5G0Mz+QLR+3rvvG73Or5 dRdC6d4JgBAwdp5u+zDq5kU0KGUM0JHC4wX/fuZN0++ZHNX+pungBnDhKTIJGdJaVUSSdOUk wVtU7j7QMC19aQOWwFmjCuYM12a6pvEcT20K545l5YWCPhwVeGtnbgY9xeXQGDK7GwBqDgvP OMqv/uuCWuyabuw3n+oAl3OsSYTwxSuK+3EaSHHXYWb/Sk1sn1znJ7nVnPhlNc9vHPdtfVoS J5/rK+fuUdcBaOW9UkqO7xFzmYBcuYKfgIQ0c0MsC5txOGdeN/d1Rhd25Iog7aBhulqSmPqN E0+ZgyDockYH/SpqS6cJwHmCF34C/Y5w8yP1/170YAd3NncrS8WCM5AESNPiaByAKnvrSwdm j7QDkAz03fvcHxgtZBc9Xh9tcS/tpz71Ko9pizbMI3AgqFEiha0bPmIASRky+VjZWIEnWsGT KPfjskr0irbxRu/27bbjIPT4CgjCMPh4WyP5kTd5kEd5Jj35kkd5YcuMqcTew1LZy4CQ7xrK i1jzYS91mQ53DV91cR5WEhYD/9gGYqYGeBowbSoH7oAXbqDPYJa5nm0HjZzv+WH+Fl9V9Th3 +gl1zUtpvmk38ms9+niGzn9feqd+y60HZXcSufuWJarXeIzPY363ckdXe6eXen237rH3EmCP +7Ov+7uv5bxnQVYH/L4v+23l+50XeMF/dDwifBVffCn3e58/fLR3fLyXAkceU8hIHA34HLoo eJfu9b//dZ43fZ23/MzH07nKQkG1Vdhw0c0l/X1X/TZPfOedfNxvfNb3JT6XxJzmgV3O1OBh 4W3M2Lim+1XObtL9+az3fXGa1Fd88tGI5py7AMpw9drf+8unfNRf/dtn7Oh3K3LGx3jnBuRo q3QuFv+pFSYyI5R2yHM4+juKd8wpN/vlx/zuJn8IGHLSai/OevOZxIAEQzCSEvgA6AR2nLBa iCsLSCU4Of5uri8oHBKLLGNxhxQqW5dAc+mLSpHU6vKK3XK73i/Y50LgyLlKE7jUXWg8yuLz rqrD9rsTj9ZPqHUJFF+f4IYWoYXhoeIiY+OAgEAAJADkAkVUQEEeXcUIZY4M4GPUDdafI6pG qGDiF9XqREDCYSthreJtqu4ur4+MwUWd2mkRQ2RCgoPCAeSsxEdkCdBkAg2sEXGvbnZY7pbf k/f3rjhfuTZ6uvqjxIHEA2kXAYBm0bzlFve6or6r7ZmFQP90ncNTcN+hAwH/yAAbACDANQ4P FlpYwFBDAQfuELaAFEmCgwcU+nGEUTJVxDsHjbx64owVOW0rT+IpUMcEkY8jSQogQPPCSxQe hxItavQo0qRKlyb92Yhkl5lEwAWUOjVmL6tOvTDrZEQSBQJgYfjcmgGq2U1p+aAdB3NkOFpY eWldW6UrBRMOJM16yEZSAwFBaaQJDEhSjxJ7H/l0oNHuEcg/JOtJaafulAoRZcklKJNyI7yx BjjwmWCFkhjsBogc7aJAAAUgPrEjoGSHAAMJcEJu+8IAmRIlZhGIVkZECTu+QQ9ZLgXzC6qd oEefa525INGiivegUQLBrFMj2IAQbWAsGxSOmTvv/yCg3gHcEha4eO+wJ5j22N3jGqg2FnUd BMjSZ/sRUpxXA9gEQnJwBaQgCDvgpRoQDuAnmH6u8EXCDVBlqIEAGx022iMbWZifgV9Y1o1/ EmwWlB4DJlFgimzVA9IJpI03AQ7iCSWBTaTZ4NAzIAjQAIIEjdAVky98eBYDEuDAjBKtCRDl Iz148WSNALVokJd5yajBmEOUOWOXld2wmwuS4GUhJPdpOQBw+Ik1gEKCcUdJAMxklAB945Wi CwAnJvlIegshcONqW+6lEzOqqbchimma0t9b/wFy5gWcZpaVpXzcU8GceCJRgCaaAFNqLwaA EGSSJqyZmoNbYjknJbS6Ef8Gl6GuCIanl2jmUmepBBvEsaEqG4QACuBZXh0IrNDTorV2ESIF QdmH7YmVLosNpuaECWCxqCRb3bfpouKdhQsJVqukmpqCJY552PcIb1z0aum+n4prLblfNnKu gOoa3IgzItaK2yr9SmBArjcilownkWwESVn6HjzEr/5k6iKxAjNCMAckb3xyp330MAwfzi4A AD6COFzjzCV/KR7BJqcMKsqHQHJQAQCwuhWc5A0wD8Ap1mzg0mTeHJfIi+icwdQGdwziALsZ iIDCjXbZNHZXR/Xli+U6UvXOPbOFH8crK8sU3HHLPbdSavNntkrjbor3yDTaXdO7QjQINi+E b/P/92R8s5g0CTlfZyziMg9hhtdfh2o4ZWJzcW5LAcEIpmc8Rw66EK9insrpjqRu1+r1/ivv WB+f7ffoXdhUTRHgoS35F7shV8J5ZIglggOfX1v7BZq79TrInise7uPIS1/yhoAFjjUYu7IT ZAj1gd16WuBzrnfjz5sv9fTpC7hkfe+YlH0deGl//ZbqRyZ73owLhH/fotv/vwUK1T4nhWFX MpDfGL73P+VhYXwUKFvUoBc6ABaBbnDjiKsgFJmfuQgBDohZ07wzFgR6kFPgM4v4nlaV8/Fv dhSsYP0Q0qxnHUFWPdpgAWvQjgRm6Q4n3EoKZYczFjJvgi8sXQz3wa41/w1KSgBIErYqxwXt 7VBK9cnYF37oFAZWwYETgGALJQi5IzYniftIGAYGeK+m0WYC3KONHHj1vyAWcYgRJOIdyZhG M4YvL4daWnGulyd6NAMkN2jN8exHxxiRb39FHBjt9Pg+jdlFCTcqnrz2o8WfcPE5ZAtZGPEY SklaYGabfI5HbtOwy81RjJdp5EH8chUj0pKU2KMkaFh1Sj3ssiSLJN39AhaEjIQgXwWrpbls ScBEfs2CznwmND2yQFcu7oug9AFF0DRGuijzbrikGSsVSU1gwVJwkAgAfT5gzAzQIJrubMY7 4wmJoXWTfGvglxeEJpyFVIN4WvIdFIzHiXp6Yf+dYTBoJ5ZDOdUwagMI7dnuwvlNpWVRS0Yy gXes+CM+Sk+eHv1o0waHRW+O7qEEBWmc0lSzJqJgTu+an0CR0Es89OQG6MSQSTPJnhwchQgi lYACxtJOn1ACYzNFx1EJCpqVymBlczrRrqiYj8u5o1AoWEFDz4JPxjlnoSLqCsRYoBcp/i2p SiVH9Y5Evz1uKRr1wRUIaFBCb33NJxMaaeIsx9UhBFIBNmnCoe5npI6eNXKLmRBQJ6mvpraU Am5wA0snmiI5lAYFZckIRjF2H2mqlHz9CixE3Lgj5Jm1sCjpFhAkoYQFlACEFZ2Derpn2SyG CmJYjGIx6TSkzG5VXp//BQIx7UVY09otg9zTYYlWM40swiJeKYXjSkNVNAE84K+xyJcauqVX 33IBLwpQQlloRVri2m2GiHXsEZbbBWhkDBrSMEEgnWEhBCByoGkaQQIIENgRxSIUQSstM4Mp YCME1XuQcJbWyFpe8qptieBpYpziGDgABzhF2gXA5xqkoHhQeKp71UPGOowKES9CIcQTmyzX FQC8iqBrGKAPFtAYjNjUpx4ktm+X2onJGfTguxIIr4J3+mFC3JgRRT7EcftBTBGgLlr3Oqap wqAQ5epUyCejj4FnqLUjg2vIvKsdl7MzDXrGgsyKoMQq3DSEFX9BWqSREjIsKlHklSXMOfEs /z9Qquc9I6V2olHNowDRIR2DRBKasJ4xbBMDaPQFCiAojjQSg5hC/0EWqQ2MiSb9AQ++60S5 GgHxdhColHIsKAdQmJ3vLM7OepnBpGSGfuOkBCaVJwRuS28LZAUMBNVnFruajazeTMO8PMIZ RnJHNt9VCiiiQBNQBPUO8GoKPlNbbnOsNrbrthOjuLqbXQmFTZNzqMG14IYouNiPgUADnyQ7 ueUWjlc+wRlsRfFE2GI2Y0jTAzlkM3tmzifnOtntgRO8xMKowLhH8MfR5ns1CAoEfshNv2zI akLuYNsn7KRGn+gkSBr+wsfx4EiD5LTgJj85koXRpmHberZUPvcRuv9S45azY1cj6Fa+TEAJ G2tCJw7okTvOeyXZOmQHlANDyO/AGUEkGOVOf3pCJAGAhghFNRsKpCWMkQwcUGJKH0Ezh0ZR VETdZ1rzrPoqwM4OiEWi5xCRUCQmIoCXqcYaiEIQlmNW0JJvYeQq4TvUAy94L8R0WHwdgLMy AKPCqyKrHCAA47mQdDv4/TKAHzzmM695DUz+oJHnQtM3L/rRkz4gl5dC7Hh5+tKzvvWuProe uEaIKbu+9rZHebZzf5R/3773pAcOchwgcCLAmGn84r3vWQ98KCAfD75bhVTdEzPm5+YkbKOU BaRtBQy4+CepLl3zk196+6S+EdFHi4n6qyP/muC2jfbsApvXsrS9/BwnUIDCPBbSp3ZAIfF0 CL/4jV4UkZr5/QFUxN9IOJ4ModoIRBqHhFag5YVaHQCbKIEBCN8xjIViWNpi+MUOWA9s3B9S 5RPL4EuuFVtedB82AGAAbt4aYWBgNIZ2OaCOvEagYdYYQIGoRQIBzo+jURpq1NRs6MCKdRoR Fod8gYWrSEKEYN8i4BZphIgazVbIucAFXtVqCB8L2AaO2IePPcK0AMltfMEFgsWo8cSWMAoA 5MkeuF+ARFYL3l4MBBIOydZDsMCsDdabuUC01Qe0HY1jXRELAMCQPAIwJMca1ZmNNUYVedAA LEBlnYbqoJoFoocE/5ZKDRhHeEhJsI1CC/iECIFHo6RHFrHbH2rf++XOKaxV4t2LKOoLC8Yh 5oVIAogID7EAFIYbqEmK3elbkZAAq/yaEzjGd/QcJzYc2yQjx/0OMKZbLG4Jqk1LGK6GHDCZ g4QcIm6ChXCcKYbJNh5UKWRTfJTCgrjUtfxBcSggam3JM8pi4EHhasSOkWhLAD1XnHQcgxiT G/xRwz1iPI5HnQXkbN0ETizIiNELG2jhy40BJgKVujkEBcKFDMjB0DWKuU1kzVRjA2KUWKGA /zkMKU5AOmoVbLCjO/rekx2BbDiBzUWhKMgKAaxMTNaA0bEKbUwY0U3daphBRQ7gxVzcyv9R jl6sHhawHf1Jyp58xIGd0yR80aAUTdWxASXU4ntgkt1BZdcdTVV+Xhm1HOwRiVo4TPSB4VlU nhTA4Un+Hp+ISFZ2j01YydkhCoVYGr5IWE09YiWERSF9wM8p5TmVHdlZQ6DcB9zJSlPmpZtQ GKooSAA9zAaw5dEcgFU5Jpm52KrwCg/GQF6yhk64TpCtYLbMQx00gU204w+YZlqOHiwsHhy8 RByEBVeKZAUUgP8tQUyhJvs1QQBQnTr8QhrZWCpiQ0/sRlOtiSMyzv+lpnIuZ0CcE2+mBTqt hi2CgQrgFSESGW4yp3Zup7EYQEkOBU58H7NkJ3eWp3nywcuo4ID/YQdanmfpJYc62cVXntFj SN1aBA15ytTxuaftWWGPRJSqFdlx0oO7AVHWEGU+6J6CekR+8id5pWQIyN96tsofAGjbTGjs NWgHyF52IKiDElyIrIdLmoWExebIEGL1kZ1ZkFsjdB7ScY6HfqirSdhGuJ/3YeguYEscrd9W LJQjzKcdTKY5xKiMMtgA4eg6HOk6UAQX/hiRPoUGPcWCLqiGFilBeRDuCMaTNgJrRSdHCMYO FArupIXujNh+WilxFd87uGi3TcSWHpF4ikGVoiniUMGO8tSU6l4q3GlH5Gnuqc6Z0mm3cU8p 9VYjECpyWtkTVsHzPUyLKSSdiMBgzMde/0AEvK3BnArqfjyKaEbKze1ARuBAtywhASbqUm0B DXhq1vSEhWBYIZHqKhoqP2CBVI2AbAQFbxgQVvHhWWaqpoIGJmUcrXCPNQ6QjVYZZfRLelCX CRqiVq7GsX5msi5BGYLAGZIUEtSqUFAdb7QqIA6besrprw5XC5jIorRJsO1KkhRPGsjqGmSa u7kAEsorHyYDkvbGGnSjI6KiqQaBtobAjuIEhqWedmDquI5XYrGNCBBrutJrbrUbq5lCWTBZ MqYbbSAIk1FEnC7TEkyaOM5XH+zfvW7oTYgCzgnXBBSsTPnqwbLOGK6RAayr28RRkFRWk24s tq4Bz8XrDhkDkP9EiE9wIc4qFhFoJAlwpHKNVK/8q2HmyJ9QScruS3u2LMp4hCVAQnzIijS8 B9jNl4XYRNAqKUUlaNY+S8WsAFh47XtonLRKxocwJM1Zk23ASK+UnxKEZzaVBjK0kcqCJtWO zkscCcw8kD9aQAGAUNiOrITmQwMMbgcc7ic+69DmVQVlZlHhwwN8xM+hoOJuQOamoCiUW+hi YZQm5992VLg6FA6w6HbRQepy3uoyHDgtgW8GQ3LxIxbwBaRFKts4xHjExsNMwnnEwHNWEMue rl1AWm0ikXq17hIoL7iIrfEpHQnMQnwgK8f8yvL60PEiL8qYY8TugpyFb1R4Z7CV4Nf/dK/3 Lhj59sLk3pIXpCd69avbqu/69oyf6qk65O+fSin/Vpv93i92qClrdN77apUjuKntti8hAGkB vW53vakAf4udEsMBs5Uj8GnnopAjsGlBwegE2xKi0i++osIIb7CBtqgEd4BZAssKh/BPcCol qOp6hOqIwioGz24VpOpffoCiueq74HChMrAgOHD2QPAW0B4Mp0uwGsmw5iCu3UcOj60ppIZI 6ET18ZqLxCoRr83/UlsAL3Hh5IC5cg+5qWsmkjDr6Au8DmC6xVGStNEFL7CRBaoYv80EOIvC ZgIU15zDCpa7ytTEAuQRFMfFNu8cD3Edx5j+CUc1KIZj7YW0/wxPQF1LGN8x6rysjcUsH87s azRv25awKeysGz+Lz5YuKFPxoqLqci3buzTIYvyasl4yJo9YXmLtYuALE/5XEHKasanx4k5b 2TLD2Yad2v4yCjvFJvWLVA0KZL3ELraAiZ5mLX9L4Dau3q2A3rnRNqOvDtMBNr8A5MJLIAdB teIlE+ZstiKXM8eVpIhEVM1yNRsMPHblpDjvu95TMt+oIB9tCESbOhuBCNVHaazbFivsDYho PtDyPKMC9BbBVObaC7vvFjw0EUR0KK8x6oVjQ5KGvWKvv7Izhl2Dt0JWlU5tQ8+RCnyxniFN OkADS6PUNFuA0X4cWGTs+NKqMJRKe/+5s8uZAkOnNHbkcoq0cDKliVXA7dHJh8226xbYaLwA MnTBolCTElEbiFG7UJckteXmZUQaSeLu8wXElwdoVkc8UU8siHwdkulWNRmF3mUMXxEsHTp4 0Sh1QO2WmzXYbCoLgktzr1vr0VVTHsFkNSTdtReUCTLYBANQhIYlMmwFNgUN9kEVtoXuAWKP jQ/hIjCHT1BLtl3AtecdAl1H0iuJ0g4HZ/2C9gtR9ouS9mULS2ZvDqCq1Geztlm4NshZtjrY 9SMRWUzv2W3jtlOINtLNdMciNyPN9vIsghG3GRJjgRITd/ro9gfDdm/nkccwwnMDnC1MNHUb iHXDH2+ng2//L7eRBbeeDXd4l4Rxg5xyf0V8589v0/cqp297Vzd4Q40gGHb/1PdpLzJ+57f0 jLfklXdda3di1/aAE3jtvHdBzbdPSXg1oTdzcxQjgwdyBJ8z3F9Bv5aD146B9x2Cm3aFAzgv 5ZCwlcJ5NKuLU3WIj86I526J+w8woXgHnPO1Eu0U1VoPIZ7dgniMIw6Ewx+FC86Rb7eF4zhZ +PO+BvQOD4NFwcj2tvWQ282MV4F/H3h2X3gXaTlHh4k3dwEVDcpI0hR7X3lW7PcKEcKWj5OS M/kG1DRvxE7qhZCUp5sCWrKa/02RS16SY1Oga7acEzoMeaWWyMcedrYQlLlFybW4//a52nSm 0rVO+XGTl3uSTHX13OHJJn41oweB+8WLVMkISkv6shxAAHNoEQ+65Lm5IjxpXreUNdxARon1 BpD1qvauXFXDmJw6qgOR3o1lVKq3R1UNsRs7SoXBYr8H5NnEdDrCdfJKmgc7bb8fZI8E2lhw OX/TmDNNtVu7HE0x07i6Pau2KN83zYS7uHcCYtiEAD0atrjBBxjbD5K7JmGBIcOJVoqArA1K JGgXumt0eiu7R7F7u7tIsN1kj9TZQDo8vrMnKzfWr50vxCvyNytCd3eBkMYImyd8TihMNlEk xF+ITmU7SL/AyDPIyqBbX+O6L3XwxzsP0808yDMLrpqAzP+V/Km9PMx/ad/pfD66nB4qGMr/ PBJ4MHl/982Lb5s8AOXcYU/CHE56ECVQ3dFnNAv3wB16FS7+stWnaNZvktJzOSvYfNM7ydnR wGkkEEREwhKual8GgM8S6tizctvjJXXZRMXklw54R91Lb76rsJubuwb8edozXX9FZMruecYg CO7i81esYWw+vrwj/T6QPdoLk8cnvjZsfAbQWsoHsxSAPvdBC+Ynqcy7OQh7/i5khAPsuUMx CLNqfR9VAezLPufR/hV3ux6Ufd8ZvuJtvusLeMZTdBdnKCF0PMkVfzMZvDwlKfRHv/9Ovzsh vPNnf47asfZ3f9Vyv/eHv7pkpP7/fZBD/E6yXapJij/7b4WOZyaUL8Gv4Yac+Xyvtj/+s5++ AjSPQ8CQk1ZbkZBFC0QTTfqu0ry8U13Z1n3hWJ7p2r7xXN/53v+BwV8gFSCxRL2MZNEBjCQC keKXEl6xWe2W2/V+wWFxODRABAYB9MQROEySg/guQwg9peqk1AG0jgEDBQcJCw0PEQlFED4Y 4QgoiCjmdDIWnqIwjwZCKHP+EkNFR0lLTU9RZfKkAKQWBggcEtjkJn+WJjdn4dZ4QFOBg4WH iYuNWTANKhw+BAgWZuM8cVorBDAlEo4Aend+j8HDxcfJy7UE3gikGAV6p23UBXY5pSCz27Xf bb7N+/3//wEGDBdg1gEHBxJweBMFjLIBAOz54CeQYkWLFzFy6WALTr+JGUGGFDmSJIYTUlCm VLmSZUuXL2HGbLmpZE2bN3FS1FfsY06fP4EGDbWTWE+hR5EmVerHI82lT6FGlYoEiAFGBC0k aOMAgFMdRqeGFTu2n4E2GpoQIVoriDMLDpJUq+KVbF27d4e5VWOmT8STQtBVULfMD128hxEn PkTkgxEXa2sEntRtAJW5ijFn1kxGw5k03dosXNex7UI42K6A3byadesYixodcQvFGmDTmc4Z dr2bd29r7Vi5giVrg5TapSmY7ZNFtW/nzzEnW9ZsFy6GbR1yKsB2QoDsvnRDF/8/fnPgwSPc VW3VLgBcCQzwaf0Onnx9+6uxGpxAIP0XAgC2ayu8+wgsMKqNAABggW4gC6Y5AyGM8KdtbuOO nAclzFBDoGTq0MMPQXxpwA1JLNGmBoHB0MQVWdSpqRZhjDEkFFNRUcYbcRSGxhesOkONvbLZ qqvCcizSSHF2hEGAAAdYzj0J5JJoxCOprLKqswZIy7gVknxBsspgmWM5Ka0s00ws9EIDgb6o aosBKKOgzDIyz6zTTh4YS2OT0CTg8zo/2pBEDtQAm/LOQxGtoAzPgJQjotlI8+PNh3BjztBE Mb0TNjNIiGUXT4/zo0IHxkzt0kxRLXOVa4RjRg6DqIv/tIrsFmimAu8uS1XXVKWbJB0pfpWV BwPWU+NJ+AiSj8hdmW02jYKYgVbYLf5jMldnsUV1o1qkeTHbbzHdhKYuS7ER3HOtDFHdddll 6VR04T3SES0AKPWKNuLNF9NGscBKiwQo01fgMvm9or0t8B1YYYIDDuJgLRJeWGIjCxbC3ywA nljjHCt22F4hIt5YZBY7BuLhLEIeWeUNSx5iHiwyXllmDVv2QVDmGp5Z5/pq7uFimHPeWejn esbz4yBSHlpp54re4WQskl5aatea1uHnK2KeWmuqg7b5aCCi3lrsxKrO4el7ux5bbbLKxuFq IbJeW+672r7hbJDTnlvvpebN/6JehPPeW3Ch2i3c8A/fHVzxksglxdzFIQep8VEej9zyiiYX pfLLOf8n86ES71x0j7wd3fRizJJEy7U+T2Tz02EHJE2+YGmznNdjzz2MPB1roXVEcNdd+H87 Q6NRuTiwQi0BXrkw9OGhP2eE2DhaQ4MH8PjamOCj776HVddr3kIL2zGHe+/Rz6HXUPvk6Pbn 04+fOff/dF7++w3ZQwLTfj/kfPxPoA41kOAARgjAAyqjBmywZw0LCBQ39lJAH7VnFg/oHQVq hYD5AOwMxJkAB38UAPGlQUi7kKAGJSDA3v3IR8QB4Y9e0aMfqYCB2TAgDCXwIwg6YIRLaUU0 ULKGm//ZD4BB4AAT4sK8CXjmTyJI0ACO2KTiTOABYyrfJKaBiy2NIAkIWOARIhZFKIqgCe2T wwcMsAbreBEO22mFX9zXxS5iYjlLegih6qKAw+2RjywJXBFp0Khu3CwJZaCNPQ4ggoUkkgJz GiJ/sriHeVhnAA75xZgYmcNerEE0BORicuCwkCcpqotLjINDRLMQOAIScolcDgInM74tzWl/ c8ikGSiQASs2IJKfNOUSJaDHE9zSlRKAJRxossZJTGois/wlbXzFStMl8hooCAAe+WCBW9bS R3FAgwgKEABhXiADa7JXBvSgxjgAzF/bpCY2k8meK0bhLC+zQDZNmc57Vkj/mpxrxccoCYIt 1rICt9zEN/uggW3msgPxBKYZ5mCdhT5EAPb6hTI7EtALdOKZuLQGP/u5uJfZkaGKiuUEFrrQ AKHhiH2YqC8hBdFGRsEvEi3kJKx10TjMKTCjNCkvfBnMj4aUc6USAC0pqqhtdEOMU6RFDqMA zmnIxZBQisNyhhglMRqVltWkQJSkGIUAzRMES7UqBSxqLaIujjFaoUw8XhYCglCygNdAJREC ZRyruIU/A6grAOYD1z6lIB4/mmc5E9AKThIBsGnwgFsFCqnC6pNY7RBNTOkxVxFMlgi9qKwb 1ho5KlyihyZwCERIcYlVzpS0VzjtakMbW9nOlra1/7XtbXGbW93ulre99S2MQOjBFrgKafD7 7XFfoMUGIQC2lVhtc+cmwfbg0T/sMe4NlNg968hDcxZToLFK+4KeEdcF0gXpCdpG3uGclxMG DBtaU8CN/m0higP9QhTLWLsSsBcHX7On6HBhnbPQsV7t4YAa29MXeW7iwMbBUp8K7IADQxFL eSiAA92zuiYN0QV1dCN1O5yz6kC3BE1tgQGqygLmWgO6uAgBe0WggT4w8RS3/J8MBFm/SJDY B30tRXvaQ4DrUqAAB6FBfhFTTlJN4Im1YOIi0HCe8mkRA30wC0GBBGW29KG+OZxxHx4gAu0N MwqLrAGNKeDjGbx0BeehAf9mMSBHEyThgqmwsXyX0MEx1ZPCTyqwBv7cJyJsJ5FyRWlFhWrh Kkrin17UgAKWXOQhFrp8pBKBWRQLgBDM4s9hRrR8XSoPsophnqMmM5d4fIKv8TcpS/gDqQb4 mevshbhl6N0cbj1BWbNlLxnAhJRZqCcugvgxC9EwllSoPCDvup7JC8CEzZDgMOmBJi89S4Aw vNkYNyZPn2kDtI3lliL7VKZ96kOkmZFGfGTg03h1LC//O4hEEiAefkVLJivN6W0dTMxb5k6M n2Ctdzp1diRV5LYsigkR8BvCNPW3IyCNm2qqFQwcHvOOkZBqGARA40HRoj0gpQxAC/Gbazhi lm//Zb17PoTkVtXAYFK8a4o27ktrqszsqByL9tEaDYycl2eAXW5bUkJ/bFnCYJYjl5c7Kdq7 dsvCS4VOtRC06dyBeB3xYMxEMBIb56n1tngRaymM1eDIdFQJ/hmmSKRgNtqGKDZBHmwtn33s moToAKPRcTTZc7SWHmy9G50BXkLi2g7vjgB4iRB3V5Ir+BDUn0OAL1C/e0nG+iNGqLoIJyIQ tUtshBNnTIKIin7hUKppY2gqZUyoiQTWi7fvTFNn3oment3pRb00ACRak8DWtKfARPfgaDgo gJoVUHft7S6Zpwf7mZFXu9Ntf3cjRGMUCw36GC0U87tzEQFiLB9mR2qA/0wu6psgT6ET7euW mO9lD/ZAp6wLBmcwqIPiRo+xMtg/1kjFGI6XxvqWFe46Emo7Im5Q2KLIzAgnBKtJ2C4P6AEl gOgV6gEtjKMVsKEJsgslnqATpACI5IAgYqwPOLCShAMfaC721oD8oO/vZM0ANODkWu6KYFDH FipKPGC7iO/BDDAJ4AIS2I+ZDsDN4mwCmkD85o7OjIcy5usHTCyTcOFvEE2KvEpNGIL22q7M CKMjpGx65ICZ7iENomCkRGP1HgIhoon2bg2YvmQM6M8CtksC0ePs/s3sMAv98M7oVE4ODA4S pA4BqA/5oKIALAMNEoAA4MMC7EAG5oEQDXEOoP+hBF7vESODSeZlUyqRUuiBU+SAChipdxzh CUNPx5qq/K5DfxipfK6JITBhUZrBwwwQDJksiZ6PuLroA8YJl5awB/7KIRSACHZhAuFAOEZQ DjiIGB0DPrTiA4pp7fwwYRBtVYSsmvIgAw4sxZZxGFMi1L6pGAWIAY1jGQPBq9YODuBQ1q7w +T5QDkmjYNgvUt5vduinB6cikRaiAIasoCTDHsXgs94AAyUQOFgF0OQhkYrMA9EJLrrv+5QI GDGQorChrvKqD5CRuKjxqBxrARIJBB3NDZaEOKQAgSqK3R4wDiar7j5QLeyRsFoFJSjqHsUg EUHgp7KBSRLiq1RgtBT/5ALWh8kqQBJPYB6egAAO4G9AoP78ChECKqFIY1MEwAsNL8YqZApK CQDMkDSs0ClxEU4ycSpwz9TUBy68khB2cgKUwStMKIBezwXwiNigaDu2oyzRbgCOiRNe4AnC S5tKJArTYD6CAbFsDqI4gPOksTOuIQRIYCKVsR3mpBVIACxjDCX6wAKN8fOewDFbMkwKErmG Ri1wBRyazCZlgC0vwDSCcijtpSZH0wLgUjNZcyjGpDNbs0iIg7GKoQCGhBiMgArsaws4ky+T iyqRYi8MbRi8iNUsJ8ygZDvWMEXaKy92QU1yUQscIzrH4dJaURimU3co4eJG4Taps1/eKi0p /2cERHMkSOqhHIQ8Y2dN1EHhvjMLUM5BovEexLO7ZM4n0GHJGDAv7A520lDQiNP3mHPDpsUU NuUnDEkywAoVDvR0uiyFLg94sC8902CBdEQ5Cad+3hMwMDR3uEKc6kUbiqEZh6EJtOKMgFMY ZMEl+2FNRFQeIvQQVjQ2aTQpsusx+ihH+ahGZQuTfId06kJHhdRwomdIjXRdfEbjNpTU7GIJ lU5AAa5SvkdHjrRKO4RDgPQGQuA/KkqERC1nljQMwlQglhAXZhCqzuj8qkBHeKAQE8QrvMgP Z8FNP/MrKIIIeOnP9GFMv+B3nm6sAq4E+NQLBtVzlICMFCoKYcmrdv/zE9h0B7xPFpfSjeTv zTBnidhkzrIUuyCh7exhQUSIfqqzSQ/VDrxq4KLK15iCQnVgm57kPB8iGkSpfwp1DOgMjESU fUb1EzoV5MyPfDZVLMqUedYyCqVxUiTiUVt1DpxhQbOkC6OARWuVSfuTu4guWCPjDZoSC9mi W8yHVHkgoEZKOT9A++zUC2JhyQSPux6DBxZKHsgNDvjMGy6VC41uXLB1zabsGppABGNsHqZV eoK0BxaUq14xXh2VUMOQLeaSS9yVWbXiawhzSgWCMbOkBPuzQMFhSeuLSQJ2fgZ2BxYwhx4L XzoB5G5sfOATX5lADe5SVG9gm8rAWbEQYSP/wzzjEGbDIUxjTGejykqB1iUKqm4uYklx8mXX tAtORuSW0mEhVRp+UReiYaxilIZwVg7U6mPRJAvkdBPeQWsB4y04CT/z9QqQ06++qWmttlUZ oz3WsB4A5gkU67L07i9EAgGv9Vuz4ACi8iX0NpeMp25d5G+5ACwjMwUStD4HFXsEdwbAdhCo K2gltyXEVFNv54OAQ9O61ETDsmgn93NZ8r74qWPX9kKwlHD3AWlRwHJNlwT7pBkAFYr0pmdp CHQ/904R7xrOYk/LVgZ81HZW7nKbhAQ8w1MFp2udVgcKkdMS5D+GJAHiDXoplkwxVb8EtXcD SUlZd1enkBTlEFRV/1do+BZ4P2E7XPGJ7IsapzcgbjV5W1dLm3Vzv/R66bd1BcURtvVVSlF0 ljAwUimFHHLtjPM16nXXetETHrctvqJTY9cov/Zv18EVfK1f93dn0nXGcrc+dRUH3vY2QLA7 Em99AaIWD211UTcyetXwJG2DNXZ7YtI3v5AYd+ZfGdZLvuc21nAbGWI5OZgiLNYf1TR4hZeD U1gd0UxlW5gnXoB0Z6bOuGOF3fcTcNiDkworeBi7SEIIk1iJpRha9TdjdQyLbFdylSSMR2Zp LeSI6/crpjgSygwqRTgjtNiMNzYHMvLtKBiMkZiOXTi5oJdFmeVsC8hCmqZ/c8pa1qAVxv/K KG92JF4qgVcVPFmYj7n4BcZXaAz3MvV4jW+AHytpbq0qAD2ZXkXigBt2j4/hL6+gb+5BaId4 cQrgvAr5hE9kjCWXG7CgIdFqe5FkaKtWa1iZl3cWKH7ZFIhWB7QHkpN1GcZ2cXS5dm0ZaIGC O4fhmHMgmU+YURp3cPr3EXLJMszVF6ZZI7jAmvtLmOv4Hhgr8rx0OE2nfxcCrPZMHJPWJ6h5 B8oTT4r5nDl5mF13eLEWNxg5cuC5jUZgFzSNw+LYJu75XKVzn28Am4WXIr13NqDYgkkFg+HN hn3BNF5VbSM5Jxo6YR8aDCS6dbtXDiFFjU/hhUJ1NK1ZhigIx6r/Vr12wKYp1lq1rl072hbC aQNkARyX2Z65IJ+dBqJt4KR39X6bAQijjzi1bRreCwnILgamugRWbL/ObLU0uAWcmAelAIZ9 NlsnY8/sILG+U5lllJx5E6lr4GuMIJqtFGA9QIL5VS/NWRAoSS9zCX6+BFZVzK0xjgfUzAbQ eBGCCp33wVo44AgYxKhVYZy3YFDzOqlL4G56eAuCOQHpUqw3GRUoSS4ejBHgAoMrQz+5Yius AVkpcOoejBueZC8UGS44StDsSIAsqK4FMmIoDQ100Bk84NnKR9I6ANHGLVENTQcvQJDT9ve4 s39G+TpcUJwkwAXpmZSJegsg22wEewbg/7qrY2C73aZhRtpehYGSmoABlsPnto0tOjEPJ2Er usjK1ntbuMsxloMDXsE9is4z8E05s5aOCCowiLJ42+cSSegV+03Vsslit5iSi0KyBbakvwCu y/tHrclmyBsGnrkvSbKhZqh3BsPt4nOZzkrYzmiGuIgPR8nNwK4Iooz/1PEpdc0tMqnXUvok p9P9rrvEZLmr1Vqcf+LC96Gcu9t3L5vIo5gNjjwSNtwiKEkScI2TtmULcXmoomoFuyOh+LCc gngT9yAJn+/p+u9XMbdJ7AFI1kPWYg5S1nwG2Eh2T0KurVTC/cbITfqywRsGQCxurObJKyJK lK70VshWtrLz7v+JtalHD0eAdNmIr/TnHB0B37QVWbl1S9CAWE4PFp2hEslQMlwvNFNiyW3A TRHgDRIEIt4UNEMaJ5TcUts6zy8As7H4Aq56Bjrm1YVhsnxKAykKYOqoHeogHjqQLP/JbT8A iPVQGhuvuB2LudrhPBDzYitvSSZMVWvJiljBG8Pa0z6wDLpxBDmgjj44NXigvqzAjj6TXetZ pNmawr3AwoeamTXc1m/CnnKSJ7uDExpREdMMTC5gMAhFvH9y3wtRi31SJntyz4t8B2xM9FSJ i9K6ycdB10MTzytcz32gzyn+sy0+JOhxAwBZm8J0lDTNQB/2NLi1IwDbG0Y+HD6+jGP/PeNn PeaFmN59BtChAvdwmgcOeJtjgN2E6wouGKI2mqeXld62aA1FlNY5+OXBweaRHj47vsOSfN7R qupzfSwcwZ1TYbMFVqflkqOXFRNDyVfQelncXbsxPt41nmAhUet1/kCq+zprBMKHgGUfwovK c74e+TZkIQHumE7WfsKpXtYtQKEz+57k3t6nArChfmtR2WPIcg4nH+9hwMTE6qm+nD6yWwsi /7K7G8mG6+0xpvHfIizy00mCvAUStwuY+99mjNRpYBeN3bIYMPZM0uWHvB8qe5etVwU4UCUA ZnJBUEd1LvWlIkHjufXbZFoz2cEZnfa3J/SLYfjpXEiTH7tL//dWpJ4Fbj2yHV8qaBfz88f8 fSCW7Z2v+3ljrT/Cadm7c2/dMtiEE5/htbTqpXpGHgACSgij2osxcgkNkVDZSJbmiWLLtKTu exJCNZ81jOe6KXj7DwzubsKiEUMU1m61xyhpCTiOKYeI+iFNsdwuZmv1isfkn0AxuJYE7Lb7 DY/L5/S6He4r61MBQUMAYMXGs1eYAQW0ZIG4SCJlGMbFuGVYCYOQZ6m5KZSQkMIohlmIoMZp eLMxQEB4Whaqo0jTmhHwWRjSNenKmwAygOkgMHUAImBKc6e8zNw8xwsEUDlRSA1deBPgA9Am fQF7HQSOo9hSs8Ft0DjyWBiJtRu+Kf/AirDkAThQ8CSv208+DZkYa//EZBMhwoGTbwWpjHvB TRqbAtw8yNDHxBElPcf8jdjY8BUrbRUu0lsT0sjDkCuPECzzMuWRVJmyIJGpZM/Fi7PY3cJp QwtQMietFfvAasCKAC16Do31dIS3agK9xIyqo6JSNk31IWuJdV2Zo0edYggUlt/HtPAOpPFB UoBbmxnZugD7D6+QqwOr2k2k9m9QPX3SCFjIyJnixYzh/LRAwMFcwSmKUfAVgtiwnnUpo7Sr Nwhfq3494wBp1vRNTolVk0B0MqlrFAC6WvBF41boqLuvPdYzak+p2T9yHSK+et4z5GK/seo9 u8CSfTaZVw//2zi7dmY1raOQjWS7+PFwTtHxfn2CMAZ9bNn78xs9w+rQgdY3j0UBgARuExAA gMBkaQAAACsHeAKgJN3Jx+BTrXl3EA3PrbNQgxcg4EkeoZDHIXky3ZeBPRVIl8xWFSxwzwAP dDTTgha+2NCD1jEx10mdwXjBAQJuiB6IJQiygAHHDPKCjxfWUNYHAF4hQg8lGfmBizhOCY2M zDHBgIT0UUnLcRBicIA2B0gG2AdTqAIeClBWIOIASQLCwGYq0uANkSpJyWWelliJHBNbCLDP DOaw6UA6ph0mQWmHnPflFxSctAOJF5A0gAKF3caBl1S0WQwBMiDJxlRs2DPVnXqe/+oKn8QR MYw9M0yk1UWSUgaGoslpemWIjwqIA24VoEFQkqoEdgSnM5RaATd/SpSlQ3iiCq1Br/V41pwk 7LQmL8Hd9dmMtw2JDzf59AEfKLecmQdPWaSZWhHGYvAYoFEO4GuL0d6LzbSNvkBWtppgBswG mxXji0A8NipkBQ7g48NhNlVogi+DoChAUzyJ6ABq2XIzYhIbnaGkwlA6iW/JYyTWYcrZ4VBY HxCDVk+K+VB3a82rKuzDcHJVQM0NS9k2QnxP8twwrkV8msAKgKjDcw8JhCFxUqOaanLVklBb dVE+mJRUAe9cZ/NsS3jTc1I6r7NbWV63668JaCxQG0fPWv9NNwwoq4y3M6cWJcJRkAKjxsHe GsYmPtTJQpcOljqcRQDIgr3q3HVPPpjRN+u5M6VxTfaS4Lkm4+oC9kTmgVa+/iKEi22HQzLl rpOz3OBcWkYvCI8UQ0nn3X5ewSdMV/o4RjTQrEvexi8j+evKt8u8a6uzFTc7ge/e5xDNz3R8 9nUkv/zrqor9+raQL6J9+XHsgGEHJgApZB9grakff7077im9/xEod/f6U99c9ZRTPB9i+U8H OmrFZtBkNy60yRqRkBc32AUP7u2vbt9z3gQ9N0AszIpov7rUB9pgudQt4SdNmoswiCLBCVqt gqp5Xo8YJbsKhClAZNpBvYB1hbL/AAAxIQxCm0hVAcQ0q3VeIKIK98fCQ6mwKi7kBRTC8LdY nCtgkEkCAh6XrTYNQFyyGUYfhBbBIw4BaLRp4p70FcPuoeZ6StTAroAgMUFxZWgBrKMRtCiy OgHDjEbUHwRHIJs1qulyPWyhCgVpRvz0DlxKCpVhyuUCMKpLYQJ0Vw1kczq3nBCFYlxJfRIJ hGFx6wnmKyUIJ4hIrCVsAAub1wec0AQhJCkNvGLjDjh2nenQwFbiSKF87FGMjhCsI4II1DH2 IQgLJLM9+0GdIDzgC4H9ZgkBQEMyheEWFHWFXHIJgZwMUKhj7DCZOSDA1kCBRt7pL5WNaiXg PjCXnlnA/2u8HMHiKpREHSDtgwX6BTcCUKMohhFfcnJYPrYUJ0q66VU0mAITRtKwTzhpklnI FCtlyFCFrgOcdLJJoTwqDnRWEnyoTKf/Dlo2Nj3qQvVMwR+b+B/W+FI+O2Plo6S2CARIqgcT QIACkvBQeIpMqBQdxk94Sg1VKGQ1/9SGRFW6x+BV4VXHtCnqLhDH8uxrnSa93KVGIa/ERaGl ZujRTHtktpuuggk6RdxaLYCGoEKKY7EB6puOA4UaxESeybITDI4iqUzh8gLsTOPyCsu7UXFl dK3UCs/IOgRTmvKsEDpcoGqEU55s8lFTFJRQWdTKnc2yokvQa19fZpOfWqB0B/+KQm7KOQOe wAKxGVTjayRrPjX4Dq5STQNkoYKFwTJBGkJq1isoOyO5hAF3FYjT0xr2J0fGMRkHkE6THKeZ ADygD5OJyAfd0o3+bZFkwiCSGxxqi9Bgyylo+EJXSbo/Qf4WBQdArg780lsUiO8jfQjSkN6n QBrRIGeJ7OPeGhA9qZTgN2C8AACI1yusSq67qzgAWhbQ4BMc5XRgyABtCcnVtWDha3oQ5PhS AMDPHHAKf3yvDwXsSjyezL59qiVOmkmO3P1Ocdw1UzIq5mEXG7KkIqYCictg4rZt8C05yCKM h2FOgRqExrORQTWxskmWsSEAO8YCGD8M3xAH2ctVMXH/EEycXzjeAIcdvAEH1ujkRdRoP2ke qBjjK+Q24rnIRziyRkfMv5lMcVtqm8KSTxzKJ1OZHItuEDV+CkrrgNk1olxtpO0iSDPvwM8X 7UKSxTBdillMr0ULWxCEe7g6K8h7rpUxVq5oY3eQIKu4NR4ADFYSumWaC8YZMxfQTAZJXtKt toStP4+BYTa0uIiN7hGECZBhmcTlFLv29DQcgWtEo6raRi6zFz6tCXWZs9LFFoyBTabcLQCM LedQ9beF4hFZS+8bUqBqAJD5xWhxu8/etnaexzBa2JiVcpkUr4Mey4l9U0GqzSYstheB08B+ YrCnUngReu1efyvYEvc8kQC6/1zuv5wbOV6L9SBzCZrCJRzeVxtpEeR7hYzI1mQWFwKnNf0D cJ8Cw2uodfka/qFlm2AD6usBAEyOE3ldOuO+hse/c/7wt85i5r/SN8v5fXUjB1oe8NtPf+6H Pwu4WwlAT4mUuYQABkSbDDUvglTHfpqof0A3tWvonz3TytH8KOsX7/evSwB3TcRZeDwT1R5G LhgZBMK8rMiYAd5z1fD4PHvU5rtKnr5puftiYR0p6BwpzYp6uaDtQLj5uzGf8/62z68n3xSo LsA0YeC8CIgXTJuc9PFex9LlQ94E6UPK+zPLPdez9g5FUfD7TUt19jrQectXvIoEYuFdbFLm 8XVR9v9rUAo3w/jYap9m6t5rIvk/ePvpazFf1Vh5ra4awOph8yk4xD978yePlAL/giVTSvqu x2gpIPUn2fcNAsgLRvEqopcRG7R0lbCAymR5tId6OQBzejIcmjUDCHQIfldiVrF1nbBmvsUm ysYm4FdIP0B9wCAhkdFEtfcXlHJrH9AA6nIOpRZyKbdyfOYQERh385Yn1CCDTCZkzGcEQggQ OkgOg+YBBqBHWXBogzdamOAJQiJ0ZGcd9pAAHEM7oRJNIIhyW2UJ5Ic+JIB/ozd8U+KDGaF3 oUCENldEgAdqICRqDBEcecUFuLRkROBBzGYdjtNaKEAprII1vveA0tIFVaH/dw0yCjxxEftl Rw4nby0XfBdXAo7DhXRIBUijNAiAGEAmMlemh8zBiCVAIgoYiP8iB/V3PK6SMmUIIxSjDoDA Ma7oW1qkhpDQhkZ4BGsDhJY4IwR4Cl7jABBGCMHYiGF2RjhYBmMoUuh3LwUyAqowHIi2hsIX bxmgjEGgAFtwAChCeMXoPL4oDyVnAlhUisfYdBxxi8w4OSRhDbX4iE6Hi0IAaWwQV6wkjA2I DeDIdVMYfnomeIOYjvCojnUzCnM4iYaQfq13jpwgVZOnPfrIOvzojeJnjky3B9dYORhwiNEy CObVcw5pPB+SH14HDAQCdvbzCQdyhdnHgmyheOWl/yWOB3lgBJLHo0gLSRQBOSkJiTkd6I8F EWf4E1jDM2AqwiLOUoUyYwC6F0TxyBs3aZHoWI07iUQ+6RlJsF3atZHIp3r/xX/FElsYJUM0 UCNbky0tyRbb9yoZE0AyME3lyIAA2QUsyYqug0Egtkg2VSbQJ5E1+AJ4FHBzViJ2RhwGOHeA CHH9eJVQ6YiUwQhbmTUwpE4dQ0WRkgSU4ipJ4ZaRqAOAaVegc1CEORsu+CgxeCMChY+Hx5jf UpMqExl3ppiOaQHvFzCytxXugwI3BIJK6BRnN3hi+Q2CKQDGhZSgCAJY2HmAsIVaMpE/GZec aW6wGZvR2RMcc3segIE2gP+EyeGbAZYjnzkvomcvzMGHa5eYzbmYrOGUByedBmdBezQ0lHIR +5ebcPh5A3Ke04kDFHeHqTZUoklpKVRT7kmRDBg7kwmbqSmVbTKffTMDkIlVJKCLzKmfL7BP btIHAKAOSohsUQM6xUkcwCiMJUA76CmbeQGXd6agr5CXwqM52OkBXhMMirMFUmNjK8pJdIOj JwOUKdpJgSgMAgNttjMFcfgLkZcC8wgyJVqh7AaRNmhYVeKjR7SjhDgiQJNgzoEUPAohT8pu raky5lmRtZWgU2oD4IV0SgCmKuOlaYEWktajXpiga7qKObAij8KTClkE8fN1KYkgNYGRatKm YWH/C94xjVIZpe2pqEXinUQ5L5v5Wp9oNe2gmraIonK6qGrUlbjJqNOnaCEYgquDllxCqYi6 B4fKopiaqazmY9m5jGApZ0UJn1kQVqtGN4VaCIEqgUBJpx2yqvujfwQGKWwAZ40qVGYSZaHn AaUKolXDrDlpqb8qrdKpm9TAm40jqyaaA7Q4Z1coZ1fYNqNKJc/Kpe84reeqQs5Umc1xRSWI Pp9KWJ7ApM1qMrh6kZWAquiqr9ASavdJiQa3MUzgnw5YRdhXN+Rqpae6rwu7P2A0oSe2Jvv0 T8kGgAPqPiOaCIOKFQirk0jGsB8rRtmYa1twjwN3q2JqBLq6gyDLssuj/6Ss1AYaY7KTmq/A Za4ti7PS2asdorFRwbFT6bE5K7Q6u7P2d7Ao63b4OrRL+6PB1Rk6tSU5SrOooLRMa7X644SX ySTHdbA122RVe7VhyyDs45Wd2n8LtVoLtQWoZauTirRCoLIw4LViS7ci2aos9pV3BCr/lxTB FLc20LNP8bOQqLB1a7iuEayhmhR9UKyeCpwoKHZyMmNdS7XReriX+xfVSgHXeixk6a6d+XoR uggYO55uawh/S4aYq7qgsZ11tCABS5mN+QHtNWWUmy+Wu7q5OxT9yon4OZhN6lJskDR9oIlR 4DScRq8lM7iCMbe667yG4LAgcZQE6gVvk6W1e/+y3pGnz8u9nCCy0SdDXzGz8iGOMLB4Rbsd 3au+T/Gy+NO4vfgiZ9clZLq+9XtjNIm+4hG4gteXfpkWVWq/AVxWTisWrCeebVtlgACTWyqT foCk1JueAizB+LqprJeRehur41UqPYa9yHGdH7CUMdeU0ClyE2wXIVAKDkBGGrG9QbBd3SE6 CAByz9i81nO34DtKZ3us6RUFf5CmvbSHPsB9bAnBAAy0JvwUt4dzlCi/qGAKFlwC5kR8hZC4 RajDNcVZszCgBkueDnqY6GnEhIvEUdEm0kG6jgoNeUgAeWi2e6C5ivsN8fGbWDxeaSBRP5yx QZwspfmDwBBOOxbGAjn/xmRcA9y4ABkjR+5jD2FwyJvVA4/8QRJAJBPgJNEkDOeSb8AIBYu8 CH+gTH2ATPRAJCfETFblAcPUwnFMSaPAucbLLnMcT2S5BHhsBvtLBlaInI+inBM1A6SoqoOc EqPjCxLBM2eCt2F1DjNAFh/QAmUxAVTHy6w0cRnFrCvlFaoVtR8HgmVBaq81M15mn71rE0cn ZbDrqCLADZY1ueR5dOa5XhB8osCcxBUjKhPAjhoSM4ugAHclddFoAJeyMyaBBPZcE4/iUGhL H/gAVdBsQq/SvxHmCGTzASV7icI7XkwxzLPAoQDVwcQRiiTQL9pawvI8z1iltYnpQWfAzzzR /zPEvKUC/S0HSSKaIXUfYM1nyBlJQVcPXQS62AOLDDSBnLymIaIu0DKM80H5qx0k/RQUFzJp sK47g81ZwM9lcUX/OstoKycOJdGTMpg7hVM2MQrcvEs4c6yF8L06wh99JNSly9Rv7ZIWzZoz ICRApiwhKB3AcmzSAMorYgxXdAzts11KN0fTNZujswoUECb54FyNlQ8T0WNsAF7YpbaGoKS0 W85KrR22DNedzWsugH8FsA9nzGC3lBVnzHUjKT/+cQsHAgC0u0VS69mzTdtjakmxm62RKqm1 zdu9rQUVDGCOi9C53X4d7dvH3dtLYMw4/KoYPNyupMWoncfITd2c8P80UpAgL3DJ4pw6NVwC 5LYJVZyZ5COzwl0MpUDJeaA+y1vL1e3e+HoDTm1AqayZvijFGcDTQfDGrRzb6/ndoZut3STf bv3eBe4FFCWEZ+lEe9K6aNOd5s0qecABa53Kh8DZBt7Z01spCgPKMPspXiFO6ybKpcAx2TgF xDsDgiBRx7RJjdzLKE4EiyMilOwNhWIFU7BJgrDG4mRV7ueVKn5x4bxNU8ENclyHNaCANX4B 10d7F47hbx2aAbQE6tCOibkzb/p6R/EAy9XLoZvMCF2raIthehSNr+cAoefS2niBRXrm9PK3 0Ws5ESu8SqOhtQMoHGwYYU41T87nKhE8bCX/1k1i5QYiC++cLCekiBfIBPu8BOChWVbAjoL+ VjKgIQNmz0BI6XrwveDBi1fi5H0OzJJbsGWtV5K+pbjR5jbxzglDIolOODTA6BQqdX/zilsk AjwhHbJw0h3jQi8rAVD9ueb26aA+yJe5pWJlkJ6rhJyel9yMBhtG10cx1cqc1RZg1TWwQ1sE HkeRENa8WZXZ7ZWwH7el2Y0x7MSOxHFiC0+jDo1dOo8NKPZwysTkBuZwDFZohXtUb/hw4jtj D3ltGKJ9DO21OLqxZXZu0X3wz3JRWuDlSHPEXUb8tqnzpNGI7hevTw9WLSxjPzzRW619AmNY AO11GQSQUBpQfCRw/+7aVogV7ocuj/Exr93xPfFeUAxzUQArf3kICfMmAKEyD/R6a1TycL49 Hw6oywdGX5dBz/QSfGk/vxdK3/RTn7NPL/UDSfVZX79I//JUofVfv75W7/VgT/bOK/Z7APVl r/Y5y/UnkPZA8PZr3/SZkqF/8dFDcfaEcfVyX90rkiyXxW7+m9o8P/Z8z/dPZINtTRsBUfiG r/YboHi/ixWnU/NSSvhov/eO39t/+MmBz/Jmx/iYr/lrv1OQkfm3qPghH/p6P/prXyjVFAjq wxY/A6Wib/utj/sg2/Y+f/oIl/u/v7B5DxO9D/zFXu6NUfusf/vFD/SpnxPQs/rDz/ydDf9M B39CkE0kkUHEwIsdyS/9yz/9JF1QsNTMpU4XRv7LSRf9ZBD34c+9NQVFdIQJ+/Vmgo8Vzu+G l6/87i/+EEDGQGGISfAICLlpqjjkCk80VVe2dd91g2e6ZmU7DwNL13lfUDgkFo1HZFK5ZDad NkFhEjUNDhtP9QBwSAgg3FMcGzPDYmA5XWa33W94XD5/CwQHhwUgAHCiD7sBBzswL4wzOiXE xJm+tjW0HsZJykrLS8xMgQaAhZmCgynDqsyixdKTUybIJ1bUV9hY2dnLO58ODgtV2hveVDfX pmBf4mLjY+QQjQAFn8OpZJddVEe24aXraO1t7m7ZEmjv3+LppGz/c0lx9XX29rr2ck3g9FZ6 93v8fH0au37/f4ABBQ4kWNCgQGPV1NgTxnDfQ4gR18UzRrHWPGsOJW7k2JGWRWIgK4kccg6J SY8pVa6kgeCOHQuDLkQJEGjAFwcgUpD8mBDjQpZBhQ59IUCngAcXPF2ZAGSDgAQ74VX8OQYl UaxZIdoSpCsDFg/gQuwJwXOW2URof2hUclXrW7gTJVDwenNDhw8hDIQjpU7tHIVW2aKLW9gw PioXpGxgSqEE4x4y/r6aHKcyDbdEMh/m3DmWHTx6+PgpAAjDIKNlVbO7/O7R4JOwPc+mrYmT JxigxvUV19pN4EgZaw8nTjlUEMlTyVUN/17c+fNEy5rp2BOVtzffbbK72CykO3Tw4SkdJF/e /PmBgooBrydc/Hv4r7Ksy7P8tfv4+fUz+j6rfkjm2ttvQAID7CYB2TBhz4n+1irwQQgbYiMn N/7zZbsWGsxBwwg79LCpBIvgMAcLecGQhRExC/FDFltMcYYXaUBwPQMlbPFGHFeI8YUdYRBg xZFqXAXIHIvUr8cMiRxiRmIWtFEwI6O8EUkUlRSixJ7uA0pKLjukUkcrg8DSPzfmG2OELtMs 8EsV2FyBSRPRk3NOOgESS00843MThT1TGPMzHRIgAABCAbCOiQLCFODOPBsFr88dwvThzyfy EGABA360aQaeEv9Tb4XjhjBrUUdLfVRSGyA9Ac4yngIhr7k4dSbU6VIIIFYhRmXUVF5nUzWX ClG1oYAwcIHCGQYmcGSQPqDaoz5L+6ipAQEYWHQQ6yy1Ttdeu6Xt118noJSJBGRoBhIHENhr ikNXy8EoHmSQKTIpCA1HshI06MqKp5Db1VuA3wJXWBtYHQMqcR1ztykBcOULimQHUGjThgXJ o4PFygpFX2Vluo6ffwMWeaiBg3Wj3EAWsMOTDqoB4AqHP/Yx1AHWraksCSqewBPJRsl0AGIf hiLkkYtWqeQ2xnWiXZyr0EUKFDpdd4AFvCp3imRdUnYvyUJhSoBmGuPWaLKDQpoNg+f/uOsD D4zCbeEZDNjjxwBk8jgQl5qFSWJSrwjggZoMcKnuRct1Uhqiy1b8obPLUNoNLAAoIIErdj0x hQJqdcE6mp1JfHHQ72l8jMfbKACMVGK+nBFSQ3edcYJhjF3G2YuY3Ed4Pn99d27MFMN30mtn Y/W0dOf9eGTqVH5584y/KAcAKmAak9aRt74b4umoPst3iZ6eiJg5df568pfQgItAyv2CD5Sz rQnqqOERvlXPVyBg/k7HL3//I7S+4LHI7EVfrlJB9tRmn+4NoFwfaBixUnM6mVxhgTVxSV5O hwBioQ8DNQnA4WKgP/6F0DvguBpXNjBAaSjnQvX7n10U5jQw//TBAEFbQNDoQoGnPIaFIuTh kCbwtbmcsFrmKqAKTcRCW+grDXTDhc44xjEgGKuEO+xhFY9gLADo4jiMOUS2iPUFRxhQDmJM Qv5E4UIgXC11X2HjDdPwNSpaUY5CcEkCyOI3vknrUijrVxXICIc/HqFTYfTaBsExGg5c4DiN UWO6SKAsr7wNZHOkpHde9r03raaPE0FgDVB2AGL97X145CPQUuOHbcXrUtUhy0zCh7hKxjIH wKtBHwMJuU6SCwZ9wE0HD4DJWoJQlpSEIPw82TANROWW2snlJGgZx2FGUwzLHF4zE1FMUwhT mtvUATXpByDWaJOb4+QU88x5ToBYk/8b2yNnO0FnlrrVjQDiXMHpOgdNd+azaJ2SxI9ocM8C vnJo+iQo2UhysxPohEcCXSMR2FlQiD7oUibIy7u6ybRmLCAnGEjUogLxrLZRSwKWgprOREXP iKaUNnORgAKMyY8caOCl4dCa2BZTUnc9haGTVGlPHSUSmabAfxdQgNhyFsScPman4vNpU/FE EkSeAKFENeoFkOrCKehiqT5CqVO9Gh+SDDVhyRFbKKrFF509BaAJ/Gpbc8STCiagoi4h1rmi EEocGqp11kqAI/2mOXy6VbASFYK9UOBBFiC2m10dbGNp482Dzc+xk9UKZKdJWczux7JP2Gxm PcuaHAiuApv/mWg1P3ta6HSqXiZ9gUJRAExRoVa2xenUcTwWhPuZYba7fSyypiAWS+FsUbdC 2OluRgigbZRf5YrJVHHHW+geplPaCoFOvhYKLpxxA686ZFNiGA7XFiW6441Lp3CYitFqlV9n zBuIssoDpYogqrIib32xUltBJGdVpwniXOYGLDU2TVmbeq59DcwS1WZ1CnepGQBwZYvIzPOQ jtBiU9gF0wNneBvaUoCm4iESuf1oixXrRx9QY4cH4PVHV1uGAvthyqMEIMAF1nCNi+GAqJAF VvRFwqEsICiOhWABmMTkkI9lYySvUKr6O9FtDQXIJEf5LCE4lyRw3APjxq8JLjEKt2yd0Fkp h/kGOuGuuLygEzTBDTtiZrMm7GAA03hCXwplBZh122Y8V4LIOKizEfP8Z0skihR9Bi2gDT2S UPRVBIyy8xIafeg/ZzcAe1FZGB5dRkhnmhGfuzQSOq1pUMtsG58OdabReWp0llrVq2Z1q139 aljHWtazpnWtbX1rXOda17vmda99/WtgB1vYwyZ2sY19bGQnW9nLZnazy4ZqaEdb2tOmdrWt fW1sZ1vb2+Z2t739bW5HAAA7 --------------03ED80715F6060887E1CDCD3-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 19 07:18:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yYQb-0000CD-00 for ; Fri, 19 Apr 2002 15:27:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 15:27:53 +0200 (CEST) Received: (qmail 4153 invoked by uid 0); 19 Apr 2002 05:12:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 19 Apr 2002 05:12:14 -0000 Received: by moria.seul.org (Postfix) id D00521463AB; Fri, 19 Apr 2002 01:12:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD3021467F1; Fri, 19 Apr 2002 01:12:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 587091463AB for ; Fri, 19 Apr 2002 01:12:12 -0400 (EDT) Received: from f-cpu.org (kdl16-144.n.club-internet.fr [213.44.18.144]) by relay-1m.club-internet.fr (Postfix) with ESMTP id CEC8E168B for ; Fri, 19 Apr 2002 07:12:06 +0200 (CEST) Message-ID: <3CBFA8B0.9462D1DF@f-cpu.org> Date: Fri, 19 Apr 2002 07:18:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Winograd DCT on my seul.org account Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, for convenience (and also attracting people with search engines ;-P) i have unpacked my paper at http://f-cpu.seul.org/whygee/dct_fc0/dct_fc0.html so it's available for online reading. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pash.cracken@free.fr Fri Apr 19 09:09:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yYQj-0000CD-00 for ; Fri, 19 Apr 2002 15:28:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 15:28:01 +0200 (CEST) Received: (qmail 3358 invoked by uid 0); 19 Apr 2002 07:10:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Apr 2002 07:10:11 -0000 Received: by moria.seul.org (Postfix) id 18D411467E9; Fri, 19 Apr 2002 03:10:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB7CE1467F0; Fri, 19 Apr 2002 03:10:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-3-163.abo.wanadoo.fr [217.128.160.163]) by moria.seul.org (Postfix) with ESMTP id 340871467E9 for ; Fri, 19 Apr 2002 03:10:09 -0400 (EDT) Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16ySWj-0000Bf-00 for ; Fri, 19 Apr 2002 09:09:49 +0200 Date: Fri, 19 Apr 2002 09:09:49 +0200 From: djrom To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Message-Id: <20020419090949.20187ae9.pash.cracken@free.fr> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N this is a very interesting paper. but what haven't you written the code in assembler ? the C code looks like assembler in any way, so ... :-) it cause the problem of gcc to (re)raise. optimisations for FC0 are very different from usual optimisations, even for RISC processors. I don't know the real structure of gcc, but I guess it'll be very difficult to put FC0 tricks without breaking the portability, no ? I even wonder if rewriting a new compiler won't be much easier than trying to add such things in gcc, if we want the compiler to be good. we don't want to see the F-Cpu ends like the PIV, used at less than 30%, right ? moreover, we should perhaps think about another langage to be used on modern processors. C is very limited in his expressivity, so the operations like SIMD or "real" optimisations put a ton of work on the compiler's shoulders. it shouldn't just try to optimise, but it must even try to *understand* what the programmers meant. is there a langage really usable for modern RISC processors ? maybe we should try to return to lisp or ML, or something like that, no ? that's could also be a way to promote new langages: I don't want 2030's processors to be always coded in C ! :-) if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Apr 19 08:38:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yYQj-0000CD-01 for ; Fri, 19 Apr 2002 15:28:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 15:28:01 +0200 (CEST) Received: (qmail 22190 invoked by uid 0); 19 Apr 2002 07:23:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Apr 2002 07:23:58 -0000 Received: by moria.seul.org (Postfix) id E3C021467EF; Fri, 19 Apr 2002 03:23:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B585A1467F1; Fri, 19 Apr 2002 03:23:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 660D71467EF for ; Fri, 19 Apr 2002 03:23:55 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16yS2P-0004t1-00; Fri, 19 Apr 2002 08:38:29 +0200 Date: Fri, 19 Apr 2002 08:38:29 +0200 (MEST) From: Juergen Goeritz To: Michael Riepe Cc: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes In-Reply-To: <20020418200628.14566@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 18 Apr 2002, Michael Riepe wrote: >On Thu, Apr 18, 2002 at 10:25:32AM +0200, Juergen Goeritz wrote: >[...] >> >However, the LSU hints are not "portable" and not accessible from >> >portable C code. Intrinsics or macros are probably necessary, >> >but it's as ugly as using MMX intrinsics in C code, so go figure... >> >But if a compiler is "smart" (?) enough, it should do the job. >> >This goes along with the same process that is used to globally >> >allocate the registers, because program-wise statistics (and even >> >profiling) are necessary to set the good flags at the right place. >> >> Jo, jo. But there ain't no PD compilers around that could >> do the job, are there? The gcc 2stage profiling optimization >> features are not thaaat convenient to use for global... > >gcc (I suppose you mean 3.0.x) doesn't optimize globally, and the >profiling feature only has an effect on branch prediction. I know this ;) what I wanted to say is that it also will hardly be adapted to the global optimization scheme required for f-cpu. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Apr 19 09:22:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yYQj-0000CD-02 for ; Fri, 19 Apr 2002 15:28:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 15:28:01 +0200 (CEST) Received: (qmail 3925 invoked by uid 0); 19 Apr 2002 07:24:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 19 Apr 2002 07:24:10 -0000 Received: by moria.seul.org (Postfix) id 618DF1467F1; Fri, 19 Apr 2002 03:24:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38CC71467F4; Fri, 19 Apr 2002 03:24:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 185491467F1 for ; Fri, 19 Apr 2002 03:23:58 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ySir-0004tT-00 for f-cpu@seul.org; Fri, 19 Apr 2002 09:22:21 +0200 Date: Fri, 19 Apr 2002 09:22:21 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Re: Navier-Stokes In-Reply-To: <3CBF3A8D.B8FA750@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 18 Apr 2002, Yann Guidon wrote: >> How about special register access methodology opcodes? >> This way you define the entry point how to access them >> but do not need to fix everything (layout, number, etc.) >> from the beginning. Just have it read/write for superuser >> only, one parameter being SR#. > >i don't understand exactly, but just in case, here is the current method : > >- there are only get, put, geti and puti as means to access the SRs. > This instruction stalls the pipeline until it is sure that there is no > access violation. Okay, this it what I meant. But why stall the pipeline? It also would be possible to just advice to use a number of NOP cycles after critical settings. Better do an out-of-order exception on access violation. Thus the register bank may also be implemented in a slow mode (maybe with eeprom backup or whatever). And finally do exception on any non-writable bit(!). This would imply a write mask to be delivered with the write data - just to be sure that the bits stay free for further extension... >- the SRs are either hardwired (read-only, for example : the mask revision), >supervisor (read-only too, if you are not running with a suitable privilege) >or user-contolled (for example your private size registers). > >- the hardwired registers provide informations to the running system, they are > defined during the CPU design and say how many SRs there are, what kind of CPU, > what is the register size, what opcodes and what units are provided... > >- The "superuser" registers control those features that have any impact on the > running system, for example the trap handler addesses, the TLB, the memory mapping... > Note that when it is possible, an individual "authorisation" is allowed to every > ressource so a pice of code can deal only with one ressource at a time. > A task can only reset this bit (when it is set), but not set it, to enforce > the system's protection. This is a bit similar to the Hurd tokens but can > be used in other places such as Linux as well. > >- The "user" registers are those which have no protection bit, for example the > task's private performance counters or size attributes. A user can be "granted" access > to a SR-controlled ressource if the super-user modifies the associated SR enable bit, > but otherwise all the task has is a virtual address range to play with. Do you handle the tasks in here? That really spoils my thinking. Task private things... for how many tasks? >There is no specific opcode for managing that, it's all done with get/put >and it traps if the necessary rights are not granted, that's all. Okay, get/put are specific opcodes, are they? ;) >> Anyway, who wants to end up programming around hardware cache >> strategies? :-/ >nobody "wants" but there are cases (yours ?) where this becomes necessary. Oops! Necessary??? If I can control the way the cpu handles it it may not be necessary at all. Shrug! >> Could probably be easier to change the cache strategy on the fly? > >if you want to change the cache strategy, there must be more than one >in HW. Intel's MTRR (and the competitor's equivalents) provide a mean >to modify the cache strategy for a fixed number of memory ranges >(for example, the video memory can be set as write-combine and >multi-CPU shared memory space can be set as uncachable). Yes, generally you have lock, disable and LRU in most processors. I was mainly talking about the aging process of the cache to be switchable from LRU to something else. It may therefore not need a cache flush at all. >This is usually possible to modify this when the system is "alive" >but there's still a risk of loosing data if you switch from one >policy to another when you forget to properly flush the caches etc... >But that's for the x86 world. :-) see above. If you manage to use the same valid bits it should not cause problems as long as it stays associative. I didn't talk of changing the load strategy! Just alternate strategies for identification which cache entry to use for replacement next. >This is possible to do this for F-CPU but i don't see the point of a MTRR-like >system, at least for the first-generation F-CPUs. I am not exactly sure >of what you have in mind but if it's simply changing the cache >>from write-through to write-back, do not forget that F-CPU is a multitasking >system and a user task doesn't have to change an environmental variable >that might impact the rest of the task's performance. I am sometimes thinking about the 64bit generation microcontrollers with 1TByte memory built into the SOC. :-) >So as a rule of thumb, the FC0 has a private memory range (as fast as possible) >and public range (uncached), and the task can specify whether to keep in cache >or not with the "hint bit" (flush) in the load and store instructions. This >does not impact mullti-tasking systems at all and is very simple to implement. I see - and I appreciate the hint bit. >> The gcc 2stage profiling optimization >> features are not thaaat convenient to use for global... >profiling is not often used, but it is useful in constrained real-time >applications, such as if you want to track where your soft DVD player >wastes time. If you have a relatively coherent program you can attempt >to do some auto-tuning (adaptative programs) which has the advantage to >be portable, but you often forget what "convenience" means when you are >CPU-bound, memory-bound and ressource-bound, no ? I did that type of thing for more than 7 years BTW... ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Apr 19 10:24:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yYQl-0000CD-00 for ; Fri, 19 Apr 2002 15:28:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 15:28:03 +0200 (CEST) Received: (qmail 23230 invoked by uid 0); 19 Apr 2002 08:25:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 19 Apr 2002 08:25:13 -0000 Received: by moria.seul.org (Postfix) id 05C211467E8; Fri, 19 Apr 2002 04:25:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98B841467F3; Fri, 19 Apr 2002 04:25:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 8AE311467E8 for ; Fri, 19 Apr 2002 04:25:09 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204190824.3722; Fri, 19 Apr 2002 08:24:55 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] new langage ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2002 08:24:55 GMT Message-id: <200204190824.3722@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N New language of a higher level is really needed to really ha= ve a code portability without the problem of performance. BUT it's really hard to devellop a all new language ( or loo= k at "D" ). I personnaly like the way systemC work. It's only a "big" li= brairy for C++. We just have to design a librairy that work well with S= IMD.=20 In c++, one librairy do such thing : STL. If we port STL (in= asm) for the fpu we could accelerate all soon written programme and f= uture one.=20 I think it's the better cost/benefit ratio. nicO -----Message d'origine----- De: djrom A: f-cpu@seul.org Date: 19/04/02 Objet: Re: [f-cpu] Winograd DCT on my seul.org account this is a very interesting paper. but what haven't you writt= en the code in assembler ? the C code looks like assembler in any way, s= o ... :-) it cause the problem of gcc to (re)raise. optimisations for = FC0 are very different from usual optimisations, even for RISC processors= . I don't know the real structure of gcc, but I guess it'll be very di= fficult to put FC0 tricks without breaking the portability, no ? I even= wonder if rewriting a new compiler won't be much easier than trying to= add such things in gcc, if we want the compiler to be good. we don't = want to see the F-Cpu ends like the PIV, used at less than 30%, right ?=20 moreover, we should perhaps think about another langage to b= e used on modern processors. C is very limited in his expressivity, so= the operations like SIMD or "real" optimisations put a ton of wo= rk on the compiler's shoulders. it shouldn't just try to optimise, but= it must even try to *understand* what the programmers meant. is ther= e a langage really usable for modern RISC processors ? maybe we should t= ry to return to lisp or ML, or something like that, no ? that's could als= o be a way to promote new langages: I don't want 2030's processors to b= e always coded in C ! :-)=20 if *we* don't promote new langages, we won't be able to coun= t on Intel to do it ! :-) ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Apr 19 15:18:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yeWs-0004eB-00 for ; Fri, 19 Apr 2002 21:58:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 21:58:46 +0200 (CEST) Received: (qmail 8028 invoked by uid 0); 19 Apr 2002 13:21:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Apr 2002 13:21:06 -0000 Received: by moria.seul.org (Postfix) id F2ABD1467ED; Fri, 19 Apr 2002 09:21:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EAA351467F5; Fri, 19 Apr 2002 09:21:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 467961467ED for ; Fri, 19 Apr 2002 09:21:04 -0400 (EDT) Received: (qmail 83912 invoked by uid 85); 19 Apr 2002 13:21:46 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.520665 secs); 19 Apr 2002 13:21:46 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 19 Apr 2002 13:21:46 -0000 Message-ID: <3CC0191F.9050007@yahoo.fr> Date: Fri, 19 Apr 2002 15:18:23 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry, But it seems than I never have receive the begining of this discussion. Where can I get it ? Perhaps the subject have been changed. Bye, Just an Illusion Nicolas Boulay wrote: >New language of a higher level is really needed to really have a code >portability without the problem of performance. > >BUT it's really hard to devellop a all new language ( or look at "D" ). > >I personnaly like the way systemC work. It's only a "big" librairy for >C++. We just have to design a librairy that work well with SIMD. > >In c++, one librairy do such thing : STL. If we port STL (in asm) for >the fpu we could accelerate all soon written programme and future one. > >I think it's the better cost/benefit ratio. > >nicO > >-----Message d'origine----- >De: djrom >A: f-cpu@seul.org >Date: 19/04/02 >Objet: Re: [f-cpu] Winograd DCT on my seul.org account > >this is a very interesting paper. but what haven't you written the code >in assembler ? the C code looks like assembler in any way, so ... :-) > >it cause the problem of gcc to (re)raise. optimisations for FC0 are very >different from usual optimisations, even for RISC processors. I don't >know the real structure of gcc, but I guess it'll be very difficult to >put FC0 tricks without breaking the portability, no ? I even wonder if >rewriting a new compiler won't be much easier than trying to add such >things in gcc, if we want the compiler to be good. we don't want to see >the F-Cpu ends like the PIV, used at less than 30%, right ? >moreover, we should perhaps think about another langage to be used on >modern processors. C is very limited in his expressivity, so the >operations like SIMD or "real" optimisations put a ton of work on the >compiler's shoulders. it shouldn't just try to optimise, but it must >even try to *understand* what the programmers meant. is there a langage >really usable for modern RISC processors ? maybe we should try to return >to lisp or ML, or something like that, no ? that's could also be a way >to promote new langages: I don't want 2030's processors to be always >coded in C ! :-) > >if *we* don't promote new langages, we won't be able to count on Intel >to do it ! :-) > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > >______________________________________________________________________________ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 19 18:02:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yeWt-0004eB-00 for ; Fri, 19 Apr 2002 21:58:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 21:58:47 +0200 (CEST) Received: (qmail 6118 invoked by uid 0); 19 Apr 2002 15:55:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 19 Apr 2002 15:55:41 -0000 Received: by moria.seul.org (Postfix) id 1BA7E1467F4; Fri, 19 Apr 2002 11:55:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 029C31467FA; Fri, 19 Apr 2002 11:55:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id B1B681467F4 for ; Fri, 19 Apr 2002 11:55:40 -0400 (EDT) Received: from f-cpu.org (kdl16-53.n.club-internet.fr [213.44.18.53]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 981AB175A for ; Fri, 19 Apr 2002 17:55:37 +0200 (CEST) Message-ID: <3CC03F82.CD640E55@f-cpu.org> Date: Fri, 19 Apr 2002 18:02:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> <3CC0191F.9050007@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Just an Illusion wrote: > Sorry, > But it seems than I never have receive the begining of this discussion. i receive error messages from some servers and users (such as the user 'bombe' for example) but i have not seen yahoo.fr yet. > Where can I get it ? look at http://archives.seul.org/f-cpu/f-cpu/ > Perhaps the subject have been changed. maybe, who knows ? :-P > Bye, i hope you read the DCT paper ;-) > Just an Illusion WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Apr 19 18:28:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yeWt-0004eB-01 for ; Fri, 19 Apr 2002 21:58:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 21:58:47 +0200 (CEST) Received: (qmail 10254 invoked by uid 0); 19 Apr 2002 16:31:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 19 Apr 2002 16:31:42 -0000 Received: by moria.seul.org (Postfix) id C55771467F3; Fri, 19 Apr 2002 12:31:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF4B71467FA; Fri, 19 Apr 2002 12:31:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 0B66A1467F3 for ; Fri, 19 Apr 2002 12:31:40 -0400 (EDT) Received: (qmail 91035 invoked by uid 85); 19 Apr 2002 16:32:22 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.337015 secs); 19 Apr 2002 16:32:22 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 19 Apr 2002 16:32:22 -0000 Message-ID: <3CC045CB.6060409@yahoo.fr> Date: Fri, 19 Apr 2002 18:28:59 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> <3CC0191F.9050007@yahoo.fr> <3CC03F82.CD640E55@f-cpu.org> Content-Type: multipart/alternative; boundary="------------050501050707060809070905" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------050501050707060809070905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi 2, Yann Guidon wrote: >hi ! > >Just an Illusion wrote: > >>Sorry, >>But it seems than I never have receive the beginning of this discussion. >> > >i receive error messages from some servers and users (such as the user 'bombe' >for example) but i have not seen yahoo.fr yet. > >>Where can I get it ? >> > >look at http://archives.seul.org/f-cpu/f-cpu/ > >>Perhaps the subject have been changed. >> > >maybe, who knows ? :-P > >>Bye, >> >i hope you read the DCT paper ;-) > Not yet, perhaps this evening/night (?), depend on my tiredness. > > >>Just an Illusion >> >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > --------------050501050707060809070905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi 2,

Yann Guidon wrote:
hi !

Just an Illusion wrote:
Sorry,
But it seems than I never have receive the beginning of this discussion.

i receive error messages from some servers and users (such as the user 'bombe'
for example) but i have not seen yahoo.fr yet.

Where can I get it ?

look at http://archives.seul.org/f-cpu/f-cpu/

Perhaps the subject have been changed.

maybe, who knows ? :-P

Bye,
i hope you read the DCT paper ;-)
Not yet, perhaps this evening/night (?), depend on my tiredness.



Just an Illusion
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


--------------050501050707060809070905-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 19 12:25:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK1-00061K-00 for ; Fri, 19 Apr 2002 23:53:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:37 +0200 (CEST) Received: (qmail 8860 invoked by uid 0); 19 Apr 2002 19:25:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Apr 2002 19:25:13 -0000 Received: by moria.seul.org (Postfix) id 9595B14680C; Fri, 19 Apr 2002 15:25:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E568146810; Fri, 19 Apr 2002 15:25:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a185.home.uni-hannover.de [130.75.232.185]) by moria.seul.org (Postfix) with ESMTP id 7F5D914680C for ; Fri, 19 Apr 2002 15:25:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00589; Fri, 19 Apr 2002 12:25:23 +0200 Message-ID: <20020419122523.52714@thrai.stud.uni-hannover.de> Date: Fri, 19 Apr 2002 12:25:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204190824.3722@th00.opsion.fr>; from Nicolas Boulay on Fri, Apr 19, 2002 at 08:24:55AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 19, 2002 at 08:24:55AM +0000, Nicolas Boulay wrote: > New language of a higher level is really needed to really have a code > portability without the problem of performance. > > BUT it's really hard to devellop a all new language ( or look at "D" ). > > I personnaly like the way systemC work. It's only a "big" librairy for > C++. We just have to design a librairy that work well with SIMD. > > In c++, one librairy do such thing : STL. If we port STL (in asm) for > the fpu we could accelerate all soon written programme and future one. > > I think it's the better cost/benefit ratio. I really don't want to be tied to a single programming language. No matter what it's called or who invented it. In order to support arbitrary languages, we need a native code generator that transforms an intermediate code representation into F-CPU machine code, and maybe also performs machine-dependent optimizations. I suggest we concentrate on this piece and worry about the language-specific front-end (which generates the intermediate code) later. That is, we have two things to do: - define an appropriate (universally usable) intermediate code - write code that maps it to F-CPU instructions -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 19 12:01:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK2-00061K-00 for ; Fri, 19 Apr 2002 23:53:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:38 +0200 (CEST) Received: (qmail 25410 invoked by uid 0); 19 Apr 2002 19:25:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Apr 2002 19:25:19 -0000 Received: by moria.seul.org (Postfix) id 7BFCF146815; Fri, 19 Apr 2002 15:25:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79822146814; Fri, 19 Apr 2002 15:25:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a185.home.uni-hannover.de [130.75.232.185]) by moria.seul.org (Postfix) with ESMTP id D0AFC14680E for ; Fri, 19 Apr 2002 15:25:11 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00528; Fri, 19 Apr 2002 12:01:39 +0200 Message-ID: <20020419120139.32825@thrai.stud.uni-hannover.de> Date: Fri, 19 Apr 2002 12:01:39 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419090949.20187ae9.pash.cracken@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020419090949.20187ae9.pash.cracken@free.fr>; from djrom on Fri, Apr 19, 2002 at 09:09:49AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 19, 2002 at 09:09:49AM +0200, djrom wrote: [...] > it cause the problem of gcc to (re)raise. optimisations for FC0 are very > different from usual optimisations, even for RISC processors. I don't > know the real structure of gcc, but I guess it'll be very difficult to > put FC0 tricks without breaking the portability, no ? I even wonder if > rewriting a new compiler won't be much easier than trying to add such > things in gcc, if we want the compiler to be good. we don't want to see > the F-Cpu ends like the PIV, used at less than 30%, right ? I guess that writing a new C compiler will indeed be easier than hacking gcc. > moreover, we should perhaps think about another langage to be used > on modern processors. C is very limited in his expressivity, so the > operations like SIMD or "real" optimisations put a ton of work on the > compiler's shoulders. it shouldn't just try to optimise, but it must even > try to *understand* what the programmers meant. is there a langage really > usable for modern RISC processors ? maybe we should try to return to lisp > or ML, or something like that, no ? that's could also be a way to promote > new langages: I don't want 2030's processors to be always coded in C ! :-) And I don't want to be unable to code in C in 2030. I like lisp, but... C is very limited in its expressivity? Huh? > if *we* don't promote new langages, we won't be able to count on Intel > to do it ! :-) Our goal is not to promote programming languages. Neither is it Intel's. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pash.cracken@free.fr Fri Apr 19 22:00:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK2-00061K-01 for ; Fri, 19 Apr 2002 23:53:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:38 +0200 (CEST) Received: (qmail 15305 invoked by uid 0); 19 Apr 2002 20:01:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 19 Apr 2002 20:01:02 -0000 Received: by moria.seul.org (Postfix) id 746F2146810; Fri, 19 Apr 2002 16:01:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F3CF6146814; Fri, 19 Apr 2002 16:01:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-3-163.abo.wanadoo.fr [217.128.160.163]) by moria.seul.org (Postfix) with ESMTP id AC25F146810 for ; Fri, 19 Apr 2002 16:00:58 -0400 (EDT) Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16yeYh-0006Aw-00 for ; Fri, 19 Apr 2002 22:00:39 +0200 Date: Fri, 19 Apr 2002 22:00:39 +0200 From: djrom To: f-cpu@seul.org Subject: Re: Re: Rep:Re: [f-cpu] new langage ? Message-Id: <20020419220039.62e8af8b.pash.cracken@free.fr> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >On Fri, Apr 19, 2002 at 08:24:55AM +0000, Nicolas Boulay wrote: >> New language of a higher level is really needed to really have a code >> portability without the problem of performance. >> >> BUT it's really hard to devellop a all new language ( or look at "D" ). >> >> I personnaly like the way systemC work. It's only a "big" librairy for >> C++. We just have to design a librairy that work well with SIMD. >> >> In c++, one librairy do such thing : STL. If we port STL (in asm) for >> the fpu we could accelerate all soon written programme and future one. >> >> I think it's the better cost/benefit ratio. >I really don't want to be tied to a single programming language. No >matter what it's called or who invented it. >In order to support arbitrary languages, we need a native code generator >that transforms an intermediate code representation into F-CPU machine >code, and maybe also performs machine-dependent optimizations. I suggest >we concentrate on this piece and worry about the language-specific >front-end (which generates the intermediate code) later. >That is, we have two things to do: > - define an appropriate (universally usable) intermediate code > - write code that maps it to F-CPU instructions you're totally right, I think. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pash.cracken@free.fr Fri Apr 19 22:14:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK3-00061K-00 for ; Fri, 19 Apr 2002 23:53:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:39 +0200 (CEST) Received: (qmail 26956 invoked by uid 0); 19 Apr 2002 20:14:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 19 Apr 2002 20:14:56 -0000 Received: by moria.seul.org (Postfix) id 29DC5146813; Fri, 19 Apr 2002 16:14:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 234F7146817; Fri, 19 Apr 2002 16:14:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-3-163.abo.wanadoo.fr [217.128.160.163]) by moria.seul.org (Postfix) with ESMTP id 59A0F146813 for ; Fri, 19 Apr 2002 16:14:53 -0400 (EDT) Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16yemA-0006B7-00 for ; Fri, 19 Apr 2002 22:14:34 +0200 Date: Fri, 19 Apr 2002 22:14:34 +0200 From: djrom To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Winograd DCT on my seul.org account Message-Id: <20020419221434.07b3780d.pash.cracken@free.fr> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >On Fri, Apr 19, 2002 at 09:09:49AM +0200, djrom wrote: >[...] >> it cause the problem of gcc to (re)raise. optimisations for FC0 are very >> different from usual optimisations, even for RISC processors. I don't >> know the real structure of gcc, but I guess it'll be very difficult to >> put FC0 tricks without breaking the portability, no ? I even wonder if >> rewriting a new compiler won't be much easier than trying to add such >> things in gcc, if we want the compiler to be good. we don't want to see >> the F-Cpu ends like the PIV, used at less than 30%, right ? >I guess that writing a new C compiler will indeed be easier than >hacking gcc. that's what I meant. >> moreover, we should perhaps think about another langage to be used >> on modern processors. C is very limited in his expressivity, so the >> operations like SIMD or "real" optimisations put a ton of work on the >> compiler's shoulders. it shouldn't just try to optimise, but it must even >> try to *understand* what the programmers meant. is there a langage really >> usable for modern RISC processors ? maybe we should try to return to lisp >> or ML, or something like that, no ? that's could also be a way to promote >> new langages: I don't want 2030's processors to be always coded in C ! :-) >And I don't want to be unable to code in C in 2030. I like lisp, but... I haven't said, that we should stop to write C compilers ! :-) I was talking about the *main* langage. >C is very limited in its expressivity? Huh? yes. you use a lots of tricks in C (casting, use of void *, "bare metal" objects with structures, intensive use of macros, ...) to hide the limited level of abstraction of the langage. look at a macro-assembler (like nasm), you'll see that C is very near of that, with just the portability advantage. I'm not saying, that C is at the same level than assembly langage, but it's clear, that C is too low-level for a modern computer, who's more complex than a old one, right ? so, as the complexity increase, you need a more abstracted langage, to avoid the necessity of very nasty tricks. if a langage needs these tricks, he's limited in its expressivity. C needs these tricks. >> if *we* don't promote new langages, we won't be able to count on Intel >> to do it ! :-) >Our goal is not to promote programming languages. Neither is it Intel's. Our goal is to improve computer science isn't it ? :-) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 20 03:37:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK6-00061K-00 for ; Fri, 19 Apr 2002 23:53:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:42 +0200 (CEST) Received: (qmail 9475 invoked by uid 0); 19 Apr 2002 20:29:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Apr 2002 20:29:12 -0000 Received: by moria.seul.org (Postfix) id 8F165146814; Fri, 19 Apr 2002 16:29:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 713D7146819; Fri, 19 Apr 2002 16:29:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 09FDF146814 for ; Fri, 19 Apr 2002 16:29:10 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-1.dial.proxad.net [62.147.156.1]) by postfix3-2.free.fr (Postfix) with ESMTP id 08EA118377 for ; Fri, 19 Apr 2002 22:29:08 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Some question about the update Date: Sat, 20 Apr 2002 03:37:50 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204200337.50475.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have started to update the manual with the two post that Michael give to me, but for certain case it's not really clear. First the FPU. Is it SIMD or not ? (problem with exeption and rouding for example, and perhaps a problem of size). Or is it SIMD hidden into the EU ? (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? date >from Wed, 15 Aug 2001 23:12:27 +0200). I don't understand the meaning of fexp with a base ? What did that mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead of flog ? I have added fcmpl[e] instructions in level-1 floating-point for compare instruction. Finally, did we add an new f2f instruction for FP conversions (32bits | 64bits -> 32 bits | 64 bits) ? About LNS: what are the rounding method (or mode) ? same as FPU ? And did we add 16 bits representation (like nicO suggestion ?) ? About memory, I didn't understand the problem with store[f] ? Can you explain it to me ? And did we add a new flag for a special immediate operand (6 bits value + 2 bits left-shift, as Michael suggest ?) I did'nt understand why did we specify into the CPU a fixed memory hierarchichies (see cachemem). I think that we could say that 0 will be the quicker and 7 the slower, or something like that ? And did we add a 'cachecode r1' instruction that will perform a prefetch in I-Cache before a jmp (in a function call for example like in Michael's C++ sample). And about the storem/loadm, I have update with the new form you give (I have read gcc documentation, and it's exactly the called form it need, so it will be easy to use for a compiler). But I think that I must remove any reference to SRB mechanism, because SRB is done in physical address space (no trap) and the storem/loadm must be done in virtual address space (trap problem). An other point about this instruction, did we add the 2 registers form ? We now have a unconditionnal move, but is it a alias for 'movez r0, r2, r1' or something else ? In the instruction set I have updated bitop[i]. I think that I must update bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'. An other question is about nop function, actually it's specified as a movez r0, r0, r0 that must be coded as a 0x00000000 in hardware, but must I change it so that it became 'nor r0, r2, r1' or 'xnor r0, r2, r1' ? (I don't understand this change). And I didn't understand the effect of widen new instruction. I don't understand if it will take 2 cycles and only replace two separated instructions or if it does something more. The not instruction did not exist anymore, right ? So it became an alias, but what is the better choice for this alias ? At least, for jmpa, it's name is now jmp, right ? Can someone explain to me the new jmp instruction, I currently didn't understand the manual definition. I think, that a good start for an update, if I miss something or you want to add something, add ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 20 03:42:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16ygK7-00061K-00 for ; Fri, 19 Apr 2002 23:53:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Apr 2002 23:53:43 +0200 (CEST) Received: (qmail 9783 invoked by uid 0); 19 Apr 2002 20:29:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 19 Apr 2002 20:29:21 -0000 Received: by moria.seul.org (Postfix) id 970F914681F; Fri, 19 Apr 2002 16:29:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 94ACD14681A; Fri, 19 Apr 2002 16:29:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 617EF146817 for ; Fri, 19 Apr 2002 16:29:20 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-1.dial.proxad.net [62.147.156.1]) by postfix3-2.free.fr (Postfix) with ESMTP id 1B3B9183A8 for ; Fri, 19 Apr 2002 22:29:11 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Always problem with SIMD and RC5 Date: Sat, 20 Apr 2002 03:42:25 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204200342.25129.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I always have a problem with my final test in my RC5 algorithm. I don't find a way to know the number of chunk or the current max size of the SIMD registers. Perhaps did we need to add two new SR : SR_REGISTER_SIZE_MAX = the maximum size of a register in SIMD mode SR_REGISTER_CURRENT_SIZE = the current limit. (If thing that both a required, because we need to first know in wich state we are and then change the value arcoding to the CPU and the algorithm) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 20 04:55:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl58-00018C-00 for ; Sat, 20 Apr 2002 04:58:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:34 +0200 (CEST) Received: (qmail 789 invoked by uid 0); 19 Apr 2002 21:38:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Apr 2002 21:38:46 -0000 Received: by moria.seul.org (Postfix) id 6E29E14681A; Fri, 19 Apr 2002 17:38:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 440B1146820; Fri, 19 Apr 2002 17:38:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id B7C6C14681A for ; Fri, 19 Apr 2002 17:38:44 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-1.dial.proxad.net [62.147.156.1]) by postfix3-2.free.fr (Postfix) with ESMTP id 570E41809D for ; Fri, 19 Apr 2002 23:38:43 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Sat, 20 Apr 2002 04:55:07 +0200 X-Mailer: KMail [version 1.4] References: <20020419090949.20187ae9.pash.cracken@free.fr> <20020419120139.32825@thrai.stud.uni-hannover.de> In-Reply-To: <20020419120139.32825@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204200455.07883.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > it cause the problem of gcc to (re)raise. optimisations for FC0 are very > > different from usual optimisations, even for RISC processors. I don't > > know the real structure of gcc, but I guess it'll be very difficult to > > put FC0 tricks without breaking the portability, no ? I even wonder if > > rewriting a new compiler won't be much easier than trying to add such > > things in gcc, if we want the compiler to be good. we don't want to see > > the F-Cpu ends like the PIV, used at less than 30%, right ? > > I guess that writing a new C compiler will indeed be easier than > hacking gcc. Euh, well,... I didn't agry with you, writing a C compiler is very hard (It actually didn't exist any bison grammar for C). And a lot of thing in the C/C++ norme are not clear specified (It's explain the problem with the 3.0.x version of gcc). So when you want to write your own C compiler, you must test it with a lot of different software and... have a lot of problem. And I recently read the gcc documentation about how to write a backend to gcc and it's not easy, but we can have some possibility and we could have some good performance. The only problem is with SIMD and perhaps some optimisation with our cray like load/store. I thing that nicolas that says to me that for the 3.1 release they will have some SIMD optimisation. With our clean ASM, it will certainly be possible to use it. Last point, if we write one backend, we can have all the gcc frontend working on our CPU, and that much more interesting. That's only my point of view, and for me coding a C/C++ compiler will be a nightmare... A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 20 05:05:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5C-00018C-00 for ; Sat, 20 Apr 2002 04:58:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:38 +0200 (CEST) Received: (qmail 17829 invoked by uid 0); 19 Apr 2002 21:49:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Apr 2002 21:49:15 -0000 Received: by moria.seul.org (Postfix) id 298B31467F5; Fri, 19 Apr 2002 17:49:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AED79146820; Fri, 19 Apr 2002 17:49:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 1E74F1467F5 for ; Fri, 19 Apr 2002 17:49:11 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-1.dial.proxad.net [62.147.156.1]) by postfix3-2.free.fr (Postfix) with ESMTP id 7134B183D3 for ; Fri, 19 Apr 2002 23:49:05 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? Date: Sat, 20 Apr 2002 05:05:30 +0200 X-Mailer: KMail [version 1.4] References: <200204190824.3722@th00.opsion.fr> In-Reply-To: <200204190824.3722@th00.opsion.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204200505.30345.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > New language of a higher level is really needed to really have a code > portability without the problem of performance. > > BUT it's really hard to devellop a all new language ( or look at "D" ). > > I personnaly like the way systemC work. It's only a "big" librairy for > C++. We just have to design a librairy that work well with SIMD. > > In c++, one librairy do such thing : STL. If we port STL (in asm) for > the fpu we could accelerate all soon written programme and future one. Well, it's a good idea, but the problem is that the a big part of the STL class are template. That mean that they are compiled with the application, and that will be difficult to optimise them. Of course, class like string must be optimised, and all the libstdc++ can be optimized. But like the libc and perhaps all the basic lib of each language we want to see on our chip. > I think it's the better cost/benefit ratio. We have two way to have better result on our CPU, optimise generic lib and compiler. The two are interesting, and we must not focus only on one of them. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 20 05:10:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5D-00018C-00 for ; Sat, 20 Apr 2002 04:58:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:39 +0200 (CEST) Received: (qmail 2540 invoked by uid 0); 19 Apr 2002 21:53:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Apr 2002 21:53:54 -0000 Received: by moria.seul.org (Postfix) id 9085414681D; Fri, 19 Apr 2002 17:53:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B92C146821; Fri, 19 Apr 2002 17:53:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id B922E14681D for ; Fri, 19 Apr 2002 17:53:52 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-1.dial.proxad.net [62.147.156.1]) by postfix3-2.free.fr (Postfix) with ESMTP id 513B31841E for ; Fri, 19 Apr 2002 23:53:51 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? Date: Sat, 20 Apr 2002 05:10:16 +0200 X-Mailer: KMail [version 1.4] References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> In-Reply-To: <20020419122523.52714@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204200510.16370.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I really don't want to be tied to a single programming language. No > matter what it's called or who invented it. > > In order to support arbitrary languages, we need a native code generator > that transforms an intermediate code representation into F-CPU machine > code, and maybe also performs machine-dependent optimizations. I suggest > we concentrate on this piece and worry about the language-specific > front-end (which generates the intermediate code) later. > > That is, we have two things to do: > > - define an appropriate (universally usable) intermediate code > - write code that maps it to F-CPU instructions So you really want to create your own compiler, you now that gcc actually does all what we need ? It scan/parse the code, then generate a abstract syntax tree and then use the back end specification to translate this tree into asm for this specific architecture. And this translation can do some optimisation. If you want more about gcc backend I think it's chapter 20 of its documentation. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Sat Apr 20 00:12:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5E-00018C-00 for ; Sat, 20 Apr 2002 04:58:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:40 +0200 (CEST) Received: (qmail 27530 invoked by uid 0); 19 Apr 2002 22:15:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 19 Apr 2002 22:15:58 -0000 Received: by moria.seul.org (Postfix) id E8B76146820; Fri, 19 Apr 2002 18:15:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DD7CA146823; Fri, 19 Apr 2002 18:15:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from lvdi.net (unknown [216.24.138.2]) by moria.seul.org (Postfix) with SMTP id 1602D146820 for ; Fri, 19 Apr 2002 18:15:55 -0400 (EDT) Received: from wyrm ([151.201.26.197]) by lvdi.net ; Fri, 19 Apr 2002 15:15:51 2000 PDT Received: from lee by wyrm with local (Exim 3.35 #1 (Debian)) id 16ygbx-0002Ze-00 for ; Fri, 19 Apr 2002 18:12:09 -0400 Date: Fri, 19 Apr 2002 18:12:09 -0400 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Message-ID: <20020419221209.GA9888@wyrm> References: <20020419090949.20187ae9.pash.cracken@free.fr> <20020419120139.32825@thrai.stud.uni-hannover.de> <200204200455.07883.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200204200455.07883.cedric.bail@free.fr> User-Agent: Mutt/1.3.28i From: Lee Salzman Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 04:55:07AM +0200, cedric wrote: > > > it cause the problem of gcc to (re)raise. optimisations for FC0 are very > > > different from usual optimisations, even for RISC processors. I don't > > > know the real structure of gcc, but I guess it'll be very difficult to > > > put FC0 tricks without breaking the portability, no ? I even wonder if > > > rewriting a new compiler won't be much easier than trying to add such > > > things in gcc, if we want the compiler to be good. we don't want to see > > > the F-Cpu ends like the PIV, used at less than 30%, right ? > > > > I guess that writing a new C compiler will indeed be easier than > > hacking gcc. > > Euh, well,... I didn't agry with you, writing a C compiler is very hard (It > actually didn't exist any bison grammar for C). And a lot of thing in the > C/C++ norme are not clear specified (It's explain the problem with the 3.0.x > version of gcc). So when you want to write your own C compiler, you must test > it with a lot of different software and... have a lot of problem. > Writing a decent C/C++ compiler is a horribly big project. Take a look at the different between the output of LCC and GCC on the same input code, and you'll see a huge difference between what a compiler that doesn't spend a few tens of KLOCs on optimizing can do and one that does can do. :) > And I recently read the gcc documentation about how to write a backend to gcc > and it's not easy, but we can have some possibility and we could have some > good performance. The only problem is with SIMD and perhaps some optimisation > with our cray like load/store. Not much of an issue since I already wrote a GCC backend for F-CPU ages ago. > I thing that nicolas that says to me that for the 3.1 release they will have > some SIMD optimisation. With our clean ASM, it will certainly be possible to > use it. This is really a more sensible idea than going and writing an overall worse compiler than GCC just for a few SIMD optimizations. > Last point, if we write one backend, we can have all the gcc frontend > working on our CPU, and that much more interesting. > That's only my point of view, and for me coding a C/C++ compiler will > be a nightmare... > C/C++ are a nightmare to write fast compilers for in general. Memory aliasing and side-effects fuck up just about every optimization you can think of unless you do some pretty heavy and complex analyses beforehand. > > A+ > Cedric Lee ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 00:20:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5F-00018C-00 for ; Sat, 20 Apr 2002 04:58:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:41 +0200 (CEST) Received: (qmail 22923 invoked by uid 0); 19 Apr 2002 22:20:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Apr 2002 22:20:54 -0000 Received: by moria.seul.org (Postfix) id 0ACB7146823; Fri, 19 Apr 2002 18:20:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 04D97146821; Fri, 19 Apr 2002 18:20:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a034.home.uni-hannover.de [130.75.232.34]) by moria.seul.org (Postfix) with ESMTP id 23159146821 for ; Fri, 19 Apr 2002 18:20:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01203; Sat, 20 Apr 2002 00:20:50 +0200 Message-ID: <20020420002050.46424@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 00:20:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419221434.07b3780d.pash.cracken@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020419221434.07b3780d.pash.cracken@free.fr>; from djrom on Fri, Apr 19, 2002 at 10:14:34PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 19, 2002 at 10:14:34PM +0200, djrom wrote: [...] > >And I don't want to be unable to code in C in 2030. I like lisp, but... > I haven't said, that we should stop to write C compilers ! :-) I was > talking about the *main* langage. There ain't no such thing as a `main' language. > >C is very limited in its expressivity? Huh? > > yes. you use a lots of tricks in C (casting, use of void *, "bare > metal" objects with structures, intensive use of macros, ...) to hide the > limited level of abstraction of the langage. look at a macro-assembler > (like nasm), you'll see that C is very near of that, with just the > portability advantage. I'm not saying, that C is at the same level > than assembly langage, but it's clear, that C is too low-level for a > modern computer, who's more complex than a old one, right ? so, as the > complexity increase, you need a more abstracted langage, to avoid the > necessity of very nasty tricks. if a langage needs these tricks, he's > limited in its expressivity. C needs these tricks. You obviously haven't seen VHDL yet. And we obviously have different definitions of expressivity (wasn't it called expressiveness? I don't remember). > >> if *we* don't promote new langages, we won't be able to count on Intel > >> to do it ! :-) > > >Our goal is not to promote programming languages. Neither is it Intel's. > Our goal is to improve computer science isn't it ? :-) That's definitely not my goal. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 00:43:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5G-00018C-00 for ; Sat, 20 Apr 2002 04:58:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:42 +0200 (CEST) Received: (qmail 25577 invoked by uid 0); 19 Apr 2002 22:43:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 19 Apr 2002 22:43:10 -0000 Received: by moria.seul.org (Postfix) id 427D91467F2; Fri, 19 Apr 2002 18:43:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37A961467F9; Fri, 19 Apr 2002 18:43:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a034.home.uni-hannover.de [130.75.232.34]) by moria.seul.org (Postfix) with ESMTP id E7E8C1467F2 for ; Fri, 19 Apr 2002 18:43:04 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01262; Sat, 20 Apr 2002 00:43:04 +0200 Message-ID: <20020420004304.25294@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 00:43:04 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update References: <200204200337.50475.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204200337.50475.cedric.bail@free.fr>; from cedric on Sat, Apr 20, 2002 at 03:37:50AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 03:37:50AM +0200, cedric wrote: > Hi, > > I have started to update the manual with the two post that Michael give to > me, but for certain case it's not really clear. > > First the FPU. Is it SIMD or not ? (problem with exeption and rouding for > example, and perhaps a problem of size). Or is it SIMD hidden into the EU ? > (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? date > from Wed, 15 Aug 2001 23:12:27 +0200). > I don't understand the meaning of fexp with a base ? What did that > mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead of flog ? That's what I suggested (or similar, at least). There's no real need for the third argument. Whether the instructions are base-e (natural logarithm), base-10 or base-2 doesn't matter much either -- we should choose a base that's easy to implement. > I have added fcmpl[e] instructions in level-1 floating-point for compare > instruction. I'd rather pick `fcmpe' (equal) and `fcmpl' (less). Remember that a floating-point number may have more than one representation (that is, r1 xor r2 may not be zero, but their values are nevertheless the same). `fcmple' (and its counterpart `cmple'), on the other hand, is redundant because the expressions a < b b > a !(a >= b) !(b <= a) are all equivalent (provided neither a nor b is a NaN). > Finally, did we add an new f2f instruction for FP conversions (32bits | > 64bits -> 32 bits | 64 bits) ? We should. > About LNS: what are the rounding method (or mode) ? same as FPU ? And did > we add 16 bits representation (like nicO suggestion ?) ? > > About memory, I didn't understand the problem with store[f] ? Can you explain > it to me ? And did we add a new flag for a special immediate operand (6 bits > value + 2 bits left-shift, as Michael suggest ?) I guess that was operand order... you can leave it as it is. > I did'nt understand why did we specify into the CPU a fixed memory > hierarchichies (see cachemem). I think that we could say that 0 will be the > quicker and 7 the slower, or something like that ? And did we add a 'cachecode > r1' instruction that will perform a prefetch in I-Cache before a jmp (in a > function call for example like in Michael's C++ sample). > And about the storem/loadm, I have update with the new form you give > (I have read gcc documentation, and it's exactly the called form it need, so > it will be easy to use for a compiler). But I think that I must remove any > reference to SRB mechanism, because SRB is done in physical address space > (no trap) and the storem/loadm must be done in virtual address space (trap > problem). An other point about this instruction, did we add the 2 registers > form ? > We now have a unconditionnal move, but is it a alias for 'movez r0, > r2, r1' or something else ? `movez r0, r1, r2' and `move r1, r2' are equivalent (that is, they're the same instruction). > In the instruction set I have updated bitop[i]. I think that I must update > bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'. That should read `r1 = bit_reverse(r2) >> (size-r3-1)', if I remember correctly. The other version is affected by the register size (which is bad). > An other question > is about nop function, actually it's specified as a movez r0, r0, r0 that > must be coded as a 0x00000000 in hardware, but must I change it so that it > became 'nor r0, r2, r1' or 'xnor r0, r2, r1' ? (I don't understand this > change). I guess you mixed up `nop' and `not'. Both `nor ...' and `xnor ...' are equivalent to the (non-existing) `not r2, r1'. Actually, there are a lot more ways to write `not'. > And I didn't understand the effect of widen new instruction. I don't > understand if it will take 2 cycles and only replace two separated > instructions or if it does something more. It should take only 1 cycle (but isn't implemented yet). Otherwise, we could also use shift/mask operations. > The not instruction did not exist anymore, right ? So it became an > alias, but what is the better choice for this alias ? See above -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Apr 20 00:41:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5H-00018C-00 for ; Sat, 20 Apr 2002 04:58:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:43 +0200 (CEST) Received: (qmail 26023 invoked by uid 0); 19 Apr 2002 22:43:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 19 Apr 2002 22:43:24 -0000 Received: by moria.seul.org (Postfix) id 4A1031467F7; Fri, 19 Apr 2002 18:43:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E6581467FD; Fri, 19 Apr 2002 18:43:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 437EE1467F7 for ; Fri, 19 Apr 2002 18:43:22 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3JMib4l089235 for ; Fri, 19 Apr 2002 16:44:38 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC09D04.3293CEF9@jetnet.ab.ca> Date: Fri, 19 Apr 2002 16:41:08 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419221434.07b3780d.pash.cracken@free.fr> <20020420002050.46424@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Fri, Apr 19, 2002 at 10:14:34PM +0200, djrom wrote: > [...] > > >And I don't want to be unable to code in C in 2030. I like lisp, but... > > I haven't said, that we should stop to write C compilers ! :-) I was > > talking about the *main* langage. > > There ain't no such thing as a `main' language. > > > >C is very limited in its expressivity? Huh? > > > > yes. you use a lots of tricks in C (casting, use of void *, "bare > > metal" objects with structures, intensive use of macros, ...) to hide the > > limited level of abstraction of the langage. look at a macro-assembler > > (like nasm), you'll see that C is very near of that, with just the > > portability advantage. I'm not saying, that C is at the same level > > than assembly langage, but it's clear, that C is too low-level for a > > modern computer, who's more complex than a old one, right ? so, as the > > complexity increase, you need a more abstracted langage, to avoid the > > necessity of very nasty tricks. if a langage needs these tricks, he's > > limited in its expressivity. C needs these tricks. > > You obviously haven't seen VHDL yet. > > And we obviously have different definitions of expressivity > (wasn't it called expressiveness? I don't remember). > > > >> if *we* don't promote new langages, we won't be able to count on Intel > > >> to do it ! :-) > > > > >Our goal is not to promote programming languages. Neither is it Intel's. > > Our goal is to improve computer science isn't it ? :-) > > That's definitely not my goal. > I think the GOAL of the F-CPU is good assembler code. If a person can code great for it then a high level compiler can do wonders. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 00:51:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5H-00018C-01 for ; Sat, 20 Apr 2002 04:58:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:43 +0200 (CEST) Received: (qmail 3389 invoked by uid 0); 19 Apr 2002 22:51:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Apr 2002 22:51:41 -0000 Received: by moria.seul.org (Postfix) id D7DCE1467F9; Fri, 19 Apr 2002 18:51:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D3AC9146803; Fri, 19 Apr 2002 18:51:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a034.home.uni-hannover.de [130.75.232.34]) by moria.seul.org (Postfix) with ESMTP id C867D1467F9 for ; Fri, 19 Apr 2002 18:51:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01287; Sat, 20 Apr 2002 00:51:35 +0200 Message-ID: <20020420005135.04990@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 00:51:35 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419090949.20187ae9.pash.cracken@free.fr> <20020419120139.32825@thrai.stud.uni-hannover.de> <200204200455.07883.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204200455.07883.cedric.bail@free.fr>; from cedric on Sat, Apr 20, 2002 at 04:55:07AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 04:55:07AM +0200, cedric wrote: [...] > > I guess that writing a new C compiler will indeed be easier than > > hacking gcc. > > Euh, well,... I didn't agry with you, writing a C compiler is very hard (It > actually didn't exist any bison grammar for C). And a lot of thing in the > C/C++ norme are not clear specified (It's explain the problem with the 3.0.x > version of gcc). So when you want to write your own C compiler, you must test > it with a lot of different software and... have a lot of problem. I have yacc/bison grammars for both C89 and C99 (the grammar for several versions of GNU C is also available, of course). The problem with gcc 3 is that some former GNU extensions are now also defined in C99 -- but with slightly different semantics (e.g. `inline'). > And I recently read the gcc documentation about how to write a backend to gcc > and it's not easy, but we can have some possibility and we could have some > good performance. The only problem is with SIMD and perhaps some optimisation > with our cray like load/store. > I thing that nicolas that says to me that for the 3.1 release they will have > some SIMD optimisation. With our clean ASM, it will certainly be possible to > use it. > Last point, if we write one backend, we can have all the gcc frontend > working on our CPU, and that much more interesting. > That's only my point of view, and for me coding a C/C++ compiler will > be a nightmare... When I see a fully functional F-CPU gcc backend that creates reasonably efficient code, I will believe that it's possible. Writing such a beast is what I call a nightmare (I don't like hacking other people's ugly code). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 01:04:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5L-00018C-00 for ; Sat, 20 Apr 2002 04:58:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:47 +0200 (CEST) Received: (qmail 11109 invoked by uid 0); 19 Apr 2002 23:04:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 19 Apr 2002 23:04:47 -0000 Received: by moria.seul.org (Postfix) id 70CE41467FD; Fri, 19 Apr 2002 19:04:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6150C146805; Fri, 19 Apr 2002 19:04:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a034.home.uni-hannover.de [130.75.232.34]) by moria.seul.org (Postfix) with ESMTP id ED7DC1467FD for ; Fri, 19 Apr 2002 19:04:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01332; Sat, 20 Apr 2002 01:04:41 +0200 Message-ID: <20020420010441.40581@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 01:04:41 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> <200204200510.16370.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204200510.16370.cedric.bail@free.fr>; from cedric on Sat, Apr 20, 2002 at 05:10:16AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 05:10:16AM +0200, cedric wrote: [...] > So you really want to create your own compiler, you now that gcc actually does > all what we need ? It scan/parse the code, then generate a abstract syntax > tree and then use the back end specification to translate this tree into asm > for this specific architecture. > And this translation can do some optimisation. If you want more about gcc > backend I think it's chapter 20 of its documentation. I've still got a printed copy of the gcc 1.3x manual somewhere... But I don't think that gcc `does all we need'. I've run benchmarks (including SPEC CPU95 and CPU2000) on Intel, Athlon, Alpha, PowerPC, PA-RISC and SPARC (did I miss any?) -- believe me, I *know* how bad gcc-generated code performs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 01:32:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5M-00018C-00 for ; Sat, 20 Apr 2002 04:58:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:48 +0200 (CEST) Received: (qmail 7387 invoked by uid 0); 19 Apr 2002 23:25:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 19 Apr 2002 23:25:51 -0000 Received: by moria.seul.org (Postfix) id CD1C61467FA; Fri, 19 Apr 2002 19:25:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C3791146803; Fri, 19 Apr 2002 19:25:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 4D87F1467FA for ; Fri, 19 Apr 2002 19:25:49 -0400 (EDT) Received: from f-cpu.org (kdl16-18.n.club-internet.fr [213.44.18.18]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 93A771703 for ; Sat, 20 Apr 2002 01:25:46 +0200 (CEST) Message-ID: <3CC0A904.F725C56B@f-cpu.org> Date: Sat, 20 Apr 2002 01:32:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419090949.20187ae9.pash.cracken@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! djrom wrote: > this is a very interesting paper. but what haven't you written the > code in assembler ? the C code looks like assembler in any way, so ... :-) you answered the question :-) i also spoke a bit about this in one place. > it cause the problem of gcc to (re)raise. optimisations for FC0 are > very different from usual optimisations, even for RISC processors. > I don't know the real structure of gcc, but I guess it'll be very difficult > to put FC0 tricks without breaking the portability, no ? I even wonder > if rewriting a new compiler won't be much easier than trying to add > such things in gcc, if we want the compiler to be good. we don't > want to see the F-Cpu ends like the PIV, used at less than 30%, right ? it is well-known that compiled code has at least 30% overhead. then the user comes in and inputs "portable" code and you loose another factor. Then you don't use the advanced features like SIMD and you loose yet another factor. Finally, if the compiler doesn't "understand" how to write efficient code (for example, jump and data prefetch !) then you have a running time that is at least this of other CPUs. But the compiler must be at least as smart as the processor, though this is not granted yet. > moreover, we should perhaps think about another langage to be used > on modern processors. C is very limited in his expressivity, so the > operations like SIMD or "real" optimisations put a ton of work on > the compiler's shoulders. it shouldn't just try to optimise, but > it must even try to *understand* what the programmers meant. is > there a langage really usable for modern RISC processors ? If you except FORTRAN (F95 and later are pretty good), C is used everywhere performance is at stake. And assembly langage, too. > maybe we should try to return to lisp or ML, or something like that, no ? mais après vous, mon cher ;-) > that's could also be a way to promote new langages: I don't want > 2030's processors to be always coded in C ! :-) neither do i but i don't have much power. A VHDL derivative would be way tooooooooo cool (funny, from ADA to VHDL and back to software :-D) but i can't do everything ... IIRC ADA was ported to the GNU framework so we could reuse the frontend and use another backend. Adding VHDL semantics could make programming become a completely different experience. > if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-) i can't even count on myself. -------------------------------------------------------------------- However i had an idea during a private discussion with Cedric... He probably won't like that i speak again about it, but i like this idea because it is a good compromise : efficient and realistic. The idea is to use GCC and give a very simplistic machine description. So we won't have to mess with GCC's internals and problems. GCC will output assembly langage for our simplistic machine (63 registers + 0, post-incrememnted-only addressing, direct register jump etc.) but all the "dirty optimisation work" will be done before assembly. The GCC code would be translated to real instructions and some global analysis will be done, for example for computing optimal pointer increments and prefetching the jump destinations well in advance... so GCC won't care and F-CPU specific stuff will be kept separate. This is the easiest solution which allows everybody to use most existing sources, not having tough problems with GCC and create our own optimisation techniques. We can start with a "dumb assembler" with a 1-to-1 translation, and add optimisations progressively. -------------------------------------------------------------------- at least, it's a better effort than doing our own compiler from scratch, no ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Softcore@web.de Sat Apr 20 01:42:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16yl5M-00018C-01 for ; Sat, 20 Apr 2002 04:58:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 20 Apr 2002 04:58:48 +0200 (CEST) Received: (qmail 14813 invoked by uid 0); 19 Apr 2002 23:44:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Apr 2002 23:44:09 -0000 Received: by moria.seul.org (Postfix) id 804E3146803; Fri, 19 Apr 2002 19:44:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 65CEC146806; Fri, 19 Apr 2002 19:44:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by moria.seul.org (Postfix) with ESMTP id C283A146803 for ; Fri, 19 Apr 2002 19:44:07 -0400 (EDT) Received: from [80.128.10.173] (helo=alex) by smtp.web.de with smtp (WEB.DE(Exim) 4.44 #50) id 16yi2w-0003pf-00 for f-cpu@seul.org; Sat, 20 Apr 2002 01:44:06 +0200 Message-ID: <002e01c1e7fc$185b5c60$c620a8c0@alex> From: "Alexander Herz" To: References: <20020419220039.62e8af8b.pash.cracken@free.fr> Subject: Re: Re: Rep:Re: [f-cpu] new langage ? Date: Sat, 20 Apr 2002 01:42:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just a little side note from an 'outsider'.. Developing a new language is far more tricky than it seams at first glance.. There are TONS of details you need to consider..and you will miss most of them at your first try.. So you need many ppl who test your language and all ppl who want to code for fcpu will have to learn a new language.. If you want to make fcpu popular..than make it as easy to use as possible.. so go for standarts..C/C++ and java maybe .. later on you can introduce other non standart languages.. and those who realy want them can use them.. Alex ----- Original Message ----- From: djrom To: Sent: Friday, April 19, 2002 10:00 PM Subject: Re: Re: Rep:Re: [f-cpu] new langage ? > >On Fri, Apr 19, 2002 at 08:24:55AM +0000, Nicolas Boulay wrote: > >> New language of a higher level is really needed to really have a code > >> portability without the problem of performance. > >> > >> BUT it's really hard to devellop a all new language ( or look at "D" ). > >> > >> I personnaly like the way systemC work. It's only a "big" librairy for > >> C++. We just have to design a librairy that work well with SIMD. > >> > >> In c++, one librairy do such thing : STL. If we port STL (in asm) for > >> the fpu we could accelerate all soon written programme and future one. > >> > >> I think it's the better cost/benefit ratio. > > >I really don't want to be tied to a single programming language. No > >matter what it's called or who invented it. > > >In order to support arbitrary languages, we need a native code generator > >that transforms an intermediate code representation into F-CPU machine > >code, and maybe also performs machine-dependent optimizations. I suggest > >we concentrate on this piece and worry about the language-specific > >front-end (which generates the intermediate code) later. > > >That is, we have two things to do: > > > - define an appropriate (universally usable) intermediate code > > - write code that maps it to F-CPU instructions > > you're totally right, I think. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Apr 20 08:01:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5i9-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:13 +0200 (CEST) Received: (qmail 15240 invoked by uid 0); 20 Apr 2002 06:13:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 20 Apr 2002 06:13:19 -0000 Received: by moria.seul.org (Postfix) id 65BCA14680A; Sat, 20 Apr 2002 02:10:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5721D146806; Sat, 20 Apr 2002 02:10:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 08C99146800 for ; Sat, 20 Apr 2002 02:10:17 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ynw5-0005qX-00; Sat, 20 Apr 2002 08:01:25 +0200 Date: Sat, 20 Apr 2002 08:01:24 +0200 (MEST) From: Juergen Goeritz To: Yann Guidon Cc: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC0A904.F725C56B@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! this is indeed a very, very convincing idea! Provide the 'fitter' for the processor with the processor. YESSS! It would be similar to todays FPGAs tool chains! You can use a 'global tool' like synplicity or whatever and run the device fitter from the vendor to create fpga netlist. Now you take gcc (or the ones for ada, f, pas and so on) and run the f-cpu optimization fitter as a second step. And I would love to see the optimization procedure as a part of the loader... Then there were the chance for portability at maxperf. And you wouldn't have to worry about f-cpu type during compilation... And the hardware guys must think about how software is to be optimized - what amount of synergy effects :-) And finally I don't see problems using gcc as a frontend tool only. JG On Sat, 20 Apr 2002, Yann Guidon wrote: >> if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-) >i can't even count on myself. > >-------------------------------------------------------------------- >However i had an idea during a private discussion with Cedric... >He probably won't like that i speak again about it, but i like >this idea because it is a good compromise : efficient and realistic. > >The idea is to use GCC and give a very simplistic machine description. >So we won't have to mess with GCC's internals and problems. >GCC will output assembly langage for our simplistic machine >(63 registers + 0, post-incrememnted-only addressing, direct register jump etc.) >but all the "dirty optimisation work" will be done before assembly. >The GCC code would be translated to real instructions and some global analysis >will be done, for example for computing optimal pointer increments and prefetching >the jump destinations well in advance... so GCC won't care and F-CPU specific stuff >will be kept separate. > >This is the easiest solution which allows everybody to use most existing sources, >not having tough problems with GCC and create our own optimisation techniques. >We can start with a "dumb assembler" with a 1-to-1 translation, and add optimisations >progressively. >-------------------------------------------------------------------- > >at least, it's a better effort than doing our own compiler from scratch, no ? > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 09:00:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5i9-0006Ap-01 for ; Sun, 21 Apr 2002 03:00:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:13 +0200 (CEST) Received: (qmail 10903 invoked by uid 0); 20 Apr 2002 06:53:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 20 Apr 2002 06:53:53 -0000 Received: by moria.seul.org (Postfix) id 6A9CA14680B; Sat, 20 Apr 2002 02:53:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4FFBB14680F; Sat, 20 Apr 2002 02:53:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id CEBDA14680B for ; Sat, 20 Apr 2002 02:53:51 -0400 (EDT) Received: from f-cpu.org (kdl11-63.n.club-internet.fr [213.44.9.63]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 37F9916C0 for ; Sat, 20 Apr 2002 08:53:50 +0200 (CEST) Message-ID: <3CC11207.4A45006D@f-cpu.org> Date: Sat, 20 Apr 2002 09:00:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> <200204200510.16370.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: > > I really don't want to be tied to a single programming language. No > > matter what it's called or who invented it. > > > > In order to support arbitrary languages, we need a native code generator > > that transforms an intermediate code representation into F-CPU machine > > code, and maybe also performs machine-dependent optimizations. I suggest > > we concentrate on this piece and worry about the language-specific > > front-end (which generates the intermediate code) later. > > > > That is, we have two things to do: > > > > - define an appropriate (universally usable) intermediate code > > - write code that maps it to F-CPU instructions > So you really want to create your own compiler, you now that gcc actually does > all what we need ? It scan/parse the code, then generate a abstract syntax > tree and then use the back end specification to translate this tree into asm > for this specific architecture. > And this translation can do some optimisation. If you want more about gcc > backend I think it's chapter 20 of its documentation. Two or three years ago, there a paper called "Porting GCC for Dummies" ("PGCCFD") in PostScript. does anyone know where it is ? > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 09:00:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iA-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:14 +0200 (CEST) Received: (qmail 30244 invoked by uid 0); 20 Apr 2002 06:53:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 20 Apr 2002 06:53:54 -0000 Received: by moria.seul.org (Postfix) id CE0BB146805; Sat, 20 Apr 2002 02:53:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9EFE514680B; Sat, 20 Apr 2002 02:53:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 3F37F146805 for ; Sat, 20 Apr 2002 02:53:50 -0400 (EDT) Received: from f-cpu.org (kdl11-63.n.club-internet.fr [213.44.9.63]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 279D116B4 for ; Sat, 20 Apr 2002 08:53:48 +0200 (CEST) Message-ID: <3CC11205.DF8CEB7@f-cpu.org> Date: Sat, 20 Apr 2002 09:00:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Always problem with SIMD and RC5 References: <200204200342.25129.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, cedric wrote: > I always have a problem with my final test in my RC5 algorithm. I don't find a > way to know the number of chunk or the current max size of the SIMD > registers. Perhaps did we need to add two new SR : > SR_REGISTER_SIZE_MAX = the maximum size of a register in SIMD mode This already exists, it's SR_MAX_SIZE > SR_REGISTER_CURRENT_SIZE = the current limit. > (If thing that both a required, because we need to first know in wich state we > are and then change the value arcoding to the CPU and the algorithm) if you want to do it "the hard way", take the maximum value that you find in SR_SIZE_0 to SR_SIZE_3. But by convention, you can decide to put the maximum size in SR_SIZE_3, which usually corresponds to size=64 bits when the CPU is limited to 64 bits. hope this old trick helps, > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 09:58:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iB-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:15 +0200 (CEST) Received: (qmail 10266 invoked by uid 0); 20 Apr 2002 07:52:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 20 Apr 2002 07:52:06 -0000 Received: by moria.seul.org (Postfix) id 34247146806; Sat, 20 Apr 2002 03:52:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 20BBC146817; Sat, 20 Apr 2002 03:52:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id AE097146806 for ; Sat, 20 Apr 2002 03:52:03 -0400 (EDT) Received: from f-cpu.org (kdl16-128.n.club-internet.fr [213.44.18.128]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 772C916EF for ; Sat, 20 Apr 2002 09:51:59 +0200 (CEST) Message-ID: <3CC11FAA.27489BE6@f-cpu.org> Date: Sat, 20 Apr 2002 09:58:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new files References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Juergen Goeritz wrote: > On Sat, 20 Apr 2002, Yann Guidon wrote: > >Juergen Goeritz wrote: > >> have been reading through dct and the proposed optimization > >> techniques. Sounds very interesting to me. From that 'small' > >> example already the benefits are visible. But do you really > >> think this scheme can also be used on a global level? > >manually, by hand and with a single brain, obviously not. > >However i believe that the method can be automated and the user > >should be able to look at the esulting work. > Yup. usually, you can't automate what you can't do by hand. some people might misunderstand my intentions ("oh gosh, not in asm !") but practice is a good way to learn how to react in complex situations and then teach computers how to deal with it. I might be reinventing the wheel but at least i know how and why it spins :-) > >> It looks to me like a try and error algorithm regarding the > >> 64 register boundary - the long it fits okay - but what do > >> you do when e.g. you start with much more regs required and > >> the algorithm can't manage to fit into 64, what is your > >> proposal then (maybe I overread something?) ? > > > >If there is some "spilling", the global dataflow graph must > >be analysed : the longest "branches" (data that is not modified > >or used during a long time) must be stored to memory. > >For example if you have a graph "width" of 100 data and > >you have only 63 usable registers, then some of them must be > >used to point at the data we'll "spill" and the remaining > >registers (let's say 55) are allocated to contain the 55 shortest > >"branches" of the graph. Once you have determined the spilling > >sequence, you can compute the post-increments for the load/stores. > >The temporary (spilled) variables should not be arbitrarily > >allocated, a global analysis must also be performed to reduce > >the length of the strides (there is only a +256/-256 limit > >for the immediate post-incremented load/store so if you spill > >more than 256 or 512 bytes, you might run into problems > >that a global algorithm would avoid). > > The hint flag for the data cache on write would be used again :) if you spill more registers than L1 can contain, you have to add another level of optimisation, but i don't see a working set that would need that. At that point, it is better to perform the simple graph analysis by taking that limit into account. well, i might be the only one who understands what i write, but give me some time to wake up :-) > >i presume it's not pretty clear, but i'll maybe write another > >paper about that. I have a few ideas in mind for the subject. > > Yes good idea. Please read my other mail about "fitter" design > in the 'Winograd DCT' line. there's an interesting idea here. > >> The point is, how should the compiler do the optimization > >> and resolving in case of 'fit' and 'no-fit'. > >i guess that it is compiler-dependent : each one can have > >a specific strategy to allow problems to appear or not... > > Yes, but that wasn't my point. Maybe you could address this > overload resolution in your further maybe-paper, do you? my next paper is about the 8*8 DCT, so there is obviously a register set "overflow" : there are 64 registers in output and 64 registers in output, plus the 4 "twiddle" constants, and the many temporary variables... the first part will show the "classic" approach and i'll try to go beyond that. > >> And second, > >> maybe even more important, how do you create the latency > >> table for compiler input and keep it consistent with the > >> advancing versions of f-cpu??? > > > >there are currently architecture-specific flags in most compilers. > >This flag would change the latency table. i don't see black > >magic there. > > And ther are really any compilers counting cycles in > a significant amount of opcodes for every new version? actually, i don't think that they "count" cycles, rather they can try to build a "suitable" codee "by construction". they don't "count" after the code is made, but rather they use the latency informations during the build phase. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 09:58:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iB-0006Ap-01 for ; Sun, 21 Apr 2002 03:00:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:15 +0200 (CEST) Received: (qmail 20766 invoked by uid 0); 20 Apr 2002 07:52:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 20 Apr 2002 07:52:07 -0000 Received: by moria.seul.org (Postfix) id 9621C146817; Sat, 20 Apr 2002 03:52:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76F23146821; Sat, 20 Apr 2002 03:52:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 1C930146817 for ; Sat, 20 Apr 2002 03:52:05 -0400 (EDT) Received: from f-cpu.org (kdl16-128.n.club-internet.fr [213.44.18.128]) by relay-1m.club-internet.fr (Postfix) with ESMTP id D5F9616F0 for ; Sat, 20 Apr 2002 09:52:01 +0200 (CEST) Message-ID: <3CC11FAA.F8224C08@f-cpu.org> Date: Sat, 20 Apr 2002 09:58:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > Hi! > > this is indeed a very, very convincing idea! Provide the > 'fitter' for the processor with the processor. YESSS! i'm happy to see that this idea is not so hallucinating for at least someone ;-) maybe you like it because you're also a "HW guy" but the important thing is to have the benefits and let people understand how that works. > > It would be similar to todays FPGAs tool chains! > You can use a 'global tool' like synplicity or whatever > and run the device fitter from the vendor to create > fpga netlist. > very nice comparison, even though i didn't think about it :-) However this creates a new kind of problems : gcc should export the whole Intermediate Representation instead of just register-wise code, because register reallocation works best on program-wise working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data in the form of a flattened netlist, but GCC outputs code that almost looks like already-fitted code. > Now you take gcc (or the ones for ada, f, pas and so on) > and run the f-cpu optimization fitter as a second step. > And I would love to see the optimization procedure as a > part of the loader... that's ADA/VHDL-like, no ? :-P > Then there were the chance for portability at maxperf. > And you wouldn't have to worry about f-cpu type during > compilation... but then your "distibuted binaries" would be some kind of IR, not executable code. what happens if you want to compile a boot loader or a boot kernel ? (i guess the answer but i ask you anyway) > And the hardware guys must think about how software is > to be optimized - what amount of synergy effects :-) > > And finally I don't see problems using gcc as a frontend > tool only. me either : that's what it simply is. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: since i am subscribed to this list, you don't need to CC: :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pash.cracken@free.fr Sat Apr 20 10:20:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iC-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:16 +0200 (CEST) Received: (qmail 17437 invoked by uid 0); 20 Apr 2002 08:20:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 20 Apr 2002 08:20:52 -0000 Received: by moria.seul.org (Postfix) id 1303A14680F; Sat, 20 Apr 2002 04:20:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C2EE146821; Sat, 20 Apr 2002 04:20:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-3-163.abo.wanadoo.fr [217.128.160.163]) by moria.seul.org (Postfix) with ESMTP id 6A17114680F for ; Sat, 20 Apr 2002 04:20:50 -0400 (EDT) Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16yq6h-0006jl-00 for ; Sat, 20 Apr 2002 10:20:31 +0200 Date: Sat, 20 Apr 2002 10:20:31 +0200 From: djrom To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Message-Id: <20020420102031.28772b6a.pash.cracken@free.fr> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >Juergen Goeritz wrote: >> Hi! >> >> this is indeed a very, very convincing idea! Provide the >> 'fitter' for the processor with the processor. YESSS! >i'm happy to see that this idea is not so hallucinating for >at least someone ;-) maybe you like it because you're also >a "HW guy" but the important thing is to have the benefits >and let people understand how that works. i find this idea very nice, too. at least two persons :-) ! >> >> It would be similar to todays FPGAs tool chains! >> You can use a 'global tool' like synplicity or whatever >> and run the device fitter from the vendor to create >> fpga netlist. >> >very nice comparison, even though i didn't think about it :-) >However this creates a new kind of problems : gcc should export >the whole Intermediate Representation instead of just register-wise >code, because register reallocation works best on program-wise >working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data >in the form of a flattened netlist, but GCC outputs code >that almost looks like already-fitted code. >> Now you take gcc (or the ones for ada, f, pas and so on) >> and run the f-cpu optimization fitter as a second step. >> And I would love to see the optimization procedure as a >> part of the loader... >that's ADA/VHDL-like, no ? :-P >> Then there were the chance for portability at maxperf. >> And you wouldn't have to worry about f-cpu type during >> compilation... >but then your "distibuted binaries" would be some kind of IR, >not executable code. what happens if you want to compile >a boot loader or a boot kernel ? (i guess the answer but >i ask you anyway) >> And the hardware guys must think about how software is >> to be optimized - what amount of synergy effects :-) >> >> And finally I don't see problems using gcc as a frontend >> tool only. >me either : that's what it simply is. sure. and I always fall in love for KISS ideas :-) >> JG >WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: since i am subscribed to this list, you don't need to CC: :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 10:47:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iD-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:17 +0200 (CEST) Received: (qmail 8408 invoked by uid 0); 20 Apr 2002 08:41:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 20 Apr 2002 08:41:04 -0000 Received: by moria.seul.org (Postfix) id 651B4146819; Sat, 20 Apr 2002 04:41:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A802146828; Sat, 20 Apr 2002 04:41:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id EDF5F146819 for ; Sat, 20 Apr 2002 04:41:01 -0400 (EDT) Received: from f-cpu.org (kdl11-125.n.club-internet.fr [213.44.9.125]) by relay-1m.club-internet.fr (Postfix) with ESMTP id C4AEC16C6 for ; Sat, 20 Apr 2002 10:40:59 +0200 (CEST) Message-ID: <3CC12B25.51B63796@f-cpu.org> Date: Sat, 20 Apr 2002 10:47:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] new langage ? References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> <200204200510.16370.cedric.bail@free.fr> <20020420010441.40581@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Sat, Apr 20, 2002 at 05:10:16AM +0200, cedric wrote: > [...] > > So you really want to create your own compiler, you now that gcc actually does > > all what we need ? It scan/parse the code, then generate a abstract syntax > > tree and then use the back end specification to translate this tree into asm > > for this specific architecture. > > And this translation can do some optimisation. If you want more about gcc > > backend I think it's chapter 20 of its documentation. > > I've still got a printed copy of the gcc 1.3x manual somewhere... > > But I don't think that gcc `does all we need'. I've run benchmarks > (including SPEC CPU95 and CPU2000) on Intel, Athlon, Alpha, PowerPC, > PA-RISC and SPARC (did I miss any?) -- believe me, I *know* how bad > gcc-generated code performs. then, i guess that using GCC as a "simple" front-end is reasonable ... GCC groks the code, the backend (as Jürgen evokes) will do the rest. i don't see a problem here. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 10:48:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iD-0006Ap-01 for ; Sun, 21 Apr 2002 03:00:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:17 +0200 (CEST) Received: (qmail 970 invoked by uid 0); 20 Apr 2002 08:42:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 20 Apr 2002 08:42:18 -0000 Received: by moria.seul.org (Postfix) id 18499146821; Sat, 20 Apr 2002 04:42:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A3F4146833; Sat, 20 Apr 2002 04:42:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 8BDBA146821 for ; Sat, 20 Apr 2002 04:42:17 -0400 (EDT) Received: from f-cpu.org (kdl11-93.n.club-internet.fr [213.44.9.93]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 764FC16B9 for ; Sat, 20 Apr 2002 10:42:13 +0200 (CEST) Message-ID: <3CC12B70.26A34CB9@f-cpu.org> Date: Sat, 20 Apr 2002 10:48:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update References: <200204200337.50475.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "questions pour un champignon" wrote: > Hi, > > I have started to update the manual with the two post that Michael give to > me, but for certain case it's not really clear. tell me if something EVER remains clear, ok ? :-P > First the FPU. Is it SIMD or not ? at least it should leave this possibility. The chip can implement it the way it wants (or not), but it is desirable. > (problem with exeption and rouding for example, and perhaps a problem of size). rounding ? You want to make separate rounding policies for specific numbers of a SIMD packet ??? > Or is it SIMD hidden into the EU ? i don't see what you mean here. It's certainly done like with integer SIMD. The register set gives a full-width data to the unit and the unit processes it. > (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? date > from Wed, 15 Aug 2001 23:12:27 +0200). > I don't understand the meaning of fexp with a base ? What did that > mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead of flog ? maybe to avoid confusion with LNS operations. you seem to have a problem with the base, right ? it is probably because the algorithm that computes log and exp is specific to a certain base so we can't specify it directly (a mutliply does the correction before or later). > I have added fcmpl[e] instructions in level-1 floating-point for compare instruction. IEEE specifies that FP compares can be done by integer units. correct me if i have mistaken something. > Finally, did we add an new f2f instruction for FP conversions (32bits | > 64bits -> 32 bits | 64 bits) ? i don't remember. > About LNS: what are the rounding method (or mode) ? same as FPU ? And did > we add 16 bits representation (like nicO suggestion ?) ? i have not heard about rounding issues with LNS. Leave that part "highly speculative -> don't bother" now because the legal issues are not all solved. > About memory, I didn't understand the problem with store[f] ? Can you explain > it to me ? the 'f' flag (as explained more or less in previous posts, such as dealing with cache replacement issues) means 'flush' : the LSU line that is being accessed is not needed anymore, so it is not saved in the L1. the behaviour is : - if it's a read and the line has no "dirty" bit, the LSU line pointed by the pointer register will be overwritten by urgent data. - if it's a write, then the line will be written back to the core's outside and then freed for immediate use. > And did we add a new flag for a special immediate operand (6 bits value + 2 > bits left-shift, as Michael suggest ?) i probably missed this post. i can't keep up with everything. just in case someone wonders, if an increment is larger than what the immediate field can contain, there must be more operations : one or more 'loadimm' loads a register with the increment, and the load/store operation uses the register value to update the pointer. > I did'nt understand why did we specify into the CPU a fixed memory > hierarchichies (see cachemem). it was speculative and it's not written in the stone. > I think that we could say that 0 will be the > quicker and 7 the slower, or something like that ? And did we add a 'cachecode > r1' instruction that will perform a prefetch in I-Cache before a jmp (in a > function call for example like in Michael's C++ sample). the cache prefetch is already speculatively performed IIRC. i don't remember the opcode name, but when you specify a register with a target, this first computes the address, then checks the validity and if ok, fetches the code. That's why the prefetch instruction must be moved far in advance. > And about the storem/loadm, I have update with the new form you give > (I have read gcc documentation, and it's exactly the called form it need, so > it will be easy to use for a compiler). argh, i don't know if we will even support loadm/storem in the first chip versions... maybe i shouldn't have spoken about it at all. > But I think that I must remove any > reference to SRB mechanism, because SRB is done in physical address space > (no trap) and the storem/loadm must be done in virtual address space (trap > problem). An other point about this instruction, did we add the 2 registers > form ? i think that we can't solve the whole problem now. Mark this as : "speculative" > We now have a unconditionnal move, but is it a alias for 'movez r0, > r2, r1' or something else ? maybe, maybe not. I think that we'll decide if the opcodes alias when the opcode map will be "compiled" for F-CPU v1. It can be ok to make separate entries and opcode names, because the opcode values can be set to identical values later. > In the instruction set I have updated bitop[i]. IIRC, the original assumptions don't hold anymore, so they also must be marked as "speculative". Maybe a "real" implementation will "chain" SHL and ROP2 together, but the critical datapath is already exploded in SHL and bitop can't fit in a single cycle. > I think that I must update > bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'. An other question > is about nop function, actually it's specified as a movez r0, r0, r0 that > must be coded as a 0x00000000 in hardware, but must I change it so that it > became 'nor r0, r2, r1' or 'xnor r0, r2, r1' ? (I don't understand this > change). i don't understand either. But NOP must become a new opcode of its own. The opcode is not defined yet, but the remaining fields must be zero. I have the intention of giving a new separate semantics to this "instruction" because it's used more often than we'd think, mainly for alignment. So the remaining fields can store hint for the alignment etc... > And I didn't understand the effect of widen new instruction. I don't > understand if it will take 2 cycles and only replace two separated > instructions or if it does something more. i don't remember this discussions... i should look into my archive... > The not instruction did not exist anymore, right ? So it became an > alias, but what is the better choice for this alias ? was there a NOT instruction ? as explained in the manual, ROP2 does only 2-operands operations. There is no specific alias, XORN with register #0 is ok (at first sight). > At least, for jmpa, it's name is now jmp, right ? i guess so. > Can someone explain to me > the new jmp instruction, I currently didn't understand the manual definition. what do you miss ? If the condition is satisfied, jmp(a) jumps to the location pointed to by the pointer register (r2 IIRC). the value of PC+4 is written to the destination register if the jump takes place, this can be R0 but it's used for function calls. > I think, that a good start for an update, if I miss something or you want to > add something, add ;-) i think that the 1st part must be shortened : the inclusion of the aug.1998 document is more misleading than anything. we'll see that when we meet. > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Apr 20 10:51:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iE-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:18 +0200 (CEST) Received: (qmail 29608 invoked by uid 0); 20 Apr 2002 08:53:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 20 Apr 2002 08:53:58 -0000 Received: by moria.seul.org (Postfix) id B9883146828; Sat, 20 Apr 2002 04:53:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90DFE146844; Sat, 20 Apr 2002 04:53:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id E1190146828 for ; Sat, 20 Apr 2002 04:53:53 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16yqan-0005yA-00 for f-cpu@seul.org; Sat, 20 Apr 2002 10:51:37 +0200 Date: Sat, 20 Apr 2002 10:51:37 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC11FAA.F8224C08@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 20 Apr 2002, Yann Guidon wrote: >Juergen Goeritz wrote: >> this is indeed a very, very convincing idea! Provide the >> 'fitter' for the processor with the processor. YESSS! > >i'm happy to see that this idea is not so hallucinating for >at least someone ;-) maybe you like it because you're also >a "HW guy" but the important thing is to have the benefits >and let people understand how that works. I spent a long, long time of my life optimizing code for processors - maybe you understand when I say, no more! I want an automatic approach. >> >> It would be similar to todays FPGAs tool chains! >> You can use a 'global tool' like synplicity or whatever >> and run the device fitter from the vendor to create >> fpga netlist. >> > >very nice comparison, even though i didn't think about it :-) Maybe you just didn't see it ;-) >However this creates a new kind of problems : gcc should export >the whole Intermediate Representation instead of just register-wise >code, because register reallocation works best on program-wise >working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data >in the form of a flattened netlist, but GCC outputs code >that almost looks like already-fitted code. As an idea, GCC may not be allowed to use the whole set of opcodes though. Or you may define a 'hypothetic processor' (like the HYPERPLD in one of the PLD synthesis tools) with only generic opcodes that allows your type of afterburner optimization. >> Now you take gcc (or the ones for ada, f, pas and so on) >> and run the f-cpu optimization fitter as a second step. >> And I would love to see the optimization procedure as a >> part of the loader... >that's ADA/VHDL-like, no ? :-P I would not try to reduce the input capabilities for the developer. Lately I ported a pascal program to C that was heavily using overlays. It was a bit tedious. If I had a pascal compiler with linux capable of overlays I could have just saved me this work. And imagine you want to rewrite the whole fortran library stuff. Better don't!!! >> Then there were the chance for portability at maxperf. >> And you wouldn't have to worry about f-cpu type during >> compilation... >but then your "distibuted binaries" would be some kind of IR, >not executable code. what happens if you want to compile >a boot loader or a boot kernel ? (i guess the answer but >i ask you anyway) This depends. If you define an opcode subset to be used by GCC it could either be a subset of really existing ones or hypothetical ones that must be converted/optimized in a second step first. Today you have two different ways to use programs a) in a operating system environment where you have a loader program as part of the OS or b) independent code that was compiled to fixed addresses (embedded). The programs you mentioned usually are of type b) in which case you would first compile&link with GCC. And depending on the used opcode subset it may be runnable code (of course slow! but interchangeable) or you need that extra step and use the afterburner optimization to get the real (fast) code (dedicated to a specific version of f-cpu). But the programs you mentioned do not really need to be fast (BIOSes aren't fast anyway). In general I propose an additional step in the toolchain compile/optimize - assemble - link - optimize - load. Some years ago there were some developments like this by the Amiga guys. They kept two versions of code in their system. A special code file (hypothetical assem.) that was converted to processor code by the loader at activation time. The system kept both versions and did only exchange the unconverted ones with other systems. But they mixed their idea up too much with parts that cracked system reliability finally. The part of post- optimization and adaption to the processor was a good idea though and should be proceeded by f-cpu, of course in an adapted manner. ;) JG >PS: since i am subscribed to this list, you don't need to CC: :-) Oops. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 20 11:11:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iF-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:19 +0200 (CEST) Received: (qmail 5032 invoked by uid 0); 20 Apr 2002 09:28:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 20 Apr 2002 09:28:41 -0000 Received: by moria.seul.org (Postfix) id BC9D0146833; Sat, 20 Apr 2002 05:28:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B8249146849; Sat, 20 Apr 2002 05:28:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 7A8E4146833 for ; Sat, 20 Apr 2002 05:28:38 -0400 (EDT) Received: from ifurita (212.194.239.220) by mail.laposte.net (5.5.044) id 3CB2AF0B0015CC7A for f-cpu@seul.org; Sat, 20 Apr 2002 11:28:37 +0200 Message-ID: <00b001c1e84b$6ad01ea0$dcefc2d4@ifurita> From: "Christophe" To: References: <200204190824.3722@th00.opsion.fr> <200204200505.30345.cedric.bail@free.fr> Subject: Re: Rep:Re: [f-cpu] new langage ? Date: Sat, 20 Apr 2002 11:11:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: cedric To: Sent: Saturday, April 20, 2002 5:05 AM Subject: Re: Rep:Re: [f-cpu] new langage ? > > New language of a higher level is really needed to really have a code > > portability without the problem of performance. > > > > BUT it's really hard to devellop a all new language ( or look at "D" ). > > > > I personnaly like the way systemC work. It's only a "big" librairy for > > C++. We just have to design a librairy that work well with SIMD. > > > > In c++, one librairy do such thing : STL. If we port STL (in asm) for > > the fpu we could accelerate all soon written programme and future one. > Well, it's a good idea, but the problem is that the a big part of the STL > class are template. What is the problem with "template" ? it is the best compromise you can have in fact so long as we cannot have a good SIMD compiler. Creating an ASM optimizer with template will be cooler than a simple preprocessor in fact (yeah I must consider creating such a language !). > That mean that they are compiled with the application, > and that will be difficult to optimise them. What do you mean ??? template classes allows us to have a seperate representation of data and algorithms : sometimes we could prefer to let the compiler to optimize the code depending of the data the latter handles. It is its main goal. > Of course, class like string must be optimised, and all the libstdc++ > can be optimized. But like the libc and perhaps all the basic lib of each > language we want to see on our chip. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sat Apr 20 14:45:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iJ-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:23 +0200 (CEST) Received: (qmail 27998 invoked by uid 0); 20 Apr 2002 12:45:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 20 Apr 2002 12:45:09 -0000 Received: by moria.seul.org (Postfix) id 7C187146816; Sat, 20 Apr 2002 08:45:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5D4E0146859; Sat, 20 Apr 2002 08:45:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 01A9E146816 for ; Sat, 20 Apr 2002 08:45:07 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16yuEk-00070B-00 for f-cpu@seul.org; Sat, 20 Apr 2002 14:45:06 +0200 Date: Sat, 20 Apr 2002 14:45:06 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC11FAA.F8224C08@f-cpu.org> Message-ID: References: <3CC11FAA.F8224C08@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > However this creates a new kind of problems : gcc should export > the whole Intermediate Representation instead of just register-wise > code, because register reallocation works best on program-wise > working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data > in the form of a flattened netlist, but GCC outputs code > that almost looks like already-fitted code. By the way there is already gcc3 patch which exports whole IR as XML .. (http://sourceforge.net/projects/introspector/) But then your postprocessor will be the same as "detached" gcc backend IMHO. devik PS: have my Itanium question been so dumb or did I violated some f-cpu list roles ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Sat Apr 20 17:17:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iU-0006Ap-00 for ; Sun, 21 Apr 2002 03:00:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:00:34 +0200 (CEST) Received: (qmail 2971 invoked by uid 0); 20 Apr 2002 15:22:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 20 Apr 2002 15:22:39 -0000 Received: by moria.seul.org (Postfix) id F367A14685B; Sat, 20 Apr 2002 11:22:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E39C0146868; Sat, 20 Apr 2002 11:22:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by moria.seul.org (Postfix) with ESMTP id 7CD2D14685B for ; Sat, 20 Apr 2002 11:22:37 -0400 (EDT) Received: from fwd03.sul.t-online.de by mailout06.sul.t-online.com with smtp id 16ywcS-0004gR-03; Sat, 20 Apr 2002 17:17:44 +0200 Received: from (0893089296-0001@[62.226.157.191]) by fwd03.sul.t-online.com with smtp id 16ywcO-1s0RDkC; Sat, 20 Apr 2002 17:17:40 +0200 From: Thilo.Reichelt@t-online.de (Reichelt) To: f-cpu@seul.org References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> <200204200510.16370.cedric.bail@free.fr> <3CC11207.4A45006D@f-cpu.org> Subject: [f-cpu] Porting GCC for Dummies [was:new langage] X-Mailer: T-Online eMail 2.34 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Sat, 20 Apr 2002 17:17:40 +0200 Message-ID: <16ywcO-1s0RDkC@fwd03.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon schrieb: > hi, > > cedric wrote: > > > I really don't want to be tied to a single programming language. No > > > matter what it's called or who invented it. ((discussion between cedric and whygee deleted)) > Two or three years ago, there a paper called "Porting GCC for Dummies" > ("PGCCFD") in PostScript. does anyone know where it is ? I got a pdf version today from: ftp://ftp.axis.se/pub/users/hp/pgccfd The files with *0.5* seem to be ok. > > A+ > > Cedric > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 12:47:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iu-0006Ap-00 for ; Sun, 21 Apr 2002 03:01:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:00 +0200 (CEST) Received: (qmail 24312 invoked by uid 0); 20 Apr 2002 16:35:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 20 Apr 2002 16:35:53 -0000 Received: by moria.seul.org (Postfix) id C8426146800; Sat, 20 Apr 2002 12:35:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE7B4146868; Sat, 20 Apr 2002 12:35:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a247.home.uni-hannover.de [130.75.232.247]) by moria.seul.org (Postfix) with ESMTP id AEF1A146800 for ; Sat, 20 Apr 2002 12:35:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00507; Sat, 20 Apr 2002 12:47:03 +0200 Message-ID: <20020420124703.64224@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 12:47:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update References: <200204200337.50475.cedric.bail@free.fr> <3CC12B70.26A34CB9@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CC12B70.26A34CB9@f-cpu.org>; from Yann Guidon on Sat, Apr 20, 2002 at 10:48:48AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 10:48:48AM +0200, Yann Guidon wrote: [...] > > I have added fcmpl[e] instructions in level-1 floating-point for compare instruction. > IEEE specifies that FP compares can be done by integer units. > correct me if i have mistaken something. Comparing IEEE FP values with an integer unit won't provide correct results. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 20 12:28:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iu-0006Ap-01 for ; Sun, 21 Apr 2002 03:01:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:00 +0200 (CEST) Received: (qmail 26800 invoked by uid 0); 20 Apr 2002 16:35:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 20 Apr 2002 16:35:58 -0000 Received: by moria.seul.org (Postfix) id BAB1C146868; Sat, 20 Apr 2002 12:35:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9AA721468D2; Sat, 20 Apr 2002 12:35:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a247.home.uni-hannover.de [130.75.232.247]) by moria.seul.org (Postfix) with ESMTP id 13D8A146868 for ; Sat, 20 Apr 2002 12:35:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00460; Sat, 20 Apr 2002 12:28:47 +0200 Message-ID: <20020420122846.10378@thrai.stud.uni-hannover.de> Date: Sat, 20 Apr 2002 12:28:46 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC11FAA.F8224C08@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Sat, Apr 20, 2002 at 10:51:37AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 10:51:37AM +0200, Juergen Goeritz wrote: [...] > I spent a long, long time of my life optimizing code for > processors - maybe you understand when I say, no more! > I want an automatic approach. No compiler will ever be as good as a skilled assembler programmer. It's only faster. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Apr 20 19:27:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5ix-0006Ap-01 for ; Sun, 21 Apr 2002 03:01:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:03 +0200 (CEST) Received: (qmail 9538 invoked by uid 0); 20 Apr 2002 17:25:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 20 Apr 2002 17:25:29 -0000 Received: by moria.seul.org (Postfix) id 524A214686B; Sat, 20 Apr 2002 13:25:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 05A121468D5; Sat, 20 Apr 2002 13:25:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id AD5EF14686B for ; Sat, 20 Apr 2002 13:25:25 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16yydd-0006T2-00 for f-cpu@seul.org; Sat, 20 Apr 2002 19:27:05 +0200 Date: Sat, 20 Apr 2002 19:27:05 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <20020420122846.10378@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 20 Apr 2002, Michael Riepe wrote: >On Sat, Apr 20, 2002 at 10:51:37AM +0200, Juergen Goeritz wrote: >[...] >> I spent a long, long time of my life optimizing code for >> processors - maybe you understand when I say, no more! >> I want an automatic approach. > >No compiler will ever be as good as a skilled assembler programmer. >It's only faster. Yes, you are right. But does this speed your development time? Especially for f-cpu it will get very time consuming to optimize by hand and thus will be omitted most of the time. That's why the automatic process is preferable. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Apr 20 20:48:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iz-0006Ap-01 for ; Sun, 21 Apr 2002 03:01:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:05 +0200 (CEST) Received: (qmail 15083 invoked by uid 0); 20 Apr 2002 18:50:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Apr 2002 18:50:24 -0000 Received: by moria.seul.org (Postfix) id 2E02214680E; Sat, 20 Apr 2002 14:50:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1132A1468D5; Sat, 20 Apr 2002 14:50:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 854AE14680E for ; Sat, 20 Apr 2002 14:50:22 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3KIpf4l048894 for ; Sat, 20 Apr 2002 12:51:41 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC1B7E8.9453E2CB@jetnet.ab.ca> Date: Sat, 20 Apr 2002 12:48:08 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > Yes, you are right. But does this speed your development > time? Especially for f-cpu it will get very time consuming > to optimize by hand and thus will be omitted most of the > time. That's why the automatic process is preferable. Cache and latency timing is almost like the OLD SERIAL drum computers.Perhaps that might be a better model to optimize from. Still only about 10% of the code in any program needs speeding up if I remember right, but good programing skills are still needed because only the programer can pick the best algorithom for the job. -- All computers wait at the same speed (unknown by me) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 00:08:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5j3-0006Ap-00 for ; Sun, 21 Apr 2002 03:01:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:09 +0200 (CEST) Received: (qmail 4594 invoked by uid 0); 20 Apr 2002 22:05:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 20 Apr 2002 22:05:12 -0000 Received: by moria.seul.org (Postfix) id B03DA146865; Sat, 20 Apr 2002 18:05:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D42B1468DC; Sat, 20 Apr 2002 18:05:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 2241F146865 for ; Sat, 20 Apr 2002 18:05:09 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16z31f-0006fd-00 for f-cpu@seul.org; Sun, 21 Apr 2002 00:08:11 +0200 Date: Sun, 21 Apr 2002 00:08:11 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC1B7E8.9453E2CB@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 20 Apr 2002, Ben Franchuk wrote: >Juergen Goeritz wrote: >> Yes, you are right. But does this speed your development >> time? Especially for f-cpu it will get very time consuming >> to optimize by hand and thus will be omitted most of the >> time. That's why the automatic process is preferable. > >Cache and latency timing is almost like the OLD SERIAL drum >computers.Perhaps that might be a better model to optimize from. Still >only about 10% of the code in any program needs speeding up if I >remember right, but good programing skills are still needed because only >the programer can pick the best algorithom for the job. :-) guess you are right again with that algorithm thing. I have followed a lot of nonsense discussions about why object oriented programming is better. But actually it depends. I have seen a lot of OO developments hitting exactly the mid of the trash container because of that algorithm thing... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sat Apr 20 22:51:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5j1-0006Ap-00 for ; Sun, 21 Apr 2002 03:01:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:07 +0200 (CEST) Received: (qmail 32115 invoked by uid 0); 20 Apr 2002 20:51:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 20 Apr 2002 20:51:53 -0000 Received: by moria.seul.org (Postfix) id 276FD146832; Sat, 20 Apr 2002 16:51:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 089AB146865; Sat, 20 Apr 2002 16:51:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8F273146832 for ; Sat, 20 Apr 2002 16:51:47 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16z1pi-0000ZD-00 for f-cpu@seul.org; Sat, 20 Apr 2002 22:51:46 +0200 Date: Sat, 20 Apr 2002 22:51:46 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC1A26A.B2E010B7@f-cpu.org> Message-ID: References: <3CC11FAA.F8224C08@f-cpu.org> <3CC1A26A.B2E010B7@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > PS: have my Itanium question been so dumb or did I violated > > some f-cpu list roles ? > why do you ask that ? are some of the post bounced or you didn't like my answer ? > i sent something maybe 2 days ago. Ehh sorry I just scanned my mailbox (9700 msgs btw) I found that I overlooked it. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sat Apr 20 23:58:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5j3-0006Ap-01 for ; Sun, 21 Apr 2002 03:01:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:09 +0200 (CEST) Received: (qmail 31256 invoked by uid 0); 20 Apr 2002 22:06:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 20 Apr 2002 22:06:26 -0000 Received: by moria.seul.org (Postfix) id B79E01468D5; Sat, 20 Apr 2002 18:06:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 72D9D1468DD; Sat, 20 Apr 2002 18:06:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B0C3E1468D5 for ; Sat, 20 Apr 2002 18:06:22 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16z2rs-0006cV-00 for f-cpu@seul.org; Sat, 20 Apr 2002 23:58:04 +0200 Date: Sat, 20 Apr 2002 23:58:04 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC1A268.63ECBB7A@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hallo, On Sat, 20 Apr 2002, Yann Guidon wrote: >Juergen Goeritz wrote: >> On Sat, 20 Apr 2002, Yann Guidon wrote: >> >Juergen Goeritz wrote: >> I spent a long, long time of my life optimizing code for >> processors - maybe you understand when I say, no more! >> I want an automatic approach. > >i did not spend my life doing this but as ar as i remember, i have >spent more than ten years trying to work around a lot of problems. >i too say "no more". However you can't solve a problem you're foreign to, >and you can't automate something you can't do yourself. >A lot of my efforts are an attempt to understand all i can from the >matter and find realistic solutions. it requires some abnegation, >such as watching over this list for example ;-P Nor did I spent my whole life with it :-) In the beginning I coded in assembler only. That was around 1975 when I was 14. And I agree with you - one has to know about the things to find some good solutions. And to get there you have to try and try, make a lot of mistakes and learn and learn from them. >> >very nice comparison, even though i didn't think about it :-) >> Maybe you just didn't see it ;-) >it was not the original idea (giving gcc an over-simplified view of the >processor and doing the rest). Yes and it's done everywhere - of course, even on hardware. >> I would not try to reduce the input capabilities for the >> developer. Lately I ported a pascal program to C that was >> heavily using overlays. It was a bit tedious. If I had >> a pascal compiler with linux capable of overlays I could >> have just saved me this work. And imagine you want to >> rewrite the whole fortran library stuff. Better don't!!! > >arrgggghhhhh.... > >however, i found that expressing algos in VHDL was not so difficult, >though it needed some leaning. But it was easier to learn VHDL than C >(for me). C is used everywhere and one feels a bit forced, but VHDL >is often tought very superficially and the benefits are not apparent. Please don't code software in VHDL - but this is just my personal view and you could argue with me about it. I learned C because it is THE U**X language. And most (mostly embedded) systems I worked with had a need for task switching operating system with dynamic driver handling. Basically I am familiar with the whole tree of different U**X versions and did a lot of driver development, system portation and bring up testing in the network area. >> In general I propose an additional step in the toolchain >> compile/optimize - assemble - link - optimize - load. > >i seem to have understood something like that. >Now my idea was something like > cpp - gcc - as=>simulates the dumb CPU and optimize<= - link - load We are not so far apart. Just put 'link' to the left, too. Linking is a dumb task that need not be addressed by your optimization and thus should better be left out. Its like cpp - gcc - as - link => for the dumb CPU => optimze - load >maybe if we provide a simplified ISA to gcc, compilation and debug >would be simpler... Hm, hm! Debugging is depending on whether you let gcc use a real opcode subset very simple. Otherwise you have to have a sort of '-O0' switch in your afterburner optimizer. Debugging on heavy optimized programs brings a hack of invisibilities anyway and thus could be skipped. If you debug you want to see as much as possible! In case of verification of heavy optimized program code you want to take a look into the assembler anyway and do not debug on the high language level... When I think back over years of work with gcc, there were compiler versions where you couldn't use all optimization switches because of malfunction in optimization. With new CPU support I see a similar problem coming. That's why I was proposing previously to build a basic subset block of f-cpu opcodes (which already make a working processor) to create a simple model for gcc that could be verified by some automatic means. And you may allow only specific optimizations inside gcc which do not spoil your second optimization phase... >> Some years ago there were some developments like this >> by the Amiga guys. They kept two versions of code in >> their system. A special code file (hypothetical assem.) >> that was converted to processor code by the loader at >> activation time. The system kept both versions and did >> only exchange the unconverted ones with other systems. >> But they mixed their idea up too much with parts that >> cracked system reliability finally. The part of post- >> optimization and adaption to the processor was a good >> idea though and should be proceeded by f-cpu, of course >> in an adapted manner. ;) >well, if you have enough time to hack that, go ahead... Hey, I say that your afterburner optimization approach is exactly fulfilling that... >but before you optimise, take some time to learn how >to do that. I know that i don't write enough papers >about it, but you already know that F-CPU is another >new type of beast which needs its own techniques >and mindset. It was designed almost as a Trojan Horse, >seeming quite similar to others (to not scare the execs >out there) but the guts and programming habits have >probably no equivalent. When you have finished your next paper (explaining it in more detail and other optimzation hints) I could probably convince myself to start to code such a beast... >As a "HW guy", you certainly have enough background >to understand most things, so i'm only worried about >my own ability to teach them. Good teaching lessons BTW ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 00:17:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5j5-0006Ap-00 for ; Sun, 21 Apr 2002 03:01:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:11 +0200 (CEST) Received: (qmail 25224 invoked by uid 0); 20 Apr 2002 22:17:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 20 Apr 2002 22:17:53 -0000 Received: by moria.seul.org (Postfix) id B485B1468DC; Sat, 20 Apr 2002 18:17:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A35451468DF; Sat, 20 Apr 2002 18:17:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 05D881468DC for ; Sat, 20 Apr 2002 18:17:51 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16z3Az-0000v5-00 for f-cpu@seul.org; Sun, 21 Apr 2002 00:17:49 +0200 Date: Sun, 21 Apr 2002 00:17:48 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CBF567E.302CDF7B@f-cpu.org> Message-ID: References: <3CBF567E.302CDF7B@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello Yann, > sorry for the delay... i have glibc problems ;-) ;-] recently I started to use uClibc (for our embeeded apps) it is simple, complete and only 250kb SO (with 30k dynamic loader) > > in docs there is stated that f-cpu was at first meant to > > be itanium killer. > hell, that was loooong loooooong ago ;-) > before we can whip Intel's ass, we have to make a first proof-of > concept for a lot of things, build a name, design a complete > working workflow and user base... FC0 is not yet the ia64 basher Yes it is the best way - I know something about hw but not so much as you and other guys here. But from my software enginnering experience the biggest problem of many projects is that they are too large from beginning and these are never finished .. Hovewer at the other side there are issues which whould be addressed in early developement ... > people expected, but it's a nice core anyway :-) Yes I like it much ;) KISS approach. > However, as you can read in the document i just released, 64 registers is > not too much in some critical circumstances... are you speaking about DCT ? Yes from coder's point of view it is good to have a lot of registers. > I have not looked deeply into IA64 and though there are 128 physical int and > fp regs, i am still unsure whether the opcode is limited to 32 registers > (then the "window" moves through user-controlled register renaming). > F-CPU can't afford all the latency and the huge hardware it requires. The opcode uses full 7 bit to address registers. Opcode is 41 bit long minus 7 predication bits. So that there is 32 bits for instruction with at most 3*7 bits to specify register. 3*41=123 and another 5 bits for group code forms instr. group. These five bits selects instruction decoder for different instruction formats so that you have almost the same expressiveness like in f-cpu - but at cost of 1/4 longer opcode. So that there is no real renaming AFAIK - first 32 regs are globa (can't be rotated) and regs 32...128 can be ROTATED - probably there is 7 bit adder in path. You can change the constant. You can rotate all 96 regs (circularly) or only 8,16,32 or 64 of them (simple logic). I've looked at string ops written for IA64 and the sw pipelining can do for eample strlen in cca 10 instructions and hidding 32 cycle memory latency here - with no unrolling (!) IMHO the adder for register rotation could be added in f-cpu without adding next stage - if I understand f-cpu pipeline then at start of decode stage we have prepared all register addresses - these are directly propagated to register file address ports where we need them al the next stage (xbar). I'm not sure but there could be transistor space in decode stage for say 4 bit adder ? Then you could control rotating of blocks of 16 regs to do sw pipelining (and as you say in prev post thare would be problem with state ruring trap/context switch). But some symetric algorithms could benefit from it - bus take it just as my braindump .. > OTOH 64 registers is equivalent to the agregated number of int and fp registers > in most RISC architectures, so it's realistic. But the number of ports > is already a problem for us. hmm I've heard that Itanium (which has 14 ported reg.file) had to add next pipeline stage only due to slowness of these ports - it seems that they have private ports per EU: Itanium has 2 MU, 2 ALU and 3 BR (I ignore FPU - it has its own bank) so you have 6 ports for ALUs, 4 for memunit, 3 for branching and 1 for ... god knows. > > = register renaming > * register renaming adds at least a pipeline stage so the jumps > are slower. We can't afford that now. as above .. is the stage neccesarry ? > allowing the core to reach a higher clock frequency than a traditional design. > It also prepares the rest of the project to very-high performance design habits, > for example it creates a pressure on the compiler from the start. Do you think that given 0.18u process f-cpu could go 2GHz ? I have unforunately no idea of speed of inverter loop at 0.18u. > * function call/returns are often a big deal, but the large number of registers > and modern compilers should help avoid unnecessary work. One ongoing discussion > deals with global-wise optimisations that analyse the call tree and keep only > the most important things in the registers, avoiding the silly spills on the stack. > The object code is probably larger but it should execute pretty fast. You can do it on code which is one module with sources. The big advantage of compile/link is compile speed. I can't imagine developers to wait several hours when recompiling moderate project linked to glibc - you would have to compile glibc along with it to do global optimization.. But if it is only way to go for speed .. well. > > = multi issue & groups > > yep but FC0 is single-issue now, we will examine the issue logic problems > for a later core (FC1 ? FC2 ?). There were several threads in the past about this... maybe unfortunately old archives at yahoo are gone. I was only thinking - if we would need later one bit to demark groups it will be hard to add it without breaking current opcode format. > that's pretty far fetched... and i doubt that there will be such a large > interconnect between the execution units. The plans i have for designing > FC0 don't use such a method because the units have a very specific form factor. I'm just curious - what is on-chip area difference between f-cpu register file:xbar interconnects:adder ? Is is possible to guess something like 1:1:1 ? ;-) > > = address disambiguation > > The memory system that i have designed (i know that nicO is not > very hot about it and if he feels angry enough, he'll design his own ;-D) > is very unusual. it keeps everything coherent at the cost of a bit more > latency, which can be hidden by the usual methods (such as software pipelining). Is there more completion description ? I've read docs 0.2 IIRC and there was not much about mem subsys. In this example: 1: *p = 1; 2: a = *q; 3: p += a; you could do a = *q first to hide [q] fetch latency but if p == q it will result in wrong a. You can prefetch it but there is still L0->register latency (2cycle). You can use condidional move to repair if a if p==q but it is too expensive. So that do you have other method to do it (which Alpha & IA64 does thru associative mem) ? > because the way loads and stores are performed is very different. I'm eager to read more about it ;) BTW: are there some proofs of neccessarity of orthogonal instrucion set ? It seems that by implementing something like tree between registers would make interconnects much cheaper - something like Alpha's split 16/16 with 1 cycle penalty. best regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 19:16:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5iv-0006Ap-01 for ; Sun, 21 Apr 2002 03:01:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:01 +0200 (CEST) Received: (qmail 7386 invoked by uid 0); 20 Apr 2002 17:09:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 20 Apr 2002 17:09:57 -0000 Received: by moria.seul.org (Postfix) id 18FF114685C; Sat, 20 Apr 2002 13:09:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0DFE1468D2; Sat, 20 Apr 2002 13:09:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 18CF014685C for ; Sat, 20 Apr 2002 13:09:54 -0400 (EDT) Received: from f-cpu.org (kdl11-132.n.club-internet.fr [213.44.9.132]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 37A2916A1 for ; Sat, 20 Apr 2002 19:09:49 +0200 (CEST) Message-ID: <3CC1A268.63ECBB7A@f-cpu.org> Date: Sat, 20 Apr 2002 19:16:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > On Sat, 20 Apr 2002, Yann Guidon wrote: > >Juergen Goeritz wrote: > >> this is indeed a very, very convincing idea! Provide the > >> 'fitter' for the processor with the processor. YESSS! > > > >i'm happy to see that this idea is not so hallucinating for > >at least someone ;-) maybe you like it because you're also > >a "HW guy" but the important thing is to have the benefits > >and let people understand how that works. > > I spent a long, long time of my life optimizing code for > processors - maybe you understand when I say, no more! > I want an automatic approach. i did not spend my life doing this but as ar as i remember, i have spent more than ten years trying to work around a lot of problems. i too say "no more". However you can't solve a problem you're foreign to, and you can't automate something you can't do yourself. A lot of my efforts are an attempt to understand all i can from the matter and find realistic solutions. it requires some abnegation, such as watching over this list for example ;-P > >> > >> It would be similar to todays FPGAs tool chains! > >> You can use a 'global tool' like synplicity or whatever > >> and run the device fitter from the vendor to create > >> fpga netlist. > >> > > > >very nice comparison, even though i didn't think about it :-) > Maybe you just didn't see it ;-) it was not the original idea (giving gcc an over-simplified view of the processor and doing the rest). > >However this creates a new kind of problems : gcc should export > >the whole Intermediate Representation instead of just register-wise > >code, because register reallocation works best on program-wise > >working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data > >in the form of a flattened netlist, but GCC outputs code > >that almost looks like already-fitted code. > > As an idea, GCC may not be allowed to use the whole set of > opcodes though. Or you may define a 'hypothetic processor' > (like the HYPERPLD in one of the PLD synthesis tools) with > only generic opcodes that allows your type of afterburner > optimization. that's what i thought (more or less) in the first place. > >> Now you take gcc (or the ones for ada, f, pas and so on) > >> and run the f-cpu optimization fitter as a second step. > >> And I would love to see the optimization procedure as a > >> part of the loader... > >that's ADA/VHDL-like, no ? :-P > > I would not try to reduce the input capabilities for the > developer. Lately I ported a pascal program to C that was > heavily using overlays. It was a bit tedious. If I had > a pascal compiler with linux capable of overlays I could > have just saved me this work. And imagine you want to > rewrite the whole fortran library stuff. Better don't!!! arrgggghhhhh.... however, i found that expressing algos in VHDL was not so difficult, though it needed some leaning. But it was easier to learn VHDL than C (for me). C is used everywhere and one feels a bit forced, but VHDL is often tought very superficially and the benefits are not apparent. > >> Then there were the chance for portability at maxperf. > >> And you wouldn't have to worry about f-cpu type during > >> compilation... > >but then your "distibuted binaries" would be some kind of IR, > >not executable code. what happens if you want to compile > >a boot loader or a boot kernel ? (i guess the answer but > >i ask you anyway) > > This depends. If you define an opcode subset to be used > by GCC it could either be a subset of really existing ones > or hypothetical ones that must be converted/optimized in > a second step first. most certainly. > Today you have two different ways to use programs > a) in a operating system environment where you have a > loader program as part of the OS or > b) independent code that was compiled to fixed addresses > (embedded). > > The programs you mentioned usually are of type b) in > which case you would first compile&link with GCC. And > depending on the used opcode subset it may be runnable > code (of course slow! but interchangeable) or you need > that extra step and use the afterburner optimization > to get the real (fast) code (dedicated to a specific > version of f-cpu). But the programs you mentioned do > not really need to be fast (BIOSes aren't fast anyway). ;-D > In general I propose an additional step in the toolchain > compile/optimize - assemble - link - optimize - load. i seem to have understood something like that. Now my idea was something like cpp - gcc - as=>simulates the dumb CPU and optimize<= - link - load maybe if we provide a simplified ISA to gcc, compilation and debug would be simpler... > Some years ago there were some developments like this > by the Amiga guys. They kept two versions of code in > their system. A special code file (hypothetical assem.) > that was converted to processor code by the loader at > activation time. The system kept both versions and did > only exchange the unconverted ones with other systems. > But they mixed their idea up too much with parts that > cracked system reliability finally. The part of post- > optimization and adaption to the processor was a good > idea though and should be proceeded by f-cpu, of course > in an adapted manner. ;) well, if you have enough time to hack that, go ahead... but before you optimise, take some time to learn how to do that. I know that i don't write enough papers about it, but you already know that F-CPU is another new type of beast which needs its own techniques and mindset. It was designed almost as a Trojan Horse, seeming quite similar to others (to not scare the execs out there) but the guts and programming habits have probably no equivalent. As a "HW guy", you certainly have enough background to understand most things, so i'm only worried about my own ability to teach them. > JG > > >PS: since i am subscribed to this list, you don't need to CC: :-) > Oops. ;-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 20 19:16:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16z5ix-0006Ap-00 for ; Sun, 21 Apr 2002 03:01:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 03:01:03 +0200 (CEST) Received: (qmail 27150 invoked by uid 0); 20 Apr 2002 17:10:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 20 Apr 2002 17:10:04 -0000 Received: by moria.seul.org (Postfix) id AB8D01468D2; Sat, 20 Apr 2002 13:09:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 959DA1468D5; Sat, 20 Apr 2002 13:09:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 055831468D2 for ; Sat, 20 Apr 2002 13:09:58 -0400 (EDT) Received: from f-cpu.org (kdl11-132.n.club-internet.fr [213.44.9.132]) by relay-2m.club-internet.fr (Postfix) with ESMTP id CF27516D1 for ; Sat, 20 Apr 2002 19:09:52 +0200 (CEST) Message-ID: <3CC1A26A.B2E010B7@f-cpu.org> Date: Sat, 20 Apr 2002 19:16:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC11FAA.F8224C08@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Martin Devera wrote: > > However this creates a new kind of problems : gcc should export > > the whole Intermediate Representation instead of just register-wise > > code, because register reallocation works best on program-wise > > working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data > > in the form of a flattened netlist, but GCC outputs code > > that almost looks like already-fitted code. > > By the way there is already gcc3 patch which exports whole > IR as XML .. (http://sourceforge.net/projects/introspector/) that's a good news ! > But then your postprocessor will be the same as "detached" > gcc backend IMHO. why not. but my initial idea was to give GCC an oversimplified ISA and do the naughty F-CPU stuff ourselves. Using XML would force me to learn it and GCC3 is not well percieved, but it's a bet on the far future. > devik > PS: have my Itanium question been so dumb or did I violated > some f-cpu list roles ? why do you ask that ? are some of the post bounced or you didn't like my answer ? i sent something maybe 2 days ago. Btw, i get bounce messages from someone in australia and someone else from tu-muenchen.de, among others. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 21 03:31:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDW6-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:18 +0200 (CEST) Received: (qmail 25806 invoked by uid 0); 21 Apr 2002 01:31:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 21 Apr 2002 01:31:28 -0000 Received: by moria.seul.org (Postfix) id 523B91468DF; Sat, 20 Apr 2002 21:31:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3400F1468E1; Sat, 20 Apr 2002 21:31:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a082.home.uni-hannover.de [130.75.232.82]) by moria.seul.org (Postfix) with ESMTP id 9F63D1468DF for ; Sat, 20 Apr 2002 21:31:25 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA00724; Sun, 21 Apr 2002 03:31:23 +0200 Message-ID: <20020421033123.46774@thrai.stud.uni-hannover.de> Date: Sun, 21 Apr 2002 03:31:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020420122846.10378@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Sat, Apr 20, 2002 at 07:27:05PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 20, 2002 at 07:27:05PM +0200, Juergen Goeritz wrote: > On Sat, 20 Apr 2002, Michael Riepe wrote: > > >On Sat, Apr 20, 2002 at 10:51:37AM +0200, Juergen Goeritz wrote: > >[...] > >> I spent a long, long time of my life optimizing code for > >> processors - maybe you understand when I say, no more! > >> I want an automatic approach. > > > >No compiler will ever be as good as a skilled assembler programmer. > >It's only faster. > > Yes, you are right. But does this speed your development > time? Especially for f-cpu it will get very time consuming > to optimize by hand and thus will be omitted most of the > time. That's why the automatic process is preferable. If you run a program once and want the result as fast as possible, a compiler is much better. But if you run it a million times, writing assembler code becomes pretty cheap. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 06:40:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWB-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:23 +0200 (CEST) Received: (qmail 20427 invoked by uid 0); 21 Apr 2002 04:34:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Apr 2002 04:34:15 -0000 Received: by moria.seul.org (Postfix) id 0DBB01468E8; Sun, 21 Apr 2002 00:34:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 056EC1468E6; Sun, 21 Apr 2002 00:34:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 94AC01468E4 for ; Sun, 21 Apr 2002 00:34:09 -0400 (EDT) Received: from f-cpu.org (kdl11-71.n.club-internet.fr [213.44.9.71]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 3969D16A2 for ; Sun, 21 Apr 2002 06:34:04 +0200 (CEST) Message-ID: <3CC242C8.E7BC0F3A@f-cpu.org> Date: Sun, 21 Apr 2002 06:40:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Martin Devera wrote: > Hello Yann, Hi Martin ! > > sorry for the delay... i have glibc problems ;-) > > ;-] recently I started to use uClibc (for our embeeded apps) > it is simple, complete and only 250kb SO (with 30k dynamic > loader) arghflk ! and how fast does this compile (compared to Glibc) ? :-) > > > in docs there is stated that f-cpu was at first meant to > > > be itanium killer. > > hell, that was loooong loooooong ago ;-) > > before we can whip Intel's ass, we have to make a first proof-of > > concept for a lot of things, build a name, design a complete > > working workflow and user base... FC0 is not yet the ia64 basher > > Yes it is the best way - I know something about hw but not so > much as you and other guys here. some of your later comments later show that you're not clueless either. > But from my software enginnering > experience the biggest problem of many projects is that they are > too large from beginning and these are never finished .. F-CPU might well be among them. But OTOH when a project is "finished" it means that it is dead... > Hovewer at the other side there are issues which whould be addressed > in early developement ... and F-CPU spends most of its time trying to find compromises... > > people expected, but it's a nice core anyway :-) > Yes I like it much ;) KISS approach. i wouldn't say it's KISS otherwise it would already be finished ;-P However, it would be cool if it became the equivalent of "MIPS R2000" of the new century. This project has been contributed by a lot of people who shared their experience. In some places it looks like a worthless compromise and in other places, where no existing solution exists, new things are imagined. > > However, as you can read in the document i just released, 64 registers is > > not too much in some critical circumstances... > are you speaking about DCT ? Yes from coder's point of view it is > good to have a lot of registers. DCT is only a simple example, of course, a proof of concept. There was a list of wished code examples, and only the complete implementation of these examples can give a good overview of WHAT F-CPU is and should be properly programmed. If you learnt MIPS and x86, you have to forget some things and learn new things, and think more globally. it's not easy. > > I have not looked deeply into IA64 and though there are 128 physical int and > > fp regs, i am still unsure whether the opcode is limited to 32 registers > > (then the "window" moves through user-controlled register renaming). > > F-CPU can't afford all the latency and the huge hardware it requires. > > The opcode uses full 7 bit to address registers. at a time, i wondered whether they implemented only 5 bits for the register addresses. > Opcode is 41 bit long minus 7 predication bits. So that there is 32 bits > for instruction with at most 3*7 bits to specify register. > 3*41=123 and another 5 bits for group code forms instr. group. These five > bits selects instruction decoder for different instruction formats so that > you have almost the same expressiveness like in f-cpu - but at cost of > 1/4 longer opcode. the code size bloat is not that important, depending on your goal and application. > So that there is no real renaming AFAIK - first 32 regs are globa (can't > be rotated) and regs 32...128 can be ROTATED - probably there is 7 bit > adder in path. You can change the constant. IIRC there IS an adder and renaming takes one cycle (in the old implementations). > You can rotate all 96 regs (circularly) or only 8,16,32 or 64 of them > (simple logic). forget the concept of "simple logic" :-) at that scale, anything takes time. Of course now, transmission takes more time than computation, but even that has a "cost". > I've looked at string ops written for IA64 and the sw > pipelining can do for eample strlen in cca 10 instructions and hidding > 32 cycle memory latency here - with no unrolling (!) nice. > IMHO the adder for register rotation could be added in f-cpu without > adding next stage it can't : it's already too tight and it would break FC0's architecture. > - if I understand f-cpu pipeline then at start of > decode stage we have prepared all register addresses - these are > directly propagated to register file address ports where we need > them al the next stage (xbar). that's acurate, even though now i'm less optimistic. if i participate to FC1, i'll take more precautions because it seems that FC0's register set will be the slowest part of the whole core. > I'm not sure but there could be > transistor space in decode stage for say 4 bit adder ? not even, because as noted before, it's probably the critical datapath. > Then you could control rotating of blocks of 16 regs to do sw > pipelining (and as you say in prev post thare would be problem > with state ruring trap/context switch). > But some symetric algorithms could benefit from it - bus take it > just as my braindump .. F-CPU was not designed with these techniques in mind, so it looks a bit handicaped in this respect. Maybe this must be considered for a "F-CPU 2" project because the programmining model is already advanced. Furthermore, optimising compilers for this kind of computer are not easy to do (look at Intel's pain :-P) and this requires predicates (which were dropped because it wouldn't fit in 32-bit instructions). As a conclusion, the state of the art in computer science and technology is not yet advanced for doing an ia64-like in F-CPU fashion. we already have to deal with different kinds of problems, such as the VHDL toolchain and the portability... > > OTOH 64 registers is equivalent to the agregated number of int and fp registers > > in most RISC architectures, so it's realistic. But the number of ports > > is already a problem for us. > hmm I've heard that Itanium (which has 14 ported reg.file) had to add > next pipeline stage only due to slowness of these ports - it seems that > they have private ports per EU: Itanium has 2 MU, 2 ALU and 3 BR > (I ignore FPU - it has its own bank) so you have 6 ports for ALUs, > 4 for memunit, 3 for branching and 1 for ... god knows. maybe only He knows, indeed ;-P The size of the register set is a big issue and it is certainly one factor of Itanium's "slowness". already with 5 ports, FC0 will be relatively "slow". Adding ports reduces the control logic's complexity (because temporary buffers must be managed otherwise) and allow more access, but completely bloats the silicon surface. it's a hard job. For example, nicO wants to reduce the number of ports and i thought about a way to achieve that. However, making a 3r2w register set with 1r1w blocks does not reduce the surface and the complexity because a lot of things must be duplicated : - you can do a 2r1w bank by using 2*1r1w blocks, so having 3 read ports requires 3 identical blocks. - you can't do a Xr2w bank as simply as a 2r1w bank because the data must be written to all the sub-blocks. One solution is to use some kind of FIFO that serializes the write but it's not a suitable solution in this case. One solution i proposed was to ensure that two simultaneous writes would not write the same sub-block, but this can reduce the overall CPU efficiency. (i'll describe the trick later) > > > = register renaming > > * register renaming adds at least a pipeline stage so the jumps > > are slower. We can't afford that now. > as above .. is the stage neccesarry ? absolutely. > > allowing the core to reach a higher clock frequency than a traditional design. > > It also prepares the rest of the project to very-high performance design habits, > > for example it creates a pressure on the compiler from the start. > Do you think that given 0.18u process f-cpu could go 2GHz ? I have > unforunately no idea of speed of inverter loop at 0.18u. the speed of the inverter is not directly linked to the frequency of the whole chip because a lot of parameters have recently become prominent : - the wires are relatively "slow", and the propagation time increases as the square of the distance - ===> a 64-bit computer then requires not 2x but 4x more time to propagate a data from bit 0 to bit 63 - logic gates have increased in complexity because the old transistor constructs (back in 1985 where pass transistors were so handy) do not hold anymore, because of the much lower core voltage and the reduced noise immunity. - ===> as a consequence, the actual surface for a given function doesn't decrease as quickly as the transistors... if you need more transistors to perform the same thing... - memory cells become relatively slower and larger This explains why a rough estimate of the complexity and speed of FC0 gives that one half of the surface and time is spent in the pipeline flip-flops. The core will spend one half of its time memorizing things between two stages... that's the point of diminishing return and all the FC0 is calibrated around that. > > * function call/returns are often a big deal, but the large number of registers > > and modern compilers should help avoid unnecessary work. One ongoing discussion > > deals with global-wise optimisations that analyse the call tree and keep only > > the most important things in the registers, avoiding the silly spills on the stack. > > The object code is probably larger but it should execute pretty fast. > > You can do it on code which is one module with sources. The big advantage > of compile/link is compile speed. I can't imagine developers to wait > several hours when recompiling moderate project linked to glibc - you > would have to compile glibc along with it to do global optimization.. > But if it is only way to go for speed .. well. This depends on the local definition of speed. When you develop an algorithm, compile time is moderately crucial. Often, only small parts of the code base are modified, so incremental compilation is possible (unless there's a avalanche effect). Then when you are finished, you can let your computer run when you sleep for some deep optimisations, if you want. > > > = multi issue & groups > > yep but FC0 is single-issue now, we will examine the issue logic problems > > for a later core (FC1 ? FC2 ?). There were several threads in the past about this... > maybe unfortunately old archives at yahoo are gone. There's an archive in Mexico (i forgot the URL). it's a pretty large archive (around 20MB of files and attachments) > I was only > thinking - if we would need later one bit to demark groups it will > be hard to add it without breaking current opcode format. one of the ideas i proposed was to use a specific opcode for this. For example, a cache line holds 8 instructions of 32 bits. if the opcode itself is 8 bits, there remains 24 bits to describe what the remaining 7 instructions of the line do. With an average of 3 bits per instruction, it could "hint" the instruction decoder and allow up to 7 parallel pipelines to be fed in one cycle. what do you think about this ? there's only a 1/8 overhead/bloat and it's pretty portable accross different implementations (recognize this opcode as NOP if not useful, extract only the needed information otherwise...) > > that's pretty far fetched... and i doubt that there will be such a large > > interconnect between the execution units. The plans i have for designing > > FC0 don't use such a method because the units have a very specific form factor. > I'm just curious - what is on-chip area difference between f-cpu register > file:xbar interconnects:adder ? > Is is possible to guess something like 1:1:1 ? ;-) in today's technology, the Xbar won't have a specific "area" because it will be routed "over" the other layers. With a 5-metal technology, the "Xbar" will use the topmost 1 or 2 layers, for example. > > > = address disambiguation > > The memory system that i have designed (i know that nicO is not > > very hot about it and if he feels angry enough, he'll design his own ;-D) > > is very unusual. it keeps everything coherent at the cost of a bit more > > latency, which can be hidden by the usual methods (such as software pipelining). > Is there more completion description ? I've read docs 0.2 IIRC and there > was not much about mem subsys. In this example: > > 1: *p = 1; > 2: a = *q; > 3: p += a; > > you could do a = *q first to hide [q] fetch latency but if p == q > it will result in wrong a. You can prefetch it but there is still > L0->register latency (2cycle). You can use condidional move to repair > if a if p==q but it is too expensive. > So that do you have other method to do it (which Alpha & IA64 does > thru associative mem) ? My (personal) point of view about this kind of problems is : if you mess with the usual way things are done, it will be done anyway (if it's legal enough) but certainly slower. If you code correctly (99% of the code out there) there wouldn't be such a problem. now for the remaining 1%, let's see what happens with some translation to asm and explanation of what happens behind the curtains ... 1: loadimm 1, r1 ; // or something like that. store r2, r1 ; // here, r2 already points to the location p, the address is // "desambiguified" at execution (otherwise it would trap // if a TLB miss occured). 2: load r3, r4 ; // like above, r3 already points to *q. If q==p, the value // of r4 becomes this of r1. there might be a small delay // (1 or 2 cycles at most) if no bypass is designed in the LSU. 3: add r2, r4, r2; // there's a bypass on the Xbar. The only bad surprise comes from // the future reuse of r2 as a pointer without a previous explicit // prefetch, a few cycles of penalty. my first estimations are // less than i expected (1 or 2 cycles) but this will not be true // in the future or in far-from-ideal cases. > > because the way loads and stores are performed is very different. > I'm eager to read more about it ;) there will be an outline in the next paper (2D DCT). > BTW: are there some proofs of neccessarity of orthogonal instrucion > set ? It seems that by implementing something like tree between > registers would make interconnects much cheaper - something > like Alpha's split 16/16 with 1 cycle penalty. split register sets will probably become more and more necessary... However, i am scratching some ideas for in hypothetical FC1, which would be even more strange but very interesting anyway (on-the-fly RISC->TTA translator with large instruction buffer, TTA core, potentially superscalar execution with TTA's inherent OOO capabilities... yeah...) but that's only for the time when FC0 will tick in more than one prototype. > best regards, > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 06:40:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWE-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:26 +0200 (CEST) Received: (qmail 516 invoked by uid 0); 21 Apr 2002 04:34:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Apr 2002 04:34:17 -0000 Received: by moria.seul.org (Postfix) id 67E011468E4; Sun, 21 Apr 2002 00:34:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3EB101468E6; Sun, 21 Apr 2002 00:34:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id AC2241468E4 for ; Sun, 21 Apr 2002 00:34:16 -0400 (EDT) Received: from f-cpu.org (kdl11-71.n.club-internet.fr [213.44.9.71]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 7550416A2 for ; Sun, 21 Apr 2002 06:34:13 +0200 (CEST) Message-ID: <3CC242D1.7E463784@f-cpu.org> Date: Sun, 21 Apr 2002 06:40:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Juergen Goeritz wrote: > On Sat, 20 Apr 2002, Yann Guidon wrote: > >Juergen Goeritz wrote: > >> On Sat, 20 Apr 2002, Yann Guidon wrote: > >> >Juergen Goeritz wrote: > >> I would not try to reduce the input capabilities for the > >> developer. Lately I ported a pascal program to C that was > >> heavily using overlays. It was a bit tedious. If I had > >> a pascal compiler with linux capable of overlays I could > >> have just saved me this work. And imagine you want to > >> rewrite the whole fortran library stuff. Better don't!!! > > > >arrgggghhhhh.... > > > >however, i found that expressing algos in VHDL was not so difficult, > >though it needed some leaning. But it was easier to learn VHDL than C > >(for me). C is used everywhere and one feels a bit forced, but VHDL > >is often tought very superficially and the benefits are not apparent. > > Please don't code software in VHDL - but this is just > my personal view and you could argue with me about it. and i won't give up this pleasure ;-) i would be very interested to see how such a parallel langage could be transformed into a sequential code. At least, the parallelism issues will disappear. The overload functions provide the user with transparent means to apply their algorithms on different data types. The event-driven model makes some more things easier (like the way functions are synchronised). I like these ideas :-) I don't want to use the ADA model verbatim, however. > I learned C because it is THE U**X language. but it's an oooooold langage :-( and it's not adapted to today's computers... > >> In general I propose an additional step in the toolchain > >> compile/optimize - assemble - link - optimize - load. > > > >i seem to have understood something like that. > >Now my idea was something like > > cpp - gcc - as=>simulates the dumb CPU and optimize<= - link - load > > We are not so far apart. Just put 'link' to the left, too. > Linking is a dumb task that need not be addressed by your > optimization and thus should better be left out. Its like > cpp - gcc - as - link => for the dumb CPU => optimze - load i am not at ease with that. However, if we can use GCC 3/4 with XML export of the IR, [far in the future] this won't be a problem anymore. The GLIBC could be compiled in XML form and the linker could choose to use only the necessary parts (if you only use printf in your program) or "link" to te usual interface. If only printf is needed, the corresponding XML IR is integrated to the program's representation and optimised with it. > >maybe if we provide a simplified ISA to gcc, compilation and debug > >would be simpler... > > Hm, hm! Debugging is depending on whether you let gcc > use a real opcode subset very simple. Otherwise you > have to have a sort of '-O0' switch in your afterburner > optimizer. Debugging on heavy optimized programs brings > a hack of invisibilities anyway and thus could be skipped. > If you debug you want to see as much as possible! i meant : debug/development of our "optimiser". It is not a good thing to optimise an untested code, btw. > >but before you optimise, take some time to learn how > >to do that. I know that i don't write enough papers > >about it, but you already know that F-CPU is another > >new type of beast which needs its own techniques > >and mindset. It was designed almost as a Trojan Horse, > >seeming quite similar to others (to not scare the execs > >out there) but the guts and programming habits have > >probably no equivalent. > > When you have finished your next paper (explaining it > in more detail and other optimzation hints) I could > probably convince myself to start to code such a beast... i'll try my best... but i better write papers that bring some money back to my pocket, too. My chocolate budget is very important ;-) some months ago, i wrote a french article that started as the french translation of the VHDL-HOWTO and i earned some money. i'll try to do that from time to time. However, the DCT optimisation paper is not likely to be accepted by any magazine i know. > >As a "HW guy", you certainly have enough background > >to understand most things, so i'm only worried about > >my own ability to teach them. > Good teaching lessons BTW ;-) does that mean that you learned something ? if yes ==> oh great ! ;-) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 06:40:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWG-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:28 +0200 (CEST) Received: (qmail 22162 invoked by uid 0); 21 Apr 2002 04:34:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 21 Apr 2002 04:34:22 -0000 Received: by moria.seul.org (Postfix) id 687481468E5; Sun, 21 Apr 2002 00:34:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 448B01468E9; Sun, 21 Apr 2002 00:34:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 00C061468E5 for ; Sun, 21 Apr 2002 00:34:21 -0400 (EDT) Received: from f-cpu.org (kdl11-71.n.club-internet.fr [213.44.9.71]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 0419E16A2 for ; Sun, 21 Apr 2002 06:34:20 +0200 (CEST) Message-ID: <3CC242D8.8547B4AC@f-cpu.org> Date: Sun, 21 Apr 2002 06:40:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC11FAA.F8224C08@f-cpu.org> <3CC1A26A.B2E010B7@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Martin Devera wrote: > > > PS: have my Itanium question been so dumb or did I violated > > > some f-cpu list roles ? > > why do you ask that ? are some of the post bounced or you didn't like my answer ? > > i sent something maybe 2 days ago. > > Ehh sorry I just scanned my mailbox (9700 msgs btw) I found > that I overlooked it. :-) > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 06:40:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWG-0003Ke-01 for ; Sun, 21 Apr 2002 11:20:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:28 +0200 (CEST) Received: (qmail 27263 invoked by uid 0); 21 Apr 2002 04:34:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 21 Apr 2002 04:34:26 -0000 Received: by moria.seul.org (Postfix) id BEF801468EB; Sun, 21 Apr 2002 00:34:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCA421468EA; Sun, 21 Apr 2002 00:34:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 749281468E6 for ; Sun, 21 Apr 2002 00:34:25 -0400 (EDT) Received: from f-cpu.org (kdl11-71.n.club-internet.fr [213.44.9.71]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 07A971695 for ; Sun, 21 Apr 2002 06:34:23 +0200 (CEST) Message-ID: <3CC242DB.5015CE4D@f-cpu.org> Date: Sun, 21 Apr 2002 06:40:59 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC1B7E8.9453E2CB@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N and then whygee stepped into the discussion again ... :-) Ben Franchuk wrote: > Juergen Goeritz wrote: > > Yes, you are right. But does this speed your development > > time? Especially for f-cpu it will get very time consuming > > to optimize by hand and thus will be omitted most of the > > time. That's why the automatic process is preferable. > > Cache and latency timing is almost like the OLD SERIAL drum > computers.Perhaps that might be a better model to optimize from. Still > only about 10% of the code in any program needs speeding up if I > remember right, but good programing skills are still needed because only > the programer can pick the best algorithom for the job. you know well that both of you have very good points and your antagonism is a bit childish ;-P we'd like to have a solution that solves all our problems without the hassles. On one hand, we can't rely on the automated code cruncher to spit efficient object code. So the user has to control/check the output and agree that there is no better way to do the job. In some cases, it would be useful that the "code generator" learns new tricks from the user (kind of basic, well-studied "artificial intelligence"). On the other hand, the size of the programs continue to explode, a lot of things are not manageable anymore only by hand. i did 160KB of asm code once, and i sworn i'll never do that again. We need something that eases asm programming, beyond macros and other low-level constructs : something that treats code blocks as a complex object with its dependencies, register allocations, parameters... and that the programmer can handle as easily as drag-n-drop. when dropped, the register allocation is done automatically, according to the programmer's settings. With this kind of tool, bigger parts of code can be tightly controlled and a better performance/ease of programming ratio can be achieved. This idea is not new and i propose something like that for a long time. No need for a new langage when your representation is not textual. Hence the name : "GNL is Not a Langage". seems like i'll have to learn XML ... > All computers wait at the same speed (unknown by me) but all users are impatient ;-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 06:41:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWH-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:29 +0200 (CEST) Received: (qmail 10377 invoked by uid 0); 21 Apr 2002 04:34:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 21 Apr 2002 04:34:35 -0000 Received: by moria.seul.org (Postfix) id 318CE1468EC; Sun, 21 Apr 2002 00:34:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F3341468EA; Sun, 21 Apr 2002 00:34:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id F0CC11468E6 for ; Sun, 21 Apr 2002 00:34:33 -0400 (EDT) Received: from f-cpu.org (kdl11-71.n.club-internet.fr [213.44.9.71]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 16A1816BD for ; Sun, 21 Apr 2002 06:34:29 +0200 (CEST) Message-ID: <3CC242DE.A6D64833@f-cpu.org> Date: Sun, 21 Apr 2002 06:41:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Porting GCC for Dummies [was:new langage] References: <200204190824.3722@th00.opsion.fr> <20020419122523.52714@thrai.stud.uni-hannover.de> <200204200510.16370.cedric.bail@free.fr> <3CC11207.4A45006D@f-cpu.org> <16ywcO-1s0RDkC@fwd03.sul.t-online.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Reichelt wrote: > Yann Guidon schrieb: > > Two or three years ago, there a paper called "Porting GCC for Dummies" > > ("PGCCFD") in PostScript. does anyone know where it is ? > I got a pdf version today from: > ftp://ftp.axis.se/pub/users/hp/pgccfd > The files with *0.5* seem to be ok. i have downloaded the PDF and am reading it now :-) thanks for the link ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 09:51:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWK-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:32 +0200 (CEST) Received: (qmail 24431 invoked by uid 0); 21 Apr 2002 08:43:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 21 Apr 2002 08:43:07 -0000 Received: by moria.seul.org (Postfix) id DA0561468EF; Sun, 21 Apr 2002 04:43:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CC81E1468F2; Sun, 21 Apr 2002 04:43:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 93ECE1468EF for ; Sun, 21 Apr 2002 04:43:03 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zC7h-00073V-00 for f-cpu@seul.org; Sun, 21 Apr 2002 09:51:01 +0200 Date: Sun, 21 Apr 2002 09:51:01 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <20020421033123.46774@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Michael Riepe wrote: >On Sat, Apr 20, 2002 at 07:27:05PM +0200, Juergen Goeritz wrote: >> On Sat, 20 Apr 2002, Michael Riepe wrote: >> >> >On Sat, Apr 20, 2002 at 10:51:37AM +0200, Juergen Goeritz wrote: >> >[...] >> >> I spent a long, long time of my life optimizing code for >> >> processors - maybe you understand when I say, no more! >> >> I want an automatic approach. >> > >> >No compiler will ever be as good as a skilled assembler programmer. >> >It's only faster. >> >> Yes, you are right. But does this speed your development >> time? Especially for f-cpu it will get very time consuming >> to optimize by hand and thus will be omitted most of the >> time. That's why the automatic process is preferable. > >If you run a program once and want the result as fast as possible, >a compiler is much better. But if you run it a million times, writing >assembler code becomes pretty cheap. Maybe we are not living in the same world? In my world products time to market is 6 to 12 months. The number of codelines by far exceed 50000. If you are late with the development or have performance impacts by design it really costs. For calculation the assembler to C/C++ ratio is set to 20 in time and cost. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 10:41:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWK-0003Ke-01 for ; Sun, 21 Apr 2002 11:20:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:32 +0200 (CEST) Received: (qmail 24668 invoked by uid 0); 21 Apr 2002 08:43:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 21 Apr 2002 08:43:13 -0000 Received: by moria.seul.org (Postfix) id 336841468F4; Sun, 21 Apr 2002 04:43:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 310C61468F3; Sun, 21 Apr 2002 04:43:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id C24571468F1 for ; Sun, 21 Apr 2002 04:43:11 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zCuj-00073x-00 for f-cpu@seul.org; Sun, 21 Apr 2002 10:41:41 +0200 Date: Sun, 21 Apr 2002 10:41:41 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC242D1.7E463784@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >> >however, i found that expressing algos in VHDL was not so difficult, >> >though it needed some leaning. But it was easier to learn VHDL than C >> >(for me). C is used everywhere and one feels a bit forced, but VHDL >> >is often tought very superficially and the benefits are not apparent. >> >> Please don't code software in VHDL - but this is just >> my personal view and you could argue with me about it. > >and i won't give up this pleasure ;-) >i would be very interested to see how such a parallel langage could >be transformed into a sequential code. >At least, the parallelism issues will disappear. >The overload functions provide the user with transparent means >to apply their algorithms on different data types. >The event-driven model makes some more things easier (like >the way functions are synchronised). >I like these ideas :-) >I don't want to use the ADA model verbatim, however. Yes, don't give up the parallel view. It is superior. ;-) >> I learned C because it is THE U**X language. >but it's an oooooold langage :-( and it's not adapted >to today's computers... You are working with oooooold operating systems BTW. U**X is nearly as old as I am :-( but still superior to MS. >> >> In general I propose an additional step in the toolchain >> >> compile/optimize - assemble - link - optimize - load. >> > >> >i seem to have understood something like that. >> >Now my idea was something like >> > cpp - gcc - as=>simulates the dumb CPU and optimize<= - link - load >> >> We are not so far apart. Just put 'link' to the left, too. >> Linking is a dumb task that need not be addressed by your >> optimization and thus should better be left out. Its like >> cpp - gcc - as - link => for the dumb CPU => optimze - load > >i am not at ease with that. >However, if we can use GCC 3/4 with XML export of the IR, >[far in the future] this won't be a problem anymore. >The GLIBC could be compiled in XML form and the linker could >choose to use only the necessary parts (if you only use >printf in your program) or "link" to te usual interface. >If only printf is needed, the corresponding XML IR is integrated >to the program's representation and optimised with it. I wanted to express that maybe one could do shared lib linking before doing the second optimization stage... >> >maybe if we provide a simplified ISA to gcc, compilation and debug >> >would be simpler... >> >> Hm, hm! Debugging is depending on whether you let gcc >> use a real opcode subset very simple. Otherwise you >> have to have a sort of '-O0' switch in your afterburner >> optimizer. Debugging on heavy optimized programs brings >> a hack of invisibilities anyway and thus could be skipped. >> If you debug you want to see as much as possible! > >i meant : debug/development of our "optimiser". Argh! Handwork welcome... >It is not a good thing to optimise an untested code, btw. :-) It's funny to compare the results... >> When you have finished your next paper (explaining it >> in more detail and other optimzation hints) I could >> probably convince myself to start to code such a beast... > >i'll try my best... >but i better write papers that bring some money back to >my pocket, too. My chocolate budget is very important ;-) Haven't seen a lot of chocolate for quite a while... ;-) >> >As a "HW guy", you certainly have enough background >> >to understand most things, so i'm only worried about >> >my own ability to teach them. >> Good teaching lessons BTW ;-) > >does that mean that you learned something ? >if yes ==> oh great ! ;-) Sorry, I can't help but learning... ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 10:45:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zDWM-0003Ke-00 for ; Sun, 21 Apr 2002 11:20:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 11:20:34 +0200 (CEST) Received: (qmail 14147 invoked by uid 0); 21 Apr 2002 08:43:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 21 Apr 2002 08:43:17 -0000 Received: by moria.seul.org (Postfix) id A1EFD1468F6; Sun, 21 Apr 2002 04:43:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9EF8C1468F5; Sun, 21 Apr 2002 04:43:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id D4A801468F2 for ; Sun, 21 Apr 2002 04:43:13 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zCyj-00073z-00 for f-cpu@seul.org; Sun, 21 Apr 2002 10:45:49 +0200 Date: Sun, 21 Apr 2002 10:45:49 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC242DB.5015CE4D@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >you know well that both of you have very good points and your antagonism >is a bit childish ;-P we'd like to have a solution that solves all our problems >without the hassles. Faith moves mountains... >> All computers wait at the same speed (unknown by me) >but all users are impatient ;-) because the users have such incredible slow IO? ;-) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 21 10:59:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zEE0-0003nR-00 for ; Sun, 21 Apr 2002 12:05:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 12:05:40 +0200 (CEST) Received: (qmail 23958 invoked by uid 0); 21 Apr 2002 09:16:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 21 Apr 2002 09:16:17 -0000 Received: by moria.seul.org (Postfix) id 6BE0C1468F1; Sun, 21 Apr 2002 05:16:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60E721468F3; Sun, 21 Apr 2002 05:16:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 255DA1468F1 for ; Sun, 21 Apr 2002 05:16:15 -0400 (EDT) Received: from ifurita (212.194.226.249) by mail.laposte.net (5.5.044) id 3CA06FFD003D6E40 for f-cpu@seul.org; Sun, 21 Apr 2002 11:16:14 +0200 Message-ID: <005001c1e912$d8d67120$f9e2c2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Sun, 21 Apr 2002 10:59:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >If you run a program once and want the result as fast as possible, > >a compiler is much better. But if you run it a million times, writing > >assembler code becomes pretty cheap. > > Maybe we are not living in the same world? In my world > products time to market is 6 to 12 months. The number > of codelines by far exceed 50000. If you are late with > the development or have performance impacts by design > it really costs. For calculation the assembler to C/C++ > ratio is set to 20 in time and cost. I was formerly an only-asm coder (I hated other languages), but I must admit it is not a viable point of view, especially if we need to reinvent the wheel when making assembly, whereas higher level language can help us to work on the essential parts. Besides, assembly code is the most difficult to maintain - just after the machine language of course ;). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 21 11:05:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zEE1-0003nR-00 for ; Sun, 21 Apr 2002 12:05:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 12:05:41 +0200 (CEST) Received: (qmail 20703 invoked by uid 0); 21 Apr 2002 09:22:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Apr 2002 09:22:28 -0000 Received: by moria.seul.org (Postfix) id D45781468F2; Sun, 21 Apr 2002 05:22:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCD2C1468F5; Sun, 21 Apr 2002 05:22:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 545F71468F2 for ; Sun, 21 Apr 2002 05:22:27 -0400 (EDT) Received: from ifurita (212.194.226.249) by mail.laposte.net (5.5.044) id 3CB2AF0B0016CD9F for f-cpu@seul.org; Sun, 21 Apr 2002 11:22:26 +0200 Message-ID: <005801c1e913$b6dd6e60$f9e2c2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Sun, 21 Apr 2002 11:05:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >and i won't give up this pleasure ;-) > >i would be very interested to see how such a parallel langage could > >be transformed into a sequential code. > >At least, the parallelism issues will disappear. > >The overload functions provide the user with transparent means > >to apply their algorithms on different data types. > >The event-driven model makes some more things easier (like > >the way functions are synchronised). > >I like these ideas :-) > >I don't want to use the ADA model verbatim, however. > > Yes, don't give up the parallel view. It is superior. ;-) Parallel execution is non-sense for uniprocessor and even multi-processor (each of them executes one sequential code). So I don't see the point. But I aggree that C language is more and more misadapted for modern microprocessors so that we should use a lot of trick too much. > >> I learned C because it is THE U**X language. > >but it's an oooooold langage :-( and it's not adapted > >to today's computers... > > You are working with oooooold operating systems BTW. > U**X is nearly as old as I am :-( but still superior > to MS. Yeah, the trouble is that the only OS which could be an alternative to MS is U**X which is a very ooooooooold concept. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 11:39:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOJ-0000ue-00 for ; Sun, 21 Apr 2002 20:48:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:48:51 +0200 (CEST) Received: (qmail 27817 invoked by uid 0); 21 Apr 2002 09:39:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 21 Apr 2002 09:39:44 -0000 Received: by moria.seul.org (Postfix) id A3A321468ED; Sun, 21 Apr 2002 05:39:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9EF5B1468F5; Sun, 21 Apr 2002 05:39:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 14C011468ED for ; Sun, 21 Apr 2002 05:39:43 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zDor-0003lZ-00 for f-cpu@seul.org; Sun, 21 Apr 2002 11:39:41 +0200 Date: Sun, 21 Apr 2002 11:39:39 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CC242C8.E7BC0F3A@f-cpu.org> Message-ID: References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > ;-] recently I started to use uClibc (for our embeeded apps) > > it is simple, complete and only 250kb SO (with 30k dynamic > > loader) > > arghflk ! > and how fast does this compile (compared to Glibc) ? :-) argh .. fucked pine .. I was writting reply 30 minutes and it crashed ;( Now I'm going to write again. Well look at www.uclibc.org. It compiles about five times faster here (IIRC) and it misses only a few parts - international support line iconv, gettext and some exotic functions (wordexp). > > Yes it is the best way - I know something about hw but not so > > much as you and other guys here. > some of your later comments later show that you're not clueless either. ;) I've learned a lot here. By the way do you know Bochs ? It would be interesting to change its cpu model to f-cpu and when compiler is ready you can emulate linux inside (as it have free bios and pci, vga,net,fdd and hdd model). > who shared their experience. In some places it looks like a worthless > compromise and in other places, where no existing solution exists, > new things are imagined. is the SRB such new idea ? It amazed me when I first saw it. > forget the concept of "simple logic" :-) at that scale, anything takes > time. Of course now, transmission takes more time than computation, but > even that has a "cost". I've been thinking about it last night and I think I understand now how tight it is these days. > that's acurate, even though now i'm less optimistic. > if i participate to FC1, i'll take more precautions > because it seems that FC0's register set will be the slowest > part of the whole core. I thing so. If you want a big paralelism and you want to feed N FUs simultaneously you need each FU to have its own port to the register file. It means that you need sum[i=0..N,eu_ports(i)] buses in register file. IIRC the average ILP in programs is about 4 so that we'd need about 16 ports to the RF. It seems way too much for me. As you've written later in this mail it seems you are convinced that some form of splitted set is neccesary (like in TTA) so that now I know that this part of debate is a bit void ;) I found some partialy interesting articles - nothing new but interesting: http://www.opencores.org/articles?cmd=view_article&id=4 http://www.opencores.org/projects/or2k/ > For example, nicO wants to reduce the number of ports and i thought > about a way to achieve that. However, making a 3r2w register set > with 1r1w blocks does not reduce the surface and the complexity because > a lot of things must be duplicated : > - you can do a 2r1w bank by using 2*1r1w blocks, so having 3 read ports > requires 3 identical blocks. > - you can't do a Xr2w bank as simply as a 2r1w bank because the data > must be written to all the sub-blocks. One solution is to use > some kind of FIFO that serializes the write but it's not a suitable > solution in this case. One solution i proposed was to ensure that > two simultaneous writes would not write the same sub-block, but this > can reduce the overall CPU efficiency. > > (i'll describe the trick later) I'm interested ;) Do you mean "one 64bit register latch" by sub-block term here ? I'm also interested how do you expect SMP to be created. As I spent many time with memory manager of linux I'm curious whether is will work with f-cpu SMP. Would it be kind of NUMA machine ? > the speed of the inverter is not directly linked to the frequency of the whole chip > because a lot of parameters have recently become prominent : Hmm did you read about the new BJT chip design ? I can't remember which university did it but they have working 3 ported 32x31 register set operating at 16GHz with only 20W of thermal loss. They use differential signal lines as pairs with low (200mV) swing. They planned to test 200GHz gate ... Only big problem is that they require pair of wires of the same length for each signal. > > You can do it on code which is one module with sources. The big advantage > > of compile/link is compile speed. I can't imagine developers to wait > > several hours when recompiling moderate project linked to glibc - you > > would have to compile glibc along with it to do global optimization.. > > But if it is only way to go for speed .. well. > > This depends on the local definition of speed. > When you develop an algorithm, compile time is moderately crucial. > Often, only small parts of the code base are modified, so incremental > compilation is possible (unless there's a avalanche effect). Then when > you are finished, you can let your computer run when you sleep for some > deep optimisations, if you want. And what about ABI ? Do you want to do these optimizations inside one compilation unit only or also between .so and binary ? The you will have no ABI and no closed software will run eficiently on it. On one side it can be good for open sw or OTOH it can make M$'s monopoly bigger - because it will no longer be possible to write efficient sw for closed-source OS. > There's an archive in Mexico (i forgot the URL). > it's a pretty large archive (around 20MB of files and attachments) I'll look for it ! 20MB is not so much for 10Mbit Internet pipe here :) > what do you think about this ? there's only a 1/8 overhead/bloat > and it's pretty portable accross different implementations > (recognize this opcode as NOP if not useful, extract only the needed > information otherwise...) Wonderfull ! The only word I can say :-> > 1: > loadimm 1, r1 ; // or something like that. > store r2, r1 ; // here, r2 already points to the location p, the address is > // "desambiguified" at execution (otherwise it would trap > // if a TLB miss occured). > 2: > load r3, r4 ; // like above, r3 already points to *q. If q==p, the value > // of r4 becomes this of r1. there might be a small delay > // (1 or 2 cycles at most) if no bypass is designed in the LSU. > 3: > add r2, r4, r2; // there's a bypass on the Xbar. The only bad surprise comes from > // the future reuse of r2 as a pointer without a previous explicit > // prefetch, a few cycles of penalty. my first estimations are > // less than i expected (1 or 2 cycles) but this will not be true > // in the future or in far-from-ideal cases. > maybe I misused the term disambiguation - I understand that code above will go just well. But often you can do this: loada r3, r4 ; start loading of r4, add r3 to disambig. mem (DM) loadimm 1, r1 store r2, r1 ; if r2 is in DM remove it verify r3, r4 ; if r3 is not in DM behave as load (instead as nop) add r2, r4, r2 So that loada will have a time to get the data during loadimm. IMHO this code should be faster (only one cycle in this particular case). But you can do it only if you are sure [r3] is not later changed by store. And you never know (at compile time) that two pointer's might be the same (if they are the same type). The verify is another cycle here so it is no win. But I've seen larger samples in IA64 docbook where much more was saved. But it is probably tied to superscalar architecture - in FC0 it will be simpler to do prefetch. So forget my kidding ;) regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 12:48:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOP-0000ue-00 for ; Sun, 21 Apr 2002 20:48:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:48:57 +0200 (CEST) Received: (qmail 29834 invoked by uid 0); 21 Apr 2002 10:48:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 21 Apr 2002 10:48:04 -0000 Received: by moria.seul.org (Postfix) id 0F2821468F5; Sun, 21 Apr 2002 06:48:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 05CEC1468F8; Sun, 21 Apr 2002 06:48:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 9CD551468F5 for ; Sun, 21 Apr 2002 06:48:01 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zEsy-00044u-00 for f-cpu@seul.org; Sun, 21 Apr 2002 12:48:00 +0200 Date: Sun, 21 Apr 2002 12:48:00 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <005001c1e912$d8d67120$f9e2c2d4@ifurita> Message-ID: References: <005001c1e912$d8d67120$f9e2c2d4@ifurita> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Maybe we are not living in the same world? In my world > > products time to market is 6 to 12 months. The number > > of codelines by far exceed 50000. If you are late with > > the development or have performance impacts by design > > it really costs. For calculation the assembler to C/C++ > > ratio is set to 20 in time and cost. > > I was formerly an only-asm coder (I hated other languages), but I must admit it > is not a viable point of view, especially if we need to reinvent the wheel when > making assembly, whereas higher level language can help us to work on the > essential parts. Besides, assembly code is the most difficult to maintain - > just after the machine language of course ;). About languages .. try http://tunes.org/Review/Languages.html devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 13:54:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOS-0000ue-00 for ; Sun, 21 Apr 2002 20:49:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:00 +0200 (CEST) Received: (qmail 15514 invoked by uid 0); 21 Apr 2002 11:51:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 21 Apr 2002 11:51:12 -0000 Received: by moria.seul.org (Postfix) id A9C111468F7; Sun, 21 Apr 2002 07:51:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3F1D1468F9; Sun, 21 Apr 2002 07:51:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B39CB1468F7 for ; Sun, 21 Apr 2002 07:51:11 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zFuu-0007EY-00 for f-cpu@seul.org; Sun, 21 Apr 2002 13:54:04 +0200 Date: Sun, 21 Apr 2002 13:54:04 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Martin Devera wrote: >> > Maybe we are not living in the same world? In my world >> > products time to market is 6 to 12 months. The number >> > of codelines by far exceed 50000. If you are late with >> > the development or have performance impacts by design >> > it really costs. For calculation the assembler to C/C++ >> > ratio is set to 20 in time and cost. >> >> I was formerly an only-asm coder (I hated other languages), but I must admit it >> is not a viable point of view, especially if we need to reinvent the wheel when >> making assembly, whereas higher level language can help us to work on the >> essential parts. Besides, assembly code is the most difficult to maintain - >> just after the machine language of course ;). > >About languages .. try http://tunes.org/Review/Languages.html >devik It doesn't help to compare languages. One has to learn them anyway and only if you practice for quite some time will the expertise build up. :-] JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 14:30:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOV-0000ue-00 for ; Sun, 21 Apr 2002 20:49:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:03 +0200 (CEST) Received: (qmail 16323 invoked by uid 0); 21 Apr 2002 12:30:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 21 Apr 2002 12:30:08 -0000 Received: by moria.seul.org (Postfix) id 683A01468F8; Sun, 21 Apr 2002 08:30:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FC871468FA; Sun, 21 Apr 2002 08:30:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E7CA51468F8 for ; Sun, 21 Apr 2002 08:30:05 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zGTk-0004aD-00 for f-cpu@seul.org; Sun, 21 Apr 2002 14:30:05 +0200 Date: Sun, 21 Apr 2002 14:30:04 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >About languages .. try http://tunes.org/Review/Languages.html > >devik > > > It doesn't help to compare languages. One has to learn > them anyway and only if you practice for quite some time > will the expertise build up. :-] I was not interested in pure compare. At the URL I found interesting info about each language regarding its suitability for concurent programing which is important for f-cpu IMHO. And also well written critique of C lang. Unfortunately C is too widely used and its codebase is still growing. It is probably good for things like kernel programing but seems to have still bigger problems with large userspace projects .. regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 15:24:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOV-0000ue-01 for ; Sun, 21 Apr 2002 20:49:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:03 +0200 (CEST) Received: (qmail 715 invoked by uid 0); 21 Apr 2002 13:21:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 21 Apr 2002 13:21:12 -0000 Received: by moria.seul.org (Postfix) id EDA651468FB; Sun, 21 Apr 2002 09:21:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDC1C1468FD; Sun, 21 Apr 2002 09:21:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B06261468FB for ; Sun, 21 Apr 2002 09:21:09 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zHKB-0007Gz-00 for f-cpu@seul.org; Sun, 21 Apr 2002 15:24:15 +0200 Date: Sun, 21 Apr 2002 15:24:15 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Martin Devera wrote: >> >About languages .. try http://tunes.org/Review/Languages.html >> >devik >> It doesn't help to compare languages. One has to learn >> them anyway and only if you practice for quite some time >> will the expertise build up. :-] > >I was not interested in pure compare. At the URL I found >interesting info about each language regarding its suitability >for concurent programing which is important for f-cpu IMHO. >And also well written critique of C lang. > >Unfortunately C is too widely used and its codebase is still >growing. It is probably good for things like kernel programing >but seems to have still bigger problems with large userspace >projects .. Hi, I agree with your comment that C is not a good language for large userspace projects. C was developed as a language to implement an operating system and I guess that's why you can also use it as a high level assembler. To my experience C++ did not improve that situation much but instead it enabled a developer to disguise the true program meaning by the possibility of redefinition of most of the constructs. In which case you end up with source code that is unmaintainable without the proper documentation. And by documentation I mean including the whole conceptual thoughts behind the program. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sun Apr 21 15:29:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOW-0000ue-00 for ; Sun, 21 Apr 2002 20:49:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:04 +0200 (CEST) Received: (qmail 30944 invoked by uid 0); 21 Apr 2002 13:24:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 21 Apr 2002 13:24:21 -0000 Received: by moria.seul.org (Postfix) id 690321468FC; Sun, 21 Apr 2002 09:24:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5DD501468FE; Sun, 21 Apr 2002 09:24:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf14bis.bellsouth.net (mail014.mail.bellsouth.net [205.152.58.34]) by moria.seul.org (Postfix) with ESMTP id 0A0D31468FC for ; Sun, 21 Apr 2002 09:24:20 -0400 (EDT) Received: from computer ([208.60.244.124]) by imf14bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020421132538.ORKI1979.imf14bis.bellsouth.net@computer>; Sun, 21 Apr 2002 09:25:38 -0400 Message-ID: <000801c1e938$a8bbb9c0$7cf43cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Erin64 Date: Sun, 21 Apr 2002 08:29:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1E90E.AB90EBE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1E90E.AB90EBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good morning from the Gulf of Mexico. A little History in the event = it isn't taught anymore. The reason processors currently have a lot of Hardware Registers = dates back to the early 1960's. Core Memory was slow (1.0 micro = second), so most companys used hardware to speed things up a bit. = Virtually all companys of the time did this except for ONE. Honeywell = Information Systems and that was the DDP-516. I am emulating that = Instruction Set Architecture (ISA) in my design of the Erin64 which has = a single Register that is used as an Accumulator. All other registers = are assigned with a Symbolic Assembler - the number is limited by the = size of Operand memory which is in my application a SSRAM having an = access time of 4.5 Nano seconds organized 64 by 256K. I am also going to capture what was a working Language written in = assembler code (9967 Instructions). During the re-work process we will = further hand optimize the resulting assembled code and taylor it to the = resulting hardware. =20 I will end with a distributed processing system (Not overly = distributed) having a Language Processor, a Peripheral Processor, and up = to 8 Math Co-processors serving up to 128 Users (CRT Monitors). There = is provision for "N" sub-systems beyond 128 Users. All being serviced = >from a single Hard Drive Disk of 80 GBytes. I have not directed the = Processor design to a "one size fits all" as you people are doing. I am = not competing with Intel and AMD as you people are doing. I am certain = they will come up with more answers while you are still in the "talking = phase." They do have a very large staff of hardware types and software = as well. However; I am not knocking your effort, it is very good = education AND I WISH YOU VERY GOOD LUCK IN YOUR EFFORT. Sincerely Richard E. Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C1E90E.AB90EBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Good morning from = the Gulf of=20 Mexico.  A little History in the event it isn't taught=20 anymore.
    The reason = processors currently=20 have a lot of Hardware Registers dates back to the early 1960's.  = Core=20 Memory was slow (1.0 micro second), so most companys used hardware to = speed=20 things up a bit.  Virtually all companys of the time did this = except for=20 ONE.  Honeywell Information Systems and that was the = DDP-516.  I=20 am emulating that Instruction Set Architecture (ISA) in my design of the = Erin64=20 which has a single Register that is used as an Accumulator.  All = other=20 registers are assigned with a Symbolic Assembler - the number is limited = by the=20 size of Operand memory which is in my application a SSRAM having an = access time=20 of 4.5 Nano seconds organized 64 by 256K.
    I am also going to = capture what=20 was a working Language written in assembler code (9967 = Instructions). =20 During the re-work process  we will further hand optimize the = resulting=20 assembled code and taylor it to the resulting hardware.  =
    I will end with a = distributed=20 processing system (Not overly distributed) having a Language Processor, = a=20 Peripheral Processor, and up to 8 Math Co-processors serving up to 128 = Users=20 (CRT Monitors).  There is provision for "N" sub-systems beyond 128=20 Users.  All being serviced from a single Hard Drive Disk of 80 = GBytes. I=20 have not directed the Processor design to a "one size fits all" as you = people=20 are doing.  I am not competing with Intel and AMD as you people are = doing.  I am certain they will come up with more answers while you = are=20 still in the "talking phase."  They do have a very large staff of = hardware=20 types and software as well.  However; I am not knocking your = effort, it is=20 very good education AND I WISH YOU VERY GOOD LUCK IN YOUR = EFFORT.
 
    = Sincerely
    Richard E. = Hartney
    Research = Director
    Erin Greene &=20 Associates
------=_NextPart_000_0005_01C1E90E.AB90EBE0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 15:27:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOX-0000ue-00 for ; Sun, 21 Apr 2002 20:49:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:05 +0200 (CEST) Received: (qmail 24683 invoked by uid 0); 21 Apr 2002 13:27:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Apr 2002 13:27:25 -0000 Received: by moria.seul.org (Postfix) id 6DED61468FD; Sun, 21 Apr 2002 09:27:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 543A31468FF; Sun, 21 Apr 2002 09:27:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D5BEA1468FD for ; Sun, 21 Apr 2002 09:27:23 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zHND-0004rJ-00 for f-cpu@seul.org; Sun, 21 Apr 2002 15:27:23 +0200 Date: Sun, 21 Apr 2002 15:27:23 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Hi, I agree with your comment that C is not a good > language for large userspace projects. C was developed > as a language to implement an operating system and I > guess that's why you can also use it as a high level > assembler. To my experience C++ did not improve that > situation much but instead it enabled a developer to > disguise the true program meaning by the possibility > of redefinition of most of the constructs. In which > case you end up with source code that is unmaintainable > without the proper documentation. And by documentation > I mean including the whole conceptual thoughts behind > the program. Exactly. I can't find language which would be good for these projects - I like Python put it can't be compiled eficiently AFAIK. Java is only hype-driven language with too many bugs in implementations and also not compilable simply... Have you some idea at which lang should one look ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pash.cracken@free.fr Sun Apr 21 15:35:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOX-0000ue-01 for ; Sun, 21 Apr 2002 20:49:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:05 +0200 (CEST) Received: (qmail 26444 invoked by uid 0); 21 Apr 2002 13:36:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 21 Apr 2002 13:36:09 -0000 Received: by moria.seul.org (Postfix) id 1AEBC146901; Sun, 21 Apr 2002 09:36:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 187BA146900; Sun, 21 Apr 2002 09:36:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-3-163.abo.wanadoo.fr [217.128.160.163]) by moria.seul.org (Postfix) with ESMTP id A46AF1468FE for ; Sun, 21 Apr 2002 09:36:08 -0400 (EDT) Received: from maturin ([127.0.0.1]) by maturin with smtp (Exim 3.35 #1 (Debian)) id 16zHVN-0000el-00 for ; Sun, 21 Apr 2002 15:35:49 +0200 Date: Sun, 21 Apr 2002 15:35:48 +0200 From: djrom To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Message-Id: <20020421153548.7470e460.pash.cracken@free.fr> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I've recently discovered GNU Sather (http://www.gnu.org/software/sather), which is a native-compiled, object-oriented langage. With a clean syntax and all the needed features of an OO langage (iterators, singletons, inheritance with renaming, ...), it's a very nice langage, which should definitively be tested. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 15:42:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOY-0000ue-00 for ; Sun, 21 Apr 2002 20:49:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:06 +0200 (CEST) Received: (qmail 9517 invoked by uid 0); 21 Apr 2002 13:40:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 21 Apr 2002 13:40:16 -0000 Received: by moria.seul.org (Postfix) id 03D1A1468FE; Sun, 21 Apr 2002 09:40:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C4BB9146900; Sun, 21 Apr 2002 09:40:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 93BC41468FE for ; Sun, 21 Apr 2002 09:40:13 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zHbq-0007K0-00 for f-cpu@seul.org; Sun, 21 Apr 2002 15:42:30 +0200 Date: Sun, 21 Apr 2002 15:42:30 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Martin Devera wrote: >> Hi, I agree with your comment that C is not a good >> language for large userspace projects. C was developed >> as a language to implement an operating system and I >> guess that's why you can also use it as a high level >> assembler. To my experience C++ did not improve that >> situation much but instead it enabled a developer to >> disguise the true program meaning by the possibility >> of redefinition of most of the constructs. In which >> case you end up with source code that is unmaintainable >> without the proper documentation. And by documentation >> I mean including the whole conceptual thoughts behind >> the program. > >Exactly. I can't find language which would be good for these >projects - I like Python put it can't be compiled eficiently >AFAIK. >Java is only hype-driven language with too many bugs in >implementations and also not compilable simply... >Have you some idea at which lang should one look ? Hmh, that's a very good question. What one would need is a language with a very good type checking like in Ada, Pascal, Modula a.s.o, a language that can do easy prototyping and reuse of coded parts like Forth, a language disallowing the side-effect programming styles, a language that can handle OO approaches and a language that is capable of parallel execution pathes. I can't remember which one has all these goods. Maybe it really is not yet available... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 15:42:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOY-0000ue-01 for ; Sun, 21 Apr 2002 20:49:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:06 +0200 (CEST) Received: (qmail 19204 invoked by uid 0); 21 Apr 2002 13:42:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 21 Apr 2002 13:42:59 -0000 Received: by moria.seul.org (Postfix) id 463B51468FF; Sun, 21 Apr 2002 09:42:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26BAB146902; Sun, 21 Apr 2002 09:42:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id BF6FD1468FF for ; Sun, 21 Apr 2002 09:42:57 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zHcG-0004wK-00; Sun, 21 Apr 2002 15:42:56 +0200 Date: Sun, 21 Apr 2002 15:42:55 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Cc: "Richard E. Hartny" Subject: Re: [f-cpu] Erin64 In-Reply-To: <000801c1e938$a8bbb9c0$7cf43cd0@computer> Message-ID: References: <000801c1e938$a8bbb9c0$7cf43cd0@computer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > distributed) having a Language Processor, a Peripheral Processor, and up > to 8 Math Co-processors serving up to 128 Users (CRT Monitors). There > is provision for "N" sub-systems beyond 128 Users. All being serviced > from a single Hard Drive Disk of 80 GBytes. I have not directed the > Processor design to a "one size fits all" as you people are doing. I am > not competing with Intel and AMD as you people are doing. I am certain > they will come up with more answers while you are still in the "talking > phase." They do have a very large staff of hardware types and software > as well. However; I am not knocking your effort, it is very good You are right - for example Linux was in similar position ten years ago. Now it is accepted by large companies not only because it is good, they start to feel danger of M$ monopoly for their own bussiness. Free cpu has harder position as you can't get it for free and test like sw. But some day motherboard makers, AMD and like may recognize that Intel works only with Intel MOBO and Intel MOBO can work only with M$ sw for example ... then they may feel ready to use something like proven free cpu with Linux and other sw already working .. People here invest much time to make f-cpu technicaly good. People at commercial companies focus often on: do it fast, good enough so it can be sell (and sometimes tricky enough so they will lock users to the product forever). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Apr 21 15:34:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOZ-0000ue-00 for ; Sun, 21 Apr 2002 20:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:07 +0200 (CEST) Received: (qmail 29275 invoked by uid 0); 21 Apr 2002 13:51:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Apr 2002 13:51:21 -0000 Received: by moria.seul.org (Postfix) id F3910146902; Sun, 21 Apr 2002 09:51:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CABEA146904; Sun, 21 Apr 2002 09:51:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 6157D146902 for ; Sun, 21 Apr 2002 09:51:20 -0400 (EDT) Received: from ifurita (212.194.214.169) by mail.laposte.net (5.5.044) id 3CA06FFD003D9D0D for f-cpu@seul.org; Sun, 21 Apr 2002 15:51:19 +0200 Message-ID: <001b01c1e939$445344c0$a9d6c2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Sun, 21 Apr 2002 15:34:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N What about CAML or derivatives ? :) You are speaking only about imperative languages, which, I think, is not very suitable in huge projects where we need to trust what we code. Anyway, I don't think C is the most efficient language. Some people considers it as a super assembler (register allocation, etc.), but in fact, the way you write a C program is underoptimized compared with an assembler : For example, to do a left bit rotation, you need to do in C : rotated_value = (value << shifter) | (((unsigned)value >> ((sizeof(value) * 8) - shifter)) & ((sizeof(value) * 256) - 1)); There is no C operator for that kind of bit operation and the generated code is not a 'rotl' but a mixture of 'shl' and 'or' operations. Using inline functions with asm ? not a standard. Depending on target, GCC is less or more efficient. Visual C++ or Borland asm directives are definitely bad (cannot tell which register is allocatable or clobbered in an asm directive). The way to code in C language is one way to code but not the most efficient : it is very easy to make buggy code even if each module has no bugs. ----- Original Message ----- From: Juergen Goeritz To: Sent: Sunday, April 21, 2002 3:24 PM Subject: Re: [f-cpu] Winograd DCT on my seul.org account > On Sun, 21 Apr 2002, Martin Devera wrote: > >> >About languages .. try http://tunes.org/Review/Languages.html > >> >devik > >> It doesn't help to compare languages. One has to learn > >> them anyway and only if you practice for quite some time > >> will the expertise build up. :-] > > > >I was not interested in pure compare. At the URL I found > >interesting info about each language regarding its suitability > >for concurent programing which is important for f-cpu IMHO. > >And also well written critique of C lang. > > > >Unfortunately C is too widely used and its codebase is still > >growing. It is probably good for things like kernel programing > >but seems to have still bigger problems with large userspace > >projects .. > > Hi, I agree with your comment that C is not a good > language for large userspace projects. C was developed > as a language to implement an operating system and I > guess that's why you can also use it as a high level > assembler. To my experience C++ did not improve that > situation much but instead it enabled a developer to > disguise the true program meaning by the possibility > of redefinition of most of the constructs. In which > case you end up with source code that is unmaintainable > without the proper documentation. And by documentation > I mean including the whole conceptual thoughts behind > the program. > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 16:29:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOg-0000ue-00 for ; Sun, 21 Apr 2002 20:49:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:14 +0200 (CEST) Received: (qmail 22826 invoked by uid 0); 21 Apr 2002 14:26:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 21 Apr 2002 14:26:02 -0000 Received: by moria.seul.org (Postfix) id DF64B146903; Sun, 21 Apr 2002 10:26:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A01D3146905; Sun, 21 Apr 2002 10:26:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 7BAA4146903 for ; Sun, 21 Apr 2002 10:25:59 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zIKv-0007N2-00 for f-cpu@seul.org; Sun, 21 Apr 2002 16:29:05 +0200 Date: Sun, 21 Apr 2002 16:29:05 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, forgot two things in my list of appreciated qualities of that ultimative language: - easy readability, easy learning, easy debugging. - easy simulation of unimplemented parts (e.g. like the test stimulation possibilities in VHDL) - integrated abstract layer documentation scheme that could be extended to automatic code generation. Very large scale projects usually lack of early test possibilities. The best way of implementation always lets you have something to show to the customer, even in very early stages already. JG On Sun, 21 Apr 2002, Juergen Goeritz wrote: >Hmh, that's a very good question. > >What one would need is a language with a very good >type checking like in Ada, Pascal, Modula a.s.o, a >language that can do easy prototyping and reuse of >coded parts like Forth, a language disallowing the >side-effect programming styles, a language that can >handle OO approaches and a language that is capable >of parallel execution pathes. > >I can't remember which one has all these goods. >Maybe it really is not yet available... > >JG > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 16:39:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOh-0000ue-00 for ; Sun, 21 Apr 2002 20:49:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:15 +0200 (CEST) Received: (qmail 23247 invoked by uid 0); 21 Apr 2002 14:41:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 21 Apr 2002 14:41:23 -0000 Received: by moria.seul.org (Postfix) id 201A8146904; Sun, 21 Apr 2002 10:41:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 12E5E146906; Sun, 21 Apr 2002 10:41:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 9296F146904 for ; Sun, 21 Apr 2002 10:41:22 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LEgh4l081747 for ; Sun, 21 Apr 2002 08:42:44 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2CF0B.A6E21645@jetnet.ab.ca> Date: Sun, 21 Apr 2002 08:39:07 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Martin Devera wrote: > Hmm did you read about the new BJT chip design ? I can't remember which > university did it but they have working 3 ported 32x31 register set > operating at 16GHz with only 20W of thermal loss. They use differential > signal lines as pairs with low (200mV) swing. They planned to test 200GHz > gate ... Only big problem is that they require pair of wires of the > same length for each signal. I am guessing on this but would not the fact the lines are differntial make error detection more likely in a high speed computer and have things slow down while any noise happens or at least give a error? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 21 16:53:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOh-0000ue-01 for ; Sun, 21 Apr 2002 20:49:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:15 +0200 (CEST) Received: (qmail 16060 invoked by uid 0); 21 Apr 2002 14:53:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 21 Apr 2002 14:53:37 -0000 Received: by moria.seul.org (Postfix) id 587E9146905; Sun, 21 Apr 2002 10:53:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45714146907; Sun, 21 Apr 2002 10:53:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E6A86146905 for ; Sun, 21 Apr 2002 10:53:35 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zIic-0005IT-00 for f-cpu@seul.org; Sun, 21 Apr 2002 16:53:34 +0200 Date: Sun, 21 Apr 2002 16:53:34 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CC2CF0B.A6E21645@jetnet.ab.ca> Message-ID: References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <3CC2CF0B.A6E21645@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > university did it but they have working 3 ported 32x31 register set > > operating at 16GHz with only 20W of thermal loss. They use differential > > signal lines as pairs with low (200mV) swing. They planned to test 200GHz > > gate ... Only big problem is that they require pair of wires of the > > same length for each signal. > I am guessing on this but would not the fact the lines are differntial > make error detection more likely in a high speed computer and have > things slow down while any noise happens or at least give a error? AFAIK the differential signal is more immune to a noise because error signal is induced to both lines equaly and difference potential still holds. Especially in BJT design where some current flows thru these wires. Intel Rambus with Yellowstone technology uses 300mV swing and doesn't seem to have problems even with MOS inputs (but they have terminators AFAIK). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 16:53:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOi-0000ue-00 for ; Sun, 21 Apr 2002 20:49:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:16 +0200 (CEST) Received: (qmail 329 invoked by uid 0); 21 Apr 2002 14:55:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 21 Apr 2002 14:55:57 -0000 Received: by moria.seul.org (Postfix) id BF0BC146906; Sun, 21 Apr 2002 10:55:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9338146908; Sun, 21 Apr 2002 10:55:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 364EC146906 for ; Sun, 21 Apr 2002 10:55:55 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LEvG4l083412 for ; Sun, 21 Apr 2002 08:57:17 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2D274.5D4C1745@jetnet.ab.ca> Date: Sun, 21 Apr 2002 08:53:40 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Sun, 21 Apr 2002, Martin Devera wrote: > >> >About languages .. try http://tunes.org/Review/Languages.html > >> >devik > >> It doesn't help to compare languages. One has to learn > >> them anyway and only if you practice for quite some time > >> will the expertise build up. :-] > > > >I was not interested in pure compare. At the URL I found > >interesting info about each language regarding its suitability > >for concurent programing which is important for f-cpu IMHO. > >And also well written critique of C lang. > > > >Unfortunately C is too widely used and its codebase is still > >growing. It is probably good for things like kernel programing > >but seems to have still bigger problems with large userspace > >projects .. > > Hi, I agree with your comment that C is not a good > language for large userspace projects. C was developed > as a language to implement an operating system and I > guess that's why you can also use it as a high level > assembler. To my experience C++ did not improve that > situation much but instead it enabled a developer to > disguise the true program meaning by the possibility > of redefinition of most of the constructs. In which > case you end up with source code that is unmaintainable > without the proper documentation. And by documentation > I mean including the whole conceptual thoughts behind > the program. The documentation part is true of any langauge. Asm programing has a bad name because early assemblers often had 6 char labels, 3 char memonics and a few K of memory space. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 16:56:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOj-0000ue-00 for ; Sun, 21 Apr 2002 20:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:17 +0200 (CEST) Received: (qmail 29720 invoked by uid 0); 21 Apr 2002 14:59:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 21 Apr 2002 14:59:06 -0000 Received: by moria.seul.org (Postfix) id 4D94214690A; Sun, 21 Apr 2002 10:59:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A952146909; Sun, 21 Apr 2002 10:59:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id B2553146907 for ; Sun, 21 Apr 2002 10:59:04 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LF0Q4l083729 for ; Sun, 21 Apr 2002 09:00:26 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2D331.88A0011D@jetnet.ab.ca> Date: Sun, 21 Apr 2002 08:56:49 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Martin Devera wrote: > Exactly. I can't find language which would be good for these > projects - I like Python put it can't be compiled eficiently > AFAIK. > Java is only hype-driven language with too many bugs in > implementations and also not compilable simply... > Have you some idea at which lang should one look ? No , but here is a intersting one. http://pliant.cx/ -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 17:00:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOj-0000ue-01 for ; Sun, 21 Apr 2002 20:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:17 +0200 (CEST) Received: (qmail 8490 invoked by uid 0); 21 Apr 2002 15:02:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 21 Apr 2002 15:02:41 -0000 Received: by moria.seul.org (Postfix) id DCBCE146907; Sun, 21 Apr 2002 11:02:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C8A59146909; Sun, 21 Apr 2002 11:02:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 3FE32146907 for ; Sun, 21 Apr 2002 11:02:39 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LF404l084077 for ; Sun, 21 Apr 2002 09:04:01 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2D408.B9F97E4E@jetnet.ab.ca> Date: Sun, 21 Apr 2002 09:00:24 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Sun, 21 Apr 2002, Martin Devera wrote: > > >> Hi, I agree with your comment that C is not a good > >> language for large userspace projects. C was developed > >> as a language to implement an operating system and I > >> guess that's why you can also use it as a high level > >> assembler. To my experience C++ did not improve that > >> situation much but instead it enabled a developer to > >> disguise the true program meaning by the possibility > >> of redefinition of most of the constructs. In which > >> case you end up with source code that is unmaintainable > >> without the proper documentation. And by documentation > >> I mean including the whole conceptual thoughts behind > >> the program. > > > >Exactly. I can't find language which would be good for these > >projects - I like Python put it can't be compiled eficiently > >AFAIK. > >Java is only hype-driven language with too many bugs in > >implementations and also not compilable simply... > >Have you some idea at which lang should one look ? > > Hmh, that's a very good question. > > What one would need is a language with a very good > type checking like in Ada, Pascal, Modula a.s.o, a > language that can do easy prototyping and reuse of > coded parts like Forth, a language disallowing the > side-effect programming styles, a language that can > handle OO approaches and a language that is capable > of parallel execution pathes. > I would add "Small" and "bootstrap-able". I never could under stand object programing as once you have more than a few operations you never know what the program will do. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Sun Apr 21 17:11:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOk-0000ue-00 for ; Sun, 21 Apr 2002 20:49:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:18 +0200 (CEST) Received: (qmail 10982 invoked by uid 0); 21 Apr 2002 15:08:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 21 Apr 2002 15:08:47 -0000 Received: by moria.seul.org (Postfix) id B471414690C; Sun, 21 Apr 2002 11:08:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFBC914690B; Sun, 21 Apr 2002 11:08:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id CF44E146908 for ; Sun, 21 Apr 2002 11:08:43 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zJ0M-0007Rn-00 for f-cpu@seul.org; Sun, 21 Apr 2002 17:11:54 +0200 Date: Sun, 21 Apr 2002 17:11:54 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC2D408.B9F97E4E@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Ben Franchuk wrote: >Juergen Goeritz wrote: >> >> On Sun, 21 Apr 2002, Martin Devera wrote: >> >> >> Hi, I agree with your comment that C is not a good >> >> language for large userspace projects. C was developed >> >> as a language to implement an operating system and I >> >> guess that's why you can also use it as a high level >> >> assembler. To my experience C++ did not improve that >> >> situation much but instead it enabled a developer to >> >> disguise the true program meaning by the possibility >> >> of redefinition of most of the constructs. In which >> >> case you end up with source code that is unmaintainable >> >> without the proper documentation. And by documentation >> >> I mean including the whole conceptual thoughts behind >> >> the program. >> > >> >Exactly. I can't find language which would be good for these >> >projects - I like Python put it can't be compiled eficiently >> >AFAIK. >> >Java is only hype-driven language with too many bugs in >> >implementations and also not compilable simply... >> >Have you some idea at which lang should one look ? >> >> Hmh, that's a very good question. >> >> What one would need is a language with a very good >> type checking like in Ada, Pascal, Modula a.s.o, a >> language that can do easy prototyping and reuse of >> coded parts like Forth, a language disallowing the >> side-effect programming styles, a language that can >> handle OO approaches and a language that is capable >> of parallel execution pathes. >> >I would add "Small" and "bootstrap-able". I never could under stand >object programing as once you have more than a few operations you never >know what the program will do. Hey, we were talking about very large scale projects in userspace BTW. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 17:18:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOk-0000ue-01 for ; Sun, 21 Apr 2002 20:49:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:18 +0200 (CEST) Received: (qmail 18538 invoked by uid 0); 21 Apr 2002 15:21:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 21 Apr 2002 15:21:12 -0000 Received: by moria.seul.org (Postfix) id 01632146908; Sun, 21 Apr 2002 11:21:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E513914690B; Sun, 21 Apr 2002 11:21:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 3F824146908 for ; Sun, 21 Apr 2002 11:21:10 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LFMV4l086279 for ; Sun, 21 Apr 2002 09:22:32 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2D85F.8F98A6D0@jetnet.ab.ca> Date: Sun, 21 Apr 2002 09:18:55 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Erin64 References: <000801c1e938$a8bbb9c0$7cf43cd0@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N richard hartny wrote: Having used a PDP-8 one finds that is another single primary register computer. 5 registers - PC,AC,MAR,MDR,IR. With core memory several times slower than internal operations and needing a write back cycle, it made more sense to have a read/modify/write architecture than a load/store one that is used today. Many early machines had the option of index registers as slow core, or high speed registers. I think you are right that with routing delays growing compared with transistor switching speed shrinking, the old architecture's will make a come back. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sun Apr 21 17:41:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOl-0000ue-00 for ; Sun, 21 Apr 2002 20:49:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:19 +0200 (CEST) Received: (qmail 3889 invoked by uid 0); 21 Apr 2002 15:35:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Apr 2002 15:35:26 -0000 Received: by moria.seul.org (Postfix) id 7F49E146909; Sun, 21 Apr 2002 11:35:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B1B314690D; Sun, 21 Apr 2002 11:35:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf24bis.bellsouth.net (mail124.mail.bellsouth.net [205.152.58.84]) by moria.seul.org (Postfix) with ESMTP id EC900146909 for ; Sun, 21 Apr 2002 11:35:24 -0400 (EDT) Received: from computer ([209.214.154.41]) by imf24bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020421153523.DIGE9906.imf24bis.bellsouth.net@computer> for ; Sun, 21 Apr 2002 11:35:23 -0400 Message-ID: <000a01c1e94a$fc4de6a0$299ad6d1@computer> From: "richard hartny" To: Subject: [f-cpu] Erin64 Date: Sun, 21 Apr 2002 10:41:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1E921.12C864C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1E921.12C864C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Ben - you made my day, and then some. The FPGA I am targeting = has on-chip RAM - however - when you surround it with supporting logic; I found it slower than using = external SSRAM from Cypress Semiconductor. Dick Hartney ------=_NextPart_000_0007_01C1E921.12C864C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Ben - you made my day, and then = some. =20 The FPGA I am targeting has on-chip RAM - however - when
you surround it with supporting logic; = I found it=20 slower than using external SSRAM from Cypress = Semiconductor.
 
Dick Hartney
------=_NextPart_000_0007_01C1E921.12C864C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Apr 21 17:35:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOl-0000ue-01 for ; Sun, 21 Apr 2002 20:49:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:19 +0200 (CEST) Received: (qmail 21473 invoked by uid 0); 21 Apr 2002 15:37:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 21 Apr 2002 15:37:57 -0000 Received: by moria.seul.org (Postfix) id 6695A14690B; Sun, 21 Apr 2002 11:37:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C85114690E; Sun, 21 Apr 2002 11:37:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id E027D14690B for ; Sun, 21 Apr 2002 11:37:55 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.incentre.net (8.12.2/8.11.6) with ESMTP id g3LFdH4l088264 for ; Sun, 21 Apr 2002 09:39:17 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC2DC4C.DEA307C5@jetnet.ab.ca> Date: Sun, 21 Apr 2002 09:35:40 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > >I would add "Small" and "bootstrap-able". I never could under stand > >object programing as once you have more than a few operations you never > >know what the program will do. > > Hey, we were talking about very large scale projects in > userspace BTW. All the more reason for small and bootstrap-able and self compile. We have this great NEW language but you need X-windows, BASH shell, make, perl , C++ (ver 99,999) and bison and flex to compile it with XXX and YYY and ZZZ libraries. Sigh! I still think a REAL OS with well designed hardware can be small as well at the compilers and other system tools. BTW I am not a fan of dynamic libraries as you have version problems galore. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Apr 21 17:37:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zMOm-0000ue-00 for ; Sun, 21 Apr 2002 20:49:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 21 Apr 2002 20:49:20 +0200 (CEST) Received: (qmail 6004 invoked by uid 0); 21 Apr 2002 16:26:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 21 Apr 2002 16:26:23 -0000 Received: by moria.seul.org (Postfix) id 7153C14690D; Sun, 21 Apr 2002 12:26:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6C53E146910; Sun, 21 Apr 2002 12:26:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 3235C14690D for ; Sun, 21 Apr 2002 12:26:22 -0400 (EDT) Received: from ifrance.com (vlt10-245.n.club-internet.fr [195.36.224.245]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 74CF11705 for ; Sun, 21 Apr 2002 18:26:20 +0200 (CEST) Message-ID: <3CC2DCD1.56FFDC3C@ifrance.com> Date: Sun, 21 Apr 2002 17:37:53 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Some answer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Argh ! 92 messages ! Define a generic representation of code to write different compiler are very hard. The big example is why gcc couldn't produice an output in java byte code. JVM are simply a "virtual processor", so it will be nice that gcc could compile for this target. But it's a stack machine not a register based one. And the semantic of the intermediate representation are too poor to be used. Our register set is definitely 3r 2W, i don't like it too much for performance reason but why using it better. One off the main problem are exepntion handler. Couldn't it be possible to use the second register to output the state without traping (imagine the DIV instruction, the second register will say if a div by zero occur or an overflow occur,...). If the system need a trap an instruction should verify the regiter otherwise it could do nothing. What do you think of it ? For the floating point unit, we should provid 128 bits extended floating point precision for the day of the register set will double. What about written a asm optimiser which could be used as backend for every different language compiler ? VHDL could never be used to write SW. It's too poor ! IO fonction are too poor. Nowdays HW world try to find an other way to code to a higher level. SystemC are the best canditate (C++ + a lib), but there is other proposal (VHDL-OO, UML-RT, new langage...) read you soon ! nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Sun Apr 21 18:26:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zQDx-00040d-00 for ; Mon, 22 Apr 2002 00:54:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 00:54:25 +0200 (CEST) Received: (qmail 31055 invoked by uid 0); 21 Apr 2002 19:50:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 21 Apr 2002 19:50:04 -0000 Received: by moria.seul.org (Postfix) id 777F014690F; Sun, 21 Apr 2002 15:50:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EC2A146912; Sun, 21 Apr 2002 15:50:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 1B32714690F for ; Sun, 21 Apr 2002 15:50:01 -0400 (EDT) Received: from art1.none.de ([62.144.184.218]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g3LJo4r20283 for ; Sun, 21 Apr 2002 21:50:04 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.144.184.218] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16zKBI-0001o7-00 for ; Sun, 21 Apr 2002 18:27:16 +0200 Date: Sun, 21 Apr 2002 18:26:36 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC242DB.5015CE4D@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > code once, and i sworn i'll never do that again. We need something that > eases asm programming, beyond macros and other low-level constructs : > something that treats code blocks as a complex object with its dependencies, > register allocations, parameters... and that the programmer can handle > as easily as drag-n-drop. when dropped, the register allocation is > done automatically, according to the programmer's settings. Remember, forth can do this... and surplus you can test forth-code interactively... Bye Art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8wug/ClxplZklbgERAjHhAKCZbBwc9lRH/S+eK8gC81QKGjuH4wCeKQoR oL0EjUWe3yMNV7T61UApXSI= =Mym/ -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 22:14:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zQDx-00040d-01 for ; Mon, 22 Apr 2002 00:54:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 00:54:25 +0200 (CEST) Received: (qmail 32200 invoked by uid 0); 21 Apr 2002 20:08:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Apr 2002 20:08:20 -0000 Received: by moria.seul.org (Postfix) id 78105146911; Sun, 21 Apr 2002 16:08:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6963E146913; Sun, 21 Apr 2002 16:08:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 2D8A2146911 for ; Sun, 21 Apr 2002 16:08:18 -0400 (EDT) Received: from f-cpu.org (kdl11-226.n.club-internet.fr [213.44.9.226]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 5E4881C98 for ; Sun, 21 Apr 2002 22:08:14 +0200 (CEST) Message-ID: <3CC31DBD.EB4EB775@f-cpu.org> Date: Sun, 21 Apr 2002 22:14:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Some answer References: <3CC2DCD1.56FFDC3C@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nico wrote: > Argh ! 92 messages ! this list is very "cyclotimic" :-) > Define a generic representation of code to write different compiler are > very hard. The big example is why gcc couldn't produice an output in > java byte code. JVM are simply a "virtual processor", so it will be nice > that gcc could compile for this target. But it's a stack machine not a > register based one. And the semantic of the intermediate representation > are too poor to be used. Add to that other parameters, such as the programmer's tastes (we have a good sample of different opinions in this list) and some corporate pressures, and the panorama becomes even more fuzzy. but don't forget that the goal of the project is to make the best CPU possible, that's all ;-) > Our register set is definitely 3r 2W, i don't like it too much for > performance reason but why using it better. One off the main problem are > exepntion handler. Couldn't it be possible to use the second register to > output the state without traping (imagine the DIV instruction, the > second register will say if a div by zero occur or an overflow > occur,...). If the system need a trap an instruction should verify the > regiter otherwise it could do nothing. What do you think of it ? i am not sure to understand what you write... for IDIV the instruction is "issued" if the zero flags are not set. it's already in the manual i think. it doesn't use the usual register read ports but the attribute bits. for the rest, i don't clearly understand. Maybe if you write in french... > For the floating point unit, we should provid 128 bits extended floating > point precision for the day of the register set will double. if you want to implement it... go ahead... but this has been discussed earlier, it's not necessary or useful. > What about written a asm optimiser which could be used as backend for > every different language compiler ? we're discussing something like that now. > VHDL could never be used to write SW. It's too poor ! IO fonction are too poor. VHDL is only the core of the thing. There are the std-XXXX libraries and the effort for adding POSIX I/O. But if i want to use a VHDL-like programming langage, i will no doubt correct some of the little problems it has. i'm not masochist ;-) > Nowdays HW world try to find an other way to code to a higher > level. SystemC are the best canditate (C++ + a lib), i think it's funny : C is lower-level than VHDL (ADA), and people want it to be higher level than VHDL. i think that a few (only, but anyway) people of this list laugh :-) > but there is other proposal (VHDL-OO, UML-RT, new langage...) we know that System-C or something like that will emerge. unfortunately, the companies that promote them are bad at planning for the very long term. > read you soon ! ans see you if you have time ! > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 21 22:56:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zQDz-00040d-00 for ; Mon, 22 Apr 2002 00:54:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 00:54:27 +0200 (CEST) Received: (qmail 28653 invoked by uid 0); 21 Apr 2002 20:50:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 21 Apr 2002 20:50:20 -0000 Received: by moria.seul.org (Postfix) id 7522D146912; Sun, 21 Apr 2002 16:50:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E2F5146914; Sun, 21 Apr 2002 16:50:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 0E84D146912 for ; Sun, 21 Apr 2002 16:50:19 -0400 (EDT) Received: from f-cpu.org (kdl16-170.n.club-internet.fr [213.44.18.170]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 0D06A173D for ; Sun, 21 Apr 2002 22:50:14 +0200 (CEST) Message-ID: <3CC32795.9BEF4A02@f-cpu.org> Date: Sun, 21 Apr 2002 22:56:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hallo, Andreas Romeyke wrote: > Hello, > > code once, and i sworn i'll never do that again. We need something that > > eases asm programming, beyond macros and other low-level constructs : > > something that treats code blocks as a complex object with its dependencies, > > register allocations, parameters... and that the programmer can handle > > as easily as drag-n-drop. when dropped, the register allocation is > > done automatically, according to the programmer's settings. > > Remember, forth can do this... and surplus you can test forth-code > interactively... Forth is an incredible language but it can't do all i want, or i would use it for a loooong time. It also introduces a lot of things that can interfere with the algorithms, or at least make you forget about what you want to do. Finally, the largest scope that i could globally optimize by hand is 100 or 120 instructions per block. we need to go beyond that. Forth is the contrary of a dataflow graph analysis tool because it over-serialises the computations. > Bye Art1 Juergen Goeritz wrote: > Hi, > > forgot two things in my list of appreciated qualities > of that ultimative language: > > - easy readability, easy learning, easy debugging. > - easy simulation of unimplemented parts (e.g. like > the test stimulation possibilities in VHDL) > - integrated abstract layer documentation scheme > that could be extended to automatic code generation. > > Very large scale projects usually lack of early test > possibilities. The best way of implementation always > lets you have something to show to the customer, even > in very early stages already. at least, with a good VHDL background, you're used to write a lot of testbenches. that's one good reason to reuse of lot of its concepts. I think about this program : - 1) make a dumb but flexible backend for, but not tied to, gcc - 2) enhance the backend - 3) create a VHLD-like frontend (without the hassles). - 4) create some basic libraries. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 00:07:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zQE1-00040d-00 for ; Mon, 22 Apr 2002 00:54:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 00:54:29 +0200 (CEST) Received: (qmail 14971 invoked by uid 0); 21 Apr 2002 22:01:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 21 Apr 2002 22:01:10 -0000 Received: by moria.seul.org (Postfix) id B53DB146913; Sun, 21 Apr 2002 18:01:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 757DE146915; Sun, 21 Apr 2002 18:01:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 1ACB6146913 for ; Sun, 21 Apr 2002 18:01:08 -0400 (EDT) Received: from f-cpu.org (kdl16-135.n.club-internet.fr [213.44.18.135]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 2F98E1756 for ; Mon, 22 Apr 2002 00:01:05 +0200 (CEST) Message-ID: <3CC3382F.55FC69AD@f-cpu.org> Date: Mon, 22 Apr 2002 00:07:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <005801c1e913$b6dd6e60$f9e2c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Christophe wrote: > > >and i won't give up this pleasure ;-) > > >i would be very interested to see how such a parallel langage could > > >be transformed into a sequential code. > > >At least, the parallelism issues will disappear. > > >The overload functions provide the user with transparent means > > >to apply their algorithms on different data types. > > >The event-driven model makes some more things easier (like > > >the way functions are synchronised). > > >I like these ideas :-) > > >I don't want to use the ADA model verbatim, however. > > > > Yes, don't give up the parallel view. It is superior. ;-) i think we understand each other :o) > Parallel execution is non-sense for uniprocessor and even multi-processor (each > of them executes one sequential code). So I don't see the point. i don't have the courage to prove the contrary tonight. Maybe you will see the point if you do more application programming and see that the reason why computers are so slow is because they are so inherently serialised. A "parallel" langage has the purpose of showing what is independent from what, it doesn't force you to use a parallel machine. and multithread support if an old issue in the OS community. C does not expose enough parallelism and requires explicit stuff which makes heavier. > But I aggree that C language is more and more misadapted for modern > microprocessors so that we should use a lot of trick too much. we live in difficult times... > > >> I learned C because it is THE U**X language. > > >but it's an oooooold langage :-( and it's not adapted > > >to today's computers... > > You are working with oooooold operating systems BTW. > > U**X is nearly as old as I am :-( but still superior > > to MS. > Yeah, the trouble is that the only OS which could be an alternative to MS is > U**X which is a very ooooooooold concept. old but rather good, because this model evolved and scaled rather well. unlike C. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 21 14:17:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zQE1-00040d-01 for ; Mon, 22 Apr 2002 00:54:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 00:54:29 +0200 (CEST) Received: (qmail 20248 invoked by uid 0); 21 Apr 2002 22:15:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Apr 2002 22:15:08 -0000 Received: by moria.seul.org (Postfix) id 0B212146914; Sun, 21 Apr 2002 18:15:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F3422146916; Sun, 21 Apr 2002 18:15:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a146.home.uni-hannover.de [130.75.232.146]) by moria.seul.org (Postfix) with ESMTP id 29EC5146914 for ; Sun, 21 Apr 2002 18:15:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00658; Sun, 21 Apr 2002 14:17:55 +0200 Message-ID: <20020421141755.48152@thrai.stud.uni-hannover.de> Date: Sun, 21 Apr 2002 14:17:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Martin Devera on Sun, Apr 21, 2002 at 11:39:39AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 21, 2002 at 11:39:39AM +0200, Martin Devera wrote: [...] > maybe I misused the term disambiguation - I understand that code > above will go just well. But often you can do this: > loada r3, r4 ; start loading of r4, add r3 to disambig. mem (DM) > loadimm 1, r1 > store r2, r1 ; if r2 is in DM remove it > verify r3, r4 ; if r3 is not in DM behave as load (instead as nop) > add r2, r4, r2 > > So that loada will have a time to get the data during loadimm. > IMHO this code should be faster (only one cycle in this particular > case). Speculative loads can probably be implemented in a similar manner as the load-linked/conditional-store instructions we've been talking about recently. When `loada' is executed, mark the corresponding bytes in the cache, and reset the markers whenever an instruction modifies the loaded data. If the markers aren't all set (or the cache line was flushed), the `verify' instruction will trap, jump to a piece of fixup code, or simply re-load the modified bytes. The drawback of this approach is that it doesn't work well if the same bytes are loaded more than once, or if the loaded register is overwritten. I'm not sure how the Itanium handles that case, however. The other (probably more expensive) solution is a table that maps register numbers to (virtual or physical) addresses. When a register is loaded, make a new entry in the table; when the loaded data is modified or the register is clobbered, remove or invalidate the entry. > But you can do it only if you are sure [r3] is not later changed > by store. And you never know (at compile time) that two pointer's > might be the same (if they are the same type). That's why ISO C99 adds the `restrict' pointer qualifier. E.g. you write void copy(char *restrict dest, const char *restrict src, size_t len) { ... } and the compiler will assume that source and destination do not overlap. That is, it does not need to disambiguate those pointers. Of course programmers have to be more careful -- calls like copy(array, array + 1, 10); will produce unspecified results. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 02:07:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zSL6-0005ZD-00 for ; Mon, 22 Apr 2002 03:09:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 03:09:56 +0200 (CEST) Received: (qmail 23481 invoked by uid 0); 22 Apr 2002 00:01:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Apr 2002 00:01:03 -0000 Received: by moria.seul.org (Postfix) id D5ABD146917; Sun, 21 Apr 2002 20:01:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D066A146919; Sun, 21 Apr 2002 20:01:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 46AB3146917 for ; Sun, 21 Apr 2002 20:01:01 -0400 (EDT) Received: from f-cpu.org (kdl11-38.n.club-internet.fr [213.44.9.38]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 84CA31684 for ; Mon, 22 Apr 2002 02:00:55 +0200 (CEST) Message-ID: <3CC35445.612C3036@f-cpu.org> Date: Mon, 22 Apr 2002 02:07:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Martin Devera wrote: > > > ;-] recently I started to use uClibc (for our embeeded apps) > > > it is simple, complete and only 250kb SO (with 30k dynamic > > > loader) > > > > arghflk ! > > and how fast does this compile (compared to Glibc) ? :-) > > argh .. fucked pine .. I was writting reply 30 minutes and it crashed ;( > Now I'm going to write again. this doesn't only happen with pine ;-) Fortunately, Netscape designed the "save as draft" button ;-P > > > Yes it is the best way - I know something about hw but not so > > > much as you and other guys here. > > some of your later comments later show that you're not clueless either. > ;) I've learned a lot here. me too, and i think a lot of other people. In that respect, even if no prototype ever gets made, F-CPU can't be a failure. > By the way do you know Bochs ? It would > be interesting to change its cpu model to f-cpu and when compiler > is ready you can emulate linux inside (as it have free bios and pci, > vga,net,fdd and hdd model). mmm IIRC, Bochs is not GNU ? It makes the same problem as a plain C simulator : we already have to deal with a VHDL source tree and there are too few contributors yet. we can't hire anybody, you know : it's all volunteer work. when work is done. > > who shared their experience. In some places it looks like a worthless > > compromise and in other places, where no existing solution exists, > > new things are imagined. > is the SRB such new idea ? It amazed me when I first saw it. after some research, i think that some other computers use this kind of technique but i'm not sure. SRB was created when writing a mail during the "how many registers" thread and it is closely related to the FC0 architecture but it is possible to find a similar principle in the i860, maybe (or is it i960 ?) > > forget the concept of "simple logic" :-) at that scale, anything takes > > time. Of course now, transmission takes more time than computation, but > > even that has a "cost". > I've been thinking about it last night and I think I understand > now how tight it is these days. it takes some time to realise it :-) Even though it was ahead of others when FC0 started, it is now comparable to others. it's time to do something. > > that's acurate, even though now i'm less optimistic. > > if i participate to FC1, i'll take more precautions > > because it seems that FC0's register set will be the slowest > > part of the whole core. > I thing so. If you want a big paralelism and you want to feed N FUs > simultaneously you need each FU to have its own port to the register > file. It means that you need sum[i=0..N,eu_ports(i)] buses in register > file. IIRC the average ILP in programs is about 4 so that we'd need > about 16 ports to the RF. It seems way too much for me. a realistic RF has maybe 8 ports. I've worked with chips using 8-ported semi-custom SRAM and speed was not the issue. I think that a FC0 with an overall 3 write and 5 read ports is possible, but really slow if we can't access full-custom technologies (like Intel and IBM do). Beyond, another strategy must be used. > As you've written later in this mail it seems you are convinced > that some form of splitted set is neccesary (like in TTA) so that > now I know that this part of debate is a bit void ;) > I found some partialy interesting articles - nothing new but > interesting: > http://www.opencores.org/articles?cmd=view_article&id=4 > http://www.opencores.org/projects/or2k/ i don't follow Opencores for a while... > > For example, nicO wants to reduce the number of ports and i thought > > about a way to achieve that. However, making a 3r2w register set > > with 1r1w blocks does not reduce the surface and the complexity because > > a lot of things must be duplicated : > > - you can do a 2r1w bank by using 2*1r1w blocks, so having 3 read ports > > requires 3 identical blocks. > > - you can't do a Xr2w bank as simply as a 2r1w bank because the data > > must be written to all the sub-blocks. One solution is to use > > some kind of FIFO that serializes the write but it's not a suitable > > solution in this case. One solution i proposed was to ensure that > > two simultaneous writes would not write the same sub-block, but this > > can reduce the overall CPU efficiency. > > > > (i'll describe the trick later) > > I'm interested ;) Do you mean "one 64bit register latch" by > sub-block term here ? i mean : splitting the 64-rergister block into 4 or 8 subblocks (8 or 16 registers each). It's a solution i don't like but others (with less sentiments and more interest in peak numbers instead of sustained numbers) would use it or have used it. > I'm also interested how do you expect SMP to be created. As > I spent many time with memory manager of linux I'm curious > whether is will work with f-cpu SMP. > Would it be kind of NUMA machine ? probably but this issue is outside of the goal of the F-CPU project. This also highly depends on how the memory interface is implemented. > > the speed of the inverter is not directly linked to the frequency of the whole chip > > because a lot of parameters have recently become prominent : > Hmm did you read about the new BJT chip design ? I can't remember which > university did it but they have working 3 ported 32x31 register set > operating at 16GHz with only 20W of thermal loss. "only" ?... > They use differential > signal lines as pairs with low (200mV) swing. They planned to test 200GHz > gate ... Only big problem is that they require pair of wires of the > same length for each signal. this is very technology dependent. it can't be done at the VHDL level ... > > > You can do it on code which is one module with sources. The big advantage > > > of compile/link is compile speed. I can't imagine developers to wait > > > several hours when recompiling moderate project linked to glibc - you > > > would have to compile glibc along with it to do global optimization.. > > > But if it is only way to go for speed .. well. > > > > This depends on the local definition of speed. > > When you develop an algorithm, compile time is moderately crucial. > > Often, only small parts of the code base are modified, so incremental > > compilation is possible (unless there's a avalanche effect). Then when > > you are finished, you can let your computer run when you sleep for some > > deep optimisations, if you want. > > And what about ABI ? Do you want to do these optimizations inside one > compilation unit only or also between .so and binary ? The you will > have no ABI and no closed software will run eficiently on it. this is the user's choice : either speed or interface. I know a lot of people will use the default settings anyway, they will want to reuse the existing methods and will certainly be disapointed by the performance. > On one side it can be good for open sw or OTOH it can make M$'s monopoly > bigger - because it will no longer be possible to write efficient > sw for closed-source OS. who knows. But my concern is about the core, despite all the discussions about languages... > > There's an archive in Mexico (i forgot the URL). > > it's a pretty large archive (around 20MB of files and attachments) > I'll look for it ! 20MB is not so much for 10Mbit Internet pipe here :) lucky :-) i'm on a RTC modem... > > what do you think about this ? there's only a 1/8 overhead/bloat > > and it's pretty portable accross different implementations > > (recognize this opcode as NOP if not useful, extract only the needed > > information otherwise...) > Wonderfull ! The only word I can say :-> you're the only one who looks enthusiastic ;-) > > 1: > > loadimm 1, r1 ; // or something like that. > > store r2, r1 ; // here, r2 already points to the location p, the address is > > // "desambiguified" at execution (otherwise it would trap > > // if a TLB miss occured). > > 2: > > load r3, r4 ; // like above, r3 already points to *q. If q==p, the value > > // of r4 becomes this of r1. there might be a small delay > > // (1 or 2 cycles at most) if no bypass is designed in the LSU. > > 3: > > add r2, r4, r2; // there's a bypass on the Xbar. The only bad surprise comes from > > // the future reuse of r2 as a pointer without a previous explicit > > // prefetch, a few cycles of penalty. my first estimations are > > // less than i expected (1 or 2 cycles) but this will not be true > > // in the future or in far-from-ideal cases. > > maybe I misused the term disambiguation - I understand that code > above will go just well. But often you can do this: > loada r3, r4 ; start loading of r4, add r3 to disambig. mem (DM) ??? > loadimm 1, r1 > store r2, r1 ; if r2 is in DM remove it > verify r3, r4 ; if r3 is not in DM behave as load (instead as nop) ??? > add r2, r4, r2 > > So that loada will have a time to get the data during loadimm. > IMHO this code should be faster (only one cycle in this particular > case). > But you can do it only if you are sure [r3] is not later changed > by store. And you never know (at compile time) that two pointer's > might be the same (if they are the same type). in FC0, the LSU is a 8*256 buffer where each line can be associated to a register (or several). so if there's an alias, there is no problem. > The verify is another cycle here so it is no win. But I've seen > larger samples in IA64 docbook where much more was saved. > But it is probably tied to superscalar architecture - in FC0 > it will be simpler to do prefetch. So forget my kidding ;) it's always interesting to chat about different things. for example, it comforts my idea that the LSU design is a really cool thing. it's a bit complex and it doesn't look like other computers (so people might have more difficulties to use it) but it's a one-does-everything unit. more about this later... > regards, devik good night, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 04:26:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0W-0000G5-00 for ; Mon, 22 Apr 2002 23:05:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:05:56 +0200 (CEST) Received: (qmail 17112 invoked by uid 0); 22 Apr 2002 02:19:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 22 Apr 2002 02:19:29 -0000 Received: by moria.seul.org (Postfix) id 209DF146919; Sun, 21 Apr 2002 22:19:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0FF6A14691B; Sun, 21 Apr 2002 22:19:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 83DB3146919 for ; Sun, 21 Apr 2002 22:19:26 -0400 (EDT) Received: from f-cpu.org (kdl16-20.n.club-internet.fr [213.44.18.20]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 9A8A71684 for ; Mon, 22 Apr 2002 04:19:21 +0200 (CEST) Message-ID: <3CC374B8.59113AE1@f-cpu.org> Date: Mon, 22 Apr 2002 04:26:00 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <20020421141755.48152@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sun, Apr 21, 2002 at 11:39:39AM +0200, Martin Devera wrote: > [...] > > maybe I misused the term disambiguation - I understand that code > > above will go just well. But often you can do this: > > loada r3, r4 ; start loading of r4, add r3 to disambig. mem (DM) > > loadimm 1, r1 > > store r2, r1 ; if r2 is in DM remove it > > verify r3, r4 ; if r3 is not in DM behave as load (instead as nop) > > add r2, r4, r2 > > > > So that loada will have a time to get the data during loadimm. > > IMHO this code should be faster (only one cycle in this particular > > case). > > Speculative loads can probably be implemented in a similar manner as > the load-linked/conditional-store instructions we've been talking about > recently. When `loada' is executed, mark the corresponding bytes in the > cache, and reset the markers whenever an instruction modifies the loaded > data. If the markers aren't all set (or the cache line was flushed), > the `verify' instruction will trap, jump to a piece of fixup code, or > simply re-load the modified bytes. The drawback of this approach is that > it doesn't work well if the same bytes are loaded more than once, or if > the loaded register is overwritten. I'm not sure how the Itanium handles > that case, however. > > The other (probably more expensive) solution is a table that maps register > numbers to (virtual or physical) addresses. When a register is loaded, > make a new entry in the table; when the loaded data is modified or the > register is clobbered, remove or invalidate the entry. that's what the LSU does :-) [more or less, in a certain sense] > > But you can do it only if you are sure [r3] is not later changed > > by store. And you never know (at compile time) that two pointer's > > might be the same (if they are the same type). > > That's why ISO C99 adds the `restrict' pointer qualifier. E.g. you write > > void copy(char *restrict dest, const char *restrict src, size_t len) { > ... > } > > and the compiler will assume that source and destination do not overlap. > That is, it does not need to disambiguate those pointers. Of course > programmers have to be more careful -- calls like > > copy(array, array + 1, 10); > > will produce unspecified results. > > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Apr 22 07:39:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0X-0000G5-00 for ; Mon, 22 Apr 2002 23:05:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:05:57 +0200 (CEST) Received: (qmail 20963 invoked by uid 0); 22 Apr 2002 05:39:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 22 Apr 2002 05:39:12 -0000 Received: by moria.seul.org (Postfix) id 6039D14684E; Mon, 22 Apr 2002 01:39:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47A7E1468E0; Mon, 22 Apr 2002 01:39:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id DCBCB14684E for ; Mon, 22 Apr 2002 01:39:10 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zWXd-00010V-00 for f-cpu@seul.org; Mon, 22 Apr 2002 07:39:09 +0200 Date: Mon, 22 Apr 2002 07:39:08 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <20020421141755.48152@thrai.stud.uni-hannover.de> Message-ID: References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <20020421141755.48152@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > recently. When `loada' is executed, mark the corresponding bytes in the > cache, and reset the markers whenever an instruction modifies the loaded > data. If the markers aren't all set (or the cache line was flushed), > the `verify' instruction will trap, jump to a piece of fixup code, or > simply re-load the modified bytes. The drawback of this approach is that nice :) the same like IA64 "advanced load" only doesn't need additional associative memory. But see below. > it doesn't work well if the same bytes are loaded more than once, or if > the loaded register is overwritten. I'm not sure how the Itanium handles > that case, however. It does it like your register<->address map table. They have 8 entry associative memory where each line holds address and register id. load.a adds line with addr/reg (doing LRU on old entries). verify (it has another name which I can't recall) looks for line with reg id. Store deletes all lines with matching address. It handles more-load case but not overwritten reg case. However there is kind of verify instr which removes the entry IIRC. > That's why ISO C99 adds the `restrict' pointer qualifier. E.g. you write > [...] ehh I should probably reread new C specs ;) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Apr 22 08:03:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0Y-0000G5-00 for ; Mon, 22 Apr 2002 23:05:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:05:58 +0200 (CEST) Received: (qmail 9121 invoked by uid 0); 22 Apr 2002 06:03:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 22 Apr 2002 06:03:25 -0000 Received: by moria.seul.org (Postfix) id F2C701468E9; Mon, 22 Apr 2002 02:03:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDD8D1468E6; Mon, 22 Apr 2002 02:03:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EC4411468D9 for ; Mon, 22 Apr 2002 02:03:22 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zWv4-00019S-00 for f-cpu@seul.org; Mon, 22 Apr 2002 08:03:22 +0200 Date: Mon, 22 Apr 2002 08:03:21 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CC35445.612C3036@f-cpu.org> Message-ID: References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <3CC35445.612C3036@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > argh .. fucked pine .. I was writting reply 30 minutes and it crashed ;( > > Now I'm going to write again. > this doesn't only happen with pine ;-) > Fortunately, Netscape designed the "save as draft" button ;-P what's irony ! Pine crashed when I did ^O (save as draft) ;-\ But is it because I compiled new message coloring and threading version of pine - old one didn't crashed. I'll have to apply gdb ;) > mmm IIRC, Bochs is not GNU ? hmm probably not - but it seems to be free enough ;) > It makes the same problem as a plain C simulator : we already have to deal with > a VHDL source tree and there are too few contributors yet. we can't hire > anybody, you know : it's all volunteer work. when work is done. true .. The biggest problem I see: is there any free tool to use for simulation cpu (or other logic) in VHDL ? If not it too hard to write one ? I ask because when I developed first version of advanced packet scheduler I did it in userspace - I was able to quickly evaluate speed and has been forced to rethink/rewrite whole agorithm three times (the complexity analyse is almost impossible there) - it saved a lot of time - then I implemented it once in kernel space (which is a bit harder/slower). I was thinking about emulator where all ideas can be quickly evaluated million times before you start coding actual logic. And if there would be single tool used by all participants I think that some ideas could be tested very fast. > slow if we can't access full-custom technologies (like Intel and IBM do). > Beyond, another strategy must be used. I'm not experianced here, what is difference between ASIC and full custom ? ASIC can use only predefined blocks ? > > university did it but they have working 3 ported 32x31 register set > > operating at 16GHz with only 20W of thermal loss. > "only" ?... hmm not too low abs. number ;) But they computed 16GHz in cmos would have much more .. Also they claim that with higher integration this number will decrease and in cmos it increases .. > > Wonderfull ! The only word I can say :-> > you're the only one who looks enthusiastic ;-) probably because I still know too little about making CPUs ;) > > But you can do it only if you are sure [r3] is not later changed > > by store. And you never know (at compile time) that two pointer's > > might be the same (if they are the same type). > > in FC0, the LSU is a 8*256 buffer where each line can be associated > to a register (or several). so if there's an alias, there is no problem. yes yes, I already understood from Riepe's mail. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 08:07:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0Y-0000G5-01 for ; Mon, 22 Apr 2002 23:05:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:05:58 +0200 (CEST) Received: (qmail 8107 invoked by uid 0); 22 Apr 2002 06:05:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 22 Apr 2002 06:05:12 -0000 Received: by moria.seul.org (Postfix) id B4D2F1468D9; Mon, 22 Apr 2002 02:05:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9AA2A1468E6; Mon, 22 Apr 2002 02:05:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A5C921468D9 for ; Mon, 22 Apr 2002 02:05:04 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zWzE-0007zb-00 for f-cpu@seul.org; Mon, 22 Apr 2002 08:07:40 +0200 Date: Mon, 22 Apr 2002 08:07:40 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CC35445.612C3036@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Yann Guidon wrote: >after some research, i think that some other computers use >this kind of technique but i'm not sure. >SRB was created when writing a mail during the "how many registers" thread >and it is closely related to the FC0 architecture but it is possible >to find a similar principle in the i860, maybe (or is it i960 ?) i860 was the floating point vector processor, i960 is the embedded RISC processor (both Intel). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 08:33:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0Z-0000G5-00 for ; Mon, 22 Apr 2002 23:05:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:05:59 +0200 (CEST) Received: (qmail 23578 invoked by uid 0); 22 Apr 2002 06:30:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 22 Apr 2002 06:30:21 -0000 Received: by moria.seul.org (Postfix) id 947A11468E6; Mon, 22 Apr 2002 02:30:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 814CA1468FA; Mon, 22 Apr 2002 02:30:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0B8111468E6 for ; Mon, 22 Apr 2002 02:30:18 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zXOX-00081a-00 for f-cpu@seul.org; Mon, 22 Apr 2002 08:33:49 +0200 Date: Mon, 22 Apr 2002 08:33:49 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC32795.9BEF4A02@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 21 Apr 2002, Yann Guidon wrote: >Juergen Goeritz wrote: >> Hi, >> >> forgot two things in my list of appreciated qualities >> of that ultimative language: >> >> - easy readability, easy learning, easy debugging. >> - easy simulation of unimplemented parts (e.g. like >> the test stimulation possibilities in VHDL) >> - integrated abstract layer documentation scheme >> that could be extended to automatic code generation. >> >> Very large scale projects usually lack of early test >> possibilities. The best way of implementation always >> lets you have something to show to the customer, even >> in very early stages already. > >at least, with a good VHDL background, you're used to write >a lot of testbenches. that's one good reason to reuse of >lot of its concepts. > >I think about this program : > - 1) make a dumb but flexible backend for, but not tied to, gcc > - 2) enhance the backend A postprocessing tool which will be enhanced to marvelous optimizer later and can be used within a loader. > - 3) create a VHLD-like frontend (without the hassles). I agree on input syntax fpr parallel processes (not VHDL). > - 4) create some basic libraries. what for? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Apr 22 10:32:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0e-0000G5-00 for ; Mon, 22 Apr 2002 23:06:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:04 +0200 (CEST) Received: (qmail 30807 invoked by uid 0); 22 Apr 2002 08:33:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 22 Apr 2002 08:33:18 -0000 Received: by moria.seul.org (Postfix) id C0C051468FA; Mon, 22 Apr 2002 04:33:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3F6E146915; Mon, 22 Apr 2002 04:33:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id E66571468FA for ; Mon, 22 Apr 2002 04:33:15 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204220832.3229; Mon, 22 Apr 2002 08:32:50 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] F-CPU vs. Itanium From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Apr 2002 08:32:50 GMT Message-id: <200204220832.3229@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Martin Devera A: f-cpu@seul.org Date: 22/04/02 Objet: Re: [f-cpu] F-CPU vs. Itanium > It makes the same problem as a plain C simulator : we alre= ady have to deal with > a VHDL source tree and there are too few contributors yet.= we can't hire > anybody, you know : it's all volunteer work. when work is = done. true .. The biggest problem I see: is there any free tool to= use for simulation cpu (or other logic) in VHDL ? If not it too = hard to write one ? I ask because when I developed first version of advanced pac= ket scheduler I did it in userspace - I was able to quickly evaluate speed= and has been forced to rethink/rewrite whole agorithm three times (the co= mplexity analyse is almost impossible there) - it saved a lot of time= - then I implemented it once in kernel space (which is a bit harder= /slower). I was thinking about emulator where all ideas can be quickly= evaluated million times before you start coding actual logic. And if there would be single tool used by all participants I= think that some ideas could be tested very fast. >>> That's where goes the big design. They called that archi= tecture exploration. Industry try to introduice many tools to create= a flow from the spec to the GDS II files. System C are design to do such research. The idea is to "ref= ine" your design with VHDL like concept. BUT you could begin dirty C++= if you want. That's where you could save time. > slow if we can't access full-custom technologies (like Int= el and IBM do). > Beyond, another strategy must be used. I'm not experianced here, what is difference between ASIC an= d full custom ? ASIC can use only predefined blocks ? >>> ASIC are a generic name. Most (99%) of the design use se= mi-custom design. In fact, the design is an interconnection of soon de= fined cells (AND/OR gate, register,...). Most of the time they define me= mory bloc, too. But this kind of block have 2 ports, very few times mor= e. >>> So you need full custom design where you could design yo= u're one memory block. But it's far more expensive for a compagny to = do it. Most of the time only foundries do it (IBM, ST, TSMC,...). >>> The third kind of ASIC called 'precaract=E9ris=E9' in fr= ench are a kind of FPGA, only the 2 or 4 last metal layer are define by the = designer. That's the chipest technology. > > university did it but they have working 3 ported 32x31 r= egister set > > operating at 16GHz with only 20W of thermal loss. > "only" ?... hmm not too low abs. number ;) But they computed 16GHz in cm= os would have much more .. Also they claim that with higher integration th= is number will decrease and in cmos it increases .. >>> ??? 20 W for a register bank is hudge ! In 400 Mhz only = 7W is needed for the whole mutiplier unit (0.18 =B5m). nicO devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Apr 22 11:36:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0i-0000G5-00 for ; Mon, 22 Apr 2002 23:06:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:08 +0200 (CEST) Received: (qmail 21842 invoked by uid 0); 22 Apr 2002 09:53:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Apr 2002 09:53:56 -0000 Received: by moria.seul.org (Postfix) id 74D27146915; Mon, 22 Apr 2002 05:53:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6AE4414691B; Mon, 22 Apr 2002 05:53:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 21FC7146915 for ; Mon, 22 Apr 2002 05:53:54 -0400 (EDT) Received: from ifurita (212.194.222.197) by mail.laposte.net (5.5.044) id 3CC0567300005FAE for f-cpu@seul.org; Mon, 22 Apr 2002 11:53:49 +0200 Message-ID: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> From: "Christophe" To: References: <005801c1e913$b6dd6e60$f9e2c2d4@ifurita> <3CC3382F.55FC69AD@f-cpu.org> Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 11:36:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Monday, April 22, 2002 12:07 AM Subject: Re: [f-cpu] Winograd DCT on my seul.org account > > Parallel execution is non-sense for uniprocessor and even multi-processor (each > > of them executes one sequential code). So I don't see the point. > i don't have the courage to prove the contrary tonight. > Maybe you will see the point if you do more application programming > and see that the reason why computers are so slow is because they are so > inherently serialised. A "parallel" langage has the purpose of showing > what is independent from what, it doesn't force you to use a parallel machine. > and multithread support if an old issue in the OS community. C does not > expose enough parallelism and requires explicit stuff which makes heavier. I'm speaking about parallel execution per instruction, not per thread (instructions in a thread are still serialized). So long as we get no real cpu able to execute parallel instructions, there is no real gain for anything for a true parallelism. Yes, a parallel language is okay to see what is independent (the good point) and shall be surely better than C but we will still have a lot of overhead due to the use of multithreading (stack space and switching for example). So if a CPU has power enough, we tend to use it more in serial way than parallel way since there is no real reason to think a multithreading would *ALWAYS* run better. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 12:43:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0k-0000G5-01 for ; Mon, 22 Apr 2002 23:06:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:10 +0200 (CEST) Received: (qmail 8005 invoked by uid 0); 22 Apr 2002 10:40:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 22 Apr 2002 10:40:16 -0000 Received: by moria.seul.org (Postfix) id 70CCA146900; Mon, 22 Apr 2002 06:40:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6C77C14691B; Mon, 22 Apr 2002 06:40:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 63787146900 for ; Mon, 22 Apr 2002 06:40:13 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zbIL-0008Hn-00 for f-cpu@seul.org; Mon, 22 Apr 2002 12:43:41 +0200 Date: Mon, 22 Apr 2002 12:43:41 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Christophe wrote: >> > Parallel execution is non-sense for uniprocessor and even multi-processor >(each >> > of them executes one sequential code). So I don't see the point. >> i don't have the courage to prove the contrary tonight. >> Maybe you will see the point if you do more application programming >> and see that the reason why computers are so slow is because they are so >> inherently serialised. A "parallel" langage has the purpose of showing >> what is independent from what, it doesn't force you to use a parallel >machine. >> and multithread support if an old issue in the OS community. C does not >> expose enough parallelism and requires explicit stuff which makes heavier. > >I'm speaking about parallel execution per instruction, not per thread >(instructions in a thread are still serialized). So long as we get no real cpu >able to execute parallel instructions, there is no real gain for anything for a >true parallelism. Yes, a parallel language is okay to see what is independent >(the good point) and shall be surely better than C but we will still have a lot >of overhead due to the use of multithreading (stack space and switching for >example). So if a CPU has power enough, we tend to use it more in serial way >than parallel way since there is no real reason to think a multithreading would >*ALWAYS* run better. What do you mean by better? It may not be faster at all on a single processor due to the extended overhead. But there is one advantage compared to sequential programming. The parallel threads could communicate with each other in new ways if you think of each thread as a unique entity... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon Apr 22 13:07:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0l-0000G5-00 for ; Mon, 22 Apr 2002 23:06:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:11 +0200 (CEST) Received: (qmail 17093 invoked by uid 0); 22 Apr 2002 11:07:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 22 Apr 2002 11:07:48 -0000 Received: by moria.seul.org (Postfix) id C55BB14691A; Mon, 22 Apr 2002 07:07:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B953814691D; Mon, 22 Apr 2002 07:07:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id D1C6D14691A for ; Mon, 22 Apr 2002 07:07:44 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g3MB7fu21960 for ; Mon, 22 Apr 2002 13:07:41 +0200 Message-ID: <009901c1e9ed$ed5583d0$bca45982@student.utwente.nl> From: "Marco Al" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 13:07:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > What one would need is a language with a very good > type checking like in Ada, Pascal, Modula a.s.o, a > language that can do easy prototyping and reuse of > coded parts like Forth, a language disallowing the > side-effect programming styles, a language that can > handle OO approaches and a language that is capable > of parallel execution pathes. How about Occam? ;) As far as type-checking/encapsulation/concurrency goes it seems to qualify, and functions are ensured to be side-effect free at least (I think that hits the sweet spot, imperative programming is here to stay). It obviously lacks some basic features, foremost handling reference's and OO ... but an implementation for zero-aliasing references was introduced not so long ago, and and some interesting proposals for OO extensions have been made by others (the distance between message passing and prototype based OO is not long). Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 13:39:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0l-0000G5-01 for ; Mon, 22 Apr 2002 23:06:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:11 +0200 (CEST) Received: (qmail 25164 invoked by uid 0); 22 Apr 2002 11:36:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 22 Apr 2002 11:36:22 -0000 Received: by moria.seul.org (Postfix) id B0FB114691B; Mon, 22 Apr 2002 07:36:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9AF8714691E; Mon, 22 Apr 2002 07:36:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 87B3C14691B for ; Mon, 22 Apr 2002 07:36:17 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zcAm-0008Ls-00 for f-cpu@seul.org; Mon, 22 Apr 2002 13:39:56 +0200 Date: Mon, 22 Apr 2002 13:39:56 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <009901c1e9ed$ed5583d0$bca45982@student.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Marco Al wrote: >Juergen Goeritz wrote: > >> What one would need is a language with a very good >> type checking like in Ada, Pascal, Modula a.s.o, a >> language that can do easy prototyping and reuse of >> coded parts like Forth, a language disallowing the >> side-effect programming styles, a language that can >> handle OO approaches and a language that is capable >> of parallel execution pathes. > >How about Occam? ;) I know occam from the time I looked at transputers. The language didn't really turn me on. Everything felt too complicated. Maybe that was one thing why the transputer never made its way to a real hit (beside being much too expensive). >As far as type-checking/encapsulation/concurrency goes it seems to >qualify, and functions are ensured to be side-effect free at least (I >think that hits the sweet spot, imperative programming is here to stay). Yes, and you also find this in a lot of other languages... >It obviously lacks some basic features, foremost handling reference's >and OO ... but an implementation for zero-aliasing references was >introduced not so long ago, and and some interesting proposals for OO >extensions have been made by others (the distance between message >passing and prototype based OO is not long). Have these proposals made the way to implementation yet? Is there a PD compiler to start with? BTW I spent years on message passing and I don't share your opinion about that 'not long' distance to OO. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Apr 22 17:39:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl0y-0000G5-00 for ; Mon, 22 Apr 2002 23:06:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:24 +0200 (CEST) Received: (qmail 8342 invoked by uid 0); 22 Apr 2002 15:56:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 22 Apr 2002 15:56:46 -0000 Received: by moria.seul.org (Postfix) id E0CB514692D; Mon, 22 Apr 2002 11:56:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8ED3146931; Mon, 22 Apr 2002 11:56:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 8C87714692D for ; Mon, 22 Apr 2002 11:56:43 -0400 (EDT) Received: from ifurita (212.194.237.129) by mail.laposte.net (5.5.044) id 3CA06FFD003F3010 for f-cpu@seul.org; Mon, 22 Apr 2002 17:56:42 +0200 Message-ID: <001501c1ea13$f27c5fc0$81edc2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 17:39:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >I'm speaking about parallel execution per instruction, not per thread > >(instructions in a thread are still serialized). So long as we get no real cpu > >able to execute parallel instructions, there is no real gain for anything for a > >true parallelism. Yes, a parallel language is okay to see what is independent > >(the good point) and shall be surely better than C but we will still have a lot > >of overhead due to the use of multithreading (stack space and switching for > >example). So if a CPU has power enough, we tend to use it more in serial way > >than parallel way since there is no real reason to think a multithreading would > >*ALWAYS* run better. > > What do you mean by better? It may not be faster at all on > a single processor due to the extended overhead. But there > is one advantage compared to sequential programming. The > parallel threads could communicate with each other in new > ways if you think of each thread as a unique entity... well, yes I mean faster. You're also right at some extent regarding with the ways threads can communicate, but for the same result, you have likely a slower execution and more wasted ressources in space too (stacks, and other structures need space). But okay we are off-topic, we shouldn't waste our time in such discussion. Sorry if i'm still off-topic :(. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Apr 22 17:47:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl10-0000G5-00 for ; Mon, 22 Apr 2002 23:06:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:26 +0200 (CEST) Received: (qmail 22333 invoked by uid 0); 22 Apr 2002 16:04:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 22 Apr 2002 16:04:23 -0000 Received: by moria.seul.org (Postfix) id 04F8E146935; Mon, 22 Apr 2002 12:04:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01DED146934; Mon, 22 Apr 2002 12:04:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id A8C21146932 for ; Mon, 22 Apr 2002 12:04:21 -0400 (EDT) Received: from ifurita (212.194.237.129) by mail.laposte.net (5.5.044) id 3CC40882000048F1 for f-cpu@seul.org; Mon, 22 Apr 2002 18:04:20 +0200 Message-ID: <003501c1ea15$03644400$81edc2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 17:47:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N CAML combines imperative and functionnal programming. In a certain way, LISP or C programs can be easily ported to CAML. There is another project COQ, which based on CAML and have the proprietary to check if an algorithms is correct (I'm speaking about the correctness of an algorithm, something that C is unable to check). We don't also need to use YACC and LEX with CAML because it can also be used as a parser. Please don't think we should use CAML :). I'm just telling you that CAML is more than a simple language. ----- Original Message ----- From: Juergen Goeritz To: Sent: Monday, April 22, 2002 1:39 PM Subject: Re: [f-cpu] Winograd DCT on my seul.org account > On Mon, 22 Apr 2002, Marco Al wrote: > >Juergen Goeritz wrote: > > > >> What one would need is a language with a very good > >> type checking like in Ada, Pascal, Modula a.s.o, a > >> language that can do easy prototyping and reuse of > >> coded parts like Forth, a language disallowing the > >> side-effect programming styles, a language that can > >> handle OO approaches and a language that is capable > >> of parallel execution pathes. > > > >How about Occam? ;) > > I know occam from the time I looked at transputers. The > language didn't really turn me on. Everything felt too > complicated. Maybe that was one thing why the transputer > never made its way to a real hit (beside being much too > expensive). > > >As far as type-checking/encapsulation/concurrency goes it seems to > >qualify, and functions are ensured to be side-effect free at least (I > >think that hits the sweet spot, imperative programming is here to stay). > > Yes, and you also find this in a lot of other languages... > > >It obviously lacks some basic features, foremost handling reference's > >and OO ... but an implementation for zero-aliasing references was > >introduced not so long ago, and and some interesting proposals for OO > >extensions have been made by others (the distance between message > >passing and prototype based OO is not long). > > Have these proposals made the way to implementation yet? > Is there a PD compiler to start with? > > BTW I spent years on message passing and I don't share > your opinion about that 'not long' distance to OO. > > JG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon Apr 22 18:32:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl13-0000G5-00 for ; Mon, 22 Apr 2002 23:06:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:29 +0200 (CEST) Received: (qmail 26643 invoked by uid 0); 22 Apr 2002 16:32:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Apr 2002 16:32:21 -0000 Received: by moria.seul.org (Postfix) id A7777146930; Mon, 22 Apr 2002 12:32:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78007146934; Mon, 22 Apr 2002 12:32:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 99707146930 for ; Mon, 22 Apr 2002 12:32:18 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g3MGWDI15599 for ; Mon, 22 Apr 2002 18:32:13 +0200 Message-ID: <00d201c1ea1b$43b92bf0$bca45982@student.utwente.nl> From: "Marco Al" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 18:32:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > On Mon, 22 Apr 2002, Marco Al wrote: >> How about Occam? ;) > Have these proposals made the way to implementation yet? > Is there a PD compiler to start with? Just the handling of references, in KroC : http://www.cs.ukc.ac.uk/projects/ofa/kroc/ > BTW I spent years on message passing and I don't share > your opinion about that 'not long' distance to OO. I have 0 experience in language design so Ill take your word for it. I have a soft spot for CSP and Occam. The absence of aliasing is interesting, and message passing just seems so much more suited for programming concurrent architectures than shared memory approaches. There dont seem to be a lot of actively maintained concurrent object oriented languages (COOLs) which use message passing, with CSP and Occam still going relatively strong after a long history Im just hoping to see Occam become one :/ Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 20:41:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl17-0000G5-01 for ; Mon, 22 Apr 2002 23:06:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:33 +0200 (CEST) Received: (qmail 5729 invoked by uid 0); 22 Apr 2002 18:45:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 22 Apr 2002 18:45:49 -0000 Received: by moria.seul.org (Postfix) id 297C814693A; Mon, 22 Apr 2002 14:44:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E8DF14693F; Mon, 22 Apr 2002 14:44:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 42E2B14693A for ; Mon, 22 Apr 2002 14:44:45 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zikK-00003L-00 for f-cpu@seul.org; Mon, 22 Apr 2002 20:41:04 +0200 Date: Mon, 22 Apr 2002 20:41:04 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <003501c1ea15$03644400$81edc2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Is it PD? Could you provide a link? Thanks! JG On Mon, 22 Apr 2002, Christophe wrote: >CAML combines imperative and functionnal programming. In a certain way, LISP or >C programs can be easily ported to CAML. There is another project COQ, which >based on CAML and have the proprietary to check if an algorithms is correct >(I'm speaking about the correctness of an algorithm, something that C is unable >to check). We don't also need to use YACC and LEX with CAML because it can also >be used as a parser. > >Please don't think we should use CAML :). I'm just telling you that CAML is >more than a simple language. > > >----- Original Message ----- From: Juergen Goeritz >To: >Sent: Monday, April 22, 2002 1:39 PM >Subject: Re: [f-cpu] Winograd DCT on my seul.org account > > >> On Mon, 22 Apr 2002, Marco Al wrote: >> >Juergen Goeritz wrote: >> > >> >> What one would need is a language with a very good >> >> type checking like in Ada, Pascal, Modula a.s.o, a >> >> language that can do easy prototyping and reuse of >> >> coded parts like Forth, a language disallowing the >> >> side-effect programming styles, a language that can >> >> handle OO approaches and a language that is capable >> >> of parallel execution pathes. >> > >> >How about Occam? ;) >> >> I know occam from the time I looked at transputers. The >> language didn't really turn me on. Everything felt too >> complicated. Maybe that was one thing why the transputer >> never made its way to a real hit (beside being much too >> expensive). >> >> >As far as type-checking/encapsulation/concurrency goes it seems to >> >qualify, and functions are ensured to be side-effect free at least (I >> >think that hits the sweet spot, imperative programming is here to stay). >> >> Yes, and you also find this in a lot of other languages... >> >> >It obviously lacks some basic features, foremost handling reference's >> >and OO ... but an implementation for zero-aliasing references was >> >introduced not so long ago, and and some interesting proposals for OO >> >extensions have been made by others (the distance between message >> >passing and prototype based OO is not long). >> >> Have these proposals made the way to implementation yet? >> Is there a PD compiler to start with? >> >> BTW I spent years on message passing and I don't share >> your opinion about that 'not long' distance to OO. >> >> JG >> >> ************************************************************* >> To unsubscribe, send an e-mail to majordomo@seul.org with >> unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Apr 22 20:50:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl18-0000G5-00 for ; Mon, 22 Apr 2002 23:06:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:34 +0200 (CEST) Received: (qmail 9756 invoked by uid 0); 22 Apr 2002 18:53:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 22 Apr 2002 18:53:48 -0000 Received: by moria.seul.org (Postfix) id 6B055146938; Mon, 22 Apr 2002 14:53:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6685F14693E; Mon, 22 Apr 2002 14:53:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 530E6146938 for ; Mon, 22 Apr 2002 14:53:47 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zite-000056-00 for f-cpu@seul.org; Mon, 22 Apr 2002 20:50:42 +0200 Date: Mon, 22 Apr 2002 20:50:41 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <00d201c1ea1b$43b92bf0$bca45982@student.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Marco Al wrote: >Juergen Goeritz wrote: >> On Mon, 22 Apr 2002, Marco Al wrote: > >>> How about Occam? ;) > >> Have these proposals made the way to implementation yet? >> Is there a PD compiler to start with? > >Just the handling of references, in KroC : >http://www.cs.ukc.ac.uk/projects/ofa/kroc/ Thanks. >> BTW I spent years on message passing and I don't share >> your opinion about that 'not long' distance to OO. > >I have 0 experience in language design so Ill take your word for it. > >I have a soft spot for CSP and Occam. The absence of aliasing is >interesting, and message passing just seems so much more suited for >programming concurrent architectures than shared memory approaches. Agreed! I also like the message passing versions better than shared memories. I think message passing is the superset of communication because it's easy clusterable. :-) >There dont seem to be a lot of actively maintained concurrent object >oriented languages (COOLs) which use message passing, with CSP and Occam >still going relatively strong after a long history Im just hoping to see >Occam become one :/ Who knows. The parallel strongness of Occam is a wanted feature for that language I have in mind. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Apr 23 00:14:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl1B-0000G5-01 for ; Mon, 22 Apr 2002 23:06:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:37 +0200 (CEST) Received: (qmail 23213 invoked by uid 0); 22 Apr 2002 19:37:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 22 Apr 2002 19:37:33 -0000 Received: by moria.seul.org (Postfix) id 0562514693D; Mon, 22 Apr 2002 15:37:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E87C6146941; Mon, 22 Apr 2002 15:37:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 9DA4214693D for ; Mon, 22 Apr 2002 15:37:29 -0400 (EDT) Received: from art1.none.de ([62.27.157.115]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g3MJbVr21958 for ; Mon, 22 Apr 2002 21:37:33 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.157.115] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16zm5U-0005rC-00 for ; Tue, 23 Apr 2002 00:15:08 +0200 Date: Tue, 23 Apr 2002 00:14:32 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC32795.9BEF4A02@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > > Remember, forth can do this... and surplus you can test forth-code > > interactively... > > Forth is an incredible language but it can't do all i want, > or i would use it for a loooong time. It also introduces a lot of things that > can interfere with the algorithms, or at least make you forget about > what you want to do. Finally, the largest scope that i could globally > optimize by hand is 100 or 120 instructions per block. we need to go beyond > that. Forth is the contrary of a dataflow graph analysis tool because > it over-serialises the computations. I disagreed. First is Forth only a little more than a MACRO-library of assembler-code. Second it is small and easy to learn 3-th there are forth-dialects coming with an object-oriented manner 4-th it is fast enough, compileable and interpretable 5-th we can implement a forth-interpreter/compiler for F-CPU in much easier way than for C and Co. 6-th we can test the FC0 as fast as possible 7-th We should have the focus on the hardware-site of F-CPU, we need a higher language only for testing the core, is not it? 8-th we can bootstrap the FC0, it is EPROM programmable 9-th we become a set of useful ASM-instructions My only disadvantage was, that a mapping of forth-technique to register-based cpu could be ineffective, but after some words with compiler-developers, should this handable... IMHO all points fullfilled: > > - easy readability, easy learning, easy debugging. > > - easy simulation of unimplemented parts (e.g. like > > the test stimulation possibilities in VHDL) > > - integrated abstract layer documentation scheme > > that could be extended to automatic code generation. An adaption of a special language should be done later. Bye Andreas PS.: PFE - portable forth environment has a gzipped tarball-size of 134k including docs and examples. The extracted C-Code is 180k. PFE is ANS conform. PPS.: we did not need a full ANS compatible forth environment, we can do it simpler and smaller -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8xItMClxplZklbgERAtV0AJ9OkM7/FtjkLmulI97SjIlE5JcqsQCfR0qu w+OeBOB1Wzgi5kZz1n+R6Fw= =1y5U -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 22 12:27:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl1D-0000G5-00 for ; Mon, 22 Apr 2002 23:06:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:39 +0200 (CEST) Received: (qmail 31534 invoked by uid 0); 22 Apr 2002 19:55:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 22 Apr 2002 19:55:37 -0000 Received: by moria.seul.org (Postfix) id 8563C1467FF; Mon, 22 Apr 2002 15:55:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80C5E1468E0; Mon, 22 Apr 2002 15:55:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a035.home.uni-hannover.de [130.75.232.35]) by moria.seul.org (Postfix) with ESMTP id 02BDD1467FF for ; Mon, 22 Apr 2002 15:55:35 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00522; Mon, 22 Apr 2002 12:27:38 +0200 Message-ID: <20020422122738.04521@thrai.stud.uni-hannover.de> Date: Mon, 22 Apr 2002 12:27:38 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] F-CPU vs. Itanium References: <200204220832.3229@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <200204220832.3229@th00.opsion.fr>; from Nicolas Boulay on Mon, Apr 22, 2002 at 08:32:50AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 08:32:50AM +0000, Nicolas Boulay wrote: [...] > >>> ??? 20 W for a register bank is hudge ! In 400 Mhz only 7W is needed > for the whole mutiplier unit (0.18 µm). You overlooked the clock frequency of *16* GHz. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 22 12:24:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16zl1D-0000G5-01 for ; Mon, 22 Apr 2002 23:06:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 22 Apr 2002 23:06:39 +0200 (CEST) Received: (qmail 21955 invoked by uid 0); 22 Apr 2002 19:55:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 22 Apr 2002 19:55:50 -0000 Received: by moria.seul.org (Postfix) id 5D60A14693F; Mon, 22 Apr 2002 15:55:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B0BE14692B; Mon, 22 Apr 2002 15:55:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a035.home.uni-hannover.de [130.75.232.35]) by moria.seul.org (Postfix) with ESMTP id E67221468E0 for ; Mon, 22 Apr 2002 15:55:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00511; Mon, 22 Apr 2002 12:24:03 +0200 Message-ID: <20020422122403.58033@thrai.stud.uni-hannover.de> Date: Mon, 22 Apr 2002 12:24:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <20020421141755.48152@thrai.stud.uni-hannover.de> <3CC374B8.59113AE1@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CC374B8.59113AE1@f-cpu.org>; from Yann Guidon on Mon, Apr 22, 2002 at 04:26:00AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 04:26:00AM +0200, Yann Guidon wrote: [...] > > The other (probably more expensive) solution is a table that maps register > > numbers to (virtual or physical) addresses. When a register is loaded, > > make a new entry in the table; when the loaded data is modified or the > > register is clobbered, remove or invalidate the entry. > > that's what the LSU does :-) [more or less, in a certain sense] That means we can get speculative loads (almost) for free :) The only question is how the `verify' instruction should work -- trap, jump or reload? I think trapping is too expensive, but a jumping variant would be a nice extension because it allows more complex fixups. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Apr 22 22:08:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFm-00023o-00 for ; Tue, 23 Apr 2002 01:29:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:50 +0200 (CEST) Received: (qmail 28376 invoked by uid 0); 22 Apr 2002 20:57:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 22 Apr 2002 20:57:23 -0000 Received: by moria.seul.org (Postfix) id 3882B146949; Mon, 22 Apr 2002 16:57:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 35E1E146948; Mon, 22 Apr 2002 16:57:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id CEB75146944 for ; Mon, 22 Apr 2002 16:57:21 -0400 (EDT) Received: from ifrance.com (vlt4-116.n.club-internet.fr [194.158.109.116]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E45801718 for ; Mon, 22 Apr 2002 22:57:18 +0200 (CEST) Message-ID: <3CC46DD9.555475EB@ifrance.com> Date: Mon, 22 Apr 2002 22:08:57 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] F-CPU vs. Itanium References: <200204220832.3229@th00.opsion.fr> <20020422122738.04521@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu > > On Mon, Apr 22, 2002 at 08:32:50AM +0000, Nicolas Boulay wrote: > [...] > > >>> ??? 20 W for a register bank is hudge ! In 400 Mhz only 7W is needed > > for the whole mutiplier unit (0.18 µm). > > You overlooked the clock frequency of *16* GHz. Yep maybe, it's 32 times more for 32*31=992 memory point. To be Compare to you're design that use packet of 4096 flip-flop banck ! ;p nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 23:21:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFm-00023o-01 for ; Tue, 23 Apr 2002 01:29:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:50 +0200 (CEST) Received: (qmail 22709 invoked by uid 0); 22 Apr 2002 21:15:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 22 Apr 2002 21:15:06 -0000 Received: by moria.seul.org (Postfix) id 8361D146944; Mon, 22 Apr 2002 17:15:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7570A14694C; Mon, 22 Apr 2002 17:15:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 05BCA146944 for ; Mon, 22 Apr 2002 17:15:03 -0400 (EDT) Received: from f-cpu.org (kdl11-95.n.club-internet.fr [213.44.9.95]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 7B5E216C4 for ; Mon, 22 Apr 2002 23:15:00 +0200 (CEST) Message-ID: <3CC47EE4.BC67408@f-cpu.org> Date: Mon, 22 Apr 2002 23:21:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CBF567E.302CDF7B@f-cpu.org> <3CC242C8.E7BC0F3A@f-cpu.org> <3CC35445.612C3036@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, some answers only (the rest is probably already answered) Martin Devera wrote: > > mmm IIRC, Bochs is not GNU ? > > hmm probably not - but it seems to be free enough ;) "free enough" ? as a member of the French Chapter of FSF Europe, i see some irony when these two words are together :-) > > It makes the same problem as a plain C simulator : we already have to deal with > > a VHDL source tree and there are too few contributors yet. we can't hire > > anybody, you know : it's all volunteer work. when work is done. > > true .. The biggest problem I see: is there any free tool to use > for simulation cpu (or other logic) in VHDL ? If not it too hard > to write one ? We use both Simili and Vanilla. These freeware VHDL simulation tools are explained in depths in the file f-cpu/vhdl/VHDL-HOWTO.f-cpu provided in the f-cpu source package. Look at a file named "stable"-something.tgz in http://f-cpu.seul.org/new (300KO IIRC) If you have a decent Linux box, installing one of them is pretty easy. Installing both is recommended if you are developping code because one tool can catch the other tool's weaknesses. > > slow if we can't access full-custom technologies (like Intel and IBM do). > > Beyond, another strategy must be used. > > I'm not experianced here, what is difference between ASIC and full > custom ? ASIC can use only predefined blocks ? "Application Specific Integrated Circuit", it's a generic name for ICs that you design for yourself with existing commercial tools. "full-custom" is handcrafted, hand-optimised design with a lot of chip and technology-specific tools and development. That's how the "big irons" do their chips (Intel, IBM, ...) because they own the factories and the research labs. When you can't, you have to get a "design kit" from your fundry , it's a set of tools or description files that hook to your commercial tool, they indicate the tool how to make transistors and gates etc... regards, > devik WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 23:21:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFn-00023o-00 for ; Tue, 23 Apr 2002 01:29:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:51 +0200 (CEST) Received: (qmail 11062 invoked by uid 0); 22 Apr 2002 21:15:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 22 Apr 2002 21:15:19 -0000 Received: by moria.seul.org (Postfix) id 52FFA146946; Mon, 22 Apr 2002 17:15:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 398BA14694D; Mon, 22 Apr 2002 17:15:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id C60E4146946 for ; Mon, 22 Apr 2002 17:15:05 -0400 (EDT) Received: from f-cpu.org (kdl11-95.n.club-internet.fr [213.44.9.95]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 81CED1717 for ; Mon, 22 Apr 2002 23:15:03 +0200 (CEST) Message-ID: <3CC47EE7.99C10F50@f-cpu.org> Date: Mon, 22 Apr 2002 23:21:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Juergen Goeritz wrote: > On Mon, 22 Apr 2002, Yann Guidon wrote: > >after some research, i think that some other computers use > >this kind of technique but i'm not sure. > >SRB was created when writing a mail during the "how many registers" thread > >and it is closely related to the FC0 architecture but it is possible > >to find a similar principle in the i860, maybe (or is it i960 ?) > > i860 was the floating point vector processor, i960 is the embedded > RISC processor (both Intel). i don't remember which, but one (or maybe both, i don't know) has a mechanism for fast register set swapping. Some other CPUs probably have something similar. > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 22 23:21:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFo-00023o-00 for ; Tue, 23 Apr 2002 01:29:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:52 +0200 (CEST) Received: (qmail 5544 invoked by uid 0); 22 Apr 2002 21:15:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 22 Apr 2002 21:15:33 -0000 Received: by moria.seul.org (Postfix) id 0172814694D; Mon, 22 Apr 2002 17:15:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F187814694F; Mon, 22 Apr 2002 17:15:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 5F10C14694D for ; Mon, 22 Apr 2002 17:15:11 -0400 (EDT) Received: from f-cpu.org (kdl11-95.n.club-internet.fr [213.44.9.95]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 899CE1773 for ; Mon, 22 Apr 2002 23:15:08 +0200 (CEST) Message-ID: <3CC47EEC.76B750F1@f-cpu.org> Date: Mon, 22 Apr 2002 23:21:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i don't want to start a new thread but i have to give some explanations. Andreas Romeyke wrote: > Hello, > > > > Remember, forth can do this... and surplus you can test forth-code > > > interactively... > > > > Forth is an incredible language but it can't do all i want, > > or i would use it for a loooong time. It also introduces a lot of things that > > can interfere with the algorithms, or at least make you forget about > > what you want to do. Finally, the largest scope that i could globally > > optimize by hand is 100 or 120 instructions per block. we need to go beyond > > that. Forth is the contrary of a dataflow graph analysis tool because > > it over-serialises the computations. > > I disagreed. do you disagree on the serialisation ? A stack-based langagae is inherently serial. this is the lethal bottleneck and it makes the execution on superpipelined + superscalar CPU underefficient because from 2 to 12 execution "threads" (dependencies) must be handled at a time. For example, if you have 4 pipelines with 3 cycles of latency, you have to find 12 operations to perform. Forth's programming paradigm forces this to be 1 in any case because the stack is the critical ressource. Even 4-stack or 5-stack designs can't solve this problem completely. > First is Forth only a little more than a MACRO-library of assembler-code. > Second it is small and easy to learn mmmm the learning curve is ok but prepare the Aspirin if you're a newcomer... > 3-th there are forth-dialects coming with an object-oriented manner > 4-th it is fast enough, compileable and interpretable not true anymore for superscalar superpipelined CPU. Fortran and C are much faster on modern computers ... > 5-th we can implement a forth-interpreter/compiler for F-CPU in much > easier way than for C and Co. > 6-th we can test the FC0 as fast as possible what is the meaning of "fast" here ? > 7-th We should have the focus on the hardware-site of F-CPU, we need a > higher language only for testing the core, is not it? > 8-th we can bootstrap the FC0, it is EPROM programmable > 9-th we become a set of useful ASM-instructions > > My only disadvantage was, that a mapping of forth-technique to > register-based cpu could be ineffective, but after some words with > compiler-developers, should this handable... it is not "impossible" but the gap is so large that you can't hope the same level of efficiency as other techniques. Even gcc might make better binaries :-( > IMHO all points fullfilled: > > > - easy readability, easy learning, easy debugging. Forth is not very readable, at least not for the unexperienced ... > > > - easy simulation of unimplemented parts (e.g. like > > > the test stimulation possibilities in VHDL) > > > - integrated abstract layer documentation scheme > > > that could be extended to automatic code generation. > > An adaption of a special language should be done later. Forth, at least Chuck's flavor, is a marvelous little thing but it is not adapted (less than C) to modern CPUs and F-CPU was not designed to run FORTH code. Take for example the DCT code i recently published. how would you code THAT in FORTH ? and then, how would this translate to machine code ? And what would be the instruction count with an existing implementation of FORTH ? What i need is a DataFlow Graph analysis tool that allows me to handle large chuncks of code with all the automated tedious tasks that i usually do by hand (register allocation, reallocation, interleaving...) > Bye Andreas regards, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Apr 22 23:15:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFp-00023o-00 for ; Tue, 23 Apr 2002 01:29:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:53 +0200 (CEST) Received: (qmail 32757 invoked by uid 0); 22 Apr 2002 21:32:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 22 Apr 2002 21:32:06 -0000 Received: by moria.seul.org (Postfix) id 6BCBF146951; Mon, 22 Apr 2002 17:32:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69757146950; Mon, 22 Apr 2002 17:32:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id EC2BD14694E for ; Mon, 22 Apr 2002 17:32:02 -0400 (EDT) Received: from ifurita (213.44.148.215) by mail.laposte.net (5.5.044) id 3CC408820000AFDB for f-cpu@seul.org; Mon, 22 Apr 2002 23:32:01 +0200 Message-ID: <003c01c1ea42$ca88f940$d7942cd5@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Mon, 22 Apr 2002 23:15:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N What is a PD ? I don't have any idea of links. I learn about CAML when I was in University. ----- Original Message ----- From: Juergen Goeritz To: Sent: Monday, April 22, 2002 8:41 PM Subject: Re: [f-cpu] Winograd DCT on my seul.org account > > Is it PD? Could you provide a link? Thanks! > > JG > > > On Mon, 22 Apr 2002, Christophe wrote: > > >CAML combines imperative and functionnal programming. In a certain way, LISP or > >C programs can be easily ported to CAML. There is another project COQ, which > >based on CAML and have the proprietary to check if an algorithms is correct > >(I'm speaking about the correctness of an algorithm, something that C is unable > >to check). We don't also need to use YACC and LEX with CAML because it can also > >be used as a parser. > > > >Please don't think we should use CAML :). I'm just telling you that CAML is > >more than a simple language. > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:36:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFp-00023o-01 for ; Tue, 23 Apr 2002 01:29:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:53 +0200 (CEST) Received: (qmail 7002 invoked by uid 0); 22 Apr 2002 21:38:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 22 Apr 2002 21:38:38 -0000 Received: by moria.seul.org (Postfix) id 8542F14694E; Mon, 22 Apr 2002 17:38:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BA05146950; Mon, 22 Apr 2002 17:38:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (unknown [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id DE0FA14694E for ; Mon, 22 Apr 2002 17:38:34 -0400 (EDT) Received: from tholana (nas-cbv-8-62-147-157-38.dial.proxad.net [62.147.157.38]) by postfix1-2.free.fr (Postfix) with ESMTP id 57425AB5C9 for ; Mon, 22 Apr 2002 23:36:39 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Tue, 23 Apr 2002 01:36:08 +0000 X-Mailer: KMail [version 1.4] References: <20020419221434.07b3780d.pash.cracken@free.fr> <20020420002050.46424@thrai.stud.uni-hannover.de> <3CC09D04.3293CEF9@jetnet.ab.ca> In-Reply-To: <3CC09D04.3293CEF9@jetnet.ab.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230136.08551.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > Our goal is to improve computer science isn't it ? :-) > > > > That's definitely not my goal. > > I think the GOAL of the F-CPU is good assembler code. If a person can > code great for it then a high level compiler can do wonders. I agree with you, it's really easy to program in F-CPU assembler, more that I never see. We only need a good asm to warn us when we not good scheduled our instructions and we will have a good tool for optimisation. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:34:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFq-00023o-00 for ; Tue, 23 Apr 2002 01:29:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:54 +0200 (CEST) Received: (qmail 21104 invoked by uid 0); 22 Apr 2002 21:39:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 22 Apr 2002 21:39:03 -0000 Received: by moria.seul.org (Postfix) id E622214694F; Mon, 22 Apr 2002 17:39:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D33D9146954; Mon, 22 Apr 2002 17:39:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 6917214694F for ; Mon, 22 Apr 2002 17:39:01 -0400 (EDT) Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by bettik.munge.net (Postfix) with ESMTP id C9F374F7CB for ; Mon, 22 Apr 2002 16:35:42 -0500 (CDT) Received: from tholana (nas-cbv-8-62-147-157-38.dial.proxad.net [62.147.157.38]) by postfix1-2.free.fr (Postfix) with ESMTP id EEBD1AB563 for ; Mon, 22 Apr 2002 23:34:48 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Tue, 23 Apr 2002 01:34:16 +0000 X-Mailer: KMail [version 1.4] References: <3CC1A26A.B2E010B7@f-cpu.org> In-Reply-To: <3CC1A26A.B2E010B7@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230134.16007.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Martin Devera wrote: > > > However this creates a new kind of problems : gcc should export > > > the whole Intermediate Representation instead of just register-wise > > > code, because register reallocation works best on program-wise > > > working sets. Usually, FPGA/ASIC synthesiser + fitter exchange data > > > in the form of a flattened netlist, but GCC outputs code > > > that almost looks like already-fitted code. > > By the way there is already gcc3 patch which exports whole > > IR as XML .. (http://sourceforge.net/projects/introspector/) > that's a good news ! Hum,... If we use the IR XML representation, we can not represent much more than what the backend of gcc receive. So we will not be able to do a better work than a normal gcc backend, without the compatibiliti... > > But then your postprocessor will be the same as "detached" > > gcc backend IMHO. > > why not. > but my initial idea was to give GCC an oversimplified ISA > and do the naughty F-CPU stuff ourselves. > Using XML would force me to learn it and GCC3 is not well percieved, > but it's a bet on the far future. XML, is only a way to see a tree, and gcc3 is actually far from a perfect compiler, but I think that he will be ready when we have a prototype. And at this time he will probably generate some SIMD code ;-) > > devik > > PS: have my Itanium question been so dumb or did I violated > > some f-cpu list roles ? Of course not, but what can we say before we have a prototype, it's not really realistic to compare a virtual CPU even if we can imagin it, to a real one that intel will probably remove from the market (because of AMD x86-64). But if you whant to know for the dnetc algorithm, I need 300 instructions per keys, and an estimation of AMD Athlon give me 250 cycles per keys... A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:26:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFr-00023o-00 for ; Tue, 23 Apr 2002 01:29:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:55 +0200 (CEST) Received: (qmail 16029 invoked by uid 0); 22 Apr 2002 21:39:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 22 Apr 2002 21:39:25 -0000 Received: by moria.seul.org (Postfix) id A7FD4146954; Mon, 22 Apr 2002 17:39:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B3AF146956; Mon, 22 Apr 2002 17:39:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 3761D146954 for ; Mon, 22 Apr 2002 17:39:24 -0400 (EDT) Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by bettik.munge.net (Postfix) with ESMTP id 186A34F775 for ; Mon, 22 Apr 2002 16:36:06 -0500 (CDT) Received: from tholana (nas-cbv-8-62-147-157-38.dial.proxad.net [62.147.157.38]) by postfix1-2.free.fr (Postfix) with ESMTP id 4D9B5AB54D for ; Mon, 22 Apr 2002 23:34:47 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Tue, 23 Apr 2002 01:26:27 +0000 X-Mailer: KMail [version 1.4] References: <001b01c1e939$445344c0$a9d6c2d4@ifurita> In-Reply-To: <001b01c1e939$445344c0$a9d6c2d4@ifurita> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230126.27938.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > What about CAML or derivatives ? :) And eiffel ? But, we need to support a lot of language and not only the one we can optimize... > You are speaking only about imperative languages, which, I think, is not > very suitable in huge projects where we need to trust what we code. The question is where did we need a language for the F-CPU ? for hardware : VHDL, OS : ASM+C, Virtual machine : ASM+C or VHDL, F-CPU asm : C... So where did you see a need of a new language ? For special developpement on F-CPU, perhaps ? In that case, it's not our choice, but the one of the developpers ! > Anyway, I don't think C is the most efficient language. Some people > considers it as a super assembler (register allocation, etc.), but in fact, > the way you write a C program is underoptimized compared with an > assembler : > For example, to do a left bit rotation, you need to do in C : > rotated_value = (value << shifter) | (((unsigned)value >> > ((sizeof(value) * 8) - shifter)) & ((sizeof(value) * 256) - 1)); I didn't agry whit your remark, it's possible to add some rewriting "macro" in gcc backend, so that a shiftl + or + shiftr = rotl. I think that's possible, perhaps not easy but possible. > There is no C operator for that kind of bit operation and the generated > code is not a 'rotl' but a mixture of 'shl' and 'or' operations. Using > inline functions with asm ? not a standard. Depending on target, GCC is > less or more efficient. Visual C++ or Borland asm directives are definitely > bad (cannot tell which register is allocatable or clobbered in an asm > directive). > The way to code in C language is one way to code but not the most efficient: > it is very easy to make buggy code even if each module has no bugs. I agree, but that's not the question, C/C++ will used and represent the majority of gnu software, so we need a good gcc port for F-CPU. But to test it and have some result we need a good virtual machine to see how bad the generated code is ;-) A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:40:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFr-00023o-01 for ; Tue, 23 Apr 2002 01:29:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:55 +0200 (CEST) Received: (qmail 2758 invoked by uid 0); 22 Apr 2002 21:41:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 22 Apr 2002 21:41:21 -0000 Received: by moria.seul.org (Postfix) id E72BD146950; Mon, 22 Apr 2002 17:41:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CC17F146956; Mon, 22 Apr 2002 17:41:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 4480A146950 for ; Mon, 22 Apr 2002 17:41:19 -0400 (EDT) Received: from tholana (nas-cbv-8-62-147-157-38.dial.proxad.net [62.147.157.38]) by postfix2-1.free.fr (Postfix) with ESMTP id 790CC5FA for ; Mon, 22 Apr 2002 23:41:16 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update Date: Tue, 23 Apr 2002 01:40:45 +0000 X-Mailer: KMail [version 1.4] References: <200204200337.50475.cedric.bail@free.fr> <20020420004304.25294@thrai.stud.uni-hannover.de> In-Reply-To: <20020420004304.25294@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230140.45413.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > First the FPU. Is it SIMD or not ? (problem with exeption and rouding for > > example, and perhaps a problem of size). Or is it SIMD hidden into the EU > > ? (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? > > date from Wed, 15 Aug 2001 23:12:27 +0200). > > I don't understand the meaning of fexp with a base ? What did that > > mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead of > > flog ? > > That's what I suggested (or similar, at least). There's no real need > for the third argument. Whether the instructions are base-e (natural > logarithm), base-10 or base-2 doesn't matter much either -- we should > choose a base that's easy to implement. So ok, we will select the base when we will implement this function. > > I have added fcmpl[e] instructions in level-1 floating-point for compare > > instruction. > > I'd rather pick `fcmpe' (equal) and `fcmpl' (less). Remember that a > floating-point number may have more than one representation (that is, > r1 xor r2 may not be zero, but their values are nevertheless the same). > `fcmple' (and its counterpart `cmple'), on the other hand, is redundant > because the expressions > a < b > b > a > !(a >= b) > !(b <= a) > are all equivalent (provided neither a nor b is a NaN). I agree, but I what thinking that it was more logic compared to the integer instructions. It can probably only be an alias, or a macro, but it's more clear. > > Finally, did we add an new f2f instruction for FP conversions (32bits | > > 64bits -> 32 bits | 64 bits) ? > > We should. and f2f, is it a good name ? > > About LNS: what are the rounding method (or mode) ? same as FPU ? And did > > we add 16 bits representation (like nicO suggestion ?) ? > > > > About memory, I didn't understand the problem with store[f] ? Can you > > explain it to me ? And did we add a new flag for a special immediate > > operand (6 bits value + 2 bits left-shift, as Michael suggest ?) > > I guess that was operand order... you can leave it as it is. Ok, and for 16 bits LNS number ? > > I did'nt understand why did we specify into the CPU a fixed memory > > hierarchichies (see cachemem). I think that we could say that 0 will be > > the quicker and 7 the slower, or something like that ? And did we add a > > 'cachecode r1' instruction that will perform a prefetch in I-Cache before > > a jmp (in a function call for example like in Michael's C++ sample). > > And about the storem/loadm, I have update with the new form you give > > (I have read gcc documentation, and it's exactly the called form it need, > > so it will be easy to use for a compiler). But I think that I must remove > > any reference to SRB mechanism, because SRB is done in physical address > > space (no trap) and the storem/loadm must be done in virtual address > > space (trap problem). An other point about this instruction, did we add > > the 2 registers form ? > > We now have a unconditionnal move, but is it a alias for 'movez r0, > > r2, r1' or something else ? > `movez r0, r1, r2' and `move r1, r2' are equivalent (that is, they're > the same instruction). It's what I understand. > > In the instruction set I have updated bitop[i]. I think that I must > > update bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'. > > That should read `r1 = bit_reverse(r2) >> (size-r3-1)', if I remember > correctly. The other version is affected by the register size (which > is bad). Ok. > > An other question > > is about nop function, actually it's specified as a movez r0, r0, r0 that > > must be coded as a 0x00000000 in hardware, but must I change it so that > > it became 'nor r0, r2, r1' or 'xnor r0, r2, r1' ? (I don't understand > > this change). > > I guess you mixed up `nop' and `not'. Oups, you are right. > Both `nor ...' and `xnor ...' are equivalent to the (non-existing) > `not r2, r1'. Actually, there are a lot more ways to write `not'. Ok, but not one we prefer ? > > And I didn't understand the effect of widen new instruction. I don't > > understand if it will take 2 cycles and only replace two separated > > instructions or if it does something more. > > It should take only 1 cycle (but isn't implemented yet). > Otherwise, we could also use shift/mask operations. > > The not instruction did not exist anymore, right ? So it became an > > alias, but what is the better choice for this alias ? > See above Ok A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:43:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFs-00023o-00 for ; Tue, 23 Apr 2002 01:29:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:56 +0200 (CEST) Received: (qmail 29924 invoked by uid 0); 22 Apr 2002 21:44:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 22 Apr 2002 21:44:04 -0000 Received: by moria.seul.org (Postfix) id 8EA39146959; Mon, 22 Apr 2002 17:44:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C75F146958; Mon, 22 Apr 2002 17:44:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 30456146956 for ; Mon, 22 Apr 2002 17:44:02 -0400 (EDT) Received: from tholana (nas-cbv-8-62-147-157-38.dial.proxad.net [62.147.157.38]) by postfix2-1.free.fr (Postfix) with ESMTP id 111131C5 for ; Mon, 22 Apr 2002 23:44:00 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Always problem with SIMD and RC5 Date: Tue, 23 Apr 2002 01:43:29 +0000 X-Mailer: KMail [version 1.4] References: <200204200342.25129.cedric.bail@free.fr> <3CC11205.DF8CEB7@f-cpu.org> In-Reply-To: <3CC11205.DF8CEB7@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230143.29291.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > cedric wrote: > > I always have a problem with my final test in my RC5 algorithm. I don't > > find a way to know the number of chunk or the current max size of the > > SIMD registers. Perhaps did we need to add two new SR : > > SR_REGISTER_SIZE_MAX = the maximum size of a register in SIMD mode > This already exists, it's SR_MAX_SIZE > > SR_REGISTER_CURRENT_SIZE = the current limit. > > (If thing that both a required, because we need to first know in wich > > state we are and then change the value arcoding to the CPU and the > > algorithm) > if you want to do it "the hard way", take the maximum value > that you find in SR_SIZE_0 to SR_SIZE_3. But by convention, you can decide > to put the maximum size in SR_SIZE_3, which usually corresponds to size=64 > bits when the CPU is limited to 64 bits. > hope this old trick helps, Euh, ok, if you prefer, I want to know if SR_MAX_SIZE div SR_SIZE_Q = Number of chunk in a register ? I think yes, but I am not sure. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 23 00:14:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFt-00023o-00 for ; Tue, 23 Apr 2002 01:29:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:57 +0200 (CEST) Received: (qmail 3261 invoked by uid 0); 22 Apr 2002 22:07:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 22 Apr 2002 22:07:34 -0000 Received: by moria.seul.org (Postfix) id 5B643146957; Mon, 22 Apr 2002 18:07:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 39A6F14695A; Mon, 22 Apr 2002 18:07:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id BD127146957 for ; Mon, 22 Apr 2002 18:07:32 -0400 (EDT) Received: from f-cpu.org (kdl16-52.n.club-internet.fr [213.44.18.52]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 53AFF1685 for ; Tue, 23 Apr 2002 00:07:29 +0200 (CEST) Message-ID: <3CC48B31.DCABC006@f-cpu.org> Date: Tue, 23 Apr 2002 00:14:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <20020419221434.07b3780d.pash.cracken@free.fr> <20020420002050.46424@thrai.stud.uni-hannover.de> <3CC09D04.3293CEF9@jetnet.ab.ca> <200204230136.08551.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: > > > > Our goal is to improve computer science isn't it ? :-) > > > > > > That's definitely not my goal. > > > > I think the GOAL of the F-CPU is good assembler code. If a person can > > code great for it then a high level compiler can do wonders. > I agree with you, it's really easy to program in F-CPU assembler, more that I > never see. We only need a good asm to warn us when we not good scheduled our > instructions and we will have a good tool for optimisation. As i have already written, asm is good for small parts of code or as an exercise, to see what the compiler could do. However it is not the goal of the assembler to tell you if you coded correctly or not. Or at least, you shoud be able to shut this option off. Furthermore, this option will not be useful when you need to write 1000 instructions. a trained brain can't even handle so many informations and your tool will not be useful, because it is bound to the textual representation of the program. In fewer words, what you do is "cool" but won't get you really far. > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 23 00:14:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFt-00023o-01 for ; Tue, 23 Apr 2002 01:29:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:57 +0200 (CEST) Received: (qmail 16249 invoked by uid 0); 22 Apr 2002 22:07:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 22 Apr 2002 22:07:46 -0000 Received: by moria.seul.org (Postfix) id BC21214695D; Mon, 22 Apr 2002 18:07:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9B8D14695C; Mon, 22 Apr 2002 18:07:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 4361514695A for ; Mon, 22 Apr 2002 18:07:34 -0400 (EDT) Received: from f-cpu.org (kdl16-52.n.club-internet.fr [213.44.18.52]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 8B6D91690 for ; Tue, 23 Apr 2002 00:07:30 +0200 (CEST) Message-ID: <3CC48B33.343F7A49@f-cpu.org> Date: Tue, 23 Apr 2002 00:14:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Always problem with SIMD and RC5 References: <200204200342.25129.cedric.bail@free.fr> <3CC11205.DF8CEB7@f-cpu.org> <200204230143.29291.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: > > cedric wrote: > > > I always have a problem with my final test in my RC5 algorithm. I don't > > > find a way to know the number of chunk or the current max size of the > > > SIMD registers. Perhaps did we need to add two new SR : > > > SR_REGISTER_SIZE_MAX = the maximum size of a register in SIMD mode > > This already exists, it's SR_MAX_SIZE > > > > SR_REGISTER_CURRENT_SIZE = the current limit. > > > (If thing that both a required, because we need to first know in wich > > > state we are and then change the value arcoding to the CPU and the > > > algorithm) > > > if you want to do it "the hard way", take the maximum value > > that you find in SR_SIZE_0 to SR_SIZE_3. But by convention, you can decide > > to put the maximum size in SR_SIZE_3, which usually corresponds to size=64 > > bits when the CPU is limited to 64 bits. > > > hope this old trick helps, > Euh, ok, if you prefer, I want to know if SR_MAX_SIZE div SR_SIZE_Q = Number > of chunk in a register ? I think yes, but I am not sure. SR_MAX_SIZE and SR_SIZE_x are powers of two, in bytes. If you have 32-bit chunks, you can write geti SR_MAX_SIZE, r1 shri 2, r1, r1 and r1 contains the number of 32-bit words per register. > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 22 23:20:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFu-00023o-00 for ; Tue, 23 Apr 2002 01:29:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:58 +0200 (CEST) Received: (qmail 28912 invoked by uid 0); 22 Apr 2002 22:23:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 22 Apr 2002 22:23:33 -0000 Received: by moria.seul.org (Postfix) id 19CC814695A; Mon, 22 Apr 2002 18:23:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0707214695C; Mon, 22 Apr 2002 18:23:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id C8B1F14695A for ; Mon, 22 Apr 2002 18:23:29 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01288; Mon, 22 Apr 2002 23:20:26 +0200 Message-ID: <20020422232026.17948@thrai.stud.uni-hannover.de> Date: Mon, 22 Apr 2002 23:20:26 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <009901c1e9ed$ed5583d0$bca45982@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <009901c1e9ed$ed5583d0$bca45982@student.utwente.nl>; from Marco Al on Mon, Apr 22, 2002 at 01:07:43PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 01:07:43PM +0200, Marco Al wrote: > Juergen Goeritz wrote: > > > What one would need is a language with a very good > > type checking like in Ada, Pascal, Modula a.s.o, a > > language that can do easy prototyping and reuse of > > coded parts like Forth, a language disallowing the > > side-effect programming styles, a language that can > > handle OO approaches and a language that is capable > > of parallel execution pathes. > > How about Occam? ;) No, he's talking about Lisp ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 22 23:18:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFu-00023o-01 for ; Tue, 23 Apr 2002 01:29:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:58 +0200 (CEST) Received: (qmail 585 invoked by uid 0); 22 Apr 2002 22:23:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 22 Apr 2002 22:23:44 -0000 Received: by moria.seul.org (Postfix) id 5900C14695C; Mon, 22 Apr 2002 18:23:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 111F8146960; Mon, 22 Apr 2002 18:23:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id 6C80614695C for ; Mon, 22 Apr 2002 18:23:32 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01279; Mon, 22 Apr 2002 23:18:36 +0200 Message-ID: <20020422231836.07415@thrai.stud.uni-hannover.de> Date: Mon, 22 Apr 2002 23:18:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Apr 22, 2002 at 12:43:41PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 12:43:41PM +0200, Juergen Goeritz wrote: > On Mon, 22 Apr 2002, Christophe wrote: [...] > >I'm speaking about parallel execution per instruction, not per thread > >(instructions in a thread are still serialized). So long as we get no real cpu > >able to execute parallel instructions, there is no real gain for anything for a > >true parallelism. Yes, a parallel language is okay to see what is independent > >(the good point) and shall be surely better than C but we will still have a lot > >of overhead due to the use of multithreading (stack space and switching for > >example). So if a CPU has power enough, we tend to use it more in serial way > >than parallel way since there is no real reason to think a multithreading would > >*ALWAYS* run better. > > What do you mean by better? It may not be faster at all on > a single processor due to the extended overhead. But there > is one advantage compared to sequential programming. The > parallel threads could communicate with each other in new > ways if you think of each thread as a unique entity... Threads work best if they don't have to communicate with each other, no matter if they're running on 1 CPU or 1000. Communication usually means that you have to synchronize the sender and receiver thread, and the faster one will have to wait. In an MP system, you can run another thread instead, but synchronization and context switching still take some time -- and the more threads communicate with each other, the more synchronization overhead you'll have. Therefore, `fine-grained' threading doesn't work well (e.g. threads that return quickly or communicate a lot). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 23 00:33:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFv-00023o-00 for ; Tue, 23 Apr 2002 01:29:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:29:59 +0200 (CEST) Received: (qmail 21428 invoked by uid 0); 22 Apr 2002 22:33:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Apr 2002 22:33:56 -0000 Received: by moria.seul.org (Postfix) id 21F9F14695E; Mon, 22 Apr 2002 18:33:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0270D146961; Mon, 22 Apr 2002 18:33:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id E344E14695E for ; Mon, 22 Apr 2002 18:33:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01654; Tue, 23 Apr 2002 00:33:50 +0200 Message-ID: <20020423003350.64125@thrai.stud.uni-hannover.de> Date: Tue, 23 Apr 2002 00:33:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CC47EE7.99C10F50@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CC47EE7.99C10F50@f-cpu.org>; from Yann Guidon on Mon, Apr 22, 2002 at 11:21:43PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 11:21:43PM +0200, Yann Guidon wrote: [...] > > i860 was the floating point vector processor, i960 is the embedded > > RISC processor (both Intel). > > i don't remember which, but one (or maybe both, i don't know) > has a mechanism for fast register set swapping. Some other > CPUs probably have something similar. Zilog Z80 ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 23 00:44:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFw-00023o-00 for ; Tue, 23 Apr 2002 01:30:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:30:00 +0200 (CEST) Received: (qmail 27254 invoked by uid 0); 22 Apr 2002 22:44:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 22 Apr 2002 22:44:42 -0000 Received: by moria.seul.org (Postfix) id 63D6F146965; Mon, 22 Apr 2002 18:44:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5BC78146964; Mon, 22 Apr 2002 18:44:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id E9F04146961 for ; Mon, 22 Apr 2002 18:44:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01688; Tue, 23 Apr 2002 00:44:36 +0200 Message-ID: <20020423004436.36499@thrai.stud.uni-hannover.de> Date: Tue, 23 Apr 2002 00:44:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC47EEC.76B750F1@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CC47EEC.76B750F1@f-cpu.org>; from Yann Guidon on Mon, Apr 22, 2002 at 11:21:48PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Apr 22, 2002 at 11:21:48PM +0200, Yann Guidon wrote: [...] > A stack-based langagae is inherently serial. this is the lethal bottleneck > and it makes the execution on superpipelined + superscalar CPU underefficient > because from 2 to 12 execution "threads" (dependencies) must be handled at a time. > For example, if you have 4 pipelines with 3 cycles of latency, you have to > find 12 operations to perform. Forth's programming paradigm forces this to be 1 > in any case because the stack is the critical ressource. Even 4-stack or 5-stack > designs can't solve this problem completely. [...] Stack-based languages (this includes not only Forth, but also Java) can execute quite efficiently if you use a smart compiler. The usual approach is to use inline substitution, transform the stack-based code into another representation and create optimized machine code from that. The resulting code should be as good as that created by any C compiler. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 23 00:51:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 16znFw-00023o-01 for ; Tue, 23 Apr 2002 01:30:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 01:30:00 +0200 (CEST) Received: (qmail 17711 invoked by uid 0); 22 Apr 2002 22:51:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 22 Apr 2002 22:51:37 -0000 Received: by moria.seul.org (Postfix) id 8DF46146961; Mon, 22 Apr 2002 18:51:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 83322146963; Mon, 22 Apr 2002 18:51:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id 8E2E2146961 for ; Mon, 22 Apr 2002 18:51:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01712; Tue, 23 Apr 2002 00:51:32 +0200 Message-ID: <20020423005131.37696@thrai.stud.uni-hannover.de> Date: Tue, 23 Apr 2002 00:51:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update References: <200204200337.50475.cedric.bail@free.fr> <20020420004304.25294@thrai.stud.uni-hannover.de> <200204230140.45413.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204230140.45413.cedric.bail@free.fr>; from cedric on Tue, Apr 23, 2002 at 01:40:45AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 23, 2002 at 01:40:45AM +0000, cedric wrote: [...] > > > Finally, did we add an new f2f instruction for FP conversions (32bits | > > > 64bits -> 32 bits | 64 bits) ? > > > > We should. > and f2f, is it a good name ? Since we already have int2f/f2int and int2l/l2int, it's a perfect match. > > > About LNS: what are the rounding method (or mode) ? same as FPU ? And did > > > we add 16 bits representation (like nicO suggestion ?) ? > > > > > > About memory, I didn't understand the problem with store[f] ? Can you > > > explain it to me ? And did we add a new flag for a special immediate > > > operand (6 bits value + 2 bits left-shift, as Michael suggest ?) > > > > I guess that was operand order... you can leave it as it is. > Ok, and for 16 bits LNS number ? Sorry, I don't remember. [...] > > Both `nor ...' and `xnor ...' are equivalent to the (non-existing) > > `not r2, r1'. Actually, there are a lot more ways to write `not'. > Ok, but not one we prefer ? None? You can mention two or three (and hope that it makes the reader THINK about it). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Tue Apr 23 05:27:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yp-0002mi-01 for ; Tue, 23 Apr 2002 22:06:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:47 +0200 (CEST) Received: (qmail 1336 invoked by uid 0); 23 Apr 2002 03:27:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 23 Apr 2002 03:27:25 -0000 Received: by moria.seul.org (Postfix) id 0132B14696A; Mon, 22 Apr 2002 23:27:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ED798146969; Mon, 22 Apr 2002 23:27:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 41467146967 for ; Mon, 22 Apr 2002 23:27:19 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g3N3RIC10742 for ; Tue, 23 Apr 2002 05:27:18 +0200 Message-ID: <018301c1ea76$c7cee4b0$bca45982@student.utwente.nl> From: "Marco Al" To: References: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> <20020422231836.07415@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Tue, 23 Apr 2002 05:27:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Threads work best if they don't have to communicate with each other, > no matter if they're running on 1 CPU or 1000. Communication usually > means that you have to synchronize the sender and receiver thread, and > the faster one will have to wait. In an MP system, you can run another > thread instead, but synchronization and context switching still take > some time -- and the more threads communicate with each other, the more > synchronization overhead you'll have. Therefore, `fine-grained' threading > doesn't work well (e.g. threads that return quickly or communicate a lot). Depends on the architecture. "We can even use threads of about 10 instructions to achieve efficient parallel execution" >from http://www.computer.org/micro/mi2000/pdf/m4012.pdf Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Tue Apr 23 12:21:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yr-0002mi-01 for ; Tue, 23 Apr 2002 22:06:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:49 +0200 (CEST) Received: (qmail 23806 invoked by uid 0); 23 Apr 2002 06:21:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Apr 2002 06:21:18 -0000 Received: by moria.seul.org (Postfix) id 8988E146808; Tue, 23 Apr 2002 02:21:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5AED6146969; Tue, 23 Apr 2002 02:21:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 019C7146808 for ; Tue, 23 Apr 2002 02:21:11 -0400 (EDT) Received: from art1.none.de ([62.27.156.150]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g3N6LBr16755 for ; Tue, 23 Apr 2002 08:21:12 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.27.156.150] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 16zxQo-0007RY-00 for ; Tue, 23 Apr 2002 12:21:54 +0200 Date: Tue, 23 Apr 2002 12:21:49 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC47EEC.76B750F1@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > find 12 operations to perform. Forth's programming paradigm forces this to be 1 > in any case because the stack is the critical ressource. Even 4-stack or 5-stack > designs can't solve this problem completely. See http://www.complang.tuwien.ac.at/papers/ertl96diss.ps.gz for Example. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8xTXCClxplZklbgERAqDbAKCTQiInCp9cbW6Fj5gkrZhJNO3uxACeKnLX I7VKprtxmQdGSJH/JiCzxfY= =4QGC -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 23 08:54:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Ys-0002mi-00 for ; Tue, 23 Apr 2002 22:06:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:50 +0200 (CEST) Received: (qmail 16605 invoked by uid 0); 23 Apr 2002 06:59:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Apr 2002 06:59:19 -0000 Received: by moria.seul.org (Postfix) id 20A9A146968; Tue, 23 Apr 2002 02:59:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1767114696B; Tue, 23 Apr 2002 02:59:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0C29D146968 for ; Tue, 23 Apr 2002 02:59:17 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zuC2-0000X4-00 for f-cpu@seul.org; Tue, 23 Apr 2002 08:54:26 +0200 Date: Tue, 23 Apr 2002 08:54:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <200204230126.27938.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 23 Apr 2002, cedric wrote: >> What about CAML or derivatives ? :) >And eiffel ? But, we need to support a lot of language and not only the one we >can optimize... We have proceeded now to the point where to distinct the optimizer from the language regarding f-cpu. >> You are speaking only about imperative languages, which, I think, is not >> very suitable in huge projects where we need to trust what we code. >The question is where did we need a language for the F-CPU ? for hardware : >VHDL, OS : ASM+C, Virtual machine : ASM+C or VHDL, F-CPU asm : C... > >So where did you see a need of a new language ? For special developpement >on F-CPU, perhaps ? In that case, it's not our choice, but the one of the >developpers ! We were talking a lot about parallel algorithms and the lack of tools that can handle it in a good manner. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 23 08:38:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Ys-0002mi-01 for ; Tue, 23 Apr 2002 22:06:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:50 +0200 (CEST) Received: (qmail 13858 invoked by uid 0); 23 Apr 2002 06:59:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 23 Apr 2002 06:59:22 -0000 Received: by moria.seul.org (Postfix) id AB94914696B; Tue, 23 Apr 2002 02:59:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9667E14696C; Tue, 23 Apr 2002 02:59:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id A14FB14696B for ; Tue, 23 Apr 2002 02:59:20 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ztx3-0000Wy-00 for f-cpu@seul.org; Tue, 23 Apr 2002 08:38:57 +0200 Date: Tue, 23 Apr 2002 08:38:57 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <20020422232026.17948@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Michael Riepe wrote: >On Mon, Apr 22, 2002 at 01:07:43PM +0200, Marco Al wrote: >> Juergen Goeritz wrote: >> >> > What one would need is a language with a very good >> > type checking like in Ada, Pascal, Modula a.s.o, a >> > language that can do easy prototyping and reuse of >> > coded parts like Forth, a language disallowing the >> > side-effect programming styles, a language that can >> > handle OO approaches and a language that is capable >> > of parallel execution pathes. >> >> How about Occam? ;) > >No, he's talking about Lisp ;) Since when does Lisp support parallel execution? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 23 08:35:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yt-0002mi-00 for ; Tue, 23 Apr 2002 22:06:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:51 +0200 (CEST) Received: (qmail 7943 invoked by uid 0); 23 Apr 2002 06:59:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 23 Apr 2002 06:59:29 -0000 Received: by moria.seul.org (Postfix) id 714F414696C; Tue, 23 Apr 2002 02:59:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B5F514696E; Tue, 23 Apr 2002 02:59:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id EC3B614696C for ; Tue, 23 Apr 2002 02:59:23 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zttN-0000Wu-00 for f-cpu@seul.org; Tue, 23 Apr 2002 08:35:09 +0200 Date: Tue, 23 Apr 2002 08:35:08 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <003c01c1ea42$ca88f940$d7942cd5@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Christophe wrote: >What is a PD ? PD means public domain. I meant to get a link to an open source code version of the compiler. If there is none, forget the language for this project. JG >I don't have any idea of links. I learn about CAML when I was in University. > >----- Original Message ----- From: Juergen Goeritz >To: >Sent: Monday, April 22, 2002 8:41 PM >Subject: Re: [f-cpu] Winograd DCT on my seul.org account > > >> >> Is it PD? Could you provide a link? Thanks! >> >> JG >> >> >> On Mon, 22 Apr 2002, Christophe wrote: >> >> >CAML combines imperative and functionnal programming. In a certain way, LISP >or >> >C programs can be easily ported to CAML. There is another project COQ, which >> >based on CAML and have the proprietary to check if an algorithms is correct >> >(I'm speaking about the correctness of an algorithm, something that C is >unable >> >to check). We don't also need to use YACC and LEX with CAML because it can >also >> >be used as a parser. >> > >> >Please don't think we should use CAML :). I'm just telling you that CAML is >> >more than a simple language. >> > >> > > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 23 08:37:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yu-0002mi-00 for ; Tue, 23 Apr 2002 22:06:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:52 +0200 (CEST) Received: (qmail 19151 invoked by uid 0); 23 Apr 2002 06:59:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 23 Apr 2002 06:59:36 -0000 Received: by moria.seul.org (Postfix) id 31B0D14696E; Tue, 23 Apr 2002 02:59:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08F98146970; Tue, 23 Apr 2002 02:59:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0139014696E for ; Tue, 23 Apr 2002 02:59:26 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16ztw8-0000Ww-00 for f-cpu@seul.org; Tue, 23 Apr 2002 08:38:00 +0200 Date: Tue, 23 Apr 2002 08:37:59 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <20020422231836.07415@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Michael Riepe wrote: >Threads work best if they don't have to communicate with each other, >no matter if they're running on 1 CPU or 1000. Communication usually >means that you have to synchronize the sender and receiver thread, and >the faster one will have to wait. In an MP system, you can run another >thread instead, but synchronization and context switching still take >some time -- and the more threads communicate with each other, the more >synchronization overhead you'll have. Therefore, `fine-grained' threading >doesn't work well (e.g. threads that return quickly or communicate a lot). It was just another possibility shown. But most of my thoughts turn around clustered implementations anyway... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Apr 23 08:45:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yu-0002mi-01 for ; Tue, 23 Apr 2002 22:06:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:52 +0200 (CEST) Received: (qmail 6079 invoked by uid 0); 23 Apr 2002 06:59:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Apr 2002 06:59:44 -0000 Received: by moria.seul.org (Postfix) id 25D76146969; Tue, 23 Apr 2002 02:59:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1042F146970; Tue, 23 Apr 2002 02:59:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 279B7146969 for ; Tue, 23 Apr 2002 02:59:29 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 16zu3B-0000X2-00 for f-cpu@seul.org; Tue, 23 Apr 2002 08:45:17 +0200 Date: Tue, 23 Apr 2002 08:45:17 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium In-Reply-To: <3CC47EE7.99C10F50@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 22 Apr 2002, Yann Guidon wrote: >Juergen Goeritz wrote: >> On Mon, 22 Apr 2002, Yann Guidon wrote: >> >after some research, i think that some other computers use >> >this kind of technique but i'm not sure. >> >SRB was created when writing a mail during the "how many registers" thread >> >and it is closely related to the FC0 architecture but it is possible >> >to find a similar principle in the i860, maybe (or is it i960 ?) >> >> i860 was the floating point vector processor, i960 is the embedded >> RISC processor (both Intel). > >i don't remember which, but one (or maybe both, i don't know) >has a mechanism for fast register set swapping. Some other >CPUs probably have something similar. Me think it was i860 because I worked with i960 and can't remember that sort of thing. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Apr 23 10:33:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yw-0002mi-00 for ; Tue, 23 Apr 2002 22:06:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:54 +0200 (CEST) Received: (qmail 26611 invoked by uid 0); 23 Apr 2002 08:36:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 23 Apr 2002 08:36:13 -0000 Received: by moria.seul.org (Postfix) id 2EBF014696D; Tue, 23 Apr 2002 04:36:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 238A4146970; Tue, 23 Apr 2002 04:36:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 5432114696D for ; Tue, 23 Apr 2002 04:36:12 -0400 (EDT) Received: (qmail 62179 invoked by uid 85); 23 Apr 2002 08:36:28 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 2.419884 secs); 23 Apr 2002 08:36:28 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 23 Apr 2002 08:36:25 -0000 Message-ID: <3CC51C58.5050409@yahoo.fr> Date: Tue, 23 Apr 2002 10:33:28 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: multipart/alternative; boundary="------------020005030101010900090706" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------020005030101010900090706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Scriiiitch ! Oups ! Danger, danger... Hello everybody, Sorry to add some comments only today but I have 269 mails left (i haven't yet finish to read all attached comments). I have begin to read this thread and I thinks some peoples seems not known the vhdl, because if you need programming some application with vhdl, good luck. Let's explain me. First I well known vhdl (i am a hardware man, then thanks for the compliments). Second, some history : vhdl is the abbreviation of Vhsic High-level Design Language, or Vlsi High-level Description Language (this is an academic fight about the D abbreviation); vhsic is itself the abbreviation for Very High Scale Integrated Circuit. This language have been firstly normalized in 1989, and have been modified only 2 time since (in 1993 and in 1998) under the reference ieee-1076. This language have been originally done to create some behavioral description of hardware to be able to make some design simulations. Yes, it has been developped in ada (and it has kept its limitations), but he hasn't all the feature of a programming language. If some one need create a program in vhdl, he must forget the sequential programming, he must think parallel execution programming, clock synchronism and sampling. In vhdl, you have two types of process the concurrential and the sequential (but not exactly same sequential than C execution). The code inside the sequential structure is executed in order of writing, but the "shared" variables (the name is not totally appropriated) are updated for the other process only at the end of the execution. All concurrential process are executed in parallel. By example, if in C you write : main () { ... a=b; c=a; ... } You have 3 "shared" variables a, b, c and in memory a=b and c=a at the end In vhdl, the syntax change (of course), but if you put your code like a concurrential statement : entity... end... architecture... ... begin ... a <= b; c <= a; ... end; At the end, you have only 2 "shared" variables b and c, and c=b at the end. If you write the same thing into a sequential statement : entity... end... architecture... ... begin ... process (...) wait ...; a <= b; c <= a; end process; ... end; At the end, you have only 3 "shared" variables a,b and c, and in a=b and c=? at the end. In realty, c keep the value of a before the execution of the process. To be more practical, all the manipulation done in the article are caduc . Because, if you parallized your execution, you couldn't predict the execution time of the instruction. It's why we need add some synchronization construct to ensure the behaviour in vhdl. At last, Juergen spoke about fpga netlist. To obtain a netlist, you need reduce the set of vhdl code (this subset is known like the rtl - Register Transfert Level - vhdl, and it normalization is in progress, under name ieee-1076.6) and some of the major restrictions are no file access, no string/char support. If someone need more informations about vhdl or want discuss on the subject, we can begin a new thread or I can send him some links on the subject. See Ya, Just an Illusion Juergen Goeritz wrote: >Hi! > >this is indeed a very, very convincing idea! Provide the >'fitter' for the processor with the processor. YESSS! > > >It would be similar to todays FPGAs tool chains! >You can use a 'global tool' like synplicity or whatever >and run the device fitter from the vendor to create >fpga netlist. > > >Now you take gcc (or the ones for ada, f, pas and so on) >and run the f-cpu optimization fitter as a second step. >And I would love to see the optimization procedure as a >part of the loader... >Then there were the chance for portability at maxperf. >And you wouldn't have to worry about f-cpu type during >compilation... > >And the hardware guys must think about how software is >to be optimized - what amount of synergy effects :-) > >And finally I don't see problems using gcc as a frontend >tool only. > >JG > >On Sat, 20 Apr 2002, Yann Guidon wrote: > >>>if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-) >>> >>i can't even count on myself. >> >>-------------------------------------------------------------------- >>However i had an idea during a private discussion with Cedric... >>He probably won't like that i speak again about it, but i like >>this idea because it is a good compromise : efficient and realistic. >> >>The idea is to use GCC and give a very simplistic machine description. >>So we won't have to mess with GCC's internals and problems. >>GCC will output assembly langage for our simplistic machine >>(63 registers + 0, post-incrememnted-only addressing, direct register jump etc.) >>but all the "dirty optimisation work" will be done before assembly. >>The GCC code would be translated to real instructions and some global analysis >>will be done, for example for computing optimal pointer increments and prefetching >>the jump destinations well in advance... so GCC won't care and F-CPU specific stuff >>will be kept separate. >> >>This is the >> easiest solution which allows everybody to use most existing sources, >>not having tough problems with GCC and create our own optimisation techniques. >>We can start with a "dumb assembler" with a 1-to-1 translation, and add optimisations >>progressively. >>-------------------------------------------------------------------- >> >>at least, it's a better effort than doing our own compiler from scratch, no ? >> >>WHYGEE >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>************************************************************* >>To unsubscribe, send an e-mail to majordomo@seul.org with >>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > --------------020005030101010900090706 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Scriiiitch ! Oups ! Danger, danger...

Hello everybody,

Sorry to add some comments only today but I have 269 mails left (i haven't yet finish to read all attached comments).

I have begin to read this thread and I thinks some peoples seems not known the vhdl, because if you need programming some application with vhdl, good luck.

Let's explain me.

First I well known vhdl (i am a hardware man, then thanks for the compliments).

Second, some history : vhdl is the abbreviation of Vhsic High-level Design Language, or Vlsi High-level Description Language (this is an academic fight about the D abbreviation); vhsic is itself the abbreviation for Very High Scale Integrated Circuit. This language have been firstly normalized in 1989, and have been modified only 2 time since (in 1993 and in 1998) under the reference ieee-1076.
This language have been originally done to create some behavioral description of hardware to be able to make some design simulations.
Yes, it has been developped in ada (and it has kept its limitations), but he hasn't all the feature of a programming language.

If some one need create a program in vhdl, he must forget the sequential programming, he must think parallel execution programming, clock synchronism and sampling.
In vhdl, you have two types of process the concurrential and the sequential (but not exactly same sequential than C execution).

The code inside the sequential structure is executed in order of writing, but the "shared" variables (the name is not totally appropriated) are updated for the other process only at the end of  the execution.
All concurrential process are executed in parallel.

By example, if in C you write :

main () {
...
a=b;
c=a;
...
}
You have 3 "shared" variables a, b, c and in memory a=b and c=a at the end

In vhdl, the syntax change (of course), but if you put your code like a concurrential statement :

entity...
end...
architecture...
...
begin
...
a <= b;
c <= a;
...
end;

At the end, you have only 2 "shared" variables b and c, and c=b at the end.

If you write the same thing into a sequential statement :
entity...
end...
architecture...
...
begin
...
process (...)
    wait ...;
    a <= b;
    c <= a;
end process;
...
end;

At the end, you have only 3 "shared" variables a,b and c, and in a=b  and c=? at the end. In realty, c keep the value of a before the execution of the process.



To be more practical, all the manipulation done in the article are caduc . Because, if you parallized your execution, you couldn't predict the execution time of the instruction. It's why we need add some synchronization construct to ensure the behaviour in vhdl.

At last,  Juergen spoke about fpga netlist. To obtain a netlist, you need reduce the set of vhdl code (this subset is known like the rtl - Register Transfert Level - vhdl, and it normalization is in progress, under name ieee-1076.6) and some of the major restrictions are no file access, no string/char support.

If someone need more informations about vhdl or want discuss on the subject, we can begin a new thread or I can send him some links on the subject.

See Ya,
Just an Illusion

Juergen Goeritz wrote:
Hi!

this is indeed a very, very  convincing idea! Provide the
'fitter' for the processor with the processor. YESSS!

<compare to vhdl>
It would be similar to todays FPGAs tool chains!
You can use a 'global tool' like synplicity or whatever
and run the device fitter from the vendor to create
fpga netlist.
</compare to vhdl>

Now you take gcc (or the ones for ada, f, pas and so on)
and run the f-cpu optimization fitter as a second step.
And I would love to see the optimization procedure as a
part of the loader...
Then there were the chance for portability at maxperf.
And you wouldn't have to worry about f-cpu type during
compilation...

And the hardware guys must think about how software is
to be optimized - what amount of synergy effects :-) 

And finally I don't see problems using gcc as a frontend
tool only.

JG

On Sat, 20 Apr 2002, Yann Guidon wrote:
if *we* don't promote new langages, we won't be able to count on Intel to do it ! :-)
i can't even count on myself.

--------------------------------------------------------------------
However i had an idea during a private discussion with Cedric...
He probably won't like that i speak again about it, but i like
this idea because it is a good compromise : efficient and realistic.

The idea is to use GCC and give a very simplistic machine description.
So we won't have to mess with GCC's internals and problems.
GCC will output assembly langage for our simplistic machine
(63 registers + 0, post-incrememnted-only addressing, direct register jump etc.)
but all the "dirty optimisation work" will be done before assembly.
The GCC code would be translated to real instructions and some global analysis
will be done, for example for computing optimal pointer increments and prefetching
the jump destinations well in advance... so GCC won't care and F-CPU specific stuff
will be kept separate.

This is the

 easiest solution which allows everybody to use most existing sources,
not having tough problems with GCC and create our own optimisation techniques.
We can start with a "dumb assembler" with a 1-to-1 translation, and add optimisations
progressively.
--------------------------------------------------------------------

at least, it's a better effort than doing our own compiler from scratch, no ?

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/



--------------020005030101010900090706-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Apr 23 10:34:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yz-0002mi-00 for ; Tue, 23 Apr 2002 22:06:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:57 +0200 (CEST) Received: (qmail 15269 invoked by uid 0); 23 Apr 2002 08:36:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 23 Apr 2002 08:36:56 -0000 Received: by moria.seul.org (Postfix) id 09640146972; Tue, 23 Apr 2002 04:36:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 070DE146971; Tue, 23 Apr 2002 04:36:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id D34C814696F for ; Tue, 23 Apr 2002 04:36:54 -0400 (EDT) Received: (qmail 62237 invoked by uid 85); 23 Apr 2002 08:37:11 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.405572 secs); 23 Apr 2002 08:37:11 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 23 Apr 2002 08:37:10 -0000 Message-ID: <3CC51C85.5090708@yahoo.fr> Date: Tue, 23 Apr 2002 10:34:13 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Some answer References: <3CC2DCD1.56FFDC3C@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N (No more than 246 mails left ;-P) nico wrote: >Argh ! 92 messages ! > >Define a generic representation of code to write different compiler are >very hard. The big example is why gcc couldn't produice an output in >java byte code. JVM are simply a "virtual processor", so it will be nice >that gcc could compile for this target. But it's a stack machine not a >register based one. And the semantic of the intermediate representation >are too poor to be used. > >Our register set is definitely 3r 2W, i don't like it too much for >performance reason but why using it better. One off the main problem are >exepntion handler. Couldn't it be possible to use the second register to >output the state without traping (imagine the DIV instruction, the >second register will say if a div by zero occur or an overflow >occur,...). If the system need a trap an instruction should verify the >regiter otherwise it could do nothing. What do you think of it ? > >For the floating point unit, we should provid 128 bits extended floating >point precision for the day of the register set will double. > >What about written a asm optimiser which could be used as backend for >every different language compiler ? > >VHDL could never be used to write SW. It's too poor ! IO fonction are >too poor. > I'm agree, i'm agree...too >Nowdays HW world try to find an other way to code to a higher >level. SystemC are the best canditate (C++ + a lib), but there is other >proposal (VHDL-OO, UML-RT, new langage...) > But I am not sure than SystemC is really the *new* hw system level description language (too early to know), it have some initiative but nothing is clear. > > >read you soon ! > >nicO >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > I'll continue my reading. Just an Illusion ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Apr 22 22:23:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Yz-0002mi-01 for ; Tue, 23 Apr 2002 22:06:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:57 +0200 (CEST) Received: (qmail 5969 invoked by uid 0); 23 Apr 2002 08:37:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 23 Apr 2002 08:37:53 -0000 Received: by moria.seul.org (Postfix) id A20B5146973; Tue, 23 Apr 2002 04:37:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FBA3146971; Tue, 23 Apr 2002 04:37:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 1455314696F for ; Tue, 23 Apr 2002 04:37:51 -0400 (EDT) Received: (qmail 62276 invoked by uid 85); 23 Apr 2002 08:38:07 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.158508 secs); 23 Apr 2002 08:38:07 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 23 Apr 2002 08:38:07 -0000 Message-ID: <3CC4713B.7080705@yahoo.fr> Date: Mon, 22 Apr 2002 22:23:23 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <3CBFA8B0.9462D1DF@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have find this articles interesting, but only one remarks the well known "MPEG3" is the 3rd feature of MPEG-1 (and not MPEG-2, official identification MPEG-1.3), isn't it ? I'll can try to check it and find you the "official" standard number. Just an Illusion Yann Guidon wrote: >hello, > >for convenience (and also attracting people with search engines ;-P) >i have unpacked my paper at http://f-cpu.seul.org/whygee/dct_fc0/dct_fc0.html >so it's available for online reading. > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Apr 23 00:32:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Z0-0002mi-00 for ; Tue, 23 Apr 2002 22:06:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:06:58 +0200 (CEST) Received: (qmail 4147 invoked by uid 0); 23 Apr 2002 08:37:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 23 Apr 2002 08:37:55 -0000 Received: by moria.seul.org (Postfix) id 01BFC146974; Tue, 23 Apr 2002 04:37:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1F53146971; Tue, 23 Apr 2002 04:37:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 43A36146970 for ; Tue, 23 Apr 2002 04:37:54 -0400 (EDT) Received: (qmail 62291 invoked by uid 85); 23 Apr 2002 08:38:10 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 2.220161 secs); 23 Apr 2002 08:38:10 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 23 Apr 2002 08:38:08 -0000 Message-ID: <3CC48F61.30907@yahoo.fr> Date: Tue, 23 Apr 2002 00:32:01 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Some answer References: <3CC2DCD1.56FFDC3C@ifrance.com> <3CC31DBD.EB4EB775@f-cpu.org> Content-Type: multipart/alternative; boundary="------------010101010808040901010100" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------010101010808040901010100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yann Guidon wrote: >hi ! > >nico wrote: > >>Argh ! 92 messages ! >> >this list is very "cyclotimic" :-) > Nico need only read 92, but me it's 245 now (what you want, Doc Geek refuse to my questionnary answers because I have a social life ;-) then I couldn't read every days my mails). > >>Define a generic representation of code to write different compiler are >>very hard. The big example is why gcc couldn't produice an output in >>java byte code. JVM are simply a "virtual processor", so it will be nice >>that gcc could compile for this target. But it's a stack machine not a >>register based one. And the semantic of the intermediate representation >>are too poor to be used. >> > >Add to that other parameters, such as the programmer's tastes >(we have a good sample of different opinions in this list) >and some corporate pressures, and the panorama becomes even more fuzzy. > >but don't forget that the goal of the project is to make the best CPU >possible, that's all ;-) > >>Our register set is definitely 3r 2W, i don't like it too much for >>performance reason but why using it better. One off the main problem are >>exepntion handler. Couldn't it be possible to use the second register to >>output the state without traping (imagine the DIV instruction, the >>second register will say if a div by zero occur or an overflow >>occur,...). If the system need a trap an instruction should verify the >>regiter otherwise it could do nothing. What do you think of it ? >> > >i am not sure to understand what you write... > >for IDIV the instruction is "issued" if the zero flags are not set. >it's already in the manual i think. it doesn't use the usual register >read ports but the attribute bits. > >for the rest, i don't clearly understand. Maybe if you write in french... > >>For the floating point unit, we should provid 128 bits extended floating >>point precision for the day of the register set will double. >> >if you want to implement it... go ahead... but this has been discussed >earlier, it's not necessary or useful. > >>What about written a asm optimiser which could be used as backend for >>every different language compiler ? >> > >we're discussing something like that now. > >>VHDL could never be used to write SW. It's too poor ! IO fonction are too poor. >> >VHDL is only the core of the thing. There are the std-XXXX libraries >and the effort for adding POSIX I/O. >But if i want to use a VHDL-like programming langage, i will no doubt correct >some of the little problems it has. i'm not masochist ;-) > I hope :-P > > >>Nowdays HW world try to find an other way to code to a higher >>level. SystemC are the best canditate (C++ + a lib), >> >i think it's funny : C is lower-level than VHDL (ADA), and people want >it to be higher level than VHDL. i think that a few (only, but anyway) >people of this list laugh :-) > Perhaps for sw guys, but not for hw world the low level is the transistor then the asm is yet a high level language. > >>but there is other proposal (VHDL-OO, UML-RT, new langage...) >> >we know that System-C or something like that will emerge. >unfortunately, the companies that promote them are bad at planning for the very long term. > >>read you soon ! >> >ans see you if you have time ! > >>nicO >> >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > --------------010101010808040901010100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Yann Guidon wrote:
hi !

nico wrote:
Argh ! 92 messages !
this list is very "cyclotimic" :-)
Nico need only read 92, but me it's 245 now (what you want, Doc Geek refuse to my questionnary answers because I have a social life ;-) then I couldn't read every days my mails).

Define a generic representation of code to write different compiler are
very hard. The big example is why gcc couldn't produice an output in
java byte code. JVM are simply a "virtual processor", so it will be nice
that gcc could compile for this target. But it's a stack machine not a
register based one. And the semantic of the intermediate representation
are too poor to be used.

Add to that other parameters, such as the programmer's tastes
(we have a good sample of different opinions in this list)
and some corporate pressures, and the panorama becomes even more fuzzy.

but don't forget that the goal of the project is to make the best CPU
possible, that's all ;-)

Our register set is definitely 3r 2W, i don't like it too much for
performance reason but why using it better. One off the main problem are
exepntion handler. Couldn't it be possible to use the second register to
output the state without traping (imagine the DIV instruction, the
second register will say if a div by zero occur or an overflow
occur,...). If the system need a trap an instruction should verify the
regiter otherwise it could do nothing. What do you think of it ?

i am not sure to understand what you write...

for IDIV the instruction is "issued" if the zero flags are not set.
it's already in the manual i think. it doesn't use the usual register
read ports but the attribute bits.

for the rest, i don't clearly understand. Maybe if you write in french...

For the floating point unit, we should provid 128 bits extended floating
point precision for the day of the register set will double.
if you want to implement it... go ahead... but this has been discussed
earlier, it's not necessary or useful.

What about written a asm optimiser which could be used as backend for
every different language compiler ?

we're discussing something like that now.

VHDL could never be used to write SW. It's too poor !  IO fonction are too poor.
VHDL is only the core of the thing. There are the std-XXXX libraries
and the effort for adding POSIX I/O.
But if i want to use a VHDL-like programming langage, i will no doubt correct
some of the little problems it has. i'm not masochist ;-)
I hope :-P



Nowdays HW world try to find an other way to code to a higher
level. SystemC are the best canditate (C++ + a lib),
i think it's funny : C is lower-level than VHDL (ADA), and people want
it to be higher level than VHDL. i think that a few (only, but anyway)
people of this list laugh :-)
Perhaps for sw guys, but not for hw world the low level is the transistor then the asm is yet a high level language.

but there is other proposal (VHDL-OO, UML-RT, new langage...)
we know that System-C or something like that will emerge.
unfortunately, the companies that promote them are bad at planning for the very long term.

read you soon !
ans see you if you have time !

nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


--------------010101010808040901010100-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Apr 23 00:55:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Z2-0002mi-00 for ; Tue, 23 Apr 2002 22:07:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:07:00 +0200 (CEST) Received: (qmail 25977 invoked by uid 0); 23 Apr 2002 08:38:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 23 Apr 2002 08:38:03 -0000 Received: by moria.seul.org (Postfix) id 4E80E146970; Tue, 23 Apr 2002 04:37:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4796E146975; Tue, 23 Apr 2002 04:37:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 6183B146970 for ; Tue, 23 Apr 2002 04:37:57 -0400 (EDT) Received: (qmail 62306 invoked by uid 85); 23 Apr 2002 08:38:13 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 2.315378 secs); 23 Apr 2002 08:38:13 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.100) by menator with SMTP; 23 Apr 2002 08:38:11 -0000 Message-ID: <3CC494FB.8020400@yahoo.fr> Date: Tue, 23 Apr 2002 00:55:55 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] F-CPU vs. Itanium References: <200204220832.3229@th00.opsion.fr> Content-Type: multipart/alternative; boundary="------------040404090208070006070408" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------040404090208070006070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Nicolas Boulay wrote: >-----Message d'origine----- >De: Martin Devera >A: f-cpu@seul.org >Date: 22/04/02 >Objet: Re: [f-cpu] F-CPU vs. Itanium > >>It makes the same problem as a plain C simulator : we already have to >> >deal with > >>a VHDL source tree and there are too few contributors yet. we can't >> >hire > >>anybody, you know : it's all volunteer work. when work is done. >> > >true .. The biggest problem I see: is there any free tool to use >for simulation cpu (or other logic) in VHDL ? If not it too hard >to write one ? >I ask because when I developed first version of advanced packet >scheduler >I did it in userspace - I was able to quickly evaluate speed and has >been >forced to rethink/rewrite whole agorithm three times (the complexity >analyse is almost impossible there) - it saved a lot of time - then >I implemented it once in kernel space (which is a bit harder/slower). >I was thinking about emulator where all ideas can be quickly evaluated >million times before you start coding actual logic. >And if there would be single tool used by all participants I think that >some ideas could be tested very fast. > >>>>That's where goes the big design. They called that architecture >>>> >exploration. Industry try to introduice many tools to create a flow from >the spec to the GDS II files. >System C are design to do such research. The idea is to "refine" your >design with VHDL like concept. BUT you could begin dirty C++ if you >want. That's where you could save time. > >>slow if we can't access full-custom technologies (like Intel and IBM >> >do). > >>Beyond, another strategy must be used. >> > >I'm not experianced here, what is difference between ASIC and full >custom ? ASIC can use only predefined blocks ? > A full-custom is generally implemented into an ASIC, but an ASIC can be not a full-custom. The ASIC term cover some other concepts. The main point to remember is than ASIC is a specific-application oriented design chip. In example, you couldn't implement into a FPGA a asynchronous design (because the FPGA have a main synchronous clock input, which drive all internal sequential cells), to do it you need an ASIC (because you implement as much clock as you like to drive the sequential cells). The cpu can be generally attach to the ASIC familly. > >>>>ASIC are a generic name. Most (99%) of the design use semi-custom >>>> >design. In fact, the design is an interconnection of soon defined cells >(AND/OR gate, register,...). Most of the time they define memory bloc, >too. But this kind of block have 2 ports, very few times more. > >>>>So you need full custom design where you could design you're one >>>> >memory block. But it's far more expensive for a compagny to do it. Most >of the time only foundries do it (IBM, ST, TSMC,...). > >>>>The third kind of ASIC called 'precaractérisé' in french are a kind >>>> >of FPGA, only the 2 or 4 last metal layer are define by the designer. >That's the chipest technology. > >>>university did it but they have working 3 ported 32x31 register set >>>operating at 16GHz with only 20W of thermal loss. >>> >>"only" ?... >> > >hmm not too low abs. number ;) But they computed 16GHz in cmos would >have >much more .. Also they claim that with higher integration this number >will decrease and in cmos it increases .. > >>>>??? 20 W for a register bank is hudge ! In 400 Mhz only 7W is needed >>>> >for the whole mutiplier unit (0.18 µm). >nicO > > >devik > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > >______________________________________________________________________________ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > --------------040404090208070006070408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Nicolas Boulay wrote:
-----Message d'origine-----
De: Martin Devera <devik@cdi.cz>
A: f-cpu@seul.org
Date: 22/04/02
Objet: Re: [f-cpu] F-CPU vs. Itanium

It makes the same problem as a plain C simulator : we already have to
deal with
a VHDL source tree and there are too few contributors yet. we can't
hire
anybody, you know : it's all volunteer work. when work is done.

true .. The biggest problem I see: is there any free tool to use
for simulation cpu (or other logic) in VHDL ? If not it too hard
to write one ?
I ask because when I developed first version of advanced packet
scheduler
I did it in userspace - I was able to quickly evaluate speed and has
been
forced to rethink/rewrite whole agorithm three times (the complexity
analyse is almost impossible there) - it saved a lot of time - then
I implemented it once in kernel space (which is a bit harder/slower).
I was thinking about emulator where all ideas can be quickly evaluated
million times before you start coding actual logic.
And if there would be single tool used by all participants I think that
some ideas could be tested very fast.

That's where goes the big design. They called that architecture
exploration. Industry try to introduice many tools to create a flow from
the spec to the GDS II files.
System C are design to do such research. The idea is to "refine" your
design with VHDL like concept. BUT you could begin dirty C++ if you
want. That's where you could save time.

slow if we can't access full-custom technologies (like Intel and IBM
do).
Beyond, another strategy must be used.

I'm not experianced here, what is difference between ASIC and full
custom ? ASIC can use only predefined blocks ?
A full-custom is generally implemented into an ASIC, but an ASIC can be not a full-custom.

The ASIC term cover some other concepts. The main point to remember  is than ASIC is a specific-application oriented design chip. In example, you couldn't implement into a FPGA a asynchronous design (because the FPGA have a main synchronous clock input, which drive all internal sequential cells), to do it you need an ASIC (because you implement as much clock as you like to drive the sequential cells). The cpu can be generally attach to the ASIC familly.

ASIC are a generic name. Most (99%) of the design use semi-custom
design. In fact, the design is an interconnection of soon defined cells
(AND/OR gate, register,...). Most of the time they define memory bloc,
too. But this kind of block have 2 ports, very few times more.

So you need full custom design where you could design you're one
memory block. But it's far more expensive for a compagny to do it. Most
of the time only foundries do it (IBM, ST, TSMC,...).

The third kind of ASIC called 'precaractérisé' in french are a kind
of FPGA, only the 2 or 4 last metal layer are define by the designer.
That's the chipest technology.

university did it but they have working 3 ported 32x31 register set
operating at 16GHz with only 20W of thermal loss.
"only" ?...

hmm not too low abs. number ;) But they computed 16GHz in cmos would
have
much more .. Also they claim that with higher integration this number
will decrease and in cmos it increases ..

??? 20 W for a register bank is hudge ! In 400 Mhz only 7W is needed
for the whole mutiplier unit (0.18 µm).
nicO


devik

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


--------------040404090208070006070408-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Apr 23 10:47:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Z5-0002mi-00 for ; Tue, 23 Apr 2002 22:07:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:07:03 +0200 (CEST) Received: (qmail 12658 invoked by uid 0); 23 Apr 2002 08:47:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Apr 2002 08:47:45 -0000 Received: by moria.seul.org (Postfix) id 4DA2914696F; Tue, 23 Apr 2002 04:47:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 49658146975; Tue, 23 Apr 2002 04:47:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E3A4B14696F for ; Tue, 23 Apr 2002 04:47:43 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 16zvxe-0005aQ-00 for f-cpu@seul.org; Tue, 23 Apr 2002 10:47:42 +0200 Date: Tue, 23 Apr 2002 10:47:42 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium (HBT technology) In-Reply-To: <3CC46DD9.555475EB@ifrance.com> Message-ID: References: <200204220832.3229@th00.opsion.fr> <20020422122738.04521@thrai.stud.uni-hannover.de> <3CC46DD9.555475EB@ifrance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > [...] > > > >>> ??? 20 W for a register bank is hudge ! In 400 Mhz only 7W is nee= ded > > > for the whole mutiplier unit (0.18 =B5m). > > > > You overlooked the clock frequency of *16* GHz. > > Yep maybe, it's 32 times more for 32*31=3D992 memory point. To be Compare > to you're design that use packet of 4096 flip-flop banck ! ;p Well I can't find the original site I read about 16G from. But there are some links to authors' work: http://www.darpa.mil/ito/research/netex/presentations/McDonald-RPI.pdf and here is info about older (3GHz) version of the chip. It discipates 5W of energy - so that 20W for 16G might be my mistake because they said that energy discipation increases slower than linarly when making HBT smaller and clock higher. http://www.isscc.org/digests/1999/DATA/11_3.pdf regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Apr 23 11:21:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706Z6-0002mi-00 for ; Tue, 23 Apr 2002 22:07:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:07:04 +0200 (CEST) Received: (qmail 16566 invoked by uid 0); 23 Apr 2002 09:38:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 23 Apr 2002 09:38:19 -0000 Received: by moria.seul.org (Postfix) id 97E34146971; Tue, 23 Apr 2002 05:38:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84EBF146976; Tue, 23 Apr 2002 05:38:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 40FB9146971 for ; Tue, 23 Apr 2002 05:38:15 -0400 (EDT) Received: from ifurita (212.194.245.237) by mail.laposte.net (5.5.044) id 3CC4088200013EE1 for f-cpu@seul.org; Tue, 23 Apr 2002 11:38:14 +0200 Message-ID: <008d01c1eaa8$3d401620$edf5c2d4@ifurita> From: "Christophe" To: References: <3CC47EE7.99C10F50@f-cpu.org> <20020423003350.64125@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] F-CPU vs. Itanium Date: Tue, 23 Apr 2002 11:21:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N That's true. 'ex' instructions ;) ----- Original Message ----- From: Michael Riepe To: Sent: Tuesday, April 23, 2002 12:33 AM Subject: Re: [f-cpu] F-CPU vs. Itanium > On Mon, Apr 22, 2002 at 11:21:43PM +0200, Yann Guidon wrote: > [...] > > > i860 was the floating point vector processor, i960 is the embedded > > > RISC processor (both Intel). > > > > i don't remember which, but one (or maybe both, i don't know) > > has a mechanism for fast register set swapping. Some other > > CPUs probably have something similar. > > Zilog Z80 ;) > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 23 12:37:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706ZC-0002mi-00 for ; Tue, 23 Apr 2002 22:07:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:07:10 +0200 (CEST) Received: (qmail 27650 invoked by uid 0); 23 Apr 2002 10:30:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Apr 2002 10:30:55 -0000 Received: by moria.seul.org (Postfix) id 25C71146976; Tue, 23 Apr 2002 06:30:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A84E146978; Tue, 23 Apr 2002 06:30:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id D2DE3146976 for ; Tue, 23 Apr 2002 06:30:54 -0400 (EDT) Received: from f-cpu.org (kdl11-82.n.club-internet.fr [213.44.9.82]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 356ED1749 for ; Tue, 23 Apr 2002 12:30:52 +0200 (CEST) Message-ID: <3CC5396D.5F04DF66@f-cpu.org> Date: Tue, 23 Apr 2002 12:37:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU vs. Itanium References: <3CC47EE7.99C10F50@f-cpu.org> <20020423003350.64125@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > > On Mon, Apr 22, 2002 at 11:21:43PM +0200, Yann Guidon wrote: > [...] > > > i860 was the floating point vector processor, i960 is the embedded > > > RISC processor (both Intel). > > > > i don't remember which, but one (or maybe both, i don't know) > > has a mechanism for fast register set swapping. Some other > > CPUs probably have something similar. > > Zilog Z80 ;) i was checking my mailbox (ouch ! 74 more mails ! F-CPU + LFS = no social life) and this remark makes me laugh so much that i can't sleep. Thanks Michael :-D > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Apr 23 15:10:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1706ZK-0002mi-01 for ; Tue, 23 Apr 2002 22:07:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 23 Apr 2002 22:07:18 +0200 (CEST) Received: (qmail 3831 invoked by uid 0); 23 Apr 2002 13:10:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 23 Apr 2002 13:10:19 -0000 Received: by moria.seul.org (Postfix) id 977C9146977; Tue, 23 Apr 2002 09:10:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EB6B146979; Tue, 23 Apr 2002 09:10:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EA02B146977 for ; Tue, 23 Apr 2002 09:10:13 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17003g-0000LI-00 for f-cpu@seul.org; Tue, 23 Apr 2002 15:10:12 +0200 Date: Tue, 23 Apr 2002 15:10:12 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: [f-cpu] 16 GHz and 125.000 MOPS In-Reply-To: <3CC5396D.5F04DF66@f-cpu.org> Message-ID: References: <3CC47EE7.99C10F50@f-cpu.org> <20020423003350.64125@thrai.stud.uni-hannover.de> <3CC5396D.5F04DF66@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi All, I found these links, see http://inp.cie.rpi.edu/research/mcdonald/frisc/slides/HTMT98/index.htm or http://inp.cie.rpi.edu/research/mcdonald/frisc/index.html nice day, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 03:48:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170APz-0005hS-00 for ; Wed, 24 Apr 2002 02:13:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 24 Apr 2002 02:13:55 +0200 (CEST) Received: (qmail 30960 invoked by uid 0); 23 Apr 2002 19:58:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 23 Apr 2002 19:58:18 -0000 Received: by moria.seul.org (Postfix) id 1A2381468F3; Tue, 23 Apr 2002 15:58:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1932146958; Tue, 23 Apr 2002 15:58:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 8BC1B1468F3 for ; Tue, 23 Apr 2002 15:58:16 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-152-139.dial.proxad.net [62.147.152.139]) by postfix3-2.free.fr (Postfix) with ESMTP id B57B4184F3 for ; Tue, 23 Apr 2002 21:58:10 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Date: Tue, 23 Apr 2002 01:48:40 +0000 X-Mailer: KMail [version 1.4] References: <3CC47EEC.76B750F1@f-cpu.org> In-Reply-To: <3CC47EEC.76B750F1@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230148.40886.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > What i need is a DataFlow Graph analysis tool that allows me to > handle large chuncks of code with all the automated tedious tasks > that i usually do by hand (register allocation, reallocation, > interleaving...) What did you mean by reallocation is i memory operation or register reallocation ? If it's the second, the problem is the same as register allocation, and it exist some good algorithm for risc machine (with a lot of registers), that can do that better than a lot of human ;-) For interleaving, it's, if I correctly understand what you mean scheduling, the problem is not easy, and need a lot of time to have the right answer. But what we can do is detecting where we lost cycle. (It's what I plan to do in my asm). A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Apr 23 14:25:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170AQ0-0005hS-00 for ; Wed, 24 Apr 2002 02:13:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 24 Apr 2002 02:13:56 +0200 (CEST) Received: (qmail 2641 invoked by uid 0); 23 Apr 2002 19:58:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 23 Apr 2002 19:58:24 -0000 Received: by moria.seul.org (Postfix) id 6C984146964; Tue, 23 Apr 2002 15:58:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69EDC146963; Tue, 23 Apr 2002 15:58:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id DDE5C146958 for ; Tue, 23 Apr 2002 15:58:18 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-152-139.dial.proxad.net [62.147.152.139]) by postfix3-2.free.fr (Postfix) with ESMTP id 38F37184B7 for ; Tue, 23 Apr 2002 21:58:16 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update Date: Tue, 23 Apr 2002 14:25:15 +0200 X-Mailer: KMail [version 1.4] References: <200204200337.50475.cedric.bail@free.fr> <3CC12B70.26A34CB9@f-cpu.org> In-Reply-To: <3CC12B70.26A34CB9@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204231425.15570.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Le Samedi 20 Avril 2002 10:48, Yann Guidon a écrit : > "questions pour un champignon" wrote: > > Hi, > > > > I have started to update the manual with the two post that Michael > > give to me, but for certain case it's not really clear. > tell me if something EVER remains clear, ok ? :-P > > First the FPU. Is it SIMD or not ? > at least it should leave this possibility. > The chip can implement it the way it wants (or not), but it is desirable. If I understand, the SIMD capability of the FPU is optional like the FPU himself. That mean that we have more than 3 level of implemented FPU ? > > (problem with exeption and rouding for example, and perhaps a problem of > > size). > rounding ? You want to make separate rounding policies for specific numbers > of a SIMD packet ??? No, I mean what append when we need to trap only because one of the chunk. > > Or is it SIMD hidden into the EU ? > > i don't see what you mean here. It's certainly done like with integer SIMD. > The register set gives a full-width data to the unit and the unit processes > it. Ok, it reply to my question. > > (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? > > date from Wed, 15 Aug 2001 23:12:27 +0200). > > I don't understand the meaning of fexp with a base ? What did > > that mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead > > of flog ? > maybe to avoid confusion with LNS operations. ok, what about fln ? > you seem to have a problem with the base, right ? it is probably because > the algorithm that computes log and exp is specific to a certain base so we > can't specify it directly (a mutliply does the correction before or later). > > About LNS: what are the rounding method (or mode) ? same as FPU ? And did > > we add 16 bits representation (like nicO suggestion ?) ? > > i have not heard about rounding issues with LNS. > Leave that part "highly speculative -> don't bother" now because the legal > issues are not all solved. Ok > > I did'nt understand why did we specify into the CPU a fixed > > memory hierarchichies (see cachemem). > > it was speculative and it's not written in the stone. but in pdf ;-) > > I think that we could say that 0 will be the > > quicker and 7 the slower, or something like that ? And did we add a > > 'cachecode r1' instruction that will perform a prefetch in I-Cache before > > a jmp (in a function call for example like in Michael's C++ sample). > > the cache prefetch is already speculatively performed IIRC. > i don't remember the opcode name, but when you specify a register > with a target, this first computes the address, then checks the > validity and if ok, fetches the code. That's why the prefetch instruction > must be moved far in advance. I don't see this instruction, but the prefetch instruction (you mean cachemem) do is work in D-Cache and not I-Cache, or I miss something. > > And about the storem/loadm, I have update with the new form you > > give (I have read gcc documentation, and it's exactly the called form it > > need, so it will be easy to use for a compiler). > > argh, i don't know if we will even support loadm/storem in the first chip > versions... maybe i shouldn't have spoken about it at all. I have an idea on howto to implement it, I will explain it "au first jeudi". > > But I think that I must remove any > > reference to SRB mechanism, because SRB is done in physical address space > > (no trap) and the storem/loadm must be done in virtual address space > > (trap problem). An other point about this instruction, did we add the 2 > > registers form ? > > i think that we can't solve the whole problem now. Mark this as : > "speculative" Ok. > > We now have a unconditionnal move, but is it a alias for 'movez > > r0, r2, r1' or something else ? > maybe, maybe not. I think that we'll decide if the opcodes alias when the > opcode map will be "compiled" for F-CPU v1. > It can be ok to make separate entries and opcode names, because the opcode > values can be set to identical values later. Ok, It means that all alias remark into the manual must be removed ? > > In the instruction set I have updated bitop[i]. > > IIRC, the original assumptions don't hold anymore, so they also must be > marked as "speculative". Maybe a "real" implementation will "chain" SHL and > ROP2 together, but the critical datapath is already exploded in SHL and > bitop can't fit in a single cycle. Ok. > But NOP must become a new opcode of its own. > The opcode is not defined yet, but the remaining fields must be zero. > I have the intention of giving a new separate semantics to this > "instruction" because it's used more often than we'd think, mainly for > alignment. So the remaining fields can store hint for the alignment etc... Ok > > And I didn't understand the effect of widen new instruction. I > > don't understand if it will take 2 cycles and only replace two separated > > instructions or if it does something more. > > i don't remember this discussions... i should look into my archive... And ? > > I think, that a good start for an update, if I miss something or you want > > to add something, add ;-) > > i think that the 1st part must be shortened : the inclusion of the aug.1998 > document is more misleading than anything. we'll see that when we meet. I agree, but I am currently working on the instruction set. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Apr 23 23:09:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170AQ4-0005hS-01 for ; Wed, 24 Apr 2002 02:14:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 24 Apr 2002 02:14:00 +0200 (CEST) Received: (qmail 20107 invoked by uid 0); 23 Apr 2002 21:57:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 23 Apr 2002 21:57:47 -0000 Received: by moria.seul.org (Postfix) id ED6DB14697E; Tue, 23 Apr 2002 17:57:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E4CF014697B; Tue, 23 Apr 2002 17:57:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id A868714695B for ; Tue, 23 Apr 2002 17:57:46 -0400 (EDT) Received: from ifrance.com (vlt6-123.n.club-internet.fr [194.158.119.123]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 1165D170E for ; Tue, 23 Apr 2002 23:57:44 +0200 (CEST) Message-ID: <3CC5CD88.5CBAC011@ifrance.com> Date: Tue, 23 Apr 2002 23:09:28 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Some question about the update References: <200204200337.50475.cedric.bail@free.fr> <3CC12B70.26A34CB9@f-cpu.org> <200204231425.15570.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric a écrit : > > Le Samedi 20 Avril 2002 10:48, Yann Guidon a écrit : > > "questions pour un champignon" wrote: > > > Hi, > > > > > > I have started to update the manual with the two post that Michael > > > give to me, but for certain case it's not really clear. > > > tell me if something EVER remains clear, ok ? :-P > > > > First the FPU. Is it SIMD or not ? > > > at least it should leave this possibility. > > The chip can implement it the way it wants (or not), but it is desirable. > > If I understand, the SIMD capability of the FPU is optional like the FPU > himself. That mean that we have more than 3 level of implemented FPU ? > I beleive that we have to limit the number of version. I propose : - one light version without one cycle mul integer (a "small" die size version) - one "normal" - the last with fpu Maybe light and normal could have the same ISA. It should be a balance between die size and computing power. Maybe unit could be choose to be smaller for the first one. nicO > A+ > Cedric > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Apr 24 03:48:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8B-0000Dc-00 for ; Thu, 25 Apr 2002 02:29:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:03 +0200 (CEST) Received: (qmail 20877 invoked by uid 0); 24 Apr 2002 01:41:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 24 Apr 2002 01:41:58 -0000 Received: by moria.seul.org (Postfix) id 41086146982; Tue, 23 Apr 2002 21:41:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D8EF14698B; Tue, 23 Apr 2002 21:41:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id AF5D4146982 for ; Tue, 23 Apr 2002 21:41:55 -0400 (EDT) Received: from f-cpu.org (kdl11-9.n.club-internet.fr [213.44.9.9]) by relay-1m.club-internet.fr (Postfix) with ESMTP id A7CFB1681 for ; Wed, 24 Apr 2002 03:41:52 +0200 (CEST) Message-ID: <3CC60EF2.2F6C0F03@f-cpu.org> Date: Wed, 24 Apr 2002 03:48:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account References: <3CC47EEC.76B750F1@f-cpu.org> <200204230148.40886.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! cedric wrote: > > What i need is a DataFlow Graph analysis tool that allows me to > > handle large chuncks of code with all the automated tedious tasks > > that i usually do by hand (register allocation, reallocation, > > interleaving...) > > What did you mean by reallocation is i memory operation or register > reallocation ? If it's the second, the problem is the same as register > allocation, and it exist some good algorithm for risc machine (with a lot of > registers), that can do that better than a lot of human ;-) do you speak about register coloring ? the complexity grows at least O(n^2) with the number of registers. the "manual" algo i use (and which can be automated) is O(n), or linear complexity. give it more registers and it will be even happier (contrarily to register coloring). > For interleaving, it's, if I correctly understand what you mean scheduling, instruction scheduling, to be exact (look at the end of the DCT paper) > the problem is not easy, what i do is straight-forward : it's like taking a string aaaaaaaaaaa and bbbbbbbbbbb and interleaving it : abababababababababababababababab... > and need a lot of time to have the right answer. at least the time to type it ;-) i know that i am probably the only one who understands myself, and it's just of problem of communication from my part. However i wish that my knowledge becomes useful to others. > But what we can do is detecting where we lost cycle. > (It's what I plan to do in my asm). it's like calling the doctor who says : "you're sick" and goes away. writing asm is ok for small code (like the DCT) but not for large code, you need to not have to worry about the representation, only about the function, and asm programming does not make that possible. peephole optimisation might be easier with your tool, but that's all. it doesn't solve the "big problems" which often come from superficial analysis. btw, do you come to the Libre Software Meeting in Bordeaux ? will you present some of our work ? > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Apr 24 13:23:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8I-0000Dc-01 for ; Thu, 25 Apr 2002 02:29:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:10 +0200 (CEST) Received: (qmail 20652 invoked by uid 0); 24 Apr 2002 11:24:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 24 Apr 2002 11:24:31 -0000 Received: by moria.seul.org (Postfix) id EF36F14697B; Wed, 24 Apr 2002 07:24:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CFD314698E; Wed, 24 Apr 2002 07:24:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 8CCC514697B for ; Wed, 24 Apr 2002 07:23:59 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204241123.32f3; Wed, 24 Apr 2002 11:23:50 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] The last killing argument FOR the GPL licence From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Apr 2002 11:23:50 GMT Message-id: <200204241123.32f3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just disover one very important point for us inside the GP= L FAQ. http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControll= edInterface --- How can I allow linking of proprietary modules with my GPL-c= overed library under a controlled interface only? Add this text to the license notice of each file in the pack= age, at the end of the text that says the file is distributed under the = GNU GPL:=20 Linking FOO statically or dynamically with other modules= is making a combined work based on FOO. Thus, the terms and conditions = of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of FOO giv= e you permission to link FOO with independent modules that communi= cate with FOO solely through the FOOBAR interface, regardless of the l= icense terms of these independent modules, and to copy and distribute the= resulting combined work under terms of your choice, provided that eve= ry copy of the combined work is accompanied by a complete copy of the s= ource code of FOO (the version of FOO used to produce the combined work= ), being distributed under the terms of the GNU General Public Licens= e plus this exception. An independent module is a module which is not d= erived from or based on FOO. Note that people who make modified versions of FOO are n= ot obligated to grant this special exception for their modified versions;= it is their choice whether to do so. The GNU General Public License giv= es permission to release a modified version without this except= ion; this exception also makes it possible to release a modified versi= on which carries forward this exception. --- So this interface could be the bus interface to the outside = only (the internal bus of the chip, the wishbone ?). nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Apr 24 16:32:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8d-0000Dc-00 for ; Thu, 25 Apr 2002 02:29:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:31 +0200 (CEST) Received: (qmail 29342 invoked by uid 0); 24 Apr 2002 14:25:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 24 Apr 2002 14:25:56 -0000 Received: by moria.seul.org (Postfix) id 7E1CE14699A; Wed, 24 Apr 2002 10:25:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73B0614699C; Wed, 24 Apr 2002 10:25:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 2B38D14699A for ; Wed, 24 Apr 2002 10:25:55 -0400 (EDT) Received: from f-cpu.org (kdl11-204.n.club-internet.fr [213.44.9.204]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 50C651975 for ; Wed, 24 Apr 2002 16:25:51 +0200 (CEST) Message-ID: <3CC6C202.1316207@f-cpu.org> Date: Wed, 24 Apr 2002 16:32:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241123.32f3@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > > I just disover one very important point for us inside the GPL FAQ. > > http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControlledInterface > --- > How can I allow linking of proprietary modules with my GPL-covered > library under a controlled interface only? > Add this text to the license notice of each file in the package, at the > end of the text that says the file is distributed under the GNU GPL: > > Linking FOO statically or dynamically with other modules is making a > combined work based on FOO. Thus, the terms and conditions of the GNU > General Public License cover the whole combination. > --- > > So this interface could be the bus interface to the outside only (the > internal bus of the chip, the wishbone ?). Whenever i can, i'll release a proposal version for a "F-CPU license". Neither GPL or LGPL seem to satisfy me. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Apr 24 17:27:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8f-0000Dc-00 for ; Thu, 25 Apr 2002 02:29:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:33 +0200 (CEST) Received: (qmail 11059 invoked by uid 0); 24 Apr 2002 15:27:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 24 Apr 2002 15:27:43 -0000 Received: by moria.seul.org (Postfix) id 1C791146997; Wed, 24 Apr 2002 11:27:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 066EA1469A0; Wed, 24 Apr 2002 11:27:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 3089E146997 for ; Wed, 24 Apr 2002 11:27:41 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200204241527.1b6c; Wed, 24 Apr 2002 15:27:27 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Apr 2002 15:27:27 GMT Message-id: <200204241527.1b6c@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N What the opinion of others ? GPL are really well written by lawyer, and it will be hard t= o be carefull of many different legal point ina new licence. Before writing something, it could be nice to have a list of= feature not present inside the GPL. nicO -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 24/04/02 Objet: Re: [f-cpu] The last killing argument FOR the GPL lic= ence hi, Nicolas Boulay wrote: >=20 > I just disover one very important point for us inside the = GPL FAQ. >=20 > http://www.fsf.org/licenses/gpl-faq.html#LinkingOverControll= edInterface > --- > How can I allow linking of proprietary modules with my GPL= -covered > library under a controlled interface only? > Add this text to the license notice of each file in the pa= ckage, at the > end of the text that says the file is distributed under th= e GNU GPL: >=20 > Linking FOO statically or dynamically with other modul= es is making a > combined work based on FOO. Thus, the terms and condition= s of the GNU > General Public License cover the whole combination. =20 > --- >=20 > So this interface could be the bus interface to the outsid= e only (the > internal bus of the chip, the wishbone ?). Whenever i can, i'll release a proposal version for a "F-CPU= license". Neither GPL or LGPL seem to satisfy me. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Apr 25 02:00:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8n-0000Dc-01 for ; Thu, 25 Apr 2002 02:29:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:41 +0200 (CEST) Received: (qmail 7572 invoked by uid 0); 24 Apr 2002 20:01:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 24 Apr 2002 20:01:05 -0000 Received: by moria.seul.org (Postfix) id 3A0AB1469A6; Wed, 24 Apr 2002 16:01:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 230261469A9; Wed, 24 Apr 2002 16:01:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id A85E51469A6 for ; Wed, 24 Apr 2002 16:01:03 -0400 (EDT) Received: from tholana (nas-cbv-11-62-147-118-250.dial.proxad.net [62.147.118.250]) by postfix3-2.free.fr (Postfix) with ESMTP id 1134F18506 for ; Wed, 24 Apr 2002 22:01:01 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Date: Thu, 25 Apr 2002 00:00:26 +0000 X-Mailer: KMail [version 1.4] References: <200204230148.40886.cedric.bail@free.fr> <3CC60EF2.2F6C0F03@f-cpu.org> In-Reply-To: <3CC60EF2.2F6C0F03@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204250000.26088.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > hi ! > cedric wrote: > > > What i need is a DataFlow Graph analysis tool that allows me to > > > handle large chuncks of code with all the automated tedious tasks > > > that i usually do by hand (register allocation, reallocation, > > > interleaving...) > > > > What did you mean by reallocation is i memory operation or register > > reallocation ? If it's the second, the problem is the same as register > > allocation, and it exist some good algorithm for risc machine (with a lot > > of registers), that can do that better than a lot of human ;-) > > do you speak about register coloring ? the complexity grows at least O(n^2) > with the number of registers. the "manual" algo i use (and which can be > automated) is O(n), or linear complexity. give it more registers and it > will be even happier (contrarily to register coloring). Well, a lot of people will be interested by your algorithm I think, you will explain it to me "au first jeudi" ? > > For interleaving, it's, if I correctly understand what you mean > > scheduling, > instruction scheduling, to be exact (look at the end of the DCT paper) > > the problem is not easy, > what i do is straight-forward : it's like taking a string aaaaaaaaaaa and > bbbbbbbbbbb and interleaving it : abababababababababababababababab... I think that gcc can do that well, it's not very difficult, the solution is when you have 2 operations that are dependent, you must maximise the distance between them. That's all, I think ? I know that perhaps not always the best solution, but it good enough. > > and need a lot of time to have the right answer. > at least the time to type it ;-) So it's not so difficult ;-) > i know that i am probably the only one who understands myself, and it's > just of problem of communication from my part. However i wish that > my knowledge becomes useful to others. > > But what we can do is detecting where we lost cycle. > > (It's what I plan to do in my asm). > it's like calling the doctor who says : "you're sick" and goes away. Exactly, but actually the human are better than our algorithm, no ? > writing asm is ok for small code (like the DCT) but not for large code, > you need to not have to worry about the representation, only about the > function, and asm programming does not make that possible. > peephole optimisation might be easier with your tool, but that's all. > it doesn't solve the "big problems" which often come from superficial > analysis. And algorithm, but you know actually developper brain is too expensive, so you need a good optimisation but it must be done quickly and without the need of learning a new tool or language. > btw, do you come to the Libre Software Meeting in Bordeaux ? > will you present some of our work ? Yes of course, I have some problem with my pop at epita, so if some discussion append on it, I can't know them. But we will meet us at the "first jeudi" ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 24 11:59:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8s-0000Dc-00 for ; Thu, 25 Apr 2002 02:29:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:46 +0200 (CEST) Received: (qmail 32081 invoked by uid 0); 24 Apr 2002 21:59:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 24 Apr 2002 21:59:52 -0000 Received: by moria.seul.org (Postfix) id 5D51A1469AE; Wed, 24 Apr 2002 17:59:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3FECE1469B0; Wed, 24 Apr 2002 17:59:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a095.home.uni-hannover.de [130.75.232.95]) by moria.seul.org (Postfix) with ESMTP id 928421469AE for ; Wed, 24 Apr 2002 17:59:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00478; Wed, 24 Apr 2002 11:59:53 +0200 Message-ID: <20020424115953.18453@thrai.stud.uni-hannover.de> Date: Wed, 24 Apr 2002 11:59:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> <20020422231836.07415@thrai.stud.uni-hannover.de> <018301c1ea76$c7cee4b0$bca45982@student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <018301c1ea76$c7cee4b0$bca45982@student.utwente.nl>; from Marco Al on Tue, Apr 23, 2002 at 05:27:21AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Apr 23, 2002 at 05:27:21AM +0200, Marco Al wrote: > Michael Riepe wrote: > > > Threads work best if they don't have to communicate with each other, > > no matter if they're running on 1 CPU or 1000. Communication usually > > means that you have to synchronize the sender and receiver thread, and > > the faster one will have to wait. In an MP system, you can run another > > thread instead, but synchronization and context switching still take > > some time -- and the more threads communicate with each other, the > more > > synchronization overhead you'll have. Therefore, `fine-grained' > threading > > doesn't work well (e.g. threads that return quickly or communicate a > lot). > > Depends on the architecture. > > "We can even use threads of about 10 instructions to achieve efficient > parallel execution" > > from http://www.computer.org/micro/mi2000/pdf/m4012.pdf Nice. If you do it in hardware, you can of course fork and synchronize threads much faster. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 25 00:37:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8s-0000Dc-01 for ; Thu, 25 Apr 2002 02:29:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:46 +0200 (CEST) Received: (qmail 19099 invoked by uid 0); 24 Apr 2002 22:37:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 24 Apr 2002 22:37:17 -0000 Received: by moria.seul.org (Postfix) id 59ADE1469B6; Wed, 24 Apr 2002 18:37:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 55D9F1469B1; Wed, 24 Apr 2002 18:37:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a095.home.uni-hannover.de [130.75.232.95]) by moria.seul.org (Postfix) with ESMTP id 144F31468E2 for ; Wed, 24 Apr 2002 18:37:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01351; Thu, 25 Apr 2002 00:37:06 +0200 Message-ID: <20020425003706.41653@thrai.stud.uni-hannover.de> Date: Thu, 25 Apr 2002 00:37:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200204241527.1b6c@th00.opsion.fr>; from Nicolas Boulay on Wed, Apr 24, 2002 at 03:27:27PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Apr 24, 2002 at 03:27:27PM +0000, Nicolas Boulay wrote: > What the opinion of others ? > > GPL are really well written by lawyer, and it will be hard to be > carefull of many different legal point ina new licence. > > Before writing something, it could be nice to have a list of feature not > present inside the GPL. Oh no, not THAT discussion again :-( -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Apr 25 00:58:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170X8u-0000Dc-00 for ; Thu, 25 Apr 2002 02:29:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 02:29:48 +0200 (CEST) Received: (qmail 32160 invoked by uid 0); 24 Apr 2002 23:00:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 24 Apr 2002 23:00:43 -0000 Received: by moria.seul.org (Postfix) id C7F461469B0; Wed, 24 Apr 2002 19:00:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C002D1469B7; Wed, 24 Apr 2002 19:00:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 5A89B1469B0 for ; Wed, 24 Apr 2002 19:00:40 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-207.jetnet.ab.ca [207.34.60.207]) by bach.incentre.net (8.12.3/8.11.6) with ESMTP id g3ON0xVQ021835 for ; Wed, 24 Apr 2002 17:01:06 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC7387E.9886FA2A@jetnet.ab.ca> Date: Wed, 24 Apr 2002 16:58:06 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <20020425003706.41653@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Wed, Apr 24, 2002 at 03:27:27PM +0000, Nicolas Boulay wrote: > > What the opinion of others ? > > > > GPL are really well written by lawyer, and it will be hard to be > > carefull of many different legal point ina new licence. > > > > Before writing something, it could be nice to have a list of feature not > > present inside the GPL. > > Oh no, not THAT discussion again :-( how about: "This software attempts to do bla-bla-bla. It is known to run on ya-ya-ya typically compiled with yap-yap-yap. You are free to use this software except where you make large sums of money and then the author wants his cut! We are not responsible for the users stupidity and expect this product to used with common sense and respected. Any copywrites are good until 5 years after the computer hardware (ya-ya-ya) has stopped being manufactured or the OS or hardware has been revised 3 times.Any damage done buy the product is limited to 1 band-ade." Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Apr 25 08:42:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovN-0000E9-01 for ; Thu, 25 Apr 2002 21:29:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:01 +0200 (CEST) Received: (qmail 4226 invoked by uid 0); 25 Apr 2002 06:49:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 25 Apr 2002 06:49:20 -0000 Received: by moria.seul.org (Postfix) id 3480A1467FF; Thu, 25 Apr 2002 02:49:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 050211469AE; Thu, 25 Apr 2002 02:49:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0727B1467FF for ; Thu, 25 Apr 2002 02:49:15 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 170cxh-0002MB-00 for f-cpu@seul.org; Thu, 25 Apr 2002 08:42:37 +0200 Date: Thu, 25 Apr 2002 08:42:37 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <20020424115953.18453@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 24 Apr 2002, Michael Riepe wrote: >> "We can even use threads of about 10 instructions to achieve efficient >> parallel execution" >> >> from http://www.computer.org/micro/mi2000/pdf/m4012.pdf > >Nice. If you do it in hardware, you can of course fork and synchronize >threads much faster. that's the way in the future anyway... JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Apr 25 08:45:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovO-0000E9-00 for ; Thu, 25 Apr 2002 21:29:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:02 +0200 (CEST) Received: (qmail 19993 invoked by uid 0); 25 Apr 2002 06:49:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 25 Apr 2002 06:49:22 -0000 Received: by moria.seul.org (Postfix) id DE5271469AE; Thu, 25 Apr 2002 02:49:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A103F1469C1; Thu, 25 Apr 2002 02:49:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 9FBE31469AE for ; Thu, 25 Apr 2002 02:49:16 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 170d0n-0002MD-00 for f-cpu@seul.org; Thu, 25 Apr 2002 08:45:49 +0200 Date: Thu, 25 Apr 2002 08:45:49 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence In-Reply-To: <3CC7387E.9886FA2A@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 24 Apr 2002, Ben Franchuk wrote: >how about: >"This software attempts to do bla-bla-bla. >It is known to run on ya-ya-ya typically compiled with yap-yap-yap. >You are free to use this software except where you make large sums >of money and then the author wants his cut! We are not responsible >for the users stupidity and expect this product to used with common >sense and respected. Any copywrites are good until 5 years after >the computer hardware (ya-ya-ya) has stopped being manufactured or the >OS or hardware has been revised 3 times.Any damage done buy the product >is limited to 1 band-ade." Why don't you just write how much you want and also provide your bank account number for the transfers as well in it? ;) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gareth-j.powell@st.com Thu Apr 25 11:09:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovO-0000E9-01 for ; Thu, 25 Apr 2002 21:29:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:02 +0200 (CEST) Received: (qmail 23154 invoked by uid 0); 25 Apr 2002 09:21:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 25 Apr 2002 09:21:25 -0000 Received: by moria.seul.org (Postfix) id EE979146811; Thu, 25 Apr 2002 05:21:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DAF701469C0; Thu, 25 Apr 2002 05:21:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by moria.seul.org (Postfix) with ESMTP id 341A9146811 for ; Thu, 25 Apr 2002 05:21:22 -0400 (EDT) Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 3C6714E6F for ; Thu, 25 Apr 2002 09:21:21 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 6D50B6327; Thu, 25 Apr 2002 09:09:34 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B280D1845 for ; Thu, 25 Apr 2002 09:09:33 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 170fFs-0006eU-00 for f-cpu@seul.org; Thu, 25 Apr 2002 10:09:32 +0100 Received: from [164.129.10.63] (helo=st.com) by masterwort with asmtp (Exim 3.22 #1) id 170fFs-0003DE-00 for f-cpu@seul.org; Thu, 25 Apr 2002 10:09:32 +0100 Message-ID: <3CC7C7CC.70955D1D@st.com> Date: Thu, 25 Apr 2002 10:09:32 +0100 From: Gareth-J Powell Organization: STMicroelectronics R&D Ltd. X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, nice to be back! goeritz@oekomm.de wrote: > > On Mon, 22 Apr 2002, Marco Al wrote: > >Juergen Goeritz wrote: > > [snip] > >How about Occam? ;) > > I know occam from the time I looked at transputers. The > language didn't really turn me on. Everything felt too > complicated. Maybe that was one thing why the transputer > never made its way to a real hit (beside being much too > expensive). [more snipage] Transputer expensive? dead? Not quite! (from the archives) From: richard@rjingram.freeserve.co.uk (Richard Ingram) Newsgroups: comp.sys.transputer Subject: Re: Questio: State of Transputer Business Date: Sat, 30 Jan 1999 12:23:46 GMT Organization: Customer of Planet Online Message-Id: <36b2f8ed.2667329@news.freeserve.net> References: <19990117221716.07791.00002292@ng115.aol.com> Xref: ukc comp.sys.transputer:9010 On Mon, 18 Jan 1999 19:19:09 +0000, Alec Cawley wrote: >In article <19990117221716.07791.00002292@ng115.aol.com>, MSmith > writes >>Can anyone tell me if transputers are still being manufactured, and who >>supports them still? > >No more orders are being taken for transputers, and orders in the >pipeline will be fulfilled by end '99. Sadly, the transputer is dead. Well not quite true, it has matured into an embedded processor only available to large OEM customers making STB's. Check out most digi STB's and they will have a derivative of the transputer in, ie the ST20 core from STM. Download the data sheets, compare to the T8/4 datasheets and it is a transputer :-) >However, see earlier posts in this news group for transputer-like follow >on hardware and other occam platforms. > >-- >Alec Cawley Richard. So if you have a digital set top box, DVD player, etc. YOU HAVE (very good chance of) A TRANSPUTER INSIDE!!! **These are my own views on not those of any of my employers past or present, not that I am stupid enough to shaft my current employer either** Regards, GP ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Apr 25 11:50:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovQ-0000E9-00 for ; Thu, 25 Apr 2002 21:29:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:04 +0200 (CEST) Received: (qmail 21476 invoked by uid 0); 25 Apr 2002 09:53:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 25 Apr 2002 09:53:13 -0000 Received: by moria.seul.org (Postfix) id A490C146803; Thu, 25 Apr 2002 05:53:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98B691469C0; Thu, 25 Apr 2002 05:53:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 3DD30146803 for ; Thu, 25 Apr 2002 05:53:11 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 170ftZ-0002c0-00 for f-cpu@seul.org; Thu, 25 Apr 2002 11:50:33 +0200 Date: Thu, 25 Apr 2002 11:50:33 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <3CC7C7CC.70955D1D@st.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Really interesting... JG On Thu, 25 Apr 2002, Gareth-J Powell wrote: >Hi, nice to be back! > >goeritz@oekomm.de wrote: >> >> On Mon, 22 Apr 2002, Marco Al wrote: >> >Juergen Goeritz wrote: >> > >[snip] >> >How about Occam? ;) >> >> I know occam from the time I looked at transputers. The >> language didn't really turn me on. Everything felt too >> complicated. Maybe that was one thing why the transputer >> never made its way to a real hit (beside being much too >> expensive). >[more snipage] > > >Transputer expensive? dead? Not quite! (from the archives) > > From: richard@rjingram.freeserve.co.uk (Richard Ingram) >Newsgroups: comp.sys.transputer >Subject: Re: Questio: State of Transputer Business >Date: Sat, 30 Jan 1999 12:23:46 GMT >Organization: Customer of Planet Online >Message-Id: <36b2f8ed.2667329@news.freeserve.net> >References: <19990117221716.07791.00002292@ng115.aol.com> > >Xref: ukc comp.sys.transputer:9010 > > >On Mon, 18 Jan 1999 19:19:09 +0000, Alec Cawley > wrote: > >>In article <19990117221716.07791.00002292@ng115.aol.com>, MSmith >> writes >>>Can anyone tell me if transputers are still being manufactured, and who >>>supports them still? >> >>No more orders are being taken for transputers, and orders in the >>pipeline will be fulfilled by end '99. Sadly, the transputer is dead. > >Well not quite true, it has matured into an embedded processor only >available to large OEM customers making STB's. Check out most digi >STB's and they will have a derivative of the transputer in, ie the >ST20 core from STM. Download the data sheets, compare to the T8/4 >datasheets and it is a transputer :-) > >>However, see earlier posts in this news group for transputer-like follow >>on hardware and other occam platforms. >> >>-- >>Alec Cawley > >Richard. > > >So if you have a digital set top box, DVD player, etc. YOU HAVE (very good chance of) A TRANSPUTER INSIDE!!! > > >**These are my own views on not those of any of my employers past or present, not that I am stupid enough to shaft my current employer either** > >Regards, >GP >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 25 12:01:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovS-0000E9-00 for ; Thu, 25 Apr 2002 21:29:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:06 +0200 (CEST) Received: (qmail 30869 invoked by uid 0); 25 Apr 2002 09:55:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 25 Apr 2002 09:55:01 -0000 Received: by moria.seul.org (Postfix) id B2AE31469C2; Thu, 25 Apr 2002 05:54:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B03D11469C1; Thu, 25 Apr 2002 05:54:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 6E5EB1469BE for ; Thu, 25 Apr 2002 05:54:58 -0400 (EDT) Received: from f-cpu.org (kdl16-142.n.club-internet.fr [213.44.18.142]) by relay-4v.club-internet.fr (Postfix) with ESMTP id C4C51173F for ; Thu, 25 Apr 2002 11:54:54 +0200 (CEST) Message-ID: <3CC7D403.6BC46BCD@f-cpu.org> Date: Thu, 25 Apr 2002 12:01:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Michael wrote : > Oh no, not THAT discussion again :-( Did you think it was over ? Nicolas Boulay wrote: > What the opinion of others ? I have discussed a bit with Michael and i think that we agree on certain points. However i will not close the debate easily. Other's voice is welcome but code writers are legally the ones who can "decide" : this is another reason why i urge others to write code. > GPL are really well written by lawyer, and it will be hard to be > carefull of many different legal point ina new licence. GPL was written for computer software (code that is executed by a computer) and does not fit the needs of a > Before writing something, it could be nice to have a list of feature not > present inside the GPL. GPL allows or forbids things that i and Michael don't agree on. However, we will reuse the principle of "Copyleft" and keep the major points. > nicO then Ben wrote : > how about: > "This software attempts to do bla-bla-bla. > It is known to run on ya-ya-ya typically compiled with yap-yap-yap. > You are free to use this software except where you make large sums > of money and then the author wants his cut! We are not responsible > for the users stupidity and expect this product to used with common > sense and respected. Any copywrites are good until 5 years after > the computer hardware (ya-ya-ya) has stopped being manufactured or the > OS or hardware has been revised 3 times.Any damage done buy the product > is limited to 1 band-ade." :-) some points however : * "Any copywrites are good until 5 years after the computer hardware (ya-ya-ya) has stopped being manufactured or the OS or hardware has been revised 3 times." This is not acceptable, even though it could be reasonable. All copyright (and copyleft) remains 70 after the author's death (or something else, i don't remember). After that, it becomes public domain. So all our code remains protected and our will is obeyed during that time. no need to limit that to another arbitrary duration. * We don't do F-CPU for the royalties. * " We are not responsible for the users stupidity and expect this product to used with common sense and respected." ==> i think i'll keep that one untouched :-) read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 25 12:01:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovS-0000E9-01 for ; Thu, 25 Apr 2002 21:29:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:06 +0200 (CEST) Received: (qmail 2307 invoked by uid 0); 25 Apr 2002 09:55:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 25 Apr 2002 09:55:01 -0000 Received: by moria.seul.org (Postfix) id 6E02B1469C0; Thu, 25 Apr 2002 05:55:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 695831469C5; Thu, 25 Apr 2002 05:55:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 46C701469C0 for ; Thu, 25 Apr 2002 05:55:00 -0400 (EDT) Received: from f-cpu.org (kdl16-142.n.club-internet.fr [213.44.18.142]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 2DFA51695 for ; Thu, 25 Apr 2002 11:54:56 +0200 (CEST) Message-ID: <3CC7D403.55603830@f-cpu.org> Date: Thu, 25 Apr 2002 12:01:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account References: <200204230148.40886.cedric.bail@free.fr> <3CC60EF2.2F6C0F03@f-cpu.org> <200204250000.26088.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric wrote: > Hi, hi ! too > > cedric wrote: > > > > What i need is a DataFlow Graph analysis tool that allows me to > > > > handle large chuncks of code with all the automated tedious tasks > > > > that i usually do by hand (register allocation, reallocation, > > > > interleaving...) > > > > > > What did you mean by reallocation is i memory operation or register > > > reallocation ? If it's the second, the problem is the same as register > > > allocation, and it exist some good algorithm for risc machine (with a lot > > > of registers), that can do that better than a lot of human ;-) > > > > do you speak about register coloring ? the complexity grows at least O(n^2) > > with the number of registers. the "manual" algo i use (and which can be > > automated) is O(n), or linear complexity. give it more registers and it > > will be even happier (contrarily to register coloring). > Well, a lot of people will be interested by your algorithm I think, you will > explain it to me "au first jeudi" ? if you have enough time and if we find a quiet place (you know how much people can shout there :-D) > > > For interleaving, it's, if I correctly understand what you mean > > > scheduling, > > instruction scheduling, to be exact (look at the end of the DCT paper) > > > > the problem is not easy, > > what i do is straight-forward : it's like taking a string aaaaaaaaaaa and > > bbbbbbbbbbb and interleaving it : abababababababababababababababab... > I think that gcc can do that well, it's not very difficult, the solution is > when you have 2 operations that are dependent, you must maximise the distance > between them. That's all, I think ? that's pretty well said. This also explains that when the degree of parallelism (ILP, or with mutliple parallel pipelines) increased and the latency increases too, the algorithm becomes more critical. > I know that perhaps not always the best solution, but it good enough. if you know a better solution, don't make me wait for an explanation ;-P > > > and need a lot of time to have the right answer. > > at least the time to type it ;-) > So it's not so difficult ;-) As i wrote in the source code of one of the DCT examples (5th version ?) the is more or less what the P6 core does, but in the _reverse_ order, which is more efficient (because no physical register is left unused). > > > But what we can do is detecting where we lost cycle. > > > (It's what I plan to do in my asm). > > it's like calling the doctor who says : "you're sick" and goes away. > Exactly, but actually the human are better than our algorithm, no ? no, what i meant is : knowing the problem doesn't solve it. If you can detect a pipeline stall, it won't tell you why it is there, and how to remove it. OTOH an algorithm that creates good code _by_construction_ is more interesting because you don't have to check the result. > > writing asm is ok for small code (like the DCT) but not for large code, > > you need to not have to worry about the representation, only about the > > function, and asm programming does not make that possible. > > peephole optimisation might be easier with your tool, but that's all. > > it doesn't solve the "big problems" which often come from superficial > > analysis. > And algorithm, but you know actually developper brain is too expensive, so you > need a good optimisation but it must be done quickly and without the need of > learning a new tool or language. i don't understand what you want to say... > > btw, do you come to the Libre Software Meeting in Bordeaux ? > > will you present some of our work ? > Yes of course, I have some problem with my pop at epita, so if some discussion > append on it, I can't know them. But we will meet us at the "first jeudi" ? of course i'll come to Les Halles. But do you want to present something ? do you have a subject in mind ? > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 25 12:01:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovU-0000E9-00 for ; Thu, 25 Apr 2002 21:29:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:08 +0200 (CEST) Received: (qmail 29118 invoked by uid 0); 25 Apr 2002 09:55:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 25 Apr 2002 09:55:05 -0000 Received: by moria.seul.org (Postfix) id D37EF1469C6; Thu, 25 Apr 2002 05:55:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D0CE61469C5; Thu, 25 Apr 2002 05:55:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id EA71C1469C3 for ; Thu, 25 Apr 2002 05:55:00 -0400 (EDT) Received: from f-cpu.org (kdl16-142.n.club-internet.fr [213.44.18.142]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 4221E1691 for ; Thu, 25 Apr 2002 11:54:57 +0200 (CEST) Message-ID: <3CC7D405.1C3EB736@f-cpu.org> Date: Thu, 25 Apr 2002 12:01:41 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account References: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> <20020422231836.07415@thrai.stud.uni-hannover.de> <018301c1ea76$c7cee4b0$bca45982@student.utwente.nl> <20020424115953.18453@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Apr 23, 2002 at 05:27:21AM +0200, Marco Al wrote: > > Michael Riepe wrote: > > > Threads work best if they don't have to communicate with each other, > > > no matter if they're running on 1 CPU or 1000. Communication usually > > > means that you have to synchronize the sender and receiver thread, and > > > the faster one will have to wait. In an MP system, you can run another > > > thread instead, but synchronization and context switching still take > > > some time -- and the more threads communicate with each other, the more > > > synchronization overhead you'll have. Therefore, `fine-grained' threading > > > doesn't work well (e.g. threads that return quickly or communicate a lot). > > Depends on the architecture. of course. but usually, we speak about "classic RISC" on this list. > > "We can even use threads of about 10 instructions to achieve efficient > > parallel execution" > > from http://www.computer.org/micro/mi2000/pdf/m4012.pdf oh, _that_ paper... > Nice. If you do it in hardware, you can of course fork and synchronize > threads much faster. i don't remember well, but even though synchronisation is rather fast (through common registers or something like that), _communication_ and _programming_ is another subject... and i don't even speak about extensibility (and binary compatibility) because it looks like an ASIC that has a very specific application (speech recognition). > Michael "Tired" Riepe Juergen Goeritz wrote: > On Wed, 24 Apr 2002, Michael Riepe wrote: > >> "We can even use threads of about 10 instructions to achieve efficient > >> parallel execution" > >> > >> from http://www.computer.org/micro/mi2000/pdf/m4012.pdf > > > >Nice. If you do it in hardware, you can of course fork and synchronize > >threads much faster. > > that's the way in the future anyway... and it will remain so for a long time ;-P (that what they said about InP and AsGa for a while and it still holds) > JG WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Thu Apr 25 14:14:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovV-0000E9-01 for ; Thu, 25 Apr 2002 21:29:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:09 +0200 (CEST) Received: (qmail 8399 invoked by uid 0); 25 Apr 2002 12:08:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 25 Apr 2002 12:08:04 -0000 Received: by moria.seul.org (Postfix) id 5B2CC1467F8; Thu, 25 Apr 2002 08:08:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 515451468D4; Thu, 25 Apr 2002 08:08:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by moria.seul.org (Postfix) with ESMTP id 0BCB61467F8 for ; Thu, 25 Apr 2002 08:08:02 -0400 (EDT) Received: from computer ([208.60.245.159]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020425120927.LHTG16252.imf13bis.bellsouth.net@computer>; Thu, 25 Apr 2002 08:09:27 -0400 Message-ID: <005301c1ec52$b38b2a80$9ff53cd0@computer> From: "richard hartny" To: Cc: "Richard E. Hartny" Subject: [f-cpu] Question Date: Thu, 25 Apr 2002 07:14:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C1EC28.C9E416E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C1EC28.C9E416E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good Morning from South Mississippi. Someone on the list doesn't like my input and has requested that I be = removed from same. I am following with interest the goings on - most of = which does me little or no good. =20 I will remove myself from the list =3D if I receive enough requests. Richard E. Hartney Research Director Erin Greene & Associates Business Information Management Systems ------=_NextPart_000_0050_01C1EC28.C9E416E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good Morning from South = Mississippi.
 
Someone on the list doesn't like my = input and has=20 requested that I be removed from same.  I am following with = interest the=20 goings on - most of which does me little or no good. 
 
I will remove myself from the list =3D = if I receive=20 enough requests.
 
Richard E. Hartney
Research Director
Erin Greene & = Associates
Business Information Management=20 Systems
------=_NextPart_000_0050_01C1EC28.C9E416E0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Apr 25 17:12:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170ovY-0000E9-00 for ; Thu, 25 Apr 2002 21:29:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 25 Apr 2002 21:29:12 +0200 (CEST) Received: (qmail 19704 invoked by uid 0); 25 Apr 2002 15:14:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 25 Apr 2002 15:14:30 -0000 Received: by moria.seul.org (Postfix) id B48EB1469C4; Thu, 25 Apr 2002 11:14:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 95F851469C7; Thu, 25 Apr 2002 11:14:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 1471F1469C4 for ; Thu, 25 Apr 2002 11:14:29 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by bach.incentre.net (8.12.3/8.11.6) with ESMTP id g3PFF3VQ085021 for ; Thu, 25 Apr 2002 09:15:03 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CC81CCB.34C77677@jetnet.ab.ca> Date: Thu, 25 Apr 2002 09:12:11 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > > On Wed, 24 Apr 2002, Ben Franchuk wrote: > >how about: > >"This software attempts to do bla-bla-bla. > >It is known to run on ya-ya-ya typically compiled with yap-yap-yap. > >You are free to use this software except where you make large sums > >of money and then the author wants his cut! We are not responsible > >for the users stupidity and expect this product to used with common > >sense and respected. Any copywrites are good until 5 years after > >the computer hardware (ya-ya-ya) has stopped being manufactured or the > >OS or hardware has been revised 3 times.Any damage done buy the product > >is limited to 1 band-ade." > > Why don't you just write how much you want and also provide > your bank account number for the transfers as well in it? ;) > Just send Cash! 1 wooden nickel for every $1.00 profit. I take a queen size mattress for all your large donations. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Fri Apr 26 01:12:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170uzZ-0005IX-00 for ; Fri, 26 Apr 2002 03:57:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 03:57:45 +0200 (CEST) Received: (qmail 29812 invoked by uid 0); 25 Apr 2002 23:12:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 25 Apr 2002 23:12:50 -0000 Received: by moria.seul.org (Postfix) id 4F2EB1468EA; Thu, 25 Apr 2002 19:12:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 07332146909; Thu, 25 Apr 2002 19:12:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 9F25C1468EA for ; Thu, 25 Apr 2002 19:12:46 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g3PNCj327119 for ; Fri, 26 Apr 2002 01:12:45 +0200 Message-ID: <003101c1ecae$ba14bb30$bca45982@student.utwente.nl> From: "Marco Al" To: References: <00b301c1e9e1$418c1f20$c5dec2d4@ifurita> <20020422231836.07415@thrai.stud.uni-hannover.de> <018301c1ea76$c7cee4b0$bca45982@student.utwente.nl> <20020424115953.18453@thrai.stud.uni-hannover.de> <3CC7D405.1C3EB736@f-cpu.org> Subject: Re: [f-cpu] Winograd DCT on my seul.org account Date: Fri, 26 Apr 2002 01:12:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > of course. but usually, we speak about "classic RISC" on this list. When I think about classic RISC I think about superscalar execution, since that is what all the classic RISC architectures used to evolve. And within the community which created those classic RISC design the consensus that superscalar has hit diminishing returns has been around long enough that even that very idea can be termed classic :) Dynamic multithreading uses threads not a whole lot bigger than mentioned here. >>> "We can even use threads of about 10 instructions to achieve efficient >>> parallel execution" >>> from http://www.computer.org/micro/mi2000/pdf/m4012.pdf > > oh, _that_ paper... > >> Nice. If you do it in hardware, you can of course fork and synchronize >> threads much faster. > > i don't remember well, but even though synchronisation is rather fast > (through common registers or something like that), _communication_ > and _programming_ is another subject... and i don't even speak about > extensibility (and binary compatibility) because it looks like > an ASIC that has a very specific application (speech recognition). It looks like an embedded processor to me, might be slightly tailored to a specific task ... but its no more a speech recognition ASIC than say the SH4 is a 3D T&L ASIC IMO. >>> Nice. If you do it in hardware, you can of course fork and synchronize >>> threads much faster. >> >> that's the way in the future anyway... > > and it will remain so for a long time ;-P You might want to tell Intel that. Marco ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Apr 26 01:51:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 170uzb-0005IX-00 for ; Fri, 26 Apr 2002 03:57:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 03:57:47 +0200 (CEST) Received: (qmail 26602 invoked by uid 0); 26 Apr 2002 01:22:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 26 Apr 2002 01:22:16 -0000 Received: by moria.seul.org (Postfix) id 7029114692B; Thu, 25 Apr 2002 21:22:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66909146933; Thu, 25 Apr 2002 21:22:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 024C614692B for ; Thu, 25 Apr 2002 21:22:14 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-155-252.dial.proxad.net [62.147.155.252]) by postfix2-1.free.fr (Postfix) with ESMTP id 7DE8CD45B for ; Thu, 25 Apr 2002 22:46:44 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Date: Thu, 25 Apr 2002 23:51:28 +0000 X-Mailer: KMail [version 1.4] References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> In-Reply-To: <3CC7D403.55603830@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204252351.28089.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Hi, > hi ! too Hi ! three ;-) > > > > But what we can do is detecting where we lost cycle. > > > > (It's what I plan to do in my asm). > > > > > > it's like calling the doctor who says : "you're sick" and goes away. > > > > Exactly, but actually the human are better than our algorithm, no ? > > no, what i meant is : knowing the problem doesn't solve it. > If you can detect a pipeline stall, it won't tell you why it is there, > and how to remove it. OTOH an algorithm that creates good code > _by_construction_ is more interesting because you don't have to check the > result. you can't create a code right scheduling _by_construction_. You nead a special pass that do the scheduling. > > > btw, do you come to the Libre Software Meeting in Bordeaux ? > > > will you present some of our work ? > > > > Yes of course, I have some problem with my pop at epita, so if some > > discussion append on it, I can't know them. But we will meet us at the > > "first jeudi" ? > > of course i'll come to Les Halles. > But do you want to present something ? do you have a subject in mind ? It depend on the time I have, but why not ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Apr 26 07:50:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719dz-00009B-00 for ; Fri, 26 Apr 2002 19:36:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:27 +0200 (CEST) Received: (qmail 25692 invoked by uid 0); 26 Apr 2002 05:54:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 26 Apr 2002 05:54:51 -0000 Received: by moria.seul.org (Postfix) id 15E38146933; Fri, 26 Apr 2002 01:54:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC0A314693E; Fri, 26 Apr 2002 01:54:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B36CC146933 for ; Fri, 26 Apr 2002 01:54:47 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 170yd1-0003GU-00 for f-cpu@seul.org; Fri, 26 Apr 2002 07:50:43 +0200 Date: Fri, 26 Apr 2002 07:50:43 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <200204252351.28089.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 25 Apr 2002, cedric wrote: >> > Hi, >> hi ! too >Hi ! three ;-) hi ! four :-) >> > > > But what we can do is detecting where we lost cycle. >> > > > (It's what I plan to do in my asm). >> > > >> > > it's like calling the doctor who says : "you're sick" and goes away. >> > >> > Exactly, but actually the human are better than our algorithm, no ? The human mind is differently working (associative) and thus not bound to sequential computer algorithmic structure which in return makes it superior because it also can think the algorithmic way. It's a superset of some kind. >> no, what i meant is : knowing the problem doesn't solve it. >> If you can detect a pipeline stall, it won't tell you why it is there, >> and how to remove it. OTOH an algorithm that creates good code >> _by_construction_ is more interesting because you don't have to check the >> result. >you can't create a code right scheduling _by_construction_. You nead a special >pass that do the scheduling. ... or go as massively parallel as the human brain does. It comes at only 30..45 Hz operating frequency ;) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Apr 26 07:45:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719dz-00009B-01 for ; Fri, 26 Apr 2002 19:36:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:27 +0200 (CEST) Received: (qmail 19849 invoked by uid 0); 26 Apr 2002 05:55:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 26 Apr 2002 05:55:02 -0000 Received: by moria.seul.org (Postfix) id BF44614693C; Fri, 26 Apr 2002 01:55:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6416146941; Fri, 26 Apr 2002 01:55:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 5A3BA14693C for ; Fri, 26 Apr 2002 01:55:00 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 170yXV-0003GS-00 for f-cpu@seul.org; Fri, 26 Apr 2002 07:45:01 +0200 Date: Fri, 26 Apr 2002 07:45:01 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <003101c1ecae$ba14bb30$bca45982@student.utwente.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >>>> Nice. If you do it in hardware, you can of course fork and >synchronize >>>> threads much faster. >>> >>> that's the way in the future anyway... >> >> and it will remain so for a long time ;-P > >You might want to tell Intel that. Neither would they listen at all, nor fund some money to make a prove. At least that is my experience with ALL the big companies I worked for or tried to acquire. At best they take your idea/concept and make it their own and I don't even bother to try to give these companies another idea any more. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Apr 26 09:54:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719eJ-00009B-00 for ; Fri, 26 Apr 2002 19:36:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:47 +0200 (CEST) Received: (qmail 6379 invoked by uid 0); 26 Apr 2002 07:54:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 26 Apr 2002 07:54:50 -0000 Received: by moria.seul.org (Postfix) id E7F4214690E; Fri, 26 Apr 2002 03:54:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8CDDE146941; Fri, 26 Apr 2002 03:54:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 95C9714690E for ; Fri, 26 Apr 2002 03:54:42 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 1710Z5-0003gZ-00 for f-cpu@seul.org; Fri, 26 Apr 2002 09:54:47 +0200 Date: Fri, 26 Apr 2002 09:54:47 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 26 Apr 2002, Juergen Goeritz wrote: >>>>> Nice. If you do it in hardware, you can of course fork and >>>>> synchronize threads much faster. >>>> >>>> that's the way in the future anyway... >>> >>> and it will remain so for a long time ;-P >> >>You might want to tell Intel that. > >Neither would they listen at all, nor fund some money to >make a prove. At least that is my experience with ALL the >big companies I worked for or tried to acquire. At best >they take your idea/concept and make it their own and I >don't even bother to try to give these companies another >idea any more. But of course I would love to have somebody prove me wrong ;) JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 26 10:16:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719eJ-00009B-01 for ; Fri, 26 Apr 2002 19:36:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:47 +0200 (CEST) Received: (qmail 25344 invoked by uid 0); 26 Apr 2002 08:10:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 26 Apr 2002 08:10:31 -0000 Received: by moria.seul.org (Postfix) id 198AD14693E; Fri, 26 Apr 2002 04:10:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 128D9146945; Fri, 26 Apr 2002 04:10:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id AC87514693E for ; Fri, 26 Apr 2002 04:10:27 -0400 (EDT) Received: from f-cpu.org (kdl11-143.n.club-internet.fr [213.44.9.143]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 4D28C169A for ; Fri, 26 Apr 2002 10:10:25 +0200 (CEST) Message-ID: <3CC90CE5.FE21378D@f-cpu.org> Date: Fri, 26 Apr 2002 10:16:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Question References: <005301c1ec52$b38b2a80$9ff53cd0@computer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, > richard hartny wrote: > > Good Morning from South Mississippi. > > Someone on the list doesn't like my input and has requested that > I be removed from same. I am following with interest the goings > on - most of which does me little or no good. > > I will remove myself from the list = if I receive enough requests. ????? If this person doesn't have the courage to express his opinion on the list, why bother ? > Richard E. Hartney > Research Director > Erin Greene & Associates > Business Information Management Systems WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 26 14:47:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719eL-00009B-00 for ; Fri, 26 Apr 2002 19:36:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:49 +0200 (CEST) Received: (qmail 10220 invoked by uid 0); 26 Apr 2002 12:41:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 26 Apr 2002 12:41:59 -0000 Received: by moria.seul.org (Postfix) id 0619E14690E; Fri, 26 Apr 2002 08:41:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF42014692B; Fri, 26 Apr 2002 08:41:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 79ABF14690E for ; Fri, 26 Apr 2002 08:41:53 -0400 (EDT) Received: from f-cpu.org (kdl16-78.n.club-internet.fr [213.44.18.78]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7979B16A4 for ; Fri, 26 Apr 2002 14:41:51 +0200 (CEST) Message-ID: <3CC94C7E.2B570C09@f-cpu.org> Date: Fri, 26 Apr 2002 14:47:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric wrote: > > > Hi, > > hi ! too > Hi ! three ;-) hi, five (after Jürgen) > > > > > But what we can do is detecting where we lost cycle. > > > > > (It's what I plan to do in my asm). > > > > it's like calling the doctor who says : "you're sick" and goes away. > > > Exactly, but actually the human are better than our algorithm, no ? > > no, what i meant is : knowing the problem doesn't solve it. > > If you can detect a pipeline stall, it won't tell you why it is there, > > and how to remove it. OTOH an algorithm that creates good code > > _by_construction_ is more interesting because you don't have to check the > > result. > you can't create a code right scheduling _by_construction_. You nead a special > pass that do the scheduling. no. that's the point. you have to think about scheduling with a different approach. adding a "rescheduler" at the butt of a dumb algorithm is under-efficient, the scheduling constraints must be taken into account in the whole program. > > > > btw, do you come to the Libre Software Meeting in Bordeaux ? > > > > will you present some of our work ? > > > Yes of course, I have some problem with my pop at epita, so if some > > > discussion append on it, I can't know them. But we will meet us at the > > > "first jeudi" ? > > of course i'll come to Les Halles. > > But do you want to present something ? do you have a subject in mind ? > It depend on the time I have, but why not ? great ! > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Apr 26 15:17:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1719eL-00009B-01 for ; Fri, 26 Apr 2002 19:36:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 19:36:49 +0200 (CEST) Received: (qmail 7934 invoked by uid 0); 26 Apr 2002 13:34:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 26 Apr 2002 13:34:48 -0000 Received: by moria.seul.org (Postfix) id B5EC7146943; Fri, 26 Apr 2002 09:34:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7AEA414694A; Fri, 26 Apr 2002 09:34:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 23DB1146943 for ; Fri, 26 Apr 2002 09:34:47 -0400 (EDT) Received: from ifurita (212.194.233.177) by smtp.laposte.net (5.5.044) id 3CC7AF7B00027EF2 for f-cpu@seul.org; Fri, 26 Apr 2002 15:34:41 +0200 Message-ID: <000a01c1ed24$bf1f7540$b1e9c2d4@ifurita> From: "Christophe" To: References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> <3CC94C7E.2B570C09@f-cpu.org> Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Date: Fri, 26 Apr 2002 15:17:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Yann Guidon To: Sent: Friday, April 26, 2002 2:47 PM Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account > cedric wrote: > > > > Hi, > > > hi ! too > > Hi ! three ;-) > hi, five (after Jürgen) hi, sex... huh six :-/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 26 12:27:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Dip-0003PI-00 for ; Fri, 26 Apr 2002 23:57:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:43 +0200 (CEST) Received: (qmail 6345 invoked by uid 0); 26 Apr 2002 17:09:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 26 Apr 2002 17:09:51 -0000 Received: by moria.seul.org (Postfix) id 3148D14694A; Fri, 26 Apr 2002 13:09:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2AAFA14691B; Fri, 26 Apr 2002 13:09:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id 99825146828 for ; Fri, 26 Apr 2002 13:09:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00572; Fri, 26 Apr 2002 12:27:05 +0200 Message-ID: <20020426122704.00354@thrai.stud.uni-hannover.de> Date: Fri, 26 Apr 2002 12:27:04 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <3CC7D403.6BC46BCD@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CC7D403.6BC46BCD@f-cpu.org>; from Yann Guidon on Thu, Apr 25, 2002 at 12:01:39PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Apr 25, 2002 at 12:01:39PM +0200, Yann Guidon wrote: > hello, > > Michael wrote : > > Oh no, not THAT discussion again :-( > Did you think it was over ? Suspended. I will change my license at most *once*. Until there is an `F-CPU Public License' that I can agree on, things will stay the way they are. In order to come to an agreement, we should start to compile a list of rights and responsibilities users shall have. In particular, they should be allowed to - make verbatim copies of the complete source code - distribute verbatim copies of the complete source code - make derived works if they release the source code under the same license - use parts of the source code in their own projects if they release the source code under the same license and include a notice that they are using parts of the F-CPU - substitute parts (e.g. gates, flipflops, maybe also memory) with cells from proprietary cell libraries if it is necessary in order to produce silicon (they shall, however, fully document such changes) - produce silicon and distribute it, as long as they also deliver the source code for everything but the above mentioned proprietary cell libraries (the source code for the substituted components must still be included) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Apr 26 19:26:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Diq-0003PI-00 for ; Fri, 26 Apr 2002 23:57:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:44 +0200 (CEST) Received: (qmail 31658 invoked by uid 0); 26 Apr 2002 17:25:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 26 Apr 2002 17:25:28 -0000 Received: by moria.seul.org (Postfix) id CA9B11468E4; Fri, 26 Apr 2002 13:25:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADC3214694B; Fri, 26 Apr 2002 13:25:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 29E0B1468E4 for ; Fri, 26 Apr 2002 13:25:26 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id 8C76560051 for ; Fri, 26 Apr 2002 19:25:25 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 9EE2CFCCA; Fri, 26 Apr 2002 19:26:36 +0200 (MEST) To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Message-ID: <1019841996.3cc98dcc7589f@imp.free.fr> Date: Fri, 26 Apr 2002 19:26:36 +0200 (MEST) From: Cedric BAIL References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> <3CC94C7E.2B570C09@f-cpu.org> In-Reply-To: <3CC94C7E.2B570C09@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.253.245.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hi, five (after Jürgen) hi, again > > > > > > But what we can do is detecting where we lost cycle. > > > > > > (It's what I plan to do in my asm). > > > > > it's like calling the doctor who says : "you're sick" and goes away. > > > > Exactly, but actually the human are better than our algorithm, no ? > > > no, what i meant is : knowing the problem doesn't solve it. > > > If you can detect a pipeline stall, it won't tell you why it is there, > > > and how to remove it. OTOH an algorithm that creates good code > > > _by_construction_ is more interesting because you don't have to check > > > the result. > > you can't create a code right scheduling _by_construction_. You nead a > > special pass that do the scheduling. > no. that's the point. you have to think about scheduling with a > different approach. adding a "rescheduler" at the butt of a dumb algorithm > is under-efficient, the scheduling constraints must be taken into account > in the whole program. What you mean is that your algorithm is scheduling before the compilator do something. It's a big problem, that mean that if we change some coding rules for a CPU branche you need to redo and maintain an other scheduling version of your code... It's like asm ! I think that you understand the problem. The only way to schedule an algorithm in a high level language is after you generate the assembler, and this assembler can't be rigt scheduled when it's generated, because the intermediate representation didn't reflect the asm language. I know you will say that we only need to change it... But the intermediate representation reflect the source language and human thinking method, so that mean that you want to change the language ! It's perhaps possible to generate a more near assembler IR, but it will only reflect the language scheduled algorithm... same problem ! A+ cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Fri Apr 26 19:39:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Diq-0003PI-01 for ; Fri, 26 Apr 2002 23:57:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:44 +0200 (CEST) Received: (qmail 23200 invoked by uid 0); 26 Apr 2002 17:39:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Apr 2002 17:39:32 -0000 Received: by moria.seul.org (Postfix) id 02AA31468E4; Fri, 26 Apr 2002 13:39:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1CB2146953; Fri, 26 Apr 2002 13:39:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id D1D6B1468E4; Fri, 26 Apr 2002 13:39:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id D1486FEE31 for ; Fri, 26 Apr 2002 13:39:30 -0400 (EDT) Date: Fri, 26 Apr 2002 13:39:30 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence In-Reply-To: <20020426122704.00354@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 26 Apr 2002, Michael Riepe wrote: > On Thu, Apr 25, 2002 at 12:01:39PM +0200, Yann Guidon wrote: > > hello, > > > > Michael wrote : > > > Oh no, not THAT discussion again :-( Since the open cores group are currently discussing the same issue, having run into practical problems with the gpl, would it be a good idea to wait till they come to a decision then use the SAME license (assuming it is a reasonable, if not perfect fit to what f-cpu people want), to avoid getting the same silly proliferation of semi-compatible licenses there is with software? Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Apr 26 19:39:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Dir-0003PI-00 for ; Fri, 26 Apr 2002 23:57:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:45 +0200 (CEST) Received: (qmail 6344 invoked by uid 0); 26 Apr 2002 17:39:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 26 Apr 2002 17:39:43 -0000 Received: by moria.seul.org (Postfix) id 77D44146952; Fri, 26 Apr 2002 13:39:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 629DD146955; Fri, 26 Apr 2002 13:39:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 08F22146952 for ; Fri, 26 Apr 2002 13:39:42 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 1719h5-0004Li-00 for f-cpu@seul.org; Fri, 26 Apr 2002 19:39:39 +0200 Date: Fri, 26 Apr 2002 19:39:39 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <1019841996.3cc98dcc7589f@imp.free.fr> Message-ID: References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> <3CC94C7E.2B570C09@f-cpu.org> <1019841996.3cc98dcc7589f@imp.free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I think that you understand the problem. The only way to schedule an algorithm > in a high level language is after you generate the assembler, and this > assembler can't be rigt scheduled when it's generated, because the > intermediate representation didn't reflect the asm language. Hmm AFAIK about gcc it does scheduling as part of compilation and it seems to work (well it not so good in all cases). I think that scheduling almost done assembler is hard because you nave not all the information. For example gcc allows you to mark conditions as "likely" or "unlikely" to branch - this should influence scheduling but it is not known at later stages .. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Apr 26 20:25:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Dis-0003PI-00 for ; Fri, 26 Apr 2002 23:57:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:46 +0200 (CEST) Received: (qmail 18460 invoked by uid 0); 26 Apr 2002 18:25:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Apr 2002 18:25:41 -0000 Received: by moria.seul.org (Postfix) id EB68B146956; Fri, 26 Apr 2002 14:25:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D0594146960; Fri, 26 Apr 2002 14:25:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 87EEA146956 for ; Fri, 26 Apr 2002 14:25:39 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix2-2.free.fr (Postfix) with ESMTP id E8A5C5FC69 for ; Fri, 26 Apr 2002 20:25:38 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id DE1D06BEC; Fri, 26 Apr 2002 20:25:38 +0200 (MEST) To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account Message-ID: <1019845538.3cc99ba2d1bf5@imp.free.fr> Date: Fri, 26 Apr 2002 20:25:38 +0200 (MEST) From: Cedric BAIL References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> <3CC94C7E.2B570C09@f-cpu.org> <1019841996.3cc98dcc7589f@imp.free.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.253.245.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I think that you understand the problem. The only way to schedule an > > algorithm in a high level language is after you generate the assembler, > > and this assembler can't be rigt scheduled when it's generated, because > > the intermediate representation didn't reflect the asm language. > Hmm AFAIK about gcc it does scheduling as part of compilation and A i don't understand what you mean by "as part of compilation". If you mean that gcc do the schedule before sending the asm code to asm, I agree, but I don't think that he do it before during the creation of the IR. > it seems to work (well it not so good in all cases). > I think that scheduling almost done assembler is hard because you > nave not all the information. For example gcc allows you to mark > conditions as "likely" or "unlikely" to branch - this should influence > scheduling but it is not known at later stages .. Yes, of course you need the knowledge of the IR and the ASM to compute the schedule. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Apr 26 20:40:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Dis-0003PI-01 for ; Fri, 26 Apr 2002 23:57:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:46 +0200 (CEST) Received: (qmail 31874 invoked by uid 0); 26 Apr 2002 18:40:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 26 Apr 2002 18:40:21 -0000 Received: by moria.seul.org (Postfix) id B16BE14695F; Fri, 26 Apr 2002 14:40:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AC2F4146961; Fri, 26 Apr 2002 14:40:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 41E0714695F for ; Fri, 26 Apr 2002 14:40:20 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 171Adm-0004fB-00 for f-cpu@seul.org; Fri, 26 Apr 2002 20:40:18 +0200 Date: Fri, 26 Apr 2002 20:40:18 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account In-Reply-To: <1019845538.3cc99ba2d1bf5@imp.free.fr> Message-ID: References: <200204250000.26088.cedric.bail@free.fr> <3CC7D403.55603830@f-cpu.org> <200204252351.28089.cedric.bail@free.fr> <3CC94C7E.2B570C09@f-cpu.org> <1019841996.3cc98dcc7589f@imp.free.fr> <1019845538.3cc99ba2d1bf5@imp.free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I think that scheduling almost done assembler is hard because you > > nave not all the information. For example gcc allows you to mark > > conditions as "likely" or "unlikely" to branch - this should influence > > scheduling but it is not known at later stages .. > Yes, of course you need the knowledge of the IR and the ASM to compute the > schedule. Ahh ok I just thought that you wanted to schedule ASM without IR knowledge ... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Apr 26 21:54:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Diu-0003PI-00 for ; Fri, 26 Apr 2002 23:57:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:48 +0200 (CEST) Received: (qmail 5187 invoked by uid 0); 26 Apr 2002 19:48:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 26 Apr 2002 19:48:36 -0000 Received: by moria.seul.org (Postfix) id 80975146963; Fri, 26 Apr 2002 15:48:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66047146965; Fri, 26 Apr 2002 15:48:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 1D8A4146963 for ; Fri, 26 Apr 2002 15:48:34 -0400 (EDT) Received: from f-cpu.org (kdl11-22.n.club-internet.fr [213.44.9.22]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 61EAC1723 for ; Fri, 26 Apr 2002 21:48:30 +0200 (CEST) Message-ID: <3CC9B07E.167ED786@f-cpu.org> Date: Fri, 26 Apr 2002 21:54:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Graham Seaman wrote: > On Fri, 26 Apr 2002, Michael Riepe wrote: > > > On Thu, Apr 25, 2002 at 12:01:39PM +0200, Yann Guidon wrote: > > > hello, > > > > > > Michael wrote : > > > > Oh no, not THAT discussion again :-( > > Since the open cores group are currently discussing the same issue, having > run into practical problems with the gpl, would it be a good idea to wait > till they come to a decision then use the SAME license (assuming it is > a reasonable, if not perfect fit to what f-cpu people want), to avoid > getting the same silly proliferation of semi-compatible licenses there is > with software? That would be interesting. We keep GPL before a new and better license is available. So we won't confuse people with X, Y and Z versions and the list will not be focused on this subject only. > Graham WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Apr 26 22:20:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171Diu-0003PI-02 for ; Fri, 26 Apr 2002 23:57:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 26 Apr 2002 23:57:48 +0200 (CEST) Received: (qmail 5889 invoked by uid 0); 26 Apr 2002 20:20:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 26 Apr 2002 20:20:37 -0000 Received: by moria.seul.org (Postfix) id A45B51467E9; Fri, 26 Apr 2002 16:20:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FCEF146811; Fri, 26 Apr 2002 16:20:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 49D211467E9 for ; Fri, 26 Apr 2002 16:20:36 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix3-2.free.fr (Postfix) with ESMTP id 28944187AC for ; Fri, 26 Apr 2002 22:20:35 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 1B7C98C0F1; Fri, 26 Apr 2002 22:20:35 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Some web page Message-ID: <1019852435.3cc9b69315330@imp.free.fr> Date: Fri, 26 Apr 2002 22:20:35 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.253.245.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have quickly created some web page to represent the 2 currents visions of the F-CPU (the older and a wishbone/without XBar version). I have added 2 others pages to list all the hardwre and the software that we could code for the project. You will find them at : http://www.epita.fr:8000/~bail_c/ I think that we could includ an equivalent page in our new web site. If you want to add some something or correct what I say, it will help. Thanks, Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 27 00:59:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bNW-0002Jd-00 for ; Sun, 28 Apr 2002 01:13:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:13:18 +0200 (CEST) Received: (qmail 31655 invoked by uid 0); 26 Apr 2002 22:59:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 26 Apr 2002 22:59:12 -0000 Received: by moria.seul.org (Postfix) id 1A4AF1463AB; Fri, 26 Apr 2002 18:59:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1B741467E9; Fri, 26 Apr 2002 18:59:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a197.home.uni-hannover.de [130.75.232.197]) by moria.seul.org (Postfix) with ESMTP id 8F4671463AB for ; Fri, 26 Apr 2002 18:59:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01672; Sat, 27 Apr 2002 00:59:07 +0200 Message-ID: <20020427005907.11816@thrai.stud.uni-hannover.de> Date: Sat, 27 Apr 2002 00:59:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some web page References: <1019852435.3cc9b69315330@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1019852435.3cc9b69315330@imp.free.fr>; from Cedric BAIL on Fri, Apr 26, 2002 at 10:20:35PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Apr 26, 2002 at 10:20:35PM +0200, Cedric BAIL wrote: > Hi, > > I have quickly created some web page to represent the 2 currents > visions of the F-CPU (the older and a wishbone/without XBar version). > I have added 2 others pages to list all the hardwre and the software that we > could code for the project. > > You will find them at : http://www.epita.fr:8000/~bail_c/ Where does this second version come from, why does it exist, and what does "will be linked with the opencores project" mean? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Apr 27 13:32:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bO4-0002Jd-00 for ; Sun, 28 Apr 2002 01:13:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:13:52 +0200 (CEST) Received: (qmail 29447 invoked by uid 0); 27 Apr 2002 11:32:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 27 Apr 2002 11:32:21 -0000 Received: by moria.seul.org (Postfix) id 025DB146817; Sat, 27 Apr 2002 07:32:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0670146813; Sat, 27 Apr 2002 07:32:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id AC81014680F for ; Sat, 27 Apr 2002 07:32:20 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix1-2.free.fr (Postfix) with ESMTP id 2376FAB2D6 for ; Sat, 27 Apr 2002 13:32:20 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id 1898A6C3A; Sat, 27 Apr 2002 13:32:20 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Some web page Message-ID: <1019907140.3cca8c440de34@imp.free.fr> Date: Sat, 27 Apr 2002 13:32:20 +0200 (MEST) From: Cedric BAIL References: <1019852435.3cc9b69315330@imp.free.fr> <20020427005907.11816@thrai.stud.uni-hannover.de> In-Reply-To: <20020427005907.11816@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.253.245.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > On Fri, Apr 26, 2002 at 10:20:35PM +0200, Cedric BAIL wrote: > > Hi, > > > > I have quickly created some web page to represent the 2 currents > > visions of the F-CPU (the older and a wishbone/without XBar version). > > > I have added 2 others pages to list all the hardwre and the software > that we > > could code for the project. > > > > You will find them at : http://www.epita.fr:8000/~bail_c/ > > Where does this second version come from, why does it exist, and Some french guy are currently redrawing a new web site to replace the old ugly web site. I think that you can see a layout at geeno.free.fr, but if I correctly remember it's a work in progress. > what does "will be linked with the opencores project" mean? Because we will use the same interconnection bus (WISHBONE) as the opencore project to be able to reuse some of there core. I hope I was clearer and I think that I must change the text of my web page. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Apr 27 15:31:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bO7-0002Jd-00 for ; Sun, 28 Apr 2002 01:13:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:13:55 +0200 (CEST) Received: (qmail 8019 invoked by uid 0); 27 Apr 2002 14:20:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 27 Apr 2002 14:20:44 -0000 Received: by moria.seul.org (Postfix) id E492A146820; Sat, 27 Apr 2002 10:20:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B7A5146832; Sat, 27 Apr 2002 10:20:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 13529146820 for ; Sat, 27 Apr 2002 10:19:03 -0400 (EDT) Received: from ifrance.com (vlt3-243.n.club-internet.fr [194.158.108.243]) by relay-2m.club-internet.fr (Postfix) with ESMTP id F291216A8 for ; Sat, 27 Apr 2002 16:18:54 +0200 (CEST) Message-ID: <3CCAA815.5C4A62B9@ifrance.com> Date: Sat, 27 Apr 2002 15:31:01 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <3CC7D403.6BC46BCD@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hello, > > Michael wrote : > > Oh no, not THAT discussion again :-( > Did you think it was over ? > > Nicolas Boulay wrote: <..> > > GPL are really well written by lawyer, and it will be hard to be > > carefull of many different legal point ina new licence. > > GPL was written for computer software (code that is executed > by a computer) and does not fit the needs of a > http://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware --- You can apply the GPL to any kind of work, as long as it is clear what constitutes the "source code" for the work. The GPL defines this as the preferred form of the work for making changes in it. However, for manuals and textbooks, or more generally any sort of work that is meant to teach a subject, we recommend using the GFDL rather than the GPL. --- There is no problem for it. It was confirm by Mélanie Clément-Fontaine ( a lawyer that work for April,...) > > Before writing something, it could be nice to have a list of feature not > > present inside the GPL. > > GPL allows or forbids things that i and Michael don't agree on. > However, we will reuse the principle of "Copyleft" and keep the > major points. Which clauses ? Which points ? Before i don't like GPL because there isn't any way to mix fcpu core and proprietary code as for Leon (for SOC design it sound stupid !). The problem are to define the interface. Even the LPGL isn't clear. So the solution given by the GPL FAQ convince me. > > > nicO > WHYGEE nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Apr 27 15:47:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bO9-0002Jd-00 for ; Sun, 28 Apr 2002 01:13:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:13:57 +0200 (CEST) Received: (qmail 15066 invoked by uid 0); 27 Apr 2002 14:35:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 27 Apr 2002 14:35:27 -0000 Received: by moria.seul.org (Postfix) id 4B20B14685B; Sat, 27 Apr 2002 10:35:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C183146868; Sat, 27 Apr 2002 10:35:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id D57AE14685B for ; Sat, 27 Apr 2002 10:35:25 -0400 (EDT) Received: from ifrance.com (vlt3-243.n.club-internet.fr [194.158.108.243]) by relay-2m.club-internet.fr (Postfix) with ESMTP id B0ACC16BA for ; Sat, 27 Apr 2002 16:35:23 +0200 (CEST) Message-ID: <3CCAABF1.F1C53BDD@ifrance.com> Date: Sat, 27 Apr 2002 15:47:29 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Graham Seaman a écrit : > > On Fri, 26 Apr 2002, Michael Riepe wrote: > > > On Thu, Apr 25, 2002 at 12:01:39PM +0200, Yann Guidon wrote: > > > hello, > > > > > > Michael wrote : > > > > Oh no, not THAT discussion again :-( > > Since the open cores group are currently discussing the same issue, having > run into practical problems with the gpl, would it be a good idea to wait > till they come to a decision then use the SAME license (assuming it is > a reasonable, if not perfect fit to what f-cpu people want), to avoid > getting the same silly proliferation of semi-compatible licenses there is > with software? > Have you the name of the mailling-list ? nicO > Graham > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Apr 27 15:57:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bOJ-0002Jd-00 for ; Sun, 28 Apr 2002 01:14:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:14:07 +0200 (CEST) Received: (qmail 27578 invoked by uid 0); 27 Apr 2002 14:45:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 27 Apr 2002 14:45:11 -0000 Received: by moria.seul.org (Postfix) id BE585146820; Sat, 27 Apr 2002 10:45:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B6004146868; Sat, 27 Apr 2002 10:45:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 68FC3146820 for ; Sat, 27 Apr 2002 10:45:10 -0400 (EDT) Received: from ifrance.com (vlt3-243.n.club-internet.fr [194.158.108.243]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8287916D2 for ; Sat, 27 Apr 2002 16:45:07 +0200 (CEST) Message-ID: <3CCAAE3A.67C4525@ifrance.com> Date: Sat, 27 Apr 2002 15:57:14 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <3CC7D403.6BC46BCD@f-cpu.org> <20020426122704.00354@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Some point to discuss ! Great ! Michael Riepe a écrit : > > On Thu, Apr 25, 2002 at 12:01:39PM +0200, Yann Guidon wrote: > > hello, > > > > Michael wrote : > > > Oh no, not THAT discussion again :-( > > Did you think it was over ? > > Suspended. > > I will change my license at most *once*. Until there is an `F-CPU > Public License' that I can agree on, things will stay the way they > are. > > In order to come to an agreement, we should start to compile a list of > rights and responsibilities users shall have. In particular, they > should be allowed to > > - make verbatim copies of the complete source code > > - distribute verbatim copies of the complete source code > > - make derived works if they release the source code under the > same license Okay that's copyleft. > > - use parts of the source code in their own projects if they > release the source code under the same license and include a > notice that they are using parts of the F-CPU Biip ! That's not permit by the GPL. The GPL FAQ explain that's not possible for a pratical point of view. You must maintain a list of contribution and will become very heavy to manage. That's why there is a new BDB licence without the obligation of the copyright. > > - substitute parts (e.g. gates, flipflops, maybe also memory) > with cells from proprietary cell libraries if it is necessary > in order to produce silicon (they shall, however, fully document > such changes) > That's the very interresting point. Allowed user to rewrite part of the design wihtout distribute the change only to use technological cell's librairy (memroy,...). We must take car that the definition must be clear because it's very easy to create a design, make it a black box and say it come from a "proprietary cell libraries". I don't speak about gate-level which is like the compilition of the work. > - produce silicon and distribute it, as long as they also > deliver the source code for everything but the above mentioned > proprietary cell libraries (the source code for the substituted > components must still be included) > Maybe the fact to sell producte ( a system from the GPL point of view) give the obligation to distribute the code as well. http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem -- I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too. A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make. However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and "incorporating" the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs--but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection. If people were to distribute GPL-covered software calling it "part of" a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear. --- > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Sat Apr 27 18:55:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171bON-0002Jd-00 for ; Sun, 28 Apr 2002 01:14:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 01:14:11 +0200 (CEST) Received: (qmail 7133 invoked by uid 0); 27 Apr 2002 16:55:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 27 Apr 2002 16:55:45 -0000 Received: by moria.seul.org (Postfix) id A3E8114685B; Sat, 27 Apr 2002 12:55:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 94F30146868; Sat, 27 Apr 2002 12:55:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 371BD14685B; Sat, 27 Apr 2002 12:55:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 29F4FFEE31 for ; Sat, 27 Apr 2002 12:55:43 -0400 (EDT) Date: Sat, 27 Apr 2002 12:55:43 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence In-Reply-To: <3CCAABF1.F1C53BDD@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 27 Apr 2002, nico wrote: > Graham Seaman a écrit : > > Since the open cores group are currently discussing the same issue, having > > run into practical problems with the gpl, would it be a good idea to wait > > till they come to a decision then use the SAME license (assuming it is > > a reasonable, if not perfect fit to what f-cpu people want), to avoid > > getting the same silly proliferation of semi-compatible licenses there is > > with software? > > > > Have you the name of the mailling-list ? > To subscribe: cores-request@opencores.org , with word 'subscribe' in body Since the discussion has been going on for a few days, you might want to see the archives: http://www.opencores.org/forums/cores/ Graham > nicO > > > Graham > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 28 02:27:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171rLU-0000G0-00 for ; Sun, 28 Apr 2002 18:16:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 18:16:16 +0200 (CEST) Received: (qmail 22033 invoked by uid 0); 28 Apr 2002 00:27:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Apr 2002 00:27:53 -0000 Received: by moria.seul.org (Postfix) id 4FC3D146868; Sat, 27 Apr 2002 20:27:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4897B1468D9; Sat, 27 Apr 2002 20:27:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id A795F146868 for ; Sat, 27 Apr 2002 20:27:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA03137; Sun, 28 Apr 2002 02:27:47 +0200 Message-ID: <20020428022747.09881@thrai.stud.uni-hannover.de> Date: Sun, 28 Apr 2002 02:27:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some web page References: <1019852435.3cc9b69315330@imp.free.fr> <20020427005907.11816@thrai.stud.uni-hannover.de> <1019907140.3cca8c440de34@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1019907140.3cca8c440de34@imp.free.fr>; from Cedric BAIL on Sat, Apr 27, 2002 at 01:32:20PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 27, 2002 at 01:32:20PM +0200, Cedric BAIL wrote: [...] > > Where does this second version come from, why does it exist, and > Some french guy are currently redrawing a new web site to replace the old ugly > web site. I think that you can see a layout at geeno.free.fr, but if I > correctly remember it's a work in progress. I read something about "1Q2001" - wasn't that more than a year ago? > > what does "will be linked with the opencores project" mean? > Because we will use the same interconnection bus (WISHBONE) as the opencore > project to be able to reuse some of there core. I still wonder who "we" is. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 28 02:43:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171rLV-0000G0-00 for ; Sun, 28 Apr 2002 18:16:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 18:16:17 +0200 (CEST) Received: (qmail 22804 invoked by uid 0); 28 Apr 2002 00:43:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 28 Apr 2002 00:43:09 -0000 Received: by moria.seul.org (Postfix) id 33D37146868; Sat, 27 Apr 2002 20:43:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2FB4F1468D9; Sat, 27 Apr 2002 20:43:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 3A9B7146868 for ; Sat, 27 Apr 2002 20:43:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA03186; Sun, 28 Apr 2002 02:43:05 +0200 Message-ID: <20020428024305.44629@thrai.stud.uni-hannover.de> Date: Sun, 28 Apr 2002 02:43:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <3CC7D403.6BC46BCD@f-cpu.org> <20020426122704.00354@thrai.stud.uni-hannover.de> <3CCAAE3A.67C4525@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CCAAE3A.67C4525@ifrance.com>; from nico on Sat, Apr 27, 2002 at 03:57:14PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Apr 27, 2002 at 03:57:14PM +0200, nico wrote: > Some point to discuss ! Great ! [...] > > - use parts of the source code in their own projects if they > > release the source code under the same license and include a > > notice that they are using parts of the F-CPU > > Biip ! That's not permit by the GPL. The GPL FAQ explain that's not > possible for a pratical point of view. You must maintain a list of > contribution and will become very heavy to manage. That's why there is a > new BDB licence without the obligation of the copyright. Since we're not talking about the GPL but about the (hypothetical) "F-CPU Public License", that shouldn't matter. On the other hand, I don't mind if we drop this point and force people to include either the full package or nothing. What does BDB mean? > > > > - substitute parts (e.g. gates, flipflops, maybe also memory) > > with cells from proprietary cell libraries if it is necessary > > in order to produce silicon (they shall, however, fully document > > such changes) > > > > That's the very interresting point. Allowed user to rewrite part of the > design wihtout distribute the change only to use technological cell's > librairy (memroy,...). We must take car that the definition must be > clear because it's very easy to create a design, make it a black box and > say it come from a "proprietary cell libraries". > > I don't speak about gate-level which is like the compilition of the > work. We can add the restriction that users must provide (under the terms of our License) functionally equivalent VHDL source code for all substituted parts that contain more than single logic gates or "storage elements" (that is, latches, flipflops and RAM cells). > > - produce silicon and distribute it, as long as they also > > deliver the source code for everything but the above mentioned > > proprietary cell libraries (the source code for the substituted > > components must still be included) > > > > Maybe the fact to sell producte ( a system from the GPL point of view) > give the obligation to distribute the code as well. Again, we're not talking about GPL any longer. (Otherwise, we had nothing to talk about, because the GPL is fixed and we're not allowed to change it.) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Apr 28 11:47:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171rLZ-0000G0-00 for ; Sun, 28 Apr 2002 18:16:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 18:16:21 +0200 (CEST) Received: (qmail 28563 invoked by uid 0); 28 Apr 2002 09:46:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 28 Apr 2002 09:46:14 -0000 Received: by moria.seul.org (Postfix) id 560251468F3; Sun, 28 Apr 2002 05:46:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C8181468F5; Sun, 28 Apr 2002 05:46:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id B62D91468F3 for ; Sun, 28 Apr 2002 05:46:08 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix1-2.free.fr (Postfix) with ESMTP id 0F11CAB1A7 for ; Sun, 28 Apr 2002 11:46:07 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 1F460FC67; Sun, 28 Apr 2002 11:47:25 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Some web page Message-ID: <1019987245.3ccbc52d116c9@imp.free.fr> Date: Sun, 28 Apr 2002 11:47:25 +0200 (MEST) From: Cedric BAIL References: <1019852435.3cc9b69315330@imp.free.fr> <20020427005907.11816@thrai.stud.uni-hannover.de> <1019907140.3cca8c440de34@imp.free.fr> <20020428022747.09881@thrai.stud.uni-hannover.de> In-Reply-To: <20020428022747.09881@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.253.245.26 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I read something about "1Q2001" - wasn't that more than a year ago? What is "1Q2001" ? The layout has been designed really recently I think. > > > what does "will be linked with the opencores project" mean? > > Because we will use the same interconnection bus (WISHBONE) as the > > opencore project to be able to reuse some of there core. > I still wonder who "we" is. Oups, you must read : the F-CPU schema use the same interconnection bus as the opencores project... A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Apr 28 11:21:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 171rLc-0000G0-00 for ; Sun, 28 Apr 2002 18:16:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 28 Apr 2002 18:16:24 +0200 (CEST) Received: (qmail 10486 invoked by uid 0); 28 Apr 2002 10:09:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 28 Apr 2002 10:09:49 -0000 Received: by moria.seul.org (Postfix) id B87311468F3; Sun, 28 Apr 2002 06:09:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A43001468F5; Sun, 28 Apr 2002 06:09:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 49BBF1468F3 for ; Sun, 28 Apr 2002 06:09:47 -0400 (EDT) Received: from ifrance.com (vlt9-74.n.club-internet.fr [195.36.223.74]) by relay-2m.club-internet.fr (Postfix) with ESMTP id D30A6168F for ; Sun, 28 Apr 2002 12:09:43 +0200 (CEST) Message-ID: <3CCBBF32.5646C21E@ifrance.com> Date: Sun, 28 Apr 2002 11:21:54 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] The last killing argument FOR the GPL licence References: <200204241527.1b6c@th00.opsion.fr> <3CC7D403.6BC46BCD@f-cpu.org> <20020426122704.00354@thrai.stud.uni-hannover.de> <3CCAAE3A.67C4525@ifrance.com> <20020428024305.44629@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sat, Apr 27, 2002 at 03:57:14PM +0200, nico wrote: > > Some point to discuss ! Great ! > [...] > > > - use parts of the source code in their own projects if they > > > release the source code under the same license and include a > > > notice that they are using parts of the F-CPU > > > > Biip ! That's not permit by the GPL. The GPL FAQ explain that's not > > possible for a pratical point of view. You must maintain a list of > > contribution and will become very heavy to manage. That's why there is a > > new BDB licence without the obligation of the copyright. > > Since we're not talking about the GPL but about the (hypothetical) > "F-CPU Public License", that shouldn't matter. On the other hand, I > don't mind if we drop this point and force people to include either > the full package or nothing. > > What does BDB mean? > A too quick way to type "BSD". ;p > > > > > > - substitute parts (e.g. gates, flipflops, maybe also memory) > > > with cells from proprietary cell libraries if it is necessary > > > in order to produce silicon (they shall, however, fully document > > > such changes) > > > > > > > That's the very interresting point. Allowed user to rewrite part of the > > design wihtout distribute the change only to use technological cell's > > librairy (memroy,...). We must take car that the definition must be > > clear because it's very easy to create a design, make it a black box and > > say it come from a "proprietary cell libraries". > > > > I don't speak about gate-level which is like the compilition of the > > work. > > We can add the restriction that users must provide (under the terms of > our License) functionally equivalent VHDL source code for all substituted > parts that contain more than single logic gates or "storage elements" > (that is, latches, flipflops and RAM cells). > That's a good idea ! > > > - produce silicon and distribute it, as long as they also > > > deliver the source code for everything but the above mentioned > > > proprietary cell libraries (the source code for the substituted > > > components must still be included) > > > > > > > Maybe the fact to sell producte ( a system from the GPL point of view) > > give the obligation to distribute the code as well. > > Again, we're not talking about GPL any longer. (Otherwise, we had > nothing to talk about, because the GPL is fixed and we're not allowed > to change it.) > Yes, you could. As for the first post, you could had "exception". The only thing is to verify that it didn't break something inside the licence. > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 28 15:32:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1721z0-00079l-00 for ; Mon, 29 Apr 2002 05:37:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 29 Apr 2002 05:37:46 +0200 (CEST) Received: (qmail 10391 invoked by uid 0); 28 Apr 2002 19:23:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 28 Apr 2002 19:23:47 -0000 Received: by moria.seul.org (Postfix) id F10E41468D3; Sun, 28 Apr 2002 15:23:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D2682146902; Sun, 28 Apr 2002 15:23:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a049.home.uni-hannover.de [130.75.232.49]) by moria.seul.org (Postfix) with ESMTP id 276AC1468D3 for ; Sun, 28 Apr 2002 15:23:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00511; Sun, 28 Apr 2002 15:32:42 +0200 Message-ID: <20020428153242.55019@thrai.stud.uni-hannover.de> Date: Sun, 28 Apr 2002 15:32:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Some web page References: <1019852435.3cc9b69315330@imp.free.fr> <20020427005907.11816@thrai.stud.uni-hannover.de> <1019907140.3cca8c440de34@imp.free.fr> <20020428022747.09881@thrai.stud.uni-hannover.de> <1019987245.3ccbc52d116c9@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1019987245.3ccbc52d116c9@imp.free.fr>; from Cedric BAIL on Sun, Apr 28, 2002 at 11:47:25AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Apr 28, 2002 at 11:47:25AM +0200, Cedric BAIL wrote: > > I read something about "1Q2001" - wasn't that more than a year ago? > What is "1Q2001" ? The layout has been designed really recently I think. First quarter (January...March) of 2001. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 30 21:11:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 172zId-0004HN-01 for ; Wed, 01 May 2002 20:58:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 01 May 2002 20:57:59 +0200 (CEST) Received: (qmail 15830 invoked by uid 0); 30 Apr 2002 19:05:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 30 Apr 2002 19:05:06 -0000 Received: by moria.seul.org (Postfix) id AC9ED146A84; Tue, 30 Apr 2002 15:05:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8A3C1146A86; Tue, 30 Apr 2002 15:05:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 30D16146A84 for ; Tue, 30 Apr 2002 15:05:03 -0400 (EDT) Received: from f-cpu.org (kdl11-152.n.club-internet.fr [213.44.9.152]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 70EE21742 for ; Tue, 30 Apr 2002 21:04:58 +0200 (CEST) Message-ID: <3CCEEC45.EFCD2A2E@f-cpu.org> Date: Tue, 30 Apr 2002 21:11:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Libre Software Meeting Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, the Libre Software Metting is almost 2 months away and the organisation team presses us for more details and planning. How many people will come ? How many beds to prepare ? What presentations will be made ? Do we need special ressources ? I especially hope that this will be the largest ever F-CPU meeting ever. The last record was 6 people, i wish we can double that. >From Paris/suburbs : Nicole, nicO, Cedric, Paul and myself, potentially one or two more. >From Toulouse : maybe 2 persons. Jürgen Göritz told me he'll try to come, Michael and Graham are not sure. Please prepare your planning, reserve a seat to Bordeaux, the Paris team will probably make a pre-meeting in Paris (prepare the speeches and the rest during a day or two). We hope to make the largest "family picture" ever ! The LSM organisation team needs a figure ASAP : they have to prepare the budget and estimate who and what to reimburse. I will ask for a rebate on the sleeping expense, too (from 10 to 5 Euros per night). Please answer (on this list) as soon as possible ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From E.Fernandez@ukc.ac.uk Wed May 1 12:36:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 172zIs-0004HN-01 for ; Wed, 01 May 2002 20:58:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 01 May 2002 20:58:14 +0200 (CEST) Received: (qmail 10739 invoked by uid 0); 1 May 2002 10:40:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 May 2002 10:40:36 -0000 Received: by moria.seul.org (Postfix) id 557E7146B0D; Wed, 1 May 2002 06:40:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4ED01146B0C; Wed, 1 May 2002 06:40:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by moria.seul.org (Postfix) with ESMTP id 179DC146B09 for ; Wed, 1 May 2002 06:40:34 -0400 (EDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 172rW1-0006DE-00 for f-cpu@seul.org; Wed, 01 May 2002 11:39:17 +0100 Received: from dhcp0dac.ukc.ac.uk ([129.12.13.172] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 172rW1-00077w-00 for f-cpu@seul.org; Wed, 01 May 2002 11:39:17 +0100 Message-ID: <3CCFC52F.ABE6D3FC@ukc.ac.uk> Date: Wed, 01 May 2002 11:36:31 +0100 From: Eric X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Partners/achat d'un portable Mitac Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Bonjour J'aurais ete interesse a acheter un portable Mitac. Malheureusement votre site partners-store.com ne fonctionne pas en ce moment. Savez-vous s'il sera disponible bientot ? En attendant, pouvez-vous me faire parvenir par e-mail une liste de vos offres et leur tarif ? Merci beaucoup Dr Eric Fernandez ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From "investcn2003@yahoo.com.cn" Thu May 2 20:19:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 173Fka-0000G5-01 for ; Thu, 02 May 2002 14:31:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 02 May 2002 14:31:56 +0200 (CEST) Received: (qmail 6863 invoked by uid 0); 2 May 2002 10:19:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 2 May 2002 10:19:40 -0000 Received: by moria.seul.org (Postfix) id 29D2B146923; Thu, 2 May 2002 06:19:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C3BE14692B; Thu, 2 May 2002 06:19:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from moria.seul.org (cm61-15-37-81.hkcable.com.hk [61.15.37.81]) by moria.seul.org (Postfix) with SMTP id B5C09146923 for ; Thu, 2 May 2002 06:19:37 -0400 (EDT) From: "investcn2003@yahoo.com.cn" Date: Thu, 02 May 2002 18:19:42 To: f-cpu@seul.org Subject: [f-cpu] Let's Introduce Your Company To China Government MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_VRZKNLPDQJ" Content-Transfer-Encoding: 7bit Message-ID: PM2000PM 06:19:42 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is an HTML email message. If you see this, your mail client does not support HTML messages. ------=_NextPart_VRZKNLPDQJ Content-Type: text/html;charset="iso-8859-1" Content-Transfer-Encoding: 7bit investcn.biz
Let China Government Gets To Know Your Company
The One and Only B2G Business Directory
(in Simplied Chinese) for the China Government Officials!
First 500 advertisers will get free handbook
The 1000 Billion Purchasing Market Handbook
( How to access China Government Purchasing Market )

InvestCN is pleased to announce that its first China B2G Directory will be published in Oct 2002. This B2G Directory is not for sale. First edition will be published 5000 issues and distributed to : State Development Planning Commission System, Ministries and Commissions under the State Council, Chief Executive Bureau of all Provinces, Cities, and Counties (more than 2000 counties), Organizations directly under the State Council, and Institutions directly under the State Council.

If you are interested to do business with China government,
don't miss out this opportunity.
Advertising and listing spaces will run out fast! First come first served!

By way of background, InvestCN, is a division of China Economic Herald, which is the media bureau of State Development Planning Commission, P.R.China. The main objective of InvestCN is to provide practical, deliverable, workable China investment solutions to investors, bankers, CEOs, CFOs, COOs, decision-making officers, purchasing managers, government officials at all levels around the world.

To reserve your listing on our China B2G Directory, email investcn2003@yahoo.com.cn
THIS IS NOT SPAM, YOU ARE RECEIVING THIS INFORMATION BECAUSE :
A) You submitted a classified ad or link, posted your e-mail address in public commercial domains.
B) You sent email to one of our domains and/or addresses in the past or
C) We are on the same list. If you were not the intended recipient of this
message, Please accept our apologies and delete. If you wish to no longer
receive email from us please send an email message to investcn2003@yahoo.com.cn
with "Remove" placed in the subject line. Thank you.
DISCLAIMER

------=_NextPart_VRZKNLPDQJ-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri May 3 22:41:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 173mR5-0007RU-00 for ; Sat, 04 May 2002 01:25:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 04 May 2002 01:25:59 +0200 (CEST) Received: (qmail 7204 invoked by uid 0); 3 May 2002 20:29:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 3 May 2002 20:29:10 -0000 Received: by moria.seul.org (Postfix) id 277B8146823; Fri, 3 May 2002 16:29:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F025146821; Fri, 3 May 2002 16:29:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id A8C75146815 for ; Fri, 3 May 2002 16:29:08 -0400 (EDT) Received: from ifrance.com (vlt10-30.n.club-internet.fr [195.36.224.30]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 9C6A11770 for ; Fri, 3 May 2002 22:29:06 +0200 (CEST) Message-ID: <3CD2F608.4B638CEA@ifrance.com> Date: Fri, 03 May 2002 22:41:44 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] page managing References: <3CCEEC45.EFCD2A2E@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N They do it ! i propose to do it with edram, 3Dlabs do it in it's new graphic chip : http://www.tomshardware.com/graphic/02q2/020503/p10vpu-04.html They use a paging system but there page are store inside the main DRAM ! They primilary work inside the core with the on board memory. That's crazy ! nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Sat May 4 09:17:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1742OJ-0000xw-00 for ; Sat, 04 May 2002 18:28:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 04 May 2002 18:28:11 +0200 (CEST) Received: (qmail 5223 invoked by uid 0); 4 May 2002 07:17:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 4 May 2002 07:17:58 -0000 Received: by moria.seul.org (Postfix) id 1198E1463AB; Sat, 4 May 2002 03:17:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC7691467E8; Sat, 4 May 2002 03:17:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 5A0561463AB for ; Sat, 4 May 2002 03:17:43 -0400 (EDT) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id KAA27928 for ; Sat, 4 May 2002 10:17:21 +0300 Date: Sat, 4 May 2002 10:17:21 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] page managing In-Reply-To: <3CD2F608.4B638CEA@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > i propose to do it with edram, 3Dlabs do it in it's new graphic chip : > http://www.tomshardware.com/graphic/02q2/020503/p10vpu-04.html edram technology is very expensive and the yields go down. There are even different ways to do edram. Some vendors use digital process and quite big amount of extra masks to build the dram structures (digital process makes the dram density lower). Some vendors use pure dram process and that on the other hand makes the digital logic slower and bigger. And there are only few vendors that support edram. It is difficult technology to master. NRE costs of edram are also quite high, because the needed extra masks. In my mind 1T-SRAM technologies are usually more feasible (Mosys, Ramtron etc.) Also 1T is quite expensive technology and is only supported on some vendors processes (TSMC and UMC are safe bets). --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon May 6 13:51:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 174qdz-0000GT-01 for ; Tue, 07 May 2002 00:07:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 07 May 2002 00:07:43 +0200 (CEST) Received: (qmail 14905 invoked by uid 0); 6 May 2002 11:52:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 6 May 2002 11:52:08 -0000 Received: by moria.seul.org (Postfix) id 31AD3146828; Mon, 6 May 2002 07:52:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C6CC146833; Mon, 6 May 2002 07:52:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 3D17B146828 for ; Mon, 6 May 2002 07:52:05 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200205061151.3618; Mon, 6 May 2002 11:51:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] page managing From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 May 2002 11:51:54 GMT Message-id: <200205061151.3618@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Kim Enkovaara A: f-cpu@seul.org Date: 04/05/02 Objet: Re: [f-cpu] page managing > i propose to do it with edram, 3Dlabs do it in it's new g= raphic chip : > http://www.tomshardware.com/graphic/02q2/020503/p10vpu-04.= html edram technology is very expensive and the yields go down. T= here are even different ways to do edram. Some vendors use digital process= and quite big amount of extra masks to build the dram structures (digital = process makes the dram density lower). Some vendors use pure dram process = and that on the other hand makes the digital logic slower and bigger. An= d there are only few vendors that support edram. It is difficult technol= ogy to master. NRE costs of edram are also quite high, because the needed e= xtra masks. In my mind 1T-SRAM technologies are usually more feasible (Mosy= s, Ramtron etc.) Also 1T is quite expensive technology and is only supp= orted on some vendors processes (TSMC and UMC are safe bets). >>> I'm almost sure that i will change in 2 years ! (When i = say edram, i think of a memory technology that maid easy to put many Mbyt= e inside the chip) For many reasons, edram are a good thing : for pow= er consumption (no more the 100 power transistor to get out of = the chip to access the memory), the board/package will became cheaper (l= ess pins and less wire), for the performance, ... For so many raisons, it will be widely used. L2 cache are th= e first candidate. nicO --Kim ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From marco@simplex.nl Mon May 6 15:15:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 174qe0-0000GT-00 for ; Tue, 07 May 2002 00:07:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 07 May 2002 00:07:44 +0200 (CEST) Received: (qmail 31321 invoked by uid 0); 6 May 2002 13:15:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 6 May 2002 13:15:47 -0000 Received: by moria.seul.org (Postfix) id ACAC9146849; Mon, 6 May 2002 09:15:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA7C9146844; Mon, 6 May 2002 09:15:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by moria.seul.org (Postfix) with ESMTP id 151AF146828 for ; Mon, 6 May 2002 09:15:43 -0400 (EDT) Received: from mfa (cal046201.student.utwente.nl [130.89.164.188]) by netlx009.civ.utwente.nl (8.11.4/HKD) with SMTP id g46DFbd02087 for ; Mon, 6 May 2002 15:15:41 +0200 Message-ID: <002101c1f500$1fbf7250$bca45982@student.utwente.nl> From: "Marco Al" To: References: <200205061151.3618@th00.opsion.fr> Subject: Re: Rep:Re: [f-cpu] page managing Date: Mon, 6 May 2002 15:15:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > I'm almost sure that i will change in 2 years ! (When i say edram, i > think of a memory technology that maid easy to put many Mbyte inside > the chip) For many reasons, edram are a good thing : for power > consumption (no more the 100 power transistor to get out of the chip > to access the memory), the board/package will became cheaper (less pins > and less wire), for the performance, ... > For so many raisons, it will be widely used. L2 cache are the first > candidate. Not for the cheap foundries. They dont have the money to get eDRAM up to the standards of say IBM ... as for really cheap embedded memory, only thin film memory cells can offer that. But Intel seems to have that market pretty much cornered. They might get access to it in a couple of years, and IDM's no doubt will buy into it too ... but again foundries will undoubtedly lag them quite a bit. Marco PS. Im sure its been said before, and you are probably slightly stubborn about it ... but damn your method of quoting sucks, it does not scale well to deep threading ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon May 6 15:20:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 174qe0-0000GT-01 for ; Tue, 07 May 2002 00:07:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 07 May 2002 00:07:44 +0200 (CEST) Received: (qmail 20380 invoked by uid 0); 6 May 2002 13:21:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 6 May 2002 13:21:02 -0000 Received: by moria.seul.org (Postfix) id F236A146828; Mon, 6 May 2002 09:21:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4A3E146844; Mon, 6 May 2002 09:20:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id D3B43146828 for ; Mon, 6 May 2002 09:20:58 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200205061320.2e9e; Mon, 6 May 2002 13:20:46 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] page managing From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 May 2002 13:20:46 GMT Message-id: <200205061320.2e9e@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- Marco PS. Im sure its been said before, and you are probably sligh= tly stubborn about it ... but damn your method of quoting sucks, it does = not scale well to deep threading ;) >>> Sorry, i'm at work and i use a stupid web mailer that on= ly handle that way to answer. nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri May 10 19:42:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 176Hds-00030r-00 for ; Fri, 10 May 2002 23:09:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 10 May 2002 23:09:32 +0200 (CEST) Received: (qmail 27068 invoked by uid 0); 10 May 2002 17:36:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 May 2002 17:36:09 -0000 Received: by moria.seul.org (Postfix) id 0E559146806; Fri, 10 May 2002 13:36:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01376146809; Fri, 10 May 2002 13:36:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 5AA90146806 for ; Fri, 10 May 2002 13:36:06 -0400 (EDT) Received: from f-cpu.org (kdl11-52.n.club-internet.fr [213.44.9.52]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 3358116DA; Fri, 10 May 2002 19:36:00 +0200 (CEST) Message-ID: <3CDC0685.7571A71C@f-cpu.org> Date: Fri, 10 May 2002 19:42:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Cc: f-cpu@seul.org Subject: [f-cpu] forged addresses (was Re: unsubscribe me please!) References: <3CDBDDB4.5000207@kip.uni-heidelberg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, a subscriber wrote: > Please unsubscribe me from the f-cpu mailing list!!! The unsubscription method is contained in the message headers of the posts that go through the list. It says : X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Warning : I have seen some "forged" posts, for example a message from owner-f-cpu@seul.org and f-cpu-approval@seul.org, as well as from a subscriber's address but i AM the maintainer with Paul Mota and we all run virus/worm-safe computers. And there is no reason for the message to come from Russia (look carefully at the headers) because i live in France and the server is in the US. ##### BE VERY CAREFUL ! DON'T USE OUTLOOK ! DISABLE ALL JAVA STUFF ! EXAMINE THE HEADERS ! DON'T SEND HTML POSTS ! ##### Everyone should know this but i write it anyway, Internet is not the cool place it used to be. I am very concerned by the increase in the amount of spam and worms since the last 6 months. It wastes bandwidth and patience, and it is propagated by a minority of people who ignore secure practices. [BTW i am currently building a Linux system "from scratch" and i'll stop using W95 and Netscape as soon as possible. Give me some time to configure everything...] Unfortunately the threats are getting smarter and i have no access to the seul.org server itself, which is maintained by the SEUL team (which uses Linux so it's pretty safe). It already blocks the worms which are larger than 50KB but the things seem to not always pass through the SEUL server, they look as being directly delivered to the subscribers. damnit. I hope that you understand the situation and that you are not angry at the F-CPU project. regards, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat May 11 03:07:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 176byz-0001PF-00 for ; Sat, 11 May 2002 20:52:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 11 May 2002 20:52:41 +0200 (CEST) Received: (qmail 31249 invoked by uid 0); 11 May 2002 01:01:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 11 May 2002 01:01:34 -0000 Received: by moria.seul.org (Postfix) id DE4A01467F2; Fri, 10 May 2002 21:01:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CE0E11467FE; Fri, 10 May 2002 21:01:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 8FCA11467F2 for ; Fri, 10 May 2002 21:01:29 -0400 (EDT) Received: from f-cpu.org (kdl11-4.n.club-internet.fr [213.44.9.4]) by relay-1m.club-internet.fr (Postfix) with ESMTP id BB4AD1693; Sat, 11 May 2002 03:01:22 +0200 (CEST) Message-ID: <3CDC6EE9.C6421DAB@f-cpu.org> Date: Sat, 11 May 2002 03:07:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Riepe Cc: fm Subject: [f-cpu] Worm attack ! (was Re: End third level navigation) References: <3CDC0687.8E0DCD5C@f-cpu.org> <20020511003148.62600@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I forward this to the list because the situation is aggravating. >From what i read in other places, this list is not the only target, it is spreading very fast. Read carefully. Michael Riepe wrote: > On Fri, May 10, 2002 at 07:42:31PM +0200, Yann Guidon wrote: > > hello > > > > michael wrote: > > > > > > i got two messages from your address. > Unlikely. I didn't send anything for days. > But I got spam from Altera that was sent to f-cpu-outgoing :( I had remarked too. Read below for the explanation. It looks like a targetted/"intelligent" attack, because i just got forged addresses from and opencores. a robot is doing this ! It has even posted to the request address, so i just got a log message of the virus sending his HTML to the mailsystem ! of course, *I* was mailbombed because the mailer outputs one error message per line and i got 300KB of error messages... ==================================== I REPEAT : BE VERY CAREFUL ! ==================================== The unprotected mail system seems to be in Russia, as the headers indicates, and they coincide with the other offensive posts. It looks like : Received: (All my server path) Received: from mx1.mail.ru (mx1.mail.ru [194.67.57.11]) by vhost.devcon.net (8.9.2/8.9.2) with ESMTP id WAA15966 for ; Fri, 10 May 2002 22:04:28 +0200 (CEST) Received: from [212.118.94.130] (helo=Hcvspyah) by mx1.mail.ru with smtp (Exim SMTP.1) id 176Gci-00013I-00 for whygee@f-cpu.org; Sat, 11 May 2002 00:04:17 +0400 From: archiver To: whygee@f-cpu.org Subject: Hi,introduction on ADSL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Mn8q66UG31k8YaZ05h5c3 Message-ID: Remark 1 : look at the message-ID and the original IP ! Remark 2 : it is a very targetted attack because the headers are pretty short, only 2 or 3 hops. Hypothesis : it scans through online archives. This is a good assumption because it explains why there is an autoreply from Altera : The worm forged the list's name and the autoreplier answered to us. Altera's mail was not spam, but a side-effect of robots talking to each others and not understanding ... Just like when it talked to the mailing list administrator. * If you have posted, the attack seems to be direct * If you have not posted, there is still the other risk that the message goes through the list. * Do not trust the "from" field > > either someone is forging your address or you have > > been infected, but i doubt that because you make > > your own OS and i doubt you use a russian server... > That mail didn't come from my system. obviously not. > I never send HTML mails, nor .exe files (unless you ask me to do it). > And my Message-ID usually looks like the one above. > > [...] > > It bounced because it is too large. fortunately. > > Yep. Seems to be a virus. Worse ! and i'm even more worried. Be careful, > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon May 13 23:59:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177fCi-0000Fy-01 for ; Tue, 14 May 2002 18:31:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 18:31:12 +0200 (CEST) Received: (qmail 428 invoked by uid 0); 13 May 2002 21:59:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 13 May 2002 21:59:02 -0000 Received: by moria.seul.org (Postfix) id E39D41467FE; Mon, 13 May 2002 17:59:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C207D146801; Mon, 13 May 2002 17:59:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a224.home.uni-hannover.de [130.75.232.224]) by moria.seul.org (Postfix) with ESMTP id A129F1467FE for ; Mon, 13 May 2002 17:58:59 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02153; Mon, 13 May 2002 23:59:00 +0200 Message-ID: <20020513235900.46546@thrai.stud.uni-hannover.de> Date: Mon, 13 May 2002 23:59:00 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New SHL EU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi gang, I have uploaded a new version of my source tree. Have a look at http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20020513.tar.gz The shifter now supports both `semi' and `full' SIMD operations -- that is, `chunk(a) op b' *and* `chunk(a) op chunk(b)'. I also hope that I got the bitrev instruction right this time. It should perform the function `y = rotate_right(bit_reverse(a), chunksize-b-1)'; but one never knows. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 14 01:52:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177fCk-0000Fy-00 for ; Tue, 14 May 2002 18:31:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 18:31:14 +0200 (CEST) Received: (qmail 23839 invoked by uid 0); 13 May 2002 23:46:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 13 May 2002 23:46:11 -0000 Received: by moria.seul.org (Postfix) id 794361467F5; Mon, 13 May 2002 19:46:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5D143146802; Mon, 13 May 2002 19:46:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id DED381467F5 for ; Mon, 13 May 2002 19:46:08 -0400 (EDT) Received: from f-cpu.org (kdl16-12.n.club-internet.fr [213.44.18.12]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 4534116A8 for ; Tue, 14 May 2002 01:46:00 +0200 (CEST) Message-ID: <3CE051C0.634C2899@f-cpu.org> Date: Tue, 14 May 2002 01:52:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New SHL EU References: <20020513235900.46546@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Hi gang, Yeah !!! at last, not a klez stuff !!! > I have uploaded a new version of my source tree. Have a look at > http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20020513.tar.gz ok, i d/l it and i'll have to check it. YEAH ! (bis) > The shifter now supports both `semi' and `full' SIMD operations -- that > is, `chunk(a) op b' *and* `chunk(a) op chunk(b)'. I also hope that I > got the bitrev instruction right this time. It should perform the > function `y = rotate_right(bit_reverse(a), chunksize-b-1)'; but one > never knows. i'll have to check that ASAP... give me some weeks ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue May 14 02:32:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177fCq-0000Fy-00 for ; Tue, 14 May 2002 18:31:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 18:31:20 +0200 (CEST) Received: (qmail 614 invoked by uid 0); 14 May 2002 09:42:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 14 May 2002 09:42:39 -0000 Received: by moria.seul.org (Postfix) id 2A94B1467EF; Tue, 14 May 2002 05:42:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DD111467F1; Tue, 14 May 2002 05:42:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a100.home.uni-hannover.de [130.75.232.100]) by moria.seul.org (Postfix) with ESMTP id 21F781467EF for ; Tue, 14 May 2002 05:42:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02929; Tue, 14 May 2002 02:32:54 +0200 Message-ID: <20020514023254.16374@thrai.stud.uni-hannover.de> Date: Tue, 14 May 2002 02:32:54 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: Re: [f-cpu] New SHL EU References: <20020513235900.46546@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020513235900.46546@thrai.stud.uni-hannover.de>; from Michael Riepe on Mon, May 13, 2002 at 11:59:00PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, May 13, 2002 at 11:59:00PM +0200, I wrote: [...] > The shifter now supports both `semi' and `full' SIMD operations -- that > is, `chunk(a) op b' *and* `chunk(a) op chunk(b)'. I also hope that I > got the bitrev instruction right this time. It should perform the > function `y = rotate_right(bit_reverse(a), chunksize-b-1)'; but one > never knows. ... as I said: one never knows. Of course the function is y = shift_right(bit_reverse(a, chunksize), chunksize-b-1) Instructions summarized (pseudo-C): // In bitwise operations, B is always modulo the chunk size. // That means: // 0 <= B < chunksize // But also: // 0 < B + 1 <= chunksize // 0 < chunksize - B <= chunksize // 0 <= chunksize - B - 1 < chunksize // You've been warned. // In `full-SIMD' mode, B comes from the appropriate chunk. // In `semi-SIMD' mode, B is taken from chunk 0 (zero). // Immediate mode is *always* `semi-SIMD', but that's probably // handled elsewhere (also for addi/subi/muli and so on). (s)shiftl: // regular output: Y = A << B; // alternate output ("leftovers"): // use this for a `double-width' shift Y2 = A >> (chunksize - B); (s)shiftr/(s)shiftra: // regular output: // `shiftra' will duplicate the MSB (signed shift) // `shiftr' zero-fills (unsigned shift) Y = A >> B; // alternate output ("leftovers"): // use this for a `double-width' shift Y2 = A << (chunksize - B); (s)bitrev: // regular output: Y = bit_reverse(A, chunksize) >> (chunksize - B - 1); // alternate output ("leftovers"): // use this for a `double-width' bitrev Y2 = bit_reverse(A, chunksize) << (B + 1); // Notes: // - the SIMD operation `sbitrev' is not yet documented. // - the documented `bitrevo' instruction is not supported. The 2r2w `double-width' shifts need to be documented, assigned opcodes, mode flags and so on. Did we already choose a name for them, BTW? I suggest `(s)dshiftXY' and `(s)dbitrev' (although there's probably not much use for the latter). (s)rotl: // regular output: Y = (A << B) | (A >> (chunksize - B)); // alternate output is currently unused (s)rotr: // regular output: Y = (A >> B) | (A << (chunksize - B)); // alternate output is currently unused If you can find any use for the second output port in the rotl/rotr modes, tell me. Note that it is impossible to perform both rotl and rotr at the same time, however. // In bytewise operations, there is no `semi-SIMD' mode. // There is no `shift count', either :) (s)byterev: // regular output: Y = byterev(A, chunksize); // alternate output (second channel): Y2 = byterev(B, chunksize); sdup: // regular output: Y = sdup(A, chunksize); // alternate output (second channel): Y2 = sdup(B, chunksize); mix: // regular output: Y = mixl(A, B, chunksize); // alternate output: Y2 = mixh(A, B, chunksize); expand: // regular output: Y = expandl(A, B, chunksize); // alternate output: Y2 = expandh(A, B, chunksize); It's not yet clear which source operand is which in the mix and expand instructions. But I can change that easily. I could also tear mixl/mixh and expandl/expandh apart and make them separate instructions, and at the same time restrict byterev and sdup to one channel. That would save some space, but I like it better this way. We should also add 2r2w `mix' and `expand' instructions (but keep the 2r1w versions). The `widen' (integer sign/zero extension) instruction is still missing. I'm not sure whether it was such a good idea. Ok, that's it for now. Have fun, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Tue May 14 19:11:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177iTE-0002jl-00 for ; Tue, 14 May 2002 22:00:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 22:00:28 +0200 (CEST) Received: (qmail 18766 invoked by uid 0); 14 May 2002 17:11:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 14 May 2002 17:11:54 -0000 Received: by moria.seul.org (Postfix) id 801B514681E; Tue, 14 May 2002 13:11:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7AA4314681D; Tue, 14 May 2002 13:11:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 4C4CC146819; Tue, 14 May 2002 13:11:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 4BAA1FEE31 for ; Tue, 14 May 2002 13:11:39 -0400 (EDT) Date: Tue, 14 May 2002 13:11:39 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: [f-cpu] accelerator In-Reply-To: <3CCEEC45.EFCD2A2E@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N http://www10.edatoolscafe.com/nbc/articles/view_article.php?section=CorpNews&articleid=30886 Anyone know how this works? Does it compile bits of a design to FPGA and read back the results to merge with the software simulation? Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 14 20:12:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177iTI-0002jl-00 for ; Tue, 14 May 2002 22:00:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 22:00:32 +0200 (CEST) Received: (qmail 7468 invoked by uid 0); 14 May 2002 18:06:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 14 May 2002 18:06:06 -0000 Received: by moria.seul.org (Postfix) id 2AE2614681A; Tue, 14 May 2002 14:06:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 257AE14681F; Tue, 14 May 2002 14:06:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id DCF7E14681A for ; Tue, 14 May 2002 14:06:02 -0400 (EDT) Received: from f-cpu.org (kdl11-70.n.club-internet.fr [213.44.9.70]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 0586116FE for ; Tue, 14 May 2002 20:06:00 +0200 (CEST) Message-ID: <3CE15397.20BFCBF@f-cpu.org> Date: Tue, 14 May 2002 20:12:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] accelerator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Graham Seaman wrote: http://www10.edatoolscafe.com/nbc/articles/view_article.php?section=CorpNews&articleid=30886 > Anyone know how this works? Does it compile bits of a design to FPGA and > read back the results to merge with the software simulation? i have downloaded what i could get and i'll have to read it. This can be interesting (or not), and my experience at Mentor could prove useful :-) > Graham WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 14 20:33:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177iUF-0002jl-00 for ; Tue, 14 May 2002 22:01:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 14 May 2002 22:01:31 +0200 (CEST) Received: (qmail 24171 invoked by uid 0); 14 May 2002 18:27:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 14 May 2002 18:27:02 -0000 Received: by moria.seul.org (Postfix) id E83D614681D; Tue, 14 May 2002 14:27:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF8B6146820; Tue, 14 May 2002 14:27:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 732BE14681D for ; Tue, 14 May 2002 14:27:00 -0400 (EDT) Received: from f-cpu.org (kdl11-13.n.club-internet.fr [213.44.9.13]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 99CAF17A6 for ; Tue, 14 May 2002 20:26:57 +0200 (CEST) Message-ID: <3CE15880.D2B2C630@f-cpu.org> Date: Tue, 14 May 2002 20:33:36 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] accelerator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Graham Seaman wrote: http://www10.edatoolscafe.com/nbc/articles/view_article.php?section=CorpNews&articleid=30886 > Anyone know how this works? Does it compile bits of a design to FPGA and > read back the results to merge with the software simulation? most interesting is http://www.eedesign.com/news/OEG20020508S0012 it says : - plug-in board for SUN workstation (at least one of the products), i don't know for the other products that are claimed as most efficient on Linux. - it's closely related to Aldec, which explains why they are located in Poland, too (i met polish Aldec techies at DATE2002, and had good relations. I still have to test Riviera but it might be an entry point.) - works with the VHPI interface of proprietary, well-known software but should also work with Aldec. At first i thought : "yet another startup that want to do cheap emulation"... but it can be interesting. > Graham WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed May 15 04:24:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 177xun-0004d8-00 for ; Wed, 15 May 2002 14:29:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 15 May 2002 14:29:57 +0200 (CEST) Received: (qmail 24849 invoked by uid 0); 15 May 2002 02:17:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 15 May 2002 02:17:39 -0000 Received: by moria.seul.org (Postfix) id BEBDA14680E; Tue, 14 May 2002 22:17:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98BC4146828; Tue, 14 May 2002 22:17:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 3FB1714680E for ; Tue, 14 May 2002 22:17:38 -0400 (EDT) Received: from f-cpu.org (kdl11-2.n.club-internet.fr [213.44.9.2]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8A6A117FB for ; Wed, 15 May 2002 04:17:35 +0200 (CEST) Message-ID: <3CE1C6CF.9D8C438F@f-cpu.org> Date: Wed, 15 May 2002 04:24:15 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] accelerator References: <3CE15880.D2B2C630@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N yet some more : http://www.alatek.com/pages/hes/hes_faqs.html#a18 it would be possible to plug the HES board on a RH7.2 PC. it costs some $40K however... There is at least one Virtex and some SDRAM per PCI board : http://www.alatek.com/img/products/hes/HES_Ov11.gif However this FAQ also writes : > All DVM version 2.x and below do not support gated and > divided clocks. A user must manually handle all timing > issues connected with gated and divided clocks, while > implementing them into an FPGA device. maybe the cost could be shared with the VHDL association that is also hosted by EPITA ? :-) The board seems to be possibly delivered with a fully-configured SUN Blade. They also have a "IP cores" page that looks a bit like this at opencollector... http://www.alatek.com/pages/ipcores/ipcores_main.html (just for the similarity). However, Alatek looks more advanced and most cores look too complex for OpenCores' team. WHYGEE, trying to setup his laptop with both sound, PCMCIA and network... USB already works so i don't complain :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu May 16 23:27:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178hHH-0000aC-00 for ; Fri, 17 May 2002 14:56:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 May 2002 14:56:11 +0200 (CEST) Received: (qmail 28682 invoked by uid 0); 16 May 2002 21:57:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 16 May 2002 21:57:11 -0000 Received: by moria.seul.org (Postfix) id B3262146811; Thu, 16 May 2002 17:57:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A78F41468D7; Thu, 16 May 2002 17:57:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a116.home.uni-hannover.de [130.75.232.116]) by moria.seul.org (Postfix) with ESMTP id EFB9F146811 for ; Thu, 16 May 2002 17:57:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA01089; Thu, 16 May 2002 23:27:11 +0200 Message-ID: <20020516232710.51423@thrai.stud.uni-hannover.de> Date: Thu, 16 May 2002 23:27:10 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] A simple SIMD extension for C(++) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I read an old article about the shortcomings of C/C++ the other day. The author complained that there is no way to apply a function to a number of arguments (like the lisp functions `map', `mapcar' & friends do). He didn't mention it, but a `map' function would be valuable for SIMD processors, too: it explicitly tells the compiler that the same function is going to be applied to many arguments in a uniform way. E.g. an instruction like __map__(result_array, function, count, array_1, array_2); (or similar) would be largely equivalent to for (int i = 0; i < count; i++) { result_array[i] = function(array_1[i], array_2[i]); } except that the former may apply the function to the array elements in any order (that is, even in parallel -- exactly what SIMD does). Of course the construct should not be limited to functions with two operands. But the number and element types of the array arguments passed to __map__ must match the prototype of the function. Therefore, __map__ itself can't be implemented as a C function or preprocessor macro. Note that the extension is fully backwards compatible: the compiler may, at its discretion, replace the mapping with a conventional `for' loop without changing the semantics of the program. On the other hand, it can easily find out that ist to be applied to successive elements of and , which enables it to perform SIMD optimizations (and/or loop unrolling) without prior data flow analysis. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri May 17 09:31:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178hHP-0000aC-00 for ; Fri, 17 May 2002 14:56:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 May 2002 14:56:19 +0200 (CEST) Received: (qmail 16429 invoked by uid 0); 17 May 2002 07:32:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 17 May 2002 07:32:10 -0000 Received: by moria.seul.org (Postfix) id 6FD4F14640E; Fri, 17 May 2002 03:32:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 647731468EA; Fri, 17 May 2002 03:32:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id B016A14640E for ; Fri, 17 May 2002 03:32:07 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200205170731.2da7; Fri, 17 May 2002 07:31:45 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] A simple SIMD extension for C(++) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 May 2002 07:31:45 GMT Message-id: <200205170731.2da7@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N In the STL C++ library there is a type called valarray it's = vector of "something" if you apply an operator with it it will be done= value by value as SIMD does ! So such thing could be done for valarray, valarray,... nicO -----Message d'origine----- De: Michael Riepe A: F-CPU Mailing List Date: 16/05/02 Objet: [f-cpu] A simple SIMD extension for C(++) I read an old article about the shortcomings of C/C++ the ot= her day. The author complained that there is no way to apply a function t= o a number of arguments (like the lisp functions `map', `mapcar' & frie= nds do). He didn't mention it, but a `map' function would be valuable= for SIMD processors, too: it explicitly tells the compiler that the s= ame function is going to be applied to many arguments in a uniform way. E= .g. an instruction like __map__(result_array, function, count, array_1, array_2); (or similar) would be largely equivalent to for (int i =3D 0; i < count; i++) { result_array[i] =3D function(array_1[i], array_2[i]); } except that the former may apply the function to the array e= lements in any order (that is, even in parallel -- exactly what SIMD does).= Of course the construct should not be limited to functions with two op= erands. But the number and element types of the array arguments pass= ed to __map__ must match the prototype of the function. Therefore,= __map__ itself can't be implemented as a C function or preprocessor = macro. Note that the extension is fully backwards compatible: the c= ompiler may, at its discretion, replace the mapping with a conventional `= for' loop without changing the semantics of the program. On the other = hand, it can easily find out that ist to be applied to = successive elements of and , which enables it to per= form SIMD optimizations (and/or loop unrolling) without prior data flo= w analysis. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri May 17 13:33:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178hHU-0000aC-00 for ; Fri, 17 May 2002 14:56:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 17 May 2002 14:56:24 +0200 (CEST) Received: (qmail 16872 invoked by uid 0); 17 May 2002 11:31:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 17 May 2002 11:31:11 -0000 Received: by moria.seul.org (Postfix) id 522BA1467E8; Fri, 17 May 2002 07:31:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 32FD214686B; Fri, 17 May 2002 07:31:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id C83DC1467E8 for ; Fri, 17 May 2002 07:31:09 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix1-2.free.fr (Postfix) with ESMTP id 3B326AB22D for ; Fri, 17 May 2002 13:31:09 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id CEF5CFCFC; Fri, 17 May 2002 13:33:46 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Question on SIMD Message-ID: <1021635226.3ce4ea9a7f4a7@imp.free.fr> Date: Fri, 17 May 2002 13:33:46 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I have a problem, that I didn't see before in my dnetc code. I need at the start to add 1 to the first key, 2 to the second, and so on. My current solution is : sdup key, R2 inc.q R2 rotli 32, R2 The problem is that it will work with the 64bits F-CPU but not with bigger version. The first way I see to do that is by doing this in a loop. But that will not work because when I look into our VHDL source I understood that each 64 bits are not connected, so my rotli will only be done on the first chunk, right ? So howto to access to each chunk when we have more than 64 bits registers ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri May 17 19:16:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178pnq-0006RZ-01 for ; Sat, 18 May 2002 00:02:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 May 2002 00:02:22 +0200 (CEST) Received: (qmail 32295 invoked by uid 0); 17 May 2002 17:02:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 17 May 2002 17:02:14 -0000 Received: by moria.seul.org (Postfix) id 066E11468EB; Fri, 17 May 2002 13:02:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE3C61468EE; Fri, 17 May 2002 13:02:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 86E1B1468EB for ; Fri, 17 May 2002 13:02:12 -0400 (EDT) Received: from ifrance.com (vlt3-225.n.club-internet.fr [194.158.108.225]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E98E216C0 for ; Fri, 17 May 2002 19:02:08 +0200 (CEST) Message-ID: <3CE53AD3.3F9C0E2F@ifrance.com> Date: Fri, 17 May 2002 19:16:03 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] A simple SIMD extension for C(++) References: <200205170731.2da7@th00.opsion.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N There is an other potentiel improvement if made several operation on many array. Imagine an mul then an add then accumulation (array added together) it could speed up things if the 3 op will be perform one after an other for each shunk and not cover 3 times the array (to stay inside the cache !) nicO Nicolas Boulay a écrit : > > In the STL C++ library there is a type called valarray it's vector of > "something" if you apply an operator with it it will be done value by > value as SIMD does ! > > So such thing could be done for valarray, valarray,... > > nicO > > -----Message d'origine----- > De: Michael Riepe > A: F-CPU Mailing List > Date: 16/05/02 > Objet: [f-cpu] A simple SIMD extension for C(++) > > I read an old article about the shortcomings of C/C++ the other day. The > author complained that there is no way to apply a function to a number > of arguments (like the lisp functions `map', `mapcar' & friends do). > He didn't mention it, but a `map' function would be valuable for SIMD > processors, too: it explicitly tells the compiler that the same function > is going to be applied to many arguments in a uniform way. E.g. an > instruction like > > __map__(result_array, function, count, array_1, array_2); > > (or similar) would be largely equivalent to > > for (int i = 0; i < count; i++) { > result_array[i] = function(array_1[i], array_2[i]); > } > > except that the former may apply the function to the array elements in > any > order (that is, even in parallel -- exactly what SIMD does). Of course > the construct should not be limited to functions with two operands. > But the number and element types of the array arguments passed to > __map__ must match the prototype of the function. Therefore, __map__ > itself can't be implemented as a C function or preprocessor macro. > > Note that the extension is fully backwards compatible: the compiler may, > at its discretion, replace the mapping with a conventional `for' loop > without changing the semantics of the program. On the other hand, it can > easily find out that ist to be applied to successive > elements of and , which enables it to perform SIMD > optimizations (and/or loop unrolling) without prior data flow analysis. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > ______________________________________________________________________________ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri May 17 12:09:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178pnr-0006RZ-01 for ; Sat, 18 May 2002 00:02:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 May 2002 00:02:23 +0200 (CEST) Received: (qmail 25373 invoked by uid 0); 17 May 2002 19:13:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 17 May 2002 19:13:27 -0000 Received: by moria.seul.org (Postfix) id C67851467F8; Fri, 17 May 2002 15:13:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A7D31467FC; Fri, 17 May 2002 15:13:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a111.home.uni-hannover.de [130.75.232.111]) by moria.seul.org (Postfix) with ESMTP id 721BC1467F8 for ; Fri, 17 May 2002 15:13:22 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00494; Fri, 17 May 2002 12:09:55 +0200 Message-ID: <20020517120955.64092@thrai.stud.uni-hannover.de> Date: Fri, 17 May 2002 12:09:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] A simple SIMD extension for C(++) References: <200205170731.2da7@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200205170731.2da7@th00.opsion.fr>; from Nicolas Boulay on Fri, May 17, 2002 at 07:31:45AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, May 17, 2002 at 07:31:45AM +0000, Nicolas Boulay wrote: > In the STL C++ library there is a type called valarray it's vector of > "something" if you apply an operator with it it will be done value by > value as SIMD does ! > > So such thing could be done for valarray, valarray,... The purpose of the `valarray' template is to make programming easier, while __map__ shall enable the compiler to optimize for SIMD processors, by explicitly marking SIMD-style parallelism. But of course you can use the latter to implement the former :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat May 18 00:57:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 178sv6-0000Fb-00 for ; Sat, 18 May 2002 03:22:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 18 May 2002 03:22:04 +0200 (CEST) Received: (qmail 8084 invoked by uid 0); 17 May 2002 22:59:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 17 May 2002 22:59:33 -0000 Received: by moria.seul.org (Postfix) id 4C7DE14640E; Fri, 17 May 2002 18:59:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 354831467FC; Fri, 17 May 2002 18:59:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a232.home.uni-hannover.de [130.75.232.232]) by moria.seul.org (Postfix) with ESMTP id B00E214640E for ; Fri, 17 May 2002 18:59:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA05310; Sat, 18 May 2002 00:57:52 +0200 Message-ID: <20020518005751.29964@thrai.stud.uni-hannover.de> Date: Sat, 18 May 2002 00:57:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] A simple SIMD extension for C(++) References: <200205170731.2da7@th00.opsion.fr> <3CE53AD3.3F9C0E2F@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CE53AD3.3F9C0E2F@ifrance.com>; from nico on Fri, May 17, 2002 at 07:16:03PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, May 17, 2002 at 07:16:03PM +0200, nico wrote: > There is an other potentiel improvement if made several operation on > many array. As I already said, the number of arrays shall not be limited to 2. This also means that the mapped function can be arbitrary complex. > Imagine an mul then an add then accumulation (array added together) it > could speed up things if the 3 op will be perform one after an other for > each shunk and not cover 3 times the array (to stay inside the cache !) You have two choices: put all operations into a single function and `call' __map__ once, or use individual functions for each operation and map them one after another. The former, however, allows the compiler to perform additional optimization. Since it *knows* that the individual function calls are independent, it can perform them in any order, and it's permitted to do inline substitution, interleave instructions >from different invocations (which is equivalent to loop unrolling) and the like. Accumulation is slightly more difficult, though. You might be tempted to try something like float y = 0.0; float sum(float a) { y += a; } float accumulate(int count, float va[]) { __map__(sum, count, va); return y; } but that's not correct because `y += a' is not quaranteed to be an atomic operation, and the calls to `sum' may be performed in parallel. The solution should look more like float fadd(float a, float b) { return a + b; } float accumulate(int count, float va[]) { // assume count >= 0 if (count < MINCOUNT) { float y = 0.0; for (int i = 0; i < count; i++) { y = fadd(y, va[i]); } return y; } else { int ncount = (count + 1) / 2; float vy[ncount]; __map__(vy, count/2, fadd, va, va + count/2); if (count % 2) { vy[count/2] = va[count-1]; } return accumulate(ncount, vy); } } This version is also more efficient (O(log(n))). We could define a special `__map2__' primitive that applies a binary function to a single array in the same way. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon May 20 01:04:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 179l8s-0002k3-00 for ; Mon, 20 May 2002 13:15:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 20 May 2002 13:15:54 +0200 (CEST) Received: (qmail 2951 invoked by uid 0); 19 May 2002 22:57:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 19 May 2002 22:57:22 -0000 Received: by moria.seul.org (Postfix) id C6EBF1468E2; Sun, 19 May 2002 18:57:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4A8E1468EF; Sun, 19 May 2002 18:57:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 1C5CA1468E2 for ; Sun, 19 May 2002 18:57:20 -0400 (EDT) Received: from f-cpu.org (kdl11-31.n.club-internet.fr [213.44.9.31]) by relay-2m.club-internet.fr (Postfix) with ESMTP id BA8C716E4 for ; Mon, 20 May 2002 00:57:15 +0200 (CEST) Message-ID: <3CE82F65.536C9957@f-cpu.org> Date: Mon, 20 May 2002 01:04:05 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] new manual chapter (?) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i just thought about something that is "obvious" in other environment.... The F-CPU manual lacks a part where the data formats are _defined_ and illustrated. This is usually an introduction to any CPU's ISA manual. - byte, word, dword, qword, - SIMD word, "chunk", and their definition and default settings in the F-CPU programming model - data addressing, endian, alignment... I know i'm lame and i can't do this right now, but it's an important thing that must be done at a time or another... Thanks for your attention, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: there are some interesting threads on comp.arch (as usual) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri May 24 23:50:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17BOxC-00043Y-00 for ; Sat, 25 May 2002 01:58:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 25 May 2002 01:58:38 +0200 (CEST) Received: (qmail 1818 invoked by uid 0); 24 May 2002 21:44:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 24 May 2002 21:44:05 -0000 Received: by moria.seul.org (Postfix) id D446014640E; Fri, 24 May 2002 17:44:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9F031467EE; Fri, 24 May 2002 17:44:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 31B6E14640E for ; Fri, 24 May 2002 17:44:01 -0400 (EDT) Received: from f-cpu.org (kdl11-22.n.club-internet.fr [213.44.9.22]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E6888173E; Fri, 24 May 2002 23:43:53 +0200 (CEST) Message-ID: <3CEEB5BD.5649A8D0@f-cpu.org> Date: Fri, 24 May 2002 23:50:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm , ff Subject: [f-cpu] F-CPU topic at LSM Content-Type: multipart/mixed; boundary="------------E2C3F2E4377186CB02242EFB" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------E2C3F2E4377186CB02242EFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello both lists, here is a preliminary page for http://lsm.abul.org and i would like to have your feedback before doing the french and spanish translations. Note : this file is going to be included by a PHP script, so there is no and tag. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------E2C3F2E4377186CB02242EFB Content-Type: text/html; charset=us-ascii; name="topic10_en.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="topic10_en.html"

Topic 10 : Libre Hardware

Keywords :

  • Freedom CPU
  • copylefted hardware
  • F-CPU
  • Free Hardware
  • microprocessor design
  • VHDL

Motivations :

The F-CPU Project was kindly invited by the LSM team during the Linux Expo 2002 in Paris. Mr Jarillon was enthusiastic and curious about the concept of transposing software concepts (copyleft, distribution) to the Hardware world.

As you can see at the OpenCollector project database, F-CPU is only one of the many projects that develop "soft cores" following the GNU and Linux principles, though each project has specific points of view. The F-CPU team wishes to discuss about them and invites other teams. To emphasize this openness, the topic which was initially named "Libre CPU" is now "Libre Hardware", in order to not sound "F-CPU centric". We believe that we belong to a wider movement, that can be called "Free Hardware" (a counterpart of the "Free Software" movement) or "Open Hardware", depending on one's tastes. If you abide to this trend, you are highly welcome.

During this 5-day meeting, we wish to tighten the links between hardware and software developpers, who often face the same problems and live in the same world. The "Free Software" explosion offers new collaboration opportunities and we can all benefit from them, with a bit of responsibility and good will.

Unfortunately, at this time of writing, no other project has wished to participate and come. If you think that this topic is actually F-CPU centric, it is not the team's fault since nobody answered to our calls for participation.

Activities

There is not yet any schedule for the 5-days gathering. We will follow the general schedule when it comes to the plenary sessions, but expect some loosely timely working sessions and some endless sleepless nights if you're enthusiastic :-D

We hope that as many people as possible can come because we have a lot to do during this short time :

  • We wish we can make a plenary session to introduce the project to newcomers. F-CPU and "Free Hardware" is not an elit's matter and everybody is concerned, especially "Free Software" writers. It is not yet known whether this session will take place, but it will certainly occur in a dedicated room otherwise.
  • The introduction will be followed by more technical presentations for the people who are interested mainly by the hacking side. Demonstrations and hands-on tutorials are also planned but not yet scheduled.
  • We wish to discuss about the licencing issues with the "law" topic. F-CPU currently uses the GNU GPL but it is not adapted to VHDL source code. A F-CPU licence is planned but participation of other Free Hardware projects could help spend less efforts and create a one-fits-all "Free Hardware Licence".
  • Of course, intense working sessions are going to happen : the manual's revamp, the F-CPU source tree reorganisation and many other hot topics will be treated, just like on the mailing lists but faster and with more people.
  • Another hot topic is "How to design Free Hardware source code with the existing tools ?" and we will introduce participants to the use of VHDL tools.
  • The software side of the F-CPU is also an important subtopic : what tools, what approaches and what do we have to rewrite from scratch ? what methods and coding practices are necessary for this 3rd millenium architecture ?
  • Finally, the french "F-CPU association" will hold its first meeting.

You are welcome to propose other topics and present a paper.

What is F-CPU ?

The Freedom CPU project is a distributed, international team of hackers, computer architects and electronicians who have the goal to design a family of microprocessor cores and the necessary basic tools to make it useful.

The programming model of a member of the F-CPU family is SIMD, superpipelined RISC with 64 registers and a simple and orthogonal instruction set. The current core is called "FC0" (it stands for "F-CPU Core 0") and is designed using industry-standard VHDL'93 coding practices and tools.

The design itself is aimed at high configuration, straight-forward retargetting (technological portability), and can be compiled in a similar fashion to a Linux kernel or a GNU tool. All the sources, documentations and utilities are distributed with a copyleft licence which emphasises on unencumbered development practices : patent-free features, widely-used standard conformant sources, freely or easily available tools. Anybody should be able to contribute.

To sum up these principles :

Design and let design.

Linguistic barreers

Most F-CPU contributors are french and it's probable that most discussions will occur in this language. However, most of us are more or less fluent in english so don't hesitate to speak with us, even if you don't speak french. We will be happy to communicate with you.

Links

The homepage of the F-CPU project is located at http://www.f-cpu.org but nobody has had the courage to update it for a while.

The freshest source files and working snapshots can be found at http://f-cpu.seul.org/new. It is a http mirror of a simple ftp site. We are too lazy to make a nice web site and all the volunteers for this task have not done anything more. If you want to help us, you are highly welcome :-)

Administrativia

This page was written ven mai 24 21:57:21 GMT 2002 by Yann Guidon, it is going to evolve at an unpredictable rate. Your comments are welcome. --------------E2C3F2E4377186CB02242EFB-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 3 01:20:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ezdu-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:34 +0200 (CEST) Received: (qmail 20214 invoked by uid 0); 2 Jun 2002 23:12:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 2 Jun 2002 23:12:56 -0000 Received: by moria.seul.org (Postfix) id C58E0146849; Sun, 2 Jun 2002 19:12:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B20FE146850; Sun, 2 Jun 2002 19:12:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 649AC146849 for ; Sun, 2 Jun 2002 19:12:54 -0400 (EDT) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 55F531758 for ; Mon, 3 Jun 2002 01:12:52 +0200 (CEST) Message-ID: <3CFAA82A.4050800@f-cpu.org> Date: Mon, 03 Jun 2002 01:20:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: fm Subject: [f-cpu] new manual, new site... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi ! This is a prototype site. It is currently under debug and will be eventually moved when it is stable enough. I have also included an interesting news for you ! http://f-cpu.tuxfamily.org/ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Mon Jun 3 01:15:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ezdv-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:35 +0200 (CEST) Received: (qmail 20288 invoked by uid 0); 2 Jun 2002 23:15:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 2 Jun 2002 23:15:25 -0000 Received: by moria.seul.org (Postfix) id 5192B14684E; Sun, 2 Jun 2002 19:15:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1406A146859; Sun, 2 Jun 2002 19:15:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id D335E14684E; Sun, 2 Jun 2002 19:15:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id CE874FF247 for ; Sun, 2 Jun 2002 19:15:23 -0400 (EDT) Date: Sun, 2 Jun 2002 19:15:23 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: fm Subject: Re: [f-cpu] new manual, new site... In-Reply-To: <3CFAA82A.4050800@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 3 Jun 2002, Yann Guidon wrote: > Hi ! > > This is a prototype site. > It is currently under debug and will be eventually > moved when it is stable enough. > > I have also included an interesting news for you ! Would that be this piece of news: "Warning: pg_freeresult(): 14 is not a valid PostgreSQL result resource in /data/www/f/-/cpu.tuxfamily.org/php-include/phplib/dbpgsql.php3 on line 170" !!?? :-) Time for more debugging... ;-) Graham > > http://f-cpu.tuxfamily.org/ > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 3 01:35:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ezdv-0000Fl-01 for ; Mon, 03 Jun 2002 23:45:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:35 +0200 (CEST) Received: (qmail 2284 invoked by uid 0); 2 Jun 2002 23:35:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 2 Jun 2002 23:35:40 -0000 Received: by moria.seul.org (Postfix) id B89A9146850; Sun, 2 Jun 2002 19:35:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C3EA146915; Sun, 2 Jun 2002 19:35:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a111.home.uni-hannover.de [130.75.232.111]) by moria.seul.org (Postfix) with ESMTP id 49863146850 for ; Sun, 2 Jun 2002 19:35:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02736; Mon, 3 Jun 2002 01:35:36 +0200 Message-ID: <20020603013536.17334@thrai.stud.uni-hannover.de> Date: Mon, 3 Jun 2002 01:35:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... References: <3CFAA82A.4050800@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CFAA82A.4050800@f-cpu.org>; from Yann Guidon on Mon, Jun 03, 2002 at 01:20:10AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 03, 2002 at 01:20:10AM +0200, Yann Guidon wrote: > This is a prototype site. > It is currently under debug and will be eventually > moved when it is stable enough. > > I have also included an interesting news for you ! Unfortunately, I need a translation to {english,german} again... If you don't want me to quit the project, you'd better start speaking to me in a language that I can understand. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jun 3 01:54:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Eze8-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:48 +0200 (CEST) Received: (qmail 9316 invoked by uid 0); 2 Jun 2002 23:55:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 2 Jun 2002 23:55:28 -0000 Received: by moria.seul.org (Postfix) id D977A146915; Sun, 2 Jun 2002 19:55:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C34F0146925; Sun, 2 Jun 2002 19:55:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 7E326146915 for ; Sun, 2 Jun 2002 19:55:26 -0400 (EDT) Received: from ifurita (213.44.146.154) by smtp.laposte.net (5.5.044) id 3CF4B4D400040D31 for f-cpu@seul.org; Mon, 3 Jun 2002 01:53:46 +0200 Message-ID: <006d01c20a90$da7eb2e0$9a922cd5@ifurita> From: "Christophe" To: References: <3CFAA82A.4050800@f-cpu.org> <20020603013536.17334@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] new manual, new site... Date: Mon, 3 Jun 2002 01:54:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N For the moment there is no real important news except that we have a more featuring website for the project and that Cédric releases source archives and pdf files for the F-CPU manual ver. 0-2-5. But you're right, we should try to speak as english as possible if we would like for that website to be expected to be read by no-french-speaking people. :) ----- Original Message ----- From: Michael Riepe To: Sent: Monday, June 03, 2002 1:35 AM Subject: Re: [f-cpu] new manual, new site... > On Mon, Jun 03, 2002 at 01:20:10AM +0200, Yann Guidon wrote: > > > This is a prototype site. > > It is currently under debug and will be eventually > > moved when it is stable enough. > > > > I have also included an interesting news for you ! > > Unfortunately, I need a translation to {english,german} again... > > If you don't want me to quit the project, you'd better start speaking > to me in a language that I can understand. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 3 02:48:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Eze9-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:49 +0200 (CEST) Received: (qmail 1217 invoked by uid 0); 3 Jun 2002 00:41:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 3 Jun 2002 00:41:27 -0000 Received: by moria.seul.org (Postfix) id D0838146920; Sun, 2 Jun 2002 20:41:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5E9C146928; Sun, 2 Jun 2002 20:41:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id DB253146920 for ; Sun, 2 Jun 2002 20:41:24 -0400 (EDT) Received: from f-cpu.org (kdl16-31.n.club-internet.fr [213.44.18.31]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 7335016A6 for ; Mon, 3 Jun 2002 02:41:21 +0200 (CEST) Message-ID: <3CFABCE6.2060709@f-cpu.org> Date: Mon, 03 Jun 2002 02:48:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... References: <3CFAA82A.4050800@f-cpu.org> <20020603013536.17334@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N good evening, Michael Riepe wrote: > On Mon, Jun 03, 2002 at 01:20:10AM +0200, Yann Guidon wrote: > >> This is a prototype site. >> It is currently under debug and will be eventually >> moved when it is stable enough. >> >> I have also included an interesting news for you ! > > Unfortunately, I need a translation to {english,german} again... > > If you don't want me to quit the project, you'd better start speaking > to me in a language that I can understand. mmm sorry : the question of langage is not yet debated. doing a site that reads both english and french (and why not german) is always going to raise problems ("what does he says on the other page ?"). This is not intentional and since a lot of activity recently took place on the french mailing list, i did not take enough care. I was carried away by the fact that a site _works_... Anyway, as written before, this site is still experimental. Feel free to use it, configure it, report bugs and whatever. I guess that the langage problem is not going to be solved soon (problems of segregation, misunderstandings etc.) but we currently work with 2 mailing lists already, it's not hopeless. It's only the beginning. Christophe wrote: > For the moment there is no real important news except that we have a more > featuring website for the project and that Cédric releases source archives and > pdf files for the F-CPU manual ver. 0-2-5. > > But you're right, we should try to speak as english as possible if we would > like for that website to be expected to be read by no-french-speaking people. :) As you can see, whatever is written in french will rise the same question from a non-french speaking person. OTOH, some discussions will have no point in english, for example for the french association. I fear we opened another big can of smelly worms... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 3 03:34:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Eze9-0000Fl-01 for ; Mon, 03 Jun 2002 23:45:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:49 +0200 (CEST) Received: (qmail 28164 invoked by uid 0); 3 Jun 2002 01:27:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 3 Jun 2002 01:27:40 -0000 Received: by moria.seul.org (Postfix) id 022D7146928; Sun, 2 Jun 2002 21:27:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE23314692A; Sun, 2 Jun 2002 21:27:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 91F4A146928 for ; Sun, 2 Jun 2002 21:27:38 -0400 (EDT) Received: from f-cpu.org (kdl14-11.n.club-internet.fr [213.44.12.11]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 8BCD916CE; Mon, 3 Jun 2002 03:27:36 +0200 (CEST) Message-ID: <3CFAC7BD.6020505@f-cpu.org> Date: Mon, 03 Jun 2002 03:34:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: fm Subject: [f-cpu] LSM site is now complete Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N http://lsm.abul.org/program/topic10/ All 3 langages are now up to date. it is waiting for your comments and ideas. bye, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Mon Jun 3 09:04:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17EzeG-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:56 +0200 (CEST) Received: (qmail 3720 invoked by uid 0); 3 Jun 2002 07:02:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 3 Jun 2002 07:02:47 -0000 Received: by moria.seul.org (Postfix) id A606E14680D; Mon, 3 Jun 2002 03:02:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B31314692E; Mon, 3 Jun 2002 03:02:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 2EDF214680D for ; Mon, 3 Jun 2002 03:02:41 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17Elsp-0000lb-00 for f-cpu@seul.org; Mon, 3 Jun 2002 09:04:03 +0200 Date: Mon, 3 Jun 2002 09:04:02 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... In-Reply-To: <3CFABCE6.2060709@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, You know what? The language problem will be with us for quite a while anyway. We are living in Europe and this area is bound to solve language problems. Just wait 'til Poland and Turkey enter the EU... ;) Cheers JG P.S. There are some automatic language translators out there in the internet. It works for a friend with english/russian translations but don't know how good it is on technical things. On Mon, 3 Jun 2002, Yann Guidon wrote: >good evening, > >Michael Riepe wrote: > >> On Mon, Jun 03, 2002 at 01:20:10AM +0200, Yann Guidon wrote: >>=20 >>> This is a prototype site. >>> It is currently under debug and will be eventually >>> moved when it is stable enough. >>>=20 >>> I have also included an interesting news for you ! >>=20 >> Unfortunately, I need a translation to {english,german} again... >>=20 >> If you don't want me to quit the project, you'd better start speaking >> to me in a language that I can understand. > >mmm sorry : the question of langage is not yet debated. > >doing a site that reads both english and french (and why not german) >is always going to raise problems ("what does he says on the other >page ?"). This is not intentional and since a lot of activity >recently took place on the french mailing list, i did not >take enough care. I was carried away by the fact that a site >_works_... > > >Anyway, as written before, this site is still experimental. >Feel free to use it, configure it, report bugs and whatever. >I guess that the langage problem is not going to be solved >soon (problems of segregation, misunderstandings etc.) >but we currently work with 2 mailing lists already, >it's not hopeless. It's only the beginning. > > >Christophe wrote: > > For the moment there is no real important news except that we have a mo= re > > featuring website for the project and that C=E9dric releases source arc= hives and > > pdf files for the F-CPU manual ver. 0-2-5. > > > > But you're right, we should try to speak as english as possible if we w= ould > > like for that website to be expected to be read by no-french-speaking p= eople. :) > >As you can see, whatever is written in french will rise the same >question from a non-french speaking person. OTOH, some discussions >will have no point in english, for example for the french association. > >I fear we opened another big can of smelly worms... > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jun 3 09:54:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17EzeI-0000Fl-00 for ; Mon, 03 Jun 2002 23:45:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:45:58 +0200 (CEST) Received: (qmail 12398 invoked by uid 0); 3 Jun 2002 07:54:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 3 Jun 2002 07:54:17 -0000 Received: by moria.seul.org (Postfix) id 4F09D1462F9; Mon, 3 Jun 2002 03:54:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C593146804; Mon, 3 Jun 2002 03:54:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 98F551462F9 for ; Mon, 3 Jun 2002 03:54:13 -0400 (EDT) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17EmfJ-0001mX-00 for f-cpu@seul.org; Mon, 03 Jun 2002 09:54:09 +0200 Date: Mon, 3 Jun 2002 09:54:09 +0200 (CEST) From: Martin Devera To: fm Subject: Re: [f-cpu] new manual, new site... In-Reply-To: <3CFAA82A.4050800@f-cpu.org> Message-ID: References: <3CFAA82A.4050800@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Unfortunately in French only :( So that what are these news in English ? ;-) devik On Mon, 3 Jun 2002, Yann Guidon wrote: > Hi ! > > This is a prototype site. > It is currently under debug and will be eventually > moved when it is stable enough. > > I have also included an interesting news for you ! > > http://f-cpu.tuxfamily.org/ > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jun 3 15:56:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17EzeL-0000Fl-01 for ; Mon, 03 Jun 2002 23:46:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:46:01 +0200 (CEST) Received: (qmail 3468 invoked by uid 0); 3 Jun 2002 14:05:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 3 Jun 2002 14:05:24 -0000 Received: by moria.seul.org (Postfix) id A13F214684E; Mon, 3 Jun 2002 10:05:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 838AB146915; Mon, 3 Jun 2002 10:05:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id CB34C14684E for ; Mon, 3 Jun 2002 10:05:22 -0400 (EDT) Received: (qmail 76289 invoked by uid 85); 3 Jun 2002 14:09:09 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.332099 secs); 03 Jun 2002 14:09:09 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 3 Jun 2002 14:09:09 -0000 Message-ID: <3CFB7593.1020803@yahoo.fr> Date: Mon, 03 Jun 2002 15:56:35 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... References: <3CFAA82A.4050800@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi 2 ! Some comment on the new site. I have try to connect, but because I have crashed my laptop I have lost my old f-cpu password. When I have try to remember it, I have obtain an error message (not found). Then I need use the backward function to come back on home/login page. I have then recreate a new account, and after the last step I need an other time use the backward function to go back on home page and try to connect. After connection, I try to see my account/comment, and on the resulting page, I couldn't find link to come back on f-cpu homepage. In conclusion, it seems missing some hyperlink to help the navigation between the different section of the site. @+ Just an Illusion Yann Guidon wrote: > Hi ! > > This is a prototype site. > It is currently under debug and will be eventually > moved when it is stable enough. > > I have also included an interesting news for you ! > > http://f-cpu.tuxfamily.org/ > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jun 3 16:11:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17EzeM-0000Fl-00 for ; Mon, 03 Jun 2002 23:46:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:46:02 +0200 (CEST) Received: (qmail 496 invoked by uid 0); 3 Jun 2002 14:44:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 3 Jun 2002 14:44:38 -0000 Received: by moria.seul.org (Postfix) id 3D18714691E; Mon, 3 Jun 2002 10:44:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F15DF146922; Mon, 3 Jun 2002 10:44:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id A139714691E for ; Mon, 3 Jun 2002 10:44:36 -0400 (EDT) Received: from ifurita (212.194.248.242) by smtp.laposte.net (5.5.044) id 3CF4B3130005FCE1 for f-cpu@seul.org; Mon, 3 Jun 2002 16:44:35 +0200 Message-ID: <009401c20b0d$4aac9560$f2f8c2d4@ifurita> From: "Christophe" To: References: <3CFAA82A.4050800@f-cpu.org> Subject: Re: [f-cpu] new manual, new site... Date: Mon, 3 Jun 2002 16:11:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I was wondering the same thing too ;-). All except Whygee's news are english ;-P. ----- Original Message ----- From: Martin Devera To: fm Sent: Monday, June 03, 2002 9:54 AM Subject: Re: [f-cpu] new manual, new site... > Unfortunately in French only :( So that what are these > news in English ? ;-) > devik > > On Mon, 3 Jun 2002, Yann Guidon wrote: > > > Hi ! > > > > This is a prototype site. > > It is currently under debug and will be eventually > > moved when it is stable enough. > > > > I have also included an interesting news for you ! > > > > http://f-cpu.tuxfamily.org/ > > > > WHYGEE > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 3 04:23:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17EzeM-0000Fl-01 for ; Mon, 03 Jun 2002 23:46:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 03 Jun 2002 23:46:02 +0200 (CEST) Received: (qmail 22319 invoked by uid 0); 3 Jun 2002 17:03:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 3 Jun 2002 17:03:56 -0000 Received: by moria.seul.org (Postfix) id 7A70D146920; Mon, 3 Jun 2002 13:03:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69225146923; Mon, 3 Jun 2002 13:03:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a171.home.uni-hannover.de [130.75.232.171]) by moria.seul.org (Postfix) with ESMTP id BF675146920 for ; Mon, 3 Jun 2002 13:03:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA03175; Mon, 3 Jun 2002 04:23:10 +0200 Message-ID: <20020603042310.11143@thrai.stud.uni-hannover.de> Date: Mon, 3 Jun 2002 04:23:10 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] manual 0.2.5 quirks Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I'm currently busy with something different (in case you're nosy: symbolic verification of the F-CPU execution units) but I stopped to have a look at the PDF version of the latest manual... ... and I still found some quirks in the instruction set part: - Register naming is inconsistent in sub and div: sub r3, r2, r1 => r1 = r2 - r3 div r3, r2, r1 => r1 = r3 / r2 The `sub' variant is more logical. - The current ASU sets the `borrow' register to 1, not -1. See vhdl/eu_asu/iadd.vhdl, line 344ff. - The description of `subi' is wrong (registers swapped): subi imm8, r2, r1 => r2 = r1 - imm8 In general, i and should be consistent. That is, the instruction is supposed to calculate `r1 = r2 - imm8'. - Registers swapped in `mod' description. Should read: r1 = r2 % r3 BTW: What this instruction really computes is the *remainder* of the division r2 / r3, *not* the modulus (this makes a difference when the operands are signed numbers). It therefore should be called `rem', not `mod'. Analogously, `divm' should be called `divr', or maybe `divrem' (just like `addsub'). And while we're at it, `sort' could have `minmax' as an alias (since that's what it does: compute the minimum and maximum of its operands at the same time). - The `alternate result register' is still named `r1+1' throughout the manual. Didn't we change that to `r1^1'? - The description if `cmpl' is missing: r1 = r2 < r3 ? -1 : 0 - With all compare/max/sort instructions, the reference to IEEE floating-point is misleading. Even if the instructions work with signed integers, they will NEVER compare IEEE floats correctly. Adding signed integer comparision, on the other hand, should not be too hard (remember: just invert both sign bits before comparision). - Same for cmple (except that it performs: r1 = r2 <= r3 ? -1 : 0) - Syntax for `scmpli' and `scmplei' is wrong. Where did the immediate operand go? The descriptions are missing, too. - The `bitop' instruction is still listed with the bit shuffling ops, and contains a reference to the SHL unit. We *could* make this true, but that means we'll have to add a pipeline stage to the SHL unit (or route the output to the ROP2 unit, which will take an extra Xbar cycle). IIRC we decided that the function (F) is be encoded in the opcode, and that the immediate for bitopi should be 8 bits wide. The correct descriptions are: bitop r3, r2, r1 => r1 = F(r2, 1 << r3) bitopi imm8, r2, r1 => r1 = F(r2, 1 << imm8) - The `bitrev' instruction performs: bitrev r3, r2, r1 => r1 = reverse(r2) >> (size - r3 % size - 1) or, if you like that better: bitrev r3, r2, r1 => r1 = reverse(r2) >> (~r3 % size) That is, you always get ((r3 % size) + 1) result bits. The two-operand form (r3 = 0) makes no sense; it's essentially the same as `andi 1, r2, r1'. The -o suffix is unsupported unless we add a pipeline stage to the SHL unit (or similar, see `bitop'). The SIMD variant `sbitrev' is undocumented. Is it really useless? - The double-word shifts are missing. We currently have dshiftl r3, r2, r1 => r1 = r2 << r3 r1^1 = r2 >> (size - r3) (*) dshiftr r3, r2, r1 => r1 = (unsigned)r2 >> r3 r1^1 = r2 << (size - r3) (*) dshiftra r3, r2, r1 => r1 = (signed)r2 >> r3 r1^1 = r2 << (size - r3) (*) dbitrev r3, r2, r1 => r1 = reverse(r2) >> (size - r3 % size - 1) r1^1 = reverse(r2) << (r3 % size + 1) (*) (immediate and SIMD versions also available). (*) result will be zero if the shift count equals the chunk size. - The sshift*/srot*/sbitrev ops are available in `full-SIMD' and `half-SIMD' modes. The latter performs an implicit `sdup' on the shift count. The manual should state which is which (and also mention the other variant if we're going to support it). - In the drawings for mix/expand, it's still not clear whether `source #1' is r2 and `source #2' is r3, or vice versa. I suggest that the least significant chunk of the result should always come from r2 (that is, source #1 is r2 and source #2 is r3). - In the description of the logic operators, the registers are named inconsistently with the rest of the manual (r3 is destination). F is be encoded in the opcode in 3-bit form, and the immediate for `logici' is 8 bits wide (see `bitop' above). It's still not clear which operand is inverted when `andn' or `orn' is performed (I suggest r3, for symmetry). And finally: there is no `not' instruction. - Floating-point compare is completely broken. With IEEE floats, two numbers can be less, equal or greater with respect to each other, but they can also be *unordered* (if one or both of them is NaN). To make things even more complicated, +0.0 and -0.0 compare equal, although they have different representations, while NaNs *never* compare equal even if their representations are identical. - `fdiv' calculates r1 = r2 / r3, NOT r1 = r3 / r2. - `fsqrt' has only two operands: r1 = fsqrt(r2). - `flog'/`fexp' still have three-operand form which requires you to preload the logarithm's base into r3. If we *really* need three-operand forms, they should calculate something like r1 = log2(r2) / r3 and r1 = exp2(r2 * r3) with two-operand forms that implicitly set r3 to 1.0. If you set r3 to log2(n), you'll get log(x) and **x (for n > 0.0) without making the implementation of log() and exp() more complex than necessary. - `faddsub' is supposed to calculate r2 + r3 and r2 - r3 (NOT r3 - r2). - `move r0, r0' is no longer an alias for `nop'. There is a real `nop' instruction (opcode 0) now, and `move' has a different opcode. The textual description claims that `r2 is copied to r3', but the target is r1. - While I suggested that `loadcons imm, r1' should be an assembler shortcut for a sequence of `loadcons.n imm16, r1' instructions, I didn't mean that the constant to load *must* be 64 bits wide. If it's only 32 bits wide, the assembler might use a shorter instruction sequence (e.g. a loadcons followed by a loadconsx). The difference between `loadcons imm, r1' and `loadconsx imm, r1' should be that the assembler sign-extends the constant in the latter case. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 3 20:17:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17F3T6-0002vj-00 for ; Tue, 04 Jun 2002 03:50:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Jun 2002 03:50:40 +0200 (CEST) Received: (qmail 21990 invoked by uid 0); 3 Jun 2002 22:18:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 3 Jun 2002 22:18:13 -0000 Received: by moria.seul.org (Postfix) id B72DE146922; Mon, 3 Jun 2002 18:18:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E3E8146936; Mon, 3 Jun 2002 18:18:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 28D9D146922 for ; Mon, 3 Jun 2002 18:18:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01326; Mon, 3 Jun 2002 20:17:01 +0200 Message-ID: <20020603201701.63222@thrai.stud.uni-hannover.de> Date: Mon, 3 Jun 2002 20:17:01 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... References: <3CFAA82A.4050800@f-cpu.org> <20020603013536.17334@thrai.stud.uni-hannover.de> <3CFABCE6.2060709@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3CFABCE6.2060709@f-cpu.org>; from Yann Guidon on Mon, Jun 03, 2002 at 02:48:38AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 03, 2002 at 02:48:38AM +0200, Yann Guidon wrote: [...] > mmm sorry : the question of langage is not yet debated. There *is* nothing to debate. [...] > I fear we opened another big can of smelly worms... [en] Yes! [fr] Oui! [es] ¡Si! [it] Si! [ru] Da! [cn] shì de! [de] Worauf Du einen lassen kannst! -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 3 19:26:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17F3T7-0002vj-00 for ; Tue, 04 Jun 2002 03:50:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Jun 2002 03:50:41 +0200 (CEST) Received: (qmail 15273 invoked by uid 0); 3 Jun 2002 22:18:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 3 Jun 2002 22:18:17 -0000 Received: by moria.seul.org (Postfix) id 51CDB146936; Mon, 3 Jun 2002 18:18:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24808146938; Mon, 3 Jun 2002 18:18:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 9B9BC146936 for ; Mon, 3 Jun 2002 18:18:14 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01081; Mon, 3 Jun 2002 19:26:46 +0200 Message-ID: <20020603192646.52302@thrai.stud.uni-hannover.de> Date: Mon, 3 Jun 2002 19:26:46 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... References: <3CFABCE6.2060709@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Mon, Jun 03, 2002 at 09:04:02AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 03, 2002 at 09:04:02AM +0200, Juergen Goeritz wrote: [...] > P.S. There are some automatic language translators out there > in the internet. It works for a friend with english/russian > translations but don't know how good it is on technical things. You mean, like babelfish? Forget it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jun 4 06:50:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17FH2E-0000Fy-00 for ; Tue, 04 Jun 2002 18:19:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Jun 2002 18:19:50 +0200 (CEST) Received: (qmail 3665 invoked by uid 0); 4 Jun 2002 04:54:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Jun 2002 04:54:29 -0000 Received: by moria.seul.org (Postfix) id 3FDC714693C; Tue, 4 Jun 2002 00:54:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01ADF14693E; Tue, 4 Jun 2002 00:54:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 779E914693C for ; Tue, 4 Jun 2002 00:54:24 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17F6HA-0001xf-00 for f-cpu@seul.org; Tue, 4 Jun 2002 06:50:32 +0200 Date: Tue, 4 Jun 2002 06:50:32 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] new manual, new site... In-Reply-To: <20020603201701.63222@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, 3 Jun 2002, Michael Riepe wrote: >On Mon, Jun 03, 2002 at 02:48:38AM +0200, Yann Guidon wrote: >[...] >> mmm sorry : the question of langage is not yet debated. > >There *is* nothing to debate. > >[...] >> I fear we opened another big can of smelly worms... > >[en] Yes! >[fr] Oui! >[es] =A1Si! >[it] Si! >[ru] Da! >[cn] sh=EC de! >[de] Worauf Du einen lassen kannst! [us] shit! JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Jun 4 13:00:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17FH2O-0000Fy-01 for ; Tue, 04 Jun 2002 18:20:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Jun 2002 18:20:00 +0200 (CEST) Received: (qmail 6769 invoked by uid 0); 4 Jun 2002 10:59:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Jun 2002 10:59:46 -0000 Received: by moria.seul.org (Postfix) id 3EADF146941; Tue, 4 Jun 2002 06:59:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F71D146943; Tue, 4 Jun 2002 06:59:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id D19FD146941 for ; Tue, 4 Jun 2002 06:59:43 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-1.free.fr (Postfix) with ESMTP id 42C255A8 for ; Tue, 4 Jun 2002 12:59:42 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 77639FCD1; Tue, 4 Jun 2002 13:00:35 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] manual 0.2.5 quirks Message-ID: <1023188435.3cfc9dd3456d2@imp.free.fr> Date: Tue, 04 Jun 2002 13:00:35 +0200 (MEST) From: Cedric BAIL References: <20020603042310.11143@thrai.stud.uni-hannover.de> In-Reply-To: <20020603042310.11143@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Quoting Michael Riepe : > I'm currently busy with something different (in case you're nosy: > symbolic verification of the F-CPU execution units) but I stopped to > have a look at the PDF version of the latest manual... > > ... and I still found some quirks in the instruction set part: I will update the manual as quick as possible with your recommandation. If somebody have another recommandation, it's the time to say them. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jun 4 15:34:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17FH2P-0000Fy-01 for ; Tue, 04 Jun 2002 18:20:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 04 Jun 2002 18:20:01 +0200 (CEST) Received: (qmail 23159 invoked by uid 0); 4 Jun 2002 13:27:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Jun 2002 13:27:30 -0000 Received: by moria.seul.org (Postfix) id 479F614680A; Tue, 4 Jun 2002 09:27:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 34769146832; Tue, 4 Jun 2002 09:27:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id E338F14680A for ; Tue, 4 Jun 2002 09:27:28 -0400 (EDT) Received: from f-cpu.org (kdl11-64.n.club-internet.fr [213.44.9.64]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A820F17C1 for ; Tue, 4 Jun 2002 15:27:26 +0200 (CEST) Message-ID: <3CFCC1F6.5090703@f-cpu.org> Date: Tue, 04 Jun 2002 15:34:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] manual 0.2.5 quirks References: <20020603042310.11143@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > I'm currently busy with something different (in case you're nosy: > symbolic verification of the F-CPU execution units) but I stopped to > have a look at the PDF version of the latest manual... > > .... and I still found some quirks in the instruction set part: > > - Register naming is inconsistent in sub and div: > > sub r3, r2, r1 => r1 = r2 - r3 > div r3, r2, r1 => r1 = r3 / r2 > > The `sub' variant is more logical. For the division, the divisor should be R3 so we can easily catch division by zero. > - The current ASU sets the `borrow' register to 1, not -1. > See vhdl/eu_asu/iadd.vhdl, line 344ff. do you number lines in hexa ? > - The description of `subi' is wrong (registers swapped): > > subi imm8, r2, r1 => r2 = r1 - imm8 > > In general, i and should be consistent. That is, the > instruction is supposed to calculate `r1 = r2 - imm8'. sure. > - The `alternate result register' is still named `r1+1' throughout the > manual. Didn't we change that to `r1^1'? right too. i'll try to assist Cedric when he updates it. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jun 4 23:35:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17FOlN-000619-01 for ; Wed, 05 Jun 2002 02:34:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Jun 2002 02:34:57 +0200 (CEST) Received: (qmail 29019 invoked by uid 0); 4 Jun 2002 21:27:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 4 Jun 2002 21:27:51 -0000 Received: by moria.seul.org (Postfix) id 0DD881467EE; Tue, 4 Jun 2002 17:27:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7D8A1467F1; Tue, 4 Jun 2002 17:27:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 1C1CD1467EE for ; Tue, 4 Jun 2002 17:27:49 -0400 (EDT) Received: from f-cpu.org (kdl11-52.n.club-internet.fr [213.44.9.52]) by relay-2m.club-internet.fr (Postfix) with ESMTP id E29DE17FD; Tue, 4 Jun 2002 23:27:43 +0200 (CEST) Message-ID: <3CFD3288.3060205@f-cpu.org> Date: Tue, 04 Jun 2002 23:35:04 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: fm Subject: [f-cpu] LSM pages now ready Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N All 3 langages are now setup. http://lsm.abul.org/program/topic10/topic10.php3?langnew=en http://lsm.abul.org/program/topic10/topic10.php3?langnew=es http://lsm.abul.org/program/topic10/topic10.php3?langnew=fr And now... we have to add the real contents. Apart from Jiri Gaisler's negative answer, i have not received _any_ answer to my call for paper. It looks like F-CPU will be quite alone (as usual...). WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jun 4 16:28:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17FOlO-000619-00 for ; Wed, 05 Jun 2002 02:34:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 05 Jun 2002 02:34:58 +0200 (CEST) Received: (qmail 9757 invoked by uid 0); 4 Jun 2002 22:25:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 4 Jun 2002 22:25:19 -0000 Received: by moria.seul.org (Postfix) id 504461467F1; Tue, 4 Jun 2002 18:25:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3352A146942; Tue, 4 Jun 2002 18:25:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a179.home.uni-hannover.de [130.75.232.179]) by moria.seul.org (Postfix) with ESMTP id C57C31467F1 for ; Tue, 4 Jun 2002 18:25:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00682; Tue, 4 Jun 2002 16:28:57 +0200 Message-ID: <20020604162857.17559@thrai.stud.uni-hannover.de> Date: Tue, 4 Jun 2002 16:28:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] manual 0.2.5 quirks References: <20020603042310.11143@thrai.stud.uni-hannover.de> <3CFCC1F6.5090703@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CFCC1F6.5090703@f-cpu.org>; from Yann Guidon on Tue, Jun 04, 2002 at 03:34:46PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jun 04, 2002 at 03:34:46PM +0200, Yann Guidon wrote: [...] > > - Register naming is inconsistent in sub and div: > > > > sub r3, r2, r1 => r1 = r2 - r3 > > div r3, r2, r1 => r1 = r3 / r2 > > > > The `sub' variant is more logical. > For the division, the divisor should be R3 > so we can easily catch division by zero. That's what I meant. > > - The current ASU sets the `borrow' register to 1, not -1. > > See vhdl/eu_asu/iadd.vhdl, line 344ff. > do you number lines in hexa ? Sorry... line 344 and the following 7-odd lines. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 00:15:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4Vq-0000PM-01 for ; Thu, 06 Jun 2002 23:09:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:42 +0200 (CEST) Received: (qmail 14328 invoked by uid 0); 5 Jun 2002 22:19:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 5 Jun 2002 22:19:55 -0000 Received: by moria.seul.org (Postfix) id 5696E146809; Wed, 5 Jun 2002 18:19:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A0C714684E; Wed, 5 Jun 2002 18:19:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 72C56146809 for ; Wed, 5 Jun 2002 18:19:53 -0400 (EDT) Received: from thallium (62.147.96.42) by smtp.laposte.net (5.5.044) id 3CD7884A00203AEA for f-cpu@seul.org; Thu, 6 Jun 2002 00:19:51 +0200 Message-ID: <3CD7884A00203AEA@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: f-cpu anglais X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 00:15:00 +0200 X-URL: http://www.pocomail.com/ Subject: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N this is a (bad) translation of a mail I have posted on the french= mailing list. I have just finished reading the new handbook, and overall I have= found what I think, no big news but a versiopn stable (I hope) of the ISA. = There remain some shells but it is inevitable and will be to correct with the= wire of time. On the other hand when I am at the chapter on the recomandations= of programation for the calling convention I have questions about= the intentions of the people who have choose it. 15 registers on the whole right for the passages of the= parameters? 13 for the donnee 1 for the stack of parameters and 1 for the number of= parameters. After read this section I have made a small script for scann all= my source file and see the average number of parameter used and I obtained= approximately 3 parameters (a little more or a little less according to the= languages) what I want to say that there is ten unused register in each functions. = Moreover there is a stack of register for each calls, which want= to say that for calling a function we need 3 stages: 1/ put the 13 parameters in the registers r1-r13 2/ push all the registers in r14 and put their number in r15 3/ make a jmp on the function (address of return in r60) At my opinion the 2nd stages is very ugly, need to store all the= parameters in memory will impose many accesses in memory which are penalisant,= or which will be found to cache memory and replace more useful donnee in it. What I propose has the place : first an observation, as well the= caller function as the function to call know at the compile time the= number of parameters. That is to say N the number of parameters: * if n inferior to 13 r1 : number of parameters r2-r(n+1) : parameters r(n+2)-r31 : temporari registers * Si n est superieur a 13 r1 : number of parameters r2-r14 : parameters r15 : pointer over the parameters list r16-r31 : temporari registers This has the advantage of optimizing the number of register to= use according to the number of parameters, a function which uses 3 parameters will= mobilize 4 register for the parameters and will have 27 temporary registers.= In the best cases, a function which does not have parameters, only one= register is to mobilize and 30 others are available. In the worst cases, it is= has to say more than 13 parameters, this calling convention is similar to= the proposal of the handbook with only an inversion of register. In all the cases the register r1 is used (by the number of= parameters), it is thus available to store the value of return of the function. The= number of parameters was present, same if it is known of the two functions,= in order to be able to possibly make checks. In the case of more than 13 parameters I don't know if it is= useful to put all the parameters in the list pointed by r15. Indeed to have all the= parameters lists some in very practical, for the function such as [printf]= in C or [format] in Pascal, but I am not sure time to gain in these= function is a superior than time wasted to put in memory parameters which are= already in the registers. Otherwise, the registers r32 with r59 are register has to= preserve and it is to the called to save them. It is a good thing because it save only= those which it use. But how save does ? With my opinion there are 2 methods= : use the SRB or a store, for the SRB I don't know if it is possible of chain= about thirty call of function with as much [srb_save] ? For the second= solution I think that it was interresting to have a register pointing on a memory area= reserved for this save. This some personal reflexion, I think that is not because we have= 64 register we can waste them. Thanls Tom -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 5 22:47:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4Vr-0000PM-00 for ; Thu, 06 Jun 2002 23:09:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:43 +0200 (CEST) Received: (qmail 15537 invoked by uid 0); 5 Jun 2002 22:29:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 5 Jun 2002 22:29:16 -0000 Received: by moria.seul.org (Postfix) id A2F5D146815; Wed, 5 Jun 2002 18:29:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8CBF314691E; Wed, 5 Jun 2002 18:29:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a205.home.uni-hannover.de [130.75.232.205]) by moria.seul.org (Postfix) with ESMTP id AFCE9146815 for ; Wed, 5 Jun 2002 18:29:12 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01861; Wed, 5 Jun 2002 22:47:29 +0200 Message-ID: <20020605224729.19469@thrai.stud.uni-hannover.de> Date: Wed, 5 Jun 2002 22:47:29 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Partial Writes Considered Harmful Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This may come a little late in the design and development process, but... I suggest we drop the `partial write' feature. In many cases, it makes no sense to keep the upper part of a register when only a fraction of it is written. E.g. when you load a byte from memory and want to use it as a full-width integer (or boolean - remember that jmp/move always look at the *whole* register), you either have to - `zero out' the destination register - load the LSByte or - load the LSByte - mask off any other bit Additionally, partial writes make the register set and the scoreboard logic (zero detection) much more complex than necessary - in fact, it makes some promising register set implementations almost impossible. The only thing it makes easier is constant loading. In fact that is the *only* operation that needs the partial write ability *at all*. Doesn't it? Currently, we need 8 constant loading instructions: loadcons and loadconsx with four variants each (in order to be able to load up to 256 bits - if there will ever be an F-CPU with registers wider than 256 bits, we will need *even more* instructions!). On the other hand, two slightly different instructions would be sufficient for *all* word sizes: loadcons $imm17, reg // similar to the original `loadconsx' => reg := sign_extend(imm17) loadconsp $imm16, reg // `p' means `partial' => reg := shift_left(reg, 16) | imm16 Values between -65536 and 65535, inclusively, can be loaded with a single instruction, 32-bit values need two instructions, and so on. This solution is more general than the original loadcons[x] instructions and IMHO also much more elegant. Since we need 8 bits for the opcode and 6 bits for the destination register, we can encode all variants using only a single opcode (compared to 8 opcodes for loadcons[x]): 8 + 1 + 1 + 16 + 6 = 32 bits +--------+---+---+-------+-----+ | opcode | P | S | imm16 | reg | +--------+---+---+-------+-----+ P=0 => load full register; S is the sign bit P=1 => load least significant 16 bits of the register; S is ignored In case you didn't notice it: the same encoding is used by `loadaddri[d]'. Implementing the new `loadcons' is simple: the decoder sign-extends the immediate value and sends it along. `loadconsp' is a little more tricky because it needs a `feedback loop' from one of the register set's read ports to one of the write ports. Fortunately, the left shift and the `or' operations take almost no time (we need an extra mux, the rest is just a bunch of wires). Without partial writes, other (non-SIMD) instructions that operate on partial words shall set the upper bits of the result to zero (= simple AND operation). Sign extension can either be performed by `move[s]' or by a separate `sext' instruction; the `widen' instruction is no longer necessary (it was an ugly kludge anyway). Ok, that had to be said. Now it's your turn... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 01:45:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4Vu-0000PM-01 for ; Thu, 06 Jun 2002 23:09:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:46 +0200 (CEST) Received: (qmail 28113 invoked by uid 0); 5 Jun 2002 23:45:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 5 Jun 2002 23:45:50 -0000 Received: by moria.seul.org (Postfix) id 50DAE146817; Wed, 5 Jun 2002 19:45:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2365414691E; Wed, 5 Jun 2002 19:45:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a205.home.uni-hannover.de [130.75.232.205]) by moria.seul.org (Postfix) with ESMTP id A24E7146817 for ; Wed, 5 Jun 2002 19:45:46 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02581; Thu, 6 Jun 2002 01:45:45 +0200 Message-ID: <20020606014545.22650@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 01:45:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3CD7884A00203AEA@smtp.laposte.net>; from Thomas Lavergne on Thu, Jun 06, 2002 at 12:15:00AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 12:15:00AM +0200, Thomas Lavergne wrote: [...] > 15 registers on the whole right for the passages of the parameters? 13 for the > donnee 1 for the stack of parameters and 1 for the number of parameters. Right, although I had something different in mind when I proposed the calling conventions: r1-r13 should hold the first 13 parameters, r14/r15 length and pointer of *the rest of them*, not all of them as the manual states. > After read this section I have made a small script for scann all my source file > and see the average number of parameter used and I obtained approximately 3 > parameters (a little more or a little less according to the languages) what I > want to say that there is ten unused register in each functions. As I mentioned here before, a function is free to use the unused parameter registers as local (unsaved) temporary registers. > Moreover there is a stack of register for each calls, which want to say that > for calling a function we need 3 stages: > 1/ put the 13 parameters in the registers r1-r13 > 2/ push all the registers in r14 and put their number in r15 Not all of them - just the rest. Since there are few function calls with 14 or more parameters, this is quite a rare case. There are some examples, however - like long calls to printf()/scanf(). > 3/ make a jmp on the function (address of return in r60) > At my opinion the 2nd stages is very ugly, need to store all the parameters in > memory will impose many accesses in memory which are penalisant, or which will > be found to cache memory and replace more useful donnee in it. You're right, that would be pointless. > What I propose has the place : first an observation, as well the caller > function as the function to call know at the compile time the number of > parameters. Not true. In some languages, there are functions taking a variable number of arguments - which is of course unknown when the function is compiled. > That is to say N the number of parameters: > * if n inferior to 13 > r1 : number of parameters > r2-r(n+1) : parameters > r(n+2)-r31 : temporari registers That was in fact my proposal. > * Si n est superieur a 13 > r1 : number of parameters > r2-r14 : parameters > r15 : pointer over the parameters list > r16-r31 : temporari registers Whether you put the first 13 args in r1-r13 or in r2-r14 doesn't make much of a difference. The advantage of using r1-r13 is that functions with fixed and variable argument lists remain call-compatible (which they won't be if we follow your proposal). > This has the advantage of optimizing the number of register to use according to > the number of parameters, a function which uses 3 parameters will mobilize 4 > register for the parameters and will have 27 temporary registers. In the best > cases, a function which does not have parameters, only one register is to > mobilize and 30 others are available. In the worst cases, it is has to say > more than 13 parameters, this calling convention is similar to the proposal of > the handbook with only an inversion of register. We could drop the `number of arguments' argument completely: r1-r14 -> first 14 arguments r15 -> pointer to additional arguments In most languages there's no need to pass the *number* of arguments (unless it's checked at runtime, e.g. in Lisp or Scheme - but those languages need different calling conventions anyway). But if we have to do so, r1 is a logical choice (that is, the function has a `hidden' or `0th' argument). > In all the cases the register r1 is used (by the number of parameters), it is > thus available to store the value of return of the function. The number of > parameters was present, same if it is known of the two functions, in order to > be able to possibly make checks. You can always store the result in r1, whether it's the first argument or the number of arguments. Since you usually do so at the *end* of a function, it makes no difference. > In the case of more than 13 parameters I don't know if it is useful to put all > the parameters in the list pointed by r15. Indeed to have all the parameters > lists some in very practical, for the function such as [printf] in C or > [format] in Pascal, but I am not sure time to gain in these function is a > superior than time wasted to put in memory parameters which are already in the > registers. You're right again (and the manual is wrong wrt. this point). > Otherwise, the registers r32 with r59 are register has to preserve and it is to > the called to save them. It is a good thing because it save only those which > it use. But how save does ? With my opinion there are 2 methods : use the SRB > or a store, for the SRB I don't know if it is possible of chain about thirty > call of function with as much [srb_save] ? For the second solution I think that > it was interresting to have a register pointing on a memory area reserved for > this save. In conventional (C- or Pascal-style) languages, one of the `global' registers (r63) serves as a `stack pointer' that can be used for explicit register saves. *How* you save them (and how many you save) will depend on the function's needs; therefore the compiler will have to choose an appropriate method (explicit `load'/`store', `loadm'/`storem', ...) BTW: The border between `caller-saved' and `global' registers was at r48 in my proposal, not r60. I intentionally left some global registers unassigned, for use by applications (and even the current assignments for r60-r63 can be debated - e.g. if a language doesn't need stack or frame pointers). That is, the assignment should be: r0 = always zero r1 = function return value, and also r1-r14 = function arguments (call-clobbered) r15 = pointer to additional function arguments (call-clobbered) r16-r31 = temporary registers (call-clobbered) r32-r47 = local registers (saved by callee) r48-r63 = global registers (shared by all functions) with the following assignments for C- and Pascal-style languages (but not necessarily others): r60 = function return address r61 = global pointer r62 = frame pointer r63 = stack pointer Note that r48-r63 are *not* callee-saved as the manual states. A function *must not* expect them to be unchanged across function calls (but *may* save/restore them on entry/exit and use them like the callee-saved registers r32-r47 if it doesn't need the global values). Analogously, a function *may* use r1-r15 as temporary registers if there aren't so many arguments (or it doesn't need them). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 6 09:45:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4Vz-0000PM-00 for ; Thu, 06 Jun 2002 23:09:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:51 +0200 (CEST) Received: (qmail 24984 invoked by uid 0); 6 Jun 2002 07:44:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 6 Jun 2002 07:44:58 -0000 Received: by moria.seul.org (Postfix) id 5E7CA1467F3; Thu, 6 Jun 2002 03:44:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37FCB146802; Thu, 6 Jun 2002 03:44:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id B4A911467F3 for ; Thu, 6 Jun 2002 03:44:55 -0400 (EDT) Received: from ifurita (212.194.224.209) by smtp.laposte.net (5.5.044) id 3CFD28F9000185AC for f-cpu@seul.org; Thu, 6 Jun 2002 09:44:54 +0200 Message-ID: <002901c20d2e$22ba8120$d1e0c2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> (added by postmaster@laposte.net) Subject: Re: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 09:45:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Select French Language Tricheur tu as utilisé Babelfish :) ça se voit à la traduction... tu aurais quand même pu le relire et modifier quelque partie où vraiment la traduction est incompréhensible pour un anglais :). --- Select English Language It smells Babelfish here :) ----- Original Message ----- From: Thomas Lavergne To: f-cpu anglais Sent: Thursday, June 06, 2002 12:15 AM Subject: [f-cpu] calling conventions this is a (bad) translation of a mail I have posted on the french mailing list. I have just finished reading the new handbook, and overall I have found what I think, no big news but a versiopn stable (I hope) of the ISA. There remain some shells but it is inevitable and will be to correct with the wire of time. On the other hand when I am at the chapter on the recomandations of programation for the calling convention I have questions about the intentions of the people who have choose it. 15 registers on the whole right for the passages of the parameters? 13 for the donnee 1 for the stack of parameters and 1 for the number of parameters. After read this section I have made a small script for scann all my source file and see the average number of parameter used and I obtained approximately 3 parameters (a little more or a little less according to the languages) what I want to say that there is ten unused register in each functions. Moreover there is a stack of register for each calls, which want to say that for calling a function we need 3 stages: 1/ put the 13 parameters in the registers r1-r13 2/ push all the registers in r14 and put their number in r15 3/ make a jmp on the function (address of return in r60) At my opinion the 2nd stages is very ugly, need to store all the parameters in memory will impose many accesses in memory which are penalisant, or which will be found to cache memory and replace more useful donnee in it. What I propose has the place : first an observation, as well the caller function as the function to call know at the compile time the number of parameters. That is to say N the number of parameters: * if n inferior to 13 r1 : number of parameters r2-r(n+1) : parameters r(n+2)-r31 : temporari registers * Si n est superieur a 13 r1 : number of parameters r2-r14 : parameters r15 : pointer over the parameters list r16-r31 : temporari registers This has the advantage of optimizing the number of register to use according to the number of parameters, a function which uses 3 parameters will mobilize 4 register for the parameters and will have 27 temporary registers. In the best cases, a function which does not have parameters, only one register is to mobilize and 30 others are available. In the worst cases, it is has to say more than 13 parameters, this calling convention is similar to the proposal of the handbook with only an inversion of register. In all the cases the register r1 is used (by the number of parameters), it is thus available to store the value of return of the function. The number of parameters was present, same if it is known of the two functions, in order to be able to possibly make checks. In the case of more than 13 parameters I don't know if it is useful to put all the parameters in the list pointed by r15. Indeed to have all the parameters lists some in very practical, for the function such as [printf] in C or [format] in Pascal, but I am not sure time to gain in these function is a superior than time wasted to put in memory parameters which are already in the registers. Otherwise, the registers r32 with r59 are register has to preserve and it is to the called to save them. It is a good thing because it save only those which it use. But how save does ? With my opinion there are 2 methods : use the SRB or a store, for the SRB I don't know if it is possible of chain about thirty call of function with as much [srb_save] ? For the second solution I think that it was interresting to have a register pointing on a memory area reserved for this save. This some personal reflexion, I think that is not because we have 64 register we can waste them. Thanls Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 6 10:56:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W0-0000PM-00 for ; Thu, 06 Jun 2002 23:09:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:52 +0200 (CEST) Received: (qmail 3981 invoked by uid 0); 6 Jun 2002 08:56:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Jun 2002 08:56:03 -0000 Received: by moria.seul.org (Postfix) id 4B1AF1467F5; Thu, 6 Jun 2002 04:56:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 11FA7146802; Thu, 6 Jun 2002 04:56:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 6B1B21467F5 for ; Thu, 6 Jun 2002 04:56:01 -0400 (EDT) Received: from ifurita (212.194.224.209) by smtp.laposte.net (5.5.044) id 3CF4B4D40007A42C for f-cpu@seul.org; Thu, 6 Jun 2002 10:56:00 +0200 Message-ID: <005201c20d38$114d3f40$d1e0c2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 10:56:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Thursday, June 06, 2002 1:45 AM Subject: Re: [f-cpu] calling conventions > As I mentioned here before, a function is free to use the unused > parameter registers as local (unsaved) temporary registers. > > > Moreover there is a stack of register for each calls, which want to say that > > for calling a function we need 3 stages: > > 1/ put the 13 parameters in the registers r1-r13 > > 2/ push all the registers in r14 and put their number in r15 > > Not all of them - just the rest. Since there are few function calls > with 14 or more parameters, this is quite a rare case. There are some > examples, however - like long calls to printf()/scanf(). > I see a difficulty : printf and scanf and likes use varargs, that is something which is pushed in stack and accessible via a pointer : Here an example such you can find for PC : va_start (fmt,arg) --> arg = (void *)((typeof(fmt))+1); va_arg(arg,type) --> *((type *)arg)++; etc. Now, since printf or scanf use registers for variable arguments, how do you plan to access them throughout va_arg ??? especially in such situation : while (*s) switch (*s) { case '1' : write_le_u8 (out,va_arg(arg,unsigned char)); break; case '2' : write_le_u16 (out,va_arg(arg,unsigned short)); break; case '4' : write_le_u32 (out,va_arg(arg,unsigned int)); break; ... } As you can see, the compilator cannot guess which register it could use at compile-time... the only solution is to push them in memory at run-time before using them. Personally, I think the best we can do when doing a printf is to push all fix parameters in register and optionnal parameters in stack, so : printf (r1:char *fmt,stack:r15 ...); sprintf (r1:char *str,r2:char *fmt,stack:r15 ...); etc. Should we try to push variable arguments into registers, the only alternative is to have something like in pseudo-c : print (r1,r2 ...) { int i = 2; int v; while (*s) switch (*s) { switch (i++) { case 2: v = r2; case 3: v = r3; case 4: v = r4; ... case 14: v = r14; default: v = ((int *)r15)[i - 2]; } case '1' : write_le_u8 (out,(unsigned char)v); break; case '2' : write_le_u16 (out,(unsigned short)v); break; case '4' : write_le_u32 (out,(unsigned int)v); break; ... } } Now just imagine how to code var_arg that way... you will forced to handle that complicated switch code for each var_arg encountered : every long and ugly code. I'm not sure it is worth that effort. > > What I propose has the place : first an observation, as well the caller > > function as the function to call know at the compile time the number of > > parameters. > > Not true. In some languages, there are functions taking a variable > number of arguments - which is of course unknown when the function is > compiled. Let us be precise :) : - caller side : it DOES know the number of parameters so it can tell to the callee via a dedicated register. ==> COMPILE-TIME. - callee side : it DOESN'T know the number of parameters but it can get it if the caller tells this number to it. ==> RUN-TIME. Now, is knowing this number necessary for callee ? well, it depends on what the callee really needs. > > In all the cases the register r1 is used (by the number of parameters), it is > > thus available to store the value of return of the function. The number of > > parameters was present, same if it is known of the two functions, in order to > > be able to possibly make checks. > > You can always store the result in r1, whether it's the first argument > or the number of arguments. Since you usually do so at the *end* of a > function, it makes no difference. > Advantage : r1:int addi (r1:int a,r2:int b) { return a + b; } instead of : r1:int addi (r2:int a,r3:int b) { return a + b; } will give us : r1 += r2; instead of : r1 = r2 + r3; and save r3 for temporary register. Another advantage : struct { r1:int error; r2:struct open_file *file; } file_open (r1:char *name,...); You can have not only one register as result but several registers this way ! > > In the case of more than 13 parameters I don't know if it is useful to put all > > the parameters in the list pointed by r15. Indeed to have all the parameters > > lists some in very practical, for the function such as [printf] in C or > > [format] in Pascal, but I am not sure time to gain in these function is a > > superior than time wasted to put in memory parameters which are already in the > > registers. > > You're right again (and the manual is wrong wrt. this point). > See above > r0 = always zero > r1 = function return value, and also > r1-r14 = function arguments (call-clobbered) > r15 = pointer to additional function arguments (call-clobbered) > r16-r31 = temporary registers (call-clobbered) > r32-r47 = local registers (saved by callee) > r48-r63 = global registers (shared by all functions) > > with the following assignments for C- and Pascal-style languages (but > not necessarily others): > > r60 = function return address > r61 = global pointer > r62 = frame pointer > r63 = stack pointer > > Note that r48-r63 are *not* callee-saved as the manual states. A function > *must not* expect them to be unchanged across function calls (but *may* > save/restore them on entry/exit and use them like the callee-saved > registers r32-r47 if it doesn't need the global values). Analogously, > a function *may* use r1-r15 as temporary registers if there aren't so > many arguments (or it doesn't need them). > I don't see the purpose to have so many global registers (shared by all functions). What can really be shareable between all functions ? very few indeed... unless it should be for kernel but even for such a thing it is a very bad idea because any applications might access or modify them. There is another point else which I would enlight : what about the ability to use a pair of registers to have 128 bit when 64 bits is default ? especially for such opcodes which use or return a pair of register (Rn,Rn^1) ? not very good if the first parameter or return register starts from r1. Worse, what can happen if we use an OPCODE which uses or computes a pair of register (Rn,Rn^1), especially when Rn == R1 ? Rn^1 would be R0, but R0 is hardwired to 0 ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 6 11:15:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W1-0000PM-00 for ; Thu, 06 Jun 2002 23:09:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:53 +0200 (CEST) Received: (qmail 30560 invoked by uid 0); 6 Jun 2002 09:14:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Jun 2002 09:14:43 -0000 Received: by moria.seul.org (Postfix) id 929741467FA; Thu, 6 Jun 2002 05:14:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4D98914680F; Thu, 6 Jun 2002 05:14:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id CBA541467FA for ; Thu, 6 Jun 2002 05:14:31 -0400 (EDT) Received: from ifurita (212.194.224.209) by smtp.laposte.net (5.5.044) id 3CF4B3130009E463 for f-cpu@seul.org; Thu, 6 Jun 2002 11:14:30 +0200 Message-ID: <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> Subject: Re: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 11:15:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > There is another point else which I would enlight : what about the ability to > use a pair of registers to have 128 bit when 64 bits is default ? especially > for such opcodes which use or return a pair of register (Rn,Rn^1) ? not very > good if the first parameter or return register starts from r1. Worse, what can > happen if we use an OPCODE which uses or computes a pair of register (Rn,Rn^1), > especially when Rn == R1 ? Rn^1 would be R0, but R0 is hardwired to 0 ! Another proposal : r0 : zero r1 : pointer to variable or additional function arguments (call-clobbered) r2-r15 : function return values or arguments (call-clobbered) r16-r31 : temporary registers (call-clobbered) r32-r47 : local registers (callee-saver) r48-r63 : global or special registers that way we could handle pair of registers much smarter (r2-r3,r3-r4,...,r14,r15). personally, I'm wondering if it is really necessary to limit function argument to r15 instead of r31 or r29 (to be sure to have at least a pair of temporary registers), in so far as we can consider that all function arguments not used by a function may be used as temporary registers by this function... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 6 11:21:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W1-0000PM-01 for ; Thu, 06 Jun 2002 23:09:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:53 +0200 (CEST) Received: (qmail 18503 invoked by uid 0); 6 Jun 2002 09:20:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Jun 2002 09:20:31 -0000 Received: by moria.seul.org (Postfix) id 75FF6146802; Thu, 6 Jun 2002 05:20:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F83C146819; Thu, 6 Jun 2002 05:20:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id EBF25146802 for ; Thu, 6 Jun 2002 05:20:29 -0400 (EDT) Received: from ifurita (212.194.224.209) by smtp.laposte.net (5.5.044) id 3CFD28F90001A0D9 for f-cpu@seul.org; Thu, 6 Jun 2002 11:20:29 +0200 Message-ID: <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> Subject: Re: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 11:21:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Another proposal : > > r0 : zero > r1 : pointer to variable or additional function arguments > (call-clobbered) > r2-r15 : function return values or arguments (call-clobbered) > r16-r31 : temporary registers (call-clobbered) > r32-r47 : local registers (callee-saver) > r48-r63 : global or special registers > > that way we could handle pair of registers much smarter > (r2-r3,r3-r4,...,r14,r15). > > personally, I'm wondering if it is really necessary to limit function argument > to r15 instead of r31 or r29 (to be sure to have at least a pair of temporary > registers), in so far as we can consider that all function arguments not used > by a function may be used as temporary registers by this function... Just a precision, the life of a temporary register in a function lasts between the time it assigned and the time a call of a function is done therein or the function exits, unlike local registers which would last between the start and the end of the function where it is used. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jun 6 13:08:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W4-0000PM-00 for ; Thu, 06 Jun 2002 23:09:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:56 +0200 (CEST) Received: (qmail 17570 invoked by uid 0); 6 Jun 2002 11:10:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 6 Jun 2002 11:10:38 -0000 Received: by moria.seul.org (Postfix) id 9FA771467F9; Thu, 6 Jun 2002 07:10:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7D2E814680F; Thu, 6 Jun 2002 07:10:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 3AB641467F9 for ; Thu, 6 Jun 2002 07:10:36 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17Fv8R-0004YU-00 for f-cpu@seul.org; Thu, 6 Jun 2002 13:08:55 +0200 Date: Thu, 6 Jun 2002 13:08:55 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions In-Reply-To: <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, isn't this just interesting for compiler development? To my opinion this seems to be as far away as the real opcode coding. And it could also be a point for some simulational tests to find the optimum for parameter passing. J.G. On Thu, 6 Jun 2002, Christophe wrote: >> Another proposal : >> >> r0 : zero >> r1 : pointer to variable or additional function arguments >> (call-clobbered) >> r2-r15 : function return values or arguments (call-clobbered) >> r16-r31 : temporary registers (call-clobbered) >> r32-r47 : local registers (callee-saver) >> r48-r63 : global or special registers >> >> that way we could handle pair of registers much smarter >> (r2-r3,r3-r4,...,r14,r15). >> >> personally, I'm wondering if it is really necessary to limit function >argument >> to r15 instead of r31 or r29 (to be sure to have at least a pair of temporary >> registers), in so far as we can consider that all function arguments not used >> by a function may be used as temporary registers by this function... > >Just a precision, the life of a temporary register in a function lasts between >the time it assigned and the time a call of a function is done therein or the >function exits, unlike local registers which would last between the start and >the end of the function where it is used. > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Jun 6 14:44:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W5-0000PM-00 for ; Thu, 06 Jun 2002 23:09:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:57 +0200 (CEST) Received: (qmail 20258 invoked by uid 0); 6 Jun 2002 12:44:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Jun 2002 12:44:20 -0000 Received: by moria.seul.org (Postfix) id 335E9146801; Thu, 6 Jun 2002 08:44:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 195B914694E; Thu, 6 Jun 2002 08:44:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id A4C93146801 for ; Thu, 6 Jun 2002 08:44:17 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-2.free.fr (Postfix) with ESMTP id 0F13C5FE61 for ; Thu, 6 Jun 2002 14:44:17 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id E84E68C0BF; Thu, 6 Jun 2002 14:44:16 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions Message-ID: <1023367456.3cff5920e193f@imp.free.fr> Date: Thu, 06 Jun 2002 14:44:16 +0200 (MEST) From: Cedric BAIL References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> In-Reply-To: <20020606014545.22650@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > 15 registers on the whole right for the passages of the parameters? > 13 for the > > donnee 1 for the stack of parameters and 1 for the number of > parameters. > > Right, although I had something different in mind when I proposed the > calling conventions: r1-r13 should hold the first 13 parameters, > r14/r15 length and pointer of *the rest of them*, not all of them as > the manual states. The problem in that case is for function like printf and scanf, it complicated a lot the call convention. If you want we can say that we only transfert the parameter after the 13th, into the stack, but we reserved the needed place, so that printf/scanf first start to save them into the stack and we didn't do any stupid transfert. It can be a solution to solve our problem with a best result. > > After read this section I have made a small script for scann all my > source file > > and see the average number of parameter used and I obtained > approximately 3 > > parameters (a little more or a little less according to the languages) > what I > > want to say that there is ten unused register in each functions. > > As I mentioned here before, a function is free to use the unused > parameter registers as local (unsaved) temporary registers. Right, I forget this mention in the manual, I will fixe that. > > What I propose has the place : first an observation, as well the > > caller function as the function to call know at the compile time the number > > of parameters. > Not true. In some languages, there are functions taking a variable > number of arguments - which is of course unknown when the function is > compiled. And we can add the problem of the unprototyped function. > > That is to say N the number of parameters: > > * if n inferior to 13 > > r1 : number of parameters > > r2-r(n+1) : parameters > > r(n+2)-r31 : temporari registers > > That was in fact my proposal. But we always have the problem of the unknow prototype and the variable number of argument. What about my proposition ? > > * Si n est superieur a 13 > > r1 : number of parameters > > r2-r14 : parameters > > r15 : pointer over the parameters list > > r16-r31 : temporari registers > > Whether you put the first 13 args in r1-r13 or in r2-r14 doesn't make > much of a difference. The advantage of using r1-r13 is that functions > with fixed and variable argument lists remain call-compatible (which > they won't be if we follow your proposal). > We could drop the `number of arguments' argument completely: > > r1-r14 -> first 14 arguments > r15 -> pointer to additional arguments > In most languages there's no need to pass the *number* of arguments > (unless it's checked at runtime, e.g. in Lisp or Scheme - but those > languages need different calling conventions anyway). But if we have > to do so, r1 is a logical choice (that is, the function has a `hidden' > or `0th' argument). I think that r1 is a good choice too. > > In the case of more than 13 parameters I don't know if it is useful to put > > all the parameters in the list pointed by r15. Indeed to have all the > > parameters lists some in very practical, for the function such as [printf] > > in C or [format] in Pascal, but I am not sure time to gain in these function > > is a superior than time wasted to put in memory parameters which are > > already in the registers. > You're right again (and the manual is wrong wrt. this point). You must at least give enough space to store them in case of you need a var_args. So you need space, but not always to save them. > BTW: The border between `caller-saved' and `global' registers was at > r48 in my proposal, not r60. I intentionally left some global > registers unassigned, for use by applications (and even the current > assignments for r60-r63 can be debated - e.g. if a language doesn't > need stack or frame pointers). That is, the assignment should be: > r0 = always zero > r1 = function return value, and also > r1-r14 = function arguments (call-clobbered) > r15 = pointer to additional function arguments (call-clobbered) > r16-r31 = temporary registers (call-clobbered) > r32-r47 = local registers (saved by callee) > r48-r63 = global registers (shared by all functions) > with the following assignments for C- and Pascal-style languages (but > not necessarily others): > r60 = function return address > r61 = global pointer > r62 = frame pointer > r63 = stack pointer > Note that r48-r63 are *not* callee-saved as the manual states. A > function *must not* expect them to be unchanged across function calls (but > *may* save/restore them on entry/exit and use them like the callee-saved > registers r32-r47 if it doesn't need the global values). Analogously, > a function *may* use r1-r15 as temporary registers if there aren't so > many arguments (or it doesn't need them). I really think that 12 registers for undefined use and not save it's a lot. And I really don't see where or in which language you can use them. If you absolutly want to use not callee-saved register for storing undefined register why not, but perhaps only 5 and not 15 (I think that we have in a normal function more callee-saved register than not calle-saved registers, so we need more space for them, and reserving some area for a not defined-perhaps-in-future can cause a loose of efficiency). A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Jun 6 14:48:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W6-0000PM-00 for ; Thu, 06 Jun 2002 23:09:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:58 +0200 (CEST) Received: (qmail 16937 invoked by uid 0); 6 Jun 2002 12:48:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Jun 2002 12:48:59 -0000 Received: by moria.seul.org (Postfix) id 9AF5714694E; Thu, 6 Jun 2002 08:48:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6C07A146954; Thu, 6 Jun 2002 08:48:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 2676714694E for ; Thu, 6 Jun 2002 08:48:58 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 7FD3117F03 for ; Thu, 6 Jun 2002 14:48:57 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 6056664126; Thu, 6 Jun 2002 14:48:57 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions Message-ID: <1023367737.3cff5a3934e02@imp.free.fr> Date: Thu, 06 Jun 2002 14:48:57 +0200 (MEST) From: Cedric BAIL References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> In-Reply-To: <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Another proposal : > > > > r0 : zero > > r1 : pointer to variable or additional function arguments > > (call-clobbered) > > r2-r15 : function return values or arguments (call-clobbered) > > r16-r31 : temporary registers (call-clobbered) > > r32-r47 : local registers (callee-saver) > > r48-r63 : global or special registers > > > > that way we could handle pair of registers much smarter > > (r2-r3,r3-r4,...,r14,r15). > > > > personally, I'm wondering if it is really necessary to limit function > > argument to r15 instead of r31 or r29 (to be sure to have at least a pair of > > temporary registers), in so far as we can consider that all function > > arguments not used by a function may be used as temporary registers by this > > function... I am currently asking the same question with a little variation, why not putting in r31 the pointer to parameter allocated stack. > Just a precision, the life of a temporary register in a function lasts > between the time it assigned and the time a call of a function is done > therein or the function exits, unlike local registers which would last > between the start and the end of the function where it is used. of course. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jun 6 14:50:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W6-0000PM-01 for ; Thu, 06 Jun 2002 23:09:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:58 +0200 (CEST) Received: (qmail 11141 invoked by uid 0); 6 Jun 2002 12:50:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 6 Jun 2002 12:50:15 -0000 Received: by moria.seul.org (Postfix) id 6EE11146953; Thu, 6 Jun 2002 08:50:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6136D146955; Thu, 6 Jun 2002 08:50:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id BAD9A146953 for ; Thu, 6 Jun 2002 08:50:13 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206061250.058f; Thu, 6 Jun 2002 12:50:05 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] manual update From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jun 2002 12:50:05 GMT Message-id: <200206061250.058f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N p195 Chapter 3 - We should thought away the reference to the xbar. If in ou= r head xbar =3D=3D buses, it will not be the case of newcomers.=20 - We can't impose that more than 2 register can't point on t= he same cache line. What happen with : foo (int toto, int tata) { int a,b,c; int * pa, *pb, *pc; =20 pa =3D &a; pb=3D&b; pc =3D &c; } a,b,c are allocate in the stack, so there are contig=FC in m= emory, so there are on the same cache line. We can't leave such enormous limitation to the fcpu. - Memory stream are to differentiate data flow by not checki= ng coherency between them and then we could buffer write and note checkin= g the adress of an immediat following load. We absolutely never mind abou= t the memory technonoly used behind the memory controler (SDRAM bank in t= he manual case). L2 cache are there to help the management.=20 So we should change all of this in the manual. Comment ? nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From JGraley@sonicblue.com Thu Jun 6 15:02:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W7-0000PM-00 for ; Thu, 06 Jun 2002 23:09:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:59 +0200 (CEST) Received: (qmail 24338 invoked by uid 0); 6 Jun 2002 12:58:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Jun 2002 12:58:57 -0000 Received: by moria.seul.org (Postfix) id CACB8146954; Thu, 6 Jun 2002 08:58:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3B52146956; Thu, 6 Jun 2002 08:58:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by moria.seul.org (Postfix) with ESMTP id 0F64A146954 for ; Thu, 6 Jun 2002 08:58:56 -0400 (EDT) Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g56Cwt918113 for ; Thu, 6 Jun 2002 06:58:55 -0600 (MDT) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g56Cwt610310 for ; Thu, 6 Jun 2002 05:58:55 -0700 (PDT) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Thu Jun 06 06:07:44 2002 -0700 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 05:59:56 -0700 Message-ID: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> From: John Graley To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 06:02:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello everyone! I'm new to this list - if it's OK with you guys I'd like to make a few comments about calling conventions: - Calling conventions are usually language-specific. So, for example, you could specify the C calling convention seperately and independently of the Lisp calling convention. - Compilers usually offer ways of calling into conventions for other languages when it is feasable. However, these are not used a great deal[1] - when programmers write components of their system in different languages, they usually run them as seperate operating system processes. [1] For a while, most or all Windows API funcitons used pascal calling convention, and C code had to specify this. But it's not difficult to call pascal from C. - In the case of C, functions with >13 parameters are rare, and var-args calls are very rare. (printf et. al. are already super slooooow) Cheers, John ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jun 6 16:19:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W7-0000PM-01 for ; Thu, 06 Jun 2002 23:09:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:09:59 +0200 (CEST) Received: (qmail 2552 invoked by uid 0); 6 Jun 2002 14:23:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 6 Jun 2002 14:23:04 -0000 Received: by moria.seul.org (Postfix) id CA1E0146812; Thu, 6 Jun 2002 10:22:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A899F146955; Thu, 6 Jun 2002 10:22:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 34F23146812 for ; Thu, 6 Jun 2002 10:22:12 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g56EMZ5L027200 for ; Thu, 6 Jun 2002 08:22:39 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CFF6F6E.EC2681B4@jetnet.ab.ca> Date: Thu, 06 Jun 2002 08:19:26 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > I don't see the purpose to have so many global registers (shared by all > functions). What can really be shareable between all functions ? very few > indeed... unless it should be for kernel but even for such a thing it is a very > bad idea because any applications might access or modify them. So when does the RISC architecture model start to become a 3 address machine with a single page of memory with direct addressing and indrect addressing for all of memory and the first page of memory? > There is another point else which I would enlight : what about the ability to > use a pair of registers to have 128 bit when 64 bits is default ? especially > for such opcodes which use or return a pair of register (Rn,Rn^1) ? not very > good if the first parameter or return register starts from r1. Worse, what can > happen if we use an OPCODE which uses or computes a pair of register (Rn,Rn^1), > especially when Rn == R1 ? Rn^1 would be R0, but R0 is hardwired to 0 ! Good point , would R1 be better as arg count and R2/3 as return registers and R4+ as general function registers. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From JGraley@sonicblue.com Thu Jun 6 16:37:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W8-0000PM-00 for ; Thu, 06 Jun 2002 23:10:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:00 +0200 (CEST) Received: (qmail 22421 invoked by uid 0); 6 Jun 2002 14:33:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 6 Jun 2002 14:33:33 -0000 Received: by moria.seul.org (Postfix) id 338D3146956; Thu, 6 Jun 2002 10:33:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F368D146959; Thu, 6 Jun 2002 10:33:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by moria.seul.org (Postfix) with ESMTP id 62E86146956 for ; Thu, 6 Jun 2002 10:33:31 -0400 (EDT) Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g56EXU924134 for ; Thu, 6 Jun 2002 08:33:30 -0600 (MDT) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g56EXU615543 for ; Thu, 6 Jun 2002 07:33:30 -0700 (PDT) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Thu Jun 06 07:42:19 2002 -0700 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 07:34:31 -0700 Message-ID: <37D1208A1C9BD511855B00D0B772242C0118AD6E@corpmail1.sc.sonicblue.com> From: John Graley To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 07:37:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > -----Original Message----- > From: Ben Franchuk [mailto:bfranchuk@jetnet.ab.ca] > Sent: 06 June 2002 15:26 > To: f-cpu@seul.org > Subject: Re: [f-cpu] calling conventions > > > John Graley wrote: > > > - In the case of C, functions with >13 parameters are > rare, and var-args > > calls are very rare. (printf et. al. are already super slooooow) > > Well printf style functions really only have two arguments - parameter > count > and ponter to the arguments stacked on the stack. > The code after printf's call clean's up the stack. Printf is a var-args function, and I think it's the C calling convention that states how such functions are handled - so when you write the calling convention you could specify some clever way of doing it. But it doesn't really matter, because there's not much justification in optimising var-args functions. Cheers, John ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jun 6 16:26:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4W8-0000PM-01 for ; Thu, 06 Jun 2002 23:10:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:00 +0200 (CEST) Received: (qmail 8420 invoked by uid 0); 6 Jun 2002 14:53:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Jun 2002 14:53:43 -0000 Received: by moria.seul.org (Postfix) id 9923B146955; Thu, 6 Jun 2002 10:28:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54625146957; Thu, 6 Jun 2002 10:28:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id B1230146955 for ; Thu, 6 Jun 2002 10:28:56 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g56ETB5L028575 for ; Thu, 6 Jun 2002 08:29:21 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3CFF70FB.107C4198@jetnet.ab.ca> Date: Thu, 06 Jun 2002 08:26:03 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N John Graley wrote: > - In the case of C, functions with >13 parameters are rare, and var-args > calls are very rare. (printf et. al. are already super slooooow) Well printf style functions really only have two arguments - parameter count and ponter to the arguments stacked on the stack. The code after printf's call clean's up the stack. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jun 6 17:59:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WB-0000PM-00 for ; Thu, 06 Jun 2002 23:10:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:03 +0200 (CEST) Received: (qmail 12565 invoked by uid 0); 6 Jun 2002 15:59:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 6 Jun 2002 15:59:16 -0000 Received: by moria.seul.org (Postfix) id DB4A314694A; Thu, 6 Jun 2002 11:59:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C90D714695A; Thu, 6 Jun 2002 11:59:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 3068014694A for ; Thu, 6 Jun 2002 11:59:15 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206061559.0083; Thu, 6 Jun 2002 15:59:00 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] manual update 2 From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jun 2002 15:59:00 GMT Message-id: <200206061559.0083@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N P 34 It said that ST50/SH5 are similar but are very different fro= m a scheduling point of view. There is no more explanations and = i believe it's false. From the user point of view, scheduling look the= same. nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 6 18:02:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WC-0000PM-00 for ; Thu, 06 Jun 2002 23:10:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:04 +0200 (CEST) Received: (qmail 19424 invoked by uid 0); 6 Jun 2002 16:01:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Jun 2002 16:01:43 -0000 Received: by moria.seul.org (Postfix) id D47CF146958; Thu, 6 Jun 2002 12:01:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAECE14695B; Thu, 6 Jun 2002 12:01:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 4BA50146958 for ; Thu, 6 Jun 2002 12:01:41 -0400 (EDT) Received: from ifurita (213.44.150.17) by smtp.laposte.net (5.5.044) id 3CFD28F900021E74 for f-cpu@seul.org; Thu, 6 Jun 2002 18:01:40 +0200 Message-ID: <001d01c20d73$88ee1660$11962cd5@ifurita> From: "Christophe" To: Subject: Re: [f-cpu] calling conventions Date: Thu, 6 Jun 2002 18:02:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > personally, I'm wondering if it is really necessary to limit function > > > argument to r15 instead of r31 or r29 (to be sure to have at least a pair of > > > temporary registers), in so far as we can consider that all function > > > arguments not used by a function may be used as temporary registers by this > > > function... > I am currently asking the same question with a little variation, why > not putting in r31 the pointer to parameter allocated stack. > Yes but still we should not start from r1 but r2 (that is with an even number) for function arguments or return values. So what would be the use of r1, number of registers allocated as arguments ? don't forget about the fact if you use your OPCODE where you need to use or compute a pair (Rn,Rn^1), you couln't use r1, instead of r0 which is hardwired to 0. And r31 is an odd number so you wouldn't have an even pair of registers. By the way, take this example : int f ((r2) a, (r3) b, (r4) c, (r1 *)...) { ... } variable arguments are pushed via, say, register sp (that is the register Rn which always points on top of stack), if you copy the value of sp before pushing variable arguments in r1, you got the number of variable registers pushed that way : sp - r1. Unless you really want to have the whole number of registers used by this function (but even so you cannot say if one is in register or in stack). So I'm not sure it is really important to have an implicit register for number of function arguments (we still don't know where in the register set or stack to fing the arguments). Well, I think it is surely too early to debate on that kind of topic, it mainly depends on compiler not on cpu hardware. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 19:53:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WE-0000PM-00 for ; Thu, 06 Jun 2002 23:10:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:06 +0200 (CEST) Received: (qmail 21436 invoked by uid 0); 6 Jun 2002 17:56:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Jun 2002 17:56:04 -0000 Received: by moria.seul.org (Postfix) id 96E441467E9; Thu, 6 Jun 2002 13:56:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B62414695F; Thu, 6 Jun 2002 13:56:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id B02D71467E9 for ; Thu, 6 Jun 2002 13:56:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00906; Thu, 6 Jun 2002 19:53:10 +0200 Message-ID: <20020606195310.38597@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 19:53:10 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com>; from John Graley on Thu, Jun 06, 2002 at 06:02:44AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 06:02:44AM -0700, John Graley wrote: [...] > I'm new to this list - if it's OK with you guys I'd like to make a few > comments about calling conventions: You're welcome. > - Calling conventions are usually language-specific. So, for example, you > could specify the C calling convention seperately and independently of the > Lisp calling convention. Maybe `calling conventions' is the wrong term. We're talking about a generic programming model that should be suitable for most languages and compilers. Lisp is definitely an exception, Forth is another one. But for C-, Pascal- or Fortran-style languages (and assembler routines called by them) it's an excellent idea to have a universal model that fits all. > - Compilers usually offer ways of calling into conventions for other > languages when it is feasable. However, these are not used a great deal[1] - > when programmers write components of their system in different languages, > they usually run them as seperate operating system processes. That's only half true (in binary: 0.5 ;). On Unix/Linux, most programs use the underlying C run-time library, even if they were written in C++, Pascal, Fortran or Ada. You may not be aware of it, but any program that's not written in C is, in fact, a multi-language application. > [1] For a while, most or all Windows API funcitons used pascal calling > convention, and C code had to specify this. But it's not difficult to call > pascal from C. Not at all. Although Microsoft made a big fuss of it... BTW: IIRC this started with OS/2, not Windows. > - In the case of C, functions with >13 parameters are rare, and var-args > calls are very rare. (printf et. al. are already super slooooow) Varargs calls may be rare compared to the total number of system calls, but they're present in almost any C program. That does not mean that we have to find an efficient way to do varargs functions. As I said before, I want the `regular' (fixed-args) functions to be as fast as possible. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 19:34:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WE-0000PM-01 for ; Thu, 06 Jun 2002 23:10:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:06 +0200 (CEST) Received: (qmail 10658 invoked by uid 0); 6 Jun 2002 17:56:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 6 Jun 2002 17:56:06 -0000 Received: by moria.seul.org (Postfix) id 4F63614695F; Thu, 6 Jun 2002 13:56:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19B0A146961; Thu, 6 Jun 2002 13:56:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id CE9BA14695F for ; Thu, 6 Jun 2002 13:56:03 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00856; Thu, 6 Jun 2002 19:34:10 +0200 Message-ID: <20020606193410.61472@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 19:34:10 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] manual update References: <200206061250.058f@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200206061250.058f@th00.opsion.fr>; from Nicolas Boulay on Thu, Jun 06, 2002 at 12:50:05PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 12:50:05PM +0000, Nicolas Boulay wrote: > p195 Chapter 3 [...] > - We can't impose that more than 2 register can't point on the same > cache line. What happen with : Why should we do that? Every register may point everywhere. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 19:24:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WF-0000PM-00 for ; Thu, 06 Jun 2002 23:10:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:07 +0200 (CEST) Received: (qmail 6290 invoked by uid 0); 6 Jun 2002 17:56:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Jun 2002 17:56:10 -0000 Received: by moria.seul.org (Postfix) id B92C814695E; Thu, 6 Jun 2002 13:56:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5737146964; Thu, 6 Jun 2002 13:56:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id 685C2146962 for ; Thu, 6 Jun 2002 13:56:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00806; Thu, 6 Jun 2002 19:24:21 +0200 Message-ID: <20020606192421.18501@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 19:24:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <00d901c20d3b$7d89a740$d1e0c2d4@ifurita>; from Christophe on Thu, Jun 06, 2002 at 11:21:06AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 11:21:06AM +0200, Christophe wrote: [...] > Just a precision, the life of a temporary register in a function lasts between > the time it assigned and the time a call of a function is done therein or the > function exits, unlike local registers which would last between the start and > the end of the function where it is used. That's exactly what `call-clobbered' and `callee-saved' mean :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 19:30:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WF-0000PM-01 for ; Thu, 06 Jun 2002 23:10:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:07 +0200 (CEST) Received: (qmail 27386 invoked by uid 0); 6 Jun 2002 17:56:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 6 Jun 2002 17:56:13 -0000 Received: by moria.seul.org (Postfix) id E602B146967; Thu, 6 Jun 2002 13:56:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9771E146965; Thu, 6 Jun 2002 13:56:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id 43001146967 for ; Thu, 6 Jun 2002 13:56:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00827; Thu, 6 Jun 2002 19:30:13 +0200 Message-ID: <20020606193013.45168@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 19:30:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> <1023367737.3cff5a3934e02@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1023367737.3cff5a3934e02@imp.free.fr>; from Cedric BAIL on Thu, Jun 06, 2002 at 02:48:57PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 02:48:57PM +0200, Cedric BAIL wrote: [...] > > > personally, I'm wondering if it is really necessary to limit function > > > argument to r15 instead of r31 or r29 (to be sure to have at least a pair of > > > temporary registers), in so far as we can consider that all function > > > arguments not used by a function may be used as temporary registers by this > > > function... > I am currently asking the same question with a little variation, why > not putting in r31 the pointer to parameter allocated stack. Because that would really be overkill? ;) We have to stop somewhere, and r15 is an educated guess, based on the code I've seen so far (and that was a *lot*, believe me). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 19:20:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WG-0000PM-00 for ; Thu, 06 Jun 2002 23:10:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:08 +0200 (CEST) Received: (qmail 11664 invoked by uid 0); 6 Jun 2002 17:56:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 6 Jun 2002 17:56:19 -0000 Received: by moria.seul.org (Postfix) id 36F8E146965; Thu, 6 Jun 2002 13:56:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 20834146964; Thu, 6 Jun 2002 13:56:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id EA28A146968 for ; Thu, 6 Jun 2002 13:56:12 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00790; Thu, 6 Jun 2002 19:20:47 +0200 Message-ID: <20020606192047.13252@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 19:20:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <005201c20d38$114d3f40$d1e0c2d4@ifurita>; from Christophe on Thu, Jun 06, 2002 at 10:56:36AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 10:56:36AM +0200, Christophe wrote: [...] > > Not all of them - just the rest. Since there are few function calls > > with 14 or more parameters, this is quite a rare case. There are some > > examples, however - like long calls to printf()/scanf(). > > I see a difficulty : printf and scanf and likes use varargs, that is something > which is pushed in stack and accessible via a pointer : > > Here an example such you can find for PC : > > va_start (fmt,arg) --> arg = (void *)((typeof(fmt))+1); > > va_arg(arg,type) --> *((type *)arg)++; > > etc. When we don't put them on the stack, va_start/va_arg will have to do a little more work, that's right. Is that a problem? I want my `regular' functions to run fast! > Now, since printf or scanf use registers for variable arguments, how do you > plan to access them throughout va_arg ??? especially in such situation : > > while (*s) switch (*s) { > case '1' : write_le_u8 (out,va_arg(arg,unsigned char)); break; > case '2' : write_le_u16 (out,va_arg(arg,unsigned short)); break; > case '4' : write_le_u32 (out,va_arg(arg,unsigned int)); break; > ... > } > > As you can see, the compilator cannot guess which register it could use at > compile-time... > the only solution is to push them in memory at run-time before using them. That will be the task of va_start(). In fact it is the reason why va_start() and va_end() exist at all! If you could be sure that the parameters are always on the stack and the stack always grows down, you could simply say `ap = (void**)(&last_fixed_arg + 1);'. Or maybe `ap = &...;', as they do in some compilers that treat `...' like an identifier. I expect va_start() to look like this on the F-CPU: // prologue of calling function subi $16*8, r63, r63 // allocate space on stack move r63, r17 // let r17 hold `ap' (arbitrary choice) ... // (inline) call to va_start() loadconsx $, r16 // known at compile time storem r1, [r17], r16 // save r1-r16 (syntax still unclear) ... // epilogue of calling function addi $16*8, r63, r63 // restore stack pointer That's all! va_arg() in turn will not change `ap' but the value stored in ap[15]. Let `WORD' be the type corresponding to a machine word, then va_arg(AP, TYPE) becomes (for sizeof(type) <= sizeof(WORD)): WORD *pointer = (WORD*)AP; WORD i = AP[15]; WORD tmp; if (i >= 14) { /* this is the only tricky part */ pointer = (WORD*)AP[14] - 14; } tmp = pointer[i]; AP[15] = i + 1; return (type)tmp; In case an argument is longer than a word (e.g. structure arguments), execute this sequence repeatedly for the individual words of the argument (there is also a more efficient solution, but I'm too tired to write it down ;). You see, it's no problem at all. There is a little overhead when dealing with variable argument lists, but that's ok as long as functions with a fixed number of arguments run fast. > Personally, I think the best we can do when doing a printf is to push all fix > parameters in register and optionnal parameters in stack, so : > > printf (r1:char *fmt,stack:r15 ...); > > sprintf (r1:char *str,r2:char *fmt,stack:r15 ...); > > etc. No. All functions MUST use the same calling conventions, whether they take a variable number of arguments or not. (The C99 standard does not require it - in fact, it contains rules that avoid this situation - but there is a *lot* of C code out there that won't work otherwise). [...] > Another advantage : > > struct { r1:int error; r2:struct open_file *file; } file_open (r1:char > *name,...); > > You can have not only one register as result but several registers this way ! That's another valid option. The canonical way to return structures is different however: the function struct blah func(...) { struct blah x; ...; return x; } is turned into struct blah *func(struct blah *result, ...) { struct blah x; ...; *result = x; return result; } The advantage is that `struct blah' can be arbitraryly large. We can (and probably should) define that small structures (up to 15 words) are returned in registers, the way you proposed it. [...] > I don't see the purpose to have so many global registers (shared by all > functions). What can really be shareable between all functions ? very few > indeed... unless it should be for kernel but even for such a thing it is a very > bad idea because any applications might access or modify them. You overlooked that each application (and also the kernel) will have its own register set. At least if we're talking about *real* operating systems ;) You can use registers for any global variable in any application. E.g. inside the Linux kernel, you would use registers for `current', `jiffies' and probably the addresses of some often-used memory locations (like the task table, for instance). In a Forth interpreter, you can use global registers for the stack pointers, the instruction pointer, HERE and probably some well-known addresses. In C, you'll have stack and frame pointers, a pointer to the top of the heap, pointers to often-used global data (stdin/stdout/stderr/errno for example) and so on. How many examples do I have to list in order to convince you? :) > There is another point else which I would enlight : what about the ability to > use a pair of registers to have 128 bit when 64 bits is default ? especially > for such opcodes which use or return a pair of register (Rn,Rn^1) ? not very > good if the first parameter or return register starts from r1. Worse, what can > happen if we use an OPCODE which uses or computes a pair of register (Rn,Rn^1), > especially when Rn == R1 ? Rn^1 would be R0, but R0 is hardwired to 0 ! You'll have to move the values around a little, then. E.g. if you turn `mulh' into a function, it will look like this: mulh r1, r2, r3 // high part written to r2 move r3, r1 jmp r60 But in most cases, you'll use inline code anyway (and save both the move and the jmp). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 17:45:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WH-0000PM-00 for ; Thu, 06 Jun 2002 23:10:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:09 +0200 (CEST) Received: (qmail 23813 invoked by uid 0); 6 Jun 2002 17:56:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Jun 2002 17:56:22 -0000 Received: by moria.seul.org (Postfix) id E36EC146963; Thu, 6 Jun 2002 13:56:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5E7D146961; Thu, 6 Jun 2002 13:56:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a207.home.uni-hannover.de [130.75.232.207]) by moria.seul.org (Postfix) with ESMTP id 0B2AD146963 for ; Thu, 6 Jun 2002 13:56:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00578; Thu, 6 Jun 2002 17:45:05 +0200 Message-ID: <20020606174505.58078@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 17:45:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <002901c20d2e$22ba8120$d1e0c2d4@ifurita>; from Christophe on Thu, Jun 06, 2002 at 09:45:30AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 09:45:30AM +0200, Christophe wrote: > --- Select French Language > > Tricheur tu as utilisé Babelfish :) ça se voit à la traduction... tu aurais > quand même pu le relire et modifier quelque partie où vraiment la traduction > est incompréhensible pour un anglais :). > > --- Select English Language > > It smells Babelfish here :) Not really. Babelfish translations are *much* worse. In fact, Thomas' mail was quite understandable, as opposed to your french text. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 20:38:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WK-0000PM-01 for ; Thu, 06 Jun 2002 23:10:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:12 +0200 (CEST) Received: (qmail 27625 invoked by uid 0); 6 Jun 2002 20:20:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 6 Jun 2002 20:20:03 -0000 Received: by moria.seul.org (Postfix) id 0CD32146807; Thu, 6 Jun 2002 16:20:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDC0A146961; Thu, 6 Jun 2002 16:20:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 5FAB1146807 for ; Thu, 6 Jun 2002 16:20:02 -0400 (EDT) Received: from thallium (193.250.154.117) by smtp.laposte.net (5.5.044) id 3CFD28F9000269BF for f-cpu@seul.org; Thu, 6 Jun 2002 22:20:01 +0200 Message-ID: <3CFD28F9000269BF@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 20:38:48 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> (added by postmaster@laposte.net) <002901c20d2e$22ba8120$d1e0c2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Jun 2002 09:45:30 +0200, Christophe wrote: >--- Select French Language > >Tricheur tu as utilis=E9 Babelfish :) =E7a se voit =E0 la= traduction... tu >aurais >quand m=EAme pu le relire et modifier quelque partie o=F9 vraiment= la >traduction >est incompr=E9hensible pour un anglais :). > >--- Select English Language > >It smells Babelfish here :) > --- Select French Language Et oui j'ai utilis=E9 Babelfish, le plus vexant dans t'a remarque= c'est que j'ai relu et corriger le texte, mais pas assez apparement... Et d=E9soler je ne suis pas anglais pour sa avais l'air assez comprehenssible comme fran-glais (tu le traduit comment =E7a ?-) --- Select English Language Use Babelfish :) -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 21:30:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WL-0000PM-00 for ; Thu, 06 Jun 2002 23:10:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:13 +0200 (CEST) Received: (qmail 25686 invoked by uid 0); 6 Jun 2002 20:20:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 6 Jun 2002 20:20:08 -0000 Received: by moria.seul.org (Postfix) id 7FF73146966; Thu, 6 Jun 2002 16:20:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F962146964; Thu, 6 Jun 2002 16:20:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 0D26C146961 for ; Thu, 6 Jun 2002 16:20:04 -0400 (EDT) Received: from thallium (193.250.154.117) by smtp.laposte.net (5.5.044) id 3CFD28F9000269C3 for f-cpu@seul.org; Thu, 6 Jun 2002 22:20:03 +0200 Message-ID: <3CFD28F9000269C3@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 21:30:21 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Jun 2002 10:56:36 +0200, Christophe wrote: >I see a difficulty : printf and scanf and likes use varargs,= that is >something >which is pushed in stack and accessible via a pointer : > >Here an example such you can find for PC : > >va_start (fmt,arg) --> arg =3D (void *)((typeof(fmt))+1); > >va_arg(arg,type) --> *((type *)arg)++; > >etc. The first thing I would say is : this problems is C specific... but I must admit that C is the most used language so... How can we handle this ? I don't see any solution. If we use a= stack for parameters passing we lost the advantage of big number of registers. If we use the register we can't do some specific thing= of some language. And if we mix the two like in manual we must= duplicate all parameters and this looks very ugly. But if va_start was implemented as a macro I think it was= possible for this macro to store all register in memory and use this mem space= after for each va_arg call and free it in va_end. This system slow down the va_arg handling but keep speed for all= other call, and most of function call doesn't use va_arg. >Let us be precise :) : >- caller side : it DOES know the number of parameters so it can= tell >to the >callee via a dedicated register. =3D=3D> COMPILE-TIME. >- callee side : it DOESN'T know the number of parameters but it= can >get it if >the caller tells this number to it. =3D=3D> RUN-TIME. > >Now, is knowing this number necessary for callee ? well, it= depends >on what the >callee really needs. > It's why I have put the number of arg in a function call not if= we have more than 13 parameters. >> > In all the cases the register r1 is used (by the number of >>parameters), it >is >> > thus available to store the value of return of the= function. >>The number of >> > parameters was present, same if it is known of the two >>functions, in order >to >> > be able to possibly make checks. >> >> You can always store the result in r1, whether it's the first >>argument >> or the number of arguments. Since you usually do so at the= *end* >>of a >> function, it makes no difference. >> > >Advantage : > >r1:int addi (r1:int a,r2:int b) { > return a + b; >} > >instead of : > >r1:int addi (r2:int a,r3:int b) { > return a + b; >} > >will give us : > >r1 +=3D r2; > >instead of : > >r1 =3D r2 + r3; > >and save r3 for temporary register. Bad example, you never make function like this is ridiculous, you= spent a lot of time in call of function so you don't see the= other benefit. And with a more real example the econmics was not a real= advantage because you generaly need number of arg only in start or function= so you can use his register for temp var, like r3 in your example. > >Another advantage : > >struct { r1:int error; r2:struct open_file *file; } file_open >(r1:char >*name,...); > >You can have not only one register as result but several= registers >this way ! So this is a different calling convention that allow multiple= return value... > >> > In the case of more than 13 parameters I don't know if it= is >>useful to put >all >> > the parameters in the list pointed by r15. Indeed to have= all the >parameters >> > lists some in very practical, for the function such as= [printf] >>in C or >> > [format] in Pascal, but I am not sure time to gain in these >>function is a >> > superior than time wasted to put in memory parameters which= are >>already in >the >> > registers. >> >> You're right again (and the manual is wrong wrt. this point). >> > >See above > >> r0 =3D always zero >> r1 =3D function return value, and also >> r1-r14 =3D function arguments (call-clobbered) >> r15 =3D pointer to additional function arguments (call-clobbered) >> r16-r31 =3D temporary registers (call-clobbered) >> r32-r47 =3D local registers (saved by callee) >> r48-r63 =3D global registers (shared by all functions) >> >> with the following assignments for C- and Pascal-style= languages >>(but >> not necessarily others): >> >> r60 =3D function return address >> r61 =3D global pointer >> r62 =3D frame pointer >> r63 =3D stack pointer >> >> Note that r48-r63 are *not* callee-saved as the manual states.= A >>function >> *must not* expect them to be unchanged across function calls= (but * >>may* >> save/restore them on entry/exit and use them like the= callee-saved >> registers r32-r47 if it doesn't need the global values). >>Analogously, >> a function *may* use r1-r15 as temporary registers if there= aren't >>so >> many arguments (or it doesn't need them). >> > >I don't see the purpose to have so many global registers (shared= by >all >functions). What can really be shareable between all functions= ? >very few >indeed... unless it should be for kernel but even for such a= thing >it is a very >bad idea because any applications might access or modify them. > >There is another point else which I would enlight : what about= the >ability to >use a pair of registers to have 128 bit when 64 bits is default= ? >especially >for such opcodes which use or return a pair of register= (Rn,Rn^1) ? >not very >good if the first parameter or return register starts from r1. >Worse, what can >happen if we use an OPCODE which uses or computes a pair of= register >(Rn,Rn^1), >especially when Rn =3D=3D R1 ? Rn^1 would be R0, but R0 is hardwired= to >0 ! > You can use it for global variable sharing or for temp reg. But= if you use it as temp reg you must save it before and restore it after= use. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 21:38:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WM-0000PM-00 for ; Thu, 06 Jun 2002 23:10:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:14 +0200 (CEST) Received: (qmail 5385 invoked by uid 0); 6 Jun 2002 20:20:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 6 Jun 2002 20:20:11 -0000 Received: by moria.seul.org (Postfix) id AD293146962; Thu, 6 Jun 2002 16:20:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9DED114696A; Thu, 6 Jun 2002 16:20:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id F3D69146962 for ; Thu, 6 Jun 2002 16:20:04 -0400 (EDT) Received: from thallium (193.250.154.117) by smtp.laposte.net (5.5.044) id 3CFD28F9000269C4 for f-cpu@seul.org; Thu, 6 Jun 2002 22:20:04 +0200 Message-ID: <3CFD28F9000269C4@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 21:38:46 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >Another proposal : > >r0 : zero >r1 : pointer to variable or additional function= arguments >(call-clobbered) >r2-r15 : function return values or arguments= (call-clobbered) >r16-r31 : temporary registers (call-clobbered) >r32-r47 : local registers (callee-saver) >r48-r63 : global or special registers > >that way we could handle pair of registers much smarter >(r2-r3,r3-r4,...,r14,r15). OK but this is another calling convention not usefull for most of= language becouse they don't allow multiple return value so these= language don't use some register. And you must add a pointer to additional return if you want to= return more than 14 values. > >personally, I'm wondering if it is really necessary to limit >function argument >to r15 instead of r31 or r29 (to be sure to have at least a pair= of >temporary >registers), in so far as we can consider that all function= arguments >not used >by a function may be used as temporary registers by this= function... ok but if you want to have the minimum of dependencies in your= code you need some temp reg. I think it was difficult in the start of your code if you have= only 2 temp reg... -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 21:57:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WN-0000PM-00 for ; Thu, 06 Jun 2002 23:10:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:15 +0200 (CEST) Received: (qmail 28304 invoked by uid 0); 6 Jun 2002 20:20:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 6 Jun 2002 20:20:15 -0000 Received: by moria.seul.org (Postfix) id C74FE14696C; Thu, 6 Jun 2002 16:20:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BFE2914680B; Thu, 6 Jun 2002 16:20:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id D47A1146969 for ; Thu, 6 Jun 2002 16:20:05 -0400 (EDT) Received: from thallium (193.250.154.117) by smtp.laposte.net (5.5.044) id 3CFD28F9000269C6 for f-cpu@seul.org; Thu, 6 Jun 2002 22:20:05 +0200 Message-ID: <3CFD28F9000269C6@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 21:57:34 +0200 X-URL: http://www.pocomail.com/ In-Reply-To: <002901c20d2e$22ba8120$d1e0c2d4@ifurita>; from Christophe on Thu, Jun 06, 2002 at 09:45:30AM +0200 References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 6 Jun 2002 17:45:05 +0200, Michael Riepe wrote: >On Thu, Jun 06, 2002 at 09:45:30AM +0200, Christophe wrote: >> --- Select French Language >> >> Tricheur tu as utilis=E9 Babelfish :) =E7a se voit =E0 la= traduction... >>tu aurais >> quand m=EAme pu le relire et modifier quelque partie o=F9 vraiment= la >>traduction >> est incompr=E9hensible pour un anglais :). >> >> --- Select English Language >> >> It smells Babelfish here :) > >Not really. Babelfish translations are *much* worse. In fact,= Thomas' >mail was quite understandable, as opposed to your french text. > Thank you to defend me ... -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 6 22:14:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G4WN-0000PM-01 for ; Thu, 06 Jun 2002 23:10:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 06 Jun 2002 23:10:15 +0200 (CEST) Received: (qmail 15083 invoked by uid 0); 6 Jun 2002 20:20:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 6 Jun 2002 20:20:19 -0000 Received: by moria.seul.org (Postfix) id D7DF114696D; Thu, 6 Jun 2002 16:20:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF7DF14696E; Thu, 6 Jun 2002 16:20:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id E620414696D for ; Thu, 6 Jun 2002 16:20:06 -0400 (EDT) Received: from thallium (193.250.154.117) by smtp.laposte.net (5.5.044) id 3CFD28F9000269C7 for f-cpu@seul.org; Thu, 6 Jun 2002 22:20:06 +0200 Message-ID: <3CFD28F9000269C7@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Thu, 6 Jun 2002 22:14:21 +0200 X-URL: http://www.pocomail.com/ In-Reply-To: <002901c20d2e$22ba8120$d1e0c2d4@ifurita>; from Christophe on Thu, Jun 06, 2002 at 09:45:30AM +0200 References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Some reflexions First some of you that callling convention was language specific,= OK but here we talk about a callin convention for inter language call.= If a compiler want to have is optimized call, it's ok, but if he want= to expose function to other program he must use a standard calling= conv. Second I don't known were is the problems for va_arg if we don't= push all arg in a list rather than just those not in reg, you have a more= compilcated va_start but you don't slow all the other function= call. All developer known that va_arg are slow, so in our case it's= possible it was a bit more slow but we keep speed for conventional call. Third : >If you want we can say that we only transfert the parameter= after the >13th, >into the stack, but we reserved the needed place, so that= printf/scanf >first >start to save them into the stack and we didn't do any stupid= transfert. >It can be a solution to solve our problem with a best result. No, I think the caller must only do convention thing, the caled= can all he want to handle this after. Fourth we don't care about incorect call or function with badly translated protoype... In all this case the programmer have done= an error so it could obtain an error... I think we don't need to spare cpu time to reduce the risk of thi= type of error, because in most of case we couldn't resolve it correctly= and the developper must try to resolve it himself. Thanks Tom -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 6 20:38:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Cc-0002zN-00 for ; Fri, 07 Jun 2002 03:06:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:06 +0200 (CEST) Received: (qmail 27698 invoked by uid 0); 6 Jun 2002 22:18:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 6 Jun 2002 22:18:44 -0000 Received: by moria.seul.org (Postfix) id 7037A14680B; Thu, 6 Jun 2002 18:18:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F6ED146813; Thu, 6 Jun 2002 18:18:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a160.home.uni-hannover.de [130.75.232.160]) by moria.seul.org (Postfix) with ESMTP id 7B04114680B for ; Thu, 6 Jun 2002 18:18:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01103; Thu, 6 Jun 2002 20:38:21 +0200 Message-ID: <20020606203821.01624@thrai.stud.uni-hannover.de> Date: Thu, 6 Jun 2002 20:38:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <00d301c20d3a$a7d343e0$d1e0c2d4@ifurita> <00d901c20d3b$7d89a740$d1e0c2d4@ifurita> <1023367737.3cff5a3934e02@imp.free.fr> <001d01c20d73$88ee1660$11962cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001d01c20d73$88ee1660$11962cd5@ifurita>; from Christophe on Thu, Jun 06, 2002 at 06:02:17PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 06:02:17PM +0200, Christophe wrote: > > > > personally, I'm wondering if it is really necessary to limit function > > > > argument to r15 instead of r31 or r29 (to be sure to have at least a pair > of > > > > temporary registers), in so far as we can consider that all function > > > > arguments not used by a function may be used as temporary registers by > this > > > > function... > > I am currently asking the same question with a little variation, why > > not putting in r31 the pointer to parameter allocated stack. > > > > Yes but still we should not start from r1 but r2 (that is with an even number) > for function arguments or return values. So what would be the use of r1, number > of registers allocated as arguments ? don't forget about the fact if you use > your OPCODE where you need to use or compute a pair (Rn,Rn^1), you couln't use > r1, instead of r0 which is hardwired to 0. Imagine the opposite case: blah1(int r2, complex r3r4) { ... } Or let's return a structure: struct { int r2, complex r3r4 } blah2(...) { ... } Now the calling convention is `improved' - but the problem is still there (i.e. the values are stored in the wrong place). But it's a dummy argument anyway: There is *no* F-CPU instruction that expects two of its operands in a (Rn, Rn^1) register pair. As a consequence, there is no overhead when the function is entered. When the function is left, there is an overhead of at most *one* move instruction (e.g. put result in r2:r3, then move r3 to r1). I guess we can afford that; the function call itself is much more expensive (and when the function is inlined, the move vanishes automagically). Let's keep things simple and not `uglify' them, please. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 00:27:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Cf-0002zN-00 for ; Fri, 07 Jun 2002 03:06:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:09 +0200 (CEST) Received: (qmail 16578 invoked by uid 0); 6 Jun 2002 22:26:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Jun 2002 22:26:54 -0000 Received: by moria.seul.org (Postfix) id 78815146811; Thu, 6 Jun 2002 18:26:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 533F1146961; Thu, 6 Jun 2002 18:26:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 6BF07146811 for ; Thu, 6 Jun 2002 18:26:51 -0400 (EDT) Received: from ifurita (212.194.251.55) by smtp.laposte.net (5.5.044) id 3CF4B313000AEC09 for f-cpu@seul.org; Fri, 7 Jun 2002 00:26:50 +0200 Message-ID: <000901c20da9$56978580$37fbc2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 00:27:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Thursday, June 06, 2002 7:20 PM Subject: Re: [f-cpu] calling conventions > When we don't put them on the stack, va_start/va_arg will have to do a > little more work, that's right. Is that a problem? I want my `regular' > functions to run fast! I know there is workaround but there are still much complicated than used by Intel for example :). But I'm not sure there is a real interest to have a little faster but more complicated calling conventions if your functions will spend more time in code than pushing argulents. Which is long in printf or scanf is not passing parameters but the string formatter. > That will be the task of va_start(). In fact it is the reason why > va_start() and va_end() exist at all! If you could be sure that the > parameters are always on the stack and the stack always grows down, > you could simply say `ap = (void**)(&last_fixed_arg + 1);'. Or maybe > `ap = &...;', as they do in some compilers that treat `...' like an > identifier. I know why va_start and va_end exist but i'm not very convinced by the necessity to optimize that if the time to pass argument is negligeable compared with functions execution. It is only my concern. And please, don't forget F-CPU has 32-bit opcodes, it takes a lot of place and you will need very big cache to be sure that code is inside... whereas to access in stack would be just an load with post incrementation and chance the data are in the data cache. > > I expect va_start() to look like this on the F-CPU: > > // prologue of calling function > subi $16*8, r63, r63 // allocate space on stack > move r63, r17 // let r17 hold `ap' (arbitrary choice) > ... > // (inline) call to va_start() > loadconsx $, r16 // known at compile time > storem r1, [r17], r16 // save r1-r16 (syntax still unclear) > ... > // epilogue of calling function > addi $16*8, r63, r63 // restore stack pointer > > That's all! But finally you are passing arguments in stack !? so I don't see what you gain here to do so afterwards. > va_arg() in turn will not change `ap' but the value stored in ap[15]. Let > `WORD' be the type corresponding to a machine word, then va_arg(AP, TYPE) > becomes (for sizeof(type) <= sizeof(WORD)): > > WORD *pointer = (WORD*)AP; > WORD i = AP[15]; > WORD tmp; > > if (i >= 14) { > /* this is the only tricky part */ > pointer = (WORD*)AP[14] - 14; > } > tmp = pointer[i]; > AP[15] = i + 1; > return (type)tmp; > no, much simpler, using gcc extensions because i'm lazy : va_list arg; void *arg; va_start(fmt,arg); ==> arg = ap; // our register which holds the pointer on the first variable argument va_arg(arg,type); ==> *(type __attribute__ ((aligned(4))) *)arg)++; va_end(arg); // nothing to do > You see, it's no problem at all. There is a little overhead when dealing > with variable argument lists, but that's ok as long as functions with > a fixed number of arguments run fast. As i told you functions with no variable arguments are given in register. > > > Personally, I think the best we can do when doing a printf is to push all fix > > parameters in register and optionnal parameters in stack, so : > > > > printf (r1:char *fmt,stack:r15 ...); > > > > sprintf (r1:char *str,r2:char *fmt,stack:r15 ...); > > > > etc. > > No. All functions MUST use the same calling conventions, whether they > take a variable number of arguments or not. (The C99 standard does not > require it - in fact, it contains rules that avoid this situation - > but there is a *lot* of C code out there that won't work otherwise). > I'm sorry, but it isn't what occurs in gcc. For example, gcc for SH use registers for the four first arguments. gcc for IA32 - when regparm option is used - use registers as possible except when this function has variable arguments (all stack parameters in that case). And I don't see why the calling conventions could not be the same for all the functions if we consider those rules : - fix arguments always as possible in registers, the rest in stack - variable arguments always in stack (because the callee don't know the exact number of arguments and their types). > [...] > > Another advantage : > > > > struct { r1:int error; r2:struct open_file *file; } file_open (r1:char > > *name,...); > > > > You can have not only one register as result but several registers this way ! > > That's another valid option. The canonical way to return structures is > different however: the function > > struct blah func(...) { > struct blah x; > ...; > return x; > } > > is turned into > > struct blah *func(struct blah *result, ...) { > struct blah x; > ...; > *result = x; > return result; > } > > The advantage is that `struct blah' can be arbitraryly large. We can > (and probably should) define that small structures (up to 15 words) > are returned in registers, the way you proposed it. True, I was just considering for the case where we can have enough registers for result. > > You can use registers for any global variable in any application. > E.g. inside the Linux kernel, you would use registers for `current', > `jiffies' and probably the addresses of some often-used memory locations > (like the task table, for instance). In a Forth interpreter, you can > use global registers for the stack pointers, the instruction pointer, > HERE and probably some well-known addresses. In C, you'll have stack and > frame pointers, a pointer to the top of the heap, pointers to often-used > global data (stdin/stdout/stderr/errno for example) and so on. > > How many examples do I have to list in order to convince you? :) Ok but because it is not a hardware issue but just a language issue (c, pascal, list and forth don't use the same convention), the need to fix exactly r48-r63 as global registers is not justified. just take the number you need according the language and free the others as local registers meseems more judicious rather than excluding a range, a small part of which would be used. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 00:43:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Ch-0002zN-00 for ; Fri, 07 Jun 2002 03:06:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:11 +0200 (CEST) Received: (qmail 26681 invoked by uid 0); 6 Jun 2002 22:42:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 6 Jun 2002 22:42:50 -0000 Received: by moria.seul.org (Postfix) id BAB35146813; Thu, 6 Jun 2002 18:42:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB59C146964; Thu, 6 Jun 2002 18:42:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 499B4146813 for ; Thu, 6 Jun 2002 18:42:48 -0400 (EDT) Received: from ifurita (212.194.251.55) by smtp.laposte.net (5.5.044) id 3CF4B313000AEE65 for f-cpu@seul.org; Fri, 7 Jun 2002 00:42:47 +0200 Message-ID: <007601c20dab$919c3f20$37fbc2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 00:43:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Not really. Babelfish translations are *much* worse. In fact, Thomas' > mail was quite understandable, as opposed to your french text. There is plenty of expressions which are word by word translation and the way i know it is a babel fish translation is simple to guess : "What I propose has the place"; In french he wanted to say "Ce que je propose à la place", that is,"What I propose instead". But in his french email, he wrote "Ce que je propose a la place", because he was lazy to stress his vowels :). But for Babelfish or equivalent, which are stupid enough not to understand that "a" was in fact "à" (i.e, "to (the place)"), it turns out to be "has", which is the real meaning of "a". I cannot think Thomas is stupid enough to write that sentence so he should have been lazy to reread all as he was lazy with stressed vowels :)=) By the way, i was just kidding Thomas. Should I put a ton of smileys !? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 00:55:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Cj-0002zN-00 for ; Fri, 07 Jun 2002 03:06:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:13 +0200 (CEST) Received: (qmail 13325 invoked by uid 0); 6 Jun 2002 22:57:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Jun 2002 22:57:41 -0000 Received: by moria.seul.org (Postfix) id 27A59146961; Thu, 6 Jun 2002 18:57:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA83714696A; Thu, 6 Jun 2002 18:57:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 9BA99146961 for ; Thu, 6 Jun 2002 18:57:39 -0400 (EDT) Received: from ifurita (212.194.251.55) by smtp.laposte.net (5.5.044) id 3CD7884A0021C3BC for f-cpu@seul.org; Fri, 7 Jun 2002 00:57:38 +0200 Message-ID: <013501c20dad$a486dbc0$37fbc2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <3CFD28F9000269C3@smtp.laposte.net> (added by postmaster@laposte.net) Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 00:55:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N [Thomas] >will give us : > >r1 += r2; > >instead of : > >r1 = r2 + r3; > >and save r3 for temporary register. Bad example, you never make function like this is ridiculous, you spent a lot of time in call of function so you don't see the other benefit. And with a more real example the econmics was not a real advantage because you generaly need number of arg only in start or function so you can use his register for temp var, like r3 in your example. [Me] Not so bad, if you use STL (c++) and bind functions, you have a class 'add' (or something like) which defines an operator () to make the addition. So my example would be good for this case ;P. Those classes are used to have compound functions to pass as a template argument on other classes. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 01:05:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Cl-0002zN-00 for ; Fri, 07 Jun 2002 03:06:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:15 +0200 (CEST) Received: (qmail 18278 invoked by uid 0); 6 Jun 2002 23:04:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 6 Jun 2002 23:04:46 -0000 Received: by moria.seul.org (Postfix) id 977D114681D; Thu, 6 Jun 2002 19:04:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 806C514696A; Thu, 6 Jun 2002 19:04:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 2467014681D for ; Thu, 6 Jun 2002 19:04:44 -0400 (EDT) Received: from ifurita (212.194.251.55) by smtp.laposte.net (5.5.044) id 3CF4B4D400087D30 for f-cpu@seul.org; Fri, 7 Jun 2002 01:04:43 +0200 Message-ID: <001b01c20dae$a1a7e240$37fbc2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 01:05:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Ok but because it is not a hardware issue but just a language issue (c, pascal, > list and forth don't use the same convention), the need to fix exactly r48-r63 > as global registers is not justified. just take the number you need according > the language and free the others as local registers meseems more judicious > rather than excluding a range, a small part of which would be used. Ah yes... I forget, maybe you wanted to be able to link several functions between Forth, Lisp, Pascal, C, C++, and so on ? i'm quite sceptical but why not... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 7 01:16:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17G8Cm-0002zN-00 for ; Fri, 07 Jun 2002 03:06:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 07 Jun 2002 03:06:16 +0200 (CEST) Received: (qmail 26803 invoked by uid 0); 6 Jun 2002 23:16:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Jun 2002 23:16:51 -0000 Received: by moria.seul.org (Postfix) id D4167146969; Thu, 6 Jun 2002 19:16:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B85BB14696B; Thu, 6 Jun 2002 19:16:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a160.home.uni-hannover.de [130.75.232.160]) by moria.seul.org (Postfix) with ESMTP id 42DAE146969 for ; Thu, 6 Jun 2002 19:16:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02390; Fri, 7 Jun 2002 01:16:45 +0200 Message-ID: <20020607011645.34012@thrai.stud.uni-hannover.de> Date: Fri, 7 Jun 2002 01:16:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000901c20da9$56978580$37fbc2d4@ifurita>; from Christophe on Fri, Jun 07, 2002 at 12:27:25AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 07, 2002 at 12:27:25AM +0200, Christophe wrote: [...] > > You see, it's no problem at all. There is a little overhead when dealing > > with variable argument lists, but that's ok as long as functions with > > a fixed number of arguments run fast. > > As i told you functions with no variable arguments are given in register. And as I told you (repeatedly!), *all* functions must use the same calling conventions - and that will be the one for fixed-args functions because it's the default case and it's fastest. [...] > > No. All functions MUST use the same calling conventions, whether they > > take a variable number of arguments or not. (The C99 standard does not > > require it - in fact, it contains rules that avoid this situation - > > but there is a *lot* of C code out there that won't work otherwise). > > > > I'm sorry, but it isn't what occurs in gcc. > > For example, gcc for SH use registers for the four first arguments. > > gcc for IA32 - when regparm option is used - use registers as possible except > when this function has variable arguments (all stack parameters in that case). Ever linked object files that were compiled with different `regparm' settings? *BOOM*. [...] > And I don't see why the calling conventions could not be the same for all the > functions if we consider those rules : > > - fix arguments always as possible in registers, the rest in stack Because you never know which arguments are fixed and which aren't, due to C's linking semantics (C doesn't have type-safe linking like C++). E.g. open() is often declared as int open(const char *name, int mode, ...); (because it can take two or three arguments) but in fact it may be (and eventually is) implemented as int open(const char *name, int mode, int perms) { ... } These two declarations must be compatible, or else a lot of `legacy' C code will break. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 02:57:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8W-0000PG-00 for ; Sat, 08 Jun 2002 00:23:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:12 +0200 (CEST) Received: (qmail 21256 invoked by uid 0); 7 Jun 2002 00:56:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Jun 2002 00:56:44 -0000 Received: by moria.seul.org (Postfix) id A69A61467ED; Thu, 6 Jun 2002 20:56:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 941C2146820; Thu, 6 Jun 2002 20:56:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 4CEE81467ED for ; Thu, 6 Jun 2002 20:56:42 -0400 (EDT) Received: from ifurita (213.44.146.81) by smtp.laposte.net (5.5.044) id 3CF4B313000AFF79 for f-cpu@seul.org; Fri, 7 Jun 2002 02:56:41 +0200 Message-ID: <001701c20dbe$45884120$51922cd5@ifurita> From: "Christophe" To: Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 02:57:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > E.g. open() is often declared as > > int open(const char *name, int mode, ...); > > (because it can take two or three arguments) but in fact it may be > (and eventually is) implemented as > > int open(const char *name, int mode, int perms) { > ... > } > > These two declarations must be compatible, or else a lot of `legacy' > C code will break. Okay, now I do know why GCC always refuse to mix register and stack parameters, because of the sacrosanctity of this ugly legacy. Well, I must admit that I don't like this calling convention but regarding with your last argument, more intelligent rules are things best forgotten. Sorry for annoying you so much. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jun 7 03:23:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8W-0000PG-01 for ; Sat, 08 Jun 2002 00:23:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:12 +0200 (CEST) Received: (qmail 28298 invoked by uid 0); 7 Jun 2002 01:26:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 7 Jun 2002 01:26:38 -0000 Received: by moria.seul.org (Postfix) id C9689146820; Thu, 6 Jun 2002 21:26:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C128114696B; Thu, 6 Jun 2002 21:26:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 4AC8E146820 for ; Thu, 6 Jun 2002 21:26:35 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g571R25L012719 for ; Thu, 6 Jun 2002 19:27:03 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D000B28.48E93EF9@jetnet.ab.ca> Date: Thu, 06 Jun 2002 19:23:52 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Varargs calls may be rare compared to the total number of system calls, > but they're present in almost any C program. That does not mean that we > have to find an efficient way to do varargs functions. As I said before, > I want the `regular' (fixed-args) functions to be as fast as possible. Recursive function calls require stack operations too. Other than inline macros to hint at function call parameters fixed arg functions still are better using off the stack in my view. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Fri Jun 7 10:48:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8s-0000PG-00 for ; Sat, 08 Jun 2002 00:23:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:34 +0200 (CEST) Received: (qmail 7164 invoked by uid 0); 7 Jun 2002 09:04:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 7 Jun 2002 09:04:41 -0000 Received: by moria.seul.org (Postfix) id E0871146972; Fri, 7 Jun 2002 05:04:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE28F146974; Fri, 7 Jun 2002 05:04:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 353FF146972 for ; Fri, 7 Jun 2002 05:04:39 -0400 (EDT) Received: from thallium (193.250.154.75) by smtp.laposte.net (5.5.044) id 3CD7884A00222801 for f-cpu@seul.org; Fri, 7 Jun 2002 11:04:38 +0200 Message-ID: <3CD7884A00222801@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Fri, 7 Jun 2002 10:48:30 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> <007601c20dab$919c3f20$37fbc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I'm not sure this is a good place for a discution about the= quality of babelfish translation... >> Not really. Babelfish translations are *much* worse. In fact, >>Thomas' >> mail was quite understandable, as opposed to your french= text. > >There is plenty of expressions which are word by word= translation >and the way i >know it is a babel fish translation is simple to guess : > >"What I propose has the place"; In french he wanted to say "Ce= que >je propose =E0 >la place", that is,"What I propose instead". > >But in his french email, he wrote "Ce que je propose a la= place", >because he >was lazy to stress his vowels :). But for Babelfish or= equivalent, >which are >stupid enough not to understand that "a" was in fact "=E0" (i.e,= "to >(the >place)"), it turns out to be "has", which is the real meaning of= "a". Sorry but for the moment my mailler have probs with accents so I= try to don't use it in mail. >I cannot think Thomas is stupid enough to write that sentence so= he >should have >been lazy to reread all as he was lazy with stressed vowels= :)=3D) I'm sorry but I have try to reread the mail, but I have not= enough time to make a very good translation. But I think most people have= understand my mail... -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Fri Jun 7 10:51:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8t-0000PG-00 for ; Sat, 08 Jun 2002 00:23:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:35 +0200 (CEST) Received: (qmail 11560 invoked by uid 0); 7 Jun 2002 09:04:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 7 Jun 2002 09:04:46 -0000 Received: by moria.seul.org (Postfix) id A9028146974; Fri, 7 Jun 2002 05:04:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 318A4146976; Fri, 7 Jun 2002 05:04:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 8F40A146974 for ; Fri, 7 Jun 2002 05:04:40 -0400 (EDT) Received: from thallium (193.250.154.75) by smtp.laposte.net (5.5.044) id 3CD7884A00222802 for f-cpu@seul.org; Fri, 7 Jun 2002 11:04:40 +0200 Message-ID: <3CD7884A00222802@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Fri, 7 Jun 2002 10:51:24 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <3CFD28F9000269C3@smtp.laposte.net> (added by postmaster@laposte.net) <013501c20dad$a486dbc0$37fbc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >Not so bad, if you use STL (c++) and bind functions, you have a >class 'add' (or >something like) which defines an operator () to make the= addition. >So my >example would be good for this case ;P. Those classes are used= to >have compound >functions to pass as a template argument on other classes. > OK but in this case your assembly code don't look like this : add r1, r2, r1 You have more than one line of code so it was not same than in= your example and the gain of your proposal wasvery small. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Fri Jun 7 10:54:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8t-0000PG-01 for ; Sat, 08 Jun 2002 00:23:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:35 +0200 (CEST) Received: (qmail 15147 invoked by uid 0); 7 Jun 2002 09:04:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 7 Jun 2002 09:04:51 -0000 Received: by moria.seul.org (Postfix) id 0CEC0146977; Fri, 7 Jun 2002 05:04:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC8E114697C; Fri, 7 Jun 2002 05:04:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 94814146977 for ; Fri, 7 Jun 2002 05:04:41 -0400 (EDT) Received: from thallium (193.250.154.75) by smtp.laposte.net (5.5.044) id 3CD7884A00222804 for f-cpu@seul.org; Fri, 7 Jun 2002 11:04:41 +0200 Message-ID: <3CD7884A00222804@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Fri, 7 Jun 2002 10:54:01 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <001b01c20dae$a1a7e240$37fbc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Jun 2002 01:05:19 +0200, Christophe wrote: >> Ok but because it is not a hardware issue but just a language >>issue (c, >pascal, >> list and forth don't use the same convention), the need to= fix >>exactly >r48-r63 >> as global registers is not justified. just take the number= you >>need according >> the language and free the others as local registers meseems= more >>judicious >> rather than excluding a range, a small part of which would be= used. > >Ah yes... I forget, maybe you wanted to be able to link several >functions >between Forth, Lisp, Pascal, C, C++, and so on ? i'm quite= sceptical >but why >not... > I'm sorry but I do this every day between C, C++, Pascal and Asm.= And all work ok because I use common calling convention (cdecl in most= case). -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Fri Jun 7 10:56:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8u-0000PG-00 for ; Sat, 08 Jun 2002 00:23:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:36 +0200 (CEST) Received: (qmail 12739 invoked by uid 0); 7 Jun 2002 09:04:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 7 Jun 2002 09:04:58 -0000 Received: by moria.seul.org (Postfix) id 515E214697A; Fri, 7 Jun 2002 05:04:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C58B14697D; Fri, 7 Jun 2002 05:04:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 85F8614697A for ; Fri, 7 Jun 2002 05:04:42 -0400 (EDT) Received: from thallium (193.250.154.75) by smtp.laposte.net (5.5.044) id 3CD7884A00222806 for f-cpu@seul.org; Fri, 7 Jun 2002 11:04:42 +0200 Message-ID: <3CD7884A00222806@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Fri, 7 Jun 2002 10:56:07 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni- <001701c20dbe$45884120$51922cd5@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Jun 2002 02:57:16 +0200, Christophe wrote: > >> E.g. open() is often declared as >> >> int open(const char *name, int mode, ...); >> >> (because it can take two or three arguments) but in fact it= may be >> (and eventually is) implemented as >> >> int open(const char *name, int mode, int perms) { >> ... >> } >> >> These two declarations must be compatible, or else a lot of >>`legacy' >> C code will break. > >Okay, now I do know why GCC always refuse to mix register and= stack >parameters, >because of the sacrosanctity of this ugly legacy. > >Well, I must admit that I don't like this calling convention= but >regarding with >your last argument, more intelligent rules are things best >forgotten. Sorry for >annoying you so much. > I'm sorry but Delphi and Kylix mix register and stack parameters= in their calling convention and all work OK without any problems. It's a= very speed call system and simple to use. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Jun 7 11:42:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8v-0000PG-00 for ; Sat, 08 Jun 2002 00:23:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:37 +0200 (CEST) Received: (qmail 14738 invoked by uid 0); 7 Jun 2002 09:42:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Jun 2002 09:42:14 -0000 Received: by moria.seul.org (Postfix) id DBC3B146975; Fri, 7 Jun 2002 05:42:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BDE1F146978; Fri, 7 Jun 2002 05:42:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 7C047146975 for ; Fri, 7 Jun 2002 05:42:12 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix3-2.free.fr (Postfix) with ESMTP id 86BF217F42 for ; Fri, 7 Jun 2002 11:42:11 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 746C98C104; Fri, 7 Jun 2002 11:42:11 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Another proposition for a call convention Message-ID: <1023442931.3d007ff369cdd@imp.free.fr> Date: Fri, 07 Jun 2002 11:42:11 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N An other call convention for call convention : R0 : zero R1 : number of parameter and return value R2-R13 : functions arguments (call-clobbered) R14 : pointer to pre allocated stack for all arguments and arguments after the 12th registers. R15-R31 : temporary registers (call-clobbered) R32-R59 : local registers (callee-saver) R60 : return adress R61 : global pointer R62 : Frame pointer R63 : stack pointer (We can add a R59 = static link, for language like caml, but I think that specifing that their are callee-saved, will be good enough for a call convention between every language and the system) For va_start we only do this : storem R2, [R14], R13 // only store the register from R2 to R13 and it's all. For normal function we have nothing to do ! If we have more parameters than 12, we only need to do something like this : ex: printf("a %i %i %i ... %i %i %i", 1, 2, 3, ..., 12, 13, 14) we will do something like : loadconsx 14, R1 loadcons STRINGADDR, R2 loadconsx 1, R3 loadconsx 2, R4 loadconsx 3, R5 ... loadconsx 12, R13 move R63, R14 subi 14 * 8, R63, R63 // allocated the needed space in stack subi 12 * 8, R14, R31 // use a temporary register to start transfering // other parameters loadconsx 13, R30 store -8, [R31], R30 loadconsx 14, R30 store -8, [R31], R30 jump "printf", R60 // do the call and save return address. if you need less that 12 registers, like a printf("a") you only have to do : loadconsx 1, R1 loadcons STRINGADDR, R2 move R63, R14 subi 8, R63, R63 // allocated the needed space in stack jump "printf", R60 // do the call and save return address. I know we first need to store the address label in a register and then use it, but that more easy to understand in that way (and in general, we can write the same code without the need of temporary registers). I think that we have an error in the manual, the second register in a jump give normally PC and not PC+4, I don't see the usage of this feature (but for a call PC+4 is really a good idea). So what is the problem of this solution ? A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 12:18:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8w-0000PG-01 for ; Sat, 08 Jun 2002 00:23:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:38 +0200 (CEST) Received: (qmail 470 invoked by uid 0); 7 Jun 2002 10:17:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Jun 2002 10:17:31 -0000 Received: by moria.seul.org (Postfix) id 3A221146976; Fri, 7 Jun 2002 06:17:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DA83146979; Fri, 7 Jun 2002 06:17:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id AB8BE146976 for ; Fri, 7 Jun 2002 06:17:29 -0400 (EDT) Received: from ifurita (212.194.239.64) by smtp.laposte.net (5.5.044) id 3CF4B4D40008E62F for f-cpu@seul.org; Fri, 7 Jun 2002 12:17:28 +0200 Message-ID: <00cc01c20e0c$9bad0880$40efc2d4@ifurita> From: "Christophe" To: References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> <007601c20dab$919c3f20$37fbc2d4@ifurita> <3CD7884A00222801@smtp.laposte.net> (added by postmaster@laposte.net) Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 12:18:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thomas, it wasn't really my intention to hurt you :(. I just found funny to see what a 'frenglish' may give as result. You really don't need to justify yourself. And of course, i wouldn't really mean you were not understandable :(. I suppose people here are not all acquainted with fluent english (as I am not), and it is not what we expect from people here, so please excuse me if I really hurt you :(. ----- Original Message ----- From: Thomas Lavergne To: Sent: Friday, June 07, 2002 10:48 AM Subject: Re: [f-cpu] calling conventions I'm not sure this is a good place for a discution about the quality of babelfish translation... >> Not really. Babelfish translations are *much* worse. In fact, >>Thomas' >> mail was quite understandable, as opposed to your french text. > >There is plenty of expressions which are word by word translation >and the way i >know it is a babel fish translation is simple to guess : > >"What I propose has the place"; In french he wanted to say "Ce que >je propose à >la place", that is,"What I propose instead". > >But in his french email, he wrote "Ce que je propose a la place", >because he >was lazy to stress his vowels :). But for Babelfish or equivalent, >which are >stupid enough not to understand that "a" was in fact "à" (i.e, "to >(the >place)"), it turns out to be "has", which is the real meaning of "a". Sorry but for the moment my mailler have probs with accents so I try to don't use it in mail. >I cannot think Thomas is stupid enough to write that sentence so he >should have >been lazy to reread all as he was lazy with stressed vowels :)=) I'm sorry but I have try to reread the mail, but I have not enough time to make a very good translation. But I think most people have understand my mail... -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 12:36:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8y-0000PG-00 for ; Sat, 08 Jun 2002 00:23:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:40 +0200 (CEST) Received: (qmail 30298 invoked by uid 0); 7 Jun 2002 10:36:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 7 Jun 2002 10:36:21 -0000 Received: by moria.seul.org (Postfix) id DEEFB146978; Fri, 7 Jun 2002 06:36:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B4A8814697B; Fri, 7 Jun 2002 06:36:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 61E80146978 for ; Fri, 7 Jun 2002 06:36:20 -0400 (EDT) Received: from ifurita (212.194.239.64) by smtp.laposte.net (5.5.044) id 3CD7884A00224913 for f-cpu@seul.org; Fri, 7 Jun 2002 12:36:19 +0200 Message-ID: <00d201c20e0f$3dd283e0$40efc2d4@ifurita> From: "Christophe" To: Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 12:36:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Oh stop ! i'm not saying that's a great deal !!! i'm just explaining with a very simple example what it could give on another more complex examples, especially in compound functions. That's all. We don't need to make a story for that ! my proposal was in fact a suggestion, so please take it or not but don't speak as if I really imposed it. I just want to understand why you discard some possible improvement. I worked on SH and I was very deceived because the choice of register use in GCC. I think the reason they used the same convention as Hitachi C compiler calling convention if for compability with the libraries of the latter, whereas they could have chosen a more efficient way to do so if no compatibility was not involved. besides, the last argument of Michael (how is 'open' prototyped) should have been the first to say to explain why he wanted to avoid some suggestions of mine. Now I know them, I can understand what his requirements are. Anyway, given that people are really free to use those registers as they want since there is no real constraint or even involvement in hardware part... so I really want to close this discussion because it is no use to get cross with each other about that topic. ----- Original Message ----- From: Thomas Lavergne To: Sent: Friday, June 07, 2002 10:51 AM Subject: Re: [f-cpu] calling conventions > >Not so bad, if you use STL (c++) and bind functions, you have a >class 'add' (or >something like) which defines an operator () to make the addition. >So my >example would be good for this case ;P. Those classes are used to >have compound >functions to pass as a template argument on other classes. > OK but in this case your assembly code don't look like this : add r1, r2, r1 You have more than one line of code so it was not same than in your example and the gain of your proposal wasvery small. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 12:48:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8z-0000PG-00 for ; Sat, 08 Jun 2002 00:23:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:41 +0200 (CEST) Received: (qmail 3945 invoked by uid 0); 7 Jun 2002 10:47:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 7 Jun 2002 10:47:35 -0000 Received: by moria.seul.org (Postfix) id EC872146951; Fri, 7 Jun 2002 06:47:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D504914697B; Fri, 7 Jun 2002 06:47:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 83B3A146951 for ; Fri, 7 Jun 2002 06:47:33 -0400 (EDT) Received: from ifurita (212.194.239.64) by smtp.laposte.net (5.5.044) id 3CD7884A00224CB0 for f-cpu@seul.org; Fri, 7 Jun 2002 12:47:33 +0200 Message-ID: <00dc01c20e10$cf302620$40efc2d4@ifurita> From: "Christophe" To: Subject: Re: [f-cpu] calling conventions Date: Fri, 7 Jun 2002 12:48:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N [Thomas] I'm sorry but Delphi and Kylix mix register and stack parameters in their calling convention and all work OK without any problems. It's a very speed call system and simple to use. [I] C only, Write your prototype : int open (char const *,int,...); ==> r1 open (r1,r2,stack); Now write your implementation : int open (char const *,int,int) { } ==> r1 open (r1,r2,r3) And now, try to call 'open' with the third argument : ... = open ("...",...,...); ==> BANG !!!!! Why ? because your header use "r1 open (r1,r2,stack)" but finally you will get the call address of "r1 open (r1,r2,r3)". So your implementation is unable to handle the third argument since it is in the stack and not in r3. Delphi and Kylix, when you use pascal functions, uses their fast calling convention because they don't need to be compatible with other languages. If they want to call C functions, they just took the C calling convention (for IA32, all parameters in stack) especially if they want to access glibc or likes. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 12:56:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS8z-0000PG-01 for ; Sat, 08 Jun 2002 00:23:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:41 +0200 (CEST) Received: (qmail 7664 invoked by uid 0); 7 Jun 2002 10:56:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 7 Jun 2002 10:56:00 -0000 Received: by moria.seul.org (Postfix) id 6B61C146979; Fri, 7 Jun 2002 06:55:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 448FD14697C; Fri, 7 Jun 2002 06:55:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id E95F1146979 for ; Fri, 7 Jun 2002 06:55:58 -0400 (EDT) Received: from ifurita (212.194.239.64) by smtp.laposte.net (5.5.044) id 3CD7884A00224ED3 for f-cpu@seul.org; Fri, 7 Jun 2002 12:55:58 +0200 Message-ID: <00e001c20e11$fc404ae0$40efc2d4@ifurita> From: "Christophe" To: References: <1023442931.3d007ff369cdd@imp.free.fr> Subject: Re: [f-cpu] Another proposition for a call convention Date: Fri, 7 Jun 2002 12:56:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N R1 : IN => # of parm, OUT : return value R2-R13 : IN => function args [, OUT : extra return values] As suggested by Michael, global registers can let kernel to pass some information to applications so they can read. It is why he chose a fix range. So I think we could keep them until there is reason not to do so. Just say there are "for specific purposes not described here" . ----- Original Message ----- From: Cedric BAIL To: Sent: Friday, June 07, 2002 11:42 AM Subject: [f-cpu] Another proposition for a call convention > An other call convention for call convention : > > R0 : zero > R1 : number of parameter and return value > R2-R13 : functions arguments (call-clobbered) > R14 : pointer to pre allocated stack for all arguments and arguments > after the 12th registers. > > R15-R31 : temporary registers (call-clobbered) > R32-R59 : local registers (callee-saver) > > R60 : return adress > R61 : global pointer > R62 : Frame pointer > R63 : stack pointer > > (We can add a R59 = static link, for language like caml, but I think that > specifing that their are callee-saved, will be good enough for a call > convention between every language and the system) > > For va_start we only do this : > storem R2, [R14], R13 // only store the register from R2 to R13 > > and it's all. For normal function we have nothing to do ! > If we have more parameters than 12, we only need to do something like this : > > ex: printf("a %i %i %i ... %i %i %i", 1, 2, 3, ..., 12, 13, 14) > > we will do something like : > loadconsx 14, R1 > loadcons STRINGADDR, R2 > loadconsx 1, R3 > loadconsx 2, R4 > loadconsx 3, R5 > ... > loadconsx 12, R13 > move R63, R14 > subi 14 * 8, R63, R63 // allocated the needed space in stack > subi 12 * 8, R14, R31 // use a temporary register to start transfering > // other parameters > loadconsx 13, R30 > store -8, [R31], R30 > loadconsx 14, R30 > store -8, [R31], R30 > jump "printf", R60 // do the call and save return address. > > if you need less that 12 registers, like a printf("a") you only have to > do : > loadconsx 1, R1 > loadcons STRINGADDR, R2 > > move R63, R14 > subi 8, R63, R63 // allocated the needed space in stack > > jump "printf", R60 // do the call and save return address. > > I know we first need to store the address label in a register and then use it, > but that more easy to understand in that way (and in general, we can write > the same code without the need of temporary registers). > > I think that we have an error in the manual, the second register in a jump > give normally PC and not PC+4, I don't see the usage of this feature (but > for a call PC+4 is really a good idea). > > So what is the problem of this solution ? > > A+ > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jun 7 12:58:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS90-0000PG-00 for ; Sat, 08 Jun 2002 00:23:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:42 +0200 (CEST) Received: (qmail 13151 invoked by uid 0); 7 Jun 2002 10:58:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 7 Jun 2002 10:58:34 -0000 Received: by moria.seul.org (Postfix) id A34E814697B; Fri, 7 Jun 2002 06:58:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91F4B14697D; Fri, 7 Jun 2002 06:58:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 21D8B14697B for ; Fri, 7 Jun 2002 06:58:32 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206071058.1876; Fri, 7 Jun 2002 10:58:24 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Another proposition for a call convention From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jun 2002 10:58:24 GMT Message-id: <200206071058.1876@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Cedric BAIL A: f-cpu@seul.org Date: 07/06/02 Objet: [f-cpu] Another proposition for a call convention R60 : return adress R61 : global pointer R62 : Frame pointer R63 : stack pointer >>> Must we obligatory have one unique stack pointer in C. I= have read somewhere that the dependancies on this register is really s= trong (typical IPC jump far away without such pointer). nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 13:11:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS90-0000PG-01 for ; Sat, 08 Jun 2002 00:23:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:42 +0200 (CEST) Received: (qmail 7367 invoked by uid 0); 7 Jun 2002 11:11:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 7 Jun 2002 11:11:18 -0000 Received: by moria.seul.org (Postfix) id E2FFC14697C; Fri, 7 Jun 2002 07:11:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2E9814697E; Fri, 7 Jun 2002 07:11:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 23F8014697C for ; Fri, 7 Jun 2002 07:11:15 -0400 (EDT) Received: from ifurita (212.194.239.64) by smtp.laposte.net (5.5.044) id 3CF4B313000B8232 for f-cpu@seul.org; Fri, 7 Jun 2002 13:11:14 +0200 Message-ID: <010201c20e14$1e5ad800$40efc2d4@ifurita> From: "Christophe" To: References: <200206071058.1876@th00.opsion.fr> Subject: Re: Rep:[f-cpu] Another proposition for a call convention Date: Fri, 7 Jun 2002 13:11:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N [Cédric] R60 : return adress R61 : global pointer R62 : Frame pointer R63 : stack pointer [Nico] >>> Must we obligatory have one unique stack pointer in C. I have read somewhere that the dependancies on this register is really strong (typical IPC jump far away without such pointer). [I] Are you speaking about frame pointer ? the only real purpose of frame pointer is to help for debug but in a release we don't really need a frame pointer. Unless it is the case for IA32 for example, and I'm quite sure for most other CPUs too. There is no real reason to get rid of it nor to be forced to use it. So I think it shouldn't be a problem. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jun 7 17:45:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS92-0000PG-00 for ; Sat, 08 Jun 2002 00:23:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:44 +0200 (CEST) Received: (qmail 13595 invoked by uid 0); 7 Jun 2002 15:48:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 7 Jun 2002 15:48:19 -0000 Received: by moria.seul.org (Postfix) id 70E9E14697D; Fri, 7 Jun 2002 11:48:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4D02214697F; Fri, 7 Jun 2002 11:48:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id D290614697D for ; Fri, 7 Jun 2002 11:48:17 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g57Fmj5L061757 for ; Fri, 7 Jun 2002 09:48:47 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D00D51B.38C44275@jetnet.ab.ca> Date: Fri, 07 Jun 2002 09:45:31 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Another proposition for a call convention References: <200206071058.1876@th00.opsion.fr> <010201c20e14$1e5ad800$40efc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > R60 : return adress > R61 : global pointer > R62 : Frame pointer > R63 : stack pointer (snip) > Are you speaking about frame pointer ? the only real purpose of frame pointer > is to help for debug but in a release we don't really need a frame pointer. > Unless it is the case for IA32 for example, and I'm quite sure for most other > CPUs too. There is no real reason to get rid of it nor to be forced to use it. > So I think it shouldn't be a problem. I think pascal needs a base pointer for stack frames as well as a frame pointer. With languages that use objects like C++ you could have a lot of hidden pointers used for message passing and indirect function calls. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 7 18:47:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS94-0000PG-01 for ; Sat, 08 Jun 2002 00:23:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:46 +0200 (CEST) Received: (qmail 13120 invoked by uid 0); 7 Jun 2002 16:53:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 7 Jun 2002 16:53:38 -0000 Received: by moria.seul.org (Postfix) id 4983514697E; Fri, 7 Jun 2002 12:53:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BB31146980; Fri, 7 Jun 2002 12:53:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id B2E9A14697E for ; Fri, 7 Jun 2002 12:53:36 -0400 (EDT) Received: from ifurita (212.194.236.77) by smtp.laposte.net (5.5.044) id 3CFD28F900036798 for f-cpu@seul.org; Fri, 7 Jun 2002 18:53:35 +0200 Message-ID: <003701c20e43$61fa8180$4decc2d4@ifurita> From: "Christophe" To: References: <200206071058.1876@th00.opsion.fr> <010201c20e14$1e5ad800$40efc2d4@ifurita> <3D00D51B.38C44275@jetnet.ab.ca> Subject: Re: Rep:[f-cpu] Another proposition for a call convention Date: Fri, 7 Jun 2002 18:47:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Ben Franchuk To: Sent: Friday, June 07, 2002 5:45 PM Subject: Re: Rep:[f-cpu] Another proposition for a call convention > Christophe wrote: > > > R60 : return adress > > R61 : global pointer > > R62 : Frame pointer > > R63 : stack pointer > (snip) > > Are you speaking about frame pointer ? the only real purpose of frame pointer > > is to help for debug but in a release we don't really need a frame pointer. > > Unless it is the case for IA32 for example, and I'm quite sure for most other > > CPUs too. There is no real reason to get rid of it nor to be forced to use it. > > So I think it shouldn't be a problem. > > I think pascal needs a base pointer for stack frames as well as a frame > pointer. Ok I was just in fact speaking about C, not for other languages. > With languages that use objects like C++ you could have a lot of hidden > pointers > used for message passing and indirect function calls. Does C++ have message passing !? If you are spoken about 'this', it is usually considered as the hidden first argument, that is r1 (or r2 if r1 cannot be an argument register). In fact you can call a C++ method like : int C::f (int arg); in C that way : int f__1Ci (void *this,int arg); VMT is accessing via 'this', so it is usually a temporary register. Because there are numberous objects, I could be wrong but it doesn't make a sense to put anything from an object in global registers. However, if we want some PIC (Program Independent Code ?) and need GOT (Global Offset Table), yes okay we can use global registers for that. PIC is a way for each process to use shared library mapped at different virtual addresses. Of course, it is not a C++ issue. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 7 18:31:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS97-0000PG-00 for ; Sat, 08 Jun 2002 00:23:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:49 +0200 (CEST) Received: (qmail 10285 invoked by uid 0); 7 Jun 2002 19:57:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 7 Jun 2002 19:57:54 -0000 Received: by moria.seul.org (Postfix) id 1D888146986; Fri, 7 Jun 2002 15:57:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 06BBC146989; Fri, 7 Jun 2002 15:57:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 21DBC146986 for ; Fri, 7 Jun 2002 15:57:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00787; Fri, 7 Jun 2002 18:31:03 +0200 Message-ID: <20020607183103.04279@thrai.stud.uni-hannover.de> Date: Fri, 7 Jun 2002 18:31:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Another proposition for a call convention References: <200206071058.1876@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200206071058.1876@th00.opsion.fr>; from Nicolas Boulay on Fri, Jun 07, 2002 at 10:58:24AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 07, 2002 at 10:58:24AM +0000, Nicolas Boulay wrote: [...] > >>> Must we obligatory have one unique stack pointer in C. I have read > somewhere that the dependancies on this register is really strong > (typical IPC jump far away without such pointer). As far as I know, the stack/IPC problem results from the fact that Intel CPUs update the stack pointer on every push/pop/call/ret instruction, creating lots of read-after-write dependencies that kill effective IPC. Intel sucks, doesn't it? Fortunately, not all of Gallia is occupied by the Intel's. There's a little town... ;) In F-CPU code, we're free to leave the stack pointer as is (or update it once on function entry and exit, respectively) and use temporary registers to access the stack (if we have to do so at all). That is, we effectively use it as a frame pointer. There is, however, good reason for an additional, `real' frame pointer - variable length arrays (standardized in ISO C99) and the function `alloca()' that allocate stack space dynamically. That is, r62 will point to the FEF (function entry frame) and r63 to (FEF - ), assuming that the stack grows downward. For languages that support nested functions (Pascal-style, but also GNU C) it would be nice to have a third register that points to the FEF of the lexically nesting function. But that doesn't have to be a global register. The `global pointer' register is an invention of mine; it is supposed to point to a well-defined address inside the address space of a process (e.g. at the beginning of the .data segment), in order to ease addressing: with a global pointer, you can use pointer-relative addressing for global data (and probably also for code), avoiding time-consuming relocations at load time (which in turn improves shareability of code pages). An additional `local pointer' will be useful for shared libraries; but we can also use one of the `callee-saved' registers for that. When a program is dynamically linked, it usually has two special data areas: the `procedure linkage table' (PLT) and the `global offset table' (GOT). The PLT provides entry points to all public functions while the GOT contains addresses of public (global) data items. The addresses of these tables should probably reside in global registers as well (unless they can be calculated by adding a constant to the global pointer, which usually is true for at most one of them). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 7 16:58:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS97-0000PG-01 for ; Sat, 08 Jun 2002 00:23:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:49 +0200 (CEST) Received: (qmail 24207 invoked by uid 0); 7 Jun 2002 19:57:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 7 Jun 2002 19:57:57 -0000 Received: by moria.seul.org (Postfix) id 3DB25146989; Fri, 7 Jun 2002 15:57:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26BF514698B; Fri, 7 Jun 2002 15:57:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 54EC7146989 for ; Fri, 7 Jun 2002 15:57:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00542; Fri, 7 Jun 2002 16:58:33 +0200 Message-ID: <20020607165833.49185@thrai.stud.uni-hannover.de> Date: Fri, 7 Jun 2002 16:58:33 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni-hannover.de> <001701c20dbe$45884120$51922cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001701c20dbe$45884120$51922cd5@ifurita>; from Christophe on Fri, Jun 07, 2002 at 02:57:16AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 07, 2002 at 02:57:16AM +0200, Christophe wrote: [...] > Okay, now I do know why GCC always refuse to mix register and stack parameters, > because of the sacrosanctity of this ugly legacy. Well, that's reality. And as we all know, it does suck. BTW: you *can* mix calling conventions with gcc by using __attribute__((regparm ...)) if all your functions are properly declared. You just can't control the calling conventions for individual arguments (like `first on the stack, second in a register, third on the stack again'). > Well, I must admit that I don't like this calling convention but regarding with > your last argument, more intelligent rules are things best forgotten. Sorry for > annoying you so much. `I don't like it' isn't an argument, is it? And `more intelligent' is at least a debatable attribute. `Keep it simple' is IMHO a very intelligent rule. Everything more complex will cause you headaches sooner or later. With respect to the memory load/store capabilities (or inabilities) of the F-CPU, I think that passing arguments in registers is the best choice. The other simple alternative - putting all arguments on the stack - will be much slower (and also produce longer code). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 7 17:16:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS98-0000PG-00 for ; Sat, 08 Jun 2002 00:23:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:50 +0200 (CEST) Received: (qmail 27239 invoked by uid 0); 7 Jun 2002 19:58:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Jun 2002 19:58:01 -0000 Received: by moria.seul.org (Postfix) id B8FE214698D; Fri, 7 Jun 2002 15:57:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BFC614698F; Fri, 7 Jun 2002 15:57:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 998E414698D for ; Fri, 7 Jun 2002 15:57:55 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00591; Fri, 7 Jun 2002 17:16:13 +0200 Message-ID: <20020607171613.35531@thrai.stud.uni-hannover.de> Date: Fri, 7 Jun 2002 17:16:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Another proposition for a call convention References: <1023442931.3d007ff369cdd@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1023442931.3d007ff369cdd@imp.free.fr>; from Cedric BAIL on Fri, Jun 07, 2002 at 11:42:11AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 07, 2002 at 11:42:11AM +0200, Cedric BAIL wrote: > An other call convention for call convention : > > R0 : zero > R1 : number of parameter and return value The number of parameters is not needed in most languages. > R2-R13 : functions arguments (call-clobbered) > R14 : pointer to pre allocated stack for all arguments and arguments > after the 12th registers. Pre-allocating is a nice idea, but unfortunately it leads to trouble if the caller hasn't allocated enough memory. BTW: we can refine both my and your version by defining that r14 and r15 are also used for arguments, and that r63 (that is, top of stack) points to the allocated memory. Since a call doesn't mess with the stack (like Intel's calls do), this should be safe. > R15-R31 : temporary registers (call-clobbered) > R32-R59 : local registers (callee-saver) > > R60 : return adress > R61 : global pointer > R62 : Frame pointer > R63 : stack pointer > > (We can add a R59 = static link, for language like caml, but I think that > specifing that their are callee-saved, will be good enough for a call > convention between every language and the system) > > For va_start we only do this : > storem R2, [R14], R13 // only store the register from R2 to R13 You need to evaluate r1 and store only those registers that are actually used (unless the caller *always* allocates 12 empty slots, no matter how many arguments there are). > and it's all. For normal function we have nothing to do ! In the original version, we need not store anything either for `normal' functions. > I know we first need to store the address label in a register and then use it, > but that more easy to understand in that way (and in general, we can write > the same code without the need of temporary registers). > > I think that we have an error in the manual, the second register in a jump > give normally PC and not PC+4, I don't see the usage of this feature (but > for a call PC+4 is really a good idea). IIRC: jmp r2 [, r1] => r1 := PC + 4; -- optional PC := r2; jmp r3, r2 [, r1] => if condition_true(, r3) then r1 := PC + 4; -- optional PC := r2; end if; `PC + 4' is supposed to point to the instruction right after the jmp. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 7 16:43:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GS99-0000PG-00 for ; Sat, 08 Jun 2002 00:23:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 08 Jun 2002 00:23:51 +0200 (CEST) Received: (qmail 7725 invoked by uid 0); 7 Jun 2002 19:58:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 7 Jun 2002 19:58:09 -0000 Received: by moria.seul.org (Postfix) id 06B2314698F; Fri, 7 Jun 2002 15:58:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D61CB146993; Fri, 7 Jun 2002 15:57:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id F2D7C14698F for ; Fri, 7 Jun 2002 15:57:57 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00497; Fri, 7 Jun 2002 16:43:01 +0200 Message-ID: <20020607164301.30298@thrai.stud.uni-hannover.de> Date: Fri, 7 Jun 2002 16:43:01 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D000B28.48E93EF9@jetnet.ab.ca>; from Ben Franchuk on Thu, Jun 06, 2002 at 07:23:52PM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 06, 2002 at 07:23:52PM -0600, Ben Franchuk wrote: > Michael Riepe wrote: > > > Varargs calls may be rare compared to the total number of system calls, > > but they're present in almost any C program. That does not mean that we > > have to find an efficient way to do varargs functions. As I said before, > > I want the `regular' (fixed-args) functions to be as fast as possible. > > Recursive function calls require stack operations too. Other than inline > macros to hint at function call parameters fixed arg functions still are > better using off the stack in my view. Not really. First of all, a lot of recursive function calls can be automatically translated to iterative code. A `tail-recursive' call like int blah(int x, int y) { ... return blah(x + 1, y - 1); } will be translated to a simple loop: int blah(int x, int y) { for (;;) { ... x++; y--; } } The rest of the recursive calls will have to save the arguments that are still in use *after* the call. That is, int blah(int x, int y) { ... x = blah(y - 1, x + 1); ... } will have to keep a copy of `y' somewhere (but not of `x'). A function that calls any other function will *always* have to save its arguments somewhere else if it needs them after the call (because the argument registers are call-clobbered). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jun 7 23:46:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspm-0000V5-00 for ; Sun, 09 Jun 2002 04:53:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:38 +0200 (CEST) Received: (qmail 30658 invoked by uid 0); 7 Jun 2002 21:49:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 7 Jun 2002 21:49:04 -0000 Received: by moria.seul.org (Postfix) id 0E8B314698A; Fri, 7 Jun 2002 17:49:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DA59114698E; Fri, 7 Jun 2002 17:48:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 6F3A814698A for ; Fri, 7 Jun 2002 17:48:59 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-210.jetnet.ab.ca [207.34.60.210]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g57LnT5L083048 for ; Fri, 7 Jun 2002 15:49:30 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D0129A6.CD606D44@jetnet.ab.ca> Date: Fri, 07 Jun 2002 15:46:14 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni-hannover.de> <001701c20dbe$45884120$51922cd5@ifurita> <20020607165833.49185@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > With respect to the memory load/store capabilities (or inabilities) of the > F-CPU, I think that passing arguments in registers is the best choice. > The other simple alternative - putting all arguments on the stack - > will be much slower (and also produce longer code). Mind you other than FORTH and dumb little functions like strlen() or strcat() most functions take a long time to execute compared to entry and exit times. I suspect that a lot of slow routines are more do to poor Instruction set architecture than coding style. Take a compare operation like A = C > F; for a typical 8 bit CPU. ld hl,C push hl ld hl,F call compare st F,hl Stack or register parameter passing will not make up for a poor instruction set if you have a rather high number of subroutines that perform dumb simple tasks that a better architecture could handle. It is not the time a instruction executes, but rather the unknown latency of the entire system that is critical. Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Jun 8 00:01:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspn-0000V5-00 for ; Sun, 09 Jun 2002 04:53:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:39 +0200 (CEST) Received: (qmail 29109 invoked by uid 0); 7 Jun 2002 22:04:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 7 Jun 2002 22:04:01 -0000 Received: by moria.seul.org (Postfix) id 631E114698B; Fri, 7 Jun 2002 18:04:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F55F146990; Fri, 7 Jun 2002 18:04:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 9D6F314698B for ; Fri, 7 Jun 2002 18:03:59 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-210.jetnet.ab.ca [207.34.60.210]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g57M4T5L087929 for ; Fri, 7 Jun 2002 16:04:30 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D012D2B.9838E997@jetnet.ab.ca> Date: Fri, 07 Jun 2002 16:01:15 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Another proposition for a call convention References: <200206071058.1876@th00.opsion.fr> <20020607183103.04279@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > The `global pointer' register is an invention of mine; it is supposed > to point to a well-defined address inside the address space of a process > (e.g. at the beginning of the .data segment), in order to ease addressing: > with a global pointer, you can use pointer-relative addressing for global > data (and probably also for code), avoiding time-consuming relocations > at load time (which in turn improves shareability of code pages). An > additional `local pointer' will be useful for shared libraries; but we > can also use one of the `callee-saved' registers for that. Funny I thought that was invented years ago and called a base pointer. One idea that I have been using is the global pointer to store interupt service local variables as well as OS variables as negitive offset from the begining of the data segment. [os variables ] [irq local variables] program data -> [ task variables ] The advantage is the not stack required to be clean at all times making emulation of complex instructions like floating point easyier as data using the stack pointer need not be cleaned up as much. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 8 00:37:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspo-0000V5-00 for ; Sun, 09 Jun 2002 04:53:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:40 +0200 (CEST) Received: (qmail 8486 invoked by uid 0); 7 Jun 2002 22:37:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 7 Jun 2002 22:37:14 -0000 Received: by moria.seul.org (Postfix) id 72D70146844; Fri, 7 Jun 2002 18:37:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F45F146991; Fri, 7 Jun 2002 18:37:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a163.home.uni-hannover.de [130.75.232.163]) by moria.seul.org (Postfix) with ESMTP id CF2EA146844 for ; Fri, 7 Jun 2002 18:37:11 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02276; Sat, 8 Jun 2002 00:37:10 +0200 Message-ID: <20020608003709.23126@thrai.stud.uni-hannover.de> Date: Sat, 8 Jun 2002 00:37:09 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni-hannover.de> <001701c20dbe$45884120$51922cd5@ifurita> <20020607165833.49185@thrai.stud.uni-hannover.de> <3D0129A6.CD606D44@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0129A6.CD606D44@jetnet.ab.ca>; from Ben Franchuk on Fri, Jun 07, 2002 at 03:46:14PM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 07, 2002 at 03:46:14PM -0600, Ben Franchuk wrote: > Michael Riepe wrote: > > > With respect to the memory load/store capabilities (or inabilities) of the > > F-CPU, I think that passing arguments in registers is the best choice. > > The other simple alternative - putting all arguments on the stack - > > will be much slower (and also produce longer code). > > Mind you other than FORTH and dumb little functions like > strlen() or strcat() most functions take a long time to > execute compared to entry and exit times. Depends on the language. Especially OO languages are often big collections of rather short subroutines (due to the encapsulation in objects). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jun 8 03:02:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspq-0000V5-00 for ; Sun, 09 Jun 2002 04:53:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:42 +0200 (CEST) Received: (qmail 26593 invoked by uid 0); 8 Jun 2002 00:54:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 8 Jun 2002 00:54:44 -0000 Received: by moria.seul.org (Postfix) id F1269146980; Fri, 7 Jun 2002 20:54:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E6C44146992; Fri, 7 Jun 2002 20:54:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 9E492146980 for ; Fri, 7 Jun 2002 20:54:43 -0400 (EDT) Received: from f-cpu.org (kdl11-72.n.club-internet.fr [213.44.9.72]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A1C5516A8 for ; Sat, 8 Jun 2002 02:54:41 +0200 (CEST) Message-ID: <3D015791.1040505@f-cpu.org> Date: Sat, 08 Jun 2002 03:02:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] manual update References: <200206061250.058f@th00.opsion.fr> <20020606193410.61472@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Thu, Jun 06, 2002 at 12:50:05PM +0000, Nicolas Boulay wrote: >> p195 Chapter 3 > [...] >> - We can't impose that more than 2 register can't point on the same >> cache line. What happen with : > Why should we do that? Every register may point everywhere. physically, yes. However there might be a HW limitation for the first versions. The code will work but might have some thrashing (one or two cycles of penalty per access where several pointers point to the same line). Please give me some time to explain that. i started to answer nicO's mail but haven't finished yet. it's not a simple thing to explain. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From robfinch@sympatico.ca Sat Jun 8 09:26:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspr-0000V5-00 for ; Sun, 09 Jun 2002 04:53:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:43 +0200 (CEST) Received: (qmail 30218 invoked by uid 0); 8 Jun 2002 07:27:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 8 Jun 2002 07:27:04 -0000 Received: by moria.seul.org (Postfix) id E9043146916; Sat, 8 Jun 2002 03:27:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D575A14691C; Sat, 8 Jun 2002 03:27:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by moria.seul.org (Postfix) with ESMTP id 706E8146916 for ; Sat, 8 Jun 2002 03:27:01 -0400 (EDT) Received: from lkhgbopihbpihb9 ([65.92.33.130]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020608072700.MATS25645.tomts22-srv.bellnexxia.net@lkhgbopihbpihb9> for ; Sat, 8 Jun 2002 03:27:00 -0400 Message-ID: <00aa01c20ebd$cf064e60$82215c41@lkhgbopihbpihb9> From: "Rob Finch" To: References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni-hannover.de> <001701c20dbe$45884120$51922cd5@ifurita> <20020607165833.49185@thrai.stud.uni-hannover.de> <3D0129A6.CD606D44@jetnet.ab.ca> <20020608003709.23126@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Date: Sat, 8 Jun 2002 03:26:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N My two cents: Defining a standard calling convention seems like a good idea to me. One of the reasons why languages use different conventions may be that no one put their foot down at the beginning and said you must use these conventions to be compatible. Heterogenous calling conventions are a big pain. I think regs should be assigned in the following order r63: return address - most RISC machines use last reg for return address and you are guarenteed to always need a return address, hence this reg should be fixed like r0. It is probably better to put it at the end since the remaining pointers are not always needed r62: stack pointer - many languages need a stack pointer - its the next most fixed requirement r61: global pointer - likely next most useful pointer r60: frame pointer - sometimes used along with stack pointer r59: base pointer - pascal It should be specified that these regs *must* be used as above. If a language doesn't need a particular register eg frame pointer, then it can use the register for whatever it wants. Variable argument lists are a bad idea. I would discourage their use by making them as slow as possible :). Most languages don't support them and this is the trend. Rob ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jun 8 10:06:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gsps-0000V5-00 for ; Sun, 09 Jun 2002 04:53:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:44 +0200 (CEST) Received: (qmail 21881 invoked by uid 0); 8 Jun 2002 08:28:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 8 Jun 2002 08:28:48 -0000 Received: by moria.seul.org (Postfix) id 6365C14691A; Sat, 8 Jun 2002 04:28:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2AC5D146921; Sat, 8 Jun 2002 04:28:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id B645714691A for ; Sat, 8 Jun 2002 04:28:46 -0400 (EDT) Received: from thallium (193.250.26.233) by smtp.laposte.net (5.5.044) id 3CF4B313000C7CBE for f-cpu@seul.org; Sat, 8 Jun 2002 10:28:45 +0200 Message-ID: <3CF4B313000C7CBE@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Sat, 8 Jun 2002 10:06:01 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <002901c20d2e$22ba8120$d1e0c2d4@ifurita> <20020606174505.58078@thrai.stud.uni-hannover.de> <007601c20dab$919c3f20$37fbc2d4@ifurita> <3CD7884A00222801@smtp.laposte.net> (added by postmaster@laposte.net) <00cc01c20e0c$9bad0880$40efc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Jun 2002 12:18:02 +0200, Christophe wrote: >Thomas, it wasn't really my intention to hurt you :(. I just= found >funny to see >what a 'frenglish' may give as result. You really don't need to >justify >yourself. And of course, i wouldn't really mean you were not >understandable :(. >I suppose people here are not all acquainted with fluent english= (as >I am not), >and it is not what we expect from people here, so please excuse= me >if I really >hurt you :(. > You never hurt me, and you are fully excused. And please excuse me for my bad english... -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jun 8 10:14:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gsps-0000V5-01 for ; Sun, 09 Jun 2002 04:53:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:44 +0200 (CEST) Received: (qmail 16075 invoked by uid 0); 8 Jun 2002 08:28:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 8 Jun 2002 08:28:50 -0000 Received: by moria.seul.org (Postfix) id 8AAC0146993; Sat, 8 Jun 2002 04:28:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D6B8146992; Sat, 8 Jun 2002 04:28:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 7A99E14691C for ; Sat, 8 Jun 2002 04:28:47 -0400 (EDT) Received: from thallium (193.250.26.233) by smtp.laposte.net (5.5.044) id 3CF4B313000C7CC0 for f-cpu@seul.org; Sat, 8 Jun 2002 10:28:47 +0200 Message-ID: <3CF4B313000C7CC0@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Sat, 8 Jun 2002 10:14:56 +0200 X-URL: http://www.pocomail.com/ References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni- <00dc01c20e10$cf302620$40efc2d4@ifurita> Subject: Re: [f-cpu] calling conventions Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 7 Jun 2002 12:48:06 +0200, Christophe wrote: >[Thomas] > >I'm sorry but Delphi and Kylix mix register and stack parameters= in >their >calling convention and all work OK without any problems. It's a= very >speed call system and simple to use. > >[I] > >C only, > >Write your prototype : > >int open (char const *,int,...); > =3D=3D> r1 open (r1,r2,stack); > >Now write your implementation : > >int open (char const *,int,int) { } > =3D=3D> r1 open (r1,r2,r3) > >And now, try to call 'open' with the third argument : > >.... =3D open ("...",...,...); > =3D=3D> BANG !!!!! False you must have same register and stack assignment : you= first choose the number of argument you can put in register and all was ok : Delphi/Kylix use 3 register so you obtain this int open (char const *,int,...); =3D=3D> r1 open (r1,r2,r3); and int open (char const *,int,int) { } =3D=3D> r1 open (r1,r2,r3) if you would two you obtain this : int open (char const *,int,...); =3D=3D> r1 open (r1,r2,stack); and int open (char const *,int,int) { } =3D=3D> r1 open (r1,r2,stack) Store in register or stack do not depend on paremters type. > >Why ? because your header use "r1 open (r1,r2,stack)" but= finally >you will get >the call address of "r1 open (r1,r2,r3)". So your implementation= is >unable to >handle the third argument since it is in the stack and not in= r3. > >Delphi and Kylix, when you use pascal functions, uses their= fast >calling >convention because they don't need to be compatible with other >languages. If >they want to call C functions, they just took the C calling >convention (for >IA32, all parameters in stack) especially if they want to= access >glibc or >likes. > They're no diference between Pascal and C for this point, all two= interact cleanly with other languages, just delphi/kylix use a= special fast call convention for internal call, but you can choose any= call convention for any call. If you could do this in C you can optimize each call... -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jun 8 10:20:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspt-0000V5-00 for ; Sun, 09 Jun 2002 04:53:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:45 +0200 (CEST) Received: (qmail 19585 invoked by uid 0); 8 Jun 2002 08:28:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 8 Jun 2002 08:28:52 -0000 Received: by moria.seul.org (Postfix) id 145D3146921; Sat, 8 Jun 2002 04:28:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8060F146995; Sat, 8 Jun 2002 04:28:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 6BC1114691C for ; Sat, 8 Jun 2002 04:28:48 -0400 (EDT) Received: from thallium (193.250.26.233) by smtp.laposte.net (5.5.044) id 3CF4B313000C7CC2 for f-cpu@seul.org; Sat, 8 Jun 2002 10:28:48 +0200 Message-ID: <3CF4B313000C7CC2@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Sat, 8 Jun 2002 10:20:02 +0200 X-URL: http://www.pocomail.com/ References: <200206071058.1876@th00.opsion.fr> <010201c20e14$1e5ad800$40efc2d4@ifurita> <3D00D51B.38C44275@jetnet.ab.ca> Subject: Re: Rep:[f-cpu] Another proposition for a call convention Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 07 Jun 2002 09:45:31 -0600, Ben Franchuk wrote: >Christophe wrote: > >> R60 : return adress >> R61 : global pointer >> R62 : Frame pointer >> R63 : stack pointer >(snip) >> Are you speaking about frame pointer ? the only real purpose= of >>frame pointer >> is to help for debug but in a release we don't really need a= frame >>pointer. >> Unless it is the case for IA32 for example, and I'm quite sure= for >>most other >> CPUs too. There is no real reason to get rid of it nor to be >>forced to use it. >> So I think it shouldn't be a problem. > >I think pascal needs a base pointer for stack frames as well as= a >frame >pointer. No you don't need it, I have worked on some Pascal compiler= without it but in case of function in function you must have it or a stack= for parameters (stack is generaly most simple to handle but base= pointer is speeder), but you can handle it internaly and you don't need to= specify it in a general call convention. >With languages that use objects like C++ you could have a lot= of >hidden >pointers >used for message passing and indirect function calls. In most of case the only thing you must have is a pointer to the= object that own the current method, and generaly it was passed as the= first parameter so you can use same calling convention. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jun 8 10:22:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspu-0000V5-01 for ; Sun, 09 Jun 2002 04:53:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:46 +0200 (CEST) Received: (qmail 13916 invoked by uid 0); 8 Jun 2002 08:28:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 8 Jun 2002 08:28:55 -0000 Received: by moria.seul.org (Postfix) id 6E6E3146994; Sat, 8 Jun 2002 04:28:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C414146997; Sat, 8 Jun 2002 04:28:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 51330146994 for ; Sat, 8 Jun 2002 04:28:49 -0400 (EDT) Received: from thallium (193.250.26.233) by smtp.laposte.net (5.5.044) id 3CF4B313000C7CC3 for f-cpu@seul.org; Sat, 8 Jun 2002 10:28:49 +0200 Message-ID: <3CF4B313000C7CC3@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Sat, 8 Jun 2002 10:22:01 +0200 X-URL: http://www.pocomail.com/ References: <200206071058.1876@th00.opsion.fr> <010201c20e14$1e5ad800$40efc2d4@ifurita> <3D00D51B.38C44275@jetnet.ab.ca> <003701c20e43$61fa8180$4decc2d4@ifurita> Subject: Re: Rep:[f-cpu] Another proposition for a call convention Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >> I think pascal needs a base pointer for stack frames as well= as a >>frame >> pointer. > >Ok I was just in fact speaking about C, not for other= languages. > Ok but we don't speak about a C specific call conv but about a= general or interlanguage call conv. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jun 8 10:26:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gspv-0000V5-00 for ; Sun, 09 Jun 2002 04:53:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:47 +0200 (CEST) Received: (qmail 8547 invoked by uid 0); 8 Jun 2002 08:30:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Jun 2002 08:30:45 -0000 Received: by moria.seul.org (Postfix) id 6CC8D14691C; Sat, 8 Jun 2002 04:30:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3786C146992; Sat, 8 Jun 2002 04:30:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id D72CF14691C for ; Sat, 8 Jun 2002 04:30:43 -0400 (EDT) Received: from thallium (193.250.26.233) by smtp.laposte.net (5.5.044) id 3CF4B313000C7D1A for f-cpu@seul.org; Sat, 8 Jun 2002 10:30:43 +0200 Message-ID: <3CF4B313000C7D1A@smtp.laposte.net> (added by postmaster@laposte.net) From: Thomas Lavergne To: X-Mailer: PocoMail 2.5 (974) - EVALUATION VERSION Date: Sat, 8 Jun 2002 10:26:06 +0200 X-URL: http://www.pocomail.com/ In-Reply-To: <1023442931.3d007ff369cdd@imp.free.fr>; from Cedric BAIL on Fri, Jun 07, 2002 at 11:42:11AM +0200 References: <1023442931.3d007ff369cdd@imp.free.fr> <20020607171613.35531@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] Another proposition for a call convention Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > R14 : pointer to pre allocated stack for all arguments and= arguments > after the 12th registers. Another solution is to push parameters in reverse order so you= can after push the other if you want without need to reserve the space. -- Thomas Lavergne "Le vrai r=EAveur est celui= qui r=EAve de l'impossible." (Elsa= Triolet) thomas.lavergne@laposte.net = d-12@laposte.net ICQ:#137121910 = http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Jun 8 12:02:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gsq1-0000V5-00 for ; Sun, 09 Jun 2002 04:53:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:53 +0200 (CEST) Received: (qmail 13240 invoked by uid 0); 8 Jun 2002 10:01:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 8 Jun 2002 10:01:53 -0000 Received: by moria.seul.org (Postfix) id 40D81146992; Sat, 8 Jun 2002 06:01:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 34E46146999; Sat, 8 Jun 2002 06:01:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id A0D32146992 for ; Sat, 8 Jun 2002 06:01:48 -0400 (EDT) Received: from ifurita (212.194.222.170) by smtp.laposte.net (5.5.044) id 3CFD28F90003EEA8 for f-cpu@seul.org; Sat, 8 Jun 2002 12:01:48 +0200 Message-ID: <004301c20ed3$93dfc800$aadec2d4@ifurita> From: "Christophe" To: References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] calling conventions Date: Sat, 8 Jun 2002 12:02:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok, to sum up : Caller always push arguments into registers whether they are fixed or variable. It is the responsibility for the callee to get the variable arguments from registers and push them in stack when using va_start. Finally, that slow copy only occurs when using va_start. Not so bad. Besides, if we can count upon just one 'loadm' to do the transfer, well... i don't really see any objection. For the case of "open", I need some info : since there are two forms and in C they share the same name, there must be only one implementation. So "open" implementation has really three arguments. What happens when we call "open" with two arguments ? put a default value on the third argument ? > > Recursive function calls require stack operations too. Other than inline > > macros to hint at function call parameters fixed arg functions still are > > better using off the stack in my view. > > Not really. First of all, a lot of recursive function calls can be > automatically translated to iterative code. A `tail-recursive' call like First, the compiler must be able to handle recursive-to-iterative translation. Not a evidence for all compilers. Second, there is really cases where compiler cannot translate but a programmer can (because programmer can use an explicit stack to save only necessary data during iteration). So recursive function always requires stack operations but as the callee is in charge to save what must callee-saved, for n recursive calls, we just save n-1 times callee-saved registers instead of n if caller-saved. Anyway, for performance, one of two choices : having a great compiler able to translate recursive functions to iterative functions, or translate by ourselves recursive functions into iterative functions. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Jun 8 12:09:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gsq1-0000V5-01 for ; Sun, 09 Jun 2002 04:53:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:53:53 +0200 (CEST) Received: (qmail 24040 invoked by uid 0); 8 Jun 2002 10:09:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 8 Jun 2002 10:09:05 -0000 Received: by moria.seul.org (Postfix) id CC716146997; Sat, 8 Jun 2002 06:09:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8F16E14699A; Sat, 8 Jun 2002 06:09:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id CC369146997 for ; Sat, 8 Jun 2002 06:09:02 -0400 (EDT) Received: from ifurita (212.194.222.170) by smtp.laposte.net (5.5.044) id 3CD7884A0023623E for f-cpu@seul.org; Sat, 8 Jun 2002 12:09:01 +0200 Message-ID: <004901c20ed4$969380e0$aadec2d4@ifurita> From: "Christophe" To: References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> <004301c20ed3$93dfc800$aadec2d4@ifurita> Subject: Re: [f-cpu] calling conventions Date: Sat, 8 Jun 2002 12:09:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > So recursive function always requires stack operations but as the callee is in > charge to save what must callee-saved, for n recursive calls, we just save n-1 > times callee-saved registers instead of n if caller-saved. Hum forget it... it would be n times and not n-1... In fact, what we could reproach against recursivity in imperative languages like C or Pascal, most of those language compilers tend to save redundant and unecessary data in recursive calls. Maybe a very intelligent compiler could just prepend the saving of only necessary data just before a recursive call and append the restoring of necessary data just after a recursive call. Is it feasible ? I dunno... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jun 8 14:14:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqF-0000V5-00 for ; Sun, 09 Jun 2002 04:54:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:07 +0200 (CEST) Received: (qmail 22589 invoked by uid 0); 8 Jun 2002 12:06:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 8 Jun 2002 12:06:42 -0000 Received: by moria.seul.org (Postfix) id AC0DD146999; Sat, 8 Jun 2002 08:06:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 808EB14699C; Sat, 8 Jun 2002 08:06:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 2520A146999 for ; Sat, 8 Jun 2002 08:06:40 -0400 (EDT) Received: from f-cpu.org (kdl16-32.n.club-internet.fr [213.44.18.32]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 97E361729 for ; Sat, 8 Jun 2002 14:06:36 +0200 (CEST) Message-ID: <3D01F50E.4090907@f-cpu.org> Date: Sat, 08 Jun 2002 14:14:06 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <3CD7884A00203AEA@smtp.laposte.net> <20020606014545.22650@thrai.stud.uni-hannover.de> <005201c20d38$114d3f40$d1e0c2d4@ifurita> <20020606192047.13252@thrai.stud.uni-hannover.de> <000901c20da9$56978580$37fbc2d4@ifurita> <20020607011645.34012@thrai.stud.uni-hannover.de> <001701c20dbe$45884120$51922cd5@ifurita> <20020607165833.49185@thrai.stud.uni-hannover.de> <3D0129A6.CD606D44@jetnet.ab.ca> <20020608003709.23126@thrai.stud.uni-hannover.de> <00aa01c20ebd$cf064e60$82215c41@lkhgbopihbpihb9> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, just a quick answer. i didn't follow this thread (i consider this to be too much software-related and i have big HW worries) but here's just a hint... Rob Finch wrote: > My two cents: > > Defining a standard calling convention seems like a good idea to me. One of > the reasons why languages use different conventions may be that no one put > their foot down at the beginning and said you must use these conventions to > be compatible. Heterogenous calling conventions are a big pain. that's looking obvious. However, we have 64 registers and it's another story... > I think regs should be assigned in the following order > r63: return address - most RISC machines use last reg for return address > and you are guarenteed to always need a return address, hence this reg > should be fixed like r0. It is probably better to put it at the end since > the remaining pointers are not always needed why 63 ? because other RISC do it ? that's not a good enough reason. 1) i remember a post from some days ago which speaks about the "special case" of using pairs of registers, it asks what would be the point of using Reg1 xor 1... if you need a return address, then it's a good idea to put it at register #1 because it's not going to be needed in a loop (the idea behind the xor with the register LSB is that it is easier to decode the numbers, check the dependencies and also helps with naming the registers when unrolling loops). 2) the F-CPU ISA says that the return address can be saved by the callee to any register (reg 0 if you don't want to save it). If you are going to nest function calls (in a non-recursive way) then you'd better use a stack in the register set (at least). This is because when you call the inside function, the return address will be moved (either to memory or another register) and the original register will loose the "flags" that associate it to the memory location. So the return will have some cycles of penalty. One good idea (and it doesn't cost that much) is that a few registers (let's say : 4) are reserved for the "leaf" functions. If a function is "leaf" (doesn't call other functions) then the return address will be stored in register #2, a function calling a leaf function will have its own return address in register #3 and so on... If you are going to make a "real men's compiler", however, everything will be flattened and the calling convention will be used to call generic library functions. for what it is worth... > Rob WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Jun 8 15:22:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqI-0000V5-00 for ; Sun, 09 Jun 2002 04:54:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:10 +0200 (CEST) Received: (qmail 18626 invoked by uid 0); 8 Jun 2002 13:22:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 8 Jun 2002 13:22:41 -0000 Received: by moria.seul.org (Postfix) id 3EF2A14699B; Sat, 8 Jun 2002 09:22:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0581F14699D; Sat, 8 Jun 2002 09:22:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by moria.seul.org (Postfix) with ESMTP id 8D39814699B for ; Sat, 8 Jun 2002 09:22:39 -0400 (EDT) Received: from computer ([209.214.154.148]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020608132405.ZIMU1087.imf13bis.bellsouth.net@computer>; Sat, 8 Jun 2002 09:24:05 -0400 Message-ID: <004a01c20eef$8ce6be20$949ad6d1@computer> From: "richard hartny" To: Cc: Subject: [f-cpu] Erin32 Calling Convention Date: Sat, 8 Jun 2002 08:22:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C20EC5.A33682C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C20EC5.A33682C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello from Southern Mississippi: Subroutine Calls are initiated with a simple JST (Jump and Store = Return) instruction. This is the mechanism: LDA Money To pass an argument JST DO CMP Lost DO PZE Initially Zero ADD Anything My design executes the LDA and JST in parallel. The JST stores the = incremented PC in DO, and executes the instruction DO+1. Upon completion of SUBR Called (DO), an Indirect Jump is executed, = JMPN. =20 =20 JMPN DO Return to JST + 1 Priority Interrupts are handled in the same manner; as an Interrupt = is nothing more that a JST I don't have to consider what Register does what, as I don't have = any. My registers are in Operand (Local Memory) . I potentially have = 256K of Registers. Have a good day Richard Hartney Erin Greene & Assiciates Business Information Management Systems =20 ------=_NextPart_000_0047_01C20EC5.A33682C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello from Southern = Mississippi:
 
    Subroutine Calls are = initiated=20 with a simple JST (Jump and Store Return) instruction.  This is the = mechanism:
 
       =20             =    =20     LDA    Money    To pass = an=20 argument
       =20             =    =20     JST     DO
       =20             =    =20     CMP    Lost
 
          &nbs= p;            = ;    =20 DO      PZE    =    =20 Initially Zero
       =20             =    =20     ADD    Anything
 
    My design executes = the LDA and=20 JST in parallel. The JST stores the incremented PC in DO, and executes = the=20 instruction DO+1.
Upon completion of  SUBR Called = (DO), an=20 Indirect Jump is executed, JMPN. 
       =20             =    =20    
       =20             =    =20     JMPN    DO    Return to = JST +=20 1
 
    Priority Interrupts = are handled=20 in the same manner; as an Interrupt is nothing more that a = JST
 
    I don't have to = consider what=20 Register does what, as I don't have any.  My registers are in = Operand=20 (Local Memory) .  I potentially have 256K of = Registers.
 
Have a good day
 
Richard Hartney
Erin Greene & = Assiciates
Business Information Management=20 Systems
       =20             =    =20    
------=_NextPart_000_0047_01C20EC5.A33682C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Jun 8 18:38:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqM-0000V5-01 for ; Sun, 09 Jun 2002 04:54:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:14 +0200 (CEST) Received: (qmail 32238 invoked by uid 0); 8 Jun 2002 16:41:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 8 Jun 2002 16:41:31 -0000 Received: by moria.seul.org (Postfix) id 45F6D14699F; Sat, 8 Jun 2002 12:41:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0FE4E1469A1; Sat, 8 Jun 2002 12:41:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 79E9314699F for ; Sat, 8 Jun 2002 12:41:29 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g58Gg15L078999 for ; Sat, 8 Jun 2002 10:42:02 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D023315.761B7FD8@jetnet.ab.ca> Date: Sat, 08 Jun 2002 10:38:45 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> <004301c20ed3$93dfc800$aadec2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: > since there are two forms and in C they share the same name, there must be only > one implementation. So "open" implementation has really three arguments. What > happens when we call "open" with two arguments ? put a default value on the > third argument ? Did not some computer languages permit subroutine parameters to be predefined. If the argument is omitted the default value is passed keeping the same number of arguments used. > Anyway, for performance, one of two choices : having a great compiler able to > translate recursive functions to iterative functions, or translate by ourselves > recursive functions into iterative functions. Choice #3 ... Have a great cpu that users can work at what ever level they wish with out problems, binary , machine language, high level and very high level languages. It is only about 10% of the code that needs to be optimized and that still is algorithm dependent rather than hardware optimized. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jun 8 20:30:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqN-0000V5-01 for ; Sun, 09 Jun 2002 04:54:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:15 +0200 (CEST) Received: (qmail 5603 invoked by uid 0); 8 Jun 2002 18:14:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 8 Jun 2002 18:14:37 -0000 Received: by moria.seul.org (Postfix) id 35E6B14693B; Sat, 8 Jun 2002 14:14:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 057411469A0; Sat, 8 Jun 2002 14:14:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id A31EC14693B for ; Sat, 8 Jun 2002 14:14:35 -0400 (EDT) Received: from ifrance.com (vlt9-63.n.club-internet.fr [195.36.223.63]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 4512116E4 for ; Sat, 8 Jun 2002 20:14:33 +0200 (CEST) Message-ID: <3D024D3A.3451CF6C@ifrance.com> Date: Sat, 08 Jun 2002 20:30:18 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] manual update References: <200206061250.058f@th00.opsion.fr> <20020606193410.61472@thrai.stud.uni-hannover.de> <3D015791.1040505@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > Michael Riepe wrote: > > > On Thu, Jun 06, 2002 at 12:50:05PM +0000, Nicolas Boulay wrote: > >> p195 Chapter 3 > > [...] > >> - We can't impose that more than 2 register can't point on the same > >> cache line. What happen with : > > Why should we do that? Every register may point everywhere. > > physically, yes. > However there might be a HW limitation for the first versions. > The code will work but might have some thrashing (one or > two cycles of penalty per access where several pointers > point to the same line). > > Please give me some time to explain that. > i started to answer nicO's mail but haven't > finished yet. it's not a simple thing to explain. > In fact, it's very easy to explain. But It's not the strong point of Whygee ;D To speed up things, register adress are used as an inputs inside kind of cache and return the content of a cache line (or more) pointed by the content of the register. So we bypass the register read and we can immediately acceded to the content of the memory before having read the register bank. To verify the integrity, we check the real adresse with the adress read in the register. This memory could react as a caches. But i think that a 64 registers adresse isn't so much and we can use a memory instead of a cache system (with 8 lines instead of 64). The problem are alias what's up if 2 registers write on the same location thought 2 differents pointers ? This line are no more up to date (this unit are the LSU, if i have a good mem). Whygee seems to have found an idea to handel that with 2 pointers. I personnaly beleive that's to much glue logic. This mecanism could be only used for code because it's "mostly" read only, so there no alias problem. But for data, i don't know. I have proposed instead of using the register adress to use the stream number of the load&store instructions. That's the main purpose of the stream : differentiate data stream. nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 8 14:32:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqO-0000V5-00 for ; Sun, 09 Jun 2002 04:54:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:16 +0200 (CEST) Received: (qmail 24237 invoked by uid 0); 8 Jun 2002 18:22:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 8 Jun 2002 18:22:07 -0000 Received: by moria.seul.org (Postfix) id 4B342146998; Sat, 8 Jun 2002 14:22:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F26A31469A1; Sat, 8 Jun 2002 14:22:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 897B5146998 for ; Sat, 8 Jun 2002 14:22:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00660; Sat, 8 Jun 2002 14:32:29 +0200 Message-ID: <20020608143228.55028@thrai.stud.uni-hannover.de> Date: Sat, 8 Jun 2002 14:32:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> <004301c20ed3$93dfc800$aadec2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <004301c20ed3$93dfc800$aadec2d4@ifurita>; from Christophe on Sat, Jun 08, 2002 at 12:02:18PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jun 08, 2002 at 12:02:18PM +0200, Christophe wrote: [...] > For the case of "open", I need some info : > > since there are two forms and in C they share the same name, there must be only > one implementation. So "open" implementation has really three arguments. What > happens when we call "open" with two arguments ? put a default value on the > third argument ? Unfortunately, open() is not part of the ISO C99 standard. It's a POSIX.1 function with a lot of historic background. The third argument is used (and must be provided) if the O_CREATE flag is set in the second argument. One can implement open() as a 3-argument function and simply ignore the additional argument (in C, there is no run-time check for the number of arguments anyway). But the prototype should specify a varargs function. There are other functions that may be declared as having a variable number of arguments: int fcntl (int fd, int cmd, ...); int ioctl (int fd, int cmd, ...); These functions also take at most 3 arguments, but the third argument may have different types. Sometimes it's an `int', sometimes an `int*', a `struct flock*', `struct termios*' and so on. > > > Recursive function calls require stack operations too. Other than inline > > > macros to hint at function call parameters fixed arg functions still are > > > better using off the stack in my view. > > > > Not really. First of all, a lot of recursive function calls can be > > automatically translated to iterative code. A `tail-recursive' call like > > First, the compiler must be able to handle recursive-to-iterative translation. > Not a evidence for all compilers. Since that can be done in the code generator (or machine-specific optimizer), we just have to replace the tail-recursive calling sequence move first_arg, r1 move second_arg, r2 ... move last_arg, r jmp , jmp with move first_arg, r1 move second_arg, r2 ... move last_arg, r jmp and we're done. Note that the second version doesn't even touch the stack. > Second, there is really cases where compiler cannot translate but a programmer > can (because programmer can use an explicit stack to save only necessary data > during iteration). If the compiler can't translate the call, it will have to use the (implicit) stack. But toys^H^H^H^Hcompilers that don't detect and replace tail-recursive calls aren't worth using them. It's one of the most simple optimizations, and quite effective. > So recursive function always requires stack operations but as the callee is in > charge to save what must callee-saved, for n recursive calls, we just save n-1 > times callee-saved registers instead of n if caller-saved. You can also save them once on entry and keep them throughout the recursion, if that's convenient. But that depends on the code (and the compiler). > Anyway, for performance, one of two choices : having a great compiler able to > translate recursive functions to iterative functions, or translate by ourselves > recursive functions into iterative functions. Try to always write *tail-recursive* functions and let the compiler do the rest. That is, instead of int fak(int x) { return x < 2 ? 1 : x * fak(x - 1); } use static int fak2(int x, int y) { return x < 2 ? y : fak2(x - 1, y * x); } int fak(int x) { return fak2(x, 1); } and the compiler should substitute int fak(int x) { int y = 1; while (x >= 2) { y *= x; x -= 1; } return y; } -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 8 13:33:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqQ-0000V5-00 for ; Sun, 09 Jun 2002 04:54:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:18 +0200 (CEST) Received: (qmail 19146 invoked by uid 0); 8 Jun 2002 18:22:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 8 Jun 2002 18:22:10 -0000 Received: by moria.seul.org (Postfix) id 8D4031469A0; Sat, 8 Jun 2002 14:22:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B0521469A3; Sat, 8 Jun 2002 14:22:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 5A9661469A0 for ; Sat, 8 Jun 2002 14:22:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00435; Sat, 8 Jun 2002 13:33:59 +0200 Message-ID: <20020608133359.16889@thrai.stud.uni-hannover.de> Date: Sat, 8 Jun 2002 13:33:59 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] manual update References: <200206061250.058f@th00.opsion.fr> <20020606193410.61472@thrai.stud.uni-hannover.de> <3D015791.1040505@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D015791.1040505@f-cpu.org>; from Yann Guidon on Sat, Jun 08, 2002 at 03:02:09AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jun 08, 2002 at 03:02:09AM +0200, Yann Guidon wrote: > hi, > > Michael Riepe wrote: > > > On Thu, Jun 06, 2002 at 12:50:05PM +0000, Nicolas Boulay wrote: > >> p195 Chapter 3 > > [...] > >> - We can't impose that more than 2 register can't point on the same > >> cache line. What happen with : > > Why should we do that? Every register may point everywhere. > > physically, yes. > However there might be a HW limitation for the first versions. > The code will work but might have some thrashing (one or > two cycles of penalty per access where several pointers > point to the same line). I see. In that case, the manual should read: `There may be hardware limitations that cause the F-CPU to run slower when more than two registers ...' but not `... only two registers can point to the same cache line at a time, the four register must reference two different streams.' which is simply wrong. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 8 20:28:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqV-0000V5-00 for ; Sun, 09 Jun 2002 04:54:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:23 +0200 (CEST) Received: (qmail 9870 invoked by uid 0); 8 Jun 2002 22:50:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 8 Jun 2002 22:50:59 -0000 Received: by moria.seul.org (Postfix) id D43A31467FC; Sat, 8 Jun 2002 18:50:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A154414691F; Sat, 8 Jun 2002 18:50:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a145.home.uni-hannover.de [130.75.232.145]) by moria.seul.org (Postfix) with ESMTP id 1513A1467FC for ; Sat, 8 Jun 2002 18:50:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA02092; Sat, 8 Jun 2002 20:28:02 +0200 Message-ID: <20020608202802.32347@thrai.stud.uni-hannover.de> Date: Sat, 8 Jun 2002 20:28:02 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> <004301c20ed3$93dfc800$aadec2d4@ifurita> <3D023315.761B7FD8@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D023315.761B7FD8@jetnet.ab.ca>; from Ben Franchuk on Sat, Jun 08, 2002 at 10:38:45AM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jun 08, 2002 at 10:38:45AM -0600, Ben Franchuk wrote: [...] > > Anyway, for performance, one of two choices : having a great compiler able to > > translate recursive functions to iterative functions, or translate by ourselves > > recursive functions into iterative functions. > > Choice #3 ... Have a great cpu that users can work at what ever level > they wish with out problems, binary , machine language, high level and > very high level languages. Don't worry, when the F-CPU is finished I'll take all the modules I need and build a Lisp Machine :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 9 03:22:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17GsqY-0000V5-01 for ; Sun, 09 Jun 2002 04:54:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 04:54:26 +0200 (CEST) Received: (qmail 22972 invoked by uid 0); 9 Jun 2002 01:14:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Jun 2002 01:14:46 -0000 Received: by moria.seul.org (Postfix) id 495801469A4; Sat, 8 Jun 2002 21:14:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D4D31469A8; Sat, 8 Jun 2002 21:14:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 875561469A5 for ; Sat, 8 Jun 2002 21:14:44 -0400 (EDT) Received: from f-cpu.org (kro1-4.n.club-internet.fr [213.44.93.4]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 44F1C1699 for ; Sun, 9 Jun 2002 03:14:42 +0200 (CEST) Message-ID: <3D02ADC4.7000507@f-cpu.org> Date: Sun, 09 Jun 2002 03:22:12 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Another proposition for a call convention References: <200206071058.1876@th00.opsion.fr> <20020607183103.04279@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Though this is not such a HW-related topic, i'm trying to cleanup my mailbox and read some of the mails... Michael Riepe wrote: > The `global pointer' register is an invention of mine; it is supposed > to point to a well-defined address inside the address space of a process > (e.g. at the beginning of the .data segment), in order to ease addressing: > with a global pointer, you can use pointer-relative addressing for global > data (and probably also for code), avoiding time-consuming relocations > at load time (which in turn improves shareability of code pages). An > additional `local pointer' will be useful for shared libraries; but we > can also use one of the `callee-saved' registers for that. In those discussions, you seem to forget one point : the "stack" is accessed through load and stores that only accept "register" addressing. Register post-increment is an addition that allows you to emulate "push" and "pop". If you want to access the stack in "random"/arbitrary order, you'll have first to copy the stack pointer (or whatever base pointer, frame pointer, whatever closest) and use several post-incremented loads and stores, possibly needing several copies of the original stack pointer if you need to interleave consecutive reads or writes. If you can stay inside the register set, do it. You can leave arrays outside (it's more practical for pointer stuffs) but leave the counters and all other management stuff inside the register set... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Jun 9 05:36:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Gub8-00020D-00 for ; Sun, 09 Jun 2002 06:46:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 09 Jun 2002 06:46:38 +0200 (CEST) Received: (qmail 1102 invoked by uid 0); 9 Jun 2002 03:39:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 9 Jun 2002 03:39:14 -0000 Received: by moria.seul.org (Postfix) id 30083146926; Sat, 8 Jun 2002 23:39:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EAB2B1469A8; Sat, 8 Jun 2002 23:39:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 72453146926 for ; Sat, 8 Jun 2002 23:39:12 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g593dj5L081044 for ; Sat, 8 Jun 2002 21:39:46 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D02CD3C.95F3B09@jetnet.ab.ca> Date: Sat, 08 Jun 2002 21:36:28 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] calling conventions References: <37D1208A1C9BD511855B00D0B772242C0118AD6D@corpmail1.sc.sonicblue.com> <20020606195310.38597@thrai.stud.uni-hannover.de> <3D000B28.48E93EF9@jetnet.ab.ca> <20020607164301.30298@thrai.stud.uni-hannover.de> <004301c20ed3$93dfc800$aadec2d4@ifurita> <3D023315.761B7FD8@jetnet.ab.ca> <20020608202802.32347@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > On Sat, Jun 08, 2002 at 10:38:45AM -0600, Ben Franchuk wrote: > [...] > > > Anyway, for performance, one of two choices : having a great compiler able to > > > translate recursive functions to iterative functions, or translate by ourselves > > > recursive functions into iterative functions. > > > > Choice #3 ... Have a great cpu that users can work at what ever level > > they wish with out problems, binary , machine language, high level and > > very high level languages. > > Don't worry, when the F-CPU is finished I'll take all the modules I need > and build a Lisp Machine :) I think it almost would be better to create a semi-reprogramable machine and then you can optimize for several kinds of virtual machines. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 10 01:55:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17HEjz-0005hW-00 for ; Mon, 10 Jun 2002 04:17:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Jun 2002 04:17:07 +0200 (CEST) Received: (qmail 27851 invoked by uid 0); 9 Jun 2002 23:48:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Jun 2002 23:48:25 -0000 Received: by moria.seul.org (Postfix) id D5DA51467E9; Sun, 9 Jun 2002 19:48:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1F601467EE; Sun, 9 Jun 2002 19:48:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 576D01467E9 for ; Sun, 9 Jun 2002 19:48:23 -0400 (EDT) Received: from f-cpu.org (kdl16-5.n.club-internet.fr [213.44.18.5]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8445C1797 for ; Mon, 10 Jun 2002 01:48:17 +0200 (CEST) Message-ID: <3D03EB06.3000609@f-cpu.org> Date: Mon, 10 Jun 2002 01:55:50 +0200 From: Yann Guidon Organization: http://www.f-cpu.org User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; m18) Gecko/20001106 Netscape6/6.0 X-Accept-Language: en-us, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: (LSU!) Re: [f-cpu] manual update X-Priority: 2 (high) References: <200206061250.058f@th00.opsion.fr> <20020606193410.61472@thrai.stud.uni-hannover.de> <3D015791.1040505@f-cpu.org> <3D024D3A.3451CF6C@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > In fact, it's very easy to explain. But It's not the strong point of > Whygee ;D it's a problem with more people than you'd agree... And please read this post carefully, it's probably the clearest thing i could write. The invalidation problem is certainly a big point that you have not yet addressed and that has forced me to abandon the rough idea you have. > To speed up things, register adress are used as an inputs inside kind > of cache and return the content of a cache line (or more) pointed by the > content of the register. So we bypass the register read and we can > immediately acceded to the content of the memory before having read the > register bank. To verify the integrity, we check the real adresse with > the adress read in the register. no need to check the integrity afterwards. The address and the register's contents MUST be coherent at the time the load/store/jump instruction is issued. Otherwise, what would be the benefit ? Of course, race conditions must be avoided (and they can appear everywhere because the latency is pretty high) but they must be solved "by design", not by explicit coherency checks... > This memory could react as a caches. But i think that a 64 registers > adresse isn't so much and we can use a memory instead of a cache system > (with 8 lines instead of 64). in theory you have a point. Except that you open a big can of worms and 64 lines is really a lot, small FPGAs could not contain that. The LSU is also a multiported memory and more lines would make the chip even bigger. I estimate that the FC0 clock speed is limited by the register set (and possibly by the Xbar), so if you add another big array, you further slow the clock down. Finally, the alias problems appear. Data duplication is often a sign of bad design, particularly when it is in the critical path... Don't forget that the LSU has to speak directly with the cache and at least one I/O (otherwise, where would the informations come ???) which is certainly not 256 bit wide. Furthermore, writes must have a byte-granularity and store some "dirty" flags. Finally, how would you separate the instructions from the data ? (because the registers can point to both types) Would there be a big block from which instructions are read and data are read/written ? then that would be a multiported block, at least with 5 read ports and 4 write ports. The Register set already totals 5 ports and it's a big slow piece of silicon... The original idea of 8 lines for the LSU and 8 lines for the fetcher is not such a bad idea. The critical datapath is already a problem but it can be pipelined. The register-line associativity problem is the price to pay, if we want to work at reasonable speeds and use a reasonable amount of silicon (though i already know the usual objections to these arguments). Here is the central problem : When a LSU line is flushed (selected by the LRU mechanism, and a line must be replaced with data coming from the cache) you have to reverse-map the allocation between the registers and the lines. And this part is extremely important : if you do it slowly, there are more risks of race conditions... The reverse mapping is usually done by a CAM, just like what i do with the configuration i promote now. Except that my CAM has at less entries than yours. And i use the CAM (comparators) at the decode stage, while you need the comparators at the time of replacement. That's the structural difference, but it can become important. > The problem are alias not if you design your system to avoid this condition. > what's up if 2 registers write on the same > location thought 2 differents pointers ? This line are no more up to > date (this unit are the LSU, if i have a good mem). In the current LSU system, writes and reads are serialised (race conditions can be detected and avoided). If your program is correctly designed (that is : the order of the operations is important, as it usually is the case) i don't see why there would be a problem. Of course, if your system promotes data duplication, alias and coherency are some of the many inherent problems. Another problem is that the unit is larger --> consumes more power and is slower... > Whygee seems to have found an idea to handel that with 2 pointers. I > personnaly beleive that's to much glue logic. there is a compromise to do at one point. The goal is to reduce the amount of logic to the minimum. (As written above, less logic = less surface = less power = faster) You have to agree (otherwise there's something wong) that a reverse-mapping mechanism is necessary : when the LRU logic of the line indicates which line to evict >from the LSU or the Fetcher (because we need a line for data coming from main RAM or caches), you have to invalidate the registers that were associated to this line (so that any use of this register as a pointer will trigger another line replacement). LRU makes data replication impossible and transparent to the programmer, but some coherency maintainance is necessary. Remember that the mechanism you propose was the "simple" solution i first found : looks nice and fast, but the invalidation logic is an order of magnitude more complex. If i give you the number of the line that is being invalidated, how do you invalidate the numbers ? - first solution : each LSU and fetcher line has another 63-bit wide field, with each bit representing the associated register. When the line is invalidated, the corresponding bit is sent to reset the "valid" flag of the register. ===> note that this means that we have a minimum of 63*16 bits of memory. The 63-bit field contains the same information as the information stored by the register flag, except that the encoding is a bit different. 63*16=1008 bits of memory, the quarter of the size of the normal register set. That's much. And the wires are pretty long and they are a lot : it's not a good thing for the surface, the speed, etc. - second solution : use a "CAM", put 2x 4-bit comparators at each regsister flag (we have to be able to invalidate both LSU and fetcher lines at the same time). The flag contains 6 bits : 1 "Checked" bit, 1 "valid" bit, 1 Instruction/data bit and 3 line bits (the address). When the correct line address is detected on the 2x3-bit input (coming from the LSU and Fetcher), the flags are cleared. ====> that's better : only 3*63 bits of storage (a total of 400 bits when we also count the other flags). However you have to compare 126 values ! Even though the comparators are 3-bits each, that's a lot. Here, notice that i take your assumption that full associativity is required. All 63 registers can be used as pointers at a time (as long as the addressed space fits inside the LSU capacity). - Whygee's solution : take a program and count how many pointers can be used at a time. Count on the LRU to evict pointers that were not used for a certain time... I'll put the upper limit arbitrarily to 32, but it can't exceed 63 anyway. A limit of 24 would be more realistic (it still leaves some room for a SW call stack) but let's say it's a user-defined parameter. This number also represents the number of comparators. They are 6-bit wide because they compare the register number (that comes from the instruction word) with the number that is locally stored (between the LSU and the fetcher). An additional flag will indicate whether the data is valid, or we could also reset the value to 0 (register #0 is invalid as a pointer). With 32 register comparators, we need 32 comparators of 6 bits = 192 bits of storage. If that's too much, use only 24 comparators and you need 144 bits. The "counting argument" is one of the many points. Another point is the drive : with the 2nd solution, the invalidation step needs that 6 wires (from the LSU and the fetcher) feed 63 inputs each. With my solution, we need 6 wires to drive 32 inputs each with the register to find. The last (and most interesting argument) is that invalidation doesn't need to propagate invalidation signals through long wires : for speed and locality reasons, the comparators are next or very close to the lines to which they are associated. When a match is detected, they can send the "hit" signal to the line faster than with the 2nd solution, which has to decode the register number, then decode the line number. That's a 2-level indirection (6->63 then 3->8) that is probably not faster than comparators because of the wire lengths. Note that the problem can become different in a superscalar architecture. Decoding only one instruction per cycle has the advantage of simplicity but a 2- or 3-instruction wide CPU will certainly require another strategy... Concerning the association between a register and a line, it is not necessarily "one to one" : it is possible to associate a register to several lines (3 or 4) and the reverse is necessarily possible (a line can be pointed to by more than one register). This depends on the number of comparators. It adds some storage (it needs to know which line is associated to which register) but not inside the critical datapath (it's managed by the LRU mechanics in a single cycle). Concerning the register invalidation process, the signal comes >from the LRU mechanism, which is triggered by the replacement logic, which is itself used when a new cache line is fetched for example. With nicO's approach (multi-CPU system that can "share" cache lines), it can also come from a remote CPU but it's his business, the mechanism is the same. > This mecanism could be only used for code because it's "mostly" read > only, so there no alias problem. But for data, i don't know. If you say you don't know... :-P Concerning aliases : they must be avoided "by design". The address that comes from the TLB is compared with all the other addresses in the fetcher and the LSU ==> no line will answer at the beginning. The least recently use line will be selected to hold the data. Later, when the address is wanted again, only ONE line will answer. This is independent >from the register number. pointer alias does not necessarily mean duplication of the data with the existing LSU. > I have proposed instead of using the register adress to use the stream number > of the load&store instructions. ? maybe i didn't understand. > That's the main purpose of the stream : differentiate data stream. at least you have understood the principle ;-) but this story is different from the story of associating registers to pointers. Remember that there is no "stream hint" for the jump instructions, but the jump uses the same mechanism as load and store. happy voting, > nicO >> WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 10 08:03:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17HQNX-0000Fw-00 for ; Mon, 10 Jun 2002 16:42:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Jun 2002 16:42:43 +0200 (CEST) Received: (qmail 19401 invoked by uid 0); 10 Jun 2002 14:21:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Jun 2002 14:21:26 -0000 Received: by moria.seul.org (Postfix) id 53BDB1467F3; Mon, 10 Jun 2002 10:21:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D1E81467F9; Mon, 10 Jun 2002 10:21:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a191.home.uni-hannover.de [130.75.232.191]) by moria.seul.org (Postfix) with ESMTP id 639FA1467F3 for ; Mon, 10 Jun 2002 10:21:23 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id IAA27517; Mon, 10 Jun 2002 08:03:28 +0200 Message-ID: <20020610080328.57416@thrai.stud.uni-hannover.de> Date: Mon, 10 Jun 2002 08:03:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: (LSU!) Re: [f-cpu] manual update References: <200206061250.058f@th00.opsion.fr> <20020606193410.61472@thrai.stud.uni-hannover.de> <3D015791.1040505@f-cpu.org> <3D024D3A.3451CF6C@ifrance.com> <3D03EB06.3000609@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D03EB06.3000609@f-cpu.org>; from Yann Guidon on Mon, Jun 10, 2002 at 01:55:50AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 10, 2002 at 01:55:50AM +0200, Yann Guidon wrote: > hi, > > nico wrote: > > > In fact, it's very easy to explain. But It's not the strong point of > > Whygee ;D > it's a problem with more people than you'd agree... > > And please read this post carefully, it's probably the clearest > thing i could write. The invalidation problem is certainly > a big point that you have not yet addressed and that has forced > me to abandon the rough idea you have. [...] Unfortunately, it's not at all clear what you two are talking about. Maybe if I had attended your meetings in Paris on a regular basis... Let me see if I get things straight. When the instruction decoder encounters a load or store instruction, it extracts the register number (r2) and tries to find the associated LSU line (or lets the LSU do it). That is, there is a 64 -> 8 (or 6-bit -> 3-bit) mapping required if we have 8 LSU lines. Right so far? If the register has no associated LSU line, the least recently used line is flushed, its current association to a register is `broken', then data is fetched from the cache into the LSU, and finally the line is linked to the new register. Still right? I understand that this is a shortcut for the normal read register -> lookup LSU line by address -> read/write LSU line procedure which will take a lot of cycles (decode, register read, Xbar, LSU lookup, LSU read/write). I also understand that the process of associating a register with an LSU line is normally triggered by the `loadaddr' instruction, not by a `load' or `store'. And I understand that the `reverse mapping' from LSU lines to register numbers is necessary in order to clear any `forward' mappings when an LSU line is flushed. But is that really a timing-critical operation? Isn't it sufficient to invalidate the line immediately and clear the forward mappings later, before the line is re-validated? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jun 10 17:14:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17HW07-00059a-00 for ; Mon, 10 Jun 2002 22:42:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Jun 2002 22:42:55 +0200 (CEST) Received: (qmail 6939 invoked by uid 0); 10 Jun 2002 15:15:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 10 Jun 2002 15:15:17 -0000 Received: by moria.seul.org (Postfix) id 963751467F5; Mon, 10 Jun 2002 11:15:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E4261467FA; Mon, 10 Jun 2002 11:15:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 090F71467F5 for ; Mon, 10 Jun 2002 11:15:15 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206101514.3ad3; Mon, 10 Jun 2002 15:14:58 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:(LSU!) Re: [f-cpu] manual update From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jun 2002 15:14:58 GMT Message-id: <200206101514.3ad3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 10/06/02 Objet: (LSU!) Re: [f-cpu] manual update hi, nico wrote: > In fact, it's very easy to explain. But It's not the stron= g point of > Whygee ;D it's a problem with more people than you'd agree... And please read this post carefully, it's probably the clear= est thing i could write. The invalidation problem is certainly a big point that you have not yet addressed and that has for= ced me to abandon the rough idea you have. > To speed up things, register adress are used as an inputs = inside kind > of cache and return the content of a cache line (or more) = pointed by the > content of the register. So we bypass the register read an= d we can > immediately acceded to the content of the memory before ha= ving read the > register bank. To verify the integrity, we check the real = adresse with > the adress read in the register. no need to check the integrity afterwards. The address and t= he register's contents MUST be coherent at the time the load/st= ore/jump instruction is issued. Otherwise, what would be the benefit = ? >>> more parrallel operations. At the verification stage you= could stop to start a load.=20 Of course, race conditions must be avoided (and they can app= ear everywhere because the latency is pretty high) but they must= be solved "by design", not by explicit coherency checks... >>> Yes ! But how ? > This memory could react as a caches. But i think that a 64= registers > adresse isn't so much and we can use a memory instead of a= cache system > (with 8 lines instead of 64). in theory you have a point. Except that you open a big can of worms and 64 lines is really a lot, small FPGAs could not contain that. The LSU is also a multiported >>> Small FPGA couldn't handel the mul unit ! Big fpga could have ~100 000 bits of storage by block of 400= 0 bits. This isn't a problem at all. This memory could have 2 port (one w= rite, one read) memory and more lines would make the chip even bigger. I estimate that the FC0 clock speed is limited by the register set (and possibly by the Xbar), so if you add another big array, you further slow the clock down. >>> The true bloquing point are the number of port to the re= gister bank !! Finally, the alias problems appear. Data duplication is often a sign of bad design, particularly when it is in the critical path... Don't forget that the LSU has to speak directly with the cache and at least one I/O (otherwise, where would the informations come ???) which is certainly not 256 bit wide. >>> It speak only with the data bus for the data part and wi= th the instruction bus for the program part (harvard architecture).= That's all. Furthermore, writes must have a byte-granularity and store some "dirty" flags. Finally, how would you separate the instructions from the data ? (because the registers can poin= t >>> The hint aren't done by the same instruction. to both types) Would there be a big block from which instruc= tions are read and data are read/written ? then that would be a multiported block, at least with 5 read ports and 4 write ports. The Register set already totals 5 ports and it's a big slow piece of silicon... >>>> ???? The original idea of 8 lines for the LSU and 8 lines for the= fetcher is not such a bad idea. The critical datapath is already a p= roblem but it can be pipelined. The register-line associativity pro= blem >>> Cache like system is much slower than simple RAM. is the price to pay, if we want to work at reasonable speeds and use a reasonable amount of silicon (though i already kno= w the usual objections to these arguments). Here is the centra= l problem : When a LSU line is flushed (selected by the LRU mechanism, a= nd a line must be replaced with data coming from the cache) you have to reverse-map the allocation between the registers and the lines. And this part is extremely impo= rtant : if you do it slowly, there are more risks of race conditions= ... The reverse mapping is usually done by a CAM, just like what= i do with the configuration i promote now. Except that my CAM has at less entries than yours. And i use the CAM (comparators) at the decode stage, while you need the comparators at the t= ime of replacement. That's the structural difference, but it can become important. >>> True CAM are much too slow. Array of comparateur are muc= h bigger than a decoder. (a CAM is only a cache system with as associ= ativity as the number of line). A cache system always need a strategy t= o be filled up. Here, no need of that ! Hint that a register contain a pointer -> corresponding line= are filled with instruction. In case of data, i didn't use register but stream number. > The problem are alias not if you design your system to avoid this condition. > what's up if 2 registers write on the same > location thought 2 differents pointers ? This line are no = more up to > date (this unit are the LSU, if i have a good mem). In the current LSU system, writes and reads are serialised (race conditions can be dete= cted and avoided). If your program is correctly designed (that is= : the order of the operations is important, as it usually is t= he case) i don't see why there would be a problem. >>> you assert that. Compiler will be to much tricky, if the= alias problem is remaining. Of course, if your system promotes data duplication, alias and coherency are some of the many inherent problems. Another problem is that the unit is larger --> consumes more power and is slower... >>> That's the problem ! > Whygee seems to have found an idea to handel that with 2 p= ointers. I > personnaly beleive that's to much glue logic. there is a compromise to do at one point. The goal is to reduce the amount of logic to the minimum. (As written above, less logic =3D less surface =3D less powe= r =3D faster) You have to agree (otherwise there's something wong) that a reverse-mapping mechanism is necessary : when the LRU logic of the line indicates which line to evict >from the LSU or the Fetcher (because we need a line for data coming from main RAM or caches), you have to invalidate the registers that were associated to this line (so that any use of this register as a pointer will trigger another line replacement).=20 >>> That's sure. That's how cache work. LRU makes data replication impossible and transparent to the programmer, but some coherency mainta= inance is necessary. >>> There is no coherency between the true adresse and the m= emory content. You never used the true adresse of the data, so ? Remember that the mechanism you propose was the "simple" solution i first found : looks nice and fast, but the invalidation logic is an order of magnitude more complex. If i give you the number of the line that is being invalidat= ed, how do you invalidate the numbers ? - first solution : each LSU and fetcher line has another 63-bit wide field, with each bit representing the associated register. When the line is invalidated, the corresponding bi= t is sent to reset the "valid" flag of the register. =3D=3D=3D> note that this means that we have a minimum of 63*16 bits of memory. The 63-bit field contains the same information as the information stored by the register flag, except that the encoding is a bit diff= erent. 63*16=3D1008 bits of memory, the quarter of the size of the normal register set. That's much. And the wires are pretty l= ong and they are a lot : it's not a good thing for the surface, the speed, etc. >>> that's what is called tag memory plan of a cache ? - second solution : use a "CAM", put 2x 4-bit comparators = at each regsister flag (we have to be able to invalidate bo= th LSU and fetcher lines at the same time). The flag contai= ns 6 bits : 1 "Checked" bit, 1 "valid" bit, 1 Instruction/d= ata bit and 3 line bits (the address). When the correct line add= ress is detected on the 2x3-bit input (coming from the LSU and F= etcher), the flags are cleared. =3D=3D=3D=3D> that's better : only 3*63 bits of storage (a t= otal of 400 bits when we also count the other flags). However you have to com= pare 126 values ! Even though the comparators are 3-bits each, th= at's a lot. >>> I didn't really understood what is the index of the cam = and what is the indexed data. Here, notice that i take your assumption that full associati= vity is required. All 63 registers can be used as pointers at a t= ime (as long as the addressed space fits inside the LSU capacity= ). - Whygee's solution : take a program and count how many pointers can be used at a = time. Count on the LRU to evict pointers that were not used for a = certain time... I'll put the upper limit arbitrarily to 32, but it can't exc= eed 63 anyway. A limit of 24 would be more realistic (it still leav= es some room for a SW call stack) but let's say it's a user-def= ined parameter. This number also represents the number of comparators. They are 6-bit wide because they compare the register number (that comes from the instruction word) with the number that = is locally stored (between the LSU and the fetcher). An additio= nal flag will indicate whether the data is valid, or we could al= so reset the value to 0 (register #0 is invalid as a pointer). With 32 register comparators, we need 32 comparators of 6 bits =3D 192 bits of storage. If that's too much, use only 24 comparators and you need 144 bits. The "counting argument" is one of the many points. Another p= oint is the drive : with the 2nd solution, the invalidation step needs that 6 wires (from the LSU and the fetcher) feed 63 in= puts each. With my solution, we need 6 wires to drive 32 inputs each wi= th the register to find. The last (and most interesting argument) is that invalidatio= n doesn't need to propagate invalidation signals through long = wires : for speed and locality reasons, the comparators are next or = very close to the lines to which they are associated. When a match is d= etected, they can send the "hit" signal to the line faster than with = the 2nd solution, which has to decode the register number, then deco= de the line number. That's a 2-level indirection (6->63 then 3->8) that is probably not faster than comparators because of the = wire lengths. Note that the problem can become different in a superscalar architecture. Decoding only one instruction per cycle has the advantage of simplicity but a 2- or 3-instruction wide CPU will certainly require another strategy... Concerning the association between a register and a line, it= is not necessarily "one to one" : it is possible to associate a register to several lines (3 or 4) and the reverse is nece= ssarily possible (a line can be pointed to by more than one register= ). This depends on the number of comparators. It adds some stor= age (it needs to know which line is associated to which register= ) but not inside the critical datapath (it's managed by the LR= U mechanics in a single cycle). >>> But don't see how you could find that 2 prefetch lines h= ave the same adress. That's our problem. All other speak are about a cach= e technique design.=20 Concerning the register invalidation process, the signal com= es >from the LRU mechanism, which is triggered by the replacemen= t logic, which is itself used when a new cache line is fetched for ex= ample. With nicO's approach (multi-CPU system that can "share" cach= e lines), >>> ??? shared a cache ??? Do you speak about the L2 inside = a multicpu chip ? it can also come from a remote CPU but it's his business, the mechanism is the same. > This mecanism could be only used for code because it's "mo= stly" read > only, so there no alias problem. But for data, i don't kno= w. If you say you don't know... :-P Concerning aliases : they must be avoided "by design". >>> By the program, you mean ? The address that comes from the TLB is compared with all the other addresses in the fetcher and the LSU =3D=3D> no line will answer at the beginning. The least recently use line will be selected to hold the data. Later, when the address is wanted again, only ONE line will answer. This is independ= ent >from the register number. pointer alias does not necessarily mean duplication of the data with the existing LSU. >>> Ok ! When you want to fill the LSU, you compare each sto= re adress by the adresse of soon store cache line. So a line could be ass= ociated with more than a register. So you need a memory that contain the = link between line of LSU and the register. In case of read, you make reg@->line#->content of the memory= . That 2 read of 63*6 bits and any(8)*cache line. In case of filling, you need 8 comparators of 64 bits to de= tectet alias. I have understood ! It's exactly how "write buffer"/"prefetc= h buffer" work.=20 > I have proposed instead of using the register adress to us= e the stream number > of the load&store instructions. ? maybe i didn't understand. >>> intead of linking register adress and data, i prefer to = link data stream and memory. That's the goal of memory stream ! Not ch= ecking coherency between them. > That's the main purpose of the stream : differentiate data= stream.=20 at least you have understood the principle ;-) but this story is different from the story of associating registers to pointers. Remember that there is no "stream hin= t" for the jump instructions, but the jump uses the same mechanism as load and store. >>> That's why i speak about data for memory stream number a= nd register adress for instruction. happy voting, >>> Soon maid ! It's closed since 20h :p nicO > nicO >> WHYGEE WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From info@french-union.com Mon Jun 10 18:59:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17HW09-00059a-00 for ; Mon, 10 Jun 2002 22:42:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 10 Jun 2002 22:42:57 +0200 (CEST) Received: (qmail 13255 invoked by uid 0); 10 Jun 2002 15:56:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Jun 2002 15:56:46 -0000 Received: by moria.seul.org (Postfix) id D294F1467F3; Mon, 10 Jun 2002 11:56:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AC7B51467F9; Mon, 10 Jun 2002 11:56:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id 3B6C01467F3 for ; Mon, 10 Jun 2002 11:56:43 -0400 (EDT) Received: from french-union (lns09v-7-2.w.club-internet.fr [212.194.186.2]) by relay-3m.club-internet.fr (Postfix) with SMTP id 649BCE05B for ; Mon, 10 Jun 2002 17:56:40 +0200 (CEST) From: French Union To: f-cpu@seul.org Subject: [f-cpu] Hello, X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Date: Mon, 10 Jun 2002 17:59:14 +0100 Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0299_01C21091.AC89A780" Message-Id: <20020610155640.649BCE05B@relay-3m.club-internet.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0299_01C21091.AC89A780 Content-Type: multipart/alternative; boundary="----=_NextPart_001_029A_01C21091.AC89A780" ------=_NextPart_001_029A_01C21091.AC89A780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear Ladies and Gentlemen, Many men and women have found good friends or are now happily married as = a result of our free service. You can too! Our website = www.french-union.com=20 ------=_NextPart_001_029A_01C21091.AC89A780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 3D""

Dear Ladies and = Gentlemen,

Many men and women have found good friends or are now = happily=20 married as a result of our free service. You can too! Our website www.french-union.com=20

------=_NextPart_001_029A_01C21091.AC89A780-- ------=_NextPart_000_0299_01C21091.AC89A780 Content-Type: application/octet-stream; name="logo.jpg" Content-Transfer-Encoding: base64 Content-ID: <029401c21080$dc54d2c0$fd50c2d4@stef> /9j/4AAQSkZJRgABAgECWAJYAAD/7Qu0UGhvdG9zaG9wIDMuMAA4QklNA+0KUmVzb2x1dGlvbgAA AAAQAlgAAAACAAICWAAAAAIAAjhCSU0EDRhGWCBHbG9iYWwgTGlnaHRpbmcgQW5nbGUAAAAABAAA AHg4QklNBBkSRlggR2xvYmFsIEFsdGl0dWRlAAAAAAQAAAAeOEJJTQPzC1ByaW50IEZsYWdzAAAA CQAAAAAAAAAAAQA4QklNBAoOQ29weXJpZ2h0IEZsYWcAAAAAAQAAOEJJTScQFEphcGFuZXNlIFBy aW50IEZsYWdzAAAAAAoAAQAAAAAAAAACOEJJTQP1F0NvbG9yIEhhbGZ0b25lIFNldHRpbmdzAAAA SAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1 AAAAAQAtAAAABgAAAAAAAThCSU0D+BdDb2xvciBUcmFuc2ZlciBTZXR0aW5ncwAAAHAAAP////// //////////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIBkd1 aWRlcwAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHg1VUkwgb3ZlcnJpZGVzAAAABAAAAAA4QklN BBoGU2xpY2VzAAAAAGkAAAAGAAAAAAAAAAAAAAAyAAAAlgAAAAQAbABvAGcAbwAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAlgAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAOEJJTQQREUlDQyBVbnRhZ2dlZCBGbGFnAAAAAQEAOEJJTQQUF0xheWVyIElEIEdlbmVy YXRvciBCYXNlAAAABAAAAAo4QklNBAwVTmV3IFdpbmRvd3MgVGh1bWJuYWlsAAAIFwAAAAEAAABw AAAAJQAAAVAAADCQAAAH+wAYAAH/2P/gABBKRklGAAECAQBIAEgAAP/uAA5BZG9iZQBkgAAAAAH/ 2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACUAcAMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEB AQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIE AgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRai soMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dn d4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl 9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AKKZzmsa57zta0FznHgAaucnS3tY C9x2tYC5zvAAcrcaCGrOwrntrpyGWPfOxrZl0au2e33bUZYWBWaegW5DbrRe2l9fpnT0nB++ttXt bczd9P6ez9KpW2ZOMKBZk3W4uUx1jbveTW8tZDbfR/TW+kze5lX6H9N/xahGY8IMhuBLTaPEyGAs gHrX2O2kdAXHgak/BYGTddtvfVlZTPSxKbamuMOdYXNZ+lZD/ps9+xitVZlf7QD77Mht7cg7K2Nc an0PDfs//BMpbX+nt/wiIzAmqr6o4HTqtquYLKXiys6B7dQY81GzJxqbGV22trss+gx0y6Tt9v8A aWL0p99TOn1U2kPuryA+m4v9IOD3vpmto3V7vpe1Xsu2ym3Ef1Bv6Bps3W4oeRXYdv2ez3fptzff /I3pRy3Diqj6b/d9XD/36TCjXn5tyjIx8lhfj2NuY07S5moB52qe9m8V7h6hbuDJ922du/b+7uWF i2utGFScm6nfflfaHMmswYurc5jmuYzfuUaMvOsoqdXY9+WcC0gGZNjbXN4/032Qb2Joz6DT7P8A B0/56vbegg+CSwbsxtlGS/AfkU4zBQGusc/eLi/9LtLnWOd+rH9Kz+bWl0959XOoNz720XxW+wy7 YR+9DW7d4cnxyiUgK363p+l/3iDChbcSSSUix//QjRgstwLry/bkw+zFp/0lWPs+3v8A61frN9P/ AIjIUcbpnUcmtl2NQ6xjyRWQWguLfp+kx722Wtr/AMJZWzZWj1dczKLMUY7nV4mI1jPsm6WWAa5P re33OzHPt9T2q30yzpzbcHPu2NZ08PrYDkBr66g619NVuL6X2jKva279DZiP9HJ/7ULYMpxBNeXX /B/RaYETQcr7Lm/ZhmljvRLBYLNzd3puOxl/o7/tDaHO/wAP6XpIl3TeqYxb6tFjHW2ek0AhzjYf c2l7Knveyx7ffW23+cRP2u93T247mWNvGMzFc5tgFWxgbXv9EVervdUzY+v7R9m/wnpqTesOrysj KqpAdkZYyy0u0gNuqfQ5zW7vezJd+m/waN5NdB1/sVUe5Qnp/Um3Gksh7G+o4+rVsa3d6W6zI9X7 PX+k/R++3fvQLm5GPY+i8OqsrJbZW7QgjxVvEz8PCbbRi0XV4t7WCwesw2h1ZLqnV2Oo9HZsd6Tq 7KH/AOk/nEG7MZfnvyrqi9j5Brc4WEDZ6Ncvta5lr6/a/wDSVel/wfpogzs2NK/l+kgiNboHG0Et eXA/nNMz/aBR6+n9Qc2myqlxGSYoIc0F8gu3NZv9T09rH77XN9Gv/CPRM/PxstssxBRcbC9924OL gZ9roYz+R/wf6P8AQ11pU9SNORi3trn7NjfZHjdBewixtjq37f0Lv03s+n70iZ1YFHsVVG92IwOp OsNQYXOFYtJFlZZ6ZO0XfaPU+zuq3+3f6vsSb07qllt1PpPD8dwbcHvawNefoM33PZW+x/0q21uf vYp5fUm5FF2OGWGu2gUtN1jXuB9VuU+xza6qafdt2enVXX/pE93UcTKa6rMxnvo3ssqbXaGOa5tN WFa1znVWMfVczHY76HqU/mPQ4snYfy/wk1HuhGH1B2N9tFbzQGGzfubu9MaOu9Hf9o9D/hvS9JT/ AGV1LdSLanMZbZXUHucwhvrEek57fU3Vte3+b9T0/VU/2hjy3K9B46jXR9mbYHj0IFbsRl76dnre q3Hds9Ftv2ex/wCkTHqTDkZVwpI+1HEMbhLRiOqfDnbPf6/of9a/lpXk7D+R/vKqLC7pWdW+0NqN ldVzqA9pb73h3pBtVYe59ljnOZ+jq9TYhZOHlYu37QzYH7gxzXMsaSw7bGepQ+2v1K/z693qKweq ubkY+RVUG2YuVflMDjIPrvFvpaNbt2Nb6fqKOdntya6qq22trrc5/wCmsbYS5waz2iqrHrbsa36W z1X/AOESBnYsCuqCI60//9Gil+XsvOEluNB9HSXnCSSn0dJecJJKfR0l5wkkp9HSXnCSSn0dJecJ JKfR0l5wkkp//9kAOEJJTQQhGlZlcnNpb24gY29tcGF0aWJpbGl0eSBpbmZvAAAAAFUAAAABAQAA AA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQA bwBzAGgAbwBwACAANgAuADAAAAABADhCSU0EBgxKUEVHIFF1YWxpdHkAAAAABwACAAAAAQEA/+4A DkFkb2JlAGSAAAAAAf/bAIQACAYGBgYGCAYGCAwIBwgMDgoICAoOEA0NDg0NEBEMDAwMDAwRDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEJCAgJCgkLCQkLDgsNCw4RDg4ODhERDAwMDAwREQwM DAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAMgCWAwEiAAIRAQMRAf/dAAQA Cv/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAAAQACAwQF BgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPBUtHhMxZi 8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWF laW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5 KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEyobHwFMHR 4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp0+PzhJSk tMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5 iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AK82bNnUOrdmwh81mWPTkngnlgkWV F5QyMlQ5o3LiRywLZ3MlrHeavNHfRpboKWdy8nDiTuymZ5DJIKf8V/6uUyziOQwI5Cyf6Pf9jMY7 jxXz2rzZRmwig8zQzM8ZtJUmpEIojxJdphyRQa0X4fj+L9jHSeYDEt4Ws3P1JVaVkdWXc7rzG3Ne vDD4+Kr4tt+h6c/uR4c+VJ3mwktvMkMs8cM9tLbLLC1wksgAUqg5N/lfZ/axSDWJri5trd7N0hvU MkUoLEqvHkDJRFRCw/kmdlxGfGaqV2a5Hn+CvhyHMeab5siWma3NZWk095HPcRfW2gNwzhgorxRQ rNy+H9r4clBnt3JhEy8zVeKsOVfahrXHHmjMWNj3Hz5LKBif0qubIbJ68Gk316t3dSW7B0tbgzyF laJyod1r8PquOHw/5PwLywxh1htOj0+xNvPdy3MCzLJz9R2JHJ68iW6/7DIR1Eb9Q4dge/6jUfmy OI9De9fLmyHNkbuNfW5srS7iSeHndi3dFZFb1BX92/IN+7b9qmDZNZmP1yS0tRNBYMyXEhk4Esg5 SLEvBufD/LaPJjPjPXuPInmLY+HLuTfNhHJ5jQXMVtb2ktx68C3MJioSyN0qv7PxfCeWGGl6jFqt lHewqyJJUcW6gqSp6fLDHLCUuGMrO/2KYSAsjZGZs2bLGLs2bNir/9ArzYe+XLCwnM1zqm1qxWyh bwnuaqsnygQPL/wGFo0y+bUH0uOFpLxHaIxKN+SE8v8AYin2s6XxI8Uo8uHck8nWcJoHvY/r+n3e p2i2tqY0+NZHeUttw3UAKprXFNStby/0ia0AiW6mQI3xN6YJ+1RuHL/hMkN1oeqWUYlnt/3TOsSy RskqM7hiqK0TOrt8DfZx15oOrWEDXF1b8YkYJIVdHMbHosqxszRN/wAZAuQIxEyPEP3g4eY393+m ZeoAbfSb5MPv9Eu7zSLW2jkSC/teDLIjNwLInpH4wofdP8nEW0nXpbG6s55bURyQiG3hiDJGCSCz t8BbYDbJvceXtYtYJLie1KJEA0g5IXVTsHMYYyen/wAWceGMXRNTaz+v+iFtyrSKzvGjMi/aeON2 WSRRT7SJkTjwn1cfMcJqWx2+9PFMbVy35MNm0O+uJrEymEQwWj2lxR3LH1EMbMnwDp1+LLs7DzPb rb20l5bG1gZQzKG9Vo0IolSvH4lHFv8AjbJpF5f1ia1F5HbFomQyqOaCRox1kSEt6zp/lLHhZhjh xkkxkbvfhl9hr+qpnKqIFdLDFm8v6odJlsAbf1JLr6zy5vxAPxFf7v8AmGH8enWCyC5+pwJcV5mR Y15Bj1IfiG/2WCyrKaMCDQGh22IqD92CLKwu9RlaGyiM0iqXZVpsoIBben82Sjixw37gBv04eX3s TOUtvu82FHy9rkFrcaXZXcB02YtwEob1FDblRRSPxwbDpWprfaZdSiDjZQGCUK71YkFarWPw45Mo vL+rTyzRRwqTbsqSyGaIRhmHJVEzOInZh+yj4yLQtWmnuLdLZhLakC5DlUEfKvEuzlVVdvt/ZysY sI5T5Ua4rEQDxR+DIzmf4ed9PmwQeX9WFnHb1t+Ud99er6j0Iofg/uvfHXmha4st6ml3cUdnqDmS aOSvJWkFJOJ4N1ycfoXVPr36N+rMbunPgCCOFOXqcwfT9Pj/ALs5cMs6Jqf1xbFYRJOyGUCKSORe ArVzLGzRBV4nkxf4cHgYKrjI2uxKjw8v9KnxMnd17urEbfRruz1O2uoTE9vbWYswGdg7FatzICMo q3+Vgny9p11pWmrZXRjZ0ZirREkEMeW/JU33ySy6HqkNzb2rQVlujxtijpIkjVpxSWNmiJFfi+PL n0HVbZYnng4LM4iVi8dFkO/py0b9y/8AkzcMnGGGMhKMh1rcfxc/9wxJmQQR3Xt3f2pdmw9v/LF9 Fqt7YWMZmitXp6jPGKIxYI0rclRK8Dy5ceOBrfy7rF2peC35AO0a1kjXm6GjrCGcetx/4q55YMuO r4gBQO572PBK6opXmx3pyep6XA+pXjwoeXKtONOta5smh//REzaytlp9jpumGGaNEM9201vFKDcy n4gBcxPT0o1SPkn2sMDqVrqNxJe8m+s3+nPDqrRREmCRCoNzxUBTHMka+r6X2VeT/VyJYta3VzZT pc2krQzJ9mRDQiux+8Z0Zwxqx9W+/fe+7rRM9eW2zKLKa10fRormK4F+ttq1rPII1dYvhimNI/WW JzJxX4v3f++/tYjqGpWSWd6ttfQzNeAIIobMRSFeayf6RKyp04/7qaT95hFe6nf6jwF5MZFjr6aA BUWvUqiBUBNN/hwJgjh34pHe76H3dEnJtQ5UyKfVLJ9Z1a7E1Ybm2migfi3xM0YRFpTkNx+1id8+ laskV6+ofVZoraOF7N4pGPOCMRqIWQGP05OHL43ThywhzZIYgKIJBAAvbkEcZ3sA3uzJddsHkg1N buG3lhhjU2/1MSXAeKMR0imK+kY24/BzlXgn7GRew+qG6X67QQ0b7XPhy4nhz9IGT0+dOXp/HgXN jHEIggE7iumwUzJq+jIryTy9Pbzv6lbsRxJFxEtKx28SKIuQpx9VZFf115cfs/zYXaTdxWi6h6rl DPZyQRUBNXdk+H4fFQ3XC7NhGMCPDZI25+SDLe6AZHpOpWZ0kabcTQWskU7zq9zbm4jcSKin7KSs sient8PxK2N1DV7e5g1SMXBkab6pHA3pCL1FtwVb4EqqKvw8OR5ccj2bI+DHiMt9zfTv4v0J4zVf juZLHqunuiWcszRxT6YllLcIjExSpN6267FozxVJOH7LYja/omzF3p36REkd/AEN7HFKqROsiyBG V1WZ4n4fvOEf/B4QZsPhDeiRe/Tn38l4z3BlWm3ul6NJp9q16t0Ev47y5uIkk9KJI1KcU5oskjPy 5ScY/wDdaYT293Cmi6haSP8A6RPPayRoQTyEYn9Q8qcdvUT7WFubEYhubJJIJP8AVPEvGflf2sj1 TVbK4k8wmCYst/cxSW3wsOaK7uTuBx6qfjwRaatYTWWnrNdQWktinpOk1p9Yc0kaQPbuFbc8/sSN H+8+LIpmweDHhEbOxB6dI8C+Ibv8c7R/6QP6a/SnJq/WfrPPgvL+89Tl6f8Ad8u/D7GbAGbJ8Ee7 pw/BHEftt//SK82cTzZ1Dq3tmbOJ5sVe2Zs4nmxV7ZmziebFXtmbOJ5sVe2Zs4nmxV7ZmziebFXt mbOJ5sVe2Zs4nmxV7ZmziebFX//Z ------=_NextPart_000_0299_01C21091.AC89A780-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jun 11 20:06:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Hqsg-0000Ly-00 for ; Tue, 11 Jun 2002 21:00:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Jun 2002 21:00:38 +0200 (CEST) Received: (qmail 26225 invoked by uid 0); 11 Jun 2002 18:08:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jun 2002 18:08:45 -0000 Received: by moria.seul.org (Postfix) id C7EC9146817; Tue, 11 Jun 2002 14:08:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B72CA14681E; Tue, 11 Jun 2002 14:08:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a167.home.uni-hannover.de [130.75.232.167]) by moria.seul.org (Postfix) with ESMTP id AD861146817 for ; Tue, 11 Jun 2002 14:08:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00897; Tue, 11 Jun 2002 20:06:54 +0200 Message-ID: <20020611200654.28476@thrai.stud.uni-hannover.de> Date: Tue, 11 Jun 2002 20:06:54 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] There's something going wrong here... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just found out that I have a CVS account on tuxfamily.org and that obviously the F-CPU sources are now located there (or shall be, at least). Of course nobody told me about it before, as usual. What's it gonna be, boys? Homepage and CVS moving *again*? We already have *too many* homepages and *too many* source trees scattered all over the web - but even ten thousand web sites can't speed up the F-CPU development. They may slow it down, however. Besides that, I still refuse to put my code-in-progress into a remote CVS, for reasons I stated several times, long ago - remember my dial-up line? I also refuse to work with a site which talks to me in a language I don't understand, i.e. everything but english or german. Therefore, I do not support this move. I suggest that you (whoever initiated this) concentrate on the design and implementation of the F-CPU and tools and stop `collecting' homepages and CVS archives. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Tue Jun 11 20:39:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Hqsh-0000Ly-01 for ; Tue, 11 Jun 2002 21:00:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 11 Jun 2002 21:00:39 +0200 (CEST) Received: (qmail 29270 invoked by uid 0); 11 Jun 2002 18:42:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jun 2002 18:42:21 -0000 Received: by moria.seul.org (Postfix) id E33CB1467FE; Tue, 11 Jun 2002 14:42:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C1D5614681E; Tue, 11 Jun 2002 14:42:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id 3735A1467FE for ; Tue, 11 Jun 2002 14:42:19 -0400 (EDT) Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 17HqXs-0007ib-00; Tue, 11 Jun 2002 20:39:08 +0200 Date: Tue, 11 Jun 2002 20:39:08 +0200 From: Paul Marques Mota To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... Message-ID: <20020611203908.A15803@opium.april.org> Mail-Followup-To: Paul Marques Mota , f-cpu@seul.org References: <20020611200654.28476@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020611200654.28476@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Tue, Jun 11, 2002 at 08:06:54PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jun 11, 2002 at 08:06:54PM +0200, Michael Riepe wrote: > I just found out that I have a CVS account on tuxfamily.org and that > obviously the F-CPU sources are now located there (or shall be, at least). > Of course nobody told me about it before, as usual. > > What's it gonna be, boys? Homepage and CVS moving *again*? We already > have *too many* homepages and *too many* source trees scattered all > over the web - but even ten thousand web sites can't speed up the F-CPU > development. They may slow it down, however. > I am setting up a CVS repository on seul.org because of that, and my short term plan is to move everything on f-cpu.seul.org. I was in Karlsruhe this week end, so things have been delayed somewhat. > Besides that, I still refuse to put my code-in-progress into a remote CVS, > for reasons I stated several times, long ago I found out that the gaos pserver does not appears to work. > - remember my dial-up line? ssh -C is your friend ;) > I also refuse to work with a site which talks to me in a language I > don't understand, i.e. everything but english or german. > > Therefore, I do not support this move. I suggest that you (whoever > initiated this) concentrate on the design and implementation of the > F-CPU and tools and stop `collecting' homepages and CVS archives. > > Michael "Tired" Riepe -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From daique@skynet.be Tue Jun 11 21:33:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0C-0000FC-00 for ; Wed, 12 Jun 2002 21:41:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:41:56 +0200 (CEST) Received: (qmail 23492 invoked by uid 0); 11 Jun 2002 19:34:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Jun 2002 19:34:15 -0000 Received: by moria.seul.org (Postfix) id C24791467F5; Tue, 11 Jun 2002 15:34:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 96CBE14681D; Tue, 11 Jun 2002 15:34:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from durendal.skynet.be (durendal.skynet.be [195.238.3.91]) by moria.seul.org (Postfix) with ESMTP id BDD6D1467F5 for ; Tue, 11 Jun 2002 15:34:12 -0400 (EDT) Received: from ced.daique.be (adsl-72146.turboline.skynet.be [217.136.153.210]) by durendal.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g5BJXDH24592 for ; Tue, 11 Jun 2002 21:33:13 +0200 (MET DST) (envelope-from ) Received: (from ced@localhost) by ced.daique.be (8.12.2/8.11.6/Cedric De Wilde - 02/08/20) id g5BJX8Pf000964 for f-cpu@seul.org; Tue, 11 Jun 2002 21:33:08 +0200 Date: Tue, 11 Jun 2002 21:33:08 +0200 From: Cedric De Wilde To: f-cpu@seul.org Subject: [f-cpu] Re: There's something going wrong here... Message-ID: <20020611193308.GA791@ced> References: <20020611200654.28476@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020611200654.28476@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i X-Operating-System: GNU/Linux-2.4.18 (i686) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jun 11, 2002 at 08:06:54PM +0200, Michael Riepe wrote: > I just found out that I have a CVS account on tuxfamily.org and that > obviously the F-CPU sources are now located there (or shall be, at least). > Of course nobody told me about it before, as usual. > > What's it gonna be, boys? Homepage and CVS moving *again*? We already > have *too many* homepages and *too many* source trees scattered all > over the web - but even ten thousand web sites can't speed up the F-CPU > development. They may slow it down, however. > We need to reorganize. When someone is interested by the f-cpu, he has to go to http://www.f-cpu.org/ , http://www.f-cpu.de/ and http://f-cpu.seul.org/ , he has to pick up some informations at different places, most of theses web sites are not up to date. Just look the manual, on f-cpu.org and f-cpu.de, it's the 0.2, on seul, it's 0.2.1 however the last one is 0.2.5. > Besides that, I still refuse to put my code-in-progress into a remote CVS, > for reasons I stated several times, long ago - remember my dial-up line? > I also refuse to work with a site which talks to me in a language I > don't understand, i.e. everything but english or german. > I've installed daCode on tuxfamily, it remain some bugs and it's not oficially launched. The site still in beta, we need to test. Of course, official News will be in english. > Therefore, I do not support this move. I suggest that you (whoever > initiated this) concentrate on the design and implementation of the > F-CPU and tools and stop `collecting' homepages and CVS archives. > I'm the new webmaster, I can update the website alone, like this, you can continue to work the f-cpu without thinking about the web site. For CVS, there will only remain tuxfamily and seul for backup and that's all. Daique ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 12 00:19:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0F-0000FC-00 for ; Wed, 12 Jun 2002 21:41:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:41:59 +0200 (CEST) Received: (qmail 32681 invoked by uid 0); 11 Jun 2002 22:19:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 11 Jun 2002 22:19:55 -0000 Received: by moria.seul.org (Postfix) id 69C731467FF; Tue, 11 Jun 2002 18:19:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4864514681E; Tue, 11 Jun 2002 18:19:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a054.home.uni-hannover.de [130.75.232.54]) by moria.seul.org (Postfix) with ESMTP id D03931467FF for ; Tue, 11 Jun 2002 18:19:50 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02843; Wed, 12 Jun 2002 00:19:53 +0200 Message-ID: <20020612001953.22872@thrai.stud.uni-hannover.de> Date: Wed, 12 Jun 2002 00:19:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <20020611203908.A15803@opium.april.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020611203908.A15803@opium.april.org>; from Paul Marques Mota on Tue, Jun 11, 2002 at 08:39:08PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jun 11, 2002 at 08:39:08PM +0200, Paul Marques Mota wrote: [...] > > Besides that, I still refuse to put my code-in-progress into a remote CVS, > > for reasons I stated several times, long ago > > I found out that the gaos pserver does not appears to work. I don't care - I use CVS locally. > > - remember my dial-up line? > > ssh -C is your friend ;) That doesn't help me pay the bills either. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 12 00:28:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0G-0000FC-00 for ; Wed, 12 Jun 2002 21:42:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:00 +0200 (CEST) Received: (qmail 1360 invoked by uid 0); 11 Jun 2002 22:28:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 11 Jun 2002 22:28:20 -0000 Received: by moria.seul.org (Postfix) id 8270F1467FF; Tue, 11 Jun 2002 18:28:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6684814681E; Tue, 11 Jun 2002 18:28:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a054.home.uni-hannover.de [130.75.232.54]) by moria.seul.org (Postfix) with ESMTP id 56B8E1467FF for ; Tue, 11 Jun 2002 18:28:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02869; Wed, 12 Jun 2002 00:28:15 +0200 Message-ID: <20020612002815.11593@thrai.stud.uni-hannover.de> Date: Wed, 12 Jun 2002 00:28:15 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Re: There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <20020611193308.GA791@ced> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020611193308.GA791@ced>; from Cedric De Wilde on Tue, Jun 11, 2002 at 09:33:08PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jun 11, 2002 at 09:33:08PM +0200, Cedric De Wilde wrote: [...] > We need to reorganize. When someone is interested by the f-cpu, he has > to go to http://www.f-cpu.org/ , http://www.f-cpu.de/ and > http://f-cpu.seul.org/ , he has to pick up some informations at > different places, most of theses web sites are not up to date. Just look > the manual, on f-cpu.org and f-cpu.de, it's the 0.2, on seul, it's 0.2.1 > however the last one is 0.2.5. And the best idea you had was to add *yet another* new site? Go sit in a corner. > > Besides that, I still refuse to put my code-in-progress into a remote CVS, > > for reasons I stated several times, long ago - remember my dial-up line? > > I also refuse to work with a site which talks to me in a language I > > don't understand, i.e. everything but english or german. > > > > I've installed daCode on tuxfamily, it remain some bugs and it's not > oficially launched. The site still in beta, we need to test. Of course, > official News will be in english. I don't care any longer. > > Therefore, I do not support this move. I suggest that you (whoever > > initiated this) concentrate on the design and implementation of the > > F-CPU and tools and stop `collecting' homepages and CVS archives. > > > > I'm the new webmaster, I can update the website alone, like this, you > can continue to work the f-cpu without thinking about the web site. For > CVS, there will only remain tuxfamily and seul for backup and that's > all. What this project really needs is somebody who kicks off all those who say "we need to reorganize" but never wrote a fucking line of VHDL code in their sad lives. I'm tired of this kind of shit. It literally makes me SICK! Under these conditions, you should not count on me any longer. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From daique@skynet.be Wed Jun 12 07:08:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0J-0000FC-01 for ; Wed, 12 Jun 2002 21:42:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:03 +0200 (CEST) Received: (qmail 5845 invoked by uid 0); 12 Jun 2002 05:11:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Jun 2002 05:11:51 -0000 Received: by moria.seul.org (Postfix) id E9BC01467F1; Wed, 12 Jun 2002 01:11:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFD9E1467FF; Wed, 12 Jun 2002 01:11:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from riker.skynet.be (riker.skynet.be [195.238.3.89]) by moria.seul.org (Postfix) with ESMTP id B56A11467F1 for ; Wed, 12 Jun 2002 01:11:47 -0400 (EDT) Received: from ced.daique.be (adsl-72633.turboline.skynet.be [217.136.155.185]) by riker.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g5C5Bi920546 for ; Wed, 12 Jun 2002 07:11:44 +0200 (MET DST) (envelope-from ) Received: (from ced@localhost) by ced.daique.be (8.12.2/8.11.6/Cedric De Wilde - 02/08/20) id g5C581oi000237 for f-cpu@seul.org; Wed, 12 Jun 2002 07:08:01 +0200 Date: Wed, 12 Jun 2002 07:08:01 +0200 From: Cedric De Wilde To: f-cpu@seul.org Subject: [f-cpu] Re: There's something going wrong here... Message-ID: <20020612050801.GA208@ced> References: <20020611200654.28476@thrai.stud.uni-hannover.de> <20020611193308.GA791@ced> <20020612002815.11593@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020612002815.11593@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i X-Operating-System: GNU/Linux-2.4.18 (i686) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 12:28:15AM +0200, Michael Riepe wrote: > On Tue, Jun 11, 2002 at 09:33:08PM +0200, Cedric De Wilde wrote: > And the best idea you had was to add *yet another* new site? > Go sit in a corner. > The 3 others will be redirected to the new when it'll be ready. > What this project really needs is somebody who kicks off all those who > say "we need to reorganize" but never wrote a fucking line of VHDL code > in their sad lives. > I'm not a developper and I haven't the required level to wrote a line of VHDL, I just wan't to help the f-cpu with my modest capabilities. > I'm tired of this kind of shit. It literally makes me SICK! > Under these conditions, you should not count on me any longer. > Hey! When I asked some months ago if I can help, it wasn't my intention to make someone sick. If you wan't I leave and stop the new web site, say it. The f-cpu project need you more than me. Daique ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jun 12 10:14:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0N-0000FC-00 for ; Wed, 12 Jun 2002 21:42:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:07 +0200 (CEST) Received: (qmail 26299 invoked by uid 0); 12 Jun 2002 08:14:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 12 Jun 2002 08:14:20 -0000 Received: by moria.seul.org (Postfix) id 43F6A1467F1; Wed, 12 Jun 2002 04:14:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00D4C14680B; Wed, 12 Jun 2002 04:14:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 65F3A1467F1 for ; Wed, 12 Jun 2002 04:14:18 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-2.free.fr (Postfix) with ESMTP id EDA975FDE4 for ; Wed, 12 Jun 2002 10:14:16 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id D086D580FC; Wed, 12 Jun 2002 10:14:11 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Communication problem Message-ID: <1023869649.3d0702d19d9b1@imp.free.fr> Date: Wed, 12 Jun 2002 10:14:09 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi everybody, It seems to be a communication problem on the French mailing List. A lot of people joined this list and they say it is difficult to join the project because the website is not up-to-date. Some of these new guys have the time and the knowledge to quickly create a dynamic website. This is why some of them where working on tuxfamily. The french team have selected this host, because we know some people in this french association. They give us some possibility to have subdomain like seul.f-cpu.org that can redirect us to f-cpu.seul.org. So when this will be ready we can switch the f-cpu.org to this site (of course it will be in English). Thus, we will have a single access point that will redirect to the actual website on an address basis After what Paul and Daique were working on two different CVS. One whant to sync it with gaos and the other create a new one from scratch. But none of them know what the other is doing. When Yann discovered that, we were making a propsition on what to do with seul.org and tuxfamily.org. It appear a consensus on the french to use seul.org for private account and backup like what it does at the time beeing and to use tuxfamily when it will be ready for f-cpu.org. And now the communication problem appears, I wrote a mail, that was not clear on the french mailing-list and Daique thought this was a decision and not a proposition. So he started to work before we make a common proposition on the english mailing-list. I hope I have do it now and I was clear. But you must know that I only have a stupid modem at 28k and wasn't previously able to download cvs from f-cpu.gaos.org, because it contains a lot of very big files. (I didn't have an unlimited connexion, and I think that most of us have the same problem). So I think that we must take care on what we upload on the CVS. I think that the most important thing we must upload on the CVS is the manual, but perhaps I am wrong, and we must discuss on this now on this mailing-list. Cheers Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Jun 12 11:55:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0O-0000FC-01 for ; Wed, 12 Jun 2002 21:42:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:08 +0200 (CEST) Received: (qmail 19724 invoked by uid 0); 12 Jun 2002 09:55:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 12 Jun 2002 09:55:29 -0000 Received: by moria.seul.org (Postfix) id 70FC91467F1; Wed, 12 Jun 2002 05:55:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 258DF146809; Wed, 12 Jun 2002 05:55:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 9F5B01467F1 for ; Wed, 12 Jun 2002 05:55:27 -0400 (EDT) Received: from ifurita (212.194.223.121) by smtp.laposte.net (5.5.044) id 3D05FC530001360D for f-cpu@seul.org; Wed, 12 Jun 2002 11:55:26 +0200 Message-ID: <000901c211f7$51e128a0$79dfc2d4@ifurita> From: "Christophe" To: References: <20020611200654.28476@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] There's something going wrong here... Date: Wed, 12 Jun 2002 11:55:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N First, any developpements outside CVS is a nightmare to synchronise. You are developped their own versions in your corner and it is a real mess when I try to have a complete version. I'm really fed up with downloading big archives because people are unable to synchronize their works in a global repositary. This project is meant to be developped by a team, so we need a configuration software, that is CVS or likes. I prefer to get the last updates instead of downloading the whole archive everytime, so that way I'm sure that I get the real last developpement. A project without CVS cannot be seriously considered. All good programmers know very well that fact. What we just want is : - english-spoken - a main homepage frequently updated (news, manual on-line, etc.) - a main CVS repositary for source tuxfamily.org was chosen for this purpose. If there are other homepages, we should consider moving interesting stuff in the main homepage, so we can really concentrate our works on a main homepage and a main CVS repositary. Mirroring can be considered on other servers. ----- Original Message ----- From: Michael Riepe To: F-CPU Mailing List Sent: Tuesday, June 11, 2002 8:06 PM Subject: [f-cpu] There's something going wrong here... > I just found out that I have a CVS account on tuxfamily.org and that > obviously the F-CPU sources are now located there (or shall be, at least). > Of course nobody told me about it before, as usual. > > What's it gonna be, boys? Homepage and CVS moving *again*? We already > have *too many* homepages and *too many* source trees scattered all > over the web - but even ten thousand web sites can't speed up the F-CPU > development. They may slow it down, however. > > Besides that, I still refuse to put my code-in-progress into a remote CVS, > for reasons I stated several times, long ago - remember my dial-up line? > I also refuse to work with a site which talks to me in a language I > don't understand, i.e. everything but english or german. > > Therefore, I do not support this move. I suggest that you (whoever > initiated this) concentrate on the design and implementation of the > F-CPU and tools and stop `collecting' homepages and CVS archives. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jun 12 13:29:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0S-0000FC-00 for ; Wed, 12 Jun 2002 21:42:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:12 +0200 (CEST) Received: (qmail 7664 invoked by uid 0); 12 Jun 2002 11:29:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Jun 2002 11:29:50 -0000 Received: by moria.seul.org (Postfix) id 7E2FE146806; Wed, 12 Jun 2002 07:29:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4ABB814680B; Wed, 12 Jun 2002 07:29:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 9D45F146806 for ; Wed, 12 Jun 2002 07:29:43 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206121129.20b9; Wed, 12 Jun 2002 11:29:32 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Stay calm(e) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jun 2002 11:29:32 GMT Message-id: <200206121129.20b9@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N oups ! Stay calme everyone ! I know there is far too much web site or internet tools for = FCPU. But the big problem is to have a true maintener for this site.=20 Daique is maybe doing things too quick and forgot to speak a= bout it on main english mailling list.=20 We used "mostly" test file on CVS and i beleive that is not = too big even for a dial-up line (i use my self a dial up line). The insta= ll is not finish yet. Directory should be decide now.=20 I have work a little bit with CVS on a team developpement an= d it's really fun and quick, if every one respect some rules. Cedri= c propose to use read only CVS + a maintener per part to avoid problems. I personnaly think it's a good idea. Daique propose to maint= ain all of this. Let him do it. Regards, nicO -----Message d'origine----- De: "Christophe" A: Date: 12/06/02 Objet: Re: [f-cpu] There's something going wrong here... First, any developpements outside CVS is a nightmare to sync= hronise. You are developped their own versions in your corner and it is a rea= l mess when I try to have a complete version. I'm really fed up with downloadi= ng big archives because people are unable to synchronize their works in a gl= obal repositary. This project is meant to be developped by a team, so we need= a configuration software, that is CVS or likes. I prefer to get the last updates instead of downloading the = whole archive everytime, so that way I'm sure that I get the real last dev= eloppement. A project without CVS cannot be seriously considered. All go= od programmers know very well that fact. What we just want is : - english-spoken - a main homepage frequently updated (news, manual on-line, = etc.) - a main CVS repositary for source tuxfamily.org was chosen for this purpose. If there are other homepages, we should consider moving inte= resting stuff in the main homepage, so we can really concentrate our works on= a main homepage and a main CVS repositary. Mirroring can be considered on ot= her servers. ----- Original Message ----- From: Michael Riepe To: F-CPU Mailing List Sent: Tuesday, June 11, 2002 8:06 PM Subject: [f-cpu] There's something going wrong here... > I just found out that I have a CVS account on tuxfamily.or= g and that > obviously the F-CPU sources are now located there (or shal= l be, at least). > Of course nobody told me about it before, as usual. > > What's it gonna be, boys? Homepage and CVS moving *again*?= We already > have *too many* homepages and *too many* source trees scat= tered all > over the web - but even ten thousand web sites can't speed= up the F-CPU > development. They may slow it down, however. > > Besides that, I still refuse to put my code-in-progress in= to a remote CVS, > for reasons I stated several times, long ago - remember my= dial-up line? > I also refuse to work with a site which talks to me in a l= anguage I > don't understand, i.e. everything but english or german. > > Therefore, I do not support this move. I suggest that you = (whoever > initiated this) concentrate on the design and implementati= on of the > F-CPU and tools and stop `collecting' homepages and CVS ar= chives. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > **********************************************************= *** > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org= / ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jun 12 17:58:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0W-0000FC-01 for ; Wed, 12 Jun 2002 21:42:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:16 +0200 (CEST) Received: (qmail 20754 invoked by uid 0); 12 Jun 2002 16:01:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 12 Jun 2002 16:01:31 -0000 Received: by moria.seul.org (Postfix) id D5E38146809; Wed, 12 Jun 2002 12:01:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9CFB14680C; Wed, 12 Jun 2002 12:01:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 41F84146809 for ; Wed, 12 Jun 2002 12:01:29 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-211.jetnet.ab.ca [207.34.60.211]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g5CG2C5L093811 for ; Wed, 12 Jun 2002 10:02:13 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D076FB2.B9C9A8A4@jetnet.ab.ca> Date: Wed, 12 Jun 2002 09:58:42 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe wrote: (snip -- what we want) > - english-spoken > - a main homepage frequently updated (news, manual on-line, etc.) > - a main CVS repositary for source Updated Doc's. Call me naive but barring inline documentation why does seem that the entire source for the F-CPU would not fit on a floppy??? If the design is truly modular why can't source be kept on a lot of local drives, and the TEAM leader handle module updates?? To me basic CPU that is 50% functional is a good start. Watching some Japanese Anime "Hand Maid May" a cute story about a 1/6 scale maid cyberdoll has got me about AI in general and why computer science has not made any real new developments since the 1960's. ( I don't consider OBJECTS a development ). Like all good SI-Fi stories you got a evolving AI. Computer hardware and software is not made for incremental changes like organic systems,but rather massive system upgrades with lots of programers. Both hardware and computer languages need to be revised for better handling of pseudo constants like word width and screen sizes as well as having a hyper-text style of control flow, data flow and constant and name and function dependancies. While as programer/hardware developer I like the computer to handle the mindless tasks but I want final say in what is generated and be-able view all generated data. Open Source to me is open source every where on the chain, hardware or software. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 12 17:10:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0Y-0000FC-00 for ; Wed, 12 Jun 2002 21:42:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:18 +0200 (CEST) Received: (qmail 26279 invoked by uid 0); 12 Jun 2002 16:44:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 12 Jun 2002 16:44:55 -0000 Received: by moria.seul.org (Postfix) id 9224114680B; Wed, 12 Jun 2002 12:44:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 68EFC146812; Wed, 12 Jun 2002 12:44:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id 1F71814680B for ; Wed, 12 Jun 2002 12:44:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00808; Wed, 12 Jun 2002 17:10:06 +0200 Message-ID: <20020612171005.45745@thrai.stud.uni-hannover.de> Date: Wed, 12 Jun 2002 17:10:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000901c211f7$51e128a0$79dfc2d4@ifurita>; from Christophe on Wed, Jun 12, 2002 at 11:55:42AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 11:55:42AM +0200, Christophe wrote: > First, any developpements outside CVS is a nightmare to synchronise. You are > developped their own versions in your corner and it is a real mess when I try > to have a complete version. I'm really fed up with downloading big archives > because people are unable to synchronize their works in a global repositary. And I'm really fed up with having to go online (and pay for it!) just to see the recent changes in my code (cvs diff) or similar things. No, thank you. Since I'm the one who does a big part of the work, you'll have to let me choose my tools myself. That is, I use my local CVS and make a new release when my changes are stable (and working, of course!). The last one wasn't big either - 28014 bytes (.tar.gz). I've seen HTML documents that were much longer. There's no reason to complain about `big archives'. > This project is meant to be developped by a team, so we need a configuration > software, that is CVS or likes. Let me tell you how we do things inside this project (those who do something, at least): Everybody has his own `playground'. I work on some of the execution units, Yann works on other units, some people do the manual translations, and so on. Ideally, there are no intersections (and if there are some, we will define the interface by mutual agreement). If you think a change in e.g. the Add/Subtract Unit is necessary, you'll have to talk to the author/maintainer (that's me). And you'll have to convince me that your idea is worth considering (or that you found a bug). If I agree with you, I'll change the code, test it(!), and make a new release. We're NOT doing `bazaar-style' development. Deal with it. You may grab all my releases and import them into the main CVS if you like (and I really do mean `cvs import', with `-d', `-ko' and `-I!' flags set). Of course you'll have to convince Yann not to include my code into his archives as well. > I prefer to get the last updates instead of downloading the whole archive > everytime, so that way I'm sure that I get the real last developpement. Sorry, but you're not supposed to see the work-in-progress states at all. I'll not release code that obviously isn't working (or doesn't do what it's supposed to). > A project without CVS cannot be seriously considered. All good programmers know > very well that fact. Bullshit. > What we just want is : > > - english-spoken > - a main homepage frequently updated (news, manual on-line, etc.) > - a main CVS repositary for source I agree fully with the first point, and partially with the second (yes, I want the manual on-line too!). Project-related news should be posted to the mailing lists (that is, at least the main - english speaking - list). I can also agree with the third point if you drop the `CVS' (or if I don't have to work with it on-line, and somebody else keeps it up-to-date). > tuxfamily.org was chosen for this purpose. This is the point I do not agree with. When you (all of you who chose it) have contributed your first lines of code (or other valuable contributions - and I certainly don't count web space, connectivity or well-meant `advice'), you may start raising your voice when things are going to be decided. Until then, you'll have to kindly *ask* and let the main developers decide. In short: "contribute or shut up". If you don't like that, start your own project and work the way you like. Or maybe join Alan Grimes. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 12 16:10:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0Y-0000FC-01 for ; Wed, 12 Jun 2002 21:42:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:18 +0200 (CEST) Received: (qmail 23969 invoked by uid 0); 12 Jun 2002 16:45:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 12 Jun 2002 16:45:01 -0000 Received: by moria.seul.org (Postfix) id 403FD146812; Wed, 12 Jun 2002 12:44:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E9BBD14681E; Wed, 12 Jun 2002 12:44:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id D0123146812 for ; Wed, 12 Jun 2002 12:44:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00631; Wed, 12 Jun 2002 16:10:32 +0200 Message-ID: <20020612161032.57460@thrai.stud.uni-hannover.de> Date: Wed, 12 Jun 2002 16:10:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <1023869649.3d0702d19d9b1@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1023869649.3d0702d19d9b1@imp.free.fr>; from Cedric BAIL on Wed, Jun 12, 2002 at 10:14:09AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 10:14:09AM +0200, Cedric BAIL wrote: > Hi everybody, > > It seems to be a communication problem on the French mailing List. > A lot of people joined this list and they say it is difficult to join the > project because the website is not up-to-date. Don't worry, it will probably never be. > Some of these new guys have the time and the knowledge to quickly create a > dynamic website. This is why some of them where working on tuxfamily. The french > team have selected this host, because we know some people in this french > association. They give us some possibility to have subdomain like seul.f-cpu.org > that can redirect us to f-cpu.seul.org. So when this will be ready we can switch > the f-cpu.org to this site (of course it will be in English). Thus, we will have > a single access point that will redirect to the actual website on an address > basis Whaddya talking, "the french team"? There is only a *single* team, and I am part of it - or something is wrong. Since you decide things without even considering to ask me or discussing them in the `public' (that is, on *this* mailing list, not on the french one!), there definitely *is* something wrong. > After what Paul and Daique were working on two different CVS. One whant to > sync it with gaos and the other create a new one from scratch. But none of them > know what the other is doing. When Yann discovered that, we were making a > propsition on what to do with seul.org and tuxfamily.org. It appear a consensus > on the french to use seul.org for private account and backup like what it does > at the time beeing and to use tuxfamily when it will be ready for f-cpu.org. "a consensus *on the french*"? Guys, you gotta work on your attitude. See above. > And now the communication problem appears, I wrote a mail, that was not clear > on the french mailing-list and Daique thought this was a decision and not > a proposition. So he started to work before we make a common proposition on > the english mailing-list. I hope I have do it now and I was clear. > > But you must know that I only have a stupid modem at 28k and wasn't previously > able to download cvs from f-cpu.gaos.org, because it contains a lot of very big > files. (I didn't have an unlimited connexion, and I think that most of us have > the same problem). So I think that we must take care on what we upload on the > CVS. Same here (although I recently bought a V.90 modem) - that's the reason why I refuse to work with a remote CVS on a regular basis, i.e. check-in all my changes and so on. I have a private CVS at home, that's sufficient. > I think that the most important thing we must upload on the CVS is the manual, > but perhaps I am wrong, and we must discuss on this now on this mailing-list. The manual *sources*, maybe. PostScript, PDF and .tar.gz files really do not belong into CVS. Everything that can be generated from the sources within a reasonable amount of time does not belong into CVS. You can put it on an FTP or HTTP server and add a `links.html' file to the CVS tree (and also to the web site) which points to them. I prefer FTP because you can see the size of the file before you download it (I don't like big files either). BTW: What do you think about converting the manual from LaTeX to XML? That would allow us to transform it to many other formats, including LaTeX and (X)HTML. That also means that we can put an up-to-date, automatically generated, online readable copy on the homepage. LaTeX is fine for printed documents, but I also need a browsable(!) manual with all bells and whistles where I can quickly look things up when I'm developing (I still refer to the 0.2 HTML version for that reason). And maybe the newbies will have a better start then, too. Many people I know don't like downloading and reading PDFs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Wed Jun 12 20:18:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0c-0000FC-00 for ; Wed, 12 Jun 2002 21:42:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:22 +0200 (CEST) Received: (qmail 11924 invoked by uid 0); 12 Jun 2002 18:22:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 12 Jun 2002 18:22:19 -0000 Received: by moria.seul.org (Postfix) id 35089146812; Wed, 12 Jun 2002 14:22:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1323A14681D; Wed, 12 Jun 2002 14:22:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id 325C4146812 for ; Wed, 12 Jun 2002 14:22:17 -0400 (EDT) Received: from mota by ns1.april.org with local (Exim 3.12 #1 (Debian)) id 17IChl-00039a-00; Wed, 12 Jun 2002 20:18:49 +0200 Date: Wed, 12 Jun 2002 20:18:49 +0200 From: Paul Marques Mota To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... Message-ID: <20020612201849.A32234@opium.april.org> Mail-Followup-To: Paul Marques Mota , f-cpu@seul.org References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020612171005.45745@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Wed, Jun 12, 2002 at 05:10:05PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 05:10:05PM +0200, Michael Riepe wrote: > > (yes, I want the manual on-line too!). Where ? > list). I can also agree with the third point if you drop the `CVS' > (or if I don't have to work with it on-line, Why not. > and somebody else keeps > it up-to-date). > Where ? > Until then, you'll have to > kindly *ask* and let the main developers decide. > Done :) but as shown above, there are a few points still unclear. > Michael "Tired" Riepe -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Jun 12 21:04:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IE0d-0000FC-01 for ; Wed, 12 Jun 2002 21:42:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 12 Jun 2002 21:42:23 +0200 (CEST) Received: (qmail 6830 invoked by uid 0); 12 Jun 2002 19:04:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 12 Jun 2002 19:04:08 -0000 Received: by moria.seul.org (Postfix) id C9CAC14681D; Wed, 12 Jun 2002 15:04:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 96FD4146823; Wed, 12 Jun 2002 15:04:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 4CD6F14681D for ; Wed, 12 Jun 2002 15:04:06 -0400 (EDT) Received: from ifurita (212.194.254.201) by smtp.laposte.net (5.5.044) id 3CFD28F900084AE8 for f-cpu@seul.org; Wed, 12 Jun 2002 21:04:05 +0200 Message-ID: <00db01c21243$f68957a0$c9fec2d4@ifurita> From: "Christophe" To: References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] There's something going wrong here... Date: Wed, 12 Jun 2002 21:04:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok, just a refinement. You use your own local CVS for developping your part. When you reach a working release, you may just commit it to global CVS, you will save your money since you would just commit modified files. Besides, usually there is a CVS mailing which is sent to people when some commitings occur : that way we keep an history of what major change is done. If you are still against, okay, just send your more recent part to someone who will commit to global CVS. You are not forced to do so, but you cannot also force other people not to use CVS because you find it not convenient. Up to now, I cannot know which archive is the official or the most recent !!! so it is why we really need a main repositary. > If you think a change in e.g. the Add/Subtract Unit is necessary, > you'll have to talk to the author/maintainer (that's me). And you'll > have to convince me that your idea is worth considering (or that you > found a bug). If I agree with you, I'll change the code, test it(!), > and make a new release. > > We're NOT doing `bazaar-style' development. Deal with it. > I aggree too. Anyway, my opinion is that global repositary is only-read for anonymous access (pserver) and commitable for only registered developpers (per module basis, ssh). > > What we just want is : > > > > - english-spoken > > - a main homepage frequently updated (news, manual on-line, etc.) > > - a main CVS repositary for source > > I agree fully with the first point, and partially with the second (yes, > I want the manual on-line too!). Project-related news should be posted > to the mailing lists (that is, at least the main - english speaking - > list). Hum yes, let us forget about news... (I don't consider news to be a mailing list, but some news that people can read when accessing the homepage, that's nothing else that) > I can also agree with the third point if you drop the `CVS' > (or if I don't have to work with it on-line, and somebody else keeps > it up-to-date). As I told you above, you can always work on your local CVS, and update/commit when you reach a major and working release, or send it to someone in charge. > > tuxfamily.org was chosen for this purpose. Okay, okay, tuxfamily or not. What is important is to have an official homepage and repositary which are not old or scattered in so many places so people can get it the easiest way and being sure to have the last one, clean and working. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Thu Jun 13 00:12:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXv-00042q-00 for ; Thu, 13 Jun 2002 03:37:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:07 +0200 (CEST) Received: (qmail 8472 invoked by uid 0); 12 Jun 2002 22:04:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 12 Jun 2002 22:04:51 -0000 Received: by moria.seul.org (Postfix) id 8025114681D; Wed, 12 Jun 2002 18:04:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5DCF6146823; Wed, 12 Jun 2002 18:04:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 510C114681D for ; Wed, 12 Jun 2002 18:04:48 -0400 (EDT) Received: from art1.none.de ([62.246.76.62]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g5CM4ke28742 for ; Thu, 13 Jun 2002 00:04:46 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.246.76.62] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 17IGMH-0004s0-00 for ; Thu, 13 Jun 2002 00:12:53 +0200 Date: Thu, 13 Jun 2002 00:12:39 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... In-Reply-To: <20020611203908.A15803@opium.april.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > > Besides that, I still refuse to put my code-in-progress into a remote CVS, > > for reasons I stated several times, long ago > > I found out that the gaos pserver does not appears to work. What goes wrong? Remember, Yann and Michael should have an account, all other people can have CVS-access. My problem is, I am working via a called line and I am too busy now to be an Administrator for F-CPU-CVS. The GAOS-Server is based on debian-Gnu/linux so it should be easy to install things that were wrong. Michael or YG, if you have questions, please don't hesitate to contact me. You can also get my private phone number. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE9B8daClxplZklbgERAqLeAKCTX17xKGEvbmwyOepQo8SfhAqZgwCcDuco EYuWimLk4yWfk/3jtaLtyZk= =/cJY -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Thu Jun 13 00:19:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXw-00042q-01 for ; Thu, 13 Jun 2002 03:37:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:08 +0200 (CEST) Received: (qmail 15377 invoked by uid 0); 12 Jun 2002 22:11:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Jun 2002 22:11:14 -0000 Received: by moria.seul.org (Postfix) id 53B8114681D; Wed, 12 Jun 2002 18:11:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 281B5146823; Wed, 12 Jun 2002 18:11:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 5031F14681D for ; Wed, 12 Jun 2002 18:11:12 -0400 (EDT) Received: from art1.none.de ([62.246.134.29]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g5CMBAe28837 for ; Thu, 13 Jun 2002 00:11:10 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.246.134.29] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 17IGSW-0004sO-00 for ; Thu, 13 Jun 2002 00:19:20 +0200 Date: Thu, 13 Jun 2002 00:19:07 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... In-Reply-To: <000901c211f7$51e128a0$79dfc2d4@ifurita> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > First, any developpements outside CVS is a nightmare to synchronise. You are > developped their own versions in your corner and it is a real mess when I try > to have a complete version. I'm really fed up with downloading big archives > because people are unable to synchronize their works in a global repositary. > > This project is meant to be developped by a team, so we need a configuration > software, that is CVS or likes. I agree. If there were a central CVS-Repository used, I could even better help and work at F-CPU... But it is a miss, If I need download different archives and merge it. CVS is a think that does these things in a better way... And of course, CVS-access is available for all OS-plattforms... A miss too is the senseless converting between different charsets. And one manual is enough. But it should be up-to-date, because I can't take the time to puzzle things to another... > - english-spoken > - a main homepage frequently updated (news, manual on-line, etc.) > - a main CVS repositary for source I agree, too. Bye art1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE9B8jnClxplZklbgERArN/AKCBEGPdVsCUMxnJzec2v1zV+YJkWgCeK2tX n/sy8csVPadSpUOtvLxrTgk= =Nqgh -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Thu Jun 13 00:27:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXx-00042q-00 for ; Thu, 13 Jun 2002 03:37:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:09 +0200 (CEST) Received: (qmail 28096 invoked by uid 0); 12 Jun 2002 22:18:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 12 Jun 2002 22:18:59 -0000 Received: by moria.seul.org (Postfix) id 94D5E14681D; Wed, 12 Jun 2002 18:18:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A6A9146823; Wed, 12 Jun 2002 18:18:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 9961814681D for ; Wed, 12 Jun 2002 18:18:56 -0400 (EDT) Received: from art1.none.de ([62.246.134.76]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g5CMIte28974 for ; Thu, 13 Jun 2002 00:18:55 +0200 X-Authentication-Warning: host-2.server.itns.de: Host [62.246.134.76] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 17IGa0-0004so-00 for ; Thu, 13 Jun 2002 00:27:04 +0200 Date: Thu, 13 Jun 2002 00:27:00 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem In-Reply-To: <20020612161032.57460@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > BTW: What do you think about converting the manual from LaTeX to XML? > That would allow us to transform it to many other formats, including > LaTeX and (X)HTML. That also means that we can put an up-to-date, Ouups, you are a potentially buzzword-bingo candidate. There is no need to change documents from TeX to whatever... Latex can be easily transformed into PDF, DVI, PS, HTML and so on. And you have a small source wit a clear syntax. XML is a Buzzword only, and there no needs to use it. > automatically generated, online readable copy on the homepage. LaTeX is > fine for printed documents, but I also need a browsable(!) manual with all > bells and whistles where I can quickly look things up when I'm developing > (I still refer to the 0.2 HTML version for that reason). And maybe the > newbies will have a better start then, too. Many people I know don't > like downloading and reading PDFs. If I know, how, the manual should be updated, I want to do it. In todays version it is quite difficult to make it browseable, but possible... Bye Andreas PS.: Is anywhere working on crossbar? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE9B8q4ClxplZklbgERAgY0AJ9kWSgApbx9CPUCGLOMpSGUGEcl/QCfb4LB TpL7Jy++yffchmcLoPk7WAE= =2STS -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 00:19:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXx-00042q-01 for ; Thu, 13 Jun 2002 03:37:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:09 +0200 (CEST) Received: (qmail 16875 invoked by uid 0); 12 Jun 2002 22:29:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 12 Jun 2002 22:29:04 -0000 Received: by moria.seul.org (Postfix) id AC81814681E; Wed, 12 Jun 2002 18:29:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59DA8146828; Wed, 12 Jun 2002 18:29:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id B269B14681E for ; Wed, 12 Jun 2002 18:29:01 -0400 (EDT) Received: from laposte.net (62.147.98.167) by smtp.laposte.net (5.5.044) id 3D0607190001BBA3 for f-cpu@seul.org; Thu, 13 Jun 2002 00:29:00 +0200 Message-ID: <3D07C8FB.1040409@laposte.net> Date: Thu, 13 Jun 2002 00:19:39 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] Where I can put my asm code Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi. I've made some simple asm code to show what we could do with the ISA but I have a problem : Where I can put it if I would all people have access to it ? Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 00:34:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXy-00042q-01 for ; Thu, 13 Jun 2002 03:37:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:10 +0200 (CEST) Received: (qmail 24514 invoked by uid 0); 12 Jun 2002 22:34:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Jun 2002 22:34:09 -0000 Received: by moria.seul.org (Postfix) id 8ED6F14681D; Wed, 12 Jun 2002 18:34:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 68CF3146823; Wed, 12 Jun 2002 18:34:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a238.home.uni-hannover.de [130.75.232.238]) by moria.seul.org (Postfix) with ESMTP id DAA1E14681D for ; Wed, 12 Jun 2002 18:34:06 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA03144; Thu, 13 Jun 2002 00:34:04 +0200 Message-ID: <20020613003404.32316@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 00:34:04 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> <20020612201849.A32234@opium.april.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020612201849.A32234@opium.april.org>; from Paul Marques Mota on Wed, Jun 12, 2002 at 08:18:49PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 08:18:49PM +0200, Paul Marques Mota wrote: > On Wed, Jun 12, 2002 at 05:10:05PM +0200, Michael Riepe wrote: > > > > (yes, I want the manual on-line too!). > > Where ? What's wrong with seul.org? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 00:47:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJXz-00042q-00 for ; Thu, 13 Jun 2002 03:37:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:11 +0200 (CEST) Received: (qmail 9221 invoked by uid 0); 12 Jun 2002 22:47:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Jun 2002 22:47:27 -0000 Received: by moria.seul.org (Postfix) id 1BDA71467EF; Wed, 12 Jun 2002 18:47:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ED572146823; Wed, 12 Jun 2002 18:47:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a238.home.uni-hannover.de [130.75.232.238]) by moria.seul.org (Postfix) with ESMTP id 400581467EF for ; Wed, 12 Jun 2002 18:47:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA03186; Thu, 13 Jun 2002 00:47:22 +0200 Message-ID: <20020613004722.61095@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 00:47:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> <00db01c21243$f68957a0$c9fec2d4@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <00db01c21243$f68957a0$c9fec2d4@ifurita>; from Christophe on Wed, Jun 12, 2002 at 09:04:21PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 12, 2002 at 09:04:21PM +0200, Christophe wrote: > Ok, just a refinement. > > You use your own local CVS for developping your part. When you reach a working > release, you may just commit it to global CVS, you will save your money since > you would just commit modified files. Besides, usually there is a CVS mailing > which is sent to people when some commitings occur : that way we keep an > history of what major change is done. If you are still against, okay, just send > your more recent part to someone who will commit to global CVS. You are not > forced to do so, but you cannot also force other people not to use CVS because > you find it not convenient. Up to now, I cannot know which archive is the > official or the most recent !!! so it is why we really need a main repositary. I will do nothing at all. You want a central CVS? Then you can also grab my releases and import them. [...] > > > tuxfamily.org was chosen for this purpose. > > Okay, okay, tuxfamily or not. What is important is to have an official homepage > and repositary which are not old or scattered in so many places so people can > get it the easiest way and being sure to have the last one, clean and working. This happened exactly because the F-CPU site moved too often. How many shiny new toys^H^H^H^Hwebsites did we have, three? Four? Now you're preparing the next move, and we'll leave yet another dead site behind. That's not an improvement, it only makes things worse. You'd better try to work with what's there (that is, seul.org) instead of moving again. Seul.org is the official F-CPU site. It's not broken, it's not dead, so why should we replace it? There's absolutely no reason for a move. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 00:54:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY0-00042q-00 for ; Thu, 13 Jun 2002 03:37:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:12 +0200 (CEST) Received: (qmail 4933 invoked by uid 0); 12 Jun 2002 22:54:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Jun 2002 22:54:29 -0000 Received: by moria.seul.org (Postfix) id E63E61467EF; Wed, 12 Jun 2002 18:54:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE5B8146823; Wed, 12 Jun 2002 18:54:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a238.home.uni-hannover.de [130.75.232.238]) by moria.seul.org (Postfix) with ESMTP id 014731467EF for ; Wed, 12 Jun 2002 18:54:26 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA03212; Thu, 13 Jun 2002 00:54:23 +0200 Message-ID: <20020613005423.10785@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 00:54:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <20020612161032.57460@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Andreas Romeyke on Thu, Jun 13, 2002 at 12:27:00AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 13, 2002 at 12:27:00AM +0200, Andreas Romeyke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > > BTW: What do you think about converting the manual from LaTeX to XML? > > That would allow us to transform it to many other formats, including > > LaTeX and (X)HTML. That also means that we can put an up-to-date, > > Ouups, you are a potentially buzzword-bingo candidate. There is no need to > change documents from TeX to whatever... Latex can be easily transformed > into PDF, DVI, PS, HTML and so on. And you have a small source wit a clear > syntax. XML is a Buzzword only, and there no needs to use it. You mean, *browseable* HTML - lots of files, with hyperlinks? I haven't seen that yet. There should be one file for each F-CPU instruction, for example (in the old manual, the instruction set document was one big file). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 13 01:16:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY1-00042q-01 for ; Thu, 13 Jun 2002 03:37:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:13 +0200 (CEST) Received: (qmail 13649 invoked by uid 0); 12 Jun 2002 23:08:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Jun 2002 23:08:29 -0000 Received: by moria.seul.org (Postfix) id 7C9261467EF; Wed, 12 Jun 2002 19:08:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 696F014681E; Wed, 12 Jun 2002 19:08:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2909C1467EF for ; Wed, 12 Jun 2002 19:08:28 -0400 (EDT) Received: from f-cpu.org (kdl4-24.n.club-internet.fr [213.44.3.24]) by relay-3v.club-internet.fr (Postfix) with ESMTP id DA7021688 for ; Thu, 13 Jun 2002 01:08:25 +0200 (CEST) Message-ID: <3D07D633.30A9594C@f-cpu.org> Date: Thu, 13 Jun 2002 01:16:03 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <3D07C8FB.1040409@laposte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Thomas Lavergne wrote: > Hi. > > I've made some simple asm code to show what we could do with the ISA but > I have a problem : > > Where I can put it if I would all people have access to it ? just login as "anonymous" on ftp.seul.org, directory is pub/f-cpu/contrib. no/dumb pasword. your file then appears on http://f-cpu.seul.org/new. all you need is ftp :-) > Tom WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 01:24:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY3-00042q-01 for ; Thu, 13 Jun 2002 03:37:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:15 +0200 (CEST) Received: (qmail 12968 invoked by uid 0); 12 Jun 2002 23:29:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 12 Jun 2002 23:29:00 -0000 Received: by moria.seul.org (Postfix) id BBAE21467EF; Wed, 12 Jun 2002 19:28:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A7F8014681D; Wed, 12 Jun 2002 19:28:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 5E1321467EF for ; Wed, 12 Jun 2002 19:28:58 -0400 (EDT) Received: from laposte.net (62.147.98.167) by smtp.laposte.net (5.5.044) id 3CF4B31300120CC3 for f-cpu@seul.org; Thu, 13 Jun 2002 01:28:57 +0200 Message-ID: <3D07D811.2090103@laposte.net> Date: Thu, 13 Jun 2002 01:24:01 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <3D07C8FB.1040409@laposte.net> <3D07D633.30A9594C@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > hi ! > > Thomas Lavergne wrote: > >>Hi. >> >>I've made some simple asm code to show what we could do with the ISA but >>I have a problem : >> >>Where I can put it if I would all people have access to it ? > > > just login as "anonymous" on ftp.seul.org, > directory is pub/f-cpu/contrib. no/dumb pasword. > your file then appears on http://f-cpu.seul.org/new. > Is it possible to make sub-directory, I will try to make some code to do simple image processing, and I think is better if all this code was in same directory. > all you need is ftp :-) > So i've all I need :-) Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 01:42:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY7-00042q-00 for ; Thu, 13 Jun 2002 03:37:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:19 +0200 (CEST) Received: (qmail 18592 invoked by uid 0); 12 Jun 2002 23:42:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 12 Jun 2002 23:42:44 -0000 Received: by moria.seul.org (Postfix) id 93E291467FF; Wed, 12 Jun 2002 19:42:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 898C714681D; Wed, 12 Jun 2002 19:42:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a238.home.uni-hannover.de [130.75.232.238]) by moria.seul.org (Postfix) with ESMTP id 1F87B1467FF for ; Wed, 12 Jun 2002 19:42:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03403; Thu, 13 Jun 2002 01:42:40 +0200 Message-ID: <20020613014240.05851@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 01:42:40 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <3D07C8FB.1040409@laposte.net> <3D07D633.30A9594C@f-cpu.org> <3D07D811.2090103@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D07D811.2090103@laposte.net>; from Thomas Lavergne on Thu, Jun 13, 2002 at 01:24:01AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 13, 2002 at 01:24:01AM +0200, Thomas Lavergne wrote: [...] > Is it possible to make sub-directory, I will try to make some code to do > simple image processing, and I think is better if all this code was in > same directory. I have created a subdirectory for you. It's called `examples' (we can rename it later). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 01:47:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY9-00042q-00 for ; Thu, 13 Jun 2002 03:37:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:21 +0200 (CEST) Received: (qmail 21515 invoked by uid 0); 12 Jun 2002 23:52:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 12 Jun 2002 23:52:38 -0000 Received: by moria.seul.org (Postfix) id 6A4671467FF; Wed, 12 Jun 2002 19:52:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 61EDC14681D; Wed, 12 Jun 2002 19:52:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id 204F21467FF for ; Wed, 12 Jun 2002 19:52:37 -0400 (EDT) Received: from laposte.net (62.147.99.59) by smtp.laposte.net (5.5.044) id 3D0607190001C981 for f-cpu@seul.org; Thu, 13 Jun 2002 01:52:36 +0200 Message-ID: <3D07DD9C.3060804@laposte.net> Date: Thu, 13 Jun 2002 01:47:40 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <3D07C8FB.1040409@laposte.net> <3D07D633.30A9594C@f-cpu.org> <3D07D811.2090103@laposte.net> <20020613014240.05851@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > On Thu, Jun 13, 2002 at 01:24:01AM +0200, Thomas Lavergne wrote: > [...] > >>Is it possible to make sub-directory, I will try to make some code to do >>simple image processing, and I think is better if all this code was in >>same directory. > > > I have created a subdirectory for you. It's called `examples' (we can > rename it later). > Sorry but I've tried to upload my file and obtain an access denied, permission not allowed... -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 13 02:05:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IJY9-00042q-01 for ; Thu, 13 Jun 2002 03:37:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 03:37:21 +0200 (CEST) Received: (qmail 30791 invoked by uid 0); 12 Jun 2002 23:57:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 12 Jun 2002 23:57:27 -0000 Received: by moria.seul.org (Postfix) id 200B51467EF; Wed, 12 Jun 2002 19:57:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 138931467FF; Wed, 12 Jun 2002 19:57:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CD6E01467EF for ; Wed, 12 Jun 2002 19:57:25 -0400 (EDT) Received: from f-cpu.org (kdl11-4.n.club-internet.fr [213.44.9.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 847E21699 for ; Thu, 13 Jun 2002 01:57:23 +0200 (CEST) Message-ID: <3D07E1AD.47DB0A43@f-cpu.org> Date: Thu, 13 Jun 2002 02:05:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Andreas Romeyke wrote: > Hello, wow, the manual was first written in LaTeX by Mathias, then i converted it to HTML (i could generate PS and PDF with HTMLDOC), then it was again converted into LaTeX by someone else.... looks like what happens to the sites, no ? > Bye Andreas > > PS.: Is anywhere working on crossbar? the Xbar is not an execution unit by itself. it can't be designed until all the scheduling problems are solved. and trust me, there are a lot of problems. However, POPCOUNT is still free of maintainer. it's an interesting little thing to do in VHDL (a tree of adders, using SIMD is straight-forward, and some features can be added). POPCOUNT is not reserved for the spooks : it will be used to "compact" signatures of the BIST engine (Built-In Self Test, a stuff that checks the chip's integrity). so you can start to design a SIMD popcount tree and we're done, that's the core of the thing. I also think that there should be some CRC means somewhere. Not only it's useful for communication but it's also used by the BIST (it does a CRC of the compacted signatures of the signals it sends through the tested units and compares the result with a "clean" signature). g'night,... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jun 13 07:36:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ibd9-0000u9-00 for ; Thu, 13 Jun 2002 22:55:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:43 +0200 (CEST) Received: (qmail 17110 invoked by uid 0); 13 Jun 2002 05:46:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 13 Jun 2002 05:46:41 -0000 Received: by moria.seul.org (Postfix) id 31D0A1467FC; Thu, 13 Jun 2002 01:46:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 153A5146812; Thu, 13 Jun 2002 01:46:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 0EA1C1467FC for ; Thu, 13 Jun 2002 01:46:34 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17INHd-0004zC-00 for f-cpu@seul.org; Thu, 13 Jun 2002 07:36:33 +0200 Date: Thu, 13 Jun 2002 07:36:32 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem In-Reply-To: <20020613005423.10785@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 13 Jun 2002, Michael Riepe wrote: >On Thu, Jun 13, 2002 at 12:27:00AM +0200, Andreas Romeyke wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> >> > BTW: What do you think about converting the manual from LaTeX to XML? >> > That would allow us to transform it to many other formats, including >> > LaTeX and (X)HTML. That also means that we can put an up-to-date, >> >> Ouups, you are a potentially buzzword-bingo candidate. There is no need to >> change documents from TeX to whatever... Latex can be easily transformed >> into PDF, DVI, PS, HTML and so on. And you have a small source wit a clear >> syntax. XML is a Buzzword only, and there no needs to use it. > >You mean, *browseable* HTML - lots of files, with hyperlinks? I haven't >seen that yet. There should be one file for each F-CPU instruction, >for example (in the old manual, the instruction set document was one >big file). Just a comment from my view. I hate these online manuals where you have all this scattered files. I prefer to do a download of the whole manual and read it offline! JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From boucli27@altavista.net Thu Jun 13 11:36:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdC-0000u9-01 for ; Thu, 13 Jun 2002 22:55:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:46 +0200 (CEST) Received: (qmail 16887 invoked by uid 0); 13 Jun 2002 09:36:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 13 Jun 2002 09:36:35 -0000 Received: by moria.seul.org (Postfix) id C2C23146812; Thu, 13 Jun 2002 05:36:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C79114681E; Thu, 13 Jun 2002 05:36:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ws1-10.us4.outblaze.com (205-158-62-111.outblaze.com [205.158.62.111]) by moria.seul.org (Postfix) with SMTP id D6DB1146812 for ; Thu, 13 Jun 2002 05:36:31 -0400 (EDT) Received: (qmail 89169 invoked by uid 1001); 13 Jun 2002 09:36:31 -0000 Message-ID: <20020613093631.89168.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [62.210.208.70] by ws1-10.us4.outblaze.com with http for boucli27@altavista.net; Thu, 13 Jun 2002 04:36:31 -0500 From: "Lionel-Wolf-Eric Bouchpan-Lerust-Juery" To: f-cpu@seul.org Date: Thu, 13 Jun 2002 04:36:31 -0500 Subject: Re: [f-cpu] Stay calm(e) X-Originating-Ip: 62.210.208.70 X-Originating-Server: ws1-10.us4.outblaze.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Nicolas Boulay" Date: Wed, 12 Jun 2002 11:29:32 GMT To: Subject: [f-cpu] Stay calm(e) > oups ! Stay calme everyone ! > Yap ! I agree with you, one should not lose its temper. Let the things settle down. -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 11:33:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdD-0000u9-00 for ; Thu, 13 Jun 2002 22:55:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:47 +0200 (CEST) Received: (qmail 18012 invoked by uid 0); 13 Jun 2002 09:38:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 13 Jun 2002 09:38:56 -0000 Received: by moria.seul.org (Postfix) id 5BC391467FF; Thu, 13 Jun 2002 05:38:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2EC7014681E; Thu, 13 Jun 2002 05:38:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id A5A331467FF for ; Thu, 13 Jun 2002 05:38:53 -0400 (EDT) Received: from laposte.net (193.250.154.14) by smtp.laposte.net (5.5.044) id 3D05FC530002B846 for f-cpu@seul.org; Thu, 13 Jun 2002 11:38:52 +0200 Message-ID: <3D086704.6040102@laposte.net> Date: Thu, 13 Jun 2002 11:33:56 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <3D07C8FB.1040409@laposte.net> <3D07D633.30A9594C@f-cpu.org> <3D07D811.2090103@laposte.net> <20020613014240.05851@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > On Thu, Jun 13, 2002 at 01:24:01AM +0200, Thomas Lavergne wrote: > [...] > >>Is it possible to make sub-directory, I will try to make some code to do >>simple image processing, and I think is better if all this code was in >>same directory. > > > I have created a subdirectory for you. It's called `examples' (we can > rename it later). > Thanks, but I have no acces to this directory so I've put my file in a simple zip file : "Image.zip" Can I have a personal directory to put sample well organised ? I have put the first two sample, simple but it could be usefull for show how the ISA work. negative.asm greyscale.asm for the moment I've used my calling convention until we could make a good standard cc well defined. I will try to update it with updated version (see limitation in asm files) and put another filter that allow applying convolution matrix to an image in few days. (so few have filter like blur, sharpen or emboss) If you have any comment, mail me. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 13 13:14:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdI-0000u9-00 for ; Thu, 13 Jun 2002 22:55:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:52 +0200 (CEST) Received: (qmail 6157 invoked by uid 0); 13 Jun 2002 11:14:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 13 Jun 2002 11:14:11 -0000 Received: by moria.seul.org (Postfix) id 586D9146812; Thu, 13 Jun 2002 07:14:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2908E14681E; Thu, 13 Jun 2002 07:14:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte09.axime.com [160.92.113.114]) by moria.seul.org (Postfix) with ESMTP id A742D146812 for ; Thu, 13 Jun 2002 07:14:09 -0400 (EDT) Received: from ifurita (213.44.150.175) by smtp.laposte.net (5.5.044) id 3D06071900023BF2 for f-cpu@seul.org; Thu, 13 Jun 2002 13:14:09 +0200 Message-ID: <006f01c212cb$79940500$af962cd5@ifurita> From: "Christophe" To: References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> <00db01c21243$f68957a0$c9fec2d4@ifurita> <20020613004722.61095@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] There's something going wrong here... Date: Thu, 13 Jun 2002 13:14:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > This happened exactly because the F-CPU site moved too often. How many > shiny new toys^H^H^H^Hwebsites did we have, three? Four? Now you're > preparing the next move, and we'll leave yet another dead site behind. > That's not an improvement, it only makes things worse. You'd better try > to work with what's there (that is, seul.org) instead of moving again. > > Seul.org is the official F-CPU site. It's not broken, it's not dead, > so why should we replace it? There's absolutely no reason for a move. > Grrr, I'm not the one who wants to move anything to another sites !!!! I was only asking for a true official and frequently updated homepage and global repositary. That's all. I don't care where they could be so long time as they are easily accessed and maintainable in one spot. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 13 13:16:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdI-0000u9-01 for ; Thu, 13 Jun 2002 22:55:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:52 +0200 (CEST) Received: (qmail 2614 invoked by uid 0); 13 Jun 2002 11:16:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 13 Jun 2002 11:16:07 -0000 Received: by moria.seul.org (Postfix) id 4159B14681D; Thu, 13 Jun 2002 07:16:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C72F146823; Thu, 13 Jun 2002 07:16:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id B8B1014681D for ; Thu, 13 Jun 2002 07:16:05 -0400 (EDT) Received: from ifurita (213.44.150.175) by smtp.laposte.net (5.5.044) id 3D05FC530002D8F9 for f-cpu@seul.org; Thu, 13 Jun 2002 13:16:04 +0200 Message-ID: <007701c212cb$bec15ec0$af962cd5@ifurita> From: "Christophe" To: References: <20020612161032.57460@thrai.stud.uni-hannover.de> <20020613005423.10785@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] Communication problem Date: Thu, 13 Jun 2002 13:16:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: Michael Riepe To: Sent: Thursday, June 13, 2002 12:54 AM Subject: Re: [f-cpu] Communication problem > > Ouups, you are a potentially buzzword-bingo candidate. There is no need to > > change documents from TeX to whatever... Latex can be easily transformed > > into PDF, DVI, PS, HTML and so on. And you have a small source wit a clear > > syntax. XML is a Buzzword only, and there no needs to use it. > > You mean, *browseable* HTML - lots of files, with hyperlinks? I haven't > seen that yet. There should be one file for each F-CPU instruction, > for example (in the old manual, the instruction set document was one > big file). Ok do you know some XML editors which are free and complete ? we might have a look on it. Those editors should work on UN*X and Windows. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 13 13:24:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdJ-0000u9-00 for ; Thu, 13 Jun 2002 22:55:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:53 +0200 (CEST) Received: (qmail 1438 invoked by uid 0); 13 Jun 2002 11:24:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 13 Jun 2002 11:24:03 -0000 Received: by moria.seul.org (Postfix) id B1ED0146823; Thu, 13 Jun 2002 07:23:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6A9114682F; Thu, 13 Jun 2002 07:23:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 343DB146823 for ; Thu, 13 Jun 2002 07:23:58 -0400 (EDT) Received: from ifurita (213.44.150.175) by smtp.laposte.net (5.5.044) id 3D05FC530002DB53 for f-cpu@seul.org; Thu, 13 Jun 2002 13:23:57 +0200 Message-ID: <008501c212cc$d8b27e80$af962cd5@ifurita> From: "Christophe" To: References: <3D07C8FB.1040409@laposte.net> <3D07D633.30A9594C@f-cpu.org> Subject: Re: [f-cpu] Where I can put my asm code Date: Thu, 13 Jun 2002 13:24:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > just login as "anonymous" on ftp.seul.org, > directory is pub/f-cpu/contrib. no/dumb pasword. > your file then appears on http://f-cpu.seul.org/new. > > all you need is ftp :-) > Really cool when you want to deposit something which not relative to official document or source (temporary works, off-topic stuffs). But really messy for tracking changes (I cannot count upon f-cpu mailing for that, especially if I want to delete them dayly). This solution is a good solution for unofficial stuffs and developpements and a good way to send to someone an archive or document (it is a way to circumvent the fact that f-cpu mailings strongly discourages attached files). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jun 13 13:33:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdJ-0000u9-01 for ; Thu, 13 Jun 2002 22:55:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:53 +0200 (CEST) Received: (qmail 28688 invoked by uid 0); 13 Jun 2002 11:33:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 13 Jun 2002 11:33:52 -0000 Received: by moria.seul.org (Postfix) id DAC9B146828; Thu, 13 Jun 2002 07:33:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7015146832; Thu, 13 Jun 2002 07:33:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id EB909146828 for ; Thu, 13 Jun 2002 07:33:50 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206131133.27b1; Thu, 13 Jun 2002 11:33:39 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Where I can put my asm code From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jun 2002 11:33:39 GMT Message-id: <200206131133.27b1@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Don't forget to put your licence with it (GPL !). But i answer your question here it could interrest lot of pe= ople : 1) What distance should be used for prefectch (how many cycl= e beteween a prefetch and the effective load) It depend, if you're in cache no need for it (you lose a cyc= le for nothing). If it's not in cache you could take 150-200 cycle.= But if the distance is too small, depending of the implementation, you = could also lose one cycle (because the underlying system didn't find th= e adress in cache and relaunch a read to the DRAM). If it's too far, the= data should have been trash by another data. Then trash or not and cache hit or not depend on the cache t= ype (size and associativity) so it depend on the effective memory adre= ss of the manipulated data. That's why i didn't like prefetch...but pr= eload. 2) Usualy a prefetch is a "silent load" so it behave the sam= e for the cache. A cache miss will generate a complete cache line load= . The VM of cedric will be used to calibrate such things (size of the li= ne...). 3)There is no asm finish yet, so there is no common interfac= e for macro, as far as i know. 4)So ASM didn't try to mix instruction to hide latency. Befo= re writting such assembler, a dumb one should be finish. I hope i have miss nothing. nicO -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 13/06/02 Objet: Re: [f-cpu] Where I can put my asm code Michael Riepe wrote: > On Thu, Jun 13, 2002 at 01:24:01AM +0200, Thomas Lavergne= wrote: > [...] > >>Is it possible to make sub-directory, I will try to make = some code to do >>simple image processing, and I think is better if all thi= s code was in >>same directory. > > > I have created a subdirectory for you. It's called `examp= les' (we can > rename it later). > Thanks, but I have no acces to this directory so I've put my= file in a=20 simple zip file : "Image.zip" Can I have a personal directory to put sample well organised= ? I have put the first two sample, simple but it could be usef= ull for show how the ISA work. negative.asm greyscale.asm for the moment I've used my calling convention until we coul= d make a good standard cc well defined. I will try to update it with updated version (see limitation= in asm files) and put another filter that allow applying convolutio= n matrix to=20 an image in few days. (so few have filter like blur, sharpen= or emboss) If you have any comment, mail me. --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jun 13 13:46:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdK-0000u9-00 for ; Thu, 13 Jun 2002 22:55:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:54 +0200 (CEST) Received: (qmail 18599 invoked by uid 0); 13 Jun 2002 11:47:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 13 Jun 2002 11:47:07 -0000 Received: by moria.seul.org (Postfix) id B0D34146828; Thu, 13 Jun 2002 07:47:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B61C146832; Thu, 13 Jun 2002 07:47:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 0001D146828 for ; Thu, 13 Jun 2002 07:47:03 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206131146.3677; Thu, 13 Jun 2002 11:46:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] There's something going wrong here... From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jun 2002 11:46:54 GMT Message-id: <200206131146.3677@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Globaly, you say the same thing ! CVS are supposed to be used read only with a maintainer for = each part. So Michael wrote this unit inlocal, when he is satisfied it = upload it to th CVS, that's all. Cedric could do the same or not ! It's easier to use CVS for downloading changes. Why using tuxfamily AND seul.org, because tuxfamily propose = easy tools to create CVS and it's possible to run php code. To do that = on seul.org, we should personnaly ask to the owner. If Cedric is in charg= e of that, it could chose it's prefered site. seul.org is nice for the personnal account and quick downloa= d. nicO -----Message d'origine----- De: "Christophe" A: Date: 13/06/02 Objet: Re: [f-cpu] There's something going wrong here... > This happened exactly because the F-CPU site moved too oft= en. How many > shiny new toys^H^H^H^Hwebsites did we have, three? Four? N= ow you're > preparing the next move, and we'll leave yet another dead = site behind. > That's not an improvement, it only makes things worse. You= 'd better try > to work with what's there (that is, seul.org) instead of m= oving again. > > Seul.org is the official F-CPU site. It's not broken, it's= not dead, > so why should we replace it? There's absolutely no reason = for a move. > Grrr, I'm not the one who wants to move anything to another = sites !!!! I was only asking for a true official and frequently updated homep= age and global repositary. That's all. I don't care where they could be so = long time as they are easily accessed and maintainable in one spot. ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 14:49:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdM-0000u9-00 for ; Thu, 13 Jun 2002 22:55:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:56 +0200 (CEST) Received: (qmail 3145 invoked by uid 0); 13 Jun 2002 12:54:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 13 Jun 2002 12:54:42 -0000 Received: by moria.seul.org (Postfix) id 9379214681D; Thu, 13 Jun 2002 08:54:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7395414682F; Thu, 13 Jun 2002 08:54:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 1D63A14681D for ; Thu, 13 Jun 2002 08:54:41 -0400 (EDT) Received: from laposte.net (193.250.154.39) by smtp.laposte.net (5.5.044) id 3D05FC530002FCD1 for f-cpu@seul.org; Thu, 13 Jun 2002 14:54:40 +0200 Message-ID: <3D0894E8.2050508@laposte.net> Date: Thu, 13 Jun 2002 14:49:44 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Prefetch and Preload References: <200206131133.27b1@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > 1) What distance should be used for prefectch (how many cycle beteween a > prefetch and the effective load) > > It depend, if you're in cache no need for it (you lose a cycle for > nothing). If it's not in cache you could take 150-200 cycle. But if the > distance is too small, depending of the implementation, you could also > lose one cycle (because the underlying system didn't find the adress in > cache and relaunch a read to the DRAM). If it's too far, the data should > have been trash by another data. > > Then trash or not and cache hit or not depend on the cache type (size > and associativity) so it depend on the effective memory adress of the > manipulated data. That's why i didn't like prefetch...but preload. Ok so Prefetch is very hardware specific. Very bad :-( but I seem we don't have any other solutions. You take about preload, I suppose you think load data in register few cycle before we need it like this load data in r1, r2, r3 do somthing without r1, r2, r3 uses data to make some computation But in my case I can do that, I work under a lot of data so I can't load all in register : a 640x480 rgba image take 640*480*4=1228800byte and I work on it sequentialy so the best thing was a pointer and prefetch, so we have a continuous flow of data. A lot of thing need this structure (image processing, file processing, crypto...) so I think we need to do some experiment to see the prefetch minimum an d maximum distance, so Cedric we need your VM :-) > 2) Usualy a prefetch is a "silent load" so it behave the same for the > cache. A cache miss will generate a complete cache line load. The VM of > cedric will be used to calibrate such things (size of the line...). Good but when you're at the end of the cache line, how could you tell to the cpu to preload next data in memory because you need it soon ? Is it doing automaticaly ? What is the length of a cache line ? Is it implementation dependent ? -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jun 13 15:35:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdO-0000u9-00 for ; Thu, 13 Jun 2002 22:55:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:58 +0200 (CEST) Received: (qmail 28684 invoked by uid 0); 13 Jun 2002 13:36:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 13 Jun 2002 13:36:06 -0000 Received: by moria.seul.org (Postfix) id F0049146801; Thu, 13 Jun 2002 09:36:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D25DF14681D; Thu, 13 Jun 2002 09:36:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 4D846146801 for ; Thu, 13 Jun 2002 09:36:04 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206131335.334b; Thu, 13 Jun 2002 13:35:51 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Prefetch and Preload From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jun 2002 13:35:51 GMT Message-id: <200206131335.334b@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 13/06/02 Objet: [f-cpu] Prefetch and Preload > 1) What distance should be used for prefectch (how many cy= cle beteween a > prefetch and the effective load) >=20 > It depend, if you're in cache no need for it (you lose a c= ycle for > nothing). If it's not in cache you could take 150-200 cycl= e. But if the > distance is too small, depending of the implementation, yo= u could also > lose one cycle (because the underlying system didn't find = the adress in > cache and relaunch a read to the DRAM). If it's too far, t= he data should > have been trash by another data. >=20 > Then trash or not and cache hit or not depend on the cache= type (size > and associativity) so it depend on the effective memory ad= ress of the > manipulated data. That's why i didn't like prefetch...but = preload. Ok so Prefetch is very hardware specific. Very bad :-( but I= seem we=20 don't have any other solutions. You take about preload, I suppose you think load data in reg= ister few=20 cycle before we need it like this load data in r1, r2, r3 do somthing without r1, r2, r3 uses data to make some computation But in my case I can do that, I work under a lot of data so = I can't load all in register : a 640x480 rgba image take 640*480*4=3D1228= 800byte and I=20 work on it sequentialy so the best thing was a pointer and p= refetch, so=20 we have a continuous flow of data. A lot of thing need this structure (image processing, file p= rocessing,=20 crypto...) so I think we need to do some experiment to see t= he prefetch=20 minimum an d maximum distance, so Cedric we need your VM :-) >>> No it's not exactly that. load R1, R2, r3 ... Work on R4 r5 r6 ... load R4 R5 r6 ... work on R1 R2 R3 ... loop beginning >>> it look pretty like prefetch but the load is effectively= done, so there is no penalty if the distance is too low.=20 look at loadm (but instruction format should be change). > 2) Usualy a prefetch is a "silent load" so it behave the s= ame for the > cache. A cache miss will generate a complete cache line lo= ad. The VM of > cedric will be used to calibrate such things (size of the = line...). Good but when you're at the end of the cache line, how could= you tell to the cpu to preload next data in memory because you need it s= oon ? Is it doing automaticaly ? >>> It could it's what is called prefetch buffer. This could= be used to have one cache line "in advance", by detecting access patter= n. But it could be easier to use the stream number associated to one p= refetch buffer. What is the length of a cache line ? Is it implementation de= pendent ? >>> Yep !! typicaly 128-256 bits. Could be more. nicO --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 13 16:57:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdP-0000u9-01 for ; Thu, 13 Jun 2002 22:55:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:55:59 +0200 (CEST) Received: (qmail 28271 invoked by uid 0); 13 Jun 2002 14:49:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 13 Jun 2002 14:49:34 -0000 Received: by moria.seul.org (Postfix) id B56AF146801; Thu, 13 Jun 2002 10:49:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 87C8E14681D; Thu, 13 Jun 2002 10:49:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 28DC3146801 for ; Thu, 13 Jun 2002 10:49:33 -0400 (EDT) Received: from f-cpu.org (kdl4-76.n.club-internet.fr [213.44.3.76]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 7186816AA for ; Thu, 13 Jun 2002 16:49:30 +0200 (CEST) Message-ID: <3D08B2C5.B0B24525@f-cpu.org> Date: Thu, 13 Jun 2002 16:57:09 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Prefetch and Preload References: <200206131133.27b1@th00.opsion.fr> <3D0894E8.2050508@laposte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Thomas Lavergne wrote: > > > 1) What distance should be used for prefectch (how many cycle beteween a > > prefetch and the effective load) > > > > It depend, if you're in cache no need for it (you lose a cycle for > > nothing). If it's not in cache you could take 150-200 cycle. But if the > > distance is too small, depending of the implementation, you could also > > lose one cycle (because the underlying system didn't find the adress in > > cache and relaunch a read to the DRAM). If it's too far, the data should > > have been trash by another data. > > > > Then trash or not and cache hit or not depend on the cache type (size > > and associativity) so it depend on the effective memory adress of the > > manipulated data. That's why i didn't like prefetch...but preload. > > Ok so Prefetch is very hardware specific. Very bad :-( but I seem we > don't have any other solutions. > > You take about preload, I suppose you think load data in register few > cycle before we need it like this > > load data in r1, r2, r3 > do somthing without r1, r2, r3 > uses data to make some computation > > But in my case I can do that, I work under a lot of data so I can't load > all in register : a 640x480 rgba image take 640*480*4=1228800byte and I > work on it sequentialy so the best thing was a pointer and prefetch, so > we have a continuous flow of data. > A lot of thing need this structure (image processing, file processing, > crypto...) so I think we need to do some experiment to see the prefetch > minimum an d maximum distance, so Cedric we need your VM :-) > > > 2) Usualy a prefetch is a "silent load" so it behave the same for the > > cache. A cache miss will generate a complete cache line load. The VM of > > cedric will be used to calibrate such things (size of the line...). > > Good but when you're at the end of the cache line, how could you tell to > the cpu to preload next data in memory because you need it soon ? > Is it doing automaticaly ? > > What is the length of a cache line ? Is it implementation dependent ? 1) use "stream hint bits" to indicate where the data comes from : 1 hint (ie, #1) for input data and 1 hint (#2) for the data you store back to memory (to a different location). hint #0 is default and used for other management purposes. 2) when consecutive cache misses are detected, the LSU setups a dual-buffering with the LSU lines : 2 lines are used in alternance so you can work on small data sets in long rows/vectors. that's almost the same principle as on a T3E... > Thomas Lavergne WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jun 13 18:05:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IbdQ-0000u9-00 for ; Thu, 13 Jun 2002 22:56:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:56:00 +0200 (CEST) Received: (qmail 11501 invoked by uid 0); 13 Jun 2002 16:08:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 13 Jun 2002 16:08:38 -0000 Received: by moria.seul.org (Postfix) id B5C73146801; Thu, 13 Jun 2002 12:08:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8775514682F; Thu, 13 Jun 2002 12:08:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id CC711146801 for ; Thu, 13 Jun 2002 12:08:35 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g5DG8fTw002328 for ; Thu, 13 Jun 2002 10:08:42 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D08C2DC.CFC33778@jetnet.ab.ca> Date: Thu, 13 Jun 2002 10:05:48 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Prefetch and Preload References: <200206131133.27b1@th00.opsion.fr> <3D0894E8.2050508@laposte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thomas Lavergne wrote: > > > 1) What distance should be used for prefectch (how many cycle beteween a > > prefetch and the effective load) > > > > It depend, if you're in cache no need for it (you lose a cycle for > > nothing). If it's not in cache you could take 150-200 cycle. But if the > > distance is too small, depending of the implementation, you could also > > lose one cycle (because the underlying system didn't find the adress in > > cache and relaunch a read to the DRAM). If it's too far, the data should > > have been trash by another data. > > > > Then trash or not and cache hit or not depend on the cache type (size > > and associativity) so it depend on the effective memory adress of the > > manipulated data. That's why i didn't like prefetch...but preload. > > Ok so Prefetch is very hardware specific. Very bad :-( but I seem we > don't have any other solutions. So why can't one make them pesudo-variables in special registers? It seems a lot of timing information is needed for tomorrow's designs where real memory and internal processing speeds differ by so much. If we have this information on timing the software could better make use of free time. A test for 25% full or empty on buffered information could be very useful for dynamic optimzation. Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 20:44:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ibdd-0000u9-00 for ; Thu, 13 Jun 2002 22:56:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:56:13 +0200 (CEST) Received: (qmail 12037 invoked by uid 0); 13 Jun 2002 19:13:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 13 Jun 2002 19:13:37 -0000 Received: by moria.seul.org (Postfix) id DFF2314681D; Thu, 13 Jun 2002 15:13:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B2C43146844; Thu, 13 Jun 2002 15:13:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 4320F14681D for ; Thu, 13 Jun 2002 15:13:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01292; Thu, 13 Jun 2002 20:44:03 +0200 Message-ID: <20020613204403.35938@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 20:44:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <20020612161032.57460@thrai.stud.uni-hannover.de> <20020613005423.10785@thrai.stud.uni-hannover.de> <007701c212cb$bec15ec0$af962cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <007701c212cb$bec15ec0$af962cd5@ifurita>; from Christophe on Thu, Jun 13, 2002 at 01:16:19PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 13, 2002 at 01:16:19PM +0200, Christophe wrote: [...] > Ok do you know some XML editors which are free and complete ? we might have a > look on it. Those editors should work on UN*X and Windows. You mean, besides emacs and vi? I'm going to ask an expert; stay tuned. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 20:38:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ibde-0000u9-00 for ; Thu, 13 Jun 2002 22:56:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:56:14 +0200 (CEST) Received: (qmail 15044 invoked by uid 0); 13 Jun 2002 19:13:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 13 Jun 2002 19:13:43 -0000 Received: by moria.seul.org (Postfix) id F2EDC146832; Thu, 13 Jun 2002 15:13:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9B63146859; Thu, 13 Jun 2002 15:13:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 06239146832 for ; Thu, 13 Jun 2002 15:13:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01274; Thu, 13 Jun 2002 20:38:45 +0200 Message-ID: <20020613203845.52624@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 20:38:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> <00db01c21243$f68957a0$c9fec2d4@ifurita> <20020613004722.61095@thrai.stud.uni-hannover.de> <006f01c212cb$79940500$af962cd5@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <006f01c212cb$79940500$af962cd5@ifurita>; from Christophe on Thu, Jun 13, 2002 at 01:14:22PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is going to be long, but I suggest you read it carefully anyway... On Thu, Jun 13, 2002 at 01:14:22PM +0200, Christophe wrote: [...] > Grrr, I'm not the one who wants to move anything to another sites !!!! I was > only asking for a true official and frequently updated homepage and global > repositary. That's all. I don't care where they could be so long time as they > are easily accessed and maintainable in one spot. If you had asked me (or Yann) before, I would have told you that seul.org is our main site. There is a CVS there (although we don't use it yet), there also is a homepage and an FTP server, and many of us have personal accounts there. We're just too lazy^H^H^H^Hbusy to update the homepage every other day. Of course that won't change just because we move to another site. The question is: what do you expect? There will be no daily bulletin saying "Good morning, it's a new day and the F-CPU project is still alive and well" (I can install a cron job to send you messages like that). If somebody wants to participate, the first thing to do is to join this mailing list (not the french one!). Here you'll get all the important news - including announcements for new uploads on seul. You can talk to other project members, ask questions and so on. There's no need to install a WWW forum, and there is very good reason *not* to do so: we need to keep *all* discussions in a central point. The french mailing list is already too much. I've complained several times that important things were discussed there, although they really belong *here*. And don't suggest that I join that list, too - I don't speak french good enough to follow, and you don't understand german, do you? We *have* to discuss things in english, and we have to do that *here*, and nowhere else. That's what I've been preaching for more than a year now, but obviously nobody was listening :( Finally, the repository. We've been talking about that a long time ago. We even developed a directory structure for it which is at least partially reflected in Yann's and my source archives (his are more complete, I usually only upload the parts I maintain myself, to keep download times short). But there are still a number of problems to solve. First of all, I (and everybody else who uses CVS locally) can't commit to the central repository. When I type `cvs ci' in my working tree, I will commit to my *local* CVS. That is, I either have to keep the global repository checked out and copy files between two independent working directories (this is awful and error-prone), or `cvs import' my files to the central repository. The latter is the preferred method, but if one isn't careful (and aware of CVS' numerous pitfalls), one may trash the rest of the repository. In particular, if two people are allowed to update the same directory, and one of them adds a file, that file will be lost if the other one imports his version (without the new file). This does not happen with the usual checkout/commit/update sequence, but as I mentioned before, that's impossible - I can't switch repositories, and I can't work with the global one by default either. The only solution is to give only one person write access to a particular directory, but that makes things difficult again, because we have shared directories (like vhdl/common) where files from different developers accumulate. That is, one of us must become the official maintainer for that directory, and everybody else must pass his changes to him, or we need to split vhdl/common into subdirectories (common/mr, common/yg and so on). Both solutions are ugly. We get even bigger problems when two people create new subdirectories with the same name. Let's say both Yann and I create vhdl/blah. Yann imports his version first. When I import my files, his will be lost. When you commit files, cvs will warn you if somebody else has changed them since you checked out, but there is no security check when you *import* them. As you can see, it's hard to get things right but it's pretty easy to fuck up the repository. The probably best solution is a single CVS maintainer who grabs the sources when we release them, resolves all the issues mentioned above, and updates the repository. It's a hairy job, and if one of you wants it, he can have it. But don't say you haven't been warned. These facts are of course independent of the location of the homepage or the repository. Therefore, a move can not be the answer; it just poses more questions. I suggest that you think about the existing questions instead, and try to solve the existing problems, instead of creating new ones. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 13 16:13:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ibdf-0000u9-00 for ; Thu, 13 Jun 2002 22:56:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:56:15 +0200 (CEST) Received: (qmail 20554 invoked by uid 0); 13 Jun 2002 19:13:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 13 Jun 2002 19:13:47 -0000 Received: by moria.seul.org (Postfix) id 48431146916; Thu, 13 Jun 2002 15:13:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 167F5146919; Thu, 13 Jun 2002 15:13:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id 27DEC146916 for ; Thu, 13 Jun 2002 15:13:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00660; Thu, 13 Jun 2002 16:13:26 +0200 Message-ID: <20020613161326.29048@thrai.stud.uni-hannover.de> Date: Thu, 13 Jun 2002 16:13:26 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <20020613005423.10785@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Thu, Jun 13, 2002 at 07:36:32AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 13, 2002 at 07:36:32AM +0200, Juergen Goeritz wrote: [XML vs. LaTeX] > >You mean, *browseable* HTML - lots of files, with hyperlinks? I haven't > >seen that yet. There should be one file for each F-CPU instruction, > >for example (in the old manual, the instruction set document was one > >big file). > > Just a comment from my view. I hate these online manuals > where you have all this scattered files. I prefer to do > a download of the whole manual and read it offline! If I'm going to read it cover to cover, I want a PDF (or better: a printed copy). But if I use it as a quick reference, I want HTML and short files. I don't want my browser to load a 250K document each time I check the encoding of a single instruction. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 21:35:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ibdh-0000u9-00 for ; Thu, 13 Jun 2002 22:56:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 13 Jun 2002 22:56:17 +0200 (CEST) Received: (qmail 30119 invoked by uid 0); 13 Jun 2002 19:40:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 13 Jun 2002 19:40:03 -0000 Received: by moria.seul.org (Postfix) id D1AB014681D; Thu, 13 Jun 2002 15:40:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A8F8C146844; Thu, 13 Jun 2002 15:40:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 6731214681D for ; Thu, 13 Jun 2002 15:40:02 -0400 (EDT) Received: from laposte.net (193.250.226.77) by smtp.laposte.net (5.5.044) id 3D05FC53000391EF for f-cpu@seul.org; Thu, 13 Jun 2002 21:40:01 +0200 Message-ID: <3D08F3E8.9030808@laposte.net> Date: Thu, 13 Jun 2002 21:35:04 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Prefetch and Preload References: <200206131133.27b1@th00.opsion.fr> <3D0894E8.2050508@laposte.net> <3D08C2DC.CFC33778@jetnet.ab.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ben Franchuk wrote: > Thomas Lavergne wrote: > >>>1) What distance should be used for prefectch (how many cycle beteween a >>>prefetch and the effective load) >>> >>>It depend, if you're in cache no need for it (you lose a cycle for >>>nothing). If it's not in cache you could take 150-200 cycle. But if the >>>distance is too small, depending of the implementation, you could also >>>lose one cycle (because the underlying system didn't find the adress in >>>cache and relaunch a read to the DRAM). If it's too far, the data should >>>have been trash by another data. >>> >>>Then trash or not and cache hit or not depend on the cache type (size >>>and associativity) so it depend on the effective memory adress of the >>>manipulated data. That's why i didn't like prefetch...but preload. >> >>Ok so Prefetch is very hardware specific. Very bad :-( but I seem we >>don't have any other solutions. > > > So why can't one make them pesudo-variables in special registers? > It seems a lot of timing information is needed for tomorrow's designs > where real memory and internal processing speeds differ by so much. > If we have this information on timing the software could better make use > of free time. A test for 25% full or empty on buffered information could > be very useful for dynamic optimzation. > OK but you can't realy use this information at runtime to place your prefetch at a good place because you can't reorder your code durrinf execution (too complicated). The only thing you can do is to produce different code and execute the good. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jun 13 23:20:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Ieo5-0002ya-00 for ; Fri, 14 Jun 2002 02:19:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 02:19:13 +0200 (CEST) Received: (qmail 32363 invoked by uid 0); 13 Jun 2002 21:32:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Jun 2002 21:32:35 -0000 Received: by moria.seul.org (Postfix) id 8974814681D; Thu, 13 Jun 2002 17:32:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6BA8B146916; Thu, 13 Jun 2002 17:32:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id F0CF614681D for ; Thu, 13 Jun 2002 17:32:33 -0400 (EDT) Received: from laposte.net (62.147.97.119) by smtp.laposte.net (5.5.044) id 3D05FC530003B078 for f-cpu@seul.org; Thu, 13 Jun 2002 23:32:33 +0200 Message-ID: <3D090CB4.2090802@laposte.net> Date: Thu, 13 Jun 2002 23:20:52 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Where I can put my asm code References: <200206131133.27b1@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > Don't forget to put your licence with it (GPL !). I'm sorry but I prefer release my code under the Expat Licence, clerly it say you can do all you want with code but you must keep my copyright and do not claim you have wrote the code. For stuff like these small code I think it was best than GPL. I don't want to start a troll and it's just an information, and I known that the fcpu licence (for the hardware) was frenquently discussed here and the gpl have finally won. But does anyone have made a paper that explain the reason of this choice, I don't critic it but just want to known why this and not another. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jun 14 08:28:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IwcH-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:13 +0200 (CEST) Received: (qmail 6033 invoked by uid 0); 14 Jun 2002 06:34:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 14 Jun 2002 06:34:16 -0000 Received: by moria.seul.org (Postfix) id BCD8A1467FE; Fri, 14 Jun 2002 02:34:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 849E814691C; Fri, 14 Jun 2002 02:34:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 2F0E61467FE for ; Fri, 14 Jun 2002 02:34:13 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17IkZO-000693-00 for f-cpu@seul.org; Fri, 14 Jun 2002 08:28:26 +0200 Date: Fri, 14 Jun 2002 08:28:26 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem In-Reply-To: <20020613161326.29048@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 13 Jun 2002, Michael Riepe wrote: >On Thu, Jun 13, 2002 at 07:36:32AM +0200, Juergen Goeritz wrote: >[XML vs. LaTeX] >> >You mean, *browseable* HTML - lots of files, with hyperlinks? I haven't >> >seen that yet. There should be one file for each F-CPU instruction, >> >for example (in the old manual, the instruction set document was one >> >big file). >> >> Just a comment from my view. I hate these online manuals >> where you have all this scattered files. I prefer to do >> a download of the whole manual and read it offline! > >If I'm going to read it cover to cover, I want a PDF (or better: a >printed copy). But if I use it as a quick reference, I want HTML and >short files. I don't want my browser to load a 250K document each time >I check the encoding of a single instruction. So I guess both ways should be available! Online manuals with scattered files usually eat up your internet access time, too. Especially if you have to search through it manually. ;-) J.G. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jun 14 10:19:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IwcQ-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:22 +0200 (CEST) Received: (qmail 17398 invoked by uid 0); 14 Jun 2002 08:19:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 14 Jun 2002 08:19:52 -0000 Received: by moria.seul.org (Postfix) id 7E2111467FE; Fri, 14 Jun 2002 04:19:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1AD3B14691C; Fri, 14 Jun 2002 04:19:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 1673B1467FE for ; Fri, 14 Jun 2002 04:19:41 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206140819.14b4; Fri, 14 Jun 2002 08:19:20 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Where I can put my asm code From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jun 2002 08:19:20 GMT Message-id: <200206140819.14b4@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 13/06/02 Objet: Re: [f-cpu] Where I can put my asm code Nicolas Boulay wrote: > Don't forget to put your licence with it (GPL !). I'm sorry but I prefer release my code under the Expat Licen= ce, clerly=20 it say you can do all you want with code but you must keep m= y copyright=20 and do not claim you have wrote the code. For stuff like these small code I think it was best than GPL= . >>> Expat licence are the MIT licence. I don't understand wh= y you want take the risk to have you're code stolen ! >>> If a part of the code will be used inside a librairy, th= e code should be change to LGPL. But it could be a choice to force = using GPL code (MS will attack by saying : "you see, GPL is a virus de= stroying you're business"). >>> It's finaly hard to choose ! If the piece of code "could= " be used in *every* program, it should be possible to use it inside prop= rietary code to spread the use of F-CPU. But it's not fear not to have so= mething in return. LGPL could be a nice balance. nicO I don't want to start a troll and it's just an information, = and I known=20 that the fcpu licence (for the hardware) was frenquently dis= cussed here=20 and the gpl have finally won. But does anyone have made a pa= per that=20 explain the reason of this choice, I don't critic it but jus= t want to=20 known why this and not another. --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jun 14 10:12:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IwcR-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:23 +0200 (CEST) Received: (qmail 19291 invoked by uid 0); 14 Jun 2002 08:21:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 14 Jun 2002 08:21:45 -0000 Received: by moria.seul.org (Postfix) id 1FCC014691C; Fri, 14 Jun 2002 04:21:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A27E2146921; Fri, 14 Jun 2002 04:21:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id DF60014691C for ; Fri, 14 Jun 2002 04:21:39 -0400 (EDT) Received: (qmail 24088 invoked by uid 85); 14 Jun 2002 08:24:05 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.427265 secs); 14 Jun 2002 08:24:05 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 14 Jun 2002 08:24:05 -0000 Message-ID: <3D09A572.50308@yahoo.fr> Date: Fri, 14 Jun 2002 10:12:34 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] There's something going wrong here... References: <20020611200654.28476@thrai.stud.uni-hannover.de> <000901c211f7$51e128a0$79dfc2d4@ifurita> <20020612171005.45745@thrai.stud.uni-hannover.de> <00db01c21243$f68957a0$c9fec2d4@ifurita> <20020613004722.61095@thrai.stud.uni-hannover.de> <006f01c212cb$79940500$af962cd5@ifurita> <20020613203845.52624@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Michael Riepe wrote: > > >In particular, if two people are allowed to update the same directory, >and one of them adds a file, that file will be lost if the other one >imports his version (without the new file). This does not happen with >the usual checkout/commit/update sequence, but as I mentioned before, > I have demand to my colleagues, which used every days cvs, if it's possible to have many cvsroot with the same local cvs directory. It seems not, but it is possible to configure (via a configuration file) cvs to launch specific script according to command event. And in that script, the cvsroot can be different than defined one. The way to do must be defined into the cvs manual. Perhaps that can be solve the problem. I try to find more information on the subject. > >that's impossible - I can't switch repositories, and I can't work with >the global one by default either. The only solution is to give only >one person write access to a particular directory, but that makes things >difficult again, because we have shared directories (like vhdl/common) >where files from different developers accumulate. That is, one of us >must become the official maintainer for that directory, and everybody >else must pass his changes to him, or we need to split vhdl/common into >subdirectories (common/mr, common/yg and so on). Both solutions are ugly. > >We get even bigger problems when two people create new subdirectories with >the same name. Let's say both Yann and I create vhdl/blah. Yann imports >his version first. When I import my files, his will be lost. When you >commit files, cvs will warn you if somebody else has changed them since >you checked out, but there is no security check when you *import* them. > >As you can see, it's hard to get things right but it's pretty easy >to fuck up the repository. The probably best solution is a single CVS >maintainer who grabs the sources when we release them, resolves all the >issues mentioned above, and updates the repository. It's a hairy job, >and if one of you wants it, he can have it. But don't say you haven't >been warned. > >These facts are of course independent of the location of the homepage or >the repository. Therefore, a move can not be the answer; it just poses >more questions. I suggest that you think about the existing questions >instead, and try to solve the existing problems, instead of creating >new ones. > Bye, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jun 13 13:49:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IwcX-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:29 +0200 (CEST) Received: (qmail 3287 invoked by uid 0); 14 Jun 2002 09:12:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 14 Jun 2002 09:12:40 -0000 Received: by moria.seul.org (Postfix) id D49B31467FE; Fri, 14 Jun 2002 05:12:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AAB7214691D; Fri, 14 Jun 2002 05:12:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte03.axime.com [160.92.113.38]) by moria.seul.org (Postfix) with ESMTP id 697161467FE for ; Fri, 14 Jun 2002 05:12:38 -0400 (EDT) Received: from ifurita (212.194.216.178) by smtp.laposte.net (5.5.044) id 3D05FC53000429F1 for f-cpu@seul.org; Fri, 14 Jun 2002 11:12:37 +0200 Message-ID: <000201c21383$a8b25c20$b2d8c2d4@ifurita> From: "Christophe" To: References: Subject: Re: [f-cpu] Communication problem Date: Thu, 13 Jun 2002 13:49:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Just a comment from my view. I hate these online manuals > where you have all this scattered files. I prefer to do > a download of the whole manual and read it offline! > > JG I aggree. One should not exclude the other. Not only an online manual could be interesting, but the ability to catch the whole manual to read it offline should be also proposed. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jun 14 11:17:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17IwcY-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:30 +0200 (CEST) Received: (qmail 5844 invoked by uid 0); 14 Jun 2002 09:17:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 14 Jun 2002 09:17:48 -0000 Received: by moria.seul.org (Postfix) id 761BA1467FE; Fri, 14 Jun 2002 05:17:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6938B14691C; Fri, 14 Jun 2002 05:17:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 1456C1467FE for ; Fri, 14 Jun 2002 05:17:45 -0400 (EDT) Received: from ifurita (212.194.216.178) by smtp.laposte.net (5.5.044) id 3CFD28F9000A0BC8 for f-cpu@seul.org; Fri, 14 Jun 2002 11:17:43 +0200 Message-ID: <001001c21384$5e52f120$b2d8c2d4@ifurita> From: "Christophe" To: Subject: Re: [f-cpu] There's something going wrong here... Date: Fri, 14 Jun 2002 11:17:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I don't speak french good enough to follow, and you don't understand german, do you? Well I could understand it even if I don't speak german good enough too (that would be a good exercise for me, but it is not the point here) :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 14 11:44:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Iwcf-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:37 +0200 (CEST) Received: (qmail 18824 invoked by uid 0); 14 Jun 2002 14:27:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 14 Jun 2002 14:27:15 -0000 Received: by moria.seul.org (Postfix) id AAD8D14691E; Fri, 14 Jun 2002 10:27:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 56B66146922; Fri, 14 Jun 2002 10:27:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a151.home.uni-hannover.de [130.75.232.151]) by moria.seul.org (Postfix) with ESMTP id 43C3614691E for ; Fri, 14 Jun 2002 10:27:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00500; Fri, 14 Jun 2002 11:44:18 +0200 Message-ID: <20020614114418.65394@thrai.stud.uni-hannover.de> Date: Fri, 14 Jun 2002 11:44:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <20020613161326.29048@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Juergen Goeritz on Fri, Jun 14, 2002 at 08:28:26AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jun 14, 2002 at 08:28:26AM +0200, Juergen Goeritz wrote: [...] > >If I'm going to read it cover to cover, I want a PDF (or better: a > >printed copy). But if I use it as a quick reference, I want HTML and > >short files. I don't want my browser to load a 250K document each time > >I check the encoding of a single instruction. > > So I guess both ways should be available! Online manuals > with scattered files usually eat up your internet access > time, too. Especially if you have to search through it > manually. ;-) Of course I want the HTML version on my disk, too. But I know how to use `wget -r' if it's necessary ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Fri Jun 14 17:16:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Iwcf-0000Eo-01 for ; Fri, 14 Jun 2002 21:20:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:37 +0200 (CEST) Received: (qmail 21502 invoked by uid 0); 14 Jun 2002 15:14:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 14 Jun 2002 15:14:21 -0000 Received: by moria.seul.org (Postfix) id 06E7D14691E; Fri, 14 Jun 2002 11:14:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8770146922; Fri, 14 Jun 2002 11:14:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 8C9FC14691E for ; Fri, 14 Jun 2002 11:14:17 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17Iso5-0006hx-00 for f-cpu@seul.org; Fri, 14 Jun 2002 17:16:09 +0200 Date: Fri, 14 Jun 2002 17:16:09 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem In-Reply-To: <20020614114418.65394@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, 14 Jun 2002, Michael Riepe wrote: >On Fri, Jun 14, 2002 at 08:28:26AM +0200, Juergen Goeritz wrote: >[...] >> >If I'm going to read it cover to cover, I want a PDF (or better: a >> >printed copy). But if I use it as a quick reference, I want HTML and >> >short files. I don't want my browser to load a 250K document each time >> >I check the encoding of a single instruction. >> >> So I guess both ways should be available! Online manuals >> with scattered files usually eat up your internet access >> time, too. Especially if you have to search through it >> manually. ;-) > >Of course I want the HTML version on my disk, too. But I know how to >use `wget -r' if it's necessary ;) But still takes longer than download of a single file/archive... ;) J.G. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jun 14 17:54:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Iwcg-0000Eo-01 for ; Fri, 14 Jun 2002 21:20:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:38 +0200 (CEST) Received: (qmail 12080 invoked by uid 0); 14 Jun 2002 15:57:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 14 Jun 2002 15:57:41 -0000 Received: by moria.seul.org (Postfix) id A7904146921; Fri, 14 Jun 2002 11:57:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89CD9146923; Fri, 14 Jun 2002 11:57:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.incentre.net (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 0B669146921 for ; Fri, 14 Jun 2002 11:57:37 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-207.jetnet.ab.ca [207.34.60.207]) by bach.incentre.net (8.12.3/8.12.3) with ESMTP id g5EFvjl6094375 for ; Fri, 14 Jun 2002 09:57:45 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D0A11C9.557608A2@jetnet.ab.ca> Date: Fri, 14 Jun 2002 09:54:49 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > So I guess both ways should be available! Online manuals > with scattered files usually eat up your internet access > time, too. Especially if you have to search through it > manually. ;-) > A zip formated version would be handy for DOZE people like my self. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jun 14 19:44:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Iwcj-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:41 +0200 (CEST) Received: (qmail 23243 invoked by uid 0); 14 Jun 2002 17:36:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 14 Jun 2002 17:36:39 -0000 Received: by moria.seul.org (Postfix) id 1124414680F; Fri, 14 Jun 2002 13:36:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 02414146828; Fri, 14 Jun 2002 13:36:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4AE7A14680F for ; Fri, 14 Jun 2002 13:36:37 -0400 (EDT) Received: from f-cpu.org (kdl14-49.n.club-internet.fr [213.44.12.49]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 8494216AE for ; Fri, 14 Jun 2002 19:36:34 +0200 (CEST) Message-ID: <3D0A2B70.ACB2D546@f-cpu.org> Date: Fri, 14 Jun 2002 19:44:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <3D0A11C9.557608A2@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > > Juergen Goeritz wrote: > > > So I guess both ways should be available! Online manuals > > with scattered files usually eat up your internet access > > time, too. Especially if you have to search through it > > manually. ;-) > > > A zip formated version would be handy for DOZE people like > my self. it doesn't compress, but winzip at least uncompresses tar.gz files. hope this helps. i also have found an old DOS version of gzip... > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jun 14 19:46:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Iwcl-0000Eo-00 for ; Fri, 14 Jun 2002 21:20:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 14 Jun 2002 21:20:43 +0200 (CEST) Received: (qmail 15237 invoked by uid 0); 14 Jun 2002 17:49:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 14 Jun 2002 17:49:18 -0000 Received: by moria.seul.org (Postfix) id BF1EE14680F; Fri, 14 Jun 2002 13:49:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BD38146828; Fri, 14 Jun 2002 13:49:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 2BB4D14680F for ; Fri, 14 Jun 2002 13:49:17 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.ccinet.ab.ca (8.12.3/8.12.3) with ESMTP id g5EHnOY0027158 for ; Fri, 14 Jun 2002 11:49:24 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D0A2BF4.CEBD1C32@jetnet.ab.ca> Date: Fri, 14 Jun 2002 11:46:28 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Communication problem References: <3D0A11C9.557608A2@jetnet.ab.ca> <3D0A2B70.ACB2D546@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > it doesn't compress, but winzip at least uncompresses tar.gz files. > hope this helps. i also have found an old DOS version of gzip... Well I downloaded a manual ( not sure of the version ) and winzip would not unarchive it. A version of Zip and Unzip are open source but you have to dig for it. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 17 03:31:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17JoxK-0005Mv-01 for ; Mon, 17 Jun 2002 07:21:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 07:21:34 +0200 (CEST) Received: (qmail 4427 invoked by uid 0); 17 Jun 2002 01:23:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 17 Jun 2002 01:23:38 -0000 Received: by moria.seul.org (Postfix) id 368DB1469A2; Sun, 16 Jun 2002 21:23:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 157541469CD; Sun, 16 Jun 2002 21:23:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id A107C1469A2 for ; Sun, 16 Jun 2002 21:23:35 -0400 (EDT) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-2v.club-internet.fr (Postfix) with ESMTP id E758216EB for ; Mon, 17 Jun 2002 03:23:30 +0200 (CEST) Message-ID: <3D0D3BE3.3A677648@f-cpu.org> Date: Mon, 17 Jun 2002 03:31:15 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] (!) a few noteworthy things X-Priority: 2 (High) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, - under popular demand (more than 500 hits on the french version), i will do my best to make an english translation of the document i recently presented, which describes some of the FC0 internals. - the SIMD flag still creates problems. Partial writes to a register are handled but bypass conditions are a major headache, and this has a big impact on the "zero flags". We should not forget the potential troubles that this choice can make on future architectures. Here are the existing possibilities : a) specify that the high part is unchanged (only the low byte/word/dword/etc. is updated) --> this is the current approach. b) specify that the high part is cleared --> simpler solution c) specify that the high part is sign-extended (sign extension might create troubles like those of the current solution d) specify that the SIMD flag has no effect at all and the high part is updated with the rest of the word (just like a normal SIMD operation would do) e) specify that the flag return an "undefined/reserved" behaviour for the MSB (could be both dangerous and safe, it would force compilers to generate valid pointers all the time) Also don't forget that usually, the MSB is not critical : when you operate on bytes or short ints, all the operations on that variable will have the corresponding/correct size flag and the rest of the register won't matter ... However it is important to consider the implication on the Xbar and the decoding logic, when bypass is required. d) and e) simplify the design because we don't have to choose subword results. For example, * if the result of an operation is 0x0123456789ABCDEF * the operation had a byte as size * the previous value of the destination register was 0xFEDCBA9876543210 then on bypass the new value will be a) 0xFEDCBA98765432EF (there must be another MUX to select between the old and new value) b) 0x00000000000000EF c) 0xFFFFFFFFFFFFFFEF d) 0x0123456789ABCDEF e) 0x??????????????EF personal notes : a) is possible but a bit complex. b) is simpler but still requires a mux (so a) would be the same) c) is a bit like b but the sign must be propagated : more complex because we must choose between at least 3 sign bits (corresponding to a 8, 16 and 32-bit result) d) is plain simple and would be a choice except that it would confuse compilers e) is a "failsafe" solution that would allow the implementor to choose between a), b), c) and d) on a case-per case basis. This is some more pressure on the compiler but i guess it's still manageable. As long as the debate is not closed, e) would be a safe bet before a) is completely supported and implemented. However it would become a problem, for example when the result is a byte and the next operations needs an int -> the unknown parts should be explicitely extended... - concerning the debate on the CAM of the LSU&Fetcher, there might be a "middle way" and a firtst approach, consisting of defining a primitive/generic CAM component, defined using sequential or abstract constructs in VHDL. Then, specific "architectures"/implementations could be created, which match specific technologies (ASIC/FPGA). I hope that it can give a "happy end" to this story. Maybe when it's ready, someone could synthesise several versions, and we'd choose the best architecture... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Jun 17 04:35:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17JoxN-0005Mv-00 for ; Mon, 17 Jun 2002 07:21:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 07:21:37 +0200 (CEST) Received: (qmail 27863 invoked by uid 0); 17 Jun 2002 02:38:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 17 Jun 2002 02:38:34 -0000 Received: by moria.seul.org (Postfix) id E8927146A40; Sun, 16 Jun 2002 22:38:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2D3B146A42; Sun, 16 Jun 2002 22:38:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 582D9146A40 for ; Sun, 16 Jun 2002 22:38:32 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.ccinet.ab.ca (8.12.3/8.12.3) with ESMTP id g5H2cmY0054260 for ; Sun, 16 Jun 2002 20:38:48 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> Date: Sun, 16 Jun 2002 20:35:43 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > personal notes : > a) is possible but a bit complex. > b) is simpler but still requires a mux (so a) would be the same) > c) is a bit like b but the sign must be propagated : > more complex because we must choose between at least > 3 sign bits (corresponding to a 8, 16 and 32-bit result) > d) is plain simple and would be a choice except that it would confuse compilers > e) is a "failsafe" solution that would allow the implementor to choose between > a), b), c) and d) on a case-per case basis. This is some more pressure on the > compiler but i guess it's still manageable. But would selection of what happens depends on just what is meant by a byte and just what you are doing? Unless you are packing bytes for something like byteswap why is a internal representation of bytes needed on a modern machine? The 8008 had load H,# and load L,# and load a,(HL) because the machine could only process bytes? No wait this is a RISC machine age !! You can't have 32,64?? bit immediate constant in the next word! Other than stupid Immediate packing because of a brain dead achitecure design all data should be converted to 32 or 64 bit internal format upon loading and not adjusted in the register bypass. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 17 05:10:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17JoxP-0005Mv-00 for ; Mon, 17 Jun 2002 07:21:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 07:21:39 +0200 (CEST) Received: (qmail 9208 invoked by uid 0); 17 Jun 2002 03:02:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 17 Jun 2002 03:02:34 -0000 Received: by moria.seul.org (Postfix) id B398C1469A5; Sun, 16 Jun 2002 23:02:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A68BA146A40; Sun, 16 Jun 2002 23:02:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4A6C01469A5 for ; Sun, 16 Jun 2002 23:02:30 -0400 (EDT) Received: from f-cpu.org (kdl16-4.n.club-internet.fr [213.44.18.4]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9B74C1693 for ; Mon, 17 Jun 2002 05:02:27 +0200 (CEST) Message-ID: <3D0D5316.D15731E2@f-cpu.org> Date: Mon, 17 Jun 2002 05:10:14 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > Yann Guidon wrote: > No wait this is a RISC machine age !! You can't have 32,64?? bit immediate > constant in the next word! Other than stupid Immediate packing because > of a brain dead achitecure design all data should be converted to 32 > or 64 bit internal format upon loading and not adjusted in the register > bypass. this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) f) avoid bypass if the size of the written register is different from the required operand :-) this way, no need to make a complex bypass mux. This is pretty easy to check, and there would be only 2 cycles of penalty otherwise (in case of "naughty coding" practices). oh yes, i like that :-P > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jun 17 11:09:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Jy3w-0000Fz-00 for ; Mon, 17 Jun 2002 17:05:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 17:05:00 +0200 (CEST) Received: (qmail 5854 invoked by uid 0); 17 Jun 2002 09:09:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 17 Jun 2002 09:09:39 -0000 Received: by moria.seul.org (Postfix) id 2515C146A9F; Mon, 17 Jun 2002 05:09:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CEAC146B37; Mon, 17 Jun 2002 05:09:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [195.219.20.10]) by moria.seul.org (Postfix) with SMTP id 8C903146A9F for ; Mon, 17 Jun 2002 05:09:35 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200206170909.1383; Mon, 17 Jun 2002 09:09:19 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] (!) a few noteworthy things From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2002 09:09:19 GMT Message-id: <200206170909.1383@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 17/06/02 Objet: Re: [f-cpu] (!) a few noteworthy things hi, Ben Franchuk wrote: > Yann Guidon wrote: > No wait this is a RISC machine age !! You can't have 32,64= ?? bit immediate > constant in the next word! Other than stupid Immediate pac= king because > of a brain dead achitecure design all data should be conve= rted to 32 > or 64 bit internal format upon loading and not adjusted i= n the register > bypass. this is unrelated but you just gave me an idea for a 6th sol= ution ("f)") :-) f) avoid bypass if the size of the written register is diff= erent from the required operand :-) this way, no need to make a complex bypass mux. This is pretty easy to check, and there would be only 2 cycl= es of penalty otherwise (in case of "naughty coding" practices)= . oh yes, i like that :-P >>> It look nice from a soft point of view. But it's add a d= osen of comparatrt to check the equality of the SIMD flags. e) ( at = least any version that doesn't need a read to the register bank to hav= e the bypass) should be more appriopriate. Is that so common to us= e register as 8 bits and reuse it as 16 or 32 bits ? Does the area cost= of comparators are justified ?=20 nicO > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 17 21:01:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17K3uy-0000DI-01 for ; Mon, 17 Jun 2002 23:20:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 23:20:08 +0200 (CEST) Received: (qmail 11847 invoked by uid 0); 17 Jun 2002 18:53:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 17 Jun 2002 18:53:48 -0000 Received: by moria.seul.org (Postfix) id 5CFEE146CA4; Mon, 17 Jun 2002 14:53:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26B80146CA7; Mon, 17 Jun 2002 14:53:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id BD830146CA4 for ; Mon, 17 Jun 2002 14:53:46 -0400 (EDT) Received: from f-cpu.org (kll1-241.n.club-internet.fr [213.44.91.241]) by relay-3v.club-internet.fr (Postfix) with ESMTP id EA3BE170D for ; Mon, 17 Jun 2002 20:53:43 +0200 (CEST) Message-ID: <3D0E320A.50A82B@f-cpu.org> Date: Mon, 17 Jun 2002 21:01:30 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] (!) a few noteworthy things References: <200206170909.1383@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Nicolas Boulay wrote: > De: Yann Guidon > Ben Franchuk wrote: > > Yann Guidon wrote: > > this is unrelated but you just gave me an idea for a 6th solution ("f)") > :-) > > f) avoid bypass if the size of the written register is different from > the required operand :-) > > this way, no need to make a complex bypass mux. > This is pretty easy to check, and there would be only 2 cycles > of penalty otherwise (in case of "naughty coding" practices). > > oh yes, i like that :-P > > >>> It look nice from a soft point of view. But it's add a dosen of > comparatrt to check the equality of the SIMD flags. e) ( at least any > version that doesn't need a read to the register bank to have the > bypass) should be more appriopriate. Is that so common to use register > as 8 bits and reuse it as 16 or 32 bits ? It is not "much" often but - when it's used (on purpose), it's practical and useful - any combination of instructions must give a deterministic result (otherwise, the code won't be portable from one CPU to another) so we have to be careful > Does the area cost of comparators are justified ? Remember that the bypass condition must be checked anyway, at least so that "normal" code does not suffer from the write back latency. Checking the size flag adds a dozen of bit comparisons, only the 2 or 3 last pipeline stages are necessary, the size flag is 2-bit wide and there are 2 write ports ==> 2*2*3=12, no ? This is not much compared to the other comparators, which have to compare hundreds of bits (in the FIFO and for the LSU/fetcher tags) Apart from the simple solution of dropping the SIMD flag, all the other solutions require some management, and particularly on the datapath (which is even more critical). > > Ben Franchuk - Dawn * 12/24 bit cpu * > WHYGEE > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 17 16:05:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17K3uz-0000DI-01 for ; Mon, 17 Jun 2002 23:20:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 23:20:09 +0200 (CEST) Received: (qmail 973 invoked by uid 0); 17 Jun 2002 19:11:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 17 Jun 2002 19:11:58 -0000 Received: by moria.seul.org (Postfix) id 38E98146CA6; Mon, 17 Jun 2002 15:11:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 18C2F146CA8; Mon, 17 Jun 2002 15:11:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 86589146CA7 for ; Mon, 17 Jun 2002 15:11:55 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00608; Mon, 17 Jun 2002 16:05:29 +0200 Message-ID: <20020617160529.43987@thrai.stud.uni-hannover.de> Date: Mon, 17 Jun 2002 16:05:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0D5316.D15731E2@f-cpu.org>; from Yann Guidon on Mon, Jun 17, 2002 at 05:10:14AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 17, 2002 at 05:10:14AM +0200, Yann Guidon wrote: > hi, > > Ben Franchuk wrote: > > Yann Guidon wrote: > > > No wait this is a RISC machine age !! You can't have 32,64?? bit immediate > > constant in the next word! Other than stupid Immediate packing because > > of a brain dead achitecure design all data should be converted to 32 > > or 64 bit internal format upon loading and not adjusted in the register > > bypass. > > this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) > > f) avoid bypass if the size of the written register is different from > the required operand :-) Is that a variant of a), b), c) or d)? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 17 16:00:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17K3v0-0000DI-00 for ; Mon, 17 Jun 2002 23:20:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 17 Jun 2002 23:20:10 +0200 (CEST) Received: (qmail 3615 invoked by uid 0); 17 Jun 2002 19:12:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 17 Jun 2002 19:12:01 -0000 Received: by moria.seul.org (Postfix) id 65F95146CA7; Mon, 17 Jun 2002 15:12:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 27191146CAC; Mon, 17 Jun 2002 15:12:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 7EA4A146CA7 for ; Mon, 17 Jun 2002 15:11:57 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00593; Mon, 17 Jun 2002 16:00:57 +0200 Message-ID: <20020617160057.08129@thrai.stud.uni-hannover.de> Date: Mon, 17 Jun 2002 16:00:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0D3BE3.3A677648@f-cpu.org>; from Yann Guidon on Mon, Jun 17, 2002 at 03:31:15AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 17, 2002 at 03:31:15AM +0200, Yann Guidon wrote: [...] > - the SIMD flag still creates problems. > Partial writes to a register are handled but bypass conditions are > a major headache, and this has a big impact on the "zero flags". > We should not forget the potential troubles that this choice > can make on future architectures. Here are the existing possibilities : > a) specify that the high part is unchanged > (only the low byte/word/dword/etc. is updated) > --> this is the current approach. - requires partial writes - requires additional instructions for zero/sign extension > b) specify that the high part is cleared --> simpler solution + requires no partial writes + saves on instruction for zero extension + cheap to implement: signal X, Y, Mask : std_ulogic_vector(63 downto 0); ... Mask <= ( 63 downto 32 => SIMD or U(2), 31 downto 16 => SIMD or U(1), 15 downto 8 => SIMD or U(0), others => '1' ); -- note that Mask is available from the decoder -- there's only an AND (or maybe MUX) inside the signal path Y <= X and Mask; > c) specify that the high part is sign-extended > (sign extension might create troubles like those of the > current solution + requires no partial writes + saves one instruction for sign extension - more complex than b) because there are multiple sign bits to consider > d) specify that the SIMD flag has no effect at all and the > high part is updated with the rest of the word (just like a > normal SIMD operation would do) + all the world is SIMD :) + requires no partial writes + even cheaper to implement than b) - requires additional instruction for zero/sign extension > e) specify that the flag return an "undefined/reserved" behaviour > for the MSB (could be both dangerous and safe, it would force > compilers to generate valid pointers all the time) + even cheaper to implement than b) - worst solution ever > Also don't forget that usually, the MSB is not critical : > when you operate on bytes or short ints, all the operations > on that variable will have the corresponding/correct size flag > and the rest of the register won't matter ... > > However it is important to consider the implication on the Xbar > and the decoding logic, when bypass is required. d) and e) simplify > the design because we don't have to choose subword results. [...] > personal notes : > a) is possible but a bit complex. > b) is simpler but still requires a mux (so a) would be the same) > c) is a bit like b but the sign must be propagated : > more complex because we must choose between at least > 3 sign bits (corresponding to a 8, 16 and 32-bit result) > d) is plain simple and would be a choice except that it would confuse compilers > e) is a "failsafe" solution that would allow the implementor to choose between > a), b), c) and d) on a case-per case basis. This is some more pressure on the > compiler but i guess it's still manageable. > > As long as the debate is not closed, e) would be a safe bet before a) is completely > supported and implemented. However it would become a problem, for example when > the result is a byte and the next operations needs an int -> the unknown parts > should be explicitely extended... e) will allow implementors to build F-CPUs that work like a), b), c), d), or any other way. As soon as those versions exist, programmers will use this particular `feature' (trust me - they *will*), and the resulting code will no longer be compatible between F-CPU versions. Therefore, we have to avoid e). Since I don't like a), and c) is more expensive than b), and d) is what we have in SIMD mode, I prefer b). On the other hand, turning SIMD on unconditionally *is* tempting. It would free one flag and streamline the instruction set (the s- prefix will no longer be needed). That is, my second choice is d). What about f): keep the SIMD bit but make d) the default and b) optional behaviour. That is, when the SIMD flag is cleared, a `conforming' F-CPU must either mask the result or trigger an `invalid instruction' trap (this can be handled inside the decoder). From the design and specification point of view, this solution is much cleaner than e). I suggest we choose f) but make any reasonable effort to implement b). Did you think about the new loadcons[p] I suggested? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jun 18 02:36:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KFoI-0008MS-00 for ; Tue, 18 Jun 2002 12:02:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Jun 2002 12:02:02 +0200 (CEST) Received: (qmail 30521 invoked by uid 0); 18 Jun 2002 00:28:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 18 Jun 2002 00:28:41 -0000 Received: by moria.seul.org (Postfix) id B87AD1467F7; Mon, 17 Jun 2002 20:28:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73C09146823; Mon, 17 Jun 2002 20:28:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id D66761467F7 for ; Mon, 17 Jun 2002 20:28:39 -0400 (EDT) Received: from f-cpu.org (kdl11-1.n.club-internet.fr [213.44.9.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id CA8F816BE for ; Tue, 18 Jun 2002 02:28:34 +0200 (CEST) Message-ID: <3D0E8087.452AF1CC@f-cpu.org> Date: Tue, 18 Jun 2002 02:36:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Mon, Jun 17, 2002 at 03:31:15AM +0200, Yann Guidon wrote: > [...] > > - the SIMD flag still creates problems. > > Partial writes to a register are handled but bypass conditions are > > a major headache, and this has a big impact on the "zero flags". > > We should not forget the potential troubles that this choice > > can make on future architectures. Here are the existing possibilities : > > a) specify that the high part is unchanged > > (only the low byte/word/dword/etc. is updated) > > --> this is the current approach. > > - requires partial writes on the register set, this is not much a problem. However, it becomes a problem for 2 things : - kepping the "zero" flags up to date (partial write of the flag + timing problems) - bypass (one unit's output is connected to another unit's input, but one part of the word must come from the register set... and this can become quite complex) > - requires additional instructions for zero/sign extension Isn't SHL meant to do that ? btw, we don't have sign extension instructions because this SIMD/partial write stuff is still not solved. i hope it will be solved cleanly soon. > > b) specify that the high part is cleared --> simpler solution > > + requires no partial writes > + saves on instruction for zero extension particularly important for pointers !!! > + cheap to implement: > > signal X, Y, Mask : std_ulogic_vector(63 downto 0); > ... > Mask <= ( > 63 downto 32 => SIMD or U(2), > 31 downto 16 => SIMD or U(1), > 15 downto 8 => SIMD or U(0), > others => '1' > ); > -- note that Mask is available from the decoder > -- there's only an AND (or maybe MUX) inside the signal path > Y <= X and Mask; that's where it hurts : it's in the critical datapath :-/ > > c) specify that the high part is sign-extended > > (sign extension might create troubles like those of the > > current solution > + requires no partial writes > + saves one instruction for sign extension > - more complex than b) because there are multiple sign bits to > consider that's what i noted : not a good solution. > > d) specify that the SIMD flag has no effect at all and the > > high part is updated with the rest of the word (just like a > > normal SIMD operation would do) > + all the world is SIMD :) ... and "God is real, unless you declare it as a char" (ok, it's not my invention, but it goes well along your remark :-D) > + requires no partial writes > + even cheaper to implement than b) sure... > - requires additional instruction for zero/sign extension it's needed anyway (at least compiler writers will want one, and people will be fed up to fiddle with arithmetic shifts etc...) don't you do one with your unit ? > > e) specify that the flag return an "undefined/reserved" behaviour > > for the MSB (could be both dangerous and safe, it would force > > compilers to generate valid pointers all the time) > + even cheaper to implement than b) > - worst solution ever sure. > [...] > e) will allow implementors to build F-CPUs that work like a), b), c), d), > or any other way. that's the obvious purpose (you seem to read in my mind ;-D) > As soon as those versions exist, programmers will use > this particular `feature' (trust me - they *will*), i know this, too. > and the resulting code will no longer be compatible between F-CPU versions. > Therefore, we have to avoid e). This was meant as a "temporary" version before the "F-CPU rev. 1" milestone. Before that, compatibility is not ensured and binary compatibility will not be enforced (because the opcodes won't be defined). > Since I don't like a), at least it won't disturb people who are used to non-RISC systems... that's the behaviour i have seen on most existing multi-size computers (68xx, 68K, inteloids etc...) > and c) is more expensive than b), obviously. > and d) is what we have in SIMD mode, I prefer b). b) is what first came to my mind but i soon realised that there are other possibilities, so i wanted to explore them all. My sources and model implement a) but i did not choose between b) and f). f) is closer to a) and b) shifts the problem from the register set to the execution units. It's a tough decision and we have to consider a lot of things, including future implementations... > On the other hand, turning SIMD on unconditionally *is* tempting. :-) didn't you propose that ?... or i misunderstood your request ? > It would free one flag and streamline the instruction set (the s- prefix > will no longer be needed). That is, my second choice is d). that's a radical cleanup, right :-) > What about f): keep the SIMD bit but make d) the default and b) optional > behaviour. you want to make a special case of e) ? > That is, when the SIMD flag is cleared, a `conforming' > F-CPU must either mask the result or trigger an `invalid instruction' > trap (this can be handled inside the decoder). From the design and > specification point of view, this solution is much cleaner than e). my intent for e) was to be completely ... open and as imprecise as possible so your proposition is certainly more "orthodox". but that doesn't solve the whole problem at all (the programs would spend their time in the exception routines...) > I suggest we choose f) but make any reasonable effort to implement b). i prefer "my" f) but b) has some problems to be solved... > Did you think about the new loadcons[p] I suggested? ??? did i miss or forget something ? can you explain and detail what you mean ? > On Mon, Jun 17, 2002 at 05:10:14AM +0200, Yann Guidon wrote: > > Ben Franchuk wrote: > > > Yann Guidon wrote: > > > > this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) > > > > f) avoid bypass if the size of the written register is different from > > the required operand :-) > > Is that a variant of a), b), c) or d)? no. it's something completely different. the idea behind this is that in a), the bypass network has to choose between more data and mix them into a single word (i gave examples). my idea was to not do the bypass (and thus avoid the complex mux management in the critical datapath) when a chunk size change is detected. the first instruction would continue to go through the write pipeline and the second (which would usually trigger the bypass) would wait until the register set performs the partial write itself. This keeps the complex muxes out of the critical datapath, it solves one problem at the cost of some more latencies >from time to time in "micro$oft-like" codes. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : for the good reason that i would like to rest a bit (and few people would be able to decypher my attemps at being clear...), i skipped the reasons why b) shifts the problem from the register set to the main datapath. However, during a little pause, i got an interesting idea ! Here is the problem : For reasons that i don't have time to detail, the "Xbar" is a bunch of wires that are routed over the execution units to keep distances small and avoid the big "stuff" that can be found on the usual FC0 diagrams. This uses one or two more metal layers but the surface and the distance are reduced. To optimise the design, the usual execution units are all in line, but one half of the units are flipped (in an odd/even fashion) so neighbouring units can "share" the latches of the input or the output of the Xbar. This organisation comes from some experiments i made on precaracterized cells, and i remarked that the FF take one half of the surface, while the execution unit is a very long strip. Sharing the FFs between neighbours can save 25% of the surface/speed/consumption/price... The "Xbar" entity can be seen as divided into 3 components : - Xbar_input latches the Xbar read and write lines, thus performing the bypass, and gives the operand to the left and right-hand units. - Xbar_output chooses between the left and right-hand unit's results and "buffers" the result on the Xbar result autobahn. In order to reduce wire lengths and reduce the need for high drives, an additional MUX (at the output of the FF) will choose between the local FF or the data that comes from the next Xbar_output. I have used this technique once and it gives good results on hand-placed semicustom ASIC. - Xbar_network connects the Register Set, all the Xbar_input and all the Xbar_output's together. it can be considered as the part that is routed on the high metal layers. This is pretty easy to design and control, because the result MUX is traightforward and spread over the whole datapath. However, with a 64-bit design, these control signal might be slow and heavy to operate. The "result MUX" requires long lines and high drive. Adding another control signal that selects "0" at the MSB requires 2x more drive and this is my problem :-/ One solution i propose for implementing b) is to "clear" the corresponding MSB when the data is handed to the Xbar by the register set. Most instructions (except ROP2 and INC with the "neg" and "not" operations) will return a 0 result (0+0=0, etc.). So there is less need to modify the Xbar_output units and less wires to spread. Do you understand the trick ? instead of clearing the MSB of the results at the output of the EUs (it's important to do this because the result is needed for bypass directly on the Xbar, and the partial write of the register set will not be enough), the MSB is cleared when the operands are read (less places where the MSB is cleared, so less control signals). With this trick, the Register set is super-simplified, but some more care must be taken inside the datapath. I hope that this explanation is not too confusing... i gotta make some more drawings but i can't do that now because my computers are broken... :-( ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From JGraley@sonicblue.com Tue Jun 18 14:51:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KLQl-0000Y9-01 for ; Tue, 18 Jun 2002 18:02:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Jun 2002 18:02:07 +0200 (CEST) Received: (qmail 12427 invoked by uid 0); 18 Jun 2002 12:47:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 18 Jun 2002 12:47:30 -0000 Received: by moria.seul.org (Postfix) id 017371467F6; Tue, 18 Jun 2002 08:47:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BB7CC1467FE; Tue, 18 Jun 2002 08:47:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by moria.seul.org (Postfix) with ESMTP id BE75D1467F6 for ; Tue, 18 Jun 2002 08:47:26 -0400 (EDT) Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g5IClP921357 for ; Tue, 18 Jun 2002 06:47:25 -0600 (MDT) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g5IClP625922 for ; Tue, 18 Jun 2002 05:47:25 -0700 (PDT) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Tue Jun 18 05:56:29 2002 -0700 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 05:48:29 -0700 Message-ID: <37D1208A1C9BD511855B00D0B772242C0118AD76@corpmail1.sc.sonicblue.com> From: John Graley To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] (!) a few noteworthy things Date: Tue, 18 Jun 2002 05:51:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > then on bypass the new value will be > a) 0xFEDCBA98765432EF (there must be another MUX to select > between the old > and new value) > b) 0x00000000000000EF > c) 0xFFFFFFFFFFFFFFEF > d) 0x0123456789ABCDEF > e) 0x??????????????EF Assuming you can use 8-bit SIMD instructions on data of the form 0x??????????????xy in order to obtain correct results for the bottom 8 bits, neglecting the other bits, then you should use option e. This is only inadequate in places where the program is converting a short data type to a longer type (when you need b for unsigned and c for signed), and this occurs fairly infrequently in program code, so it would be wasteful to do it every time. Instead you should have explicit cast instructions for b and c. Cheers, John ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jun 18 18:50:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KMdq-0001Tr-01 for ; Tue, 18 Jun 2002 19:19:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Jun 2002 19:19:42 +0200 (CEST) Received: (qmail 23230 invoked by uid 0); 18 Jun 2002 16:54:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 18 Jun 2002 16:54:07 -0000 Received: by moria.seul.org (Postfix) id 842E4146803; Tue, 18 Jun 2002 12:54:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59C4D146809; Tue, 18 Jun 2002 12:54:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a096.home.uni-hannover.de [130.75.232.96]) by moria.seul.org (Postfix) with ESMTP id 51DE5146803 for ; Tue, 18 Jun 2002 12:54:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01331; Tue, 18 Jun 2002 18:50:45 +0200 Message-ID: <20020618185045.43598@thrai.stud.uni-hannover.de> Date: Tue, 18 Jun 2002 18:50:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: More Alphabet Soup (was: [f-cpu] (!) a few noteworthy things) References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0E8087.452AF1CC@f-cpu.org>; from Yann Guidon on Tue, Jun 18, 2002 at 02:36:23AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! Unfortunately, on of my mails (concerning partial writes) seems to have gone unnoticed... On Tue, Jun 18, 2002 at 02:36:23AM +0200, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > On Mon, Jun 17, 2002 at 03:31:15AM +0200, Yann Guidon wrote: > > [...] > > > - the SIMD flag still creates problems. > > > Partial writes to a register are handled but bypass conditions are > > > a major headache, and this has a big impact on the "zero flags". > > > We should not forget the potential troubles that this choice > > > can make on future architectures. Here are the existing possibilities : > > > a) specify that the high part is unchanged > > > (only the low byte/word/dword/etc. is updated) > > > --> this is the current approach. > > > > - requires partial writes > on the register set, this is not much a problem. However, it > becomes a problem for 2 things : > - kepping the "zero" flags up to date (partial write of the flag + timing problems) > - bypass (one unit's output is connected to another unit's input, but one part of the > word must come from the register set... and this can become quite complex) > > > - requires additional instructions for zero/sign extension > Isn't SHL meant to do that ? Or any other unit. The omega shifter can't do it; if we want it, we need extra code. > btw, we don't have sign extension instructions because this SIMD/partial write > stuff is still not solved. i hope it will be solved cleanly soon. > > > > b) specify that the high part is cleared --> simpler solution > > > > + requires no partial writes > > + saves on instruction for zero extension > particularly important for pointers !!! Maybe not for pointers (since they're always full size), but for pointer arithmetics (add/subtract a small offset to/from a pointer, for example). > > + cheap to implement: > > > > signal X, Y, Mask : std_ulogic_vector(63 downto 0); > > ... > > Mask <= ( > > 63 downto 32 => SIMD or U(2), > > 31 downto 16 => SIMD or U(1), > > 15 downto 8 => SIMD or U(0), > > others => '1' > > ); > > -- note that Mask is available from the decoder > > -- there's only an AND (or maybe MUX) inside the signal path > > Y <= X and Mask; > > that's where it hurts : it's in the critical datapath :-/ If bypassed values don't have to be zero-extended (as in your f) proposal), we can include it into the write ports of the register set. And it's only a single AND (or MUX). > > > c) specify that the high part is sign-extended > > > (sign extension might create troubles like those of the > > > current solution > > + requires no partial writes > > + saves one instruction for sign extension > > - more complex than b) because there are multiple sign bits to > > consider > that's what i noted : not a good solution. No, not at all. > > > d) specify that the SIMD flag has no effect at all and the > > > high part is updated with the rest of the word (just like a > > > normal SIMD operation would do) > > + all the world is SIMD :) > ... and "God is real, unless you declare it as a char" > (ok, it's not my invention, but it goes well along your remark :-D) I guess it was `... unless declared integer'. There is no `char' in Fortran (only character - but God probably lacks that ;). > > + requires no partial writes > > + even cheaper to implement than b) > sure... > > > - requires additional instruction for zero/sign extension > it's needed anyway (at least compiler writers will want one, > and people will be fed up to fiddle with arithmetic shifts etc...) > > don't you do one with your unit ? Not yet. I've been looking for a better solution... > > > e) specify that the flag return an "undefined/reserved" behaviour > > > for the MSB (could be both dangerous and safe, it would force > > > compilers to generate valid pointers all the time) > > + even cheaper to implement than b) > > - worst solution ever > sure. > > > [...] > > e) will allow implementors to build F-CPUs that work like a), b), c), d), > > or any other way. > that's the obvious purpose (you seem to read in my mind ;-D) .o( using Linux Telepathy Driver v0.0.1-alpha ) > > As soon as those versions exist, programmers will use > > this particular `feature' (trust me - they *will*), > i know this, too. > > > and the resulting code will no longer be compatible between F-CPU versions. > > Therefore, we have to avoid e). > This was meant as a "temporary" version before the "F-CPU rev. 1" milestone. > Before that, compatibility is not ensured and binary compatibility will > not be enforced (because the opcodes won't be defined). If the non-SIMD opcodes trigger a trap, your e) is almost my f). > > Since I don't like a), > at least it won't disturb people who are used to non-RISC systems... > that's the behaviour i have seen on most existing multi-size computers > (68xx, 68K, inteloids etc...) And it sucks. > > and c) is more expensive than b), > obviously. > > > and d) is what we have in SIMD mode, I prefer b). > b) is what first came to my mind but i soon realised that there are > other possibilities, so i wanted to explore them all. > > My sources and model implement a) but i did not choose between b) and f). > f) is closer to a) and b) shifts the problem from the register set to > the execution units. It's a tough decision and we have to consider a lot > of things, including future implementations... > > > On the other hand, turning SIMD on unconditionally *is* tempting. > :-) > didn't you propose that ?... or i misunderstood your request ? No, *you* did. I still want b), one way or another. > > It would free one flag and streamline the instruction set (the s- prefix > > will no longer be needed). That is, my second choice is d). > that's a radical cleanup, right :-) Tabula rasa (for those of you who don't understand latin: `clean table') is better than creeping featurism (SW people, are you listening?), especially if you have to deal with limited resources (like die space or delay time). I don't want the F-CPU to suffer from `galloping elephantiasis' (or was it called `chronic Intelism'? ;) > > What about f): keep the SIMD bit but make d) the default and b) optional > > behaviour. > you want to make a special case of e) ? Yes, but a *clean* one. There's a difference between saying: `the behaviour is unspecified' and `these opcodes are reserved for a specific purpose'. > > That is, when the SIMD flag is cleared, a `conforming' > > F-CPU must either mask the result or trigger an `invalid instruction' > > trap (this can be handled inside the decoder). From the design and > > specification point of view, this solution is much cleaner than e). > my intent for e) was to be completely ... open and as imprecise as possible > so your proposition is certainly more "orthodox". but that doesn't > solve the whole problem at all (the programs would spend their time > in the exception routines...) Programs are supposed to use SIMD operations whenever possible. By making other variants much more expensive, we kind of force d) through the back door, at least on the specification level :) I know, this sounds like RMS in a Linux vs. GNU/Linux debate ;) > > I suggest we choose f) but make any reasonable effort to implement b). > i prefer "my" f) but b) has some problems to be solved... I guess we can combine your f) with a), b), c) or d) - or my f). > > Did you think about the new loadcons[p] I suggested? > ??? did i miss or forget something ? > can you explain and detail what you mean ? See my mail from Wed, 5 Jun 2002 22:47:29 +0200. The subject was "Partial Writes Considered Harmful". > > On Mon, Jun 17, 2002 at 05:10:14AM +0200, Yann Guidon wrote: > > > Ben Franchuk wrote: > > > > Yann Guidon wrote: > > > > > > this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) > > > > > > f) avoid bypass if the size of the written register is different from > > > the required operand :-) > > > > Is that a variant of a), b), c) or d)? > no. > it's something completely different. They're almost orthogonal. > the idea behind this is that in a), the bypass network has to choose between > more data and mix them into a single word (i gave examples). > > my idea was to not do the bypass (and thus avoid the complex mux management > in the critical datapath) when a chunk size change is detected. the first > instruction would continue to go through the write pipeline and the second > (which would usually trigger the bypass) would wait until the register set > performs the partial write itself. This keeps the complex muxes out of the > critical datapath, it solves one problem at the cost of some more latencies > from time to time in "micro$oft-like" codes. That can be done with any variant. When the chunk sizes don't match, let the second instruction wait until the register set has performed the write. Whether it's a partial write (a), a masked write (b) or a sign-extended write (c) doesn't really matter. BTW: if masking is done when the register is written, bypassing *is* possible unless the second instruction has wider operands. > PS : for the good reason that i would like to rest a bit (and few > people would be able to decypher my attemps at being clear...), > i skipped the reasons why b) shifts the problem from the register set > to the main datapath. I'm aware of that anyway. But b) combined with your f) might be a good solution. > However, during a little pause, i got an interesting idea ! > > Here is the problem : For reasons that i don't have time to detail, > the "Xbar" is a bunch of wires that are routed over the execution > units to keep distances small and avoid the big "stuff" that can be > found on the usual FC0 diagrams. This uses one or two more metal layers > but the surface and the distance are reduced. > > To optimise the design, the usual execution units are all in line, but > one half of the units are flipped (in an odd/even fashion) so neighbouring > units can "share" the latches of the input or the output of the Xbar. > This organisation comes from some experiments i made on precaracterized > cells, and i remarked that the FF take one half of the surface, while > the execution unit is a very long strip. Sharing the FFs between neighbours > can save 25% of the surface/speed/consumption/price... At the input of the EUs, at the output, or both? Note that you may introduce EU dependencies that way. [...] > One solution i propose for implementing b) is to "clear" the corresponding MSB > when the data is handed to the Xbar by the register set. Most instructions > (except ROP2 and INC with the "neg" and "not" operations) will return a 0 > result (0+0=0, etc.). So there is less need to modify the Xbar_output units > and less wires to spread. Another exception is the IDU (0/0 = ?). For other drawbacks, see A) below. > Do you understand the trick ? instead of clearing the MSB of the results > at the output of the EUs (it's important to do this because the result is > needed for bypass directly on the Xbar, and the partial write of the register > set will not be enough), the MSB is cleared when the operands are read > (less places where the MSB is cleared, so less control signals). There are at least four approaches (capital letters this time): A) `early masking': mask off the high bits when the register is read (before the instruction is issued). + masking moved to register set - bypass impossible when first instruction has wider operands 1) - requires at least 3 masking units (one per register read port) - some instructions need special handling (complex!) 1) Surprise! You need to mask the operands of the second instruction but there is no masking unit inside the bypass. B) `write masking': mask off the high bits when the result is written to the register. + masking moved to register set + requires only 2 masking units (one per register write port) - bypass impossible when second instruction has wider operands C) `late masking': store the chunk size in the register set (or scoreboard) and mask off the high bits when the result is read from the register (that is, before the *next* instruction that uses the value). + masking moved to register set - bypass impossible when second instruction has wider operands - requires at least 3 masking units (one per register read port) - requires extra `valid' bits that indicate the chunk size D) move the problem to the EUs. This can be done easily in the IMU, but there's no room left inside the ASU, for example. SHL is pretty tight, too (I already violate the `6 gate rule' there). + bypass always possible - heavy implementation - not all EUs support it E/F/G anyone? ;) If we can add a masking unit inside the bypass, ABC) will always be able to bypass results. But even if we can't, B) looks like the best solution so far. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jun 18 20:18:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KP85-0003Sc-00 for ; Tue, 18 Jun 2002 21:59:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 18 Jun 2002 21:59:05 +0200 (CEST) Received: (qmail 27361 invoked by uid 0); 18 Jun 2002 18:02:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 18 Jun 2002 18:02:15 -0000 Received: by moria.seul.org (Postfix) id 6F80E146809; Tue, 18 Jun 2002 14:02:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2492F14680B; Tue, 18 Jun 2002 14:02:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7EEA8146809 for ; Tue, 18 Jun 2002 14:02:12 -0400 (EDT) Received: from ifrance.com (vlt9-202.n.club-internet.fr [195.36.223.202]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BD0231704 for ; Tue, 18 Jun 2002 20:02:07 +0200 (CEST) Message-ID: <3D0F7989.727E0587@ifrance.com> Date: Tue, 18 Jun 2002 20:18:49 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi ! > > Michael Riepe wrote: > > On Mon, Jun 17, 2002 at 03:31:15AM +0200, Yann Guidon wrote: > > [...] > > > - the SIMD flag still creates problems. > > > Partial writes to a register are handled but bypass conditions are > > > a major headache, and this has a big impact on the "zero flags". > > > We should not forget the potential troubles that this choice > > > can make on future architectures. Here are the existing possibilities : > > > a) specify that the high part is unchanged > > > (only the low byte/word/dword/etc. is updated) > > > --> this is the current approach. > > > > - requires partial writes > on the register set, this is not much a problem. However, it > becomes a problem for 2 things : > - kepping the "zero" flags up to date (partial write of the flag + timing problems) We should defined 8, 16, 32, 64 bits "zero" flag. > - bypass (one unit's output is connected to another unit's input, but one part of the > word must come from the register set... and this can become quite complex) > I don't think it's complexe : it's just on overkill ! We need to read the register that will be write ! Otherwise we can't compute things depending one all bits in the register. In e), if we checks the kind of SIMd to bypass, there is always the problem for the zero flag that aren't correct any more. Or we need to treat special case with a longer cdp. > > - requires additional instructions for zero/sign extension > Isn't SHL meant to do that ? > > btw, we don't have sign extension instructions because this SIMD/partial write > stuff is still not solved. i hope it will be solved cleanly soon. > > > > b) specify that the high part is cleared --> simpler solution > > > > + requires no partial writes > > + saves on instruction for zero extension > particularly important for pointers !!! > ???? Could you explain more ? > > + cheap to implement: > > > > signal X, Y, Mask : std_ulogic_vector(63 downto 0); > > ... > > Mask <= ( > > 63 downto 32 => SIMD or U(2), > > 31 downto 16 => SIMD or U(1), > > 15 downto 8 => SIMD or U(0), > > others => '1' > > ); > > -- note that Mask is available from the decoder > > -- there's only an AND (or maybe MUX) inside the signal path > > Y <= X and Mask; > > that's where it hurts : it's in the critical datapath :-/ > > > > c) specify that the high part is sign-extended > > > (sign extension might create troubles like those of the > > > current solution > > + requires no partial writes > > + saves one instruction for sign extension > > - more complex than b) because there are multiple sign bits to > > consider > that's what i noted : not a good solution. > > > > d) specify that the SIMD flag has no effect at all and the > > > high part is updated with the rest of the word (just like a > > > normal SIMD operation would do) > > + all the world is SIMD :) > ... and "God is real, unless you declare it as a char" > (ok, it's not my invention, but it goes well along your remark :-D) > > > + requires no partial writes > > + even cheaper to implement than b) > sure... > > > - requires additional instruction for zero/sign extension > it's needed anyway (at least compiler writers will want one, > and people will be fed up to fiddle with arithmetic shifts etc...) > > don't you do one with your unit ? > > > > e) specify that the flag return an "undefined/reserved" behaviour > > > for the MSB (could be both dangerous and safe, it would force > > > compilers to generate valid pointers all the time) > > + even cheaper to implement than b) > > - worst solution ever > sure. > > > [...] > > e) will allow implementors to build F-CPUs that work like a), b), c), d), > > or any other way. > that's the obvious purpose (you seem to read in my mind ;-D) > > > As soon as those versions exist, programmers will use > > this particular `feature' (trust me - they *will*), > i know this, too. > > > and the resulting code will no longer be compatible between F-CPU versions. > > Therefore, we have to avoid e). > This was meant as a "temporary" version before the "F-CPU rev. 1" milestone. > Before that, compatibility is not ensured and binary compatibility will > not be enforced (because the opcodes won't be defined). > I think personnaly, that we shouldn't try to keep binary compatibility. > > Since I don't like a), > at least it won't disturb people who are used to non-RISC systems... > that's the behaviour i have seen on most existing multi-size computers > (68xx, 68K, inteloids etc...) > > > and c) is more expensive than b), > obviously. > > > and d) is what we have in SIMD mode, I prefer b). > b) is what first came to my mind but i soon realised that there are > other possibilities, so i wanted to explore them all. > > My sources and model implement a) but i did not choose between b) and f). > f) is closer to a) and b) shifts the problem from the register set to > the execution units. It's a tough decision and we have to consider a lot > of things, including future implementations... > > > On the other hand, turning SIMD on unconditionally *is* tempting. > :-) > didn't you propose that ?... or i misunderstood your request ? > > > It would free one flag and streamline the instruction set (the s- prefix > > will no longer be needed). That is, my second choice is d). > that's a radical cleanup, right :-) > > > What about f): keep the SIMD bit but make d) the default and b) optional > > behaviour. > you want to make a special case of e) ? > > > That is, when the SIMD flag is cleared, a `conforming' > > F-CPU must either mask the result or trigger an `invalid instruction' > > trap (this can be handled inside the decoder). From the design and > > specification point of view, this solution is much cleaner than e). > my intent for e) was to be completely ... open and as imprecise as possible > so your proposition is certainly more "orthodox". but that doesn't > solve the whole problem at all (the programs would spend their time > in the exception routines...) > > > I suggest we choose f) but make any reasonable effort to implement b). > i prefer "my" f) but b) has some problems to be solved... > > > Did you think about the new loadcons[p] I suggested? > ??? did i miss or forget something ? > can you explain and detail what you mean ? > > > On Mon, Jun 17, 2002 at 05:10:14AM +0200, Yann Guidon wrote: > > > Ben Franchuk wrote: > > > > Yann Guidon wrote: > > > > > > this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) > > > > > > f) avoid bypass if the size of the written register is different from > > > the required operand :-) > > > > Is that a variant of a), b), c) or d)? > no. > it's something completely different. > > the idea behind this is that in a), the bypass network has to choose between > more data and mix them into a single word (i gave examples). > > my idea was to not do the bypass (and thus avoid the complex mux management > in the critical datapath) when a chunk size change is detected. the first > instruction would continue to go through the write pipeline and the second > (which would usually trigger the bypass) would wait until the register set > performs the partial write itself. This keeps the complex muxes out of the > critical datapath, it solves one problem at the cost of some more latencies > from time to time in "micro$oft-like" codes. > Nice but there is still a pb on the zero flag. nicO > > Michael "Tired" Riepe > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > PS : for the good reason that i would like to rest a bit (and few > people would be able to decypher my attemps at being clear...), > i skipped the reasons why b) shifts the problem from the register set > to the main datapath. > > However, during a little pause, i got an interesting idea ! > > Here is the problem : For reasons that i don't have time to detail, > the "Xbar" is a bunch of wires that are routed over the execution > units to keep distances small and avoid the big "stuff" that can be > found on the usual FC0 diagrams. This uses one or two more metal layers > but the surface and the distance are reduced. > > To optimise the design, the usual execution units are all in line, but > one half of the units are flipped (in an odd/even fashion) so neighbouring > units can "share" the latches of the input or the output of the Xbar. > This organisation comes from some experiments i made on precaracterized > cells, and i remarked that the FF take one half of the surface, while > the execution unit is a very long strip. Sharing the FFs between neighbours > can save 25% of the surface/speed/consumption/price... > > The "Xbar" entity can be seen as divided into 3 components : > - Xbar_input latches the Xbar read and write lines, thus performing > the bypass, and gives the operand to the left and right-hand units. You really want to use "latches" ??? :( > - Xbar_output chooses between the left and right-hand unit's results > and "buffers" the result on the Xbar result autobahn. In order to > reduce wire lengths and reduce the need for high drives, an additional > MUX (at the output of the FF) will choose between the local FF > or the data that comes from the next Xbar_output. I have used this > technique once and it gives good results on hand-placed semicustom ASIC. > - Xbar_network connects the Register Set, all the Xbar_input and all the > Xbar_output's together. it can be considered as the part that is routed > on the high metal layers. > > This is pretty easy to design and control, because the result MUX is traightforward > and spread over the whole datapath. However, with a 64-bit design, these control > signal might be slow and heavy to operate. The "result MUX" requires long lines > and high drive. Adding another control signal that selects "0" at the MSB requires 2x > more drive and this is my problem :-/ > > One solution i propose for implementing b) is to "clear" the corresponding MSB > when the data is handed to the Xbar by the register set. Most instructions > (except ROP2 and INC with the "neg" and "not" operations) will return a 0 > result (0+0=0, etc.). So there is less need to modify the Xbar_output units > and less wires to spread. > > Do you understand the trick ? instead of clearing the MSB of the results > at the output of the EUs (it's important to do this because the result is > needed for bypass directly on the Xbar, and the partial write of the register > set will not be enough), the MSB is cleared when the operands are read > (less places where the MSB is cleared, so less control signals). > > With this trick, the Register set is super-simplified, but some more care > must be taken inside the datapath. > > I hope that this explanation is not too confusing... i gotta make some more > drawings but i can't do that now because my computers are broken... :-( > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jun 19 02:24:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KTZc-0006VM-00 for ; Wed, 19 Jun 2002 02:43:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 02:43:48 +0200 (CEST) Received: (qmail 3649 invoked by uid 0); 19 Jun 2002 00:16:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 19 Jun 2002 00:16:53 -0000 Received: by moria.seul.org (Postfix) id 13827146815; Tue, 18 Jun 2002 20:16:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4EE1146819; Tue, 18 Jun 2002 20:16:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 65950146815 for ; Tue, 18 Jun 2002 20:16:51 -0400 (EDT) Received: from f-cpu.org (kdl4-8.n.club-internet.fr [213.44.3.8]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 1BDDD1880 for ; Wed, 19 Jun 2002 02:16:48 +0200 (CEST) Message-ID: <3D0FCF46.1584D826@f-cpu.org> Date: Wed, 19 Jun 2002 02:24:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Late answer on " Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just ressurected it from my HDD... > This may come a little late in the design and development process, but... fortunately not :-) > I suggest we drop the `partial write' feature. it's what we discuss in the other thread. > In many cases, it makes > no sense to keep the upper part of a register when only a fraction of > it is written. E.g. when you load a byte from memory and want to use > it as a full-width integer (or boolean - remember that jmp/move always > look at the *whole* register), you either have to > > - `zero out' the destination register > - load the LSByte > > or > > - load the LSByte > - mask off any other bit > > Additionally, partial writes make the register set and the scoreboard > logic (zero detection) much more complex than necessary - in fact, it > makes some promising register set implementations almost impossible. The > only thing it makes easier is constant loading. In fact that is the *only* > operation that needs the partial write ability *at all*. Doesn't it? At the time when it was decided (3 years ago ? i don't remember), it seemed like a good idea... > Currently, we need 8 constant loading instructions: loadcons and loadconsx > with four variants each (in order to be able to load up to 256 bits - > if there will ever be an F-CPU with registers wider than 256 bits, we > will need *even more* instructions!). don't worry, with 512 bit registers, it's faster to "loadcons" the pointer to the immediate data, or do a shift ... > On the other hand, two slightly > different instructions would be sufficient for *all* word sizes: > > loadcons $imm17, reg // similar to the original `loadconsx' > => reg := sign_extend(imm17) > > loadconsp $imm16, reg // `p' means `partial' > => reg := shift_left(reg, 16) | imm16 > > Values between -65536 and 65535, inclusively, can be loaded with a > single instruction, 32-bit values need two instructions, and so on. > This solution is more general than the original loadcons[x] instructions > and IMHO also much more elegant. do you meant that you include the SHL in the pipeline ? in that case, "strings" of consecutive loadcons will have a terrific latency ! The purpose of the previous version was clearly to allow the programmer to issue 4 loadcons in 4 cycles, in a row. > Since we need 8 bits for the opcode and 6 bits for the destination > register, we can encode all variants using only a single opcode (compared > to 8 opcodes for loadcons[x]): given the relative usefulness of loadcons, allocating 8 opcodes is not completely unjustified. > 8 + 1 + 1 + 16 + 6 = 32 bits > +--------+---+---+-------+-----+ > | opcode | P | S | imm16 | reg | > +--------+---+---+-------+-----+ > > P=0 => load full register; S is the sign bit > P=1 => load least significant 16 bits of the register; S is ignored > > In case you didn't notice it: the same encoding is used by `loadaddri[d]'. thanks for the remark, but `loadaddri[d]' doesn't use SHL... > Implementing the new `loadcons' is simple: the decoder sign-extends the > immediate value and sends it along. `loadconsp' is a little more tricky > because it needs a `feedback loop' from one of the register set's read > ports to one of the write ports. Fortunately, the left shift and the > `or' operations take almost no time (we need an extra mux, the rest is > just a bunch of wires). I am more and more reluctant to perform shifts on the Xbar. I thought we could perform some bit-reversing there, for example, but in practice it's too difficult to manage. And how do you manage the bypasses ?... i don't want this to become yet another naughty hack. It is possible to operate on the immediates because the decode stage leaves enough time to amplify the signals (scalar, sign extension or SIMD modes), but later it becomes too difficult. > Without partial writes, other (non-SIMD) instructions that operate on > partial words shall set the upper bits of the result to zero (= simple > AND operation). Sign extension can either be performed by `move[s]' or > by a separate `sext' instruction; the `widen' instruction is no longer > necessary (it was an ugly kludge anyway). > > Ok, that had to be said. do you feel better, now ? :-)) > Now it's your turn... i don't want to use the "shift" approach. I don't know for the ALPHA, but even MIPS uses a specific instruction to load the MSB with a constant. The "relative" approach increases the dependencies between the operations, while the "absolute" way does not require an order. I remember that Cedric used loadcons optimisations to create a specific constant in his RC5 code... the "old" loadcons can still be done without partial writes, like you said, with another MUX in the CDP. ok. But remember that a shift requires a certain amount of Silicon surface, much more than a simple mux, and it depends on the number of wires to cross. My conclusion : partial writes are being abandonned but the "old" loadcons is still useful and easy to do. I don't even think that there will be a problem. It's just like a "move" instruction but with a modified datapath. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jun 19 02:24:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KTZd-0006VM-00 for ; Wed, 19 Jun 2002 02:43:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 02:43:49 +0200 (CEST) Received: (qmail 30389 invoked by uid 0); 19 Jun 2002 00:17:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 19 Jun 2002 00:17:00 -0000 Received: by moria.seul.org (Postfix) id 973BD14681E; Tue, 18 Jun 2002 20:16:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6985614681F; Tue, 18 Jun 2002 20:16:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 67FF214681E for ; Tue, 18 Jun 2002 20:16:57 -0400 (EDT) Received: from f-cpu.org (kdl4-8.n.club-internet.fr [213.44.3.8]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 2C0DA16A0 for ; Wed, 19 Jun 2002 02:16:51 +0200 (CEST) Message-ID: <3D0FCF48.585320F1@f-cpu.org> Date: Wed, 19 Jun 2002 02:24:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: More Alphabet Soup (was: [f-cpu] (!) a few noteworthy things) References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The Health Bureau says : "don't read this post unless you have a full bottle of aspirin next to you ! Now you are warned !". In case you don't understand this post, reread it several times. - - - - - - - - - - - 8<- - - - - - - - - - - - - - - - - - - - hi ! Michael Riepe wrote: > Hi! > > Unfortunately, on of my mails (concerning partial writes) seems to > have gone unnoticed... certainly my fault. my emails and computers are breaking up... so i better keep the old, working and rather stable NS4.51 that i use for years... > On Tue, Jun 18, 2002 at 02:36:23AM +0200, Yann Guidon wrote: > > Michael Riepe wrote: > > > - requires additional instructions for zero/sign extension > > Isn't SHL meant to do that ? > Or any other unit. The omega shifter can't do it; if we want it, we need > extra code. I don't think Omega is the best choice... When i find time, i'll try to program another strategy where the wire length is shorter in the Critical DataPath. Concerning the latency, it seems obvious that, past a certain point, it should be pipelined. Though i'm not sure whether all the control logic can keep up ... > > > > b) specify that the high part is cleared --> simpler solution > > > > > > + requires no partial writes > > > + saves on instruction for zero extension > > particularly important for pointers !!! > Maybe not for pointers (since they're always full size), but for pointer > arithmetics (add/subtract a small offset to/from a pointer, for example). that's more or less what i meant :-) > > > + cheap to implement: > > > signal X, Y, Mask : std_ulogic_vector(63 downto 0); > > > ... > > > Mask <= ( > > > 63 downto 32 => SIMD or U(2), > > > 31 downto 16 => SIMD or U(1), > > > 15 downto 8 => SIMD or U(0), > > > others => '1' > > > ); > > > -- note that Mask is available from the decoder > > > -- there's only an AND (or maybe MUX) inside the signal path > > > Y <= X and Mask; > > > > that's where it hurts : it's in the critical datapath :-/ > > If bypassed values don't have to be zero-extended (as in your f) proposal), > we can include it into the write ports of the register set. And it's only > a single AND (or MUX). that's what i explain later : the zero-extension can not happen at that level, but at (or before) the EU's outputs. We don't want to have to check whether the data granularity changes between two depending operations... and the bypassed value MUST be the same as what is written to the Register Set. > > > > c) specify that the high part is sign-extended > > > > (sign extension might create troubles like those of the > > > > current solution > > > + requires no partial writes > > > + saves one instruction for sign extension > > > - more complex than b) because there are multiple sign bits to > > > consider > > that's what i noted : not a good solution. > No, not at all. so let's just leave it alone... > > > > d) specify that the SIMD flag has no effect at all and the > > > > high part is updated with the rest of the word (just like a > > > > normal SIMD operation would do) > > > + all the world is SIMD :) > > ... and "God is real, unless you declare it as a char" > > (ok, it's not my invention, but it goes well along your remark :-D) > I guess it was `... unless declared integer'. There is no `char' in > Fortran (only character - but God probably lacks that ;). sorry, i am equiped with defect core memory... > > > - requires additional instruction for zero/sign extension > > it's needed anyway (at least compiler writers will want one, > > and people will be fed up to fiddle with arithmetic shifts etc...) > > don't you do one with your unit ? > Not yet. I've been looking for a better solution... there is one. It's a bit heavy but should scale correctly. i think i explained it on this list, several months ago... > > > > e) specify that the flag return an "undefined/reserved" behaviour > > > > for the MSB (could be both dangerous and safe, it would force > > > > compilers to generate valid pointers all the time) > > > + even cheaper to implement than b) > > > - worst solution ever > > sure. > > > [...] > > > e) will allow implementors to build F-CPUs that work like a), b), c), d), > > > or any other way. > > that's the obvious purpose (you seem to read in my mind ;-D) > .o( using Linux Telepathy Driver v0.0.1-alpha ) seems you can renumber it as v0.99-beta already. > > > As soon as those versions exist, programmers will use > > > this particular `feature' (trust me - they *will*), > > i know this, too. > > > > > and the resulting code will no longer be compatible between F-CPU versions. > > > Therefore, we have to avoid e). > > This was meant as a "temporary" version before the "F-CPU rev. 1" milestone. > > Before that, compatibility is not ensured and binary compatibility will > > not be enforced (because the opcodes won't be defined). > If the non-SIMD opcodes trigger a trap, your e) is almost my f). almost, except that e) is more "generic" and attemps to "not" specify, indeed. > > > Since I don't like a), > > at least it won't disturb people who are used to non-RISC systems... > > that's the behaviour i have seen on most existing multi-size computers > > (68xx, 68K, inteloids etc...) > And it sucks. there are some ways to work around that. but it's not "plain orthodox RISC", MIPS, ALPHA, SPARC and others seem to be more than happy with only one data size and the SIMD flag would seem useless to them, since usually they would use the 64-bit size by default (which is the same, SIMD flag or not, on a 64-bit machine). However, F-CPU can have more than 64 bits per register... thus, at least the size flags are absolutely necessary. > > > On the other hand, turning SIMD on unconditionally *is* tempting. > > :-) > > didn't you propose that ?... or i misunderstood your request ? > No, *you* did. I still want b), one way or another. i'll try to do b) since is is consistent with pointer arithmetics. I already have found a hack in yesterday's mail, so we'll probably use that anyway. > > > It would free one flag and streamline the instruction set (the s- prefix > > > will no longer be needed). That is, my second choice is d). > > that's a radical cleanup, right :-) > Tabula rasa (for those of you who don't understand latin: `clean table') it's very close to the french saying ;-) > is better than creeping featurism (SW people, are you listening?), At least a few are. Cedric warned me about d), which would be dangerous for SW people. that would be too complex to handle "cleanly" with compilers... but ... MAYBE..... MAYBE..... The SIMD flag could be turned into a "pointer" flag ??????? waddayouthink ? We would still use the b) approach with a bit of d) in the description, but the current SIMD flag could have an inverted meaning, and trigger TLB checks and the rest ?... It would be : * all "normal" operations are SIMD (you said "all the world is SIMD :)") and operand size would be managed as in RISC world * all pointers operations must have the flag reset so the result is zero-extended and the TLB is correctly checked (but then we need bits to indicate whether it's I or D) but i fear it's evenn more complex and confusing than before... for example, the 3 bits would have different meanings than today, we would need the following combinations : - instruction pointer - data pointer - SIMD 8/16/32/64/128/256 bits/chunk So there are some instructions that become useless on the memory side... argh. i wish i didn't have this idea. forget it. > especially if you have to deal with limited resources (like die space if you listen to nicO, you know it's not the biggest problem ;-P > or delay time). that's the critical point, which is more or less proportional to the surface... > I don't want the F-CPU to suffer from `galloping > elephantiasis' (or was it called `chronic Intelism'? ;) you named it. > > > What about f): keep the SIMD bit but make d) the default and b) optional > > > behaviour. > > you want to make a special case of e) ? > > Yes, but a *clean* one. There's a difference between saying: `the > behaviour is unspecified' and `these opcodes are reserved for a specific > purpose'. sure. one is a subset of the other ;-) > > > That is, when the SIMD flag is cleared, a `conforming' > > > F-CPU must either mask the result or trigger an `invalid instruction' > > > trap (this can be handled inside the decoder). From the design and > > > specification point of view, this solution is much cleaner than e). > > my intent for e) was to be completely ... open and as imprecise as possible > > so your proposition is certainly more "orthodox". but that doesn't > > solve the whole problem at all (the programs would spend their time > > in the exception routines...) > > > Programs are supposed to use SIMD operations whenever possible. By making > other variants much more expensive, we kind of force d) through the back > door, at least on the specification level :) > > > I know, this sounds like RMS in a Linux vs. GNU/Linux debate ;) no. it sounds rather logical, but not fair. Still, the problem of the pointer's definition is hurting us here. in my vision, a pointer is held in a whole register, whatever the size of both. a pointer has no defined size, just like the register. by not binding the pointer format to the existing data formats (char, int, long int...), it becomes difficult to do pointer arithmetics with "common" arithmetic operations. Just a note about multiple pointers : a register can contain ONLY ONE pointer, otherwise how would we handle jumps and load/stores ? another note : a scatter/gather instruction would be ideally performed using a "base" pointer (checked the usual way) and a SIMD "offset", so every SIMD offset chunk is parallelly checked against the maximum allowed offset (size of page in TLB ?) and the TLB doens't need as many ports as there are chunks... > > > I suggest we choose f) but make any reasonable effort to implement b). > > i prefer "my" f) but b) has some problems to be solved... > I guess we can combine your f) with a), b), c) or d) - or my f). now i understand why you renamed the subject to "Re: More Alphabet Soup " :-P The obvious goal of this thread is to SPECIFY how SIMD and scalar operations interact, so i would not be happy if at the end we say "ok, so let's leave it unspecified". This thread would then prove useless... b) is now my goal, for obvious architectural/design reasons, and i try to find simple solutions as well. You said you desired b) too and it looks like the most suitable solution (nobody yelled at b) yet). a) is the current approach but let's see how we can do b) and allow bypasses without exploding the control logic's surface... > > > Did you think about the new loadcons[p] I suggested? > > ??? did i miss or forget something ? > > can you explain and detail what you mean ? > See my mail from Wed, 5 Jun 2002 22:47:29 +0200. The subject was > "Partial Writes Considered Harmful". thanks for the references. Unfortunately, by the date, i see that it was "swallowed" during a Netscape 6 crash... scandisc did the rest. do you feel how desperate i am ??? i'll try to find it on the seul.org archives. ok, i found it on my HDD anyway, it was fortunately not wiped away definitely. it took minutes to find/scan, however. It was also burried in the "calling conventions" thread... I reply to this on another mail, for sake of readability. > > > On Mon, Jun 17, 2002 at 05:10:14AM +0200, Yann Guidon wrote: > > > > Ben Franchuk wrote: > > > > > Yann Guidon wrote: > > > > > > > > this is unrelated but you just gave me an idea for a 6th solution ("f)") :-) > > > > f) avoid bypass if the size of the written register is different from > > > > the required operand :-) > > > Is that a variant of a), b), c) or d)? > > no. > > it's something completely different. > They're almost orthogonal. it's an "enhancement" on a) but it's useless if b) works as expected. > > the idea behind this is that in a), the bypass network has to choose between > > more data and mix them into a single word (i gave examples). > > > > my idea was to not do the bypass (and thus avoid the complex mux management > > in the critical datapath) when a chunk size change is detected. the first > > instruction would continue to go through the write pipeline and the second > > (which would usually trigger the bypass) would wait until the register set > > performs the partial write itself. This keeps the complex muxes out of the > > critical datapath, it solves one problem at the cost of some more latencies > > from time to time in "micro$oft-like" codes. > > That can be done with any variant. probably but the goal is to make it useless. > When the chunk sizes don't match, > let the second instruction wait until the register set has performed > the write. Whether it's a partial write (a), a masked write (b) or a > sign-extended write (c) doesn't really matter. a "clean" bypass rule is necessary, however. if there are special rules, coding might get uselessly complex, too intel-like, like in P6 cores.... > BTW: if masking is done when the register is written, bypassing *is* > possible unless the second instruction has wider operands. my latest idea with b) is that "if" the masking is done at the EU output (and at the register set output as well, because it works for most operations :-D) then there is no need to check anything. the programming model is simplified and the behaviour is clearly determined. > > PS : for the good reason that i would like to rest a bit (and few > > people would be able to decypher my attemps at being clear...), > > i skipped the reasons why b) shifts the problem from the register set > > to the main datapath. > I'm aware of that anyway. But b) combined with your f) might be a good > solution. the point with the latest b) implementation details is that f) is useless. the scheduling rules are not changed because the masking is done (mostly) before the operation starts. > > However, during a little pause, i got an interesting idea ! > > > > Here is the problem : For reasons that i don't have time to detail, > > the "Xbar" is a bunch of wires that are routed over the execution > > units to keep distances small and avoid the big "stuff" that can be > > found on the usual FC0 diagrams. This uses one or two more metal layers > > but the surface and the distance are reduced. > > > > To optimise the design, the usual execution units are all in line, but > > one half of the units are flipped (in an odd/even fashion) so neighbouring > > units can "share" the latches of the input or the output of the Xbar. > > This organisation comes from some experiments i made on precaracterized > > cells, and i remarked that the FF take one half of the surface, while > > the execution unit is a very long strip. Sharing the FFs between neighbours > > can save 25% of the surface/speed/consumption/price... > > At the input of the EUs, at the output, or both? both. a FF gets or sends values to/from the Xbar on the higher metal levels, and collects or sends data in two opposite directions. In fact, this factors the HW, no need for individual FF for input and output of each EU. Here is a proposal/first picture : _______________________________________________________________________ read buses | _____|______________________|______________________|____________ | write buses || | | | | | | | R7 in-> INC ->out<- ROP2 <-in-> ASU ->out<- SHL <-in-> POPC ->out<- IDIV it's very incomplete, bypass and signal repeaters are not represented, but making graphic illustrations is almost impossible for me (unless you prefer i sent scanned pictures...) Note that due to its size, the IMUL is not inside the central datapath, and the IDIV can be put on one extremity (it is likely to be smaller than the IMUL unit). > Note that you may introduce EU dependencies that way. I don't see what you mean by "EU dependencies". The only scheduling problem i have seen so far is that it becomes difficult to "chain" EUs, for example chain the output of SHL to the input of ROP2. OTOH the gain is meaningful, both in die space and speed. -25% for the main pipeline (ROP2, INC, ASU, SHL, POPC) is something good. Removing one half of the FF from the Xbar's CDP is really worth it. > [...] > > One solution i propose for implementing b) is to "clear" the corresponding MSB > > when the data is handed to the Xbar by the register set. Most instructions > > (except ROP2 and INC with the "neg" and "not" operations) will return a 0 > > result (0+0=0, etc.). So there is less need to modify the Xbar_output units > > and less wires to spread. > > Another exception is the IDU (0/0 = ?). ooops. well, huh... then the EU output is explicitely cleared in that case, and this special case must be handled by the unit... > For other drawbacks, see A) below. > > > Do you understand the trick ? instead of clearing the MSB of the results > > at the output of the EUs (it's important to do this because the result is > > needed for bypass directly on the Xbar, and the partial write of the register > > set will not be enough), the MSB is cleared when the operands are read > > (less places where the MSB is cleared, so less control signals). > > There are at least four approaches (capital letters this time): you really like alphabet soup :-) However, note that all approaches can be combined in a way or another. > A) `early masking': mask off the high bits when the register is read > (before the instruction is issued). > > + masking moved to register set and less places where this must be done ---> less control logic and less long wires > - bypass impossible when first instruction has wider operands 1) hhhmmm ???... i'll have to check that. > - requires at least 3 masking units (one per register read port) i guess it's not the critical parameter and compared to others, it's even the simplest one. > - some instructions need special handling (complex!) which ? > 1) Surprise! You need to mask the operands of the second instruction > but there is no masking unit inside the bypass. if it's needed, we'll make it. > B) `write masking': mask off the high bits when the result is > written to the register. i think it was your first idea (or at least i understood that, and i later developped). > + masking moved to register set > + requires only 2 masking units (one per register write port) there is no big difference in practice, i guess. But the real difference is that 2 instructions can use the 2 write ports and they can use 2 different write sizes --> in practice, it's more complex than A) because A) needs 1 mask control logic, while B) needs 2. > - bypass impossible when second instruction has wider operands that's why i thought about moving it further down the pipeline... B+f is possible but not satisfying. there is certainly something better. > C) `late masking': store the chunk size in the register set (or > scoreboard) and mask off the high bits when the result is read from the > register (that is, before the *next* instruction that uses the value). > > + masking moved to register set > - bypass impossible when second instruction has wider operands > - requires at least 3 masking units (one per register read port) > - requires extra `valid' bits that indicate the chunk size where did that crazy idea come from ? ... can't we just trry to make something a kid can understand ?... > D) move the problem to the EUs. This can be done easily in the IMU, but > there's no room left inside the ASU, for example. SHL is pretty tight, > too (I already violate the `6 gate rule' there). then split SHL into 2 stages... given the long wires of you Omega network, it won't be useless... > + bypass always possible > - heavy implementation > - not all EUs support it i propose to let the Xbar "unit" perform a part of it. it can mask off the MSB when it reads the register operands. If the EU can't do it, then Xbar masks the EU output locally. > E/F/G anyone? ;) > > If we can add a masking unit inside the bypass, ABC) will always be able > to bypass results. But even if we can't, B) looks like the best solution > so far. not really because it still has problems with bypass (detecting special conditions). Don't forget that without bypass capability, FC0 will be ... unacceptably slow. wow. i think we can already start to modify the manual to reflect these new specifications. the R7 VHDL source will become simpler, and i have a better view of the Xbar and scheduler architecture. Ain't it great ?... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jun 19 02:24:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KTZg-0006VM-00 for ; Wed, 19 Jun 2002 02:43:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 02:43:52 +0200 (CEST) Received: (qmail 19843 invoked by uid 0); 19 Jun 2002 00:17:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 19 Jun 2002 00:17:06 -0000 Received: by moria.seul.org (Postfix) id DDEAF14681A; Tue, 18 Jun 2002 20:17:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5400146828; Tue, 18 Jun 2002 20:17:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9476414681A for ; Tue, 18 Jun 2002 20:17:05 -0400 (EDT) Received: from f-cpu.org (kdl4-8.n.club-internet.fr [213.44.3.8]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 278A1168E for ; Wed, 19 Jun 2002 02:17:02 +0200 (CEST) Message-ID: <3D0FCF55.EB6ED8C3@f-cpu.org> Date: Wed, 19 Jun 2002 02:24:53 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (!) a few noteworthy things References: <37D1208A1C9BD511855B00D0B772242C0118AD76@corpmail1.sc.sonicblue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, John Graley wrote: > > then on bypass the new value will be > > a) 0xFEDCBA98765432EF (there must be another MUX to select > > between the old > > and new value) > > b) 0x00000000000000EF > > c) 0xFFFFFFFFFFFFFFEF > > d) 0x0123456789ABCDEF > > e) 0x??????????????EF > > Assuming you can use 8-bit SIMD instructions on data of the form > 0x??????????????xy in order to obtain correct results for the bottom > 8 bits, neglecting the other bits, then you should use option e. that's why i proposed it and it's the usual behaviour in most algorithms. > This is only inadequate in places where the program is converting a short > data type to a longer type (when you need b for unsigned and c for signed), > and this occurs fairly infrequently in program code, so it would be wasteful > to do it every time. sign extension is often used by compilers and they handle that well, at least with the usual platforms. it seems however that sign extension is not yet provided by FC0's execution units. > Instead you should have explicit cast instructions for b and c. this operation is pretty straight-forward to perform and hardwire, but it's not clear whether Michael's SHL can do it easily. At least we should define its behaviour in the instruction set part of the manual. regards, > Cheers, John WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 19 17:11:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KjOa-0000Fg-00 for ; Wed, 19 Jun 2002 19:37:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 19:37:28 +0200 (CEST) Received: (qmail 32633 invoked by uid 0); 19 Jun 2002 16:04:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 19 Jun 2002 16:04:53 -0000 Received: by moria.seul.org (Postfix) id 9045A146859; Wed, 19 Jun 2002 12:04:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73CD6146916; Wed, 19 Jun 2002 12:04:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id 15FAA146859 for ; Wed, 19 Jun 2002 12:04:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00969; Wed, 19 Jun 2002 17:11:14 +0200 Message-ID: <20020619171114.04784@thrai.stud.uni-hannover.de> Date: Wed, 19 Jun 2002 17:11:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: More Alphabet Soup (was: [f-cpu] (!) a few noteworthy things) References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0FCF48.585320F1@f-cpu.org>; from Yann Guidon on Wed, Jun 19, 2002 at 02:24:40AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 19, 2002 at 02:24:40AM +0200, Yann Guidon wrote: > The Health Bureau says : "don't read this post unless you have > a full bottle of aspirin next to you ! Now you are warned !". *broad evil grin* :) [...] > > > > - requires additional instructions for zero/sign extension > > > Isn't SHL meant to do that ? > > Or any other unit. The omega shifter can't do it; if we want it, we need > > extra code. > > I don't think Omega is the best choice... When i find time, i'll try > to program another strategy where the wire length is shorter in the > Critical DataPath. If you can find one where wire length doesn't explode in the later stages... The nicest property of the omega net ist that all stages are equal (except the control logic). > Concerning the latency, it seems obvious that, past a certain point, > it should be pipelined. Though i'm not sure whether all the control logic > can keep up ... A pipelined SHL would be more difficult to write but should be possible. But please let's keep the 1-stage version for now. [...] > > If bypassed values don't have to be zero-extended (as in your f) proposal), > > we can include it into the write ports of the register set. And it's only > > a single AND (or MUX). > that's what i explain later : the zero-extension can not happen at that level, > but at (or before) the EU's outputs. We don't want to have to check whether the data > granularity changes between two depending operations... and the bypassed value > MUST be the same as what is written to the Register Set. The bypassed value need NOT be the same. Only the valid part must be identical, the rest is a `don't care'. If it's not masked in the bypass, it will be masked after the second instruction (given that the second instruction does not use bigger chunks). The granularity check isn't hard to do. Let U1 and U2 be the decoded `size vectors' (that is, "000", "001", "011" or "111") and SIMD1 and SIMD2 be the SIMD flags of the first and second instruction, respectively, then bypassing without masking is permitted if not (U1 or (2 downto 0 => SIMD1)) and (U2 or (2 downto 0 => SIMD2)) = "000" It's MUCH harder to check for the case whether a bypass is appropriate at all (compare register numbers and so on)! [...] > MAYBE..... > > The SIMD flag could be turned into a "pointer" flag ??????? > > waddayouthink ? > > We would still use the b) approach with a bit of d) in the description, > but the current SIMD flag could have an inverted meaning, and trigger > TLB checks and the rest ?... > > It would be : > * all "normal" operations are SIMD (you said "all the world is SIMD :)") > and operand size would be managed as in RISC world > * all pointers operations must have the flag reset so the result is zero-extended > and the TLB is correctly checked (but then we need bits to indicate whether > it's I or D) I guess we can limit ourselves to data pointers. But there's another problem: consider a two-dimensional array `int a[5][9]'. The address of the element `a[y][x]' is calculated as `a + sizeof(int) * (9 * y + x)', that is // let r1 = a, r2 = x, r3 = y muli 9, r3, r4 add r2, r4, r5 muli INTSIZE, r5, r6 // actually, this will be a shift add r1, r6, r1 Do you want ALL those results to be pointers that trigger a prefetch? What about r4/r5/r6 which do not point to memory but are just integers? > but i fear it's evenn more complex and confusing than before... Yep, and it has severe semantic problems. > for example, the 3 bits would have different meanings than today, we would need > the following combinations : > - instruction pointer > - data pointer > - SIMD 8/16/32/64/128/256 bits/chunk > > So there are some instructions that become useless on the memory side... > argh. i wish i didn't have this idea. > forget it. Ok. It's better that way. [...] > in my vision, a pointer is held in a whole register, whatever the size > of both. a pointer has no defined size, just like the register. Yep. In practice, the number of valid bits in a pointer will be determined by the hardware (number of address lines) and/or the operating system (TLB miss handler). > by not binding the pointer format to the existing data formats > (char, int, long int...), it becomes difficult to do pointer arithmetics > with "common" arithmetic operations. The answer is, of course: use SIMD mode with maximum chunk size. Since it is identical to non-SIMD mode with the same chunk size... > Just a note about multiple pointers : a register can contain > ONLY ONE pointer, otherwise how would we handle jumps and load/stores ? Yep. > another note : > a scatter/gather instruction would be ideally performed using a "base" > pointer (checked the usual way) and a SIMD "offset", so every SIMD offset > chunk is parallelly checked against the maximum allowed offset (size of page > in TLB ?) and the TLB doens't need as many ports as there are chunks... Sounds good. Especially if we require the base pointer to be page aligned :) > > > > I suggest we choose f) but make any reasonable effort to implement b). > > > i prefer "my" f) but b) has some problems to be solved... > > I guess we can combine your f) with a), b), c) or d) - or my f). > now i understand why you renamed the subject to "Re: More Alphabet Soup " :-P *evil grin* again :) [...port sharing between EUs...] > > Note that you may introduce EU dependencies that way. > I don't see what you mean by "EU dependencies". If two EUs share a port, you can use only one of them at a time. This currently doesn't matter for input ports (because we build a 1-issue CPU) but is important for output ports - results MUST NOT arrive at the same time, and the scheduler will have to take care of that. Yet another special case to handle... [...] > > Another exception is the IDU (0/0 = ?). > ooops. well, huh... then the EU output is explicitely cleared in that case, > and this special case must be handled by the unit... Ok. I suppose the IDU won't crash and burn when the divisor is zero; it just will produce meaningless results (which will be masked). > > For other drawbacks, see A) below. > > > > > Do you understand the trick ? instead of clearing the MSB of the results > > > at the output of the EUs (it's important to do this because the result is > > > needed for bypass directly on the Xbar, and the partial write of the register > > > set will not be enough), the MSB is cleared when the operands are read > > > (less places where the MSB is cleared, so less control signals). > > > > There are at least four approaches (capital letters this time): > you really like alphabet soup :-) > > However, note that all approaches can be combined in a way or another. > > > A) `early masking': mask off the high bits when the register is read > > (before the instruction is issued). > > > > + masking moved to register set > and less places where this must be done ---> less control logic and less long wires > > > - bypass impossible when first instruction has wider operands 1) > hhhmmm ???... i'll have to check that. > > > - requires at least 3 masking units (one per register read port) > i guess it's not the critical parameter and compared to others, it's even the > simplest one. > > > - some instructions need special handling (complex!) > which ? You already mentioned them - ROP2 (xnor, orn), INC - and IDU. > > 1) Surprise! You need to mask the operands of the second instruction > > but there is no masking unit inside the bypass. > if it's needed, we'll make it. If we put masks into the bypass and the register write ports, the whole discussion is closed. With that, we can always bypass, and we can always zero-extend. > > B) `write masking': mask off the high bits when the result is > > written to the register. > i think it was your first idea (or at least i understood that, > and i later developped). Right. > > + masking moved to register set > > + requires only 2 masking units (one per register write port) > there is no big difference in practice, i guess. > > But the real difference is that 2 instructions can use the 2 write ports > and they can use 2 different write sizes --> in practice, it's more > complex than A) because A) needs 1 mask control logic, while B) needs 2. I suppose that every masking unit has its own decoder logic anyway, in order to reduce the number of wires. You only send the SIMD and U bits to it, and the rest is done in place. > > - bypass impossible when second instruction has wider operands > that's why i thought about moving it further down the pipeline... > > B+f is possible but not satisfying. there is certainly something better. B+b, with an optional masking unit inside the bypass :) > > C) `late masking': store the chunk size in the register set (or > > scoreboard) and mask off the high bits when the result is read from the > > register (that is, before the *next* instruction that uses the value). > > > > + masking moved to register set > > - bypass impossible when second instruction has wider operands > > - requires at least 3 masking units (one per register read port) > > - requires extra `valid' bits that indicate the chunk size > > where did that crazy idea come from ? ... Um. Hmm. Where did... outta my crazy head? ;) > can't we just trry to make something a kid can understand ?... Ok, let's build a Turing machine ;) > > D) move the problem to the EUs. This can be done easily in the IMU, but > > there's no room left inside the ASU, for example. SHL is pretty tight, > > too (I already violate the `6 gate rule' there). > then split SHL into 2 stages... given the long wires of you Omega network, > it won't be useless... > > > + bypass always possible > > - heavy implementation > > - not all EUs support it > > i propose to let the Xbar "unit" perform a part of it. > it can mask off the MSB when it reads the register operands. > If the EU can't do it, then Xbar masks the EU output locally. I thought you wanted to reduce the complexity of the Xbar? > > E/F/G anyone? ;) > > > > If we can add a masking unit inside the bypass, ABC) will always be able > > to bypass results. But even if we can't, B) looks like the best solution > > so far. > > not really because it still has problems with bypass (detecting special conditions). > Don't forget that without bypass capability, FC0 will be ... unacceptably slow. If you want maximum speed, always use full words (with or without SIMD). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jun 19 15:47:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KjOc-0000Fg-00 for ; Wed, 19 Jun 2002 19:37:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 19:37:30 +0200 (CEST) Received: (qmail 20176 invoked by uid 0); 19 Jun 2002 16:05:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 19 Jun 2002 16:05:00 -0000 Received: by moria.seul.org (Postfix) id 11CFE146916; Wed, 19 Jun 2002 12:04:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0066514691A; Wed, 19 Jun 2002 12:04:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id D9793146916 for ; Wed, 19 Jun 2002 12:04:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00776; Wed, 19 Jun 2002 15:47:18 +0200 Message-ID: <20020619154718.58467@thrai.stud.uni-hannover.de> Date: Wed, 19 Jun 2002 15:47:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer on " References: <3D0FCF46.1584D826@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D0FCF46.1584D826@f-cpu.org>; from Yann Guidon on Wed, Jun 19, 2002 at 02:24:38AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jun 19, 2002 at 02:24:38AM +0200, Yann Guidon wrote: [...] > > On the other hand, two slightly > > different instructions would be sufficient for *all* word sizes: > > > > loadcons $imm17, reg // similar to the original `loadconsx' > > => reg := sign_extend(imm17) > > > > loadconsp $imm16, reg // `p' means `partial' > > => reg := shift_left(reg, 16) | imm16 > > > > Values between -65536 and 65535, inclusively, can be loaded with a > > single instruction, 32-bit values need two instructions, and so on. > > This solution is more general than the original loadcons[x] instructions > > and IMHO also much more elegant. > > do you meant that you include the SHL in the pipeline ? Heck no! It's just a hardwired 16-bit left shift: if LOADCONSP = '1' then Register_In(63 downto 16) <= Register_Out(47 downto 0); Register_In(15 downto 0) <= Data_from_Xbar(15 downto 0); else Register_In <= Data_from_Xbar; end if; BTW: If you use a 3-way MUX, you can also do zero extension. Add another input and you can choose between old loadcons, new loadcons, zero extension and `straight-through' mode. Fact is that you *will* need a MUX for both variants if we abandon partial writes. > in that case, "strings" of consecutive loadcons will have a terrific > latency ! The purpose of the previous version was clearly to allow > the programmer to issue 4 loadcons in 4 cycles, in a row. That should be possible. > > Since we need 8 bits for the opcode and 6 bits for the destination > > register, we can encode all variants using only a single opcode (compared > > to 8 opcodes for loadcons[x]): > given the relative usefulness of loadcons, allocating 8 opcodes is not > completely unjustified. IMHO it is. > > 8 + 1 + 1 + 16 + 6 = 32 bits > > +--------+---+---+-------+-----+ > > | opcode | P | S | imm16 | reg | > > +--------+---+---+-------+-----+ > > > > P=0 => load full register; S is the sign bit > > P=1 => load least significant 16 bits of the register; S is ignored > > > > In case you didn't notice it: the same encoding is used by `loadaddri[d]'. > thanks for the remark, but `loadaddri[d]' doesn't use SHL... Neither does loadconsp :P > > Implementing the new `loadcons' is simple: the decoder sign-extends the > > immediate value and sends it along. `loadconsp' is a little more tricky > > because it needs a `feedback loop' from one of the register set's read > > ports to one of the write ports. Fortunately, the left shift and the > > `or' operations take almost no time (we need an extra mux, the rest is > > just a bunch of wires). > > I am more and more reluctant to perform shifts on the Xbar. > I thought we could perform some bit-reversing there, for example, > but in practice it's too difficult to manage. And how do you > manage the bypasses ?... i don't want this to become yet > another naughty hack. Why bypasses? Constants are supposed to go into the register set directly, aren't they? If the loadcons[p] instructions are always issued in-order, there is another way to implement them: add an `accumulator' register to the instruction decoder. That is, a load will look like this: loadcons 0x7777, r0 // acc = 0x0000000000007777; // maybe do something else here loadconsp 0x33bb, r0 // acc = 0x00000000777733bb; // maybe do something else here loadconsp 0x1919, r42 // acc = 0x0000777733bb1919; r42 = acc; Note that destination register `r0' is used as a synonym for `accumulate but do not write'. + less pressure on the register set (ports remain free) + feedback loop is local, not wrapped around the register set + less timing critical! + can be interleaved with other instructions (except loadcons) - disables well-known loadcons tricks (but probably enables others) If the value is used immediately after the load, it can also be sent to the EU directly while the value is moved to the destination register. That is, the sequence loadcons 0x12, r1 mul r1, r2, r3 will take only one cycle longer than muli 0x12, r2, r3 while it allows bigger (17-bit) constants. [...] > i don't want to use the "shift" approach. I don't know for the ALPHA, > but even MIPS uses a specific instruction to load the MSB with a constant. SPARC as well (but they split the register after 22 bits). > The "relative" approach increases the dependencies between the operations, > while the "absolute" way does not require an order. I remember that Cedric > used loadcons optimisations to create a specific constant in his RC5 code... > > the "old" loadcons can still be done without partial writes, like you > said, with another MUX in the CDP. ok. > But remember that a shift requires a certain amount of Silicon surface, > much more than a simple mux, and it depends on the number of wires to cross. Since it's not really a shift, it requires a 48-bit MUX, 48 wires and 1 control line. A normal (unshifted) feedback, as needed for the old loadcons, requires four 16-bit MUXes, 64 wires and 4 control lines. Not a big difference (and my version is actually cheaper). > My conclusion : partial writes are being abandonned but > the "old" loadcons is still useful and easy to do. > I don't even think that there will be a problem. > It's just like a "move" instruction but with a modified > datapath. I guess I should be satisfied, but I'm not :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jun 19 18:10:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KjOd-0000Fg-00 for ; Wed, 19 Jun 2002 19:37:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 19 Jun 2002 19:37:31 +0200 (CEST) Received: (qmail 26317 invoked by uid 0); 19 Jun 2002 16:13:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Jun 2002 16:13:30 -0000 Received: by moria.seul.org (Postfix) id B71BE146917; Wed, 19 Jun 2002 12:13:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9F07914691B; Wed, 19 Jun 2002 12:13:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 43032146917 for ; Wed, 19 Jun 2002 12:13:28 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-217.jetnet.ab.ca [207.34.60.217]) by bach.ccinet.ab.ca (8.12.3/8.12.3) with ESMTP id g5JGDpNI029281 for ; Wed, 19 Jun 2002 10:13:52 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D10ACFD.9E0DD64A@jetnet.ab.ca> Date: Wed, 19 Jun 2002 10:10:37 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] More broth in the Alphabet Soup References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> <20020619171114.04784@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > Just a note about multiple pointers : a register can contain > > ONLY ONE pointer, otherwise how would we handle jumps and load/stores ? > > Yep. > > > another note : > > a scatter/gather instruction would be ideally performed using a "base" > > pointer (checked the usual way) and a SIMD "offset", so every SIMD offset > > chunk is parallelly checked against the maximum allowed offset (size of page > > in TLB ?) and the TLB doens't need as many ports as there are chunks... > > Sounds good. Especially if we require the base pointer to be page > aligned :) > What about dumb things like video displays that have multiple byte sizes? Here your gather would need to be for bytes,words,and longs on a long boundry. Also what about list languages that often use the upper bits of a address for garbage colection and pointer types? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 20 00:15:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17KoWW-0002y5-01 for ; Thu, 20 Jun 2002 01:06:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Jun 2002 01:06:00 +0200 (CEST) Received: (qmail 11926 invoked by uid 0); 19 Jun 2002 22:08:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 19 Jun 2002 22:08:08 -0000 Received: by moria.seul.org (Postfix) id 5DB27146810; Wed, 19 Jun 2002 18:08:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29EE1146844; Wed, 19 Jun 2002 18:08:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id CAB36146810 for ; Wed, 19 Jun 2002 18:08:05 -0400 (EDT) Received: from f-cpu.org (kdl11-25.n.club-internet.fr [213.44.9.25]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 2A9A01754 for ; Thu, 20 Jun 2002 00:08:03 +0200 (CEST) Message-ID: <3D11029A.F9B1F6EA@f-cpu.org> Date: Thu, 20 Jun 2002 00:15:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] More broth in the Alphabet Soup References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> <20020619171114.04784@thrai.stud.uni-hannover.de> <3D10ACFD.9E0DD64A@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Ben Franchuk wrote: > Michael Riepe wrote: > > > Just a note about multiple pointers : a register can contain > > > ONLY ONE pointer, otherwise how would we handle jumps and load/stores ? > > Yep. > > > > > another note : > > > a scatter/gather instruction would be ideally performed using a "base" > > > pointer (checked the usual way) and a SIMD "offset", so every SIMD offset > > > chunk is parallelly checked against the maximum allowed offset (size of page > > > in TLB ?) and the TLB doens't need as many ports as there are chunks... > > > > Sounds good. Especially if we require the base pointer to be page > > aligned :) > > > What about dumb things like video displays that have multiple byte sizes? > Here your gather would need to be for bytes,words,and longs on a long boundry. hmm i see, that's the offset size problem... if you need to access more than 64K 16-bit words, then you can mask off the LSB and perform more 32-bit accesses. The results are shifted/masked to return the wanted part. scatter/gather is not going to be implemented on FC0 but it's not too late to speak about it... though by nature, it's going to trigger a lot of cache misses and it's not adapted to FC0 at all... > Also what about list languages that often use the upper bits of a > address for garbage colection and pointer types? then a simple ANDN instruction will mask off those bits before they are used... no ? > Ben Franchuk - Dawn * 12/24 bit cpu * WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 20 04:32:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Kss1-0006I9-00 for ; Thu, 20 Jun 2002 05:44:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Jun 2002 05:44:29 +0200 (CEST) Received: (qmail 23603 invoked by uid 0); 20 Jun 2002 02:24:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 20 Jun 2002 02:24:36 -0000 Received: by moria.seul.org (Postfix) id 25860146820; Wed, 19 Jun 2002 22:24:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0434C14691B; Wed, 19 Jun 2002 22:24:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 828F8146820 for ; Wed, 19 Jun 2002 22:24:34 -0400 (EDT) Received: from f-cpu.org (kdl11-2.n.club-internet.fr [213.44.9.2]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 12E4616B9 for ; Thu, 20 Jun 2002 04:23:49 +0200 (CEST) Message-ID: <3D113EB5.FAC945FC@f-cpu.org> Date: Thu, 20 Jun 2002 04:32:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: More Alphabet Soup (was: [f-cpu] (!) a few noteworthy things) References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> <20020619171114.04784@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Again, i don't know how long it will take to me to write this, and to you to read this... Anyway, don't be afraid... or we'll never do anything at all... Michael Riepe wrote: > On Wed, Jun 19, 2002 at 02:24:40AM +0200, Yann Guidon wrote: > > The Health Bureau says : "don't read this post unless you have > > a full bottle of aspirin next to you ! Now you are warned !". > *broad evil grin* :) i guess i scared a lot of people with that ... > [...] > > > > > - requires additional instructions for zero/sign extension > > > > Isn't SHL meant to do that ? > > > Or any other unit. The omega shifter can't do it; if we want it, we need > > > extra code. > > I don't think Omega is the best choice... When i find time, i'll try > > to program another strategy where the wire length is shorter in the > > Critical DataPath. > If you can find one where wire length doesn't explode in the later stages... if you include that in your construction rules, this will be ok. My "design rule" says to not cross more than 16 wires per shift... > The nicest property of the omega net ist that all stages are equal > (except the control logic). Omega can do cut & paste and thus, all paths are equal. However it is suboptimal because the paths are 2x longer than the optimal path. In the construction i want to use, there is a first stage made of 2 layers of 4-mux, followed by a 2nd stage made of 3 layers of 3-mux. The first stage does shifts up to 16 bits in either directions, the second stage just handles the "long wires" and performs shifts of +1, 0 and -1 block of 16 wires. > > Concerning the latency, it seems obvious that, past a certain point, > > it should be pipelined. Though i'm not sure whether all the control logic > > can keep up ... > A pipelined SHL would be more difficult to write but should be > possible. But please let's keep the 1-stage version for now. is there any reason not to ? > [...] > > > If bypassed values don't have to be zero-extended (as in your f) proposal), > > > we can include it into the write ports of the register set. And it's only > > > a single AND (or MUX). > > that's what i explain later : the zero-extension can not happen at that level, > > but at (or before) the EU's outputs. We don't want to have to check whether the data > > granularity changes between two depending operations... and the bypassed value > > MUST be the same as what is written to the Register Set. > > The bypassed value need NOT be the same. Only the valid part must be > identical, the rest is a `don't care'. If it's not masked in the bypass, > it will be masked after the second instruction (given that the second > instruction does not use bigger chunks). ok but it's only one half of the problem. when the chuncks are bigger, it's another story... > The granularity check isn't hard to do. Let U1 and U2 be the decoded > `size vectors' (that is, "000", "001", "011" or "111") and SIMD1 and > SIMD2 be the SIMD flags of the first and second instruction, respectively, > then bypassing without masking is permitted if > > not (U1 or (2 downto 0 => SIMD1)) > and (U2 or (2 downto 0 => SIMD2)) = "000" > > It's MUCH harder to check for the case whether a bypass is appropriate > at all (compare register numbers and so on)! ok, we can check whether there is a size change. and then ? the "simple solution is to "hold/stall" the decode pipeline, but this thought is not funny... > [...] > > MAYBE..... > > > > The SIMD flag could be turned into a "pointer" flag ??????? > > but i fear it's evenn more complex and confusing than before... > Yep, and it has severe semantic problems. > > > So there are some instructions that become useless on the memory side... > > argh. i wish i didn't have this idea. > > forget it. > > Ok. It's better that way. pffffiuuh.... ideas are difficult to control... > [...] > > in my vision, a pointer is held in a whole register, whatever the size > > of both. a pointer has no defined size, just like the register. > > Yep. In practice, the number of valid bits in a pointer will be > determined by the hardware (number of address lines) and/or the > operating system (TLB miss handler). This should be written in the manual... > > by not binding the pointer format to the existing data formats > > (char, int, long int...), it becomes difficult to do pointer arithmetics > > with "common" arithmetic operations. > The answer is, of course: use SIMD mode with maximum chunk size. Since > it is identical to non-SIMD mode with the same chunk size... no, because all F-CPUs are not 64-bit wide... > [...port sharing between EUs...] > > > Note that you may introduce EU dependencies that way. > > I don't see what you mean by "EU dependencies". > If two EUs share a port, you can use only one of them at a time. This > currently doesn't matter for input ports (because we build a 1-issue CPU) > but is important for output ports - results MUST NOT arrive at the same > time, and the scheduler will have to take care of that. Yet another > special case to handle... i went to a japanese restaurant today and made a few drawings on my papers... ===> it's not a problem. One parameter is that we can group units that have the same latency : the current ROP2 and INC units are rather similar and can share the same "output" port, which can be further simplified. This one needs however to support the write to either R7's write port (if a preceding ASU operation was started, for example, ROP2/INC has to use the alternate write port). Another problem arises, however : i've been very laxist about the "variable latency" of the units, such as additional/optional pipe stages for some units. putting a non-shareable "output" in the middle of some units might be difficult in practice. we'll probably have to abandon the idea of min/max/sort/etc. in the INC unit, as well as 16-bit and 32-bit combination in ROP2, and the 8-bit 1-cycle latency of the ASU. The other good side is that the latency decoder is simplified... > [...] > > > Another exception is the IDU (0/0 = ?). > > ooops. well, huh... then the EU output is explicitely cleared in that case, > > and this special case must be handled by the unit... > > Ok. I suppose the IDU won't crash and burn when the divisor is zero; > it just will produce meaningless results (which will be masked). let's hope so and specify it now ;-P > > > For other drawbacks, see A) below. > > > > > > > Do you understand the trick ? instead of clearing the MSB of the results > > > > at the output of the EUs (it's important to do this because the result is > > > > needed for bypass directly on the Xbar, and the partial write of the register > > > > set will not be enough), the MSB is cleared when the operands are read > > > > (less places where the MSB is cleared, so less control signals). > > > > > > There are at least four approaches (capital letters this time): > > you really like alphabet soup :-) > > > > However, note that all approaches can be combined in a way or another. > > > > > A) `early masking': mask off the high bits when the register is read > > > (before the instruction is issued). > > > > > > + masking moved to register set > > and less places where this must be done ---> less control logic and less long wires > > > > > - bypass impossible when first instruction has wider operands 1) > > hhhmmm ???... i'll have to check that. > > > > > - requires at least 3 masking units (one per register read port) > > i guess it's not the critical parameter and compared to others, it's even the > > simplest one. > > > > > - some instructions need special handling (complex!) > > which ? > > You already mentioned them - ROP2 (xnor, orn), INC - and IDU. is SHL safe ? then, MSB clearing is performed on the R7 read ports and on the "output" port shared by INC and ROP2 (add to that that they have the same latency, and you understand why they are grouped together ;-) > > > 1) Surprise! You need to mask the operands of the second instruction > > > but there is no masking unit inside the bypass. > > if it's needed, we'll make it. > > If we put masks into the bypass and the register write ports, the > whole discussion is closed. With that, we can always bypass, and we > can always zero-extend. According to my remark above, masking at 2 locations only is possible. no scheduling trick, i guess it's the best i can do. > > > B) `write masking': mask off the high bits when the result is > > > written to the register. > > i think it was your first idea (or at least i understood that, > > and i later developped). > Right. working with you is such a pleasure, dear colleague :-) > > > + masking moved to register set > > > + requires only 2 masking units (one per register write port) > > there is no big difference in practice, i guess. > > > > But the real difference is that 2 instructions can use the 2 write ports > > and they can use 2 different write sizes --> in practice, it's more > > complex than A) because A) needs 1 mask control logic, while B) needs 2. > > I suppose that every masking unit has its own decoder logic anyway, > in order to reduce the number of wires. You only send the SIMD and U > bits to it, and the rest is done in place. if you can do it only once (as on the read port), it certainly is easier to understand and implement :-) > > > - bypass impossible when second instruction has wider operands > > that's why i thought about moving it further down the pipeline... > > B+f is possible but not satisfying. there is certainly something better. > B+b, with an optional masking unit inside the bypass :) i choose A+optional masking at some EU output :-) > > > C) `late masking': store the chunk size in the register set (or > > > scoreboard) and mask off the high bits when the result is read from the > > > register (that is, before the *next* instruction that uses the value). > > > + masking moved to register set > > > - bypass impossible when second instruction has wider operands ouch. > > > - requires at least 3 masking units (one per register read port) > > > - requires extra `valid' bits that indicate the chunk size ouch^3 !!! > > where did that crazy idea come from ? ... > Um. Hmm. Where did... outta my crazy head? ;) ohgottohgottohgott ! > > can't we just trry to make something a kid can understand ?... > Ok, let's build a Turing machine ;) can this run a Linux kernel ? :-P > > > D) move the problem to the EUs. This can be done easily in the IMU, but > > > there's no room left inside the ASU, for example. SHL is pretty tight, > > > too (I already violate the `6 gate rule' there). > > then split SHL into 2 stages... given the long wires of you Omega network, > > it won't be useless... > > > > > + bypass always possible > > > - heavy implementation > > > - not all EUs support it > > i propose to let the Xbar "unit" perform a part of it. > > it can mask off the MSB when it reads the register operands. > > If the EU can't do it, then Xbar masks the EU output locally. > I thought you wanted to reduce the complexity of the Xbar? i think i have come to a pretty simple implementation and masking can be perfomed at 2 locations (R7 output and INC/ROP2 Xbar tap). > > > E/F/G anyone? ;) > > > > > > If we can add a masking unit inside the bypass, ABC) will always be able > > > to bypass results. But even if we can't, B) looks like the best solution > > > so far. > > > > not really because it still has problems with bypass (detecting special conditions). > > Don't forget that without bypass capability, FC0 will be ... unacceptably slow. > > If you want maximum speed, always use full words (with or without SIMD). sure. but it makes the coding rules more complex. as of today, there is one main restriction : the stall/delay between two dependent instructions is only this of the used execution unit. If we make it more complex, optimisation rules will become too complex. FC0 can already be programmed/seen/optimised like a 2-way or 3-way superscalar RISC machine, that's already enough. ok, let's continue this thread on the other mail ;-D > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jun 20 05:52:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Kv1P-0007wc-00 for ; Thu, 20 Jun 2002 08:02:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Jun 2002 08:02:19 +0200 (CEST) Received: (qmail 9790 invoked by uid 0); 20 Jun 2002 03:44:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 20 Jun 2002 03:44:46 -0000 Received: by moria.seul.org (Postfix) id 05DC3146820; Wed, 19 Jun 2002 23:44:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD34114691B; Wed, 19 Jun 2002 23:44:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 62417146820 for ; Wed, 19 Jun 2002 23:44:43 -0400 (EDT) Received: from f-cpu.org (kdl11-1.n.club-internet.fr [213.44.9.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 90DEC16AE for ; Thu, 20 Jun 2002 05:44:38 +0200 (CEST) Message-ID: <3D11517D.6123504@f-cpu.org> Date: Thu, 20 Jun 2002 05:52:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Wed, Jun 19, 2002 at 02:24:38AM +0200, Yann Guidon wrote: > [...] > > > On the other hand, two slightly > > > different instructions would be sufficient for *all* word sizes: > > > > > > loadcons $imm17, reg // similar to the original `loadconsx' > > > => reg := sign_extend(imm17) > > > > > > loadconsp $imm16, reg // `p' means `partial' > > > => reg := shift_left(reg, 16) | imm16 > > > > > > Values between -65536 and 65535, inclusively, can be loaded with a > > > single instruction, 32-bit values need two instructions, and so on. > > > This solution is more general than the original loadcons[x] instructions > > > and IMHO also much more elegant. > > do you meant that you include the SHL in the pipeline ? > Heck no! It's just a hardwired 16-bit left shift: > > if LOADCONSP = '1' then > Register_In(63 downto 16) <= Register_Out(47 downto 0); > Register_In(15 downto 0) <= Data_from_Xbar(15 downto 0); > else > Register_In <= Data_from_Xbar; > end if; i figured this later... and it is not a "clean" option, if we consider future cores that don't work the same way as FC0. #If# the future cores don't use an in-order pipeline or #if# some kind of "translation" is performed on the instruction, then the operation will pass though different stages. Now imagine a crazy coder like us, who reads the description of this instruction : he thinks "great ! a zero-latency shift instruction !" and we'll soon see this instruction used for things completely unrelated >from constant loading... And the coders will be disapointed when another core will perform the instruction differently. The second objection deals with the surface of the shift on the Xbar. see below. > BTW: If you use a 3-way MUX, you can also do zero extension. Add another > input and you can choose between old loadcons, new loadcons, zero > extension and `straight-through' mode. Fact is that you *will* need a > MUX for both variants if we abandon partial writes. sure, but i prefer a simple 2-input mux. Though there are several kinds of immediates, which are treated/expanded during the decode stage. Only the result of the decoded constant will feed the next mux.... And i forgot to mention a "2nd order bypass", which remembers the last word written to the R7, because R7's latency is so high that it needs 2 cycles for data to go in and out, between the time it is written to when it is read again... So in fact, the above mux requires 4 ports : 1 for constants, 1 for register output, and 1 for each "old" write port value... so it's full now. > > in that case, "strings" of consecutive loadcons will have a terrific > > latency ! The purpose of the previous version was clearly to allow > > the programmer to issue 4 loadcons in 4 cycles, in a row. > That should be possible. at what price ? > > > Since we need 8 bits for the opcode and 6 bits for the destination > > > register, we can encode all variants using only a single opcode (compared > > > to 8 opcodes for loadcons[x]): > > given the relative usefulness of loadcons, allocating 8 opcodes is not > > completely unjustified. > IMHO it is. mmmm we could limit the constants to 64 bits and free 2 bits / 4(8) opcodes ? > > > 8 + 1 + 1 + 16 + 6 = 32 bits > > > +--------+---+---+-------+-----+ > > > | opcode | P | S | imm16 | reg | > > > +--------+---+---+-------+-----+ > > > > > > P=0 => load full register; S is the sign bit > > > P=1 => load least significant 16 bits of the register; S is ignored > > > > > > In case you didn't notice it: the same encoding is used by `loadaddri[d]'. > > thanks for the remark, but `loadaddri[d]' doesn't use SHL... > Neither does loadconsp :P but loadaddri uses the ASU to computer PC-relative pointers (i KNEW there was a flaw in what you claimed ;-D) > > > Implementing the new `loadcons' is simple: the decoder sign-extends the > > > immediate value and sends it along. `loadconsp' is a little more tricky > > > because it needs a `feedback loop' from one of the register set's read > > > ports to one of the write ports. Fortunately, the left shift and the > > > `or' operations take almost no time (we need an extra mux, the rest is > > > just a bunch of wires). > > > > I am more and more reluctant to perform shifts on the Xbar. > > I thought we could perform some bit-reversing there, for example, > > but in practice it's too difficult to manage. And how do you > > manage the bypasses ?... i don't want this to become yet > > another naughty hack. > > Why bypasses? Constants are supposed to go into the register set > directly, aren't they? not directly, otherwise we can't do loadconsx 0x1234, r1 add r1, r2, r3 there would be some bypass troubles. To keep things simple, all the write operations MUST share the same datapath, including the R7 read, Xbar read cycle, Xbar write cycle and R7 writeback. If we writeback after the read cycle, it creates new bypass conditions... If loadcons and move use the 2 Xbar (read then write) cycles, it's not slower from the user point of view and it doesn't create special bypass conditions. > If the loadcons[p] instructions are always issued in-order, there is > another way to implement them: add an `accumulator' register to the > instruction decoder. That is, a load will look like this: > > loadcons 0x7777, r0 // acc = 0x0000000000007777; > // maybe do something else here > loadconsp 0x33bb, r0 // acc = 0x00000000777733bb; > // maybe do something else here > loadconsp 0x1919, r42 // acc = 0x0000777733bb1919; r42 = acc; > > Note that destination register `r0' is used as a synonym for `accumulate > but do not write'. hmmmm i thought about this for a while (so i won't blame on you :-P) but quickly abandonned this idea. What would happen if an IRQ fired in the middle of this sequence ? r0 would be lost and we wouldn't know where to write its contents :-( So loadcons MUST always specify the destination. > + less pressure on the register set (ports remain free) > + feedback loop is local, not wrapped around the register set > + less timing critical! > + can be interleaved with other instructions (except loadcons) > - disables well-known loadcons tricks (but probably enables others) but major flaw with interrupts and exceptions/traps :-( in other words : it's not "atomic" and it relies on the state of a single register (so it might become a bottleneck later) ... and if there is a state somewhere, it might confuse the compilers as well... > [...] > > i don't want to use the "shift" approach. I don't know for the ALPHA, > > but even MIPS uses a specific instruction to load the MSB with a constant. > SPARC as well (but they split the register after 22 bits). > > > The "relative" approach increases the dependencies between the operations, > > while the "absolute" way does not require an order. I remember that Cedric > > used loadcons optimisations to create a specific constant in his RC5 code... > > > > the "old" loadcons can still be done without partial writes, like you > > said, with another MUX in the CDP. ok. > > But remember that a shift requires a certain amount of Silicon surface, > > much more than a simple mux, and it depends on the number of wires to cross. > Since it's not really a shift, but IT IS A SHIFT ! it's not a barrel shifter, but you need at least another metal layer to bring a bunch of wires up to 16 positions. Given the mask rules of 1Lambda for a wire width and 2L for spacing (as a rough estimate), then your shift will consume a surface of at least (2+1*16) * 48 Lambdas. And since oblique routing (45° wires) is not usual, it's going to take even more. OTOH, a straight line consumes far less wires and surface. > it requires a 48-bit MUX, 48 wires and 1 control line. > A normal (unshifted) feedback, as needed for the old > loadcons, requires four 16-bit MUXes, 64 wires and 4 control lines. Not > a big difference (and my version is actually cheaper). not cheaper in wire length because the number of wires you shift (16 in this case) is also the minimal distance between 2 gates. Unless you eat up all the routing/metal levels... > > My conclusion : partial writes are being abandonned but > > the "old" loadcons is still useful and easy to do. > > I don't even think that there will be a problem. > > It's just like a "move" instruction but with a modified > > datapath. > I guess I should be satisfied, but I'm not :) Don't worry, you can confide yourself to Doktor Guidon ;-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From JGraley@sonicblue.com Thu Jun 20 12:00:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17L4iZ-0005wD-00 for ; Thu, 20 Jun 2002 18:23:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 20 Jun 2002 18:23:31 +0200 (CEST) Received: (qmail 24340 invoked by uid 0); 20 Jun 2002 09:56:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 20 Jun 2002 09:56:19 -0000 Received: by moria.seul.org (Postfix) id 02FA414698B; Thu, 20 Jun 2002 05:56:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDF1714698D; Thu, 20 Jun 2002 05:56:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by moria.seul.org (Postfix) with ESMTP id 3500114698B for ; Thu, 20 Jun 2002 05:56:17 -0400 (EDT) Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g5K9uG903643 for ; Thu, 20 Jun 2002 03:56:16 -0600 (MDT) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g5K9uG608443 for ; Thu, 20 Jun 2002 02:56:16 -0700 (PDT) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Thu Jun 20 03:05:22 2002 -0700 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 02:57:19 -0700 Message-ID: <37D1208A1C9BD511855B00D0B772242C0118AD7B@corpmail1.sc.sonicblue.com> From: John Graley To: "'f-cpu@seul.org'" Subject: RE: [f-cpu] Late answer Date: Thu, 20 Jun 2002 03:00:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello! Why not use the barrel shifter, but optimise the design to be super-fast for a shift left of exactly 16 bits. Eg shifter1 = (shift_amount & 4) ? input[47:0]+input[63:48] : input // do bit 4 FIRST for fast 16-bit shifter2 = (shift_amount & 5) ? shifter1[31:0]+shifter1[63:32] : shifter1 shifter3 = (shift_amount & 1) ? shifter2[62:0]+shifter2[63] : shifter2 etc... result = (shift_amount==16) ? shifter1 : shifter6 // bypass all but first stage in 16-bit case Cheers, John ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 20 20:30:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LAl2-0002At-00 for ; Fri, 21 Jun 2002 00:50:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Jun 2002 00:50:28 +0200 (CEST) Received: (qmail 22673 invoked by uid 0); 20 Jun 2002 19:21:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Jun 2002 19:21:29 -0000 Received: by moria.seul.org (Postfix) id 66C7F146921; Thu, 20 Jun 2002 15:21:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D387146923; Thu, 20 Jun 2002 15:21:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a069.home.uni-hannover.de [130.75.232.69]) by moria.seul.org (Postfix) with ESMTP id CABC9146921 for ; Thu, 20 Jun 2002 15:21:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00937; Thu, 20 Jun 2002 20:30:42 +0200 Message-ID: <20020620203042.39024@thrai.stud.uni-hannover.de> Date: Thu, 20 Jun 2002 20:30:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3D11517D.6123504@f-cpu.org>; from Yann Guidon on Thu, Jun 20, 2002 at 05:52:29AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 20, 2002 at 05:52:29AM +0200, Yann Guidon wrote: [loadconsp] > > Heck no! It's just a hardwired 16-bit left shift: > > > > if LOADCONSP = '1' then > > Register_In(63 downto 16) <= Register_Out(47 downto 0); > > Register_In(15 downto 0) <= Data_from_Xbar(15 downto 0); > > else > > Register_In <= Data_from_Xbar; > > end if; > > i figured this later... and it is not a "clean" option, if we consider > future cores that don't work the same way as FC0. #If# the future cores > don't use an in-order pipeline or #if# some kind of "translation" > is performed on the instruction, then the operation will pass though > different stages. But it will still perform the same operation. It has to, for compatibility. > Now imagine a crazy coder like us, who reads the description of this > instruction : he thinks "great ! a zero-latency shift instruction !" > and we'll soon see this instruction used for things completely unrelated > from constant loading... And the coders will be disapointed when another > core will perform the instruction differently. It can't. But it may be slower -> not our problem. If some weirdo uses an instruction for purposes it wasn't meant for, ... ;) On the other hand, I'm one of those weirdoes myself... ;) > The second objection deals with the surface of the shift on the Xbar. > see below. Hmm... > > BTW: If you use a 3-way MUX, you can also do zero extension. Add another > > input and you can choose between old loadcons, new loadcons, zero > > extension and `straight-through' mode. Fact is that you *will* need a > > MUX for both variants if we abandon partial writes. > sure, but i prefer a simple 2-input mux. > Though there are several kinds of immediates, which are treated/expanded > during the decode stage. Only the result of the decoded constant > will feed the next mux.... > > And i forgot to mention a "2nd order bypass", which remembers the last > word written to the R7, because R7's latency is so high that it needs > 2 cycles for data to go in and out, between the time it is written to > when it is read again... So in fact, the above mux requires 4 ports : > 1 for constants, 1 for register output, and 1 for each "old" write > port value... so it's full now. Oh boy... 2nd order bypass? *sigh* Sounds like `angina pectoris'. [...] > > > given the relative usefulness of loadcons, allocating 8 opcodes is not > > > completely unjustified. > > IMHO it is. > mmmm we could limit the constants to 64 bits and free 2 bits / 4(8) opcodes ? We can free 7 opcodes without limiting constant size. > > > > 8 + 1 + 1 + 16 + 6 = 32 bits > > > > +--------+---+---+-------+-----+ > > > > | opcode | P | S | imm16 | reg | > > > > +--------+---+---+-------+-----+ > > > > > > > > P=0 => load full register; S is the sign bit > > > > P=1 => load least significant 16 bits of the register; S is ignored > > > > > > > > In case you didn't notice it: the same encoding is used by `loadaddri[d]'. > > > thanks for the remark, but `loadaddri[d]' doesn't use SHL... > > Neither does loadconsp :P > but loadaddri uses the ASU to computer PC-relative pointers (i KNEW there > was a flaw in what you claimed ;-D) The encoding is still the same, though. I didn't claim that it uses the same EU, did I? ;) [...] > > Why bypasses? Constants are supposed to go into the register set > > directly, aren't they? > > not directly, otherwise we can't do > loadconsx 0x1234, r1 > add r1, r2, r3 > there would be some bypass troubles. To keep things simple, all > the write operations MUST share the same datapath, including > the R7 read, Xbar read cycle, Xbar write cycle and R7 writeback. > If we writeback after the read cycle, it creates new bypass conditions... You can't bypass when you load a partial constant: loadconsx.1 0, r1 // no bypass possible! add r1, r2, r3 (ironically, this is one way to zero-extend a 16- or 32-bit value). When part of the value comes from the register set and the rest from the decoder, you *have* to read the register - and you have to write it *before*, or you'll need another MUX inside the datapath. [...] > > If the loadcons[p] instructions are always issued in-order, there is > > another way to implement them: add an `accumulator' register to the > > instruction decoder. That is, a load will look like this: > > > > loadcons 0x7777, r0 // acc = 0x0000000000007777; > > // maybe do something else here > > loadconsp 0x33bb, r0 // acc = 0x00000000777733bb; > > // maybe do something else here > > loadconsp 0x1919, r42 // acc = 0x0000777733bb1919; r42 = acc; > > > > Note that destination register `r0' is used as a synonym for `accumulate > > but do not write'. > > hmmmm i thought about this for a while (so i won't blame on you :-P) > but quickly abandonned this idea. What would happen if an IRQ fired > in the middle of this sequence ? r0 would be lost and we wouldn't know > where to write its contents :-( So loadcons MUST always specify the > destination. That's easy to solve, isn't it? The obvious solution is to include the accumulator register in the SRB. When the IRQ arrives, the register is automatically saved if it is going to be re-used inside the IRQ service routine, and it is automatically restored when the IRQ handler returns. > > + less pressure on the register set (ports remain free) > > + feedback loop is local, not wrapped around the register set > > + less timing critical! > > + can be interleaved with other instructions (except loadcons) > > - disables well-known loadcons tricks (but probably enables others) > but major flaw with interrupts and exceptions/traps :-( Solved :) > in other words : it's not "atomic" and it relies on the state of a single > register (so it might become a bottleneck later) ... > and if there is a state somewhere, it might confuse the compilers as well... There's no need to become confused. Compilers can treat a loadcons sequence as a single instruction, and assemblers can translate a single `loadcons' into an appropriate sequence automatically. You just write loadcons some_large_constant, r23 and the assembler does the rest. A super-optimizing compiler will of course have to handle loadcons himself (for instruction interleaving etc.), but then it's also supposed to know what it does. [...] > Given the mask rules of 1Lambda for a wire width and 2L for spacing > (as a rough estimate), then your shift will consume a surface of at least > (2+1*16) * 48 Lambdas. And since oblique routing (45° wires) is not usual, > it's going to take even more. OTOH, a straight line consumes far less wires > and surface. Ok, that's a point. Then let's use the accumulator solution (where the shift is moved outside the Xbar/EU complex). It also has the advantage that it can't be abused as a `fast left shift' ;) [...] > > I guess I should be satisfied, but I'm not :) > Don't worry, you can confide yourself to Doktor Guidon ;-) Don't tell me about doctors... *sigh* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 20 19:21:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LAl3-0002At-00 for ; Fri, 21 Jun 2002 00:50:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Jun 2002 00:50:29 +0200 (CEST) Received: (qmail 7032 invoked by uid 0); 20 Jun 2002 19:21:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 20 Jun 2002 19:21:44 -0000 Received: by moria.seul.org (Postfix) id 3442D146923; Thu, 20 Jun 2002 15:21:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B073146925; Thu, 20 Jun 2002 15:21:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a069.home.uni-hannover.de [130.75.232.69]) by moria.seul.org (Postfix) with ESMTP id 91724146923 for ; Thu, 20 Jun 2002 15:21:28 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00784; Thu, 20 Jun 2002 19:21:30 +0200 Message-ID: <20020620192129.45856@thrai.stud.uni-hannover.de> Date: Thu, 20 Jun 2002 19:21:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: More Alphabet Soup (was: [f-cpu] (!) a few noteworthy things) References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> <20020619171114.04784@thrai.stud.uni-hannover.de> <3D113EB5.FAC945FC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D113EB5.FAC945FC@f-cpu.org>; from Yann Guidon on Thu, Jun 20, 2002 at 04:32:21AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 20, 2002 at 04:32:21AM +0200, Yann Guidon wrote: [...] > > A pipelined SHL would be more difficult to write but should be > > possible. But please let's keep the 1-stage version for now. > is there any reason not to ? Not at the moment. [...] > > The granularity check isn't hard to do. Let U1 and U2 be the decoded > > `size vectors' (that is, "000", "001", "011" or "111") and SIMD1 and > > SIMD2 be the SIMD flags of the first and second instruction, respectively, > > then bypassing without masking is permitted if > > > > not (U1 or (2 downto 0 => SIMD1)) > > and (U2 or (2 downto 0 => SIMD2)) = "000" > > > > It's MUCH harder to check for the case whether a bypass is appropriate > > at all (compare register numbers and so on)! > > ok, we can check whether there is a size change. and then ? > the "simple solution is to "hold/stall" the decode pipeline, > but this thought is not funny... Stalling for 1 cycle is better than scheduling an explicit "zero extend" instructions that will take at least 2 cycles (one for operating, and one for another result bypass). [...] > > > by not binding the pointer format to the existing data formats > > > (char, int, long int...), it becomes difficult to do pointer arithmetics > > > with "common" arithmetic operations. > > The answer is, of course: use SIMD mode with maximum chunk size. Since > > it is identical to non-SIMD mode with the same chunk size... > no, because all F-CPUs are not 64-bit wide... I said: MAXIMUM chunk size - that is, full-word. If that isn't possible, use 64-bit mode instead (I doubt that we'll see F-CPU chips with more than 64 address lines during the next 10...20 years). > > [...port sharing between EUs...] > > > > Note that you may introduce EU dependencies that way. > > > I don't see what you mean by "EU dependencies". > > If two EUs share a port, you can use only one of them at a time. This > > currently doesn't matter for input ports (because we build a 1-issue CPU) > > but is important for output ports - results MUST NOT arrive at the same > > time, and the scheduler will have to take care of that. Yet another > > special case to handle... > > i went to a japanese restaurant today and made a few drawings on my papers... Japanese characters, again? ;) *kritzel* > ===> it's not a problem. > > One parameter is that we can group units that have the same latency : > the current ROP2 and INC units are rather similar and can share the same > "output" port, which can be further simplified. This one needs however > to support the write to either R7's write port (if a preceding ASU > operation was started, for example, ROP2/INC has to use the alternate > write port). What a hack! > Another problem arises, however : i've been very laxist about the > "variable latency" of the units, such as additional/optional pipe stages > for some units. putting a non-shareable "output" in the middle of > some units might be difficult in practice. we'll probably have to abandon > the idea of min/max/sort/etc. in the INC unit, as well as 16-bit and 32-bit > combination in ROP2, and the 8-bit 1-cycle latency of the ASU. > The other good side is that the latency decoder is simplified... What about the IMU? It has ports at d=3, d=4, d=5 and d=6. [...] > > > > - some instructions need special handling (complex!) > > > which ? > > > > You already mentioned them - ROP2 (xnor, orn), INC - and IDU. > > is SHL safe ? Shifting/rotating 0 by 0 bits, in any direction, gives 0 ;) > then, MSB clearing is performed on the R7 read ports and on the "output" port > shared by INC and ROP2 (add to that that they have the same latency, > and you understand why they are grouped together ;-) I still like the B+b solution better. What about future EUs that we didn't specify yet? What about the FP units? Not all FP operations have the `f(0)=0' property! That adds a lot of potential special cases :( > > > > 1) Surprise! You need to mask the operands of the second instruction > > > > but there is no masking unit inside the bypass. > > > if it's needed, we'll make it. > > > > If we put masks into the bypass and the register write ports, the > > whole discussion is closed. With that, we can always bypass, and we > > can always zero-extend. > > According to my remark above, masking at 2 locations only > is possible. no scheduling trick, i guess it's the best i can do. Sorry but it's an ugly hack. Boomerang-style - if you don't pay attention, it will come back and hit you. I prefer clean solutions. [...] > > > > + masking moved to register set > > > > + requires only 2 masking units (one per register write port) > > > there is no big difference in practice, i guess. > > > > > > But the real difference is that 2 instructions can use the 2 write ports > > > and they can use 2 different write sizes --> in practice, it's more > > > complex than A) because A) needs 1 mask control logic, while B) needs 2. > > > > I suppose that every masking unit has its own decoder logic anyway, > > in order to reduce the number of wires. You only send the SIMD and U > > bits to it, and the rest is done in place. > if you can do it only once (as on the read port), it certainly is easier > to understand and implement :-) And takes much more (and longer) wires. [...] > > > can't we just trry to make something a kid can understand ?... > > Ok, let's build a Turing machine ;) > can this run a Linux kernel ? :-P A Turing machine can run anything, so the question is: "Has Linux been ported to it already?" ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jun 20 19:00:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LAl4-0002At-00 for ; Fri, 21 Jun 2002 00:50:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Jun 2002 00:50:30 +0200 (CEST) Received: (qmail 10933 invoked by uid 0); 20 Jun 2002 19:21:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 20 Jun 2002 19:21:46 -0000 Received: by moria.seul.org (Postfix) id D2EDE146925; Thu, 20 Jun 2002 15:21:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A31EE14692B; Thu, 20 Jun 2002 15:21:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a069.home.uni-hannover.de [130.75.232.69]) by moria.seul.org (Postfix) with ESMTP id BE82C146925 for ; Thu, 20 Jun 2002 15:21:32 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00733; Thu, 20 Jun 2002 19:00:18 +0200 Message-ID: <20020620190018.02764@thrai.stud.uni-hannover.de> Date: Thu, 20 Jun 2002 19:00:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] More broth in the Alphabet Soup References: <3D0D3BE3.3A677648@f-cpu.org> <3D0D4AFF.6C7BE7F2@jetnet.ab.ca> <3D0D5316.D15731E2@f-cpu.org> <20020617160529.43987@thrai.stud.uni-hannover.de> <3D0E8087.452AF1CC@f-cpu.org> <20020618185045.43598@thrai.stud.uni-hannover.de> <3D0FCF48.585320F1@f-cpu.org> <20020619171114.04784@thrai.stud.uni-hannover.de> <3D10ACFD.9E0DD64A@jetnet.ab.ca> <3D11029A.F9B1F6EA@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D11029A.F9B1F6EA@f-cpu.org>; from Yann Guidon on Thu, Jun 20, 2002 at 12:15:54AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jun 20, 2002 at 12:15:54AM +0200, Yann Guidon wrote: [...] > > > > a scatter/gather instruction would be ideally performed using a "base" > > > > pointer (checked the usual way) and a SIMD "offset", so every SIMD offset > > > > chunk is parallelly checked against the maximum allowed offset (size of page > > > > in TLB ?) and the TLB doens't need as many ports as there are chunks... > > > > > > Sounds good. Especially if we require the base pointer to be page > > > aligned :) > > > > > What about dumb things like video displays that have multiple byte sizes? > > Here your gather would need to be for bytes,words,and longs on a long boundry. > hmm i see, that's the offset size problem... > if you need to access more than 64K 16-bit words, then you can mask off > the LSB and perform more 32-bit accesses. The results are shifted/masked > to return the wanted part. What's scatter/gather good for in a video framebuffer? Scatter/gather in the form outlined above is most useful for parallel (SIMD) table lookups - encode/decode small values (bytes or maybe 16-bit words), grab coefficients from a table and so on. Ideally, scatter/gather will simply OR the base pointer with each of the offsets, instead of adding them. If you really need a higher granularity for the base pointer, you'll have to do it manually. I.e. instead of gather.d r2, r1, r3 // r1 = base, r2 = 16-bit offsets, r3 = destination you'll write: loadcons PAGE_MASK, r3 and r3, r1, r4 // aligned pointer andn r3, r1, r3 // common offset sdup.d r3, r3 sadd r3, r2, r3 // add offsets gather.d r3, r4, r3 The reason is, of course, to keep the latency of scatter/gather as low as possible. If the instruction had to perform up to eight adds first, it would be inacceptably slow. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jun 21 00:51:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LAlE-0002At-00 for ; Fri, 21 Jun 2002 00:50:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Jun 2002 00:50:40 +0200 (CEST) Received: (qmail 32266 invoked by uid 0); 20 Jun 2002 22:44:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Jun 2002 22:44:05 -0000 Received: by moria.seul.org (Postfix) id C49AA14691D; Thu, 20 Jun 2002 18:44:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 99133146924; Thu, 20 Jun 2002 18:44:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CD40A14691D for ; Thu, 20 Jun 2002 18:44:01 -0400 (EDT) Received: from f-cpu.org (kdl11-5.n.club-internet.fr [213.44.9.5]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 93B84168D for ; Fri, 21 Jun 2002 00:43:55 +0200 (CEST) Message-ID: <3D125C82.7D96EAEF@f-cpu.org> Date: Fri, 21 Jun 2002 00:51:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Thu, Jun 20, 2002 at 05:52:29AM +0200, Yann Guidon wrote: > [loadconsp] > > > Heck no! It's just a hardwired 16-bit left shift: > > > if LOADCONSP = '1' then > > > Register_In(63 downto 16) <= Register_Out(47 downto 0); > > > Register_In(15 downto 0) <= Data_from_Xbar(15 downto 0); > > > else > > > Register_In <= Data_from_Xbar; > > > end if; > > i figured this later... and it is not a "clean" option, if we consider > > future cores that don't work the same way as FC0. #If# the future cores > > don't use an in-order pipeline or #if# some kind of "translation" > > is performed on the instruction, then the operation will pass though > > different stages. > But it will still perform the same operation. It has to, for compatibility. certainly, but that's the first half of the problem. Though if loadcons relies on naughty hacks, it will be much more difficult to implement later... {insert thought about your "accumulator" proposal here} > > Now imagine a crazy coder like us, who reads the description of this > > instruction : he thinks "great ! a zero-latency shift instruction !" > > and we'll soon see this instruction used for things completely unrelated > > from constant loading... And the coders will be disapointed when another > > core will perform the instruction differently. > It can't. But it may be slower -> not our problem. If some weirdo uses > an instruction for purposes it wasn't meant for, ... ;) > On the other hand, I'm one of those weirdoes myself... ;) now, you see what i mean. now, imagine the crowd of people who have read Michael Abrash's "Zen of code optimisation" and who apply his saying "don't look at an instuction for what it is meant to do, but for what it does"... > > The second objection deals with the surface of the shift on the Xbar. > > see below. > Hmm... sure... > > > BTW: If you use a 3-way MUX, you can also do zero extension. Add another > > > input and you can choose between old loadcons, new loadcons, zero > > > extension and `straight-through' mode. Fact is that you *will* need a > > > MUX for both variants if we abandon partial writes. > > sure, but i prefer a simple 2-input mux. > > Though there are several kinds of immediates, which are treated/expanded > > during the decode stage. Only the result of the decoded constant > > will feed the next mux.... > > > > And i forgot to mention a "2nd order bypass", which remembers the last > > word written to the R7, because R7's latency is so high that it needs > > 2 cycles for data to go in and out, between the time it is written to > > when it is read again... So in fact, the above mux requires 4 ports : > > 1 for constants, 1 for register output, and 1 for each "old" write > > port value... so it's full now. > > Oh boy... 2nd order bypass? *sigh* Sounds like `angina pectoris'. Fortunately, Doktor Guidon found the cure ;-P > [...] > > > > given the relative usefulness of loadcons, allocating 8 opcodes is not > > > > completely unjustified. > > > IMHO it is. > > mmmm we could limit the constants to 64 bits and free 2 bits / 4(8) opcodes ? > We can free 7 opcodes without limiting constant size. groumpfh. > > > > > 8 + 1 + 1 + 16 + 6 = 32 bits > > > > > +--------+---+---+-------+-----+ > > > > > | opcode | P | S | imm16 | reg | > > > > > +--------+---+---+-------+-----+ > > > > > > > > > > P=0 => load full register; S is the sign bit > > > > > P=1 => load least significant 16 bits of the register; S is ignored > > > > > > > > > > In case you didn't notice it: the same encoding is used by `loadaddri[d]'. > > > > thanks for the remark, but `loadaddri[d]' doesn't use SHL... > > > Neither does loadconsp :P > > but loadaddri uses the ASU to computer PC-relative pointers (i KNEW there > > was a flaw in what you claimed ;-D) > The encoding is still the same, though. I didn't claim that it uses > the same EU, did I? ;) sorry, wrong question :-P > [...] > > > Why bypasses? Constants are supposed to go into the register set > > > directly, aren't they? > > not directly, otherwise we can't do > > loadconsx 0x1234, r1 > > add r1, r2, r3 > > there would be some bypass troubles. To keep things simple, all > > the write operations MUST share the same datapath, including > > the R7 read, Xbar read cycle, Xbar write cycle and R7 writeback. > > If we writeback after the read cycle, it creates new bypass conditions... > You can't bypass when you load a partial constant: > loadconsx.1 0, r1 > // no bypass possible! > add r1, r2, r3 partial constants certainly ARE bypassable, otherwise what would be the point of the MUXes in the Xbar read cycle ? > (ironically, this is one way to zero-extend a 16- or 32-bit value). > > When part of the value comes from the register set and the rest from > the decoder, you *have* to read the register - and you have to write > it *before*, or you'll need another MUX inside the datapath. There is already a MUX in the xbar, which chooses between the register set's output, the constants that come from the decoder (for the usual addi stuffs) and the other bypasses (both levels of both write ports). > [...] > > > If the loadcons[p] instructions are always issued in-order, there is > > > another way to implement them: add an `accumulator' register to the > > > instruction decoder. That is, a load will look like this: > > > > > > loadcons 0x7777, r0 // acc = 0x0000000000007777; > > > // maybe do something else here > > > loadconsp 0x33bb, r0 // acc = 0x00000000777733bb; > > > // maybe do something else here > > > loadconsp 0x1919, r42 // acc = 0x0000777733bb1919; r42 = acc; > > > > > > Note that destination register `r0' is used as a synonym for `accumulate > > > but do not write'. > > > > hmmmm i thought about this for a while (so i won't blame on you :-P) > > but quickly abandonned this idea. What would happen if an IRQ fired > > in the middle of this sequence ? r0 would be lost and we wouldn't know > > where to write its contents :-( So loadcons MUST always specify the > > destination. > > That's easy to solve, isn't it? so easy that you forget the catches... 'easy' is not always 'good'. > The obvious solution is to include the > accumulator register in the SRB. When the IRQ arrives, the register is > automatically saved if it is going to be re-used inside the IRQ service > routine, and it is automatically restored when the IRQ handler returns. no, not THAT .... you're just adding yet another non-portable feature. did you already forget the binary compatibility ? the naughty hacker's codes that perform platform-dependent optimisations ?... > > > + less pressure on the register set (ports remain free) > > > + feedback loop is local, not wrapped around the register set > > > + less timing critical! > > > + can be interleaved with other instructions (except loadcons) > > > - disables well-known loadcons tricks (but probably enables others) > > but major flaw with interrupts and exceptions/traps :-( > Solved :) i don't consider this as a viable solution ... > > in other words : it's not "atomic" and it relies on the state of a single > > register (so it might become a bottleneck later) ... > > and if there is a state somewhere, it might confuse the compilers as well... > > There's no need to become confused. Compilers can treat a loadcons > sequence as a single instruction, and assemblers can translate a single > `loadcons' into an appropriate sequence automatically. You just write > > loadcons some_large_constant, r23 > > and the assembler does the rest. A super-optimizing compiler will of > course have to handle loadcons himself (for instruction interleaving > etc.), but then it's also supposed to know what it does. "it's also supposed to know what it does." but does it want to do it ? > [...] > > Given the mask rules of 1Lambda for a wire width and 2L for spacing > > (as a rough estimate), then your shift will consume a surface of at least > > (2+1*16) * 48 Lambdas. oups ! wrong formula ! it should be 16 * 48 * (1+2)^2 which is even 3x larger. > > And since oblique routing (45° wires) is not usual, > > it's going to take even more. OTOH, a straight line consumes far less wires > > and surface. > Ok, that's a point. Then let's use the accumulator solution (where the > shift is moved outside the Xbar/EU complex). It also has the advantage > that it can't be abused as a `fast left shift' ;) no ! loadcons is loadcons and is not a unit in itself. otherwise, one has to use SHL instead. > [...] > > > I guess I should be satisfied, but I'm not :) > > Don't worry, you can confide yourself to Doktor Guidon ;-) > Don't tell me about doctors... *sigh* are you sick ?... say "dreiunddreizig"... :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: just in case you didn't know, Simili2 build 23 is out on symphonyeda.com. Several bug fixes, but still no command-line only package. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 21 01:43:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LR74-0000HB-00 for ; Fri, 21 Jun 2002 18:18:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 21 Jun 2002 18:18:18 +0200 (CEST) Received: (qmail 32389 invoked by uid 0); 20 Jun 2002 23:43:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Jun 2002 23:43:57 -0000 Received: by moria.seul.org (Postfix) id CBE3D146926; Thu, 20 Jun 2002 19:43:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3A79146929; Thu, 20 Jun 2002 19:43:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a086.home.uni-hannover.de [130.75.232.86]) by moria.seul.org (Postfix) with ESMTP id F03BD146926 for ; Thu, 20 Jun 2002 19:43:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02943; Fri, 21 Jun 2002 01:43:51 +0200 Message-ID: <20020621014350.22549@thrai.stud.uni-hannover.de> Date: Fri, 21 Jun 2002 01:43:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D125C82.7D96EAEF@f-cpu.org>; from Yann Guidon on Fri, Jun 21, 2002 at 12:51:46AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well, here we go again... [...] > > > i figured this later... and it is not a "clean" option, if we consider > > > future cores that don't work the same way as FC0. #If# the future cores > > > don't use an in-order pipeline or #if# some kind of "translation" > > > is performed on the instruction, then the operation will pass though > > > different stages. > > But it will still perform the same operation. It has to, for compatibility. > certainly, but that's the first half of the problem. Though if loadcons > relies on naughty hacks, it will be much more difficult to implement later... > {insert thought about your "accumulator" proposal here} A future core will have to do only one thing: implement the specified behaviour. If we specify the `shifted' version, it will have to work that way, whether it uses a hardwired shift, the SHL or something else. If we specify the original `partial write' version, it will have to work *that* way, whether the register set actually supports partial writes or not. And if we specify the `accumulator' version, it will of course have to use an accumulator. We're not only discussing the implementation, but also the specification (because the current specification is suboptimal and hard to implement). > > > Now imagine a crazy coder like us, who reads the description of this > > > instruction : he thinks "great ! a zero-latency shift instruction !" > > > and we'll soon see this instruction used for things completely unrelated > > > from constant loading... And the coders will be disapointed when another > > > core will perform the instruction differently. > > It can't. But it may be slower -> not our problem. If some weirdo uses > > an instruction for purposes it wasn't meant for, ... ;) > > On the other hand, I'm one of those weirdoes myself... ;) > now, you see what i mean. > now, imagine the crowd of people who have read Michael Abrash's > "Zen of code optimisation" and who apply his saying "don't look at > an instuction for what it is meant to do, but for what it does"... If you look at the specification (and not the implementation), everything will be fine. If we *specify* that `loadconsp' does a left-shift and replaces the least significant 16 bits, then why shouldn't a programmer use it for that purpose? You can also use the current `loadconsx.1 0, reg' and `loadconsx.2 0, reg' for zero-extending 16- and 32-bit values. There's nothing wrong with it. For example, Thomas used mixl/mixh with r0 as the first operand in order to separate 8-bit RGB values and zero-extend them to 16 bit, or sdup.q in order to duplicate a 32-bit constant. [...] > > You can't bypass when you load a partial constant: > > loadconsx.1 0, r1 > > // no bypass possible! > > add r1, r2, r3 > > partial constants certainly ARE bypassable, otherwise what would be the > point of the MUXes in the Xbar read cycle ? And if we can avoid those MUXes? Move the complexity out of the Xbar? Make the datapath shorter? I thought that was what you wanted. > > (ironically, this is one way to zero-extend a 16- or 32-bit value). > > > > When part of the value comes from the register set and the rest from > > the decoder, you *have* to read the register - and you have to write > > it *before*, or you'll need another MUX inside the datapath. > > There is already a MUX in the xbar, which chooses between the register > set's output, the constants that come from the decoder (for the usual > addi stuffs) and the other bypasses (both levels of both write ports). That's a lot of stuff. Four n-way 16-bit muxes with control logic for each 64-bit datapath - and there are at least three of them, because EUs can take three operands. [...accumulating loadcons...] > > > hmmmm i thought about this for a while (so i won't blame on you :-P) > > > but quickly abandonned this idea. What would happen if an IRQ fired > > > in the middle of this sequence ? r0 would be lost and we wouldn't know > > > where to write its contents :-( So loadcons MUST always specify the > > > destination. > > > > That's easy to solve, isn't it? > so easy that you forget the catches... 'easy' is not always 'good'. > > > The obvious solution is to include the > > accumulator register in the SRB. When the IRQ arrives, the register is > > automatically saved if it is going to be re-used inside the IRQ service > > routine, and it is automatically restored when the IRQ handler returns. > no, not THAT .... > you're just adding yet another non-portable feature. did you already forget > the binary compatibility ? the naughty hacker's codes that perform > platform-dependent optimisations ?... Since this variant works differently, we would of course have to specify that it works this way (and future cores would have to work just the same way). The point is that this variant avoids partial data transports in both the register set and the Xbar. We will only have to move full-length words around - and that makes a lot of things a lot easier, doesn't it? [...] > > > in other words : it's not "atomic" and it relies on the state of a single > > > register (so it might become a bottleneck later) ... > > > and if there is a state somewhere, it might confuse the compilers as well... > > > > There's no need to become confused. Compilers can treat a loadcons > > sequence as a single instruction, and assemblers can translate a single > > `loadcons' into an appropriate sequence automatically. You just write > > > > loadcons some_large_constant, r23 > > > > and the assembler does the rest. A super-optimizing compiler will of > > course have to handle loadcons himself (for instruction interleaving > > etc.), but then it's also supposed to know what it does. > "it's also supposed to know what it does." but does it want to do it ? If it wants to squeeze out every unnecessary cycle, yes. Otherwise, no. [...] > > Ok, that's a point. Then let's use the accumulator solution (where the > > shift is moved outside the Xbar/EU complex). It also has the advantage > > that it can't be abused as a `fast left shift' ;) > no ! loadcons is loadcons and is not a unit in itself. > otherwise, one has to use SHL instead. Who says it isn't? As far as I am concerned, the current F-CPU specification is not cast in stone. If there are mistakes in it, we have to correct them - and believe me, partial writes (and partial data moves) *are* mistakes. There are others - like the `mac mistake': the mac and mul instructions use different result formats (mac results are widened "if the destination register is wide enough"). Since `mac.64' will behave differently on a 64- and a 128-bit F-CPU, this clearly is a Big Bad Bug in the specification. But there are always alternatives, and we should at least consider them. AND we should take care that we choose an alternative that is easy to implement. KISS principle. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jun 21 23:13:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17LZDP-000660-00 for ; Sat, 22 Jun 2002 02:57:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 22 Jun 2002 02:57:23 +0200 (CEST) Received: (qmail 16882 invoked by uid 0); 21 Jun 2002 21:05:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 21 Jun 2002 21:05:48 -0000 Received: by moria.seul.org (Postfix) id AD6451462F9; Fri, 21 Jun 2002 17:05:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F3F714692E; Fri, 21 Jun 2002 17:05:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 171B914692D for ; Fri, 21 Jun 2002 17:05:46 -0400 (EDT) Received: from f-cpu.org (kll1-134.n.club-internet.fr [213.44.91.134]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 20CB116C0 for ; Fri, 21 Jun 2002 23:05:43 +0200 (CEST) Message-ID: <3D139703.15818C24@f-cpu.org> Date: Fri, 21 Jun 2002 23:13:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] (VHDL) new tool-independent scripts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! the result of 6 hours of hacking is very promising : there will soon be no tool dependent scripting chores ! you won't be forced to do one script for Simili, another for vanilla, etc... and the support of any other tool will be almost painless ! The core of the program is a few bash scripts which go fetch and read small tool description files. i already have programmed the detection side for simili, vanilla (the most difficult, because i don't have libc5) and ncsim. Adding Riviera or modelsim will be as simple as writing a few lines... Another use is to run all tool at the same time. That's easy, now. Not everything is ready now, and i guess that the different contributors have file trees in various shapes. it's time to clean that up in order to reduce all the coding efforts and finally concentrate only on VHDL ;-) i'll put my files in a few days on seul.org. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jun 23 16:10:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17MK9r-0000qn-01 for ; Mon, 24 Jun 2002 05:04:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Jun 2002 05:04:51 +0200 (CEST) Received: (qmail 8114 invoked by uid 0); 23 Jun 2002 16:13:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 23 Jun 2002 16:13:21 -0000 Received: by moria.seul.org (Postfix) id B2DB5146CD4; Sun, 23 Jun 2002 12:13:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B2F1146DFB; Sun, 23 Jun 2002 12:13:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 0043D146CD4 for ; Sun, 23 Jun 2002 12:13:14 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-155-59.dial.proxad.net [62.147.155.59]) by postfix1-2.free.fr (Postfix) with ESMTP id 3E60AAB0E0 for ; Sun, 23 Jun 2002 18:13:13 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Call convention resume Date: Sun, 23 Jun 2002 14:10:57 +0000 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206231410.57519.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi every body, I will try to do a resume of what has been say about call convention during the last week, before updating the manual. R0: zero R1 : number of parameter (for debug and security) and return value R2-R15 : functions arguments (call-clobbered) R15-R31 : temporary registers (call-clobbered) R32-R58 : local registers (callee-saver) R59 : return adress R60 : pointer to the Procedure Linkage Table R61 : pointer to the Global Offset Table R62 : Frame pointer (Function Entry Frame) R63 : stack pointer after which the parameters after the 14th are push in reverse order (Function Entry Frame - number of bytes allocated) I think that I don't forget any of your post, but if not I wait for your notes. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jun 24 00:27:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17MK9v-0000qn-01 for ; Mon, 24 Jun 2002 05:04:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Jun 2002 05:04:55 +0200 (CEST) Received: (qmail 23743 invoked by uid 0); 23 Jun 2002 22:10:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 23 Jun 2002 22:10:05 -0000 Received: by moria.seul.org (Postfix) id 81421146D5E; Sun, 23 Jun 2002 18:10:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 469DA146DC7; Sun, 23 Jun 2002 18:10:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4D369146D5E for ; Sun, 23 Jun 2002 18:10:00 -0400 (EDT) Received: from ifrance.com (vlt4-17.n.club-internet.fr [194.158.109.17]) by relay-4v.club-internet.fr (Postfix) with ESMTP id A58771689 for ; Mon, 24 Jun 2002 00:09:57 +0200 (CEST) Message-ID: <3D164B39.55763DB8@ifrance.com> Date: Mon, 24 Jun 2002 00:27:05 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] [Very] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> <20020621014350.22549@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I think the biggest of our problem is what whygee, Micheal and I think about the register system of SIMD. Personnaly, it wasn't clear for me. To keep things easier to understand it will be better to think of the use of a 256 bits registers set. Because 64 is a big illness : the biggest format couldn't be used as SIMD and ease a lot of thing for inter-chunk operations. For me, a 256 bits should handel 8/16/32/64 bits (the size of chunks) in integer and 32/64/128 bits for floting point unit. Pointers are 64 bits. Full stop. Load& store unit handel only a *single* load. So there is 4 x 64 bits chunks (that's mainly this size that make me use of 256 bits registers), 8*32 bits, 16*16 bits, 32*8 bits in integer and 8*32,4*64,2*128 bits chunks for floating point unit. You can absolutely *never* make a "global" operation on the 256 bits registers. Otherwise it will slow done all the cpu (it's sure that some wire will have to cross from bit 0 to bit 255). In that case, we will need powerfull chunk manipulation operation (it will be strongly used by compiler !). [partial write] The partial write are only usefull for partial constant load. It's an overkill to introduice raw dependancies but what about disabled the bypass facilities for that particular instruction ? It does add nothing in the cdp. The instruction still use 1 cycle and 4 instructions of that style could be handel in the same time... hum, i just thing that we must keep some more bit in the scorebord to handle that cases... Uh, bad... 1 bit for 16 bits chunk for the scorebord ? It remind me the problem of partial write false dependancies of Intel chip ! Michael Riepe a écrit : > > [...] > > > Ok, that's a point. Then let's use the accumulator solution (where the > > > shift is moved outside the Xbar/EU complex). It also has the advantage > > > that it can't be abused as a `fast left shift' ;) > > no ! loadcons is loadcons and is not a unit in itself. > > otherwise, one has to use SHL instead. > > Who says it isn't? As far as I am concerned, the current F-CPU > specification is not cast in stone. If there are mistakes in it, we > have to correct them - and believe me, partial writes (and partial data > moves) *are* mistakes. There are others - like the `mac mistake': the > mac and mul instructions use different result formats (mac results are > widened "if the destination register is wide enough"). Since `mac.64' > will behave differently on a 64- and a 128-bit F-CPU, this clearly is > a Big Bad Bug in the specification. But there are always alternatives, > and we should at least consider them. AND we should take care that we > choose an alternative that is easy to implement. KISS principle. > I really strongly agree ! nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 24 00:31:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17MK9w-0000qn-00 for ; Mon, 24 Jun 2002 05:04:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Jun 2002 05:04:56 +0200 (CEST) Received: (qmail 457 invoked by uid 0); 23 Jun 2002 22:31:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 23 Jun 2002 22:31:33 -0000 Received: by moria.seul.org (Postfix) id 3BCEB146D5F; Sun, 23 Jun 2002 18:31:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B307146DFD; Sun, 23 Jun 2002 18:31:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a152.home.uni-hannover.de [130.75.232.152]) by moria.seul.org (Postfix) with ESMTP id 54F64146D5F for ; Sun, 23 Jun 2002 18:31:29 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02510; Mon, 24 Jun 2002 00:31:27 +0200 Message-ID: <20020624003127.47646@thrai.stud.uni-hannover.de> Date: Mon, 24 Jun 2002 00:31:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Call convention resume References: <200206231410.57519.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200206231410.57519.cedric.bail@free.fr>; from cedric on Sun, Jun 23, 2002 at 02:10:57PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jun 23, 2002 at 02:10:57PM +0000, cedric wrote: > Hi every body, > > I will try to do a resume of what has been say about call convention during > the last week, before updating the manual. > > R0: zero > R1 : number of parameter (for debug and security) and return value I still do not agree with that point. It's a waste. > R2-R15 : functions arguments (call-clobbered) > > R15-R31 : temporary registers (call-clobbered) > R32-R58 : local registers (callee-saver) > > R59 : return adress > > R60 : pointer to the Procedure Linkage Table > R61 : pointer to the Global Offset Table > > R62 : Frame pointer (Function Entry Frame) > R63 : stack pointer after which the parameters after the 14th are push in > reverse order (Function Entry Frame - number of bytes allocated) Better make r61 (or r63) the return address. Statically linked programs don't use the PLT and GOT pointers, and we don't want to have a hole in the middle. The stack pointer is always the end of the allocated area on the stack. If a program uses memory from the stack, it MUST move the stack pointer. That way, the operating system can tell how big the user mode stack is. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jun 24 02:21:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17MK9x-0000qn-00 for ; Mon, 24 Jun 2002 05:04:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 24 Jun 2002 05:04:57 +0200 (CEST) Received: (qmail 23132 invoked by uid 0); 24 Jun 2002 00:23:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 24 Jun 2002 00:23:34 -0000 Received: by moria.seul.org (Postfix) id 1F5B0146E03; Sun, 23 Jun 2002 20:23:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 09641146E37; Sun, 23 Jun 2002 20:23:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id B079D146E03 for ; Sun, 23 Jun 2002 20:23:31 -0400 (EDT) Received: from LocalHost (80.15.61.111) by smtp.laposte.net (5.5.044) id 3CFD28F90012EC31 for f-cpu@seul.org; Mon, 24 Jun 2002 02:23:29 +0200 Message-ID: <001901c21b15$53f937a0$0100000a@LocalHost> From: "Christophe" To: References: <200206231410.57519.cedric.bail@free.fr> <20020624003127.47646@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] Call convention resume Date: Mon, 24 Jun 2002 02:21:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Monday, June 24, 2002 12:31 AM Subject: Re: [f-cpu] Call convention resume > On Sun, Jun 23, 2002 at 02:10:57PM +0000, cedric wrote: > > Hi every body, > > > > I will try to do a resume of what has been say about call convention during > > the last week, before updating the manual. > > > > R0: zero > > R1 : number of parameter (for debug and security) and return value > > I still do not agree with that point. It's a waste. Not only it is a waste but it is unefficient. Why ? how many arguments for such function : int f (struct a _a) ? 1 or the number of words necessary for struct a ? it doesn't make a sense to have one. If you really want a debug info, pass a parameter signature instead, something like C++ functions signature but just for parameters. So if you call a function with three integer arguments then passing the string "iii" (for example) would be more precise and usable for debug than just passing number of arguments. Personnally i would drop it. > > > R2-R15 : functions arguments (call-clobbered) > > > > R15-R31 : temporary registers (call-clobbered) > > R32-R58 : local registers (callee-saver) > > > > R59 : return adress > > > > R60 : pointer to the Procedure Linkage Table > > R61 : pointer to the Global Offset Table > > > > R62 : Frame pointer (Function Entry Frame) > > R63 : stack pointer after which the parameters after the 14th are push in > > reverse order (Function Entry Frame - number of bytes allocated) > > Better make r61 (or r63) the return address. Statically linked programs > don't use the PLT and GOT pointers, and we don't want to have a hole in > the middle. > > The stack pointer is always the end of the allocated area on the stack. > If a program uses memory from the stack, it MUST move the stack pointer. > That way, the operating system can tell how big the user mode stack is. > I totally aggree with Michael; something like : R63/62 : return pointer (RP) , mandatory R62/63 : stack pointer (SP) , mandatory R61 : frame pointer (FP) , optional R60 : GOT , optional R59 : PLT , optional R14 should point on the first argument pushed in stack, so we can access it as an argument pointer (AP) R14,R61 and R62 all point on the same stack indeed. Personnally I would have used R60 for AP instead of R14, unless there is a real reason to choose r14. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 24 09:02:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Mcvx-0000YJ-00 for ; Tue, 25 Jun 2002 01:07:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Jun 2002 01:07:45 +0200 (CEST) Received: (qmail 8832 invoked by uid 0); 24 Jun 2002 06:54:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 24 Jun 2002 06:54:37 -0000 Received: by moria.seul.org (Postfix) id 077C5146BE9; Mon, 24 Jun 2002 02:54:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C38FE146BEB; Mon, 24 Jun 2002 02:54:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 6835E146BE9 for ; Mon, 24 Jun 2002 02:54:36 -0400 (EDT) Received: from f-cpu.org (kdl11-99.n.club-internet.fr [213.44.9.99]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B0FC716BB for ; Mon, 24 Jun 2002 08:54:33 +0200 (CEST) Message-ID: <3D16C40A.C04C6AE2@f-cpu.org> Date: Mon, 24 Jun 2002 09:02:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] good news Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! i have worked hard this week-end. First, you can now mark the register set as "finished", or at least, "working". I cleaned up the code according to the latest discussions (removing the partial writes) and it is easier to manage now, it only took a few hours in fact. I don't have a "serious" testbench but it compiles and elaborates without warnings. The second, and more important, news is that you don't have to care about tools anymore ! as promised, i have written a tool abstraction script which now understand Simili, Vanilla (without libc5 by default), ncsim and Riviera (though not tested yet). All one has to do now is source this script and call the few functions that it defines with the correct parameters, the rest is done automatically ! Not only it means that we don't have to write one script per tool, but it also means that portability is not an issue anymore : you can add support for ANY decent tool with some bash lines and run regression tests, whatever your current tool(s) is/are. I will also distribute it in a separate file as well, because it can be useful outside of F-CPU. If you want to play with it, it's in my latest snapshot (not yet online, but look anyway) under f-cpu/vhdl/tools.desc/ and the directory f-cpu/vhdl/registers/ contains test.sh which shows one example of use. Now that R7 is done, i have to rewrite the ROP2 script(s) and begin the Xbar unit. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 24 14:01:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Mcw3-0000YJ-00 for ; Tue, 25 Jun 2002 01:07:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Jun 2002 01:07:51 +0200 (CEST) Received: (qmail 31647 invoked by uid 0); 24 Jun 2002 17:16:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Jun 2002 17:16:13 -0000 Received: by moria.seul.org (Postfix) id DF786146801; Mon, 24 Jun 2002 13:16:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5293146807; Mon, 24 Jun 2002 13:16:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id E34C7146801 for ; Mon, 24 Jun 2002 13:16:08 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00488; Mon, 24 Jun 2002 14:01:26 +0200 Message-ID: <20020624140126.51273@thrai.stud.uni-hannover.de> Date: Mon, 24 Jun 2002 14:01:26 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Call convention resume References: <200206231410.57519.cedric.bail@free.fr> <20020624003127.47646@thrai.stud.uni-hannover.de> <001901c21b15$53f937a0$0100000a@LocalHost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001901c21b15$53f937a0$0100000a@LocalHost>; from Christophe on Mon, Jun 24, 2002 at 02:21:30AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jun 24, 2002 at 02:21:30AM +0200, Christophe wrote: [...] > > > R1 : number of parameter (for debug and security) and return value > > > > I still do not agree with that point. It's a waste. > > Not only it is a waste but it is unefficient. Why ? how many arguments for such > function : int f (struct a _a) ? 1 or the number of words necessary for struct > a ? it doesn't make a sense to have one. If you really want a debug info, pass > a parameter signature instead, something like C++ functions signature but just > for parameters. So if you call a function with three integer arguments then > passing the string "iii" (for example) would be more precise and usable for > debug than just passing number of arguments. Personnally i would drop it. If you want an argument check, do what C++ does: add the signature to the function's name, and check the arguments at compile/link time. The only place where a run-time check may be reasonable is in a varargs function. [...global registers...] > > Better make r61 (or r63) the return address. Statically linked programs > > don't use the PLT and GOT pointers, and we don't want to have a hole in > > the middle. > > > > The stack pointer is always the end of the allocated area on the stack. > > If a program uses memory from the stack, it MUST move the stack pointer. > > That way, the operating system can tell how big the user mode stack is. > > > > I totally aggree with Michael; something like : > > R63/62 : return pointer (RP) , mandatory > R62/63 : stack pointer (SP) , mandatory > R61 : frame pointer (FP) , optional > R60 : GOT , optional > R59 : PLT , optional > > R14 should point on the first argument pushed in stack, so we can access it as > an argument pointer (AP) > > R14,R61 and R62 all point on the same stack indeed. > > Personnally I would have used R60 for AP instead of R14, unless there is a real > reason to choose r14. In principle, we don't need any pointer for it if we specify that additional arguments (beyond R1...R15) are found at the top of the stack - that is, in the place where the stack pointer points to. R62 also becomes the argument pointer in that case. This also makes things more clean for varargs functions: just push R15...R1, and you get a contiguous array of arguments on the stack, with R62 pointing to it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Jun 25 12:50:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17MwvM-0000Fl-01 for ; Tue, 25 Jun 2002 22:28:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 25 Jun 2002 22:28:28 +0200 (CEST) Received: (qmail 32277 invoked by uid 0); 25 Jun 2002 10:50:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 25 Jun 2002 10:50:44 -0000 Received: by moria.seul.org (Postfix) id C5F531467EE; Tue, 25 Jun 2002 06:50:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 849FA1467F4; Tue, 25 Jun 2002 06:50:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 01A0B1467EE for ; Tue, 25 Jun 2002 06:50:39 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix3-2.free.fr (Postfix) with ESMTP id 32062180F6 for ; Tue, 25 Jun 2002 12:50:38 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 1DECB87396; Tue, 25 Jun 2002 12:50:38 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Call convention resume Message-ID: <1025002238.3d184afe11169@imp.free.fr> Date: Tue, 25 Jun 2002 12:50:38 +0200 (MEST) From: Cedric BAIL References: <200206231410.57519.cedric.bail@free.fr> <20020624003127.47646@thrai.stud.uni-hannover.de> <001901c21b15$53f937a0$0100000a@LocalHost> In-Reply-To: <001901c21b15$53f937a0$0100000a@LocalHost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 163.5.255.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > On Sun, Jun 23, 2002 at 02:10:57PM +0000, cedric wrote: > > > Hi every body, > > > > > > I will try to do a resume of what has been say about call convention > > > during the last week, before updating the manual. > > > R0: zero > > > R1 : number of parameter (for debug and security) and return value > > I still do not agree with that point. It's a waste. > Not only it is a waste but it is unefficient. Why ? how many arguments > for such function : int f (struct a _a) ? 1 or the number of words necessary > for struct a ? it doesn't make a sense to have one. If you really want a debug > info, pass a parameter signature instead, something like C++ functions > signature but just for parameters. So if you call a function with three > integer arguments then passing the string "iii" (for example) would be more > precise and usable for debug than just passing number of arguments. > Personnally i would drop it. I understand your point of view but I am thinking that with this we can remove all the "format string" like bug, and have a better security in the system. I am not sure and I need to read more documentation before. But it's sure that when we say a parameter, we need to clarify if it's a number of register, or word, or something else (perhaps, we have some binary compatibility problem, when we change the size of a register) > > > R2-R15 : functions arguments (call-clobbered) > > > > > > R15-R31 : temporary registers (call-clobbered) > > > R32-R58 : local registers (callee-saver) > > > > > > R59 : return adress > > > > > > R60 : pointer to the Procedure Linkage Table > > > R61 : pointer to the Global Offset Table > > > > > > R62 : Frame pointer (Function Entry Frame) > > > R63 : stack pointer after which the parameters after the 14th are > > > push in reverse order (Function Entry Frame - number of bytes allocated) > > > > Better make r61 (or r63) the return address. Statically linked programs > > don't use the PLT and GOT pointers, and we don't want to have a hole in > > the middle. > > The stack pointer is always the end of the allocated area on the stack. > > If a program uses memory from the stack, it MUST move the stack pointer. > > That way, the operating system can tell how big the user mode stack is. > I totally aggree with Michael; something like : > R63/62 : return pointer (RP) , mandatory > R62/63 : stack pointer (SP) , mandatory > R61 : frame pointer (FP) , optional > R60 : GOT , optional > R59 : PLT , optional I agree with your point of view for the last register, but I think that we didn't need anymore an argument pointer and that we use the SP instead, with a reverse ordered list of argument. > R14 should point on the first argument pushed in stack, so we can access > it as an argument pointer (AP) > R14,R61 and R62 all point on the same stack indeed. > Personnally I would have used R60 for AP instead of R14, unless there is > a real reason to choose r14. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From adam.r.hunt@gmx.net Tue Jul 2 22:20:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17PVhW-0005WZ-00 for ; Wed, 03 Jul 2002 00:00:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 03 Jul 2002 00:00:46 +0200 (CEST) Received: (qmail 6145 invoked by uid 0); 2 Jul 2002 20:20:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 2 Jul 2002 20:20:58 -0000 Received: by moria.seul.org (Postfix) id E97C9146915; Tue, 2 Jul 2002 16:20:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCE74146917; Tue, 2 Jul 2002 16:20:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by moria.seul.org (Postfix) with SMTP id 252BE146915 for ; Tue, 2 Jul 2002 16:20:56 -0400 (EDT) Received: (qmail 24702 invoked by uid 0); 2 Jul 2002 20:20:55 -0000 Date: Tue, 2 Jul 2002 22:20:54 +0200 (MEST) From: Adam Hunt To: f-cpu@seul.org MIME-Version: 1.0 Subject: [f-cpu] F-CPU Status?!?! X-Priority: 3 (Normal) X-Authenticated-Sender: #0008562179@gmx.net X-Authenticated-IP: [199.101.15.180] Message-ID: <30930.1025641254@www41.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I've just discovered the F-CPU project and I am very interested. One problem. I have found numerous F-CPU web sites none of which seem to be up to date. Is there an official site? The only site that makes any sense to me is http://f-cpu.tux.org/original/ but it hasn't been updated since 1998. Any help would be greatly appreciated. Thanks. --adam -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 2 23:02:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17PVhX-0005WZ-00 for ; Wed, 03 Jul 2002 00:00:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 03 Jul 2002 00:00:47 +0200 (CEST) Received: (qmail 23486 invoked by uid 0); 2 Jul 2002 20:44:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 2 Jul 2002 20:44:45 -0000 Received: by moria.seul.org (Postfix) id 42221146817; Tue, 2 Jul 2002 16:44:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F424146916; Tue, 2 Jul 2002 16:44:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id A8352146817 for ; Tue, 2 Jul 2002 16:44:43 -0400 (EDT) Received: from ifrance.com (vlt4-163.n.club-internet.fr [194.158.109.163]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E79B916B1 for ; Tue, 2 Jul 2002 22:44:40 +0200 (CEST) Message-ID: <3D2214EB.2F3595E9@ifrance.com> Date: Tue, 02 Jul 2002 23:02:35 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU Status?!?! References: <30930.1025641254@www41.gmx.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N In fact there is no real web master. www.f-cpu.org are the "official page". One day it will point on f-cpu.seul.org/ . They were a tentative to instal a kind of news system using a php program on f-cpu.tuxfamily.org but i just see it was closed. This kind of system could be used as a "resume" of this mailing list. But the main document are the not so up-to-date manual. nicO Adam Hunt a écrit : > > I've just discovered the F-CPU project and I am very interested. One > problem. I have found numerous F-CPU web sites none of which seem to be up to > date. Is there an official site? The only site that makes any sense to me is > http://f-cpu.tux.org/original/ but it hasn't been updated since 1998. > > Any help would be greatly appreciated. > > Thanks. > > --adam > > -- > GMX - Die Kommunikationsplattform im Internet. > http://www.gmx.net > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 3 00:53:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17PZYX-00085T-00 for ; Wed, 03 Jul 2002 04:07:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 03 Jul 2002 04:07:45 +0200 (CEST) Received: (qmail 2928 invoked by uid 0); 2 Jul 2002 22:46:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 2 Jul 2002 22:46:02 -0000 Received: by moria.seul.org (Postfix) id 372C2146927; Tue, 2 Jul 2002 18:45:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8A259146926; Tue, 2 Jul 2002 18:45:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 95712146922 for ; Tue, 2 Jul 2002 18:45:44 -0400 (EDT) Received: from f-cpu.org (kdl16-3.n.club-internet.fr [213.44.18.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id A638516A3 for ; Wed, 3 Jul 2002 00:45:34 +0200 (CEST) Message-ID: <3D222EFF.2F768742@f-cpu.org> Date: Wed, 03 Jul 2002 00:53:51 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU Status?!?! References: <30930.1025641254@www41.gmx.net> Content-Type: multipart/mixed; boundary="------------8290224CF74C58DE3EB6DEBD" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------8290224CF74C58DE3EB6DEBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, Adam Hunt wrote: > I've just discovered the F-CPU project and I am very interested. let's hope you will not be afraid by what you will see :-) > One problem. only ?... that's good news :-/ > I have found numerous F-CPU web sites none of which seem to be up to > date. Is there an official site? The only site that makes any sense to me is > http://f-cpu.tux.org/original/ but it hasn't been updated since 1998. Currently we're very lazy... well, at least those who write VHDL (it's already very time consuming). The others can't seem to find a place to start... After several critical server failured, daique tries to move a "daCode" site to f-cpu.seul.org/ but the admin doesn't seem to answer database access right requests. However, look at the attached schematic view for a rough idea of what is already done. > Any help would be greatly appreciated. > > Thanks. no problem. > --adam WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------8290224CF74C58DE3EB6DEBD Content-Type: image/gif; name="FC0-02_07_2002.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="FC0-02_07_2002.gif" R0lGODlhDwKyArMAAAAAAP///wD/AP+AgAHS/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACwAAAAADwKyAgAE/jDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//A oHBILBqPyKRyyWw6iYOBJvpMAq7Y1ZWF3Qa63i9gEiaDQeUWeGzOitM+OEVu6bbZb7xdFO33 qy1UGYKARXQnhyJhW4tsjXV6eByJGJIaco1elBKWdSiJm5pjomKco46dH4SFK6usTZsjsR2Y kaZmkLgxs3C9qJOpujKzt6Skc8Edq39/HMyEfgHNEn5S1FTT19PR2dUT1a7RFd7a0q6vKr6i ZXvFkY9ZtRePpbcV9HvtmZJ27fbIue79EsjITb54A/0FPFZQmMB6Des5DBFO0LkLzZZZtAbN mjmO/h7HhcwY8tvIkiJTXjMJEl2eZB586WL4y2DCgqcCPrRHDyBPWxBv/pQ4kei/mZaMOUI6 9Ng8oaV6+lR6lBjGkh2VnTRpoeJKrl23btA4RSzYrOj0IDojkebQoG+dFn0J1ChdYW7hGuXF VuZedvxsNg0FlSokoU7dkPD6dazZc+BIUugorrHIyubKTsba0nKhd2ti+b1LOq/pTvJ0jvap d51g1htWv0WWOGdrVKAK10yFz7bUEYwzO3uM8qLljWA9NyY7yOxXtK/UZoB59J/s23EHwp77 225b3TqrT0dNXrwp3+CJKl4IfrVhuYs5Jy/bWbnw58jxOz/LXFpYlfdB/scKW5UAo1p6OGU3 G2sR7WRXathF2GBREB60U0SnvQGXXwl+V95U6HmnSmQfSYEZBthQdiI4XGXz0YskbmaiRjSS U6JH3Ljo0iWxfXheYIB5CBR8d2hHEISw6QMabXWJR0df692BlGLvvcZgiOcdZtM+P1oFg3Hx 7SimImMS4WWZ84TXI3UugQkcSmjGeY+cP5xJ5xdPfWCnEzaa0OedTBA4HaA6REmoInzteeii gAgqHY+MRirppJSmRcYcRa7BSaWcdurppzOEpg+mmw7KJqiopqoqqjA9+hKPp64q66y00tmq QnomI+quvPbq66/ABivssMQWa2yxSxyr7LLM/jbr7LPQChoTDYfEWusO1n6SbGTcduttNQB8 K+645JZr7rnopquuH9mWGuqg1x7Rrgnz5hDuuufei+++/Pbr77/etltvl5PAG68hNwycMMDf 6svwwxBHLPEAAgOznqsFZnywmQlvOzG7H4cs8sjjVhzbpSjT1ZfBGwuhMJlKOPyxzCTXbPPE JveaMp7upqlryxzb8HINNEtc9M1IJ71vxa3uLO2cPwPtcscxk3y00lhnXXIIo1yCa0xRSw3E 0Gh4LPLVWqetdh8Ck22gxmLHQbUVVq9t991sc+12wXDHzcPetJgdMtp4F16zybJ8PWfffhc6 NxKEAxy54ZTjzLXF/uzszLjmjdv7uLx1Vy66zYgbzE+mK2/eudCfGzG5v6+PLju/OfPqNOeY hr2656xXPXLsswefLtOQ8kywqSzv3vougs8s/PMPEz+eoWAnrzzRy5sZOvTc0643tbpfj33v dP/e/fn4tj1+muJn/wLgMAC/NPr0o1u63tQvzn7761PbPM71CyC57veUi+FOf57gX//e5buz CfCBAbvcyXoGmtD0DIEKZB75ILc9CHowb2VT2ahS1rTwZfB97nNZBz/oQelpDEigMF4CT6jB BbpuhSx8oAsLuKdq0XAYKQyC/NKXQxaqL1Qm/KEWgjg2HBaxfkdk4P6UqAYm1smJT0Qf/gFz lT9STZGKS9wg6MyXRR1K0GsGvOAXvQjGMNrQEFgsI/e2qL/TdUlTMsRgG7UlxhuSUY5QlKDO KHjATSVxjyWA3wTL50BABrJsTaOg4gxpPUQm0opxiKMjg7dDLQ3Mh5ZMgSKLx8E/brJ7UdzF IUN5Rv81cHCn1OL3XLlGVsLsjdozZSyfR0daTLKQowRjMFU3hCGuy5i7TFsvi+RFNq3SltPq Ixx1mczZLdNddhShQSoJTT1hsgfIHF41oVe7Xd1OjbnjZjcDJ81cNnKcnLxcJGX4tHQSc52L pGUp3wlP2XXySJ98Jj7V6YJhakGT/bxbKuMn0IHWMn7/M1pC/q05SynO0KHRxGUxETpRtV0T jaEgKEYvWgkL3nKfsOyo6D7qqEICc6TelMVJx8hPlRaOpefUpiZEClOX5pOdjEypTQ1XTlHl tIQ87WkeQxjToDpvqESVZ/FgiNR7KhWdGc0qTdUVu3BCdWZSnV4PG6rUT87Uj8csl1e/arSK qjKpPXWmSVu5VXEOkK14WyhErXpVg5IUrQ3blVrxqlC6ouGXWF3qVfVYQ5TatWSEtRtL/YGx hyp2sT79ERuB6lj7DTayHjXsDLM5SLLGlW+GnJdfRTm/u4JWmYK0HSETiyfTwtSZ22lqZyX6 Wq39s5lMqqplMYvbzMIVnGq9lzHX/hqxo2HBs4/05q262KPjjrS4tP0pYAMWBeVCV6GR0Zf8 mAvbw4LPukT7JXX5agXUXpazde2Wdyn2XcmCQ2bAI69v3dpYxsrtgJXV7hPkalSm7pZb4Zqv ufTLMJqh7blsu0J3KYZfCftTtGBb73tXO1PU+Je9kPvm3wYIhsfaF1zyZduEJ2xh8ap4dJNN 43tfGjTO6SoN2wQMhxEhYmxxFGkOhix9QbbiIRu5cjidrU6XAuLPeXh/j/INNmN2SQPHl7fg RbF8IYzfF1MYwiuNrTmVLNy/1kmP2E0KygJczCrr9spaLnF91xZkIhtZwUV2sfB+S8Lgwgq9 +lzqjRdR/sfjhZgEH70id4/MaCFnWctHVq6CE+xlPYcZkiANKKAtKujFRbnQM67xWQXsTgQX +dSufTS4LMwuSne3xV7+MkXNi8RNAxHAfW7LpaTD5qkhGsMbXfSdTdzbpOkVhU0Wmnpx3LU2 TDlLVF7TXLW63fCKas7FvlmiS6ph2163x4X6cbbbamUekta9HyYuuO0l7nFDLMn0RF0+bL1O 1f76lU91t7bFXOB407bZw12svWWK70WzesH6BnJYX+hn5CUbowMfdakNjmpHJ9xqCzc3or0N 8RCeacf0ci2eU33x3/H3fRx3qLWYvG3kCnnkFi/54E6O7ID3NaZMfnO1t1zx/pjL3HLl5mJI H65ynGfXzBMXVzgZ/POGAZuZuSZlugVO64gfOMVcbfrZnv5sbMo25QMFeaibiPCsax2sHpet v2cMcKRjduxuvHr0zo526U614QUCOz7FLnZEt5vuw8u4JzdO726uvN/o3rm1r01ywDeY5mrQ e72Z2uupk13ptHN8cyFfRaKH/c05J3WwMd9azT8+6Bkeus3LCvqjuz6TPse26b2HerwbD7tu V7fQQy96FcY+X7M/vc5H28yvFx6afI9oeDMf/H8Vda7ndvjqT9vO0Qu1+bS3u+ls7wnJG/6w iM29EP+O/QhiWqya9vzejW51ON9XsI0vP1c5rwXv/iPf6HDfrOKF3Wisyz999Bd3lsd60cR7 iTdNZddzpvZ/AFh7mIN7A0h9Bdh+++d//beADDh/Dmhot3eAr3db64YD4+UwXZWBx8R1HUhC xqd+k9d7G3h5SudqCrh8Jhh4aTdma1dmEQiCLjh8SYeBX5ZfNWiD2sdwUJd3x2dLEOhmctdg Q2g/ggdQhMeC3ydteOSD1pdvTzhAAShK9qeEHihxWRhYa/BZW8iFtMZp+vd2R7c3fScLZmh2 Z7g1L4h+YfiG17OE9+ZUFiiHc+h0L9hSbZiErJR8BQeEfviH8oWCrlJBePSFhRiCC/N7CaiI i3iD/RZ9SEiF91d9vkeJ/vFnieAShcB1hD5DiKFkiHwYMKERh6J4X6RoimkofjfnieNHTa8I QrlyXpwIhrYIg1qYi+zShaKEipakik0oOcIYXihoh6KHh8qDjO43d8s4ioFIWZkFiakoiUJD fk8Ib6S1gtPHgxr1iddXjRTDb9BXips4jt/2i4pWU9XIZ133KtJHiwRYjrcoj8tIj/aIKMaI SNJYgU6IjrpYPbXWi5EIj7DHj8J4bAWFftEykRRZkRY5kAg4OBe5kRzZkcTSjNymevgogYFG kJLDhu44doKokgG5Rxj5g5uHkjs4iGQmjiNZJ1eoIQSBJi85huRWBdNmKBoWbTindpp4igpZ /pJRl4Ji0pPmWHcDtn1L2SixWI/1tGstuVckxXvQGJEM6XJbR5VfxJXRUZX/yHldiWHBkJa3 po/ACHRAqTpsyQXEuBZZiXKpc5Nx+ZUjZnKN8ohJOTZ1yWOB2Zb+NZdaqZQw+W6fIZdl0nKD 94yw4Ji2wo1Eg3FiiXSImQ6MiI00mZJ/0zdk2ZSWSS2YuZdbeUGbSXBYuJSOmJd6CU5SWY8u 4ZT7OHOZSXxTiZoTiINH2X13WVA5KZSK4jqlGSqnOWDDqQ61aZaNqF4bJpMzSZirGJPS+YGU 5IwAWZgueZzDkJzSCZFcoI3H6J27AJ4yKZ50yZ1tZJtv+ZPXCZlS/iiZ14md1JmMzlef9klg mfOZsVl0fOljflmf4Fh8Y0aeAmme8YOeKPl8V/ibUCORHjmhFFqhHZksFpqhGrqhzuKcTgOd qzmY48EpvEEp1BGiiUQ2xdmc0zVWjami+ceToNmcUvei2oKiCcNhK+o4MQovOKqGPUqaNbqX MBqkY7Kj8JUsxrVIP9pf9rkjJ2opT6qbk6IwV7mGhzalCNSkNYelgBKlA+KlusWliRmSEPqf oSmmWkWm6zmdUNqD8uKmqSkpaWagBcamNsZHanqkMyqlwWmYWqp/eBpGg5SDf6akaMpYg3qf S/qYcCpqjVpJi3qjdyeLEUqUcpqpb5qo/mU5pO3Vp3tKKG0XmdvZmIxKp6Aapp6am3tIojo6 qZwaqTIaq6b6pyKop67qllnKhFWaqrXKntiCq5UyVt3WqfTSKSXaq6vKm606rA/IjrYKqKxp or7KqrTqa8fqKXWqggdqrLyKqtfKrOEqmKeqrIV6plipqtnqrOPqBGC6qetKomz3odQ1qlFZ roySrOAarQFarZbSoun3q826r6E6q/yqq496J0haXer6rZGirw+bsJg6sFW6YxzKLJ9wsRtq bhp7oZnWsceSsSCroRs3lHFgVviaXmmqqQ3rr+mAsvFqL3i6kmxqr9Qmhu/SlRCbrxILRDDr sNgzs0eldmn6/rMU60o667Lu2rN7ZbTTSjWbea7Q2q635LQ4q5VJS7WBwrReaaSBKqvF+LWc OZtnqbUIqaW44Ro6ZrNvBbZjy7ICa7aziLJQQlnxIILZtLJmurSZOqpsGxitk7VwW6pyq6Zp +WRkomZrmVtOCqt827dIiWbSJLgFa6dAQkyVB7RuG7aQC5x/BXI7Kz6L+7Q8QyCnwAi4RLmy ulOkEmCnEkzveqt9+mSmmwdeK3FzGVAmq5i3C7jsEyRAKrYOmy1/S5up1RtcornCK4Y/+yRV oaMH23s0K0TLWqn3uLzLqrpPCrH5059MuXZX+4bzdEZRirhlOrjCCmpeh4PBu7mh/lei5tu1 wJqkRpoUZ0q7OZWy2Huzletpa2ivfhW74GSUU4u+PWhWigutC2tz2lu/m6Vmkvu9tqu8t0u6 ieq3hjoXbxu9bkZV1Zu+s6symsUkFQynDRxxpwPBgmq8mxtqoEu/gWNSCtEP56u0DLW7mGS1 IAmSJwwzEOy6mrgUect1Fsu/YdiaFNzCrLJyR1uHs8i1nNu/GgJ98qAkdRF+1btaxKDDTryL Rtyv1NvFgws/8imA+zuZHxyzR5zGUPxwuVuyMdR5YizFSkuBk0utbGzBUFykUfzFnji9LVkv XIzEhGzDQee4IEzHfqx+fKy/HExQjShvOAzDa5yEbjPI/tJawnFrwJ17tZQ8x0pcf75ZwJ6k LClqLCK7LKecoRw7shZphc+yyh+5FhgLxyTLpNznr1YqyIkMyhoMpIjsyKO0y3rsy5q6wJ58 pZX8NjJlxztcUpeEh6F7KAKcsdHsycvsNdccrLy4zQRXxrHKtuwkvoaMqAEpznwDziyLzhME jcgMzVVmpZHayILUwbLLyWhsjAbYVMTby+lszzJry4fKmvLcqPTMz0yIkcGsxgacuaTExI5M tq1EzgBLyul6UgW9pAfNWRl9xkO60BR8yYqsmouczVvKq32HzpF8R7AJ0Ge5TcVcyLjMgTDN o/i8tXmM0DTNutjcxlHnKDzN/s1Su5vhmhD+m509ndMZE9Sle9G8c9PmzJ5G3bpObcwj3bqj qRZsua0cqJBdM7pa3cQy/WdgXdXLA9JircmnWNZI/cy9+NVLbdb3rJ1Jbb1sVNNuXa2uSxse PXxoHdNqTaV3zdRjbcm4c7mBncReyLn2C1yY/MkZ1dh91sPKmpUY473sbNjUKdlTttWvytgP 7CA1utH9rGSqSdkEW84rrTmica3TTLYqbB45KtDXu4eRzNk/ddCIc9uiPdehbK1Q/WlVzQtj HJvC3dYiwjoVTdRyzdFrdtS19WFD/LSvW4o/PNx3XNlebd3QjcFwQ8/VnWvXjdwpPa812a22 nSVU/vy+Mx2vEF26OGHFpg3MeIyKvBbfVBLU79rI740bIgxt081AQ83C6xyoDt3Um13P6X3W 9R2Y+xzZ46ynOePSTPScxXqsBc3ERcrLGf7UV92yVJvZPlqE8dzMJW7TdJ3XanJ+XozhKerN DK7dhqwoIs64ZsmwJs7NCRnRI1rX8KzYP+7bfT2xZkvMPp4nDH22hfLZZurKTv7kUB7lUj7l VO4rIprL9lTOwqSgXdq+ukfipCrBl6rlVOSeZwbG68fiUGa5gDm/SmTm/4Ww5NibmWjRXvrX 7CrneuvlVBeI9CqSUL3laM7lSg2ghKzM9IlyhDvJyrbizKyTv13YOs67/tbsVoyusr3tS3wt xRZLVuMrp8ctyj00o6EO57IJj5+uyKH+speuWLxslVeeODwVx6Qe6aJpwa9+Waa+55mc6XdO 0P2V66qOa0+8ewMtfgB3EJgwwaaYttAb31ri6sxO012965PO58m+JfAbJYKI6MUI7Uci7TPs mdLij4DcjvjI3hv2m6teQ95LT7zB7sxt7SjO56ViRzc2te2OtXnru6J92fPuoed9p0m1zyY0 umIunCvcaZ9rhLpO6HJM6c/tdvH7093M8BXP8FSK8HS+jsz966g1QmvkiB+/wWpkgKFL8gRO 7x5u77dHJdaj8gnfpnmq8QtPGjNfoJZK8fT7/uAYr74BTNXQfdgJpMJsxvJC7qS15PP4y45B P/FC/79FD/Ru/KxNHN74fvJT7/TBrvWSNPIkvfIQT/Mur+4ov/UWX6Zn//UNn0f7HqSdPuuu kVsXo7a11SHCeQZ1vyTMhth6P8XLPuiC35lpS/c6RjCnC+mRp/eHr1l9v+l/jxCv3ePDgKDd OfgST/bpGetdPeaF++Zjb8ZKz4bm7pnzavntGfom3+tvZ+5Di95kDvp91Oq/bNVH/nmY6PEE DvIE6mQ05tO2Dtm1eOh/rodDXua+v8wijfkLeehYjLn6mdgcLd8jXP2n+9iiT/oqTriBjvxi ZPSsjdXDzvzbWOwK/u/mPwTRdhLb4x32GQ/8tt+JLY4/MYT6gv7PDjzYsMnx27v6nw8BQU5a 7cVZb979twAwEMUMQFHKJLXyHGN5pmtbZjdzj/N28gFXmGCQY8Qdb0tm0/lEwqI/KjV1vUqi 02fX+21yhT9xqOJjpbXrcbHHFJfBc3qdONphsWN29f63CxQc5DvieQNSWVFMXFRMccTD04PU IbzEBJMrBMzZswTMFB2l2bwxxUSFASVtde1Ajcua2Xq1vTULVCXcvYjDBb6NtWPMDT4elaMs VkL2K2121UtytontBWEequYW3FTriz7GRpT2qO2mnaSdvUNPh/9SPgtnHe85PLedD43X/s9+ 5qgYOHer/B2E86/NB3LEJJFhuI/II0aVSqCpGNDZsCkErSx7ZBCZkU9+GuL6NsvUSUOcxMFi 821fO3AEL/apyZLXQ5AZ+fzqF8zNNjQIRdLRyYpLUUn5XibztbCeTan+hikVCDRqtaFV6xl1 qcmhwq86SsJ8RVIlJ5trD1510a6csZF0t4UFm1IuWRU0L3piliWPQC2VNHpJemrrXaZW7KaD O0cbXmG+AtMD+/jPi7kkPDWK+XORaK+HuyS2tjifGqqh365D+q7uCY+mX6N1SvZZbpO7S+eW 6dkwWnOW0xxfHakst2vshpuRfQ9U48yUMfN+ObTItK7Ye+PG/ky8+njxMDvKrU0vulC7wMlb v76Luuu79XEun78q/9H3/cPr66gQ5JZZzrbi7GutP9RcOOOzshL0jDTXvDMmPQb9w/A/3HoS EL7DFjztk7OEyxDEfv5CzrgG+/orkYEsnIiSiDKk0UANVcvqKQ9rRGipMG4kxcTFeFTwobie AygoIqvzMSH7WhFSsyXzMlKy9aak8sIlAIuysw2TxHK85mLjL8wezSKwSvaSpFBKM+MZEx8k h7jyTTjtSW0jngp0085uODpyIOs4G9JPq/CsoUvF2OQTSEP/bEpLB4VLs85HuUIUGtCogQKf Rh29VE82OQwHxid3DLUyXUDVDzFv/lK9E0yDuJwMVEVh/XHVU7WU51VcIZU1xlrL2/VXlHwV cLiSXhxWN8mMZU5NeSyFNi1k7/tNQhvL7LXa2RhSdNhbvVVH19JaaMw9TcciF5g4J5lTCGrb FWXc79xI99Ngn6X3WIDOU3bQD/v1l1362kBP3xkNJhjKSGdljNR5Gx7E3nzP1ZYciym2dlSQ Ovx0Yo4Z5rewAbPK4+RErx05k8g6yTFThVsWy1xno9yY5nqlDWGvfVHV2VWbicWZ5aCNlhkK kY8+DWk0482VZOOeg5rpPi2rQ1yrdxraXac1hHBrJeNyrllCrxbbiZy/zbo8ddMuVAmABeXz bFbhjrpt/lGlbm/mtAGF+CeJucVb7a875htsv8W+qiePTKXMXsYPP1Dvp30qnFdiK4xZ82Iz 35Jyh7uOe/GtX54am6VB59Ry6RLfdT+8UUdsddZ57pZtpDbH9vZtN9XEdt+drVn3kj1Xbvh3 s/GZTsKHLxf2yneHPm/zAp00QOGrRz73113nfuV/JY3444HDX1T60dVHX8cLHQfZwO3bv9vw vcGnH/fne6dUK7Tz35/9jFc8AOpvbJ3zEtAK+LlO3Y96C/xZ95QWQAjWz3peI10FKTgaMgnL cR8EYQhFOEISltCEJ0RhClW4Qha20IUvhGEMZThC2MjJbL8rXYBKtyN+EK9+/pbSoffeIzn3 4bCBuLLbiuhmmiT+LIisKkMPecfA8+3QdOAiYmyyGKMD4u9STcyYiyolPih2MYo+7GLICPdE w4HxNW58VRO3eMUapSxNVYAcHR/UPTamUYH+OyC1QHSIOdqvTXrjTSELiUHyiRGQPOtj3aZo QQ89MnISXFceMcW/imnrOyYbJG1E1LwsYW9drROYFW0kxSJWco2YbN2kwLU+PAZJJJgz4iSJ QklgdTB6n0NCJP+HQ0va6nmJmY8qFvlJPYYOZod0JvAKtEy1hUtjqgwmLBW2klZO85gX7Aoa SzGiG4WTa4XiASnzFKGekcQ/zTKlFEQ5Q3rW054r/jwi2RLml5SBMm7Z1Mwc0dGXwlDRhuKA 5xvjyUn1bFCDuUxagyLGmF2yxUUzo2axDJPIai4so00LYvYG58eHNlOVT+IotnRIyIVNT5op tQZB/yFLJoFSRqVyJUlLihpWQiQ8TvEZS3+3IBX27JM0xQFSLSq7M2HFkUX8KMV4erOvfAag UoGmAsVpJC6JMaZ9GiU5SzlP1TlUg1OFRfbossSj3qSlTsrnOWF1K62VtJsJjAo/k2eSOTWE qEJDliaXlNBTzK+AaL2rWW2KVzLaNIWXEGqoCJs6BhkWgIiNaGabFteovgGOZoLjWSDnxs4S DLOihBdkN6tVlEx2SqGN/h/8qigUqkGiakOMK3n+alAHStaxy6Jo0kqLNQ4WdLBJvWdyW4jK KCrXuc8tagSDu1jh/uk4Ej0uYztJy7eeMX+0U2JZdQolt46mthtl0XCHycvj7awz3qUfeCc4 XvKqZTDGZSeJ8vu9t7rMpW7T5e2WVzvFJmMyLyLufqOlXdGxr2+JBd2Az6FOdBXYZeUFXkWW pV4LZ9TDzA0w6wDnwenm1cKQvW5x2alhaW7SgA32YnZCHOGHwUxw5rOsNzCiHBbj17X/hfAD ofLeGWeucaSqpRrpi+LAWKRFhKFIrF6cQbl2t8iFk2/GKOxNu2p2hxsWUeqEibAwhxe+wToz /vqyTF1U8vah8glFMtG5PzkrzssPvrORp7ylHMe3zVNB0JzTWOdA57nQhp5dDYN34sv+mZn7 YWqTLGpnbQoa0XCTcFqrRtouX1oj1IG0WOFDaEemWTem5t6IKevJhi4ZgnC2NDMnfVJSA9rT slNq9VTNuRuP0dULhDWeZW1rWlN61h02pkmPdmTzJVl+ZIVutKUdQ0eDGkiRxlN+mMraYVfU z9LV8m0hKmLVDqnWxL7aubd9xXV/VsBTFvWVfSfu3LKZLWHddLbN3L/mOrfR4A4Dh9/0Asl9 mLuntoTAiZTpjr76YEJ2ry2J3KrvKpp5+Vb4a1ktRP8eHMA2/nZE/uamVnm+udwSRzma4/xv kTcSJyM968mHnHIrBxnLPEEyySudaplHfOYqt3miAe6Yp3qa3FXuOM0RHnRMw3vLO9d1z5P+ 85ob/XR7LuxOpZ4KIOub6X+zOIFNjnSue1zGX58c88qmPa2Tfetv97rVrbbr8JYYOm2v2LT1 Ltsam2qL8f7lACvr8o/gGO9SprqvIntS7yGzlzPNud0ZH76Mq8jAf5eXbTDvZrS7PYCPe3rl wyTD3blbLKbPp7g3f+MVXbQRXV0DNdfcv1N2ep1Cy+pmc289VIMvOfepiY8R1vVfe8pQAkA+ j4QUNssJlvfyhit9ahP83u0e4i3xJTCQ/r/95Duh+zQykSxT3HjO336VZSczLoneFosgbsJr Hzwyvv/9JdAfQ6E8tDKXzm0Qd76xPqW03/MN4jMxspI855E/AZgA+uM+BaSABqyA7QuA7uM+ CahAo6ArxQomsRIoC1o9ogNBQhFA6jO7kgO5wvO1Y5g/B5xAFrS/BXRBB5RAC2TBFsyMDIwz ZSElcxq39NGXv9uL83I9fxrCj2K2O9I5RrMDCITBCKzBJrRBKKTBKbzBxHkcdHu5t6my3oOe 2QM91XMGCozBBlzBC2TAGhTDmooxAMw8lJoQ9hKgH2S5raK9wMOFFaTCC8DDKMxDC+TDsSKg 67g7N/SpdQtE/i5UHqz7qgSUwjOkwhmMQkikwRe8jes7Fztyp0KEw+fzP6ZhuIBLwBkURSac xBYcQ1N0Qt2yQpDRChZZL86CPrBTO+S6IdEbBEqsxPYqQh1sHkRsL198t/ExwI1rw1/BxVwM xH2xr1rpQIOyxfurMRzptZt6RjogxSpcw6fohWbkoTnckGZLwuKzvVesPXihN3E0P2A8uv7i NXtDx3HkP0XUxaFRRxobOsCTO3gMmb3jx5tSk3rUs6HjM300P18YgINEyIRUyIVkyIZ0yIeE yIiUyIYMNjmsuFm0EoL8P4OcyI70yI8ESZCsyPO7yFmiRbbTSDsMgZBkyZZ0yY8c/kmAvDlh JDFijL2UVMkzeMmd5MmeHICYjMW0a7nAycIUxMl79MmkVMqOBMpOXDacA8cD3MSjjIOltMqr XMimzMenvMdkAUMP6sew9LdoYgusNMur1Eqom0l2rLucJAEyhMu4lMu5pMu6tMu7xMu81EsB 0IlM1IKzBMykTEsl9ER5HKcT2MvEVMzFZMzGzMu+7ITAlMydHMx35EqTzEgicMzN5MzO9Ey5 hMzNmMzRZMnKnDx7xExzRElf+MzWdM3X1Mu+BCHSpE2PNE1ybDqaXDWGQkDWhM3fBM7gDJe/ rM3ihMjbnEqhBBDCGxBqRMzghM7o7MwuSQPjtE6K7L+t/gyaI/THcLQiAJDO8BTPxCwaILjO 80xI5Cy/3GTLEsPHDxnP+JTPuVw+nURP9FTPeJw7pzvH7wROPfBMFOA+ASVDLNg+AA1Pi7lP /DwhD/RGp0yr5/xP8PxMAkU+Cz1QCuVLCrVQDBVOb1jQ82QJmRS61JwWCf1ND3VMD1VRFd3Q DE1QEA1R6xzRoLw6jFTN+PPNCR1QAU2BAr0CuGRRDc1QIr1QDXVR2FTQGTXOGoVQnaE7BBot +BROI/3RF4XRI23AFjXSI8VQBJXOXIMDJm3S5XpSmonSMPott9jRFLVSIiXQJM3SHo3LINXS O41O5ysFMi3OtWkf7pwGnFKy/jZV0jelUyyt0y5FVCGNUyRVVCVVtiPg09r0UzWDN69MqC2A ziE9VDld1DlNVDz11NZEPWuYVNqsVMrjzx+zlU011DntUEcN1S2VVUQd1Qp9rlMlzVTlOYHM Os10Uztd1C8V1k8t0ivdUGQF0zztwWzQ1dHUU7dMRBw9UWCdz9h81Gslz0jVgWedzGh1tC4M uwnDOBTVVru81XNFV/2EBW+VTF6NOt1spyVazRBQ13uNUXbtVncFzPtyRfyKkB47zYAcyhNs zkDVVHxV2P+UUX41y7a4STxKJ/x40OmIPJuMnIXV2NdcUofFSghJQqUSy5F9rkstldAz141V 2cbs/liPtUqQdc/1xE2yNCtJc7+aDNdsXdmdxcuWdVmlhFk1Nan+vKCBhRqizUZQtFaeZdrY bNifBVqhBUFnS4JSjb4NIjgTiypWTaqUbdqvpc+nhVqf7CcnK1uK6CdqsD4fpKDF00Rp2EYK Iy2SpVt7Etux5cnOYr5kZLwE2VvVGjmpjFhZhAcAwNuoXRPP4zybNYeQKh+jvNH7MdzDJVv+ orLF1U5DuljeTE5yEb3qpNye5LAPrNnMLdqfQiDLNBZb3IHQFV3LZR9uUkv1eU/ChJZnLAHX zduAeyH0U0vGLcGG+5u6/SDdpczTRbzSnd2ssaYSjZbJNd6WTIpqJCnZ/rXd+bKheo3cTYLe 6A3J6RWTKwNeWwpcjLVa0+ql7vVemETewhVf000Ix51GhHXe71Hf9WXK9t2b6cPYRiktTAxU Zyum7bQK/P1e/RUV7HDbQSsYoqzD5aUX6r1fA45I8KUSTkO98U28eRUvMSPeD8YnXaBg9r3a t4Cn/tRgn1u0pQXbFq7Tux3hh7RgbDS0FL4w5vVaF9ZhvoThGMZOsGQhaAPhIUay9ztJHbXX HVbiA+1hH87KHF7MLXBiSo1GDhbcCmPhJXZhn51ihkzY6TyBLt7VKkbd+S0zQtXiFuZiMU5P KFZMKWbjd4VKJLziaUpjJV7jOP5JN95WItDj/sD0QkwdYJ2945XN4zj+Ys6E4z9+2FXt4CQu ZDVuYjZO5M1cZEZGS8NkBz52VQMFUmT10mJV2UOmZE52Wj/G5I8dV+yF5GuN1R51VDit1VAm 5DCdZDGu5BUN41TOZGrFolo05So91E8l1k6dZVe+5S7OZZbdZV5eyjS1tyld5vEs5mSl1WNu VFCdT1LG5WDu2WZ2ZsEk45hd0/bL4vh8ZS+9ZlhV1HTd1GSe4mmOYnAO59f1GDruXyrV1mUF ZWum5XauZVsWYWeW5zem53o+3q482a9EY3TmUFl+02MGUoXlZmX25ru8ZIRO6PYsupxV13TG 05CWU3cWaGII54Iu/tZ+ZmJUFswrEEygPcvZG8hzpmZZLtKb1mZQDegPHWhelmc4vdADFdKD fkn1neDShOlG9uUQuWiOBWVi7WdR/uedZtieTuWfHtCg1uotJWqXNGqyTWpVXmpNA2aajmRD hmcnxmqh3tKhZmnRdcgUQEi5PkjDhV66/smf7F681uu9zmu9/muxLtjdnNpBbOizRmurxuS1 3urGHtCu9moUUMi7DuzJley6nuu6tmzM5mzK1uzOPurKldcyLkrnNGvE1tiKjmcoBmq2dmuO fFnPzuzOTs/Z9mzZnu3Kzu1enhG+8043oWrU3ue09mHG5kvXfu2VfFjOzu3NnmuX1u3o/u5r 2cbtlzVZiWXoVhbuxDZpgmbtrHZsrn7rvJ1s5mZu5zbv81Zv6abumHbkcgSC7WZa1Vbr70bu sB1vyixv3b7t2qbt//5ry27v9H5mTe7a05bvjybuGEbpp8Zv2CZb6Nbsu77swJ7w567wvk5P u95tCedtI87Mw07we6Xv4m7qusxojfbqVTaEcgViIoZxEVrwES7oPoZwFV/x0ZZSgaFeiZjZ ejnpE6fLFMfxA9ZxoZWtHr9ZbtVXFwhyBN9LIi9yEu7tzS3sga0Wv6TZ03hyETfo/J5yKqfD L8zUy5RZ1d1XnxbyB1fuMC/N95bWftHyjUSMLtduXQZzN59I/plm25aJ8dn0big/5RvX8/wd 6zhEUyyH4B6w8zOoUMgudBlm8ctZ9F+Z85XBmUZfgUfP80iXdO0SrVQy8yYndUjvZkF/TFP3 9CcG9dgqYgL+8QKUB02P7wBV9VVv45MM4N9mzzOPdWcNdC+38TbH9QpeLVpRcsjwYCKmdS3g dEIv9h+uJqQlXF/vXGBXc1T/5k6P9lw/ys2ZYU1o9re0dW7v9rr+duJxPMkYd9J78T+P8XQH 93oLg3GXoGSXd9/6dciydy5qp3xvLXgX+A+acQoGlKI4X4CXjBHn7qzpd0FcPyZX+ERh+FEu eAMODscIm4Hn+Ff/k4rf2BJn8Jxd/nOQT9G3MPmFFXkaJ3ltT/l3toqXx9eVN/iWF3aZL+nC xXkFV2xGHkmN2vlz7fHgDnrXpHmMt/k7L/p8hZOl3+aLx9+fz1inR2eUp3pqhvr1lXo7vnrx HPqu9/qs996t12ewh/mmN3tm7fk/JvsaT3swjvm35+nuznb9cXu5x3O0x3tIXXs9bvuS3/t1 jfvAN3qxj96/d3nCT/XBz9NRVWl/plXGfHxSNXzjRfybV/xhh4wEBU/Hf1QXJelZrWq6v+qk d/TMf3adD9POJ+Qk5dIVJfovJ/3FNv1NR/1y13thDml1hmpjhWpltWktnXxLrnzdvXylv/15 Znwe3f1G/q3VqA7+O61mfw79xZ99n6/9Wk9+4l/+QqUEnX7oYRZplZ7+6cd9hw926br77Rf8 3HfTyB//+M9pT5b/YY399kf/uld/wGf/lXZ/CBBy0movBeBq2ef3eRtIchopCqKqYi8MBDNd 2zee08DQ+z8wKBwSi8YjcijT6ZY4580Em1Kr1is2q40xu94vOLrVukalkSnEkprPK3VaPaZC w/YaL6nf8/v9OhjgDh7enOEhYiKi4F2jow2bYgUKG2XJRkvH2onlJaYciqQF42NXnh9qqqoe KRNpnVOk6Cxt7VVrae6XrG1tWa8ori7karHx8YDwU1PUDC8wdLSi8nB1obTt/i+2IXX1KTJ4 +FE3YY6gzPO2+jqXtbtXOrv8PLnutzh+fg8lf7//P0Bt8wayq/euVDyCCqEZRKjvYb6G9dAt rFjwIMYnFjdia/joHsSQqyTaWZKQI0puGVfuSOmSlkdHIEXS/CMzTKyXOqexZHlyJ9AXMRvN rGkUCcld19T1IxOUTs+VP59S9RAVz9Gse5LemSqp0rSqQ6+aq2oWKtkARbWy/cG1ZMFJYamO TQvpLF4MdXG27avkJtG4GS5NwuSBcCg0IFYopmfXnde8L/cG8mvZLWB4S7eBZXz4c4jPjNMs fiM68tfH1lBLRkl51+XYb021XNf0dGnPKeTi9ux7/uBru6xbbwxuKvbl2bTVCv7NL/fuxnES S0kszzjZ4cQrYm+C3LJy2trnVM89GPQo35FkjVepelj77cCFf/cb8D7+f83VQ28TfXR//Ilm 23vw5XcgggkquCCDDf5DX31tdddMfE6d90YlhqknR2POCRTNhAWKOCIzzZDYVYQSXmWSWPKB cCKMMR50jowlOpMiWyE6U5tOpLm4Qo1BCtnVMkNCsgOOWukIRYUMfYiXjkZK+Q6NUw6iVpJZ RbnZj09taSWYHxUZJjpZHvWlM12ahWaYbQbiIJxx+mOmUWw2qaY0bLq5p43lkIklnTTZiSdd fBoqYpVTonNjoCIx2dOd/oQCo+ehlSaqKJKNhhRLVJFKmk2loaZ1qZGLAqrpQyat+ClQlIq6 J6mYroXqMaZ2yupOrr7a5jly+pogran+eiCuPe56LEaxSllmsBGplV2xkyE77WpjWmlSs84+ e2u0KelKbanWLptptuFwCmm33oK7rpgmYkpuucg86lO6rrF7b0nigjlrvH4MSqhAnm7xbS7D GnwwwsNC2G+tfmbUZCcYRsybXtZRfDHFAltBMEL1cmQnw/JeSe8iF5psxifpmTcgxno5ZqjG Ho8BcsjGqMotN3QI9dvKKrscMRzTxfwizDJbRHPNI22LM3kSjxLwzxYLWNiFPg44NJBFG70Q /tJJp5JwQIuUxwHZ7I3tHNm8Wc3zpIdivfXGC3uNiq3oHrJe2mekfPJo/vhc2tpOt6013PON OrcqN9udc8tss9wze3kD3jPlqRFe+HVyI87HuSTffV5nWJzdeAsBavh4MG5jbnh2m9PtcLLT WPzcwFITlsEna8ThCUOqr5754a7bNOrvwPP5dvEcaC48UrDPmDyBl0MP4vLg3HMKv0qOLNX0 nPnePfXB64O9WxEq7jn4gx+ffvitp+rDN9lrufTi7IMq/aS0236LC9bt/7L73ne9ZMRPA/BL hqDAph/79YJjH+nI7tpgIRZI8ElMqZ44QGJABHKQgxt0FP3Qx8BZ/jhQJnkKnQVP8DQVHg2D 5goC+YCQB/mJLIQPG+H91gcibWgiE7hzww9XiDv/9VBjXYtIB/dxwH2gQIk16Rz3cAiT7zmp DNSJoH9mZzsfVpBDqRMfEp0oxhkukYYN217spEhCKu6Qi1kMommoJsQ4drF3YMRHDMfoxA2a 0WbCUeMa8ddGIMbRjVY0myeA9rYjvrB8TPwgAT1Ypz8C0nI6ZIgc6VjI6mCRkEAM2CJdyLy/ EK+SPBEkTDrJxSt2UoJwpOMm1LeiUW6FkqZcBBuzQTtC6i53rvzlL3epSV+IkpYytOUt3XPJ ZJKnmMaEHzKZObBcSlN0znxmMqJZTWui/nKbaAkgNonwL29moYSBIWc5r/nMcaIzbt1sp/Lu GE4YahOeQqGmPeMJznnSc1QK/CdAA6oBfOZzEuo0pjnxpdBVFXQKjOQnNBcqUXwhL30PhWg2 J6pRcFUUfBeFaEI3KlJ7NNShB6VlSEeq0nOWVC8nHaWdBCrTmf6KoC39KD9xilEQvrOkOg3n T3eaKpv69KXMC6pQtbXMlhpUnjtFalIz6DaaUrWqCjKq8KAqIUrAjx+0SulKH6ava0U1ovs0 nwzFqFY6gTWsMxprwSBV1n1gtU5pTSJezdRWt0IGru3yyVwzuiPAZqkoA3xkYflKUb8SZZZz heLD2ApJvJJx/q3f2ati4cPYfDm2rOeTiqY+2I8l6jWz7LJqwgJbN8KGVo9umWx9MGtahGwW J2d9Kk31etf4CaGPZ5otR2tr2yWp1oaRLexuHdlB304SuNNSFm3l+tjBSrewXF0r9mB7Wec+ V7iBMC5kiktd0Ab2idxFFnQb29mozou85eXpeV/VK9Q2SLy3fS8e47ur9BJpvUldElbwuyn9 yte7SumUfaUCr6+WS7YE1oy7vIHg6XaKUc3KY6Mc/GBXGPi7rGVvdk4VL+baZ8OW6jCMSOw6 qjaSiZF0sQyb6OLrwpjGBBQtD2R8YxX7a6r0/TGQtQrTEPNYCTFWYmXVml3lLveu/mMkH2/h CyumutSpGN0StmpF4yjvEYaWzSOXy+jl+fW0oUI+aoUtXCsnJzHJYnYyhjVo2R2bt8wFPXNW IRVgebE5ynLOK5iZ3OUiFLmWds4nnldcV1YwOc6kJW0M3YxhJQuKqGZeNOISnQQZcxrHnn5t jnEM6uxqUMcDPrQ9NZ1pTAt405a+M6u9pupWNw/V8Jy1rGNNa0K/GtG6rhmudy3OXqf61yEL trB7S+xbG5thMQ0ytKu67HYi+9gmvvYN8zcxwaFBalucndrk4rcc+leoGsb2aTFZtXWzG20B AtzokFdtZ6O73t5Q9+TCDTp973vfa5N3s/t1bns/F9/o/uH3wf+WcPT8u33lfqpwoi3xmU7b Qvnu98Vb9p+DbxzgVgZpPak88Lto238qu43j2LZx3Szc4/cFeSmp3NSlwsRlCOfb41b+n9Ol /Isvz2nImTpyLtVccgs/2cpZjnGeu/zhVw76TStezp2922fxbjcncR7In8+TnTK3iq0HFgNw C+WQZke61n3udJhD6+sZkLo35y1wqBc17OiU+4idRyW3v93u5MR7g9GYRr5njeYyB3y2Pptt wg+dR3xH/IXB+zzCF37KlId8sKhK+cq7qaPdw/xXJb/3y8N9m6BHlaqWtPnGp4n0Hwf6eBf/ +NJX8/Sh3ZHqXW94kQc871/y/vz0WK+WiRMfoL1vME1XX++BCz8Kxf298tHN/BMv2Ny4r5/b m48oXoUqFvaNEvChp/0CTb/7av7v9UX49fG/p/zmL3Suoa/7azO/+AxSbfLnb2L3nxj+SVtt FDHe8nGf22yL/wFb7FWL42XfAP4J9YkY+iWghLWeAEofAcKMASZYd7CI/m0Y/xXgAVrbijBH Bz7YBzqD/QUE/s1U9JngyMgWfwUJs3gWkbWgCxrgtaDY9kGg9fmEAdqgCwKgkMRgjHgfhfkg Bc4etqGAAx5JDlYfxPkgB1bgEl6g3ilKgkkhEPJKCnahwrxe1+UfFcJKsuUXGAJVDZbgvpSh VJ0h/jZhWRIyIMywobkcX+KlGQmOYefRofXYYeQhYRyun9vwYQ1xHRrGHNcIk9iEXzscDyGe kSG+Id0VhBEx4j3N4SMWw7N5IU1Nom1UYnEMYiYqTXDBDixIlCWO3Q9Zgha9Ugp1hCiO4tes yynuwEChIPvBg2tkiHSoUta1ECbK4uuU4gs+y6IIYcF9DC/WkSa5EdfEojAOD7XU4s1UI0Xt YibFkjO+Yp5A4x94lTjN2aMRmo2N2YvtmKlJGXodCacco+ChFzbCkTb+IjCxDhl+DZsZWV7t ozmKoyT11h/4ETHGXi0qVCqWXTZGECu9kkIIX5EdFqHNmfxA5JgZVkBq/iItOiEa5aIuHs0u xRIshQIRhWIw+ktyDVqo/VmoAaQSiNaNsWRXFdAMaRfnZKQpauQ1qiFZfQ04Ntk/zsRMSuRk RZo4clmSudksDmQIFWRO6iGvJM5J/qREulZLQtqg9SNR5uMw7tcguGP6vSNHbSGZQKUjZWVl cRpVhiM6XmWfbZlLYuQ64qBcMuW9HCTmOCRZvplU7uNR9uM/lqU++uNfJs40GqNhQhZHmoJY riE+AiZKTqVPClpfDmaj6SVSbiV63eLwtZcEhqVOYiFP2th1naVKjuMjQZKOXSZ2oaaokWJh 3uQVTuNi7mQ0SiNOcCJuOsgDfeay1GaPoYhv/takCfFmqQSncJaEcRoaSymhIyanqwGnc47D bjrlWEandEKndQ7bcFInY2andiKnd35nV8wmaIansmGneWLGdjLnPabnMaGnewrWeBLnkIQg HxqEfdKhR9hl4eBlfKoneP4nXa2nHDangMpnZRwoguIEefamguKngi5oIDRoqeSmhV4VfLrn flIowXFXfrLhhtJnhwLXh5ZhiHLniMZXiSbbibJnippghLZogb4ojF5WT8bk3BGoINKoB6YI TZ4jkAaKjO4ojxLYio7EWrBm6Ono4RVpjcbW9RjQjyppbE2nizqpcx1p4hQQYnUpkP6oijAp 72GpivroknXVa6VptpDKhpXOKJmSqJmiqZzCWI1paVIup5u+qWnZKd2cKZ0GaTkix5A2qZ5m aZzKqakNZToK6kdcqKPmR6Eaqo265UrOqaVWaaRmqqbyoIZuqqfqKZ8KWGJ+KqmmWIyWKqq+ aKji16imqqv64a616qvOanUJqKzSKq7OyKnmKq966K72KrBm1qq+160Gq7EGqK0eq7Kq1LCW V7EuK7Q+wa9GK7We1rRWK7Zm5qNu64Nkq7d+K7jyVQQAADs= --------------8290224CF74C58DE3EB6DEBD-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 4 00:32:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17PvcL-0000MA-00 for ; Thu, 04 Jul 2002 03:41:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Jul 2002 03:41:09 +0200 (CEST) Received: (qmail 26384 invoked by uid 0); 3 Jul 2002 22:33:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 3 Jul 2002 22:33:22 -0000 Received: by moria.seul.org (Postfix) id E4DC914691F; Wed, 3 Jul 2002 18:33:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C12EE146927; Wed, 3 Jul 2002 18:33:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a249.home.uni-hannover.de [130.75.232.249]) by moria.seul.org (Postfix) with ESMTP id AF80B14691F for ; Wed, 3 Jul 2002 18:33:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA04197; Thu, 4 Jul 2002 00:32:54 +0200 Message-ID: <20020704003254.19944@thrai.stud.uni-hannover.de> Date: Thu, 4 Jul 2002 00:32:54 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] I forgot to tell you... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ... that I uploaded fcpu-mr-20020628.tar.gz to http://f-cpu.seul.org/~f-cpu/new/ recently. But there are only minor changes, so... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 4 09:10:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Q6ou-0000P0-00 for ; Thu, 04 Jul 2002 15:38:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Jul 2002 15:38:52 +0200 (CEST) Received: (qmail 16238 invoked by uid 0); 4 Jul 2002 07:02:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 4 Jul 2002 07:02:28 -0000 Received: by moria.seul.org (Postfix) id B7F45146815; Thu, 4 Jul 2002 03:02:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B014146933; Thu, 4 Jul 2002 03:02:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 2F1EA146815 for ; Thu, 4 Jul 2002 03:02:26 -0400 (EDT) Received: from f-cpu.org (kdl11-65.n.club-internet.fr [213.44.9.65]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 273A016B6 for ; Thu, 4 Jul 2002 09:02:24 +0200 (CEST) Message-ID: <3D23F4F3.154E5F75@f-cpu.org> Date: Thu, 04 Jul 2002 09:10:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] I forgot to tell you... References: <20020704003254.19944@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > ... that I uploaded fcpu-mr-20020628.tar.gz to > http://f-cpu.seul.org/~f-cpu/new/ recently. > > But there are only minor changes, so... OTOH in my corner, the last 2 weeks have been very productive ! - support of 4 tools (vanilla and Simili like before, ncsim and Riviera now, and very easy addition of new tools) - i started popcount and mostly finished the register set. - still "in the pipeline" : finish popcount (btw Michael's help is welcome because i don't know how to you his generic adders), rewrite (mostly) INC, and start BIST. - changes : ncsim and Riviera did not like the random package. now it is changed and the functions are renamed. It currently compiles without modification with all tools - the f-cpu/install.sh script is better populated and executes in 1 minute with all 4 tools at once. 8 subdirectories are compiled and tested (configuration, common, registers, rop2, imu, asu, imul and clock). INC and popcount are next in the list. I do not run the ASU and IMU exhaustive tests, as they are excessively slow ... i'll upload a new snapshot soon. Btw, for those who still want a C emulator : i care even less, now that i have found that ncsim runs 60 times faster than simili and 120x faster than vanilla. Riviera is almost (some %) as fast as ncsim. So the "easy" solution is to get a free Riviera license :-) have fun, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jul 4 10:25:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Q6ow-0000P0-00 for ; Thu, 04 Jul 2002 15:38:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Jul 2002 15:38:54 +0200 (CEST) Received: (qmail 4409 invoked by uid 0); 4 Jul 2002 08:25:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 4 Jul 2002 08:25:58 -0000 Received: by moria.seul.org (Postfix) id 9F3B914694D; Thu, 4 Jul 2002 04:25:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79F0F14694F; Thu, 4 Jul 2002 04:25:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id D333C14694D for ; Thu, 4 Jul 2002 04:25:56 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207040825.2db0; Thu, 4 Jul 2002 08:25:45 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] I forgot to tell you... From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2002 08:25:45 GMT Message-id: <200207040825.2db0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 04/07/02 Objet: Re: [f-cpu] I forgot to tell you... hi ! Michael Riepe wrote: > ... that I uploaded fcpu-mr-20020628.tar.gz to > http://f-cpu.seul.org/~f-cpu/new/ recently. >=20 > But there are only minor changes, so... OTOH in my corner, the last 2 weeks have been very productiv= e ! - support of 4 tools (vanilla and Simili like before, ncsim and Riviera now, and very easy addition of new tools= ) - i started popcount and mostly finished the register set. - still "in the pipeline" : finish popcount (btw Michael's h= elp is welcome because i don't know how to you his generic add= ers), rewrite (mostly) INC, and start BIST. - changes : ncsim and Riviera did not like the random packag= e. now it is changed and the functions are renamed. It curren= tly compiles without modification with all tools - the f-cpu/install.sh script is better populated and execut= es in 1 minute with all 4 tools at once. 8 subdirectories are compiled and tested (configuration, common, registers, rop= 2, imu, asu, imul and clock). INC and popcount are next in th= e list. I do not run the ASU and IMU exhaustive tests, as th= ey are excessively slow ... i'll upload a new snapshot soon. Btw, for those who still want a C emulator : i care even les= s, now that i have found that ncsim runs 60 times faster than s= imili* >>> Ouch ! 60 x ! 2 or 3 could be acceptable but not 60 x ..= . nicO and 120x faster than vanilla. Riviera is almost (some %) as = fast as ncsim. So the "easy" solution is to get a free Riviera li= cense :-) have fun, > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 4 14:15:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Q94c-00022Z-00 for ; Thu, 04 Jul 2002 18:03:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Jul 2002 18:03:14 +0200 (CEST) Received: (qmail 18263 invoked by uid 0); 4 Jul 2002 14:09:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 4 Jul 2002 14:09:58 -0000 Received: by moria.seul.org (Postfix) id C8B4F146933; Thu, 4 Jul 2002 10:09:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9171D146936; Thu, 4 Jul 2002 10:09:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a062.home.uni-hannover.de [130.75.232.62]) by moria.seul.org (Postfix) with ESMTP id 7627D146933 for ; Thu, 4 Jul 2002 10:09:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00515; Thu, 4 Jul 2002 14:15:24 +0200 Message-ID: <20020704141523.60040@thrai.stud.uni-hannover.de> Date: Thu, 4 Jul 2002 14:15:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207040825.2db0@th00.opsion.fr>; from Nicolas Boulay on Thu, Jul 04, 2002 at 08:25:45AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 04, 2002 at 08:25:45AM +0000, Nicolas Boulay wrote: [...] > - support of 4 tools (vanilla and Simili like before, > ncsim and Riviera now, and very easy addition of new tools) > - i started popcount and mostly finished the register set. Ah... I wundered why they were marked green in the latest picture. > - still "in the pipeline" : finish popcount (btw Michael's help > is welcome because i don't know how to you his generic adders), > rewrite (mostly) INC, and start BIST. What do you want to add? How big are the operands? > - changes : ncsim and Riviera did not like the random package. > now it is changed and the functions are renamed. It currently > compiles without modification with all tools > - the f-cpu/install.sh script is better populated and executes > in 1 minute with all 4 tools at once. 8 subdirectories are > compiled and tested (configuration, common, registers, rop2, > imu, asu, imul and clock). INC and popcount are next in the > list. I do not run the ASU and IMU exhaustive tests, as they > are excessively slow ... > > i'll upload a new snapshot soon. > > Btw, for those who still want a C emulator : i care even less, > now that i have found that ncsim runs 60 times faster than simili* > > >>> Ouch ! 60 x ! 2 or 3 could be acceptable but not 60 x ... > nicO > > and 120x faster than vanilla. Riviera is almost (some %) as fast > as ncsim. So the "easy" solution is to get a free Riviera license :-) Did they offer us a full license, or only the 20-day trial license on the web? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jul 4 16:44:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Q94c-00022Z-01 for ; Thu, 04 Jul 2002 18:03:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 04 Jul 2002 18:03:14 +0200 (CEST) Received: (qmail 10383 invoked by uid 0); 4 Jul 2002 14:44:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 4 Jul 2002 14:44:22 -0000 Received: by moria.seul.org (Postfix) id 623E4146917; Thu, 4 Jul 2002 10:44:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E801146934; Thu, 4 Jul 2002 10:44:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 5A98C146917 for ; Thu, 4 Jul 2002 10:44:20 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207041444.0a59; Thu, 4 Jul 2002 14:44:10 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] I forgot to tell you... From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2002 14:44:10 GMT Message-id: <200207041444.0a59@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Is it possible to have 2 or 3 vhdl files to test the speed o= f vsim at work ? nicO=20 -----Message d'origine----- > >>> Ouch ! 60 x ! 2 or 3 could be acceptable but not 60 x = ... > nicO >=20 > and 120x faster than vanilla. Riviera is almost (some %) a= s fast > as ncsim. So the "easy" solution is to get a free Riviera = license :-) Did they offer us a full license, or only the 20-day trial l= icense on the web? --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 4 18:08:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QHHX-00066o-00 for ; Fri, 05 Jul 2002 02:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 02:49:07 +0200 (CEST) Received: (qmail 26808 invoked by uid 0); 4 Jul 2002 16:00:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Jul 2002 16:00:03 -0000 Received: by moria.seul.org (Postfix) id 03978146933; Thu, 4 Jul 2002 12:00:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9516146936; Thu, 4 Jul 2002 12:00:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 655EB146933 for ; Thu, 4 Jul 2002 12:00:02 -0400 (EDT) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-5v.club-internet.fr (Postfix) with ESMTP id B744B16C3 for ; Thu, 4 Jul 2002 17:59:59 +0200 (CEST) Message-ID: <3D2472F5.D232083F@f-cpu.org> Date: Thu, 04 Jul 2002 18:08:21 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Thu, Jul 04, 2002 at 08:25:45AM +0000, Nicolas Boulay wrote: > [...] > > - i started popcount and mostly finished the register set. > Ah... I wundered why they were marked green in the latest picture. :-) Kein Wunder hier... > > - still "in the pipeline" : finish popcount (btw Michael's help > > is welcome because i don't know how to you his generic adders), > > rewrite (mostly) INC, and start BIST. > What do you want to add? How big are the operands? For the popcount, i have to solve the 4-bit input -> 3 bits ouptut logic operation (bit 0 is a AND-reduce and bit 2 is XOR-reduce but bit 1 is not straight-forward at all). Currently i do it with a lookup table in the integer world (that's lame but it should simulate fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results, 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint results and a final 6+6=7 adder for the full 64-bit result. Currently, i do this with the lame (from memory) subtype type_result6 is integer range 0 to 32; type array_6 is array (1 downto 0) of type_result6; signal tmp_6 : array_6; approach with some loops in which i simple perform the addition as is. so what i need is entities that perform 3+3, 4+4, 5+5, 6+6 and 7+7, that's that simple :-) and the boolean equation of bit 1 of the 4->3 bit reduction woud be handy, too. > > Btw, for those who still want a C emulator : i care even less, > > now that i have found that ncsim runs 60 times faster than simili* > > > > >>> Ouch ! 60 x ! 2 or 3 could be acceptable but not 60 x ... > > nicO remark : that was a measurement i made on my laptop (everybody knows how it sucks), the difference my change with other configurations. And it was for running Michael's exhaustive loops. I don't know how it will behave with a full CPU : cache locality will not work and the speedup might drop a bit... i have only 128KB of L2 on my Celeron and a good big XEON or ATHLON might help accelerate that too :-) > > and 120x faster than vanilla. Riviera is almost (some %) as fast > > as ncsim. So the "easy" solution is to get a free Riviera license :-) > Did they offer us a full license, or only the 20-day trial license on > the web? when you get the distro, there is a 20-day "restricted" evaluation period. It is then unlocked on a request to ALDEC, which seems to be very liberal with their 3 months "unlimited" evaluation period (all limits are gone, except the time, but like Simili, it seems to be updated regularly on their site and it might be a way to force the upgrade). I have no answer to the question "and after 3 months ?". Cadence automatically sends me a new license some days before mine expires, but the ALDEC policy is not totally clear concerning F-CPU. But it might be worth it to try the 3-months thing, just for the test run. It's a 37MB download, but it contains Verilog and EDIF simulation, code coverage, random init, GUI, TCL, etc... it's a kind of "advanced" Simili but Simili still wins concerning the installation speed and ease. I've found that not only Riviera conflicts (on paper) with Modelsim's tool names (that's solved through the use of direct paths), but also with Vanilla (that's solved with an option that changes the current library directory). I'll update the VHDL_HOWTO whenever i find time... nicO : > Is it possible to have 2 or 3 vhdl files to test the speed of vsim at work ? i measured the times to run iadtest5 and iadtest6.vhdl, as found in Michael's snapshot. i'll upload mine ASAP so you have the latest scripts. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 4 18:19:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QHHX-00066o-01 for ; Fri, 05 Jul 2002 02:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 02:49:07 +0200 (CEST) Received: (qmail 3579 invoked by uid 0); 4 Jul 2002 16:11:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Jul 2002 16:11:01 -0000 Received: by moria.seul.org (Postfix) id 415B3146917; Thu, 4 Jul 2002 12:10:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26F0F146936; Thu, 4 Jul 2002 12:10:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 79393146917 for ; Thu, 4 Jul 2002 12:10:58 -0400 (EDT) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 95C3016AE for ; Thu, 4 Jul 2002 18:10:56 +0200 (CEST) Message-ID: <3D247585.F5CB9ECA@f-cpu.org> Date: Thu, 04 Jul 2002 18:19:17 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Yann Guidon wrote: >i'll upload mine ASAP so you have the latest scripts. it's http://f-cpu.seul.org/new/snapshot_yg_04_07_2002.tar.bz2 - uncompress in a new directory - go to f-cpu - run ./install.sh WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 5 00:08:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QHHh-00066o-00 for ; Fri, 05 Jul 2002 02:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 02:49:17 +0200 (CEST) Received: (qmail 30758 invoked by uid 0); 4 Jul 2002 22:08:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 4 Jul 2002 22:08:17 -0000 Received: by moria.seul.org (Postfix) id 03EB0146939; Thu, 4 Jul 2002 18:08:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A8B4414693C; Thu, 4 Jul 2002 18:08:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a175.home.uni-hannover.de [130.75.232.175]) by moria.seul.org (Postfix) with ESMTP id 0C8C9146939 for ; Thu, 4 Jul 2002 18:08:14 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02520; Fri, 5 Jul 2002 00:08:17 +0200 Message-ID: <20020705000817.51086@thrai.stud.uni-hannover.de> Date: Fri, 5 Jul 2002 00:08:17 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207041444.0a59@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207041444.0a59@th00.opsion.fr>; from Nicolas Boulay on Thu, Jul 04, 2002 at 02:44:10PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 04, 2002 at 02:44:10PM +0000, Nicolas Boulay wrote: > Is it possible to have 2 or 3 vhdl files to test the speed of vsim at > work ? Of course. Just grab my latest sources (fcpu-mr-20020628.tar.gz) from seul.org, plus a copy of f-cpu_config.vhdl. The package contains the ASU, IMU and SHL EUs and my part of the `common' directory. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 5 01:05:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QHHh-00066o-01 for ; Fri, 05 Jul 2002 02:49:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 02:49:17 +0200 (CEST) Received: (qmail 1754 invoked by uid 0); 4 Jul 2002 23:05:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 4 Jul 2002 23:05:49 -0000 Received: by moria.seul.org (Postfix) id 8E93F146939; Thu, 4 Jul 2002 19:05:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EDE214693D; Thu, 4 Jul 2002 19:05:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a175.home.uni-hannover.de [130.75.232.175]) by moria.seul.org (Postfix) with ESMTP id 9ED81146939 for ; Thu, 4 Jul 2002 19:05:45 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02660; Fri, 5 Jul 2002 01:05:44 +0200 Message-ID: <20020705010544.52418@thrai.stud.uni-hannover.de> Date: Fri, 5 Jul 2002 01:05:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2472F5.D232083F@f-cpu.org>; from Yann Guidon on Thu, Jul 04, 2002 at 06:08:21PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 04, 2002 at 06:08:21PM +0200, Yann Guidon wrote: [...] > > > - still "in the pipeline" : finish popcount (btw Michael's help > > > is welcome because i don't know how to you his generic adders), > > > rewrite (mostly) INC, and start BIST. > > What do you want to add? How big are the operands? > For the popcount, i have to solve the 4-bit input -> 3 bits ouptut > logic operation (bit 0 is a AND-reduce and bit 2 is XOR-reduce Vice versa (assuming that bit 0 is the LSB, as usual). > but bit 1 is not straight-forward at all). Currently i do it with a > lookup table in the integer world (that's lame but it should simulate > fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results, > 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint > results and a final 6+6=7 adder for the full 64-bit result. You can use my CIAdd procedure from the Generic_Adder package. Here's how to use it: function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is use work.Generic_Adder.CIAdd; constant w : natural := A'length; alias aa : std_ulogic_vector(w-1 downto 0) is A; alias bb : std_ulogic_vector(w-1 downto 0) is B; variable yy, cc : std_ulogic_vector(w-1 downto 0); variable pp, gg : std_ulogic; begin CIAdd(aa, bb, yy, cc, gg, pp); -- we only care about yy here return yy; end "+"; That should work at all operand sizes you need. But note that the delay will probably be big (d=4...5 per CIAdd), that is, a 64-bit result will need 4 pipeline stages :( We may reduce that to 3 if the adders are broken down into their components (CIA_Row and CIA_Inc). > Currently, i do this with the lame (from memory) > subtype type_result6 is integer range 0 to 32; > type array_6 is array (1 downto 0) of type_result6; > signal tmp_6 : array_6; > approach with some loops in which i simple perform the addition as is. > > so what i need is entities that perform 3+3, 4+4, 5+5, 6+6 and 7+7, > that's that simple :-) and the boolean equation of bit 1 of the 4->3 bit > reduction woud be handy, too. The sum is 2 or 3, so there must be two or three bits set but not all four: (AB or AC or AD or BC or BD or CD) and not ABCD if A, B, C and D are the input bits. Bit 2 is, of course, ABCD, so you already have that part of it, at least. Maybe it becomes cheaper if you transform it... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 5 03:37:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QUb5-0000EN-01 for ; Fri, 05 Jul 2002 17:02:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 17:02:11 +0200 (CEST) Received: (qmail 14999 invoked by uid 0); 5 Jul 2002 01:28:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 5 Jul 2002 01:28:51 -0000 Received: by moria.seul.org (Postfix) id 13FA114693C; Thu, 4 Jul 2002 21:28:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0367414693F; Thu, 4 Jul 2002 21:28:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9994A14693C for ; Thu, 4 Jul 2002 21:28:49 -0400 (EDT) Received: from f-cpu.org (kdl11-31.n.club-internet.fr [213.44.9.31]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 8CFF5169C for ; Fri, 5 Jul 2002 03:28:45 +0200 (CEST) Message-ID: <3D24F843.43728A4B@f-cpu.org> Date: Fri, 05 Jul 2002 03:37:07 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> <20020705010544.52418@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 'night, Michael Riepe wrote: > On Thu, Jul 04, 2002 at 06:08:21PM +0200, Yann Guidon wrote: > [...] > > > > - still "in the pipeline" : finish popcount (btw Michael's help > > > > is welcome because i don't know how to you his generic adders), > > > > rewrite (mostly) INC, and start BIST. > > > What do you want to add? How big are the operands? > > For the popcount, i have to solve the 4-bit input -> 3 bits ouptut > > logic operation (bit 0 is a AND-reduce and bit 2 is XOR-reduce > Vice versa (assuming that bit 0 is the LSB, as usual). ooooops. > > but bit 1 is not straight-forward at all). Currently i do it with a > > lookup table in the integer world (that's lame but it should simulate > > fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results, > > 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint > > results and a final 6+6=7 adder for the full 64-bit result. > > You can use my CIAdd procedure from the Generic_Adder package. Here's > how to use it: > > function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is > use work.Generic_Adder.CIAdd; > constant w : natural := A'length; > alias aa : std_ulogic_vector(w-1 downto 0) is A; > alias bb : std_ulogic_vector(w-1 downto 0) is B; > variable yy, cc : std_ulogic_vector(w-1 downto 0); > variable pp, gg : std_ulogic; > begin > CIAdd(aa, bb, yy, cc, gg, pp); > -- we only care about yy here > return yy; > end "+"; you mean, i copy it verbatim in the code ? > That should work at all operand sizes you need. But note that the > delay will probably be big (d=4...5 per CIAdd), that is, a 64-bit > result will need 4 pipeline stages :( We may reduce that to 3 if the > adders are broken down into their components (CIA_Row and CIA_Inc). i don't understand well... here the operands are 3 to 6 bit wide. > > Currently, i do this with the lame (from memory) > > subtype type_result6 is integer range 0 to 32; > > type array_6 is array (1 downto 0) of type_result6; > > signal tmp_6 : array_6; > > approach with some loops in which i simple perform the addition as is. > > > > so what i need is entities that perform 3+3, 4+4, 5+5, 6+6 and 7+7, > > that's that simple :-) and the boolean equation of bit 1 of the 4->3 bit > > reduction woud be handy, too. > > The sum is 2 or 3, so there must be two or three bits set but not > all four: > (AB or AC or AD or BC or BD or CD) and not ABCD > if A, B, C and D are the input bits. Bit 2 is, of course, ABCD, so you > already have that part of it, at least. Maybe it becomes cheaper if > you transform it... in the Thornton book at page 108-109 (PDF page #62), it looks like that so i guess it's close to the best we can do... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 5 08:13:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QUb9-0000EN-00 for ; Fri, 05 Jul 2002 17:02:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 17:02:15 +0200 (CEST) Received: (qmail 10432 invoked by uid 0); 5 Jul 2002 06:04:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 5 Jul 2002 06:04:49 -0000 Received: by moria.seul.org (Postfix) id 8F4F914640E; Fri, 5 Jul 2002 02:04:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 17606146917; Fri, 5 Jul 2002 02:04:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8DB681467EF for ; Fri, 5 Jul 2002 02:04:46 -0400 (EDT) Received: from f-cpu.org (kro1-59.n.club-internet.fr [213.44.93.59]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B08621699 for ; Fri, 5 Jul 2002 08:04:43 +0200 (CEST) Message-ID: <3D2538F1.4C85B7FF@f-cpu.org> Date: Fri, 05 Jul 2002 08:13:05 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> <20020705010544.52418@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N huh, Houston ? i got a little issue... Michael Riepe wrote: > > but bit 1 is not straight-forward at all). Currently i do it with a > > lookup table in the integer world (that's lame but it should simulate > > fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results, > > 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint > > results and a final 6+6=7 adder for the full 64-bit result. > > You can use my CIAdd procedure from the Generic_Adder package. Here's > how to use it: > > function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is > use work.Generic_Adder.CIAdd; > constant w : natural := A'length; > alias aa : std_ulogic_vector(w-1 downto 0) is A; > alias bb : std_ulogic_vector(w-1 downto 0) is B; > variable yy, cc : std_ulogic_vector(w-1 downto 0); > variable pp, gg : std_ulogic; > begin > CIAdd(aa, bb, yy, cc, gg, pp); > -- we only care about yy here > return yy; > end "+"; The problem here is that a N+N addition will return a N-bit result. I remarked that when Simili elaborated the design and loudly complained of a size mismatch... How does one manage the cc, gg and pp outputs ? and how do we do an aggregate of the result, that is independent of the to/downto (direction) ? Another problem is the SIMD stuffs, which is even more complex than the adder tree... but that's a good exercise to any VHDL designer wannabe ... > Michael "Tired" Riepe WHYGEE, who's going to sleep now... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 5 15:00:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QUbE-0000EN-00 for ; Fri, 05 Jul 2002 17:02:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 17:02:20 +0200 (CEST) Received: (qmail 31605 invoked by uid 0); 5 Jul 2002 13:54:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 5 Jul 2002 13:54:47 -0000 Received: by moria.seul.org (Postfix) id AA4971467F7; Fri, 5 Jul 2002 09:54:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 96A03146933; Fri, 5 Jul 2002 09:54:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id 675F91467F7 for ; Fri, 5 Jul 2002 09:54:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00723; Fri, 5 Jul 2002 15:00:25 +0200 Message-ID: <20020705150025.01124@thrai.stud.uni-hannover.de> Date: Fri, 5 Jul 2002 15:00:25 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Remarks to most recent (2002/07/04) snapshot Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N EU_IDU (not ready yet): The 8-bit subtractor can be replaced with misc.Generic_Adder.CIAdd. EU_INC: The `bloc_and' entity and the tree of AND gates can probably be replaced with my misc.Bit_Manipulation.cascade_and function. Only the SIMD stuff needs to be added. Since only INC/DEC/LSB is supported, will there be a complementary unit for CMP/MSB? EU_POPC: Currently uses function "+" from IEEE.Numeric_Std (but that's going to change, fortunately). Please do NEVER use IEEE.Numeric_Std in your designs (it is acceptable in testbenches, however). I'm also missing delay indications in the new EUs. Do they all satisfy the 6G/10T rule? I doubt that e.g. the 8-bit divider from EU_IDU fits into a single pipeline stage, no matter how fast the subtractor is. Concerning component instantiations: First of all, there are too many. Please use functions or procedures whenever you can. And if something is used in several places, put it in a package. Also look into the packages in the common/ subdirectory - maybe the function you're looking for is already there. Second, if you instantiate a component, please use VHDL'87 style instantiation, that is: component blah ... end component; ... label : blah generic map (...) port map (...); The VHDL'93 `label : entity blah' instantiation style may be more convenient, but it requires blah to be analyzed first. With '87 style, you can analyze the source files in any order. And it will work with ALL tools (one never knows...). (Yann, you can put this into the VHDL HOWTO). In order to speed up simulation and synthesis, it's also a good idea to avoid signal assignments whenever possible. Use processes and sequential statements, and put temporary values into variables, not signals. Signal assignments are only needed for inter-process communication, pipeline registers and the like. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 5 13:46:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QUbF-0000EN-00 for ; Fri, 05 Jul 2002 17:02:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 17:02:21 +0200 (CEST) Received: (qmail 4796 invoked by uid 0); 5 Jul 2002 13:54:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 5 Jul 2002 13:54:54 -0000 Received: by moria.seul.org (Postfix) id 77787146933; Fri, 5 Jul 2002 09:54:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 58DDA146934; Fri, 5 Jul 2002 09:54:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id 08350146933 for ; Fri, 5 Jul 2002 09:54:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00505; Fri, 5 Jul 2002 13:46:06 +0200 Message-ID: <20020705134606.37233@thrai.stud.uni-hannover.de> Date: Fri, 5 Jul 2002 13:46:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> <20020705010544.52418@thrai.stud.uni-hannover.de> <3D24F843.43728A4B@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D24F843.43728A4B@f-cpu.org>; from Yann Guidon on Fri, Jul 05, 2002 at 03:37:07AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 05, 2002 at 03:37:07AM +0200, Yann Guidon wrote: [...] > > You can use my CIAdd procedure from the Generic_Adder package. Here's > > how to use it: > > > > function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is > > use work.Generic_Adder.CIAdd; > > constant w : natural := A'length; > > alias aa : std_ulogic_vector(w-1 downto 0) is A; > > alias bb : std_ulogic_vector(w-1 downto 0) is B; > > variable yy, cc : std_ulogic_vector(w-1 downto 0); > > variable pp, gg : std_ulogic; > > begin > > CIAdd(aa, bb, yy, cc, gg, pp); > > -- we only care about yy here > > return yy; > > end "+"; > > you mean, i copy it verbatim in the code ? This function, yes. You can of course call it differently (redefined operators are tricky sometimes). I probably should add something like that to package Generic_Adder. > > That should work at all operand sizes you need. But note that the > > delay will probably be big (d=4...5 per CIAdd), that is, a 64-bit > > result will need 4 pipeline stages :( We may reduce that to 3 if the > > adders are broken down into their components (CIA_Row and CIA_Inc). > i don't understand well... here the operands are 3 to 6 bit wide. The function above can add two operands that have the same size. Whether they both have 3, 4, 5, 6 or 64 (or 640) bits doesn't matter. The delay of the outputs, however, depends on the operand size: for 1...4 bit operands, the delay is d=4; for 5...8 bit, the delay increases to d=5. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 5 13:58:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QUbF-0000EN-01 for ; Fri, 05 Jul 2002 17:02:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 17:02:21 +0200 (CEST) Received: (qmail 24749 invoked by uid 0); 5 Jul 2002 13:54:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Jul 2002 13:54:57 -0000 Received: by moria.seul.org (Postfix) id 7938B146936; Fri, 5 Jul 2002 09:54:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5656B146939; Fri, 5 Jul 2002 09:54:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a225.home.uni-hannover.de [130.75.232.225]) by moria.seul.org (Postfix) with ESMTP id 8E59F146936 for ; Fri, 5 Jul 2002 09:54:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00535; Fri, 5 Jul 2002 13:58:23 +0200 Message-ID: <20020705135823.50326@thrai.stud.uni-hannover.de> Date: Fri, 5 Jul 2002 13:58:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> <20020705010544.52418@thrai.stud.uni-hannover.de> <3D2538F1.4C85B7FF@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2538F1.4C85B7FF@f-cpu.org>; from Yann Guidon on Fri, Jul 05, 2002 at 08:13:05AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 05, 2002 at 08:13:05AM +0200, Yann Guidon wrote: > huh, Houston ? i got a little issue... > > Michael Riepe wrote: > > > but bit 1 is not straight-forward at all). Currently i do it with a > > > lookup table in the integer world (that's lame but it should simulate > > > fast ;-D). Then there is a row of 8*(3+3=4) adders to make the byte results, > > > 4*(4+4=5) adders for the 4 shortint results, 2*(5+5=6) for the two lontgint > > > results and a final 6+6=7 adder for the full 64-bit result. > > > > You can use my CIAdd procedure from the Generic_Adder package. Here's > > how to use it: > > > > function "+" (A, B : in std_ulogic_vector) return std_ulogic_vector is > > use work.Generic_Adder.CIAdd; > > constant w : natural := A'length; > > alias aa : std_ulogic_vector(w-1 downto 0) is A; > > alias bb : std_ulogic_vector(w-1 downto 0) is B; > > variable yy, cc : std_ulogic_vector(w-1 downto 0); > > variable pp, gg : std_ulogic; > > begin > > CIAdd(aa, bb, yy, cc, gg, pp); > > -- we only care about yy here > > return yy; > > end "+"; > > The problem here is that a N+N addition will return a N-bit result. > I remarked that when Simili elaborated the design and loudly complained > of a size mismatch... Oh sorry... I forgot. You can use `gg' as the most significant output bit. That is, rename the function, change the declaration of yy to variable yy : std_ulogic_vector(w downto 0); and then call CIAdd(aa, bb, yy(w-1 downto 0), cc, yy(w), pp); return yy; (cc and pp are still unused dummies). > How does one manage the cc, gg and pp outputs ? and how do we do > an aggregate of the result, that is independent of the to/downto (direction) ? You'll need the other variables if you build an adder with carry-in/carry-out. `cc' is an `increment vector' for yy (like the INC EU uses it, but precomputed and with less delay than yy itself). That is, you can add a carry-in with yy := yy xor (cc and (cc'range => Cin)); Carry-out is generated from Cin, gg and pp: Cout := gg or (pp and Cin); If Cin = 0, the sum equals yy and Cout equals gg. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 5 20:57:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QYtv-0003ED-00 for ; Fri, 05 Jul 2002 21:37:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 05 Jul 2002 21:37:55 +0200 (CEST) Received: (qmail 22032 invoked by uid 0); 5 Jul 2002 18:49:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 5 Jul 2002 18:49:35 -0000 Received: by moria.seul.org (Postfix) id EAD61146802; Fri, 5 Jul 2002 14:49:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BB1E914693F; Fri, 5 Jul 2002 14:49:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 5F4FF146802 for ; Fri, 5 Jul 2002 14:49:33 -0400 (EDT) Received: from f-cpu.org (kdl11-20.n.club-internet.fr [213.44.9.20]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3320C16A3 for ; Fri, 5 Jul 2002 20:49:31 +0200 (CEST) Message-ID: <3D25EC32.2F4142FC@f-cpu.org> Date: Fri, 05 Jul 2002 20:57:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] I forgot to tell you... References: <200207040825.2db0@th00.opsion.fr> <20020704141523.60040@thrai.stud.uni-hannover.de> <3D2472F5.D232083F@f-cpu.org> <20020705010544.52418@thrai.stud.uni-hannover.de> <3D24F843.43728A4B@f-cpu.org> <20020705134606.37233@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Jul 05, 2002 at 03:37:07AM +0200, Yann Guidon wrote: > [...] > > you mean, i copy it verbatim in the code ? > > This function, yes. You can of course call it differently (redefined > operators are tricky sometimes). > > I probably should add something like that to package Generic_Adder. that would be cool, sure ! > > > That should work at all operand sizes you need. But note that the > > > delay will probably be big (d=4...5 per CIAdd), that is, a 64-bit > > > result will need 4 pipeline stages :( We may reduce that to 3 if the > > > adders are broken down into their components (CIA_Row and CIA_Inc). > > i don't understand well... here the operands are 3 to 6 bit wide. > The function above can add two operands that have the same size. > Whether they both have 3, 4, 5, 6 or 64 (or 640) bits doesn't matter. > > The delay of the outputs, however, depends on the operand size: for > 1...4 bit operands, the delay is d=4; for 5...8 bit, the delay increases > to d=5. ok, this is the kind of thing you could write in your readme :-) whether there is a 4-cycle latency for POPCOUNT is not a problem because it's not a "critical" unit. > On Fri, Jul 05, 2002 at 08:13:05AM +0200, Yann Guidon wrote: > > huh, Houston ? i got a little issue... > > > > The problem here is that a N+N addition will return a N-bit result. > > I remarked that when Simili elaborated the design and loudly complained > > of a size mismatch... > > Oh sorry... I forgot. You can use `gg' as the most significant output > bit. That is, rename the function, change the declaration of yy to > variable yy : std_ulogic_vector(w downto 0); > and then call > CIAdd(aa, bb, yy(w-1 downto 0), cc, yy(w), pp); > return yy; > (cc and pp are still unused dummies). cool, i'll try :-) > > How does one manage the cc, gg and pp outputs ? and how do we do > > an aggregate of the result, that is independent of the to/downto (direction) ? > You'll need the other variables if you build an adder with > carry-in/carry-out. `cc' is an `increment vector' for yy (like the > INC EU uses it, but precomputed and with less delay than yy itself). > That is, you can add a carry-in with > yy := yy xor (cc and (cc'range => Cin)); > Carry-out is generated from Cin, gg and pp: > Cout := gg or (pp and Cin); > If Cin = 0, the sum equals yy and Cout equals gg. wow, i hope you'll copy-paste it to your readme :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 6 00:12:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Qdmj-0006jD-00 for ; Sat, 06 Jul 2002 02:50:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Jul 2002 02:50:49 +0200 (CEST) Received: (qmail 4830 invoked by uid 0); 5 Jul 2002 22:04:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 5 Jul 2002 22:04:04 -0000 Received: by moria.seul.org (Postfix) id 7F5AF1467F7; Fri, 5 Jul 2002 18:04:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C2E814693F; Fri, 5 Jul 2002 18:04:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 8131B1467F7 for ; Fri, 5 Jul 2002 18:04:02 -0400 (EDT) Received: from f-cpu.org (kdl11-16.n.club-internet.fr [213.44.9.16]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 01B6416B5 for ; Sat, 6 Jul 2002 00:03:59 +0200 (CEST) Message-ID: <3D2619C7.50498152@f-cpu.org> Date: Sat, 06 Jul 2002 00:12:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Remarks to most recent (2002/07/04) snapshot References: <20020705150025.01124@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, Michael Riepe wrote: > EU_IDU (not ready yet): > The 8-bit subtractor can be replaced with misc.Generic_Adder.CIAdd. i'll try to do it. Cédric is busy with other things, but i'll do it anyway. > EU_INC: > > The `bloc_and' entity and the tree of AND gates can probably > be replaced with my misc.Bit_Manipulation.cascade_and function. > Only the SIMD stuff needs to be added. > > Since only INC/DEC/LSB is supported, will there be a complementary > unit for CMP/MSB? i don't think so, at least yet. INC now is a 1-cycle unit, i wanted to add a priority encoder but popcount does it nicely. i also wanted min/max but it can be done with a substract with saturation followed by a MUX in ROP2. > EU_POPC: > Currently uses function "+" from IEEE.Numeric_Std (but that's > going to change, fortunately). sure :-) > Please do NEVER use IEEE.Numeric_Std in your designs > (it is acceptable in testbenches, however). that was only a first version that could do the job in simulation. > I'm also missing delay indications in the new EUs. Do they all satisfy > the 6G/10T rule? I doubt that e.g. the 8-bit divider from EU_IDU fits > into a single pipeline stage, no matter how fast the subtractor is. that's a specific IDIV problem... Concerning the others, they are indicated in CAPABILITIES.txt. it's not always up to date but it gives a rough estimation. POPCOUNT will be updated too. > Concerning component instantiations: > > The VHDL'93 `label : entity blah' instantiation style may be > more convenient, but it requires blah to be analyzed first. > With '87 style, you can analyze the source files in any order. > And it will work with ALL tools (one never knows...). > > (Yann, you can put this into the VHDL HOWTO). i'll do > In order to speed up simulation and synthesis, it's also a good idea to > avoid signal assignments whenever possible. Use processes and sequential > statements, and put temporary values into variables, not signals. Signal > assignments are only needed for inter-process communication, pipeline > registers and the like. ok. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From baba-jo@address.com Sat Jul 6 00:38:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Qdmk-0006jD-01 for ; Sat, 06 Jul 2002 02:50:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Jul 2002 02:50:50 +0200 (CEST) Received: (qmail 18085 invoked by uid 0); 5 Jul 2002 22:37:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 5 Jul 2002 22:37:43 -0000 Received: by moria.seul.org (Postfix) id 246FD1467F7; Fri, 5 Jul 2002 18:37:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C43D14693F; Fri, 5 Jul 2002 18:37:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D18821467F7 for ; Fri, 5 Jul 2002 18:37:40 -0400 (EDT) Received: from Administrator (unknown [212.100.72.145]) by bettik.munge.net (Postfix) with ESMTP id 8EB4D4F7B4 for ; Fri, 5 Jul 2002 17:35:27 -0500 (CDT) From: baba-jo@address.com Subject: [f-cpu] BUSINESS INFO To: f-cpu@seul.org Content-Type: text/plain;;;;;;;;;;;;;;;;;;;;;;;;;;; Date: Fri, 5 Jul 2002 23:38:57 +0100 X-Priority: 3 X-Library: Indy 8.0.25 Message-Id: <20020705223527.8EB4D4F7B4@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N DR BABA OJO LAGOS, NIGERIA. A very good day to you. We have an immediate business proposal that involvesUS$ 21.320.000.00 (Twenty-one Million Three Hundred and Twenty ThousandUnited States Dollars) which we will like to invest under your custody. Once I receive a message from you notifying me of your interest,the details of the transaction/the terms and condition of sharing regarding the business would then be brought to your knowledge.Your urgent response will be highly appreciated and will swiftly bring us to the commencement of the transaction. We hope to conclude this transaction within 10-12 working days.Do not forget to contact me on the receipt of this e-mail address.And please you have to maintain absolute confidentiality as regards this pending transaction. I urgently await your response. Best Regards, DR BABA OJO NB:PLEASE QUOTE REFERENCE NUMBER FM/01 IN YOUR RESPONSE. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Sat Jul 6 14:25:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Qv1U-0000Fs-01 for ; Sat, 06 Jul 2002 21:15:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 06 Jul 2002 21:15:12 +0200 (CEST) Received: (qmail 3046 invoked by uid 0); 6 Jul 2002 13:06:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Jul 2002 13:06:49 -0000 Received: by moria.seul.org (Postfix) id 5EF70146945; Sat, 6 Jul 2002 09:06:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F861146947; Sat, 6 Jul 2002 09:06:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id DF3AC146945 for ; Sat, 6 Jul 2002 09:06:41 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-2-62-147-133-224.dial.proxad.net [62.147.133.224]) by postfix2-1.free.fr (Postfix) with SMTP id 3E50688A for ; Sat, 6 Jul 2002 15:06:40 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Sat, 6 Jul 2002 14:25:39 +0200 Date: Sat, 6 Jul 2002 14:25:39 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] Remarks to most recent (2002/07/04) snapshot Message-ID: <20020706122539.GB368@free.fr> References: <20020705150025.01124@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020705150025.01124@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 05, 2002 at 03:00:25PM +0200, Michael Riepe wrote: > EU_IDU (not ready yet): > > The 8-bit subtractor can be replaced with misc.Generic_Adder.CIAdd. > > EU_INC: > > The `bloc_and' entity and the tree of AND gates can probably > be replaced with my misc.Bit_Manipulation.cascade_and function. > Only the SIMD stuff needs to be added. Yes, i will try to include your generic function in my code. > > Since only INC/DEC/LSB is supported, will there be a complementary > unit for CMP/MSB? For the moment, the INC unit perform INC/DEC/NEG operation with only one cycle. I will add others operations support (CMP/MAX/MIN), but i don't know if it's possible with one cycle, because the size of end-MUX. Etienne ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jul 6 18:06:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QzWX-0003bd-01 for ; Sun, 07 Jul 2002 02:03:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Jul 2002 02:03:33 +0200 (CEST) Received: (qmail 4813 invoked by uid 0); 6 Jul 2002 21:44:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 6 Jul 2002 21:44:44 -0000 Received: by moria.seul.org (Postfix) id 0EBEC14694B; Sat, 6 Jul 2002 17:44:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D955A14694D; Sat, 6 Jul 2002 17:44:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a041.home.uni-hannover.de [130.75.232.41]) by moria.seul.org (Postfix) with ESMTP id 9B25A14694B for ; Sat, 6 Jul 2002 17:44:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01539; Sat, 6 Jul 2002 18:06:10 +0200 Message-ID: <20020706180610.64379@thrai.stud.uni-hannover.de> Date: Sat, 6 Jul 2002 18:06:10 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New upload Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I uploaded my latest sources (and also some documentation) to http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20020706.tar.gz -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sat Jul 6 23:38:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QzWZ-0003bd-01 for ; Sun, 07 Jul 2002 02:03:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Jul 2002 02:03:35 +0200 (CEST) Received: (qmail 3620 invoked by uid 0); 6 Jul 2002 22:08:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Jul 2002 22:08:02 -0000 Received: by moria.seul.org (Postfix) id E37EC1467FF; Sat, 6 Jul 2002 18:08:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ACE9014694C; Sat, 6 Jul 2002 18:08:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte14.axime.com [160.92.113.57]) by moria.seul.org (Postfix) with ESMTP id 510D71467FF for ; Sat, 6 Jul 2002 18:08:00 -0400 (EDT) Received: from laposte.net (193.250.154.4) by smtp.laposte.net (5.5.044) id 3CFD28F9001D669E for f-cpu@seul.org; Sun, 7 Jul 2002 00:07:59 +0200 Message-ID: <3D27633B.1040900@laposte.net> Date: Sat, 06 Jul 2002 23:38:03 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi all, I come back and take a long time to read all message... And more time to understand all :-) In the discution about loadcons, personnaly I agree with Michael Riepe solution, because it's possibly a bit more difficult to implement in hardware side (but I'm not sure... ) but it's a lot simpler and more powerfull in software side. And personnaly I think that the design of a cpu is to find a good middle between software and hardware. If you look at the x86 architecture, it was designed by hardware man, and look at the 68000 it was designed by software man, and all have problems, I think we must keep the two side in mind. Thanks for your attention. Tom PS: I've not used BabelFish but I'm not sure the result was better :-) -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sun Jul 7 00:24:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17QzWa-0003bd-01 for ; Sun, 07 Jul 2002 02:03:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Jul 2002 02:03:36 +0200 (CEST) Received: (qmail 26417 invoked by uid 0); 6 Jul 2002 22:27:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 6 Jul 2002 22:27:15 -0000 Received: by moria.seul.org (Postfix) id 66E881467FF; Sat, 6 Jul 2002 18:27:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F9A514694C; Sat, 6 Jul 2002 18:27:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A76E91467FF for ; Sat, 6 Jul 2002 18:27:12 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-217.jetnet.ab.ca [207.34.60.217]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g66MRC65093601 for ; Sat, 6 Jul 2002 16:27:13 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D276E08.C22676E2@jetnet.ab.ca> Date: Sat, 06 Jul 2002 16:24:08 -0600 From: Ben Franchuk X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> <3D27633B.1040900@laposte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thomas Lavergne wrote: > In the discution about loadcons, personnaly I agree with Michael Riepe > solution, because it's possibly a bit more difficult to implement in > hardware side (but I'm not sure... ) but it's a lot simpler and more > powerfull in software side. > And personnaly I think that the design of a cpu is to find a good middle > between software and hardware. > > If you look at the x86 architecture, it was designed by hardware man, > and look at the 68000 it was designed by software man, and all have > problems, I think we must keep the two side in mind. Right now it is hard to tell just how good the F-Cpu is with software, since none has been written. It is in the little werd segments of program code that you discover how well or bad your computer design is. Typical C code or O/S Calls look good but how well does it behave for a handwritten interface for some unknown fast function? Once the documentaion is final, some static programs hand assembled and desk debugged for common but dumb routines, block moves, strings and multiplies/divides using both simple instructions and higher level ones, to get a feel for the machine. Playing with my CPU design right now flags are the bottle neck, and need to be cleaned up. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 7 05:53:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17R3kc-0006rw-00 for ; Sun, 07 Jul 2002 06:34:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Jul 2002 06:34:22 +0200 (CEST) Received: (qmail 22977 invoked by uid 0); 7 Jul 2002 03:45:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 7 Jul 2002 03:45:23 -0000 Received: by moria.seul.org (Postfix) id 7BC1414694F; Sat, 6 Jul 2002 23:45:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 62C2A146951; Sat, 6 Jul 2002 23:45:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 10EC414694F for ; Sat, 6 Jul 2002 23:45:22 -0400 (EDT) Received: from f-cpu.org (kdl16-28.n.club-internet.fr [213.44.18.28]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 36B4F1683 for ; Sun, 7 Jul 2002 05:45:17 +0200 (CEST) Message-ID: <3D27BB46.9502D072@f-cpu.org> Date: Sun, 07 Jul 2002 05:53:42 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> <3D27633B.1040900@laposte.net> <3D276E08.C22676E2@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi all ! Ben Franchuk wrote: > Thomas Lavergne wrote: > > In the discution about loadcons, personnaly I agree with Michael Riepe > > solution, because it's possibly a bit more difficult to implement in > > hardware side (but I'm not sure... ) but it's a lot simpler and more > > powerfull in software side. being also a SW guy, i am rather suspicious about the "powerfull" thing. First, most of the code will be generated by a compiler, so it's a big factor. Second, i am worried about side effect and how they can be "exploited" by hand programmers which would learn bad habits. Finally, remember that the instruction must be easily scheduled on FC1, FC2, FC3 etc. and nobody has any idea about how they will be architectured. > > And personnaly I think that the design of a cpu is to find a good middle > > between software and hardware. certainly. This is why an instruction that looks "cool" on one architecture can become "unwanted" on another. Look at the x86 saga, with the ENTER/LEAVE or the LEA instructions that are ok, then that are not recommended, etc... Also remember that F-CPU is based on the RISC principles. Why make the Xbar more complex when it yields no speedup ? > > If you look at the x86 architecture, it was designed by hardware man, > > and look at the 68000 it was designed by software man, i don't know the full story, but i disagree... 68000 was designed like a "VAX on a chip", 8086 was an extension to a microcontroller. > > and all have problems, I think we must keep the two side in mind. > > Right now it is hard to tell just how good the F-Cpu is with software, > since none has been written. It is in the little werd segments of > program code that you discover how well or bad your computer design is. Typical > C code or O/S Calls look good but how well does it behave for a > handwritten interface for some unknown fast function? I don't know about the GCC and assembler things, but i am starting to design a cycle-acurate simulator. It is based on the experience i got last year with QDCPOC, and the methodology is much more rigid. the SW hackers will suffer because it uses the HW methodology, but the results WILL be good. I'll be there to watch if all the testbenches are correctly written and match the VHDL behaviours. > Once the documentaion is final, some static programs hand assembled > and desk debugged for common but dumb routines, block moves, strings > and multiplies/divides using both simple instructions and higher level > ones, to get a feel for the machine. > Playing with my CPU design right now flags are the bottle neck, and need > to be cleaned up. flags are a well-known bottleneck, right ? the risk with MR's shifting loadcons is that it will become a bottleneck on other architectures. I meet Etienne Labarre tomorrow at 4PM and i go to Bordeaux on monday. Stay tuned : this summer will be VERY HOT... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 7 05:53:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17R3kd-0006rw-00 for ; Sun, 07 Jul 2002 06:34:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 07 Jul 2002 06:34:23 +0200 (CEST) Received: (qmail 23077 invoked by uid 0); 7 Jul 2002 03:45:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 7 Jul 2002 03:45:27 -0000 Received: by moria.seul.org (Postfix) id D2D1C146950; Sat, 6 Jul 2002 23:45:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADA43146952; Sat, 6 Jul 2002 23:45:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 73313146950 for ; Sat, 6 Jul 2002 23:45:26 -0400 (EDT) Received: from f-cpu.org (kdl16-28.n.club-internet.fr [213.44.18.28]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 07B51169E for ; Sun, 7 Jul 2002 05:45:21 +0200 (CEST) Message-ID: <3D27BB48.D492F736@f-cpu.org> Date: Sun, 07 Jul 2002 05:53:44 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New upload References: <20020706180610.64379@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > I uploaded my latest sources (and also some documentation) to > http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20020706.tar.gz you see, when you want to do something good, you succeed ;-P now, i have to match that... > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sun Jul 7 14:36:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNB1-0000Wm-00 for ; Mon, 08 Jul 2002 03:18:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:18:55 +0200 (CEST) Received: (qmail 12852 invoked by uid 0); 7 Jul 2002 12:41:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 7 Jul 2002 12:41:30 -0000 Received: by moria.seul.org (Postfix) id DDB6D146956; Sun, 7 Jul 2002 08:41:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A443D146959; Sun, 7 Jul 2002 08:41:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte19.axime.com [160.92.113.201]) by moria.seul.org (Postfix) with ESMTP id 29BB7146956 for ; Sun, 7 Jul 2002 08:41:28 -0400 (EDT) Received: from laposte.net (193.250.154.69) by smtp.laposte.net (5.5.044) id 3D19D7080005E245 for f-cpu@seul.org; Sun, 7 Jul 2002 14:41:27 +0200 Message-ID: <3D2835B1.3060307@laposte.net> Date: Sun, 07 Jul 2002 14:36:01 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] Reamrks and suggestions about the manual Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Here's some remarks about the ISA decritpion in the manual, some are little write error, other are remarks about coding of the ISA... Page 94 ------- You have these two form defined at the start : addsubs r3, r2, r1 saddsubs r3, r2, r1 but no explication of the s suffixe later Page 104 -------- At the start you have : scmpli r3, r2, r1 instead of : scmpli Imm8, r2, r1 Page 114 -------- The lines : l2int r2, r1 sl2int r2, r1 Must be changed to : l2int[r/t/f/c] r2, r1 sl2int[r/t/f/c] r2, r1 For the rouding mode, if we use the bit 12-13 instead of the bit 11-12 the assembler can use the same constant for encoding l2int instruction and f2int (see page 144) Same reflexion for int2l. Page 128 -------- You have the following lines : bitrev r3, r2, r1 bitrevo r3, r2, r1 bitrev r2, r1 bitrevo r2, r1 but if we follow the convention used for other operand you must write it like : bitrev (r3,) r2, r1 bitrevo (r3,) r2, r1 (see popcount) Page 130 -------- For PopCount the reg for have r3 optional so the Imm form have the Imm8 optional (default 0) For Bitrev we have the same for the reg form but not for the Imm form. I think for uniformity of the ISA, we can set the Imm8 optional (default 0) Page 131 -------- byterev have the form (Imm8, r2, r1) but not use the Imm8 field, for the other operand we usually use the form (r3, r2, r1) for this case (allow more flag). Page 137 -------- This definition of the logic operand does not compail with the implementation of the rop2 unit, here the function was encoded with 4 bits and in the rop (see at page 52) the function was encoded with 3 bits and decoded with a lookup table. So you don't have the same functions avalable : not was not imlemented in the rop2 unit. Page 139 -------- You don't explain the encoding of the flags xtcs, I suppose it was the same than for the bitop operand but it could be could to say it. At the top of the page you say 'logici.xxxx' so I understand this style of codding 'logici.0111' like for the logic operand but ater you say 'logici.s' like for bitop, we must clarify this and I think it was best to have the same form for logic and logici even if we don't have all the function of logic in logici. Page 146 -------- Same remark than for byterev page 131 (see bellow) Page 147 -------- Same remark... Page 151 -------- Same remark... And at the top you write : fsqrt r3, r2, r1 instead of : fsqrt r2, r1 Page 154 -------- At the top you have write : smac r3, r2, r1 smacx r3, r2, r1 instead of sfmac r3, r2, r1 sfmacx r3, r2, r1 Page 162 -------- At the top you have write : loadie r3, r2, r1 instead of : loadie Imm8, r2, r1 Page 166 -------- cachemm have a form (op[8], flag[8], 0[4], r2[6], r1[6]) not referenced at the start of the manual page 69 Page 184 -------- loopentry use a non standard form (op[8], 0[18], r1[6]) Page 187 and more ----------------- Same remarks ... Forms remarks ------------- Page 69 you describ a form : (op[8], flag[12], r2[6], r1[6]) and used only at the end of the manual (the first was get), but it could be used in a lot of case, ie when we don't need the r3 register, and it could solve the problem for cachemm (who don't use a standard form) -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sun Jul 7 14:42:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNB1-0000Wm-01 for ; Mon, 08 Jul 2002 03:18:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:18:55 +0200 (CEST) Received: (qmail 23685 invoked by uid 0); 7 Jul 2002 12:47:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 7 Jul 2002 12:47:33 -0000 Received: by moria.seul.org (Postfix) id A3083146958; Sun, 7 Jul 2002 08:47:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 670AB14695A; Sun, 7 Jul 2002 08:47:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 1204D146958 for ; Sun, 7 Jul 2002 08:47:32 -0400 (EDT) Received: from laposte.net (193.250.154.69) by smtp.laposte.net (5.5.044) id 3CF4B313002AD1B7 for f-cpu@seul.org; Sun, 7 Jul 2002 14:47:31 +0200 Message-ID: <3D28371C.9000808@laposte.net> Date: Sun, 07 Jul 2002 14:42:04 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Late answer References: <3D0FCF46.1584D826@f-cpu.org> <20020619154718.58467@thrai.stud.uni-hannover.de> <3D11517D.6123504@f-cpu.org> <20020620203042.39024@thrai.stud.uni-hannover.de> <3D125C82.7D96EAEF@f-cpu.org> <3D27633B.1040900@laposte.net> <3D276E08.C22676E2@jetnet.ab.ca> <3D27BB46.9502D072@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > hi all ! > > Ben Franchuk wrote: > >>Thomas Lavergne wrote: >> >>>In the discution about loadcons, personnaly I agree with Michael Riepe >>>solution, because it's possibly a bit more difficult to implement in >>>hardware side (but I'm not sure... ) but it's a lot simpler and more >>>powerfull in software side. >> > being also a SW guy, i am rather suspicious about the "powerfull" thing. > First, most of the code will be generated by a compiler, so it's a big factor. Ok, but if we can make work of compiler easier, why not doing it ? > Second, i am worried about side effect and how they can be "exploited" > by hand programmers which would learn bad habits. If we you the ACC trick we don't have more side effect than with your loadcons. > Finally, remember that the instruction must be easily scheduled on > FC1, FC2, FC3 etc. and nobody has any idea about how they will be > architectured. Ok, but I'm not sure your loadcons was more adapted. > >>>And personnaly I think that the design of a cpu is to find a good middle >>>between software and hardware. >> > certainly. This is why an instruction that looks "cool" on one architecture > can become "unwanted" on another. Look at the x86 saga, with the ENTER/LEAVE > or the LEA instructions that are ok, then that are not recommended, etc... > Also remember that F-CPU is based on the RISC principles. Why make the Xbar > more complex when it yields no speedup ? > We don't make the XBar more complex if we use an ACC >>Once the documentaion is final, some static programs hand assembled >>and desk debugged for common but dumb routines, block moves, strings >>and multiplies/divides using both simple instructions and higher level >>ones, to get a feel for the machine. >>Playing with my CPU design right now flags are the bottle neck, and need >>to be cleaned up. > > flags are a well-known bottleneck, right ? > > the risk with MR's shifting loadcons is that it will become > a bottleneck on other architectures. Not more than other approch, and this was the advantage to easisly allow loading of any size constant. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jul 7 15:40:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNB3-0000Wm-00 for ; Mon, 08 Jul 2002 03:18:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:18:57 +0200 (CEST) Received: (qmail 7935 invoked by uid 0); 7 Jul 2002 16:48:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 7 Jul 2002 16:48:25 -0000 Received: by moria.seul.org (Postfix) id 36F711467EE; Sun, 7 Jul 2002 12:48:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E094D1467F4; Sun, 7 Jul 2002 12:48:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a064.home.uni-hannover.de [130.75.232.64]) by moria.seul.org (Postfix) with ESMTP id DD59B1467EE for ; Sun, 7 Jul 2002 12:48:03 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00538; Sun, 7 Jul 2002 15:40:02 +0200 Message-ID: <20020707154002.19354@thrai.stud.uni-hannover.de> Date: Sun, 7 Jul 2002 15:40:02 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Reamrks and suggestions about the manual References: <3D2835B1.3060307@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2835B1.3060307@laposte.net>; from Thomas Lavergne on Sun, Jul 07, 2002 at 02:36:01PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 07, 2002 at 02:36:01PM +0200, Thomas Lavergne wrote: > Here's some remarks about the ISA decritpion in the manual, some are > little write error, other are remarks about coding of the ISA... > > Page 94 > ------- > > You have these two form defined at the start : > addsubs r3, r2, r1 > saddsubs r3, r2, r1 > > but no explication of the s suffixe later That might mean `saturated'. [...] > Page 139 > -------- > > You don't explain the encoding of the flags xtcs, I suppose it was the > same than for the bitop operand but it could be could to say it. > > At the top of the page you say 'logici.xxxx' so I understand this style > of codding 'logici.0111' like for the logic operand but ater you say > 'logici.s' like for bitop, we must clarify this and I think it was best > to have the same form for logic and logici even if we don't have all the > function of logic in logici. The `logic[i].xxxx' instruction is obsolete. And it's rather hard to grok right because the function encoding is non-intuitive - e.g. does `logic.0010 A, B, C' mean `A and not B' or `B and not A'? Is `logic.0001' an AND or NOR operation? Both variants are possible, depending on the interpretation of the function field. ROP2 instructions and bitop use the same function encoding for the AND/ANDN/XOR/OR functions (using bits stolen from the 8-bit opcode field). According to the VHDL source, the encoding is 000 - and (ROP2/bitop) 001 - andn (ROP2/bitop) 010 - xor (ROP2/bitop) 011 - or (ROP2/bitop) 100 - nor (ROP2 only) 101 - xnor (ROP2 only) 110 - orn (ROP2 only) 111 - nand (ROP2 only) [...] > Page 184 > -------- > > loopentry use a non standard form (op[8], 0[18], r1[6]) `loopentry r1' is a special case; it's equivalent to `loadaddri 0, r1'. That is, the encoding is (op[8], flags[2], imm[16], r1[6]) with an immediate of zero and both flags cleared (D=0 because it's not a data address, S=0 because the immediate is not negative). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sun Jul 7 20:13:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNB3-0000Wm-01 for ; Mon, 08 Jul 2002 03:18:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:18:57 +0200 (CEST) Received: (qmail 14085 invoked by uid 0); 7 Jul 2002 18:19:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Jul 2002 18:19:12 -0000 Received: by moria.seul.org (Postfix) id 3DE69146952; Sun, 7 Jul 2002 14:19:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0AB7B146955; Sun, 7 Jul 2002 14:19:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte04.axime.com [160.92.113.39]) by moria.seul.org (Postfix) with ESMTP id 987C5146952 for ; Sun, 7 Jul 2002 14:19:09 -0400 (EDT) Received: from laposte.net (193.250.226.87) by smtp.laposte.net (5.5.044) id 3CF4B313002AECCC for f-cpu@seul.org; Sun, 7 Jul 2002 20:19:08 +0200 Message-ID: <3D2884D2.9060900@laposte.net> Date: Sun, 07 Jul 2002 20:13:38 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Reamrks and suggestions about the manual References: <3D2835B1.3060307@laposte.net> <20020707154002.19354@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I agree with all your remark but I think this must be clrified in the manual. Michael Riepe wrote: > On Sun, Jul 07, 2002 at 02:36:01PM +0200, Thomas Lavergne wrote: > >>Here's some remarks about the ISA decritpion in the manual, some are >>little write error, other are remarks about coding of the ISA... >> >>Page 94 >>------- >> >>You have these two form defined at the start : >> addsubs r3, r2, r1 >> saddsubs r3, r2, r1 >> >>but no explication of the s suffixe later > > > That might mean `saturated'. > > [...] > >>Page 139 >>-------- >> >>You don't explain the encoding of the flags xtcs, I suppose it was the >>same than for the bitop operand but it could be could to say it. >> >>At the top of the page you say 'logici.xxxx' so I understand this style >>of codding 'logici.0111' like for the logic operand but ater you say >>'logici.s' like for bitop, we must clarify this and I think it was best >>to have the same form for logic and logici even if we don't have all the >>function of logic in logici. > > > The `logic[i].xxxx' instruction is obsolete. And it's rather hard to > grok right because the function encoding is non-intuitive - e.g. does > `logic.0010 A, B, C' mean `A and not B' or `B and not A'? Is `logic.0001' > an AND or NOR operation? Both variants are possible, depending on the > interpretation of the function field. > > ROP2 instructions and bitop use the same function encoding for the > AND/ANDN/XOR/OR functions (using bits stolen from the 8-bit opcode field). > According to the VHDL source, the encoding is > > 000 - and (ROP2/bitop) > 001 - andn (ROP2/bitop) > 010 - xor (ROP2/bitop) > 011 - or (ROP2/bitop) > 100 - nor (ROP2 only) > 101 - xnor (ROP2 only) > 110 - orn (ROP2 only) > 111 - nand (ROP2 only) > > [...] > >>Page 184 >>-------- >> >>loopentry use a non standard form (op[8], 0[18], r1[6]) > > > `loopentry r1' is a special case; it's equivalent to `loadaddri 0, r1'. > That is, the encoding is (op[8], flags[2], imm[16], r1[6]) with an > immediate of zero and both flags cleared (D=0 because it's not a data > address, S=0 because the immediate is not negative). > -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 8 00:06:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNBK-0000Wm-00 for ; Mon, 08 Jul 2002 03:19:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:19:14 +0200 (CEST) Received: (qmail 8801 invoked by uid 0); 7 Jul 2002 21:58:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 7 Jul 2002 21:58:32 -0000 Received: by moria.seul.org (Postfix) id CA9EC1467F8; Sun, 7 Jul 2002 17:58:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BFC05146803; Sun, 7 Jul 2002 17:58:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7F29A1467F8 for ; Sun, 7 Jul 2002 17:58:31 -0400 (EDT) Received: from f-cpu.org (kdl14-16.n.club-internet.fr [213.44.12.16]) by relay-3v.club-internet.fr (Postfix) with ESMTP id A438E16A0 for ; Sun, 7 Jul 2002 23:58:28 +0200 (CEST) Message-ID: <3D28BB81.214ED858@f-cpu.org> Date: Mon, 08 Jul 2002 00:06:57 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Reamrks and suggestions about the manual References: <3D2835B1.3060307@laposte.net> <20020707154002.19354@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, just a few remarks, Michael Riepe wrote: > On Sun, Jul 07, 2002 at 02:36:01PM +0200, Thomas Lavergne wrote: > > Here's some remarks about the ISA decritpion in the manual, some are > > little write error, other are remarks about coding of the ISA... as you have remarked : there are a lot of things to change. But this manual is getting old and can be used as an historical reference... the implementation has changed too quickly to keep it acurate. > [...] > > At the top of the page you say 'logici.xxxx' so I understand this style > > of codding 'logici.0111' like for the logic operand but ater you say > > 'logici.s' like for bitop, we must clarify this and I think it was best > > to have the same form for logic and logici even if we don't have all the > > function of logic in logici. > > The `logic[i].xxxx' instruction is obsolete. And it's rather hard to > grok right because the function encoding is non-intuitive - e.g. does > `logic.0010 A, B, C' mean `A and not B' or `B and not A'? Is `logic.0001' > an AND or NOR operation? Both variants are possible, depending on the > interpretation of the function field. There is another problem : when one of the operands is negated (ANDN and ORN), which one is it ? currently, the VHDL source is the de facto reference and Cédric is in charge of maintaining the manual, but it's a hard task. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 8 00:20:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNBK-0000Wm-01 for ; Mon, 08 Jul 2002 03:19:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:19:14 +0200 (CEST) Received: (qmail 5154 invoked by uid 0); 7 Jul 2002 22:20:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 7 Jul 2002 22:20:23 -0000 Received: by moria.seul.org (Postfix) id 159321467FC; Sun, 7 Jul 2002 18:20:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C55FE14680B; Sun, 7 Jul 2002 18:20:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a157.home.uni-hannover.de [130.75.232.157]) by moria.seul.org (Postfix) with ESMTP id 10B901467FC for ; Sun, 7 Jul 2002 18:20:20 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02110; Mon, 8 Jul 2002 00:20:24 +0200 Message-ID: <20020708002024.39526@thrai.stud.uni-hannover.de> Date: Mon, 8 Jul 2002 00:20:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Reamrks and suggestions about the manual References: <3D2835B1.3060307@laposte.net> <20020707154002.19354@thrai.stud.uni-hannover.de> <3D28BB81.214ED858@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D28BB81.214ED858@f-cpu.org>; from Yann Guidon on Mon, Jul 08, 2002 at 12:06:57AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 08, 2002 at 12:06:57AM +0200, Yann Guidon wrote: [...] > > > At the top of the page you say 'logici.xxxx' so I understand this style > > > of codding 'logici.0111' like for the logic operand but ater you say > > > 'logici.s' like for bitop, we must clarify this and I think it was best > > > to have the same form for logic and logici even if we don't have all the > > > function of logic in logici. > > > > The `logic[i].xxxx' instruction is obsolete. And it's rather hard to > > grok right because the function encoding is non-intuitive - e.g. does > > `logic.0010 A, B, C' mean `A and not B' or `B and not A'? Is `logic.0001' > > an AND or NOR operation? Both variants are possible, depending on the > > interpretation of the function field. > > There is another problem : when one of the operands is negated > (ANDN and ORN), which one is it ? Since all operands have the form operation r3-or-imm8, r2, r1 and the mathematical interpretation is r1 := r2 r3 and `andn' means `and not', r1 := r2 and not r3 is the logical choice. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Mon Jul 8 01:19:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNBM-0000Wm-00 for ; Mon, 08 Jul 2002 03:19:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:19:16 +0200 (CEST) Received: (qmail 21565 invoked by uid 0); 7 Jul 2002 23:24:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 7 Jul 2002 23:24:40 -0000 Received: by moria.seul.org (Postfix) id 166D014680B; Sun, 7 Jul 2002 19:24:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EFE4114680F; Sun, 7 Jul 2002 19:24:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (nposte20.axime.com [160.92.113.202]) by moria.seul.org (Postfix) with ESMTP id 9586D14680B for ; Sun, 7 Jul 2002 19:24:33 -0400 (EDT) Received: from laposte.net (193.250.226.208) by smtp.laposte.net (5.5.044) id 3D19CF890007DC21 for f-cpu@seul.org; Mon, 8 Jul 2002 01:24:32 +0200 Message-ID: <3D28CC69.40104@laposte.net> Date: Mon, 08 Jul 2002 01:19:05 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Reamrks and suggestions about the manual References: <3D2835B1.3060307@laposte.net> <20020707154002.19354@thrai.stud.uni-hannover.de> <3D28BB81.214ED858@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > > as you have remarked : there are a lot of things to change. > But this manual is getting old and can be used as an historical > reference... the implementation has changed too quickly to > keep it acurate. > [...] > > currently, the VHDL source is the de facto reference and Cédric is > in charge of maintaining the manual, but it's a hard task. > I don't blame anyone, I just try help people in this hard task, I understand it was difficult to keep it up to date. I've thinking about the instruction format problem (some instruction don't have a standard format) and see that all instruction can be coded with standard format without any change in their encoding, we just need these switch (old format was compatible with new) : OpCode Format cachemm r2, r1 loopentry r2, r1 (with r2 set to 0) halt r2, r1 (with r2 and r1 set to 0) ... (until serialize) byterev r3, r2, r1 fiaprx r3, r2, r1 fsqrtiaprx r3, r2, r1 fsqrt r3, r2, r1 The last four was only for uniformity with the other op in the manual. It's possible to create a new format without reg or imm, only flag, because we have a suficient amount of instruction for justify it, but I think it was not so usefull, the format (r2, r1) allow 12 flag and it was sufficiently. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 8 02:14:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17RNBN-0000Wm-00 for ; Mon, 08 Jul 2002 03:19:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 08 Jul 2002 03:19:17 +0200 (CEST) Received: (qmail 16092 invoked by uid 0); 8 Jul 2002 00:06:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 8 Jul 2002 00:06:32 -0000 Received: by moria.seul.org (Postfix) id 1F59614680C; Sun, 7 Jul 2002 20:06:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E8603146813; Sun, 7 Jul 2002 20:06:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7408114680C for ; Sun, 7 Jul 2002 20:06:30 -0400 (EDT) Received: from f-cpu.org (kdl11-14.n.club-internet.fr [213.44.9.14]) by relay-3v.club-internet.fr (Postfix) with ESMTP id EB03116A8 for ; Mon, 8 Jul 2002 02:06:26 +0200 (CEST) Message-ID: <3D28D97F.7D818717@f-cpu.org> Date: Mon, 08 Jul 2002 02:14:55 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] before i go to Bordeaux... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, just to let you know that i am uploading yet another snapshot. It's more or less functionning and it's aimed at the "active" people (those who write code too). There are still some small bugs in the "core" VHDL stuff and i just started yet another C thing... I met Etienne today and we agreed on one thing : we are currently rewriting our units (he maintains INC and i maintain ROP2) to comply with Michael's recommendations. However we don't want to do that all the time and synthesis will be another difficult time. So we better do it now. Conclusion : it's now time to seek FPGA partners which would at least provide a synthesizer, so we can check whether our code is correctly elaborated. If you have friends in this branch, please tell them about F-CPU ;-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jul 8 15:01:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Rj6N-0007XC-00 for ; Tue, 09 Jul 2002 02:43:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Jul 2002 02:43:35 +0200 (CEST) Received: (qmail 21495 invoked by uid 0); 8 Jul 2002 13:01:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 8 Jul 2002 13:01:37 -0000 Received: by moria.seul.org (Postfix) id 5B3E3146958; Mon, 8 Jul 2002 09:01:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F24A14695A; Mon, 8 Jul 2002 09:01:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B8AFC146958 for ; Mon, 8 Jul 2002 09:01:35 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207081301.1a79; Mon, 8 Jul 2002 13:01:26 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Tr:[ff] Syntetisation d'un FCPU? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jul 2002 13:01:26 GMT Message-id: <200207081301.1a79@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N A french guy have access to a big FPGA board (XCV1000) until= the 20 july. Maybe it's possible to write some executable testbench= ? Does it have an interrest compare to the simulated one ? Maybe it's = have an interrest for timing test ? (all unit must run at the same s= peed) We could ask him to start to synthetis each unit and send th= e timing report. nicO -----Message d'origine----- De: "Arg0S HargOS" A: Date: 08/07/02 Objet: [ff] Syntetisation d'un FCPU? Comme j'en ai parle a certains qui etaient au First Jeudi, j= 'ai peut-etre la possibilit=E9 de toucher a un FPGA d'un million= de portes (un XILINX XCV1000 pour etre exact), o=F9 je bosse.=20 Mais, ne vous emballez pas:=20 - Je suis dans cette boite jusqu'au 20 juillet seuleument. - La personne qui bosse sur ce FPGA n'est pas souvent la en= ce moment (et je n'y toucherai pas sans sa presence) - Le FPGA est utilis=E9 en ce moment dans une application. = Ca veut dire qu'on ne peut pas le squatter longtemps. - Je ne sais pas du tout comment il marche ce FPGA (et ca a= l'air complique...). Je ne sais pas non plus comment on va pouvoir= le tester une fois synthetis=E9. Bref, moi, je vois ca difficilement fesable, mais je ne suis= pas expert. A+ J=E9rome Pouiller=20 =20 ____________________________________________________________= ____________ ______ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jul 8 16:32:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Rj6O-0007XC-00 for ; Tue, 09 Jul 2002 02:43:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Jul 2002 02:43:36 +0200 (CEST) Received: (qmail 25140 invoked by uid 0); 8 Jul 2002 14:32:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 8 Jul 2002 14:32:36 -0000 Received: by moria.seul.org (Postfix) id 095CF1467EE; Mon, 8 Jul 2002 10:32:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C97171467FC; Mon, 8 Jul 2002 10:32:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 33DCD1467EE for ; Mon, 8 Jul 2002 10:32:34 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207081432.17d0; Mon, 8 Jul 2002 14:32:23 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] vsim From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jul 2002 14:32:23 GMT Message-id: <200207081432.17d0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I have run vsim on the eu_imu. here is the result on a Ultra= Blade 1650 (bi UIII 650 Mhz 512 Mb thought NFS file system) the run use= 9 Mb of memory. No special option are used for vcom nor vsim. imu64_test3 : real 0m12.671s user 0m4.830s sys 0m0.410s imu64_test2 real 5m49.004s user 5m47.730s sys 0m0.130s the first test is a bit too long for today ! ;p Does somebod= y have the number for ncsim and simily ? To compare. nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jul 8 17:16:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Rj6Q-0007XC-00 for ; Tue, 09 Jul 2002 02:43:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Jul 2002 02:43:38 +0200 (CEST) Received: (qmail 4727 invoked by uid 0); 8 Jul 2002 15:17:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 8 Jul 2002 15:17:02 -0000 Received: by moria.seul.org (Postfix) id 82D8A1467EE; Mon, 8 Jul 2002 11:17:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 633741467FC; Mon, 8 Jul 2002 11:17:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id A0F381467EE for ; Mon, 8 Jul 2002 11:16:59 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207081516.3347; Mon, 8 Jul 2002 15:16:51 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] vsim From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jul 2002 15:16:51 GMT Message-id: <200207081516.3347@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Et voila : imu64_test : real 43m37.359s user 43m27.900s sys 0m0.400s so the others number ? nicO -----Message d'origine----- De: "Nicolas Boulay" A: Date: 08/07/02 Objet: [f-cpu] vsim I have run vsim on the eu_imu. here is the result on a Ultra= Blade 1650 (bi UIII 650 Mhz 512 Mb thought NFS file system) the run use= 9 Mb of memory. No special option are used for vcom nor vsim. imu64_test3 : real 0m12.671s user 0m4.830s sys 0m0.410s imu64_test2 real 5m49.004s user 5m47.730s sys 0m0.130s the first test is a bit too long for today ! ;p Does somebod= y have the number for ncsim and simily ? To compare. nicO =20 ____________________________________________________________= ____________ ______ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 8 21:36:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Rj6R-0007XC-00 for ; Tue, 09 Jul 2002 02:43:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 09 Jul 2002 02:43:39 +0200 (CEST) Received: (qmail 2781 invoked by uid 0); 8 Jul 2002 19:43:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 8 Jul 2002 19:43:05 -0000 Received: by moria.seul.org (Postfix) id B0DAB1467ED; Mon, 8 Jul 2002 15:43:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A2D921467F3; Mon, 8 Jul 2002 15:43:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a216.home.uni-hannover.de [130.75.232.216]) by moria.seul.org (Postfix) with ESMTP id 4BC4A1467ED for ; Mon, 8 Jul 2002 15:43:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01773; Mon, 8 Jul 2002 21:36:10 +0200 Message-ID: <20020708213609.53076@thrai.stud.uni-hannover.de> Date: Mon, 8 Jul 2002 21:36:09 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Tr:[ff] Syntetisation d'un FCPU? References: <200207081301.1a79@th00.opsion.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=gBBFr7Ir9EOA20Yy X-Mailer: Mutt 0.84e In-Reply-To: <200207081301.1a79@th00.opsion.fr>; from Nicolas Boulay on Mon, Jul 08, 2002 at 01:01:26PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii On Mon, Jul 08, 2002 at 01:01:26PM +0000, Nicolas Boulay wrote: > A french guy have access to a big FPGA board (XCV1000) until the 20 > july. Maybe it's possible to write some executable testbench ? Does it > have an interrest compare to the simulated one ? Maybe it's have an > interrest for timing test ? (all unit must run at the same speed) Try the one below. It continuously calculates Y := A * Y + B with user-defined A and B and an initial Y of 0. A, B and the clock must be supplied externally. The Y output should change every 8 cycles. You can also run a simulation of the second entity (Test_Test) and watch the numbers flow by... but don't wait for it to finish; it runs forever. (Yann, *now* you have reason to complain that my testbenches take too long ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="eu_timing_test.vhdl" -- eu_timing_test.vhdl - IMU/ASU timing test -- Copyright (C) 2002 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- $Id$ library IEEE; use IEEE.std_logic_1164.all; use work.FCPU_config.all; entity EU_Timing_Test is port ( A, B : in F_VECTOR; Clk : in std_ulogic; Y : out F_VECTOR ); end EU_Timing_Test; architecture Struct_1 of EU_Timing_Test is component EU_ASU port( Din_0 : in F_VECTOR; Din_1 : in F_VECTOR; Subtract : in std_ulogic; Flags : in std_ulogic_vector(13 downto 8); Size : in std_ulogic_vector(LOGMAXSIZE-1 downto 0); Clk : in std_ulogic; Rst : in std_ulogic; En : in std_ulogic; -- Dout_0 : out F_VECTOR; Dout_1 : out F_VECTOR; Dout_2 : out F_VECTOR; Dout_3 : out F_VECTOR ); end component; component EU_IMU port( Din_0 : in F_VECTOR; -- multiplicand Din_1 : in F_VECTOR; -- multiplicator Din_2 : in F_VECTOR; -- summand (optional) MacLo : in std_ulogic; MacHi : in std_ulogic; MacAlt : in std_ulogic; Flags : in std_ulogic_vector(13 downto 8); Size : in std_ulogic_vector(LOGMAXSIZE-1 downto 0); Clk : in std_ulogic; Rst : in std_ulogic; En : in std_ulogic; -- Dout_0 : out F_VECTOR; Dout_1 : out F_VECTOR; Dout_2 : out F_VECTOR; Dout_3 : out F_VECTOR; Dout_4 : out F_VECTOR; Dout_5 : out F_VECTOR; Dout_6 : out F_VECTOR; Dout_7 : out F_VECTOR ); end component; constant zero : std_ulogic := '0'; constant one : std_ulogic := '1'; constant v0 : F_VECTOR := (others => '0'); constant v1 : F_VECTOR := (others => '1'); signal T, X : F_VECTOR; signal r_T, r_X : F_VECTOR; signal En_IMU, En_ASU : std_ulogic; signal State : integer := 0; begin multiplier : EU_IMU port map ( Din_0 => A, Din_1 => r_X, Din_2 => v0, MacLo => zero, MacHi => zero, MacAlt => zero, Flags => v0(13 downto 8), Size => v1(LOGMAXSIZE-1 downto 0), Clk => Clk, Rst => zero, En => En_IMU, Dout_6 => T ); adder : EU_ASU port map ( Din_0 => r_T, Din_1 => B, Subtract => zero, Flags => v0(13 downto 8), Size => v1(LOGMAXSIZE-1 downto 0), Clk => Clk, Rst => zero, En => En_ASU, Dout_2 => X ); -- output Y <= r_X; control : process (Clk, State, T, X) variable nextstate : integer; begin if rising_edge(Clk) then En_ASU <= '0'; En_IMU <= '0'; nextstate := State + 1; case State is when 0 => r_X <= (others => '0'); En_IMU <= '1'; when 6 => r_T <= T; En_ASU <= '1'; when 8 => r_X <= X; En_IMU <= '1'; nextstate := 1; when others => null; end case; State <= nextstate; end if; end process; end Struct_1; -- pragma synthesis_off library IEEE; use IEEE.std_logic_1164.all; use work.FCPU_config.all; entity Test_Test is end Test_Test; architecture Blah of Test_Test is component EU_Timing_Test port ( A, B : in F_VECTOR; Clk : in std_ulogic; Y : out F_VECTOR ); end component; signal A, B, Y : F_VECTOR; signal Clk : std_ulogic; begin mut : EU_Timing_Test port map (A => A, B => B, Clk => Clk, Y => Y); A <= X"0000000000000003"; B <= X"0000000000000001"; monitor : process (Y) use std.textio.all; use ieee.std_logic_textio.all; variable lout : line; begin write(lout, string'("Y = ")); write(lout, Y); writeline(output, lout); end process; clock : process begin Clk <= '0'; wait for 1 ns; Clk <= '1'; wait for 1 ns; end process; end Blah; -- pragma synthesis_on -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --gBBFr7Ir9EOA20Yy-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 10 13:49:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SHNn-0005LT-00 for ; Wed, 10 Jul 2002 15:19:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 10 Jul 2002 15:19:51 +0200 (CEST) Received: (qmail 7218 invoked by uid 0); 10 Jul 2002 11:51:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 10 Jul 2002 11:51:12 -0000 Received: by moria.seul.org (Postfix) id E0758146828; Wed, 10 Jul 2002 07:51:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5316146832; Wed, 10 Jul 2002 07:51:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a107.home.uni-hannover.de [130.75.232.107]) by moria.seul.org (Postfix) with ESMTP id CA3A6146828 for ; Wed, 10 Jul 2002 07:51:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00745; Wed, 10 Jul 2002 13:49:41 +0200 Message-ID: <20020710134941.01764@thrai.stud.uni-hannover.de> Date: Wed, 10 Jul 2002 13:49:41 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Coding for Synthesis Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N [Yann, you may copy&paste this to the VHDL HOWTO if you wish] VHDL is a very powerful language, but synthesis tools support only a rather limited subset of it. Many constructions that work fine during simulation won't be accepted by synthesizers at all. Since some of you are going to rewrite their units (and expressed their wishes to do it only *once* ;), I'll give you some more hints. - processes, wait statements and sensitivity lists: DO NOT use `wait' statements; always write processes with an explicit sensitivity list. Make sure that every signal that is used (= read) inside the process is also mentioned in its sensitivity list. - clocked circuits: In order to instantiate flipflops (or pipeline registers), use the following idiom: process (...) ... begin expression1 := ...; expression2 := ...; expression3 := ...; ... if rising_edge(clock_signal) then signal1 <= expression1; signal2 <= expression2; signal3 <= expression3; ... end if; end process; Note that there must be AT MOST ONE `if rising_edge(clock_signal)' inside a particular process, the conditional expression MUST NOT have other elements, and the `if' statement MUST NOT have `elsif' or `else' clauses. The `if rising_edge(clock_signal)' may be nested inside another `if' statement (or may be an `elsif' clause itself), but you should limit this use to the cases listed below. Also note that use of rising_edge() - or the signal'event attribute - is NOT supported inside functions or procedures! BTW: It is considered good style to write one process per pipeline stage (unless the pipeline is `forked'), and put the `if rising_edge(clock_signal)' clause at the very end of the process, as shown. - clock enable and reset: If you need a clock enable signal and asynchronous reset, you can write: if to_X01(async_reset) = '1' then some_signal <= '0'; elsif rising_edge(clock_signal) then if to_X01(clock_enable) = '1' then some_signal <= some_expression; end if; end if; Synchronous reset is also possible: if rising_edge(clock_signal) then if to_X01(sync_reset) = '1' then some_signal <= '0'; elsif to_X01(clock_enable) = '1' then some_signal <= some_expression; end if; end if; But I used asynchronous reset everywhere. - pipeline enable: If your unit has more than two pipeline stages, you probably want to chain the enable signal. That is, the enable signal `travels' through the pipeline together with the data `wavefront' (I used that trick in the IMU in order to save power). To do so, provide an `enable out' signal in each stage: if to_X01(async_reset) = '1' then some_signal <= '0'; enable_out <= '0'; elsif rising_edge(clock_signal) then if to_X01(enable_in) = '1' then some_signal <= some_expression; end if; enable_out <= enable_in; end if; Then, connect `enable_out' of stage to `enable_in' of stage . - multibit: Avoid fiddling with individual bits if a vector will do. It is a good idea to put more complex operations inside a procedure or function, and then apply that to its argument vectors (if there is a single result vector, please use a function). Some operations are already defined. E.g. `reduce_and' calculates A(A'low) and A(A'low+1) and ... and A(A'high) for an arbitrary std_ulogic_vector A; analogously, `reduce_or' and `reduce_xor' perform the `or' and `xor' operations. These functions (among others) can be found in package Bit_Manipulation in the common/ subdirectory, and are documented in common/doc/. - while loops: The sequential `while ... loop' statement is not supported by Synopsys (and probably other synthesizers). If you need something like that, use for i in 0 to MAX_LOOPS loop exit when condition; ... end loop; or similar, and make sure MAX_LOOPS is big enough (integer'high is a possible choice). - assertions: If you use assertions or report statements (which is a good idea for simulation but won't work during synthesis), surround them with -- pragma synthesis_off assert blah ... ; -- pragma synthesis_on -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 10 18:35:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRIL-0003fl-00 for ; Thu, 11 Jul 2002 01:54:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:54:53 +0200 (CEST) Received: (qmail 6880 invoked by uid 0); 10 Jul 2002 16:44:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 10 Jul 2002 16:44:43 -0000 Received: by moria.seul.org (Postfix) id 46C3114680D; Wed, 10 Jul 2002 12:44:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C8D9146859; Wed, 10 Jul 2002 12:44:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 330FC14680D for ; Wed, 10 Jul 2002 12:44:41 -0400 (EDT) Received: (qmail 29454 invoked by uid 85); 10 Jul 2002 16:44:03 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.659287 secs); 10 Jul 2002 16:44:03 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 10 Jul 2002 16:44:02 -0000 Message-ID: <3D2C6240.3000401@yahoo.fr> Date: Wed, 10 Jul 2002 18:35:12 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: >[Yann, you may copy&paste this to the VHDL HOWTO if you wish] > >VHDL is a very powerful language, but synthesis tools support only a >rather limited subset of it. Many constructions that work fine during >simulation won't be accepted by synthesizers at all. Since some of you >are going to rewrite their units (and expressed their wishes to do it >only *once* ;), I'll give you some more hints. > >- processes, wait statements and sensitivity lists: > > DO NOT use `wait' statements; always write processes with an > explicit sensitivity list. Make sure that every signal that > is used (= read) inside the process is also mentioned in its > sensitivity list. > >- clocked circuits: > > In order to instantiate flipflops (or pipeline registers), > use the following idiom: > > process (...) > ... > begin > expression1 := ...; > expression2 := ...; > expression3 := ...; > ... > if rising_edge(clock_signal) then > signal1 <= expression1; > signal2 <= expression2; > signal3 <= expression3; > ... > end if; > end process; > if rising_edge... is well but the syntax if (clock_signal'event and clock_signal='1') then ... is better (see synopsys recommendation coding style) and for falling_edge if (clock_signal'event and clock_signal='0') then ... > > Note that there must be AT MOST ONE `if rising_edge(clock_signal)' > inside a particular process, the conditional expression MUST NOT > have other elements, and the `if' statement MUST NOT have `elsif' > or `else' clauses. The `if rising_edge(clock_signal)' may be nested > inside another `if' statement (or may be an `elsif' clause itself), > but you should limit this use to the cases listed below. Also note > that use of rising_edge() - or the signal'event attribute - is NOT > supported inside functions or procedures! > > BTW: It is considered good style to write one process per > pipeline stage (unless the pipeline is `forked'), and put the > `if rising_edge(clock_signal)' clause at the very end of the > process, as shown. > BTW (2) : It is considered good style to write one process to drive only one signal. > >- clock enable and reset: > > If you need a clock enable signal and asynchronous reset, you > can write: > > if to_X01(async_reset) = '1' then > some_signal <= '0'; > elsif rising_edge(clock_signal) then > if to_X01(clock_enable) = '1' then > some_signal <= some_expression; > end if; > end if; > > Synchronous reset is also possible: > > if rising_edge(clock_signal) then > if to_X01(sync_reset) = '1' then > some_signal <= '0'; > elsif to_X01(clock_enable) = '1' then > some_signal <= some_expression; > end if; > end if; > > But I used asynchronous reset everywhere. > >- pipeline enable: > > If your unit has more than two pipeline stages, you probably want > to chain the enable signal. That is, the enable signal `travels' > through the pipeline together with the data `wavefront' (I used > that trick in the IMU in order to save power). To do so, provide an > `enable out' signal in each stage: > > if to_X01(async_reset) = '1' then > some_signal <= '0'; > enable_out <= '0'; > elsif rising_edge(clock_signal) then > if to_X01(enable_in) = '1' then > some_signal <= some_expression; > end if; > enable_out <= enable_in; > end if; > > Then, connect `enable_out' of stage to `enable_in' of stage . > >- multibit: > > Avoid fiddling with individual bits if a vector will do. It is > a good idea to put more complex operations inside a procedure > or function, and then apply that to its argument vectors (if > there is a single result vector, please use a function). > > Some operations are already defined. E.g. `reduce_and' calculates > > A(A'low) and A(A'low+1) and ... and A(A'high) > > for an arbitrary std_ulogic_vector A; analogously, `reduce_or' > and `reduce_xor' perform the `or' and `xor' operations. These > functions (among others) can be found in package Bit_Manipulation > in the common/ subdirectory, and are documented in common/doc/. > > >- while loops: > > The sequential `while ... loop' statement is not supported by > Synopsys (and probably other synthesizers). If you need something > like that, use > > for i in 0 to MAX_LOOPS loop > exit when condition; > ... > end loop; > > or similar, and make sure MAX_LOOPS is big enough (integer'high is > a possible choice). > >- assertions: > > If you use assertions or report statements (which is a good > idea for simulation but won't work during synthesis), surround > them with > > -- pragma synthesis_off > assert blah ... ; > -- pragma synthesis_on > @+ Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 10 19:34:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRIM-0003fl-00 for ; Thu, 11 Jul 2002 01:54:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:54:54 +0200 (CEST) Received: (qmail 10112 invoked by uid 0); 10 Jul 2002 17:37:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Jul 2002 17:37:36 -0000 Received: by moria.seul.org (Postfix) id 58A88146859; Wed, 10 Jul 2002 13:37:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3C14C146954; Wed, 10 Jul 2002 13:37:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id D6B3D146859 for ; Wed, 10 Jul 2002 13:37:34 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-197.jetnet.ab.ca [207.34.60.197]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6AHbk65073505 for ; Wed, 10 Jul 2002 11:37:47 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D2C7009.6010704@jetnet.ab.ca> Date: Wed, 10 Jul 2002 11:34:01 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >> - pipeline enable: >> >> If your unit has more than two pipeline stages, you probably want >> to chain the enable signal. That is, the enable signal `travels' >> through the pipeline together with the data `wavefront' (I used >> that trick in the IMU in order to save power). To do so, provide an >> `enable out' signal in each stage: But would not optimzation refactor the gates down to a single level? As for just what the enable logic is give me a schematic any day as it looks like the enable signal is undefined most of the time. Also two resets for a CPU may be useful. Power on reset -- level sensitive and gated with the system clock. Master reset that edge sensitive and povides a soft reset. A jump/call to address 0 could provide a RESET trap to kill that thread. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 10 23:51:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJc-0003fl-00 for ; Thu, 11 Jul 2002 01:56:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:12 +0200 (CEST) Received: (qmail 8999 invoked by uid 0); 10 Jul 2002 21:51:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 10 Jul 2002 21:51:56 -0000 Received: by moria.seul.org (Postfix) id A3923146807; Wed, 10 Jul 2002 17:51:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74C42146819; Wed, 10 Jul 2002 17:51:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a123.home.uni-hannover.de [130.75.232.123]) by moria.seul.org (Postfix) with ESMTP id F38D7146807 for ; Wed, 10 Jul 2002 17:51:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02569; Wed, 10 Jul 2002 23:51:51 +0200 Message-ID: <20020710235151.39417@thrai.stud.uni-hannover.de> Date: Wed, 10 Jul 2002 23:51:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2C6240.3000401@yahoo.fr>; from Just an Illusion on Wed, Jul 10, 2002 at 06:35:12PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 10, 2002 at 06:35:12PM +0200, Just an Illusion wrote: [...] > if rising_edge... is well but the syntax > > if (clock_signal'event and clock_signal='1') then ... > > is better (see synopsys recommendation coding style) Since Synopsys understands either version, and the *correct* incantation reads if clock_signal'event and clock_signal = '1' and clock_signal'last_value = '0' then ... I prefer the shorter form. > and for falling_edge > > if (clock_signal'event and clock_signal='0') then ... We do not use falling edge clocks, negative logic and the like. [...] > > BTW: It is considered good style to write one process per > > pipeline stage (unless the pipeline is `forked'), and put the > > `if rising_edge(clock_signal)' clause at the very end of the > > process, as shown. > > > BTW (2) : It is considered good style to write one process to drive only > one signal. And replicate everything that's common? No, thank you. *Who* recommends this, BTW? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 10 23:53:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJc-0003fl-01 for ; Thu, 11 Jul 2002 01:56:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:12 +0200 (CEST) Received: (qmail 22866 invoked by uid 0); 10 Jul 2002 21:53:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Jul 2002 21:53:32 -0000 Received: by moria.seul.org (Postfix) id 0ABC014680A; Wed, 10 Jul 2002 17:53:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 004FB146919; Wed, 10 Jul 2002 17:53:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a123.home.uni-hannover.de [130.75.232.123]) by moria.seul.org (Postfix) with ESMTP id 8A91F14680A for ; Wed, 10 Jul 2002 17:53:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02580; Wed, 10 Jul 2002 23:53:30 +0200 Message-ID: <20020710235330.11135@thrai.stud.uni-hannover.de> Date: Wed, 10 Jul 2002 23:53:30 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> <3D2C7009.6010704@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2C7009.6010704@jetnet.ab.ca>; from Ben Franchuk on Wed, Jul 10, 2002 at 11:34:01AM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 10, 2002 at 11:34:01AM -0600, Ben Franchuk wrote: > > >> - pipeline enable: > >> > >> If your unit has more than two pipeline stages, you probably want > >> to chain the enable signal. That is, the enable signal `travels' > >> through the pipeline together with the data `wavefront' (I used > >> that trick in the IMU in order to save power). To do so, provide an > >> `enable out' signal in each stage: > > But would not optimzation refactor the gates down to a single level? Yes, they're supposed to be there. The goal is to turn off all unused stages - not the whole pipeline at a time. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 11 00:01:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJd-0003fl-00 for ; Thu, 11 Jul 2002 01:56:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:13 +0200 (CEST) Received: (qmail 17708 invoked by uid 0); 10 Jul 2002 22:01:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Jul 2002 22:01:26 -0000 Received: by moria.seul.org (Postfix) id 4831814691A; Wed, 10 Jul 2002 18:01:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1E93146954; Wed, 10 Jul 2002 18:01:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a123.home.uni-hannover.de [130.75.232.123]) by moria.seul.org (Postfix) with ESMTP id 13CE914691A for ; Wed, 10 Jul 2002 18:01:23 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02625; Thu, 11 Jul 2002 00:01:21 +0200 Message-ID: <20020711000121.60568@thrai.stud.uni-hannover.de> Date: Thu, 11 Jul 2002 00:01:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> <20020710235151.39417@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020710235151.39417@thrai.stud.uni-hannover.de>; from Michael Riepe on Wed, Jul 10, 2002 at 11:51:51PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 10, 2002 at 11:51:51PM +0200, Michael Riepe wrote: > On Wed, Jul 10, 2002 at 06:35:12PM +0200, Just an Illusion wrote: > [...] > > if rising_edge... is well but the syntax > > > > if (clock_signal'event and clock_signal='1') then ... > > > > is better (see synopsys recommendation coding style) > > Since Synopsys understands either version, and the *correct* > incantation reads > > if clock_signal'event > and clock_signal = '1' > and clock_signal'last_value = '0' then ... Oops... I forgot some () and to_X01() here and there. But now you get the idea I guess... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jul 11 00:18:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJe-0003fl-00 for ; Thu, 11 Jul 2002 01:56:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:14 +0200 (CEST) Received: (qmail 23399 invoked by uid 0); 10 Jul 2002 22:18:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 10 Jul 2002 22:18:46 -0000 Received: by moria.seul.org (Postfix) id F159D146817; Wed, 10 Jul 2002 18:18:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCB1B146915; Wed, 10 Jul 2002 18:18:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 05744146817 for ; Wed, 10 Jul 2002 18:18:44 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207102218.23b3; Wed, 10 Jul 2002 22:18:35 GMT Send-By: 147.210.68.141 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 To: Subject: Rep:[f-cpu] Coding for Synthesis From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 2002 22:18:35 GMT Message-id: <200207102218.23b3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nice resume but... -----Message d'origine----- De: Michael Riepe A: F-CPU Mailing List Date: 10/07/02 Objet: [f-cpu] Coding for Synthesis [Yann, you may copy&paste this to the VHDL HOWTO if you wish= ] VHDL is a very powerful language, but synthesis tools suppor= t only a rather limited subset of it. Many constructions that work fi= ne during simulation won't be accepted by synthesizers at all. Since = some of you are going to rewrite their units (and expressed their wishes= to do it only *once* ;), I'll give you some more hints. - processes, wait statements and sensitivity lists: DO NOT use `wait' statements; always write processes wit= h an explicit sensitivity list. Make sure that every signal t= hat is used (=3D read) inside the process is also mentioned = in its sensitivity list. - clocked circuits: In order to instantiate flipflops (or pipeline registers= ), use the following idiom: process (...) ... begin expression1 :=3D ...; expression2 :=3D ...; expression3 :=3D ...; ... if rising_edge(clock_signal) then signal1 <=3D expression1; signal2 <=3D expression2; signal3 <=3D expression3; ... end if; end process; Note that there must be AT MOST ONE `if rising_edge(cloc= k_signal)' inside a particular process, the conditional expression = MUST NOT have other elements, and the `if' statement MUST NOT hav= e `elsif' or `else' clauses. The `if rising_edge(clock_signal)' ma= y be nested inside another `if' statement (or may be an `elsif' clau= se itself), but you should limit this use to the cases listed below.= Also note that use of rising_edge() - or the signal'event attribut= e - is NOT supported inside functions or procedures! BTW: It is considered good style to write one process pe= r pipeline stage (unless the pipeline is `forked'), and pu= t the `if rising_edge(clock_signal)' clause at the very end of= the process, as shown. - clock enable and reset: If you need a clock enable signal and asynchronous reset= , you can write: if to_X01(async_reset) =3D '1' then some_signal <=3D '0'; elsif rising_edge(clock_signal) then if to_X01(clock_enable) =3D '1' then some_signal <=3D some_expression; end if; end if; Synchronous reset is also possible: if rising_edge(clock_signal) then if to_X01(sync_reset) =3D '1' then some_signal <=3D '0'; elsif to_X01(clock_enable) =3D '1' then some_signal <=3D some_expression; end if; end if; But I used asynchronous reset everywhere. >>>ok ! But i always read that synopsys prefer synchronous r= eset but in every design i see asynchronous reset was compulsory !=20 - pipeline enable: If your unit has more than two pipeline stages, you prob= ably want to chain the enable signal. That is, the enable signal `= travels' through the pipeline together with the data `wavefront' = (I used that trick in the IMU in order to save power). To do so,= provide an `enable out' signal in each stage: if to_X01(async_reset) =3D '1' then some_signal <=3D '0'; enable_out <=3D '0'; elsif rising_edge(clock_signal) then if to_X01(enable_in) =3D '1' then some_signal <=3D some_expression; end if; enable_out <=3D enable_in; end if; Then, connect `enable_out' of stage to `enable_in' o= f stage . >>>Gloups ! i don't like that at all : a new asynch signal (= that's introduice slew rate problem). I think that such signal must= be under the rising_edge of the process. nicO - multibit: Avoid fiddling with individual bits if a vector will do.= It is a good idea to put more complex operations inside a proc= edure or function, and then apply that to its argument vectors= (if there is a single result vector, please use a function). Some operations are already defined. E.g. `reduce_and' c= alculates A(A'low) and A(A'low+1) and ... and A(A'high) for an arbitrary std_ulogic_vector A; analogously, `redu= ce_or' and `reduce_xor' perform the `or' and `xor' operations. = These functions (among others) can be found in package Bit_Man= ipulation in the common/ subdirectory, and are documented in commo= n/doc/. - while loops: The sequential `while ... loop' statement is not support= ed by Synopsys (and probably other synthesizers). If you need= something like that, use for i in 0 to MAX_LOOPS loop exit when condition; ... end loop; or similar, and make sure MAX_LOOPS is big enough (integ= er'high is a possible choice). - assertions: If you use assertions or report statements (which is a g= ood idea for simulation but won't work during synthesis), su= rround them with -- pragma synthesis_off assert blah ... ; -- pragma synthesis_on --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 11 00:31:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJf-0003fl-00 for ; Thu, 11 Jul 2002 01:56:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:15 +0200 (CEST) Received: (qmail 9481 invoked by uid 0); 10 Jul 2002 22:31:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 10 Jul 2002 22:31:08 -0000 Received: by moria.seul.org (Postfix) id CAC30146807; Wed, 10 Jul 2002 18:31:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A559E146817; Wed, 10 Jul 2002 18:31:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a123.home.uni-hannover.de [130.75.232.123]) by moria.seul.org (Postfix) with ESMTP id 2CD16146807 for ; Wed, 10 Jul 2002 18:31:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02716; Thu, 11 Jul 2002 00:31:03 +0200 Message-ID: <20020711003103.16678@thrai.stud.uni-hannover.de> Date: Thu, 11 Jul 2002 00:31:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Coding for Synthesis References: <200207102218.23b3@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207102218.23b3@th00.opsion.fr>; from Nicolas Boulay on Wed, Jul 10, 2002 at 10:18:35PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 10, 2002 at 10:18:35PM +0000, Nicolas Boulay wrote: > Nice resume but... [...] > - pipeline enable: > > If your unit has more than two pipeline stages, you probably want > to chain the enable signal. That is, the enable signal `travels' > through the pipeline together with the data `wavefront' (I used > that trick in the IMU in order to save power). To do so, provide an > `enable out' signal in each stage: > > if to_X01(async_reset) = '1' then > some_signal <= '0'; > enable_out <= '0'; > elsif rising_edge(clock_signal) then > if to_X01(enable_in) = '1' then > some_signal <= some_expression; > end if; > enable_out <= enable_in; > end if; > > Then, connect `enable_out' of stage to `enable_in' of stage > . > > >>>Gloups ! i don't like that at all : a new asynch signal (that's > introduice slew rate problem). I think that such signal must be under > the rising_edge of the process. `enable' is a synchronous signal. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jul 11 00:45:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SRJg-0003fl-00 for ; Thu, 11 Jul 2002 01:56:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 01:56:16 +0200 (CEST) Received: (qmail 27056 invoked by uid 0); 10 Jul 2002 22:45:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 10 Jul 2002 22:45:21 -0000 Received: by moria.seul.org (Postfix) id E0B7F146807; Wed, 10 Jul 2002 18:45:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5DDD146817; Wed, 10 Jul 2002 18:45:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3DA3C146807 for ; Wed, 10 Jul 2002 18:45:19 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207102245.0aa1; Wed, 10 Jul 2002 22:45:10 GMT Send-By: 147.210.68.141 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 To: Subject: Rep:Re: Rep:[f-cpu] Coding for Synthesis From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 2002 22:45:10 GMT Message-id: <200207102245.0aa1@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i need a nap sorry... nicO=20 -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 11/07/02 Objet: Re: Rep:[f-cpu] Coding for Synthesis On Wed, Jul 10, 2002 at 10:18:35PM +0000, Nicolas Boulay wro= te: > Nice resume but... [...] > - pipeline enable: >=20 > If your unit has more than two pipeline stages, you pr= obably want > to chain the enable signal. That is, the enable signal= `travels' > through the pipeline together with the data `wavefront= ' (I used > that trick in the IMU in order to save power). To do s= o, provide an > `enable out' signal in each stage: >=20 > if to_X01(async_reset) =3D '1' then > some_signal <=3D '0'; > enable_out <=3D '0'; > elsif rising_edge(clock_signal) then > if to_X01(enable_in) =3D '1' then > some_signal <=3D some_expression; > end if; > enable_out <=3D enable_in; > end if; >=20 > Then, connect `enable_out' of stage to `enable_in'= of stage > . >=20 > >>>Gloups ! i don't like that at all : a new asynch signal= (that's > introduice slew rate problem). I think that such signal mu= st be under > the rising_edge of the process. `enable' is a synchronous signal. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Thu Jul 11 10:23:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Sdpk-0003VM-01 for ; Thu, 11 Jul 2002 15:18:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 11 Jul 2002 15:18:12 +0200 (CEST) Received: (qmail 31135 invoked by uid 0); 11 Jul 2002 08:32:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 11 Jul 2002 08:32:58 -0000 Received: by moria.seul.org (Postfix) id 30A37146918; Thu, 11 Jul 2002 04:32:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1D9E14691B; Thu, 11 Jul 2002 04:32:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id AD93B146918 for ; Thu, 11 Jul 2002 04:32:55 -0400 (EDT) Received: (qmail 45356 invoked by uid 85); 11 Jul 2002 08:32:14 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.237054 secs); 11 Jul 2002 08:32:14 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 11 Jul 2002 08:32:14 -0000 Message-ID: <3D2D407B.7040301@yahoo.fr> Date: Thu, 11 Jul 2002 10:23:23 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> <20020710235151.39417@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Michael Riepe wrote: >On Wed, Jul 10, 2002 at 06:35:12PM +0200, Just an Illusion wrote: >[...] > >>if rising_edge... is well but the syntax >> >>if (clock_signal'event and clock_signal='1') then ... >> >>is better (see synopsys recommendation coding style) >> > >Since Synopsys understands either version, and the *correct* >incantation reads > > if clock_signal'event > and clock_signal = '1' > and clock_signal'last_value = '0' then ... > That is not a supported declaration format for clock edge specification, for information you can see the IEEE 1076-93 (Vhdl LRM) and the IEEE P1076.6-2001 (Vhdl RTL LRM, the IEEE-1076.6 give same things on the subject). > >I prefer the shorter form. > >>and for falling_edge >> >>if (clock_signal'event and clock_signal='0') then ... >> > >We do not use falling edge clocks, negative logic and the like. > >[...] > >>> BTW: It is considered good style to write one process per >>> pipeline stage (unless the pipeline is `forked'), and put the >>> `if rising_edge(clock_signal)' clause at the very end of the >>> process, as shown. >>> >>BTW (2) : It is considered good style to write one process to drive only >>one signal. >> Sorry I have forget to add "in case of edge-sensitive sequential logic" > >And replicate everything that's common? No, thank you. > The code replication can be fastidious but that can help the synthesizer to give a better netlist. > > >*Who* recommends this, BTW? > By example : Synopsis, Symplicity, Examplar... This is not a mandatory condition but it can help synthesis :-) @+ Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jprenticehall@anonymous.to Thu Jul 11 15:41:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17SxuS-0000nM-00 for ; Fri, 12 Jul 2002 12:44:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Jul 2002 12:44:24 +0200 (CEST) Received: (qmail 26310 invoked by uid 0); 11 Jul 2002 14:41:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 11 Jul 2002 14:41:24 -0000 Received: by moria.seul.org (Postfix) id D4D9B146850; Thu, 11 Jul 2002 10:41:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B6B0114691C; Thu, 11 Jul 2002 10:41:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail18.bigmailbox.com (mail18.bigmailbox.com [209.132.220.49]) by moria.seul.org (Postfix) with ESMTP id 0764E146850 for ; Thu, 11 Jul 2002 10:41:23 -0400 (EDT) Received: (from www@localhost) by mail18.bigmailbox.com (8.11.6/8.10.0) id g6BDf0C06506; Thu, 11 Jul 2002 06:41:00 -0700 Date: Thu, 11 Jul 2002 06:41:00 -0700 Message-Id: <200207111341.g6BDf0C06506@mail18.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [172.152.105.75] From: "Jason Hall" To: wy822@007infosys.com Subject: [f-cpu] You Owe It To Yourself To Send For More Info! - Start Making Money Today! Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This e-mail is sent in compliance with strict anti-abuse and NO SPAM regulations. Your address was collected as a result of posting to a link, a classified ad, a message to my FFA Page, you have sent me an E- >mail recently, or you are on a list that I have purchased. You may >remove your E-mail address at no cost to you whatsoever by simply >sending an E-mail to the same e-mail address link above.............. >=========================================================== > > > YOUR CHOICE is SIMPLE!! > > Everyone knows there's HUGE money to be made in > the online adult industry.. > >Let's face it folks....this is what sells on the internet!!! >Adult entertainment is the most lucrative industry >on the internet... and YOU can be part of it!! > >All you have to do is promote this golden opportunity >on the internet and you will get paid $25 for every member >you sign AND $25 for the first two members that THEY >sign and another $25 for the first two members that >THEY sign and so on!! > > Now that's residual income!! > >Blazeline permits me to work part-time and earn a substantial >residual income while having access to quality adult >material such as exclusive movies, interactive live shows, >XXX pictures, adult dating services, adult games, >sex stories and much more !!! > >The most lucrative compensation plan in the industry >combined with quality adult material at the lowest price >on the internet is, by far, the best business you can ever own!!! >Complete Anonymity - We will never give out your >personal info. >You really have nothing to lose because you only need >two members in your downline to be in profit!! > >Free Info, please email me immediately! >INFO PLEASE in the subject line, > >jprenticehall@anonymous.to >or >j_prenticehall@yahoo.com > >You owe it to yourself to join Blazeline, >======================================== >"Your name has not been added to any email list. >This is a one time email so there is no need to ask to be >removed. I'm sending you this email based on the >information I gathered from your web mail to my FFa page. >If you have received this email in error, please forgive my intrusion >and delete it. Thanks for your time." ------------------------------------------------------------ This email was sent through the free email service at http://www.anonymous.to/ To report abuse, please visit our website and click 'Contact Us.' --------------------------------------------------------------------- Express yourself with a super cool email address from BigMailBox.com. Hundreds of choices. It's free! http://www.bigmailbox.com --------------------------------------------------------------------- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 11 21:36:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Sxuk-0000nM-00 for ; Fri, 12 Jul 2002 12:44:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Jul 2002 12:44:42 +0200 (CEST) Received: (qmail 29126 invoked by uid 0); 11 Jul 2002 22:05:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 11 Jul 2002 22:05:34 -0000 Received: by moria.seul.org (Postfix) id 3C896146922; Thu, 11 Jul 2002 18:05:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F3D8B146926; Thu, 11 Jul 2002 18:05:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a234.home.uni-hannover.de [130.75.232.234]) by moria.seul.org (Postfix) with ESMTP id 49CD2146922 for ; Thu, 11 Jul 2002 18:05:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00455; Thu, 11 Jul 2002 21:36:42 +0200 Message-ID: <20020711213642.06831@thrai.stud.uni-hannover.de> Date: Thu, 11 Jul 2002 21:36:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> <20020710235151.39417@thrai.stud.uni-hannover.de> <3D2D407B.7040301@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D2D407B.7040301@yahoo.fr>; from Just an Illusion on Thu, Jul 11, 2002 at 10:23:23AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 11, 2002 at 10:23:23AM +0200, Just an Illusion wrote: [...] > >>> BTW: It is considered good style to write one process per > >>> pipeline stage (unless the pipeline is `forked'), and put the > >>> `if rising_edge(clock_signal)' clause at the very end of the > >>> process, as shown. > >>> > >>BTW (2) : It is considered good style to write one process to drive only > >>one signal. > >> > Sorry I have forget to add "in case of edge-sensitive sequential logic" Some people also recommend to use two separate processes for sequential and combinatorial stuff. I agree with that in certain cases - e.g. when the code is written in `state machine style'. For the F-CPU with its huge number of pipeline registers, the `process per stage' variant is much more readable. > >And replicate everything that's common? No, thank you. > > > The code replication can be fastidious but that can help the synthesizer > to give a better netlist. Sorry, but that doesn't sound logical at all. If the synthesizer can `factor out' common sub-circuits, it can do so in any case - and if it can't, you better do it manually. > >*Who* recommends this, BTW? > > > By example : Synopsis, Symplicity, Examplar... > This is not a mandatory condition but it can help synthesis :-) If a synthesizer needs help with *that*, it's probably not worth the (huge amount of) money you pay for it ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jul 12 08:54:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Sxuz-0000nM-00 for ; Fri, 12 Jul 2002 12:44:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Jul 2002 12:44:57 +0200 (CEST) Received: (qmail 19524 invoked by uid 0); 12 Jul 2002 07:04:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 12 Jul 2002 07:04:32 -0000 Received: by moria.seul.org (Postfix) id 5FA5C146809; Fri, 12 Jul 2002 03:04:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3878C14692F; Fri, 12 Jul 2002 03:04:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 4A406146809 for ; Fri, 12 Jul 2002 03:04:30 -0400 (EDT) Received: (qmail 82566 invoked by uid 85); 12 Jul 2002 07:03:42 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.161844 secs); 12 Jul 2002 07:03:42 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 12 Jul 2002 07:03:41 -0000 Message-ID: <3D2E7D39.50908@yahoo.fr> Date: Fri, 12 Jul 2002 08:54:49 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020710134941.01764@thrai.stud.uni-hannover.de> <3D2C6240.3000401@yahoo.fr> <20020710235151.39417@thrai.stud.uni-hannover.de> <3D2D407B.7040301@yahoo.fr> <20020711213642.06831@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > >>>*Who* recommends this, BTW? >>> >>By example : Synopsis, Symplicity, Examplar... >>This is not a mandatory condition but it can help synthesis :-) >> > >If a synthesizer needs help with *that*, it's probably not worth the >(huge amount of) money you pay for it ;) > ;-) I am agree, but I haven't find some good free synthesizer :-( Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jul 12 10:51:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Sxv3-0000nM-01 for ; Fri, 12 Jul 2002 12:45:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Jul 2002 12:45:01 +0200 (CEST) Received: (qmail 17153 invoked by uid 0); 12 Jul 2002 08:51:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 12 Jul 2002 08:51:16 -0000 Received: by moria.seul.org (Postfix) id 7C2F214692D; Fri, 12 Jul 2002 04:51:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54526146930; Fri, 12 Jul 2002 04:51:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 7092B14692D for ; Fri, 12 Jul 2002 04:51:14 -0400 (EDT) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id LAA30546 for ; Fri, 12 Jul 2002 11:51:12 +0300 Date: Fri, 12 Jul 2002 11:51:12 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis In-Reply-To: <20020711213642.06831@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > >*Who* recommends this, BTW? > > > > > By example : Synopsis, Symplicity, Examplar... > > This is not a mandatory condition but it can help synthesis :-) > > If a synthesizer needs help with *that*, it's probably not worth the > (huge amount of) money you pay for it ;) At least Synopsys DC is not very good optimizer. And DC VHDL reader is one of the worst ones, DC just has a big market share and good name, it is not very modern product. You can try how bad DC is by feeding it parallel CRC network made from xor gates with just for loop and generate. DC can't optimize that network but Synplify happily optimizes it. With DC the network has to be first optimized by some other tools (usually designers own perl/C programs). --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 12 17:30:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17T4s5-0000Ff-01 for ; Fri, 12 Jul 2002 20:10:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 12 Jul 2002 20:10:25 +0200 (CEST) Received: (qmail 22331 invoked by uid 0); 12 Jul 2002 16:01:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 12 Jul 2002 16:01:03 -0000 Received: by moria.seul.org (Postfix) id 32C6414692D; Fri, 12 Jul 2002 12:01:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 18A63146930; Fri, 12 Jul 2002 12:01:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a153.home.uni-hannover.de [130.75.232.153]) by moria.seul.org (Postfix) with ESMTP id 92BFE14692D for ; Fri, 12 Jul 2002 12:01:00 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01180; Fri, 12 Jul 2002 17:30:51 +0200 Message-ID: <20020712173051.43231@thrai.stud.uni-hannover.de> Date: Fri, 12 Jul 2002 17:30:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Coding for Synthesis References: <20020711213642.06831@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Kim Enkovaara on Fri, Jul 12, 2002 at 11:51:12AM +0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 12, 2002 at 11:51:12AM +0300, Kim Enkovaara wrote: [...] > At least Synopsys DC is not very good optimizer. And DC VHDL reader is one > of the worst ones, DC just has a big market share and good name, it is > not very modern product. I already realized that... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jul 12 21:23:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17T9O9-0004Nq-00 for ; Sat, 13 Jul 2002 00:59:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Jul 2002 00:59:49 +0200 (CEST) Received: (qmail 1744 invoked by uid 0); 12 Jul 2002 19:23:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Jul 2002 19:23:20 -0000 Received: by moria.seul.org (Postfix) id 90F5014692E; Fri, 12 Jul 2002 15:23:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 83CD3146932; Fri, 12 Jul 2002 15:23:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id E33EB14692E for ; Fri, 12 Jul 2002 15:23:18 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207121923.02a7; Fri, 12 Jul 2002 19:23:02 GMT Send-By: 147.210.68.141 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 To: Subject: [f-cpu] little feed-back from the libre softawre meeting From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jul 2002 19:23:02 GMT Message-id: <200207121923.02a7@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric, Whygee and i have travel to Bordeaux to assist to th= e libre software meeting ( lsm.abul.org ). Lots of people from very = differents open/libre source word are comming. It end tomorow. The following is a little feed-back from our= discussion with different people. (we don't know where is whygee so i s= end you without his rereading) --- Security point of view We have seen Frederic, pappy Raynal (main writter in MISC,= french securities newspaper) and Bradley Spencer who write the gr= security patch. They propose : read, write, exec bit + at least 3 rings (super user + = user + something like for library,...) >From Cedric thinks : we need 3 sr : to set or unset the tbl=20 something to change the ring for vm writter we must enable or not the read access to sr(trap on read AND write) >From discussion with a Hurd guy (Neal Wafield) 16 kb for a page is a little bit to much 8 kb could be enough all new processor have between 5 to 11 page size ! alpha handle an 8 bits fields for virtual area number (= for tlb and caches) -> sw must avoid collusion. we should try to implement L4 (hurd main kernel) to ver= ify the process management of the f-cpu =20 >From my view, none polling thread barrer should be implemented (for t= igh multithreaded application on multicpu)=20 Conclusion : implemented L4 change specification of the tlb (no more the kind of ca= ches use but an 8 bits fields) Looking for technics to handle different page size on t= he same memory for (tlb) to avoid the use of many independant= memories =20 Hope this help. Comments ? nicO and Cedric =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sat Jul 13 06:30:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TCJr-0006ZN-00 for ; Sat, 13 Jul 2002 04:07:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Jul 2002 04:07:35 +0200 (CEST) Received: (qmail 8770 invoked by uid 0); 12 Jul 2002 23:30:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 12 Jul 2002 23:30:49 -0000 Received: by moria.seul.org (Postfix) id 87EFA146932; Fri, 12 Jul 2002 19:30:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F2A4146937; Fri, 12 Jul 2002 19:30:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E97EE146932 for ; Fri, 12 Jul 2002 19:30:46 -0400 (EDT) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-2v.club-internet.fr (Postfix) with SMTP id 8FDF216D8 for ; Sat, 13 Jul 2002 01:30:45 +0200 (CEST) Received: from [147.210.68.141] by flashmail-5v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Sat, 13 Jul 2002 01:30:45 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, new and not-so-new readers, i am at LSM until monday and internet access is not easy for my poorly configured computers, but most mails recipients are physically here :-) ----Message d'origine---- >De: =22Nicolas Boulay=22 > >Cedric, Whygee and i have travel to Bordeaux to assist to the libre >software meeting ( lsm.abul.org ). Lots of people from very differents >open/libre source word are comming. > >It end tomorow. The following is a little feed-back from our discussion >with different people. (we don't know where is whygee so i send you >without his rereading) sorry, i woke up late and had to gather some food for the week-end, i expl= ained the F-CPU development to a Hurd guy all night long... >Security point of view > > They propose : > read, write, exec bit + at least 3 rings (super user + user + > something like for library,...) RWX is ok, because this is how protection is enforced. i'd say that it is the minimum required TLB feature. Concerning rings and groups, the issue is still open, as several proposal and ideas are floating and careless design will turn F-CPU implementations into a VAX-like, or worse... helping SW and OS is ok, as long as we don't do in HW all the work. It must be also =22friendly=22 with many OS approaches, so i choose the =22least common denominator=22 approach. A TLB with RWX rights and VMID is the most common feature and it's straight-forward to understand for SW and HW design. I'll try to continue to speak with the OS guyz (linux, Hurd and *BSD) to sort this. >>>From Cedric thinks : > we need 3 sr : to set or unset the tbl = i presume that we will need much more, as the interface must remain clean and orthogonal throughout different core types... let's make something simple, logical and easy to understand from the beginning, even though if we don't use all the features now... > something to change the ring > for vm writter we must enable or not the read > access to sr(trap on read AND write) SRs will contain a place which says what the current user can read and/or write =3D> not a problem (it's slow anyway, so...) it's not yet defined in the VHDL sources but will become a reality whenever the corresponding piece of code is written. >>>From discussion with a Hurd guy (Neal Wafield) hmmm... speaking about God and its saints .. ;-) we started speaking about IPC yesterday... > 16 kb for a page is a little bit to much why ? if you have huge datasets (megabytes, gigabytes...) you will spend your time in the trap handler... i count on the OS to =22gather=22 contiguous small pages into larger ones, possibly based on usage statistics (that the CPU could gather). > 8 kb could be enough > all new processor have between 5 to 11 page size =21 cool. however too many sizes might make the LSU more complex :-( i guess that 4 is the best tradeoff. **************************** Don't let children look **************************** i just found a REALLY naughty (cough)=23hack=23 .... it doesn't soleve the page size problems but removes some =22kernel addressing =22 problems, which make the LSU a bit more complex... > alpha handle an 8 bits fields for virtual area number (for tlb and > caches) -> sw must avoid collusion. you mean =22collision=22 ? :o) > we should try to implement L4 (hurd main kernel) to verify the > process management of the f-cpu whatever you want as long you =23do=23 it ... you know the song.... >>>From my view, > none polling thread barrer should be implemented (for tigh > multithreaded application on multicpu) please rephrase that and spellcheck it, i did not understand. >Conclusion : > implemented L4 > change specification of the tlb (no more the kind of caches use > but an 8 bits fields) 8-bit field if you want but will this solve virtual aliases problems ? > Looking for technics to handle different page size on the same > memory for (tlb) to avoid the use of many independant memories my current method is to have N parallel TLBs with = one size each. Say, 8 entries for 4KB, 8 entries for 32KB, 8 entries for 256 etc... >Hope this help. Comments ? let's have a talk :-) >nicO and Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jul 13 01:57:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TCJs-0006ZN-01 for ; Sat, 13 Jul 2002 04:07:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Jul 2002 04:07:36 +0200 (CEST) Received: (qmail 2180 invoked by uid 0); 12 Jul 2002 23:57:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 12 Jul 2002 23:57:08 -0000 Received: by moria.seul.org (Postfix) id B7ED3146935; Fri, 12 Jul 2002 19:57:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8BD5D146938; Fri, 12 Jul 2002 19:57:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a050.home.uni-hannover.de [130.75.232.50]) by moria.seul.org (Postfix) with ESMTP id 00F58146935 for ; Fri, 12 Jul 2002 19:57:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00802; Sat, 13 Jul 2002 01:57:03 +0200 Message-ID: <20020713015703.08661@thrai.stud.uni-hannover.de> Date: Sat, 13 Jul 2002 01:57:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Sat, Jul 13, 2002 at 01:30:45AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jul 13, 2002 at 01:30:45AM +0200, whygee@club-internet.fr wrote: [...] > > read, write, exec bit + at least 3 rings (super user + user + > > something like for library,...) > > RWX is ok, because this is how protection is enforced. > i'd say that it is the minimum required TLB feature. *nod* What about different permission bits for different protection levels? Like `supervisor may read and write, j. random luser may only read'. That's probably better than a `user/supervisor' bit or an explicit `page protection level'. > Concerning rings and groups, the issue is still open, > as several proposal and ideas are floating and careless > design will turn F-CPU implementations into a VAX-like, > or worse... helping SW and OS is ok, as long as we don't > do in HW all the work. It must be also "friendly" with > many OS approaches, so i choose the "least common denominator" > approach. A TLB with RWX rights and VMID is the most common > feature and it's straight-forward to understand for SW and > HW design. I'll try to continue to speak with the OS guyz > (linux, Hurd and *BSD) to sort this. Misquoting Bill Gates: `Two protection levels should be enough for every OS.' [...] > >>From my view, > > none polling thread barrer should be implemented (for tigh > > multithreaded application on multicpu) > > please rephrase that and spellcheck it, i did not understand. He probably meant: a non-polling thread barrier should be implemented for `tight' multithreading. I'm not sure what he means with `thread barrier', though - something like a hardware semaphore? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Sat Jul 13 02:52:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TCJu-0006ZN-00 for ; Sat, 13 Jul 2002 04:07:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sat, 13 Jul 2002 04:07:38 +0200 (CEST) Received: (qmail 11664 invoked by uid 0); 13 Jul 2002 00:58:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Jul 2002 00:58:22 -0000 Received: by moria.seul.org (Postfix) id 6F7DB146937; Fri, 12 Jul 2002 20:58:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B384146947; Fri, 12 Jul 2002 20:58:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from lvdi.net (unknown [216.24.138.2]) by moria.seul.org (Postfix) with SMTP id F1FFA146937 for ; Fri, 12 Jul 2002 20:58:17 -0400 (EDT) Received: from wyrm ([216.24.140.80]) by lvdi.net ; Fri, 12 Jul 2002 17:58:06 2000 PDT Received: from lee by wyrm with local (Exim 3.35 #1 (Debian)) id 17TB9I-0007Ec-00 for ; Fri, 12 Jul 2002 20:52:36 -0400 Date: Fri, 12 Jul 2002 20:52:36 -0400 To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <20020713005236.GA27801@wyrm> References: <20020713015703.08661@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020713015703.08661@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.28i From: Lee Salzman Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jul 13, 2002 at 01:57:03AM +0200, Michael Riepe wrote: > On Sat, Jul 13, 2002 at 01:30:45AM +0200, whygee@club-internet.fr wrote: > [...] > > > read, write, exec bit + at least 3 rings (super user + user + > > > something like for library,...) > > > > RWX is ok, because this is how protection is enforced. > > i'd say that it is the minimum required TLB feature. > > *nod* > > What about different permission bits for different protection levels? > Like `supervisor may read and write, j. random luser may only read'. > That's probably better than a `user/supervisor' bit or an explicit > `page protection level'. > I have to agree with Michael here. In all the time I've been making kernels, I've never EVER found protection levels to be of any use. Separate masks for supervisor and user level for the page are the way to go, i.e. user RWX and supervisor RWX. > > Concerning rings and groups, the issue is still open, > > as several proposal and ideas are floating and careless > > design will turn F-CPU implementations into a VAX-like, > > or worse... helping SW and OS is ok, as long as we don't > > do in HW all the work. It must be also "friendly" with > > many OS approaches, so i choose the "least common denominator" > > approach. A TLB with RWX rights and VMID is the most common > > feature and it's straight-forward to understand for SW and > > HW design. I'll try to continue to speak with the OS guyz > > (linux, Hurd and *BSD) to sort this. > > Misquoting Bill Gates: > > `Two protection levels should be enough for every OS.' > One protection level is one too many. Capability masks allow features to be more smoothly virtualized and privileges to be more easily delegated. Protection levels just totally munge this idea. > [...] > > >>From my view, > > > none polling thread barrer should be implemented (for tigh > > > multithreaded application on multicpu) > > > > please rephrase that and spellcheck it, i did not understand. > > He probably meant: a non-polling thread barrier should be implemented for > `tight' multithreading. I'm not sure what he means with `thread barrier', > though - something like a hardware semaphore? > Aside from a test-and-set instruction, you can implement just about any type of worthwhile thread synchronization in software. Even better is to just have your threads running asynchronously whenever possible. > -- > Michael "Tired" Riepe Lee ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Jul 13 11:01:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdSm-0000CX-00 for ; Sun, 14 Jul 2002 09:06:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:36 +0200 (CEST) Received: (qmail 10746 invoked by uid 0); 13 Jul 2002 09:02:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 13 Jul 2002 09:02:03 -0000 Received: by moria.seul.org (Postfix) id 6EB1114640E; Sat, 13 Jul 2002 05:02:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A5E514693C; Sat, 13 Jul 2002 05:02:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id C6E7814640E for ; Sat, 13 Jul 2002 05:02:00 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix1-2.free.fr (Postfix) with ESMTP id 22331AB3D2 for ; Sat, 13 Jul 2002 11:02:00 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id EAAC58736A; Sat, 13 Jul 2002 11:01:59 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026550919.3d2fec87deeff@imp.free.fr> Date: Sat, 13 Jul 2002 11:01:59 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <20020713005236.GA27801@wyrm> In-Reply-To: <20020713005236.GA27801@wyrm> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 147.210.68.141 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > > read, write, exec bit + at least 3 rings (super user + user + > > > > something like for library,...) > > > > > > RWX is ok, because this is how protection is enforced. > > > i'd say that it is the minimum required TLB feature. > > > > *nod* > > > > What about different permission bits for different protection levels? > > Like `supervisor may read and write, j. random luser may only read'. > > That's probably better than a `user/supervisor' bit or an explicit > > `page protection level'. > I have to agree with Michael here. In all the time I've been making > kernels, I've never EVER found protection levels to be of any use. > Separate masks for supervisor and user level for the page are the way > to go, i.e. user RWX and supervisor RWX. I totally agree with you. I and nicO didn't find any use of this kind of ring protection (and in fact that create a stack into the CPU ;-( ). But when we discuss with Bradley Spencer, he says that somebody was working on a ring protection for linux and that we must see what we can do with that, but Bradley say to us too that he didn't see how to use them ! ;-) I personnally think that we must remove the SR that say that we are superuser or user, and prefer to us a protection mecanism with the SR. But because the SR will be really use frequently by the kernel (we didn't have a lot of entry in our TLB), so we must have a quick protection, I mean for example that we only make a difference between read-only SR and read/write SR, and if we trap we put in a SR the number that the user task want to access to and if it's a write the value it wan't to put in it and that's all. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Jul 13 11:33:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdSn-0000CX-00 for ; Sun, 14 Jul 2002 09:06:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:37 +0200 (CEST) Received: (qmail 7192 invoked by uid 0); 13 Jul 2002 09:33:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Jul 2002 09:33:11 -0000 Received: by moria.seul.org (Postfix) id 4C509146931; Sat, 13 Jul 2002 05:33:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 423DC14694A; Sat, 13 Jul 2002 05:33:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id C86E9146931 for ; Sat, 13 Jul 2002 05:33:08 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id 895CD5F86F for ; Sat, 13 Jul 2002 11:33:07 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 6C9018736A; Sat, 13 Jul 2002 11:33:07 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026552787.3d2ff3d360754@imp.free.fr> Date: Sat, 13 Jul 2002 11:33:07 +0200 (MEST) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 147.210.68.141 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >>From Cedric thinks : > > we need 3 sr : to set or unset the tbl > i presume that we will need much more, as the interface > must remain clean and orthogonal throughout different > core types... let's make something simple, logical > and easy to understand from the beginning, even though if we > don't use all the features now... > > something to change the ring > > for vm writter we must enable or not the read > > access to sr(trap on read AND write) Ok, it's what not clear, I was only speaking about an activate/unactivate TLB SR, that's only for protection mecanism. I didn't speak about the way to put data in the TLB, it's still an open question. If someone have an idea ;-) > SRs will contain a place which says what the current user > can read and/or write => not a problem (it's slow anyway, so...) > it's not yet defined in the VHDL sources but will become > a reality whenever the corresponding piece of code is written. The problem I currently see is that you are not clear about this protection mecanism. I mean I don't understand if you do a per range protection mecanism, or a per SR protection or like the one I explain in a precedent mail. I think that a per range or a per SR protection mecanism can become in the futur a nightmare. And we must have some good performance when we only read the SR. When you set SR, you must quickly know if you have the right or not, typically a good OS will block the write on any SR, so only virtual OS need to access them... > > 16 kb for a page is a little bit to much > why ? if you have huge datasets (megabytes, gigabytes...) run top on your computer and see how many task need more than 8k ;-) on my laptop, only 20%. > you will spend your time in the trap handler... Yes, it's why an "unified" TLB will be preferable to a lot of different one because we can adjust dynamically the number of TLB entry per size page. I know it perhaps a nightmare in hardware, but if somebody see a solution ;-) And at least a guy who program a TLB miss handler say to me what is for him the best solution from a software point of view (and I think that in hardware it's a nightmare ;-). What you need to know when a TLB miss append, is to know which line you can replace. So the best solution is to remove the one that's are the less used. A system that "swap" TLB line and always say which line is the less used really ease the TLB miss handler... I currently didn't find a way to implement this in hardware, and I think that a solution with a counter that are in read/write access is the best solution for hardware and software. > i count on the OS to "gather" contiguous small pages into > larger ones, possibly based on usage statistics (that the > CPU could gather). The problem is with small task, and you have really a big number of small task. > > 8 kb could be enough > > all new processor have between 5 to 11 page size ! > cool. > however too many sizes might make the LSU more complex :-( > i guess that 4 is the best tradeoff. You know it's totally arbitrary, we currently can't know the impact of the number of different page size, the number of line into the TLB and of course the size of each page size. I think that it depend on the use of the core, so what did you think to add some read only SR that will say to the kernel all this information so that we didn't need to re-"port" OS when we change the usage of the core (or in the future when we need more bigger page size) ? > **************************** > Don't let children look > **************************** Can I read this yann ? ;-) > i just found a REALLY naughty (cough)#hack# .... > it doesn't soleve the page size problems > but removes some "kernel addressing " problems, > which make the LSU a bit more complex... Can you explain it to us ? > > we should try to implement L4 (hurd main kernel) to verify the > > process management of the f-cpu > whatever you want as long you #do# it ... > you know the song.... But before we need an virtual machine and an assembler ;-) > > Looking for technics to handle different page size on the same > > memory for (tlb) to avoid the use of many independant memories > my current method is to have N parallel TLBs with > one size each. Say, 8 entries for 4KB, 8 entries for 32KB, > 8 entries for 256 etc... I think that 4KB is really to small (did you see any process that can be put into a so small page, and don't forget that we are 64bits CPU not a 32bits so we need more place). After discussing with Neal, 8KB and 8MB will be necessary, for other size it's really a random decision ;-) At least, only 8 entries per TLB is really small, you can put a lot of task running at the same time (I think that µKernel will dislike this and all the server that handle many connection at the same time). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jul 13 11:33:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdSo-0000CX-00 for ; Sun, 14 Jul 2002 09:06:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:38 +0200 (CEST) Received: (qmail 16339 invoked by uid 0); 13 Jul 2002 09:33:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 13 Jul 2002 09:33:53 -0000 Received: by moria.seul.org (Postfix) id 1322214694A; Sat, 13 Jul 2002 05:33:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F19D5146955; Sat, 13 Jul 2002 05:33:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 4DDA714694A for ; Sat, 13 Jul 2002 05:33:51 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207130933.24d0; Sat, 13 Jul 2002 09:33:36 GMT Send-By: 147.210.68.141 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 To: Subject: Rep:Re: [f-cpu] little feed-back from the libre softawre meeting From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2002 09:33:36 GMT Message-id: <200207130933.24d0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Interressing stuff ! -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 13/07/02 Objet: Re: [f-cpu] little feed-back from the libre softawre = meeting On Sat, Jul 13, 2002 at 01:30:45AM +0200, whygee@club-intern= et.fr wrote: [...] > > read, write, exec bit + at least 3 rings (super user= + user + > > something like for library,...) >=20 > RWX is ok, because this is how protection is enforced. > i'd say that it is the minimum required TLB feature. *nod* What about different permission bits for different protectio= n levels? Like `supervisor may read and write, j. random luser may onl= y read'. That's probably better than a `user/supervisor' bit or an ex= plicit `page protection level'. >>> During the travel to bordeaux, cedric and i think about = using unix file system style protection. With users, groups and others = permition. But after many discussions to kernel guys, they have nothing= to do with it. >>> Maybe it could be used as user =3D=3D a virtual address = space, other rings are like groups inside the address space. The problem = come when you want to change the ring : how do you come back to the go= od ring ? (with a stack ?) =20 >>> Praticaly you access the tlb with virtual adress + the a= sn (address space number manage by the sw, the name came from alpha worl= d), it return a miss or the physical address + the tags. The tags could be simply the rwx bit + rings number. If we = want real kind of groups (like unix file system), it must send back th= e rights for every ring and we must compare the bit according to the stat= us of the current code. Could be interresting if there isn't too much = ring. > Concerning rings and groups, the issue is still open, > as several proposal and ideas are floating and careless > design will turn F-CPU implementations into a VAX-like, > or worse... helping SW and OS is ok, as long as we don't > do in HW all the work. It must be also "friendly" with > many OS approaches, so i choose the "least common denomina= tor" > approach. A TLB with RWX rights and VMID is the most commo= n > feature and it's straight-forward to understand for SW and > HW design. I'll try to continue to speak with the OS guyz > (linux, Hurd and *BSD) to sort this. Misquoting Bill Gates: `Two protection levels should be enough for every OS.' [...] >>>It's the guy who write the grsecurity patch that say that= some people try to use the third ring of x86 to increase protection. > >>From my view, > > none polling thread barrer should be implemented (fo= r tigh > > multithreaded application on multicpu) >=20 > please rephrase that and spellcheck it, i did not understa= nd. He probably meant: a non-polling thread barrier should be im= plemented for `tight' multithreading. I'm not sure what he means with `thr= ead barrier', though - something like a hardware semaphore? >>>kind of. But much more simple. More like a mutexes. It co= me to my mind when i see here one of my professor from my university = year ;p In some courses, i have seen different model to program mas= sevily parrallel machine. For the professor, the easier way and the= most effective way of programming is "big step" programm. Each pr= ocessor run it's own thread so this could be used at the thread level.=20 >>>In fact, imagine a big loop split in 4 inside 4 thread. A= fter the loop, the program reused the data. Instead having a costly s= emaphore. A easy way to do it is to put a "barrer", when a thread finish= its work it reach the barrer and must wait the other when the 4 threads = have reach the barrer the program continue. >>> It could be a kind of mutexes, and could be uniq for a g= roup of thread. For the futur it could be nice to have more than a u= niq ressource. Imagine actual multireaded application but compil= e to use more than a single cpu. So each " programmed thread" could h= ave has many threads as cpu. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jul 13 11:45:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdSp-0000CX-00 for ; Sun, 14 Jul 2002 09:06:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:39 +0200 (CEST) Received: (qmail 31874 invoked by uid 0); 13 Jul 2002 09:46:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 13 Jul 2002 09:46:05 -0000 Received: by moria.seul.org (Postfix) id 3908914693C; Sat, 13 Jul 2002 05:46:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23D88146955; Sat, 13 Jul 2002 05:46:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 64D5714693C for ; Sat, 13 Jul 2002 05:46:01 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207130945.2dad; Sat, 13 Jul 2002 09:45:45 GMT Send-By: 147.210.68.141 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 To: Subject: Rep:Re: [f-cpu] little feed-back from the libre softawre meeting From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2002 09:45:45 GMT Message-id: <200207130945.2dad@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 13/07/02 Objet: Re: [f-cpu] little feed-back from the libre softawre = meeting hello, new and not-so-new readers, i am at LSM until monday and internet access is not easy for my poorly configured computers, but most mails recipients are physically here :-) ----Message d'origine---- >De: "Nicolas Boulay" > >Cedric, Whygee and i have travel to Bordeaux to assist to t= he libre >software meeting ( lsm.abul.org ). Lots of people from very= differents >open/libre source word are comming. > >It end tomorow. The following is a little feed-back from ou= r discussion >with different people. (we don't know where is whygee so i = send you >without his rereading) sorry, i woke up late and had to gather some food for the we= ek-end, i explained the F-CPU development to a Hurd guy all night long... >Security point of view > > They propose : > read, write, exec bit + at least 3 rings (super user += user + > something like for library,...) RWX is ok, because this is how protection is enforced. i'd say that it is the minimum required TLB feature. Concerning rings and groups, the issue is still open, as several proposal and ideas are floating and careless design will turn F-CPU implementations into a VAX-like, or worse... helping SW and OS is ok, as long as we don't do in HW all the work. It must be also "friendly" with many OS approaches, so i choose the "least common denominato= r" approach. A TLB with RWX rights and VMID is the most common feature and it's straight-forward to understand for SW and HW design. I'll try to continue to speak with the OS guyz (linux, Hurd and *BSD) to sort this. >>>From Cedric thinks : > we need 3 sr : to set or unset the tbl=20 i presume that we will need much more, as the interface must remain clean and orthogonal throughout different core types... let's make something simple, logical and easy to understand from the beginning, even though if we don't use all the features now... > something to change the ring > for vm writter we must enable or not the read > access to sr(trap on read AND write) SRs will contain a place which says what the current user can read and/or write =3D> not a problem (it's slow anyway, = so...) it's not yet defined in the VHDL sources but will become a reality whenever the corresponding piece of code is writte= n. >>>From discussion with a Hurd guy (Neal Wafield) hmmm... speaking about God and its saints .. ;-) we started speaking about IPC yesterday... > 16 kb for a page is a little bit to much why ? if you have huge datasets (megabytes, gigabytes...) you will spend your time in the trap handler... i count on the OS to "gather" contiguous small pages into larger ones, possibly based on usage statistics (that the CPU could gather). >>> For neal, the probleme came when a task ask for a very l= arge amount of memory you gie him a large page but then he will not use = the all memory so it could be good to catch all the unused memory. T= hat's could only be done with smaller page size. =20 > 8 kb could be enough > all new processor have between 5 to 11 page size ! cool. however too many sizes might make the LSU more complex :-( i guess that 4 is the best tradeoff. >>> i-64 give 4, 8,16,... kb page size (11 size !) **************************** Don't let children look **************************** i just found a REALLY naughty (cough)#hack# .... it doesn't soleve the page size problems but removes some "kernel addressing " problems, which make the LSU a bit more complex... > alpha handle an 8 bits fields for virtual area number = (for tlb and > caches) -> sw must avoid collusion. you mean "collision" ? :o) > we should try to implement L4 (hurd main kernel) to ve= rify the > process management of the f-cpu whatever you want as long you #do# it ... you know the song.... >>>From my view, > none polling thread barrer should be implemented (for = tigh > multithreaded application on multicpu) please rephrase that and spellcheck it, i did not understand= . >Conclusion : > implemented L4 > change specification of the tlb (no more the kind of c= aches use > but an 8 bits fields) 8-bit field if you want but will this solve virtual aliases problems ? >>> That's the sw problem ! you need bigger number than the = number of line in the tlb (8 bits =3D=3D=3D maximum 255 line in the tl= b) > Looking for technics to handle different page size on = the same > memory for (tlb) to avoid the use of many independan= t memories my current method is to have N parallel TLBs with=20 one size each. Say, 8 entries for 4KB, 8 entries for 32KB, 8 entries for 256 etc... >>>That's few !! It will be better to avoid so much differen= t table but maybe it's the only solution. nicO (that go to see the RMS show ;p) >Hope this help. Comments ? let's have a talk :-) >nicO and Cedric YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Jul 13 18:28:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdT2-0000CX-01 for ; Sun, 14 Jul 2002 09:06:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:52 +0200 (CEST) Received: (qmail 11710 invoked by uid 0); 13 Jul 2002 16:30:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 13 Jul 2002 16:30:08 -0000 Received: by moria.seul.org (Postfix) id 9868A1467F9; Sat, 13 Jul 2002 12:30:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E80114692C; Sat, 13 Jul 2002 12:30:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 5001B1467F9 for ; Sat, 13 Jul 2002 12:30:04 -0400 (EDT) Received: from hli (80.14.37.229) by smtp.laposte.net (6.0.053) id 3D2EF5910000D495 for f-cpu@seul.org; Sat, 13 Jul 2002 18:30:03 +0200 Message-ID: <001201c22a8a$56b410d0$e5250e50@hli> From: "Christophe Avoinne" To: References: <20020713015703.08661@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Sat, 13 Jul 2002 18:28:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Saturday, July 13, 2002 1:57 AM Subject: Re: [f-cpu] little feed-back from the libre softawre meeting > On Sat, Jul 13, 2002 at 01:30:45AM +0200, whygee@club-internet.fr wrote: > [...] > > > read, write, exec bit + at least 3 rings (super user + user + > > > something like for library,...) > > > > RWX is ok, because this is how protection is enforced. > > i'd say that it is the minimum required TLB feature. > > *nod* > > What about different permission bits for different protection levels? > Like `supervisor may read and write, j. random luser may only read'. > That's probably better than a `user/supervisor' bit or an explicit > `page protection level'. > 1) Permission bits : rwx - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and "store" operations), but what could be the meaning of 'x' ? - 'x' is relevant for code memory (ICACHE, instruction "load" operations, but what could be the meaning of 'r' or 'w' ?. It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' bit. But my question is about knowing if there would be two different TLB or an unified one ? 2) Supervisor/user bits : - 's' : some instructions which are considered as priviledged requires this bit set. But I aggree with you : we should have like 'sr','sw','ur','uw' for data memory and 'sx','ux' for code memory (that way we can protect some user applications for accessing supervisor code pages with 'sx = 1' and 'ux' = 0 in fact) if we want a more fined-grain protection. 3) How to share code between memory spaces, especially for kernel or shared library codes : - code pages can be shared between space memories; using a bit to tell if VMID must be checked for this page allows kernel code or shared library to run without excessive cache flushing because of a VMID differs between two processes. 4) Group bits : are we speaking about equivalence of unix group bits ? that is 'u','g' and 'o' ? 5) Ring bits : well instead of Supervisor/user bit we have several bits to encode a level ring. A page must have a ring of lower priority to be accessed. 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail them here. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Sun Jul 14 00:06:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdT3-0000CX-00 for ; Sun, 14 Jul 2002 09:06:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:53 +0200 (CEST) Received: (qmail 29892 invoked by uid 0); 13 Jul 2002 17:06:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 13 Jul 2002 17:06:20 -0000 Received: by moria.seul.org (Postfix) id B19BF146844; Sat, 13 Jul 2002 13:06:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8F25A14692C; Sat, 13 Jul 2002 13:06:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id DB61B146844 for ; Sat, 13 Jul 2002 13:06:14 -0400 (EDT) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-1v.club-internet.fr (Postfix) with SMTP id BDC3A1691; Sat, 13 Jul 2002 19:06:12 +0200 (CEST) Received: from [147.210.68.141] by flashmail-5v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] little feed-back from the libre softawre meeting Date: Sat, 13 Jul 2002 19:06:13 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: =22Nicolas Boulay=22 >De: whygee=40club-internet.fr >>>>From discussion with a Hurd guy (Neal Wafield) >hmmm... speaking about God and its saints .. ;-) >we started speaking about IPC yesterday... > >> 16 kb for a page is a little bit to much >why ? if you have huge datasets (megabytes, gigabytes...) >you will spend your time in the trap handler... >i count on the OS to =22gather=22 contiguous small pages into >larger ones, possibly based on usage statistics (that the >CPU could gather). > >>>> For neal, the probleme came when a task ask for a very large amount >of memory you gie him a large page but then he will not use the all >memory so it could be good to catch all the unused memory. That's could >only be done with smaller page size. = i'm currently in the FreeBSD room ... they gave me an indication : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D332902+0+archive/2002/freeb= sd-alpha/20020707.freebsd-alpha which contains another link : * http://shimizu-lab.dt.u-tokai.ac.jp/lsp.html * http://www.cs.rice.edu/=7Ejnavarro/mitosis >> 8 kb could be enough >> all new processor have between 5 to 11 page size =21 >cool. >however too many sizes might make the LSU more complex :-( >i guess that 4 is the best tradeoff. > >>>> i-64 give 4, 8,16,... kb page size (11 size =21) it will depend on the possibility to have several sizes... >>Conclusion : >> implemented L4 >> change specification of the tlb (no more the kind of caches use >> but an 8 bits fields) > >8-bit field if you want but will this solve virtual >aliases problems ? > >>>> That's the sw problem =21 you need bigger number than the number of >line in the tlb (8 bits =3D=3D=3D maximum 255 line in the tlb) hmmm ..... that's another problem... >my current method is to have N parallel TLBs with = >one size each. Say, 8 entries for 4KB, 8 entries for 32KB, >8 entries for 256 etc... > >>>>That's few =21=21 let's start with something that works first, no ? > It will be better to avoid so much different table but >maybe it's the only solution. >nicO (that go to see the RMS show ;p) time to wake up :-( ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jul 13 22:34:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdT7-0000CX-00 for ; Sun, 14 Jul 2002 09:06:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:57 +0200 (CEST) Received: (qmail 26993 invoked by uid 0); 13 Jul 2002 22:19:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 13 Jul 2002 22:19:08 -0000 Received: by moria.seul.org (Postfix) id A6EB41467FE; Sat, 13 Jul 2002 18:19:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 64903146802; Sat, 13 Jul 2002 18:19:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a141.home.uni-hannover.de [130.75.232.141]) by moria.seul.org (Postfix) with ESMTP id 7F4631467FE for ; Sat, 13 Jul 2002 18:19:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01318; Sat, 13 Jul 2002 22:34:04 +0200 Message-ID: <20020713223404.57058@thrai.stud.uni-hannover.de> Date: Sat, 13 Jul 2002 22:34:04 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] TLB design Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I've been thinking about the TLB before; IMHO, we need at least the following (assuming bits for the page offset): - virtual address (64- bits) - physical address (64- bits) - address space identifier (ASI; 8 bits was suggested) - supervisor access rights (RWX, 3 bits) - user access rights (RWX, 3 bits) - valid bit (indicating that the entry is valid) - present bit (indicating that the page is in memory) - dirty bit (indicating that the page has been written to) - used bit (indicating that the page has been accessed) The latter can be used to implement an LRU algorithm. That is, we need 128+2*-18 bits. If an entry shall fit into 128 bits, must be at least 9 (i.e. a page must have at least 512 bytes). With 4K pages, we will have 6 bits left. Some (or all) of them may be used to indicate the page size. A TLB lookup is performed by XORing the address and ASI fields with the actual values; if the result is 0, the entry matches. If we are going to use multiple page sizes, the result must be ANDed with a mask that depends on the page size. The question is how we choose the page sizes. With 4K/32K/256K/2M pages and 8 entries per size we can map only ~18M of memory at the same time, and we will have a hard time if we want to map arbitrary segments (with sizes that are not a power of two). Additionally, the CPU will spend a lot of time inside the TLB miss handler. Note that there are applications that easily take megabytes of code space and hundreds or even thousands of megabytes of data -- that's the kind of program a 64-bit CPU is most useful for, because it has a large address space. It's probably better to provide all page sizes that are powers of two, >from 4K up to at least 4G. It may also be a good idea to implement a `best match' strategy: if multiple TLB entries match a virtual address, the most specific one (that is, the one with the smallest page size) is chosen. That way you can put small `windows' inside a bigger page. The total number of TLB entries should not be smaller than 256. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jul 14 00:54:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17TdT8-0000CX-00 for ; Sun, 14 Jul 2002 09:06:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 09:06:58 +0200 (CEST) Received: (qmail 21351 invoked by uid 0); 13 Jul 2002 22:54:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 13 Jul 2002 22:54:41 -0000 Received: by moria.seul.org (Postfix) id 29E6F146800; Sat, 13 Jul 2002 18:54:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F4122146929; Sat, 13 Jul 2002 18:54:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a141.home.uni-hannover.de [130.75.232.141]) by moria.seul.org (Postfix) with ESMTP id 41359146800 for ; Sat, 13 Jul 2002 18:54:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01780; Sun, 14 Jul 2002 00:54:34 +0200 Message-ID: <20020714005434.64899@thrai.stud.uni-hannover.de> Date: Sun, 14 Jul 2002 00:54:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001201c22a8a$56b410d0$e5250e50@hli>; from Christophe Avoinne on Sat, Jul 13, 2002 at 06:28:35PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jul 13, 2002 at 06:28:35PM +0200, Christophe Avoinne wrote: [...] > 1) Permission bits : rwx > - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and > "store" operations), but what could be the meaning of 'x' ? > - 'x' is relevant for code memory (ICACHE, instruction "load" > operations, but what could be the meaning of 'r' or 'w' ?. > It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' bit. > But my question is about knowing if there would be two different TLB or an > unified one ? Different TLB entries for data and code `views' of the same page of memory? That may introduce yet another aliasing problem. BTW: why should a page NOT be both writable and executable? > 2) Supervisor/user bits : > - 's' : some instructions which are considered as priviledged requires > this bit set. Inside the TLB? > But I aggree with you : we should have like 'sr','sw','ur','uw' for data > memory and 'sx','ux' for code memory (that way we can protect some user > applications for accessing supervisor code pages with 'sx = 1' and 'ux' = 0 > in fact) if we want a more fined-grain protection. > > 3) How to share code between memory spaces, especially for kernel or shared > library codes : > - code pages can be shared between space memories; using a bit to tell > if VMID must be checked for this page allows kernel code or shared library > to run without excessive cache flushing because of a VMID differs between > two processes. In reality, processes sharing a code page will have individual TLB entries for it, with different VMIDs. The page is shared, the TLB entry isn't. > 4) Group bits : are we speaking about equivalence of unix group bits ? that > is 'u','g' and 'o' ? Not useful, IMHO. We only have two different user IDs: ordinary user and supervisor. > 5) Ring bits : well instead of Supervisor/user bit we have several bits to > encode a level ring. A page must have a ring of lower priority to be > accessed. Big can of worms. If privileged code always has at least the same access rights as unprivileged code, you have a built-in security hole (see Intel). Contrary to popular belief, one must be able to give privileged code *less* access rights than unprivileged code. > 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail > them here. Who inherits what? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jul 14 20:09:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4M-0000Wx-00 for ; Sun, 14 Jul 2002 21:30:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:10 +0200 (CEST) Received: (qmail 2745 invoked by uid 0); 14 Jul 2002 18:06:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 14 Jul 2002 18:06:46 -0000 Received: by moria.seul.org (Postfix) id 7537B14693A; Sun, 14 Jul 2002 14:06:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 291EF14693E; Sun, 14 Jul 2002 14:06:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id A3D0814693A for ; Sun, 14 Jul 2002 14:06:43 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id BC4575F866 for ; Sun, 14 Jul 2002 20:06:11 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 09A2DFCFA; Sun, 14 Jul 2002 20:09:52 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026670191.3d31be6ff0517@imp.free.fr> Date: Sun, 14 Jul 2002 20:09:51 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> In-Reply-To: <20020714005434.64899@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.251.188.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > 2) Supervisor/user bits : > > - 's' : some instructions which are considered as priviledged requires > > this bit set. > > Inside the TLB? Question: which instruction, normally the only one is get and put the other didn't affect the CPU ? > > But I aggree with you : we should have like 'sr','sw','ur','uw' for data > > memory and 'sx','ux' for code memory (that way we can protect some user > > applications for accessing supervisor code pages with 'sx = 1' and 'ux' = 0 > > in fact) if we want a more fined-grain protection. you must have rwx bits that must be differencied. I mean that on a x86, you have difficult to sy that a page is only executable and not readable, in fact it was the only big recommandation, we must have 3 bits to say rwx rights. > > 5) Ring bits : well instead of Supervisor/user bit we have several bits to > > encode a level ring. A page must have a ring of lower priority to be > > accessed. > > Big can of worms. If privileged code always has at least the same > access rights as unprivileged code, you have a built-in security hole > (see Intel). Contrary to popular belief, one must be able to give > privileged code *less* access rights than unprivileged code. In fact ring a really not useful, I think that on the majority of the processor where it's implemented it is not used. (in hurd, and linux it's not used, i don't know for bsd). > > 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail > > them here. > > Who inherits what? I didn't understand the meaning of inheritance bits. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jul 14 20:12:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4M-0000Wx-01 for ; Sun, 14 Jul 2002 21:30:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:10 +0200 (CEST) Received: (qmail 28588 invoked by uid 0); 14 Jul 2002 18:12:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 14 Jul 2002 18:12:23 -0000 Received: by moria.seul.org (Postfix) id A125614693B; Sun, 14 Jul 2002 14:12:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CD2314693F; Sun, 14 Jul 2002 14:12:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id A32A014693B for ; Sun, 14 Jul 2002 14:12:20 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix3-2.free.fr (Postfix) with ESMTP id ACDCB17FAC for ; Sun, 14 Jul 2002 20:12:19 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id 9EA2511A06; Sun, 14 Jul 2002 20:12:19 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design Message-ID: <1026670339.3d31bf03926c5@imp.free.fr> Date: Sun, 14 Jul 2002 20:12:19 +0200 (MEST) From: Cedric BAIL References: <20020713223404.57058@thrai.stud.uni-hannover.de> In-Reply-To: <20020713223404.57058@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.251.188.8 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I've been thinking about the TLB before; IMHO, we need at least the > following (assuming bits for the page offset): > > - virtual address (64- bits) > - physical address (64- bits) > - address space identifier (ASI; 8 bits was suggested) > - supervisor access rights (RWX, 3 bits) > - user access rights (RWX, 3 bits) > - valid bit (indicating that the entry is valid) > - present bit (indicating that the page is in memory) What did you mean whith this bit ? > - dirty bit (indicating that the page has been written to) Same question. > - used bit (indicating that the page has been accessed) Why not a counter ? I currently don't see how the OS can make it's decision about how to remove a TLB entry if TLB is full. > The latter can be used to implement an LRU algorithm. > That is, we need 128+2*-18 bits. If an entry shall fit into 128 bits, > must be at least 9 (i.e. a page must have at least 512 bytes). > With 4K pages, we will have 6 bits left. Some (or all) of them may be > used to indicate the page size. That's a really nice idea in fact. But what did this bit mean, are they number of Ko for a page, or predefined size page ? > A TLB lookup is performed by XORing the address and ASI fields with the > actual values; if the result is 0, the entry matches. If we are going > to use multiple page sizes, the result must be ANDed with a mask that > depends on the page size. > The question is how we choose the page sizes. With 4K/32K/256K/2M > pages and 8 entries per size we can map only ~18M of memory at the same > time, and we will have a hard time if we want to map arbitrary segments > (with sizes that are not a power of two). Additionally, the CPU will spend a > lot of time inside the TLB miss handler. Note that there are applications > that easily take megabytes of code space and hundreds or even thousands > of megabytes of data -- that's the kind of program a 64-bit CPU is most > useful for, because it has a large address space. > It's probably better to provide all page sizes that are powers of two, > from 4K up to at least 4G. It may also be a good idea to implement a > `best match' strategy: if multiple TLB entries match a virtual > address, the most specific one (that is, the one with the smallest page size) > is chosen. That way you can put small `windows' inside a bigger page. > The total number of TLB entries should not be smaller than 256. That's a great idea, and if can do it in the F-CPU it will be really nice. I really like your idea and I think it will solve a lot of TLB problem. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 14 20:17:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4N-0000Wx-00 for ; Sun, 14 Jul 2002 21:30:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:11 +0200 (CEST) Received: (qmail 26264 invoked by uid 0); 14 Jul 2002 18:19:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 14 Jul 2002 18:19:03 -0000 Received: by moria.seul.org (Postfix) id 144C314693E; Sun, 14 Jul 2002 14:19:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6587146940; Sun, 14 Jul 2002 14:19:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 538A614693E for ; Sun, 14 Jul 2002 14:19:01 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EF5910001D681 for f-cpu@seul.org; Sun, 14 Jul 2002 20:19:00 +0200 Message-ID: <001201c22b62$b7c9cbc0$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713223404.57058@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] TLB design Date: Sun, 14 Jul 2002 20:17:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N We should have have a bit to tell if we must check the ASI or not. Kernel pages are always shared between processes which have different ASI. As an example, Intel has added a global bit from the Pentium II because they realised that OS was slowed down because kernal pages were invalidated when switching space memory !!! ----- Original Message ----- From: "Michael Riepe" To: "F-CPU Mailing List" Sent: Saturday, July 13, 2002 10:34 PM Subject: [f-cpu] TLB design > I've been thinking about the TLB before; IMHO, we need at least the > following (assuming bits for the page offset): > > - virtual address (64- bits) > - physical address (64- bits) > - address space identifier (ASI; 8 bits was suggested) > - supervisor access rights (RWX, 3 bits) > - user access rights (RWX, 3 bits) > - valid bit (indicating that the entry is valid) > - present bit (indicating that the page is in memory) > - dirty bit (indicating that the page has been written to) > - used bit (indicating that the page has been accessed) > > The latter can be used to implement an LRU algorithm. > > That is, we need 128+2*-18 bits. If an entry shall fit into 128 bits, > must be at least 9 (i.e. a page must have at least 512 bytes). > With 4K pages, we will have 6 bits left. Some (or all) of them may be > used to indicate the page size. > > A TLB lookup is performed by XORing the address and ASI fields with the > actual values; if the result is 0, the entry matches. If we are going > to use multiple page sizes, the result must be ANDed with a mask that > depends on the page size. > > The question is how we choose the page sizes. With 4K/32K/256K/2M pages > and 8 entries per size we can map only ~18M of memory at the same time, > and we will have a hard time if we want to map arbitrary segments (with > sizes that are not a power of two). Additionally, the CPU will spend a > lot of time inside the TLB miss handler. Note that there are applications > that easily take megabytes of code space and hundreds or even thousands > of megabytes of data -- that's the kind of program a 64-bit CPU is most > useful for, because it has a large address space. > > It's probably better to provide all page sizes that are powers of two, > from 4K up to at least 4G. It may also be a good idea to implement a > `best match' strategy: if multiple TLB entries match a virtual address, > the most specific one (that is, the one with the smallest page size) > is chosen. That way you can put small `windows' inside a bigger page. > The total number of TLB entries should not be smaller than 256. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 14 20:41:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4O-0000Wx-01 for ; Sun, 14 Jul 2002 21:30:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:12 +0200 (CEST) Received: (qmail 22857 invoked by uid 0); 14 Jul 2002 18:42:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 14 Jul 2002 18:42:36 -0000 Received: by moria.seul.org (Postfix) id 53F4114693F; Sun, 14 Jul 2002 14:42:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 297F5146941; Sun, 14 Jul 2002 14:42:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9E8FB14693F for ; Sun, 14 Jul 2002 14:42:33 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB28C00020D7D for f-cpu@seul.org; Sun, 14 Jul 2002 20:42:32 +0200 Message-ID: <001801c22b66$012c6360$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Sun, 14 Jul 2002 20:41:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Sunday, July 14, 2002 12:54 AM Subject: Re: [f-cpu] little feed-back from the libre softawre meeting > On Sat, Jul 13, 2002 at 06:28:35PM +0200, Christophe Avoinne wrote: > [...] > > 1) Permission bits : rwx > > - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and > > "store" operations), but what could be the meaning of 'x' ? > > - 'x' is relevant for code memory (ICACHE, instruction "load" > > operations, but what could be the meaning of 'r' or 'w' ?. > > It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' bit. > > But my question is about knowing if there would be two different TLB or an > > unified one ? > > Different TLB entries for data and code `views' of the same page of > memory? That may introduce yet another aliasing problem. > > BTW: why should a page NOT be both writable and executable? When reading or writing a code segment, you use "load"/"store" instructions to do so, so it is clearly a DCACHE operation even if page contains a code When executing (that is reading with ICACHE), it is the scheduler which reads, so it is clearly a ICACHE operation. So if you have separate TLB entries for ICACHE and DCACHE, it makes nonsense to speak about a page writable in a TLB entry for ICACHE. Do you understand what I mean now ? Now, the problem is to know if the entries for TLB are unified for both ICACHE or DCACHE ? > > > 2) Supervisor/user bits : > > - 's' : some instructions which are considered as priviledged requires > > this bit set. > > Inside the TLB? > It is just a question. Usually in ISA there is some instructions too dangerous to be handled by an application. > > 3) How to share code between memory spaces, especially for kernel or shared > > library codes : > > - code pages can be shared between space memories; using a bit to tell > > if VMID must be checked for this page allows kernel code or shared library > > to run without excessive cache flushing because of a VMID differs between > > two processes. > > In reality, processes sharing a code page will have individual TLB entries > for it, with different VMIDs. The page is shared, the TLB entry isn't. > ??? you use a SW tlb, that is ? so you'd better to avoid having several entries pointed out on the same kernel page because of different VMID. Try to imagine 8 actives processes, you spoiled 8 entries whereas you can just have one entrie for any processes. If you look at the most of SW TLB they have a bit to to tell if we want to check VMID or bypass. If, unhappily, you switch a new process (that is a new VMID), your running kernel code would be invalidated because of the VMID. It is stupid. > > 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail > > them here. > > Who inherits what? Rights for access on page for children, something like : deny, one-level inheritance,deep inheritance, etc. My memory is leaking. I don't remember if it is an issue I read in L4 or something else. Anyway, it doesn't matter because I think it is clearly a SW issue which occurs when you want to share page between father and children. A very interestion point but off-topic here since I don't think we need extra bits for them in TLB ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 14 20:48:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4P-0000Wx-00 for ; Sun, 14 Jul 2002 21:30:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:13 +0200 (CEST) Received: (qmail 9110 invoked by uid 0); 14 Jul 2002 19:17:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Jul 2002 19:17:31 -0000 Received: by moria.seul.org (Postfix) id 4D4C9146811; Sun, 14 Jul 2002 15:17:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1184E146941; Sun, 14 Jul 2002 15:17:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id B1917146811 for ; Sun, 14 Jul 2002 15:17:28 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB60900022249 for f-cpu@seul.org; Sun, 14 Jul 2002 21:17:28 +0200 Message-ID: <000201c22b6a$e278a3c0$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Sun, 14 Jul 2002 20:48:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Seriously, 'x' : executable -> ICACHE, because it is the instruction fetcher which needs to access bytes in code page : IT NEVER WRITES !!! so 'x' is in fact a disguised 'r' and 'w' a non-sense. 'r','w' : readable, writable -> DCACHE, because it is the LSU which needs to access bytes in data page : IT NEVER EXECUTES !!! When you write code in page you are indeed using LSU for that purpose so you handle its page like a data page not as a code page. ----- Original Message ----- From: "Cedric BAIL" To: Sent: Sunday, July 14, 2002 8:09 PM Subject: Re: [f-cpu] little feed-back from the libre softawre meeting > > > 2) Supervisor/user bits : > > > - 's' : some instructions which are considered as priviledged requires > > > this bit set. > > > > Inside the TLB? > > Question: which instruction, normally the only one is get and put the other > didn't affect the CPU ? > > > > But I aggree with you : we should have like 'sr','sw','ur','uw' for data > > > memory and 'sx','ux' for code memory (that way we can protect some user > > > applications for accessing supervisor code pages with 'sx = 1' and 'ux' = 0 > > > in fact) if we want a more fined-grain protection. > > you must have rwx bits that must be differencied. I mean that on a x86, you > have difficult to sy that a page is only executable and not readable, in fact > it was the only big recommandation, we must have 3 bits to say rwx rights. > > > > 5) Ring bits : well instead of Supervisor/user bit we have several bits to > > > encode a level ring. A page must have a ring of lower priority to be > > > accessed. > > > > Big can of worms. If privileged code always has at least the same > > access rights as unprivileged code, you have a built-in security hole > > (see Intel). Contrary to popular belief, one must be able to give > > privileged code *less* access rights than unprivileged code. > > In fact ring a really not useful, I think that on the majority of the > processor where it's implemented it is not used. (in hurd, and linux it's > not used, i don't know for bsd). > > > > 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail > > > them here. > > > > Who inherits what? > > I didn't understand the meaning of inheritance bits. > > Cedric > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 14 21:15:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tp4Q-0000Wx-00 for ; Sun, 14 Jul 2002 21:30:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 21:30:14 +0200 (CEST) Received: (qmail 24923 invoked by uid 0); 14 Jul 2002 19:17:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 14 Jul 2002 19:17:34 -0000 Received: by moria.seul.org (Postfix) id 25175146942; Sun, 14 Jul 2002 15:17:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ED94C146944; Sun, 14 Jul 2002 15:17:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 235F5146942 for ; Sun, 14 Jul 2002 15:17:29 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB6090002224A for f-cpu@seul.org; Sun, 14 Jul 2002 21:17:29 +0200 Message-ID: <000301c22b6a$e309c030$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> Subject: Re: [f-cpu] TLB design Date: Sun, 14 Jul 2002 21:15:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Sunday, July 14, 2002 8:12 PM Subject: Re: [f-cpu] TLB design > > - virtual address (64- bits) > > - physical address (64- bits) > > - address space identifier (ASI; 8 bits was suggested) > > - supervisor access rights (RWX, 3 bits) > > - user access rights (RWX, 3 bits) > > - valid bit (indicating that the entry is valid) > > - present bit (indicating that the page is in memory) > What did you mean whith this bit ? Present bit is absolutely necessary for HW tlb, it is to say that entry is not a valid mapping and help us to raise an exception to fix it. We use it to implement virtual memory swapping from/to mass storage. But I don't know if it is necessary for SW tlb, I thought SW tlb only contained valid page entries (since if not in TLB, it always raises an exception). > > - dirty bit (indicating that the page has been written to) > Same question. This page was modified by someone so we could need to synchronise with external storage, it is absolutely necessary for virtual memory and file mapping. > > - used bit (indicating that the page has been accessed) > Why not a counter ? I currently don't see how the OS can make it's decision > about how to remove a TLB entry if TLB is full. It is the only way to know if this page was accessed at least one time, absolutely necessary for virtual memory. Counter is interesting but still a luxe. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jul 14 23:14:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tqrd-00025b-00 for ; Sun, 14 Jul 2002 23:25:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Sun, 14 Jul 2002 23:25:09 +0200 (CEST) Received: (qmail 3112 invoked by uid 0); 14 Jul 2002 21:11:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 14 Jul 2002 21:11:13 -0000 Received: by moria.seul.org (Postfix) id 079CA146934; Sun, 14 Jul 2002 17:11:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D370D146940; Sun, 14 Jul 2002 17:11:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 3CE94146934 for ; Sun, 14 Jul 2002 17:11:11 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id C14835F773 for ; Sun, 14 Jul 2002 23:11:10 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 92E36FCFA; Sun, 14 Jul 2002 23:14:51 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design Message-ID: <1026681291.3d31e9cb87570@imp.free.fr> Date: Sun, 14 Jul 2002 23:14:51 +0200 (MEST) From: Cedric BAIL References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <000301c22b6a$e309c030$5e250e50@hli> In-Reply-To: <000301c22b6a$e309c030$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > - virtual address (64- bits) > > > - physical address (64- bits) > > > - address space identifier (ASI; 8 bits was suggested) > > > - supervisor access rights (RWX, 3 bits) > > > - user access rights (RWX, 3 bits) > > > - valid bit (indicating that the entry is valid) > > > - present bit (indicating that the page is in memory) > > What did you mean whith this bit ? > > Present bit is absolutely necessary for HW tlb, it is to say that entry > is not a valid mapping and help us to raise an exception to fix it. For my point of view you valid page or not, normally you only have entry in the TLB that are corresponding to memory. So what is the difference between this two bits ? > We use it to implement virtual memory swapping from/to mass storage. Ok, but that's not a clean method. The VM detect that's you need to swap, so she select a page to swap and remove them from the virtual address space. Then they are transfered to the disk. When the task wake up, and access to this page you make a TLB miss, and you start to remove some other from the virtual address space to the disk and then you put the other to the new free space and set entry in the TLB. For me, you don't have enough entry into the TLB to say that some of them are mapped to disk, and on rescent computer the swap are not so much use (database program prefer to have their own save polici). > But I don't know if it is necessary for SW tlb, I thought SW tlb only > contained valid page entries (since if not in TLB, it always raises an > exception). For me, it's a SW problem, that can take place in userspace, so really no need in HW. > > > - dirty bit (indicating that the page has been written to) > > Same question. > > This page was modified by someone so we could need to synchronise with > external storage, it is absolutely necessary for virtual memory and > file mapping. You mean Copy On Write technique ? > > > - used bit (indicating that the page has been accessed) > > Why not a counter ? I currently don't see how the OS can make it's decision > > about how to remove a TLB entry if TLB is full. > It is the only way to know if this page was accessed at least one time, > absolutely necessary for virtual memory. Counter is interesting but > still a luxe. Ok, I understand. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jul 14 23:27:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1m-0003dk-00 for ; Mon, 15 Jul 2002 01:43:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:46 +0200 (CEST) Received: (qmail 5002 invoked by uid 0); 14 Jul 2002 21:24:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 14 Jul 2002 21:24:00 -0000 Received: by moria.seul.org (Postfix) id 4C5EF146938; Sun, 14 Jul 2002 17:23:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2366D146941; Sun, 14 Jul 2002 17:23:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id C03BF146938 for ; Sun, 14 Jul 2002 17:23:58 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-1.free.fr (Postfix) with ESMTP id EE0B62F4 for ; Sun, 14 Jul 2002 23:23:57 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id C10C6FCFA; Sun, 14 Jul 2002 23:27:38 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026682058.3d31eccaa2313@imp.free.fr> Date: Sun, 14 Jul 2002 23:27:38 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> <000201c22b6a$e278a3c0$5e250e50@hli> In-Reply-To: <000201c22b6a$e278a3c0$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Seriously, > 'x' : executable -> ICACHE, because it is the instruction fetcher > which needs to access bytes in code page : IT NEVER WRITES !!! so 'x' is in > fact a disguised 'r' and 'w' a non-sense. If I understand what you say, we can't write "automodify" code. > 'r','w' : readable, writable -> DCACHE, because it is the LSU which > needs to access bytes in data page : IT NEVER EXECUTES !!! Why not, we must not block this possibility. > When you write code in page you are indeed using LSU for that purpose so > you handle its page like a data page not as a code page. So you have to TLB, one for data, and one for fetcher, so you divide by two the capacity of the OS to do a "load balancing" of TLB entry. And in fact if you wan't to be able to write automodifing code, you will have a lot of problem. I really don't understand your mail, I think Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Jul 14 23:37:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1n-0003dk-00 for ; Mon, 15 Jul 2002 01:43:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:47 +0200 (CEST) Received: (qmail 1637 invoked by uid 0); 14 Jul 2002 21:37:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Jul 2002 21:37:40 -0000 Received: by moria.seul.org (Postfix) id 27558146940; Sun, 14 Jul 2002 17:37:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1276F146944; Sun, 14 Jul 2002 17:37:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 9A765146940 for ; Sun, 14 Jul 2002 17:37:38 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id 245EB5F8C5 for ; Sun, 14 Jul 2002 23:37:38 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 051BC87397; Sun, 14 Jul 2002 23:37:37 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026682657.3d31ef21e6514@imp.free.fr> Date: Sun, 14 Jul 2002 23:37:37 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <001801c22b66$012c6360$5e250e50@hli> In-Reply-To: <001801c22b66$012c6360$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > 1) Permission bits : rwx > > > - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and > > > "store" operations), but what could be the meaning of 'x' ? > > > - 'x' is relevant for code memory (ICACHE, instruction "load" > > > operations, but what could be the meaning of 'r' or 'w' ?. > > > It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' > > > bit.But my question is about knowing if there would be two different TLB > > > or an unified one ? > > Different TLB entries for data and code `views' of the same page of > > memory? That may introduce yet another aliasing problem. > > BTW: why should a page NOT be both writable and executable? > When reading or writing a code segment, you use "load"/"store" > instructions to do so, so it is clearly a DCACHE operation even if page > contains a code > When executing (that is reading with ICACHE), it is the scheduler which > reads, so it is clearly a ICACHE operation. > So if you have separate TLB entries for ICACHE and DCACHE, it makes nonsense > to speak about a page writable in a TLB entry for ICACHE. Do you understand > what I mean now ? > Now, the problem is to know if the entries for TLB are unified for > both ICACHE or DCACHE ? I think it will be an overkill to separate them, because you have normally more data than code. > > > 2) Supervisor/user bits : > > > - 's' : some instructions which are considered as priviledged > > > requires this bit set. > > Inside the TLB? > It is just a question. Usually in ISA there is some instructions too > dangerous to be handled by an application. I don't remind any that are dangerous. Perhaps get and put, but with a trap on it you can do more things. > > > 3) How to share code between memory spaces, especially for kernel or > > > shared library codes : > > > - code pages can be shared between space memories; using a bit to > > > tell if VMID must be checked for this page allows kernel code or shared > > > library to run without excessive cache flushing because of a VMID differs > > > between two processes. > > In reality, processes sharing a code page will have individual TLB entries > > for it, with different VMIDs. The page is shared, the TLB entry isn't. > you use a SW tlb, that is ? so you'd better to avoid having several entries > pointed out on the same kernel page because of different VMID. Try to > imagine 8 actives processes, you spoiled 8 entries whereas you can just have > one entrie for any processes. If you look at the most of SW TLB they have a > bit to to tell if we want to check VMID or bypass. If, unhappily, you switch > a new process (that is a new VMID), your running kernel code would be > invalidated because of the VMID. It is stupid. I agree with this point of view, but not so much OS use this. > > > 6) Inheritance bits : mostly a software issue I think, so I wouldn't > > > detail them here. > > Who inherits what? > Rights for access on page for children, something like : deny, one-level > inheritance,deep inheritance, etc. > My memory is leaking. I don't remember if it is an issue I read in L4 or > something else. Anyway, it doesn't matter because I think it is clearly > a SW issue which occurs when you want to share page between father and > children. > A very interestion point but off-topic here since I don't think we > need extra bits for them in TLB I am interested by this topic, so did you have any url ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 00:22:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1n-0003dk-01 for ; Mon, 15 Jul 2002 01:43:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:47 +0200 (CEST) Received: (qmail 7428 invoked by uid 0); 14 Jul 2002 22:23:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 14 Jul 2002 22:23:57 -0000 Received: by moria.seul.org (Postfix) id 885071467E8; Sun, 14 Jul 2002 18:23:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47BDE1467FA; Sun, 14 Jul 2002 18:23:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id BEFCA1467E8 for ; Sun, 14 Jul 2002 18:23:54 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB28C0002297A for f-cpu@seul.org; Mon, 15 Jul 2002 00:23:54 +0200 Message-ID: <002b01c22b84$edceddb0$5e250e50@hli> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Mon, 15 Jul 2002 00:22:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I'm discouraged... your diagram about F-CPU is speaking about ICACHE and DCACHE, am I wrong ? They are separate !!!! I'm explaining why it is a nonsense to speak about 'r','w' for code page and 'x' for data page, especially if you need a seperate TLB for ICACHE and DCACHE. Of course, if you used a unified TLB for ICACHE and DCACHE, well we can can have entries with 'r', 'w', 'x'. 'r','w' would be relevant accessing DCACHE and 'x' for accessing ICACHE. ----- Original Message ----- From: "Cedric BAIL" To: Sent: Sunday, July 14, 2002 11:27 PM Subject: Re: [f-cpu] little feed-back from the libre softawre meeting > > Seriously, > > > 'x' : executable -> ICACHE, because it is the instruction fetcher > > which needs to access bytes in code page : IT NEVER WRITES !!! so 'x' is in > > fact a disguised 'r' and 'w' a non-sense. > > If I understand what you say, we can't write "automodify" code. Oh my god !!!!! i turn into french explanation : Dis-moi, depuis quand l'unité qui va chercher les instructions à exécuter dans le cache ICACHE peut modifier les instructions en mémoire !? Je suis en train de dire que les opérations 'r', 'w' sont des opérations que seules les instructions 'load' ou 'store' peuvent effectuer en mémoire, c'est à dire par l'unité LSU et non le fetcher d'instruction. Ce n'est pas clair ? Le code auto-modifié se fait précisèment avec des instrcutions "store" donc on passe par le LSU et donc par le DCACHE. ICACHE n'est en rien concerné par l'écriture. De fait tu n'échape à la duplicité en ICACHE et DCACHE et qui fait que beaucoup de CPU n'aime pas le code auto-modifié (problème de cohérence entre ICACHE et DCACHE) > > > 'r','w' : readable, writable -> DCACHE, because it is the LSU which > > needs to access bytes in data page : IT NEVER EXECUTES !!! > > Why not, we must not block this possibility. Again in french, sorry :( Je ne comprends vraiment pas comment un "load"/"store" peut exécuter du code... ce n'est pas le LSU qui est en charge mais le fetcher d'instructions. Si tu regardes les TLB software de la pluparts des CPU, tu verras qu'il y a toujours cette distinction, et que la plupart on bien des TLB distincts. Je ne suis pas contre 'r','w,' et 'x' dans une entrée de TLB mais à condition de savoir bien les utiliser or il faut savoir si le TLB se place avant ou après ICACHE et DCACHE et s'il est unifié, et comment vous l'unifiez. > > > When you write code in page you are indeed using LSU for that purpose so > > you handle its page like a data page not as a code page. > > So you have to TLB, one for data, and one for fetcher, so you divide by two > the capacity of the OS to do a "load balancing" of TLB entry. And in fact if > you wan't to be able to write automodifing code, you will have a lot of problem It only depends if you place your TLB before or after ICACHE and DCACHE and if you unify or not TLB for ICACHE and DCACHE. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 00:46:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1o-0003dk-00 for ; Mon, 15 Jul 2002 01:43:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:48 +0200 (CEST) Received: (qmail 21174 invoked by uid 0); 14 Jul 2002 22:46:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 14 Jul 2002 22:46:56 -0000 Received: by moria.seul.org (Postfix) id CBCA91467F7; Sun, 14 Jul 2002 18:46:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD19B146802; Sun, 14 Jul 2002 18:46:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a118.home.uni-hannover.de [130.75.232.118]) by moria.seul.org (Postfix) with ESMTP id F0F5C1467F7 for ; Sun, 14 Jul 2002 18:46:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02239; Mon, 15 Jul 2002 00:46:52 +0200 Message-ID: <20020715004651.06901@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 00:46:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1026670339.3d31bf03926c5@imp.free.fr>; from Cedric BAIL on Sun, Jul 14, 2002 at 08:12:19PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 14, 2002 at 08:12:19PM +0200, Cedric BAIL wrote: > > I've been thinking about the TLB before; IMHO, we need at least the > > following (assuming bits for the page offset): > > > > - virtual address (64- bits) > > - physical address (64- bits) > > - address space identifier (ASI; 8 bits was suggested) > > - supervisor access rights (RWX, 3 bits) > > - user access rights (RWX, 3 bits) > > - valid bit (indicating that the entry is valid) > > - present bit (indicating that the page is in memory) > What did you mean whith this bit ? If the bit is set, the page is mapped to physical ram. If it is cleared, a page fault occurs. > > - dirty bit (indicating that the page has been written to) > Same question. It's used for memory management inside the OS. If a page is dirty, it must be written back to permanent storage; if it's not, it can be simply discarded to make room for something else. > > - used bit (indicating that the page has been accessed) > Why not a counter ? I currently don't see how the OS can make it's decision > about how to remove a TLB entry if TLB is full. A counter would be more expensive (and would take more bits). The OS will have to scan (and reset) the `used' bits on a regular basis (e.g. inside a (slow) timer interrupt) and record the entries that have been used. The entry that has been used least recently can be replaced. > > The latter can be used to implement an LRU algorithm. > > > That is, we need 128+2*-18 bits. If an entry shall fit into 128 bits, > > must be at least 9 (i.e. a page must have at least 512 bytes). > > With 4K pages, we will have 6 bits left. Some (or all) of them may be > > used to indicate the page size. > That's a really nice idea in fact. But what did this bit mean, are they > number of Ko for a page, or predefined size page ? Anything you like. I'd say: pagesize = 4K << sizebits; but that is my personal opinion. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 00:51:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1p-0003dk-00 for ; Mon, 15 Jul 2002 01:43:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:49 +0200 (CEST) Received: (qmail 31380 invoked by uid 0); 14 Jul 2002 22:57:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 14 Jul 2002 22:57:32 -0000 Received: by moria.seul.org (Postfix) id 839C01467FA; Sun, 14 Jul 2002 18:57:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7201D146806; Sun, 14 Jul 2002 18:57:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 25CED1467FA for ; Sun, 14 Jul 2002 18:57:31 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB28C00022D22 for f-cpu@seul.org; Mon, 15 Jul 2002 00:57:30 +0200 Message-ID: <000c01c22b89$9fa85bc0$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <000301c22b6a$e309c030$5e250e50@hli> <1026681291.3d31e9cb87570@imp.free.fr> Subject: Re: [f-cpu] TLB design Date: Mon, 15 Jul 2002 00:51:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Sunday, July 14, 2002 11:14 PM Subject: Re: [f-cpu] TLB design > > Present bit is absolutely necessary for HW tlb, it is to say that entry > > is not a valid mapping and help us to raise an exception to fix it. > > For my point of view you valid page or not, normally you only have entry > in the TLB that are corresponding to memory. So what is the difference > between this two bits ? Ok, it seems we don't have the same notion : - HW TLB, like in IA32 (Intel,AMD) : we never access or change directly a TLB entry, we just set an array of entries (valid or not) and let TLB to get managed with - SW TLB : if we access a page not in TLB, we are responsive to change TLB so we can access this page. As I already told it to you, i'm not sure that a valid bit is necessary for SW TLB. > > We use it to implement virtual memory swapping from/to mass storage. > > Ok, but that's not a clean method. The VM detect that's you need to swap, > so she select a page to swap and remove them from the virtual address space. > Then they are transfered to the disk. When the task wake up, and access > to this page you make a TLB miss, and you start to remove some other from > the virtual address space to the disk and then you put the other to the new > free space and set entry in the TLB. In HW TLB we usually use the invalid entry to store info about where the page is stored in mass storage, so the exception can retrieve quickly some info. Much more helpful than you think. I used to leave the invalid physical address so i can transform it to an index and examine the associated info to check if is active or inactive (that is content is in fact swapped on external storage)... > For me, you don't have enough entry into the TLB to say that some of them > are mapped to disk, and on rescent computer the swap are not so much use > (database program prefer to have their own save polici). It is why i'm unsure about the necessity for this bit with a SW TLB. > > > > - dirty bit (indicating that the page has been written to) > > > Same question. > > > > This page was modified by someone so we could need to synchronise with > > external storage, it is absolutely necessary for virtual memory and > > file mapping. > > You mean Copy On Write technique ? No, for COW, we just need to fix it as read-only. When writing on a read-only page, we apply a COW if we know this page allows it. When you mapped a file on memory and you modify this memory and you declared the mapping so that any change of memory must be replicated in file, well you could use this bit to tell us if you must update this page in file before discarding this TLB entry for another one. Without this bit you are unable to know if this page was modified and so to update the file. Your mmap (unix) would be very unefficient because it would be forced to rewrite all the memory in the file since it would be unable to know which pages have been modified. I think that kind of bit is not as expensive to have it. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 00:56:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1p-0003dk-01 for ; Mon, 15 Jul 2002 01:43:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:49 +0200 (CEST) Received: (qmail 3210 invoked by uid 0); 14 Jul 2002 22:57:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 14 Jul 2002 22:57:33 -0000 Received: by moria.seul.org (Postfix) id ADF1C146806; Sun, 14 Jul 2002 18:57:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B82C146926; Sun, 14 Jul 2002 18:57:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id D9B14146806 for ; Sun, 14 Jul 2002 18:57:31 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB28C00022D23 for f-cpu@seul.org; Mon, 15 Jul 2002 00:57:31 +0200 Message-ID: <000d01c22b89$a0165fd0$5e250e50@hli> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Mon, 15 Jul 2002 00:56:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I am interested by this topic, so did you have any url ? I lost the URL :( ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 00:58:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1q-0003dk-00 for ; Mon, 15 Jul 2002 01:43:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:50 +0200 (CEST) Received: (qmail 16971 invoked by uid 0); 14 Jul 2002 22:58:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 14 Jul 2002 22:58:55 -0000 Received: by moria.seul.org (Postfix) id 42643146802; Sun, 14 Jul 2002 18:58:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3568B146926; Sun, 14 Jul 2002 18:58:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a118.home.uni-hannover.de [130.75.232.118]) by moria.seul.org (Postfix) with ESMTP id B0744146802 for ; Sun, 14 Jul 2002 18:58:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02272; Mon, 15 Jul 2002 00:58:51 +0200 Message-ID: <20020715005851.53737@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 00:58:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <001801c22b66$012c6360$5e250e50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001801c22b66$012c6360$5e250e50@hli>; from Christophe Avoinne on Sun, Jul 14, 2002 at 08:41:01PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 14, 2002 at 08:41:01PM +0200, Christophe Avoinne wrote: > > ----- Original Message ----- > From: "Michael Riepe" > To: > Sent: Sunday, July 14, 2002 12:54 AM > Subject: Re: [f-cpu] little feed-back from the libre softawre meeting > > > > On Sat, Jul 13, 2002 at 06:28:35PM +0200, Christophe Avoinne wrote: > > [...] > > > 1) Permission bits : rwx > > > - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and > > > "store" operations), but what could be the meaning of 'x' ? > > > - 'x' is relevant for code memory (ICACHE, instruction "load" > > > operations, but what could be the meaning of 'r' or 'w' ?. > > > It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' > bit. > > > But my question is about knowing if there would be two different TLB or > an > > > unified one ? > > > > Different TLB entries for data and code `views' of the same page of > > memory? That may introduce yet another aliasing problem. > > > > BTW: why should a page NOT be both writable and executable? > > When reading or writing a code segment, you use "load"/"store" instructions > to do so, so it is clearly a DCACHE operation even if page contains a code > When executing (that is reading with ICACHE), it is the scheduler which > reads, so it is clearly a ICACHE operation. But you can still use the same TLB entry for both operations. [...] > > In reality, processes sharing a code page will have individual TLB entries > > for it, with different VMIDs. The page is shared, the TLB entry isn't. > > > ??? > you use a SW tlb, that is ? so you'd better to avoid having several entries > pointed out on the same kernel page because of different VMID. Try to > imagine 8 actives processes, you spoiled 8 entries whereas you can just have > one entrie for any processes. If you look at the most of SW TLB they have a > bit to to tell if we want to check VMID or bypass. If, unhappily, you switch > a new process (that is a new VMID), your running kernel code would be > invalidated because of the VMID. It is stupid. That doesn't make sense. The VMID is part of the primary key for TLB lookups. If you ignore it, the keys are no longer unique - the same virtual address may pointer to several different physical pages. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 01:02:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Tt1r-0003dk-01 for ; Mon, 15 Jul 2002 01:43:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 01:43:51 +0200 (CEST) Received: (qmail 14286 invoked by uid 0); 14 Jul 2002 23:02:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 14 Jul 2002 23:02:09 -0000 Received: by moria.seul.org (Postfix) id 6608E146926; Sun, 14 Jul 2002 19:02:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B32B14692A; Sun, 14 Jul 2002 19:02:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a118.home.uni-hannover.de [130.75.232.118]) by moria.seul.org (Postfix) with ESMTP id 87BD6146926 for ; Sun, 14 Jul 2002 19:02:06 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02287; Mon, 15 Jul 2002 01:02:05 +0200 Message-ID: <20020715010205.00197@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 01:02:05 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> <000201c22b6a$e278a3c0$5e250e50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000201c22b6a$e278a3c0$5e250e50@hli>; from Christophe Avoinne on Sun, Jul 14, 2002 at 08:48:44PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 14, 2002 at 08:48:44PM +0200, Christophe Avoinne wrote: > Seriously, > > 'x' : executable -> ICACHE, because it is the instruction fetcher which > needs to access bytes in code page : IT NEVER WRITES !!! so 'x' is in fact a > disguised 'r' and 'w' a non-sense. > > 'r','w' : readable, writable -> DCACHE, because it is the LSU which needs to > access bytes in data page : IT NEVER EXECUTES !!! > > When you write code in page you are indeed using LSU for that purpose so you > handle its page like a data page not as a code page. Vice versa: - when the r-bit is set, the LSU may read the page. - when the w-bit is set, the LSU may write the page. - when the x-bit is set, the fetcher may read the page. It's still the same old page, though. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Jul 15 05:54:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qb-0000PQ-01 for ; Mon, 15 Jul 2002 15:25:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:05 +0200 (CEST) Received: (qmail 445 invoked by uid 0); 15 Jul 2002 03:57:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 15 Jul 2002 03:57:53 -0000 Received: by moria.seul.org (Postfix) id 5B4D01467FA; Sun, 14 Jul 2002 23:57:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C4A4146800; Sun, 14 Jul 2002 23:57:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id CD51B1467FA for ; Sun, 14 Jul 2002 23:57:49 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6F3wBs2009961 for ; Sun, 14 Jul 2002 21:58:12 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D32477F.2060407@jetnet.ab.ca> Date: Sun, 14 Jul 2002 21:54:39 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: <20020713015703.08661@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: >>Concerning rings and groups, the issue is still open, >>as several proposal and ideas are floating and careless >>design will turn F-CPU implementations into a VAX-like, >>or worse... helping SW and OS is ok, as long as we don't >>do in HW all the work. It must be also "friendly" with >>many OS approaches, so i choose the "least common denominator" >>approach. A TLB with RWX rights and VMID is the most common >>feature and it's straight-forward to understand for SW and >>HW design. I'll try to continue to speak with the OS guyz >>(linux, Hurd and *BSD) to sort this. > > > Misquoting Bill Gates: > > `Two protection levels should be enough for every OS.' > Is that with the 640 kb of memory that is more than ample for all the OS's too?! Would it also be possible to have a real time bit for processes that need to stay in memory or need that extra bit of processing power? BTW would not DDL's come under the same catagory as installable device drivers? I still can't see why only DOS really made use of that idea. ( OK OS/9 was a much better OS but fewer people have used that 6809/68000 OS). -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jul 15 10:54:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qd-0000PQ-00 for ; Mon, 15 Jul 2002 15:25:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:07 +0200 (CEST) Received: (qmail 23609 invoked by uid 0); 15 Jul 2002 08:54:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 15 Jul 2002 08:54:09 -0000 Received: by moria.seul.org (Postfix) id B2F541467E8; Mon, 15 Jul 2002 04:54:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 92D4C1467FA; Mon, 15 Jul 2002 04:54:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D14AE1467E8 for ; Mon, 15 Jul 2002 04:54:05 -0400 (EDT) Received: from localhost ([127.0.0.1]) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17U1cJ-0004nV-00 for f-cpu@seul.org; Mon, 15 Jul 2002 10:54:03 +0200 Date: Mon, 15 Jul 2002 10:54:02 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design In-Reply-To: <20020715004651.06901@thrai.stud.uni-hannover.de> Message-ID: References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <20020715004651.06901@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > - used bit (indicating that the page has been accessed) > > Why not a counter ? I currently don't see how the OS can make it's decision > > about how to remove a TLB entry if TLB is full. > > A counter would be more expensive (and would take more bits). > > The OS will have to scan (and reset) the `used' bits on a regular basis > (e.g. inside a (slow) timer interrupt) and record the entries that have > been used. The entry that has been used least recently can be replaced. Counter is not useable. It is because you often got multiple accesses in burst and this would make it overflow quicly. Rather you need to count these burst to get LFU replacement strategy which is emulated in 2.4.10 and latest BSDs. What would help and what is pain in current linux mm is timestamp of last access. But yes - it is unfortunately space expensive. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 11:20:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qf-0000PQ-00 for ; Mon, 15 Jul 2002 15:25:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:09 +0200 (CEST) Received: (qmail 2793 invoked by uid 0); 15 Jul 2002 09:22:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 15 Jul 2002 09:22:16 -0000 Received: by moria.seul.org (Postfix) id 35BC41467E8; Mon, 15 Jul 2002 05:22:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 12C041467FA; Mon, 15 Jul 2002 05:22:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 8BFEB1467E8 for ; Mon, 15 Jul 2002 05:22:13 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB60900028A46 for f-cpu@seul.org; Mon, 15 Jul 2002 11:22:12 +0200 Message-ID: <001401c22be0$e349d2d0$5e250e50@hli> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Mon, 15 Jul 2002 11:20:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > you use a SW tlb, that is ? so you'd better to avoid having several entries > > pointed out on the same kernel page because of different VMID. Try to > > imagine 8 actives processes, you spoiled 8 entries whereas you can just have > > one entrie for any processes. If you look at the most of SW TLB they have a > > bit to to tell if we want to check VMID or bypass. If, unhappily, you switch > > a new process (that is a new VMID), your running kernel code would be > > invalidated because of the VMID. It is stupid. > > That doesn't make sense. The VMID is part of the primary key for TLB > lookups. If you ignore it, the keys are no longer unique - the same > virtual address may pointer to several different physical pages. Nope, without the VMID, one virtual address can point only to a unique physical page. The programmer would be an idiot if he/she tries to put a different physical page with an active VMID (which interest to do so since the purpose of using global page is to see it whatever the virtual address space is ?). When not using VMID, it is for sharing the same page (physical address) in the same virtual address for all processes without exception : virtual and physical kernel pages are the same for all the processes, so what is the problem ? Sorry, but nearly all the SW TLB I saw in most modern CPU has the ability to check or not the actual ASID in the entry (usual name, Address Space ID) with the current ASID (whenever you switch a process with a different address space, you must change the current ASID). When the global bit is set, you instruct the TLB entry to go along with since it must be considered as a unique valid virtual to physical address mapping whatever the ASID is (kernel page must be in this category). When this bit is unset, you instruct the TLB entry to validate the translation only if the ASID of TLB entry matchs the current ASID (your XOR operation). Ok, now, just imagine that case : Scheduler Timer (preemptive task-switching) expires, an interrupt is raised : - enter kernel code (with ASID:A for process A). - elect process B with a different ASID:B. - switch task contest - switch the current ASID:A for ASID:B --> * BANG * What happens ? * TLB has no entry for our kernel page (contains the code where we switched the current ASID) with VMID:B, we raise an exception, but our exception must also run in another kernel page which is not in TLB :/ It is clear that not only ASID is problematic but even without ASID. If we had a HW TLB (that is, we have a full array of valid or invalid page entries which TLB can get managed with), there is no problem, since TLB knows where to look for the translation (example, IA32 MMU/TLB). For SW TLB, we have no way to tell it where to look the translation because it is our exception which is in charge. So, your exception need to run without TLB (that is with physical addresses rather than virtual addresses). Solutions : * TLB has no entry for our kernel page (contains the code where we switched the current ASID) with VMID:B, we raise an exception in a physical address space. TLB will have two entries with the same virtual and physical address but with VMID:A and VMID:B, what a waste ! (I'm speaking about two pages but it could be more : the fact is that you would have much more cache misses because of possible excessive discarding entries for kernel pages with different VMID). * kernel code is always running in physical address space (never using TLB, as suggested by Whigee) Ok, but what is the point to have supervisor/user bit ????? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 11:32:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qg-0000PQ-00 for ; Mon, 15 Jul 2002 15:25:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:10 +0200 (CEST) Received: (qmail 31515 invoked by uid 0); 15 Jul 2002 09:34:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 15 Jul 2002 09:34:20 -0000 Received: by moria.seul.org (Postfix) id E9CD41467E8; Mon, 15 Jul 2002 05:34:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B74071467FA; Mon, 15 Jul 2002 05:34:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 5BB3A1467E8 for ; Mon, 15 Jul 2002 05:34:17 -0400 (EDT) Received: from hli (80.14.37.94) by smtp.laposte.net (6.0.053) id 3D2EB3A200052C79 for f-cpu@seul.org; Mon, 15 Jul 2002 11:34:16 +0200 Message-ID: <000201c22be2$92cd8160$5e250e50@hli> From: "Christophe Avoinne" To: References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <20020715004651.06901@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] TLB design Date: Mon, 15 Jul 2002 11:32:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Martin Devera" To: Sent: Monday, July 15, 2002 10:54 AM Subject: Re: [f-cpu] TLB design > > > > - used bit (indicating that the page has been accessed) > > > Why not a counter ? I currently don't see how the OS can make it's decision > > > about how to remove a TLB entry if TLB is full. > > > > A counter would be more expensive (and would take more bits). > > > > The OS will have to scan (and reset) the `used' bits on a regular basis > > (e.g. inside a (slow) timer interrupt) and record the entries that have > > been used. The entry that has been used least recently can be replaced. > > Counter is not useable. It is because you often got multiple accesses > in burst and this would make it overflow quicly. Rather you need to > count these burst to get LFU replacement strategy which is emulated > in 2.4.10 and latest BSDs. > What would help and what is pain in current linux mm is timestamp of > last access. But yes - it is unfortunately space expensive. > devik Oh well i supose we can have a saturate counter ? no, i'm joking :) Usually a SW TLB raises an exception when a miss cache occurs, so we can timestamped the page discarded (linux for example have a info block per physical page) and use it when a slow timer is walking the info blocks to lookup for a ideal candidate (timestamp least recent I think). I suppose of course that there is much more physical pages than entries in TLB. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From art1@it-netservice.de Mon Jul 15 10:22:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qh-0000PQ-00 for ; Mon, 15 Jul 2002 15:25:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:11 +0200 (CEST) Received: (qmail 24507 invoked by uid 0); 15 Jul 2002 10:56:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 15 Jul 2002 10:56:30 -0000 Received: by moria.seul.org (Postfix) id 550F41467E8; Mon, 15 Jul 2002 06:56:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 262AE1467FA; Mon, 15 Jul 2002 06:56:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from host-2.server.itns.de (host-2.server.itns.de [213.179.64.8]) by moria.seul.org (Postfix) with ESMTP id 09F711467E8 for ; Mon, 15 Jul 2002 06:56:27 -0400 (EDT) Received: from art1.none.de (core134-b159.dialo.tiscali.de [62.246.134.159]) by host-2.server.itns.de (8.11.0/8.11.0) with ESMTP id g6FAuTI26988 for ; Mon, 15 Jul 2002 12:56:29 +0200 X-Authentication-Warning: host-2.server.itns.de: Host core134-b159.dialo.tiscali.de [62.246.134.159] claimed to be art1.none.de Received: from art1 (helo=localhost) by art1.none.de with local-esmtp (Exim 3.35 #1 (Debian)) id 17U18J-0001hh-00 for ; Mon, 15 Jul 2002 10:23:03 +0200 Date: Mon, 15 Jul 2002 10:22:59 +0200 (CEST) From: Andreas Romeyke To: f-cpu@seul.org Subject: Pagesize, was Re: [f-cpu] TLB design In-Reply-To: <20020715004651.06901@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Mon, 15 Jul 2002, Michael Riepe wrote: > > > With 4K pages, we will have 6 bits left. Some (or all) of them may be > > > used to indicate the page size. > > That's a really nice idea in fact. But what did this bit mean, are they > > number of Ko for a page, or predefined size page ? > > Anything you like. I'd say: pagesize = 4K << sizebits; but that is my > personal opinion. Why not full/more configurable? Is there any problem with a bootstrap-code for adjusting pagesize? IMHO the CPU should be programmable as it can, because there will be different tasks to be handled. Bye Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE9MoZmClxplZklbgERAvg/AJ9fa7hiSaqWC8xim5aOCt0Kw4IL0ACfUZCI 93kMmHD504chdJTXfqqDwpI= =7KTZ -----END PGP SIGNATURE----- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jul 15 14:00:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17U5qh-0000PQ-01 for ; Mon, 15 Jul 2002 15:25:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 15:25:11 +0200 (CEST) Received: (qmail 22380 invoked by uid 0); 15 Jul 2002 12:00:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 15 Jul 2002 12:00:57 -0000 Received: by moria.seul.org (Postfix) id 959AF1467F7; Mon, 15 Jul 2002 08:00:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 67C2C1467FF; Mon, 15 Jul 2002 08:00:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 015641467F7 for ; Mon, 15 Jul 2002 08:00:52 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207151200.29e8; Mon, 15 Jul 2002 12:00:41 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Rep:Re: [f-cpu] little feed-back from the libre softawre meeting From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2002 12:00:41 GMT Message-id: <200207151200.29e8@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Et bien ! You're blown my mail box ! I) Page size >From my last talk with Neal (the guy who port L4 to the Hurd= and try to design a new VM for it), it appears that he's needs for page= size are : - small for passing message, in that case increasing the pag= e size doesn't decrease the number of the page because we allways h= ave at least one page per message. - one medium for typical code and data. - one big for frame buffer and kernel page - one hudge for data base small could be 4 Kb.=20 Neal propose at the beginning 64 kb for medium but if you do= "top" on you're linux bow you will see very few program using 64 kb o= f memory (i beleive that one program have at least 3 pages). So maybe 16= kb or even 8 kb could be enought. Most of the time current OS use only = a single size for paging system, so this size must be carefully choos= en. If it's too big they will use the smallest size. big are 4 Mo for like for intel big pages. hudge could be 256 Mo, it's for data base system that used h= udge amount of memory and use it's own memory allocator (so it will ask = almost all the system's memory at start and then manage it).=20 Page size are important. Many object are page aligned. for e= xample : library and files. If the page are too big, copy-on-write te= chnique became less efficient.( on the average there is more data to= copy than needed by smaller sized page). The otherdraw back of many different size is that the OS mus= t find "big and aligned hole" in memory to give such pages to a program = and that could be hard !(having many sized from 4kb could help to red= uice such problem) It could be very important to have 2 tlb (one for data and o= ne for code), it's quite unusual to mix the 2 kind of pages. So you= could save one port to the tlb or double the bandwith of the all system= . (it could be very important if we keep the L1 cache in the physical ad= dress space and check at allmost every memory access the tlb) If we could have how many size we want for page, it could be= great but i can't see how look such tlb. --- II) kernel space I have always read that kernel run in the adress space of th= e running process otherwise it became very tricky to pass data from us= er space to kernel space. And it became very hard to avoid copy. x86 use a global bit because it didn't used asid number, i t= hink. =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 15 17:58:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqD-0000Ft-00 for ; Mon, 15 Jul 2002 21:49:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:05 +0200 (CEST) Received: (qmail 10653 invoked by uid 0); 15 Jul 2002 15:58:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 15 Jul 2002 15:58:40 -0000 Received: by moria.seul.org (Postfix) id 44536146806; Mon, 15 Jul 2002 11:58:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F6F1146812; Mon, 15 Jul 2002 11:58:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 9807A146806 for ; Mon, 15 Jul 2002 11:58:38 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 21BD11819E for ; Mon, 15 Jul 2002 17:58:38 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id F06C864123; Mon, 15 Jul 2002 17:58:37 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026748717.3d32f12db0bfe@imp.free.fr> Date: Mon, 15 Jul 2002 17:58:37 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <001801c22b66$012c6360$5e250e50@hli> <20020715005851.53737@thrai.stud.uni-hannover.de> <001401c22be0$e349d2d0$5e250e50@hli> In-Reply-To: <001401c22be0$e349d2d0$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > you use a SW tlb, that is ? so you'd better to avoid having several > > > entries pointed out on the same kernel page because of different VMID. > > > Try to imagine 8 actives processes, you spoiled 8 entries whereas you can > > > just have one entrie for any processes. If you look at the most of SW TLB > > > they have a bit to to tell if we want to check VMID or bypass. If, > > > unhappily, you switch a new process (that is a new VMID), your running > > > kernel code would be invalidated because of the VMID. It is stupid. > > That doesn't make sense. The VMID is part of the primary key for TLB > > lookups. If you ignore it, the keys are no longer unique - the same > > virtual address may pointer to several different physical pages. > Nope, without the VMID, one virtual address can point only to a unique > physical page. The programmer would be an idiot if he/she tries to put > a different physical page with an active VMID (which interest to do so > since the purpose of using global page is to see it whatever the virtual > address space is ?). When not using VMID, it is for sharing the same page > (physical address) in the same virtual address for all processes without > exception : > virtual and physical kernel pages are the same for all the processes, > so what is the problem ? > Sorry, but nearly all the SW TLB I saw in most modern CPU has the ability to > check or not the actual ASID in the entry (usual name, Address Space ID) > with the current ASID (whenever you switch a process with a different > address space, you must change the current ASID). When the global bit is > set, you instruct the TLB entry to go along with since it must be considered > as a unique valid virtual to physical address mapping whatever the ASID is > (kernel page must be in this category). When this bit is unset, you instruct > the TLB entry to validate the translation only if the ASID of TLB entry > matchs the current ASID (your XOR operation). > Ok, now, just imagine that case : > Scheduler Timer (preemptive task-switching) expires, an interrupt is raised: > - enter kernel code (with ASID:A for process A). > - elect process B with a different ASID:B. > - switch task contest > - switch the current ASID:A for ASID:B --> * BANG * > What happens ? If you replace an older ASID by an new one, it's easy you replace the old entry from the old task, by new entry from the new task. If you didn't replace an new task, you look in the list of current task and TLB entry the one that it's too old and never used, and you put your new entry. It's really a stupid algorithm, but it explain how I see what append. > * TLB has no entry for our kernel page (contains the code where we switched > the current ASID) with VMID:B, we raise an exception, but our exception must > also run in another kernel page which is not in TLB :/ For me exception are running with an unactivated TLB, if you need the TLB, active it, it's all. > It is clear that not only ASID is problematic but even without ASID. If we > had a HW TLB (that is, we have a full array of valid or invalid page entries > which TLB can get managed with), there is no problem, since TLB knows where > to look for the translation (example, IA32 MMU/TLB). > For SW TLB, we have no way to tell it where to look the translation because > it is our exception which is in charge. > So, your exception need to run without TLB (that is with physical > addresses rather than virtual addresses). > Solutions : > * TLB has no entry for our kernel page (contains the code where we > switched the current ASID) with VMID:B, we raise an exception in a physical > address space. > TLB will have two entries with the same virtual and physical address > but with VMID:A and VMID:B, what a waste ! (I'm speaking about two pages but > it could be more : the fact is that you would have much more cache misses > because of possible excessive discarding entries for kernel pages with > different VMID). Not a wast, you can have two different type of protection bits. This is useful, and you software can do more thing to protect form problem. > * kernel code is always running in physical address space (never using > TLB, as suggested by Whigee) > Ok, but what is the point to have supervisor/user bit ????? I think I have the same question. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 15 18:07:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqF-0000Ft-00 for ; Mon, 15 Jul 2002 21:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:07 +0200 (CEST) Received: (qmail 29452 invoked by uid 0); 15 Jul 2002 16:08:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 15 Jul 2002 16:08:00 -0000 Received: by moria.seul.org (Postfix) id 4926B146806; Mon, 15 Jul 2002 12:07:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2246A146812; Mon, 15 Jul 2002 12:07:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id BC40E146806 for ; Mon, 15 Jul 2002 12:07:58 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix1-2.free.fr (Postfix) with ESMTP id 15D5EAB120 for ; Mon, 15 Jul 2002 18:07:57 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id E6DC68C103; Mon, 15 Jul 2002 18:07:56 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Message-ID: <1026749276.3d32f35cd589d@imp.free.fr> Date: Mon, 15 Jul 2002 18:07:56 +0200 (MEST) From: Cedric BAIL References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> <000201c22b6a$e278a3c0$5e250e50@hli> <1026682058.3d31eccaa2313@imp.free.fr> <002b01c22b84$edceddb0$5e250e50@hli> In-Reply-To: <002b01c22b84$edceddb0$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N En réponse à Christophe Avoinne : > I'm discouraged... your diagram about F-CPU is speaking about ICACHE > and DCACHE, am I wrong ? No. > They are separate !!!! I'm explaining why it is a nonsense to speak > about 'r','w' for code page and 'x' for data page, especially if you need a > seperate TLB for ICACHE and DCACHE. Of course, if you used a unified TLB > for ICACHE and DCACHE, well we can can have entries with 'r', 'w', 'x'. > 'r','w' would be relevant accessing DCACHE and 'x' for accessing ICACHE. I now understand you, I was thinking about an unified TLB for ICACHE and DCACHE. But it can be a question. Personnally, I think that they must unified, so that the software can allocate the good ratio of entry for code and for data. > > > Seriously, > > > > > 'x' : executable -> ICACHE, because it is the instruction fetcher > > > which needs to access bytes in code page : IT NEVER WRITES !!! so 'x' is > > > in fact a disguised 'r' and 'w' a non-sense. > > If I understand what you say, we can't write "automodify" code. > Oh my god !!!!! i turn into french explanation : I think I know I understand your question, it isn't about the rwx bits, but more on the unified TLB for data and code, now I am right ? > > > 'r','w' : readable, writable -> DCACHE, because it is the LSU which > > > needs to access bytes in data page : IT NEVER EXECUTES !!! > > Why not, we must not block this possibility. Currently the TLB is placed before any access to memory. You can't acces any cache without asking the TLB. (I am not sure about the cache in LSU and fetcher). >From what Yann say, I understand that we have only one unified TLB. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 15 18:19:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqF-0000Ft-01 for ; Mon, 15 Jul 2002 21:49:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:07 +0200 (CEST) Received: (qmail 15714 invoked by uid 0); 15 Jul 2002 16:16:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 15 Jul 2002 16:16:18 -0000 Received: by moria.seul.org (Postfix) id 66B83146806; Mon, 15 Jul 2002 12:16:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45F7B146812; Mon, 15 Jul 2002 12:16:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id C66CD146806 for ; Mon, 15 Jul 2002 12:16:15 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix3-2.free.fr (Postfix) with ESMTP id 2EB7E1800F for ; Mon, 15 Jul 2002 18:16:15 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 38E72FC67; Mon, 15 Jul 2002 18:19:59 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design Message-ID: <1026749999.3d32f62f1498c@imp.free.fr> Date: Mon, 15 Jul 2002 18:19:59 +0200 (MEST) From: Cedric BAIL References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <000301c22b6a$e309c030$5e250e50@hli> <1026681291.3d31e9cb87570@imp.free.fr> <000c01c22b89$9fa85bc0$5e250e50@hli> In-Reply-To: <000c01c22b89$9fa85bc0$5e250e50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > In HW TLB we usually use the invalid entry to store info about where > the page is stored in mass storage, so the exception can retrieve quickly > some info. Much more helpful than you think. I used to leave the invalid > physical address so i can transform it to an index and examine the associated > info to check if is active or inactive (that is content is in fact swapped on > external storage)... > > For me, you don't have enough entry into the TLB to say that some of them > > are mapped to disk, and on rescent computer the swap are not so much use > > (database program prefer to have their own save polici). > It is why i'm unsure about the necessity for this bit with a SW TLB. I think it clearly an overkill, because you really need space in your TLB, and by puting TLB entry that "map to disk" you loose entry in TLB and complexify your TLB miss handler. > No, for COW, we just need to fix it as read-only. When writing on a > read-only page, we apply a COW if we know this page allows it. > > When you mapped a file on memory and you modify this memory and you > declared the mapping so that any change of memory must be replicated in file, > well you could use this bit to tell us if you must update this page in file > before discarding this TLB entry for another one. Without this bit you are > unable to know if this page was modified and so to update the file. Your > mmap (unix) would be very unefficient because it would be forced to rewrite > all the memory in the file since it would be unable to know which pages > have been modified. > I think that kind of bit is not as expensive to have it. Ok, I now understand why you want this bit, and it can be useful. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 14:46:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqG-0000Ft-00 for ; Mon, 15 Jul 2002 21:49:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:08 +0200 (CEST) Received: (qmail 10922 invoked by uid 0); 15 Jul 2002 16:20:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 15 Jul 2002 16:20:12 -0000 Received: by moria.seul.org (Postfix) id 8C554146806; Mon, 15 Jul 2002 12:20:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5689D146811; Mon, 15 Jul 2002 12:20:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a150.home.uni-hannover.de [130.75.232.150]) by moria.seul.org (Postfix) with ESMTP id 16EEF146806 for ; Mon, 15 Jul 2002 12:20:06 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00648; Mon, 15 Jul 2002 14:46:04 +0200 Message-ID: <20020715144604.45123@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 14:46:04 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] little feed-back from the libre softawre meeting References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <001801c22b66$012c6360$5e250e50@hli> <20020715005851.53737@thrai.stud.uni-hannover.de> <001401c22be0$e349d2d0$5e250e50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001401c22be0$e349d2d0$5e250e50@hli>; from Christophe Avoinne on Mon, Jul 15, 2002 at 11:20:39AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 15, 2002 at 11:20:39AM +0200, Christophe Avoinne wrote: > > > > you use a SW tlb, that is ? so you'd better to avoid having several > entries > > > pointed out on the same kernel page because of different VMID. Try to > > > imagine 8 actives processes, you spoiled 8 entries whereas you can just > have > > > one entrie for any processes. If you look at the most of SW TLB they > have a > > > bit to to tell if we want to check VMID or bypass. If, unhappily, you > switch > > > a new process (that is a new VMID), your running kernel code would be > > > invalidated because of the VMID. It is stupid. > > > > That doesn't make sense. The VMID is part of the primary key for TLB > > lookups. If you ignore it, the keys are no longer unique - the same > > virtual address may pointer to several different physical pages. > > Nope, without the VMID, one virtual address can point only to a unique > physical page. The programmer would be an idiot if he/she tries to put a > different physical page with an active VMID (which interest to do so since > the purpose of using global page is to see it whatever the virtual address > space is ?). When not using VMID, it is for sharing the same page (physical > address) in the same virtual address for all processes without exception : > virtual and physical kernel pages are the same for all the processes, so > what is the problem ? I'm not sure if it will work that way. > Sorry, but nearly all the SW TLB I saw in most modern CPU has the ability to > check or not the actual ASID in the entry (usual name, Address Space ID) > with the current ASID (whenever you switch a process with a different > address space, you must change the current ASID). When the global bit is > set, you instruct the TLB entry to go along with since it must be considered > as a unique valid virtual to physical address mapping whatever the ASID is > (kernel page must be in this category). When this bit is unset, you instruct > the TLB entry to validate the translation only if the ASID of TLB entry > matchs the current ASID (your XOR operation). Should not be hard to implement. We can drop the `present' bit (it seems to be superfluous) and add a `global' bit instead. If necessary, a `negative' page mapping can still be performed by an entry with zero access rights. > Ok, now, just imagine that case : > > Scheduler Timer (preemptive task-switching) expires, an interrupt is raised > : > - enter kernel code (with ASID:A for process A). > - elect process B with a different ASID:B. > - switch task contest > - switch the current ASID:A for ASID:B --> * BANG * > > What happens ? > > * TLB has no entry for our kernel page (contains the code where we switched > the current ASID) with VMID:B, we raise an exception, but our exception must > also run in another kernel page which is not in TLB :/ Without a global bit, the kernel must provide TLB entries with the VMID of the new task while the task switch is in progress. This can probably be done step-by-step, that is, only one additional TLB entry is required: add entry for current code page (ASID:B) switch to ASID:B change entries for other kernel pages to ASID:B remove old code page entry > It is clear that not only ASID is problematic but even without ASID. If we > had a HW TLB (that is, we have a full array of valid or invalid page entries > which TLB can get managed with), there is no problem, since TLB knows where > to look for the translation (example, IA32 MMU/TLB). > > For SW TLB, we have no way to tell it where to look the translation because > it is our exception which is in charge. > > So, your exception need to run without TLB (that is with physical addresses > rather than virtual addresses). > > Solutions : > > * TLB has no entry for our kernel page (contains the code where we switched > the current ASID) with VMID:B, we raise an exception in a physical address > space. > > TLB will have two entries with the same virtual and physical address but > with VMID:A and VMID:B, what a waste ! (I'm speaking about two pages but it > could be more : the fact is that you would have much more cache misses > because of possible excessive discarding entries for kernel pages with > different VMID). Depends on the cache. > * kernel code is always running in physical address space (never using TLB, > as suggested by Whigee) That would be a choice for an embedded system but not for a real OS. > Ok, but what is the point to have supervisor/user bit ????? I don't remember such a bit in my TLB proposal. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 13:57:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqH-0000Ft-00 for ; Mon, 15 Jul 2002 21:49:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:09 +0200 (CEST) Received: (qmail 13801 invoked by uid 0); 15 Jul 2002 16:20:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 15 Jul 2002 16:20:13 -0000 Received: by moria.seul.org (Postfix) id 9BB47146812; Mon, 15 Jul 2002 12:20:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 77213146926; Mon, 15 Jul 2002 12:20:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a150.home.uni-hannover.de [130.75.232.150]) by moria.seul.org (Postfix) with ESMTP id A72D2146812 for ; Mon, 15 Jul 2002 12:20:08 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00528; Mon, 15 Jul 2002 13:57:02 +0200 Message-ID: <20020715135702.02681@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 13:57:02 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <20020715004651.06901@thrai.stud.uni-hannover.de> <000201c22be2$92cd8160$5e250e50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <000201c22be2$92cd8160$5e250e50@hli>; from Christophe Avoinne on Mon, Jul 15, 2002 at 11:32:26AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 15, 2002 at 11:32:26AM +0200, Christophe Avoinne wrote: [...] > Oh well i supose we can have a saturate counter ? no, i'm joking :) A single `used' bit *is* a saturated counter (counts up to 1). > Usually a SW TLB raises an exception when a miss cache occurs, so we can > timestamped the page discarded (linux for example have a info block per > physical page) and use it when a slow timer is walking the info blocks to > lookup for a ideal candidate (timestamp least recent I think). I suppose of > course that there is much more physical pages than entries in TLB. Cache miss? You mean TLB miss, don't you? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 15 18:31:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqI-0000Ft-00 for ; Mon, 15 Jul 2002 21:49:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:10 +0200 (CEST) Received: (qmail 13546 invoked by uid 0); 15 Jul 2002 16:34:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 15 Jul 2002 16:34:20 -0000 Received: by moria.seul.org (Postfix) id A3792146806; Mon, 15 Jul 2002 12:34:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84451146844; Mon, 15 Jul 2002 12:34:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 0B859146806 for ; Mon, 15 Jul 2002 12:34:19 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id AB2DA5FE9E for ; Mon, 15 Jul 2002 18:31:51 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 8B47A873B9; Mon, 15 Jul 2002 18:31:51 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design Message-ID: <1026750711.3d32f8f778907@imp.free.fr> Date: Mon, 15 Jul 2002 18:31:51 +0200 (MEST) From: Cedric BAIL References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <20020715004651.06901@thrai.stud.uni-hannover.de> In-Reply-To: <20020715004651.06901@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > I've been thinking about the TLB before; IMHO, we need at least the > > > following (assuming bits for the page offset): > > > > > > - virtual address (64- bits) > > > - physical address (64- bits) > > > - address space identifier (ASI; 8 bits was suggested) > > > - supervisor access rights (RWX, 3 bits) > > > - user access rights (RWX, 3 bits) > > > - valid bit (indicating that the entry is valid) > > > - present bit (indicating that the page is in memory) > > What did you mean whith this bit ? > > If the bit is set, the page is mapped to physical ram. If it is > cleared, a page fault occurs. So what is the difference with valid bit. I think you have the same idea as cristophe for this two bits. From my point of view only one is useful, because when you don't map to physical ram you will always trap and look where to put you new entry, same as with the valid bit. > > > - dirty bit (indicating that the page has been written to) > > Same question. > > It's used for memory management inside the OS. If a page is dirty, it > must be written back to permanent storage; if it's not, it can be > simply discarded to make room for something else. Ok, I now see how to use it. > > > - used bit (indicating that the page has been accessed) > > Why not a counter ? I currently don't see how the OS can make it's decision > > about how to remove a TLB entry if TLB is full. > A counter would be more expensive (and would take more bits). > The OS will have to scan (and reset) the `used' bits on a regular basis > (e.g. inside a (slow) timer interrupt) and record the entries that have > been used. The entry that has been used least recently can be replaced. In fact, it was only a dream ;-) Previously I wanted a lot of TLB page size and you give an answer to me, so I ask more ;-) > > > The latter can be used to implement an LRU algorithm. > > > That is, we need 128+2*-18 bits. If an entry shall fit into 128 bits, > > > must be at least 9 (i.e. a page must have at least 512 bytes). > > > With 4K pages, we will have 6 bits left. Some (or all) of them may be > > > used to indicate the page size. > > That's a really nice idea in fact. But what did this bit mean, are they > > number of Ko for a page, or predefined size page ? > Anything you like. I'd say: pagesize = 4K << sizebits; but that is my > personal opinion. You mean that I can do a page of : (4 << 64) K ? I think that with your system we can be ready for the future ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jul 15 19:05:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UBqK-0000Ft-01 for ; Mon, 15 Jul 2002 21:49:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Mon, 15 Jul 2002 21:49:12 +0200 (CEST) Received: (qmail 12561 invoked by uid 0); 15 Jul 2002 17:05:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 15 Jul 2002 17:05:32 -0000 Received: by moria.seul.org (Postfix) id 78C57146812; Mon, 15 Jul 2002 13:05:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EE5A146926; Mon, 15 Jul 2002 13:05:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 1A2EA146812 for ; Mon, 15 Jul 2002 13:05:31 -0400 (EDT) Received: from localhost ([127.0.0.1]) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17U9Ht-0002H8-00 for f-cpu@seul.org; Mon, 15 Jul 2002 19:05:29 +0200 Date: Mon, 15 Jul 2002 19:05:27 +0200 (CEST) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] TLB design In-Reply-To: <000201c22be2$92cd8160$5e250e50@hli> Message-ID: References: <20020713223404.57058@thrai.stud.uni-hannover.de> <1026670339.3d31bf03926c5@imp.free.fr> <20020715004651.06901@thrai.stud.uni-hannover.de> <000201c22be2$92cd8160$5e250e50@hli> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Counter is not useable. It is because you often got multiple accesses > > in burst and this would make it overflow quicly. Rather you need to > > count these burst to get LFU replacement strategy which is emulated > > in 2.4.10 and latest BSDs. > > What would help and what is pain in current linux mm is timestamp of > > last access. But yes - it is unfortunately space expensive. > > devik > > Oh well i supose we can have a saturate counter ? no, i'm joking :) > > Usually a SW TLB raises an exception when a miss cache occurs, so we can > timestamped the page discarded (linux for example have a info block per > physical page) and use it when a slow timer is walking the info blocks to > lookup for a ideal candidate (timestamp least recent I think). I suppose of > course that there is much more physical pages than entries in TLB. ehh .. I've forgotten .. fcpu has SW TLB .. I spent too many time with x86 thing ;-) Forget my note. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 23:26:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKcz-0006IE-01 for ; Tue, 16 Jul 2002 07:12:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:01 +0200 (CEST) Received: (qmail 11917 invoked by uid 0); 15 Jul 2002 21:27:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 15 Jul 2002 21:27:53 -0000 Received: by moria.seul.org (Postfix) id BD891146812; Mon, 15 Jul 2002 17:27:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8CFD3146926; Mon, 15 Jul 2002 17:27:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 3BB89146812 for ; Mon, 15 Jul 2002 17:27:51 -0400 (EDT) Received: from hli (80.14.37.190) by smtp.laposte.net (6.0.053) id 3D2EB3A20005F702 for f-cpu@seul.org; Mon, 15 Jul 2002 23:27:50 +0200 Message-ID: <001b01c22c46$40c99200$be250e50@hli> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] little feed-back from the libre softawre meeting Date: Mon, 15 Jul 2002 23:26:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Ok, but what is the point to have supervisor/user bit ????? > > I don't remember such a bit in my TLB proposal. > Sorry, I was spoken about 'sr','sw','sx' and 'ur','uw', 'ux' in fact. The remark still remains. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 15 18:42:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKd0-0006IE-00 for ; Tue, 16 Jul 2002 07:12:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:02 +0200 (CEST) Received: (qmail 6514 invoked by uid 0); 15 Jul 2002 21:28:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 15 Jul 2002 21:28:38 -0000 Received: by moria.seul.org (Postfix) id F3D4D146812; Mon, 15 Jul 2002 17:28:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCE2E14692A; Mon, 15 Jul 2002 17:28:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a171.home.uni-hannover.de [130.75.232.171]) by moria.seul.org (Postfix) with ESMTP id BE13B146812 for ; Mon, 15 Jul 2002 17:28:35 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01420; Mon, 15 Jul 2002 18:42:50 +0200 Message-ID: <20020715184250.14849@thrai.stud.uni-hannover.de> Date: Mon, 15 Jul 2002 18:42:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: [f-cpu] little feed-back from the libre softawre meeting References: <200207151200.29e8@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207151200.29e8@th00.opsion.fr>; from Nicolas Boulay on Mon, Jul 15, 2002 at 12:00:41PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 15, 2002 at 12:00:41PM +0000, Nicolas Boulay wrote: > Et bien ! You're blown my mail box ! Oh, sorry ;) > I) Page size > > >From my last talk with Neal (the guy who port L4 to the Hurd and try to > design a new VM for it), it appears that he's needs for page size are : > - small for passing message, in that case increasing the page size > doesn't decrease the number of the page because we allways have at least > one page per message. > - one medium for typical code and data. > - one big for frame buffer and kernel page > - one hudge for data base > > small could be 4 Kb. That seems to be a reasonable lower limit. > Neal propose at the beginning 64 kb for medium but if you do "top" on > you're linux bow you will see very few program using 64 kb of memory (i > beleive that one program have at least 3 pages). So maybe 16 kb or even > 8 kb could be enought. Most of the time current OS use only a single > size for paging system, so this size must be carefully choosen. > If it's too big they will use the smallest size. > > big are 4 Mo for like for intel big pages. > > hudge could be 256 Mo, it's for data base system that used hudge amount > of memory and use it's own memory allocator (so it will ask almost all > the system's memory at start and then manage it). What about programs that have larger working sets? Especially on 64-bit machines, you may have applications that use gigabytes of data and have several megabytes of code space - and I want to be prepared for such beasts. What is a 64-bit CPU good for, after all? Big stuff! > Page size are important. Many object are page aligned. for example : > library and files. If the page are too big, copy-on-write technique > became less efficient.( on the average there is more data to copy than > needed by smaller sized page). > > The otherdraw back of many different size is that the OS must find "big > and aligned hole" in memory to give such pages to a program and that > could be hard !(having many sized from 4kb could help to reduice such > problem) A buddy system allocator with power-of-two page sizes should be ok. > It could be very important to have 2 tlb (one for data and one for > code), it's quite unusual to mix the 2 kind of pages. So you could save > one port to the tlb or double the bandwith of the all system. (it could > be very important if we keep the L1 cache in the physical address space > and check at allmost every memory access the tlb) There's no need to check the TLB on every instruction fetch. The virtual->physical mapping remains valid until we leave the page or the TLB entry is changed or invalidated - and that will be rather rare if the compiler generates good code. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 15 23:29:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKd0-0006IE-01 for ; Tue, 16 Jul 2002 07:12:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:02 +0200 (CEST) Received: (qmail 507 invoked by uid 0); 15 Jul 2002 21:31:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 15 Jul 2002 21:31:11 -0000 Received: by moria.seul.org (Postfix) id 7BC6F146812; Mon, 15 Jul 2002 17:31:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FC15146926; Mon, 15 Jul 2002 17:31:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 23E8E146812 for ; Mon, 15 Jul 2002 17:31:10 -0400 (EDT) Received: from hli (80.14.37.190) by smtp.laposte.net (6.0.053) id 3D2EB3A20005F78A for f-cpu@seul.org; Mon, 15 Jul 2002 23:31:09 +0200 Message-ID: <002101c22c46$b75e5220$be250e50@hli> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] TLB design Date: Mon, 15 Jul 2002 23:29:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Oh well i supose we can have a saturate counter ? no, i'm joking :) > > A single `used' bit *is* a saturated counter (counts up to 1). > > > Usually a SW TLB raises an exception when a miss cache occurs, so we can > > timestamped the page discarded (linux for example have a info block per > > physical page) and use it when a slow timer is walking the info blocks to > > lookup for a ideal candidate (timestamp least recent I think). I suppose of > > course that there is much more physical pages than entries in TLB. > > Cache miss? You mean TLB miss, don't you? > Yes, sorry I sometimes tend to consider TLB as a special cache (the only difference is the hold data is not the content of memory but a physical address instead, but TLB works like a cache indeed). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 16 00:04:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKd3-0006IE-00 for ; Tue, 16 Jul 2002 07:12:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:05 +0200 (CEST) Received: (qmail 959 invoked by uid 0); 15 Jul 2002 21:45:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 15 Jul 2002 21:45:09 -0000 Received: by moria.seul.org (Postfix) id DA3E51467F6; Mon, 15 Jul 2002 17:45:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C0028146844; Mon, 15 Jul 2002 17:45:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 76DB51467F6 for ; Mon, 15 Jul 2002 17:45:07 -0400 (EDT) Received: from ifrance.com (vlt4-238.n.club-internet.fr [194.158.109.238]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1FECC16D7 for ; Mon, 15 Jul 2002 23:45:05 +0200 (CEST) Message-ID: <3D3346E0.686E5B60@ifrance.com> Date: Tue, 16 Jul 2002 00:04:16 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] tlb References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> <000201c22b6a$e278a3c0$5e250e50@hli> <1026682058.3d31eccaa2313@imp.free.fr> <002b01c22b84$edceddb0$5e250e50@hli> <1026749276.3d32f35cd589d@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > The otherdraw back of many different size is that the OS must find "big > and aligned hole" in memory to give such pages to a program and that > could be hard !(having many sized from 4kb could help to reduice such > problem) A buddy system allocator with power-of-two page sizes should be ok. >>> ??? a simple algorythme could be fine but with typical use there is a big risk to be very fragmented and never find such hole. Or you need to remap a lot of page. > It could be very important to have 2 tlb (one for data and one for > code), it's quite unusual to mix the 2 kind of pages. So you could save > one port to the tlb or double the bandwith of the all system. (it could > be very important if we keep the L1 cache in the physical address space > and check at allmost every memory access the tlb) There's no need to check the TLB on every instruction fetch. The virtual->physical mapping remains valid until we leave the page or the TLB entry is changed or invalidated - and that will be rather rare if the compiler generates good code. >>>> i dont understand you. If the L1 caches is on the physical address space, you always have to check the data (minus the trick with the LSU which is a kind of L0 caches in virtual space) nicO -- Michael "Tired" Riepe ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 16 00:00:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKd4-0006IE-00 for ; Tue, 16 Jul 2002 07:12:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:06 +0200 (CEST) Received: (qmail 24769 invoked by uid 0); 15 Jul 2002 22:00:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 15 Jul 2002 22:00:15 -0000 Received: by moria.seul.org (Postfix) id 07BC41467F6; Mon, 15 Jul 2002 18:00:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ED75B146844; Mon, 15 Jul 2002 18:00:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a171.home.uni-hannover.de [130.75.232.171]) by moria.seul.org (Postfix) with ESMTP id E79A91467F6 for ; Mon, 15 Jul 2002 18:00:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02570; Tue, 16 Jul 2002 00:00:09 +0200 Message-ID: <20020716000009.04278@thrai.stud.uni-hannover.de> Date: Tue, 16 Jul 2002 00:00:09 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] tlb References: <20020713015703.08661@thrai.stud.uni-hannover.de> <001201c22a8a$56b410d0$e5250e50@hli> <20020714005434.64899@thrai.stud.uni-hannover.de> <1026670191.3d31be6ff0517@imp.free.fr> <000201c22b6a$e278a3c0$5e250e50@hli> <1026682058.3d31eccaa2313@imp.free.fr> <002b01c22b84$edceddb0$5e250e50@hli> <1026749276.3d32f35cd589d@imp.free.fr> <3D3346E0.686E5B60@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D3346E0.686E5B60@ifrance.com>; from nico on Tue, Jul 16, 2002 at 12:04:16AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 16, 2002 at 12:04:16AM +0200, nico wrote: > > > The otherdraw back of many different size is that the OS must find "big > > and aligned hole" in memory to give such pages to a program and that > > could be hard !(having many sized from 4kb could help to reduice such > > problem) > > A buddy system allocator with power-of-two page sizes should be ok. > > >>> ??? a simple algorythme could be fine but with typical use there is a big risk to be very fragmented and never find such hole. Or you need to remap a lot of page. You'll *always* have that problem if you have multiple page sizes. BTW: sometimes, a little garbage collection isn't so bad :) > > It could be very important to have 2 tlb (one for data and one for > > code), it's quite unusual to mix the 2 kind of pages. So you could save > > one port to the tlb or double the bandwith of the all system. (it could > > be very important if we keep the L1 cache in the physical address space > > and check at allmost every memory access the tlb) > > There's no need to check the TLB on every instruction fetch. The > virtual->physical mapping remains valid until we leave the page or the > TLB entry is changed or invalidated - and that will be rather rare if > the compiler generates good code. > > >>>> i dont understand you. If the L1 caches is on the physical address space, you always have to check the data (minus the trick with the LSU which is a kind of L0 caches in virtual space) I'm not talking about data, I'm talking about code. Instruction fetches happen at consecutive addresses (unless there is a jump or trap), therefore you know when you will hit the end of the current page (every 1024 instructions if your code is linear and pages are 4K). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jul 16 01:30:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UKdC-0006IE-00 for ; Tue, 16 Jul 2002 07:12:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 07:12:14 +0200 (CEST) Received: (qmail 29741 invoked by uid 0); 15 Jul 2002 23:33:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 15 Jul 2002 23:33:17 -0000 Received: by moria.seul.org (Postfix) id 5A702146803; Mon, 15 Jul 2002 19:33:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4D82D146844; Mon, 15 Jul 2002 19:33:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A5B8E146803 for ; Mon, 15 Jul 2002 19:33:14 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6FNXeo0002611 for ; Mon, 15 Jul 2002 17:33:41 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D335AFD.5070506@jetnet.ab.ca> Date: Mon, 15 Jul 2002 17:30:05 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: [f-cpu] little feed-back from the libre softawre meeting References: <200207151200.29e8@th00.opsion.fr> <20020715184250.14849@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > There's no need to check the TLB on every instruction fetch. The > virtual->physical mapping remains valid until we leave the page or the > TLB entry is changed or invalidated - and that will be rather rare if > the compiler generates good code. > But need the TLB sizes be the same size for code and data? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 16 09:24:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UOvo-0000sT-00 for ; Tue, 16 Jul 2002 11:47:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 11:47:44 +0200 (CEST) Received: (qmail 23028 invoked by uid 0); 16 Jul 2002 07:24:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 16 Jul 2002 07:24:49 -0000 Received: by moria.seul.org (Postfix) id BFB2B1467FF; Tue, 16 Jul 2002 03:24:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B36E146813; Tue, 16 Jul 2002 03:24:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id A83341467FF for ; Tue, 16 Jul 2002 03:24:46 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207160724.27d3; Tue, 16 Jul 2002 07:24:39 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Rep:Re: [f-cpu] little feed-back from the libre softawre From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2002 07:24:39 GMT Message-id: <200207160724.27d3@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Good question ! I believe that tiny, large and hudge page are mostly for dat= a and medium size page for code. With an execption : the linux kernel use= a 4 Mb page to avoid miss. nicO -----Message d'origine----- De: Ben Franchuk A: f-cpu@seul.org Date: 16/07/02 Objet: Re: Rep:Rep:Re: [f-cpu] little feed-back from the lib= re softawre > There's no need to check the TLB on every instruction fetc= h. The > virtual->physical mapping remains valid until we leave the= page or the > TLB entry is changed or invalidated - and that will be rat= her rare if > the compiler generates good code. >=20 But need the TLB sizes be the same size for code and data? --=20 Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 16 10:29:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UOvo-0000sT-01 for ; Tue, 16 Jul 2002 11:47:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 11:47:44 +0200 (CEST) Received: (qmail 16116 invoked by uid 0); 16 Jul 2002 08:21:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 16 Jul 2002 08:21:09 -0000 Received: by moria.seul.org (Postfix) id 3A471146926; Tue, 16 Jul 2002 04:21:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EBB42146813; Tue, 16 Jul 2002 04:21:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CF2C3146803; Tue, 16 Jul 2002 04:21:06 -0400 (EDT) Received: from f-cpu.org (kdl4-18.n.club-internet.fr [213.44.3.18]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 4CBE916BB; Tue, 16 Jul 2002 10:20:59 +0200 (CEST) Message-ID: <3D33D97D.65A4E60E@f-cpu.org> Date: Tue, 16 Jul 2002 10:29:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] LSM2002 : Proceedings for the F-CPU topic Content-Type: multipart/mixed; boundary="------------61F25B9F66A7184CF0A39EEE" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------61F25B9F66A7184CF0A39EEE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, i am back from Bordeaux. Here are some notes about this meeting, other material will be provided later for the proceedings' CDROM. Despite some technical and social problem (seems i attracted them all), there are some interesting points : - the schedule collision between the F-CPU conference and this of RMS was an issue for a number of people. What started as a pure laziness and coincidence has reached some unexpected (trolling) proportions. The fact that they had to make an exclusive choice creates an artificial conflict, at least in their minds. I promise i won't give trolls a chance, if there is a next time. The F-CPU presentation conference went well and some interested people showed up, despite the relatively few people in the room. - One reason i chose the 11th was because some non-parisian people wanted to come that day from the region of Toulouse. So we better had to choose one single day so as many F-CPU team members could be in a single point at the same time and see each others IRL for the first time. It was a pleasure to meet for the first time people with which i communicated for two (?) years. This trip to Bordeaux was worth the efforts for this at least. - I am particularly disapointed that only the F-CPU project was represented. Though Peter brought his NEC/MIPS boards, the issue is different. I explained this issue a bit in the conference's introduction but yet, the fragmentation of the projects is damageable to the whole community. I have no idea how this could change. I have to code, too, social engineering is not my full-time job. If someone can convince the FreeHDL and others to participate in common meetings, that would be cool, no ? - On top of that, it was a good occasion to see how the F-CPU project is perceived by others. The simultaneous RMS/F-CPU/Prelude conferences were a good occasion to see who wants what. I also met Abdoulaye and a lot of other enthusiastic people which did not troll on the difficulty of the project. Despite design/coding problems, there are also good contacts with the OS teams (mainly Hurd but also *BSD) as you can see http://perso.linuxfr.org/penso/photos/lsm2002/kif_1901.jpg and http://plouc.net/lsm/kilobug/IMG_0616.JPG for example. - I will keep myself away from APRIL and other such organisations for a while. Their unacceptable behaviour during the evening of july 13th upsets me. I'll also stay away from geek social events, as i now know they are potentially dangerous. Furthermore, i don't see any interest for their work, only theory and no result. I prefer to code, that's the most efficient and tangible way to change things. Finally, i'll think twice or more before accepting to make a presentation in an unknown place. It's nice, as my budget is rather reduced... Read you soon, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------61F25B9F66A7184CF0A39EEE Content-Type: text/plain; charset=iso-8859-1; name="yg_lsm.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="yg_lsm.txt" file : yg_lsm.txt written in july 2002 by Yann Guidon (whygee@f-cpu) version Sat Jul 13 06:06:48 CEST 2002 This file contains the original sliding text for the Freedom CPU conference, held in july, thu. 11th 2002 in ENSEIRB in the campus of the university of Bordeaux for the Libre Software Meeting. Notes : * some personal "papers" can be found on http://f-cpu.seul.org/whygee. For example, an architectural presentation of the pipeline scheduling techniques (in french) and a step-by-step DCT optimization. * The most recent design files can be found at http://f-cpu.seul.org/new The most important files are the VHDL source snapshots and the latest manual's updates. This is the text commented and explained by Yann Guidon. Before him spoke Nicolas Boulay who explained the audience some basics about general CPU design and industry. After YG came Cédric Bail who spoke about some SW aspects. But before starting to comment the slides, there was a little speech about more general, non-technical things. Here is a little recollection from memory. -----------------------FOREWORDS----------------------- First, i have often heard people say "Free CPU" when speaking about F-CPU. The "F" means "Freedom", as it is only about that. F-CPU was first called "The Freedom project", then "Freedom CPU project" and "F-CPU" for short. It will probably sound like RMS (and he is currently doing his presentation at the same time in the Grand Amphithéatre) but please say "Freedom CPU", not "Free CPU". It is less confusing to the audience, as others might understand it differently than you (even if you mean it strongly). Second point i want to make clear is : participating actively to this project is a proof of deep dispair. One has to be really depressed if he wants to participate in such a crusade and reinvent the wheel everyday (even if this one grants you more freedom). It is only because i see no other durable, ethical and technical solution that i joined and contributed to this project which was first a pure acid-induced utopia. DMCA, EUCD and all other copyright or security enforcement laws, as well as the "murder" of the Alpha CPU, slowly made this project more important than it first seemed. Knowing how this project is difficult, you can understand that i am particularly hopeless. Emphasizing on this difficulty will not solve the F-CPU's problems, so please make constructive remarks. All contributors are perfectly aware of the problems but they try to solve the little ones that are easiest first. Third, F-CPU is not the only project that provides its design files on the Internet with a "Free" license. Several meaningful such projects were invited but none could come, we are sorry for this. This shows that the "Open source hardware" field is very fragmented and does not work the same way as in software. Fourth point is that "Open hardware" is not the same as "Free hardware" : the first will publish some code on the Internet and use whatever "free" license exists, even the GNU GPL though it is difficult to be sure about its meaning in the HW/EDA world, where tools are extremely expensive and restrictive (not to mention proprietary). F-CPU aims at Freedom and understands (as most contributors can't access the expensive tools) that copylefted sources are not enough. A proprietary-free workflow does not exist yet because the question was never serious enough to justify efforts in this domain. As noted in 3, the fragmentation and the relative overlapping of the projects that can be found on http://www.opencollector.org leads to inefficient workflows, non-standard formats or simply non-functioning sources. In a world where proprietary software rule the world for more than a decade, it is particularly frustrating. As the question was never raised before (or at least, loudly enough), there is no difference or straight line between "Open hardware" and "Free hardware". Most projects have roughly the same wish for freedom but each one takes this more or less seriously. Fashions or buzzwords also influence people's behaviour, we have seen a blossoming number of projects with "IP", "Open", "Free", Core", etc. and all their combinations in the last 5 years (for example : "OpenIP", "OpenCores", "OpenIPCores"...). One reason why F-CPU is not advanced yet is because the toolchains are not able to do serious work that can match proprietary tools. One can say that Linux existed thanks to the existence of the GNU tools and larger HDDs. However, there is no decent non-proprietary workflow. We don't ask for extensive feature support, but at least for a tool that works decently and is compatible with commercial solutions. The current solution is to use proprietary software, in hope that a serious free solution will become available soon. In order to keep the F-CPU project free from commercial and industrial pressure, the strategy is to perform intensive tests with as many tools we can legally get, either through trial periods or partnerships. Cadence's ncsim is one of the tools that are usually extremely expensive but one Cadence employee believes in "Free hardware" and provides personal licenses to the contributors of F-CPU or Opencores. Other tools are not as restrictive and don't require the user to apply or fill in any form. There are several toolsuites that an individual user can run on a personal workstation with more or less freedom, ease and performance (F-CPU contributors also maintain a "VHDL Howto" where each known tool is described and installation and use are explained). In case a tool breaks or a partnership ends, compatibility tests with the other tools will ensure that the source will remain free from any ties from one vendor. Similarly, if the sources compile nicely through all the available tools, there are few chances that a major problem appears when yet another tool is used. This makes the port to unsupported tools much easier ! For example, a lot of problems appeared when going from single tool support to dual, and much fewer problems were found when a third tool was added. However, every tools has a specific understanding of the VHDL Reference Langage Manual and error-free compilation is not garanteed on the first try. Contrarily to the Linux kernel and most GNU projects, the freedom of the F-CPU sources is not only ensured by the Copyleft, but also by the respect of the minimal langage standards, so everyone can REALLY use it. This "least common feature" approach slows the project's progress but makes it more attractive, serious... It's like an OS kernel that is designed to be compiled with Intel's, Alpha's and IBM's compilers : performance and portability would be terrific. Why spend so much personal efforts in F-CPU ? - I could have been hired by a high-tech company and do wonderful things... However everyone knows that this position does not allow one to follow the project as wanted. It is frustrating to see a project stop because corporate priorities change. There is often a lot of work waste or wrong decisions that an individual can not change. Profit of the shareholders is not always compatible with working ethic, or at least with personal beliefs. - I could make a start-up. Well, i'm an artist, not a businessman. Forget about that. - I could play the old role of the lonely inventor in his house... But patent laws would crush me. The solution is to abandon the idea of individual profit and work with other people who believe in the same things, so the project really remains free. From this point on, it becomes possible to find a win-win deal in our society which is eager to spend money in order to spend less money... Finally, the F-CPU project has recently gained some interest >from the EDA (Electronics Design Automation) community and its users : not only does the "Linux" wave become successful (it's not only a bit cheaper, it's also much easier to port old software from the SUN and HP platforms than to Windows), but the last economic recession has made everybody wonder where they are heading... -----------------------SLIDES----------------------- Title : The Freedom CPU specification and its implementation (logo) "Design and let Design" Yann Guidon (whygee@f-cpu.org) @LSM2002 F-CPU history : - the origin in 1998 : a sloshdated site by Andrew D. Balsa, Richard Gooch, Raphael Reilova... (linux hackers) - M2M : memory-mapped registers -> never caught - AlphaRISC's TTA -> too many problems - RISC -> looks classical and should work F-CPU goals: The Freedom CPU Project Constitution: voted in early 1999 " To develop and make freely available an architecture, and all other intellectual property necessary to fabricate one or more implementations of that architecture, with the following priorities, in decreasing order of importance: 1. Versatility and usefulness in as wide a range of applications as possible 2. Performance, emphasizing user-level parallelism and derived through intelligent architecture rather than advanced silicon process 3. Architecture lifespan and forward compatibility 4. Cost, including monetary and thermal considerations " Important note : "To develop (... IP...) necessary to fabricate" does NOT mean "To fabricate". It just means "To design". Fabrication is not our goal. Some constraints : - must be easily understood and manageable by a small team - no tools, no methodology, no "Free Hardware" model to copy --> we are reinventing the wheel all the time... - no structure/organisation (only a mailing list and a lot of abandonned websites) - "yet another open IP core" but done by software guyz.... Freedom as utopia * when nothing exists, we are free to imagine whatever comes to mind * when it starts to work, the real problems start and nobody wants to solve them, prefering the comfy dreams... F-CPU overview : - A new architecture that builds upon decades of computer families --> F-CPU learns from the errors of the past and wipes the compatibility problems away - inspired by DEC's Alpha and all the frustrations accumulated with other architectures : it shouldn't su>< too much. - looks like a MIPS at first sight (from very far) --> should not frighten the average CS student that was nursed with P&H's book ("bible") - The "Execution Pipeline" is inspired by the CDC6600's, but the memory interface is ground-breaking new. Instructions : - unified register set with 63 SIMD registers - fixed-size 32-bit instruction word with 3-address operations (image : ISA2.gif) - extensions with 3r1w (store+postinc) and 2r2w (load+postinc) and some nice other things. Resources : - Unified register set (64 regs, R0 = 0) (SIMD or scalar data, pointers, FP...) - Execution Units - Physical memory address space (private + public) - Virtual Memory address space (mapped to Physical memory by a TLB) - Special Registers (to perform whatever can't be scheduled cleanly in the pipeline) BUT - no stack - no architecture-visible "status register" -> no known bottleneck (except instruction decoding, prefetching, dumb compilers...) FC0 : the F-CPU Core #0 - simple static scheduling in-order issue, OOOC : "Out Of Order Completion" (not OOOE like PPC or P6 !) - VSPS : Very Short Pipeline Stages (also known as "Superpipeline" but keeps the issue of the depth open) - separation between the "memory interface" (speculative) and the "Execution pipeline" (completely deterministic) (image : FC0 coupé en 2) Pipeline latency : FC0 is a "Carpaccio CPU" FC0 has an average complexity of 6 gates between 2 pipeline D-latches --> Complex operations will take more time than simple ones ex.: MOVE, LOADCONS : 0 cycle OR, AND : 1 cycle ADD, SUB, SHL : 2 cycles Multiply, MAC : 2-4-6-8 cycles Division : very long (if ever implemented...) The FC0 Execution Pipeline GOLDEN RULE : IF AN INSTRUCTION ENTERS THE PIPELINE, IT WILL NOT BE STOPPED A short instruction can complete before a longer one --> the pipeline can not be kept coherent if it must be flushed, or it would be REALLY too complex with temporary / renamed registers :-( FC0 pipeline "flush" : When a trap/interrupt/exception occurs, the pipeline "flushes" alone by completing ALL accepted (valid) operations. A tag (one bit) per register designates which task ("new" or "old") owns each register (in order to avoid overwriting registers that are not yet saved) All the exception conditions must be caught at DECODE TIME ! --> all the instructions are designed to be trap-safe INSIDE the execution units. --> TLB miss, div/0, jump... are detected during decode so nothing harmful is injected inside the pipeline --> some instructions have yet unseen forms ! F-CPU's unusual instructions : * GET and PUT stall the instruction decode as long as the SR unit is not "ready" --> used to perform "unsafe" operations and enforce resource protection (a bit like the Pentium's MSRs) * Load and Store only use post-increment addressing mode --> pointer update and data access are parallel, keeping the pipeline short --> the next pointer is computed and checked speculatively --> the decode stage then knows whether the pointer is OK when the same pointing register is reused FC0 scheduling : * The Fetcher tries to prefetch instructions and hands them to the pipeline in order. * All instructions start at "decode", where a lot of things are done in parallel --> gather the resource status (register ready, execution unit ready...) --> read the register set --> check the memory buffers (with the register number) * Xbar Read stage : --> sends the data to the units (long wires) or bypass --> accepts the instruction or not (it's the last place where we can 'stop the pipeline') --> records the instruction in the scoreboard * OPERATION (where appliable) --> move or modify the data --> 0 to X cycles * Xbar Write stage : --> Gets the results from the units and compute the ZERO flag --> perfom bypass * Register Writeback --> there is one cycle before data can be available for reading again --> 2nd level bypass images can be found in http://f-cpu.seul.org/whygee/conf_parinux.zip FC0 throughput : NO REGISTER RENAMING ==> MINIMAL OVERHEAD Minimum : 4 cycles per instruction and 0 cycle of latency (one instruction enters the pipeline every cycle) Maximum : depends on the latency/throughput of the instruction (avoid cache misses and divisions...) Most units are pipelined : Multiply, shift, additions, load and stores ==> high sustained throughput with correctly scheduled code 1 instruction per cycle peak >>1 Arithmetic Operation per cycle with SIMD and very wide registers FC0 pipeline hazards the "Superpipeline myth" (100s of stages and deadly bubbles) does not apply to FC0. * 1 cycle bubble for a taken jump * no "hard flush", no branch prediction (not worth the effort) * FC0 can be programmed like a 2 or 3-issue superscalar CPU (most instruction take 1 or 2 cycles to complete when no register dependency is detected) Development plan : 1) Execution Pipeline (All the execution units + Xbar) ==> well advanced 2) Instruction Decoding and Scheduling --> when all the Execution Units will work properly 3) Memory interface, virtual memory 4) Interrupts, exceptions, protection. 5) Opcode map optimization and definition -------------------------------------------------------- This is the end of this small introduction to the F-CPU and the FC0's general architecture. More informations can be found on the 'net. Other planning informations : No schedule is determined : we know by experience that a schedule exists only to not be respected. It proved remarkably well for F-CPU in the last years :o) F-CPU v1.0 will be started when everything will be tested and the opcode map will be optimally defined. F-CPU will not be tagged "1.0" until everything is absolutely OK, even though v0.7 or 0.8 will seem to work and will even probably be implemented : no software compatibility will be ensured before v1.0. Fabrication is not yet planned. It may arrive in the far future, or a desperate industrial company, a government body or a non-governmental organisation may want to help this project to cut their own development costs, in which case development could occur faster than expected. A 64-bit version will be experimented first, then a 256-bit version will follow to demonstrate the design's validity and scalability. --------------61F25B9F66A7184CF0A39EEE-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jul 16 13:59:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17URdn-00030c-00 for ; Tue, 16 Jul 2002 14:41:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 14:41:19 +0200 (CEST) Received: (qmail 22925 invoked by uid 0); 16 Jul 2002 11:59:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 16 Jul 2002 11:59:07 -0000 Received: by moria.seul.org (Postfix) id 141DF146803; Tue, 16 Jul 2002 07:59:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A2F1146926; Tue, 16 Jul 2002 07:59:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14207.mail.yahoo.com (web14207.mail.yahoo.com [216.136.173.71]) by moria.seul.org (Postfix) with SMTP id 9AF3F146803 for ; Tue, 16 Jul 2002 07:59:05 -0400 (EDT) Message-ID: <20020716115905.27488.qmail@web14207.mail.yahoo.com> Received: from [130.89.241.117] by web14207.mail.yahoo.com via HTTP; Tue, 16 Jul 2002 04:59:05 PDT Date: Tue, 16 Jul 2002 04:59:05 -0700 (PDT) From: jaap stolk Subject: [f-cpu] f-cpu simulator To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i uploaded: snapshot_jws_16_07_2002.tar.bz2 to: http://f-cpu.seul.org/~f-cpu/new/ it's just a little test of last weekend, but it compiles, and can simulate ASU and INC instructions including xbar and register set. see the /c/jaap.txt file for more info. jaap. yg, it now shows all registers, and waits for enter after every stage. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 16 14:35:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17URmy-00031M-00 for ; Tue, 16 Jul 2002 14:50:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 14:50:48 +0200 (CEST) Received: (qmail 21489 invoked by uid 0); 16 Jul 2002 12:36:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 16 Jul 2002 12:36:02 -0000 Received: by moria.seul.org (Postfix) id D0174146810; Tue, 16 Jul 2002 08:36:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 93C1E14692A; Tue, 16 Jul 2002 08:36:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B505A146810 for ; Tue, 16 Jul 2002 08:35:59 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207161235.3017; Tue, 16 Jul 2002 12:35:48 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] f-cpu simulator From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2002 12:35:48 GMT Message-id: <200207161235.3017@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N where is jaap.txt ? nicO -----Message d'origine----- De: jaap stolk A: f-cpu@seul.org Date: 16/07/02 Objet: [f-cpu] f-cpu simulator i uploaded: snapshot_jws_16_07_2002.tar.bz2 to: http://f-cpu.seul.org/~f-cpu/new/ it's just a little test of last weekend, but it compiles, and can simulate ASU and INC instructions including xbar and register set. see the /c/jaap.txt file for more info. jaap. yg, it now shows all registers, and waits for enter after every stage. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 16 15:27:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17USfy-0003d4-00 for ; Tue, 16 Jul 2002 15:47:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Tue, 16 Jul 2002 15:47:38 +0200 (CEST) Received: (qmail 16836 invoked by uid 0); 16 Jul 2002 13:29:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 16 Jul 2002 13:29:26 -0000 Received: by moria.seul.org (Postfix) id 6659F14692E; Tue, 16 Jul 2002 09:29:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5BDD6146933; Tue, 16 Jul 2002 09:29:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id E083414692E for ; Tue, 16 Jul 2002 09:29:23 -0400 (EDT) Received: from hli (80.14.37.108) by smtp.laposte.net (6.0.053) id 3D32A1F900015A62 for f-cpu@seul.org; Tue, 16 Jul 2002 15:29:23 +0200 Message-ID: <000901c22ccc$93486160$6c250e50@hli> From: "Christophe Avoinne" To: References: <200207161235.3017@th00.opsion.fr> Subject: Re: Rep:[f-cpu] f-cpu simulator Date: Tue, 16 Jul 2002 15:27:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N in snapshot_jws_16_07_2002.tar.bz2. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Tuesday, July 16, 2002 2:35 PM Subject: Rep:[f-cpu] f-cpu simulator where is jaap.txt ? nicO -----Message d'origine----- De: jaap stolk A: f-cpu@seul.org Date: 16/07/02 Objet: [f-cpu] f-cpu simulator i uploaded: snapshot_jws_16_07_2002.tar.bz2 to: http://f-cpu.seul.org/~f-cpu/new/ it's just a little test of last weekend, but it compiles, and can simulate ASU and INC instructions including xbar and register set. see the /c/jaap.txt file for more info. jaap. yg, it now shows all registers, and waits for enter after every stage. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 16 21:39:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmZW-00016W-00 for ; Wed, 17 Jul 2002 13:02:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:02:18 +0200 (CEST) Received: (qmail 11698 invoked by uid 0); 16 Jul 2002 19:30:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 16 Jul 2002 19:30:35 -0000 Received: by moria.seul.org (Postfix) id E5A0B146937; Tue, 16 Jul 2002 15:30:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D214F14693C; Tue, 16 Jul 2002 15:30:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 94991146937 for ; Tue, 16 Jul 2002 15:30:33 -0400 (EDT) Received: from f-cpu.org (kdl14-194.n.club-internet.fr [213.44.12.194]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5BF7416B6 for ; Tue, 16 Jul 2002 21:30:30 +0200 (CEST) Message-ID: <3D347668.9307EA08@f-cpu.org> Date: Tue, 16 Jul 2002 21:39:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] vsim References: <200207081516.3347@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, here is a late answer but i guess you'll forgive, i did not yet read the whole TLB thread anyway... I believe you are speaking about Modelsim. Riviera uses the same file names for its tools "to ease user's migration from Modelsim". I have run the tests on a PIII-550 (my crappy laptop). it can't compare to the dual UIII when it comes to bandwidth and cache (i have a cheap mobile Celeron...) i think that Michael does not use imu64_test anymore, rather the 2 and 3. i'll have to check. I found ncsim to be fastest, with Riviera close (7% slower). simili was 60x slower and Vanilla 2x slower than simili... i did not run the tests on these two last, or i would have to wait a whole day for a positive result... But this does not qualify as a good testbench. The real one will be the time it takes to boot the CPU, no ? Nicolas Boulay wrote: > > Et voila : imu64_test : > > real 43m37.359s > user 43m27.900s > sys 0m0.400s > > so the others number ? > > nicO > > -----Message d'origine----- > De: "Nicolas Boulay" > A: > Date: 08/07/02 > Objet: [f-cpu] vsim > > I have run vsim on the eu_imu. here is the result on a Ultra Blade 1650 > (bi UIII 650 Mhz 512 Mb thought NFS file system) the run use 9 Mb of > memory. No special option are used for vcom nor vsim. > > imu64_test3 : > real 0m12.671s > user 0m4.830s > sys 0m0.410s > > imu64_test2 > real 5m49.004s > user 5m47.730s > sys 0m0.130s > > the first test is a bit too long for today ! ;p Does somebody have the > number for ncsim and simily ? To compare. > > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 17 00:05:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmZn-00016W-01 for ; Wed, 17 Jul 2002 13:02:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:02:35 +0200 (CEST) Received: (qmail 7058 invoked by uid 0); 16 Jul 2002 21:57:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 16 Jul 2002 21:57:14 -0000 Received: by moria.seul.org (Postfix) id 1084F1467EE; Tue, 16 Jul 2002 17:57:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4D5C14693A; Tue, 16 Jul 2002 17:57:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 9410C1467EE for ; Tue, 16 Jul 2002 17:57:11 -0400 (EDT) Received: from f-cpu.org (kdl16-1.n.club-internet.fr [213.44.18.1]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 21C431B68 for ; Tue, 16 Jul 2002 23:57:09 +0200 (CEST) Message-ID: <3D3498C7.D355AA5F@f-cpu.org> Date: Wed, 17 Jul 2002 00:05:59 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] f-cpu simulator References: <20020716115905.27488.qmail@web14207.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > > i uploaded: > snapshot_jws_16_07_2002.tar.bz2 to: > http://f-cpu.seul.org/~f-cpu/new/ ok i got it and will look at it. The files you first sent me seem to be ok though i did not yet compile them. > it's just a little test of last weekend, > but it compiles, and can simulate ASU and > INC instructions including xbar and register set. wow. > see the /c/jaap.txt file for more info. > > jaap. > > yg, it now shows all registers, and waits for > enter after every stage. i do not want to stop your helpful efforts but i have a problem with the current testing workflow, a solution would be to rewrite some things... The problem is to be sure that all versions (C, VHDL etc.) are coherent with the manual's description and (more importantly) with each others. This way, any input in the C version will return the same result for all other versions (if someone wants to make a Verilog version, or whatever). The idea is to do a pattern generator for each unit, and send it to all the testbenches. The results will then be compared (a diff will be ok) and equivalence of the versions will be ensured. I don't have a clear idea yet of how to do this, i want to avoid "naughty hacks" at any cost. I don't want to be forced to rewrite things whenever a new thing is implemented... one "clean" way would be to create another subdirectory, maybe "patterns", so "c" and "vhdl" could read the generated files. The script would then run "diff" on both results. Another solution is to generate the patterns containing input and expected output, so each testbench can catch the inconsistencies themselves, but it's more complex. Not to mention that the input format for every unit changes (the interfaces differ) so a library must be written in each langage to read and compare the test patterns :-/ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 17 00:02:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmZt-00016W-00 for ; Wed, 17 Jul 2002 13:02:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:02:41 +0200 (CEST) Received: (qmail 24809 invoked by uid 0); 16 Jul 2002 22:33:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 16 Jul 2002 22:33:57 -0000 Received: by moria.seul.org (Postfix) id 97FE51467F8; Tue, 16 Jul 2002 18:33:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 636D714693C; Tue, 16 Jul 2002 18:33:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a128.home.uni-hannover.de [130.75.232.128]) by moria.seul.org (Postfix) with ESMTP id E64751467F8 for ; Tue, 16 Jul 2002 18:33:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA16413; Wed, 17 Jul 2002 00:02:45 +0200 Message-ID: <20020717000245.17667@thrai.stud.uni-hannover.de> Date: Wed, 17 Jul 2002 00:02:45 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] vsim References: <200207081516.3347@th00.opsion.fr> <3D347668.9307EA08@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D347668.9307EA08@f-cpu.org>; from Yann Guidon on Tue, Jul 16, 2002 at 09:39:20PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 16, 2002 at 09:39:20PM +0200, Yann Guidon wrote: [...] > i think that Michael does not use imu64_test anymore, > rather the 2 and 3. i'll have to check. [...] Right. It's too expensive on my poor old box. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Wed Jul 17 00:47:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmZt-00016W-01 for ; Wed, 17 Jul 2002 13:02:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:02:41 +0200 (CEST) Received: (qmail 27178 invoked by uid 0); 16 Jul 2002 22:47:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 16 Jul 2002 22:47:19 -0000 Received: by moria.seul.org (Postfix) id AF37214693A; Tue, 16 Jul 2002 18:47:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3B7C14693E; Tue, 16 Jul 2002 18:47:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 907A814693A for ; Tue, 16 Jul 2002 18:47:16 -0400 (EDT) Message-ID: <20020716224715.10891.qmail@web14205.mail.yahoo.com> Received: from [130.89.241.117] by web14205.mail.yahoo.com via HTTP; Tue, 16 Jul 2002 15:47:15 PDT Date: Tue, 16 Jul 2002 15:47:15 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] f-cpu simulator To: f-cpu@seul.org In-Reply-To: <3D3498C7.D355AA5F@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, I intent to test each unit to the corresponding VHDL unit, either by reading an input file (generated by VHDL or C) or by using a c routine that generates the input code (like in the VHDL tests ) i won't test the timing inside each unit, only the output after each cycle. for this to work i will uses exactly the same input / output signals as the VHDL code. i also would like to use the same names as in VHDL, but the vhdl names are not unique (i.e. they use "input_a" wile i would like to use "asu_input_a". my problem for now is that it is very hard to find what the exact input/output signals are and what they do. (that’s wy i made the funny "stage" drawings in the c source files) i'm sure this will we more clear at some point, and i'm happy to keep adapting the names according to the vhdl. to make it more complicated: i also would like to mix the vhdl units into the simulator. would it be difficult to prepare a file with input data, call the VHDL simulator, and read its output back into the c simulator ? for example run the c simulator, but instead of the c opcode decoder, use a (experimental) vhdl opcode decoder. i'll try to fix any differences between vhdl and c as soon as possible. i also have a cople of questions: - the intermediate data can't go strait from the fetcher to the Xbar, because the 8 bit and 16 bit data are not aliged (6 bit shift needed) can i run the 16 bit intermediate data through the decoder and shift it there if it turns out to be 8 bit? (it already end up there as flags) -hoe do i do r3w1 ? (only 3 registers in opcode) is the 3rd input register == to the result register? -as i understand it, the register units reads the 3 registers that are indicated by the fetcher, and the decoder decides later if they need to be loaded onto the xbar. and doesn’t if they were not registers but flags or part of intermediate data or the instruction is stalled. dous this sound ok? --- Yann Guidon wrote: > hi ! > > jaap stolk wrote: > > > > i uploaded: > > snapshot_jws_16_07_2002.tar.bz2 to: > > http://f-cpu.seul.org/~f-cpu/new/ > ok i got it and will look at it. > The files you first sent me seem to be ok > though i did not yet compile them. > > > it's just a little test of last weekend, > > but it compiles, and can simulate ASU and > > INC instructions including xbar and register set. > wow. > > > see the /c/jaap.txt file for more info. > > > > jaap. > > > > yg, it now shows all registers, and waits for > > enter after every stage. > > i do not want to stop your helpful efforts but i > have > a problem with the current testing workflow, a > solution > would be to rewrite some things... > > The problem is to be sure that all versions (C, VHDL > etc.) > are coherent with the manual's description and (more > importantly) > with each others. This way, any input in the C > version will > return the same result for all other versions (if > someone wants > to make a Verilog version, or whatever). > > The idea is to do a pattern generator for each unit, > and send it to all the testbenches. The results will > then > be compared (a diff will be ok) and equivalence of > the > versions will be ensured. > > I don't have a clear idea yet of how to do this, i > want > to avoid "naughty hacks" at any cost. I don't want > to be > forced to rewrite things whenever a new thing is > implemented... > > one "clean" way would be to create another > subdirectory, > maybe "patterns", so "c" and "vhdl" could read the > generated > files. The script would then run "diff" on both > results. > Another solution is to generate the patterns > containing > input and expected output, so each testbench can > catch > the inconsistencies themselves, but it's more > complex. > Not to mention that the input format for every unit > changes (the interfaces differ) so a library must be > written in each langage to read and compare the test > patterns :-/ > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 17 01:20:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmZv-00016W-00 for ; Wed, 17 Jul 2002 13:02:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:02:43 +0200 (CEST) Received: (qmail 28746 invoked by uid 0); 16 Jul 2002 23:20:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 16 Jul 2002 23:20:34 -0000 Received: by moria.seul.org (Postfix) id 90DD114693E; Tue, 16 Jul 2002 19:20:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A7F6146940; Tue, 16 Jul 2002 19:20:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a128.home.uni-hannover.de [130.75.232.128]) by moria.seul.org (Postfix) with ESMTP id 7FEEB14693E for ; Tue, 16 Jul 2002 19:20:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA16667; Wed, 17 Jul 2002 01:20:29 +0200 Message-ID: <20020717012029.00188@thrai.stud.uni-hannover.de> Date: Wed, 17 Jul 2002 01:20:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] f-cpu simulator References: <3D3498C7.D355AA5F@f-cpu.org> <20020716224715.10891.qmail@web14205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <20020716224715.10891.qmail@web14205.mail.yahoo.com>; from jaap stolk on Tue, Jul 16, 2002 at 03:47:15PM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 16, 2002 at 03:47:15PM -0700, jaap stolk wrote: > hi, > > I intent to test each unit to the corresponding > VHDL unit, either by reading an input file > (generated by VHDL or C) or by using a c routine > that generates the input code (like in the VHDL > tests ) > i won't test the timing inside each unit, only > the output after each cycle. > > for this to work i will uses exactly the same > input / output signals as the VHDL code. > i also would like to use the same names as in VHDL, > but the vhdl names are not unique (i.e. they use > "input_a" wile i would like to use "asu_input_a". Doesn't matter in VHDL. In C, you can prefix the port names with `_' or something like that. > my problem for now is that it is very hard to find > what the exact input/output signals are and what they > do. (that’s wy i made the funny "stage" drawings > in the c source files) > i'm sure this will we more clear at some point, > and i'm happy to keep adapting the names according > to the vhdl. At least in my units (IAdd, IMul64 and Shuffle64) the inputs and outputs are well-documented. Do not look at the wrappers but at the files behind them. > to make it more complicated: > i also would like to mix the vhdl units into the > simulator. would it be difficult to prepare a file > with input data, call the VHDL simulator, and read > its output back into the c simulator ? If you write VHDL test engines that read the file, pass the signals to the entity-under-test, read the results and write them back, yes. But it's going to be sloooooooooooooow... > for example run the c simulator, but instead of the > c opcode decoder, use a (experimental) vhdl opcode > decoder. > > i'll try to fix any differences between vhdl and c as > soon as possible. > > i also have a cople of questions: > - the intermediate data can't go strait from the > fetcher to the Xbar, because the 8 bit and 16 bit > data are not aliged (6 bit shift needed) > can i run the 16 bit intermediate data through the > decoder and shift it there if it turns out to be > 8 bit? (it already end up there as flags) The decoder is supposed to do that. > -hoe do i do r3w1 ? (only 3 registers in opcode) > is the 3rd input register == to the result register? Either that, or the result register's "buddy" (register number ^ 1). I don't remember which one it was. > -as i understand it, the register units reads the > 3 registers that are indicated by the fetcher, and > the decoder decides later if they need to be loaded > onto the xbar. and doesn’t if they were not > registers but flags or part of intermediate data > or the instruction is stalled. > dous this sound ok? IIRC, register read and decode are performed in the same cycle: 1 - instruction fetch 2 - register read & instruction decode 3 - xbar 4 - EU That is, your idea looks correct. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 17 10:39:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmaP-00016W-00 for ; Wed, 17 Jul 2002 13:03:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:03:13 +0200 (CEST) Received: (qmail 7239 invoked by uid 0); 17 Jul 2002 08:30:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 17 Jul 2002 08:30:45 -0000 Received: by moria.seul.org (Postfix) id B151C14680B; Wed, 17 Jul 2002 04:30:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D518146823; Wed, 17 Jul 2002 04:30:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id F006114680B for ; Wed, 17 Jul 2002 04:30:40 -0400 (EDT) Received: from f-cpu.org (kdl11-241.n.club-internet.fr [213.44.9.241]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 0B5FB1EFA3; Wed, 17 Jul 2002 10:30:37 +0200 (CEST) Message-ID: <3D352D3B.8DDFB038@f-cpu.org> Date: Wed, 17 Jul 2002 10:39:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rms@gnu.org Cc: fm Subject: [f-cpu] Re: LSM2002 : Proceedings for the F-CPU topic References: <3D33D97D.65A4E60E@f-cpu.org> <200207170304.g6H34KQ22730@aztec.santafe.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Richard Stallman wrote: > > - the schedule collision between the F-CPU conference and this of RMS > was an issue for a number of people. What started as a pure laziness > and coincidence has reached some unexpected (trolling) proportions. > > I don't understand--what exactly is it that happened? All this fuss is my fault originally. It then became a way to make fun at the F-CPU presentation, some people arguing that nobody would come, others said they knew your show by heart and wanted to see something else... --------oO0°0Oo-------- End of june : i had not setup the schedule for the conference, so the LSM team gave me a list of free rooms/hours. As it was late and there was a shortage on rooms, I immediately chose the slot on the 11th because we agreed to make a F-CPU gathering on that day, so it would be cool if the people coming from Toulouse and the surroundings could see the presentation as well. The "problem" came when we discovered that there was your conference at the same time. As i said, if i had tried, i wouldn't have succeeded doing such a mistake. On top of that, Yoann (an early F-CPU France lurker, btw) did his presentation on his IDS tool too. People interested in all subjects had a hard choice to make, so a common "discussion topic" was whether there would be anybody at the F-CPU presentation. Or whether people who are used to the usual presentation in the big room would prefer to listen to something "new". The fact that the presentations took place at the same time has also put their expected values face-to-face, comparing stuffs etc... There was a strange climate, we were all curious about the outcome. Finally, the presentation was rather short (1h30) and light, but like always there were people who didn't catch :-D Though it was nothing compared to the indepth presentation done in june for Parinux (i did a very technical description of the scheduling techniques). I did not count but around 20 or 30 people were in the room, which is ok : only one guy fell asleep :-) We shouldn't have done a pause in the middle, as a few people left at that time. --------oO0°0Oo-------- What i did write in the report text was mostly the "positive aspects". One of the not so good aspect is that we didn't follow all our plans, particularly about the constitutive assembly of the F-CPU association. Not all people came at the same time (Khalid had some work troubles) and the "F-CPU France" association is still not yet created (Cédric was in charge for it but stopped at the last time). It is a deception because F-CPU has no legal existence yet. Another missed plan is that there was no way to "work" there : my computer is badly configured (LFS with no network support, i had to download, compile and configure DHCP) so the first days were spent doing basic stuffs. then the building was not open 24/7 so we had to leave during the night, and most people (inc. myself) had a room in Village 2, that is : far. It is inconvenient and in these conditions, it's better to stay in one's room and hack a bit, i did not attend any conference. My next presentation will be at the CCC's annual congress in Berlin, i wish i'll have enough money to get there and present things myself for the 4th year in a row (Cédric and nicO went there alone last year because i was broke). I like this place and wish things will be smooth like before, without schedule mistakes, trolls or any other problem. Not to mention the absence of insects and the presence of a nearby tube station ;-) and Berlin is a really exciting city... I also hope that the original presentation text gave useful informations. I made it rather short on purpose, i can be very boring sometimes and i wanted this to be understood by an average geek. I can provide any additional information if needed. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 17 10:54:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmaR-00016W-00 for ; Wed, 17 Jul 2002 13:03:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:03:15 +0200 (CEST) Received: (qmail 11196 invoked by uid 0); 17 Jul 2002 08:54:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 17 Jul 2002 08:54:44 -0000 Received: by moria.seul.org (Postfix) id F2BF6146823; Wed, 17 Jul 2002 04:54:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E1A7514698F; Wed, 17 Jul 2002 04:54:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 2275B146823 for ; Wed, 17 Jul 2002 04:54:41 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207170854.1ddf; Wed, 17 Jul 2002 08:54:29 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:[f-cpu] vsim From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2002 08:54:29 GMT Message-id: <200207170854.1ddf@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N For the first test ok, but what about test2 and 3 ???? Could you send real number and you're configuration to estim= ate some performance. nicO -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 17/07/02 Objet: Re: Rep:[f-cpu] vsim On Tue, Jul 16, 2002 at 09:39:20PM +0200, Yann Guidon wrote: [...] > i think that Michael does not use imu64_test anymore, > rather the 2 and 3. i'll have to check. [...] Right. It's too expensive on my poor old box. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 17 11:23:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UmaT-00016W-00 for ; Wed, 17 Jul 2002 13:03:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 13:03:17 +0200 (CEST) Received: (qmail 11307 invoked by uid 0); 17 Jul 2002 09:24:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 17 Jul 2002 09:24:11 -0000 Received: by moria.seul.org (Postfix) id 8FBE9146943; Wed, 17 Jul 2002 05:24:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FCBD146990; Wed, 17 Jul 2002 05:24:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3A200146943 for ; Wed, 17 Jul 2002 05:24:08 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207170923.38d8; Wed, 17 Jul 2002 09:23:56 GMT Send-By: 140.94.82.17 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Re: LSM2002 : Proceedings for the F-CPU topic From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2002 09:23:56 GMT Message-id: <200207170923.38d8@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I don't see it's really negative. The colision with others conference are the same problem for= each speaker. For the association, there is a big problem : what do we wan= t to do with it ? Very few people have answer to the question. >From my point of view, the main goal of this association is = to have a credible intermediate for sponsoring in front of compagny or= university. Cedric propose to use the facilities offer by its school. Th= e school is a little bit contreversal and a lot of other university will= not want to work with us because there is written "Epita" somewhere in t= he association status. So such association does not need to have a big managment. S= o it could be simply address to a private place. I want to try to use the facilities of the school where i co= me from. I am pretty sure that they won't help us if we use the Epita s= tructure. Cedric must send his slide to the organisation (in picture f= ormat !). nicO -----Message d'origine----- De: Yann Guidon A: rms@gnu.org Date: 17/07/02 Objet: [f-cpu] Re: LSM2002 : Proceedings for the F-CPU topic hello, Richard Stallman wrote: >=20 > - the schedule collision between the F-CPU conference= and this of RMS > was an issue for a number of people. What started a= s a pure laziness > and coincidence has reached some unexpected (trolli= ng) proportions. >=20 > I don't understand--what exactly is it that happened? All this fuss is my fault originally. It then became a way t= o make fun at the F-CPU presentation, some people arguing that nobo= dy would come, others said they knew your show by heart and wanted to see s= omething else... --------oO0=B00Oo-------- End of june : i had not setup the schedule for the conferenc= e, so the LSM team gave me a list of free rooms/hours. As it was late and there= was a shortage on rooms, I immediately chose the slot on the 11th because we agreed to make a F-CPU gathering on that day, so = it would be cool if the people coming from Toulouse and the surroundi= ngs could see the presentation as well. The "problem" came when we discovered that there was your co= nference at the same time. As i said, if i had tried, i wouldn't have= succeeded doing such a mistake. On top of that, Yoann (an early F-CPU = France lurker, btw) did his presentation on his IDS tool too. People interested in all subjects had a hard choice to make,= so a common "discussion topic" was whether there would be anybody at the= F-CPU presentation. Or whether people who are used to the usual presentation in = the big room would prefer to listen to something "new". The fact that the presentations took place at the same time has also put their expected valu= es face-to-face, comparing stuffs etc... There was a strange climate, we were all curious about the o= utcome. Finally, the presentation was rather short (1h30) and light,= but like always there were people who didn't catch :-D Though it was = nothing compared to the indepth presentation done in june for Parinu= x (i did a very technical description of the scheduling techniques). I did n= ot count but around 20 or 30 people were in the room, which is ok : o= nly one guy fell asleep :-) We shouldn't have done a pause in the middle= , as a few people left at that time. --------oO0=B00Oo-------- What i did write in the report text was mostly the "positive= aspects". One of the not so good aspect is that we didn't follow all o= ur plans, particularly about the constitutive assembly of the F-CPU as= sociation. Not all people came at the same time (Khalid had some work t= roubles) and the "F-CPU France" association is still not yet created = (C=E9dric was in charge for it but stopped at the last time). It is a dece= ption because F-CPU has no legal existence yet. Another missed plan is that there was no way to "work" there= : my computer is badly configured (LFS with no network support, i had to d= ownload, compile and configure DHCP) so the first days were spent doing basic= stuffs. then the building was not open 24/7 so we had to leave durin= g the night, and most people (inc. myself) had a room in Village 2, that = is : far. It is inconvenient and in these conditions, it's better to s= tay in one's room and hack a bit, i did not attend any conference. My next presentation will be at the CCC's annual congress in= Berlin, i wish i'll have enough money to get there and present thing= s myself for the 4th year in a row (C=E9dric and nicO went there alon= e last year because i was broke). I like this place and wish things will= be smooth like before, without schedule mistakes, trolls or any other = problem. Not to mention the absence of insects and the presence of a = nearby tube station ;-) and Berlin is a really exciting city... I also hope that the original presentation text gave useful informations. I made it rather short on purpose, i can be very boring some= times and i wanted this to be understood by an average geek. I can provide any additional information if needed. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 17 14:28:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Urkh-0004yT-00 for ; Wed, 17 Jul 2002 18:34:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 18:34:11 +0200 (CEST) Received: (qmail 3428 invoked by uid 0); 17 Jul 2002 15:34:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 17 Jul 2002 15:34:33 -0000 Received: by moria.seul.org (Postfix) id 2F14F146940; Wed, 17 Jul 2002 11:34:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1441146944; Wed, 17 Jul 2002 11:34:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id 62A8D146942 for ; Wed, 17 Jul 2002 11:34:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00560; Wed, 17 Jul 2002 14:28:14 +0200 Message-ID: <20020717142814.54172@thrai.stud.uni-hannover.de> Date: Wed, 17 Jul 2002 14:28:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:[f-cpu] vsim References: <200207170854.1ddf@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207170854.1ddf@th00.opsion.fr>; from Nicolas Boulay on Wed, Jul 17, 2002 at 08:54:29AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 17, 2002 at 08:54:29AM +0000, Nicolas Boulay wrote: > For the first test ok, but what about test2 and 3 ???? > > Could you send real number and you're configuration to estimate some > performance. You want me to run them *again*? What a waste of time. Simili 1.x (using wine) reports 38.712s for test3 (166 MHz Pentium/MMX, 96 MB RAM). Everything else takes much longer. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From zumbi2@netcourrier.com Wed Jul 17 19:44:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17UtBG-0005u3-00 for ; Wed, 17 Jul 2002 20:05:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Wed, 17 Jul 2002 20:05:42 +0200 (CEST) Received: (qmail 2920 invoked by uid 0); 17 Jul 2002 17:45:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 17 Jul 2002 17:45:24 -0000 Received: by moria.seul.org (Postfix) id 3C774146945; Wed, 17 Jul 2002 13:45:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D737146948; Wed, 17 Jul 2002 13:45:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id BCECE146945 for ; Wed, 17 Jul 2002 13:45:22 -0400 (EDT) Received: from nice-1-a7-62-147-124-27.dial.proxad.net (nice-1-a7-62-147-124-27.dial.proxad.net [62.147.124.27]) by postfix2-2.free.fr (Postfix) with ESMTP id D17585FDEF for ; Wed, 17 Jul 2002 19:41:45 +0200 (CEST) Subject: [f-cpu] Free synthesis tool for Verilog and other links From: Michael Opdenacker To: f-cpu@seul.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1026927812.2114.11.camel@pumpkin.michaelo.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.5-3mdk Date: 17 Jul 2002 19:44:00 +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, As I told some of you last week in the LSM event, a free synthesis tool exists for Verilog (unfortunately not for VHDL): http://icarus.com/eda/verilog/ Here is also a nice page full of useful links, for those who may not know it: http://www.eedesign.com/resources/opensourcelinks.html Good luck for your great project! @:-) Cheers, Michael. -- Michael Opdenacker http://michaelo.free.fr/ MATH AND ALCOHOL DON'T MIX! Please, don't drink and derive. Mathematicians Against Drunk Deriving ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Thu Jul 18 10:09:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VAqO-0000Fz-00 for ; Thu, 18 Jul 2002 14:57:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 14:57:20 +0200 (CEST) Received: (qmail 30575 invoked by uid 0); 18 Jul 2002 08:19:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 18 Jul 2002 08:19:01 -0000 Received: by moria.seul.org (Postfix) id C74221467F5; Thu, 18 Jul 2002 04:18:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8721E14680E; Thu, 18 Jul 2002 04:18:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 967AA1467F5 for ; Thu, 18 Jul 2002 04:18:58 -0400 (EDT) Received: (qmail 61759 invoked by uid 85); 18 Jul 2002 08:17:26 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.352628 secs); 18 Jul 2002 08:17:26 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 18 Jul 2002 08:17:26 -0000 Message-ID: <3D3677A8.5090202@yahoo.fr> Date: Thu, 18 Jul 2002 10:09:12 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have yet tested this tools (on this version, if well remember), but it seems have too many limitations on supported verilog subset. It's why we have decided (in my company) to do not use it. For information the Alliance project from the lip6 laboratory (from university of Jussieu in France) have a free synthesize tool with a capability of vhdl keeping. But the rtl vhdl subset is too limited to support a "real" industrial model. http://www-asim.lip6.fr/alliance/ If we want use this type of tools (on the project), we need well identified the input restrictions on the language, and code with it. Cheers, Just an Illusion Michael Opdenacker wrote: >Hello, > >As I told some of you last week in the LSM event, a free synthesis tool >exists for Verilog (unfortunately not for VHDL): > >http://icarus.com/eda/verilog/ > >Here is also a nice page full of useful links, for those who may not >know it: > >http://www.eedesign.com/resources/opensourcelinks.html > >Good luck for your great project! > > @:-) > > Cheers, > > Michael. > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 18 11:20:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VAqS-0000Fz-01 for ; Thu, 18 Jul 2002 14:57:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 14:57:24 +0200 (CEST) Received: (qmail 21852 invoked by uid 0); 18 Jul 2002 09:11:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 18 Jul 2002 09:11:19 -0000 Received: by moria.seul.org (Postfix) id 43F37146801; Thu, 18 Jul 2002 05:11:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E34A2146814; Thu, 18 Jul 2002 05:11:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 8CE82146801 for ; Thu, 18 Jul 2002 05:11:17 -0400 (EDT) Received: from f-cpu.org (kdl4-97.n.club-internet.fr [213.44.3.97]) by relay-5v.club-internet.fr (Postfix) with ESMTP id BBC4A18AE for ; Thu, 18 Jul 2002 11:11:11 +0200 (CEST) Message-ID: <3D368843.499476C4@f-cpu.org> Date: Thu, 18 Jul 2002 11:20:03 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Just an Illusion wrote: > Hi, > > I have yet tested this tools (on this version, if well remember), but it > seems have too many limitations on supported verilog subset. > > It's why we have decided (in my company) to do not use it. > > For information the Alliance project from the lip6 laboratory (from > university of Jussieu in France) have a free synthesize tool with a > capability of vhdl keeping. But the rtl vhdl subset is too limited to > support a "real" industrial model. > > http://www-asim.lip6.fr/alliance/ if needed, i still have the v4.5 files. The VHDL is useless. However, there could be a possibility to import EDIF so Leonardo or similar could help us use Alliance ... But even then, we would need access to a funder's cell library and i'm not sure Alliance would accept their formats. And even though the provided "portable" cell library works, the characterization was done in simulation IIRC, and in .35u only. So you understand that we're not done soon... > If we want use this type of tools (on the project), we need well > identified the input restrictions on the language, and code with it. As of today, the *minimal* support is that of Vanilla VHDL. It's not "open source" but it's an "abandonware" that works under Linux, the main advantage is that it is small. OTOH it's slow and only supports a few VHDL'93 constructs, but it's already enough and far more interesting than Alliance, Electric or FreeHDL... > Cheers, > Just an Illusion > > Michael Opdenacker wrote: > > >Hello, > > > >As I told some of you last week in the LSM event, a free synthesis tool > >exists for Verilog (unfortunately not for VHDL): > > > >http://icarus.com/eda/verilog/ As far as i can read, it's only a compiler/elaborator/simulator, it does not seem to provide synthesis. > >Here is also a nice page full of useful links, for those who may not > >know it: > > > >http://www.eedesign.com/resources/opensourcelinks.html hmmm the links looks like i've been there before :-) > >Good luck for your great project! luck, and courage too :-) > > @:-) > > > > Cheers, > > > > Michael. > > > WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 18 14:29:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VArF-0000Fz-00 for ; Thu, 18 Jul 2002 14:58:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 14:58:13 +0200 (CEST) Received: (qmail 27945 invoked by uid 0); 18 Jul 2002 12:20:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 18 Jul 2002 12:20:42 -0000 Received: by moria.seul.org (Postfix) id 1325214680E; Thu, 18 Jul 2002 08:20:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D30F614681A; Thu, 18 Jul 2002 08:20:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4C3EF14680E for ; Thu, 18 Jul 2002 08:20:40 -0400 (EDT) Received: from f-cpu.org (kdl11-106.n.club-internet.fr [213.44.9.106]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5125816BF for ; Thu, 18 Jul 2002 14:20:37 +0200 (CEST) Message-ID: <3D36B4AC.C7BC813D@f-cpu.org> Date: Thu, 18 Jul 2002 14:29:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] about the manual Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, cédric will try to push some manual updates this week-end. He asks me to update the ROP2 part. If people want to help, they can also submit updates. not remarks, but patches or simply a modified part. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS : i'll try to get an early plane ticket in order to go to the CCC congress in Berlin. I hope it will not be too expensive and i'll have a sleeping room close to the HAKP. As usually, it takes place between the 27th and the 29th of december. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rms@gnu.org Thu Jul 18 16:54:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VEoO-00035D-01 for ; Thu, 18 Jul 2002 19:11:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 19:11:32 +0200 (CEST) Received: (qmail 6215 invoked by uid 0); 18 Jul 2002 14:55:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 18 Jul 2002 14:55:00 -0000 Received: by moria.seul.org (Postfix) id 9525114682F; Thu, 18 Jul 2002 10:54:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E0BA146833; Thu, 18 Jul 2002 10:54:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from pele.santafe.edu (pele.santafe.edu [192.12.12.119]) by moria.seul.org (Postfix) with ESMTP id 6C33014682F for ; Thu, 18 Jul 2002 10:54:58 -0400 (EDT) Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g6IEt1B29818; Thu, 18 Jul 2002 08:55:01 -0600 (MDT) Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g6IEsub24967; Thu, 18 Jul 2002 08:54:56 -0600 (MDT) Date: Thu, 18 Jul 2002 08:54:56 -0600 (MDT) Message-Id: <200207181454.g6IEsub24967@aztec.santafe.edu> X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f From: Richard Stallman To: whygee@f-cpu.org Cc: f-cpu@seul.org In-reply-to: <3D352D3B.8DDFB038@f-cpu.org> (message from Yann Guidon on Wed, 17 Jul 2002 10:39:23 +0200) Subject: [f-cpu] Re: LSM2002 : Proceedings for the F-CPU topic References: <3D33D97D.65A4E60E@f-cpu.org> <200207170304.g6H34KQ22730@aztec.santafe.edu> <3D352D3B.8DDFB038@f-cpu.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The "problem" came when we discovered that there was your conference at the same time. Such things happen. It's too bad if that caused problems, but clearly nobody deserves to be blamed for it. I'm sorry if some people blamed you. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jul 18 17:03:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VEoQ-00035D-00 for ; Thu, 18 Jul 2002 19:11:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 19:11:34 +0200 (CEST) Received: (qmail 12497 invoked by uid 0); 18 Jul 2002 15:06:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 18 Jul 2002 15:06:52 -0000 Received: by moria.seul.org (Postfix) id 7B11E146832; Thu, 18 Jul 2002 11:06:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A9FC14693C; Thu, 18 Jul 2002 11:06:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A9185146832 for ; Thu, 18 Jul 2002 11:06:50 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6IF7Ojo095678 for ; Thu, 18 Jul 2002 09:07:25 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D36D8CD.4060904@jetnet.ab.ca> Date: Thu, 18 Jul 2002 09:03:41 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just an Illusion wrote: > Hi, > > I have yet tested this tools (on this version, if well remember), but it > seems have too many limitations on supported verilog subset. > It's why we have decided (in my company) to do not use it. > For information the Alliance project from the lip6 laboratory (from > university of Jussieu in France) have a free synthesize tool with a > capability of vhdl keeping. But the rtl vhdl subset is too limited to > support a "real" industrial model. > if we want use this type of tools (on the project), we need well > identified the input restrictions on the language, and code with it. > > Cheers, > Just an Illusion I allways thought BOTH were stupid languges : VHDL and Verlog. The irony is for best layout you still need to design the layout by hand -- CLB placement or Transistor masks. But did not the limited vhdl subset in Alliance permit generation of gate level constructs by calling C routines? The problem is how much open source is the F-CPU? If you can't have visible information >from HDL source to transistor masks (or raw gates) how can you 1) find bugs , 2) Improve layout 3) have open source from libraries used? Right now using FPGA's the tools limit you to gates and FF's for portable work. While HDL's seem to permit simulation and ease of coding, you still need several layers of abstraction that the tools don't permit you so still almost have to write your own stuff. My question is that the F-CPU is to be tested with a FPGA design but will it still be portable to a mask layout? What if I want optimize some logic by hand can I still get at information generated after several versions of compilation? ----- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 18 18:03:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VEoT-00035D-00 for ; Thu, 18 Jul 2002 19:11:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 19:11:37 +0200 (CEST) Received: (qmail 22253 invoked by uid 0); 18 Jul 2002 15:54:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 18 Jul 2002 15:54:35 -0000 Received: by moria.seul.org (Postfix) id ACE7C146833; Thu, 18 Jul 2002 11:54:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A2FE2146941; Thu, 18 Jul 2002 11:54:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4DBD6146833 for ; Thu, 18 Jul 2002 11:54:34 -0400 (EDT) Received: from f-cpu.org (kro1-228.n.club-internet.fr [213.44.93.228]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 04F4516B2 for ; Thu, 18 Jul 2002 17:54:32 +0200 (CEST) Message-ID: <3D36E6CD.A7B76AB6@f-cpu.org> Date: Thu, 18 Jul 2002 18:03:25 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Berlin in december Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i got a pair of tickets today, so i can go to Berlin in december. Now i have to find a backpacker's hostel that is close to HAKP. It will be far easier than 2 years ago, since it's early enough ;-) I have the intention to present F-CPU for the 4th time and have some fun as well. Speaking with hackers and OS writers will be another interesting side of this trip. If you plan to go there, please tell me, so i can reserve enough beds. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 18 18:34:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VEoa-00035D-00 for ; Thu, 18 Jul 2002 19:11:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 19:11:44 +0200 (CEST) Received: (qmail 27041 invoked by uid 0); 18 Jul 2002 16:25:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 18 Jul 2002 16:25:59 -0000 Received: by moria.seul.org (Postfix) id DD56F14684E; Thu, 18 Jul 2002 12:25:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91679146944; Thu, 18 Jul 2002 12:25:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 2BF6114684E for ; Thu, 18 Jul 2002 12:25:57 -0400 (EDT) Received: from f-cpu.org (kdl11-23.n.club-internet.fr [213.44.9.23]) by relay-5v.club-internet.fr (Postfix) with ESMTP id E9DB117DB for ; Thu, 18 Jul 2002 18:25:53 +0200 (CEST) Message-ID: <3D36EE28.28B5599C@f-cpu.org> Date: Thu, 18 Jul 2002 18:34:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Ben Franchuk wrote: > > Just an Illusion wrote: > > Hi, > > > > I have yet tested this tools (on this version, if well remember), but it > > seems have too many limitations on supported verilog subset. > > It's why we have decided (in my company) to do not use it. > > For information the Alliance project from the lip6 laboratory (from > > university of Jussieu in France) have a free synthesize tool with a > > capability of vhdl keeping. But the rtl vhdl subset is too limited to > > support a "real" industrial model. > > if we want use this type of tools (on the project), we need well > > identified the input restrictions on the language, and code with it. > > > > Cheers, > > Just an Illusion > > I allways thought BOTH were stupid languges : VHDL and Verlog. alright, but it's like C : we have to use them anyway :-/ > The irony is for best layout you still need to design the layout > by hand -- CLB placement or Transistor masks. > But did not the limited vhdl subset in Alliance permit generation > of gate level constructs by calling C routines? not only it's not portable but it's also extremely ugly. An extension to VHDL would probably be better than adding yet another level of langage mess (that's what you you refer in the last part of your mail). > The problem is how much open source is the F-CPU? as much as possible. > If you can't have visible information > from HDL source to transistor masks (or raw gates) how can you 1) find bugs , > 2) Improve layout 3) have open source from libraries used? First thing first : we have to define what it does, before defining how. Later "architectures" of each entity can be further optimised, but a simple behavioural code is first necessary... > Right now using FPGA's the tools limit you to gates and FF's for portable > work. While HDL's seem to permit simulation and ease of coding, you still need > several layers of abstraction that the tools don't permit you so still > almost have to write your own stuff. My question is that the F-CPU is > to be tested with a FPGA design but will it still be portable to a > mask layout? F-CPU is not only targetted at FPGA or ASIC exclusively. the behavioural version should synthesise to any platform, and specific versions of the descriptions (VHDL is cool for that) can be targetted at a specific technologies (under the same license). > What if I want optimize some logic by hand can I still > get at information generated after several versions of compilation? i don't understand the last part of the question. However, VHDL allows you to replace one version of a module ("entity" in VHDL jargon) with another version ("architecture" in VHDL, which can be written differently or even include a technology-specific description (hierarchical or flat netlist for example). > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jul 18 18:55:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VEoe-00035D-00 for ; Thu, 18 Jul 2002 19:11:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Thu, 18 Jul 2002 19:11:48 +0200 (CEST) Received: (qmail 13096 invoked by uid 0); 18 Jul 2002 16:58:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 18 Jul 2002 16:58:31 -0000 Received: by moria.seul.org (Postfix) id 2F294146808; Thu, 18 Jul 2002 12:58:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DAC5146941; Thu, 18 Jul 2002 12:58:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 8881B146808 for ; Thu, 18 Jul 2002 12:58:29 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-199.jetnet.ab.ca [207.34.60.199]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6IGx4jo029232 for ; Thu, 18 Jul 2002 10:59:04 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D36F2F7.3060207@jetnet.ab.ca> Date: Thu, 18 Jul 2002 10:55:19 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > alright, but it's like C : we have to use them anyway :-/ But what else is open source that not written in C? > First thing first : we have to define what it does, before defining how. > Later "architectures" of each entity can be further optimised, but a simple > behavioural code is first necessary... That is true. I was just reading on the web that the biggest problem with software is keeping the comments up to date. Do you have a procedure for that? > i don't understand the last part of the question. > However, VHDL allows you to replace one version of a module ("entity" in > VHDL jargon) with another version ("architecture" in VHDL, which can be > written differently or even include a technology-specific description > (hierarchical or flat netlist for example). I can do that with schematics too. I will re-state the question. Is the net-list in a form that can still be read by people if you want to tweek the code by hand? -- Ben Franchuk - Dawn * 12/24 bit cpu * ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 18 21:29:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VMB8-0008IZ-00 for ; Fri, 19 Jul 2002 03:03:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 03:03:30 +0200 (CEST) Received: (qmail 1184 invoked by uid 0); 18 Jul 2002 21:39:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 18 Jul 2002 21:39:31 -0000 Received: by moria.seul.org (Postfix) id C3629146950; Thu, 18 Jul 2002 17:39:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE246146952; Thu, 18 Jul 2002 17:39:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a130.home.uni-hannover.de [130.75.232.130]) by moria.seul.org (Postfix) with ESMTP id 4D718146950 for ; Thu, 18 Jul 2002 17:39:29 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01932; Thu, 18 Jul 2002 21:29:59 +0200 Message-ID: <20020718212959.38420@thrai.stud.uni-hannover.de> Date: Thu, 18 Jul 2002 21:29:59 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D36EE28.28B5599C@f-cpu.org>; from Yann Guidon on Thu, Jul 18, 2002 at 06:34:48PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 18, 2002 at 06:34:48PM +0200, Yann Guidon wrote: [...] > However, VHDL allows you to replace one version of a module ("entity" in > VHDL jargon) with another version ("architecture" in VHDL, which can be > written differently or even include a technology-specific description > (hierarchical or flat netlist for example). The question is whether such an architecture can still be considered `edible source code' or whether it is `binary'. Imagine someone who takes the original source, creates an optimized netlist from it and then edits it... that's almost like bit-twiddling in .o files. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jul 19 00:34:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VMB8-0008IZ-01 for ; Fri, 19 Jul 2002 03:03:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 03:03:30 +0200 (CEST) Received: (qmail 20751 invoked by uid 0); 18 Jul 2002 22:16:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Jul 2002 22:16:29 -0000 Received: by moria.seul.org (Postfix) id 05B44146951; Thu, 18 Jul 2002 18:16:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A5FF0146956; Thu, 18 Jul 2002 18:16:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 234C8146951 for ; Thu, 18 Jul 2002 18:16:25 -0400 (EDT) Received: from ifrance.com (vlt9-86.n.club-internet.fr [195.36.223.86]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 119E916E5 for ; Fri, 19 Jul 2002 00:16:04 +0200 (CEST) Message-ID: <3D374281.F1D40FB@ifrance.com> Date: Fri, 19 Jul 2002 00:34:41 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <20020718212959.38420@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Thu, Jul 18, 2002 at 06:34:48PM +0200, Yann Guidon wrote: > [...] > > However, VHDL allows you to replace one version of a module ("entity" in > > VHDL jargon) with another version ("architecture" in VHDL, which can be > > written differently or even include a technology-specific description > > (hierarchical or flat netlist for example). > > The question is whether such an architecture can still be considered > `edible source code' or whether it is `binary'. Imagine someone who > takes the original source, creates an optimized netlist from it and then > edits it... that's almost like bit-twiddling in .o files. > It's clearly not a problem. GPL apply for every thing that have a prefered forme for modification (source code in C, vhdl, but i have seen that a simple picture could be GPL, the prefered forme of modification is the picture it-self) I think we must defined how a entity could be replace by a technological one (imagine replacing the register bank by a specific design, technology dependant) : it's good for speed. But if we allow to much "closed" change, somebody could change what ever entity he want, without releasing it in "libre" licence. Maybe could we tolerate an exchange if the new code have exactly the same beavioral of the previous code. But if there is some architectural improvement, this could be hidden too... That's seems endless... :-/ nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jul 19 09:51:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagH-0000G3-00 for ; Fri, 19 Jul 2002 18:32:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:37 +0200 (CEST) Received: (qmail 29618 invoked by uid 0); 19 Jul 2002 08:01:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 19 Jul 2002 08:01:55 -0000 Received: by moria.seul.org (Postfix) id B6C20146817; Fri, 19 Jul 2002 04:01:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 70530146915; Fri, 19 Jul 2002 04:01:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 6694F146817 for ; Fri, 19 Jul 2002 04:01:52 -0400 (EDT) Received: (qmail 95014 invoked by uid 85); 19 Jul 2002 08:00:14 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.228483 secs); 19 Jul 2002 08:00:14 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 19 Jul 2002 08:00:13 -0000 Message-ID: <3D37C51E.2090809@yahoo.fr> Date: Fri, 19 Jul 2002 09:51:58 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Ben Franchuk wrote: > If you can't have visible information > from HDL source to transistor masks (or raw gates) how can you 1) find > bugs , Many technics can be apply, more traditional (like classical-simulation, driven-simulation, random-simulation...) or more new method like formal approach (equivalence checking, model checking, property checking, theorem proving...). You can find some combinaison of tools which can extract a logical function from a mask or gates netlist and generate a hdl equivalent model. > > 2) Improve layout 3) have open source from libraries used? > Right now using FPGA's the tools limit you to gates and FF's for portable > work. While HDL's seem to permit simulation and ease of coding, you > still need > several layers of abstraction that the tools don't permit you so still > almost have to write your own stuff. My question is that the F-CPU is > to be tested with a FPGA design but will it still be portable to a > mask layout? What if I want optimize some logic by hand can I still > get at information generated after several versions of compilation? Sorry but the notion of compilation is not really appropriate. You have a "real" compilation only for simulation. Alright, the first step of synthesis process is a compilation too, but the result is only used by the synthesis tools and it can't give to an other one. If you make hand-made customization to optimize logic, you can recover (fully, partially or not) some information, that depend which information at which level. By example, if you want check the customized mask layout, you can launch your testbench on both model (before customisation and after) to compare results, or make equivalence checking... (see above about remarks on how to find a bug) > > ----- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jul 19 10:22:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagH-0000G3-01 for ; Fri, 19 Jul 2002 18:32:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:37 +0200 (CEST) Received: (qmail 14190 invoked by uid 0); 19 Jul 2002 08:22:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 19 Jul 2002 08:22:18 -0000 Received: by moria.seul.org (Postfix) id 389A6146819; Fri, 19 Jul 2002 04:22:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 09117146952; Fri, 19 Jul 2002 04:22:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 26483146819 for ; Fri, 19 Jul 2002 04:22:16 -0400 (EDT) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id LAA32333 for ; Fri, 19 Jul 2002 11:22:13 +0300 Date: Fri, 19 Jul 2002 11:22:13 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links In-Reply-To: <3D36D8CD.4060904@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I allways thought BOTH were stupid languges : VHDL and Verlog. > The irony is for best layout you still need to design the layout > by hand -- CLB placement or Transistor masks. They are adequate languages for the design, not optimal. It is not usually feasible to design everything at gate level, imagine how long it would take to make 5M gate chip with schematics. Even with high level VHDL description it is a huge task. It much faster to manually fiddle with the most critical blocks and let the automatic generation handle the noncritical parts. > almost have to write your own stuff. My question is that the F-CPU is > to be tested with a FPGA design but will it still be portable to a > mask layout? What if I want optimize some logic by hand can I still > get at information generated after several versions of compilation? Easiest way is to code first versions of FCPU at quite high level with HDL languages. From that description it is quite easy to synthesize quite good versions of the chip for testing. Even if the speed is 50% of the optimal speed it is good for the testing. After the design is working and tested then different architectures of the block can be made to optimize the behavior for different needs (ASIC/FPGA etc.). For example with good synthesizer best implementation of multiplier can be c<=a*b style structure. Synplify for example has excellent multiplier library for FPGAs or if available used HW multipliers from the fabric. The equivalence of the different block architectures can be checked with formal tools to make verification of different versions easier. The problem with this approach is that there are no free formal tools, and I doubt that there will be for a long time. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jul 19 10:31:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagI-0000G3-00 for ; Fri, 19 Jul 2002 18:32:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:38 +0200 (CEST) Received: (qmail 14534 invoked by uid 0); 19 Jul 2002 08:31:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Jul 2002 08:31:21 -0000 Received: by moria.seul.org (Postfix) id 00496146915; Fri, 19 Jul 2002 04:31:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D2E44146957; Fri, 19 Jul 2002 04:31:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 260FE146915 for ; Fri, 19 Jul 2002 04:31:17 -0400 (EDT) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id LAA00306 for ; Fri, 19 Jul 2002 11:31:15 +0300 Date: Fri, 19 Jul 2002 11:31:15 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links In-Reply-To: <3D36F2F7.3060207@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > That is true. I was just reading on the web that the biggest problem > with software is keeping the comments up to date. Do you have a > procedure for that? Documentation is always the problem. One critical thing is that the design specifications should always be the master documents. Usually the code is considered to be the main documentation, but in big project it is impossible to read everybodys code. Internal block implementation documentation is not so critical if the interfaces are well documented between the blocks. Interfaces are important for the other designers and for the verification engineers. > I can do that with schematics too. I will re-state the question. > Is the net-list in a form that can still be read by people if you want > to tweek the code by hand? Usually different tools destroy the hierarchy inside the netlist at least to some extent. For big chips manually fiddling with the netlist is not fun task to do. I wouldn't even try that without formal tools to check what the change really did. And even small manual netlist changes can make interesting problems in layout. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Fri Jul 19 10:36:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagJ-0000G3-00 for ; Fri, 19 Jul 2002 18:32:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:39 +0200 (CEST) Received: (qmail 14050 invoked by uid 0); 19 Jul 2002 08:36:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 19 Jul 2002 08:36:40 -0000 Received: by moria.seul.org (Postfix) id 39AFC146952; Fri, 19 Jul 2002 04:36:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4E2C14695C; Fri, 19 Jul 2002 04:36:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mpoli.fi (mpoli.fi [62.236.132.1]) by moria.seul.org (Postfix) with ESMTP id 46AF4146952 for ; Fri, 19 Jul 2002 04:36:37 -0400 (EDT) Received: from localhost (embo@localhost) by mpoli.fi (8.9.3/8.9.3/19991028-jr) with ESMTP id LAA00508 for ; Fri, 19 Jul 2002 11:36:35 +0300 Date: Fri, 19 Jul 2002 11:36:35 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links In-Reply-To: <3D374281.F1D40FB@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > I think we must defined how a entity could be replace by a technological > one (imagine replacing the register bank by a specific design, > technology dependant) : it's good for speed. But if we allow to much > "closed" change, somebody could change what ever entity he want, without > releasing it in "libre" licence. Maybe could we tolerate an exchange if How about marking all the blocks where this kind of technology dependent optimization can be done. For example in register bank the optimal solution can be some block from the vendor libraries that is proprietary and NDA covered. And the entity encapsulating those "commercial" blocks could also contain some glue logic to adapt the interfaces. For the control logic this kind of technology dependent twiddling should not be so important. Or if it is needed they should be functionally identical. ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jul 19 12:00:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagJ-0000G3-01 for ; Fri, 19 Jul 2002 18:32:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:39 +0200 (CEST) Received: (qmail 17363 invoked by uid 0); 19 Jul 2002 10:10:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 19 Jul 2002 10:10:01 -0000 Received: by moria.seul.org (Postfix) id 652F1146957; Fri, 19 Jul 2002 06:09:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2573A14695D; Fri, 19 Jul 2002 06:09:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 4C506146957 for ; Fri, 19 Jul 2002 06:09:58 -0400 (EDT) Received: (qmail 1183 invoked by uid 85); 19 Jul 2002 10:08:19 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.321402 secs); 19 Jul 2002 10:08:19 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 19 Jul 2002 10:08:19 -0000 Message-ID: <3D37E323.3010203@yahoo.fr> Date: Fri, 19 Jul 2002 12:00:03 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Ben Franchuk wrote: >> i don't understand the last part of the question. >> However, VHDL allows you to replace one version of a module ("entity" in >> VHDL jargon) with another version ("architecture" in VHDL, which can be >> written differently or even include a technology-specific description >> (hierarchical or flat netlist for example). > > > I can do that with schematics too. I will re-state the question. > Is the net-list in a form that can still be read by people if you want > to tweek the code by hand? > The problem with schematics is that they are in proprietary format, which are incompatible between tools. More, synthesizer don't like them (I don't no why but when I try to give them circuit like postscript, jpeg, png files... They crush :-D). It seems than some peoples misunderstood what we have in a hdl code (verilog or vhdl). With the same language, we can describe 3 main level of abstraction of the same design (or function) : - The behavioral level, where you describe the dataflow treatment without any preoccupation of register transmission, synchronism implementation... - The structural level (named *rtl*, for Register Transfert Level), where you describe one of the implementation possibility of the previous behavioral model. At this level, you need define the registers, the synchronism clocks... - The gate level (or netlist) where you made a implementation of the previous levels, and describe like primary blocks interconnexion. About remarks of Whygee about couple entity/architecture, when you want simulate, synthesize, check... the design you need give a couple of "elements" which describe in on hand the external interface (the "entity") and in the other hand the behavior code (the "architecture"). The most important thing about optimization is than you can easily change your behavioral code, without modify all the system, if your custom code have the same functionnality (and more respect the same communication protocol). The internal block treatment isn't important in that case. Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jul 19 12:49:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagM-0000G3-00 for ; Fri, 19 Jul 2002 18:32:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:42 +0200 (CEST) Received: (qmail 19872 invoked by uid 0); 19 Jul 2002 10:59:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Jul 2002 10:59:04 -0000 Received: by moria.seul.org (Postfix) id E381814695D; Fri, 19 Jul 2002 06:59:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA19D14695F; Fri, 19 Jul 2002 06:59:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id DD96D14695D for ; Fri, 19 Jul 2002 06:59:01 -0400 (EDT) Received: (qmail 2762 invoked by uid 85); 19 Jul 2002 10:57:23 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.165745 secs); 19 Jul 2002 10:57:23 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 19 Jul 2002 10:57:22 -0000 Message-ID: <3D37EEA3.7000504@yahoo.fr> Date: Fri, 19 Jul 2002 12:49:07 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Kim Enkovaara wrote: > >The equivalence of the different block architectures can be checked with >formal tools to make verification of different versions easier. The >problem with this approach is that there are no free formal tools, and I >doubt that there will be for a long time. > False, you can find few of them, but they are limited : in performance, on input language support... See my previous answer with the Alliance link. Follow a non exhaustive list : Alliance vis & sis (I know than I have forget 1 or 2 more minimum but I could remember their names) Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 19 13:58:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagN-0000G3-01 for ; Fri, 19 Jul 2002 18:32:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:43 +0200 (CEST) Received: (qmail 18785 invoked by uid 0); 19 Jul 2002 11:58:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Jul 2002 11:58:50 -0000 Received: by moria.seul.org (Postfix) id 822A314695E; Fri, 19 Jul 2002 07:58:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B1AB146961; Fri, 19 Jul 2002 07:58:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 143BA14695E for ; Fri, 19 Jul 2002 07:58:48 -0400 (EDT) Message-ID: <20020719115847.99968.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.38] by web14208.mail.yahoo.com via HTTP; Fri, 19 Jul 2002 04:58:47 PDT Date: Fri, 19 Jul 2002 04:58:47 -0700 (PDT) From: jaap stolk Subject: [f-cpu] Snapshot_jws update To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, for those interested: i uploaded a new Snapshot_jws of a f-cpu simulator to: http://f-cpu.seul.org/~f-cpu/new/?M=A it now compiles on its own (no YG snapshot needed) just unpack it somewhere and read jaap.txt biggest changes are a rewrite of the x-bar, and a working fetcher / decoder (no scheduler yet). jaap. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From targetemailextractor@btamail.net.cn Fri Jul 19 15:07:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagO-0000G3-00 for ; Fri, 19 Jul 2002 18:32:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:44 +0200 (CEST) Received: (qmail 26056 invoked by uid 0); 19 Jul 2002 13:07:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Jul 2002 13:07:49 -0000 Received: by moria.seul.org (Postfix) id 3B8D214695C; Fri, 19 Jul 2002 09:07:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F3529146962; Fri, 19 Jul 2002 09:07:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from localhost.com (unknown [61.174.203.44]) by moria.seul.org (Postfix) with SMTP id 05D3914695C for ; Fri, 19 Jul 2002 09:07:42 -0400 (EDT) From: targetemailextractor@btamail.net.cn To: f-cpu@seul.org Date: Fri, 19 Jul 2002 21:07:42 +0800 Subject: [f-cpu] ADV: Direct email blaster, email addresses extractor, maillist verify, maillist manager........... X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20020719130742.05D3914695C@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N =3CBODY bgColor=3D#ffffff=3E =3CDIV=3E=3CFONT size=3D2=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EDirect Email Blaster=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E=3CFONT size=3D2=3E =3CP=3E=3CFONT face=3DArial=3E=3CB=3E=3CFONT color=3D#006600=3E=3CI=3EThe program will send mail at the rate of over 1=2C 000 e-mails per minute=2E =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3ELegal and Fast sending bulk emails =3B=3CBR=3E=3CFONT color=3D#006600=3E=3CI=3EBuilt in SMTP server =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3EHave Return Path =3B=3CBR=3ECan Check Mail Address =3B=3CBR=3E=3CFONT color=3D#006600=3E=3CI=3EMake Error Send Address List=28 Remove or Send Again=29 =3B=3C=2FI=3E=3C=2FFONT=3E=3CBR=3ESupport multi-threads=2E =3B=3CBR=3ESupport multi-smtp servers=2E =3B=3CBR=3EManages your opt-in E-Mail Lists =3B=3CBR=3EOffers an easy-to-use interface! =3B=3CBR=3EEasy to configure and use =3B=3C=2FB=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fedeb=5Fset=2Ezip=22=3E=3CSTRONG=3EDownload Now=3C=2FSTRONG=3E=3C=2FA=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EMaillist Verify=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EMaillist Verify is intended for e-mail addresses and mail lists verifying=2E The main task is to determine which of addresses in the mail list are dead=2E The program is oriented=2C basically=2C on programmers which have their own mail lists to inform their users about new versions of their programs=2E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EThe program works on the same algorithm as ISP mail systems do=2E Mail servers addresses for specified address are extracted from DNS=2E The program tries to connect with found SMTP-servers and simulates the sending of message=2E It does not come to the message =3CNOBR=3Esending ‿=3B=2FNOBR>=3B EMV disconnect as soon as mail server informs does this address exist or not=2E EMV can find=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CNOBR=3E =3Babout 90% of dead addresses ‿=3B=2FNOBR>=3B some mail systems receive all messages and only then see their =3B=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CNOBR=3Eaddresses and if the address is dead send the message back with remark about it=2E=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FP=3E=3CNOBR=3E =3CP=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbemv=5Fset=2Ezip=22=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FA=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EExpress Email Blaster =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EExpress Email Blaster =3B is a very fast=2C powerful yet simple to use email sender=2E Utilizing multiple threads=2Fconnections=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E =3Band multiple SMTP servers your emails will be sent out fast and easily=2E There are User Information=2C Attach Files=2C =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3EAddress and Mail Logs four tabbed area for the E-mails details for sending=2E About 25 SMTP servers come with the =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3Edemo version=2C and users may Add and Delete SMTP servers=2E About =3CFONT color=3D#008000=3E=3CB=3E60=2C000=3C=2FB=3E=3C=2FFONT=3E E-mails will be sent out per hour=2E=22=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbeeb=5Fset=2Ezip=22=3E=3CFONT face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial size=3D4=3EExpress Email Address Extractor=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FP=3E=3CFONT size=3D4=3E =3CP=3E=3CFONT color=3D#008000 size=3D3=3EThis program is the most efficient=2C easy to use email address collector available on the =3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3D#008000 size=3D3=3E =3Binternet! =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D3=3EBeijing Express Email Address Extractor =28ExpressEAE=29 is designed to extract=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3E =3Be-mail addresses from web-pages on the Internet =28using HTTP protocols=29 =2EExpressEAE=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3E =3Bsupports operation through many proxy-server and works very fast=2C as it is able of =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 size=3D3=3Eloading several pages simultaneously=2C and requires very few resources=2E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial=3E=3CFONT size=3D3=3EWith it=2C you will be able to=3C=2FFONT=3E=3CFONT size=3D2=3E =3C=2FFONT=3E=3CFONT size=3D3=3Euse targeted searches to crawl the world wide web=2C extracting =3B=3C=2FFONT=3E=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Ethousands of clean=2C fresh email addresses=2E Ably Email address Extractor is unlike other =3B=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Eaddress collecting programs=2C which limit you to one or two search engines and are unable=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3E =3Bto do auto searches HUGE address=2E Most of them collect a high percentage of incomplete=2C =3B=3C=2FFONT=3E =3CP=3E=3CFONT color=3D#000000 face=3DArial size=3D3=3Eunusable addresses which will cause you serious problems when using them in a mailing=2E =3B=3C=2FFONT=3E =3CUL=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EEasier to learn and use than any other email address collector program available=2E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAccesses eight search engines =3B=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAdd your own URLs to the list to be searched=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D3=3E=3CFONT color=3D#008000=3ESupports operation through =3C=2FFONT=3E=3CFONT color=3D#ff00ff=3Ea lot of=3C=2FFONT=3E=3CFONT color=3D#008000=3E proxy-server and works very fast =28HTTP Proxy=29=3C=2FFONT=3E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAble of loading several pages simultaneously=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3ERequires very few resources=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3ETimeout feature allows user to limit the amount of time crawling in dead sites and traps=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D3=3E=3CFONT color=3D#008000=3EEasy to make =3C=2FFONT=3E=3CFONT color=3D#ff00ff=3EHuge=3C=2FFONT=3E=3CFONT color=3D#008000=3E address list=3C=2FFONT=3E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EPause=2Fcontinue extraction at any time=2E=3C=2FFONT=3E =3CLI=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EAuto connection to the Internet=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Feeae=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial=3EExpress Email Address Downloader=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CUL=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Eis a 32 bit Windows Program for e-mail marketing=2E It is intended for easy and convenient=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3E =3Bsearch large e-mail address lists from mail servers=2E The program can be operated on =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3EWindows 95=2F98=2FME=2F2000 and NT=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Esupport multi-threads =28up to 1024 connections=29=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Ehas the ability =3B to reconnect to the mail server if the server has disconnected and =3B=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#000000 size=3D2=3Econtinue the searching at the point where it has been interrupted=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#006600 size=3D2=3EExpressEAD =3B =3C=2FFONT=3E=3CFONT color=3D#000000 size=3D2=3Ehas an ergonomic interface that is easy to set up and simple to use=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CP=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT color=3D#008000 face=3DArial size=3D4=3EFeatures=3A=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CUL type=3Ddisc=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Esupport multi-threads=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eauto get smtp server address=2Csupport multi-smtp servers=2E=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eauto save =3B E-Mail Lists=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial=3E=3CSTRONG=3E=3CFONT face=3DArial size=3D2=3Eoffers an easy-to-use interface!=3C=2FFONT=3E=3C=2FSTRONG=3E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CDIV=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Feead=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CSTRONG=3E=3CFONT color=3D#ff0080 face=3DArial=3EExpress Maillist Manager=3C=2FFONT=3E=3C=2FSTRONG=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT size=3D2=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3EThis program was designed to be a complement to the =3C=2FFONT=3E=3CFONT color=3D#800080 size=3D3=3EDirect Email Blaster =3B =3C=2FFONT=3E=3CFONT color=3Dblack size=3D3=3Eand =3C=2FFONT=3E=3CFONT color=3D#800080 size=3D3=3EEmail Blaster =3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3Esuite of bulk email software programs=2E Its purpose is to organize your email lists in order to be more =3B=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E=3CFONT color=3Dblack size=3D3=3Eeffective with your email marketing campaign=2E Some of its features include=3A=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#008000 face=3DArial=3E=3CFONT size=3D3=3E‿=3BCombine several lists into one file=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BSplit up larger lists to make them more manageable=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BRemove addresses from file=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BManual editing=2C adding=2C and deleting of addresses=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BAbility to auto clean lists=2C that is=2C remove any duplicate or unwanted addresses=2E=3C=2FFONT=3E=3CBR=3E=3CFONT size=3D3=3E‿=3BMaintain all your address lists within the program so you no =3B longer need to keep all your=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3E =3Blists saved as separate text files=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CSTRONG=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fbj=5Fdownload=2Fbemm=5Fset=2Ezip=22=3E=3CFONT color=3D#008000 face=3DArial size=3D3=3EDownload Now=3C=2FFONT=3E=3C=2FA=3E=3C=2FSTRONG=3E=3C=2FP=3E =3CP=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E=3C=2FP=3E =3CP=3E =3B=3C=2FP=3E =3CDIV=3E=3CFONT face=3DArial=3Eif you want to remove your email=2C please send email to =3CA href=3D=22mailto=3Atargetemailremoval=40btamail=2Enet=2Ecn=22=3Etargetemailremoval=40btamail=2Enet=2Ecn=3C=2FA=3E=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DArial=3E =3B=3C=2FFONT=3E =3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E=3C=2FFONT=3E=3C=2FDIV=3E=3C=2FFONT=3E=3C=2FNOBR=3E=3C=2FFONT=3E=3C=2FFONT=3E=3C=2FDIV=3E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jul 19 15:52:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagR-0000G3-00 for ; Fri, 19 Jul 2002 18:32:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:47 +0200 (CEST) Received: (qmail 13455 invoked by uid 0); 19 Jul 2002 13:55:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Jul 2002 13:55:22 -0000 Received: by moria.seul.org (Postfix) id 7A33814695F; Fri, 19 Jul 2002 09:55:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71BC0146962; Fri, 19 Jul 2002 09:55:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 0E98914695F for ; Fri, 19 Jul 2002 09:55:20 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6JDtujo008683 for ; Fri, 19 Jul 2002 07:55:57 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D381988.1050905@jetnet.ab.ca> Date: Fri, 19 Jul 2002 07:52:08 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just an Illusion wrote: > The problem with schematics is that they are in proprietary format, > which are incompatible between tools. > More, synthesizer don't like them (I don't no why but when I try to give > them circuit like postscript, jpeg, png files... They crush :-D). True, but I am visible person I like to see block diagrams and such. The schematic problem is one due to lack of tools rather than a poor data entry format. I would also go so far as to say even the HDL's are proprietary formats because of the minor diferences in compilers. I suspect most venders of the tools don't want portablity but rather just have you to stick with their product. > It seems than some peoples misunderstood what we have in a hdl code > (verilog or vhdl). I want more choice than that, but since I am NOT FPGA vender or some BIG GOVERMENT AGENCY I have no say in the matter. > With the same language, we can describe 3 main level of abstraction of > the same design (or function) : > > - The behavioral level, where you describe the dataflow treatment > without any preoccupation of register transmission, synchronism > implementation... > - The structural level (named *rtl*, for Register Transfert Level), > where you describe one of the implementation possibility of the previous > behavioral model. At this level, you need define the registers, the > synchronism clocks... > - The gate level (or netlist) where you made a implementation of the > previous levels, and describe like primary blocks interconnexion. I can't see how the behavorial level be a major level above the RTL level? All operations still have fully defined. a <- b * c may look ok but what about overflow, signed vs unsigned and other parameters. But then too I have used a computer (PDP-8/S) that used real transistors diodes and other components. If something breaks you fix it, not like today's computers. I still like to stay close to the hardware level. Note I am questioning the tools that can be used here, not how the F-CPU is implimented. The F-CPU seems to be comeing along nicely. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jul 19 17:31:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VagW-0000G3-00 for ; Fri, 19 Jul 2002 18:32:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 18:32:52 +0200 (CEST) Received: (qmail 2308 invoked by uid 0); 19 Jul 2002 15:41:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Jul 2002 15:41:00 -0000 Received: by moria.seul.org (Postfix) id 028A7146962; Fri, 19 Jul 2002 11:41:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC9B7146964; Fri, 19 Jul 2002 11:40:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id AF737146962 for ; Fri, 19 Jul 2002 11:40:58 -0400 (EDT) Received: (qmail 13531 invoked by uid 85); 19 Jul 2002 15:39:18 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.504108 secs); 19 Jul 2002 15:39:18 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 19 Jul 2002 15:39:17 -0000 Message-ID: <3D3830B6.4050204@yahoo.fr> Date: Fri, 19 Jul 2002 17:31:02 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> <3D381988.1050905@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Ben Franchuk wrote: > Just an Illusion wrote: > >> The problem with schematics is that they are in proprietary format, >> which are incompatible between tools. >> More, synthesizer don't like them (I don't no why but when I try to >> give them circuit like postscript, jpeg, png files... They crush :-D). > > > True, but I am visible person I like to see block diagrams and such. > The schematic problem is one due to lack of tools rather than a poor data > entry format. > I would also go so far as to say even the HDL's are proprietary formats > because of the minor diferences in compilers. I suspect most venders > of the > tools don't want portablity but rather just have you to stick with > their product. > Some time, I'll prefer graphical view too, but it can be confusing too (by example, if you have a design with 10 explosed 64 bits buses and some logic). I am agree, the vendors have proprietary compiling format because this format isn't an normalized nor standardize exchange format. Each vendor adapt his compiled model to their proprietary tools treatment philosophy. The h/w exchange format are hdl (vhdl and verilog) sources, hdl netlist source and *edif* format. See the different h/w project on the net. > >> It seems than some peoples misunderstood what we have in a hdl code >> (verilog or vhdl). > > > I want more choice than that, but since I am NOT FPGA vender or some BIG > GOVERMENT AGENCY I have no say in the matter. Wait, wait, don't make mistake. The both main hdl language are *not* fpga specific. The both ones are h/w modelisation language to design any h/w systems (digital or not, with the vhdl-ams and the verilog-a extension). The design can be implemented (fully or partially) in any type of appropriate programmable logic like : rom, prom, eprom e2prom, ram, pld, gal, fpga, asic... > >> With the same language, we can describe 3 main level of abstraction >> of the same design (or function) : >> >> - The behavioral level, where you describe the dataflow treatment >> without any preoccupation of register transmission, synchronism >> implementation... >> - The structural level (named *rtl*, for Register Transfert Level), >> where you describe one of the implementation possibility of the >> previous behavioral model. At this level, you need define the >> registers, the synchronism clocks... >> - The gate level (or netlist) where you made a implementation of the >> previous levels, and describe like primary blocks interconnexion. > > > I can't see how the behavorial level be a major level above the RTL > level? Search the processor Mark2 code, this is an old model of 8 bit processor given into the book : R. ARMSTRONG : Chip-Level Modeling With VHDL; Prentice Hall, Englewood Cliffs,NEW-JERSEY 07632. 1989 And try to synthesize the code, or try to rewrite it like rtl model and you can see the difference. Or keep behavioral description of different project on opencores.org > > All operations still have fully defined. a <- b * c may look ok but what > about overflow, signed vs unsigned and other parameters. > But then too I have used a computer (PDP-8/S) that used real transistors > diodes and other components. If something breaks you fix it, not like > today's > computers. I still like to stay close to the hardware level. > Note I am questioning the tools that can be used here, not how the F-CPU > is implimented. The F-CPU seems to be comeing along nicely. > Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Jul 19 19:24:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17VdnU-0002VV-00 for ; Fri, 19 Jul 2002 21:52:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.8.3) for thomas@localhost (single-drop); Fri, 19 Jul 2002 21:52:16 +0200 (CEST) Received: (qmail 17787 invoked by uid 0); 19 Jul 2002 17:27:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Jul 2002 17:27:49 -0000 Received: by moria.seul.org (Postfix) id 1E5DE146921; Fri, 19 Jul 2002 13:27:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2D8D146965; Fri, 19 Jul 2002 13:27:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 5EA6B146921 for ; Fri, 19 Jul 2002 13:27:47 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-212.jetnet.ab.ca [207.34.60.212]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6JHSOjo070053 for ; Fri, 19 Jul 2002 11:28:25 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D384B55.4060904@jetnet.ab.ca> Date: Fri, 19 Jul 2002 11:24:37 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> <3D381988.1050905@jetnet.ab.ca> <3D3830B6.4050204@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just an Illusion wrote: > The h/w exchange format are hdl (vhdl and verilog) sources, hdl netlist > source and *edif* format. See the different h/w project on the net. There is some good stuff out there but good I/O devices are still harder to find Open Source. A whole lot 6502 chips with out BCD math too. Since I will be designing in TTL for a while still all my source is in PDF schematics :) > Wait, wait, don't make mistake. > The both main hdl language are *not* fpga specific. It is the minor ones -- Cupl,Ahdl,Pal-asm I was thinking about. > The both ones are h/w modelisation language to design any h/w systems > (digital or not, with the vhdl-ams and the verilog-a extension). The > design can be implemented (fully or partially) in any type of > appropriate programmable logic like : rom, prom, eprom e2prom, ram, pld, > gal, fpga, asic... I note TTL is missing from the LIST (grin). > > Search the processor Mark2 code, this is an old model of 8 bit processor > given into the book : > R. ARMSTRONG : Chip-Level Modeling With VHDL; Prentice Hall, Englewood > Cliffs,NEW-JERSEY 07632. 1989 > > And try to synthesize the code, or try to rewrite it like rtl model and > you can see the difference. I live in the middle of the Great White North of Canada, getting any book is difficult unless I buy it. I would like to learn a HDL but I need a book that explains the languge and constructs well rather than teaching logic. A complier would help too, but this thread is getting off topic now. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 19 14:18:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Vjq0-0006gc-01 for ; Sat, 20 Jul 2002 04:19:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 20 Jul 2002 04:19:16 +0200 (CEST) Received: (qmail 32693 invoked by uid 0); 19 Jul 2002 21:58:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 19 Jul 2002 21:58:57 -0000 Received: by moria.seul.org (Postfix) id 6592C1467FD; Fri, 19 Jul 2002 17:58:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4402C14681E; Fri, 19 Jul 2002 17:58:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a236.home.uni-hannover.de [130.75.232.236]) by moria.seul.org (Postfix) with ESMTP id B36361467FD for ; Fri, 19 Jul 2002 17:58:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00545; Fri, 19 Jul 2002 14:18:03 +0200 Message-ID: <20020719141803.29442@thrai.stud.uni-hannover.de> Date: Fri, 19 Jul 2002 14:18:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D37E323.3010203@yahoo.fr>; from Just an Illusion on Fri, Jul 19, 2002 at 12:00:03PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 19, 2002 at 12:00:03PM +0200, Just an Illusion wrote: [...] > The problem with schematics is that they are in proprietary format, > which are incompatible between tools. > More, synthesizer don't like them (I don't no why but when I try to give > them circuit like postscript, jpeg, png files... They crush :-D). Of course you have to convert them to *text* before you feed them to the VHDL tools. Try uuencode. (SCNR) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 20 19:08:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Vyum-0000Iu-00 for ; Sat, 20 Jul 2002 20:25:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 20 Jul 2002 20:25:12 +0200 (CEST) Received: (qmail 3288 invoked by uid 0); 20 Jul 2002 16:59:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Jul 2002 16:59:50 -0000 Received: by moria.seul.org (Postfix) id E3F8E146809; Sat, 20 Jul 2002 12:59:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2D8A146919; Sat, 20 Jul 2002 12:59:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 3CF43146809 for ; Sat, 20 Jul 2002 12:59:49 -0400 (EDT) Received: from f-cpu.org (kdl11-55.n.club-internet.fr [213.44.9.55]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 6E4971696 for ; Sat, 20 Jul 2002 18:59:45 +0200 (CEST) Message-ID: <3D39991C.7FC4BFCF@f-cpu.org> Date: Sat, 20 Jul 2002 19:08:44 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] f-cpu simulator References: <20020716224715.10891.qmail@web14205.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! i'm starting only now to dig into your files (even though i have thousands of other things to do, such as work on the manual, i know...). In the beginning, i think that i'll have to carefully watch how fcpusim is designed. when everything goes ok, we will all return back to our favorite things. First thing to remark : clearly separate the simulator >from the I/O. I think that the fcpusim files should be moved away from the /toplevel/ directory, to another new one that is dedicated to this simulator (simply /fcpusim/ for example). This way, someone wanting to make a different interface does not have any problem. OTOH toplevel will be in charge of keeping the pipeline correctly ordered by calling the individual unit's functions in the correct order (there are some ways to avoid the costly FF copy). Concerning one of your remarks in your jaap.txt file, i recommend usign ncurses and gpm. I have found some resources about programming with these libraries and it should not be too complex. i'll send you a file that explains how to use GPM. Using this is a first step towards a better interface. jaap stolk wrote: > hi, > > I intent to test each unit to the corresponding > VHDL unit, either by reading an input file > (generated by VHDL or C) or by using a c routine > that generates the input code (like in the VHDL > tests ) finally, it seems that we will have to write a little library in C and VHDL that can read the input stimuli. The vectors will be generated by another program. i'll do my best to make something clean and scalable. It would be cool if Renaud/Illusion helped us here... > i won't test the timing inside each unit, only > the output after each cycle. that's obvious. > for this to work i will uses exactly the same > input / output signals as the VHDL code. > i also would like to use the same names as in VHDL, > but the vhdl names are not unique (i.e. they use > "input_a" wile i would like to use "asu_input_a". that's not a big problem ... > my problem for now is that it is very hard to find > what the exact input/output signals are and what they > do. (that’s wy i made the funny "stage" drawings > in the c source files) > i'm sure this will we more clear at some point, > and i'm happy to keep adapting the names according > to the vhdl. i am not sure that it is absolutely necessary to reuse the VHDL names. > to make it more complicated: > i also would like to mix the vhdl units into the > simulator. why ? do you want to do cosimulation ? > would it be difficult to prepare a file > with input data, call the VHDL simulator, and read > its output back into the c simulator ? it's possible, but a big overkill... > for example run the c simulator, but instead of the > c opcode decoder, use a (experimental) vhdl opcode > decoder. what would be the benefits ? if we can ensure that the C and VHDL sources are equivalent, there is no need to do that... > i'll try to fix any differences between vhdl and c as > soon as possible. don't stay focused too much on that, though. > i also have a cople of questions: > - the intermediate data can't go strait from the > fetcher to the Xbar, because the 8 bit and 16 bit > data are not aliged (6 bit shift needed) > can i run the 16 bit intermediate data through the > decoder and shift it there if it turns out to be > 8 bit? (it already end up there as flags) the decoding stage performs the shifts 'speculatively' : imm8 and imm16 are expanded and duplicated, and the desired result is multiplexed by the Xbar. it takes one or two cycles, that's enough. > -hoe do i do r3w1 ? (only 3 registers in opcode) > is the 3rd input register == to the result register? the 3 sources are the 3 register fields of the instruction (they are wired to the register set's input). that's as simple as that. Now for the result, it depends on the instruction : - for the normal operations, the destination is simply the deest field. - mac, mux : the destination is the destination register xor 1 (that : if source is 4, the destination is 5 and vice versa) - load/store with postinc : the destination register is the pointer field (in the middle). I don't remember whether there are other exceptions (i doubt) but the write field is less critical than the read fields, which are in the decoding critical datapath. The time to perform any operation is enough to multiplex and select the written register, so it's ok. > -as i understand it, the register units reads the > 3 registers that are indicated by the fetcher, and > the decoder decides later if they need to be loaded > onto the xbar. and doesn’t if they were not > registers but flags or part of intermediate data > or the instruction is stalled. > dous this sound ok? the decoder (usually, a ROM or something hardwired and optimised like that) gives signals to the Xbar for the next cycle. then the Xbar selects what data is put on the read bus : immediate data, register set output or bypassed values. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 20 19:31:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Vyun-0000Iu-00 for ; Sat, 20 Jul 2002 20:25:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 20 Jul 2002 20:25:13 +0200 (CEST) Received: (qmail 5489 invoked by uid 0); 20 Jul 2002 17:22:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 20 Jul 2002 17:22:39 -0000 Received: by moria.seul.org (Postfix) id 1CD69146815; Sat, 20 Jul 2002 13:22:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 099C714691A; Sat, 20 Jul 2002 13:22:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id BCE8C146815 for ; Sat, 20 Jul 2002 13:22:37 -0400 (EDT) Received: from f-cpu.org (kdl11-118.n.club-internet.fr [213.44.9.118]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 470CC16B2 for ; Sat, 20 Jul 2002 19:22:35 +0200 (CEST) Message-ID: <3D399E75.5ABE4A58@f-cpu.org> Date: Sat, 20 Jul 2002 19:31:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Snapshot_jws update References: <20020719115847.99968.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > hi, > > for those interested: > > i uploaded a new Snapshot_jws of a f-cpu simulator to: > http://f-cpu.seul.org/~f-cpu/new/?M=A > > it now compiles on its own (no YG snapshot needed) > just unpack it somewhere and read jaap.txt :-) but a YG snapshot is necessary if some definitions must be changed. > biggest changes are a rewrite of the x-bar, and a > working fetcher / decoder (no scheduler yet). i would concentrate on - validation of the units - careful design and validation of the register set - and then connect the units together with the Xbar. - then comes the decoder and the scheduler queue. i have remarked that you have not integrated ROP2 in your files, however. I am trying to integrate your files in my snapshot. I also remark that EU_INC is not capable of doing SIMD operations. I have also chmod'ed the files so only scripts appear as executable (it's better for the autocompletion ;-D) Do i move the fcpusim files out of the toplevel directory ? Concerning the "clocking" : - one solution to reduce the number of temporary variables is to use the input parameters of the functions. it''s a "clean" way to rename signals :-) - another (complementary) solution is to run the pipeline in reverse order : compute the EU first and _only_then_ the Xbar operation. it saves some temporary data and code. Your code seems to be good but i hope you'll forgive the paranoid and picky remarks :-) I hope this helps and you will keep the good work up ! other remarks will come soon. read you soon, > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 20 21:11:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W1Xq-0002IR-00 for ; Sat, 20 Jul 2002 23:13:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 20 Jul 2002 23:13:42 +0200 (CEST) Received: (qmail 29400 invoked by uid 0); 20 Jul 2002 19:02:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 20 Jul 2002 19:02:28 -0000 Received: by moria.seul.org (Postfix) id 80D1F146919; Sat, 20 Jul 2002 15:02:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4664C14691B; Sat, 20 Jul 2002 15:02:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id B3842146919 for ; Sat, 20 Jul 2002 15:02:25 -0400 (EDT) Received: from f-cpu.org (kdl11-9.n.club-internet.fr [213.44.9.9]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 4195F16C9 for ; Sat, 20 Jul 2002 21:02:20 +0200 (CEST) Message-ID: <3D39B5D7.EC69293A@f-cpu.org> Date: Sat, 20 Jul 2002 21:11:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] f-cpu/c/registers/ Content-Type: multipart/mixed; boundary="------------A16ED62EC391FD55DBE95F0C" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------A16ED62EC391FD55DBE95F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, i have checked f-cpu/c/registers/ and now it seems ok. i did not yet create the big testbench but most issues are covered. - moved jaap.txt to f-cpu/c/ - chmoded files so autocompletion is easier - changed carriage returns from MSDOS to UNIX type - adressed some scheduling issues (write after read to reflect the write and read latencies) - added the flags - made the testbench to work (renamed some stuffs to reflect the right names) there is still a lot of work to do but it seems to be on the right tracks. i've been "forced" to rewrite some stuffs but i kept the old versions of the code. here is a first result (not worth uploading on seul.org yet) hope this helps. now that the registers are reviewed, i'll check something else. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------A16ED62EC391FD55DBE95F0C Content-Type: application/x-unknown-content-type-WinZip; name="registers.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="registers.tgz" H4sIABLROT0AA+xcb2wbR3ZfylKsMFZiO3Ls3CW4sRInkiNRXP6RbCmyT5YlW6lsq6RcOee4 7IpckXumuAS5lMSL0zonX2LB5zZAU8SIg9ZJv/Rbr8AhCO4K1EHSxC0K1CjQAm2/+IA0UJoc mgOMIB/cqr83s3+GFCXFsOLctRp7uft23nvz5s2bmd/Mjl3Q00bR0gvFTuVrS8FgJNgdjeJO Sa2686SAQe0KR7ojalgJqmowFFFY9OszyUuloqUVGFPK6ZX5Jozc3TDnbqeC2/7uUyC5xmUE 1WCwKxJZpv3VYLTLa/9wNAT+cAghwYJrbEfN9P+8/Tt3+xmb7EjmS51JLwQ69VJCK5YCSdbB 3Jds0iwwK6OzoY6B0eOsaEyVspplFqBgwMyXC0Y6Y7HWgTaGxguxZzQtz+KWmT3NWp8Zj7ex 788UifpuWcuYZiBpTkFuGmoNM9fD1L3smVK2LETVcE84KOfGNYuykQvGnsienmhYcE6U2Uym nNb17/IqBMxCmvWwUj6lWXoKthq5dNHvZx3LpAODh4aPdowMDwwejQ8uxyQnGDWWMYosXzDT BW2K4XGyoOusaE5aM1pB72Vls8SSWg5eS8FrBWOiZOnMsJiWS3XCfVNmypgsQw1elXIpXTgU 3p0qMnOSE4eOHmeH9Jxe0LJstDSRNZJsxEjquaLONJRMb4oZ1G6C1PDmIAvitgVsyIRezYLf epluIL/g+JGFnCJsfe2MN14rvAuzC8zMk1gbbC0ztKwnGfDXqLhXvxQzclxvxsyjMhnoQ/Vm jGyWTeisVNQnS9l2aAAvGx8eO3zs+BjrP/osG++PxfqPjj3bC14rYyJXn9aFJmMqnzWgGFUq aDmrDMuh4MhgbOAwJPoPDI8Mjz0L89nQ8NjRwXicDR2LsX422h8bGx44PtIfY6PHY6PH4oMB xuI6GaVDfgXXTvLGgf9SuqUZ2SKv8rNozCIMy6ZYRpvW0ahJ3ZiGWRpLIuJXbzHo0LJmLs0r SPHoerCXGZMsZ1rtbKZgIEQsc2lbQtprzXY2nEsG2ll0LxvT4R2djWa1JNowXiL5cDjYzg6Y 6GLgPNLPgiFVVTvUcLCbHY/3L98FkAaPHryNPkB+YZ0eTeNDIldIjAfxfh9TA4GuMLGc8Zhc FrWaxWVyWGJCS1BmsZlcFrUWC2dyWUK1Wc5UEGzVROqoXvyu3qYwc5l4sdPun6+QHKZpP9u1 Jon0rFBLe4DHVJjWVzBrZT1fPf166lkbP4vkxseShzMrvxfBQskNlCUP0yu/p6gRMatljXSO P31vMHaMPxyJH+D3Efs+NGrzxuw4p+7F7yG/f3en39+5G0PipJHTi3yASpo5REnOKrZj0M+X rCLNbAxjN3/uYRB5zMgls6WUzlo8SJlp8fshZ2FoNHJZaGPTppHyQi+RLCezeiu9bGPP0xjD gQnGyFZ3fEGGK5CY1rIl/aSbd4r12b21l71QJaiuIKi6gioJVkrGnCLJOX3LqIgFT0GS6VlM IhLzUjtiqqtNXV6bukSbWltbyNUWWl5baIm2kKMN6gDL0GIFXUsBJ/F2pLmInqmli9qU7up1 pkHM5/kCzdIWRyCCMQk4UsrqhQBNmYcYdJZL+YBbQKthPQm4YKLRTTG7n5jQCm0u8/79LusP 9IJJM7CepCmPUIaWLZpCFqUBV5kc0ZRyABj7XQ05k+V0GIT5WMt5HO0wN6kBfwCfTZGCvFYs UgSnDFJfZFMA/6KECd0uVk8FnA7IDuvAA4aI+wkdrHmacWmqTpl8Mg+ww+YMvFHwSqLCuRBs IgyVS5ZdfZj6J7L6FABXkRDT4fG29gp+Xgdon9KMHEBIjmCGBuc6OIN34smslvZ8e+x0AJIz QBEZydikZiUz+wmEAYo+aVHtOCrTtWI5EJCaiVCfgQ6NHmuxYl7XThdZb0ebazHgP+mjMtEU KGDKKBYRINUMvPcyLVkqaMmycCvKdOqBWvVwNi+adMtTgZSBRygO3SDUbecZfNiB6Y5OXoal Y6kAKK1noXqnq4kj1KwGRlhZ0l2ZopnloE1GYm7YUrjbDeNCcIpPLwwGSoUCAj4ron3SKEDr jFaW4oD73QQ2tziLqED/0NhgzK62JkXVsIDJDkKeMQtow7hZKJSpfxvgFvK8cZKoJHeKWDiQ VA800cBMQ6RwGh91q0YuthP9XDTkVxjAwEeDRCV7sLd6PFSrta48kC3RqtbUGqrWuvKAtkRr yNUKh3jh6vpEckofFcTOnBGF2y9GRtq8wnkf4/qqirEzVF6QM4P2Od56Qso4wjOcEvbtY13h NsHAHBNFV9XYhOEGH+Nvd9J7Q4QR9IigQd/OSSiN+mFWK6T54hFDYlcEejD57rfDwp7W+TjP Q6SoFyj+KVc4aVwr5CjuUZpY2JAN2gQiXJ9NQmUa3IWg6CqFkLvu534VJvX17cNoiPEEfT+j J097EUmMeRMdH+Zx/DGFvsNFnTj1kEmfExZPoJXUp58eOXboSP+J+PD3Bts61LZex1zRH5ZG +XhVlK+GDKoCb1xdXVzGB8IY0Xg0JWFgLWK1VtYt9OgZqefb477o3/YwFeAeesH/Te/3VKda +3+ZNS5j5f2/YDjU3eXs/0VU2guk/b/o+v7f3UjL7P9JwYApvj9+3Ju782bB+rXZC4zu6Qmq bGAwPibYewjZaKkUBjBu5/rm3/rm3/rm3wpBfZubfzSJPWZMIngnWQwdKA6MG08c9j8m9ggq 3nkbAU/zASaBldekkQ5k9vFdheW2DyhPn0UA5uDRoSHyszsacYbjwAjuYl9AqpDtSDE2VfBg 3naJmCsQFsh5KX+sgj/U6y/tsQEgRxO9S0vDaAOIVdS5ngputVI6JqQril5WOFYtDFMmTDPr YtFeF21FPMDrcgA7SvwjFdTQqKSaA7Feu0E8p0/o1oyO7sh3BCvdLsOkrgjhccieBM6yO0uO FsR8qWbXLdVZoh/ymUU93OStXGM3iK8iEx7QFdtBMO4xHUv2SSpHii/S8k3Pnr/5qcaUn5g2 9Jm1/Ai8Gv7r7orY+C8UidI5ATUSioTW8d/dSOhTTSsjQDscwIQOPsM/Eliloj0sFw3L2Y6j SZSr+drR4BpiuqY1AnVNa4TqmtYC1jV9NVzX5K9V+9tEdk13DO2a7hTbNd0muBP1vmN413Rn +K5p7QBe0xoivCZAPHKQh92KVsowAdrkd5Po5ujlYmggPFf1NYfei9n7eT9gBUca9C6RzFl8 GyZfwOvJ1hYJ2bXy78JtjLW00VYLNVurLNen9srk012RCvqpp1CW2GUXqneFTvS1tMssXC9j 6da2Xo9L7cpmT7S019oAcuROgT/Xaku7O4pOLtvFIm19fWH6HuNofS6HSrAX7A8vzlvGX0LL C54HUF0PH/YRQ6V5oRMtrN37HuUa4up0NmxryIqqCfEasijZA7arFD2+fNE1ZeWia8k+l/OA 7mq1VpevdS3ZilovlZVrvVrR48sXXVNWiqWaslKtQ6vVOrR8rWvJykXXkuURSRuQSPL8L034 pdyUHiiu9eafIvDfiuc/u7ur8F8oqkbW8d/dSH5/OplkHZig9KIlrb06hgOd9BPoxF973O+s YgIo/KbNX093mLz+X922a1fGqvv/Yaf/R6KRSFis/9T1/n830qr7/3QEmEKjWPEFv3jnSzt3 J18NMzXSE97bEwxW7OSLL+1Udg2hUBB/SSjaXb39L75gFllWt2ApB21JzV4IaFi8mMlkqaDn kjpfn7XEBg8lMHHyYyAFnR/xSHGhlqr9qBYB9D3MKg4ttax/Ylj/xLD+iWGtFqD2J4bq1af0 Shqb9jE/X1/SSaNWetAK6WQ7jQAFtns3iGn7NGH1elPswdPY0iOQsbQUouMNLBR23vEX/F1w VgVCDUcjXdHurj3de/cER0ZkSZVzRaOupOpJBvfs7d7T1R3tikTDkVBYdSUrzj9WQPaltvKD cDaSr8Fnt3SNSsWCVaY556jtky7eUZyKui9vGw2aWHOKZQcKsxcewaVM6hImdSlTaAlTSKxW vunp8f988qb82GD/wSODAWvWWusyVsF/ajjq4r9uVQ2K9V/3Ov67G2kp9PPiwJ/EyEPTbyXo ikR6olEJdNX4R1h+/1jVcU9x3i2vFSwjWcrC4/ToTHB5I6/TZ8CAH/M6nQXVap8G5TMinQXm I1KAFyJO9eriWBw/KKxZ7iFOYMBpPRtgw5Y4YmsxyGkFv3xmyzto6iAK+/uFwB0DmKnt83JF OnvZ4ZyZI22kh59/IyjBT4bZZ+TFCWMqtBVjL+Z+DK372/z2cVk6IchPxCEfuPi0OPZLOV1h zOMThusZx4X8+Kg4OMitdA/s0XdW9wghPyiohvY85QAru05aPq/zE60djlI6ILjUAjp+HeDw jB+aFsgEICxNZw01PGl5sgMNxEEH7lBjO5YQlT4lDobv3LnTKavyCGBROkdunm7niE2cHwTv FJU8o5UJGrle5oCWkNoUsAeWBFk6EGymtDIwMaHAok7ndmE7naN1CrXnSt1ucpM+SE+VkpnA +nxSnZZb/69lGSvv/6nAQ6Gqf/8dCa6P/3cn/cHgyJDP53PpOmWDQtTmufrGCO7X7C4TUZhy j9KqfFvZgTvRuM6CB9dVPNPVgKse1wZcN+lCHl0P4vlBO89nXzwhj67zGxWFLpJXNot8/u41 5OHahBevQuk9dn4dbm8g/w3k0XWN7FREfr19NUKm8cX6RroYaCbldWaNic5sqgNTTmk2UDQD IfF+s20b1lu2L7xEddpol7HBrquTfBJv/TJ+/i1c139Y37gb9xZcW3HdAL3Lpvfi+hz0e3be fSSENgjZNMkpL9c3kv4tyv2KJummuimoU5Lq0qUIZK0kElj+Ox+1JrEk1BNGbtJUEsPHErSq yiXoWA7YSDJBvcBK0DoKb2qKJdJTZs7mSyiHRoYPDCRCgSCvu/gj2tYn4se2bbNhNBFH3qZf uVTfeA+ceBb3jWA8R3c47zzd4dgf0x2VPD7/H3OfNccXSObki+9d36YoC+fwvHAfhBY+BufJ vyNfLUZnIbG46wx+iXdxF2nmHzE+ubGItItKyFDeJ9c5TSVlyLxPrnKaSszsIPonINVf/u78 L+Y++nx0LJa58RJyLqFRfvt3Msq5+saFvwHDzfkvqmyLwLYLc4+A+NFVq27xOgyb/+IVO3He xrm+VxGnSmnfp1vffAVPF0fr57fRwwVl8Tp/M7dHKX30DkUElDTNvX8zcwlvF/pQ4ocNJExO nf/s1HsXp4VvGomwbWl857oQ3Dr3/peZK1QhLv1f/7O4uETm4k+fIMMv/vWTdLPtQ3n1iK6F X0Ji7v3NHzTsuFzfuP3NWby7sO0Mfv/8o9frG+e3LeD3g4ZmZHa/eZZnnqPM+suU2Yjfhdco bqHuYVL3p0Id0SGi/9BRfxU2dn/QcAPqlA8aFCps4RSXvPXmpsukdzN+Y6OZwyQ27qi59eZn r1Pm56/zzHHK7PEyv+SZt0TmJGU+KjJdX8XP9lHRitX6wNvciIvNf0tueOcGni+M1NVfaK6b 30YWzDeRBZ82f9hAFPF82LDZfjrbxw3nSuipphKydL6JLCUlRAkln7/uKKFqK1YHlNBTTSVf ciVUo08ffuWi9QTkv3Q13XI1iTo9yF13HzcTwVD/6db5Lz5ouElcn95vN7ugfVeI83HfWw+T r5u4xx8lsflr8/82f139p3cXvnP+3bO/8J1veugytfg2MvUKVeLxjW9tB3G2bwe3/okH3t5G Txfr/5nU/4xb30TBcuFRCpb5TZvnn9tcf7av2WVvXsJez8un8LHZL5y6Jcdtc/znKTDO9dHv orXpwobF63Pv3ZrrXSzdPCn3g2Xi2+ur57dgCFpI31pcRC/dwMerOqXGppC/xku+upAypO0W v1KxIWKTaiUZcklqs3JmfCj6+IPqgXiq9NJrjc5YnrfHMUXx5spNuGgYaqI54yUxB7RiXqM5 6BruNCedwJ0U/8CeO2iA22broXpa0FtnzxXNfA5RlO24ZqGXnvO40zxDhT9o39F3zFG8xxhk kh2f437gh559XzXRMCvfac528v4F+j7G9QWue+Zq6D40MNDDWjElt7FQYG80wP/nDzUYVqN0 PIT/E6S233Aup9Lk46AaADJW7so7JVAsT1naBO5WQdwzzhM/DJxXAlhA6YH+A8MdlpZWAlib Z5RAqpyDoLhbBSWQzpUC9oKzgkggD5UMpE1LPOSzFmk28Gvps/idBIEsrOcsDfr4r54RsIPr 16aMpBJIWiZWJIGUuE0U8ZM0p2hVKQy8jVj8tuLhNY5PFRHvTnKw6WOKwHvEx3Gkz8ZZdnJw HvmxweajPtkKvqCU72DObkX0S+KjvnoCfHlb1qd4+HO/Ivor8VHfvuYTfbravkMK708m8VGf PICH+6Vy6+xrTBH9mJ6pL4/WiXrI5VKiz7332jI0FuTrRMxQfrN9Jzor8dHYMVvnYev7JL6S rZ/GJhq7LoFvVw3/5SW+q+C7Cr7RKj66npf4aG2yGU66vsHjc/DmixIfjZU38PBIjXJfVrw4 uAW+W+D7cQ2+P7L5qCi+HtnolSXz/YnER9jr0sbKtYDz/GeKt4bg65eNYu3SIPGR//5C0kez XqrR68Oyvr+U+LLgyy7Dl5b4aC6wGpfGM11v2+UTHwHJKyDOSAshR+bnirSOI17wfSTRTt77 iuhHTjqH4JmtwbfFLtNJt8D39zX45LUWTw8ghuC8b+Exqnj96N4qfXkE8VuSoGx7daJxQeHy gov6v6CFglaXFiWccGnh7WsuLVrVmTM3iBUs74eCFp7Ju7RouVmXvpfTl1xaLMavujRfJfL+ IOhNnKa4F3QTp2+59P2cPv+aQz8g9Lu0iOw3XHoLp1OXHHorp7MuLUZOy6WbOX3FpR0EItIG 5aEqensVvaOKfriK/hZvkYiLEzZxj8n0domus/N/T8onUPiKXT8f6v+UVB8f6kPr8Fel/EFJ nvSdlPzlg79oU+inUn7Zrv8Onr9NmcP9qpRP48mCRL9eoe8B3u9Trj1buf1XXvLsf1uiSf4f cM9I/KT/2kvL6/9XxcOYVN+Pq+pDDzek8m5K/q9XfrXIM855+Q1okM9A/5VPlLcNd1qNUDtt Qf2/gwcC+dR1iA74vPjagj/dvsp9EZoXaUnlyE/ggVYTjTZt+EQ8O/sgeSpfyp8BfVOSP4uH L6X8l31ef9qK/nTRV7kP8xMSvOzJ/8zn9a+tqN+7oGm54uij+XmTRP8j7VVdcur3q8V/9wl/ /actf8NXuc/z36CbpfL4XojtH4b22kpDjrQP9Hid1z5b0b93g94myat1leXvqfP65xb0z6Og H7ns5cdBPyTJnwS9XaJ1Kl/ad7JA75Dyf1+ydzPsvQD6YSn/j6vnjhGdQ790MhlKAMTlDfrH 8UpSy2alDSYlHwgricTBsWOxxMhwfCyRUIg3q9P/zxKhrS0zkc6aE1o2wUFhQivN4u3g4cRQ rP/IYIIfvIEQ4ctEqjQ1VVbMie/rSSugqorY1BJvCYzaj5NmIaknLDPBYWgiMSAVLheYlArk PINHD3KWgzIh7BDUkpN1VZ/WFfcrvZsjTqEriYPPHu3/3/btIAdBGIjC8JzJEwAGiEkNC9nP Rgwr487rO3RKMU09gMn/7Qi0hHZTXjvXy7meyTXNkcLlTX3xMwuij5eub/Edd9mrBv36JBpX 4T8iwlq/1sRnxg82eD/2FrXVeLqTwsMiTqx0Zs23Md6nOsaV349p/C3wXSrRxedjDFPXBp2G 4dbPOrdd6G2cl+ddUr2j5HLGMuLMJzu2Dz5enCojy2QTAAAAAAAAAAAAAADgv3wASqBhEgB4 AAA= --------------A16ED62EC391FD55DBE95F0C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gertom_fcpu@yahoo.fr Sat Jul 20 23:30:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W4iu-0004cH-00 for ; Sun, 21 Jul 2002 02:37:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 02:37:20 +0200 (CEST) Received: (qmail 30219 invoked by uid 0); 20 Jul 2002 21:30:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 20 Jul 2002 21:30:35 -0000 Received: by moria.seul.org (Postfix) id DCABE14691A; Sat, 20 Jul 2002 17:30:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A064D14691C; Sat, 20 Jul 2002 17:30:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by moria.seul.org (Postfix) with SMTP id BB7A614691A for ; Sat, 20 Jul 2002 17:30:30 -0400 (EDT) Received: from mix-montpellier-211-4-184.abo.wanadoo.fr (HELO thomas) (gertom?fcpu@80.9.115.184 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jul 2002 21:30:27 -0000 From: "GerTom" To: Subject: RE : [f-cpu] Snapshot_jws update Date: Sat, 20 Jul 2002 23:30:00 +0200 Message-ID: <000301c23034$9cd25d60$b8730950@thomas> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C23045.605CB400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20020719115847.99968.qmail@web14208.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C23045.605CB400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello I'm reading this mailing for ~1 month, trying to understand! It's a great project and I wonder how I can help. (I'm not a VHDL boss :-( ) I downloaded jaap's last snapshot and saw he required help about this: - how do i read a key from stdin in linux ? (I can only do it if i press after each key) Just add getkey.c file in /toplevel And the updated fcpusim_view.c Test and give feedback! Thomas ------=_NextPart_000_0004_01C23045.605CB400 Content-Type: application/octet-stream; name="getkey.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="getkey.c" /*=0A= getkey.c=0A= Copyright (C) 2002 Thomas Geroudet gertom_fcpu@yahoo.fr=0A= version: 20 July 2002 19:00=0A= =0A= = ------------------------BEGIN-LICENSE------------------------------------=0A= This program is free software; you can redistribute it and/or modify=0A= it under the terms of the GNU General Public License as published by=0A= the Free Software Foundation; either version 2 of the License, or=0A= (at your option) any later version.=0A= =0A= This program is distributed in the hope that it will be useful,=0A= but WITHOUT ANY WARRANTY; without even the implied warranty of=0A= MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the=0A= GNU General Public License for more details.=0A= =0A= You should have received a copy of the GNU General Public License=0A= along with this program; if not, write to the Free Software=0A= Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA=0A= = ---------------------------END-LICENSE-----------------------------------=0A= */=0A= =0A= =0A= =0A= #include =0A= #include =0A= =0A= =0A= int kbhit();=0A= int getch();=0A= int getkey();=0A= =0A= /*=0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= Function : main : self test=0A= =0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= */=0A= /*=0A= int main()=0A= {=0A= int key;=0A= =0A= printf( "Press a key...\n[q] to quit (not [Q] !)\nDo *not* try = [CTRL]+[s] (you've been warned !)\n" );=0A= =0A= while ( ( key =3D getkey() ) !=3D 113 )=0A= {=0A= printf( "%i\t'%c'\n", key, key );=0A= }=0A= return ( 0 );=0A= }=0A= */=0A= =0A= =0A= /*=0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= Function : getkey=0A= =0A= In : void=0A= =0A= Out : int : ascii val of the pressed key=0A= =0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= */=0A= int getkey()=0A= {=0A= int key;=0A= =0A= // waiting for a key to be pressed=0A= while( ! kbhit() );=0A= =0A= key =3D getch();=0A= =0A= // emptying buffer=0A= // some keys like arrows, etc... returns an escape sequence with 3 or = 5 characters=0A= // i don't know what could happen if some characters remain in the = buffer=0A= // maybe some unexpected result :-(=0A= while ( getch() !=3D -1 );=0A= =0A= return( key );=0A= }=0A= =0A= =0A= /*=0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= Function : kbhit returns keyboard status=0A= =0A= In : void=0A= =0A= Out : int : 1 if a key has been entered=0A= 0 if nothing happened=0A= =0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= */=0A= int kbhit()=0A= {=0A= struct termios term, old_term;=0A= int fd =3D 0;=0A= int c;=0A= =0A= // getting term info=0A= tcgetattr( fd, &old_term );=0A= =0A= // copying term info before modifying it=0A= memcpy( &term, &old_term, sizeof( term ) );=0A= =0A= // selecting automated mode (non-canonical)=0A= // waiting until the first of these two events :=0A= // 0.1s elapsed=0A= // key pressed=0A= term.c_lflag =3D term.c_lflag & ( ! ICANON );=0A= term.c_cc[ VMIN ] =3D 0;=0A= term.c_cc[ VTIME ] =3D 1;=0A= // TCSANOW means changes applies immediately=0A= tcsetattr( fd, TCSANOW, &term );=0A= =0A= // reading a character=0A= c =3D getchar();=0A= =0A= // restoring term info=0A= tcsetattr( fd, TCSANOW, &old_term );=0A= =0A= // if a key has been pressed, we re-put c in stdin=0A= if ( c !=3D -1 )=0A= {=0A= ungetc( c, stdin );=0A= return( 1 );=0A= }=0A= else=0A= {=0A= return( 0 );=0A= }=0A= }=0A= =0A= =0A= =0A= /*=0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= Function : getch returns the ascii val of the last pressed key=0A= =0A= In : void=0A= =0A= Out : int : ascii val of the pressed key=0A= -1 if there were nothing in buffer=0A= (non-ascii keys such as arrows, etc... returns an escape sequence)=0A= =0A= ---------- ---------- ---------- ---------- ---------- ----------=0A= */=0A= int getch()=0A= {=0A= int c, fd =3D 0;=0A= struct termios term, old_term;=0A= =0A= // getting term info=0A= tcgetattr( fd, &old_term );=0A= =0A= // copying term info before modifying it=0A= memcpy( &term, &old_term, sizeof( term ) );=0A= =0A= // selecting automated mode (non-canonical)=0A= // waiting until the first of these two events :=0A= // 0.1s elapsed=0A= // key pressed=0A= term.c_lflag =3D term.c_lflag & ( ! ICANON );=0A= term.c_cc[ VMIN ] =3D 0; //1=0A= term.c_cc[ VTIME ] =3D 0;=0A= tcsetattr( fd, TCSANOW, &term );=0A= =0A= // reading the character=0A= c =3D getchar();=0A= =0A= // restoring term info=0A= tcsetattr( fd, TCSANOW, &old_term );=0A= =0A= // returning ascii val of the pressed key=0A= return c;=0A= }=0A= =0A= ------=_NextPart_000_0004_01C23045.605CB400 Content-Type: application/octet-stream; name="fcpusim_view.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fcpusim_view.c" /*=0A= f-cpu/c/toplevel/fcpusim.c=0A= view status and menu interface for F-CPU simulator Copyright (C) 2002 Jaap Stolk (JWS) jwstolk@yahoo.com version: 19 July 2002 13:30=0A= = ------------------------BEGIN-LICENSE------------------------------------= This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA = ---------------------------END-LICENSE-----------------------------------= */ #include #include =0A= =0A= #include =0A= =0A= #include =0A= #include =0A= #include =0A= #include #include =0A= =0A= #include =0A= =0A= void g(void){=0A= /* if (use_colors){ */=0A= printf("%c[1;33;44m",0x1B);=0A= }=0A= =0A= void n(void){=0A= /* if (use_colors){ */=0A= printf("%c[0;37;40m",0x1B);=0A= }=0A= =0A= void status_view(void){=0A= printf("\n");=0A= printf("________________________________________");=0A= printf("_______________________________________\n");=0A= printf("status after cycle ");=0A= g(); printf("%d" , cycle_counter); n();=0A= printf(" :\n");=0A= if (view =3D=3D "f"){ fetcher_view(); }=0A= if (view =3D=3D "r"){ registers_view(); }=0A= if (view =3D=3D "x"){ xbar_view(); }=0A= if (view =3D=3D "a"){ eu_asu_view(); }=0A= if (view =3D=3D "i"){ eu_inc_view(); }=0A= }=0A= =0A= =0A= void menu(void){=0A= int do_next_cycle;=0A= do {=0A= status_view();=0A= printf("f=3Dfetcher r=3Dregisters x=3Dxbar a=3Dasu i=3Dinc = =3Dnext_cycle q=3Dquit ");=0A= c =3D getkey();=0A= printf( "\n" );=0A= do_next_cycle =3D 0;=0A= if (c=3D=3D10 ) { do_next_cycle =3D 1; }=0A= if ((c=3D=3D'f')|(c=3D=3D'F')) { view =3D "f"; } /* fetcher */=0A= if ((c=3D=3D'r')|(c=3D=3D'R')) { view =3D "r"; } /* registers */=0A= if ((c=3D=3D'x')|(c=3D=3D'X')) { view =3D "x"; } /* xbar */=0A= if ((c=3D=3D'a')|(c=3D=3D'A')) { view =3D "a"; } /* asu */=0A= if ((c=3D=3D'i')|(c=3D=3D'I')) { view =3D "i"; } /* inc */=0A= if ((c=3D=3D'q')|(c=3D=3D'Q')) { quit_fcpusim =3D 1; do_next_cycle = =3D 1; printf( "\n" ); }=0A= } while (do_next_cycle=3D=3D0);=0A= }=0A= =0A= =0A= =0A= ------=_NextPart_000_0004_01C23045.605CB400-- ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.comm ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 21 00:04:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W4iy-0004cH-01 for ; Sun, 21 Jul 2002 02:37:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 02:37:24 +0200 (CEST) Received: (qmail 4935 invoked by uid 0); 20 Jul 2002 22:04:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 20 Jul 2002 22:04:30 -0000 Received: by moria.seul.org (Postfix) id 5368E14691E; Sat, 20 Jul 2002 18:04:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01343146920; Sat, 20 Jul 2002 18:04:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id F129514691E for ; Sat, 20 Jul 2002 18:04:27 -0400 (EDT) Message-ID: <20020720220427.84091.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.38] by web14202.mail.yahoo.com via HTTP; Sat, 20 Jul 2002 15:04:27 PDT Date: Sat, 20 Jul 2002 15:04:27 -0700 (PDT) From: jaap stolk Subject: Re: RE : [f-cpu] Snapshot_jws update To: f-cpu@seul.org In-Reply-To: <000301c23034$9cd25d60$b8730950@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, thanks GerTom, i will try it ASAP. some info on my situation: i live +/- 100 km NE of amsterdam. this week has been a bit hectic ( my brothers wedding), but i played around with a simple scheduler/scoreboard this morning. im 24 and a (nearly finished) electronics student. i'm running a w98/rh7.1) dual boot AMD 1200 now, and have little(non) experience with programming under linux. however, i programmed for as long as my living memory, in gw/q-basic, lots of pascal and some c(++). that includes thinks like a 3D engine, a very useful "windows" simulator, in pascal, and also pascal mixed with assembler for thinks like as spectrum analyser and a (dos) multithreading server. (and 1001 other less useful thinks) all your responses are very helpful, and a will let you know more when i have read / tried it all. sorry for the dos-text formatted files (and the capital "S" in my last upload). i somehow cant get my modem to work under linux ... is it ok if i convert the files to unidentified-unix using emacs ? what tab standard do you use ? (i prefer not to use tab's at all) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 21 01:51:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W4j3-0004cH-00 for ; Sun, 21 Jul 2002 02:37:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 02:37:29 +0200 (CEST) Received: (qmail 31582 invoked by uid 0); 20 Jul 2002 23:42:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 20 Jul 2002 23:42:05 -0000 Received: by moria.seul.org (Postfix) id 072FE14691F; Sat, 20 Jul 2002 19:42:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1F8C146922; Sat, 20 Jul 2002 19:42:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 7B0C114691F for ; Sat, 20 Jul 2002 19:42:04 -0400 (EDT) Received: from f-cpu.org (kdl16-110.n.club-internet.fr [213.44.18.110]) by relay-5v.club-internet.fr (Postfix) with ESMTP id E19211698 for ; Sun, 21 Jul 2002 01:42:21 +0200 (CEST) Message-ID: <3D39F765.6713D02D@f-cpu.org> Date: Sun, 21 Jul 2002 01:51:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: RE : [f-cpu] Snapshot_jws update References: <20020720220427.84091.qmail@web14202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! seems this idea of a SW C simulator triggered some interest. At least it will help people better understand that VHDL is not an impossible langage. thanks for the getkeys trick, btw :-) jaap stolk wrote: > > hi, > > thanks GerTom, i will try it ASAP. > > some info on my situation: > i live +/- 100 km NE of amsterdam. i live +/- 10km east from Paris... But it seems that there is a lot of people around the Benelux region, which is cool :-) > this week has been a bit hectic ( my brothers > wedding), but i played around with a simple > scheduler/scoreboard this morning. have a look at all the files provided in the YG snapshot, it contains the rough algorithm for managin the slots. it's not very clear but at least that's the idea. > im 24 and a (nearly finished) electronics student. > i'm running a w98/rh7.1) dual boot AMD 1200 now, > and have little(non) experience with programming > under linux. fortunately i have a bit more experience with Linux (i'm doing a customized Linux From Scratch distro, after all the problems i had with the other commercial distros) but i'm far from being a guru. i work on the algorithms only and system programming makes C programs non portable. and i hate C btw :-) > however, i programmed for as long as my living memory, > in gw/q-basic, lots of pascal and some c(++). > that includes thinks like a 3D engine, a very > useful "windows" simulator, in pascal, and also > pascal mixed with assembler for thinks like as > spectrum analyser and a (dos) multithreading server. > (and 1001 other less useful thinks) it seems that you have followed a path similar to this of many other people (inc. me)... > all your responses are very helpful, and a will let > you know more when i have read / tried it all. i don't know yet, but i'll try to fix ASU and INC whenever i can. then i'll try to find a solution for the tests. > sorry for the dos-text formatted files (and the capital > "S" in my last upload). i somehow cant get my modem > to work under linux ... i know this symptom very well :-) > is it ok if i convert the files to > unidentified-unix using emacs ? > what tab standard do you use ? (i prefer not to > use tab's at all) Michael is picky about his tabs but i indent with 2 spaces. btw, http://f-cpu.seul.org/daCode/board/ is a meeting point where some of the F-CPU people chat about things and else... it's active around 1AM (GMT) :-) > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jul 21 02:14:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W4j6-0004cH-00 for ; Sun, 21 Jul 2002 02:37:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 02:37:32 +0200 (CEST) Received: (qmail 2930 invoked by uid 0); 21 Jul 2002 00:14:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 21 Jul 2002 00:14:16 -0000 Received: by moria.seul.org (Postfix) id 38559146920; Sat, 20 Jul 2002 20:14:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0BB93146923; Sat, 20 Jul 2002 20:14:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a039.home.uni-hannover.de [130.75.232.39]) by moria.seul.org (Postfix) with ESMTP id 97CE1146920 for ; Sat, 20 Jul 2002 20:14:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02537; Sun, 21 Jul 2002 02:14:08 +0200 Message-ID: <20020721021408.05470@thrai.stud.uni-hannover.de> Date: Sun, 21 Jul 2002 02:14:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: RE : [f-cpu] Snapshot_jws update References: <20020720220427.84091.qmail@web14202.mail.yahoo.com> <3D39F765.6713D02D@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D39F765.6713D02D@f-cpu.org>; from Yann Guidon on Sun, Jul 21, 2002 at 01:51:01AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 21, 2002 at 01:51:01AM +0200, Yann Guidon wrote: [...] > > is it ok if i convert the files to > > unidentified-unix using emacs ? > > what tab standard do you use ? (i prefer not to > > use tab's at all) > Michael is picky about his tabs but i indent with 2 spaces. I prefer 1 tab (which is 4 spaces in my editor). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 21 02:28:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17W4j7-0004cH-01 for ; Sun, 21 Jul 2002 02:37:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 02:37:33 +0200 (CEST) Received: (qmail 20449 invoked by uid 0); 21 Jul 2002 00:19:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 21 Jul 2002 00:19:45 -0000 Received: by moria.seul.org (Postfix) id F3773146971; Sat, 20 Jul 2002 20:19:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9D78146973; Sat, 20 Jul 2002 20:19:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 74D6F146971 for ; Sat, 20 Jul 2002 20:19:43 -0400 (EDT) Received: from f-cpu.org (kdl16-110.n.club-internet.fr [213.44.18.110]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BE6381696 for ; Sun, 21 Jul 2002 02:20:01 +0200 (CEST) Message-ID: <3D3A0038.848B42A4@f-cpu.org> Date: Sun, 21 Jul 2002 02:28:40 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: RE : [f-cpu] Snapshot_jws update References: <20020720220427.84091.qmail@web14202.mail.yahoo.com> <3D39F765.6713D02D@f-cpu.org> <20020721021408.05470@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > > On Sun, Jul 21, 2002 at 01:51:01AM +0200, Yann Guidon wrote: > [...] > > > is it ok if i convert the files to > > > unidentified-unix using emacs ? > > > what tab standard do you use ? (i prefer not to > > > use tab's at all) > > Michael is picky about his tabs but i indent with 2 spaces. > I prefer 1 tab (which is 4 spaces in my editor). this confirms that :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 21 04:48:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WIOs-0005Vr-01 for ; Sun, 21 Jul 2002 17:13:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 17:13:34 +0200 (CEST) Received: (qmail 17755 invoked by uid 0); 21 Jul 2002 02:48:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 21 Jul 2002 02:48:33 -0000 Received: by moria.seul.org (Postfix) id 39BE1146922; Sat, 20 Jul 2002 22:48:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 11C73146924; Sat, 20 Jul 2002 22:48:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 6B954146922 for ; Sat, 20 Jul 2002 22:48:30 -0400 (EDT) Message-ID: <20020721024829.14632.qmail@web14205.mail.yahoo.com> Received: from [130.89.243.38] by web14205.mail.yahoo.com via HTTP; Sat, 20 Jul 2002 19:48:29 PDT Date: Sat, 20 Jul 2002 19:48:29 -0700 (PDT) From: jaap stolk Subject: Re: RE : [f-cpu] Snapshot_jws update To: f-cpu@seul.org In-Reply-To: <3D39F765.6713D02D@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Yann Guidon wrote: > seems this idea of a SW C simulator triggered > some interest. don't spent to mutch time on a simulator, a real F-CPU would be a lot nicer :-) to make sure we don't spend to much time doing the same thing, i tried to implement all suggestions, and reply to all questions ASAP. i also uploaded a new snapshot_jws. >about ncurses: looks very useful, but i will save it till the simulator needs more user input. (dous a simulator need any input, apart from selecting different views?) i now use a gnome x-terminal of +/-60 lines, so i can see the last state as well. >getkey.c: i'll use it until i start on ncurses. it was just what i needed. thanks Thomas. i made some changes: -changed carriage returns from MSDOS to UNIX type -moved jaap.txt to f-cpu/c/ -only scripts appear as executable -added YG's register .c / .h and test_registers.c -reordered register.h -added flags to register_view.c -added "print(true/false)" function -created /c/fcpusim/ and split the files into: toplevel.c -> link al units (i.e. simulate) fcpusim.c -> interface, (was fcpusim_view.c) -added getkey.c todo: -make more connections between units stall-able. -add counters for IMUL and IDIV to scheduler. -and a lot more.. and some more reply's: >but a YG snapshot is necessary if some definitions >must be changed. i'm still using a YG snapshot to change definitions i will try to add the script soon. >i would concentrate on > - validation of the units > - careful design and validation of the register set > - and then connect the units together with the Xbar. > - then comes the decoder and the scheduler queue. but it's more fun to do it all at once :-) >i have remarked that you have not integrated ROP2 i (or YG?) will do it soon. connecting EU's is easy. >I also remark that EU_INC is not capable of doing SIMD >operations. .. as well as a lot of other things. supporting SIMD is not on the top of my list... i just looked at GMP, would this we useful for doing 64 / 128 / 256 bit ? > "clocking" / reduce temporary variables.. i spotted the possibilities, and there are a lot of other things that can improve speed, but for now i like the "clocking" / "copying" because it's easy and clear. i now shift the scoreboard every cycle, how is that for slow simulation! :-) as soon as it is (mostly) working a will take a closer look at speed. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 21 13:50:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WIP2-0005Vr-00 for ; Sun, 21 Jul 2002 17:13:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 17:13:44 +0200 (CEST) Received: (qmail 3156 invoked by uid 0); 21 Jul 2002 11:41:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Jul 2002 11:41:42 -0000 Received: by moria.seul.org (Postfix) id A98F0146923; Sun, 21 Jul 2002 07:41:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 841A7146927; Sun, 21 Jul 2002 07:41:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1AD8C146923 for ; Sun, 21 Jul 2002 07:41:36 -0400 (EDT) Received: from f-cpu.org (kro1-64.n.club-internet.fr [213.44.93.64]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 57D901694 for ; Sun, 21 Jul 2002 13:41:33 +0200 (CEST) Message-ID: <3D3AA00A.C68F14DE@f-cpu.org> Date: Sun, 21 Jul 2002 13:50:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] stimulib : C version seems to work Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, tonight i hacked a small C utility that manages test vectors. it works with plain HEX files and uses the stdio.h capabilities (fscanf and fprintf). It should also work in VHDL with the TEXTIO package, but it's not coded yet. i think i have reached a compromise between compactness, speed (it's small, so i coded it quickly and it should reuse the libc) and compatibility. By avoiding most features (not even comments) it fits in a few hundreds of lines (overall) and it works. I am playing currently with the ROP2 unit (which i have to cleanup again for the XXXth time) and i'll finish the test vectors when the VHDL version will be ready. Here is how it works (general workflow) : - there is a vector generator (in C) that outputs a HEX file. - the testbenches (C or VHDL) include the DUT (Design Under Test) and borrow some functions and stuffs from stimulib to import the vectors from the HEX file. - The inputs are fed by the testbench/wrapper to the DUT and the results are compared (still inside the testbench) with the provided expected results. The good side is that the original vectors can be generated in any langage. If there is no pipeline stage, one can even merge vectors or modify them with a text editor (to inject errors). The vectors can be reasonably big (thousands of cycles). The bad side is that when there is an error, it's harder to track (no comments -> no debug info in the hex files). Though i could have implemented this, it is not the most required feature (all we want is it to work, no ?). i'll upload another snapshot whenever i finished the VHDL side. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 21 14:21:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WIP3-0005Vr-00 for ; Sun, 21 Jul 2002 17:13:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 21 Jul 2002 17:13:45 +0200 (CEST) Received: (qmail 3866 invoked by uid 0); 21 Jul 2002 12:12:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 21 Jul 2002 12:12:30 -0000 Received: by moria.seul.org (Postfix) id A52E6146924; Sun, 21 Jul 2002 08:12:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6B013146927; Sun, 21 Jul 2002 08:12:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id EAFE0146924 for ; Sun, 21 Jul 2002 08:12:28 -0400 (EDT) Received: from f-cpu.org (kdl16-31.n.club-internet.fr [213.44.18.31]) by relay-2v.club-internet.fr (Postfix) with ESMTP id D6D0D16B6 for ; Sun, 21 Jul 2002 14:12:25 +0200 (CEST) Message-ID: <3D3AA746.1007D90F@f-cpu.org> Date: Sun, 21 Jul 2002 14:21:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: RE : [f-cpu] Snapshot_jws update References: <20020721024829.14632.qmail@web14205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! just before i fall asleep... jaap stolk wrote: > hi, > > --- Yann Guidon wrote: > > seems this idea of a SW C simulator triggered > > some interest. > don't spent to mutch time on a simulator, a real > F-CPU would be a lot nicer :-) i am working on a model, be it in VHDL or C... i am also continuing the work on a C version (i did that before but the method was flawed). > to make sure we don't spend to much time doing the > same thing, i tried to implement all suggestions, > and reply to all questions ASAP. > i also uploaded a new snapshot_jws. i gotta check it now ;-) > >about ncurses: > looks very useful, but i will save it till the > simulator needs more user input. (dous a simulator > need any input, apart from selecting different views?) > i now use a gnome x-terminal of +/-60 lines, > so i can see the last state as well. i'm working in text mode, but in a 800*600 framebuffer with 8*8 font : i got 75 lines and 100 columns ;-) > >getkey.c: > i'll use it until i start on ncurses. > it was just what i needed. > thanks Thomas. i can't find anything about it on my linux box. where and how is it provided ? is it outside of the libc ? > i made some changes: > -changed carriage returns from MSDOS to UNIX type > -moved jaap.txt to f-cpu/c/ > -only scripts appear as executable > -added YG's register .c / .h and test_registers.c > -reordered register.h > -added flags to register_view.c > -added "print(true/false)" function > -created /c/fcpusim/ and split the files into: > toplevel.c -> link al units (i.e. simulate) > fcpusim.c -> interface, (was fcpusim_view.c) > -added getkey.c wow, i gotta upgrade my snapshot again... > todo: > -make more connections between units stall-able. maybe i'm too low-level, but what's the use of connecting things that are not yet working ?... the Xbar is a difficult design so be careful. > -add counters for IMUL and IDIV to scheduler. ? since IMUL can be pipelined, there is no need of a counter is the Scheduler Queue : the queue must be as deep as the IMUL unit (as IMUL is the largest pipelined unit). there would be only one counter (for IDIV). > -and a lot more.. let's make things work and verify them :-) > and some more reply's: > > >but a YG snapshot is necessary if some definitions > >must be changed. > i'm still using a YG snapshot to change definitions > i will try to add the script soon. beware ! i found a typo on f-cpu_types.h. a comment is not closed. > >i would concentrate on > > - validation of the units > > - careful design and validation of the register set > > - and then connect the units together with the Xbar. > > - then comes the decoder and the scheduler queue. > but it's more fun to do it all at once :-) maybe, until you see that nothing fits with the rest... of course, it's interesting to "play" with the units, in order to see how it works as a whole. but it won't work correctly without some planification. Even though this planification needs one to try things, but these attempts can't work as is. That's why my last attempt was called "QDCPOC" and as a result, i started coding the langage-independent configuration engine with m4... Now i continue the work by adding another functionality (the cross-langage tests). When all the tools will be ready, we will be able to make really good code (at last) that will require less maintainance. > >i have remarked that you have not integrated ROP2 > i (or YG?) will do it soon. connecting EU's is easy. i'm doing this currently, simply because i usually maintain this small (but interesting) part and i integrate new tools this way... > >I also remark that EU_INC is not capable of doing SIMD > >operations. > .. as well as a lot of other things. > supporting SIMD is not on the top of my list... > i just looked at GMP, would this we useful for doing > 64 / 128 / 256 bit ? GMP is huge and not really useful (we don't care about 99% of the functionalities). all we need is a compile-time precision (while GMP is dynamic) and a dozen of functions (add, copy, or, and, xor, not...) on SIMD data... > > "clocking" / reduce temporary variables.. > i spotted the possibilities, and there are a lot of > other things that can improve speed, but for now i > like the "clocking" / "copying" because it's easy and clear. > i now shift the scoreboard every cycle, how is that for > slow simulation! :-) not a big problem however. "Alles is relativ" : if you don't shift something, something else has to move... > as soon as it is (mostly) working a will take a closer > look at speed. :-) my worries now (as always) : - make it work - make it perfectly clean (absolutely kludge-free) - make it scalable (no need to hack it when something else changes) - and prove it, whatever the langage. That's why i spend a lot of time tidying stuffs, making scripts and tools, so it's so much easier to make clean code after that :-) happy hacking, but be careful. > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 22 10:23:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WiOB-0003dY-01 for ; Mon, 22 Jul 2002 20:58:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Jul 2002 20:58:35 +0200 (CEST) Received: (qmail 29797 invoked by uid 0); 22 Jul 2002 08:33:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 22 Jul 2002 08:33:42 -0000 Received: by moria.seul.org (Postfix) id E6C0914694C; Mon, 22 Jul 2002 04:33:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B77F0146964; Mon, 22 Jul 2002 04:33:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id DB4D914694C for ; Mon, 22 Jul 2002 04:33:39 -0400 (EDT) Received: (qmail 44686 invoked by uid 85); 22 Jul 2002 08:31:39 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.306775 secs); 22 Jul 2002 08:31:39 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 22 Jul 2002 08:31:39 -0000 Message-ID: <3D3BC0F7.5000802@yahoo.fr> Date: Mon, 22 Jul 2002 10:23:19 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> <3D381988.1050905@jetnet.ab.ca> <3D3830B6.4050204@yahoo.fr> <3D384B55.4060904@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Ben Franchuk wrote: > Just an Illusion wrote: > >> The h/w exchange format are hdl (vhdl and verilog) sources, hdl >> netlist source and *edif* format. See the different h/w project on >> the net. > > > > There is some good stuff out there but good I/O devices are still harder > to find Open Source. A whole lot 6502 chips with out BCD math too. > > Since I will be designing in TTL for a while still all my source is > in PDF schematics :) Ok, but you can't synthesize them. > > >> Wait, wait, don't make mistake. >> The both main hdl language are *not* fpga specific. > > > It is the minor ones -- Cupl,Ahdl,Pal-asm I was thinking about. > >> The both ones are h/w modelisation language to design any h/w systems >> (digital or not, with the vhdl-ams and the verilog-a extension). The >> design can be implemented (fully or partially) in any type of >> appropriate programmable logic like : rom, prom, eprom e2prom, ram, >> pld, gal, fpga, asic... > > > I note TTL is missing from the LIST (grin). Yes but *ttl* isn't programmable logic :-( > >> >> Search the processor Mark2 code, this is an old model of 8 bit >> processor given into the book : >> R. ARMSTRONG : Chip-Level Modeling With VHDL; Prentice Hall, >> Englewood Cliffs,NEW-JERSEY 07632. 1989 >> >> And try to synthesize the code, or try to rewrite it like rtl model >> and you can see the difference. > > > I live in the middle of the Great White North of Canada, getting any book > is difficult unless I buy it. I would like to learn a HDL but I need a > book that explains the languge and constructs well rather than teaching > logic. A complier would help too, but this thread is getting off topic > now. Try this link : http://www.1001tutorials.com/vhdl/index.shtml > Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Jul 22 15:44:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WiOT-0003dY-00 for ; Mon, 22 Jul 2002 20:58:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Jul 2002 20:58:53 +0200 (CEST) Received: (qmail 25989 invoked by uid 0); 22 Jul 2002 13:47:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 22 Jul 2002 13:47:21 -0000 Received: by moria.seul.org (Postfix) id DD91A14692F; Mon, 22 Jul 2002 09:47:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFB1514694D; Mon, 22 Jul 2002 09:47:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 1AD6E14692F for ; Mon, 22 Jul 2002 09:47:20 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-219.jetnet.ab.ca [207.34.60.219]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6MDm5jo089898 for ; Mon, 22 Jul 2002 07:48:06 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3C0C27.9090201@jetnet.ab.ca> Date: Mon, 22 Jul 2002 07:44:07 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Free synthesis tool for Verilog and other links - OT References: <1026927812.2114.11.camel@pumpkin.michaelo.net> <3D3677A8.5090202@yahoo.fr> <3D36D8CD.4060904@jetnet.ab.ca> <3D36EE28.28B5599C@f-cpu.org> <3D36F2F7.3060207@jetnet.ab.ca> <3D37E323.3010203@yahoo.fr> <3D381988.1050905@jetnet.ab.ca> <3D3830B6.4050204@yahoo.fr> <3D384B55.4060904@jetnet.ab.ca> <3D3BC0F7.5000802@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just an Illusion wrote: > Hi, > > Ben Franchuk wrote: Ok, but you can't synthesize them. But I can! While not portable schematic entry is still low cost entry for many fpga packages.I have the FPGA source files but that even less portable. > Yes but *ttl* isn't programmable logic :-( Yes it is... Hand programable logic ... you make all the programming connections by hand :) > Try this link : http://www.1001tutorials.com/vhdl/index.shtml Thanks for the link. Mind you my own FPGA project is on hold as I just found a nice stereo AMP I like and can afford soon. http://s5electronics.com/gpage1.html Now to find speakers too. > Cheers, Just an Illusion > -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 22 18:33:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WiOc-0003dY-01 for ; Mon, 22 Jul 2002 20:59:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Jul 2002 20:59:02 +0200 (CEST) Received: (qmail 6787 invoked by uid 0); 22 Jul 2002 16:33:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 22 Jul 2002 16:33:15 -0000 Received: by moria.seul.org (Postfix) id 99FFE14693B; Mon, 22 Jul 2002 12:33:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 55EFF14696B; Mon, 22 Jul 2002 12:33:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id DED4B14693B for ; Mon, 22 Jul 2002 12:33:13 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 0B98F1855A for ; Mon, 22 Jul 2002 18:33:13 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id DFBD86411D; Mon, 22 Jul 2002 18:33:12 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] New manual release (0.2.6) Message-ID: <1027355592.3d3c33c8c9ba4@imp.free.fr> Date: Mon, 22 Jul 2002 18:33:12 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi every body, I have uploaded on seul a new manual : http://f-cpu.seul.org/cedric/ Change are : - New index at the end of the manual - Add new dshift instructions (must be verified) - Applying change suggested by Thomas LAVERGNE - New call convention - Reversing all the bits - New loadcons from Michael RIEPE Good reading, Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Mon Jul 22 18:56:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WiOd-0003dY-01 for ; Mon, 22 Jul 2002 20:59:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Jul 2002 20:59:03 +0200 (CEST) Received: (qmail 2391 invoked by uid 0); 22 Jul 2002 17:03:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 22 Jul 2002 17:03:21 -0000 Received: by moria.seul.org (Postfix) id A7802146965; Mon, 22 Jul 2002 13:03:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B3EF14696D; Mon, 22 Jul 2002 13:03:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2574B146965 for ; Mon, 22 Jul 2002 13:03:19 -0400 (EDT) Received: from laposte.net (193.250.154.158) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB28C000AD2BE for f-cpu@seul.org; Mon, 22 Jul 2002 19:03:17 +0200 Message-ID: <3D3C3959.80201@laposte.net> Date: Mon, 22 Jul 2002 18:56:57 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL wrote: > Hi every body, > > I have uploaded on seul a new manual : > http://f-cpu.seul.org/cedric/ > Please set the good right for the files... -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 22 22:02:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Wm0s-00068s-01 for ; Tue, 23 Jul 2002 00:50:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 00:50:46 +0200 (CEST) Received: (qmail 25564 invoked by uid 0); 22 Jul 2002 19:57:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 22 Jul 2002 19:57:52 -0000 Received: by moria.seul.org (Postfix) id 775BF146939; Mon, 22 Jul 2002 15:57:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4429C146975; Mon, 22 Jul 2002 15:57:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id E65E9146939 for ; Mon, 22 Jul 2002 15:57:50 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-1.free.fr (Postfix) with ESMTP id F37D615D for ; Mon, 22 Jul 2002 21:57:49 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 8369EFCED; Mon, 22 Jul 2002 22:02:03 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) Message-ID: <1027368123.3d3c64bb76400@imp.free.fr> Date: Mon, 22 Jul 2002 22:02:03 +0200 (MEST) From: Cedric BAIL References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <3D3C3959.80201@laposte.net> In-Reply-To: <3D3C3959.80201@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Hi every body, > > > > I have uploaded on seul a new manual : > > http://f-cpu.seul.org/cedric/ > > > > > Please set the good right for the files... Oups, I only set the good right for the subdirectory. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Mon Jul 22 23:19:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Wm16-00068s-01 for ; Tue, 23 Jul 2002 00:51:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 00:51:00 +0200 (CEST) Received: (qmail 5713 invoked by uid 0); 22 Jul 2002 21:19:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 22 Jul 2002 21:19:56 -0000 Received: by moria.seul.org (Postfix) id 9BF3C146975; Mon, 22 Jul 2002 17:19:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 717B5146978; Mon, 22 Jul 2002 17:19:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14201.mail.yahoo.com (web14201.mail.yahoo.com [216.136.172.143]) by moria.seul.org (Postfix) with SMTP id DEA94146975 for ; Mon, 22 Jul 2002 17:19:54 -0400 (EDT) Message-ID: <20020722211954.81686.qmail@web14201.mail.yahoo.com> Received: from [130.89.243.164] by web14201.mail.yahoo.com via HTTP; Mon, 22 Jul 2002 14:19:54 PDT Date: Mon, 22 Jul 2002 14:19:54 -0700 (PDT) From: jaap stolk Subject: [f-cpu] simulator update: scheduler and xbar are working To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i uploaded Snapshot_jws_22_07_2002.tar.bz2 to http://f-cpu.seul.org/~f-cpu/new/?M=A ik renamed most things to stop confusing register numbers with (x-bar) port numbers. stalling the pipelinge when a register result is not ready works, recovering from the stall works. doing direct bypass or delayed bypass works. stalling if no write ports are avalable should work. the simulator now includes a "Notes"-screen that shows some pre-compiled instructions, that can be entered into the simulator, so you can try some register stalls etc. ( it currently only dous 64-bit add ) ( code is NOT optimezed (yet) ) i will try to put the all the interesting findings in a readme soon. any bug reports would be helpfull... jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 23 01:17:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Wnl2-0007a7-00 for ; Tue, 23 Jul 2002 02:42:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 02:42:32 +0200 (CEST) Received: (qmail 14819 invoked by uid 0); 22 Jul 2002 23:08:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 22 Jul 2002 23:08:15 -0000 Received: by moria.seul.org (Postfix) id 46165146976; Mon, 22 Jul 2002 19:08:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 06D41146978; Mon, 22 Jul 2002 19:08:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 97D61146976 for ; Mon, 22 Jul 2002 19:08:13 -0400 (EDT) Received: from f-cpu.org (kdl14-34.n.club-internet.fr [213.44.12.34]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 9DA9B1685 for ; Tue, 23 Jul 2002 01:08:10 +0200 (CEST) Message-ID: <3D3C927B.6D069774@f-cpu.org> Date: Tue, 23 Jul 2002 01:17:15 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <3D3C3959.80201@laposte.net> <1027368123.3d3c64bb76400@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > > > > Hi every body, > > > > > > I have uploaded on seul a new manual : > > > http://f-cpu.seul.org/cedric/ > > > > > > > > > Please set the good right for the files... > > Oups, I only set the good right for the subdirectory. todo : REMOVE THE BODY OF CHAPTER 3 IN PART 1. it has mislead several people and it is more and more off-topic. We can keep some meaningful parts, but the technical details are like a time bomb. And all the parts that remain MUST be surrounded by a colored frame, to show that it is not written by the current team. when the manual was in HTML, there was a grey backgrgound, but someone removed it when going to LaTeX :-( > A+ > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Jul 23 06:42:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Wtq3-0000Fr-01 for ; Tue, 23 Jul 2002 09:12:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 09:12:07 +0200 (CEST) Received: (qmail 29845 invoked by uid 0); 23 Jul 2002 04:49:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Jul 2002 04:49:14 -0000 Received: by moria.seul.org (Postfix) id ADA3D1467F9; Tue, 23 Jul 2002 00:49:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 75FEA146973; Tue, 23 Jul 2002 00:49:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id E380F1467F9 for ; Tue, 23 Jul 2002 00:49:11 -0400 (EDT) Received: from laposte.net (193.250.154.223) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB28C000B4A68 for f-cpu@seul.org; Tue, 23 Jul 2002 06:49:11 +0200 Message-ID: <3D3CDEB2.2070009@laposte.net> Date: Tue, 23 Jul 2002 06:42:26 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] Stack handling Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I've reread the manual and found a problem in stack handling suggestion The manual say : pop = load 8, r3, r2 push = store -8, r3, r2 With r3 a stack pointer and r2 a value to be pushed/poped to/from the stack. but this was false, for example try to make : push r2 pop r2 you obtain this code store -8, r3, r2 load 8, r3, r2 you push r2 at r3 address and increment r3, and after you get in r2 the value at r3 and decrement the pointer so after executing this you don't have the same value in r2... Bug We can't manage a stack without pre-decrement instruction, or we need a lot of tricks and obtain very bad code... Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 09:43:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17WveL-0001x3-01 for ; Tue, 23 Jul 2002 11:08:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 11:08:09 +0200 (CEST) Received: (qmail 22565 invoked by uid 0); 23 Jul 2002 07:43:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 23 Jul 2002 07:43:45 -0000 Received: by moria.seul.org (Postfix) id ED2CC14640E; Tue, 23 Jul 2002 03:43:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAA40146973; Tue, 23 Jul 2002 03:43:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 407B914640E for ; Tue, 23 Jul 2002 03:43:43 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207230743.1c80; Tue, 23 Jul 2002 07:43:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Arithmetic lib From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2002 07:43:28 GMT Message-id: <200207230743.1c80@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Is this url knowns ? http://www.iis.ee.ethz.ch/~zimmi/ nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Jul 23 12:20:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1S9-0005ha-00 for ; Tue, 23 Jul 2002 17:19:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:19:57 +0200 (CEST) Received: (qmail 9391 invoked by uid 0); 23 Jul 2002 10:20:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 23 Jul 2002 10:20:54 -0000 Received: by moria.seul.org (Postfix) id C882C1467FE; Tue, 23 Jul 2002 06:20:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 83AFB14697B; Tue, 23 Jul 2002 06:20:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id F1E0F1467FE for ; Tue, 23 Jul 2002 06:20:51 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-1.free.fr (Postfix) with ESMTP id 674C7256 for ; Tue, 23 Jul 2002 12:20:51 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 379EC580C4; Tue, 23 Jul 2002 12:20:51 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) Message-ID: <1027419651.3d3d2e0328412@imp.free.fr> Date: Tue, 23 Jul 2002 12:20:51 +0200 (MEST) From: Cedric BAIL References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <3D3C3959.80201@laposte.net> <1027368123.3d3c64bb76400@imp.free.fr> <3D3C927B.6D069774@f-cpu.org> In-Reply-To: <3D3C927B.6D069774@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > todo : > REMOVE THE BODY OF CHAPTER 3 IN PART 1. > it has mislead several people and it is > more and more off-topic. > We can keep some meaningful parts, > but the technical details are like a time bomb. > And all the parts that remain MUST be surrounded > by a colored frame, to show that it is not > written by the current team. when the manual was in > HTML, there was a grey backgrgound, but someone > removed it when going to LaTeX :-( Ok. I think, I will start to learn how to put color in LaTeX, it can be nice for the manual. Other remarks ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 12:44:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SB-0005ha-01 for ; Tue, 23 Jul 2002 17:19:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:19:59 +0200 (CEST) Received: (qmail 11752 invoked by uid 0); 23 Jul 2002 10:46:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Jul 2002 10:46:57 -0000 Received: by moria.seul.org (Postfix) id 3E9C6146959; Tue, 23 Jul 2002 06:46:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D12114697C; Tue, 23 Jul 2002 06:46:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id A0CFF146959 for ; Tue, 23 Jul 2002 06:46:55 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB3A2001123AE for f-cpu@seul.org; Tue, 23 Jul 2002 12:46:54 +0200 Message-ID: <007601c23235$fbb36a10$86313051@hli> From: "Christophe Avoinne" To: References: <3D3CDEB2.2070009@laposte.net> Subject: Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 12:44:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Was it possible that nobody never saw that problem !? so no one found a workaround to avoid pre-increment/decrement and still thinks he can use 'push' and 'pop' without pre-increment/decrement ? Well I can see two workarounds : 1) push ... push ... push ... push ... ... addi 8,r3,r3 // we need to point on the last pushed word for popping properly pop ... pop ... pop ... pop ... subi 8,r3,r3 // we need to adjust stack to avoid leaving a word hole after popping Just imagine a interruption occurs between the last pop and subi, and for some reasons we push in the stack, we are corrupting the stack with the first push because we are crashing a pushed value no matter where it is. In fact the problem is the same for the other pop too. | POPPED | | POPPED | | POPPED | | POPPED | <- interruptions occurs | PUSHED | <- r3 is pointing here when interrupted, this word instead the last popped is likely to be crashed if a push occurs. | PUSHED | ... So you understand why a lot of CPU has the pre/post-increment/decrement to be atomic with this regard. Of course, some people would argue interruption cannot do that. Just an idea, you want to use unix signals. That means you want to run asynchronously signal handlers. How to do that ? let us try SIG_ALARM. A timer interruption raises. It sees there is a signal to send to a process, so it installs a user interrupt (what matters how) in the given process so the latter can execute the alarm handler. Of course, this alarm handler is a normal C function which is likely to push some registers in the stack, usually in the same stack of the interrupted application of the same process. Well corruption due to a bad design for stack operations. 2) subi 8,r3,r3 // we need to adjust stack to avoid leaving a word hole push ... push ... push ... push ... addi 8,r3,r3 // we need to point on the last pushed word for popping properly ... pop ... pop ... pop ... pop ... The same problem still occurs after each pop. ----- Original Message ----- From: "Thomas Lavergne" To: "FCpu English" Sent: Tuesday, July 23, 2002 6:42 AM Subject: [f-cpu] Stack handling > I've reread the manual and found a problem in stack handling suggestion > > The manual say : > > pop = load 8, r3, r2 > push = store -8, r3, r2 > > With r3 a stack pointer and r2 a value to be pushed/poped to/from the stack. > > but this was false, for example try to make : > push r2 > pop r2 > > you obtain this code > > store -8, r3, r2 > load 8, r3, r2 > > you push r2 at r3 address and increment r3, > and after you get in r2 the value at r3 and decrement the pointer > so after executing this you don't have the same value in r2... Bug > > We can't manage a stack without pre-decrement instruction, or we need a > lot of tricks and obtain very bad code... > > Tom > > -- > Thomas Lavergne "Le vrai rêveur est celui qui rêve > de l'impossible." (Elsa Triolet) > thomas.lavergne@laposte.net > d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 13:22:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SC-0005ha-00 for ; Tue, 23 Jul 2002 17:20:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:00 +0200 (CEST) Received: (qmail 9591 invoked by uid 0); 23 Jul 2002 11:22:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Jul 2002 11:22:57 -0000 Received: by moria.seul.org (Postfix) id 78B1F14697C; Tue, 23 Jul 2002 07:22:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E16D14697E; Tue, 23 Jul 2002 07:22:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id CC26614697C for ; Tue, 23 Jul 2002 07:22:55 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207231122.2ddc; Tue, 23 Jul 2002 11:22:45 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2002 11:22:45 GMT Message-id: <200207231122.2ddc@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Maybe it's a stupid question, but why it's forced to try to = simulate a simple stack. There is no hardware support for stack in the = f-cpu. Why not using a completely different pointer for such things ? W= hy must we stuck to the use of one single stack ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 23/07/02 Objet: Re: [f-cpu] Stack handling Was it possible that nobody never saw that problem !? so no = one found a workaround to avoid pre-increment/decrement and still thinks= he can use 'push' and 'pop' without pre-increment/decrement ? Well I can see two workarounds : 1) push ... push ... push ... push ... ... addi 8,r3,r3 // we need to point on the last pushed = word for popping properly pop ... pop ... pop ... pop ... subi 8,r3,r3 // we need to adjust stack to avoid lea= ving a word hole after popping Just imagine a interruption occurs between the last pop and = subi, and for some reasons we push in the stack, we are corrupting the sta= ck with the first push because we are crashing a pushed value no matter = where it is. In fact the problem is the same for the other pop too. | POPPED | | POPPED | | POPPED | | POPPED | <- interruptions occurs | PUSHED | <- r3 is pointing here when interrupted, this wor= d instead the last popped is likely to be crashed if a push occurs. | PUSHED | ... So you understand why a lot of CPU has the pre/post-incremen= t/decrement to be atomic with this regard. Of course, some people would argue interruption cannot do th= at. Just an idea, you want to use unix signals. That means you want to r= un asynchronously signal handlers. How to do that ? let us try = SIG_ALARM. A timer interruption raises. It sees there is a signal to send= to a process, so it installs a user interrupt (what matters how) in the gi= ven process so the latter can execute the alarm handler. Of course, this al= arm handler is a normal C function which is likely to push some registers in = the stack, usually in the same stack of the interrupted application of = the same process. Well corruption due to a bad design for stack opera= tions. 2) subi 8,r3,r3 // we need to adjust stack to avoid lea= ving a word hole push ... push ... push ... push ... addi 8,r3,r3 // we need to point on the last pushed = word for popping properly ... pop ... pop ... pop ... pop ... The same problem still occurs after each pop. ----- Original Message ----- From: "Thomas Lavergne" To: "FCpu English" Sent: Tuesday, July 23, 2002 6:42 AM Subject: [f-cpu] Stack handling > I've reread the manual and found a problem in stack handli= ng suggestion > > The manual say : > > pop =3D load 8, r3, r2 > push =3D store -8, r3, r2 > > With r3 a stack pointer and r2 a value to be pushed/poped = to/from the stack. > > but this was false, for example try to make : > push r2 > pop r2 > > you obtain this code > > store -8, r3, r2 > load 8, r3, r2 > > you push r2 at r3 address and increment r3, > and after you get in r2 the value at r3 and decrement the = pointer > so after executing this you don't have the same value in r= 2... Bug > > We can't manage a stack without pre-decrement instruction,= or we need a > lot of tricks and obtain very bad code... > > Tom > > -- > Thomas Lavergne "Le vrai r=EAveur es= t celui qui r=EAve > de l'impossible." = (Elsa Triolet) > thomas.lavergne@laposte.net > d-12@laposte.net ICQ:#137121910 =20 http://assoc.wanadoo.fr/thallium/ > > **********************************************************= *** > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org= / ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jul 23 13:42:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SD-0005ha-00 for ; Tue, 23 Jul 2002 17:20:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:01 +0200 (CEST) Received: (qmail 7769 invoked by uid 0); 23 Jul 2002 11:41:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 23 Jul 2002 11:41:01 -0000 Received: by moria.seul.org (Postfix) id 8431E14697D; Tue, 23 Jul 2002 07:40:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6C551146980; Tue, 23 Jul 2002 07:40:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id D08C814697D for ; Tue, 23 Jul 2002 07:40:57 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17Wy3v-0008Md-00 for f-cpu@seul.org; Tue, 23 Jul 2002 13:42:43 +0200 Date: Tue, 23 Jul 2002 13:42:43 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <200207231122.2ddc@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N No, it's not a stupid question at all. I had the same first thought when I read the posting. You may just have a need for a seperate stack for the scheduling handler. JG On Tue, 23 Jul 2002, Nicolas Boulay wrote: > >Maybe it's a stupid question, but why it's forced to try to simulate a >simple stack. There is no hardware support for stack in the f-cpu. Why >not using a completely different pointer for such things ? Why must we >stuck to the use of one single stack ? > >nicO > > >-----Message d'origine----- >De: "Christophe Avoinne" >A: >Date: 23/07/02 >Objet: Re: [f-cpu] Stack handling > >Was it possible that nobody never saw that problem !? so no one found a >workaround to avoid pre-increment/decrement and still thinks he can use >'push' and 'pop' without pre-increment/decrement ? > >Well I can see two workarounds : > >1) > push ... > push ... > push ... > push ... > ... > addi 8,r3,r3 // we need to point on the last pushed word for >popping >properly > pop ... > pop ... > pop ... > pop ... > subi 8,r3,r3 // we need to adjust stack to avoid leaving a word >hole >after popping > >Just imagine a interruption occurs between the last pop and subi, and >for >some reasons we push in the stack, we are corrupting the stack with the >first push because we are crashing a pushed value no matter where it is. >In >fact the problem is the same for the other pop too. >| POPPED | >| POPPED | >| POPPED | >| POPPED | <- interruptions occurs >| PUSHED | <- r3 is pointing here when interrupted, this word instead >the >last popped is likely to be crashed if a push occurs. >| PUSHED | >... > >So you understand why a lot of CPU has the pre/post-increment/decrement >to >be atomic with this regard. > >Of course, some people would argue interruption cannot do that. Just an >idea, you want to use unix signals. That means you want to run >asynchronously signal handlers. How to do that ? let us try SIG_ALARM. A >timer interruption raises. It sees there is a signal to send to a >process, >so it installs a user interrupt (what matters how) in the given process >so >the latter can execute the alarm handler. Of course, this alarm handler >is a >normal C function which is likely to push some registers in the stack, >usually in the same stack of the interrupted application of the same >process. Well corruption due to a bad design for stack operations. > >2) > subi 8,r3,r3 // we need to adjust stack to avoid leaving a word >hole > push ... > push ... > push ... > push ... > addi 8,r3,r3 // we need to point on the last pushed word for >popping >properly > ... > pop ... > pop ... > pop ... > pop ... > >The same problem still occurs after each pop. > > >----- Original Message ----- From: "Thomas Lavergne" >To: "FCpu English" >Sent: Tuesday, July 23, 2002 6:42 AM >Subject: [f-cpu] Stack handling > > >> I've reread the manual and found a problem in stack handling >suggestion >> >> The manual say : >> >> pop =3D load 8, r3, r2 >> push =3D store -8, r3, r2 >> >> With r3 a stack pointer and r2 a value to be pushed/poped to/from the >stack. >> >> but this was false, for example try to make : >> push r2 >> pop r2 >> >> you obtain this code >> >> store -8, r3, r2 >> load 8, r3, r2 >> >> you push r2 at r3 address and increment r3, >> and after you get in r2 the value at r3 and decrement the pointer >> so after executing this you don't have the same value in r2... Bug >> >> We can't manage a stack without pre-decrement instruction, or we need >a >> lot of tricks and obtain very bad code... >> >> Tom >> >> -- >> Thomas Lavergne "Le vrai r=EAveur est celui qui >r=EAve >> de l'impossible." (Elsa >Triolet) >> thomas.lavergne@laposte.net >> d-12@laposte.net ICQ:#137121910 =20 >http://assoc.wanadoo.fr/thallium/ >> >> ************************************************************* >> To unsubscribe, send an e-mail to majordomo@seul.org with >> unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > >=20 >__________________________________________________________________________= ____ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 13:39:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SE-0005ha-00 for ; Tue, 23 Jul 2002 17:20:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:02 +0200 (CEST) Received: (qmail 31093 invoked by uid 0); 23 Jul 2002 11:44:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 23 Jul 2002 11:44:10 -0000 Received: by moria.seul.org (Postfix) id 81D1C14697F; Tue, 23 Jul 2002 07:44:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 70EBF146982; Tue, 23 Jul 2002 07:44:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id BDA3C14697F for ; Tue, 23 Jul 2002 07:44:08 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB609000D0131 for f-cpu@seul.org; Tue, 23 Jul 2002 13:44:07 +0200 Message-ID: <00c601c2323d$fa0d3a80$86313051@hli> From: "Christophe Avoinne" To: References: <200207231122.2ddc@th00.opsion.fr> Subject: Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 13:39:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N If you want to invent a new OS which doesn't need a stack, well okay. But my oppinion is that you would need to be friendly with software programmers and don't complicate their jobs because you only think about the hardware part without any regard about the habits of programmers. I really understand the whys you prefer to avoid a pre-increment/decrement, but the fact is there are situations we need it. Stacks must be used with minimal intents. Having too much stacks can lead to a bad ressource handling (lot of memory wasted) and a lot of cache miss (stack is used as a temporary memory so functions should reuse the same room when not embedded). By the way, i was not speaking about the stack for OS but about the user signal handler which is a simple C function to call in the owner process. You can still give it another stack, but you need to allocate one (wasted ressource), need to know which register for stack pointer to use (gcc knows only one), or use a stack-pointer switching (where to save the old stack pointer ?), etc. Do you really want to have Linux works on your F-CPU ?! why to do things more complicate when one user process stack is enough to handle this handler ? ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Tuesday, July 23, 2002 1:22 PM Subject: Rep:Re: [f-cpu] Stack handling Maybe it's a stupid question, but why it's forced to try to simulate a simple stack. There is no hardware support for stack in the f-cpu. Why not using a completely different pointer for such things ? Why must we stuck to the use of one single stack ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 23/07/02 Objet: Re: [f-cpu] Stack handling Was it possible that nobody never saw that problem !? so no one found a workaround to avoid pre-increment/decrement and still thinks he can use 'push' and 'pop' without pre-increment/decrement ? Well I can see two workarounds : 1) push ... push ... push ... push ... ... addi 8,r3,r3 // we need to point on the last pushed word for popping properly pop ... pop ... pop ... pop ... subi 8,r3,r3 // we need to adjust stack to avoid leaving a word hole after popping Just imagine a interruption occurs between the last pop and subi, and for some reasons we push in the stack, we are corrupting the stack with the first push because we are crashing a pushed value no matter where it is. In fact the problem is the same for the other pop too. | POPPED | | POPPED | | POPPED | | POPPED | <- interruptions occurs | PUSHED | <- r3 is pointing here when interrupted, this word instead the last popped is likely to be crashed if a push occurs. | PUSHED | ... So you understand why a lot of CPU has the pre/post-increment/decrement to be atomic with this regard. Of course, some people would argue interruption cannot do that. Just an idea, you want to use unix signals. That means you want to run asynchronously signal handlers. How to do that ? let us try SIG_ALARM. A timer interruption raises. It sees there is a signal to send to a process, so it installs a user interrupt (what matters how) in the given process so the latter can execute the alarm handler. Of course, this alarm handler is a normal C function which is likely to push some registers in the stack, usually in the same stack of the interrupted application of the same process. Well corruption due to a bad design for stack operations. 2) subi 8,r3,r3 // we need to adjust stack to avoid leaving a word hole push ... push ... push ... push ... addi 8,r3,r3 // we need to point on the last pushed word for popping properly ... pop ... pop ... pop ... pop ... The same problem still occurs after each pop. ----- Original Message ----- From: "Thomas Lavergne" To: "FCpu English" Sent: Tuesday, July 23, 2002 6:42 AM Subject: [f-cpu] Stack handling > I've reread the manual and found a problem in stack handling suggestion > > The manual say : > > pop = load 8, r3, r2 > push = store -8, r3, r2 > > With r3 a stack pointer and r2 a value to be pushed/poped to/from the stack. > > but this was false, for example try to make : > push r2 > pop r2 > > you obtain this code > > store -8, r3, r2 > load 8, r3, r2 > > you push r2 at r3 address and increment r3, > and after you get in r2 the value at r3 and decrement the pointer > so after executing this you don't have the same value in r2... Bug > > We can't manage a stack without pre-decrement instruction, or we need a > lot of tricks and obtain very bad code... > > Tom > > -- > Thomas Lavergne "Le vrai rêveur est celui qui rêve > de l'impossible." (Elsa Triolet) > thomas.lavergne@laposte.net > d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 14:10:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SF-0005ha-00 for ; Tue, 23 Jul 2002 17:20:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:03 +0200 (CEST) Received: (qmail 31621 invoked by uid 0); 23 Jul 2002 12:12:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 23 Jul 2002 12:12:31 -0000 Received: by moria.seul.org (Postfix) id 387DD1467E8; Tue, 23 Jul 2002 08:12:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2441B146981; Tue, 23 Jul 2002 08:12:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9D3881467E8 for ; Tue, 23 Jul 2002 08:12:28 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D32A1F9000922CD for f-cpu@seul.org; Tue, 23 Jul 2002 14:12:27 +0200 Message-ID: <000e01c23241$ef9493b0$86313051@hli> From: "Christophe Avoinne" To: References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> Subject: Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 14:10:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N And if you are not convienced, just imagine the SIG_BUS case : You want to execute a signal handler which displays your message using 'printf'. But the trouble is that if you want use a different stack register, 'printf' still uses those of user process, so you are still stuck. So you need to compile as many functions as you have different stacks. Sorry to say, but it is stupid to duplicate code because of a different stack register. Personnally, if things were easy with different stack register, there would be a long time people would use them instead of an signle stack register. I tell you, your stack design is bad or incomplete, should I say at least. Post-increment/decrement is a no use without pre-decrement/increment. Hummm... i think we can remove one instruction. // pushing r1..r5 store -8,r62,r1 store -8,r62,r2 store -8,r62,r3 store -8,r62,r4 store -8,r62,r5 ... addi +8,r62,r62 // we still need to adjust the stack pointer load +8,r62,r1 load +8,r62,r2 load +8,r62,r3 load +8,r62,r4 load +0,r62,r5 // but we don't need to advance stack pointer ! But stack crashing still remains possible. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 14:14:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SG-0005ha-01 for ; Tue, 23 Jul 2002 17:20:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:04 +0200 (CEST) Received: (qmail 19781 invoked by uid 0); 23 Jul 2002 12:16:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 23 Jul 2002 12:16:09 -0000 Received: by moria.seul.org (Postfix) id CE50D146980; Tue, 23 Jul 2002 08:16:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF989146983; Tue, 23 Jul 2002 08:16:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 1A7F4146980 for ; Tue, 23 Jul 2002 08:16:07 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D32A1F9000923DF for f-cpu@seul.org; Tue, 23 Jul 2002 14:16:06 +0200 Message-ID: <002b01c23242$71c261f0$86313051@hli> From: "Christophe Avoinne" To: References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> <000e01c23241$ef9493b0$86313051@hli> Subject: Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 14:14:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N sorry some errors : 1) // pushing r1..r5 store -8,r62,r1 store -8,r62,r2 store -8,r62,r3 store -8,r62,r4 store -0,r62,r5 ... // popping r1..r5 load +8,r62,r5 load +8,r62,r4 load +8,r62,r3 load +8,r62,r2 load +0,r62,r1 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Jul 23 13:52:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SO-0005ha-00 for ; Tue, 23 Jul 2002 17:20:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:12 +0200 (CEST) Received: (qmail 6679 invoked by uid 0); 23 Jul 2002 13:53:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Jul 2002 13:53:43 -0000 Received: by moria.seul.org (Postfix) id 61A021467F7; Tue, 23 Jul 2002 09:53:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47F84146800; Tue, 23 Jul 2002 09:53:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id EBC9D1467F7 for ; Tue, 23 Jul 2002 09:53:40 -0400 (EDT) Received: from laposte.net (193.250.226.165) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB28C000BDA7E for f-cpu@seul.org; Tue, 23 Jul 2002 15:53:40 +0200 Message-ID: <3D3D4386.5020306@laposte.net> Date: Tue, 23 Jul 2002 13:52:38 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Have you ever written a compiler ? A stack is the most simple and clean solution to handle a lot of thing. We have a lot of register so most compiler simulate the first stack push/pop with reg but when the stack grow we need a real stack handling. If we haven't stack we must reinvent the weel or back 50 years ago in compiler theorie. The debat about the number of stack is another thing, I think we need some instruction for stack (pre-dec) on all register so we can have all stack we need. Juergen Goeritz wrote: > No, it's not a stupid question at all. I had the same > first thought when I read the posting. You may just > have a need for a seperate stack for the scheduling > handler. > > JG > > > On Tue, 23 Jul 2002, Nicolas Boulay wrote: > >>Maybe it's a stupid question, but why it's forced to try to simulate a >>simple stack. There is no hardware support for stack in the f-cpu. Why >>not using a completely different pointer for such things ? Why must we >>stuck to the use of one single stack ? >> >>nicO >> -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 16:24:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SS-0005ha-00 for ; Tue, 23 Jul 2002 17:20:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:16 +0200 (CEST) Received: (qmail 28576 invoked by uid 0); 23 Jul 2002 14:24:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Jul 2002 14:24:38 -0000 Received: by moria.seul.org (Postfix) id 148191467FA; Tue, 23 Jul 2002 10:24:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DEA98146802; Tue, 23 Jul 2002 10:24:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 316A41467FA for ; Tue, 23 Jul 2002 10:24:36 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207231424.18e0; Tue, 23 Jul 2002 14:24:24 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2002 14:24:24 GMT Message-id: <200207231424.18e0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 23/07/02 Objet: Re: Rep:Re: [f-cpu] Stack handling Have you ever written a compiler ? A stack is the most simple and clean solution to handle a lo= t of thing.=20 We have a lot of register so most compiler simulate the firs= t stack=20 push/pop with reg but when the stack grow we need a real sta= ck handling. If we haven't stack we must reinvent the weel or back 50 yea= rs ago in=20 compiler theorie. The debat about the number of stack is another thing, I thin= k we need=20 some instruction for stack (pre-dec) on all register so we c= an have all=20 stack we need. Juergen Goeritz wrote: > No, it's not a stupid question at all. I had the same > first thought when I read the posting. You may just > have a need for a seperate stack for the scheduling > handler. >=20 > JG >=20 >=20 > On Tue, 23 Jul 2002, Nicolas Boulay wrote: >=20 >>Maybe it's a stupid question, but why it's forced to try t= o simulate a >>simple stack. There is no hardware support for stack in th= e f-cpu. Why >>not using a completely different pointer for such things ?= Why must we >>stuck to the use of one single stack ? >> >>nicO >> --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 16:27:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SS-0005ha-01 for ; Tue, 23 Jul 2002 17:20:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:16 +0200 (CEST) Received: (qmail 21598 invoked by uid 0); 23 Jul 2002 14:27:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 23 Jul 2002 14:27:55 -0000 Received: by moria.seul.org (Postfix) id ED696146800; Tue, 23 Jul 2002 10:27:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BFFDD14697E; Tue, 23 Jul 2002 10:27:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 142C1146800 for ; Tue, 23 Jul 2002 10:27:53 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207231427.29b0; Tue, 23 Jul 2002 14:27:41 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2002 14:27:41 GMT Message-id: <200207231427.29b0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Stack have a main draw back : it's add a udge dependancies i= n a single poor register (the stack pointer). For security reason, i have proposed to use 2 stack : one fo= r data, one for code. So buffer overflow will became really hard ! this = could be usefull for performance, too. But most of the time, the stac= k will use the register bank... And that doesn't solve the problem of push and pop. nicO -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 23/07/02 Objet: Re: Rep:Re: [f-cpu] Stack handling Have you ever written a compiler ? A stack is the most simple and clean solution to handle a lo= t of thing.=20 We have a lot of register so most compiler simulate the firs= t stack=20 push/pop with reg but when the stack grow we need a real sta= ck handling. If we haven't stack we must reinvent the weel or back 50 yea= rs ago in=20 compiler theorie. The debat about the number of stack is another thing, I thin= k we need=20 some instruction for stack (pre-dec) on all register so we c= an have all=20 stack we need. Juergen Goeritz wrote: > No, it's not a stupid question at all. I had the same > first thought when I read the posting. You may just > have a need for a seperate stack for the scheduling > handler. >=20 > JG >=20 >=20 > On Tue, 23 Jul 2002, Nicolas Boulay wrote: >=20 >>Maybe it's a stupid question, but why it's forced to try t= o simulate a >>simple stack. There is no hardware support for stack in th= e f-cpu. Why >>not using a completely different pointer for such things ?= Why must we >>stuck to the use of one single stack ? >> >>nicO >> --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Jul 23 16:49:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SY-0005ha-01 for ; Tue, 23 Jul 2002 17:20:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:22 +0200 (CEST) Received: (qmail 26665 invoked by uid 0); 23 Jul 2002 14:55:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 23 Jul 2002 14:55:34 -0000 Received: by moria.seul.org (Postfix) id AFC93146802; Tue, 23 Jul 2002 10:55:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EFD2146981; Tue, 23 Jul 2002 10:55:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2D15C146802 for ; Tue, 23 Jul 2002 10:55:32 -0400 (EDT) Received: from laposte.net (193.250.226.178) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9000958B6 for f-cpu@seul.org; Tue, 23 Jul 2002 16:55:31 +0200 Message-ID: <3D3D6CE2.5030009@laposte.net> Date: Tue, 23 Jul 2002 16:49:06 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231427.29b0@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > Stack have a main draw back : it's add a udge dependancies in a single > poor register (the stack pointer). For classical code OK, but for well written alogithm you can use more than one stack. On a 68000 processor I've written a compiler that use two stack and switch each time between, so each push/pop operation was directed alternatively in the first and in the second. You can use as stack as you want. > > For security reason, i have proposed to use 2 stack : one for data, one > for code. So buffer overflow will became really hard ! this could be > usefull for performance, too. But most of the time, the stack will use > the register bank... > In most case you never have to exec code in the stack so put it in a page without execution right and you can't use buffer overflow to execute a shellcode. Case you need execute code in stack was very rare so in this case you can make an exception and check your code a lot of time. Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 17:06:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X1SZ-0005ha-00 for ; Tue, 23 Jul 2002 17:20:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 17:20:23 +0200 (CEST) Received: (qmail 3468 invoked by uid 0); 23 Jul 2002 15:06:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Jul 2002 15:06:34 -0000 Received: by moria.seul.org (Postfix) id 8F30314697E; Tue, 23 Jul 2002 11:06:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 623B2146982; Tue, 23 Jul 2002 11:06:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 7445E14697E for ; Tue, 23 Jul 2002 11:06:31 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207231506.15c6; Tue, 23 Jul 2002 15:06:21 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2002 15:06:21 GMT Message-id: <200207231506.15c6@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N That's not the point. When i say "stack for code", it's a st= ack where you put you're return adresse when you maid a function call= or something like that. That's not terrific for speed so i pref= er having "some" data stack like you said.=20 That's an argument to change calling convention one more tim= e ? ;p nicO -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 23/07/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling Nicolas Boulay wrote: > Stack have a main draw back : it's add a udge dependancies= in a single > poor register (the stack pointer). For classical code OK, but for well written alogithm you can= use more=20 than one stack. On a 68000 processor I've written a compiler= that use=20 two stack and switch each time between, so each push/pop ope= ration was=20 directed alternatively in the first and in the second. You can use as stack as you want. >=20 > For security reason, i have proposed to use 2 stack : one = for data, one > for code. So buffer overflow will became really hard ! thi= s could be > usefull for performance, too. But most of the time, the st= ack will use > the register bank... >=20 In most case you never have to exec code in the stack so put= it in a=20 page without execution right and you can't use buffer overfl= ow to=20 execute a shellcode. Case you need execute code in stack was very rare so in this= case you=20 can make an exception and check your code a lot of time. Tom --=20 Thomas Lavergne "Le vrai r=EAveur est = celui qui r=EAve de l'impossible." (= Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.= fr/thallium/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jul 23 17:22:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X3aO-00080Z-00 for ; Tue, 23 Jul 2002 19:36:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 19:36:36 +0200 (CEST) Received: (qmail 9884 invoked by uid 0); 23 Jul 2002 15:25:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 23 Jul 2002 15:25:24 -0000 Received: by moria.seul.org (Postfix) id 7EC2F146981; Tue, 23 Jul 2002 11:25:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 740DF146984; Tue, 23 Jul 2002 11:25:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id EA2AD146981 for ; Tue, 23 Jul 2002 11:25:22 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6NFQ9jo048214 for ; Tue, 23 Jul 2002 09:26:10 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3D74A0.8000308@jetnet.ab.ca> Date: Tue, 23 Jul 2002 09:22:08 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Juergen Goeritz wrote: > No, it's not a stupid question at all. I had the same > first thought when I read the posting. You may just > have a need for a seperate stack for the scheduling > handler. > > JG But why is a stack even needed? Since you have IRQ vector tables why not fixed IRQ memory locations for fast save/restore locations. With 64 bit addressing you got room for a few words of memory for IRQ's. Really how often is IRQ's nested? -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jul 23 17:26:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X3aP-00080Z-00 for ; Tue, 23 Jul 2002 19:36:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 19:36:37 +0200 (CEST) Received: (qmail 4846 invoked by uid 0); 23 Jul 2002 15:29:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 23 Jul 2002 15:29:23 -0000 Received: by moria.seul.org (Postfix) id 62E38146983; Tue, 23 Jul 2002 11:29:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B11B146985; Tue, 23 Jul 2002 11:29:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id C8618146983 for ; Tue, 23 Jul 2002 11:29:21 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6NFUAjo049487 for ; Tue, 23 Jul 2002 09:30:11 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3D7591.80005@jetnet.ab.ca> Date: Tue, 23 Jul 2002 09:26:09 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231427.29b0@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > Stack have a main draw back : it's add a udge dependancies in a single > poor register (the stack pointer). > > For security reason, i have proposed to use 2 stack : one for data, one > for code. So buffer overflow will became really hard ! this could be > usefull for performance, too. But most of the time, the stack will use > the register bank... Hmm just like Forth.:) crash_os() { crash_os(); } -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 18:43:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X3aV-00080Z-01 for ; Tue, 23 Jul 2002 19:36:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 19:36:43 +0200 (CEST) Received: (qmail 30258 invoked by uid 0); 23 Jul 2002 16:45:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Jul 2002 16:45:20 -0000 Received: by moria.seul.org (Postfix) id B9175146985; Tue, 23 Jul 2002 12:45:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88AED14698A; Tue, 23 Jul 2002 12:45:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 2BA47146985 for ; Tue, 23 Jul 2002 12:45:19 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB3A2001196F8 for f-cpu@seul.org; Tue, 23 Jul 2002 18:45:18 +0200 Message-ID: <000e01c23268$0cea3b60$86313051@hli> From: "Christophe Avoinne" To: References: <200207231427.29b0@th00.opsion.fr> Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 18:43:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I'm not against having a separate stack for data in one hand and the return addresses in other hand. But I'm not sure the huge dependency is really alleviated for the data (since they are the main part of what is pushed). Maybe using two stack registers in parallel to push data can divide this dependency : to push r1..r6, do : addi -8 ,r62,r8 store -16,r62,r1 store -16,r8 ,r2 store -16,r62,r3 store -16,r8 ,r4 store -0 ,r62,r5 store -0 ,r8 ,r6 instead of : store -8,r62,r1 store -8,r62,r2 store -8,r62,r3 store -8,r62,r4 store -8,r62,r5 store -0,r62,r6 why not a triple stack ? addi -8 ,r62,r8 addi -16,r62,r9 store -24,r62,r1 store -24,r8 ,r2 store -24,r9 ,r3 store -0 ,r62,r4 store -0 ,r8 ,r5 store -0 ,r9 ,r6 ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Tuesday, July 23, 2002 4:27 PM Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling Stack have a main draw back : it's add a udge dependancies in a single poor register (the stack pointer). For security reason, i have proposed to use 2 stack : one for data, one for code. So buffer overflow will became really hard ! this could be usefull for performance, too. But most of the time, the stack will use the register bank... And that doesn't solve the problem of push and pop. nicO -----Message d'origine----- De: Thomas Lavergne A: f-cpu@seul.org Date: 23/07/02 Objet: Re: Rep:Re: [f-cpu] Stack handling Have you ever written a compiler ? A stack is the most simple and clean solution to handle a lot of thing. We have a lot of register so most compiler simulate the first stack push/pop with reg but when the stack grow we need a real stack handling. If we haven't stack we must reinvent the weel or back 50 years ago in compiler theorie. The debat about the number of stack is another thing, I think we need some instruction for stack (pre-dec) on all register so we can have all stack we need. Juergen Goeritz wrote: > No, it's not a stupid question at all. I had the same > first thought when I read the posting. You may just > have a need for a seperate stack for the scheduling > handler. > > JG > > > On Tue, 23 Jul 2002, Nicolas Boulay wrote: > >>Maybe it's a stupid question, but why it's forced to try to simulate a >>simple stack. There is no hardware support for stack in the f-cpu. Why >>not using a completely different pointer for such things ? Why must we >>stuck to the use of one single stack ? >> >>nicO >> -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 19:01:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X3ac-00080Z-00 for ; Tue, 23 Jul 2002 19:36:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 19:36:50 +0200 (CEST) Received: (qmail 11005 invoked by uid 0); 23 Jul 2002 17:03:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Jul 2002 17:03:45 -0000 Received: by moria.seul.org (Postfix) id 1838F146989; Tue, 23 Jul 2002 13:03:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0882C14698C; Tue, 23 Jul 2002 13:03:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9177E146989 for ; Tue, 23 Jul 2002 13:03:43 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB609000D6F21 for f-cpu@seul.org; Tue, 23 Jul 2002 19:03:42 +0200 Message-ID: <003c01c2326a$9eee6160$86313051@hli> From: "Christophe Avoinne" To: References: <200207231427.29b0@th00.opsion.fr> <3D3D7591.80005@jetnet.ab.ca> Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 19:01:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Having a separate stack for return addresses (call stack) is a good argument for an easy backtracing of what is calling what. For garbage collectors, it is also good since data stack can only contain data relative stuff. Just a precision : the difference between the top and the bottom of the call stack gives us the call depth. But still it is not an hardware issue since we don't need to rely upon a special opcode to do so. The pre/post-increment/decrement remains a problem depending how you intend to handle asynchrounous events as exception or interrupt. ----- Original Message ----- From: "Ben Franchuk" To: Sent: Tuesday, July 23, 2002 5:26 PM Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling > Nicolas Boulay wrote: > > Stack have a main draw back : it's add a udge dependancies in a single > > poor register (the stack pointer). > > > > For security reason, i have proposed to use 2 stack : one for data, one > > for code. So buffer overflow will became really hard ! this could be > > usefull for performance, too. But most of the time, the stack will use > > the register bank... > > > Hmm just like Forth.:) > crash_os() { crash_os(); } > > -- > Ben Franchuk - Dawn * 12/24 bit cpu * > www.jetnet.ab.ca/users/bfranchuk/index.html > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Jul 23 19:13:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X3ad-00080Z-00 for ; Tue, 23 Jul 2002 19:36:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 19:36:51 +0200 (CEST) Received: (qmail 13878 invoked by uid 0); 23 Jul 2002 17:20:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 23 Jul 2002 17:20:00 -0000 Received: by moria.seul.org (Postfix) id D1FBE14698A; Tue, 23 Jul 2002 13:19:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C94C814698D; Tue, 23 Jul 2002 13:19:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 5E67414698A for ; Tue, 23 Jul 2002 13:19:58 -0400 (EDT) Received: from laposte.net (193.250.226.137) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9000980B9 for f-cpu@seul.org; Tue, 23 Jul 2002 19:19:57 +0200 Message-ID: <3D3D8EB4.3030009@laposte.net> Date: Tue, 23 Jul 2002 19:13:24 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231506.15c6@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > That's not the point. When i say "stack for code", it's a stack where > you put you're return adresse when you maid a function call or > something like that. That's not terrific for speed so i prefer having > "some" data stack like you said. > > That's an argument to change calling convention one more time ? ;p > For calling convention I've just realesed a draft about it in my folder on seul.org (in thomas\call_draft.html) it's not yet finished and I'd love your feedback and comment. But he explain that we only need to define a call convention to inter-language call so this CC don't have to be time critical, but he need to be simple, so the return address was stored in a register. But each compiler could choose to implement a stack for return address for all is internal call if he want (it seems better for security, but if programmer make good job...) This talk about two different stack was hardware related it was a software discution and it was dependent of each compiler. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jul 23 20:17:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X5E2-0000oF-01 for ; Tue, 23 Jul 2002 21:21:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 21:21:38 +0200 (CEST) Received: (qmail 21737 invoked by uid 0); 23 Jul 2002 18:14:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 23 Jul 2002 18:14:11 -0000 Received: by moria.seul.org (Postfix) id 95FA2146806; Tue, 23 Jul 2002 14:14:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5E842146990; Tue, 23 Jul 2002 14:14:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id E5BB6146806 for ; Tue, 23 Jul 2002 14:14:07 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17X4Di-0000Fc-00 for f-cpu@seul.org; Tue, 23 Jul 2002 20:17:14 +0200 Date: Tue, 23 Jul 2002 20:17:14 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <3D3D4386.5020306@laposte.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 23 Jul 2002, Thomas Lavergne wrote: > >Have you ever written a compiler ? Yeah, C and Pascal. >A stack is the most simple and clean solution to handle a lot of thing.=20 >We have a lot of register so most compiler simulate the first stack=20 >push/pop with reg but when the stack grow we need a real stack handling. > >If we haven't stack we must reinvent the weel or back 50 years ago in=20 >compiler theorie. > >The debat about the number of stack is another thing, I think we need=20 >some instruction for stack (pre-dec) on all register so we can have all=20 >stack we need. I think the number of stack is the important case anyway. Since every process has it's own stack with operating systems like Linux one only has to take care that the scheduler timer interrupt should not switch to other process stack without properly resolving everything of the previous process. That's why a lot of processors use different stacks for the interrupt handling and normal operating modes (switched by hardware). In which way the normal stack stays clean of interrupt/trap stuff. The previous descriptions that I read on this list gave the impression to me that each process' own stack can be implemented without changes of architecture. Atomic INC/DEC with PUSH/POP style operation is not really necessary for sequential code if interrupts are handled separately. JG >Juergen Goeritz wrote: >> No, it's not a stupid question at all. I had the same >> first thought when I read the posting. You may just >> have a need for a seperate stack for the scheduling >> handler. >>=20 >> JG >>=20 >>=20 >> On Tue, 23 Jul 2002, Nicolas Boulay wrote: >>=20 >>>Maybe it's a stupid question, but why it's forced to try to simulate a >>>simple stack. There is no hardware support for stack in the f-cpu. Why >>>not using a completely different pointer for such things ? Why must we >>>stuck to the use of one single stack ? >>> >>>nicO >>> > > > >--=20 >Thomas Lavergne "Le vrai r=EAveur est celui qui r=EA= ve > de l'impossible." (Elsa Triolet) >thomas.lavergne@laposte.net >d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jul 23 20:21:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X5E3-0000oF-00 for ; Tue, 23 Jul 2002 21:21:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 21:21:39 +0200 (CEST) Received: (qmail 24578 invoked by uid 0); 23 Jul 2002 18:14:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 23 Jul 2002 18:14:13 -0000 Received: by moria.seul.org (Postfix) id A88FD146990; Tue, 23 Jul 2002 14:14:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89F11146992; Tue, 23 Jul 2002 14:14:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 1024F146990 for ; Tue, 23 Jul 2002 14:14:10 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17X4HX-0000HY-00 for f-cpu@seul.org; Tue, 23 Jul 2002 20:21:11 +0200 Date: Tue, 23 Jul 2002 20:21:11 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling In-Reply-To: <000e01c23268$0cea3b60$86313051@hli> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Basically there is no problem with stack handling at all in the f-cpu design. Worst case one can use lots of registers to setup several stacks. That's why I like the versatility of the f-cpu approach. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Jul 23 20:24:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X5E6-0000oF-00 for ; Tue, 23 Jul 2002 21:21:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 21:21:42 +0200 (CEST) Received: (qmail 12671 invoked by uid 0); 23 Jul 2002 18:25:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Jul 2002 18:25:03 -0000 Received: by moria.seul.org (Postfix) id EA4B414698C; Tue, 23 Jul 2002 14:25:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0933146992; Tue, 23 Jul 2002 14:25:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 5105D14698C for ; Tue, 23 Jul 2002 14:25:00 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-2.free.fr (Postfix) with ESMTP id 600085FE33 for ; Tue, 23 Jul 2002 20:24:59 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 3A4C2580C4; Tue, 23 Jul 2002 20:24:59 +0200 (MEST) To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling Message-ID: <1027448699.3d3d9f7b2da43@imp.free.fr> Date: Tue, 23 Jul 2002 20:24:59 +0200 (MEST) From: Cedric BAIL References: <200207231506.15c6@th00.opsion.fr> <3D3D8EB4.3030009@laposte.net> In-Reply-To: <3D3D8EB4.3030009@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > For calling convention I've just realesed a draft about it in my folder I have read it, it's a good resume, and I have only one thing to say. Invert return address and stack pointer. Two reasons for this choice : on MIPS the return address is at the end of the register bank, so why not use the same idee. And if we need frame pointer, or some thing like that we will creat separate the pointer with an jump destination, and I think that's not clean. An other question, why didn't you speak about the relocation problem (big problem on F-CPU) ? > on seul.org (in thomas\call_draft.html) it's not yet finished and I'd > love your feedback and comment. > But he explain that we only need to define a call convention to > inter-language call so this CC don't have to be time critical, but he > need to be simple, so the return address was stored in a register. I agree. > But each compiler could choose to implement a stack for return address > for all is internal call if he want (it seems better for security, but > if programmer make good job...) Programmer make good job ;-) Prefer to say compiler do the must do the best work they can, because programmer didn't care about security and speed in most case. > This talk about two different stack was hardware related it was a > software discution and it was dependent of each compiler. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Tue Jul 23 20:37:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X5E6-0000oF-01 for ; Tue, 23 Jul 2002 21:21:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 21:21:42 +0200 (CEST) Received: (qmail 26670 invoked by uid 0); 23 Jul 2002 18:30:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 23 Jul 2002 18:30:15 -0000 Received: by moria.seul.org (Postfix) id A02A7146929; Tue, 23 Jul 2002 14:30:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B91B146992; Tue, 23 Jul 2002 14:30:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 8E60F146929 for ; Tue, 23 Jul 2002 14:30:13 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17X4XA-0000M9-00 for f-cpu@seul.org; Tue, 23 Jul 2002 20:37:20 +0200 Date: Tue, 23 Jul 2002 20:37:20 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <1027448699.3d3d9f7b2da43@imp.free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, 23 Jul 2002, Cedric BAIL wrote: > >> For calling convention I've just realesed a draft about it in my folder > >I have read it, it's a good resume, and I have only one thing to say. Invert >return address and stack pointer. Two reasons for this choice : on MIPS >the return address is at the end of the register bank, so why not use the same >idee. And if we need frame pointer, or some thing like that we will creat >separate the pointer with an jump destination, and I think that's not clean. Hi, don't think this it's clever to copy this MIPS approach on a processor that has no fixed number of registers by default. JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 23 21:17:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X5EC-0000oF-01 for ; Tue, 23 Jul 2002 21:21:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 21:21:48 +0200 (CEST) Received: (qmail 15363 invoked by uid 0); 23 Jul 2002 19:08:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 23 Jul 2002 19:08:26 -0000 Received: by moria.seul.org (Postfix) id C93DF146991; Tue, 23 Jul 2002 15:08:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADFDE146994; Tue, 23 Jul 2002 15:08:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 5BFAE146991 for ; Tue, 23 Jul 2002 15:08:24 -0400 (EDT) Received: from f-cpu.org (kdl16-41.n.club-internet.fr [213.44.18.41]) by relay-3v.club-internet.fr (Postfix) with ESMTP id DFF4316D9 for ; Tue, 23 Jul 2002 21:08:20 +0200 (CEST) Message-ID: <3D3DABC6.89B52CA8@f-cpu.org> Date: Tue, 23 Jul 2002 21:17:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling References: <3D3CDEB2.2070009@laposte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Thomas Lavergne wrote: > I've reread the manual and found a problem in stack handling suggestion > > The manual say : > > pop = load 8, r3, r2 > push = store -8, r3, r2 > > With r3 a stack pointer and r2 a value to be pushed/poped to/from the stack. > > but this was false, for example try to make : > push r2 > pop r2 > > you obtain this code > > store -8, r3, r2 > load 8, r3, r2 > > you push r2 at r3 address and increment r3, > and after you get in r2 the value at r3 and decrement the pointer > so after executing this you don't have the same value in r2... Bug > > We can't manage a stack without pre-decrement instruction, or we need a > lot of tricks and obtain very bad code... there is something very important to note here : we CAN'T use pre-inc/decrement in F-CPU. the obvious conclusion is that we have to use some tricks. This does not annoy me for the simple reason that F-CPU works best when global optimisations are applied (all the program is flattened and cross-routine optimisations and allocation are done). In this context, your remark is not an issue. However, i think that the people who discussed about the parameter passing, have forgotten a VERY IMPORTANT DETAIL. but i doubt they would care listen, even though this is absolutely critical for performance. If they don't want to lose a factor of roughly 5 on their codes, they MUST specify which registers will be used as pointers. FC0 uses 8 pointers to data and 8 pointers to instructions : a software-managed "return stack" and "data stack" MUST be allocated (that is : there remains 48 registers for the rest). Of course it is not usual and it might confuse some people. However, it is much more easier to GCC which will only use these pointers to access the memory, preventing unacceptable latencies. GCC has a parameter (in the machine description files) that says if there are pointer-only registers, and we can statically allocate 8 for data and 8 for instructions. Please take into account that a SW-managed stack is an excellent place for doing optimisations. What is written in the last manual is a big issue for F-CPU : the unique function return address register is a critical "bottleneck" because a pointer can't be moved to another register (the value can, but the hidden flags won't be moved, so the next use will create a stall during maybe 5 or 10 cycles). I think and know that there are several "inconsistencies". but the key is to NOT think like with usual CPUs. Ask yourself : what the CPU has to do and what is the simplest, fastest way to perform the task. F-CPU is not MIPS : r63 is not hardwired in the instructions when a call or return is performed. We have the choice of using 63 registers for storing the return address. 8 of them can be used "statically", whatever their number, to reduce the re-fetching overhead. Same for data. It is simpler and faster to allocate 8 data and 8 instruction pointers, rather than trying to reuse the scheme used by other CPUs "because that's all people are used to". If somebody cares... > Tom > Thomas Lavergne WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 23 21:39:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X63p-0001bT-00 for ; Tue, 23 Jul 2002 22:15:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 22:15:09 +0200 (CEST) Received: (qmail 3232 invoked by uid 0); 23 Jul 2002 19:30:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 23 Jul 2002 19:30:36 -0000 Received: by moria.seul.org (Postfix) id 3492F146993; Tue, 23 Jul 2002 15:30:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A7A3146996; Tue, 23 Jul 2002 15:30:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id D2236146993 for ; Tue, 23 Jul 2002 15:30:34 -0400 (EDT) Received: from f-cpu.org (kll1-202.n.club-internet.fr [213.44.91.202]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7937E16DE for ; Tue, 23 Jul 2002 21:30:28 +0200 (CEST) Message-ID: <3D3DB0EF.7726FB2A@f-cpu.org> Date: Tue, 23 Jul 2002 21:39:27 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> <000e01c23241$ef9493b0$86313051@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > I tell you, your stack design is bad or incomplete, should I say at least. it is simple and you do whatever you want with it, even waste cycles if you feel like it's necessary. > Post-increment/decrement is a no use without pre-decrement/increment. pre-modification is not possible, as you know. but use your imagination. > Hummm... i think we can remove one instruction. > > // pushing r1..r5 > store -8,r62,r1 > store -8,r62,r2 > store -8,r62,r3 > store -8,r62,r4 > store -8,r62,r5 > ... > addi +8,r62,r62 // we still need to adjust the stack pointer don't do that, unless you like to waste cycles. The add will flush the "pointer" flag, which means that the result will be checked inside the TLB. If you don't check the TLB, you will have at least several "dead" cycles, during which the CPU will refresh the flags. Furthermore, F-CPU is well adapted to contain a part of the stack in the registers. that is : it can be viewed as a "cache", though this must be managed by the compiler. Why waste at least 2 cycles (push and pop of a data, for its creation and consumption) when you can ask the compiler to keep data in the register set for a limited time ? Since the compiler can know the data lifelength, it can decide if it must be pushed/popped to memory (long lifelength) or kept in the registers. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 23 21:41:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X63q-0001bT-00 for ; Tue, 23 Jul 2002 22:15:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 22:15:10 +0200 (CEST) Received: (qmail 16298 invoked by uid 0); 23 Jul 2002 19:32:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 23 Jul 2002 19:32:27 -0000 Received: by moria.seul.org (Postfix) id A6019146998; Tue, 23 Jul 2002 15:32:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FCFA146997; Tue, 23 Jul 2002 15:32:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 6606B146994 for ; Tue, 23 Jul 2002 15:32:26 -0400 (EDT) Received: from f-cpu.org (kll1-202.n.club-internet.fr [213.44.91.202]) by relay-2v.club-internet.fr (Postfix) with ESMTP id C599116CC for ; Tue, 23 Jul 2002 21:32:11 +0200 (CEST) Message-ID: <3D3DB158.F4D227AD@f-cpu.org> Date: Tue, 23 Jul 2002 21:41:12 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> <000e01c23241$ef9493b0$86313051@hli> <002b01c23242$71c261f0$86313051@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > sorry some errors : > > 1) > // pushing r1..r5 > store -8,r62,r1 > store -8,r62,r2 > store -8,r62,r3 > store -8,r62,r4 > store -0,r62,r5 > ... > // popping r1..r5 > load +8,r62,r5 > load +8,r62,r4 > load +8,r62,r3 > load +8,r62,r2 > load +0,r62,r1 at last you got it right. it is still possible to find extreme cases where there could be a problem, but you have understood the trick. congratulations :-D WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 23 21:56:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X63q-0001bT-01 for ; Tue, 23 Jul 2002 22:15:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Jul 2002 22:15:10 +0200 (CEST) Received: (qmail 27080 invoked by uid 0); 23 Jul 2002 19:36:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 23 Jul 2002 19:36:13 -0000 Received: by moria.seul.org (Postfix) id EA8B3146994; Tue, 23 Jul 2002 15:36:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C4813146997; Tue, 23 Jul 2002 15:36:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7D72E146994 for ; Tue, 23 Jul 2002 15:36:12 -0400 (EDT) Received: from ifrance.com (vlt4-102.n.club-internet.fr [194.158.109.102]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 24B3516C9 for ; Tue, 23 Jul 2002 21:36:10 +0200 (CEST) Message-ID: <3D3DB4D7.A089BB29@ifrance.com> Date: Tue, 23 Jul 2002 21:56:07 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231427.29b0@th00.opsion.fr> <000e01c23268$0cea3b60$86313051@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > But each compiler could choose to implement a stack for return address > for all is internal call if he want (it seems better for security, but > if programmer make good job...) When you read some example, it's really tricky not to make security hole with C ! --- > don't think this it's clever to copy this MIPS approach on a > processor that has no fixed number of registers by default. > > JG Hue ? the field in ther register set is fixed (6 bits 64 registers) that's all. The other point is that the number of chunk in SIMD mode aren't fixed and are a power of 2. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 22:11:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8D7-00037n-00 for ; Wed, 24 Jul 2002 00:32:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:32:53 +0200 (CEST) Received: (qmail 19995 invoked by uid 0); 23 Jul 2002 20:13:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 23 Jul 2002 20:13:23 -0000 Received: by moria.seul.org (Postfix) id B289D146996; Tue, 23 Jul 2002 16:13:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F352146999; Tue, 23 Jul 2002 16:13:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id DE518146996 for ; Tue, 23 Jul 2002 16:13:20 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB3A20011BF17 for f-cpu@seul.org; Tue, 23 Jul 2002 22:13:20 +0200 Message-ID: <002301c23285$1bf4ea70$86313051@hli> From: "Christophe Avoinne" To: References: <200207231427.29b0@th00.opsion.fr> <000e01c23268$0cea3b60$86313051@hli> Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling Date: Tue, 23 Jul 2002 22:11:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Please, I would like to know if using several registers as stack pointers pointing out on the same stack but with interleaved offset is a good way to reduce dependency register (in fact using contiguous store +8,r64,r? has or not depencency problem like in x86 ?) > to push r1..r6, do : > > addi -8 ,r62,r8 > store -16,r62,r1 > store -16,r8 ,r2 > store -16,r62,r3 > store -16,r8 ,r4 > > store -0 ,r62,r5 > store -0 ,r8 ,r6 > > instead of : > > store -8,r62,r1 > store -8,r62,r2 > store -8,r62,r3 > store -8,r62,r4 > > store -8,r62,r5 > store -0,r62,r6 > > why not a triple stack ? > > addi -8 ,r62,r8 > addi -16,r62,r9 > store -24,r62,r1 > store -24,r8 ,r2 > store -24,r9 ,r3 > store -0 ,r62,r4 > > store -0 ,r8 ,r5 > store -0 ,r9 ,r6 > > ----- Original Message ----- > From: "Nicolas Boulay" > To: > Sent: Tuesday, July 23, 2002 4:27 PM > Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling > > > Stack have a main draw back : it's add a udge dependancies in a single > poor register (the stack pointer). > > For security reason, i have proposed to use 2 stack : one for data, one > for code. So buffer overflow will became really hard ! this could be > usefull for performance, too. But most of the time, the stack will use > the register bank... > > And that doesn't solve the problem of push and pop. > > nicO > > -----Message d'origine----- > De: Thomas Lavergne > A: f-cpu@seul.org > Date: 23/07/02 > Objet: Re: Rep:Re: [f-cpu] Stack handling > > Have you ever written a compiler ? > > A stack is the most simple and clean solution to handle a lot of thing. > We have a lot of register so most compiler simulate the first stack > push/pop with reg but when the stack grow we need a real stack handling. > > If we haven't stack we must reinvent the weel or back 50 years ago in > compiler theorie. > > The debat about the number of stack is another thing, I think we need > some instruction for stack (pre-dec) on all register so we can have all > stack we need. > > Juergen Goeritz wrote: > > No, it's not a stupid question at all. I had the same > > first thought when I read the posting. You may just > > have a need for a seperate stack for the scheduling > > handler. > > > > JG > > > > > > On Tue, 23 Jul 2002, Nicolas Boulay wrote: > > > >>Maybe it's a stupid question, but why it's forced to try to simulate a > >>simple stack. There is no hardware support for stack in the f-cpu. Why > >>not using a completely different pointer for such things ? Why must we > >>stuck to the use of one single stack ? > >> > >>nicO > >> > > > > -- > Thomas Lavergne "Le vrai rêveur est celui qui rêve > de l'impossible." (Elsa > Triolet) > thomas.lavergne@laposte.net > d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > ____________________________________________________________________________ > __ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jul 23 22:14:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8DF-00037n-00 for ; Wed, 24 Jul 2002 00:33:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:33:01 +0200 (CEST) Received: (qmail 32051 invoked by uid 0); 23 Jul 2002 20:14:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 23 Jul 2002 20:14:40 -0000 Received: by moria.seul.org (Postfix) id 7F791146997; Tue, 23 Jul 2002 16:14:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57B6914699A; Tue, 23 Jul 2002 16:14:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 92707146997 for ; Tue, 23 Jul 2002 16:14:38 -0400 (EDT) Message-ID: <20020723201437.70147.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 13:14:37 PDT Date: Tue, 23 Jul 2002 13:14:37 -0700 (PDT) From: jaap stolk Subject: [f-cpu] fcpusim picture To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, if anybody looked at the c-simulator code, and can't see how i have thrown it together, this might be helpful: http://f-cpu.seul.org/~f-cpu/new/fcpusim_23_july_2002.png (uploaded last night) it's very similar to the info in the files and YG's paper. (and in theory it should be the same) points of concern for now are: -the combine of bypass_possible and register_needed info on the x-bar (x-bar already needs all the time we can get) -checking the scoreboard and adding a new instruction must be done in the same cycle. (or we have to find some way to "bypass" the scoreboard) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Jul 23 22:17:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8DU-00037n-00 for ; Wed, 24 Jul 2002 00:33:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:33:16 +0200 (CEST) Received: (qmail 8735 invoked by uid 0); 23 Jul 2002 20:19:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Jul 2002 20:19:03 -0000 Received: by moria.seul.org (Postfix) id 12DA4146999; Tue, 23 Jul 2002 16:19:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D3F4C14699B; Tue, 23 Jul 2002 16:19:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 5B069146999 for ; Tue, 23 Jul 2002 16:19:01 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D2EB3A20011BFF6 for f-cpu@seul.org; Tue, 23 Jul 2002 22:19:00 +0200 Message-ID: <004801c23285$e6f0b8d0$86313051@hli> From: "Christophe Avoinne" To: References: <20020723201437.70147.qmail@web14208.mail.yahoo.com> Subject: Re: [f-cpu] fcpusim picture Date: Tue, 23 Jul 2002 22:17:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Please could you tell me what you used to draw this picture ? ----- Original Message ----- From: "jaap stolk" To: Sent: Tuesday, July 23, 2002 10:14 PM Subject: [f-cpu] fcpusim picture > Hi, > > if anybody looked at the c-simulator code, > and can't see how i have thrown it together, > this might be helpful: > > http://f-cpu.seul.org/~f-cpu/new/fcpusim_23_july_2002.png > > (uploaded last night) > > it's very similar to the info in the files and YG's > paper. (and in theory it should be the same) > > points of concern for now are: > -the combine of bypass_possible and register_needed > info on the x-bar (x-bar already needs all the time > we can get) > -checking the scoreboard and adding a new instruction > must be done in the same cycle. (or we have to find > some way to "bypass" the scoreboard) > > jaap. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jul 23 22:24:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8DZ-00037n-00 for ; Wed, 24 Jul 2002 00:33:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:33:21 +0200 (CEST) Received: (qmail 5913 invoked by uid 0); 23 Jul 2002 20:24:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 23 Jul 2002 20:24:57 -0000 Received: by moria.seul.org (Postfix) id AEDEF14699A; Tue, 23 Jul 2002 16:24:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A01BB14699C; Tue, 23 Jul 2002 16:24:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 2226914699A for ; Tue, 23 Jul 2002 16:24:56 -0400 (EDT) Message-ID: <20020723202455.7483.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.164] by web14206.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 13:24:55 PDT Date: Tue, 23 Jul 2002 13:24:55 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] fcpusim picture To: f-cpu@seul.org In-Reply-To: <004801c23285$e6f0b8d0$86313051@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Christophe Avoinne wrote: > Please could you tell me what you used to draw this > picture ? > i used windows 98 paint (just draw / move / copy the pixels ;-) ) i also can go to the other end of the spectrum: i just made some macro's that make it realy easy to draw (2D!) lines, text and rectangles in pov-ray.. any prefered drawing program / format ? jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Tue Jul 23 22:50:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8EH-00037n-00 for ; Wed, 24 Jul 2002 00:34:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:34:05 +0200 (CEST) Received: (qmail 5925 invoked by uid 0); 23 Jul 2002 20:56:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 23 Jul 2002 20:56:35 -0000 Received: by moria.seul.org (Postfix) id C8CE2146811; Tue, 23 Jul 2002 16:56:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A31F114699C; Tue, 23 Jul 2002 16:56:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from lvdi.net (unknown [216.24.138.2]) by moria.seul.org (Postfix) with SMTP id EEBAA146811 for ; Tue, 23 Jul 2002 16:56:32 -0400 (EDT) Received: from wyrm ([216.24.142.44]) by lvdi.net ; Tue, 23 Jul 2002 13:56:28 2000 PDT Received: from lee by wyrm with local (Exim 3.35 #1 (Debian)) id 17X6c0-0001A9-00 for ; Tue, 23 Jul 2002 16:50:28 -0400 Date: Tue, 23 Jul 2002 16:50:28 -0400 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling Message-ID: <20020723205028.GA4458@wyrm> References: <3D3CDEB2.2070009@laposte.net> <3D3DABC6.89B52CA8@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3DABC6.89B52CA8@f-cpu.org> User-Agent: Mutt/1.3.28i From: Lee Salzman Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 23, 2002 at 09:17:26PM +0200, Yann Guidon wrote: > hi ! > > Thomas Lavergne wrote: > > I've reread the manual and found a problem in stack handling suggestion > > > > The manual say : > > > > pop = load 8, r3, r2 > > push = store -8, r3, r2 > > > > With r3 a stack pointer and r2 a value to be pushed/poped to/from the stack. > > > > but this was false, for example try to make : > > push r2 > > pop r2 > > > > you obtain this code > > > > store -8, r3, r2 > > load 8, r3, r2 > > > > you push r2 at r3 address and increment r3, > > and after you get in r2 the value at r3 and decrement the pointer > > so after executing this you don't have the same value in r2... Bug > > > > We can't manage a stack without pre-decrement instruction, or we need a > > lot of tricks and obtain very bad code... > > there is something very important to note here : > we CAN'T use pre-inc/decrement in F-CPU. > F-CPU doesn't really need pre-inc or pre-dec either. The most efficient way to push a lot of values on the stack is to: 1) decrement the stack pointer by the amount of space we need for arguments 2) just store all the arguments in parallel to the stack space On a superscalar CPU, this scheme is even better, because the processor doesn't have to get all tricky about handling dependencies between the store instructions with pre-dec, and also can help make for better cache usage. On the other hand, post-inc can be useful for popping stuff from the stack, but I would not fret at all over pre-dec. > the obvious conclusion is that we have to use some tricks. > > This does not annoy me for the simple reason that F-CPU works > best when global optimisations are applied (all the program > is flattened and cross-routine optimisations and allocation > are done). In this context, your remark is not an issue. > The tricks that need to be applied to the F-CPU really aren't tricks. They are sensible architecture constraints. As someone who regularly writes optimizing backends, I can say nothing in the F-CPU phases me in the least. :) > However, i think that the people who discussed about the > parameter passing, have forgotten a VERY IMPORTANT DETAIL. > but i doubt they would care listen, even though this is absolutely > critical for performance. If they don't want to lose a factor > of roughly 5 on their codes, they MUST specify which registers > will be used as pointers. FC0 uses 8 pointers to data and 8 pointers > to instructions : a software-managed "return stack" and "data stack" > MUST be allocated (that is : there remains 48 registers for the rest). > > Of course it is not usual and it might confuse some people. > However, it is much more easier to GCC which will only use > these pointers to access the memory, preventing unacceptable > latencies. GCC has a parameter (in the machine description > files) that says if there are pointer-only registers, and we > can statically allocate 8 for data and 8 for instructions. > GCC is fairly old stuff, though. You could easily write algorithms to make better use of this idiom without artificially setting a boundary between what is a data register and what is an address register. > Please take into account that a SW-managed stack is an excellent > place for doing optimisations. What is written in the last manual > is a big issue for F-CPU : the unique function return address > register is a critical "bottleneck" because a pointer can't > be moved to another register (the value can, but the hidden > flags won't be moved, so the next use will create a stall > during maybe 5 or 10 cycles). > > I think and know that there are several "inconsistencies". > but the key is to NOT think like with usual CPUs. > Ask yourself : what the CPU has to do and what is the simplest, > fastest way to perform the task. > > F-CPU is not MIPS : r63 is not hardwired in the instructions > when a call or return is performed. We have the choice of using > 63 registers for storing the return address. 8 of them can be used > "statically", whatever their number, to reduce the re-fetching overhead. > Same for data. It is simpler and faster to allocate 8 data and > 8 instruction pointers, rather than trying to reuse the scheme > used by other CPUs "because that's all people are used to". > Interprocedural register allocation is great stuff. When the call chain is known, it's a simple matter to determine the best place to store the return addresses without ever resorting to stack use. > If somebody cares... > > > Tom > > Thomas Lavergne > WHYGEE Lee ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 23 14:35:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8FT-00037n-00 for ; Wed, 24 Jul 2002 00:35:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:35:19 +0200 (CEST) Received: (qmail 26783 invoked by uid 0); 23 Jul 2002 22:09:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Jul 2002 22:09:56 -0000 Received: by moria.seul.org (Postfix) id DAFBD1469A0; Tue, 23 Jul 2002 18:09:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B92A01469A4; Tue, 23 Jul 2002 18:09:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a248.home.uni-hannover.de [130.75.232.248]) by moria.seul.org (Postfix) with ESMTP id 19B291469A0 for ; Tue, 23 Jul 2002 18:09:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00547; Tue, 23 Jul 2002 14:35:44 +0200 Message-ID: <20020723143544.28147@thrai.stud.uni-hannover.de> Date: Tue, 23 Jul 2002 14:35:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027355592.3d3c33c8c9ba4@imp.free.fr>; from Cedric BAIL on Mon, Jul 22, 2002 at 06:33:12PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > I have uploaded on seul a new manual : > http://f-cpu.seul.org/cedric/ > > Change are : > - New index at the end of the manual > - Add new dshift instructions (must be verified) Unfortunately, there are errors: the shift counts are wrong. For `dshiftl', they are r1 = r2 << (r3 % size) r1^1 = r2 >> (size - r3 % size) and similar for the other `d-' operations. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 23 15:20:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8FW-00037n-00 for ; Wed, 24 Jul 2002 00:35:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:35:22 +0200 (CEST) Received: (qmail 8133 invoked by uid 0); 23 Jul 2002 22:09:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 23 Jul 2002 22:09:55 -0000 Received: by moria.seul.org (Postfix) id 0008C14699C; Tue, 23 Jul 2002 18:09:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D67D81469A1; Tue, 23 Jul 2002 18:09:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a248.home.uni-hannover.de [130.75.232.248]) by moria.seul.org (Postfix) with ESMTP id C8F3C14699C for ; Tue, 23 Jul 2002 18:09:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00650; Tue, 23 Jul 2002 15:20:27 +0200 Message-ID: <20020723152027.46636@thrai.stud.uni-hannover.de> Date: Tue, 23 Jul 2002 15:20:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <00c601c2323d$fa0d3a80$86313051@hli>; from Christophe Avoinne on Tue, Jul 23, 2002 at 01:39:53PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi! Guys, you're on the wrong track. You're still thinking Intel-style. On Tue, Jul 23, 2002 at 01:39:53PM +0200, Christophe Avoinne wrote: > If you want to invent a new OS which doesn't need a stack, well okay. But my > oppinion is that you would need to be friendly with software programmers and > don't complicate their jobs because you only think about the hardware part > without any regard about the habits of programmers. > > I really understand the whys you prefer to avoid a pre-increment/decrement, > but the fact is there are situations we need it. Then do it manually: subi 8, , // is the register used as a stack pointer storei -8, , ... ... store , ... // last push doesn't use postdecrement Alternatively, allocate a larger piece of stack memory at once and fill it later. In either case, calling a signal handler is not a problem at all, as long as user and kernel mode agree on the stack pointer register (which will be defined in the user<->kernel API and/or the calling conventions). In general, doing stack-like operations on a register machine is not a good idea. On Intel CPUs, you're forced to do it because you have only eight registers, but the F-CPU has 63 of them (r0 not counted). There should rarely be a need for stack operations, except on function entry/exit (where you can use storem/loadm). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Jul 24 00:16:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X8Fg-00037n-00 for ; Wed, 24 Jul 2002 00:35:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 00:35:32 +0200 (CEST) Received: (qmail 6886 invoked by uid 0); 23 Jul 2002 22:18:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 23 Jul 2002 22:18:28 -0000 Received: by moria.seul.org (Postfix) id E81651469A1; Tue, 23 Jul 2002 18:18:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A467B1469A2; Tue, 23 Jul 2002 18:18:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id F3E591469A3 for ; Tue, 23 Jul 2002 18:18:25 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D32A1F90009B4D2 for f-cpu@seul.org; Wed, 24 Jul 2002 00:18:24 +0200 Message-ID: <00a101c23296$955a1ff0$86313051@hli> From: "Christophe Avoinne" To: References: <200207231122.2ddc@th00.opsion.fr> <00c601c2323d$fa0d3a80$86313051@hli> <20020723152027.46636@thrai.stud.uni-hannover.de> Subject: Re: Rep:Re: [f-cpu] Stack handling Date: Wed, 24 Jul 2002 00:16:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yes i know, i was thinking about allocating first stack space then filling them to avoid the stack crashing problem, but I didn't speak about. ----- Original Message ----- From: "Michael Riepe" To: Sent: Tuesday, July 23, 2002 3:20 PM Subject: Re: Rep:Re: [f-cpu] Stack handling > Hi! > > Guys, you're on the wrong track. You're still thinking Intel-style. > > On Tue, Jul 23, 2002 at 01:39:53PM +0200, Christophe Avoinne wrote: > > If you want to invent a new OS which doesn't need a stack, well okay. But my > > oppinion is that you would need to be friendly with software programmers and > > don't complicate their jobs because you only think about the hardware part > > without any regard about the habits of programmers. > > > > I really understand the whys you prefer to avoid a pre-increment/decrement, > > but the fact is there are situations we need it. > > Then do it manually: > > subi 8, , // is the register used as a stack pointer > storei -8, , ... > ... > store , ... // last push doesn't use postdecrement > > Alternatively, allocate a larger piece of stack memory at once and fill it > later. In either case, calling a signal handler is not a problem at all, > as long as user and kernel mode agree on the stack pointer register (which > will be defined in the user<->kernel API and/or the calling conventions). > > In general, doing stack-like operations on a register machine is not a > good idea. On Intel CPUs, you're forced to do it because you have only > eight registers, but the F-CPU has 63 of them (r0 not counted). There > should rarely be a need for stack operations, except on function > entry/exit (where you can use storem/loadm). > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 24 00:44:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17X9Ba-0003nN-00 for ; Wed, 24 Jul 2002 01:35:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 01:35:22 +0200 (CEST) Received: (qmail 4526 invoked by uid 0); 23 Jul 2002 22:44:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 23 Jul 2002 22:44:52 -0000 Received: by moria.seul.org (Postfix) id 414FA1469A2; Tue, 23 Jul 2002 18:44:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3830E1469A4; Tue, 23 Jul 2002 18:44:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a248.home.uni-hannover.de [130.75.232.248]) by moria.seul.org (Postfix) with ESMTP id E54551469A2 for ; Tue, 23 Jul 2002 18:44:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00795; Wed, 24 Jul 2002 00:44:48 +0200 Message-ID: <20020724004448.03991@thrai.stud.uni-hannover.de> Date: Wed, 24 Jul 2002 00:44:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231506.15c6@th00.opsion.fr> <3D3D8EB4.3030009@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D3D8EB4.3030009@laposte.net>; from Thomas Lavergne on Tue, Jul 23, 2002 at 07:13:24PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 23, 2002 at 07:13:24PM +0200, Thomas Lavergne wrote: [...] > For calling convention I've just realesed a draft about it in my folder > on seul.org (in thomas\call_draft.html) it's not yet finished and I'd > love your feedback and comment. Is it so large that you can't convert it to ASCII and post it here? On the other hand, we already had this discussion, didn't we? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 24 01:51:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XBU6-0005Ia-00 for ; Wed, 24 Jul 2002 04:02:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 04:02:38 +0200 (CEST) Received: (qmail 19067 invoked by uid 0); 24 Jul 2002 00:12:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 24 Jul 2002 00:12:29 -0000 Received: by moria.seul.org (Postfix) id 20B8E1469A3; Tue, 23 Jul 2002 20:12:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0AE91469A5; Tue, 23 Jul 2002 20:12:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 46CCB1469A3 for ; Tue, 23 Jul 2002 20:12:26 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-197.jetnet.ab.ca [207.34.60.197]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6NNsA8P036084 for ; Tue, 23 Jul 2002 17:55:38 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3DEBF3.3000208@jetnet.ab.ca> Date: Tue, 23 Jul 2002 17:51:15 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling References: <3D3CDEB2.2070009@laposte.net> <3D3DABC6.89B52CA8@f-cpu.org> <20020723205028.GA4458@wyrm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Lee Salzman wrote: > Interprocedural register allocation is great stuff. When the call > chain is known, it's a simple matter to determine the best place to > store the return addresses without ever resorting to stack use. Sounds like computers have come full circle, to square ONE in memory addressing. Old machines stored the return address in the 1st word of the program or in a specific return register. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 24 03:00:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XBUy-0005Ia-00 for ; Wed, 24 Jul 2002 04:03:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 04:03:32 +0200 (CEST) Received: (qmail 15958 invoked by uid 0); 24 Jul 2002 00:51:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 24 Jul 2002 00:51:37 -0000 Received: by moria.seul.org (Postfix) id CC265146984; Tue, 23 Jul 2002 20:51:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C29D71469A4; Tue, 23 Jul 2002 20:51:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 7972A146984 for ; Tue, 23 Jul 2002 20:51:36 -0400 (EDT) Received: from f-cpu.org (kdl16-7.n.club-internet.fr [213.44.18.7]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1E1DD168D for ; Wed, 24 Jul 2002 02:51:34 +0200 (CEST) Message-ID: <3D3DFC37.6CE62EAF@f-cpu.org> Date: Wed, 24 Jul 2002 03:00:39 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231427.29b0@th00.opsion.fr> <000e01c23268$0cea3b60$86313051@hli> <002301c23285$1bf4ea70$86313051@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i can't read all the messages in this thread, but i see that this last message contains some good things. First, nicO's remark about buffer overflows etc. :-) Then i have to answer Christophe's questions : Christophe Avoinne wrote: > > Please, I would like to know if using several registers as stack pointers > pointing out on the same stack but with interleaved offset is a good way to > reduce dependency register (in fact using contiguous store +8,r64,r? has or > not depencency problem like in x86 ?) in fact, it is much better ! it's not a problem of dependency here, but of scheduling. it takes several cycles to update a pointer, that is : the "distance" between two uses of a same pointer in a register is rather large, around 6 cycles. If you can interleave memory references, you can avoid the 6 cycles stalls. if you interleave the stack pointers 2x, then your push and pop duration is one half. yet you have to find other instructions to interleave, but that's another story. > > to push r1..r6, do : > > > > addi -8 ,r62,r8 > > store -16,r62,r1 > > store -16,r8 ,r2 > > store -16,r62,r3 > > store -16,r8 ,r4 > > > > store -0 ,r62,r5 > > store -0 ,r8 ,r6 > > > > instead of : > > > > store -8,r62,r1 > > store -8,r62,r2 > > store -8,r62,r3 > > store -8,r62,r4 > > > > store -8,r62,r5 > > store -0,r62,r6 > > > > why not a triple stack ? > > > > addi -8 ,r62,r8 > > addi -16,r62,r9 > > store -24,r62,r1 > > store -24,r8 ,r2 > > store -24,r9 ,r3 > > store -0 ,r62,r4 > > > > store -0 ,r8 ,r5 > > store -0 ,r9 ,r6 > > > > ----- Original Message ----- > > From: "Nicolas Boulay" > > To: > > Sent: Tuesday, July 23, 2002 4:27 PM > > Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling > > > > > > Stack have a main draw back : it's add a udge dependancies in a single > > poor register (the stack pointer). > > > > For security reason, i have proposed to use 2 stack : one for data, one > > for code. So buffer overflow will became really hard ! this could be > > usefull for performance, too. But most of the time, the stack will use > > the register bank... > > > > And that doesn't solve the problem of push and pop. > > > > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Jul 24 06:36:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XGai-0000Yy-01 for ; Wed, 24 Jul 2002 09:29:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 09:29:48 +0200 (CEST) Received: (qmail 13155 invoked by uid 0); 24 Jul 2002 04:42:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 24 Jul 2002 04:42:41 -0000 Received: by moria.seul.org (Postfix) id A6E80146812; Wed, 24 Jul 2002 00:42:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E14114698E; Wed, 24 Jul 2002 00:42:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 20F73146812 for ; Wed, 24 Jul 2002 00:42:38 -0400 (EDT) Received: from laposte.net (193.250.226.198) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D359CE900072F36 for f-cpu@seul.org; Wed, 24 Jul 2002 06:42:37 +0200 Message-ID: <3D3E2EBD.4020000@laposte.net> Date: Wed, 24 Jul 2002 06:36:13 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231506.15c6@th00.opsion.fr> <3D3D8EB4.3030009@laposte.net> <20020724004448.03991@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Is it so large that you can't convert it to ASCII and post it here? I've started to write this paper for with two objectives, first explain the standard call convention, and second take some hints about compiler specific calling convention. So it was not a simple message but a doc about calling convention in FCpu. But if you don't want to clic on the link, I can made post on the list (but it was alittle big when it was finished) > On the other hand, we already had this discussion, didn't we? > Yes but the objectives of this paper was not to restart a discution about this. And I think the actual call convention was not ok, we have some language/compiler specific feature, and we have thing like frame pointer that was not calling convention related but function prefix code related. Cedric BAIL wrote: > An other question, why didn't you speak about the relocation problem (big > problem on F-CPU) ? This is a draft, not a finished paper, for the moment I don't speek about a lot of thing, I have a lot of thing I want to take about in that paper... >>But he explain that we only need to define a call convention to >>inter-language call so this CC don't have to be time critical, but he >>need to be simple, so the return address was stored in a register. > > I agree. Good thing, I've found a people that understand what I think... >>But each compiler could choose to implement a stack for return address >>for all is internal call if he want (it seems better for security, but >>if programmer make good job...) > > > Programmer make good job ;-) Prefer to say compiler do the must do the best work > they can, because programmer didn't care about security and speed in most case. > Yann Guidon wrote : >Yes, but we can hope in heaven programmer reread their code a lot of >time and found all security hole... >However, i think that the people who discussed about the >parameter passing, have forgotten a VERY IMPORTANT DETAIL. >but i doubt they would care listen, even though this is absolutely >critical for performance. If they don't want to lose a factor >of roughly 5 on their codes, they MUST specify which registers >will be used as pointers. FC0 uses 8 pointers to data and 8 pointers >to instructions : a software-managed "return stack" and "data stack" >MUST be allocated (that is : there remains 48 registers for the rest). I never heard about this, I've reread the manual and not found anything about this, could you detail it or point me some links about this ? Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Jul 24 06:46:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XGaj-0000Yy-01 for ; Wed, 24 Jul 2002 09:29:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 09:29:49 +0200 (CEST) Received: (qmail 6833 invoked by uid 0); 24 Jul 2002 04:53:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 24 Jul 2002 04:53:14 -0000 Received: by moria.seul.org (Postfix) id 35F9D14692C; Wed, 24 Jul 2002 00:53:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2338D1469A4; Wed, 24 Jul 2002 00:53:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id BCD9C14692C for ; Wed, 24 Jul 2002 00:53:12 -0400 (EDT) Received: from laposte.net (193.250.226.198) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB3A2001214F2 for f-cpu@seul.org; Wed, 24 Jul 2002 06:53:12 +0200 Message-ID: <3D3E3138.7070305@laposte.net> Date: Wed, 24 Jul 2002 06:46:48 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling References: <3D3CDEB2.2070009@laposte.net> <3D3DABC6.89B52CA8@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Please take into account that a SW-managed stack is an excellent > place for doing optimisations. What is written in the last manual > is a big issue for F-CPU : the unique function return address > register is a critical "bottleneck" because a pointer can't > be moved to another register (the value can, but the hidden > flags won't be moved, so the next use will create a stall > during maybe 5 or 10 cycles). Ok, but this call convention was only for inter-language call, so not the most common, generally most of the call was made inside the programm and the compiler could optimize register allocation for return address. > I think and know that there are several "inconsistencies". > but the key is to NOT think like with usual CPUs. > Ask yourself : what the CPU has to do and what is the simplest, > fastest way to perform the task. If you want to make thing in the simplest way you need a stack, because most compiler was based on a stack and if you have few function call imbricated with some expression evaluation you quickly overflow a register stack and you need to store data in memory and stack is the simplest way to do this. > F-CPU is not MIPS : r63 is not hardwired in the instructions > when a call or return is performed. We have the choice of using > 63 registers for storing the return address. 8 of them can be used > "statically", whatever their number, to reduce the re-fetching overhead. > Same for data. It is simpler and faster to allocate 8 data and > 8 instruction pointers, rather than trying to reuse the scheme > used by other CPUs "because that's all people are used to". I'm ok, but I don't want to remake thing made in other cpu, I just want to make a call convention that will be easy to use for most languages. But I'll agree with you for internal call in programs. > If somebody cares... Yes I care... Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jul 24 08:41:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XGan-0000Yy-00 for ; Wed, 24 Jul 2002 09:29:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 09:29:53 +0200 (CEST) Received: (qmail 32751 invoked by uid 0); 24 Jul 2002 06:41:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Jul 2002 06:41:11 -0000 Received: by moria.seul.org (Postfix) id 3F0181467F2; Wed, 24 Jul 2002 02:41:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A9291469A4; Wed, 24 Jul 2002 02:41:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 61F7A1467F2 for ; Wed, 24 Jul 2002 02:41:07 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id CC43C28C for ; Wed, 24 Jul 2002 08:41:06 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 7EACE8C062; Wed, 24 Jul 2002 08:41:06 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) Message-ID: <1027492866.3d3e4c0277f40@imp.free.fr> Date: Wed, 24 Jul 2002 08:41:06 +0200 (MEST) From: Cedric BAIL References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <20020723143544.28147@thrai.stud.uni-hannover.de> In-Reply-To: <20020723143544.28147@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Hi, > > > I have uploaded on seul a new manual : > > http://f-cpu.seul.org/cedric/ > > > > Change are : > > - New index at the end of the manual > > - Add new dshift instructions (must be verified) > > Unfortunately, there are errors: the shift counts are wrong. For > `dshiftl', they are > > r1 = r2 << (r3 % size) > r1^1 = r2 >> (size - r3 % size) > > and similar for the other `d-' operations. Ok, I will change this. No other error ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Jul 24 11:28:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLb-0008Cx-01 for ; Wed, 24 Jul 2002 22:02:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:02:59 +0200 (CEST) Received: (qmail 17513 invoked by uid 0); 24 Jul 2002 09:31:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 24 Jul 2002 09:31:30 -0000 Received: by moria.seul.org (Postfix) id 658A01467F4; Wed, 24 Jul 2002 05:31:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1B3BB1469A4; Wed, 24 Jul 2002 05:31:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9283E1467F4 for ; Wed, 24 Jul 2002 05:31:28 -0400 (EDT) Received: from hli (81.48.49.134) by smtp.laposte.net (6.0.053) id 3D359CE900076635 for f-cpu@seul.org; Wed, 24 Jul 2002 11:31:25 +0200 Message-ID: <002201c232f4$99544140$86313051@hli> From: "Christophe Avoinne" To: References: <3D3CDEB2.2070009@laposte.net> <3D3DABC6.89B52CA8@f-cpu.org> <3D3E3138.7070305@laposte.net> Subject: Re: [f-cpu] Stack handling Date: Wed, 24 Jul 2002 11:28:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Thomas Lavergne" To: Sent: Wednesday, July 24, 2002 6:46 AM Subject: Re: [f-cpu] Stack handling > > Please take into account that a SW-managed stack is an excellent > > place for doing optimisations. What is written in the last manual > > is a big issue for F-CPU : the unique function return address > > register is a critical "bottleneck" because a pointer can't > > be moved to another register (the value can, but the hidden > > flags won't be moved, so the next use will create a stall > > during maybe 5 or 10 cycles). > > Ok, but this call convention was only for inter-language call, so not > the most common, generally most of the call was made inside the programm > and the compiler could optimize register allocation for return address. > It reminds to me that AMD Athlon uses an internal 12 entry return-address stack to speedup 'retn' . So your proposal is having several return pointer registers instead of one ? for static functions it isn't a problem but for public functions it is. Because everytime you need to enter a function in a function, you will need to know which register to save. But how the caller can know which return-address register to save since it can be called by anyone ? > > I think and know that there are several "inconsistencies". > > but the key is to NOT think like with usual CPUs. > > Ask yourself : what the CPU has to do and what is the simplest, > > fastest way to perform the task. > > If you want to make thing in the simplest way you need a stack, because > most compiler was based on a stack and if you have few function call > imbricated with some expression evaluation you quickly overflow a > register stack and you need to store data in memory and stack is the > simplest way to do this. With optimized compiler, stack should be in last resort. But the fact (look at the code generated by gcc), a lot of registers is saved in stack. It is not a matter of limited number of registers but the necessity that some registers need to be inchanged thru a function call (the callee will save these registers at enter and restore them at exit). Having one or several stacks changes nothing, we always need an temporary memory for saving those registers and the bottleneck remains. > > > F-CPU is not MIPS : r63 is not hardwired in the instructions > > when a call or return is performed. We have the choice of using > > 63 registers for storing the return address. 8 of them can be used > > "statically", whatever their number, to reduce the re-fetching overhead. > > Same for data. It is simpler and faster to allocate 8 data and > > 8 instruction pointers, rather than trying to reuse the scheme > > used by other CPUs "because that's all people are used to". > > I'm ok, but I don't want to remake thing made in other cpu, I just want > to make a call convention that will be easy to use for most languages. > But I'll agree with you for internal call in programs. > Sometimes I wonder if you are aware of the problem arised with the multiple instruction pointers... for public code, you still need to save one of those multiple instruction pointer because we cannot be sure that our public functions that we call in our function use or not the same instruction pointer !!! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jul 24 12:01:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLc-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:00 +0200 (CEST) Received: (qmail 1797 invoked by uid 0); 24 Jul 2002 09:54:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 24 Jul 2002 09:54:22 -0000 Received: by moria.seul.org (Postfix) id 82A251469A4; Wed, 24 Jul 2002 05:54:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A2CC1469A8; Wed, 24 Jul 2002 05:54:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id B63B31469A4 for ; Wed, 24 Jul 2002 05:54:20 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17XIxx-0001JO-00 for f-cpu@seul.org; Wed, 24 Jul 2002 12:01:57 +0200 Date: Wed, 24 Jul 2002 12:01:57 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling In-Reply-To: <002201c232f4$99544140$86313051@hli> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Apropos call/return saving of return address. I am not really convinced that return address handling should be a matter of the code. As someone mentioned before this requires the need for defining which register contains what data already in a statically fixed manner. The return addresses are the most critical part. If you get wrong data you simply get wrong results but if your return address gets faked the program crashes (I know there are exceptions where it needs fake to circumvent some processor inconveniences - but not f-cpu so far). So why not use a simple fifo type structure onchip for separate return address handling? JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jul 24 12:19:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLd-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:01 +0200 (CEST) Received: (qmail 9724 invoked by uid 0); 24 Jul 2002 10:12:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 24 Jul 2002 10:12:18 -0000 Received: by moria.seul.org (Postfix) id 410001469A7; Wed, 24 Jul 2002 06:12:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 07D091469A9; Wed, 24 Jul 2002 06:12:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id CD73E1469A7 for ; Wed, 24 Jul 2002 06:12:15 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17XJFK-0001Lk-00 for f-cpu@seul.org; Wed, 24 Jul 2002 12:19:54 +0200 Date: Wed, 24 Jul 2002 12:19:54 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: [f-cpu] Stack handling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry for the typo - must be lifo of course. On Wed, 24 Jul 2002, Juergen Goeritz wrote: >Apropos call/return saving of return address. I am not >really convinced that return address handling should >be a matter of the code. As someone mentioned before >this requires the need for defining which register >contains what data already in a statically fixed manner. > >The return addresses are the most critical part. If you >get wrong data you simply get wrong results but if your >return address gets faked the program crashes (I know >there are exceptions where it needs fake to circumvent >some processor inconveniences - but not f-cpu so far). > >So why not use a simple fifo type structure onchip for >separate return address handling? > >JG > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 24 13:18:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLd-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:01 +0200 (CEST) Received: (qmail 15014 invoked by uid 0); 24 Jul 2002 11:19:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 24 Jul 2002 11:19:05 -0000 Received: by moria.seul.org (Postfix) id 3C7121469A9; Wed, 24 Jul 2002 07:19:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24E001469AB; Wed, 24 Jul 2002 07:19:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B16531469A9 for ; Wed, 24 Jul 2002 07:19:02 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207241118.3641; Wed, 24 Jul 2002 11:18:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2002 11:18:54 GMT Message-id: <200207241118.3641@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >From the beginning we choose that they will be no hardware s= tack in F-cpu. Stacks are always a bottleneck. So this should be lef= t on the SW side. If you want to avoid the need to save and restore data for c= all convention, we should use windowed register (that could be a= great thing to decrease memory pressure, because most of the time there = is no memory access). But the interrupt handler must be really optimised. For interrupt management, it must have somethings as a lifo = to be reentrant (nested interrupt). The linked list previously pro= posed is hard for the hardware and hard to be extended. nicO -----Message d'origine----- De: Juergen Goeritz A: f-cpu@seul.org Date: 24/07/02 Objet: Re: [f-cpu] Stack handling Sorry for the typo - must be lifo of course. On Wed, 24 Jul 2002, Juergen Goeritz wrote: >Apropos call/return saving of return address. I am not >really convinced that return address handling should >be a matter of the code. As someone mentioned before >this requires the need for defining which register >contains what data already in a statically fixed manner. > >The return addresses are the most critical part. If you >get wrong data you simply get wrong results but if your >return address gets faked the program crashes (I know >there are exceptions where it needs fake to circumvent >some processor inconveniences - but not f-cpu so far). > >So why not use a simple fifo type structure onchip for >separate return address handling? > >JG > >***********************************************************= ** >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Jul 24 13:58:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLf-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:03 +0200 (CEST) Received: (qmail 29794 invoked by uid 0); 24 Jul 2002 12:05:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 24 Jul 2002 12:05:19 -0000 Received: by moria.seul.org (Postfix) id 82F5F1469AB; Wed, 24 Jul 2002 08:05:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42A681469AD; Wed, 24 Jul 2002 08:05:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id BD93E1469AB for ; Wed, 24 Jul 2002 08:05:16 -0400 (EDT) Received: from laposte.net (193.250.154.153) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB609000E472C for f-cpu@seul.org; Wed, 24 Jul 2002 14:05:16 +0200 Message-ID: <3D3E9678.6050802@laposte.net> Date: Wed, 24 Jul 2002 13:58:48 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Rep:Re: [f-cpu] Stack handling References: <200207241118.3641@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: >>>From the beginning we choose that they will be no hardware stack in > F-cpu. Stacks are always a bottleneck. So this should be left on the SW > side. > > If you want to avoid the need to save and restore data for call > convention, we should use windowed register (that could be a great thing > to decrease memory pressure, because most of the time there is no memory > access). But the interrupt handler must be really optimised. Windowed register have big problems with recursive function or too imbricated call. And task switching is a nightmare. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Wed Jul 24 14:28:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLf-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:03 +0200 (CEST) Received: (qmail 476 invoked by uid 0); 24 Jul 2002 12:21:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Jul 2002 12:21:18 -0000 Received: by moria.seul.org (Postfix) id 4E3A81469AC; Wed, 24 Jul 2002 08:21:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 180631469AE; Wed, 24 Jul 2002 08:21:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 8F1CC1469AC for ; Wed, 24 Jul 2002 08:21:14 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17XLG4-0001Vo-00 for f-cpu@seul.org; Wed, 24 Jul 2002 14:28:48 +0200 Date: Wed, 24 Jul 2002 14:28:48 +0200 (MEST) From: Juergen Goeritz To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <200207241118.3641@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 24 Jul 2002, Nicolas Boulay wrote: >>>From the beginning we choose that they will be no hardware stack in >F-cpu. Stacks are always a bottleneck. So this should be left on the SW >side. Okay, if it was a main design goal. >If you want to avoid the need to save and restore data for call >convention, we should use windowed register (that could be a great thing >to decrease memory pressure, because most of the time there is no memory >access). But the interrupt handler must be really optimised. Windowed register is some kind of a invisibility handling. I can imagine to have it be implemented like some ReadOnly setting of parts of a global register bank combined with a reordering just on the addressing scheme. (or use leon :) To save operations to restore/save of data which is provided to subroutines I can imagine an offset indication telling the code that parameters start at register position xy. Could be great when 256 registers or more are available. You don't have to copy to specific postitions then but just make sure that parameters are ascending assigned to registers and tell the callee where it starts or the other way round to tell the caller where multiple return data is starting in the registers. >For interrupt management, it must have somethings as a lifo to be >reentrant (nested interrupt). The linked list previously proposed is >hard for the hardware and hard to be extended. Linked list is preferably software feature or for dma units but hardly an processor issue. JG >nicO > >-----Message d'origine----- >De: Juergen Goeritz >A: f-cpu@seul.org >Date: 24/07/02 >Objet: Re: [f-cpu] Stack handling > >Sorry for the typo - must be lifo of course. > >On Wed, 24 Jul 2002, Juergen Goeritz wrote: >>Apropos call/return saving of return address. I am not >>really convinced that return address handling should >>be a matter of the code. As someone mentioned before >>this requires the need for defining which register >>contains what data already in a statically fixed manner. >> >>The return addresses are the most critical part. If you >>get wrong data you simply get wrong results but if your >>return address gets faked the program crashes (I know >>there are exceptions where it needs fake to circumvent >>some processor inconveniences - but not f-cpu so far). >> >>So why not use a simple fifo type structure onchip for >>separate return address handling? >> >>JG >> >>************************************************************* >>To unsubscribe, send an e-mail to majordomo@seul.org with >>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > >______________________________________________________________________________ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 24 14:21:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLh-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:05 +0200 (CEST) Received: (qmail 16501 invoked by uid 0); 24 Jul 2002 12:24:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Jul 2002 12:24:45 -0000 Received: by moria.seul.org (Postfix) id 6DC221469AD; Wed, 24 Jul 2002 08:24:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4011B1469B2; Wed, 24 Jul 2002 08:24:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id BF4661469AE for ; Wed, 24 Jul 2002 08:24:37 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-219.jetnet.ab.ca [207.34.60.219]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6OCOL8P072398 for ; Wed, 24 Jul 2002 06:24:21 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3E9BC5.7040200@jetnet.ab.ca> Date: Wed, 24 Jul 2002 06:21:25 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Stack handling References: <200207241118.3641@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: >>>From the beginning we choose that they will be no hardware stack in > F-cpu. Stacks are always a bottleneck. So this should be left on the SW > side. > > If you want to avoid the need to save and restore data for call > convention, we should use windowed register (that could be a great thing > to decrease memory pressure, because most of the time there is no memory > access). But the interrupt handler must be really optimised. I say make interupts slow and force people to use well designed buffered hardware.Task switching needs to be fast for threads than handle i/o. > For interrupt management, it must have somethings as a lifo to be > reentrant (nested interrupt). The linked list previously proposed is > hard for the hardware and hard to be extended. > One advantage of fixed Interupt and I/O locations (i/o page?) is that they don't cause a page fault as they are static locations for the MMU. Video/Sound/network buffers really need to be re-designed for MMU and task swaping. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 24 15:37:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLk-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:08 +0200 (CEST) Received: (qmail 24046 invoked by uid 0); 24 Jul 2002 13:37:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 24 Jul 2002 13:37:39 -0000 Received: by moria.seul.org (Postfix) id 292C2146803; Wed, 24 Jul 2002 09:37:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1CCC11469B5; Wed, 24 Jul 2002 09:37:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 83F44146803 for ; Wed, 24 Jul 2002 09:37:37 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207241337.1bde; Wed, 24 Jul 2002 13:37:27 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2002 13:37:27 GMT Message-id: <200207241337.1bde@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N That's OS stuff not cpu one. nicO -----Message d'origine----- De: Ben Franchuk A: f-cpu@seul.org Date: 24/07/02 Objet: Re: Rep:Re: [f-cpu] Stack handling Nicolas Boulay wrote: >>>From the beginning we choose that they will be no hardware= stack in > F-cpu. Stacks are always a bottleneck. So this should be l= eft on the SW > side. >=20 > If you want to avoid the need to save and restore data for= call > convention, we should use windowed register (that could be= a great thing > to decrease memory pressure, because most of the time ther= e is no memory > access). But the interrupt handler must be really optimise= d. I say make interupts slow and force people to use well desig= ned buffered hardware.Task switching needs to be fast for threads than ha= ndle i/o. > For interrupt management, it must have somethings as a lif= o to be > reentrant (nested interrupt). The linked list previously p= roposed is > hard for the hardware and hard to be extended. >=20 One advantage of fixed Interupt and I/O locations (i/o page?= ) is that they don't cause a page fault as they are static locations f= or the MMU. Video/Sound/network buffers really need to be re-designed fo= r MMU and task swaping. --=20 Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 24 15:58:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLl-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:09 +0200 (CEST) Received: (qmail 18433 invoked by uid 0); 24 Jul 2002 13:59:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 24 Jul 2002 13:59:02 -0000 Received: by moria.seul.org (Postfix) id 50E49146810; Wed, 24 Jul 2002 09:59:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E93F14692A; Wed, 24 Jul 2002 09:59:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id A5AC7146810 for ; Wed, 24 Jul 2002 09:59:00 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207241358.33f6; Wed, 24 Jul 2002 13:58:51 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2002 13:58:51 GMT Message-id: <200207241358.33f6@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Another idea for security : One of my idea is to use a separate stack for return adress = to avoid buffer overflow. But this new stack are in memory with read/= write right by this task. If an other way is find to modify the memory p= lace, it's always possible. (i should refind an article where they explain how to bypas= s none execute right on stack by writing inside librairies address = space (that could be protected by a ring ?) or by executing exec() with = the good parameter (/sbin/sh ! ;p) ). So what about creating 2 stores instructions ? One manipulat= es data visible for the user and the other one for "internal" manage= ment as for return address. Then we add a new bit on the MMU to allow a = page to be accessed (or not) by "user" store.=20 This userStore could be used when manipulating array and poi= nters. Stacks will be manipulated with the sysStore instruction ins= ide a protected page. Comments ? nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Wed Jul 24 17:29:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLo-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:12 +0200 (CEST) Received: (qmail 5662 invoked by uid 0); 24 Jul 2002 15:29:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 24 Jul 2002 15:29:58 -0000 Received: by moria.seul.org (Postfix) id 3CD6B146813; Wed, 24 Jul 2002 11:29:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 06A66146931; Wed, 24 Jul 2002 11:29:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14204.mail.yahoo.com (web14204.mail.yahoo.com [216.136.172.146]) by moria.seul.org (Postfix) with SMTP id 2ABC9146813 for ; Wed, 24 Jul 2002 11:29:56 -0400 (EDT) Message-ID: <20020724152955.31748.qmail@web14204.mail.yahoo.com> Received: from [130.89.243.164] by web14204.mail.yahoo.com via HTTP; Wed, 24 Jul 2002 08:29:55 PDT Date: Wed, 24 Jul 2002 08:29:55 -0700 (PDT) From: jaap stolk Subject: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling To: f-cpu@seul.org In-Reply-To: <200207241358.33f6@th00.opsion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Nicolas Boulay wrote: > Another idea for security : > > One of my idea is to use a separate stack for return > adress to avoid > buffer overflow. But this new stack are in memory hi, I might be missing the point here, but why can’t we just check the input of a program ? (like everybody used to do in basic) Is it so hard to check the size of something before its put into a buffer ? As far as i can see, this is more a problem coused by a programmer / compiler that doesn’t check un-thruster input data, and not a CPU “security” problem. Even when using separate code and data stack, a buffer overflow still course corrupted data, I can hardly call that “secure”, and corrupted data is very likely to crash the program anyway :-) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 24 17:44:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLp-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:13 +0200 (CEST) Received: (qmail 18938 invoked by uid 0); 24 Jul 2002 15:44:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 24 Jul 2002 15:44:56 -0000 Received: by moria.seul.org (Postfix) id 11B9914692E; Wed, 24 Jul 2002 11:44:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E1E75146932; Wed, 24 Jul 2002 11:44:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 644B914692E for ; Wed, 24 Jul 2002 11:44:54 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207241544.2f34; Wed, 24 Jul 2002 15:44:47 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2002 15:44:47 GMT Message-id: <200207241544.2f34@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N At the lsm lsm.abul.org , we see people who write security p= atches for intel/x86. Those great guy takes hours juste to write someth= ing that couls *simulate* none executing stack on ix86 ( www.grsecuri= ty.org ). So much work for littles hardware problems !=20 That's not possible not to forget it. Writing security hole = is very easy in C, even when you try to be clean. This have to do with th= e security of a system. Those system must handle bad written code and a= pplication without crashing. nicO -----Message d'origine----- De: jaap stolk A: f-cpu@seul.org Date: 24/07/02 Objet: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling --- Nicolas Boulay wrote: > Another idea for security : >=20 > One of my idea is to use a separate stack for return > adress to avoid > buffer overflow. But this new stack are in memory hi, I might be missing the point here, but why can=92t we just check the input of a program ? (like everybody used to do in basic) Is it so hard to check the size of something before its put into a buffer ? As far as i can see, this is more a problem coused by a programmer / compiler that doesn=92t check un-thruster input data, and not a CPU =93security=94 problem. Even when using separate code and data stack, a buffer overflow still course corrupted data, I can hardly call that =93secure=94, and corrupted data is very likely to crash the program anyway :-)=20 jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 24 18:02:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLq-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:14 +0200 (CEST) Received: (qmail 15016 invoked by uid 0); 24 Jul 2002 16:05:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 24 Jul 2002 16:05:34 -0000 Received: by moria.seul.org (Postfix) id 80BAC146931; Wed, 24 Jul 2002 12:05:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52ED61469B5; Wed, 24 Jul 2002 12:05:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A5E8F146931 for ; Wed, 24 Jul 2002 12:05:30 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-203.jetnet.ab.ca [207.34.60.203]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6OG5E8P024587 for ; Wed, 24 Jul 2002 10:05:15 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3ECF89.1080304@jetnet.ab.ca> Date: Wed, 24 Jul 2002 10:02:17 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241337.1bde@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: > That's OS stuff not cpu one. Writing a good OS is hard with crappy hardware.I would like a Good CPU and a good hardware inteface. While a CPU is not directly involved with I/O and user/system software they still are tightly coupled system and design change in one area has a large impact in another one. Also while off topic the anime "Lain:The serial experiments" is a good si-fi story in the post-internet-age. It really makes you think about the future. PS. I feel the RISC idea is a step backwards and the way to go is a CLEAN VITRUAL cpu/memory/io design. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 24 15:59:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLq-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:14 +0200 (CEST) Received: (qmail 20070 invoked by uid 0); 24 Jul 2002 16:23:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 24 Jul 2002 16:23:40 -0000 Received: by moria.seul.org (Postfix) id 36138146938; Wed, 24 Jul 2002 12:23:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F6861469BA; Wed, 24 Jul 2002 12:23:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a146.home.uni-hannover.de [130.75.232.146]) by moria.seul.org (Postfix) with ESMTP id 46102146938 for ; Wed, 24 Jul 2002 12:23:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00621; Wed, 24 Jul 2002 15:59:57 +0200 Message-ID: <20020724155957.54855@thrai.stud.uni-hannover.de> Date: Wed, 24 Jul 2002 15:59:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231506.15c6@th00.opsion.fr> <3D3D8EB4.3030009@laposte.net> <20020724004448.03991@thrai.stud.uni-hannover.de> <3D3E2EBD.4020000@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D3E2EBD.4020000@laposte.net>; from Thomas Lavergne on Wed, Jul 24, 2002 at 06:36:13AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 24, 2002 at 06:36:13AM +0200, Thomas Lavergne wrote: > Michael Riepe wrote: > > Is it so large that you can't convert it to ASCII and post it here? > > I've started to write this paper for with two objectives, first explain > the standard call convention, and second take some hints about compiler > specific calling convention. So it was not a simple message but a doc > about calling convention in FCpu. > But if you don't want to clic on the link, I can made post on the list > (but it was alittle big when it was finished) Not necessary. > > On the other hand, we already had this discussion, didn't we? > > > > Yes but the objectives of this paper was not to restart a discution > about this. And I think the actual call convention was not ok, we have > some language/compiler specific feature, and we have thing like frame > pointer that was not calling convention related but function prefix code > related. If we want to link the output of several compilers (or written in several languages), we need to fix things. We also have to define a process<->OS kernel API. A single user stack pointer is important for the OS kernel: it indicates how much stack memory the process has allocated. That does not mean that the register has to be changed on every push/pop, which leaves room for optimization. A frame pointer is not strictly required in any language, but helps with debugging: programs like gdb use it to trace function calls. Therefore, all compilers/languages that support a frame pointer must use the same register. An explicit "number of arguments" argument, on the other hand, is not required by most languages. It's the compiler's job to make sure the number of arguments is correct, except in languages like Lisp (but in Lisp, you may have to use different calling conventions anyway). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 24 15:26:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLr-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:15 +0200 (CEST) Received: (qmail 22157 invoked by uid 0); 24 Jul 2002 16:23:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 24 Jul 2002 16:23:44 -0000 Received: by moria.seul.org (Postfix) id DA6FD1469BE; Wed, 24 Jul 2002 12:23:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D3AA01469BD; Wed, 24 Jul 2002 12:23:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a146.home.uni-hannover.de [130.75.232.146]) by moria.seul.org (Postfix) with ESMTP id 4B7BF1469B5 for ; Wed, 24 Jul 2002 12:23:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00544; Wed, 24 Jul 2002 15:26:37 +0200 Message-ID: <20020724152637.22852@thrai.stud.uni-hannover.de> Date: Wed, 24 Jul 2002 15:26:37 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <20020723143544.28147@thrai.stud.uni-hannover.de> <1027492866.3d3e4c0277f40@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027492866.3d3e4c0277f40@imp.free.fr>; from Cedric BAIL on Wed, Jul 24, 2002 at 08:41:06AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 24, 2002 at 08:41:06AM +0200, Cedric BAIL wrote: [...] > > Unfortunately, there are errors: the shift counts are wrong. For > > `dshiftl', they are > > > > r1 = r2 << (r3 % size) > > r1^1 = r2 >> (size - r3 % size) > > > > and similar for the other `d-' operations. > > Ok, I will change this. No other error ? I didn't look at the rest yet, sorry. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 24 19:39:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLu-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:18 +0200 (CEST) Received: (qmail 12607 invoked by uid 0); 24 Jul 2002 17:49:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 24 Jul 2002 17:49:04 -0000 Received: by moria.seul.org (Postfix) id 66F541469C2; Wed, 24 Jul 2002 13:49:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B3AA1469C4; Wed, 24 Jul 2002 13:49:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 603891469C2 for ; Wed, 24 Jul 2002 13:49:02 -0400 (EDT) Received: (qmail 35592 invoked by uid 85); 24 Jul 2002 17:46:45 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.165215 secs); 24 Jul 2002 17:46:45 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 24 Jul 2002 17:46:44 -0000 Message-ID: <3D3EE65B.1010400@yahoo.fr> Date: Wed, 24 Jul 2002 19:39:39 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Arithmetic lib References: <200207230743.1c80@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I know the name, but I don't know why. See Ya Just an Illusion Nicolas Boulay wrote: >Is this url knowns ? > >http://www.iis.ee.ethz.ch/~zimmi/ > >nicO > > > >______________________________________________________________________________ >ifrance.com, l'email gratuit le plus complet de l'Internet ! >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >http://www.ifrance.com/_reloc/email.emailif > > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 24 21:10:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLy-0008Cx-00 for ; Wed, 24 Jul 2002 22:03:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:22 +0200 (CEST) Received: (qmail 3830 invoked by uid 0); 24 Jul 2002 19:01:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 24 Jul 2002 19:01:01 -0000 Received: by moria.seul.org (Postfix) id D5D8D1469C0; Wed, 24 Jul 2002 15:00:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C09EB1469C6; Wed, 24 Jul 2002 15:00:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 61D531469C0 for ; Wed, 24 Jul 2002 15:00:59 -0400 (EDT) Received: from f-cpu.org (kdl11-28.n.club-internet.fr [213.44.9.28]) by relay-4v.club-internet.fr (Postfix) with ESMTP id CBF1816BA for ; Wed, 24 Jul 2002 21:00:56 +0200 (CEST) Message-ID: <3D3EFB8C.595D3CD1@f-cpu.org> Date: Wed, 24 Jul 2002 21:10:04 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241358.33f6@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > > Another idea for security : > > One of my idea is to use a separate stack for return adress to avoid > buffer overflow. But this new stack are in memory with read/write right > by this task. If an other way is find to modify the memory place, it's > always possible. > > (i should refind an article where they explain how to bypass none > execute right on stack by writing inside librairies address space (that > could be protected by a ring ?) or by executing exec() with the good > parameter (/sbin/sh ! ;p) ). > > So what about creating 2 stores instructions ? One manipulates data > visible for the user and the other one for "internal" management as for > return address. Then we add a new bit on the MMU to allow a page to be > accessed (or not) by "user" store. > > This userStore could be used when manipulating array and pointers. > Stacks will be manipulated with the sysStore instruction inside a > protected page. > > Comments ? 1) security in FC0 is enforced through the SRs and the TLB. 2) there can be only one kind of load and store instructions because there are already a lot of variations around it. 3) maybe a compromise would be to use the "stream" flags : computers that recognize it can setup a specific right or protection mechanism. Others (like embedded stuffs with no security problems) could simply not care, and the SW portability would work at no cost. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Jul 24 21:05:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XSLy-0008Cx-01 for ; Wed, 24 Jul 2002 22:03:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 24 Jul 2002 22:03:22 +0200 (CEST) Received: (qmail 13480 invoked by uid 0); 24 Jul 2002 19:12:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 24 Jul 2002 19:12:33 -0000 Received: by moria.seul.org (Postfix) id 2C9D41469C5; Wed, 24 Jul 2002 15:12:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 005CD1469C7; Wed, 24 Jul 2002 15:12:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 95C641469C5 for ; Wed, 24 Jul 2002 15:12:31 -0400 (EDT) Received: from laposte.net (193.250.154.146) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9000AAA98 for f-cpu@seul.org; Wed, 24 Jul 2002 21:12:30 +0200 Message-ID: <3D3EFA8E.20804@laposte.net> Date: Wed, 24 Jul 2002 21:05:50 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207231506.15c6@th00.opsion.fr> <3D3D8EB4.3030009@laposte.net> <20020724004448.03991@thrai.stud.uni-hannover.de> <3D3E2EBD.4020000@laposte.net> <20020724155957.54855@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >>Yes but the objectives of this paper was not to restart a discution >>about this. And I think the actual call convention was not ok, we have >>some language/compiler specific feature, and we have thing like frame >>pointer that was not calling convention related but function prefix code >>related. > > > If we want to link the output of several compilers (or written in several > languages), we need to fix things. We also have to define a process<->OS > kernel API. for all external function you use the standard CC, it's deigned for that, but not all function was exported and for the other you could (must?) use a CC optimized for your language/compiler. > A single user stack pointer is important for the OS kernel: it > indicates how much stack memory the process has allocated. That does > not mean that the register has to be changed on every push/pop, which > leaves room for optimization. I never say the contrary, and I defend a best stack handling in the FCpu ISA. > A frame pointer is not strictly required in any language, but helps with > debugging: programs like gdb use it to trace function calls. Therefore, > all compilers/languages that support a frame pointer must use the same > register. We can suggest a reg for Frame Pointer and if a compiler use it could be used by debugger, but I think this is not directly a part of CC because the stack frame was made by the function called, not the caller. > An explicit "number of arguments" argument, on the other hand, is not > required by most languages. It's the compiler's job to make sure the > number of arguments is correct, except in languages like Lisp (but in > Lisp, you may have to use different calling conventions anyway). > Yes but in inter-language call, one of the most common error was bad argument number, (the second was problem about argument type, and after you can found, alignment in record). The compiler never known if the other compiler have make good job... But for internal function he known he have made good job (I hope :-)) so for internal CC, we don't need it. (It was one of the point discussed in the part not finished of the draft) -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 24 22:29:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWlt-0002qV-00 for ; Thu, 25 Jul 2002 02:46:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:25 +0200 (CEST) Received: (qmail 28279 invoked by uid 0); 24 Jul 2002 20:09:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 24 Jul 2002 20:09:32 -0000 Received: by moria.seul.org (Postfix) id 955901469A5; Wed, 24 Jul 2002 16:09:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 740A91469B7; Wed, 24 Jul 2002 16:09:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 1CA0F1469A5 for ; Wed, 24 Jul 2002 16:09:30 -0400 (EDT) Received: from ifrance.com (vlt4-120.n.club-internet.fr [194.158.109.120]) by relay-5v.club-internet.fr (Postfix) with ESMTP id B768316B8 for ; Wed, 24 Jul 2002 22:09:27 +0200 (CEST) Message-ID: <3D3F0E2A.EEA69F8F@ifrance.com> Date: Wed, 24 Jul 2002 22:29:30 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241358.33f6@th00.opsion.fr> <3D3EFB8C.595D3CD1@f-cpu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon a écrit : > > hi, > > Nicolas Boulay wrote: > > > > Another idea for security : > > > > One of my idea is to use a separate stack for return adress to avoid > > buffer overflow. But this new stack are in memory with read/write right > > by this task. If an other way is find to modify the memory place, it's > > always possible. > > > > (i should refind an article where they explain how to bypass none > > execute right on stack by writing inside librairies address space (that > > could be protected by a ring ?) or by executing exec() with the good > > parameter (/sbin/sh ! ;p) ). > > > > So what about creating 2 stores instructions ? One manipulates data > > visible for the user and the other one for "internal" management as for > > return address. Then we add a new bit on the MMU to allow a page to be > > accessed (or not) by "user" store. > > > > This userStore could be used when manipulating array and pointers. > > Stacks will be manipulated with the sysStore instruction inside a > > protected page. > > > > Comments ? > > 1) security in FC0 is enforced through the SRs and the TLB. It's nothing new compare to others machines. > > 2) there can be only one kind of load and store instructions > because there are already a lot of variations around it. > I don't see any problem. It's just a flag that follow the store. > 3) maybe a compromise would be to use the "stream" flags : > computers that recognize it can setup a specific right or > protection mechanism. Others (like embedded stuffs with no > security problems) could simply not care, and the SW portability > would work at no cost. > You should set a right on page to have an explicit protection ! > > nicO > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 24 19:59:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWm2-0002qV-01 for ; Thu, 25 Jul 2002 02:46:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:34 +0200 (CEST) Received: (qmail 30903 invoked by uid 0); 24 Jul 2002 21:34:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 24 Jul 2002 21:34:05 -0000 Received: by moria.seul.org (Postfix) id 828FA146937; Wed, 24 Jul 2002 17:34:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 49378146916; Wed, 24 Jul 2002 17:34:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a136.home.uni-hannover.de [130.75.232.136]) by moria.seul.org (Postfix) with ESMTP id A462214681E for ; Wed, 24 Jul 2002 17:34:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01549; Wed, 24 Jul 2002 19:59:05 +0200 Message-ID: <20020724195904.23896@thrai.stud.uni-hannover.de> Date: Wed, 24 Jul 2002 19:59:04 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Manual 0.2.6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N There are still some open ends in part V: 1.2.5 `rem': computes r1 = r2 % r3 1.3.5 `cmpl': We should define a flag for signed/unsigned comparision. Also for cmple/cmpli/cmplei/min/max/sort. 2.1.1 `shiftl': computes r1 = r2 << (r3 % size) Also for shiftr/shiftra/rotl/rotr and immediate forms. 2.3.1 `bitrev': computes r1 = bit_reverse(r2) >> (size - 1 - r3 % size) Also for bitrevi and dbitrev[i]. Bitrev supports SIMD; the remark that "the SIMD flag is not used" is obsolete. The `-o' form is currently not implemented, and only makes sense in non-SIMD modes. 2.3.6 `dshiftl': computes r1 = r2 << (r3 % size) and r1^1 = r2 >> (size - r3 % size) Also for other dshift* ops. 6.1.2 `loadcons': The jury is still discussing this. 7.1.7 `syscall'/`trap': It's still not clear what the difference is. I suppose both instructions perform an SRB. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 24 19:21:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWm3-0002qV-00 for ; Thu, 25 Jul 2002 02:46:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:35 +0200 (CEST) Received: (qmail 19368 invoked by uid 0); 24 Jul 2002 21:34:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 24 Jul 2002 21:34:07 -0000 Received: by moria.seul.org (Postfix) id 7BA4C14681E; Wed, 24 Jul 2002 17:34:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5746B14693D; Wed, 24 Jul 2002 17:34:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a136.home.uni-hannover.de [130.75.232.136]) by moria.seul.org (Postfix) with ESMTP id 71A4214681E for ; Wed, 24 Jul 2002 17:34:03 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01448; Wed, 24 Jul 2002 19:21:48 +0200 Message-ID: <20020724192147.16114@thrai.stud.uni-hannover.de> Date: Wed, 24 Jul 2002 19:21:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241358.33f6@th00.opsion.fr> <20020724152955.31748.qmail@web14204.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <20020724152955.31748.qmail@web14204.mail.yahoo.com>; from jaap stolk on Wed, Jul 24, 2002 at 08:29:55AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 24, 2002 at 08:29:55AM -0700, jaap stolk wrote: [...] > I might be missing the point here, but why can’t we > just check the input of a program ? (like everybody > used to do in basic) > Is it so hard to check the size of something before > its put into a buffer ? Ask a programmer. Most of them refuse to (or are not aware of the problem at all). > As far as i can see, this is more a problem coused by > a programmer / compiler that doesn’t check un-thruster > input data, and not a CPU “security” problem. If a program is insecure, it usually is the programmer's fault. > Even when using separate code and data stack, a > buffer overflow still course corrupted data, I can > hardly call that “secure”, and corrupted data is > very likely to crash the program anyway :-) Both are equally dangerous if pointers to code are involved (e.g. a pointer to a function): overwrite them and you're able to inject and execute your own (malicious) code. A separate return stack helps with some cases, but it's no guarantee. Neither is a non-executable stack. Keeping the return address and other `code' pointers in registers is relatively safe - until the registers are saved to memory. Since this will happen sooner or later, C programmers always have to check array bounds, and avoid inherently unsafe functions like gets() or getwd(). On the other hand, F-CPU code can be less vulnerable to stack smashing than e.g. Intel (ia32) code, mostly because function arguments and return addresses are not by default stored in a memory-based stack. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mail@apexo.de Wed Jul 24 23:43:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWm3-0002qV-01 for ; Thu, 25 Jul 2002 02:46:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:35 +0200 (CEST) Received: (qmail 26361 invoked by uid 0); 24 Jul 2002 21:43:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 24 Jul 2002 21:43:53 -0000 Received: by moria.seul.org (Postfix) id E42F8146850; Wed, 24 Jul 2002 17:43:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CB56D14693D; Wed, 24 Jul 2002 17:43:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from moutvdomng3.kundenserver.de (moutvdom.kundenserver.de [195.20.224.200]) by moria.seul.org (Postfix) with ESMTP id 7CA14146850 for ; Wed, 24 Jul 2002 17:43:51 -0400 (EDT) Received: from [195.20.224.198] (helo=mrvdomng3.kundenserver.de) by moutvdomng3.kundenserver.de with esmtp (Exim 3.35 #2) id 17XTvC-0003d2-00 for f-cpu@seul.org; Wed, 24 Jul 2002 23:43:50 +0200 Received: from [145.254.55.134] (helo=apex) by mrvdomng3.kundenserver.de with esmtp (Exim 3.35 #2) id 17XTvC-0005F3-00 for f-cpu@seul.org; Wed, 24 Jul 2002 23:43:50 +0200 Date: Wed, 24 Jul 2002 23:43:50 +0200 From: "Christian M. Schubert" X-Mailer: The Bat! (v1.53d) X-Priority: 3 (Normal) Message-ID: <19954660657.20020724234350@apexo.de> To: Michael Riepe Subject: Re[2]: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <20020724192147.16114@thrai.stud.uni-hannover.de> References: <200207241358.33f6@th00.opsion.fr> <20020724152955.31748.qmail@web14204.mail.yahoo.com> <20020724192147.16114@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Wednesday, July 24, 2002, 7:21:47 PM, you wrote: >> I might be missing the point here, but why can’t we >> just check the input of a program ? (like everybody >> used to do in basic) >> Is it so hard to check the size of something before >> its put into a buffer ? > Ask a programmer. Most of them refuse to (or are not aware of the > problem at all). Personally I do error checking wherever possible. I think it's a lot of fun to write error messages that will probably never be seen by a human - but who cares. Some guys don't put that much effort into their programs and are happy are soon as the program works within their expected operational limits. IMHO Zero terminated strings are the root of all evil. Explicit length specification would require an additional parameter per passed string (that seems to be a pain in the a** for some guys) but seems to be getting more popular (at least in the newer functions in the Windows API some functions require you to pass pointer to a string and the length). That makes it far more easier to check for buffer overflows (but still needs extra code to be written what most programmers tend to avoid if possible). From that point of view it is indeed very hard to check buffer sizes (at least in C)... however, I wouldn't encourage that behaviour so don't let the CPU do things which the programmer has to take care of. just my 2 cents ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 25 00:36:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWmA-0002qV-00 for ; Thu, 25 Jul 2002 02:46:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:42 +0200 (CEST) Received: (qmail 23815 invoked by uid 0); 24 Jul 2002 22:36:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 24 Jul 2002 22:36:37 -0000 Received: by moria.seul.org (Postfix) id 82E061467EE; Wed, 24 Jul 2002 18:36:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 30125146936; Wed, 24 Jul 2002 18:36:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a136.home.uni-hannover.de [130.75.232.136]) by moria.seul.org (Postfix) with ESMTP id 54A961467EE for ; Wed, 24 Jul 2002 18:36:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02540; Thu, 25 Jul 2002 00:36:30 +0200 Message-ID: <20020725003630.43845@thrai.stud.uni-hannover.de> Date: Thu, 25 Jul 2002 00:36:30 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re[2]: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241358.33f6@th00.opsion.fr> <20020724152955.31748.qmail@web14204.mail.yahoo.com> <20020724192147.16114@thrai.stud.uni-hannover.de> <19954660657.20020724234350@apexo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <19954660657.20020724234350@apexo.de>; from Christian M. Schubert on Wed, Jul 24, 2002 at 11:43:50PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 24, 2002 at 11:43:50PM +0200, Christian M. Schubert wrote: [...] > IMHO Zero terminated strings are the root of all evil. Explicit length > specification would require an additional parameter per passed string > (that seems to be a pain in the a** for some guys) but seems to be > getting more popular (at least in the newer functions in the Windows > API some functions require you to pass pointer to a string and the > length). That makes it far more easier to check for buffer overflows > (but still needs extra code to be written what most programmers tend > to avoid if possible). [...] Do you remember the latest BIND resolver bug (some weeks ago)? They *did* use a pointer and a length, and then forgot to update one of them. I guess the root of all evil is lazy programmers. Or too many programmers working on the same project at the same time. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jul 25 00:42:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XWmB-0002qV-01 for ; Thu, 25 Jul 2002 02:46:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 02:46:43 +0200 (CEST) Received: (qmail 12408 invoked by uid 0); 24 Jul 2002 22:45:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 24 Jul 2002 22:45:27 -0000 Received: by moria.seul.org (Postfix) id 32DE914693D; Wed, 24 Jul 2002 18:45:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 101ED14694A; Wed, 24 Jul 2002 18:45:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 8BE0F14693D for ; Wed, 24 Jul 2002 18:45:25 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6OMj98P044673 for ; Wed, 24 Jul 2002 16:45:10 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D3F2D42.5040007@jetnet.ab.ca> Date: Wed, 24 Jul 2002 16:42:10 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling References: <200207241358.33f6@th00.opsion.fr> <20020724152955.31748.qmail@web14204.mail.yahoo.com> <20020724192147.16114@thrai.stud.uni-hannover.de> <19954660657.20020724234350@apexo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christian M. Schubert wrote: > IMHO Zero terminated strings are the root of all evil. Explicit length > specification would require an additional parameter per passed string > (that seems to be a pain in the a** for some guys) but seems to be > getting more popular (at least in the newer functions in the Windows > API some functions require you to pass pointer to a string and the > length). That makes it far more easier to check for buffer overflows > (but still needs extra code to be written what most programmers tend > to avoid if possible). From that point of view it is indeed very hard > to check buffer sizes (at least in C)... however, I wouldn't encourage > that behaviour so don't let the CPU do things which the programmer > has to take care of. I think it is more of a case of unrestriced parameters and undefined limits. The problem is finding the pesudo-constants used in a program and modifing how we think about program design. Say you have parsing routing that say "speaks your files selected". What happens if you save a email from a friend who speaks Japanese? Can the program be modifed from a config file or is it hard coded? What hapens if you have Windows 2040 with unlimited length file names? True people make mistakes but software design works best only you have written it a few times from scratch. :( -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From goeritz@oekomm.de Thu Jul 25 09:43:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XfKW-0000hX-01 for ; Thu, 25 Jul 2002 11:54:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 11:54:44 +0200 (CEST) Received: (qmail 9317 invoked by uid 0); 25 Jul 2002 07:35:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 25 Jul 2002 07:35:42 -0000 Received: by moria.seul.org (Postfix) id D1706146974; Thu, 25 Jul 2002 03:35:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB9AA146978; Thu, 25 Jul 2002 03:35:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from redwood.oekomm.de (redwood.oekomm.de [195.247.49.177]) by moria.seul.org (Postfix) with ESMTP id 9E0AE146974 for ; Thu, 25 Jul 2002 03:35:39 -0400 (EDT) Received: from goeritz (helo=localhost) by redwood.oekomm.de with local-smtp (Exim 2.02 #1) id 17XdHD-0002Re-00 for f-cpu@seul.org; Thu, 25 Jul 2002 09:43:11 +0200 Date: Thu, 25 Jul 2002 09:43:11 +0200 (MEST) From: Juergen Goeritz To: Michael Riepe Subject: Re: Re[4]: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <471914783.20020725091412@apexo.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, 25 Jul 2002, Christian M. Schubert wrote: > >Thursday, July 25, 2002, 12:36:30 AM, Michael Riepe wrote: >> Do you remember the latest BIND resolver bug (some weeks ago)? They *did* >> use a pointer and a length, and then forgot to update one of them. > >> I guess the root of all evil is lazy programmers. Or too many >> programmers working on the same project at the same time. > >Well, multiple programmers on the same project usually doesn't impose >a problem usually - the problem arises when one programmer who doesn't >have a clue of the programm tries to modify something on his own - >that might have disastrous consequences. The problem one seem to have in a lot of huge long term projects. Especially when developers change to other projects during its development cycle. Compared to the hardware the software is much, much more complex. And it gets even worse with OO software. Once in a project it looked like I had to program the interface between the two splitted parts of the team. They had the reflection of the splitted team in the code as well. Needed some software statemachines to program around the (design) issue which couldn't get resolved by the team (freelancers haven't got strong positions in such projects, they are easy replaceable or exchangeable). JG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Jul 25 10:09:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XfKY-0000hX-01 for ; Thu, 25 Jul 2002 11:54:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 11:54:46 +0200 (CEST) Received: (qmail 1066 invoked by uid 0); 25 Jul 2002 08:09:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 25 Jul 2002 08:09:42 -0000 Received: by moria.seul.org (Postfix) id 364121467ED; Thu, 25 Jul 2002 04:09:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF847146978; Thu, 25 Jul 2002 04:09:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id A057F1467ED for ; Thu, 25 Jul 2002 04:09:40 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix1-2.free.fr (Postfix) with ESMTP id 6CCCDAB3FA for ; Thu, 25 Jul 2002 10:09:39 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id 5D4E6123C6; Thu, 25 Jul 2002 10:09:39 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 Message-ID: <1027584579.3d3fb243503a7@imp.free.fr> Date: Thu, 25 Jul 2002 10:09:39 +0200 (MEST) From: Cedric BAIL References: <20020724195904.23896@thrai.stud.uni-hannover.de> In-Reply-To: <20020724195904.23896@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Finally you take time to read it, thanks. > There are still some open ends in part V: > > 1.2.5 `rem': > computes r1 = r2 % r3 > 1.3.5 `cmpl': > We should define a flag for signed/unsigned comparision. > Also for cmple/cmpli/cmplei/min/max/sort. > 2.1.1 `shiftl': > computes r1 = r2 << (r3 % size) > Also for shiftr/shiftra/rotl/rotr and immediate forms. > 2.3.1 `bitrev': > computes r1 = bit_reverse(r2) >> (size - 1 - r3 % size) > Also for bitrevi and dbitrev[i]. > Bitrev supports SIMD; the remark that "the SIMD flag is > not used" is obsolete. The `-o' form is currently not > implemented, and only makes sense in non-SIMD modes. > 2.3.6 `dshiftl': > computes r1 = r2 << (r3 % size) > and r1^1 = r2 >> (size - r3 % size) > Also for other dshift* ops. > 6.1.2 `loadcons': > The jury is still discussing this. Ok, but you and thomas write the latest post, because nobody answer, I was thinking it was decided. > 7.1.7 `syscall'/`trap': > It's still not clear what the difference is. > I suppose both instructions perform an SRB. Ok, I will update the manual as quick as possible. But was did you think about a red warning on page that are still discussing ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mail@apexo.de Thu Jul 25 09:14:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XfKW-0000hX-00 for ; Thu, 25 Jul 2002 11:54:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 11:54:44 +0200 (CEST) Received: (qmail 25095 invoked by uid 0); 25 Jul 2002 07:14:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 25 Jul 2002 07:14:14 -0000 Received: by moria.seul.org (Postfix) id 98685146973; Thu, 25 Jul 2002 03:14:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7797C146977; Thu, 25 Jul 2002 03:14:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from moutvdomng1.kundenserver.de (moutvdom.kundenserver.de [195.20.224.131]) by moria.seul.org (Postfix) with ESMTP id 36B60146973 for ; Thu, 25 Jul 2002 03:14:12 -0400 (EDT) Received: from [195.20.224.199] (helo=mrvdomng4.kundenserver.de) by moutvdomng1.kundenserver.de with esmtp (Exim 3.35 #2) id 17Xcp9-0005nX-00 for f-cpu@seul.org; Thu, 25 Jul 2002 09:14:11 +0200 Received: from [145.254.64.239] (helo=apex) by mrvdomng4.kundenserver.de with esmtp (Exim 3.35 #2) id 17Xcp9-00021E-00 for f-cpu@seul.org; Thu, 25 Jul 2002 09:14:11 +0200 Date: Thu, 25 Jul 2002 09:14:12 +0200 From: "Christian M. Schubert" X-Mailer: The Bat! (v1.53d) X-Priority: 3 (Normal) Message-ID: <471914783.20020725091412@apexo.de> To: Michael Riepe Subject: Re[4]: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling In-Reply-To: <20020725003630.43845@thrai.stud.uni-hannover.de> References: <200207241358.33f6@th00.opsion.fr> <20020724152955.31748.qmail@web14204.mail.yahoo.com> <20020724192147.16114@thrai.stud.uni-hannover.de> <19954660657.20020724234350@apexo.de> <20020725003630.43845@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thursday, July 25, 2002, 12:36:30 AM, Michael Riepe wrote: > Do you remember the latest BIND resolver bug (some weeks ago)? They *did* > use a pointer and a length, and then forgot to update one of them. > I guess the root of all evil is lazy programmers. Or too many > programmers working on the same project at the same time. Well, multiple programmers on the same project usually doesn't impose a problem usually - the problem arises when one programmer who doesn't have a clue of the programm tries to modify something on his own - that might have disastrous consequences. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 25 13:05:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XhHz-00024J-00 for ; Thu, 25 Jul 2002 14:00:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 14:00:15 +0200 (CEST) Received: (qmail 14241 invoked by uid 0); 25 Jul 2002 10:56:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 25 Jul 2002 10:56:56 -0000 Received: by moria.seul.org (Postfix) id E0370146823; Thu, 25 Jul 2002 06:56:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAB9814694A; Thu, 25 Jul 2002 06:56:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 75646146823 for ; Thu, 25 Jul 2002 06:56:54 -0400 (EDT) Received: from f-cpu.org (kdl11-21.n.club-internet.fr [213.44.9.21]) by relay-1v.club-internet.fr (Postfix) with ESMTP id ED1FB1687 for ; Thu, 25 Jul 2002 12:56:48 +0200 (CEST) Message-ID: <3D3FDB96.828B5E9F@f-cpu.org> Date: Thu, 25 Jul 2002 13:05:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] "yet another ROP2 version" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! so i've finally debugged the newest version. i have included Jaap's files but have not checked them extensively. I am rather impressed by his work, btw, but "we have a lot of work left to do" :-) My recent additions are a complete synch between the C and VHDL versions of ROP2. VHDL is straight-forward with the IEEE textio package, C requires stdio and a tiny "library". i think i'll even remove vhdl/stimulib. This test is CRITICAL for the project. It is not enough to have the code, it is important to prove that it works. The problem gets even WORSE with different langages. Now that i have stressed my ROP2 code, i'm certain that both versions behave exactly the same. Then all the units will have to pass the same kind of tests... fortunately, now, we can write the test vectors either with VHDL or C, or even both. However, could someone help me rewrite the following : (in f-cpu/vhdl/eu_rop2/vect_rop2.vhdl) -- lame, lame, lame, but it should work... function val(a : integer) return std_ulogic is begin if a = 1 then return '1'; else return '0'; end if; end val; begin for a in 0 to 1 loop l_ROP2_in_A := F_VECTOR'(others => val(a)); for b in 0 to 1 loop l_ROP2_in_B := F_VECTOR'(others => val(b)); for c in 0 to 1 loop l_ROP2_in_C := F_VECTOR'(others => val(c)); all_functions; end loop; -- c end loop; -- b end loop; -- a all i wanted is transform the integer into a std_ulogic but never found the right casting :-/ i have not yet uploaded the latest "correct" snapshot. i'll do this ASAP, though i had already posted something tonight on f-cpu.seul.org/new (contains a few flaws). Yet another remark : Jaap's version of include/f-cpu_types.h is still flawed, i remarked this when running gcc -Wall -W. You can use the newest version from my (not so complete but this flaw is already corrected) tonight's snapshot. Please also update configuration/f-cpu_types.h.in, so new builds won't revert to the old flawed version. ok, i have a lot of other things to do now... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 25 13:52:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XhHz-00024J-01 for ; Thu, 25 Jul 2002 14:00:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 14:00:15 +0200 (CEST) Received: (qmail 17535 invoked by uid 0); 25 Jul 2002 11:43:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 25 Jul 2002 11:43:13 -0000 Received: by moria.seul.org (Postfix) id 28A62146943; Thu, 25 Jul 2002 07:43:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C2C614696F; Thu, 25 Jul 2002 07:43:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id D63E2146943 for ; Thu, 25 Jul 2002 07:43:10 -0400 (EDT) Received: from f-cpu.org (kdl11-17.n.club-internet.fr [213.44.9.17]) by relay-5v.club-internet.fr (Postfix) with ESMTP id A648F16C2 for ; Thu, 25 Jul 2002 13:43:08 +0200 (CEST) Message-ID: <3D3FE671.C0B1691@f-cpu.org> Date: Thu, 25 Jul 2002 13:52:17 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Cedric BAIL wrote: > Finally you take time to read it, thanks. :-) > > 6.1.2 `loadcons': > > The jury is still discussing this. > Ok, but you and thomas write the latest post, because nobody answer, I > was thinking it was decided. i am definitely against. > > 7.1.7 `syscall'/`trap': > > It's still not clear what the difference is. > > I suppose both instructions perform an SRB. the difference is that "syscall" uses CPU cycles in a shared library or something like that, on behalf of the calling task. A trap is used for exceptional conditions, not common functions. But that old question could still change a bit... > Ok, I will update the manual as quick as possible. But was did you think about > a red warning on page that are still discussing ? if you can do it : great ! i'd even also add a flag that says that the instruction is implemented and frozen. Now that i have fully tested ROP2, i should take time to rewrite the corresponding parts of the manual and validate them. > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Jul 25 14:08:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xhy6-0002gi-00 for ; Thu, 25 Jul 2002 14:43:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 14:43:46 +0200 (CEST) Received: (qmail 13426 invoked by uid 0); 25 Jul 2002 12:15:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 25 Jul 2002 12:15:11 -0000 Received: by moria.seul.org (Postfix) id A12DD14696F; Thu, 25 Jul 2002 08:15:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 926A2146979; Thu, 25 Jul 2002 08:15:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 0817514696F for ; Thu, 25 Jul 2002 08:15:09 -0400 (EDT) Received: from laposte.net (193.250.154.62) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D359CE900089BE4 for f-cpu@seul.org; Thu, 25 Jul 2002 14:15:08 +0200 Message-ID: <3D3FEA3C.4070901@laposte.net> Date: Thu, 25 Jul 2002 14:08:28 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: >>> 6.1.2 `loadcons': >>> The jury is still discussing this. >> >>Ok, but you and thomas write the latest post, because nobody answer, I >>was thinking it was decided. > > i am definitely against. I'm definitely for... Or for any other proposition that allow simple constant loading of any size. And thats not the case for your loadcons/loadconsx. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jul 25 14:49:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xjn4-0004Oc-00 for ; Thu, 25 Jul 2002 16:40:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 16:40:30 +0200 (CEST) Received: (qmail 19765 invoked by uid 0); 25 Jul 2002 12:51:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 25 Jul 2002 12:51:38 -0000 Received: by moria.seul.org (Postfix) id 80AF2146987; Thu, 25 Jul 2002 08:51:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CFB514698F; Thu, 25 Jul 2002 08:51:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id F124A146987 for ; Thu, 25 Jul 2002 08:51:35 -0400 (EDT) Received: from hli (80.15.61.38) by smtp.laposte.net (6.0.053) id 3D32A1F9000B5C6E for f-cpu@seul.org; Thu, 25 Jul 2002 14:51:35 +0200 Message-ID: <006601c233d9$b800b890$263d0f50@hli> From: "Christophe Avoinne" To: References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> Subject: Re: [f-cpu] Manual 0.2.6 Date: Thu, 25 Jul 2002 14:49:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Thursday, July 25, 2002 1:52 PM Subject: Re: [f-cpu] Manual 0.2.6 > hi ! > > Cedric BAIL wrote: > > Finally you take time to read it, thanks. > :-) > > > > 6.1.2 `loadcons': > > > The jury is still discussing this. > > Ok, but you and thomas write the latest post, because nobody answer, I > > was thinking it was decided. > i am definitely against. > > > > 7.1.7 `syscall'/`trap': > > > It's still not clear what the difference is. > > > I suppose both instructions perform an SRB. > the difference is that "syscall" uses CPU cycles in a shared library > or something like that, on behalf of the calling task. A trap is > used for exceptional conditions, not common functions. > But that old question could still change a bit... Well, take an example : On x86, we usually use a INT $0x80 to call a linux syscall, but calling it >from user code has some drawbacks due to the ring change and involve a lot of cycles lost. Two new instructions were introduced with AMD and PII+, which looks like a SYSENTER/SYSCALL and a SYSLEAVE/SYSEXIT (i don't remember if it is AMD which uses SYSENTER/LEAVE instead of SYSCALL/EXIT or PII+) SYSENTER: - just enter syscall handler in supervisor mode and change stack pointer. the supervisor pc and sp are found in SMR registers (say, SR equivalent in x86), so we cannot enter in supervisor mode with any sp or pc, of course. - there is no register saving, so general registers can be usually seen as parameters for syscall (like INT $0x80 for Linux x86 syscall). - should only be called from user mode (calling it from supervisor mode makes non sense since calling SYSLEAVE should return to user mode, so SYSCALL is not reentrant). Don't know if an exception is raised on this case. - the former user pc and sp are saved in two general registers (AMD does both, but PII+ only does one of both if I remember well). SYSLEAVE: - just go back in user mode with restoring user pc and sp from the both registers where they were saved after executing SYSENTER. - can only be called from supervisor mode to leave it, so it is a priviledged instruction (if executing it at user mode, raise an exception) Both instructions are very very very fast compared with the very slow INT n to switch between user and superuser modes. Concerning F-CPU, we could have something like SYSCALL/SYSEXIT but much simpler : syscall/sysexit : one SR could contain the supervisor PC (i.e, the start point of syscall handler, which can only be altered in supervisor mode of course), or have a fixed entry somewhere like interrupts (16- word entries if I remember well, Whygee). SYSCALL R1 - actual user PC is saved in register R1 - supervisor mode is set. - supervisor PC is fetched from SR[syscall_pc] or simply set to a (virtual/physically ?) fix address (syscall code must reside on supervisor pages) - syscall handler uses its stack pointer (using a different global register which is much simpler; its stack must contain only supervisor pages to protect it from user access). - optional : raise an exception if called from supervisor mode. NOTE : SYSCALL being used to be called from user mode, the PC entry in syscall handler should not be blindly provided by the user but by a supervisor entity (here, a protected SR) or with a fixed address only accessible in supervisor mode. SYSEXIT R1 - user mode is set. - former user PC is restored from R1 (saved by SYSCALL) - raise an exception if called from user mode. Please, I'm not telling we must have both instructions but just to instruct how an implementation of a fast syscall can be. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Thu Jul 25 16:06:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xjn9-0004Oc-00 for ; Thu, 25 Jul 2002 16:40:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Jul 2002 16:40:35 +0200 (CEST) Received: (qmail 12065 invoked by uid 0); 25 Jul 2002 14:06:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 25 Jul 2002 14:06:16 -0000 Received: by moria.seul.org (Postfix) id 6900614698F; Thu, 25 Jul 2002 10:06:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38C441469A6; Thu, 25 Jul 2002 10:06:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 8BC7914698F for ; Thu, 25 Jul 2002 10:06:14 -0400 (EDT) Message-ID: <20020725140613.67050.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Thu, 25 Jul 2002 07:06:13 PDT Date: Thu, 25 Jul 2002 07:06:13 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] "yet another ROP2 version" To: f-cpu@seul.org In-Reply-To: <3D3FDB96.828B5E9F@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Yann Guidon wrote: > hi ! > so i've finally debugged the newest version. > i have included Jaap's files but have not checked be carful: snapshot_yg_25_07_2002.tat.bz2 is NOT the same as: snapshot_yg_25_07_2002.tbz i also fixed ther ORed output of YGASM it now compiles and i can run it in fcpusim :-) i used ygasm from stable_yg_12_31_2001.tgz and added: current_instruction = 0; after: /* reset for the next round : */ in: /ygasm/ygasm_bin.c but check the binary output, ygasm is far from being completed ! jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jul 25 17:10:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XypT-0000Fu-00 for ; Fri, 26 Jul 2002 08:43:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:43:59 +0200 (CEST) Received: (qmail 1031 invoked by uid 0); 25 Jul 2002 15:01:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 25 Jul 2002 15:01:08 -0000 Received: by moria.seul.org (Postfix) id 0A3511467F6; Thu, 25 Jul 2002 11:01:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF4CA14699F; Thu, 25 Jul 2002 11:01:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9247B1467F6 for ; Thu, 25 Jul 2002 11:01:04 -0400 (EDT) Received: from f-cpu.org (kll1-106.n.club-internet.fr [213.44.91.106]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2BF0F170B for ; Thu, 25 Jul 2002 17:01:02 +0200 (CEST) Message-ID: <3D4014D3.DD6464B2@f-cpu.org> Date: Thu, 25 Jul 2002 17:10:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "yet another ROP2 version" References: <20020725140613.67050.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > hi, > > --- Yann Guidon wrote: > > hi ! > > so i've finally debugged the newest version. > > i have included Jaap's files but have not checked > > be carful: > snapshot_yg_25_07_2002.tat.bz2 > is NOT the same as: > snapshot_yg_25_07_2002.tbz yes, because one can't erase files through ftp. so i simply gave it another name :-) if you don't know which one is most recent, check the date. the file is also larger (+/-360KB) > i also fixed ther ORed output of YGASM > it now compiles and i can run it in fcpusim :-) unbelievable... > i used ygasm from stable_yg_12_31_2001.tgz > and added: current_instruction = 0; > after: /* reset for the next round : */ > in: /ygasm/ygasm_bin.c > > but check the binary output, ygasm is far from > being completed ! sure... now i have to hurry : there is a meeting this evening in Paris (with Nicole, Etienne, Cédric, Nico, Renaud etc) i probably won't be on the board tonight (haven't slept at all). > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jul 25 17:32:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XypV-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:01 +0200 (CEST) Received: (qmail 4577 invoked by uid 0); 25 Jul 2002 15:35:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 25 Jul 2002 15:35:57 -0000 Received: by moria.seul.org (Postfix) id 6836F146844; Thu, 25 Jul 2002 11:35:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F3081469A6; Thu, 25 Jul 2002 11:35:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id C9AA4146844 for ; Thu, 25 Jul 2002 11:35:54 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6PFZf8P072844 for ; Thu, 25 Jul 2002 09:35:42 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D401A18.80208@jetnet.ab.ca> Date: Thu, 25 Jul 2002 09:32:40 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL wrote: > Ok, I will update the manual as quick as possible. But was did you think about > a red warning on page that are still discussing ? What about "new" "revised" "outdated" "subject to change" html style tags as instead. Text block olors look nice but still alot of printing in done in B&W. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Jul 25 17:45:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XypW-0000Fu-01 for ; Fri, 26 Jul 2002 08:44:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:02 +0200 (CEST) Received: (qmail 16022 invoked by uid 0); 25 Jul 2002 15:48:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Jul 2002 15:48:57 -0000 Received: by moria.seul.org (Postfix) id 05ED014699F; Thu, 25 Jul 2002 11:48:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D64961469AF; Thu, 25 Jul 2002 11:48:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 69C6B14699F for ; Thu, 25 Jul 2002 11:48:56 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6PFmh8P076805 for ; Thu, 25 Jul 2002 09:48:44 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D401D26.7010804@jetnet.ab.ca> Date: Thu, 25 Jul 2002 09:45:42 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> <006601c233d9$b800b890$263d0f50@hli> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe Avoinne wrote: > Please, I'm not telling we must have both instructions but just to instruct > how an implementation of a fast syscall can be. One hack would have a fake stack register and other common registers. This register would be loaded with the 'real' register in use and use of this special register (SU?) provides a indirection for system/user stacks. In system use stack S, in user mode use stack U and SU provides a standard stack for library functions like in C. -- Ben Franchuk - Dawn * 12/24 bit cpu * www.jetnet.ab.ca/users/bfranchuk/index.html ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Jul 25 19:08:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17XypZ-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:05 +0200 (CEST) Received: (qmail 1533 invoked by uid 0); 25 Jul 2002 17:10:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Jul 2002 17:10:31 -0000 Received: by moria.seul.org (Postfix) id 9DCCF1469A6; Thu, 25 Jul 2002 13:10:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B0DF1469B0; Thu, 25 Jul 2002 13:10:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 171D41469A6 for ; Thu, 25 Jul 2002 13:10:30 -0400 (EDT) Received: from hli (80.15.61.38) by smtp.laposte.net (6.0.053) id 3D2EB28C000E4838 for f-cpu@seul.org; Thu, 25 Jul 2002 19:10:29 +0200 Message-ID: <005d01c233fd$e2f1b8f0$263d0f50@hli> From: "Christophe Avoinne" To: Subject: [f-cpu] syscall Date: Thu, 25 Jul 2002 19:08:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C2340E.A5EC79C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_005A_01C2340E.A5EC79C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Of course, we can imagine to use jump to call a supervisor code, like = ARM does. That means the user code must provide the supervisor code = start address, provided this one resides on a supervisor address space. = Jump can have flags to indicate a supervisor mode entering or leaving. But such a thing suppose that a user code is unable to turn a user = address space area in a supervisor address space area. Just take an example : An user code allocates via "mmap" a writable user space. It writes an = executable code into it. it call "mprotect" to change the access rights = so the writable user space turns into an executable supervisor space. = The user space just need to use the "jmp" with providing a start address = in the executable supervisor space... the user code thru its troyan = horse would be now able to spy all the supervisor regions of kernel. =20 =20 ------=_NextPart_000_005A_01C2340E.A5EC79C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Of = course, we can=20 imagine to use jump to call a supervisor code, like ARM does. That means = the=20 user code must provide the supervisor code start address, provided = this one=20 resides on a supervisor address space.  
 
Jump can have flags to indicate a = supervisor=20 mode entering or leaving.
 
But such a thing suppose that a user = code is unable=20 to turn a user address space area in a supervisor address space=20 area.
 
Just take an example :
 
An user code = allocates via "mmap" a=20 writable user space. It writes an executable code into it. it call = "mprotect" to=20 change the access rights so the writable user space turns into an=20 executable supervisor space. The user space just need to use = the "jmp"=20 with providing a start address in the executable supervisor space... the = user=20 code thru its troyan horse would be now able to spy all the = supervisor=20 regions of kernel.  
 
 
 
 
 
 
------=_NextPart_000_005A_01C2340E.A5EC79C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 25 15:55:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xypc-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:08 +0200 (CEST) Received: (qmail 23800 invoked by uid 0); 25 Jul 2002 17:48:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 25 Jul 2002 17:48:09 -0000 Received: by moria.seul.org (Postfix) id B01B0146942; Thu, 25 Jul 2002 13:48:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A667A14694D; Thu, 25 Jul 2002 13:48:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 24C93146942 for ; Thu, 25 Jul 2002 13:48:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00799; Thu, 25 Jul 2002 15:55:32 +0200 Message-ID: <20020725155532.01836@thrai.stud.uni-hannover.de> Date: Thu, 25 Jul 2002 15:55:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D3FE671.C0B1691@f-cpu.org>; from Yann Guidon on Thu, Jul 25, 2002 at 01:52:17PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 25, 2002 at 01:52:17PM +0200, Yann Guidon wrote: [...] > > > 7.1.7 `syscall'/`trap': > > > It's still not clear what the difference is. > > > I suppose both instructions perform an SRB. > the difference is that "syscall" uses CPU cycles in a shared library > or something like that, on behalf of the calling task. A trap is > used for exceptional conditions, not common functions. > But that old question could still change a bit... Shared library calls usually are ordinary function calls. Two different instructions only make sense if one of them - doesn't switch to supervisor mode - doesn't perform an SRB (that is, works in the context of the caller). But how are you going to return from it? `rte' won't work because it assumes that a context switch has been performed. The only form that would make sense is syscall imm16, r1 which performs r1 := pc + 4 pc := table_from_some_SR[imm16] (plus range checking) but nothing else. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 25 15:31:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xypc-0000Fu-01 for ; Fri, 26 Jul 2002 08:44:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:08 +0200 (CEST) Received: (qmail 14765 invoked by uid 0); 25 Jul 2002 17:48:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 25 Jul 2002 17:48:11 -0000 Received: by moria.seul.org (Postfix) id C8F4214694D; Thu, 25 Jul 2002 13:48:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3BCB146947; Thu, 25 Jul 2002 13:48:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 0635514694D for ; Thu, 25 Jul 2002 13:48:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00745; Thu, 25 Jul 2002 15:31:42 +0200 Message-ID: <20020725153142.61694@thrai.stud.uni-hannover.de> Date: Thu, 25 Jul 2002 15:31:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "yet another ROP2 version" References: <3D3FDB96.828B5E9F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D3FDB96.828B5E9F@f-cpu.org>; from Yann Guidon on Thu, Jul 25, 2002 at 01:05:58PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 25, 2002 at 01:05:58PM +0200, Yann Guidon wrote: [...] > However, could someone help me rewrite the following : > (in f-cpu/vhdl/eu_rop2/vect_rop2.vhdl) > > -- lame, lame, lame, but it should work... > function val(a : integer) > return std_ulogic is > begin > if a = 1 then > return '1'; > else > return '0'; > end if; > end val; > > begin > > for a in 0 to 1 loop > l_ROP2_in_A := F_VECTOR'(others => val(a)); > for b in 0 to 1 loop > l_ROP2_in_B := F_VECTOR'(others => val(b)); > for c in 0 to 1 loop > l_ROP2_in_C := F_VECTOR'(others => val(c)); > all_functions; > end loop; -- c > end loop; -- b > end loop; -- a > > all i wanted is transform the integer into a std_ulogic > but never found the right casting :-/ constant std_0 : std_ulogic := '0'; constant std_1 : std_ulogic := '1'; begin for a in std_0 to std_1 loop l_ROP2_in_A := (others => a); for b in std_0 to std_1 loop l_ROP2_in_B := (others => b); for c in std_0 to std_1 loop l_ROP2_in_C := (others => c); all_functions; end loop; end loop; end loop; -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jul 25 14:24:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xypd-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:09 +0200 (CEST) Received: (qmail 24950 invoked by uid 0); 25 Jul 2002 17:48:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 25 Jul 2002 17:48:20 -0000 Received: by moria.seul.org (Postfix) id 6CCE2146947; Thu, 25 Jul 2002 13:48:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 649A2146953; Thu, 25 Jul 2002 13:48:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id CF77F146947 for ; Thu, 25 Jul 2002 13:48:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00577; Thu, 25 Jul 2002 14:24:41 +0200 Message-ID: <20020725142441.42821@thrai.stud.uni-hannover.de> Date: Thu, 25 Jul 2002 14:24:41 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027584579.3d3fb243503a7@imp.free.fr>; from Cedric BAIL on Thu, Jul 25, 2002 at 10:09:39AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Jul 25, 2002 at 10:09:39AM +0200, Cedric BAIL wrote: [...] > Ok, I will update the manual as quick as possible. But was did you think about > a red warning on page that are still discussing ? Good idea. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 00:37:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xypv-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:27 +0200 (CEST) Received: (qmail 17272 invoked by uid 0); 25 Jul 2002 22:28:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 25 Jul 2002 22:28:18 -0000 Received: by moria.seul.org (Postfix) id EFB7D1467E9; Thu, 25 Jul 2002 18:28:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC75A146945; Thu, 25 Jul 2002 18:28:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 6437E1467E9 for ; Thu, 25 Jul 2002 18:28:16 -0400 (EDT) Received: from f-cpu.org (kdl4-19.n.club-internet.fr [213.44.3.19]) by relay-4v.club-internet.fr (Postfix) with ESMTP id CA0A216A9 for ; Fri, 26 Jul 2002 00:28:13 +0200 (CEST) Message-ID: <3D407DA3.5EF46E9D@f-cpu.org> Date: Fri, 26 Jul 2002 00:37:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "yet another ROP2 version" References: <3D3FDB96.828B5E9F@f-cpu.org> <20020725153142.61694@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Thu, Jul 25, 2002 at 01:05:58PM +0200, Yann Guidon wrote: > [...] > > However, could someone help me rewrite the following : > > (in f-cpu/vhdl/eu_rop2/vect_rop2.vhdl) > > all i wanted is transform the integer into a std_ulogic > > but never found the right casting :-/ > > constant std_0 : std_ulogic := '0'; > constant std_1 : std_ulogic := '1'; > begin > for a in std_0 to std_1 loop > l_ROP2_in_A := (others => a); > for b in std_0 to std_1 loop > l_ROP2_in_B := (others => b); > for c in std_0 to std_1 loop > l_ROP2_in_C := (others => c); > all_functions; > end loop; > end loop; > end loop; oh yes, i did not know where this trick was located in your code... thanks :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 26 00:51:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Xypw-0000Fu-00 for ; Fri, 26 Jul 2002 08:44:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 08:44:28 +0200 (CEST) Received: (qmail 28246 invoked by uid 0); 25 Jul 2002 22:52:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 25 Jul 2002 22:52:00 -0000 Received: by moria.seul.org (Postfix) id 5DDAF14680C; Thu, 25 Jul 2002 18:51:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 441AC14694E; Thu, 25 Jul 2002 18:51:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id 4FAC314680C for ; Thu, 25 Jul 2002 18:51:57 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02543; Fri, 26 Jul 2002 00:51:52 +0200 Message-ID: <20020726005152.24357@thrai.stud.uni-hannover.de> Date: Fri, 26 Jul 2002 00:51:52 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] "yet another ROP2 version" References: <3D3FDB96.828B5E9F@f-cpu.org> <20020725153142.61694@thrai.stud.uni-hannover.de> <3D407DA3.5EF46E9D@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3D407DA3.5EF46E9D@f-cpu.org>; from Yann Guidon on Fri, Jul 26, 2002 at 12:37:23AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 26, 2002 at 12:37:23AM +0200, Yann Guidon wrote: [...] > oh yes, i did not know where this trick was located in your code... In some of the testbenches... > thanks :-) Da man nich für ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Jul 26 15:18:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKi-0008Px-00 for ; Fri, 26 Jul 2002 21:01:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:00 +0200 (CEST) Received: (qmail 24129 invoked by uid 0); 26 Jul 2002 13:18:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 26 Jul 2002 13:18:18 -0000 Received: by moria.seul.org (Postfix) id 6DEB31467F3; Fri, 26 Jul 2002 09:18:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38E461467FC; Fri, 26 Jul 2002 09:18:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id D74D01467F5 for ; Fri, 26 Jul 2002 09:18:16 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 27CC8180F7 for ; Fri, 26 Jul 2002 15:18:16 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id E303064113; Fri, 26 Jul 2002 15:18:15 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Conditionnal Load and Store Message-ID: <1027689495.3d414c17bd2c6@imp.free.fr> Date: Fri, 26 Jul 2002 15:18:15 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Why didn't we have conditionnal load and store. I mean somtehing like storez, storenz, loadz, loadnz, ... It can be really usefull and we can do with that all what we can do with predicate I think. For example if you have : if (r1 == 0) *r2 = r3 You currently must do a jump or a load and a conditionnal move after. Something like that : load [r2], r4 movez r1, r3, r5 movenz r1, r4, r5 store [r2], r5 will be : storez r1, [r2], r3 With conditionnal load you can really reduce the memory bandwith usage without using jump. Sample : if (r1 == 0) r2 = *r3 else r2 = *r4 You have somtehing like : load [r3], r5 load [r4], r6 movez r1, r5, r2 movenz r1, r6, r2 Will be : loadz r1, [r3], r2 loadnz r1, [r4], r2 It will really help the compiler I think to produce efficient code without stupid jump, but it will cost 8 OP codes for load and 8 more OP codes for store. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 26 16:13:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKj-0008Px-00 for ; Fri, 26 Jul 2002 21:01:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:01 +0200 (CEST) Received: (qmail 24203 invoked by uid 0); 26 Jul 2002 14:13:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 26 Jul 2002 14:13:54 -0000 Received: by moria.seul.org (Postfix) id 8FD401467FC; Fri, 26 Jul 2002 10:13:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B0FF14681A; Fri, 26 Jul 2002 10:13:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id A81001467FC for ; Fri, 26 Jul 2002 10:13:52 -0400 (EDT) Message-ID: <20020726141351.29507.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 07:13:51 PDT Date: Fri, 26 Jul 2002 07:13:51 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] Manual 0.2.6 To: f-cpu@seul.org In-Reply-To: <20020725155532.01836@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N sorry if this has been found before, but somewhere in the manual ther is a "F-CPUU" i think that should be "F-CPU" jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 26 16:30:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKk-0008Px-00 for ; Fri, 26 Jul 2002 21:01:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:02 +0200 (CEST) Received: (qmail 28720 invoked by uid 0); 26 Jul 2002 14:30:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 26 Jul 2002 14:30:44 -0000 Received: by moria.seul.org (Postfix) id 9C3C714680E; Fri, 26 Jul 2002 10:30:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D1E214681D; Fri, 26 Jul 2002 10:30:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 8C11114680E for ; Fri, 26 Jul 2002 10:30:41 -0400 (EDT) Message-ID: <20020726143040.7237.qmail@web14205.mail.yahoo.com> Received: from [130.89.243.164] by web14205.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 07:30:40 PDT Date: Fri, 26 Jul 2002 07:30:40 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] Conditionnal Load and Store To: f-cpu@seul.org In-Reply-To: <1027689495.3d414c17bd2c6@imp.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Cedric BAIL wrote: > Why didn't we have conditionnal load and store. I - snip - > but it will cost 8 OP codes for load > and 8 more OP codes for store. or as a compromize, only check for z/nz, and not MSB,LSB,etc. that will cost only 1 exta opcode for load and 1 extra for store. (unconditional load/store -> check r0 for zero) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jul 26 16:34:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKk-0008Px-01 for ; Fri, 26 Jul 2002 21:01:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:02 +0200 (CEST) Received: (qmail 31236 invoked by uid 0); 26 Jul 2002 14:34:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 26 Jul 2002 14:34:26 -0000 Received: by moria.seul.org (Postfix) id A006114681A; Fri, 26 Jul 2002 10:34:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84677146828; Fri, 26 Jul 2002 10:34:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id BA18C14681A for ; Fri, 26 Jul 2002 10:34:23 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207261434.0c8e; Fri, 26 Jul 2002 14:34:12 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Conditionnal Load and Store From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jul 2002 14:34:12 GMT Message-id: <200207261434.0c8e@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N To be as "clean" as possible, does we need to handle everywh= ere the same test ? I think so. z/nz/MSB/LSB 4 opcodes and where is the other 4 ? nicO -----Message d'origine----- De: jaap stolk A: f-cpu@seul.org Date: 26/07/02 Objet: Re: [f-cpu] Conditionnal Load and Store --- Cedric BAIL wrote: > Why didn't we have conditionnal load and store. I - snip - > but it will cost 8 OP codes for load > and 8 more OP codes for store.=20 or as a compromize, only check for z/nz, and not MSB,LSB,etc. that will cost only 1 exta opcode for load and 1 extra for store. (unconditional load/store -> check r0 for zero) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 16:57:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKl-0008Px-00 for ; Fri, 26 Jul 2002 21:01:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:03 +0200 (CEST) Received: (qmail 25314 invoked by uid 0); 26 Jul 2002 14:48:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 26 Jul 2002 14:48:26 -0000 Received: by moria.seul.org (Postfix) id E8FB914681D; Fri, 26 Jul 2002 10:48:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BE9BD14693F; Fri, 26 Jul 2002 10:48:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 7E14014681D for ; Fri, 26 Jul 2002 10:48:24 -0400 (EDT) Received: from f-cpu.org (kro1-199.n.club-internet.fr [213.44.93.199]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 3230518EA for ; Fri, 26 Jul 2002 16:48:21 +0200 (CEST) Message-ID: <3D41635C.132123EC@f-cpu.org> Date: Fri, 26 Jul 2002 16:57:32 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store X-Priority: 2 (High) References: <1027689495.3d414c17bd2c6@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > Why didn't we have conditionnal load and store. I mean somtehing like storez, > storenz, loadz, loadnz, ... It can be really usefull and we can do with that > all what we can do with predicate I think. conditional loads/stores are a corollary of the conditional moves. IIRC it appeared that these instructions were in fact needed, when we were discussing about the semaphores done with LL/SC. "Store conditional" is this thing. By the way : condition 3 is still reserved for FP, but we could simply connect it to the LSU : LL/SC would then not need any specific opcode. it sounds easy and logical, what do others think ? > It will really help the compiler I think to produce efficient code without > stupid jump, but it will cost 8 OP codes for load and 8 more OP codes for store. that's not a real problem. it is important to keep the instruction orthogonal, and we have enough room, particularly if you consider that Loads and Stores make 30 or 40% of a program. Could you add a page about conditional loads and stores to the manual ? (that is marked "highly speculative") *************************************************************** HOWEVER I HAVE A BIG PROBLEM WITH THE MSB CONDITION CODE ! i believe i told this on the list, but no solution is known yet. Currently, the "MSB" condition just takes the 63th bit of the pointed register. But what about larger registers ? what about small integers ? I stick to the original definition because i don't have a satisfying answer to both questions. - larger registers is not really a problem because a task or system will always start up in "compatibility" 64-bit mode, with all 4 size flags set to emulate the "standard" 8-16-32-64 sizes. - small integers can't be tested because we don't have enough bits to code the size. The corresponding bits are used for other flags. Except maybe in the conditional move, but these size flags indicate what size to move, not the size to test. *************************************************************** > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 16:57:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKm-0008Px-00 for ; Fri, 26 Jul 2002 21:01:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:04 +0200 (CEST) Received: (qmail 9624 invoked by uid 0); 26 Jul 2002 14:48:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 26 Jul 2002 14:48:34 -0000 Received: by moria.seul.org (Postfix) id 8B04F14693F; Fri, 26 Jul 2002 10:48:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 58EE014694E; Fri, 26 Jul 2002 10:48:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id EAC2814693F for ; Fri, 26 Jul 2002 10:48:28 -0400 (EDT) Received: from f-cpu.org (kro1-199.n.club-internet.fr [213.44.93.199]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 74B751684 for ; Fri, 26 Jul 2002 16:48:23 +0200 (CEST) Message-ID: <3D41635F.F6CBCB6C@f-cpu.org> Date: Fri, 26 Jul 2002 16:57:35 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020726141351.29507.qmail@web14203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > > sorry if this has been found before, but > somewhere in the manual ther is a > "F-CPUU" > i think that should be "F-CPU" :-))) > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 17:54:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKo-0008Px-01 for ; Fri, 26 Jul 2002 21:01:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:06 +0200 (CEST) Received: (qmail 15016 invoked by uid 0); 26 Jul 2002 15:45:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 26 Jul 2002 15:45:48 -0000 Received: by moria.seul.org (Postfix) id 72EF0146828; Fri, 26 Jul 2002 11:45:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37E8414694E; Fri, 26 Jul 2002 11:45:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id C947D146828 for ; Fri, 26 Jul 2002 11:45:46 -0400 (EDT) Received: from f-cpu.org (kdl11-36.n.club-internet.fr [213.44.9.36]) by relay-5v.club-internet.fr (Postfix) with ESMTP id E45641859 for ; Fri, 26 Jul 2002 17:45:44 +0200 (CEST) Message-ID: <3D4170D0.A906FDE4@f-cpu.org> Date: Fri, 26 Jul 2002 17:54:56 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Conditionnal Load and Store References: <200207261434.0c8e@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > To be as "clean" as possible, does we need to handle everywhere the same > test ? I think so. > > z/nz/MSB/LSB 4 opcodes and where is the other 4 ? no it's not z and nz, the 3rd bit XORs the condition (so we have z and nz, MSB and ~MSB etc.) Currently we implement 3 conditions : zero, MSB and LSB. the 4th condition is still reserved for FP but it could be useful to use it for LL/SC. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 26 19:31:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKt-0008Px-01 for ; Fri, 26 Jul 2002 21:01:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:11 +0200 (CEST) Received: (qmail 11044 invoked by uid 0); 26 Jul 2002 17:33:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 26 Jul 2002 17:33:46 -0000 Received: by moria.seul.org (Postfix) id CCB71146832; Fri, 26 Jul 2002 13:33:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A34E914693C; Fri, 26 Jul 2002 13:33:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id B76A2146832 for ; Fri, 26 Jul 2002 13:33:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01638; Fri, 26 Jul 2002 19:31:21 +0200 Message-ID: <20020726193121.31085@thrai.stud.uni-hannover.de> Date: Fri, 26 Jul 2002 19:31:21 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] CMP Execution Unit Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=VS++wcV0S1rZb1Fb X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii We've been talking about this some days ago on the web. It contains the currently missing parts from EU_INC (cmp, min/max/sort, msb0 and msb1) and may be merged with EU_INC one day (that is, both units may share I/O ports). The implementation is rather simple; there's still some unnecessary code duplication, and the layout could be improved as well (e.g. by `interleaving' the trees for different chunk sizes). But it works :) The timing is pretty tight: I had do violate the Six Gate Rule in the second stage (but there are only and/or gates and muxes - I guess it's not a problem). Synthesis reports are welcome, as usual. For the record: all operations have a latency of two clock cycles. It is possible to perform 8-bit compares in a single cycle, but that will require an additional unit which can do nothing else, or a more serious violation of the Six Gate Rule. Sometimes I think we might do better with a `Twelve Gate Rule', half the clock frequency, and shorter pipelines - at least when I look at benchmark results of the Pentium 3 and 4 families... the P4 clocks are much higher, but the CPUs aren't much faster. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --VS++wcV0S1rZb1Fb Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-cmp-mr-20020726.tar.gz" H4sIABSAQT0CA+0ca3PaSDJf4VdMcGoNCdgSz5wdUotZsnFdcFJ+XOytq+KEGLDWQuIkYcPV /vjr7hk9AEmA7SR7e+gDaLqne3p6enp6ZhqG+mRa0seT0tgplRWlrDTK9cMXz/uwqtKo1dgL xphardI3K8tv8SiMNWplpaKABFWoVW6o1Res9uI7PFPX0xzGXowN/VbjZmI9qDYcvvjLPcO4 8efTHoAOf9z4V9X6bvx/+Pgb8FGvHtzfDswntaEqSl2Oe8z4lwFWF+NfbjTqNRz/ekVtvGDK bvy/+VMqscgwMyh+KLW/XLF6tdQ3PHZqeXzEHda2xxPN4ezKMrwsVGrbk7ljjG49lm8XGBoO 6woFsnODTzh7J/X5s+tNBwdTyyjdapZl33PnYMDfAwvkcnlruGzi2CNHGzN4HTqcM9ceeg/Q 1jGb21OmaxZz+MBwPcfoTz3OQCjNGhzaDhvbA2M4Rz4Am1oDENO75czjzthl9pAKv55dsV+5 xR3NZF+mfdPQ2SdD55bLmQZNI8S95QPWJz5I8QFluJAysA82MNY8w7aOGTcA7zDoggtlVvbb kAyLzHaQSV7zUHKH2ROkK4C4c2ZqXkh6kND9sJcDZljE+9YGXXq3wBL6+GCYJutzNnX5cGoW kQVUZl9PLz9+vrpkrbMb9rV1ft46u7w5hsrerQ1Yfs8FK2M8MQ3gDP1yNMubg/jIods5b38E ktbJ6afTyxvoBPtwennWubhgHz6fsxb70jq/PG1ffWqdsy9X518+X3QOGLvgKBZHBikqHtIo gRoH3NMM0/U7fgMD64J05oDdavccBljnxj3IpjEdDGv94CETzbStEXUTKoeKPGbGkFm2V2QP jgH24tmrw4rk4cgWwcr1gyKr/Y1dclASZ19MTYfxvJgig0pFKbIT2/WwZrcFi1VZVdWSWlEa jF1dtLLI7dXp4Cg6kYr3TD1QaWIcKo3Dch182lHt7VFZYXJisM5swl5ls6bRdzRnzk47nc5x FoaW3g5cb9Az7ZGh91RYCw800xTIB9u5OzgxvF5Xs4zJ1KQeCHSWW54B43raRjHAoLKZEWoP 1JbPZjJfT3+5/MiOmKV5U9ToURMmeQZkH9ioLwZSWSP+MpspHGczE9vxiArwYIJgMGiSk6kH TDMt4AL2iSJOhYz3XPdsJ09NlFTg+GCB3hXklDnZqrbfnmfA4MIM59ggep9lLlj5AqWMgXfd vpIAV+Pg0OjQ1EbY1IUxsvigCw0nVLw47f5CgjEXbE+/JQGvkvpYXumdbtr63aHDXe6FGm2b d3HNnbux3etYMVCYWZnMDQwrw1m/obZvbjevT4ZRKk0cbTTWmDu3YFq5htuzh8Nsn48MK5vR XJc76JDQ0tC8oAmHky3lHowBzFSY2WiebAzLLrqyejUHdVxwUg6a7hC8xBRcf2w7Fhj4QFo3 WLvm6LcwP3WwZs5OODqSnuo3IO3fhdEEU+9CL1d72FjQhazq9Laq3IqtHKfrgORke5L29iTX yttHEKn1RxBVyo8gggHamojsfsHoJepmbFjbsrsZa7OtaXTyQ1u24/Y3pZHTqMveNcn5Kqz5 nkKvIhRULKDHw0IZC+jmsFCRBRULVaoWeDEE1RB0lVcKWKiLgkqFhiiUxeQGmT1thLPoCFdT nbsuy7dg8YN1r8jARxUZeKQi61hQPzOcWjouPrBwTK07lr9O8IHoZ/A5E3i5/BRg0YeXmPo0 cTMZ3bZAGguinsU163rf5NbIuyW2mmlAGDeLH8iHqHIxvrommnvNMbQ+rPLz+XqyRQrPi6U4 W6YQ45jgK1Fs4SfP2HumHEcAD+x9k50tQmCpgYpNrBjvFKEyxlkGKvfhMCoLM217QtpHwZug p/zZa+NNpAoURRdlDQj5ew46Y5fndc3VtQHvQQejYM8rFBZo4HMG7TvurTH0AF1kqsTP53Ht CRqqgf4cZaSCtIf5HEuIIbtCqwwHYDzewDmH1TVt49kaEvX7jyDS9UcQzWaPIdrCsUeotvDs EaotXHuEagvfLj1eBkcKzMKGdUvNt8Qk6kdAJwTC4Q9AXfJYGFJ5GNtTLMVcbkJjAjxoluEF dgPjcb5SgCm0r+7jXoCmDO58wGPiKw5DE2yF7M50BUE5nkAJCTBmDoi4rILO+hCddJQxzY9+ 37drY+gLDvsrlN315a3DC41vUxh/fjYrMvaW+k4jGIWrdQHHMYrCK2UBx1GIwuvVQGEQ6Q9g oFxaJWDLRXv7Q1eITZJU4AVtGtYhG3e9Li4U+8o+sdb1fL1C8xgUVfVBtVoIwi06KQhKNb9C tRFfoe5XqPxtDYeKGl+h4VcoV9ZwUGtrZGCNdA6kUz0YUaGviTHhpmHhRnYEe3juCLuThgpr 5rIxYeD4Lla3GQwQE1HtZFQ3GYWxYDIS7CoZCcaVjAQLS0RCrAY4AISzyjFc2NT1+GDE8xBM FAJthKqCyGJJU76qxEwL1CNmU6ASXfeLpIbx2C/KrsOkCiCivzCdAojoJEykACJ6NsN9Riac tJGOdazobKYXGTGFYVQ5GkZBN4oY/ONHGz+6RRGlF0XcXRSRdFHExhhfEekANzcywBKRGBCv i7TYTdewivCpwbS/gd0QvlMUGrvVK2wfcSUsrCsRVytCk7CurtCcRGgSltUVmvbTo8GkLURK OJi0g0ghSdpApLXi9p8pTn04LCfTmGimS9urCPoutIkwwoUKgqyJZ7RTnYJFGDP0m7OZaIB6 vOAlkETgwolPsOWpT0MSTn1SdzD1/UXXr+V7BFlLEkWmLukx3l0F8bOCx4UVNQyc+QzPXUEg Vn792oB4/UG0coesROxO1L8jtYrUDyEx9u93CuCBOG+8gdUL4ntiFPQRo+j8XUGG57+zUhA9 y0bu2BumSkikN4uxs79duAt2FCEEvBUMvFSO28+LCDwcL2w/ahaF1dAc/QmtioYly0LJoGtR botBhrGWeKFraO75gnloHL0ltIlf0BSVICR7TDwMzNDnAjP8AmZUgoCw/jhm6LmBGX4BMyq5 /UdFz8CsXiVm+EUnysTsEUE1Ria268k1CNZeP7qrZSM2TxwO38btG0Xw6C/DefYWdnMsGB8s 0ikCrcqp2HYqFlbBFDyNexoeDSIFT5aSRo8mFIsv+MbrT4Qlnan1DZSm1oGxWvPrYTGitDRs OxULMUMKnuw7DY+Gn4KnGZFGj1MlFr9OaZXyBkqrlIFxJaiHxYjS0rDtVCxEWCl4msdpeJzg KXia+Wn06BJi8euUVq9uoLR6FRjXK349LEaUloZtp2IhHk3Bk79Kw6MjS8GTh0ujR9cXi19S mrw8mnryTiXYUS+cGkDgTXRil99YjjnoJPldU3hhsZZhQPGuKRyygGBI864pfLOsA+vdu6Zw 0wvHCPWUBuR+I9KADwkbCOoEDQhI0EAtpQG5xYk04EPCBoI6QQMC4odXEXZyDxVh50NCdkGd gJ2AJO2UYLh64+lscacEWyNstkhn9EU6dS/SOXph6/AhshReX18fsVN2b9h4GU+Xwv+6MGbs VyydT02+zyAw5Hi5bVg6VXD4vrQky2bXn8/ZCOvKq/mB5mkTTdxpYdnlsIEaMNr7FQXVKShp zkbcY9oDvNBdteEdHBz45tlIMk9dczmdWy3sWVC1FIzmVEVRcuwPllNUfIFgVh5oHfqHVHgX CCNwI2Mwuutb2q1fy/BXsFSAlc/JP8EKmMjATzK58QM/n1JRfUo8AItS+iHhuuYDeIQ4rnIy H4oyQW3LRoYF/3rwmC7r7w0wHBgUz21WmfsAH/zfU82cOKNmbjj2WKlRZqVJqZQDqzQ5sMy+ +Ms+6/O/eh53vSclga3J/6qXK9Wl/K9GpVbf5X991/yvcJhxGl9Coc8t/ZZyeCD8ONkmGUwt 7lLCdilhu5Swo5W5tXleWMLt8bb5YoS0pmNMA+tBpRCDBY/PoLtLtUNWUXSptFX6GXUZQ5Yw Z4dAy4k7LShE03YCugxeS9kWMJUYWOKj6Wyb57NRQluY0Rab0rZlTtuWSW3xWW2JaW2JeW2J iW2JmW3R1LY1uW2JyW0bZ7clprcl5bclJbjFZ7iJFLetc9y2THIja6FY0rc/3KcEdyOxVkd3 PhummsWfQUtqccVzU2S/bXbYl8pMKD3kgpXFhZysILSfUmEp4Yrw6j72NrycIpcKixTLi+sD B0xc7lXCuwXU/hHDK9LInowo84grMnEhQBCslRfb+CJR+gPit7TY/gQa9PzUobzZNwMp/GP0 TOwtTYCFyRiQYA9z9LF9F7Dpn2BZg66wKHzmlxM7Fu1CXOfEaLgkkd9ylCafa+WKTGRNLMJP AH4SA+8CvBsDvwH4TQz8N4D/tiiuFGpR3oHd446TNBBaD3bzWi827aqw0Dt/qPO5rx8/t9jl x8555+XLl7mIaEH7S7JCw9jIrJCEmRdhiA9xiGV/fKEXuwLOT7/ryZUzwbBYumWxeegolu3J S7gInO07uGwt3gnEG58nLl1WeXh2b2qJ5I78HCKpMd45zeQtLhikfCv4B2EzVAdy88+QfI0I lcGgAbKwcoyzoKE45QmnEas62PdpRdZPtgT/MjdWSZrsQXDwTBe6dOMnyOIz+/qxZP0NVC0v 04J2m8znJTLXRIpzX4Nw1Rm5uHJFNJBjq/nNkRNeOeLBqa4FQZe4cpzjXR243BIlUUQQM4FA /HHseM0LkZS6pbPlcOjkwio7CYs3rPxT0IHcOMEEzGbGpI6VCGysTVhe5nm/F4tiwQ+yCCdi KsC1iiJegteTYhD1YMKqTEgV0Q4BRFKqiHIIUA4AqgBUJEkYyRC4KsBXohSstjUBxoUQE2nN u6IfdEARU1llrAGljlWUwQUUbooyboD330RIQPoZOLAlcfyjJWnw+BLGBxGrUxIW19jKatJK u+hdKbwSEyS4gn/QYCOI5qQyi/whdfid5JBaQabnCCdIvJeaFA6UIsK8a4wHSzm84kgyYfJE JIyu9OQH9vO5169fk43hspuTt84LFaG5GKhPTj9PI8GA0QJ97DobWbmQaKmbKEdvisfYSz3S 7sFL3RcT3XV8xBmQYx9ABj4EScQJSXwWRbjeRbXiO3HKGqFeBtkKsK21woSFMOVAjFGTvWWv 0eljNeFyw67nQ8WKTPPc9fW1Qme4YT4DeaYaMm8s5jMY7J1o/A2iwyyGLrqkiM1FEjQiSGV/ bSYDti4SnvzuiSswlLoUyczISH3KFMfXiJfMUd+U40A13tAoYGKFRGv3y2FzcLic6afgvJVM FvDMPpKUBn5zhmKTANIkhBCh2NB8nioWIh5BNB2FB2rEZvMrDEXkv9oOCqUGQmVE6tz9MRNJ c/ASznNRI7ISyPAvXO1XpVUTpFUeL63y7aRdsLbQwhZK0QK+B54gzkO4fzYP8d38g7rzD0/z D2CZ2OySYfaj0EAzT5hDa6fQmhmkxQrUjxX+CY7pqWLG623FB4fTbueF//e8sJvghaf4Q4U/ Z6BGkn3zSE1V/q89cZDMIe+L8F4CT/PtMeVkpDnqjUh/UJy3ft4lz2rpthcRm07XZLb9jdnS AeHTfNZT+t//Nv3Xnq//j49F0afEBqN/Ojf4/ZygunOCP9IJbhPMrp3Wj5vVayb14+b0mim9 TXD8hG5r36Lb/cd3+/sH27ulcLcUxm0IkpZCzDbGPylYThoofN/l8RkOwqEncWfh0LeUo/AN T8C/yUpMOxK5EuN9DcIx+wYk9oEVAgaA/+fjo9hZlLwtl4p88uHTDzxQWlgmRAPQErWatEAE lpIm+Orc9W/do7ffouVSMFSqvFb6Zocd14/1bSJNP7jaD0+hZcGNFuSewEctlPAnnv74hQA6 jRK/OnA9e4JakMl72eVoPkRRCpTJPR5G83iVGJdgL9L4jrMJ/1Gzy7r/X8z/72p3fGiY/Klt pOf/s0pVKS/l/9ca1V3+/3d59tjSYGf3nimffw84PUs2/97zJPPvPUMu/95GqfxxPd82kX/v qXn8e09M49/bLosf+/z0HP69J6Xw7z1nBv+eSOD3p8XmiftfWu2/t37tsCYblsC5Zv/ROb84 /Ux/4XagKEo26zr6wHCgfJCFpbgXFg+yCAgK7rQv3sUMzWZ12xoKyKu8qFg4RJgxmjpiLYcF e2xbq3UQms22P599IIRkVDgkCXuCB/0+Aep0uyQs1pLMCof4B3DjaMY/1b04b19Azej/Ry// 3iH7y+nF5YfTT50LYokUhUCn2cvOxeVJ56z9sRPyIdps9h8ff/n0BYDIZMJKOHl0j6AdCeXZ r5/P//7p9ATKJfxdQqTHWMxmB3yoTU3v6Phnrt/a7P1PZbZ/ZjMJZuD3R9x7uQ9TH//lQ81m NdM8ymZe5anxAvCTLRR80WGAQLojmPSaOf8P92MlDqQCskiOChffqNQIF58Oqs+auVf5iCIK uWOaXhQwv3o1w4iU/RNCL8G3U0Ag++MPKfQx4ga2BSLoEDVZwNEZs5IzFD/VcOdj0AP4Ht8m pHUWSsBOGGaB8IGxhUp8lZeE+CrwILqAyiK0Nr5Dulc/i2aOgD4YcuxwpHI2g4OO3Q1r5Eh+ 7C/iRJfxLei1CZC8mCIgBuEWuaIq/km/hgczmWxQeVlvuxhw9+ye3bN7ds/u2T27Z/fsnt2z e3bP7tk9u2f37J7d89d8/guyk7EVAHgAAA== --VS++wcV0S1rZb1Fb-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 26 17:46:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKw-0008Px-00 for ; Fri, 26 Jul 2002 21:01:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:14 +0200 (CEST) Received: (qmail 32561 invoked by uid 0); 26 Jul 2002 17:33:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 26 Jul 2002 17:33:58 -0000 Received: by moria.seul.org (Postfix) id 12F8A146833; Fri, 26 Jul 2002 13:33:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08281146953; Fri, 26 Jul 2002 13:33:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id E5B56146833 for ; Fri, 26 Jul 2002 13:33:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA01058; Fri, 26 Jul 2002 17:46:21 +0200 Message-ID: <20020726174621.46397@thrai.stud.uni-hannover.de> Date: Fri, 26 Jul 2002 17:46:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027689495.3d414c17bd2c6@imp.free.fr>; from Cedric BAIL on Fri, Jul 26, 2002 at 03:18:15PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 26, 2002 at 03:18:15PM +0200, Cedric BAIL wrote: > Why didn't we have conditionnal load and store. I mean somtehing like storez, > storenz, loadz, loadnz, ... It can be really usefull and we can do with that > all what we can do with predicate I think. Conditional load/store makes less sense than you may think. When an address is loaded into a register, the prefetch cycle begins, whether or not memory is actually accessed. Thus, there will be no increase in memory bandwidth due to the use of conditional load/store. The only positive effect ist that CL/S will avoid some jumps. That is, in the rare case that you have code like if (condition) { *pointer = expression; } with no preset and no else clause (or a volatile memory location), and with a trivial expression (something that is already present in a register, or can be computed with few additional instructions). If the computation of the expression becomes more complex, a jump is the better choice. As soon as other statements precede or follow the assignment (inside the if clause), it is a must anyway. BTW: Good programmers avoid code like this anyway. Remember that the contents of `*pointer' remain undefined if `condition' evaluates to `false'. It's much better to write: if (condition) { *pointer = expression; } else { *pointer = default_value; } or: *pointer = condition ? expression : default_value; which can be transformed to a conditional move. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jul 26 20:16:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKy-0008Px-01 for ; Fri, 26 Jul 2002 21:01:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:16 +0200 (CEST) Received: (qmail 8394 invoked by uid 0); 26 Jul 2002 18:18:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 26 Jul 2002 18:18:42 -0000 Received: by moria.seul.org (Postfix) id 05727146808; Fri, 26 Jul 2002 14:18:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A73D14693C; Fri, 26 Jul 2002 14:18:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id EDA6D146808 for ; Fri, 26 Jul 2002 14:18:38 -0400 (EDT) Received: from hli (80.15.61.38) by smtp.laposte.net (6.0.053) id 3D2EB28C000F80F4 for f-cpu@seul.org; Fri, 26 Jul 2002 20:18:37 +0200 Message-ID: <001c01c234d0$9015e0b0$263d0f50@hli> From: "Christophe Avoinne" To: References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> Subject: Re: [f-cpu] Conditionnal Load and Store Date: Fri, 26 Jul 2002 20:16:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Friday, July 26, 2002 4:57 PM Subject: Re: [f-cpu] Conditionnal Load and Store > hi, > > Cedric BAIL wrote: > > Why didn't we have conditionnal load and store. I mean somtehing like storez, > > storenz, loadz, loadnz, ... It can be really usefull and we can do with that > > all what we can do with predicate I think. > > > conditional loads/stores are a corollary of the conditional moves. > > IIRC it appeared that these instructions were in fact needed, > when we were discussing about the semaphores done with LL/SC. > "Store conditional" is this thing. > > By the way : condition 3 is still reserved for FP, but we could > simply connect it to the LSU : LL/SC would then not need any specific > opcode. it sounds easy and logical, what do others think ? > I don't really understand how you plan to do so. retry: LL [r1],r2 ==> loading [r1] in r2 and set a lock bit in matching LSU entry. ... SC r2,[r1],r3 ==> storing r2 in [r1] if lock bit in matching LSU entry is set and set r3 to 1, otherwise just set r3 to 0. Then lock bit in matching LSU entry is reset. IF (r3 == 0) JUMP ... // goto retry; As you can see, you need to set this special bit with a LOAD operation and check it and report it in register with a STORE operation So I wonder how you can use condition 3 with LOAD/STORE to do so since STORE would also need to report if storing really occured or not.. NOTE: the given syntax for LL/SC is absolutely not mandatory. They are just an example but the idea still remains the same. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jul 26 20:32:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YAKz-0008Px-00 for ; Fri, 26 Jul 2002 21:01:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 21:01:17 +0200 (CEST) Received: (qmail 16101 invoked by uid 0); 26 Jul 2002 18:34:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 26 Jul 2002 18:34:14 -0000 Received: by moria.seul.org (Postfix) id 1246814684E; Fri, 26 Jul 2002 14:34:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00E0F146946; Fri, 26 Jul 2002 14:34:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 8792B14684E for ; Fri, 26 Jul 2002 14:34:12 -0400 (EDT) Received: from hli (80.15.61.38) by smtp.laposte.net (6.0.053) id 3D2EB28C000F8393 for f-cpu@seul.org; Fri, 26 Jul 2002 20:34:10 +0200 Message-ID: <00bd01c234d2$bba78650$263d0f50@hli> From: "Christophe Avoinne" To: Subject: [f-cpu] Date: Fri, 26 Jul 2002 20:32:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C234E3.7ECE8740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_00BA_01C234E3.7ECE8740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW, what do they mean ? - IIRC - IMHO There is another one, but i don't remember exactly ( FW... ? ). ------=_NextPart_000_00BA_01C234E3.7ECE8740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
BTW, what do they mean  = ?
 
- IIRC
- IMHO
 
There is another one, but i don't = remember exactly=20 ( FW... ? ).
------=_NextPart_000_00BA_01C234E3.7ECE8740-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 26 21:21:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDO-0001Ey-00 for ; Fri, 26 Jul 2002 23:01:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:34 +0200 (CEST) Received: (qmail 12064 invoked by uid 0); 26 Jul 2002 19:21:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 26 Jul 2002 19:21:42 -0000 Received: by moria.seul.org (Postfix) id 712B114680D; Fri, 26 Jul 2002 15:21:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5DF5B146948; Fri, 26 Jul 2002 15:21:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 2579914680D for ; Fri, 26 Jul 2002 15:21:39 -0400 (EDT) Message-ID: <20020726192137.79351.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 12:21:37 PDT Date: Fri, 26 Jul 2002 12:21:37 -0700 (PDT) From: jaap stolk Subject: [f-cpu] register move in 1 x-bar cycle To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, this could be a simple typo, but according to the manual (chapter 6) a register move looks like this: Fetch > Decod > Xbar > Register write (+reg read) (+schedule) (+bypass check) i would like to turn that into Fetch > Decod > Xbar > Xbar > Register w. (+reg read) (+schedule) (+bypass check) ther will be no extra lost cycle (the next instuction will use a direct bypass instead of a delayed bypass) http://f-cpu.seul.org/whygee/parinux/conf_yg.html seems to conferm this. i tryed doing it in one cycle in the c simulator, but it has the folowing complications: -its a reversed bypass (so we need extra hardware to bypass FROM the read bus TO the write bus) -we can't use the schedule queue for the register write (schedule cycle is to late), so we have to control the xbar directly from the decoder. -the x-bar needs to ignore these commands from the decoder in normal operation. can we change it into two x-bar cycles ? jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 21:35:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDP-0001Ey-01 for ; Fri, 26 Jul 2002 23:01:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:35 +0200 (CEST) Received: (qmail 24316 invoked by uid 0); 26 Jul 2002 19:26:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 26 Jul 2002 19:26:02 -0000 Received: by moria.seul.org (Postfix) id ABCF3146946; Fri, 26 Jul 2002 15:26:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85982146949; Fri, 26 Jul 2002 15:26:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 79103146946 for ; Fri, 26 Jul 2002 15:26:00 -0400 (EDT) Received: from f-cpu.org (kdl19-63.n.club-internet.fr [213.44.21.63]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 3B6DB16B0 for ; Fri, 26 Jul 2002 21:25:57 +0200 (CEST) Message-ID: <3D41A46C.91FCF894@f-cpu.org> Date: Fri, 26 Jul 2002 21:35:08 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <001c01c234d0$9015e0b0$263d0f50@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > ----- Original Message ----- > From: "Yann Guidon" > > hi, > > > > > > > > conditional loads/stores are a corollary of the conditional moves. > > > > IIRC it appeared that these instructions were in fact needed, > > when we were discussing about the semaphores done with LL/SC. > > "Store conditional" is this thing. > > > > By the way : condition 3 is still reserved for FP, but we could > > simply connect it to the LSU : LL/SC would then not need any specific > > opcode. it sounds easy and logical, what do others think ? > > I don't really understand how you plan to do so. > > retry: > LL [r1],r2 ==> loading [r1] in r2 and set a lock bit in matching LSU entry. > ... > SC r2,[r1],r3 ==> storing r2 in [r1] if lock bit in matching LSU entry is > set and set r3 to 1, otherwise just set r3 to 0. Then lock bit in matching > LSU entry is reset. > IF (r3 == 0) JUMP ... // goto retry; > > As you can see, you need to set this special bit with a LOAD operation and > check it and report it in register with a STORE operation > > So I wonder how you can use condition 3 with LOAD/STORE to do so since STORE > would also need to report if storing really occured or not.. mmmh i see. My idea goes as follows : The condition is an "attribute" of the condition register, which can be tested with move and jmp as well. Like the "zero" flag, it is regenerated everytime something related happens. So the information of whether the store really occured needs not to be duplicated. The only "problem" is that it is a "volatile" flag, so it might yield false negatives. Your idea is a bit different because it includes "persistent" data. it has drawbacks and advantages. the drawback comes from the fact that the decision history is made "static" or "persistent". One problem is that the condition in your code is at the place of R2, and a specific SC is not desired if we add the generic "conditional store" instruction. The real big problem is that in this instruction, the condition and the pointer are the same register => should not need to be duplicated... There is something i miss, but i don't know what... > NOTE: the given syntax for LL/SC is absolutely not mandatory. They are just > an example but the idea still remains the same. sure. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 21:38:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDQ-0001Ey-00 for ; Fri, 26 Jul 2002 23:01:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:36 +0200 (CEST) Received: (qmail 3748 invoked by uid 0); 26 Jul 2002 19:28:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 26 Jul 2002 19:28:55 -0000 Received: by moria.seul.org (Postfix) id 3F944146948; Fri, 26 Jul 2002 15:28:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37DD914694B; Fri, 26 Jul 2002 15:28:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id CE231146948 for ; Fri, 26 Jul 2002 15:28:52 -0400 (EDT) Received: from f-cpu.org (kdl16-108.n.club-internet.fr [213.44.18.108]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 669C717AD for ; Fri, 26 Jul 2002 21:28:50 +0200 (CEST) Message-ID: <3D41A51A.408ECBBE@f-cpu.org> Date: Fri, 26 Jul 2002 21:38:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register move in 1 x-bar cycle References: <20020726192137.79351.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > > hi, > > this could be a simple typo, but > according to the manual (chapter 6) > a register move looks like this: > > Fetch > Decod > Xbar > Register write > (+reg read) (+schedule) > (+bypass check) > > i would like to turn that into > > Fetch > Decod > Xbar > Xbar > Register w. > (+reg read) (+schedule) > (+bypass check) > > ther will be no extra lost cycle (the next instuction > will use a direct bypass instead of a delayed bypass) > http://f-cpu.seul.org/whygee/parinux/conf_yg.html > seems to conferm this. > > i tryed doing it in one cycle in the c simulator, > but it has the folowing complications: > > -its a reversed bypass (so we need extra hardware > to bypass FROM the read bus TO the write bus) > -we can't use the schedule queue for the register > write (schedule cycle is to late), so we have > to control the xbar directly from the decoder. > -the x-bar needs to ignore these commands from the > decoder in normal operation. > > can we change it into two x-bar cycles ? you're right, the manual is not up to date. btw : could we add a modification date to each instruction in the manual ? This would help people understand what document to trust if there is such another problem. > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 26 21:32:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDS-0001Ey-00 for ; Fri, 26 Jul 2002 23:01:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:38 +0200 (CEST) Received: (qmail 10150 invoked by uid 0); 26 Jul 2002 19:32:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 26 Jul 2002 19:32:39 -0000 Received: by moria.seul.org (Postfix) id 2CBBF146949; Fri, 26 Jul 2002 15:32:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 03743146953; Fri, 26 Jul 2002 15:32:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 86C09146949 for ; Fri, 26 Jul 2002 15:32:35 -0400 (EDT) Message-ID: <20020726193231.81545.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 12:32:31 PDT Date: Fri, 26 Jul 2002 12:32:31 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] register move in 1 x-bar cycle To: f-cpu@seul.org In-Reply-To: <3D41A51A.408ECBBE@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, btw, i found YGASM has some rop2 code, but it won't do 3r1w :( but rop2 sould work in the simulator now... jaap --- Yann Guidon wrote: > hi, > > jaap stolk wrote: > > > > hi, > > > > this could be a simple typo, but > > according to the manual (chapter 6) > > a register move looks like this: > > > > Fetch > Decod > Xbar > Register write > > (+reg read) (+schedule) > > (+bypass check) > > > > i would like to turn that into > > > > Fetch > Decod > Xbar > Xbar > > Register w. > > (+reg read) (+schedule) > > (+bypass check) > > > > ther will be no extra lost cycle (the next > instuction > > will use a direct bypass instead of a delayed > bypass) > > http://f-cpu.seul.org/whygee/parinux/conf_yg.html > > seems to conferm this. > > > > i tryed doing it in one cycle in the c simulator, > > but it has the folowing complications: > > > > -its a reversed bypass (so we need extra hardware > > to bypass FROM the read bus TO the write bus) > > -we can't use the schedule queue for the register > > write (schedule cycle is to late), so we have > > to control the xbar directly from the decoder. > > -the x-bar needs to ignore these commands from the > > decoder in normal operation. > > > > can we change it into two x-bar cycles ? > > you're right, the manual is not up to date. > > btw : could we add a modification date to each > instruction > in the manual ? This would help people understand > what document to trust if there is such another > problem. > > > jaap. > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 26 21:46:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDS-0001Ey-01 for ; Fri, 26 Jul 2002 23:01:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:38 +0200 (CEST) Received: (qmail 18762 invoked by uid 0); 26 Jul 2002 19:37:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 26 Jul 2002 19:37:28 -0000 Received: by moria.seul.org (Postfix) id 4D4FC14694B; Fri, 26 Jul 2002 15:37:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 44E7C146956; Fri, 26 Jul 2002 15:37:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id E869D14694B for ; Fri, 26 Jul 2002 15:37:26 -0400 (EDT) Received: from f-cpu.org (kdl16-108.n.club-internet.fr [213.44.18.108]) by relay-5v.club-internet.fr (Postfix) with ESMTP id E9DA816E9 for ; Fri, 26 Jul 2002 21:37:24 +0200 (CEST) Message-ID: <3D41A71C.27CE77F3@f-cpu.org> Date: Fri, 26 Jul 2002 21:46:36 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] register move in 1 x-bar cycle References: <20020726193231.81545.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, jaap stolk wrote: > hi, > > btw, i found YGASM has some rop2 code, but > it won't do 3r1w :( > but rop2 sould work in the simulator now... hmmmh .... time to send a snapshot ? :-) > jaap WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Jul 26 22:46:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YCDa-0001Ey-01 for ; Fri, 26 Jul 2002 23:01:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 26 Jul 2002 23:01:46 +0200 (CEST) Received: (qmail 4080 invoked by uid 0); 26 Jul 2002 20:46:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 26 Jul 2002 20:46:41 -0000 Received: by moria.seul.org (Postfix) id 745F8146859; Fri, 26 Jul 2002 16:46:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4CA4C14695B; Fri, 26 Jul 2002 16:46:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 09077146859 for ; Fri, 26 Jul 2002 16:46:39 -0400 (EDT) Message-ID: <20020726204637.81483.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.164] by web14206.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 13:46:37 PDT Date: Fri, 26 Jul 2002 13:46:37 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] register move in 1 x-bar cycle To: f-cpu@seul.org In-Reply-To: <3D41A71C.27CE77F3@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N its on /new/ jaap --- Yann Guidon wrote: > hi again, > > jaap stolk wrote: > > hi, > > > > btw, i found YGASM has some rop2 code, but > > it won't do 3r1w :( > > but rop2 sould work in the simulator now... > hmmmh .... time to send a snapshot ? :-) > > > jaap > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Jul 26 23:37:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YEEr-0002wm-00 for ; Sat, 27 Jul 2002 01:11:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 01:11:13 +0200 (CEST) Received: (qmail 9391 invoked by uid 0); 26 Jul 2002 21:39:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 26 Jul 2002 21:39:55 -0000 Received: by moria.seul.org (Postfix) id B9C03146953; Fri, 26 Jul 2002 17:39:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 93546146964; Fri, 26 Jul 2002 17:39:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 38DF3146953 for ; Fri, 26 Jul 2002 17:39:54 -0400 (EDT) Received: from hli (80.15.61.38) by smtp.laposte.net (6.0.053) id 3D32A1F9000D00B0 for f-cpu@seul.org; Fri, 26 Jul 2002 23:39:53 +0200 Message-ID: <000901c234ec$adad30d0$263d0f50@hli> From: "Christophe Avoinne" To: References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <001c01c234d0$9015e0b0$263d0f50@hli> <3D41A46C.91FCF894@f-cpu.org> Subject: Re: [f-cpu] Conditionnal Load and Store Date: Fri, 26 Jul 2002 23:37:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Friday, July 26, 2002 9:35 PM Subject: Re: [f-cpu] Conditionnal Load and Store > hi, > > Christophe Avoinne wrote: > > ----- Original Message ----- > > From: "Yann Guidon" > > > hi, > > > > > > > > > > > > conditional loads/stores are a corollary of the conditional moves. > > > > > > IIRC it appeared that these instructions were in fact needed, > > > when we were discussing about the semaphores done with LL/SC. > > > "Store conditional" is this thing. > > > > > > By the way : condition 3 is still reserved for FP, but we could > > > simply connect it to the LSU : LL/SC would then not need any specific > > > opcode. it sounds easy and logical, what do others think ? > > > > I don't really understand how you plan to do so. > > > > retry: > > LL [r1],r2 ==> loading [r1] in r2 and set a lock bit in matching LSU entry. > > ... > > SC r2,[r1],r3 ==> storing r2 in [r1] if lock bit in matching LSU entry is > > set and set r3 to 1, otherwise just set r3 to 0. Then lock bit in matching > > LSU entry is reset. > > IF (r3 == 0) JUMP ... // goto retry; > > > > As you can see, you need to set this special bit with a LOAD operation and > > check it and report it in register with a STORE operation > > > > So I wonder how you can use condition 3 with LOAD/STORE to do so since STORE > > would also need to report if storing really occured or not.. > > mmmh i see. > My idea goes as follows : > The condition is an "attribute" of the condition register, which > can be tested with move and jmp as well. Like the "zero" flag, > it is regenerated everytime something related happens. > So the information of whether the store really occured needs not to > be duplicated. The only "problem" is that it is a "volatile" flag, > so it might yield false negatives. In fact, most pair LL/SC are used in a conditional loop as the following example : int atomic_add (int *slot,int delta) { int old_value; // we must loop until we are able to store the new value in slot do { old_value = ll(slot); } while (!sc(old_value + delta,slot)); return old_value; // the very last value we read before really changing it } As you can see, we really need to know if 'sc' succeeds in storing when called. If we cannot have this info, we would have bad behavior : int atomic_add_unsafe (int *slot,int delta) { int old_value = *slot; do { old_value = ll(slot); sc(old_value + delta,slot); } while (*slot != old_value + delta); return old_value; // the very last value we read before really changing it } This second example has a drawback : someone can have changed the value of slot, just after 'sc', so we loop again for nothing ! Worse : A enters function with delta = 1 and is switched off just before 'sc' for B. B also enters functions with delta = 1, executes 'll' then 'sc' which succeeds. When A resumes, its 'sc' aborts (normal behavior) but the while condition *slot != old_value + delta is false (because 'sc' cannot instruct its abort) because it still believes its old_value is good (whereas it must be refetched). In fact our function atomic_add_unsafe really fails to be atomic in certain condition. Now are you convinced why you absolutely need to instruct if 'sc' succeeds or not ? and why despite this info looks like redundant (duplicated) it is necessary ? Now I can state : 'sc' is not a simple conditional store. In fact, 'sc' cannot only be replaced with a conditionnal store. > Your idea is a bit different because it includes "persistent" data. > it has drawbacks and advantages. the drawback comes from the fact > that the decision history is made "static" or "persistent". What is persistent ? the lock bit in LSU is reset (so it is in fact very volatile) when executing 'sc' so you need to save it somewhere (i.e, in a register) before resetting it, so we can know which action to take after a 'sc'. > One problem is that the condition in your code is at the place > of R2, and a specific SC is not desired if we add the generic > "conditional store" instruction. I know but as I told you, 'sc' cannot be replaced with a simple conditionnal store. > The real big problem is that in this instruction, the condition > and the pointer are the same register => should not need to be > duplicated... Which instruction ? Sorry to say, you cannot escape this apparent duplication, if you really want a ll/sc mechanism. > There is something i miss, but i don't know what... I think so. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jul 26 19:52:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YEEu-0002wm-01 for ; Sat, 27 Jul 2002 01:11:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 01:11:16 +0200 (CEST) Received: (qmail 29687 invoked by uid 0); 26 Jul 2002 22:40:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 26 Jul 2002 22:40:16 -0000 Received: by moria.seul.org (Postfix) id 88A27146954; Fri, 26 Jul 2002 18:40:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4902B146964; Fri, 26 Jul 2002 18:40:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id A0834146954 for ; Fri, 26 Jul 2002 18:40:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01796; Fri, 26 Jul 2002 19:52:58 +0200 Message-ID: <20020726195258.16646@thrai.stud.uni-hannover.de> Date: Fri, 26 Jul 2002 19:52:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D41635C.132123EC@f-cpu.org>; from Yann Guidon on Fri, Jul 26, 2002 at 04:57:32PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 26, 2002 at 04:57:32PM +0200, Yann Guidon wrote: [...] > conditional loads/stores are a corollary of the conditional moves. > > IIRC it appeared that these instructions were in fact needed, > when we were discussing about the semaphores done with LL/SC. > "Store conditional" is this thing. That's a very different kind of instruction (atomic read-write). > By the way : condition 3 is still reserved for FP, but we could > simply connect it to the LSU : LL/SC would then not need any specific > opcode. it sounds easy and logical, what do others think ? Definitely no. move/jump has NOTHING to do with ll/sc, and they should have different opcodes. [...] > *************************************************************** > HOWEVER I HAVE A BIG PROBLEM WITH THE MSB CONDITION CODE ! > i believe i told this on the list, but no solution is known yet. > > Currently, the "MSB" condition just takes the 63th bit of the > pointed register. But what about larger registers ? what about > small integers ? Proposed fixes: a) always use bit 63 b) always use the most significant bit c) drop the MSB condition thing altogether d) never build an F-CPU with registers wider than 64 bits I like c) because it makes things simpler. We can drop the unused condition, too (testing for NaNs is too complex anyway). If somebody really wants to test for any other bit than the LSB, he shall either shift/rotate it in place or mask the other bits off (bitopt/btst instruction) and use a zero/notzero condition. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jul 27 01:12:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YGtY-0004mf-01 for ; Sat, 27 Jul 2002 04:01:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 04:01:24 +0200 (CEST) Received: (qmail 12022 invoked by uid 0); 26 Jul 2002 23:12:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 26 Jul 2002 23:12:50 -0000 Received: by moria.seul.org (Postfix) id A7CFC146951; Fri, 26 Jul 2002 19:12:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C547146967; Fri, 26 Jul 2002 19:12:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 3C708146951 for ; Fri, 26 Jul 2002 19:12:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02779; Sat, 27 Jul 2002 01:12:35 +0200 Message-ID: <20020727011235.23390@thrai.stud.uni-hannover.de> Date: Sat, 27 Jul 2002 01:12:35 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] References: <00bd01c234d2$bba78650$263d0f50@hli> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <00bd01c234d2$bba78650$263d0f50@hli>; from Christophe Avoinne on Fri, Jul 26, 2002 at 08:32:00PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Jul 26, 2002 at 08:32:00PM +0200, Christophe Avoinne wrote: > BTW, what do they mean ? > > - IIRC > - IMHO > > There is another one, but i don't remember exactly ( FW... ? ). AFAIK (As Far As I Know), that means "If I Remember Correctly" and "In My Humble Opinion". SCNR (Sorry Could Not Resist), -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 07:19:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YMXW-0000B0-00 for ; Sat, 27 Jul 2002 10:03:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 10:03:02 +0200 (CEST) Received: (qmail 10386 invoked by uid 0); 27 Jul 2002 05:10:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 27 Jul 2002 05:10:39 -0000 Received: by moria.seul.org (Postfix) id 058CC14682F; Sat, 27 Jul 2002 01:10:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B5C7814696A; Sat, 27 Jul 2002 01:10:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 5D06714682F for ; Sat, 27 Jul 2002 01:10:37 -0400 (EDT) Received: from f-cpu.org (kdl16-216.n.club-internet.fr [213.44.18.216]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3CE3816A7 for ; Sat, 27 Jul 2002 07:10:35 +0200 (CEST) Message-ID: <3D422D75.2D41B18D@f-cpu.org> Date: Sat, 27 Jul 2002 07:19:49 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] C/VHDL code and fcpusim Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, now that EU_ROP2 is working exactly the same in C and VHDL, i'm now working on the register set. Because i reuse several parts of the code for the testbenches (particularly the viewing parts) i am forced (more or less, but that's what i did anyway) to do several modifications on the existing code : - rewrite the *_view() to clear the syntax and removing the g() and n(). One compromise would be to use the form "%s" inside the string itself, and we put the corresponding escape codes at the end of the printf. I don't know yet where to put the constant, so it is acessed both by fcpusim and the testbenches, but a subfile from f-cpu_config.h would be ok. - i moved the contents of the registers_view.c to registers.c, and adapted the .h accordingly. both fcpusim and test_registers.c need it, so a separate file is not justified. - modified/corrected the runme.sh Btw, i think that there are some race conditions in the VHDL version of the register set. i'll correct that and upload my snapshot (but not before tomorrow). ok, time to sleep, have fun and be careful, WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sat Jul 27 10:48:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YQGS-0002ju-00 for ; Sat, 27 Jul 2002 14:01:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 14:01:40 +0200 (CEST) Received: (qmail 24017 invoked by uid 0); 27 Jul 2002 08:48:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 27 Jul 2002 08:48:41 -0000 Received: by moria.seul.org (Postfix) id E628314680A; Sat, 27 Jul 2002 04:48:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D5EBE146819; Sat, 27 Jul 2002 04:48:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id 19F6214680A for ; Sat, 27 Jul 2002 04:48:39 -0400 (EDT) Message-ID: <20020727084838.6607.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 01:48:38 PDT Date: Sat, 27 Jul 2002 01:48:38 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] C/VHDL code and fcpusim To: f-cpu@seul.org In-Reply-To: <3D422D75.2D41B18D@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Yann Guidon wrote: > hi, > > now that EU_ROP2 is working exactly the same > in C and VHDL, i'm now working on the register set. > > Because i reuse several parts of the code for the > testbenches (particularly the viewing parts) > i am forced (more or less, but that's what i did > anyway) > to do several modifications on the existing code : > - rewrite the *_view() to clear the syntax and > removing the g() and n(). One compromise would be > to use the form "%s" inside the string itself, > and we put the corresponding escape codes at the > end of the printf. I don't know yet where to put > the constant, so it is acessed both by fcpusim > and > the testbenches, but a subfile from > f-cpu_config.h > would be ok. > - i moved the contents of the registers_view.c to > registers.c, and adapted the .h accordingly. > both fcpusim and test_registers.c need it, so > a separate file is not justified. > - modified/corrected the runme.sh sound ok, i'll wait with changing it till is get your snapshot. > > Btw, i think that there are some race conditions in > the VHDL version of the register set. i'll correct > that > and upload my snapshot (but not before tomorrow). i made some small changed to the scheduler and a couple other files, and now register movement is working ok. i can even do: add r1,r2,r3 nop move r4,r5 and r3 and r5 get writen to the register unit at the same time !! (as long as you don't save the carry) abot an extra 0-cycle unit for the register moves: we also could add an extra ouput to an existing unit, and use that as a 0-cycle bypass. about your last snapshot: there where some dubble/unused files. the fcpusim_view.c/.h files are not needed (its all in fcpusim.c/.h) i als removed the notes_view.c file i'll upload my snapshot as soon as i added your changes. > ok, time to sleep, have fun and be careful, > WHYGEE awake yet ? __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sat Jul 27 15:03:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YRVM-0003ej-00 for ; Sat, 27 Jul 2002 15:21:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 15:21:08 +0200 (CEST) Received: (qmail 20053 invoked by uid 0); 27 Jul 2002 13:03:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 27 Jul 2002 13:03:44 -0000 Received: by moria.seul.org (Postfix) id 44D37146817; Sat, 27 Jul 2002 09:03:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D72B146915; Sat, 27 Jul 2002 09:03:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 619E9146817 for ; Sat, 27 Jul 2002 09:03:41 -0400 (EDT) Message-ID: <20020727130340.10256.qmail@web14205.mail.yahoo.com> Received: from [195.241.186.50] by web14205.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 06:03:40 PDT Date: Sat, 27 Jul 2002 06:03:40 -0700 (PDT) From: jaap stolk Subject: [f-cpu] MUL question To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N the manual is not very clear on the latency of the MUL EU. >from the VHDL i understand it's like: size: reult(low) result(high) 8 bit 3 4 16 bit 4 5 32 bit 5 5 64 bit 6 6 my question is, (even if the actual numbers change) are we going to have seperate latencies for each output ? and what if the used write slots look like this: (i know a very big if) w0 w1 used used free free used used free free used used free free used used we would never be able to start the MUL, unles we delay one of the MUL EU outputs to pull it strait. (of corce this also hapens the other way around, when none of the write slots are aligned, and we need two aligned slots (like ADD+carry)) do we delay one of the outputs, or just wait for a free pair of slots that "fits" the units output? PS i'm not sure if this would be a real problem, or if it's only going to hapen in rare conditions. also, using a seperate latency for each write port shoeld not be to compilcated. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Jul 27 17:34:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YUPv-0005lF-00 for ; Sat, 27 Jul 2002 18:27:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 27 Jul 2002 18:27:43 +0200 (CEST) Received: (qmail 30513 invoked by uid 0); 27 Jul 2002 15:35:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Jul 2002 15:35:01 -0000 Received: by moria.seul.org (Postfix) id 8AEE3146915; Sat, 27 Jul 2002 11:34:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F992146957; Sat, 27 Jul 2002 11:34:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id AF314146915 for ; Sat, 27 Jul 2002 11:34:58 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id A0ED117F26 for ; Sat, 27 Jul 2002 17:34:57 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 8216F64118; Sat, 27 Jul 2002 17:34:57 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] register move in 1 x-bar cycle Message-ID: <1027784097.3d42bda173932@imp.free.fr> Date: Sat, 27 Jul 2002 17:34:57 +0200 (MEST) From: Cedric BAIL References: <20020726192137.79351.qmail@web14208.mail.yahoo.com> <3D41A51A.408ECBBE@f-cpu.org> In-Reply-To: <3D41A51A.408ECBBE@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.252.194.232 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > can we change it into two x-bar cycles ? > you're right, the manual is not up to date. I noticed > btw : could we add a modification date to each instruction > in the manual ? This would help people understand > what document to trust if there is such another problem. good idea, I will start to do this. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 18:33:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEY-0002H8-00 for ; Sun, 28 Jul 2002 01:44:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:26 +0200 (CEST) Received: (qmail 20725 invoked by uid 0); 27 Jul 2002 16:23:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 27 Jul 2002 16:23:54 -0000 Received: by moria.seul.org (Postfix) id 8A34A146952; Sat, 27 Jul 2002 12:23:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A82814695D; Sat, 27 Jul 2002 12:23:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C5C74146952 for ; Sat, 27 Jul 2002 12:23:51 -0400 (EDT) Received: from f-cpu.org (kdl16-151.n.club-internet.fr [213.44.18.151]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 705A817E4 for ; Sat, 27 Jul 2002 18:23:49 +0200 (CEST) Message-ID: <3D42CB40.4858FEBD@f-cpu.org> Date: Sat, 27 Jul 2002 18:33:04 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL code and fcpusim References: <20020727084838.6607.qmail@web14203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > --- Yann Guidon wrote: > sound ok, i'll wait with changing it till is get > your snapshot. could you please rename ygasm (or at least parts you changed) to jwsasm ? and post it, so i can integrgate it as well. no need to keep the .bin files in the snapshots. > > ok, time to sleep, have fun and be careful, > > WHYGEE > awake yet ? i just woke up :-) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 19:12:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEc-0002H8-00 for ; Sun, 28 Jul 2002 01:44:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:30 +0200 (CEST) Received: (qmail 24339 invoked by uid 0); 27 Jul 2002 17:03:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 27 Jul 2002 17:03:38 -0000 Received: by moria.seul.org (Postfix) id 4F86F146957; Sat, 27 Jul 2002 13:03:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 46E0214695E; Sat, 27 Jul 2002 13:03:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id F0332146957 for ; Sat, 27 Jul 2002 13:03:35 -0400 (EDT) Received: from f-cpu.org (kdl14-49.n.club-internet.fr [213.44.12.49]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E1F3017E7 for ; Sat, 27 Jul 2002 19:03:32 +0200 (CEST) Message-ID: <3D42D48F.2CF71EAB@f-cpu.org> Date: Sat, 27 Jul 2002 19:12:47 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL code and fcpusim References: <20020727084838.6607.qmail@web14203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, jaap stolk wrote: > hi, > --- Yann Guidon wrote: > > hi, > sound ok, i'll wait with changing it till is get > your snapshot. i'll try to be fast, so you can continue to work. i have only touched eu_rop2 and registers, could you start integrating the *_view.c to the *.c ? i also just created a couple of constants : char display_color[] and char display_normal[] which can replace your g() and n() functions. it is very easy to use : printf ("something : %s%16llX%s\n", display_color, some_data, display_normal); > i made some small changed to the scheduler and a > couple other files, and now register movement is > working ok. i can even do: > add r1,r2,r3 > nop > move r4,r5 > and r3 and r5 get writen to the register unit at the > same time !! (as long as you don't save the carry) i did not believe one could do this so fast :-) > abot an extra 0-cycle unit for the register moves: > we also could add an extra ouput to an existing > unit, and use that as a 0-cycle bypass. ? > about your last snapshot: > there where some dubble/unused files. > the fcpusim_view.c/.h files are not needed > (its all in fcpusim.c/.h) > i als removed the notes_view.c file rm toplevel/fcpusim_view.* rm fcpusim/notes_view.c is that ok ? > i'll upload my snapshot as soon as i added your > changes. i'll make something quick so you can work. give me an hour, and i'll upload something, i doesn't work yet. btw, did you install simili ? did you try to run the install.sh script ? does the script work ? if yes, then i'll integrate fcpusim in install.sh. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 19:56:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEf-0002H8-00 for ; Sun, 28 Jul 2002 01:44:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:33 +0200 (CEST) Received: (qmail 25426 invoked by uid 0); 27 Jul 2002 17:46:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 27 Jul 2002 17:46:50 -0000 Received: by moria.seul.org (Postfix) id C4FAD14695D; Sat, 27 Jul 2002 13:46:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FACD14695F; Sat, 27 Jul 2002 13:46:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5005614695D for ; Sat, 27 Jul 2002 13:46:48 -0400 (EDT) Received: from f-cpu.org (kdl11-62.n.club-internet.fr [213.44.9.62]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3C62D16F8 for ; Sat, 27 Jul 2002 19:46:46 +0200 (CEST) Message-ID: <3D42DEB1.216E1223@f-cpu.org> Date: Sat, 27 Jul 2002 19:56:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] changes to C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, the latest YG snapshot is not fully functional and i have probably broken a few things in fcpusim, but nothing harmful. - For safety reasons, gcc should be called at least with the flags -W and -Wall (it helped me find some flaws) - added f-cpu_display.h and sdtio.h in /configuration/f-cpu_config.h - tested eu_rop2 and registers, they should now be ok. and some other stuffs. use diff to be sure. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jul 27 15:26:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEf-0002H8-01 for ; Sun, 28 Jul 2002 01:44:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:33 +0200 (CEST) Received: (qmail 16694 invoked by uid 0); 27 Jul 2002 17:56:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 27 Jul 2002 17:56:33 -0000 Received: by moria.seul.org (Postfix) id 62E2E14695E; Sat, 27 Jul 2002 13:56:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 33501146960; Sat, 27 Jul 2002 13:56:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a050.home.uni-hannover.de [130.75.232.50]) by moria.seul.org (Postfix) with ESMTP id B5F3A14695E for ; Sat, 27 Jul 2002 13:56:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00474; Sat, 27 Jul 2002 15:26:24 +0200 Message-ID: <20020727152624.37319@thrai.stud.uni-hannover.de> Date: Sat, 27 Jul 2002 15:26:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] MUL question References: <20020727130340.10256.qmail@web14205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020727130340.10256.qmail@web14205.mail.yahoo.com>; from jaap stolk on Sat, Jul 27, 2002 at 06:03:40AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Jul 27, 2002 at 06:03:40AM -0700, jaap stolk wrote: > > the manual is not very clear on the latency of > the MUL EU. > from the VHDL i understand it's like: > > size: reult(low) result(high) > 8 bit 3 4 > 16 bit 4 5 > 32 bit 5 5 > 64 bit 6 6 Correct. > my question is, (even if the actual numbers change) > are we going to have seperate latencies for each > output ? In most units, no. In this unit, yes. > and what if the used write slots look like this: > (i know a very big if) > w0 w1 > used used > free free > used used > free free > used used > free free > used used > > we would never be able to start the MUL, unles we > delay one of the MUL EU outputs to pull it strait. > (of corce this also hapens the other way around, > when none of the write slots are aligned, and we > need two aligned slots (like ADD+carry)) I guess that's an Xbar question. > do we delay one of the outputs, or just wait for > a free pair of slots that "fits" the units output? Delaying one output seems to be the better solution. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sat Jul 27 19:59:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEg-0002H8-00 for ; Sun, 28 Jul 2002 01:44:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:34 +0200 (CEST) Received: (qmail 25803 invoked by uid 0); 27 Jul 2002 17:59:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 27 Jul 2002 17:59:48 -0000 Received: by moria.seul.org (Postfix) id BB77314695F; Sat, 27 Jul 2002 13:59:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E84B146961; Sat, 27 Jul 2002 13:59:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 01C8314695F for ; Sat, 27 Jul 2002 13:59:47 -0400 (EDT) Message-ID: <20020727175946.48401.qmail@web14205.mail.yahoo.com> Received: from [130.89.243.164] by web14205.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 10:59:46 PDT Date: Sat, 27 Jul 2002 10:59:46 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] C/VHDL code and fcpusim To: f-cpu@seul.org In-Reply-To: <3D42D48F.2CF71EAB@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, YGASM/JWSASM: there is not a lot of difference, i only made one change: i used ygasm from stable_yg_12_31_2001.tgz and added the line: current_instruction = 0; after: /* reset for the next round : */ in: /ygasm/ygasm_bin.c > > about an extra 0-cycle unit for the register moves: > > we also could add an extra ouput to an existing > > unit, and use that as a 0-cycle bypass. > ? i added a EU_MOV read / write port to the xbar, that dous the read-bus -> write-bus bypass. (see: /include/***_ports.h) but useing the read port of an other unit could work also. all bypasses before and after a register move work ok now. :-) > > i'll upload my snapshot as soon as i added your > > changes. > i'll make something quick so you can work. we are getting into a bit of a snapsot-war.... :-) i'll try and display_color[] display_normal[] to the other units. > btw, did you install simili ? yes, and read some of the documentation, but i haven't run it yet. i spend all morning getting my modem to work, and then found that my kernel has no PPP support :-( what's your opinion about two latency outputs from the decoder (one for each write port) ? jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sat Jul 27 21:15:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEh-0002H8-01 for ; Sun, 28 Jul 2002 01:44:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:35 +0200 (CEST) Received: (qmail 27381 invoked by uid 0); 27 Jul 2002 19:15:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Jul 2002 19:15:13 -0000 Received: by moria.seul.org (Postfix) id 9019114691D; Sat, 27 Jul 2002 15:15:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7618F146960; Sat, 27 Jul 2002 15:15:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id B2FEE14691D for ; Sat, 27 Jul 2002 15:15:11 -0400 (EDT) Message-ID: <20020727191511.64615.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 12:15:11 PDT Date: Sat, 27 Jul 2002 12:15:11 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] changes to C To: f-cpu@seul.org In-Reply-To: <3D42DEB1.216E1223@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i uploaded a new (jws) snapshot, witch includes whygee's latest /c/registers/ and /c/rop2/ i changed eu_rop2.c/.h a bit. (renamed function, added (and used!) two extra tmp_'s, and added some things to the view function. hope you don't mind :-) ( also note the updated ports.h in /include/ ) at least fcpusim now compiles, try to run the move_test.bin, it fils a few registers using all kinds of bypassing, etc. jaap. --- Yann Guidon wrote: > hi, > > the latest YG snapshot is not fully functional and > i have probably broken a few things in fcpusim, > but nothing harmful. > > - For safety reasons, gcc should be called at least > with the flags -W and -Wall (it helped me find > some > flaws) > > - added f-cpu_display.h and sdtio.h in > /configuration/f-cpu_config.h > > - tested eu_rop2 and registers, they should now be > ok. > > and some other stuffs. use diff to be sure. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 23:03:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEn-0002H8-00 for ; Sun, 28 Jul 2002 01:44:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:41 +0200 (CEST) Received: (qmail 20726 invoked by uid 0); 27 Jul 2002 20:54:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 27 Jul 2002 20:54:22 -0000 Received: by moria.seul.org (Postfix) id E35DC14681F; Sat, 27 Jul 2002 16:54:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF2BF146961; Sat, 27 Jul 2002 16:54:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 019A514681F for ; Sat, 27 Jul 2002 16:54:19 -0400 (EDT) Received: from f-cpu.org (kro1-28.n.club-internet.fr [213.44.93.28]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 296CC16C8 for ; Sat, 27 Jul 2002 22:54:17 +0200 (CEST) Message-ID: <3D430AA3.C6EF90D2@f-cpu.org> Date: Sat, 27 Jul 2002 23:03:31 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] changes to C References: <20020727191511.64615.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > hi, > > i uploaded a new (jws) snapshot, witch includes > whygee's latest /c/registers/ and /c/rop2/ > i changed eu_rop2.c/.h a bit. (renamed function, > added (and used!) two extra tmp_'s, and added some > things to the view function. > hope you don't mind :-) i'm downloading the file, i'll check. we'll make as many versions as necessary anyway :-) > ( also note the updated ports.h in /include/ ) > > at least fcpusim now compiles, try to run the > move_test.bin, it fils a few registers using all > kinds of bypassing, etc. cool. Will you include your version of the assembler ? > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 23:34:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEo-0002H8-00 for ; Sun, 28 Jul 2002 01:44:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:42 +0200 (CEST) Received: (qmail 16067 invoked by uid 0); 27 Jul 2002 21:25:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 27 Jul 2002 21:25:01 -0000 Received: by moria.seul.org (Postfix) id 8ED81146921; Sat, 27 Jul 2002 17:24:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 87A10146963; Sat, 27 Jul 2002 17:24:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 160FE146921 for ; Sat, 27 Jul 2002 17:24:59 -0400 (EDT) Received: from f-cpu.org (kdl14-24.n.club-internet.fr [213.44.12.24]) by relay-5v.club-internet.fr (Postfix) with ESMTP id D480E16E9 for ; Sat, 27 Jul 2002 23:24:55 +0200 (CEST) Message-ID: <3D4311D2.398F5D68@f-cpu.org> Date: Sat, 27 Jul 2002 23:34:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL code and fcpusim References: <20020727175946.48401.qmail@web14205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > > hi, > > YGASM/JWSASM: > there is not a lot of difference, i only made one > change: > > i used ygasm from stable_yg_12_31_2001.tgz > and added the line: > current_instruction = 0; > after: > /* reset for the next round : */ > in: /ygasm/ygasm_bin.c well, i could reuse this version but i had worked on it after december, until i found that i wanted a sophisticated memory allocation library (i don't trust glibc...) My goal is to allow forward label declaration, which would make FROMFS possible, as well as many other things. The problem is that i don't want to promote memory leaks (for example, when a very large application is compiled, the assembler could kill the computer if the allocation is not correctly done). Maybe i should concentrate on this now ? This would give you enough visibility on your code so you can advance it without waiting for my updates. > > > about an extra 0-cycle unit for the register moves: > > > we also could add an extra ouput to an existing > > > unit, and use that as a 0-cycle bypass. > > ? > i added a EU_MOV read / write port to the xbar, that > dous the read-bus -> write-bus bypass. > (see: /include/***_ports.h) ok > but useing the read port of an other unit could work > also. here, i don't understand. > all bypasses before and after a register move work > ok now. :-) did you solve the problem of the 2nd bypass ? that is : after the first obvious bypass, there is another bypass condition due to the write latency of the register set. The register set must be bypassed so that the old value is not read. Usually, there is a "latch" before the register set write ports : these 2 values (2 write ports) can be reused/reinjected on the Xbar. > > > i'll upload my snapshot as soon as i added your > > > changes. > > i'll make something quick so you can work. > we are getting into a bit of a snapsot-war.... :-) it's not a war, and quite the contrary :-) i'm happy that things move and give tangible results. Like many people, i'm fed up of the useless endless "discussions" on this list and your code is a bliss. > i'll try and display_color[] display_normal[] to the > other units. isn't it handy ? :-) > > btw, did you install simili ? > yes, and read some of the documentation, but i haven't > run it yet. i spend all morning getting my modem to > work, and then found that my kernel has no PPP > support :-( been there, done that, and still doesn't work because cardmgr doesn't recognize my PCMCIA modem ... > what's your opinion about two latency outputs from > the decoder (one for each write port) ? i still don't understand what it means. is it related to the IMUL thing ? If yes, then i think it's necessary. > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jul 27 23:34:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEp-0002H8-00 for ; Sun, 28 Jul 2002 01:44:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:43 +0200 (CEST) Received: (qmail 8992 invoked by uid 0); 27 Jul 2002 21:25:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 27 Jul 2002 21:25:03 -0000 Received: by moria.seul.org (Postfix) id 97619146963; Sat, 27 Jul 2002 17:25:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B0FB14696A; Sat, 27 Jul 2002 17:25:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 9C1B9146963 for ; Sat, 27 Jul 2002 17:25:00 -0400 (EDT) Received: from f-cpu.org (kdl14-24.n.club-internet.fr [213.44.12.24]) by relay-2v.club-internet.fr (Postfix) with ESMTP id F045816EC for ; Sat, 27 Jul 2002 23:24:57 +0200 (CEST) Message-ID: <3D4311D3.3621165E@f-cpu.org> Date: Sat, 27 Jul 2002 23:34:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] MUL question References: <20020727130340.10256.qmail@web14205.mail.yahoo.com> <20020727152624.37319@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: > On Sat, Jul 27, 2002 at 06:03:40AM -0700, jaap stolk wrote: > > > > the manual is not very clear on the latency of the MUL EU. > > from the VHDL i understand it's like: > > > > size: reult(low) result(high) > > 8 bit 3 4 > > 16 bit 4 5 > > 32 bit 5 5 > > 64 bit 6 6 > Correct. ??? i thought that it was 2-4-6-8 ? so i have to modify the f-cpu/CAPABILITIES file. > > my question is, (even if the actual numbers change) > > are we going to have seperate latencies for each > > output ? > In most units, no. In this unit, yes. multiplies are often a critical operation when it is used. > > and what if the used write slots look like this: > > (i know a very big if) > > w0 w1 > > used used > > free free > > used used > > free free > > used used > > free free > > used used > > > > we would never be able to start the MUL, unles we > > delay one of the MUL EU outputs to pull it strait. > > (of corce this also hapens the other way around, > > when none of the write slots are aligned, and we > > need two aligned slots (like ADD+carry)) > > I guess that's an Xbar question. > > > do we delay one of the outputs, or just wait for > > a free pair of slots that "fits" the units output? > Delaying one output seems to be the better solution. i don't think it's necessary, however. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 00:09:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YbEq-0002H8-00 for ; Sun, 28 Jul 2002 01:44:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 01:44:44 +0200 (CEST) Received: (qmail 29581 invoked by uid 0); 27 Jul 2002 22:09:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 27 Jul 2002 22:09:04 -0000 Received: by moria.seul.org (Postfix) id B893E146962; Sat, 27 Jul 2002 18:09:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C6D0146982; Sat, 27 Jul 2002 18:09:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14207.mail.yahoo.com (web14207.mail.yahoo.com [216.136.173.71]) by moria.seul.org (Postfix) with SMTP id BF0CF146962 for ; Sat, 27 Jul 2002 18:09:01 -0400 (EDT) Message-ID: <20020727220901.37596.qmail@web14207.mail.yahoo.com> Received: from [130.89.243.164] by web14207.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 15:09:01 PDT Date: Sat, 27 Jul 2002 15:09:01 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] C/VHDL code and fcpusim To: f-cpu@seul.org In-Reply-To: <3D4311D2.398F5D68@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Yann Guidon wrote: - snip - > the assembler could kill the computer if the > allocation is > not correctly done). > > Maybe i should concentrate on this now ? > This would give you enough visibility on your code i have no experience with flex or bison, so i don't dare changing a lot. i'm not sure about the memory problems, but the 3r1w and rop2 code should not be to hard (?) > > but useing the read port of an other unit could > > work also. > here, i don't understand. turn this: mov read port -> --stage ff-- --> move write port asu read port -> --stage ff-- asu stage 1 --stage ff-- --> 1 cycle write port asu stage 1 --stage ff-- --> 2 cycle write port into: asu read port -> --stage ff-- --> 0 cycle write port asu stage 1 --stage ff-- --> 1 cycle write port asu stage 1 --stage ff-- --> 2 cycle write port it will save you a read port on the x-bar, and the first stage if the ASU can't be used if we are doing a move. > > all bypasses before and after a register move work > > ok now. :-) > did you solve the problem of the 2nd bypass ? daaaay's ago :-) the trick is extrending the register write nr queue with one extra level. (that extra level is needed for the register write anyway) > > work, and then found that my kernel has no PPP > > support :-( > been there, done that, and still doesn't work > because > cardmgr doesn't recognize my PCMCIA modem ... now i have to find out how to compile a module and add it to the kernell. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 28 02:19:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YeQy-0004a4-00 for ; Sun, 28 Jul 2002 05:09:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 05:09:28 +0200 (CEST) Received: (qmail 32251 invoked by uid 0); 28 Jul 2002 00:22:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 28 Jul 2002 00:22:11 -0000 Received: by moria.seul.org (Postfix) id 1191F1467FD; Sat, 27 Jul 2002 20:22:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C0672146982; Sat, 27 Jul 2002 20:22:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 104C41467FD for ; Sat, 27 Jul 2002 20:22:08 -0400 (EDT) Received: from hli (80.15.61.249) by smtp.laposte.net (6.0.053) id 3D32A1F9000DBE11 for f-cpu@seul.org; Sun, 28 Jul 2002 02:22:05 +0200 Message-ID: <000b01c235cc$7e6b0aa0$f93d0f50@hli> From: "Christophe Avoinne" To: References: <20020727220901.37596.qmail@web14207.mail.yahoo.com> Subject: Re: [f-cpu] C/VHDL code and fcpusim Date: Sun, 28 Jul 2002 02:19:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "jaap stolk" To: Sent: Sunday, July 28, 2002 12:09 AM Subject: Re: [f-cpu] C/VHDL code and fcpusim > > --- Yann Guidon wrote: > - snip - > > the assembler could kill the computer if the > > allocation is > > not correctly done). > > > > Maybe i should concentrate on this now ? > > This would give you enough visibility on your code > i have no experience with flex or bison, so i don't > dare changing a lot. i'm not sure about the memory > problems, but the 3r1w and rop2 code should not be to > hard (?) I could be helpful regarding with flex or bison. What the trouble with the memory allocation ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 04:15:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YeR0-0004a4-00 for ; Sun, 28 Jul 2002 05:09:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 28 Jul 2002 05:09:30 +0200 (CEST) Received: (qmail 19877 invoked by uid 0); 28 Jul 2002 02:06:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 28 Jul 2002 02:06:45 -0000 Received: by moria.seul.org (Postfix) id 706F614696C; Sat, 27 Jul 2002 22:06:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3250E14699E; Sat, 27 Jul 2002 22:06:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 947CB14696C for ; Sat, 27 Jul 2002 22:06:42 -0400 (EDT) Received: from f-cpu.org (kdl11-63.n.club-internet.fr [213.44.9.63]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 49B2A16AF for ; Sun, 28 Jul 2002 04:06:40 +0200 (CEST) Message-ID: <3D4353DA.73385B12@f-cpu.org> Date: Sun, 28 Jul 2002 04:15:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] C/VHDL code and fcpusim References: <20020727220901.37596.qmail@web14207.mail.yahoo.com> <000b01c235cc$7e6b0aa0$f93d0f50@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > > I could be helpful regarding with flex or bison. What the trouble with the > memory allocation ? it's not a problem with Bison and Flex (they are solved for a long time now). the problem is that there is a quantity of different kinds of data with different properties, some are allocated once and remain until the end of the program (ie : the binary code), some structures are more complex (a file descriptor stack for the includes, a #define list of symbols etc) and some are even worse. so i have to find the best algorithm and structure for each case. The goal is to avoid memory leaks and unused regions, so the computer doesn't run out of memory when compiling something like X11 or Mozilla... (just in case it's used to do that). WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 14:01:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGJ-0008S0-01 for ; Mon, 29 Jul 2002 01:15:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:43 +0200 (CEST) Received: (qmail 24614 invoked by uid 0); 28 Jul 2002 12:01:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 28 Jul 2002 12:01:10 -0000 Received: by moria.seul.org (Postfix) id B73BD1467F5; Sun, 28 Jul 2002 08:01:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 675F3146807; Sun, 28 Jul 2002 08:01:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14201.mail.yahoo.com (web14201.mail.yahoo.com [216.136.172.143]) by moria.seul.org (Postfix) with SMTP id F0C931467F5 for ; Sun, 28 Jul 2002 08:01:05 -0400 (EDT) Message-ID: <20020728120105.56247.qmail@web14201.mail.yahoo.com> Received: from [130.89.243.164] by web14201.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 05:01:05 PDT Date: Sun, 28 Jul 2002 05:01:05 -0700 (PDT) From: jaap stolk Subject: Re: RE : [f-cpu] Snapshot_jws update To: f-cpu@seul.org In-Reply-To: <000301c23034$9cd25d60$b8730950@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- GerTom wrote: > Just add getkey.c file in /toplevel > And the updated fcpusim_view.c > > Test and give feedback! it works great!, however when i compile with "-w -wall" i get this warning: getkey.c: In function 'kbhit': getkey.c:105: implicit declaration of function 'memcpy' dous anybody know wat this means and how to stop it ? jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 28 14:01:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGK-0008S0-00 for ; Mon, 29 Jul 2002 01:15:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:44 +0200 (CEST) Received: (qmail 7175 invoked by uid 0); 28 Jul 2002 12:03:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Jul 2002 12:03:28 -0000 Received: by moria.seul.org (Postfix) id BFBB81467F8; Sun, 28 Jul 2002 08:03:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BF78146849; Sun, 28 Jul 2002 08:03:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2431C1467F8 for ; Sun, 28 Jul 2002 08:03:26 -0400 (EDT) Received: from hli (80.15.61.249) by smtp.laposte.net (6.0.053) id 3D2EB28C0010A873 for f-cpu@seul.org; Sun, 28 Jul 2002 14:03:25 +0200 Message-ID: <003501c2362e$76ad9c80$f93d0f50@hli> From: "Christophe Avoinne" To: References: <20020728120105.56247.qmail@web14201.mail.yahoo.com> Subject: Re: RE : [f-cpu] Snapshot_jws update Date: Sun, 28 Jul 2002 14:01:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just add #include or #include ----- Original Message ----- From: "jaap stolk" To: Sent: Sunday, July 28, 2002 2:01 PM Subject: Re: RE : [f-cpu] Snapshot_jws update > hi, > > --- GerTom wrote: > > Just add getkey.c file in /toplevel > > And the updated fcpusim_view.c > > > > Test and give feedback! > > it works great!, however > when i compile with "-w -wall" i get this warning: > > getkey.c: In function 'kbhit': > getkey.c:105: implicit declaration of function > 'memcpy' > > dous anybody know wat this means and > how to stop it ? > > jaap. > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 28 14:01:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGL-0008S0-00 for ; Mon, 29 Jul 2002 01:15:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:45 +0200 (CEST) Received: (qmail 9894 invoked by uid 0); 28 Jul 2002 12:04:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Jul 2002 12:04:09 -0000 Received: by moria.seul.org (Postfix) id 76DC0146807; Sun, 28 Jul 2002 08:04:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 67474146917; Sun, 28 Jul 2002 08:04:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id EB91B146807 for ; Sun, 28 Jul 2002 08:04:07 -0400 (EDT) Received: from hli (80.15.61.249) by smtp.laposte.net (6.0.053) id 3D2EB6090012424A for f-cpu@seul.org; Sun, 28 Jul 2002 14:04:06 +0200 Message-ID: <003a01c2362e$8f74b0a0$f93d0f50@hli> From: "Christophe Avoinne" To: References: <20020728120105.56247.qmail@web14201.mail.yahoo.com> Subject: Re: RE : [f-cpu] Snapshot_jws update Date: Sun, 28 Jul 2002 14:01:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N or : extern void *memcpy (const void *,void *); ----- Original Message ----- From: "jaap stolk" To: Sent: Sunday, July 28, 2002 2:01 PM Subject: Re: RE : [f-cpu] Snapshot_jws update > hi, > > --- GerTom wrote: > > Just add getkey.c file in /toplevel > > And the updated fcpusim_view.c > > > > Test and give feedback! > > it works great!, however > when i compile with "-w -wall" i get this warning: > > getkey.c: In function 'kbhit': > getkey.c:105: implicit declaration of function > 'memcpy' > > dous anybody know wat this means and > how to stop it ? > > jaap. > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Jul 28 14:09:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGL-0008S0-01 for ; Mon, 29 Jul 2002 01:15:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:45 +0200 (CEST) Received: (qmail 29715 invoked by uid 0); 28 Jul 2002 12:11:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 28 Jul 2002 12:11:29 -0000 Received: by moria.seul.org (Postfix) id 85210146849; Sun, 28 Jul 2002 08:11:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 582CE146918; Sun, 28 Jul 2002 08:11:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id E9521146849 for ; Sun, 28 Jul 2002 08:11:26 -0400 (EDT) Received: from hli (80.15.61.249) by smtp.laposte.net (6.0.053) id 3D359CE9000B61ED for f-cpu@seul.org; Sun, 28 Jul 2002 14:11:26 +0200 Message-ID: <004801c2362f$95469970$f93d0f50@hli> From: "Christophe Avoinne" To: References: <20020728120105.56247.qmail@web14201.mail.yahoo.com> Subject: Re: RE : [f-cpu] Snapshot_jws update Date: Sun, 28 Jul 2002 14:09:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N it means the prototype of memcpy is not defined anywhere, so it warns you about because it can be sure about what the function must return and what its argument types are really. So you'd better to EXPLICIT its prototype, just by including the file where it is defined or define it by yourself : extern void *memcpy (const void *,void *); can be : void *memcpy (const void *,void *); void memcpy (const void *,void *); int memcpy (const void *,void *); void memcpy (void *,void *); the only important thing is the two arguments must be pointers of any type (void *). ----- Original Message ----- From: "jaap stolk" To: Sent: Sunday, July 28, 2002 2:01 PM Subject: Re: RE : [f-cpu] Snapshot_jws update > hi, > > --- GerTom wrote: > > Just add getkey.c file in /toplevel > > And the updated fcpusim_view.c > > > > Test and give feedback! > > it works great!, however > when i compile with "-w -wall" i get this warning: > > getkey.c: In function 'kbhit': > getkey.c:105: implicit declaration of function > 'memcpy' > > dous anybody know wat this means and > how to stop it ? > > jaap. > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 15:32:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGL-0008S0-02 for ; Mon, 29 Jul 2002 01:15:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:45 +0200 (CEST) Received: (qmail 4239 invoked by uid 0); 28 Jul 2002 13:32:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 28 Jul 2002 13:32:07 -0000 Received: by moria.seul.org (Postfix) id 326DB146917; Sun, 28 Jul 2002 09:32:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 28895146927; Sun, 28 Jul 2002 09:32:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14201.mail.yahoo.com (web14201.mail.yahoo.com [216.136.172.143]) by moria.seul.org (Postfix) with SMTP id B68F3146917 for ; Sun, 28 Jul 2002 09:32:05 -0400 (EDT) Message-ID: <20020728133205.66090.qmail@web14201.mail.yahoo.com> Received: from [130.89.243.164] by web14201.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 06:32:05 PDT Date: Sun, 28 Jul 2002 06:32:05 -0700 (PDT) From: jaap stolk Subject: Re: RE : [f-cpu] Snapshot_jws update To: f-cpu@seul.org In-Reply-To: <004801c2362f$95469970$f93d0f50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Christophe Avoinne wrote: > From: "jaap stolk" > > getkey.c: In function 'kbhit': > > getkey.c:105: implicit declaration of function > > 'memcpy' > > thanks, all warnings in fcpusim are gone. :-) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 15:40:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGM-0008S0-00 for ; Mon, 29 Jul 2002 01:15:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:46 +0200 (CEST) Received: (qmail 19945 invoked by uid 0); 28 Jul 2002 13:40:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 28 Jul 2002 13:40:06 -0000 Received: by moria.seul.org (Postfix) id 96BC3146918; Sun, 28 Jul 2002 09:40:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7EFAC146928; Sun, 28 Jul 2002 09:40:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id 0D2FE146918 for ; Sun, 28 Jul 2002 09:40:05 -0400 (EDT) Message-ID: <20020728134004.94277.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 06:40:04 PDT Date: Sun, 28 Jul 2002 06:40:04 -0700 (PDT) From: jaap stolk Subject: [f-cpu] condition flag location To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N as sayd last nignt, i would look it up: JMP: condition = bits 19-21 JMP: condition = bits 10-12 i think i found why, the bit numbering is different. what's the story on bit numbering? is bit 0 still the LSBit ? reverse all bits in the opcode ? ?? jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 15:57:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGN-0008S0-00 for ; Mon, 29 Jul 2002 01:15:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:47 +0200 (CEST) Received: (qmail 6211 invoked by uid 0); 28 Jul 2002 13:57:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 28 Jul 2002 13:57:42 -0000 Received: by moria.seul.org (Postfix) id D6A46146820; Sun, 28 Jul 2002 09:57:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B4BCE146928; Sun, 28 Jul 2002 09:57:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14207.mail.yahoo.com (web14207.mail.yahoo.com [216.136.173.71]) by moria.seul.org (Postfix) with SMTP id 05FC4146820 for ; Sun, 28 Jul 2002 09:57:41 -0400 (EDT) Message-ID: <20020728135740.35974.qmail@web14207.mail.yahoo.com> Received: from [130.89.243.164] by web14207.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 06:57:40 PDT Date: Sun, 28 Jul 2002 06:57:40 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] condition flag location To: f-cpu@seul.org In-Reply-To: <20020728134004.94277.qmail@web14203.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- jaap stolk wrote: > > as sayd last nignt, i would look it up: > > JMP: > condition = bits 19-21 > JMP: --> correction: MOVE > condition = bits 10-12 > > i think i found why, the bit numbering is > different. > what's the story on bit numbering? the Revision history in the manual: 07/20/2002 : Reverse all the bits. is JMP the old or new numbering? > is bit 0 still the LSBit ? > reverse all bits in the opcode ? > ?? > > jaap. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 16:58:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGO-0008S0-00 for ; Mon, 29 Jul 2002 01:15:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:48 +0200 (CEST) Received: (qmail 19277 invoked by uid 0); 28 Jul 2002 14:49:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 28 Jul 2002 14:49:22 -0000 Received: by moria.seul.org (Postfix) id E330C146927; Sun, 28 Jul 2002 10:49:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA13514692A; Sun, 28 Jul 2002 10:49:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 51541146927 for ; Sun, 28 Jul 2002 10:49:20 -0400 (EDT) Received: from f-cpu.org (kdl11-64.n.club-internet.fr [213.44.9.64]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7816816AA for ; Sun, 28 Jul 2002 16:48:19 +0200 (CEST) Message-ID: <3D44069A.F3D2DB40@f-cpu.org> Date: Sun, 28 Jul 2002 16:58:34 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] condition flag location References: <20020728135740.35974.qmail@web14207.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! for more informations, read the files f-cpu/INSTRUCTIONS.txt and f-cpu/FORMAT.txt which contain the correct bit numbers. If you have found a place where the manual is not correctly updated, please warn Cédric (but i think he's in vacations for the week-end now) Concerning the assembler : i wonder if that was a good idea to get back at it now. in fact it opens a whole new (old) can of stincky worms and we haven't even solved many problems yet. My priority now is to finish all the EUs, both in C and VHDL, so they work in SIMD and pass the same tests whatever the langage. >From there, we will be able to rewrite the opcode map and solve scheduling problems. Currently, only ROP2 is almost ready (i have to check your changes) and the register set has problemsin the VHDL version. Given these simple and critical issues, i don't have the courage to do something even more complicated now. jaap stolk wrote: > > --- jaap stolk wrote: > > > > as sayd last nignt, i would look it up: > > > > JMP: > > condition = bits 19-21 > > > > JMP: --> correction: MOVE > > > condition = bits 10-12 > > > > i think i found why, the bit numbering is > > different. > > what's the story on bit numbering? > > the Revision history in the manual: > 07/20/2002 : Reverse all the bits. > is JMP the old or new numbering? > > > is bit 0 still the LSBit ? > > reverse all bits in the opcode ? > > ?? > > > > jaap. > > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 17:03:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGO-0008S0-01 for ; Mon, 29 Jul 2002 01:15:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:48 +0200 (CEST) Received: (qmail 19568 invoked by uid 0); 28 Jul 2002 15:03:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 28 Jul 2002 15:03:09 -0000 Received: by moria.seul.org (Postfix) id EF30F146928; Sun, 28 Jul 2002 11:03:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB8B914692B; Sun, 28 Jul 2002 11:03:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id E4FE7146928 for ; Sun, 28 Jul 2002 11:03:04 -0400 (EDT) Message-ID: <20020728150304.3578.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 08:03:04 PDT Date: Sun, 28 Jul 2002 08:03:04 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] condition flag location To: f-cpu@seul.org In-Reply-To: <3D44069A.F3D2DB40@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Yann Guidon wrote: > hi ! > for more informations, read the files > f-cpu/INSTRUCTIONS.txt and > f-cpu/FORMAT.txt which contain the correct bit > numbers. i will. > If you have found a place where the manual is not > correctly updated, please warn Cédric (but i think > he's > in vacations for the week-end now) i will look out for him :-) > Concerning the assembler : i wonder if that was a > good idea to get back at it now. in fact it opens a > whole new (old) can of stincky worms and we haven't > even solved many problems yet. My priority now is to > finish all the EUs, both in C and VHDL, so they work > in SIMD and pass the same tests whatever the langage. ok. if i need anything, i'll just hack one of your old YGASM's or more likely: hexedit the bin file. :-) > register set has problemsin the VHDL version. ouch ! :-( i made the depth of the scheduling queue defined at one pont, its now on 6 cycles (MUL), but can be changed to whateverr you like :) just out of interest, is there going to be a real score bord in hardware, or just a small table ? (there are never more than a couple of registers "being computed") i gess its a timging problem. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 17:39:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGP-0008S0-00 for ; Mon, 29 Jul 2002 01:15:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:49 +0200 (CEST) Received: (qmail 32554 invoked by uid 0); 28 Jul 2002 15:30:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 28 Jul 2002 15:30:02 -0000 Received: by moria.seul.org (Postfix) id 1739014692A; Sun, 28 Jul 2002 11:29:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EFEF614692D; Sun, 28 Jul 2002 11:29:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 9BF2014692A for ; Sun, 28 Jul 2002 11:29:56 -0400 (EDT) Received: from f-cpu.org (kro1-202.n.club-internet.fr [213.44.93.202]) by relay-2v.club-internet.fr (Postfix) with ESMTP id BB3E516D2 for ; Sun, 28 Jul 2002 17:29:54 +0200 (CEST) Message-ID: <3D44101E.543A9C6D@f-cpu.org> Date: Sun, 28 Jul 2002 17:39:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] changes to C References: <20020727191511.64615.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, jaap stolk wrote: > hi, > > i uploaded a new (jws) snapshot, witch includes > whygee's latest /c/registers/ and /c/rop2/ > i changed eu_rop2.c/.h a bit. (renamed function, > added (and used!) two extra tmp_'s, and added some > things to the view function. > hope you don't mind :-) Unfortunately, this changed the behaviour of the unit : until recently, the mode and the combine_size arrived _after_ the function. I had written the test vectors to take that into account. I propose to swap tmp_* and *, so it reverts to the old behaviour, but it keeps your code functional (particularly the stall part). All you have to do is change a few things in your scheduler/xbar. However, where do you declare the stall ? it was not included in the testbenches and i guess the testbench will have to declare it itself. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 17:46:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGP-0008S0-01 for ; Mon, 29 Jul 2002 01:15:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:49 +0200 (CEST) Received: (qmail 28748 invoked by uid 0); 28 Jul 2002 15:37:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 28 Jul 2002 15:37:04 -0000 Received: by moria.seul.org (Postfix) id 9E82D14692B; Sun, 28 Jul 2002 11:37:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FC44146932; Sun, 28 Jul 2002 11:37:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1B3CD14692B for ; Sun, 28 Jul 2002 11:37:02 -0400 (EDT) Received: from f-cpu.org (kdl14-16.n.club-internet.fr [213.44.12.16]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 84ECF1692 for ; Sun, 28 Jul 2002 17:36:59 +0200 (CEST) Message-ID: <3D4411C8.24F68BE7@f-cpu.org> Date: Sun, 28 Jul 2002 17:46:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] condition flag location References: <20020728150304.3578.qmail@web14203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > hi, > > Concerning the assembler : i wonder if that was a > > good idea to get back at it now. in fact it opens a > > whole new (old) can of stincky worms and we haven't > > even solved many problems yet. My priority now is to > > finish all the EUs, both in C and VHDL, so they work > > in SIMD and pass the same tests whatever the langage. > ok. if i need anything, i'll just hack one of your > old YGASM's or more likely: hexedit the bin file. :-) that's it. As long as the other units are not ready (and worse : the register is not OK), there is no use for a complex ASM. > > register set has problemsin the VHDL version. > ouch ! :-( i had identified some timing problems. But now i have to repair the ROP2 because you addedd signals :-/ Usually, in the VHDL, these signals should have been propagated in the Xbar. > i made the depth of the scheduling queue defined > at one pont, its now on 6 cycles (MUL), but can be > changed to whateverr you like :) i #think# there was such a definition somewhere, look at the configuration files... > just out of interest, is there going to be a real > score bord in hardware, or just a small table ? > (there are never more than a couple of registers > "being computed") i gess its a timging problem. currently, and for a single-issue FC0, all we need is a bunch of comparators tied to the scheduler's queue. My original idea (long ago) was to have one bit per register, but the data (whether a register can be used) would have been duplicated. And the SQ provides much more precise information : not only whether it can be used, but also when :-) > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 18:03:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGQ-0008S0-00 for ; Mon, 29 Jul 2002 01:15:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:50 +0200 (CEST) Received: (qmail 17973 invoked by uid 0); 28 Jul 2002 15:54:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 28 Jul 2002 15:54:10 -0000 Received: by moria.seul.org (Postfix) id 17E2E14692D; Sun, 28 Jul 2002 11:54:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4245146933; Sun, 28 Jul 2002 11:54:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 81D1814692D for ; Sun, 28 Jul 2002 11:54:06 -0400 (EDT) Received: from f-cpu.org (kdl11-68.n.club-internet.fr [213.44.9.68]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 8092916AF for ; Sun, 28 Jul 2002 17:54:04 +0200 (CEST) Message-ID: <3D4415C8.EFB2EB82@f-cpu.org> Date: Sun, 28 Jul 2002 18:03:20 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Control signals on the Xbar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i have too much troubles with your modifications to the ROP2 unit, because you changed the scheduling of the units. Now the C and VHDL version do no behave the same way and that's not a good news because it worked before. Could you please move the mode and the size control bits to the Xbar ? including their pipeline in the ROP2 unit creates problems both in C and VHDL. Concerning the "stalled" signal : it is not present in the ROP2 files, because the rop2_xbar and rop2_unit stages are "included" from the Xbar which will perform the "if (!stalled)" thing. The execution units should not contain the input and output pipeline latches because it's the job of the Xbar. You just added a pipeline stage with a conditional thing inside ROP2, which makes it very different. I'm going to keep some of your modifications but i'll have to remove the tmp_* which should be in the Xbar file. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 18:12:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGR-0008S0-00 for ; Mon, 29 Jul 2002 01:15:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:51 +0200 (CEST) Received: (qmail 8097 invoked by uid 0); 28 Jul 2002 16:02:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 28 Jul 2002 16:02:48 -0000 Received: by moria.seul.org (Postfix) id 8F69E146932; Sun, 28 Jul 2002 12:02:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57B46146935; Sun, 28 Jul 2002 12:02:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id D965B146932 for ; Sun, 28 Jul 2002 12:02:46 -0400 (EDT) Received: from f-cpu.org (kdl14-93.n.club-internet.fr [213.44.12.93]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 1200016A8 for ; Sun, 28 Jul 2002 18:02:45 +0200 (CEST) Message-ID: <3D4417D1.60E60E25@f-cpu.org> Date: Sun, 28 Jul 2002 18:12:01 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Control signals on the Xbar References: <3D4415C8.EFB2EB82@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi again, yet another remark : when the pipeline is stalled (well, the decoder and the Xbar), then the old value is kept. In your ROP2 version i read something like : if ( ! stalled ) tmp_ROP2_function = ROP2_function ; else tmp_ROP2_function = 0; In fact, there should be no "else" clause because the old value must be preserved. This is important for the physical implementation because the CMOS circuits consume energy when a data is changed. If there is a 1-cycle stall, then the input of the units will go from the old value to 0, and then from 0 to the new value. This consumes 2x more power than keeping the old value, even though it's a bit more complex to implement in HW ("clock gating" or a MUX per latched bit). but it's worth it ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 18:44:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGR-0008S0-01 for ; Mon, 29 Jul 2002 01:15:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:51 +0200 (CEST) Received: (qmail 21107 invoked by uid 0); 28 Jul 2002 16:35:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 28 Jul 2002 16:35:46 -0000 Received: by moria.seul.org (Postfix) id CE8AB146933; Sun, 28 Jul 2002 12:35:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9B7614693C; Sun, 28 Jul 2002 12:35:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 73500146933 for ; Sun, 28 Jul 2002 12:35:44 -0400 (EDT) Received: from f-cpu.org (kdl14-35.n.club-internet.fr [213.44.12.35]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 52713168A for ; Sun, 28 Jul 2002 18:35:42 +0200 (CEST) Message-ID: <3D441F89.20765138@f-cpu.org> Date: Sun, 28 Jul 2002 18:44:57 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] opcodes : missing m4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i have seen that jaap has modified f-cpu/include/f-cpu_opcodes.h ==> i need the .in file ! the .h can disappear if i rerun install.sh, the newer version would be overwritten by the makefile. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 22:28:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGV-0008S0-01 for ; Mon, 29 Jul 2002 01:15:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:55 +0200 (CEST) Received: (qmail 25229 invoked by uid 0); 28 Jul 2002 20:28:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 28 Jul 2002 20:28:55 -0000 Received: by moria.seul.org (Postfix) id D8C9C146919; Sun, 28 Jul 2002 16:28:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A07C5146941; Sun, 28 Jul 2002 16:28:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id EF741146919 for ; Sun, 28 Jul 2002 16:28:53 -0400 (EDT) Message-ID: <20020728202853.27976.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 13:28:53 PDT Date: Sun, 28 Jul 2002 13:28:53 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] opcodes : missing m4 To: f-cpu@seul.org In-Reply-To: <3D441F89.20765138@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N sorry for the slow response. about the tmp_*'s: i have been thinking about this, but could not decide what would be the best. lots of flags/signals are the same for all EU's, so it would make sence to delay them in/after the decoder (or on the x-bar), and then distribute then to all the EU's. on the other hand, distributing the flags to all the EU's across long wires (from the decoder) will take some time, witch is a pity if there is a free cycle before that. also some units need that cycle to improve the fan-out of the flags ? but anyway, changing it back is fine, i'll just delay mode and combine_size in the decoder. about the stall's: stall is declared by toplevel, if you use an EU without the rest, then the test bench shoeld provide the stall signal. > when the pipeline is stalled (well, the > decoder and the Xbar), actually it's just the decoder (and the fetcher), we can't stall the xbar, because we need to keep re- loading the data in case there is a bypass. i looked into it, and yes, it is a bit confusing. in hardware it's easy to "stall" a unit just by not changing it's input. in software, i have to save it's output or re-run the unit. to save hardware-power, you need to not-change the inputs, to save software-power you need to not-re-run the units. mixing both ways doesn't seem to go very well. :-( please forget about stalls, and just use your original eu_rop2.c files. i'll sort this ASAP in the simulator. i'll let you know more soon... and i'll look at the files you send me. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 23:04:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGW-0008S0-00 for ; Mon, 29 Jul 2002 01:15:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:56 +0200 (CEST) Received: (qmail 24818 invoked by uid 0); 28 Jul 2002 20:55:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 28 Jul 2002 20:55:12 -0000 Received: by moria.seul.org (Postfix) id 8022814693E; Sun, 28 Jul 2002 16:55:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 595C0146944; Sun, 28 Jul 2002 16:55:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id F417414693E for ; Sun, 28 Jul 2002 16:55:10 -0400 (EDT) Received: from f-cpu.org (kdl16-170.n.club-internet.fr [213.44.18.170]) by relay-1v.club-internet.fr (Postfix) with ESMTP id E4F4A1697 for ; Sun, 28 Jul 2002 22:55:08 +0200 (CEST) Message-ID: <3D445C59.B85DA79E@f-cpu.org> Date: Sun, 28 Jul 2002 23:04:25 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] opcodes : missing m4 References: <20020728202853.27976.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > sorry for the slow response. no problem :-) > about the tmp_*'s: > > i have been thinking about this, but could not > decide what would be the best. lots of flags/signals > are the same for all EU's, so it would make sence to > delay them in/after the decoder (or on the x-bar), > and then distribute then to all the EU's. > on the other hand, distributing the flags to all the > EU's across long wires (from the decoder) will take > some time, witch is a pity if there is a free cycle > before that. also some units need that cycle to > improve the fan-out of the flags ? it's not a problem : the synthesizer+place+route software will do the right decision (and if not, we'll correct it). > but anyway, > changing it back is fine, i'll just delay mode and > combine_size in the decoder. not in the decoder : the decoder decodes, and Xbar transmits. > about the stall's: > stall is declared by toplevel, if you use an EU > without the rest, then the test bench shoeld provide > the stall signal. that's what i did. Fortunately there is only one signal to recreate :-) > > when the pipeline is stalled (well, the > > decoder and the Xbar), > actually it's just the decoder (and the fetcher), we > can't stall the xbar, because we need to keep re- > loading the data in case there is a bypass. hmmmmmmmgrmblgrmbl.... did i miss something ?.... > i looked into it, and yes, it is a bit confusing. sure. > in hardware it's easy to "stall" a unit just by not > changing it's input. in software, i have to save it's > output or re-run the unit. but not by clearing the input. my latest ROP2 fixes that. > to save hardware-power, you need to not-change the > inputs, to save software-power you need to > not-re-run the units. sure. But then it's a higher level ad it's independent >from the unit itself. Don't you think it would be better to split eu_rop2 to solve all these troubles ? For example, we remove the fanout/xbar stage and we let the Xbar function do the switches when the control signals are ok.... > mixing both ways doesn't seem to go very well. :-( > please forget about stalls, and just use your original > eu_rop2.c files. i'll sort this ASAP in the simulator. ok. do i remove the pipeline stage (with tmp_function) >from eu_rop2_cycle() ? i believe that there should be no mention of "stalled" in the execution units (it's the Xbar's job)... > i'll let you know more soon... ok. > and i'll look at the files you send me. ok. send me a short tarball when done. > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Jul 28 23:40:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGX-0008S0-00 for ; Mon, 29 Jul 2002 01:15:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:57 +0200 (CEST) Received: (qmail 4320 invoked by uid 0); 28 Jul 2002 21:20:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 28 Jul 2002 21:20:01 -0000 Received: by moria.seul.org (Postfix) id 34346146919; Sun, 28 Jul 2002 17:19:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 15FD3146941; Sun, 28 Jul 2002 17:19:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id B2C00146919 for ; Sun, 28 Jul 2002 17:19:58 -0400 (EDT) Received: from ifrance.com (vlt6-111.n.club-internet.fr [194.158.119.111]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 7306816B9 for ; Sun, 28 Jul 2002 23:19:55 +0200 (CEST) Message-ID: <3D4464C7.DDC347ED@ifrance.com> Date: Sun, 28 Jul 2002 23:40:23 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <20020726195258.16646@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Fri, Jul 26, 2002 at 04:57:32PM +0200, Yann Guidon wrote: > [...] > > conditional loads/stores are a corollary of the conditional moves. > > > > IIRC it appeared that these instructions were in fact needed, > > when we were discussing about the semaphores done with LL/SC. > > "Store conditional" is this thing. > > That's a very different kind of instruction (atomic read-write). > > > By the way : condition 3 is still reserved for FP, but we could > > simply connect it to the LSU : LL/SC would then not need any specific > > opcode. it sounds easy and logical, what do others think ? > > Definitely no. move/jump has NOTHING to do with ll/sc, and they should > have different opcodes. > > [...] > > *************************************************************** > > HOWEVER I HAVE A BIG PROBLEM WITH THE MSB CONDITION CODE ! > > i believe i told this on the list, but no solution is known yet. > > > > Currently, the "MSB" condition just takes the 63th bit of the > > pointed register. But what about larger registers ? what about > > small integers ? > > Proposed fixes: > > a) always use bit 63 > b) always use the most significant bit > c) drop the MSB condition thing altogether > d) never build an F-CPU with registers wider than 64 bits > Can we used the usual SIMD bits ? so we will use the 63 or the 31 or the 15 or the 7 bits. d) solution aren't possible ! ;p (i'm for thinking with 256 bits registers). I think in that case that we used the register as a scalar value (not a packed one for SIMD stuff). In the case of 256 bits registers, the scalar chunk of 64-32-16-8 bits are still there. If "int" is 64 bits long it's not a hard point to always read the 63th bits of the register. Maybe the 31th will be better (it's a true "C int" size). solution b) have no sense on a 256 bits register set. It will read the 255th bit but we work only with the 0-63 first bit on scalar operation (that's an other point but : "What a waste by only using a quarter of the register !" (why not using 2 registers set : on scalar and the other SIMD)). nicO > I like c) because it makes things simpler. We can drop the unused > condition, too (testing for NaNs is too complex anyway). If somebody > really wants to test for any other bit than the LSB, he shall either > shift/rotate it in place or mask the other bits off (bitopt/btst > instruction) and use a zero/notzero condition. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Jul 28 23:22:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGX-0008S0-01 for ; Mon, 29 Jul 2002 01:15:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:15:57 +0200 (CEST) Received: (qmail 14877 invoked by uid 0); 28 Jul 2002 21:22:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 28 Jul 2002 21:22:03 -0000 Received: by moria.seul.org (Postfix) id 4086214693E; Sun, 28 Jul 2002 17:22:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3230D146944; Sun, 28 Jul 2002 17:22:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id 3CE4E14693E for ; Sun, 28 Jul 2002 17:22:01 -0400 (EDT) Message-ID: <20020728212200.49309.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 14:22:00 PDT Date: Sun, 28 Jul 2002 14:22:00 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] opcodes : missing m4 To: f-cpu@seul.org In-Reply-To: <3D445C59.B85DA79E@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Yann Guidon wrote: > hi ! -- snip - > not in the decoder : the decoder decodes, and Xbar > transmits. ok i put it in the xbar. :-) > > can't stall the xbar, because we need to keep re- > > loading the data in case there is a bypass. > hmmmmmmmgrmblgrmbl.... did i miss something ?.... to keep it in hardware terms:( i won't say re-run the xbar..) the decoder may discover a (posible) bypass during the stall, and change the input signals of the x-bar. that will do the bypass. > Don't you think it would be better to split eu_rop2 > to solve all these troubles ? > For example, we remove the fanout/xbar stage > and we let the Xbar function do the switches when > the control signals are ok.... i think its more of a docoder (or xbar) task. doing anything in a EU before there is any data is a bit confusing. > ok. do i remove the pipeline stage (with > tmp_function) > from eu_rop2_cycle() ? i believe that there should > be no mention of "stalled" in the execution units i agree. the stalled signal is not strictly needed, in the EU. the decoder is stalled, so it will re-provide the ROP2_function. but it will save a lot of computation (or bit changes) when we stop the ROP2_function signal. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 23:59:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGb-0008S0-00 for ; Mon, 29 Jul 2002 01:16:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:16:01 +0200 (CEST) Received: (qmail 31455 invoked by uid 0); 28 Jul 2002 21:50:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 28 Jul 2002 21:50:10 -0000 Received: by moria.seul.org (Postfix) id CB92414691A; Sun, 28 Jul 2002 17:50:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF0D0146941; Sun, 28 Jul 2002 17:50:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 81FCA14691A for ; Sun, 28 Jul 2002 17:50:09 -0400 (EDT) Received: from f-cpu.org (kdl16-25.n.club-internet.fr [213.44.18.25]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 4079716A3 for ; Sun, 28 Jul 2002 23:50:07 +0200 (CEST) Message-ID: <3D446937.3B7A5E7F@f-cpu.org> Date: Sun, 28 Jul 2002 23:59:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] opcodes : missing m4 References: <20020728212200.49309.qmail@web14203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > --- Yann Guidon wrote: > > hi ! > -- snip - > > not in the decoder : the decoder decodes, and Xbar > > transmits. > ok i put it in the xbar. :-) great ! things become so simple now :-) > > > can't stall the xbar, because we need to keep re- > > > loading the data in case there is a bypass. > > hmmmmmmmgrmblgrmbl.... did i miss something ?.... > to keep it in hardware terms:( i won't say re-run the xbar..) > the decoder may discover a (posible) bypass during > the stall, and change the input signals of the x-bar. > that will do the bypass. oh god, these HW/SW collisions... now i get it. > > Don't you think it would be better to split eu_rop2 > > to solve all these troubles ? > > For example, we remove the fanout/xbar stage > > and we let the Xbar function do the switches when > > the control signals are ok.... > i think its more of a docoder (or xbar) task. remember : "the decoder decodes, and the Xbar transmits." :-) > doing anything in a EU before there is any data > is a bit confusing. sure. oh i forgot : "an EU processes data". > > ok. do i remove the pipeline stage (with tmp_function) > > from eu_rop2_cycle() ? i believe that there should > > be no mention of "stalled" in the execution units > i agree. ok so i do it. > the stalled signal is not strictly needed, in the EU. sure because an EU is a strict, straight pipeline. control signals come before and after, but not inside (ideally). > the decoder is stalled, so it will re-provide the > ROP2_function. but it will save a lot of computation > (or bit changes) when we stop the ROP2_function > signal. mmmm now you manage this in the Xbar so i can simply strip the pipeline worries out of ROP2, right ? WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 28 23:59:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGc-0008S0-00 for ; Mon, 29 Jul 2002 01:16:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:16:02 +0200 (CEST) Received: (qmail 17114 invoked by uid 0); 28 Jul 2002 21:50:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 28 Jul 2002 21:50:13 -0000 Received: by moria.seul.org (Postfix) id 39866146941; Sun, 28 Jul 2002 17:50:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 11E9E146945; Sun, 28 Jul 2002 17:50:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 99E57146941 for ; Sun, 28 Jul 2002 17:50:10 -0400 (EDT) Received: from f-cpu.org (kdl16-25.n.club-internet.fr [213.44.18.25]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 881AA16B4 for ; Sun, 28 Jul 2002 23:50:07 +0200 (CEST) Message-ID: <3D44693A.72105E82@f-cpu.org> Date: Sun, 28 Jul 2002 23:59:22 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <20020726195258.16646@thrai.stud.uni-hannover.de> <3D4464C7.DDC347ED@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nico wrote: > Michael Riepe a écrit : > > On Fri, Jul 26, 2002 at 04:57:32PM +0200, Yann Guidon wrote: > > [...] > > > *************************************************************** > > > HOWEVER I HAVE A BIG PROBLEM WITH THE MSB CONDITION CODE ! > > > i believe i told this on the list, but no solution is known yet. > > > > > > Currently, the "MSB" condition just takes the 63th bit of the > > > pointed register. But what about larger registers ? what about > > > small integers ? > > > > Proposed fixes: > > > > a) always use bit 63 > > b) always use the most significant bit > > c) drop the MSB condition thing altogether > > d) never build an F-CPU with registers wider than 64 bits > > Can we used the usual SIMD bits ? so we will use the 63 or the 31 or the > 15 or the 7 bits. we don't have enough room in the opcode for that. > d) solution aren't possible ! ;p i think it was Michael's humour :-) > (i'm for thinking with 256 bits registers). me too. > I think in that case that we used the register as a scalar > value (not a packed one for SIMD stuff). In the case of 256 bits > registers, the scalar chunk of 64-32-16-8 bits are still there. If "int" > is 64 bits long it's not a hard point to always read the 63th bits of > the register. Maybe the 31th will be better (it's a true "C int" size). RIP, C. > solution b) have no sense on a 256 bits register set. It will read the > 255th bit but we work only with the 0-63 first bit on scalar operation > (that's an other point but : "What a waste by only using a quarter of > the register !" (why not using 2 registers set : on scalar and the other > SIMD)). As i have written before (maybe differently), we don't have enough room to specify the "tested" size. We only have 3 bits : one bit inverts the result of the 2-bit condition. it's rather minimal. but if we select a specific bit inside the register, then this involves a mux and even with 4 inputs, the problem is the length of the wires (going from bit 63 to bit 8...) Another problem is that the instructions that use the 3-bit condition also use the 2-bit size field and we don't have any room left ! One "good" solution would be to find another bit => the condition would take 4 bits, including the negation. the 3 other bits would be : 0 1 2 0 0 0 ZERO 0 0 1 LSB 0 1 0 FP 0 1 1 dirty 1 0 0 MSB8 1 0 1 MSB16 1 1 0 MSB32 1 1 1 MSB64 but as i said, there is no room in the instructions that use this field :-/ we simply need *1* bit :-( is there any room to take it from the opcode ? > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 29 00:30:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGc-0008S0-01 for ; Mon, 29 Jul 2002 01:16:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:16:02 +0200 (CEST) Received: (qmail 17175 invoked by uid 0); 28 Jul 2002 22:30:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 28 Jul 2002 22:30:36 -0000 Received: by moria.seul.org (Postfix) id 15BAA14691A; Sun, 28 Jul 2002 18:30:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0217146941; Sun, 28 Jul 2002 18:30:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a240.home.uni-hannover.de [130.75.232.240]) by moria.seul.org (Postfix) with ESMTP id EB7DC14691A for ; Sun, 28 Jul 2002 18:30:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02657; Mon, 29 Jul 2002 00:30:32 +0200 Message-ID: <20020729003031.22112@thrai.stud.uni-hannover.de> Date: Mon, 29 Jul 2002 00:30:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <20020726195258.16646@thrai.stud.uni-hannover.de> <3D4464C7.DDC347ED@ifrance.com> <3D44693A.72105E82@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D44693A.72105E82@f-cpu.org>; from Yann Guidon on Sun, Jul 28, 2002 at 11:59:22PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Jul 28, 2002 at 11:59:22PM +0200, Yann Guidon wrote: [...] > > > Proposed fixes: > > > > > > a) always use bit 63 > > > b) always use the most significant bit > > > c) drop the MSB condition thing altogether > > > d) never build an F-CPU with registers wider than 64 bits > > > > Can we used the usual SIMD bits ? so we will use the 63 or the 31 or the > > 15 or the 7 bits. > we don't have enough room in the opcode for that. > > > d) solution aren't possible ! ;p > i think it was Michael's humour :-) Of course. c) was meant seriously, though. > > (i'm for thinking with 256 bits registers). > me too. > > > I think in that case that we used the register as a scalar > > value (not a packed one for SIMD stuff). In the case of 256 bits > > registers, the scalar chunk of 64-32-16-8 bits are still there. If "int" > > is 64 bits long it's not a hard point to always read the 63th bits of > > the register. Maybe the 31th will be better (it's a true "C int" size). > RIP, C. Hey, *I* like it. But of course `int has 32 bits' is not an argument. > > solution b) have no sense on a 256 bits register set. It will read the > > 255th bit but we work only with the 0-63 first bit on scalar operation > > (that's an other point but : "What a waste by only using a quarter of > > the register !" (why not using 2 registers set : on scalar and the other > > SIMD)). > > As i have written before (maybe differently), we don't have enough room > to specify the "tested" size. > > We only have 3 bits : one bit inverts the result of the 2-bit condition. > it's rather minimal. but if we select a specific bit inside the register, > then this involves a mux and even with 4 inputs, the problem is the > length of the wires (going from bit 63 to bit 8...) > > Another problem is that the instructions that use the 3-bit condition > also use the 2-bit size field and we don't have any room left ! `jump' has a free bit, and we can free one in `move' if we make sign extension a separate operation. Another option is to make `move' a full-word operation (that is, no size bits at all, like jump) and reconsider `widen' for sign and zero extension. That way, we can use 6 bits for the condition code. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Mon Jul 29 00:46:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17YxGd-0008S0-00 for ; Mon, 29 Jul 2002 01:16:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 01:16:03 +0200 (CEST) Received: (qmail 27145 invoked by uid 0); 28 Jul 2002 22:46:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 28 Jul 2002 22:46:27 -0000 Received: by moria.seul.org (Postfix) id 5DC5614691A; Sun, 28 Jul 2002 18:46:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 35D19146941; Sun, 28 Jul 2002 18:46:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 98D0914691A for ; Sun, 28 Jul 2002 18:46:25 -0400 (EDT) Message-ID: <20020728224625.54951.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.164] by web14206.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 15:46:25 PDT Date: Sun, 28 Jul 2002 15:46:25 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] opcodes : missing m4 To: f-cpu@seul.org In-Reply-To: <3D446937.3B7A5E7F@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Yann Guidon wrote: > jaap stolk wrote: > > --- Yann Guidon wrote: -- snip -- snip -- > ok. do i remove the pipeline stage (with > tmp_function) > from eu_rop2_cycle() ? i believe that there > should > be no mention of "stalled" in the execution > units > ok so i do it. i just dit the same in the ASU unit. i was working in 10+ files at once, but it looks (nearly) ok now. :-) > mmmm now you manage this in the Xbar so i can simply > strip the pipeline worries out of ROP2, right ? yes. i came across http://www.pullmoll.de/sqrt.htm today (digging for a smaler GNUmp) you feed bytes of the number x into this: ( MSByte first ) dig_c := dig_c - 1; nextd := input AND dmask; nextd := nextd SHR (dig_c*8); dmask := dmask SHR 8; digit := digit SHL 8; digit := digit + nextd; sub_c := 0; condf := digit - subst; while condf >= 0 do begin digit := condf; subst := subst + 2; sub_c := sub_c + 1; condf := digit - subst; end; outpu := outpu SHL 4; outpu := outpu + sub_c; subst := outpu SHL 5; subst := subst + 1; and it outputs 1/2 byte of sqrt(x) at a time :-) ( i estimated +/- 130 instructions to do a sqrt(32_bit)=16_bit ) jaap __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 01:22:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UD-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:41 +0200 (CEST) Received: (qmail 6019 invoked by uid 0); 28 Jul 2002 23:13:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 28 Jul 2002 23:13:22 -0000 Received: by moria.seul.org (Postfix) id 84EC714691A; Sun, 28 Jul 2002 19:13:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69BFE14691C; Sun, 28 Jul 2002 19:13:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1B22C14691A for ; Sun, 28 Jul 2002 19:13:21 -0400 (EDT) Received: from f-cpu.org (kdl11-239.n.club-internet.fr [213.44.9.239]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3154F168B for ; Mon, 29 Jul 2002 01:13:19 +0200 (CEST) Message-ID: <3D447CBC.A052E864@f-cpu.org> Date: Mon, 29 Jul 2002 01:22:36 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] Yet Another YG Snapshot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N the title says it all. i've modified some stuffs in f-cpu/include and f-cpu/configuration, and i've modified ROP2 so the VHDL and C are the same again, without any pipeline. I'll now work on the register set because Riviera caughs somewhere... I don't think that fcpusim will work, i count on jaap's feedback about this snapshot. for the hurried people : http://f-cpu.seul.org/~f-cpu/new/snapshot_yg_29_07_2002.tbz damn, these snapshots are getting huge... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Jul 29 01:31:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UD-0006Wo-01 for ; Mon, 29 Jul 2002 11:06:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:41 +0200 (CEST) Received: (qmail 2947 invoked by uid 0); 28 Jul 2002 23:34:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 28 Jul 2002 23:34:15 -0000 Received: by moria.seul.org (Postfix) id D3D8E14691A; Sun, 28 Jul 2002 19:34:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A3A014691C; Sun, 28 Jul 2002 19:34:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 293E714691A for ; Sun, 28 Jul 2002 19:34:14 -0400 (EDT) Received: from hli (80.14.37.148) by smtp.laposte.net (6.0.053) id 3D2EB3A20016C121 for f-cpu@seul.org; Mon, 29 Jul 2002 01:34:13 +0200 Message-ID: <001301c2368e$f65ea950$94250e50@hli> From: "Christophe Avoinne" To: References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <20020726195258.16646@thrai.stud.uni-hannover.de> <3D4464C7.DDC347ED@ifrance.com> <3D44693A.72105E82@f-cpu.org> <20020729003031.22112@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] Conditionnal Load and Store Date: Mon, 29 Jul 2002 01:31:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Monday, July 29, 2002 12:30 AM Subject: Re: [f-cpu] Conditionnal Load and Store > `jump' has a free bit, and we can free one in `move' if we make sign > extension a separate operation. > > Another option is to make `move' a full-word operation (that is, no > size bits at all, like jump) and reconsider `widen' for sign and zero > extension. That way, we can use 6 bits for the condition code. > If we consider that registers are always 64-bit wide (or 256-bit wide), 'move' does not need to have size-bits. I always thought that size-bits usually apply for load and store operations not for registers by themselves. Sign or zero extension should be done with 'widen', since its name is not misnamed :). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 01:48:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UE-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:42 +0200 (CEST) Received: (qmail 10557 invoked by uid 0); 28 Jul 2002 23:39:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Jul 2002 23:39:38 -0000 Received: by moria.seul.org (Postfix) id 25CC314691A; Sun, 28 Jul 2002 19:39:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0ED6114691C; Sun, 28 Jul 2002 19:39:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id C80A014691A for ; Sun, 28 Jul 2002 19:39:36 -0400 (EDT) Received: from f-cpu.org (kdl11-239.n.club-internet.fr [213.44.9.239]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 3AE311685 for ; Mon, 29 Jul 2002 01:39:34 +0200 (CEST) Message-ID: <3D4482E4.96978CFB@f-cpu.org> Date: Mon, 29 Jul 2002 01:48:52 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <3D41635C.132123EC@f-cpu.org> <20020726195258.16646@thrai.stud.uni-hannover.de> <3D4464C7.DDC347ED@ifrance.com> <3D44693A.72105E82@f-cpu.org> <20020729003031.22112@thrai.stud.uni-hannover.de> <001301c2368e$f65ea950$94250e50@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > ----- Original Message ----- > From: "Michael Riepe" > To: > Sent: Monday, July 29, 2002 12:30 AM > Subject: Re: [f-cpu] Conditionnal Load and Store > > > `jump' has a free bit, and we can free one in `move' if we make sign > > extension a separate operation. if it is possible to use the proposed 4-bit version of the condition field, i'll integrate it. > > Another option is to make `move' a full-word operation (that is, no > > size bits at all, like jump) and reconsider `widen' for sign and zero > > extension. That way, we can use 6 bits for the condition code. i don't remember what the options for MOVE are. however i have separated MOVE from CMOVE because CMOVE requires an additional condition field. Although these fields are cleared in a normal MOVE, the separate opcode might be critical for later architectures. > If we consider that registers are always 64-bit wide (or 256-bit wide), > 'move' does not need to have size-bits. I always thought that size-bits > usually apply for load and store operations not for registers by themselves. > Sign or zero extension should be done with 'widen', since its name is not > misnamed :). maybe the size bit can have special uses in move. but the context is not fresh in my head. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Mon Jul 29 02:47:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UG-0006Wo-02 for ; Mon, 29 Jul 2002 11:06:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:44 +0200 (CEST) Received: (qmail 9499 invoked by uid 0); 29 Jul 2002 00:47:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 29 Jul 2002 00:47:34 -0000 Received: by moria.seul.org (Postfix) id 9BBAA14691B; Sun, 28 Jul 2002 20:47:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8359214691E; Sun, 28 Jul 2002 20:47:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id 099FD14691B for ; Sun, 28 Jul 2002 20:47:33 -0400 (EDT) Message-ID: <20020729004732.59617.qmail@web14208.mail.yahoo.com> Received: from [130.89.243.164] by web14208.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 17:47:32 PDT Date: Sun, 28 Jul 2002 17:47:32 -0700 (PDT) From: jaap stolk Subject: [f-cpu] jws snapshot To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N its on: http://f-cpu.seul.org/~f-cpu/new/snapshot_jws_29_07_2002.tar.bz2 bug reports would be nice, but i already know a lot of them ... it includes your (unchanged :-) rop2 files) i haven't checked everything mot the move_test.asm seems to work ok. (there could be a g(); n(); somwhere :-) ) i could not find an M4 file for the ports.h is that correct? now, i'm going to get some sleep, before my bugs/h rate hits the roof... jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 03:09:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UK-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:48 +0200 (CEST) Received: (qmail 31216 invoked by uid 0); 29 Jul 2002 00:59:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 29 Jul 2002 00:59:55 -0000 Received: by moria.seul.org (Postfix) id 53F1414691B; Sun, 28 Jul 2002 20:59:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45CDB14691E; Sun, 28 Jul 2002 20:59:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id E7C2614691B for ; Sun, 28 Jul 2002 20:59:53 -0400 (EDT) Received: from f-cpu.org (kro1-17.n.club-internet.fr [213.44.93.17]) by relay-5v.club-internet.fr (Postfix) with ESMTP id C26381699 for ; Mon, 29 Jul 2002 02:59:51 +0200 (CEST) Message-ID: <3D4495B6.8E47CDC1@f-cpu.org> Date: Mon, 29 Jul 2002 03:09:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] jws snapshot References: <20020729004732.59617.qmail@web14208.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: > its on: > > http://f-cpu.seul.org/~f-cpu/new/snapshot_jws_29_07_2002.tar.bz2 donwloaded. i'll check it now. > bug reports would be nice, but i already know > a lot of them ... :-) > it includes your (unchanged :-) rop2 files) > i haven't checked everything mot the > move_test.asm seems to work ok. > (there could be a g(); n(); somwhere :-) ) we've already done the hardest :-) > i could not find an M4 file for the ports.h > is that correct? right. I was speaking about the opcodes, but i changed it. though i did not add new instructions, just moved them around + added cmove. > now, i'm going to get some sleep, before my > bugs/h rate hits the roof... good night :-) i'll work until sunrise... > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 06:07:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UM-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:50 +0200 (CEST) Received: (qmail 9330 invoked by uid 0); 29 Jul 2002 03:58:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 29 Jul 2002 03:58:28 -0000 Received: by moria.seul.org (Postfix) id BFD401467F1; Sun, 28 Jul 2002 23:58:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6504146815; Sun, 28 Jul 2002 23:58:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 276781467F1 for ; Sun, 28 Jul 2002 23:58:23 -0400 (EDT) Received: from f-cpu.org (kdl16-29.n.club-internet.fr [213.44.18.29]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 21BAD16A1 for ; Mon, 29 Jul 2002 05:58:16 +0200 (CEST) Message-ID: <3D44BF85.7B079C2@f-cpu.org> Date: Mon, 29 Jul 2002 06:07:33 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] jws snapshot References: <20020729004732.59617.qmail@web14208.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------076E2C8697A0C2FF40C91868" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------076E2C8697A0C2FF40C91868 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit re-hi, jaap stolk wrote: > (there could be a g(); n(); somwhere :-) ) best way to find them is to undefine them : gcc will be happy to complain ;-D > i could not find an M4 file for the ports.h is that correct? there is none yet. However, you have modified f-cpu/include/f-cpu_opcodes.h and f-cpu/configuration/f-cpu_opcodes.m4 but not f-cpu/configuration/f-cpu_opcodes.h.in ! so your f-cpu/include/f-cpu_opcodes.h will be lost if i rerun f-cpu/configure.sh. it's only a quick hack. I have however added a big !!WARNING!! to say that it's only temporary as long as the corresponding units are not done. all you have to do is uncompress the 3 files in f-cpu/configuration and rerun f-cpu/configure.sh. enjoy, > jaap. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------076E2C8697A0C2FF40C91868 Content-Type: application/x-unknown-content-type-WinZip; name="opcodes.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="opcodes.tgz" H4sIAE/ZRD0AA+1abXPaSBLO19OvaGc/2N7FGATYjlJ3dRhwoi1buIy9cT4RWQygi9CwerGX q/3x1z0zAiEkMLndTdWdulK7Zqa7p6df5uXRjE+ceTzkc4ePWFidVl3/zR9OtXqtdtZsvqkJ qmf/X2vq2Hfe0uv1VrPe0pFfb9TO30Dtjzdlk+IwsgOAN4vJdr6nP8Mz35+Gwyvzujf82Gt3 e3fDoab94I79ERvDVef2Ydi/7fS7vcHwo/YDtrk+yzZrpz9qWsjjwGFgwJiS6dTh/tidxIEd udw/HW8kmIZ/RK4vupdCru948Yhl2TXVPoKnheKUHHIQZHACZkfYP7Aj+Dn2oN4EvWHoZ0bj DHTMLhJ8mS4mjP1TSFZ5MNHskT0nofuYQTuegF6HWsvQ3xmNCyk05gHMmjAP2DzgDgtD159o 2v3UDWHsegxw+Mh2/RCiKQPhGldMh49Fi7L/UHu2vZiFFQjY2GMOznoi+mc8jLDNYX4ELzz4 WgWXGRr13PVv9UQccPI8mHP0JBNi49h3xDBjz56E6JvUYGgX80ZVEDbiP59HsGARYHrTTCWv xn5zQ2HFMwtC1BQmFl+dYGBhZvux7VU1Tfsxhz617yzT+nCQ10ektT1PKEuSxQ4YhPHTv3Dm EHFwprY/waiiH9kCzWZiYjidi5MnNwLpK1SAkZzZC3iSbsZU4nGoHdn+CGZYrRWaS8hn2GuH LDymKS+HDOHFRSOemMbnkTtz/41TJ8GAYdht3w3xt4ejBlXocv+QguAtyAQ02w1UuODg4CDX AbtI05RbRWKJbDyHmm60dKNRX2bj5w9gpHPJFYGWWY5Tk1n+68iZc0c/nWGWVR2N5iA7FhM7 nMn/Vh30A1keCCXcF1NhmBcYdB8rUsWWRqmCGUmOZeomLhPK0f+O7ZPPAxaH0hJOqnGIcfRC kbTRuczzZCTYM/OJ55eP3WuMCEzQb5jnMRUKOPP5cVVNEf+hXjuK2Gwe4f9hxInFxtriaB/+ Q4McNo8qmP/IPHMn00hkr8Nnc7T3xY2mqRS9ESkqbHZ47I2S+QALAh6EqwLA2vUwA3w7WFRw UI1UrqKNDEmsqNZJv+1EqFmlIZr/kb/gLIMKzD2GmSYdIzh9eyamyX30AhVkqBHn4kWGIhLD c1w0npTjRVKGc/IiprKNP2zw0B6cPZU/HGir1BnEvliToAV1XJB0o/ZOpI4my2ckc//wp0Mq qcPfDzcl6zrUGkathquglAwYWoyS44DPYLUUY/uMP2O7z/0TtYqEUTweVzWP868iGXFxjQPi RqaXau5Yes2o15PlVpMa0bT1dX29NFZrbuPCaDRzJde3EbE4JiqWVVK4a9D69wJ2HPEZyjvo 8QVMmC9WnJFMqVkzMx2qV/0C6hdGq27UG9DpDe7JMh23C6pNG0KGIaQ1q3PT/0U5cqXjhisd 72hizQuj2dzQIWJHpYCLerBI7Rwh/ARJgGmqnr3gcYTr8CntsTsXHkAisbfkxLcwxgSlTB8n 0dZgp47T5R7fvx1a/VtSCcNht3c1XDWc/oilRNU5xQKowroQOWVNCBvS/R3FsOynBpqeMH21 7QXs19ilBQeaYmMIp+44kvtbRVMT1eF6cAmyoBhue5+wKhn67mKpRZV1SLxGxtLrfrvb6VuD tDFJWx7fYw7fo3DHUVrbT9A83jNgYr//r8MltKQnoxrQtVi8LHiWS25DuFM4Ev7+j5SvMnF8 eMzEUTagNvpLLr2zJ+LGbAs8ey4X1IuT9FEko7RtddeVqgbpQmHv73D1YHXuzb5Fnccb8lZW 3tomb2UUPPbv1g1QDfkKsDMjr8RX8qohX35D3MoOb20b3tqQf1T8K/NlQ4H5mwr6d1bWfmub /Vn/WSpgqwnIhoIJqAhms9TMZqlJ9e/OZheAW408T2NFj3EdxVwN6YDzQic9OqsxX2QX5SDW dpKCG2liZtPEXLPSzObZpgbLzGighmINVlYFJo+ZTbUtRlCuQTZYZjZYJhRr2FRgZU2wtppg bWp4VBJrCVfsh8ccFZhEZjblthhBOZedhgrfWtIVG2El8XzFEoxr8MEBqDsN/SlOx7RrMDvA vyK8pb5mIZajgdzfSfznT4PMLEyrs+YG9XsphZeCTaFub11I/d4uhJrNzEjma0YyMyPtFmp3 11cD9Xu70ODhck1I/d45kpkZabd5qNnMjFQgpP3A/JE7pq5e/4pavjcm81fS+sl51vwzxtiF /+mE+Un8r35WayF//fxcL/G/v4Ly7lqrbFiha8l17x3Uz41W09AvdqNr4rpp0FF3+20NGb4J xUtfuHSB3qUubVTeBqRuXbTo0tG1PXhY3oE1DU4K6LL3wbROrs1Ozxr0ipjShNMQ0MM84JPA nhEGMA4YW+In7wFvdAJkCdjIDaPAfYojgRagVaeEN3JchhaoBptif8QkKhGxYLZE6T5YD/BB XGM9uI2fPNeBa9dhfijQmTm1hFOxumnyenFFFgwSBOeKo14R4/fAXIHuJJdXPRlC6avgEQt1 HGE80OwACE7j/jHaupAAWiJJPtyY+Gp+CfIIUz5nEttzowSkUyc9utQhL3wy7z/2H+6hbX2m ffmubd1/fi8u63gVlogTaXJnc8+lW7wdBLYf0b0JFdz07jofUaJ9aV6b95/phHhl3lu9wQCu 8KDchtv23b3Zebhu38Htw91tf9CrAgyYQHRQfotrBRjMAwJ6I9v1RNrAZwxmOBUI1NR+ZgLN dZ8FTODw+WJ3xFCH7XG8lymAa+XB94DbEd6xK/ASuAT98s1YovQqmhUwfadagdY7uGfoHQa3 nu1gDAcxyTcatQpc8jAizps2Fku9Xj+pN2rn8DBoF5cAUs/q7lED3wgb7wmrvxpUT/DoMIGW ///waGfKnK+UTgK2ZPQlg3AncrZ0h+3hyjtagPrMgeYY2qw5dMdo/9GX5fEpfd05pHr9gkws COaB60dHXzQoYE1/iUhA7qqG6SkQVdWSY1xVOzw+PNbwcJZHcNP/pQe5XVSab1cQ1Vs4CnG1 iORedOQcEz52TPg72i9DlJql1b89rPztSw1HzuvGUam7XtDdUf06GQ5HrSW64rFxBAQNU3sC Sb0G7BKroi4vJqLm7Wdcf+wnrBQxHwHue/ZEAS7yrhyHCTq25JFjod93oGT5XkngLZrbRcHc l6AYMVFqYOYebfTiVa25LawCRCgMq+jF2YUZJGv9M1ga16rSvqAQq07/5tK0etsQqwouClw4 HeWk0yGcM8cd46qtGF0K5wQXc3Ic6S5wGhkrkuWsKJkehK/WBfJZRc3luFVhLvL3GqRRrMja T5NVpOqxf7eHJkI4ChTtpadYjbWXHqtY0eN+mh63qOrf7eNtQj+KJrdfBlgqBegomQeszSiR BbpmFIFrqlpQgzidoBo8s9LuiAcOu0JcZrK0Lz90FReCuc34iy3ZWixo7p34++ralvp76dqa /Htp2pr+e2naUQD7zW97Cew5w61FsN8ckzLI32yq1WrxXnOwhgzSEfAwzAUIK+nrTPIBT5zo 6PaUeguC/eK0j+dOvOaN8TTg49Ex9umMK+5sMZ51w+P8IsK762EFr8lf6rWiw0m3t2QpOqAQ GEg8yFK01RD0p1gaRbXU7SYDNQtYBg+XCUurWEsyUNEOSZCdYjlHlu+NlPxv0joW8zwdeX/8 E8Dt+F+tiSmwfP/XPMO/8Wqqt0r876+g7Pu/kxPY4zmfyheSynvUR9075Uk4gf/Sb0POjGbN aL4rhv9QLoM0YstOsFHyfBPeeHJC0q97MiKMK341QuCFfO8ikQOOByw/CjNDrL8oaaFH6nlD qEclYbR2q/v500Cp+yZQBuX2xWXI8tdCM8iboDNsFzwjTNkfoUGxfUEaFPkmnGY5cwHVFLh8 N1ozt52v9gRvo6mUxWO2tgxGwpB+MvgyZT69PsNMoyNEAiiE4qTBksDY9GoqjIJYPiDlxI5p GcnngxjHI/GmVDkGJ+OO3GiJYqZFXeFZ8UCPwCW0QLx6MwSjwwMces79EYWe/cacWAgJy+R7 PQyS/RRSJpCDCXwl88KQO64oSbL4NP0wSj6ec8VjQMKMffHih05pGGx66RilXywBWuLTozW8 oxt/X3/A9D4jkzxYKpKh/qxMZymUL9PJE0re5xQJif4N69QznELrsD9vIHPHQOaG1Oo5VL7U sr9I8HGHIBlKYT44SNad1Od2XKjwcK0+t6+pV9/JC2dD/VmT1GfyQhnqz8qor+Tbxtl0mvpK vm2gTSH1lbxQiPqzMuojeaEM9eeMs9U40Z8z0FYh0Y+BZPQYObVEvS/P5iWVVFJJJZVUUkkl lVRSSSWVVFJJJZVUUkkllVRSSSWVVFJJ353+A49JrH8AUAAA --------------076E2C8697A0C2FF40C91868-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 29 10:08:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UR-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:55 +0200 (CEST) Received: (qmail 9702 invoked by uid 0); 29 Jul 2002 08:18:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 Jul 2002 08:18:28 -0000 Received: by moria.seul.org (Postfix) id AAEC21467F1; Mon, 29 Jul 2002 04:18:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FDDA146815; Mon, 29 Jul 2002 04:18:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 64E141467F1 for ; Mon, 29 Jul 2002 04:18:23 -0400 (EDT) Received: (qmail 37770 invoked by uid 85); 29 Jul 2002 08:15:33 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.656112 secs); 29 Jul 2002 08:15:33 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 29 Jul 2002 08:15:32 -0000 Message-ID: <3D44F7FD.6040607@yahoo.fr> Date: Mon, 29 Jul 2002 10:08:29 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org, f-cpu_france@april.org Subject: [f-cpu] Web and webmaster Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The french version can be found at the end of the message Hello everyboby, Some parisian member of the f-cpu list have been made a little meeting to discuss about status of the project, the last week. It seems than we have or we will have a problem with the web site of f-cpu project. Today, Whygee manage this aspect (collect web proposal, discuss with people, try new methods...) but he will stop this. Because some people seems don't want work on the vhdl coding or software aspect of the project, we open a proposal for them, if they can program the website. We looking for a new webmaster (to replace Whygee). To define the job, I give you some possible point : * Site maintenance (like broken links, look & feel, update, and perhaps cvs management too) * He can delegate some part of job, but he can impose the format (like html, php, dacode...) * If a web team is created, he must follow the state of the work, and manage the team. * When a new look and feel, a new section, a major modification on the site must be made, he must launch the discussion on the f-cpu mailing list, organize the pools and synthesize result. If you want add something, do it. Until now, Whygee have communicate me the following list of name (people who have propose their services for the web site developpement) : -"Cedric De Wilde" who have proposing the daCode version. -"Pablo Belin" who have made the Who's Who -"Paul Marques Mota" who give help about server problems -"Samuel Desseaux" who propose a php version of the site. If this people accept to keep in charge of the site developpement, I'll propose than they can submit their application. If others people want submit their application too, do it. I propose to close the discussion during the third week of august (I gooing in holidays at the end of the week, and I have no access to my account before the 19th august). The future webmaster can be named by a pool, after the canditature collection. Cheers, Just an Illusion PS : About the web site content, the proposal can be made too. ************************** Bonjour tout le monde, Une partie des membres parisiens du f-cpu se sont réunis la semaine dernière, pour faire un point sur l'avancé du projet. Il semble que nous avons, nous aurons, un problème avec le site web. Actuellement, Whygee s'occupe d'organiser cela, mais il désire ne plus avoir à le faire. Parce que certaines personnes ne semble pas avoir envie de développer le code vhdl, ou le soft nécessaire, nous leurs faisons une proposition, s'ils peuvent développer le site. Nous recherchons un nouveau webmestre (pour remplacer whygee) Voici quelques point pour illuster son rôle possible : * Maintenance du site * En cas de travail en équipe, choix du format des pages, et rôle de manager de l'équipe. * C'est de lui qu'emmaneront les proposition d'évolution, les proposition de nouvelles rubriques, il organisera les votes et les synthèses. Si vous avez d'autres propositions, faites le. Voici une liste de personnes que Whygee m'a communiqué qui ont proposé leurs services pour le développement du site. - "Cedric De Wilde" qui a fait le proposition du site en daCode - pablo.belin@free.fr (ABUL) qui a fait un Who's Who. - Paul Marques Mota qui peut parfois aider pour les histoires de serveurs. - "samuel desseaux" qui propose une version php du site Si ces personnes veulent prendre en charge le développement, qu'ils proposent leurs candidatures Si d'autres personnes veulent se proposer, qu'ils le fassent. Je propose de conclure cette discussion la 3e semaine d'août (je pars en vacances en fin de semaine, et je n'aurais pas accées à mon compte d'ici le 19) Le nouveau webmestre pourra être désigné par un vote, aprés la collecte des candidatures. @+ Just an Illusion PS : Pour le contenu du site, faites aussi des propositions. -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 29 10:18:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6US-0006Wo-01 for ; Mon, 29 Jul 2002 11:06:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:56 +0200 (CEST) Received: (qmail 11953 invoked by uid 0); 29 Jul 2002 08:28:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 29 Jul 2002 08:28:53 -0000 Received: by moria.seul.org (Postfix) id 374021467F1; Mon, 29 Jul 2002 04:28:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ECCA2146815; Mon, 29 Jul 2002 04:28:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 5C43D1467F1 for ; Mon, 29 Jul 2002 04:28:47 -0400 (EDT) Received: (qmail 38173 invoked by uid 85); 29 Jul 2002 08:25:57 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.164641 secs); 29 Jul 2002 08:25:57 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 29 Jul 2002 08:25:57 -0000 Message-ID: <3D44FA6E.4060708@yahoo.fr> Date: Mon, 29 Jul 2002 10:18:54 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Made synthesis on closed subject Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, after a private disussion between different member of the f-cpu list, we have arrive to conclude than some decision have been made on f-cpu, decision which are not clearly explain to everybody. So we propose you something, each time a thread seems close, the initiator (if possible) made a synthesis of the there content and give the result. NicO have propose made this synthesis like an rfc (request for comment), which can be put on the web site to submit to pool if necessary, but more to be reference in case of questions. Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 29 10:32:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z6UT-0006Wo-00 for ; Mon, 29 Jul 2002 11:06:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 11:06:57 +0200 (CEST) Received: (qmail 20349 invoked by uid 0); 29 Jul 2002 08:42:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 Jul 2002 08:42:31 -0000 Received: by moria.seul.org (Postfix) id 4749B1467F1; Mon, 29 Jul 2002 04:42:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23584146815; Mon, 29 Jul 2002 04:42:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 5CA7F1467F1 for ; Mon, 29 Jul 2002 04:42:29 -0400 (EDT) Received: (qmail 38823 invoked by uid 85); 29 Jul 2002 08:39:39 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.440605 secs); 29 Jul 2002 08:39:39 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 29 Jul 2002 08:39:38 -0000 Message-ID: <3D44FDA3.6060408@yahoo.fr> Date: Mon, 29 Jul 2002 10:32:35 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] HDL coding rules Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, After a private disussion between different member of the f-cpu list, we have arrive to conclude than no coding rules exist on the project. This point seems not very important as long as the number of coder is small, but to help newbies or modification of existing block, the coding rule usage is better. The existance of coding rule, can be help to understand the code of a bloc and the hierarchical structure. We made some proposal : * hierarchical prefix on each signal (and interface pad) to give hierarchical belonging * postfix on each signal to give signal direction or polarity, like _i (input), _o(output), _s(internal signal), _n(not signal)... * file name rule * don't use signal declaration into package declaration. If you see other rules, propose them. Cheers, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 29 12:42:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z9KK-0000FS-00 for ; Mon, 29 Jul 2002 14:08:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 14:08:40 +0200 (CEST) Received: (qmail 32528 invoked by uid 0); 29 Jul 2002 10:52:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 29 Jul 2002 10:52:47 -0000 Received: by moria.seul.org (Postfix) id EE9011467F1; Mon, 29 Jul 2002 06:52:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7A41146815; Mon, 29 Jul 2002 06:52:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 845D41467F1 for ; Mon, 29 Jul 2002 06:52:44 -0400 (EDT) Received: (qmail 43465 invoked by uid 85); 29 Jul 2002 10:49:53 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 3.496427 secs); 29 Jul 2002 10:49:53 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 29 Jul 2002 10:49:50 -0000 Message-ID: <3D451C27.9010703@yahoo.fr> Date: Mon, 29 Jul 2002 12:42:47 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org, f-cpu_france@april.org Subject: [f-cpu] An introduction to F-CPU / Une introduction au F-CPU Content-Type: multipart/mixed; boundary="------------000006030502070604080800" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------000006030502070604080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The french version of this document is given at the end of the message Hello, When I am arrived on the project (last March), I have encounter a little problem: I haven't find any update document to clearly explain me the history of the project, the current status of development, the architecture of the F-CPU... All this information exist but aren't easily accessible to newbies or new members. I have discuss with some other f-cpu members and they are agree than new members can have difficulty to well understand the current status and know what they can do to help the project. I have made an other observation, after few month of reading subject on the mailing-list, answers made, list of caller it seems than some people don't make comment on lot of subject (see the TLB design thread where only 5 peoples have been made comments), or made comment which illustrate a misunderstood of the subject. I propose than I make a starter kit for new members with your help. To begin I propose the attached document which can be the first step of the starter kit. The document format is not important, I have made it in html to help the cross-os consultation. At the end, the definitive format can be changed. The current version is only a squeleton to begin discussion, I propose than everybody made comment, write something in any part, add part if they want. I have made two version currently, a french and an english; if some one want translate them into other language, please do it. I'll propose to manage the development of this document, including any proposal after validation by the list. I have certainly made grammatical or spelling error, then you can made any correction you want. Cheers, Just an Illusion ****************************** Bonjours, Quand je suis arrivé sur le project (en mars denier), j'ai rencontré un petit problème : j'ai eu beaucoup de mal à trouver un document qui explique clairement l'histoire du projet, l'état courant du développement, l'architecture... Toutes ces informations existent, mais elles sont difficilement accessibles aux debutant et aux nouveaux membres. J'en ai discuté avec d'autres membres, et il semble d'accord pour dire qu'un nouveau membre a souvent du mal à comprendre l'état courant du développement et ce qu'il peut faire pour le project. J'ai constaté aussi autre chose en suivant les discussions, le contenu des réponses et la liste des intervenants, il semblerait qu'un certain nombre de sujet dépasse les connaissances de certains membres (regarder par exemple le sujet TLB design sur la liste anglaise), ou bien que certaines réponses prouvent la méconaissance de certains sujets. Je me propose donc de faire un kit de démarrage pour les nouveaux membres, avec votre aide à tous. Pour commencer, je vous propose le document ci-joint, qui pourra servir de premier pas dans le kit. Le format courant du document n'est pas important, je l'ai écrit en html pour facilité la consultation multi OS. Le format sera déterminé pour le version finale. La version courante n'est qu'un squelette qui servira de base à la discussion. Je propose que chacun le commente, voir écrive un morceau, fasse des ajouts si possible. Je maintiens deux versions du document, une en français et une en anglais ; si quelqu'un se veut les traduire dans une autre langue, il n'y a aucun problème. Je me propose de diriger la rédaction de ce document, y inclure toutes les propositions aprés que la liste les ait validés. J'ai certainement fait des erreurs de grammaire et d'orthographe, si vous en trouvez corriger les, merci. @+ Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 --------------000006030502070604080800 Content-Type: text/html; charset=us-ascii; name="fcpu-pour-les-nuls.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fcpu-pour-les-nuls.htm" FCPU pour les Nuls

F-CPU pour les Nuls

Introduction au projet F-CPU

  

F-CPU for Dummies

Introduction to the F-CPU Project

Plan

  

Plan

Notice Légale

  

Legal Notice

Présentation Générale

Le nom F-CPU signifie Freedom CPU

Le but de ce document n'est nullement de présenter le projet F-CPU, il existe déjà plusieurs documents présentant les buts et l'état actuel du projet (Voir la bibliographie).

Le but recherché est plutôt de vulgariser les concepts afin de donner aux non spécialistes une culture suffisante pour comprendre la majorité des sujets qui ont été, qui sont et qui seront traités sur la liste de diffusion F-CPU.

Dans un premier temps, nous nous efforcerons d'expliquer ce qu'est un CPU,  ce qui le caractérise, quel sont les architectures matériel/logiciel associées. Nous présenterons aussi une partie du vocabulaire associé.

Dans un deuxième temps nous donnerons une vue rapide sur les choix architecturaux retenus pour le FCPU et leFC0 et l'explication de la fonction attendue de chaque bloc.

Dans un derniers temp, nous nous intéresseront plus particulièrement aux outils utilisés pour le développement et la vérification/validation du F-CPU, avec une introduction aux language de modélisation/description/spécification HW.

  

Overview

The name F-CPU is the abbreviation for Freedom CPU

This document goal isn't presentation of the F-CPU project, you can find some other document which give you the project objectives and the current status (see bibliography).

No, the goal is more made some concept vulgarisation to give to non specialized a minimum base to understand a greater number of subject, developped, developpe or will be developped on the f-cpu mailing list.

In a first time will be try to explain what is a CPU, what thing characterized it, what are the associated hardware/software architecture. We will present some part of the associated vocabular, with a simple definition.

In a second time, we will present a quick overview of the FCO architecture with a explanation on the behavior of each block.

In a last time, we will present the developpement tools used in F-CPU developpement and validation/verification, with a complementary introduction to the modelization/description/specification HW language.

Table des Matières

  

Table of Content

0-Le CPU

  

0-The CPU

0.1-Qu'est ce que c'est ?

<Dans cette partie, il faut tenter de donner une explication ce que fait un CPU, des définitions, ses propriétés...>
  

0.1-What it is ?


<In this part, we must try to give an explanation on CPU job, some definitions, the CPU properties...>

0.2-Le vocabulaire des Barbares

<Ici il faut définir les grand concepts sur les processeur, telque les jeux d'instructions, l'organisation des données, les architectures...>
  

0.2-Barbarians words


<We must define here the great concept link with processor, like instruction set, data organisation, architectures...>

0.2.1-RISC/CISC

  

0.2.1-RISC/CISC

0.2.2-Big/Little Endian

  

0.2.2-Big/Little Endian

0.2.3-Havard/Von Neumann

  

0.2.3-Havard/Von Neumann

0.2.4-Multiprocesseur

0.2.4-Multiprocessor

0.2.5-SMP

0.2.5-SMP

0.2.6-ACMD

0.2.6-ACMD

0.2.7-SIMD/MIMD/SISD

0.2.7-SIMD/MIMD/SISD

0.2.8-VLIW

0.2.8-VLIW
...   ...

0.3-Il ne faut pas confondre

<Ici je verrais bien un rassemblement de fausses vérités sur les CPU>
  

0.3-Don't make confusion


<Here I see a garbage of common mistake on CPU>

0.3.1-CPU & MCU

  

0.3.1-CPU & MCU

0.3.2-CPU & DSP

  

0.3.2-CPU & DSP

0.3.3-CPU & FPGA

  

0.3.3-CPU & FPGA

0.3.4-CPU & ASIC

  

0.3.4-CPU & ASIC

0.3.5-CPU & ASIP

0.3.5-CPU & ASIP

0.3.6-CPU & Chipset

0.3.6-CPU & Chipset

0.3.7-Pipeline

0.3.7-Pipeline

0.4-Les mots clés du F-CPU

<Ici il faudrait définir chacun des blocs du FC0 et de leurs fonctionnalités>
  

0.4-The F-CPU Keywords


<Here we define each FC0 blocks and behaviour>

0.4.1-L'architecture

  

0.4.1-The architecture

0.4.2-Le sequenceur

  

0.4.2-Sequencer

0.4.3-UAL

  

0.4.3-ALU

0.4.4-Le banc de registres

  

0.4.4-Registers

0.4.5-XBar

  

0.4.5-XBar

0.4.6-TLB & mémoire cache

  

0.4.6-TLB & cache memory

0.4.7-Mémoire

  

0.4.7-Memories

0.4.8-OOOC

0.4.8-OOOC

1-Le flot de développement matériel

<Ici il faut expliquer comment les SoC, les IC ou autres sont développés du point de vue HW, avec peut-être un comparatif avec un développement soft>
  

1-The hardware development process


<Here we define the HW  development process for SoC, IC and others. With, perhaps, a comparison with SW development>

2-Le HDL

< Ici on fait un cours introductif aux HDL et à leur utilisation pour le développement HW, le but étant d'éviter les éternels retours de la discussion autours du fait que l'on utilise VHDL et Verilog et que les softeux comprennes pas pourquoi il peuvent pas avoir une puce depuis un fichier compiler C ou autre>
  

2-HDL


<Here we made an introduction lesson to HDL and their usage to HW development, the goal is to clarify some recurrent error which give recurrent discussion on the development language; some SW developper seems not understand why we couldn't obtain a chip from a compiled C file or other common SW development language>

2.1-Qu'est-ce-que c'est ?

  

2.1-What is it ?

2.2-Les niveaux d'abstraction

  

2.2-Abstraction Levels

2.3-Le VHDL

  

2.3-VHDL

2.3.1-Histoire

  

2.3.1-History

2.3.2-Ils l'ont dit...

<Ici je metttrai bien des extraits des discussions des mailing-list sur les mécompréhensions du but du VHDL>
  

2.3.2-They have said...


< Here I see some extracts from mailing-list discussion on the common mistake about VHDL which illustrated the problem>

2.3.3-Présentation des concepts

  

2.3.3-Concept overview

2.3.4-Exemple de code

  

2.3.4-Code Example

2.4-Le Verilog

  

2.4-Verilog

2.4.1-Histoire

  

2.4.1-History

2.4.2-Ils l'ont dit...

<Ici je metttrai bien des extraits des discussions des mailling-list sur les mécompréhensions du but du Verilog, je ne sait pas s'il y en a mais cela pourrait arriver à l'avenir>
  

2.4.2-They have said...


< Here I see some extracts from mailing-list discussion on the common mistake about Verilog which illustrated the problem>

2.4.3-Présentation des concepts

  

2.4.3-Concept overview

2.4.4-Exemple de code

  

2.4.4-Code Example

3-La simulation

<Ici il faut parler des problèmes de vérification HW, et des méthodes classiques employées.
Si l'on désire appliquer des méthodes modernes de vérif', le chapitre pourrait changer de nom et en parler>
  

3-Simulation


<Here, we can present the classical HW verification methods.
We can add chapter on new methods too, in taht case the chapter name will certainly change>

4-La synthèse

<Il faut parler des problèmes de la synthèse et pourquoi un code HDL n'est pas obligatoirement synthétisable.
On peut y présenter aussi un avant goût des règles de bonne écriture et les problèmes de timing HW>
  

4-Synthesis


<We must present the problems link to the HW synthesis, and why any HDL code can be unsynthezisable.
We can present an overview of well coding rules and HW timing problematic>

5-Les Outils

<Il serait bien de pouvoir lister l'ensemble des outils intervenant dans le développement du F-CPU avec à chaque fois un positionnement dans le flot de conception>
  

5-Tools


<Here we can give the list of tools currently used on the project and give their position into the conception stream>

6-Ou trouver de l'information complémentaire

<Ici un ensemble de liens sur les sujets abordés qui permettront d'approfondir les recherches des gens sur ces sujets, il y aura biensur des liens vers les ressources F-CPU>
  

6-Where found complementary informations


<We can put here a list of link about different subject presented above to help people who want more informations on a specific subject, of course we will add links to F-CPU ressources>

6.1-F-CPU

  

6.1-F-CPU

6.2-VHDL

  

6.2-VHDL

6.3-Verilog

  

6.3-Verilog

6.4-Architecture des Processeurs

  

6.4-Processors Architecture

6.5-Les outils de l'EDA

  

6.5-EDA tools

7-Glossaire

  

7-Glossaire

8-Index

  

8-Index

9-Bibliographie

  

9-Bibliography

 

--------------000006030502070604080800-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jul 29 13:23:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Z9KO-0000FS-00 for ; Mon, 29 Jul 2002 14:08:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Jul 2002 14:08:44 +0200 (CEST) Received: (qmail 8306 invoked by uid 0); 29 Jul 2002 11:33:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 29 Jul 2002 11:33:53 -0000 Received: by moria.seul.org (Postfix) id 03D7F1467F1; Mon, 29 Jul 2002 07:33:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF143146815; Mon, 29 Jul 2002 07:33:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 572B91467F1 for ; Mon, 29 Jul 2002 07:33:52 -0400 (EDT) Received: (qmail 44642 invoked by uid 85); 29 Jul 2002 11:31:01 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.370992 secs); 29 Jul 2002 11:31:01 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 29 Jul 2002 11:31:01 -0000 Message-ID: <3D4525CE.2040103@yahoo.fr> Date: Mon, 29 Jul 2002 13:23:58 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Control signals on the Xbar References: <3D4415C8.EFB2EB82@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Yann Guidon wrote: >hi, > >i have too much troubles with your modifications to the >ROP2 unit, because you changed the scheduling of the units. > Do you understand now the problem of non-definition of communication process between blocks ? > >Now the C and VHDL version do no behave the same way >and that's not a good news because it worked before. > >Could you please move the mode and the size control bits >to the Xbar ? including their pipeline in the ROP2 unit >creates problems both in C and VHDL. > Do you understand now, the necessity to clearly define the block interface and the communication protocols ? > > >Concerning the "stalled" signal : it is not present in >the ROP2 files, because the rop2_xbar and rop2_unit >stages are "included" from the Xbar which will perform >the "if (!stalled)" thing. The execution units should >not contain the input and output pipeline latches >because it's the job of the Xbar. You just added a >pipeline stage with a conditional thing inside ROP2, >which makes it very different. > >I'm going to keep some of your modifications but >i'll have to remove the tmp_* which should be in >the Xbar file. > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > @+ Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 29 16:22:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbg-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:24 +0200 (CEST) Received: (qmail 6182 invoked by uid 0); 29 Jul 2002 14:30:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 29 Jul 2002 14:30:50 -0000 Received: by moria.seul.org (Postfix) id 279E71467F1; Mon, 29 Jul 2002 10:30:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE5B114691E; Mon, 29 Jul 2002 10:30:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a232.home.uni-hannover.de [130.75.232.232]) by moria.seul.org (Postfix) with ESMTP id 2F11F1467F1 for ; Mon, 29 Jul 2002 10:30:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00723; Mon, 29 Jul 2002 16:22:22 +0200 Message-ID: <20020729162222.22776@thrai.stud.uni-hannover.de> Date: Mon, 29 Jul 2002 16:22:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Web and webmaster References: <3D44F7FD.6040607@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D44F7FD.6040607@yahoo.fr>; from Just an Illusion on Mon, Jul 29, 2002 at 10:08:29AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 10:08:29AM +0200, Just an Illusion wrote: [...] > We looking for a new webmaster (to replace Whygee). Does he want to be replaced? > To define the job, I give you some possible point : > * Site maintenance (like broken links, look & feel, update, and > perhaps cvs management too) > * He can delegate some part of job, but he can impose the format > (like html, php, dacode...) > * If a web team is created, he must follow the state of the work, > and manage the team. > * When a new look and feel, a new section, a major modification on > the site must be made, he must launch the discussion on the f-cpu > mailing list, organize the pools and synthesize result. > > If you want add something, do it. * (S)he MUST speak English. * The website MUST NOT move again. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 29 16:08:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbg-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:24 +0200 (CEST) Received: (qmail 26628 invoked by uid 0); 29 Jul 2002 14:30:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 29 Jul 2002 14:30:53 -0000 Received: by moria.seul.org (Postfix) id 085E714691B; Mon, 29 Jul 2002 10:30:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C1EC214691F; Mon, 29 Jul 2002 10:30:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a232.home.uni-hannover.de [130.75.232.232]) by moria.seul.org (Postfix) with ESMTP id 35E5D14691B for ; Mon, 29 Jul 2002 10:30:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00687; Mon, 29 Jul 2002 16:08:37 +0200 Message-ID: <20020729160837.53960@thrai.stud.uni-hannover.de> Date: Mon, 29 Jul 2002 16:08:37 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D44FDA3.6060408@yahoo.fr>; from Just an Illusion on Mon, Jul 29, 2002 at 10:32:35AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 10:32:35AM +0200, Just an Illusion wrote: > Hello, > > After a private disussion between different member of the f-cpu list, we > have arrive to conclude than no coding rules exist on the project. > This point seems not very important as long as the number of coder is > small, but to help newbies or modification of existing block, the coding > rule usage is better. > The existance of coding rule, can be help to understand the code of a > bloc and the hierarchical structure. > > We made some proposal : > * hierarchical prefix on each signal (and interface pad) to give > hierarchical belonging > * postfix on each signal to give signal direction or polarity, > like _i (input), _o(output), _s(internal signal), _n(not signal)... > * file name rule That's pure bureaucracy, and it won't help at all. I've seen (and written) a lot of code in my life, and I know that names don't make it more readable. Structure is more important, as well as proper indentation (some code I've seen really sucks with respect to that). Whitespace makes a program readable (unless you overdose it), and once it is readable, one should be able to understand it (assuming that one knows the language it's written in). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Mon Jul 29 17:32:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbh-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:25 +0200 (CEST) Received: (qmail 915 invoked by uid 0); 29 Jul 2002 15:32:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 29 Jul 2002 15:32:49 -0000 Received: by moria.seul.org (Postfix) id DCB2C14691B; Mon, 29 Jul 2002 11:32:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2389414691F; Mon, 29 Jul 2002 11:32:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id D0F9114691B for ; Mon, 29 Jul 2002 11:32:42 -0400 (EDT) Message-ID: <20020729153242.37234.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.164] by web14202.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 08:32:42 PDT Date: Mon, 29 Jul 2002 08:32:42 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] Control signals on the Xbar To: f-cpu@seul.org In-Reply-To: <3D4525CE.2040103@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, (i'm the one that caused al these problems :-) ) --- Just an Illusion wrote: > Do you understand now the problem of non-definition > of communication > process between blocks ? > Do you understand now, the necessity to clearly > define the block > interface and the communication protocols ? centenary, an accurate and fixed description of each units interface would be helpful, however we will never have that till the F-CPU is completely designed, implemented, and tested. it will always we necessary to keep changing what part belongs to witch unit, and the communication between the units will we changed now and than, if it could make both units less complicated (think transistor count, timing, fan-out, etc. ) i think the best would be to make it easy to change the interface (if possible) and tell other ppl before doing a interface change. ------------------------ also: simulator update: multiply is working now, i can get upto 14 registers in the writeback queue in the scheduler, if i do a roe mul's :-). (not uploaded yet) jaap __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Jul 23 16:37:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbj-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:27 +0200 (CEST) Received: (qmail 6682 invoked by uid 0); 29 Jul 2002 15:44:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 29 Jul 2002 15:44:26 -0000 Received: by moria.seul.org (Postfix) id 3463C14691C; Mon, 29 Jul 2002 11:44:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D1B4146920; Mon, 29 Jul 2002 11:44:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id A803B14691C for ; Mon, 29 Jul 2002 11:44:23 -0400 (EDT) Received: from laposte.net (193.250.154.71) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9000EF532 for f-cpu@seul.org; Mon, 29 Jul 2002 17:44:22 +0200 Message-ID: <3D3D6A25.4080207@laposte.net> Date: Tue, 23 Jul 2002 16:37:26 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <3D3C3959.80201@laposte.net> <1027368123.3d3c64bb76400@imp.free.fr> <3D3C927B.6D069774@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > todo : > > REMOVE THE BODY OF CHAPTER 3 IN PART 1. > > it has mislead several people and it is > more and more off-topic. > We can keep some meaningful parts, > but the technical details are like a time bomb. > > And all the parts that remain MUST be surrounded > by a colored frame, to show that it is not > written by the current team. when the manual was in > HTML, there was a grey backgrgound, but someone > removed it when going to LaTeX :-( > > >>A+ >> Cedric > > WHYGEE I think it could be a good thing to have 3 different book : 1/ A first book for the project history where we can put all old stuff so this will not mislead new people. 2/ A book for describing the f-cpu and his execution unit and all hardware related informations. 3/ A book for the ISA. It was more simple for read and update I think. Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 29 18:14:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbj-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:27 +0200 (CEST) Received: (qmail 24403 invoked by uid 0); 29 Jul 2002 16:14:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 Jul 2002 16:14:32 -0000 Received: by moria.seul.org (Postfix) id 40DA814691B; Mon, 29 Jul 2002 12:14:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 14D3C14691F; Mon, 29 Jul 2002 12:14:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 424F314691B for ; Mon, 29 Jul 2002 12:14:30 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 12C8B14D for ; Mon, 29 Jul 2002 18:14:28 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id E51EA8C105; Mon, 29 Jul 2002 18:14:27 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store Message-ID: <1027959267.3d4569e3ddd3c@imp.free.fr> Date: Mon, 29 Jul 2002 18:14:27 +0200 (MEST) From: Cedric BAIL References: <1027689495.3d414c17bd2c6@imp.free.fr> <20020726174621.46397@thrai.stud.uni-hannover.de> In-Reply-To: <20020726174621.46397@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Quoting Michael Riepe : > On Fri, Jul 26, 2002 at 03:18:15PM +0200, Cedric BAIL wrote: > > Why didn't we have conditionnal load and store. I mean somtehing like > > storez, storenz, loadz, loadnz, ... It can be really usefull and we can do > > with that all what we can do with predicate I think. > Conditional load/store makes less sense than you may think. When an > address is loaded into a register, the prefetch cycle begins, whether > or not memory is actually accessed. Thus, there will be no increase in > memory bandwidth due to the use of conditional load/store. Arf, I forgot prefetch... A conditional prefetch, is it possible ? ;-D That not so stupid in fact. We have our strange cachemm instruction (I mean what did you think about : cachemmlcV, it's fun but have no sense...) So why not changing it, so that we have a conditionnal cachemm. In that case we need 2 more bits to define a register and 3 more for the test. And for loadaddr we have 11 unused bits, so we can have a conditionnal loadaddr too. I think that taking vacancy are not so good, I have crazy idea when I came back ;-) Now back to what you say, I was thinking that we make the test at start (before sending the job to the LSU), but if I correctly understand, we send all and make the test at the same time, right ? That's strange. > The only positive effect ist that CL/S will avoid some jumps. That is, > in the rare case that you have code like > > if (condition) { > *pointer = expression; > } > > with no preset and no else clause (or a volatile memory location), > and with a trivial expression (something that is already present in a > register, or can be computed with few additional instructions). If > the computation of the expression becomes more complex, a jump is the > better choice. As soon as other statements precede or follow the assignment > (inside the if clause), it is a must anyway. If think that a jump could be a good solution actually because we only issue one instruction per cycle, but what append if we issue more instructions ? I mean that of course we make reflexion for our ISA with big register, but we have the same reflexion with number of instructions per cycle. > BTW: Good programmers avoid code like this anyway. Remember that the > contents of `*pointer' remain undefined if `condition' evaluates to > `false'. It's much better to write: > if (condition) { > *pointer = expression; > } > else { > *pointer = default_value; > } > > or: > > *pointer = condition ? expression : default_value; > > which can be transformed to a conditional move. I agree, but you know "good programmer"... ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 29 18:21:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbk-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:28 +0200 (CEST) Received: (qmail 3062 invoked by uid 0); 29 Jul 2002 16:21:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 29 Jul 2002 16:21:22 -0000 Received: by moria.seul.org (Postfix) id 2286014691B; Mon, 29 Jul 2002 12:21:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB08514691F; Mon, 29 Jul 2002 12:21:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 5194214691B for ; Mon, 29 Jul 2002 12:21:20 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix1-2.free.fr (Postfix) with ESMTP id B9733AB608 for ; Mon, 29 Jul 2002 18:21:15 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id 984211270F; Mon, 29 Jul 2002 18:21:15 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] condition flag location Message-ID: <1027959675.3d456b7b8d38d@imp.free.fr> Date: Mon, 29 Jul 2002 18:21:15 +0200 (MEST) From: Cedric BAIL References: <20020728150304.3578.qmail@web14203.mail.yahoo.com> In-Reply-To: <20020728150304.3578.qmail@web14203.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am back from vacation, what append with reversing bits ? It's really possible that I make some mistake, but I think not so much (I write a translation table to limit them). If you have find one, can you clearly say where ? Cedric > hi, > > --- Yann Guidon wrote: > > hi ! > > for more informations, read the files > > f-cpu/INSTRUCTIONS.txt and > > f-cpu/FORMAT.txt which contain the correct bit > > numbers. > i will. > > > If you have found a place where the manual is not > > correctly updated, please warn Cédric (but i think > > he's in vacations for the week-end now) > i will look out for him :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 29 18:26:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbl-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:29 +0200 (CEST) Received: (qmail 14354 invoked by uid 0); 29 Jul 2002 16:26:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 29 Jul 2002 16:26:09 -0000 Received: by moria.seul.org (Postfix) id 8735E14691C; Mon, 29 Jul 2002 12:26:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57E42146920; Mon, 29 Jul 2002 12:26:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id CFF8814691C for ; Mon, 29 Jul 2002 12:26:06 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix2-2.free.fr (Postfix) with ESMTP id 05E9B5F9E5 for ; Mon, 29 Jul 2002 18:26:06 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id DF44612710; Mon, 29 Jul 2002 18:26:05 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Web and webmaster Message-ID: <1027959965.3d456c9dcb72f@imp.free.fr> Date: Mon, 29 Jul 2002 18:26:05 +0200 (MEST) From: Cedric BAIL References: <3D44F7FD.6040607@yahoo.fr> <20020729162222.22776@thrai.stud.uni-hannover.de> In-Reply-To: <20020729162222.22776@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > On Mon, Jul 29, 2002 at 10:08:29AM +0200, Just an Illusion wrote: > > We looking for a new webmaster (to replace Whygee). > Does he want to be replaced? He take time to answer, but from what he say, I think that he never whant any more to wrote a web site ;-) And that he really prefer VHDL. > > To define the job, I give you some possible point : > > * Site maintenance (like broken links, look & feel, update, and > > > perhaps cvs management too) > > * He can delegate some part of job, but he can impose the format > > > (like html, php, dacode...) > > * If a web team is created, he must follow the state of the work, > > and manage the team. > > * When a new look and feel, a new section, a major modification on > > the site must be made, he must launch the discussion on the f-cpu > > mailing list, organize the pools and synthesize result. > > If you want add something, do it. > > * (S)he MUST speak English. Of coure, but are your sure that we have a chance for the "s" ? ;-D > * The website MUST NOT move again. I must be more clear, he must use seul ! Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 29 18:33:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbl-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:29 +0200 (CEST) Received: (qmail 4950 invoked by uid 0); 29 Jul 2002 16:33:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 29 Jul 2002 16:33:18 -0000 Received: by moria.seul.org (Postfix) id CEC5114691C; Mon, 29 Jul 2002 12:33:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C18BB146920; Mon, 29 Jul 2002 12:33:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 6AA4014691C for ; Mon, 29 Jul 2002 12:33:16 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix2-2.free.fr (Postfix) with ESMTP id CF9085FB28 for ; Mon, 29 Jul 2002 18:33:15 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 3F340FC67; Mon, 29 Jul 2002 18:33:32 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) Message-ID: <1027960412.3d456e5c261b5@imp.free.fr> Date: Mon, 29 Jul 2002 18:33:32 +0200 (MEST) From: Cedric BAIL References: <1027355592.3d3c33c8c9ba4@imp.free.fr> <3D3C3959.80201@laposte.net> <1027368123.3d3c64bb76400@imp.free.fr> <3D3C927B.6D069774@f-cpu.org> <3D3D6A25.4080207@laposte.net> In-Reply-To: <3D3D6A25.4080207@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > todo : > > > > REMOVE THE BODY OF CHAPTER 3 IN PART 1. > > > > it has mislead several people and it is > > more and more off-topic. > > We can keep some meaningful parts, > > but the technical details are like a time bomb. > > > > And all the parts that remain MUST be surrounded > > by a colored frame, to show that it is not > > written by the current team. when the manual was in > > HTML, there was a grey backgrgound, but someone > > removed it when going to LaTeX :-( > > > > > >>A+ > >> Cedric > > > > WHYGEE > > I think it could be a good thing to have 3 different book : > > 1/ A first book for the project history where we can put all old stuff > > so this will not mislead new people. > > 2/ A book for describing the f-cpu and his execution unit and all > hardware related informations. > > 3/ A book for the ISA. > > It was more simple for read and update I think. > > Tom Why not, but you will need some body to write them. For the ISA and history, I can do it I think, but for the "nd, I didn't have enough time for it. I have a question in which book will you put the justification of decision in F-CPU family. For example the discussion about call convention, or on the TLB, or loadcons, ... Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Jul 29 18:36:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbm-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:30 +0200 (CEST) Received: (qmail 12202 invoked by uid 0); 29 Jul 2002 16:36:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 29 Jul 2002 16:36:42 -0000 Received: by moria.seul.org (Postfix) id 8CF1014691C; Mon, 29 Jul 2002 12:36:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 705B2146920; Mon, 29 Jul 2002 12:36:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 0C67414691C for ; Mon, 29 Jul 2002 12:36:40 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix1-2.free.fr (Postfix) with ESMTP id 1D9A9AB40C for ; Mon, 29 Jul 2002 18:36:39 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 86574FCCF; Mon, 29 Jul 2002 18:36:55 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 Message-ID: <1027960615.3d456f27547ca@imp.free.fr> Date: Mon, 29 Jul 2002 18:36:55 +0200 (MEST) From: Cedric BAIL References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> <3D3FEA3C.4070901@laposte.net> In-Reply-To: <3D3FEA3C.4070901@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Quoting Thomas Lavergne : > >>> 6.1.2 `loadcons': > >>> The jury is still discussing this. > >> > >>Ok, but you and thomas write the latest post, because nobody answer, I > >>was thinking it was decided. > > i am definitely against. > I'm definitely for... > Or for any other proposition that allow simple constant loading of any > size. And thats not the case for your loadcons/loadconsx. So it's under discussion ;-) Yann the reason you give to me for not doing it is only that you need 3 times more place for the version that Thomas want than for the one you whant, right > But Thomas version is more scalable and orhtogonal. And in fact I don't see that it cost so much. (I think you didn't explain completly your reason on the mailing list, like you explain to me, so if you have time it would be a good idea) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Mon Jul 29 20:06:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbm-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:30 +0200 (CEST) Received: (qmail 23571 invoked by uid 0); 29 Jul 2002 18:06:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 29 Jul 2002 18:06:24 -0000 Received: by moria.seul.org (Postfix) id BC0FB14691B; Mon, 29 Jul 2002 14:06:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7CCBC14691F; Mon, 29 Jul 2002 14:06:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id D0CE114691B for ; Mon, 29 Jul 2002 14:06:21 -0400 (EDT) Message-ID: <20020729180621.72752.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.164] by web14202.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 11:06:21 PDT Date: Mon, 29 Jul 2002 11:06:21 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] condition flag location To: f-cpu@seul.org In-Reply-To: <1027959675.3d456b7b8d38d@imp.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Cedric BAIL wrote: > Hi, > If you have find one, can you clearly > say where ? in the latest manual: MOVE numbered from bit 0.....bit 32 JMP numbered from bit 31.....bit 0 (at least) one of them must be wrong :-) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 20:50:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbn-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:31 +0200 (CEST) Received: (qmail 11948 invoked by uid 0); 29 Jul 2002 18:41:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 29 Jul 2002 18:41:06 -0000 Received: by moria.seul.org (Postfix) id A70FB1467EF; Mon, 29 Jul 2002 14:41:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C99E146920; Mon, 29 Jul 2002 14:41:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id F0AD61467EF for ; Mon, 29 Jul 2002 14:40:59 -0400 (EDT) Received: from f-cpu.org (kdl16-63.n.club-internet.fr [213.44.18.63]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5D62216B5 for ; Mon, 29 Jul 2002 20:40:57 +0200 (CEST) Message-ID: <3D458E68.8E4537C3@f-cpu.org> Date: Mon, 29 Jul 2002 20:50:16 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Just an Illusion wrote: > Hello, > > After a private disussion between different member of the f-cpu list, we > have arrive to conclude than no coding rules exist on the project. ??? that's wrong. or maybe you mixed "coding style" and "coding rule" which in our context are the same thing. And in case you want to start a new unit, just copy/paste an existing one and modify the necessary parts, while keeping the same look. btw, i looked once at the LEON code and i think it's easier to use F-CPU's sources. It's probably a bit confusing, but not confused. > This point seems not very important as long as the number of coder is > small, but to help newbies or modification of existing block, the coding > rule usage is better. The use of a brain (and optionally : good sense) is ok, too. > The existance of coding rule, can be help to understand the code of a > bloc and the hierarchical structure. > > We made some proposal : > * hierarchical prefix on each signal (and interface pad) to give > hierarchical belonging > * postfix on each signal to give signal direction or polarity, > like _i (input), _o(output), _s(internal signal), _n(not signal)... > * file name rule > * don't use signal declaration into package declaration. > > If you see other rules, propose them. maybe you can look at the code and see yourself. > Cheers, > Just an Illusion WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Mon Jul 29 20:48:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbq-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:34 +0200 (CEST) Received: (qmail 17183 invoked by uid 0); 29 Jul 2002 19:28:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 29 Jul 2002 19:28:45 -0000 Received: by moria.seul.org (Postfix) id 3FBA61467EF; Mon, 29 Jul 2002 15:28:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3500A146920; Mon, 29 Jul 2002 15:28:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 624601467EF for ; Mon, 29 Jul 2002 15:28:43 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-11-62-147-118-198.dial.proxad.net [62.147.118.198]) by postfix2-1.free.fr (Postfix) with SMTP id E39B3458 for ; Mon, 29 Jul 2002 21:28:37 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Mon, 29 Jul 2002 20:48:13 +0200 Date: Mon, 29 Jul 2002 20:48:13 +0200 From: Etienne LABARRE To: f-cpu english ML Subject: [f-cpu] New snapshot for EU_INC and EU_CMP Message-ID: <20020729184813.GB948@free.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pAwQNkOnpTn9IO2O" Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --pAwQNkOnpTn9IO2O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, New snapshot include a lot of changes and features : INC unit and CMP unit are now two different units, for simplify and decrease latency Both units are based to the same component : find_lsb It's a binary tree for find the first null lsb in a word. It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 bits) It's based to only one function : and_reduce. It's is a standard function of ieee.std_logic_1164 library. Latency of find_lsb is not exactly know, but i can estimate this to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of 8-and, and 1 level of mux. The precise latency is not important, because max latency will be fixed by timing constraints during synthetisis process. (It's an explain of my choice of standard function. "Just an Illusion" will can explain this more easy that me, i think...) For INC unit, the data flow is : 1 level of mux find_lsb : 3 level of 4-and, 1 level of mux 1 level of xor 2 level of mux total is 8 levels. Critical datapath is only for ABS operation. Supported operations : INC, DEC, NEG, ABS, LSB0, LSB1 All operations are tested by my testbenches. For CMP unit, the data flow is : 1 level of xor, 1 level of mux, find_lsb : 3 level of 4-and, 1 level of mux 2 level of mux, total is 8 levels. Critical datapath is for CMP, MIN, MAX, SORT operations. Supported operations : CMP, MIN, MAX, SORT, MSB0, MSB1 Today, only CMP, MSB0 and MSB1 are tested by my testbenches. Todo : test for others operations. All operations can need only one cycle, if we accept the 8 level of gates latency. Etienne. --pAwQNkOnpTn9IO2O Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="eu_inc_EL_290702.tar.gz" Content-Transfer-Encoding: base64 H4sICJeBRT0AA2V1X2luY19FTF8yOTA3MDIudGFyAOw9a3PbOJLzNfoVuOzWRsrYMkk97Mjr qZVtJfGtorgsZ+aydVUuSqJtJhSpIyUnnl9/3QBIAiRIiZL8yISs3YxFNBpAo7sB9AO0Flfj 6ax+dztxfnmoR9M1rd1s/qJpmr7f2sf/ajr7Tf+Cf37R9luGbrTb+1oD4I1Gs/UL0R6sR8Kz COamT8gv9ldzkgfnete2YwWP0aXHfHa39lR2d8lbIBFBXtqzFle2O8b/hOxFdsnJh3PyybXn pPfdGi/mtudipRNvdu/bN7dzUj2pEUPTDNKb25brWqRvjkzft0jVYi/qDnvxrxtz8mfd829q FdbwcOGS/144xDggeqPTaHYAyUlveMnQdUivTvrd4+7FRQ+hoZ9+MCd3lh+wPlSyh3Xce3c2 2P39/Wl/t3920huc9JZS4fLWDsjM9258c0rgz2vfskjgXc+/mb51SO69BRmbLvGtiR3MfXu0 mFsEiGK6kz3PJ1NvYl/fIx54t3Anlk/mtxaZW/40IN41/fFu8Im8s1zLNx1yvhg59pj07bHl BhYxoWl8E9xaEzKieLDGW+zDkPeBvPUAsYkTcEgsG8r9kBjECNvgCHeI5yOSqjnHnvvEm2G9 GnT3njjmPK5ar6iHH49yQmyX4r71ZjCiW0AJY/xmOw4ZWWQRWNcLZwdRADD54+zy/cdPl6Q7 +Ez+gJnrDi4/HwLw/NaDUuvOYqjs6cyxATOMyzfd+T10HzF86F2cvIcq3eOz/tnlZxgEeXt2 OegNh+TtxwvSJefdi8uzk0/97gU5/3Rx/nEILEKGFnbLQgQ5JL6mswRknFhz03aCcOCfYWID 6J0zIbfmnQUTPLbsO+ibScbA48snD5GYjufe0GECcEzIQ2JfE9eb75Bvvg38MvfS00olMJrZ HXLmjus7pPWGXFpAJIucO+YY5nO4QASNhrZDjr1gjpAfukQzdF3f1RvaPvk07OYIxG5vcLq6 POyGAnr24ZR8+HjaG+KvAHqN6hT+cSdXTjCiGgJL8P8fz3sX3cuzj4MhrYGvmDq5AtmwgAGB dDhCkIlgjqWwgBD6oIJhD3utsx8fzgbia51Df+j+j/SaQw8/XlziCz3E+mF4rLEXevRCz9ca RZ8KlXd37CxggLAiwRz6E+LYI9/0bSuo9M+OL7oXn4ltWdZh5dOwR/+qB3Ognndjj690vd2s d/t9odBdTC0figCobjrOodQGsNUXazxXNPHN878yLPhXPZwhVv3Ugt82JT5wc+/TFVLccuf2 /L7C/kOYygfBrwClbpDPgcGr/PXVN3sCnN0hrjlfoAB0jkib1A4Rdub5sARUGIk5eBf/7qDa IDjWBRvsHfTc86vG69ci1l2dTLxvLkiGxhDGaI63gyawp5NMNBKOZiYOysKZXcms9pmNAFXf JiP4z5poOBZAZ7kTjizkiGDs2zM1S5j++BaUzRjmGtjaploIgCQWmd/DWoCNogK/xwWD/iHT sxF3BREUJ0Fg37jAbnPQl1dIeyDCZkiQhMWRIJbrhTum5LLduyuQsUm1yxgihasGSwiQTlHC aQfPHUivOQK69mWp6r5yvG+HSaD3SaBb2HiloI6VA3sfDqTPBzKybmyX18U10cZB9HFpek8c z5vxIniOq3aNtld9/2t/1465EpgJIcPffLjH9DcWhrSCBiXSIXnHtwv3a5V0YRnboZpfTUSy IRUt92aeJtG/V6H2n5bvSaRM042BHGH/q//mdIVnbAa8etRFeL7dwqbnlf6KHP0Wjql7mCzW xOLjZLGHm71AhQDJjc2qaB/1mG7XpzPPBQGPFm8qxSgT4QsYM18MRBASLwdTc1aNyviaAF2S 1ohQ59BlASvEI4lq2u4MxRCqcsHeUQCBpCJUCAQ/VVBUtxOhF/gihuNTw8uAzzq4hI6tIAgV FfBhuNrsiDh2RM1fU7AcL4bN3Xr6RGAnmJ4zShLQkQtYp9lbsYEj3ERGqyufe8pt4voESjga OmWbl7DFeikSmvzzKNZf0WL9HWQqJELtMIVC3xiFvnkv9I17oa9CC0Wt5Q3D3CTrxQK7Smsp IeZMGnEv7qJx6YrZNxIKsikjD2KdmFKFCb2aYOoUeNimDtWivUEmlJELRQcIxfpaa74Kk7Gx oKKkwjEGVs0p9pxiTq6kGq6kiV2QvKwOOCltQctj9S9R9QH0Qq6D4h4SF1blavXLr3rtdX9v EPf3C/6k63W8zEoIYp3Sza6/k1HluECViM9DJs2uWxMERxyksfkgi/R4DbqsO8jk5in+HfNY YOEWnNDFzbHuLAetTGS6+E75BHrKQQUZORL4Q6utIh+CWBwJdF+tspLdEQHdmiaY174WIXBT eUT3Q6AjXYmsGeOxga6rdCp3XAWQ4JTY13kT9JFtTqT1WrUeJ7Zx8XocnQ/FZSHkpNphfPBT l6fx6mm8ETVldPHrFBZd0buInGoshgJL8b6ksegPRCldRanN8cbr/XbwZu8I4Af8Q7cET+r/ 0duNduj/aWr7+9T/0yr9P4/ybNGEmeH/CdmLwNlkcPKg/h+XNDT0/2hvOkajoP+HDM05dSHp DaIfdPRWR8tFQceBtvi55VK7g/V/Czz0wv4WVfZ6filzMonN2wGUd4+HO6Q/PNbovzq3kGc9 pa+q9FWVvirxeca+qkHvHV/3JV/Vae9EfB36qlB1iq85NOgHyVXVT7qq+qWrKvRLIAlTripo ROWqwgks4KpC8BVcVRHWDA8Nli/zMcU41D6miPWK+Ziw2go+JuUIUs4hgMpyDgmTkO0ciieF OofMUaBwDsVdWdE5lE39As6h1ZAscQ5lIJE8HDhowcPxtM4NpZcIB7zEu8FA0O+T9G3QkuW+ jRcZTo0XP4Y3I1YjT+nNCNWKypuBZUlvBtVmO2LNHVGzhKbfpX6H0IwRqaTV3ArcQUF7sYoP IRde4TDIhi2GW+UGyIYthFtp9E/AbmrqX3GWc/RHQpmlFESePwDVG1/qIvWutre71s1a+jiF CFeVrSCCDq+n3EXVGI+NcUK0bnDXk8QWcf+PsgDTfgXsZp5fQVxA1/YrvMCycDKXmtqFRY3V jDk1z2IeA4dUyzGRb9VCDh0Wp4DO/FE83sjEncs9Ssrnm7hDiISJ+0VmTwSjdEZfXmxqjRbU eJ41mu0kQ5MszFWujVmGphvHJLSehVsNnYUbSJVrG5ahQcByLb5LoSU7bma/l1hnH97+Jx1q H6iNJfZfra0b1P4L/28ZBo3/b7f10v77GM8W7QIq+6/EXmSXHNuu6d9TMaBqEcvRRvEQdmC9 09jvNJpF7cAfPGayJQdEf9NptTutXDvwya3p3lAbl2ABnsTn3oR12dhH67LW7DQPcq3LAT0L +9ZkMQbVJZxfSJXZQe7pBgRtKbUygaE0CpdG4Qc2Cis1F1oHgCNMtD9O6mRo/2nhvnmww8Y/ gL3b1PxODkICX4/seXjsOefbdGptjuzEdZICPSIv6/U6XStf4n6C5jJAaSC4irJq6KzGnrFq DT2s0VTWsOZjgGOjoxt52DjDmKe2awOOA1pliZOq6PMQ9ua4cGoHY1aYthlHBiDZahy9luzG KQvQcsNx0vCTYzyWcSsPGQkDUY4dtwAybkfK6lkCUzPLJixY5hVm4SSdMwzDIt0R/Rh4Ethh To5BLx7TXsrGCbl3h5E9GQfFDcqxRTkxlKU2ZdpoinYUv+3CopJqIFVBjbfdTFoNJLNwcGtf zx2dbJQzEFFuVYOwae6Q0Uhp9Ogvi3Oc+ebN1CTBvQv6PrCDK+/6mheaQWD52IvfSBRDpKoQ IjNN2ssQdDSCAzi+gfOx8E7okc6sDia8U7g9OKFGo1wjMSicK6r1YzuaLLg7krSo7GbQb6L2 B6i5SKwLZOcCGDFVOg52zPFHjJ0CmUyWgnwlRBQiZcwq2zAD89wgPeDkOjYnfH8KDMb0P1sY QiLIxg+QypSk1VIxqrKtaV+0NJnVg9f2r1/YvAIetkNOzAiDCYkKPwpbhYYWyMgkGqhvuebU ikilHls4l/JYgCHtGudT6L1NLTGwFarav+3XBKsO4nIQl464qvbeQU0YNzxfEcPBa1ayi385 uzrFJjbkhA19jQvjAWbbgPBXPHzYAfuTzGk2YbvLdi10qQlI9WBXb+82jF1QXsgBNSV9Uho2 b9JxnbLTnMHhvspE35OhQ4qMx0iRL69FmF+/JlkH6JYCqX7dO4hlMouOy5gItrI+bARCMlLV jX12LPivjpSKyJkjMhuQjfZ6IphlE9SKDKfie0qfiIZ8vakyWhbAUluZStBATKTxrQdHCVwa GXNl7G7+eYTj0mrZCjSDiDlmVwlGZXhVd4JaXhXdyLe3PoWtT/XAWG3HrsOIHq6NfPufoaOx T9tvwf/aDQqnG0ZbK+1/j/EM76ezW8+9J73TLqle1AgejKlXHEbr7w3t6cIxcfP4wZssYJPw ++3EOd8hv4fGljoewhe2M/mboY/qlciGhyY8Cbf+5s3+Lhq76qQLCo8CBbCwwg7wzprUKxeW ObHdG7IHiyw2C1xpaHsj290LOJo6HjLh9FnpcwPYKzzLvXrx4ggOrH8ffv5w/v7j4DO0tQeH wz0s22OHvfspqfqA3nOd+1pcG2OGeG0aPgRwUS+W4NuTT5d7M9+e1qHjlXMT6AL1z83xV1Bo HR8WGm9K/gXnVdeCzu+NvenUc/fYe2oV7bT0yh8+HDqx2bAjHCBGvGrHhEiq4pXjUc2t77AP zhwXOfYm90sGd4XywkfYyh7h1QhQ0TZ6vu/5QYcAR/1h+i5Aww99h/QccxZYE3JpTy0o1W47 mjaF/wcd7UCbBpWShbfKwhtxWsgnPXqS74wcb0y3jZxHwt+MLRoqxg9B0ji7glkgwlxl9oGa uoVmbgtXrO66zNcume95MV9UeQVm4gwa2ZQ4+0j+qk6zrWCfEGQJg4ZgSQaVW2jt57UgMujm OjxNnuQikyAOhixfJSkkveRyrBqEBLeEVhJsFX+NLHd8G72q5TSuFHG58as0xjVlXi9l/tnL fJrn1tALPAiZs52QxdRpNhX8xr3d+VzOgJL6QMTd1rJxb7hY7ZeM+0wZ9wH1eRoiyagPJD5U /7K22k1JeYcvl60cIdwqK0cIK6wc7FUtp+nsdSNq+iqJb91Vo1UKXyl8TyF8RqutEAF4u5r4 AeDq8gfAKwlg1PoyCcTWtyaCa69/vZ9ABJdt2rfFqOvIbGwfWlNjKBBk26DWVgx5rax2Gskh svIcmG/PePE39KEMaU5awH0cR0TXjJbBy6LMp4CVHbR5wTlzS1gBr9Q02mGdU9/GWLkIX0tr NCqnFk3m6nvmZA8kcOTxjNcMaTwIOm26IL5OP2R42b24JB/fkkuMjVRAVF6ztmk5RtgR1HHH Z5dDFb7lT+USZgOHhpmzzKuJCGkcU7pINw6yirjrU1HSMDLRZTaU2QxvRUU70huc5pHudYUr OBpHMvdmM4zsm3fIvrZP3EAszZ46be29zM+nSNN72MfbE/zMqnbJBj5zEvLV7Pa1cQO1p1oZ G40MZfym0c7QxbrR2i+qiw0QaGN9XUw10hFht/hEyupscBL9fdqL/x703gk19KI19KI19KI1 9NVrbFX/6vWW0SKLVTRwK+g01nZ6/awaWDrGlCr48VRw9gnu2ehgXT/Q3mTtiPezd8TNrB1x q1lYC+OO+M1WtDA+BfUwVd7F6xTW92to/DV0vlZc6/MqT6D3jbreWE3vN7Sg02wgi2w7TIzH fwW3W8YrPhj/td9qZcR/aVqrGeZ/tvWGRuO/tPL7T4/z/O2/CF2sR2ZwW6mgXW6mDlPKie8h //jH//Kqcr5n2l0rgIpXA0pvow9GxW/T9nt1YWhbVJQC1mTVhD85+T7yXyjfo5UgXUBboe8r 1vjWIy9fPlFc56pPmjzbb2NJ/Cf75hu9/3Nf1w0d4ButMv/7cZ4t5ulhQuHueLbYExPABf4K c8Avww0hjdHGJFD20ZhlOeAsPTo/B5wsvQy0TJYuk6XLZOkHTpbeavqvnOCLx6zcJF8JIHWx JAoInGHJ2d5HCglsSM56vV49ecZl4CEI1hffAxo4Y8KUhhmDyUspw17QMynfRkUYowIr/JAW c90mthE0kRCTrqczmn08kcuhmuiLJdJBGz8qgRyYRFgRsj9dejaXU0B17VCC+ePs9DLx0aj2 oQjw6QN+RC+ZekurUUz8WkQr/HCOHmajqtIhAVkylydZ39ioPiiTzToACDbsAehC/ijvEMur S5M36RVMyrqU6PK1oDyNNXXZIV9p6PTz6+LoZzAigOjOQ1aSvvGQSB9owzsDaPPpew5fSN/y i++1j1lhJ4Y5TsIYaZjPMowwpQLQf1JACkyUlALQzBIK2b0Iv6VoDxA8z5nqEqAg28xQOkYy GGcLK/KBHX4/KIZGpNJwaQZrxKQZbKJgszQSY0MkLM1N6Mr6SIzNkFjfZwBoTYrKrhJJMflN U3ZifQ/lF5Oybyw/1ZQ7YtfcrQSk5wHBudziuAQg4bI/ZLIJqn/cp0ys0eImlMCohL698q1g 4cx16fa2XI4UU7/hoTuRqkOvj8QtnnvzqvqS3VxBR/BSSrIWoSWOppmRtBTbqjL22KEdyKof tcbzLvWwtRcSmMyum7QTcgq0pGgnyYyrtBSle+KEhC9zJ8r4kSeKtWas0JrxA7EFb8fIa2cb 49k++y1tychrqciYEoweK6roBhN6EORXb7gLOAwy5GHadggGRaQKfO8srMy7r+PR5d15opCi OWyp1SsRbfCVj3e6xco/IWBRajkDptnkfMVgbxzvW/reAmyTfwb1lfZKmJlkknw8HKwiEla4 niRNV/5BL5hK2okgSVAs4wTVMyh6yIqNRye4Xojieprk+lKaMzD8gffmsnFW7drDzAO9HIx+ NjwxCdNgpD0cW49N379PXMleeC6WTAVvI8nEG8sExSt/f82+5q3RxtIfeWMgFD2/riEDSuq2 /uowWS5f1JDxLps96PXN67KIrmARvWSR6Nk2i6i+Fpjs9hOxSLwRpGYb/KS1yAd0709qwsRm aUl65QmrGN8DQ2/Ro58OIDxx311MR5Yv01M6fHYYaDW5L0zVMJQ1pH0D64E5mzn31JwJI4R9 B71mml2ukzIQ0c/aCQ0fJgCNJKAhA6ou92Yl0fEMDV6H8f1L7Gyn+BYlPfjzy9GStwzJ36Sk kFWKKH2BDHvE1sO/XxvxRU4hW6XuHCLS9e7R3o1OtDQnESPQu6Si9qRuJ7eRVfs1nH33QuD4 EFy1d/WaVCbfEETot1ZlHimCbEfElOKoIphqafGUSffN5Fcu6WR8P3YsViC8dYMYGI1l6D1h xzH2OmER6RwpjFCHIqihBI0ZVeyvdPrLuj0pdYgkinMkVR+4/Xim+mOL2qAU8scScty6ri/l z0o2+b2TKaviUQJJNHzfovbslyNzwrbwfH5exvekAeP5aC//xhLSUtuURPf2jtLNq/Ylku1O YBfGOxtrCL3UEKWG2KKG0EsNMWEnuB9PQ4TehCBgH6vk0s9Lo3+VhsS1Ipdj03CuUZGBpFyg IO70uzMhCpkPsrvKw34TjYcmz0QrK3Uw2XZO42EsMZztVhy96DdODDk8JVaZI7+2Usu4LVyz aT3RNKIq2ra+dtt6sm092XYGi+gli5QskssieskiJYvksoheskjJIvltr5UatGonceLxT/k7 n3hvNNkswUCRPLGlyPL4yY//bzZamhZ+/63Z1DWM/2832mX8/2M8WwzUzY3/j1J9MuL/Memu jP8v4//L+P8y/l/G+BeP/6cfg03G//P8wuwEAAaQmwGA95cKGQAxysrmKQAHh5W1UgDY1+bX j8Bn9dcPwOefRN+s/poB/OEnnR8sgB8bUAfwQwm39CUD+KNvRS8L4Kef6Mb38QeNUwH87CvH EkxMbAFGCLvnBBUKhbB7iWKPEna/lYD57YS6/8xB6g8R+rw8FHl7EcI58cHbDNrNCdndasQu 84mNfWuKikX0M0UgKKpQQDA+LOvDhPGwigaPYjBaVjRaFIuWrpcb65bgHHiwGRYoKrtmGBpl YBj7MiknDNSPfYhfeKAbDWpjvlLhs1OC0zAKX1O4CKEYkFa/SLGNcrQMLw87JxcKPdfkQssJ rGxMWh6mRDOSmzL5O+HEC8NpC4ZKTqxc3oPin5T3YsI8a95Lcsz6vJfk4ofnPdu9Q0dwhtK7 +yEZ7wUnOY088OaM68SXXJtX4WdtM/KZo0BNOyj44WnH5x+RhmRiwcbVUOKUsR98MDHVUSBI sphSWnLmFyA7DS7vK/IPnJ8k/yDWfGGkeZl7kGaPVO6B85PkHjwBe/w4eQdng5OniQpUBgUW jAlMWJjCmMAVQgLF7qwcGSiZKHIjAyXIHykycAuBgeF+QpyK5xgaKEcGyvYrdWBgMi4wLyww PimuGxuoCA1cNTJwjcBAtXY47ZXaodQO29QO/Pz+k2uH+Cz/Y2gH9qh1xKD3rtQRpY7Y6g7i rtQRoTHqx1cQ3ePhz6ggimUdlZphFc3ADYk/uWYAKnjO4q+gGvpPlrZc6oa/mm5wopTln1Yx OJtkKz8rrfBEqcqlVvgLagW91ArrZyg/olZA2X72aclyYCdPnXqAxGSpnYfKFzsbnBRInArj YVkWpZy0BZgK5Wyd9tZuOZGyBZgKtTzovVu7ZXnMgKlQy3AOXpva8pgBU6GW+8Wy88Smk9l5 /aLZef1i2Xly23qybVUCp1okt5/CWYpkKZKlSK4vkg+QVV2KZCmSpUiuLZIPcdFBKZKlSJYi ua5I6qVIliJZiuQzEkm9FMlSJEuRfCKR/AtdvvQMHuF6iCf6/nNjf7/RjO9/2m/S+5+08vvP j/Js8aKW8v6n/2/v7HkThoEwPJNfkbFDhybQgFSpQ7cO3bpXQmKo1C7Q/68SEzt2cjaO8kGC nldiAXM5HPvixHcP8J/gP8F/gv80BP8p+P/P6vOO9Keb//8z8CfgT8CfgD8BfwL+NAuWR2oJ +BPwJ61ljD3gT8CfKoF1AusE1ukisE5gncA6lQLrRAUVPCd4TvCcCAuAnCYLC4CcCA4EBwhO njUDBCciA5HB/kEQnCA4ERuIDRCcxMAAwYmoQFSA4LRMgpMxkiyV5EShH4V+145Mod+EhAom JBOSCTmbCUkpPBOSCTmfCQmbggnJhIRNEcemUD+lTBz9+jntb8J/yDZPRW74D/l2W/Iftus1 /IcpNGChtp//4IwvkQChWwzBgAABAQICBAQIiGUgIHTka0Ag9Ns+CIT1NQ8EwljQGAjbZBJG POxekljEQxxPoiIhaBfOl4Zwoby276ExGDv1lko/O+rmJlB03wPOYI4h4BnMZU+t5WxAw0P9 PRfRkEqMBqtf1Zboq9DTj3a7y1LSaVh3pdNSIxmkrkpGxjLUG5d6SLWaxJAbfIPAMeTujPUw FMNwkA1VlhbITHDb9EUniG2d8zPAIV2Qgti2zVOIPWgcVmGScs5VuFBvNYsKPbWn3C7NU29L NXlWKoRUq2mlCrhVeN6Mh+Ze9qp/IeaHcGJ/7/bEqnNZxbL6VN/DyW3kMbXnppPKJHahN5Mp tWQSmqr1mvOhe5kLZTIJSyxvttIsM3vGyvfzJPBUlx7d6XICj7BIclN43G+00mpaKTyH4/Fw vrU+nV/qcWggg0fPk7jUHW2nT87OqsyIMak5ddZOx2ecQ6XneI54cV3ZLp8ceDYv9EoraCt9 e/+Mfhoe+/uvK+KIl4/F25TWH801kgz9ztoP4lO19ZM/F+n+++8U2wcmEjYfgAc9zSRP826e ZvlufE8z0dNNN0+LzeiOZrKju5dQJl3b03Xe11P1/jV3M4+7WdFxCIw9VjOfp+uOg3Wgobq8 XSWEEEIIIYQQQgghhBBCCCGEEEIIIYTQFPoHlqdrwABoAQA= --pAwQNkOnpTn9IO2O-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 22:44:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbt-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:37 +0200 (CEST) Received: (qmail 22829 invoked by uid 0); 29 Jul 2002 20:35:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 29 Jul 2002 20:35:33 -0000 Received: by moria.seul.org (Postfix) id 6BF4D146809; Mon, 29 Jul 2002 16:35:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3ADDC146919; Mon, 29 Jul 2002 16:35:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id D995A146809 for ; Mon, 29 Jul 2002 16:35:31 -0400 (EDT) Received: from f-cpu.org (kdl14-100.n.club-internet.fr [213.44.12.100]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 0EB4516DF; Mon, 29 Jul 2002 22:35:29 +0200 (CEST) Message-ID: <3D45A940.10037112@f-cpu.org> Date: Mon, 29 Jul 2002 22:44:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Web and webmaster References: <3D44F7FD.6040607@yahoo.fr> <20020729162222.22776@thrai.stud.uni-hannover.de> <1027959965.3d456c9dcb72f@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > > On Mon, Jul 29, 2002 at 10:08:29AM +0200, Just an Illusion wrote: > > > We looking for a new webmaster (to replace Whygee). > > > Does he want to be replaced? > He take time to answer, but from what he say, I think that he never > whant any more to wrote a web site ;-) And that he really prefer VHDL. sure. And foremost : i am not a webmaster. i just fixed important things when nobody else was there. > > * The website MUST NOT move again. > I must be more clear, he must use seul ! question : - given the fragmentation of the sites and seul's convenience, - given the great difficulties of tuxfamily (mega technical failures, data loss etc.) - given devcon's costs and misconfiguration, would it be possible to move the DNS of f-cpu.org/net/com to seul.org ? and change of registrar (Gandi would be ok, but i don't know them much). IF THE FRENCH GUYZ DID WHAT THEY SAID THEY WOULD DO, THE FRENCH F-CPU ASSOCIATION WOULD HAVE ALREADY SOLVED THE DNS TROUBLES, AS WELL AS OTHERS (TRADE MARK PROTECTED IN EUROPE). BUT NO : CEDRIC AND NICO (TO NAME A FEW) LOST 6 MONTHS AND I STILL HAVE TO SOLVE THE PROBLEMS. THANKS GUYS. DO I HAVE TO MAKE THE ASSOCIATION MYSELF NOW ? > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 29 23:43:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbv-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:39 +0200 (CEST) Received: (qmail 18337 invoked by uid 0); 29 Jul 2002 21:33:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 29 Jul 2002 21:33:56 -0000 Received: by moria.seul.org (Postfix) id EC159146809; Mon, 29 Jul 2002 17:33:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D0CD0146919; Mon, 29 Jul 2002 17:33:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 8216E146815 for ; Mon, 29 Jul 2002 17:33:54 -0400 (EDT) Received: from f-cpu.org (kdl19-29.n.club-internet.fr [213.44.21.29]) by relay-5v.club-internet.fr (Postfix) with ESMTP id AC57316D1 for ; Mon, 29 Jul 2002 23:33:51 +0200 (CEST) Message-ID: <3D45B6EF.455A037F@f-cpu.org> Date: Mon, 29 Jul 2002 23:43:11 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> <3D3FEA3C.4070901@laposte.net> <1027960615.3d456f27547ca@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: > Quoting Thomas Lavergne : > > > >>> 6.1.2 `loadcons': > > >>> The jury is still discussing this. > > >> > > >>Ok, but you and thomas write the latest post, because nobody answer, I > > >>was thinking it was decided. > > > i am definitely against. > > I'm definitely for... > > Or for any other proposition that allow simple constant loading of any > > size. And thats not the case for your loadcons/loadconsx. > > So it's under discussion ;-) > > Yann the reason you give to me for not doing it is only that you need 3 times > more place for the version that Thomas want than for the one you whant, right > > But Thomas version is more scalable and orhtogonal. And in fact I don't see > that it cost so much. (I think you didn't explain completly your reason on > the mailing list, like you explain to me, so if you have time it would be a > good idea) * if you want to shift, use the shifter unit (SHL) : it's its job. The purpose of Xbar is not to shift. * a shifter takes more room than you would think. More room means decreased frequency and higher power consumption. Even though the shift is only 16 bits, remember that the "cost" is proportional to N*M (if M is the number of bits in the word and N is the shift amount). And even though there are several metal layers and better synthesizers, you can't modify this basic topological rule. i think that Michael's shifter will not match the speed of other units if he keeps wanting a single cycle shift. * The Xbar is already very loaded : - 4 bypass (2 write ports with 2 bypass nets each) - 3 read ports that must feed half a dozen of inputs - roughly 10 execution units (and still no FP in sight) - CIP, NIP; TLB, immediate data and i probably forget many things. In the beginning, Xbar was a place where we could do whatever we wanted but now it's proably as heavy and slow as the register set. Adding a shifter in this critical datapath would slow down the whole circuit. * Show me the proposed instruction form. Remark : the existing loadcons shifts the constant before use (not exactly, but it's the principle). it benefits >from the latency of the decoder and the Xbar (2 cycles are enough to amplify and select the right bits). The "shifting loadcons" does the reverse and the shifting cost is put in the critical datapath of the Xbar. And shifting has a cost (don't tell me "it's only a mux"). > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Mon Jul 29 23:27:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbw-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:40 +0200 (CEST) Received: (qmail 4596 invoked by uid 0); 29 Jul 2002 21:34:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 Jul 2002 21:34:25 -0000 Received: by moria.seul.org (Postfix) id A22C7146815; Mon, 29 Jul 2002 17:34:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8BF5114691E; Mon, 29 Jul 2002 17:34:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 41F7E146815 for ; Mon, 29 Jul 2002 17:34:24 -0400 (EDT) Received: from laposte.net (193.250.226.40) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB28C0011E39C for f-cpu@seul.org; Mon, 29 Jul 2002 23:34:23 +0200 Message-ID: <3D45B33A.6070000@laposte.net> Date: Mon, 29 Jul 2002 23:27:22 +0200 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New manual release (0.2.6) References: <1027355592.3d3c33c8c9ba4@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL wrote: > Change are : > - Reversing all the bits I'm not here when you have discussed this chage, and I think you have good reason for changing it, but what are these ? I love numbering : OPCODE FLAGS ... 0.............31 because if you flag was well assigned you ca make this for the assembling : ASM = OPCODE | (FLAGS << OPCODE_SIZE) | ... And you can use the same Flags constants for all opcode if they share the same flags. with the other order you can't because of the different flag space size if the different instruction format. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 00:13:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLby-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:42 +0200 (CEST) Received: (qmail 15221 invoked by uid 0); 29 Jul 2002 22:16:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 29 Jul 2002 22:16:43 -0000 Received: by moria.seul.org (Postfix) id 3B77C146809; Mon, 29 Jul 2002 18:16:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6D6914691B; Mon, 29 Jul 2002 18:16:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 97BE3146809 for ; Mon, 29 Jul 2002 18:16:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01987; Tue, 30 Jul 2002 00:13:58 +0200 Message-ID: <20020730001357.13732@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 00:13:57 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Control signals on the Xbar References: <3D4525CE.2040103@yahoo.fr> <20020729153242.37234.qmail@web14202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020729153242.37234.qmail@web14202.mail.yahoo.com>; from jaap stolk on Mon, Jul 29, 2002 at 08:32:42AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 08:32:42AM -0700, jaap stolk wrote: > hi, (i'm the one that caused al these problems :-) ) > > --- Just an Illusion wrote: > > Do you understand now the problem of non-definition > > of communication > > process between blocks ? > > Do you understand now, the necessity to clearly > > define the block > > interface and the communication protocols ? > > centenary, an accurate and fixed description of each > units interface would be helpful, however > we will never have that till the F-CPU is completely > designed, implemented, and tested. > it will always we necessary to keep changing > what part belongs to witch unit, and the > communication between the units will we changed now > and than, if it could make both units less > complicated (think transistor count, timing, fan-out, > etc. ) At least for the EUs, the interface and communication protocol should be pretty clear: - There's an input register between the Xbar and the EU. - There are output registers between the EU and the Xbar. - There's an `enable' flipflop in front of each EU. - When an instruction is issued, operands and flags are clocked into the input register, and '1' is clocked into the enable flipflop. - When no instruction is issued, '0' is clocked into the enable flipflop. Contents of the input register are unspecified (ideally, the values remain unchanged, to save power). - Both data and the enable signal `move' through the stages of the EU in a wave-like fashion. Inactive stages may remain quiet, controlled by the propagated enable signal (ideally, their outputs will remain stable as well). - When data is ready at the output port(s), it is clocked into the output register(s). If a port has a latency of cycles, and data is written to the input register at cycle , its corresponding output register will be written at cycle . - Whether or not the value of an output register changes in other clock cycles is unspecified. It may stay unchanged until the next valid result appears. On the other hand, an EU is allowed to ignore the enable bits and `work full-time'. In that case, a valid result will be available at the output register(s) only for a single clock period. Note that input/output registers and the enable flipflop are NOT part of the EU entities. There also are no `output enable' signals currently; the scheduler is supposed to know when the result arrives, and at which port. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 29 19:53:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbz-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:43 +0200 (CEST) Received: (qmail 4288 invoked by uid 0); 29 Jul 2002 22:16:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 29 Jul 2002 22:16:45 -0000 Received: by moria.seul.org (Postfix) id 0F6AE146919; Mon, 29 Jul 2002 18:16:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC735146920; Mon, 29 Jul 2002 18:16:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id CE1C6146919 for ; Mon, 29 Jul 2002 18:16:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01288; Mon, 29 Jul 2002 19:53:14 +0200 Message-ID: <20020729195313.32076@thrai.stud.uni-hannover.de> Date: Mon, 29 Jul 2002 19:53:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Web and webmaster References: <3D44F7FD.6040607@yahoo.fr> <20020729162222.22776@thrai.stud.uni-hannover.de> <1027959965.3d456c9dcb72f@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027959965.3d456c9dcb72f@imp.free.fr>; from Cedric BAIL on Mon, Jul 29, 2002 at 06:26:05PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 06:26:05PM +0200, Cedric BAIL wrote: > > On Mon, Jul 29, 2002 at 10:08:29AM +0200, Just an Illusion wrote: > > > We looking for a new webmaster (to replace Whygee). > > > Does he want to be replaced? > He take time to answer, but from what he say, I think that he never > whant any more to wrote a web site ;-) And that he really prefer VHDL. Me too. [...] > > * (S)he MUST speak English. > > Of coure, but are your sure that we have a chance for the "s" ? ;-D It's an optional feature... ;) > > * The website MUST NOT move again. > I must be more clear, he must use seul ! Yep. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jul 29 19:50:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLbz-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:43 +0200 (CEST) Received: (qmail 17129 invoked by uid 0); 29 Jul 2002 22:16:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 29 Jul 2002 22:16:51 -0000 Received: by moria.seul.org (Postfix) id 36CD014691E; Mon, 29 Jul 2002 18:16:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01949146922; Mon, 29 Jul 2002 18:16:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id C880C14691E for ; Mon, 29 Jul 2002 18:16:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01277; Mon, 29 Jul 2002 19:50:57 +0200 Message-ID: <20020729195056.45744@thrai.stud.uni-hannover.de> Date: Mon, 29 Jul 2002 19:50:56 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store References: <1027689495.3d414c17bd2c6@imp.free.fr> <20020726174621.46397@thrai.stud.uni-hannover.de> <1027959267.3d4569e3ddd3c@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1027959267.3d4569e3ddd3c@imp.free.fr>; from Cedric BAIL on Mon, Jul 29, 2002 at 06:14:27PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 06:14:27PM +0200, Cedric BAIL wrote: > Quoting Michael Riepe : > > > On Fri, Jul 26, 2002 at 03:18:15PM +0200, Cedric BAIL wrote: > > > Why didn't we have conditionnal load and store. I mean somtehing like > > > storez, storenz, loadz, loadnz, ... It can be really usefull and we can do > > > with that all what we can do with predicate I think. > > > Conditional load/store makes less sense than you may think. When an > > address is loaded into a register, the prefetch cycle begins, whether > > or not memory is actually accessed. Thus, there will be no increase in > > memory bandwidth due to the use of conditional load/store. > > Arf, I forgot prefetch... A conditional prefetch, is it possible ? ;-D > > That not so stupid in fact. We have our strange cachemm instruction (I > mean what did you think about : cachemmlcV, it's fun but have no sense...) > So why not changing it, so that we have a conditionnal cachemm. In that case > we need 2 more bits to define a register and 3 more for the test. And for > loadaddr we have 11 unused bits, so we can have a conditionnal loadaddr too. > I think that taking vacancy are not so good, I have crazy idea when I came back > ;-) What is a conditional loadaddr supposed to do if the condition is false? Cachemm is really strange (as well as serialize). I prefer not to think about it ;) > Now back to what you say, I was thinking that we make the test at start > (before sending the job to the LSU), but if I correctly understand, we send > all and make the test at the same time, right ? That's strange. If I remember correctly, the read operation of a conditional move will be executed (because it is done at decode time) but the corresponding write operation will never happen. This has nothing to do with the LSU, however (the LSU is only used for memory load/store, not for moves). > > The only positive effect ist that CL/S will avoid some jumps. That is, > > in the rare case that you have code like > > > > if (condition) { > > *pointer = expression; > > } > > > > with no preset and no else clause (or a volatile memory location), > > and with a trivial expression (something that is already present in a > > register, or can be computed with few additional instructions). If > > the computation of the expression becomes more complex, a jump is the > > better choice. As soon as other statements precede or follow the assignment > > (inside the if clause), it is a must anyway. > > If think that a jump could be a good solution actually because we only issue > one instruction per cycle, but what append if we issue more instructions ? > I mean that of course we make reflexion for our ISA with big register, but > we have the same reflexion with number of instructions per cycle. That depends on the architecture. We can define `packets' of two, four or even more instructions that are executed in parallel (that is, Itanium-style EPIC), or a `stream' model that takes and executes as many instructions as possible. In either case, jumps need special handling. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 00:31:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLc1-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:45 +0200 (CEST) Received: (qmail 4676 invoked by uid 0); 29 Jul 2002 22:31:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 29 Jul 2002 22:31:28 -0000 Received: by moria.seul.org (Postfix) id 2DB2C146809; Mon, 29 Jul 2002 18:31:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5E5B14691B; Mon, 29 Jul 2002 18:31:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 0A6DF146809 for ; Mon, 29 Jul 2002 18:31:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02206; Tue, 30 Jul 2002 00:31:27 +0200 Message-ID: <20020730003127.54696@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 00:31:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027584579.3d3fb243503a7@imp.free.fr> <3D3FE671.C0B1691@f-cpu.org> <3D3FEA3C.4070901@laposte.net> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D45B6EF.455A037F@f-cpu.org>; from Yann Guidon on Mon, Jul 29, 2002 at 11:43:11PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 11:43:11PM +0200, Yann Guidon wrote: [...] > * if you want to shift, use the shifter unit (SHL) : it's its job. > The purpose of Xbar is not to shift. That's right. `loadconsp' shifts are supposed to happen elsewhere, though. > * a shifter takes more room than you would think. More > room means decreased frequency and higher power consumption. > Even though the shift is only 16 bits, remember that > the "cost" is proportional to N*M (if M is the number of > bits in the word and N is the shift amount). > And even though there are several metal layers and better > synthesizers, you can't modify this basic topological rule. > i think that Michael's shifter will not match the speed of > other units if he keeps wanting a single cycle shift. I remember that the synthesis report was encouraging. > * The Xbar is already very loaded : > - 4 bypass (2 write ports with 2 bypass nets each) > - 3 read ports that must feed half a dozen of inputs > - roughly 10 execution units (and still no FP in sight) > - CIP, NIP; TLB, immediate data > and i probably forget many things. > In the beginning, Xbar was a place where we could do > whatever we wanted but now it's proably as heavy and > slow as the register set. Adding a shifter in this > critical datapath would slow down the whole circuit. The shifter itself is outside the CDP. There's only a MUX inside the CDP, and you'll need that for partial writes as well. > * Show me the proposed instruction form. Didn't I? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 01:04:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLc1-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:45 +0200 (CEST) Received: (qmail 22218 invoked by uid 0); 29 Jul 2002 23:04:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 29 Jul 2002 23:04:37 -0000 Received: by moria.seul.org (Postfix) id 9A5C2146809; Mon, 29 Jul 2002 19:04:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73C1514691B; Mon, 29 Jul 2002 19:04:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a164.home.uni-hannover.de [130.75.232.164]) by moria.seul.org (Postfix) with ESMTP id 768D2146809 for ; Mon, 29 Jul 2002 19:04:32 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02368; Tue, 30 Jul 2002 01:04:30 +0200 Message-ID: <20020730010430.29967@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 01:04:30 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020729184813.GB948@free.fr>; from Etienne LABARRE on Mon, Jul 29, 2002 at 08:48:13PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Jul 29, 2002 at 08:48:13PM +0200, Etienne LABARRE wrote: > Hi all, > > New snapshot include a lot of changes and features : > > INC unit and CMP unit are now two different units, for simplify and > decrease latency > > Both units are based to the same component : find_lsb > It's a binary tree for find the first null lsb in a word. > It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 > bits) > It's based to only one function : and_reduce. It's is a standard > function of ieee.std_logic_1164 library. Did you find source code or documentation for package std_logic_misc? I noted that you use ieee.numeric_std in your designs, which is a no-no. Or did you include it by mistake? > Latency of find_lsb is not exactly know, but i can estimate this > to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of > 8-and, and 1 level of mux. The precise latency is not important, > because max latency will be fixed by timing constraints during synthetisis process. > (It's an explain of my choice of standard function. "Just an > Illusion" > will can explain this more easy that me, i think...) I'm afraid that a timing constraint will `blow up' the unit. BTW: for 256 bits, you need *four* levels of 4-and. > For INC unit, the data flow is : > 1 level of mux > find_lsb : 3 level of 4-and, 1 level of mux > 1 level of xor > 2 level of mux > total is 8 levels. > Critical datapath is only for ABS operation. > > Supported operations : > INC, DEC, NEG, ABS, LSB0, LSB1 > > All operations are tested by my testbenches. > > For CMP unit, the data flow is : > 1 level of xor, > 1 level of mux, > find_lsb : 3 level of 4-and, 1 level of mux > 2 level of mux, > total is 8 levels. > Critical datapath is for CMP, MIN, MAX, SORT operations. I doubt that you can get away with 8 cycles. From my experience, 64-bit CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jul 30 01:18:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLc2-0008Ml-01 for ; Tue, 30 Jul 2002 03:15:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:46 +0200 (CEST) Received: (qmail 1243 invoked by uid 0); 29 Jul 2002 23:21:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 29 Jul 2002 23:21:38 -0000 Received: by moria.seul.org (Postfix) id 484EC146809; Mon, 29 Jul 2002 19:21:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E710146919; Mon, 29 Jul 2002 19:21:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 588BD146809 for ; Mon, 29 Jul 2002 19:21:36 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-209.jetnet.ab.ca [207.34.60.209]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6TNLYh1061558 for ; Mon, 29 Jul 2002 17:21:35 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D45CD3B.5040204@jetnet.ab.ca> Date: Mon, 29 Jul 2002 17:18:19 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > > I doubt that you can get away with 8 cycles. From my experience, 64-bit > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, > 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. > But would not CMP be better defined like the add operation One cycle for small operands Two cycles for full compare ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 01:53:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLc3-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:47 +0200 (CEST) Received: (qmail 19581 invoked by uid 0); 29 Jul 2002 23:44:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 29 Jul 2002 23:44:06 -0000 Received: by moria.seul.org (Postfix) id 49F39146815; Mon, 29 Jul 2002 19:44:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B2DC14691B; Mon, 29 Jul 2002 19:44:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id B152A146815 for ; Mon, 29 Jul 2002 19:44:04 -0400 (EDT) Received: from f-cpu.org (kdl4-14.n.club-internet.fr [213.44.3.14]) by relay-3v.club-internet.fr (Postfix) with ESMTP id BC6141692 for ; Tue, 30 Jul 2002 01:44:00 +0200 (CEST) Message-ID: <3D45D56F.FC1F5B53@f-cpu.org> Date: Tue, 30 Jul 2002 01:53:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <3D45CD3B.5040204@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi all, Ben Franchuk wrote: > Michael Riepe wrote: > > I doubt that you can get away with 8 cycles. From my experience, 64-bit > > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, > > 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. > > > But would not CMP be better defined like the add operation > One cycle for small operands > Two cycles for full compare i believe (for a few months when the evidences became so obvious) that this idea creates problems, at least for the "common" operations (MUL is another case). i think i'll drop the special case of 1-cycle for 8-bit add/sub (and thus for cmp). the reason is the Xbar structure which already has too many ports. Furthermore, the layout could become too complex because units should try to share input and output ports. Having an output port in the middle of a unit (ie : ASU) reduces the opportunities to share that port with another unit. it's probably not clear yet but the conclusion is that variable latency is not good for the small units (CMP, ASU, SHL) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 01:57:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZLc4-0008Ml-00 for ; Tue, 30 Jul 2002 03:15:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 03:15:48 +0200 (CEST) Received: (qmail 8468 invoked by uid 0); 29 Jul 2002 23:47:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 29 Jul 2002 23:47:52 -0000 Received: by moria.seul.org (Postfix) id 9927B146919; Mon, 29 Jul 2002 19:47:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A62B14691E; Mon, 29 Jul 2002 19:47:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 35443146919 for ; Mon, 29 Jul 2002 19:47:46 -0400 (EDT) Received: from f-cpu.org (kdl4-14.n.club-internet.fr [213.44.3.14]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 0118F16A0 for ; Tue, 30 Jul 2002 01:47:44 +0200 (CEST) Message-ID: <3D45D64F.1FD92C51@f-cpu.org> Date: Tue, 30 Jul 2002 01:57:03 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Mon, Jul 29, 2002 at 08:48:13PM +0200, Etienne LABARRE wrote: > > Hi all, > > New snapshot include a lot of changes and features : > > > > INC unit and CMP unit are now two different units, for simplify and > > decrease latency > > > > Both units are based to the same component : find_lsb > > It's a binary tree for find the first null lsb in a word. > > It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 > > bits) > > It's based to only one function : and_reduce. It's is a standard > > function of ieee.std_logic_1164 library. > > Did you find source code or documentation for package std_logic_misc? > > I noted that you use ieee.numeric_std in your designs, which is a > no-no. Or did you include it by mistake? hmmm... this remembers me of the story.... what do we decide ? JaI is pretty optimistic. > > For CMP unit, the data flow is : > > 1 level of xor, > > 1 level of mux, > > find_lsb : 3 level of 4-and, 1 level of mux > > 2 level of mux, > > total is 8 levels. > > Critical datapath is for CMP, MIN, MAX, SORT operations. > > I doubt that you can get away with 8 cycles. From my experience, 64-bit > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, > 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. don't forget the wiring delays either ! running a wire from bit 0 to bit 63 will take nearly a cycle, so from 0 to 255 will take 4 cycles :-/ > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 30 09:30:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZSHE-0004jM-01 for ; Tue, 30 Jul 2002 10:22:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 10:22:44 +0200 (CEST) Received: (qmail 5666 invoked by uid 0); 30 Jul 2002 07:31:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 30 Jul 2002 07:31:07 -0000 Received: by moria.seul.org (Postfix) id 663BF146815; Tue, 30 Jul 2002 03:31:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 41C4014691B; Tue, 30 Jul 2002 03:31:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 7402B146815 for ; Tue, 30 Jul 2002 03:31:05 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207300730.38e4; Tue, 30 Jul 2002 07:30:56 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] New snapshot for EU_INC and EU_CMP From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2002 07:30:56 GMT Message-id: <200207300730.38e4@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Etienne LABARRE A: f-cpu english ML Date: 29/07/02 Objet: [f-cpu] New snapshot for EU_INC and EU_CMP Hi all, New snapshot include a lot of changes and features : INC unit and CMP unit are now two different units, for simpl= ify and decrease latency Both units are based to the same component : find_lsb It's a binary tree for find the first null lsb in a word. It supports SIMD operations (size of chunk =3D 8, 16, 32, 6= 4, 128, 256 bits) >>>> ??? oups ! I think we will go to ever more confusing. F= -cpu should always have 5 chunk size (8-16-32-64&128( for future long do= uble)) and should have some instruction for the whole register like you= 're 256 bits (which is in fact all the bits). So chunk are 5 and fixed (i= ntra-chunk operation) but the register size are not fixed and we need i= nter-chunk operation (where the *number* of chunk isn't given). nicO =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 30 09:49:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZSHG-0004jM-01 for ; Tue, 30 Jul 2002 10:22:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 10:22:46 +0200 (CEST) Received: (qmail 14229 invoked by uid 0); 30 Jul 2002 07:49:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 30 Jul 2002 07:49:14 -0000 Received: by moria.seul.org (Postfix) id 57A46146815; Tue, 30 Jul 2002 03:49:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 27AD614691B; Tue, 30 Jul 2002 03:49:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id AB679146815 for ; Tue, 30 Jul 2002 03:49:12 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207300749.0233; Tue, 30 Jul 2002 07:49:02 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] superscalar From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2002 07:49:02 GMT Message-id: <200207300749.0233@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 30/07/02 Objet: Re: [f-cpu] Conditionnal Load and Store On Mon, Jul 29, 2002 at 06:14:27PM +0200, Cedric BAIL wrote: > Quoting Michael Riepe : >=20 > > On Fri, Jul 26, 2002 at 03:18:15PM +0200, Cedric BAIL wr= ote: > > > Why didn't we have conditionnal load and store. I mean= somtehing like > > > storez, storenz, loadz, loadnz, ... It can be really u= sefull and we can do > > > with that all what we can do with predicate I think. >=20 > > Conditional load/store makes less sense than you may thi= nk. When an > > address is loaded into a register, the prefetch cycle be= gins, whether > > or not memory is actually accessed. Thus, there will be = no increase in > > memory bandwidth due to the use of conditional load/stor= e. >=20 > Arf, I forgot prefetch... A conditional prefetch, is it po= ssible ? ;-D >=20 > That not so stupid in fact. We have our strange cachemm in= struction (I > mean what did you think about : cachemmlcV, it's fun but h= ave no sense...) > So why not changing it, so that we have a conditionnal cac= hemm. In that case > we need 2 more bits to define a register and 3 more for th= e test. And for > loadaddr we have 11 unused bits, so we can have a conditio= nnal loadaddr too. > I think that taking vacancy are not so good, I have crazy = idea when I came back > ;-) What is a conditional loadaddr supposed to do if the conditi= on is false? Cachemm is really strange (as well as serialize). I prefer n= ot to think about it ;) > Now back to what you say, I was thinking that we make the = test at start=20 > (before sending the job to the LSU), but if I correctly un= derstand, we send > all and make the test at the same time, right ? That's str= ange. If I remember correctly, the read operation of a conditional= move will be executed (because it is done at decode time) but the corr= esponding write operation will never happen. This has nothing to do wi= th the LSU, however (the LSU is only used for memory load/store, not for= moves). > > The only positive effect ist that CL/S will avoid some j= umps. That is, > > in the rare case that you have code like > > > > if (condition) { > > *pointer =3D expression; > > } > >=20 > > with no preset and no else clause (or a volatile memory = location), > > and with a trivial expression (something that is already= present in a > > register, or can be computed with few additional instruc= tions). If > > the computation of the expression becomes more complex, = a jump is the > > better choice. As soon as other statements precede or fo= llow the assignment > > (inside the if clause), it is a must anyway. >=20 > If think that a jump could be a good solution actually bec= ause we only issue > one instruction per cycle, but what append if we issue mor= e instructions ? > I mean that of course we make reflexion for our ISA with b= ig register, but > we have the same reflexion with number of instructions per= cycle. That depends on the architecture. We can define `packets' of= two, four or even more instructions that are executed in parallel= (that is, Itanium-style EPIC), or a `stream' model that takes and exec= utes as many instructions as possible. In either case, jumps need special= handling. >>>> A vliw like instructions using 64 bits alignement, inst= ruction of 32 and 64 bits, and 2 registers adress for reading register = and one for writing in each 32 bits instructions chunk (inside the 64 bi= ts). >>>>So we can use true 4r2w instructions and we could give e= xplicitely the name of the 6 registers. We could have a true MAC operat= ion (without the udge latency). Most of the unit are 2r1w so most of the = time the pipeline will issue 2 instructions per cycle. >>>> The 64 bits op must be 64 bits aligned to avoid shift. = And the use of 4r2w operation could even raised the cpi without the prob= lem of coherency and other dependancies when you use superscalar te= chnique. >>>> you could have instruction as MMAC (MegaMAC [sorry]) th= at perform x =3D a*b + c*d. so 2 mul and 1 add in one instruction. >>>Does i dream ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 30 10:23:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZSTg-0004t1-00 for ; Tue, 30 Jul 2002 10:35:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 10:35:36 +0200 (CEST) Received: (qmail 26429 invoked by uid 0); 30 Jul 2002 08:23:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 30 Jul 2002 08:23:33 -0000 Received: by moria.seul.org (Postfix) id F307E146815; Tue, 30 Jul 2002 04:23:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AEB9014691B; Tue, 30 Jul 2002 04:23:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 0C444146815 for ; Tue, 30 Jul 2002 04:23:30 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207300823.14f0; Tue, 30 Jul 2002 08:23:20 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Control signals on the Xbar From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2002 08:23:20 GMT Message-id: <200207300823.14f0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N find the >>>> -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 30/07/02 Objet: Re: [f-cpu] Control signals on the Xbar On Mon, Jul 29, 2002 at 08:32:42AM -0700, jaap stolk wrote: > hi, (i'm the one that caused al these problems :-) ) >=20 > --- Just an Illusion wrote: > > Do you understand now the problem of non-definition > > of communication=20 > > process between blocks ? > > Do you understand now, the necessity to clearly > > define the block=20 > > interface and the communication protocols ? >=20 > centenary, an accurate and fixed description of each > units interface would be helpful, however > we will never have that till the F-CPU is completely > designed, implemented, and tested. > it will always we necessary to keep changing > what part belongs to witch unit, and the > communication between the units will we changed now > and than, if it could make both units less > complicated (think transistor count, timing, fan-out, > etc. ) At least for the EUs, the interface and communication protoc= ol should be pretty clear: - There's an input register between the Xbar and the EU. - There are output registers between the EU and the Xbar. - There's an `enable' flipflop in front of each EU. - When an instruction is issued, operands and flags are clo= cked into the input register, and '1' is clocked into the enab= le flipflop. - When no instruction is issued, '0' is clocked into the en= able flipflop. Contents of the input register are unspecified (ideally, the values remain unchanged, to save power). - Both data and the enable signal `move' through the stages= of the EU in a wave-like fashion. Inactive stages may remain= quiet, controlled by the propagated enable signal (ideally, thei= r outputs will remain stable as well). - When data is ready at the output port(s), it is clocked i= nto the output register(s). If a port has a latency of cy= cles, and data is written to the input register at cycle , i= ts corresponding output register will be written at cycle . - Whether or not the value of an output register changes in other clock cycles is unspecified. It may stay unchanged until the next valid result appears. On the other hand, a= n EU is allowed to ignore the enable bits and `work full-ti= me'. In that case, a valid result will be available at the out= put register(s) only for a single clock period. Note that input/output registers and the enable flipflop are= NOT part of the EU entities. There also are no `output enable' signals c= urrently; the scheduler is supposed to know when the result arrives, and a= t which=20 port. >>> I don't like that so much because the scheduler must kno= wn the exact behavior of the unit or try to simulate it. In either case, = this task should be done but the unit "known" much more than the sched= uler about it's own scheduling. (imagine load&store, multi-cycle operat= ion that are pipeline,...). >>>I know that the whygee will. Because he think that for to= pology reason this "simulation" of timing beavior must be done very= close to the scheduler it-self to avoid long wire. From my point of v= iew it's only a place&route problem and spliting desing from a routin= g point of view could became a real mess in the future when things get = bigger.=20 nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jul 30 10:26:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZSTh-0004t1-00 for ; Tue, 30 Jul 2002 10:35:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 10:35:37 +0200 (CEST) Received: (qmail 16424 invoked by uid 0); 30 Jul 2002 08:26:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 30 Jul 2002 08:26:14 -0000 Received: by moria.seul.org (Postfix) id 0C9EA146815; Tue, 30 Jul 2002 04:26:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4A0214691B; Tue, 30 Jul 2002 04:26:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 19254146815 for ; Tue, 30 Jul 2002 04:26:13 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207300826.0050; Tue, 30 Jul 2002 08:26:00 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] New snapshot for EU_INC and EU_CMP From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2002 08:26:00 GMT Message-id: <200207300826.0050@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 30/07/02 Objet: Re: [f-cpu] New snapshot for EU_INC and EU_CMP hi, Michael Riepe wrote: > On Mon, Jul 29, 2002 at 08:48:13PM +0200, Etienne LABARRE = wrote: > > Hi all, > > New snapshot include a lot of changes and features : > > > > INC unit and CMP unit are now two different units, for s= implify and > > decrease latency > > > > Both units are based to the same component : find_lsb > > It's a binary tree for find the first null lsb in a wor= d. > > It supports SIMD operations (size of chunk =3D 8, 16, 3= 2, 64, 128, 256 > > bits) > > It's based to only one function : and_reduce. It's is a= standard > > function of ieee.std_logic_1164 library. >=20 > Did you find source code or documentation for package std_= logic_misc? >=20 > I noted that you use ieee.numeric_std in your designs, whi= ch is a > no-no. Or did you include it by mistake? hmmm... this remembers me of the story.... what do we decide ? JaI is pretty optimistic. > > For CMP unit, the data flow is : > > 1 level of xor, > > 1 level of mux, > > find_lsb : 3 level of 4-and, 1 level of mux > > 2 level of mux, > > total is 8 levels. > > Critical datapath is for CMP, MIN, MAX, SORT operations= . >=20 > I doubt that you can get away with 8 cycles. From my exper= ience, 64-bit > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 lev= el of 2-xor, > 1 level of 2-and plus 3 levels of 4-or, giving a total of = 9 levels. don't forget the wiring delays either ! running a wire from bit 0 to bit 63 will take nearly a cycle= , so from 0 to 255 will take 4 cycles :-/ >>>> Where did you find those numbers ? nicO > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 10:50:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZTvY-00066F-00 for ; Tue, 30 Jul 2002 12:08:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 12:08:28 +0200 (CEST) Received: (qmail 3468 invoked by uid 0); 30 Jul 2002 09:00:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 30 Jul 2002 09:00:18 -0000 Received: by moria.seul.org (Postfix) id 2FC9A146815; Tue, 30 Jul 2002 05:00:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1602714691B; Tue, 30 Jul 2002 05:00:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 7A9C7146815 for ; Tue, 30 Jul 2002 05:00:16 -0400 (EDT) Received: (qmail 72038 invoked by uid 85); 30 Jul 2002 08:57:17 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.461076 secs); 30 Jul 2002 08:57:17 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 08:57:16 -0000 Message-ID: <3D465364.8040000@yahoo.fr> Date: Tue, 30 Jul 2002 10:50:44 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: >On Mon, Jul 29, 2002 at 08:48:13PM +0200, Etienne LABARRE wrote: > >>Hi all, >> >>New snapshot include a lot of changes and features : >> >>INC unit and CMP unit are now two different units, for simplify and >>decrease latency >> >>Both units are based to the same component : find_lsb >> It's a binary tree for find the first null lsb in a word. >> It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 >> bits) >> It's based to only one function : and_reduce. It's is a standard >> function of ieee.std_logic_1164 library. >> > >Did you find source code or documentation for package std_logic_misc? > The source code, of course. If some one need it, I can send it. Like Whygee has previously said me this is not a ieee package (it's copyrighted Synopsis), it is why I have never said than it is a normalized package of ieee. But in the header of the package, Synopsis give right to use this package without restriction. > > >I noted that you use ieee.numeric_std in your designs, which is a >no-no. Or did you include it by mistake? > >> Latency of find_lsb is not exactly know, but i can estimate this >> to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of >> 8-and, and 1 level of mux. The precise latency is not important, >> because max latency will be fixed by timing constraints during synthetisis process. >> (It's an explain of my choice of standard function. "Just an >> Illusion" >> will can explain this more easy that me, i think...) >> > >I'm afraid that a timing constraint will `blow up' the unit. >BTW: for 256 bits, you need *four* levels of 4-and. > If your target techno have it. More the timing can change if your target techno have native 8-and or more. > >>For INC unit, the data flow is : >> 1 level of mux >> find_lsb : 3 level of 4-and, 1 level of mux >> 1 level of xor >> 2 level of mux >> total is 8 levels. >> Critical datapath is only for ABS operation. >> >> Supported operations : >> INC, DEC, NEG, ABS, LSB0, LSB1 >> >> All operations are tested by my testbenches. >> >>For CMP unit, the data flow is : >> 1 level of xor, >> 1 level of mux, >> find_lsb : 3 level of 4-and, 1 level of mux >> 2 level of mux, >> total is 8 levels. >> Critical datapath is for CMP, MIN, MAX, SORT operations. >> > >I doubt that you can get away with 8 cycles. From my experience, 64-bit >CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, >1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 11:05:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZTvZ-00066F-00 for ; Tue, 30 Jul 2002 12:08:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 12:08:29 +0200 (CEST) Received: (qmail 12206 invoked by uid 0); 30 Jul 2002 09:14:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 30 Jul 2002 09:14:49 -0000 Received: by moria.seul.org (Postfix) id 89132146919; Tue, 30 Jul 2002 05:14:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 652AE14691E; Tue, 30 Jul 2002 05:14:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id ACD7C146919 for ; Tue, 30 Jul 2002 05:14:46 -0400 (EDT) Received: (qmail 72600 invoked by uid 85); 30 Jul 2002 09:11:49 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 1.697899 secs); 30 Jul 2002 09:11:49 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 09:11:47 -0000 Message-ID: <3D4656CB.9060504@yahoo.fr> Date: Tue, 30 Jul 2002 11:05:15 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, Etienne LABARRE wrote: >Hi all, > >The precise latency is not important, > because max latency will be fixed by timing constraints during synthetisis process. > (It's an explain of my choice of standard function. "Just an > Illusion" > will can explain this more easy that me, i think...) > In many synthesis tools you can define some critical path and give timing constraint to the optimization process, in the current case we couldn't predict the latency time in general because that depend of the optimization result , and the target technology. We can ensure a pseudo latency timing if we manually force the mapping (use specific 4-and components by example), but in that case our code couldn't really migrate between different target technology. And this type of constraint (if they are generalized) can work against optimization process. The avantage of using normalized, or by default standardized, functions is than synthesizer have generally yet optimized this functions and can ensure best result with any target technology. >Etienne. > Cheers Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 11:29:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZTvb-00066F-01 for ; Tue, 30 Jul 2002 12:08:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 12:08:31 +0200 (CEST) Received: (qmail 27041 invoked by uid 0); 30 Jul 2002 09:38:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Jul 2002 09:38:47 -0000 Received: by moria.seul.org (Postfix) id 2F663146815; Tue, 30 Jul 2002 05:38:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 20A4114691B; Tue, 30 Jul 2002 05:38:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 73E1F146815 for ; Tue, 30 Jul 2002 05:38:45 -0400 (EDT) Received: (qmail 73503 invoked by uid 85); 30 Jul 2002 09:35:48 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.276071 secs); 30 Jul 2002 09:35:48 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 09:35:47 -0000 Message-ID: <3D465C6B.9010606@yahoo.fr> Date: Tue, 30 Jul 2002 11:29:15 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I have read your code and, unfortunately, I have found an unsynthesisable structure : tree_find_lsb : entity find_lsb ^^^^^ the entity keyword is not supported at this position. See IEEE P1076.6-2001 for more information on VHDL RTL synthesis subset. Just an Illusion PS : If some one need a version of the IEEE P1076.6-2001 standard, I can upload a version on seul.org. Etienne LABARRE wrote: >Hi all, > >New snapshot include a lot of changes and features : > >INC unit and CMP unit are now two different units, for simplify and >decrease latency > >Both units are based to the same component : find_lsb > It's a binary tree for find the first null lsb in a word. > It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 > bits) > It's based to only one function : and_reduce. It's is a standard > function of ieee.std_logic_1164 library. > Latency of find_lsb is not exactly know, but i can estimate this > to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of > 8-and, and 1 level of mux. The precise latency is not important, > because max latency will be fixed by timing constraints during synthetisis process. > (It's an explain of my choice of standard function. "Just an > Illusion" > will can explain this more easy that me, i think...) > >For INC unit, the data flow is : > 1 level of mux > find_lsb : 3 level of 4-and, 1 level of mux > 1 level of xor > 2 level of mux > total is 8 levels. > Critical datapath is only for ABS operation. > > Supported operations : > INC, DEC, NEG, ABS, LSB0, LSB1 > > All operations are tested by my testbenches. > >For CMP unit, the data flow is : > 1 level of xor, > 1 level of mux, > find_lsb : 3 level of 4-and, 1 level of mux > 2 level of mux, > total is 8 levels. > Critical datapath is for CMP, MIN, MAX, SORT operations. > > Supported operations : > CMP, MIN, MAX, SORT, MSB0, MSB1 > > Today, only CMP, MSB0 and MSB1 are tested by my testbenches. Todo : > test for others operations. > > >All operations can need only one cycle, if we accept the 8 level of gates >latency. > >Etienne. > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 12:19:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZUlj-0006tx-00 for ; Tue, 30 Jul 2002 13:02:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 13:02:23 +0200 (CEST) Received: (qmail 27638 invoked by uid 0); 30 Jul 2002 10:10:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 30 Jul 2002 10:10:09 -0000 Received: by moria.seul.org (Postfix) id 2FF45146815; Tue, 30 Jul 2002 06:10:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE62514691B; Tue, 30 Jul 2002 06:10:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 9452A146815 for ; Tue, 30 Jul 2002 06:10:06 -0400 (EDT) Received: from f-cpu.org (kdl11-143.n.club-internet.fr [213.44.9.143]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 352D516AA for ; Tue, 30 Jul 2002 12:10:04 +0200 (CEST) Message-ID: <3D46682C.749213E4@f-cpu.org> Date: Tue, 30 Jul 2002 12:19:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] superscalar References: <200207300749.0233@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > >>>Does i dream ? obviously. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 12:24:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZUlj-0006tx-01 for ; Tue, 30 Jul 2002 13:02:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 13:02:23 +0200 (CEST) Received: (qmail 20970 invoked by uid 0); 30 Jul 2002 10:15:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 30 Jul 2002 10:15:08 -0000 Received: by moria.seul.org (Postfix) id 9DA8B146815; Tue, 30 Jul 2002 06:15:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7523714691B; Tue, 30 Jul 2002 06:15:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E4558146815 for ; Tue, 30 Jul 2002 06:15:05 -0400 (EDT) Received: from f-cpu.org (kdl4-83.n.club-internet.fr [213.44.3.83]) by relay-4v.club-internet.fr (Postfix) with ESMTP id BB95016C5 for ; Tue, 30 Jul 2002 12:15:03 +0200 (CEST) Message-ID: <3D466957.EE585F7B@f-cpu.org> Date: Tue, 30 Jul 2002 12:24:23 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <3D465C6B.9010606@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Just an Illusion wrote: > Hello, > > I have read your code and, unfortunately, I have found an > unsynthesisable structure : > > tree_find_lsb : entity find_lsb > ^^^^^ > the entity keyword is not supported at this position. does that mean that it must use the "duplicated" form of declaration+use ? what tool are you using ? > See IEEE P1076.6-2001 for more information on VHDL RTL synthesis subset. > > Just an Illusion > > PS : If some one need a version of the IEEE P1076.6-2001 standard, I can > upload a version on seul.org. cool ! that would be useful, indeed. thanks ! WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 13:13:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZWZy-0008GP-00 for ; Tue, 30 Jul 2002 14:58:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 14:58:22 +0200 (CEST) Received: (qmail 6940 invoked by uid 0); 30 Jul 2002 11:23:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Jul 2002 11:23:17 -0000 Received: by moria.seul.org (Postfix) id 9469F146919; Tue, 30 Jul 2002 07:23:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8AFA4146920; Tue, 30 Jul 2002 07:23:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id EB051146919 for ; Tue, 30 Jul 2002 07:23:14 -0400 (EDT) Received: (qmail 76616 invoked by uid 85); 30 Jul 2002 11:20:17 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.216149 secs); 30 Jul 2002 11:20:17 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 11:20:16 -0000 Message-ID: <3D4674E8.7050407@yahoo.fr> Date: Tue, 30 Jul 2002 13:13:44 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <3D465C6B.9010606@yahoo.fr> <3D466957.EE585F7B@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Yann Guidon wrote: >hi ! > >Just an Illusion wrote: > >>Hello, >> >>I have read your code and, unfortunately, I have found an >>unsynthesisable structure : >> >> tree_find_lsb : entity find_lsb >> ^^^^^ >>the entity keyword is not supported at this position. >> > >does that mean that it must use the "duplicated" form of >declaration+use ? > >what tool are you using ? > That not a problem of tools, some support, other not. The "good" way to instantiate a component is : component_instantiation_statement ::= instantation_label : instantiated_unit [ generic_map_aspect ] [ port_map_aspect ] ; instantiated_unit ::= component_name And btw, for component declaration : component_declaration ::= component identifier [local_generic_clause] [local_port_clause] end component; > >>See IEEE P1076.6-2001 for more information on VHDL RTL synthesis subset. >> >>Just an Illusion >> >>PS : If some one need a version of the IEEE P1076.6-2001 standard, I can >>upload a version on seul.org. >> > >cool ! that would be useful, indeed. thanks ! > How can I made upload ? > >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 13:43:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZWZy-0008GP-01 for ; Tue, 30 Jul 2002 14:58:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 14:58:22 +0200 (CEST) Received: (qmail 31971 invoked by uid 0); 30 Jul 2002 11:53:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 30 Jul 2002 11:53:15 -0000 Received: by moria.seul.org (Postfix) id 50EB3146919; Tue, 30 Jul 2002 07:53:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 46C94146920; Tue, 30 Jul 2002 07:53:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 9EFD4146919 for ; Tue, 30 Jul 2002 07:53:13 -0400 (EDT) Received: (qmail 77286 invoked by uid 85); 30 Jul 2002 11:50:15 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.476239 secs); 30 Jul 2002 11:50:15 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 11:50:14 -0000 Message-ID: <3D467BEE.5060204@yahoo.fr> Date: Tue, 30 Jul 2002 13:43:42 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Yann Guidon wrote: >hello, > >Just an Illusion wrote: > >>Hello, >> >>After a private disussion between different member of the f-cpu list, we >>have arrive to conclude than no coding rules exist on the project. >> > >??? > >that's wrong. > >or maybe you mixed "coding style" and "coding rule" which in our context >are the same thing. > I go try to clarify my mind. "coding style" and "coding rule" are not same (in any context). If you said : all my signal must be postfixed with the entity name, this is a "coding rule" not a "coding style". If you said : all my state machine must be mealy-like, this is a "coding style" not a "coding rule". > > >And in case you want to start a new unit, just copy/paste an existing >one and modify the necessary parts, while keeping the same look. > >btw, i looked once at the LEON code and i think it's easier to use >F-CPU's sources. It's probably a bit confusing, but not confused. > >>This point seems not very important as long as the number of coder is >>small, but to help newbies or modification of existing block, the coding >>rule usage is better. >> >The use of a brain (and optionally : good sense) is ok, too. > >>The existance of coding rule, can be help to understand the code of a >>bloc and the hierarchical structure. >> >>We made some proposal : >> * hierarchical prefix on each signal (and interface pad) to give >>hierarchical belonging >> * postfix on each signal to give signal direction or polarity, >>like _i (input), _o(output), _s(internal signal), _n(not signal)... >> * file name rule >> * don't use signal declaration into package declaration. >> >>If you see other rules, propose them. >> > >maybe you can look at the code and see yourself. > Ok, I have done it. Please, Etienne forgive me, but your code can be a good example to illustrated this subject. In the eu_inc.vhd file : * some keywords are in capital letter, some others not. * The generic parameter eu_inc_width can be put in capital letter, to help distinction with signal and variable value. * The interface signals aren't globally in capital letter except for function abs_chunk. That doesn't change the result, but can help the code reading. The next remark is not a "coding rule", but more a "coding style" rule. I thing is better if you create a package which embedded all the necessary component (and perhaps functions) needed for your eu_inc and eu_cmp rather than "use work.find_lsb;" notation. > >>Cheers, >>Just an Illusion >> >WHYGEE >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 13:58:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZWZz-0008GP-00 for ; Tue, 30 Jul 2002 14:58:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 14:58:23 +0200 (CEST) Received: (qmail 21201 invoked by uid 0); 30 Jul 2002 12:08:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 30 Jul 2002 12:08:05 -0000 Received: by moria.seul.org (Postfix) id E1CAF146919; Tue, 30 Jul 2002 08:08:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6C3F146920; Tue, 30 Jul 2002 08:08:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id DE36E146919 for ; Tue, 30 Jul 2002 08:08:02 -0400 (EDT) Received: (qmail 78007 invoked by uid 85); 30 Jul 2002 12:05:04 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 1.963645 secs); 30 Jul 2002 12:05:04 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 12:05:01 -0000 Message-ID: <3D467F65.60206@yahoo.fr> Date: Tue, 30 Jul 2002 13:58:29 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have forgot some thing Just an Illusion wrote: > Hi, > > Yann Guidon wrote: >> >> maybe you can look at the code and see yourself. >> > Ok, I have done it. > > Please, Etienne forgive me, but your code can be a good example to > illustrated this subject. > > In the eu_inc.vhd file : > > * some keywords are in capital letter, some others not. > * The generic parameter eu_inc_width can be put in capital letter, to > help distinction with signal and variable value. > * The interface signals aren't globally in capital letter except for > function abs_chunk. > > That doesn't change the result, but can help the code reading. > > The next remark is not a "coding rule", but more a "coding style" rule. > > I thing is better if you create a package which embedded all the > necessary component (and perhaps functions) needed for your eu_inc and > eu_cmp rather than "use work.find_lsb;" notation. I have an other one (coding style) : Defined each value of eu_inc_mode by a constant, and use them into the case structure. Something like : ... architecture simple of eu_inc is ... constant C_EU_INC_MODE_NEG : natural := "000" constant C_EU_INC_MODE_DEC : natural := "001" constant C_EU_INC_MODE_INC : natural := "010" constant C_EU_INC_MODE_ABS : natural := "011" constant C_EU_INC_MODE_LSB0 : natural := "100" constant C_EU_INC_MODE_LSB1 : natural := "101" ... begin ... eu_inc_in : process(eu_inc_A, eu_inc_simd, eu_inc_mode) is begin -- Input of unit case eu_inc_mode is when C_EU_INC_MODE_NEG => tree_in <= not eu_inc_A; when C_EU_INC_MODE_DEC => tree_in <= not eu_inc_A; when C_EU_INC_MODE_INC => tree_in <= eu_inc_A; when C_EU_INC_MODE_ABS => tree_in <= not eu_inc_A; when C_EU_INC_MODE_LSB0 => tree_in <= eu_inc_A; when C_EU_INC_MODE_LSB1 => tree_in <= not eu_inc_A; when others => tree_in <= eu_inc_A; end case; end process; ... Now, if you want change the eu_inc_mode coding values, you need modify it only in one place. See the coding rule I have use to immediatly link (when read) the constant value with the content of eu_inc_mode. > >> >>> Cheers, >>> Just an Illusion >>> >> WHYGEE >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ************************************************************* >> To unsubscribe, send an e-mail to majordomo@seul.org with >> unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> > Just an Illusion > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 14:54:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZWu6-0008QO-00 for ; Tue, 30 Jul 2002 15:19:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 15:19:10 +0200 (CEST) Received: (qmail 25979 invoked by uid 0); 30 Jul 2002 13:03:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 30 Jul 2002 13:03:41 -0000 Received: by moria.seul.org (Postfix) id B73DC14691E; Tue, 30 Jul 2002 09:03:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 788AE146922; Tue, 30 Jul 2002 09:03:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 90CE214691E for ; Tue, 30 Jul 2002 09:03:34 -0400 (EDT) Received: (qmail 80022 invoked by uid 85); 30 Jul 2002 13:00:35 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 1.237195 secs); 30 Jul 2002 13:00:35 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 13:00:34 -0000 Message-ID: <3D468C6A.1090701@yahoo.fr> Date: Tue, 30 Jul 2002 14:54:02 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> <3D467F65.60206@yahoo.fr> Content-Type: multipart/mixed; boundary="------------070302010000030607040804" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------070302010000030607040804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Find attached an example than how we can give some more "readeable" code with some simple coding rules or coding style. Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 --------------070302010000030607040804 Content-Type: application/octet-stream; name="example.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="example.tgz" H4sIALKLRj0AA+0Z23LayDKv4Su68nACWSAS+LIL8anFGCdkCXYZvKk8UYM0wCRC4uhih/P1 2z26I1BsnzgPp6bLFVsz3T19m75MeDATtjHbNO9W5otnAk3XtJOjoxeaph8ftzX8jX9pJ/I3 wvHp6fEL7fS4pR9rx8enOuK3tZP2C9CeS6AsBJ7PXIAXLrdZUGICj7t3wuC/QqRfCY2fC5VG A6bCtzhI6MDgFoa24fI1t324ZsY3tuSEdO06X7nhh0iXLuems4b+9W3lGQS6FLE8eBbPBDxt 9gJ/5bjR5keMBmA2DC0r8IRjE0LfWW+YvY0kbYQyQt/lzOdmuNrStNZb7fRtW6OtEUMmwcbE /d2ta4v5C8ddS6rnUPWCe4YrNj7K3oHpSniAP/6K5/2wCf0A98JfgckXwhZEAc4CmGWBjd7g 0jiLwDZox0OjmGCgJRybGKAOEdfZcNwHXBL+9jn06TubrSuWKx+qRk0as+AjqIror5nvzGzu /7llK8dpLtwa/Ctx2E+X7IbfCU+aBjrS8ujuKMjgb+5KyZLgyriFcNOgANCbWkj0kQ1fRlH1 DPIegvPB++G48feHi1FjNOwPxv3BDzWXYbVxnaXL1hReC7y94DkL/565vAtbJwAD/eNyU3i+ K+YBGkaQy8y3aIu1Y4oFxQqtBbbJw0jyubv2KADp4/34Ft5zm7vMgutgbgkDRph7bY8Dw6Np xVvh5ZtLPkRBGQQmkQxw6SBjRtbuAscYxzPuIpe04jMihnVwXGJSZT5J7oIjvVQDuvJ4W1PS ZmW/+qmWJghb8l45G9RohSxRx3sMT5hzCDy+CKw6sUBk+Dycfri6nUJv/AU+925ueuPpl668 kQ7u8jseshLrjSWQM+rlMtvfovjE4dPgpv8BSXrnw9Fw+gWVgMvhdDyYTODy6gZ6cN27mQ77 t6PeDVzf3lxfTQZNgAknsWT+LTHxQnoJzWhynwnLixX/go71UDrLhBW74+hgg4s7lI1hZths f+w8YsIsx16GicfPGLILYgG249fh3hUYL75TdKtM5Yln65TPmnU4/gOmHI3EKbka6M9JQAza ba0O547nE+anHmgtXdcb2Ficwu2kV3bBBuOLh9+HRqViibnL3C0Iznm3gl6WfzU935xZzlIY M10/OWpiXu1WKnHijYtQ9Cm8CmSzq7CR1ptXKC0syZRow2olTBPvZ5fD8cVsNDmffR5eTD9g IbGZH6C1a12JsnFcP8GOWeFxGwwrRMYQBZItCIW7wyLsuNXWmze7jBs6mM69jZ7QIs4Zdhij xK8DFKz/OztPrE04LF2B11HKSzLj2eqEdoakcgGbezNjFdjfqtDDiAjPKBwBNQxntOKeLcnO wETv4/2D/iysebNPVxeD2XjwHlIHQOcMXmFD+6p7mOJi0C9S6GUUVGB3KfTSM3rnkyJF6Rlo WW2HQi/XAyn0AgWdUSFf5OM7E/hzx9zuif4DDmN1mD/eYeF1ArhjrmBzTAxWXlD22uL20l91 81jf8ljz1yvsO3ZwPLG0ES09UgbHnC+FLRHDfTyi+q0mt9B+zIvoIrEA7leY3F/rr+Hs37ES rJvb07J789yeQ+XMK27LK4Bnxdchtid9088+t2D/Hy25XObd55kCy+c/vXXazsx/Jy3EP2qd nqr571dAeXV7DCSTFsaQ9TaMq+gXhZUFDaBUdouzBgy+cyPwkwEr6fH7UY8/8AW3bWzS2Bz7 Hg5VHi40rXDhzyUz/9t03GUt6k0mgY2DgQ3YUevtjvZHp9WG/mAyDdnhGNqEUe8c26wBYaOc Lg4RUWMXs8B27WNgIT3ov3f0445WykLqQZfGx0tJGYr/J6A5CLMHtrg8J5cFrd9JrvZRB1mV MGWmiQ0otk7h0NUBTOV1oOws/9UJSfagAZdsSV0UVNtli7OE5Bdd67DfMrDzxt7LDdBHNM55 /tYKuz05QPnhqRU1LqhxQY0LzzUuRGlh+OkCqI+a0JeHUi8oc8b9sMyX8V2/uh7c9KbDq/FE UtBSVLQpz6TpAu+E59Mu1tSwX5DdqYRwWQ8/ZAuaLusRtuwzM8sRNmYg+tZjppSMwgU9WdDL k8ZjoSKvu21YAepHzafJXBPCOUtw7zETV6ORbNvBmgapGaJF01jmlE30HFk85N5xv8V86O9m 7CRkkKzlG6uU/UXubS3/Whb+inwZNYfJsIdjXtRt7wx51F2eQDhB5Sa9SIQelMxRcizL8t03 lEWM5Eh2eCDLcTk6yEWG6EFxDpJ9CbUoGS4PaRHxQYZpwxv7InmDKzqDucYK84CBNqZuXSYI RMo5x99imqbphHLrlnK5/GPXGO1UGGLxFC/QuICu9jGdzch0uZHjaWyccPp/NBvZRvzEaZps KVlmx6pRPr57yYBWwPxrFzMc0gp4+wY1iRTOajF+PK/1qn8luu7ObPHi/sGtR4e/3De2nWd2 CkNbL5U5HdzkSn52q4Ty0tbGZcs1Q28y26NOY+YsFpl1b2vjIZ7w5Dq6n3k4smB+2Mkk7+Ao vCQul/nj1RQL54ZhUeXUvexgr+mxHbuRpXyYpt4LW7X2q3DYxa7DpRR22RuObm8G3f3S2PuF t8O5FKL/YSm+fMmwjRfQl7lXsTRVrtmmmj4k3QsTWwW0844ecV6QKhNJJXHq7hMZEkcXr74H KXr4ipHwcx9W9J6FWJlsmuJFbwPRnqBIxQJkcM+rxmm8nqWsZ9OpVCV9ciADDqXkmGwCLDaV NISzSRjTVSyADMk9D1mp5vDujNqrpKh0S0hlO/E0Utly5EkfQibft552onzoevyJ8rXroSdG lz0LpSdmX27kRxQLaXzkwsWR765xvCRRCA+MHDicdwuloLtLME4JCntUGqKmISmSBSQprs2X T6xoBVZUnX8SKxT6SQUyfxszGoYxklTf71j8dgMm1eHsEGKESTmUu/L/jklQQo4f0amoUhnW aAwqNCOW42zSzDOO/Cy6mayFDL4mDMaonqR5SXuxU6uiVq1+/U2vvRm9HacG+EqfNfnimTYG IWUasL3DlPUUObbbYeRaRma6JiRl0jcm36m9PE5dHciYtLBWWfLVYx18lxqjwFknSO+fpfpq tYfFUN76mZsnO5Md6+PQWs2goFHhjPqJGk2vdmiKvdIINMmP5HkpjSAWZSa5CqtXrlLsKxWJ yCWlImnV350lzuuWEcaFokAoW/QSwrhMPJowLhQFQjRsKWFcJgqEeD9/RKg/kHB/mSjT8UeF Qp5B6+EAI9/3FShQoECBAgUKFChQoECBAgUKFChQoECBAgUKFChQoECBAgUKFChQoECBAgUK FPx/wT/ohsFKAFAAAA== --------------070302010000030607040804-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 14:59:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZWu7-0008QO-00 for ; Tue, 30 Jul 2002 15:19:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 30 Jul 2002 15:19:11 +0200 (CEST) Received: (qmail 4139 invoked by uid 0); 30 Jul 2002 13:09:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 30 Jul 2002 13:09:05 -0000 Received: by moria.seul.org (Postfix) id D6ECF14691E; Tue, 30 Jul 2002 09:09:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 824AE146922; Tue, 30 Jul 2002 09:09:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 78D0014691E for ; Tue, 30 Jul 2002 09:09:01 -0400 (EDT) Received: (qmail 80290 invoked by uid 85); 30 Jul 2002 13:06:03 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.565136 secs); 30 Jul 2002 13:06:03 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 13:06:02 -0000 Message-ID: <3D468DB1.4000307@yahoo.fr> Date: Tue, 30 Jul 2002 14:59:29 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <3D465C6B.9010606@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I have found some other mistakes (unsupported code for the VHDL RTL Synthesis subset). See the attached example I give in thread : [f-cpu] HDL coding style. In the message from 07/30/2002 at 02:54 PM Just an Illusion. Just an Illusion wrote: > Hello, > > I have read your code and, unfortunately, I have found an > unsynthesisable structure : > > tree_find_lsb : entity find_lsb > ^^^^^ > the entity keyword is not supported at this position. > > See IEEE P1076.6-2001 for more information on VHDL RTL synthesis subset. > > Just an Illusion > > PS : If some one need a version of the IEEE P1076.6-2001 standard, I > can upload a version on seul.org. > > Etienne LABARRE wrote: > >> Hi all, >> >> New snapshot include a lot of changes and features : >> >> INC unit and CMP unit are now two different units, for simplify and >> decrease latency >> >> Both units are based to the same component : find_lsb >> It's a binary tree for find the first null lsb in a word. >> It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 >> bits) >> It's based to only one function : and_reduce. It's is a standard >> function of ieee.std_logic_1164 library. >> Latency of find_lsb is not exactly know, but i can estimate this >> to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of >> 8-and, and 1 level of mux. The precise latency is not important, >> because max latency will be fixed by timing constraints during >> synthetisis process. >> (It's an explain of my choice of standard function. "Just an >> Illusion" >> will can explain this more easy that me, i think...) >> >> For INC unit, the data flow is : >> 1 level of mux >> find_lsb : 3 level of 4-and, 1 level of mux >> 1 level of xor >> 2 level of mux >> total is 8 levels. >> Critical datapath is only for ABS operation. >> >> Supported operations : >> INC, DEC, NEG, ABS, LSB0, LSB1 >> >> All operations are tested by my testbenches. >> >> For CMP unit, the data flow is : >> 1 level of xor, >> 1 level of mux, >> find_lsb : 3 level of 4-and, 1 level of mux >> 2 level of mux, >> total is 8 levels. >> Critical datapath is for CMP, MIN, MAX, SORT operations. >> >> Supported operations : >> CMP, MIN, MAX, SORT, MSB0, MSB1 >> >> Today, only CMP, MSB0 and MSB1 are tested by my testbenches. Todo : >> test for others operations. >> >> >> All operations can need only one cycle, if we accept the 8 level of >> gates >> latency. >> >> Etienne. >> > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 02:15:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZljT-0001n6-00 for ; Wed, 31 Jul 2002 07:09:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:11 +0200 (CEST) Received: (qmail 4840 invoked by uid 0); 30 Jul 2002 14:27:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 30 Jul 2002 14:27:48 -0000 Received: by moria.seul.org (Postfix) id 562DC14691E; Tue, 30 Jul 2002 10:27:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19EE6146923; Tue, 30 Jul 2002 10:27:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a216.home.uni-hannover.de [130.75.232.216]) by moria.seul.org (Postfix) with ESMTP id F15F314691E for ; Tue, 30 Jul 2002 10:27:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02629; Tue, 30 Jul 2002 02:15:08 +0200 Message-ID: <20020730021508.07502@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 02:15:08 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] What's wrong here? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok... can anybody tell me what's wrong with this function? function inv_word(A : in std_ulogic_vector) return std_ulogic_vector is variable L : natural := A'low; variable H : natural := A'high; variable B : std_ulogic_vector(H downto L); begin for i in L to H loop B(i) := A(H+L-i); end loop; return B; end function; Hint: consider the possible index ranges of the argument. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jul 30 16:37:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZljT-0001n6-01 for ; Wed, 31 Jul 2002 07:09:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:11 +0200 (CEST) Received: (qmail 25596 invoked by uid 0); 30 Jul 2002 14:37:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 30 Jul 2002 14:37:13 -0000 Received: by moria.seul.org (Postfix) id CAA8714691E; Tue, 30 Jul 2002 10:37:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91CC9146922; Tue, 30 Jul 2002 10:37:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id CAC9B14691E for ; Tue, 30 Jul 2002 10:37:10 -0400 (EDT) Message-ID: <20020730143710.93022.qmail@web14205.mail.yahoo.com> Received: from [130.89.243.164] by web14205.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 07:37:10 PDT Date: Tue, 30 Jul 2002 07:37:10 -0700 (PDT) From: jaap stolk Subject: [f-cpu] yet another snapsot_jws To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, not a lot of time since the last update, but a lot of news: i implemented (whether used or not) different latencies for high / low output od the IMUL EU. it contains an updated pictiure: /f-cpu/c/fcpusim/fcpusim.png i added an other bypass, i now heve: - direct bypass: F D X E X R | . . F D X E X R - delayed bypass: F D X E X R \ . . . F D X E X R - 2x delayed bypass: F D X E X R \--\ . . . . F D X E X R (after we can use normal register output.) it contains jwsasm (changed ygasm) and some example / test programs (including YG's winograd_DCT ) try: -unpack it somewhere (no need to install) -goto: /f-cpu/programs/ -and run runme.sh (-read: /f-cpu/programs/README.txt ) -run: ./fcpusim winograd_dct.bin there is sill a lot of wirk to do, but you should now be able write your own asm programs and run them on the F-CPU (using only MOVE ADD SUB and MUL) :-) (and some things i forgot.) jaap __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Jul 30 19:01:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZljY-0001n6-00 for ; Wed, 31 Jul 2002 07:09:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:16 +0200 (CEST) Received: (qmail 5009 invoked by uid 0); 30 Jul 2002 17:10:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 30 Jul 2002 17:10:45 -0000 Received: by moria.seul.org (Postfix) id 4D82214691E; Tue, 30 Jul 2002 13:10:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E3F3146922; Tue, 30 Jul 2002 13:10:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 4360114691E for ; Tue, 30 Jul 2002 13:10:43 -0400 (EDT) Received: (qmail 88452 invoked by uid 85); 30 Jul 2002 17:07:43 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.480905 secs); 30 Jul 2002 17:07:43 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 30 Jul 2002 17:07:43 -0000 Message-ID: <3D46C656.2030207@yahoo.fr> Date: Tue, 30 Jul 2002 19:01:10 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, The variable H and L can't be used to calculate the size of B, more they are unnecessary. When you call the function inv_word with a vector, the A'HIGH and the A'LOW aren't referred to the real size of the vecteur, but the part connected. The good version is more like : function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is variable B : std_ulogic_vector ( A'HIGH downto 0); begin for i in 0 to B'HIGH loop B(i)=A(A'HIGH-i); end loop; end inv_word; or function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is variable B : std_ulogic_vector ( A'LENGHT-1 downto 0); begin for i in 0 to B'LENGHT-1 loop B(i)=A(A'LENGHT-1-i); end loop; end inv_word; Or any combinaison of both. Michael Riepe wrote: >Ok... can anybody tell me what's wrong with this function? > > function inv_word(A : in std_ulogic_vector) return std_ulogic_vector is > variable L : natural := A'low; > variable H : natural := A'high; > variable B : std_ulogic_vector(H downto L); > begin > for i in L to H loop > B(i) := A(H+L-i); > end loop; > return B; > end function; > >Hint: consider the possible index ranges of the argument. > Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Jul 30 19:34:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZljZ-0001n6-00 for ; Wed, 31 Jul 2002 07:09:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:17 +0200 (CEST) Received: (qmail 9941 invoked by uid 0); 30 Jul 2002 17:32:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 30 Jul 2002 17:32:33 -0000 Received: by moria.seul.org (Postfix) id 4C4CF14691E; Tue, 30 Jul 2002 13:32:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37BD0146922; Tue, 30 Jul 2002 13:32:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf03bis.bellsouth.net (mail203.mail.bellsouth.net [205.152.58.143]) by moria.seul.org (Postfix) with ESMTP id E165514691E for ; Tue, 30 Jul 2002 13:32:30 -0400 (EDT) Received: from computer ([208.60.244.64]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020730173402.DJWY11981.imf03bis.bellsouth.net@computer> for ; Tue, 30 Jul 2002 13:34:02 -0400 Message-ID: <002801c237ef$63bdf4e0$40f43cd0@computer> From: "richard hartny" To: Subject: [f-cpu] CMP Date: Tue, 30 Jul 2002 12:34:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C237C5.7A16E140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C237C5.7A16E140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For what its worth; I use the equivalent of an SN7485 Comparator for a 64 bit result of = EQU, AGB, and ALB. Requires 113 Logic cells of the Eclipse family of = FPGA devices. It requires 7 logic levels and executes in 10.2 NS plus = setup time of three DFF's. I can test and Branch on each of the = registered outputs. If my Canadian counterpart (Ben) will send me his mailing address, I = will send him an VHDL manual that I will never use. Dick Hartney ------=_NextPart_000_0025_01C237C5.7A16E140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
   For what its = worth;
 
    I use the equivalent = of an=20 SN7485 Comparator for a 64 bit result of EQU, AGB, and ALB.  = Requires 113=20 Logic cells of the Eclipse family of FPGA devices.  It requires 7 = logic=20 levels and executes in 10.2 NS plus setup time of three DFF's.  I = can test=20 and Branch on each of the registered outputs.
    If my Canadian = counterpart (Ben)=20 will send me his mailing address, I will send him an VHDL manual that I = will=20 never use.
 
Dick Hartney
------=_NextPart_000_0025_01C237C5.7A16E140-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 20:18:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZljZ-0001n6-01 for ; Wed, 31 Jul 2002 07:09:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:17 +0200 (CEST) Received: (qmail 1531 invoked by uid 0); 30 Jul 2002 18:09:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 30 Jul 2002 18:09:22 -0000 Received: by moria.seul.org (Postfix) id E002714691E; Tue, 30 Jul 2002 14:09:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0F95146922; Tue, 30 Jul 2002 14:09:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4764314691E for ; Tue, 30 Jul 2002 14:09:20 -0400 (EDT) Received: from f-cpu.org (kdl11-97.n.club-internet.fr [213.44.9.97]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 23BE316A1 for ; Tue, 30 Jul 2002 20:09:16 +0200 (CEST) Message-ID: <3D46D87E.78D39B42@f-cpu.org> Date: Tue, 30 Jul 2002 20:18:38 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > Ok... can anybody tell me what's wrong with this function? > > function inv_word(A : in std_ulogic_vector) return std_ulogic_vector is > variable L : natural := A'low; > variable H : natural := A'high; > variable B : std_ulogic_vector(H downto L); > begin > for i in L to H loop > B(i) := A(H+L-i); > end loop; > return B; > end function; > > Hint: consider the possible index ranges of the argument. i've seen a post on comp.lang.vhdl (Wed, 10 Jul 2002) about this problem. Since bit reversing is often an issue, i have archived it. The conclusion was : Jonathan Bromley wrote: > > someone wrote... > > > temp : std_logic_vector(N downto 0); > > a: std_logic_vector(N downto 0); > > > > a(a'high downto a'low) <= temp(temp'low to temp'high); > > Nope, sorry, doesn't work. Bad slice direction on the right. > > Renaud is right; you must simply copy the bits, one by one, > probably using a 'for' loop. Synthesis should have no > trouble with this, and will just hook the right wires together. > > My favourite way to do it exploits the VHDL'93 attribute > REVERSE_RANGE and saves you the trouble of doing any > explicit arithmetic on the subscripts: > > function reverse_bits(a: in std_logic_vector) > return std_logic_vector > is > variable a_rev: std_logic_vector(a'REVERSE_RANGE); > begin > for i in a'RANGE loop > a_rev(i) := a(i); > end loop; > return a_rev; > end; > > and then you can do things like this... > > signal a, b: std_logic_vector(7 downto 0); > ... > a <= reverse_bits(b); > -- > Jonathan Bromley > HDL Consultant / DOULOS - Developing Design Know-how > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jul 30 21:17:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljc-0001n6-01 for ; Wed, 31 Jul 2002 07:09:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:20 +0200 (CEST) Received: (qmail 17285 invoked by uid 0); 30 Jul 2002 19:20:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 30 Jul 2002 19:20:24 -0000 Received: by moria.seul.org (Postfix) id C7F8214691E; Tue, 30 Jul 2002 15:20:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABB39146922; Tue, 30 Jul 2002 15:20:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 4617E14691E for ; Tue, 30 Jul 2002 15:20:23 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-215.jetnet.ab.ca [207.34.60.215]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6UJKOh1042957 for ; Tue, 30 Jul 2002 13:20:25 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D46E630.5000100@jetnet.ab.ca> Date: Tue, 30 Jul 2002 13:17:04 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CMP References: <002801c237ef$63bdf4e0$40f43cd0@computer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N richard hartny wrote: > For what its worth; > > I use the equivalent of an SN7485 Comparator for a 64 bit result of EQU, AGB, and ALB. Requires 113 Logic cells of the Eclipse family of FPGA devices. It requires 7 logic levels and executes in 10.2 NS plus setup time of three DFF's. I can test and Branch on each of the registered outputs. > If my Canadian counterpart (Ben) will send me his mailing address, I will send him an VHDL manual that I will never use. > > Dick Hartney > I would have used a adder as I forgot about the 7485 style comparator. My mailing address is on my web page under 'about me'. http://www.jetnet.ab.ca/users/bfranchuk/index.html Thanks. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Jul 30 20:55:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljd-0001n6-00 for ; Wed, 31 Jul 2002 07:09:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:21 +0200 (CEST) Received: (qmail 13898 invoked by uid 0); 30 Jul 2002 19:35:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 30 Jul 2002 19:35:43 -0000 Received: by moria.seul.org (Postfix) id 5394214691E; Tue, 30 Jul 2002 15:35:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42D38146923; Tue, 30 Jul 2002 15:35:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id C42BB14691E for ; Tue, 30 Jul 2002 15:35:41 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-5-62-147-144-194.dial.proxad.net [62.147.144.194]) by postfix3-2.free.fr (Postfix) with SMTP id BEEDF17FAC for ; Tue, 30 Jul 2002 21:35:37 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 30 Jul 2002 20:55:14 +0200 Date: Tue, 30 Jul 2002 20:55:14 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? Message-ID: <20020730185514.GD250@free.fr> References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46D87E.78D39B42@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D46D87E.78D39B42@f-cpu.org> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 08:18:38PM +0200, Yann Guidon wrote: > hi, > > Michael Riepe wrote: > > Ok... can anybody tell me what's wrong with this function? > > > > function inv_word(A : in std_ulogic_vector) return std_ulogic_vector is > > variable L : natural := A'low; > > variable H : natural := A'high; > > variable B : std_ulogic_vector(H downto L); > > begin > > for i in L to H loop > > B(i) := A(H+L-i); > > end loop; > > return B; > > end function; > > > > Hint: consider the possible index ranges of the argument. > > i've seen a post on comp.lang.vhdl (Wed, 10 Jul 2002) > about this problem. Since bit reversing is often an issue, > i have archived it. The conclusion was : > > Jonathan Bromley wrote: > > > > someone wrote... > > > > > temp : std_logic_vector(N downto 0); > > > a: std_logic_vector(N downto 0); > > > > > > a(a'high downto a'low) <= temp(temp'low to temp'high); > > > > Nope, sorry, doesn't work. Bad slice direction on the right. > > > > Renaud is right; you must simply copy the bits, one by one, > > probably using a 'for' loop. Synthesis should have no > > trouble with this, and will just hook the right wires together. > > > > My favourite way to do it exploits the VHDL'93 attribute > > REVERSE_RANGE and saves you the trouble of doing any > > explicit arithmetic on the subscripts: > > > > function reverse_bits(a: in std_logic_vector) > > return std_logic_vector > > is > > variable a_rev: std_logic_vector(a'REVERSE_RANGE); > > begin > > for i in a'RANGE loop > > a_rev(i) := a(i); > > end loop; > > return a_rev; > > end; > > > > and then you can do things like this... > > > > signal a, b: std_logic_vector(7 downto 0); > > ... > > a <= reverse_bits(b); > > -- > > Jonathan Bromley > > HDL Consultant / DOULOS - Developing Design Know-how > > > WHYGEE Thank for this example, but i don't see _my_ error !!! Can you explain me ? Etienne. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Jul 30 20:55:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljd-0001n6-01 for ; Wed, 31 Jul 2002 07:09:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:21 +0200 (CEST) Received: (qmail 3111 invoked by uid 0); 30 Jul 2002 19:35:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 30 Jul 2002 19:35:46 -0000 Received: by moria.seul.org (Postfix) id 7FC79146923; Tue, 30 Jul 2002 15:35:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59FF1146920; Tue, 30 Jul 2002 15:35:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id DB888146923 for ; Tue, 30 Jul 2002 15:35:44 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-5-62-147-144-194.dial.proxad.net [62.147.144.194]) by postfix2-2.free.fr (Postfix) with SMTP id 613605F9BA for ; Tue, 30 Jul 2002 21:35:43 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 30 Jul 2002 20:55:20 +0200 Date: Tue, 30 Jul 2002 20:55:20 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules Message-ID: <20020730185520.GE250@free.fr> References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D467BEE.5060204@yahoo.fr> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 01:43:42PM +0200, Just an Illusion wrote: > Please, Etienne forgive me, but your code can be a good example to > illustrated this subject. > > In the eu_inc.vhd file : > > * some keywords are in capital letter, some others not. > * The generic parameter eu_inc_width can be put in capital letter, to > help distinction with signal and variable value. > * The interface signals aren't globally in capital letter except for > function abs_chunk. > > That doesn't change the result, but can help the code reading. > > The next remark is not a "coding rule", but more a "coding style" rule. > > I thing is better if you create a package which embedded all the > necessary component (and perhaps functions) needed for your eu_inc and > eu_cmp rather than "use work.find_lsb;" notation. I'm totally agree with you. For the moment, my code works, it's the more important :-) . But, it should better if we can easy read the code. Discuss around code will be more easy. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Jul 30 20:55:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zlje-0001n6-00 for ; Wed, 31 Jul 2002 07:09:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:22 +0200 (CEST) Received: (qmail 25981 invoked by uid 0); 30 Jul 2002 19:35:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 30 Jul 2002 19:35:51 -0000 Received: by moria.seul.org (Postfix) id 1E6DC146920; Tue, 30 Jul 2002 15:35:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 13A10146925; Tue, 30 Jul 2002 15:35:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id A555C146920 for ; Tue, 30 Jul 2002 15:35:50 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-5-62-147-144-194.dial.proxad.net [62.147.144.194]) by postfix2-2.free.fr (Postfix) with SMTP id 1EB635FBC1 for ; Tue, 30 Jul 2002 21:35:49 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 30 Jul 2002 20:55:26 +0200 Date: Tue, 30 Jul 2002 20:55:26 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules Message-ID: <20020730185526.GF250@free.fr> References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> <3D467F65.60206@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D467F65.60206@yahoo.fr> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 01:58:29PM +0200, Just an Illusion wrote: > Hi, > > I have forgot some thing > > Just an Illusion wrote: > > >Hi, > > > >Yann Guidon wrote: > > > > >> > >>maybe you can look at the code and see yourself. > >> > >Ok, I have done it. > > > >Please, Etienne forgive me, but your code can be a good example to > >illustrated this subject. > > > >In the eu_inc.vhd file : > > > >* some keywords are in capital letter, some others not. > >* The generic parameter eu_inc_width can be put in capital letter, to > >help distinction with signal and variable value. > >* The interface signals aren't globally in capital letter except for > >function abs_chunk. > > > >That doesn't change the result, but can help the code reading. > > > >The next remark is not a "coding rule", but more a "coding style" rule. > > > >I thing is better if you create a package which embedded all the > >necessary component (and perhaps functions) needed for your eu_inc and > >eu_cmp rather than "use work.find_lsb;" notation. > > I have an other one (coding style) : > > Defined each value of eu_inc_mode by a constant, and use them into the > case structure. Something like : > ... > architecture simple of eu_inc is > ... > constant C_EU_INC_MODE_NEG : natural := "000" > constant C_EU_INC_MODE_DEC : natural := "001" > constant C_EU_INC_MODE_INC : natural := "010" > constant C_EU_INC_MODE_ABS : natural := "011" > constant C_EU_INC_MODE_LSB0 : natural := "100" > constant C_EU_INC_MODE_LSB1 : natural := "101" > ... > begin > ... > eu_inc_in : process(eu_inc_A, eu_inc_simd, eu_inc_mode) is > begin > -- Input of unit > case eu_inc_mode is > when C_EU_INC_MODE_NEG => tree_in <= not eu_inc_A; > when C_EU_INC_MODE_DEC => tree_in <= not eu_inc_A; > when C_EU_INC_MODE_INC => tree_in <= eu_inc_A; > when C_EU_INC_MODE_ABS => tree_in <= not eu_inc_A; > when C_EU_INC_MODE_LSB0 => tree_in <= eu_inc_A; > when C_EU_INC_MODE_LSB1 => tree_in <= not eu_inc_A; > when others => tree_in <= eu_inc_A; > end case; > end process; > ... > > Now, if you want change the eu_inc_mode coding values, you need modify > it only in one place. > > See the coding rule I have use to immediatly link (when read) the > constant value with the content of eu_inc_mode. Ok, il will modify my code. I don't wait the document had written :-) Etienne ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Jul 30 20:55:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljf-0001n6-00 for ; Wed, 31 Jul 2002 07:09:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:23 +0200 (CEST) Received: (qmail 14792 invoked by uid 0); 30 Jul 2002 19:35:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 30 Jul 2002 19:35:55 -0000 Received: by moria.seul.org (Postfix) id 18618146924; Tue, 30 Jul 2002 15:35:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DD33E14692F; Tue, 30 Jul 2002 15:35:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 9A5D0146924 for ; Tue, 30 Jul 2002 15:35:54 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-5-62-147-144-194.dial.proxad.net [62.147.144.194]) by postfix1-2.free.fr (Postfix) with SMTP id 420D9AB774 for ; Tue, 30 Jul 2002 21:35:31 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 30 Jul 2002 20:55:08 +0200 Date: Tue, 30 Jul 2002 20:55:08 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? Message-ID: <20020730185508.GC250@free.fr> References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D46C656.2030207@yahoo.fr> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 07:01:10PM +0200, Just an Illusion wrote: > Hello, > > The variable H and L can't be used to calculate the size of B, more they > are unnecessary. > > When you call the function inv_word with a vector, the A'HIGH and the > A'LOW aren't referred to the real size of the vecteur, but the part > connected. > > The good version is more like : > > function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is > variable B : std_ulogic_vector ( A'HIGH downto 0); > begin > for i in 0 to B'HIGH loop > B(i)=A(A'HIGH-i); > end loop; > end inv_word; > > or > > function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is > variable B : std_ulogic_vector ( A'LENGHT-1 downto 0); > begin > for i in 0 to B'LENGHT-1 loop > B(i)=A(A'LENGHT-1-i); > end loop; > end inv_word; > > Or any combinaison of both. > My problem is : Input vector maybe 0 to length-1, but low index can be not null. And i want a output vector with same range as input. And i don't see what's wrong, it's works fine with simili. Is it luke ? Etienne. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Tue Jul 30 20:54:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljf-0001n6-01 for ; Wed, 31 Jul 2002 07:09:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:23 +0200 (CEST) Received: (qmail 18725 invoked by uid 0); 30 Jul 2002 19:37:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 30 Jul 2002 19:37:54 -0000 Received: by moria.seul.org (Postfix) id E070B14691E; Tue, 30 Jul 2002 15:37:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D0A14146925; Tue, 30 Jul 2002 15:37:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 6350014691E for ; Tue, 30 Jul 2002 15:37:53 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-5-62-147-144-194.dial.proxad.net [62.147.144.194]) by postfix2-1.free.fr (Postfix) with SMTP id BC9956FF for ; Tue, 30 Jul 2002 21:35:09 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Tue, 30 Jul 2002 20:54:46 +0200 Date: Tue, 30 Jul 2002 20:54:46 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP Message-ID: <20020730185446.GB250@free.fr> References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020730010430.29967@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 01:04:30AM +0200, Michael Riepe wrote: > On Mon, Jul 29, 2002 at 08:48:13PM +0200, Etienne LABARRE wrote: > > Hi all, > > > > New snapshot include a lot of changes and features : > > > > INC unit and CMP unit are now two different units, for simplify and > > decrease latency > > > > Both units are based to the same component : find_lsb > > It's a binary tree for find the first null lsb in a word. > > It supports SIMD operations (size of chunk = 8, 16, 32, 64, 128, 256 > > bits) > > It's based to only one function : and_reduce. It's is a standard > > function of ieee.std_logic_1164 library. > > Did you find source code or documentation for package std_logic_misc? ???? It's standard library. Packages std_logic_1164 and std_logic_misc are available with all vhdl tools. (For example, with Simili, in Simili_dir/lib/ieee/stdlogicmisc.vhd) > > I noted that you use ieee.numeric_std in your designs, which is a > no-no. Or did you include it by mistake? Oop's ! It's an error. My code don't need ieee.numeric_std... I have forgotten to remove this line. > > > Latency of find_lsb is not exactly know, but i can estimate this > > to 3 level of 4-and, and 1 level of mux, or more exactly 2 level of > > 8-and, and 1 level of mux. The precise latency is not important, > > because max latency will be fixed by timing constraints during synthetisis process. > > (It's an explain of my choice of standard function. "Just an > > Illusion" > > will can explain this more easy that me, i think...) > > I'm afraid that a timing constraint will `blow up' the unit. The problem of "6 levels of 4 and gates" is to depend to final techno. I think taht this criteria is ok for FPGA techno, but not optimized for the others. I call standard functions, because synthetisis tools will have (i hope) available pre-routed (and optimized) functions for chosen technology. ==> the code don't must depend to techno. > BTW: for 256 bits, you need *four* levels of 4-and. Exactly, but 6-levels criteria is for 64 bits only. > > > For INC unit, the data flow is : > > 1 level of mux > > find_lsb : 3 level of 4-and, 1 level of mux > > 1 level of xor > > 2 level of mux > > total is 8 levels. > > Critical datapath is only for ABS operation. > > > > Supported operations : > > INC, DEC, NEG, ABS, LSB0, LSB1 > > > > All operations are tested by my testbenches. > > > > For CMP unit, the data flow is : > > 1 level of xor, > > 1 level of mux, > > find_lsb : 3 level of 4-and, 1 level of mux > > 2 level of mux, > > total is 8 levels. > > Critical datapath is for CMP, MIN, MAX, SORT operations. > > I doubt that you can get away with 8 cycles. From my experience, 64-bit > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, > 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. Hmm, i have perhap's made an error. Can you look at my code ? Etienne. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 22:05:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljh-0001n6-00 for ; Wed, 31 Jul 2002 07:09:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:25 +0200 (CEST) Received: (qmail 25644 invoked by uid 0); 30 Jul 2002 19:56:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 30 Jul 2002 19:56:24 -0000 Received: by moria.seul.org (Postfix) id 6C30B14691E; Tue, 30 Jul 2002 15:56:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 62B46146923; Tue, 30 Jul 2002 15:56:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 1A9CD14691E for ; Tue, 30 Jul 2002 15:56:23 -0400 (EDT) Received: from f-cpu.org (kdl14-232.n.club-internet.fr [213.44.12.232]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 6203316A4 for ; Tue, 30 Jul 2002 21:56:20 +0200 (CEST) Message-ID: <3D46F195.839E1E8D@f-cpu.org> Date: Tue, 30 Jul 2002 22:05:41 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] CMP References: <002801c237ef$63bdf4e0$40f43cd0@computer> <3D46E630.5000100@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Ben Franchuk wrote: > richard hartny wrote: > > For what its worth; > > > > I use the equivalent of an SN7485 Comparator for a 64 bit result of EQU, AGB, and ALB. Requires 113 Logic cells of the Eclipse family of FPGA devices. It requires 7 logic levels and executes in 10.2 NS plus setup time of three DFF's. I can test and Branch on each of the registered outputs. > > If my Canadian counterpart (Ben) will send me his mailing address, I will send him an VHDL manual that I will never use. > > > > Dick Hartney > > I would have used a adder as I forgot about the 7485 style comparator. that is also my proposition. the ASU has a "saturated mode" and the output (unsigned mode ?) can be used to control a CMOV. Better : if there was the necessary wiring or mode, a SIMD version would be possible and the resulting bitfield would be used in a MUX instruction. Then MIN, MAX and SORT would require 2 or 3 instructructions but there would be no need of another unit. But Michael knows his unit better than me. I simply wish that the original "sub" with saturated output was implemented : MR implemented a simple bit (which is logical, in a sense) but a "-1" output would have been useful to emulate CMP. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PS: the ADDSUB instruction is very useful in DSP, and much simpler to implement than what nicO proposes... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 22:15:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljh-0001n6-01 for ; Wed, 31 Jul 2002 07:09:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:25 +0200 (CEST) Received: (qmail 9813 invoked by uid 0); 30 Jul 2002 20:05:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 30 Jul 2002 20:05:51 -0000 Received: by moria.seul.org (Postfix) id 4EF2A146920; Tue, 30 Jul 2002 16:05:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DF97146924; Tue, 30 Jul 2002 16:05:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id A80EB146920 for ; Tue, 30 Jul 2002 16:05:49 -0400 (EDT) Received: from f-cpu.org (kdl16-190.n.club-internet.fr [213.44.18.190]) by relay-5v.club-internet.fr (Postfix) with ESMTP id EA6EC16E6 for ; Tue, 30 Jul 2002 22:05:47 +0200 (CEST) Message-ID: <3D46F3CC.D270D1A5@f-cpu.org> Date: Tue, 30 Jul 2002 22:15:08 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46D87E.78D39B42@f-cpu.org> <20020730185514.GD250@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Etienne LABARRE wrote: > On Tue, Jul 30, 2002 at 08:18:38PM +0200, Yann Guidon wrote: > > hi, > Thank for this example, but i don't see _my_ error !!! Can you explain me ? sorry, i have not yet checked your code, or even integrated it. i'm working on the validation of DCT code. > Etienne. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jul 30 22:15:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zlji-0001n6-00 for ; Wed, 31 Jul 2002 07:09:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:26 +0200 (CEST) Received: (qmail 9919 invoked by uid 0); 30 Jul 2002 20:05:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 30 Jul 2002 20:05:54 -0000 Received: by moria.seul.org (Postfix) id 700C814691E; Tue, 30 Jul 2002 16:05:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45ADB146925; Tue, 30 Jul 2002 16:05:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9E86C14691E for ; Tue, 30 Jul 2002 16:05:51 -0400 (EDT) Received: from f-cpu.org (kdl16-190.n.club-internet.fr [213.44.18.190]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 62EE21694 for ; Tue, 30 Jul 2002 22:05:49 +0200 (CEST) Message-ID: <3D46F3CE.E9E8318A@f-cpu.org> Date: Tue, 30 Jul 2002 22:15:10 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> <3D467F65.60206@yahoo.fr> <20020730185526.GF250@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Etienne LABARRE wrote: > On Tue, Jul 30, 2002 at 01:58:29PM +0200, Just an Illusion wrote: > > Hi, > > I have an other one (coding style) : > > > > Defined each value of eu_inc_mode by a constant, and use them into the > > case structure. Something like : > > ... > > architecture simple of eu_inc is > > ... > > constant C_EU_INC_MODE_NEG : natural := "000" > > constant C_EU_INC_MODE_DEC : natural := "001" > > constant C_EU_INC_MODE_INC : natural := "010" > > constant C_EU_INC_MODE_ABS : natural := "011" > > constant C_EU_INC_MODE_LSB0 : natural := "100" > > constant C_EU_INC_MODE_LSB1 : natural := "101" > > ... > > > > Now, if you want change the eu_inc_mode coding values, you need modify > > it only in one place. > > > > See the coding rule I have use to immediatly link (when read) the > > constant value with the content of eu_inc_mode. > > Ok, il will modify my code. I don't wait the document had written :-) If possible, make a separate VHDL file for these constant, or better : add them to the f-cpu_config.vhdl.in file ! This way, the same constant will have the same value in all langages. This will help during the maintainance. > Etienne WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jul 31 02:23:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zlji-0001n6-01 for ; Wed, 31 Jul 2002 07:09:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:26 +0200 (CEST) Received: (qmail 10567 invoked by uid 0); 30 Jul 2002 21:18:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 30 Jul 2002 21:18:47 -0000 Received: by moria.seul.org (Postfix) id D524F146920; Tue, 30 Jul 2002 17:18:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B5994146924; Tue, 30 Jul 2002 17:18:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 77C24146920 for ; Tue, 30 Jul 2002 17:18:45 -0400 (EDT) Received: from tholana (nas-cbv-7-62-147-155-77.dial.proxad.net [62.147.155.77]) by postfix2-1.free.fr (Postfix) with ESMTP id F29273FA for ; Tue, 30 Jul 2002 23:18:43 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal Load and Store Date: Wed, 31 Jul 2002 00:23:48 +0000 X-Mailer: KMail [version 1.4] References: <1027689495.3d414c17bd2c6@imp.free.fr> <1027959267.3d4569e3ddd3c@imp.free.fr> <20020729195056.45744@thrai.stud.uni-hannover.de> In-Reply-To: <20020729195056.45744@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207310023.48744.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > That not so stupid in fact. We have our strange cachemm instruction (I > > mean what did you think about : cachemmlcV, it's fun but have no > > sense...) So why not changing it, so that we have a conditionnal cachemm. > > In that case we need 2 more bits to define a register and 3 more for the > > test. And for loadaddr we have 11 unused bits, so we can have a > > conditionnal loadaddr too. I think that taking vacancy are not so good, I > > have crazy idea when I came back ;-) > > What is a conditional loadaddr supposed to do if the condition is > false? Absolutely nothing, I mean no prefetch, no memory operation, ... > Cachemm is really strange (as well as serialize). I prefer not to > think about it ;) I think that most of us want to remove this instruction or change it a lot. In fact we need a loadaddr in a absolute mode, so why not changing it's definition to something more useful ? > > Now back to what you say, I was thinking that we make the test at start > > (before sending the job to the LSU), but if I correctly understand, we > > send all and make the test at the same time, right ? That's strange. > > If I remember correctly, the read operation of a conditional move will > be executed (because it is done at decode time) but the corresponding > write operation will never happen. This has nothing to do with the LSU, > however (the LSU is only used for memory load/store, not for moves). Ok, I understand. Hum, I now understand your question about my conditionnal loadaddr too. I don't know the cost of a conditionnal loadaddr in fact, but reducing memory bandwith is usefull, so not an easy decision. > That depends on the architecture. We can define `packets' of two, > four or even more instructions that are executed in parallel (that is, > Itanium-style EPIC), or a `stream' model that takes and executes as many > instructions as possible. In either case, jumps need special handling. Yes, and in fact some other instructions too. Like memory operation if we didn't want to explode memory bandwith. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 18:45:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljm-0001n6-00 for ; Wed, 31 Jul 2002 07:09:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:30 +0200 (CEST) Received: (qmail 26816 invoked by uid 0); 30 Jul 2002 22:29:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 30 Jul 2002 22:29:35 -0000 Received: by moria.seul.org (Postfix) id 8EA8E146923; Tue, 30 Jul 2002 18:29:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 35C1E146924; Tue, 30 Jul 2002 18:29:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 42A6B146920 for ; Tue, 30 Jul 2002 18:29:32 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00873; Tue, 30 Jul 2002 18:45:24 +0200 Message-ID: <20020730184523.54850@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 18:45:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] HDL coding rules References: <3D44FDA3.6060408@yahoo.fr> <3D458E68.8E4537C3@f-cpu.org> <3D467BEE.5060204@yahoo.fr> <3D467F65.60206@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D467F65.60206@yahoo.fr>; from Just an Illusion on Tue, Jul 30, 2002 at 01:58:29PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 01:58:29PM +0200, Just an Illusion wrote: [...] > I have an other one (coding style) : > > Defined each value of eu_inc_mode by a constant, and use them into the > case structure. Something like : > ... > architecture simple of eu_inc is > ... > constant C_EU_INC_MODE_NEG : natural := "000" > constant C_EU_INC_MODE_DEC : natural := "001" > constant C_EU_INC_MODE_INC : natural := "010" > constant C_EU_INC_MODE_ABS : natural := "011" > constant C_EU_INC_MODE_LSB0 : natural := "100" > constant C_EU_INC_MODE_LSB1 : natural := "101" No wait... binary encoded mode vectors are a bad idea - they may force the synthesizer to add unnecessary encoding and decoding circuits. I usually pass opcode selection and mode bits unencoded (or one-hot encoded if it makes sense - as in this case). The general idea is to send the `flags' portion of the instruction word directly to the EU and let the EU pick the appropriate bits (the size bits are handled separately because they need a table lookup). The opcode is decoded once inside IF/ID, and the result is sent to the EUs. NB: If you define constants that are going to be used in an entity interface, it doesn't make sense to define them inside the architecture body (where they are invisible). Better put them in a package. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 16:43:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljm-0001n6-01 for ; Wed, 31 Jul 2002 07:09:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:30 +0200 (CEST) Received: (qmail 32673 invoked by uid 0); 30 Jul 2002 22:29:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 30 Jul 2002 22:29:38 -0000 Received: by moria.seul.org (Postfix) id 6F6F6146920; Tue, 30 Jul 2002 18:29:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B63814692F; Tue, 30 Jul 2002 18:29:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 708BB146920 for ; Tue, 30 Jul 2002 18:29:34 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00591; Tue, 30 Jul 2002 16:43:03 +0200 Message-ID: <20020730164303.55106@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 16:43:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <3D465C6B.9010606@yahoo.fr> <3D466957.EE585F7B@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D466957.EE585F7B@f-cpu.org>; from Yann Guidon on Tue, Jul 30, 2002 at 12:24:23PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 12:24:23PM +0200, Yann Guidon wrote: > hi ! > > Just an Illusion wrote: > > Hello, > > > > I have read your code and, unfortunately, I have found an > > unsynthesisable structure : > > > > tree_find_lsb : entity find_lsb > > ^^^^^ > > the entity keyword is not supported at this position. > > does that mean that it must use the "duplicated" form of > declaration+use ? That's the preferred form anyway. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 16:42:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljn-0001n6-00 for ; Wed, 31 Jul 2002 07:09:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:31 +0200 (CEST) Received: (qmail 7426 invoked by uid 0); 30 Jul 2002 22:29:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 30 Jul 2002 22:29:39 -0000 Received: by moria.seul.org (Postfix) id 2BC66146924; Tue, 30 Jul 2002 18:29:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E706214692F; Tue, 30 Jul 2002 18:29:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 3A342146930 for ; Tue, 30 Jul 2002 18:29:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00584; Tue, 30 Jul 2002 16:42:28 +0200 Message-ID: <20020730164227.44869@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 16:42:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <3D465C6B.9010606@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D465C6B.9010606@yahoo.fr>; from Just an Illusion on Tue, Jul 30, 2002 at 11:29:15AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 11:29:15AM +0200, Just an Illusion wrote: > Hello, > > I have read your code and, unfortunately, I have found an > unsynthesisable structure : > > tree_find_lsb : entity find_lsb > ^^^^^ > the entity keyword is not supported at this position. Huh? It is supported in VHDL'93. Did they remove it again? > See IEEE P1076.6-2001 for more information on VHDL RTL synthesis subset. > > Just an Illusion > > PS : If some one need a version of the IEEE P1076.6-2001 standard, I can > upload a version on seul.org. Yes, please. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jul 30 16:40:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljn-0001n6-01 for ; Wed, 31 Jul 2002 07:09:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:31 +0200 (CEST) Received: (qmail 6497 invoked by uid 0); 30 Jul 2002 22:29:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 30 Jul 2002 22:29:42 -0000 Received: by moria.seul.org (Postfix) id AAFFE146930; Tue, 30 Jul 2002 18:29:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80864146935; Tue, 30 Jul 2002 18:29:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 12DAE146930 for ; Tue, 30 Jul 2002 18:29:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00575; Tue, 30 Jul 2002 16:40:08 +0200 Message-ID: <20020730164008.33596@thrai.stud.uni-hannover.de> Date: Tue, 30 Jul 2002 16:40:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <3D465364.8040000@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D465364.8040000@yahoo.fr>; from Just an Illusion on Tue, Jul 30, 2002 at 10:50:44AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 10:50:44AM +0200, Just an Illusion wrote: [...] > >Did you find source code or documentation for package std_logic_misc? > > > The source code, of course. If some one need it, I can send it. Yes, please. > Like Whygee has previously said me this is not a ieee package (it's > copyrighted Synopsis), it is why I have never said than it is a > normalized package of ieee. But in the header of the package, Synopsis > give right to use this package without restriction. Hmm... someone claimed that it is a standard package. That was obviously wrong. [...] > >I'm afraid that a timing constraint will `blow up' the unit. > >BTW: for 256 bits, you need *four* levels of 4-and. > > > If your target techno have it. More the timing can change if your target > techno have native 8-and or more. We can't rely on that. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 00:46:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljo-0001n6-00 for ; Wed, 31 Jul 2002 07:09:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:32 +0200 (CEST) Received: (qmail 22242 invoked by uid 0); 30 Jul 2002 22:46:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 30 Jul 2002 22:46:41 -0000 Received: by moria.seul.org (Postfix) id 13030146920; Tue, 30 Jul 2002 18:46:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5865146924; Tue, 30 Jul 2002 18:46:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 9B4CE146920 for ; Tue, 30 Jul 2002 18:46:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00671; Wed, 31 Jul 2002 00:46:40 +0200 Message-ID: <20020731004640.61052@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 00:46:40 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D46C656.2030207@yahoo.fr>; from Just an Illusion on Tue, Jul 30, 2002 at 07:01:10PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 07:01:10PM +0200, Just an Illusion wrote: > Hello, > > The variable H and L can't be used to calculate the size of B, more they > are unnecessary. That's not the point. In fact, the function works fine under certain circumstances. In other cases, it does *nothing* (namely, when the argument is declared with an ascending index range). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 01:13:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljo-0001n6-01 for ; Wed, 31 Jul 2002 07:09:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:32 +0200 (CEST) Received: (qmail 13991 invoked by uid 0); 30 Jul 2002 23:14:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 30 Jul 2002 23:14:02 -0000 Received: by moria.seul.org (Postfix) id 983D5146923; Tue, 30 Jul 2002 19:14:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7989C146925; Tue, 30 Jul 2002 19:14:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id DE7B5146923 for ; Tue, 30 Jul 2002 19:13:59 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00754; Wed, 31 Jul 2002 01:13:58 +0200 Message-ID: <20020731011358.22755@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 01:13:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> <20020730185508.GC250@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020730185508.GC250@free.fr>; from Etienne LABARRE on Tue, Jul 30, 2002 at 08:55:08PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 08:55:08PM +0200, Etienne LABARRE wrote: [...] > And i don't see what's wrong, it's works fine with simili. Is it luke ? It works fine as long as the argument is declared with a descending (high downto low) array index range. When the index range is ascending (low to high), the function will not reverse the bits but copy them. BTW: you can use work.Bit_Manipulation.bit_reverse instead. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 01:33:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljq-0001n6-00 for ; Wed, 31 Jul 2002 07:09:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:34 +0200 (CEST) Received: (qmail 30319 invoked by uid 0); 30 Jul 2002 23:33:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 30 Jul 2002 23:33:24 -0000 Received: by moria.seul.org (Postfix) id B8A8B14691B; Tue, 30 Jul 2002 19:33:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE793146925; Tue, 30 Jul 2002 19:33:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 3EB1914691B for ; Tue, 30 Jul 2002 19:33:20 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00808; Wed, 31 Jul 2002 01:33:18 +0200 Message-ID: <20020731013318.26538@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 01:33:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=6R2i8wDzkSurJwd6 X-Mailer: Mutt 0.84e In-Reply-To: <20020730185446.GB250@free.fr>; from Etienne LABARRE on Tue, Jul 30, 2002 at 08:54:46PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --6R2i8wDzkSurJwd6 Content-Type: text/plain; charset=us-ascii On Tue, Jul 30, 2002 at 08:54:46PM +0200, Etienne LABARRE wrote: [...] > > Did you find source code or documentation for package std_logic_misc? > > ???? It's standard library. Packages std_logic_1164 and std_logic_misc > are available with all vhdl tools. > (For example, with Simili, in Simili_dir/lib/ieee/stdlogicmisc.vhd) A `standard' is something people have agreed on. Not everything that is found in library std or library ieee is a standard (especially if you use Synopsys). [...] > ==> the code don't must depend to techno. Therefore we only use elements that are supposed to be available everywhere: and/or gates with 2...4 inputs, 2-input xor gates, inverters and muxes. With the famous `6 Gate Rule', any of them count as 1 gate. Bigger elements (like an 8-input and gate) count as 2 or more gates. After the first synthesis experiences, I later added another rule: 2-input xors count as 2 gates, and the sum of gate delays must not exceed 10. I call this the `6G/10T' rule. [...] > > I doubt that you can get away with 8 cycles. From my experience, 64-bit > > CMP alone needs 1 level of 2-xor, 3 levels of 4-and, 1 level of 2-xor, > > 1 level of 2-and plus 3 levels of 4-or, giving a total of 9 levels. > > Hmm, i have perhap's made an error. Can you look at my code ? You have made many errors, according to my testbench for eu_cmp. CMP is supposed to be either 0 or -1: cmp(a, b) = a < b ? -1 : 0. MSB1 is supposed to return the *number* of the most significant `1' bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some strange bit mask. Likewise for MSB0. I'll attach a testbench for eu_cmp. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --6R2i8wDzkSurJwd6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="eu_cmp_test_mr.vhdl" -- eu_cmp_test_mr.vhdl -- Testbench for eu_cmp -- Copyright (C) 2001, 2002 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- $Id: icmp64_test.vhdl,v 1.1 2002/07/26 16:58:20 michael Exp $ --pragma synthesis_off library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use std.textio.all; use IEEE.std_logic_textio.all; --use work.Bit_Manipulation.all; entity eu_cmp_test is end eu_cmp_test; architecture Arch_1 of eu_cmp_test is component eu_cmp generic ( eu_cmp_width : natural := 6 ); port ( eu_cmp_A : in std_ulogic_vector(2**eu_cmp_width-1 downto 0); eu_cmp_B : in std_ulogic_vector(2**eu_cmp_width-1 downto 0); eu_cmp_simd : in std_ulogic_vector(eu_cmp_width-4 downto 0); eu_cmp_mode : in std_ulogic_vector(2 downto 0); eu_cmp_Y : out std_ulogic_vector(2**eu_cmp_width-1 downto 0); eu_cmp_Z : out std_ulogic_vector(2**eu_cmp_width-1 downto 0) ); end component; constant WIDTH : natural := 64; signal M : std_ulogic_vector(5 downto 0) := (others => '0'); signal A, B, Y, Z : std_ulogic_vector(WIDTH-1 downto 0) := (others => '0'); signal Clk : std_ulogic := '0'; signal Rst : std_ulogic := '0'; signal En : std_ulogic := '1'; procedure writestr (s : string) is variable lout : line; begin write(lout, s); writeline(output, lout); end writestr; procedure print_vector (lbl : string; x : std_ulogic_vector; des : string := " := ") is variable lout : line; begin write(lout, lbl & des); write(lout, x); writeline(output, lout); end print_vector; procedure print_signals is begin print_vector("A", A); print_vector("B", B); print_vector("M", M); print_vector("Y", Y); print_vector("Z", Z); end print_signals; procedure do_error (lbl : string; a_x, a_y : std_ulogic_vector) is begin writestr("WHOA THERE!!!"); print_signals; print_vector(lbl, a_x); print_vector(lbl, a_y, " /= "); end do_error; procedure check_numeric (lbl : string; x : std_ulogic_vector; y : natural) is variable tmp : std_ulogic_vector(x'range); variable lout : line; begin tmp := std_ulogic_vector(to_unsigned(y rem 2**x'length, x'length)); if x /= tmp then do_error(lbl, x, tmp); end if; end check_numeric; procedure check_logic (lbl : string; a, b : std_ulogic_vector) is alias x : std_ulogic_vector(a'length downto 1) is a; alias y : std_ulogic_vector(b'length downto 1) is b; variable lout : line; begin assert a'length = b'length report "bad args in check_logic" severity failure; for i in x'range loop next when y(i) = '-'; next when x(i) = y(i); do_error(lbl, x, y); return; end loop; end check_logic; begin -- module under test mut : eu_cmp generic map (eu_cmp_width => 6) port map ( eu_cmp_A => A, eu_cmp_B => B, eu_cmp_simd => M(5 downto 3), eu_cmp_mode => M(2 downto 0), eu_cmp_Y => Y, eu_cmp_Z => Z ); -- driver process process constant std_ulogic_0 : std_ulogic := '0'; constant std_ulogic_1 : std_ulogic := '1'; procedure do_clock is begin wait for 1 ns; -- Clk <= '1'; -- wait for 1 ns; -- Clk <= '0'; end do_clock; procedure print_mode (simd : in natural) is variable lout : line; begin write(lout, string'("*** testing ")); write(lout, simd); write(lout, string'("-bit mode ***")); writeline(output, lout); end print_mode; procedure test_ucmp is variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable simd, left, right : natural; begin writestr("*** testing unsigned cmp ***"); for gran in 0 to 3 loop simd := 8 * 2**gran; print_mode(simd); M <= "XXX000"; for i in 3 to 5 loop if i < gran + 3 then M(i) <= '1'; else M(i) <= '0'; end if; end loop; for chunk in 0 to WIDTH/simd-1 loop right := chunk*simd; left := right + simd - 1; av := (others => 'X'); bv := (others => 'X'); tmp := (others => '-'); for index in left downto right loop av(index) := '0'; bv(index) := '1'; tmp(left downto right) := (left downto right => '1'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(index) := '1'; bv(index) := '0'; tmp(left downto right) := (left downto right => '0'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(index) := '0'; end loop; end loop; end loop; end test_ucmp; procedure test_scmp is variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable simd, left, right : natural; begin writestr("*** testing signed cmp ***"); for gran in 0 to 3 loop simd := 8 * 2**gran; print_mode(simd); M <= "XXX000"; for i in 3 to 5 loop if i < gran + 3 then M(i) <= '1'; else M(i) <= '0'; end if; end loop; for chunk in 0 to WIDTH/simd-1 loop right := chunk*simd; left := right + simd - 1; av := (others => 'X'); bv := (others => 'X'); tmp := (others => '-'); av(left) := '0'; bv(left) := '1'; tmp(left downto right) := (left downto right => '0'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(left) := '1'; bv(left) := '0'; tmp(left downto right) := (left downto right => '1'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); bv(left) := '1'; for index in left-1 downto right loop av(index) := '0'; bv(index) := '1'; tmp(left downto right) := (left downto right => '1'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(index) := '1'; bv(index) := '0'; tmp(left downto right) := (left downto right => '0'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(index) := '0'; end loop; end loop; end loop; end test_scmp; procedure test_usort is variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable simd, left, right : natural; begin writestr("*** testing unsigned sort ***"); for gran in 0 to 3 loop simd := 8 * 2**gran; print_mode(simd); M <= "XXX011"; for i in 3 to 5 loop if i < gran + 3 then M(i) <= '1'; else M(i) <= '0'; end if; end loop; for chunk in 0 to WIDTH/simd-1 loop right := chunk*simd; left := right + simd - 1; av := (others => 'X'); -- XXX: should use random data bv := (others => 'X'); -- XXX: should use random data tmp := (others => '-'); for index in left downto right loop av(index) := '0'; bv(index) := '1'; A <= av; B <= bv; do_clock; tmp(left downto right) := av(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := bv(left downto right); check_logic("Z", Z, tmp); av(index) := '1'; bv(index) := '0'; A <= av; B <= bv; do_clock; tmp(left downto right) := bv(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := av(left downto right); check_logic("Z", Z, tmp); av(index) := '0'; end loop; end loop; end loop; end test_usort; procedure test_ssort is variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable simd, left, right : natural; begin writestr("*** testing signed sort ***"); for gran in 0 to 3 loop simd := 8 * 2**gran; print_mode(simd); M <= "XXX011"; for i in 3 to 5 loop if i < gran + 3 then M(i) <= '1'; else M(i) <= '0'; end if; end loop; for chunk in 0 to WIDTH/simd-1 loop right := chunk*simd; left := right + simd - 1; av := (others => 'X'); -- XXX: should use random data bv := (others => 'X'); -- XXX: should use random data tmp := (others => '-'); av(left) := '0'; bv(left) := '1'; A <= av; B <= bv; do_clock; tmp(left downto right) := bv(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := av(left downto right); check_logic("Z", Z, tmp); av(left) := '1'; bv(left) := '0'; A <= av; B <= bv; do_clock; tmp(left downto right) := av(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := bv(left downto right); check_logic("Z", Z, tmp); bv(left) := '1'; for index in left-1 downto right loop av(index) := '0'; bv(index) := '1'; A <= av; B <= bv; do_clock; tmp(left downto right) := av(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := bv(left downto right); check_logic("Z", Z, tmp); av(index) := '1'; bv(index) := '0'; A <= av; B <= bv; do_clock; tmp(left downto right) := bv(left downto right); check_logic("Y", Y, tmp); tmp(left downto right) := av(left downto right); check_logic("Z", Z, tmp); av(index) := '0'; end loop; end loop; end loop; end test_ssort; procedure test_msb (bit : in std_ulogic) is variable av, bv, tmp : std_ulogic_vector(WIDTH-1 downto 0); variable simd, left, right : natural; variable lout : line; begin write(lout, string'("*** testing msb")); write(lout, bit); write(lout, string'(" ***")); writeline(output, lout); for gran in 0 to 3 loop simd := 8 * 2**gran; print_mode(simd); M <= "XXX10X"; M(0) <= bit; for i in 3 to 5 loop if i < gran + 3 then M(i) <= '1'; else M(i) <= '0'; end if; end loop; for chunk in 0 to WIDTH/simd-1 loop right := chunk*simd; left := right + simd - 1; av := (others => 'X'); av(left downto right) := (left downto right => not bit); bv := (others => 'X'); tmp := (others => '-'); tmp(left downto right) := (left downto right => '0'); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); for index in right to left loop av(index) := bit; tmp(left downto right) := std_ulogic_vector( to_unsigned(index - right + 1, simd)); A <= av; B <= bv; do_clock; check_logic("Y", Y, tmp); av(index) := 'X'; end loop; end loop; end loop; end test_msb; begin test_ucmp; -- test_scmp; test_usort; -- test_ssort; test_msb('0'); test_msb('1'); -- stop simulation writestr("*** simulation complete ***"); wait; end process; end Arch_1; --pragma synthesis_on -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --6R2i8wDzkSurJwd6-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 01:40:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljs-0001n6-00 for ; Wed, 31 Jul 2002 07:09:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:36 +0200 (CEST) Received: (qmail 21117 invoked by uid 0); 30 Jul 2002 23:40:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 30 Jul 2002 23:40:52 -0000 Received: by moria.seul.org (Postfix) id 1DABB14691B; Tue, 30 Jul 2002 19:40:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 120C2146925; Tue, 30 Jul 2002 19:40:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 84B4A14691B for ; Tue, 30 Jul 2002 19:40:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00833; Wed, 31 Jul 2002 01:40:48 +0200 Message-ID: <20020731014047.34883@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 01:40:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CMP References: <002801c237ef$63bdf4e0$40f43cd0@computer> <3D46E630.5000100@jetnet.ab.ca> <3D46F195.839E1E8D@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D46F195.839E1E8D@f-cpu.org>; from Yann Guidon on Tue, Jul 30, 2002 at 10:05:41PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 10:05:41PM +0200, Yann Guidon wrote: [...] > that is also my proposition. the ASU has a "saturated mode" > and the output (unsigned mode ?) can be used to control > a CMOV. Better : if there was the necessary wiring or mode, > a SIMD version would be possible and the resulting bitfield > would be used in a MUX instruction. Then MIN, MAX and SORT > would require 2 or 3 instructructions but there would > be no need of another unit. With the `subb' instruction, you can't do signed compare/min/max/sort. With my version of EU_CMP, you can. > But Michael knows his unit better than me. I simply wish that > the original "sub" with saturated output was implemented : > MR implemented a simple bit (which is logical, in a sense) > but a "-1" output would have been useful to emulate CMP. Just negate the carry/borrow output. There is only a single bit because otherwise, I had to distinguish between `addc' and `subb'. The way it is now, the carry logic is completely shared between both operations. If that's not a damn good reason, there never was one. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 31 01:44:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zljs-0001n6-01 for ; Wed, 31 Jul 2002 07:09:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:36 +0200 (CEST) Received: (qmail 22207 invoked by uid 0); 30 Jul 2002 23:47:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 30 Jul 2002 23:47:57 -0000 Received: by moria.seul.org (Postfix) id 1146614691B; Tue, 30 Jul 2002 19:47:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ECAF2146925; Tue, 30 Jul 2002 19:47:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 78D1414691B for ; Tue, 30 Jul 2002 19:47:55 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-208.jetnet.ab.ca [207.34.60.208]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6UNlth1061573 for ; Tue, 30 Jul 2002 17:47:56 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D4724E1.10109@jetnet.ab.ca> Date: Tue, 30 Jul 2002 17:44:33 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > Therefore we only use elements that are supposed to be available > everywhere: and/or gates with 2...4 inputs, 2-input xor gates, inverters > and muxes. With the famous `6 Gate Rule', any of them count as 1 gate. > Bigger elements (like an 8-input and gate) count as 2 or more gates. > > After the first synthesis experiences, I later added another rule: > 2-input xors count as 2 gates, and the sum of gate delays must not > exceed 10. I call this the `6G/10T' rule. What about inverted inputs? Do they count as a gate and what about flip/flop set up and delay times and what memory elements can one count on. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 31 04:18:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zlju-0001n6-00 for ; Wed, 31 Jul 2002 07:09:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 07:09:38 +0200 (CEST) Received: (qmail 6885 invoked by uid 0); 31 Jul 2002 02:08:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 31 Jul 2002 02:08:46 -0000 Received: by moria.seul.org (Postfix) id 2A6C8146924; Tue, 30 Jul 2002 22:08:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E16CC14692F; Tue, 30 Jul 2002 22:08:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 81C1F146924 for ; Tue, 30 Jul 2002 22:08:44 -0400 (EDT) Received: from f-cpu.org (kdl11-12.n.club-internet.fr [213.44.9.12]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 64D491696 for ; Wed, 31 Jul 2002 04:08:41 +0200 (CEST) Message-ID: <3D4748DA.513D0F89@f-cpu.org> Date: Wed, 31 Jul 2002 04:18:02 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Tue, Jul 30, 2002 at 08:54:46PM +0200, Etienne LABARRE wrote: > [...] > > > Did you find source code or documentation for package std_logic_misc? > > ???? It's standard library. Packages std_logic_1164 and std_logic_misc > > are available with all vhdl tools. > > (For example, with Simili, in Simili_dir/lib/ieee/stdlogicmisc.vhd) > A `standard' is something people have agreed on. Not everything that > is found in library std or library ieee is a standard (especially if > you use Synopsys). i'll agree with MR as long as no deecisive argument is found. > [...] > > ==> the code don't must depend to techno. > > Therefore we only use elements that are supposed to be available > everywhere: and/or gates with 2...4 inputs, 2-input xor gates, inverters > and muxes. With the famous `6 Gate Rule', any of them count as 1 gate. > Bigger elements (like an 8-input and gate) count as 2 or more gates. yep, because the technology must be "portable"... btw, sometimes i make big "ORs" with a code like a <= '1' when b /= "0000000000" else '0'; is this technology dependent enough ? :-) Ben Franchuk wrote: > What about inverted inputs? Do they count as a gate and what about > flip/flop set up and delay times and what memory elements can > one count on. Inverted inputs and outputs are usually rather well handled by the synthesisers and optimisers, so they are not taken into account. most "standard" libraries contain gates with one or more inverted inputs and outputs, so it's again technology dependent, but transparent. What matters most is to have balanced, short and simple pipeline stages to ensure the highest clock frequency possible. > After the first synthesis experiences, I later added another rule: > 2-input xors count as 2 gates, and the sum of gate delays must not > exceed 10. I call this the `6G/10T' rule. what is 'T' ? > [...] > MSB1 is supposed to return the *number* of the most significant `1' > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some > strange bit mask. Likewise for MSB0. This feature has been dropped, particularly if popc is implemented : you can feed the bit mast to POPC which will return the number of bits. Of course there are faster ways to implement that, but there is no reason of adding one cycle of latency to the units. Particularly if it's not used often. > I'll attach a testbench for eu_cmp. > > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 31 09:43:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zoh3-0003t6-01 for ; Wed, 31 Jul 2002 10:18:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 10:18:53 +0200 (CEST) Received: (qmail 12372 invoked by uid 0); 31 Jul 2002 07:52:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 31 Jul 2002 07:52:57 -0000 Received: by moria.seul.org (Postfix) id 473B114640E; Wed, 31 Jul 2002 03:52:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38957146925; Wed, 31 Jul 2002 03:52:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id A672514640E for ; Wed, 31 Jul 2002 03:52:56 -0400 (EDT) Received: (qmail 1182 invoked by uid 85); 31 Jul 2002 07:49:52 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.24411 secs); 31 Jul 2002 07:49:52 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 31 Jul 2002 07:49:52 -0000 Message-ID: <3D479516.9000106@yahoo.fr> Date: Wed, 31 Jul 2002 09:43:18 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> <20020730185508.GC250@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, Etienne LABARRE wrote: >On Tue, Jul 30, 2002 at 07:01:10PM +0200, Just an Illusion wrote: > >>Hello, >> >>The variable H and L can't be used to calculate the size of B, more they >>are unnecessary. >> >>When you call the function inv_word with a vector, the A'HIGH and the >>A'LOW aren't referred to the real size of the vecteur, but the part >>connected. >> >>The good version is more like : >> >>function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is >> variable B : std_ulogic_vector ( A'HIGH downto 0); >>begin >> for i in 0 to B'HIGH loop >> B(i)=A(A'HIGH-i); >> end loop; >>end inv_word; >> >>or >> >>function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is >> variable B : std_ulogic_vector ( A'LENGHT-1 downto 0); >>begin >> for i in 0 to B'LENGHT-1 loop >> B(i)=A(A'LENGHT-1-i); >> end loop; >>end inv_word; >> >>Or any combinaison of both. >> > >My problem is : >Input vector maybe 0 to length-1, but low index can be not null. And i >want a output vector with same range as input. > From the point of view of the function, the size of the input vector isn't given by index. Take the following exemple : .... signal input,result1, result2 : std_ulogic_vector (4 downto 0); signal other_input : std_ulogic_vector(7 downto 0); .... result1 <= inv_word(input); result2 <= inv_word(other_input(6 downto 2); .... In that both case (result1 and result2), the function see only a vector of size 5-bits, whatever index values. > >And i don't see what's wrong, it's works fine with simili. Is it luke ? > Perhaps. Or perhaps you have see something wrong that are lucky equivalent to what you want. > >Etienne. >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 31 09:45:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zoh4-0003t6-00 for ; Wed, 31 Jul 2002 10:18:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 10:18:54 +0200 (CEST) Received: (qmail 29572 invoked by uid 0); 31 Jul 2002 07:55:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 31 Jul 2002 07:55:06 -0000 Received: by moria.seul.org (Postfix) id 65A491467F9; Wed, 31 Jul 2002 03:55:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CF2014692F; Wed, 31 Jul 2002 03:55:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id C95871467F9 for ; Wed, 31 Jul 2002 03:55:04 -0400 (EDT) Received: (qmail 1320 invoked by uid 85); 31 Jul 2002 07:52:00 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.814479 secs); 31 Jul 2002 07:52:00 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 31 Jul 2002 07:51:59 -0000 Message-ID: <3D479595.3080506@yahoo.fr> Date: Wed, 31 Jul 2002 09:45:25 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sorry, I have made a little mistake, I have forgot the return line. Just an Illusion wrote: > Hello, > > The variable H and L can't be used to calculate the size of B, more > they are unnecessary. > > When you call the function inv_word with a vector, the A'HIGH and the > A'LOW aren't referred to the real size of the vecteur, but the part > connected. > > The good version is more like : > > function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is > variable B : std_ulogic_vector ( A'HIGH downto 0); > begin > for i in 0 to B'HIGH loop > B(i)=A(A'HIGH-i); > end loop; return B; > > end inv_word; > > or > > function inv_word (A : in std_ulogic_vector) return std_ulogic_vector is > variable B : std_ulogic_vector ( A'LENGHT-1 downto 0); > begin > for i in 0 to B'LENGHT-1 loop > B(i)=A(A'LENGHT-1-i); > end loop; return B; > > end inv_word; > > Or any combinaison of both. > > > Michael Riepe wrote: > >> Ok... can anybody tell me what's wrong with this function? >> >> function inv_word(A : in std_ulogic_vector) return >> std_ulogic_vector is >> variable L : natural := A'low; >> variable H : natural := A'high; >> variable B : std_ulogic_vector(H downto L); >> begin >> for i in L to H loop >> B(i) := A(H+L-i); >> end loop; >> return B; >> end function; >> >> Hint: consider the possible index ranges of the argument. >> > Just an Illusion > Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 31 10:02:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zoh5-0003t6-00 for ; Wed, 31 Jul 2002 10:18:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 10:18:55 +0200 (CEST) Received: (qmail 21119 invoked by uid 0); 31 Jul 2002 08:02:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 31 Jul 2002 08:02:40 -0000 Received: by moria.seul.org (Postfix) id D5C2014640E; Wed, 31 Jul 2002 04:02:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6554E14692F; Wed, 31 Jul 2002 04:02:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 5B91E14640E for ; Wed, 31 Jul 2002 04:02:35 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207310802.1760; Wed, 31 Jul 2002 08:02:23 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] New snapshot for EU_INC and EU_CMP From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jul 2002 08:02:23 GMT Message-id: <200207310802.1760@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N "Some" people beleive if as much effort will be put in desig= ning a goog CAML compiler it could go faster than a c++ compiler. Why because instruction are at a very high level and the sem= antics have no side effect : so a lot of optimising could be done. (imag= ine what could be done if C language support vector operation as matl= ab, we could use SIMD of every size we want and do strip mining and so on= e.) That's the same thing in VHDL if you directly use AND gate, = the optimiser will have great problem. If youre code are "simple= " it could find lot of think to speed it up. SOI technology didn't have the same difference in speed for = large gate than classic silicium (8 input AND isn't so slow compare to = a 2 input AND).=20 nicO -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 31/07/02 Objet: Re: [f-cpu] New snapshot for EU_INC and EU_CMP On Tue, Jul 30, 2002 at 10:50:44AM +0200, Just an Illusion w= rote: [...] > >Did you find source code or documentation for package std= _logic_misc? > > > The source code, of course. If some one need it, I can sen= d it. Yes, please. > Like Whygee has previously said me this is not a ieee pack= age (it's=20 > copyrighted Synopsis), it is why I have never said than it= is a=20 > normalized package of ieee. But in the header of the packa= ge, Synopsis > give right to use this package without restriction. Hmm... someone claimed that it is a standard package. That w= as obviously wrong. [...] > >I'm afraid that a timing constraint will `blow up' the un= it. > >BTW: for 256 bits, you need *four* levels of 4-and. > > > If your target techno have it. More the timing can change = if your target=20 > techno have native 8-and or more. We can't rely on that. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 31 10:00:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zoh5-0003t6-01 for ; Wed, 31 Jul 2002 10:18:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 10:18:55 +0200 (CEST) Received: (qmail 5025 invoked by uid 0); 31 Jul 2002 08:09:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 31 Jul 2002 08:09:48 -0000 Received: by moria.seul.org (Postfix) id 7014914640E; Wed, 31 Jul 2002 04:09:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 432AA146930; Wed, 31 Jul 2002 04:09:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 8879814640E for ; Wed, 31 Jul 2002 04:09:46 -0400 (EDT) Received: (qmail 2139 invoked by uid 85); 31 Jul 2002 08:06:42 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.355056 secs); 31 Jul 2002 08:06:42 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 31 Jul 2002 08:06:41 -0000 Message-ID: <3D479907.7010400@yahoo.fr> Date: Wed, 31 Jul 2002 10:00:07 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> <20020731004640.61052@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, Michael Riepe wrote: >On Tue, Jul 30, 2002 at 07:01:10PM +0200, Just an Illusion wrote: > >>Hello, >> >>The variable H and L can't be used to calculate the size of B, more they >>are unnecessary. >> > >That's not the point. In fact, the function works fine under certain >circumstances. In other cases, it does *nothing* (namely, when the >argument is declared with an ascending index range). > You can't use H and L to define size of B because their initial values are ignored during synthesis phase. A good way to suppress that type of error is removing all initial values. They are used only during simulation and they are no "true" physical reality. Before the power up and the reset/preset phase, you have no way to give the flip-flop and memory values. If the function works fine under certain circumstances, it is only by chance. Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 31 10:16:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZrGs-0005t3-00 for ; Wed, 31 Jul 2002 13:04:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 13:04:02 +0200 (CEST) Received: (qmail 1815 invoked by uid 0); 31 Jul 2002 08:25:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 31 Jul 2002 08:25:50 -0000 Received: by moria.seul.org (Postfix) id D451514640E; Wed, 31 Jul 2002 04:25:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0C35146925; Wed, 31 Jul 2002 04:25:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id D78B314640E for ; Wed, 31 Jul 2002 04:25:48 -0400 (EDT) Received: (qmail 2626 invoked by uid 85); 31 Jul 2002 08:22:44 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 1.330749 secs); 31 Jul 2002 08:22:44 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 31 Jul 2002 08:22:43 -0000 Message-ID: <3D479CC9.1000107@yahoo.fr> Date: Wed, 31 Jul 2002 10:16:09 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, Michael Riepe wrote: >On Tue, Jul 30, 2002 at 08:54:46PM +0200, Etienne LABARRE wrote: >[...] > >>>Did you find source code or documentation for package std_logic_misc? >>> >>???? It's standard library. Packages std_logic_1164 and std_logic_misc >>are available with all vhdl tools. >>(For example, with Simili, in Simili_dir/lib/ieee/stdlogicmisc.vhd) >> > >A `standard' is something people have agreed on. Not everything that >is found in library std or library ieee is a standard (especially if >you use Synopsys). > But which people ? When you can found this package in standard version of Synopsis, Mentor Graphics and Cadence tools, you can say than this a 'standard' package de facto. If you reply than you have some other tools which doesn't support this, I can only say than this 3 societies cover between 80% and 90% of the EDA market tools (this is a fact), and the 'standard' (and indirectly the norme) are decided by them. Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jul 31 10:34:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZrGt-0005t3-00 for ; Wed, 31 Jul 2002 13:04:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 13:04:03 +0200 (CEST) Received: (qmail 15831 invoked by uid 0); 31 Jul 2002 08:44:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 31 Jul 2002 08:44:03 -0000 Received: by moria.seul.org (Postfix) id 917FD14640E; Wed, 31 Jul 2002 04:44:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7EAA6146925; Wed, 31 Jul 2002 04:44:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id C92C914640E for ; Wed, 31 Jul 2002 04:44:01 -0400 (EDT) Received: (qmail 3272 invoked by uid 85); 31 Jul 2002 08:40:57 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.339911 secs); 31 Jul 2002 08:40:57 -0000 Received: from unknown (HELO yahoo.fr) (192.168.3.4) by menator with SMTP; 31 Jul 2002 08:40:57 -0000 Message-ID: <3D47A10F.7080103@yahoo.fr> Date: Wed, 31 Jul 2002 10:34:23 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Add documents on ftp.seul.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, I have upload two (2) documents on the ftp.seul.org/pub/f-cpu/contrib server. std_logic_misc.vhd - This is the official source of the Synopsis standard package which define some function like and_reduce 20010906.pdf - This is the official DRAFT version of proposal for the norme IEEE 1076.6 For people who don't know what is a DRAFT version. A draft version isn't the definitive version, but it's quite similar. Some modification can be made on it, generally by add new support or mandatory requirement (rarelly by suppression). At present time, any society who try to develop some eda tools compliance with the ieee 1076.6 based their job on this version or previous one (which is more restrictive). Then we can restrict the coding rule and style to the mandatory and supported parts of this document. Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 02:16:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zt02-0007I6-00 for ; Wed, 31 Jul 2002 14:54:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 14:54:46 +0200 (CEST) Received: (qmail 16559 invoked by uid 0); 31 Jul 2002 11:54:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 31 Jul 2002 11:54:47 -0000 Received: by moria.seul.org (Postfix) id 90F871467FE; Wed, 31 Jul 2002 07:54:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8298714692F; Wed, 31 Jul 2002 07:54:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a054.home.uni-hannover.de [130.75.232.54]) by moria.seul.org (Postfix) with ESMTP id EC4761467FE for ; Wed, 31 Jul 2002 07:54:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00968; Wed, 31 Jul 2002 02:16:07 +0200 Message-ID: <20020731021607.62316@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 02:16:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <3D4724E1.10109@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D4724E1.10109@jetnet.ab.ca>; from Ben Franchuk on Tue, Jul 30, 2002 at 05:44:33PM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Jul 30, 2002 at 05:44:33PM -0600, Ben Franchuk wrote: > Michael Riepe wrote: > > > > Therefore we only use elements that are supposed to be available > > everywhere: and/or gates with 2...4 inputs, 2-input xor gates, inverters > > and muxes. With the famous `6 Gate Rule', any of them count as 1 gate. > > Bigger elements (like an 8-input and gate) count as 2 or more gates. > > > > After the first synthesis experiences, I later added another rule: > > 2-input xors count as 2 gates, and the sum of gate delays must not > > exceed 10. I call this the `6G/10T' rule. > > What about inverted inputs? Do they count as a gate and what about > flip/flop set up and delay times and what memory elements can > one count on. I count inverters as gates. Since it's a `rule of thumb' that applies only to the combinatorial parts of the F-CPU, flipflops are not covered. Memory elements haven't been interesting for me because I currently deal only with the execution units, not with caches or the register set. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jul 31 14:19:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zt02-0007I6-01 for ; Wed, 31 Jul 2002 14:54:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 14:54:46 +0200 (CEST) Received: (qmail 9251 invoked by uid 0); 31 Jul 2002 12:10:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 31 Jul 2002 12:10:39 -0000 Received: by moria.seul.org (Postfix) id EB622146925; Wed, 31 Jul 2002 08:10:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CA447146930; Wed, 31 Jul 2002 08:10:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 8A1DA146925 for ; Wed, 31 Jul 2002 08:10:37 -0400 (EDT) Received: from f-cpu.org (kdl16-9.n.club-internet.fr [213.44.18.9]) by relay-1v.club-internet.fr (Postfix) with ESMTP id EBEA0169A for ; Wed, 31 Jul 2002 14:10:34 +0200 (CEST) Message-ID: <3D47D5ED.3CDF7A00@f-cpu.org> Date: Wed, 31 Jul 2002 14:19:57 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <3D479CC9.1000107@yahoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Just an Illusion wrote: > Hello, > Michael Riepe wrote: > >On Tue, Jul 30, 2002 at 08:54:46PM +0200, Etienne LABARRE wrote: > >[...] > >A `standard' is something people have agreed on. Not everything that > >is found in library std or library ieee is a standard (especially if > >you use Synopsys). > > > But which people ? When you can found this package in standard version > of Synopsis, Mentor Graphics and Cadence tools, you can say than this a > 'standard' package de facto. > If you reply than you have some other tools which doesn't support this, > I can only say than this 3 societies cover between 80% and 90% of the > EDA market tools (this is a fact), and the 'standard' (and indirectly > the norme) are decided by them. ok then let's think like that, and apply this reasoning to the F-CPU project : "because x86 is 95% of the market, let's make a clone." it is not my habbit to follow the rest of the flock, unless there is a very good reason. I guess that Michael thinks the same :-P > Just an Illusion WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jul 31 14:47:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17Zt03-0007I6-01 for ; Wed, 31 Jul 2002 14:54:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 14:54:47 +0200 (CEST) Received: (qmail 5084 invoked by uid 0); 31 Jul 2002 12:47:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 31 Jul 2002 12:47:40 -0000 Received: by moria.seul.org (Postfix) id EE14A14692F; Wed, 31 Jul 2002 08:47:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD96E146935; Wed, 31 Jul 2002 08:47:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3065A14692F for ; Wed, 31 Jul 2002 08:47:39 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200207311247.1bdf; Wed, 31 Jul 2002 12:47:27 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] New snapshot for EU_INC and EU_CMP From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jul 2002 12:47:27 GMT Message-id: <200207311247.1bdf@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Most of the time typical cell are NAND and NOR, to use AND g= ate synthetiser could have to use NAND+NOT gate. It's very techn= ologicaly dependent (FPGA use lut of something as 8 inputs and 2 outpu= ts, it's a kind memory : 8 adress bit and 2 data bit, so every function= of 8 inputs have the same timing). Then came the fan out problem. If the fan out is too high, t= he synthetiser use bigger gate to drive higher current or use t= ree of amplificater (inverter or not). This could be done also afte= r place&route if the wire is too long. nicO =20 -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 31/07/02 Objet: Re: [f-cpu] New snapshot for EU_INC and EU_CMP On Tue, Jul 30, 2002 at 05:44:33PM -0600, Ben Franchuk wrote= : > Michael Riepe wrote: >=20 >=20 > > Therefore we only use elements that are supposed to be a= vailable > > everywhere: and/or gates with 2...4 inputs, 2-input xor = gates, inverters > > and muxes. With the famous `6 Gate Rule', any of them co= unt as 1 gate. > > Bigger elements (like an 8-input and gate) count as 2 or= more gates. > >=20 > > After the first synthesis experiences, I later added ano= ther rule: > > 2-input xors count as 2 gates, and the sum of gate delay= s must not > > exceed 10. I call this the `6G/10T' rule. >=20 > What about inverted inputs? Do they count as a gate and wh= at about > flip/flop set up and delay times and what memory elements = can > one count on. I count inverters as gates. Since it's a `rule of thumb' that applies only to the combin= atorial parts of the F-CPU, flipflops are not covered. Memory elements haven't been interesting for me because I cu= rrently deal only with the execution units, not with caches or the r= egister set. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Wed Jul 31 18:31:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZyhP-0002aU-01 for ; Wed, 31 Jul 2002 20:59:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 20:59:55 +0200 (CEST) Received: (qmail 27342 invoked by uid 0); 31 Jul 2002 17:11:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 31 Jul 2002 17:11:29 -0000 Received: by moria.seul.org (Postfix) id EBB451467FE; Wed, 31 Jul 2002 13:11:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCCCC146802; Wed, 31 Jul 2002 13:11:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 803111467FE for ; Wed, 31 Jul 2002 13:11:27 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-6-62-147-150-113.dial.proxad.net [62.147.150.113]) by postfix3-2.free.fr (Postfix) with SMTP id 1B51817FE1 for ; Wed, 31 Jul 2002 19:11:26 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Wed, 31 Jul 2002 18:31:04 +0200 Date: Wed, 31 Jul 2002 18:31:04 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP Message-ID: <20020731163104.GB179@free.fr> References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020731013318.26538@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 01:33:18AM +0200, Michael Riepe wrote: > > CMP is supposed to be either 0 or -1: cmp(a, b) = a < b ? -1 : 0. > > MSB1 is supposed to return the *number* of the most significant `1' > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some > strange bit mask. Likewise for MSB0. Idon't agree with you. The criteria for CMP unit for me is : If A = B, then result is null, else result not null. I think that is more simple, and permit to win one or more level latency. But, my unit is not compliant to the manual. What must we correct : manual or code ? Etienne. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From etienne.labarre@gadz.org Wed Jul 31 18:30:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZyhQ-0002aU-01 for ; Wed, 31 Jul 2002 20:59:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 20:59:56 +0200 (CEST) Received: (qmail 8881 invoked by uid 0); 31 Jul 2002 17:12:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 31 Jul 2002 17:12:01 -0000 Received: by moria.seul.org (Postfix) id B2E95146802; Wed, 31 Jul 2002 13:12:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B898146924; Wed, 31 Jul 2002 13:12:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 09ABF146802 for ; Wed, 31 Jul 2002 13:12:00 -0400 (EDT) Received: from ikad54cl193 (nas-cbv-6-62-147-150-113.dial.proxad.net [62.147.150.113]) by postfix2-2.free.fr (Postfix) with SMTP id 2B7405FCF1 for ; Wed, 31 Jul 2002 19:11:21 +0200 (CEST) Received: by ikad54cl193 (sSMTP sendmail emulation); Wed, 31 Jul 2002 18:30:59 +0200 Date: Wed, 31 Jul 2002 18:30:59 +0200 From: Etienne LABARRE To: f-cpu@seul.org Subject: Re: [f-cpu] What's wrong here? Message-ID: <20020731163059.GA179@free.fr> References: <20020730021508.07502@thrai.stud.uni-hannover.de> <3D46C656.2030207@yahoo.fr> <20020730185508.GC250@free.fr> <20020731011358.22755@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020731011358.22755@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.3.25i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 01:13:58AM +0200, Michael Riepe wrote: > On Tue, Jul 30, 2002 at 08:55:08PM +0200, Etienne LABARRE wrote: > [...] > > And i don't see what's wrong, it's works fine with simili. Is it luke ? > > It works fine as long as the argument is declared with a descending > (high downto low) array index range. When the index range is ascending > (low to high), the function will not reverse the bits but copy them. > > BTW: you can use work.Bit_Manipulation.bit_reverse instead. OK, good idea. Etienne. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Jul 31 19:17:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ZyhR-0002aU-00 for ; Wed, 31 Jul 2002 20:59:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 31 Jul 2002 20:59:57 +0200 (CEST) Received: (qmail 11233 invoked by uid 0); 31 Jul 2002 17:21:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 31 Jul 2002 17:21:16 -0000 Received: by moria.seul.org (Postfix) id C7228146923; Wed, 31 Jul 2002 13:21:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8F3FB146925; Wed, 31 Jul 2002 13:21:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 21DBA146923 for ; Wed, 31 Jul 2002 13:21:15 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-194.jetnet.ab.ca [207.34.60.194]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g6VHLJh1081854 for ; Wed, 31 Jul 2002 11:21:20 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D481BC5.4050006@jetnet.ab.ca> Date: Wed, 31 Jul 2002 11:17:57 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <20020731163104.GB179@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Etienne LABARRE wrote: > > Idon't agree with you. The criteria for CMP unit for me is : > If A = B, then result is null, else result not null. > > I think that is more simple, and permit to win one or more level > latency. The problem is -1,1 and the sign bit all can be used for a logic true. You almost need a two bit opcode field for the result returned. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jul 31 17:51:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIV-0000Fr-01 for ; Thu, 01 Aug 2002 11:31:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:07 +0200 (CEST) Received: (qmail 32000 invoked by uid 0); 31 Jul 2002 22:27:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 31 Jul 2002 22:27:12 -0000 Received: by moria.seul.org (Postfix) id 179A1146806; Wed, 31 Jul 2002 18:27:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE8E6146929; Wed, 31 Jul 2002 18:27:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 78ED8146806 for ; Wed, 31 Jul 2002 18:27:10 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-152-11.dial.proxad.net [62.147.152.11]) by postfix1-2.free.fr (Postfix) with ESMTP id 78CE1AB2E0 for ; Thu, 1 Aug 2002 00:27:08 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 Date: Wed, 31 Jul 2002 17:51:10 +0200 X-Mailer: KMail [version 1.4] References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> In-Reply-To: <3D45B6EF.455A037F@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207311751.10396.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > * Show me the proposed instruction form. I have something different to propose. We currently didn't have any instruction to load chunk after the 64 bits. Currently we use the shifter to do this and in fact it's not a good idea, if we want to write evolutive code. An idea is to propose a loadchunk that work like loadcons, but with every chunk size. With this we are scalable as much as we want and we can do what we want with any registers size. And if we add this instruction, the loadconsp will be seen like a immediate form of loadchunk. So what about this idea ? > The "shifting loadcons" does the reverse and the shifting cost > is put in the critical datapath of the Xbar. And shifting has > a cost (don't tell me "it's only a mux"). ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jul 31 18:27:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIW-0000Fr-00 for ; Thu, 01 Aug 2002 11:31:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:08 +0200 (CEST) Received: (qmail 15973 invoked by uid 0); 31 Jul 2002 22:27:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 31 Jul 2002 22:27:14 -0000 Received: by moria.seul.org (Postfix) id A3D2D146929; Wed, 31 Jul 2002 18:27:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7690C146935; Wed, 31 Jul 2002 18:27:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 0A6EA146929 for ; Wed, 31 Jul 2002 18:27:13 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-152-11.dial.proxad.net [62.147.152.11]) by postfix1-2.free.fr (Postfix) with ESMTP id 1BA80AB304 for ; Thu, 1 Aug 2002 00:27:11 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] condition flag location Date: Wed, 31 Jul 2002 18:27:18 +0200 X-Mailer: KMail [version 1.4] References: <20020728135740.35974.qmail@web14207.mail.yahoo.com> In-Reply-To: <20020728135740.35974.qmail@web14207.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207311827.18860.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > as sayd last nignt, i would look it up: > > > > JMP: > > condition = bits 19-21 > > JMP: --> correction: MOVE Ok, I don't know why, but I forgot to update move, sorry I will fix that as soon as possible. > > condition = bits 10-12 > > > > i think i found why, the bit numbering is > > different. > > what's the story on bit numbering? > > the Revision history in the manual: > 07/20/2002 : Reverse all the bits. > is JMP the old or new numbering? new numbering. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jul 31 18:23:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIW-0000Fr-01 for ; Thu, 01 Aug 2002 11:31:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:08 +0200 (CEST) Received: (qmail 10189 invoked by uid 0); 31 Jul 2002 22:27:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 31 Jul 2002 22:27:17 -0000 Received: by moria.seul.org (Postfix) id DC841146811; Wed, 31 Jul 2002 18:27:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF77D14693B; Wed, 31 Jul 2002 18:27:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 741C1146811 for ; Wed, 31 Jul 2002 18:27:16 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-152-11.dial.proxad.net [62.147.152.11]) by postfix1-2.free.fr (Postfix) with ESMTP id CDA4BAB307 for ; Thu, 1 Aug 2002 00:27:13 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Web and webmaster Date: Wed, 31 Jul 2002 18:23:26 +0200 X-Mailer: KMail [version 1.4] References: <3D44F7FD.6040607@yahoo.fr> <1027959965.3d456c9dcb72f@imp.free.fr> <3D45A940.10037112@f-cpu.org> In-Reply-To: <3D45A940.10037112@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207311823.26500.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > would it be possible to move the DNS of f-cpu.org/net/com to seul.org ? > and change of registrar (Gandi would be ok, but i don't know them much). > IF THE FRENCH GUYZ DID WHAT THEY SAID THEY WOULD DO, THE FRENCH F-CPU > ASSOCIATION WOULD HAVE ALREADY SOLVED THE DNS TROUBLES, AS WELL AS Association can't solved the DNS problem, because she didn't pay it. In fact you only need to ask your registar to solve this. If you want to change your registar, prefer gandy (because some of this guy come at the first jeudi, and they didn't cost a lot) and ask the too registar to solve this problem. It's all and it's not a job for association. > OTHERS (TRADE MARK PROTECTED IN EUROPE). BUT NO : CEDRIC AND NICO (TO Protect trade mark in europe cost a lot, and creating an association will not help to have money. In fact it's a French F-CPU association that you want to create, so it can't be a possibility for this association to proctect trade mark in europe. > NAME A FEW) LOST 6 MONTHS AND I STILL HAVE TO SOLVE THE PROBLEMS. THANKS And what did you want to do during this 6 months with the association ? The only interrest I currently see to the association is for sponsoring for licence and hardware, it's all. > GUYS. DO I HAVE TO MAKE THE ASSOCIATION MYSELF NOW ? I think it's not as clear as you expected, so first clear the problem before starting something. First a good idea will be to say, what the association can do for the project. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 14:41:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCId-0000Fr-00 for ; Thu, 01 Aug 2002 11:31:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:15 +0200 (CEST) Received: (qmail 29650 invoked by uid 0); 1 Aug 2002 00:08:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 1 Aug 2002 00:08:42 -0000 Received: by moria.seul.org (Postfix) id C7F4114692F; Wed, 31 Jul 2002 20:08:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9F54A14693C; Wed, 31 Jul 2002 20:08:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a121.home.uni-hannover.de [130.75.232.121]) by moria.seul.org (Postfix) with ESMTP id EE44014692F for ; Wed, 31 Jul 2002 20:08:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00575; Wed, 31 Jul 2002 14:41:54 +0200 Message-ID: <20020731144153.65151@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 14:41:53 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <3D479CC9.1000107@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D479CC9.1000107@yahoo.fr>; from Just an Illusion on Wed, Jul 31, 2002 at 10:16:09AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 10:16:09AM +0200, Just an Illusion wrote: [...] > >A `standard' is something people have agreed on. Not everything that > >is found in library std or library ieee is a standard (especially if > >you use Synopsys). > > > But which people ? When you can found this package in standard version > of Synopsis, Mentor Graphics and Cadence tools, you can say than this a > 'standard' package de facto. > If you reply than you have some other tools which doesn't support this, > I can only say than this 3 societies cover between 80% and 90% of the > EDA market tools (this is a fact), and the 'standard' (and indirectly > the norme) are decided by them. >From that point of view, Intel CPUs and Microsoft operating systems are standards, too. Why do we deal with F-CPU and Unix/Linux, then? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jul 31 14:06:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIe-0000Fr-00 for ; Thu, 01 Aug 2002 11:31:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:16 +0200 (CEST) Received: (qmail 6546 invoked by uid 0); 1 Aug 2002 00:08:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 1 Aug 2002 00:08:59 -0000 Received: by moria.seul.org (Postfix) id 775D214693E; Wed, 31 Jul 2002 20:08:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66056146940; Wed, 31 Jul 2002 20:08:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a121.home.uni-hannover.de [130.75.232.121]) by moria.seul.org (Postfix) with ESMTP id C323A14693E for ; Wed, 31 Jul 2002 20:08:56 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00488; Wed, 31 Jul 2002 14:06:58 +0200 Message-ID: <20020731140658.64323@thrai.stud.uni-hannover.de> Date: Wed, 31 Jul 2002 14:06:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <3D4748DA.513D0F89@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D4748DA.513D0F89@f-cpu.org>; from Yann Guidon on Wed, Jul 31, 2002 at 04:18:02AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 04:18:02AM +0200, Yann Guidon wrote: [...] > > After the first synthesis experiences, I later added another rule: > > 2-input xors count as 2 gates, and the sum of gate delays must not > > exceed 10. I call this the `6G/10T' rule. > what is 'T' ? Transistors, more or less. > > [...] > > > MSB1 is supposed to return the *number* of the most significant `1' > > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some > > strange bit mask. Likewise for MSB0. > > This feature has been dropped, particularly if popc is implemented : > you can feed the bit mast to POPC which will return the number of bits. Oh, really? Then you forgot to tell us (and update the manual). > Of course there are faster ways to implement that, but there is no > reason of adding one cycle of latency to the units. Particularly > if it's not used often. Latency is not an argument in this case. In fact, CMP/SORT have higher latency than the original MSB[01]. Please restore the old behaviour. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 1 02:33:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIe-0000Fr-01 for ; Thu, 01 Aug 2002 11:31:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:16 +0200 (CEST) Received: (qmail 16479 invoked by uid 0); 1 Aug 2002 00:33:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 1 Aug 2002 00:33:08 -0000 Received: by moria.seul.org (Postfix) id 3D7A114693B; Wed, 31 Jul 2002 20:33:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF2C4146940; Wed, 31 Jul 2002 20:33:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a121.home.uni-hannover.de [130.75.232.121]) by moria.seul.org (Postfix) with ESMTP id 9170A14693B for ; Wed, 31 Jul 2002 20:33:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00640; Thu, 1 Aug 2002 02:33:04 +0200 Message-ID: <20020801023303.14773@thrai.stud.uni-hannover.de> Date: Thu, 1 Aug 2002 02:33:03 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <20020731163104.GB179@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020731163104.GB179@free.fr>; from Etienne LABARRE on Wed, Jul 31, 2002 at 06:31:04PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 06:31:04PM +0200, Etienne LABARRE wrote: > On Wed, Jul 31, 2002 at 01:33:18AM +0200, Michael Riepe wrote: > > > > CMP is supposed to be either 0 or -1: cmp(a, b) = a < b ? -1 : 0. > > > > MSB1 is supposed to return the *number* of the most significant `1' > > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some > > strange bit mask. Likewise for MSB0. > > Idon't agree with you. The criteria for CMP unit for me is : > If A = B, then result is null, else result not null. We have XOR for that, don't we? The instruction we need is `cmpl', aka `CoMPare Less' (A < B). > I think that is more simple, and permit to win one or more level > latency. > > But, my unit is not compliant to the manual. What must we correct : > manual or code ? Since the semantics of scan/lsb/msb seem to have changed behind my back, we will have to discuss that here. CMP/MIN/MAX/SORT is wrong, however. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 1 02:36:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIf-0000Fr-00 for ; Thu, 01 Aug 2002 11:31:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:17 +0200 (CEST) Received: (qmail 12467 invoked by uid 0); 1 Aug 2002 00:36:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 1 Aug 2002 00:36:56 -0000 Received: by moria.seul.org (Postfix) id 5BDFE14693C; Wed, 31 Jul 2002 20:36:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24624146941; Wed, 31 Jul 2002 20:36:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a121.home.uni-hannover.de [130.75.232.121]) by moria.seul.org (Postfix) with ESMTP id 8F4D214693C for ; Wed, 31 Jul 2002 20:36:53 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA00654; Thu, 1 Aug 2002 02:36:52 +0200 Message-ID: <20020801023651.10519@thrai.stud.uni-hannover.de> Date: Thu, 1 Aug 2002 02:36:51 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200207311751.10396.cedric.bail@free.fr>; from cedric on Wed, Jul 31, 2002 at 05:51:10PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Jul 31, 2002 at 05:51:10PM +0200, cedric wrote: [...] > An idea is to propose a loadchunk that work like loadcons, but with every > chunk size. With this we are scalable as much as we want and we can do > what we want with any registers size. And if we add this instruction, the > loadconsp will be seen like a immediate form of loadchunk. > > So what about this idea ? There is no room in the instruction word. Where should a 64-bit constant come from - a register? How does it get there? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 1 03:36:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aCIh-0000Fr-00 for ; Thu, 01 Aug 2002 11:31:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 11:31:19 +0200 (CEST) Received: (qmail 11205 invoked by uid 0); 1 Aug 2002 01:27:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 1 Aug 2002 01:27:05 -0000 Received: by moria.seul.org (Postfix) id F245C146940; Wed, 31 Jul 2002 21:27:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DD784146944; Wed, 31 Jul 2002 21:27:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 98B20146940 for ; Wed, 31 Jul 2002 21:27:04 -0400 (EDT) Received: from f-cpu.org (kdl16-14.n.club-internet.fr [213.44.18.14]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 1162716F2 for ; Thu, 1 Aug 2002 03:27:02 +0200 (CEST) Message-ID: <3D48909A.7C423EB7@f-cpu.org> Date: Thu, 01 Aug 2002 03:36:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <20020731163104.GB179@free.fr> <20020801023303.14773@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Wed, Jul 31, 2002 at 06:31:04PM +0200, Etienne LABARRE wrote: > > On Wed, Jul 31, 2002 at 01:33:18AM +0200, Michael Riepe wrote: > > > > > > CMP is supposed to be either 0 or -1: cmp(a, b) = a < b ? -1 : 0. > > > > > > MSB1 is supposed to return the *number* of the most significant `1' > > > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some > > > strange bit mask. Likewise for MSB0. > > > > Idon't agree with you. The criteria for CMP unit for me is : > > If A = B, then result is null, else result not null. > > We have XOR for that, don't we? exact. If the combine mode is able to stand the width, a SIMD mask is even possible (just do a MUX to select your data). > The instruction we need is `cmpl', aka `CoMPare Less' (A < B). > > > I think that is more simple, and permit to win one or more level > > latency. > > > > But, my unit is not compliant to the manual. What must we correct : > > manual or code ? > > Since the semantics of scan/lsb/msb seem to have changed behind my > back, we will have to discuss that here. CMP/MIN/MAX/SORT is wrong, > however. LSB and MSB are needed in some cases but these algorithm do not justify an additional pipeline cycle on CMP. When POPC is implemented, it is "cheaper" to run the result from LSB into POPC. Giving an "integer" number of 1 bits was just pure convenience, but the structure of the reduce-tree (and the tight pipeline) force us to use another simpler approach. I even agree that some parts of the manual are science fiction. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 1 11:38:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZi-0005zq-01 for ; Thu, 01 Aug 2002 20:21:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:26 +0200 (CEST) Received: (qmail 12859 invoked by uid 0); 1 Aug 2002 09:39:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 Aug 2002 09:39:14 -0000 Received: by moria.seul.org (Postfix) id 444C814692C; Thu, 1 Aug 2002 05:39:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B23E14694A; Thu, 1 Aug 2002 05:39:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 9EBA414692C for ; Thu, 1 Aug 2002 05:39:11 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208010938.39e7; Thu, 1 Aug 2002 09:38:57 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Manual 0.2.6 From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Aug 2002 09:38:57 GMT Message-id: <200208010938.39e7@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N And what about an inter-chunk shift ? It will come will all = the missing inter chunk operation. nicO -----Message d'origine----- De: cedric A: f-cpu@seul.org Date: 01/08/02 Objet: Re: [f-cpu] Manual 0.2.6 > * Show me the proposed instruction form. I have something different to propose. We currently didn't h= ave any=20 instruction to load chunk after the 64 bits. Currently we us= e the shifter to=20 do this and in fact it's not a good idea, if we want to writ= e evolutive code. An idea is to propose a loadchunk that work like loadcons, b= ut with every chunk size. With this we are scalable as much as we want and= we can do=20 what we want with any registers size. And if we add this ins= truction, the loadconsp will be seen like a immediate form of loadchunk. So what about this idea ? > The "shifting loadcons" does the reverse and the shifting = cost > is put in the critical datapath of the Xbar. And shifting = has > a cost (don't tell me "it's only a mux"). ;-) Cedric ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 1 11:42:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZj-0005zq-00 for ; Thu, 01 Aug 2002 20:21:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:27 +0200 (CEST) Received: (qmail 11495 invoked by uid 0); 1 Aug 2002 09:42:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 1 Aug 2002 09:42:49 -0000 Received: by moria.seul.org (Postfix) id C3E2114694C; Thu, 1 Aug 2002 05:42:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9DDB114694A; Thu, 1 Aug 2002 05:42:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 91BFD14694C for ; Thu, 1 Aug 2002 05:42:46 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208010942.1d4a; Thu, 1 Aug 2002 09:42:29 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] New snapshot for EU_INC and EU_CMP From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Aug 2002 09:42:29 GMT Message-id: <200208010942.1d4a@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 01/08/02 Objet: Re: [f-cpu] New snapshot for EU_INC and EU_CMP On Wed, Jul 31, 2002 at 10:16:09AM +0200, Just an Illusion w= rote: [...] > >A `standard' is something people have agreed on. Not ever= ything that > >is found in library std or library ieee is a standard (es= pecially if > >you use Synopsys). > > > But which people ? When you can found this package in stan= dard version > of Synopsis, Mentor Graphics and Cadence tools, you can sa= y than this a=20 > 'standard' package de facto. > If you reply than you have some other tools which doesn't = support this,=20 > I can only say than this 3 societies cover between 80% and= 90% of the=20 > EDA market tools (this is a fact), and the 'standard' (and= indirectly=20 > the norme) are decided by them. >From that point of view, Intel CPUs and Microsoft operating = systems are standards, too. Why do we deal with F-CPU and Unix/Linux, th= en? >>> For me the argument aren't so stupid ;p In fact, we didn= 't want to recreate a complete free design flow. So at a certain point,= we *must* use closed software. If we could use not so standard code bu= t without losing our liberty, why not ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Thu Aug 1 14:32:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZn-0005zq-00 for ; Thu, 01 Aug 2002 20:21:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:31 +0200 (CEST) Received: (qmail 27161 invoked by uid 0); 1 Aug 2002 12:32:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 1 Aug 2002 12:32:49 -0000 Received: by moria.seul.org (Postfix) id 818391467F2; Thu, 1 Aug 2002 08:32:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52C401467F7; Thu, 1 Aug 2002 08:32:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by moria.seul.org (Postfix) with SMTP id 930221467F2 for ; Thu, 1 Aug 2002 08:32:46 -0400 (EDT) Message-ID: <20020801123245.8940.qmail@web14203.mail.yahoo.com> Received: from [130.89.243.164] by web14203.mail.yahoo.com via HTTP; Thu, 01 Aug 2002 05:32:45 PDT Date: Thu, 1 Aug 2002 05:32:45 -0700 (PDT) From: jaap stolk Subject: [f-cpu] condition checking and register atribote cache To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, im trying to add conditional instructions to fcpusim, and have some ideas: according to the manual there will be "cache" copy of the flags, because reading a register is rather "slow". what i would like to do is use the x-bar read-bus instead. this is possible, because the condition register is read onto the x-bar (but not passed on to any EU) if the condition is false, we can simply disable the clock signal that clocks the data and control signals from the x-bar onto the EU's (just like if there is a stall) and disable the clock signal that clocks the port numbers into the x-bar write queue. (just like if there is a stall) this will automatically fix the bypassing problem in situations like these: move r2,r3 nop move r3,r4,r5 ( if (r3) r5-r4; ) it seems to be ok for normal instructions and register move instructions, i'm not sure how it will go with conditional moves, loadcons. etc. dous this sounds reasonable, or are there any major problems i overlooked ? i also made a drawing of the write queue / scheduler. i'll upload it if anyone is interested. jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 1 16:22:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZo-0005zq-00 for ; Thu, 01 Aug 2002 20:21:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:32 +0200 (CEST) Received: (qmail 11935 invoked by uid 0); 1 Aug 2002 14:22:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 1 Aug 2002 14:22:34 -0000 Received: by moria.seul.org (Postfix) id 32E331467EF; Thu, 1 Aug 2002 10:22:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D812F1467F4; Thu, 1 Aug 2002 10:22:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 679051467EF for ; Thu, 1 Aug 2002 10:22:31 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id A68FE5F8C3 for ; Thu, 1 Aug 2002 16:22:30 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 8C5F8873CF; Thu, 1 Aug 2002 16:22:30 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 Message-ID: <1028211750.3d4944267b7e0@imp.free.fr> Date: Thu, 01 Aug 2002 16:22:30 +0200 (MEST) From: Cedric BAIL References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> <20020801023651.10519@thrai.stud.uni-hannover.de> In-Reply-To: <20020801023651.10519@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.58.21 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > An idea is to propose a loadchunk that work like loadcons, but with every > > chunk size. With this we are scalable as much as we want and we can do > > what we want with any registers size. And if we add this instruction, the > > loadconsp will be seen like a immediate form of loadchunk. > > So what about this idea ? > > There is no room in the instruction word. Where should a 64-bit > constant come from - a register? How does it get there? Hum, in fact it wasn't clear enough. I mean something like : loadchunk.b r2, r1 in c that's somtehing like : r1 = r1 << 8 | r2.b The idea is to have this capability for every register size (8, 16, 32, 64). We need this instructions to load register that are bigger than 64 bits (the shifter only work on 64 bits, and it isn't its job to work in a inter chunk capability). In fact we need the opposite operation : unloadchunk.b r2, r1 (equal to : r2 = r1 & 8 r1 = r1 >> 8) Personnaly I didn't like the name because we are thinking it's something like a memory operation, but I have no better idea. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 1 17:11:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZp-0005zq-00 for ; Thu, 01 Aug 2002 20:21:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:33 +0200 (CEST) Received: (qmail 18868 invoked by uid 0); 1 Aug 2002 15:02:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 1 Aug 2002 15:02:18 -0000 Received: by moria.seul.org (Postfix) id A9D2E14640E; Thu, 1 Aug 2002 11:02:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7C21A1467F1; Thu, 1 Aug 2002 11:02:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id ABBA214640E for ; Thu, 1 Aug 2002 11:02:16 -0400 (EDT) Received: from f-cpu.org (kdl16-13.n.club-internet.fr [213.44.18.13]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 383F81697 for ; Thu, 1 Aug 2002 17:02:06 +0200 (CEST) Message-ID: <3D494F9D.B4A7F601@f-cpu.org> Date: Thu, 01 Aug 2002 17:11:25 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> <20020801023651.10519@thrai.stud.uni-hannover.de> <1028211750.3d4944267b7e0@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, just a little detail : Cedric BAIL wrote: > The idea is to have this capability for every register size (8, 16, 32, 64). > We need this instructions to load register that are bigger than 64 bits (the > shifter only work on 64 bits, and it isn't its job to work in a inter chunk > capability). beware : Michael did not implement inter-chunk shifts, but it is not a norm. i would like to implement a different shifter structure which could shift 64 bits, even between two neighbouring chunks. > Cedric WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 1 14:57:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZq-0005zq-01 for ; Thu, 01 Aug 2002 20:21:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:34 +0200 (CEST) Received: (qmail 20260 invoked by uid 0); 1 Aug 2002 16:07:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 1 Aug 2002 16:07:30 -0000 Received: by moria.seul.org (Postfix) id 85DA11467E8; Thu, 1 Aug 2002 12:07:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4D46A1467F4; Thu, 1 Aug 2002 12:07:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 8A9011467E8 for ; Thu, 1 Aug 2002 12:07:26 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00546; Thu, 1 Aug 2002 14:57:24 +0200 Message-ID: <20020801145724.29949@thrai.stud.uni-hannover.de> Date: Thu, 1 Aug 2002 14:57:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <20020731163104.GB179@free.fr> <20020801023303.14773@thrai.stud.uni-hannover.de> <3D48909A.7C423EB7@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D48909A.7C423EB7@f-cpu.org>; from Yann Guidon on Thu, Aug 01, 2002 at 03:36:26AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 01, 2002 at 03:36:26AM +0200, Yann Guidon wrote: [...] > > The instruction we need is `cmpl', aka `CoMPare Less' (A < B). > > > > > I think that is more simple, and permit to win one or more level > > > latency. > > > > > > But, my unit is not compliant to the manual. What must we correct : > > > manual or code ? > > > > Since the semantics of scan/lsb/msb seem to have changed behind my > > back, we will have to discuss that here. CMP/MIN/MAX/SORT is wrong, > > however. > > LSB and MSB are needed in some cases but these algorithm do not > justify an additional pipeline cycle on CMP. When POPC is implemented, > it is "cheaper" to run the result from LSB into POPC. MSBx is the *fastest* instruction the EU_CMP can compute. The second stage (in my version) looks like this: - MSBx: a row of 32-input OR gates (d=3) - CMP: A row of AND2 gates, followed by a 64-input OR gate (d=4) - SORT: same as CMP, followed by a row of 2:1 MUXes (d=5) Dropping or re-defining MSBx doesn't change the timing of the unit. > Giving an "integer" number of 1 bits was just pure convenience, > but the structure of the reduce-tree (and the tight pipeline) > force us to use another simpler approach. No they don't. We just won't be able to do it in 1 cycle. NONE of the instructions. > I even agree that some parts of the manual are science fiction. Yep. Some are pretty real, though. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Aug 1 18:17:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aKZr-0005zq-00 for ; Thu, 01 Aug 2002 20:21:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 01 Aug 2002 20:21:35 +0200 (CEST) Received: (qmail 12934 invoked by uid 0); 1 Aug 2002 16:20:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 1 Aug 2002 16:20:22 -0000 Received: by moria.seul.org (Postfix) id 5C4D71467F1; Thu, 1 Aug 2002 12:20:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 11E871467F7; Thu, 1 Aug 2002 12:20:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 708D11467F1 for ; Thu, 1 Aug 2002 12:20:20 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-207.jetnet.ab.ca [207.34.60.207]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g71GKRh1039201 for ; Thu, 1 Aug 2002 10:20:28 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D495EFE.5090000@jetnet.ab.ca> Date: Thu, 01 Aug 2002 10:17:02 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New snapshot for EU_INC and EU_CMP References: <20020729184813.GB948@free.fr> <20020730010430.29967@thrai.stud.uni-hannover.de> <20020730185446.GB250@free.fr> <20020731013318.26538@thrai.stud.uni-hannover.de> <20020731163104.GB179@free.fr> <20020801023303.14773@thrai.stud.uni-hannover.de> <3D48909A.7C423EB7@f-cpu.org> <20020801145724.29949@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > No they don't. We just won't be able to do it in 1 cycle. > NONE of the instructions. Just what are the cycle times of the units so far? >>I even agree that some parts of the manual are science fiction. Until it is built, it all fiction.:) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 1 20:28:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aPz6-0001SH-00 for ; Fri, 02 Aug 2002 02:08:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 02:08:00 +0200 (CEST) Received: (qmail 1477 invoked by uid 0); 1 Aug 2002 21:53:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 1 Aug 2002 21:53:19 -0000 Received: by moria.seul.org (Postfix) id 94CEC1467E8; Thu, 1 Aug 2002 17:53:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 81DB91467F4; Thu, 1 Aug 2002 17:53:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a203.home.uni-hannover.de [130.75.232.203]) by moria.seul.org (Postfix) with ESMTP id BDEAB1467E8 for ; Thu, 1 Aug 2002 17:53:16 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01393; Thu, 1 Aug 2002 20:28:47 +0200 Message-ID: <20020801202847.21164@thrai.stud.uni-hannover.de> Date: Thu, 1 Aug 2002 20:28:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> <20020801023651.10519@thrai.stud.uni-hannover.de> <1028211750.3d4944267b7e0@imp.free.fr> <3D494F9D.B4A7F601@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D494F9D.B4A7F601@f-cpu.org>; from Yann Guidon on Thu, Aug 01, 2002 at 05:11:25PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 01, 2002 at 05:11:25PM +0200, Yann Guidon wrote: > hi, > > just a little detail : > > Cedric BAIL wrote: > > The idea is to have this capability for every register size (8, 16, 32, 64). > > We need this instructions to load register that are bigger than 64 bits (the > > shifter only work on 64 bits, and it isn't its job to work in a inter chunk > > capability). > > beware : Michael did not implement inter-chunk shifts, but it is not a norm. > i would like to implement a different shifter structure which could shift > 64 bits, even between two neighbouring chunks. It's not a problem to extend the shifter to 128, 256 or even more bits. But it will affect the latency, of course. The same is true for the ASU and IMU units; the only EU that is mostly immune to word size changes is ROP2. A 256-bit F-CPU core that supports full-word operations will have longer pipelines or more delay per pipeline stage (or both). Unless we use variable latency EUs, almost all operations will be slower than in a 64-bit version. The question is whether e.g. a 256-bit add, multiply or shift instruction is really useful. Most of the time, applications use small integers that fit into 32 (or less) bits, and IEEE single or double floats. That is, wider registers will be used for SIMD operations a lot, but rarely for `wide' operations. How to move data to/from wide registers? Data that is stored in memory can be handled with load/store, immediate data will be handled by the loadcons* instructions, and the mix, expand, byterev and sdup instructions (which may handle wider chunks than 64-bit without significant performance loss) can be used to move data between different chunks. If we're going to implement a `monster shift' anyway, I suggest a `chunk shift' instruction that operates on full-size registers (that is, there will be no SIMD mode) and always shifts 64-bit quantities: cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) This can probably be integrated with the SHL execution unit. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 1 18:50:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aPz7-0001SH-00 for ; Fri, 02 Aug 2002 02:08:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 02:08:01 +0200 (CEST) Received: (qmail 15576 invoked by uid 0); 1 Aug 2002 21:53:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 Aug 2002 21:53:22 -0000 Received: by moria.seul.org (Postfix) id A190C1467F4; Thu, 1 Aug 2002 17:53:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84F651467FE; Thu, 1 Aug 2002 17:53:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a203.home.uni-hannover.de [130.75.232.203]) by moria.seul.org (Postfix) with ESMTP id DB5F91467F4 for ; Thu, 1 Aug 2002 17:53:18 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01163; Thu, 1 Aug 2002 18:50:07 +0200 Message-ID: <20020801185007.63989@thrai.stud.uni-hannover.de> Date: Thu, 1 Aug 2002 18:50:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] condition checking and register atribote cache References: <20020801123245.8940.qmail@web14203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020801123245.8940.qmail@web14203.mail.yahoo.com>; from jaap stolk on Thu, Aug 01, 2002 at 05:32:45AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 01, 2002 at 05:32:45AM -0700, jaap stolk wrote: > hi, > > im trying to add conditional instructions to > fcpusim, and have some ideas: > > according to the manual there will be "cache" copy > of the flags, because reading a register is > rather "slow". The scoreboard, yes. > what i would like to do is use the x-bar read-bus > instead. this is possible, because the condition > register is read onto the x-bar (but not passed on to > any EU) That may be too slow. If you have a zero condition, you'll have to OR all bits of the condition register - which will take some time (approximately 0.5 cycles). > if the condition is false, we can simply disable the > clock signal that clocks the data and control > signals from the x-bar onto the EU's > (just like if there is a stall) If the condition signal becomes available during the Xbar cycle, you can use the `enable' input of the EU. If it comes later, you'll have to issue the instruction speculatively, and discard the result. > and disable the clock signal that clocks the port > numbers into the x-bar write queue. > (just like if there is a stall) That's not a problem because it happens several cycles later. > this will automatically fix the bypassing problem in > situations like these: > > move r2,r3 > nop > move r3,r4,r5 ( if (r3) r5-r4; ) A compiler that generates this kind of code should be taken out and shot. You can use r2 as the condition register! -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Aug 2 00:54:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aPz9-0001SH-01 for ; Fri, 02 Aug 2002 02:08:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 02:08:03 +0200 (CEST) Received: (qmail 30147 invoked by uid 0); 1 Aug 2002 22:54:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 1 Aug 2002 22:54:12 -0000 Received: by moria.seul.org (Postfix) id 977201467EE; Thu, 1 Aug 2002 18:54:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6E7471467F7; Thu, 1 Aug 2002 18:54:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14201.mail.yahoo.com (web14201.mail.yahoo.com [216.136.172.143]) by moria.seul.org (Postfix) with SMTP id E84291467EE for ; Thu, 1 Aug 2002 18:54:10 -0400 (EDT) Message-ID: <20020801225410.47871.qmail@web14201.mail.yahoo.com> Received: from [130.89.243.164] by web14201.mail.yahoo.com via HTTP; Thu, 01 Aug 2002 15:54:10 PDT Date: Thu, 1 Aug 2002 15:54:10 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] condition checking and register atribote cache To: f-cpu@seul.org In-Reply-To: <20020801185007.63989@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Michael Riepe wrote: > On Thu, Aug 01, 2002 at 05:32:45AM -0700, jaap stolk > wrote: > > hi, > > > > im trying to add conditional instructions to > > fcpusim, and have some ideas: > > > > according to the manual there will be "cache" copy > > of the flags, because reading a register is > > rather "slow". > > The scoreboard, yes. > > > what i would like to do is use the x-bar read-bus > > instead. this is possible, because the condition > > register is read onto the x-bar (but not passed on > to > > any EU) > > That may be too slow. If you have a zero condition, > you'll have to OR all > bits of the condition register - which will take > some time (approximately > 0.5 cycles). > depends on the timing of the x-bar, i was thinking of puting this check for zero somwhere neer the direct bypass. from that poin we need about 0.5 cycle, to get the data to the EU anyway. > > if the condition is false, we can simply disable > the > > clock signal that clocks the data and control > > signals from the x-bar onto the EU's > > (just like if there is a stall) > > If the condition signal becomes available during the > Xbar cycle, you > can use the `enable' input of the EU. If it comes > later, you'll have > to issue the instruction speculatively, and discard > the result. at the moment i'm not using any enable signal. the read ports only get clocked when the x-bar writes to them, and the input is kept like that if the EU is not used. > > > and disable the clock signal that clocks the port > > numbers into the x-bar write queue. > > (just like if there is a stall) > > That's not a problem because it happens several > cycles later. true, but if we can avoid geting the instruction in the write queue, we can use the write "slot" for somthing else (like a register move). also if the register enters the write queue, it can couse as stall in one of the next instructions. so it would be nice to avoid is. as fat as i can see, we can disable writing to the queue just before the end of the x-bar. > > > this will automatically fix the bypassing problem > in > > situations like these: > > > > move r2,r3 > > nop > > move r3,r4,r5 ( if (r3) r5-r4; ) > > A compiler that generates this kind of code should > be taken out and > shot. You can use r2 as the condition register! agree, i used move just as an example of a 1 cycle instuction. (the nop shows that there would be one stall anyway) > > -- > Michael "Tired" Riepe > > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 2 01:28:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aPzA-0001SH-00 for ; Fri, 02 Aug 2002 02:08:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 02:08:04 +0200 (CEST) Received: (qmail 28308 invoked by uid 0); 1 Aug 2002 23:07:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 1 Aug 2002 23:07:20 -0000 Received: by moria.seul.org (Postfix) id 34EC61467EF; Thu, 1 Aug 2002 19:07:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 109A41467FF; Thu, 1 Aug 2002 19:07:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A734D1467EF for ; Thu, 1 Aug 2002 19:07:17 -0400 (EDT) Received: from ifrance.com (vlt4-208.n.club-internet.fr [194.158.109.208]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 95E6816CD for ; Fri, 2 Aug 2002 01:07:14 +0200 (CEST) Message-ID: <3D49C407.EDEEE68@ifrance.com> Date: Fri, 02 Aug 2002 01:28:07 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] condition checking and register atribote cache References: <20020801225410.47871.qmail@web14201.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N We must never play with the clock ! Always use enable signal, always. Then it could be used to stop the clock but for testing purpose it must not be obligatory to stop a clock for fonctionnal beavior. Few years ago, it was an heresy to ever think of puting a gate inside the clock tree. nicO jaap stolk a écrit : > > hi, > > --- Michael Riepe > wrote: > > > On Thu, Aug 01, 2002 at 05:32:45AM -0700, jaap stolk > > wrote: > > > hi, > > > > > > im trying to add conditional instructions to > > > fcpusim, and have some ideas: > > > > > > according to the manual there will be "cache" copy > > > of the flags, because reading a register is > > > rather "slow". > > > > The scoreboard, yes. > > > > > what i would like to do is use the x-bar read-bus > > > instead. this is possible, because the condition > > > register is read onto the x-bar (but not passed on > > to > > > any EU) > > > > That may be too slow. If you have a zero condition, > > you'll have to OR all > > bits of the condition register - which will take > > some time (approximately > > 0.5 cycles). > > > > depends on the timing of the x-bar, i was thinking of > puting this check for zero somwhere neer the direct > bypass. from that poin we need about 0.5 cycle, to get > the data to the EU anyway. > > > > if the condition is false, we can simply disable > > the > > > clock signal that clocks the data and control > > > signals from the x-bar onto the EU's > > > (just like if there is a stall) > > > > If the condition signal becomes available during the > > Xbar cycle, you > > can use the `enable' input of the EU. If it comes > > later, you'll have > > to issue the instruction speculatively, and discard > > the result. > > at the moment i'm not using any enable signal. > the read ports only get clocked when the x-bar > writes to them, and the input is kept like that if > the EU is not used. > > > > > > and disable the clock signal that clocks the port > > > numbers into the x-bar write queue. > > > (just like if there is a stall) > > > > That's not a problem because it happens several > > cycles later. > > true, but if we can avoid geting the instruction in > the write queue, we can use the write "slot" for > somthing else (like a register move). also > if the register enters the write queue, it can couse > as stall in one of the next instructions. > so it would be nice to avoid is. > as fat as i can see, we can disable writing > to the queue just before the end of the x-bar. > > > > > > this will automatically fix the bypassing problem > > in > > > situations like these: > > > > > > move r2,r3 > > > nop > > > move r3,r4,r5 ( if (r3) r5-r4; ) > > > > A compiler that generates this kind of code should > > be taken out and > > shot. You can use r2 as the condition register! > > agree, i used move just as an example of a 1 cycle > instuction. (the nop shows that there would be one > stall anyway) > > > > > -- > > Michael "Tired" Riepe > > > > "All I wanna do is have a little fun before I die" > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org > > with > > unsubscribe f-cpu in the body. > http://f-cpu.seul.org/ > > jaap. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 2 01:35:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aPzB-0001SH-00 for ; Fri, 02 Aug 2002 02:08:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 02:08:05 +0200 (CEST) Received: (qmail 16828 invoked by uid 0); 1 Aug 2002 23:14:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 Aug 2002 23:14:42 -0000 Received: by moria.seul.org (Postfix) id BB7041467F7; Thu, 1 Aug 2002 19:14:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9293F146800; Thu, 1 Aug 2002 19:14:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 3CD201467F7 for ; Thu, 1 Aug 2002 19:14:41 -0400 (EDT) Received: from ifrance.com (vlt4-208.n.club-internet.fr [194.158.109.208]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 828051691 for ; Fri, 2 Aug 2002 01:14:38 +0200 (CEST) Message-ID: <3D49C5C3.DC84A17D@ifrance.com> Date: Fri, 02 Aug 2002 01:35:31 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> <20020801023651.10519@thrai.stud.uni-hannover.de> <1028211750.3d4944267b7e0@imp.free.fr> <3D494F9D.B4A7F601@f-cpu.org> <20020801202847.21164@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Thu, Aug 01, 2002 at 05:11:25PM +0200, Yann Guidon wrote: > > hi, > > > > just a little detail : > > > > Cedric BAIL wrote: > > > The idea is to have this capability for every register size (8, 16, 32, 64). > > > We need this instructions to load register that are bigger than 64 bits (the > > > shifter only work on 64 bits, and it isn't its job to work in a inter chunk > > > capability). > > > > beware : Michael did not implement inter-chunk shifts, but it is not a norm. > > i would like to implement a different shifter structure which could shift > > 64 bits, even between two neighbouring chunks. > > It's not a problem to extend the shifter to 128, 256 or even more > bits. But it will affect the latency, of course. The same is true for > the ASU and IMU units; the only EU that is mostly immune to word size > changes is ROP2. > > A 256-bit F-CPU core that supports full-word operations will have longer > pipelines or more delay per pipeline stage (or both). Unless we use > variable latency EUs, almost all operations will be slower than in a > 64-bit version. > > The question is whether e.g. a 256-bit add, multiply or shift instruction > is really useful. Most of the time, applications use small integers that > fit into 32 (or less) bits, and IEEE single or double floats. That is, > wider registers will be used for SIMD operations a lot, but rarely for > `wide' operations. > >From the beginning, the FCPU is a 64 bit cpu. It manage 64 bits integer value. It is the size of chunk. The number of chunk is a power of 2. So we will never have to create a 256 bits shifter ! Numbers are fixed. i have soon made such speach few weeks, ago. At this day i propose to use 256 bits regiter set, so must think of inter chunk operation. Why 256 ? because it's 4*64 and this number was find to be an optimal for a vectorising algorithme. > How to move data to/from wide registers? Data that is stored in memory > can be handled with load/store, immediate data will be handled by the > loadcons* instructions, and the mix, expand, byterev and sdup instructions > (which may handle wider chunks than 64-bit without significant performance > loss) can be used to move data between different chunks. > > If we're going to implement a `monster shift' anyway, I suggest a `chunk > shift' instruction that operates on full-size registers (that is, there > will be no SIMD mode) and always shifts 64-bit quantities: > > cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) > cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) > > This can probably be integrated with the SHL execution unit. Why not using the SIMD flag ? And do : r1 = r2 << ([8|16|32|64]*r3) nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 2 04:38:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aTUT-0000G5-00 for ; Fri, 02 Aug 2002 05:52:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 05:52:37 +0200 (CEST) Received: (qmail 9755 invoked by uid 0); 2 Aug 2002 02:29:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 2 Aug 2002 02:29:04 -0000 Received: by moria.seul.org (Postfix) id 311191467E8; Thu, 1 Aug 2002 22:29:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E385F1467F7; Thu, 1 Aug 2002 22:29:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 693441467E8 for ; Thu, 1 Aug 2002 22:29:02 -0400 (EDT) Received: from f-cpu.org (kro1-14.n.club-internet.fr [213.44.93.14]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 015421693 for ; Fri, 2 Aug 2002 04:29:00 +0200 (CEST) Message-ID: <3D49F0A2.D9859371@f-cpu.org> Date: Fri, 02 Aug 2002 04:38:26 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: fm Subject: [f-cpu] about the scheduler... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Jaap made a drawing : http://f-cpu.seul.org/~f-cpu/new/scheduler.png This does not take into account the problem of the 3r1W cases (or 2R2W, depends), where the 4rth register number is this of the 3rd field with the LSB inverted. There must be a comparison with this negated bit, but fortunately it is easier to write it in VHDL than explain it by email :-) Otherwise, the drawing looks more complex than it is, it's just some FF, MUX and comparators that are copy/pasted and the basic principle is there. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 2 09:52:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aafE-0005KM-00 for ; Fri, 02 Aug 2002 13:32:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 13:32:12 +0200 (CEST) Received: (qmail 7600 invoked by uid 0); 2 Aug 2002 07:52:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 2 Aug 2002 07:52:24 -0000 Received: by moria.seul.org (Postfix) id 2145C14640E; Fri, 2 Aug 2002 03:52:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A3CB1467EE; Fri, 2 Aug 2002 03:52:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6FA6F14640E for ; Fri, 2 Aug 2002 03:52:22 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208020752.0878; Fri, 2 Aug 2002 07:52:08 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] about the scheduler... From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Aug 2002 07:52:08 GMT Message-id: <200208020752.0878@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: fm Date: 02/08/02 Objet: [f-cpu] about the scheduler... hi ! Jaap made a drawing : http://f-cpu.seul.org/~f-cpu/new/scheduler.png This does not take into account the problem of the 3r1W cases (or 2R2W, depends), where the 4rth register number is this of the 3rd field with the LSB inverted. There must be a comparison with this negated bit, but fortunately it is easier to write it in VHDL than explain it by email :-) Otherwise, the drawing looks more complex than it is, it's just some FF, MUX and comparators that are copy/pasted and the basic principle is there. >>> "just" some muxes ? :p but i always don't understand why= you need a specific unit to do it and not displaced the task to each un= it. >>> To do the scoreboard stuff, a memory could be used but i= t's could not be the fastest design possible. nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Aug 2 10:44:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aafG-0005KM-01 for ; Fri, 02 Aug 2002 13:32:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 13:32:14 +0200 (CEST) Received: (qmail 24681 invoked by uid 0); 2 Aug 2002 08:44:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 2 Aug 2002 08:44:09 -0000 Received: by moria.seul.org (Postfix) id 51E081467E8; Fri, 2 Aug 2002 04:44:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D9941467EE; Fri, 2 Aug 2002 04:44:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id 422861467E8 for ; Fri, 2 Aug 2002 04:44:06 -0400 (EDT) Message-ID: <20020802084405.13967.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.164] by web14202.mail.yahoo.com via HTTP; Fri, 02 Aug 2002 01:44:05 PDT Date: Fri, 2 Aug 2002 01:44:05 -0700 (PDT) From: jaap stolk Subject: Re: Rep:[f-cpu] about the scheduler... To: f-cpu@seul.org In-Reply-To: <200208020752.0878@th00.opsion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Nicolas Boulay wrote: > -----Message d'origine----- > De: Yann Guidon > A: fm > Date: 02/08/02 > Objet: [f-cpu] about the scheduler... > > hi ! > > Jaap made a drawing : > http://f-cpu.seul.org/~f-cpu/new/scheduler.png > > This does not take into account the problem of the > 3r1W > cases (or 2R2W, depends), where the 4rth register > number > is this of the 3rd field with the LSB inverted. > There must be a comparison with this negated bit, > but fortunately it is easier to write it in VHDL > than explain it by email :-) > > Otherwise, the drawing looks more complex than it > is, > it's just some FF, MUX and comparators that are > copy/pasted > and the basic principle is there. > > >>> "just" some muxes ? :p but i always don't > understand why you need a > specific unit to do it and not displaced the task to > each unit. > the ragister nr queue needs to be checked for posible stalls, it would be to slow if we need to get all this info to and from each EU. the write port nr queue only controls the xbar write and the register write, as the register unit is a bit sloow, it would be nice to put the queue close to that. if there is going to be an "enable" FIFO that travels along each EU, we can't realy use that in the scheduler unles its phisicaly neer the scheduler. i changed my mind on this: the check for zero in the register write queue can be don in other ways, like just ignoring R0_busy when R0_nr == 0. but we still need to check somehow if a write slot is free. if we write to R0, then it would nice if we kept the write (port nr) out of the queue, so we can use that write slot for somthing else. > >>> To do the scoreboard stuff, a memory could be > used but it's could > not be the fastest design possible. > nicO as far as i can see, if we use a scoreboard to get the condition flags for a register, we still need to bypass it in the x-bar stage, so why not always do it in the x-bar stage ? (the condition register can be read onto the x-bar read bus, and in case of a bypass the register valueue end op on the x-bar anyway. > > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. > http://f-cpu.seul.org/ > > > ______________________________________________________________________________ > ifrance.com, l'email gratuit le plus complet de > l'Internet ! > vos emails depuis un navigateur, en POP3, sur > Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Aug 2 11:04:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17aafI-0005KM-01 for ; Fri, 02 Aug 2002 13:32:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 13:32:16 +0200 (CEST) Received: (qmail 7484 invoked by uid 0); 2 Aug 2002 09:04:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 2 Aug 2002 09:04:18 -0000 Received: by moria.seul.org (Postfix) id 1542A1467ED; Fri, 2 Aug 2002 05:04:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD3AD1467F4; Fri, 2 Aug 2002 05:04:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by moria.seul.org (Postfix) with SMTP id 0A7071467ED for ; Fri, 2 Aug 2002 05:04:16 -0400 (EDT) Message-ID: <20020802090415.25486.qmail@web14205.mail.yahoo.com> Received: from [130.89.243.164] by web14205.mail.yahoo.com via HTTP; Fri, 02 Aug 2002 02:04:15 PDT Date: Fri, 2 Aug 2002 02:04:15 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] about the scheduler... To: f-cpu@seul.org In-Reply-To: <3D49F0A2.D9859371@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- Yann Guidon wrote: > hi ! > > This does not take into account the problem of the > 3r1W > cases (or 2R2W, depends), where the 4rth register > number > is this of the 3rd field with the LSB inverted. > There must be a comparison with this negated bit, > but fortunately it is easier to write it in VHDL > than explain it by email :-) ah, i think i get your point now, as far as i can see, its ok to write to a register that is "being computed" as long as the second write will be performed _after_ the first one. xmp: add r1,r2,r3 (2 cycle) mov r4,r5 ( 0 cycle) the simulator now wtites r4 first and r1+r2 later and the resulting value in r3 is wrong. :-( and than we have situations like these add r1,r2,r3 (2 cycle) (don't write carry) nop mov r4,r3 ( 0 cycle) where both write ports try to write to r3 at the same time. thanks, jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 2 01:43:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17adWa-0007Ia-00 for ; Fri, 02 Aug 2002 16:35:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 16:35:28 +0200 (CEST) Received: (qmail 4345 invoked by uid 0); 2 Aug 2002 11:48:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 2 Aug 2002 11:48:24 -0000 Received: by moria.seul.org (Postfix) id CBCF814640E; Fri, 2 Aug 2002 07:48:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9913E1467ED; Fri, 2 Aug 2002 07:48:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a167.home.uni-hannover.de [130.75.232.167]) by moria.seul.org (Postfix) with ESMTP id F1E6914640E for ; Fri, 2 Aug 2002 07:48:21 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA08499; Fri, 2 Aug 2002 01:43:24 +0200 Message-ID: <20020802014324.03613@thrai.stud.uni-hannover.de> Date: Fri, 2 Aug 2002 01:43:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.6 References: <20020724195904.23896@thrai.stud.uni-hannover.de> <1027960615.3d456f27547ca@imp.free.fr> <3D45B6EF.455A037F@f-cpu.org> <200207311751.10396.cedric.bail@free.fr> <20020801023651.10519@thrai.stud.uni-hannover.de> <1028211750.3d4944267b7e0@imp.free.fr> <3D494F9D.B4A7F601@f-cpu.org> <20020801202847.21164@thrai.stud.uni-hannover.de> <3D49C5C3.DC84A17D@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D49C5C3.DC84A17D@ifrance.com>; from nico on Fri, Aug 02, 2002 at 01:35:31AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 02, 2002 at 01:35:31AM +0200, nico wrote: [...] > > If we're going to implement a `monster shift' anyway, I suggest a `chunk > > shift' instruction that operates on full-size registers (that is, there > > will be no SIMD mode) and always shifts 64-bit quantities: > > > > cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) > > cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) > > > > This can probably be integrated with the SHL execution unit. > > Why not using the SIMD flag ? And do : > r1 = r2 << ([8|16|32|64]*r3) Too complicated. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 2 14:46:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17adWb-0007Ia-01 for ; Fri, 02 Aug 2002 16:35:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 16:35:29 +0200 (CEST) Received: (qmail 12970 invoked by uid 0); 2 Aug 2002 12:46:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 2 Aug 2002 12:46:40 -0000 Received: by moria.seul.org (Postfix) id BAF1514640E; Fri, 2 Aug 2002 08:46:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7BF181467ED; Fri, 2 Aug 2002 08:46:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id DFF2514640E for ; Fri, 2 Aug 2002 08:46:38 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208021246.1c74; Fri, 2 Aug 2002 12:46:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Manual 0.2.6 From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Aug 2002 12:46:28 GMT Message-id: <200208021246.1c74@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 02/08/02 Objet: Re: [f-cpu] Manual 0.2.6 On Fri, Aug 02, 2002 at 01:35:31AM +0200, nico wrote: [...] > > If we're going to implement a `monster shift' anyway, I = suggest a `chunk > > shift' instruction that operates on full-size registers = (that is, there > > will be no SIMD mode) and always shifts 64-bit quantitie= s: > >=20 > > cshiftl r3, r2, r1 // r1 =3D r2 << (64 * r3= ) > > cshiftr r3, r2, r1 // r1 =3D r2 >> (64 * r3= ) > >=20 > > This can probably be integrated with the SHL execution u= nit. >=20 > Why not using the SIMD flag ? And do : > r1 =3D r2 << ([8|16|32|64]*r3) Too complicated. >>> From hardware point of view ? You need in fact 4 shifter= s. I beleive such shifter are smaller than a true 64 bits one. Maybe the 16 bits version could be implemented (sizeof the l= oadcons). >>> What's think software guys ? Is this instruction usefull= ? I personnaly think yes. We can shuffle easly the vector and in= crease the use of SIMD. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 2 15:03:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17adWc-0007Ia-00 for ; Fri, 02 Aug 2002 16:35:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 16:35:30 +0200 (CEST) Received: (qmail 11361 invoked by uid 0); 2 Aug 2002 13:04:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 2 Aug 2002 13:04:43 -0000 Received: by moria.seul.org (Postfix) id 9018914640E; Fri, 2 Aug 2002 09:04:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F5F71467ED; Fri, 2 Aug 2002 09:04:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a069.home.uni-hannover.de [130.75.232.69]) by moria.seul.org (Postfix) with ESMTP id 0335F14640E for ; Fri, 2 Aug 2002 09:04:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00706; Fri, 2 Aug 2002 15:03:23 +0200 Message-ID: <20020802150323.22378@thrai.stud.uni-hannover.de> Date: Fri, 2 Aug 2002 15:03:23 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] about the scheduler... References: <3D49F0A2.D9859371@f-cpu.org> <20020802090415.25486.qmail@web14205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20020802090415.25486.qmail@web14205.mail.yahoo.com>; from jaap stolk on Fri, Aug 02, 2002 at 02:04:15AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 02, 2002 at 02:04:15AM -0700, jaap stolk wrote: [...] > ah, i think i get your point now, as far as i > can see, its ok to write to a register that is > "being computed" as long as the second write will > be performed _after_ the first one. [...] Or at the same time. In that case, the second result should overwrite the first; that is, the second write takes precedence. This is a rare case but it may happen with 2r2w instructions if only the `secondary' result is used, e.g.: addc r1, r2, r4 // we only want the carry bits from r5 and r6, r7, r4 // re-use of r4 overwrites previous result `addc' and `and' may write at the same time, with the `and' instruction taking precedence. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 2 15:55:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17adWd-0007Ia-00 for ; Fri, 02 Aug 2002 16:35:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 16:35:31 +0200 (CEST) Received: (qmail 18381 invoked by uid 0); 2 Aug 2002 13:46:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 2 Aug 2002 13:46:25 -0000 Received: by moria.seul.org (Postfix) id 0065C14640E; Fri, 2 Aug 2002 09:46:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC0DF146815; Fri, 2 Aug 2002 09:46:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B367514640E for ; Fri, 2 Aug 2002 09:46:24 -0400 (EDT) Received: from f-cpu.org (kdl4-52.n.club-internet.fr [213.44.3.52]) by relay-1v.club-internet.fr (Postfix) with ESMTP id A7AC81682 for ; Fri, 2 Aug 2002 15:46:22 +0200 (CEST) Message-ID: <3D4A8F64.E5A91D4@f-cpu.org> Date: Fri, 02 Aug 2002 15:55:48 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] about the scheduler... References: <20020802084405.13967.qmail@web14202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, jaap stolk wrote: > --- Nicolas Boulay wrote: > > -----Message d'origine----- > > De: Yann Guidon > > A: fm > i changed my mind on this: > the check for zero in the register write queue can > be don in other ways, like just ignoring > R0_busy when R0_nr == 0. > > but we still need to check somehow if a write slot is > free. > > if we write to R0, then it would nice if we > kept the write (port nr) out of the queue, so we > can use that write slot for somthing else. each slot should have a "valid" bit, so it validates the comparisons. Otherwise, as you see, it becomes too complex. Question : do we discard the instructions that write to register zero ? It can save a few cycles, but on the other hands it might become too complex to check. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Aug 3 02:17:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ailv-0000Fz-00 for ; Fri, 02 Aug 2002 22:11:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 22:11:39 +0200 (CEST) Received: (qmail 11851 invoked by uid 0); 2 Aug 2002 17:50:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 2 Aug 2002 17:50:41 -0000 Received: by moria.seul.org (Postfix) id 9516C1467ED; Fri, 2 Aug 2002 13:50:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 595D21467EF; Fri, 2 Aug 2002 13:50:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 05BC71467ED for ; Fri, 2 Aug 2002 13:50:40 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-153-36.dial.proxad.net [62.147.153.36]) by postfix2-2.free.fr (Postfix) with ESMTP id 351A45F92A for ; Fri, 2 Aug 2002 19:49:43 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] about the scheduler... Date: Sat, 3 Aug 2002 02:17:23 +0200 X-Mailer: KMail [version 1.4] References: <20020802084405.13967.qmail@web14202.mail.yahoo.com> <3D4A8F64.E5A91D4@f-cpu.org> In-Reply-To: <3D4A8F64.E5A91D4@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208030217.24150.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > each slot should have a "valid" bit, so it validates > the comparisons. Otherwise, as you see, it becomes > too complex. > > Question : do we discard the instructions that > write to register zero ? It can save a few cycles, > but on the other hands it might become too complex > to check. I think that's not usefull, because you have a nop, so if you use it it's only for scheduling reason. Too complex and not usefull. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 2 15:15:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ailv-0000Fz-01 for ; Fri, 02 Aug 2002 22:11:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 22:11:39 +0200 (CEST) Received: (qmail 11090 invoked by uid 0); 2 Aug 2002 18:01:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 2 Aug 2002 18:01:48 -0000 Received: by moria.seul.org (Postfix) id BFC401467F4; Fri, 2 Aug 2002 14:01:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7EB0F1467FE; Fri, 2 Aug 2002 14:01:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a153.home.uni-hannover.de [130.75.232.153]) by moria.seul.org (Postfix) with ESMTP id C6FD21467F4 for ; Fri, 2 Aug 2002 14:01:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00806; Fri, 2 Aug 2002 15:15:01 +0200 Message-ID: <20020802151501.63679@thrai.stud.uni-hannover.de> Date: Fri, 2 Aug 2002 15:15:01 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Manual 0.2.6 References: <200208021246.1c74@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208021246.1c74@th00.opsion.fr>; from Nicolas Boulay on Fri, Aug 02, 2002 at 12:46:28PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 02, 2002 at 12:46:28PM +0000, Nicolas Boulay wrote: [...] > > > cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) > > > cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) > > > > > > This can probably be integrated with the SHL execution unit. > > > > Why not using the SIMD flag ? And do : > > r1 = r2 << ([8|16|32|64]*r3) > > Too complicated. > > >>> From hardware point of view ? You need in fact 4 shifters. I beleive > such shifter are smaller than a true 64 bits one. > Maybe the 16 bits version could be implemented (sizeof the loadcons). I don't want to make the control logic too complex. Therefore, the basic shift count (= chunk size) will have to be fixed. If it were variable, I also had to scale (that is, shift) the second operand in front of the control logic part. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Fri Aug 2 20:24:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ailw-0000Fz-01 for ; Fri, 02 Aug 2002 22:11:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 02 Aug 2002 22:11:40 +0200 (CEST) Received: (qmail 25033 invoked by uid 0); 2 Aug 2002 18:24:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 2 Aug 2002 18:24:34 -0000 Received: by moria.seul.org (Postfix) id 1497B1467EF; Fri, 2 Aug 2002 14:24:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C06D01467FF; Fri, 2 Aug 2002 14:24:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id D07E51467EF for ; Fri, 2 Aug 2002 14:24:31 -0400 (EDT) Message-ID: <20020802182431.18632.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.164] by web14202.mail.yahoo.com via HTTP; Fri, 02 Aug 2002 11:24:31 PDT Date: Fri, 2 Aug 2002 11:24:31 -0700 (PDT) From: jaap stolk Subject: Re: Rep:[f-cpu] about the scheduler... To: f-cpu@seul.org In-Reply-To: <200208030217.24150.cedric.bail@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, --- cedric wrote: > > Question : do we discard the instructions that > > write to register zero ? It can save a few cycles, > > but on the other hands it might become too complex > > to check. > > I think that's not usefull, because you have a nop, > so if > you use it it's only for scheduling reason. Too > complex > and not usefull. i mean do the instruction, but don't set the register write queue and the x-bar write queue. it looks easy to me, it can be easily done in the decoder. (the scheduler cycle runs after the decoder cycle) the only thing the scheduler dous during decode is check for posible bypasses. it may not look very helpful for fast instructions but we don't heve only two write slots per instruction so it seems a pity to spoil them. when long instructions use both slots to save the result, than that almost automaticaly results in a stall further down the line, becouse there are no free slots. therfore it looks very inportent to me to not use a free write slot if we write the result to register 0 anyway. __________________ (small) simulator update, i got (unconditional) JMP(/CALL/RET) working :-) jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 2 20:09:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17alYP-0002ae-00 for ; Sat, 03 Aug 2002 01:09:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 03 Aug 2002 01:09:53 +0200 (CEST) Received: (qmail 28026 invoked by uid 0); 2 Aug 2002 21:39:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 2 Aug 2002 21:39:33 -0000 Received: by moria.seul.org (Postfix) id DDCDF1467ED; Fri, 2 Aug 2002 17:39:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4C031467FF; Fri, 2 Aug 2002 17:39:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a093.home.uni-hannover.de [130.75.232.93]) by moria.seul.org (Postfix) with ESMTP id 2A8811467ED for ; Fri, 2 Aug 2002 17:39:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00507; Fri, 2 Aug 2002 20:09:21 +0200 Message-ID: <20020802200921.46422@thrai.stud.uni-hannover.de> Date: Fri, 2 Aug 2002 20:09:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] about the scheduler... References: <20020802084405.13967.qmail@web14202.mail.yahoo.com> <3D4A8F64.E5A91D4@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D4A8F64.E5A91D4@f-cpu.org>; from Yann Guidon on Fri, Aug 02, 2002 at 03:55:48PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 02, 2002 at 03:55:48PM +0200, Yann Guidon wrote: [...] > Question : do we discard the instructions that > write to register zero ? It can save a few cycles, > but on the other hands it might become too complex > to check. If it is an instruction with a side effect (like load), we must not discard it (only the final write). Making a difference here is probably too much effort. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 3 00:34:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17alYP-0002ae-01 for ; Sat, 03 Aug 2002 01:09:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 03 Aug 2002 01:09:53 +0200 (CEST) Received: (qmail 10450 invoked by uid 0); 2 Aug 2002 22:25:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 2 Aug 2002 22:25:34 -0000 Received: by moria.seul.org (Postfix) id 0E7A61467ED; Fri, 2 Aug 2002 18:25:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D4124146800; Fri, 2 Aug 2002 18:25:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 2C9EE1467ED for ; Fri, 2 Aug 2002 18:25:33 -0400 (EDT) Received: from f-cpu.org (kll1-33.n.club-internet.fr [213.44.91.33]) by relay-2v.club-internet.fr (Postfix) with ESMTP id E8AC216A0 for ; Sat, 3 Aug 2002 00:25:30 +0200 (CEST) Message-ID: <3D4B0912.A1EDF5E0@f-cpu.org> Date: Sat, 03 Aug 2002 00:34:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] about the scheduler... References: <20020802084405.13967.qmail@web14202.mail.yahoo.com> <3D4A8F64.E5A91D4@f-cpu.org> <20020802200921.46422@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Aug 02, 2002 at 03:55:48PM +0200, Yann Guidon wrote: > [...] > > Question : do we discard the instructions that > > write to register zero ? It can save a few cycles, > > but on the other hands it might become too complex > > to check. > > If it is an instruction with a side effect (like load), we must not > discard it (only the final write). Making a difference here is > probably too much effort. sure. > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Aug 4 21:21:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bNYG-0005JK-00 for ; Sun, 04 Aug 2002 17:44:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 Aug 2002 17:44:16 +0200 (CEST) Received: (qmail 663 invoked by uid 0); 4 Aug 2002 14:52:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 4 Aug 2002 14:52:12 -0000 Received: by moria.seul.org (Postfix) id D6E2614680C; Sun, 4 Aug 2002 10:52:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B094D146813; Sun, 4 Aug 2002 10:52:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 343A414680C for ; Sun, 4 Aug 2002 10:52:10 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-158-74.dial.proxad.net [62.147.158.74]) by postfix2-2.free.fr (Postfix) with ESMTP id CCA3D5FBBA for ; Sun, 4 Aug 2002 16:52:07 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Manual 0.2.6 Date: Sun, 4 Aug 2002 21:21:38 +0200 X-Mailer: KMail [version 1.4] References: <200208021246.1c74@th00.opsion.fr> <20020802151501.63679@thrai.stud.uni-hannover.de> In-Reply-To: <20020802151501.63679@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208042121.38804.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Le Vendredi 2 Août 2002 15:15, Michael Riepe a écrit : > On Fri, Aug 02, 2002 at 12:46:28PM +0000, Nicolas Boulay wrote: > [...] > > > > > cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) > > > > cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) > > > > > > > > This can probably be integrated with the SHL execution unit. > > > > > > Why not using the SIMD flag ? And do : > > > r1 = r2 << ([8|16|32|64]*r3) > > > > Too complicated. > > > > >>> From hardware point of view ? You need in fact 4 shifters. I beleive > > such shifter are smaller than a true 64 bits one. > > Maybe the 16 bits version could be implemented (sizeof the loadcons). > > I don't want to make the control logic too complex. Therefore, the basic > shift count (= chunk size) will have to be fixed. If it were variable, > I also had to scale (that is, shift) the second operand in front of the > control logic part. I think you are right, because we have the mix/expand instruction. Currently we must do something like this for 8 bits : mixl.b r1, r2, r9 mixl.b r3, r4, r10 mixl.b r5, r6, r11 mixl.b r7, r8, r12 mixl.d r9, r10, r13 mixl.d r11, r12, r14 mixl.q r13, r14, r15 7 cycles for 8 chunks, that's quite good. So no need of a more complex instruction for small chunk and the cshift[l/r] will be enough (perhaps a immediate version will be usefull). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Aug 4 21:45:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bNYG-0005JK-01 for ; Sun, 04 Aug 2002 17:44:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 Aug 2002 17:44:16 +0200 (CEST) Received: (qmail 22727 invoked by uid 0); 4 Aug 2002 14:52:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 4 Aug 2002 14:52:14 -0000 Received: by moria.seul.org (Postfix) id 2F400146810; Sun, 4 Aug 2002 10:52:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0313C146814; Sun, 4 Aug 2002 10:52:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 9F386146813 for ; Sun, 4 Aug 2002 10:52:13 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-158-74.dial.proxad.net [62.147.158.74]) by postfix2-2.free.fr (Postfix) with ESMTP id 47CF25FA7A for ; Sun, 4 Aug 2002 16:52:12 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Conditionnal load and store, the return Date: Sun, 4 Aug 2002 21:45:35 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208042145.35776.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I have reread the discussion about conditionnal load and store, and I think that we forgot something : exception. In fact when we do a load or a store and check the condition only on write. The problem is what append if page fault occur ? I think we must clarify that. From my point of view I think that we must do the test before starting any memory operation, so a trap only occur if the test is true. We must do the same if we have a conditionnal prefetch. It's for me the only way to correctly execute the 2 branch of a if simultaneously. Finally what did we do with the cachemm instruction ? Did we remove or change this strange instruction ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Aug 4 22:50:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bNYH-0005JK-00 for ; Sun, 04 Aug 2002 17:44:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 Aug 2002 17:44:17 +0200 (CEST) Received: (qmail 17468 invoked by uid 0); 4 Aug 2002 14:52:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 4 Aug 2002 14:52:17 -0000 Received: by moria.seul.org (Postfix) id 5F016146814; Sun, 4 Aug 2002 10:52:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B16F146817; Sun, 4 Aug 2002 10:52:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id C7080146814 for ; Sun, 4 Aug 2002 10:52:14 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-158-74.dial.proxad.net [62.147.158.74]) by postfix2-2.free.fr (Postfix) with ESMTP id 77CE65FB9C for ; Sun, 4 Aug 2002 16:52:13 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Come back of loadcons Date: Sun, 4 Aug 2002 22:50:50 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208042250.50015.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Because no body continu the discussion about loadcons, I don't know if we take a decision. For memory, Yann say that the shifted loadcons cost a lot in the CDP and that's a reason to not implement it. For Michael "it only cost a mux" in the CDP that currently always exist. From Thomas point of view it's better because of scalability reason and I agree with him. If I resume all this different argument I can only go to the conclusion that we must implement this loadcons. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Aug 4 17:44:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bPze-00079V-00 for ; Sun, 04 Aug 2002 20:20:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 Aug 2002 20:20:42 +0200 (CEST) Received: (qmail 3984 invoked by uid 0); 4 Aug 2002 17:50:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Aug 2002 17:50:40 -0000 Received: by moria.seul.org (Postfix) id 4AD9C146814; Sun, 4 Aug 2002 13:50:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D07BC146817; Sun, 4 Aug 2002 13:50:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a041.home.uni-hannover.de [130.75.232.41]) by moria.seul.org (Postfix) with ESMTP id 317AC146814 for ; Sun, 4 Aug 2002 13:50:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00576; Sun, 4 Aug 2002 17:44:32 +0200 Message-ID: <20020804174432.52532@thrai.stud.uni-hannover.de> Date: Sun, 4 Aug 2002 17:44:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Come back of loadcons References: <200208042250.50015.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208042250.50015.cedric.bail@free.fr>; from cedric on Sun, Aug 04, 2002 at 10:50:50PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 04, 2002 at 10:50:50PM +0200, cedric wrote: > Because no body continu the discussion about loadcons, I don't know if we take > a decision. For memory, Yann say that the shifted loadcons cost a lot in the > CDP and that's a reason to not implement it. For Michael "it only cost a mux" > in the CDP that currently always exist. > From Thomas point of view it's better because of scalability reason and I > agree with him. If I resume all this different argument I can only go to the > conclusion that we must implement this loadcons. There is a new argument: When we have `cshiftl', the old loadcons[x].4 (and higher suffixes) and the new `shifting loadcons' are no longer required. Building large constants may take a little longer with cshift, but it is possible to populate the whole register, no matter how wide it is - and we need only two opcodes (loadcons.[0-3] and loadconsx.[0-3]). The only remaining argument against the original loadcons is that it requires a partial write (that is, a feedback from the register read port and a mux inside the CDP). But that's true for the shifting loadcons as well, unless we use a `shadow register' implementation. I think we should implement cshift and drop the shifting loadcons variant, as well as loadcons[x].[4-15]. Any objections? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Aug 4 17:16:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bPze-00079V-01 for ; Sun, 04 Aug 2002 20:20:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 Aug 2002 20:20:42 +0200 (CEST) Received: (qmail 15998 invoked by uid 0); 4 Aug 2002 17:50:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 4 Aug 2002 17:50:43 -0000 Received: by moria.seul.org (Postfix) id EDAEC146819; Sun, 4 Aug 2002 13:50:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CADE714681A; Sun, 4 Aug 2002 13:50:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a041.home.uni-hannover.de [130.75.232.41]) by moria.seul.org (Postfix) with ESMTP id F1C8D146819 for ; Sun, 4 Aug 2002 13:50:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00505; Sun, 4 Aug 2002 17:16:13 +0200 Message-ID: <20020804171613.60163@thrai.stud.uni-hannover.de> Date: Sun, 4 Aug 2002 17:16:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Manual 0.2.6 References: <200208021246.1c74@th00.opsion.fr> <20020802151501.63679@thrai.stud.uni-hannover.de> <200208042121.38804.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208042121.38804.cedric.bail@free.fr>; from cedric on Sun, Aug 04, 2002 at 09:21:38PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 04, 2002 at 09:21:38PM +0200, cedric wrote: [... cshift instruction...] > I think you are right, because we have the mix/expand instruction. Currently > we must do something like this for 8 bits : > mixl.b r1, r2, r9 > mixl.b r3, r4, r10 > mixl.b r5, r6, r11 > mixl.b r7, r8, r12 > mixl.d r9, r10, r13 > mixl.d r11, r12, r14 > mixl.q r13, r14, r15 Right. > 7 cycles for 8 chunks, that's quite good. So no need of a more complex > instruction for small chunk and the cshift[l/r] will be enough (perhaps a > immediate version will be usefull). An immediate version (cshift[rl]i) is not a problem. I think an `arithmetic' right shift (cshiftra) is not useful; but what about rotates (crotl/crotr)? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Aug 4 23:51:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bUGn-0001jq-00 for ; Mon, 05 Aug 2002 00:54:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 05 Aug 2002 00:54:41 +0200 (CEST) Received: (qmail 22027 invoked by uid 0); 4 Aug 2002 21:30:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Aug 2002 21:30:00 -0000 Received: by moria.seul.org (Postfix) id 66CC414681D; Sun, 4 Aug 2002 17:29:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A611146828; Sun, 4 Aug 2002 17:29:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id DC62514681D for ; Sun, 4 Aug 2002 17:29:58 -0400 (EDT) Received: from ifrance.com (vlt6-86.n.club-internet.fr [194.158.119.86]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 2E6121716 for ; Sun, 4 Aug 2002 23:29:56 +0200 (CEST) Message-ID: <3D4DA1C8.582F8121@ifrance.com> Date: Sun, 04 Aug 2002 23:51:04 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Come back of loadcons References: <200208042250.50015.cedric.bail@free.fr> <20020804174432.52532@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Sun, Aug 04, 2002 at 10:50:50PM +0200, cedric wrote: > > Because no body continu the discussion about loadcons, I don't know if we take > > a decision. For memory, Yann say that the shifted loadcons cost a lot in the > > CDP and that's a reason to not implement it. For Michael "it only cost a mux" > > in the CDP that currently always exist. > > From Thomas point of view it's better because of scalability reason and I > > agree with him. If I resume all this different argument I can only go to the > > conclusion that we must implement this loadcons. > > There is a new argument: When we have `cshiftl', the old loadcons[x].4 > (and higher suffixes) and the new `shifting loadcons' are no longer > required. Building large constants may take a little longer with cshift, > but it is possible to populate the whole register, no matter how wide > it is - and we need only two opcodes (loadcons.[0-3] and loadconsx.[0-3]). > > The only remaining argument against the original loadcons is that it > requires a partial write (that is, a feedback from the register read > port and a mux inside the CDP). But that's true for the shifting > loadcons as well, unless we use a `shadow register' implementation. > > I think we should implement cshift and drop the shifting loadcons > variant, as well as loadcons[x].[4-15]. > > Any objections? nop ! For immediat data, i propose to add the idea to use 6 bits immediat for each instructions (it does cost nothing more, you just use the field of the register adress instead of the content of the register). I beleive that's a lot of small constant could be used in real code. So such immediat could be interresting (small multi dimentionnal array index calculation, stack index management,...) ! nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 5 07:42:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17beNE-0008SI-01 for ; Mon, 05 Aug 2002 11:42:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 05 Aug 2002 11:42:00 +0200 (CEST) Received: (qmail 537 invoked by uid 0); 5 Aug 2002 05:32:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 5 Aug 2002 05:32:46 -0000 Received: by moria.seul.org (Postfix) id ED69A1467F7; Mon, 5 Aug 2002 01:32:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C4FF314684E; Mon, 5 Aug 2002 01:32:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 76CB41467FD for ; Mon, 5 Aug 2002 01:32:44 -0400 (EDT) Received: from f-cpu.org (kro1-39.n.club-internet.fr [213.44.93.39]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 672531698 for ; Mon, 5 Aug 2002 07:32:42 +0200 (CEST) Message-ID: <3D4E1037.B1FF97C5@f-cpu.org> Date: Mon, 05 Aug 2002 07:42:15 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Come back of loadcons References: <200208042250.50015.cedric.bail@free.fr> <20020804174432.52532@thrai.stud.uni-hannover.de> <3D4DA1C8.582F8121@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > Michael Riepe a écrit : > > Any objections? > > nop ! > > For immediat data, i propose to add the idea to use 6 bits immediat for > each instructions (it does cost nothing more, you just use the field of > the register adress instead of the content of the register). I beleive > that's a lot of small constant could be used in real code. So such > immediat could be interresting (small multi dimentionnal array index > calculation, stack index management,...) ! > > nicO ok, then let's clone a VAX from now on... WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Aug 5 18:19:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bfLQ-0000nG-01 for ; Mon, 05 Aug 2002 12:44:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 05 Aug 2002 12:44:12 +0200 (CEST) Received: (qmail 3520 invoked by uid 0); 5 Aug 2002 09:51:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 5 Aug 2002 09:51:58 -0000 Received: by moria.seul.org (Postfix) id 61B8F1467E9; Mon, 5 Aug 2002 05:51:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3538F14682F; Mon, 5 Aug 2002 05:51:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id D7A091467E9 for ; Mon, 5 Aug 2002 05:51:57 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-169.dial.proxad.net [62.147.156.169]) by postfix3-2.free.fr (Postfix) with ESMTP id 25D0D17ECD for ; Mon, 5 Aug 2002 11:51:56 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Manual 0.2.6 Date: Mon, 5 Aug 2002 18:19:54 +0200 X-Mailer: KMail [version 1.4] References: <200208021246.1c74@th00.opsion.fr> <200208042121.38804.cedric.bail@free.fr> <20020804171613.60163@thrai.stud.uni-hannover.de> In-Reply-To: <20020804171613.60163@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208051819.55274.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > [... cshift instruction...] > [... use mix ...] > > 7 cycles for 8 chunks, that's quite good. So no need of a more complex > > instruction for small chunk and the cshift[l/r] will be enough (perhaps a > > immediate version will be usefull). > > An immediate version (cshift[rl]i) is not a problem. > > I think an `arithmetic' right shift (cshiftra) is not useful; but what > about rotates (crotl/crotr)? I agree for the arithmetic right shift. For a rotates (crot[l/r]), I think it depend of move. If move work with different size, it can be usefull, because we can extract more quickly a data from the register. So I am for. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 5 01:36:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bizm-0000PP-00 for ; Mon, 05 Aug 2002 16:38:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 05 Aug 2002 16:38:06 +0200 (CEST) Received: (qmail 9968 invoked by uid 0); 5 Aug 2002 11:42:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 5 Aug 2002 11:42:30 -0000 Received: by moria.seul.org (Postfix) id 1CC7A1467E9; Mon, 5 Aug 2002 07:42:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E899914682F; Mon, 5 Aug 2002 07:42:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a123.home.uni-hannover.de [130.75.232.123]) by moria.seul.org (Postfix) with ESMTP id C81FE1467E9 for ; Mon, 5 Aug 2002 07:42:26 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02135; Mon, 5 Aug 2002 01:36:52 +0200 Message-ID: <20020805013652.50245@thrai.stud.uni-hannover.de> Date: Mon, 5 Aug 2002 01:36:52 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Come back of loadcons References: <200208042250.50015.cedric.bail@free.fr> <20020804174432.52532@thrai.stud.uni-hannover.de> <3D4DA1C8.582F8121@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D4DA1C8.582F8121@ifrance.com>; from nico on Sun, Aug 04, 2002 at 11:51:04PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 04, 2002 at 11:51:04PM +0200, nico wrote: [...] > For immediat data, i propose to add the idea to use 6 bits immediat for > each instructions (it does cost nothing more, you just use the field of > the register adress instead of the content of the register). I beleive > that's a lot of small constant could be used in real code. So such > immediat could be interresting (small multi dimentionnal array index > calculation, stack index management,...) ! We already have 8-bit immediate forms for most instructions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 5 14:27:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bizo-0000PP-01 for ; Mon, 05 Aug 2002 16:38:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 05 Aug 2002 16:38:08 +0200 (CEST) Received: (qmail 21393 invoked by uid 0); 5 Aug 2002 12:27:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 5 Aug 2002 12:27:52 -0000 Received: by moria.seul.org (Postfix) id 391031467F5; Mon, 5 Aug 2002 08:27:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5D33146801; Mon, 5 Aug 2002 08:27:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 133981467F5 for ; Mon, 5 Aug 2002 08:27:49 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208051227.2757; Mon, 5 Aug 2002 12:27:39 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Come back of loadcons From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Aug 2002 12:27:39 GMT Message-id: <200208051227.2757@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 05/08/02 Objet: Re: [f-cpu] Come back of loadcons On Sun, Aug 04, 2002 at 11:51:04PM +0200, nico wrote: [...] > For immediat data, i propose to add the idea to use 6 bits= immediat for > each instructions (it does cost nothing more, you just use= the field of > the register adress instead of the content of the register= ). I beleive > that's a lot of small constant could be used in real code.= So such > immediat could be interresting (small multi dimentionnal a= rray index > calculation, stack index management,...) ! We already have 8-bit immediate forms for most instructions. >>> Oups ! should reread the manual ! But it signifies that = 2 bits from the "opcode" are discared. So SIMD isn't used anymore ? Is t= hat annoying for software use ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur l= e WAP... http://www.ifrance.com/_reloc/email.emailif ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 5 18:26:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17bqb4-00041R-01 for ; Tue, 06 Aug 2002 00:45:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 06 Aug 2002 00:45:06 +0200 (CEST) Received: (qmail 14508 invoked by uid 0); 5 Aug 2002 21:47:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 5 Aug 2002 21:47:40 -0000 Received: by moria.seul.org (Postfix) id B4D2D1467E9; Mon, 5 Aug 2002 17:47:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 960B91467FD; Mon, 5 Aug 2002 17:47:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a067.home.uni-hannover.de [130.75.232.67]) by moria.seul.org (Postfix) with ESMTP id 33FBD1467E9 for ; Mon, 5 Aug 2002 17:47:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01282; Mon, 5 Aug 2002 18:26:45 +0200 Message-ID: <20020805182644.44231@thrai.stud.uni-hannover.de> Date: Mon, 5 Aug 2002 18:26:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Come back of loadcons References: <200208051227.2757@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208051227.2757@th00.opsion.fr>; from Nicolas Boulay on Mon, Aug 05, 2002 at 12:27:39PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 05, 2002 at 12:27:39PM +0000, Nicolas Boulay wrote: [...] > We already have 8-bit immediate forms for most instructions. > > >>> Oups ! should reread the manual ! But it signifies that 2 bits from > the "opcode" are discared. So SIMD isn't used anymore ? Is that annoying > for software use ? The 8-bit immediate forms support SIMD where it makes sense. They just don't support every operating mode (like saturated addition, for example). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Aug 6 14:11:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17c4G0-0004pM-01 for ; Tue, 06 Aug 2002 15:20:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 06 Aug 2002 15:20:16 +0200 (CEST) Received: (qmail 15268 invoked by uid 0); 6 Aug 2002 12:08:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 6 Aug 2002 12:08:38 -0000 Received: by moria.seul.org (Postfix) id 2291F14691A; Tue, 6 Aug 2002 08:08:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D197C14691D; Tue, 6 Aug 2002 08:08:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf07bis.bellsouth.net (mail207.mail.bellsouth.net [205.152.58.147]) by moria.seul.org (Postfix) with ESMTP id 3D21914691A for ; Tue, 6 Aug 2002 08:08:36 -0400 (EDT) Received: from computer ([208.60.245.52]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020806121009.FAZT23238.imf07bis.bellsouth.net@computer>; Tue, 6 Aug 2002 08:10:09 -0400 Message-ID: <000801c23d42$5723e020$34f53cd0@computer> From: "richard hartny" To: Cc: Subject: [f-cpu] Erin64 Date: Tue, 6 Aug 2002 07:11:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C23D18.6CE5BCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C23D18.6CE5BCA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Food for thought, As some of you know of my effort; I have added Instructions to the = basic DDP-516 repetoire. The following are to support data handling = (packing/unpacking) requirements for a 64 Bit design: Clear Bit Set Bit Test Bit & Branch Load selected Byte in the selected Byte Position Store selected Byte in the selected Byte Position Clear selected Byte in Accumulator (A-Reg) Haven't forgot you Ben - I wanted good news of implementation before = sending you=20 a data package. The Load & Store logic is the most complicated compared = to other functions & requires a lot of FPGA cells. The performance exceeds my = self inflicted requirements. Dick Hartney ------=_NextPart_000_0005_01C23D18.6CE5BCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Food for thought,
 
    As some of you know = of my=20 effort; I have added Instructions to the basic
DDP-516 repetoire.  The following = are to=20 support data handling (packing/unpacking) requirements for a 64 Bit design:
 
    Clear = Bit
    Set Bit
    Test Bit &=20 Branch
    Load selected Byte = in the=20 selected Byte Position
    Store selected Byte = in the=20 selected Byte Position
    Clear selected Byte = in=20 Accumulator (A-Reg)
 
    Haven't forgot you = Ben - I=20 wanted good news of implementation before sending you
a data package. The Load & Store = logic is the=20 most complicated compared to other
functions & requires a lot of FPGA = cells. =20 The performance exceeds my self inflicted
requirements.
 
Dick Hartney
------=_NextPart_000_0005_01C23D18.6CE5BCA0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 7 02:29:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEkQ-0001C8-00 for ; Wed, 07 Aug 2002 02:32:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:22 +0200 (CEST) Received: (qmail 25874 invoked by uid 0); 6 Aug 2002 19:25:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 6 Aug 2002 19:25:15 -0000 Received: by moria.seul.org (Postfix) id 6FF20146802; Tue, 6 Aug 2002 15:25:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F35E14680C; Tue, 6 Aug 2002 15:25:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id CB39D146802 for ; Tue, 6 Aug 2002 15:25:13 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-153-43.dial.proxad.net [62.147.153.43]) by postfix1-2.free.fr (Postfix) with ESMTP id DABDCAB6B3 for ; Tue, 6 Aug 2002 21:25:11 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] TLB resume Date: Wed, 7 Aug 2002 02:29:09 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208070229.09431.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Here is an extract from the TLB discussion that append one month ago. Michael propose this : " I've been thinking about the TLB before; IMHO, we need at least the following (assuming bits for the page offset): - virtual address (64- bits) - physical address (64- bits) - address space identifier (ASI; 8 bits was suggested) - supervisor access rights (RWX, 3 bits) - user access rights (RWX, 3 bits) - valid bit (indicating that the entry is valid) - dirty bit (indicating that the page has been written to) - used bit (indicating that the page has been accessed) - page size (4K << size, 6 bits) " "present bits" has been removed because it's only needed by HW TLB after the discussion. I hope I have maid a good resume, but if someone want to add something, before I add this to the manual (perhaps we must clarify how to access it before). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 7 03:47:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEkQ-0001C8-01 for ; Wed, 07 Aug 2002 02:32:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:22 +0200 (CEST) Received: (qmail 29383 invoked by uid 0); 6 Aug 2002 19:25:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 6 Aug 2002 19:25:17 -0000 Received: by moria.seul.org (Postfix) id 94A1714680C; Tue, 6 Aug 2002 15:25:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6BE9C14680E; Tue, 6 Aug 2002 15:25:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id DC18814680C for ; Tue, 6 Aug 2002 15:25:14 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-153-43.dial.proxad.net [62.147.153.43]) by postfix1-2.free.fr (Postfix) with ESMTP id 72746AB78C for ; Tue, 6 Aug 2002 21:25:13 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] SR security Date: Wed, 7 Aug 2002 03:47:38 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208070342.17682.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Because on the F-CPU all the security depend on TLB and SR, we need to discuss about them. About SR, I think that we have 2 differents class of SR, the one that can only be read and the other than can be read and write. The one that are readed can be readed by a lot of normal program, I mean that we will have some SR for the Floating Point (rouding flags, ...) for example. And you must have a quick access to them. For the others, they can be slow, because write on them can change the internal state of the CPU. Finally we must access to both of them with the immediate form of GET/PUT. Why not using the LSB to determine if the SR is read only or not ? In the manual, we currently have some specified SR : TLB_OFF, GET_CMB, GET_VM (I think we have : FAMILY, STEPPING, MAX_SIZE, SIZE_0, SIZE_1, SIZE_2, SIZE_3, MAX_CHUNK_SIZE, CYCLE, IRQ_BASE, IRQ_SIZE, TRAP_BASE, TRAP_SIZE, SYSCALL_BASE, SYSCALL_SIZE, URL, URL_SIZE, TIME_SLICE, CMB_NEXT, CMB). In fact we must clarify them, TLB_OFF is really usefull. We didn't need GET_CMB and GET_VM has defined into the manual. We currently have an other strange SR : TLBMISS_BASE (For me it's a trap). And I didn't understood the meaning of PAGING and CONTROL. What I think we need to add : - READ_ONLY, that say if we must trap or not when we access to read only SR - WRITE_ONLY, idem but for read/write SR - ASI, the Identifier of the current task - IRQ_STACK_BASE and IRQ_STACK_SIZE, for being able to handle multiple IRQ at the same time - TRAP_STACK_BASE and TRAP_STACK_SIZE, in case of multiple TRAP (I think it's not usefull, because the trap handler must do his job correctly) So it's a resume of what I read in the last snapshot from Whygee, in the manual and what we say on the mailing list. I hope I didn't forget or missunderstand something. Cedric PS: my objective it's to start adding a SR map for the next release of the manual so that thinking to port an OS like L4 can start. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 6 22:27:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEkR-0001C8-00 for ; Wed, 07 Aug 2002 02:32:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:23 +0200 (CEST) Received: (qmail 4567 invoked by uid 0); 6 Aug 2002 20:06:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Aug 2002 20:06:17 -0000 Received: by moria.seul.org (Postfix) id 49414146802; Tue, 6 Aug 2002 16:06:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 17E5714680D; Tue, 6 Aug 2002 16:06:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 925BD146802 for ; Tue, 6 Aug 2002 16:06:15 -0400 (EDT) Received: from ifrance.com (vlt9-228.n.club-internet.fr [195.36.223.228]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 6CC4A1698 for ; Tue, 6 Aug 2002 22:06:12 +0200 (CEST) Message-ID: <3D503133.5874B5BA@ifrance.com> Date: Tue, 06 Aug 2002 22:27:31 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB resume References: <200208070229.09431.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I try to explain for every one. TLB is a little buffer used to translate virtual adresse to physical memory adress. This is used to clearly sperate adresse space of processes. It's possible to have 2 differentes TLB : one for data and one for code. This piece of hardware is critical because on the critical data path when we access the memory. Sometimes the L1 cache cache virtual adresse to avoid accessing to much the tlb. Tlb is critical on task switch, too. On x86, it must be almost entirely flush before being usable for the next task. The tlb is in fact a kind of caches. It mainly use CAM (content adresse memory, so the more entries, the slower) it's memory where you could send a data and it give you back an address (that could used to access an other normal memory bank, it's a key to content association). It critical by it's size the number of address and by the size of the page used. x86 have a very week protection model by using only 2 bit, that's why buffer overflow are so easy to do in the x86 world. cedric a écrit : > > Here is an extract from the TLB discussion that append one month ago. > > Michael propose this : > " > I've been thinking about the TLB before; IMHO, we need at least the > following (assuming bits for the page offset): > > - virtual address (64- bits) the input. > - physical address (64- bits) The main ouput. > - address space identifier (ASI; 8 bits was suggested) Could be an output and then we check it with an SR. But if it's an input, we didn't to flush the tlb during a task switch ! > - user access rights (RWX, 3 bits) Ouput and check what it's doing and raise the appropriate trap if needed. > - supervisor access rights (RWX, 3 bits) i don't really understood the use of this one. If a process make a system call. It use a specif call that change the mode (user-> superuser). Superuser (the kernel) could access to anything. But the strangest thing is that superuser are the one that could change the tlb content... > - valid bit (indicating that the entry is valid) > - dirty bit (indicating that the page has been written to) > - used bit (indicating that the page has been accessed) That's for tlb miss handler to accelerate some choice and avoid duplicate rewrite and so one... > > - page size (4K << size, 6 bits) Page size are critical. How many memories could be acceded without a tlb miss ? In x86 world, the pages are 4 Kb large. The tlb have between 32 to 128 entries : 512 Kb adressed. That's few ! Intel introduice big sized pages (4 Mb) for framebuffer for example. Linux use it for the kernel code (so there is no tlb miss inside the kernel code). If the size of the page are bigger you could addresse more memories with the same number of entries. But i could became hard for the pagging system to find hole aligned with power of 2 adresse bits. A process needs at least 3 pages (code, data, stack). Here is a top extract : 10402 nico 9 0 23516 22M 12628 S 0,0 24,8 0:00 mozilla-bin 10402 nico 9 0 23516 22M 12628 S 0,0 24,8 0:00 mozilla-bin 10402 nico 9 0 23516 22M 12628 S 0,0 24,8 0:00 mozilla-bin 10403 nico 9 0 23516 22M 12628 S 0,0 24,8 0:00 mozilla-bin 10409 nico 9 0 20920 20M 9620 S 0,0 21,9 0:24 netscape-commun 1439 root 9 0 59432 7608 1216 S 0,0 8,0 2:16 X 10427 nico 8 0 3832 3752 3272 S 0,0 3,9 0:00 netscape-commun 1351 xfs 9 0 5080 3440 696 S 0,0 3,6 0:13 xfs 1656 nico 9 0 1812 1480 1016 S 0,0 1,5 0:15 wmaker 1739 nico 9 0 1476 1280 1080 S 0,0 1,3 0:00 bash 10440 nico 12 0 1056 1056 844 R 0,7 1,1 0:00 top 1730 nico 9 0 1108 792 628 S 0,0 0,8 0:00 bash 1731 nico 9 0 940 448 424 S 0,0 0,4 0:00 bash 8913 root 8 0 760 428 236 S 0,0 0,4 0:00 bash 1723 nico 9 0 492 412 400 S 0,0 0,4 0:00 aterm 10249 root 8 0 476 412 320 S 0,0 0,4 0:00 pppd 1724 nico 9 0 496 396 372 R 0,1 0,4 0:00 aterm 1725 nico 9 0 468 364 364 S 0,0 0,3 0:00 aterm 1726 nico 9 0 384 288 288 S 0,0 0,3 0:00 aterm 1727 nico 9 0 412 184 184 S 0,0 0,1 0:00 wmCalClock-Wind 878 root 9 0 236 180 180 S 0,0 0,1 0:00 syslogd 886 root 9 0 828 172 172 S 0,0 0,1 0:00 klogd 22 Mb for mozilla, 60 Mb for X (but used 7.5 Mb currently and swap almost 90% of it's size), a few utility use ~1Mb and lot of them use 512 Kb. So around 1 Mb for most of them and many Mb for 2 or 3 applications. Hurd guys advice to have 4 size : tiny for message passing (4 Ko ? what ever the size, a message is message and most of them are small, so it will use a page), medium size for code (64 Kb was the first idea), big size for framebuffer and fat kernel (4-8Mo, 16 Mo) and very big for memory hungry application (data based, a scientific tools,...) (256 Mo !). So 4 sizes ! In the IA-64 arch, intel put 11 sizes ! My current problem is how managing different size of page inside the same CAM. Maybe you could manipulat the bit mask but i don't see how or split the adresse in 2 or 4. Using how many table than size don't seems to be too realistic. Or we can use faster cache. Instead of using full associativity we can use 4 way caches. it's smaller and faster but you add depencies inside the adresse that could be put inside the tlb. hope this help. nicO > " > > "present bits" has been removed because it's only needed by HW TLB after the > discussion. I hope I have maid a good resume, but if someone want to add > something, before I add this to the manual (perhaps we must clarify how to > access it before). > > Cedric > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 7 00:06:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEka-0001C8-00 for ; Wed, 07 Aug 2002 02:32:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:32 +0200 (CEST) Received: (qmail 14950 invoked by uid 0); 6 Aug 2002 22:06:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 6 Aug 2002 22:06:50 -0000 Received: by moria.seul.org (Postfix) id 41B0214680C; Tue, 6 Aug 2002 18:06:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 04CA714680F; Tue, 6 Aug 2002 18:06:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a208.home.uni-hannover.de [130.75.232.208]) by moria.seul.org (Postfix) with ESMTP id 350A814680C for ; Tue, 6 Aug 2002 18:06:46 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02553; Wed, 7 Aug 2002 00:06:44 +0200 Message-ID: <20020807000644.22007@thrai.stud.uni-hannover.de> Date: Wed, 7 Aug 2002 00:06:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] TLB resume References: <200208070229.09431.cedric.bail@free.fr> <3D503133.5874B5BA@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D503133.5874B5BA@ifrance.com>; from nico on Tue, Aug 06, 2002 at 10:27:31PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 06, 2002 at 10:27:31PM +0200, nico wrote: [...] > > - address space identifier (ASI; 8 bits was suggested) > > Could be an output and then we check it with an SR. But if it's an > input, we didn't to flush the tlb during a task switch ! The ASI was supposed to be an input. Together with the virtual address, it forms the lookup `key'. [...] > > - supervisor access rights (RWX, 3 bits) > > i don't really understood the use of this one. > > If a process make a system call. It use a specif call that change the > mode (user-> superuser). Superuser (the kernel) could access to > anything. But the strangest thing is that superuser are the one that > could change the tlb content... If supervisor mode is allowed to always access everything, you have a big security hole. [...] > > - page size (4K << size, 6 bits) > > Page size are critical. How many memories could be acceded without a tlb > miss ? In x86 world, the pages are 4 Kb large. The tlb have between 32 > to 128 entries : 512 Kb adressed. That's few ! > > Intel introduice big sized pages (4 Mb) for framebuffer for example. > Linux use it for the kernel code (so there is no tlb miss inside the > kernel code). > > If the size of the page are bigger you could addresse more memories with > the same number of entries. But i could became hard for the pagging > system to find hole aligned with power of 2 adresse bits. A process > needs at least 3 pages (code, data, stack). > > Here is a top extract : [...] > Hurd guys advice to have 4 size : tiny for message passing (4 Ko ? what > ever the size, a message is message and most of them are small, so it > will use a page), medium size for code (64 Kb was the first idea), big > size for framebuffer and fat kernel (4-8Mo, 16 Mo) and very big for > memory hungry application (data based, a scientific tools,...) (256 Mo > !). > > So 4 sizes ! In the IA-64 arch, intel put 11 sizes ! Bigger address space, bigger pages. That's logical, isn't it? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 7 00:54:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEka-0001C8-01 for ; Wed, 07 Aug 2002 02:32:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:32 +0200 (CEST) Received: (qmail 22796 invoked by uid 0); 6 Aug 2002 22:33:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 6 Aug 2002 22:33:17 -0000 Received: by moria.seul.org (Postfix) id 364F214680F; Tue, 6 Aug 2002 18:33:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 13C36146811; Tue, 6 Aug 2002 18:33:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 8BD6814680F for ; Tue, 6 Aug 2002 18:33:15 -0400 (EDT) Received: from ifrance.com (vlt4-103.n.club-internet.fr [194.158.109.103]) by relay-5v.club-internet.fr (Postfix) with ESMTP id CDE9916AB for ; Wed, 7 Aug 2002 00:33:12 +0200 (CEST) Message-ID: <3D5053A8.B682A966@ifrance.com> Date: Wed, 07 Aug 2002 00:54:32 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB resume References: <200208070229.09431.cedric.bail@free.fr> <3D503133.5874B5BA@ifrance.com> <20020807000644.22007@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Tue, Aug 06, 2002 at 10:27:31PM +0200, nico wrote: > [...] > > > - address space identifier (ASI; 8 bits was suggested) > > > > Could be an output and then we check it with an SR. But if it's an > > input, we didn't to flush the tlb during a task switch ! > > The ASI was supposed to be an input. Together with the virtual > address, it forms the lookup `key'. > Yep ! > [...] > > > - supervisor access rights (RWX, 3 bits) > > > > i don't really understood the use of this one. > > > > If a process make a system call. It use a specif call that change the > > mode (user-> superuser). Superuser (the kernel) could access to > > anything. But the strangest thing is that superuser are the one that > > could change the tlb content... > > If supervisor mode is allowed to always access everything, you have a > big security hole. > Could you explain why ? > [...] > > > - page size (4K << size, 6 bits) > > > > Page size are critical. How many memories could be acceded without a tlb > > miss ? In x86 world, the pages are 4 Kb large. The tlb have between 32 > > to 128 entries : 512 Kb adressed. That's few ! > > > > Intel introduice big sized pages (4 Mb) for framebuffer for example. > > Linux use it for the kernel code (so there is no tlb miss inside the > > kernel code). > > > > If the size of the page are bigger you could addresse more memories with > > the same number of entries. But i could became hard for the pagging > > system to find hole aligned with power of 2 adresse bits. A process > > needs at least 3 pages (code, data, stack). > > > > Here is a top extract : > [...] > > Hurd guys advice to have 4 size : tiny for message passing (4 Ko ? what > > ever the size, a message is message and most of them are small, so it > > will use a page), medium size for code (64 Kb was the first idea), big > > size for framebuffer and fat kernel (4-8Mo, 16 Mo) and very big for > > memory hungry application (data based, a scientific tools,...) (256 Mo > > !). > > > > So 4 sizes ! In the IA-64 arch, intel put 11 sizes ! > > Bigger address space, bigger pages. That's logical, isn't it? > bigger waste, too ! That's the risk. > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 7 00:57:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cEkb-0001C8-00 for ; Wed, 07 Aug 2002 02:32:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 02:32:33 +0200 (CEST) Received: (qmail 18856 invoked by uid 0); 6 Aug 2002 22:57:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 6 Aug 2002 22:57:36 -0000 Received: by moria.seul.org (Postfix) id A504C146811; Tue, 6 Aug 2002 18:57:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71CFE146813; Tue, 6 Aug 2002 18:57:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a208.home.uni-hannover.de [130.75.232.208]) by moria.seul.org (Postfix) with ESMTP id C896F14680F for ; Tue, 6 Aug 2002 18:57:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02765; Wed, 7 Aug 2002 00:57:32 +0200 Message-ID: <20020807005731.13185@thrai.stud.uni-hannover.de> Date: Wed, 7 Aug 2002 00:57:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] TLB resume References: <200208070229.09431.cedric.bail@free.fr> <3D503133.5874B5BA@ifrance.com> <20020807000644.22007@thrai.stud.uni-hannover.de> <3D5053A8.B682A966@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D5053A8.B682A966@ifrance.com>; from nico on Wed, Aug 07, 2002 at 12:54:32AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote: [...] > > If supervisor mode is allowed to always access everything, you have a > > big security hole. > > Could you explain why ? Because when a user process calls the OS kernel, the system call is executed with supervisor access rights. That is, you can take an address that you're not allowed to access and pass it to the kernel, and the kernel *is* allowed to access it. You'll have to add rather expensive memory bounds checks to almost every system call in order to prevent that. Sacrificing three bits per TLB entry is cheaper (and more secure). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 7 09:31:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cOu1-0000FE-01 for ; Wed, 07 Aug 2002 13:22:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 13:22:57 +0200 (CEST) Received: (qmail 9087 invoked by uid 0); 7 Aug 2002 07:31:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 7 Aug 2002 07:31:56 -0000 Received: by moria.seul.org (Postfix) id C580D14681A; Wed, 7 Aug 2002 03:31:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8996A146920; Wed, 7 Aug 2002 03:31:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id E70A914681A for ; Wed, 7 Aug 2002 03:31:49 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208070731.285d; Wed, 7 Aug 2002 07:31:40 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Aug 2002 07:31:40 GMT Message-id: <200208070731.285d@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 07/08/02 Objet: Re: [f-cpu] TLB resume On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote: [...] > > If supervisor mode is allowed to always access everythin= g, you have a > > big security hole. >=20 > Could you explain why ? Because when a user process calls the OS kernel, the system = call is executed with supervisor access rights. That is, you can tak= e an address that you're not allowed to access and pass it to the kernel,= and the kernel *is* allowed to access it. You'll have to add rather = expensive memory bounds checks to almost every system call in order to= prevent that. Sacrificing three bits per TLB entry is cheaper (and more se= cure). --- >>> ??? In an adress space, the process could see what ever = he want. Kernel are just mapped in the same adress in each AS to avoi= d trashing of the caches. (Christophe speak about a "global" that come = >from the x86 world. It say that virual adresse is OK for every AS. It avo= id tlb miss.) In the AS, there is only data relevant to the user, to the l= ibrairy and to the kernel. Kernel page have none of the RWE bit set. To = change the ring (pass from the user mode to the superuser one), you nee= d something as trap, a specific call using vector adress. The adress are= well known and defined as OS call. The exploit of buffer overflow could try to change the conte= nt of a librairy, to run "excve sh" (no need to have an executing st= ack, only the good parameter in the stack and the return adress of a f= unction replace by those of a librairy function) or write you're cod= e inside the librairy code. This could be defait by changing the memory l= ocation of the librairy (random adress at load), it became very hard to= find good adresses.=20 An other trick could be to use an other ring for librairie. = So you enter the librairy as you enter in the kernel, with a kind of trap= . This could only be used for dangerous function. Then you could protect = the librairy space by adding RWE bit for a "librairy ring" or "librairy u= ser", user bit will be 0 for such pages. The last exploit use the mmap fonction. You mmap a file with= RWE right and then execute it (by replace a return adress by the adres= s of the buffer mmaped). Ring doesn't change anything on this, the on= ly way to avoid it, is to disable the possibility to run a function ca= ll using a buffer overflow (as for excve). Our API are very less smart for crackers than those from x86= . Most of the time the return adresse are on the register set. Because= we need for none leaf function to save the return adress, i have propose= d to use a specific return adress stack that could'nt be erased by buff= er overflow. I don't understand why we need 3 superuser bits for that. Th= e process does not know about other AS and kernel page could not be ac= cessed. So ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ Nouveau sur i (france), ne vous faites pas piquer votre nom! R=E9servez d=E8s =E0 pr=E9sent votre nom de domaine pour 1 E= uro* HT/mois (*=E0 partir de)=20 http://www.ifrance.com/_reloc/signdom ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 7 17:30:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cOu3-0000FE-01 for ; Wed, 07 Aug 2002 13:22:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 13:22:59 +0200 (CEST) Received: (qmail 9292 invoked by uid 0); 7 Aug 2002 09:06:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 7 Aug 2002 09:06:11 -0000 Received: by moria.seul.org (Postfix) id 88A8B1467F2; Wed, 7 Aug 2002 05:06:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47DEC146804; Wed, 7 Aug 2002 05:06:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id C99641467F2 for ; Wed, 7 Aug 2002 05:06:07 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-157-14.dial.proxad.net [62.147.157.14]) by postfix3-2.free.fr (Postfix) with ESMTP id ECAFC1830B for ; Wed, 7 Aug 2002 11:06:05 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] SR security Date: Wed, 7 Aug 2002 17:30:41 +0200 X-Mailer: KMail [version 1.4] References: <200208070342.17682.cedric.bail@free.fr> In-Reply-To: <200208070342.17682.cedric.bail@free.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208071730.41980.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > What I think we need to add : > - READ_ONLY, that say if we must trap or not when we access > to read only SR > - WRITE_ONLY, idem but for read/write SR > - ASI, the Identifier of the current task > - IRQ_STACK_BASE and IRQ_STACK_SIZE, for being able to handle > multiple IRQ at the same time > - TRAP_STACK_BASE and TRAP_STACK_SIZE, in case of multiple TRAP > (I think it's not usefull, because the trap handler must do his job > correctly) I forget some of them : - RANDOM, random key for pseudo-random initialisation (depend on the implementation) - USER, currently only the LSB is usefull to say if we are SUPER_USER or not. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 7 11:25:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cOu4-0000FE-00 for ; Wed, 07 Aug 2002 13:23:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 13:23:00 +0200 (CEST) Received: (qmail 20562 invoked by uid 0); 7 Aug 2002 09:25:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 7 Aug 2002 09:25:40 -0000 Received: by moria.seul.org (Postfix) id DB2CC1467F2; Wed, 7 Aug 2002 05:25:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFCEE146804; Wed, 7 Aug 2002 05:25:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3DBF41467F2 for ; Wed, 7 Aug 2002 05:25:37 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208070925.1a8a; Wed, 7 Aug 2002 09:25:26 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] SR security From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Aug 2002 09:25:26 GMT Message-id: <200208070925.1a8a@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: cedric A: f-cpu@seul.org Date: 07/08/02 Objet: Re: [f-cpu] SR security > What I think we need to add : > - READ_ONLY, that say if we must trap or not when we acc= ess > to read only SR > - WRITE_ONLY, idem but for read/write SR > - ASI, the Identifier of the current task > - IRQ_STACK_BASE and IRQ_STACK_SIZE, for being able to h= andle > multiple IRQ at the same time > - TRAP_STACK_BASE and TRAP_STACK_SIZE, in case of multip= le TRAP > (I think it's not usefull, because the trap handler must d= o his job > correctly) I forget some of them : - RANDOM, random key for pseudo-random initialisation (dep= end on the=20 implementation) - USER, currently only the LSB is usefull to say if we are= SUPER_USER or=20 not. >>> A task should not know if it run in superuser mode or no= t. So ? >>>Maybe we should add a free running timer, and "some" time= r alarm that generate interrupt (for complexe schuling policy, very preci= se timing, low power,...). nicO Cedric =20 ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ =20 ____________________________________________________________= __________________ Nouveau sur i (france), ne vous faites pas piquer votre nom! R=E9servez d=E8s =E0 pr=E9sent votre nom de domaine pour 1 E= uro* HT/mois (*=E0 partir de)=20 http://www.ifrance.com/_reloc/signdom ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From emailharvest@email.com Wed Aug 7 16:24:23 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cVbn-0000Fs-01 for ; Wed, 07 Aug 2002 20:32:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 20:32:35 +0200 (CEST) Received: (qmail 32342 invoked by uid 0); 7 Aug 2002 14:24:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 7 Aug 2002 14:24:38 -0000 Received: by moria.seul.org (Postfix) id 6F3AD146817; Wed, 7 Aug 2002 10:24:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 344D214681F; Wed, 7 Aug 2002 10:24:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id A89FC146817 for ; Wed, 7 Aug 2002 10:24:37 -0400 (EDT) Received: from localhost.com (unknown [61.174.203.230]) by bettik.munge.net (Postfix) with SMTP id 38FDF4F7AF for ; Wed, 7 Aug 2002 09:22:45 -0500 (CDT) From: emailharvest@email.com To: f-cpu@seul.org Date: Wed, 7 Aug 2002 22:24:23 +0800 Subject: [f-cpu] ADV: Harvest lots of E-mail addresses quickly ! X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20020807142245.38FDF4F7AF@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Dear f-cpu =2C =3CBODY bgColor=3D#ffccff=3E =3CTABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 width=3D475=3E =3CTBODY=3E =3CTR=3E =3CTD align=3Dmiddle vAlign=3Dtop=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E=3CBR=3E =3CTABLE=3E =3CTBODY=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#b8ecff borderColor=3D#0000ff width=3D=2290%=22=3E=3CFONT color=3D#ff0000 face=3D=22Arial Black=22 size=3D6=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B Want To Harvest A Lot Of Email =3B =3B Addresses In A Very Short Time=3F=3C=2FFONT=3E =3CP=3E=3CB=3E=3CFONT color=3D#0000ff face=3DArial size=3D4=3EEasy Email Searcher=3C=2FFONT=3E=3CFONT color=3D#ff00ff face=3DArial size=3D4=3E =3B is =3B a =3B powerful =3B Email =3B software =3B =3B that =3B harvests general Email lists from mail servers =3B =3B =3C=2FFONT=3E=3CFONT color=3D#0000ff face=3DArial size=3D4=3EEasy Email Searcher =3C=2FFONT=3E=3CFONT color=3D#ff00ff face=3DArial size=3D4=3Ecan get 100=2C000 Email=3C=2FFONT=3E=3C=2FB=3E =3CFONT color=3D#ff00ff face=3DArial size=3D4=3E=3CB=3Eaddresses directly from the Email servers in only one hour! =3B=3C=2FB=3E=3C=2FFONT=3E=3C=2FP=3E =3CUL=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E is a 32 bit Windows Program for e-mail marketing=2E It is intended for easy and convenient search large e-mail address lists from mail servers=2E The program can be operated on Windows 95=2F98=2FME=2F2000 and NT=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E =3C=2FB=3Esupport multi-threads =28up to 512 connections=29=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E has the ability =3B to reconnect to the mail server if the server has disconnected and continue the searching at the point where it has been interrupted=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E has an ergonomic interface that is easy to set up and simple to use=2E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CP=3E=A1=A1=3CB=3E=3CFONT color=3D#0000ff face=3DArial=3EEasy Email Searcher is an email address searcher and bulk e-mail sender=2E It can verify more than 5500 email addresses per minute at only 56Kbps speed=2E It even allows you send email to valid email address while searching=2E You can save the searching progress and load it to resume work at your convenience=2E All you need to do is just input an email address=2C and press the =22Search=22 button=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#0000ff face=3DArial=3E=3CBR=3E=3C=2FFONT=3E=3Cfont face=3D=22Comic Sans MS=22 size=3D=224=22 color=3D=22#FF00FF=22=3EVery Low Price ! ------- =3B Now=2C =3B The full version of Easy Email Searcher only costs =3C=2Ffont=3E=3Cfont face=3D=22Comic Sans MS=22 size=3D=224=22 color=3D=22#0000FF=22=3E$ 39=2E 95=3C=2Ffont=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CI=3EClick The Following Link To Download The Demo =3A=3C=2FI=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2Fnewees=2Ezip=22=3EDownload Site 1=3C=2FA=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2Fnewees=2Ezip=22=3EDownload Site 2=3C=2FA=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3C=2FFONT=3E=3C=2FB=3E=A1=A1=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EIf =3B you can not download this program =2C =3B please copy the following link into your URL =2C and then click =22 Enter=22 on your Computer Keyboard=2E=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT size=3D2=3E=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EHere is the download links=3A=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FP=3E =3CDIV=3E =3CP=3Ehttp=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2Fnewees=2Ezip=3C=2FP=3E =3CP=3Ehttp=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2Fnewees=2Ezip=3C=2FP=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CP=3E=3C=2FP=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#0f95de width=3D=2290%=22=3E=3CFONT color=3D#ffffff face=3D=22Verdana=2C Tahoma=2C Helvetica=2C SansSerif=22 size=3D1=3E=3CB=3EDisclaimer=3A=3C=2FB=3E=3CBR=3EWe are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings=2E We have attained the services of an independent 3rd party to overlook list management and removal services=2E This is not unsolicited email=2E If you do not wish to receive further mailings=2C please click this link =3CA href=3D=22 mailto=3Aremoval=40btamail=2Enet=2Ecn =22 target=3D=5Fblank=3E=3CFONT color=3D#fdd32a=3E=3CB=3Emailto=3Aremoval=40btamail=2Enet=2Ecn =3C=2FB=3E=3C=2FFONT=3E=3C=2FA=3E=2E =3B=3C=2FFONT=3E=3CB=3E=3CFONT class=3Ddisclaimer color=3D#000080 face=3DArial=3E=3CBR=3EThis message is a commercial advertisement=2E It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code=2E We have provided the subject line =22ADV=22 to provide you notification that this is a commercial advertisement for persons over 18yrs old=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E =3CBR=3E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 8 03:51:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cXGs-0001fc-01 for ; Wed, 07 Aug 2002 22:19:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 22:19:06 +0200 (CEST) Received: (qmail 7310 invoked by uid 0); 7 Aug 2002 19:22:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 7 Aug 2002 19:22:59 -0000 Received: by moria.seul.org (Postfix) id 32F0C14680F; Wed, 7 Aug 2002 15:22:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A0D2146813; Wed, 7 Aug 2002 15:22:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id B0D5914680F for ; Wed, 7 Aug 2002 15:22:57 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-185.dial.proxad.net [62.147.156.185]) by postfix1-2.free.fr (Postfix) with ESMTP id 2631AAB73A for ; Wed, 7 Aug 2002 21:22:56 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] SR security Date: Thu, 8 Aug 2002 03:51:09 +0200 X-Mailer: KMail [version 1.4] References: <200208070925.1a8a@th00.opsion.fr> In-Reply-To: <200208070925.1a8a@th00.opsion.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208080351.10159.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > What I think we need to add : > > - READ_ONLY, that say if we must trap or not when we access > > to read only SR > > - WRITE_ONLY, idem but for read/write SR > > - ASI, the Identifier of the current task > > - IRQ_STACK_BASE and IRQ_STACK_SIZE, for being able to handle > > multiple IRQ at the same time > > - TRAP_STACK_BASE and TRAP_STACK_SIZE, in case of multiple TRAP > > (I think it's not usefull, because the trap handler must do his job > > correctly) > I forget some of them : > - RANDOM, random key for pseudo-random initialisation (depend on the > implementation) > - USER, currently only the LSB is usefull to say if we are SUPER_USER > or not. > >>> A task should not know if it run in superuser mode or not. So ? Not a problem, USER is in read/write so if you access it you must have the right... And normally you didn't have it. > >>>Maybe we should add a free running timer, and "some" timer alarm that > generate interrupt (for complexe schuling policy, very precise timing, > low power,...). > nicO We have TIME_SLICE that is used for that, but perhaps a TIME, or CYCLE since start of CPU will be usefull. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Wed Aug 7 21:39:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cXGt-0001fc-01 for ; Wed, 07 Aug 2002 22:19:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 07 Aug 2002 22:19:07 +0200 (CEST) Received: (qmail 15749 invoked by uid 0); 7 Aug 2002 19:39:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 7 Aug 2002 19:39:53 -0000 Received: by moria.seul.org (Postfix) id 9488314680F; Wed, 7 Aug 2002 15:39:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C56B146813; Wed, 7 Aug 2002 15:39:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14202.mail.yahoo.com (web14202.mail.yahoo.com [216.136.172.144]) by moria.seul.org (Postfix) with SMTP id 0D99114680F for ; Wed, 7 Aug 2002 15:39:51 -0400 (EDT) Message-ID: <20020807193950.89027.qmail@web14202.mail.yahoo.com> Received: from [130.89.243.164] by web14202.mail.yahoo.com via HTTP; Wed, 07 Aug 2002 12:39:50 PDT Date: Wed, 7 Aug 2002 12:39:50 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] ADV: Harvest lots of E-mail addresses quickly ! To: f-cpu@seul.org In-Reply-To: <20020807142245.38FDF4F7AF@bettik.munge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just orderd there most expensive product, and used ther own "disclamer" as the adress :-) ----------------------------------- Shipping Address: Disclaimer Mr. We are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings ---- good, so an I :-) USA Kansas 123345664 42353245 stop@spamming.me The software will be licensed to Disclaimer ----------------------------------- jaap. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 7 14:44:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cm0K-0002xJ-00 for ; Thu, 08 Aug 2002 14:03:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 08 Aug 2002 14:03:00 +0200 (CEST) Received: (qmail 18019 invoked by uid 0); 7 Aug 2002 21:42:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 7 Aug 2002 21:42:30 -0000 Received: by moria.seul.org (Postfix) id 7B505146811; Wed, 7 Aug 2002 17:42:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 53F13146815; Wed, 7 Aug 2002 17:42:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a197.home.uni-hannover.de [130.75.232.197]) by moria.seul.org (Postfix) with ESMTP id 8BB4B146811 for ; Wed, 7 Aug 2002 17:42:25 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00632; Wed, 7 Aug 2002 14:44:34 +0200 Message-ID: <20020807144434.37106@thrai.stud.uni-hannover.de> Date: Wed, 7 Aug 2002 14:44:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] TLB resume References: <200208070731.285d@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208070731.285d@th00.opsion.fr>; from Nicolas Boulay on Wed, Aug 07, 2002 at 07:31:40AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 07, 2002 at 07:31:40AM +0000, Nicolas Boulay wrote: > -----Message d'origine----- > De: Michael Riepe > A: f-cpu@seul.org > Date: 07/08/02 > Objet: Re: [f-cpu] TLB resume > > On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote: > [...] > > > If supervisor mode is allowed to always access everything, you have > a > > > big security hole. > > > > Could you explain why ? > > Because when a user process calls the OS kernel, the system call is > executed with supervisor access rights. That is, you can take an address > that you're not allowed to access and pass it to the kernel, and the > kernel *is* allowed to access it. You'll have to add rather expensive > memory bounds checks to almost every system call in order to prevent > that. > Sacrificing three bits per TLB entry is cheaper (and more secure). > --- > >>> ??? In an adress space, the process could see what ever he want. > Kernel are just mapped in the same adress in each AS to avoid trashing > of the caches. (Christophe speak about a "global" that come from the x86 > world. It say that virual adresse is OK for every AS. It avoid tlb > miss.) > > In the AS, there is only data relevant to the user, to the librairy and > to the kernel. Kernel page have none of the RWE bit set. To change the > ring (pass from the user mode to the superuser one), you need something > as trap, a specific call using vector adress. The adress are well known > and defined as OS call. [hacking tricks deleted] You forgot some: User processes may try to modify kernel pages, or let the kernel execute arbitrary data. Note that we're not talking about becoming `root' (which also runs with user privileges) but compromising the kernel. > Our API are very less smart for crackers than those from x86. Most of > the time the return adresse are on the register set. Because we need for > none leaf function to save the return adress, i have proposed to use a > specific return adress stack that could'nt be erased by buffer overflow. > > I don't understand why we need 3 superuser bits for that. The process > does not know about other AS and kernel page could not be accessed. So ? Because user and supervisor mode should have an independent view. Your assumption is wrong. When the kernel executes a system call (on behalf of a process), it will run in the processes AS but with supervisor privileges. If you only make a difference between `user' and `supervisor' pages and allow supervisor mode to access user pages regardless of the permission bits in the TLB, you have a problem. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Thu Aug 8 08:53:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cm0f-0002xJ-01 for ; Thu, 08 Aug 2002 14:03:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 08 Aug 2002 14:03:21 +0200 (CEST) Received: (qmail 16657 invoked by uid 0); 8 Aug 2002 06:54:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 8 Aug 2002 06:54:02 -0000 Received: by moria.seul.org (Postfix) id 631A114693E; Thu, 8 Aug 2002 02:54:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB4B2146940; Thu, 8 Aug 2002 02:53:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by moria.seul.org (Postfix) with ESMTP id 68A8714693E for ; Thu, 8 Aug 2002 02:53:59 -0400 (EDT) Received: from fwd04.sul.t-online.de by mailout09.sul.t-online.com with smtp id 17chBC-0002PH-09; Thu, 08 Aug 2002 08:53:54 +0200 Received: from (0893089296-0001@[62.226.159.196]) by fwd04.sul.t-online.com with smtp id 17chB5-1rRn3gC; Thu, 8 Aug 2002 08:53:47 +0200 From: Thilo.Reichelt@t-online.de (Reichelt) To: f-cpu@seul.org References: <200208070925.1a8a@th00.opsion.fr> <200208080351.10159.cedric.bail@free.fr> Subject: Re: Rep:Re: [f-cpu] SR security X-Mailer: T-Online eMail 2.34 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Thu, 8 Aug 2002 08:53:47 +0200 Message-ID: <17chB5-1rRn3gC@fwd04.sul.t-online.com> X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric schrieb: > We have TIME_SLICE that is used for that, but perhaps a TIME, or CYCLE since > start of CPU will be usefull. > A timer counting cycles from start of CPU is very useful for profiling (how long does that function really take ?) And profiling is neccessary for optimisation, because you want to concentrate efforts on the hot spots. Also precision timekeeping (NTP) needs this cycle counter to interpolate time between timer interrupts. Regards Thilo Reichelt ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 8 09:57:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17cm0g-0002xJ-00 for ; Thu, 08 Aug 2002 14:03:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 08 Aug 2002 14:03:22 +0200 (CEST) Received: (qmail 32539 invoked by uid 0); 8 Aug 2002 07:57:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Aug 2002 07:57:24 -0000 Received: by moria.seul.org (Postfix) id B84AD146809; Thu, 8 Aug 2002 03:57:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 962D3146815; Thu, 8 Aug 2002 03:57:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id EE147146809 for ; Thu, 8 Aug 2002 03:57:21 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208080757.0e92; Thu, 8 Aug 2002 07:57:14 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Aug 2002 07:57:14 GMT Message-id: <200208080757.0e92@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 07/08/02 Objet: Re: Rep:Re: [f-cpu] TLB resume On Wed, Aug 07, 2002 at 07:31:40AM +0000, Nicolas Boulay wro= te: > -----Message d'origine----- > De: Michael Riepe > A: f-cpu@seul.org > Date: 07/08/02 > Objet: Re: [f-cpu] TLB resume >=20 > On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote: > [...] > > > If supervisor mode is allowed to always access everyth= ing, you have > a > > > big security hole. > >=20 > > Could you explain why ? >=20 > Because when a user process calls the OS kernel, the syste= m call is > executed with supervisor access rights. That is, you can t= ake an address > that you're not allowed to access and pass it to the kerne= l, and the > kernel *is* allowed to access it. You'll have to add rathe= r expensive > memory bounds checks to almost every system call in order = to prevent > that. > Sacrificing three bits per TLB entry is cheaper (and more = secure). > --- > >>> ??? In an adress space, the process could see what eve= r he want. > Kernel are just mapped in the same adress in each AS to av= oid trashing > of the caches. (Christophe speak about a "global" that com= e from the x86 > world. It say that virual adresse is OK for every AS. It a= void tlb > miss.) >=20 > In the AS, there is only data relevant to the user, to the= librairy and > to the kernel. Kernel page have none of the RWE bit set. T= o change the > ring (pass from the user mode to the superuser one), you n= eed something > as trap, a specific call using vector adress. The adress a= re well known > and defined as OS call. [hacking tricks deleted] You forgot some: User processes may try to modify kernel pag= es, or let the >>> They can't. They doesn't have write right on the kernel = pages. kernel execute arbitrary data.=20 >>> Impossible ! OS call are made thought somethink like int= errupt and the use of a vector table. Only API could be called that way= . Note that we're not talking about becoming `root' (which also runs with user privileges) but compromisi= ng the kernel. >>> Even with stupid right on x86 you can't compromise the k= ernel code. user process have no right on the kernel pages. > Our API are very less smart for crackers than those from x= 86. Most of > the time the return adresse are on the register set. Becau= se we need for > none leaf function to save the return adress, i have propo= sed to use a > specific return adress stack that could'nt be erased by bu= ffer overflow. >=20 > I don't understand why we need 3 superuser bits for that. = The process > does not know about other AS and kernel page could not be = accessed. So ? Because user and supervisor mode should have an independent = view. >>> You don't convince me. You're protection scheme unallowe= d the kernel to touch to some user page. But kernel have the ability to c= hange the content of the tlb. So it could change it's own adress right= . So ?=20 Your assumption is wrong. When the kernel executes a system = call (on behalf of a process), it will run in the processes AS but wi= th supervisor privileges.=20 >>>Yep ! If you only make a difference between `user' and `supervisor= ' pages and allow supervisor mode to access user pages regardl= ess of the permission bits in the TLB, you have a problem. >>> Nop ! Give me an exemple. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ i (france), c'est aussi une gamme compl=E8te de PC en exclus= ivit=E9 avec DELL=20 http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Aug 8 18:48:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5gf-0000mf-00 for ; Fri, 09 Aug 2002 11:04:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:01 +0200 (CEST) Received: (qmail 32317 invoked by uid 0); 8 Aug 2002 16:38:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 8 Aug 2002 16:38:33 -0000 Received: by moria.seul.org (Postfix) id DC51E1467F9; Thu, 8 Aug 2002 12:38:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A0F3314681F; Thu, 8 Aug 2002 12:38:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 352B01467F9 for ; Thu, 8 Aug 2002 12:38:31 -0400 (EDT) Received: from f-cpu.org (kdl16-23.n.club-internet.fr [213.44.18.23]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 3126F169A for ; Thu, 8 Aug 2002 18:38:29 +0200 (CEST) Message-ID: <3D52A0C8.B9DA0B6D@f-cpu.org> Date: Thu, 08 Aug 2002 18:48:08 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] SR security References: <200208070925.1a8a@th00.opsion.fr> <200208080351.10159.cedric.bail@free.fr> <17chB5-1rRn3gC@fwd04.sul.t-online.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Reichelt wrote: > > cedric schrieb: > > > We have TIME_SLICE that is used for that, but perhaps a TIME, or CYCLE since > > start of CPU will be usefull. > > > A timer counting cycles from start of CPU is very useful for profiling (how long > does that function really take ?) And profiling is neccessary for optimisation, > because you want to concentrate efforts on the hot spots. > Also precision timekeeping (NTP) needs this cycle counter to interpolate time > between timer interrupts. don't worry, i think that at least one counter will be implemented. in "normal" CPUs, several will even be present. > Regards > Thilo Reichelt WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 8 15:19:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5h2-0000mf-00 for ; Fri, 09 Aug 2002 11:04:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:24 +0200 (CEST) Received: (qmail 20990 invoked by uid 0); 8 Aug 2002 21:46:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 8 Aug 2002 21:46:28 -0000 Received: by moria.seul.org (Postfix) id 740CA146817; Thu, 8 Aug 2002 17:46:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 557A8146823; Thu, 8 Aug 2002 17:46:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a050.home.uni-hannover.de [130.75.232.50]) by moria.seul.org (Postfix) with ESMTP id 4FA58146817 for ; Thu, 8 Aug 2002 17:46:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00639; Thu, 8 Aug 2002 15:19:19 +0200 Message-ID: <20020808151919.47331@thrai.stud.uni-hannover.de> Date: Thu, 8 Aug 2002 15:19:19 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] SR security References: <200208070925.1a8a@th00.opsion.fr> <200208080351.10159.cedric.bail@free.fr> <17chB5-1rRn3gC@fwd04.sul.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <17chB5-1rRn3gC@fwd04.sul.t-online.com>; from Reichelt on Thu, Aug 08, 2002 at 08:53:47AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 08, 2002 at 08:53:47AM +0200, Reichelt wrote: > cedric schrieb: > > > We have TIME_SLICE that is used for that, but perhaps a TIME, or CYCLE since > > start of CPU will be usefull. > > > A timer counting cycles from start of CPU is very useful for profiling (how long > does that function really take ?) And profiling is neccessary for optimisation, > because you want to concentrate efforts on the hot spots. Agreed. It would also be nice to have some 64-bit timers that can be set to arbitrary values and support several operating modes: - run always / only in user mode - when the counter overflows: + do / don't issue an interrupt + stop / continue running / automatically load a new timer value -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 8 14:42:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5h2-0000mf-01 for ; Fri, 09 Aug 2002 11:04:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:24 +0200 (CEST) Received: (qmail 12713 invoked by uid 0); 8 Aug 2002 21:46:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 8 Aug 2002 21:46:29 -0000 Received: by moria.seul.org (Postfix) id 2801E14681F; Thu, 8 Aug 2002 17:46:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0BE9B14682F; Thu, 8 Aug 2002 17:46:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a050.home.uni-hannover.de [130.75.232.50]) by moria.seul.org (Postfix) with ESMTP id 8BB2114681F for ; Thu, 8 Aug 2002 17:46:26 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00552; Thu, 8 Aug 2002 14:42:48 +0200 Message-ID: <20020808144248.15845@thrai.stud.uni-hannover.de> Date: Thu, 8 Aug 2002 14:42:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208080757.0e92@th00.opsion.fr>; from Nicolas Boulay on Thu, Aug 08, 2002 at 07:57:14AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 08, 2002 at 07:57:14AM +0000, Nicolas Boulay wrote: [...] > You forgot some: User processes may try to modify kernel pages, or let > the > > >>> They can't. They doesn't have write right on the kernel pages. Consider this system call: read(fd, &kernel_page, page_length); -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 9 00:52:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5h4-0000mf-00 for ; Fri, 09 Aug 2002 11:04:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:26 +0200 (CEST) Received: (qmail 16990 invoked by uid 0); 8 Aug 2002 22:31:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 8 Aug 2002 22:31:06 -0000 Received: by moria.seul.org (Postfix) id E2868146817; Thu, 8 Aug 2002 18:31:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA779146823; Thu, 8 Aug 2002 18:31:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 528A4146817 for ; Thu, 8 Aug 2002 18:31:04 -0400 (EDT) Received: from ifrance.com (vlt6-108.n.club-internet.fr [194.158.119.108]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 23F541687 for ; Fri, 9 Aug 2002 00:31:02 +0200 (CEST) Message-ID: <3D52F631.37390FEB@ifrance.com> Date: Fri, 09 Aug 2002 00:52:33 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Thu, Aug 08, 2002 at 07:57:14AM +0000, Nicolas Boulay wrote: > [...] > > You forgot some: User processes may try to modify kernel pages, or let > > the > > > > >>> They can't. They doesn't have write right on the kernel pages. > > Consider this system call: > > read(fd, &kernel_page, page_length); > Why you're read can't check if the given pages are a real user one ? It's easy under linux 0-2Gb is for process, 2-4 Gb AS is for kernel. How you're 3 bits right for superuser could avoid this ? nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 9 01:03:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5h9-0000mf-00 for ; Fri, 09 Aug 2002 11:04:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:31 +0200 (CEST) Received: (qmail 13978 invoked by uid 0); 8 Aug 2002 23:03:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 8 Aug 2002 23:03:12 -0000 Received: by moria.seul.org (Postfix) id 617BE1467FA; Thu, 8 Aug 2002 19:03:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 349CF14681F; Thu, 8 Aug 2002 19:03:11 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a050.home.uni-hannover.de [130.75.232.50]) by moria.seul.org (Postfix) with ESMTP id 8D2F51467FA for ; Thu, 8 Aug 2002 19:03:09 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01224; Fri, 9 Aug 2002 01:03:08 +0200 Message-ID: <20020809010308.10100@thrai.stud.uni-hannover.de> Date: Fri, 9 Aug 2002 01:03:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D52F631.37390FEB@ifrance.com>; from nico on Fri, Aug 09, 2002 at 12:52:33AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote: [...] > > Consider this system call: > > > > read(fd, &kernel_page, page_length); > > > > Why you're read can't check if the given pages are a real user one ? > It's easy under linux 0-2Gb is for process, 2-4 Gb AS is for kernel. It's not always so easy. You'll have to check the memory mappings of the user process (in software) which may become quite expensive. > How you're 3 bits right for superuser could avoid this ? By turning off supervisor access rights for pages that are mapped in user mode (or maybe set the supervisor privileges to the same value). If the kernel is really going to do something that the user is not permitted to do, it will have to a) temporarily raise its own privileges, or b) establish its own TLB entry with appropriate access rights (but its own ASI). Note that it may be possible to use a single set of access bits - if they are valid for both user and supervisor mode (I'll have to think that over). But `supervisor mode is allowed to access everything' is a BIG mistake. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 9 07:58:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5hG-0000mf-00 for ; Fri, 09 Aug 2002 11:04:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:38 +0200 (CEST) Received: (qmail 19667 invoked by uid 0); 9 Aug 2002 05:49:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Aug 2002 05:49:08 -0000 Received: by moria.seul.org (Postfix) id AED72146823; Fri, 9 Aug 2002 01:49:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 92ECA14682F; Fri, 9 Aug 2002 01:49:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 1FDCB146823 for ; Fri, 9 Aug 2002 01:49:04 -0400 (EDT) Received: from f-cpu.org (kdl16-74.n.club-internet.fr [213.44.18.74]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 090461687 for ; Fri, 9 Aug 2002 07:49:01 +0200 (CEST) Message-ID: <3D535A12.B01E17FA@f-cpu.org> Date: Fri, 09 Aug 2002 07:58:42 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote: > [...] > > > Consider this system call: > > > > > > read(fd, &kernel_page, page_length); > > > > > > > Why you're read can't check if the given pages are a real user one ? > > It's easy under linux 0-2Gb is for process, 2-4 Gb AS is for kernel. > > It's not always so easy. You'll have to check the memory mappings of > the user process (in software) which may become quite expensive. In Bordeaux, there was an idea of adding an instruction that would return the access rights and mapping associated to a pointer. this could help... and since F-CPU uses "split loads/stores" it should not be too difficult. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 9 10:26:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5hJ-0000mf-00 for ; Fri, 09 Aug 2002 11:04:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:41 +0200 (CEST) Received: (qmail 20303 invoked by uid 0); 9 Aug 2002 08:27:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 9 Aug 2002 08:27:02 -0000 Received: by moria.seul.org (Postfix) id ACDAB146828; Fri, 9 Aug 2002 04:27:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 67FC1146833; Fri, 9 Aug 2002 04:27:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6AF00146828 for ; Fri, 9 Aug 2002 04:26:59 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208090826.32f8; Fri, 9 Aug 2002 08:26:50 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Aug 2002 08:26:50 GMT Message-id: <200208090826.32f8@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I would like to have the opinion of Christophe or Cedric but= it seems that they are in vacation. -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 09/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote: [...] > > Consider this system call: > >=20 > > read(fd, &kernel_page, page_length); > >=20 >=20 > Why you're read can't check if the given pages are a real = user one ? > It's easy under linux 0-2Gb is for process, 2-4 Gb AS is f= or kernel. It's not always so easy. You'll have to check the memory map= pings of the user process (in software) which may become quite expens= ive. >>>It's not easy it's a choice of the OS designer. If the sp= lit is so strong it's to ease this kind of test. And in this case, it = cost almost nothing. > How you're 3 bits right for superuser could avoid this ? By turning off supervisor access rights for pages that are m= apped in user mode (or maybe set the supervisor privileges to the same val= ue). If the kernel is really going to do something that the user is not = permitted to do,=20 >>>Usually it the kernel code that decided what could be don= e by the process. Checking it's input must be done. Most of the time = the process could only annoying it-self, there is no real probleme of pr= otection. it will have to a) temporarily raise its own privileges, or = b) establish its own TLB entry with appropriate access rights (= but its own ASI). >>> Kernel does not have it's own ASI. It is in the memory s= pace in every process.=20 Note that it may be possible to use a single set of access b= its - if they are valid for both user and supervisor mode (I'll have = to think that over).=20 >>> there is always the same conceptual probleme : the kerne= l decide the right to put in the tlb. It's one of it's role. Usually kern= el is always trusted. But `supervisor mode is allowed to access everything' is a BIG mistake. >>> Maybe. x86 is a big shit in this topic, but i have never= heard about tricks to compromise the kernel that way. Kernel hacker meet= at lsm does not speak about that (grsecurity patch maintainer (who mainl= y try to simulate a true none executing bit in x86), VM designer of t= he hurd). Maybe you discover a new concept of cracking. But i think it= 's really easy to verify the pointer given by the user process. >>>Because the kernel is trusted, i can't imagine that you c= ould compromise it's security by a call to it's own API. Because = kernel could change the right in the tlb it could access what ever he wan= t. If you want to make things like chmod (that could unallowed to acce= ss a file but a run of chmod could change that), how could the kernel = be run without virtual adress. I think that should be done during t= ask switch (christophe ?). nicO, who need a lot more precise explanation. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ i (france), c'est aussi une gamme compl=E8te de PC en exclus= ivit=E9 avec DELL=20 http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 9 10:30:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17d5hK-0000mf-00 for ; Fri, 09 Aug 2002 11:04:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 Aug 2002 11:04:42 +0200 (CEST) Received: (qmail 15556 invoked by uid 0); 9 Aug 2002 08:31:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Aug 2002 08:31:06 -0000 Received: by moria.seul.org (Postfix) id 26BBC14682F; Fri, 9 Aug 2002 04:31:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 144F3146828; Fri, 9 Aug 2002 04:31:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6682F14691B for ; Fri, 9 Aug 2002 04:31:04 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208090830.355b; Fri, 9 Aug 2002 08:30:53 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Aug 2002 08:30:53 GMT Message-id: <200208090830.355b@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 09/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume hi, Michael Riepe wrote: > On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote: > [...] > > > Consider this system call: > > > > > > read(fd, &kernel_page, page_length); > > > > > > > Why you're read can't check if the given pages are a rea= l user one ? > > It's easy under linux 0-2Gb is for process, 2-4 Gb AS is= for kernel. >=20 > It's not always so easy. You'll have to check the memory m= appings of > the user process (in software) which may become quite expe= nsive. In Bordeaux, there was an idea of adding an instruction that= would return the access rights and mapping associated to a pointer= . this could help... and since F-CPU uses "split loads/stores" it should not be too difficult. >>> You make an access to the memory and if it's trap you do= es not have this right ;p I don't like this too much because a task coul= d see that there are virtualise (it's like seing that an os is not runn= ing with superuser mode). I think that such check must be done inside= the table of the OS. What does this instruction do if the data is not = present in the TLB ? A tlb miss ? nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ i (france), c'est aussi une gamme compl=E8te de PC en exclus= ivit=E9 avec DELL=20 http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 9 15:42:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dLLs-0002wt-00 for ; Sat, 10 Aug 2002 03:47:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 10 Aug 2002 03:47:36 +0200 (CEST) Received: (qmail 11177 invoked by uid 0); 9 Aug 2002 16:15:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Aug 2002 16:15:44 -0000 Received: by moria.seul.org (Postfix) id 4EAF214691D; Fri, 9 Aug 2002 12:15:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0682A14691F; Fri, 9 Aug 2002 12:15:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a229.home.uni-hannover.de [130.75.232.229]) by moria.seul.org (Postfix) with ESMTP id 23BD414691D for ; Fri, 9 Aug 2002 12:15:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00715; Fri, 9 Aug 2002 15:42:14 +0200 Message-ID: <20020809154214.06284@thrai.stud.uni-hannover.de> Date: Fri, 9 Aug 2002 15:42:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208090826.32f8@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208090826.32f8@th00.opsion.fr>; from Nicolas Boulay on Fri, Aug 09, 2002 at 08:26:50AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay wrote: [...] > >>> Kernel does not have it's own ASI. It is in the memory space in > every process. That depends on the OS. > Note that it may be possible to use a single set of access bits - if > they are valid for both user and supervisor mode (I'll have to think > that over). > > >>> there is always the same conceptual probleme : the kernel decide the > right to put in the tlb. It's one of it's role. Usually kernel is always > trusted. And exactly that is the problem. > But `supervisor mode is allowed to access everything' is a > BIG mistake. > > >>> Maybe. x86 is a big shit in this topic, but i have never heard about > tricks to compromise the kernel that way. Kernel hacker meet at lsm does > not speak about that (grsecurity patch maintainer (who mainly try to > simulate a true none executing bit in x86), VM designer of the hurd). > Maybe you discover a new concept of cracking. But i think it's really > easy to verify the pointer given by the user process. Depends on the OS, again. > >>>Because the kernel is trusted, i can't imagine that you could > compromise it's security by a call to it's own API. Because kernel could > change the right in the tlb it could access what ever he want. If you > want to make things like chmod (that could unallowed to access a file > but a run of chmod could change that), how could the kernel be run > without virtual adress. I think that should be done during task switch > (christophe ?). *Because* the kernel ist trusted, it is one of the main targets for attacks. If you manage to hack the kernel, you can do everything (compare root kits and `trojan' kernel modules). Therefore, the kernel needs *more* protection than a (user) process with root privileges, not less. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 9 14:32:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dLLt-0002wt-00 for ; Sat, 10 Aug 2002 03:47:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 10 Aug 2002 03:47:37 +0200 (CEST) Received: (qmail 1862 invoked by uid 0); 9 Aug 2002 16:15:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 9 Aug 2002 16:15:47 -0000 Received: by moria.seul.org (Postfix) id 58E1914691E; Fri, 9 Aug 2002 12:15:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 273A5146923; Fri, 9 Aug 2002 12:15:46 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a229.home.uni-hannover.de [130.75.232.229]) by moria.seul.org (Postfix) with ESMTP id 8BBAD14691E for ; Fri, 9 Aug 2002 12:15:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00544; Fri, 9 Aug 2002 14:32:10 +0200 Message-ID: <20020809143210.16412@thrai.stud.uni-hannover.de> Date: Fri, 9 Aug 2002 14:32:10 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> <3D535A12.B01E17FA@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D535A12.B01E17FA@f-cpu.org>; from Yann Guidon on Fri, Aug 09, 2002 at 07:58:42AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Fri, Aug 09, 2002 at 07:58:42AM +0200, Yann Guidon wrote: [...] > In Bordeaux, there was an idea of adding an instruction that would > return the access rights and mapping associated to a pointer. Uh... Intel-style :( -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Aug 9 18:22:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dLLu-0002wt-00 for ; Sat, 10 Aug 2002 03:47:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 10 Aug 2002 03:47:38 +0200 (CEST) Received: (qmail 2277 invoked by uid 0); 9 Aug 2002 16:25:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 9 Aug 2002 16:25:53 -0000 Received: by moria.seul.org (Postfix) id E336A146828; Fri, 9 Aug 2002 12:25:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B564D146833; Fri, 9 Aug 2002 12:25:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 214D2146828 for ; Fri, 9 Aug 2002 12:25:51 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-194.jetnet.ab.ca [207.34.60.194]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g79GQKOD041874 for ; Fri, 9 Aug 2002 10:26:21 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D53EC44.7090906@jetnet.ab.ca> Date: Fri, 09 Aug 2002 10:22:28 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208090826.32f8@th00.opsion.fr> <20020809154214.06284@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: *>Kernel does not have it's own ASI. It is in the memory space in *>every process. >That depends on the OS. >*Because* the kernel ist trusted, it is one of the main targets for >attacks. If you manage to hack the kernel, you can do everything >(compare root kits and `trojan' kernel modules). Therefore, the kernel >needs *more* protection than a (user) process with root privileges, >not less. > Has anybody checked if the F-CPU is a nice cpu for real-time or micro-kernel OS's like Hurd? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Aug 10 03:53:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dM4i-0003QK-00 for ; Sat, 10 Aug 2002 04:33:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 10 Aug 2002 04:33:56 +0200 (CEST) Received: (qmail 3829 invoked by uid 0); 10 Aug 2002 01:43:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 10 Aug 2002 01:43:27 -0000 Received: by moria.seul.org (Postfix) id 96B7D1467F1; Fri, 9 Aug 2002 21:43:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B5D614682F; Fri, 9 Aug 2002 21:43:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 275181467F1 for ; Fri, 9 Aug 2002 21:43:26 -0400 (EDT) Received: from f-cpu.org (kdl11-1.n.club-internet.fr [213.44.9.1]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 0252416A8 for ; Sat, 10 Aug 2002 03:43:23 +0200 (CEST) Message-ID: <3D547204.CB73FA39@f-cpu.org> Date: Sat, 10 Aug 2002 03:53:08 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> <3D535A12.B01E17FA@f-cpu.org> <20020809143210.16412@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > On Fri, Aug 09, 2002 at 07:58:42AM +0200, Yann Guidon wrote: > [...] > > In Bordeaux, there was an idea of adding an instruction that would > > return the access rights and mapping associated to a pointer. > > Uh... Intel-style :( ?? > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Aug 10 15:44:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dhMU-0001Cr-00 for ; Sun, 11 Aug 2002 03:17:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 11 Aug 2002 03:17:42 +0200 (CEST) Received: (qmail 4133 invoked by uid 0); 10 Aug 2002 22:42:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 10 Aug 2002 22:42:54 -0000 Received: by moria.seul.org (Postfix) id 696AD1467FE; Sat, 10 Aug 2002 18:42:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D6C0146926; Sat, 10 Aug 2002 18:42:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a249.home.uni-hannover.de [130.75.232.249]) by moria.seul.org (Postfix) with ESMTP id A79731467FE for ; Sat, 10 Aug 2002 18:42:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00476; Sat, 10 Aug 2002 15:44:58 +0200 Message-ID: <20020810154458.62240@thrai.stud.uni-hannover.de> Date: Sat, 10 Aug 2002 15:44:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> <3D535A12.B01E17FA@f-cpu.org> <20020809143210.16412@thrai.stud.uni-hannover.de> <3D547204.CB73FA39@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D547204.CB73FA39@f-cpu.org>; from Yann Guidon on Sat, Aug 10, 2002 at 03:53:08AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Aug 10, 2002 at 03:53:08AM +0200, Yann Guidon wrote: > Michael Riepe wrote: > > On Fri, Aug 09, 2002 at 07:58:42AM +0200, Yann Guidon wrote: > > [...] > > > In Bordeaux, there was an idea of adding an instruction that would > > > return the access rights and mapping associated to a pointer. > > > > Uh... Intel-style :( > > ?? The ia32 has a similar instruction, IIRC. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 11 06:29:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dsoc-0000G6-00 for ; Sun, 11 Aug 2002 15:31:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 11 Aug 2002 15:31:30 +0200 (CEST) Received: (qmail 24654 invoked by uid 0); 11 Aug 2002 04:20:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 11 Aug 2002 04:20:05 -0000 Received: by moria.seul.org (Postfix) id 6D96C14691F; Sun, 11 Aug 2002 00:20:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2669F146922; Sun, 11 Aug 2002 00:20:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 93BDE14691F for ; Sun, 11 Aug 2002 00:20:01 -0400 (EDT) Received: from f-cpu.org (kll1-17.n.club-internet.fr [213.44.91.17]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B81ED16A2 for ; Sun, 11 Aug 2002 06:19:58 +0200 (CEST) Message-ID: <3D55E839.71049903@f-cpu.org> Date: Sun, 11 Aug 2002 06:29:45 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> <3D535A12.B01E17FA@f-cpu.org> <20020809143210.16412@thrai.stud.uni-hannover.de> <3D547204.CB73FA39@f-cpu.org> <20020810154458.62240@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Michael Riepe wrote: > > On Sat, Aug 10, 2002 at 03:53:08AM +0200, Yann Guidon wrote: > > Michael Riepe wrote: > > > On Fri, Aug 09, 2002 at 07:58:42AM +0200, Yann Guidon wrote: > > > [...] > > > > In Bordeaux, there was an idea of adding an instruction that would > > > > return the access rights and mapping associated to a pointer. > > > > > > Uh... Intel-style :( > > > > ?? > > The ia32 has a similar instruction, IIRC. so what ? they also do additions, multiplies, register moves... The idea here is that one could read the "hidden flags" associated to a pointer/register. When it comes to the other flags (MSB, Zero etc) they are implicitly available through the conditional instructions. I don't think it's overly complex to do a "pointer test" instruction because load and store are also conditional instructions, though more complex : - is the register marked as a pointer - is it valid - is the associated data present - what access rights are granted (R,W,RW or X) to current process. Here are what these flags indicate : * if the register is not marked as pointer, a load/store/jump will perform some synching cycles (pass the register value through TLB then compare the address with the LSU/Fetcher entries. * if it is not valid, any access (load/store/jump) will trigger a trap. * if the data is present, the load/store/jump instruction will not stall. * if the access right is R -> store and jump will trap (protection error) W -> load and jump will trap RW-> jump will trap X -> load and store will trap Note : in FC0, aliases between the LSU and the fetcher give potentially wrong results -> the presence must be exclusive, or the whole system breaks. but i presume nobody will make self-modifying code, right ? So we can spare 1 bit and encode the allowed rights in 2 bits only. The same remark also applies to the TLB entries. OOOPs, i shouldn't have written that... it'll trigger a lot of mails again and i was quietly programming some useful software :-) > Michael "Tired" Riepe WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Aug 11 19:54:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17dzcr-0005EU-00 for ; Sun, 11 Aug 2002 22:47:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 11 Aug 2002 22:47:49 +0200 (CEST) Received: (qmail 5819 invoked by uid 0); 11 Aug 2002 17:33:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 11 Aug 2002 17:33:10 -0000 Received: by moria.seul.org (Postfix) id 7E167146924; Sun, 11 Aug 2002 13:33:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4C8EE146927; Sun, 11 Aug 2002 13:33:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 91BD7146924 for ; Sun, 11 Aug 2002 13:33:07 -0400 (EDT) Received: from ifrance.com (vlt4-238.n.club-internet.fr [194.158.109.238]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 07EF216A7 for ; Sun, 11 Aug 2002 19:33:05 +0200 (CEST) Message-ID: <3D56A4EB.7BFC0ED2@ifrance.com> Date: Sun, 11 Aug 2002 19:54:51 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208090826.32f8@th00.opsion.fr> <20020809154214.06284@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe a écrit : > > On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay wrote: > [...] > > >>> Kernel does not have it's own ASI. It is in the memory space in > > every process. > > That depends on the OS. > > > Note that it may be possible to use a single set of access bits - if > > they are valid for both user and supervisor mode (I'll have to think > > that over). > > > > >>> there is always the same conceptual probleme : the kernel decide the > > right to put in the tlb. It's one of it's role. Usually kernel is always > > trusted. > > And exactly that is the problem. > > > But `supervisor mode is allowed to access everything' is a > > BIG mistake. > > > > >>> Maybe. x86 is a big shit in this topic, but i have never heard about > > tricks to compromise the kernel that way. Kernel hacker meet at lsm does > > not speak about that (grsecurity patch maintainer (who mainly try to > > simulate a true none executing bit in x86), VM designer of the hurd). > > Maybe you discover a new concept of cracking. But i think it's really > > easy to verify the pointer given by the user process. > > Depends on the OS, again. > The real and only danger is to given a kernel page to a kernel function. I don't understand the problem of using software verification of it. If the kernel is bad written it's is problem ! > > >>>Because the kernel is trusted, i can't imagine that you could > > compromise it's security by a call to it's own API. Because kernel could > > change the right in the tlb it could access what ever he want. If you > > want to make things like chmod (that could unallowed to access a file > > but a run of chmod could change that), how could the kernel be run > > without virtual adress. I think that should be done during task switch > > (christophe ?). > > *Because* the kernel ist trusted, it is one of the main targets for > attacks. If you manage to hack the kernel, you can do everything > (compare root kits and `trojan' kernel modules). What you speak about is the use of kernel modules of linux used to hijack os call to hide a back door or something like. It's possible because this module run in kernel space : that not the case in microkernel os. And this module could only be loaded if you gain the root access. So before puting a kernel code, you must have root access. > Therefore, the kernel > needs *more* protection than a (user) process with root privileges, > not less. Because the kernel (or the tiny part of the microkernel that have all the right : VM and scheduling) must have all the right. It's a conceptal point. How could you restricit the right of a kernel that have all the right : it's like setting rwx specific right for root in a unix file system. For me, it does not make a sense. All the danger you speak about could only be done at the design of the OS. It's a story of right management. F-cpu could provide means for that. But rwx bit for superuser mode... Kernel will avoid to read or write in specific pages and trap in kernel and make a kernel_core_dump ? I really need the opinion of Christophe. Maybe a rwx specific right for defining a new ring for librairy could be used ? nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Aug 11 21:18:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17e3Bk-0007el-00 for ; Mon, 12 Aug 2002 02:36:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 12 Aug 2002 02:36:04 +0200 (CEST) Received: (qmail 16099 invoked by uid 0); 11 Aug 2002 22:06:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 11 Aug 2002 22:06:55 -0000 Received: by moria.seul.org (Postfix) id A8FDC146926; Sun, 11 Aug 2002 18:06:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F9E1146929; Sun, 11 Aug 2002 18:06:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a204.home.uni-hannover.de [130.75.232.204]) by moria.seul.org (Postfix) with ESMTP id AF92D146926 for ; Sun, 11 Aug 2002 18:06:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01278; Sun, 11 Aug 2002 21:18:16 +0200 Message-ID: <20020811211816.46318@thrai.stud.uni-hannover.de> Date: Sun, 11 Aug 2002 21:18:16 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208080757.0e92@th00.opsion.fr> <20020808144248.15845@thrai.stud.uni-hannover.de> <3D52F631.37390FEB@ifrance.com> <20020809010308.10100@thrai.stud.uni-hannover.de> <3D535A12.B01E17FA@f-cpu.org> <20020809143210.16412@thrai.stud.uni-hannover.de> <3D547204.CB73FA39@f-cpu.org> <20020810154458.62240@thrai.stud.uni-hannover.de> <3D55E839.71049903@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D55E839.71049903@f-cpu.org>; from Yann Guidon on Sun, Aug 11, 2002 at 06:29:45AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Aug 11, 2002 at 06:29:45AM +0200, Yann Guidon wrote: [...] > The idea here is that one could read the "hidden flags" > associated to a pointer/register. When it comes to the other > flags (MSB, Zero etc) they are implicitly available through > the conditional instructions. I don't think it's overly complex > to do a "pointer test" instruction because load and store are > also conditional instructions, though more complex : > - is the register marked as a pointer > - is it valid > - is the associated data present > - what access rights are granted (R,W,RW or X) to current process. That could be a security risk if the instruction is not privileged. > Here are what these flags indicate : > > * if the register is not marked as pointer, a load/store/jump > will perform some synching cycles (pass the register value > through TLB then compare the address with the LSU/Fetcher entries. > * if it is not valid, any access (load/store/jump) will trigger > a trap. Does `not valid' mean that the register's value is currently being computed? > * if the data is present, the load/store/jump instruction will > not stall. > * if the access right is > R -> store and jump will trap (protection error) > W -> load and jump will trap > RW-> jump will trap > X -> load and store will trap Executable pages usually are readable, too. They may contain read-only data (string constants), jump tables and so on. > Note : in FC0, aliases between the LSU and the fetcher give > potentially wrong results -> the presence must be exclusive, > or the whole system breaks. but i presume nobody will make > self-modifying code, right ? So we can spare 1 bit and encode > the allowed rights in 2 bits only. The same remark also > applies to the TLB entries. OOOPs, i shouldn't have > written that... it'll trigger a lot of mails again > and i was quietly programming some useful software :-) Dynamic linking usually requires that code pages can be modified at runtime (the PLT is maintained that way). When demand paging is used, it's also common that a page is written to immediately before it is executed. In either case, the LSU and the fetcher will have to cooperate. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 12 09:15:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1gt-0000Fx-01 for ; Wed, 28 Aug 2002 14:12:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:12:55 +0200 (CEST) Received: (qmail 27747 invoked by uid 0); 12 Aug 2002 07:15:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 12 Aug 2002 07:15:40 -0000 Received: by moria.seul.org (Postfix) id F3530146929; Mon, 12 Aug 2002 03:15:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD15014692B; Mon, 12 Aug 2002 03:15:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 4E86D146929 for ; Mon, 12 Aug 2002 03:15:38 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208120715.1a03; Mon, 12 Aug 2002 07:15:26 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Aug 2002 07:15:26 GMT Message-id: <200208120715.1a03@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 12/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume On Sun, Aug 11, 2002 at 06:29:45AM +0200, Yann Guidon wrote: [...] > The idea here is that one could read the "hidden flags" > associated to a pointer/register. When it comes to the oth= er > flags (MSB, Zero etc) they are implicitly available throug= h > the conditional instructions. I don't think it's overly co= mplex > to do a "pointer test" instruction because load and store = are > also conditional instructions, though more complex : > - is the register marked as a pointer > - is it valid > - is the associated data present > - what access rights are granted (R,W,RW or X) to current= process. That could be a security risk if the instruction is not priv= ileged. >>>If a program could verify the protection of his pages, yo= u couldn't virtualise a task any more. > Here are what these flags indicate : >=20 > * if the register is not marked as pointer, a load/store/j= ump > will perform some synching cycles (pass the register value > through TLB then compare the address with the LSU/Fetcher = entries. > * if it is not valid, any access (load/store/jump) will tr= igger > a trap. Does `not valid' mean that the register's value is currently= being computed? > * if the data is present, the load/store/jump instruction = will > not stall. > * if the access right is > R -> store and jump will trap (protection error) > W -> load and jump will trap > RW-> jump will trap > X -> load and store will trap Executable pages usually are readable, too. They may contain= read-only data (string constants), jump tables and so on. >>> So for that kind of pages set the r bits, or put all thi= s stuff in a specific pages (i prefer this solution). R that imply X is t= he killing problem of x86. nicO > Note : in FC0, aliases between the LSU and the fetcher giv= e > potentially wrong results -> the presence must be exclusiv= e, > or the whole system breaks. but i presume nobody will make > self-modifying code, right ? So we can spare 1 bit and enc= ode > the allowed rights in 2 bits only. The same remark also > applies to the TLB entries. OOOPs, i shouldn't have > written that... it'll trigger a lot of mails again > and i was quietly programming some useful software :-) Dynamic linking usually requires that code pages can be modi= fied at runtime (the PLT is maintained that way). When demand pagin= g is used, it's also common that a page is written to immediately befor= e it is executed. In either case, the LSU and the fetcher will have= to cooperate. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 12 09:30:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1gu-0000Fx-00 for ; Wed, 28 Aug 2002 14:12:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:12:56 +0200 (CEST) Received: (qmail 9060 invoked by uid 0); 12 Aug 2002 07:30:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Aug 2002 07:30:59 -0000 Received: by moria.seul.org (Postfix) id A315C146928; Mon, 12 Aug 2002 03:30:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B17914692B; Mon, 12 Aug 2002 03:30:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6642D146928 for ; Mon, 12 Aug 2002 03:30:56 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208120730.2d4b; Mon, 12 Aug 2002 07:30:45 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Aug 2002 07:30:45 GMT Message-id: <200208120730.2d4b@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thats really funny openBSD have currently a bug in it's syst= em call : they didn't verify the boundary of the adresse (like i have = explain it). A local user could gain access root by executing what ever k= ernel code he want. That's exactly our discution.=20 http://marc.theaimsgroup.com/?l=3Dopenbsd-announce&m=3D10291= 0116106798&w=3D2 nicO -----Message d'origine----- De: nico A: f-cpu@seul.org Date: 11/08/02 Objet: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume Michael Riepe a =E9crit : >=20 > On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay w= rote: > [...] > > >>> Kernel does not have it's own ASI. It is in the memo= ry space in > > every process. >=20 > That depends on the OS. >=20 > > Note that it may be possible to use a single set of acce= ss bits - if > > they are valid for both user and supervisor mode (I'll h= ave to think > > that over). > > > > >>> there is always the same conceptual probleme : the k= ernel decide the > > right to put in the tlb. It's one of it's role. Usually = kernel is always > > trusted. >=20 > And exactly that is the problem. >=20 > > But `supervisor mode is allowed to access everything' is= a > > BIG mistake. > > > > >>> Maybe. x86 is a big shit in this topic, but i have n= ever heard about > > tricks to compromise the kernel that way. Kernel hacker = meet at lsm does > > not speak about that (grsecurity patch maintainer (who m= ainly try to > > simulate a true none executing bit in x86), VM designer = of the hurd). > > Maybe you discover a new concept of cracking. But i thin= k it's really > > easy to verify the pointer given by the user process. >=20 > Depends on the OS, again. >=20 The real and only danger is to given a kernel page to a kern= el function. I don't understand the problem of using software verificatio= n of it. If the kernel is bad written it's is problem ! > > >>>Because the kernel is trusted, i can't imagine that y= ou could > > compromise it's security by a call to it's own API. Beca= use kernel could > > change the right in the tlb it could access what ever he= want. If you > > want to make things like chmod (that could unallowed to = access a file > > but a run of chmod could change that), how could the ker= nel be run > > without virtual adress. I think that should be done duri= ng task switch > > (christophe ?). >=20 > *Because* the kernel ist trusted, it is one of the main ta= rgets for > attacks. If you manage to hack the kernel, you can do ever= ything > (compare root kits and `trojan' kernel modules). What you speak about is the use of kernel modules of linux u= sed to hijack os call to hide a back door or something like. It's p= ossible because this module run in kernel space : that not the case = in microkernel os. And this module could only be loaded if you = gain the root access. So before puting a kernel code, you must have r= oot access. > Therefore, the kernel > needs *more* protection than a (user) process with root pr= ivileges, > not less. Because the kernel (or the tiny part of the microkernel that= have all the right : VM and scheduling) must have all the right. It's= a conceptal point. How could you restricit the right of a kernel that ha= ve all the right : it's like setting rwx specific right for root in a u= nix file system. For me, it does not make a sense. All the danger you speak about could only be done at the des= ign of the OS. It's a story of right management. F-cpu could provide me= ans for that. But rwx bit for superuser mode... Kernel will avoid to read or write in specific pages and tra= p in kernel and make a kernel_core_dump ? I really need the opinion of C= hristophe. Maybe a rwx specific right for defining a new ring for libra= iry could be used ? nicO >=20 > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > **********************************************************= *** > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org= / ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 12 18:43:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1h5-0000Fx-00 for ; Wed, 28 Aug 2002 14:13:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:13:07 +0200 (CEST) Received: (qmail 8609 invoked by uid 0); 12 Aug 2002 22:52:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 12 Aug 2002 22:52:46 -0000 Received: by moria.seul.org (Postfix) id 5F4D114680A; Mon, 12 Aug 2002 18:52:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2640414692A; Mon, 12 Aug 2002 18:52:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a252.home.uni-hannover.de [130.75.232.252]) by moria.seul.org (Postfix) with ESMTP id 3A90F14680A for ; Mon, 12 Aug 2002 18:52:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00491; Mon, 12 Aug 2002 18:43:58 +0200 Message-ID: <20020812184358.38429@thrai.stud.uni-hannover.de> Date: Mon, 12 Aug 2002 18:43:58 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208120730.2d4b@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208120730.2d4b@th00.opsion.fr>; from Nicolas Boulay on Mon, Aug 12, 2002 at 07:30:45AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 12, 2002 at 07:30:45AM +0000, Nicolas Boulay wrote: > Thats really funny openBSD have currently a bug in it's system call : > they didn't verify the boundary of the adresse (like i have explain it). > A local user could gain access root by executing what ever kernel code > he want. > > That's exactly our discution. See what I mean? :) > The real and only danger is to given a kernel page to a kernel function. > I don't understand the problem of using software verification of it. If > the kernel is bad written it's is problem ! If the hardware sucks, chances are good that kernel security will also suck. And not only security - you'll have to work around lots of nasty things (like a write protect bit that only works in user mode, as seen on old Intel CPUs). [...] > > *Because* the kernel ist trusted, it is one of the main targets for > > attacks. If you manage to hack the kernel, you can do everything > > (compare root kits and `trojan' kernel modules). > > What you speak about is the use of kernel modules of linux used to > hijack os call to hide a back door or something like. It's possible > because this module run in kernel space : that not the case in > microkernel os. And this module could only be loaded if you gain the > root access. So before puting a kernel code, you must have root access. As the OpenBSD example shows, it also works the other way round. > > Therefore, the kernel > > needs *more* protection than a (user) process with root privileges, > > not less. > > Because the kernel (or the tiny part of the microkernel that have all > the right : VM and scheduling) must have all the right. It's a conceptal > point. How could you restricit the right of a kernel that have all the > right : it's like setting rwx specific right for root in a unix file > system. For me, it does not make a sense. There are rights that a kernel doesn't need (and therefore shouldn't have). For example, there is no reason for the kernel to write to its own code segment, or to directly execute code from a processes pages. > All the danger you speak about could only be done at the design of the > OS. It's a story of right management. F-cpu could provide means for > that. But rwx bit for superuser mode... > > Kernel will avoid to read or write in specific pages and trap in kernel > and make a kernel_core_dump ? I really need the opinion of Christophe. If the access was caused by the kernel itself, it will probably panic and die. Otherwise, the kernel will catch the error and either kill the process that caused it, or return EINVAL or EFAULT or something like that. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Aug 13 01:03:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1h6-0000Fx-00 for ; Wed, 28 Aug 2002 14:13:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:13:08 +0200 (CEST) Received: (qmail 31401 invoked by uid 0); 12 Aug 2002 23:07:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Aug 2002 23:07:24 -0000 Received: by moria.seul.org (Postfix) id D9B78146922; Mon, 12 Aug 2002 19:07:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABBCB14692B; Mon, 12 Aug 2002 19:07:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 3A5B6146922 for ; Mon, 12 Aug 2002 19:07:22 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-195.jetnet.ab.ca [207.34.60.195]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g7CN81hm024777 for ; Mon, 12 Aug 2002 17:08:02 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D583EDC.4020309@jetnet.ab.ca> Date: Mon, 12 Aug 2002 17:03:56 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume References: <200208120730.2d4b@th00.opsion.fr> <20020812184358.38429@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael Riepe wrote: > If the access was caused by the kernel itself, it will probably panic > and die. Otherwise, the kernel will catch the error and either kill the > process that caused it, or return EINVAL or EFAULT or something like that. > Unless you run a STUPID OS. My biggest problem with running windows/me is that system freezes on on shut down and you can't turn the stupid thing off as it re-runs windows again . (Thank GOD I can reach the power cord ) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 14 05:47:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1ha-0000Fx-01 for ; Wed, 28 Aug 2002 14:13:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:13:38 +0200 (CEST) Received: (qmail 1594 invoked by uid 0); 14 Aug 2002 19:42:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 14 Aug 2002 19:42:59 -0000 Received: by moria.seul.org (Postfix) id C0ACC14693F; Wed, 14 Aug 2002 15:42:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A462146942; Wed, 14 Aug 2002 15:42:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id EF86E14693F for ; Wed, 14 Aug 2002 15:42:43 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-155-100.dial.proxad.net [62.147.155.100]) by postfix1-2.free.fr (Postfix) with ESMTP id E3792AB1F2 for ; Wed, 14 Aug 2002 21:42:41 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: Subject: [f-cpu] TLB right Date: Wed, 14 Aug 2002 05:47:01 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208140547.02827.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am back from vacation and I read some thing coming from scary movie. We must use 3 bits for right and that was an absolute requirement from the guy that work on the grsecurity patch. Never remove it, without them we will have some security problem. The use of a special instruction to know if the pointer is a part of the kernel or not, mean that we need to change all the kernel exported function to verify in software if all the pointer are ok or not. So if we port an OS, we need to do a lot of change, and we can forget some of them (like the last local bug in OpenBSD). To conclude, I am for super user security bits and we need 3 "real" bits for security. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 15 17:50:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1hu-0000Fx-00 for ; Wed, 28 Aug 2002 14:13:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:13:58 +0200 (CEST) Received: (qmail 22859 invoked by uid 0); 15 Aug 2002 15:28:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 15 Aug 2002 15:28:03 -0000 Received: by moria.seul.org (Postfix) id EC5A4146949; Thu, 15 Aug 2002 11:28:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A667A14694B; Thu, 15 Aug 2002 11:28:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 32F10146949 for ; Thu, 15 Aug 2002 11:28:01 -0400 (EDT) Received: from ifrance.com (vlt6-5.n.club-internet.fr [194.158.119.5]) by relay-2v.club-internet.fr (Postfix) with ESMTP id A07C416A6 for ; Thu, 15 Aug 2002 17:27:58 +0200 (CEST) Message-ID: <3D5BCDB0.54D70AD0@ifrance.com> Date: Thu, 15 Aug 2002 17:50:08 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB right References: <200208140547.02827.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric a écrit : > > Hi, > > I am back from vacation and I read some thing coming from scary movie. We > must use 3 bits for right and that was an absolute requirement from the guy > that work on the grsecurity patch. Never remove it, without them we will have > some security problem. > The use of a special instruction to know if the pointer is a part of the > kernel or not, mean that we need to change all the kernel exported function > to verify in software if all the pointer are ok or not. That's how things are done today. In 32 bits adresse space, kernel are in 4-2 Go. So you could put the mask 0x7FFFFFFF to every pointer. So if it's a kernel adresse, it will point elsewhere and die or it could verify the last bit of the pointer if it's 1 it kill the process. > So if we port an OS, > we need to do a lot of change, and we can forget some of them (like the last > local bug in OpenBSD). Every kernel call should be check, so what ? nicO > To conclude, I am for super user security bits and we need 3 "real" bits for > security. > > Cedric > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 15 17:58:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1hv-0000Fx-00 for ; Wed, 28 Aug 2002 14:13:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:13:59 +0200 (CEST) Received: (qmail 8888 invoked by uid 0); 15 Aug 2002 15:36:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 15 Aug 2002 15:36:49 -0000 Received: by moria.seul.org (Postfix) id 931A7146949; Thu, 15 Aug 2002 11:36:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CA4814694B; Thu, 15 Aug 2002 11:36:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 19B18146949 for ; Thu, 15 Aug 2002 11:36:48 -0400 (EDT) Received: from ifrance.com (vlt6-5.n.club-internet.fr [194.158.119.5]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 6796C1697 for ; Thu, 15 Aug 2002 17:36:45 +0200 (CEST) Message-ID: <3D5BCFBF.F3C8FAC3@ifrance.com> Date: Thu, 15 Aug 2002 17:58:55 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB right References: <200208140547.02827.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Todays, linux use 1 big page for kernel, so there isn't any page miss inside the kernel code. That's speed up things ! If you use many pages to protect things, you could lose speed. Maybe, this could be used to create modules with superuser privileges. It could be interresting to protect kernel from a bad written driver. Usualy it is done by using user space. But you don't prevent anything if the driver touch the tlb stuff. I beleive it's none sense because superuser code could always change tlb entries. And to avoid sending a kernel space adresse to a user call, you only have to check the pointer MSB bit... nicO cedric a écrit : > > Hi, > > I am back from vacation and I read some thing coming from scary movie. We > must use 3 bits for right and that was an absolute requirement from the guy > that work on the grsecurity patch. Never remove it, without them we will have > some security problem. > The use of a special instruction to know if the pointer is a part of the > kernel or not, mean that we need to change all the kernel exported function > to verify in software if all the pointer are ok or not. So if we port an OS, > we need to do a lot of change, and we can forget some of them (like the last > local bug in OpenBSD). > To conclude, I am for super user security bits and we need 3 "real" bits for > security. > > Cedric > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 27 23:15:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1pG-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:34 +0200 (CEST) Received: (qmail 18007 invoked by uid 0); 27 Aug 2002 21:05:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 27 Aug 2002 21:05:32 -0000 Received: by moria.seul.org (Postfix) id 63F0015E747; Tue, 27 Aug 2002 17:05:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3D4C615E74B; Tue, 27 Aug 2002 17:05:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id E290215E747 for ; Tue, 27 Aug 2002 17:05:30 -0400 (EDT) Received: from f-cpu.org (kdl16-86.n.club-internet.fr [213.44.18.86]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 621B9168D for ; Tue, 27 Aug 2002 23:05:48 +0200 (CEST) Message-ID: <3D6BEC0A.CF57D6D1@f-cpu.org> Date: Tue, 27 Aug 2002 23:15:54 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] ll/sc References: <002201c24dad$b0c11500$a73d0f50@hli> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i don't read much the f-cpu mails these days... but... > Christophe Avoinne wrote: > > Another possibility : > > loopentry r3 > ... > lload r1,[r2] --> r1 = *r2; lock LSU entry > ... > lstore r1,[r2],r3 --> if locked, *r2 = r1, unlock LSU entry. > if not, jump to r3 no <- the jump destination can only be in R2. > we jump instead of setting false a register when > we cannot store because the lock is discarded in the LSU entry. > > The only interest to do so, is to reduce instructions since > we can expect having a conditional jumping after a failed lstore. > > But the counterpart is that you cannot sandwitch some > instructions between lstore and conditional jump or > just want to jump when lstore suceeds. The instruction format problem is much more important and makes this approach impossible. sorry. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sdesseaux@free.fr Tue Aug 27 18:09:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1p5-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:23 +0200 (CEST) Received: (qmail 19585 invoked by uid 0); 27 Aug 2002 16:09:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 27 Aug 2002 16:09:33 -0000 Received: by moria.seul.org (Postfix) id 95C8F15E725; Tue, 27 Aug 2002 12:09:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 62DA915E745; Tue, 27 Aug 2002 12:09:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 6F13F15E725 for ; Tue, 27 Aug 2002 12:09:31 -0400 (EDT) Received: from client1 (lille-2-a7-62-147-5-136.dial.proxad.net [62.147.5.136]) by postfix3-2.free.fr (Postfix) with SMTP id AC72917ECA; Tue, 27 Aug 2002 18:08:52 +0200 (CEST) Message-ID: <001d01c24de4$341af7a0$8805933e@client1> From: "Samuel Desseaux" To: , Cc: References: <3D44F7FD.6040607@yahoo.fr> <3D6B820F.2080109@yahoo.fr> Subject: [f-cpu] Re: [ff] Web and webmaster Synthesis (and end ?) Date: Tue, 27 Aug 2002 18:09:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C24DF4.ECCCD100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C24DF4.ECCCD100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! ok! i will send my ideas as soon as possible. See you later Sam ----- Original Message -----=20 From: Just an Illusion=20 To: f-cpu@seul.org=20 Cc: f-cpu_france@april.org=20 Sent: Tuesday, August 27, 2002 3:43 PM Subject: [ff] Web and webmaster Synthesis (and end ?) The french version can be found at the end of the message=20 Hello everybody, This subject seems not interresting lot of peoples, then I propose to = close it. First, summary of job for the webmaster (or webmistress ;-)): * Site maintenance (like broken links, look & feel, update, and = perhaps cvs management too)=20 * He can delegate some part of job, but he can impose the format = (like html, php, dacode...)=20 * If a web team is created, he must follow the state of the work, = and manage the team.=20 * When a new look and feel, a new section, a major modification on = the site must be made, he must launch the discussion on the f-cpu = mailing list, organize the pools and synthesize result.=20 * He must speak [dixit Michael] (and more write[dixit Just an = Illusion]) in english * The web site musn't move against [dixit Michael], and it must be = seul.org [dixit C=E9dric Bail] Until now, only Samuel Desseaux have been contact me (by private mail) = to confirm me than he was interresting to keep in charge of the web site = (to do every things). He have an idea for the new web structure and only = wait a decision from the list to begin real job. Perhaps he can present his idea himself ? (to you Samuel) If no body have additionnal comments, perhaps it's time to make a pool = to declare Samuel like new webmaster (I don't know if seul.org have an = embedded system to make pool, Whygee ?), or Whygee (like moderator) can = send a global message to declare Samuel like new Webmaster (if no body = want the pool). SeeYa, Just an Illusion **************************=20 Bonjour tout le monde,=20 Au vu du nombre de r=E9action, le sujet ne semble pas passionner les = foules. Je propose donc que nous le cloturions. Premi=E8rement un r=E9sum=E9 des t=E2ches du (ou de la ;-)) webmestre = : * Maintenance du site=20 * En cas de travail en =E9quipe, choix du format des pages, et = r=F4le de manager de l'=E9quipe.=20 * C'est de lui qu'emmaneront les proposition d'=E9volution, les = proposition de nouvelles rubriques, il organisera les votes et les = synth=E8ses.=20 * Il doit parlet [dixit Michael] (et =E9crire biens=FBre [dixit = Just an Illusion]) anglais * L'adresse du site ne doit pas =E0 nouveau changer [dixit = Michael], et se doit =EAtre seul.org [dixit C=E9dric Bail] Jusqu'=E0 maintenant, seul Samuel Desseaux m'a contact=E9 (par = courrier priv=E9) qu'il =E9tait interress=E9 pour prendre en charge tout = le site. Il a d=E9j=E0 une id=E9e pour l'infrastructure, mais attends = une d=E9cission de la liste pour commenc=E9 =E0 r=E9ellement = travaill=E9. Peut-=EAtre peut-il pr=E9sent=E9 lui-m=EAme son id=E9e ? (=E0 toi = d'agir Samuel) Si personne n'a de remarque compl=E9mentaire, il est peut-=EAtre temps = de voter pour confier =E0 Samuel le d=E9veloppement du site (je ne sais = pas si seul.org propose un syst=E8me pour les votes, Whygee ?), ou bien = Whygee (en tant que moderateur) peut envoyer un message g=E9n=E9ral pour = signaler que Samuel sera le nouveau webmestre avec en charge le = developpement du nouveau site (si personne ne veut du vote). To define the job, I give you some possible point :=20 * Site maintenance (like broken links, look & feel, update, and = perhaps cvs management too)=20 * He can delegate some part of job, but he can impose the format = (like html, php, dacode...)=20 * If a web team is created, he must follow the state of the = work, and manage the team.=20 * When a new look and feel, a new section, a major modification = on the site must be made, he must launch the discussion on the f-cpu = mailing list, organize the pools and synthesize result.=20 If you want add something, do it.=20 Until now, Whygee have communicate me the following list of name = (people who have propose their services for the web site developpement) = :=20 -"Cedric De Wilde" who have proposing the daCode = version.=20 -"Pablo Belin" who have made the Who's Who=20 -"Paul Marques Mota" who give help about server = problems=20 -"Samuel Desseaux" who propose a php version of = the site.=20 If this people accept to keep in charge of the site developpement, = I'll propose than they can submit their application.=20 If others people want submit their application too, do it.=20 I propose to close the discussion during the third week of august (I = gooing in holidays at the end of the week, and I have no access to my = account before the 19th august).=20 The future webmaster can be named by a pool, after the canditature = collection.=20 Cheers,=20 Just an Illusion=20 PS : About the web site content, the proposal can be made too.=20 **************************=20 Bonjour tout le monde,=20 Une partie des membres parisiens du f-cpu se sont r=E9unis la = semaine derni=E8re, pour faire un point sur l'avanc=E9 du projet.=20 Il semble que nous avons, nous aurons, un probl=E8me avec le site = web.=20 Actuellement, Whygee s'occupe d'organiser cela, mais il d=E9sire ne = plus avoir =E0 le faire.=20 Parce que certaines personnes ne semble pas avoir envie de = d=E9velopper le code vhdl, ou le soft n=E9cessaire, nous leurs faisons = une proposition, s'ils peuvent d=E9velopper le site.=20 Nous recherchons un nouveau webmestre (pour remplacer whygee)=20 Voici quelques point pour illuster son r=F4le possible :=20 * Maintenance du site=20 * En cas de travail en =E9quipe, choix du format des pages, et = r=F4le de manager de l'=E9quipe.=20 * C'est de lui qu'emmaneront les proposition d'=E9volution, les = proposition de nouvelles rubriques, il organisera les votes et les = synth=E8ses.=20 Si vous avez d'autres propositions, faites le.=20 Voici une liste de personnes que Whygee m'a communiqu=E9 qui ont = propos=E9 leurs services pour le d=E9veloppement du site.=20 - "Cedric De Wilde" qui a fait le proposition du = site en daCode=20 - pablo.belin@free.fr (ABUL) qui a fait un Who's Who.=20 - Paul Marques Mota qui peut parfois aider pour les = histoires de serveurs.=20 - "samuel desseaux" qui propose une version php = du site=20 Si ces personnes veulent prendre en charge le d=E9veloppement, = qu'ils proposent leurs candidatures=20 Si d'autres personnes veulent se proposer, qu'ils le fassent.=20 Je propose de conclure cette discussion la 3e semaine d'ao=FBt (je = pars en vacances en fin de semaine, et je n'aurais pas acc=E9es =E0 mon = compte d'ici le 19)=20 Le nouveau webmestre pourra =EAtre d=E9sign=E9 par un vote, apr=E9s = la collecte des candidatures.=20 @+=20 Just an Illusion=20 PS : Pour le contenu du site, faites aussi des propositions.=20 ------=_NextPart_000_001A_01C24DF4.ECCCD100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
 
ok! i will send my ideas as soon as=20 possible.
 
See you later
 
Sam
----- Original Message -----
From:=20 Just=20 an Illusion
Sent: Tuesday, August 27, 2002 = 3:43=20 PM
Subject: [ff] Web and webmaster = Synthesis=20 (and end ?)

The french version can be found at the end of the = message=20

Hello everybody,

This subject seems not interresting = lot of=20 peoples, then I propose to close it.

First, summary of =  job for=20 the webmaster (or webmistress ;-)):

    * Site=20 maintenance (like broken links, look & feel, update, and perhaps = cvs=20 management too)
    * He can delegate some part of = job, but=20 he can impose the format (like html, php, dacode...) =
    *=20 If a web team is created, he must follow the state of the work, and = manage the=20 team.
    * When a new look and feel, a new = section, a=20 major modification on the site must be made, he must launch the = discussion on=20 the f-cpu mailing list, organize the pools and synthesize result. =
 =20   * He must speak [dixit Michael] (and more write[dixit Just an=20 Illusion]) in english
    * The web site musn't move = against=20 [dixit Michael], and it must be seul.org [dixit C=E9dric = Bail]

Until now,=20 only Samuel Desseaux have been contact me (by private mail) to = confirm=20 me than he was interresting to keep in charge of the web site (to do = every=20 things). He have an idea for the new web structure and only wait a = decision=20 from the list to begin real job.
Perhaps he can present his idea = himself ?=20 (to you Samuel)

If no body have additionnal comments, perhaps = it's time=20 to make a pool to declare Samuel like new webmaster (I don't know if = seul.org=20 have an embedded system to make pool, Whygee ?), or Whygee (like = moderator)=20 can send a global message to declare Samuel like new Webmaster (if no = body=20 want the pool).

SeeYa,
Just an=20 Illusion

**************************

Bonjour tout le = monde,=20

Au vu du nombre de r=E9action, le sujet ne semble pas = passionner les=20 foules. Je propose donc que nous le cloturions.

Premi=E8rement = un r=E9sum=E9=20 des t=E2ches du (ou de la ;-)) webmestre :

   * = Maintenance du=20 site
   * En cas de travail en =E9quipe, choix du format = des=20 pages, et r=F4le de manager de l'=E9quipe.
   * C'est de = lui=20 qu'emmaneront les proposition d'=E9volution, les proposition de = nouvelles=20 rubriques,  il organisera les votes et les synth=E8ses. =
    *=20 Il doit parlet [dixit Michael] (et =E9crire biens=FBre [dixit Just an = Illusion])=20 anglais
    * L'adresse du site ne doit pas =E0 nouveau = changer=20 [dixit Michael], et se doit =EAtre seul.org [dixit C=E9dric = Bail]

Jusqu'=E0=20 maintenant, seul Samuel Desseaux m'a contact=E9 (par courrier = priv=E9)=20 qu'il =E9tait interress=E9 pour prendre en charge tout le site. Il a = d=E9j=E0 une id=E9e=20 pour l'infrastructure, mais attends une d=E9cission de la liste pour = commenc=E9 =E0=20 r=E9ellement travaill=E9.
Peut-=EAtre peut-il pr=E9sent=E9 = lui-m=EAme son id=E9e ? (=E0 toi=20 d'agir Samuel)

Si personne n'a de remarque compl=E9mentaire, il = est=20 peut-=EAtre temps de voter pour confier =E0 Samuel le d=E9veloppement = du site (je ne=20 sais pas si seul.org propose un syst=E8me pour les votes, Whygee ?), = ou bien=20 Whygee (en tant que moderateur) peut envoyer un message g=E9n=E9ral = pour signaler=20 que Samuel sera le nouveau webmestre avec en charge le developpement = du=20 nouveau site (si personne ne veut du vote).



To = define the=20 job, I give you some possible point :
    * Site=20 maintenance (like broken links, look & feel, update, and perhaps = cvs=20 management too)
    * He can delegate some part = of job,=20 but he can impose the format (like html, php, dacode...)=20
    * If a web team is created, he must follow = the state=20 of the work, and manage the team.
    * When a = new look=20 and feel, a new section, a major modification on the site must be = made, he=20 must launch the discussion on the f-cpu mailing list, organize the = pools and=20 synthesize result.

If you want add something, do it. =

Until=20 now, Whygee have communicate me the following list of name (people = who have=20 propose their services for the web site developpement) : =
-"Cedric De=20 Wilde" <daique@skynet.be> who = have=20 proposing the daCode version.
-"Pablo Belin" <pablo.belin@free.fr> = who have=20 made the Who's Who
-"Paul Marques Mota" <mota@april.org> who give = help about=20 server problems
-"Samuel Desseaux"<sdesseaux@free.fr> who = propose a=20 php version of the site.

If this people accept to keep in = charge of=20 the site developpement, I'll propose than they can submit their = application.=20
If others people want submit their application too, do it. =

I=20 propose to close the discussion during the third week of august (I = gooing in=20 holidays at the end of the week, and I have no access to my account = before=20 the 19th august).

The future webmaster can be named by a = pool, after=20 the canditature collection.

Cheers,
Just an Illusion =

PS=20 : About the web site content, the proposal can be made too.=20

**************************

Bonjour tout le monde,=20

Une partie des membres parisiens du f-cpu se sont r=E9unis = la semaine=20 derni=E8re, pour faire un point sur l'avanc=E9 du projet.
Il = semble que nous=20 avons, nous aurons, un probl=E8me avec le site web. =

Actuellement,=20 Whygee s'occupe d'organiser cela, mais il d=E9sire ne plus avoir =E0 = le faire.=20

Parce que certaines personnes ne semble pas avoir envie de=20 d=E9velopper le code vhdl, ou le soft n=E9cessaire, nous leurs = faisons une=20 proposition, s'ils peuvent d=E9velopper le site.

Nous = recherchons un=20 nouveau webmestre (pour remplacer whygee)

Voici quelques = point pour=20 illuster son r=F4le possible :
  * Maintenance du site =
  *=20 En cas de travail en =E9quipe, choix du format des pages, et r=F4le = de manager=20 de l'=E9quipe.
  * C'est de lui qu'emmaneront les = proposition=20 d'=E9volution, les proposition de nouvelles rubriques,  il = organisera les=20 votes et les synth=E8ses.

Si vous avez d'autres = propositions, faites=20 le.

Voici une liste de personnes que Whygee m'a communiqu=E9 = qui ont=20 propos=E9 leurs services pour le d=E9veloppement du site.
- = "Cedric De=20 Wilde" <daique@skynet.be> qui a = fait le=20 proposition du site en daCode
- pablo.belin@free.fr (ABUL) = qui a fait=20 un Who's Who.
- Paul Marques Mota <mota@april.org> qui peut = parfois=20 aider pour les histoires de serveurs.
- "samuel desseaux" <sdesseaux@free.fr> qui = propose=20 une version php du site

Si ces personnes veulent prendre en = charge=20 le d=E9veloppement, qu'ils proposent leurs candidatures
Si = d'autres=20 personnes veulent se proposer, qu'ils le fassent.

Je propose = de=20 conclure cette discussion la 3e semaine d'ao=FBt (je pars en = vacances en fin=20 de semaine, et je n'aurais pas acc=E9es =E0 mon compte d'ici le 19) =

Le=20 nouveau webmestre pourra =EAtre d=E9sign=E9 par un vote, apr=E9s la = collecte des=20 candidatures.

@+
Just an Illusion

PS : Pour le = contenu=20 du site, faites aussi des propositions.=20


------=_NextPart_000_001A_01C24DF4.ECCCD100-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Aug 27 14:33:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1ov-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:13 +0200 (CEST) Received: (qmail 11558 invoked by uid 0); 27 Aug 2002 12:33:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 27 Aug 2002 12:33:37 -0000 Received: by moria.seul.org (Postfix) id 04D1315E725; Tue, 27 Aug 2002 08:33:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D523D15E72F; Tue, 27 Aug 2002 08:33:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 6E16115E725 for ; Tue, 27 Aug 2002 08:33:35 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix3-2.free.fr (Postfix) with ESMTP id 08ED417DEF for ; Tue, 27 Aug 2002 14:33:33 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 8FA4C582C3; Tue, 27 Aug 2002 14:33:33 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return Message-ID: <1030451613.3d6b719d6eee5@imp.free.fr> Date: Tue, 27 Aug 2002 14:33:33 +0200 (MEST) From: Cedric BAIL References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> <1030410212.3d6acfe45bf20@imp.free.fr> <001501c24dac$960f6460$a73d0f50@hli> In-Reply-To: <001501c24dac$960f6460$a73d0f50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.147.68.112 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > load the data ? what data ? the conditional load only to need access > > > to memory if condition is true, so even an exception occurs, when > > > reexecuting the faulty instruction, all is okay. Same thing for the > > > conditional store. > > > So i don't see any problem. > > > > You will not reexecute it. I mean the conditionnal store on wich we > > discuss test if the condition register is zero or not, or if the lsb/msb > > if zero or not and if the test is true, the write is done. If you load > > a data conditionnaly, if the address isn't ok, and the test is false, no > > exeption must occur and it's where the problem is. > 'load' : you mean you always load the value from memory and assign the > value to the data register only if test is succeeded ? well, if so, an > exception will occur before any test anyway. But you still must reexecute. > Page fault exception must point on the faulty instruction and must resume > the faulty instruction since we suppose we've just resolved the fault, so > the program can continue as if there was no fault. It is the behavior you > will find on all CPU for mmu management. Otherwise, you wouldn't be able to > virtualize memory. > But if you only access memory just after the test succeeds, an > exception will occur and still you need to rexecute the instruction. And what append if you point to NULL and the test is false ? You can't reexecute it and never. So what did you do ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Aug 27 11:39:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1or-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:09 +0200 (CEST) Received: (qmail 25575 invoked by uid 0); 27 Aug 2002 09:43:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Aug 2002 09:43:49 -0000 Received: by moria.seul.org (Postfix) id 8179715E742; Tue, 27 Aug 2002 05:43:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7858F15E745; Tue, 27 Aug 2002 05:43:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 28F1E15E742 for ; Tue, 27 Aug 2002 05:43:48 -0400 (EDT) Received: from hli (80.15.61.167) by smtp.laposte.net (6.0.053) id 3D2EB609002DB548 for f-cpu@seul.org; Tue, 27 Aug 2002 11:43:47 +0200 Message-ID: <002201c24dad$b0c11500$a73d0f50@hli> From: "Christophe Avoinne" To: Subject: [f-cpu] ll/sc Date: Tue, 27 Aug 2002 11:39:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C24DBE.73A98650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_001F_01C24DBE.73A98650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another possibility : loopentry r3 ... lload r1,[r2] --> r1 =3D *r2; lock LSU entry ... lstore r1,[r2],r3 --> if locked, *r2 =3D r1, unlock LSU entry. if not, jump to r3 we jump instead of setting false a register when we cannot store because = the lock is discarded in the LSU entry. The only interest to do so, is to reduce instructions since we can = expect having a conditional jumping after a failed lstore. But the counterpart is that you cannot sandwitch some instructions = between lstore and conditional jump or just want to jump when lstore = suceeds. ------=_NextPart_000_001F_01C24DBE.73A98650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another possibility :
 
loopentry r3
...
lload    r1,[r2] --> = r1 =3D=20 *r2; lock LSU entry
...
lstore   r1,[r2],r3 = --> if=20 locked, *r2 =3D r1, unlock LSU entry.
          &nbs= p;            = ;     =20 if not, jump to r3
 
we jump instead of setting false a = register=20 when we cannot store because the lock is discarded in the LSU=20 entry.
 
The only interest to do so, is to = reduce=20 instructions since we can expect having a conditional jumping after a = failed=20 lstore.
 
But the counterpart is that you cannot = sandwitch=20 some instructions between lstore and conditional jump or just want to = jump when=20 lstore suceeds.
 
------=_NextPart_000_001F_01C24DBE.73A98650-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 24 20:15:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nZ-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:49 +0200 (CEST) Received: (qmail 9479 invoked by uid 0); 24 Aug 2002 18:18:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 24 Aug 2002 18:18:52 -0000 Received: by moria.seul.org (Postfix) id 6E0A115E72C; Sat, 24 Aug 2002 14:18:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4730D15E731; Sat, 24 Aug 2002 14:18:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id EA98715E72C for ; Sat, 24 Aug 2002 14:18:50 -0400 (EDT) Received: from hli (80.15.61.85) by smtp.laposte.net (6.0.053) id 3D2EB609002B78CA for f-cpu@seul.org; Sat, 24 Aug 2002 20:18:50 +0200 Message-ID: <002301c24b9a$2aa3cd60$553d0f50@hli> From: "Christophe Avoinne" To: References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> Subject: Re: [f-cpu] Conditionnal load and store, the return Date: Sat, 24 Aug 2002 20:15:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Saturday, August 24, 2002 4:49 PM Subject: Re: [f-cpu] Conditionnal load and store, the return > > > I have reread the discussion about conditionnal load and store, and I > > > think that we forgot something : exception. In fact when we do a load > > > or a store and check the condition only on write. > > > Spoken about the bit in a LSU0 entry telling us if we can write ? if it > > is like a write-right token, setting it to 1 allows the first one to reset > > it and have right to write. If an exception occurs at this place, it means > > that there is no matching LSU0 entry (am I wrong ?), so there is no right > > to write and condition fails. Meanwhile, the exception is executed. At > > exception exit, condition fails so we can reexecute the faulty > > conditional store instruction. > > In fact we were speaking about a possible store[z/nz/m/l/nm/nl] and > load[z/nz/m/l/nm/nl] instructions. And the problem was that currently the > test is checked on wright, that mean you do first load the data and then you > verify if the test is ok. load the data ? what data ? the conditional load only to need access to memory if condition is true, so even an exception occurs, when reexecuting the faulty instruction, all is okay. Same thing for the conditional store. So i don't see any problem. I maybe miss something. The problem is that if you access to a not valid > But in fact we still have a problem with the conditional store/load with > the LSU test in multi processor architecture. > Again, I don't see any problem. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Aug 24 16:49:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nW-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:46 +0200 (CEST) Received: (qmail 22502 invoked by uid 0); 24 Aug 2002 14:49:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 24 Aug 2002 14:49:06 -0000 Received: by moria.seul.org (Postfix) id C1FF015E72A; Sat, 24 Aug 2002 10:49:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4C9A15E72D; Sat, 24 Aug 2002 10:49:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 522DE15E72A for ; Sat, 24 Aug 2002 10:49:05 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix1-2.free.fr (Postfix) with ESMTP id AED68AB32E for ; Sat, 24 Aug 2002 16:49:04 +0200 (CEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id A416913B94; Sat, 24 Aug 2002 16:49:04 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return Message-ID: <1030200544.3d679ce095ead@imp.free.fr> Date: Sat, 24 Aug 2002 16:49:04 +0200 (MEST) From: Cedric BAIL References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> In-Reply-To: <006201c24b74$fa0953c0$553d0f50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.14.101.180 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I have reread the discussion about conditionnal load and store, and I > > think that we forgot something : exception. In fact when we do a load > > or a store and check the condition only on write. > Spoken about the bit in a LSU0 entry telling us if we can write ? if it > is like a write-right token, setting it to 1 allows the first one to reset > it and have right to write. If an exception occurs at this place, it means > that there is no matching LSU0 entry (am I wrong ?), so there is no right > to write and condition fails. Meanwhile, the exception is executed. At > exception exit, condition fails so we can reexecute the faulty > conditional store instruction. In fact we were speaking about a possible store[z/nz/m/l/nm/nl] and load[z/nz/m/l/nm/nl] instructions. And the problem was that currently the test is checked on wright, that mean you do first load the data and then you verify if the test is ok. The problem is that if you access to a not valid address, a exeption must occur before you wait for the answer from the memory system. Or the test is false, so no trap must occur and no request to memory must be send. (with store, we didn't have the problem, because you write only if the test is ok). But in fact we still have a problem with the conditional store/load with the LSU test in multi processor architecture. > > The problem is what append if page > > fault occur ? I think we must clarify that. > > From my point of view I think that we must do the test before starting any > > memory operation, so a trap only occur if the test is true. We must do the > > same if we have a conditionnal prefetch. It's for me the only way to > > correctly execute the 2 branch of a if simultaneously. > > Finally what did we do with the cachemm instruction ? Did we remove or > > change this strange instruction ? For next release of the manual I mark this instruction a deprecated, so if no body cry it will be change or removed. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 24 16:15:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nV-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:45 +0200 (CEST) Received: (qmail 16677 invoked by uid 0); 24 Aug 2002 14:19:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 24 Aug 2002 14:19:30 -0000 Received: by moria.seul.org (Postfix) id 6230415E72B; Sat, 24 Aug 2002 10:19:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B45115E72E; Sat, 24 Aug 2002 10:19:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id BAF1E15E72B for ; Sat, 24 Aug 2002 10:19:28 -0400 (EDT) Received: from hli (80.15.61.85) by smtp.laposte.net (6.0.053) id 3D2EB3A2002F46B4 for f-cpu@seul.org; Sat, 24 Aug 2002 16:19:27 +0200 Message-ID: <003601c24b78$baa59e10$553d0f50@hli> From: "Christophe Avoinne" To: Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume Date: Sat, 24 Aug 2002 16:15:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Intel has some intructions for that but it is for segmentation part not for paging part ! ----- Original Message ----- From: "Yann Guidon" To: Sent: Saturday, August 10, 2002 3:53 AM Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume > hi, > > Michael Riepe wrote: > > On Fri, Aug 09, 2002 at 07:58:42AM +0200, Yann Guidon wrote: > > [...] > > > In Bordeaux, there was an idea of adding an instruction that would > > > return the access rights and mapping associated to a pointer. > > > > Uh... Intel-style :( > > ?? > > > Michael "Tired" Riepe > WHYGEE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 24 16:13:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nU-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:44 +0200 (CEST) Received: (qmail 10542 invoked by uid 0); 24 Aug 2002 14:17:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 24 Aug 2002 14:17:23 -0000 Received: by moria.seul.org (Postfix) id 8333115E72A; Sat, 24 Aug 2002 10:17:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5716E15E72D; Sat, 24 Aug 2002 10:17:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id B4E2E15E72A for ; Sat, 24 Aug 2002 10:17:20 -0400 (EDT) Received: from hli (80.15.61.85) by smtp.laposte.net (6.0.053) id 3D32A1F90025FA97 for f-cpu@seul.org; Sat, 24 Aug 2002 16:17:20 +0200 Message-ID: <002801c24b78$6e6d97f0$553d0f50@hli> From: "Christophe Avoinne" To: References: <200208090826.32f8@th00.opsion.fr> Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume Date: Sat, 24 Aug 2002 16:13:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well for other reason, I'm not against those three bits sr,sw,sx since it can help even for the kernel to separate data and code pages. An example for "pipe" : For different AS, we can even a write-only page for one process and the same page as read-only for the other process for a memory pipe (indeed we need for one process at least two pages, one as read-only and the other as write-only, while the other process have the same pages but with inversed rights). ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Friday, August 09, 2002 10:26 AM Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume I would like to have the opinion of Christophe or Cedric but it seems that they are in vacation. -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 09/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB resume On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote: [...] > > Consider this system call: > > > > read(fd, &kernel_page, page_length); > > > > Why you're read can't check if the given pages are a real user one ? > It's easy under linux 0-2Gb is for process, 2-4 Gb AS is for kernel. It's not always so easy. You'll have to check the memory mappings of the user process (in software) which may become quite expensive. >>>It's not easy it's a choice of the OS designer. If the split is so strong it's to ease this kind of test. And in this case, it cost almost nothing. > How you're 3 bits right for superuser could avoid this ? By turning off supervisor access rights for pages that are mapped in user mode (or maybe set the supervisor privileges to the same value). If the kernel is really going to do something that the user is not permitted to do, >>>Usually it the kernel code that decided what could be done by the process. Checking it's input must be done. Most of the time the process could only annoying it-self, there is no real probleme of protection. it will have to a) temporarily raise its own privileges, or b) establish its own TLB entry with appropriate access rights (but its own ASI). >>> Kernel does not have it's own ASI. It is in the memory space in every process. Note that it may be possible to use a single set of access bits - if they are valid for both user and supervisor mode (I'll have to think that over). >>> there is always the same conceptual probleme : the kernel decide the right to put in the tlb. It's one of it's role. Usually kernel is always trusted. But `supervisor mode is allowed to access everything' is a BIG mistake. >>> Maybe. x86 is a big shit in this topic, but i have never heard about tricks to compromise the kernel that way. Kernel hacker meet at lsm does not speak about that (grsecurity patch maintainer (who mainly try to simulate a true none executing bit in x86), VM designer of the hurd). Maybe you discover a new concept of cracking. But i think it's really easy to verify the pointer given by the user process. >>>Because the kernel is trusted, i can't imagine that you could compromise it's security by a call to it's own API. Because kernel could change the right in the tlb it could access what ever he want. If you want to make things like chmod (that could unallowed to access a file but a run of chmod could change that), how could the kernel be run without virtual adress. I think that should be done during task switch (christophe ?). nicO, who need a lot more precise explanation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ i (france), c'est aussi une gamme complète de PC en exclusivité avec DELL http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Aug 23 00:18:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lc-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:48 +0200 (CEST) Received: (qmail 29490 invoked by uid 0); 22 Aug 2002 22:18:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 22 Aug 2002 22:18:25 -0000 Received: by moria.seul.org (Postfix) id 7D2F915E43E; Thu, 22 Aug 2002 18:18:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 484B415E6F7; Thu, 22 Aug 2002 18:18:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a045.home.uni-hannover.de [130.75.232.45]) by moria.seul.org (Postfix) with ESMTP id 568C115E43E for ; Thu, 22 Aug 2002 18:18:22 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02568; Fri, 23 Aug 2002 00:18:20 +0200 Message-ID: <20020823001820.02472@thrai.stud.uni-hannover.de> Date: Fri, 23 Aug 2002 00:18:20 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Too much option References: <1030047006.3d65451edaeeb@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1030047006.3d65451edaeeb@imp.free.fr>; from Cedric BAIL on Thu, Aug 22, 2002 at 10:10:06PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 22, 2002 at 10:10:06PM +0200, Cedric BAIL wrote: > Hi, > > I am currently working on a new release of the manual with the new color > code for ISA and an OP_CODE map. I discover that we have 2048 possibles > versions of the F-CPU, because we have a lot of optionals instructions. > All the immediate form are optional, mix/expand/sdup are optional too. For me > they must be include in all F-CPU compatible chip and we must reduce the number > of possible version of F-CPU chip. I agree that LNS and FPU must be optional, > but for increment based operation I think it's really too much usefull to be > optional. > What did you think about this problem ? I guess mix/expand/sdup and the increment based ops can be made mandatory. > I update shift instructions too and I discover that they have 2 unused bits. > Why not using them to say : > 00 => double shift right > 01 => shift right > 10 => shift left > 11 => double shift left > > The problem will be with immediate, in that case we can use 2 operandes one for > normal shift the other for dshift. (rot instructions have 2 unused bits too, so > we can use them in the same way). It can save a lot of OP_CODE. (I quickly > count them, and we have approximatively 100 different OP_CODE). It may also work if their immediate counterparts use 6-bit constants (instead of 8-bit ones). > For the next release I want to insert widen instructions, but I read in a > precedent mail that michael didn't like the way he describe it or something > like that. Is it possible to have a little description on them ? That's still undecided. It will probably become something like widen[s].[bdq] r2, r1 with semantics equivalent to the C cast operations r1 = (signed/unsigned char)r2 // 8 bit (.b) r1 = (signed/unsigned short)r2 // 16 bit (.d) r1 = (signed/unsigned int)r2 // 32 bit (.q) where the destination size is always 64 bits. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 22 22:14:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lZ-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:45 +0200 (CEST) Received: (qmail 18535 invoked by uid 0); 22 Aug 2002 20:14:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 22 Aug 2002 20:14:37 -0000 Received: by moria.seul.org (Postfix) id 84CFC15E43E; Thu, 22 Aug 2002 16:14:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 705CA15E6F7; Thu, 22 Aug 2002 16:14:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 2BF1615E43E for ; Thu, 22 Aug 2002 16:14:36 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 67E2217E42 for ; Thu, 22 Aug 2002 22:14:35 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 477E86410F; Thu, 22 Aug 2002 22:14:35 +0200 (MEST) To: f-cpu@seul.org Subject: RE: Rep:Re: Rep:Re: [f-cpu] TLB right + resume Message-ID: <1030047275.3d65462b38a2b@imp.free.fr> Date: Thu, 22 Aug 2002 22:14:35 +0200 (MEST) From: Cedric BAIL References: <37D1208A1C9BD511855B00D0B772242C0118ADD1@corpmail1.sc.sonicblue.com> In-Reply-To: <37D1208A1C9BD511855B00D0B772242C0118ADD1@corpmail1.sc.sonicblue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.15.34.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > >>> What you think about the idea of tagged page that could > > > only be used by tagged read&write instructions (to protect data page of > > > the kernel and return stack write) ? > > I'm afraid that will help only if you compile all your > > binaries yourself (otherwise, they might contain "trojan writes"). > Surely it would be a simple matter in software to search through > executables looking for the op-codes of illegal instructions before > execution? In that case you will loose less time by enabling a trap handler on this particular instructions and waiting to trap, than to always scan the binary. But currently in the F-CPU only one instruction need this : PUT, and perhaps GET. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Aug 22 09:56:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lT-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:39 +0200 (CEST) Received: (qmail 19921 invoked by uid 0); 22 Aug 2002 07:56:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 22 Aug 2002 07:56:50 -0000 Received: by moria.seul.org (Postfix) id 89E3814640E; Thu, 22 Aug 2002 03:56:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 670BA1467F1; Thu, 22 Aug 2002 03:56:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id D072514640E for ; Thu, 22 Aug 2002 03:56:47 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208220756.272d; Thu, 22 Aug 2002 07:56:39 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Aug 2002 07:56:39 GMT Message-id: <200208220756.272d@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 21/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume On Wed, Aug 21, 2002 at 02:58:35AM -0700, John Graley wrote: [...] > Surely it would be a simple matter in software to search t= hrough executables > looking for the op-codes of illegal instructions before ex= ecution? That's not simple at all. Especially if these instructions a= re allowed in certain places (stack write) but not in any others. >>> The "real" answer is that we never mind that a user of t= he system could forge a program to breack it's own program. What inter= rest to try to catch right that the user already have ? (the main goal o= f an attack is to obtain a shell with the user root) >>> And for the kernel, it's even simple : no user could exe= cute code in superuse mode, so it's over. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 21 13:01:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lA-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:20 +0200 (CEST) Received: (qmail 17410 invoked by uid 0); 21 Aug 2002 11:01:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Aug 2002 11:01:25 -0000 Received: by moria.seul.org (Postfix) id 662361467E8; Wed, 21 Aug 2002 07:01:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4784514680C; Wed, 21 Aug 2002 07:01:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id A93681467E8 for ; Wed, 21 Aug 2002 07:01:22 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208211101.0e32; Wed, 21 Aug 2002 11:01:14 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:RE: Rep:Re: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Aug 2002 11:01:14 GMT Message-id: <200208211101.0e32@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: John Graley A: "'f-cpu@seul.org'" Date: 21/08/02 Objet: RE: Rep:Re: Rep:Re: [f-cpu] TLB right + resume > -----Original Message----- > From: Michael Riepe [mailto:michael@stud.uni-hannover.de] > Sent: 20 August 2002 13:40 > To: f-cpu@seul.org > Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume >=20 >=20 > On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay w= rote: > [...] > > > 3- execute librairy call to execute excve with /bin/sh= to=20 > have a shell > > > access. > >=20 > > That's a SW problem. > >=20 > > >>> A compiler problem, so an abi problem. The last=20 > security problem in > > case of buffer overflow. > >=20 > > > 4- diseable any possiblity of buffer overflow. > >=20 > > Dto. > >=20 > > >>> ??? don't understand that word. >=20 > Sorry... it was supposed to mean "same as above". >=20 > > > 5- Protect part of the kernel (driver) from it-self > >=20 > > That's what you need fine-grained access rights for. > >=20 > > >>> Do you think it's wise to protect the kernel from it= -self ?=20 >=20 > It's a side-effect when you protect the kernel from user c= ode. >=20 > > >>> What you think about the idea of tagged page that co= uld=20 > only be used > > by tagged read&write instructions (to protect data page = of=20 > the kernel > > and return stack write) ? >=20 > I'm afraid that will help only if you compile all your=20 > binaries yourself > (otherwise, they might contain "trojan writes"). Surely it would be a simple matter in software to search thr= ough executables looking for the op-codes of illegal instructions before exec= ution? >>>This instruction are normaly used by the compiler to mana= ge the return adress stack, so the presence of this instruction are= normal. We want to avoid the change of the normal process run, like wri= ting beside an array to scratch the return adress. nicO Cheers, John =20 ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From JGraley@sonicblue.com Wed Aug 21 11:58:35 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1l9-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:19 +0200 (CEST) Received: (qmail 15664 invoked by uid 0); 21 Aug 2002 09:52:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 21 Aug 2002 09:52:49 -0000 Received: by moria.seul.org (Postfix) id DF0DD14640E; Wed, 21 Aug 2002 05:52:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C1E271467F1; Wed, 21 Aug 2002 05:52:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail-gw.sonicblue.com (mail-gw.sonicblue.com [209.10.223.218]) by moria.seul.org (Postfix) with ESMTP id 17F7214640E for ; Wed, 21 Aug 2002 05:52:47 -0400 (EDT) Received: from relay.sonicblue.com (timbale [10.6.1.10]) by mail-gw.sonicblue.com (8.11.6/8.11.6) with ESMTP id g7L9qkG05060 for ; Wed, 21 Aug 2002 03:52:46 -0600 (MDT) Received: from corpvirus1.sc.sonicblue.com (corpvirus1.sonicblue.com [10.6.2.49]) by relay.sonicblue.com (8.11.5/8.11.5) with SMTP id g7L9qkU22685 for ; Wed, 21 Aug 2002 02:52:46 -0700 (PDT) Received: FROM corpmailmx.sonicblue.com BY corpvirus1.sc.sonicblue.com ; Wed Aug 21 03:03:09 2002 -0700 Received: by CORPMAILMX with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 02:54:02 -0700 Message-ID: <37D1208A1C9BD511855B00D0B772242C0118ADD1@corpmail1.sc.sonicblue.com> From: John Graley To: "'f-cpu@seul.org'" Subject: RE: Rep:Re: Rep:Re: [f-cpu] TLB right + resume Date: Wed, 21 Aug 2002 02:58:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > -----Original Message----- > From: Michael Riepe [mailto:michael@stud.uni-hannover.de] > Sent: 20 August 2002 13:40 > To: f-cpu@seul.org > Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume > > > On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wrote: > [...] > > > 3- execute librairy call to execute excve with /bin/sh to > have a shell > > > access. > > > > That's a SW problem. > > > > >>> A compiler problem, so an abi problem. The last > security problem in > > case of buffer overflow. > > > > > 4- diseable any possiblity of buffer overflow. > > > > Dto. > > > > >>> ??? don't understand that word. > > Sorry... it was supposed to mean "same as above". > > > > 5- Protect part of the kernel (driver) from it-self > > > > That's what you need fine-grained access rights for. > > > > >>> Do you think it's wise to protect the kernel from it-self ? > > It's a side-effect when you protect the kernel from user code. > > > >>> What you think about the idea of tagged page that could > only be used > > by tagged read&write instructions (to protect data page of > the kernel > > and return stack write) ? > > I'm afraid that will help only if you compile all your > binaries yourself > (otherwise, they might contain "trojan writes"). Surely it would be a simple matter in software to search through executables looking for the op-codes of illegal instructions before execution? Cheers, John ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 21 10:09:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1l5-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:15 +0200 (CEST) Received: (qmail 28735 invoked by uid 0); 21 Aug 2002 08:09:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 21 Aug 2002 08:09:34 -0000 Received: by moria.seul.org (Postfix) id D51181469FE; Wed, 21 Aug 2002 04:09:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0677146A01; Wed, 21 Aug 2002 04:09:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id EFC551469FE for ; Wed, 21 Aug 2002 04:09:31 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208210809.1561; Wed, 21 Aug 2002 08:09:21 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Aug 2002 08:09:21 GMT Message-id: <200208210809.1561@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 21/08/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wro= te: [...] > > 3- execute librairy call to execute excve with /bin/sh t= o have a shell > > access. >=20 > That's a SW problem. >=20 > >>> A compiler problem, so an abi problem. The last securi= ty problem in > case of buffer overflow. >=20 > > 4- diseable any possiblity of buffer overflow. >=20 > Dto. >=20 > >>> ??? don't understand that word. Sorry... it was supposed to mean "same as above". >>> This is the problem number one of the computer security,= if it became impossible to do it, you see what reputation could ha= ve the f-cpu... > > 5- Protect part of the kernel (driver) from it-self >=20 > That's what you need fine-grained access rights for. >=20 > >>> Do you think it's wise to protect the kernel from it-s= elf ?=20 It's a side-effect when you protect the kernel from user cod= e. >>>> That's kernel code, call by user code. Not simple user = code ! It's kernel code with pointer given by user that could cause prob= lem. This problem are soon easly handle by cheecking the adress. This = problem are really not common compare to buffer overflow one but you pre= fer to add many hardware to avoid to do the job in software...=20 >>> Buffer overflow are really hard to catch. In this case, = you juste have to check the bound of the pointer, that's a realy easy = and quick task ! >>> I don't understand why you prefer adding 3 more right bi= ts just to replace a mask and a test in software. Chekcking parameter i= s a normal thing when you call a librairy or a system call. Buffer over= flow are more than 30 % of the overall security bug's in C. What abou= t such kernel protection ? I have been at HAL conference, read some= newspaper abuot security, i have never read anything about problem wit= h kernel pointer. >>> The only kernel problem, i knows, is the module system o= f linux. If you have root access, you could load a module that catch eve= ry system call and you can hide what ever thing you want (back door, t= rojan,...).=20 =20 >>> One of the advantage, i see for such system, is kernel d= ebugging, and building a kind of microkernel architecture in monokerne= l OS. But such protection are usual done by puting the code in user la= nd.=20 >>>If linus don't want to do that, it's for speed. TLB trap = could be a really on overkill for performance. I have read that zero co= py HTML server maid by IBM (challenger of Tux) is quicker under Linu= x than under Windows because of the use of a single big memory page for t= he kernel. It's avoid hundred of tlb miss. >>> For example, in Hurd/L4 only L4 is in superuser mode. It= 's only fex hundred of asm line. It even delegate the security of the sy= stem to an other kernel. So Why having right for such tiny piece of cod= e ? > >>> What you think about the idea of tagged page that coul= d only be used > by tagged read&write instructions (to protect data page of= the kernel > and return stack write) ? I'm afraid that will help only if you compile all your binar= ies yourself (otherwise, they might contain "trojan writes"). >>> ;p Nop ! Buffer overflow are used to gain privileges tha= t you don't have. So you try to crack root processes, you never mind to = crack you're own process, because you will only receive the right that yo= u already have. Furthermore, user didn't compile code for the kernel o= r execute there code in superuser mode. nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 20 11:05:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1kI-0000Fx-00 for ; Wed, 28 Aug 2002 14:16:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:26 +0200 (CEST) Received: (qmail 10520 invoked by uid 0); 20 Aug 2002 09:05:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 20 Aug 2002 09:05:18 -0000 Received: by moria.seul.org (Postfix) id 8906B1469BA; Tue, 20 Aug 2002 05:05:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 55A981469D0; Tue, 20 Aug 2002 05:05:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id C1D161469BA for ; Tue, 20 Aug 2002 05:05:16 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208200905.08b6; Tue, 20 Aug 2002 09:05:08 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Aug 2002 09:05:08 GMT Message-id: <200208200905.08b6@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 20/08/02 Objet: Re: Rep:Re: [f-cpu] TLB right + resume On Mon, Aug 19, 2002 at 09:11:59AM +0000, Nicolas Boulay wro= te: [...] > >>> You can't prevent the mistake of all the future use of= the F-cpu ! > Beleiving that the hardware will do all the job for you is= a dream of > progammer, but not a reality ! HW+SW are design to realise= a task, the > faster, the cheeper, the more flexible way they can. The R= ICS adventure > said to use more the SW and speed up dumb thing in the HW = and do the > clever thing in SW.=20 Since we're building a processor for general use, we must pr= ovide a reasonable amount of functionality. Paging and fine-grained = page level protection *is* reasonable, IMHO. [...] > >>> I try to resume what we want to avoid : > 1- give kernel page to kernel function call to access kern= el page from > user process. > 2- execute user code in kernel mode=20 > 3- execute librairy call to execute excve with /bin/sh to = have a shell > access. That's a SW problem. >>> A compiler problem, so an abi problem. The last security= problem in case of buffer overflow. > 4- diseable any possiblity of buffer overflow. Dto. >>> ??? don't understand that word. > 5- Protect part of the kernel (driver) from it-self That's what you need fine-grained access rights for. >>> Do you think it's wise to protect the kernel from it-sel= f ?=20 >>> What you think about the idea of tagged page that could = only be used by tagged read&write instructions (to protect data page of t= he kernel and return stack write) ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 20 03:13:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1k5-0000Fx-00 for ; Wed, 28 Aug 2002 14:16:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:13 +0200 (CEST) Received: (qmail 30835 invoked by uid 0); 20 Aug 2002 01:03:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 20 Aug 2002 01:03:26 -0000 Received: by moria.seul.org (Postfix) id 76555146801; Mon, 19 Aug 2002 21:03:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 489F4146804; Mon, 19 Aug 2002 21:03:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 07A7E146801 for ; Mon, 19 Aug 2002 21:03:24 -0400 (EDT) Received: from f-cpu.org (kll1-1.n.club-internet.fr [213.44.91.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D24D616A2 for ; Tue, 20 Aug 2002 03:03:16 +0200 (CEST) Message-ID: <3D6197AF.594EBCE7@f-cpu.org> Date: Tue, 20 Aug 2002 03:13:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register use References: <3D617A2A.8060502@laposte.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Thomas Lavergne wrote: > > Some times ago, someone have pointed out that we can't use all register > as pointer or data, but only 8 of us. But I've searched all the manual, > I can't find anything about that (except a section that say that f-cpu > have general register so no reg dedicated for pointer) > Could someone explain what is exactly this limitation and the reason of > this chioce ? Here are some explanations. This is valid for FC0, F-CPU as a "ISA" is not directly impacted. FC0 accesses memory through "split load" and "split stores". The load and store instructions, when used with post-increment mode, perform one half of the preceding load, and the first half of the next. For example, you want to code a <= [b]; [c] <= a; You do a prefetch to b, and store the pointer in R1 for example. Then load : load (c-b),[R1],R2 which will increment R1 with the difference between the two pointers, after having moved the location pointed to by R1 into R2. For the next instruction it's the same principle : store [R1],R2 FC0 maintains a number of flags associated to the registers, particularly whether the register is a valid pointer or not (and thus, whether a load or store using this register as a pointer will trap or not). One of the versions of FC0 can maintain at most 8 registers as data pointers and 8 for instruction pointing (jump target, useful for call/return stack). This version is a bit limited but it's simple. Other versions should appear which can associate more registers, at a higher cost. I don't count on them yet and i prefer to be careful when coding, i try to reduce the pressure on the LSU. FC0 behaves like F-CPU : all registers can be used to point to data or instructions, but FC0 implements this in such a way that using a lot of registers will "spill" (like a cache that overflows). The program's behaviour will be the same but with some performance reductions. I hope this helps. > Thomas Lavergne "Le vrai rêveur est celui qui rêve > de l'impossible." (Elsa Triolet) WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Tue Aug 20 01:07:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1k3-0000Fx-00 for ; Wed, 28 Aug 2002 14:16:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:11 +0200 (CEST) Received: (qmail 21500 invoked by uid 0); 19 Aug 2002 23:15:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 19 Aug 2002 23:15:43 -0000 Received: by moria.seul.org (Postfix) id 03CFA1469B4; Mon, 19 Aug 2002 19:15:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E217B1469B7; Mon, 19 Aug 2002 19:15:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9CF051469B4 for ; Mon, 19 Aug 2002 19:15:41 -0400 (EDT) Received: from laposte.net (193.250.226.244) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB60900266BEF for f-cpu@seul.org; Tue, 20 Aug 2002 01:15:40 +0200 Message-ID: <3D617A2A.8060502@laposte.net> Date: Tue, 20 Aug 2002 01:07:22 +0200 From: Thomas Lavergne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Register use Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Some times ago, someone have pointed out that we can't use all register as pointer or data, but only 8 of us. But I've searched all the manual, I can't find anything about that (except a section that say that f-cpu have general register so no reg dedicated for pointer) Could someone explain what is exactly this limitation and the reason of this chioce ? -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Aug 20 00:49:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1k1-0000Fx-00 for ; Wed, 28 Aug 2002 14:16:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:09 +0200 (CEST) Received: (qmail 32393 invoked by uid 0); 19 Aug 2002 22:46:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Aug 2002 22:46:20 -0000 Received: by moria.seul.org (Postfix) id 44F061469B1; Mon, 19 Aug 2002 18:46:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 148CA1469B5; Mon, 19 Aug 2002 18:46:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf10bis.bellsouth.net (mail010.mail.bellsouth.net [205.152.58.30]) by moria.seul.org (Postfix) with ESMTP id B15D51469B1 for ; Mon, 19 Aug 2002 18:46:18 -0400 (EDT) Received: from computer ([208.60.245.152]) by imf10bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020819224754.KZXW19269.imf10bis.bellsouth.net@computer> for ; Mon, 19 Aug 2002 18:47:54 -0400 Message-ID: <000c01c247d2$a9934360$98f53cd0@computer> From: "richard hartny" To: Subject: [f-cpu] Erin32/64/128 Date: Mon, 19 Aug 2002 17:49:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C247A8.BFFCF8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C247A8.BFFCF8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nico: Your question was - How do you handle function pointer and = return address in function? Is it no more data? I have adequate Local Memory to provide a fixed (dedicated) amount = of USER memory for 128 CRT Monitors. Now; if I understand your question = correctly: The sequence of execution is: 1. Load Accumulator with Arg 2. Execute a JST (Jump & Store Return) to Routine X 3. X will now contain the incremented Address for = return (if desired) and the next series is executed. 4. If required or desired; an Indirect Jump is executed = which will return to the Address stored in X. 5. The software System I am capturing always passes the = Arg to the Routine Called for Interrupt considerations. I hope this is the correct answer to your question. If not - come = again.=20 Will have the Erin128 ready in two days. All changes are made except = for the Barrel Shifter. Not difficult - just time consuming. Dick Hartney ------=_NextPart_000_0009_01C247A8.BFFCF8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    = Nico:    Your=20 question was - How do you handle function pointer and return address in=20 function?  Is it no more data?
 
    I have adequate = Local Memory to=20 provide a fixed (dedicated) amount of USER memory for 128 CRT = Monitors. =20 Now; if I understand your question correctly:
 
    The sequence = of  execution=20 is:
       =20         1.  Load Accumulator with=20 Arg
       =20         2.  Execute a JST (Jump & = Store=20 Return) to Routine X
       =20         3.  X will now contain the=20 incremented Address for return (if desired)
       =20             and the next = series is=20 executed.
       =20         4.  If required or desired; = an=20 Indirect Jump is executed which will return
       =20             to the Address = stored=20 in X.
          &nbs= p;    =20 5.  The software System I am capturing always passes the Arg to=20 the
       =20             Routine Called = for=20 Interrupt considerations.
 
I hope this is the correct answer to = your=20 question.  If not - come again.
 
Will have the Erin128 ready in two = days.  All=20 changes are made except for the Barrel Shifter.  Not difficult - = just time=20 consuming.
 
Dick Hartney
------=_NextPart_000_0009_01C247A8.BFFCF8A0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Aug 19 19:02:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1jw-0000Fx-01 for ; Wed, 28 Aug 2002 14:16:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:04 +0200 (CEST) Received: (qmail 32073 invoked by uid 0); 19 Aug 2002 22:08:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 19 Aug 2002 22:08:59 -0000 Received: by moria.seul.org (Postfix) id 67947146998; Mon, 19 Aug 2002 18:08:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 30FD01469B3; Mon, 19 Aug 2002 18:08:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a184.home.uni-hannover.de [130.75.232.184]) by moria.seul.org (Postfix) with ESMTP id 8D29E146998 for ; Mon, 19 Aug 2002 18:08:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00376; Mon, 19 Aug 2002 19:02:32 +0200 Message-ID: <20020819190232.37973@thrai.stud.uni-hannover.de> Date: Mon, 19 Aug 2002 19:02:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] TLB right + resume References: <200208190911.3baf@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208190911.3baf@th00.opsion.fr>; from Nicolas Boulay on Mon, Aug 19, 2002 at 09:11:59AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Mon, Aug 19, 2002 at 09:11:59AM +0000, Nicolas Boulay wrote: [...] > >>> You can't prevent the mistake of all the future use of the F-cpu ! > Beleiving that the hardware will do all the job for you is a dream of > progammer, but not a reality ! HW+SW are design to realise a task, the > faster, the cheeper, the more flexible way they can. The RICS adventure > said to use more the SW and speed up dumb thing in the HW and do the > clever thing in SW. Since we're building a processor for general use, we must provide a reasonable amount of functionality. Paging and fine-grained page level protection *is* reasonable, IMHO. [...] > >>> I try to resume what we want to avoid : > 1- give kernel page to kernel function call to access kernel page from > user process. > 2- execute user code in kernel mode > 3- execute librairy call to execute excve with /bin/sh to have a shell > access. That's a SW problem. > 4- diseable any possiblity of buffer overflow. Dto. > 5- Protect part of the kernel (driver) from it-self That's what you need fine-grained access rights for. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 19 15:15:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1ja-0000Fx-00 for ; Wed, 28 Aug 2002 14:15:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:15:42 +0200 (CEST) Received: (qmail 24993 invoked by uid 0); 19 Aug 2002 13:15:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 19 Aug 2002 13:15:22 -0000 Received: by moria.seul.org (Postfix) id B3FF4146984; Mon, 19 Aug 2002 09:15:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 961F6146987; Mon, 19 Aug 2002 09:15:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id E112C146984 for ; Mon, 19 Aug 2002 09:15:19 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208191315.082f; Mon, 19 Aug 2002 13:15:08 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Erin32/64/128 From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Aug 2002 13:15:08 GMT Message-id: <200208191315.082f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N How do you handle function pointer and return adress in func= tion ? Is it no more data ? nicO -----Message d'origine----- De: "richard hartny" A: Date: 19/08/02 Objet: [f-cpu] Erin32/64/128 Very interesting discussion. Fortunately I will never be fa= ced with the problems of the F-CPU architecture. Its more of the same st= uff - permit downloading of software and the problems will exist FOREVER.= My processors are bootloaded from Flash Eproms ONLY. No regist= er worries - I have only one - an Accumulator. And there is no hardware path to the SRAM Program Memory from Data downlo= ads. =20 Dick Hartney =20 ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Mon Aug 19 14:58:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1jZ-0000Fx-00 for ; Wed, 28 Aug 2002 14:15:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:15:41 +0200 (CEST) Received: (qmail 22559 invoked by uid 0); 19 Aug 2002 12:55:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Aug 2002 12:55:14 -0000 Received: by moria.seul.org (Postfix) id 97BC914697B; Mon, 19 Aug 2002 08:55:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F1C114697F; Mon, 19 Aug 2002 08:55:13 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf04bis.bellsouth.net (mail004.mail.bellsouth.net [205.152.58.24]) by moria.seul.org (Postfix) with ESMTP id 155DF14697B for ; Mon, 19 Aug 2002 08:55:13 -0400 (EDT) Received: from computer ([208.60.245.217]) by imf04bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020819125648.XIDA6747.imf04bis.bellsouth.net@computer> for ; Mon, 19 Aug 2002 08:56:48 -0400 Message-ID: <001401c24780$16111740$d9f53cd0@computer> From: "richard hartny" To: Subject: [f-cpu] Erin32/64/128 Date: Mon, 19 Aug 2002 07:58:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C24756.2C826DA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C24756.2C826DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Very interesting discussion. Fortunately I will never be faced with the = problems of the F-CPU architecture. Its more of the same stuff - permit = downloading of software and the problems will exist FOREVER. My = processors are bootloaded from Flash Eproms ONLY. No register worries - = I have only one - an Accumulator. And there is no hardware path to the SRAM Program Memory from Data downloads. =20 Dick Hartney =20 ------=_NextPart_000_0011_01C24756.2C826DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Very interesting discussion.  = Fortunately I=20 will never be faced with the problems of the F-CPU architecture.  = Its more=20 of the same stuff - permit downloading of software and the problems will = exist=20 FOREVER.  My processors are bootloaded from Flash Eproms = ONLY.  No=20 register worries - I have only one - an Accumulator.  And there=20 is
no hardware path to the SRAM Program = Memory from=20 Data downloads. 
 
Dick Hartney
 
    =
------=_NextPart_000_0011_01C24756.2C826DA0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 19 13:58:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1jW-0000Fx-00 for ; Wed, 28 Aug 2002 14:15:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:15:38 +0200 (CEST) Received: (qmail 31668 invoked by uid 0); 19 Aug 2002 11:59:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 19 Aug 2002 11:59:08 -0000 Received: by moria.seul.org (Postfix) id 83E2C146965; Mon, 19 Aug 2002 07:59:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 56888146974; Mon, 19 Aug 2002 07:59:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id E4013146965 for ; Mon, 19 Aug 2002 07:59:06 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208191158.398a; Mon, 19 Aug 2002 11:58:57 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] url From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Aug 2002 11:58:57 GMT Message-id: <200208191158.398a@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I just find this one from the utopia webring. http://www.jwdt.com/~paysan/4stack.html I will juste read all the spec there is interesting things i= n it (like avoiding large ported register bank,...) ! nicO ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 19 11:11:59 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1jT-0000Fx-01 for ; Wed, 28 Aug 2002 14:15:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:15:35 +0200 (CEST) Received: (qmail 18129 invoked by uid 0); 19 Aug 2002 09:12:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 19 Aug 2002 09:12:13 -0000 Received: by moria.seul.org (Postfix) id B288E14695E; Mon, 19 Aug 2002 05:12:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 92812146962; Mon, 19 Aug 2002 05:12:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id DE0A314695E for ; Mon, 19 Aug 2002 05:12:11 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208190911.3baf; Mon, 19 Aug 2002 09:11:59 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Aug 2002 09:11:59 GMT Message-id: <200208190911.3baf@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: cedric A: f-cpu@seul.org Date: 15/08/02 Objet: Re: [f-cpu] TLB right > Todays, linux use 1 big page for kernel, so there isn't an= y page miss > inside the kernel code. That's speed up things ! If you us= e many pages > to protect things, you could lose speed. The problem isn't with the kernel page (and we can still hav= e a big page for=20 the kernel). The problem is for user page, when you do a mal= loc you say that=20 the kernel can't execute them, and your kernel will be prote= cted from all=20 attack that want to execute user code with kernel right and = in hardware. >>> Not only. Reread MISC. The last attack use a call to exc= ve with /bin/sh as argument. There is no malicious code executed, ju= st a call to a librairy.=20 > Maybe, this could be used to create modules with superuser= privileges. > It could be interresting to protect kernel from a bad writ= ten driver. > Usualy it is done by using user space. But you don't preve= nt anything if > the driver touch the tlb stuff. That's not the problem. You can't protect the kernel from it= self, and a driver=20 (in Linux) is a part of the kernel and not from the outside.= We can probably=20 do a protection in kernel with a special handler for SR writ= e in kernel mode,=20 but it's still an idea. > I beleive it's none sense because superuser code could alw= ays change tlb > entries. And to avoid sending a kernel space adresse to a = user call, you Not true, you can have a TLB handler on write that make an authentification of=20 the code that want to write data into the TLB. With a SR wri= te handler and a=20 special TLB handler you can have a really securised kernel.=20 At least it will not cost a lot to do that, because the 2 h= andlers will only=20 be called when they are not in IRQ/TRAP. >>> So you can't make "delayed" interrupt, so can't really m= ake preemptive kernel...or you lose time inside a kernel trap. T= he drivers could also change the tlb write handler... That's juste a sl= ide of the problem...And you try to protect the kernel from it-self, to= o. Maybe we could add an other ring to protected tlb handler ? Antoine propose to use different load&store intructions to l= oad user page or kernel pages. It is a little bit like my proposal to= split load&store for managing the return stack securely. You can u= se a specific return stack to avoid buffer overflow, but you coul= d want to be absolutely sure that the 2 stacks could not be override by u= sing different load&store instructions. > only have to check the pointer MSB bit... And only have to forgot some of them like in OpenBSD... the = most secur OS >>> You can't prevent the mistake of all the future use of t= he F-cpu ! Beleiving that the hardware will do all the job for you is a= dream of progammer, but not a reality ! HW+SW are design to realise a= task, the faster, the cheeper, the more flexible way they can. The RIC= S adventure said to use more the SW and speed up dumb thing in the HW an= d do the clever thing in SW.=20 > > So if we port an OS, > > we need to do a lot of change, and we can forget some of= them (like the > > last local bug in OpenBSD). > > Every kernel call should be check, so what ? If in OpenBSD they have forgotten one, they can forget it in= other OS, so more=20 security you have better it is. And it's easy to write a TLB= handler and a SR=20 handler than to modify all the kernel call and not to forget= any of them. >>> We can't work to avoid future possible mistaks of OS wri= ters !! We try to give enough tools to do it cleanly (and not by trying= to *emulate* the none excution bit of the stack). Cedric ---- >>> I try to resume what we want to avoid : 1- give kernel page to kernel function call to access kernel= page from user process. 2- execute user code in kernel mode=20 3- execute librairy call to execute excve with /bin/sh to ha= ve a shell access. 4- diseable any possiblity of buffer overflow. 5- Protect part of the kernel (driver) from it-self My proposal : 1- memory check by the OS like today's OS. 2- I can't see how it could possible. 3- if buffer overflow isn't possible any more, this problem = is over, too. 4- You can split the return stack of the function, and use s= pecific write instruction to write on this stack. Such instruction a= re placed by the compiler at the call of the function only, so typical st= rcpy() could not be used to scratch this area. Maybe this could be done b= y a "tagged" memory (a flag in tlb and in the instruction write) and coul= d be reused for split user from kernel pages. But there is always the problem of function pointer (i hate = C ! ;p).(the pointer could still be overridden by buffer overflow, we cou= ld try to make 2 indirections to use such pointer (the pointer are a p= ointer to the table of the pointer of fonction). We could also try to = put the pointer before any array in a function. And we could use a c= anary, it's a random number put before any function pointer, if this num= ber change the program die. It's very hard for a buffer overflow attack= to preserve the canary but always possible) (our main discussion) 5- Could be an interresting feature, but most of the time th= e OS use user land to do it. Maybe we could use the idea of the "tagg= ed" memory and "tagged" write. ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Aug 19 10:17:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1jT-0000Fx-00 for ; Wed, 28 Aug 2002 14:15:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:15:35 +0200 (CEST) Received: (qmail 31686 invoked by uid 0); 19 Aug 2002 08:17:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Aug 2002 08:17:39 -0000 Received: by moria.seul.org (Postfix) id AA819146914; Mon, 19 Aug 2002 04:17:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 743DD14695F; Mon, 19 Aug 2002 04:17:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 5AA24146914 for ; Mon, 19 Aug 2002 04:17:36 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208190817.1879; Mon, 19 Aug 2002 08:17:24 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] TLB right From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Aug 2002 08:17:24 GMT Message-id: <200208190817.1879@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N F-cpu pointer size are determined and are fixed at 64 bits != It's not in a chunk and have nothing to do with it. Pointer use the bigg= er size available for integer so 64 bits, what ever chunck could han= dle the register bank. nicO -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 16/08/02 Objet: Re: [f-cpu] TLB right hi, nico wrote: > I beleive it's none sense because superuser code could alw= ays change tlb > entries. And to avoid sending a kernel space adresse to a = user call, you > only have to check the pointer MSB bit... i don't want to step into your high level discussions, but ... F-CPU pointers are not 32 bits. F-CPU pointers (in userland) fit in a "chunk" and it's defined as "minimum 64 bits". Please avoid problems and don't do like other architectures : F-CPU pointer sizes are not determined. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 16 02:11:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1iA-0000Fx-01 for ; Wed, 28 Aug 2002 14:14:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:14:14 +0200 (CEST) Received: (qmail 19151 invoked by uid 0); 16 Aug 2002 01:03:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 16 Aug 2002 01:03:15 -0000 Received: by moria.seul.org (Postfix) id D1FA714694C; Thu, 15 Aug 2002 21:03:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9B7A8146950; Thu, 15 Aug 2002 21:03:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 6AC2514694C for ; Thu, 15 Aug 2002 21:03:14 -0400 (EDT) Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by bettik.munge.net (Postfix) with ESMTP id 983844F7F3 for ; Thu, 15 Aug 2002 19:00:06 -0500 (CDT) Received: from f-cpu.org (kdl16-247.n.club-internet.fr [213.44.18.247]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1F0BF1688 for ; Fri, 16 Aug 2002 02:01:09 +0200 (CEST) Message-ID: <3D5C431A.E412E74@f-cpu.org> Date: Fri, 16 Aug 2002 02:11:06 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB right References: <200208140547.02827.cedric.bail@free.fr> <3D5BCFBF.F3C8FAC3@ifrance.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > I beleive it's none sense because superuser code could always change tlb > entries. And to avoid sending a kernel space adresse to a user call, you > only have to check the pointer MSB bit... i don't want to step into your high level discussions, but ... F-CPU pointers are not 32 bits. F-CPU pointers (in userland) fit in a "chunk" and it's defined as "minimum 64 bits". Please avoid problems and don't do like other architectures : F-CPU pointer sizes are not determined. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Aug 16 05:08:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1i1-0000Fx-00 for ; Wed, 28 Aug 2002 14:14:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:14:05 +0200 (CEST) Received: (qmail 14275 invoked by uid 0); 15 Aug 2002 20:39:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 15 Aug 2002 20:39:07 -0000 Received: by moria.seul.org (Postfix) id 4018C14694B; Thu, 15 Aug 2002 16:39:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F3D214694F; Thu, 15 Aug 2002 16:39:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id ACBAE14694B for ; Thu, 15 Aug 2002 16:39:06 -0400 (EDT) Received: from gaia (nas-cbv-8-62-147-156-241.dial.proxad.net [62.147.156.241]) by postfix2-1.free.fr (Postfix) with ESMTP id C1AC8545 for ; Thu, 15 Aug 2002 22:39:04 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] TLB right Date: Fri, 16 Aug 2002 05:08:19 +0200 X-Mailer: KMail [version 1.4] References: <200208140547.02827.cedric.bail@free.fr> <3D5BCDB0.54D70AD0@ifrance.com> In-Reply-To: <3D5BCDB0.54D70AD0@ifrance.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208160508.19552.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Todays, linux use 1 big page for kernel, so there isn't any page miss > inside the kernel code. That's speed up things ! If you use many pages > to protect things, you could lose speed. The problem isn't with the kernel page (and we can still have a big page for the kernel). The problem is for user page, when you do a malloc you say that the kernel can't execute them, and your kernel will be protected from all attack that want to execute user code with kernel right and in hardware. > Maybe, this could be used to create modules with superuser privileges. > It could be interresting to protect kernel from a bad written driver. > Usualy it is done by using user space. But you don't prevent anything if > the driver touch the tlb stuff. That's not the problem. You can't protect the kernel from itself, and a driver (in Linux) is a part of the kernel and not from the outside. We can probably do a protection in kernel with a special handler for SR write in kernel mode, but it's still an idea. > I beleive it's none sense because superuser code could always change tlb > entries. And to avoid sending a kernel space adresse to a user call, you Not true, you can have a TLB handler on write that make an authentification of the code that want to write data into the TLB. With a SR write handler and a special TLB handler you can have a really securised kernel. At least it will not cost a lot to do that, because the 2 handlers will only be called when they are not in IRQ/TRAP. > only have to check the pointer MSB bit... And only have to forgot some of them like in OpenBSD... the most secur OS > > So if we port an OS, > > we need to do a lot of change, and we can forget some of them (like the > > last local bug in OpenBSD). > > Every kernel call should be check, so what ? If in OpenBSD they have forgotten one, they can forget it in other OS, so more security you have better it is. And it's easy to write a TLB handler and a SR handler than to modify all the kernel call and not to forget any of them. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 20 03:21:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1k5-0000Fx-01 for ; Wed, 28 Aug 2002 14:16:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:13 +0200 (CEST) Received: (qmail 13574 invoked by uid 0); 20 Aug 2002 01:11:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 20 Aug 2002 01:11:11 -0000 Received: by moria.seul.org (Postfix) id 9C930146802; Mon, 19 Aug 2002 21:11:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 775BD14681D; Mon, 19 Aug 2002 21:11:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 3132B146802 for ; Mon, 19 Aug 2002 21:11:10 -0400 (EDT) Received: from f-cpu.org (kll1-1.n.club-internet.fr [213.44.91.1]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 4588A1687 for ; Tue, 20 Aug 2002 03:11:03 +0200 (CEST) Message-ID: <3D619982.6E1E3A66@f-cpu.org> Date: Tue, 20 Aug 2002 03:21:06 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] url References: <200208191158.398a@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > > I just find this one from the utopia webring. woohooo ! someone uses it :-) > http://www.jwdt.com/~paysan/4stack.html cool that you discover this exists... > I will juste read all the spec there is interesting things in it (like > avoiding large ported register bank,...) ! mmmmh beware of wrong "good ideas"... stack-CPUs, even multistack ones, can hide problems. > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 20 09:29:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1kA-0000Fx-01 for ; Wed, 28 Aug 2002 14:16:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:18 +0200 (CEST) Received: (qmail 8042 invoked by uid 0); 20 Aug 2002 07:29:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 20 Aug 2002 07:29:27 -0000 Received: by moria.seul.org (Postfix) id B785F14696B; Tue, 20 Aug 2002 03:29:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A21921469BD; Tue, 20 Aug 2002 03:29:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id EE87614696B for ; Tue, 20 Aug 2002 03:29:25 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208200729.134e; Tue, 20 Aug 2002 07:29:19 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] url From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Aug 2002 07:29:19 GMT Message-id: <200208200729.134e@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 20/08/02 Objet: Re: [f-cpu] url hi, Nicolas Boulay wrote: >=20 > I just find this one from the utopia webring. woohooo ! someone uses it :-) > http://www.jwdt.com/~paysan/4stack.html cool that you discover this exists... > I will juste read all the spec there is interesting things= in it (like > avoiding large ported register bank,...) ! mmmmh beware of wrong "good ideas"... stack-CPUs, even multistack ones, can hide problems. >>> They need a true C compiler ! Forth is not enought. nicO > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Aug 20 14:40:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1kl-0000Fx-00 for ; Wed, 28 Aug 2002 14:16:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:16:55 +0200 (CEST) Received: (qmail 18997 invoked by uid 0); 20 Aug 2002 21:14:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 20 Aug 2002 21:14:22 -0000 Received: by moria.seul.org (Postfix) id 9DFB2146ABD; Tue, 20 Aug 2002 15:30:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8BD4F146AC7; Tue, 20 Aug 2002 15:30:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (unknown [130.75.232.127]) by moria.seul.org (Postfix) with ESMTP id 521EE146ABD for ; Tue, 20 Aug 2002 15:30:15 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00492; Tue, 20 Aug 2002 14:40:21 +0200 Message-ID: <20020820144021.20838@thrai.stud.uni-hannover.de> Date: Tue, 20 Aug 2002 14:40:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume References: <200208200905.08b6@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208200905.08b6@th00.opsion.fr>; from Nicolas Boulay on Tue, Aug 20, 2002 at 09:05:08AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wrote: [...] > > 3- execute librairy call to execute excve with /bin/sh to have a shell > > access. > > That's a SW problem. > > >>> A compiler problem, so an abi problem. The last security problem in > case of buffer overflow. > > > 4- diseable any possiblity of buffer overflow. > > Dto. > > >>> ??? don't understand that word. Sorry... it was supposed to mean "same as above". > > 5- Protect part of the kernel (driver) from it-self > > That's what you need fine-grained access rights for. > > >>> Do you think it's wise to protect the kernel from it-self ? It's a side-effect when you protect the kernel from user code. > >>> What you think about the idea of tagged page that could only be used > by tagged read&write instructions (to protect data page of the kernel > and return stack write) ? I'm afraid that will help only if you compile all your binaries yourself (otherwise, they might contain "trojan writes"). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 21 13:11:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lA-0000Fx-01 for ; Wed, 28 Aug 2002 14:17:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:20 +0200 (CEST) Received: (qmail 3957 invoked by uid 0); 21 Aug 2002 11:01:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 21 Aug 2002 11:01:26 -0000 Received: by moria.seul.org (Postfix) id 8E5DB14680C; Wed, 21 Aug 2002 07:01:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FCE0146850; Wed, 21 Aug 2002 07:01:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id E7C8214680C for ; Wed, 21 Aug 2002 07:01:23 -0400 (EDT) Received: from f-cpu.org (kdl11-132.n.club-internet.fr [213.44.9.132]) by relay-3v.club-internet.fr (Postfix) with ESMTP id F294D169B for ; Wed, 21 Aug 2002 13:01:20 +0200 (CEST) Message-ID: <3D637561.A0E4977E@f-cpu.org> Date: Wed, 21 Aug 2002 13:11:29 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume References: <200208210809.1561@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Nicolas Boulay wrote: > -----Message d'origine----- > De: Michael Riepe > > On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wrote: > [...] > > > 4- diseable any possiblity of buffer overflow. > > > > Dto. > > > > >>> ??? don't understand that word. > > Sorry... it was supposed to mean "same as above". > > >>> This is the problem number one of the computer security, if it > became impossible to do it, you see what reputation could have the > f-cpu... If there was an easy way to do this, then it would already be used by everybody. Unfortunately, everybody sticks with C and the select() exploit is possible. This could have been avoided by using ADA or JAVA. Java sux but at least, strongly typed langages are good at avoiding silly errors like this. Buffer overflows are another problems and it depends a lot on the coder and the langage. The CPU can't do much on this matter, particularly if a (dumb) coder wants to use a (dumb) langage. I think i'll simply make the TLB user-configurable until F-CPU rev. 1 is frozen. This way, people could explore the necessary/useless features. This is the easiest way to solve the TLB problems because everybody wants something different. John Graley wrote: > > From: Michael Riepe [mailto:michael@stud.uni-hannover.de] > > > >>> What you think about the idea of tagged page that could > > > only be used by tagged read&write instructions (to protect > > > data page of the kernel and return stack write) ? > > > > I'm afraid that will help only if you compile all your > > binaries yourself (otherwise, they might contain "trojan writes"). > > Surely it would be a simple matter in software to search through executables > looking for the op-codes of illegal instructions before execution? ever heard about self-modifying codes ? sure they could be avoided by not allowing WX pages. but this opens a new domain of vulnerabilities and this would not help against physical failures. maybe the solution lies somewhere else, not in the TLBs. > Cheers, John WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 21 13:13:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lB-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:21 +0200 (CEST) Received: (qmail 26159 invoked by uid 0); 21 Aug 2002 11:14:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Aug 2002 11:14:04 -0000 Received: by moria.seul.org (Postfix) id 73F6A1467F1; Wed, 21 Aug 2002 07:14:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F498146850; Wed, 21 Aug 2002 07:14:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id DCDCD1467F1 for ; Wed, 21 Aug 2002 07:14:02 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208211113.37ca; Wed, 21 Aug 2002 11:13:55 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Aug 2002 11:13:55 GMT Message-id: <200208211113.37ca@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 21/08/02 Objet: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resum= e hi, Nicolas Boulay wrote: > -----Message d'origine----- > De: Michael Riepe >=20 > On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay w= rote: > [...] > > > 4- diseable any possiblity of buffer overflow. > > > > Dto. > > > > >>> ??? don't understand that word. >=20 > Sorry... it was supposed to mean "same as above". >=20 > >>> This is the problem number one of the computer securit= y, if it > became impossible to do it, you see what reputation could = have the > f-cpu... If there was an easy way to do this, then it would already b= e used by everybody. >>>And windows is the best OS because everybody use it ? :-/= Most of the cpu of workstation have an old ISA, and maybe i could have s= ome new idea some times... Unfortunately, everybody sticks with C and the select() expl= oit is possible. This could have been avoided by using ADA or JA= VA. Java sux but at least, strongly typed langages are good at a= voiding silly errors like this. >>>Client have always right ! Client (end user) use C for ma= ny reasons, so must provide a good way to use C ! Nothing to add more. W= hat do you mean by select() exploit ? Buffer overflows are another problems and it depends a lot o= n the coder and the langage. The CPU can't do much on this mat= ter, particularly if a (dumb) coder wants to use a (dumb) langage= . >>> Hummm ! I don't think that the coder of mozilla,etc ... = are so dumb ! I think i'll simply make the TLB user-configurable until F-CPU rev. 1 is frozen. This way, people could explore the necessary/useless features. This is the easiest way to s= olve the TLB problems because everybody wants something different= . >>> You mean : just puting bits in tlb and parameter their = meaning ? How could you verify for read, write, instruction fetch, loa= d&store in tagged region in a configurable way ? Do we implement all of= this ? nicO John Graley wrote: > > From: Michael Riepe [mailto:michael@stud.uni-hannover.de= ] > > > >>> What you think about the idea of tagged page that = could > > > only be used by tagged read&write instructions (to pro= tect > > > data page of the kernel and return stack write) ? > > > > I'm afraid that will help only if you compile all your > > binaries yourself (otherwise, they might contain "trojan= writes"). >=20 > Surely it would be a simple matter in software to search t= hrough executables > looking for the op-codes of illegal instructions before ex= ecution? ever heard about self-modifying codes ? sure they could be avoided by not allowing WX pages. but thi= s opens a new domain of vulnerabilities and this would not help agai= nst physical failures. >>>physical failure !!! You want to be fault tolerant. What = a news ! But as i said in the previous mail, that a false problem ! maybe the solution lies somewhere else, not in the TLBs. >>> Why ? Where are your arguments ? nicO > Cheers, John WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Aug 21 21:46:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lG-0000Fx-01 for ; Wed, 28 Aug 2002 14:17:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:26 +0200 (CEST) Received: (qmail 12931 invoked by uid 0); 21 Aug 2002 19:43:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 21 Aug 2002 19:43:20 -0000 Received: by moria.seul.org (Postfix) id 72D2B146AAA; Wed, 21 Aug 2002 15:43:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5DA40146AAC; Wed, 21 Aug 2002 15:43:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf17bis.bellsouth.net (mail217.mail.bellsouth.net [205.152.58.157]) by moria.seul.org (Postfix) with ESMTP id 0C60C146AAA for ; Wed, 21 Aug 2002 15:43:19 -0400 (EDT) Received: from computer ([208.60.244.45]) by imf17bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020821194454.FCNK1206.imf17bis.bellsouth.net@computer> for ; Wed, 21 Aug 2002 15:44:54 -0400 Message-ID: <001001c2494b$70f56360$2df43cd0@computer> From: "richard hartny" To: Subject: [f-cpu] Erin32/64/128 Date: Wed, 21 Aug 2002 14:46:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C24921.87684060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C24921.87684060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Software System I am going to capture uses SELF MODIFYING CODE. But with my hardware design this will be IMPOSSIBLE. I will not permit = downloading of Instructions into the Instruction SRAM. After boot load - the SRAM is = read ONLY. Where this is presently used by previous Software troops - this code = shall be rewritten....... Dick Hartney ------=_NextPart_000_000D_01C24921.87684060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The Software System I am going to = capture uses SELF=20 MODIFYING CODE.  But
with my hardware design this will be=20 IMPOSSIBLE.  I will not permit downloading of
Instructions into the Instruction = SRAM.  After=20 boot load - the SRAM is read ONLY.
Where this is presently used by = previous Software=20 troops - this code shall be rewritten.......
 
Dick Hartney
------=_NextPart_000_000D_01C24921.87684060-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 21 13:38:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lL-0000Fx-01 for ; Wed, 28 Aug 2002 14:17:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:31 +0200 (CEST) Received: (qmail 8981 invoked by uid 0); 21 Aug 2002 21:46:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 21 Aug 2002 21:46:03 -0000 Received: by moria.seul.org (Postfix) id B7990146919; Wed, 21 Aug 2002 17:46:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 941B8146A02; Wed, 21 Aug 2002 17:46:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 3F0E5146919 for ; Wed, 21 Aug 2002 17:46:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00502; Wed, 21 Aug 2002 13:38:48 +0200 Message-ID: <20020821133847.14281@thrai.stud.uni-hannover.de> Date: Wed, 21 Aug 2002 13:38:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume References: <37D1208A1C9BD511855B00D0B772242C0118ADD1@corpmail1.sc.sonicblue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <37D1208A1C9BD511855B00D0B772242C0118ADD1@corpmail1.sc.sonicblue.com>; from John Graley on Wed, Aug 21, 2002 at 02:58:35AM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 21, 2002 at 02:58:35AM -0700, John Graley wrote: [...] > Surely it would be a simple matter in software to search through executables > looking for the op-codes of illegal instructions before execution? That's not simple at all. Especially if these instructions are allowed in certain places (stack write) but not in any others. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 22 22:10:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lY-0000Fx-00 for ; Wed, 28 Aug 2002 14:17:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:44 +0200 (CEST) Received: (qmail 6466 invoked by uid 0); 22 Aug 2002 20:10:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 22 Aug 2002 20:10:12 -0000 Received: by moria.seul.org (Postfix) id 5B32215E43E; Thu, 22 Aug 2002 16:10:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2748515E6F7; Thu, 22 Aug 2002 16:10:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id DA4B115E43E for ; Thu, 22 Aug 2002 16:10:08 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-2.free.fr (Postfix) with ESMTP id 8AD4B5FE9A for ; Thu, 22 Aug 2002 22:10:07 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 5559D64120; Thu, 22 Aug 2002 22:10:07 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Too much option Message-ID: <1030047006.3d65451edaeeb@imp.free.fr> Date: Thu, 22 Aug 2002 22:10:06 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.15.34.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am currently working on a new release of the manual with the new color code for ISA and an OP_CODE map. I discover that we have 2048 possibles versions of the F-CPU, because we have a lot of optionals instructions. All the immediate form are optional, mix/expand/sdup are optional too. For me they must be include in all F-CPU compatible chip and we must reduce the number of possible version of F-CPU chip. I agree that LNS and FPU must be optional, but for increment based operation I think it's really too much usefull to be optional. What did you think about this problem ? I update shift instructions too and I discover that they have 2 unused bits. Why not using them to say : 00 => double shift right 01 => shift right 10 => shift left 11 => double shift left The problem will be with immediate, in that case we can use 2 operandes one for normal shift the other for dshift. (rot instructions have 2 unused bits too, so we can use them in the same way). It can save a lot of OP_CODE. (I quickly count them, and we have approximatively 100 different OP_CODE). For the next release I want to insert widen instructions, but I read in a precedent mail that michael didn't like the way he describe it or something like that. Is it possible to have a little description on them ? Cedric PS: Yann I am waiting for your new ROP2 instructions list... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 22 22:23:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1lZ-0000Fx-01 for ; Wed, 28 Aug 2002 14:17:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:17:45 +0200 (CEST) Received: (qmail 4831 invoked by uid 0); 22 Aug 2002 20:23:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Aug 2002 20:23:33 -0000 Received: by moria.seul.org (Postfix) id 2C3FF15E74C; Thu, 22 Aug 2002 16:23:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0960D15E74F; Thu, 22 Aug 2002 16:23:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 5ADC115E74C for ; Thu, 22 Aug 2002 16:23:31 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id 226625A0 for ; Thu, 22 Aug 2002 22:23:30 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id EF45664120; Thu, 22 Aug 2002 22:23:29 +0200 (MEST) To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume Message-ID: <1030047809.3d654841e3397@imp.free.fr> Date: Thu, 22 Aug 2002 22:23:29 +0200 (MEST) From: Cedric BAIL References: <200208211113.37ca@th00.opsion.fr> In-Reply-To: <200208211113.37ca@th00.opsion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.15.34.130 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > > 4- diseable any possiblity of buffer overflow. > > >>> This is the problem number one of the computer security, if it > > became impossible to do it, you see what reputation could have the > > f-cpu... > If there was an easy way to do this, then it would already be used > by everybody. Not sure, it help software society to sell new release ;-) > >>>And windows is the best OS because everybody use it ? :-/ Most of > the cpu of workstation have an old ISA, and maybe i could have some new > idea some times... > Unfortunately, everybody sticks with C and the select() exploit > is possible. This could have been avoided by using ADA or JAVA. > Java sux but at least, strongly typed langages are good at avoiding > silly errors like this. > >>>Client have always right ! Client (end user) use C for many > reasons, so must provide a good way to use C ! Nothing to add more. > What do you mean by select() exploit ? I think that it was the system call where the bug was in OpenBSD. > Buffer overflows are another problems and it depends a lot on > the coder and the langage. The CPU can't do much on this matter, > particularly if a (dumb) coder wants to use a (dumb) langage. I agree that C is not the best langage, but in a lot of case it's the most usefull. > >>> Hummm ! I don't think that the coder of mozilla,etc ... are so > dumb ! > I think i'll simply make the TLB user-configurable > until F-CPU rev. 1 is frozen. This way, people could explore > the necessary/useless features. This is the easiest way to solve > the TLB problems because everybody wants something different. > >>> You mean : just puting bits in tlb and parameter their meaning ? > How could you verify for read, write, instruction fetch, load&store in > tagged region in a configurable way ? Do we implement all of this ? I didn't understand your idea. Can you explain this a little bit more ? > >>>physical failure !!! You want to be fault tolerant. What a news ! > But as i said in the previous mail, that a false problem ! > maybe the solution lies somewhere else, not in the TLBs. > >>> Why ? Where are your arguments ? We have 2 points of security in F-CPU : TLB and SR. If he think it's not in TLB, he certainly think about SR, but I don't see why. Or perhaps the truth is somewhere else ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 24 15:48:49 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nM-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:36 +0200 (CEST) Received: (qmail 14238 invoked by uid 0); 24 Aug 2002 13:52:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 24 Aug 2002 13:52:39 -0000 Received: by moria.seul.org (Postfix) id D4DEF15E727; Sat, 24 Aug 2002 09:52:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BADDB15E72C; Sat, 24 Aug 2002 09:52:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 660C615E727 for ; Sat, 24 Aug 2002 09:52:37 -0400 (EDT) Received: from hli (80.15.61.85) by smtp.laposte.net (6.0.053) id 3D359CE9002361E5 for f-cpu@seul.org; Sat, 24 Aug 2002 15:52:36 +0200 Message-ID: <006201c24b74$fa0953c0$553d0f50@hli> From: "Christophe Avoinne" To: References: <200208042145.35776.cedric.bail@free.fr> Subject: Re: [f-cpu] Conditionnal load and store, the return Date: Sat, 24 Aug 2002 15:48:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Back from vacation. Wooh not less than 2000 emails received !! ----- Original Message ----- From: "cedric" To: Sent: Sunday, August 04, 2002 9:45 PM Subject: [f-cpu] Conditionnal load and store, the return > Hi, > > I have reread the discussion about conditionnal load and store, and I think > that we forgot something : exception. In fact when we do a load or a store > and check the condition only on write. Spoken about the bit in a LSU0 entry telling us if we can write ? if it is like a write-right token, setting it to 1 allows the first one to reset it and have right to write. If an exception occurs at this place, it means that there is no matching LSU0 entry (am I wrong ?), so there is no right to write and condition fails. Meanwhile, the exception is executed. At exception exit, condition fails so we can reexecute the faulty conditional store instruction. > The problem is what append if page > fault occur ? I think we must clarify that. > From my point of view I think that we must do the test before starting any > memory operation, so a trap only occur if the test is true. We must do the > same if we have a conditionnal prefetch. It's for me the only way to > correctly execute the 2 branch of a if simultaneously. > > Finally what did we do with the cachemm instruction ? Did we remove or change > this strange instruction ? > > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 24 16:01:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1nQ-0000Fx-00 for ; Wed, 28 Aug 2002 14:19:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:19:40 +0200 (CEST) Received: (qmail 466 invoked by uid 0); 24 Aug 2002 14:05:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 24 Aug 2002 14:05:57 -0000 Received: by moria.seul.org (Postfix) id 3D24F15E727; Sat, 24 Aug 2002 10:05:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F32C315E72C; Sat, 24 Aug 2002 10:05:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 837E515E727 for ; Sat, 24 Aug 2002 10:05:55 -0400 (EDT) Received: from hli (80.15.61.85) by smtp.laposte.net (6.0.053) id 3D2EB28C0028915F for f-cpu@seul.org; Sat, 24 Aug 2002 16:05:54 +0200 Message-ID: <000201c24b76$d606a8e0$553d0f50@hli> From: "Christophe Avoinne" To: References: <200208070731.285d@th00.opsion.fr> Subject: Re: Rep:Re: [f-cpu] TLB resume Date: Sat, 24 Aug 2002 16:01:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well there can be supervisor pages which are only data and should not be used for execution, so we need to set sx (supervisor,execute bits) to 0. For example the stack, so no application can try to pull code in a stack and execute it. There are many things where using supervisor right bits can be useful. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Wednesday, August 07, 2002 9:31 AM Subject: Rep:Re: [f-cpu] TLB resume -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 07/08/02 Objet: Re: [f-cpu] TLB resume On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote: [...] > > If supervisor mode is allowed to always access everything, you have a > > big security hole. > > Could you explain why ? Because when a user process calls the OS kernel, the system call is executed with supervisor access rights. That is, you can take an address that you're not allowed to access and pass it to the kernel, and the kernel *is* allowed to access it. You'll have to add rather expensive memory bounds checks to almost every system call in order to prevent that. Sacrificing three bits per TLB entry is cheaper (and more secure). --- >>> ??? In an adress space, the process could see what ever he want. Kernel are just mapped in the same adress in each AS to avoid trashing of the caches. (Christophe speak about a "global" that come from the x86 world. It say that virual adresse is OK for every AS. It avoid tlb miss.) In the AS, there is only data relevant to the user, to the librairy and to the kernel. Kernel page have none of the RWE bit set. To change the ring (pass from the user mode to the superuser one), you need something as trap, a specific call using vector adress. The adress are well known and defined as OS call. The exploit of buffer overflow could try to change the content of a librairy, to run "excve sh" (no need to have an executing stack, only the good parameter in the stack and the return adress of a function replace by those of a librairy function) or write you're code inside the librairy code. This could be defait by changing the memory location of the librairy (random adress at load), it became very hard to find good adresses. An other trick could be to use an other ring for librairie. So you enter the librairy as you enter in the kernel, with a kind of trap. This could only be used for dangerous function. Then you could protect the librairy space by adding RWE bit for a "librairy ring" or "librairy user", user bit will be 0 for such pages. The last exploit use the mmap fonction. You mmap a file with RWE right and then execute it (by replace a return adress by the adress of the buffer mmaped). Ring doesn't change anything on this, the only way to avoid it, is to disable the possibility to run a function call using a buffer overflow (as for excve). Our API are very less smart for crackers than those from x86. Most of the time the return adresse are on the register set. Because we need for none leaf function to save the return adress, i have proposed to use a specific return adress stack that could'nt be erased by buffer overflow. I don't understand why we need 3 superuser bits for that. The process does not know about other AS and kernel page could not be accessed. So ? nicO -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ Nouveau sur i (france), ne vous faites pas piquer votre nom! Réservez dès à présent votre nom de domaine pour 1 Euro* HT/mois (*à partir de) http://www.ifrance.com/_reloc/signdom ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Aug 27 03:03:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1od-0000Fx-00 for ; Wed, 28 Aug 2002 14:20:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:20:55 +0200 (CEST) Received: (qmail 14613 invoked by uid 0); 27 Aug 2002 01:03:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 27 Aug 2002 01:03:34 -0000 Received: by moria.seul.org (Postfix) id E72EF15E73D; Mon, 26 Aug 2002 21:03:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C993015E740; Mon, 26 Aug 2002 21:03:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by moria.seul.org (Postfix) with ESMTP id 6358A15E73D for ; Mon, 26 Aug 2002 21:03:33 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix1-2.free.fr (Postfix) with ESMTP id BC983AAFE9 for ; Tue, 27 Aug 2002 03:03:32 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 68CBB582CA; Tue, 27 Aug 2002 03:03:32 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return Message-ID: <1030410212.3d6acfe45bf20@imp.free.fr> Date: Tue, 27 Aug 2002 03:03:32 +0200 (MEST) From: Cedric BAIL References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> In-Reply-To: <002301c24b9a$2aa3cd60$553d0f50@hli> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.147.70.129 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > > I have reread the discussion about conditionnal load and store, and I > > > > think that we forgot something : exception. In fact when we do a load > > > > or a store and check the condition only on write. > > In fact we were speaking about a possible store[z/nz/m/l/nm/nl] and > > load[z/nz/m/l/nm/nl] instructions. And the problem was that currently the > > test is checked on wright, that mean you do first load the data and then > > you verify if the test is ok. > > load the data ? what data ? the conditional load only to need access > to memory if condition is true, so even an exception occurs, when > reexecuting the faulty instruction, all is okay. Same thing for the > conditional store. > So i don't see any problem. You will not reexecute it. I mean the conditionnal store on wich we discuss test if the condition register is zero or not, or if the lsb/msb if zero or not and if the test is true, the write is done. If you load a data conditionnaly, if the address isn't ok, and the test is false, no exeption must occur and it's where the problem is. > I maybe miss something. I think that you are thinking to the specific form that test if any access occur since you have read the data. That's the problem I speak on at the end of this mail. > The problem is that if you access to a not valid > > > But in fact we still have a problem with the conditional store/load > > with the LSU test in multi processor architecture. > Again, I don't see any problem. Currently if you have this : [DATA] | [CPU 1]---[CPU 2] When CPU2 do a conditional load/Store pair, it will not be abble to see if CPU 1 access to the data. The only reason why CPU 2 know that, is because all memory access will always be send to CPU 2 by CPU 1... It can be a big overkill. I perhaps miss something but the problem exist. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From e-lottoticket@columbus.rr.com Tue Aug 27 05:16:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1og-0000Fx-00 for ; Wed, 28 Aug 2002 14:20:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:20:58 +0200 (CEST) Received: (qmail 9895 invoked by uid 0); 27 Aug 2002 03:16:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 27 Aug 2002 03:16:32 -0000 Received: by moria.seul.org (Postfix) id E7EE915E73D; Mon, 26 Aug 2002 23:16:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C908515E740; Mon, 26 Aug 2002 23:16:30 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from list2.bravenet.com (celeborn.bravenet.com [66.180.230.24]) by moria.seul.org (Postfix) with ESMTP id 52E9615E73D for ; Mon, 26 Aug 2002 23:16:30 -0400 (EDT) Received: from bravenet.com (localhost [127.0.0.1]) by list2.bravenet.com (Postfix) with SMTP id 4D1DB9BCAB for ; Mon, 26 Aug 2002 20:16:29 -0700 (PDT) To: f-cpu@seul.org Received: from [24.93.116.191] by bravenet.com with HTTP From: e-lottoticket@columbus.rr.com Subject: [f-cpu] All new Way to play and Win........... MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--bravenet_list_id_2568_2" X-ListID: 2568 X-Groupnum: 2 X-IPAddy: 24.93.116.191 X-Usernum: 118107732 Message-Id: <20020827031629.4D1DB9BCAB@list2.bravenet.com> Date: Mon, 26 Aug 2002 20:16:29 -0700 (PDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ----bravenet_list_id_2568_2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Update....Multi state Lotteries.....Update Jackpots are up and so are your ways of playing for Realtime Money in Real Time Games......Win money Playing against others in realtime modes........Most fun since I was a kid....All legal games of skill, choose your favorite.... http://e-lottoticket.com e-lottoticket.com does not sell, share, or give out e-mail addresses for any reason, you can rest assured that we will not send junk mail trying to sell you something. Get more than 25 tools for your website WITHOUT ads. Summer Special: 25% OFF! http://linktrack.bravenet.com/o.php?id=3D705 ----bravenet_list_id_2568_2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html
3D"All
All New Way To Play For Real Time Money
 
">August 26, 2002   Keeping you up-to-date on the Big Jackpots!
Mega Millions Jackpot at 105 Million for Tuesday Drawing
Mega Millions, formerly known as The Big Game, changed its name in May when New York and Ohio joined seven other states: Georgia, Illinois, Maryland, Massachusetts, Michigan, Virginia and New Jersey. The game was created in 1996. Washington State will join in the fun on Sept 6th.



 

PowerBall, 55 Million For Wednesday Drawing
No one hit the Powerball on Sat. Jackpot moves to 55 Million.

 
........Visit e-lottoticket.com for your chance to win........
All new Way to Win Big in Real Time Play...

 
3D""
The Big Game News

No Jackpot winner Friday, click here for drawing results.

Powerball Update

Powerball Jackpot
Click Here for details

Get your Shot at RealTime Money........

All New Real Time Skill Games For Real Time Money
Click Here

You don't have to be left out anymore!!!!!

  http://e-lottoticket.com
----bravenet_list_id_2568_2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Aug 27 11:31:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1oq-0000Fx-01 for ; Wed, 28 Aug 2002 14:21:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:08 +0200 (CEST) Received: (qmail 25590 invoked by uid 0); 27 Aug 2002 09:35:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 27 Aug 2002 09:35:55 -0000 Received: by moria.seul.org (Postfix) id C7D4715E741; Tue, 27 Aug 2002 05:35:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AC1BA15E744; Tue, 27 Aug 2002 05:35:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 59D7E15E741 for ; Tue, 27 Aug 2002 05:35:54 -0400 (EDT) Received: from hli (80.15.61.167) by smtp.laposte.net (6.0.053) id 3D2EB28C002ADD73 for f-cpu@seul.org; Tue, 27 Aug 2002 11:35:53 +0200 Message-ID: <001501c24dac$960f6460$a73d0f50@hli> From: "Christophe Avoinne" To: References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> <1030410212.3d6acfe45bf20@imp.free.fr> Subject: Re: [f-cpu] Conditionnal load and store, the return Date: Tue, 27 Aug 2002 11:31:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Tuesday, August 27, 2002 3:03 AM Subject: Re: [f-cpu] Conditionnal load and store, the return > > load the data ? what data ? the conditional load only to need access > > to memory if condition is true, so even an exception occurs, when > > reexecuting the faulty instruction, all is okay. Same thing for the > > conditional store. > > So i don't see any problem. > > You will not reexecute it. I mean the conditionnal store on wich we > discuss test if the condition register is zero or not, or if the lsb/msb > if zero or not and if the test is true, the write is done. If you load > a data conditionnaly, if the address isn't ok, and the test is false, no > exeption must occur and it's where the problem is. > 'load' : you mean you always load the value from memory and assign the value to the data register only if test is succeeded ? well, if so, an exception will occur before any test anyway. But you still must reexecute. Page fault exception must point on the faulty instruction and must resume the faulty instruction since we suppose we've just resolved the fault, so the program can continue as if there was no fault. It is the behavior you will find on all CPU for mmu management. Otherwise, you wouldn't be able to virtualize memory. But if you only access memory just after the test succeeds, an exception will occur and still you need to rexecute the instruction. So there is no problem for me because when resuming from a page fault exception, you must reexecute the faulty instruction. It cannot be otherwise. 'store' : you cannot store the value of a data register until the test succeeds. So an exception only can happen after a succeeded test. Anyway, if an exception occurs, all operation must abort, because it would be resumed once exiting exception. Because your instruction has no internal state. You cannot use partial execution with exception. After an exception occurs, you cannot finish an instruction by resuming partial execution : you need to reexecute the instruction. > > Again, I don't see any problem. > > Currently if you have this : > > [DATA] > | > [CPU 1]---[CPU 2] > > > When CPU2 do a conditional load/Store pair, it will not be abble to see > if CPU 1 access to the data. The only reason why CPU 2 know that, is because > all memory access will always be send to CPU 2 by CPU 1... It can be a > big overkill. I perhaps miss something but the problem exist. Ok you are speaking about inter-cpu locking, not intra-cpu locking. Well of course it is the most difficult problem to solve. CPU1 and CPU2 can access directly to DATA, because they both have a different LSU we are stuck. In fact, the problem only occurs when you want a bi-processor or more, so I think you an extra stuff to allow global locking of data between CPU. I suppose you want several CPU able to access the same DATA directly : CPU1------------------\ CPU2------------------+------DATA CPU3------------------+ CPU4------------------/ You need a bridge to access DATA for all CPU. It cannot be possible for all CPU to access DATA meanwhile. Just an idea : beside the LSU for each CPU (internal LSU), we can have a external LSU which only contains the locked entries : if a CPU do normal load/store, just bypass external LSU : faster behavior. if a CPU do lock load, set a new entry in external LSU. if a CPU do lock store, check if entry is in external LSU. This external LSU can be seen as a special memory. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Aug 27 15:43:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1ox-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:15 +0200 (CEST) Received: (qmail 5603 invoked by uid 0); 27 Aug 2002 13:45:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 27 Aug 2002 13:45:18 -0000 Received: by moria.seul.org (Postfix) id 251A615E743; Tue, 27 Aug 2002 09:45:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0AC8B15E747; Tue, 27 Aug 2002 09:45:16 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 127CF15E743 for ; Tue, 27 Aug 2002 09:45:16 -0400 (EDT) Received: (qmail 48552 invoked by uid 85); 27 Aug 2002 13:38:56 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 1.106826 secs); 27 Aug 2002 13:38:56 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 27 Aug 2002 13:38:55 -0000 Message-ID: <3D6B820F.2080109@yahoo.fr> Date: Tue, 27 Aug 2002 15:43:43 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Cc: f-cpu_france@april.org Subject: [f-cpu] Web and webmaster Synthesis (and end ?) References: <3D44F7FD.6040607@yahoo.fr> Content-Type: multipart/alternative; boundary="------------080706070708040001070401" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --------------080706070708040001070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The french version can be found at the end of the message Hello everybody, This subject seems not interresting lot of peoples, then I propose to close it. First, summary of job for the webmaster (or webmistress ;-)): * Site maintenance (like broken links, look & feel, update, and perhaps cvs management too) * He can delegate some part of job, but he can impose the format (like html, php, dacode...) * If a web team is created, he must follow the state of the work, and manage the team. * When a new look and feel, a new section, a major modification on the site must be made, he must launch the discussion on the f-cpu mailing list, organize the pools and synthesize result. * He must speak [dixit Michael] (and more write[dixit Just an Illusion]) in english * The web site musn't move against [dixit Michael], and it must be seul.org [dixit Cédric Bail] Until now, only Samuel Desseaux have been contact me (by private mail) to confirm me than he was interresting to keep in charge of the web site (to do every things). He have an idea for the new web structure and only wait a decision from the list to begin real job. Perhaps he can present his idea himself ? (to you Samuel) If no body have additionnal comments, perhaps it's time to make a pool to declare Samuel like new webmaster (I don't know if seul.org have an embedded system to make pool, Whygee ?), or Whygee (like moderator) can send a global message to declare Samuel like new Webmaster (if no body want the pool). SeeYa, Just an Illusion ************************** Bonjour tout le monde, Au vu du nombre de réaction, le sujet ne semble pas passionner les foules. Je propose donc que nous le cloturions. Premièrement un résumé des tâches du (ou de la ;-)) webmestre : * Maintenance du site * En cas de travail en équipe, choix du format des pages, et rôle de manager de l'équipe. * C'est de lui qu'emmaneront les proposition d'évolution, les proposition de nouvelles rubriques, il organisera les votes et les synthèses. * Il doit parlet [dixit Michael] (et écrire biensûre [dixit Just an Illusion]) anglais * L'adresse du site ne doit pas à nouveau changer [dixit Michael], et se doit être seul.org [dixit Cédric Bail] Jusqu'à maintenant, seul Samuel Desseaux m'a contacté (par courrier privé) qu'il était interressé pour prendre en charge tout le site. Il a déjà une idée pour l'infrastructure, mais attends une décission de la liste pour commencé à réellement travaillé. Peut-être peut-il présenté lui-même son idée ? (à toi d'agir Samuel) Si personne n'a de remarque complémentaire, il est peut-être temps de voter pour confier à Samuel le développement du site (je ne sais pas si seul.org propose un système pour les votes, Whygee ?), ou bien Whygee (en tant que moderateur) peut envoyer un message général pour signaler que Samuel sera le nouveau webmestre avec en charge le developpement du nouveau site (si personne ne veut du vote). > > To define the job, I give you some possible point : > * Site maintenance (like broken links, look & feel, update, and > perhaps cvs management too) > * He can delegate some part of job, but he can impose the format > (like html, php, dacode...) > * If a web team is created, he must follow the state of the work, > and manage the team. > * When a new look and feel, a new section, a major modification on > the site must be made, he must launch the discussion on the f-cpu > mailing list, organize the pools and synthesize result. > > If you want add something, do it. > > Until now, Whygee have communicate me the following list of name > (people who have propose their services for the web site developpement) : > -"Cedric De Wilde" who have proposing the daCode > version. > -"Pablo Belin" who have made the Who's Who > -"Paul Marques Mota" who give help about server problems > -"Samuel Desseaux" who propose a php version of the > site. > > If this people accept to keep in charge of the site developpement, > I'll propose than they can submit their application. > If others people want submit their application too, do it. > > I propose to close the discussion during the third week of august (I > gooing in holidays at the end of the week, and I have no access to my > account before the 19th august). > > The future webmaster can be named by a pool, after the canditature > collection. > > Cheers, > Just an Illusion > > PS : About the web site content, the proposal can be made too. > > ************************** > > Bonjour tout le monde, > > Une partie des membres parisiens du f-cpu se sont réunis la semaine > dernière, pour faire un point sur l'avancé du projet. > Il semble que nous avons, nous aurons, un problème avec le site web. > > Actuellement, Whygee s'occupe d'organiser cela, mais il désire ne plus > avoir à le faire. > > Parce que certaines personnes ne semble pas avoir envie de développer > le code vhdl, ou le soft nécessaire, nous leurs faisons une > proposition, s'ils peuvent développer le site. > > Nous recherchons un nouveau webmestre (pour remplacer whygee) > > Voici quelques point pour illuster son rôle possible : > * Maintenance du site > * En cas de travail en équipe, choix du format des pages, et rôle de > manager de l'équipe. > * C'est de lui qu'emmaneront les proposition d'évolution, les > proposition de nouvelles rubriques, il organisera les votes et les > synthèses. > > Si vous avez d'autres propositions, faites le. > > Voici une liste de personnes que Whygee m'a communiqué qui ont proposé > leurs services pour le développement du site. > - "Cedric De Wilde" qui a fait le proposition du > site en daCode > - pablo.belin@free.fr (ABUL) qui a fait un Who's Who. > - Paul Marques Mota qui peut parfois aider pour les > histoires de serveurs. > - "samuel desseaux" qui propose une version php du > site > > Si ces personnes veulent prendre en charge le développement, qu'ils > proposent leurs candidatures > Si d'autres personnes veulent se proposer, qu'ils le fassent. > > Je propose de conclure cette discussion la 3e semaine d'août (je pars > en vacances en fin de semaine, et je n'aurais pas accées à mon compte > d'ici le 19) > > Le nouveau webmestre pourra être désigné par un vote, aprés la > collecte des candidatures. > > @+ > Just an Illusion > > PS : Pour le contenu du site, faites aussi des propositions. > --------------080706070708040001070401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The french version can be found at the end of the message

Hello everybody,

This subject seems not interresting lot of peoples, then I propose to close it.

First, summary of  job for the webmaster (or webmistress ;-)):

    * Site maintenance (like broken links, look & feel, update, and perhaps cvs management too)
    * He can delegate some part of job, but he can impose the format (like html, php, dacode...)
    * If a web team is created, he must follow the state of the work, and manage the team.
    * When a new look and feel, a new section, a major modification on the site must be made, he must launch the discussion on the f-cpu mailing list, organize the pools and synthesize result.
    * He must speak [dixit Michael] (and more write[dixit Just an Illusion]) in english
    * The web site musn't move against [dixit Michael], and it must be seul.org [dixit Cédric Bail]

Until now, only Samuel Desseaux have been contact me (by private mail) to confirm me than he was interresting to keep in charge of the web site (to do every things). He have an idea for the new web structure and only wait a decision from the list to begin real job.
Perhaps he can present his idea himself ? (to you Samuel)

If no body have additionnal comments, perhaps it's time to make a pool to declare Samuel like new webmaster (I don't know if seul.org have an embedded system to make pool, Whygee ?), or Whygee (like moderator) can send a global message to declare Samuel like new Webmaster (if no body want the pool).

SeeYa,
Just an Illusion

**************************

Bonjour tout le monde,

Au vu du nombre de réaction, le sujet ne semble pas passionner les foules. Je propose donc que nous le cloturions.

Premièrement un résumé des tâches du (ou de la ;-)) webmestre :

   * Maintenance du site
   * En cas de travail en équipe, choix du format des pages, et rôle de manager de l'équipe.
   * C'est de lui qu'emmaneront les proposition d'évolution, les proposition de nouvelles rubriques,  il organisera les votes et les synthèses.
    * Il doit parlet [dixit Michael] (et écrire biensûre [dixit Just an Illusion]) anglais
    * L'adresse du site ne doit pas à nouveau changer [dixit Michael], et se doit être seul.org [dixit Cédric Bail]

Jusqu'à maintenant, seul Samuel Desseaux m'a contacté (par courrier privé) qu'il était interressé pour prendre en charge tout le site. Il a déjà une idée pour l'infrastructure, mais attends une décission de la liste pour commencé à réellement travaillé.
Peut-être peut-il présenté lui-même son idée ? (à toi d'agir Samuel)

Si personne n'a de remarque complémentaire, il est peut-être temps de voter pour confier à Samuel le développement du site (je ne sais pas si seul.org propose un système pour les votes, Whygee ?), ou bien Whygee (en tant que moderateur) peut envoyer un message général pour signaler que Samuel sera le nouveau webmestre avec en charge le developpement du nouveau site (si personne ne veut du vote).



To define the job, I give you some possible point :
    * Site maintenance (like broken links, look & feel, update, and perhaps cvs management too)
    * He can delegate some part of job, but he can impose the format (like html, php, dacode...)
    * If a web team is created, he must follow the state of the work, and manage the team.
    * When a new look and feel, a new section, a major modification on the site must be made, he must launch the discussion on the f-cpu mailing list, organize the pools and synthesize result.

If you want add something, do it.

Until now, Whygee have communicate me the following list of name (people who have propose their services for the web site developpement) :
-"Cedric De Wilde" <daique@skynet.be> who have proposing the daCode version.
-"Pablo Belin" <pablo.belin@free.fr> who have made the Who's Who
-"Paul Marques Mota" <mota@april.org> who give help about server problems
-"Samuel Desseaux"<sdesseaux@free.fr> who propose a php version of the site.

If this people accept to keep in charge of the site developpement, I'll propose than they can submit their application.
If others people want submit their application too, do it.

I propose to close the discussion during the third week of august (I gooing in holidays at the end of the week, and I have no access to my account before the 19th august).

The future webmaster can be named by a pool, after the canditature collection.

Cheers,
Just an Illusion

PS : About the web site content, the proposal can be made too.

**************************

Bonjour tout le monde,

Une partie des membres parisiens du f-cpu se sont réunis la semaine dernière, pour faire un point sur l'avancé du projet.
Il semble que nous avons, nous aurons, un problème avec le site web.

Actuellement, Whygee s'occupe d'organiser cela, mais il désire ne plus avoir à le faire.

Parce que certaines personnes ne semble pas avoir envie de développer le code vhdl, ou le soft nécessaire, nous leurs faisons une proposition, s'ils peuvent développer le site.

Nous recherchons un nouveau webmestre (pour remplacer whygee)

Voici quelques point pour illuster son rôle possible :
  * Maintenance du site
  * En cas de travail en équipe, choix du format des pages, et rôle de manager de l'équipe.
  * C'est de lui qu'emmaneront les proposition d'évolution, les proposition de nouvelles rubriques,  il organisera les votes et les synthèses.

Si vous avez d'autres propositions, faites le.

Voici une liste de personnes que Whygee m'a communiqué qui ont proposé leurs services pour le développement du site.
- "Cedric De Wilde" <daique@skynet.be> qui a fait le proposition du site en daCode
- pablo.belin@free.fr (ABUL) qui a fait un Who's Who.
- Paul Marques Mota <mota@april.org> qui peut parfois aider pour les histoires de serveurs.
- "samuel desseaux" <sdesseaux@free.fr> qui propose une version php du site

Si ces personnes veulent prendre en charge le développement, qu'ils proposent leurs candidatures
Si d'autres personnes veulent se proposer, qu'ils le fassent.

Je propose de conclure cette discussion la 3e semaine d'août (je pars en vacances en fin de semaine, et je n'aurais pas accées à mon compte d'ici le 19)

Le nouveau webmestre pourra être désigné par un vote, aprés la collecte des candidatures.

@+
Just an Illusion

PS : Pour le contenu du site, faites aussi des propositions.


--------------080706070708040001070401-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Aug 27 22:40:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1pE-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:32 +0200 (CEST) Received: (qmail 7268 invoked by uid 0); 27 Aug 2002 20:18:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 27 Aug 2002 20:18:22 -0000 Received: by moria.seul.org (Postfix) id BD88B15E745; Tue, 27 Aug 2002 16:18:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90F0615E749; Tue, 27 Aug 2002 16:18:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 412BB15E745 for ; Tue, 27 Aug 2002 16:18:21 -0400 (EDT) Received: from ifrance.com (vlt6-85.n.club-internet.fr [194.158.119.85]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 627B916CF for ; Tue, 27 Aug 2002 22:17:48 +0200 (CEST) Message-ID: <3D6BE3CE.FB0A3B75@ifrance.com> Date: Tue, 27 Aug 2002 22:40:46 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] TLB resume References: <200208070229.09431.cedric.bail@free.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N cedric a écrit : > > Here is an extract from the TLB discussion that append one month ago. > > Michael propose this : > " > I've been thinking about the TLB before; IMHO, we need at least the > following (assuming bits for the page offset): > > - virtual address (64- bits) > - physical address (64- bits) > - address space identifier (ASI; 8 bits was suggested) > - supervisor access rights (RWX, 3 bits) > - user access rights (RWX, 3 bits) > - valid bit (indicating that the entry is valid) > - dirty bit (indicating that the page has been written to) > - used bit (indicating that the page has been accessed) > > - page size (4K << size, 6 bits) -> too much ? > " > > "present bits" has been removed because it's only needed by HW TLB after the > discussion. I hope I have maid a good resume, but if someone want to add > something, before I add this to the manual (perhaps we must clarify how to > access it before). > > Cedric So to resume one more time every one is ok with that.Christophe think it's better to use supervisor right, so why not ! (just one question : we want to avoid that user could give kernel adresse to OS call, so we want to put no-read bit on kernel data page, so how the kernel could read it's own pages ?) For the page size, 4k << size is a little bit too much. I prefer something like previously said: - tiny for message passing ~4Ko - usual page for program 64~256 Kb - For kernel, frame buffer 4-64 Mb - udge for data base,... 256-1024 Mb I propose to not fixed the size now but let it to be defined "later". Could Cédric put that in the manual ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Aug 28 01:34:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17k1pf-0000Fx-00 for ; Wed, 28 Aug 2002 14:21:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 Aug 2002 14:21:59 +0200 (CEST) Received: (qmail 7202 invoked by uid 0); 27 Aug 2002 23:34:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 27 Aug 2002 23:34:30 -0000 Received: by moria.seul.org (Postfix) id D52D315E748; Tue, 27 Aug 2002 19:34:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCECA15E74D; Tue, 27 Aug 2002 19:34:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 706F315E748 for ; Tue, 27 Aug 2002 19:34:29 -0400 (EDT) Received: from ifurita (80.15.61.125) by smtp.laposte.net (6.0.053) id 3D359CE900269A81 for f-cpu@seul.org; Wed, 28 Aug 2002 01:34:28 +0200 Message-ID: <004b01c24e22$4911c0b0$0100000a@ifurita> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] Conditionnal load and store, the return Date: Wed, 28 Aug 2002 01:34:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Tuesday, August 27, 2002 2:33 PM Subject: Re: [f-cpu] Conditionnal load and store, the return > > But if you only access memory just after the test succeeds, an > > exception will occur and still you need to rexecute the instruction. > > And what append if you point to NULL and the test is false ? You can't > reexecute it and never. So what did you do ? > Hey did you ever program a page fault exception ? by default the last IP (or PC) when a page fault occurs is pointed on the faulty instruction so we can resume - BY DEFAULT - with the faulty instruction. It is up to the exception handler to determine if it must resume or kill the process !!! so if you encounter a NULL either you just need change the IP (or PC) to call a user exception (signal in Unix) or just kill the process. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Aug 28 16:19:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbF-0000F4-01 for ; Thu, 29 Aug 2002 18:56:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:56:53 +0200 (CEST) Received: (qmail 8340 invoked by uid 0); 28 Aug 2002 15:17:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 28 Aug 2002 15:17:28 -0000 Received: by moria.seul.org (Postfix) id 3E9D515E757; Wed, 28 Aug 2002 11:17:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0295F15E75B; Wed, 28 Aug 2002 11:17:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 7046815E757 for ; Wed, 28 Aug 2002 11:17:26 -0400 (EDT) Received: from laposte.net (193.250.226.171) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB3A2003394AB for f-cpu@seul.org; Wed, 28 Aug 2002 17:17:25 +0200 Message-ID: <3D6CDBD4.9020004@laposte.net> Date: Wed, 28 Aug 2002 16:19:00 +0200 From: Lavergne Thomas Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; fr-FR; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr, fr-fr, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] Correction for manual 0.2.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Some little errors in the manual : Page 116-119 : shiftr, shiftra, rotl, rotr The h postfix was not described on top of page Page 123 : rotli The table indicate a half-simd flag, is it good or is it a copy-past error ? (shift with imm does not have it) Page 126 : bitopi This instruction does use a standard format, it use a 6 bit constant. Page 131 : dbitrev The text specifie that the SIMD flag was not used but it was indicated at top and in the table. Page 133 : dhiftl Use the opcode of shiftl instead of his own opcode. Page 137-138 : shiftra, shiftrai These two instructions was already defined in the preceding section of the manual. Page 142 : logic The bit oreder was not reversed. Page 174 : move The bit oreder was not reversed. Page 186 : loadaddr The bit oreder was not reversed. Page 187 : loadaddri How the S flag is specified in the asm ? With a "s" postfix ? -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 28 18:23:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbH-0000F4-01 for ; Thu, 29 Aug 2002 18:56:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:56:55 +0200 (CEST) Received: (qmail 337 invoked by uid 0); 28 Aug 2002 16:23:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 28 Aug 2002 16:23:13 -0000 Received: by moria.seul.org (Postfix) id 136E515E736; Wed, 28 Aug 2002 12:23:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D24C315E75D; Wed, 28 Aug 2002 12:23:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 1D7B915E736 for ; Wed, 28 Aug 2002 12:23:10 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208281623.0257; Wed, 28 Aug 2002 16:23:02 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] tlb last ! (secure bit, lib ring) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Aug 2002 16:23:02 GMT Message-id: <200208281623.0257@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I forgot to add for the tlb, the tagged region. - So one more bit in the tlb ("secure bit"). - split the load&store in normal and secure one (to access t= he secure area). Maybe we could have one user secure bit and one superuser se= cure bit. [That's mainly to definitely protect the return stack from b= uffer overflow. return stack are on a secure area, and buffer are = only managed by normal load&store. Only fonction pointer are now a proble= m : this could be solve with the use of a new ring to protect excve ?= (that's means that to access excve a kind of trap must occur which i= s a very different thing compare to a typical function call)] [Maybe rwx right for this new (lib ?) ring could be added, t= oo.] nicO ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Aug 29 00:11:07 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbI-0000F4-00 for ; Thu, 29 Aug 2002 18:56:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:56:56 +0200 (CEST) Received: (qmail 23301 invoked by uid 0); 28 Aug 2002 17:11:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 28 Aug 2002 17:11:10 -0000 Received: by moria.seul.org (Postfix) id F33D815E763; Wed, 28 Aug 2002 13:11:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E725815E765; Wed, 28 Aug 2002 13:11:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id AAB7315E761 for ; Wed, 28 Aug 2002 13:11:08 -0400 (EDT) Received: from club-internet.fr (flashmail-3m.cs.clubint.net [172.16.20.62]) by relay-1m.club-internet.fr (Postfix) with SMTP id 084E916D2 for ; Wed, 28 Aug 2002 19:11:07 +0200 (CEST) Received: from [212.43.214.31] by flashmail-3m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) Date: Wed, 28 Aug 2002 19:11:07 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N nicO =3D The Lord of the Ring(s) ? :-) this thread is looking (at least to me, i don't speak for other lurkers) like it's going in endless circles. Sure, F-CPU was not designed for security in the beginning, and it's probably the right time to address this issue. But remember that it must remain simple, and what is simple for you might be out of reach for many people. i'll adopt a =22middle=22 behaviour : TLB format can be user-defined until F-CPU v1 is frozen. Though my new job at http://www.artabel.net/ might slow the process. All i want it something that works (and i'm not alone). I don't need a Hurd-like project. /me ---> /home/bed. ----Message d'origine---- >Sujet: =5Bf-cpu=5D tlb last =21 (secure bit, lib ring) >De: =22Nicolas Boulay=22 > >I forgot to add for the tlb, the tagged region. >- So one more bit in the tlb (=22secure bit=22). >- split the load&store in normal and secure one (to access the secure >area). > >Maybe we could have one user secure bit and one superuser secure bit. > >=5BThat's mainly to definitely protect the return stack from buffer >overflow. return stack are on a secure area, and buffer are only managed >by normal load&store. Only fonction pointer are now a problem : this >could be solve with the use of a new ring to protect excve ? (that's >means that to access excve a kind of trap must occur which is a very >different thing compare to a typical function call)=5D > >=5BMaybe rwx right for this new (lib ?) ring could be added, too.=5D > >nicO > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F >Pour mieux recevoir vos emails, utilisez un PC plus performant =21 >D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (france) >http://www.ifrance.com/=5Freloc/signhdell > >************************************************************* >To unsubscribe, send an e-mail to majordomo=40seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Aug 28 20:45:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSba-0000F4-00 for ; Thu, 29 Aug 2002 18:57:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:14 +0200 (CEST) Received: (qmail 17840 invoked by uid 0); 28 Aug 2002 18:22:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 28 Aug 2002 18:22:19 -0000 Received: by moria.seul.org (Postfix) id 0907815E762; Wed, 28 Aug 2002 14:22:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF84015E768; Wed, 28 Aug 2002 14:22:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E8BCB15E762 for ; Wed, 28 Aug 2002 14:22:16 -0400 (EDT) Received: from ifrance.com (vlt4-159.n.club-internet.fr [194.158.109.159]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 8ABA616A7 for ; Wed, 28 Aug 2002 20:22:14 +0200 (CEST) Message-ID: <3D6D1A51.7E19FE91@ifrance.com> Date: Wed, 28 Aug 2002 20:45:37 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr a écrit : > > nicO = The Lord of the Ring(s) ? :-) > > this thread is looking (at least to me, i don't > speak for other lurkers) like it's going in endless > circles. really no comment... > > Sure, F-CPU was not designed for security in the > beginning, and it's probably the right time to address > this issue. But remember that it must remain simple, > and what is simple for you might be out of reach > for many people. > Simple ? Or that *you* understand ? > i'll adopt a "middle" behaviour : TLB format can > be user-defined until F-CPU v1 is frozen. Though my > new job at http://www.artabel.net/ might slow the process. > I think that the discussion. Is quite closed. I'm ok for rwx right for supervisor. I hope "s" bits will bit used, too (We should have a secure jump, too. Don't you think ?). Any comment ? nicO > All i want it something that works (and i'm not alone). > I don't need a Hurd-like project. > > /me ---> /home/bed. > > ----Message d'origine---- > >Sujet: [f-cpu] tlb last ! (secure bit, lib ring) > >De: "Nicolas Boulay" > > > >I forgot to add for the tlb, the tagged region. > >- So one more bit in the tlb ("secure bit"). > >- split the load&store in normal and secure one (to access the secure > >area). > > > >Maybe we could have one user secure bit and one superuser secure bit. > > > >[That's mainly to definitely protect the return stack from buffer > >overflow. return stack are on a secure area, and buffer are only managed > >by normal load&store. Only fonction pointer are now a problem : this > >could be solve with the use of a new ring to protect excve ? (that's > >means that to access excve a kind of trap must occur which is a very > >different thing compare to a typical function call)] > > > >[Maybe rwx right for this new (lib ?) ring could be added, too.] > > > >nicO > > > > > >______________________________________________________________________________ > >Pour mieux recevoir vos emails, utilisez un PC plus performant ! > >Découvrez la nouvelle gamme DELL en exclusivité sur i (france) > >http://www.ifrance.com/_reloc/signhdell > > > >************************************************************* > >To unsubscribe, send an e-mail to majordomo@seul.org with > >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 28 22:08:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbd-0000F4-00 for ; Thu, 29 Aug 2002 18:57:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:17 +0200 (CEST) Received: (qmail 14784 invoked by uid 0); 28 Aug 2002 19:58:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 28 Aug 2002 19:58:13 -0000 Received: by moria.seul.org (Postfix) id 3E42715E765; Wed, 28 Aug 2002 15:58:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23D7715E769; Wed, 28 Aug 2002 15:58:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id A4BD815E765 for ; Wed, 28 Aug 2002 15:58:11 -0400 (EDT) Received: from f-cpu.org (kdl11-180.n.club-internet.fr [213.44.9.180]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 0E23716B3 for ; Wed, 28 Aug 2002 21:58:09 +0200 (CEST) Message-ID: <3D6D2DC5.B8D2D8D5@f-cpu.org> Date: Wed, 28 Aug 2002 22:08:37 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) References: <3D6D1A51.7E19FE91@ifrance.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, nico wrote: > whygee@club-internet.fr a écrit : > > i'll adopt a "middle" behaviour : TLB format can > > be user-defined until F-CPU v1 is frozen. Though my > > new job at http://www.artabel.net/ might slow the process. > > I think that the discussion. Is quite closed. I'm ok for rwx right for > supervisor. I hope "s" bits will bit used, too (We should have a secure > jump, too. Don't you think ?). > > Any comment ? whenever i come to the point of writing the TLB source (unless someone else does it before), i'll make most things user-defined. If someone wants some more bits, then he'll add them. that's what i call "simple" (at least temporarily). 'night, > nicO WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 28 22:10:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbd-0000F4-01 for ; Thu, 29 Aug 2002 18:57:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:17 +0200 (CEST) Received: (qmail 15494 invoked by uid 0); 28 Aug 2002 20:00:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 28 Aug 2002 20:00:36 -0000 Received: by moria.seul.org (Postfix) id B66B415E767; Wed, 28 Aug 2002 16:00:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85DE015E76A; Wed, 28 Aug 2002 16:00:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 089FB15E767 for ; Wed, 28 Aug 2002 16:00:33 -0400 (EDT) Received: from f-cpu.org (kdl11-180.n.club-internet.fr [213.44.9.180]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 80F2C16EA for ; Wed, 28 Aug 2002 22:00:30 +0200 (CEST) Message-ID: <3D6D2E52.EC2F4A26@f-cpu.org> Date: Wed, 28 Aug 2002 22:10:58 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 References: <3D6CDBD4.9020004@laposte.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Lavergne Thomas wrote: > > Some little errors in the manual : > Page 126 : bitopi > > This instruction does use a standard format, it use > a 6 bit constant. maybe it will be dropped... > Page 142 : logic > > The bit oreder was not reversed. because Cédric waits for my patch (damned lazy me). i wish i'll sort the job things out and find some time to "get back to the source". > Thomas Lavergne WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 28 23:10:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbe-0000F4-01 for ; Thu, 29 Aug 2002 18:57:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:18 +0200 (CEST) Received: (qmail 12056 invoked by uid 0); 28 Aug 2002 21:10:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 28 Aug 2002 21:10:45 -0000 Received: by moria.seul.org (Postfix) id BC3C615E76B; Wed, 28 Aug 2002 17:10:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8FC4F15E76E; Wed, 28 Aug 2002 17:10:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id 01C9215E76B for ; Wed, 28 Aug 2002 17:10:43 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix3-1.free.fr (Postfix) with ESMTP id 01C31D9E9A for ; Wed, 28 Aug 2002 23:10:41 +0200 (MEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id BE3FD87356; Wed, 28 Aug 2002 23:10:41 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 Message-ID: <1030569041.3d6d3c51b2b16@imp.free.fr> Date: Wed, 28 Aug 2002 23:10:41 +0200 (MEST) From: Cedric BAIL References: <3D6CDBD4.9020004@laposte.net> In-Reply-To: <3D6CDBD4.9020004@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.12.157.63 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Nice, somebody read the manual ;-) > Some little errors in the manual : > > Page 116-119 : shiftr, shiftra, rotl, rotr > The h postfix was not described on top of page > > Page 123 : rotli > > The table indicate a half-simd flag, is it good > or is it a copy-past error ? > (shift with imm does not have it) Sorry it's a copy past error. > Page 126 : bitopi > > This instruction does use a standard format, it use > a 6 bit constant. I know it's a problem, I don't know if I must add a new form or something else. > Page 131 : dbitrev > > The text specifie that the SIMD flag was not used > but it was indicated at top and in the table. It's for orthogonality > Page 133 : dhiftl > > Use the opcode of shiftl instead of his own opcode. I know it will be fixed for next release (new format). > Page 137-138 : shiftra, shiftrai > > These two instructions was already defined in the > preceding section of the manual. > Page 142 : logic > > The bit oreder was not reversed. This instruction is not up to date, and I wait for an description from Whygee for it. > Page 174 : move > > The bit oreder was not reversed. > Page 186 : loadaddr > > The bit oreder was not reversed. > > Page 187 : loadaddri > > How the S flag is specified in the asm ? > With a "s" postfix ? Will be fixed for next release. Thanks for all this remarks. I am planing to release a new version of the manual during the second week of september. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Aug 28 23:15:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbf-0000F4-00 for ; Thu, 29 Aug 2002 18:57:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:19 +0200 (CEST) Received: (qmail 5798 invoked by uid 0); 28 Aug 2002 21:14:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 28 Aug 2002 21:14:02 -0000 Received: by moria.seul.org (Postfix) id DD38915E76C; Wed, 28 Aug 2002 17:14:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6A0015E76F; Wed, 28 Aug 2002 17:14:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 41CD315E76C for ; Wed, 28 Aug 2002 17:14:01 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix3-2.free.fr (Postfix) with ESMTP id 9AB3517E34 for ; Wed, 28 Aug 2002 23:14:00 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 6366AFC27; Wed, 28 Aug 2002 23:15:39 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return Message-ID: <1030569339.3d6d3d7b4bad3@imp.free.fr> Date: Wed, 28 Aug 2002 23:15:39 +0200 (MEST) From: Cedric BAIL References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> <1030410212.3d6acfe45bf20@imp.free.fr> <001501c24dac$960f6460$a73d0f50@hli> <1030451613.3d6b719d6eee5@imp.free.fr> <004b01c24e22$4911c0b0$0100000a@ifurita> In-Reply-To: <004b01c24e22$4911c0b0$0100000a@ifurita> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.12.157.63 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > > But if you only access memory just after the test succeeds, an > > > exception will occur and still you need to rexecute the instruction. > > > > And what append if you point to NULL and the test is false ? You can't > > reexecute it and never. So what did you do ? > > Hey did you ever program a page fault exception ? by default the last IP > (or PC) when a page fault occurs is pointed on the faulty instruction so we > can resume - BY DEFAULT - with the faulty instruction. It is up to the > exception handler to determine if it must resume or kill the process !!! so if > you encounter a NULL either you just need change the IP (or PC) to call a > user exception (signal in Unix) or just kill the process. The problem is that you didn't have any error in fact the test is false, so no real memory access are done. So you must not reexecute the instruction and only pass it even if the address is bad. It's were I see a problem, you execute a handler for nothing... A+ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 28 19:07:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbg-0000F4-00 for ; Thu, 29 Aug 2002 18:57:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:20 +0200 (CEST) Received: (qmail 21298 invoked by uid 0); 28 Aug 2002 21:21:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 28 Aug 2002 21:21:33 -0000 Received: by moria.seul.org (Postfix) id D294A15E770; Wed, 28 Aug 2002 17:21:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE03D15E773; Wed, 28 Aug 2002 17:21:32 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id 31FC615E770 for ; Wed, 28 Aug 2002 17:21:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00458; Wed, 28 Aug 2002 19:07:01 +0200 Message-ID: <20020828190701.42307@thrai.stud.uni-hannover.de> Date: Wed, 28 Aug 2002 19:07:01 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 References: <3D6CDBD4.9020004@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D6CDBD4.9020004@laposte.net>; from Lavergne Thomas on Wed, Aug 28, 2002 at 04:19:00PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 28, 2002 at 04:19:00PM +0200, Lavergne Thomas wrote: > Some little errors in the manual : > > Page 116-119 : shiftr, shiftra, rotl, rotr > > The h postfix was not described on top of page > > Page 123 : rotli > > The table indicate a half-simd flag, is it good > or is it a copy-past error ? > (shift with imm does not have it) Immediate shifts are *always* `half-simd' - that is, the same shift count is used for all chunks. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 28 19:13:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbg-0000F4-01 for ; Thu, 29 Aug 2002 18:57:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:20 +0200 (CEST) Received: (qmail 23108 invoked by uid 0); 28 Aug 2002 21:21:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 28 Aug 2002 21:21:38 -0000 Received: by moria.seul.org (Postfix) id 5E2E115E771; Wed, 28 Aug 2002 17:21:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3D3D415E775; Wed, 28 Aug 2002 17:21:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id E96A915E771 for ; Wed, 28 Aug 2002 17:21:32 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00477; Wed, 28 Aug 2002 19:13:44 +0200 Message-ID: <20020828191344.12214@thrai.stud.uni-hannover.de> Date: Wed, 28 Aug 2002 19:13:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) References: <200208281623.0257@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200208281623.0257@th00.opsion.fr>; from Nicolas Boulay on Wed, Aug 28, 2002 at 04:23:02PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 28, 2002 at 04:23:02PM +0000, Nicolas Boulay wrote: > I forgot to add for the tlb, the tagged region. > - So one more bit in the tlb ("secure bit"). > - split the load&store in normal and secure one (to access the secure > area). You better forget that idea soon. Tagged load&store doesn't help with security at all - you still have to scan the code for `illegal' stores, which is a pretty hard job. If it weren't, we could do it with regular stores as well and wouldn't need special instructions at all. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Wed Aug 28 23:42:09 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbh-0000F4-01 for ; Thu, 29 Aug 2002 18:57:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:21 +0200 (CEST) Received: (qmail 7517 invoked by uid 0); 28 Aug 2002 21:50:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 28 Aug 2002 21:50:56 -0000 Received: by moria.seul.org (Postfix) id BC1C615E774; Wed, 28 Aug 2002 17:50:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A358A15E777; Wed, 28 Aug 2002 17:50:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 5E1F115E774 for ; Wed, 28 Aug 2002 17:50:54 -0400 (EDT) Received: from laposte.net (193.250.154.21) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D2EB3A200340D54 for f-cpu@seul.org; Wed, 28 Aug 2002 23:50:53 +0200 Message-ID: <3D6D43B1.4040105@laposte.net> Date: Wed, 28 Aug 2002 23:42:09 +0200 From: Lavergne Thomas Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; fr-FR; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr, fr-fr, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 References: <3D6CDBD4.9020004@laposte.net> <1030569041.3d6d3c51b2b16@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Will be fixed for next release. > > Thanks for all this remarks. I am planing to release a new version of the > manual during the second week of september. > Good news, if you would, I could make a read of it and search for similar errors, before an official release. I known it was a difficult task to correct a manual so if you need help, ask me. Have you plan to split the manual in different book, like I've suggested in past. I think with 3 book, it was more easy to use : One for description and history, the first part of the actual manual, so we don't need it each time a new release was published. One for hardware description, part II, II and IV of the actual manual, mainly for HW guy, but also for SW. And last a book for the ISA. It was more easy to have different book when you search a thing, and if you make an asm prog you generaly use only the third book, if you want to present the F-Cpu at a new person you show it the book one in first time. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Aug 29 01:44:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbp-0000F4-01 for ; Thu, 29 Aug 2002 18:57:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:29 +0200 (CEST) Received: (qmail 30988 invoked by uid 0); 28 Aug 2002 23:44:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 28 Aug 2002 23:44:16 -0000 Received: by moria.seul.org (Postfix) id 7F64715E778; Wed, 28 Aug 2002 19:44:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4DF3F15E77B; Wed, 28 Aug 2002 19:44:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id EE3FD15E778 for ; Wed, 28 Aug 2002 19:44:14 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-1.free.fr (Postfix) with ESMTP id 54EA328 for ; Thu, 29 Aug 2002 01:44:14 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 428CE8C107; Thu, 29 Aug 2002 01:44:14 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 Message-ID: <1030578254.3d6d604e3bead@imp.free.fr> Date: Thu, 29 Aug 2002 01:44:14 +0200 (MEST) From: Cedric BAIL References: <3D6CDBD4.9020004@laposte.net> <1030569041.3d6d3c51b2b16@imp.free.fr> <3D6D43B1.4040105@laposte.net> In-Reply-To: <3D6D43B1.4040105@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.249.238.171 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > Will be fixed for next release. > > > > Thanks for all this remarks. I am planing to release a new version of the > > manual during the second week of september. > Good news, if you would, I could make a read of it and search for > similar errors, before an official release. I known it was a difficult > task to correct a manual so if you need help, ask me. I will not forget ;-) > Have you plan to split the manual in different book, like I've suggested > in past. I think with 3 book, it was more easy to use : > One for description and history, the first part of the actual manual, so > we don't need it each time a new release was published. > One for hardware description, part II, II and IV of the actual manual, > mainly for HW guy, but also for SW. > And last a book for the ISA. > It was more easy to have different book when you search a thing, and if > you make an asm prog you generaly use only the third book, if you want > to present the F-Cpu at a new person you show it the book one in first > time. For me it's not difficult to have many different book because each part are separated. So if you want a special book I only need the list of part you want in it. That's all. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Aug 29 11:42:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbu-0000F4-00 for ; Thu, 29 Aug 2002 18:57:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:34 +0200 (CEST) Received: (qmail 3685 invoked by uid 0); 29 Aug 2002 09:42:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 29 Aug 2002 09:42:15 -0000 Received: by moria.seul.org (Postfix) id 8218D15E751; Thu, 29 Aug 2002 05:42:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5984715E785; Thu, 29 Aug 2002 05:42:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id DD93315E751 for ; Thu, 29 Aug 2002 05:42:13 -0400 (EDT) Received: from ifurita (80.14.37.138) by smtp.laposte.net (6.0.053) id 3D2EB609003083A9 for f-cpu@seul.org; Thu, 29 Aug 2002 11:42:12 +0200 Message-ID: <00f601c24f40$5666bcb0$0100000a@ifurita> From: "Christophe Avoinne" To: References: <3D6D1A51.7E19FE91@ifrance.com> <3D6D2DC5.B8D2D8D5@f-cpu.org> Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) Date: Thu, 29 Aug 2002 11:42:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I'm confused. Sometimes I wonder if we are not mixing hardware and software TLB notions when speaking. Software TLB : It has very few valid entries. In fact it doesn't contain all the valid mapping of a space address. So I don't understand why we need user or extra bits since entries in TLB cannot be obviously persistent !!! it doesn't make sense for TLB to have invalid entries or of other kind, because it is not up to the TLB to handle the rest of entries but to a software dedicated to virtual memory [dixit Cédric ]. So my oppinion is that user or extra bits has no interest to be in TLB entries since they should be in fact handled by the software, not by the TLB. If I take the example of SH3, it has two TLBs, one for ICACHE, another for DCACHE. A valid entry in TLB associated with ICACHE has only X bit (equivalent to R bit for data) because the instruction fetcher never writes data. A valid entry in TLB associated with DCACHE has R and W bits, but not X bit because the data fetcher never executes an instruction. So if you intend to have a seperate TLB for ICACHE and DCACHE, it makes no sense to have a different bit for X and R IN THE TLB ENTRY. You want a general R,W,X with U/S pairing. Okay, but I still don't understand because it is up to the software to handle them and not to TLB. Take this example : One instruction raises a page fault exception. Ok, we know it is for a code page and not a data page, so we must deal with TLB for ICACHE (ITLB). Now our software dedicated to virtual memory tells us this faulty address is associated with a physical address and has UX bit set to 1 and SX to 0. Okay set UX to 1 and SX to 0 in the new ITLB entry, regardless with UR,UW,SR,SW since they are no interest for ITLB. One data read access raises a page fault exception. Ok, we know it is for a data page and not a code page, so we must deal with TLB for DCACHE (DTLB). Now our software dedicated to virtual memory tells us this faulty address is associated with a physical address and has UR,UW,SR and SW set to 1,0,1 and 1. okay, set UR,UW,SR and SW to 1,0,1 and 1 in the new DTLB entry, regardless with UX and SX. So my opinion is that : - from the viewpoint of software dedicated to virtual memory we have 6 bits to handle : ur,uw,ux,sr,sw,sx. But the programmer can choose the way to represent them since it is not a hardware point. - from the viewpoint of ITLB (TLB for ICACHE) we have only 2 bits to handle : ux,sx. They can be fix at the same bit position than ur,sr for DTLB entries, since ur,sr,sr,sw are absent for ITLB. - from the viewpoint of DTLB (TLB for DCACHE) we have only 4 bits to handle : ur,uw,sr,sw. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Aug 29 11:52:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSbw-0000F4-00 for ; Thu, 29 Aug 2002 18:57:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:36 +0200 (CEST) Received: (qmail 31819 invoked by uid 0); 29 Aug 2002 09:52:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 29 Aug 2002 09:52:48 -0000 Received: by moria.seul.org (Postfix) id 7014615E72E; Thu, 29 Aug 2002 05:52:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60A2B15E782; Thu, 29 Aug 2002 05:52:47 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 131B815E72E for ; Thu, 29 Aug 2002 05:52:47 -0400 (EDT) Received: from ifurita (80.14.37.138) by smtp.laposte.net (6.0.053) id 3D32A1F9002ADEF0 for f-cpu@seul.org; Thu, 29 Aug 2002 11:52:46 +0200 Message-ID: <010001c24f41$cfee88a0$0100000a@ifurita> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] Conditionnal load and store, the return Date: Thu, 29 Aug 2002 11:52:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Cedric BAIL" To: Sent: Wednesday, August 28, 2002 11:15 PM Subject: Re: [f-cpu] Conditionnal load and store, the return > The problem is that you didn't have any error in fact the test is false, so no > real memory access are done. So you must not reexecute the instruction and only > pass it even if the address is bad. It's were I see a problem, you execute a > handler for nothing... > 'loadCC' : If you access memory regardless the test result, yes you will raise an exception even for false test. Due to this design you need to delay the exception until the test is completed and is true. 'storeCC' : You should only access memory if the test succeeds so I don't see how an exception can be done when the test is false, since I suppose we only store in memory if the test is true. 'lload' : no problem. 'lstore' : same thoughts than 'storeCC'. You should really detail your explanation because I really don't see how you planned to execute 'loadCC' and 'storeCC' and find out that kind of problem. A+ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Thu Aug 29 15:42:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kSc1-0000F4-00 for ; Thu, 29 Aug 2002 18:57:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 29 Aug 2002 18:57:41 +0200 (CEST) Received: (qmail 11935 invoked by uid 0); 29 Aug 2002 13:55:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 29 Aug 2002 13:55:25 -0000 Received: by moria.seul.org (Postfix) id 9803A15E758; Thu, 29 Aug 2002 09:55:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B9B315E784; Thu, 29 Aug 2002 09:55:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2FBC815E758 for ; Thu, 29 Aug 2002 09:55:24 -0400 (EDT) Received: from laposte.net (193.250.154.91) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D359CE9002897AF for f-cpu@seul.org; Thu, 29 Aug 2002 15:55:23 +0200 Message-ID: <3D6E24C2.4010905@laposte.net> Date: Thu, 29 Aug 2002 15:42:26 +0200 From: Lavergne Thomas Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; fr-FR; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr, fr-fr, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] THasm 0.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I release a new workable assembler for the F-Cpu. Ok I known we already have an assembler in the yg and jws snapshot but I can't make them work correctly and these cover only a small part of the ISA. Why a new assembler ? -I love writting assembler and compiler and the first step was the assembler. -I would assemble the full ISA. -This assembler allow you to define encoding format and instruction in the asm file, they're not hardcoded in the program so if we make change in the ISA it was easy to update the assembler without need to recompile it. -I love some strange syntaxe construct in asm files. -I dislike C and prefere Pascal (ok I known a lot you disagree but I don't want to start a troll and I've provide binnaries) -I prefere use my own softwares ;-) Ok for the moment THasm have some lack but globaly it work and I've succesfully assembled some of my asm files. It was for the moment a proof-of-concept assembler, with some part very badly written and I probably need to rewrite all, but this version was just for test the concept and it works. You can define new encoding format or new instruction directly in your asm file so for ISA testing it could be very usefull. For the moment it does not have label handling, "db", "dw"... pseudo instruction and preprocessor, but this was added soon. You can get it on seul.org in my folder the zip file contain full source, file format documentation and windows binnaries. I'm sorry I don't provide linux binnaries for the moment because I need to redownload it and it was a huge file... I hope I could add it quickly. @+, Tom -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 29 14:25:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcep-00072u-00 for ; Fri, 30 Aug 2002 05:41:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:15 +0200 (CEST) Received: (qmail 14032 invoked by uid 0); 29 Aug 2002 17:38:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 29 Aug 2002 17:38:04 -0000 Received: by moria.seul.org (Postfix) id D73B415E784; Thu, 29 Aug 2002 13:38:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C878B15E787; Thu, 29 Aug 2002 13:38:03 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a052.home.uni-hannover.de [130.75.232.52]) by moria.seul.org (Postfix) with ESMTP id 11CF015E784 for ; Thu, 29 Aug 2002 13:38:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00559; Thu, 29 Aug 2002 14:25:13 +0200 Message-ID: <20020829142513.41226@thrai.stud.uni-hannover.de> Date: Thu, 29 Aug 2002 14:25:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) References: <3D6D1A51.7E19FE91@ifrance.com> <3D6D2DC5.B8D2D8D5@f-cpu.org> <00f601c24f40$5666bcb0$0100000a@ifurita> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <00f601c24f40$5666bcb0$0100000a@ifurita>; from Christophe Avoinne on Thu, Aug 29, 2002 at 11:42:05AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Aug 29, 2002 at 11:42:05AM +0200, Christophe Avoinne wrote: > Hi, > > I'm confused. > > Sometimes I wonder if we are not mixing hardware and software TLB notions > when speaking. > > Software TLB : > > It has very few valid entries. In fact it doesn't contain all the valid > mapping of a space address. So I don't understand why we need user or extra > bits since entries in TLB cannot be obviously persistent !!! it doesn't make > sense for TLB to have invalid entries or of other kind, because it is not up > to the TLB to handle the rest of entries but to a software dedicated to > virtual memory [dixit Cédric ]. So my oppinion is that user or extra bits > has no interest to be in TLB entries since they should be in fact handled by > the software, not by the TLB. Invalid entries don't make sense in a software-controlled TLB, that's right. But there will be permanent entries (e.g. for the system call entry point and the interrupt handlers). > If I take the example of SH3, it has two TLBs, one for ICACHE, another for > DCACHE. A valid entry in TLB associated with ICACHE has only X bit > (equivalent to R bit for data) because the instruction fetcher never writes > data. A valid entry in TLB associated with DCACHE has R and W bits, but not > X bit because the data fetcher never executes an instruction. So if you > intend to have a seperate TLB for ICACHE and DCACHE, it makes no sense to > have a different bit for X and R IN THE TLB ENTRY. > > You want a general R,W,X with U/S pairing. Okay, but I still don't > understand because it is up to the software to handle them and not to TLB. Access violations can (and will) be handled in software, but they can not be *detected* in software, unless you want to run an exception handler for *every* memory access. Note that the absence of a TLB entry means something different. And yes, we always want all three bits (rwx). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Aug 29 21:44:34 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcf9-00072u-00 for ; Fri, 30 Aug 2002 05:41:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:35 +0200 (CEST) Received: (qmail 23001 invoked by uid 0); 29 Aug 2002 19:44:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 29 Aug 2002 19:44:43 -0000 Received: by moria.seul.org (Postfix) id E69AA15E786; Thu, 29 Aug 2002 15:44:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A9E2815E78A; Thu, 29 Aug 2002 15:44:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 50CF515E786 for ; Thu, 29 Aug 2002 15:44:42 -0400 (EDT) Received: from ifurita (80.14.37.138) by smtp.laposte.net (6.0.053) id 3D2EB28C002E1984 for f-cpu@seul.org; Thu, 29 Aug 2002 21:44:41 +0200 Message-ID: <005301c24f94$808fd860$0100000a@ifurita> From: "Christophe Avoinne" To: References: <3D6D1A51.7E19FE91@ifrance.com> <3D6D2DC5.B8D2D8D5@f-cpu.org> <00f601c24f40$5666bcb0$0100000a@ifurita> <20020829142513.41226@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) Date: Thu, 29 Aug 2002 21:44:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Thursday, August 29, 2002 2:25 PM Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) > > If I take the example of SH3, it has two TLBs, one for ICACHE, another for > > DCACHE. A valid entry in TLB associated with ICACHE has only X bit > > (equivalent to R bit for data) because the instruction fetcher never writes > > data. A valid entry in TLB associated with DCACHE has R and W bits, but not > > X bit because the data fetcher never executes an instruction. So if you > > intend to have a seperate TLB for ICACHE and DCACHE, it makes no sense to > > have a different bit for X and R IN THE TLB ENTRY. > > > > You want a general R,W,X with U/S pairing. Okay, but I still don't > > understand because it is up to the software to handle them and not to TLB. > > Access violations can (and will) be handled in software, but they can > not be *detected* in software, unless you want to run an exception > handler for *every* memory access. > > Note that the absence of a TLB entry means something different. > > And yes, we always want all three bits (rwx). > I know very well that. But you were talking if there is only one TLB which can be used for code or data page. It hurts me for the reasons I gave above. >From the viewpoint of programmer we have those three bits, but from ITLB or DTLB we dont need them all in the same TLB; r,w go in DTLB, and x goes in ITLB. I just want for you to give a better detail of what kind of TLB fcpu will use. Anyway, you always have your three bits but it is not really an hardware issue (as I told bit x and bit r don't need to be in different position since TLB entry are not the same in ITLB as in DTLB). I hope you understand why now I insist on the fact we should be more clear about what kind of TLB it must be and avoid some confusion about fixing three bits in TLB entry, which is not very relevant to me. Quite now, I feel as if you (people in general) have not an exact viewpoint of what TLB in FCPU should be. Unless speaking of unified TLB for ICACHE and DCACHE - are you sure it is a good thing ? most cpu avoid that - you really need to split your TLB into ITLB and DTLB and have relevant description for each TLB : it is only my concern. Be sure I'm not against all three bits. Regards. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Aug 29 20:38:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfB-00072u-00 for ; Fri, 30 Aug 2002 05:41:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:37 +0200 (CEST) Received: (qmail 5257 invoked by uid 0); 29 Aug 2002 21:48:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 29 Aug 2002 21:48:33 -0000 Received: by moria.seul.org (Postfix) id D153915E78A; Thu, 29 Aug 2002 17:48:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE77715E78D; Thu, 29 Aug 2002 17:48:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a115.home.uni-hannover.de [130.75.232.115]) by moria.seul.org (Postfix) with ESMTP id 45B1F15E78A for ; Thu, 29 Aug 2002 17:48:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00583; Thu, 29 Aug 2002 20:38:14 +0200 Message-ID: <20020829203814.65177@thrai.stud.uni-hannover.de> Date: Thu, 29 Aug 2002 20:38:14 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Correction for manual 0.2.6 References: <3D6CDBD4.9020004@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D6CDBD4.9020004@laposte.net>; from Lavergne Thomas on Wed, Aug 28, 2002 at 04:19:00PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Aug 28, 2002 at 04:19:00PM +0200, Lavergne Thomas wrote: > Some little errors in the manual : [...] > Page 133 : dhiftl > > Use the opcode of shiftl instead of his own opcode. [...] I looked at this again, and the result is that shiftl and dshiftl can (and should) share a single opcode. The only difference between the instructions is that dshiftl provides a second result word (the EU_SHL always provides it, but it is ignored for shiftl). The same is true for [d]shiftr, [d]shiftra, [d]bitrev as well as their immediate versions. That is, the d- prefix can be represented as a flag if there is room in the instruction. In that case, we may also change the syntax and make it a -d suffix. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 30 01:31:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfF-00072u-00 for ; Fri, 30 Aug 2002 05:41:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:41 +0200 (CEST) Received: (qmail 30569 invoked by uid 0); 29 Aug 2002 23:20:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 29 Aug 2002 23:20:44 -0000 Received: by moria.seul.org (Postfix) id 38A9D15E78C; Thu, 29 Aug 2002 19:20:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0B3215E78F; Thu, 29 Aug 2002 19:20:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 851AA15E78C for ; Thu, 29 Aug 2002 19:20:42 -0400 (EDT) Received: from f-cpu.org (kdl11-7.n.club-internet.fr [213.44.9.7]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 782AF16CF for ; Fri, 30 Aug 2002 01:20:33 +0200 (CEST) Message-ID: <3D6EAEB7.AC5B0474@f-cpu.org> Date: Fri, 30 Aug 2002 01:31:03 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> <1030410212.3d6acfe45bf20@imp.free.fr> <001501c24dac$960f6460$a73d0f50@hli> <1030451613.3d6b719d6eee5@imp.free.fr> <004b01c24e22$4911c0b0$0100000a@ifurita> <1030569339.3d6d3d7b4bad3@imp.free.fr> <010001c24f41$cfee88a0$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Christophe Avoinne wrote: > "Cedric BAIL" wrote : > > The problem is that you didn't have any error in fact the test is false, so no > > real memory access are done. So you must not reexecute the instruction and only > > pass it even if the address is bad. It's were I see a problem, you execute a > > handler for nothing... > 'loadCC' : If you access memory regardless the test result, yes you will > raise an exception even for false test. Due to this design you need to delay > the exception until the test is completed and is true. the condition test AND the pointer check happen at the same time. The decision (stall, trap or issue) is taken during the Xbar stage. So there is no problem such as what Cédric explained (with the Null pointer and false condition). The issue logic should be smart enough (and it's not too difficult) to avoid these situations. Let's say that the condition has precedence over the pointer. In HW, condition is faster than pointer LUT reading, so it's also a natural choice. > You should really detail your explanation because I really don't see how you > planned to execute 'loadCC' and 'storeCC' and find out that kind of problem. i hope the problem has disappeared now :-) In a previous mail, you also wrote : > From: "Cedric BAIL" > 'load' : you mean you always load the value from memory and assign the value > to the data register only if test is succeeded ? well, if so, an exception > will occur before any test anyway. no. This can be a waste of CPU time (spent in the trap handler) if the SW is badly coded. > But if you only access memory just after the test succeeds, an exception > will occur and still you need to rexecute the instruction. they are accessed at the same time, and the issue logic (a big "AND-OR" of all the status and conditions) will sort things. > Because your instruction has no internal state. You cannot use partial > execution with exception. After an exception occurs, you cannot finish an > instruction by resuming partial execution : you need to reexecute the > instruction. The F-CPU instructions are (and should remain so) such that partial execution is not necessary. The instruction flow is only controlled at the decode/issue stage. > > > Again, I don't see any problem. > > > > Currently if you have this : > > > > [DATA] > > | > > [CPU 1]---[CPU 2] > > > > > > When CPU2 do a conditional load/Store pair, it will not be abble to see > > if CPU 1 access to the data. # error : "access" variable undefined. for reading, there is no problem. for writing, the "dirty" flag will change so locked things will work (well, unless you read all the lengthy thread about this too much). > > The only reason why CPU 2 know that, is because > > all memory access will always be send to CPU 2 by CPU 1... It can be a > > big overkill. I perhaps miss something but the problem exist. badly written programs. false assumptions. communication is an expensive resource, that a lot of programmers waste for laziness reasons (that they excuse with "portability", "langage", "existing code base" etc....). Currently, we can't afford a complex and costly MESI thing. And if you look at PCs, you'll have more reasons to seek another approach. > Ok you are speaking about inter-cpu locking, not intra-cpu locking. Well of > course it is the most difficult problem to solve. ... given a certain perspective. This has been "solved" in many ways by several generations of programmers and computer designers.. > CPU1 and CPU2 can access directly to DATA, because they both have a > different LSU we are stuck. that's one very simple way to see this :-) > In fact, the problem only occurs when you want a bi-processor or more, so I > think you an extra stuff to allow global locking of data between CPU. This is the kind of stuff that exists in "high performance" computers but when i speak about that, i get flamed. otherwise, i would already have invented a clean interface for that and the debate would be over. But there is the argument that "locks" are mostly for local (intra-CPU) resources and an external lock would slow all CPUs. > I suppose you want several CPU able to access the same DATA directly : > > CPU1------------------\ > CPU2------------------+------DATA > CPU3------------------+ > CPU4------------------/ i would naturally put this in the "G-chip"... > You need a bridge to access DATA for all CPU. It cannot be possible for all > CPU to access DATA meanwhile. 4-port SRAMs can now work around 250MHz.... but a FPGA would do the job easily as well, and manage the locks. > Just an idea : beside the LSU for each CPU (internal LSU), we can have a > external LSU which only contains the locked entries : does this mean that a specific instruction is needed ? i wanted to do this through the SRs, in order to not limit the number of running locks/semaphores. > if a CPU do normal load/store, just bypass external LSU : faster behavior. > if a CPU do lock load, set a new entry in external LSU. > if a CPU do lock store, check if entry is in external LSU. > > This external LSU can be seen as a special memory. looks cool but there is a problem : how do you manage coherency between the usual 'L0' LSU and the special one ? The problem of splitting the functions is a natural one, but i wouldn't put this in the memory addressing range, as it conflicts with the LSU and coherency between the units will adds more problems (and shift the SW problems to the HW, but HW is usually more difficult to design, particularly when there is no code). I would propose an independent "lock" space for this purpose, so this wouldn't conflict with the memory space. The same kinds of techniques and protections can be enforced (N entries, associative addressing, trap on illegal ranges...) but it's much more simpler. Instructions would be "lock imm/reg, value, result" and "release imm/reg, result". no addressing, no TLB access/miss, no granularity problems (memory should be reserved for high-bandwidth, large chunk transfers, and a single byte or word is an overkill). You see, i try to bring solutions, too. i hope someone will enhance on them. Thanks to Crhistophe for the "parallel LSU" idea, it's less scary than the SRs and can reuse a lot of existing methods. Btw, in a multi-CPU configuration, an interconnexion network can be dedicated to passing lock messages, if it can't be multiplexed with the memory streams on the front-side bus (this last idea is however what will be certainly implemented first). This is a common technique in large computers. > A+ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 30 01:31:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfG-00072u-00 for ; Fri, 30 Aug 2002 05:41:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:42 +0200 (CEST) Received: (qmail 27016 invoked by uid 0); 29 Aug 2002 23:20:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 29 Aug 2002 23:20:49 -0000 Received: by moria.seul.org (Postfix) id B498015E78B; Thu, 29 Aug 2002 19:20:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB20015E790; Thu, 29 Aug 2002 19:20:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 633F115E78B for ; Thu, 29 Aug 2002 19:20:48 -0400 (EDT) Received: from f-cpu.org (kdl11-7.n.club-internet.fr [213.44.9.7]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 8ED7716A4 for ; Fri, 30 Aug 2002 01:20:45 +0200 (CEST) Message-ID: <3D6EAEC3.4A550C2B@f-cpu.org> Date: Fri, 30 Aug 2002 01:31:15 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] tlb last ! (secure bit, lib ring) References: <3D6D1A51.7E19FE91@ifrance.com> <3D6D2DC5.B8D2D8D5@f-cpu.org> <00f601c24f40$5666bcb0$0100000a@ifurita> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nicO< this presentation is what i call "simple" : let an average CS student read that, and he'll be able to implement it. Maybe it could be copy/pasted in the manual in some way. OK it is not the "best" way to get all the efficiency out of a "top class" CPU, but it works easily so one can start coding now. As the problem is not "classified" yet, we will have enough time to _experiment_ different factors (number of entries, tags, handlers, etc.). Christophe Avoinne wrote: > > Hi, > > I'm confused. > > Sometimes I wonder if we are not mixing hardware and software TLB notions > when speaking. > > Software TLB : WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Aug 30 01:32:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfG-00072u-01 for ; Fri, 30 Aug 2002 05:41:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:42 +0200 (CEST) Received: (qmail 3152 invoked by uid 0); 29 Aug 2002 23:22:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 29 Aug 2002 23:22:17 -0000 Received: by moria.seul.org (Postfix) id 2543E15E78F; Thu, 29 Aug 2002 19:22:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 198EC15E792; Thu, 29 Aug 2002 19:22:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CBA6615E78F for ; Thu, 29 Aug 2002 19:22:16 -0400 (EDT) Received: from f-cpu.org (kll1-30.n.club-internet.fr [213.44.91.30]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D821516A4 for ; Fri, 30 Aug 2002 01:22:13 +0200 (CEST) Message-ID: <3D6EAF1B.5C037D08@f-cpu.org> Date: Fri, 30 Aug 2002 01:32:43 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] THasm 0.1 References: <3D6E24C2.4010905@laposte.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Lavergne Thomas wrote: > > Hi, > > I release a new workable assembler for the F-Cpu. cool ! For the "logic" instruction, i hope you looked at the more up-to-date documentation located in the snapshots (f-cpu/vhdl/eu_rop2/ROP2.txt) and the exact encoding is in F-CPU/FORMATS.txt (IIRC). > Ok I known we already have an assembler in the yg and jws snapshot but I > can't make them work correctly and these cover only a small part of the ISA. > > Why a new assembler ? whatever reason, if it works and is published, that's not a problem. > You can define new encoding format or new instruction directly in your > asm file so for ISA testing it could be very usefull. that a curious and unusual feature, but if it works correctly, it's interesting as well :-) > For the moment it does not have label handling, "db", "dw"... pseudo > instruction and preprocessor, but this was added soon. this lack in ygasm is what made me break my code. forward label declaration is a very important feature and i had to rework the memory management, and the rest has broken up. Be careful. > You can get it on seul.org in my folder the zip file contain full > source, file format documentation and windows binnaries. I'm sorry I > don't provide linux binnaries for the moment because I need to > redownload it and it was a huge file... > I hope I could add it quickly. i wish i'll integrate it soon to the snapshots. i'm eager to try it but my new job takes all my time (and my desk is near the boss's desk, so i can't spend too much time playing ;-P). I don't even read all my mail anymore... i wish more people can continue the work, as nobody is reliable. > @+, Tom > Thomas Lavergne "Le vrai rêveur est celui qui rêve WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From oscarcereal2@hotmail.com Fri Aug 30 03:35:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfH-00072u-00 for ; Fri, 30 Aug 2002 05:41:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:43 +0200 (CEST) Received: (qmail 22479 invoked by uid 0); 30 Aug 2002 01:35:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 30 Aug 2002 01:35:56 -0000 Received: by moria.seul.org (Postfix) id EAB6815E794; Thu, 29 Aug 2002 21:35:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DBA9015E796; Thu, 29 Aug 2002 21:35:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from hotmail.com (f23.sea1.hotmail.com [207.68.163.23]) by moria.seul.org (Postfix) with ESMTP id D2CCD15E793; Thu, 29 Aug 2002 21:35:53 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 29 Aug 2002 18:35:53 -0700 Received: from 217.146.9.176 by sea1fd.sea1.hotmail.msn.com with HTTP; Fri, 30 Aug 2002 01:35:52 GMT X-Originating-IP: [217.146.9.176] From: "oscar cereal" To: oscarcereal2@hotmail.com Subject: [f-cpu] VERY URGENT AND CONFIDENTIAL. Date: Fri, 30 Aug 2002 03:35:52 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Aug 2002 01:35:53.0194 (UTC) FILETIME=[941DFCA0:01C24FC5] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 18 Independence Close, Johannesburg, South Africa. REPLY ME IN THIS PRVITA E- MAIL ADDRESS VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from a in Africa. I want to ask you to kindly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new bank account immediately to receive this money, though an empty bank account could serve this purpose as long as you will remain honest to me till the end of this important business trusting in you and believing in God that you will never let me down either now or in time to come. I am Oscar Cereal.the external auditor of a Bank.During the course of our auditing,I discovered a floating fund in an account opened in the bank in 1990 and since 1993 nobody has operated on this account again.After going through some old files in the records, I discovered that the owner of the account died without a “Heir apparent to the throne” hence the money is floating and if I do not remit this money out urgently it will be forfeited for nothing. The owner of this account who is Mr.Eshed.B.Willey, a foreigner and an industrialist died, since 1990,until now no other person(s) knows about this account or could give any documentary evidence concerning this account. As such this account has no other beneficiary and my investigation proved to me as well that Eshed.B.Willey until his death was the manager Oriental Diamond Company,in South Africa. However, if you are interested in this business we will start the first money transfer with Forty Two Million U.S.Dollars(U.S.$42,000,000.00) upon successful transaction without any disappointment from you. We shall also re-apply for the payment of the remaining amount to your account. While the total amount involved is One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00)only. I would want us to make a first transfer of [Forty Two Million United States Dollar.(U.S.$42,000,000.00)from this money into a safe foreigners account abroad before the rest. I am only contacting you as a foreigner because this money can not be approved to a local account, without valid international foreign “Agreement”, but could only be approved to any foreigner with valid international credentials: passport or drivers license and foreign account because this sum is in U.S. dollars and the former owner of the account Mr.Eshed.B.Willey is a foreigner too, thus the money could only be approved into a foreign account. However, knowing all this, we will reach a binding agreement in this regards. As a matter of urgency, I will inform you the next step to take, while you Send your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments,I need your full co-operation to make this business a success, because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you,upon your positive response and once I am convinced that you are capable and will meet up with the instructions of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never let me down. With my influence and the position in the bank we can transfer this money to any foreigner's reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing. And to build confidence that you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act as directed. To prove the authenticity of the business I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries, foreign exchange departments, embassy and Board of Internal Revenue Services. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during this process. I look forward to your earliest reply through telephone,Fax or my email address. Yours truly Oscar. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From oscarcereal@email.com Fri Aug 30 03:39:03 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kcfI-00072u-00 for ; Fri, 30 Aug 2002 05:41:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 05:41:44 +0200 (CEST) Received: (qmail 10524 invoked by uid 0); 30 Aug 2002 01:39:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 30 Aug 2002 01:39:22 -0000 Received: by moria.seul.org (Postfix) id 0E43915E797; Thu, 29 Aug 2002 21:39:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF9DC15E79A; Thu, 29 Aug 2002 21:39:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ws3-2.us4.outblaze.com (205-158-62-92.outblaze.com [205.158.62.92]) by moria.seul.org (Postfix) with SMTP id 073F115E797 for ; Thu, 29 Aug 2002 21:39:20 -0400 (EDT) Received: (qmail 29848 invoked by uid 1001); 30 Aug 2002 01:39:03 -0000 Message-ID: <20020830013903.29847.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [217.146.9.176] by ws3-2.us4.outblaze.com with http for oscarcereal@email.com; Thu, 29 Aug 2002 20:39:03 -0500 From: "oscar cereal" To: oscarcereal@mail.com Date: Thu, 29 Aug 2002 20:39:03 -0500 Subject: [f-cpu] VERY URGENT AND CONFIDENTIAL. X-Originating-Ip: 217.146.9.176 X-Originating-Server: ws3-2.us4.outblaze.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N 18 Independence Close, Johannesburg, South Africa. REPLY ME WITH THIS PRVITA ADDRESS VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from a in Africa. I want to ask you to kindly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new bank account immediately to receive this money, though an empty bank account could serve this purpose as long as you will remain honest to me till the end of this important business trusting in you and believing in God that you will never let me down either now or in time to come. I am Oscar Cereal.the external auditor of a Bank.During the course of our auditing,I discovered a floating fund in an account opened in the bank in 1990 and since 1993 nobody has operated on this account again.After going through some old files in the records, I discovered that the owner of the account died without a “Heir apparent to the throne” hence the money is floating and if I do not remit this money out urgently it will be forfeited for nothing. The owner of this account who is Mr.Eshed.B.Willey, a foreigner and an industrialist died, since 1990,until now no other person(s) knows about this account or could give any documentary evidence concerning this account. As such this account has no other beneficiary and my investigation proved to me as well that Eshed.B.Willey until his death was the manager Oriental Diamond Company,in South Africa. However, if you are interested in this business we will start the first money transfer with Forty Two Million U.S.Dollars(U.S.$42,000,000.00) upon successful transaction without any disappointment from you. We shall also re-apply for the payment of the remaining amount to your account. While the total amount involved is One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00)only. I would want us to make a first transfer of [Forty Two Million United States Dollar.(U.S.$42,000,000.00)from this money into a safe foreigners account abroad before the rest. I am only contacting you as a foreigner because this money can not be approved to a local account, without valid international foreign “Agreement”, but could only be approved to any foreigner with valid international credentials: passport or drivers license and foreign account because this sum is in U.S. dollars and the former owner of the account Mr.Eshed.B.Willey is a foreigner too, thus the money could only be approved into a foreign account. However, knowing all this, we will reach a binding agreement in this regards. As a matter of urgency, I will inform you the next step to take, while you Send your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments,I need your full co-operation to make this business a success, because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you,upon your positive response and once I am convinced that you are capable and will meet up with the instructions of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never let me down. With my influence and the position in the bank we can transfer this money to any foreigner's reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing. And to build confidence that you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act as directed. To prove the authenticity of the business I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries, foreign exchange departments, embassy and Board of Internal Revenue Services. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during this process. I look forward to your earliest reply through telephone,Fax or my email address. Yours truly oscar. -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 30 11:03:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kopt-0006rl-00 for ; Fri, 30 Aug 2002 18:41:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:29 +0200 (CEST) Received: (qmail 413 invoked by uid 0); 30 Aug 2002 09:03:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 30 Aug 2002 09:03:40 -0000 Received: by moria.seul.org (Postfix) id 0946315E790; Fri, 30 Aug 2002 05:03:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDB0C15E796; Fri, 30 Aug 2002 05:03:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id A836915E790 for ; Fri, 30 Aug 2002 05:03:37 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208300903.19c4; Fri, 30 Aug 2002 09:03:25 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Conditionnal load and store, the return From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Aug 2002 09:03:25 GMT Message-id: <200208300903.19c4@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N look for >>> for answer. -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 30/08/02 Objet: Re: [f-cpu] Conditionnal load and store, the return hi, Christophe Avoinne wrote: > "Cedric BAIL" wrote : > > The problem is that you didn't have any error in fact th= e test is false, so no > > real memory access are done. So you must not reexecute t= he instruction and only > > pass it even if the address is bad. It's were I see a pr= oblem, you execute a > > handler for nothing... > 'loadCC' : If you access memory regardless the test result= , yes you will > raise an exception even for false test. Due to this design= you need to delay > the exception until the test is completed and is true. the condition test AND the pointer check happen at the same = time. The decision (stall, trap or issue) is taken during the Xbar= stage. So there is no problem such as what C=E9dric explained (with= the Null pointer and false condition). The issue logic should be smart enough= (and it's not too difficult) to avoid these situations. Let's say that the condition has precedence over the pointer= . In HW, condition is faster than pointer LUT reading, so it's= also a natural choice. > You should really detail your explanation because I really= don't see how you > planned to execute 'loadCC' and 'storeCC' and find out tha= t kind of problem. i hope the problem has disappeared now :-) In a previous mail, you also wrote : > From: "Cedric BAIL" > 'load' : you mean you always load the value from memory an= d assign the value > to the data register only if test is succeeded ? well, if = so, an exception > will occur before any test anyway. no. This can be a waste of CPU time (spent in the trap handl= er) if the SW is badly coded. > But if you only access memory just after the test succeeds= , an exception > will occur and still you need to rexecute the instruction. they are accessed at the same time, and the issue logic (a b= ig "AND-OR" of all the status and conditions) will sort things. > Because your instruction has no internal state. You cannot= use partial > execution with exception. After an exception occurs, you c= annot finish an > instruction by resuming partial execution : you need to re= execute the > instruction. The F-CPU instructions are (and should remain so) such that = partial execution is not necessary. The instruction flow is only con= trolled at the decode/issue stage. > > > Again, I don't see any problem. > > > > Currently if you have this : > > > > [DATA] > > | > > [CPU 1]---[CPU 2] > > > > > > When CPU2 do a conditional load/Store pair, it will not = be abble to see > > if CPU 1 access to the data. # error : "access" variable undefined. for reading, there is no problem. for writing, the "dirty" flag will change so locked things will work (well, unless you read all the lengthy thread about this too much). > > The only reason why CPU 2 know that, is because > > all memory access will always be send to CPU 2 by CPU 1.= .. It can be a > > big overkill. I perhaps miss something but the problem e= xist. badly written programs. false assumptions. communication is an expensive resource, that a lot of progra= mmers waste for laziness reasons (that they excuse with "portability", "= langage", "existing code base" etc....). Currently, we can't afford a = complex and costly MESI thing. And if you look at PCs, you'll have m= ore reasons to seek another approach. >>>It's you're usual speach but programing efficiently MIMD = computer is a research topic. But maybe you soon overcome this.=20 > Ok you are speaking about inter-cpu locking, not intra-cpu= locking. Well of > course it is the most difficult problem to solve. ... given a certain perspective. This has been "solved" in many ways by several generations o= f programmers and computer designers.. >>> It's as *never* been sold by a satisfactionnely. NUMA (N= one uniform memory access : flat adressing but each node have it's memor= y bank to speed up local access, remote access are much longer, hardwa= ring sharing model is "central server type") computer put a great pressur= e under the OS scheduler. Don't say they are bad programmer ! A scheduli= ng is a NP-complet problem !=20 >>> COMA (cache only memory access) of the last SUN E10000 u= se the read-replication approch. >>> From a research point of view none approch is better tha= n the other : it depend on the application. My idea is to permit the 4 a= pproches (could read a old draft at http://f-cpu.seul.org/nico ). May= be we should look at L4 and decide what is needed in hardware to do it.=20 >>> I really think that not so much thing are needed. We onl= y have to find a good way to permit to have a duplicated virtual pages= on 2 physical one (on different node). This could add some interr= esting problem ;p > CPU1 and CPU2 can access directly to DATA, because they bo= th have a > different LSU we are stuck. that's one very simple way to see this :-) > In fact, the problem only occurs when you want a bi-proces= sor or more, so I > think you an extra stuff to allow global locking of data b= etween CPU. This is the kind of stuff that exists in "high performance" = computers but when i speak about that, i get flamed. otherwise, i woul= d already=20 >>>> Yep ! Because you never explain correctly how you're id= ea work ! have invented a clean interface for that and the debate would be = over. But there is the argument that "locks" are mostly for local = (intra-CPU) resources and an external lock would slow all CPUs. >>>> We not need a list od signals ! But a list of bus fonct= ionnality. > I suppose you want several CPU able to access the same DAT= A directly : >=20 > CPU1------------------\ > CPU2------------------+------DATA > CPU3------------------+ > CPU4------------------/ i would naturally put this in the "G-chip"... >>> Grrr ! We put the memory controller inside the f-cpu to = decrease latency and you want to add an other chip ! Think with fonct= ionnality in mind (IP !), not chip ! look at what AMD want to do with opt= eron...=20 > You need a bridge to access DATA for all CPU. It cannot be= possible for all > CPU to access DATA meanwhile. 4-port SRAMs can now work around 250MHz.... but a FPGA would do the job easily as well, and manage the l= ocks. >>> Limited ressources, a big buse for very few use. Why spe= aking one more time about FPGA ? We design IP, so we could then choose= when things will be implemented. 250 Mhz for FPGA is very very optimisti= c ! On our system it must have only memory+f-cpus+io controler, = that's all. One more chip will increase the price for almost nothing. > Just an idea : beside the LSU for each CPU (internal LSU),= we can have a > external LSU which only contains the locked entries : does this mean that a specific instruction is needed ? >>> ??? i wanted to do this through the SRs, in order to not limit t= he number of running locks/semaphores. >>> You can't use SR for that refind an old Christophe post.= That's simply impossible with SR that are only write and read. > if a CPU do normal load/store, just bypass external LSU : = faster behavior. > if a CPU do lock load, set a new entry in external LSU. > if a CPU do lock store, check if entry is in external LSU. >=20 > This external LSU can be seen as a special memory. looks cool but there is a problem : how do you manage cohere= ncy between the usual 'L0' LSU and the special one ? >>> LSU is only a caches. The problem of splitting the functions is a natural one, but= i wouldn't put this in the memory addressing range, as it conflicts wit= h the LSU and coherency between the units will adds more problems (and= shift the SW problems to the HW, but HW is usually more difficult = to design, particularly when there is no code). I would propose an independent "lock" space for this purpose= , so this wouldn't conflict with the memory space. The same ki= nds of techniques and protections can be enforced (N entries, as= sociative addressing, trap on illegal ranges...) but it's much more si= mpler. Instructions would be "lock imm/reg, value, result" and "release imm/reg, result". no addressing, no TLB access/miss= , no granularity problems (memory should be reserved for high-= bandwidth, large chunk transfers, and a single byte or word is an overk= ill). >>> lock aren't so common but using 20 pins to do that is re= ally an overkill. You see, i try to bring solutions, too. i hope someone will = enhance on them. Thanks to Crhistophe for the "parallel LSU" idea, i= t's less scary than the SRs and can reuse a lot of existing methods. Btw, in a multi-CPU configuration, an interconnexion network= can be dedicated to passing lock messages, if it can't be multip= lexed >>> overkill !!! with the memory streams on the front-side bus (this last ide= a is however what will be certainly implemented first). >>> It's only a new fonctionnality of the bus a new transact= ion, that's all. This is a common technique in large computers. >>>> Old large computer, with frequency of 50 Mhz, with no r= eally wire routing problem, that cost millions dollars,... nicO > A+ WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Fri Aug 30 17:25:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kopu-0006rl-00 for ; Fri, 30 Aug 2002 18:41:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:30 +0200 (CEST) Received: (qmail 5122 invoked by uid 0); 30 Aug 2002 10:26:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 30 Aug 2002 10:26:21 -0000 Received: by moria.seul.org (Postfix) id F334115E795; Fri, 30 Aug 2002 06:26:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0B0E15E79F; Fri, 30 Aug 2002 06:26:20 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 2607815E795 for ; Fri, 30 Aug 2002 06:26:20 -0400 (EDT) Received: from club-internet.fr (flashmail-6m.cs.clubint.net [172.16.20.65]) by relay-4m.club-internet.fr (Postfix) with SMTP id D73D5E103; Fri, 30 Aug 2002 12:26:18 +0200 (CEST) Received: from [212.43.214.31] by flashmail-6m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Conditionnal load and store, the return Date: Fri, 30 Aug 2002 12:25:29 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 =22Nicolas Boulay=22 wrote : >De: Yann Guidon >hi, > >Christophe Avoinne wrote: >> From: =22Cedric BAIL=22 >> > > Again, I don't see any problem. >> > >> > Currently if you have this : >> > >> > =5BDATA=5D >> > =7C >> > =5BCPU 1=5D---=5BCPU 2=5D >> > >> > >> > When CPU2 do a conditional load/Store pair, it will not be abble to s= ee >> > if CPU 1 access to the data. >=23 error : =22access=22 variable undefined. > >for reading, there is no problem. >for writing, the =22dirty=22 flag will change >so locked things will work (well, unless you >read all the lengthy thread about this too much). > >> > The only reason why CPU 2 know that, is because >> > all memory access will always be send to CPU 2 by CPU 1.... It can be= a >> > big overkill. I perhaps miss something but the problem exist. >badly written programs. false assumptions. >communication is an expensive resource, that a lot of programmers waste >for laziness reasons (that they excuse with =22portability=22, =22langage= =22, >=22existing code base=22 etc....). Currently, we can't afford a complex >and costly MESI thing. And if you look at PCs, you'll have more reasons >to seek another approach. > >>>>It's you're usual speach but programing efficiently MIMD computer is >a research topic. But maybe you soon overcome this. = well, this research seems to be endless and unfruitful. unless you read some litterature. You have found a paper/course on COMA, i have found other resources : you see, it's not a desperate case. >> Ok you are speaking about inter-cpu locking, not intra-cpu locking. Wel= l of >> course it is the most difficult problem to solve. >.... given a certain perspective. >This has been =22solved=22 in many ways by several generations of >programmers >and computer designers.. > >>>> It's as *never* been sold by a satisfactionnely. oh, yes. Pentium is better because it is sold in larger quantities. cool architectural argument. > NUMA (None uniform >memory access : flat adressing but each node have it's memory bank to >speed up local access, remote access are much longer, hardwaring sharing >model is =22central server type=22) computer put a great pressure under t= he >OS scheduler. Don't say they are bad programmer =21 A scheduling is a >NP-complet problem =21 = then tell that to the people who put tens or hundreds of DSP in a rack. And scheduling is not a new science either. just type this keyword in google and you'll find heuristics. >>>> COMA (cache only memory access) of the last SUN E10000 use the read-r= eplication approch. > >>>> From a research point of view none approch is better than the other >: it depend on the application. My idea is to permit the 4 approches >(could read a old draft at http://f-cpu.seul.org/nico ). Maybe we should >look at L4 and decide what is needed in hardware to do it. = good luck. >>>> I really think that not so much thing are needed. We only have to >find a good way to permit to have a duplicated virtual pages on 2 >physical one (on different node). This could add some interresting >problem ;p do you think it's impossible ? i believe that F-CPU is not the first computer to attempt that. look at a T3D/E. >> CPU1 and CPU2 can access directly to DATA, because they both have a >> different LSU we are stuck. >that's one very simple way to see this :-) > >> In fact, the problem only occurs when you want a bi-processor or more, = so I >> think you an extra stuff to allow global locking of data between CPU. >This is the kind of stuff that exists in =22high performance=22 computers >but when i speak about that, i get flamed. otherwise, i would already = > >>>>> Yep =21 Because you never explain correctly how you're idea work =21 ditto. one more reason for this thread to end up with Godwin points distributions. If it ever ends. >have invented a clean interface for that and the debate would be over. >But there is the argument that =22locks=22 are mostly for local (intra-CP= U) >resources and an external lock would slow all CPUs. > >>>>> We not need a list od signals =21 But a list of bus fonctionnality. i don't see where i speak about signals, here. >> I suppose you want several CPU able to access the same DATA directly : >> = >> CPU1------------------=5C >> CPU2------------------+------DATA >> CPU3------------------+ >> CPU4------------------/ > >i would naturally put this in the =22G-chip=22... > >>>> Grrr =21 We put the memory controller inside the f-cpu to decrease >latency and you want to add an other chip =21 this is not related. The local memory is accessed by the same CPU but seve= ral CPUs want to talk together. If there is a =22hub=22, then it's the best place to store the inter-CPU locks. > Think with fonctionnality in mind (IP =21), not chip =21 just like you, i think whatever pleases me. > look at what AMD want to do with opteron... = and then count the pins ;-) >> You need a bridge to access DATA for all CPU. It cannot be possible for= all >> CPU to access DATA meanwhile. >4-port SRAMs can now work around 250MHz.... >but a FPGA would do the job easily as well, and manage the locks. >>>> Limited ressources, a big buse for very few use. Why speaking one >more time about FPGA ? We design IP, so we could then choose when things >will be implemented. 250 Mhz for FPGA is very very optimistic =21 >On our system it must have only memory+f-cpus+io controler, that's all. >One more chip will increase the price for almost nothing. >> Just an idea : beside the LSU for each CPU (internal LSU), we can have = a >> external LSU which only contains the locked entries : >does this mean that a specific instruction is needed ? > >>>> ??? yes : separate unit implies a separate instruction. pure example of associated ideas. >i wanted to do this through the SRs, in order to not limit the number >of running locks/semaphores. > >>>> You can't use SR for that refind an old Christophe post. That's >simply impossible with SR that are only write and read. you forgot that since we design the stuff, we are free to modify whatever parts do not fit in the =22big picture=22. but let's forget about SRs now. The =22pseudo-LSU=22 idea seems promising (but protection, scheduling and atomicity are still problems if we don't use the register association flags. >> if a CPU do normal load/store, just bypass external LSU : faster behavi= or. >> if a CPU do lock load, set a new entry in external LSU. >> if a CPU do lock store, check if entry is in external LSU. >> This external LSU can be seen as a special memory. > >looks cool but there is a problem : how do you manage coherency between >the usual 'L0' LSU and the special one ? > >>>> LSU is only a caches. and cache coherency is not an issue for you ? what is the =5Freal=5F cost for this ? * if the same addressing space (memory) is used, then this will conflict with other ongoing streams. * if the LSU is parallel to the lock unit, the units must be synchronised and keep coherency. * if the units are in series, then one will slow down the other. To these problem, there is a simple solution : create a new adressing space that does not coincide with the memory space. We can apply some of the techniques of the LSU and forget about coherency. >The problem of splitting the functions is a natural one, but i wouldn't >put this in the memory addressing range, as it conflicts with the LSU >and coherency between the units will adds more problems (and shift >the SW problems to the HW, but HW is usually more difficult to design, >particularly when there is no code). > >I would propose an independent =22lock=22 space for this purpose, >so this wouldn't conflict with the memory space. The same kinds >of techniques and protections can be enforced (N entries, associative >addressing, trap on illegal ranges...) but it's much more simpler. >Instructions would be =22lock imm/reg, value, result=22 and >=22release imm/reg, result=22. no addressing, no TLB access/miss, >no granularity problems (memory should be reserved for high-bandwidth, >large chunk transfers, and a single byte or word is an overkill). > >>>> lock aren't so common but using 20 pins to do that > is really an overkill. it is also an overkill to use memory (with the 256-bit granularity) for a single 32-bit lock. And we are not forced to use external pins either. Look at the bottom of the message where we start to agree that the FSB can support special messages that can be harmlessly interlevead in the memory streams and bursts. >You see, i try to bring solutions, too. i hope someone will enhance >on them. Thanks to Crhistophe for the =22parallel LSU=22 idea, it's less >scary than the SRs and can reuse a lot of existing methods. > >Btw, in a multi-CPU configuration, an interconnexion network can >be dedicated to passing lock messages, if it can't be multiplexed > >>>> overkill =21=21=21 i said =22if=22. but it seems that we what we want is a contradiction in itself. We want =22high-end performance=22 with low-level technology, and even though there are some techniques, we can't get more than what we pay. >with the memory streams on the front-side bus (this last idea >is however what will be certainly implemented first). > >>>> It's only a new fonctionnality of the bus a new transaction, that's a= ll. that's what i said. it's not difficult to modify existing protocols to include these =22messages=22. >This is a common technique in large computers. > >>>>> Old large computer, with frequency of 50 Mhz, with > no really wire routing problem, that cost millions dollars,... sorry about the wire routing problems. If they cost so much, it's because the routing is the main problem. and if the routing is so expensive, it's efficient. you get what you pay, there is no magic. see you on thursday, > nicO >> A+ >WHYGEE ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Fri Aug 30 12:29:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kopw-0006rl-00 for ; Fri, 30 Aug 2002 18:41:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:32 +0200 (CEST) Received: (qmail 12584 invoked by uid 0); 30 Aug 2002 10:44:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 30 Aug 2002 10:44:57 -0000 Received: by moria.seul.org (Postfix) id 883A815E796; Fri, 30 Aug 2002 06:44:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F51C15E7A1; Fri, 30 Aug 2002 06:44:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 30AFE15E796 for ; Fri, 30 Aug 2002 06:44:56 -0400 (EDT) Received: from laposte.net (193.250.154.76) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9002C264D for f-cpu@seul.org; Fri, 30 Aug 2002 12:44:55 +0200 Message-ID: <3D6F48FB.4090602@laposte.net> Date: Fri, 30 Aug 2002 12:29:15 +0200 From: Lavergne Thomas Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: fr, fr-fr, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] THasm 0.1 References: <3D6E24C2.4010905@laposte.net> <3D6EAF1B.5C037D08@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > For the "logic" instruction, i hope you looked at the more up-to-date > documentation located in the snapshots (f-cpu/vhdl/eu_rop2/ROP2.txt) > and the exact encoding is in F-CPU/FORMATS.txt (IIRC). > No, for the moment I've respected the current release of the manual (yes I known it was out of date for some part but...). But it was simple to update it, you just need to edit the std.inc file and change the instructions definition (no need to recompile), it was the advantage of inline definition of instruction. >>You can define new encoding format or new instruction directly in your >>asm file so for ISA testing it could be very usefull. > > > that a curious and unusual feature, but if it works correctly, > it's interesting as well :-) It work... This first release was only made for testing if that idea can work and if I could obtain resonable assembling time. For the moment I can assemble 20000 line per second with badly written and unoptimized code and I hope best for the future, so it was sufficient for hand written code and small compiled program. I known that medium and big compiled program need best perf, but this is not the domain of this assembler, it was best to use specialised or internal assembler in this case. >>For the moment it does not have label handling, "db", "dw"... pseudo >>instruction and preprocessor, but this was added soon. > > > this lack in ygasm is what made me break my code. forward label declaration > is a very important feature and i had to rework the memory management, > and the rest has broken up. Be careful. I've started a full rewrite of THasm with this in mind, I implement a forward label definition and some other tricks, but for the moment no local label, no backward value associations. >>You can get it on seul.org in my folder the zip file contain full >>source, file format documentation and windows binnaries. I'm sorry I >>don't provide linux binnaries for the moment because I need to >>redownload it and it was a huge file... >>I hope I could add it quickly. > > > i wish i'll integrate it soon to the snapshots. This is only a test version for the format instruction idea, it was quickly out of date, I think it could be better to wait for the next release. -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Aug 30 12:45:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kopx-0006rl-00 for ; Fri, 30 Aug 2002 18:41:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:33 +0200 (CEST) Received: (qmail 2460 invoked by uid 0); 30 Aug 2002 10:47:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 30 Aug 2002 10:47:19 -0000 Received: by moria.seul.org (Postfix) id 7085C15E79F; Fri, 30 Aug 2002 06:47:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 475B615E7A2; Fri, 30 Aug 2002 06:47:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 973C015E79F for ; Fri, 30 Aug 2002 06:47:18 -0400 (EDT) Received: (qmail 32528 invoked by uid 85); 30 Aug 2002 10:40:38 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.165447 secs); 30 Aug 2002 10:40:38 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 30 Aug 2002 10:40:38 -0000 Message-ID: <3D6F4CCD.7050105@yahoo.fr> Date: Fri, 30 Aug 2002 12:45:33 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Conditionnal load and store, the return References: <200208300903.19c4@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Nicolas Boulay wrote: >>>> Why speaking one >>>>more time about FPGA ? We design IP, so we could then choose when things >>>>will be implemented. 250 Mhz for FPGA is very very optimistic ! >>>>On our system it must have only memory+f-cpus+io controler, that's all. >>>>One more chip will increase the price for almost nothing. >>>> Joke :-P Do you know than Actel proposed a FPGA wich reach 500MHz ? See Ya, Just an Illusion ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 30 13:57:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kopz-0006rl-00 for ; Fri, 30 Aug 2002 18:41:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:35 +0200 (CEST) Received: (qmail 21626 invoked by uid 0); 30 Aug 2002 11:57:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Aug 2002 11:57:55 -0000 Received: by moria.seul.org (Postfix) id 0BC1415E792; Fri, 30 Aug 2002 07:57:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8E7A15E7A1; Fri, 30 Aug 2002 07:57:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 42EBB15E792 for ; Fri, 30 Aug 2002 07:57:53 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208301157.2ded; Fri, 30 Aug 2002 11:57:45 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] Conditionnal load and store, the return From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Aug 2002 11:57:45 GMT Message-id: <200208301157.2ded@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 30/08/02 Objet: Re: Rep:Re: [f-cpu] Conditionnal load and store, the = return hi ! "Nicolas Boulay" wrote : >De: Yann Guidon >hi, > >Christophe Avoinne wrote: >> From: "Cedric BAIL" >> > > Again, I don't see any problem. >> > >> > Currently if you have this : >> > >> > [DATA] >> > | >> > [CPU 1]---[CPU 2] >> > >> > >> > When CPU2 do a conditional load/Store pair, it will not= be abble to see >> > if CPU 1 access to the data. ># error : "access" variable undefined. > >for reading, there is no problem. >for writing, the "dirty" flag will change >so locked things will work (well, unless you >read all the lengthy thread about this too much). > >> > The only reason why CPU 2 know that, is because >> > all memory access will always be send to CPU 2 by CPU 1= .... It can be a >> > big overkill. I perhaps miss something but the problem = exist. >badly written programs. false assumptions. >communication is an expensive resource, that a lot of progr= ammers waste >for laziness reasons (that they excuse with "portability", = "langage", >"existing code base" etc....). Currently, we can't afford a= complex >and costly MESI thing. And if you look at PCs, you'll have = more reasons >to seek another approach. > >>>>It's you're usual speach but programing efficiently MIMD= computer is >a research topic. But maybe you soon overcome this.=20 well, this research seems to be endless and unfruitful. >>>>>>Who you are to permit sucgh judgement ? I hope my last= teacher in parrallel computing will never read such words ! unless you read some litterature. You have found a paper/cou= rse on COMA, i have found other resources : you see, it's not a desperate case. >>>>Ok ,it's not. But it's a very hard problem. Not solve at= all. >> Ok you are speaking about inter-cpu locking, not intra-cp= u locking. Well of >> course it is the most difficult problem to solve. >.... given a certain perspective. >This has been "solved" in many ways by several generations = of >programmers >and computer designers.. > >>>> It's as *never* been sold by a satisfactionnely. oh, yes. Pentium is better because it is sold in larger quantities. cool architectural argument. >>>> oups. you must read "solved" not sold. Sorry. > NUMA (None uniform >memory access : flat adressing but each node have it's memo= ry bank to >speed up local access, remote access are much longer, hardw= aring sharing >model is "central server type") computer put a great pressu= re under the >OS scheduler. Don't say they are bad programmer ! A schedul= ing is a >NP-complet problem !=20 then tell that to the people who put tens or hundreds of DSP in a rack. And scheduling is not a new science either. just type this keyword in google and you'll find heuristics. >>>>>> Sorry, but it's stupid ! You can't compare general co= mputing with highly specific DSP archetecture, where topology are defined= for the application, well known when the software is written. In suc= h world, you manipulate message passing directly, and there is no OS who = handle data stream without knowing what the software do. >>>>> All the stuff is controlled. SW knows exactly the hard= ware on wich the software will be run. There is absolutely no question of= security, or even scheduling ! >>>> COMA (cache only memory access) of the last SUN E10000 = use the=20 >read-replication approch. > >>>> From a research point of view none approch is better th= an the other >: it depend on the application. My idea is to permit the 4 = approches >(could read a old draft at http://f-cpu.seul.org/nico ). Ma= ybe we should >look at L4 and decide what is needed in hardware to do it.=20 good luck. >>>> I really think that not so much thing are needed. We on= ly have to >find a good way to permit to have a duplicated virtual page= s on 2 >physical one (on different node). This could add some inter= resting >problem ;p do you think it's impossible ? i believe that F-CPU is not the first computer to attempt that. look at a T3D/E. >>>I have look at it. This architecture is called none-CC-NU= MA which means none cache coherent none uniforme memory access. It's = a real pain to write a program in that mode. And sorry this computer is = only NUMA, nothing new. >> CPU1 and CPU2 can access directly to DATA, because they b= oth have a >> different LSU we are stuck. >that's one very simple way to see this :-) > >> In fact, the problem only occurs when you want a bi-proce= ssor or more, so I >> think you an extra stuff to allow global locking of data = between CPU. >This is the kind of stuff that exists in "high performance"= computers >but when i speak about that, i get flamed. otherwise, i wou= ld already=20 > >>>>> Yep ! Because you never explain correctly how you're i= dea work ! ditto. one more reason for this thread to end up with Godwin points distributions. If it ever ends. >>>>>:p >have invented a clean interface for that and the debate wou= ld be over. >But there is the argument that "locks" are mostly for local= (intra-CPU) >resources and an external lock would slow all CPUs. > >>>>> We not need a list od signals ! But a list of bus fonc= tionnality. i don't see where i speak about signals, here. >>>>>i read "interface" so i thought about you're "fbus". >> I suppose you want several CPU able to access the same DA= TA directly : >>=20 >> CPU1------------------\ >> CPU2------------------+------DATA >> CPU3------------------+ >> CPU4------------------/ > >i would naturally put this in the "G-chip"... > >>>> Grrr ! We put the memory controller inside the f-cpu to= decrease >latency and you want to add an other chip ! this is not related. The local memory is accessed by the sam= e CPU but several CPUs want to talk together. If there is a "hub", then it's the best place to store the inter-CPU locks. >>>So you lose all the benefit of keep off the northchip chi= pset. Welcome back to the 90's ! > Think with fonctionnality in mind (IP !), not chip ! just like you, i think whatever pleases me. >>>>Yep ! But in that case, it's a none sense. > look at what AMD want to do with opteron...=20 and then count the pins ;-) >>>>Yes count it : only memory interface + interconnection b= uses. In you're proposal. Maybe the f-cpu will have less pin but the = bandwith to the chip will decrease and the latency increase. And i can't= imagine the size of the gchip ! >> You need a bridge to access DATA for all CPU. It cannot b= e possible for all >> CPU to access DATA meanwhile. >4-port SRAMs can now work around 250MHz.... >but a FPGA would do the job easily as well, and manage the = locks. >>>> Limited ressources, a big buse for very few use. Why sp= eaking one >more time about FPGA ? We design IP, so we could then choos= e when things >will be implemented. 250 Mhz for FPGA is very very optimist= ic ! >On our system it must have only memory+f-cpus+io controler,= that's all. >One more chip will increase the price for almost nothing. >> Just an idea : beside the LSU for each CPU (internal LSU)= , we can have a >> external LSU which only contains the locked entries : >does this mean that a specific instruction is needed ? > >>>> ??? yes : separate unit implies a separate instruction. pure example of associated ideas. >>>From my point of view LSU, is kind of L0 caches. So some = instruction give hint for it, but that's only hint. >i wanted to do this through the SRs, in order to not limit = the number >of running locks/semaphores. > >>>> You can't use SR for that refind an old Christophe post= . That's >simply impossible with SR that are only write and read. you forgot that since we design the stuff, we are free to modify whatever parts do not fit in the "big picture". but let's forget about SRs now. The "pseudo-LSU" idea seems promising (but protection, scheduling and atomicity are still problems if we don't use the register association = flags. >> if a CPU do normal load/store, just bypass external LSU := faster behavior. >> if a CPU do lock load, set a new entry in external LSU. >> if a CPU do lock store, check if entry is in external LSU= . >> This external LSU can be seen as a special memory. > >looks cool but there is a problem : how do you manage coher= ency between >the usual 'L0' LSU and the special one ? > >>>> LSU is only a caches. and cache coherency is not an issue for you ? what is the _real_ cost for this ? * if the same addressing space (memory) is used, then this will conflict with other ongoing streams. * if the LSU is parallel to the lock unit, the units must be synchronised and keep coherency. * if the units are in series, then one will slow down the other. To these problem, there is a simple solution : create a new adressing space that does not coincide with the memory space. We can apply some of the techniques of the LSU and forget about coherency. >>>>i must rethink about that. But if you need to keep the e= xternal LSU coherent with internal LSU, i don't understand the interrest= of the external lsu. >The problem of splitting the functions is a natural one, bu= t i wouldn't >put this in the memory addressing range, as it conflicts wi= th the LSU >and coherency between the units will adds more problems (an= d shift >the SW problems to the HW, but HW is usually more difficult= to design, >particularly when there is no code). > >I would propose an independent "lock" space for this purpos= e, >so this wouldn't conflict with the memory space. The same k= inds >of techniques and protections can be enforced (N entries, a= ssociative >addressing, trap on illegal ranges...) but it's much more s= impler. >Instructions would be "lock imm/reg, value, result" and >"release imm/reg, result". no addressing, no TLB access/mis= s, >no granularity problems (memory should be reserved for high= -bandwidth, >large chunk transfers, and a single byte or word is an over= kill). > >>>> lock aren't so common but using 20 pins to do that > is really an overkill. it is also an overkill to use memory (with the 256-bit granu= larity) for a single 32-bit lock. And we are not forced to use >>> no it's not !!!!!! Such lock are really uncommon in prog= ram. So lose even one pin is soon too much. external pins either. Look at the bottom of the message where we start to agree that the FSB can support special messages that can be harmlessly interlevead in the memory streams and bursts. >>>That's called bus fonctionnality, and we could extend the= wishbone for it. >You see, i try to bring solutions, too. i hope someone will= enhance >on them. Thanks to Crhistophe for the "parallel LSU" idea, = it's less >scary than the SRs and can reuse a lot of existing methods. > >Btw, in a multi-CPU configuration, an interconnexion networ= k can >be dedicated to passing lock messages, if it can't be multi= plexed > >>>> overkill !!! i said "if". but it seems that we what we want is a contradiction in itse= lf. We want "high-end performance" with low-level technology, an= d even though there are some techniques, we can't get more tha= n what we pay. >>>>False ! We work in a world where pin count is a very lim= ited ressource for many different raison (power consomption, pack= age price, routing,...). >>>> So a pin, represent some Gbits/s of bandwith. If it's n= ot often use, this number decrease, and it's a waste of IO capacities= ! >>>>imagine 99% of the time io bus are use to communicate wi= th other cpu, 1% for locking. What do you prefer : increasing the spe= ed of the 1% by 50% or increasing the speed of the 99% by 10% ? >with the memory streams on the front-side bus (this last id= ea >is however what will be certainly implemented first). > >>>> It's only a new fonctionnality of the bus a new transac= tion, that's all. that's what i said. it's not difficult to modify existing protocols to include these "messages". >>>Yep ! >This is a common technique in large computers. > >>>>> Old large computer, with frequency of 50 Mhz, with > no really wire routing problem, that cost millions dollars= ,... sorry about the wire routing problems. If they cost so much, it's because the routing is the main problem. and if the routing is so expensive, it's efficient. you get what you pay, there is no magic. >>>So we know for low cost we can't have lot of wire. I pref= er buy a big pc rather than a bi-UIII, it cost 5x the price for the same performance...=20 see you on thursday, > nicO >> A+ >WHYGEE ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Aug 30 16:16:44 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17koq4-0006rl-00 for ; Fri, 30 Aug 2002 18:41:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:40 +0200 (CEST) Received: (qmail 24435 invoked by uid 0); 30 Aug 2002 14:16:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 30 Aug 2002 14:16:58 -0000 Received: by moria.seul.org (Postfix) id 23A4715E79D; Fri, 30 Aug 2002 10:16:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E4FBB15E7A3; Fri, 30 Aug 2002 10:16:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 1ABA715E79D for ; Fri, 30 Aug 2002 10:16:55 -0400 (EDT) Received: from ifurita (80.14.37.83) by smtp.laposte.net (6.0.053) id 3D32A1F9002C67BD for f-cpu@seul.org; Fri, 30 Aug 2002 16:16:54 +0200 Message-ID: <001701c2502f$df504560$0100000a@ifurita> From: "Christophe Avoinne" To: Subject: [f-cpu] Hot issue : external LSU ? Date: Fri, 30 Aug 2002 16:16:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Humm, well this discussion seems to be very hot. The best I can do is to expose better the different ways i saw (they must or not have their drawbacks) : First : ------ The locked load/store cannot be shared with the same instructions of normal load/store. Why ? because lstore is not a simple conditional store, we really need to catch the test result into a register to check if a locked write occurs because numerous algorithms needs this information after executing a locked store. So you must forget the idea to put the locked load/store in a conditional load/store format. Second : --------- Most of data don't need to be shared between CPU, so normal load/store without any synchronisation can be done at full speed. In fact, it is up to the software programmer not to abuse locked load/store operations, since there is no real solution to speedup them (they would always be slower than normal load/store operations). --- In the case of a uniprocessor : ------------------------------ locked load/store can be done easily in the LSU with a bit acting like a token. The locked load put a token in a LSU entry, the first locked store must be the first to take the token in the LSU entry. It should be easy enough. The only trouble is that you cannot handle an array of lock that way because of the byte-width of LSU entry (how many bytes does an LSU entry represent ?) the fastest way : if i 'locked load' two contiguous words i would in fact set the token in the same LSU entry. So if I 'locked store' the two contiguous words, the last one would fail (not what we expect in fact, but it will just slowdown). But if you array of large node with a lock word well separated, this trouble should disappear. I can see some error about using a separate address space for locking. You should not read 'locked load/store' as a semaphore 'acquire/release', which is not exactly the purpose of CAS and CAS2. Just consider an atomic stack, you want to push into or pop element from a stack atomically. You just need to change the top pointer with a CAS (so the need for 'locked load/store' to be able to access the same space address), instead you need to acquire semaphore first, then modify the top pointer then release semaphore, which gives us not exactly the same behaviour (blocking solution). Another problem, just imagine you need to update an array entry in a user array. This array is being shared. It could be used a locked load/store to be sure that no other cpu or task is doing something else with the same entry meanwhile (very fine-grained synchronisation). Using a semaphore would force to associate one semaphore per entry... So, please don't confuse 'locked load/store' with semaphore concept and don't think using separate address space is the solution for 'll/sc' counterpart. Your acquire/release suggestion, say, is another solution for another locking purpose. --- In the case of a multi-processor : --------------------------------- having an LSU for each processor leads to a coherency problem. To share locked entry in each LSU, is not a good idea, especially for CPU which never access those locked memory places. besides, it is difficult and slow to propagate such infos between LSUs. It is why i was wondering if using an external LSU shared for all CPU could be a solution. You must see it just as a suggestion that can be down or improved. Two cases: - locked entries are kept both in internal and external LSUs; - locked entries are only kept in external LSU; I don't think coherency between internal and external LSUs is a real matter (I may be wrong). locked entries are kept in both LSUs :- normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). - locked load sets a lock into internal (for intra-cpu locking) and external (for inter-cpu locking) LSU entries, no matter their contents. - locked store checks this lock into internal (for intra-cpu locking) AND external (for inter-cpu locking) LSU entries. Having this lock bit in internal LSU allows us to remove the necessity to have an external LSU for uniprocessor (just need cpu intra-locking), so external LSU is just an option to have inter-cpu locking capability. If an external LSU is not present : - locked load sets a lock into internal (for intra-cpu locking). - locked store checks this lock into internal (for intra-cpu locking). locked entries are only kept in external LSU : - normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). In fact internal LSU has no locked LSU entry (insensitive to locked load/store). - locked load/store always operate on external LSU entries instead of internal LSU entries. - locked load sets a lock into external (for intra/inter-cpu locking) LSU entry. - locked store checks this lock into external (for intra/inter-cpu locking) LSU entry. You need to have an external LSU even for a uniprocessor. An external LSU entry is really shared between CPU without duplicata, so there is no coherency problem. A mixture : ----------- lock load/store can have a mixture : an only intra-cpu locking (only use internal LSU), an only inter-cpu locking (only use external LSU) or both intra/extra-cpu locking just using suffixes to do so. That way you can even use only intra-cpu locks for threads in a multiprocessor for faster execution than usual intra/inter-cou locks (i'm thinking about locks which are only relevant for threads of a same process in one cpu only ). As a result : ------------ The main idea behind the external LSU is to prevent from normal load/store to be dependent of a global locking. An application should use mostly this solution. Threads in a process could use intra-cpu locked load/store if necessary. Intra/inter-cpu locked load/store would only be used if coherency between CPU is needed. Inter-cpu locked load/store can be used for situation we know there is only one task to access but you need coherency amongst cpus. That's all folks. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Aug 30 17:07:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17koq9-0006rl-00 for ; Fri, 30 Aug 2002 18:41:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:45 +0200 (CEST) Received: (qmail 9746 invoked by uid 0); 30 Aug 2002 15:07:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 30 Aug 2002 15:07:21 -0000 Received: by moria.seul.org (Postfix) id 47B0F15E7A4; Fri, 30 Aug 2002 11:07:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 028A115E7A7; Fri, 30 Aug 2002 11:07:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 71F0315E7A4 for ; Fri, 30 Aug 2002 11:07:19 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id 99DDD5F762 for ; Fri, 30 Aug 2002 17:07:18 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 84B7687372; Fri, 30 Aug 2002 17:07:18 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Conditionnal load and store, the return Message-ID: <1030720038.3d6f8a2677363@imp.free.fr> Date: Fri, 30 Aug 2002 17:07:18 +0200 (MEST) From: Cedric BAIL References: <200208042145.35776.cedric.bail@free.fr> <006201c24b74$fa0953c0$553d0f50@hli> <1030200544.3d679ce095ead@imp.free.fr> <002301c24b9a$2aa3cd60$553d0f50@hli> <1030410212.3d6acfe45bf20@imp.free.fr> <001501c24dac$960f6460$a73d0f50@hli> <1030451613.3d6b719d6eee5@imp.free.fr> <004b01c24e22$4911c0b0$0100000a@ifurita> <1030569339.3d6d3d7b4bad3@imp.free.fr> <010001c24f41$cfee88a0$0100000a@ifurita> <3D6EAEB7.AC5B0474@f-cpu.org> In-Reply-To: <3D6EAEB7.AC5B0474@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.251.54.39 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > the condition test AND the pointer check happen at the same time. > The decision (stall, trap or issue) is taken during the Xbar stage. > So there is no problem such as what Cédric explained (with the Null > pointer and false condition). The issue logic should be smart enough > (and it's not too difficult) to avoid these situations. > Let's say that the condition has precedence over the pointer. > In HW, condition is faster than pointer LUT reading, so it's also > a natural choice. Hey, that's a good news ;-) I wait for this answer since two week ;-) I think I will add this for the next release. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Fri Aug 30 22:31:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17koq9-0006rl-01 for ; Fri, 30 Aug 2002 18:41:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 Aug 2002 18:41:45 +0200 (CEST) Received: (qmail 29520 invoked by uid 0); 30 Aug 2002 15:31:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 30 Aug 2002 15:31:21 -0000 Received: by moria.seul.org (Postfix) id F1D7215E7A2; Fri, 30 Aug 2002 11:31:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5FC415E7A6; Fri, 30 Aug 2002 11:31:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 89D7015E7A2 for ; Fri, 30 Aug 2002 11:31:19 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 4E8721711; Fri, 30 Aug 2002 17:31:18 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] THasm 0.1 Date: Fri, 30 Aug 2002 17:31:18 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 Lavergne Thomas : >> i wish i'll integrate it soon to the snapshots. > >This is only a test version for the format instruction idea, it was = >quickly out of date, I think it could be better to wait for the next rele= ase. i don't think it's a problem ;-) i don't know when i can work on a new snapshot, so don't worry. >-- = >Thomas Lavergne =22Le vrai r=EAveur est celui qui r= =EAve > de l'impossible.=22 (Elsa Triole= t) >thomas.lavergne=40laposte.net >d-12=40laposte.net ICQ:=23137121910 http://assoc.wanadoo.fr/thalli= um/ > > >************************************************************* >To unsubscribe, send an e-mail to majordomo=40seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 30 19:20:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ktzk-0001u7-01 for ; Sat, 31 Aug 2002 00:12:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 00:12:00 +0200 (CEST) Received: (qmail 14885 invoked by uid 0); 30 Aug 2002 17:20:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 30 Aug 2002 17:20:46 -0000 Received: by moria.seul.org (Postfix) id 4D2F915E7A7; Fri, 30 Aug 2002 13:20:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 221A515E7AA; Fri, 30 Aug 2002 13:20:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 750A115E7A7 for ; Fri, 30 Aug 2002 13:20:44 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200208301720.21e0; Fri, 30 Aug 2002 17:20:33 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] Hot issue : external LSU ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Aug 2002 17:20:33 GMT Message-id: <200208301720.21e0@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i will reread this carefully later but juste one question : = Does lstore/cload could be replaced by CAS and CAS2 ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 30/08/02 Objet: [f-cpu] Hot issue : external LSU ? Humm, well this discussion seems to be very hot. The best I can do is to expose better the different ways i s= aw (they must or not have their drawbacks) : First : ------ The locked load/store cannot be shared with the same instruc= tions of normal load/store. Why ? because lstore is not a simple conditional= store, we really need to catch the test result into a register to chec= k if a locked write occurs because numerous algorithms needs this informat= ion after executing a locked store. So you must forget the idea to put= the locked load/store in a conditional load/store format. Second : --------- Most of data don't need to be shared between CPU, so normal = load/store without any synchronisation can be done at full speed. In fa= ct, it is up to the software programmer not to abuse locked load/store opera= tions, since there is no real solution to speedup them (they would always= be slower than normal load/store operations). --- In the case of a uniprocessor : ------------------------------ locked load/store can be done easily in the LSU with a bit a= cting like a token. The locked load put a token in a LSU entry, the first= locked store must be the first to take the token in the LSU entry. It sho= uld be easy enough. The only trouble is that you cannot handle an array = of lock that way because of the byte-width of LSU entry (how many bytes does = an LSU entry represent ?) the fastest way : if i 'locked load' two contig= uous words i would in fact set the token in the same LSU entry. So if I '= locked store' the two contiguous words, the last one would fail (not what = we expect in fact, but it will just slowdown). But if you array of large = node with a lock word well separated, this trouble should disappear. I can see some error about using a separate address space fo= r locking. You should not read 'locked load/store' as a semaphore 'acquire/= release', which is not exactly the purpose of CAS and CAS2. Just consider an= atomic stack, you want to push into or pop element from a stack atomically= . You just need to change the top pointer with a CAS (so the need for 'locke= d load/store' to be able to access the same space address), instead you need = to acquire semaphore first, then modify the top pointer then release se= maphore, which gives us not exactly the same behaviour (blocking solution). Another problem, just imagine you need to update an array en= try in a user array. This array is being shared. It could be used a locked= load/store to be sure that no other cpu or task is doing something else wi= th the same entry meanwhile (very fine-grained synchronisation). Using a= semaphore would force to associate one semaphore per entry... So, please don't confuse 'locked load/store' with semaphore = concept and don't think using separate address space is the solution for= 'll/sc' counterpart. Your acquire/release suggestion, say, is anoth= er solution for another locking purpose. --- In the case of a multi-processor : --------------------------------- having an LSU for each processor leads to a coherency proble= m. To share locked entry in each LSU, is not a good idea, especially for= CPU which never access those locked memory places. besides, it is difficult = and slow to propagate such infos between LSUs. It is why i was wondering if using an external LSU shared fo= r all CPU could be a solution. You must see it just as a suggestion that can= be down or improved. Two cases: - locked entries are kept both in internal and external LSUs= ; - locked entries are only kept in external LSU; I don't think coherency between internal and external LSUs i= s a real matter (I may be wrong). locked entries are kept in both LSUs :- normal load/store do= n't bother with external LSU. Internal LSU accesses directly the memory (we = can expect it is what the software programmer will use most time). - locked load sets a lock into internal (for intra-cpu locki= ng) and external (for inter-cpu locking) LSU entries, no matter their content= s. - locked store checks this lock into internal (for intra-cpu= locking) AND external (for inter-cpu locking) LSU entries. Having this lock bit in internal LSU allows us to remove the= necessity to have an external LSU for uniprocessor (just need cpu intra-l= ocking), so external LSU is just an option to have inter-cpu locking cap= ability. If an external LSU is not present : - locked load sets a lock into internal (for intra-cpu locki= ng). - locked store checks this lock into internal (for intra-cpu= locking). locked entries are only kept in external LSU : - normal load/store don't bother with external LSU. Internal= LSU accesses directly the memory (we can expect it is what the software p= rogrammer will use most time). In fact internal LSU has no locked LSU entry (insensitive to locked load/store). - locked load/store always operate on external LSU entries i= nstead of internal LSU entries. - locked load sets a lock into external (for intra/inter-cpu= locking) LSU entry. - locked store checks this lock into external (for intra/int= er-cpu locking) LSU entry. You need to have an external LSU even for a uniprocessor. An external LSU entry is really shared between CPU without d= uplicata, so there is no coherency problem. A mixture : ----------- lock load/store can have a mixture : an only intra-cpu locki= ng (only use internal LSU), an only inter-cpu locking (only use external = LSU) or both intra/extra-cpu locking just using suffixes to do so. That w= ay you can even use only intra-cpu locks for threads in a multiprocessor for= faster execution than usual intra/inter-cou locks (i'm thinking abo= ut locks which are only relevant for threads of a same process in one cpu o= nly ). As a result : ------------ The main idea behind the external LSU is to prevent from nor= mal load/store to be dependent of a global locking. An application should u= se mostly this solution. Threads in a process could use intra-cpu locked lo= ad/store if necessary. Intra/inter-cpu locked load/store would only be u= sed if coherency between CPU is needed. Inter-cpu locked load/store can be us= ed for situation we know there is only one task to access but you need cohere= ncy amongst cpus. That's all folks. ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________________ Pour mieux recevoir vos emails, utilisez un PC plus performa= nt ! D=E9couvrez la nouvelle gamme DELL en exclusivit=E9 sur i (f= rance) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Aug 30 20:57:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ktzm-0001u7-01 for ; Sat, 31 Aug 2002 00:12:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 00:12:02 +0200 (CEST) Received: (qmail 14478 invoked by uid 0); 30 Aug 2002 18:57:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 30 Aug 2002 18:57:17 -0000 Received: by moria.seul.org (Postfix) id 4D76515E76D; Fri, 30 Aug 2002 14:57:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3117E15E776; Fri, 30 Aug 2002 14:57:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 7D26715E76D for ; Fri, 30 Aug 2002 14:57:16 -0400 (EDT) Received: from ifurita (80.14.37.83) by smtp.laposte.net (6.0.053) id 3D2EB60900328DE8 for f-cpu@seul.org; Fri, 30 Aug 2002 20:57:15 +0200 Message-ID: <000701c25057$0954e290$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Fri, 30 Aug 2002 20:57:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N * 'CAS' can be written with a pair of 'locked load/store', very easily. - read a value with 'locked load' and compare if it is matching with old value, if not CAS fails. - store the new value with 'locked store', if it fails, CAS fails too. - elsewhere CAS succeeds. * 'CAS2' is a little bit more difficult to do but it can. But If you want a good one you must have a pairable 'lock load/store' (ll/sc, llp,scp), but i think very few people want to enter in such consideration, because it is quite difficult to handle in hardware : 'll' only set only the first lock bit. 'llp' set a second lock bit. 'scp' checks the both lock bits are set and clears the second lock bit. 'sc' checks the first lock bit is set and the second lock bit is cleared, then clears the first lock bit. As you can see, we need a way to link two lock bits together whereas they are not in the same entry. Mandatory order of execution : ll -> llp -> scp -> sc. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Friday, August 30, 2002 7:20 PM Subject: Rep:[f-cpu] Hot issue : external LSU ? i will reread this carefully later but juste one question : Does lstore/cload could be replaced by CAS and CAS2 ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 30/08/02 Objet: [f-cpu] Hot issue : external LSU ? Humm, well this discussion seems to be very hot. The best I can do is to expose better the different ways i saw (they must or not have their drawbacks) : First : ------ The locked load/store cannot be shared with the same instructions of normal load/store. Why ? because lstore is not a simple conditional store, we really need to catch the test result into a register to check if a locked write occurs because numerous algorithms needs this information after executing a locked store. So you must forget the idea to put the locked load/store in a conditional load/store format. Second : --------- Most of data don't need to be shared between CPU, so normal load/store without any synchronisation can be done at full speed. In fact, it is up to the software programmer not to abuse locked load/store operations, since there is no real solution to speedup them (they would always be slower than normal load/store operations). --- In the case of a uniprocessor : ------------------------------ locked load/store can be done easily in the LSU with a bit acting like a token. The locked load put a token in a LSU entry, the first locked store must be the first to take the token in the LSU entry. It should be easy enough. The only trouble is that you cannot handle an array of lock that way because of the byte-width of LSU entry (how many bytes does an LSU entry represent ?) the fastest way : if i 'locked load' two contiguous words i would in fact set the token in the same LSU entry. So if I 'locked store' the two contiguous words, the last one would fail (not what we expect in fact, but it will just slowdown). But if you array of large node with a lock word well separated, this trouble should disappear. I can see some error about using a separate address space for locking. You should not read 'locked load/store' as a semaphore 'acquire/release', which is not exactly the purpose of CAS and CAS2. Just consider an atomic stack, you want to push into or pop element from a stack atomically. You just need to change the top pointer with a CAS (so the need for 'locked load/store' to be able to access the same space address), instead you need to acquire semaphore first, then modify the top pointer then release semaphore, which gives us not exactly the same behaviour (blocking solution). Another problem, just imagine you need to update an array entry in a user array. This array is being shared. It could be used a locked load/store to be sure that no other cpu or task is doing something else with the same entry meanwhile (very fine-grained synchronisation). Using a semaphore would force to associate one semaphore per entry... So, please don't confuse 'locked load/store' with semaphore concept and don't think using separate address space is the solution for 'll/sc' counterpart. Your acquire/release suggestion, say, is another solution for another locking purpose. --- In the case of a multi-processor : --------------------------------- having an LSU for each processor leads to a coherency problem. To share locked entry in each LSU, is not a good idea, especially for CPU which never access those locked memory places. besides, it is difficult and slow to propagate such infos between LSUs. It is why i was wondering if using an external LSU shared for all CPU could be a solution. You must see it just as a suggestion that can be down or improved. Two cases: - locked entries are kept both in internal and external LSUs; - locked entries are only kept in external LSU; I don't think coherency between internal and external LSUs is a real matter (I may be wrong). locked entries are kept in both LSUs :- normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). - locked load sets a lock into internal (for intra-cpu locking) and external (for inter-cpu locking) LSU entries, no matter their contents. - locked store checks this lock into internal (for intra-cpu locking) AND external (for inter-cpu locking) LSU entries. Having this lock bit in internal LSU allows us to remove the necessity to have an external LSU for uniprocessor (just need cpu intra-locking), so external LSU is just an option to have inter-cpu locking capability. If an external LSU is not present : - locked load sets a lock into internal (for intra-cpu locking). - locked store checks this lock into internal (for intra-cpu locking). locked entries are only kept in external LSU : - normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). In fact internal LSU has no locked LSU entry (insensitive to locked load/store). - locked load/store always operate on external LSU entries instead of internal LSU entries. - locked load sets a lock into external (for intra/inter-cpu locking) LSU entry. - locked store checks this lock into external (for intra/inter-cpu locking) LSU entry. You need to have an external LSU even for a uniprocessor. An external LSU entry is really shared between CPU without duplicata, so there is no coherency problem. A mixture : ----------- lock load/store can have a mixture : an only intra-cpu locking (only use internal LSU), an only inter-cpu locking (only use external LSU) or both intra/extra-cpu locking just using suffixes to do so. That way you can even use only intra-cpu locks for threads in a multiprocessor for faster execution than usual intra/inter-cou locks (i'm thinking about locks which are only relevant for threads of a same process in one cpu only ). As a result : ------------ The main idea behind the external LSU is to prevent from normal load/store to be dependent of a global locking. An application should use mostly this solution. Threads in a process could use intra-cpu locked load/store if necessary. Intra/inter-cpu locked load/store would only be used if coherency between CPU is needed. Inter-cpu locked load/store can be used for situation we know there is only one task to access but you need coherency amongst cpus. That's all folks. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ Pour mieux recevoir vos emails, utilisez un PC plus performant ! Découvrez la nouvelle gamme DELL en exclusivité sur i (france) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Aug 30 21:30:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ku04-0001u7-00 for ; Sat, 31 Aug 2002 00:12:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 00:12:20 +0200 (CEST) Received: (qmail 27845 invoked by uid 0); 30 Aug 2002 19:30:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 30 Aug 2002 19:30:58 -0000 Received: by moria.seul.org (Postfix) id 1F3CD15E76E; Fri, 30 Aug 2002 15:30:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2E7E15E779; Fri, 30 Aug 2002 15:30:56 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 80CA915E76E for ; Fri, 30 Aug 2002 15:30:56 -0400 (EDT) Received: from ifurita (80.14.37.83) by smtp.laposte.net (6.0.053) id 3D2EB60900329420 for f-cpu@seul.org; Fri, 30 Aug 2002 21:30:55 +0200 Message-ID: <002301c2505b$b1d3f7e0$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Fri, 30 Aug 2002 21:30:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N sorry, i understood the contrary of what you wanted. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Friday, August 30, 2002 7:20 PM Subject: Rep:[f-cpu] Hot issue : external LSU ? i will reread this carefully later but juste one question : Does lstore/cload could be replaced by CAS and CAS2 ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 30/08/02 Objet: [f-cpu] Hot issue : external LSU ? Humm, well this discussion seems to be very hot. The best I can do is to expose better the different ways i saw (they must or not have their drawbacks) : First : ------ The locked load/store cannot be shared with the same instructions of normal load/store. Why ? because lstore is not a simple conditional store, we really need to catch the test result into a register to check if a locked write occurs because numerous algorithms needs this information after executing a locked store. So you must forget the idea to put the locked load/store in a conditional load/store format. Second : --------- Most of data don't need to be shared between CPU, so normal load/store without any synchronisation can be done at full speed. In fact, it is up to the software programmer not to abuse locked load/store operations, since there is no real solution to speedup them (they would always be slower than normal load/store operations). --- In the case of a uniprocessor : ------------------------------ locked load/store can be done easily in the LSU with a bit acting like a token. The locked load put a token in a LSU entry, the first locked store must be the first to take the token in the LSU entry. It should be easy enough. The only trouble is that you cannot handle an array of lock that way because of the byte-width of LSU entry (how many bytes does an LSU entry represent ?) the fastest way : if i 'locked load' two contiguous words i would in fact set the token in the same LSU entry. So if I 'locked store' the two contiguous words, the last one would fail (not what we expect in fact, but it will just slowdown). But if you array of large node with a lock word well separated, this trouble should disappear. I can see some error about using a separate address space for locking. You should not read 'locked load/store' as a semaphore 'acquire/release', which is not exactly the purpose of CAS and CAS2. Just consider an atomic stack, you want to push into or pop element from a stack atomically. You just need to change the top pointer with a CAS (so the need for 'locked load/store' to be able to access the same space address), instead you need to acquire semaphore first, then modify the top pointer then release semaphore, which gives us not exactly the same behaviour (blocking solution). Another problem, just imagine you need to update an array entry in a user array. This array is being shared. It could be used a locked load/store to be sure that no other cpu or task is doing something else with the same entry meanwhile (very fine-grained synchronisation). Using a semaphore would force to associate one semaphore per entry... So, please don't confuse 'locked load/store' with semaphore concept and don't think using separate address space is the solution for 'll/sc' counterpart. Your acquire/release suggestion, say, is another solution for another locking purpose. --- In the case of a multi-processor : --------------------------------- having an LSU for each processor leads to a coherency problem. To share locked entry in each LSU, is not a good idea, especially for CPU which never access those locked memory places. besides, it is difficult and slow to propagate such infos between LSUs. It is why i was wondering if using an external LSU shared for all CPU could be a solution. You must see it just as a suggestion that can be down or improved. Two cases: - locked entries are kept both in internal and external LSUs; - locked entries are only kept in external LSU; I don't think coherency between internal and external LSUs is a real matter (I may be wrong). locked entries are kept in both LSUs :- normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). - locked load sets a lock into internal (for intra-cpu locking) and external (for inter-cpu locking) LSU entries, no matter their contents. - locked store checks this lock into internal (for intra-cpu locking) AND external (for inter-cpu locking) LSU entries. Having this lock bit in internal LSU allows us to remove the necessity to have an external LSU for uniprocessor (just need cpu intra-locking), so external LSU is just an option to have inter-cpu locking capability. If an external LSU is not present : - locked load sets a lock into internal (for intra-cpu locking). - locked store checks this lock into internal (for intra-cpu locking). locked entries are only kept in external LSU : - normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). In fact internal LSU has no locked LSU entry (insensitive to locked load/store). - locked load/store always operate on external LSU entries instead of internal LSU entries. - locked load sets a lock into external (for intra/inter-cpu locking) LSU entry. - locked store checks this lock into external (for intra/inter-cpu locking) LSU entry. You need to have an external LSU even for a uniprocessor. An external LSU entry is really shared between CPU without duplicata, so there is no coherency problem. A mixture : ----------- lock load/store can have a mixture : an only intra-cpu locking (only use internal LSU), an only inter-cpu locking (only use external LSU) or both intra/extra-cpu locking just using suffixes to do so. That way you can even use only intra-cpu locks for threads in a multiprocessor for faster execution than usual intra/inter-cou locks (i'm thinking about locks which are only relevant for threads of a same process in one cpu only ). As a result : ------------ The main idea behind the external LSU is to prevent from normal load/store to be dependent of a global locking. An application should use mostly this solution. Threads in a process could use intra-cpu locked load/store if necessary. Intra/inter-cpu locked load/store would only be used if coherency between CPU is needed. Inter-cpu locked load/store can be used for situation we know there is only one task to access but you need coherency amongst cpus. That's all folks. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ Pour mieux recevoir vos emails, utilisez un PC plus performant ! Découvrez la nouvelle gamme DELL en exclusivité sur i (france) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Aug 30 21:41:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ku05-0001u7-00 for ; Sat, 31 Aug 2002 00:12:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 00:12:21 +0200 (CEST) Received: (qmail 19678 invoked by uid 0); 30 Aug 2002 19:41:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 30 Aug 2002 19:41:32 -0000 Received: by moria.seul.org (Postfix) id 98DD715E772; Fri, 30 Aug 2002 15:41:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8462A15E77E; Fri, 30 Aug 2002 15:41:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 1D7E415E772 for ; Fri, 30 Aug 2002 15:41:31 -0400 (EDT) Received: from ifurita (80.14.37.83) by smtp.laposte.net (6.0.053) id 3D359CE9002A3308 for f-cpu@seul.org; Fri, 30 Aug 2002 21:41:30 +0200 Message-ID: <003401c2505d$37cabf90$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Fri, 30 Aug 2002 21:41:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well, I try but I don't see any interest to emulate 'll/sc' with a CAS. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Friday, August 30, 2002 7:20 PM Subject: Rep:[f-cpu] Hot issue : external LSU ? i will reread this carefully later but juste one question : Does lstore/cload could be replaced by CAS and CAS2 ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 30/08/02 Objet: [f-cpu] Hot issue : external LSU ? Humm, well this discussion seems to be very hot. The best I can do is to expose better the different ways i saw (they must or not have their drawbacks) : First : ------ The locked load/store cannot be shared with the same instructions of normal load/store. Why ? because lstore is not a simple conditional store, we really need to catch the test result into a register to check if a locked write occurs because numerous algorithms needs this information after executing a locked store. So you must forget the idea to put the locked load/store in a conditional load/store format. Second : --------- Most of data don't need to be shared between CPU, so normal load/store without any synchronisation can be done at full speed. In fact, it is up to the software programmer not to abuse locked load/store operations, since there is no real solution to speedup them (they would always be slower than normal load/store operations). --- In the case of a uniprocessor : ------------------------------ locked load/store can be done easily in the LSU with a bit acting like a token. The locked load put a token in a LSU entry, the first locked store must be the first to take the token in the LSU entry. It should be easy enough. The only trouble is that you cannot handle an array of lock that way because of the byte-width of LSU entry (how many bytes does an LSU entry represent ?) the fastest way : if i 'locked load' two contiguous words i would in fact set the token in the same LSU entry. So if I 'locked store' the two contiguous words, the last one would fail (not what we expect in fact, but it will just slowdown). But if you array of large node with a lock word well separated, this trouble should disappear. I can see some error about using a separate address space for locking. You should not read 'locked load/store' as a semaphore 'acquire/release', which is not exactly the purpose of CAS and CAS2. Just consider an atomic stack, you want to push into or pop element from a stack atomically. You just need to change the top pointer with a CAS (so the need for 'locked load/store' to be able to access the same space address), instead you need to acquire semaphore first, then modify the top pointer then release semaphore, which gives us not exactly the same behaviour (blocking solution). Another problem, just imagine you need to update an array entry in a user array. This array is being shared. It could be used a locked load/store to be sure that no other cpu or task is doing something else with the same entry meanwhile (very fine-grained synchronisation). Using a semaphore would force to associate one semaphore per entry... So, please don't confuse 'locked load/store' with semaphore concept and don't think using separate address space is the solution for 'll/sc' counterpart. Your acquire/release suggestion, say, is another solution for another locking purpose. --- In the case of a multi-processor : --------------------------------- having an LSU for each processor leads to a coherency problem. To share locked entry in each LSU, is not a good idea, especially for CPU which never access those locked memory places. besides, it is difficult and slow to propagate such infos between LSUs. It is why i was wondering if using an external LSU shared for all CPU could be a solution. You must see it just as a suggestion that can be down or improved. Two cases: - locked entries are kept both in internal and external LSUs; - locked entries are only kept in external LSU; I don't think coherency between internal and external LSUs is a real matter (I may be wrong). locked entries are kept in both LSUs :- normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). - locked load sets a lock into internal (for intra-cpu locking) and external (for inter-cpu locking) LSU entries, no matter their contents. - locked store checks this lock into internal (for intra-cpu locking) AND external (for inter-cpu locking) LSU entries. Having this lock bit in internal LSU allows us to remove the necessity to have an external LSU for uniprocessor (just need cpu intra-locking), so external LSU is just an option to have inter-cpu locking capability. If an external LSU is not present : - locked load sets a lock into internal (for intra-cpu locking). - locked store checks this lock into internal (for intra-cpu locking). locked entries are only kept in external LSU : - normal load/store don't bother with external LSU. Internal LSU accesses directly the memory (we can expect it is what the software programmer will use most time). In fact internal LSU has no locked LSU entry (insensitive to locked load/store). - locked load/store always operate on external LSU entries instead of internal LSU entries. - locked load sets a lock into external (for intra/inter-cpu locking) LSU entry. - locked store checks this lock into external (for intra/inter-cpu locking) LSU entry. You need to have an external LSU even for a uniprocessor. An external LSU entry is really shared between CPU without duplicata, so there is no coherency problem. A mixture : ----------- lock load/store can have a mixture : an only intra-cpu locking (only use internal LSU), an only inter-cpu locking (only use external LSU) or both intra/extra-cpu locking just using suffixes to do so. That way you can even use only intra-cpu locks for threads in a multiprocessor for faster execution than usual intra/inter-cou locks (i'm thinking about locks which are only relevant for threads of a same process in one cpu only ). As a result : ------------ The main idea behind the external LSU is to prevent from normal load/store to be dependent of a global locking. An application should use mostly this solution. Threads in a process could use intra-cpu locked load/store if necessary. Intra/inter-cpu locked load/store would only be used if coherency between CPU is needed. Inter-cpu locked load/store can be used for situation we know there is only one task to access but you need coherency amongst cpus. That's all folks. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________________________ __ Pour mieux recevoir vos emails, utilisez un PC plus performant ! Découvrez la nouvelle gamme DELL en exclusivité sur i (france) http://www.ifrance.com/_reloc/signhdell ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Aug 30 22:35:50 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ku07-0001u7-00 for ; Sat, 31 Aug 2002 00:12:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 00:12:23 +0200 (CEST) Received: (qmail 31468 invoked by uid 0); 30 Aug 2002 20:12:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Aug 2002 20:12:20 -0000 Received: by moria.seul.org (Postfix) id EBA5C15E779; Fri, 30 Aug 2002 16:12:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADE0C15E781; Fri, 30 Aug 2002 16:12:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 40ADB15E779 for ; Fri, 30 Aug 2002 16:12:18 -0400 (EDT) Received: from ifrance.com (vlt4-151.n.club-internet.fr [194.158.109.151]) by relay-4v.club-internet.fr (Postfix) with ESMTP id BDBD016EA for ; Fri, 30 Aug 2002 22:12:14 +0200 (CEST) Message-ID: <3D6FD726.FC670D01@ifrance.com> Date: Fri, 30 Aug 2002 22:35:50 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On other world, does ll/sc are there to "emulate" true CAS ? In that cases, it's much more easy to create a kind of CAS instruction. This could be maid by linking 2 or more instructions (the first instruction raise a flag, and if the second instruction come, it's a true CAS). Then the system emit the CAS functionnality that should have the bus system. Exactly the same could be handle for CAS2 (could you reexplain why we need CAS2, Cedric explain to me that it isn't usefull, CAS is enough). nicO Christophe Avoinne a écrit : > > Well, I try but I don't see any interest to emulate 'll/sc' with a CAS. > > ----- Original Message ----- > From: "Nicolas Boulay" > To: > Sent: Friday, August 30, 2002 7:20 PM > Subject: Rep:[f-cpu] Hot issue : external LSU ? > > i will reread this carefully later but juste one question : Does > lstore/cload could be replaced by CAS and CAS2 ? > > nicO > > -----Message d'origine----- > De: "Christophe Avoinne" > A: > Date: 30/08/02 > Objet: [f-cpu] Hot issue : external LSU ? > > Humm, well this discussion seems to be very hot. > > The best I can do is to expose better the different ways i saw (they > must or > not have their drawbacks) : > > First : > ------ > The locked load/store cannot be shared with the same instructions of > normal > load/store. Why ? because lstore is not a simple conditional store, we > really need to catch the test result into a register to check if a > locked > write occurs because numerous algorithms needs this information after > executing a locked store. So you must forget the idea to put the locked > load/store in a conditional load/store format. > > Second : > --------- > Most of data don't need to be shared between CPU, so normal load/store > without any synchronisation can be done at full speed. In fact, it is up > to > the software programmer not to abuse locked load/store operations, since > there is no real solution to speedup them (they would always be slower > than > normal load/store operations). > > --- > > In the case of a uniprocessor : > ------------------------------ > > locked load/store can be done easily in the LSU with a bit acting like a > token. The locked load put a token in a LSU entry, the first locked > store > must be the first to take the token in the LSU entry. It should be easy > enough. The only trouble is that you cannot handle an array of lock that > way > because of the byte-width of LSU entry (how many bytes does an LSU entry > represent ?) the fastest way : if i 'locked load' two contiguous words i > would in fact set the token in the same LSU entry. So if I 'locked > store' > the two contiguous words, the last one would fail (not what we expect in > fact, but it will just slowdown). But if you array of large node with a > lock > word well separated, this trouble should disappear. > > I can see some error about using a separate address space for locking. > You > should not read 'locked load/store' as a semaphore 'acquire/release', > which > is not exactly the purpose of CAS and CAS2. Just consider an atomic > stack, > you want to push into or pop element from a stack atomically. You just > need > to change the top pointer with a CAS (so the need for 'locked > load/store' to > be able to access the same space address), instead you need to acquire > semaphore first, then modify the top pointer then release semaphore, > which > gives us not exactly the same behaviour (blocking solution). > > Another problem, just imagine you need to update an array entry in a > user > array. This array is being shared. It could be used a locked load/store > to > be sure that no other cpu or task is doing something else with the same > entry meanwhile (very fine-grained synchronisation). Using a semaphore > would > force to associate one semaphore per entry... > > So, please don't confuse 'locked load/store' with semaphore concept and > don't think using separate address space is the solution for 'll/sc' > counterpart. Your acquire/release suggestion, say, is another solution > for > another locking purpose. > > --- > > In the case of a multi-processor : > --------------------------------- > > having an LSU for each processor leads to a coherency problem. To share > locked entry in each LSU, is not a good idea, especially for CPU which > never > access those locked memory places. besides, it is difficult and slow to > propagate such infos between LSUs. > > It is why i was wondering if using an external LSU shared for all CPU > could > be a solution. You must see it just as a suggestion that can be down or > improved. > > Two cases: > - locked entries are kept both in internal and external LSUs; > - locked entries are only kept in external LSU; > > I don't think coherency between internal and external LSUs is a real > matter > (I may be wrong). > > locked entries are kept in both LSUs :- normal load/store don't bother > with > external LSU. Internal LSU accesses directly the memory (we can expect > it is > what the software programmer will use most time). > - locked load sets a lock into internal (for intra-cpu locking) and > external > (for inter-cpu locking) LSU entries, no matter their contents. > - locked store checks this lock into internal (for intra-cpu locking) > AND > external (for inter-cpu locking) LSU entries. > > Having this lock bit in internal LSU allows us to remove the necessity > to > have an external LSU for uniprocessor (just need cpu intra-locking), so > external LSU is just an option to have inter-cpu locking capability. > > If an external LSU is not present : > - locked load sets a lock into internal (for intra-cpu locking). > - locked store checks this lock into internal (for intra-cpu locking). > > locked entries are only kept in external LSU : > > - normal load/store don't bother with external LSU. Internal LSU > accesses > directly the memory (we can expect it is what the software programmer > will > use most time). In fact internal LSU has no locked LSU entry > (insensitive to > locked load/store). > - locked load/store always operate on external LSU entries instead of > internal LSU entries. > - locked load sets a lock into external (for intra/inter-cpu locking) > LSU > entry. > - locked store checks this lock into external (for intra/inter-cpu > locking) > LSU entry. > > You need to have an external LSU even for a uniprocessor. > > An external LSU entry is really shared between CPU without duplicata, so > there is no coherency problem. > > A mixture : > ----------- > lock load/store can have a mixture : an only intra-cpu locking (only use > internal LSU), an only inter-cpu locking (only use external LSU) or both > intra/extra-cpu locking just using suffixes to do so. That way you can > even > use only intra-cpu locks for threads in a multiprocessor for faster > execution than usual intra/inter-cou locks (i'm thinking about locks > which > are only relevant for threads of a same process in one cpu only ). > > As a result : > ------------ > > The main idea behind the external LSU is to prevent from normal > load/store > to be dependent of a global locking. An application should use mostly > this > solution. Threads in a process could use intra-cpu locked load/store if > necessary. Intra/inter-cpu locked load/store would only be used if > coherency > between CPU is needed. Inter-cpu locked load/store can be used for > situation > we know there is only one task to access but you need coherency amongst > cpus. > > That's all folks. > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ____________________________________________________________________________ > __ > Pour mieux recevoir vos emails, utilisez un PC plus performant ! > Découvrez la nouvelle gamme DELL en exclusivité sur i (france) > http://www.ifrance.com/_reloc/signhdell > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 31 01:14:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17kwZy-0003r2-00 for ; Sat, 31 Aug 2002 02:57:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 02:57:34 +0200 (CEST) Received: (qmail 28578 invoked by uid 0); 30 Aug 2002 23:14:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 30 Aug 2002 23:14:40 -0000 Received: by moria.seul.org (Postfix) id 125B615E77E; Fri, 30 Aug 2002 19:14:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E391015E7A8; Fri, 30 Aug 2002 19:14:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 7787D15E77E for ; Fri, 30 Aug 2002 19:14:38 -0400 (EDT) Received: from ifurita (81.48.49.242) by smtp.laposte.net (6.0.053) id 3D359CE9002A5434 for f-cpu@seul.org; Sat, 31 Aug 2002 01:14:37 +0200 Message-ID: <001501c2507a$fdc08500$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Sat, 31 Aug 2002 01:14:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "nico" To: Sent: Friday, August 30, 2002 10:35 PM Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > On other world, does ll/sc are there to "emulate" true CAS ? Not exactly, with "ll/sc" we can much more things than a CAS does. Instead of a comparison like in CAS we can have other tests or no test at all to do. We can do several interesting operations between a "ll" and "sc". CAS is in fact more specifical than "ll/sc". It is why I could find "ll/sc" more elegant than CAS from a software viewpoint. > In that cases, it's much more easy to create a kind of CAS instruction. > This could be maid by linking 2 or more instructions (the first > instruction raise a flag, and if the second instruction come, it's a > true CAS). I'm not sure about that... CAS must be an atomical read-check-modify operation. So if you want to split into two instructions, it is no longer a CAS and still a bit too specific. "ll/sc" is like a more general CAS splitted into two instructions but with no comparison to do (indeed you are free to choose what to do between the first instruction and the second one). Up to now, it looks for me easier and more advantageous to implement "ll/sc" than a CAS, since "ll/sc" are in fact simpler operations than CAS. But as a programmer, I must admit I find the pair "ll/sc" more attractive than CAS. > Then the system emit the CAS functionnality that should have the bus > system. Exactly the same could be handle for CAS2 (could you reexplain > why we need CAS2, Cedric explain to me that it isn't usefull, CAS is > enough). Well, there are several cases where CAS is not enough because of the ABA problem : sometimes you need to change the value of a pointer along with a version stamping to avoid this situation. For example, you want to scan a list to delete an element. Instead of having a mutex, you can just increase an associated version stamping when modifing a pointer to be sure you can change this value of pointer without creating uncoherency. In fact you need modify the version stamps AND the pointer atomically, so you need CAS2. Of course, you can use three CAS (if I remember well) to simulate a CAS2 but you ususally ruin performance that way. P.S.: What is the ABA problem ? a task partially acquires an object being in state A, modifes its contents; another task fully acquires the object, changes its state to B and modify its contents then releases it in state A. The first task, which has been interrupted by the second task tries to finish. Normally it should rollback because the second task has invalidated what the changes the first task has done. But it is fooled by the fact it only checks the state (using a simple CAS on state, here A) and not the contents and believes no other task acquired the same object meanwhile. To solve this problem we can associate a version stamping. For each attempt to acquire we increase the version stamp. That way, we haven't a reversible state which can fool a task. So a CAS2 is necessary to solve this problem and is better than a simple CAS for more complex algorithms. But of course, people can always deny the interest of a CAS2... I'm not sure there is a lot of people who really know who is right. That's all folks ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 31 16:40:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lEVp-00071D-00 for ; Sat, 31 Aug 2002 22:06:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 22:06:29 +0200 (CEST) Received: (qmail 11787 invoked by uid 0); 31 Aug 2002 14:16:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 31 Aug 2002 14:16:38 -0000 Received: by moria.seul.org (Postfix) id A7D0E15E729; Sat, 31 Aug 2002 10:16:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7997315E7AD; Sat, 31 Aug 2002 10:16:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E665915E729 for ; Sat, 31 Aug 2002 10:16:35 -0400 (EDT) Received: from ifrance.com (vlt9-168.n.club-internet.fr [195.36.223.168]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 0481516C6 for ; Sat, 31 Aug 2002 16:16:33 +0200 (CEST) Message-ID: <3D70D54C.22118A78@ifrance.com> Date: Sat, 31 Aug 2002 16:40:12 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I don't refind the precise behavior of ll/sc. But i don't like too much to lock a precise adress line. This become to be a very limited ressource and raise many problem. And what about distributed memory where pages are duplicated ? But maybe ll/sc seems to be much more low level but it's seen by user. So what do you think about ? nicO Christophe Avoinne a écrit : > > ----- Original Message ----- > From: "nico" > To: > Sent: Friday, August 30, 2002 10:35 PM > Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > > > On other world, does ll/sc are there to "emulate" true CAS ? > > Not exactly, with "ll/sc" we can much more things than a CAS does. Instead > of a comparison like in CAS we can have other tests or no test at all to do. > We can do several interesting operations between a "ll" and "sc". CAS is in > fact more specifical than "ll/sc". It is why I could find "ll/sc" more > elegant than CAS from a software viewpoint. > > > In that cases, it's much more easy to create a kind of CAS instruction. > > This could be maid by linking 2 or more instructions (the first > > instruction raise a flag, and if the second instruction come, it's a > > true CAS). > > I'm not sure about that... CAS must be an atomical read-check-modify > operation. So if you want to split into two instructions, it is no longer a > CAS and still a bit too specific. "ll/sc" is like a more general CAS > splitted into two instructions but with no comparison to do (indeed you are > free to choose what to do between the first instruction and the second one). > Up to now, it looks for me easier and more advantageous to implement "ll/sc" > than a CAS, since "ll/sc" are in fact simpler operations than CAS. But as a > programmer, I must admit I find the pair "ll/sc" more attractive than CAS. > > > Then the system emit the CAS functionnality that should have the bus > > system. Exactly the same could be handle for CAS2 (could you reexplain > > why we need CAS2, Cedric explain to me that it isn't usefull, CAS is > > enough). > > Well, there are several cases where CAS is not enough because of the ABA > problem : sometimes you need to change the value of a pointer along with a > version stamping to avoid this situation. For example, you want to scan a > list to delete an element. Instead of having a mutex, you can just increase > an associated version stamping when modifing a pointer to be sure you can > change this value of pointer without creating uncoherency. In fact you need > modify the version stamps AND the pointer atomically, so you need CAS2. Of > course, you can use three CAS (if I remember well) to simulate a CAS2 but > you ususally ruin performance that way. > > P.S.: > What is the ABA problem ? a task partially acquires an object being in state > A, modifes its contents; another task fully acquires the object, changes its > state to B and modify its contents then releases it in state A. The first > task, which has been interrupted by the second task tries to finish. > Normally it should rollback because the second task has invalidated what the > changes the first task has done. But it is fooled by the fact it only checks > the state (using a simple CAS on state, here A) and not the contents and > believes no other task acquired the same object meanwhile. To solve this > problem we can associate a version stamping. For each attempt to acquire we > increase the version stamp. That way, we haven't a reversible state which > can fool a task. So a CAS2 is necessary to solve this problem and is better > than a simple CAS for more complex algorithms. > > But of course, people can always deny the interest of a CAS2... I'm not sure > there is a lot of people who really know who is right. > > That's all folks ! > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 31 16:41:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lEVq-00071D-00 for ; Sat, 31 Aug 2002 22:06:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 22:06:30 +0200 (CEST) Received: (qmail 23588 invoked by uid 0); 31 Aug 2002 14:18:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 31 Aug 2002 14:18:01 -0000 Received: by moria.seul.org (Postfix) id 12F5615E730; Sat, 31 Aug 2002 10:18:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 05D5715E7AE; Sat, 31 Aug 2002 10:18:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9971B15E730 for ; Sat, 31 Aug 2002 10:18:00 -0400 (EDT) Received: from ifrance.com (vlt9-168.n.club-internet.fr [195.36.223.168]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 1644016FA for ; Sat, 31 Aug 2002 16:17:58 +0200 (CEST) Message-ID: <3D70D5A2.69B0D24F@ifrance.com> Date: Sat, 31 Aug 2002 16:41:38 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N tO finish : i prefer CAS and CAS2 because they are stateless it's always easier to implement, to speed up, etc... ll/sc seems to became hard to manage. nicO Christophe Avoinne a écrit : > > ----- Original Message ----- > From: "nico" > To: > Sent: Friday, August 30, 2002 10:35 PM > Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > > > On other world, does ll/sc are there to "emulate" true CAS ? > > Not exactly, with "ll/sc" we can much more things than a CAS does. Instead > of a comparison like in CAS we can have other tests or no test at all to do. > We can do several interesting operations between a "ll" and "sc". CAS is in > fact more specifical than "ll/sc". It is why I could find "ll/sc" more > elegant than CAS from a software viewpoint. > > > In that cases, it's much more easy to create a kind of CAS instruction. > > This could be maid by linking 2 or more instructions (the first > > instruction raise a flag, and if the second instruction come, it's a > > true CAS). > > I'm not sure about that... CAS must be an atomical read-check-modify > operation. So if you want to split into two instructions, it is no longer a > CAS and still a bit too specific. "ll/sc" is like a more general CAS > splitted into two instructions but with no comparison to do (indeed you are > free to choose what to do between the first instruction and the second one). > Up to now, it looks for me easier and more advantageous to implement "ll/sc" > than a CAS, since "ll/sc" are in fact simpler operations than CAS. But as a > programmer, I must admit I find the pair "ll/sc" more attractive than CAS. > > > Then the system emit the CAS functionnality that should have the bus > > system. Exactly the same could be handle for CAS2 (could you reexplain > > why we need CAS2, Cedric explain to me that it isn't usefull, CAS is > > enough). > > Well, there are several cases where CAS is not enough because of the ABA > problem : sometimes you need to change the value of a pointer along with a > version stamping to avoid this situation. For example, you want to scan a > list to delete an element. Instead of having a mutex, you can just increase > an associated version stamping when modifing a pointer to be sure you can > change this value of pointer without creating uncoherency. In fact you need > modify the version stamps AND the pointer atomically, so you need CAS2. Of > course, you can use three CAS (if I remember well) to simulate a CAS2 but > you ususally ruin performance that way. > > P.S.: > What is the ABA problem ? a task partially acquires an object being in state > A, modifes its contents; another task fully acquires the object, changes its > state to B and modify its contents then releases it in state A. The first > task, which has been interrupted by the second task tries to finish. > Normally it should rollback because the second task has invalidated what the > changes the first task has done. But it is fooled by the fact it only checks > the state (using a simple CAS on state, here A) and not the contents and > believes no other task acquired the same object meanwhile. To solve this > problem we can associate a version stamping. For each attempt to acquire we > increase the version stamp. That way, we haven't a reversible state which > can fool a task. So a CAS2 is necessary to solve this problem and is better > than a simple CAS for more complex algorithms. > > But of course, people can always deny the interest of a CAS2... I'm not sure > there is a lot of people who really know who is right. > > That's all folks ! > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 31 17:30:20 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lEVs-00071D-01 for ; Sat, 31 Aug 2002 22:06:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 22:06:32 +0200 (CEST) Received: (qmail 6464 invoked by uid 0); 31 Aug 2002 15:30:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 31 Aug 2002 15:30:37 -0000 Received: by moria.seul.org (Postfix) id 49C6B15E7AB; Sat, 31 Aug 2002 11:30:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1287115E7AE; Sat, 31 Aug 2002 11:30:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 32EF315E7AB for ; Sat, 31 Aug 2002 11:30:35 -0400 (EDT) Received: from ifurita (80.15.61.245) by smtp.laposte.net (6.0.053) id 3D2EB28C002FF180 for f-cpu@seul.org; Sat, 31 Aug 2002 17:30:34 +0200 Message-ID: <001201c25103$521b7c80$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Sat, 31 Aug 2002 17:30:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "nico" To: Sent: Saturday, August 31, 2002 4:40 PM Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > I don't refind the precise behavior of ll/sc. But i don't like too much > to lock a precise adress line. This become to be a very limited > ressource and raise many problem. > > And what about distributed memory where pages are duplicated ? But maybe > ll/sc seems to be much more low level but it's seen by user. So what do > you think about ? > First if cpu uses a normal load, it does operation on a precise address line even locked since cpu doesn't matter !!! it is the case when cpu only need to read a value : full speed. If cpu uses a normal store when a precise address line is locked, either we choose to raise an exception because we think it is a bad programming to do so, or we choose to let cpu write the new value but it must also clear the lock bit to 0 so the next locked store must fail : full speed. What's the difference ? we priviledge for performance the normal load/store against the lock load/store, because there should be very few interractions between the normal load/store and locked load/store operations in the same address, which is not the case for 'CAS'. 'CAS' is still a difficult instruction to realize because it only modifies a content (write operation) when the first read value (read operation) matches the expected value, so an atomical read-write transaction is not enough since write is conditional and should be done by your bus !!! however, if it is the CPU which realizes the read then write operation separately, you need to have internal state for 'CAS' instruction, I think. For intra-cpu locking, I don't see why it is hard to manage a locked load/store (aka 'll/sc'). I did already talk about that with Whygee and it seems feasible. For inter-cpu locking, well you should first select it before things could really slow everything down. As I suggested, locked load/store can have suffix to be told whether inter-cpu locking is required. You said that became to be a very limited ressource. Can you say why ? About distributed memory where pages are duplicated ? neither 'll/sc' nor 'CAS' can be helpful directly on those pages since cpu never see the same page, I fear. I suppose the external LSU works in parallel with each internal LSU, when need of course. Please, I need more info about the way to implement CAS in f-cpu. /Chris ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Aug 31 18:00:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lEVt-00071D-00 for ; Sat, 31 Aug 2002 22:06:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 22:06:33 +0200 (CEST) Received: (qmail 641 invoked by uid 0); 31 Aug 2002 16:00:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 31 Aug 2002 16:00:20 -0000 Received: by moria.seul.org (Postfix) id 8A79115E7B0; Sat, 31 Aug 2002 12:00:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80A4815E7B4; Sat, 31 Aug 2002 12:00:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 234FA15E7B0 for ; Sat, 31 Aug 2002 12:00:19 -0400 (EDT) Received: from ifurita (80.15.61.245) by smtp.laposte.net (6.0.053) id 3D6F99BC0000E469 for f-cpu@seul.org; Sat, 31 Aug 2002 18:00:18 +0200 Message-ID: <002101c25107$7979c6c0$0100000a@ifurita> From: "Christophe Avoinne" To: References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Sat, 31 Aug 2002 18:00:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Ok take this example : i want to increase a memory value atomically CAS version : void atomic_inc (int *slot) { int old; do { old = *slot; } while (cas(slot,old,old+1) != old); } or better to avoid reading *slot twice : void atomic_inc (int *slot) { int old1,old2 = *slot; do { old1 = old2; } while ((old1 = cas(slot,old1,old1+1)) != old2); } ll/sc version : void atomic_inc (int *slot) { int old; do { old = ll(slot); } while (!sc(slot,old+1)); } as you can see : ll/sc looks much more "elegant" and simpler for a programmer. you want to apply a function in a "atomical" way : void atomic_apply (int *slot,int (*f) (int)) { int old; do { old = ll(slot); } while (!sc(slot,f(old))); } in C++ :) : template< typename f > void apply< f >(int &slot) { int old; do { old = ll(slot); } while (!sc(slot,f(old))); } Don't forget : *ll read a value in the matching LSU entry and set the lock bit. *sc doesn't need to read a value in the matching LSU entry and compare with an expected value unlike CAS, it just needs to check the lock bit, so it should be faster. ----- Original Message ----- From: "nico" To: Sent: Saturday, August 31, 2002 4:40 PM Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > I don't refind the precise behavior of ll/sc. But i don't like too much > to lock a precise adress line. This become to be a very limited > ressource and raise many problem. > > And what about distributed memory where pages are duplicated ? But maybe > ll/sc seems to be much more low level but it's seen by user. So what do > you think about ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Aug 31 22:18:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lEW2-00071D-00 for ; Sat, 31 Aug 2002 22:06:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 31 Aug 2002 22:06:42 +0200 (CEST) Received: (qmail 32362 invoked by uid 0); 31 Aug 2002 19:55:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 31 Aug 2002 19:55:23 -0000 Received: by moria.seul.org (Postfix) id 9A94F15E7B3; Sat, 31 Aug 2002 15:55:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FE5A15E7B7; Sat, 31 Aug 2002 15:55:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 262FB15E7B3 for ; Sat, 31 Aug 2002 15:55:22 -0400 (EDT) Received: from ifrance.com (vlt9-245.n.club-internet.fr [195.36.223.245]) by relay-3v.club-internet.fr (Postfix) with ESMTP id AF38416BB for ; Sat, 31 Aug 2002 21:55:16 +0200 (CEST) Message-ID: <3D7124B2.D8AC6D9D@ifrance.com> Date: Sat, 31 Aug 2002 22:18:58 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> <002101c25107$7979c6c0$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe Avoinne a écrit : > > Ok take this example : i want to increase a memory value atomically > > CAS version : > > void atomic_inc (int *slot) { > int old; > do { > old = *slot; > } while (cas(slot,old,old+1) != old); > } > > or better to avoid reading *slot twice : > > void atomic_inc (int *slot) { > int old1,old2 = *slot; > do { > old1 = old2; > } while ((old1 = cas(slot,old1,old1+1)) != old2); > } > > ll/sc version : > > void atomic_inc (int *slot) { > int old; > do { > old = ll(slot); > } while (!sc(slot,old+1)); > } > > as you can see : ll/sc looks much more "elegant" and simpler for a > programmer. > > you want to apply a function in a "atomical" way : > > void atomic_apply (int *slot,int (*f) (int)) { > int old; > do { > old = ll(slot); > } while (!sc(slot,f(old))); > } > > in C++ :) : > > template< typename f > void apply< f >(int &slot) { > int old; > do { > old = ll(slot); > } while (!sc(slot,f(old))); > } > > Don't forget : > *ll read a value in the matching LSU entry and set the lock bit. > *sc doesn't need to read a value in the matching LSU entry and compare with > an expected value unlike CAS, it just needs to check the lock bit, so it Does it have one single lock bit for the whole system or a lock bit per adress line ? If there is only one, in large scale system, there will have a problem. If there is one by address line, can't have a flag for each line so the memory will act as a caches. So you could "loose" some lock bit, because there isn't enough room. If you have a lot of process or a lot of memory, soonre or later you will have a big problem. For CAS, it's a little easier. The io bus (opppose to the memory bus) should have read-modify-write cycle. This kind of cycle will "lock" for a little moment all the system from the cpu to the memory what ever way it cross. That's possible. The performance is very poor but is much quicker than a mutex. If we add CAS to the bus sub-system, CAS2 could be added to it, too. nicO > should be faster. > > ----- Original Message ----- > From: "nico" > To: > Sent: Saturday, August 31, 2002 4:40 PM > Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > > > I don't refind the precise behavior of ll/sc. But i don't like too much > > to lock a precise adress line. This become to be a very limited > > ressource and raise many problem. > > > > And what about distributed memory where pages are duplicated ? But maybe > > ll/sc seems to be much more low level but it's seen by user. So what do > > you think about ? > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Sep 1 01:44:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lMWV-0004CY-00 for ; Sun, 01 Sep 2002 06:39:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 06:39:43 +0200 (CEST) Received: (qmail 27143 invoked by uid 0); 31 Aug 2002 23:45:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 31 Aug 2002 23:45:03 -0000 Received: by moria.seul.org (Postfix) id D7E6E15E7AC; Sat, 31 Aug 2002 19:45:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CA3D715E7B1; Sat, 31 Aug 2002 19:45:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 05E5615E7AC for ; Sat, 31 Aug 2002 19:45:01 -0400 (EDT) Received: from ifurita (80.15.61.254) by smtp.laposte.net (6.0.053) id 3D2EB28C0030315E for f-cpu@seul.org; Sun, 1 Sep 2002 01:45:00 +0200 Message-ID: <002601c25148$6366eca0$0100000a@ifurita> From: "Christophe Avoinne" To: Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Sun, 1 Sep 2002 01:44:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "nico" To: Sent: Saturday, August 31, 2002 10:18 PM Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > Does it have one single lock bit for the whole system or a lock bit per > adress line ? Well, maybe the name of lock bit is not appropriate since we don't lock but something like a no-dirty bit in fact . This bit is per address line since it is located in a LSU entry. Normally, a 'll' sets a LSU entry - like a normal load as well, and 'sc' should be executed as soon as possible (should be just a matter of few cycles), so we can expect the lsu entry would most time (a really good percentage) still be valid. Situations where a rollback must be done are rarer than you think. > If there is only one, in large scale system, there will have a problem. Forget it, I never think about a global lock anyway. > If there is one by address line, can't have a flag for each line so the > memory will act as a caches. So you could "loose" some lock bit, because > there isn't enough room. The problem is same as for normal load/store : data must be in LSU. As I said above, 'll' then 'sc' must be executed in a very few laptime so "loosing" a no-dirty bit shouldn't be so critical as you seem to think. > If you have a lot of process or a lot of > memory, soonre or later you will have a big problem. ??? nope because the time between a 'll' and 'sc' is very short and can be spoken in cycles. Processes should not abuse the 'll/sc' the same way with normal load/store. > For CAS, it's a little easier. The io bus (opppose to the memory bus) > should have read-modify-write cycle. > This kind of cycle will "lock" for a little moment all the system from the cpu > to the memory what ever way it cross. That's possible. No doubt it is possible but you really lock the memory bus for all cpus indeed. If a cpu want to read normally (with a normal load), it would be blocked too without reason. If you want only intra-cpu locking, you are still preventing the other cpu from normal load/store operation. > The performance is very poor but is much > quicker than a mutex. Maybe you shouldn't think always the worse case as if it is 100%. Just imagine that 'll/sc' is twice as fast as a 'CAS' and has 95% of success (no rollback). Overall performance is in fact better for 'll/sc'. > If we add CAS to the bus sub-system, CAS2 could be > added to it, too. > Yes I could imagine if we can have both CAS and CAS2, that could be interresting. But if it is only for CAS, well I maybe prefer 'll/sc'. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Sep 1 13:07:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lUSJ-0001PN-00 for ; Sun, 01 Sep 2002 15:07:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 15:07:55 +0200 (CEST) Received: (qmail 9362 invoked by uid 0); 1 Sep 2002 10:43:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 Sep 2002 10:43:40 -0000 Received: by moria.seul.org (Postfix) id 8526415E723; Sun, 1 Sep 2002 06:43:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6092715E783; Sun, 1 Sep 2002 06:43:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id DA34815E723 for ; Sun, 1 Sep 2002 06:43:38 -0400 (EDT) Received: from ifrance.com (vlt4-171.n.club-internet.fr [194.158.109.171]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 63D3C16C0 for ; Sun, 1 Sep 2002 12:43:36 +0200 (CEST) Message-ID: <3D71F4E9.F9D5E27C@ifrance.com> Date: Sun, 01 Sep 2002 13:07:21 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> <002101c25107$7979c6c0$0100000a@ifurita> <3D7124B2.D8AC6D9D@ifrance.com> <002601c25148$6366eca0$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe Avoinne a écrit : > > ----- Original Message ----- > From: "nico" > To: > Sent: Saturday, August 31, 2002 10:18 PM > Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > > > Does it have one single lock bit for the whole system or a lock bit per > > adress line ? > > Well, maybe the name of lock bit is not appropriate since we don't lock but > something like a no-dirty bit in fact . This bit is per address line since > it is located in a LSU entry. Normally, a 'll' sets a LSU entry - like a > normal load as well, and 'sc' should be executed as soon as possible (should > be just a matter of few cycles), so we can expect the lsu entry would most > time (a really good percentage) still be valid. Situations where a rollback > must be done are rarer than you think. > > > If there is only one, in large scale system, there will have a problem. > > Forget it, I never think about a global lock anyway. > Ok ! > > If there is one by address line, can't have a flag for each line so the > > memory will act as a caches. So you could "loose" some lock bit, because > > there isn't enough room. > > The problem is same as for normal load/store : data must be in LSU. As I > said above, 'll' then 'sc' must be executed in a very few laptime so > "loosing" a no-dirty bit shouldn't be so critical as you seem to think. > > > If you have a lot of process or a lot of > > memory, soonre or later you will have a big problem. > > ??? nope because the time between a 'll' and 'sc' is very short and can be > spoken in cycles. Processes should not abuse the 'll/sc' the same way with > normal load/store. > Imagine 32 node with Apache process&thread. In the worst case, you could go in infinite loop, no ? > > For CAS, it's a little easier. The io bus (opppose to the memory bus) > > should have read-modify-write cycle. > > This kind of cycle will "lock" for a little moment all the system from the > cpu > > to the memory what ever way it cross. That's possible. > > No doubt it is possible but you really lock the memory bus for all cpus > indeed. > It's depend on topology of the network. But network is much slower than cpu so if we care about that very few cycle will be lost. > If a cpu want to read normally (with a normal load), it would be blocked too > without reason. > If the bus is locked, yes. Maybe with split CAS cycle ? The destination of the load is locked during few cycle waiting for the conditionnal store. Or you define not a read-modify-write cycle but a true CAS cycle. The comparaison is maid by the controler (adresse of the load, data to be compare and the write). The return is just an ack. > If you want only intra-cpu locking, you are still preventing the other cpu > from normal load/store operation. > I don't like to differ inter and intra cpu process operation. Otherwise, 2 thread running on the same cpu will not have the same code as 2 thread running on 2 cpu. And that's baaaaaad ! > > The performance is very poor but is much > > quicker than a mutex. > > Maybe you shouldn't think always the worse case as if it is 100%. > > Just imagine that 'll/sc' is twice as fast as a 'CAS' and has 95% of success > (no rollback). Overall performance is in fact better for 'll/sc'. > The external LSU means a set/unset for each access and that is a cost for each memory access. > > If we add CAS to the bus sub-system, CAS2 could be > > added to it, too. > > > > Yes I could imagine if we can have both CAS and CAS2, that could be > interresting. But if it is only for CAS, well I maybe prefer 'll/sc'. I really don't like state in hardware, that's a lot of problem in the future : test, speed, speed up,... nicO > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Sep 1 14:32:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lUSM-0001PN-00 for ; Sun, 01 Sep 2002 15:07:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 15:07:58 +0200 (CEST) Received: (qmail 9195 invoked by uid 0); 1 Sep 2002 12:32:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 1 Sep 2002 12:32:35 -0000 Received: by moria.seul.org (Postfix) id 1B10115E728; Sun, 1 Sep 2002 08:32:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E3CE815E7B1; Sun, 1 Sep 2002 08:32:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 5972115E728 for ; Sun, 1 Sep 2002 08:32:33 -0400 (EDT) Received: from ifurita (81.48.49.40) by smtp.laposte.net (6.0.053) id 3D2EB28C00307420 for f-cpu@seul.org; Sun, 1 Sep 2002 14:32:32 +0200 Message-ID: <000701c251b3$9b8a8ea0$0100000a@ifurita> From: "Christophe Avoinne" To: Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? Date: Sun, 1 Sep 2002 14:32:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Well let's and see. For the moment we haven't even a uniprocessor working so we should delay this issue until it comes necessary. ----- Original Message ----- From: "nico" To: Sent: Sunday, September 01, 2002 1:07 PM Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > Imagine 32 node with Apache process&thread. In the worst case, you could > go in infinite loop, no ? > No, because there would always one which succeeds. If one succeeds, the others will have more chance to succeed too until all succeed. The laptime spent between 'll' and 'sc' is so ridiculous short compared with the rest that must be executed. Anyway, I see 'll/sc' as a way to do no blocking synchronistation, but not the only one. > If the bus is locked, yes. Maybe with split CAS cycle ? The destination > of the load is locked during few cycle waiting for the conditionnal > store. Or you define not a read-modify-write cycle but a true CAS cycle. > The comparaison is maid by the controler (adresse of the load, data to > be compare and the write). The return is just an ack. Well a true CAS cycle would be more interesting. Such thing is possible ? > > If you want only intra-cpu locking, you are still preventing the other cpu > > from normal load/store operation. > > > > I don't like to differ inter and intra cpu process operation. Otherwise, > 2 thread running on the same cpu will not have the same code as 2 thread > running on 2 cpu. And that's baaaaaad ! No, you didn't understand me. Intra-cpu locking can be interesting if code just need to be executed in a uni-processor environment. That's all. Anyway, the uniprocessor wouldn't suffer from an external-LSU since it doesn't need to be present (behaves as if no-dirty bit checking always succeeds in that case) and you don't incur an io bus locking indeed. The external-LSU behaves exactly as an internal-LSU but it is shared between CPU. The only instant when you have a locktime is when several cpus tries to access meanwhile. But such a thing would happen for CAS too. > The external LSU means a set/unset for each access and that is a cost > for each memory access. The external LSU is only accessed when a inter-cpu locking is involved and is accessed as a cpu would access an internal LSU. > I really don't like state in hardware, that's a lot of problem in the > future : test, speed, speed up,... State ? I'm not sure there is any state with 'll/sc'. --- I believe Whygee and Michael R. prefer 'll/sc' instructions against CAS instruction. --- I need to know the real format of your CAS. For me it should look something like : before : three registers contain an expected value, a value address and a new value after : one register contains the read value before writing or before : three registers contain an expected value, a value address and a new value after : one register contains a boolean value telling us if writing succeeds. Is such format possible with a CAS cycle ? CAS2: geeek ! we need 6 registers instead of 3 ! of course we can decide to use pair of registers ( rN', rN^1). But I feel it isn't feasible. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Sep 1 15:30:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lYZJ-0004Hn-00 for ; Sun, 01 Sep 2002 19:31:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 19:31:25 +0200 (CEST) Received: (qmail 843 invoked by uid 0); 1 Sep 2002 13:30:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 1 Sep 2002 13:30:56 -0000 Received: by moria.seul.org (Postfix) id C1ED115E7A0; Sun, 1 Sep 2002 09:30:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B023615E7B1; Sun, 1 Sep 2002 09:30:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id 6CAB415E7A0 for ; Sun, 1 Sep 2002 09:30:54 -0400 (EDT) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix3-1.free.fr (Postfix) with ESMTP id AC6E2D9F47 for ; Sun, 1 Sep 2002 15:30:53 +0200 (MEST) Received: by imp4-1.free.fr (Postfix, from userid 33) id A1F26843C; Sun, 1 Sep 2002 15:30:53 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] Memory add/sub Message-ID: <1030887053.3d72168d9749a@imp.free.fr> Date: Sun, 01 Sep 2002 15:30:53 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, If we want to correctly manage a stack with pop/push operation, we need a add/sub operator that preserve the LSU information bit. I propose something like that : madd[0-7] and msub[0-7]. I don't know if we need size for this operation or endian, I think not. Stream information is needed if we want to implement them by simply multipling the number of LSU. In the same idea I think we need to affect some stream, for example 0 for unknow stream and 7 for stack. What did you think about that ? If we want a second stack for return address, we can use a other stream. In that case we perhaps need to put a recommandation in the call convention for a return stack address pointer. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Sep 1 16:09:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lYZJ-0004Hn-01 for ; Sun, 01 Sep 2002 19:31:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 19:31:25 +0200 (CEST) Received: (qmail 25685 invoked by uid 0); 1 Sep 2002 13:45:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 1 Sep 2002 13:45:31 -0000 Received: by moria.seul.org (Postfix) id D1A9615E7AE; Sun, 1 Sep 2002 09:45:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C86AE15E7B5; Sun, 1 Sep 2002 09:45:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7FBCD15E7AE for ; Sun, 1 Sep 2002 09:45:29 -0400 (EDT) Received: from ifrance.com (vlt9-27.n.club-internet.fr [195.36.223.27]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 32D9816A6 for ; Sun, 1 Sep 2002 15:45:27 +0200 (CEST) Message-ID: <3D721F88.DAB3CAB4@ifrance.com> Date: Sun, 01 Sep 2002 16:09:12 +0200 From: nico X-Mailer: Mozilla 4.78 [fr] (X11; U; Linux 2.4.8-26mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> <002101c25107$7979c6c0$0100000a@ifurita> <3D7124B2.D8AC6D9D@ifrance.com> <002601c25148$6366eca0$0100000a@ifurita> <3D71F4E9.F9D5E27C@ifrance.com> <000701c251b3$9b8a8ea0$0100000a@ifurita> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Christophe Avoinne a écrit : > > Well let's and see. For the moment we haven't even a uniprocessor working so > we should delay this issue until it comes necessary. > Yes and no. I strongly beleive that all is now decide which can be seen by the user will be keep as is. So good definition should be find now. > ----- Original Message ----- > From: "nico" > To: > Sent: Sunday, September 01, 2002 1:07 PM > Subject: Re: Rep:[f-cpu] Hot issue : external LSU ? > > > Imagine 32 node with Apache process&thread. In the worst case, you could > > go in infinite loop, no ? > > > > No, because there would always one which succeeds. If one succeeds, the > others will have more chance to succeed too until all succeed. The laptime > spent between 'll' and 'sc' is so ridiculous short compared with the rest > that must be executed. Anyway, I see 'll/sc' as a way to do no blocking > synchronistation, but not the only one. If there is no entries deleted because there isn't enought room any more in the dirty/lock bit LSU. > > > If the bus is locked, yes. Maybe with split CAS cycle ? The destination > > of the load is locked during few cycle waiting for the conditionnal > > store. Or you define not a read-modify-write cycle but a true CAS cycle. > > The comparaison is maid by the controler (adresse of the load, data to > > be compare and the write). The return is just an ack. > > Well a true CAS cycle would be more interesting. Such thing is possible ? > Yes, we just have to define it. It will be a mandatory feature of the interconnect newtwork. Then this should be handel by the slaves devices (the memory controller). > > > If you want only intra-cpu locking, you are still preventing the other > cpu > > > from normal load/store operation. > > > > > > > I don't like to differ inter and intra cpu process operation. Otherwise, > > 2 thread running on the same cpu will not have the same code as 2 thread > > running on 2 cpu. And that's baaaaaad ! > > No, you didn't understand me. Intra-cpu locking can be interesting if code > just need to be executed in a uni-processor environment. That's all. > > Anyway, the uniprocessor wouldn't suffer from an external-LSU since it > doesn't need to be present (behaves as if no-dirty bit checking always > succeeds in that case) and you don't incur an io bus locking indeed. > > The external-LSU behaves exactly as an internal-LSU but it is shared between > CPU. The only instant when you have a locktime is when several cpus tries to > access meanwhile. But such a thing would happen for CAS too. > Yes, but the underlaying hardware isn't the same at all. > > The external LSU means a set/unset for each access and that is a cost > > for each memory access. > > The external LSU is only accessed when a inter-cpu locking is involved and > is accessed as a cpu would access an internal LSU. > The external LSU is taking into account in ll/sc transaction but it still there in all access (+if a normal load occure in a locked adresse the lock bit must be cleared). > > I really don't like state in hardware, that's a lot of problem in the > > future : test, speed, speed up,... > > State ? I'm not sure there is any state with 'll/sc'. > If you set a bit, there is a state (lock/unlocked). nicO > --- > > I believe Whygee and Michael R. prefer 'll/sc' instructions against CAS > instruction. > > --- > > I need to know the real format of your CAS. > > For me it should look something like : > > before : three registers contain an expected value, a value address and > a new value > after : one register contains the read value before writing > or > before : three registers contain an expected value, a value address and > a new value > after : one register contains a boolean value telling us if writing > succeeds. > > Is such format possible with a CAS cycle ? Yes, it is. We define buses also, so this kind of feature could be imposed. The 2 formats are possible but the first is more general. > > CAS2: geeek ! we need 6 registers instead of 3 ! of course we can decide to > use pair of registers ( rN', rN^1). But I feel it isn't feasible. Not if you "link" instruction. Remember if we lose some cycle here it's not so hard. nicO > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 1 18:12:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lYZO-0004Hn-00 for ; Sun, 01 Sep 2002 19:31:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Sep 2002 19:31:30 +0200 (CEST) Received: (qmail 5290 invoked by uid 0); 1 Sep 2002 16:02:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 1 Sep 2002 16:02:16 -0000 Received: by moria.seul.org (Postfix) id D151E15E7BC; Sun, 1 Sep 2002 12:02:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9338415E7BF; Sun, 1 Sep 2002 12:02:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id EF89515E7BC for ; Sun, 1 Sep 2002 12:02:12 -0400 (EDT) Received: from f-cpu.org (kdl11-92.n.club-internet.fr [213.44.9.92]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 5CF4C16BB; Sun, 1 Sep 2002 18:02:10 +0200 (CEST) Message-ID: <3D723C7E.94C31BD8@f-cpu.org> Date: Sun, 01 Sep 2002 18:12:46 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Hynek Hanke Cc: f-cpu@seul.org Subject: [f-cpu] Re: [Fwd: request for interview about F-CPU] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! I forward this to the english mailing list so they know what is going on. Hynek Hanke wrote: > On Sat, 17 Aug 2002, Yann Guidon wrote: > > Hi Yann, hi Riepe > > it seems my previous reply got lost somewhere :( probably. But things seem to be ok anyway. > > please inform me if there's something silly :-) > > No, it's absolutely perfect. Thank you very much! > I've included both your answers and Michael's. cool ! > > Important note : please mention that the active site > > for F-CPU is at http://f-cpu.seul.org (http://www.f-cpu.org > > is not updated). seul.org also hosts the english mailing list. > > Of course I did :) > > > Please keep in touch and inform us about your article. > > There is a mini-series of 3 articles now on > http://www.zive.cz/H/Uzivatel/Ar.asp?ARI=107037&CAI=2104 . > The interview has completely filled the second one: > http://www.zive.cz/H/Uzivatel/Ar.asp?ARI=107123&CAI=2104 > (but it's all only in Czech :( i have remarked this ;-) i believe it was a heavy translation work. > The first is a general introduction into the topic. > It discusses how hardware can be 'libre' and that for > these "liberties" to be really liberties, you need > to have the design. A definition of libre hardware > designs follows. Then there is a discussion about > the objections of Richard Stallman why it's not > sure that they are really relevant, quoting some > developers who can actually ,,copy'' hardware in > their homes. The following paragraph talks about > some history, about the idea of freedom of information, > and also mentions the Midnight Computer Wiring Society > in order to show that hardware used to be free (at least > at some period of time). The first article ends with > a discussion about education purposes and ,,giving > society information that is normally being accumulated behind > the walls of proprietary companies''. > > I'll skip the second because you know it (you have written > it) and except for the translation, there is nearly no editing. > I only had to change ,,free/libre hardware'' to ,,free/libre > hardware design(s)'' because in Czech, this makes much more > sense (I think the difference is bigger than in English) > and because of my readers (I know they would misunderstand > ,,free hardware''). I just wanted to introduce some real > project before I would continue with general explanation. > You both have done an excellent job in it and I think F-CPU > is one of the greatest representatives of current libre > hardware projects. > > In the third article I'm returning back into history right > at the beginning and I'm writing about Homebrew Computer > Club quoting Bob Lash. Then I move forward to 1998 to > the foundation of Open Design Circuits, to the description > of the six stages they describe and the problems they > have foreseen and that really appeared. I continued with > a description of how these problems are solved now > with examples of other free hardware. I quote John Khatib's > article on IBM Developer Network mentioning OR1K. I describe > GNUBook as another approach to free hw designs and mention > Simputer. I'm closing the mini-series with a note that > it's everything just at the beginning now and there are > still hard problems to solve before we can really use hardware > with free designs. I quote Yan's words about the ,,utopic dream'' > and the dedication at OpenCollector: ,,to old aging hippies.'' :) > > The reactions were mostly positive and I was surprised > to learn in the discussion with readers that there is > one Czech open-source hardware project (for a WiFi transmitter > or something like this). If you are interested, have a look > at www.czfree.net . i think it's "Ronja", they belong to our webring ;-) it's not a CPU but definitely belongs to the "libre" domain. > I hope I've (and you have) covered this area of the ,,Free/Libre'' > movement quite well and that my readers are now a little bit more > familiar with this wonderful effort. most importantly, you seemed to cover most or all the subject in a reasonable space :-) > I'll certainly > try to bring some news from this area once I've introduced > it so don't hesitate to write me if there is some important > progress in F-CPU or something. no problem. > Thank you both very much, I was surprised by the depth > of your answers! Thank you for F-CPU! thank you for the efforts, > Hynek WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 1 19:41:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ld6q-0007WJ-02 for ; Mon, 02 Sep 2002 00:22:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 00:22:20 +0200 (CEST) Received: (qmail 2288 invoked by uid 0); 1 Sep 2002 21:56:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 1 Sep 2002 21:56:11 -0000 Received: by moria.seul.org (Postfix) id DCFB015E7C7; Sun, 1 Sep 2002 17:56:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B206715E7CA; Sun, 1 Sep 2002 17:56:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a063.home.uni-hannover.de [130.75.232.63]) by moria.seul.org (Postfix) with ESMTP id 051D415E7C7 for ; Sun, 1 Sep 2002 17:56:08 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01254; Sun, 1 Sep 2002 19:41:27 +0200 Message-ID: <20020901194127.26273@thrai.stud.uni-hannover.de> Date: Sun, 1 Sep 2002 19:41:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Memory add/sub References: <1030887053.3d72168d9749a@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1030887053.3d72168d9749a@imp.free.fr>; from Cedric BAIL on Sun, Sep 01, 2002 at 03:30:53PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: > If we want to correctly manage a stack with pop/push operation, we need a > add/sub operator that preserve the LSU information bit. I propose something > like that : madd[0-7] and msub[0-7]. I don't know if we need size for > this operation or endian, I think not. Stream information is needed if we want > to implement them by simply multipling the number of LSU. > In the same idea I think we need to affect some stream, for example 0 for > unknow stream and 7 for stack. What did you think about that ? I already outlined the need for such a `pointer add' instruction last year. Programs that deal with structures (or classes/objects) will need it quite often. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 2 00:28:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17leUW-0000A4-00 for ; Mon, 02 Sep 2002 01:50:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 01:50:52 +0200 (CEST) Received: (qmail 13897 invoked by uid 0); 1 Sep 2002 22:17:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 1 Sep 2002 22:17:46 -0000 Received: by moria.seul.org (Postfix) id 55E0F15E7C9; Sun, 1 Sep 2002 18:17:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 283A915E7CC; Sun, 1 Sep 2002 18:17:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9DDDE15E7C9 for ; Sun, 1 Sep 2002 18:17:44 -0400 (EDT) Received: from f-cpu.org (kdl4-75.n.club-internet.fr [213.44.3.75]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 4767E16B2 for ; Mon, 2 Sep 2002 00:17:42 +0200 (CEST) Message-ID: <3D729483.70B9B299@f-cpu.org> Date: Mon, 02 Sep 2002 00:28:19 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Memory add/sub References: <1030887053.3d72168d9749a@imp.free.fr> <20020901194127.26273@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, i really wonder what this thing is really about... anyway. Michael Riepe wrote: > On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: > > If we want to correctly manage a stack with pop/push operation, we need a > > add/sub operator that preserve the LSU information bit. really ? push/pop is just one use of pointer updates, and the existing post-increment (with register or immediate modifier) has already been discussed, right ? > > I propose something > > like that : madd[0-7] and msub[0-7]. I don't know if we need size for > > this operation or endian, I think not. Stream information is needed if we want > > to implement them by simply multipling the number of LSU. do you mean that you want to add or substract up to 7 bytes from a pointer ? the existing post-increment does this already, and you get a load or store for free. If you want to hust update the pointer, "load" R0 so the result is cancelled. "Think RISC". Or should i say : project yourself in an over-simplified world. > > In the same idea I think we need to affect some stream, for example 0 for > > unknow stream and 7 for stack. What did you think about that ? allocating stream now would reduce our scalability in the future : we still have a lot of other means to do specific things : we can add some instructions for example. > I already outlined the need for such a `pointer add' instruction last > year. Programs that deal with structures (or classes/objects) will > need it quite often. then just do a "load" to this pointer, put the result in R0 and update the pointer with the register or immediate value you want. Is a specific instruction really needed ? > Michael "Tired" Riepe WHYGEE (currently digging in the pthread docs and looking at pthread_mutex) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Sep 2 00:35:24 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17leUX-0000A4-00 for ; Mon, 02 Sep 2002 01:50:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 01:50:53 +0200 (CEST) Received: (qmail 22663 invoked by uid 0); 1 Sep 2002 22:24:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 1 Sep 2002 22:24:55 -0000 Received: by moria.seul.org (Postfix) id 4A03115E7CE; Sun, 1 Sep 2002 18:24:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF7C815E7D2; Sun, 1 Sep 2002 18:24:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 33F7C15E7CE for ; Sun, 1 Sep 2002 18:24:53 -0400 (EDT) Received: from f-cpu.org (kdl16-26.n.club-internet.fr [213.44.18.26]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 9F41416A3 for ; Mon, 2 Sep 2002 00:24:47 +0200 (CEST) Message-ID: <3D72962C.5A44D359@f-cpu.org> Date: Mon, 02 Sep 2002 00:35:24 +0200 From: Yann Guidon Organization: http://www.f-cpu.org X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: f-cpu@seul.org Subject: For those who don't understand Czech (was Re: [f-cpu] Re: [Fwd: request for interview about F-CPU]) References: <3D723C7E.94C31BD8@f-cpu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello, here is the oiginal english text that was submitted for Hynek's article. The rest of his article is explained in the last mail. WHYGEE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here is what i sent to Hynek : Michael Riepe wrote: > > Hi! > > Here are my comments; feel free to pass them along, but please also ask > for a (translated!) copy of the article. > > > Can you briefly describe what is the aim > > of F-CPU project? Your motto is: ``Design > > and let design'', could you explain it? > > Why do you think these goals are important? > > Design a CPU that is freely available for everyone. > That's important because > > - We're not locked with one of a small number of vendors that > always tend to hide their cards. > - We not only make the design available for everyone, but also > the knowledge. You can learn a hell of a lot if you read > other people's code - that's the way many of us learned how > to program. > - People can participate in further development > - It's fun! :) HH: Can you briefly describe what is the aim of F-CPU project? YG: The Freedom CPU Project Constitution was voted in early 1999 : " To develop and make freely available an architecture, and all other intellectual property necessary to fabricate one or more implementations of that architecture, with the following priorities, in decreasing order of importance: 1. Versatility and usefulness in as wide a range of applications as possible 2. Performance, emphasizing user-level parallelism and derived through intelligent architecture rather than advanced silicon process 3. Architecture lifespan and forward compatibility 4. Cost, including monetary and thermal considerations " The people who created this project feared that Intel's monopoly would bar them from hacking and patching the Linux kernel. One of them, Richard Gooch, is known to have designed the MTRR support and devfsd. So they imagined that applying Linux's recipe to the HW world would provide a viable alternative. They named this the "Freedom CPU Project" which was compressed and slowly became "F-CPU". As the name says : it's about freedom. It's a very strong culture clash and a utopic dream but indeed this attracted a lot of people who slowly built the project's success. Note however that "to design" does not mean "to build" or "to fabricate". The goal is to create "Intellectual Property" under Copyleft, fabricating the chips is not the issue. The existing industry will be more than happy to fabricate the chips because the "IP" cost is increasing. Our goal is to set new fair rules and a sane computing environment for everybody. HH: Your motto is: ``Design and let design'', could you explain it? I found this when preparing a presentation for the 17C3 in Berlin. It's a play on "live and let live" because, for people like us, to design is life (and vice versa). This has many meanings, for example : it's a good anti-patent slogan ("don't keep me from doing my business with your silly obvious patents") or an anti-troll cure ("well, what you propose is nice but we would like to see the source code..."). Or, when someone become unhappy with F-CPU, for example when his suggestions are not accepted, it is better for everybody to continue its own development rather than fight. In the end, both versions will be tested and there will be more alternatives. This motto contains the notions of respect, peace and freedom because someone's freedom ends where other's begin. It remembers people that our goal is to design, not loose our time with endless discussions or non-technical matters. Well, at least, not to the point where the development stalls. HH: Why do you think these goals are important? I do not wonder this because it seems so obvious to me, as i work in the electronics and software worlds. I believe that there is something that i can do and i see that i am not alone. This is granted for me and now the question is "how". I joined this project because i was doing mostly the same alone. This personal project was motivated by the frustration i had accumulated when programming PCs or DSPs. I already had a pretty disapointed perspective of how the microelectronics industry worked. People who participate in F-CPU have experiennced the same problems as me : "Non Disclosure Agreements", hidden flaws in the chips, unfair commercial practices, complicated design that does not do the expected work.... This situation exists because the companies are profit-oriented and they prefer to spare their efforts on some subjects, or not disclose anything, rather than help customers when it needs it. As it is often said, companies have no ethics. A Copylefted design can change the situation : the "legal" ties attached to the design make the companies aware of their responsibilities and of their role. The "customer" is not only something you skim from his money. I know no other project which emphasizes on both the freedom and individual responsibility and this is why i continue to support this project. > > Tell us something about the pure technical improvements > > the F-CPU has over proprietary CPU designs. > > Scalable register width and generalized SIMD support. F-CPU does not bring so many ground-breaking technical improvements over other designs. And most of them are consequences of design choices. What the programming model brings is a simplification and homogenization of features that are found in other families. For example : - F-CPU is defined as a "64 bit minimum" CPU because we intend to support wider data and pointer types. If one looks back at all the major migrations, there are 8 bit to 16 bits, 16 bits to 32 bits, 32 bits to 64 bits. These are major milestones and investments for the users because software has to take register width into account. F-CPU will probably be the first computer that will not trap the users into a determined data size and the coexistence of several different computer width should be transparent if some basic coding rules are respected. On top of that, well-written software will run faster on larger computers, and still execute on "basic" 64-bit versions. - F-CPU uses 64 registers for all data, pointers etc. so one can use all the available registers when it is necessary to. It is suited for loop unrolling of complex algorithms and heavy data intensive computations (graphics, sound processing, crypto, physical simulations, video...) - numerical data can be treated as scalar or SIMD (packed) data. This is not an extension (if compared to SSE, MMX, Altivec etc) and it is completely integrated in the instruction set from the start. Programming F-CPU in assembly can be as easy as in C because there are no silly coding rules and restrictions. The instruction set is designed to provide all the performance to the user. These are some of the most noticeable features brought by the F-CPU. Most of the remaining features are only consequenses of these design decisions. If it can look like a 64-bit orthogonal MIPS to the newcomer, it differs a lot when one investigates a bit. It's both a "classical" looking design and a new approach because the early F-CPU attempts wanted to break too much from the existing model and nobody knew how to program it. The current work is satisfying because there is a lot of room for enhancements and even if a newcomer wants to code for it, it will not be too complex to understand the basics and it will work quickly (though at the cost of a temporary performance drop). Concerning the "microarchitecture", "FC0" started in mid-99 and it borrows bits from known high-end computer architectures. It's like a crossover between an early ALPHA chip and a "super" mainframe of the '70-80 era, so there should be no patent problem. In the details, F-CPU is so different that the implementation does not look like anything but there is no secret : everything is a logical consequence of the basic design goals. Interested readers should look at the "F-CPU Manual" : version 0.2.6 is out but several parts are long outdated. > > What are your chances to really fabricate > > F-CPU? Is it only FPGAs? > > That's mainly a money issue. The question is whether somebody will manage > to build a computer around it. I believe that the chances are good. In boils down to being able to finish the code. When F-CPU version 1 will be out, binary compatibility will be ensured and the basic features will be frozen. Anybody will be able to download the sources, synthesise them for their target (either FPGA or semi-custom), adapt the sources to their needs and make money on the chips. This sounds interesting to many more people than i thought and the current economical troubles make managers more interested by ways to reduce costs, increasing "coopetition" with multiple sourcing and reverse auctions... The cost of current IP from ARM or MIPS is very high and if a company spares one million dollars in license fees, it will be able to reduce end-product costs and invest more in real R&D. In fact, i know few people today (in the industry) who see F-CPU and "Open Hardware" as a threat, and budget restrictions are not the only reason (otherwise ARM would go bankrupt). Even Intel could build and market F-CPUs, as long as they respect the team's copyright. > > If I asked you to figure out how many percents of F-CPU > > design is currently done and how much is still waiting > > for someone to hack on, what would your answer be? > > Hard to say. I'd guess 30% if we don't count the caches (they'll > utilize a lot of silicon but are highly regular, so...). The really > hard part is still under development, though. I'd say 15% or 20% for the integer core. The source code is very important but more important is the validation process and the cross-tests between different tools. For 1 line of "core" code, maybe 5 lines must be written for the testbenches, and both in C and VHDL. We have spent the last two years building a methodology from scratch and it is still not finished. Fortunately, the hardest parts have been done and the rest should be designed faster : once all the testbench support files and scripts are designed, it's a matter of cut&paste for adapting the tests to another unit. Designing and hacking F-CPU is easier for "electronicians" because they are used to create testbenches and carefully check all the parameters. A classical "hacker" or even CS engineer will code a C function, include it in a program and see that it works, then do another function ... F-CPU is not a hack, everything must work perfectly with the rest, whatever the configuration. So most of the efforts are done with automating things, testing them and write the documentation. Just like in a normal company, but with different constraints. Ensuring the freedom of the design requires a lot of efforts and even though our methods use "hacks", the result is not a hack (it's usually the contrary in commercial designs). These are some reasons why the development is so slow. > > Are you also using some other libre designs or > > you are doing everything from scratch? > > Due to the unique properties of the F-CPU, we do most things from scratch > (at least the parts I did). There simply are no arithmetic units (or > generators for them) that support SIMD operations the way we need them, > for example - except our own, of course. We have not only to do the design from scratch, but also the rest. For example, i have written the system that configures the sources. There is no "make xconfig" like with Linux but all the machinery behind the scene works, so you can configure your own CPU without having to browse all the source files. Because the central langage is VHDL which has particular characteristics, the usual "configure" software is useless but m4 is used. Another critical point in ensuring the project's freedom is that the sources must not depend on vendors (unlike a lot of sources released with a "GPL sticker"). There are no really free VHDL design suites and those we tested do not keep their technical promises. So yes we are forced to use commercial tools. Cadence was the first (and not the lest) company that proposed some help. Then Aldec did the same. But the team is slow to accept them for many reasons : these are highly expensive tools which require training, hardware, configuration, legal agreements etc. Most contributors also use freeware VHDL compilers and simulators. The situation is now better and simplified : i have written a little script that abstracts the tools. In fact it's so simple that i wonder why it was not done before by others. This script is important because - it is distrubuted under GPL and can be used by others for other projects - it can be easily enhanced (it's written in bash) - whatever the tool suites installed on your computer, there is only one script to write for compiling and testing a design unit So F-CPU remains free because it is independent from the tools. If there was any problem with a sponsor, the development would still continue in freedom. No tool-dependent feature is used and all the sources are tested against know tools for compliance. If F-CPU ever happens to not keep its promises, at least all this work will be important for other projects. > > Do you use Free Software to develop the designs or are > > you forced to use proprietary packages? Is there some hope > > to have free software replacements for these packages? > > There is some problem with programable logic boards, isn't there? > > I'd really like to use free tools, but those that are available > (FreeHDL, Savant) are less developed than their closed-source > counterparts. The lack of "decent" Free EDA tools is alarming. Most "Open Hardware" designs are developped with one or maybe two proprietary tools, thus reinforcing their importance. EDA vendors are smart. Those designs written with a Free tool often do not correspond to industry standards : they become useless. Currently, there is a solution to keep the design free from dependencies from proprietary tools, but F-CPU's goal is not to write EDA tools. If at least FreeHDL worked... > > Do you see some direct connection between libre > > hardware designs and Free Software? Richard > > Stallman says the question of freedom > > is not really relevant for hardware because > > only few people can actually 'copy' hardware. > > I think your point of view is different > > as is the one of Graham Seaman? > > Times are changing. Ten years ago, almost nobody knew Free Software or > the GNU project. PC users had to deal with Microsoft operating systems > exclusively. Today, we have Linux, *BSD, the HURD and masses of other > software that are freely available. Who knows what will happen ten > years from now? > > Today, it's rather difficult (and expensive) to `copy' or `modify' > hardware. It also was difficult to copy a CD in the 1980ies, but today > every PC can do it. In 2020, you may be able to buy a blank gate or cell > array for 7,95 EUR in every other supermarket, and program it yourself. > `Free Hardware' projects like F-CPU or OpenCores are only the beginning. I think that when Richard spoke about this, he missed the point. I think it was two years ago and even him changed since then. But we don't require his blessing to make F-CPU and he seems to understand what is at stake on this front, particularly when one considers the DMCA and other laws, or the merciful monopoly of Intel (MIPS and ALPHA are dropped from the workstation market and PowerPC is rumored to follow). When i joined F-CPU, i saw it as the only "way out" for me (i can't say how much i'm sick of my PCs). Since year 2000 (rumors of copy protection on ATA, ALPHA dropped) i understand that it will become the only solution for others too ! I work in an egotistical way but i know that it's also important not only for the Free Software movement, but also the computer industry. When i discuss with Richard, there is no disagreement when you forget his usual pickiness :-) F-CPU definitely has philosophical and technical connexions with the FSF and the Linux community but we have to invent something else. Graham Seaman has a very deep understanding of the "Free Hardware" movement because he observes and interacts with the electronics industry for decades. He is very instructive and his character is probably the contrary of Richard on a lot of points (i met both several times). I can't say that one is wrong, they speak about completely different things with different points of view and they have different goals (like : Graham doesn't lead a jihad ;-D) But i don't care about right or wrong. Only source code is a tangible proof, and we're writing it. Once again, "Design and let design" :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Sep 2 15:22:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lsv5-0001Zv-00 for ; Mon, 02 Sep 2002 17:15:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 17:15:15 +0200 (CEST) Received: (qmail 9070 invoked by uid 0); 2 Sep 2002 13:22:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 2 Sep 2002 13:22:28 -0000 Received: by moria.seul.org (Postfix) id 8376315E7A8; Mon, 2 Sep 2002 09:22:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4933015E7D1; Mon, 2 Sep 2002 09:22:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 0B8C215E7A8 for ; Mon, 2 Sep 2002 09:22:25 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix3-2.free.fr (Postfix) with ESMTP id 0E65017DD4 for ; Mon, 2 Sep 2002 15:22:21 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 438B86411E; Mon, 2 Sep 2002 15:22:21 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] Memory add/sub Message-ID: <1030972941.3d73660d2059d@imp.free.fr> Date: Mon, 02 Sep 2002 15:22:21 +0200 (MEST) From: Cedric BAIL References: <1030887053.3d72168d9749a@imp.free.fr> <20020901194127.26273@thrai.stud.uni-hannover.de> <3D729483.70B9B299@f-cpu.org> In-Reply-To: <3D729483.70B9B299@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hello, > i really wonder what this thing is really about... > anyway. ;-) > Michael Riepe wrote: > > On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: > > > If we want to correctly manage a stack with pop/push operation, we > > > need a add/sub operator that preserve the LSU information bit. > really ? yes > push/pop is just one use of pointer updates, and the existing > post-increment (with register or immediate modifier) has > already been discussed, right ? Yes, and you perhaps forgot that the solution need a add/sub before doing a pop after the last push. > > > I propose something > > > like that : madd[0-7] and msub[0-7]. I don't know if we need size for > > > this operation or endian, I think not. Stream information is needed > > > if we want to implement them by simply multipling the number of LSU. > do you mean that you want to add or substract up to 7 bytes from a > pointer ? euh... I was speacking about stream in the instruction (all load/store have it). You know the cray like feature ;-) > the existing post-increment does this already, and you get a load or > store for free. If you want to hust update the pointer, "load" R0 so the > result is cancelled. "Think RISC". Or should i say : project yourself in an > over-simplified world. I say no, it doesn't update the pointer before memory operation. And in a lot of case we need that (compiler need it when they manipulate object or in certain case the stack because of big jump). > > > In the same idea I think we need to affect some stream, for > > > example 0 for unknow stream and 7 for stack. What did you think > > > about that ? > allocating stream now would reduce our scalability in the future : > we still have a lot of other means to do specific things : we can add > some instructions for example. I think that not a good solution. But what append if you compiler can detect that stack and malloc are not the same stream and want to allocate them. It can't because he will use external librairie that will always use the default stream 0. So he will never be able to use them ! So if we don't say any thing about stream now before any application are written, we can remove this feature I think. And I don't see why adding instructions or delaying the problem will solve it. > > I already outlined the need for such a `pointer add' instruction last > > year. Programs that deal with structures (or classes/objects) will > > need it quite often. > then just do a "load" to this pointer, put the result in R0 > and update the pointer with the register or immediate value you want. ??? What are you doing ??? You prefer to do a memory operation instead of only updating a pointer ? In fact you use a hack to do something like madd/msub, but that isn't clean ! Think RISC, don't forget ;-) > Is a specific instruction really needed ? Yes, and absolutely yes ! Or you must specially handle load/store to R0, you prefer to complexify a complex instruction instead of adding a simpler instruction... Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Sep 2 17:27:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lvfp-0003m0-00 for ; Mon, 02 Sep 2002 20:11:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:11:41 +0200 (CEST) Received: (qmail 1237 invoked by uid 0); 2 Sep 2002 15:28:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 2 Sep 2002 15:28:09 -0000 Received: by moria.seul.org (Postfix) id B35DC15E7AA; Mon, 2 Sep 2002 11:28:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8072015E7D5; Mon, 2 Sep 2002 11:28:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (mallaury.noc.nerim.net [62.4.17.82]) by moria.seul.org (Postfix) with ESMTP id 1A3FD15E7AA for ; Mon, 2 Sep 2002 11:28:08 -0400 (EDT) Received: from rezo.net (telehouse-101-1-252.net1.nerim.net [213.41.190.252]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 76A5962D3A for ; Mon, 2 Sep 2002 17:28:05 +0200 (CEST) Message-ID: <3D73837C.7050206@rezo.net> Date: Mon, 02 Sep 2002 17:27:56 +0200 From: Antoine User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: fr,en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] ll / sc, cas2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, Some interesting reading on the subject : http://www-dsg.stanford.edu/papers/non-blocking-osdi/non-blocking-osdi.html yours Antoine. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Sep 2 22:59:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lvfq-0003m0-00 for ; Mon, 02 Sep 2002 20:11:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:11:42 +0200 (CEST) Received: (qmail 24241 invoked by uid 0); 2 Sep 2002 16:00:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 2 Sep 2002 16:00:09 -0000 Received: by moria.seul.org (Postfix) id E25A815E7D2; Mon, 2 Sep 2002 12:00:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9978615E7D6; Mon, 2 Sep 2002 12:00:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 2E9E115E7D2 for ; Mon, 2 Sep 2002 12:00:08 -0400 (EDT) Received: from club-internet.fr (flashmail-1m.cs.clubint.net [172.16.20.60]) by relay-5m.club-internet.fr (Postfix) with SMTP id 37F90E0F6 for ; Mon, 2 Sep 2002 18:00:06 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Memory add/sub Date: Mon, 2 Sep 2002 17:59:43 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi there, >De: Cedric BAIL >> hello, = > = >> i really wonder what this thing is really about... = >> anyway. = >;-) = :-/ >> Michael Riepe wrote: = >>> On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: = >>>> If we want to correctly manage a stack with pop/push operation, we = >>>> need a add/sub operator that preserve the LSU information bit. = >> really ? = >yes = OMG... >> push/pop is just one use of pointer updates, and the existing = >> post-increment (with register or immediate modifier) has = >> already been discussed, right ? = >Yes, and you perhaps forgot that the solution need a add/sub > before doing a pop after the last push. or a push without pointer update. >>>> I propose something = >>>> like that : madd=5B0-7=5D and msub=5B0-7=5D. so you think about a simple a+b=3D>c instruction ? then the existing one will do the trick, maybe with 1 or 2 cycles of penalty (and no prefetch). >>>> I don't know if we need size for = >>>> this operation or endian, I think not. Stream information is needed = >>>> if we want to implement them by simply multipling the number of LSU. = >> do you mean that you want to add or substract up to 7 bytes from a = >> pointer ? = >euh... I was speacking about stream in the instruction > (all load/store have it). You know the cray like feature ;-) = =5Bremark : it's not Cray per se. Cray had left Cray Research for more than 10 years when the T3D appeared.=5D >> the existing post-increment does this already, and you get a load or = >> store for free. If you want to hust update the pointer, =22load=22 R0 s= o the = >> result is cancelled. =22Think RISC=22. Or should i say : project yourse= lf in an = >> over-simplified world. = >I say no, it doesn't update the pointer before memory operation. And in = >a lot of case we need that (compiler need it when they manipulate object = >or in certain case the stack because of big jump). = if the result of the load is cancelled, then the pointer update is not subject to order problems, and it does just what you want at no cost. >>>> In the same idea I think we need to affect some stream, for = >>>> example 0 for unknow stream and 7 for stack. What did you think = >>>> about that ? = >> allocating stream now would reduce our scalability in the future : = >> we still have a lot of other means to do specific things : we can add = >> some instructions for example. = >I think that not a good solution. and i think the contrary (not a surprise, right ? ;-D) > But what append if you compiler = >can detect that stack and malloc are not the same stream and want to allo= cate = >them. It can't because he will use external librairie that will always us= e = >the default stream 0. So he will never be able to use them =21 = this flag is a =22hint=22 and its semantics is not well defined yet. it's ok to separate streams but what if there is a collision in your library ? or if the semantics is interpreted differently from software to software ? and do you know ANY compiler that does that anyway ?... >So if we don't say any thing about stream now before any application = >are written, we can remove this feature I think. And I don't see why = >adding instructions or delaying the problem will solve it. = we have a lot of time to populate the stream hint flags : the architecture is meant to last for decades, and you already want to reduce vitale extension possibilities. >>> I already outlined the need for such a =60pointer add' instruction las= t = >>> year. Programs that deal with structures (or classes/objects) will = >>> need it quite often. = >> then just do a =22load=22 to this pointer, put the result in R0 = >> and update the pointer with the register or immediate value you want. = >??? What are you doing ??? consider that as a =22side effect=22. Otherwise, why would we take care about making a =22zero=22 register ? do you know that in hardware, it's a pain to do ? > You prefer to do a memory operation = >instead of only updating a pointer ? In fact you use a hack to do = >something like madd/msub, but that isn't clean =21 Think RISC, don't = >forget ;-) = OMG.... Then look at a MIPS CPU and how it is used. for example, comparison is just another form of substraction. and it's only the simplest example. why add a new scheduling complexity when the same operation is already done by another instruction ? Take some course about RISC, i mean, 1990-era when silicon was not so large... >> Is a specific instruction really needed ? = >Yes, and absolutely yes =21 Or you must specially handle load/store >to R0, you prefer to complexify a complex instruction instead of = >adding a simpler instruction... = tell me : what was the previous side effect of doing a load to R0 ? IIRC it did a prefetch. isn't it what you want to do ? >Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Mon Sep 2 18:52:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lvfs-0003m0-00 for ; Mon, 02 Sep 2002 20:11:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:11:44 +0200 (CEST) Received: (qmail 2493 invoked by uid 0); 2 Sep 2002 16:52:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 2 Sep 2002 16:52:35 -0000 Received: by moria.seul.org (Postfix) id 7C9DA15E71E; Mon, 2 Sep 2002 12:52:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 51E3815E7D6; Mon, 2 Sep 2002 12:52:34 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 4F6A115E71E for ; Mon, 2 Sep 2002 12:52:33 -0400 (EDT) Received: from laposte.net (193.250.226.206) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3D32A1F9002F1A54 for f-cpu@seul.org; Mon, 2 Sep 2002 18:52:32 +0200 Message-ID: <3D739756.2080101@laposte.net> Date: Mon, 02 Sep 2002 18:52:38 +0200 From: Lavergne Thomas Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: fr, fr-fr, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Memory add/sub References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >>>push/pop is just one use of pointer updates, and the existing >>>post-increment (with register or immediate modifier) has >>>already been discussed, right ? >> >>Yes, and you perhaps forgot that the solution need a add/sub >>before doing a pop after the last push. > > or a push without pointer update. > And you forgot the problems when the push/pop sequence was stoped by an interuption or a trap... -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://assoc.wanadoo.fr/thallium/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 3 00:21:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lvfu-0003m0-00 for ; Mon, 02 Sep 2002 20:11:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:11:46 +0200 (CEST) Received: (qmail 12837 invoked by uid 0); 2 Sep 2002 17:21:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 2 Sep 2002 17:21:57 -0000 Received: by moria.seul.org (Postfix) id DD31815E7D4; Mon, 2 Sep 2002 13:21:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A770815E7D7; Mon, 2 Sep 2002 13:21:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 2BA7A15E7D4 for ; Mon, 2 Sep 2002 13:21:55 -0400 (EDT) Received: from club-internet.fr (flashmail-5m.cs.clubint.net [172.16.20.64]) by relay-1m.club-internet.fr (Postfix) with SMTP id 13D6C1685 for ; Mon, 2 Sep 2002 19:21:53 +0200 (CEST) Received: from [212.43.214.31] by flashmail-5m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Memory add/sub Date: Mon, 2 Sep 2002 19:21:11 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, ----Message d'origine---- De: Lavergne Thomas >>>>push/pop is just one use of pointer updates, and the existing = >>>>post-increment (with register or immediate modifier) has = >>>>already been discussed, right ? = >>> >>>Yes, and you perhaps forgot that the solution need a add/sub >>>before doing a pop after the last push. >> = >> or a push without pointer update. >> = > >And you forgot the problems when the push/pop sequence was stoped by an = >interuption or a trap... This is not a problem, unless you are suicidal enough to use the interrupted task's stack (and particularly in the case of a fault). >Thomas Lavergne YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Sep 2 19:57:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lvfv-0003m0-00 for ; Mon, 02 Sep 2002 20:11:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:11:47 +0200 (CEST) Received: (qmail 15122 invoked by uid 0); 2 Sep 2002 17:57:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 2 Sep 2002 17:57:53 -0000 Received: by moria.seul.org (Postfix) id 4BE1D15E72A; Mon, 2 Sep 2002 13:57:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1985E15E7D8; Mon, 2 Sep 2002 13:57:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 85F1215E72A for ; Mon, 2 Sep 2002 13:57:51 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-2.free.fr (Postfix) with ESMTP id D36905F7E3 for ; Mon, 2 Sep 2002 19:57:48 +0200 (CEST) Received: by imp1-1.free.fr (Postfix, from userid 33) id 650CB64117; Mon, 2 Sep 2002 19:57:48 +0200 (MEST) To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Memory add/sub Message-ID: <1030989468.3d73a69c12367@imp.free.fr> Date: Mon, 02 Sep 2002 19:57:48 +0200 (MEST) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 217.128.36.20 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >> Michael Riepe wrote: > >>> On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: > >>>> If we want to correctly manage a stack with pop/push operation, we > >>>> need a add/sub operator that preserve the LSU information bit. > >> really ? > >yes > OMG... What did you mean by OMG ? Something linked with DNA ? > >> push/pop is just one use of pointer updates, and the existing > >> post-increment (with register or immediate modifier) has > >> already been discussed, right ? > >Yes, and you perhaps forgot that the solution need a add/sub > > before doing a pop after the last push. > or a push without pointer update. > >>>> I propose something > >>>> like that : madd[0-7] and msub[0-7]. > so you think about a simple a+b=>c instruction ? > then the existing one will do the trick, maybe with > 1 or 2 cycles of penalty (and no prefetch). It's why I want this, for prefetch and only prefetch. > >> the existing post-increment does this already, and you get a load or > >> store for free. If you want to hust update the pointer, "load" R0 so the > >> result is cancelled. "Think RISC". Or should i say : project yourself in > >> an over-simplified world. > >I say no, it doesn't update the pointer before memory operation. And in > >a lot of case we need that (compiler need it when they manipulate object > >or in certain case the stack because of big jump). > if the result of the load is cancelled, then the pointer > update is not subject to order problems, and it does just > what you want at no cost. Perhaps, but the load are done, I mean the data are loaded from the LSU, so you ask something you didn't need. > >>>> In the same idea I think we need to affect some stream, for > >>>> example 0 for unknow stream and 7 for stack. What did you think > >>>> about that ? > >> allocating stream now would reduce our scalability in the future : > >> we still have a lot of other means to do specific things : we can add > >> some instructions for example. > >I think that not a good solution. > and i think the contrary (not a surprise, right ? ;-D) of course ;-D > > But what append if you compiler can detect that stack and malloc are not > > the same stream and want to allocate them. It can't because he will use > > external librairie that will always use the default stream 0. So he will > > never be able to use them ! > this flag is a "hint" and its semantics is not well defined yet. > it's ok to separate streams but what if there is a collision > in your library ? or if the semantics is interpreted differently > from software to software ? and do you know ANY compiler that > does that anyway ?... Yes, GCC does it (man memcpy for a start). And the meaning of this hint is, correct me if I am wrong, don't check coerrency with the other stream than myself. > >So if we don't say any thing about stream now before any application > >are written, we can remove this feature I think. And I don't see why > >adding instructions or delaying the problem will solve it. > we have a lot of time to populate the stream hint flags : > the architecture is meant to last for decades, and you already > want to reduce vitale extension possibilities. To late, as I explained earlier, if we don't say before having any binary, for compability reason, we will lose all the interest of this feature. For example if you call memcpy, without saying anything about stream params, you will never be able to use a stream for read and an other for write... > >>> I already outlined the need for such a `pointer add' instruction last > >>> year. Programs that deal with structures (or classes/objects) will > >>> need it quite often. > >> then just do a "load" to this pointer, put the result in R0 > >> and update the pointer with the register or immediate value you want. > > >??? What are you doing ??? > consider that as a "side effect". Otherwise, why would > we take care about making a "zero" register ? do you know > that in hardware, it's a pain to do ? It's clearly a hack ! > > You prefer to do a memory operation > >instead of only updating a pointer ? In fact you use a hack to do > >something like madd/msub, but that isn't clean ! Think RISC, don't > >forget ;-) > OMG.... > Then look at a MIPS CPU and how it is used. > for example, comparison is just another form of > substraction. and it's only the simplest example. > why add a new scheduling complexity when the > same operation is already done by another instruction ? > Take some course about RISC, i mean, 1990-era > when silicon was not so large... Yes, but we are not doing a MIPS... but something powerfull and clean... > >> Is a specific instruction really needed ? > >Yes, and absolutely yes ! Or you must specially handle load/store > >to R0, you prefer to complexify a complex instruction instead of > >adding a simpler instruction... > tell me : what was the previous side effect of doing a load to > R0 ? IIRC it did a prefetch. isn't it what you want to do ? Yes, but I didn't want a hack ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Sep 3 01:33:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17lwEK-00045b-00 for ; Mon, 02 Sep 2002 20:47:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Sep 2002 20:47:20 +0200 (CEST) Received: (qmail 4396 invoked by uid 0); 2 Sep 2002 18:34:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 2 Sep 2002 18:34:16 -0000 Received: by moria.seul.org (Postfix) id C62E015E7D8; Mon, 2 Sep 2002 14:34:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A5A315E7DB; Mon, 2 Sep 2002 14:34:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2753B15E7D8 for ; Mon, 2 Sep 2002 14:34:15 -0400 (EDT) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-3v.club-internet.fr (Postfix) with SMTP id ACB9A1688; Mon, 2 Sep 2002 20:34:13 +0200 (CEST) Received: from [62.212.107.173] by flashmail-2v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] Memory add/sub Date: Mon, 2 Sep 2002 20:33:21 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi there, This instruction (pointer add, could be =22padd=22, or =22madd=22 but it sounds too crayzy, moomoo...) is annoying. it is doing what two other instructions already do : add/sub and load->R0. The ONLY reason i see to include it is that it allows a =223-address=22 instruction, allowing some other sofware constructs that are less constraining. That's all. Scheduling, latency, etc. : this will change in the future. Maybe a future architecture will be smart enough to recognize that an arbitrary operation will create a pointer. Who knows. I don't see this as important : the whole core is not finished yet and everybody wants his instruction. Yet, the manual is very hard to maintain. Then guess why i prefer to concentrate on the code. Include this instruction in the set if you want but take your responsibilities then. If you ask for something that can't be implemented, i won't do any magic. 'night, YG (tired). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Sep 11 00:20:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17otQf-0001ZT-01 for ; Wed, 11 Sep 2002 00:24:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Sep 2002 00:24:17 +0200 (CEST) Received: (qmail 30705 invoked by uid 0); 10 Sep 2002 22:10:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 10 Sep 2002 22:10:04 -0000 Received: by moria.seul.org (Postfix) id 498CE15E78F; Tue, 10 Sep 2002 18:10:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C8BBD15E792; Tue, 10 Sep 2002 18:10:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4D65615E78F for ; Tue, 10 Sep 2002 18:10:00 -0400 (EDT) Received: from f-cpu.org (kdl14-125.n.club-internet.fr [213.44.12.125]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 6AB1B169A for ; Wed, 11 Sep 2002 00:09:58 +0200 (CEST) Message-ID: <3D7E7047.6010809@f-cpu.org> Date: Wed, 11 Sep 2002 00:20:55 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] new news Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, has anyone seen the news ? http://f-cpu.seul.org/daCode/ It mostly concerns the french people because the western Africa is mostly french speaking, but the decisions belong to this list anyway. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Tue Sep 10 17:19:16 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17otQP-0001ZT-00 for ; Wed, 11 Sep 2002 00:24:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Sep 2002 00:24:01 +0200 (CEST) Received: (qmail 27677 invoked by uid 0); 10 Sep 2002 15:15:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 10 Sep 2002 15:15:20 -0000 Received: by moria.seul.org (Postfix) id 510D415E784; Tue, 10 Sep 2002 11:15:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0AFD615E78C; Tue, 10 Sep 2002 11:15:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf26bis.bellsouth.net (mail026.mail.bellsouth.net [205.152.58.66]) by moria.seul.org (Postfix) with ESMTP id 6F03315E784 for ; Tue, 10 Sep 2002 11:15:17 -0400 (EDT) Received: from computer ([208.60.245.230]) by imf26bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020910151504.WQZR19756.imf26bis.bellsouth.net@computer>; Tue, 10 Sep 2002 11:15:04 -0400 Message-ID: <000801c258dd$6e449400$e6f53cd0@computer> From: "richard hartny" To: Cc: , Subject: [f-cpu] Erin Processors Date: Tue, 10 Sep 2002 10:19:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C258B3.846B25C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C258B3.846B25C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chuck & Support I want to thank both of you for your very good support. The Erin64 = Processor gave me some very good performance numbers. It was my = original intent to use two of these in each system; one for Language = (9,976 instructions) and one for Peripheral processing. (System = Dependent) I did a little brainstorming and will use an almost total change of = concept. I will still use the Erin64 for Peripheral processing. Now = comes the change of concept. I will use the On-Chip Ram for Instructions and operands. I will = use 12 Ram Blocks for instructions (512 x 54), and 16 Ram Blocks for = Source/Destination Data. (512 x 64). This will almost negate the need for SSRAM off chip. In = addition I will use one Ql6600 for EACH of the Operating system Language = processes. This will require approx 30 - 35 devices where access to the = Operator (chip) is accessed via Interrupt. The device will contain ONLY = those functions required by the sub-routine which it Emulates and contains a four instruction pipeline. Scheduling = these requests is a concern but not a major one, as the software = contains a Skedular. For highly re-entrant routines I will use = duplicate functions to prevent a log-jam; however a little math says it = won't happen. (128 Users typing at 100 Words per minute) or using = mouse/lightpen selections. Back to work - QUESTIONS???? Dick Hartney ------=_NextPart_000_0005_01C258B3.846B25C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chuck & Support
 
    I want to thank both = of you for=20 your very good support. The Erin64 Processor gave me some very good = performance=20 numbers.  It was my original intent to use two of these in each = system; one=20 for Language (9,976 instructions) and one for Peripheral processing. = (System=20 Dependent)
 
    I did a little = brainstorming and=20 will use an almost total change of  concept.  I will still use = the=20 Erin64 for Peripheral processing.  Now comes the change of=20 concept.
 
    I will use the = On-Chip Ram for=20 Instructions and operands.  I will use 12 Ram Blocks for = instructions=20 (512 x 54), and 16 Ram Blocks for Source/Destination Data.
(512 x 64).  This will almost = negate the need=20 for SSRAM off chip.  In addition I will use one Ql6600 = for EACH of the=20 Operating system Language processes.  This will require approx 30 - = 35=20 devices where access to the Operator (chip) is accessed via = Interrupt.  The=20 device will contain ONLY those functions required by the=20 sub-routine
which it Emulates and contains a four = instruction=20 pipeline. Scheduling these requests is a concern but not a major one, as = the=20 software contains a Skedular.  For highly re-entrant routines I = will use=20 duplicate functions to prevent a log-jam; however a little math says it = won't=20 happen. (128 Users typing at 100 Words per minute) or using = mouse/lightpen=20 selections.
 
Back to work - = QUESTIONS????
 
Dick Hartney
------=_NextPart_000_0005_01C258B3.846B25C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kbmljohanna45a@malaysia.cc Sun Feb 10 22:35:47 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17otQe-0001ZT-00 for ; Wed, 11 Sep 2002 00:24:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Sep 2002 00:24:16 +0200 (CEST) Received: (qmail 8078 invoked by uid 0); 10 Sep 2002 20:32:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 10 Sep 2002 20:32:53 -0000 Received: by moria.seul.org (Postfix) id EB9E215E78E; Tue, 10 Sep 2002 16:32:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 978E715E796; Tue, 10 Sep 2002 16:32:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 848D315E78E for ; Tue, 10 Sep 2002 16:32:50 -0400 (EDT) Received: from 210.22.158.90 (200-206-140-244.dsl.telesp.net.br [200.206.140.244]) by bettik.munge.net (Postfix) with SMTP id C98274F750 for ; Tue, 10 Sep 2002 15:32:05 -0500 (CDT) Received: from unknown (HELO rly-xw01.mx.aol.com) (96.213.243.25) by n9.groups.yahoo.com with asmtp; Feb, 10 2002 22:21:32 -0700 Received: from unknown (149.89.93.47) by rly-xr02.mx.aol.com with NNFMP; Feb, 10 2002 21:32:22 -0300 Received: from unknown (HELO da001d2020.lax-ca.osd.concentric.net) (194.29.209.49) by f64.law4.hotmail.com with QMQP; Feb, 10 2002 20:24:32 -0200 From: ikrrRechtsanwalt A Fortun To: f-cpu@seul.org Subject: [f-cpu] Sie haben gewonnen acv Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 10 Feb 2002 22:35:47 +0100 X-Mailer: Microsoft Outlook Build 10.0.2627 Message-Id: <20020910203205.C98274F750@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Herzliche Glückwünsche, Sie haben gewonnen. Mehr Informationen finden Sie hier: http://gewinnspiel.computer.webseite.to/?pi=352&fi=12&li= lvpddyymuwaxvrljsvluwxuvtthsatbxynjnpdl ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From LebanonTania@yahoo.com Wed Sep 11 03:02:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17p3eu-0000H4-00 for ; Wed, 11 Sep 2002 11:19:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Sep 2002 11:19:40 +0200 (CEST) Received: (qmail 28659 invoked by uid 0); 11 Sep 2002 01:02:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 11 Sep 2002 01:02:16 -0000 Received: by moria.seul.org (Postfix) id D81F815E790; Tue, 10 Sep 2002 21:02:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76EEB15E794; Tue, 10 Sep 2002 21:02:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from 169.254.219.47 (unknown [63.172.9.25]) by moria.seul.org (Postfix) with SMTP id CB02B15E790 for ; Tue, 10 Sep 2002 21:02:08 -0400 (EDT) From: Tania To: f-cpu@seul.org Subject: [f-cpu] ALERT, Next terrorist attack Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii X-GCMulti: 1 Message-Id: <20020911010208.CB02B15E790@moria.seul.org> Date: Tue, 10 Sep 2002 21:02:08 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N
Prevent Next Terrorist attack

The totalitarian regime of Syria has been building and sponsoring terrorist groups in Lebanon since early seventies. Syria has invaded Lebanon gradually till it gained a complete control over the capital Beirut in 1990. Lebanon, under Syrian occupation, was turned from a democratic country to a totalitarian regime ruled by the Syrian army and intelligence. YOU Can Help Lebanon and the USA by supporting the bill entitled "The Syria Accountability Act" that was introduced to the Congress last April. This legislation calls for an end of the Syrian occupation of Lebanon and the cessation by Syria of all terrorist activities. Please Act Now, hearing begins Sep 12th

It takes one minute http://lebanon.tonysky.net

God Bless America

Sincerely yours

Tania

 

Please pass this message.

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Wed Sep 11 13:33:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJBo-00026l-01 for ; Thu, 12 Sep 2002 03:54:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:54:40 +0200 (CEST) Received: (qmail 26308 invoked by uid 0); 11 Sep 2002 11:33:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 11 Sep 2002 11:33:11 -0000 Received: by moria.seul.org (Postfix) id 86DAF15E798; Wed, 11 Sep 2002 07:33:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 07C3615E79B; Wed, 11 Sep 2002 07:33:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 965B915E798; Wed, 11 Sep 2002 07:33:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 5927015E796 for ; Wed, 11 Sep 2002 07:33:01 -0400 (EDT) Date: Wed, 11 Sep 2002 07:33:01 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: Re: [f-cpu] new news In-Reply-To: <3D7E7047.6010809@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 11 Sep 2002, Yann Guidon wrote: > Hi, > > has anyone seen the news ? > http://f-cpu.seul.org/daCode/ > > It mostly concerns the french people > because the western Africa is mostly > french speaking, but the decisions belong > to this list anyway. > Where is the backend.rss file on the new site? I'd like to put the news summary back on opencollector now dacode is running again... :-) Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Sep 11 14:02:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJBt-00026l-01 for ; Thu, 12 Sep 2002 03:54:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:54:45 +0200 (CEST) Received: (qmail 1019 invoked by uid 0); 11 Sep 2002 17:54:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 11 Sep 2002 17:54:09 -0000 Received: by moria.seul.org (Postfix) id E9ACA15E7B1; Wed, 11 Sep 2002 13:54:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA05D15E7B6; Wed, 11 Sep 2002 13:54:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a195.home.uni-hannover.de [130.75.232.195]) by moria.seul.org (Postfix) with ESMTP id 69D7915E7B1 for ; Wed, 11 Sep 2002 13:54:07 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00521; Wed, 11 Sep 2002 14:02:13 +0200 Message-ID: <20020911140213.52046@thrai.stud.uni-hannover.de> Date: Wed, 11 Sep 2002 14:02:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new news References: <3D7E7047.6010809@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D7E7047.6010809@f-cpu.org>; from Yann Guidon on Wed, Sep 11, 2002 at 12:20:55AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 11, 2002 at 12:20:55AM +0200, Yann Guidon wrote: > Hi, > > has anyone seen the news ? > http://f-cpu.seul.org/daCode/ Haven't looked at it for ages (I only use the board). > It mostly concerns the french people > because the western Africa is mostly > french speaking, but the decisions belong > to this list anyway. If it belongs here, then post it here, please. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.Fr Wed Sep 11 23:01:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJC9-00026l-00 for ; Thu, 12 Sep 2002 03:55:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:55:01 +0200 (CEST) Received: (qmail 22424 invoked by uid 0); 11 Sep 2002 20:52:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 11 Sep 2002 20:52:27 -0000 Received: by moria.seul.org (Postfix) id 8318815E73A; Wed, 11 Sep 2002 16:52:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4322415E7B2; Wed, 11 Sep 2002 16:52:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id B650115E73A for ; Wed, 11 Sep 2002 16:52:25 -0400 (EDT) Received: from tux (nas-cbv-11-62-147-117-167.dial.proxad.net [62.147.117.167]) by postfix2-2.free.fr (Postfix) with ESMTP id 22D4F5F768 for ; Wed, 11 Sep 2002 22:52:23 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Cedric BAIL Organization: EPITA To: f-cpu@seul.org Subject: [f-cpu] Memory convention Date: Wed, 11 Sep 2002 23:01:02 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209112301.02220.cedric.bail@free.Fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi every body, =09I am currently adding some new parts to the manual (SR MAP, changing optionales instructions, ...) and I think that we need to clarify some little thing about memory operation. =09First we must specify if we are using by default little or big endian, because librairies will dislike to manipulate big endian data if they wai= t for little endian. I think that for portability reason we must specify li= ttle endian by default, as a memory convention. =09Second stream hints call convention. As I explain to Yann, we need a call convention for stream hints too. Because if we don't do that we will have a lot of diffculty to use it in the normal case. The=20 problem is that for example if we say stream 0 for stack and 8 for=20 malloced data, what append if we pass it to a function that use it as a pointer ? Certainly a crach. =09So I see three possibilty (If you have other idea) : =09- First : say always stream 0 for all parameter and all =09exported pointer =3D> Easy, but stream have no interrest =09- Second : as NicO suggest to me, do something like a flush all =09LSU instruction (certainly add a flag to serialize) =09=3D> A little bit better, but you loose all your cached data... =09- Third : Add a new instruction that take a pointer and change =09the associated stream to it =3D> problem with copy, but the =09most easiest for a compiler to generate optimal code. =09The last case can be handle by a madd/msub with r0 for parameter, but it create a copy of the pointer and well that can be a problem. And currently I think that if you change the stream hints with madd/msub the result must be unknow (normally madd/msub are used to walk in the same memory area). =09And a new instruction will certainly be cleaner. =09Finally, I am sure that some body will say, it's not a problem, it will not be implemented into the FC0... So I will answer directly, why speacking about this now. Imagine you are now working on the libc and you are porting it on the F-CPU, for example the string operation. =09Take strdup as an example. If you don't know wich stream to use you will generate a simple code that will work with only stream 0. And then a guy came and say now the call convention say stream must be like this. Will you change all you code ? I think not, and=20 perhaps a lot of people will not do it. =09But before starting discussion on stream hints call convention, we must take a decision on witch solution we choose for=20 synchronising different LSU. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 12 00:18:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJCB-00026l-00 for ; Thu, 12 Sep 2002 03:55:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:55:03 +0200 (CEST) Received: (qmail 17738 invoked by uid 0); 11 Sep 2002 22:18:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 11 Sep 2002 22:18:54 -0000 Received: by moria.seul.org (Postfix) id 855AE15E721; Wed, 11 Sep 2002 18:18:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E00815E7B2; Wed, 11 Sep 2002 18:18:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a163.home.uni-hannover.de [130.75.232.163]) by moria.seul.org (Postfix) with ESMTP id 7FC9F15E721 for ; Wed, 11 Sep 2002 18:18:50 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02271; Thu, 12 Sep 2002 00:18:48 +0200 Message-ID: <20020912001848.52501@thrai.stud.uni-hannover.de> Date: Thu, 12 Sep 2002 00:18:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Memory convention References: <200209112301.02220.cedric.bail@free.Fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200209112301.02220.cedric.bail@free.Fr>; from Cedric BAIL on Wed, Sep 11, 2002 at 11:01:02PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Sep 11, 2002 at 11:01:02PM +0200, Cedric BAIL wrote: > First we must specify if we are using by default little or big endian, > because librairies will dislike to manipulate big endian data if they wait > for little endian. I think that for portability reason we must specify little > endian by default, as a memory convention. Since the default (for load/store) is little endian, and since little endian makes more sense with SIMD, it should be the default. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 12 02:56:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJCB-00026l-01 for ; Thu, 12 Sep 2002 03:55:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:55:03 +0200 (CEST) Received: (qmail 27256 invoked by uid 0); 12 Sep 2002 00:45:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Sep 2002 00:45:20 -0000 Received: by moria.seul.org (Postfix) id C8A0615E7B5; Wed, 11 Sep 2002 20:45:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B631915E7B8; Wed, 11 Sep 2002 20:45:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 537A015E7B5 for ; Wed, 11 Sep 2002 20:45:19 -0400 (EDT) Received: from f-cpu.org (kdl14-10.n.club-internet.fr [213.44.12.10]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3329A1689 for ; Thu, 12 Sep 2002 02:45:17 +0200 (CEST) Message-ID: <3D7FE62F.5000407@f-cpu.org> Date: Thu, 12 Sep 2002 02:56:15 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new news References: <3D7E7047.6010809@f-cpu.org> <20020911140213.52046@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Sep 11, 2002 at 12:20:55AM +0200, Yann Guidon wrote: > > >>Hi, >> >>has anyone seen the news ? >>http://f-cpu.seul.org/daCode/ >> >Haven't looked at it for ages (I only use the board). > And even that is not done so often, lately ;-) >>It mostly concerns the french people >>because the western Africa is mostly >>french speaking, but the decisions belong >>to this list anyway. >> > If it belongs here, then post it here, please. I hope you'll forgive my laziness... you see, i was even lazy to send a post about the meeting with Boubakar... even though the partnership with UNESCO might be very important. I hope that others will relieve me from the explanation chores :-) Renaud ? nicO ?... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 12 02:56:19 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJCC-00026l-00 for ; Thu, 12 Sep 2002 03:55:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:55:04 +0200 (CEST) Received: (qmail 12339 invoked by uid 0); 12 Sep 2002 00:45:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 12 Sep 2002 00:45:23 -0000 Received: by moria.seul.org (Postfix) id 7E7B915E7B7; Wed, 11 Sep 2002 20:45:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5092D15E7BA; Wed, 11 Sep 2002 20:45:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id D6EBA15E7B7 for ; Wed, 11 Sep 2002 20:45:21 -0400 (EDT) Received: from f-cpu.org (kdl14-10.n.club-internet.fr [213.44.12.10]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 46DC6169E for ; Thu, 12 Sep 2002 02:45:19 +0200 (CEST) Message-ID: <3D7FE633.8070707@f-cpu.org> Date: Thu, 12 Sep 2002 02:56:19 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Memory convention References: <200209112301.02220.cedric.bail@free.Fr> <20020912001848.52501@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Sep 11, 2002 at 11:01:02PM +0200, Cedric BAIL wrote: > > >>First we must specify if we are using by default little or big endian, >>because librairies will dislike to manipulate big endian data if they wait >>for little endian. I think that for portability reason we must specify little >>endian by default, as a memory convention >> > Since the default (for load/store) is little endian, and since little > endian makes more sense with SIMD, it should be the default. Is this really a problem ? As far as i remember, the endian flag in the instructions is still present... In the endian threads, there are always people wanting somethings and its contrary. That's why the flag is here. IIRC it's little endian by default. Now, anybody is free to use the endian one wants. Even though i'll be the third to claim that SIMD requires little endian to work properly. But if somebody needs something else, the endian flag is here to fullfill his programming needs. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Sep 12 02:56:29 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pJCC-00026l-01 for ; Thu, 12 Sep 2002 03:55:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 03:55:04 +0200 (CEST) Received: (qmail 19795 invoked by uid 0); 12 Sep 2002 00:45:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 12 Sep 2002 00:45:32 -0000 Received: by moria.seul.org (Postfix) id 7BB4715E7B6; Wed, 11 Sep 2002 20:45:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A95D15E7BA; Wed, 11 Sep 2002 20:45:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 2CF6F15E7B6 for ; Wed, 11 Sep 2002 20:45:31 -0400 (EDT) Received: from f-cpu.org (kdl14-10.n.club-internet.fr [213.44.12.10]) by relay-1v.club-internet.fr (Postfix) with ESMTP id C5B861688; Thu, 12 Sep 2002 02:45:28 +0200 (CEST) Message-ID: <3D7FE63D.3060603@f-cpu.org> Date: Thu, 12 Sep 2002 02:56:29 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new news References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Graham Seaman wrote: >On Wed, 11 Sep 2002, Yann Guidon wrote: > >>Hi, >> >>has anyone seen the news ? >>http://f-cpu.seul.org/daCode/ >> >>It mostly concerns the french people >>because the western Africa is mostly >>french speaking, but the decisions belong >>to this list anyway. >> >> >Where is the backend.rss file on the new site? I'd like to put the >news summary back on opencollector now dacode is running again... :-) > > Unfortunately, when i moderated the news, there was a server warning that said that the rss generation had failed. I don't know what/where/how.... However, it could be possible to copy/paste the text if you want to cover this on OpenCollector.org :-) Damn, i'm so lazy... I (too) wish that the situation will change. Maybe the french team will find a way to organise itself ? >Graham > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Sep 12 05:02:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pMIX-0004Js-01 for ; Thu, 12 Sep 2002 07:13:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 07:13:49 +0200 (CEST) Received: (qmail 21402 invoked by uid 0); 12 Sep 2002 03:05:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 12 Sep 2002 03:05:50 -0000 Received: by moria.seul.org (Postfix) id BAB1F15E7BC; Wed, 11 Sep 2002 23:05:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 876F015E7BF; Wed, 11 Sep 2002 23:05:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 0594E15E7BC for ; Wed, 11 Sep 2002 23:05:49 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-218.jetnet.ab.ca [207.34.60.218]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g8C3677C045240 for ; Wed, 11 Sep 2002 21:06:07 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D8003AD.3040408@jetnet.ab.ca> Date: Wed, 11 Sep 2002 21:02:05 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Memory convention References: <200209112301.02220.cedric.bail@free.Fr> <20020912001848.52501@thrai.stud.uni-hannover.de> <3D7FE633.8070707@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: > Is this really a problem ? As far as i remember, the endian flag in the > instructions is still present... > In the endian threads, there are always people wanting somethings and > its contrary. That's why > the flag is here. IIRC it's little endian by default. > > Now, anybody is free to use the endian one wants. Even though i'll be > the third to claim that > SIMD requires little endian to work properly. Why? Too lazy to find the lastest docs? But if somebody needs > something else, > the endian flag is here to fullfill his programming needs. I asume that the endian flag is for SIMD. One other problem with SIMD is that I asume it is for just operations with simple register indirect addressing. *a=*a op *b;a++;b++; If you need anything else you have to go back to normal processing. This limits the what you can do as you want to have orthagonal processing ability on SIMD. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Sep 12 19:15:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pZc8-0004qb-00 for ; Thu, 12 Sep 2002 21:26:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 21:26:56 +0200 (CEST) Received: (qmail 12256 invoked by uid 0); 12 Sep 2002 12:17:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 12 Sep 2002 12:17:03 -0000 Received: by moria.seul.org (Postfix) id 1A72215E73D; Thu, 12 Sep 2002 08:17:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D85F215E7BF; Thu, 12 Sep 2002 08:17:00 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 6A7BE15E73D for ; Thu, 12 Sep 2002 08:17:00 -0400 (EDT) Received: from club-internet.fr (flashmail-6m.cs.clubint.net [172.16.20.65]) by relay-1m.club-internet.fr (Postfix) with SMTP id 7380716B1; Thu, 12 Sep 2002 14:16:58 +0200 (CEST) Received: from [212.43.214.31] by flashmail-6m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Memory convention Date: Thu, 12 Sep 2002 14:15:58 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 Ben Franchuk wrote : >Yann Guidon wrote: > >> Is this really a problem ? As far as i remember, the endian flag in the= = >> instructions is still present... >> In the endian threads, there are always people wanting somethings and = >> its contrary. That's why >> the flag is here. IIRC it's little endian by default. >> = >> Now, anybody is free to use the endian one wants. Even though i'll be = >> the third to claim that >> SIMD requires little endian to work properly. >Why? Too lazy to find the lastest docs? > But if somebody needs >> something else, >> the endian flag is here to fullfill his programming needs. >I asume that the endian flag is for SIMD. no. The load/store instructions don't care at all about the data format, they only know the width of the register to write. >One other problem with SIMD is that I asume it is for >just operations with simple register indirect addressing. >*a=3D*a op *b;a++;b++; ??? >If you need anything else you have to go back to >normal processing. This limits the what you can do >as you want to have orthagonal processing ability on >SIMD. i'm not sure to understand what you mean. Can you elaborate ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Sep 12 16:51:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pZcC-0004qb-00 for ; Thu, 12 Sep 2002 21:27:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 21:27:00 +0200 (CEST) Received: (qmail 19146 invoked by uid 0); 12 Sep 2002 14:55:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 12 Sep 2002 14:55:27 -0000 Received: by moria.seul.org (Postfix) id 1909615E740; Thu, 12 Sep 2002 10:55:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D73C315E7C2; Thu, 12 Sep 2002 10:55:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 59EB815E740 for ; Thu, 12 Sep 2002 10:55:24 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-205.jetnet.ab.ca [207.34.60.205]) by bach.ccinet.ab.ca (8.12.5/8.12.3) with ESMTP id g8CEti7C074452 for ; Thu, 12 Sep 2002 08:55:45 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3D80A9FC.4030402@jetnet.ab.ca> Date: Thu, 12 Sep 2002 08:51:40 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Memory convention References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N whygee@club-internet.fr wrote: > i'm not sure to understand what you mean. > Can you elaborate ? No, Not until I re-read the DOCS. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Sep 12 13:07:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17pZcE-0004qb-00 for ; Thu, 12 Sep 2002 21:27:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Sep 2002 21:27:02 +0200 (CEST) Received: (qmail 10344 invoked by uid 0); 12 Sep 2002 17:39:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 12 Sep 2002 17:39:00 -0000 Received: by moria.seul.org (Postfix) id 1193015E6F6; Thu, 12 Sep 2002 13:38:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DA9C515E72E; Thu, 12 Sep 2002 13:38:58 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a163.home.uni-hannover.de [130.75.232.163]) by moria.seul.org (Postfix) with ESMTP id 61F1015E6F6 for ; Thu, 12 Sep 2002 13:38:57 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00507; Thu, 12 Sep 2002 13:07:21 +0200 Message-ID: <20020912130721.35680@thrai.stud.uni-hannover.de> Date: Thu, 12 Sep 2002 13:07:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new news References: <3D7E7047.6010809@f-cpu.org> <20020911140213.52046@thrai.stud.uni-hannover.de> <3D7FE62F.5000407@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D7FE62F.5000407@f-cpu.org>; from Yann Guidon on Thu, Sep 12, 2002 at 02:56:15AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Thu, Sep 12, 2002 at 02:56:15AM +0200, Yann Guidon wrote: > >>has anyone seen the news ? > >>http://f-cpu.seul.org/daCode/ > >> > >Haven't looked at it for ages (I only use the board). > > > And even that is not done so often, lately ;-) Oh, I looked at it, but I didn't understand what was going on (the language problem again). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Sep 14 21:56:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qHgJ-0008R8-00 for ; Sat, 14 Sep 2002 20:30:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Sep 2002 20:30:11 +0200 (CEST) Received: (qmail 10229 invoked by uid 0); 14 Sep 2002 13:25:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 14 Sep 2002 13:25:00 -0000 Received: by moria.seul.org (Postfix) id 7FAFA15E748; Sat, 14 Sep 2002 09:24:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A44815E798; Sat, 14 Sep 2002 09:24:59 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id D92C315E748 for ; Sat, 14 Sep 2002 09:24:58 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-152-223.dial.proxad.net [62.147.152.223]) by postfix2-1.free.fr (Postfix) with ESMTP id 6C23A380 for ; Sat, 14 Sep 2002 15:24:32 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: Subject: [f-cpu] dshift, drot ? Date: Sat, 14 Sep 2002 21:56:30 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209142156.30368.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am currently adding the new instruction for shift and rot, and I am asking myself if we have a rotd[l/r] or not (like shiftd[l/r]). I think that Michael can answer to that easily. Cedric PS: Yann, I wait for your part ;-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Sep 14 19:34:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qHgL-0008R8-01 for ; Sat, 14 Sep 2002 20:30:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Sep 2002 20:30:13 +0200 (CEST) Received: (qmail 23930 invoked by uid 0); 14 Sep 2002 17:23:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Sep 2002 17:23:50 -0000 Received: by moria.seul.org (Postfix) id 5D8D715E74B; Sat, 14 Sep 2002 13:23:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2CCB915E74F; Sat, 14 Sep 2002 13:23:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id DC74115E74B for ; Sat, 14 Sep 2002 13:23:48 -0400 (EDT) Received: from f-cpu.org (kll1-110.n.club-internet.fr [213.44.91.110]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B780C16DA for ; Sat, 14 Sep 2002 19:23:46 +0200 (CEST) Message-ID: <3D83733B.4040105@f-cpu.org> Date: Sat, 14 Sep 2002 19:34:51 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] dshift, drot ? References: <200209142156.30368.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: >Hi, > >PS: Yann, I wait for your part ;-) > grrrrr..... if i had time ..... I often forget about it. Can we meet ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Sep 15 01:17:41 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qVkA-00017L-01 for ; Sun, 15 Sep 2002 11:31:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 15 Sep 2002 11:31:06 +0200 (CEST) Received: (qmail 28921 invoked by uid 0); 14 Sep 2002 23:17:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 14 Sep 2002 23:17:46 -0000 Received: by moria.seul.org (Postfix) id 6E94615E74E; Sat, 14 Sep 2002 19:17:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 36BA615E751; Sat, 14 Sep 2002 19:17:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a066.home.uni-hannover.de [130.75.232.66]) by moria.seul.org (Postfix) with ESMTP id 8D85E15E74E for ; Sat, 14 Sep 2002 19:17:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02163; Sun, 15 Sep 2002 01:17:41 +0200 Message-ID: <20020915011741.46467@thrai.stud.uni-hannover.de> Date: Sun, 15 Sep 2002 01:17:41 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] dshift, drot ? References: <200209142156.30368.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200209142156.30368.cedric.bail@free.fr>; from cedric on Sat, Sep 14, 2002 at 09:56:30PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Sep 14, 2002 at 09:56:30PM +0200, cedric wrote: > I am currently adding the new instruction for shift and rot, and I am asking > myself if we have a rotd[l/r] or not (like shiftd[l/r]). I think that Michael > can answer to that easily. No, there is no drot[lr]. That wouldn't make sense - what is the upper word supposed to contain? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Sep 15 18:18:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qXbf-0002d9-00 for ; Sun, 15 Sep 2002 13:30:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 15 Sep 2002 13:30:27 +0200 (CEST) Received: (qmail 16075 invoked by uid 0); 15 Sep 2002 09:46:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 15 Sep 2002 09:46:09 -0000 Received: by moria.seul.org (Postfix) id 7F6AC15E75A; Sun, 15 Sep 2002 05:46:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3D34015E760; Sun, 15 Sep 2002 05:46:07 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id B80F415E75A for ; Sun, 15 Sep 2002 05:46:06 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-155-98.dial.proxad.net [62.147.155.98]) by postfix2-2.free.fr (Postfix) with ESMTP id 5F3C05F95E for ; Sun, 15 Sep 2002 11:46:05 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] dshift, drot ? Date: Sun, 15 Sep 2002 18:18:27 +0200 X-Mailer: KMail [version 1.4] References: <200209142156.30368.cedric.bail@free.fr> <20020915011741.46467@thrai.stud.uni-hannover.de> In-Reply-To: <20020915011741.46467@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209151818.27899.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Le Dimanche 15 Septembre 2002 01:17, Michael Riepe a écrit : > On Sat, Sep 14, 2002 at 09:56:30PM +0200, cedric wrote: > > I am currently adding the new instruction for shift and rot, and I am > > asking myself if we have a rotd[l/r] or not (like shiftd[l/r]). I think > > that Michael can answer to that easily. > > No, there is no drot[lr]. That wouldn't make sense - what is the upper > word supposed to contain? I don't know, but perhaps something like that : r1 = r2 <@ r3 r1^1 = r2 @> r3 But in fact it's not really the same idea as the shiftd, so no drot[lr]. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Sep 15 18:29:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qXbf-0002d9-01 for ; Sun, 15 Sep 2002 13:30:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 15 Sep 2002 13:30:27 +0200 (CEST) Received: (qmail 28379 invoked by uid 0); 15 Sep 2002 09:56:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 15 Sep 2002 09:56:54 -0000 Received: by moria.seul.org (Postfix) id 0D17215E75A; Sun, 15 Sep 2002 05:56:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DB06E15E760; Sun, 15 Sep 2002 05:56:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by moria.seul.org (Postfix) with ESMTP id 99B5D15E75A for ; Sun, 15 Sep 2002 05:56:52 -0400 (EDT) Received: from gaia (nas-cbv-7-62-147-155-98.dial.proxad.net [62.147.155.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 448C45BCD for ; Sun, 15 Sep 2002 11:56:51 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: cedric To: Subject: [f-cpu] special register map Date: Sun, 15 Sep 2002 18:29:13 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209151829.13940.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, I am currently starting adding a map for special register and if somebody can clarify some of them it would be nice. Here is the list : MAX_SIZE SIZE_0 SIZE_1 SIZE_2 SIZE_3 MAX_CHUNK_SIZE Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Sep 15 17:13:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17qbTP-0005Dd-00 for ; Sun, 15 Sep 2002 17:38:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 15 Sep 2002 17:38:11 +0200 (CEST) Received: (qmail 19812 invoked by uid 0); 15 Sep 2002 15:02:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 15 Sep 2002 15:02:25 -0000 Received: by moria.seul.org (Postfix) id 5338C15E75E; Sun, 15 Sep 2002 11:02:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F1F3A15E761; Sun, 15 Sep 2002 11:02:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5BBA815E75E for ; Sun, 15 Sep 2002 11:02:21 -0400 (EDT) Received: from f-cpu.org (kll1-215.n.club-internet.fr [213.44.91.215]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 094C41690 for ; Sun, 15 Sep 2002 17:02:16 +0200 (CEST) Message-ID: <3D84A395.80403@f-cpu.org> Date: Sun, 15 Sep 2002 17:13:25 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] special register map References: <200209151829.13940.cedric.bail@free.fr> Content-Type: multipart/mixed; boundary="------------070305010607010908040000" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------070305010607010908040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi, cedric wrote: >Hi, > > I am currently starting adding a map for special register and if somebody can >clarify some of them it would be nice. Here is the list : > MAX_SIZE > SIZE_0 > SIZE_1 > SIZE_2 > SIZE_3 > MAX_CHUNK_SIZE > >Cedric > The SR map is, like the opcode map, defined only by symbolic addresses before F-CPU v1. However, the map will evolve a lot more than the opcode map in the future, so the files must always use the symbolic names, not their numeric value. These names and some preliminary values are defined in the file f-cpu/configuration/f-cpu_config.vhdl.in in the snapshots. I have attached it to this mail. The SR map in not "cleanly" managed yet. The corresponding unit is not even written. More work is needed to take the SR map out of the "general" configuration files, maybe even with a tool that creates a configuration file according to the user's needs. In case one is lazy to read the vhdl.in file, here are some indications : - MAX_SIZE is the number of bytes per register. [ however the file is unclear : it seems to indicate that it is the log2 of the number of bytes. i would rather use this second version but we'll have to see what this involves in SW, because the natural value is used in the source. ] - SIZE_0, SIZE_1, SIZE_2, SIZE_3 are the widths (in bytes) of the chunks associated to the size flag in the instructions. for example when add.0 is performed, the value associated to the size flag is 8 bits (SIZE_0 is 1 byte by default). This width can be reprogrammed when more than 64 bits per register is available, so it can mean 128 bits or 512 bits if necessary. - MAX_CHUNK_SIZE is the maximum size of a single chunk. Currently is is hardwired to 8 bytes/register. These SR may be hardwired or not, depending on the version. Usually, MAX_SIZE and MAX_CHUNK_SIZE are hardwired (unless there is some instruction emulation). The application reads MAX_SIZE to determine if more than 64 bits per register are available, and if needed, the application modifies SIZE_0-3 to the required widths. These are "private" registers which, when modifiable, are saved across context switches. The format is obvously a problem, the sources indicate that this is the raw number of bytes but the logarithm would be more useful in practice. The values of SIZE_0-3 could fit in 16 bits if the widths are stored in logarithmic way : each 4-bit parts could represent widths from 8 to 256K bits, more than enough for future CPU generations. This packed 16-bit word is stored in the CMB for the context switches. Another point is that these registers are mainly used during program setup, when loop counts and data widths are computed. Using raw byte counts, the application has to divide the iteration counts but using the fact that register width is always a power of two, a simple shift is enough. Computing the log of a value is not very easy, but computing the exponent is straight-foward (a simple shift). For example, take a program that loops over an array of 256 bytes : using SIMD and the F-CPU "abstract" model, the loop number is computed with : L = 256 >> MAX_SIZE. If L is zero, then a SIZE_x must be programmed to manage 256 bytes and L=1. Then, the loop can run L times and each data is treated using the size flag corresponding to SIZE_x. Obviously, there is a problem but i have no time left to modify the sources. I would like to meet cédric to speak about it with him. YG --------------070305010607010908040000 Content-Type: text/plain; name="f-cpu_config.vhdl.in" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="f-cpu_config.vhdl.in" __FILE_HEADER__ -- source : f-cpu/configuration/f-cpu_config.vhdl.in -- destination : f-cpu/vhdl/configuration/f-cpu_config.vhdl -- (c) Yann GUIDON, oct. 21, 2000 -- -- v0.2 : Michael Riepe changed F_RANGE -- v0.3 : YG specified the user-modifiable constants + GPL -- v0.4 : MR proposed LOGMAXSIZE, YG added the ROP2 constants. -- v0.5 : nov. 17, 2000, YG added SR_IRQ_BASE, SR_TRAP_BASE, -- SR_SYSCALL_BASE, SR_URL etc. -- v0.6 : nov. 26, 2000, YG moved some SR stuff to /VHDL/EU_sr -- v0.7 : dec. 31, 2000, YG added SR_MAX_CHUNK_SIZE and SR_TLBMISS_BASE -- v0.8 : aug. 19, 2001, YG hacked for m4 preprocessing. -- run f-cpu/configure.sh to update this file. -- v0.9 : aug. 28, 2001 : YG + MR modified some stuffs. -- MR hinted the "eval(radix)" trick, status is satisfying. -- v0.10 :dec. 31, 2001 : restored MAX_CHUNK_SIZE, SR_TLBMISS_BASE -- and SR_LAST_SR which disapeared during the transition to m4 format. -- v0.11 : june 2002 : adding a new type for the register addresses. -- -- This package defines the "characteristic widths" of -- the internal units. Please respect the restrictions. -- -- #### The SR code should be moved to another file ! #### -- -- ************************************************************** -- WARNING : All the user-modifiable values are defined in the -- f-cpu/configuration/f-cpu_user.m4 file. -- ************************************************************** -- -- * LOGMAXSIZE : Log2 of the Size of the registers in bytes. -- Can be any integer above or equal to 2. 2 corresponds to -- a 32-bit implementation, 3 corresponds to a 64-bit version. -- This is the most important parameter, the first with -- which one can play. Be careful anyway. The 32-bit version will -- not work yet. -- -- * L1LogLines : Log2 of the NumBer of cache Lines (MUST be EVEN) -- This parameter determines how many L1 cache lines are implemented. -- It must be >=4 and _even_ because of the particular LRU mechanism -- used for this prototype. Allowed values are 4, 6 or 8 (that is : -- 16, 64 or 256 lines, or 512 bytes, 2KB or 8KB). More would correspond -- to a L2 cache... but are possible if you have enough ressources. -- -- * L1ABwidth :Address Bus width, in 32-byte chuncks (32+5=128GB) -- This determines the width of the address comparator of every L1 -- cache line. Be careful, too many bits might require a LOT of ressources. -- A reasonable value for a small design would be 16 (2MB of adressable -- physical memory), adapt as required. Warning : this parameter -- also determines how many address bits are physically implemented. -- LIBRARY ieee; USE ieee.std_logic_1164.ALL; package FCPU_config is ------------------------------------------------------ -- Most important F-CPU constants : ------------------------------------------------------ -- Number >=2, 3 corresponds to 64-bit registers constant LOGMAXSIZE : natural := __DEF_LOGMAXSIZE; -- defined in f-cpu/configuration/f-cpu_user.m4 -- Size of the registers in bytes constant MAXSIZE : natural := 2**LOGMAXSIZE; -- Size of the registers in bits. constant UMAX : natural := MAXSIZE * 8; -- Range of a register width declaration. subtype F_RANGE is natural range UMAX-1 downto 0 ; -- shortcut for a very common declaration. subtype F_VECTOR is std_ulogic_vector(F_RANGE) ; -- MAX_CHUNK_SIZE in bits. This should not change. constant MAX_CHUNK_SIZE : natural := 64 ; ------------------------------------------------------ -- Definition of a register address : ------------------------------------------------------ -- defines a 6-wire address : subtype t_reg is std_ulogic_vector(5 downto 0); -- moved from f-cpu/vhdl/scheduler/scheduler_definitions.vhdl -- defines the integer value thereof : subtype reg_number is natural range 0 to 63; ------------------------------------------------------ -- Some architectural constants, bound to FC0 only : ------------------------------------------------------ ------------------------------------------------------ -- L1 Caches (split instructions and data) ------------------------------------------------------ -- Data Bus width, or width of each cache line (32 bytes) constant L1DBwidth : natural := 256 ; -- Address Bus width, in 32-byte chuncks (32+5=128GB) constant L1ABwidth : natural := __DEF_L1ABwidth ; -- Log2 of the NumBer of cache Lines (MUST be EVEN) -- (small number for the first attempts) constant L1LogLines : natural := __DEF_L1LogLines ; -- NumBer of cache Lines (2**L1LogLines) constant L1NBlines : natural := 2**L1LogLines ; ------------------------------------------------------ -- The Special Registers : (adapted from SR.h) -- -- (please check f-cpu/configuration/f-cpu_sr.m4 !) -- -- What the user should modify when implementing the core : -- * SR_NUMBERS_val should be updated when the -- number of implemented SR changes. -- * SR_FAMILY_val specifies the type of core (FC0, FC1 etc). -- This is meant to be used for selecting particular code -- sections that are optimized for certain cores. -- * SR_STEPPING_val specifies the mask revision, for example. -- * SR_URL_val contains the Internet URL where the source, -- software and documentation are stored (64 char max.) -- -- DO NOT MODIFY the other constants unless the specifications -- change. New SRs will appear soon. Stay tuned. ------------------------------------------------------ -- last SR : constant SR_LAST_SR : natural := 27; -- number of SRs that are implemented in this model constant SR_NUMBERS : natural := 0; constant SR_NUMBERS_val : natural := SR_LAST_SR; -- F-CPU core number. remark : 0xFC0 = 4032d :-) constant SR_FAMILY : natural := 1; constant SR_FAMILY_val : natural := __DEF_SR_FAMILY_val; -- revision/implementation constant SR_STEPPING : natural := 2; constant SR_STEPPING_val : natural := __DEF_SR_STEPPING_val; -- in bytes, a power of two >= 3 constant SR_MAX_SIZE : natural := 3; constant SR_MAX_SIZE_val : natural := MAXSIZE; -- Size attribute 0, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_0 : natural := 4; constant SR_SIZE_0_val : natural := 1; -- Size attribute 1, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_1 : natural := 5; constant SR_SIZE_1_val : natural := 2; -- Size attribute 2, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_2 : natural := 6; constant SR_SIZE_2_val : natural := 4; -- Size attribute 3, hardwired if SR_MAX_SIZE <= 8 constant SR_SIZE_3 : natural := 7; constant SR_SIZE_3_val : natural := 8; -- SIMD chunck size, hardwired. constant SR_MAX_CHUNK_SIZE : natural := 8; constant SR_MAX_CHUNK_SIZE_val : natural := MAX_CHUNK_SIZE/8; -- R/W, Value is dynamic, incremented every cycle. constant SR_CYCLE : natural := 9; -- Protected, R/W, Controls the paged memory. constant SR_PAGING : natural := 10; -- Protected, R/W, general status and mode bits which control other enable bits. constant SR_CONTROL : natural := 11; -- IRQ, TRAP and SYSCALL jump tables : all are R/W in protected mode - only. constant SR_IRQ_BASE : natural := 12; -- For the hardware interrupt requests constant SR_IRQ_SIZE : natural := 13; constant SR_TRAP_BASE : natural := 14; -- faults and system errors constant SR_TRAP_SIZE : natural := 15; constant SR_SYSCALL_BASE : natural := 16; -- OS system call constant SR_SYSCALL_SIZE : natural := 17; constant SR_TLBMISS_BASE : natural := 18; -- TLB miss trap -- The URL registers must be modified to point to the manual, sources, patches etc. -- The registers are hardwired, format is ASCII and padded with 0s. constant SR_URL : natural := 19; -- 64 characters max. for a 64-bit version, 32 chars for a 32-bit version... constant SR_URL_size : natural := 8; constant SR_URL_val : string := __DEF_SR_URL_val; -- defined in f-cpu/configuration/f-cpu_user.m4 ------------------------------------------------------- -- The ROP2 unit : these constants specify the -- correspondance between the binary code and the actual -- operation. These data are copied here for convenience -- only, for example if you want to make an assembler in -- VHDL. Check the file ROP2.vhdl for more informations. -------------------------------------------------------- constant ROP2_DIRECT_MODE : std_ulogic_vector(1 downto 0) := "m4_eval(__DEF_ROP2_DIRECT_MODE,2,2)"; constant ROP2_AND_MODE : std_ulogic_vector(1 downto 0) := "m4_eval(__DEF_ROP2_AND_MODE,2,2)"; constant ROP2_OR_MODE : std_ulogic_vector(1 downto 0) := "m4_eval(__DEF_ROP2_OR_MODE,2,2)"; constant ROP2_MUX_MODE : std_ulogic_vector(1 downto 0) := "m4_eval(__DEF_ROP2_MUX_MODE,2,2)"; constant ROP2_AND : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_AND,2,3)"; constant ROP2_ANDN : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_ANDN,2,3)"; constant ROP2_XOR : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_XOR,2,3)"; constant ROP2_OR : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_OR,2,3)"; constant ROP2_NOR : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_NOR,2,3)"; constant ROP2_XNOR : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_XNOR,2,3)"; constant ROP2_ORN : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_ORN,2,3)"; constant ROP2_NAND : std_ulogic_vector(2 downto 0) := "m4_eval(__DEF_FUNCTION_NAND,2,3)"; constant ROP2_VALUE_AND : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_AND,2,4)"; constant ROP2_VALUE_ANDN : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_ANDN,2,4)"; constant ROP2_VALUE_XOR : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_XOR,2,4)"; constant ROP2_VALUE_OR : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_OR,2,4)"; constant ROP2_VALUE_NOR : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_NOR,2,4)"; constant ROP2_VALUE_XNOR : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_XNOR,2,4)"; constant ROP2_VALUE_ORN : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_ORN,2,4)"; constant ROP2_VALUE_NAND : std_ulogic_vector(3 downto 0) := "m4_eval(__DEF_FUNCTION_VALUE_NAND,2,4)"; end FCPU_config; package body FCPU_config is -- The use of the ilog functions is not recommended inside -- the synthesisable processes, they are provided for -- convenience only. Usually, the logarithm is provided -- and exponentiation is performed on it (it's much simpler). -- integer logarithm (rounded up) [MR version] function ilog (x : natural; base : natural := 2) return natural is variable y : natural := 1; begin while x > base ** y loop y := y + 1; end loop; return y; end ilog; -- integer logarithm (rounded up) [YG version] -- i wonder if there is an off-by-1 error... ? function ilog2 (x : natural) return natural is variable y, z : natural := 1; begin while x > z loop y := y + 1; z := z + z; -- you can notice the "little" enhancement :o) end loop; return y; end ilog2; ------------------------------------------------------ -- Some useful wrappers or functions could be included -- here if they are necessary for rest of the project. ------------------------------------------------------ end FCPU_config; --------------070305010607010908040000-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Sep 17 15:51:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17rIxj-0001QX-00 for ; Tue, 17 Sep 2002 16:04:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 17 Sep 2002 16:04:23 +0200 (CEST) Received: (qmail 10994 invoked by uid 0); 17 Sep 2002 13:51:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 17 Sep 2002 13:51:44 -0000 Received: by moria.seul.org (Postfix) id 32C5115E728; Tue, 17 Sep 2002 09:51:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E145F15E7BE; Tue, 17 Sep 2002 09:51:40 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 13B1F15E728 for ; Tue, 17 Sep 2002 09:51:38 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix3-2.free.fr (Postfix) with ESMTP id 74CFF17EA6 for ; Tue, 17 Sep 2002 15:51:37 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 4D1CE582C9; Tue, 17 Sep 2002 15:51:37 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] special register map Message-ID: <1032270696.3d8733682b452@imp.free.fr> Date: Tue, 17 Sep 2002 15:51:36 +0200 (MEST) From: Cedric BAIL References: <200209151829.13940.cedric.bail@free.fr> <3D84A395.80403@f-cpu.org> In-Reply-To: <3D84A395.80403@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 80.11.98.140 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > > I am currently starting adding a map for special register and if > somebody can > >clarify some of them it would be nice. Here is the list : > > MAX_SIZE > > SIZE_0 > > SIZE_1 > > SIZE_2 > > SIZE_3 > > MAX_CHUNK_SIZE > > > >Cedric > The SR map is, like the opcode map, defined only by symbolic addresses > before F-CPU v1. However, the map will evolve a lot more than the > opcode map in the future, so the files must always use the symbolic > names, not their numeric value. Of course ;-) > These names and some preliminary values are defined > in the file f-cpu/configuration/f-cpu_config.vhdl.in in the snapshots. > I have attached it to this mail. I read it, but from the discussion we have on this mailing-list a lot of them must be added. > Obviously, there is a problem but i have no time left to modify the > sources. > I would like to meet cédric to speak about it with him. Sorry, I will not be in Paris this week, perhaps next week. I think I will start to read your snapshot to extract what we must put in the manual about ROP2. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From vivianonye@excite.com Wed Sep 18 22:46:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17sM77-0000E4-00 for ; Fri, 20 Sep 2002 13:38:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Sep 2002 13:38:25 +0200 (CEST) Received: (qmail 18370 invoked by uid 0); 20 Sep 2002 08:55:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 20 Sep 2002 08:55:26 -0000 Received: by moria.seul.org (Postfix) id F04FA15E77D; Fri, 20 Sep 2002 04:55:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C36D915E793; Fri, 20 Sep 2002 04:55:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 3056915E77D for ; Fri, 20 Sep 2002 04:55:24 -0400 (EDT) Received: from 2mails2739.com (host-217-146-2-126.warsun.com [217.146.2.126] (may be forged)) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id g8K8tLn05804 for ; Fri, 20 Sep 2002 04:55:22 -0400 Message-Id: <200209200855.g8K8tLn05804@belegost.mit.edu> From: "PRINCESS VIVIAN ONYEKWERE" Date: Wed, 18 Sep 2002 14:46:54 -0600 Subject: [f-cpu] X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N INTRODUTION I am Princess Vivian Onyekwere=2C daughter of Chief Oti Onyekwer=2C the king of Ogoni Kingdom=2E Iam 25 Years old and a graduate of Mass Communication=2E My Father was the king of Ogoni Kingdom the highest oil Producing area in Nigeria=2E He was in charge of Reviving royalties from the multi-national oil Companies and government on behalf of the oil Producing communities in Nigeria=2E After the hanging of The Ogoni Nine =289=29 including Ken Saro Wiwa by the late Dictator General Sani Abacha=2C my father suffered Stroke and died November 15th lastyear=2E But before his death=2C he called me and told me he has twenty Three Million Five Hundred and Sixty Thousand Dollars=28USD23=2C560=2C000=2E00=29 cash in his Possession=2C Specially deposited in a Security company here=2E He advised me not to tell anybody except my mother who is the last wife of the =288=29 eight wives that he married=2E My mother did not bear any male child for him=2E Which implies that all my fathers' properties=2C companies' e=2Et=2Ec=2C we have! no share in them because my mother has No male child according to African Tradition=2E My father there fore secretly gave me all the relevant Documents of the said money=2C and told me that I should Use this money with my mother and my younger sisters Because he knows that traditionally=2C if he dies we Cannot get anything=2C as inheritance=2E He importantly Advised me that I should seek foreign assistance=3Fs and that I should not invest this money here in Nigeria Because of his other wives and male children who happen to be my elders=2E I am soliciting for your immediate assistance to get a bungalow for us=2C wherein Will live with my mother and two younger sisters and Further advise me where and how I will invest the balance money overseas=2C possibly on products of your Company and other profitable ventures=2E I believe that by the special grace of God=2C you will help us move this money out of Nigeria to any country of your Choice where we can invest this money judiciously with you=2E You are! entitled to a reasonable part of this Money based on our agreement=2C and God will bless you as you help us=2E Please reply through my e-mail Looking Forward to hear from you as soon as possible=2E Best regard=2C Top of Form 1 =09=09 Bottom of Form 1 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From softcore@web.de Fri Sep 20 11:22:45 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17sM77-0000E4-01 for ; Fri, 20 Sep 2002 13:38:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Sep 2002 13:38:25 +0200 (CEST) Received: (qmail 5001 invoked by uid 0); 20 Sep 2002 09:22:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 20 Sep 2002 09:22:12 -0000 Received: by moria.seul.org (Postfix) id CC09B15E797; Fri, 20 Sep 2002 05:22:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADF0215E7A0; Fri, 20 Sep 2002 05:22:10 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by moria.seul.org (Postfix) with ESMTP id 3B27F15E797 for ; Fri, 20 Sep 2002 05:22:10 -0400 (EDT) Received: from [212.250.16.253] (helo=alexhertz01) by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2) id 17sJzF-0002DN-00 for f-cpu@seul.org; Fri, 20 Sep 2002 11:22:09 +0200 From: "Alex Herz" To: Subject: RE: [f-cpu] Date: Fri, 20 Sep 2002 10:22:45 +0100 Message-ID: <000801c26087$486d0170$3814a8c0@lhdomain.lionhead.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200209200855.g8K8tLn05804@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On the behalf King O. B. Laden. Dear princess, my kingdom has been wiped by strong enemies. My followers have been suffering. But I have made the ultimate plan to protect my country from further mischief. And as luck comes to play this is an incredible great investment opportunitity. To execute our holy mission we happen to need exactely (USD23,560,000.00) To buy a very dedicated device of mass communication. Using this incredible device we can persuade thousands of ppl within an area of many square miles of our superiority within a couple of seconds. So if you'd like to help and participate using the device to send our holy message pls put the money in a big black bag and drop it somewhere near afghanistan (certain circumstances don't allow me to be to exact about my current location). My followers will pick it up and hopefully they will not know what to do with it and bring it to me. Your sincerely, O. B. L. King of a big mess. -----Original Message----- From: owner-f-cpu@seul.org [mailto:owner-f-cpu@seul.org] On Behalf Of PRINCESS VIVIAN ONYEKWERE Sent: 18 September 2002 21:47 To: undisclosed-recipients: Subject: [f-cpu] INTRODUTION I am Princess Vivian Onyekwere, daughter of Chief Oti Onyekwer, the king of Ogoni Kingdom. Iam 25 Years old and a graduate of Mass Communication. My Father was the king of Ogoni Kingdom the highest oil Producing area in Nigeria. He was in charge of Reviving royalties from the multi-national oil Companies and government on behalf of the oil Producing communities in Nigeria. After the hanging of The Ogoni Nine (9) including Ken Saro Wiwa by the late Dictator General Sani Abacha, my father suffered Stroke and died November 15th lastyear. But before his death, he called me and told me he has twenty Three Million Five Hundred and Sixty Thousand Dollars(USD23,560,000.00) cash in his Possession, Specially deposited in a Security company here. He advised me not to tell anybody except my mother who is the last wife of the (8) eight wives that he married. My mother did not bear any male child for him. Which implies that all my fathers' properties, companies' e.t.c, we have! no share in them because my mother has No male child according to African Tradition. My father there fore secretly gave me all the relevant Documents of the said money, and told me that I should Use this money with my mother and my younger sisters Because he knows that traditionally, if he dies we Cannot get anything, as inheritance. He importantly Advised me that I should seek foreign assistance?s and that I should not invest this money here in Nigeria Because of his other wives and male children who happen to be my elders. I am soliciting for your immediate assistance to get a bungalow for us, wherein Will live with my mother and two younger sisters and Further advise me where and how I will invest the balance money overseas, possibly on products of your Company and other profitable ventures. I believe that by the special grace of God, you will help us move this money out of Nigeria to any country of your Choice where we can invest this money judiciously with you. You are! entitled to a reasonable part of this Money based on our agreement, and God will bless you as you help us. Please reply through my e-mail Looking Forward to hear from you as soon as possible. Best regard, Top of Form 1 Bottom of Form 1 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From vivianonye@excite.com Thu Sep 19 00:25:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17sM79-0000E4-00 for ; Fri, 20 Sep 2002 13:38:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Sep 2002 13:38:27 +0200 (CEST) Received: (qmail 4343 invoked by uid 0); 20 Sep 2002 10:33:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 20 Sep 2002 10:33:53 -0000 Received: by moria.seul.org (Postfix) id 5A10F15E79F; Fri, 20 Sep 2002 06:33:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1AC5315E7A3; Fri, 20 Sep 2002 06:33:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 77B6915E79F for ; Fri, 20 Sep 2002 06:33:51 -0400 (EDT) Received: from ab17c1160.com (host-217-146-2-126.warsun.com [217.146.2.126] (may be forged)) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id g8KAXnn06086 for ; Fri, 20 Sep 2002 06:33:50 -0400 Message-Id: <200209201033.g8KAXnn06086@belegost.mit.edu> From: "VIVIAN ONYEKWERE" Date: Wed, 18 Sep 2002 16:25:22 -0600 Subject: [f-cpu] X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ATTN=3A INTRODUTION I am Princess Vivian Onyekwere=2C daughter of Chief Oti Onyekwer=2C the king of Ogoni Kingdom=2E Iam 25 Years old and a graduate of Mass Communication=2E My Father was the king of Ogoni Kingdom the highest oil Producing area in Nigeria=2E He was in charge of Reviving royalties from the multi-national oil Companies and government on behalf of the oil Producing communities in Nigeria=2E After the hanging of The Ogoni Nine =289=29 including Ken Saro Wiwa by the late Dictator General Sani Abacha=2C my father suffered Stroke and died November 15th lastyear=2E But before his death=2C he called me and told me he has twenty Three Million Five Hundred and Sixty Thousand Dollars=28USD23=2C560=2C000=2E00=29 cash in his Possession=2C Specially deposited in a Security company here=2E He advised me not to tell anybody except my mother who is the last wife of the =288=29 eight wives that he married=2E My mother did not bear any male child for him=2E Which implies that a! ll my fathers' properties=2C companies' e=2Et=2Ec=2C we have no share in them because my mother has No male child according to African Tradition=2E My father there fore secretly gave me all the relevant Documents of the said money=2C and told me that I should Use this money with my mother and my younger sisters Because he knows that traditionally=2C if he dies we Cannot get anything=2C as inheritance=2E He importantly Advised me that I should seek foreign assistance=92s and that I should not invest this money here in Nigeria Because of his other wives and male children who happen to be my elders=2E I am soliciting for your immediate assistance to get a bungalow for us=2C wherein Will live with my mother and two younger sisters and Further advise me where and how I will invest the balance money overseas=2C possibly on products of your Company and other profitable ventures=2E I believe that by the special grace of God=2C you will help us move this money out of Nigeria to any c! ountry of your Choice where we can invest this money judiciously with you=2E You are entitled to a reasonable part of this Money based on our agreement=2C and God will bless you as you help us=2E Please reply through my e-mail Looking Forward to hear from you as soon as possible=2E Best regard=2C ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jem486749@yahoo.com Mon Sep 30 11:11:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17wFEz-0000Ew-00 for ; Tue, 01 Oct 2002 07:06:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 01 Oct 2002 07:06:37 +0200 (CEST) Received: (qmail 28891 invoked by uid 0); 30 Sep 2002 14:45:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 30 Sep 2002 14:45:38 -0000 Received: by moria.seul.org (Postfix) id 4223215E740; Mon, 30 Sep 2002 10:45:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08F9415E8BD; Mon, 30 Sep 2002 10:45:37 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mailman.xlresponder.com (mailman.xlresponder.com [217.18.64.76]) by moria.seul.org (Postfix) with ESMTP id 21A5615E740 for ; Mon, 30 Sep 2002 10:45:36 -0400 (EDT) Received: (qmail 39259 invoked by uid 10001); 30 Sep 2002 09:11:14 -0000 Date: 30 Sep 2002 09:11:14 -0000 Message-ID: <20020930091114.39258.qmail@mailman.xlresponder.com> To: f-cpu@seul.org From: jem486749@yahoo.com Content-Type: text/plain; charset=us-ascii Subject: [f-cpu] Want a Big Penis? X-Header: Reply-To: jem486749@yahoo.com X-Loop-Prevention: 1 Size DOES Matter!! You're girlfriend tells you that she doesn't care about your size(penis)? Scientific studies show that there is a significant relationship between the intensiveness of women's orgasm and the penis size. Ged a bigger penis with this doctor-approved natural penis enlargement pill. If you don't see any effect, you'll get 100% money back. Why wait? The result is 100% guaranteed. Find out more at http://www.albionmedical.com/pt=truedreammaker2/ Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Click on the link below to remove yourself http://www.xlresponder.com/cgi-bin/varpro/r.cgi?id=dreammaker5&a=f-cpu@seul.org AOL Users Remove Me ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mmeyer@nhbb.com Tue Oct 1 22:25:26 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17wUnw-0003Qk-00 for ; Tue, 01 Oct 2002 23:43:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 01 Oct 2002 23:43:44 +0200 (CEST) Received: (qmail 12998 invoked by uid 0); 1 Oct 2002 20:27:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 1 Oct 2002 20:27:26 -0000 Received: by moria.seul.org (Postfix) id 0E49415E90B; Tue, 1 Oct 2002 16:27:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7916E15E90C; Tue, 1 Oct 2002 16:27:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from ppb012.nhbb.com (ppb012.nhbb.com [64.214.75.196]) by moria.seul.org (Postfix) with ESMTP id 8B6CD15E909; Tue, 1 Oct 2002 16:27:21 -0400 (EDT) Subject: [f-cpu] Re: VERY URGENT AND CONFIDENTIAL. To: "" joseph titus " , "info" , "mediarelations" , "fraud.alert" , "419.fcd" <419.fcd@usss.treas.gov>, "wafl" , "modules" , "f-cpu" , "owner-f-cpu" , "p_wellskat2" Cc: "abuse" , "abuse" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "MIKE MEYER" Date: Tue, 1 Oct 2002 13:25:26 -0700 X-MIMETrack: Serialize by Router on MAILPB01/NHBBMAIL(Release 5.0.8 |June 18, 2001) at 10/01/2002 04:30:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Joseph, Oscar or Kato What is your true name? Are all these other letters yours? 18 Independence Close, Johannesburg, South Africa. REPLY ME IN THIS PRVITA E- MAIL ADDRESS VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from = a in Africa. I want to ask you to kindly look for a reliable and............. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 18 Independence Close, Johannesburg, South Africa. REPLY ME WITH THIS PRVITA ADDRESS VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from = a in Africa. I want to ask you to kindly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new ......... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D mots cl=E9s: auditor kato wells, Money Transfer, Johannesburg, South Af= rica, Mr.Eshed.B.Willey titre: "Money Transfer" email: p_wellskat2@weedmail.com message: 18 Independence Close, Johannesburg, South Africa. VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from a in Africa. I want to ask you to kindly look for a reliable and honest person who w= ill be capable and fit to provide either an existing bank account or to set= up a new bank account immediately to receive this money, though an empty b= ank account could serve this purpose as long as you will remain honest to m= e till the end of this important business trusting in you and believing i= n God that you will never let me down either now or in time to come. I am Prince Kato Wells.the external auditor of a Bank. .................................................... You are a stupid man. = =20 "joseph titus" = =20 cc: = =20 Subject: VERY URGENT AND= CONFIDENTIAL. =20 09/25/2002 09:42 = =20 PM = =20 = =20 = =20 Johannesburg, South Africa. VERY URGENT AND CONFIDENTIAL. We want to transfer to overseas the sum of One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00) from = a in Africa. I want to ask you to kindly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new bank account immediately to receive this money, though an empty bank account could serve this purpose as long as you will remain honest to me till the end of this important business trusting in you and believing in God that you will never let me down either now or in time to come. I am Oscar Cereal.the external auditor of a Bank.During the course of o= ur auditing,I discovered a floating fund in an account opened in the bank= in 1990 and since 1993 nobody has operated on this account again.After going through some old files in the records, I discovered that the owner of the accou= nt died without a "Heir apparent to the throne" hence the money is floating and= if I do not remit this money out urgently it will be forfeited for nothing. The owner of this account who is Mr.Eshed.B.Willey, a foreigner and an industrialist died, since 1990,until now no other person(s) knows about this account or could give any documentary evidence concerning this account. As such this account has no other beneficiary and my investigation proved to me as well that Eshed.B.Willey until his death was the manager Oriental Diamond Company,in South Africa. However, if you are interested in this business we will start the first money transfer with Forty Two Million U.S.Dollars(U.S.$42,000,000.00) upon successful transaction without any disappointment from you. We shall also re-apply for the payment of the remaining amount to your account. While the total amount involved is One hundred and Forty Two Million United States Dollars (U.S.$142,000,000.00)only. I would want us to make a first transfer of [Forty Two Million United States Dollar.(U.S.$42,000,000.00)from this money into a safe foreigners account abroad before the rest. I am only contacting you as a foreigner because this money can not be approved to a local account, without valid international foreign "Agreement", but could only be approved to any foreigner with valid international credentials: passport or drivers license and foreign account because this sum is in U.S. dollars and the former owner of the account Mr.Eshed.B.Willey is a foreigner too, thus the money could only be approved into a foreign account. However, knowing all this, we will reach a binding agreement in this regards. As a matter of urgency, I will inform you the next step to take, while you Send your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments,I need your full co-operation to make this business a success, because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you,upon your positive response and once I am convinced that you are capable and will meet up with the instructions of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never let me down. With my influence and the position in the bank we can transfer this money to any foreigner's reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing. And to build confidence that you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act as directed. To prove the authenticity of the business I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries, foreign exchange departments, embassy and Board of Internal Revenue Services. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during this process. I look forward to your earliest reply through telephone,Fax or my email address. Yours truly oscar. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx = ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Oct 3 13:18:40 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDaa-0008Vp-01 for ; Thu, 03 Oct 2002 23:32:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:32:56 +0200 (CEST) Received: (qmail 30238 invoked by uid 0); 3 Oct 2002 11:18:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 3 Oct 2002 11:18:52 -0000 Received: by moria.seul.org (Postfix) id 867B315E754; Thu, 3 Oct 2002 07:18:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CF9515E75A; Thu, 3 Oct 2002 07:18:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id ED2E215E754 for ; Thu, 3 Oct 2002 07:18:47 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210031118.285d; Thu, 3 Oct 2002 11:18:40 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] registers From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Oct 2002 11:18:40 GMT Message-id: <200210031118.285d@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Just a little speach. For my job, i work with sparc V7 clone (ERC32 from ESA) and = V8 (LEON). This cpu have no fpu. But you could add a fpu called Me=EFko= from Sun. Sparc V8 arch use 32 windows register (>100 registers but on= ly 32 seeing in a given time). When you add the fpu you receive 32 regist= ers dedicated to the fpu (the 32 fpu regiter are 32 bit but you = could access it by to for 64 bit double). i have ask to our expert why adding new register set and not= use the integer register bank. I had in mind the f-cpu approach. This answer was quite simple : "to use more register" ! Think about it for Fcpu ! That's not a bad point because there is very few case where = you have to use integer operation on flotting point number. So it's 2 cl= ass of number with no real operation crossover. But this is also th= e case for Fcpu : why mixing register bank for simple integer and vecto= r ? Nowadays we too often think about 64 bits register length. s= o 64 =3D=3D the biggest int number. But in fact, the most interresting vecto= r size is 256 bits. As you can see, using a register of 256 for storing an integ= er of 64 bits is a big waste ! Look at our programmation api. We alwa= ys have 3 or 4 pointers in the register set, so 3/4 of the register will = never be used 95% of the time, what a waist, don't you think ? I don't think we should split fp and int register but SIMD a= nd scalar number. Why not having 2 registers bank, one SIMD, the other Scalar = ? This add 1/4 of memory content inside the cpu but double the number o= f usable registers. I don't thing this change could will need lot of modificatio= n in existing code. nicO ____________________________________________________________= __________ Exclusif: 75 euros rembours=E9s sur le pack eXtense Haut D=E9= bit de Wanadoo !=20 Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Oct 3 13:56:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDac-0008Vp-00 for ; Thu, 03 Oct 2002 23:32:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:32:58 +0200 (CEST) Received: (qmail 13533 invoked by uid 0); 3 Oct 2002 11:56:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 3 Oct 2002 11:56:40 -0000 Received: by moria.seul.org (Postfix) id 6183F15E720; Thu, 3 Oct 2002 07:56:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 58AA215E759; Thu, 3 Oct 2002 07:56:39 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 0B2AE15E720 for ; Thu, 3 Oct 2002 07:56:39 -0400 (EDT) Received: from homeworld (80.15.61.228) by smtp.laposte.net (6.0.053) id 3D984CCF0004E957 for f-cpu@seul.org; Thu, 3 Oct 2002 13:56:37 +0200 Message-ID: <00eb01c26ad3$db517e70$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200210031118.285d@th00.opsion.fr> Subject: Re: [f-cpu] registers Date: Thu, 3 Oct 2002 13:56:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Thursday, October 03, 2002 1:18 PM Subject: [f-cpu] registers [You] That's not a bad point because there is very few case where you have to use integer operation on flotting point number. So it's 2 class of number with no real operation crossover. But this is also the case for Fcpu : why mixing register bank for simple integer and vector ? {I} I think it is what you all would like to do : sharing the same register-bank regardless with integer or float, single or vector modes. [You] Nowadays we too often think about 64 bits register length. so 64 == the biggest int number. But in fact, the most interresting vector size is 256 bits. As you can see, using a register of 256 for storing an integer of 64 bits is a big waste ! Look at our programmation api. We always have 3 or 4 pointers in the register set, so 3/4 of the register will never be used 95% of the time, what a waist, don't you think ? {I} Okay, single integer can be only in 64-bit even if physically they are 256 bit. So you prefer to split and use a different register-bank instead. The trouble if we consider using vector integer registers are much more underused than single integer registers, well we still waste memory indeed for 95% of the time wherever the 3/4 of 256-bit for registers are physically located :). P.S.: waist = taille,ceinture (fr), you mean "waste" ;) [You] I don't think we should split fp and int register but SIMD and scalar number. Why not having 2 registers bank, one SIMD, the other Scalar ? This add 1/4 of memory content inside the cpu but double the number of usable registers. {I} So we would switch one of the two register-banks through the SIMD bit in the instruction format ? What do you mean by doubling the number of usable registers ? as far as I know, we can only access 64 registers at most as a range, so if you want to transfer between scalar integer registers and vector integer registers, it would be impossible to do so since we cannot mix both through the SIMD bit setting. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Oct 3 15:42:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDac-0008Vp-01 for ; Thu, 03 Oct 2002 23:32:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:32:58 +0200 (CEST) Received: (qmail 19266 invoked by uid 0); 3 Oct 2002 12:30:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 3 Oct 2002 12:30:57 -0000 Received: by moria.seul.org (Postfix) id 1B89415E722; Thu, 3 Oct 2002 08:30:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C3DA015E75A; Thu, 3 Oct 2002 08:30:55 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id CE0FB15E722 for ; Thu, 3 Oct 2002 08:30:54 -0400 (EDT) Received: from f-cpu.org (kdl14-73.n.club-internet.fr [213.44.12.73]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 02F7316A7 for ; Thu, 3 Oct 2002 14:30:49 +0200 (CEST) Message-ID: <3D9C4937.4020604@f-cpu.org> Date: Thu, 03 Oct 2002 14:42:15 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Nicolas Boulay wrote: >Just a little speach. > >For my job, i work with sparc V7 clone (ERC32 from ESA) and V8 (LEON). >This cpu have no fpu. But you could add a fpu called Meïko from Sun. > >Sparc V8 arch use 32 windows register (>100 registers but only 32 seeing >in a given time). > AFAIK, the "windows" have a granularity of 8 registers. Only 24 registers from the "sliding window" can be seen at a time. I wouldn't count your >100 registers as interesting because only a small fraction is used at a time. > When you add the fpu you receive 32 registers >dedicated to the fpu (the 32 fpu regiter are 32 bit but you could access >it by to for 64 bit double). > Is it in a "sliding window" too ? >i have ask to our expert why adding new register set and not use the >integer register bank. I had in mind the f-cpu approach. > >This answer was quite simple : "to use more register" ! > >Think about it for Fcpu ! > > Think that F-CPU has 3x more "useful" registers than SPARC ! Think that the 64 registers of F-CPU amounts to the same total register number as ALPHA 21064 or MIPS R4000. we have 63 registers while SPARC has only 24 (+32, if what is understood is ok). So the argument doesn't hold. >That's not a bad point because there is very few case where you have to >use integer operation on flotting point number. > But when you have to do it, you are often caught in a critical place where moving registers from one set to another is the slowest thing, indeed because those smart engineers thought that this operation doesn't occur often... > So it's 2 class of >number with no real operation crossover. But this is also the case for >Fcpu : why mixing register bank for simple integer and vector ? > > If you want such a computer, use a Cray or a derived architecture. BTW, F-CPU is not a "vector" computer, it's "SIMD" (or "very short vector", compared to the 64 numbers per register of CRAY). >Nowadays we too often think about 64 bits register length. so 64 == the >biggest int number. But in fact, the most interresting vector size is >256 bits. > > This can change in the future.... if compilers get better, if programs are better written... It will take some time, but when it's done, then a 256-bit-only CPU will be outperformed by more flexible computers. >As you can see, using a register of 256 for storing an integer of 64 >bits is a big waste ! Look at our programmation api. We always have 3 or >4 pointers in the register set, so 3/4 of the register will never be >used 95% of the time, what a waist, don't you think ? > > hey ! speak about the waste of adding a FPU and FP registers to a computer that does ints most of the time : you _lose_ 1/2 of the silicon. I would like to see the _real_ use of the FPU in your spacec computers : do they do FP 50% of the time ? And by the way, LEON is a single issue CPU so by definition, one half of the core is not used (or available) at any time. Compare ALPHA 21064 (just an example that i am not too ignorant to speak) and a single-issue CPU with FPU : ALPHA can issue 2 instructions at a time. one FP and one INT (for example). this is the best case and in that condition, it achieves 100% of performance (well, i don't speak about memory access etc...) LEON can issue 1 inst/cycle ==> At any cycle, the decoder (and the program) can't use either one of int or FP units. so even in the best cases, 50% of silicon use is the most one can achieve. By "silicon use", i mean : accessing data in the register set and computing it. Computing can be pipelined, but accessing data is what hurts most if there is a split register set. Currently, FC0 is the current implementation of F-CPU. I believe that EVEN though newer and better architectures will come, FC0 will be used a lot for power-saving applications for example. So yes we must think about the future but we must not harm FC0 too. FC0 uses a single monolithic register set which is probably very slow, but it's compact and efficient for a single-instruction pipeline. We can later make more "intelligent" cores that will have different register sizes and split banks, but it's much too complex now, because we don't even do a single-issue CPU... >I don't think we should split fp and int register but SIMD and scalar >number. > > Cray went even further (and a lot followed) : there are 3 (sometimes even more) banks, 1 for ints, 1 for FP and 1 for vectors. However, the compilers are not in the public domain... More importantly, i don't think it was an issue in the CRAYs but in a single-chip, split sets means separate execution units. dooohoh ! this means that some units will be duplicated ! more headaches... >Why not having 2 registers bank, one SIMD, the other Scalar ? This add >1/4 of memory content inside the cpu but double the number of usable >registers. > > And what about the case when there is no need of SIMD ? And what about the problems of saving the whole CPU state ? And what about the cases when ints must be compared to SIMDs or stuffs like that ? And what about the necessary additional instruction that is necessary to at least help in the last question ? And what about the modification of the non-computational instructions (load/store etc) ? Does this means that it creates new coding restrictions ? (not being able to do a "GET" or "PUT" to/from SIMD ...) And will you have the courage to modify all the manual to reflect these "additions" ? >I don't thing this change could will need lot of modification in >existing code. > > of course it will ! it will affect the register allocation algorithms, the compilers, the instruction set etc.... And more importantly : you will go back to the programming environment of those "multimedia extensions" such as MMX, SSE, Altivec... you will "split" the core in parts that will not be able to communicate as easily as if it was unified. Now one question : why going back almost 4 years in the past and want to modify such a critical characteristics of the F-CPU ISA ? I don't think it's constructive. Let me remember you that if F-CPU was only developped by myself, there would be at least 128 registers..... So we have to make some "compromises" and once the difficult and long decision is taken, it is a waste of time to discuss about it again. Rather, it is more important to implement it. A single large set might be underused, but the situation is often worse with split sets. I guess that FC0 has reached a point of least return on modification. If you really want to exercise your skills usefully, maybe you can make a draft about FC1 ? à ce soir, >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Oct 3 14:46:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDad-0008Vp-00 for ; Thu, 03 Oct 2002 23:32:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:32:59 +0200 (CEST) Received: (qmail 20828 invoked by uid 0); 3 Oct 2002 12:49:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 3 Oct 2002 12:49:15 -0000 Received: by moria.seul.org (Postfix) id B9F7115E8E9; Thu, 3 Oct 2002 08:46:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4D6E15E8EF; Thu, 3 Oct 2002 08:46:18 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 5349E15E8E9 for ; Thu, 3 Oct 2002 08:46:18 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix2-2.free.fr (Postfix) with ESMTP id AB56A5F82E for ; Thu, 3 Oct 2002 14:46:17 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id 9BD018C05C; Thu, 3 Oct 2002 14:46:17 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] registers Message-ID: <1033649177.3d9c3c1995063@imp.free.fr> Date: Thu, 03 Oct 2002 14:46:17 +0200 (MEST) From: Cedric BAIL References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> In-Reply-To: <00eb01c26ad3$db517e70$0100000a@homeworld> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > [You] > Nowadays we too often think about 64 bits register length. so 64 == > the biggest int number. But in fact, the most interresting vector size is > 256 bits. > As you can see, using a register of 256 for storing an integer of 64 > bits is a big waste ! Look at our programmation api. We always have 3 > or 4 pointers in the register set, so 3/4 of the register will never be > used 95% of the time, what a waist, don't you think ? > {I} > Okay, single integer can be only in 64-bit even if physically they are > 256 bit. So you prefer to split and use a different register-bank instead. > The trouble if we consider using vector integer registers are much more > underused than single integer registers, well we still waste memory > indeed for 95% of the time wherever the 3/4 of 256-bit for registers are > physically > located :). And perhaps more, because you always need to save all your register, so you have 256*63 + 64*63 = 20160 (2520 o => 2,5 Ko) instead of 256*63 = 16128 (2016 o => 1,9 Ko). So you loose more place and you increase needed move when you work with SIMD. > Sparc V8 arch use 32 windows register (>100 registers but only 32 seeing > in a given time). When you add the fpu you receive 32 registers > dedicated to the fpu (the 32 fpu regiter are 32 bit but you could access > it by to for 64 bit double). > i have ask to our expert why adding new register set and not use the > integer register bank. I had in mind the f-cpu approach. > This answer was quite simple : "to use more register" ! I think it's not the real reason. Because when you have 64 registers for int and float you can produce better code with less data in memory than with 32 registers for int and 32 registers for float. In a normal application you don't use a lot of float (and SIMD), so you can't use them for int (or scalar). In fact by dividing the registers bank, you waste capacity from my point of view. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Oct 3 15:16:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDae-0008Vp-00 for ; Thu, 03 Oct 2002 23:33:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:33:00 +0200 (CEST) Received: (qmail 13265 invoked by uid 0); 3 Oct 2002 13:16:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 3 Oct 2002 13:16:43 -0000 Received: by moria.seul.org (Postfix) id F064715E75E; Thu, 3 Oct 2002 09:16:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C3D8015E761; Thu, 3 Oct 2002 09:16:41 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3C1FF15E75E for ; Thu, 3 Oct 2002 09:16:41 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210031316.1c76; Thu, 3 Oct 2002 13:16:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] registers From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Oct 2002 13:16:28 GMT Message-id: <200210031316.1c76@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 03/10/02 Objet: Re: [f-cpu] registers hello, Nicolas Boulay wrote: >Just a little speach. > >For my job, i work with sparc V7 clone (ERC32 from ESA) and= V8 (LEON). >This cpu have no fpu. But you could add a fpu called Me=EFk= o from Sun. > >Sparc V8 arch use 32 windows register (>100 registers but o= nly 32 seeing >in a given time). > AFAIK, the "windows" have a granularity of 8 registers. Only= 24=20 registers from the "sliding window" can be seen at a time. I wouldn't count your >100 registers = as=20 interesting because only a small fraction is used at a time. >>>>there is 32 register at a time, 24 inside the windows an= d 8 globals. Windows register have the interrest to have lithning fast ca= ll convention, that is much quicker that the mess of the fcpu n= eeded for a call. But there is the trap handler problem. > When you add the fpu you receive 32 registers >dedicated to the fpu (the 32 fpu regiter are 32 bit but you= could access >it by to for 64 bit double). > Is it in a "sliding window" too ? >>>nop, it's completly appart. >i have ask to our expert why adding new register set and no= t use the >integer register bank. I had in mind the f-cpu approach. > >This answer was quite simple : "to use more register" ! > >Think about it for Fcpu ! > =20 > Think that F-CPU has 3x more "useful" registers than SPARC ! Think that the 64 registers of F-CPU amounts to the same tot= al register number as ALPHA 21064 or MIPS R4000. we have 63 registers while SPARC has only 24 (+32, if what i= s understood is ok). So the argument doesn't hold. >>>i never try to compare f-cpu and the little 50000 gate LE= ON wich run at 200 Mhz or the ERC32 =E0 25 Mhz ! I try to compare the ph= ilosophie of the use of the register. They think we have only 5 bits for = register adressing so let split the bank to have more space. >That's not a bad point because there is very few case where= you have to >use integer operation on flotting point number. > But when you have to do it, you are often caught in a critic= al place=20 where moving registers from one set to another is the slowes= t thing, indeed because those smart engineers thought that this opera= tion doesn't occur often... >>>Even with a single register set you will need to manipula= te the vector because you can't access every chunk individualy ! > So it's 2 class of >number with no real operation crossover. But this is also t= he case for >Fcpu : why mixing register bank for simple integer and vect= or ? > =20 > If you want such a computer, use a Cray or a derived archite= cture. BTW, F-CPU is not a "vector" computer, it's "SIMD" (or "very= short vector", compared to the 64 numbers per register of CRAY). >>>Or compare to the 144kb register of NEC ESS supercomputer= a little bit newer than Cray ( http://www.nec-ess.com/newsroom/attachments/SX-6-Single-node= .pdf ). >Nowadays we too often think about 64 bits register length. = so 64 =3D=3D the >biggest int number. But in fact, the most interresting vect= or size is >256 bits. > =20 > This can change in the future.... if compilers get better, if programs are better written... It will take some time, but when it's done, then a 256-bit-o= nly CPU will be outperformed by more flexible computers. >>>This size as been found as a good size for double intensi= ve application. With more chunk in a register you couldn't use = the vector any more, if there is too much dependancies. When the time will come why keeping binary compatibility is = important ? >As you can see, using a register of 256 for storing an inte= ger of 64 >bits is a big waste ! Look at our programmation api. We alw= ays have 3 or >4 pointers in the register set, so 3/4 of the register will= never be >used 95% of the time, what a waist, don't you think ? > =20 > hey ! speak about the waste of adding a FPU and FP registers= to a=20 computer that does ints most of the time : you _lose_ 1/2 of the silicon. = I would like to see the _real_ use of the FPU in your spacec computers : do they do = FP 50% of=20 the time ? >>>I forgot that you are an expert in SCAO and realtime comp= uting...:-/ That's true the leader in space insdustrie in Europe have on= ly stupid expert, i forgot, that... And by the way, LEON is a single issue CPU so by definition,= one half of the core is not used (or available) at any time. Compare ALPHA 21064 (just an example that i am not too ignor= ant to speak) and a single-issue CPU with FPU : ALPHA can issue 2 instructions at a time. one FP and one IN= T (for example). this is the best case and in that condition, it achieves 10= 0% of=20 performance (well, i don't speak about memory access etc...) LEON can issue 1 inst/cycle =3D=3D> At any cycle, the decod= er (and the program) can't use either one of int or FP units. so even in the bes= t cases, 50% of silicon use is the most one can achieve. >>>I beleive that operator in f-cpu doesn't shared much of t= he silicon, so when things are computed 80% of the chip sleep... By "silicon use", i mean : accessing data in the register se= t and=20 computing it. Computing can be pipelined, but accessing data is what hurts= most if there is a split register set. Currently, FC0 is the current implementation of F-CPU. I believe that EVEN though newer and better architectures wi= ll come, FC0 will be used a lot for power-saving applications for exa= mple. So yes we must think about the future but we must not harm F= C0 too. FC0 uses a single monolithic register set which is probably = very slow, but it's compact and efficient for a single-instruction pipe= line. >>>if it slow it's not efficient. "simple", i prefer. We can later make more "intelligent" cores that will have di= fferent register sizes and split banks, but it's much too complex no= w, because we don't even do a single-issue CPU... >I don't think we should split fp and int register but SIMD = and scalar >number. > =20 > Cray went even further (and a lot followed) : there are 3 (s= ometimes=20 even more) banks, 1 for ints, 1 for FP and 1 for vectors. However, the compile= rs are not=20 in the public domain... >>> actual x86 arch are even worse, almost every register ha= ven't the same usefullness... More importantly, i don't think it was an issue in the CRAYs= but in a=20 single-chip, split sets means separate execution units. dooohoh ! this me= ans that=20 some units will be duplicated ! more headaches... >>>> ???? i don't think why, you could reused what you want = ! >Why not having 2 registers bank, one SIMD, the other Scalar= ? This add >1/4 of memory content inside the cpu but double the number = of usable >registers. > =20 > And what about the case when there is no need of SIMD ? >>>only 1/4 of the waste.=20 And what about the problems of saving the whole CPU state ? >>>Not really the hard point for me. And what about the cases when ints must be compared to SIMDs= or stuffs like that ? >>>>i don't understand why not try to access the 2bank for t= he same op. And what about the necessary additional instruction that is = necessary to at least help in the last question ? And what about the modification of the non-computational ins= tructions (load/store etc) ? Does this means that it creates new codin= g restrictions ? (not being able to do a "GET" or "PUT" to/from SIMD ...) And will you have the courage to modify all the manual to re= flect these "additions" ? >>> the bigger side effect is when you use mixed instruction= . But this could be detected. To know which register to load. >I don't thing this change could will need lot of modificati= on in >existing code. > =20 > of course it will ! it will affect the register allocation a= lgorithms,=20 the compilers, the instruction set etc....=20 >>> in the expression "existing code", there is the word "ex= isting" from the verbe to exist, which means that the code is still there= in f-cpu.seul.org. Does i miss a complete port of gcc ? And more importantly : you will go back to the programming e= nvironment of those "multimedia extensions" such as MMX, SSE, Altivec..= . >>>not really. you will "split" the core in parts that will not be able to = communicate as easily as if it was unified. >>> You think about think i didn't mention. Now one question : why going back almost 4 years in the past and want to modify= such a critical characteristics of the F-CPU ISA ? I don't think it's constructive. Let me remember you that if= F-CPU was only developped by myself, there would be at least 128 regis= ters..... >>>Not enought space in the 32 bits instruction world. Big r= egister set are really interresting to decrease memory pressure and vect= or registor could be used as preload area in really no-SIMD code. So we have to make some "compromises" and once the difficult= and long decision is taken, it is a waste of time to discuss abo= ut it again. Rather, it is more important to implement it. A single large= set might be underused, but the situation is often worse with split se= ts. I guess that FC0 has reached a point of least return on modification= . >>>the usual speach... If you really want to exercise your skills usefully, maybe = you can make a draft about FC1 ? >>> I should do that to avoid to be to much frustrated. nicO =E0 ce soir, >nicO > =20 > YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________ Etudiant: Wanadoo t'offre le Pack eXtense Haut D=E9bit soit = 150,92 euros d'=E9conomies ! Clique ici : http://www.ifrance.com/_reloc/m= ail.etudiant=20 ____________________________________________________________= __________ Etudiant: Wanadoo t'offre le Pack eXtense Haut D=E9bit soit = 150,92 euros d'=E9conomies ! Clique ici : http://www.ifrance.com/_reloc/m= ail.etudiant ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Oct 3 15:29:28 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDah-0008Vp-00 for ; Thu, 03 Oct 2002 23:33:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:33:03 +0200 (CEST) Received: (qmail 22854 invoked by uid 0); 3 Oct 2002 13:29:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 3 Oct 2002 13:29:40 -0000 Received: by moria.seul.org (Postfix) id E2E2715E75F; Thu, 3 Oct 2002 09:29:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C82E415E8E8; Thu, 3 Oct 2002 09:29:38 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 5C0E315E75F for ; Thu, 3 Oct 2002 09:29:38 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210031329.1c10; Thu, 3 Oct 2002 13:29:28 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] registers From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Oct 2002 13:29:28 GMT Message-id: <200210031329.1c10@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N i maid a misatake when i speak about waste. The true point is performance. We can't access more than 64 = registers because of the instruction word size. How using more registe= r (i remember you that's the main point to decrease memory bandwi= th pressure) ? So the answer of the sparc designer is to ADD an other regis= ter bank. They choose to put it for fp numbers. The true killer point is all the change in the register set = to use it in fcpu. I admit it could be a hard stuff.=20 An other proposal for making Whygee cry : use only 16 256 bi= ts vector register. So you leave 2 bits to direct access each of the 6= 4 bits chunk and you will gain a lot of flexibility to access them (compa= re to now) ok it's too few compare to the pipeline size... [ok je sors ;p]=20 -----Message d'origine----- De: Cedric BAIL A: f-cpu@seul.org Date: 03/10/02 Objet: Re: [f-cpu] registers > [You] > Nowadays we too often think about 64 bits register length.= so 64 =3D=3D > the biggest int number. But in fact, the most interresting= vector size is > 256 bits. =20 > As you can see, using a register of 256 for storing an int= eger of 64 > bits is a big waste ! Look at our programmation api. We al= ways have 3 > or 4 pointers in the register set, so 3/4 of the register = will never be > used 95% of the time, what a waist, don't you think ? > {I} > Okay, single integer can be only in 64-bit even if physica= lly they are > 256 bit. So you prefer to split and use a different regist= er-bank instead. > The trouble if we consider using vector integer registers = are much more > underused than single integer registers, well we still was= te memory > indeed for 95% of the time wherever the 3/4 of 256-bit for= registers are > physically > located :). And perhaps more, because you always need to save all your r= egister, so you have 256*63 + 64*63 =3D 20160 (2520 o =3D> 2,5 Ko) inste= ad of=20 256*63 =3D 16128 (2016 o =3D> 1,9 Ko). So you loose more pla= ce and you increase needed move when you work with SIMD. > Sparc V8 arch use 32 windows register (>100 registers but = only 32 seeing > in a given time). When you add the fpu you receive 32 regi= sters > dedicated to the fpu (the 32 fpu regiter are 32 bit but yo= u could access > it by to for 64 bit double). > i have ask to our expert why adding new register set and n= ot use the > integer register bank. I had in mind the f-cpu approach. > This answer was quite simple : "to use more register" ! I think it's not the real reason. Because when you have 64 r= egisters for int and float you can produce better code with less data in = memory than with 32 registers for int and 32 registers for float. In a normal= application you don't use a lot of float (and SIMD), so you can't use th= em for int (or=20 scalar). In fact by dividing the registers bank, you waste c= apacity from my point of view. A+ Cedric ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________ Etudiant: Wanadoo t'offre le Pack eXtense Haut D=E9bit soit = 150,92 euros d'=E9conomies ! Clique ici : http://www.ifrance.com/_reloc/m= ail.etudiant=20 ____________________________________________________________= __________ Exclusif: 75 euros rembours=E9s sur le pack eXtense Haut D=E9= bit de Wanadoo !=20 Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Oct 3 18:23:56 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xDai-0008Vp-00 for ; Thu, 03 Oct 2002 23:33:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Oct 2002 23:33:04 +0200 (CEST) Received: (qmail 6893 invoked by uid 0); 3 Oct 2002 15:12:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 3 Oct 2002 15:12:32 -0000 Received: by moria.seul.org (Postfix) id C257415E708; Thu, 3 Oct 2002 11:12:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A5F7215E8EC; Thu, 3 Oct 2002 11:12:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4D03415E708 for ; Thu, 3 Oct 2002 11:12:31 -0400 (EDT) Received: from f-cpu.org (kdl14-145.n.club-internet.fr [213.44.12.145]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2963F1687 for ; Thu, 3 Oct 2002 17:12:28 +0200 (CEST) Message-ID: <3D9C6F1C.5050703@f-cpu.org> Date: Thu, 03 Oct 2002 17:23:56 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] registers References: <200210031329.1c10@th00.opsion.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello, Nicolas Boulay wrote: >i maid a misatake when i speak about waste. > no : it's part of the whole equation. If some part of the die is underused, then it means that it can be removed or the same function is already implemented somewhere else. Then the die can be smaller, the power consumption and the price can be reduced, and the cost/performance ratio enhanced. >The true point is performance. We can't access more than 64 registers >because of the instruction word size. > On the other extreme, we could easily make a "move machine" (TTA) with 64K registers ;-P Some computers with 32-bit instruction words like MMIX or SX-6 have a 4-byte organisation (8 bits for opcode, 8 for each operand) and 256 registers. I have already explored the world of 128-register machines (leaving 11 bits for the opcode) but this was rejected. Fortunately there are more than 32 registers and we can still make very flexible opcodes. Increasing the instruction word size creates another world of problem. But we currently use it because it's the best compromise yet. Maybe other "extensions" will be used for a superscalar core ?... > How using more register (i >remember you that's the main point to decrease memory bandwith pressure) ? > may i remember you that you don't have to convince me on this ? The real problem is "how"... and at what cost. >So the answer of the sparc designer is to ADD an other register bank. >They choose to put it for fp numbers. > > This problem has been taken into account since the beginning of FC0, because in 1999, "classical" RISC machines had already reached their limits. However, the solutions they used were not always very good and only moved the real problems around (that is : adding a new register set does not change the fact that in the beginning, there were not enough registers). >The true killer point is all the change in the register set to use it in >fcpu. I admit it could be a hard stuff. > > do you think we don't have enough registers ? >An other proposal for making Whygee cry : use only 16 256 bits vector >register. So you leave 2 bits to direct access each of the 64 bits chunk >and you will gain a lot of flexibility to access them (compare to now) >ok it's too few compare to the pipeline size... > good point... >[ok je sors ;p] > welcome to the english f-cpu bouchot... n'oublie pas d'ailleurs de participer à Da Manual Bouchot, ce soir... et encore bravo pour le troll : très réussi ! YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Fri Oct 4 00:46:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xLlG-0005m2-00 for ; Fri, 04 Oct 2002 08:16:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 04 Oct 2002 08:16:30 +0200 (CEST) Received: (qmail 32295 invoked by uid 0); 4 Oct 2002 05:57:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 4 Oct 2002 05:57:46 -0000 Received: by moria.seul.org (Postfix) id D8AA015E754; Fri, 4 Oct 2002 01:57:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAE9715E766; Fri, 4 Oct 2002 01:57:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by moria.seul.org (Postfix) with ESMTP id 4E21715E754 for ; Fri, 4 Oct 2002 01:57:44 -0400 (EDT) Received: (qmail 22316 invoked from network); 4 Oct 2002 05:57:45 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Oct 2002 05:57:45 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id 10FE3C2 for ; Thu, 3 Oct 2002 23:00:32 -0700 (PDT) Message-ID: <3D9CC8B6.5030701@m4x.org> Date: Thu, 03 Oct 2002 22:46:14 +0000 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Salut cedric, Je viens de debarquer y a pas longtemps dans la planete F-CPU et j'ai commence par lire le manuel. J'ai recupere un Snapshot et j'ai regarde ou en etait les differentes EUs. Je suis interesse par aider sur l'EU de la division entiere. J'ai vu que t'as deja designe une unite qui gere au niveau 8 bits unsigned. J'ai vu aussi que tu obtenais le resultat en 7 cycles. Je voulais savoir, quelles etaient les contraintes qui sont imposees au niveau timing, perf, taille a l'implementation etc. J'ai pas mal de documentation de cours anciens que j'ai pris sur de l'arithmetique hardware. Je vais essayer de voir ce que je peux en sortir. A bienot Dali Cedric BAIL wrote: >>[You] >>Nowadays we too often think about 64 bits register length. so 64 == >>the biggest int number. But in fact, the most interresting vector size is >>256 bits. > > > >>As you can see, using a register of 256 for storing an integer of 64 >>bits is a big waste ! Look at our programmation api. We always have 3 >>or 4 pointers in the register set, so 3/4 of the register will never be >>used 95% of the time, what a waist, don't you think ? > > >>{I} >>Okay, single integer can be only in 64-bit even if physically they are >>256 bit. So you prefer to split and use a different register-bank instead. >>The trouble if we consider using vector integer registers are much more >>underused than single integer registers, well we still waste memory >>indeed for 95% of the time wherever the 3/4 of 256-bit for registers are >>physically >>located :). > > > And perhaps more, because you always need to save all your register, so > you have 256*63 + 64*63 = 20160 (2520 o => 2,5 Ko) instead of > 256*63 = 16128 (2016 o => 1,9 Ko). So you loose more place and you increase > needed move when you work with SIMD. > > >>Sparc V8 arch use 32 windows register (>100 registers but only 32 seeing >>in a given time). When you add the fpu you receive 32 registers >>dedicated to the fpu (the 32 fpu regiter are 32 bit but you could access >>it by to for 64 bit double). > > >>i have ask to our expert why adding new register set and not use the >>integer register bank. I had in mind the f-cpu approach. > > >>This answer was quite simple : "to use more register" ! > > > I think it's not the real reason. Because when you have 64 registers for > int and float you can produce better code with less data in memory than with > 32 registers for int and 32 registers for float. In a normal application > you don't use a lot of float (and SIMD), so you can't use them for int (or > scalar). In fact by dividing the registers bank, you waste capacity from > my point of view. > > A+ > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ______________________________________________________________________ > Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros > d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Oct 4 11:47:18 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xQ67-0000Yi-01 for ; Fri, 04 Oct 2002 12:54:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 04 Oct 2002 12:54:19 +0200 (CEST) Received: (qmail 25265 invoked by uid 0); 4 Oct 2002 09:50:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 4 Oct 2002 09:50:18 -0000 Received: by moria.seul.org (Postfix) id D826E15E708; Fri, 4 Oct 2002 05:50:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B533E15E768; Fri, 4 Oct 2002 05:50:17 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id 06C2E15E708 for ; Fri, 4 Oct 2002 05:50:17 -0400 (EDT) Received: (qmail 70873 invoked by uid 85); 4 Oct 2002 09:39:27 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.43606 secs); 04 Oct 2002 09:39:27 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 4 Oct 2002 09:39:26 -0000 Message-ID: <3D9D63A6.5070505@yahoo.fr> Date: Fri, 04 Oct 2002 11:47:18 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hello Mohamed, Like you can see this list must be write in english, if you have some problems with the Shakespeare language, try some web translator, like http://www.freetranslation.com this is certainly not the better one, but it's usefull. Otherwise, you have the french f-cpu list to have some non technical info on f-cpu. This french list discuss about planning activity around f-cpu for french members (and more especially for Parisien people). If you want contact a specific people on list, use his address. Thanks Just an Illusion Mohamed Ali Kilani a écrit: > Salut cedric, > > Je viens de debarquer y a pas longtemps dans la planete F-CPU et j'ai > commence par lire le manuel. J'ai recupere un Snapshot et j'ai regarde > ou en etait les differentes EUs. > > Je suis interesse par aider sur l'EU de la division entiere. > J'ai vu que t'as deja designe une unite qui gere au niveau 8 bits > unsigned. J'ai vu aussi que tu obtenais le resultat en 7 cycles. > > Je voulais savoir, quelles etaient les contraintes qui sont imposees > au niveau timing, perf, taille a l'implementation etc. > > J'ai pas mal de documentation de cours anciens que j'ai pris sur de > l'arithmetique hardware. Je vais essayer de voir ce que je peux en > sortir. > > A bienot > > Dali > > Cedric BAIL wrote: > >>> [You] >>> Nowadays we too often think about 64 bits register length. so 64 == >>> the biggest int number. But in fact, the most interresting vector >>> size is >>> 256 bits. >> >> >> >> >>> As you can see, using a register of 256 for storing an integer of 64 >>> bits is a big waste ! Look at our programmation api. We always have 3 >>> or 4 pointers in the register set, so 3/4 of the register will never be >>> used 95% of the time, what a waist, don't you think ? >> >> >> >>> {I} >>> Okay, single integer can be only in 64-bit even if physically they are >>> 256 bit. So you prefer to split and use a different register-bank >>> instead. >>> The trouble if we consider using vector integer registers are much more >>> underused than single integer registers, well we still waste memory >>> indeed for 95% of the time wherever the 3/4 of 256-bit for registers >>> are >>> physically >>> located :). >> >> >> >> And perhaps more, because you always need to save all your register, so >> you have 256*63 + 64*63 = 20160 (2520 o => 2,5 Ko) instead of 256*63 >> = 16128 (2016 o => 1,9 Ko). So you loose more place and you increase >> needed move when you work with SIMD. >> >> >>> Sparc V8 arch use 32 windows register (>100 registers but only 32 >>> seeing >>> in a given time). When you add the fpu you receive 32 registers >>> dedicated to the fpu (the 32 fpu regiter are 32 bit but you could >>> access >>> it by to for 64 bit double). >> >> >> >>> i have ask to our expert why adding new register set and not use the >>> integer register bank. I had in mind the f-cpu approach. >> >> >> >>> This answer was quite simple : "to use more register" ! >> >> >> >> I think it's not the real reason. Because when you have 64 registers for >> int and float you can produce better code with less data in memory >> than with >> 32 registers for int and 32 registers for float. In a normal application >> you don't use a lot of float (and SIMD), so you can't use them for >> int (or scalar). In fact by dividing the registers bank, you waste >> capacity from >> my point of view. >> >> A+ >> Cedric >> ************************************************************* >> To unsubscribe, send an e-mail to majordomo@seul.org with >> unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> ______________________________________________________________________ >> Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros >> d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant > > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Fri Oct 4 11:21:53 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xaXP-0007Ty-00 for ; Sat, 05 Oct 2002 00:03:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 05 Oct 2002 00:03:11 +0200 (CEST) Received: (qmail 21267 invoked by uid 0); 4 Oct 2002 16:33:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 4 Oct 2002 16:33:23 -0000 Received: by moria.seul.org (Postfix) id F402515E743; Fri, 4 Oct 2002 12:33:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD7CE15E763; Fri, 4 Oct 2002 12:33:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by moria.seul.org (Postfix) with ESMTP id 0786815E743 for ; Fri, 4 Oct 2002 12:33:22 -0400 (EDT) Received: (qmail 19323 invoked from network); 4 Oct 2002 16:33:21 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Oct 2002 16:33:21 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id BC687C3 for ; Fri, 4 Oct 2002 09:36:11 -0700 (PDT) Message-ID: <3D9D5DB1.1080908@m4x.org> Date: Fri, 04 Oct 2002 09:21:53 +0000 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi there, it was a miss posting. I didn't pay attention to the "To:" field in the e-mail. I should have posted it in english anyway ;) So I was saying in the e-mail that I just joined the team. I am trying to get some information on the EU_IDU in order to look and see what I can do. Dali Just an Illusion wrote: > Hello Mohamed, > > Like you can see this list must be write in english, if you have some > problems with the Shakespeare language, try some web translator, like > http://www.freetranslation.com this is certainly not the better one, but > it's usefull. > > Otherwise, you have the french f-cpu list to have some non technical > info on f-cpu. > This french list discuss about planning activity around f-cpu for french > members (and more especially for Parisien people). > > If you want contact a specific people on list, use his address. > > Thanks > Just an Illusion > > Mohamed Ali Kilani a écrit: > > >>Salut cedric, >> >>Je viens de debarquer y a pas longtemps dans la planete F-CPU et j'ai >>commence par lire le manuel. J'ai recupere un Snapshot et j'ai regarde >>ou en etait les differentes EUs. >> >>Je suis interesse par aider sur l'EU de la division entiere. >>J'ai vu que t'as deja designe une unite qui gere au niveau 8 bits >>unsigned. J'ai vu aussi que tu obtenais le resultat en 7 cycles. >> >>Je voulais savoir, quelles etaient les contraintes qui sont imposees >>au niveau timing, perf, taille a l'implementation etc. >> >>J'ai pas mal de documentation de cours anciens que j'ai pris sur de >>l'arithmetique hardware. Je vais essayer de voir ce que je peux en >>sortir. >> >>A bienot >> >>Dali >> >>Cedric BAIL wrote: >> >> >>>>[You] >>>>Nowadays we too often think about 64 bits register length. so 64 == >>>>the biggest int number. But in fact, the most interresting vector >>>>size is >>>>256 bits. >>> >>> >>> >>> >>> >>>>As you can see, using a register of 256 for storing an integer of 64 >>>>bits is a big waste ! Look at our programmation api. We always have 3 >>>>or 4 pointers in the register set, so 3/4 of the register will never be >>>>used 95% of the time, what a waist, don't you think ? >>> >>> >>> >>>>{I} >>>>Okay, single integer can be only in 64-bit even if physically they are >>>>256 bit. So you prefer to split and use a different register-bank >>>>instead. >>>>The trouble if we consider using vector integer registers are much more >>>>underused than single integer registers, well we still waste memory >>>>indeed for 95% of the time wherever the 3/4 of 256-bit for registers >>>>are >>>>physically >>>>located :). >>> >>> >>> >>>And perhaps more, because you always need to save all your register, so >>>you have 256*63 + 64*63 = 20160 (2520 o => 2,5 Ko) instead of 256*63 >>>= 16128 (2016 o => 1,9 Ko). So you loose more place and you increase >>>needed move when you work with SIMD. >>> >>> >>> >>>>Sparc V8 arch use 32 windows register (>100 registers but only 32 >>>>seeing >>>>in a given time). When you add the fpu you receive 32 registers >>>>dedicated to the fpu (the 32 fpu regiter are 32 bit but you could >>>>access >>>>it by to for 64 bit double). >>> >>> >>> >>>>i have ask to our expert why adding new register set and not use the >>>>integer register bank. I had in mind the f-cpu approach. >>> >>> >>> >>>>This answer was quite simple : "to use more register" ! >>> >>> >>> >>>I think it's not the real reason. Because when you have 64 registers for >>>int and float you can produce better code with less data in memory >>>than with >>>32 registers for int and 32 registers for float. In a normal application >>>you don't use a lot of float (and SIMD), so you can't use them for >>>int (or scalar). In fact by dividing the registers bank, you waste >>>capacity from >>>my point of view. >>> >>>A+ >>> Cedric >>>************************************************************* >>>To unsubscribe, send an e-mail to majordomo@seul.org with >>>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >>>______________________________________________________________________ >>>Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros >>>d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant >> >> >> >> >>************************************************************* >>To unsubscribe, send an e-mail to majordomo@seul.org with >>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Oct 4 14:10:46 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xaXV-0007Ty-00 for ; Sat, 05 Oct 2002 00:03:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 05 Oct 2002 00:03:17 +0200 (CEST) Received: (qmail 13395 invoked by uid 0); 4 Oct 2002 17:58:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Oct 2002 17:58:54 -0000 Received: by moria.seul.org (Postfix) id CEED715E755; Fri, 4 Oct 2002 13:58:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFA8215E766; Fri, 4 Oct 2002 13:58:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 3A4C015E755 for ; Fri, 4 Oct 2002 13:58:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00494; Fri, 4 Oct 2002 14:10:46 +0200 Message-ID: <20021004141046.62177@thrai.stud.uni-hannover.de> Date: Fri, 4 Oct 2002 14:10:46 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D9CC8B6.5030701@m4x.org>; from Mohamed Ali Kilani on Thu, Oct 03, 2002 at 10:46:14PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Thank you very much for speaking a language I can understand :( English, please! On Thu, Oct 03, 2002 at 10:46:14PM +0000, Mohamed Ali Kilani wrote: > Salut cedric, > > Je viens de debarquer y a pas longtemps dans la planete F-CPU et j'ai > commence par lire le manuel. J'ai recupere un Snapshot et j'ai regarde > ou en etait les differentes EUs. [...] -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Oct 4 22:22:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xaXX-0007Ty-01 for ; Sat, 05 Oct 2002 00:03:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 05 Oct 2002 00:03:19 +0200 (CEST) Received: (qmail 24197 invoked by uid 0); 4 Oct 2002 21:06:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 4 Oct 2002 21:06:45 -0000 Received: by moria.seul.org (Postfix) id 4546815E720; Fri, 4 Oct 2002 17:06:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E6F2515E76B; Fri, 4 Oct 2002 17:06:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a202.home.uni-hannover.de [130.75.232.202]) by moria.seul.org (Postfix) with ESMTP id 0C78C15E720 for ; Fri, 4 Oct 2002 17:06:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA00936; Fri, 4 Oct 2002 22:22:33 +0200 Message-ID: <20021004222233.55765@thrai.stud.uni-hannover.de> Date: Fri, 4 Oct 2002 22:22:33 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D9D5DB1.1080908@m4x.org>; from Mohamed Ali Kilani on Fri, Oct 04, 2002 at 09:21:53AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi Mohamed, hi rest-of-the-f-gang, > So I was saying in the e-mail that I just joined the team. I am trying > to get some information on the EU_IDU in order to look and see what I > can do. Everything you like to. But first let me summarize the status quo: I'm still playing with the SRT divider, and I guess I found a way to do SIMD integer divisions with few extra code (that is, gates). The unit will deliver one bit/cycle but needs some extra cycles for preparation and post-processing. This approach works best for large chunks. Compare-and-subtract, subtract-and-restore or non-restore algorithms will work with chunk sizes > 8 bit, but they will take two cycles/bit because the add/subtract subunit doesn't fit into a single pipeline stage. They're fine for 8-bit operands but too expensive for larger chunks. Cedric has written an 8-bit divider that is included in the latest snapshot. Finally, iterative solutions (like Newton-Raphson) will not only be rather slow (each step requires at least two successive arithmetic operations, at least one of them being a multiplication), but may also produce incorrect results due to limited precision (rounding errors). IMHO, they're suited for FP division only. Ideas/suggestions welcome. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Oct 5 01:06:02 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xkjl-0000PW-01 for ; Sat, 05 Oct 2002 10:56:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 05 Oct 2002 10:56:37 +0200 (CEST) Received: (qmail 8206 invoked by uid 0); 4 Oct 2002 23:01:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 4 Oct 2002 23:01:03 -0000 Received: by moria.seul.org (Postfix) id F048715E76A; Fri, 4 Oct 2002 19:01:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBDDB15E76E; Fri, 4 Oct 2002 19:01:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by moria.seul.org (Postfix) with ESMTP id 7962815E76A for ; Fri, 4 Oct 2002 19:01:01 -0400 (EDT) Received: from computer ([209.215.11.107]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021004230241.NPIX13943.imf03bis.bellsouth.net@computer> for ; Fri, 4 Oct 2002 19:02:41 -0400 Message-ID: <000a01c26bfa$9e04b5a0$6b0bd7d1@computer> From: "richard hartny" To: Subject: [f-cpu] Division Date: Fri, 4 Oct 2002 18:06:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C26BD0.B37A46E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C26BD0.B37A46E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael Riepe etal My design for the ERIN processor family uses an algoritm that skips = strings of ones and zeros. Is not a fixed time division. Includes = Normalization and Equalization of arguments. Requirements are; the = divisor must be equal to or greater than dividend. Does not include = improper divide. I have a very good functional block diagram that I = would be glad to provide - mailing addresses please. The hurricane missed me. Dick Hartney Erin Greene & Associates ------=_NextPart_000_0007_01C26BD0.B37A46E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Michael Riepe etal
 
    My design for the = ERIN processor=20 family uses an algoritm that skips strings of ones and zeros.  Is = not a=20 fixed time division.  Includes Normalization and Equalization of=20 arguments.  Requirements are; the divisor must be equal to or = greater than=20 dividend.  Does not include improper divide.  I have a very = good=20 functional block diagram that I would be glad to provide - mailing = addresses=20 please.
    The hurricane missed = me.
 
Dick Hartney
Erin Greene &=20 Associates
------=_NextPart_000_0007_01C26BD0.B37A46E0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Sat Oct 5 14:43:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xyQa-0001O6-00 for ; Sun, 06 Oct 2002 01:33:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 06 Oct 2002 01:33:44 +0200 (CEST) Received: (qmail 9969 invoked by uid 0); 5 Oct 2002 19:55:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 5 Oct 2002 19:55:06 -0000 Received: by moria.seul.org (Postfix) id 1F23315E76B; Sat, 5 Oct 2002 15:55:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D982315E778; Sat, 5 Oct 2002 15:55:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by moria.seul.org (Postfix) with ESMTP id 50C5915E76B for ; Sat, 5 Oct 2002 15:55:04 -0400 (EDT) Received: (qmail 14018 invoked from network); 5 Oct 2002 19:55:04 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Oct 2002 19:55:04 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id 393D4C2 for ; Sat, 5 Oct 2002 12:57:56 -0700 (PDT) Message-ID: <3D9EDE7A.5050600@m4x.org> Date: Sat, 05 Oct 2002 12:43:38 +0000 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael, All, Michael Riepe wrote: > Hi Mohamed, > hi rest-of-the-f-gang, > > >>So I was saying in the e-mail that I just joined the team. I am trying >>to get some information on the EU_IDU in order to look and see what I >>can do. > > > Everything you like to. But first let me summarize the status quo: It is always a good starting point. > > I'm still playing with the SRT divider, and I guess I found a way to do > SIMD integer divisions with few extra code (that is, gates). The unit > will deliver one bit/cycle but needs some extra cycles for preparation > and post-processing. This approach works best for large chunks. I am looking at SRT division with higher radix, like Radix-4 division which produces 2 bits at each iteration, or even radix-16 which produces 4 bits at each iteration. If the last solution could produce the 4 bits in 3 cycles for example given the adequate hardware, there is a gain (6 cycles of processing versus 8 cycles for 8 bits division). I am going to spend some time working through the implementation and try to get an idea of the critical path. > > Compare-and-subtract, subtract-and-restore or non-restore algorithms will > work with chunk sizes > 8 bit, but they will take two cycles/bit because > the add/subtract subunit doesn't fit into a single pipeline stage. > They're fine for 8-bit operands but too expensive for larger chunks. > Cedric has written an 8-bit divider that is included in the latest > snapshot. I have seen it. The problem with these dividers is that the critical path is a add/sub which is impossible to handle in 6 gates delays for large chuncks. I am still not clear what speed do we want to acheive with this unit and what is exactly the hardware budget available. Also, do we need for example to handle 64 bits division as well as 2x32 bits division/ 4x16 bits/8x8 division SIMD style? > > Finally, iterative solutions (like Newton-Raphson) will not only be rather > slow (each step requires at least two successive arithmetic operations, > at least one of them being a multiplication), but may also produce > incorrect results due to limited precision (rounding errors). IMHO, > they're suited for FP division only. If we can afford a multiplier and an add/sub unit quick enough (to be precised), we can go with this solution since it doubles the precision at each iteration, getting a 64 bits precision is just 3 iterations(one iteration = how many cycles?, I will get this later) after we have an 8 bits precision. If the error is less than 2^(-64) it can not show up in our 64 bits representation. > > Ideas/suggestions welcome. > I will work on the details of the different ideas I am talking about and try to come up with the Pros/Cons of each one. Dali ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 6 01:02:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17xyQj-0001O6-01 for ; Sun, 06 Oct 2002 01:33:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 06 Oct 2002 01:33:53 +0200 (CEST) Received: (qmail 5007 invoked by uid 0); 5 Oct 2002 23:02:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Oct 2002 23:02:25 -0000 Received: by moria.seul.org (Postfix) id 39C6215E778; Sat, 5 Oct 2002 19:02:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 126D715E77F; Sat, 5 Oct 2002 19:02:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a222.home.uni-hannover.de [130.75.232.222]) by moria.seul.org (Postfix) with ESMTP id 150FA15E778 for ; Sat, 5 Oct 2002 19:02:23 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02649; Sun, 6 Oct 2002 01:02:21 +0200 Message-ID: <20021006010221.29557@thrai.stud.uni-hannover.de> Date: Sun, 6 Oct 2002 01:02:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D9EDE7A.5050600@m4x.org>; from Mohamed Ali Kilani on Sat, Oct 05, 2002 at 12:43:38PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, Oct 05, 2002 at 12:43:38PM +0000, Mohamed Ali Kilani wrote: [...] > I am looking at SRT division with higher radix, like Radix-4 division > which produces 2 bits at each iteration, or even radix-16 which produces > 4 bits at each iteration. If the last solution could produce the 4 > bits in 3 cycles for example given the adequate hardware, there is a > gain (6 cycles of processing versus 8 cycles for 8 bits division). I am > going to spend some time working through the implementation and try to > get an idea of the critical path. Radix-16 is probably the smallest size that can produce more bits than it uses cycles. But the code will be rather complicated, compared to a radix-2 SRT, and will take a lot of die space. > > Compare-and-subtract, subtract-and-restore or non-restore algorithms will > > work with chunk sizes > 8 bit, but they will take two cycles/bit because > > the add/subtract subunit doesn't fit into a single pipeline stage. > > They're fine for 8-bit operands but too expensive for larger chunks. > > Cedric has written an 8-bit divider that is included in the latest > > snapshot. > > I have seen it. The problem with these dividers is that the critical > path is a add/sub which is impossible to handle in 6 gates delays for > large chuncks. I am still not clear what speed do we want to acheive > with this unit and what is exactly the hardware budget available. Also, > do we need for example to handle 64 bits division as well as 2x32 bits > division/ 4x16 bits/8x8 division SIMD style? That's the goal, yes. Speed should be reasonable (that is, approximately 1 bit/cycle). > > Finally, iterative solutions (like Newton-Raphson) will not only be rather > > slow (each step requires at least two successive arithmetic operations, > > at least one of them being a multiplication), but may also produce > > incorrect results due to limited precision (rounding errors). IMHO, > > they're suited for FP division only. > > If we can afford a multiplier and an add/sub unit quick enough (to be > precised), we can go with this solution since it doubles the precision > at each iteration, getting a 64 bits precision is just 3 iterations(one > iteration = how many cycles?, I will get this later) after we have an 8 > bits precision. You can count 6 cycles for a 64x64->128 bit multiplication, and 2 cycles for 64-bit add/sub. Plus the Xbar cycles to transfer data to/from the IDU and ASU units, since we're not going to duplicate them for division (the multiplier is huge!). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Sun Oct 6 04:48:54 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaC3-0000vn-00 for ; Mon, 07 Oct 2002 17:53:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:15 +0200 (CEST) Received: (qmail 10394 invoked by uid 0); 6 Oct 2002 10:00:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Oct 2002 10:00:23 -0000 Received: by moria.seul.org (Postfix) id 21E0215E769; Sun, 6 Oct 2002 06:00:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E95A915E772; Sun, 6 Oct 2002 06:00:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by moria.seul.org (Postfix) with ESMTP id 39D0C15E769 for ; Sun, 6 Oct 2002 06:00:19 -0400 (EDT) Received: (qmail 11449 invoked from network); 6 Oct 2002 10:00:22 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Oct 2002 10:00:22 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id ECD6CC2 for ; Sun, 6 Oct 2002 03:03:11 -0700 (PDT) Message-ID: <3D9FA496.9060403@m4x.org> Date: Sun, 06 Oct 2002 02:48:54 +0000 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi Michael, All, Here is the WE summary: division, division and even more division ;) SRT with radix 2 is definitely the way to go in our case. I found these two references that explain in details the trade offs: http://citeseer.nj.nec.com/rd/83262034%2C370636%2C1%2C0.25%2CDownload/http://citeseer.nj.nec.com/cache/papers/cs/3067/ftp:zSzzSzumunhum.stanford.eduzSztrzSzsrtcomplexity_TVLSI.pdf/oberman98minimizing.pdf http://citeseer.nj.nec.com/rd/83262034%2C477278%2C1%2C0.25%2CDownload/http://citeseer.nj.nec.com/cache/papers/cs/23488/ftp:zSzzSzumunhum.stanford.eduzSztrzSz12_liddicoat_a.pdf/high-performance-floating-point.pdf I guess you are planning to fit an iteration in one cycle so we maintain 1bit/iteration throughput. The only way that I see to acheive this, for larger chuncks than 8 bits, is using CSAs for partial reminder(PR) computation and archiving it in redundant form. On the other hand, this architecture probably would work pretty good for the SIMD datapath. I think you said that you a block diagram of the Divider you're designing. I would be glad to see it. If you could also incorporate the code you have in the repository on seul.org so I can be really up to date. By the way, I have a general question about SIMD registers. I have read in the manual that any 64 bit general purpose register would have a flag indicating if it is a SIMD register or not. how about the SIMD mode? i.e: 8x8 bits vs 4x16 bits vs 2x32 bits ? Are we assuming a default mode or any of the three is allowed? Dali Michael Riepe wrote: > On Sat, Oct 05, 2002 at 12:43:38PM +0000, Mohamed Ali Kilani wrote: > [...] > >>I am looking at SRT division with higher radix, like Radix-4 division >>which produces 2 bits at each iteration, or even radix-16 which produces >> 4 bits at each iteration. If the last solution could produce the 4 >>bits in 3 cycles for example given the adequate hardware, there is a >>gain (6 cycles of processing versus 8 cycles for 8 bits division). I am >>going to spend some time working through the implementation and try to >>get an idea of the critical path. > > > Radix-16 is probably the smallest size that can produce more bits than > it uses cycles. But the code will be rather complicated, compared to a > radix-2 SRT, and will take a lot of die space. > > >>>Compare-and-subtract, subtract-and-restore or non-restore algorithms will >>>work with chunk sizes > 8 bit, but they will take two cycles/bit because >>>the add/subtract subunit doesn't fit into a single pipeline stage. >>>They're fine for 8-bit operands but too expensive for larger chunks. >>>Cedric has written an 8-bit divider that is included in the latest >>>snapshot. >> >>I have seen it. The problem with these dividers is that the critical >>path is a add/sub which is impossible to handle in 6 gates delays for >>large chuncks. I am still not clear what speed do we want to acheive >>with this unit and what is exactly the hardware budget available. Also, >>do we need for example to handle 64 bits division as well as 2x32 bits >>division/ 4x16 bits/8x8 division SIMD style? > > > That's the goal, yes. Speed should be reasonable (that is, > approximately 1 bit/cycle). > > >>>Finally, iterative solutions (like Newton-Raphson) will not only be rather >>>slow (each step requires at least two successive arithmetic operations, >>>at least one of them being a multiplication), but may also produce >>>incorrect results due to limited precision (rounding errors). IMHO, >>>they're suited for FP division only. >> >>If we can afford a multiplier and an add/sub unit quick enough (to be >>precised), we can go with this solution since it doubles the precision >>at each iteration, getting a 64 bits precision is just 3 iterations(one >>iteration = how many cycles?, I will get this later) after we have an 8 >>bits precision. > > > You can count 6 cycles for a 64x64->128 bit multiplication, and 2 cycles > for 64-bit add/sub. Plus the Xbar cycles to transfer data to/from the > IDU and ASU units, since we're not going to duplicate them for division > (the multiplier is huge!). > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 6 14:37:14 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaC9-0000vn-00 for ; Mon, 07 Oct 2002 17:53:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:21 +0200 (CEST) Received: (qmail 9249 invoked by uid 0); 6 Oct 2002 11:25:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Oct 2002 11:25:45 -0000 Received: by moria.seul.org (Postfix) id 5A87B15E79D; Sun, 6 Oct 2002 07:25:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5348A15E7A2; Sun, 6 Oct 2002 07:25:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id D03A615E79D for ; Sun, 6 Oct 2002 07:25:41 -0400 (EDT) Received: from f-cpu.org (kro1-169.n.club-internet.fr [213.44.93.169]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 9557816C1 for ; Sun, 6 Oct 2002 13:25:39 +0200 (CEST) Message-ID: <3DA02E7A.7010005@f-cpu.org> Date: Sun, 06 Oct 2002 13:37:14 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hello ! Mohamed Ali Kilani wrote: > Hi Michael, All, > By the way, I have a general question about SIMD registers. I have > read in the manual that any 64 bit general purpose register would have > a flag indicating if it is a SIMD register or not. how about the SIMD > mode? i.e: 8x8 bits vs 4x16 bits vs 2x32 bits ? Are we assuming a > default mode or any of the three is allowed? i am not sure to understand you, here. are you speaking about the internal units or the register set ? - The instructions contain 3 bits : 1 SIMD flag and 2 size flags - These flags are converted in any other necessary representation, for example 3-bit or 4-bit encoded, and sent to the EUs. - The register set does not contain flags about whether data is SIMD or not. there are flags indicating whether each register is a pointer (and whether it is a valid one) but that's all. I hope i answered your questions, > Dali YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Oct 6 14:40:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCC-0000vn-01 for ; Mon, 07 Oct 2002 17:53:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:24 +0200 (CEST) Received: (qmail 20731 invoked by uid 0); 6 Oct 2002 12:41:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Oct 2002 12:41:24 -0000 Received: by moria.seul.org (Postfix) id 515FE15E76F; Sun, 6 Oct 2002 08:41:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EACEB15E775; Sun, 6 Oct 2002 08:41:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 15B2C15E76F for ; Sun, 6 Oct 2002 08:41:22 -0400 (EDT) Received: from homeworld (81.48.95.154) by smtp.laposte.net (6.0.053) id 3D9887250008648B for f-cpu@seul.org; Sun, 6 Oct 2002 14:41:20 +0200 Message-ID: <000a01c26d35$93e4e0e0$c986fea9@homeworld> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] registers Date: Sun, 6 Oct 2002 14:40:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Sunday, October 06, 2002 2:37 PM Subject: Re: [f-cpu] registers > hello ! > > Mohamed Ali Kilani wrote: > > > Hi Michael, All, > > > > > By the way, I have a general question about SIMD registers. I have > > read in the manual that any 64 bit general purpose register would have > > a flag indicating if it is a SIMD register or not. how about the SIMD > > mode? i.e: 8x8 bits vs 4x16 bits vs 2x32 bits ? Are we assuming a > > default mode or any of the three is allowed? > > i am not sure to understand you, here. > are you speaking about the internal units or the register set ? > > - The instructions contain 3 bits : 1 SIMD flag and 2 size flags > - These flags are converted in any other necessary representation, > for example 3-bit or 4-bit encoded, and sent to the EUs. > - The register set does not contain flags about whether data is SIMD or not. > there are flags indicating whether each register is a pointer (and > whether > it is a valid one) but that's all. > okay, the SIMD flag is not stored in the register-bank but in the opcode of an instruction to tell the unit if it must compute in SIMD mode or not. for 64-bit architecture : add.8 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] add.32 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] add.64 R1,R2,R3 -> bit SIMD = 0 => R3[63..0] = R1[63..0] + R2[63..0] sadd.8 R1,R2,R3 -> bit SIMD = 1 => R3[7..0] = R1[7..0] + R2[7..0] and R3[15..8] = R1[15..8] + R2[15..8] and R3[23..16] = R1[23..16] + R2[23..16] and R3[31..24] = R1[31..24] + R2[31..24] ... and R3[63..56] = R1[63..56] + R2[63..56] sadd.16 R1,R2,R3 -> bit SIMD = 1 => R3[15..0] = R1[15..0] + R2[15..0] and R3[31..16] = R1[31..16] + R2[31..16] and R3[47..32] = R1[47..32] + R2[47..32] and R3[63..48] = R1[63..48] + R2[63..48] sadd.32 R1,R2,R3 -> bit SIMD = 1 => R3[31..0] = R1[31..0] + R2[31..0] and R3[63..32] = R1[63..32] + R2[63..32] Now do you understand better ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Oct 6 16:45:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCF-0000vn-00 for ; Mon, 07 Oct 2002 17:53:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:27 +0200 (CEST) Received: (qmail 2546 invoked by uid 0); 6 Oct 2002 14:46:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 6 Oct 2002 14:46:15 -0000 Received: by moria.seul.org (Postfix) id 7956915E772; Sun, 6 Oct 2002 10:46:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E2B115E77F; Sun, 6 Oct 2002 10:46:14 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 920EA15E772 for ; Sun, 6 Oct 2002 10:46:13 -0400 (EDT) Received: from homeworld (81.48.95.154) by smtp.laposte.net (6.0.053) id 3D98869B00086BE9 for f-cpu@seul.org; Sun, 6 Oct 2002 16:46:12 +0200 Message-ID: <001201c26d47$055cd230$c986fea9@homeworld> From: "Christophe Avoinne" To: Subject: Re: [f-cpu] registers Date: Sun, 6 Oct 2002 16:45:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N ----- Original Message ----- From: "Christophe Avoinne" To: Sent: Sunday, October 06, 2002 2:40 PM Subject: Re: [f-cpu] registers > Now do you understand better ? huh, I mean : Now do you undestand better how the SIMD bit works ? :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 6 18:09:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCG-0000vn-00 for ; Mon, 07 Oct 2002 17:53:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:28 +0200 (CEST) Received: (qmail 29993 invoked by uid 0); 6 Oct 2002 14:58:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 6 Oct 2002 14:58:28 -0000 Received: by moria.seul.org (Postfix) id 582AA15E775; Sun, 6 Oct 2002 10:58:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F20315E780; Sun, 6 Oct 2002 10:58:27 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id DB08215E775 for ; Sun, 6 Oct 2002 10:58:26 -0400 (EDT) Received: from f-cpu.org (kdl4-74.n.club-internet.fr [213.44.3.74]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 3A6EB1717 for ; Sun, 6 Oct 2002 16:58:24 +0200 (CEST) Message-ID: <3DA06055.4050004@f-cpu.org> Date: Sun, 06 Oct 2002 17:09:57 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> <3DA02E7A.7010005@f-cpu.org> <000a01c26d35$93e4e0e0$c986fea9@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Christophe Avoinne wrote: >>Mohamed Ali Kilani wrote: >> >>>Hi Michael, All, >>> >>> >> >> >> >> >>>By the way, I have a general question about SIMD registers. I have >>>read in the manual that any 64 bit general purpose register would have >>>a flag indicating if it is a SIMD register or not. how about the SIMD >>>mode? i.e: 8x8 bits vs 4x16 bits vs 2x32 bits ? Are we assuming a >>>default mode or any of the three is allowed? >>> >>> >>i am not sure to understand you, here. >>are you speaking about the internal units or the register set ? >> >>- The instructions contain 3 bits : 1 SIMD flag and 2 size flags >>- These flags are converted in any other necessary representation, >> for example 3-bit or 4-bit encoded, and sent to the EUs. >>- The register set does not contain flags about whether data is SIMD or not. >> >> >> there are flags indicating whether each register is a pointer (and >>whether >> it is a valid one) but that's all. >> > >okay, the SIMD flag is not stored in the register-bank but in the opcode of >an instruction to tell the unit if it must compute in SIMD mode or not. > > yup. >for 64-bit architecture : > >add.8 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] > > not exactly : it's R3[7..0] = R1[7..0] + R2[7..0] (copy-paste error ?) >add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] >add.32 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] >add.64 R1,R2,R3 -> bit SIMD = 0 => R3[63..0] = R1[63..0] + R2[63..0] > >sadd.8 R1,R2,R3 -> bit SIMD = 1 => R3[7..0] = R1[7..0] + R2[7..0] > and R3[15..8] = R1[15..8] + R2[15..8] > and R3[23..16] = R1[23..16] + R2[23..16] > and R3[31..24] = R1[31..24] + R2[31..24] > ... > and R3[63..56] = R1[63..56] + R2[63..56] > >sadd.16 R1,R2,R3 -> bit SIMD = 1 => R3[15..0] = R1[15..0] + R2[15..0] > and R3[31..16] = R1[31..16] + R2[31..16] > and R3[47..32] = R1[47..32] + R2[47..32] > and R3[63..48] = R1[63..48] + R2[63..48] > >sadd.32 R1,R2,R3 -> bit SIMD = 1 => R3[31..0] = R1[31..0] + R2[31..0] > and R3[63..32] = R1[63..32] + R2[63..32] > >Now do you understand better ? > > Now it should be even more clear :-) Concerning the flags that go to the units, they can be transcoded in the decoder. One is not forced to using the 3-bit field coming from the opcode, there are 2 clock cycles before the operation starts (decoder + Xbar) and it is enough to do the fanout and recoding. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 6 18:33:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCH-0000vn-00 for ; Mon, 07 Oct 2002 17:53:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:29 +0200 (CEST) Received: (qmail 3034 invoked by uid 0); 6 Oct 2002 15:21:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 6 Oct 2002 15:21:55 -0000 Received: by moria.seul.org (Postfix) id A94EF15E77F; Sun, 6 Oct 2002 11:21:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5EA2115E782; Sun, 6 Oct 2002 11:21:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 99A6615E77F for ; Sun, 6 Oct 2002 11:21:52 -0400 (EDT) Received: from f-cpu.org (kro1-216.n.club-internet.fr [213.44.93.216]) by relay-3v.club-internet.fr (Postfix) with ESMTP id B696E1716 for ; Sun, 6 Oct 2002 17:21:49 +0200 (CEST) Message-ID: <3DA065D5.7070802@f-cpu.org> Date: Sun, 06 Oct 2002 17:33:25 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> <3DA02E7A.7010005@f-cpu.org> <000a01c26d35$93e4e0e0$c986fea9@homeworld> <3DA06055.4050004@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hmmmmm maybe i hit "send" too quickly. Yann Guidon wrote: > hi ! > > Christophe Avoinne wrote: > >>> Mohamed Ali Kilani wrote: >>> >>>> Hi Michael, All, >>>> >>> >>>> >>> >> for 64-bit architecture : >> >> add.8 R1,R2,R3 -> bit SIMD = 0 => R3[7..0] = R1[7..0] + R2[7..0] > >> add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] >> add.32 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] >> add.64 R1,R2,R3 -> bit SIMD = 0 => R3[63..0] = R1[63..0] + R2[63..0] > One of the latest modifications was to solve the problems related to the MSB in the "partial write" cases. Maintaining the high part became a headache so we decided to clear it. Now we can write : add.8 R1,R2,R3 -> bit SIMD = 0 => R3[7..0] = R1[7..0] + R2[7..0] and R3[MSB..8] = 0 add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] and R3[MSB..16] = 0 and so on. Even though it might make some algorithms or programming habits more difficult to use, it removes a lot of pressure on the architecture and its scalability. And when these are necessary, shifts and ORs work without needing to mask things out. Clearing the MSB can occur at several places : the simplest one is on the register set's write ports. a simple row of AND gates do the trick. However, this creates problems when bypass occurs : the second execution unit gets data that is different from what is written to the register set. The second solution is to mask the EU's results out, but this adds a lot of AND gates all over the critical datapath. Another last solution is to put the ANDs on the read ports of the register set, trying to exploit some properties of the operations : 0 + 0 = 0 etc.... There are some exceptions (0 nor 0 = 1) and they can be found and trteated case by case. Finally, i think that these solutions will be used partially, in order to globally reduce the number of ANDs in the critical datapath. Solution 3 looks best. For the IDU, i don't know what solution is preferred. It is very specific because division by zero is not wanted. However, zero divided by something is zero. Maybe there are some particular cases that can be used in a smart way... I hope it is even more clearer now :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 6 14:13:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCd-0000vn-00 for ; Mon, 07 Oct 2002 17:53:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:51 +0200 (CEST) Received: (qmail 23011 invoked by uid 0); 6 Oct 2002 21:30:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 6 Oct 2002 21:30:44 -0000 Received: by moria.seul.org (Postfix) id 11CE915E785; Sun, 6 Oct 2002 17:30:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC56215E788; Sun, 6 Oct 2002 17:30:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id C94B215E785 for ; Sun, 6 Oct 2002 17:30:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00518; Sun, 6 Oct 2002 14:13:15 +0200 Message-ID: <20021006141315.36132@thrai.stud.uni-hannover.de> Date: Sun, 6 Oct 2002 14:13:15 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3D9FA496.9060403@m4x.org>; from Mohamed Ali Kilani on Sun, Oct 06, 2002 at 02:48:54AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Oct 06, 2002 at 02:48:54AM +0000, Mohamed Ali Kilani wrote: > Here is the WE summary: division, division and even more division ;) > > SRT with radix 2 is definitely the way to go in our case. I came to the same conclusion :) > I guess you are planning to fit an iteration in one cycle so we maintain > 1bit/iteration throughput. The only way that I see to acheive this, for > larger chuncks than 8 bits, is using CSAs for partial reminder(PR) > computation and archiving it in redundant form. > > On the other hand, this architecture probably would work pretty good for > the SIMD datapath. That's right. > I think you said that you a block diagram of the Divider you're > designing. I would be glad to see it. That was somebody else. But the picture is pretty simple: The operands are normalized and fed into the SRT core. cycles later, the core delivers -bit quotients and remainders, both in redundant form. If the remainders have the wrong sign, the result is corrected. Finally, the result is denormalized and converted back to normal binary encoding. > If you could also incorporate the code you have in the repository on > seul.org so I can be really up to date. It's not finished yet, and I never release code that doesn't work. > By the way, I have a general question about SIMD registers. I have read > in the manual that any 64 bit general purpose register would have a flag > indicating if it is a SIMD register or not. how about the SIMD mode? No, that's wrong. Instructions have a SIMD flag, but not registers. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Mon Oct 7 01:51:15 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCg-0000vn-00 for ; Mon, 07 Oct 2002 17:53:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:54 +0200 (CEST) Received: (qmail 32148 invoked by uid 0); 6 Oct 2002 23:51:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Oct 2002 23:51:22 -0000 Received: by moria.seul.org (Postfix) id C4AFC15E787; Sun, 6 Oct 2002 19:51:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A258F15E78A; Sun, 6 Oct 2002 19:51:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by moria.seul.org (Postfix) with ESMTP id 1499615E787 for ; Sun, 6 Oct 2002 19:51:21 -0400 (EDT) Received: (qmail 15832 invoked from network); 6 Oct 2002 23:51:21 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Oct 2002 23:51:21 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id B99C6C3 for ; Sun, 6 Oct 2002 16:54:14 -0700 (PDT) Message-ID: <3DA0CC73.5@m4x.org> Date: Sun, 06 Oct 2002 16:51:15 -0700 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> <3DA02E7A.7010005@f-cpu.org> <000a01c26d35$93e4e0e0$c986fea9@homeworld> <3DA06055.4050004@f-cpu.org> <3DA065D5.7070802@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann, I got the picture about the SIMD flag. It makes totally sense. Yann Guidon wrote: > hmmmmm maybe i hit "send" too quickly. > > Yann Guidon wrote: > > >>hi ! >> >>Christophe Avoinne wrote: >> >> >>>>Mohamed Ali Kilani wrote: >>>> >>>> >>>>>Hi Michael, All, >>>>> >>>> >>>>> >>>> >>>for 64-bit architecture : >>> >>>add.8 R1,R2,R3 -> bit SIMD = 0 => R3[7..0] = R1[7..0] + R2[7..0] >> >>>add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] >>>add.32 R1,R2,R3 -> bit SIMD = 0 => R3[31..0] = R1[31..0] + R2[31..0] >>>add.64 R1,R2,R3 -> bit SIMD = 0 => R3[63..0] = R1[63..0] + R2[63..0] >> > > One of the latest modifications was to solve the problems related to the MSB > in the "partial write" cases. Maintaining the high part became a headache > so we decided to clear it. > > Now we can write : > add.8 R1,R2,R3 -> bit SIMD = 0 => R3[7..0] = R1[7..0] + R2[7..0] > and R3[MSB..8] = 0 > add.16 R1,R2,R3 -> bit SIMD = 0 => R3[15..0] = R1[15..0] + R2[15..0] > and R3[MSB..16] = 0 > and so on. > > Even though it might make some algorithms or programming habits > more difficult to use, it removes a lot of pressure on the architecture > and its scalability. And when these are necessary, shifts and ORs > work without needing to mask things out. > > > > Clearing the MSB can occur at several places : > the simplest one is on the register set's write ports. a simple row of > AND gates do the trick. However, this creates problems when bypass > occurs : the second execution unit gets data that is different from > what is written to the register set. > The second solution is to mask the EU's results out, but this > adds a lot of AND gates all over the critical datapath. > Another last solution is to put the ANDs on the read ports > of the register set, trying to exploit some properties of the > operations : 0 + 0 = 0 etc.... There are some exceptions > (0 nor 0 = 1) and they can be found and trteated case by case. Just one question here, The output of every EU is registered (stored in a FF) so the combinatorial path out of an EU is either the connection to a Xbar port or to a bypass network, unless I am missing something ... If this is right, I don't think an extra AND gate would hurt that path timing and make it critical at the design level. > > Finally, i think that these solutions will be used partially, > in order to globally reduce the number of ANDs > in the critical datapath. Solution 3 looks best. > For the IDU, i don't know what solution is preferred. > It is very specific because division by zero is not wanted. > However, zero divided by something is zero. > Maybe there are some particular cases that can be > used in a smart way... > > > > I hope it is even more clearer now :-) > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ______________________________________________________________________ > Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros > d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant > Dali ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Mon Oct 7 02:47:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17yaCi-0000vn-00 for ; Mon, 07 Oct 2002 17:53:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 07 Oct 2002 17:53:56 +0200 (CEST) Received: (qmail 13712 invoked by uid 0); 7 Oct 2002 00:47:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 7 Oct 2002 00:47:36 -0000 Received: by moria.seul.org (Postfix) id 80B9315E781; Sun, 6 Oct 2002 20:47:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3CB1115E78C; Sun, 6 Oct 2002 20:47:35 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by moria.seul.org (Postfix) with ESMTP id 2AD5C15E781 for ; Sun, 6 Oct 2002 20:47:34 -0400 (EDT) Received: (qmail 4781 invoked from network); 7 Oct 2002 00:47:33 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Oct 2002 00:47:33 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id ED08BC3 for ; Sun, 6 Oct 2002 17:50:28 -0700 (PDT) Message-ID: <3DA0D9A4.4000604@m4x.org> Date: Sun, 06 Oct 2002 17:47:32 -0700 From: Mohamed Ali Kilani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <200210031118.285d@th00.opsion.fr> <00eb01c26ad3$db517e70$0100000a@homeworld> <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> <20021006141315.36132@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Michael, Michael Riepe wrote: >>I guess you are planning to fit an iteration in one cycle so we maintain >>1bit/iteration throughput. The only way that I see to acheive this, for >>larger chuncks than 8 bits, is using CSAs for partial reminder(PR) >>computation and archiving it in redundant form. >> >>On the other hand, this architecture probably would work pretty good for >>the SIMD datapath. > > > That's right. > Glad to see that we are on the same page. > >>I think you said that you a block diagram of the Divider you're >>designing. I would be glad to see it. > > > That was somebody else. But the picture is pretty simple: The operands > are normalized and fed into the SRT core. cycles later, the core > delivers -bit quotients and remainders, both in redundant form. > If the remainders have the wrong sign, the result is corrected. Finally, > the result is denormalized and converted back to normal binary encoding. > When you normalize operands, in which range do you keep the divisor? [-1/2,1/2]? How about "Quotient Selection" mecanism? Just compare PR to 0 and -1/2? How many bits do you use from the redundant representation to decide? Do you plan to add, let's say, the 4 MSB of the sum and carry representations of the PR and then compare it to -1/2 and 0? or use a 256x2 table/PLA to generate quotient digit? The PLA solution looks more efficient timing wise vs "small adder + one gate stage for decoding". Playing some tricks with the encoding would reduce its size and so keep its "access" time reasonable in order to acheive: Quotient Selection + D/Not(D) Mux Slection + CSA stages for PR computation + miscellaneous logic < 6 gates. I am just curious how do you manage to keep the critical path for an iteration under 6G/10T. Honnestly, I am having trouble doing it. :) > >>If you could also incorporate the code you have in the repository on >>seul.org so I can be really up to date. > > > It's not finished yet, and I never release code that doesn't work. > I would be glad to help as much as I can. > >>By the way, I have a general question about SIMD registers. I have read >>in the manual that any 64 bit general purpose register would have a flag >>indicating if it is a SIMD register or not. how about the SIMD mode? > > > No, that's wrong. Instructions have a SIMD flag, but not registers. > thanks to Christophe and Yann, I understand better the situation. Dali ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Oct 7 14:43:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ysUs-0004kX-00 for ; Tue, 08 Oct 2002 13:25:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Oct 2002 13:25:54 +0200 (CEST) Received: (qmail 14453 invoked by uid 0); 7 Oct 2002 17:19:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 7 Oct 2002 17:19:05 -0000 Received: by moria.seul.org (Postfix) id BB61015E797; Mon, 7 Oct 2002 13:19:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8C18315E7A3; Mon, 7 Oct 2002 13:19:04 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a049.home.uni-hannover.de [130.75.232.49]) by moria.seul.org (Postfix) with ESMTP id 68CEC15E797 for ; Mon, 7 Oct 2002 13:19:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00589; Mon, 7 Oct 2002 14:43:09 +0200 Message-ID: <20021007144308.21671@thrai.stud.uni-hannover.de> Date: Mon, 7 Oct 2002 14:43:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] registers References: <1033649177.3d9c3c1995063@imp.free.fr> <3D9CC8B6.5030701@m4x.org> <3D9D63A6.5070505@yahoo.fr> <3D9D5DB1.1080908@m4x.org> <20021004222233.55765@thrai.stud.uni-hannover.de> <3D9EDE7A.5050600@m4x.org> <20021006010221.29557@thrai.stud.uni-hannover.de> <3D9FA496.9060403@m4x.org> <20021006141315.36132@thrai.stud.uni-hannover.de> <3DA0D9A4.4000604@m4x.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=tKW2IUtsqtDRztdT X-Mailer: Mutt 0.84e In-Reply-To: <3DA0D9A4.4000604@m4x.org>; from Mohamed Ali Kilani on Sun, Oct 06, 2002 at 05:47:32PM -0700 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii On Sun, Oct 06, 2002 at 05:47:32PM -0700, Mohamed Ali Kilani wrote: [...] > When you normalize operands, in which range do you keep the divisor? > [-1/2,1/2]? Since I deal with integers of different sizes, the answer is a little bit more complex. First, I extend the operand by 1 bit (either 0 or a copy of the sign bit, depending on signed/unsigned mode). Then, I shift the operand left as much as possible without generating an overflow. That is, an unsigned divisor will be in the range [2^(n-1);2^n[, where is the chunk size in bits. > How about "Quotient Selection" mecanism? > Just compare PR to 0 and -1/2? I compare PR with 0, and if it's != 0, I compare the signs of the PR and the divisor. > How many bits do you use from the redundant representation to decide? Four digits. > Do you plan to add, let's say, the 4 MSB of the sum and carry > representations of the PR and then compare it to -1/2 and 0? or use a > 256x2 table/PLA to generate quotient digit? I use an encoding that makes comparision with 0 rather cheap. The sign bit is calculated by a small adder. > The PLA solution looks more efficient timing wise vs "small adder + one > gate stage for decoding". Playing some tricks with the encoding would > reduce its size and so keep its "access" time reasonable in order to > acheive: Quotient Selection + D/Not(D) Mux Slection + CSA stages for PR > computation + miscellaneous logic < 6 gates. I'm already in the 6 gate range. In fact, the decision logic (quotient selection) isn't a problem at all - it's the SIMD capability that is most timing critical. > I am just curious how do you manage to keep the critical path for an > iteration under 6G/10T. Honnestly, I am having trouble doing it. :) I use several tricks: - optimized encoding of the PR - precomputed PR(n+1) for all cases - I moved the pipeline register towards the middle of the SRT core I'll attach a copy of my latest working version of the core. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="srt64.vhdl" -- srt64.vhdl - SIMD SRT Divider Core -- Copyright (C) 2001, 2002 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- $Id$ library IEEE; use IEEE.std_logic_1164.all; use work.Bit_Manipulation.all; package SRT64 is -- 64-bit SIMD SRT procedure SRT64 (U, V, B : in std_ulogic_vector(79 downto 0); A : in std_ulogic_vector(63 downto 0); Size : in std_ulogic_vector(2 downto 0); U2, V2 : out std_ulogic_vector(79 downto 0); A2 : out std_ulogic_vector(63 downto 0); QP, QN : out std_ulogic_vector(7 downto 0)); end SRT64; package body SRT64 is -- decision logic procedure decide (U, V, B : in std_ulogic_vector(9 downto 0); P, D : out std_ulogic) is variable C : std_ulogic; begin -- p = '1' when remainder is zero (approximately) -- d=1 P := U(9) and U(8) and U(7) and U(6); -- carry for most significant bit -- d=2 C := V(8) or (U(8) and V(7)) or (U(8) and U(7) and V(6)); -- D = '1' when remainder/divisor signs differ (=> add) -- d=3 D := (B(9) xor U(9)) xor C; end decide; -- SRT core procedure slice (U, V, B : in std_ulogic_vector; A : in std_ulogic_vector; Ax : in std_ulogic; P, D : in std_ulogic; Ui, Vi, Xi0, Xi1 : in std_ulogic; Chain : in std_ulogic; U2, V2 : out std_ulogic_vector; Uo, Vo, Xo0, Xo1 : out std_ulogic) is constant L : natural := A'length; alias aa : std_ulogic_vector(L-1 downto 0) is A; variable uu, vv : std_ulogic_vector(L+1 downto 0); variable r0, r1 : std_ulogic_vector(L+1 downto 0); begin -- pragma synthesis_off assert U'length = L + 2; assert V'length = L + 2; assert B'length = L + 2; assert U2'length = L + 2; assert V2'length = L + 2; -- pragma synthesis_on -- left shift -- d=0 Uo := U(L-1); Vo := V(L-1); uu := lshift(U, 1); vv := lshift(V, 1); -- d=2 if to_X01(Chain) = '1' then uu(0) := Ui; vv(0) := Vi; else uu(0) := not Ax; -- Ax xor '1' vv(0) := Ax; -- Ax and '1' end if; -- CSA chaining outputs -- d=3 (worst case) Xo1 := vv(L-1) or (uu(L-1) and B(L-1)); Xo0 := vv(L-1) or (uu(L-1) and not B(L-1)); -- CSA core -- d=6 (worst case) if to_X01(P) = '1' then -- remainder is zero => do nothing null; elsif to_X01(D) = '1' then -- add B r0 := uu xor B; r1 := vv or (uu and B); r1 := lshift(r1, 1, Xi1 and Chain); uu := r0 xor r1; vv := r0 and r1; else -- subtract B r0 := uu xor not B; r1 := vv or (uu and not B); r1 := lshift(r1, 1, Xi0 or not Chain); uu := r0 xor r1; vv := r0 and r1; end if; -- outputs -- d=6 U2 := uu; V2 := vv; end slice; procedure SRT64 (U, V, B : in std_ulogic_vector(79 downto 0); A : in std_ulogic_vector(63 downto 0); Size : in std_ulogic_vector(2 downto 0); U2, V2 : out std_ulogic_vector(79 downto 0); A2 : out std_ulogic_vector(63 downto 0); QP, QN : out std_ulogic_vector(7 downto 0)) is variable ax, p, d, chain : std_ulogic_vector(7 downto 0); variable cu, cv, ca, cx0, cx1 : std_ulogic_vector(8 downto 0); variable aa : std_ulogic_vector(63 downto 0); begin -- decision logic for all chunks for i in 0 to 7 loop decide(U(10*i+9 downto 10*i), V(10*i+9 downto 10*i), B(10*i+9 downto 10*i), p(i), d(i)); end loop; -- SIMD result selector if to_X01(Size(2)) = '1' then d := (7 downto 0 => d(7)); p := (7 downto 0 => p(7)); elsif to_X01(Size(1)) = '1' then d := (7 downto 4 => d(7), 3 downto 0 => d(3)); p := (7 downto 4 => p(7), 3 downto 0 => p(3)); elsif to_X01(Size(0)) = '1' then d(6) := d(7); p(6) := p(7); d(4) := d(5); p(4) := p(5); d(2) := d(3); p(2) := p(3); d(0) := d(1); p(0) := p(1); end if; -- result output QP := d or p; QN := d and not p; -- chaining control vector chain := ( 7 => Size(0), 6 => Size(1), 5 => Size(0), 4 => Size(2), 3 => Size(0), 2 => Size(1), 1 => Size(0), 0 => '0' ); -- SRT slices cu(0) := '0'; cv(0) := '0'; ca(0) := '0'; cx0(0) := '0'; cx1(0) := '0'; for i in 0 to 7 loop -- range MUST be ascending! aa(8*i+7 downto 8*i) := lshift(A(8*i+7 downto 8*i), 1, ca(i) and chain(i)); ca(i+1) := A(8*i+7); end loop; if to_X01(Size(2)) = '1' then ax := (7 downto 0 => ca(8)); elsif to_X01(Size(1)) = '1' then ax := ( 7 downto 4 => ca(8), 3 downto 0 => ca(4) ); elsif to_X01(Size(0)) = '1' then ax := ( 7 downto 6 => ca(8), 5 downto 4 => ca(6), 3 downto 2 => ca(4), 1 downto 0 => ca(2) ); else ax := ca(8 downto 1); end if; for i in 0 to 7 loop -- range MUST be ascending! slice( U(10*i+9 downto 10*i), V(10*i+9 downto 10*i), B(10*i+9 downto 10*i), aa(8*i+7 downto 8*i), ax(i), p(i), d(i), cu(i), cv(i), cx0(i), cx1(i), chain(i), U2(10*i+9 downto 10*i), V2(10*i+9 downto 10*i), cu(i+1), cv(i+1), cx0(i+1), cx1(i+1) ); end loop; A2 := aa; end SRT64; end SRT64; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --tKW2IUtsqtDRztdT-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Oct 9 21:48:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zCk6-0001sb-01 for ; Wed, 09 Oct 2002 11:02:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 11:02:58 +0200 (CEST) Received: (qmail 22596 invoked by uid 0); 8 Oct 2002 19:46:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Oct 2002 19:46:37 -0000 Received: by moria.seul.org (Postfix) id 4473E15E71E; Tue, 8 Oct 2002 15:46:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2DB4C15E76A; Tue, 8 Oct 2002 15:46:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id D73FE15E71E for ; Tue, 8 Oct 2002 15:46:35 -0400 (EDT) Received: from Biathlon (vlt10-87.n.club-internet.fr [195.36.224.87]) by relay-4v.club-internet.fr (Postfix) with SMTP id 856B716A5 for ; Tue, 8 Oct 2002 21:46:15 +0200 (CEST) Date: Wed, 9 Oct 2002 21:48:05 +0200 From: nico To: f-cpu@seul.org Subject: [f-cpu] new pointer on simulator tool kit Message-Id: <20021009214805.241ea493.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N it's recommended from somebody of the gcc mailling list. http://www.simplescalar.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Oct 9 00:34:52 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zCk7-0001sb-00 for ; Wed, 09 Oct 2002 11:02:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 11:02:59 +0200 (CEST) Received: (qmail 19542 invoked by uid 0); 8 Oct 2002 21:23:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 8 Oct 2002 21:23:28 -0000 Received: by moria.seul.org (Postfix) id 8649E15E721; Tue, 8 Oct 2002 17:23:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0729215E76B; Tue, 8 Oct 2002 17:23:26 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id C2BDE15E721 for ; Tue, 8 Oct 2002 17:23:24 -0400 (EDT) Received: from f-cpu.org (kro1-82.n.club-internet.fr [213.44.93.82]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 5BC5A16E4 for ; Tue, 8 Oct 2002 23:23:18 +0200 (CEST) Message-ID: <3DA35D8C.20404@f-cpu.org> Date: Tue, 08 Oct 2002 23:34:52 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new pointer on simulator tool kit References: <20021009214805.241ea493.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! nico wrote: >it's recommended from somebody of the gcc mailling list. >http://www.simplescalar.com/ > oh, i think i saw it .... some years ago. did this evolve ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Oct 9 10:14:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zCkG-0001sb-00 for ; Wed, 09 Oct 2002 11:03:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 11:03:08 +0200 (CEST) Received: (qmail 30996 invoked by uid 0); 9 Oct 2002 07:02:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 9 Oct 2002 07:02:47 -0000 Received: by moria.seul.org (Postfix) id 04C0515E726; Wed, 9 Oct 2002 03:02:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD0B115E781; Wed, 9 Oct 2002 03:02:45 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 3AC0C15E726 for ; Wed, 9 Oct 2002 03:02:45 -0400 (EDT) Received: from f-cpu.org (kdl14-82.n.club-internet.fr [213.44.12.82]) by relay-2v.club-internet.fr (Postfix) with ESMTP id ED8C61698 for ; Wed, 9 Oct 2002 09:02:41 +0200 (CEST) Message-ID: <3DA3E55D.9020304@f-cpu.org> Date: Wed, 09 Oct 2002 09:14:21 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] F-CPU project and Debian Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, i just got a mail from Russell Coker and here is the answer i sent him. Your comments are welcome, maybe i wrote something silly.... However, before you flame me, please read until the end (the "white list" idea). --------------------------------------------------------------------- hello, ----Message d'origine---- >>De: Russell Coker >>A: whygee@f-cpu.org >>Sujet: f-cpu and Debian >>Date: Tue, 8 Oct 2002 10:48:31 +0200 >> >>I am a developer of Debian GNU/Linux. I like what your project is doing, >>while I can't commit any great amounts of time I would like to help out in a >>minor way if I can. >> >>Please tell me what can be added to Debian to make it a better platform for >>your f-cpu development work (and hopefully encourage Debian users to join >>your project). >> >>Anything that's not to difficult is something that I'll do myself. Anything >>that requires more time than I can spare I will post to the debian-devel list >>and hopefully someone else will be interested. >> > > I have used Debian (1 year ago) and respect the work of this great project. Now i use LFS on my own system (whenever i can) and i download all the sources for additional SW at the Debian repository. I am using and developping a fork of LFS3.3 and I find anything i need on debian.org :-) I have also seen that the Hurd kernel has been ported on Debian (or the contrary, who knows) and a FreeBSD support team started working on using this other kernel. This is a very good sign because F-CPU is probably underused under Linux and some parts of a kernel or another might need some changes. Debian seems to have undertaken a huge work to : - make a stable and reliable software base for linux - "ported" this base to the Hurd and other architecture So it is the most open, most portable and largest resource of Free software that i know and the F-CPU team members are often in contact with these communities so this is not a wonder for me that Debian is one of the preferred ways to go (even though it will not be easy all the time and i'll certainly use a LFS derivated system for my first runs). When using a different architecture, there are a lot of things to consider, particularly for such a large software base as Debian : - verify all the endianness problems in all packages (F-CPU is little endian but can work with big endian data : this might be a bit complex for network codes that are used to single-endian CPUs) - verify all the dependencies against architectural specific code (inlines, PCI stuffs, hardcoded addresses...) - verify that F-CPU idioms don't collide with existing ones (for example, the "FCPU_*" name space should be unused in all preprocessing directives and C/++ libraries) - examine all the bootstrap-related problems (F-CPU has no BIOS, but rather something that looks like the monitors of the SPARC or ALPHA computers) - create and verify new data types that are adapted to the F-CPU principles : UMAX, SMAX, FPTR ... (A certain F-CPU implementation instanciates a small part of the F-CPU specification, which states that the registers have a "default" width of 64 bits at program startup, but the hardware can be larger ...) [ read the F-CPU manual for more explanations ] Integer numbers can give rise to troubles if not used carefully, though it supports at least 8, 16, 32 and 64-bit wide data, and 64-bit pointers [though pointers should not have a size, but be defined just as : "up to as wide as a register"] A lot of these problems are linked to the compiler and we have not ported GCC decently yet. The other parts come from the way developers program .... And this is where the Debian project is of critical usefulness. Any company or structure could simply use GCC to recompile the existing applications and port their SW base to F-CPU. However F-CPU will be underused, particularly because most computers now are 32-bit ... F-CPU has more registers, much wider registers, more adressing range, and SIMD capabilities since the beginning, compared to a SPARC, MIPS-32 or x86 computer. Maybe most of the work can reuse MIPS-64 or ALPHA-specific code. But this will not be enough to exploit the SIMD operators and the potentially larger registers (a simple line in a configuration file is enough to make a 128-bit wide computer, or 256-bit, or any other power of two...). Recompilation is not enough to speed things up, some critical algorithms and coding practices must be reviewed. For example, glibc, mpeg and jpeg libraries, X (though i'd rather stick with DirectFB and XDirectFB...), network, etc. The kernel side will be a whole other project on its own and AFAIK it's not the main subject of concern for Debian. So if Debian can do something, the first is to inspect all the existing packages for conflicts or problems, in order to make a "F-CPU white list". To do this, there should be a coding advice list, but the above gives you an good idea. I am here if you need more help (though my paid job doesn't leave much time). When the "white list" is ready, the remaining packages can be examined and then modified more or less deeply, on a case by case basis. But this work will require that a working GCC port and a whole F-CPU simulator is ready (not yet, it's still going to take a long while). So the first thing to do is know which packages do not need modifications :-) i presume that it is going to take a while, asking all the package maintainers which of their package comply to some rules. Maybe we must write a survey and send it to all the maintainers ? You are free to copy this message wherever needed. You can also post technical questions to the english f-cpu mailing list. Best regards, >>Russell Coker > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Oct 9 10:58:36 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyP-0007N8-00 for ; Wed, 09 Oct 2002 19:50:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:17 +0200 (CEST) Received: (qmail 2942 invoked by uid 0); 9 Oct 2002 09:01:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Oct 2002 09:01:02 -0000 Received: by moria.seul.org (Postfix) id 9511A15E729; Wed, 9 Oct 2002 05:01:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 64CC215E785; Wed, 9 Oct 2002 05:01:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id C7D9915E729 for ; Wed, 9 Oct 2002 05:01:00 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix3-1.free.fr (Postfix) with ESMTP id 952ABDA05D for ; Wed, 9 Oct 2002 10:58:38 +0200 (MEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id D47F35803D; Wed, 9 Oct 2002 10:58:38 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU project and Debian Message-ID: <1034153916.3da3efbc57c38@imp.free.fr> Date: Wed, 09 Oct 2002 10:58:36 +0200 (MEST) From: Cedric BAIL References: <3DA3E55D.9020304@f-cpu.org> In-Reply-To: <3DA3E55D.9020304@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hi, > > i just got a mail from Russell Coker and here is the answer i sent > him. > Your comments are welcome, maybe i wrote something silly.... > However, before you flame me, please read until the end (the > "white list" idea). I don't know if it's this is a good idea to start from distribution, before having the CPU... or a simulator. Perhaps it will be a good idea if you can send me a list of new opcode/instruction for ROP2 before starting helping porting debian ;-) Or give me a pointer to your latest package. In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on a single processor what are the mnemonic and the option. I reread all instruction that use stream in the old manual, and I discover that if you specify the stream 0, it mean that it will use the last specified stream for this register. The question is what append if it wasn't specified ? (I think that we must say that stream 0 is like the other stream so that we didn't have any special strange case). In the same idea I will add the following instruction : loadz Rc, [Rm], Rd ... loadnz Rc, [Rm], Rd storez Rc, [Rm], Rd ... storenz Rc, [Rm], Rd And I will specify a new form for assembler : loadaddri Imm64, Rm Where Imm64 will be marked as a PC relative relocation, and it will be expanded like this : loadcons.0 Imm64 & 0xFFFF, Rm loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm loadaddr Rm, Rm If you want to specify something it will be a good idea to say it now. I am planning to post a prerelease for next week. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Oct 9 11:04:21 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyR-0007N8-00 for ; Wed, 09 Oct 2002 19:50:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:19 +0200 (CEST) Received: (qmail 8279 invoked by uid 0); 9 Oct 2002 09:04:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Oct 2002 09:04:47 -0000 Received: by moria.seul.org (Postfix) id 8CD4115E785; Wed, 9 Oct 2002 05:04:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4379C15E79B; Wed, 9 Oct 2002 05:04:44 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 72F3C15E785 for ; Wed, 9 Oct 2002 05:04:43 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210090904.153f; Wed, 9 Oct 2002 09:04:21 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] F-CPU project and Debian From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Oct 2002 09:04:21 GMT Message-id: <200210090904.153f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N As we design a risc cpu an asm instruction is supposed to al= ways take 32 bits. So i does it sound good to add the "." prefix to all m= acro ? To be more coherent maybe we have to keep the loadaddri without do= t. It's only a little detail... -----Message d'origine----- De: Cedric BAIL A: f-cpu@seul.org Date: 09/10/02 Objet: Re: [f-cpu] F-CPU project and Debian > hi, >=20 > i just got a mail from Russell Coker and here is the answe= r i sent > him. > Your comments are welcome, maybe i wrote something silly..= .. > However, before you flame me, please read until the end (t= he > "white list" idea). I don't know if it's this is a good idea to start from distr= ibution, before having the CPU... or a simulator. Perhaps it will be a good = idea if you can send me a list of new opcode/instruction for ROP2 before sta= rting helping porting debian ;-) Or give me a pointer to your latest packa= ge. In the same idea for the new instruction ll/sc for emulating= CAS/CAS2 on a single processor what are the mnemonic and the option. I reread all instruction that use stream in the old manual, = and I discover that if you specify the stream 0, it mean that it will use t= he last specified stream for this register. The question is what append if it = wasn't specified ? (I think that we must say that stream 0 is like the other st= ream so that we didn't have any special strange case). In the same idea I will add the following instruction : loadz Rc, [Rm], Rd ... loadnz Rc, [Rm], Rd storez Rc, [Rm], Rd ... storenz Rc, [Rm], Rd And I will specify a new form for assembler : loadaddri Imm64, Rm Where Imm64 will be marked as a PC relative relocation, and = it will be expanded like this : loadcons.0 Imm64 & 0xFFFF, Rm loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm loadaddr Rm, Rm If you want to specify something it will be a good idea to s= ay it now. I am planning to post a prerelease for next week. Cedric ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________ Etudiant: Wanadoo t'offre le Pack eXtense Haut D=E9bit soit = 150,92 euros d'=E9conomies ! Clique ici : http://www.ifrance.com/_reloc/m= ail.etudiant=20 ____________________________________________________________= __________ Exclusif: 75 euros rembours=E9s sur le pack eXtense Haut D=E9= bit de Wanadoo !=20 Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 17:29:31 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyZ-0007N8-00 for ; Wed, 09 Oct 2002 19:50:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:27 +0200 (CEST) Received: (qmail 22926 invoked by uid 0); 9 Oct 2002 10:30:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Oct 2002 10:30:29 -0000 Received: by moria.seul.org (Postfix) id E33D715E729; Wed, 9 Oct 2002 06:30:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADF1C15E781; Wed, 9 Oct 2002 06:30:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2671F15E729 for ; Wed, 9 Oct 2002 06:30:28 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 56A37170C; Wed, 9 Oct 2002 12:30:25 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU project and Debian Date: Wed, 9 Oct 2002 12:29:31 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 De: Cedric BAIL >> hi, >> = >> i just got a mail from Russell Coker and here is the answer i sent >> him. >> Your comments are welcome, maybe i wrote something silly.... >> However, before you flame me, please read until the end (the >> =22white list=22 idea). > > yep, but i hope it was not boring anyway :-P >I don't know if it's this is a good idea to start from distribution, befo= re >having the CPU... or a simulator. what i simply propose is to review the existing packages and have a first list of software that can be recompiled without modification (provided the libraries and compiler are adapted too). The package maintainers can indicate us what ports to ALPHA and SPARC-64 created problems and what kinds of problems they found. When the white list is done, we will have a first idea of what problems to solve, and what can be already used (recompiled) immediately. It is as simple as that for me. > Perhaps it will be a good idea if you can >send me a list of new opcode/instruction for ROP2 before starting helping >porting debian ;-) Or give me a pointer to your latest package. ouch.... can we meet this week-end ?... >In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on >a single processor what are the mnemonic and the option. i am currently investigating the idea (found in a discussion some months ago) of a LL/SC unit that would work a bit like the Load/Store Unit, but without the problems. >I reread all instruction that use stream in the old manual, and I discove= r >that if you specify the stream 0, it mean that it will use the last speci= fied >stream for this register. ?????????????????? it's not what i meant. stream 0 is the =22default=22 stream and that's all, there is no notion of a persistent state. Unless you have found a really good idea, which i would be pleased to read. > The question is what append if it wasn't specified ? >(I think that we must say that stream 0 is like the other stream so that >we didn't have any special strange case). The idea of a =22persistent default stream=22 has never come into my head. I have never found a case where this would be useful, so i never thought of it. Maybe your questions about streams and libraries (which i think can be answered in several ways) made you think about this eventuality ? >In the same idea I will add the following instruction : >loadz Rc, =5BRm=5D, Rd >.... >loadnz Rc, =5BRm=5D, Rd >storez Rc, =5BRm=5D, Rd >.... >storenz Rc, =5BRm=5D, Rd please mark this as preliminary and optional for now. The LSU design is not finished and the conditions could still change, maybe. >And I will specify a new form for assembler : >loadaddri Imm64, Rm > >Where Imm64 will be marked as a PC relative relocation, and it will be >expanded like this : >loadcons.0 Imm64 & 0xFFFF, Rm >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm >loadaddr Rm, Rm This is a macro, so it must be documented in the assembler's doc, not in the CPU doc... right ? >If you want to specify something it will be a good idea to say it now. I >am planning to post a prerelease for next week. I would like to add a small part about data types, formats, pointers, addressing spaces. however i don't think i have enough neurons to write it.... /o=5C >Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 17:45:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKya-0007N8-00 for ; Wed, 09 Oct 2002 19:50:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:28 +0200 (CEST) Received: (qmail 6670 invoked by uid 0); 9 Oct 2002 10:46:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Oct 2002 10:46:30 -0000 Received: by moria.seul.org (Postfix) id BBC6B15E74B; Wed, 9 Oct 2002 06:46:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 72EE015E785; Wed, 9 Oct 2002 06:46:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id E3F7915E74B for ; Wed, 9 Oct 2002 06:46:28 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-2v.club-internet.fr (Postfix) with SMTP id BFC4316A8; Wed, 9 Oct 2002 12:46:27 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] today's idea : JTAG console ! Date: Wed, 9 Oct 2002 12:45:33 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 are there some IC test specialists in this list ? how many people have used and programmed tools for the JTAG interface ? This synchronous interface uses a few wires and it's a wide-spread IEEE standard that is used to test PCB traces, IC internal units, program and check FPGAs, configure systems... There is a relatively good article about this in Elektor (available now in France) and there are many resources about this on the Net. Today's idea is to add an architecture-specific (shift) register that can be used to communicate with the core itself, without any need for serial RS232 ports etc. This JTAG register is split in 2 parts, one for writing and another for reading, so the host (whatever type) can send bytes to the CPU and the CPU can answer. Some kind of protocol must be defined (a flag must be used to specify if the last byte has been =22consumed=22 or =22read=22 by the target) but it will remain very simple. A more sophisticated SW layer can be made on this, allowing very simple debugging and development, either emulated, simulated or in HW, with very few efforts. Because it only needs 2 SRs and a few wires that are used for testing only, it requires very few HW resources and it is compatible with most existing test devices. I have already used (a bit) JTAG at the university but i don't trust their programs (which i believe to break most standards and good taste). So i would like to ask the listees whether they have used or programmed GPL'd code for JTAG ? Is somebody wanting to be responsible for the design of this unit and of the JTAG interface ? YG (sorry if this post is a bit messy) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Oct 9 13:08:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKye-0007N8-00 for ; Wed, 09 Oct 2002 19:50:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:32 +0200 (CEST) Received: (qmail 29745 invoked by uid 0); 9 Oct 2002 11:11:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 9 Oct 2002 11:11:37 -0000 Received: by moria.seul.org (Postfix) id 9B6E515E74B; Wed, 9 Oct 2002 07:11:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7ED7815E785; Wed, 9 Oct 2002 07:11:36 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from menator.dmz.valiosys.com (pblr1.valiosys.com [195.7.123.178]) by moria.seul.org (Postfix) with SMTP id E3A2615E74B for ; Wed, 9 Oct 2002 07:11:35 -0400 (EDT) Received: (qmail 18945 invoked by uid 85); 9 Oct 2002 11:00:09 -0000 Received: from illusion_to_net@yahoo.fr by menator.dmz.valiosys.com with qmail-scanner-1.00 (uvscan: v4.1.40/v4157. . Clean. Processed in 0.439272 secs); 09 Oct 2002 11:00:09 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by menator with SMTP; 9 Oct 2002 11:00:09 -0000 Message-ID: <3DA40E2B.7020101@yahoo.fr> Date: Wed, 09 Oct 2002 13:08:27 +0200 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] today's idea : JTAG console ! References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, The JTAG intreface can be a good point, but I think it's too early. First, because the JTAG is an On Board Test mechanism, then we need a full CPU (after production) and its board. Second, if we implement the FC0 into a FPGA, some of them have yet a JTAG interface implemented (or the code is given by tools). Third, if I well remember, you can find some yet done JTAG interface on net. Bye, Just an Illusion whygee@club-internet.fr a écrit: >hi ! > >are there some IC test specialists in this list ? >how many people have used and programmed tools >for the JTAG interface ? > >This synchronous interface uses a few wires and >it's a wide-spread IEEE standard that is used to >test PCB traces, IC internal units, program and check >FPGAs, configure systems... There is a relatively good >article about this in Elektor (available now in France) >and there are many resources about this on the Net. > >Today's idea is to add an architecture-specific >(shift) register that can be used to communicate >with the core itself, without any need for serial >RS232 ports etc. This JTAG register is split in >2 parts, one for writing and another for reading, >so the host (whatever type) can send bytes to the >CPU and the CPU can answer. Some kind of protocol >must be defined (a flag must be used to specify >if the last byte has been "consumed" or "read" by >the target) but it will remain very simple. > >A more sophisticated SW layer can be made on this, >allowing very simple debugging and development, >either emulated, simulated or in HW, with very few >efforts. Because it only needs 2 SRs and a few wires >that are used for testing only, it requires very few HW >resources and it is compatible with most existing test >devices. > >I have already used (a bit) JTAG at the university >but i don't trust their programs (which i believe >to break most standards and good taste). So i would like >to ask the listees whether they have used or programmed >GPL'd code for JTAG ? > >Is somebody wanting to be responsible for the design of >this unit and of the JTAG interface ? > >YG >(sorry if this post is a bit messy) > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Wed Oct 9 13:31:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyf-0007N8-00 for ; Wed, 09 Oct 2002 19:50:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:33 +0200 (CEST) Received: (qmail 12758 invoked by uid 0); 9 Oct 2002 11:31:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Oct 2002 11:31:09 -0000 Received: by moria.seul.org (Postfix) id 0232115E77F; Wed, 9 Oct 2002 07:31:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E392815E787; Wed, 9 Oct 2002 07:31:06 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id B403015E781; Wed, 9 Oct 2002 07:31:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id B23EE15E77F for ; Wed, 9 Oct 2002 07:31:06 -0400 (EDT) Date: Wed, 9 Oct 2002 07:31:06 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: Re: [f-cpu] today's idea : JTAG console ! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Oct 2002 whygee@club-internet.fr wrote: > hi ! > > are there some IC test specialists in this list ? > how many people have used and programmed tools > for the JTAG interface ? There's a discussion on jtag software/hardware (ie driver hardware, not the internal implementation) going on the the geda-dev mailing list archived at geda.seul.org at the moment - see the 'gtag' thread. You may find a link to relevant software there. Graham > > This synchronous interface uses a few wires and > it's a wide-spread IEEE standard that is used to > test PCB traces, IC internal units, program and check > FPGAs, configure systems... There is a relatively good > article about this in Elektor (available now in France) > and there are many resources about this on the Net. > > Today's idea is to add an architecture-specific > (shift) register that can be used to communicate > with the core itself, without any need for serial > RS232 ports etc. This JTAG register is split in > 2 parts, one for writing and another for reading, > so the host (whatever type) can send bytes to the > CPU and the CPU can answer. Some kind of protocol > must be defined (a flag must be used to specify > if the last byte has been "consumed" or "read" by > the target) but it will remain very simple. > > A more sophisticated SW layer can be made on this, > allowing very simple debugging and development, > either emulated, simulated or in HW, with very few > efforts. Because it only needs 2 SRs and a few wires > that are used for testing only, it requires very few HW > resources and it is compatible with most existing test > devices. > > I have already used (a bit) JTAG at the university > but i don't trust their programs (which i believe > to break most standards and good taste). So i would like > to ask the listees whether they have used or programmed > GPL'd code for JTAG ? > > Is somebody wanting to be responsible for the design of > this unit and of the JTAG interface ? > > YG > (sorry if this post is a bit messy) > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 18:31:13 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyf-0007N8-01 for ; Wed, 09 Oct 2002 19:50:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:33 +0200 (CEST) Received: (qmail 16939 invoked by uid 0); 9 Oct 2002 11:32:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Oct 2002 11:32:13 -0000 Received: by moria.seul.org (Postfix) id 4A4D215E781; Wed, 9 Oct 2002 07:32:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 14D6D15E78A; Wed, 9 Oct 2002 07:32:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C27A315E781 for ; Wed, 9 Oct 2002 07:32:08 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id 2B64116C3 for ; Wed, 9 Oct 2002 13:32:07 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] today's idea : JTAG console ! Date: Wed, 9 Oct 2002 13:31:13 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Just an Illusion > >Hi, > >The JTAG intreface can be a good point, but I think it's too early. i don't think so. Have you ever heard about =22DFT=22 ? not =22Discrete Fourier Transform=22 but =22Design For Test=22 :-) If F-CPU wants to be successful, it needs tests to be tightly integrated in the development. If we can extend some of the test functions, it's the right time now. I have already started investigating the BIST architecture, and integrating a JTAG core will help reduce duplicated functions. For example, BIST needs a pin to indicate whether the test failed or succeeded. JTAG defines this already :-) so no need to allocate one more pin. This is one example. >First, because the JTAG is an On Board Test mechanism, then we need a = >full CPU (after production) and its board. not necessarily =21 we can already simulate JTAG in VHDL and/or C, along with the whole core. This allows us to start developping the test SW. And JTAG is not =5Fonly=5F an =22On Board Test mechanism=22, it is used in many situations like non-intrusive debugging or performance measurements. For example, i have a book that deeply describes the way to access some of the MSRs of the Pentium CPU so an external computer can =22plug=22 some wires in the tested computer and read performance counters, HW status registers etc... Adding a couple of JTAG registers is not complex and helps solve some problems, like : what HW and SW interface do we use to communicate with the core and the EPROM when no keyboard, no RS232 and no screen is available ? This =22only=22 requires 2 SRs in the core and a simple (ACK-based ?) handshaking protocol. After all, it's not designed for performance but for portability and simplicity. >Second, if we implement the FC0 into a FPGA, some of them have yet a = >JTAG interface implemented (or the code is given by tools). yup but nothing keeps us from adding a parallel JTAG path inside the logic. Then the paths can be chained :-) this will reinforce confidence in the =22custom=22 JTAG code too. >Third, if I well remember, you can find some yet done JTAG interface on n= et. cool =21 =5BURL=5D ?... >Bye, >Just an Illusion Read you, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Oct 9 13:59:27 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyg-0007N8-00 for ; Wed, 09 Oct 2002 19:50:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:34 +0200 (CEST) Received: (qmail 7222 invoked by uid 0); 9 Oct 2002 11:54:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 9 Oct 2002 11:54:58 -0000 Received: by moria.seul.org (Postfix) id 4571515E787; Wed, 9 Oct 2002 07:54:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 37F5315E79B; Wed, 9 Oct 2002 07:54:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id D65A515E787 for ; Wed, 9 Oct 2002 07:54:56 -0400 (EDT) Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix3-2.free.fr (Postfix) with ESMTP id 5372717F23 for ; Wed, 9 Oct 2002 13:54:56 +0200 (CEST) Received: by imp3-1.free.fr (Postfix, from userid 33) id 8E448FA70; Wed, 9 Oct 2002 13:59:27 +0200 (MEST) To: f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU project and Debian Message-ID: <1034164767.3da41a1f5095c@imp.free.fr> Date: Wed, 09 Oct 2002 13:59:27 +0200 (MEST) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > When the white list is done, we will have a first idea > of what problems to solve, and what can be already used > (recompiled) immediately. It is as simple as that for me. In that case it can be very interesting for us to know that. > > Perhaps it will be a good idea if you can > >send me a list of new opcode/instruction for ROP2 before starting helping > >porting debian ;-) Or give me a pointer to your latest package. > ouch.... > can we meet this week-end ?... Sorry, I must go back to home (a stupid electrical problem with my server...) > >In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on > >a single processor what are the mnemonic and the option. > i am currently investigating the idea (found in a discussion > some months ago) of a LL/SC unit that would work a bit > like the Load/Store Unit, but without the problems. Hum, the question was : wich form ? > >I reread all instruction that use stream in the old manual, and I discover > >that if you specify the stream 0, it mean that it will use the last specified > >stream for this register. > ?????????????????? > > it's not what i meant. stream 0 is the "default" > stream and that's all, there is no notion of a > persistent state. Unless you have found a really > good idea, which i would be pleased to read. >From what I remember you can find this into this tex file : http://f-cpu.seul.org/cedric/F-CPU_manual-0.2.6-en/src/i7/Draft/Memory/loadi.tex > > The question is what append if it wasn't specified ? > >(I think that we must say that stream 0 is like the other stream so that > >we didn't have any special strange case). > The idea of a "persistent default stream" has never > come into my head. I have never found a case where this > would be useful, so i never thought of it. > Maybe your questions about streams and libraries > (which i think can be answered in several ways) > made you think about this eventuality ? No, from what I think it's a bad idea. > >In the same idea I will add the following instruction : > >loadz Rc, [Rm], Rd > >.... > >loadnz Rc, [Rm], Rd > >storez Rc, [Rm], Rd > >.... > >storenz Rc, [Rm], Rd > please mark this as preliminary and optional > for now. The LSU design is not finished and the > conditions could still change, maybe. I will mark it, like all the instruction that are not yet implemented as subject to change. > >And I will specify a new form for assembler : > >loadaddri Imm64, Rm > > > >Where Imm64 will be marked as a PC relative relocation, and it will be > >expanded like this : > >loadcons.0 Imm64 & 0xFFFF, Rm > >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm > >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm > >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm > >loadaddr Rm, Rm > This is a macro, so it must be documented in the > assembler's doc, not in the CPU doc... right ? False, "loadcons Imm64, Rd" is in the manual, and I think it must stay in the manual for compatible assembler. Same idea for loadaddr (NicO: I dont like the dot prefix for an instruction because it isn't really a macro, it must be treated by the assembler like a unique instruction for relocation). > >If you want to specify something it will be a good idea to say it now. I > >am planning to post a prerelease for next week. > I would like to add a small part about data types, > formats, pointers, addressing spaces. however i don't think > i have enough neurons to write it.... /o\ Write a simple .txt file and send it. I will do the rest. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From russell@coker.com.au Wed Oct 9 15:39:38 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyj-0007N8-00 for ; Wed, 09 Oct 2002 19:50:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:37 +0200 (CEST) Received: (qmail 9362 invoked by uid 0); 9 Oct 2002 13:39:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 9 Oct 2002 13:39:56 -0000 Received: by moria.seul.org (Postfix) id E420C15E7A4; Wed, 9 Oct 2002 09:39:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C634E15E7BE; Wed, 9 Oct 2002 09:39:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by moria.seul.org (Postfix) with ESMTP id 32BFD15E7A4 for ; Wed, 9 Oct 2002 09:39:54 -0400 (EDT) Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id EE13B92465; Wed, 9 Oct 2002 23:39:50 +1000 (EST) Received: from lyta (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id B72C2AE2E; Wed, 9 Oct 2002 15:39:38 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker To: whygee@club-internet.fr, f-cpu@seul.org Subject: Re: Re: [f-cpu] F-CPU project and Debian Date: Wed, 9 Oct 2002 15:39:38 +0200 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210091539.38280.russell@coker.com.au> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, 9 Oct 2002 17:29, whygee@club-internet.fr wrote: > >I don't know if it's this is a good idea to start from distribution, > > before having the CPU... or a simulator. > > what i simply propose is to review the existing packages > and have a first list of software that can be recompiled > without modification (provided the libraries and compiler > are adapted too). The package maintainers can indicate > us what ports to ALPHA and SPARC-64 created problems and > what kinds of problems they found. As mentioned in a previous message I think that the results for all this can already be found in the build daemon results: http://buildd.debian.org/ The stats page http://buildd.debian.org/stats/ shows the statistics of how many packages build on each platform (over 90% for every platform), and allows querying which packages don't build for each platform. > > Perhaps it will be a good idea if you can > >send me a list of new opcode/instruction for ROP2 before starting helping > >porting debian ;-) Or give me a pointer to your latest package. > > ouch.... > can we meet this week-end ?... I get the impression that the main developers are in France and Germany, maybe a meeting of FCPU people in the Netherlands would be a good. I could probably arrange some free and some cheap accomodation in Amsterdam... If a meeting was held to co-incide with a local computer users group then in return for a presentation they would probably put some money towards train fares. Let me know if there's interest in this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 20:49:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyk-0007N8-00 for ; Wed, 09 Oct 2002 19:50:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:38 +0200 (CEST) Received: (qmail 15057 invoked by uid 0); 9 Oct 2002 13:50:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 9 Oct 2002 13:50:10 -0000 Received: by moria.seul.org (Postfix) id D98BC15E78C; Wed, 9 Oct 2002 09:50:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7B5615E7BF; Wed, 9 Oct 2002 09:50:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 62BDA15E78C for ; Wed, 9 Oct 2002 09:50:08 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id 571B41708 for ; Wed, 9 Oct 2002 15:50:07 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Date: Wed, 9 Oct 2002 15:49:12 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >De: Cedric BAIL >> When the white list is done, we will have a first idea >> of what problems to solve, and what can be already used >> (recompiled) immediately. It is as simple as that for me. >In that case it can be very interesting for us to know that. :-) >> > Perhaps it will be a good idea if you can >> >send me a list of new opcode/instruction for ROP2 before starting help= ing >> >porting debian ;-) Or give me a pointer to your latest package. > >> ouch.... >> can we meet this week-end ?... > >Sorry, I must go back to home (a stupid electrical problem with my >server...) :-((( >> >In the same idea for the new instruction ll/sc for emulating CAS/CAS2 = on >> >a single processor what are the mnemonic and the option. > = >> i am currently investigating the idea (found in a discussion >> some months ago) of a LL/SC unit that would work a bit >> like the Load/Store Unit, but without the problems. > >Hum, the question was : wich form ? My proposition is : make a =22load locked=22 and =22store conditional=22 couple of instruction that is not related to the usual memory system (no streams, no size, no alignment etc). A bit like =22get=22 and =22put=22 but in a different addressing space (a 3rd one, after the memory space and the SR space). =22Load Locked=22 and =22Store conditional=22 take an =22address=22 (a handle that can be controlled by the kernel), an operand (a read (store) or write (load) register) and a result ( 0 =3D> ok, 1 =3D> retry (data was modified since last checkout), 2 =3D> wrong address...) adr val flag ll r1, r2, r3 =3D> checkout at address R1 then put the result in R2 and the status in r3 sc r1, r2, r3 =3D> checkin the value of R2 at address R1 and put the status in R3 = So a =22dumb=22 'locked add' would look like loopentry r1 ll r3, r4, r2 addi.64 r5, r4, r4 sc r3, r4, r2 loop r1, r2 (this adds r5 to the mutexed value which address is in r3) The advantage is that any number of values can be checked in and out at a time. By using a separate Execution Unit and a separate addressing space, all the collision worries and the race conditions are forgotten. However some protection measures are needed and the kernel must allocate a certain accessible range to the tasks. It is obvious, however, that the LSU tags can't be reused because the =22address=22 (or =22item number=22) is not a pointer to memory. To keep the format simple, i have put the =22address=22 in the first position (read only), the status result at the last position (write only) and the data in the middle (this field can also be written to, for example in the post-incremented loads) The principle of the unit that performs this operation will be a bit similar to the LSU but smaller and simpler. we could even start making it before the LSU. >> >I reread all instruction that use stream in the old manual, and I disc= over >> >that if you specify the stream 0, it mean that it will use the last sp= ecified >> >stream for this register. > = >> ?????????????????? >> = >> it's not what i meant. stream 0 is the =22default=22 >> stream and that's all, there is no notion of a >> persistent state. Unless you have found a really >> good idea, which i would be pleased to read. > >>From what I remember you can find this into this tex file : >http://f-cpu.seul.org/cedric/F-CPU=5Fmanual-0.2.6-en/src/i7/Draft/Memory/= loadi.tex oh i see : =22 Because of the width of the immediate data, there is no room to specify th= e = stream hint bits. It is therefore assumed that the processor will associat= e'' = the stream number with the pointer register thanks to a hidden status flag= =2E =22 hmm that's a real problem, indeed.... you were right. but it is not exactly the same thing as what you explained (=22stream 0 =3D last stream=22). >> > The question is what append if it wasn't specified ? >> >(I think that we must say that stream 0 is like the other stream so th= at >> >we didn't have any special strange case). > >> The idea of a =22persistent default stream=22 has never >> come into my head. I have never found a case where this >> would be useful, so i never thought of it. >> Maybe your questions about streams and libraries >> (which i think can be answered in several ways) >> made you think about this eventuality ? > >No, from what I think it's a bad idea. > >> >In the same idea I will add the following instruction : >> >loadz Rc, =5BRm=5D, Rd >> >.... >> >loadnz Rc, =5BRm=5D, Rd >> >storez Rc, =5BRm=5D, Rd >> >.... >> >storenz Rc, =5BRm=5D, Rd > = >> please mark this as preliminary and optional >> for now. The LSU design is not finished and the >> conditions could still change, maybe. > >I will mark it, like all the instruction that are not yet implemented as >subject to change. great =21 >> >And I will specify a new form for assembler : >> >loadaddri Imm64, Rm >> > >> >Where Imm64 will be marked as a PC relative relocation, and it will be >> >expanded like this : >> >loadcons.0 Imm64 & 0xFFFF, Rm >> >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm >> >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm >> >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm >> >loadaddr Rm, Rm > >> This is a macro, so it must be documented in the >> assembler's doc, not in the CPU doc... right ? > >False, =22loadcons Imm64, Rd=22 is in the manual, ???.... i thought there was only =22loadcons(x) imm16, rd=22 ? > and I think it must stay in >the manual for compatible assembler. Same idea for loadaddr (NicO: I dont >like the dot prefix for an instruction because it isn't really a macro, i= t >must be treated by the assembler like a unique instruction for relocation= ). > = >> >If you want to specify something it will be a good idea to say it now.= I >> >am planning to post a prerelease for next week. > = >> I would like to add a small part about data types, >> formats, pointers, addressing spaces. however i don't think >> i have enough neurons to write it.... /o=5C > >Write a simple .txt file and send it. I will do the rest. i won't promise anything.... but remember me often. Maybe there will be a time when i will be lucid enough to write something simple and clear... >A+ > Cedric read you soon, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Oct 9 16:09:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKym-0007N8-00 for ; Wed, 09 Oct 2002 19:50:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:40 +0200 (CEST) Received: (qmail 5220 invoked by uid 0); 9 Oct 2002 14:09:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 9 Oct 2002 14:09:34 -0000 Received: by moria.seul.org (Postfix) id 08AAF15E7B1; Wed, 9 Oct 2002 10:09:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C7E1A15E7BF; Wed, 9 Oct 2002 10:09:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 48DEF15E7B1 for ; Wed, 9 Oct 2002 10:09:33 -0400 (EDT) Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix3-2.free.fr (Postfix) with ESMTP id CCB6F17E29 for ; Wed, 9 Oct 2002 16:09:32 +0200 (CEST) Received: by imp2-2.free.fr (Postfix, from userid 33) id AE1BF8C0A1; Wed, 9 Oct 2002 16:09:32 +0200 (MEST) To: f-cpu@seul.org Subject: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Message-ID: <1034172572.3da4389c9daf4@imp.free.fr> Date: Wed, 09 Oct 2002 16:09:32 +0200 (MEST) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >> >In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on > >> >a single processor what are the mnemonic and the option. > >> i am currently investigating the idea (found in a discussion > >> some months ago) of a LL/SC unit that would work a bit > >> like the Load/Store Unit, but without the problems. > >Hum, the question was : wich form ? > > My proposition is : > It is obvious, however, that the LSU tags can't > be reused because the "address" (or "item number") > is not a pointer to memory. To keep the format simple, > i have put the "address" in the first position (read only), > the status result at the last position (write only) > and the data in the middle (this field can also be > written to, for example in the post-incremented loads) > The principle of the unit that performs this operation > will be a bit similar to the LSU but smaller and simpler. > we could even start making it before the LSU. Did we need to add a bit in the TLB entry to manage right on page for this unit ? I mean the VM must be able to create a page only for ll/sc to prevent normal load/store on it. > oh i see : > " > Because of the width of the immediate data, there is no room to specify > the > stream hint bits. It is therefore assumed that the processor will > associate'' > the stream number with the pointer register thanks to a hidden status > flag. > " > hmm that's a real problem, indeed.... you were right. > but it is not exactly the same thing as what you explained > ("stream 0 = last stream"). Right, I don't remember if it was exactly that or if it was somewhere else in the manual. When I have time I will to it. > >> > The question is what append if it wasn't specified ? > >> >(I think that we must say that stream 0 is like the other stream so that > >> >we didn't have any special strange case). But the question is still open. > >> >And I will specify a new form for assembler : > >> >loadaddri Imm64, Rm > >> > > >> >Where Imm64 will be marked as a PC relative relocation, and it will be > >> >expanded like this : > >> >loadcons.0 Imm64 & 0xFFFF, Rm > >> >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm > >> >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm > >> >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm > >> >loadaddr Rm, Rm > >> This is a macro, so it must be documented in the > >> assembler's doc, not in the CPU doc... right ? > >False, "loadcons Imm64, Rd" is in the manual, > ???.... i thought there was only "loadcons(x) imm16, rd" ? Oups, not in the 0.2.6, but 0.2.4/5 I think. That's not the problem in fact. We must provide in all assembler this "instruction" so that relocation are possible without it we will have a lot of problem. But in fact like what nicO say, we need an other syntax so that 16 bits versions can be forced. I will look to the one that reduce gperf colision and I think that we must specify this one. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Oct 9 17:55:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyp-0007N8-00 for ; Wed, 09 Oct 2002 19:50:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:43 +0200 (CEST) Received: (qmail 26488 invoked by uid 0); 9 Oct 2002 15:56:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 9 Oct 2002 15:56:30 -0000 Received: by moria.seul.org (Postfix) id 99E3615E7BF; Wed, 9 Oct 2002 11:56:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7020015E8AB; Wed, 9 Oct 2002 11:56:29 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id DCA7C15E7BF for ; Wed, 9 Oct 2002 11:56:28 -0400 (EDT) Received: from homeworld (81.48.49.2) by smtp.laposte.net (6.0.053) id 3D988725000DA0EA for f-cpu@seul.org; Wed, 9 Oct 2002 17:56:28 +0200 Message-ID: <002101c26fac$4d506e50$c986fea9@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Date: Wed, 9 Oct 2002 17:55:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N the original term of "ll" is "load-linked" and not "load locked". Indeed "lock" term is misused. We don't lock anything, we just set a bit to tell us later if an memory content is dirty or not. Executing the first "sc" on a "ll"-ed memory set this dirty bit to one to prevent following "sc" from success : no lock, just a status flag. Kinda of "safe-load" and "safe-store" indeed. ll r1,r2,r3 : what the purpose of storing a status in r3 ? which status ? is there any reasons to have it ? several "ll"s without "sc" don't harm at all, so what's its purpose ? just a addinational way to know if several "people" try to access the same memory, so we can have a different behavior if a previous "ll" on the same address has been set ? like a conditional load as spoken in one pdf about non-blocking syncs ? sc r1,r2,r3 : "checking the value of r2" ? what does that mean ? what you only need is to check the nodirty flag is still set when "sc" is executed so that r2 may be stored at address r1. r3 should just tell us whether the nodirty flag was set or not, that is, if r2 is stored. But your example looks correct, so I think it is just the way you explain which is disturbing, not the example :). What does that mean a separate address ? just a separate way to access data in SDRAM or just a special memory. Using a special memory is not appropriate for a large database of several GB : you would need a dynamic allocation of slots, to store them somewhere so you can read them in r1 before executing "ll r1,..." or "sc r1,...", etc. Not really a cool thing to handle, and memory accesses in SDRAM are not avoided since we still need to keep the slot number somewhere so objects can lock or unlock their access with their allocated slot number. By the way, you don't prevent the user code to read the content of slots allocated for kernel !!! it is a hole in the security. If you plan to forbid user code to allocate slots, well you are completely wrong,because you force user code to call kernel code... in any case, I don't see where it is the quickest way to execute "ll/sc" since you need other slowing workarounds to do to use them. If you are just speaking about a separate way to access data in SDRAM. Well, no virtualisation of memory, no right access. We still have a problem of security : user code or kernel code could read or change anything they want in SDRAM that way. As you can see, a separate address still leads to several problems that I'm not sure you did well consider as you should. ----- Original Message ----- From: To: Sent: Wednesday, October 09, 2002 5:49 PM Subject: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) My proposition is : make a "load locked" and "store conditional" couple of instruction that is not related to the usual memory system (no streams, no size, no alignment etc). A bit like "get" and "put" but in a different addressing space (a 3rd one, after the memory space and the SR space). "Load Locked" and "Store conditional" take an "address" (a handle that can be controlled by the kernel), an operand (a read (store) or write (load) register) and a result ( 0 => ok, 1 => retry (data was modified since last checkout), 2 => wrong address...) adr val flag ll r1, r2, r3 => checkout at address R1 then put the result in R2 and the status in r3 sc r1, r2, r3 => checkin the value of R2 at address R1 and put the status in R3 So a "dumb" 'locked add' would look like loopentry r1 ll r3, r4, r2 addi.64 r5, r4, r4 sc r3, r4, r2 loop r1, r2 (this adds r5 to the mutexed value which address is in r3) The advantage is that any number of values can be checked in and out at a time. By using a separate Execution Unit and a separate addressing space, all the collision worries and the race conditions are forgotten. However some protection measures are needed and the kernel must allocate a certain accessible range to the tasks. It is obvious, however, that the LSU tags can't be reused because the "address" (or "item number") is not a pointer to memory. To keep the format simple, i have put the "address" in the first position (read only), the status result at the last position (write only) and the data in the middle (this field can also be written to, for example in the post-incremented loads) The principle of the unit that performs this operation will be a bit similar to the LSU but smaller and simpler. we could even start making it before the LSU. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 22:59:43 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyq-0007N8-00 for ; Wed, 09 Oct 2002 19:50:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:44 +0200 (CEST) Received: (qmail 530 invoked by uid 0); 9 Oct 2002 16:00:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Oct 2002 16:00:44 -0000 Received: by moria.seul.org (Postfix) id 0AF3015E8A8; Wed, 9 Oct 2002 12:00:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C80DB15E8AE; Wed, 9 Oct 2002 12:00:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8E28E15E8A8 for ; Wed, 9 Oct 2002 12:00:41 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 7C58F16F8 for ; Wed, 9 Oct 2002 18:00:37 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Date: Wed, 9 Oct 2002 17:59:43 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi =21 >> >> >In the same idea for the new instruction ll/sc for emulating CAS/CA= S2 on >> >> >a single processor what are the mnemonic and the option. >> >> i am currently investigating the idea (found in a discussion >> >> some months ago) of a LL/SC unit that would work a bit >> >> like the Load/Store Unit, but without the problems. >> >Hum, the question was : wich form ? >> = >> My proposition is : > > >> It is obvious, however, that the LSU tags can't >> be reused because the =22address=22 (or =22item number=22) >> is not a pointer to memory. To keep the format simple, >> i have put the =22address=22 in the first position (read only), >> the status result at the last position (write only) >> and the data in the middle (this field can also be >> written to, for example in the post-incremented loads) >> The principle of the unit that performs this operation >> will be a bit similar to the LSU but smaller and simpler. >> we could even start making it before the LSU. > >Did we need to add a bit in the TLB entry to manage right on page >for this unit ? if a new addressing space is created, there is no need to care about the TLB entries... > I mean the VM must be able to create a page only >for ll/sc to prevent normal load/store on it. a different =22address space=22 is necessary because if a local CPU can prevent L/S, nothing prevents another CPU from not doing it... >> oh i see : >> =22 >> Because of the width of the immediate data, there is no room to specify >> the = >> stream hint bits. It is therefore assumed that the processor will >> associate'' = >> the stream number with the pointer register thanks to a hidden status >> flag. >> =22 > = >> hmm that's a real problem, indeed.... you were right. >> but it is not exactly the same thing as what you explained >> (=22stream 0 =3D last stream=22). > >Right, I don't remember if it was exactly that or if it was somewhere els= e >in the manual. at least you pointed to this page. > When I have time I will to it. ?... >> >> > The question is what append if it wasn't specified ? >> >> >(I think that we must say that stream 0 is like the other stream so= that >> >> >we didn't have any special strange case). >But the question is still open. huh lazy me :-) if the stream number is lost (through IRQ or a context switch) then the =22best=22 thing is to default to stream 0. >> >> >And I will specify a new form for assembler : >> >> >loadaddri Imm64, Rm >> >> > >> >> >Where Imm64 will be marked as a PC relative relocation, and it will= be >> >> >expanded like this : >> >> >loadcons.0 Imm64 & 0xFFFF, Rm >> >> >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm >> >> >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm >> >> >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm >> >> >loadaddr Rm, Rm > >> >> This is a macro, so it must be documented in the >> >> assembler's doc, not in the CPU doc... right ? > >> >False, =22loadcons Imm64, Rd=22 is in the manual, > = >> ???.... i thought there was only =22loadcons(x) imm16, rd=22 ? > >Oups, not in the 0.2.6, but 0.2.4/5 I think. That's not the problem in fa= ct. >We must provide in all assembler this =22instruction=22 so that relocatio= n >are possible without it we will have a lot of problem. But in fact like >what nicO say, we need an other syntax so that 16 bits versions can be fo= rced. ok. > I will look to the one that reduce gperf colision and I think that we >must specify this one. ARAARRRRGGGGHLHLLHH...... =22gperf collision=22.... forget about this and think more in terms of simplicity, rather than parsing speed.... gperf is not the only tool on Earth... >A+ > Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Oct 9 23:34:57 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zKyq-0007N8-01 for ; Wed, 09 Oct 2002 19:50:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 19:50:44 +0200 (CEST) Received: (qmail 10167 invoked by uid 0); 9 Oct 2002 16:35:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 9 Oct 2002 16:35:55 -0000 Received: by moria.seul.org (Postfix) id AD61F15E8AB; Wed, 9 Oct 2002 12:35:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9933815E8B3; Wed, 9 Oct 2002 12:35:53 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 1F47C15E8AB for ; Wed, 9 Oct 2002 12:35:53 -0400 (EDT) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-5v.club-internet.fr (Postfix) with SMTP id 2A41C1701; Wed, 9 Oct 2002 18:35:52 +0200 (CEST) Received: from [212.43.214.31] by flashmail-1v.club-internet.fr via html interface; From: whygee@club-internet.fr To: russell@coker.com.au, f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] F-CPU project and Debian Date: Wed, 9 Oct 2002 18:34:57 CEST Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi all =21 >De: Russell Coker >On Wed, 9 Oct 2002 17:29, whygee wrote: >> >I don't know if it's this is a good idea to start from distribution, >> > before having the CPU... or a simulator. >> >> what i simply propose is to review the existing packages >> and have a first list of software that can be recompiled >> without modification (provided the libraries and compiler >> are adapted too). The package maintainers can indicate >> us what ports to ALPHA and SPARC-64 created problems and >> what kinds of problems they found. > >As mentioned in a previous message I think that the results for all this = can = >already be found in the build daemon results: >http://buildd.debian.org/ > >The stats page http://buildd.debian.org/stats/ shows the statistics of ho= w = >many packages build on each platform (over 90% for every platform), and = >allows querying which packages don't build for each platform. cool graphics :-D >> > Perhaps it will be a good idea if you can >> >send me a list of new opcode/instruction for ROP2 before starting help= ing >> >porting debian ;-) Or give me a pointer to your latest package. >> >> ouch.... >> can we meet this week-end ?... > >I get the impression that the main developers are in France and Germany, This is not exclusive, some people are also in Belgium and Netherland (for example Jaap has written a big part of the C simulator). A lot of people are in France because a lot of articles have found their way in the french press... And France is a more centralized country, half of the people are in/around Paris, so it's easier to organise meetings... > maybe a meeting of FCPU people in the Netherlands would be a good. I co= uld = >probably arrange some free and some cheap accomodation in Amsterdam... It could be funny but after the last events at the huge LSM, i would prefer to go to a well-established, correctly organised place. I have my ticket for the 19C3 in Berlin. However if my job allows, i'll consider going to a meeting in Holland... Maybe some people from the Hurd, BSD and Debian teams can organise something in common with F-CPU so we could discuss all the porting issues... >If a meeting was held to co-incide with a local computer users group then= in = >return for a presentation they would probably put some money towards trai= n = >fares. > >Let me know if there's interest in this. We've discussed about some similar stuff after the last LSM. The problem is mostly with the structure/hosting and organisation... but it is definitely wanted. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Wed Oct 9 21:20:04 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zMou-0000Bg-01 for ; Wed, 09 Oct 2002 21:48:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Oct 2002 21:48:36 +0200 (CEST) Received: (qmail 9151 invoked by uid 0); 9 Oct 2002 19:20:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 9 Oct 2002 19:20:07 -0000 Received: by moria.seul.org (Postfix) id D0ABD15E720; Wed, 9 Oct 2002 15:20:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A93D015E8BD; Wed, 9 Oct 2002 15:20:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 3B9B815E720 for ; Wed, 9 Oct 2002 15:20:05 -0400 (EDT) Message-ID: <20021009192004.14684.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.115] by web14206.mail.yahoo.com via HTTP; Wed, 09 Oct 2002 12:20:04 PDT Date: Wed, 9 Oct 2002 12:20:04 -0700 (PDT) From: jaap stolk Subject: Re: Re: Re: [f-cpu] F-CPU project and Debian To: f-cpu@seul.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- whygee@club-internet.fr wrote: > Netherland (for example Jaap has written a big part > of the C simulator). ... and I’m still here... any ideas (recommendations) for the c-simulator yet ?? (I spend the last month reading HURD/Unununium/etc.) jaap. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Oct 9 22:38:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zOu0-0001a7-00 for ; Thu, 10 Oct 2002 00:02:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 00:02:00 +0200 (CEST) Received: (qmail 2353 invoked by uid 0); 9 Oct 2002 20:39:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 9 Oct 2002 20:39:04 -0000 Received: by moria.seul.org (Postfix) id B0EC815E77F; Wed, 9 Oct 2002 16:39:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E47815E8BE; Wed, 9 Oct 2002 16:39:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 0BD9815E77F for ; Wed, 9 Oct 2002 16:39:02 -0400 (EDT) Received: from homeworld (81.48.49.62) by smtp.laposte.net (6.0.053) id 3D9885F6000E0BE9 for f-cpu@seul.org; Wed, 9 Oct 2002 22:39:02 +0200 Message-ID: <002b01c26fd3$c65b73e0$c986fea9@homeworld> From: "Christophe Avoinne" To: References: <20021009192004.14684.qmail@web14206.mail.yahoo.com> Subject: Re: Re: Re: [f-cpu] F-CPU project and Debian Date: Wed, 9 Oct 2002 22:38:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Unununium ? is that project still existing ? ----- Original Message ----- From: "jaap stolk" To: Sent: Wednesday, October 09, 2002 9:20 PM Subject: Re: Re: Re: [f-cpu] F-CPU project and Debian > > --- whygee@club-internet.fr wrote: > > > > > Netherland (for example Jaap has written a big part > > of the C simulator). > > ... and I'm still here... > any ideas (recommendations) for the c-simulator yet ?? > (I spend the last month reading HURD/Unununium/etc.) > > jaap. > > > > > > __________________________________________________ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Oct 10 00:09:12 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zRdI-0003PA-01 for ; Thu, 10 Oct 2002 02:56:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 02:56:56 +0200 (CEST) Received: (qmail 31125 invoked by uid 0); 9 Oct 2002 22:09:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Oct 2002 22:09:13 -0000 Received: by moria.seul.org (Postfix) id 49C4715E753; Wed, 9 Oct 2002 18:09:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2725D15E8C0; Wed, 9 Oct 2002 18:09:12 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a079.home.uni-hannover.de [130.75.232.79]) by moria.seul.org (Postfix) with ESMTP id 3D59715E753 for ; Wed, 9 Oct 2002 18:09:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01124; Thu, 10 Oct 2002 00:09:12 +0200 Message-ID: <20021010000912.19594@thrai.stud.uni-hannover.de> Date: Thu, 10 Oct 2002 00:09:12 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) References: <1034172572.3da4389c9daf4@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1034172572.3da4389c9daf4@imp.free.fr>; from Cedric BAIL on Wed, Oct 09, 2002 at 04:09:32PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Wed, Oct 09, 2002 at 04:09:32PM +0200, Cedric BAIL wrote: [...] > > >> >And I will specify a new form for assembler : > > >> >loadaddri Imm64, Rm > > >> > > > >> >Where Imm64 will be marked as a PC relative relocation, and it will be > > >> >expanded like this : > > >> >loadcons.0 Imm64 & 0xFFFF, Rm > > >> >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm > > >> >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm > > >> >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm > > >> >loadaddr Rm, Rm > > > >> This is a macro, so it must be documented in the > > >> assembler's doc, not in the CPU doc... right ? > > > >False, "loadcons Imm64, Rd" is in the manual, > > > ???.... i thought there was only "loadcons(x) imm16, rd" ? > > Oups, not in the 0.2.6, but 0.2.4/5 I think. That's not the problem in fact. > We must provide in all assembler this "instruction" so that relocation > are possible without it we will have a lot of problem. But in fact like > what nicO say, we need an other syntax so that 16 bits versions can be forced. That's easy to solve: loadcons imm64, r1 can use an optimal representation while loadcons.0 imm16, r1 will always use the constant as-is. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Oct 10 02:26:00 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zRdK-0003PA-01 for ; Thu, 10 Oct 2002 02:56:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 02:56:58 +0200 (CEST) Received: (qmail 5965 invoked by uid 0); 9 Oct 2002 23:14:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Oct 2002 23:14:22 -0000 Received: by moria.seul.org (Postfix) id AE7B815E75B; Wed, 9 Oct 2002 19:14:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F0C415E8C1; Wed, 9 Oct 2002 19:14:21 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 07AB215E75B for ; Wed, 9 Oct 2002 19:14:21 -0400 (EDT) Received: from f-cpu.org (kro1-34.n.club-internet.fr [213.44.93.34]) by relay-4v.club-internet.fr (Postfix) with ESMTP id F0408169B for ; Thu, 10 Oct 2002 01:14:16 +0200 (CEST) Message-ID: <3DA4C918.60207@f-cpu.org> Date: Thu, 10 Oct 2002 01:26:00 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU project and Debian References: <20021009192004.14684.qmail@web14206.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! jaap stolk wrote: >--- whygee@club-internet.fr wrote: > > ouch ! :-) >>Netherland (for example Jaap has written a big part >>of the C simulator). >> >> > >.... and I'm still here... > yeah ! \o/ >any ideas (recommendations) for the c-simulator yet ?? > yes : it would be very, very, very good if you could recode/reprogram all the datapath to support "very wide words", that is : registers larger than 64 bits. Maybe a bunch of macros will do, but you know better than others where and how to use your code... When this is done, then the rest will be a bit easier. Then, the second step will be to completely synchronize the C and VHDL code, in order to write common testbenches and patter generators.... >(I spend the last month reading HURD/Unununium/etc.) > >jaap. > > > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Oct 10 09:43:33 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zdnR-000304-01 for ; Thu, 10 Oct 2002 15:56:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 15:56:13 +0200 (CEST) Received: (qmail 15736 invoked by uid 0); 10 Oct 2002 07:44:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 10 Oct 2002 07:44:11 -0000 Received: by moria.seul.org (Postfix) id C332515E7A4; Thu, 10 Oct 2002 03:44:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A91FE15E8D3; Thu, 10 Oct 2002 03:44:09 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (unknown [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 3A9A615E7A4 for ; Thu, 10 Oct 2002 03:44:09 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-1.free.fr (Postfix) with ESMTP id 442C2FD for ; Thu, 10 Oct 2002 09:43:33 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id 2CFEE873A0; Thu, 10 Oct 2002 09:43:33 +0200 (MEST) To: f-cpu@seul.org Subject: Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Message-ID: <1034235813.3da52fa51a215@imp.free.fr> Date: Thu, 10 Oct 2002 09:43:33 +0200 (MEST) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > >Did we need to add a bit in the TLB entry to manage right on page > >for this unit ? > if a new addressing space is created, there is no need to > care about the TLB entries... Hum, we have a problem here ! Cristophe mean yes and you say no. From what Cristophe say I think it's the best idea to put some info in the TLB. > > I mean the VM must be able to create a page only > >for ll/sc to prevent normal load/store on it. > a different "address space" is necessary because > if a local CPU can prevent L/S, nothing prevents > another CPU from not doing it... But all the other CPU will have the same TLB entry, because they run the same OS ! So that's not the problem. In fact the problem is that we must prevent the user code from accessing to super user data and read/modify it without authorisation => we absolutly need a mechanism like the TLB ! > if the stream number is lost (through IRQ or a context switch) > then the "best" thing is to default to stream 0. oki > > I will look to the one that reduce gperf colision and I think that we > >must specify this one. > ARAARRRRGGGGHLHLLHH...... "gperf collision".... > forget about this and think more in terms of simplicity, > rather than parsing speed.... gperf is not the only tool > on Earth... Yes, but if we create a hash table for all our asm instructions we must be aware about collision problem (actually we have around 200 collisions, compared to a x86 with fpu, sse, mmx, 3dnow it's really a lot because it only have 6 collisions !) and in fact it's only a little test, run gperf on f-cpu.perf and have the result ! Finally it didn't cost anything to us to test that before adding a new instruction/form to the manual, so why not testing it ? In fact the solution from michael didn't change anything in collision and it's clear so I will specify it. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Oct 10 10:16:39 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17zdnX-000304-00 for ; Thu, 10 Oct 2002 15:56:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 15:56:19 +0200 (CEST) Received: (qmail 27478 invoked by uid 0); 10 Oct 2002 13:13:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 10 Oct 2002 13:13:20 -0000 Received: by moria.seul.org (Postfix) id 1842A15E729; Thu, 10 Oct 2002 04:17:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D871815E8D8; Thu, 10 Oct 2002 04:17:05 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3468515E729 for ; Thu, 10 Oct 2002 04:17:05 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210100816.27b2; Thu, 10 Oct 2002 08:16:39 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Oct 2002 08:16:39 GMT Message-id: <200210100816.27b2@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >From an old speach, i remember that ll/sc couldn't be used f= or multi-cpu computer. Or it work if the teste are maid at the memory int= erface and not inside the cpu ? It should be great to think about the problem of having 2 me= mory bank on 2 differents cpus, so you could have the same virtual page o= n 2 separate physical page. You could manage such thing with managing the= write right and a kind of lock but what about ll/sc ? nicO (from my point of view, the cpu should always be seen to adr= ess a single flat adresse space that ease so much things !) -----Message d'origine----- De: Cedric BAIL A: f-cpu@seul.org Date: 10/10/02 Objet: Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project = and Debian) > >Did we need to add a bit in the TLB entry to manage right= on page > >for this unit ? > if a new addressing space is created, there is no need to > care about the TLB entries... Hum, we have a problem here ! Cristophe mean yes and you say= no. From what Cristophe say I think it's the best idea to put some info in= the TLB. =20 > > I mean the VM must be able to create a page only > >for ll/sc to prevent normal load/store on it. > a different "address space" is necessary because > if a local CPU can prevent L/S, nothing prevents > another CPU from not doing it... But all the other CPU will have the same TLB entry, because = they run the same OS ! So that's not the problem. In fact the problem is = that we must prevent the user code from accessing to super user data and = read/modify it without authorisation =3D> we absolutly need a mechanism lik= e the TLB ! > if the stream number is lost (through IRQ or a context swi= tch) > then the "best" thing is to default to stream 0. oki=20 > > I will look to the one that reduce gperf colision and I= think that we > >must specify this one. =20 > ARAARRRRGGGGHLHLLHH...... "gperf collision".... > forget about this and think more in terms of simplicity, > rather than parsing speed.... gperf is not the only tool > on Earth... Yes, but if we create a hash table for all our asm instructi= ons we must be aware about collision problem (actually we have around 20= 0 collisions, compared to a x86 with fpu, sse, mmx, 3dnow it's really a lo= t because it only have 6 collisions !) and in fact it's only a little test, ru= n gperf on=20 f-cpu.perf and have the result ! Finally it didn't cost anyt= hing to us to=20 test that before adding a new instruction/form to the manual= , so why not testing it ? In fact the solution from michael didn't change anything in = collision and it's clear so I will specify it. A+ Cedric ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________ Etudiant: Wanadoo t'offre le Pack eXtense Haut D=E9bit soit = 150,92 euros d'=E9conomies ! Clique ici : http://www.ifrance.com/_reloc/m= ail.etudiant=20 ____________________________________________________________= __________ Exclusif: 75 euros rembours=E9s sur le pack eXtense Haut D=E9= bit de Wanadoo !=20 Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Thu Oct 10 20:34:32 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ziqI-0006qJ-00 for ; Thu, 10 Oct 2002 21:19:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 21:19:30 +0200 (CEST) Received: (qmail 18383 invoked by uid 0); 10 Oct 2002 18:34:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Oct 2002 18:34:34 -0000 Received: by moria.seul.org (Postfix) id B507D15E8D8; Thu, 10 Oct 2002 14:34:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D05915E8DD; Thu, 10 Oct 2002 14:34:33 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id EC5A815E8D8 for ; Thu, 10 Oct 2002 14:34:32 -0400 (EDT) Message-ID: <20021010183432.82070.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.115] by web14206.mail.yahoo.com via HTTP; Thu, 10 Oct 2002 11:34:32 PDT Date: Thu, 10 Oct 2002 11:34:32 -0700 (PDT) From: jaap stolk Subject: [f-cpu] Unununium (was:F-CPU project and Debian) To: f-cpu@seul.org In-Reply-To: <002b01c26fd3$c65b73e0$c986fea9@homeworld> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --- Christophe Avoinne wrote: > Unununium ? is that project still existing ? no. but it's verly well documented, and it contains many very good ideas. the "cell"-structure is very much like the HURD "translator"-structure. there is also an interesting paper about why the project ended. the BRIX "Advanced Computing Environment" is somewhat similar. i'm also reading about hard-real-time compilers. jaap. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@artabel.net Thu Oct 10 20:34:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 17ziqJ-0006qJ-00 for ; Thu, 10 Oct 2002 21:19:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Oct 2002 21:19:31 +0200 (CEST) Received: (qmail 22299 invoked by uid 0); 10 Oct 2002 18:36:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Oct 2002 18:36:26 -0000 Received: by moria.seul.org (Postfix) id 91AD515E8DA; Thu, 10 Oct 2002 14:36:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71B9515E8DF; Thu, 10 Oct 2002 14:36:25 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 289E315E8DA for ; Thu, 10 Oct 2002 14:36:23 -0400 (EDT) Received: from mail.artabel.net (artabel.net1.nerim.net [62.212.107.173]) by kraid.nerim.net (Postfix) with ESMTP id 3170140E29 for ; Thu, 10 Oct 2002 20:27:22 +0200 (CEST) Received: from artabel.net (merlin.bel [192.168.1.34]) by mail.artabel.net (Postfix) with ESMTP id E49DC5A00 for ; Thu, 10 Oct 2002 20:36:45 +0200 (CEST) Message-ID: <3DA5C836.6070404@artabel.net> Date: Thu, 10 Oct 2002 20:34:30 +0200 From: Yann Guidon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Interesting O.C. News Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi there, As always, Graham did a very good work. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Oct 12 09:42:42 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180Ma1-0000F4-01 for ; Sat, 12 Oct 2002 15:45:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Oct 2002 15:45:21 +0200 (CEST) Received: (qmail 30716 invoked by uid 0); 12 Oct 2002 06:31:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 12 Oct 2002 06:31:03 -0000 Received: by moria.seul.org (Postfix) id 7667F15E72F; Sat, 12 Oct 2002 02:31:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 25AE815E74D; Sat, 12 Oct 2002 02:31:02 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 2664815E72F for ; Sat, 12 Oct 2002 02:31:01 -0400 (EDT) Received: from f-cpu.org (kdl4-89.n.club-internet.fr [213.44.3.89]) by relay-5v.club-internet.fr (Postfix) with ESMTP id D74D216AE for ; Sat, 12 Oct 2002 08:30:54 +0200 (CEST) Message-ID: <3DA7D272.60500@f-cpu.org> Date: Sat, 12 Oct 2002 08:42:42 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] spec draft about booting F-CPU Content-Type: multipart/mixed; boundary="------------000507030002050101030801" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------000507030002050101030801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hello, this is a first version. comments, enhancements, flaws... can be discussed on this list. have a nice day, YG --------------000507030002050101030801 Content-Type: text/plain; name="F-CPU_boot.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="F-CPU_boot.txt" http://f-cpu.seul.org/new/F-CPU_boot.txt created Sat Oct 12 01:15:53 CEST 2002 by whygee@f-cpu.org ************** In case you didn't know ************** F-CPU is a set of specifications that describe a family of microprocessors and their reference implementations. The Freedom CPU project is a community of volunteers that work on defining these specifications, write the reference source code, develop all the necessary files in order for F-CPU to become a serious and long-lasting alternative to the existing microprocessor families. ************** Introduction ************** This file contains a preliminary overview of the mechanisms used by F-CPU for "booting". - It covers BIST-time, monitor-time and kernel setup-time libraries, communications and troubleshooting. - It applies to a single CPU with a minimum number of external devices. Multi-CPU booting is not addressed yet and it must be handled at a higher level. - The goal of this "spec" is to be very simple to understand, to implement and to use on any implementation of F-CPU, whether as a software simulation, FPGA, Full-Custom and whatever the core family (not limited to FC0) - It covers a "least common denominator" way to start an operating system, providing enough features to allow extensions. ************** Requirements ************** This being said, here are the minimum requirements. This should be relatively easy to get, either in software, FPGA or ASIC. - a working F-CPU core (huh, not ready yet) - one or more external RAM interface (typically, SDRAM or any available or necessary technology) - EEPROM (probably FLASH with any necessary controller to handle fine-grained access) The interconnexion is not specified. However the access to the EEPROM must be transparent (to not require any preliminary configuration). In short, to implement this specification, you need only a few components that are easy to find and assemble. A FPGA starter kit's board should contain them and it's also the common parts of a minimum "F-CPU module". Finally, these different implementations should only need a single common debug and troubleshooting tool (this also reduces the coding efforts). ************** boot-time I/O channel ************** Starting an operating system (even minimal) on F-CPU requires 3 steps after power-up and/or reset : - BIST - initialisation from EEPROM - kernel initialisation and startup Before this finishes, there is _no_ way to communicate with outside devices or user, as there is no other device that has been initialised. Support of peripherals is not to be standardised and it is unwanted, as it would bloat the EEPROM and make this spec so complex that it would make it unimplementable. Support of video, disk, keyboard or network must be handled by additional, user-provided software, as these peripherals might not be implemented or can evolve. Yet, the 3 "init" steps require a means to report status and get commands from external tools (when necessary). This can be achieved by mapping a very simple character-based interface in the Special Register ("SR") space. This avoids the use of memory-mapped communication (difficult to track with an external probe, since the F-CPU core uses to cache things a lot) and is straight-forward to implement. It also remains independent from the external architecture and its evolutions. 2 SRs are created : [RO, 2 bits] SR_CONS_STATUS : contains handshaking bits [RW, 8 bits] SR_CONS_DATA : where the CPU reads or puts a byte. The chosen protocol is a handshake with some limited HW support. After BIST is successful, these special registers are reset to 0. The protocol is the same in both direction : the "sender" waits for the "data ready" flag to be cleared, then writes a byte in the data register. This action sets the "data ready" flag. The "receiver" waits for this flag to be set, and reads the data register : this resets the flag to 0. The set and reset are handled in hardware, thus reducing the protocol complexity a bit. Data in SR_CONS_DATA are "multiplexed" (from the core's point of view) : reading SR_CONS_DATA always returns the contents of the receive buffer, writing to it writes to the output buffer. These two buffers are independent and have a single handshake flag each. The two handshake flags are visible from both ends of the channel. | ----|----< DIN | | INTERNAL _____| | DATA BUS | | ----|----> DOUT | >From the F-CPU core's point of view, this is used with few instructions : read_char : loopentry r1; define the start of the wait loop get SR_CONS_STATUS, r2; read the handshaking flags andi 1, r2, r2; isolate the "data in ready" flag jmp.0 r2, r1; if nothing ready, try again (ok, i could have used the LSB condition) get SR_CONS_DATA, r2; read the input character (and clear the flag) write_char : loopentry r1; define the start of the wait loop get SR_CONS_STATUS, r2; read the handshaking flags andi 2, r2, r2; isolate the "data out ready" flag jmp.1 r2, r1; if buffer busy, try again put SR_CONS_DATA, r3; write the output character (and set the flag) This code implies that : - SR_CONS_DATA is 8-bit only - bit 0 of SR_CONS_STATUS is the "data in ready" flag and it is set to 1 when there is something to read - bit 1 of SR_CONS_STATUS is the "data out ready" flag and one can write when it is cleared (0). Other behaviours are undetermined and you are not encouraged to play with them (though i guess that this protocol will be enhanced, but it will loose its simplicity). The protocol is roughly the same for the "host", or whatever is connected to the other end of the channel. >From there, it is easy to write some more code that handles character buffers like a UNIX console, or whatever. Adding support for a timer will provide asynchronous communications, but it is out of the scope of this spec : the most important goal is that any software can interact with a user, or at least display booting information, before the classical I/O peripherals are initialised by an operating system. The hardware implementation is very simple from the SR side. It provides a 8+8+2-bits interface to the outside world, which can then be transmitted to a host using many kinds of links, including : - "parallel printer port" cable - RS-232 - JTAG - a named pipe or a /dev entry (thus providing a single interface to simulated, emulated or built versions) or it can simply remain disconnected. Otherwise, it provides a simple means to - output boot messages - debug low-level drivers - select a kernel (if a multiboot utility is written) - upload or download kernel images to/from EEPROM - or simply connect a dumb alphanumeric LCD + keypad Now that we can examine and control the CPU's activity, let's proceed to the real stuff : booting to some kernel, or whatever. ************** boot environment ************** Among all the golden rules that are necessary for F-CPU to never suffer from compatibility issues, one is : to never define a fixed memory address map. If there was a definition of a device mapped at a certain address, then the addition of devices would make software and hardware more complex in the future. All device mapping addresses and the control registers are mapped in the Special Register space, which does not communicate with the memory addressing space, thus ensuring fine-grained protection, simplifying the address decoders and keeping the pipelines from complex interactions with some configuration changes. Using SRs for defining the address map also helps when devices are hotswapped, for example. There is one exception, though : the instruction stream must start somewhere in the memory space and it is logical to start at address 0. Some architectures start at 0xFFFFFsomething, but F-CPU pointers have no MSB. Starting at address 0 ensures that any F-CPU compliant core can boot the same code without porting effort. The EEPROM is mapped from address 0x0 and there is no size limit. However the code it contains must know this size. No need to mention that all the protection bits are cleared and all the resources are available to the boot code. Another important fact concerning the booting environment is that upon booting, the core has no other temporary storage location than the register set. The EEPROM is read-only at this time, the cache is probably working but useless, and the external private RAM is not initialised. So the first thing to do, when starting at address 0, is to configure and initialize the RAM controller(s). It depends a lot on the available technology so it won't be described precisely. Let's hope that it is not too complex, though, so the 63 usable registers are enough. The boot code must detect the available SDRAM controllers through the SRs. There can be more than one SDRAM ports and some parts can be performed in parallel (for example when scanning the chips for integrity checking). For each controller, the boot code reads the HW parameters off the SDRAM chips and configures the controller to match these : size, number of banks, wait cycles, interleaving, precharge and most importantly : the base address. If there are several controllers, the base addresses must be contiguous. Then, turn the Dcache off and start writing and reading the RAM to check its integrity. Both the involved SR and the boot code can change in the future so the priority is to keep the interface clean and simple, rather than add more and more definitions. The goal is to have a cachable memory area at the end of this process. However i have mentioned in the introduction that this document doesn't address multi-CPU configuration. But the base address of the private memory areas must not collide with other processors ! There are several workarounds : - include the multi-CPU setup in the boot code ==> this would be superfluous because it's the kernel's job, and the boot code would become overly large. - assign a unique CPU number to each processor in the system (à la SHARC) to compute the base address ==> there would be collisions or holes if the system is not heterogeneous (not the same amount of RAM for all CPUs) and we would like the memory space to be contiguous (all the RAMs form a unique block) - include the memory configuration in the EEPROM (the base address would be computed by the kernel, then written to EEPROM) ==> the system configuration could change between 2 boots and would force to recompute the addresses (though it's unlikely) ==> Another problem is that the boot EEPROM could be used and read by several CPU at a time, the cores can't boot in parallel at the risk of mapping their RAMs to the same address --> boot must be serialised - some inter-CPU communication channel could be created and mapped to the SR ==> the protocol could be too complex and not portable, as it depends on the system's topology and the available HW Choose your camp, according on the system's design and environment. ************** bootstrapping some software ************** Now, the CPU can access the EEPROM and a contiguous area of faster RAM. The most important core's features are configured (IRQs are off, protection is disabled, etc.) and it's time to dig what's left in the EEPROM. All this process can be punctuated by messages sent to SR_CONS_DATA. This means that the EEPROM has some code that knows how to do this, a kind of a library that manages a dumb microconsole. To make life easier, this code can be reused by some other parts of the software remaining in the EEPROM. Another library manages the allocation of blocks in the private RAM. It's a kind of low-level malloc() and free() that can be used by other software, and that can use the microconsole code, for example, to output debug messages. The last library is a set of ROMFS-like low-level handling routines that can read files inside a simplified file system located in the EEPROM. This library requires malloc() functions provided by the memory library in order to load "files" to the RAM before executing binaries from there (the files in the F-ROMFS can be unaligned to save some space, and 256-bit versions will be rather stong about code and data alignment). The FROMFS code has been started already, but is not complete. All these things will certainly require trap handlers during development and debug, for example to catch invalid addresses, invalid opcodes or alignment faults to name a few possible coding errors. They can be removed later but are recommended in case a binary, as run off FROMFS, can contain flaws => the user will be happy to know why the computer hangs. These handlers can be replaced by other code before or when the kernel installs itself. When the RAM initialisation is completed, the code calls a function from the FROMFS library, asking to execute a file off the EEPROM, for example "runme.first". Then, the user's choice prevails. To sum up : the EEPROM contains 5 parts : - the initialisation code (init trap handlers+IRQ..., init SDRAM controller(s), then call FROMFS code) - the message printing/reading library - the memory allocation library - the fromfs library - the fromfs image The 4 first parts are provided by the F-CPU project, as well as some debugging tools and fromfs image manipulation software. They come more or less in that order. Since they are provided by F-CPU, they are "free software" and can be compiled by any user, so the entry points are known and can even be controlled. This means that the addresses of the functions depend on the version of the software, but it's not important because the symbol table can be easily exported and reused during the kernel's compilation. ************** other software ************** The FROMFS specification is described in a different file and it can change anyway, but it is primarily a dumb file system : each "file" is described with an entry in the file table. A name, some attributes, a size and an offset in the image are the minimal properties. >From there, the provided FROMFS library can locate, open and seek into a file given its name. Using the malloc library, a file can be loaded into RAM and then executed. This software can in turn execute some other software located in the FROMFS, load data files, allocate more memory, communicate with the user through the microconsole and more importantly : add new features and detect more devices to extend the reach of the software. The first possibility is to simply link a Linux kernel with the existing "libraries". The first messages will be output to the microconsole and the kernel will enumerate all the known devices before redirecting the messages to them. The rest of the story is well known. The same works with microkernels as well. Just name the kernel as "runme.first" or hardlink it. Another possibility is to choose between several kernels or kernel parameters, with software like GRUB or LILO. This would use the provided facilities to select the boot parameters and fetch the correct "file" from the EEPROM. The multiboot utility would be hardlinked to "runme.first" and each kernel image can keep a distinct name. However, in case no "microconsole" is connected, this might be less practical than expected. Some HW detection software, or "device driver", must be installed to allow GRUB to use the screen, the keyboard and any mass storage device. Then the device driver would be named "runme.first" but it is getting a bit complex now ! Some basic command or script interpreter can be programmed to run the desired software, in the order specified in a "file". Another eventuality is to exploit the microconsole as a communication link, and download an image to execute. Though it's a bit slow (the link is not designed for high-speed communication, with a maximum of 1M bit/s) it can spare some FLASH room in a large multi-CPU system or it can be used when developping new kernels (instead of writing to the EEPROM each time). There are certainly other possible uses, it is even possible to design a boot system like these of SPARC or ALPHA, but if this is not needed, it still works. ************** conclusion ************** This specification is very important both for the software and hardware development of the F-CPU project, which is still in its infancy and not completely determined. Defining a minimal "console port" and the necessary SRs is important when designing the core, this specification can influence the existing files but much care is taken to avoid any impact. The definition of the bootstrap procedure is also critical for the development of the first SW tools : simulator, emulator, debuggers, compilers and so much more. Making these tools independent from the target (SW or HW), providing a flexible, powerful and simple interface for booting a CPU, lowers the coding efforts and makes it suitable for more applications, but this keeps the architecture independent from them and can evolve without compatibility issue. Finally, these guidelines are open enough so that sombeody can code and boot whatever software he wants, whether it is a monolithic kernel, a microkernel, a custom application or simply a toy software. --------------000507030002050101030801-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sat Oct 12 23:29:06 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180ZA4-0002Jp-01 for ; Sun, 13 Oct 2002 05:11:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 05:11:24 +0200 (CEST) Received: (qmail 5758 invoked by uid 0); 12 Oct 2002 21:23:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 12 Oct 2002 21:23:43 -0000 Received: by moria.seul.org (Postfix) id CC5E815E75A; Sat, 12 Oct 2002 17:23:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B55E215E761; Sat, 12 Oct 2002 17:23:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by moria.seul.org (Postfix) with ESMTP id 5FF6315E75A for ; Sat, 12 Oct 2002 17:23:42 -0400 (EDT) Received: from computer ([209.214.154.24]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021012212524.XGAW1186.imf07bis.bellsouth.net@computer> for ; Sat, 12 Oct 2002 17:25:24 -0400 Message-ID: <000a01c27236$65804220$189ad6d1@computer> From: "richard hartny" To: Subject: [f-cpu] Bounce????? Date: Sat, 12 Oct 2002 16:29:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2720C.7BE9F760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2720C.7BE9F760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yann I don't understand what you want. The file is in Microsoft Word = format. Dick Hartney ------=_NextPart_000_0007_01C2720C.7BE9F760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yann
 
    I don't understand = what you=20 want.  The file is in Microsoft Word format.
 
Dick Hartney
------=_NextPart_000_0007_01C2720C.7BE9F760-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 13 01:07:11 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180ZA5-0002Jp-00 for ; Sun, 13 Oct 2002 05:11:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 05:11:25 +0200 (CEST) Received: (qmail 12491 invoked by uid 0); 12 Oct 2002 21:55:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Oct 2002 21:55:24 -0000 Received: by moria.seul.org (Postfix) id E014315E75E; Sat, 12 Oct 2002 17:55:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1B7415E762; Sat, 12 Oct 2002 17:55:23 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 90D8D15E75E for ; Sat, 12 Oct 2002 17:55:23 -0400 (EDT) Received: from f-cpu.org (kdl14-84.n.club-internet.fr [213.44.12.84]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 105AD16BA for ; Sat, 12 Oct 2002 23:55:21 +0200 (CEST) Message-ID: <3DA8AB1F.3060400@f-cpu.org> Date: Sun, 13 Oct 2002 00:07:11 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Bounce????? References: <000a01c27236$65804220$189ad6d1@computer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, richard hartny wrote: > Yann > > I don't understand what you want. The file is in Microsoft Word > format. > > Dick Hartney You have sent a file to the mailing list but it bounced because it is too large (there is a 50K limit per post) can you upload this file to a website so interested people can read it ? Another important remark : not all people (ie : me) can read Word files. Is a HTML version available ? Regards, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Oct 13 00:12:22 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180ZA6-0002Jp-00 for ; Sun, 13 Oct 2002 05:11:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 05:11:26 +0200 (CEST) Received: (qmail 32074 invoked by uid 0); 12 Oct 2002 22:12:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 12 Oct 2002 22:12:25 -0000 Received: by moria.seul.org (Postfix) id E7C5A15E760; Sat, 12 Oct 2002 18:12:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B77AD15E763; Sat, 12 Oct 2002 18:12:24 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a083.home.uni-hannover.de [130.75.232.83]) by moria.seul.org (Postfix) with ESMTP id B91E215E760 for ; Sat, 12 Oct 2002 18:12:21 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00634; Sun, 13 Oct 2002 00:12:22 +0200 Message-ID: <20021013001222.00464@thrai.stud.uni-hannover.de> Date: Sun, 13 Oct 2002 00:12:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Bounce????? References: <000a01c27236$65804220$189ad6d1@computer> <3DA8AB1F.3060400@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3DA8AB1F.3060400@f-cpu.org>; from Yann Guidon on Sun, Oct 13, 2002 at 12:07:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, Oct 13, 2002 at 12:07:11AM +0100, Yann Guidon wrote: > hi, > > richard hartny wrote: > > > Yann > > > > I don't understand what you want. The file is in Microsoft Word > > format. > > > > Dick Hartney > > > You have sent a file to the mailing list but it > bounced because it is too large (there is a 50K limit per post) > > can you upload this file to a website so interested people can > read it ? And please remember to convert it to an open format. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Oct 13 04:40:55 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180luq-0002Vk-00 for ; Sun, 13 Oct 2002 18:48:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:32 +0200 (CEST) Received: (qmail 9777 invoked by uid 0); 13 Oct 2002 09:54:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 13 Oct 2002 09:54:49 -0000 Received: by moria.seul.org (Postfix) id 4BF8815E761; Sun, 13 Oct 2002 05:54:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2BDD315E764; Sun, 13 Oct 2002 05:54:48 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id A0E0D15E761 for ; Sun, 13 Oct 2002 05:54:47 -0400 (EDT) Received: from gaia.bail.voulx.fr (nas-cbv-7-62-147-152-100.dial.proxad.net [62.147.152.100]) by postfix3-2.free.fr (Postfix) with ESMTP id 5FDB017F34 for ; Sun, 13 Oct 2002 11:54:42 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian) Date: Sun, 13 Oct 2002 04:40:55 +0200 User-Agent: KMail/1.4.3 References: <002101c26fac$4d506e50$c986fea9@homeworld> In-Reply-To: <002101c26fac$4d506e50$c986fea9@homeworld> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210130440.55948.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > ll r1,r2,r3 : > what the purpose of storing a status in r3 ? which status ? is there > any reasons to have it ? several "ll"s without "sc" don't harm at all, so > what's its purpose ? just a addinational way to know if several "people" > try to access the same memory, so we can have a different behavior if a > previous "ll" on the same address has been set ? like a conditional load as > spoken in one pdf about non-blocking syncs ? I am currently adding this instruction to the manual and it still not clear what r3 mean. If somebody can explain it so that I can add it to the manual. > sc r1,r2,r3 : > "checking the value of r2" ? what does that mean ? what you only need > is to check the nodirty flag is still set when "sc" is executed so that r2 > may be stored at address r1. r3 should just tell us whether the nodirty > flag was set or not, that is, if r2 is stored. > > But your example looks correct, so I think it is just the way you > explain which is disturbing, not the example :). I think that I will include it the manual. A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Oct 13 04:54:30 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180luq-0002Vk-01 for ; Sun, 13 Oct 2002 18:48:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:32 +0200 (CEST) Received: (qmail 12803 invoked by uid 0); 13 Oct 2002 09:54:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Oct 2002 09:54:51 -0000 Received: by moria.seul.org (Postfix) id D05AE15E763; Sun, 13 Oct 2002 05:54:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B406D15E766; Sun, 13 Oct 2002 05:54:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 5713115E763 for ; Sun, 13 Oct 2002 05:54:49 -0400 (EDT) Received: from gaia.bail.voulx.fr (nas-cbv-7-62-147-152-100.dial.proxad.net [62.147.152.100]) by postfix3-2.free.fr (Postfix) with ESMTP id 6E9AC17F4D for ; Sun, 13 Oct 2002 11:54:47 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU Date: Sun, 13 Oct 2002 04:54:30 +0200 User-Agent: KMail/1.4.3 References: <3DA7D272.60500@f-cpu.org> In-Reply-To: <3DA7D272.60500@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210130454.30355.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > hello, > > this is a first version. > comments, enhancements, flaws... can be discussed on this list. Really interresting in did, but I don't know if it's really a good idea to add so much thing in the SR. I mean they will be really slow and not easy to access from a kernel because it didn't exist on other architecture so it need a special work. > have a nice day, > YG A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 13 17:49:48 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180lv0-0002Vk-01 for ; Sun, 13 Oct 2002 18:48:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:42 +0200 (CEST) Received: (qmail 26170 invoked by uid 0); 13 Oct 2002 14:38:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 13 Oct 2002 14:38:03 -0000 Received: by moria.seul.org (Postfix) id 256B415E765; Sun, 13 Oct 2002 10:38:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DFBB415E76C; Sun, 13 Oct 2002 10:38:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 7574715E765 for ; Sun, 13 Oct 2002 10:38:01 -0400 (EDT) Received: from f-cpu.org (kro1-163.n.club-internet.fr [213.44.93.163]) by relay-5v.club-internet.fr (Postfix) with ESMTP id CF6BF16AB for ; Sun, 13 Oct 2002 16:37:58 +0200 (CEST) Message-ID: <3DA9961C.1090009@f-cpu.org> Date: Sun, 13 Oct 2002 16:49:48 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: >>hello, >> >>this is a first version. >>comments, enhancements, flaws... can be discussed on this list. >> >> > >Really interresting in did, but I don't know if it's really a good idea to add >so much thing in the SR. > It's the only place where it is suitable. In fact it has been designed for this purpose. Otherwise, if the configuration registers are mapped in main memory space, each CPU core will have to manage the sharing of this resource, because the memory space is shared and accessed by all CPUs in the system. Imagine what could happen if a remote CPU changes a protection bit.... The SRs are used to configure the (local) core and provide minimum I/O. The proposition of the "microconsole" only uses 2 SR entries and 18 bits at most. This is very few compared to the number of existing SRs (around 30 ?) defined in the existing source code, and we'll need even more if we want to control the TLB, the IRQ controller, the onchip SDRAM controller(s) etc.... and i forgot about providing some SRs (8) for "scratchpad" and performance counters... The management of the SR map is an important work (it must be centralised so independent modifications don't collide, for example if you want to add a SR and another function has been implemented at that address by someone else) but there are at least some failesafe protections, like the availability of a hardwired SR. > I mean they will be really slow and not easy to >access from a kernel because it didn't exist on other architecture so it need >a special work. > > now imagine the mess if it is mapped in memory... BTW, SRs are not meant to be fast or user-accessed (only SR_SIZE_xxx and the performance counters need to be accessed by the user applications in write mode). Concerning the kernels : if an "old" kernel runs on "new" CPU, then some functions will remain unused. If a "new" kernel runs on an "old" CPU, then the kernel will use only the provided functions. After all, Linux 2.4 still runs on i486, AFAIK. If two CPUs have a different SR map (which is not wanted but can happen), the kernel can update his SR map definition based on the signature provided by SR_NUMBERS, SR_FAMILY, SR_STEPPING and SR_URL. This is more or less what happens on the latest x86 computers, by the way (and one of the only things Intel did not completely fail to do). Yet, there remains many questions when using a multi-CPU system, either multiple cores on a chip or multiple-chip systems. Enumeration of the neighbours depends a lot on the topology and it is obvious that none must be favored. But without topology, no enumeration is possible, so what to do ? How can a booting CPU recognize that there are other CPUs in the system ? >>have a nice day, >>YG >> >> >A+ > Cedric > YG PS : Opencores.org seems to be down : anybody know what is going on ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From poster@seul.org Sun Oct 13 16:43:51 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180lv1-0002Vk-00 for ; Sun, 13 Oct 2002 18:48:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:43 +0200 (CEST) Received: (qmail 1136 invoked by uid 0); 13 Oct 2002 14:38:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 13 Oct 2002 14:38:32 -0000 Received: by moria.seul.org (Postfix) id F399515E766; Sun, 13 Oct 2002 10:38:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1E2215E76D; Sun, 13 Oct 2002 10:38:31 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from CVP (unknown [202.54.128.5]) by moria.seul.org (Postfix) with SMTP id EE8F915E766 for ; Sun, 13 Oct 2002 10:38:29 -0400 (EDT) InterScan-Notification: yes From: poster@seul.org To: "f-cpu@seul.org"@seul.org Subject: [f-cpu] Notification Date: Sun, 13 Oct 2002 20:13:51 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1034520231_B78506032.R82506026" Message-Id: <20021013143829.EE8F915E766@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_1034520231_B78506032.R82506026 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ************* eManager Notification ************** Sender, Content filter has detected a sensitive e-mail. Source mailbox: "f-cpu@seul.org" Destination mailbox(es): "f-cpu@seul.org" ******************* End of message ******************* ------=_NextPart_000_1034520231_B78506032.R82506026 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Received: from ([198.138.182.2]) by hexaware; Sun, 13 Oct 2002 20:04:44 +0530 (IST) Received: from ws_firewall ([192.168.16.2]) by mail.hexaware.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 13 Oct 2002 10:38:25 -0400 Received: from engine.ieee.org ([140.98.193.23]) by ws_firewall; Sun, 13 Oct 2002 -0700 (Pacific Daylight Time) Received: from orion3.ieee.org (gemini4.ieee.org [140.98.193.189]) by engine.ieee.org (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9DEc3v25723; Sun, 13 Oct 2002 10:38:03 -0400 (EDT) Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by orion3.ieee.org (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9DEc0q09576; Sun, 13 Oct 2002 10:38:00 -0400 (EDT) Received: by moria.seul.org (Postfix) id 256B415E765; Sun, 13 Oct 2002 10:38:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DFBB415E76C; Sun, 13 Oct 2002 10:38:01 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 7574715E765 for ; Sun, 13 Oct 2002 10:38:01 -0400 (EDT) Received: from f-cpu.org (kro1-163.n.club-internet.fr [213.44.93.163]) by relay-5v.club-internet.fr (Postfix) with ESMTP id CF6BF16AB for ; Sun, 13 Oct 2002 16:37:58 +0200 (CEST) Message-ID: <3DA9961C.1090009@f-cpu.org> Date: Sun, 13 Oct 2002 16:49:48 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Return-Path: owner-f-cpu-outgoing@seul.org X-OriginalArrivalTime: 13 Oct 2002 14:38:26.0242 (UTC) FILETIME=[307D8A20:01C272C6] ------=_NextPart_000_1034520231_B78506032.R82506026-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Oct 14 17:05:01 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180lv2-0002Vk-01 for ; Sun, 13 Oct 2002 18:48:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:44 +0200 (CEST) Received: (qmail 18350 invoked by uid 0); 13 Oct 2002 15:02:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 13 Oct 2002 15:02:52 -0000 Received: by moria.seul.org (Postfix) id 816D015E768; Sun, 13 Oct 2002 11:02:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F0D015E79C; Sun, 13 Oct 2002 11:02:50 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id BD12B15E768 for ; Sun, 13 Oct 2002 11:02:47 -0400 (EDT) Received: from Biathlon (vlt4-191.n.club-internet.fr [194.158.109.191]) by relay-4v.club-internet.fr (Postfix) with SMTP id B6A0E1682 for ; Sun, 13 Oct 2002 17:02:45 +0200 (CEST) Date: Mon, 14 Oct 2002 17:05:01 +0200 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU Message-Id: <20021014170501.253a02b5.nicolas.boulay@ifrance.com> In-Reply-To: <3DA9961C.1090009@f-cpu.org> References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sun, 13 Oct 2002 16:49:48 +0100 Yann Guidon wrote: > hi, > > cedric wrote: rdwired SR. > > > I mean they will be really slow and not easy to > >access from a kernel because it didn't exist on other architecture so it need > >a special work. > > > > > now imagine the mess if it is mapped in memory... I imagine it very well. All computer/microcontrolor/DSP work like that ! If cpu are design to use only one single bus (from the outside world) it's to add what ever you want peripheral. For sparc, there is an "SR" to change memory map so the tlb is accessed like that. A serial interface as nothing to do inside the cpu. It's a very slow thing, can't be remapped by an os, can't directly be accessed by user application. And most of all, why complicated a so simple thing that a rs232 peripheral ? You could even download it from opencores.com. Christophe could explain more about such thing, but from my point of view it's unusefull, and complicate things for nothing. nicO > >> > >> > >A+ > > Cedric > > > YG > > > PS : > Opencores.org seems to be down : anybody know what is going on ? > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ______________________________________________________________________ > Etudiant: Wanadoo t'offre le Pack eXtense Haut D_bit soit 150,92 euros > d'_conomies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Oct 14 17:23:08 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180lv3-0002Vk-00 for ; Sun, 13 Oct 2002 18:48:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 18:48:45 +0200 (CEST) Received: (qmail 17923 invoked by uid 0); 13 Oct 2002 15:20:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 13 Oct 2002 15:20:55 -0000 Received: by moria.seul.org (Postfix) id 6A5AA15E76D; Sun, 13 Oct 2002 11:20:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38DEA15E79F; Sun, 13 Oct 2002 11:20:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id C853615E76D for ; Sun, 13 Oct 2002 11:20:53 -0400 (EDT) Received: from Biathlon (vlt4-191.n.club-internet.fr [194.158.109.191]) by relay-5v.club-internet.fr (Postfix) with SMTP id 66A811685 for ; Sun, 13 Oct 2002 17:20:52 +0200 (CEST) Date: Mon, 14 Oct 2002 17:23:08 +0200 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU Message-Id: <20021014172308.7fad0f17.nicolas.boulay@ifrance.com> In-Reply-To: <3DA7D272.60500@f-cpu.org> References: <3DA7D272.60500@f-cpu.org> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N On Sat, 12 Oct 2002 08:42:42 +0100 Yann Guidon wrote: > hello, > > this is a first version. > comments, enhancements, flaws... can be discussed on this list. > > have a nice day, > YG > I don't understand the interrest of you're "SR interface". To begin to boot you need a programme to read, and for you, you need some thing to control the state of the booting cpu. What it is a humain ? An other system ? Why don't we use a single supid ROM interface (eeprom, what ever you want), even serial. A hw mecanisme copy the ROM to the memory and the cpu start execute the code at a predefined adress. Why reinvented the wheel ? If you want to check DRAM, you could start inside the cache memory. So you don't want to define a memory map like a working computer should do but you define a things sticked to the cpu silicon ? I don't understand why physical adress must be continuous ? virtual memory management should play is roll. So why such constraints ? Each cpu could have it's own eeprom that's not a problem at all. You could have a hardwire code to fixe the cpu numer. this number could be reread throught SR or memory. I stop reading the rest of the draft, it's to much... "deconnected to a reality". nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Oct 13 22:34:37 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 180oY5-0004DT-00 for ; Sun, 13 Oct 2002 21:37:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Oct 2002 21:37:13 +0200 (CEST) Received: (qmail 6280 invoked by uid 0); 13 Oct 2002 19:22:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 13 Oct 2002 19:22:52 -0000 Received: by moria.seul.org (Postfix) id 7F05A15E76F; Sun, 13 Oct 2002 15:22:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5AF3615E7A3; Sun, 13 Oct 2002 15:22:51 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id E75F815E76F for ; Sun, 13 Oct 2002 15:22:50 -0400 (EDT) Received: from f-cpu.org (kll1-166.n.club-internet.fr [213.44.91.166]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 17F05169C for ; Sun, 13 Oct 2002 21:22:46 +0200 (CEST) Message-ID: <3DA9D8DD.1020402@f-cpu.org> Date: Sun, 13 Oct 2002 21:34:37 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! it was only a matter of time before this "discussion" arises :-) nico wrote: >On Sun, 13 Oct 2002 16:49:48 +0100 >Yann Guidon wrote: > >>hi, >> >>cedric wrote: >> >> >>>I mean they will be really slow and not easy to >>>access from a kernel because it didn't exist on other architecture so it need >>>a special work. >>> >>now imagine the mess if it is mapped in memory... >> >> >I imagine it very well. All computer/microcontrolor/DSP work like that ! > > yup. for example, a microcontroller like the 8080 evolved into a 8086 and now, after several generations of standards and software and hardware abstraction layers, out PCs are some of the most complex things that are available on the free market. How many CDROMs are required to explain how your PC works "under the OS" ? Another example : 8086/8088 defines the interrupt table as starting at address 0 and spanning 1 K byte. Later, as i286 came, a "specific register" was created to change this address under SW control. Yet, even today, the first KBytes are reserved to IRQ and BIOS in "real mode", for "compatibility reasons". Wouldn't it be better if such resources were configurable, instead of defining a specific address ? This allows later implementations to not suffer from "early design choices". Why do you think the PCI standard allows device enumeration ?.... If i follow your logic, it's much easier to allocate an address for EVERY board that is built. yeah :-) Oh, btw, i have an answer that will probably be suitable for you : DSP- or microcontroller-based systems don't have to evolve and have less pressure on compatibility. This is probably why this old habit is still around. >If cpu are design to use only one single bus (from the outside world) it's to add what ever you want peripheral. > huh, i don't understand your english here.... > For sparc, there is an "SR" to change memory map so the tlb is accessed like that. > > can you elaborate, please ? >A serial interface as nothing to do inside the cpu. > who spoke about a serial interface ? are you speaking about the "microconsole"'s SRs ? this is a parallel interface, from the software point of view : you implement the hardware the way you want.It's up to you. You can even decide to not implement it, if you like. > It's a very slow thing, > the goal is not speed here. It should be obvious. Early developpers and users need a simple, low-level access to the boot code. On a PC, where the address map is "frozen" for a long while, it is possible to program a link though the parallel printer port, for example. the BIOS usually ouputs specific codes on this port, that show the progression of the BIOS setup, before the screen BIOS is executed. The problem here is not speed either, just to report useful information in case the BIOS is corrupt, a HW device doesn't work, or anything like that. On F-CPU it is not possible : F-CPU is not a PC, but a CPU core. it has no means to communicate with an external reporting device, unless you can afford to put a logic analyser on the outside bus. Furthermore, this means must be portable across implementations and families, so mapping the console to memory is not possible. What would happen if several CPU want to speak at the same time ?... Using a SR solves this problem. First, the SR map is the only area where a map is defined. Then, it is private to each CPU, so there is no multi-CPU worries. Finally, it is very easy to implement in HW and SW. You have the choice of the physical interface and you can use this for remote debugging or troubleshooting if your system fails. For example, if a PCB doesn't seem to work, it's possible to just plug a JTAG probe and see if the boot code had started, instead of plugging a logical analyzer on the bus. And what if it is a "SOC" and there is no external bus that can be probed ? > can't be remapped by an os, can't directly be accessed by user application. > > not the goal either. but it's funny : you use arguments here, but you claim the contrary in your first criticisms. >And most of all, why complicated a so simple thing that a rs232 peripheral ? > RS232 is "simple" ? you have to worry about all the protocol and stuffs like start, stop, parity, baud rate.... On the SW side, it's complex because it needs polling or interrupt code, and ACK is requires even more code. And defining that each F-CPU core must have a RS232 interface is like, huh, an overkill.... > You could even download it from opencores.com. > > yup (but it seems to be unreachable). so you want to map a full UART in the SRs ?......... >Christophe could explain more about such thing, but from my point of view it's unusefull, and complicate things for nothing. > > complex ? a pair of SRs with a straight-forward handshake protocol, what did i miss ? >>> hello, >>> >>> this is a first version. >>> comments, enhancements, flaws... can be discussed on this list. >>> >>> have a nice day, >>> YG >> >I don't understand the interrest of you're "SR interface". > For short (but i'm sure you know this already, though you seem to be very microcontroller-oriented), if some address or function is defined, it should be in the SR instead of being mapped in memory at a fixed address. If some device is memory-mapped, the mapping address must be configured in the SR. The memory addressing area is designed for high-speed storage, not for slow and blocking communications. BTW the text explains more than just SR stories. it also speaks about minimal contents of a boot code. >To begin to boot you need a programme to read, and for you, you need some thing to control the state of the booting cpu. What it is a humain ? An other system ? > > whatever is required. It can remain unplugged. But if the system fails, a user or developper can connect to this "port" to locate where the system hangs. Furthermore, there is another implication : As this interface is the same for SW-versions or silicon versions, this interface can be used to run regression tests and compare results automatically. For example, a simple program (let's say, a pocket calculator) can be running on the booted CPU without any other device driver. This program would be available in source code in the F-CPU source tree and compiled and run on the simulator. Then, regression tests can use a simple set of input patterns and errors could be detected by a "diff" with the expected answer. Later, when a silicon or other implementation is available, the same test can be run. >Why don't we use a single supid ROM interface (eeprom, what ever you want), even serial. A hw mecanisme copy the ROM to the memory and the cpu start execute the code at a predefined adress. Why reinvented the wheel ? If you want to check DRAM, you could start inside the cache memory. > > AFAIK, ALPHA does that. however, we can't rely on the structure of the caches in the future. It also implicitly limits the size of the booted code, what would happen if the cache is not large enough ?... It is also painful to design a cache that can be set by external HW. It is so easy to simply say : initialise the instruction pointer to 0 and let the cache do what it is meant to do. I believe it is simpler than having to design a HW that reads the external ROM and plays with the cache line entries (this design would be of course too much dependent on the external interface and the internal features). >So you don't want to define a memory map like a working computer should do but you define a things sticked to the cpu silicon ? > > what do you mean by "working computer" ?..... i'll try to answer the question that i have understood : i try to avoid the known causes of compatibility problems. And if it doesn't fit your needs, you can hack into the VHDL source and make your own boot code, if you want. >I don't understand why physical adress must be continuous ? virtual memory management should play is roll. So why such constraints ? > > when the CPU boots, VM and paging is not yet configured. continuous addresses are also so much simpler to manage than many scattered blocks, don't you think ? it makes the address decoders easier to design. But i'm sure you can find cases where scattered memory blocks are desirable :-) Now look at the computer you're currently using. it's a PC. I dont know how much RAM it has but mine has 288MB : one 32MB and 2x 128MB module. don't you think it's more complex to think about them as continuous ? Unless you want all modules to start on a gigabyte boundary... then, i don't think that the malloc and kernel codes will apreciate. >Each cpu could have it's own eeprom that's not a problem at all. > right. but it depends on the case and the application. For example, a dual CPU PC has only a single boot ROM. Maybe you can find examples where there is more, but at least you can find these dual CPU boards in the public stores in Paris. The first reason is to cut costs, another is compatibility with single-CPU systems. Now, F-CPU should have as few compatibility problems as possible, so the reason to choose whether a single ROM is used or not is not dependent on the CPU specification, but it depends on the context, on the price tag, on the scalability.... > You could have a hardwire code to fixe the cpu numer. > > this number could be reread throught SR or memory. > > i thought about this, too. however it's a static allocation thing and it doesn't answer all the questions. Currently, i think about using a "scratch SR" (a classical read-write location in SR space) to store the CPU number in the system. This can also be read from the PCB slot or something like that, during powerup. But it doesn't answer the question "how much RAM does the whole system contain" and "how is this RAM distributed", as we can't expect or assume that all CPUs have the same type and amount of RAM. And it also depends on how the chips are connected together. Sure, each CPU could have its own boot ROM with a dedicated code where the base address and RAM size is stored, for every CPU. But it can be more cost-efficient to have a single ROM, from which all CPUs boot, and also containing a table describing the memory layout (base address of each CPU etc). If there is a SR_CPU_NUMBER available, then each CPU can boot from the same code and initialise the DRAM base address by using the CPU number as an index in the memory layout table. I think it's the cleanest and simplest solutionn, because it doesn't specify a given number of PROM and CPU. It's also a weakness because it relies on the PROM to be up to date :-( But at least it requires a single SR_CPU_NUMBER (i hope that nicO will agree on this). Can i update the file to include this ? or do we want to troll a bit again before ? :-) >I stop reading the rest of the draft, it's to much... "deconnected to a reality". > > Maybe it's not a dirty enough hack ? have fun anyway, >nicO > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Oct 14 10:19:17 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1813YK-00064y-01 for ; Mon, 14 Oct 2002 13:38:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Oct 2002 13:38:28 +0200 (CEST) Received: (qmail 14060 invoked by uid 0); 14 Oct 2002 08:19:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Oct 2002 08:19:21 -0000 Received: by moria.seul.org (Postfix) id B035315E75E; Mon, 14 Oct 2002 04:19:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7713815E763; Mon, 14 Oct 2002 04:19:19 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id D8A6E15E75E for ; Mon, 14 Oct 2002 04:19:18 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id 0B6205F81E for ; Mon, 14 Oct 2002 10:19:18 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id E3CAA87342; Mon, 14 Oct 2002 10:19:17 +0200 (MEST) To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU Message-ID: <1034583557.3daa7e05cea39@imp.free.fr> Date: Mon, 14 Oct 2002 10:19:17 +0200 (MEST) From: Cedric BAIL References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> <3DA9D8DD.1020402@f-cpu.org> In-Reply-To: <3DA9D8DD.1020402@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > For short (but i'm sure you know this already, though you seem > to be very microcontroller-oriented), if some address or function is > defined, it should be in the SR instead of being mapped in memory > at a fixed address. If some device is memory-mapped, the mapping > address must be configured in the SR. The memory addressing area > is designed for high-speed storage, not for slow and blocking > communications. I really prefer to not put any "device" in the SR, but having their base address in it is really a good idea. Finally why did you want a micro-consol ? On some actual PC mainboard we have some LED that give us enough information about the booting process. To manage them a I2C bus will be enough and we still have one for the all the monitor interface (fan, temp, ...), so why defining a new interface, if some exist ? > >Why don't we use a single supid ROM interface (eeprom, what ever you > want), even serial. A hw mecanisme copy the ROM to the memory and the > cpu start execute the code at a predefined adress. Why reinvented the > wheel ? If you want to check DRAM, you could start inside the cache > memory. Why not having an eeprom directly mapped in the memory space so that we can directly access to it for the boot process (without copy process)? > >I don't understand why physical adress must be continuous ? virtual > memory management should play is roll. So why such constraints ? > when the CPU boots, VM and paging is not yet configured. Right, but they will be quickly activated when we need memory, and I hope that we didn't need more than 1 MB for the boot process ! > >Each cpu could have it's own eeprom that's not a problem at all. > right. but it depends on the case and the application. > For example, a dual CPU PC has only a single boot ROM. > Maybe you can find examples where there is more, but at least > you can find these dual CPU boards in the public stores in Paris. > The first reason is to cut costs, another is compatibility with > single-CPU systems. Now, F-CPU should have as few compatibility > problems as possible, so the reason to choose whether a single ROM > is used or not is not dependent on the CPU specification, but it > depends on the context, on the price tag, on the scalability.... Please, we must specify something, like the base address for boot, and where the boot code is accessible in memory, but not on which support. > If there is a SR_CPU_NUMBER available, then each CPU can boot > from the same code and initialise the DRAM base address by using the > CPU number as an index in the memory layout table. Your SR_CPU_NUMBER came from ? mainboard ? eeprom ? universe ? How long is it ? > I think it's the cleanest and simplest solutionn, because it doesn't > specify a given number of PROM and CPU. It's also a weakness > because it relies on the PROM to be up to date :-( > But at least it requires a single SR_CPU_NUMBER (i hope that nicO > will agree on this). Hum, like the PIII ?!? > Can i update the file to include this ? > or do we want to troll a bit again before ? :-) Isn't it possible to have a discussion ? You know all discussion are not troll ! A+ Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Oct 14 11:11:05 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1813YM-00064y-00 for ; Mon, 14 Oct 2002 13:38:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Oct 2002 13:38:30 +0200 (CEST) Received: (qmail 11044 invoked by uid 0); 14 Oct 2002 09:11:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 14 Oct 2002 09:11:16 -0000 Received: by moria.seul.org (Postfix) id 5F8BF15E729; Mon, 14 Oct 2002 05:11:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2026F15E761; Mon, 14 Oct 2002 05:11:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3C9E615E729 for ; Mon, 14 Oct 2002 05:11:14 -0400 (EDT) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200210140911.059f; Mon, 14 Oct 2002 09:11:05 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] spec draft about booting F-CPU From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Oct 2002 09:11:05 GMT Message-id: <200210140911.059f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 13/10/02 Objet: Re: [f-cpu] spec draft about booting F-CPU hi ! it was only a matter of time before this "discussion" arises= :-) nico wrote: >On Sun, 13 Oct 2002 16:49:48 +0100 >Yann Guidon wrote: > >>hi, >> >>cedric wrote: >> =20 >> >>>I mean they will be really slow and not easy to=20 >>>access from a kernel because it didn't exist on other arc= hitecture so it need=20 >>>a special work. >>> >>now imagine the mess if it is mapped in memory... >> =20 >> >I imagine it very well. All computer/microcontrolor/DSP wor= k like that ! > =20 > yup. for example, a microcontroller like the 8080 evolved in= to a 8086=20 and now, after several generations of standards and software and hard= ware=20 abstraction layers, out PCs are some of the most complex things that are availab= le on the=20 free market. How many CDROMs are required to explain how your PC works "u= nder the OS" ? Another example : 8086/8088 defines the interrupt table as s= tarting at=20 address 0 and spanning 1 K byte. Later, as i286 came, a "specific regi= ster" was=20 created to change this address under SW control. Yet, even today, th= e first=20 KBytes are reserved to IRQ and BIOS in "real mode", for "compatibility = reasons".=20 Wouldn't it be better if such resources were configurable, instead of= defining a=20 specific address ? This allows later implementations to not suffer from "early = design choices". >>>Hum ! We design a cpu not a computer ! That's all the dif= ference. There is an interrest to be enought configurable to remove a= nd add peripherals but when it's on silicon such flexibility as no = raison to exist. Read the LEON documentation, maybe you will better un= derstood... Why do you think the PCI standard allows device enumeration = ?.... If i follow your logic, it's much easier to allocate an addr= ess for EVERY board that is built. yeah :-) Oh, btw, i have an answer that will probably be suitable for= you : DSP- or microcontroller-based systems don't have to evolve a= nd have less pressure on compatibility. This is probably why this old hab= it is still=20 around. >>>No, if you fixed SR mapped it's even worst than fixed mem= ory map. It's almost the same but SR-map is not standard at all. >If cpu are design to use only one single bus (from the outs= ide world) it's to add what ever you want peripheral. > huh, i don't understand your english here.... >>>From tehorical point of view a cpu is seen as a black bos= that speak to the outer world thought a unique buses. If you break this= universal rules, you will cross very big theorical problem. > For sparc, there is an "SR" to change memory map so the tl= b is accessed like that. > =20 > can you elaborate, please ? >>>This is a configuration register where you change the adr= ess space of the chip. It's not a tlb. So for some register you could acc= ess the tlb or what ever things you want. >A serial interface as nothing to do inside the cpu. > who spoke about a serial interface ? are you speaking about = the=20 "microconsole"'s SRs ? this is a parallel interface, from the software point of vie= w : you=20 implement the hardware the way you want.It's up to you. You can even decide to not = implement=20 it, if you like. > It's a very slow thing, > the goal is not speed here. It should be obvious. Early developpers and users need a simple, low-level access to the boot code. On a PC, where the address map is "frozen" for a long while, it is possible to program a link though th= e parallel printer port, for example. the BIOS usually ouputs specific = codes on this port, that show the progression of the BIOS setup, b= efore the screen BIOS is executed. The problem here is not speed e= ither, just to report useful information in case the BIOS is corrup= t, a HW device doesn't work, or anything like that. >>>What ever you say or speak you always think PC ! For typi= cal embedded target, you have a cpu, an eeprom or a jtag link to full the= RAM of the cpu to boot, and a link like rs232. The "printf" of the libr= airy used inside knows how to use the rs232, it's like terms under lin= ux. On F-CPU it is not possible : F-CPU is not a PC, but a CPU c= ore. >>>So there is nothing to add more than jtag interface and d= ebuging facilities (like leon or ARM !!). Such interface are not see= n at all by the cpu and control directly it's beavior. It's not dependen= d on SW runnning on the cpu. it has no means to communicate with an external reporting de= vice, unless you can afford to put a logic analyser on the outside= bus. >>> :) begginner... jtag ? Furthermore, this means must be portable across implementati= ons and families, so mapping the console to memory is not possib= le. What would happen if several CPU want to speak at the same t= ime ?... >>>where is the problem ? You have one link per chip. If the= re many cpu on a chip, it will happen what happen when you launch many p= rograme on a linux term. It will mix the output. And where is the problem= ? Using a SR solves this problem. First, the SR map is the onl= y area where a map is defined. Then, it is private to each CPU, so = there is no multi-CPU worries. Finally, it is very easy to impleme= nt in >>> you don't even speak about multi-cpu ! HW and SW. You have the choice of the physical interface and you can use this for remote debugging or troubleshooting if your system fails. For example, if a PCB doesn't seem to = work, it's possible to just plug a JTAG probe and see if the boot = code had started, instead of plugging a logical analyzer on the bus. = And what if it is a "SOC" and there is no external bus that can be pr= obed ? >>>What do you think is used nowdays ? My DEA research proje= ct was about the problem of the programmability of SOC, 2 years ago. > can't be remapped by an os, can't directly be accessed by = user application. > =20 > not the goal either. but it's funny : you use arguments here, but you claim the c= ontrary in=20 your first criticisms. >>>? >And most of all, why complicated a so simple thing that a r= s232 peripheral ? > RS232 is "simple" ? you have to worry about all the protocol= and stuffs=20 like start, stop, parity, baud rate.... On the SW side, it's complex because it needs polling or int= errupt code, and ACK is requires even more code. And defining that each = F-CPU core must have a RS232 interface is like, huh, an overkill.... >>> ;) RSR232 is standard and used every where. > You could even download it from opencores.com. > =20 > yup (but it seems to be unreachable). so you want to map a full UART in the SRs ?......... >>>no SR. SR are for cpu stuff and stuff that is maid inside= the cpu for speed, like the memory and tlb management, that is all. >Christophe could explain more about such thing, but from my= point of view it's unusefull, and complicate things for nothing. > =20 > complex ? a pair of SRs with a straight-forward handshake pr= otocol, what did i miss ? >>>it will add things to the cpu that have nothing to do wit= h cpu. So it's a bloc that increase the complexity for nothing. >>> hello, >>>=20 >>> this is a first version. >>> comments, enhancements, flaws... can be discussed on thi= s list. >>>=20 >>> have a nice day, >>> YG >> >I don't understand the interrest of you're "SR interface". > For short (but i'm sure you know this already, though you se= em to be very microcontroller-oriented), if some address or fun= ction is defined, it should be in the SR instead of being mapped in m= emory at a fixed address. If some device is memory-mapped, the map= ping address must be configured in the SR. The memory addressing = area is designed for high-speed storage, not for slow and blockin= g=20 communications. >>>There is no real difference between fixed SR map and fixe= d memory map. SR map introduice a new adresse space that not have the= same capability than the memory interface.=20 BTW the text explains more than just SR stories. it also speaks about minimal contents of a boot code. >To begin to boot you need a programme to read, and for you,= you need some thing to control the state of the booting cpu. What it = is a humain ? An other system ? > =20 > whatever is required. It can remain unplugged. But if the system fails, a user or developper can connect to= this "port" to locate where the system hangs. >>>Jtag stuff ! Furthermore, there is another implication : As this interface is the same for SW-versions or silicon ver= sions, this interface can be used to run regression tests and compa= re results automatically. For example, a simple program (let's say, a p= ocket=20 calculator) can be running on the booted CPU without any other device dr= iver. >>> You want to add silicon to replace sw code !!!!!! That's= $^=F9*!:; ! This program would be available in source code in the F-CPU = source tree and compiled and run on the simulator. Then, regression test= s can use a simple set of input patterns and errors could be detected = by a "diff" with the expected answer. Later, when a silicon or other imp= lementation is available, the same test can be run. >Why don't we use a single supid ROM interface (eeprom, what= ever you want), even serial. A hw mecanisme copy the ROM to the memor= y and the cpu start execute the code at a predefined adress. Why reinv= ented the wheel ? If you want to check DRAM, you could start inside th= e cache memory.=20 > =20 > AFAIK, ALPHA does that. however, we can't rely on the structure of the caches in the= future. >>>You want to keep compatibility between new cpu and old pr= om boot ? *gni* It also implicitly limits the size of the booted code, what = would happen if the cache is not large enough ?... >>>boot code have very minimal things to do. He try to acces= s DRAM. And then use it. It is also painful to design a cache that can be set by exte= rnal HW. >>> ? It is so easy to simply say : initialise the instruction poi= nter to 0=20 and let the cache do what it is meant to do. I believe it is simpler than having to design a HW that read= s the=20 external ROM and plays with the cache line entries (this des= ign would be of course too much dependent on the external interface and t= he internal features). >So you don't want to define a memory map like a working com= puter should do but you define a things sticked to the cpu silicon ? > =20 > what do you mean by "working computer" ?..... >>> you want to add design constraint to a cpu like it is a = whole computer. Compatibility issue is more on access to the under= laying hardware rather than isa because the c compiler does the nee= ded abstraction layer. It's really true. Maybe we could define a= way to be very flexible (pci stuff) but it as nothing to do with boot = process... i'll try to answer the question that i have understood : i try to avoid the known causes of compatibility problems. And if it doesn't fit your needs, you can hack into the VHDL= source and make your own boot code, if you want. >I don't understand why physical adress must be continuous ?= virtual memory management should play is roll. So why such constrain= ts ? > =20 > when the CPU boots, VM and paging is not yet configured. continuous addresses are also so much simpler to manage than= many=20 scattered blocks, don't you think ? it makes the address decoders easier to de= sign. But i'm sure you can find cases where scattered memory block= s are=20 desirable :-) Now look at the computer you're currently using. it's a PC. I dont know how much RAM it has but mine has 288MB : one 32M= B and 2x 128MB module. don't you think it's more complex to th= ink about them as continuous ? Unless you want all modules to start on= a gigabyte=20 boundary... >>>But for the hardware it's not continuous at all ! then, i don't think that the malloc and kernel codes will ap= reciate. >Each cpu could have it's own eeprom that's not a problem at= all. > right. but it depends on the case and the application. For example, a dual CPU PC has only a single boot ROM. >>> PC... quite normal they use a single chip to access the = memory, so you only need on eeprom access to the chip. FCPU have dedica= ted memory interace on each chip... Maybe you can find examples where there is more, but at leas= t you can find these dual CPU boards in the public stores in P= aris. The first reason is to cut costs, another is compatibility w= ith single-CPU systems. Now, F-CPU should have as few compatibil= ity problems as possible, so the reason to choose whether a sing= le ROM is used or not is not dependent on the CPU specification, bu= t it depends on the context, on the price tag, on the scalability= .... > You could have a hardwire code to fixe the cpu numer. > > this number could be reread throught SR or memory. > =20 > i thought about this, too. however it's a static allocation thing and it doesn't answer= all the=20 questions. >>>Sure. What happen if you add a cpu to machine. But it's = more a system designer problem, no ? SR interface will change nothi= ng on that. Currently, i think about using a "scratch SR" (a classical r= ead-write=20 location in SR space) to store the CPU number in the system.= This can also be read from the PCB slot or something like that, durin= g powerup. But it doesn't answer the question "how much RAM does the wh= ole system contain" and "how is this RAM distributed", as we can= 't expect >>> at the first stage of boot, the eeprom code will read th= is value thought the i2c bus dedicated to that. or assume that all CPUs have the same type and amount of RAM= . And it also depends on how the chips are connected together. Sure, each CPU could have its own boot ROM with a dedicated = code where the base address and RAM size is stored, for every CPU= . But it can be more cost-efficient to have a single ROM, from= which all CPUs boot, and also containing a table describing the me= mory layout (base address of each CPU etc). >>>that's a more interresting question. It's : how flat is o= ur physical adress space ? If this should be defined by boot process, it= 's much more flexible. If there is a SR_CPU_NUMBER available, then each CPU can boo= t from the same code and initialise the DRAM base address by u= sing the CPU number as an index in the memory layout table. >>>Yes, it's the simple, static way. I think it's the cleanest and simplest solutionn, because it= doesn't specify a given number of PROM and CPU. It's also a weakness because it relies on the PROM to be up to date :-( >>> ???? But at least it requires a single SR_CPU_NUMBER (i hope that= nicO will agree on this). >>> i agree it's simple but as you said before, it's not rea= lly usefull if node could be added to a system. In a chip, you will have= one or more cpu, peripheral, memory interface and one or more io interfa= ces, (+ debug interface and eeprom boot). Maybe some dialogue could = be send tought io interface to discover neibourghoud. Or we completl= y drop such feature not really used nowadays (in fact 8 way computers ar= e design to have 8 cpus or ...less) Can i update the file to include this ? or do we want to troll a bit again before ? :-) >>>i could troll again... What about unique cpu number that = could only be accessed in superuser mode ? Then an algorythme could be = used to discover the cpu network and assigne adress space... ok it's= much more too complicated ! This SR should be used to defined local ph= ysical adresse space. >I stop reading the rest of the draft, it's to much... "deco= nnected to a reality". > =20 > Maybe it's not a dirty enough hack ? >>> It's soon too dirty.=20 Boot : - initialisation of the DRAM interface, (i think that you do= n't really need the use of the internal cache as RAM for such little th= ing but it could be an interresting feature.) - use of it ! - then what ever BIOS could take the cpu, as normal code (fo= r memory test,...). nicO have fun anyway, >nicO > YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= __________ Exclusif: 75 euros rembours=E9s sur le pack eXtense Haut D=E9= bit de Wanadoo !=20 Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Oct 14 20:08:58 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 181BnY-0003nM-00 for ; Mon, 14 Oct 2002 22:26:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Oct 2002 22:26:44 +0200 (CEST) Received: (qmail 9332 invoked by uid 0); 14 Oct 2002 18:10:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 14 Oct 2002 18:10:16 -0000 Received: by moria.seul.org (Postfix) id 61AD715E763; Mon, 14 Oct 2002 14:10:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E62315E768; Mon, 14 Oct 2002 14:10:15 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 7799215E763 for ; Mon, 14 Oct 2002 14:10:14 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.ccinet.ab.ca (8.12.3/8.12.5) with ESMTP id g9EIB5oP041268 for ; Mon, 14 Oct 2002 12:11:06 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DAB083A.2070200@jetnet.ab.ca> Date: Mon, 14 Oct 2002 12:08:58 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> <3DA9D8DD.1020402@f-cpu.org> <1034583557.3daa7e05cea39@imp.free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cedric BAIL wrote: >>when the CPU boots, VM and paging is not yet configured. > Right, but they will be quickly activated when we need memory, and I hope > that we didn't need more than 1 MB for the boot process ! Well why can't VM and paging be configured on boot? You would have a system dump/restore mode that dumps all the register contents. Also 1 MB is very small to boot from nowdays --- look how big the linux kernal is. Also would not splitting the CPU in to smaller segments like CPU only Memory Management, I/O and Basic OS functions handeled by other well abstracted CPU blocks? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 15 00:51:25 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 181G7y-0006nj-01 for ; Tue, 15 Oct 2002 03:04:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Oct 2002 03:04:06 +0200 (CEST) Received: (qmail 8928 invoked by uid 0); 14 Oct 2002 21:39:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 14 Oct 2002 21:39:45 -0000 Received: by moria.seul.org (Postfix) id 9666715E724; Mon, 14 Oct 2002 17:39:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6305E15E777; Mon, 14 Oct 2002 17:39:43 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id B908815E724 for ; Mon, 14 Oct 2002 17:39:42 -0400 (EDT) Received: from f-cpu.org (kdl14-252.n.club-internet.fr [213.44.12.252]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 0EE5F170C for ; Mon, 14 Oct 2002 23:39:36 +0200 (CEST) Message-ID: <3DAB4A6D.6090108@f-cpu.org> Date: Mon, 14 Oct 2002 23:51:25 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> <3DA9D8DD.1020402@f-cpu.org> <1034583557.3daa7e05cea39@imp.free.fr> <3DAB083A.2070200@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! i answer this mail first because it's the shortest :-) Ben Franchuk wrote: > Cedric BAIL wrote: > >>> when the CPU boots, VM and paging is not yet configured. >> >> Right, but they will be quickly activated when we need memory, and I >> hope >> that we didn't need more than 1 MB for the boot process ! > > Well why can't VM and paging be configured on boot? it's the user's choice. VM is mostly useful when dealing with multiple programs but boot is single-threaded, dealing with HW resources at the highest priviledge access rights. there is no need for VM at this time. When the boot code starts the kernel, the memory must also be in a specific, stable state so the kernel can install its own VM. > You would have a system dump/restore mode that dumps > all the register contents. Also 1 MB is very small to boot > from nowdays --- look how big the linux kernal is. then larger EPROM will allow to store several kernels :-) along with a simple multiboot utility. > Also would not splitting the CPU in to smaller segments > like CPU only Memory Management, I/O and Basic OS functions > handeled by other well abstracted CPU blocks? can you elaborate, please ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Oct 15 00:46:10 2002 Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 181G81-0006nj-00 for ; Tue, 15 Oct 2002 03:04:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Oct 2002 03:04:09 +0200 (CEST) Received: (qmail 22071 invoked by uid 0); 14 Oct 2002 22:47:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 14 Oct 2002 22:47:30 -0000 Received: by moria.seul.org (Postfix) id 374CE15E724; Mon, 14 Oct 2002 18:47:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0F8F15E77B; Mon, 14 Oct 2002 18:47:28 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 63BCB15E724 for ; Mon, 14 Oct 2002 18:47:28 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.ccinet.ab.ca (8.12.3/8.12.5) with ESMTP id g9EMmJoP000449 for ; Mon, 14 Oct 2002 16:48:20 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DAB4932.2060504@jetnet.ab.ca> Date: Mon, 14 Oct 2002 16:46:10 -0600 From: Ben Franchuk User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,ja MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> <3DA9D8DD.1020402@f-cpu.org> <1034583557.3daa7e05cea39@imp.free.fr> <3DAB083A.2070200@jetnet.ab.ca> <3DAB4A6D.6090108@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Yann Guidon wrote: >> Also would not splitting the CPU in to smaller segments >> like CPU only Memory Management, I/O and Basic OS functions >> handeled by other well abstracted CPU blocks? > A multi-tasking OS requires multi-threads running on a single CPU to abstract OS functions. Look at Minux for example 4 states 1) Irq/trap service 2) memory management process 3) File & I/O process 4) user process. Right now you trap for every OS service and time slice a single cpu as the default. Multi-cpu's still follow the same model. Even deicated hardware like smart I/O can't make much improvment. The default would be best if was deicated smart I/O. If you don't have smart I/O then you fall back to Multi-cpu operations. If that fails you fall back to a single cpu. I think a generic standard I/O interface can be developed but it requires thought at the system rather than the CPU level. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Oct 15 05:24:43 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 181Hi2-0007ux-00 for ; Tue, 15 Oct 2002 04:45:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Oct 2002 04:45:26 +0200 (CEST) Received: (qmail 5023 invoked by uid 0); 15 Oct 2002 02:12:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 15 Oct 2002 02:12:53 -0000 Received: by moria.seul.org (Postfix) id BB92315E783; Mon, 14 Oct 2002 22:12:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8225D15E788; Mon, 14 Oct 2002 22:12:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 1E7AB15E783 for ; Mon, 14 Oct 2002 22:12:52 -0400 (EDT) Received: from f-cpu.org (kro1-3.n.club-internet.fr [213.44.93.3]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 0BB2016A7 for ; Tue, 15 Oct 2002 04:12:50 +0200 (CEST) Message-ID: <3DAB8A7B.4000700@f-cpu.org> Date: Tue, 15 Oct 2002 04:24:43 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] spec draft about booting F-CPU References: <3DA7D272.60500@f-cpu.org> <200210130454.30355.cedric.bail@free.fr> <3DA9961C.1090009@f-cpu.org> <20021014170501.253a02b5.nicolas.boulay@ifrance.com> <3DA9D8DD.1020402@f-cpu.org> <1034583557.3daa7e05cea39@imp.free.fr> <3DAB083A.2070200@jetnet.ab.ca> <3DAB4A6D.6090108@f-cpu.org> <3DAB4932.2060504@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi ! Ben Franchuk wrote: > Yann Guidon wrote: > >>> Also would not splitting the CPU in to smaller segments >>> like CPU only Memory Management, I/O and Basic OS functions >>> handeled by other well abstracted CPU blocks? >> >> > A multi-tasking OS requires multi-threads running on > a single CPU to abstract OS functions. Look at Minux > for example 4 states 1) Irq/trap service 2) memory management > process 3) File & I/O process 4) user process. > Right now you trap for every OS service and time slice > a single cpu as the default. Multi-cpu's still follow > the same model. Even deicated hardware like smart I/O > can't make much improvment. > The default would be best if was deicated smart I/O. > If you don't have smart I/O then you fall back to > Multi-cpu operations. If that fails you fall back to > a single cpu. I think a generic standard I/O interface > can be developed but it requires thought at the system > rather than the CPU level. but there is no relationship with boot, it seems. it's more a kernel matter.... and F-CPU is only a microprocessor project :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graceita2001ng@spinfinder.com Fri Oct 18 17:52:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 182mbp-0000bM-01 for ; Sat, 19 Oct 2002 07:57:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Oct 2002 07:57:13 +0200 (CEST) Received: (qmail 26141 invoked by uid 0); 18 Oct 2002 14:53:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 18 Oct 2002 14:53:10 -0000 Received: by moria.seul.org (Postfix) id 2941715E787; Fri, 18 Oct 2002 10:53:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E31AF15E8B8; Fri, 18 Oct 2002 10:53:08 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from moria.seul.org (unknown [217.78.77.101]) by moria.seul.org (Postfix) with SMTP id D00A215E8B4 for ; Fri, 18 Oct 2002 10:52:53 -0400 (EDT) From: "Grace Ita (Mrs)" Date: Fri, 18 Oct 2002 15:52:28 To: f-cpu@seul.org Subject: [f-cpu] URGENT ASSISTANCE/INVESTMENT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20021018145253.D00A215E8B4@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N >From the desk of:- MRS GRACE ITA C/O Barrister Chike Egobia Lagos Nigeria Sir, URGENT AND CONFIDENTIAL BUSINESS PROPOSAL I am Grace Ita (mrs) widow of the late Col. Kulu Ita the former governor of Kano State of Nigerian. My late husband was one of the victims of the November ADC Aircraft Boeing 722 that crashed in Lagos. I have just been informed by family attorney Barrister Chike Egobia that my late husband operated a secret account with fictitious name in a Nigeria bank into which total sum of Nineteen Million, Five Hundred Thousand US Dollars ($19.5) was transferred and credited in his favour. The attorney now advised me to seek in confidence a foreign account into which this fund could be transferred for disbursement as directed by my late husband in his will. It has been resolved that 25% will be your share for nominating an account for this purpose and any other assistance you will give in that regard. 10% has been mapped out to payback all local and international expenses, which may be, incurred in the transfer process and 5% has been conceded to the local bank manager here assisting facilitating the transfer. Finally, 60% will come to myself and my children and good part of this shall be directed towards executing his will which is to buy shares and stocks in foreign country to securities his children’s future to facilitate the conclusion of this transaction if accepted do send to me promptly by fax through family attorney, the following. 1. The account number to be used for remittance 2. Name and address of your bank 3. Fax and telephone numbers, through which you will be contacted 4. Promptly whenever you attorney/ assistance may be required Please note that i have been assured that the transaction will be concluded in ten (10) banking working days upon my receiving from you the above listed information will commence the process of retrieving the will immediately i hear from you. May at this point emphasize the high level of confidentiality, which this business demands hope you will not betray the trust and confidence, which is reposed in you. However, you may need to give me sufficient assurance that you will not sit on this fund when it is finally remitted into your account. Please direct your reply by email to my box in which the family attorney will communicate with him towards effective completion of this transaction. Regards. Grace Ita (Mrs) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Oct 18 22:51:57 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 182mbt-0000bM-00 for ; Sat, 19 Oct 2002 07:57:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Oct 2002 07:57:17 +0200 (CEST) Received: (qmail 15764 invoked by uid 0); 18 Oct 2002 20:51:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Oct 2002 20:51:59 -0000 Received: by moria.seul.org (Postfix) id 0732915E757; Fri, 18 Oct 2002 16:51:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF8E815E8B1; Fri, 18 Oct 2002 16:51:57 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id 83E5815E757 for ; Fri, 18 Oct 2002 16:51:57 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix3-2.free.fr (Postfix) with ESMTP id 2A48517E7D for ; Fri, 18 Oct 2002 22:51:57 +0200 (CEST) Received: by imp2-1.free.fr (Postfix, from userid 33) id 115B258088; Fri, 18 Oct 2002 22:51:57 +0200 (MEST) To: f-cpu@seul.org Subject: [f-cpu] New manual (0.2.7) Message-ID: <1034974317.3db0746d03cbb@imp.free.fr> Date: Fri, 18 Oct 2002 22:51:57 +0200 (MEST) From: Cedric BAIL MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 212.30.114.9 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi every body, I have released a new manual at seul : http://f-cpu.seul.org/cedric/unstable/ Because a lot of change occur since the last manual, I nead that as much as possible people read it and say where they found error. So that I can do a release that can be a start for discussion. So the change-log since 0.2.6 : Add color and new convention for ISA. Add new shift and rot. Remove unnecessary option. Add widen. Add LSU flush to serialize for stream hints problem. Add madd/msub/mschg instructions. Change stream hints postfix by adding a dot (reduce gperf colision). Add chsift. Start SR\_MAP. Change loadcons to the new form. Change loadaddri to the new form. Add new memory instruction : ss, sl, cstore, cload. Change logic/logici instructions. Add new combine_or, combine_and instructions. Add new mux instruction. What you will not see in this manual : TLB entry specification Sum and co. instructions Nice read, Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dltJulia@blues-mad.co.uk Tue Feb 19 10:55:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 183G35-0004RY-00 for ; Sun, 20 Oct 2002 15:23:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 20 Oct 2002 15:23:19 +0200 (CEST) Received: (qmail 26968 invoked by uid 0); 20 Oct 2002 08:50:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 20 Oct 2002 08:50:49 -0000 Received: by moria.seul.org (Postfix) id D5C3815E8DB; Sun, 20 Oct 2002 04:50:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA7AA15E8FD; Sun, 20 Oct 2002 04:50:49 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from 195.42.76.98 (unknown [195.42.76.98]) by moria.seul.org (Postfix) with SMTP id 7567715E8E3 for ; Sun, 20 Oct 2002 04:50:44 -0400 (EDT) Received: from unknown (HELO web13708.mail.yahoo.com) (141.52.163.69) by smtp4.cyberec.com with SMTP; Feb, 19 2002 10:54:06 -0800 Received: from 14.17.76.127 ([14.17.76.127]) by rly-xl04.mx.aol.com with QMQP; Feb, 19 2002 09:29:06 +0300 Received: from [48.211.102.224] by rly-xl05.mx.aol.com with local; Feb, 19 2002 08:50:06 +0300 From: mswcSue E To: f-cpu@seul.org Subject: [f-cpu] Sie haben eine neue Nachricht erhalten xgtb Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Feb 2002 10:55:25 +0100 X-Mailer: eGroups Message Poster Message-Id: <20021020085046.7567715E8E3@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Sie haben von Susanne eine neue Nachricht erhalten: Klicken Sie hier um die Nachricht zu lesen. http://happy_chat_de.erotik.amateurseite.to --------------------------------------------------------------------------------------------- Viel Spass Happy Chat Messagin System dinvdysbphfwgbnsaelmax ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Oct 20 21:37:56 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 183G3C-0004RY-00 for ; Sun, 20 Oct 2002 15:23:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 20 Oct 2002 15:23:26 +0200 (CEST) Received: (qmail 8382 invoked by uid 0); 20 Oct 2002 13:01:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 20 Oct 2002 13:01:55 -0000 Received: by moria.seul.org (Postfix) id C514A15E73F; Sun, 20 Oct 2002 09:01:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9932E15E756; Sun, 20 Oct 2002 09:01:54 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 18ED315E73F for ; Sun, 20 Oct 2002 09:01:54 -0400 (EDT) Received: from gaia.bail.voulx.fr (nas-cbv-11-62-147-120-174.dial.proxad.net [62.147.120.174]) by postfix2-2.free.fr (Postfix) with ESMTP id 7B7135F767 for ; Sun, 20 Oct 2002 15:01:52 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New manual (0.2.7) Date: Sun, 20 Oct 2002 21:37:56 +0200 User-Agent: KMail/1.4.3 References: <1034974317.3db0746d03cbb@imp.free.fr> In-Reply-To: <1034974317.3db0746d03cbb@imp.free.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210202137.56932.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > Hi every body, > > I have released a new manual at seul : > http://f-cpu.seul.org/cedric/unstable/ > > Because a lot of change occur since the last manual, I nead that as much as > possible people read it and say where they found error. So that I can do a > release that can be a start for discussion. > > So the change-log since 0.2.6 : > Add color and new convention for ISA. > Add new shift and rot. > Remove unnecessary option. > Add widen. > Add LSU flush to serialize for stream hints problem. > Add madd/msub/mschg instructions. > Change stream hints postfix by adding a dot (reduce gperf colision). > Add chsift. > Start SR\_MAP. > Change loadcons to the new form. > Change loadaddri to the new form. > Add new memory instruction : ss, sl, cstore, cload. > Change logic/logici instructions. > Add new combine_or, combine_and instructions. > Add new mux instruction. > > What you will not see in this manual : > TLB entry specification > Sum and co. instructions > So I find some error in rot, shit, addsub, nabs, dshifti, dbitrevi, I will correct them as quick as possible. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Subscriber_Services78039@xo.com Mon Oct 21 19:58:16 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 183z8c-0000Gz-00 for ; Tue, 22 Oct 2002 15:32:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Oct 2002 15:32:02 +0200 (CEST) Received: (qmail 16873 invoked by uid 0); 21 Oct 2002 17:58:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 21 Oct 2002 17:58:23 -0000 Received: by moria.seul.org (Postfix) id 4847315E764; Mon, 21 Oct 2002 13:58:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E85115E787; Mon, 21 Oct 2002 13:58:22 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E4A7A15E764 for ; Mon, 21 Oct 2002 13:58:21 -0400 (EDT) Received: from 218.5.200.70 ([195.127.215.146]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id g9LHwDn05316 for ; Mon, 21 Oct 2002 13:58:15 -0400 Message-Id: <200210211758.g9LHwDn05316@belegost.mit.edu> Received: from unknown (156.54.224.23) by a231242.upc-a.chello.nl with local; Oct, 21 2002 12:33:54 PM -0200 Received: from 11.139.74.233 ([11.139.74.233]) by n7.groups.yahoo.com with NNFMP; Oct, 21 2002 11:31:03 AM +1200 Received: from [138.156.251.163] by da001d2020.lax-ca.osd.concentric.net with local; Oct, 21 2002 10:32:46 AM -0100 Received: from ssymail.ssy.co.kr ([115.212.44.160]) by hd.regsoft.net with asmtp; Oct, 21 2002 9:50:03 AM -0800 From: "WALL STREET BULLETIN..46694" To: f-cpu@seul.org Subject: [f-cpu] New Stock Pick: NNCO....................................................... bjkm Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 21 Oct 2002 12:58:16 -0500 X-Mailer: Microsoft Outlook Build 10.0.2616 X-Priority: 1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N

NEW ISSUE - Volume 6, Issue 37 - October 2002

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

jqbtjruqfedxbgmulkjrhps ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Subscriber_Services78040@core.com Wed Oct 23 18:40:37 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 184cYP-0007iN-00 for ; Thu, 24 Oct 2002 09:37:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 24 Oct 2002 09:37:17 +0200 (CEST) Received: (qmail 27020 invoked by uid 0); 23 Oct 2002 16:40:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 23 Oct 2002 16:40:44 -0000 Received: by moria.seul.org (Postfix) id 3818C15E72A; Wed, 23 Oct 2002 12:40:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF8E015E77D; Wed, 23 Oct 2002 12:40:42 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 91F6915E72A for ; Wed, 23 Oct 2002 12:40:42 -0400 (EDT) Received: from 211.161.132.67 (athen144.server4free.de [217.172.180.144]) by bettik.munge.net (Postfix) with SMTP id AD3D24F670 for ; Wed, 23 Oct 2002 11:39:28 -0500 (CDT) Received: from unknown (170.127.231.172) by smtp013.mail.yahoo.com with local; Oct, 23 2002 11:27:29 AM +1200 Received: from [138.156.251.163] by da001d2020.lax-ca.osd.concentric.net with local; Oct, 23 2002 10:18:30 AM +0600 Received: from unknown (HELO web13708.mail.yahoo.com) (141.52.163.69) by smtp4.cyberec.com with SMTP; Oct, 23 2002 9:35:26 AM +0400 Received: from unknown (148.179.169.246) by rly-yk05.mx.aol.com with QMQP; Oct, 23 2002 8:18:31 AM -0700 From: WALL STREET BULLETIN…..47577 To: f-cpu@seul.org Subject: [f-cpu] NEW STOCK PICK: PRCT - LAST PICK UP 233%, NNCO......................................................................................................................................................................................................... yaw Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 23 Oct 2002 11:40:37 -0500 X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Priority: 1 Message-Id: <20021023163928.AD3D24F670@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N

Did you miss out on NNCO, UP 233% IN JUST 2 DAYS?

If so, Here's another pick - Another Short Play

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

epkhukdtjeofrhcvlpitkauedxghpbxakorcx ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bamako@ecplaza.net Sat Oct 26 11:56:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 185xHO-0004Wh-00 for ; Mon, 28 Oct 2002 00:57:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 28 Oct 2002 00:57:14 +0100 (CET) Received: (qmail 13432 invoked by uid 0); 26 Oct 2002 09:56:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 26 Oct 2002 09:56:54 -0000 Received: by moria.seul.org (Postfix) id D2BCB15E75A; Sat, 26 Oct 2002 05:56:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A4CD15E77B; Sat, 26 Oct 2002 05:56:52 -0400 (EDT) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 033A015E75A for ; Sat, 26 Oct 2002 05:56:52 -0400 (EDT) Received: from helimore2588.com ([217.78.77.105]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id g9Q9ufn24734 for ; Sat, 26 Oct 2002 05:56:47 -0400 Message-Id: <200210260956.g9Q9ufn24734@belegost.mit.edu> From: "Mr BAMAK ALI" To: f-cpu@seul.org Date: Sat, 26 Oct 2002 02:56:47 -0700 Subject: [f-cpu] ALI X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Dear Sir=2C =09=09 Compliments=2C It is my great pleasure to write you this letter on behalf of myself and my colleagues=2E Your particulars was given to me by a member of the Nigeria Export Promotion Council =28NEPC=29 who with the Federal Delegates to your country during an exhibition=2E I have decided to seek a confidential cooperation with you in the execution of the deal described hereunder for the benefit of all the parties and hope you will keep it as a top secret because of thenature of thebusiness=2E Within the ministry of Petroleum Resources where I work as a director=2C Project Implementation and with the co-operation of four other top officials=2C we have in our possesion an overdue payment bill totalling twenty Seven million=2C Five Hundred Thousand US DOLLARS=3E =28US$27=2C500=2C000=2E00=29 which we want to transfer abroad with the assistance and co-operation of a foreign company or individual to receive the said fund on our behalf or a reliable foreign non-companyaccount toreceive such fund=2E The amount represents some percentage of the total contract value executed on behalf of my ministry by a foreign contracting firm which we the officialover-invoiced=2E Though the actual contract cost have been paid to the original contractor=2C leaving the balance of US$27=2E5M which we have in principle gotten an approval to remit to a foreign bank account you will provide=2E Since the present Government of Nigeria is determine to pay every Foreign contractor all debts owed so as to maintain good relationship with Foreign and non-Government Financial Agencies we then decided to include our bills for payment with the co-operation of some officials from the Ministry of finance =28FMF=29 and the Central Bank of Nigeria =28CBN=29=2E We are seeking your assistance in providing a good company=92s account or any other bank account into which we can remit this money by fronting as thebeneficiary=2E This process being an internal arrangement with the departments concerned=2E I have the authority of my partners-involve to propose this deal to you as you might be willing to assist us in this transaction=2C for your assistances we shall offer you 20% of USD27=2E5M=2C 75%for us and 5% for miscellaneous expenses=2E The business is 100% hitch free on your part provided you treat it with utmost secrecy and confidentiality=2E Also your area of specialization is not hiderance to the successful execution of this transaction=2E I have reposed my confidences in you and hope that youwill not disappoint me=2E Yours sincerely=2C BAMAKO ALI NB=3A That you are not running any risk=2C thanks for yourcooperation=2E Please include your Tel=2Ffax Number foreasy communication ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From k_aram84@hotmail.com Fri Nov 1 07:08:56 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 187d7M-0000i3-01 for ; Fri, 01 Nov 2002 15:49:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 01 Nov 2002 15:49:48 +0100 (CET) Received: (qmail 9031 invoked by uid 0); 1 Nov 2002 06:08:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 1 Nov 2002 06:08:59 -0000 Received: by moria.seul.org (Postfix) id 7C4FA15E791; Fri, 1 Nov 2002 01:08:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CFB815E796; Fri, 1 Nov 2002 01:08:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dwi-law.com (63-217-20-14.sdsl.cais.net [63.217.20.14]) by moria.seul.org (Postfix) with ESMTP id D37B815E791 for ; Fri, 1 Nov 2002 01:08:56 -0500 (EST) Received: from Wauzj ([80.15.240.141]) by dwi-law.com ([63.217.20.14]) with SMTP (MDaemon.PRO.v6.0.5.R) for ; Fri, 01 Nov 2002 01:11:30 -0500 From: k_aram84 To: f-cpu@seul.org Subject: [f-cpu] Webmasters $$$ MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=PC8024q3glbfkD2ZI7o3V83c5S8 X-MDRemoteIP: 80.15.240.141 X-Return-Path: drew@dwi-law.com X-MDaemon-Deliver-To: f-cpu@seul.org Message-Id: <20021101060856.D37B815E791@moria.seul.org> Date: Fri, 1 Nov 2002 01:08:56 -0500 (EST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N --PC8024q3glbfkD2ZI7o3V83c5S8 Content-Type: text/plain ****************************** WARNING ******************************* This message has been scanned by MDaemon/DKAV and was found to contain infected attachment(s). Please review the list below. Attachment Virus name Action taken ---------------------------------------------------------------------- cf291806994.att Exploit.IFrame.FileDownloadRemoved 3eesa-alkbeesi-s[1].scr Win95.CIH Removed ********************************************************************** --PC8024q3glbfkD2ZI7o3V83c5S8 Content-Type: application/octet-stream; name=3eesa-alkbeesi-s[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CABCAD8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7LqvqF7bWFs1xdSrHGoySTU0rrHGXY8Cu J8SmXU3ZSWWNORxxRoYV68aK13Oa8V/GK3t5ntdFt/tDrnLk4Ue5NcRc/GDxA8pZZUCD0z1/ w/Wux1Dw9o96oW5FpI2SWDEZJrMk+F3h27dWWKWLd3ic4/CtVOmjmWIlLV6Gdpfxs1SGVRdQ xzR9znBr1LwX8RtF8RBYw4gnP8DGvOL34I2rxtPY6zcwsOQssauD/Ks0fC3xBpm2fTtStpp1 IO3Bjx+PNN8ktEbwqH0cCCMg5Borivh1qGtpbDT9etXSVBhZQQyt+IrtayasdCdyrqPzR7Ox 615f8SPEMUN2vhzTpQL2RN88g/5Yp/8AFH9K9Su9wUleCeM14b4i0tIvinqczqdsltHID2O7 IP8A6DXFiq6pppb2OdUFUrc0uhjz+IdL0eQLd38MIwFw55z9K6Xwz4htrsedpWo29x3KxyAn 8q47xXompxFzokFoHcEkywKxZiR1J7YzWK2gxafqNrci2jW8IXzJIkEZ398Be31ryozgoc3M 7nr0qN2lbQ99fxKq2qrLaTCZRyBwtc5qPi68QukQjiX/AGRkj868v8Z3Wq3bQabbahdQFlJZ kfBP41ymjWU7iOW7k1eC5MmxW+17zkd2Qj7tdMK0qkL89jRYOEJK0Nz6c8AeIhrMc8Uyfv7Y rlwfvA9D9eK7qFw8YYGvBvg7dXlt4vksLj5zNY+ZIwHAZW4+mc17fpDl4CCc4NepQk50k2cl emoTaiWpl3RkV4n49ultPiFJGVYLLbIQPcE17c/3D9K8E+OYMHipLpGIxCvBOOR/+uuPHU1J JmNN/vEi8l2s8ZBIGAea5O+ke51jZEu5Fbapz1NYWueIdRtNMgTT7czXM7+WMn5QMZJNcx9q 8SyXsNzJqNrb+Ww3xiF8H2zivJjhm1dtI9ejK2kVc7a+Rh4hjjcA9t2ehrTvBBbxl3RS56t7 15ZDr2t6dey3WoCLUEZt26I/NGvsCOgrpb7XGvra3+zqZZLgKIlXqxboP1FX9WnGStqmdHtY 9VZo9V+DlsZ9R1DVWBLELEh7bRkn9f5V7Bo4by2Y98VzngHwwvh7Qra1b55vJUSk/wB/qf1J rrbeMRxBQK+gox5Kaizxa01OTaJCM8VxXxT8Fr4o0nda4W+g+aPPAk/2Se31rtaKc4KaszHz PjqRrrRtcuLDU7Z4GU7Ssowc+2al1Z2mSKS01WO3ZztVXgV92Ow719LePvAegeMrULqUBjuk GIrqLAkT8e49jXjet/AjxNby50nWIbxFPyeYdhA+n/164amDTlzJnVSxLirM8v1u/gsbVxO8 E8j5Usq4zn2r0D9mrwnJr+sHxPqEf+h2BCWseOGkA6/RR+tWvDv7O+p3d6LjxRqsaQht3k2/ zMx9yeBXv/hXQNO8N6LDpOlwLDbxdAOpPcn1Nb0aEaastWRVxUqrNBykaAscKKWKVZPugj61 FqCu0ACKSQ3YexqKNXN0rBTtC4J24rrSVjnL1FFFSMKKKKACiiigAooooA//2T== --PC8024q3glbfkD2ZI7o3V83c5S8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@dwi-law.com Fri Nov 1 07:11:57 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 187d7N-0000i3-00 for ; Fri, 01 Nov 2002 15:49:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 01 Nov 2002 15:49:49 +0100 (CET) Received: (qmail 27037 invoked by uid 0); 1 Nov 2002 06:09:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 1 Nov 2002 06:09:01 -0000 Received: by moria.seul.org (Postfix) id D64F215E792; Fri, 1 Nov 2002 01:08:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A0A3715E795; Fri, 1 Nov 2002 01:08:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dwi-law.com (63-217-20-14.sdsl.cais.net [63.217.20.14]) by moria.seul.org (Postfix) with ESMTP id D718715E792 for ; Fri, 1 Nov 2002 01:08:56 -0500 (EST) Received: from dwi-law.com [63.217.20.14] by dwi-law.com [63.217.20.14] with RAW (MDaemon.PRO.v6.0.5.R) for ; Fri, 01 Nov 2002 01:11:57 -0500 Date: Fri, 01 Nov 2002 01:11:57 -0500 From: postmaster@dwi-law.com Subject: [f-cpu] MDaemon Warning - Virus Found To: f-cpu@seul.org X-MDaemon-Deliver-To: f-cpu@seul.org Message-ID: Mime-Version: 1.0 X-Actual-From: postmaster@dwi-law.com Content-Type: text/plain; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N The following message had attachment(s) which contained the viruses: >From : k_aram84@hotmail.com To : f-cpu@seul.org Subject : Webmasters $$$ Date : Message-ID: Attachment Virus name Action taken ------------------------------------------------------------------------------ cf291806994.att Exploit.IFrame.FileDownloadRemoved 3eesa-alkbeesi-s[1].scr Win95.CIH Removed ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From StopForeclosure98066@mindspring.com Sun Nov 3 02:59:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188VTM-0000Fu-01 for ; Mon, 04 Nov 2002 01:52:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 01:52:08 +0100 (CET) Received: (qmail 25217 invoked by uid 0); 3 Nov 2002 01:56:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 3 Nov 2002 01:56:00 -0000 Received: by moria.seul.org (Postfix) id 69C6215E7B1; Sat, 2 Nov 2002 20:55:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3612B15E7B7; Sat, 2 Nov 2002 20:55:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 8904115E7B1 for ; Sat, 2 Nov 2002 20:55:58 -0500 (EST) Received: from 61.188.216.53 (unknown [210.126.63.68]) by bettik.munge.net (Postfix) with SMTP id 78EF94F7D4 for ; Sat, 2 Nov 2002 19:55:35 -0600 (CST) Received: from [206.22.148.111] by smtp4.cyberec.com with NNFMP; Nov, 02 2002 7:44:33 PM +1100 Received: from [106.226.127.61] by n7.groups.yahoo.com with local; Nov, 02 2002 6:49:31 PM +0300 Received: from [204.80.13.95] by asy100.as122.sol.superonline.com with smtp; Nov, 02 2002 5:29:48 PM +0600 From: StopForeclosure1214 To: HOMEOWNER96811@munge.net Subject: [f-cpu] STOP YOUR FORECOSURE............................................................................................................................................................................................... mkpvl Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 2 Nov 2002 19:59:01 -0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 1 Message-Id: <20021103015535.78EF94F7D4@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N

CLICK HERE

 

Unsubscribe click here

cphddubemkdyksptqahqmngaur ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thomas.lavergne@laposte.net Sun Nov 3 18:45:32 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188pPv-0000Yi-00 for ; Mon, 04 Nov 2002 23:09:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 23:09:55 +0100 (CET) Received: (qmail 5891 invoked by uid 0); 4 Nov 2002 09:13:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 4 Nov 2002 09:13:08 -0000 Received: by moria.seul.org (Postfix) id 37AF015E8B4; Mon, 4 Nov 2002 04:13:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DF1CC15E8C5; Mon, 4 Nov 2002 04:13:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 7A1B415E8B4 for ; Mon, 4 Nov 2002 04:13:06 -0500 (EST) Received: from laposte.net (193.249.62.223) by smtp.laposte.net (6.0.053) (authenticated as thomas.lavergne@laposte.net) id 3DB5C84D00121EFE for f-cpu@seul.org; Mon, 4 Nov 2002 09:52:19 +0100 Message-ID: <3DC560BC.9010709@laposte.net> Date: Sun, 03 Nov 2002 18:45:32 +0100 From: Thomas Lavergne Organization: THallium Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: FCpu English Subject: [f-cpu] Error in f-cpu_opcodes.m4 or in manual Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N I think there was an error here : In the f-pu_opcodes.m4 the 3 bit for encoding the operation of the logic.xxx instruction was reserved int the opcode. In the manual the 3 bit field was in the flag part of the instruction and all form share the same opcode. What is the good form ? -- Thomas Lavergne "Le vrai rêveur est celui qui rêve de l'impossible." (Elsa Triolet) thomas.lavergne@laposte.net d-12@laposte.net ICQ:#137121910 http://www.thallium-software.net ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 4 10:25:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188pPv-0000Yi-01 for ; Mon, 04 Nov 2002 23:09:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 23:09:55 +0100 (CET) Received: (qmail 17064 invoked by uid 0); 4 Nov 2002 09:25:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 4 Nov 2002 09:25:52 -0000 Received: by moria.seul.org (Postfix) id 0A85E15E8C4; Mon, 4 Nov 2002 04:25:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B43A515E8C7; Mon, 4 Nov 2002 04:25:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by moria.seul.org (Postfix) with ESMTP id 2C11715E8C4 for ; Mon, 4 Nov 2002 04:25:49 -0500 (EST) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix4-1.free.fr (Postfix) with ESMTP id D0523BDAB for ; Mon, 4 Nov 2002 11:25:48 +0100 (CET) Received: by imp4-1.free.fr (Postfix, from userid 33) id BC0D34432; Mon, 4 Nov 2002 10:25:48 +0100 (CET) To: f-cpu@seul.org Subject: Re: [f-cpu] Error in f-cpu_opcodes.m4 or in manual Message-ID: <1036401948.3dc63d1cad419@imp.free.fr> Date: Mon, 04 Nov 2002 10:25:48 +0100 (MET) From: Cedric BAIL References: <3DC560BC.9010709@laposte.net> In-Reply-To: <3DC560BC.9010709@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Cool, someone read the manual ;-) > I think there was an error here : > In the f-pu_opcodes.m4 the 3 bit for encoding the operation of the > logic.xxx instruction was reserved int the opcode. > In the manual the 3 bit field was in the flag part of the instruction > and all form share the same opcode. > What is the good form ? I think that it's logical to have this information in the flag part and I don't see any reason to see them in the opcode part. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 4 11:17:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188pPw-0000Yi-00 for ; Mon, 04 Nov 2002 23:09:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 23:09:56 +0100 (CET) Received: (qmail 1584 invoked by uid 0); 4 Nov 2002 10:04:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 4 Nov 2002 10:04:51 -0000 Received: by moria.seul.org (Postfix) id 6443415E8C6; Mon, 4 Nov 2002 05:04:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E5DA15E8C9; Mon, 4 Nov 2002 05:04:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id BFF8315E8C6 for ; Mon, 4 Nov 2002 05:04:49 -0500 (EST) Received: from f-cpu.org (kdl4-64.n.club-internet.fr [213.44.3.64]) by relay-1v.club-internet.fr (Postfix) with ESMTP id DB7DF16C9 for ; Mon, 4 Nov 2002 11:04:42 +0100 (CET) Message-ID: <3DC6492F.8020807@f-cpu.org> Date: Mon, 04 Nov 2002 11:17:19 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Error in f-cpu_opcodes.m4 or in manual References: <3DC560BC.9010709@laposte.net> <1036401948.3dc63d1cad419@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, Cedric BAIL wrote: >Cool, someone read the manual ;-) > >>I think there was an error here : >> >> >>In the f-pu_opcodes.m4 the 3 bit for encoding the operation of the >>logic.xxx instruction was reserved int the opcode. >> >>In the manual the 3 bit field was in the flag part of the instruction >>and all form share the same opcode. >> >> >>What is the good form ? >> >> > >I think that it's logical to have this information in the flag part and I don't >see any reason to see them in the opcode part. > > i see a good reason for putting some of the information in the opcode. we have to encode the "combine" and the mux flags and also have a form with 8-bit immediate data. Since this needs 2 bits more than the 6-bit register field, some informations has to be pushed back into the opcode field. Finally, the .m4 files are often more up to date than the manual. This is not always true (now that Cédric maintains it) but the ROP2 operations have been redesigned, tested and refined several times so i'm confident in the code. But if at least i had time to read the new version of the manual..... >Cedric > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 4 12:12:09 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188pPz-0000Yi-01 for ; Mon, 04 Nov 2002 23:10:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 23:09:59 +0100 (CET) Received: (qmail 15345 invoked by uid 0); 4 Nov 2002 11:12:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 4 Nov 2002 11:12:12 -0000 Received: by moria.seul.org (Postfix) id BE1D215E8B4; Mon, 4 Nov 2002 06:12:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A264E15E8C7; Mon, 4 Nov 2002 06:12:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by moria.seul.org (Postfix) with ESMTP id 30F1B15E8B4 for ; Mon, 4 Nov 2002 06:12:10 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix4-1.free.fr (Postfix) with ESMTP id DDA42BD13 for ; Mon, 4 Nov 2002 13:12:09 +0100 (CET) Received: by imp1-1.free.fr (Postfix, from userid 33) id A23AC64076; Mon, 4 Nov 2002 12:12:09 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] Error in f-cpu_opcodes.m4 or in manual Message-ID: <1036408329.3dc6560925b9f@imp.free.fr> Date: Mon, 04 Nov 2002 12:12:09 +0100 (CET) From: Cedric BAIL References: <3DC560BC.9010709@laposte.net> <1036401948.3dc63d1cad419@imp.free.fr> <3DC6492F.8020807@f-cpu.org> In-Reply-To: <3DC6492F.8020807@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N > i see a good reason for putting some of the information in the opcode. > we have to encode the "combine" and the mux flags and also For me combine and mux are different instruction, that mean different opcode. If I correctly count this : we have 2 bits for this part. > have a form with 8-bit immediate data. Since this needs 2 bits more > than the 6-bit register field, some informations has to be pushed back into > the opcode field. So it's logical to put mux/combine in the opcode more than the logic function to execute (which need 3 bits). And it's more clear in the manual to split mux/combine/logic in different instruction even if we finally decide that the some of the most signifient bits from the opcode field are the same for combine/mux/logic. > Finally, the .m4 files are often more up to date than the manual. > This is not always true (now that Cédric maintains it) but the ROP2 > operations have been redesigned, tested and refined several times > so i'm confident in the code. I didn't understant the end of your sentence, did you start coding the decoder, because we speak about opcode ? > But if at least i had time to read the new version of the manual..... It will be great. The part that need to be read are the one that are not green at the head of the page. I propose a deal, you read the manual, I read your last snapshot ;-) (Is it the one from june ?) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Subscriber_Services78038@worldnet.att.net Mon Nov 4 20:56:26 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188pQM-0000Yi-00 for ; Mon, 04 Nov 2002 23:10:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 04 Nov 2002 23:10:22 +0100 (CET) Received: (qmail 16723 invoked by uid 0); 4 Nov 2002 19:53:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 4 Nov 2002 19:53:29 -0000 Received: by moria.seul.org (Postfix) id 2C98015E8CC; Mon, 4 Nov 2002 14:53:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E8F6415E8D1; Mon, 4 Nov 2002 14:53:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 210.22.109.66 (unknown [210.22.109.66]) by moria.seul.org (Postfix) with SMTP id 3444D15E8CC for ; Mon, 4 Nov 2002 14:53:25 -0500 (EST) Received: from mta6.snfc21.pbi.net ([39.26.127.61]) by ssymail.ssy.co.kr with esmtp; Nov, 04 2002 1:35:07 PM +0300 Received: from unknown (HELO rly-xw01.mx.aol.com) (96.213.243.25) by n9.groups.yahoo.com with asmtp; Nov, 04 2002 12:55:58 PM +1100 Received: from smtp-server6.tampabay.rr.com ([12.232.159.86]) by mailout2-eri1.midsouth.rr.com with asmtp; Nov, 04 2002 11:50:00 AM -0200 From: WALL STREET BULLETIN…..47039 To: Subscriber@seul.org, Acct.#99091@seul.org Subject: [f-cpu] NEW STOCK PICK: NVHG - PRCT WENT UP 300%........................................................................................................................................................................ cvkuh Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 4 Nov 2002 13:56:26 -0600 X-Mailer: Microsoft Outlook Build 10.0.2616 X-Priority: 1 Message-Id: <20021104195325.3444D15E8CC@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N

Did you miss out on PRCT, UP 300%?

Here's another pick - Another Short Play

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

xdltdptrwudjmlwejvxeonyoyr ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Magellan@emarkethost.net Mon Nov 4 23:02:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188uMW-00048C-01 for ; Tue, 05 Nov 2002 04:26:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 04:26:44 +0100 (CET) Received: (qmail 2753 invoked by uid 0); 4 Nov 2002 22:02:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 4 Nov 2002 22:02:56 -0000 Received: by moria.seul.org (Postfix) id 3FF7C15E708; Mon, 4 Nov 2002 17:02:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 09F6215E8C5; Mon, 4 Nov 2002 17:02:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from emarkethost.net (unknown [64.75.48.41]) by moria.seul.org (Postfix) with ESMTP id 5F77915E708 for ; Mon, 4 Nov 2002 17:02:54 -0500 (EST) Date: 4 Nov 2002 22:02:54 GMT From: Magellan@emarkethost.net To: f-cpu@seul.org Subject: [f-cpu] Join our excellent adventure MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------70DC67B31B0E" X-MKTFI: AOarlvSsO44T5biDN0/90U- Message-Id: <20021104220254.5F77915E708@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N This is a multi-part message in MIME format. --------------70DC67B31B0E Content-Type: multipart/alternative; boundary="------------A70DC67B31B0E" --------------A70DC67B31B0E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit We noticed your resume on the Web. If you've got two minutes, we could have an exciting career opportunity waiting for you! Simply register here: http://hire.emarkethost.net/mk/get/REMA10?_ED=MrkDlBrH.zEjVi70r6n58E and complete a quick profile of your job requirements. Your profile will be matched against all posted positions. If there's a match, you'll instantly receive an email inviting you to apply. It's quick...easy...free...and confidential. If you're a team player looking for a dynamic company in a high-growth industry, then join Magellan, where you can make a difference. And, if you know someone else that might be interested, please forward this invitation to tell them about the opportunity. www.magellanlabs.com You have received this email because your resume is posted on the Web. If you do not wish to receive future employment opportunities or information about us - we apologize for the interruption - please reply (including all original text) with Unsubscribe in the subject line -MKTFI:enUS:AOarlvSsO44T5biDN0/90U- --------------A70DC67B31B0E Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Please profile


 

Magellan Laboratories was established in 1991 to become the premier pharmaceutical development organization.

A decade later, Magellan has grown to over 500 employees, seven divisions and four locations with opportunities that cross a range of scientific fields including analytical, inhalation, microbiology, structural chemistry, synthesis, formulation, manufacturing, clinical supply operations, drug discovery, and bioanalytical services.

 

  
We noticed your resume on the Web.
If you've got two minutes, we could have an exciting career opportunity waiting for you!

Simply register here and complete a quick profile of your job requirements. Your profile will be matched against all posted positions. If there's a match, you'll instantly receive an email inviting you to apply.

It's quick...easy...free...and confidential.

If you're a team player looking for a dynamic company in a high-growth industry, then join Magellan, where you can make a difference. And, if you know someone else that might be interested, please forward this invitation to tell them about the opportunity.

www.magellanlabs.com

You have received this email because your resume is posted on the Web. If you do not wish to receive future employment opportunities or information about us - we apologize for the interruption - please reply (including all original text) with Unsubscribe in the subject line, or simply Notify us here.

-MKTFI:enUS: AOarlvSsO44T5biDN0/90U-
--------------A70DC67B31B0E-- --------------70DC67B31B0E-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Nov 5 00:34:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188uMb-00048C-01 for ; Tue, 05 Nov 2002 04:26:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 04:26:49 +0100 (CET) Received: (qmail 31681 invoked by uid 0); 4 Nov 2002 22:44:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 4 Nov 2002 22:44:23 -0000 Received: by moria.seul.org (Postfix) id 277E715E71E; Mon, 4 Nov 2002 17:44:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1801F15E8C8; Mon, 4 Nov 2002 17:44:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 8773715E71E for ; Mon, 4 Nov 2002 17:44:21 -0500 (EST) Received: from thor (161.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.161]) by smtp3.9tel.net (Postfix) with ESMTP id 251EE5BD4A for ; Mon, 4 Nov 2002 23:44:20 +0100 (CET) Content-Type: text/plain; charset="us-ascii" From: cedric To: Subject: [f-cpu] New suggestion about call convention Date: Mon, 4 Nov 2002 23:34:36 +0000 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211042333.19012.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi everybody, On the French mailing-list Antoine () has suggested a new idea for the call convention. At the beginning it just say that it was a funny idea, but it could be very interresting finally. So he suggest to specify a new register MR (mask register). Each bit in this register specify if the corresponding register need to be saved or not before using it. In the prologue of a function you make a "and" between the MR and a local constant that represent which register are used, then you conditionally load register to stack if a collision occur. Finally in the epilogue you restore register with the same idea. When you call a function you update mr with something like this : mr = mr | register to preserve. Of course this mask can evolve during the function. If you "randomly" select which register to use (when you don't which function call me), you have some chance that no collision occur (You have more in most case a chance that not a full collision occur). A second possibility when you allocated your registers is to use feedback from run-time, but each time you compile and run, you can have some different result... With this idea came 2 different call convention proposition : - 15 parameters registers - 16 temporary registers - 26 mask saved registers - 6 "system" registers (mr, plt, got, fp, sp, ra) Or : - 7 parameters registers - 8 temporary registers - 42 mask saved register - 6 "system" registers I prefer the second solution, but that's only my point of view. And perhaps some other can be better. Too use this mr, we need some instructions. Antoine first suggest to use a maskload and a maskstore. This instruction will act like a storem/loadm but with the mask technique. They will certainly look like this : - maskload r3, [r2] - maskstore r3, [r2] I have found that Michael RIEPE have suggested a similar instruction in a post ("Re: [f-cpu] Re: Floating-Point?" [15/08/2001]) but the discussion was lost. Perhaps Michael have some other idea on how to use it, or a reason why this instruction was lost (I don't find any reason in my archive). With this instruction the epilogue/prologue can look like this : ; epilogue move r0, t0 loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 maskstore t1, [sp] ; If we call a function we need to save/restore mr move mr, m1 ; prologue move r0, t0 loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 maskload t1, [sp] jmp ra The value loaded in t0 correspond to the register that are used in this function and that will trash registers. A second possibility, proposed by Cristophe Avoinne () is to split maskstore/maskload in 4 chunk like loadcons. You will have something like this for epilogue/prologue: ; epilogue loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 maskstore.1 t1, [sp] ; save register from r16 to r31 maskstore.2 t1, [sp] ; from r32 to r47 maskstore.3 t1, [sp] ; I am sure that you understood the idea ;-) ; If we call a function we need to save/restore mr move mr, m1 ; prologue loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 maskload.1 t1, [sp] maskload.2 t1, [sp] maskload.3 t1, [sp] jmp ra The objective of this instruction is to be less complex and perhaps more easy to put in FC0. (Of course maskload.0 and maskstore.0 exist ;-). Finally a last proposition, that only work on one register. It will look like this for epilogue/prologue : ; epilogue loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 rotr 16, t1, t1 ; pass first 16 registers maskstore t1, [sp] ; save r16 if needed and rotr t1 maskstore t1, [sp] ; save r17 if needed and rotr t1 ... maskstore t1, [sp] ; I am sure that you understood the idea ;-) ; If we call a function we need to save/restore mr move mr, m1 ; prologue loadcons.1 0xFFFF, t0 loadcons.2 0xFFFF, t0 loadcons.3 0xFFFF, t0 and mr, t0, t1 rotr 16, t1, t1 ; pass first 16 register maskload t1, [sp] ... maskload t1, [sp] jmp ra The problem of the first solution are : - complexity - popcount unit must not be optional - block the CPU for 3/4 cycles (before being sure that no TLB trap append) For the second solution : - complexity - popcount unit must not be optional - block the CPU for 3/4 cycles like the first solution, but you need to use this instruction more frequently than the previous solution, but this solution give you the possibility to pass a chunk if not needed. The last solution : - stack problem (same problem as storei/loadi that need when you are change direction to add an instruction for alignment) - In big function you need to call it a lot >From a software point of view I prefer the first solution from Antoine, but it can be a mess to implement it in hardware ! What are your point of view about this and what did you think about this idea. Not really linked with this discussion, it appear that when you only want to load a constant that is bigger than 8 bits, but smaller than 64 bits, you always need to do a move r0, your_constant. I think it will be a good idea to add a loadconsz that will set all the chunk to zero before putting his immediate value. Sorry for this long, but I hope it could be interresting, Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Nov 5 00:50:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 188uMg-00048C-00 for ; Tue, 05 Nov 2002 04:26:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 04:26:54 +0100 (CET) Received: (qmail 29511 invoked by uid 0); 4 Nov 2002 23:37:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 4 Nov 2002 23:37:57 -0000 Received: by moria.seul.org (Postfix) id 80FEA15E6F6; Mon, 4 Nov 2002 18:37:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BE2015E8C3; Mon, 4 Nov 2002 18:37:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id E0AC915E6F6 for ; Mon, 4 Nov 2002 18:37:55 -0500 (EST) Received: from f-cpu.org (kdl4-24.n.club-internet.fr [213.44.3.24]) by relay-4v.club-internet.fr (Postfix) with ESMTP id B7FEA16EE for ; Tue, 5 Nov 2002 00:37:52 +0100 (CET) Message-ID: <3DC707C3.3050606@f-cpu.org> Date: Tue, 05 Nov 2002 00:50:27 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <200211042333.19012.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N hi, cedric wrote: >Hi everybody, > > On the French mailing-list Antoine () has suggested a new >idea for the call convention. At the beginning it just say that it was a >funny idea, but it could be very interresting finally. > and in the end, it can be disapointing. > So he suggest to specify a new register MR (mask register). Each bit in this >register specify if the corresponding register need to be saved or not before >using it. In the prologue of a function you make a "and" between the MR and a >local constant that represent which register are used, then you conditionally >load register to stack if a collision occur. Finally in the epilogue you >restore register with the same idea. > When you call a function you update mr with something like this : >mr = mr | register to preserve. Of course this mask can evolve during the >function. > If you "randomly" select which register to use (when you don't which function >call me), you have some chance that no collision occur (You have more in most >case a chance that not a full collision occur). A second possibility when you >allocated your registers is to use feedback from run-time, but each time you >compile and run, you can have some different result... > With this idea came 2 different call convention proposition : > - 15 parameters registers > - 16 temporary registers > - 26 mask saved registers > - 6 "system" registers (mr, plt, got, fp, sp, ra) > Or : > - 7 parameters registers > - 8 temporary registers > - 42 mask saved register > - 6 "system" registers > I prefer the second solution, but that's only my point of view. And perhaps >some other can be better. > > one could choose to use the middle : 32 mask saved registers ?.... > Too use this mr, we need some instructions. Antoine first suggest to use a >maskload and a maskstore. This instruction will act like a storem/loadm but >with the mask technique. > in fact it is more complex because for each un/masked register, it does both the pointer increment and the memory access. The pointer thing makes the whole thing even more complex that loadm/storem/whatever. >The problem of the first solution are : >- complexity >- popcount unit must not be optional >- block the CPU for 3/4 cycles (before being sure that no TLB trap append) > > not only that, but : - instruction lifelength is not static ==> more difficult to decode and schedule - instruction cannot be interrupted in the middle (IRQ/whatever) ==> IRQ response time is unpredictable :-( - it can't be pipelined (issued and then another instruction can be decoded) - the read port is connected to the instruction buffer ==> it is not possible to generate the sequence of registers to be saved. And even a counter would not be ok (in order to generate the register numbers), because the mask can have holes ! >For the second solution : >- complexity >- popcount unit must not be optional >- block the CPU for 3/4 cycles like the first solution, but you need to use >this instruction more frequently than the previous solution, but this >solution give you the possibility to pass a chunk if not needed. > > same remarks as before. it's multicycle, CISC instrtuction with most of the problems. >The last solution : >- stack problem (same problem as storei/loadi that need when you are change >direction to add an instruction for alignment) >- In big function you need to call it a lot > > there is also : - it is more complex and heavy than a classical store/load with post-incrementation with the same result (except that it is conditionnal) - there are not enough register set ports to allow all the writes at the same time. Since this kind of instructions is used in bursts, it's a big problem because the differing latencies can't be hidden by other instructions that don't use all the write ports. >>From a software point of view I prefer the first solution from Antoine, but it >can be a mess to implement it in hardware ! > it is. > What are your point of view about >this and what did you think about this idea. > > I am completely against this idea in F-CPU up to v.1 and in FC0, where the pipeline is not adapted at all for these kinds of CISC gymnastics. BTW, there was also the evocation of using SRB for doing the backup/restore, but there are a lot of problems as well, do you'd better not think of it. > Not really linked with this discussion, it appear that when you only want to >load a constant that is bigger than 8 bits, but smaller than 64 bits, you >always need to do a move r0, your_constant. I think it will be a good idea to >add a loadconsz that will set all the chunk to zero before putting his >immediate value. > > Here is what i remember : loadcons doesn't sign extend the constant. loadconsx does it. >Sorry for this long, but I hope it could be interresting, > Cedric > well, at last it made it to this list. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Nov 5 10:05:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189AnE-0000G4-00 for ; Tue, 05 Nov 2002 21:59:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 21:59:24 +0100 (CET) Received: (qmail 8309 invoked by uid 0); 5 Nov 2002 09:05:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 5 Nov 2002 09:05:51 -0000 Received: by moria.seul.org (Postfix) id 6E1C215E721; Tue, 5 Nov 2002 04:05:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 43D2515E8C8; Tue, 5 Nov 2002 04:05:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by moria.seul.org (Postfix) with ESMTP id C13B915E721 for ; Tue, 5 Nov 2002 04:05:49 -0500 (EST) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix4-1.free.fr (Postfix) with ESMTP id 7DD3CBD00 for ; Tue, 5 Nov 2002 11:05:47 +0100 (CET) Received: by imp1-1.free.fr (Postfix, from userid 33) id 617836409B; Tue, 5 Nov 2002 10:05:47 +0100 (MET) To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Message-ID: <1036487144.3dc789e8e9989@imp.free.fr> Date: Tue, 05 Nov 2002 10:05:44 +0100 (CET) From: Cedric BAIL References: <200211042333.19012.cedric.bail@free.fr> <3DC707C3.3050606@f-cpu.org> In-Reply-To: <3DC707C3.3050606@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Status: R X-Status: N Hi, > > With this idea came 2 different call convention proposition : > > - 15 parameters registers > > - 16 temporary registers > > - 26 mask saved registers > > - 6 "system" registers (mr, plt, got, fp, sp, ra) > > Or : > > - 7 parameters registers > > - 8 temporary registers > > - 42 mask saved register > > - 6 "system" registers > > I prefer the second solution, but that's only my point of view. And > > perhaps some other can be better. > one could choose to use the middle : 32 mask saved registers ?.... The problem of 32 mask saved registers is : where did you start ? and where did you end ? Don't forget that you load 16 bits constants. > >The problem of the first solution are : > >- complexity > >- popcount unit must not be optional > >- block the CPU for 3/4 cycles (before being sure that no TLB trap > > append) > not only that, but : > - instruction lifelength is not static ==> more difficult to decode and > schedule Same problem as SRB for scheduling. But for decode I don't understant the problem. > - instruction cannot be interrupted in the middle > (IRQ/whatever) ==> IRQ response time is unpredictable :-( Like SRB, and I don't see the problem. If you start IRQ now or in 64 cycles, when you run at 100 Mhz, you will loose only 0,00000064 s... > - it can't be pipelined (issued and then another instruction can be > decoded) If you mean that you must first finish maskstore before starting maskload or maskstore it's correct. If you mean that no other instruction can start before the end of masksotre/load that's false, because you can check TLB for each bound before memory operation. > - the read port is connected to the instruction buffer ==> it is not > possible to generate the sequence of registers to be saved. And even a > counter would not be ok (in order to generate the register numbers), because > the mask can have holes ! I think that you want to implement it with a jump over zero or something like that. Why isn't it possible to start from first register to the end and check if the corresponding bit is set or not ? (You certainly need to add a bit per register and make a "or" with, I don't remember, the dirty bit). > >For the second solution : > >- complexity > >- popcount unit must not be optional > >- block the CPU for 3/4 cycles like the first solution, but you need to > > use this instruction more frequently than the previous solution, but this > >solution give you the possibility to pass a chunk if not needed. > same remarks as before. > it's multicycle, CISC instrtuction with most of the problems. > >The last solution : > >- stack problem (same problem as storei/loadi that need when you are > > change direction to add an instruction for alignment) > >- In big function you need to call it a lot > there is also : > - it is more complex and heavy than a classical store/load with > post-incrementation with the same result (except that it is conditionnal) Yes, but not so much (only add a rotation in parallele). > - there are not enough register set ports to allow all the writes at > the same time. I forgot to count for maskload, sorry. > Since this kind of instructions is used in bursts, it's a big problem > because the differing latencies can't be hidden by other instructions that > don't use all the write ports. I was thinking that the idea behind this instruction is the possibility to schedule it with the rest of the function code. > > What are your point of view about > >this and what did you think about this idea. > I am completely against this idea in F-CPU up to v.1 and in FC0, where > the pipeline is not adapted at all for these kinds of CISC gymnastics. > BTW, there was also the evocation of using SRB for doing the backup/restore, > but there are a lot of problems as well, do you'd better not think of it. > > Not really linked with this discussion, it appear that when you only > > want to load a constant that is bigger than 8 bits, but smaller than 64 > > bits, you always need to do a move r0, your_constant. I think it will be a > > good idea to add a loadconsz that will set all the chunk to zero before > > putting his immediate value. > Here is what i remember : > loadcons doesn't sign extend the constant. > loadconsx does it. Yes, but it doesn't set the lower bit, imagine : you want to put 0xFFFF0000, you need to do : move r0, t0 loadcons.1 0xFFFF, t0 or from the discussion about bypassing I understood that setting all the other bit to zero will be possible. And loadconsx doesn't exist anymore because we have widen (I find an other error in loadcons into the manual, of course is opcode is OP_LOADCONS). > well, at last it made it to this list. long mail take long time to write ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Nov 5 18:50:14 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189ApQ-0000G4-00 for ; Tue, 05 Nov 2002 22:01:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 22:01:40 +0100 (CET) Received: (qmail 693 invoked by uid 0); 5 Nov 2002 18:12:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 5 Nov 2002 18:12:31 -0000 Received: by moria.seul.org (Postfix) id 138C415E71E; Tue, 5 Nov 2002 13:12:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E2F3C15E728; Tue, 5 Nov 2002 13:12:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a184.home.uni-hannover.de [130.75.232.184]) by moria.seul.org (Postfix) with ESMTP id C7C8715E71E for ; Tue, 5 Nov 2002 13:12:27 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01183; Tue, 5 Nov 2002 18:50:14 +0100 Message-ID: <20021105185014.20040@thrai.stud.uni-hannover.de> Date: Tue, 5 Nov 2002 18:50:14 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <200211042333.19012.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211042333.19012.cedric.bail@free.fr>; from cedric on Mon, Nov 04, 2002 at 11:34:36PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 04, 2002 at 11:34:36PM +0000, cedric wrote: > On the French mailing-list Antoine () has suggested a new > idea for the call convention. At the beginning it just say that it was a > funny idea, but it could be very interresting finally. > So he suggest to specify a new register MR (mask register). Each bit in this > register specify if the corresponding register need to be saved or not before > using it. In the prologue of a function you make a "and" between the MR and a > local constant that represent which register are used, then you conditionally > load register to stack if a collision occur. Finally in the epilogue you > restore register with the same idea. > When you call a function you update mr with something like this : > mr = mr | register to preserve. Of course this mask can evolve during the > function. > If you "randomly" select which register to use (when you don't which function > call me), you have some chance that no collision occur (You have more in most > case a chance that not a full collision occur). A second possibility when you > allocated your registers is to use feedback from run-time, but each time you > compile and run, you can have some different result... [snip] First, a decent F-CPU compiler should not select registers randomly. It should analyze every function and assign register numbers so that chances for a collision are minimized. That is, in a module containing several functions that call each other, each function should use a different set of registers. Additionally, functions can have both an "internal" entry point for intra-module calls (which need not save any registers) and a "public" entry point that saves all registers used inside it, prepares for restoring them, and then dispatches to the internal entry point. Unless there are recursive functions, you'll have to save registers only when you enter the module (and restore them when you leave it). Ideally, each function will use a contiguous set of registers, and there will be an entry in the object file reporting which registers it uses. That way it becomes possible to further minimize collisions at link time by renumbering the registers inside a function - you may also call it "deferred register allocation" if you like. Consider three functions A, B and C. A uses r16-r19, B uses r16-r21, and C uses r16 and r17. If the functions do not depend on each other (that is, don't call each other), you can simply link them together, and the resulting set of used registers will be the union of the functions' individual sets, that is, r16-r21. If function C calls A but not B, you can rename registers and assign r20 and r21 to C, and the resulting common set still is r16-r21. If C calls both A and B, it is assigned r22 and r23, and the resulting common set is r16-r23. In either case, there will be no register collisions between the functions. Only if caller and callee together need more than the number of available registers, the linker will have to put save/restore code (since the register sets are contiguous, storem/loadm will do the trick) "around" the callee: new_entry_point: // allocate stack space here storem xyz move r63, saved_reg // save return address loadaddri old_entry_point, temp_reg jump temp_reg, r63 // call original function restore_code: move saved_reg, r63 // restore return address loadm xyz // deallocate stack space here jump r63 (This is generic code that may still be improved) The same algorithm works with both functions and modules, and it only needs the set of used registers per function/module and a dependency graph. Both can be easily constructed from intermediate code. Register renumbering is done on the object code directly (thanks for the uniform register model and instruction format of the F-CPU which allow us to `transpose' the object code -- note to guitar players: think `capo' ;-). Conclusion: Using a smart linker, we can resolve register collision issues statically. We can also take profiling (feedback) information into account, like you suggested, to optimize the number and placement of save/restore points. Therefore, I see no real need to do it at run time. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Nov 6 21:28:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189Aq3-0000G4-00 for ; Tue, 05 Nov 2002 22:02:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Nov 2002 22:02:19 +0100 (CET) Received: (qmail 1048 invoked by uid 0); 5 Nov 2002 20:25:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 5 Nov 2002 20:25:08 -0000 Received: by moria.seul.org (Postfix) id B0E1615E727; Tue, 5 Nov 2002 15:25:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91D9E15E72A; Tue, 5 Nov 2002 15:25:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 3F57C15E727 for ; Tue, 5 Nov 2002 15:25:07 -0500 (EST) Received: from Biathlon (vlt4-147.n.club-internet.fr [194.158.109.147]) by relay-5v.club-internet.fr (Postfix) with SMTP id 7D33316AF for ; Tue, 5 Nov 2002 21:25:06 +0100 (CET) Date: Wed, 6 Nov 2002 21:28:01 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Message-Id: <20021106212801.3ac51163.nicolas.boulay@ifrance.com> In-Reply-To: <3DC707C3.3050606@f-cpu.org> References: <200211042333.19012.cedric.bail@free.fr> <3DC707C3.3050606@f-cpu.org> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 05 Nov 2002 00:50:27 +0100 Yann Guidon wrote: > hi, > > cedric wrote: > > >Hi everybody, > > > > On the French mailing-list Antoine () has suggested a new > >idea for the call convention. At the beginning it just say that it was a > >funny idea, but it could be very interresting finally. > > > and in the end, it can be disapointing. > > > So he suggest to specify a new register MR (mask register). Each bit in this > >register specify if the corresponding register need to be saved or not before > >using it. In the prologue of a function you make a "and" between the MR and a > >local constant that represent which register are used, then you conditionally > >load register to stack if a collision occur. Finally in the epilogue you > >restore register with the same idea. > > When you call a function you update mr with something like this : > >mr = mr | register to preserve. Of course this mask can evolve during the > >function. > > If you "randomly" select which register to use (when you don't which function > >call me), you have some chance that no collision occur (You have more in most > >case a chance that not a full collision occur). A second possibility when you > >allocated your registers is to use feedback from run-time, but each time you > >compile and run, you can have some different result... > > With this idea came 2 different call convention proposition : > > - 15 parameters registers > > - 16 temporary registers > > - 26 mask saved registers > > - 6 "system" registers (mr, plt, got, fp, sp, ra) > > Or : > > - 7 parameters registers > > - 8 temporary registers > > - 42 mask saved register > > - 6 "system" registers > > I prefer the second solution, but that's only my point of view. And perhaps > >some other can be better. > > > > > one could choose to use the middle : 32 mask saved registers ?.... > > > Too use this mr, we need some instructions. Antoine first suggest to use a > >maskload and a maskstore. This instruction will act like a storem/loadm but > >with the mask technique. > > > in fact it is more complex because for each un/masked register, it does > both the pointer increment and the memory access. The pointer thing > makes the whole thing even more complex that loadm/storem/whatever. > > > > >The problem of the first solution are : > >- complexity > >- popcount unit must not be optional > >- block the CPU for 3/4 cycles (before being sure that no TLB trap append) > > > > > not only that, but : > - instruction lifelength is not static ==> more difficult to decode and > schedule ??? I need to see a proof of that. > - instruction cannot be interrupted in the middle > (IRQ/whatever) ==> IRQ response time is unpredictable :-( Like our /0 trick, the pipeline should check IRQ first. And then the following stay asynchronous. > - it can't be pipelined (issued and then another instruction can be > decoded) It could. Where is the probleme ? You have to play with a contention on the register bank. > - the read port is connected to the instruction buffer ==> it is not > possible > to generate the sequence of registers to be saved. And even a counter > would > not be ok (in order to generate the register numbers), because the > mask can > have holes ! You could mask hole. But then you loose cycle. I'm pretty sure that a "sequencer generator" could be used. > > >For the second solution : > >- complexity > >- popcount unit must not be optional > >- block the CPU for 3/4 cycles like the first solution, but you need to use > >this instruction more frequently than the previous solution, but this > >solution give you the possibility to pass a chunk if not needed. > > > > > same remarks as before. > it's multicycle, CISC instrtuction with most of the problems. the biggest probleme is the connection of the read/write port that annoyed instruction buffer but that the case of SRB, too. > > >The last solution : > >- stack problem (same problem as storei/loadi that need when you are change > >direction to add an instruction for alignment) > >- In big function you need to call it a lot > > > > > there is also : > - it is more complex and heavy than a classical store/load with > post-incrementation with the same result (except that it is conditionnal) > - there are not enough register set ports to allow all the writes at > the same time. > Since this kind of instructions is used in bursts, it's a big problem > because > the differing latencies can't be hidden by other instructions that > don't use all the > write ports. > > >>From a software point of view I prefer the first solution from Antoine, but it > >can be a mess to implement it in hardware ! > > > it is. > > > What are your point of view about > >this and what did you think about this idea. > > > > > I am completely against this idea in F-CPU up to v.1 and in FC0, where > the pipeline > is not adapted at all for these kinds of CISC gymnastics. > > BTW, there was also the evocation of using SRB for doing the > backup/restore, but > there are a lot of problems as well, do you'd better not think of it. > > > Not really linked with this discussion, it appear that when you only want to > >load a constant that is bigger than 8 bits, but smaller than 64 bits, you > >always need to do a move r0, your_constant. I think it will be a good idea to > >add a loadconsz that will set all the chunk to zero before putting his > >immediate value. > > > > > Here is what i remember : > loadcons doesn't sign extend the constant. > loadconsx does it. > > >Sorry for this long, but I hope it could be interresting, > > Cedric > > > well, at last it made it to this list. > > YG Maybe the idea of Michael is better (SW). It's okay if the linker could really do the job. Otherwise... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Tue Nov 5 22:11:50 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189Frx-0003u2-01 for ; Wed, 06 Nov 2002 03:24:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 03:24:37 +0100 (CET) Received: (qmail 3783 invoked by uid 0); 5 Nov 2002 21:12:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 5 Nov 2002 21:12:20 -0000 Received: by moria.seul.org (Postfix) id AC6FA15E721; Tue, 5 Nov 2002 16:12:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 93C6A15E72A; Tue, 5 Nov 2002 16:12:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 55F3F15E721 for ; Tue, 5 Nov 2002 16:12:18 -0500 (EST) Received: from telehouse-102-2-127.net1.nerim.net (telehouse-102-2-127.net1.nerim.net [213.41.189.127]) by kraid.nerim.net (Postfix) with ESMTP id 143F240E32 for ; Tue, 5 Nov 2002 22:02:30 +0100 (CET) Subject: Re: [f-cpu] New suggestion about call convention From: Antoine To: f-cpu@seul.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 05 Nov 2002 22:11:50 +0100 Message-Id: <1036530711.3376.39.camel@fsol> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, Just my two cents... About the idea that register optimization could be done at linking time. I don't know if F-CPU is meant to work as an isolated architecture, with only dedicated tools. But if you want to benefit from existing software, you must think in terms of compatibility with the Gnu tools. That means : - compiler capabilities - linker capabilities - object file format (ELF, etc.) I'd bet (but I may be wrong ;-)) that none of those are ready for such a thing as link-time or load-time register reallocation. I'd also bet that if nobody does it at the moment, maybe it's because there are serious problems with it (despite the fact that compilation time is cheap so there is much incentive to optimize as far as possible in this phase). For once the optimization problem itself doesn't seem very simple, especially when programs get big. An example is the mysql daemon (which is a respectable database, but not a big and featureful monster as Postgres or Oracle). [root@fsol antoine]# strip -s /usr/sbin/mysqld [root@fsol antoine]# ls -la /usr/sbin/mysqld -rwxr-xr-x 1 root root 1957780 nov 5 21:38 /usr/sbin/mysqld* This is quite a big executable indeed. Of course there is not only code. Given that stuff other than code (strings, empty data...) is likely to be highly compressable, we can still estimate an order of magnitude of the actual code : [antoine@fsol antoine]$ gzip -c /usr/sbin/mysqld > mysqld [antoine@fsol antoine]$ ls -la mysqld -rw-rw-r-- 1 antoine antoine 871030 nov 5 21:48 mysqld So we can, quite safely, assume that the mysqld code (again, not that a big database program compared to others) is several hundreds of kilobytes big (and this would probably be worse on a RISC machine, with lots of small instructions using lots of registers !). I don't think it's reasonable to expect processing some global register allocation (how do you do that ? ;-)) on such a big piece of code. Also, keep in mind that registers may have a special role and not be easily exchangeable (not really the case in F-CPU, except for instructions that also write to the register next to the output register). (note : mysqld is a practical example because it is completely standalone - even a custom glibc is statically linked -, so there is no "hidden cost") Another strong argument is that you can't even be sure that there is a good solution to the optimization problem (even if you have invented an outstanding algorithm that makes you sure to find the optimum, and maybe it also helps you demonstrate that P==NP at the same time :-)). The optimum may be not much better than the common case. For example, if you have three functions (A, B, C) that each allocate 32 different registers. B calls C. A calls in turn : C then B. So sometimes C is called from B which is called from A, sometimes C is called directly from A. How do you think the optimal solution will look like, and will that optimality be satisfactory ? (if you optimize C for being called by B, it won't be optimized for being called by A, and vice-versa ; of course, you can duplicate C in two versions but beware of cache thrashing, given that this is a very simple example) Antoine. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Nov 5 23:29:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189Fs0-0003u2-00 for ; Wed, 06 Nov 2002 03:24:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 03:24:40 +0100 (CET) Received: (qmail 4290 invoked by uid 0); 5 Nov 2002 21:38:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 5 Nov 2002 21:38:56 -0000 Received: by moria.seul.org (Postfix) id 49CEA15E728; Tue, 5 Nov 2002 16:38:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1438815E72B; Tue, 5 Nov 2002 16:38:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 8F5E415E728 for ; Tue, 5 Nov 2002 16:38:54 -0500 (EST) Received: from thor (84.188.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.188.84]) by smtp3.9tel.net (Postfix) with ESMTP id BD4D75BD9A for ; Tue, 5 Nov 2002 22:38:53 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Date: Tue, 5 Nov 2002 22:29:00 +0000 User-Agent: KMail/1.4.3 References: <200211042333.19012.cedric.bail@free.fr> <20021105185014.20040@thrai.stud.uni-hannover.de> In-Reply-To: <20021105185014.20040@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211052229.00764.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > First, a decent F-CPU compiler should not select registers randomly. > It should analyze every function and assign register numbers so that > chances for a collision are minimized. It depend if you have knowledge about what the other module librairie do. You will certainly agree that if you don't have any knowledge about the register usage, random is the best solution. > That is, in a module containing several functions that call each other, > each function should use a different set of registers. Additionally, > functions can have both an "internal" entry point for intra-module calls > (which need not save any registers) and a "public" entry point that > saves all registers used inside it, prepares for restoring them, and > then dispatches to the internal entry point. Unless there are recursive > functions, you'll have to save registers only when you enter the module > (and restore them when you leave it). It's a good idea for having quick call intra-module. The problem is in the epilogue, how did you know from where you came ? > Ideally, each function will use a contiguous set of registers, and there > will be an entry in the object file reporting which registers it uses. > That way it becomes possible to further minimize collisions at link time > by renumbering the registers inside a function - you may also call it > "deferred register allocation" if you like. It's an interesting idea, but for each instruction in each function in each module you need to search in a "database" which chunk to replace and then replace it with a mask. But before taking your decision you need to execute a allocation algorithm. Currently, with only relocation on x86, a lot of people are thinking that time needed by linking is slow... But the idea is good, what did you think about a double solution : for .o (not librairie), you use your technique and for the rest the technique suggested by Arnaud. In the prologue you use the mask technique and put a second entry point for optimal call. (I don't see why you need to have contiguous register, you only need a 64 bits mask per function, so 2 techniques can be used together). > new_entry_point: > // allocate stack space here > storem xyz > move r63, saved_reg // save return address > loadaddri old_entry_point, temp_reg > jump temp_reg, r63 // call original function > restore_code: > move saved_reg, r63 // restore return address > loadm xyz > // deallocate stack space here > jump r63 Problem with this is that you have a double jump each time you call a function outside of your module. Why didn't you use something like this : low_entry_point: storei +8, [sp], r63 loadaddri restore_code, r63 loadcons.1 0xFFFF, r0 loadcons.2 0xFFFF, r0 loadcons.3 0xFFFF, r0 and r0, mr, r1 maskstore r1, [sp] quick_entry_point: // My function jmp r63 restore_code: loadcons.1 0xFFFF, r0 loadcons.2 0xFFFF, r0 loadcons.3 0xFFFF, r0 and r0, mr, r1 maskload r1, [sp] loadi -8, [sp], r0 ; I didn't like this piece of code loadi -8, [sp], r63 jmp r63 With this you have both possibility. In fact you don't need to add a jump for entry point with your method too, because you can add the 2 entries points when you compile. A possibility to improve your idea is to specify a other registre Quick Entry, if qe == r0 => don't restore else restore so the epilogue/prologue will look like : low_entry_point: loadcons.1 0xFFFF, r0 loadcons.2 0xFFFF, r0 loadcons.3 0xFFFF, r0 and r0, mr, r1 maskstore r1, [sp] quick_entry_point: // My function jmpz qe, r63 restore_code: loadcons.1 0xFFFF, r0 loadcons.2 0xFFFF, r0 loadcons.3 0xFFFF, r0 and r0, mr, r1 maskload r1, [sp] jmp r63 > The same algorithm works with both functions and modules, and it only > needs the set of used registers per function/module and a dependency > graph. Both can be easily constructed from intermediate code. Register > renumbering is done on the object code directly (thanks for the uniform > register model and instruction format of the F-CPU which allow us to > `transpose' the object code -- note to guitar players: think `capo' ;-). I don't understood you here, we have a lot of different instruction : 2r1w, 1i1w, 1i1r, 1i1r1w, 3r2w... For each you have a special case. > Conclusion: Using a smart linker, we can resolve register collision > issues statically. We can also take profiling (feedback) information > into account, like you suggested, to optimize the number and placement of > save/restore points. Therefore, I see no real need to do it at run time. The problem is doing a optimising linker will really improve the code, but will not work for shared code (librairie are loaded only once) and will certainly be really slow for big code... The mr is not as optimal as your proposition but didn't cost so much each time you run a application. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From usman1926@mailsurf.com Fri Oct 25 14:50:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RI7-0000G1-00 for ; Wed, 06 Nov 2002 15:36:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:23 +0100 (CET) Received: (qmail 16654 invoked by uid 0); 6 Nov 2002 03:09:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 6 Nov 2002 03:09:22 -0000 Received: by moria.seul.org (Postfix) id BC3F015E720; Tue, 5 Nov 2002 22:09:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A692515E727; Tue, 5 Nov 2002 22:09:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 6825B15E720 for ; Tue, 5 Nov 2002 22:09:20 -0500 (EST) Received: from n2now2459.com ([217.78.76.157]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id gA638cn02561 for ; Tue, 5 Nov 2002 22:08:45 -0500 Message-Id: <200211060308.gA638cn02561@belegost.mit.edu> From: "Barrister Usman Rabiu [LLB]" To: f-cpu@seul.org Date: Fri, 25 Oct 2002 14:50:25 +0200 Subject: [f-cpu] Awaiting Your Response X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N URGENT REQUEST I am a Solicitor resident and practicing in Lagos=2C Nigeria and I am using this correspondence to urgently seek and request your assistance and cooperation in a sensitive but highly beneficial financial arrangement=2E An important client of mine whose details and person I cannot release at this point has implored me to contact a reliable and trustworthy partner overseas to urgently receive and handle funds total FIFTEEN MILLION US DOLLARS=28US$15=2EM=29in CASH presently lodged in a security=2Ffinance outfit in overseas=2E Due to my client inability to travel out of the country presently and the fact that we continue to accumulate huge debts daily as long as this consignment remains in the security=2Ffinance company we need an associate and partner to proceed as soon as possible to receive this funds for investment purpose as shall be instructed by my client=2E We have agreed in principle to give twenty-five percent =2825%=29 of the total sum to whom ever shall handle this funds for us while the remaining sixty-five percent =2865%=29shall be for my client and ten-percent =2810%=29 for me as the attorney=2E As soon as you are ready to proceed to receive this cash on our behalf we shall furnish you with the details and information you will need to accomplish this task=2E Please be rest assured that this arrangement is absolutely risk free And cannot implicate you in any way=2E However I implore you to handle this matter with urgency and utmost confidence even if you do not intend to execute the project for us=2E Whatever the case=2C please acknowledge receipt of this mail via the my Email address=2E If your response is positive we shall proceed immediately without any delay=2E Thank you in anticipation of your cooperation and hoping to hear from you soonest=2E Yours sincerely=2C Barrister Usman Rabiu =28LLB=29=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tmwwyc@hotmail.com Wed Nov 6 06:44:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIC-0000G1-00 for ; Wed, 06 Nov 2002 15:36:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:28 +0100 (CET) Received: (qmail 22784 invoked by uid 0); 6 Nov 2002 05:50:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 6 Nov 2002 05:50:16 -0000 Received: by moria.seul.org (Postfix) id 02D2B15E725; Wed, 6 Nov 2002 00:50:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DB0A915E728; Wed, 6 Nov 2002 00:50:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id F0F0115E721; Wed, 6 Nov 2002 00:50:13 -0500 (EST) Received: from chat.ru (unknown [213.82.33.50]) by bettik.munge.net (Postfix) with SMTP id C86944F794; Tue, 5 Nov 2002 23:49:40 -0600 (CST) From: Alex Subject: [f-cpu] Áàçû äàííûõ Ìîñêâû è Ðîññèè (ñâåæèå îáíîâëåíèÿ) . TMWWYCKBXD X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Wed, 6 Nov 2002 08:44:46 +0300 Message-Id: <20021106054940.C86944F794@bettik.munge.net> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ÐÓÊÎÂÎÄÈÒÅËÞ, ÁÓÕÃÀËÒÅÐÓ, ÍÀ×ÀËÜÍÈÊÓ ÑÁ ======================================= Ïðåäëàãàåì êîìïüþòåðíûå CD-ROM äèñêè (çà íàëè÷íûé ðàñ÷åò): 1. "Ìàññîâûå Ðàññûëêè - Ìîñêâà" 130.000 ôàêñîâ Ìîñêâû è Îáëàñòè + 60.000 àäðåñîâ E-mail ïî ôèðìàì ã. Ìîñêâû + íåîáõîäèìîå ïðîãðàììíîå îáåñïå÷åíèå + èíñòðóêöèè ê ïðîãðàììàì íà ðóññêîì ÿçûêå. Öåíà: 1000ð. (1 CD) ******************** 2. "Ìàññîâûå Ðàññûëêè - Ðîññèÿ" 1.370.000 àäðåñîâ E-mail ïî Ðîññèè + 22.000 àäðåñîâ E-mail ïî ôèðìàì Ñàíêò-Ïåòåðáóðãà + 30.000 àäðåñîâ E-mail ïî Åâðîïå + ïðîãðàììà ðàññûëêè + èíñòðóêöèÿ íà ðóññêîì ÿçûêå. Öåíà: 1000ð. (1 CD) ******************** 3. "ÅÃÒÑ 16.3" Ñîäåðæèò îáíîâëåííóþ èíôîðìàöèþ (îáíîâëåíû äàííûå ïî âëàäåëüöàì òåëåôîíîâ - ÷àñòíûì ëèöàì ñ óêàçàíèåì ÔÈÎ è äàòû ðîæäåíèÿ) î òåëåôîíàõ ÷àñòíûõ ëèö è ó÷ðåæäåíèé, ñîòîâûõ òåëåôîíîâ è òàêñîôîíîâ ïî Ìîñêîâñêîìó ðåãèîíó. Ðàáîòàåò ñ CD â ñðåäå DOS è Windows. Äàííûå äî àâãóñòà 2001 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 4. "ÊÎÒÈÊ-2" Íîâåéøàÿ òåëåôîííàÿ áàçà ïî ã. Ìîñêâå è Ìîñêîâñêîé îáëàñòè. Îáíîâëåííàÿ èíôîðìàöèÿ ïî òåëåôîííûì íîìåðàì ðàéîíîâ: Æóëåáèíî, Ìèòèíî, Áóòîâî, Ñòðîãèíî è ò.ä. Òðåáóåò íàëè÷èÿ MS Access è 3 Ãá íà æåñòêîì äèñêå. Äàííûå íà èþëü 2002 ãîäà. Öåíà: 2000ð. (1 CD) ******************** 5. "Ìîñêîâñêàÿ Íåäâèæèìîñòü" ÁÄ Ìîñêîìèìóùåñòâà. Àðåíäàòîðû è ñîáñòâåííèêè íåæèëûõ ïîìåùåíèé ã. Ìîñêâû. Ïîäðîáíàÿ èíôîðìàöèÿ ïî ëþáîìó àðåíäàòîðó è ñîáñòâåííèêó. Äàííûå íà 1999 ãîä. Öåíà: 1000ð. (1 CD) ******************** 6. "Ñîáñòâåííèêè Ìîñêîâñêèõ Êâàðòèð" Èíôîðìàöèÿ î âëàäåëüöàõ êâàðòèð â ã.Ìîñêâå, ñ óêàçàíèåì ïàñïîðòíûõ äàííûõ, äàòû ïðèâàòèçàöèè (ïîêóïêè), äðóãèõ ñîâëàäåëüöåâ è ò.ä. Ðàáîòàåò ñ CD â ñðåäå DOS è Windows. Äàííûå íà àïðåëü 2000 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 7. "Æèëîé Ôîíä Ìîñêâû" Áàçà Ìîñêîâñêîãî Äåïàðòàìåíòà Ìóíèöèïàëüíîãî Æèëüÿ. Ðàáîòàåò â ñðåäå Windows, òðåáóåò 900Ìá ñâîáîäíîãî ïðîñòðàíñòâà íà æåñòêîì äèñêå. Äàííûå äî ôåâðàëÿ 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 8. "Àâòîìîáèëè - 2002" Èíôîðìàöèÿ î âëàäåëüöå àâòîòðàíñïîðòà è åãî ìàøèíå (â ò.÷. ÔÈÎ, òåëåôîí, àäðåñ, ïàñïîðòíûå äàííûå è ò.ä.) ïî ã. Ìîñêâå.  ò.÷. ïðîäàííûå è ñíÿòûå ñ ó÷åòà ìàøèíû. Ðàáîòàåò â ñðåäå Windows. Òðåáóåò 3Ãá ñâîáîäíîãî ïðîñòðàíñòâà íà æåñòêîì äèñêå. Äàííûå íà îêòÿáðü 2002 ãîäà. Öåíà: 1000ð. (2 CD) ******************** 9. "Àâòîìîáèëè Ìîñêîâñêîé Îáëàñòè - 2002" Èíôîðìàöèÿ î âëàäåëüöå àâòîòðàíñïîðòà è åãî ìàøèíå (â ò.÷. ÔÈÎ, òåëåôîí, àäðåñ, ïàñïîðòíûå äàííûå è ò.ä.) ïî Ìîñê. Îáë.  ò.÷. ïðîäàííûå è ñíÿòûå ñ ó÷åòà ìàøèíû. Òðåáóåò 2Ãá ñâîáîäíîãî ìåñòà íà æåñòêîì äèñêå. Äàííûå íà ôåâðàëü 2002 ãîäà. Öåíà: 1000ð. (2 CD) ******************** 10. "Âîäèòåëüñêèå ïðàâà" Áàçà ïî âëàäåëüöàì âîäèòåëüñêèõ ïðàâ â Ìîñêâå. Äàííûå íà ñåíòÿáðü 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 11. "ÌÐÏ" Áàçà Ìîñêîâñêîé Ðåãèñòðàöèîííîé Ïàëàòû ïî þðèäè÷åñêèì ëèöàì ã. Ìîñêâû. Ñîäåðæèò äàííûå îá ó÷ðåäèòåëÿõ è ó÷ðåæäåííûõ îðãàíèçàöèÿõ. Ðàáîòàåò â DOS è Windows. Äàííûå íà àïðåëü 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 12. "Àíàëèç âçàèìîäåéñòâèÿ ïðåäïðèÿòèé Ìîñêâû" Áàçà ïî ïðåäïðèÿòèÿì ã. Ìîñêâû ñ ïîëíîé èíôîðìàöèåé îá ó÷ðåäèòåëÿõ è ó÷ðåæäåííûõ îðãàíèçàöèÿõ â ò.÷. äî÷åðíèõ. Òðåáóåò íàëè÷èÿ MS Access è 1,3 Ãá íà æåñòêîì äèñêå. Äàííûå íà èþíü 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 13. "Àíàëèç âçàèìîäåéñòâèÿ ïðåäïðèÿòèé Ìîñêîâñêîé îáëàñòè" Áàçà ïî çàðåãèñòðèðîâàííûì â Ìîñê. îáëàñòè þðèäè÷åñêèì ëèöàì. Äàííûå äî àïðåëÿ 2002 ã. Öåíà: 1000ð. (1 CD) ******************** 14. "Áèçíåñ Èíôî (ðåãèîíû Ðîññèè)" Âêëþ÷àåò â ñåáÿ: 1) Èíôîðìàöèÿ î þðèäè÷åñêèõ ëèöàõ êðóïíûõ ãîðîäîâ Ðîññèè (â ò.÷. ÔÈÎ, ïàñïîðòíûå äàííûå ó÷ðåäèòåëåé, òåëåôîíû, þðèäè÷åñêèé àäðåñ, áàíêîâñêèå ðåêâèçèòû è ò.ä.) 2) Áàçû Ðåãèñòðàöèîííîé Ïàëàòû Ñàíêò-Ïåòåðáóðãà (èþíü 2002 ã.) 3) Áàçà ÃÍÈ Ñàíêò-Ïåòåðáóðãà (èþíü 2002 ã.) 4) "Ïðåäïðèÿòèÿ Ðîññèè è ÑÍÃ". Âêëþ÷àåò èíôîðìàöèþ: íàçâàíèå, ðåãèîí, àäðåñ, òåëåôîí, ôàêñ, Ô.È.Î. ðóêîâîäèòåëÿ, èíôîðìàöèÿ î ïðîäóêöèè è óñëóãàõ è ò.ä. 5) Áàçà "Ïðîìûøëåííîñòü Ðîññèè". 6) Ñïðàâî÷íèê ïî íåçàâèñèìûì ïðîèçâîäèòåëÿì òîâàðîâ è óñëóã. Öåíà: 1000ð. (3 CD) ******************** 15. "ÃÎÑÊÎÌÑÒÀÒ" Áàçà äàííûõ Ãîñêîìñòàòà ïî Ìîñêâå. Îñíîâíàÿ èíôîðìàöèÿ ïî ïðåäïðèÿòèÿì - àäðåñ, òåëåôîí, ïðèñâîåííûå êîäû è ò.ä. Ðàáîòàåò ñ CD â ñðåäå Windows. Äàííûå íà ìàé 2000 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 16. "ÃÒÊ-2000" ÁÄ ïî ýêñïîðòíî-èìïîðòíûì îïåðàöèÿì, ïðîèçâåäåííûì ïî Ðîññèè çà 2000 ãîä. Òðåáóåò 1,4Ãá íà æåñòêîì äèñêå, ðàáîòàåò â ñðåäå Dos è Windows. Äàííûå íà âåñü 2000 ãîä. Öåíà: 1000ð. (2 CD) ******************** 17. "ÃÒÊ-2001" ÁÄ ïî ýêñïîðòíî-èìïîðòíûì îïåðàöèÿì, ïðîèçâåäåííûì ïî Ðîññèè çà 2001 ãîä. Äîáàâëåí ïîèñê ïî êîäó ÒÍÂÝÄ è ïî íîìåðó ÃÒÄ! Òðåáóåò 3Ãá íà æåñòêîì äèñêå. Windows-âåðñèÿ. Äàííûå íà âåñü 2001 ã. Öåíà: 2000ð. (2 CD) ******************** 18. "ÃÒÊ-2002" ÁÄ ïî ýêñïîðòíî-èìïîðòíûì îïåðàöèÿì, ïðîèçâåäåííûì ïî Ðîññèè çà 2002 ãîä. Òðåáóåò 2Ãá íà æåñòêîì äèñêå, ðàáîòàåò â ñðåäå Windows. Äàííûå äî 15 ñåíòÿáðÿ 2002 ã. Öåíà: 2000ð. (1 CD) ******************** 19. "Ìîñêâà 2000" Ñîäåðæèò èíôîðìàöèþ î 12 000 000 æèòåëÿõ Ìîñêâû - ÔÈÎ, ïîë, ïðîïèñêà, äàòà ðîæäåíèÿ. Äîáàâëåí ïîèñê ïî àäðåñó. Ðàáîòàåò ñ CD â ñðåäå DOS è Windows. Äàííûå íà íîÿáðü 2000 ãîäà. Öåíà: 1000ð. (2 CD) ******************** 20. "Îáëàñòü 2002" Ñîäåðæèò èíôîðìàöèþ î æèòåëÿõ Ìîñêîâñêîé Îáëàñòè, âêëþ÷àþùóþ ÔÈÎ, ïîë, ìåñòî æèòåëüñòâà, äàòó ðîæäåíèÿ. Âîçìîæåí ïîèñê ïî àäðåñó, ÔÈÎ è ò.ä. Ðàáîòàåò ñ CD â ñðåäå DOS è Windows. Äàííûå íà èþíü 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 21. "Àíòèêðèìèíàë" Ñîäåðæèò 12 áàç: 1) Ñâîäêè ÃÓÂÄ çà ïîñëåäíèå 7 ëåò. 2) "Ôåäåðàëüíûé ðîçûñê ëèö" (èþíü 2002 ãîäà) Îïåðàòèâíàÿ áàçà äàííûõ ïî ëèöàì, íàõîäÿùèìñÿ â ôåäåðàëüíîì ðîçûñêå. 3) "Ðîçûñê-Ñóäèìîñòü" 4) "Àâòîìîáèëè-ðîçûñê" (îêòÿáðü 2002 ãîäà.) Îïåðàòèâíàÿ áàçà äàííûõ ïî óãíàííûì àâòîìîáèëÿì, ïîõèùåííûì äîêóìåíòàì íà àâòîìîáèëè (òåõ.ïàñïîðòàì, âîäèòåëüñêèì óäîñòîâåðåíèÿì, ÒÎ è ò.ä.) Îõâàòûâàåò âñþ òåððèòîðèþ áûâøåãî ÑÍÃ. Ðàáîòàåò â ñðåäå Windows, òðåáóåò 700Ìá ìåñòà íà æåñòêîì äèñêå. 5) "Äîðîæíî-òðàíñïîðòíûå ïðîèñøåñòâèÿ" (îêòÿáðü 2001 ãîäà) Áàçà äàííûõ ÄÒÏ ïî ã. Ìîñêâå. Ñîäåðæèò ñâåäåíèÿ î òðàíñïîðòíûõ ñðåäñòâàõ è ãðàæäàíàõ, ïîïàâøèõ â ÄÒÏ. 6) "Çàïèñíûå êíèæêè". Ñâåäåíèÿ ïî âëàäåëüöàì èçúÿòûõ çàïèñíûõ êíèæåê, òåëåôîííî-àäðåñíàÿ èíôîðìàöèÿ ñ êîììåíòàðèÿìè. 7) Áàçà ïî àäìèíèñòðàòèâíûì ïðàâîíàðóøåíèÿì 8) ÎÏÃ. 9) "Ïîõèùåííûå ïàñïîðòà". 10) Äîëæíèêè ÃÍÈ. 11) "ËÀÁÈÐÈÍÒ". 12) Òåëåôîííûé ñïðàâî÷íèê âåäîìñòâ è êðóïíåéøèõ ïðåäïðèÿòèé ÐÔ-99. 13) ×àñòíûå îõðàííûå ïðåäïðèÿòèÿ Àêòóàëüíîñòü êîìïëåêòà - ñåðåäèíà 2000 ã. - èþíü 2002 ã. Öåíà: 2000ð. (4 CD) ******************** 22. "ÎÂÈÐ" Áàçà äàííûõ ÎÂÈÐ. Ðàáîòàåò ñ CD â ñðåäå DOS è Windows. Äàííûå íà 1999 ãîä. Öåíà: 1000ð. (1 CD) ******************** 23. "Áàíêè Ðîññèè" Ñîäåðæèò: èíôîðìàöèþ îá ó÷ðåäèòåëÿõ, óñòàâíîì ôîíäå, ïóáëèêàöèè â ïðåññå, àäðåñà, òåëåôîíû, ôàêñû, ýëåêòðîííûå àäðåñà è ò.ä. Äàííûå íà ñåíòÿáðü 2002 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 24. Ýëåêòðîííàÿ áèáëèîòåêà íîðìàòèâíûõ äîêóìåíòîâ ïî ñòðîèòåëüñòâó (êîíåö 2000 ãîäà) ÃÎÑÒû, ÑÍÈÏû, Êîíñòðóêöèè, Ïðàâèëà, Ïðèêàçû, Ñïðàâî÷íèêè, Ïîñîáèÿ, Èíñòðóêöèè, Ïðèëîæåíèÿ, ÒÎÈ, ÒÑÍ, ÐÑÍ è ìíîãîå äðóãîå). Öåíà: 2000ð. (5 CD) ******************** 25. "Ìîñêîìçåì-2001". Áàçà äàííûõ Ìîñêîâñêîãî Çåìåëüíîãî Êîìèòåòà ïî ñîáñòâåííèêàì çåìåëüíûõ ó÷àñòêîâ â ã. Ìîñêâå. Äàííûå íà àâãóñò 2001 ãîäà. Öåíà: 1000ð. (1 CD) ******************** 26. "Àðõèâ Ðîññèéñêîé Ïðåññû" Ñîäåðæèò â òåêñòîâîì ôîðìàòå îêîëî 3.000.000 ñòàòåé âñåõ êðóïíûõ ïåðèîäè÷åñêèõ èçäàíèé Ðîññèéñêîãî ðåãèîíà çà ïåðèîä 1995 - èþëü 2002 ã. Âåñü àðõèâ îáúåäèíåí â åäèíóþ óäîáíóþ îáîëî÷êó ñ âîçìîæíîñòüþ ðàñøèðåííîãî ïîèñêà. Òðåáóåò 5Gb íà æåñòêîì äèñêå. Öåíà: 3000ð. (8 CD) ******************** 27. "ÖÀÁ Ñàíêò-Ïåòåðáóðãà". Áàçà äàííûõ ïî ôèçè÷åñêèì ëèöàì Ñàíêò-Ïåòåðáóðãà. Âîçìîæåí ïîèñê ïî ôàìèëèè, àäðåñó, òåëåôîíó. Òðåáóåò 1,5 Gb ñâîáîäíîãî ïðîñòðàíñòâà íà æåñòêîì äèñêå. Äàííûå íà îêòÿáðü 1999 ãîäà. Öåíà: 1000ð. (1 CD) ******************** ÏÐÈ ÏÎÊÓÏÊÅ ÏßÒÈ È ÁÎËÅÅ ÏÎÇÈÖÈÉ - ÇÍÀ×ÈÒÅËÜÍÀß ÑÊÈÄÊÀ! Íàø Òåëåôîí: (095) 797-0008 (Îñòàâëÿéòå ñîîáùåíèå íà àâòîîòâåò÷èê, óêàçàâ òåëåôîí, êîíòàêòíîå ëèöî è èíòåðåñóþùèå Âàñ ïîçèöèè ïðàéñ-ëèñòà) !!! Âíèìàíèå! Ïðîñèì Âàñ íå îòïðàâëÿòü Âàøè çàêàçû íà E-Mail, à ïîëüçîâàòüñÿ òîëüêî àâòîîòâåò÷èêîì! [T93M90W110W91Y102C73K77B70X94D73V90F70X94N83H77G71D69P82] ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 15:43:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIQ-0000G1-00 for ; Wed, 06 Nov 2002 15:36:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:42 +0100 (CET) Received: (qmail 24339 invoked by uid 0); 6 Nov 2002 10:43:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 6 Nov 2002 10:43:14 -0000 Received: by moria.seul.org (Postfix) id 727F215E727; Wed, 6 Nov 2002 05:43:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 321F915E72B; Wed, 6 Nov 2002 05:43:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 8628215E727 for ; Wed, 6 Nov 2002 05:43:12 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-4v.club-internet.fr (Postfix) with SMTP id 3704C169D for ; Wed, 6 Nov 2002 11:43:11 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 11:43:11 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 i'm trying to catch up on my mail .... >De: Michael Riepe >On Mon, Nov 04, 2002 at 11:34:36PM +0000, cedric wrote: > >> On the French mailing-list Antoine has suggested a new = >> idea for the call convention. At the beginning it just say that it was = a = >> funny idea, but it could be very interresting finally. >=5Bsnip=5D > >First, a decent F-CPU compiler should not select registers randomly. =5Co/ >It should analyze every function and assign register numbers so that >chances for a collision are minimized. =5Co/ =5Co/ >That is, in a module containing several functions that call each other, >each function should use a different set of registers. Additionally, >functions can have both an =22internal=22 entry point for intra-module ca= lls >(which need not save any registers) and a =22public=22 entry point that >saves all registers used inside it, prepares for restoring them, and >then dispatches to the internal entry point. Unless there are recursive >functions, you'll have to save registers only when you enter the module >(and restore them when you leave it). > >Ideally, each function will use a contiguous set of registers, and there >will be an entry in the object file reporting which registers it uses. >That way it becomes possible to further minimize collisions at link time >by renumbering the registers inside a function - you may also call it >=22deferred register allocation=22 if you like. > >Consider three functions A, B and C. A uses r16-r19, B uses r16-r21, >and C uses r16 and r17. If the functions do not depend on each other >(that is, don't call each other), you can simply link them together, and >the resulting set of used registers will be the union of the functions' >individual sets, that is, r16-r21. If function C calls A but not B, >you can rename registers and assign r20 and r21 to C, and the resulting >common set still is r16-r21. If C calls both A and B, it is assigned r22 >and r23, and the resulting common set is r16-r23. In either case, there >will be no register collisions between the functions. Only if caller >and callee together need more than the number of available registers, >the linker will have to put save/restore code (since the register sets >are contiguous, storem/loadm will do the trick) =22around=22 the callee: > > new=5Fentry=5Fpoint: > // allocate stack space here > storem xyz > move r63, saved=5Freg // save return address > loadaddri old=5Fentry=5Fpoint, temp=5Freg > jump temp=5Freg, r63 // call original function > restore=5Fcode: > move saved=5Freg, r63 // restore return address > loadm xyz > // deallocate stack space here > jump r63 > >(This is generic code that may still be improved) hmmmm where do storem and loadm come from ? and how do you want to implement it ?..... =5B/me is feeling a bit less good now=5D >The same algorithm works with both functions and modules, and it only >needs the set of used registers per function/module and a dependency >graph. Both can be easily constructed from intermediate code. Register >renumbering is done on the object code directly (thanks for the uniform >register model and instruction format of the F-CPU which allow us to >=60transpose' the object code -- note to guitar players: think =60capo' ;= -). i get the picture. However, due to the nature of some 2W instructions, the =22capo=22 MUST be done with pairs of registers, on a =22granularity=22 of 2. That is : you can't do half-tone pitch shifting. >Conclusion: Using a smart linker, we can resolve register collision >issues statically. We can also take profiling (feedback) information >into account, like you suggested, to optimize the number and placement of >save/restore points. Therefore, I see no real need to do it at run time. Still there is a problem with loadm and storem. >-- = > Michael =22Tired=22 Riepe > =22All I wanna do is have a little fun before I die=22 >************************************************************* >To unsubscribe, send an e-mail to majordomo=40seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 16:33:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIR-0000G1-01 for ; Wed, 06 Nov 2002 15:36:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:43 +0100 (CET) Received: (qmail 19812 invoked by uid 0); 6 Nov 2002 11:33:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 6 Nov 2002 11:33:50 -0000 Received: by moria.seul.org (Postfix) id 97C8515E728; Wed, 6 Nov 2002 06:33:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8489C15E72C; Wed, 6 Nov 2002 06:33:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 32AF415E728 for ; Wed, 6 Nov 2002 06:33:49 -0500 (EST) Received: from club-internet.fr (flashmail-3v.cs.clubint.net [172.16.0.153]) by relay-2v.club-internet.fr (Postfix) with SMTP id 958CD1684 for ; Wed, 6 Nov 2002 12:33:48 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 12:33:48 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: nico >On Tue, 05 Nov 2002 00:50:27 +0100 >Yann Guidon wrote: = >> >> = >> >The problem of the first solution are : >> >- complexity >> >- popcount unit must not be optional >> >- block the CPU for 3/4 cycles (before being sure that no TLB trap app= end) >> > = >> not only that, but : >> - instruction lifelength is not static =3D=3D> more difficult to decod= e and = >> schedule > >??? I need to see a proof of that. proof of what ? * the instruction lifelength is not static because the number of operations is indicated by a register, not a field in the opcode. * if the instruction is not equivalent to a static dataflow graph, then it is not possible to schedule it in FC0. Now you can admit that it is =22a bit more complex=22 than a simple ADD or even the division unit (which is an exception to the static scheduling because it has a static datapath). >> - instruction cannot be interrupted in the middle >> (IRQ/whatever) =3D=3D> IRQ response time is unpredictable :-( >Like our /0 trick, gni ? > the pipeline should check IRQ first. FC0 doesn't =22check IRQ=22. The new instruction flow is inserted in the pipeline whenever it is available and can be issued. It can be ok to delay IRQ while an instruction waits for the operands to be ready before it is issued, but allowing more delay (particularly when it could have been avoided with the use of discrete instructions) reduces the system's responsiveness. It may be completely off-topic for an average desktop PC, but F-CPU is not meant to be used only there. > And then the following stay asynchronous. ? do you meant that IRQ is blocked when the instruction runs, or do you allow asynchronous IRQ in the middle of the instruction ?... >> - it can't be pipelined (issued and then another instruction can be = >> decoded) >It could. then tell me how. > Where is the probleme ? people have sexy ideas but no way to integrate them in the existing framework. Think about it : the existing FC0 pipeline is designed in such a way that an instruction implements a simple function : =22add=22 is decoded, operands are fetched, result is computed and written back. THAT can be pipelined and it works well. Now if an instruction must perform several steps, it has to =22stay=22 in the decoder, so that the steps can reuse the existing pipeline. This means that the instruction is =22blocking=22 because no other instruction can start decoding. This is why it is not =22pipelinable=22 because even if the rest of the data pipeline is used, the instruction fetch and decode pipeline is stalled and no IRQ can be acknowledged. > You have to play with a contention on the register bank. i wouldn't call that =22play=22.... >> - the read port is connected to the instruction buffer =3D=3D> it is n= ot = >> possible to generate the sequence of registers to be saved. And even a = counter = >> would not be ok (in order to generate the register numbers), because th= e = >> mask can have holes =21 > >You could mask hole. But then you loose cycle. heh. that's what i meant. > I'm pretty sure that a >=22sequencer generator=22 could be used. a =23what=23 ?... and don't forget about the =22tight pipeline stages=22 : if the =22solution=22 takes more than 1 cycle per register, then it's worthless. >> >For the second solution : >> >- complexity >> >- popcount unit must not be optional >> >- block the CPU for 3/4 cycles like the first solution, but you need t= o use = >> >this instruction more frequently than the previous solution, but this = >> >solution give you the possibility to pass a chunk if not needed. >> same remarks as before. >> it's multicycle, CISC instrtuction with most of the problems. > >the biggest probleme is the connection of the read/write port that >annoyed instruction buffer but that the case of SRB, too. remember that SRB is =22optional=22 ..... >> >Sorry for this long, but I hope it could be interresting, >> > Cedric >> > >> well, at last it made it to this list. >> = >> YG = > >Maybe the idea of Michael is better (SW). It's okay if the linker could r= eally do the job. Otherwise... i would go for it. However, the loadm/storem have some of the problems of the masked load/stores. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Nov 6 13:15:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIV-0000G1-00 for ; Wed, 06 Nov 2002 15:36:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:47 +0100 (CET) Received: (qmail 9718 invoked by uid 0); 6 Nov 2002 12:15:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 6 Nov 2002 12:15:32 -0000 Received: by moria.seul.org (Postfix) id D672815E72B; Wed, 6 Nov 2002 07:15:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C0A8915E72E; Wed, 6 Nov 2002 07:15:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id DF0BD15E72B for ; Wed, 6 Nov 2002 07:15:30 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211061215.15c4; Wed, 6 Nov 2002 12:15:21 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] New suggestion about call convention From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2002 12:15:21 GMT Message-id: <200211061215.15c4@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 06/11/02 Objet: Re: Re: [f-cpu] New suggestion about call convention hi, >De: nico >On Tue, 05 Nov 2002 00:50:27 +0100 >Yann Guidon wrote: =20 >> >>=20 >> >The problem of the first solution are : >> >- complexity >> >- popcount unit must not be optional >> >- block the CPU for 3/4 cycles (before being sure that n= o TLB trap append) >> > =20 >> not only that, but : >> - instruction lifelength is not static =3D=3D> more diff= icult to decode and=20 >> schedule > >??? I need to see a proof of that. proof of what ? * the instruction lifelength is not static because the number of operations is indicated by a register, not a field in the opcode. * if the instruction is not equivalent to a static dataflow graph, then it is not possible to schedule it in FC0. Now you can admit that it is "a bit more complex" than a simple ADD or even the division unit (which is an exception to the static scheduling because it has a static datapath). >>>>Maybe with the vision of the scheduler that you have (wi= th fifo and "simulation" of behavior) that needs to stop the pipeline in= case of cache miss because the latency is too high for you NP algory= thme.. >>>It's always possible to have a multicycle load/store unit= that handle that stuff. >> - instruction cannot be interrupted in the middle >> (IRQ/whatever) =3D=3D> IRQ response time is unpredic= table :-( >Like our /0 trick, gni ? >>>> "divide by zero". All instruction are in order at the b= eginning. You check the exception. And then you could finish the instr= uction. So there is no write to cancel.=20 > the pipeline should check IRQ first. FC0 doesn't "check IRQ". The new instruction flow is inserted in the pipeline whenever it is available and can be issued. It can be ok to delay IRQ while an instruction waits for the operands to be ready before it is issued, but allowing more delay (particularly when it could have been avoided with the use of discrete instructions) reduces the system's responsiveness. It may be completely off-topic for an average desktop PC, but F-CPU is not meant to be used only there. > And then the following stay asynchronous. ? do you meant that IRQ is blocked when the instruction runs, or do you allow asynchronous IRQ in the middle of the instruction ?... >>>Neither. Instruction are raised as early as possible, it'= s the first work of the pipeline for every instruction (what you could "= put the exception check in the decoder stage", that's not possible a= t all but that's an image) >> - it can't be pipelined (issued and then another instruc= tion can be=20 >> decoded) >It could. then tell me how. >>>>:) Every thing could be pipeline. Like divide,... > Where is the probleme ? people have sexy ideas but no way to integrate them in the existing framework. Think about it : the existing FC0 pipeline is designed in such a way that an instruction implements a simple function : "add" is decoded, operands are fetched, result is computed and written back. THAT can be pipelined and it works well. >>>That's RISC stuff, but F-cpu is quite far from that, no? Now if an instruction must perform several steps, it has to "stay" in the decoder, so that the steps >>>No ! The load/store unit hold it. can reuse the existing pipeline. This means that the instruction is "blocking" because no other instruction can start decoding. This is why it is not "pipelinable" because even if the rest of the data pipeline is used, the instruction fetch and decode pipeline is stalled and no IRQ can be acknowledged. >>>There alwas be the problem of read/write port contention.= things go heavy and not in a simple way. It's as hard as SRB stuff.=20 > You have to play with a contention on the register bank. i wouldn't call that "play".... >> - the read port is connected to the instruction buffer =3D= =3D> it is not >> possible to generate the sequence of registers to be save= d. And even a counter=20 >> would not be ok (in order to generate the register number= s), because the=20 >> mask can have holes ! > >You could mask hole. But then you loose cycle. heh. that's what i meant. > I'm pretty sure that a >"sequencer generator" could be used. a #what# ?... and don't forget about the "tight pipeline stages" : if the "solution" takes more than 1 cycle per register, then it's worthless. >>>For a very longtime i said that 6 gate per stage is far f= rom realistic, but... >> >For the second solution : >> >- complexity >> >- popcount unit must not be optional >> >- block the CPU for 3/4 cycles like the first solution, = but you need to use=20 >> >this instruction more frequently than the previous solut= ion, but this=20 >> >solution give you the possibility to pass a chunk if not= needed. >> same remarks as before. >> it's multicycle, CISC instrtuction with most of the probl= ems. > >the biggest probleme is the connection of the read/write po= rt that >annoyed instruction buffer but that the case of SRB, too. remember that SRB is "optional" ..... >>>And remember that i didn't like that so much thing could = be optional ! there will be no compatibility at all between Fcpu otherwi= se. >> >Sorry for this long, but I hope it could be interresting= , >> > Cedric >> > >> well, at last it made it to this list. >>=20 >> YG=20 > >Maybe the idea of Michael is better (SW). It's okay if the = linker could really do the job. Otherwise... i would go for it. However, the loadm/storem have some of the problems of the masked load/stores. >>>>hmm, not my own version ! :) "m" could signifie 4 or 8 r= egisters at a glance, so you could read or write a complete cache line i= n a cycle (so adress are aligned and even 1K adress aligned to simply = things even more) :) (it's really easy to do 4x or 8x the width of the r= egister, and make a choice thought a mux (for usual use) or not (for "m" = operation)). So you could manipulate R0-3/r4-7/r8-11/... in one cycle. I love this because it's really simple to do it in HW. It pr= ovide a udge bandwith from cache to cpu (hmm, let's see 256*4=3D1024 bits= interface, nice :) >>>>You don't increase true memory bandwith but it easier to= hide latency. Imagine unrolling loops. nicO YG __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Nov 6 13:14:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIW-0000G1-00 for ; Wed, 06 Nov 2002 15:36:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:48 +0100 (CET) Received: (qmail 13968 invoked by uid 0); 6 Nov 2002 12:17:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 6 Nov 2002 12:17:22 -0000 Received: by moria.seul.org (Postfix) id E07E415E72C; Wed, 6 Nov 2002 07:17:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF10315E72F; Wed, 6 Nov 2002 07:17:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 6EE6415E72C for ; Wed, 6 Nov 2002 07:17:21 -0500 (EST) Received: from homeworld (80.14.37.225) by smtp.laposte.net (6.0.053) id 3DB5C84D00167144 for f-cpu@seul.org; Wed, 6 Nov 2002 13:17:19 +0100 Message-ID: <002d01c2858e$191aeb40$c986fea9@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 13:14:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: To: Sent: Wednesday, November 06, 2002 12:43 PM Subject: Re: Re: [f-cpu] New suggestion about call convention > new_entry_point: > // allocate stack space here > storem xyz > move r63, saved_reg // save return address > loadaddri old_entry_point, temp_reg > jump temp_reg, r63 // call original function > restore_code: > move saved_reg, r63 // restore return address > loadm xyz > // deallocate stack space here > jump r63 > >(This is generic code that may still be improved) hmmmm where do storem and loadm come from ? and how do you want to implement it ?..... --- AH ! WHAT DID I TELL YOU, YANN, ABOUT MICHAEL'S LOADM/STOREM ? MESEEMS YOU FORGET ONE EPISODE :) I suppose the main trouble is the fact that we borrow the register number from the instruction format to select the right data from the register set. Due to this fact, it is highlly extremely difficult to access another register at the same time. Just imagine this kind of instruction - getr r1,r2 - as an example. It reads the value of the register, the number of which is read from r1, then store the value in r2. The main difficulty comes from the fact how to select the register pointed by r1 since it is not hardwired in the instruction format ? the same trouble arises with loadm/storem as for maskload/maskstore. For those who needs to understand : an FCPU instruction format has an opcode field and three register operand fields. So when executing an 2r1w instruction, two registers would be selected in the register set to be read and the third register to be written back. The unit in charge of the operation would have two data to read, compute a new result and then output it. So in fact you link between the register set and the unit with two source data (in) and one target data (out) for the unit. So the instruction decoding operates simultaneously on register set and units. As you can see, there is no way else to select a register through the instruction format. Unhopefully, loadm/storem fall into this category, since it uses two registers to tell us the two numbers of registers to start and end. First you can not select all the registers in the same time above two. Second even looping innerly you cannot select the in-between registers. The only solution I see is the following (not sure about the real format) : storem r16,[sp],r31 // saving r16-r31 when executing the instruction, we save r16 in [sp]; but instead of executing next instruction, we reexecute the same instruction slightly modified until we reach r31: every time we execute this instruction we increment the first register operand number in the instruction format. When the first and the thirds register operand numbers are the same, we go on the next instruction. maskstore mr,[sp],r16 will work the same time : the first 16 bits of mr will contain our local registers. Since the third register operand starts with r16, having the least significant bit of mr to be 1 means we need to store r16 into [sp]. Every time we shift the bit in mr, we increment the third register operand number in the instruction format until mr becomes 0, then we go on the next instruction. Well I suppose this kind of solution would not be appreciated by a lot of people. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Nov 6 13:53:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIX-0000G1-00 for ; Wed, 06 Nov 2002 15:36:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:49 +0100 (CET) Received: (qmail 13455 invoked by uid 0); 6 Nov 2002 12:53:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Nov 2002 12:53:53 -0000 Received: by moria.seul.org (Postfix) id CB27915E72A; Wed, 6 Nov 2002 07:53:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B2F4415E72E; Wed, 6 Nov 2002 07:53:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 3978D15E72A for ; Wed, 6 Nov 2002 07:53:52 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211061253.29e2; Wed, 6 Nov 2002 12:53:41 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] New suggestion about call convention From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2002 12:53:41 GMT Message-id: <200211061253.29e2@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: "Christophe Avoinne" A: Date: 06/11/02 Objet: Re: Re: [f-cpu] New suggestion about call convention ----- Original Message ----- From: To: Sent: Wednesday, November 06, 2002 12:43 PM Subject: Re: Re: [f-cpu] New suggestion about call conventio= n > new_entry_point: > // allocate stack space here > storem xyz > move r63, saved_reg // save return address > loadaddri old_entry_point, temp_reg > jump temp_reg, r63 // call original function > restore_code: > move saved_reg, r63 // restore return address > loadm xyz > // deallocate stack space here > jump r63 > >(This is generic code that may still be improved) hmmmm where do storem and loadm come from ? and how do you want to implement it ?..... --- AH ! WHAT DID I TELL YOU, YANN, ABOUT MICHAEL'S LOADM/ST= OREM ? MESEEMS YOU FORGET ONE EPISODE :) I suppose the main trouble is the fact that we borrow the re= gister number from the instruction format to select the right data from th= e register set. Due to this fact, it is highlly extremely difficult to acces= s another register at the same time. Just imagine this kind of instruction - getr r1,r2 - as an e= xample. It reads the value of the register, the number of which is read from = r1, then store the value in r2. The main difficulty comes from the fact how= to select the register pointed by r1 since it is not hardwired in the inst= ruction format ? the same trouble arises with loadm/storem as for maskload/ma= skstore. For those who needs to understand : an FCPU instruction format has an opcode field and three reg= ister operand fields. So when executing an 2r1w instruction, two register= s would be selected in the register set to be read and the third regist= er to be written back. The unit in charge of the operation would have two dat= a to read, compute a new result and then output it. So in fact you link= between the register set and the unit with two source data (in) and one= target data (out) for the unit. So the instruction decoding operates sim= ultaneously on register set and units. As you can see, there is no way else to select a register th= rough the instruction format. Unhopefully, loadm/storem fall into this category, since it = uses two registers to tell us the two numbers of registers to start a= nd end. First you can not select all the registers in the same time above = two. Second even looping innerly you cannot select the in-between registers. The only solution I see is the following (not sure about the= real format) : storem r16,[sp],r31 // saving r16-r31 when executing the instruction, we save r16 in [sp]; but ins= tead of executing next instruction, we reexecute the same instructio= n slightly modified until we reach r31: every time we execute this inst= ruction we increment the first register operand number in the instructi= on format. When the first and the thirds register operand numbers are the sa= me, we go on the next instruction. >>>>That's clear ! But what's up in case of external it ? We wait to finish thi= s instruction ? -> blocking instruction In case of access violation ? Typical faulty instruction are= not executed and pointed by a register for the trap handler. But= hier, the execution will partly be executed -> beark ! >>>From timing point of view it's exaclty the same that havi= ng n instructions to do it. That's the usual deal between CISC/RI= SC (same work but faster clock with a bigger code (2x compare to x86 = even compare to ARM !)). This implementation require a kind of logique be= tween instruction buffer and register bank port, so it will slow d= one everything. maskstore mr,[sp],r16 will work the same time : the first 16= bits of mr will contain our local registers. Since the third register operan= d starts with r16, having the least significant bit of mr to be 1 means we= need to store r16 into [sp]. Every time we shift the bit in mr, we increme= nt the third register operand number in the instruction format until mr b= ecomes 0, then we go on the next instruction. Well I suppose this kind of solution would not be appreciate= d by a lot of people. >>>What about my fixed one shoot, mload/store instruction ? ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Nov 6 05:38:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIY-0000G1-01 for ; Wed, 06 Nov 2002 15:36:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:50 +0100 (CET) Received: (qmail 23486 invoked by uid 0); 6 Nov 2002 13:20:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 6 Nov 2002 13:20:24 -0000 Received: by moria.seul.org (Postfix) id A543315E725; Wed, 6 Nov 2002 08:20:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88EE215E72F; Wed, 6 Nov 2002 08:20:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a076.home.uni-hannover.de [130.75.232.76]) by moria.seul.org (Postfix) with ESMTP id BB6BB15E725 for ; Wed, 6 Nov 2002 08:20:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA03217; Wed, 6 Nov 2002 05:38:48 +0100 Message-ID: <20021106053848.56360@thrai.stud.uni-hannover.de> Date: Wed, 6 Nov 2002 05:38:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <200211042333.19012.cedric.bail@free.fr> <20021105185014.20040@thrai.stud.uni-hannover.de> <200211052229.00764.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211052229.00764.cedric.bail@free.fr>; from cedric on Tue, Nov 05, 2002 at 10:29:00PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Nov 05, 2002 at 10:29:00PM +0000, cedric wrote: > > First, a decent F-CPU compiler should not select registers randomly. > > It should analyze every function and assign register numbers so that > > chances for a collision are minimized. > > It depend if you have knowledge about what the other module librairie do. > You will certainly agree that if you don't have any knowledge about the > register usage, random is the best solution. The goal is to have that knowledge available - either via calling conventions, or via hints inside the object file, or via code analysis if everything else fails. As a last resort, you can still save all registers when you enter an unknown function. > > That is, in a module containing several functions that call each other, > > each function should use a different set of registers. Additionally, > > functions can have both an "internal" entry point for intra-module calls > > (which need not save any registers) and a "public" entry point that > > saves all registers used inside it, prepares for restoring them, and > > then dispatches to the internal entry point. Unless there are recursive > > functions, you'll have to save registers only when you enter the module > > (and restore them when you leave it). > > It's a good idea for having quick call intra-module. The problem is in the > epilogue, how did you know from where you came ? By changing the `return address' register, as indicated in the code I included in my original mail. > > Ideally, each function will use a contiguous set of registers, and there > > will be an entry in the object file reporting which registers it uses. > > That way it becomes possible to further minimize collisions at link time > > by renumbering the registers inside a function - you may also call it > > "deferred register allocation" if you like. > > It's an interesting idea, but for each instruction in each function in each > module you need to search in a "database" which chunk to replace and then > replace it with a mask. But before taking your decision you need to execute a > allocation algorithm. Currently, with only relocation on x86, a lot of people > are thinking that time needed by linking is slow... You mean run-time (dynamic) linking? We're going to do it at compile time; there will be no overhead when the program starts. You don't need a complicated database look-up. You just do the following: get the instruction word for all register fields do if the register number has to be replaced replace it with the new register number You can use a table-based translation (64 table entries) or an algorithmic approach (add a constant to the register number if it's inside the range that is supposed to be `pitch-shifted'). The number of register fields is available from the opcode (another table with 256 entries). Nothing more, nothing less. In either case, transposing an instruction will take only a handful of CPU cycles. The allocation algorithm isn't complicated either (I outlined it in my other mail). > But the idea is good, what did you think about a double solution : for .o > (not librairie), you use your technique and for the rest the technique > suggested by Arnaud. Inside a shared library or a program, reallocation can be used as well. It just won't work at the interface between programs and shared libraries. > In the prologue you use the mask technique and put a second entry point for > optimal call. (I don't see why you need to have contiguous register, you only > need a 64 bits mask per function, so 2 techniques can be used together). Contiguous register numbers make the allocation and transposition easier, expecially when register pairs are involved. And it's what compilers usually do: start with the first, and always pick the next available register. > > new_entry_point: > > // allocate stack space here > > storem xyz > > move r63, saved_reg // save return address > > loadaddri old_entry_point, temp_reg > > jump temp_reg, r63 // call original function > > restore_code: > > move saved_reg, r63 // restore return address > > loadm xyz > > // deallocate stack space here > > jump r63 > > Problem with this is that you have a double jump each time you call a function > outside of your module. Why didn't you use something like this : As I already mentioned, that piece of code can be improved :) On the other hand, the `double jump' allows us to put multiple wrappers around the same function without touching the function itself. [...] > With this you have both possibility. In fact you don't need to add a jump for > entry point with your method too, because you can add the 2 entries points > when you compile. The link time register reallocation relies on the fact that any number of wrappers can be added to a function. That has to be done at link time because the compiler doesn't know how many wrappers it has to provide. > A possibility to improve your idea is to specify a other > registre Quick Entry, if qe == r0 => don't restore else restore so the > epilogue/prologue will look like : > > low_entry_point: > loadcons.1 0xFFFF, r0 > loadcons.2 0xFFFF, r0 > loadcons.3 0xFFFF, r0 > and r0, mr, r1 > maskstore r1, [sp] > quick_entry_point: > // My function > jmpz qe, r63 > restore_code: > loadcons.1 0xFFFF, r0 > loadcons.2 0xFFFF, r0 > loadcons.3 0xFFFF, r0 > and r0, mr, r1 > maskload r1, [sp] > jmp r63 Nice idea, but it still allows only a single wrapper per function. BTW: Your restore code is broken; you'll have to use the modified mask when you restore the registers, and then put the original mask back in place. > > The same algorithm works with both functions and modules, and it only > > needs the set of used registers per function/module and a dependency > > graph. Both can be easily constructed from intermediate code. Register > > renumbering is done on the object code directly (thanks for the uniform > > register model and instruction format of the F-CPU which allow us to > > `transpose' the object code -- note to guitar players: think `capo' ;-). > > I don't understood you here, we have a lot of different instruction : 2r1w, > 1i1w, 1i1r, 1i1r1w, 3r2w... For each you have a special case. But the register numbers are always encoded in the same 1...3 fields of the instruction word - and that's all that matters. We don't have to touch the instructions itself, only the register numbers. > > Conclusion: Using a smart linker, we can resolve register collision > > issues statically. We can also take profiling (feedback) information > > into account, like you suggested, to optimize the number and placement of > > save/restore points. Therefore, I see no real need to do it at run time. > > The problem is doing a optimising linker will really improve the code, but > will not work for shared code (librairie are loaded only once) and will > certainly be really slow for big code... The mr is not as optimal as your > proposition but didn't cost so much each time you run a application. Au contraire, mon ami! (I always wanted to say that ;) Link time register allocation is done *once* for each program - before it is run. At run time, you'll only waste cycles when you have to save/restore registers. The `mask' approach also needs some cycles for bookkeeping (that is, the mask operations), which makes it slower than link time allocation in the worst case. One might consider the `mask' approach as an alternative for the program/library interface (after all, that looks like the weak point of my approach). But there is a good argument against it: A reasonably complex program will use *all* registers internally. That is, you always have to save registers when you enter a shared library - with either approach. Both link time allocation (when the library is built) and register masking (at run time) help to reduce the number of registers you have to save, but link time allocation is superior because it has less run time overhead. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Nov 6 04:49:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIa-0000G1-00 for ; Wed, 06 Nov 2002 15:36:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:52 +0100 (CET) Received: (qmail 20034 invoked by uid 0); 6 Nov 2002 13:20:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 6 Nov 2002 13:20:28 -0000 Received: by moria.seul.org (Postfix) id 860D515E72C; Wed, 6 Nov 2002 08:20:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5C06915E731; Wed, 6 Nov 2002 08:20:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a076.home.uni-hannover.de [130.75.232.76]) by moria.seul.org (Postfix) with ESMTP id C2FAC15E72C for ; Wed, 6 Nov 2002 08:20:22 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA03092; Wed, 6 Nov 2002 04:49:11 +0100 Message-ID: <20021106044911.44562@thrai.stud.uni-hannover.de> Date: Wed, 6 Nov 2002 04:49:11 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1036530711.3376.39.camel@fsol>; from Antoine on Tue, Nov 05, 2002 at 10:11:50PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Antoine wrote: > Just my two cents... About the idea that register optimization > could be done at linking time. I don't know if F-CPU is meant > to work as an isolated architecture, with only dedicated tools. > But if you want to benefit from existing software, you must think > in terms of compatibility with the Gnu tools. > > That means : > - compiler capabilities Can be added. Hey, it's Free Software, isn't it? > - linker capabilities Can be added as well (although I would prefer a specialized F-CPU linker). Note that GNU ld is not required on all operating systems; gcc is usually capable to use the native linker (and assembler) of the OS it runs on. > - object file format (ELF, etc.) ELF is no problem at all. It was designed for these kind of things. Other executable formats are rare nowadays (and most of them aren't 64-bit capable anyway, while ELF is). > I'd bet (but I may be wrong ;-)) that none of those are ready > for such a thing as link-time or load-time register reallocation. > I'd also bet that if nobody does it at the moment, maybe it's > because there are serious problems with it (despite the fact that > compilation time is cheap so there is much incentive to optimize > as far as possible in this phase). For once the optimization > problem itself doesn't seem very simple, especially when programs > get big. It shouldn't be more complex than the register allocation pass inside the compiler. Just on a higher level - replace `instruction' with `function', and you've got it. > An example is the mysql daemon (which is a respectable database, > but not a big and featureful monster as Postgres or Oracle). > > [root@fsol antoine]# strip -s /usr/sbin/mysqld > [root@fsol antoine]# ls -la /usr/sbin/mysqld > -rwxr-xr-x 1 root root 1957780 nov 5 21:38 /usr/sbin/mysqld* > > > This is quite a big executable indeed. Of course there is not only > code. Given that stuff other than code (strings, empty data...) is > likely to be highly compressable, we can still estimate an order of > magnitude of the actual code : The command you are looking for is called `size', BTW :) > [antoine@fsol antoine]$ gzip -c /usr/sbin/mysqld > mysqld > [antoine@fsol antoine]$ ls -la mysqld > -rw-rw-r-- 1 antoine antoine 871030 nov 5 21:48 mysqld > > So we can, quite safely, assume that the mysqld code (again, not > that a big database program compared to others) is several hundreds > of kilobytes big (and this would probably be worse on a RISC > machine, with lots of small instructions using lots of registers !). Right. > I don't think it's reasonable to expect processing some global > register allocation (how do you do that ? ;-)) on such a big > piece of code. Also, keep in mind that registers may have a > special role and not be easily exchangeable (not really the case > in F-CPU, except for instructions that also write to the register > next to the output register). Not global register allocation; that's a different issue. We're talking only about the `callee-saved' registers. And register pairs should be easy to handle if the register sets are contiguous. [...] > Another strong argument is that you can't even be sure that there > is a good solution to the optimization problem (even if you have > invented an outstanding algorithm that makes you sure to find the > optimum, and maybe it also helps you demonstrate that P==NP at the > same time :-)). The optimum may be not much better than the common > case. I do not expect to get optimal results. The `register mask' approach won't deliver optimal performance either. It may even perform worse than a clever static allocation. I just want to eliminate save/restore points where they're not necessary; that's better than a `smart' save/restore, IMHO. The algorithm I have in mind will simply process the call tree bottom-up (recursive functions will be handled separately). That can be done in linear time - each function is processed at most once. Unused functions need no processing at all; in fact, they may be removed during the process (another win). Self-contained (`leaf') functions need no modifications either. Transposing a function also requires linear time: each instruction is processed exactly once. In addition to that, encapsulated code modules (e.g. object files) can be preprocessed to save compilation time. Shared libraries need special handling because they can be replaced after the programs using them have been compiled. This is the only place where the calling conventions have to be strictly enforced. > For example, if you have three functions (A, B, C) that each > allocate 32 different registers. B calls C. A calls in turn : > C then B. So sometimes C is called from B which is called from > A, sometimes C is called directly from A. How do you think the > optimal solution will look like, and will that optimality be > satisfactory ? In that case, you'll have to save registers at each call (assuming that you have no more than 32 registers available). Everything else requires a more detailed analysis of the code. > (if you optimize C for being called by B, it won't be optimized > for being called by A, and vice-versa ; of course, you can > duplicate C in two versions but beware of cache thrashing, given > that this is a very simple example) Let's take slightly different numbers: 16 registers per function, 32 registers available. The execution sequence shall look like this: A -> C => A -> B -> C => B => A where `->' indicates a call, and `=>' indicates a return. When you process the call tree (remember: bottom-up), you will first encounter the `B -> C' call. Let's assume that C uses the first half of the available registers; then B can use the second half, and the whole `B+C' code uses all available registers. Only the code of B will have to be `transposed'; C stays unchanged (it's a `leaf' function). No registers need to be saved. No function is duplicated (we're done with B, and it will stay that way for the rest of the time). Now look at A. It calls both B+C and C. B+C uses the whole register set, while C uses only the first half. You have several options now; an obvious approach is to save the second half when you enter B+C, and allocate the same second half to A. Note that B+C doesn't need to be modified - the linker will simply put a save/restore `wrapper' around it and use its entry point instead of the real one. That is, another function D may still call B without saving and restoring registers, using the original entry point, or use another wrapper if it has different requirements. Finally, A is transposed and we're done. Ok, let's count the save/restore points. 16 registers have to be saved when A calls B, and restored afterwards - and that's all. With your masking approach, there would be `smart' save/restore points at the entries of both B and C; assuming that 50% of the allocated registers need saving, 24 registers would have been saved during the execution of A. This sounds not too bad; but what happens if B calls C repeatedly, in a loop? In that case, you'll have to save the same registers again and again, and the number becomes MUCH higher, while it stays the same with static allocation. I have to admit that static (link-time) allocation and register masking together will probably do even better. It also depends very much on the code - the linker may have to take loops etc. into account when it selects the save/restore points. But in general, the `lazy save' algorithm I outlined above should work pretty well. Now YG will probably ask again where I get `those crazy ideas' from... It's basically the same `register windowing' approach that SPARC and Itanium CPUs use - only in software. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Nov 6 14:59:07 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189RIe-0000G1-00 for ; Wed, 06 Nov 2002 15:36:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 15:36:56 +0100 (CET) Received: (qmail 23990 invoked by uid 0); 6 Nov 2002 14:01:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 6 Nov 2002 14:01:57 -0000 Received: by moria.seul.org (Postfix) id 3C4F315E725; Wed, 6 Nov 2002 09:01:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 27A0415E730; Wed, 6 Nov 2002 09:01:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 573ED15E72D for ; Wed, 6 Nov 2002 09:01:42 -0500 (EST) Received: from homeworld (80.14.37.225) by smtp.laposte.net (6.0.053) id 3DB5C84D0016A6FF for f-cpu@seul.org; Wed, 6 Nov 2002 15:01:41 +0100 Message-ID: <005d01c2859c$ad7c1da0$c986fea9@homeworld> From: "Christophe Avoinne" To: References: <002d01c2858e$191aeb40$c986fea9@homeworld> Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 14:59:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hummm some explanations can be required. storem r16,[sp],r31 can be seen as equivalent of : store r16,[sp]+ store r17,[sp]+ ... store r13,[sp] so loadm r16,[sp],r31 : load [sp]-,r31 load [sp]-,r30 ... load [sp],r16 How does storem r1,[r2],r3 work : 1) store the value of r1 at memory [r2] 2) if r1 and r3 has the same register number, stop here and let the next instruction to run 3) increase the register number of r1 in the instrution format 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next instruction in instruction queue How does loadm r1,[r2],r3 work : 1) load the value at memory [r2] into r3 2) if r1 and r3 has the same register number, stop here and let the next instruction to run 3) decrease the register number of r3 in the instrution format 4) decrease the address stored into r2 5) rexecute the modified instruction or insert it as a next instruction in instruction queue Note : I'm not sure about load operation, source register is first operand or third operand ? using third operand would share more things between load and store operations. Non trivial parts are 3 and 5. Number of generated "instructions" is n where n = register_index(r3) - register_index(r1). maskstore mr,[sp],r16 (mr is ...101x) : : store r16,[sp]+ lsb(mr = ...0101) = 1 : store r17,[sp]+ lsb(mr = ...0010) = 0 : lsb(mr = ...0001) = 1 : store r19,[sp] ... maskload mr,[r1],r16 (mr is ...101x) : : load [r1]+,r16 lsb(mr = ...0101) = 1 : load [r1]+,r17 lsb(mr = ...0010) = 0 : lsb(mr = ...0001) = 1 : load [r1],r19 ... How does maskstore r1,[r2],r3 work : 1) store the value of r3 at memory [r2] 2) while lsb(r1) is 0 and r1 not 0, increase the register number of r3 in the instrution format and right shift r1. 3) check if mask r1 is 0, if so stop it and let the next instruction to run 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next instruction in instruction queue How does maskload r1,[r2],r3 work : 1) load the value at memory [r2] into r3 2) while lsb(r1) is 0 and r1 not 0, increase the register number of r3 in the instrution format and right shift r1. 3) check if mask r1 is 0, if so stop it and let the next instruction to run 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next instruction in instruction queue Non trivial parts are 2 and 5. Number of generated "instructions" is n where n = number of bits set to 1 in r1 except for the lsb which is always counted as 1. Conclusion : well, such a solution have some drawbacks : - if an resumable exception occurs, we need to keep the modified instruction so we can be able to resume from it and not from the original instruction. - a more complex scheduler to handle instruction self-modification, not speaking about the difficulties for pipelines. - a more complex instruction decoder able to handle instruction self-modification. You know what ? I think it will always be a nightmare to have a great CPU without any sacrifices :((( (I mean whatever the side is) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Nov 6 15:57:23 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WNK-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:06 +0100 (CET) Received: (qmail 26515 invoked by uid 0); 6 Nov 2002 14:57:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 6 Nov 2002 14:57:37 -0000 Received: by moria.seul.org (Postfix) id 750FA15E727; Wed, 6 Nov 2002 09:57:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 421A015E72D; Wed, 6 Nov 2002 09:57:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B530415E727 for ; Wed, 6 Nov 2002 09:57:35 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211061457.175a; Wed, 6 Nov 2002 14:57:23 GMT Send-By: 140.94.82.17 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] New suggestion about call convention From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2002 14:57:23 GMT Message-id: <200211061457.175a@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: "Christophe Avoinne" A: Date: 06/11/02 Objet: Re: Re: [f-cpu] New suggestion about call convention Hummm some explanations can be required. storem r16,[sp],r31 can be seen as equivalent of : store r16,[sp]+ store r17,[sp]+ ... store r13,[sp] so loadm r16,[sp],r31 : load [sp]-,r31 load [sp]-,r30 ... load [sp],r16 How does storem r1,[r2],r3 work : 1) store the value of r1 at memory [r2] 2) if r1 and r3 has the same register number, stop here and = let the next instruction to run 3) increase the register number of r1 in the instrution form= at 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next = instruction in instruction queue How does loadm r1,[r2],r3 work : 1) load the value at memory [r2] into r3 2) if r1 and r3 has the same register number, stop here and = let the next instruction to run 3) decrease the register number of r3 in the instrution form= at 4) decrease the address stored into r2 5) rexecute the modified instruction or insert it as a next = instruction in instruction queue Note : I'm not sure about load operation, source register is= first operand or third operand ? using third operand would share more thin= gs between load and store operations. Non trivial parts are 3 and 5. Number of generated "instructions" is n where n =3D register= _index(r3) - register_index(r1). maskstore mr,[sp],r16 (mr is ...101x) : : store r16,[sp]+ lsb(mr =3D ...0101) =3D 1 : store r17,[sp]+ lsb(mr =3D ...0010) =3D 0 : lsb(mr =3D ...0001) =3D 1 : store r19,[sp] ... maskload mr,[r1],r16 (mr is ...101x) : : load [r1]+,r16 lsb(mr =3D ...0101) =3D 1 : load [r1]+,r17 lsb(mr =3D ...0010) =3D 0 : lsb(mr =3D ...0001) =3D 1 : load [r1],r19 ... How does maskstore r1,[r2],r3 work : 1) store the value of r3 at memory [r2] 2) while lsb(r1) is 0 and r1 not 0, increase the register nu= mber of r3 in the instrution format and right shift r1. 3) check if mask r1 is 0, if so stop it and let the next ins= truction to run 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next = instruction in instruction queue How does maskload r1,[r2],r3 work : 1) load the value at memory [r2] into r3 2) while lsb(r1) is 0 and r1 not 0, increase the register nu= mber of r3 in the instrution format and right shift r1. 3) check if mask r1 is 0, if so stop it and let the next ins= truction to run 4) increase the address stored into r2 5) rexecute the modified instruction or insert it as a next = instruction in instruction queue Non trivial parts are 2 and 5. Number of generated "instructions" is n where n =3D number o= f bits set to 1 in r1 except for the lsb which is always counted as 1. >>>> ! you miss the tlb check !=20 Conclusion : well, such a solution have some drawbacks : - if an resumable exception occurs, we need to keep the modi= fied instruction so we can be able to resume from it and not from the origina= l instruction. >>>Glurps :/ - a more complex scheduler to handle instruction self-modifi= cation, not speaking about the difficulties for pipelines. - a more complex instruction decoder able to handle instruct= ion self-modification. You know what ? I think it will always be a nightmare to hav= e a great CPU without any sacrifices :((( (I mean whatever the side is) >>>> The choice come from what to put in the front of the re= gister port. RISC put the instruction buffer directly. If we had any kind= of redirection (SRB, not direct mload/store, maskL&s,...), we n= eed to add one more mux. So we add "something" between port and instruc= tion buffer, which slow down clock. Adding one more thing to this thing d= oesn't double time but add a little bit, it's a kind of "log" compl= exity. >>>It's say : raw speed is much more important =3D direct ac= cess, clever things are better =3D put the maximum things on it (clever b= ut slower and bigger). >>> It make me a pain in the ass to say that... i finaly agr= ee with whygee : KISS ! (keep it simple and stupid) __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Nov 6 16:37:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WNX-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:19 +0100 (CET) Received: (qmail 24447 invoked by uid 0); 6 Nov 2002 15:40:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Nov 2002 15:40:05 -0000 Received: by moria.seul.org (Postfix) id 9595115E727; Wed, 6 Nov 2002 10:40:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 706E015E72C; Wed, 6 Nov 2002 10:40:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id EED6D15E727 for ; Wed, 6 Nov 2002 10:40:03 -0500 (EST) Received: from homeworld (81.48.49.86) by smtp.laposte.net (6.0.053) id 3DB5C84D0016D6C7 for f-cpu@seul.org; Wed, 6 Nov 2002 16:40:03 +0100 Message-ID: <009701c285aa$6b349d60$c986fea9@homeworld> From: "Christophe Avoinne" To: References: <200211061457.175a@th00.opsion.fr> Subject: Re: Rep:Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 16:37:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Well, if we want for F-CPU to be KISS, we need to consider loadm/storem rather as a macro than as a real instruction indeed. storem r16,[sp],r31 will be rewritten as : store [sp]+,r16 store [sp]+,r17 ... store [sp],r31 (note: i choose here the third register field as source register for 'store' to be consistant with 'load') and loadm r16,[sp],r31 : load [sp]-,r31 load [sp]-,r30 ... load [sp],r16 Just a problem : whygee stated that there would not be any pre-decrement addresses, so I was forced to use a post-decrement - especially without modifying the address register of the last store/load. But just after a "store [sp],r31" for example, if we call a sub-function with other stores, we will crash the saved value of r31. So my question is : what must I do to change the address register without discarding its pointer status ? (you know, Whygee, you told me if I do "add 8,sp,sp", sp would no longer be considered as a pointer). Replace store [sp],r31 with store [sp]+,r31 and load [sp]-,r31 with load [sp]-,r0 load [sp]-,r31 is annoying if we still need to wait for reading [sp]. ----- Original Message ----- From: "Nicolas Boulay" To: Sent: Wednesday, November 06, 2002 3:57 PM Subject: Rep:Re: Re: [f-cpu] New suggestion about call convention -----Message d'origine----- De: "Christophe Avoinne" A: Date: 06/11/02 Objet: Re: Re: [f-cpu] New suggestion about call convention >>> It make me a pain in the ass to say that... i finaly agree with whygee : KISS ! (keep it simple and stupid) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Nov 6 17:18:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WNo-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:36 +0100 (CET) Received: (qmail 30944 invoked by uid 0); 6 Nov 2002 16:18:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Nov 2002 16:18:09 -0000 Received: by moria.seul.org (Postfix) id B290315E727; Wed, 6 Nov 2002 11:18:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 749FF15E72D; Wed, 6 Nov 2002 11:18:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id 0786B15E727 for ; Wed, 6 Nov 2002 11:18:08 -0500 (EST) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix3-1.free.fr (Postfix) with ESMTP id 02E0ED9ED7 for ; Wed, 6 Nov 2002 17:18:05 +0100 (MET) Received: by imp2-1.free.fr (Postfix, from userid 33) id D73775805E; Wed, 6 Nov 2002 17:18:05 +0100 (MET) To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] New suggestion about call convention Message-ID: <1036599485.3dc940bda5920@imp.free.fr> Date: Wed, 06 Nov 2002 17:18:05 +0100 (MET) From: Cedric BAIL References: <200211061457.175a@th00.opsion.fr> <009701c285aa$6b349d60$c986fea9@homeworld> In-Reply-To: <009701c285aa$6b349d60$c986fea9@homeworld> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > "store [sp],r31" for example, if we call a sub-function with other > stores, we will crash the saved value of r31. So my question is : what must > I do to change the address register without discarding its pointer status ? > (you know, Whygee, you told me if I do "add 8,sp,sp", sp would no longer be > considered as a pointer). You have madd/msub for this purpose (an imediate version could be usefull too). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Nov 6 17:25:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WNy-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:46 +0100 (CET) Received: (qmail 24116 invoked by uid 0); 6 Nov 2002 16:25:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 6 Nov 2002 16:25:55 -0000 Received: by moria.seul.org (Postfix) id 7061315E729; Wed, 6 Nov 2002 11:25:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2FEC615E72F; Wed, 6 Nov 2002 11:25:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id AF6BB15E729 for ; Wed, 6 Nov 2002 11:25:53 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id A178F1D4FA for ; Wed, 6 Nov 2002 17:25:52 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Wed, 6 Nov 2002 17:25:52 +0100 (CET) Message-ID: <48070.80.67.170.17.1036599952.squirrel@rezo.net> Date: Wed, 6 Nov 2002 17:25:52 +0100 (CET) Subject: [f-cpu] pointer add & sub From: "Antoine" To: In-Reply-To: <1036599485.3dc940bda5920@imp.free.fr> References: <1036599485.3dc940bda5920@imp.free.fr> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >> (you know, Whygee, you told me if I do "add 8,sp,sp", >> sp would no longer be considered as a pointer). I don't understand why, by the way. You could have the following : - add r3,r2,r1 => r1.pointer = r2.pointer XOR r3.pointer - sub r3,r2,r1 => r1.pointer = r3.pointer AND NOT r2.pointer (as for immediates, the obvious convention is imm8.pointer = false) So, unless there are useful exceptions to the above, you can get rid of special "memory pointer" operations. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Nov 6 14:31:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WO5-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:53 +0100 (CET) Received: (qmail 24095 invoked by uid 0); 6 Nov 2002 17:10:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 6 Nov 2002 17:10:43 -0000 Received: by moria.seul.org (Postfix) id 87A0F15E721; Wed, 6 Nov 2002 12:10:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60C3215E72C; Wed, 6 Nov 2002 12:10:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a094.home.uni-hannover.de [130.75.232.94]) by moria.seul.org (Postfix) with ESMTP id DB0DF15E721 for ; Wed, 6 Nov 2002 12:10:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00570; Wed, 6 Nov 2002 14:31:00 +0100 Message-ID: <20021106143100.64059@thrai.stud.uni-hannover.de> Date: Wed, 6 Nov 2002 14:31:00 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] New suggestion about call convention References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Wed, Nov 06, 2002 at 11:43:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Nov 06, 2002 at 11:43:11AM +0100, whygee@club-internet.fr wrote: [...] > i get the picture. > > However, due to the nature of some 2W instructions, > the "capo" MUST be done with pairs of registers, on a > "granularity" of 2. That is : you can't do half-tone > pitch shifting. Right. > Still there is a problem with loadm and storem. If loadm/storem aren't available, we can still use explicit load/store instructions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Nov 6 19:00:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOA-0004Kc-00 for ; Wed, 06 Nov 2002 21:02:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:02:58 +0100 (CET) Received: (qmail 14637 invoked by uid 0); 6 Nov 2002 18:01:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Nov 2002 18:01:56 -0000 Received: by moria.seul.org (Postfix) id 3FA1515E725; Wed, 6 Nov 2002 13:01:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 14E0215E72C; Wed, 6 Nov 2002 13:01:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 96B5A15E725 for ; Wed, 6 Nov 2002 13:01:54 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-220.jetnet.ab.ca [207.34.60.220]) by bach.ccinet.ab.ca (8.12.3/8.12.5) with ESMTP id gA6I3o6j042834 for ; Wed, 6 Nov 2002 11:03:51 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DC958B3.6070609@jetnet.ab.ca> Date: Wed, 06 Nov 2002 11:00:19 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> <20021106044911.44562@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe wrote: > I have to admit that static (link-time) allocation and register masking > together will probably do even better. It also depends very much on the > code - the linker may have to take loops etc. into account when it selects > the save/restore points. But in general, the `lazy save' algorithm > I outlined above should work pretty well. BYTE or Dr Dobb's magazine a few years ago had a good idea when the Z80 was still a popular computer. Sort all subroutines into recursive and non-recursive piles. Recursive routines use normal stack addressing. Non-recursive routines would be sorted into the level of subroutine calls made, and static global memory would be alloted for the variables. Since the Z80/8080 does not have easy stack addresssing this idea could save time and space. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 23:16:37 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOE-0004Kc-00 for ; Wed, 06 Nov 2002 21:03:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:02 +0100 (CET) Received: (qmail 25276 invoked by uid 0); 6 Nov 2002 18:16:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 6 Nov 2002 18:16:39 -0000 Received: by moria.seul.org (Postfix) id 93F9315E741; Wed, 6 Nov 2002 13:16:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 758C115E8AB; Wed, 6 Nov 2002 13:16:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 1DD6015E741 for ; Wed, 6 Nov 2002 13:16:38 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 78AD816AB for ; Wed, 6 Nov 2002 19:16:31 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 19:16:37 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: Michael Riepe >I have to admit that static (link-time) allocation and register masking >together will probably do even better. It also depends very much on the >code - the linker may have to take loops etc. into account when it select= s >the save/restore points. But in general, the =60lazy save' algorithm >I outlined above should work pretty well. i second you. >Now YG will probably ask again where I get =60those crazy ideas' from... >It's basically the same =60register windowing' approach that SPARC and >Itanium CPUs use - only in software. how disapointing =21 i thought you invented everything ;-P (why reinvent the wheel when you can copy it, by the way ?) > Michael =22Tired=22 Riepe > =22All I wanna do is have a little fun before I die=22 YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 23:20:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOE-0004Kc-01 for ; Wed, 06 Nov 2002 21:03:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:02 +0100 (CET) Received: (qmail 3512 invoked by uid 0); 6 Nov 2002 18:20:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Nov 2002 18:20:47 -0000 Received: by moria.seul.org (Postfix) id 5AE1B15E742; Wed, 6 Nov 2002 13:20:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4DCD115E8AB; Wed, 6 Nov 2002 13:20:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 063A415E742 for ; Wed, 6 Nov 2002 13:20:46 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-2v.club-internet.fr (Postfix) with SMTP id 5A0141690 for ; Wed, 6 Nov 2002 19:20:45 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 19:20:45 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >De: ben franchuk >A: f-cpu=40seul.org >Sujet: Re: =5Bf-cpu=5D New suggestion about call convention > >Michael Riepe wrote: > >> I have to admit that static (link-time) allocation and register masking >> together will probably do even better. It also depends very much on the >> code - the linker may have to take loops etc. into account when it sele= cts >> the save/restore points. But in general, the =60lazy save' algorithm >> I outlined above should work pretty well. > >BYTE or Dr Dobb's magazine a few years ago had a good idea when the >Z80 was still a popular computer. Sort all subroutines into recursive >and non-recursive piles. Recursive routines use normal stack addressing. >Non-recursive routines would be sorted into the level of subroutine = >calls made, and static global memory would be alloted for the variables. >Since the Z80/8080 does not have easy stack addresssing this idea could >save time and space. Makes a lot of sense. but .... how many years ago was it ? .... does gcc use this now ? just curious, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 23:32:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WON-0004Kc-01 for ; Wed, 06 Nov 2002 21:03:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:11 +0100 (CET) Received: (qmail 1809 invoked by uid 0); 6 Nov 2002 18:32:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 6 Nov 2002 18:32:24 -0000 Received: by moria.seul.org (Postfix) id D01A715E729; Wed, 6 Nov 2002 13:32:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90EF715E8AB; Wed, 6 Nov 2002 13:32:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 2E8AE15E729 for ; Wed, 6 Nov 2002 13:32:22 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-1v.club-internet.fr (Postfix) with SMTP id AFBCF16D3 for ; Wed, 6 Nov 2002 19:32:15 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 19:32:21 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >De: =22Nicolas Boulay=22 >>>> It make me a pain in the ass to say that... i finaly agree with >whygee : KISS =21 (keep it simple and stupid) LOL =21 KISS =21 XOXO ASV ? :-P (ok i couldn't resist this, sorry forgive me my tiredness) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 6 23:40:18 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOO-0004Kc-01 for ; Wed, 06 Nov 2002 21:03:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:12 +0100 (CET) Received: (qmail 24459 invoked by uid 0); 6 Nov 2002 18:40:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 6 Nov 2002 18:40:21 -0000 Received: by moria.seul.org (Postfix) id C945215E746; Wed, 6 Nov 2002 13:40:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9647315E8B8; Wed, 6 Nov 2002 13:40:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 53CD815E746 for ; Wed, 6 Nov 2002 13:40:19 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-4v.club-internet.fr (Postfix) with SMTP id E46B71762 for ; Wed, 6 Nov 2002 19:40:17 +0100 (CET) Received: from [212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Rep:Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 19:40:18 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, > >> =22store =5Bsp=5D,r31=22 for example, if we call a sub-function with ot= her >> stores, we will crash the saved value of r31. So my question is : what = must >> I do to change the address register without discarding its pointer stat= us ? >> (you know, Whygee, you told me if I do =22add 8,sp,sp=22, sp would no l= onger be >> considered as a pointer). > >You have madd/msub for this purpose (an imediate version could be usefull= too). In the interim, addi/subi can still be used, as i have evaluated the (=22ideal=22) delay to be around 1 or 2 cycles of penalty for the =22load=22 instruction (LSU already contains data, no TLB miss ...) But the decoder will refuse to =22issue=22 the instruction as long as the TLB is not checked and ok, so there is quite a stall. Fortunately, the TLB is connected to the Xbar and the ASU output so if the Load/store is located right behind (1 or 2 instructions) the add, the TLB can check the ASU output. Then the penalty will depend on the TLB latency, then by the LSU and the cache etc... (i hope this will work) >Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Nov 6 20:13:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOc-0004Kc-00 for ; Wed, 06 Nov 2002 21:03:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:26 +0100 (CET) Received: (qmail 27645 invoked by uid 0); 6 Nov 2002 19:16:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Nov 2002 19:16:33 -0000 Received: by moria.seul.org (Postfix) id 464C315E725; Wed, 6 Nov 2002 14:16:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F4CB15E72C; Wed, 6 Nov 2002 14:16:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id BED1E15E725 for ; Wed, 6 Nov 2002 14:16:31 -0500 (EST) Received: from homeworld (81.48.49.86) by smtp.laposte.net (6.0.053) id 3DB5C8A80017A0F9 for f-cpu@seul.org; Wed, 6 Nov 2002 20:16:30 +0100 Message-ID: <000201c285c8$a862dd00$c986fea9@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 20:13:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Not very clear... I did program with Z80 (I have a very old SHARP MZ-80K) not least 18 years ago. Even if it has two exemplars of register set, it has only one stack at once. So what is the meaning to sort recursive or non-recursive functions ? it makes a sense to use a normal stack for recursive-stack but what about non-recursive function ? due to the limit of register (8bit : A, B, C, D, E, H, L; 16-bit : BC, DE, HL) it is very hard not to be forced to save those registers into stacks. A push/pop rr takes 3 cycles and one instruction. A ld rr,(nn)/ld (nn),rr takes 6 cycles and 4 instructions. And a ld r,(nn)/ld (nn),r takes 4 cycles and. So you'd better to do "push bc" instead of doing "ld bc,(nn)" or "ld b,(nn); ld c,(nn+1)" when possible. But because the instruction set is rather restrictive about the use of each register, it was very difficult for using them as callee-saver registers and not very efficient comparing with the static global memory. But using static global memory with F-CPU is nothing comprarable with a Z80 !? It makes me crasy to think we can compare the power of a 64x64-bit registers cpu with those poor registers of a Z80 (saying that, i keep a good souvenir for it). ----- Original Message ----- From: To: Sent: Wednesday, November 06, 2002 8:20 PM Subject: Re: Re: [f-cpu] New suggestion about call convention >De: ben franchuk >A: f-cpu@seul.org >Sujet: Re: [f-cpu] New suggestion about call convention > >Michael Riepe wrote: > >> I have to admit that static (link-time) allocation and register masking >> together will probably do even better. It also depends very much on the >> code - the linker may have to take loops etc. into account when it selects >> the save/restore points. But in general, the `lazy save' algorithm >> I outlined above should work pretty well. > >BYTE or Dr Dobb's magazine a few years ago had a good idea when the >Z80 was still a popular computer. Sort all subroutines into recursive >and non-recursive piles. Recursive routines use normal stack addressing. >Non-recursive routines would be sorted into the level of subroutine >calls made, and static global memory would be alloted for the variables. >Since the Z80/8080 does not have easy stack addresssing this idea could >save time and space. Makes a lot of sense. but .... how many years ago was it ? .... does gcc use this now ? just curious, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Nov 6 20:44:07 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189WOj-0004Kc-00 for ; Wed, 06 Nov 2002 21:03:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 06 Nov 2002 21:03:33 +0100 (CET) Received: (qmail 9208 invoked by uid 0); 6 Nov 2002 19:45:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Nov 2002 19:45:44 -0000 Received: by moria.seul.org (Postfix) id 45F5015E721; Wed, 6 Nov 2002 14:45:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E45915E72C; Wed, 6 Nov 2002 14:45:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 800CC15E721 for ; Wed, 6 Nov 2002 14:45:42 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-220.jetnet.ab.ca [207.34.60.220]) by bach.ccinet.ab.ca (8.12.3/8.12.5) with ESMTP id gA6Jld6j075720 for ; Wed, 6 Nov 2002 12:47:39 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DC97107.3060506@jetnet.ab.ca> Date: Wed, 06 Nov 2002 12:44:07 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <000201c285c8$a862dd00$c986fea9@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Christophe Avoinne wrote: > Not very clear... > > I did program with Z80 (I have a very old SHARP MZ-80K) not least 18 years > ago. Even if it has two exemplars of register set, it has only one stack at > once. So what is the meaning to sort recursive or non-recursive functions ? > it makes a sense to use a normal stack for recursive-stack but what about > non-recursive function ? due to the limit of register (8bit : A, B, C, D, E, > H, L; 16-bit : BC, DE, HL) it is very hard not to be forced to save those > registers into stacks. A push/pop rr takes 3 cycles and one instruction. A > ld rr,(nn)/ld (nn),rr takes 6 cycles and 4 instructions. And a ld r,(nn)/ld > (nn),r takes 4 cycles and. So you'd better to do "push bc" instead of doing > "ld bc,(nn)" or "ld b,(nn); ld c,(nn+1)" when possible. But because the > instruction set is rather restrictive about the use of each register, it was > very difficult for using them as callee-saver registers and not very > efficient comparing with the static global memory. But using static global > memory with F-CPU is nothing comprarable with a Z80 !? I think so, the large register set of the F-CPU could be compared to static global memory on the Z80/8080. If you consider the 8080 a 8 bit RISC machine things look cleaner. Direct addressing ( register F-CPU ) (memory 8080 ) (Page Zero 6502,6800) are both very fast but suffer problems with dynamic use. Personaly I favor a machine with memory /acumulator achitecture and haveing the cache handle usage. from ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Nov 6 21:36:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQL-0000PZ-00 for ; Thu, 07 Nov 2002 23:46:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:46:53 +0100 (CET) Received: (qmail 14477 invoked by uid 0); 6 Nov 2002 20:37:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 6 Nov 2002 20:37:13 -0000 Received: by moria.seul.org (Postfix) id A4AB615E728; Wed, 6 Nov 2002 15:37:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74B8315E72F; Wed, 6 Nov 2002 15:37:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 0DEE615E728 for ; Wed, 6 Nov 2002 15:37:12 -0500 (EST) Received: from telehouse-102-2-121.net1.nerim.net (telehouse-102-2-121.net1.nerim.net [213.41.189.121]) by kraid.nerim.net (Postfix) with ESMTP id CB40040F61 for ; Wed, 6 Nov 2002 21:27:21 +0100 (CET) Subject: Re: [f-cpu] New suggestion about call convention From: Antoine To: f-cpu@seul.org In-Reply-To: <20021106044911.44562@thrai.stud.uni-hannover.de> References: <1036530711.3376.39.camel@fsol> <20021106044911.44562@thrai.stud.uni-hannover.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 06 Nov 2002 21:36:46 +0100 Message-Id: <1036615007.3080.74.camel@fsol> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > That means : > > - compiler capabilities > > Can be added. Hey, it's Free Software, isn't it? Of course. But I doubt adding something to gcc is very simple, especially if you want to do it cleanly so that the maintainers accept the patch. And in your case the patch might be quite intrusive, because you are assigning new roles to both compiler and linker, and it's likely that gcc's current architecture isn't very adapted. > Note that GNU ld is not required on all operating systems; > gcc is usually capable to use the native linker (and assembler) of the > OS it runs on. Yes. But whatever the linker, I don't think linkers are commonly assumed to mess with instruction codes & register allocation (even at function boundaries). So you may end up with custom versions of the gnu tools which will probably not be very compatible with the standard ones. Your proposal has another big problem : it ruins a part of the advantages of separate compilation. That is, if the linking part involves a costly optimization phase, rebuilding a whole project when changing just a source file will be much slower that it is today. > It shouldn't be more complex than the register allocation pass inside the > compiler. Just on a higher level - replace `instruction' with `function', > and you've got it. Are you sure ? You are not dealing only with register numbers but also register quantities. It's one thing to allocate single registers, it's another to allocate variable-size register sets. Think about the difference between a memory allocator that only allocates chunks of a fixed size, and another one that can allocate chunks of any size. > Unused functions need no processing at all; in > fact, they may be removed during the process (another win). You do not need all this analysis for such a win ;) > Transposing a function > also requires linear time: each instruction is processed exactly once. Well, either the object file carries information about the place of each register-bitfield needing to be transposed, or the linker does some on-the-fly disassembling (which makes it heavily architecture dependent, and is also not a very clean design imho). But I agree that on a pure operational point of view, this is ok. It's rather the optimization that bothers me. > The algorithm I have in > mind will simply process the call tree bottom-up (recursive functions will > be handled separately). What if recursion occurs at multiple stages and in non-trivial ways (between several functions and even several levels of the function "tree" - which is in fact a graph because of these recursions) ? > In addition to that, encapsulated code modules (e.g. object files) can > be preprocessed to save compilation time. You mean linking time. > > For example, if you have three functions (A, B, C) that each > > allocate 32 different registers. B calls C. A calls in turn : > > C then B. So sometimes C is called from B which is called from > > A, sometimes C is called directly from A. How do you think the > > optimal solution will look like, and will that optimality be > > satisfactory ? > > In that case, you'll have to save registers at each call (assuming that > you have no more than 32 registers available). Everything else requires > a more detailed analysis of the code. In fact my example was the same as yours, I was assuming 64 registers are available. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Nov 6 23:44:20 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQU-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:02 +0100 (CET) Received: (qmail 15568 invoked by uid 0); 6 Nov 2002 21:54:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Nov 2002 21:54:18 -0000 Received: by moria.seul.org (Postfix) id 76A5415E721; Wed, 6 Nov 2002 16:54:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A36315E72B; Wed, 6 Nov 2002 16:54:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 900BC15E721 for ; Wed, 6 Nov 2002 16:54:16 -0500 (EST) Received: from thor (223.188.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.188.223]) by smtp3.9tel.net (Postfix) with ESMTP id B30885BD47 for ; Wed, 6 Nov 2002 22:54:15 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] pointer add & sub Date: Wed, 6 Nov 2002 22:44:20 +0000 User-Agent: KMail/1.4.3 References: <1036599485.3dc940bda5920@imp.free.fr> <48070.80.67.170.17.1036599952.squirrel@rezo.net> In-Reply-To: <48070.80.67.170.17.1036599952.squirrel@rezo.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211062244.20293.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >> (you know, Whygee, you told me if I do "add 8,sp,sp", > >> sp would no longer be considered as a pointer). > > I don't understand why, by the way. > > You could have the following : > > - add r3,r2,r1 => r1.pointer = r2.pointer XOR r3.pointer > - sub r3,r2,r1 => r1.pointer = r3.pointer AND NOT r2.pointer > > (as for immediates, the obvious convention is imm8.pointer = false) > > So, unless there are useful exceptions to the above, > you can get rid of special "memory pointer" operations. In fact a pointer imply a TLB check, so it complicate really a lot the normal adder. In F-CPU it's more logical to add a new instruction that only with memory. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Nov 7 00:50:12 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQg-0000PZ-01 for ; Thu, 07 Nov 2002 23:47:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:14 +0100 (CET) Received: (qmail 5950 invoked by uid 0); 6 Nov 2002 23:00:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 6 Nov 2002 23:00:22 -0000 Received: by moria.seul.org (Postfix) id D2F0B15E721; Wed, 6 Nov 2002 18:00:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A51E115E72B; Wed, 6 Nov 2002 18:00:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp3.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 28B4815E721 for ; Wed, 6 Nov 2002 18:00:20 -0500 (EST) Received: from thor (223.188.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.188.223]) by smtp3.9tel.net (Postfix) with ESMTP id E07FE5BD26 for ; Thu, 7 Nov 2002 00:00:08 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Date: Wed, 6 Nov 2002 23:50:12 +0000 User-Agent: KMail/1.4.3 References: <200211042333.19012.cedric.bail@free.fr> <200211052229.00764.cedric.bail@free.fr> <20021106053848.56360@thrai.stud.uni-hannover.de> In-Reply-To: <20021106053848.56360@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211062350.12901.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > It's an interesting idea, but for each instruction in each function in > > each module you need to search in a "database" which chunk to replace and > > then replace it with a mask. But before taking your decision you need to > > execute a allocation algorithm. Currently, with only relocation on x86, a > > lot of people are thinking that time needed by linking is slow... > > You mean run-time (dynamic) linking? We're going to do it at compile > time; there will be no overhead when the program starts. Ok, I was thinking you do this for every linking process. I better understood your idea. So we still need some idea for dynamic librairie. > You don't need a complicated database look-up. You just do the > following: > > get the instruction word > for all register fields do > if the register number has to be replaced > replace it with the new register number > You can use a table-based translation (64 table entries) or an algorithmic > approach (add a constant to the register number if it's inside the range > that is supposed to be `pitch-shifted'). The number of register fields is > available from the opcode (another table with 256 entries). Nothing more, > nothing less. In either case, transposing an instruction will take only > a handful of CPU cycles. For me tjhe 256 entries tables is a database. It's still a lot. I know that a good idea will be to preload into register each possible destination jump, then look in the table for a constant and then do a conditionnal call to the right destination. It can be quite quick and a good approach for the linking process. The problem is that will be an intruisive patch into gcc and ld... > The allocation algorithm isn't complicated either (I outlined it in my > other mail). Perhaps a little bit, but we know how to handle it correctly now. But you need to see your function more like a graph than a tree, and you must for every function that you don't know if they call somebody say that they call every body ! > > But the idea is good, what did you think about a double solution : for > > .o (not librairie), you use your technique and for the rest the technique > > suggested by Arnaud. > Inside a shared library or a program, reallocation can be used as well. > It just won't work at the interface between programs and shared libraries. Where I was thinking with mask register... > > In the prologue you use the mask technique and put a second entry point > > for optimal call. (I don't see why you need to have contiguous register, > > you only need a 64 bits mask per function, so 2 techniques can be used > > together). > Contiguous register numbers make the allocation and transposition easier, > expecially when register pairs are involved. And it's what compilers > usually do: start with the first, and always pick the next available > register. So here you don't whant to change the compiler ;-) I think that's possible to have a register allocation that select them "randomly" and give good result (problem with pair isn't a problem, because you know where to put the second register). > On the other hand, the `double jump' allows us to put multiple wrappers > around the same function without touching the function itself. I was thinking that in the quick entry we didn't save/restore register. So that the wrapper can use the method they want for entering in this function (with or without save, depending on the information they have). > > With this you have both possibility. In fact you don't need to add a jump > > for entry point with your method too, because you can add the 2 entries > > points when you compile. > The link time register reallocation relies on the fact that any number > of wrappers can be added to a function. That has to be done at link time > because the compiler doesn't know how many wrappers it has to provide. We can have a default wrapper and many other that use the normal entry. > > low_entry_point: > > loadcons.1 0xFFFF, r0 > > loadcons.2 0xFFFF, r0 > > loadcons.3 0xFFFF, r0 > > and r0, mr, r1 > > maskstore r1, [sp] ; oups : move qe, m0 not r0, qe > > quick_entry_point: > > // My function > > jmpz qe, r63 > > restore_code: > > loadcons.1 0xFFFF, r0 > > loadcons.2 0xFFFF, r0 > > loadcons.3 0xFFFF, r0 > > and r0, mr, r1 > > maskload r1, [sp] > > jmp r63 > Nice idea, but it still allows only a single wrapper per function. You point to quick_entry_point if you want an other wrapper... > BTW: Your restore code is broken; you'll have to use the modified mask > when you restore the registers, and then put the original mask back in > place. I forgot to set qe ! > But the register numbers are always encoded in the same 1...3 fields > of the instruction word - and that's all that matters. We don't have to > touch the instructions itself, only the register numbers. Of course. > > The problem is doing a optimising linker will really improve the code, > > but will not work for shared code (librairie are loaded only once) and > > will certainly be really slow for big code... The mr is not as optimal as > > your proposition but didn't cost so much each time you run a application. > Au contraire, mon ami! (I always wanted to say that ;) ;-) > Link time register allocation is done *once* for each program - before > it is run. At run time, you'll only waste cycles when you have to > save/restore registers. The `mask' approach also needs some cycles for > bookkeeping (that is, the mask operations), which makes it slower than > link time allocation in the worst case. Of course, but I was only thinking about shared libraire, sorry. > One might consider the `mask' approach as an alternative for the > program/library interface (after all, that looks like the weak point > of my approach). But there is a good argument against it: A reasonably > complex program will use *all* registers internally. That is, you always Perhaps for a program, but not a librairie, and perhaps not between librairie and certainly not every time. > have to save registers when you enter a shared library - with either > approach. Both link time allocation (when the library is built) and > register masking (at run time) help to reduce the number of registers > you have to save, but link time allocation is superior because it has > less run time overhead. I agree. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu Nov 7 00:00:07 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQi-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:16 +0100 (CET) Received: (qmail 17205 invoked by uid 0); 6 Nov 2002 23:00:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 6 Nov 2002 23:00:34 -0000 Received: by moria.seul.org (Postfix) id B781115E728; Wed, 6 Nov 2002 18:00:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 92A1915E731; Wed, 6 Nov 2002 18:00:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 3CB1315E728 for ; Wed, 6 Nov 2002 18:00:33 -0500 (EST) Received: from telehouse-103-1-95.net1.nerim.net (telehouse-103-1-95.net1.nerim.net [213.41.186.95]) by kraid.nerim.net (Postfix) with ESMTP id 963D440F98 for ; Wed, 6 Nov 2002 23:50:42 +0100 (CET) Subject: Re: [f-cpu] pointer add & sub From: Antoine To: f-cpu@seul.org In-Reply-To: <200211062244.20293.cedric.bail@free.fr> References: <1036599485.3dc940bda5920@imp.free.fr> <48070.80.67.170.17.1036599952.squirrel@rezo.net> <200211062244.20293.cedric.bail@free.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 07 Nov 2002 00:00:07 +0100 Message-Id: <1036623607.3087.5.camel@fsol> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > You could have the following : > > > > - add r3,r2,r1 => r1.pointer = r2.pointer XOR r3.pointer > > - sub r3,r2,r1 => r1.pointer = r3.pointer AND NOT r2.pointer > > > > (as for immediates, the obvious convention is imm8.pointer = false) > > > > So, unless there are useful exceptions to the above, > > you can get rid of special "memory pointer" operations. > > In fact a pointer imply a TLB check, so it complicate really a lot the normal > adder. In F-CPU it's more logical to add a new instruction that only with > memory. That doesn't mean you need to have two different opcodes ! (by the way, what is the current opcode count ? the max is 256...) Also, the TLB check is speculative and performed after the addition so it needn't be in the main execution path, does it ? So I don't understand why the adder in itself would be complicated by this. My feeling was that madd/msub had been added because people didn't know how to calculate the pointer flag after a normal arithmetic operation... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Nov 7 00:48:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQn-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:21 +0100 (CET) Received: (qmail 20025 invoked by uid 0); 6 Nov 2002 23:48:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 6 Nov 2002 23:48:59 -0000 Received: by moria.seul.org (Postfix) id 1ABBA15E721; Wed, 6 Nov 2002 18:48:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0EB9415E729; Wed, 6 Nov 2002 18:48:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id D461015E721 for ; Wed, 6 Nov 2002 18:48:55 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00758; Thu, 7 Nov 2002 00:48:54 +0100 Message-ID: <20021107004854.05434@thrai.stud.uni-hannover.de> Date: Thu, 7 Nov 2002 00:48:54 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> <20021106044911.44562@thrai.stud.uni-hannover.de> <1036615007.3080.74.camel@fsol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1036615007.3080.74.camel@fsol>; from Antoine on Wed, Nov 06, 2002 at 09:36:46PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Nov 06, 2002 at 09:36:46PM +0100, Antoine wrote: > > > > That means : > > > - compiler capabilities > > > > Can be added. Hey, it's Free Software, isn't it? > > Of course. But I doubt adding something to gcc is very simple, > especially if you want to do it cleanly so that the maintainers > accept the patch. And in your case the patch might be quite > intrusive, because you are assigning new roles to both compiler > and linker, and it's likely that gcc's current architecture > isn't very adapted. The changes to gcc are rather small. At a minimum, it should report which registers a function uses, and where its code starts and ends (the latter is already available, at least on Linux/ELF systems). An explicit call tree would be nice, too. It's only a list of (caller; callee) pairs that is easy to generate and process. > > Note that GNU ld is not required on all operating systems; > > gcc is usually capable to use the native linker (and assembler) of the > > OS it runs on. > > Yes. But whatever the linker, I don't think linkers are commonly > assumed to mess with instruction codes & register allocation (even > at function boundaries). They perform relocations for memory addresses - why not for registers, too? They also add code and data on their own when they build shared libraries. There's absolutely nothing new, it's all been done before. > So you may end up with custom versions of the gnu tools which will > probably not be very compatible with the standard ones. As long as the tools are free (in the GPL sense), where's the problem? > Your proposal has another big problem : it ruins a part of the > advantages of separate compilation. That is, if the linking part > involves a costly optimization phase, rebuilding a whole project > when changing just a source file will be much slower that it is today. As I already pointed out, the register reallocation phase doesn't cost much. > > It shouldn't be more complex than the register allocation pass inside the > > compiler. Just on a higher level - replace `instruction' with `function', > > and you've got it. > > Are you sure ? You are not dealing only with register numbers but also > register quantities. It's one thing to allocate single registers, it's > another to allocate variable-size register sets. Think about the > difference between a memory allocator that only allocates chunks of a > fixed size, and another one that can allocate chunks of any size. I guess `allocation' was the wrong term. The real allocation is still done by the compiler, the linker only *re*locates them, as it does with memory addresses. > > Unused functions need no processing at all; in > > fact, they may be removed during the process (another win). > > You do not need all this analysis for such a win ;) But you get it for free :) > > Transposing a function > > also requires linear time: each instruction is processed exactly once. > > Well, either the object file carries information about the place of > each register-bitfield needing to be transposed, or the linker does > some on-the-fly disassembling (which makes it heavily architecture > dependent, and is also not a very clean design imho). But I agree > that on a pure operational point of view, this is ok. It's rather > the optimization that bothers me. Hmm... if the compiler would store register relocation entries in the object file, processing could go even faster. But we don't really need it. And yes, this *is* architecture dependent - it won't work on other CPUs (memory relocation is CPU-dependent, too!), although it can probably ported to another RISC CPU with a uniform register set and instruction format. > > The algorithm I have in > > mind will simply process the call tree bottom-up (recursive functions will > > be handled separately). > > What if recursion occurs at multiple stages and in non-trivial ways > (between several functions and even several levels of the function > "tree" - which is in fact a graph because of these recursions) ? As I said, recursive functions will be handled separately (e.g. by always saving all registers used internally). Note that this does not apply to tail-recursive functions (which will be translated to ordinary loops by the compiler). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Nov 7 01:06:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQo-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:22 +0100 (CET) Received: (qmail 12287 invoked by uid 0); 7 Nov 2002 00:08:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 7 Nov 2002 00:08:48 -0000 Received: by moria.seul.org (Postfix) id 16BF515E725; Wed, 6 Nov 2002 19:08:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E56EA15E72B; Wed, 6 Nov 2002 19:08:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 8AC1515E725 for ; Wed, 6 Nov 2002 19:08:45 -0500 (EST) Received: from homeworld (81.48.49.86) by smtp.laposte.net (6.0.053) id 3DB5C8A8001803E8 for f-cpu@seul.org; Thu, 7 Nov 2002 01:08:45 +0100 Message-ID: <001b01c285f1$7b497760$c986fea9@homeworld> From: "Christophe Avoinne" To: References: <200211042333.19012.cedric.bail@free.fr> <200211052229.00764.cedric.bail@free.fr> <20021106053848.56360@thrai.stud.uni-hannover.de> <200211062350.12901.cedric.bail@free.fr> Subject: Re: [f-cpu] New suggestion about call convention Date: Thu, 7 Nov 2002 01:06:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "cedric" To: Sent: Thursday, November 07, 2002 12:50 AM Subject: Re: [f-cpu] New suggestion about call convention > Of course, but I was only thinking about shared libraire, sorry. > > Perhaps for a program, but not a librairie, and perhaps not between librairie > and certainly not every time. > Library, mein Freund, library ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Nov 7 01:10:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQp-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:23 +0100 (CET) Received: (qmail 28483 invoked by uid 0); 7 Nov 2002 00:10:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 7 Nov 2002 00:10:12 -0000 Received: by moria.seul.org (Postfix) id DFCFD15E728; Wed, 6 Nov 2002 19:10:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C265415E72C; Wed, 6 Nov 2002 19:10:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id AEDAF15E728 for ; Wed, 6 Nov 2002 19:10:09 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00848; Thu, 7 Nov 2002 01:10:08 +0100 Message-ID: <20021107011008.56779@thrai.stud.uni-hannover.de> Date: Thu, 7 Nov 2002 01:10:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <200211042333.19012.cedric.bail@free.fr> <200211052229.00764.cedric.bail@free.fr> <20021106053848.56360@thrai.stud.uni-hannover.de> <200211062350.12901.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211062350.12901.cedric.bail@free.fr>; from cedric on Wed, Nov 06, 2002 at 11:50:12PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Nov 06, 2002 at 11:50:12PM +0000, cedric wrote: [...] > For me tjhe 256 entries tables is a database. It's still a lot. I know that a > good idea will be to preload into register each possible destination jump, > then look in the table for a constant and then do a conditionnal call to the > right destination. It can be quite quick and a good approach for the linking > process. In C, it's a `switch (opcode)' statement with 256 case labels but only few different pathes. That is, a jump table will probably be fine. I'll let the compiler choose the implementation, however ;) > The problem is that will be an intruisive patch into gcc and ld... It will be part of the F-CPU port of ld (it's done at link time), and probably not more intrusive than the F-CPU port itself. > > The allocation algorithm isn't complicated either (I outlined it in my > > other mail). > > Perhaps a little bit, but we know how to handle it correctly now. But you need > to see your function more like a graph than a tree, and you must for every > function that you don't know if they call somebody say that they call every > body ! It works vice versa: For every function that is *called* by unknown functions (maybe because its address is passed as a pointer, or because it is an entry point of a shared library), you'll have to provide a wrapper that saves all registers that might be modified inside it, and redirect the calls to the wrapper. [...] > > On the other hand, the `double jump' allows us to put multiple wrappers > > around the same function without touching the function itself. > > I was thinking that in the quick entry we didn't save/restore register. So > that the wrapper can use the method they want for entering in this function > (with or without save, depending on the information they have). The quick entry doesn't save/restore, that's right. > > > With this you have both possibility. In fact you don't need to add a jump > > > for entry point with your method too, because you can add the 2 entries > > > points when you compile. > > > The link time register reallocation relies on the fact that any number > > of wrappers can be added to a function. That has to be done at link time > > because the compiler doesn't know how many wrappers it has to provide. > > We can have a default wrapper and many other that use the normal entry. No - because they'll all have to use the same restore code if you jump (or fall through) to the quick entry point without changing the return address. [...] > > One might consider the `mask' approach as an alternative for the > > program/library interface (after all, that looks like the weak point > > of my approach). But there is a good argument against it: A reasonably > > complex program will use *all* registers internally. That is, you always > > Perhaps for a program, but not a librairie, and perhaps not between librairie > and certainly not every time. A shared library (viewed from the outside) is just a collection of `public' functions that always save the registers they use. If a function uses only a subset, only that subset needs saving. But it's quite likely that the subset used in the library will collide with the one of the program, or with the ones of other shared libraries, so unconditional save/restore seems to be the best guess. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu Nov 7 01:14:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQq-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:24 +0100 (CET) Received: (qmail 12659 invoked by uid 0); 7 Nov 2002 00:15:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 7 Nov 2002 00:15:08 -0000 Received: by moria.seul.org (Postfix) id 4A64115E728; Wed, 6 Nov 2002 19:15:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19E0515E72F; Wed, 6 Nov 2002 19:15:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id B7B8A15E728 for ; Wed, 6 Nov 2002 19:15:06 -0500 (EST) Received: from telehouse-103-1-95.net1.nerim.net (telehouse-103-1-95.net1.nerim.net [213.41.186.95]) by kraid.nerim.net (Postfix) with ESMTP id 4745640F17 for ; Thu, 7 Nov 2002 01:05:16 +0100 (CET) Subject: Re: [f-cpu] New suggestion about call convention From: Antoine To: f-cpu@seul.org In-Reply-To: <20021107004854.05434@thrai.stud.uni-hannover.de> References: <1036530711.3376.39.camel@fsol> <20021106044911.44562@thrai.stud.uni-hannover.de> <1036615007.3080.74.camel@fsol> <20021107004854.05434@thrai.stud.uni-hannover.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 07 Nov 2002 01:14:41 +0100 Message-Id: <1036628081.3192.18.camel@fsol> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > As I said, recursive functions will be handled separately (e.g. by always > saving all registers used internally). Note that this does not apply to > tail-recursive functions (which will be translated to ordinary loops by > the compiler). Maybe I wasn't very clear. There are not only recursive fonctions. There can be non-trivial loops in the function call graph (e.g. A calls B calls C calls A). And lots of funky stuff. Usually when you code something there is no requirement about "keeping the function call graph clean" ;-)) So people don't bother about it... So you may end up with a program where lots of functions won't be optimized at all because of that. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Nov 7 01:47:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQs-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:26 +0100 (CET) Received: (qmail 9003 invoked by uid 0); 7 Nov 2002 00:34:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 7 Nov 2002 00:34:53 -0000 Received: by moria.seul.org (Postfix) id A042F15E727; Wed, 6 Nov 2002 19:34:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80AD715E72C; Wed, 6 Nov 2002 19:34:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 2D4AC15E727 for ; Wed, 6 Nov 2002 19:34:51 -0500 (EST) Received: from f-cpu.org (kdl4-22.n.club-internet.fr [213.44.3.22]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D0B0D169D for ; Thu, 7 Nov 2002 01:34:43 +0100 (CET) Message-ID: <3DC9B81F.30503@f-cpu.org> Date: Thu, 07 Nov 2002 01:47:27 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <20021106143100.64059@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe wrote: >On Wed, Nov 06, 2002 at 11:43:11AM +0100, whygee@club-internet.fr wrote: >[...] > > >>i get the picture. >> >>However, due to the nature of some 2W instructions, >>the "capo" MUST be done with pairs of registers, on a >>"granularity" of 2. That is : you can't do half-tone >>pitch shifting. >> >> > >Right. > i hope that this restriction will not frustrate too much anybdy.... >>Still there is a problem with loadm and storem. >> >> > >If loadm/storem aren't available, we can still use explicit >load/store instructions. > i think that the "explicit" instructions are going to be used for a while because the LSU and Xbar are not designed to handle 4 words at a time. They can do 2 words but LSU has only 1 read and 1 write port (+ address). Otherwise, handling more register at once will explode the bypass logic's size. i hope that nicO understands the problem. So "storem" and "loadm" seem to be very limited (2 words) and i am not even sure that it is still "safe" in FC0. For example, alignment is a big problem : what to do when the 2 words are not aligned on a LSU line boundary, or across pages ?.... if strict alignment is required, then the stack will bloat (filled with empty slots). If it is allowed, then a lot of HW problems are to be solved. If one wants more bandwidth, then a PFQ-based architecture is required, but it requires a complete redesign of everything. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Nov 7 01:47:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQt-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:27 +0100 (CET) Received: (qmail 29192 invoked by uid 0); 7 Nov 2002 00:34:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 7 Nov 2002 00:34:54 -0000 Received: by moria.seul.org (Postfix) id 81EDB15E72B; Wed, 6 Nov 2002 19:34:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57FA315E730; Wed, 6 Nov 2002 19:34:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 008BD15E72B for ; Wed, 6 Nov 2002 19:34:53 -0500 (EST) Received: from f-cpu.org (kdl4-22.n.club-internet.fr [213.44.3.22]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 3638116A7 for ; Thu, 7 Nov 2002 01:34:51 +0100 (CET) Message-ID: <3DC9B822.7000900@f-cpu.org> Date: Thu, 07 Nov 2002 01:47:30 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] pointer add & sub References: <1036599485.3dc940bda5920@imp.free.fr> <48070.80.67.170.17.1036599952.squirrel@rezo.net> <200211062244.20293.cedric.bail@free.fr> <1036623607.3087.5.camel@fsol> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Antoine wrote: >>>You could have the following : >>> >>>- add r3,r2,r1 => r1.pointer = r2.pointer XOR r3.pointer >>>- sub r3,r2,r1 => r1.pointer = r3.pointer AND NOT r2.pointer >>> >>>(as for immediates, the obvious convention is imm8.pointer = false) >>> >>>So, unless there are useful exceptions to the above, >>>you can get rid of special "memory pointer" operations. >>> >>> >>In fact a pointer imply a TLB check, so it complicate really a lot the normal >>adder. In F-CPU it's more logical to add a new instruction that only with >>memory. >> >> > >That doesn't mean you need to have two different opcodes ! > madd needs no saturation, SIMD or whatever. but if madd is a subset of add, it has another function and there is no room left in the opcode.... >(by the way, what is the current opcode count ? the max is 256...) > are we still around 110 ? >Also, the TLB check is speculative and performed after the addition >so it needn't be in the main execution path, does it ? So I don't >understand why the adder in itself would be complicated by this. > > the adder itself is not changed. however, checking ALL results from Xbar in the TLB (just as the "zero check" does) consumes more resources and power. By only "activating" the TLB when needed, this part consumes less power. >My feeling was that madd/msub had been added because people >didn't know how to calculate the pointer flag after a normal >arithmetic operation... > > The pointer flag is nothing. The "valid" flag is more important. FYI : There are two flags (on top of the zero and some for SRB when/if implemented) : - "pointer flag" - "pointer valid flag". And this is "only a model", as the implementation can differ (for example with some associative memory instead of 1 flag per register). when "pointer flag" is unset AND a load/store is required, then a "penalty cycle" (several cycles in fact) is necessary to "refresh" the flag. when it is set, "pointer valid" indicated whether to trap or continue. An additional flag is necessary to distinguish between data and instruction, but it can also be implemented as a set of 2 separate associative memory blocks. Another rule is that after any operation, the register's "pointer" flag is cleared (or the entry is removed from the CAM). This is to prevent any case of protection violation or race conditions or whatever. So if a "normal" operation updates a register which then used as a pointer, the TLB must be rechecked. Only the post-incremented instructions do update the "pointer valid" flag (after it has been reset, like with any other instructions) because it's the most common case. The loopentry/prefetch family of instructions also "copy" the pointer flags. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Nov 7 03:38:42 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vQz-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:33 +0100 (CET) Received: (qmail 15002 invoked by uid 0); 7 Nov 2002 02:41:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 7 Nov 2002 02:41:23 -0000 Received: by moria.seul.org (Postfix) id AC18915E725; Wed, 6 Nov 2002 21:41:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A09E815E729; Wed, 6 Nov 2002 21:41:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 5545215E725 for ; Wed, 6 Nov 2002 21:41:22 -0500 (EST) Received: from homeworld (81.48.49.86) by smtp.laposte.net (6.0.053) id 3DB5C84D0017B899 for f-cpu@seul.org; Thu, 7 Nov 2002 03:41:19 +0100 Message-ID: <002a01c28606$cbf08ae0$c986fea9@homeworld> From: "Christophe Avoinne" To: References: <20021106143100.64059@thrai.stud.uni-hannover.de> <3DC9B81F.30503@f-cpu.org> Subject: Re: [f-cpu] New suggestion about call convention Date: Thu, 7 Nov 2002 03:38:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Thursday, November 07, 2002 1:47 AM Subject: Re: [f-cpu] New suggestion about call convention > If one wants more bandwidth, then a PFQ-based architecture is required, > but it requires a complete redesign of everything. Something like 32x64-bit PFQs ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Nov 7 10:12:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vRG-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:50 +0100 (CET) Received: (qmail 25899 invoked by uid 0); 7 Nov 2002 09:12:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 7 Nov 2002 09:12:21 -0000 Received: by moria.seul.org (Postfix) id C7D1315E725; Thu, 7 Nov 2002 04:12:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79E9B15E72B; Thu, 7 Nov 2002 04:12:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 893C115E725 for ; Thu, 7 Nov 2002 04:12:19 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211070912.0193; Thu, 7 Nov 2002 09:12:01 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] New suggestion about call convention From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Nov 2002 09:12:01 GMT Message-id: <200211070912.0193@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 07/11/02 Objet: Re: [f-cpu] New suggestion about call convention Michael Riepe wrote: >On Wed, Nov 06, 2002 at 11:43:11AM +0100, whygee@club-inter= net.fr wrote: >[...] > =20 > >>i get the picture. >> >>However, due to the nature of some 2W instructions, >>the "capo" MUST be done with pairs of registers, on a >>"granularity" of 2. That is : you can't do half-tone >>pitch shifting. >> =20 >> > >Right. > i hope that this restriction will not frustrate too much any= bdy.... >>Still there is a problem with loadm and storem. >> =20 >> > >If loadm/storem aren't available, we can still use explicit >load/store instructions. > i think that the "explicit" instructions are going to be use= d for a while because the LSU and Xbar are not designed to handle 4 words = at a time. They can do 2 words but LSU has only 1 read and 1 write port= (+ address). >>>> I don't see any problem for that. Otherwise, handling more register at once will explode the b= ypass=20 logic's size. >>>I have soon write some graph on it but it became old and = i forgot about it. i hope that nicO understands the problem. So "storem" and "l= oadm" seem to be very limited (2 words) and i am not even sure that it = is still=20 "safe" in FC0. >>> 2 words is not so interesting, 8 or 4 is much better (8 = imply very very large datapath). For example, alignment is a big problem : what to do when th= e 2 words are not aligned on a LSU line boundary, or across pages ?...= . >>>For something simple it must be memory aligned to enable = the load of a complete cache line. Otherwise, the data path will be full= of muxes. So there is no exception problem. If you enable that feature= , it's always the same : check the exception the earlier. if strict alignment is required, then the stack will bloat (= filled with empty slots). If it is allowed, then a lot of HW problems ar= e to be solved. >>> ? Why ? For better data handling, we must consider 2 cases SIMD or n= ot. Otherwise, if all mload/mstore are SIMD, using it for scalar= operation will be a mess. If one wants more bandwidth, then a PFQ-based architecture i= s required, but it requires a complete redesign of everything. >>>a WHAT ? nicO YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Nov 7 11:11:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vRH-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:51 +0100 (CET) Received: (qmail 22707 invoked by uid 0); 7 Nov 2002 09:59:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 7 Nov 2002 09:59:00 -0000 Received: by moria.seul.org (Postfix) id CDE0F15E729; Thu, 7 Nov 2002 04:59:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABFC615E730; Thu, 7 Nov 2002 04:59:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5D7A915E729 for ; Thu, 7 Nov 2002 04:59:00 -0500 (EST) Received: from f-cpu.org (kdl4-118.n.club-internet.fr [213.44.3.118]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 1587D16E7 for ; Thu, 7 Nov 2002 10:58:59 +0100 (CET) Message-ID: <3DCA3C5A.8090904@f-cpu.org> Date: Thu, 07 Nov 2002 11:11:38 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <20021106143100.64059@thrai.stud.uni-hannover.de> <3DC9B81F.30503@f-cpu.org> <002a01c28606$cbf08ae0$c986fea9@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Christophe Avoinne wrote: From: "Yann Guidon" > >>If one wants more bandwidth, then a PFQ-based architecture is required, >>but it requires a complete redesign of everything. >> >> >Something like 32x64-bit PFQs ? > that would kick ass, right ? :-P YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu Nov 7 11:52:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vRJ-0000PZ-01 for ; Thu, 07 Nov 2002 23:47:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:53 +0100 (CET) Received: (qmail 19568 invoked by uid 0); 7 Nov 2002 10:52:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 7 Nov 2002 10:52:55 -0000 Received: by moria.seul.org (Postfix) id 653D415E72B; Thu, 7 Nov 2002 05:52:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5126015E732; Thu, 7 Nov 2002 05:52:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 0D7D015E72B for ; Thu, 7 Nov 2002 05:52:48 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id 884021C061 for ; Thu, 7 Nov 2002 11:52:47 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Thu, 7 Nov 2002 11:52:47 +0100 (CET) Message-ID: <45702.80.67.170.17.1036666367.squirrel@rezo.net> Date: Thu, 7 Nov 2002 11:52:47 +0100 (CET) Subject: Re: [f-cpu] pointer add & sub From: "Antoine" To: In-Reply-To: <3DC9B822.7000900@f-cpu.org> References: <3DC9B822.7000900@f-cpu.org> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, > however, checking ALL results from Xbar in the TLB (just as the "zero > check" does) > consumes more resources and power. By only "activating" the TLB when > needed, this part consumes less power. Once again : so what ? You don't need another opcode to "activate" the TLB. You just have to trigger it if the pointer flag is set. The pointer flag can be calculated very simply, as I've shown. So : - you calculate the pointer flag (this can be done in parallel to the addition) - at the end of the addition, if the pointer flag is set, you activate the TLB That is, instead of having this flag determined by the opcode, you just calculate it (using a very straightforward formula) at runtime inside the CPU. > And this is "only a model", as the implementation can differ (for > example with some associative memory instead of 1 flag per register). If implementation can differ, then madd is all the more useless because its use may be deprecated in next versions of the CPU. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Nov 7 01:59:20 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 189vRP-0000PZ-00 for ; Thu, 07 Nov 2002 23:47:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Nov 2002 23:47:59 +0100 (CET) Received: (qmail 3492 invoked by uid 0); 7 Nov 2002 13:21:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 7 Nov 2002 13:21:14 -0000 Received: by moria.seul.org (Postfix) id E25C315E731; Thu, 7 Nov 2002 08:21:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3A3715E73D; Thu, 7 Nov 2002 08:21:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a104.home.uni-hannover.de [130.75.232.104]) by moria.seul.org (Postfix) with ESMTP id C9FBF15E731 for ; Thu, 7 Nov 2002 08:21:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00994; Thu, 7 Nov 2002 01:59:21 +0100 Message-ID: <20021107015920.15026@thrai.stud.uni-hannover.de> Date: Thu, 7 Nov 2002 01:59:20 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> <20021106044911.44562@thrai.stud.uni-hannover.de> <1036615007.3080.74.camel@fsol> <20021107004854.05434@thrai.stud.uni-hannover.de> <1036628081.3192.18.camel@fsol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1036628081.3192.18.camel@fsol>; from Antoine on Thu, Nov 07, 2002 at 01:14:41AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Nov 07, 2002 at 01:14:41AM +0100, Antoine wrote: > > > As I said, recursive functions will be handled separately (e.g. by always > > saving all registers used internally). Note that this does not apply to > > tail-recursive functions (which will be translated to ordinary loops by > > the compiler). > > Maybe I wasn't very clear. There are not only recursive fonctions. There > can be non-trivial loops in the function call graph (e.g. A calls B > calls C calls A). And lots of funky stuff. Usually when you code > something there is no requirement about "keeping the function call > graph clean" ;-)) So people don't bother about it... > > So you may end up with a program where lots of functions won't be > optimized at all because of that. No problem, there is a solution for that. If A, B and C form a loop, you can put a `save-all' wrapper around one of them, and the loop will be broken. The only thing that matters is the register set of the callee; if that set is empty, you can delete the (caller; callee) edge from the graph, the loop vanishes, and you can handle the rest like any other non-recursive function. Inserting a `save-all' wrapper by definition empties the register set, so... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Nov 8 16:22:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B0zW-00010s-00 for ; Sun, 10 Nov 2002 23:55:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:55:42 +0100 (CET) Received: (qmail 12554 invoked by uid 0); 8 Nov 2002 15:22:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 8 Nov 2002 15:22:19 -0000 Received: by moria.seul.org (Postfix) id 4FE5615E756; Fri, 8 Nov 2002 10:22:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 32ED815E759; Fri, 8 Nov 2002 10:22:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14908.mail.yahoo.com (web14908.mail.yahoo.com [216.136.225.60]) by moria.seul.org (Postfix) with SMTP id 9794815E756 for ; Fri, 8 Nov 2002 10:22:17 -0500 (EST) Message-ID: <20021108152215.73063.qmail@web14908.mail.yahoo.com> Received: from [132.166.133.152] by web14908.mail.yahoo.com via HTTP; Fri, 08 Nov 2002 16:22:15 CET Date: Fri, 8 Nov 2002 16:22:15 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: [f-cpu] Comment on Manual 0.2.6 To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, At last, I have entirelly read the manual, and I have some error or problems. On the content, I have see one big error on the instruction set and some minor mistake : * The big error is on the function description of "expand" instruction (p.140), it is give : " This is the reverse operation of the "mix" instruction..." This is false, if we look the figure 2.2, take the following example : r1="12345678" r2="abcdefgh" mixl r1,r2,r3 => r3="1a2b3c4d" mixh r1,r2,r4 => r4="5e6f7g8h" expandl r3,r4,r1 => r1="15263748" expandh r3,r4,r2 => r2="aebfcgdh" If expand is the reverse operation of mix then r1 before and after mix and expand sequence must be equals. * Some minor errors are into example of "sub" and "addsub" instructions (p.80 and 93). I am not a genius;-), but if r1=r2-r3 and r3 <= r2 then r1 >= 0 :-P. With : r1=0x05 and r2=0x07 We have : sub.b r1,r2,r3 => r3=0x02 in any case and if (r1)+1=r2-r3 and r3 <= r2 then (r1)+1 >= 0 :-P. with : r1=0x23 and r2=0x36 We have : addsub.b r1,r2,r3 => r3=0x59 and r4=0x13 * In chapter 3.3 (p.54) in paragraph 4, the text "...number is cleared : 0>1, 11>10..." must be replaced by "...number is cleared : 1>0, 11>10..." On the presentation aspect, I have many remarks : * It is better if chapter (and Part title) begin on the right page (I have made a recto-verso printing and lot of chapter began on left page). * In part IV - advanced topics, the text before the chapter 1 (p.59) can be included into a chapter named Overview. * It seems missing a mandatory package into the tex header, because all the mathematic symbols like sqrt is transforme, likewise with "r1+1" (to say the r1's follower register) wich become : r1&1circ; * It is better if we begin the Instruction Set section by a "notation" section where we gave the syntax legend, like "When an instruction is given into the description of function object, it is write into italic bold" in example. In that case, we can remove the " into description of addi (p.95) into "...to the add" instruction..." ;-) * In Performance section of each instruction, the "Execution Unit" name could be followed by its short abbrev. * Into chapter VI.2, the "Flag" definition tables overflow on the right side (and I miss the end of the definition) * For "bitop" and "bitopi", the F tables aren't similar of presentation used with other instruction, more the "bitopi" and the "bitop" format presentation are different one give F only inside the "Flag" definition, the other give it into the flag and outside. * The following instructions haven't the same bits ordering, inconsistent with the the format description gived into chapter V.2, than others: "logic", "logici", "move", "loadaddr". * In chapter VI.4 on floating point operations, a default operator size must be given. * In chapter VI.5, to describe the endian flag, the presentation must be uniformized on the model of other parameter (1 if big endian => loade by example). * In paragraph VI.5.2.5, it missing the format description and the flag explanation. * In paragraph VI.5.2.6, the memory level postfix must be lowercase. * In "move" and "jump" instructions, the conditions postfix "-nz, -nm, -nl" are redundant with the Flag 10 definition. More the Condition definition table and the Flag definition tables must be coherent => merge bit 10 to 12 under name Condition oder split them like negation/condition and adapt the second table. Some spelling mistakes: * In chapter III.3.4 (p.55): "...For these reason, it would is difficult..." must be replaced by "...For these reason, it would be difficult..." * In chapter IV.1 into the third cause (p.61): "...otherwise the result will sturate..." must be replaced by "...otherwise the result will saturate..." * In chapter V.1 (p.69) in second paragraph: "For the F-CPUU..." must be replaced by "For the F-CPU..." and "...(ISA) faces a lot of constraints and evolitivity..." must be replaced by "...(ISA) faces a lot of constraints and evolutivity..." * Into the Instruction set draft section, you have many "...wrap"..." Other topics: * In chapter IV.3-Scheduler (p.66), what meens: "On average, it is propable that the 2 write ports of the register set are used 70the data is actually available" I don't understand "70the" :-? * In chapter V.1 (p.69), the figure 1.1 and the text are inconsistent with the instructions format description gived into chapter V.2 (p.71) (same remarks on chapter V.2 text). Into the description, the opcode is localized into bit 31 to bit 24 position, which is a MSB position, and the destination register is given on LSB position. * In case of "popcounti" : If the Imm8 parameter is really optional, we can add a remark to signalized than "popcount" is functionnaly equivalent to "popcounti" without r3 and Imm8 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Nov 8 22:02:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B0zi-00010s-00 for ; Sun, 10 Nov 2002 23:55:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:55:54 +0100 (CET) Received: (qmail 9429 invoked by uid 0); 8 Nov 2002 20:12:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 8 Nov 2002 20:12:35 -0000 Received: by moria.seul.org (Postfix) id 4A2C015E758; Fri, 8 Nov 2002 15:12:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F01F415E75D; Fri, 8 Nov 2002 15:12:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id E914615E758 for ; Fri, 8 Nov 2002 15:12:27 -0500 (EST) Received: from thor (nas-cbv-8-62-147-158-230.dial.proxad.net [62.147.158.230]) by postfix3-1.free.fr (Postfix) with ESMTP id 4C3A3D9EC4 for ; Fri, 8 Nov 2002 21:12:26 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Comment on Manual 0.2.6 Date: Fri, 8 Nov 2002 21:02:21 +0000 User-Agent: KMail/1.4.3 References: <20021108152215.73063.qmail@web14908.mail.yahoo.com> In-Reply-To: <20021108152215.73063.qmail@web14908.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211082102.21982.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Just a quick reply, did you speak about 0.2.6 or 0.2.7 ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 9 12:42:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B100-00010s-01 for ; Sun, 10 Nov 2002 23:56:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:12 +0100 (CET) Received: (qmail 12801 invoked by uid 0); 9 Nov 2002 11:30:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 9 Nov 2002 11:30:56 -0000 Received: by moria.seul.org (Postfix) id AA21615E74C; Sat, 9 Nov 2002 06:30:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 77BB215E75A; Sat, 9 Nov 2002 06:30:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id E84E415E74C for ; Sat, 9 Nov 2002 06:30:54 -0500 (EST) Received: from thor (nas-cbv-8-62-147-156-135.dial.proxad.net [62.147.156.135]) by postfix3-2.free.fr (Postfix) with ESMTP id 00FB317E4D for ; Sat, 9 Nov 2002 12:30:52 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Comment on Manual 0.2.6 Date: Sat, 9 Nov 2002 11:42:36 +0000 User-Agent: KMail/1.4.3 References: <20021108152215.73063.qmail@web14908.mail.yahoo.com> In-Reply-To: <20021108152215.73063.qmail@web14908.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211091142.36322.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N A longer reply, > On the content, I have see one big error on the > instruction set and some minor mistake : > * The big error is on the function description of > "expand" instruction (p.140), it is give : > " This is the reverse operation of the "mix" > instruction..." > This is false, if we look the figure 2.2, take the > following example : > r1="12345678" r2="abcdefgh" > mixl r1,r2,r3 => r3="1a2b3c4d" > mixh r1,r2,r4 => r4="5e6f7g8h" > expandl r3,r4,r1 => r1="15263748" > expandh r3,r4,r2 => r2="aebfcgdh" > If expand is the reverse operation of mix then r1 > before and after mix and expand sequence must be > equals. It's true, and I wanted to start a discussion about this problem. Normally, if expand is the reverse opertion of the mix operation, it must be a 1r2w. So we must correct the manual. I don't know how currently, perhaps by saying that mix is used with expand to pack/unpack data in SIMD operation. > * Some minor errors are into example of "sub" and > "addsub" instructions (p.80 and 93). > I am not a genius;-), but if r1=r2-r3 and r3 <= r2 > then r1 >= 0 :-P. > With : r1=0x05 and r2=0x07 > We have : sub.b r1,r2,r3 => r3=0x02 in any case > and if (r1)+1=r2-r3 and r3 <= r2 then (r1)+1 >= 0 :-P. > with : r1=0x23 and r2=0x36 > We have : addsub.b r1,r2,r3 => r3=0x59 and r4=0x13 I never take the time to read sample, but that a good idea. > * In chapter 3.3 (p.54) in paragraph 4, the text > "...number is cleared : 0>1, 11>10..." must be > replaced by "...number is cleared : 1>0, 11>10..." > On the presentation aspect, I have many remarks : > * It is better if chapter (and Part title) begin on > the right page (I have made a recto-verso printing and > lot of chapter began on left page). I will look what the result of a recto-verso printing is and correct it if necessary for next result. > * In part IV - advanced topics, the text before the > chapter 1 (p.59) can be included into a chapter named > Overview. > * It seems missing a mandatory package into the tex > header, because all the mathematic symbols like sqrt > is transforme, likewise with "r1+1" (to say the r1's > follower register) wich become : r1&1circ; I think you read an old manual, currently it's r1 ^ 1, that mean r1 xor 1. > * It is better if we begin the Instruction Set section > by a "notation" section where we gave the syntax > legend, like "When an instruction is given into the > description of function object, it is write into > italic bold" in example. In that case, we can remove > the " into description of addi (p.95) into "...to the add" > instruction..." ;-) It's an idea. > * In Performance section of each instruction, the > "Execution Unit" name could be followed by its short > abbrev. Right. > * Into chapter VI.2, the "Flag" definition tables > overflow on the right side (and I miss the end of the > definition) > * For "bitop" and "bitopi", the F tables aren't > similar of presentation used with other instruction, > more the "bitopi" and the "bitop" format presentation > are different one give F only inside the "Flag" > definition, the other give it into the flag and > outside. In fact we have an other problem with bitopi, it's an other form of instruction (6 bits immediate). > * The following instructions haven't the same bits > ordering, inconsistent with the the format description > gived into chapter V.2, than others: "logic", > "logici", "move", "loadaddr". I don't see the problem with this instruction. > * In chapter VI.4 on floating point operations, a > default operator size must be given. What did you mean by a "default operator size" ? > * In chapter VI.5, to describe the endian flag, the > presentation must be uniformized on the model of other > parameter (1 if big endian => loade by example). > * In paragraph VI.5.2.5, it missing the format > description and the flag explanation. > * In paragraph VI.5.2.6, the memory level postfix must > be lowercase. > * In "move" and "jump" instructions, the conditions > postfix "-nz, -nm, -nl" are redundant with the Flag 10 > definition. More the Condition definition table and > the Flag definition tables must be coherent => merge > bit 10 to 12 under name Condition oder split them like > negation/condition and adapt the second table. I think it solved in manual 0.2.7. > Some spelling mistakes: > * In chapter III.3.4 (p.55): "...For these reason, it > would is difficult..." must be replaced by "...For > these reason, it would be difficult..." > * In chapter IV.1 into the third cause (p.61): > "...otherwise the result will sturate..." must be > replaced by "...otherwise the result will saturate..." > * In chapter V.1 (p.69) in second paragraph: "For the > F-CPUU..." must be replaced by "For the F-CPU..." and I think you read manual 0.2.6 ;-) > "...(ISA) faces a lot of constraints and > evolitivity..." must be replaced by "...(ISA) faces a > lot of constraints and evolutivity..." > * Into the Instruction set draft section, you have > many "...wrap"..." I will correct all this mistake during the week-end and I will post a new unstable manual (0.2.7b) monday or tuesday. > Other topics: > * In chapter IV.3-Scheduler (p.66), what meens: "On > average, it is propable that the 2 write ports of the > register set are used 70the data is actually > available" > I don't understand "70the" :-? Me too... > * In chapter V.1 (p.69), the figure 1.1 and the text > are inconsistent with the instructions format > description gived into chapter V.2 (p.71) (same > remarks on chapter V.2 text). > Into the description, the opcode is localized into bit > 31 to bit 24 position, which is a MSB position, and > the destination register is given on LSB position. I forgot to correct this in 0.2.7... > * In case of "popcounti" : If the Imm8 parameter is > really optional, we can add a remark to signalized > than "popcount" is functionnaly equivalent to > "popcounti" without r3 and Imm8 I will update 0.2.7 manual with your remark. It's nice to know that somebody totally read the manual ;-) But did somebody read the 0.2.7 manual ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 9 12:51:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B102-00010s-00 for ; Sun, 10 Nov 2002 23:56:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:14 +0100 (CET) Received: (qmail 14101 invoked by uid 0); 9 Nov 2002 11:31:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Nov 2002 11:31:04 -0000 Received: by moria.seul.org (Postfix) id 39F9F15E750; Sat, 9 Nov 2002 06:30:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24DE115E75B; Sat, 9 Nov 2002 06:30:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id C7B6D15E750 for ; Sat, 9 Nov 2002 06:30:55 -0500 (EST) Received: from thor (nas-cbv-8-62-147-156-135.dial.proxad.net [62.147.156.135]) by postfix3-2.free.fr (Postfix) with ESMTP id A709517E81 for ; Sat, 9 Nov 2002 12:30:54 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Date: Sat, 9 Nov 2002 11:51:52 +0000 User-Agent: KMail/1.4.3 References: <1036530711.3376.39.camel@fsol> <1036628081.3192.18.camel@fsol> <20021107015920.15026@thrai.stud.uni-hannover.de> In-Reply-To: <20021107015920.15026@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211091151.52968.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > No problem, there is a solution for that. If A, B and C form a loop, > you can put a `save-all' wrapper around one of them, and the loop will > be broken. > The only thing that matters is the register set of the callee; if > that set is empty, you can delete the (caller; callee) edge from the > graph, the loop vanishes, and you can handle the rest like any other > non-recursive function. Inserting a `save-all' wrapper by definition > empties the register set, so... Well it's not so easy. What append if : A call B B call C C call an external function This external function call A. You don't have any information about the external function, so you must save all register before calling it (I really mean all, not only the one that used by C, but the one that are used by B too, because B will certainly crash them). So we must detect call back function, but that not so easy. Of course you have pointer to function, it's easy to say that their are callback, but sometime you give fixed name to callback, and in that case you can't detect them (With some graphical toolkit, I remember that I used a "callback" to initialise the interface before the interface call it. So it's not because a function is call in your source code, that it isn't a callback). This is a very big problem of your algorithm. The only solution is to use a call-graph to know who call each function and to link it with every library... In fact the problem is that you can take a decision only if you totally know the world around your program ! That's a big problem. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Nov 10 16:14:24 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B108-00010s-00 for ; Sun, 10 Nov 2002 23:56:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:20 +0100 (CET) Received: (qmail 8333 invoked by uid 0); 9 Nov 2002 15:13:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 9 Nov 2002 15:13:35 -0000 Received: by moria.seul.org (Postfix) id 34DAA15E751; Sat, 9 Nov 2002 10:13:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1B9A615E75D; Sat, 9 Nov 2002 10:13:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id C4BBC15E751 for ; Sat, 9 Nov 2002 10:13:33 -0500 (EST) Received: from Biathlon (vlt6-151.n.club-internet.fr [194.158.119.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id C6EF716F6 for ; Sat, 9 Nov 2002 16:13:24 +0100 (CET) Date: Sun, 10 Nov 2002 16:14:24 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Comment on Manual 0.2.6 Message-Id: <20021110161424.4c8175ae.nicolas.boulay@ifrance.com> In-Reply-To: <200211091142.36322.cedric.bail@free.fr> References: <20021108152215.73063.qmail@web14908.mail.yahoo.com> <200211091142.36322.cedric.bail@free.fr> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 9 Nov 2002 11:42:36 +0000 cedric wrote: > > I will update 0.2.7 manual with your remark. It's nice to know that somebody > totally read the manual ;-) But did somebody read the 0.2.7 manual ? > That's a really udge task to read this all. Is it possible to only read the difference between version (in the Leon project there is a line in front of modified text, sometimes there is many line if the text have change twice or more). nicO > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! > Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 9 17:12:20 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B108-00010s-01 for ; Sun, 10 Nov 2002 23:56:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:20 +0100 (CET) Received: (qmail 3131 invoked by uid 0); 9 Nov 2002 15:22:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 9 Nov 2002 15:22:36 -0000 Received: by moria.seul.org (Postfix) id AEA6015E786; Sat, 9 Nov 2002 10:22:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8CB9E15E794; Sat, 9 Nov 2002 10:22:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 95ECE15E786 for ; Sat, 9 Nov 2002 10:22:33 -0500 (EST) Received: from thor (nas-cbv-8-62-147-158-174.dial.proxad.net [62.147.158.174]) by postfix2-1.free.fr (Postfix) with ESMTP id 18640CF for ; Sat, 9 Nov 2002 16:22:32 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Comment on Manual 0.2.6 Date: Sat, 9 Nov 2002 16:12:20 +0000 User-Agent: KMail/1.4.3 References: <20021108152215.73063.qmail@web14908.mail.yahoo.com> <200211091142.36322.cedric.bail@free.fr> <20021110161424.4c8175ae.nicolas.boulay@ifrance.com> In-Reply-To: <20021110161424.4c8175ae.nicolas.boulay@ifrance.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211091612.20863.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > On Sat, 9 Nov 2002 11:42:36 +0000 > cedric wrote: > > I will update 0.2.7 manual with your remark. It's nice to know that > > somebody totally read the manual ;-) But did somebody read the 0.2.7 > > manual ? > That's a really udge task to read this all. > Is it possible to only read the difference between version (in the Leon > project there is a line in front of modified text, sometimes there is many > line if the text have change twice or more). Currently we only have this for instruction look at the header, when it orange it has changed since the last release. I will look what I can do for the rest. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Nov 9 20:21:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10F-00010s-00 for ; Sun, 10 Nov 2002 23:56:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:27 +0100 (CET) Received: (qmail 26213 invoked by uid 0); 9 Nov 2002 19:23:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Nov 2002 19:23:30 -0000 Received: by moria.seul.org (Postfix) id F351015E75B; Sat, 9 Nov 2002 14:23:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E740915E760; Sat, 9 Nov 2002 14:23:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 80EAD15E75B for ; Sat, 9 Nov 2002 14:23:28 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by bach.ccinet.ab.ca (8.12.3/8.12.5) with ESMTP id gA9JPX6j009944 for ; Sat, 9 Nov 2002 12:25:34 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DCD6050.3060102@jetnet.ab.ca> Date: Sat, 09 Nov 2002 12:21:52 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> <1036628081.3192.18.camel@fsol> <20021107015920.15026@thrai.stud.uni-hannover.de> <200211091151.52968.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N cedric wrote: > Well it's not so easy. What append if : > > A call B > B call C > C call an external function > This external function call A. > > You don't have any information about the external function, so you must save > all register before calling it (I really mean all, not only the one that used > by C, but the one that are used by B too, because B will certainly crash > them). > But the point is you have all the calling information. It may mean a extra pass in the compiler but it can be done. Also since this works best with leaf functions you could do this with say three passes. pass #1 all functions with no calls or system calls only. pass #2 all functions that call level #1 functions ... pass #3 all functions that call level #2 and #1 functions. At the same time functions could be tagged for in-line macro replacement. The old compile/run time trade off again. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 9 22:37:24 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10Q-00010s-00 for ; Sun, 10 Nov 2002 23:56:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:38 +0100 (CET) Received: (qmail 28968 invoked by uid 0); 9 Nov 2002 20:48:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 9 Nov 2002 20:48:00 -0000 Received: by moria.seul.org (Postfix) id 8F41D15E75E; Sat, 9 Nov 2002 15:47:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 626F515E766; Sat, 9 Nov 2002 15:47:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by moria.seul.org (Postfix) with ESMTP id 2109A15E75E for ; Sat, 9 Nov 2002 15:47:59 -0500 (EST) Received: from thor (nas-cbv-7-62-147-155-140.dial.proxad.net [62.147.155.140]) by postfix3-1.free.fr (Postfix) with ESMTP id 93A9FD9ED7 for ; Sat, 9 Nov 2002 21:47:57 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Date: Sat, 9 Nov 2002 21:37:24 +0000 User-Agent: KMail/1.4.3 References: <1036530711.3376.39.camel@fsol> <200211091151.52968.cedric.bail@free.fr> <3DCD6050.3060102@jetnet.ab.ca> In-Reply-To: <3DCD6050.3060102@jetnet.ab.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211092137.24307.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > But the point is you have all the calling information. > It may mean a extra pass in the compiler but it can be done. > Also since this works best with leaf functions you could do this with > say three passes. pass #1 all functions with no calls or system calls > only. pass #2 all functions that call level #1 functions ... pass #3 > all functions that call level #2 and #1 functions. > At the same time functions could be tagged for in-line macro > replacement. The old compile/run time trade off again. What append if my library staticaly call a function foo () that is used in my code by the main function. /* Main.c */ static void bar () {} void foo () { bar (); } int main (int argc, char argv[]) { libcall (); foo (); } /* Mylib.c */ void libcall () { foo (); } I think that you couldn't know anything about the librairie, and you couldn't detect if your program use this thing or not, because it came from the outside... Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Nov 10 22:29:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10Q-00010s-01 for ; Sun, 10 Nov 2002 23:56:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:38 +0100 (CET) Received: (qmail 17444 invoked by uid 0); 9 Nov 2002 21:31:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Nov 2002 21:31:06 -0000 Received: by moria.seul.org (Postfix) id 9BA8415E75B; Sat, 9 Nov 2002 16:31:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7BAE015E766; Sat, 9 Nov 2002 16:31:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id D9EF615E75B for ; Sat, 9 Nov 2002 16:31:04 -0500 (EST) Received: from Biathlon (vlt6-48.n.club-internet.fr [194.158.119.48]) by relay-4v.club-internet.fr (Postfix) with SMTP id 7B7F41710 for ; Sat, 9 Nov 2002 22:31:02 +0100 (CET) Date: Sun, 10 Nov 2002 22:29:46 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Message-Id: <20021110222946.046c1d0b.nicolas.boulay@ifrance.com> In-Reply-To: <200211092137.24307.cedric.bail@free.fr> References: <1036530711.3376.39.camel@fsol> <200211091151.52968.cedric.bail@free.fr> <3DCD6050.3060102@jetnet.ab.ca> <200211092137.24307.cedric.bail@free.fr> X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 9 Nov 2002 21:37:24 +0000 cedric wrote: > > But the point is you have all the calling information. > > It may mean a extra pass in the compiler but it can be done. > > Also since this works best with leaf functions you could do this with > > say three passes. pass #1 all functions with no calls or system calls > > only. pass #2 all functions that call level #1 functions ... pass #3 > > all functions that call level #2 and #1 functions. > > At the same time functions could be tagged for in-line macro > > replacement. The old compile/run time trade off again. > > What append if my library staticaly call a function foo () that is used in my > code by the main function. > > /* > Main.c > */ > > static void bar () {} > void foo () { bar (); } > > int main (int argc, char argv[]) > { > libcall (); > foo (); > } > > /* > Mylib.c > */ > > void libcall () { foo (); } > > I think that you couldn't know anything about the librairie, and you couldn't > detect if your program use this thing or not, because it came from the > outside... You're right. But i thinl this case is a ill one. I hope nobody code like that ! So maybe the 20-80 rule apply. This case could not be optimised but the common one could. nicO > > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! > Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 9 23:41:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10R-00010s-00 for ; Sun, 10 Nov 2002 23:56:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:39 +0100 (CET) Received: (qmail 8040 invoked by uid 0); 9 Nov 2002 21:51:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 9 Nov 2002 21:51:55 -0000 Received: by moria.seul.org (Postfix) id D1ECF15E74F; Sat, 9 Nov 2002 16:51:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A7A5D15E766; Sat, 9 Nov 2002 16:51:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 1E68E15E74F for ; Sat, 9 Nov 2002 16:51:53 -0500 (EST) Received: from thor (nas-cbv-7-62-147-155-140.dial.proxad.net [62.147.155.140]) by postfix2-2.free.fr (Postfix) with ESMTP id AC9075F79D for ; Sat, 9 Nov 2002 22:51:51 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention Date: Sat, 9 Nov 2002 22:41:38 +0000 User-Agent: KMail/1.4.3 References: <1036530711.3376.39.camel@fsol> <200211092137.24307.cedric.bail@free.fr> <20021110222946.046c1d0b.nicolas.boulay@ifrance.com> In-Reply-To: <20021110222946.046c1d0b.nicolas.boulay@ifrance.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211092241.38062.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > You're right. But i thinl this case is a ill one. I hope nobody code like > that ! It's append and sometime it can be usefull. > So maybe the 20-80 rule apply. This case could not be optimised but the > common one could. The problem is that you couldn't make any different between a source of problem and a correct program that you could optimize. So sometime you will generate wrong code and a compiler can never generate wrong code because of an optimisation. Patching gcc with surch an algorithm will never be acceptable, because of regression risk ! If we don't find a solution to this problem, we must forget this idea ! Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Nov 9 15:41:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10W-00010s-00 for ; Sun, 10 Nov 2002 23:56:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:56:44 +0100 (CET) Received: (qmail 2122 invoked by uid 0); 9 Nov 2002 22:44:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 9 Nov 2002 22:44:51 -0000 Received: by moria.seul.org (Postfix) id 3C01415E74F; Sat, 9 Nov 2002 17:44:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E36C215E766; Sat, 9 Nov 2002 17:44:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a078.home.uni-hannover.de [130.75.232.78]) by moria.seul.org (Postfix) with ESMTP id BFCA715E74F for ; Sat, 9 Nov 2002 17:44:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA04985; Sat, 9 Nov 2002 15:41:30 +0100 Message-ID: <20021109154130.14362@thrai.stud.uni-hannover.de> Date: Sat, 9 Nov 2002 15:41:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New suggestion about call convention References: <1036530711.3376.39.camel@fsol> <1036628081.3192.18.camel@fsol> <20021107015920.15026@thrai.stud.uni-hannover.de> <200211091151.52968.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211091151.52968.cedric.bail@free.fr>; from cedric on Sat, Nov 09, 2002 at 11:51:52AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Nov 09, 2002 at 11:51:52AM +0000, cedric wrote: > > No problem, there is a solution for that. If A, B and C form a loop, > > you can put a `save-all' wrapper around one of them, and the loop will > > be broken. > > > The only thing that matters is the register set of the callee; if > > that set is empty, you can delete the (caller; callee) edge from the > > graph, the loop vanishes, and you can handle the rest like any other > > non-recursive function. Inserting a `save-all' wrapper by definition > > empties the register set, so... > > Well it's not so easy. What append if : > > A call B > B call C > C call an external function > This external function call A. This is easy, again. All external functions are required to have an empty `used register' set - that is, they will save registers on their own. This applies in the following cases: - the function resides in a(nother) shared library, or is called from there (inter-module call) - another function takes its address and passes it around. In this case, the address must point to a `save-all' wrapper, but the program is still allowed to use the `quick' entry point for direct calls. > You don't have any information about the external function, so you must save > all register before calling it (I really mean all, not only the one that used > by C, but the one that are used by B too, because B will certainly crash > them). You must save at only one place: At the `public' entry point of A that is used by the external function (because A is external from the external functions point of view). > So we must detect call back function, but that not so easy. Of course you have > pointer to function, it's easy to say that their are callback, but sometime > you give fixed name to callback, and in that case you can't detect them (With > some graphical toolkit, I remember that I used a "callback" to initialise the > interface before the interface call it. So it's not because a function is > call in your source code, that it isn't a callback). > > This is a very big problem of your algorithm. The only solution is to use a > call-graph to know who call each function and to link it with every > library... That won't help at all. Remember that a shared library may be replaced by a new version which may behave differently (*after* the program has been linked). Due to that, we will never be able to optimize register usage across the `border' of a shared library. Therefore, shared libraries have to be `isolated', and have to save registers. > In fact the problem is that you can take a decision only if you totally know > the world around your program ! That's a big problem. Therefore, the interface to `the world around' is clearly specified. And it looks exactly like what you would expect without any link time optimizations - that is, it will be compatible even with `dumb' linkers. In fact, link time register relocation (I guess I'll call it LTRR from now on) is an optional step. Legacy compilers will generate code that always saves registers, and will not provide optimization hints. LTRR-aware compilers provide hints and a corresponding `quick' entry point for each function. Dumb linkers will always use the `register-saved' entry point of a function - because that's all they can `see'. That way, full compatibility is maintained. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Sun Nov 10 13:53:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18B10m-00010s-00 for ; Sun, 10 Nov 2002 23:57:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 10 Nov 2002 23:57:00 +0100 (CET) Received: (qmail 9798 invoked by uid 0); 10 Nov 2002 12:53:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 10 Nov 2002 12:53:33 -0000 Received: by moria.seul.org (Postfix) id 4F5FC15E75E; Sun, 10 Nov 2002 07:53:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A29415E767; Sun, 10 Nov 2002 07:53:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14911.mail.yahoo.com (web14911.mail.yahoo.com [216.136.225.249]) by moria.seul.org (Postfix) with SMTP id 5EE7615E75E for ; Sun, 10 Nov 2002 07:53:31 -0500 (EST) Message-ID: <20021110125330.76866.qmail@web14911.mail.yahoo.com> Received: from [152.163.189.172] by web14911.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 13:53:30 CET Date: Sun, 10 Nov 2002 13:53:30 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: Re: [f-cpu] Comment on Manual 0.2.6 To: f-cpu@seul.org In-Reply-To: <200211082102.21982.cedric.bail@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Read the object and you have your answer :-P --- cedric a écrit : > Just a quick reply, did you speak about 0.2.6 or > 0.2.7 ? > > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Subscriber_Services78062@msn.com Wed Nov 13 15:47:40 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18C1YG-0004Hm-00 for ; Wed, 13 Nov 2002 18:43:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 13 Nov 2002 18:43:44 +0100 (CET) Received: (qmail 18623 invoked by uid 0); 13 Nov 2002 14:44:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 13 Nov 2002 14:44:30 -0000 Received: by moria.seul.org (Postfix) id C41DB15E7BE; Wed, 13 Nov 2002 09:44:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A2D4B15E8A8; Wed, 13 Nov 2002 09:44:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 5866D15E7BE for ; Wed, 13 Nov 2002 09:44:29 -0500 (EST) Received: from 200.207.190.137 (unknown [212.12.7.11]) by bettik.munge.net (Postfix) with SMTP id 869C94F773 for ; Wed, 13 Nov 2002 08:43:46 -0600 (CST) Received: from [41.237.71.37] by f64.law4.hotmail.com with NNFMP; Nov, 13 2002 8:46:23 AM -0200 Received: from [49.164.250.3] by rly-xw01.mx.aol.com with SMTP; Nov, 13 2002 7:34:26 AM +0300 Received: from [206.22.148.111] by smtp4.cyberec.com with NNFMP; Nov, 13 2002 6:46:37 AM -0200 Received: from 82.49.149.76 ([82.49.149.76]) by hd.regsoft.net with asmtp; Nov, 13 2002 5:29:20 AM +0600 From: WALL STREET BULLETIN…..46639 To: Subscriber@munge.net, Acct.#99050@munge.net Subject: [f-cpu] NEW STOCK PICK: PRCT - LAST PICK UP 150%....................................................................................................................................................................... eaf Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 13 Nov 2002 08:47:40 -0600 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-Priority: 1 Message-Id: <20021113144346.869C94F773@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

Did you miss out on NNCO, UP 233% IN JUST 2 DAYS?

Here's another pick - Another Short Play

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

qijeedmmkpnvjxjssdfaoturybovcrf ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From veronicap@aboutaustralia.com Fri Nov 15 19:17:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18D5fm-0000G3-01 for ; Sat, 16 Nov 2002 17:19:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 16 Nov 2002 17:19:54 +0100 (CET) Received: (qmail 22928 invoked by uid 0); 15 Nov 2002 18:45:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 15 Nov 2002 18:45:25 -0000 Received: by moria.seul.org (Postfix) id DDD4D15E721; Fri, 15 Nov 2002 13:45:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D02BE15E73A; Fri, 15 Nov 2002 13:45:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from marlborough.nxlkhost.com (marlborough.nxlkhost.com [207.155.248.65]) by moria.seul.org (Postfix) with ESMTP id 4408615E721 for ; Fri, 15 Nov 2002 13:45:23 -0500 (EST) Received: from backofc (w158.z064000079.sat-tx.dsl.cnc.net [64.0.79.158]) by marlborough.nxlkhost.com id NAA13609; Fri, 15 Nov 2002 13:12:04 -0500 (EST) [ConcentricHost SMTP Relay 1.15] Message-ID: <002401c28cd3$7cb01da0$9e4f0040@concentric.net> From: "Veronica Pearce" To: Subject: [f-cpu] Australian Chocolates - Linking Question Date: Fri, 15 Nov 2002 12:17:46 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C28CA1.033C4520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C28CA1.033C4520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable G'day, I found your website via a search on Altavista using the term "Chocolate = Club".=20 We operate an Australian Retail Store and Online Shop in the USA. We = sell authentic Australian Foods inclusive of many hard to find = Australian Chocolates. =20 I was wondering, if you found it appropriate, whether you could add a = link to our website from your website to promote Australian Chocolates = in the USA? If you are interested please see the link at the end of = this email for simple linking instructions. If you have received this email in error, I apologise*. Thankyou very much for your time and consideration, Kindest Regards, Veronica Pearce About Australia 123 Alamo Plaza San Antonio TX 78205 USA ph 210-2991077 fx 210-2991078 www.about-australia-shop.com Australian Food, Gifts & Souvenirs To add a link to our website please follow the simple instructions at: = http://www.about-australia-shop.com/linktous.htm * You are not on our Mailing List. This is a once-off email notice = based on a once-off search conducted on Altavisa. =20 ** If you would like to be added to our Mailing List simply reply to = this email with "PLEASE ADD" in the subject line and provide any other = details (name, address, etc) in the body of your email. ------=_NextPart_000_0021_01C28CA1.033C4520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
G'day,
 
I found your website via a search on Altavista using = the term=20 "Chocolate Club". 
 
We operate an Australian Retail Store and = Online Shop in=20 the USA.  We sell authentic Australian Foods inclusive of many hard = to find=20 Australian Chocolates. 
 
I was wondering, if you found it appropriate, = whether you=20 could add a link to our website from your website to promote Australian=20 Chocolates in the USA?  If you are interested please see the link = at the=20 end of this email for simple linking instructions.
 
If you have received this email in error, I apologise*.
 
Thankyou very much for your time and=20 consideration,
 
Kindest Regards,
 
Veronica Pearce
About Australia
123 Alamo Plaza
San Antonio  TX  78205 USA
ph 210-2991077
fx 210-2991078
www.about-australia-shop.com=
Australian Food, Gifts & Souvenirs
 
To add a link to our website please = follow the=20 simple instructions at: http://www.abou= t-australia-shop.com/linktous.htm
 
* You are not on our Mailing List.  This is a once-off email = notice=20 based on a once-off search conducted on Altavisa. 
 
** If you would like to be added to our Mailing List simply reply = to this=20 email with "PLEASE ADD" in the subject line and provide any = other details=20 (name, address, etc) in the body of=20 your email.
------=_NextPart_000_0021_01C28CA1.033C4520-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Nov 15 23:29:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18D5fs-0000G3-01 for ; Sat, 16 Nov 2002 17:20:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 16 Nov 2002 17:20:00 +0100 (CET) Received: (qmail 31563 invoked by uid 0); 15 Nov 2002 21:40:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 15 Nov 2002 21:40:28 -0000 Received: by moria.seul.org (Postfix) id CD3B415E8B5; Fri, 15 Nov 2002 16:40:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76ED515E8C3; Fri, 15 Nov 2002 16:40:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by moria.seul.org (Postfix) with ESMTP id 333F615E72F for ; Fri, 15 Nov 2002 16:40:23 -0500 (EST) Received: from thor (nas-cbv-7-62-147-152-114.dial.proxad.net [62.147.152.114]) by postfix2-2.free.fr (Postfix) with ESMTP id D1EF35F718 for ; Fri, 15 Nov 2002 22:40:02 +0100 (CET) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] Manual 0.2.7b Date: Fri, 15 Nov 2002 22:29:00 +0000 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211152229.00525.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi everyone, I put a new release in the unstable section ( http://f-cpu.seul.org/cedric/unstable ). The changelog is small, only spelling correction suggested by Just an Illusion and Karl-Heinz Eischer. So if someone have some time to read this new release. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mohamed.kilani@m4x.org Sat Nov 16 08:55:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18D5gB-0000G3-00 for ; Sat, 16 Nov 2002 17:20:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 16 Nov 2002 17:20:19 +0100 (CET) Received: (qmail 8276 invoked by uid 0); 16 Nov 2002 07:55:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 16 Nov 2002 07:55:28 -0000 Received: by moria.seul.org (Postfix) id 4CC6715E73A; Sat, 16 Nov 2002 02:55:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 261C015E742; Sat, 16 Nov 2002 02:55:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by moria.seul.org (Postfix) with ESMTP id 9FAD015E73A for ; Sat, 16 Nov 2002 02:55:26 -0500 (EST) Received: (qmail 8601 invoked from network); 16 Nov 2002 07:55:43 -0000 Received: from unknown (HELO frankiz.org) ([66.93.129.139]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Nov 2002 07:55:43 -0000 Received: from m4x.org (thisismyplanet [192.168.1.4]) by frankiz.org (Postfix) with ESMTP id B0B76CF for ; Sat, 16 Nov 2002 00:58:01 -0800 (PST) Message-ID: <3DD5FA01.8050009@m4x.org> Date: Fri, 15 Nov 2002 23:55:45 -0800 From: Mohamed Ali Kilani User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.7b References: <200211152229.00525.cedric.bail@free.fr> In-Reply-To: <200211152229.00525.cedric.bail@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N cedric, I am taking some time off these next couple of weeks. I will probably have some time to go through the whole thing and give you some feed back. Dali cedric wrote: > Hi everyone, > > I put a new release in the unstable section ( > http://f-cpu.seul.org/cedric/unstable ). The changelog is small, only > spelling correction suggested by Just an Illusion and Karl-Heinz Eischer. > So if someone have some time to read this new release. > > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! > Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 16 17:58:10 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18D6fo-0001K1-00 for ; Sat, 16 Nov 2002 18:24:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 16 Nov 2002 18:24:00 +0100 (CET) Received: (qmail 2965 invoked by uid 0); 16 Nov 2002 16:08:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 16 Nov 2002 16:08:51 -0000 Received: by moria.seul.org (Postfix) id 9A07815E741; Sat, 16 Nov 2002 11:08:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 711D415E744; Sat, 16 Nov 2002 11:08:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by moria.seul.org (Postfix) with ESMTP id F3D9215E741 for ; Sat, 16 Nov 2002 11:08:49 -0500 (EST) Received: from thor (nas-cbv-11-62-147-116-187.dial.proxad.net [62.147.116.187]) by postfix3-2.free.fr (Postfix) with ESMTP id A9DD517E62 for ; Sat, 16 Nov 2002 17:08:48 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.7b Date: Sat, 16 Nov 2002 16:58:10 +0000 User-Agent: KMail/1.4.3 References: <200211152229.00525.cedric.bail@free.fr> <3DD5FA01.8050009@m4x.org> In-Reply-To: <3DD5FA01.8050009@m4x.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211161658.10111.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > cedric, > I am taking some time off these next couple of weeks. I will probably > have some time to go through the whole thing and give you some feed back. That's a good news, but I forgot to update bitrev instruction with Michael RIEPE recommendation. So, look to 0.2.7c, sorry. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sales@smoking.com.net Thu Nov 14 17:05:43 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18DKwD-0002hp-00 for ; Sun, 17 Nov 2002 09:37:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 17 Nov 2002 09:37:53 +0100 (CET) Received: (qmail 6215 invoked by uid 0); 17 Nov 2002 05:43:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 17 Nov 2002 05:43:52 -0000 Received: by moria.seul.org (Postfix) id C394015E741; Sun, 17 Nov 2002 00:43:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B013715E747; Sun, 17 Nov 2002 00:43:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from linux.local (unknown [213.9.248.180]) by moria.seul.org (Postfix) with SMTP id 5158715E741 for ; Sun, 17 Nov 2002 00:43:50 -0500 (EST) Received: (qmail 2336 invoked from network); 14 Nov 2002 17:07:04 -0000 Received: from unknown (HELO admin) (192.168.0.1) by linux.local with SMTP; 14 Nov 2002 17:07:04 -0000 From: "Sales Department" Subject: [f-cpu] Discounted Cigarettes To: f-cpu@seul.org Date: Thu, 14 Nov 2002 17:05:43 +0100 X-Priority: 3 X-Library: Indy 8.0.25 Message-Id: <20021117054350.5158715E741@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Dear Sir or Madam In the past you have requested information on discounted products. If you are not a smoker, and find this email offensive, then we sincerely apologise. We will be only too happy to take you off our database. If you are a smoker, however, you are probably fed up with paying high prices for your cigarettes and tobacco. Take a look at what we can do for you at http://www.britishsmokers.com/?S=15&ID=2&E=4425542 We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 40 pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing. Why pay more? If you would rather not hear from us any more, this link will ensure that you are not bothered again. http://www.britishsmokers.com/off/index.php Yours faithfully. British Smokers http://www.britishsmokers.com/?S=15&ID=2&E=4425542 w2y14425542563 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Nov 18 08:46:26 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dm3L-0002uE-00 for ; Mon, 18 Nov 2002 14:35:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 14:35:03 +0100 (CET) Received: (qmail 23803 invoked by uid 0); 18 Nov 2002 07:46:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 18 Nov 2002 07:46:28 -0000 Received: by moria.seul.org (Postfix) id 8CEED15E72C; Mon, 18 Nov 2002 02:46:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 59B3315E756; Mon, 18 Nov 2002 02:46:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14901.mail.yahoo.com (web14901.mail.yahoo.com [216.136.225.53]) by moria.seul.org (Postfix) with SMTP id B825615E72C for ; Mon, 18 Nov 2002 02:46:26 -0500 (EST) Message-ID: <20021118074626.7251.qmail@web14901.mail.yahoo.com> Received: from [132.166.133.152] by web14901.mail.yahoo.com via HTTP; Mon, 18 Nov 2002 08:46:26 CET Date: Mon, 18 Nov 2002 08:46:26 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: Re: [f-cpu] Manual 0.2.7b To: f-cpu@seul.org In-Reply-To: <200211161658.10111.cedric.bail@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I have a little question for you. Why have you change the history date presentation on this released ? Before the version 0.2.7x, the date was MM/DD/YYYY, and now it is DD/MM/YYYY. This is little confusing. Just an Illusion --- cedric a écrit : > > cedric, > > > I am taking some time off these next couple of > weeks. I will probably > > have some time to go through the whole thing and > give you some feed back. > > That's a good news, but I forgot to update bitrev > instruction with Michael > RIEPE recommendation. So, look to 0.2.7c, sorry. > > Cedric > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 18 19:42:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dqvy-0006EE-00 for ; Mon, 18 Nov 2002 19:47:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 19:47:46 +0100 (CET) Received: (qmail 1894 invoked by uid 0); 18 Nov 2002 17:52:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 18 Nov 2002 17:52:52 -0000 Received: by moria.seul.org (Postfix) id D188B15E75D; Mon, 18 Nov 2002 12:52:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A4DF115E8AE; Mon, 18 Nov 2002 12:52:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp3.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 51A3A15E75D for ; Mon, 18 Nov 2002 12:52:51 -0500 (EST) Received: from thor (132.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.132]) by smtp3.9tel.net (Postfix) with ESMTP id 7CF2B5BFFE for ; Mon, 18 Nov 2002 18:52:49 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.7b Date: Mon, 18 Nov 2002 18:42:01 +0000 User-Agent: KMail/1.4.3 References: <20021118074626.7251.qmail@web14901.mail.yahoo.com> In-Reply-To: <20021118074626.7251.qmail@web14901.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211181842.01432.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > I have a little question for you. > Why have you change the history date presentation on > this released ? It's an error. Stupid french convension ! (Nice to know that somebody read it ;-) > Before the version 0.2.7x, the date was MM/DD/YYYY, > and now it is DD/MM/YYYY. This is little confusing. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 18 20:15:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dqvz-0006EE-00 for ; Mon, 18 Nov 2002 19:47:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 19:47:47 +0100 (CET) Received: (qmail 2686 invoked by uid 0); 18 Nov 2002 18:26:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 18 Nov 2002 18:26:46 -0000 Received: by moria.seul.org (Postfix) id 3ECC415E760; Mon, 18 Nov 2002 13:26:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 216F115E8B5; Mon, 18 Nov 2002 13:26:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp4.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id D081315E760 for ; Mon, 18 Nov 2002 13:26:43 -0500 (EST) Received: from thor (132.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.132]) by smtp4.9tel.net (Postfix) with ESMTP id 9A5255BFCF for ; Mon, 18 Nov 2002 19:26:42 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric Subject: [f-cpu] Fwd: announce: VHDL front-end for GCC Date: Mon, 18 Nov 2002 19:15:54 +0000 User-Agent: KMail/1.4.3 To: f-cpu@seul.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211181915.54119.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Read on the GCC mailing-list. It's a good news I think. Cedric ---------- Message transmis ---------- Subject: announce: VHDL front-end for GCC Date: Mon, 18 Nov 2002 12:26:24 +0100 From: Tristan Gingold To: gcc@gcc.gnu.org I am happy to introduce GHDL. GHDL is a GCC front-end for the VHDL (IEEE 1076) language, an hardware design language. Currently, GHDL implements most of VHDL-1987 and some features of VHDL-1993. It is mature enough to compile and run some complex design (such as a DLX processor and leon1, a SPARCv7 processor) GHDL has been developped on a GNU/Linux x86 system, and only this configuration has been tested (porting to other processor or system should not be an hard task, but there are system dependent files in the run time). GHDL is written in Ada95 (using GNAT) and relies on agcc, an Ada binding for GCC. It also includes a run-time library (written in Ada), named grt. The front-end and the library are both distributed under the GPL licence. For sources, binary tarballs, or for more information, go to http://ghdl.free.fr Tristan Gingold. ------------------------------------------------------- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Nov 18 19:32:06 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dur7-0000Xq-00 for ; Mon, 18 Nov 2002 23:59:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 23:59:01 +0100 (CET) Received: (qmail 26283 invoked by uid 0); 18 Nov 2002 18:39:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 18 Nov 2002 18:39:29 -0000 Received: by moria.seul.org (Postfix) id D360D15E8BF; Mon, 18 Nov 2002 13:39:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA4A715E8C3; Mon, 18 Nov 2002 13:39:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (mallaury.noc.nerim.net [62.4.17.82]) by moria.seul.org (Postfix) with ESMTP id 2356B15E8BF for ; Mon, 18 Nov 2002 13:39:15 -0500 (EST) Received: from aboukir-102-2-46.net1.nerim.net (aboukir-102-2-46.net1.nerim.net [213.41.185.46]) by mallaury.noc.nerim.net (Postfix) with ESMTP id A46F462D38 for ; Mon, 18 Nov 2002 19:39:11 +0100 (CET) Subject: Re: [f-cpu] Manual 0.2.7b From: Antoine To: f-cpu@seul.org In-Reply-To: <200211181842.01432.cedric.bail@free.fr> References: <20021118074626.7251.qmail@web14901.mail.yahoo.com> <200211181842.01432.cedric.bail@free.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 18 Nov 2002 19:32:06 +0100 Message-Id: <1037644327.3144.1.camel@fsol> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > I have a little question for you. > > Why have you change the history date presentation on > > this released ? > > It's an error. Stupid french convension ! (Nice to know that somebody read it > ;-) > > > Before the version 0.2.7x, the date was MM/DD/YYYY, > > and now it is DD/MM/YYYY. This is little confusing. Not that stupid, in my opinion. DD/MM/YYYY is the most wide-spread convention, isn't it ? I think only Americans use the other one (which is also less logical). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Mon Nov 18 19:51:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dur7-0000Xq-01 for ; Mon, 18 Nov 2002 23:59:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 23:59:01 +0100 (CET) Received: (qmail 21128 invoked by uid 0); 18 Nov 2002 18:51:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 18 Nov 2002 18:51:35 -0000 Received: by moria.seul.org (Postfix) id 40F3315E8B5; Mon, 18 Nov 2002 13:51:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DB4C15E8C2; Mon, 18 Nov 2002 13:51:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id EA09B15E8B6; Mon, 18 Nov 2002 13:51:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id E6DC115E8B5 for ; Mon, 18 Nov 2002 13:51:33 -0500 (EST) Date: Mon, 18 Nov 2002 13:51:33 -0500 (EST) From: Graham Seaman X-X-Sender: graham@moria To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.7b In-Reply-To: <1037644327.3144.1.camel@fsol> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On 18 Nov 2002, Antoine wrote: > Not that stupid, in my opinion. DD/MM/YYYY is the most > wide-spread convention, isn't it ? I think only Americans > use the other one (which is also less logical). > No, way more logical IMO - it lets you sort documents in date order. Anyway isnt the 2002-11-18 format an ISO standard? Graham ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 18 21:24:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Dur9-0000Xq-00 for ; Mon, 18 Nov 2002 23:59:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 23:59:03 +0100 (CET) Received: (qmail 13801 invoked by uid 0); 18 Nov 2002 20:11:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 18 Nov 2002 20:11:28 -0000 Received: by moria.seul.org (Postfix) id 8911A15E756; Mon, 18 Nov 2002 15:11:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7EF6615E760; Mon, 18 Nov 2002 15:11:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 3FCED15E756 for ; Mon, 18 Nov 2002 15:11:26 -0500 (EST) Received: from f-cpu.org (unknown [213.44.93.29]) by relay-4v.club-internet.fr (Postfix) with ESMTP id E1C1616CA for ; Mon, 18 Nov 2002 21:11:23 +0100 (CET) Message-ID: <3DD94C7C.3000702@f-cpu.org> Date: Mon, 18 Nov 2002 21:24:28 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Manual 0.2.7b References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Graham Seaman wrote: >On 18 Nov 2002, Antoine wrote: > >>Not that stupid, in my opinion. DD/MM/YYYY is the most >>wide-spread convention, isn't it ? I think only Americans >>use the other one (which is also less logical). >> >No, way more logical IMO - it lets you sort documents in date order. >Anyway isnt the 2002-11-18 format an ISO standard? > > whatever it is, it's certainly the best representation when it comes to sort the files. have a look at the f-cpu.seul.org/new directory if you are not convinced.... should we decide to use only one date format ? >Graham > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 18 21:24:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18DurA-0000Xq-00 for ; Mon, 18 Nov 2002 23:59:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Nov 2002 23:59:04 +0100 (CET) Received: (qmail 323 invoked by uid 0); 18 Nov 2002 20:11:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Nov 2002 20:11:29 -0000 Received: by moria.seul.org (Postfix) id D095215E75D; Mon, 18 Nov 2002 15:11:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABD4815E8BF; Mon, 18 Nov 2002 15:11:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 4D16A15E75D for ; Mon, 18 Nov 2002 15:11:27 -0500 (EST) Received: from f-cpu.org (unknown [213.44.93.29]) by relay-2v.club-internet.fr (Postfix) with ESMTP id CF3EB1716; Mon, 18 Nov 2002 21:11:25 +0100 (CET) Message-ID: <3DD94C81.2080401@f-cpu.org> Date: Mon, 18 Nov 2002 21:24:33 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Fwd: announce: VHDL front-end for GCC References: <200211181915.54119.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hello, cedric wrote: >Read on the GCC mailing-list. It's a good news I think. > it's A BIG UNDERSTATEMENT !!! It's one of the best news ever in the project. If it was ready before (and even in early beta) it would have saved some work. However it is a good thing to continue the compliance tests with other commercial tools. I also hope that it can run on other architectures and on SMP systems. i just got my hands on an unused Digital^WCompaq^WHewlett Packard DS20 with a huge amount of RAM and two 500MHz EV67 CPUs... i would be that it simply kicks ass. And it has a RedHat already installed but i don't know how to boot it yet :-D .... >Cedric > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Nov 19 00:29:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18DyUh-00033z-00 for ; Tue, 19 Nov 2002 03:52:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 19 Nov 2002 03:52:07 +0100 (CET) Received: (qmail 16340 invoked by uid 0); 18 Nov 2002 23:29:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 18 Nov 2002 23:29:35 -0000 Received: by moria.seul.org (Postfix) id 5BD1515E757; Mon, 18 Nov 2002 18:29:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5288315E760; Mon, 18 Nov 2002 18:29:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a204.home.uni-hannover.de [130.75.232.204]) by moria.seul.org (Postfix) with ESMTP id ED13515E757 for ; Mon, 18 Nov 2002 18:29:32 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02342; Tue, 19 Nov 2002 00:29:36 +0100 Message-ID: <20021119002936.00894@thrai.stud.uni-hannover.de> Date: Tue, 19 Nov 2002 00:29:36 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Fwd: announce: VHDL front-end for GCC References: <200211181915.54119.cedric.bail@free.fr> <3DD94C81.2080401@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3DD94C81.2080401@f-cpu.org>; from Yann Guidon on Mon, Nov 18, 2002 at 09:24:33PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 18, 2002 at 09:24:33PM +0100, Yann Guidon wrote: > hello, > > cedric wrote: > > >Read on the GCC mailing-list. It's a good news I think. > > > > it's A BIG UNDERSTATEMENT !!! > It's one of the best news ever in the project. Except the part where it says "written in Ada". > If it was ready before (and even in early beta) > it would have saved some work. However it > is a good thing to continue the compliance > tests with other commercial tools. Of course. In fact, GHDL will first have to prove its usefulness and correctness before I use it as the primary tool. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From StopForeclosure98532@usa.net Tue Nov 19 08:46:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EHm4-0000G4-00 for ; Wed, 20 Nov 2002 00:27:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 00:27:20 +0100 (CET) Received: (qmail 2005 invoked by uid 0); 19 Nov 2002 07:41:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 19 Nov 2002 07:41:45 -0000 Received: by moria.seul.org (Postfix) id 3EFC315E780; Tue, 19 Nov 2002 02:41:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A0E015E8C1; Tue, 19 Nov 2002 02:41:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id C797A15E780 for ; Tue, 19 Nov 2002 02:41:43 -0500 (EST) Received: from 63.117.75.126 (unknown [209.99.226.105]) by bettik.munge.net (Postfix) with SMTP id 93BC04F7D0 for ; Tue, 19 Nov 2002 01:40:48 -0600 (CST) Received: from [138.156.251.163] by da001d2020.lax-ca.osd.concentric.net with local; Nov, 19 2002 1:26:39 AM +0700 Received: from [190.198.219.49] by a231242.upc-a.chello.nl with QMQP; Nov, 19 2002 12:37:47 AM +0600 Received: from [159.218.252.32] by n7.groups.yahoo.com with SMTP; Nov, 18 2002 11:37:47 PM -0000 From: StopForeclosure347 To: HOMEOWNER97194@munge.net Subject: [f-cpu] STOP YOUR FORECLOSURE.............................................................................................................................................................................................. yngol Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 19 Nov 2002 01:46:01 -0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 1 Message-Id: <20021119074048.93BC04F7D0@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

CLICK HERE

 

Unsubscribe click here

dopnpsddsrrllkmaiwvfp ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Tue Nov 19 10:05:37 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EHm7-0000G4-00 for ; Wed, 20 Nov 2002 00:27:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 00:27:23 +0100 (CET) Received: (qmail 15446 invoked by uid 0); 19 Nov 2002 09:05:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Nov 2002 09:05:40 -0000 Received: by moria.seul.org (Postfix) id 398B715E780; Tue, 19 Nov 2002 04:05:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 02ACF15E8B6; Tue, 19 Nov 2002 04:05:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14905.mail.yahoo.com (web14905.mail.yahoo.com [216.136.225.57]) by moria.seul.org (Postfix) with SMTP id 5BA4815E780 for ; Tue, 19 Nov 2002 04:05:38 -0500 (EST) Message-ID: <20021119090537.14027.qmail@web14905.mail.yahoo.com> Received: from [132.166.133.152] by web14905.mail.yahoo.com via HTTP; Tue, 19 Nov 2002 10:05:37 CET Date: Tue, 19 Nov 2002 10:05:37 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: Re: [f-cpu] Manual 0.2.7b To: f-cpu@seul.org In-Reply-To: <3DD94C7C.3000702@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I am agree with Graham, the best format is certainly YYYY/MM/DD (or YYYY-MM-DD). It help in case of sort. At your question, I think than is better for documentation than date have always the same format. It can be usefull, to use this format into the code files too. One of the advantage is than it give an easy way to give a version number to the file : the date of submission. A last remarks about history section (for this point you have two different school): * currently, the history order is older modifications to newer. I think is better if the newer modifications are given in first position, because the reader can immediatly determine, what is new and when. The only problem is than the history part couldn't be update only by append a new line at the end of the list. * It is difficult to determine the list of new function since the last 'official' released of the manual. I think than we must add the "release" submission date with the version number like : ... 2002-11-16 Manual version 0.2.7c submission or (and perhaps better :-?) add in the history only the release submission date, following by the list of modifications (dated or not) since the previous released, like : ... 2002-11-16 Manual version 0.2.7c * Color modification (2002-08-27) * Add new shift and rot, and clean ISA options (2002-09-08) * Add widen (2002-09-12) * Add madd, msub, mschg, cshift (2002-09-14) ... SeeYa, Just an Illusion --- Yann Guidon a écrit : > hi, > > Graham Seaman wrote: > > >On 18 Nov 2002, Antoine wrote: > > > >>Not that stupid, in my opinion. DD/MM/YYYY is the > most > >>wide-spread convention, isn't it ? I think only > Americans > >>use the other one (which is also less logical). > >> > >No, way more logical IMO - it lets you sort > documents in date order. > >Anyway isnt the 2002-11-18 format an ISO standard? > > > > > whatever it is, it's certainly the best > representation when it comes to > sort the files. > have a look at the f-cpu.seul.org/new directory if > you are not convinced.... > > should we decide to use only one date format ? > > >Graham > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 19 14:54:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EHm7-0000G4-01 for ; Wed, 20 Nov 2002 00:27:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 00:27:23 +0100 (CET) Received: (qmail 8334 invoked by uid 0); 19 Nov 2002 09:54:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 19 Nov 2002 09:54:39 -0000 Received: by moria.seul.org (Postfix) id 6640915E780; Tue, 19 Nov 2002 04:54:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3CAD515E8B6; Tue, 19 Nov 2002 04:54:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 8E76715E780 for ; Tue, 19 Nov 2002 04:54:37 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-2v.club-internet.fr (Postfix) with SMTP id A6B7F16FF for ; Tue, 19 Nov 2002 10:54:36 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Fwd: announce: VHDL front-end for GCC Date: Tue, 19 Nov 2002 10:54:36 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >De: Michael Riepe > >On Mon, Nov 18, 2002 at 09:24:33PM +0100, Yann Guidon wrote: >> hello, >> = >> cedric wrote: >> = >> >Read on the GCC mailing-list. It's a good news I think. >> >> = >> it's A BIG UNDERSTATEMENT =21=21=21 >> It's one of the best news ever in the project. > >Except the part where it says =22written in Ada=22. troll detected >> If it was ready before (and even in early beta) >> it would have saved some work. However it >> is a good thing to continue the compliance >> tests with other commercial tools. > >Of course. In fact, GHDL will first have to prove its usefulness and >correctness before I use it as the primary tool. sure but we can give it a chance. I simply hope that it will hold the promises that Savant and FreeHDL made... > Michael =22Tired=22 Riepe YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 19 22:12:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EHmK-0000G4-00 for ; Wed, 20 Nov 2002 00:27:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 00:27:36 +0100 (CET) Received: (qmail 12055 invoked by uid 0); 19 Nov 2002 17:12:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 19 Nov 2002 17:12:14 -0000 Received: by moria.seul.org (Postfix) id 5D0A215E751; Tue, 19 Nov 2002 12:12:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F22115E780; Tue, 19 Nov 2002 12:12:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id E8DCB15E751 for ; Tue, 19 Nov 2002 12:12:11 -0500 (EST) Received: from club-internet.fr (flashmail-4v.cs.clubint.net [172.16.0.154]) by relay-3v.club-internet.fr (Postfix) with SMTP id A893516D6; Tue, 19 Nov 2002 18:11:58 +0100 (CET) Received: from [//212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Cc: debian-devel@lists.debian.org Subject: [f-cpu] the ghdl bomb Date: Tue, 19 Nov 2002 18:12:11 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, Even though it has not been tested and validated by the F-CPU team, the announcement of GHDL is a very good news. Usually, =22software people=22 don't like VHDL because =22it is slow=22 and a C version of the source code has been started. This increases the size of the project because two versions of the sources must be written, maintained and checked against each others. The a= vailability of a native GCC support reduces the need of a C version of the code and reduces the coding, testing and regression check efforts. This also provides a high speed simulation engine that doesn't require contributors to use extremely expensive proprietary software for the long runs. Finally, it becomes possible to =22execute=22 F-CPU as a (mostly) standalone program. http://ghdl.free.fr/ghdl/ it's a quick read and i am still amazed =21 If this project existed 2 years ago, a lot of efforts could have been spared (but they are worth anyway). i did not try to run it yet but it's highly promising : - it's free software (though some runtime libraries are not completely GPL, they are copylefted or public domain) - it directly uses GCC -> no worry about intermediate representations or naughty C things (unlike Savant/FreeHDL) - Emphasis on VHDL LRM compliance (on sync with F-CPU) - Has already compiled LEON and DLX so the F-CPU core should require minimal changes - Communication is easy (Tristan lives near Paris, as several F-CPU contributors do) - KISS (Keep It Simple and Sexy ;-P) - and a few i forgot The first thing that can be done is to check how the two project coincide and how GHDL compiles the F-CPU VHDL code. GHDL needs a few minor feature boosts to compile the testbenches but the core itself should be ok. Support for GHDL is only a minimal change to the existing, portable F-CPU sources (if any). Now, support for parallel (multi-CPU) computers is probably not working (unlike Savant) but i'm sure it's only a matter of time :-P Feature enhancements can be done by other people, if they are interested or feel concerned. I copy this mail to the Debian list because they once asked how they could help. Now, this is a good way to start :-) I encourage any Debian developer to contact the GHDL author and propose his help. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Nov 20 19:36:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EHmT-0000G4-01 for ; Wed, 20 Nov 2002 00:27:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 00:27:45 +0100 (CET) Received: (qmail 430 invoked by uid 0); 19 Nov 2002 18:54:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Nov 2002 18:54:45 -0000 Received: by moria.seul.org (Postfix) id AC1D415E73A; Tue, 19 Nov 2002 13:54:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 83E2E15E781; Tue, 19 Nov 2002 13:54:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id B1D0515E73A for ; Tue, 19 Nov 2002 13:54:42 -0500 (EST) Received: from Biathlon (vlt4-77.n.club-internet.fr [194.158.109.77]) by relay-4v.club-internet.fr (Postfix) with SMTP id 8E4EE16EB for ; Tue, 19 Nov 2002 19:54:40 +0100 (CET) Date: Wed, 20 Nov 2002 19:36:48 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] the ghdl bomb Message-Id: <20021120193648.2f40f18d.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 19 Nov 2002 18:12:11 CET whygee@club-internet.fr wrote: > Hello, > > Even though it has not been tested and validated by the > F-CPU team, the announcement of GHDL is a very good news. > > Usually, "software people" don't like VHDL because "it is slow" > and a C version of the source code has been started. This > increases the size of the project because two versions of the > sources must be written, maintained and checked against each others. The availability of a native GCC support reduces the > need of a C version of the code and reduces the coding, testing > and regression check efforts. This also provides a high > speed simulation engine that doesn't require contributors high speed !!!!! It's a joke ? you will have a simulation time around 1:100000 and you want to debug program ! That's not an emulator ! We could juste test few 10 ms (15 min) of test not much ! Check leon, it vhdl exist but an emulator existe too ! > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! > Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Nov 20 15:39:32 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EUEr-0000G2-01 for ; Wed, 20 Nov 2002 13:45:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 13:45:53 +0100 (CET) Received: (qmail 13323 invoked by uid 0); 20 Nov 2002 10:39:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 20 Nov 2002 10:39:35 -0000 Received: by moria.seul.org (Postfix) id 53E5B15E788; Wed, 20 Nov 2002 05:39:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2291415E78D; Wed, 20 Nov 2002 05:39:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CCCF015E788 for ; Wed, 20 Nov 2002 05:39:33 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-3v.club-internet.fr (Postfix) with SMTP id 38BAE16D8 for ; Wed, 20 Nov 2002 11:39:21 +0100 (CET) Received: from [//212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] the ghdl bomb Date: Wed, 20 Nov 2002 11:39:32 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N heck =21 the old simulation/emulation trouble pops up again ..... >De: nico > >> Hello, >> = >> Usually, =22software people=22 don't like VHDL because =22it is slow=22 >> and a C version of the source code has been started. This >> increases the size of the project because two versions of the >> sources must be written, maintained and checked against each others. Th= e availability of a native GCC support reduces the >> need of a C version of the code and reduces the coding, testing >> and regression check efforts. This also provides a high >> speed simulation engine that doesn't require contributors > >high speed =21=21=21=21=21 It's a joke ? =22Everything is relative=22 (Einstein) and it's certainly going to be faster than vanilla or Simili. And you forgot the main point : it's free. >you will have a simulation time around 1:100000 > and you want to debug program =21 At least if the program fails, we can know where the RTL model fails. And before giving numbers, one has to measure it.... >That's not an emulator =21 We could juste test few 10 ms (15 min) of test= not much =21 > >Check leon, it vhdl exist but an emulator existe too =21 The problem with an =22emulator=22 is that it completely skips all the RTL level and dirty hacks are necessary to make it behave the same way. Sure it's =22fast=22 (depending on the complexity of the model and architecture) but a lot of efforts must be spent to keep the simulator and the emulator in synch. And this puts pressure on the development. Now, tell me who has ever written a F-CPU program that has a longer simulation time than a few seconds. The longer program i know is the RC5 client from C=E9dric. Finally, if you don't want to use GHDL, you're not forced. >> YG YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Nov 21 19:03:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EaF2-0004Td-00 for ; Wed, 20 Nov 2002 20:10:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 20:10:28 +0100 (CET) Received: (qmail 19788 invoked by uid 0); 20 Nov 2002 18:23:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 20 Nov 2002 18:23:41 -0000 Received: by moria.seul.org (Postfix) id 2B44315E78C; Wed, 20 Nov 2002 13:23:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0BEE515E78F; Wed, 20 Nov 2002 13:23:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id BE6CD15E78C for ; Wed, 20 Nov 2002 13:23:39 -0500 (EST) Received: from Biathlon (vlt6-140.n.club-internet.fr [194.158.119.140]) by relay-5v.club-internet.fr (Postfix) with SMTP id 680981710 for ; Wed, 20 Nov 2002 19:23:42 +0100 (CET) Date: Thu, 21 Nov 2002 19:03:46 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] the ghdl bomb Message-Id: <20021121190346.736cbc76.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 20 Nov 2002 11:39:32 CET whygee@club-internet.fr wrote: > heck ! the old simulation/emulation trouble > pops up again ..... > > >De: nico > > > >> Hello, > >> > >> Usually, "software people" don't like VHDL because "it is slow" > >> and a C version of the source code has been started. This > >> increases the size of the project because two versions of the > >> sources must be written, maintained and checked against each others. The availability of a native GCC support reduces the > >> need of a C version of the code and reduces the coding, testing > >> and regression check efforts. This also provides a high > >> speed simulation engine that doesn't require contributors > > > >high speed !!!!! It's a joke ? > > "Everything is relative" (Einstein) But not this sentence. > and it's certainly going to be faster than > vanilla or Simili. And you forgot the main > point : it's free. > Yep but not fast enought to develop program. > >you will have a simulation time around 1:100000 > > and you want to debug program ! > At least if the program fails, we can know where the > RTL model fails. And before giving numbers, one > has to measure it.... > That's not really the point. Emulator are for developping software not debugging hardware. Cedric wanted to develop a "model" to validate the architectural point. SystemC or other high level language are design to do so. Even C (mostly C in fact) to check algorythme. > >That's not an emulator ! We could juste test few 10 ms (15 min) of test not much ! > > > >Check leon, it vhdl exist but an emulator existe too ! > > The problem with an "emulator" is that it completely > skips all the RTL level and dirty hacks are necessary > to make it behave the same way. Sure it's "fast" (depending No. > on the complexity of the model and architecture) but a lot > of efforts must be spent to keep the simulator and the > emulator in synch. And this puts pressure on the development. Sur, you have twice the work but emulator should be far simple. > > Now, tell me who has ever written a F-CPU program that > has a longer simulation time than a few seconds. Have you ever run a few second rtl simulation run ? How long it will take to your opinion ? > The longer program i know is the RC5 client from Cédric. > > Finally, if you don't want to use GHDL, you're not forced. fcpu will be written in VHDL to be synthetise. So GHDL could be used. But he only replace simili or freehdl or ... nicO > > >> YG > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! > Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Wed Nov 20 19:37:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18EaF4-0004Td-00 for ; Wed, 20 Nov 2002 20:10:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Nov 2002 20:10:30 +0100 (CET) Received: (qmail 9724 invoked by uid 0); 20 Nov 2002 18:38:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 20 Nov 2002 18:38:27 -0000 Received: by moria.seul.org (Postfix) id 48DC015E78C; Wed, 20 Nov 2002 13:38:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1846815E78F; Wed, 20 Nov 2002 13:38:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from hell.mpoli.fi (hell.mpoli.fi [62.236.132.10]) by moria.seul.org (Postfix) with ESMTP id 2ED4A15E78C for ; Wed, 20 Nov 2002 13:38:25 -0500 (EST) Received: from hell.mpoli.fi (hell.mpoli.fi [127.0.0.1]) by hell.mpoli.fi (8.12.5/8.12.5) with ESMTP id gAKIb1XI009840 for ; Wed, 20 Nov 2002 20:37:01 +0200 Received: from localhost (embo@localhost) by hell.mpoli.fi (8.12.5/8.12.5/Submit) with ESMTP id gAKIb1Bp030473 for ; Wed, 20 Nov 2002 20:37:01 +0200 Date: Wed, 20 Nov 2002 20:37:00 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: Re: [f-cpu] the ghdl bomb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 20 Nov 2002 whygee@club-internet.fr wrote: > >you will have a simulation time around 1:100000 > > and you want to debug program ! > At least if the program fails, we can know where the > RTL model fails. And before giving numbers, one > has to measure it.... Usually what I use is behavioral- and RTL-model running at the same time. Then just generate huge amount of input data and compare the two "designs" on the output. Of course in real life the checking needs much more visibility. One problem is to generate huge amounts of pseudorandom but sane command stream. There are solutions for that, OpenVERA (only spec is open) verification language for example has nice "stream generation" framework where the language can be described with BNF. > The problem with an "emulator" is that it completely > skips all the RTL level and dirty hacks are necessary > to make it behave the same way. Sure it's "fast" (depending With emulator/model it is easy to test the architecture selections. You can even add some peripherial emulation to the model and run first versions of the OS inside the model. This is the way all commercial processors are finetuned. It's quite difficult to predict real functionality and bottlenecks from spec. -- ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Subscriber_Services78063@juno.com Thu Nov 21 22:39:57 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18FE6D-0000FU-00 for ; Fri, 22 Nov 2002 14:44:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 22 Nov 2002 14:44:01 +0100 (CET) Received: (qmail 22051 invoked by uid 0); 21 Nov 2002 21:40:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 21 Nov 2002 21:40:10 -0000 Received: by moria.seul.org (Postfix) id 6934515E722; Thu, 21 Nov 2002 16:40:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5ECC115E7A7; Thu, 21 Nov 2002 16:40:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E208B15E722 for ; Thu, 21 Nov 2002 16:40:04 -0500 (EST) Received: from 192.117.96.61 ([203.170.4.68]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id gALLdwn29316 for ; Thu, 21 Nov 2002 16:40:00 -0500 Message-Id: <200211212140.gALLdwn29316@belegost.mit.edu> Received: from unknown (HELO mailout2-eri1.midsouth.rr.com) (184.119.91.62) by rly-xw05.mx.aol.com with asmtp; Nov, 21 2002 3:39:49 PM -0700 Received: from unknown (148.179.169.246) by rly-yk05.mx.aol.com with QMQP; Nov, 21 2002 2:21:38 PM +0600 Received: from [48.211.102.224] by rly-xl05.mx.aol.com with local; Nov, 21 2002 1:32:35 PM +0300 Received: from mx.rootsystems.net ([60.127.54.24]) by smtp-server6.tampabay.rr.com with SMTP; Nov, 21 2002 12:29:50 PM -0100 From: "WALL STREET BULLETIN..47111" To: f-cpu@seul.org Subject: [f-cpu] STOP YOUR FORECLOSURE........................................................................................................................................................................................................ wskyf Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Thu, 21 Nov 2002 15:39:57 -0600 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Priority: 1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

Did you miss out on SYPY, UP 309%?

Here's another pick - Another SHORT PLAY

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

ofpxlnuiewonbdqmybpoijprkdykcdf ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Your_Health_Care_242@skybest.com Sat Nov 23 08:08:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18FfP7-0002ZN-01 for ; Sat, 23 Nov 2002 19:53:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 23 Nov 2002 19:53:21 +0100 (CET) Received: (qmail 23951 invoked by uid 0); 23 Nov 2002 07:05:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 23 Nov 2002 07:05:18 -0000 Received: by moria.seul.org (Postfix) id C5D1115E8BD; Sat, 23 Nov 2002 02:05:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 869EF15E8E4; Sat, 23 Nov 2002 02:05:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 0230315E8BD for ; Sat, 23 Nov 2002 02:05:17 -0500 (EST) Received: from 61.171.203.110 (host2-81.pool80207.interbusiness.it [80.207.81.2]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id gAN75En03644 for ; Sat, 23 Nov 2002 02:05:14 -0500 Message-Id: <200211230705.gAN75En03644@belegost.mit.edu> Received: from [190.198.219.49] by a231242.upc-a.chello.nl with QMQP; Nov, 23 2002 12:43:22 AM +0300 Received: from rly-xl05.mx.aol.com ([147.119.50.98]) by smtp4.cyberec.com with NNFMP; Nov, 22 2002 11:41:27 PM +0600 Received: from unknown (19.150.51.145) by n9.groups.yahoo.com with esmtp; Nov, 22 2002 10:58:17 PM -0700 Received: from unknown (28.35.188.67) by rly-xl04.mx.aol.com with esmtp; Sun, 07 Apr 2002 13:26:58 +1000; Nov, 22 2002 9:46:36 PM -0100 From: Your_Health_Care_308 To: Subscriber2129@corecom.net Subject: [f-cpu] YOUR HEALTH CARE...................................................................................................................................................................... wpml Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 23 Nov 2002 01:08:38 -0600 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-Priority: 1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

CLICK HERE

 

Unsubscribe click here

npfpndyplfipkhcqbdnwoulfkupxgwm ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Nov 24 16:54:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18G27E-000193-00 for ; Sun, 24 Nov 2002 20:08:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 24 Nov 2002 20:08:24 +0100 (CET) Received: (qmail 3430 invoked by uid 0); 24 Nov 2002 15:55:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 24 Nov 2002 15:55:41 -0000 Received: by moria.seul.org (Postfix) id F24C015E8EF; Sun, 24 Nov 2002 10:55:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B6C4B15E8F4; Sun, 24 Nov 2002 10:55:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 1204F15E8EF for ; Sun, 24 Nov 2002 10:55:40 -0500 (EST) Received: from a57-137.dialup.iol.cz ([194.228.137.57] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Fz6e-0003PA-00 for f-cpu@seul.org; Sun, 24 Nov 2002 16:55:37 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Fz5o-0000CM-00 for f-cpu@seul.org; Sun, 24 Nov 2002 16:54:44 +0100 Date: Sun, 24 Nov 2002 16:54:44 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] reg. rotation [Was: New suggestion about call convention] In-Reply-To: <20021109154130.14362@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I read a discussion sometimes and just read about call conventions. --- RESUME: Michael's way was silently accepted - transposing calee saved registers at link time and generating prolog/epilogs for external calls. --- PROBLEMS: While it is sexy idea, when you look at apache or linux kernel source code for example you will see that in many functions there are indirect calls to other functions. For these you can't use the optimalisation. For GTK, GLIBC and others you have many functions in library, often with wery short code (where prolog/epilog really counts) which you can't optimize in this way too. Also it don't address parameter registers - assuming that most of functions uses 3 arguments then the first three argument registers will be very exposed - you will need often to copy them to another registers to free space for nested subroutine call. --- HADWARE NEEDED: Add register rotation. I'll try to explain my idea even if I know that rotation/renaming will probably eat next pipeline stage before decode. Maybe performance saving of it will be greater than looses from additional 1 cycle latency of jumps. And maybe someone clever will find way how to implement the idea without next stage. Suppose that r32...r63 (for now) can be rotated with granularity 2 regs (because of register pairing) by adding 5 bit constant ROFF somewhere in fetch, decode or new stage. We could manipulate the constant ROFF by instruction circ n; n is even int between 0...30 and instruction performs ROFF=ROFF+n in unsigned unsatureated (wrapped) arithmetic Note that 0th bit of ROFF is always 0 so that adder is 4bit in reality. I think (however I'm not HW expert) that HW needed is trivial and without impact on other parts of f-cpu. It is like instruction stream register renaming before it hits f-cpu as we know is currently. --- CALLING CONVENTION: r0..31 are system and scratch (caller saved) registers. I don't want to consider fine grained use just now. Rotated r32..r63 are parameter and calee-saved (local) registers. We have several calling conventions attached to function by keyword __poolsize(N) in GCC (for example) where N is even number from 0 to 32. Default would be 8 for example. A function with __poolsize(N) is guaranted that is will be called with r{64-N}..r{63} saved (not used). If such function needs L registers as locals is calls "circ L" and if L>N then it needs to save these L-N unsaved registers by itself. Example: function __poolsize(4) B(x,y,z); function __poolsize(8) A(a,b,c) { B(b+c,b-a,a); } leads to: A: ; call with r32=a,r33=b,r34=c add r33,r34,r62 sub r33,r32,r63 circ 2 ; now r32=b+c,r33=b-a, r34=a, r35=b, r36=c call to B (not sure with syntax) circ -2 ret (dtto) If A would be __poolsize(4) too then we would have to save some other registers before: A: ; call with r32=a,r33=b,r34=c add r33,r34,r62 sub r33,r32,r63 store [sp],r58 store [sp],r59 ; to assure that B will get poolsize 4 too circ 2 ; now r32=b+c,r33=b-a, r34=a, r35=b, r36=c call to B (not sure with syntax) circ -2 load [sp],r59 ; restore load [sp],r58 --- PERFORMANCE: I make some assumptions about LSU (because I found no description of it unfortunately). Example 1 shows the best case (probably return address could be saved in rotated local reg. too) and you can see that is can be really fast. Secons example (more common) is still good IMHO because stores and loads (could be done by SRB better) operates on registers which are not in use just now. So that if LSU can post read operation (assuming TLB is ok) and block only if registed is mentioned in other instruction then we could have a lot of time for (uncached) load. Additionaly compiler knows poolsize of all subroutines it will call so that it can iteratively start to prepare that size during its own progress at places where its own code has low ILP. It is simpler than IA64 like auto-spilled set but should still allow CPU to adapt to current code and use almost all registers. --- OTHER USES: One could do sw pipelining with that. Like: here: store [r21++],r33 add r32,r22,r33 load [r20++],r34 circ 2 loop here the snippet is wrong probably I only wanted you catch the idea - it adds r22 to all nums at r21=r20. Additinaly is uses registers r32..r63 as cache to hide potentional latency of load (up to 15 cycles). I'm not sure what would say current LSU however... best regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sat Nov 23 18:54:04 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQW-0000cm-00 for ; Mon, 25 Nov 2002 08:13:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:04 +0100 (CET) Received: (qmail 31059 invoked by uid 0); 24 Nov 2002 21:07:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 24 Nov 2002 21:07:20 -0000 Received: by moria.seul.org (Postfix) id 4EA5F15E8F2; Sun, 24 Nov 2002 16:07:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F44C15E8F5; Sun, 24 Nov 2002 16:07:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id D661415E8F2 for ; Sun, 24 Nov 2002 16:07:18 -0500 (EST) Received: from thor (155.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.155]) by smtp3.9tel.net (Postfix) with ESMTP id CC36F5BD9B for ; Sun, 24 Nov 2002 22:07:17 +0100 (CET) Content-Type: text/plain; charset="us-ascii" From: cedric To: f-cpu@seul.org Subject: [f-cpu] FPU size flag Date: Sat, 23 Nov 2002 17:54:04 +0000 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211231754.04897.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi every body, We currently define that FPU operand have to different size (32 bits [00] and 64 bits [01]). It would be nice to specify their name so that we can write some sample code with it. Why not using .d for 64 bits (double in C) and nothing for 32 bits float (f at the beginning of the instruction already say that). I reread the chapter named "ISA modularity" and I have a little problem. If we trust this paragraph, the SRB is optional, or I think that's totally impossible to write an OS without it. I don't know if the idea is to be able to create F-CPU where only one application can run or if it's a mistake. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Sun Nov 24 22:05:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQX-0000cm-01 for ; Mon, 25 Nov 2002 08:13:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:05 +0100 (CET) Received: (qmail 2195 invoked by uid 0); 24 Nov 2002 21:12:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 24 Nov 2002 21:12:52 -0000 Received: by moria.seul.org (Postfix) id 549BA15E8F2; Sun, 24 Nov 2002 16:12:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4AB5E15E8F5; Sun, 24 Nov 2002 16:12:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 0B25815E8F2 for ; Sun, 24 Nov 2002 16:12:51 -0500 (EST) Received: from telehouse-101-1-214.net1.nerim.net (telehouse-101-1-214.net1.nerim.net [213.41.190.214]) by kraid.nerim.net (Postfix) with ESMTP id 180CB40FB0 for ; Sun, 24 Nov 2002 22:02:21 +0100 (CET) Subject: Re: [f-cpu] optional SRB From: Antoine To: f-cpu@seul.org In-Reply-To: <200211231754.04897.cedric.bail@free.fr> References: <200211231754.04897.cedric.bail@free.fr> Content-Type: text/plain Message-Id: <1038171952.3399.27.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 24 Nov 2002 22:05:52 +0100 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > I reread the chapter named "ISA modularity" and I have a little problem. If > we trust this paragraph, the SRB is optional, or I think that's totally > impossible to write an OS without it. I don't know if the idea is to be able > to create F-CPU where only one application can run or if it's a mistake. It's quite simple to solve IMHO. On a context switch (IRQ/trap/...), the current PC could be stored in a special register, so as to be restored at the end without any need for SRB. Of course, the IRQ/trap/syscall handler should actually store the SR somewhere else as soon as possible, so as to avoid crashing if the handler itself is interrupted (besides, the OS would take care that all handlers are locked in memory - i.e. can not be swapped to disk). This is much simpler than making the SRB mandatory. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 25 00:10:59 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQd-0000cm-00 for ; Mon, 25 Nov 2002 08:13:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:11 +0100 (CET) Received: (qmail 11085 invoked by uid 0); 24 Nov 2002 23:11:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 24 Nov 2002 23:11:03 -0000 Received: by moria.seul.org (Postfix) id BFD5915E8EF; Sun, 24 Nov 2002 18:11:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9777C15E8F4; Sun, 24 Nov 2002 18:11:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a179.home.uni-hannover.de [130.75.232.179]) by moria.seul.org (Postfix) with ESMTP id 1A50415E8EF for ; Sun, 24 Nov 2002 18:11:01 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02498; Mon, 25 Nov 2002 00:10:59 +0100 Message-ID: <20021125001059.12071@thrai.stud.uni-hannover.de> Date: Mon, 25 Nov 2002 00:10:59 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] FPU size flag References: <200211231754.04897.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211231754.04897.cedric.bail@free.fr>; from cedric on Sat, Nov 23, 2002 at 05:54:04PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Nov 23, 2002 at 05:54:04PM +0000, cedric wrote: > We currently define that FPU operand have to different size (32 bits [00] and > 64 bits [01]). It would be nice to specify their name so that we can write > some sample code with it. Why not using .d for 64 bits (double in C) and > nothing for 32 bits float (f at the beginning of the instruction already say > that). In my assembler, I use `.f' for 32-bit and `.d' for 64-bit operations (or their numeric equivalents, `.32' and `.64'), with `.d' being the default (that is, you can omit it). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Nov 25 00:10:17 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQe-0000cm-00 for ; Mon, 25 Nov 2002 08:13:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:12 +0100 (CET) Received: (qmail 12073 invoked by uid 0); 24 Nov 2002 23:13:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 24 Nov 2002 23:13:57 -0000 Received: by moria.seul.org (Postfix) id 69A1C15E8F2; Sun, 24 Nov 2002 18:13:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 444FF15E8F5; Sun, 24 Nov 2002 18:13:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id E25E715E8F2 for ; Sun, 24 Nov 2002 18:13:55 -0500 (EST) Received: from homeworld (81.48.95.67) by smtp.laposte.net (6.0.053) id 3DDAB94B000961BC for f-cpu@seul.org; Mon, 25 Nov 2002 00:13:54 +0100 Message-ID: <003101c2940e$a7a24dc0$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> Subject: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 00:10:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N And where is the stack pointer ????? F-cpu has no dedicated stack pointer !!! ----- Original Message ----- From: "Antoine" To: Sent: Sunday, November 24, 2002 10:05 PM Subject: Re: [f-cpu] optional SRB > > > I reread the chapter named "ISA modularity" and I have a little problem. If > > we trust this paragraph, the SRB is optional, or I think that's totally > > impossible to write an OS without it. I don't know if the idea is to be able > > to create F-CPU where only one application can run or if it's a mistake. > > It's quite simple to solve IMHO. On a context switch (IRQ/trap/...), > the current PC could be stored in a special register, so as to be > restored at the end without any need for SRB. > > Of course, the IRQ/trap/syscall handler should actually store the > SR somewhere else as soon as possible, so as to avoid crashing if > the handler itself is interrupted (besides, the OS would take care > that all handlers are locked in memory - i.e. can not be swapped to > disk). > > This is much simpler than making the SRB mandatory. > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Nov 25 00:29:14 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQh-0000cm-00 for ; Mon, 25 Nov 2002 08:13:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:15 +0100 (CET) Received: (qmail 28125 invoked by uid 0); 24 Nov 2002 23:36:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 24 Nov 2002 23:36:19 -0000 Received: by moria.seul.org (Postfix) id E874D15E8F2; Sun, 24 Nov 2002 18:36:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DB72A15E8F5; Sun, 24 Nov 2002 18:36:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id 9014715E8F2 for ; Sun, 24 Nov 2002 18:36:16 -0500 (EST) Received: from aboukir-101-1-53.net1.nerim.net (aboukir-101-1-53.net1.nerim.net [213.41.182.53]) by kraid.nerim.net (Postfix) with ESMTP id E7D2441329 for ; Mon, 25 Nov 2002 00:25:42 +0100 (CET) Subject: Re: [f-cpu] optional SRB From: Antoine To: f-cpu@seul.org In-Reply-To: <003101c2940e$a7a24dc0$0100000a@homeworld> References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <003101c2940e$a7a24dc0$0100000a@homeworld> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1038180554.3151.11.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 00:29:14 +0100 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Le lun 25/11/2002 à 00:10, Christophe Avoinne a écrit : > And where is the stack pointer ????? F-cpu has no dedicated stack pointer > !!! So what ? SRB or not, it makes no difference. The OS still has to figure out where to save the registers anyway. In one case it will just set the SRB context block address in an SR and let the CPU do the savin, in the other case it will have to save registers manually. Please note : even if the SRB is not available, the SRs SRB_old and SRB_new can still exist, and just be used by the OS to emulate the SRB in a software way. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Nov 25 02:52:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GDQp-0000cm-00 for ; Mon, 25 Nov 2002 08:13:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Nov 2002 08:13:23 +0100 (CET) Received: (qmail 28020 invoked by uid 0); 25 Nov 2002 01:38:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 25 Nov 2002 01:38:42 -0000 Received: by moria.seul.org (Postfix) id D8D3A15E8F2; Sun, 24 Nov 2002 20:38:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C361D15E8F8; Sun, 24 Nov 2002 20:38:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 82DF515E8F2 for ; Sun, 24 Nov 2002 20:38:40 -0500 (EST) Received: from f-cpu.org (unknown [213.44.93.3]) by relay-4v.club-internet.fr (Postfix) with ESMTP id D08E71750 for ; Mon, 25 Nov 2002 02:38:37 +0100 (CET) Message-ID: <3DE18241.2030808@f-cpu.org> Date: Mon, 25 Nov 2002 02:52:01 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Antoine wrote: >> I reread the chapter named "ISA modularity" and I have a little problem. If >>we trust this paragraph, the SRB is optional, or I think that's totally >>impossible to write an OS without it. I don't know if the idea is to be able >>to create F-CPU where only one application can run or if it's a mistake. >> >> > >It's quite simple to solve IMHO. On a context switch (IRQ/trap/...), >the current PC could be stored in a special register, so as to be >restored at the end without any need for SRB. > >Of course, the IRQ/trap/syscall handler should actually store the >SR somewhere else as soon as possible, so as to avoid crashing if >the handler itself is interrupted (besides, the OS would take care >that all handlers are locked in memory - i.e. can not be swapped to >disk). > >This is much simpler than making the SRB mandatory. > > and that's "RISC" ;-) > Antoine wrote: > >Le lun 25/11/2002 à 00:10, Christophe Avoinne a écrit : > > >>And where is the stack pointer ????? F-cpu has no dedicated stack pointer !!! >> >> > >So what ? SRB or not, it makes no difference. The OS still >has to figure out where to save the registers anyway. In one >case it will just set the SRB context block address in an SR >and let the CPU do the savin, in the other case it will have >to save registers manually. > >Please note : even if the SRB is not available, the SRs >SRB_old and SRB_new can still exist, and just be used by the >OS to emulate the SRB in a software way. > > cool ! someone who understands the basics ;-) ok, there might be some hidden costs. it might not solve everything, but it addresses most problems. and it doesn't sound difficult to implement. YG PS : i recently attended a conference about GNU/Hurd and i have seen some Hurd sourcec code. It's very far from POSIX but one of the most crazy things i've seen is ... mmap() used for doing a malloc() ..... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 25 11:23:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUWz-0003fC-00 for ; Tue, 26 Nov 2002 02:28:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:53 +0100 (CET) Received: (qmail 4817 invoked by uid 0); 25 Nov 2002 12:24:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 25 Nov 2002 12:24:40 -0000 Received: by moria.seul.org (Postfix) id 007B415E8F4; Mon, 25 Nov 2002 07:24:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFDE315E8F8; Mon, 25 Nov 2002 07:24:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a253.home.uni-hannover.de [130.75.232.253]) by moria.seul.org (Postfix) with ESMTP id 7EB7615E8F4 for ; Mon, 25 Nov 2002 07:24:37 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id LAA00454; Mon, 25 Nov 2002 11:23:29 +0100 Message-ID: <20021125112329.55920@thrai.stud.uni-hannover.de> Date: Mon, 25 Nov 2002 11:23:29 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <3DE18241.2030808@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3DE18241.2030808@f-cpu.org>; from Yann Guidon on Mon, Nov 25, 2002 at 02:52:01AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote: > PS : i recently attended a conference about GNU/Hurd and i have > seen some Hurd sourcec code. It's very far from POSIX but > one of the most crazy things i've seen is ... mmap() used for doing > a malloc() ..... Huh? Linux (glibc) does that all the time (and has been doing it for many years), if the requested size is big enough. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Nov 25 17:53:55 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX0-0003fC-00 for ; Tue, 26 Nov 2002 02:28:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:54 +0100 (CET) Received: (qmail 13414 invoked by uid 0); 25 Nov 2002 12:53:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 25 Nov 2002 12:53:57 -0000 Received: by moria.seul.org (Postfix) id 7A57C15E8F4; Mon, 25 Nov 2002 07:53:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FA7B15E8F8; Mon, 25 Nov 2002 07:53:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 2268715E8F4 for ; Mon, 25 Nov 2002 07:53:56 -0500 (EST) Received: from club-internet.fr (flashmail-6v.cs.clubint.net [172.16.0.157]) by relay-2v.club-internet.fr (Postfix) with SMTP id 789C51701 for ; Mon, 25 Nov 2002 13:53:55 +0100 (CET) Received: from [//212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 13:53:55 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >De: Michael Riepe > >On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote: > >> PS : i recently attended a conference about GNU/Hurd and i have >> seen some Hurd sourcec code. It's very far from POSIX but >> one of the most crazy things i've seen is ... mmap() used for doing >> a malloc() ..... > >Huh? Linux (glibc) does that all the time (and has been doing it for >many years), if the requested size is big enough. O gawd .... Then how do they manage the situations where there is a lot of fragmentation, or when =22garbage collection=22 must be done ?... > Michael =22Tired=22 Riepe YG (back from Mars) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Nov 25 14:02:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX2-0003fC-00 for ; Tue, 26 Nov 2002 02:28:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:56 +0100 (CET) Received: (qmail 25006 invoked by uid 0); 25 Nov 2002 13:06:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 25 Nov 2002 13:06:18 -0000 Received: by moria.seul.org (Postfix) id DDEF015E8F4; Mon, 25 Nov 2002 08:06:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C31AB15E8F8; Mon, 25 Nov 2002 08:06:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id E46DB15E8F4 for ; Mon, 25 Nov 2002 08:06:12 -0500 (EST) Received: from homeworld (81.48.95.67) by smtp.laposte.net (6.0.053) id 3DDAB9440009E348 for f-cpu@seul.org; Mon, 25 Nov 2002 14:06:12 +0100 Message-ID: <000d01c29482$ec951dd0$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <3DE18241.2030808@f-cpu.org> <20021125112329.55920@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 14:02:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hey, Yann ! can you imagine to allocate a huge memory block and to access all its range in a very short time ? usually, a programs works only on a small part of the memory block, so it is more judicious to let the virtual memory to map the necessary physical page and makes the swap when necessary. Don't forget, malloc() and free() are not exactly POSIX functions and they don't belong to kernel functions but to user functions. So instead of using the obsolete sbreak() function to handle malloc() and free() functions, it make more sense to use mmap() instead to allocate the necessary heaps since it the application which handle those heaps, not the kernel. I could even say that the mmap() is the only way for the application to allocate heaps for its own malloc() and free() usage. ----- Original Message ----- From: "Michael Riepe" To: Sent: Monday, November 25, 2002 11:23 AM Subject: Re: [f-cpu] optional SRB > On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote: > > > PS : i recently attended a conference about GNU/Hurd and i have > > seen some Hurd sourcec code. It's very far from POSIX but > > one of the most crazy things i've seen is ... mmap() used for doing > > a malloc() ..... > > Huh? Linux (glibc) does that all the time (and has been doing it for > many years), if the requested size is big enough. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Mon Nov 25 14:21:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX3-0003fC-00 for ; Tue, 26 Nov 2002 02:28:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:57 +0100 (CET) Received: (qmail 17671 invoked by uid 0); 25 Nov 2002 13:24:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 25 Nov 2002 13:24:45 -0000 Received: by moria.seul.org (Postfix) id 3E24415E8F4; Mon, 25 Nov 2002 08:24:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A2AF15E8F8; Mon, 25 Nov 2002 08:24:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id D5D8F15E8F4 for ; Mon, 25 Nov 2002 08:24:43 -0500 (EST) Received: from homeworld (81.48.95.67) by smtp.laposte.net (6.0.053) id 3DDAB94B000A6413 for f-cpu@seul.org; Mon, 25 Nov 2002 14:24:43 +0100 Message-ID: <002101c29485$82fc4fd0$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 14:21:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Personnaly, I use mmap() a lot when I need to read or write a file with complex structures. That way, I access the file as if it is a memory thru word or structure pointers. It is very convenient for a search algorithm or creating a structural file. You don't need to explicetely use lseek(), read() or write() functions, just a msync() or a munmap() then a close() at the end. Not speaking about the share and access rights you can give at this memory. ----- Original Message ----- From: To: Sent: Monday, November 25, 2002 2:53 PM Subject: Re: Re: [f-cpu] optional SRB >De: Michael Riepe > >On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote: > >> PS : i recently attended a conference about GNU/Hurd and i have >> seen some Hurd sourcec code. It's very far from POSIX but >> one of the most crazy things i've seen is ... mmap() used for doing >> a malloc() ..... > >Huh? Linux (glibc) does that all the time (and has been doing it for >many years), if the requested size is big enough. O gawd .... Then how do they manage the situations where there is a lot of fragmentation, or when "garbage collection" must be done ?... > Michael "Tired" Riepe YG (back from Mars) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Nov 25 18:39:04 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX4-0003fC-00 for ; Tue, 26 Nov 2002 02:28:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:58 +0100 (CET) Received: (qmail 32315 invoked by uid 0); 25 Nov 2002 13:39:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 25 Nov 2002 13:39:09 -0000 Received: by moria.seul.org (Postfix) id 268B215E8F4; Mon, 25 Nov 2002 08:39:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FC4B15E8F8; Mon, 25 Nov 2002 08:39:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id EF3FF15E8F4 for ; Mon, 25 Nov 2002 08:39:04 -0500 (EST) Received: from club-internet.fr (flashmail-6v.cs.clubint.net [172.16.0.157]) by relay-4v.club-internet.fr (Postfix) with SMTP id 8B9611733 for ; Mon, 25 Nov 2002 14:39:03 +0100 (CET) Received: from [//212.43.214.31] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 14:39:04 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: =22Christophe Avoinne=22 > >Personnaly, I use mmap() a lot when I need to read or write a file with >complex structures. That way, I access the file as if it is a memory thru >word or structure pointers. It is very convenient for a search algorithm = or >creating a structural file. You don't need to explicetely use lseek(), >read() or write() functions, just a msync() or a munmap() then a close() = at >the end. Not speaking about the share and access rights you can give at t= his memory. That is fine on an Alpha or any other true 64-bit computer. The problem is ... doing mmap all the time on a 32-bit machine is a big source of limitations and annoyances. First example : GNU/Hurd's ext2 =22translator=22 does not accept partitions that are larger than a bit less than 2GB on x86. why ? because the developper originally thought it is easier to mmap the WHOLE partition. ghaaaaaaaaaaa..... Another example : at work, i have to deal with huge DNA and protein sequence databases which are several megabytes. However, the most widely used sequencing program (from NCBI) has the naughty habit of mmap()ing almost everything =21 This creates a lot of very naughty troubles. mmap works nicely when communicating with devices (/dev/fb for example). however, before we have a full 64-bit architecture, its use must be very carefully analysed otherwise it can become a nightmare. Now, when it comes to F-CPU, there should not be a problem (just in case one wondered ;-D) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Nov 25 14:53:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX5-0003fC-00 for ; Tue, 26 Nov 2002 02:28:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:28:59 +0100 (CET) Received: (qmail 13395 invoked by uid 0); 25 Nov 2002 13:54:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 25 Nov 2002 13:54:09 -0000 Received: by moria.seul.org (Postfix) id 1B04F15E8F4; Mon, 25 Nov 2002 08:54:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E0C215E8F8; Mon, 25 Nov 2002 08:54:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6F58915E8F4 for ; Mon, 25 Nov 2002 08:54:08 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211251353.367c; Mon, 25 Nov 2002 13:53:54 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] optional SRB From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Nov 2002 13:53:54 GMT Message-id: <200211251353.367c@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N When you're file didn't fill the memory what happen ? (256 M= B of RAM, 500 Mo of file ?) ? nicO -----Message d'origine----- De: "Christophe Avoinne" A: Date: 25/11/02 Objet: Re: Re: [f-cpu] optional SRB Personnaly, I use mmap() a lot when I need to read or write = a file with complex structures. That way, I access the file as if it is = a memory thru word or structure pointers. It is very convenient for a sear= ch algorithm or creating a structural file. You don't need to explicetely us= e lseek(), read() or write() functions, just a msync() or a munmap() th= en a close() at the end. Not speaking about the share and access rights you = can give at this memory. ----- Original Message ----- From: To: Sent: Monday, November 25, 2002 2:53 PM Subject: Re: Re: [f-cpu] optional SRB >De: Michael Riepe > >On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote= : > >> PS : i recently attended a conference about GNU/Hurd and = i have >> seen some Hurd sourcec code. It's very far from POSIX but >> one of the most crazy things i've seen is ... mmap() used= for doing >> a malloc() ..... > >Huh? Linux (glibc) does that all the time (and has been doi= ng it for >many years), if the requested size is big enough. O gawd .... Then how do they manage the situations where there is a lot of fragmentation, or when "garbage collection" must be done = ?... > Michael "Tired" Riepe YG (back from Mars) ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jendillard@companysales.com Mon Nov 25 15:01:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUX6-0003fC-00 for ; Tue, 26 Nov 2002 02:29:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:00 +0100 (CET) Received: (qmail 27690 invoked by uid 0); 25 Nov 2002 13:57:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 25 Nov 2002 13:57:32 -0000 Received: by moria.seul.org (Postfix) id B654A15E743; Mon, 25 Nov 2002 08:57:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A24FA15E8F7; Mon, 25 Nov 2002 08:57:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from outgoing3.themail.com (unknown [216.204.151.37]) by moria.seul.org (Postfix) with ESMTP id 564E915E743 for ; Mon, 25 Nov 2002 08:57:31 -0500 (EST) Received: from mail.TheMail.com [216.204.151.249] by outgoing3.themail.com (SMTPD32-6.06) id ABDBC383028E; Mon, 25 Nov 2002 08:55:39 -0500 Received-From: mail.TheMail.com To: youremail@yourdomain.com From: jendillard@companysales.com Subject: [f-cpu] Buy Printer Ink Direct from Factory, SAVE Up To 89% X-Priority: 3 Authorized-User: jendillard@companysales.com IP-Address: 12.238.175.75 MIME-Version: 1.0 Content-type: text/html Message-Id: <200211250855765.SM00690@mail.TheMail.com> Date: Mon, 25 Nov 2002 09:01:08 -0500 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N
If you are reading this then your email reader software cannot properly display this message. Fear not, you can access this very important message in its intended form directly on the Internet by simply clicking the link below. If the text below does not show up as a link, then copy the entire line and paste it into the address field of any Web browser. http://excuria.com/digitaloutreach/response01.html?ID=4053668-1879586
Buy Printer Ink Direct from Factory, SAVE Up To 89%
Apple Hewlett Packard Lexmark Brother IBM Canon Epson Xerox BuyInkDirect.com
click on your brand above for pricing

Order now and you could win
FREE black ink cartridges for a year *
compliments of Buy Ink Direct

for a complete price list
>> click here <<

* All orders over $35 between Oct 1, 2002 and Feb 1, 2003 will automatically be entered into a drawing to be held Feb 1, 2003. The winners of the Feb 1, 2003 drawing will receive 12 black ink cartridges (1 for each of 12 months) corresponding to the type of ink cartridges placed on the winning order. If you wish to be permanently remove from this distribution list email postmaster@excuria.com with Remove youremail@yourdomain.com from eXcuria as the subject.

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Nov 25 15:39:04 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXA-0003fC-00 for ; Tue, 26 Nov 2002 02:29:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:04 +0100 (CET) Received: (qmail 8491 invoked by uid 0); 25 Nov 2002 14:39:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 25 Nov 2002 14:39:07 -0000 Received: by moria.seul.org (Postfix) id 3A03C15E8F5; Mon, 25 Nov 2002 09:39:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 315F815E8FC; Mon, 25 Nov 2002 09:39:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id A539615E8F5 for ; Mon, 25 Nov 2002 09:39:05 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 18GKO8-00055l-00 for f-cpu@seul.org; Mon, 25 Nov 2002 15:39:04 +0100 Date: Mon, 25 Nov 2002 15:39:04 +0100 (CET) From: Martin Devera To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] optional SRB In-Reply-To: <200211251353.367c@th00.opsion.fr> Message-ID: References: <200211251353.367c@th00.opsion.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N It will use normal swap mechanism - expunge unused pages to get space for new. With large scattered accesses you end with MM trashing :( In Linux 2.4 there was a lot of fimilar issues around 2.4.10. devik On Mon, 25 Nov 2002, Nicolas Boulay wrote: > When you're file didn't fill the memory what happen ? (256 MB of RAM, > 500 Mo of file ?) ? > > nicO > > -----Message d'origine----- > De: "Christophe Avoinne" > A: > Date: 25/11/02 > Objet: Re: Re: [f-cpu] optional SRB > > Personnaly, I use mmap() a lot when I need to read or write a file with > complex structures. That way, I access the file as if it is a memory > thru > word or structure pointers. It is very convenient for a search algorithm > or > creating a structural file. You don't need to explicetely use lseek(), > read() or write() functions, just a msync() or a munmap() then a close() > at > the end. Not speaking about the share and access rights you can give at > this > memory. > > ----- Original Message ----- > From: > To: > Sent: Monday, November 25, 2002 2:53 PM > Subject: Re: Re: [f-cpu] optional SRB > > > >De: Michael Riepe > > > >On Mon, Nov 25, 2002 at 02:52:01AM +0100, Yann Guidon wrote: > > > >> PS : i recently attended a conference about GNU/Hurd and i have > >> seen some Hurd sourcec code. It's very far from POSIX but > >> one of the most crazy things i've seen is ... mmap() used for doing > >> a malloc() ..... > > > >Huh? Linux (glibc) does that all the time (and has been doing it for > >many years), if the requested size is big enough. > > O gawd .... > Then how do they manage the situations where there is a lot > of fragmentation, or when "garbage collection" must be done ?... > > > Michael "Tired" Riepe > YG (back from Mars) > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense de Wanadoo ! > Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifrance.com/_reloc/= w > > > __________________________________________________ > Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense de Wanadoo ! > Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifrance.com/_reloc/= w > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Nov 25 18:45:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXI-0003fC-00 for ; Tue, 26 Nov 2002 02:29:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:12 +0100 (CET) Received: (qmail 30295 invoked by uid 0); 25 Nov 2002 17:52:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 25 Nov 2002 17:52:24 -0000 Received: by moria.seul.org (Postfix) id 5ED0E15E900; Mon, 25 Nov 2002 12:52:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3C2B615E903; Mon, 25 Nov 2002 12:52:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (mallaury.noc.nerim.net [62.4.17.82]) by moria.seul.org (Postfix) with ESMTP id F261915E900 for ; Mon, 25 Nov 2002 12:52:22 -0500 (EST) Received: from telehouse-103-2-178.net1.nerim.net (telehouse-103-2-178.net1.nerim.net [213.41.187.178]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 3E66C62DD1 for ; Mon, 25 Nov 2002 18:52:20 +0100 (CET) Subject: Re: [f-cpu] optional SRB From: Antoine To: f-cpu@seul.org In-Reply-To: <3DE18241.2030808@f-cpu.org> References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <3DE18241.2030808@f-cpu.org> Content-Type: text/plain Message-Id: <1038246325.3448.52.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 18:45:25 +0100 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N For IRQ/trap handlers you probably also need : - a SR_PC which automatically holds the PC value just before the context switch - a set of temporary SRs with no other purpose than holding temporary values (let's say SR_TMP0 ... SR_TMP3). This because you need to save some registers before even the register save pointer is set up (at the very least you need to save the registe that will contain the register save pointer :-)) - an instruction which takes SR_PC and loads it into the PC. The instruction that returns from an IRQ/trap handler cannot use a general-purpose register, because the interrupted thread (or whatever you call it) needs to have all its registers untouched. This instruction could be called "reti" (return from interrupt). - an EI instruction to re-enable interrupts. Indeed, when a IRQ/trap is launched, interruptions should be automatically disabled by the CPU, because the very beginning of the handler will not be reentrant ; then you will re-enable them after the non-reentrant part is finished (which probably means when all registers are successfully saved). The DI instruction is optional. To my opinion this should be sufficient. The rest can be handled in software, for example by having a software-managed stack dedicated to context-switches. (please note : I am no systems programmer ;-)) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 25 20:31:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXL-0003fC-01 for ; Tue, 26 Nov 2002 02:29:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:15 +0100 (CET) Received: (qmail 30126 invoked by uid 0); 25 Nov 2002 18:42:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 25 Nov 2002 18:42:58 -0000 Received: by moria.seul.org (Postfix) id E2C3415E903; Mon, 25 Nov 2002 13:42:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B39B215E906; Mon, 25 Nov 2002 13:42:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp3.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 6269E15E903 for ; Mon, 25 Nov 2002 13:42:57 -0500 (EST) Received: from thor (61.188.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.188.61]) by smtp3.9tel.net (Postfix) with ESMTP id 862535BDD1 for ; Mon, 25 Nov 2002 19:42:56 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 19:31:29 +0000 User-Agent: KMail/1.4.3 References: <200211231754.04897.cedric.bail@free.fr> <003101c2940e$a7a24dc0$0100000a@homeworld> <1038180554.3151.11.camel@fsol> In-Reply-To: <1038180554.3151.11.camel@fsol> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211251931.29691.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > And where is the stack pointer ????? F-cpu has no dedicated stack > > pointer !!! > So what ? SRB or not, it makes no difference. The OS still > has to figure out where to save the registers anyway. In one > case it will just set the SRB context block address in an SR > and let the CPU do the savin, in the other case it will have > to save registers manually. How did you start to save your register ? You need a target address that you must first put in a register to save your registers, so you always lost at least one register... Puting the PC in the SR is not needed. If you want it, use loopentry. If you want to modify it use jmp. No need to complexify the SR unit for something like that. > Please note : even if the SRB is not available, the SRs > SRB_old and SRB_new can still exist, and just be used by the > OS to emulate the SRB in a software way. That's not the problem, the problem is how did you preserve all your registers ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Nov 25 19:51:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXP-0003fC-01 for ; Tue, 26 Nov 2002 02:29:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:19 +0100 (CET) Received: (qmail 28379 invoked by uid 0); 25 Nov 2002 18:54:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 25 Nov 2002 18:54:23 -0000 Received: by moria.seul.org (Postfix) id 5912A15E8F3; Mon, 25 Nov 2002 13:54:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2381815E904; Mon, 25 Nov 2002 13:54:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A785015E8F3 for ; Mon, 25 Nov 2002 13:54:21 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-200.jetnet.ab.ca [207.34.60.200]) by bach.ccinet.ab.ca (8.12.6/8.12.5) with ESMTP id gAPItPFB004576 for ; Mon, 25 Nov 2002 11:55:51 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DE2713A.4030007@jetnet.ab.ca> Date: Mon, 25 Nov 2002 11:51:38 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB References: <200211231754.04897.cedric.bail@free.fr> <003101c2940e$a7a24dc0$0100000a@homeworld> <1038180554.3151.11.camel@fsol> <200211251931.29691.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N cedric wrote: > That's not the problem, the problem is how did you preserve all your > registers ? Why not do the dumb stupid thing and reserve both registers and memory pointers for IRQ's. Only during a interupt service call can you read/write them. One advantage of fixed memory for system traps and irq's is you don'y have to worry about page faults or even a mmu. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Nov 25 19:49:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXQ-0003fC-00 for ; Tue, 26 Nov 2002 02:29:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:20 +0100 (CET) Received: (qmail 13078 invoked by uid 0); 25 Nov 2002 18:56:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 25 Nov 2002 18:56:28 -0000 Received: by moria.seul.org (Postfix) id 44A1915E8F3; Mon, 25 Nov 2002 13:56:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1AB0115E905; Mon, 25 Nov 2002 13:56:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id CAAAB15E8F3 for ; Mon, 25 Nov 2002 13:56:27 -0500 (EST) Received: from telehouse-103-2-178.net1.nerim.net (telehouse-103-2-178.net1.nerim.net [213.41.187.178]) by kraid.nerim.net (Postfix) with ESMTP id CFFDE41107 for ; Mon, 25 Nov 2002 19:45:55 +0100 (CET) Subject: Re: [f-cpu] optional SRB From: Antoine To: f-cpu@seul.org In-Reply-To: <200211251931.29691.cedric.bail@free.fr> References: <200211231754.04897.cedric.bail@free.fr> <003101c2940e$a7a24dc0$0100000a@homeworld> <1038180554.3151.11.camel@fsol> <200211251931.29691.cedric.bail@free.fr> Content-Type: text/plain Message-Id: <1038250170.3637.5.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 19:49:30 +0100 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, > How did you start to save your register ? You need a target address that you > must first put in a register to save your registers, so you always lost at > least one register... Puting the PC in the SR is not needed. If you want it, > use loopentry. If you want to modify it use jmp. No need to complexify the SR > unit for something like that. My previous email (18:45) was just addressing that ;) Note : you *cannot* use "jmp" or "loopentry" to return from an interrupt handler. You can't use any instruction that would use a general-purpose register. The interrupted task does not know it has been interrupted, so you must restore the whole of the register set when you return. Thus the return address cannot be taken from a general-purpose register. It can however be taken from a SR, because SRs are not meant to be used by ordinary code. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 25 20:53:23 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXR-0003fC-00 for ; Tue, 26 Nov 2002 02:29:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:21 +0100 (CET) Received: (qmail 25034 invoked by uid 0); 25 Nov 2002 19:04:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 25 Nov 2002 19:04:53 -0000 Received: by moria.seul.org (Postfix) id 526F415E8F3; Mon, 25 Nov 2002 14:04:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47F9B15E905; Mon, 25 Nov 2002 14:04:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id EC31315E8F3 for ; Mon, 25 Nov 2002 14:04:51 -0500 (EST) Received: from thor (61.188.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.188.61]) by smtp3.9tel.net (Postfix) with ESMTP id 2A12B5BD3E for ; Mon, 25 Nov 2002 20:04:50 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 19:53:23 +0000 User-Agent: KMail/1.4.3 References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <3DE18241.2030808@f-cpu.org> In-Reply-To: <3DE18241.2030808@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211251953.23243.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >Of course, the IRQ/trap/syscall handler should actually store the > >SR somewhere else as soon as possible, so as to avoid crashing if > >the handler itself is interrupted (besides, the OS would take care > >that all handlers are locked in memory - i.e. can not be swapped to > >disk). > >This is much simpler than making the SRB mandatory. > and that's "RISC" ;-) Hum, are you sure ? I never see SR used like this before... > cool ! someone who understands the basics ;-) > ok, there might be some hidden costs. > it might not solve everything, but it addresses most problems. > and it doesn't sound difficult to implement. It doesn't address the most important problem, preserve all your register. > PS : i recently attended a conference about GNU/Hurd and i have > seen some Hurd sourcec code. It's very far from POSIX but > one of the most crazy things i've seen is ... mmap() used for doing > a malloc() ..... It's all you remind about it ? I don't wan't to make a list of the idea they give about Hurd, but it's really the first OS where I see some new and interesting idea (fakeauth, IPC jail, ...). A lot of good idea, but a lot of work (That's remind me something, but what ?). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From webmaster@mond-grundstuecke.de Mon Nov 25 21:30:04 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXc-0003fC-00 for ; Tue, 26 Nov 2002 02:29:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:32 +0100 (CET) Received: (qmail 28671 invoked by uid 0); 25 Nov 2002 20:30:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 25 Nov 2002 20:30:57 -0000 Received: by moria.seul.org (Postfix) id 471C615E8F3; Mon, 25 Nov 2002 15:30:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2964615E903; Mon, 25 Nov 2002 15:30:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from post.webmailer.de (natsmtp01.webmailer.de [192.67.198.81]) by moria.seul.org (Postfix) with ESMTP id 73BAF15E8F3 for ; Mon, 25 Nov 2002 15:30:55 -0500 (EST) Received: from nbcjhfdf-d8bnlu ([212.83.58.34]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA00256 for ; Mon, 25 Nov 2002 21:30:51 +0100 (MET) Message-ID: <902309536933$18819409$81753993@nbcjhfdf-d8bnlu.technet> From: "www.Mond-Grundstuecke.de" To: Subject: [f-cpu] News! Date: Mon, 25 Nov 2002 21:30:04 +0100 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_757_79869127.89199322" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_757_79869127.89199322 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable Herzlich Willkommen! Liebe Besucher, bestimmt kennen Sie das auch: eine Einladung bei guten Freunden, eine wichtig= e Verabredung, oder eine Hochzeit, und dann die bekannte Frage: was soll ich = denn nur verschenken? Enter this link www.Mond-Grundstuecke.de Wir bieten Ihnen au=DFergew=F6hnliche Geschenkideen f=FCr besondere Freunde z= u besten Preisen - oder beschenken Sie sich einfach selbst. Wir w=FCnschen Ih= nen viel Spa=DF auf unseren Seiten! =20 ------=_NextPart_000_757_79869127.89199322 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable MOND

Herzlich Willkommen!<= /FONT>

     
Liebe Besucher,

bestimmt kennen Sie das auch:= eine Einladung bei guten Freunden, eine wichtige Verabredung, oder eine = Hochzeit, und dann die bekannte Frage: was soll ich denn nur vers= chenken?

 

 

Enter this link

ww= w.Mond-Grundstuecke.de

 

Wir bieten Ihnen au=DFergew=F6hnli= che Geschenkideen f=FCr besondere Freunde zu besten Preisen<= /STRONG> - oder beschenken Sie sich einfach selbst. Wir w=FCnschen Ihnen= viel Spa=DF auf unseren Seiten!

 

 

------=_NextPart_000_757_79869127.89199322-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 25 22:30:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXc-0003fC-01 for ; Tue, 26 Nov 2002 02:29:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:32 +0100 (CET) Received: (qmail 1306 invoked by uid 0); 25 Nov 2002 20:42:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 25 Nov 2002 20:42:14 -0000 Received: by moria.seul.org (Postfix) id 0DE9B15E8F3; Mon, 25 Nov 2002 15:42:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC0DD15E903; Mon, 25 Nov 2002 15:42:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp4.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id A746115E8F3 for ; Mon, 25 Nov 2002 15:42:13 -0500 (EST) Received: from thor (189.191.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.191.189]) by smtp4.9tel.net (Postfix) with ESMTP id BB0035BD37 for ; Mon, 25 Nov 2002 21:42:11 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB Date: Mon, 25 Nov 2002 21:30:44 +0000 User-Agent: KMail/1.4.3 References: <200211231754.04897.cedric.bail@free.fr> <200211251931.29691.cedric.bail@free.fr> <1038250170.3637.5.camel@fsol> In-Reply-To: <1038250170.3637.5.camel@fsol> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211252130.44451.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > How did you start to save your register ? You need a target address that > > you must first put in a register to save your registers, so you always > > lost at least one register... Puting the PC in the SR is not needed. If > > you want it, use loopentry. If you want to modify it use jmp. No need to > > complexify the SR unit for something like that. > My previous email (18:45) was just addressing that ;) > Note : you *cannot* use "jmp" or "loopentry" to return from an interrupt > handler. You can't use any instruction that would use a general-purpose > register. The interrupted task does not know it has been interrupted, > so you must restore the whole of the register set when you return. Thus > the return address cannot be taken from a general-purpose register. > It can however be taken from a SR, because SRs are not meant to be > used by ordinary code. But I was thinking that we have "ret" for that purpose and in fact SR will be very slow. Of course, this can't be taken from "user" register because we can't trust them, but I don't see the need to access it throug SR. In fact, SR can be used by ordinary code, specially by one that adapt their SIMD code. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Nov 25 21:46:39 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXf-0003fC-01 for ; Tue, 26 Nov 2002 02:29:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:35 +0100 (CET) Received: (qmail 23500 invoked by uid 0); 25 Nov 2002 20:53:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 25 Nov 2002 20:53:37 -0000 Received: by moria.seul.org (Postfix) id 94F9115E8F3; Mon, 25 Nov 2002 15:53:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8638E15E903; Mon, 25 Nov 2002 15:53:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (mallaury.noc.nerim.net [62.4.17.82]) by moria.seul.org (Postfix) with ESMTP id 3D73715E8F3 for ; Mon, 25 Nov 2002 15:53:36 -0500 (EST) Received: from telehouse-103-2-178.net1.nerim.net (telehouse-103-2-178.net1.nerim.net [213.41.187.178]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 25DF062D08 for ; Mon, 25 Nov 2002 21:53:33 +0100 (CET) Subject: Re: [f-cpu] optional SRB From: Antoine To: f-cpu@seul.org In-Reply-To: <200211252130.44451.cedric.bail@free.fr> References: <200211231754.04897.cedric.bail@free.fr> <200211251931.29691.cedric.bail@free.fr> <1038250170.3637.5.camel@fsol> <200211252130.44451.cedric.bail@free.fr> Content-Type: text/plain Message-Id: <1038257199.4201.6.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 21:46:39 +0100 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > But I was thinking that we have "ret" for that purpose and in fact SR will be > very slow. Of course, this can't be taken from "user" register because we > can't trust them, but I don't see the need to access it throug SR. I've just looked at the manual... In fact, there is "rfe", but it's defined to use the SRB ;-)))))))) SRs will be slower than general purpose registers, but they won't be used very often either ; also, the advantage is that it should be easy to add/remove SRs (because the unit is separate and doesn't need to be light speed-fast). Of course with the SRB context switches are faster, that's the whole point of it ;) It seems sensible to do at first without the SRB, and then add the SRB if it's really too slow. But I don't write the VHDL, anyway ;) > In fact, SR can be used by ordinary code, specially by one that adapt their > SIMD code. Well, yes, but the SRs which are usuable by ordinary code must be clearly specified in the coding conventions. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Nov 25 23:17:40 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXi-0003fC-00 for ; Tue, 26 Nov 2002 02:29:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:38 +0100 (CET) Received: (qmail 31401 invoked by uid 0); 25 Nov 2002 21:29:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 25 Nov 2002 21:29:11 -0000 Received: by moria.seul.org (Postfix) id C1B4615E8F3; Mon, 25 Nov 2002 16:29:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80B2615E903; Mon, 25 Nov 2002 16:29:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id EF14915E8F3 for ; Mon, 25 Nov 2002 16:29:08 -0500 (EST) Received: from thor (189.191.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.191.189]) by smtp4.9tel.net (Postfix) with ESMTP id 0FB415BDC5 for ; Mon, 25 Nov 2002 22:29:08 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Date: Mon, 25 Nov 2002 22:17:40 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211252217.40491.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > --- HADWARE NEEDED: > Add register rotation. I'll try to explain my idea even if I know > that rotation/renaming will probably eat next pipeline stage before > decode. Maybe performance saving of it will be greater than looses > from additional 1 cycle latency of jumps. > And maybe someone clever will find way how to implement the idea > without next stage. > Suppose that r32...r63 (for now) can be rotated with granularity > 2 regs (because of register pairing) by adding 5 bit constant ROFF > somewhere in fetch, decode or new stage. > We could manipulate the constant ROFF by instruction > circ n; n is even int between 0...30 and instruction performs > ROFF=ROFF+n in unsigned unsatureated (wrapped) arithmetic > Note that 0th bit of ROFF is always 0 so that adder is 4bit in > reality. I think (however I'm not HW expert) that HW needed is trivial > and without impact on other parts of f-cpu. It is like instruction > stream register renaming before it hits f-cpu as we know is currently. It look like a complex instruction that look having a lot of effect on the CPU I think. But I currently don't see where you can expect better performance. > --- PERFORMANCE: > I make some assumptions about LSU (because I found no description > of it unfortunately). Example 1 shows the best case (probably > return address could be saved in rotated local reg. too) and you > can see that is can be really fast. If I understand you example correctly, you want to protect parameter to not being transfered to a saved register, right ? But you still do memory transfert and an one cycle in the decoder to do this, plus a cycle for circ instruction. I don't see where you expect to have better performance. > Secons example (more common) is still good IMHO because stores > and loads (could be done by SRB better) operates on registers > which are not in use just now. So that if LSU can post read > operation (assuming TLB is ok) and block only if registed is > mentioned in other instruction then we could have a lot of time > for (uncached) load. Same remark for this example. > Additionaly compiler knows poolsize of all subroutines it will > call so that it can iteratively start to prepare that size > during its own progress at places where its own code has low > ILP. If I understand correctly, you are thinking that parameter will be saved a lot of time and restored after a call, right ? I am not sure that's the most common case. As you explain previously, the only place where it can be interresting is in library. But they have short code, and most of them only will only use temporary. (I think we need to have some stat about software on RISC CPU. Did somebody know a tool or something for that purpose ?). > It is simpler than IA64 like auto-spilled set but should > still allow CPU to adapt to current code and use almost > all registers. >From my point of view, the idea isn't to use all of them, but to use them to reduce memory operation and to reduce pipeline bubble. And I think, but perhaps I am wrong, that store didn't cost anything (only load introduce bubble, from what I remember about whygee LSU). I think that I don't understand your idea very well, can you please give us a timing sample with multiple call and what result you expect and where you expect them. Cedric PS: A macro that do a call will certainly look like this. .macro call name loadaddri name, t0 store [sp], ra jmp [t0], ra .endm ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 25 20:45:12 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXn-0003fC-00 for ; Tue, 26 Nov 2002 02:29:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:43 +0100 (CET) Received: (qmail 31790 invoked by uid 0); 25 Nov 2002 22:36:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 25 Nov 2002 22:36:41 -0000 Received: by moria.seul.org (Postfix) id F19FE15E747; Mon, 25 Nov 2002 17:36:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C887C15E8FF; Mon, 25 Nov 2002 17:36:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 21EE515E747 for ; Mon, 25 Nov 2002 17:36:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01896; Mon, 25 Nov 2002 20:45:12 +0100 Message-ID: <20021125204512.01790@thrai.stud.uni-hannover.de> Date: Mon, 25 Nov 2002 20:45:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB References: <200211231754.04897.cedric.bail@free.fr> <1038171952.3399.27.camel@fsol> <3DE18241.2030808@f-cpu.org> <1038246325.3448.52.camel@fsol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1038246325.3448.52.camel@fsol>; from Antoine on Mon, Nov 25, 2002 at 06:45:25PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 25, 2002 at 06:45:25PM +0100, Antoine wrote: > > For IRQ/trap handlers you probably also need : > > - a SR_PC which automatically holds the PC value just before the > context switch Yes, definitely. > - a set of temporary SRs with no other purpose than holding > temporary values (let's say SR_TMP0 ... SR_TMP3). This because > you need to save some registers before even the register save > pointer is set up (at the very least you need to save the registe > that will contain the register save pointer :-)) We need at least one of them, yes. > - an instruction which takes SR_PC and loads it into the PC. > The instruction that returns from an IRQ/trap handler cannot > use a general-purpose register, because the interrupted > thread (or whatever you call it) needs to have all its registers > untouched. This instruction could be called "reti" (return from > interrupt). It already exists, and is called `rfe'. > - an EI instruction to re-enable interrupts. Indeed, when a IRQ/trap > is launched, interruptions should be automatically disabled by the > CPU, because the very beginning of the handler will not be reentrant ; > then you will re-enable them after the non-reentrant part is finished > (which probably means when all registers are successfully saved). > The DI instruction is optional. This could be handled via SRs. E.g. interrupts could be re-enabled when SR_PC is read for the first time, or when `rfe' is executed, whichever happens first. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 25 20:26:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXo-0003fC-00 for ; Tue, 26 Nov 2002 02:29:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:44 +0100 (CET) Received: (qmail 20062 invoked by uid 0); 25 Nov 2002 22:36:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 25 Nov 2002 22:36:45 -0000 Received: by moria.seul.org (Postfix) id 1581315E8FF; Mon, 25 Nov 2002 17:36:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D54F915E904; Mon, 25 Nov 2002 17:36:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 58BCC15E8FF for ; Mon, 25 Nov 2002 17:36:42 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01844; Mon, 25 Nov 2002 20:26:46 +0100 Message-ID: <20021125202645.50138@thrai.stud.uni-hannover.de> Date: Mon, 25 Nov 2002 20:26:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] optional SRB References: <200211251353.367c@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200211251353.367c@th00.opsion.fr>; from Nicolas Boulay on Mon, Nov 25, 2002 at 01:53:54PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 25, 2002 at 01:53:54PM +0000, Nicolas Boulay wrote: > When you're file didn't fill the memory what happen ? (256 MB of RAM, > 500 Mo of file ?) ? Demand paging. The system will load the pages you access, and will write back dirty pages when RAM is too short. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Nov 25 20:22:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GUXo-0003fC-01 for ; Tue, 26 Nov 2002 02:29:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 02:29:44 +0100 (CET) Received: (qmail 7060 invoked by uid 0); 25 Nov 2002 22:36:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 25 Nov 2002 22:36:50 -0000 Received: by moria.seul.org (Postfix) id 629B115E904; Mon, 25 Nov 2002 17:36:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5804D15E907; Mon, 25 Nov 2002 17:36:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a149.home.uni-hannover.de [130.75.232.149]) by moria.seul.org (Postfix) with ESMTP id 0239715E904 for ; Mon, 25 Nov 2002 17:36:47 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01831; Mon, 25 Nov 2002 20:22:46 +0100 Message-ID: <20021125202246.63924@thrai.stud.uni-hannover.de> Date: Mon, 25 Nov 2002 20:22:46 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] optional SRB References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Nov 25, 2002 at 01:53:55PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Nov 25, 2002 at 01:53:55PM +0100, whygee@club-internet.fr wrote: [...] > O gawd .... > Then how do they manage the situations where there is a lot > of fragmentation, or when "garbage collection" must be done ?... They only use mmap() directly when the requested size exceeds a certain limit (I guess it was 128 KBytes). Smaller memory chunks are allocated differently. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 26 15:34:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GjMM-0000Fw-01 for ; Tue, 26 Nov 2002 18:18:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 18:18:54 +0100 (CET) Received: (qmail 21411 invoked by uid 0); 26 Nov 2002 10:34:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 26 Nov 2002 10:34:03 -0000 Received: by moria.seul.org (Postfix) id 2024815E74D; Tue, 26 Nov 2002 05:34:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B64715E8DF; Tue, 26 Nov 2002 05:34:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id DCD9415E74D for ; Tue, 26 Nov 2002 05:34:00 -0500 (EST) Received: from club-internet.fr (flashmail-6m.cs.clubint.net [172.16.20.65]) by relay-1m.club-internet.fr (Postfix) with SMTP id 147921683 for ; Tue, 26 Nov 2002 11:34:08 +0100 (CET) Received: from [//212.43.214.31] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] optional SRB Date: Tue, 26 Nov 2002 11:34:00 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >cedric wrote: > >> That's not the problem, the problem is how did >> you preserve all your registers ? > >Why not do the dumb stupid thing and reserve both >registers and memory pointers for IRQ's. Only during >a interupt service call can you read/write them. >One advantage of fixed memory for system traps and >irq's is you don'y have to worry about page faults >or even a mmu. Why ? because, as you wrote, it's dumb. it works well for one architecture or version, but then it becomes difficult to make it evolve... >Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 26 15:56:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GjMN-0000Fw-01 for ; Tue, 26 Nov 2002 18:18:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 18:18:55 +0100 (CET) Received: (qmail 10342 invoked by uid 0); 26 Nov 2002 10:56:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 26 Nov 2002 10:56:18 -0000 Received: by moria.seul.org (Postfix) id 9580415E8C5; Tue, 26 Nov 2002 05:56:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57F1515E908; Tue, 26 Nov 2002 05:56:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 120ED15E8C5 for ; Tue, 26 Nov 2002 05:56:16 -0500 (EST) Received: from club-internet.fr (flashmail-6m.cs.clubint.net [172.16.20.65]) by relay-1m.club-internet.fr (Postfix) with SMTP id 3DA9D16C6 for ; Tue, 26 Nov 2002 11:56:23 +0100 (CET) Received: from [//212.43.214.31] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] optional SRB Date: Tue, 26 Nov 2002 11:56:15 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >> >Of course, the IRQ/trap/syscall handler should actually store the >> >SR somewhere else as soon as possible, so as to avoid crashing if >> >the handler itself is interrupted (besides, the OS would take care >> >that all handlers are locked in memory - i.e. can not be swapped to >> >disk). > >> >This is much simpler than making the SRB mandatory. > >> and that's =22RISC=22 ;-) > >Hum, are you sure ? I never see SR used like this before... SRs are meant for special situations. Even if traps can happen at a high rate, it does not involve the application program. >> cool =21 someone who understands the basics ;-) >> ok, there might be some hidden costs. >> it might not solve everything, but it addresses most problems. >> and it doesn't sound difficult to implement. > >It doesn't address the most important problem, preserve all your register= =2E AFAIK, in practice (working systems) it is done by SRB. Now if you want to disable it, or deal with special cases (like, huh, now, because we don't have it yet) then the SRB's SRs can be reused for storing the first data. Concerning the backup itself, it can be done by the compiler on a case-by-case basis (backup the register just before it is first used). >> PS : i recently attended a conference about GNU/Hurd and i have >> seen some Hurd sourcec code. It's very far from POSIX but >> one of the most crazy things i've seen is ... mmap() used for doing >> a malloc() ..... > >It's all you remind about it ? No =21 i wrote : =22most crazy things i've seen=22. There are some =22good=22 things, i agree, but the good principles are hidden by the implementation problems. > I don't wan't to make a list of the idea they = >give about Hurd, but it's really the first OS where I see some new and = >interesting idea (fakeauth, IPC jail, ...). good ideas are abundant today .... Now the problem is to =22master the technology=22. Too many new things are difficult to handle at once. =22Many projects failed because they wanted to introduce too many groundbreaking technologies=22 which are less easily accepted and understood. GNU/Hurd did not fail =22yet=22 :-) I simply hoped that the bridges to the mainstream Linux word were more important. However, i know that the Hurd crowd is definitely hooked to the idea of using F-CPU. > A lot of good idea, but a lot of = >work (That's remind me something, but what ?). no idea ...... really ;-) >Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 26 16:56:09 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GjMQ-0000Fw-00 for ; Tue, 26 Nov 2002 18:18:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 18:18:58 +0100 (CET) Received: (qmail 16347 invoked by uid 0); 26 Nov 2002 11:56:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 26 Nov 2002 11:56:11 -0000 Received: by moria.seul.org (Postfix) id 4281815E74C; Tue, 26 Nov 2002 06:56:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3988915E8C6; Tue, 26 Nov 2002 06:56:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id DF7F415E74C for ; Tue, 26 Nov 2002 06:56:09 -0500 (EST) Received: from club-internet.fr (flashmail-1m.cs.clubint.net [172.16.20.60]) by relay-4m.club-internet.fr (Postfix) with SMTP id EEEDAE08A for ; Tue, 26 Nov 2002 12:56:23 +0100 (CET) Received: from [//212.43.214.31] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Date: Tue, 26 Nov 2002 12:56:09 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: cedric >> --- HADWARE NEEDED: >> Add register rotation. no. >> I'll try to explain my idea even if I know >> that rotation/renaming will probably eat next >> pipeline stage before decode. it's not probable, it's certain. Currently, the register set is probably the slowest part of the core. If you add any more logic to this, you have to slow down the general clock. >> Maybe performance saving of it will be greater than looses >> from additional 1 cycle latency of jumps. jump latency can be harmful. Currently there is 1 cycle on taken branch and this is too few to justify the implementatition of a branch predictor. But two cycles of latency will double this penalty. >> And maybe someone clever will find way how to implement the >> idea without next stage. AFAIK, this is not technically possible. >> Suppose that r32...r63 (for now) can be rotated with granularity >> 2 regs (because of register pairing) by adding 5 bit constant ROFF >> somewhere in fetch, decode or new stage. >> We could manipulate the constant ROFF by instruction > >> circ n; n is even int between 0...30 and instruction performs >> ROFF=3DROFF+n in unsigned unsatureated (wrapped) arithmetic > >> Note that 0th bit of ROFF is always 0 so that adder is 4bit in >> reality. I think (however I'm not HW expert) that HW needed is trivial >> and without impact on other parts of f-cpu. there IS an impact. it's half of a pipeline stage =21 >> It is like instruction >> stream register renaming before it hits f-cpu as we know is currently. > >It look like a complex instruction that look > having a lot of effect on the CPU I think. it hurst because it adds a new =22hidden state=22 and it might even have consequences on the scheduler because it is running in parallel with the register set reading cycle. > But I currently don't see where you can expect > better performance. idem. >Cedric > >PS: A macro that do a call will certainly look like this. > .macro call name > loadaddri name, t0 > store =5Bsp=5D, ra > jmp =5Bt0=5D, ra > .endm nice but how do you manage the stack (increment/decrement the pointer) ?... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Nov 26 16:46:16 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GjMX-0000Fw-00 for ; Tue, 26 Nov 2002 18:19:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 18:19:05 +0100 (CET) Received: (qmail 16379 invoked by uid 0); 26 Nov 2002 15:46:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 26 Nov 2002 15:46:31 -0000 Received: by moria.seul.org (Postfix) id BE78615E729; Tue, 26 Nov 2002 10:46:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A024B15E8DF; Tue, 26 Nov 2002 10:46:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by moria.seul.org (Postfix) with ESMTP id 1FAC415E729 for ; Tue, 26 Nov 2002 10:46:28 -0500 (EST) Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix2-1.free.fr (Postfix) with ESMTP id 8B31B4E for ; Tue, 26 Nov 2002 16:46:16 +0100 (CET) Received: by imp4-1.free.fr (Postfix, from userid 33) id 7B5F1554B; Tue, 26 Nov 2002 16:46:16 +0100 (CET) To: f-cpu@seul.org Subject: Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Message-ID: <1038325576.3de3974843206@imp.free.fr> Date: Tue, 26 Nov 2002 16:46:16 +0100 (MET) From: Cedric BAIL References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 193.49.124.107 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >PS: A macro that do a call will certainly look like this. > > .macro call name > > loadaddri name, t0 > > store [sp], ra > > jmp [t0], ra > > .endm > nice but how do you manage the stack > (increment/decrement the pointer) ?... I forgot... So it look like this : .macro call name loadaddri name, t0 storei -8, [sp], ra jmp [t0], ra loadi +8, [sp], ra .endm Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Nov 26 21:37:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GjMb-0000Fw-00 for ; Tue, 26 Nov 2002 18:19:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Nov 2002 18:19:09 +0100 (CET) Received: (qmail 22600 invoked by uid 0); 26 Nov 2002 16:37:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 26 Nov 2002 16:37:07 -0000 Received: by moria.seul.org (Postfix) id E230215E729; Tue, 26 Nov 2002 11:37:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C2C4C15E908; Tue, 26 Nov 2002 11:37:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 5131E15E729 for ; Tue, 26 Nov 2002 11:37:06 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-1v.club-internet.fr (Postfix) with SMTP id DE44116EE for ; Tue, 26 Nov 2002 17:36:48 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] reg. rotation Date: Tue, 26 Nov 2002 17:37:05 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: Cedric BAIL > = >> nice but how do you manage the stack >> (increment/decrement the pointer) ?... > = >I forgot... So it look like this : >..macro call name > loadaddri name, t0 > storei -8, =5Bsp=5D, ra > jmp =5Bt0=5D, ra > loadi +8, =5Bsp=5D, ra >..endm =5Co/ but now ... how do you manage the fact that ra will not be the restored ? because you push ra, but you pop =5Bsp - 8=5D .... SP will be ok, but not the temporary register. i'd do something like =2E.macro call name loadaddri name, t0 storei -8, =5Bsp=5D, ra jmp =5Bt0=5D, ra loadi =5Bsp=5D, ra =2E.endm =2E.macro return loadi +8, =5Bsp=5D, r0 jmp =5Bra=5D =2E.endm but it looses a lot of context. any local optimisation can remove half of the instructions. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Nov 26 18:13:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18GuEv-0000hR-00 for ; Wed, 27 Nov 2002 05:55:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Nov 2002 05:55:57 +0100 (CET) Received: (qmail 26465 invoked by uid 0); 26 Nov 2002 17:15:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 26 Nov 2002 17:15:33 -0000 Received: by moria.seul.org (Postfix) id 37A7015E736; Tue, 26 Nov 2002 12:15:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A23215E90A; Tue, 26 Nov 2002 12:15:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A6A2315E736 for ; Tue, 26 Nov 2002 12:15:31 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-201.jetnet.ab.ca [207.34.60.201]) by bach.ccinet.ab.ca (8.12.6/8.12.5) with ESMTP id gAQHHMFB018442 for ; Tue, 26 Nov 2002 10:17:23 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DE3ABC9.2050009@jetnet.ab.ca> Date: Tue, 26 Nov 2002 10:13:45 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] optional SRB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N whygee@club-internet.fr wrote: > Why ? because, as you wrote, it's dumb. > it works well for one architecture or version, > but then it becomes difficult to make it evolve... But then does making things complex, make it better? None the less software protocalls need to be well defined now,before code gets written. Mind you more dummy code needs to be written to find code generation bottlenecks from high level langauges. Also since the memory access times in the cache is the limiting speed factor I don't think much more speed improvments are possible at the hardware level. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Nov 27 11:50:57 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18H1f0-0000G4-00 for ; Wed, 27 Nov 2002 13:51:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Nov 2002 13:51:22 +0100 (CET) Received: (qmail 26174 invoked by uid 0); 27 Nov 2002 10:51:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 27 Nov 2002 10:51:01 -0000 Received: by moria.seul.org (Postfix) id 41B9915E76A; Wed, 27 Nov 2002 05:51:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 212D715E777; Wed, 27 Nov 2002 05:51:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4AEFF15E76A for ; Wed, 27 Nov 2002 05:50:59 -0500 (EST) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 18GzmT-0002zL-00 for f-cpu@seul.org; Wed, 27 Nov 2002 11:50:57 +0100 Date: Wed, 27 Nov 2002 11:50:57 +0100 (CET) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] In-Reply-To: <200211252217.40491.cedric.bail@free.fr> Message-ID: References: <200211252217.40491.cedric.bail@free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > of it unfortunately). Example 1 shows the best case (probably > > return address could be saved in rotated local reg. too) and you > > can see that is can be really fast. > > If I understand you example correctly, you want to protect parameter to not > being transfered to a saved register, right ? But you still do memory > transfert and an one cycle in the decoder to do this, plus a cycle for circ > instruction. I don't see where you expect to have better performance. eh eh .. Sorry my fault. I recomputed it yesterday and yes you are right. The only benefit would be fact that memory loads would not affect saved values whose we saved itself but some "older" ones which might not be needed soon ... But on other side these registers would be needed for store by next sibling subroutine call so that it is nonsence. > will only use temporary. (I think we need to have some stat about software on > RISC CPU. Did somebody know a tool or something for that purpose ?). Hmm, some time ago I patched gcc to give me interdependency information. The I found http://sourceforge.net/projects/introspector/. It might do the job you want. > >From my point of view, the idea isn't to use all of them, but to use them to > reduce memory operation and to reduce pipeline bubble. And I think, but > perhaps I am wrong, that store didn't cost anything (only load introduce > bubble, from what I remember about whygee LSU). this leads me to question, is LSU documented somewhere ? I'd be interested to study it but found nothing except some disscussion. When I tried to write call to validate my assumptions I found that I sometimes need to move bunch of parameters from s? to a?. Like in: f(a,b,c) { g(a,b,c); g(a,b,c+1); g(a,b,c+2) } where you want to save a,b and c as local vars and later move them to a?. Would be possible to have unconditional double move which would be 2r2w and moe 2 regs at the time ? Like: ; t0=addr of g store -8,[sp],s0 store -8,[sp],s1 store -8,[sp],s2 store -8,[sp],ra dmove a0,a1,s0,s1 move a2,s2 jmp t0,ra inc s2,a2 dmove s0,s1,a0,a1 move a2,s2 jmp t0,ra dmove s0,s1,a0,a1 ..... There is enough room in opcode. What do you think ? I'm not sure with orthogonality of it ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Nov 27 21:03:10 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HCbK-00056N-00 for ; Thu, 28 Nov 2002 01:32:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 01:32:18 +0100 (CET) Received: (qmail 7163 invoked by uid 0); 27 Nov 2002 19:16:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 27 Nov 2002 19:16:35 -0000 Received: by moria.seul.org (Postfix) id 5F78D15E76A; Wed, 27 Nov 2002 14:16:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26EC615E77E; Wed, 27 Nov 2002 14:16:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id 429CA15E76A for ; Wed, 27 Nov 2002 14:16:33 -0500 (EST) Received: from thor (122.191.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.191.122]) by smtp4.9tel.net (Postfix) with ESMTP id 427145CB8B for ; Wed, 27 Nov 2002 20:14:41 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Date: Wed, 27 Nov 2002 20:03:10 +0000 User-Agent: KMail/1.4.3 References: <200211252217.40491.cedric.bail@free.fr> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211272003.10491.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > will only use temporary. (I think we need to have some stat about > > software on RISC CPU. Did somebody know a tool or something for that > > purpose ?). > Hmm, some time ago I patched gcc to give me interdependency information. > The I found http://sourceforge.net/projects/introspector/. > It might do the job you want. Interresting, I will look to that. > > >From my point of view, the idea isn't to use all of them, but to use > > > them to > > reduce memory operation and to reduce pipeline bubble. And I think, but > > perhaps I am wrong, that store didn't cost anything (only load introduce > > bubble, from what I remember about whygee LSU). > this leads me to question, is LSU documented somewhere ? I'd be interested > to study it but found nothing except some disscussion. Currently, I think it's only documented in the brain of whygee ;-) > When I tried to write call to validate my assumptions I found that > I sometimes need to move bunch of parameters from s? to a?. Like in: > f(a,b,c) { > g(a,b,c); g(a,b,c+1); g(a,b,c+2) > } > where you want to save a,b and c as local vars and later move them > to a?. Would be possible to have unconditional double move which > would be 2r2w and moe 2 regs at the time ? Like: > ; t0=addr of g > store -8,[sp],s0 > store -8,[sp],s1 > store -8,[sp],s2 > store -8,[sp],ra > dmove a0,a1,s0,s1 > move a2,s2 > jmp t0,ra > inc s2,a2 > dmove s0,s1,a0,a1 > move a2,s2 > jmp t0,ra > dmove s0,s1,a0,a1 > ..... dmove syntax will be more like this (if it exist) : dmove r2, r1 the behaviour will be : r1 = r2 r1^1 = r2^1 But I don't know if it will possible to implement it, but it's a good idea I think. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Nov 27 20:47:58 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HCbL-00056N-00 for ; Thu, 28 Nov 2002 01:32:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 01:32:19 +0100 (CET) Received: (qmail 13913 invoked by uid 0); 27 Nov 2002 19:34:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 27 Nov 2002 19:34:33 -0000 Received: by moria.seul.org (Postfix) id 8999115E769; Wed, 27 Nov 2002 14:34:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FDCA15E77E; Wed, 27 Nov 2002 14:34:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 31B9915E769 for ; Wed, 27 Nov 2002 14:34:32 -0500 (EST) Received: from f-cpu.org (lcbv3-1-210.n.club-internet.fr [213.44.91.210]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 98E0F16F0 for ; Wed, 27 Nov 2002 20:34:14 +0100 (CET) Message-ID: <3DE5216E.5070201@f-cpu.org> Date: Wed, 27 Nov 2002 20:47:58 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] References: <200211252217.40491.cedric.bail@free.fr> <200211272003.10491.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, cedric wrote: >dmove syntax will be more like this (if it exist) : > dmove r2, r1 >the behaviour will be : > r1 = r2 > r1^1 = r2^1 >But I don't know if it will possible to implement it, but it's a good idea I >think. > > i don't think so (TM) > Cedric > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Nov 28 00:32:49 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HCbV-00056N-00 for ; Thu, 28 Nov 2002 01:32:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 01:32:29 +0100 (CET) Received: (qmail 668 invoked by uid 0); 27 Nov 2002 22:44:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 27 Nov 2002 22:44:23 -0000 Received: by moria.seul.org (Postfix) id E359B15E756; Wed, 27 Nov 2002 17:44:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B528115E796; Wed, 27 Nov 2002 17:44:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp3.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 4DCD615E756 for ; Wed, 27 Nov 2002 17:44:22 -0500 (EST) Received: from thor (122.191.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.191.122]) by smtp3.9tel.net (Postfix) with ESMTP id 310995C0CE for ; Wed, 27 Nov 2002 23:44:21 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Date: Wed, 27 Nov 2002 23:32:49 +0000 User-Agent: KMail/1.4.3 References: <200211272003.10491.cedric.bail@free.fr> <3DE5216E.5070201@f-cpu.org> In-Reply-To: <3DE5216E.5070201@f-cpu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211272332.49607.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, > cedric wrote: > >dmove syntax will be more like this (if it exist) : > > dmove r2, r1 > >the behaviour will be : > > r1 = r2 > > r1^1 = r2^1 > >But I don't know if it will possible to implement it, but it's a good idea > > I think. > i don't think so (TM) Are you sure ? I was thinking that we currently need a mecanism to read r1 and r1^1 and to write r2 and r2^2 at the same cycle, if we implement all the instruction specified in the manual. I don't see where will be the overhead in hardware, but I think it can be usefull for a lot of code. So why not ? (A more precise answer will be appreciate ;-) Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu Nov 28 10:41:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HPxv-0000Gs-00 for ; Thu, 28 Nov 2002 15:48:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 15:48:31 +0100 (CET) Received: (qmail 23433 invoked by uid 0); 28 Nov 2002 09:48:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 28 Nov 2002 09:48:45 -0000 Received: by moria.seul.org (Postfix) id 7775215E73A; Thu, 28 Nov 2002 04:48:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3DCF615E761; Thu, 28 Nov 2002 04:48:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by moria.seul.org (Postfix) with ESMTP id DA2DC15E73A for ; Thu, 28 Nov 2002 04:48:43 -0500 (EST) Received: from aboukir-101-1-63.net1.nerim.net (aboukir-101-1-63.net1.nerim.net [213.41.182.63]) by kraid.nerim.net (Postfix) with ESMTP id 27F6540F89 for ; Thu, 28 Nov 2002 10:38:06 +0100 (CET) Subject: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] From: Antoine To: f-cpu@seul.org In-Reply-To: <200211272332.49607.cedric.bail@free.fr> References: <200211272003.10491.cedric.bail@free.fr> <3DE5216E.5070201@f-cpu.org> <200211272332.49607.cedric.bail@free.fr> Content-Type: text/plain Message-Id: <1038476506.3134.5.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 28 Nov 2002 10:41:46 +0100 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > cedric wrote: > > >dmove syntax will be more like this (if it exist) : > > > dmove r2, r1 > > >the behaviour will be : > > > r1 = r2 > > > r1^1 = r2^1 > > >But I don't know if it will possible to implement it, but it's a good idea > > > I think. > > > i don't think so (TM) > > Are you sure ? I was thinking that we currently need a mecanism to read r1 and > r1^1 and to write r2 and r2^2 at the same cycle, if we implement all the > instruction specified in the manual. I don't see where will be the overhead > in hardware, but I think it can be usefull for a lot of code. So why not ? (A > more precise answer will be appreciate ;-) I think the answer is : CISC (tm) ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Nov 28 11:19:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HPxy-0000Gs-00 for ; Thu, 28 Nov 2002 15:48:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 15:48:34 +0100 (CET) Received: (qmail 30544 invoked by uid 0); 28 Nov 2002 10:19:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 28 Nov 2002 10:19:42 -0000 Received: by moria.seul.org (Postfix) id 239DE15E73A; Thu, 28 Nov 2002 05:19:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F43C15E761; Thu, 28 Nov 2002 05:19:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 003E015E73A for ; Thu, 28 Nov 2002 05:19:39 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200211281019.13a4; Thu, 28 Nov 2002 10:19:19 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Nov 2002 10:19:19 GMT Message-id: <200211281019.13a4@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N If register windows realy interrest you. Watch Sparc documen= tation. They used a rotating register set. Compiler choose to rotate or n= ot. When overflow/underflow occure, OS interrupt handler dump a (some= ?) register window in the current stack frame. (when a function call use= the rotating register set, it use 24*4+n octets, most of the tim= e never used). Compiler must be clever to avoid windows overflow. OS always= reserve one windows for interrupt handler (the register rotate at interr= upt). nicO -----Message d'origine----- De: Martin Devera A: f-cpu@seul.org Date: 27/11/02 Objet: Re: [f-cpu] reg. rotation [Was: New suggestion about = call convention] > > of it unfortunately). Example 1 shows the best case (pro= bably > > return address could be saved in rotated local reg. too)= and you > > can see that is can be really fast. > > If I understand you example correctly, you want to protect= parameter to not > being transfered to a saved register, right ? But you stil= l do memory > transfert and an one cycle in the decoder to do this, plus= a cycle for circ > instruction. I don't see where you expect to have better p= erformance. eh eh .. Sorry my fault. I recomputed it yesterday and yes y= ou are right. The only benefit would be fact that memory loads would not affect saved values whose we saved itself but some= "older" ones which might not be needed soon ... But on other side these registers would be needed for store = by next sibling subroutine call so that it is nonsence. > will only use temporary. (I think we need to have some sta= t about software on > RISC CPU. Did somebody know a tool or something for that p= urpose ?). Hmm, some time ago I patched gcc to give me interdependency = information. The I found http://sourceforge.net/projects/introspector/. It might do the job you want. > >From my point of view, the idea isn't to use all of them,= but to use them to > reduce memory operation and to reduce pipeline bubble. And= I think, but > perhaps I am wrong, that store didn't cost anything (only = load introduce > bubble, from what I remember about whygee LSU). this leads me to question, is LSU documented somewhere ? I'd= be interested to study it but found nothing except some disscussion. When I tried to write call to validate my assumptions I foun= d that I sometimes need to move bunch of parameters from s? to a?. = Like in: f(a,b,c) { g(a,b,c); g(a,b,c+1); g(a,b,c+2) } where you want to save a,b and c as local vars and later mov= e them to a?. Would be possible to have unconditional double move w= hich would be 2r2w and moe 2 regs at the time ? Like: ; t0=3Daddr of g store -8,[sp],s0 store -8,[sp],s1 store -8,[sp],s2 store -8,[sp],ra dmove a0,a1,s0,s1 move a2,s2 jmp t0,ra inc s2,a2 dmove s0,s1,a0,a1 move a2,s2 jmp t0,ra dmove s0,s1,a0,a1 ..... There is enough room in opcode. What do you think ? I'm not sure with orthogonality of it ... devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w __________________________________________________ Modem offert : 150,92 euros rembours=E9s sur le Pack eXtense= de Wanadoo !=20 Haut d=E9bit =E0 partir de 30 euros/mois : http://www.ifranc= e.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Nov 28 16:46:31 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HPy2-0000Gs-00 for ; Thu, 28 Nov 2002 15:48:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 15:48:38 +0100 (CET) Received: (qmail 21173 invoked by uid 0); 28 Nov 2002 11:46:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 28 Nov 2002 11:46:34 -0000 Received: by moria.seul.org (Postfix) id A7F5815E751; Thu, 28 Nov 2002 06:46:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B69815E761; Thu, 28 Nov 2002 06:46:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 3291D15E751 for ; Thu, 28 Nov 2002 06:46:32 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-3v.club-internet.fr (Postfix) with SMTP id 02A8416A8 for ; Thu, 28 Nov 2002 12:46:13 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention] Date: Thu, 28 Nov 2002 12:46:31 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: cedric > >hi, > >> cedric wrote: >> >dmove syntax will be more like this (if it exist) : >> > dmove r2, r1 >> >the behaviour will be : >> > r1 =3D r2 >> > r1=5E1 =3D r2=5E1 >> >But I don't know if it will possible to implement it, but it's a good = idea >> > I think. > >> i don't think so (TM) > >Are you sure ? absolutely. I will need another, better reason than =22it is possible=22 to be convinced that it is really necessary. > I was thinking that we currently need a mecanism to read r1 and = >r1=5E1 and to write r2 and r2=5E2 at the same cycle, so this will require to discard the condition field. do you remember that the =22move=22 instructions are conditional ? > if we implement all the instruction specified in the manual. i don't understand why there should be a relation with the other instructions. > I don't see where will be the overhead in hardware, it's not orthogonal with the move instructions. > but I think it can be usefull for a lot of code. > So why not ? Why make something that will become complex in the next generations of F-CPU ? > (A more precise answer will be appreciate ;-) try to think about the decoding+issue logic of a more complex implementation of F-CPU, for example one that executes 2 (or more) instructions per cycle. > Cedric YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Nov 28 16:58:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HPy2-0000Gs-01 for ; Thu, 28 Nov 2002 15:48:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 15:48:38 +0100 (CET) Received: (qmail 22425 invoked by uid 0); 28 Nov 2002 11:58:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 28 Nov 2002 11:58:33 -0000 Received: by moria.seul.org (Postfix) id C7F2815E756; Thu, 28 Nov 2002 06:58:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A998115E76C; Thu, 28 Nov 2002 06:58:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 50F7915E756 for ; Thu, 28 Nov 2002 06:58:31 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-2v.club-internet.fr (Postfix) with SMTP id 96C141684 for ; Thu, 28 Nov 2002 12:58:30 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: =?iso-8859-1?Q?Re:_Re:_[f-cpu]_reg._rotation_[Was:_New_suggestion_about_c?= =?iso-8859-1?Q?all=09convention]?= Date: Thu, 28 Nov 2002 12:58:30 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi again, >De: Antoine >> > cedric wrote: >> > >dmove syntax will be more like this (if it exist) : >> > > dmove r2, r1 >> > >the behaviour will be : >> > > r1 =3D r2 >> > > r1=5E1 =3D r2=5E1 >> > >But I don't know if it will possible to implement it, but it's a goo= d idea >> > > I think. >> = >> > i don't think so (TM) >> = >> Are you sure ? I was thinking that we currently need a mecanism to read= r1 and = >> r1=5E1 and to write r2 and r2=5E2 at the same cycle, if we implement al= l the = >> instruction specified in the manual. I don't see where will be the over= head = >> in hardware, but I think it can be usefull for a lot of code. So why no= t ? (A = >> more precise answer will be appreciate ;-) > >I think the answer is : CISC (tm) ? yup. 1) the =22double move=22 is highly implementation dependent. Nobody would have thought about it in another kind of core. This means that if FC1 ever exists, either it will have to drop the instruction, or the structure will have to be adapted to be able to perform =5Fone=5F instruction. 2) you can split the =22double move=22 into 2 simple instructions. There are a lot of scheduling issues with this : - first the destination will have to be paired. it is probable that in certain (annoyingly useful) situations, it is not possible. - the 2 sources are not likely to be ready/available at the same clock cycle. This means that a MOVE of one data can be easily blocked by another operand that is not ready. Clearly the intent is to increase coding density at the cost of scheduling and flexibility. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Nov 28 14:01:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HRtn-0001hD-00 for ; Thu, 28 Nov 2002 17:52:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 17:52:23 +0100 (CET) Received: (qmail 18183 invoked by uid 0); 28 Nov 2002 15:25:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 28 Nov 2002 15:25:43 -0000 Received: by moria.seul.org (Postfix) id E5C3615E780; Thu, 28 Nov 2002 10:25:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B61D315E783; Thu, 28 Nov 2002 10:25:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 292A515E780 for ; Thu, 28 Nov 2002 10:25:41 -0500 (EST) Received: from a68-137.dialup.iol.cz ([194.228.137.68] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18HQXr-0007wj-00 for f-cpu@seul.org; Thu, 28 Nov 2002 16:25:39 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18HOI0-0000D1-00 for f-cpu@seul.org; Thu, 28 Nov 2002 14:01:08 +0100 Date: Thu, 28 Nov 2002 14:01:08 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] dmove [Was: reg. rotation] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > I was thinking that we currently need a mecanism to read r1 and > >r1^1 and to write r2 and r2^2 at the same cycle, > > so this will require to discard the condition field. > do you remember that the "move" instructions are conditional ? Why to discard it ? There only would be different opcode which would change it from 2r1w ro 3r2w. However original intention was to make "unconditional" 2w2w move and use all 24bit as 4 register nums. > it's not orthogonal with the move instructions. I take this argument (if you read the original post I was worrying about it). But others arguments .. see below. Also you already have immediate form of majority of insns which is again not strictly orthogonal. But you optimize for common case - dmove it the same kind of animal. > try to think about the decoding+issue logic > of a more complex implementation of F-CPU, > for example one that executes 2 (or more) > instructions per cycle. And ? The insn would the like insn "sort". Or should all 2r2w (or 3r2w if any) be dropped from FC1 ? > 2) you can split the "double move" into 2 simple instructions. > There are a lot of scheduling issues with this : > - first the destination will have to be paired. > it is probable that in certain (annoyingly > useful) situations, it is not possible. with unconditional variant with 4 regs this is not problem IMHO. > - the 2 sources are not likely to be ready/available > at the same clock cycle. This means that a MOVE > of one data can be easily blocked by another operand > that is not ready. this is THE SAME for all 2r insn. Only difference from 2r2w mul or sort is different outcome of dmove. Compiler has to schedule it as other 2r2w insns. Only it'd be twice faster if used appropriately. > Clearly the intent is to increase coding density > at the cost of scheduling and flexibility. yes. I agree that increasing density and doubling throughtput was the main reason. But not at cost of scheduling nor flexibility. With multiisue FC1 with enough ports if will still make it faster when placed appropriately by compiler. I'd really like to understand where is problem with the instruction other than orthogonality. I'm not egoist I don't want the insn so much but I'm sad if I don't understand where is the problem :-( devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Nov 28 16:51:14 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HRto-0001hD-00 for ; Thu, 28 Nov 2002 17:52:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 17:52:24 +0100 (CET) Received: (qmail 14132 invoked by uid 0); 28 Nov 2002 15:58:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 28 Nov 2002 15:58:16 -0000 Received: by moria.seul.org (Postfix) id 0F07915E751; Thu, 28 Nov 2002 10:58:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DDB8715E76C; Thu, 28 Nov 2002 10:58:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3D14315E751 for ; Thu, 28 Nov 2002 10:58:14 -0500 (EST) Received: from a1-137.dialup.iol.cz ([194.228.137.1] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18HR3M-0000Fo-00 for f-cpu@seul.org; Thu, 28 Nov 2002 16:58:12 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18HQwc-0000GR-00 for f-cpu@seul.org; Thu, 28 Nov 2002 16:51:14 +0100 Date: Thu, 28 Nov 2002 16:51:14 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] Manual problems and strchr optimized routine Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-577244414-1038498674=:537" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-577244414-1038498674=:537 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, regarding manual 0.2.7b from point of casual reader: ** logic There might be explained what is meant by andn. These can be found at page 54 but is missing in OPs reference page. ** cand/cor There might be mentioned that is sets ALL bits of word to the result of and/or of bits. Because problem with mux insn I wasn't even understand it from examples :( ** mux The description doesn't make sense as English sentence to me. Also from ROP2-YG-2001201.tgz sources it seems that mux is done bitwise, so that what is a size flag here for ? ------- I also tried to make strchr function to learn more about f-cpu ISA. The funtion is attached and seems to have only one stall while testing 1.3 characters per cycle. If someone would be looking at it tell me please whether I coded it optimaly or whether I understand fc0 scheduling badly ... thanks, devik --8323328-577244414-1038498674=:537 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="strchr.asm" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="strchr.asm" OyBGQzAgb3B0aW1pemVkIHN0cmNociBieSBkZXZpa0BjZGkuY3oNCjsgSXQg c2hvdWxkIGJlIGZhc3RlciB0aGF0IGJ5dGUtd2lkZSBsb29wIGZyb20gMTAg Ynl0ZXMgdXB3YXJkcw0KOyBhcyBpdCB0ZXN0cyAxNiBjaGFyYWN0ZXJzIGVh Y2ggMTIgY3ljbGVzDQpzdHJjaHI6DQoJCWFuZGkgNyxhMCx0MTAJCTsgYnl0 ZSBvZmZzZXQNCgkJYnNldGkgNCxyMCx0OQkJOyBwcmVwYXJlIGNvbnN0YW50 IDE2DQoJCXNoaWZ0aXIgMyx0MTAsdDExCTsgb2Zmc2V0KjggZm9yIG1hc2sg Y3JlYXRpb24NCgkJbXN1YiB0MTAsYTAsYTAJCTsgYWxpZ24gYTAgdG8gNjRi aXQgYm91bmRhcnkNCgkJYnNldCB0MTEscjAsdDExCQk7IGNyZWF0ZSBtYXNr IHNlZWQNCgkJc2R1cC5iIGExLHQwCQk7IG1ha2UgY2hhci1jb21wYXJlIG1h c2sNCgkJbG9hZGFkZHJpIGZuZC0kLHQxNgk7IGFkZHJlc3Mgb2YgZm5kIGxh YmVsDQoJCW1hZGQgdDksYTAsdDMJCTsgcHJlcGFyZSBzZWNvbmRhcnkgcG9p bnRlcg0KCQlkZWMgdDExLHQxMwkJCTsgbWFrZSBmaXJzdC10ZXN0IG1hc2sN Cg0KCQlsb2FkaTEgOCxhMCx0MQkJOyBmaXJzdCAoaW5jb21wbGV0ZSkgYmxv Y2sNCgkJbG9hZGkxIDE2LHQzLHQyCQk7IGN5Y2xlIHByb2xvZw0KCQlzY2Fu ZC54bm9yLmIgdDAsdDEsdDYJOyB0ZXN0IGZvciBjaGFycw0KCQlzY2FuZC54 bm9yLmIgcjAsdDEsdDcJOyBhbmQgemVyb3MNCgkJbG9hZGkxIDE2LGEwLHQx CQk7IGN5Y2xlIHByb2xvZw0KCQkNCgkJb3IgdDYsdDcsdDgJCQk7IGZvdW5k IGFueXRoaW5nID8NCgkJYnNldGkgMyx0OSx0MTQJCTsgcHJlcGFyZSBjb25z dGFudCAyNCA9IDE2KHQ5KSs4DQoJCWFuZCB0OCx0MTMsdDgJCTsga2VlcCBv bmx5IGludGVyZXN0aW5nIHBhcnQgW3N0YWxsXQ0KCQlic2V0aSA1LHIwLHQx NQkJOyBwcmVwYXJlIGNvbnN0YW50IDMyDQoJCWptcC5ueiB0OCx0MTYJCTsg am1wIHRvIGZuZDoJCQ0KDQoJCWxvb3BlbnRyeSB0NQ0KCQlsb2FkaTEgMTYs YTAsdDEJOyBiaWcgZW5kaWFuIGxvYWRzDQoJCXNjYW5kLnhub3IuYiB0MCx0 Mix0OA0KCQlzY2FuZC54bm9yLmIgcjAsdDIsdDkNCgkJc2NhbmQueG5vci5i IHQwLHQxLHQ2DQoJCXNjYW5kLnhub3IuYiByMCx0MSx0Nw0KCQlvciB0OCx0 OSx0MTENCgkJb3IgdDYsdDcsdDEwDQoJCWxvYWRpMSAxNix0Myx0Mg0KCQlv ciB0MTAsdDExLHQxMg0KCQlsb2FkaTEgMTYsYTAsdDENCgkJam1wLnogdDEy LHQ1DQoJCQ0KCQltb3ZlLnogdDEwLHQ4LHQ2DQoJCW1vdmUueiB0MTAsdDks dDcJOyBzZWxlY3QgY29ycmVjdCBoYWxmDQpmbmQ6CQkNCgkJY21wbCB0Nix0 Nyx0OAkJOyBmb3VuZCBcMCBvciBjaGFyID8NCgkJbXNiMSB0Nix0NwkJCTsg cHJlcGFyZSBieXRlIG9mZnNldA0KCQltb3ZlIHIwLHJ2DQoJCWptcC5ueiB0 OCxyYQkJOyBcMCBmb3VuZCwgcmV0dXJuIE5VTEwNCg0KCQlzaGlmdGlyIDMs dDcsdDcJCTsgZmluaXNoIGJ5dGUgb2Zmc2V0DQoJCW1vdmUueiB0MTAsdDE0 LHQxNQk7IGZpbmFsIGNvbnN0YW50IGluIHQxNSAoMjQgb3IgMzIpDQoJCXN1 YiB0Nyx0MTUsdDcJCTsgZmluYWwgb2Zmc2V0DQoJCW1hZGQgYTAsdDcscnYJ CTsgdXBkYXRlIHBvaW50ZXIgW3N0YWxsXQ0KCQlqbXAgcmEJCQkJOyBmaW5p c2ggKG1hZGQgc3RpbGwgcnVubmluZykNCgkJDQo= --8323328-577244414-1038498674=:537-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Nov 28 19:16:17 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HVUp-0000Pc-00 for ; Thu, 28 Nov 2002 21:42:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 21:42:51 +0100 (CET) Received: (qmail 24731 invoked by uid 0); 28 Nov 2002 18:20:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 28 Nov 2002 18:20:09 -0000 Received: by moria.seul.org (Postfix) id 2E69C15E76C; Thu, 28 Nov 2002 13:20:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B31615E780; Thu, 28 Nov 2002 13:20:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id AC3F715E76C for ; Thu, 28 Nov 2002 13:20:08 -0500 (EST) Received: from homeworld (81.50.64.219) by smtp.laposte.net (6.0.053) id 3DDAB94B00120D26 for f-cpu@seul.org; Thu, 28 Nov 2002 19:20:07 +0100 Message-ID: <002701c2970a$3f94d1e0$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] Manual 0.2.7b Date: Thu, 28 Nov 2002 19:16:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Found it : "the ISO 8601 extended specification for representations of dates and times is YYYY-MM-DDTHH:MM:SS" A more condensed date would then be YYYYMMDD. ----- Original Message ----- From: "Graham Seaman" To: Sent: Monday, November 18, 2002 7:51 PM Subject: Re: [f-cpu] Manual 0.2.7b > On 18 Nov 2002, Antoine wrote: > > > Not that stupid, in my opinion. DD/MM/YYYY is the most > > wide-spread convention, isn't it ? I think only Americans > > use the other one (which is also less logical). > > > No, way more logical IMO - it lets you sort documents in date order. > Anyway isnt the 2002-11-18 format an ISO standard? > > Graham > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Nov 29 19:50:12 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18HVUq-0000Pc-01 for ; Thu, 28 Nov 2002 21:42:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 28 Nov 2002 21:42:52 +0100 (CET) Received: (qmail 32584 invoked by uid 0); 28 Nov 2002 19:09:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 28 Nov 2002 19:09:48 -0000 Received: by moria.seul.org (Postfix) id 4AB5315E77D; Thu, 28 Nov 2002 14:09:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 35D0015E781; Thu, 28 Nov 2002 14:09:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D62C415E77D for ; Thu, 28 Nov 2002 14:09:46 -0500 (EST) Received: from Biathlon (vlt6-219.n.club-internet.fr [194.158.119.219]) by relay-2v.club-internet.fr (Postfix) with SMTP id 088E916C4 for ; Thu, 28 Nov 2002 20:09:45 +0100 (CET) Date: Fri, 29 Nov 2002 19:50:12 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] dmove [Was: reg. rotation] Message-Id: <20021129195012.4c3da322.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 28 Nov 2002 14:01:08 +0100 (CET) devik wrote: > > > I was thinking that we currently need a mecanism to read r1 and > > >r1^1 and to write r2 and r2^2 at the same cycle, > > > > so this will require to discard the condition field. > > do you remember that the "move" instructions are conditional ? > > Why to discard it ? There only would be different opcode which > would change it from 2r1w ro 3r2w. > However original intention was to make "unconditional" 2w2w > move and use all 24bit as 4 register nums. > The instruction world are 32 bits. The 3*6 bits field are fixed for direct acces without any shift to extract register adress for using it. The 32 bits are really tight for real 3r2w. I had proposed a 4r2w versions. Your double move is only 2 move paired as it's maid in superscalar cpu. "My" 4r2w version use 64 bits world with true 4r2w (6 adress field). So there is no more register pairing, you only add one read port to the register bank but you could executed 90% twice the number of instruction (most fcpu instruction are 2r1w and some instruction as MAC is tricky to use). It is a"little" vliw. So it's 2*32 bits instruction or 64 bits one. The 64 bits version must behave as 3 one (by using output of 2 units that goes to another). For whygee, it's for FC1. :) I must write a draft of it. > > it's not orthogonal with the move instructions. > > I take this argument (if you read the original post > I was worrying about it). But others arguments .. see below. > Also you already have immediate form of majority of insns > which is again not strictly orthogonal. But you optimize for > common case - dmove it the same kind of animal. > > > try to think about the decoding+issue logic > > of a more complex implementation of F-CPU, > > for example one that executes 2 (or more) > > instructions per cycle. > > And ? The insn would the like insn "sort". Or should > all 2r2w (or 3r2w if any) be dropped from FC1 ? > > > 2) you can split the "double move" into 2 simple instructions. > > There are a lot of scheduling issues with this : > > - first the destination will have to be paired. > > it is probable that in certain (annoyingly > > useful) situations, it is not possible. > > with unconditional variant with 4 regs this is not problem IMHO. > > > - the 2 sources are not likely to be ready/available > > at the same clock cycle. This means that a MOVE > > of one data can be easily blocked by another operand > > that is not ready. > > this is THE SAME for all 2r insn. Only difference from > 2r2w mul or sort is different outcome of dmove. > Compiler has to schedule it as other 2r2w insns. > Only it'd be twice faster if used appropriately. > > > Clearly the intent is to increase coding density > > at the cost of scheduling and flexibility. > > yes. I agree that increasing density and doubling throughtput > was the main reason. But not at cost of scheduling nor flexibility. > With multiisue FC1 with enough ports if will still make it faster > when placed appropriately by compiler. > > I'd really like to understand where is problem with the instruction > other than orthogonality. I'm not egoist I don't want the insn so > much but I'm sad if I don't understand where is the problem :-( > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > __________________________________________________ > Modem offert : 150,92 euros rembours_s sur le Pack eXtense de Wanadoo > ! Haut d_bit _ partir de 30 euros/mois : > http://www.ifrance.com/_reloc/w ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Nov 28 23:55:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Hdbz-0005u1-00 for ; Fri, 29 Nov 2002 06:22:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 29 Nov 2002 06:22:47 +0100 (CET) Received: (qmail 10299 invoked by uid 0); 28 Nov 2002 22:07:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 28 Nov 2002 22:07:47 -0000 Received: by moria.seul.org (Postfix) id 8591815E73A; Thu, 28 Nov 2002 17:07:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 779C415E780; Thu, 28 Nov 2002 17:07:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id 195E815E73A for ; Thu, 28 Nov 2002 17:07:46 -0500 (EST) Received: from thor (211.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.211]) by smtp4.9tel.net (Postfix) with ESMTP id 692035BD26 for ; Thu, 28 Nov 2002 23:07:06 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Re: [f-cpu] reg. rotation [Was: New suggestion about =?iso-8859-1?q?call convention=5D?= Date: Thu, 28 Nov 2002 22:55:29 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211282255.29259.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > 1) the "double move" is highly implementation dependent. > Nobody would have thought about it in another kind > of core. This means that if FC1 ever exists, either it > will have to drop the instruction, or the structure will > have to be adapted to be able to perform _one_ instruction. Hum, I don't understand your problem. It exist instruction (like bitrev, mux, ...), that need to read 2 paired registers and it exist some other instructions (like addsub, divmod, ...) that need to write 2 paired registers. So where is the cost ? In fact the difference with move is really few, and we have still the flags room and the 3th operand free, if you want we have the same behaviour has move but with 2 paired registers. > 2) you can split the "double move" into 2 simple instructions. > There are a lot of scheduling issues with this : > - first the destination will have to be paired. > it is probable that in certain (annoyingly > useful) situations, it is not possible. That's not the problem, we have scheduler for this and they work well with this type of problem. > - the 2 sources are not likely to be ready/available > at the same clock cycle. This means that a MOVE > of one data can be easily blocked by another operand > that is not ready. Same problem for bitrevi and mux, but for add, sub and other. > Clearly the intent is to increase coding density > at the cost of scheduling and flexibility. In fact not, it increase the possibility of the scheduling to provide smaller and more efficient code and if you absolutely want to move only one register or not paired register you still have move instruction. The idea is interesting, because in a lot of case parameter need to be moved from parameter register to other register. I want really to know where it cost in hardware, I think it's in the decoder, but I don't see where, because all is already present. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@solitel.com Fri Nov 29 14:40:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Hdc4-0005u1-01 for ; Fri, 29 Nov 2002 06:22:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 29 Nov 2002 06:22:52 +0100 (CET) Received: (qmail 24902 invoked by uid 0); 29 Nov 2002 04:42:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 Nov 2002 04:42:55 -0000 Received: by moria.seul.org (Postfix) id 910E515E750; Thu, 28 Nov 2002 23:42:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6307B15E781; Thu, 28 Nov 2002 23:42:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ns3000.ovh.net (ns3000.ovh.net [213.186.35.100]) by moria.seul.org (Postfix) with SMTP id B67A915E750 for ; Thu, 28 Nov 2002 23:42:53 -0500 (EST) Received: (qmail 13474 invoked by uid 503); 29 Nov 2002 04:42:51 -0000 Received: from unknown (HELO iloos-8sqxh3e4v) (81.49.82.170) by ns3000.ovh.net with SMTP; 29 Nov 2002 04:42:51 -0000 From: postmaster@solitel.com To: f-cpu@seul.org Date: Fri, 29 Nov 2002 05:40:08 PST Subject: [f-cpu] MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: <20021129044253.B67A915E750@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N moteur de recherche


HTTP://WWW.SOLITEL.COM

___________________________________
Si vous ne désirez plus recevoir de courriers de cette liste :
To remove your email address from this list :
http://www.intellitec.net/remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Fri Nov 29 16:35:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18IXkR-0000G4-00 for ; Sun, 01 Dec 2002 18:19:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Dec 2002 18:19:15 +0100 (CET) Received: (qmail 16677 invoked by uid 0); 29 Nov 2002 11:35:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 29 Nov 2002 11:35:36 -0000 Received: by moria.seul.org (Postfix) id 2737015E71F; Fri, 29 Nov 2002 06:35:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08C8715E782; Fri, 29 Nov 2002 06:35:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 97BDE15E71F for ; Fri, 29 Nov 2002 06:35:34 -0500 (EST) Received: from club-internet.fr (flashmail-5m.cs.clubint.net [172.16.20.64]) by relay-4m.club-internet.fr (Postfix) with SMTP id A45A6E0F3 for ; Fri, 29 Nov 2002 12:35:49 +0100 (CET) Received: from [//212.43.214.31] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Manual problems and strchr optimized routine Date: Fri, 29 Nov 2002 12:35:33 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: devik > >Hi, > >I also tried to make strchr function to learn more about >f-cpu ISA. The funtion is attached and seems to have only >one stall while testing 1.3 characters per cycle. >If someone would be looking at it tell me please whether >I coded it optimaly or whether I understand fc0 scheduling >badly ... i did not have enough time to make a very detailed static analysis (partially because the register allocation is not well documented in your source) but it seems to be ok. I just had to remember what =22strchr=22 means ;-) >thanks, >devik > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 1 14:05:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18IXlw-0000G4-01 for ; Sun, 01 Dec 2002 18:20:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 01 Dec 2002 18:20:48 +0100 (CET) Received: (qmail 12217 invoked by uid 0); 1 Dec 2002 12:51:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 1 Dec 2002 12:51:55 -0000 Received: by moria.seul.org (Postfix) id E34CE15E73A; Sun, 1 Dec 2002 07:51:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCA7415E768; Sun, 1 Dec 2002 07:51:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 4E0AD15E73A for ; Sun, 1 Dec 2002 07:51:53 -0500 (EST) Received: from f-cpu.org (lcbv1-3-111.n.club-internet.fr [213.44.21.111]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3FA8C16C6 for ; Sun, 1 Dec 2002 13:51:33 +0100 (CET) Message-ID: <3DEA0918.7040304@f-cpu.org> Date: Sun, 01 Dec 2002 14:05:28 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Fun about the "Free Hardware Foundation" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! i found the following parodic text at http://www.hackvan.com/pub/stig/funny/parody/free-hardware-foundation I hope that you understand this 2nd degree humor :-) It's a strange mixture of parody and irony : parody because it mimics RMS's famous post and irony because we participate to what was previously thought to be a joke .... >From stig Fri Mar 24 15:02:10 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2486" "Fri" "24" "March" "1995" "17:38:47" "-0500" "Bill Dubuque" "wgd@martigny.ai.mit.edu" "<199503242238.AA00258@a.cs.uiuc.edu>" "70" "[Free _HARDWARE_ Foundation]" "^Resent-Date:" nil nil "3" nil nil nil nil] ("=stig=")) Received: from fugu.inse.com (fugu.inse.com [204.94.169.2]) by bonk.inse.com (8.6.9/8.6.9) with SMTP id PAA01672 for ; Fri, 24 Mar 1995 15:02:09 -0800 Resent-Message-Id: <199503242302.PAA01672@bonk.inse.com> Received: by fugu.inse.com (4.1/SMI-4.1) id AA00594; Fri, 24 Mar 95 15:00:19 PST Message-Id: <199503242238.AA00258@a.cs.uiuc.edu> Resent-Date: Fri, 24 Mar 1995 15:02:09 -0800 Resent-From: Stig Resent-To: stig@hackvan.com From: Bill Dubuque To: xemacs-beta@cs.uiuc.edu Subject: [Free _HARDWARE_ Foundation] Date: Fri, 24 Mar 95 17:38:47 -0500 [There really is a semi-serious thread on this stuff over in c.o.l.d. -wgd] From: hsu@Glue.umd.edu (Dave bd Hsu) Newsgroups: comp.os.linux.development.system,comp.os.linux.hardware Subject: Re: Free _HARDWARE_ Foundation Date: 23 Mar 1995 16:19:01 -0500 Organization: Pix -- The company with no adult supervision. NNTP-Posting-Host: convolution.eng.umd.edu In article <3kni3q$gn@jaws.cs.hmc.edu>, Ocie Mitchell wrote: >>I (half jokingly) posted something about starting a free hardware foundation >>(I.E. free access to schematics, no non-disclosure agreements etc.) A >>couple of people have taken me seriously, and now that I think about it, it >>doesn't seem like such a far fetched idea after all. > > I imagine most of you weren't on the net when this originally went out April Fool's Day 1986, so here's a blast from the past you might appreciate about this very topic. Enjoy! -dave === >From daemon Fri Apr 4 09:41:06 1986 Received: by eneevax.umd.edu (5.9/4.7) id AA14458; Fri, 4 Apr 86 09:40:53 EST Received: from OZ.AI.MIT.EDU by PREP.AI.MIT.EDU; Thu, 3 Apr 86 15:26:06 est Resent-Message-Id: <8604032026.AA14790@prep> Date: 2 Apr 1986 00:29 EST (Wed) Message-Id: Sender: "Richard N. Stollmin" From: RNS%MIT-PREP.ARPA@CCC.MIT.EDU Subject: Sample April Fools message Reply-To: RNS at MIT-PREP.ARPA To: INFO-GNU@PREP.AI.MIT.EDU, RNS%MIT-PREP.KIN@CCC.MIT.EDU, INFO-COBOL@MC.LCS.MIT.EDU Organization: Free Hardware Foundation Resent-From: SMC%MIT-OZ@PREP.AI.MIT.EDU Resent-To: usually-bizarre-mailing-list@MIT-OZ Resent-Date: Wed 2 Apr 1986 00:25-EST Status: RO Now available from Project Knu is our new FREE Vax-11/780 compatible computer. The Free Hardware Foundation opposes the tyranny of hardware manufacturers not allowing everyone to have one of their machines for free. With volunteer labor, we have built a machine just like the VAX-11/780, even down to its nameplate. Just send us a note, enclosing a self addressed, stamped shipping crate (extra large) and we will send you our KNU machine. Send your request to: Free Hardware Foundation, Inc. 1E+3 Weight Ave Camtunnel, MA 02138 We will pack it and ship it the same day. -RNS "The Last of the True Packers" -- Dave Hsu "The only way to deal with bureaucrats is with stealth and sudden violence." - UN Secretary-General Boutros Boutros-Ghali ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tsmith@gecco-online.net Mon Dec 2 10:47:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Isn4-0000G4-00 for ; Mon, 02 Dec 2002 16:47:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Dec 2002 16:47:22 +0100 (CET) Received: (qmail 24686 invoked by uid 0); 2 Dec 2002 09:50:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 2 Dec 2002 09:50:48 -0000 Received: by moria.seul.org (Postfix) id AB60615E721; Mon, 2 Dec 2002 04:50:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9586515E775; Mon, 2 Dec 2002 04:50:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from members.yahoo.com (unknown [63.137.89.55]) by moria.seul.org (Postfix) with SMTP id 90BB415E721 for ; Mon, 2 Dec 2002 04:50:45 -0500 (EST) To: f-cpu@seul.org From: tsmith@gecco-online.net Subject: [f-cpu] Avoiding Your Bills?..........319361 Message-Id: Content-Transfer-Encoding: quoted-printable Date: Mon, 02 Dec 2002 04:47:52 -0500 Content-Type: text/html; charset="us-ascii" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N = =

= = = = =
= = =

Email:f-cpu@seul.org 2-1Customer Service = Number346015

=
= = ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Dec 2 19:47:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18IsnA-0000G4-01 for ; Mon, 02 Dec 2002 16:47:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 02 Dec 2002 16:47:28 +0100 (CET) Received: (qmail 24152 invoked by uid 0); 2 Dec 2002 14:47:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 2 Dec 2002 14:47:54 -0000 Received: by moria.seul.org (Postfix) id D8C5815E720; Mon, 2 Dec 2002 09:47:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B8D2415E78E; Mon, 2 Dec 2002 09:47:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 5D22D15E720 for ; Mon, 2 Dec 2002 09:47:53 -0500 (EST) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-5v.club-internet.fr (Postfix) with SMTP id 5EA6A16AB for ; Mon, 2 Dec 2002 15:47:59 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] i hope it's not too late :-( Date: Mon, 2 Dec 2002 15:47:52 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N i was curious because i didn't hear about CCC for a long while, and found today : http://www.ccc.de/updates/2002/cfp I hope they don't mind if i sent a preliminary programme one day after the last day .... I keep you informed. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 02:53:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18J2ft-0007W3-01 for ; Tue, 03 Dec 2002 03:20:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 03:20:37 +0100 (CET) Received: (qmail 15812 invoked by uid 0); 3 Dec 2002 01:55:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 3 Dec 2002 01:55:14 -0000 Received: by moria.seul.org (Postfix) id 9459415E78C; Mon, 2 Dec 2002 20:55:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 575E415E794; Mon, 2 Dec 2002 20:55:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 5D90E15E78C for ; Mon, 2 Dec 2002 20:55:11 -0500 (EST) Received: from a82-137.dialup.iol.cz ([194.228.137.82] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18J2H0-0005kn-00 for f-cpu@seul.org; Tue, 03 Dec 2002 02:54:55 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18J2G3-0007En-00 for f-cpu@seul.org; Tue, 03 Dec 2002 02:53:55 +0100 Date: Tue, 3 Dec 2002 02:53:54 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] GCC 3.1 for F-CPU port Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1542613921-1038880434=:519" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1542613921-1038880434=:519 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, there was a lot of discussion about ISA. Lets create assembler, emulator and compiler and test it (boot linux kernel for example and count cycles it takes until /sbin/init is launched). As maintainer of part of Linux kernel I know that if I want to bug people with my ideas I should also do something. I created port of GCC for F-CPU. Just now it compiles rather complex functions however there are known bugs in stack handling (pointer inc) and some others. Also insns other than add and shift should be add (just now gcc uses its libs). There is problem with jump optimizer because it needs labels tied to jumps but we have them in registers. Just now I suppose assembler to handle it (ineffecient). Also conditional branching is not tuned - it supresses loop optimization :( But at least something to play with :) Test: long f(short a,short b) { short i; for (i=(short)0;i<(short)10;i++) a += b; return a+(long)0x100000; } ; FCPU ASM; CC by devik@cdi.cz.text .extern f f: move.d a0,a3 loadcons.0 0,a2 loadcons.0 9,a4 @L6: addi.d 1,a2,a2 add.d a3,a1,a3 cmples.d a4,a2,a0 jmp_direct.nz a0,@L6 widen.d a3,a1 bseti log2(1048576),r0,a0 add a0,a1,rv jmp ra --8323328-1542613921-1038880434=:519 Content-Type: APPLICATION/octet-stream; name="gccfcpu.tgz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="gccfcpu.tgz" H4sIAIcM7D0AA+w8aXPbxpL+Ktb+iDFdikmZlABJll1WlCwtwTLrSaTCI7Fj uxCQGEqIQIALgDrip/++fczgInXYifPeq12WLBFz9PT03YMej8Ng4p1uTMaz +cajb/QxjG3jxYvn8NcwXuxsF/6qzyPjxfMXW4bxfGdr55Fhbm6+ePFIPP9W COU/8zhxIiEeufLCO79j3H39/6GfcY7/+Gt9/NevYZiGsVPie8b/zZ2drS3i PzB9e/s5fDe3tjeNR8L461FZ/Pwf5//GmjiQEy/wEi8MYhFOBJDjVCZi6ozP vECKSRiJw85QjMPpzPNltC7Em+b+yVBcyCiGOesVIQQR57/Hrrc+/qMi1jYq lSdeMPbnrhRVlrD1s2quLb6OEzkttkWJX2yYzIMxYlVsDefJbJ4U25JIymKL vJpFJfDyNC7B951y05kTuU0Y2YxleYmpPSu1EJ2WtTVdOSm2e0EcNJcRIpLj kJoq8iqRUQBkDuJEjAERsQaI2IEzlfGHT7uVKLkS4+nMDmfGntFQX809Y7dS AR4mzsiXyL1I+g6zEhmHTHMiGQsncMUocoLxGTwAf0DoE29cWE19B7gA7MMn sSc+I2tF9TSpNvRv+T/Z71OZ/faT7Hcg9W+e7/MIWRU3gKxaeRSGvpD+VezZ ThzLKaBve0EiT2UkTlq91nFf1Gqw54aYB7F3GkhXQHcDf9XruxrKRei5CgrL ha2Fxp5FoR+ezmUG7U37yBJrDfG22x/Yv7QPLLvdGTwMmATRfyCw/0J2tFGf HN/7Q4rkTIrD/X2tVnESzcfJPJKgR8CHJ/MAhEUMWr1Da2C3+sf26/cDy+6e VJ64qJZySZfoDI+OlsxsHbUPO9aB/bZ9y/zCgPug9O+D0r8LChDDOrR6y+ar rluYX1kC7M2wsz9odzv2Sa971D0cWsvALgy6Ry7uWsc6ad+/jh50j8igxCPL xel4bCsh4D9TUDEFuN1pD9pA2F+tnpKgAY88C8Nz0mRFJy84FVpNwtHvcpzE IEgDkDHr6F2/rYcBHUHz4usgca7EPEYDIOL5ZOJdiSQEAK43dhKWzRiFFAyH 6yROQ8ShuJRi7ARPE5yHUHDQPJ47Psouro84xSy+eW2u3KLNNdBhXKQhQCFQ ke1ZnQyDQJN2tcvf81pOw1U7PqbzditokryJqJVAxZdeMj4TNZyogCvrJWAz sRTmq/zTZuFp+1VlZQK8i0Wt+jFZR0J8REPmxFPkqj0BtweKvaI47LhuZLOx rOWHNMQVjprMgEjJpNxX/bzq3nwMqkwLsSZetwd9+8Tq2UPgPU6MJJiFQICw 6L2LG/irmkEQnbmfPIy8u5UblqJDGchIc1pNvQar77Jf18IqZJBE1+jZ0ap5 JC2J64UkROBcnSmKDe+fQBGEJIQZfZBZmhEgq16BcFxC6BBcA0O9BOMJEiE5 nYWRE10DNPh7inMBXT9EKVyv4JCenMBmoJkwjSLnWvyGLtuWEGfYvnchn2Kv K8FLTlElL8884DgM8SCUiGLoJGydC7lbnvmh/ekp4hiEwR8yClGA9DwRzKcj +NPGfpyAQEDwUQ4JlTQIQS2DMSnJ4Ds41hnIgYeuF8l5HoSXoCAIooxdfBbO fRcwSMRIEpYuLhcgLrhcUZ3QE1XucWs1lqucxLNLwmYlPwXfpJTqM4mU2jwq FzwE4W65dQz/9gQGF0JgeAGUGEkfeJtchgKsEFqUCBgl3rb2/9Gg8EJtEbbn Sh/Y5DbEaJ4wJkgdIA7NASJfi+kcyBNI6QIdaub61vM67p91exJBzGPPQpTw yOZBvMUSW3dMjFJMCIZAlmwko40jVLuBmyr3bH1Kt4U41Wj31MSEEN8DGXtA tpO+NTzo2j3rsN0fgFXm7mfPGBFEs4QM9X8S330nHpcW5R5tlpCyz/bESybt BkIii/AMe+rUBrhpI6KMx8dkCmZHrLqNeAY/ZEeaNK1J0zAI3BAZ1/5lu1tE HDUe0HyJmK/GhHkW16rJRIu7Wb8IGAkyAZhuYzLLDOszRY8bCouLKnuqrGF8 rzm88hLKa1rRqRJ0jqdv18Y6m7FBzmSINGrMab8rZxKUJWTrMp5HkUSHlzjj c5yvtv5YiHaipwGt2RQhcfQIgOBfa6MEP2BzwXGF0TVCGcmxg7PArbOV3UWv 7vjg3RPnHL65Fw6EBqc0wkvIuE+9HBqO+zvkxVNALQZgE+Qg+yEwb+sPtFTp 7v9mSwXEAO/sUkILQQs8djtH78WZjGRKmISeyNG9Hh4qJKx3bYjEDjvdnmX3 B2DXcAC4VNg9uIMklv4E7LpUfsGLIACA5CpRPk4ox6hWxrnoyh9DIJAIXzow GlyKSppFzuQp8/pyzTRwEorZzrYYsfcU69Fz0PH1yNzODKSSmozUqJKxzawW //wna8IPe6K2+XwHZr+EcMM06kx8HRbBskiJ9WgbhdvJfPRj0T3XBnsdPrzu ch303fWdbYiZou0GoghqyLqsbX5qgZaanaap7dIPZKOaTXqqV1a+ygKtlIzr AhL3m8Fnz/4sBnfQCCzVB6TSp1VXm8EgbFRWYJZo1mqIexNwr4MNg19NsQ3/ SGmy3dwKHIwrMOFj8DFB2/UxMZgVOoiUPsfyKff/HegSOq643y0s3/fv05mI nEWzzxtm459cz0jHUbsg5ZFXaC9UgDkKL6Q6NAHxhsFkRKtVIgxnIg0BX6tz bkrTExidPzSp4HkJIlOLG7RgA01EpA1dfmicy2hw5G6WBNEUtnjcMIrscBZ/ 2PrEgwgAKqgP3uvDc0M356BPgI/V6mI72RHo2tlWnchATDmPuwcWmBI+UaqL vT3RfzMFT1gXBGoClNVztzbvnXtQnMvD1S4MjLnUFnPNFKQpGIWOzazDzNZV DSBMMUtDTRMEBGI1hu7VeH0UrYMwJaurZmN1dfPV7/zgG1VUswnICm+qkR5z ISM+KblBJaGl1ibLV5nArPwSe0ZphYfAjutoeiHDFpzupZE1JhyQFQmUJmV2 lyEB0OeIBKr9IhIizi24dD6Az9GI5uQRfmZqlHW6C2ksHl/mYDCf1DCVn6Ls gdot6EYsk5xugGIv04yGWCtpBAz8D9CHlKtfoBT3zOm3ec6XrvW2NM/cedi8 n0rzXi7RXWLGN9ZcFkmjoVV3NV7QWRSR+6R7GTjQkLuhfZWkU+RLCMAQSCsC l06GZBxrN4WPtwW8aQiL0o0DS/Gu0gGTVGYTEZGnDeEpTmBvOJmAbpGL1Kdf yOF94jAtreM91gE86Tq2jvXJl5YIHv/OenfCsxoCAkUUDHD+OqlbdMBIz5y/ hrGdrlpVmw8leeBpo6SWtsE+nPPdHEowVaNUXuTDavzpAcssgDw5GvY1TKQh RTgrSEedHBMBoIF7Rvqb6mHKFsY+iFgrnzHQSWfnh5l4wCeI0aUeA3tu8hS7 fTHzYYsZty5m5hf7SnLnTkFJ1hmFpdxQZ5avFmfq89OcopRiNwndGHhN5RSS WqGWgwBsdJ1pCbhI2AL8c2GYVkNAadYQZNUqK6QpM9i1DOZT/U7Txk4agVqn D15rvNQSMBjaao4QQ7Arx3myB4gIIIYHjH8aE73BZbhAegeWbKW23+1AktqB YB06CUVInX9uHeHT3p5RJ6yIOtPpyz+N0V2r/bBnFBu+39t8/jxdHzfzV6Bw N1HupcktWObRBAH4t2Efb4mMT0G6M1AlzIHG5s6/HPUlVDauJvD5qg19a6H5 6v08dDdgyTDNRWsnYD/S9fBlDJ4DnsFgX9JxOZbd2PJqhiHEFPNSMGsjD5Xm G6htLbcVA0mQ26viFNszCnDE4qeygG4Nl4VsGQKl25FSaGMpQx4Y4MrZ0FMI 0MPZtXDBL48T/xpzIQhX1HEnmf1OtwPWlvKioo/kQJXMMU5ZYq2xnyz2Y+0+ V9Lo9lQGNiBnw1TeCbidscQDjNoJPZdgoA8lrOk8NYf6JAqnX4SzeQ/O5jKc zS/D2dQ4E8r6BJxTIidI7saMxIeOZHP4FeiNm1N9mFvY+Dqwxur1g9isQ/S5 suKHwamgX1eAeipvtArQkpa/oiNABHUlvodvymbg9JV88rKwAEqPLyGzwyAu nPGhL4gP7gs+YEYSDuo1yfrWgEmmOHpodXCHNcXZJYLxq9Xr2ta7Qa+1v3yq uVPPg0EoNxzLEf6A4tl0Sm9GQagRI/HjjwpBNBAyearPmfEwHvWdrQMeCaxP XR56g5EbCx4QJDuCvsSTbBQhegcn8QBaS12Ch9X0HgDPuwth04M1KJOHJWKY SV1KFuIpYRme0ylHKnKs2UJbuFtY83O3fZCnsYLJNklVUpAFUqVNhQdYGeAo C4Xgcy8CbC5/gnSUzSgZKlyVXv+MteUsNUPqOibrxrNtHrfEyuHIaX4kte4J vZ/UAhpItxzO69CExtNcbDfVJMhH4ZteAcYdtBkk0RlfOTGRfcp/XgFbfFe9 jUBQXhwG+o09NWPqSy8XdHkYpgvQ46A0gexdwC7GZ2EYY7UHHVAx6ZxYBHIM YbhDxQJ0QKVST0VUlHfKwTrWK5WNHWXfBlnbMGuEr/Rt2On2DqyedfBKKcYv jAtiEMsU11dKczRr8MShzCFo61ikzDodUWhZP6nF9FL8dJjieDhIm4ZZ21Cj NCBUpvOYXuNHeAaevrwv4qT6MglUNCrjaf1UwjNNmqCVkmdR46yNmP0jWA6g y9SJzpmVGXemisOA2P6+fpghHgEVbRCTtdZk9YDstkYSeQ29I4+OvoH1Y5mT ISloOqoripcfXsaibVmWiOY+vU91kjwubiix3CJRlCmqBGOXk14GiAigAZ96 f6gKRlwWX3PmDuVTMVCQ6XwJwYJ1AqlCy5U+DgqPh8VeYKqSV5S0M4n1ePuL xHFOHQ8zVSMNTDSzcWXS2j12pgaasHpJCjrtozLDx2rvyFCE8XhJ0ggGgVW8 zubWyNtaUeM+NBqU6t8GxSxBMW+DgscCzA1rSg5IeFy/mDIfaYCmF9jSQPdT NgNgoQA4HQeu6CM/TWmggaI0jyJrL0+RXDyQUEQtIJON/oHcgsBzuEbqhSfT xJYyA93ImVxtQus5TfkVK31QJBVFtMRAsE5n0t/ljW1DGPwiKcTzkFxHGjn1 ZHZcz6KRGVcFWQXdZYRz7C84h4ag/VGMZdi9wbscNcjd/S313wv1/2d//Rp3 1/+/MF9k9f9bhmFS/b+5+f/1/3/H51vV/2Pq28FjROWFVCGtqqqDhlkUog3B shv4R2UbxZVVSZwuwd0/ObFPwGVbb9odqy+qzQMUV9E8mAfelWi2+ErBnnqC rj3ubylw9FglvE4iKjKdj2IPEvLoGrACHKbkddLKHLXdtGLDo1C6hJQq3/3Z 6vXb3U52pBonroyihqiyNalTWQRakXnQBA+nwfOKYEWAUFwmKH1wMugJXW8y kVQbhHcSLtEII8Iy0ZW36r4AvU0mutl0n4HXOXbGURgXChk1P10ZjyOPEiWK B/GglbIJug3BsJF3Wa0k48rxAUYV6OuHSOa02JgCff2kCtuLFBp22u+wfBqM eg5Z8Z0w65UMY67wpHn0bl7tAFrRZGdYcqUVFz45wve4tgZs65jj2pkDqVHW RPcQJOyfOlSs81lUO61jq9oQkI4OLSqT4LfUqkFVDtCLMYUBnkd7wbzYQekn V4sFkN3NkmtdKI3wEYzehOcCP73JNU1XcR4vtlys+r+0B/tvQdjFRwD/WXyu onQDxuDZO3atephl8y4Ha/NFtnAqWa3fNFY+8guhKvSG+AKnuRSOg7sYSRdL M28DpSCJKkBRyIJitoZHgwbdCLjhU/wDtccCzzF8CNU7K2BXPJNjb+KlJbBP vEm+Ll+BLZNGNQuz8kRCgD0pFM1rUdfFxr5zHc4TLdkHSsBIfiYQNscJBZeA xBhPRICvyDSISFE1uD5YuhWKfvOBkIp6KbxIMFBNxyKIJmzJd4uiiud+WBOm bczPrXdFZaGa8NftQ9vqHLRbHWE8DOHrhEv9xGUYuVpuS/iXFno/sL5iJYJP K02BrR49qgJq3N7SpX6BVGvJUh2eBsBIj4C0aEL4LQ+V5WjmYR35Ao103bx4 ScB+8dzkjPRdVc05oorIVRuqEFvRBIKdhGoaeQ9KTPS5CPGqEyZSpzMZ13S8 6/msvJe0oLo1wYVGv4ElfkovsaikG/Xf3GmSMNGKsDux8xLinQZDvqTazjjx fB9Ttq1NWv41yCkN1ciBmpxpQGk5eQEETDZ3lsgR0giJL3a2M8vS7gzswfsT PkeDRbOeo27nMNeVn0Rdd/S/Oeq2bgN70B2+PrLuArx0RMrUVK4b5IHpUkEN JT6uF/eM4pDb9K2Coepnidp9qati2UGCB/qNzk+fKjfkcm1OcaWTLl5h6hWQ bfFlBnSqo3AeuBhV1GBdqjdZq3MGCxKNYqEwIKHnd47L4b/uDjsHrd77r1kD DOGcy3dRs9QDecrSWq3ecbYQMg4Wer0MOqzKukRFwmkZclb1r66fFOFTHe3C Ag/ZSXrNhLiWu4aRg57exUoXeKngAyq0Y5hMhlg4E8QWlVS8EsZTIsvCZTwF 1jo+Gby337Sto4MyZItuL6TznsZcfqhPhJRhnPFdTFTSMjl6w/3BsMeSvkgX lFPG15Vj34nIBbNp4dRdPzjpDjWtGKcSd/f3wfIOeCekYMetAYhWH/wmB3k5 A3bpBBzQZLwUEXIH7+WcYb3awnbAqh9a/QFfCTy2OgMtqguO5EIWXeclmj0H aEiH9RPH83Fl0PNzFYZBHu3h/Zh5oHFBTBeo2d7Pr25wGNBPsBgefFN64j2P wZXkgtvU+TAKWYydmth1Xc2/2KUuBKgDKfZ6cU5mOXHA+XS0ZuDOfmcBwTq/ pSW2HD8CTXIXmvSZWpqK4P2iGCtqwEloiWMqKSQ40L2gEvUwVn4MsSUfhimO T/cdAkh8KFDR58bZtov6tQxVzWOTtlzClw5sISK6cGJADG0FcwLvINLFgsBN EXIugO2OvjyFO035pe6GhdF6AZt31kGKRh/Cz4+VFXNjDfOUtQ2IijfWogv8 Yjz0B+Y/eOy3nGHmf27ovOmuzwxC6lMg4GQG0bOInDThLrOkSGXKCXPXYejW gJZzfaytb6YjO8oEJ+ahu3QCumZS4j2mCCPJ2Q6GLSimnGvRfbdUoyDtRR4v LJeB4zTswvHn6p4ZH61xFI5YFISFR6c2uUnz0oohBjDDTIZRaKHws2oi2g0B yQHhrnFxYr7BWHxrFmM7DvW985K/2G8dHdnDflE4b5FN86E/OP8LhvOML5RN fHv6fVNdR1zb+DtFVZ2nBqklRqskx/MEzcaZMt6xviKIZ3R0LOJQFCyoNA2Z Cab1DN92xeFUgrfBVwgTfhOCb4sL2RfEkF6QhfC+DE45NsToUgWHLDp5EHSd ap4Kt481b/Q/K8gocTCAg4EUZFEeC6aUXnQX3Ug3Tffwkq5f8iQhRvmYSeHM omC9bfVIpjpdG1/o9mv0vUGI1QUdC9SKr8ZFjfuelePhpjDrYqPUWidW/Eyb BgqZ6KvPCo6TawAp+Ucy5ynECUozI/YtmBNu3X8UcTeXrMx5twPyErp4VuLQ +ZQn6c7pLJZzN8xIl4YJSL4zVFmNh0kWYqGZ86v2ZAlqIHsYw86i0J2PZe7o TVkg5HcGmYCRp6V7+WAoNMka/Madoh7tnw31/3BE9PJb/eclBSYjvL49aFst TINOiIEm02kTmMyU6tMpyXXJTpKpzUtj6m9n82gGEUAWxqitUFRKxp5PCPOB jY4isjipp3uAEVhHgEvN5jHpWepG0lRjWeSvcxmk9/BY7KgEA1+rpssSGceY YOM66Ph9QDfy+AQwnJTvYedDgl7r2FpYJC9cWX6Su/2tgSk2UdBSuF3JdKNX SFPpBPGS+5domdL73DIR85mooXjMnOh/2/sW4MjSq7w2NmuPvH5g/IiDCXd7 azzq2VZPt+ax423Ls1o9RmI1klbS7MrsjHtb3VfS9Xb37enbPZrZ8RgKE2xw UTxN2TxcAQonVCCxTaB4pArjFGAIBoekkoCBcjAJNqHCswyYVJzvnP//7/3v q/v2Q9Ks6WsfzUr3v/9/zvlf55z/nPPXeXTWy7dZlGbKUPamVZaCuqY/ZWjp 8NDhfdQxzbrhdCw2gfqWMJIEO21h032mZZJr2SnWi8V/F3KV7ux54uryxsI8 WWA8ewAnnij5S64tLpIvxvzC+tZS5sSJE9cm7mgRmCfEQzZAi1Us113ae4E+ nRTFZ3pHl6noYyMjTZTW7mQw1rtXkJn7resUzXGAHkaSGuA5qQpg8WSzJAcd kx43SQvn2YzxRuOd+JkpBr/Me7Tf7TmQPRW86xCe3bgcHsDYmC9duhSchZam gretylRln+Y8xoWQbkT4UHQrmI1by3OluaXZ5VXVTD6mduXaTUZvDt7WFGWx jrCVK1mzpO+W2MbtNXu/T0WEglMrs6Bm72prmy7JihP2VtmSBg3yZuAZFjrS yJEW5binCK1yY0+5ugiHN0fEaa81TNUtqnVeCsq1g/Jth5cLDIqqQZId7by8 8rsCYq3miShqW3FDiuvEMlaYaQ/i2ilBgpAm+Vd3cxBtrPJc2FSyLRkpqV8b ti5GqHWcPjEuL6wubMxKzFRlbfWWJRnR0CTvUKTOiwB20YZAhcs6HeHXo+jM aCHlLnN8HTOhXIVorya/DeHomN5Lc7xkKy1MKxFdJ3Vcx85q3YwdkeVxEbfN rbF6LZODVIUDCO30wgKv2RAoxxeNU/zk/bpiulp43WOYr3uJ58pIzyxuVM1K yyyzuRYymNkqKuJ4hy9DWWntma0p9yutAxu0OlGVssekdwrlvqjdlucFmDqk dIdqEPgtSgGCBByJZ1aKQWxnwsC2Wqy7KWMAx7CrLqQqBD78ms5UsbWzFWff tCho1Z2Q5GsrvW0ghrJkxIylIfqs1aj6upjTAMlRyUNSjQ5mSUsMNf5cIq2O JNl3ztwrCaTuqDqyvgGbdavLGivLV+i/SnMrs5ubC5ucIEytHau+N5OU+CtY nhewy6QxcMSKToTb76BUHMeJwVHt1JsGhZ0AZ9+Zm1ttiY7tNkm2vpOWBFD+ Mp0E+l0RkTbu6iavYOKXXT4AkH9W7PKdX7reNtiA5B6C3q+0bVaLlLRKzpET vLkpzcXHn1wcMXNr2FlWt6CQ3sln83ezZDO5I9xr8ZhZ9z93g+929XcqnQbl rqmb+oE5yR8YrJiqHOej+cmIUeBpeCz88GygaEx+KWeOTJpDmp0szvK5Wosq ronZl9lBzn/8woxpyXIi1JtWPcoiFGaM6FPBHqGUZAzxL/ly5Y1L3qL/iG/g ZlweCOSFKkQdJprU5o+yUdjSgWJHyglOAJ3l1fmFbQ8dX3OelXV2cyGujEjy 1NZmHRs2yuRVzOZ5ub6Xm02z3FKbZ8zOGT2CFjfWrpRWFshuPDmXcXcrxQvR kGMsZ42vzxqPY04LLSl2G5DTkRcvzWLE0gZ9yUoGqfuVTo38ut0t3AugcF26 3IkkDm8E7mQ/kqZT+TG501LROfdwlJEW/eSe9pc9r3ju2pw2nllBdUtKLnLt 3gE2bYNzYCMLBA1jkZxkDkyhKCzPXC1cyH79zCZ+Pj5z9UJ2ZebqxezaTD57 RVTYNqbftjrhsyqx8/3a46XFtQ3Jf2iHjEPWQEcYQt6dpE7BwD21fApDV7zP GDJuRf2qonAwojHHDfXJ1/s/mTo7/fCFi8HvHubv9M8e79rShbP+0itdS0+f P+8vnteL84T0vb7Cr9X7B2TQgFZ+0n35RmNK/iceUUtezOFNq25hbHGCKpH5 B+pTW3i4SDFRjA3uCvq7GuWX+c9LPDSWQr4iosvEgSYH6YqsMUFPJq1Ul/4t uLsbn41TddvSnirUPZEszxazDHCjY7XERNoxpfghlgSex1kVvxwU61h+Vycx 5OIkx686G1Dn4HyEwVUVmW9Q/cnqptYSRzbJfyO/aUdKMkI8E1KMMCOUhYyM xRsrQYUtfkIo8vNpfWNhcWFjg82qK2uz83LJ3s7yv5gAk+I/dHuiWNxuWXVI ItG2RZ8gK82LbdsTnjyLUWAFo3o8dgpc0bBu3FOsklqEnl5RVcjGRpYthYt1 2B7YVpssfRowNPOCfGV2W5oDZceySe3E8MZAdXhWeVa6zBQDGQKznBlLaClA 3FL2yogjP2Umkk4p0uPFTTBVLz8r03D5j5NdeVlpoVFGpcsba09tYgI9tfoU pKOo1lkXsusWiQlKnVUSCLfHOr9UY+VesW/t7U+pwqYQiYUjjc8gVdQUoKzw KsNHSibxF/bUGPpoj5zi6UBODP+GuVfmESnNESrhIGEWZcaJoHpNfEmHLcL4 pyiTu2mrrTDgNSxgWSu3le4a1YA3mlmQES3JAJKF1XnJHTaDchySqN0lGBSs kY5yYDmm0mnCFT22cHl5dXV59bIUbb2wpnB1/mGwsYWvpNlKmKuMqXM6U/jk X+boEu6V6szH9Bwi1LBzJ7nY+KMOQclRQtrFFiG1za1kjHMRRmw3TZoSxHzH bUa507ZJbqZfWEds2k3Hh5MjhbIdIVDwSOaFbMrenSpTPjrhICCHC1XE3bh4 lbFSfBb+A8LHoiHdKHQjFOUnpaxfLdPMZOX35CHgfu/6BfT60FZKS83a4Ryf TKg05jeU06NFFgeVaI/nYWenhSWGOEzKW27CL31uXd1YLa2vrW+WZjew0knq shLLLC1vGb/Xmoyv27Wk7C3Ec3VySLzUrFSEOLbarhSLCjRyNVMP7WoVy9HY IiNoaPFiHzw6rIdyRC4qLOGhY113FSKF1xHbmyKqYN5bUuXWwoKkMPzzHndT DTgMgY0Cjd1yq1pTayVp+mEHGRYrJiXFojEpQapwBQoYnBQ+Ihz2J8tmsuyi 2x+b1UhQzGG7geN06iqgTHzkO58ZJdkry4/xmaygWp6W+QilvwUpU5vH+tyc yJksdpEGuh6bH6kFkCMomoq6W5gn5Vzn7dw1kdL2yKYXeejiUqa75UiDrDSQ ivEu6ed1ZFVoJE3bEfllA4c0csq5o89TWDTuZYlPat0lc41bSXu/4+h5Z6PH izwlW59chYZMPyBeS5YlxjF0TMRWY5IcQsi2pmlgFc6zFNQNOTKZB1B7y8w0 6wGrmTfPFM5nfCbmsja1RbdV+Cx4j80Y0p+mHHCT46iGTksNWIdUVV4X2KPG 70/HGqjXhjhyogrEmSlWQzdeyhdqIFr2La5CYXA9ZdwCvPDLkAk6D8cEJP3F bNidvX0OK26wwCGO9Xg8Ss1f51owg7Ipxc2GeYupUqdle7a0T9IU5KnAphmb k2gGtZmrV66uYCw/ucArNakkE4EU+GVPIEJpZiPxKfCle6IqNhDfqQJwJX8m j8dg+CLvBDnXjurbf7LytVhRJ0JjTZ6jCiGJpbLpkGlmeasUQHESv2dFxdlb 2eXV+eWNhbktKXrjHZ0RTYsJcrVZVXm3GWssWkQ7UUXJVyH522Q91oadFIE8 9YMVUJdil9hJRVejAzYRx0A4+/K4PUrCqTbO6CRSnlS63kC5TJfJNTv/5Ozq 3AKTa4ilUuwbZBqd1+l9aCYQ+8+L7ZtnLmb8RlHGyzaa3nCWwo7/8Ii3ZbXO 82ktf+Ts+8U2XZtQMkg54LngGl3dYyy9CjEkhFLml79OOa51jLpCmJi6iQku VkFJwfP776Oj+MNQZ7Hx6uoVsd66kylmIkm6yTPQ0ZY4rlmJLmZVegk7gYUm Up4RnvHU94E06rxlugxg7MSZlit0CxuVK+d4ciGWnFZZE87BgorQGPEOumXT sZSLt1BLqQsL54R+KDBn64ewqsbJPeBH3CgmS9ikGMa0Z4jtQ7wJZbRwR/Ul TYoQQgR9/4i0K62JDPla1IwMw+b8b3zzQqVlil2wZe+yUyc62KwZDxors48t rAinJraA8nuhQYfS9Ee5QK9vrFErG3wzSVZVp8yEbmSaeCvTr3JempPVbLtw gVLHUmdfa9crdqfR5tSqk6qWTJGdn0MJkqO8K7LCLydWEcpOyHHo1/xVyDgN hDaHGbpuKzz1TMc9DbRYoAx4TcQ5caxKs7CblZnsZKiWo+JtZaoh3AMbQJha oW5IBcCfmMyYnZ/fEHcC1IRWLzVcH0ZMuvIFEnm3OY2A/xM/X+jI0ywr70mx oNAAYSYfYD2y5V0dxGK9MXHcSmhpPvre4tHwzAyYyHndyzbgDUJ1LGxuTtK/ WekLoTxCXOePqYLuFyLTF1JGSabGTemOF5pPBoWKM4YQLP2p3ymW3i3mS8l3 QmsmIl8eVceCKmUBpIks8t8x7mT1imqJbeKGP+uJ/plM9eZmw8mE8RJZbUKf FQdGNT8YqoXBUC0cAqoZQ0UJcuIT2gFKItOiv+Wi1s9RPa3eyPGkFmDGRGY7 Cg+yrNdgpmjcHeVoSUZX/ujo4kwUonpKopTx1R/juEWPunGM8uIGfKquRyIP Ye9ckXyGl+WqQzYOLES3L3E+I/2LAa+f8CrodQtFEGOZMlyvIMoTzH0tlh2j Wes4JffYj9vLGp5/mFjtiNPGXV+k6axY9ml7Yw9gcVzE5wMcLClCyYP+TOyZ 4t9llmafpJWWZ+vcxgKHsRQi3s4veG8JAX8JbFFegbw8mQgV8VrIK7FKBopT GPO+iV0n6AvqJkCRp5yVkIOFJ6KJKAK280jZVpyqs1jIwjnJNa4fr2xCeaje ZoHVlSPERr8bqoLTfElLvnSRFJi4aoDWgrwoATV5/kSscLifqjpFOKBKesPn YHym3jIFllnxZw7DL++aynmm4i/FOn+Z3MfozE41qYJQ9+kQvsH2K7ZuT3EJ 5bMZcFGQ54LCQWBdTCUW5ibVf8dMJsrpp+OkJg0vDdGNsIOB28awTdwvxlXw DC4iWEQ4JYhjNkhkVjUgVAUYQ+dedOzFJ1ZSKJGzgc1R21KzoGVZGhLUxHYd 1mQ70Q242RJl5eDJtnSz96Xk5X2BRWPgs0jcCL7cfOuVx9b4rVxxIsp4yfXi XsZ/u7R8eSkTzNMgI5w1DwbJEqMG3retOhkk1KmudKEQJm3mjYgkY05tY5C3 LWfXgkjupZCk6cXV6QfYARauYIhsLV+Z3Vooabknt9We6efiAzO+qjz/Gumc Tj4oYojmcjm0ry8tUvMWCJFJlxK/SbOZWMrI4s69bbVvq/Eg3eSlCx6KuznG DkgVoP2QU9VpGVHoSz7lE6tO3fWoF3fiaboFuf422+wVqS1CTlHYX2UwEV/Z JzWgutFpcEAJry2Mh3/lCK9TnkO/c7u+Y9cUj0QopMG320gXFxFlpeEntA02 rArrB4f3251WxWSPOIdDQIU7AFGiE6GOm/YxbrgDJAm3RSQnZV3wLbGek4Hb W5zTSQaZEu0CHUsYfTZ1NISRlu8HabILmancGgzhMSBUm11xckfl+IRRnClD zFABHBVTJTLTKSE+0/fMarNm0Slx2z1sc/2gZBoKH3+DM247sDGFwuDK0r+v at6S+5MW5+Ih5VfpvWHvLv/b5A4yQNuu49lArct9gRuH9EM594dgQBIio/Y+ 5ZyH95mheJCAzoht0de8Twa8vFZaXixpK57ak/hS34b1HN+7a2xsrQRcFYO7 UcCUIMKKdF9nd9ILu7Bmb9Od+er68Sql8Yxo1Q3yFrdgERJyK+QlIbwDMp7K O0jFfFF/0jVmZEj1r/9xPJEHbttZQ6hcbEBQqryrxQS3Oco3SuGDNn9V9JWN QJW6SCtudKtaKXx56DMPPPDA6TMZTWfyIUYPentJpGR9msfy9TdLtr3FcxyS Ua9isE9hpyLfdrPFSVQottLTaoKq+7Z+j4Bs9wQr+aFB6v9ELxpRabQx4ESA oR6VMbgVDgO3aJtKHG539R65OyGz/bS8EemOR4PNeeIcxdq9LQ3K2KM8EUh2 Hc8JWwR1qnc5Pt8/MMXxtt0wfV5zDfMgGxAgAw6olpdzy3Wvb9bKFfMR4xl5 vYD8kjNQYIJSdpGKPKBamd92TyPkWlBmL7qDsnsNHycK5XtlZX0tc9fhApqp fjnCDQ947XZqIsLOftZQCW74RLBCERjsNEtbrUoCAR3f1M5JSLJ6anlVC6c2 OHOKqklwgFZfeXFw3Fog6lxua55yrFO5eeDqbi4wmyzC+8LPDB+Yt6BCOMJd Ty6xvLE1m3arTblhLJFvTqYRlYEKIuZyIkJMpRwcaoHazhL/s7xOgUwsUXeE 0/tlRoXFfZohbDiY9MnUrtOYu95mlCZIhxkQRipSBRHD1FEHWL6V2+0mdoHO GSIAzL+w8onE/ML6ArZGb+kTJifGMCPnhh4v6mvF11/8Z5WaQe0c6qo0/oWl z7dTzIS+HQWi3zH5n1yY28JCwANFXGGkn/+BEXMad6Q+bJKOIq7jtP2HSlq7 wqvUbZpqIQnaK8S2CxkyJQw3jubo5fP94xnvnqfN2/JCzpDnoKhXWs1V3eUd x651vN42+dRJt7PojFifI6dVPpODchrhIlmW/mLPkPntlGuiv+3mhSNhlzOM FOVFOq5rkJtaSeRAK22K+9jnlmY3pDosrj2tlfc4WatMZQRZ2HVKFTEcjjo7 Yb+WVlvaRkRek13rFpR3Vqk4z70swsufSM9PM11di2c3Ql5z21dXN0tbG1dX 50ory48vlOhggX+VhqdbmnGAEzrJm8dFthjuQikYtW35X9LF2OakXWXHJp8H yh7DiSRihueVtScp7c22TOCjSY9eqKZsZ+e2RATccyhVi/DkcaOwAk6IK2tP lSiRWml2bo7EPp83Gup39q3dNt8C2vBuW6e/GXzCRsTI7GT1Zo1WLo4XJD8T zsLLHTFFRtoGTxpMT8Lc+4t0GCjrlQZQXFpepJ33KmX9ItZjFZ6PjL2XSKrt Ut0wv2ssr65vLMy5yQ7Xrm65v0v3WdomZH6b23S23CYRmZxr5AKPnqredrkQ 8OQEVitvLa2ura0rBJfXVidlK1nZeiYiCD68qLlptUjB0zREmYBeGWTbtay0 lMisOq7auNtpsZJexSZjeY5rO2b7gFRFt34+MHfzg9g7rNKrfE9+5wF/NibG dd5bHWc17yi5ULEtTDhQegNa+SmLTH/eLWMq8oiTismAf955MF/ZmKoUAb5k jL8+5UQg5p4h8/L9hIfgnIg3l/xy2ipnfEcMFM/aBK7q6/vG1rYY3eS0g8an +BzcImMSO/qRKrNjY1RoTBPSE3mTtdq+wS0yzFPIM5+c51wXTFWpGxVPThV8 xCplNku4RrMTP/9Br0TzTmaZyts0RIuRQRtza5tbm5MgL0uUZDFOFzZYshUG Lk4X74q0j+gSLHNTckssQFhjOk2yo++b5aZR7YidrNYKLWVuULxBLQcSjivS xLGSV3JSLc0Z98APH2fU5Rrud4Vi5FeGe2lH4Pu3uHdzqArysgaP+Ec02V0k +Ve20kcCLzw7qY9ZsuqzxWBFurkw6ovznP52wuDLA6QoKhzNN+chgigPMel4 7CXt2mt08E5kRFI+fiZVI/IzqjsstMT4ZXIUUnFm2Ddsq4aV8EDc4dm4TVJt bkJt/G6OwvnlJzeXz5akf6qRPt2pWjfTATniKqZhoFTLrHMpofeY5E5EsQ25 inuriLJjgRNVyqhHhjzTvy9qRzUcunRgKuEnrEWJVK0cjsd5TDmYqFKiCdTh hX/SMU0ILyoc08ntnyJvnVVbOvbYDZl5SYbYKE67OU89px69ai7jrSRetLk0 bsu7FCqcdYdNj8pbniUVXvDNWxzrI9Z7vyFFLklNto2yNwj0UV0aZBuwsE9K YdD3tXuNu1sOqJ8KniOsrm0tzy2Urq7Psx18bhKN0F62ucpOR9L79+pmiXwM i1Jix+rQbtk1Iba6DkTCN8xQd3Po+WM0h6O2FvovQihq3L3Efzd7cyDtxOaV Em2zVyE/rl3dmCP5bGWB/J8mN7c2FmavCDcpsa5BD7tzwnUhUu/T19o5aula O82H3SBNXvF3o2NjspRkGmR/hbxaRFXWELXwhL5LkhFomAw4VpFYvGc1GjLR k8YnKyieEYFEUomDRdjvKWPsohbsnOmicG1FmaIxNyfEbi+DOXk+cXmZtVtx 2Q40iBl2q01SNXs5uZdY1FQ0HPldKvWBxPxyxY2EFSGGYqqA1DaFkZbJXo3u YsdIvGwHTwaJpNn19dLaqpFOD4VZw+a1XWDD+HUa4jxDxOlivAcHtdv44mKg dWmZIDlviq0eXqZGT85b2MZAW5BOeTT21o10jrCMquqgJY89ImrCnJoN10QF RU1LYkHkoEPxH+rc0WpoXFJWAWW/ccwbHToxEAEGEKrEiYCSEk85bGWeUrXJ dA5iGeTbxDO50DEuH5a66QTupFt02XK6dZN+lvm/ywX+Oc0/z/LPc/zzPP+8 kM6eOX3x9BmahOnyw/y3i/zzTeJrWYmopSCqKXA9bX7VLlANhYdlFW0u0RYF uKE2N9S+wD+5gTY30H6T+DxP309fUN9TS/gpqpENFURFBa7J4WYdRsihYvSZ wwUdLueIYtygww063KDzJvFhXn3DTTmiKUc05YimHNlUQVRSELUURDWFN9Fn 024101zNtKhmWlQzLaqZFtVMczXNWpv+2bP5n90mfUU/WuX0XU+nxv8hSXB+ DEsZ0+cf25bLtLcuu4P1se3S/MJjVy9fpmi15dXFNdcWIPYbIXrmsCDsOPJI Rvq10sS0Gp2yvnPr1VJih+XVEtbsy1tLUvf0ZW7hO7K9vF16fZxslwUqFZ9O R3YQoIR/olZwh1wR7UZwcGsIsNnh1KVTkirljEgoPHPL2bXt4ilvUaE5SPwS s68ohH9xcwM1TT6gVAEEY1IDwOOIdlfXStsQGDd9FEsxyPb2Q+3gk/UIINWa qpk3zZp0uZXJdzA7s3q8hDg7pQK2SBFM0Xqeoma3PBdK+jZilZTbKgu9wt+W N74Taid1VyG+Z1e55IrN0d2hHmEHXN6FiqHtMJrqMm8enHrCZq2WaelCN7Nc 5rkWZ67y2FToQkK/5SPZCCovr6w9NrtCFtR4QhUxOelq5lGUhAUaB8IMYDf2 XeuWiKioypHemrppiVgkb6UXB+XCWudlC9/EyizUEgozX95We1oMa4VNpEUh vm4iH8FOduUnTsp6gomTRCnqlVXhwO9FdKrAXbd8/GBiT9zV2RWd2aLBLKoV LA/6eD960jlZFeNIFiUUIkeQIwVx1wOZBTduy/XWZjbScYOXZeqIuKK7Prse ETRgZe+wkv+Mb0idihqxnDhlayHITP4Z4qajuCleS3Ym4KU+ZJyGG8CiZxLQ wleUA46eTpBzP7FVs+LaaqIGBZ3ArV/dXBIdLlPZGFFD4Vpb9PDUxazTzJ50 eFC0/Dd9X09Kjd3UifHMJiMhZ209CTXsGzIELWbNVOnhy7wRTsmMS+7RvLT2 y4grobh6MQq0w/GGIT4TCR0oKcaBTKOsnyoI45YwCgTDrjTy6RCHjg9KCytb klKZyCSGCbkbnFohf+vkyjYzQRQfknIVjRDfT4zo/PLioobpY2vzb5UIZCH6 riRCeiqAuviyO/7euk7KjGseEEcbXnBdWyZukNaCTkOGIvEJh56jf/r06ZW1 y8Lu34VkSjEviEBpSRxvcWQ1w58eoCu7I6jl5PXX2ierMp4GHyffz4eilrQX TgLSg7TNx5fllBMx9XH9xvqpoQjhshryjFES9N3UjGVjr2bviDsG65RLhveX eDzn1q5cWVvVJIUsk4cxQ5coUNQWea56IgdVa3iafFZaFgKCh3ibFZFfXMpH vnqdzirCVWvDEi/yWySkfWVtbnYlOek72GNHSXnW1+vZIA9cK57AVqQLZcNP vVyVN9gI58BMIOGbzqUpRktmkmDmSNHbF7EkBFdelWVsmptDTxxZuff9eFmc XQ9OzpURZvLi2saV2S3IgctPknTANjBBiuK2CoM7QWyW7ziTLCtZpzOSPLr3 rVUzGxSRzkw1HjIK+UzWL0+o78Hbk06ORQpRXI+3y2gX1QVMmOqGz22SI9jY Q10lQkS1eFY+HXE355NT5MBvyDyRNzoimo5REiHu+EpWrO4weubkc2dPsWeJ ys/Gxd32z8p016rRU88FhS5wdHWrtLYOqWt1Xg7f7awhzkvYA8xz5kIdlN6r dSrgLxR9J3WE35Q/7CW4gJ10wkKCv5rrKt1vRJjQdqCRvtoQNfeoGxT66paG VPesT8c0EKkl7oa7Rqn4q+ZOhy9WRa1FttmcQC0VY/LUzClX9fLMtFS7CH5R NGzz5sQo3NVHoDohV30vzOjuoaVD3Roajbw2sj+yFsJKx/fc+tTN8q1Q7INv xLjuLQI313FQjEN1063HI62YHo/Cd0N0dmSIDntZ3zZl7KUwNbbJ69dnrdyY vbK+trK8KvNoTV+IerW1cGV9BSuGWCrdEiqnNqnGXulJ/s/s4ir76sxtb2Ui rzOnK8jlnykYjDyQT/Pttqf5OvC7RXXvY4Kr0BPd/xm6/7VeHfkdo93vf51+ OH+hwPe/ns3nz184e4Hufz2PP43vfz2Cp1icoiCw0NWgwWtfs+LW16z/qteJ Cfp+Wdud5NEaCZxP0e7gytrqBUX91G5n+cO2m+6LfEhUAjRaROhYn9aYRo4K cmG6rI3fpVvtWg4zIy0S+toV9oZ2b28V05CvkM6KrAKl03SaksMu7dVWaTal YhZ3aseZ+fkspZ7bl3dfOoEzSK6qw6k+xGEye/v6zlwnJiYlRmBAy0hTxoY0 LY9ptq9lsXxlVSx+llyf0sIbd5IXZnWGJgqnSS6Y1Ag00vh83zpL3zw9yfda C4rl4vjI0rKRB8Oksq7+nDbSM60sqqPEmhQCSeXCXxYiv5QfnjAivpgWX9Tr F30fWEA8cx04pgnR9KMkjVaruapxspA9OZ09mRd/sOgvFfyOv+ZdknS+Mb3p zPUoNjhd2LCZkA2bITZs9s2GzX7ZcCPEhhtDsKHahQ3zCdkwH2LDfN9smO+T DcZJSbFkQnIWFIsP6g97LWEHdPACk7TpSi2OuO+43iSVwnE5Z95qkmCQrtSb VQttSc5VKtDoJ9XWGslIGUunESdYEcm7qMLMBuLCnQnf5p3Dlg/1QuH9dP56 MVSgoBcoUIH5tdUF/HM3E0XaflLSlvohbenISQvRtmPe0MZ7swI0J63dEqkm JZaPJcrVTpOSl9FI5eWVLdBszvbTRNQLCryyqFUfsXd07IAro2/WrXZJS09e 2kEJKJ2TC0+QUJ2OQr1h3tuory7Eol5r39uor2zFo36Pc30lnut79zjXL8dz fe8e5/rlbmO9c2/jvrJ1tctov9eRX4hHfu9e5/zlLpzfu9c5f7kL5zsNvg7H rN7bJFxdXduYX9hYmI8l5HlBRoAICK5ba/NrjxibW5R9bHFl9rLIyGpcuhSQ +E9DtmMxol+BX4j7DbMvYZ8/ipf0w8VdMTB9C9qxEvHTIcWFyBAr1WB04Nuj IoQx7UXKEJS0j5QSHyHuuGuz6ZSTYsjLmpWfEBlFMJSNByI7cIj+O9Luc3r1 3xDdd5SEOKPtvv3R9l+8CSmS7KU++i9X7dWDQ9AS1YWHRksvUrBb7LQaHjHY Z4zA5oVFfG4uMZnCXnNCGRjpfIdO0foyXHBhteMxKW+vN0tVixJblhrPGSfz 2ZO1AsoZ0fR0Jce8cU+Ro1ETYWqSIV07NZtSDjUck9JJTyqDbm413KPqXd7R TDIUElbicIBKO9oKGU39Q9L6plFfuJAJMGMixAph1XQv1NIqJOOcYoJLRd44 WYkZny411ThqIpfDkVIzPzg1WDL9PbrAciNWSjLFO0U39MsRro6yCWnsF0HJ xaKh3UBJ4qH3kRshSa2TAdIOi6ho6YaVNmKWqyeYWQ27EUVfOiMOC0LrzxPx hjnFDyGRMg4lDrmeFJGfWVdyhTjKhrcouRpf7McjvTQQ0l2sifFIL/WHtBOP 9OZASG8OgvRmPNJGFNY8ubptZ/FYn0hujfa0lzDG813YHFoWZ9t23aqIKRRa MUQn9DypweTiZcR3SFHPtvC/egRZ7jlN+Dv+JGtlrXTw2IEQlMcvdOzAPrL0 O9b7An6nOau9Zka08qGyrah1MUmn9U/l/KBU+mn0UdiFvm7U7cdTtzQgdUsa dRjNhQsR5K1Fd+JBoBMP/J3ovQ7tAv5P4qi9EU/tEwNS+4Sf2ovJid0JELvj J3YnAbE7HrHBybti283QGlS1a/hzyWxUeZfvOMFzI88kIpdJo0iJhpoyqGnC iPqmEP7GapsiWQP2XpWoo9Pgy5Si65gO11Ev39Lqif7sbAy6HCkT/ck59cl1 7xMyELnnXGzeoaQ1YuBMUkpnj3ElN1Zi0jUNnbue1Y/CsiT8aL9TAGrU2ZcY lxFV97ByNaIOMruoNXysq8limWFsY+xJH70WRqtKMwWeNYETac9Gp2E2VVAN VGr2DgdmitJOpUX/0vfo8Zlt34Ri9gkp3zhZoykUNR8WbsmMJgH2cx6WqmNV remBVU1KtlASFUXIyfG+B7oSeUA3rBlKf4zCcf8QceymFwdwlP4ekYvOJufK CXozOPs14c4wqDdDmVPjDODPECVQR7ozWFmPUF6iuUWr5rkvyD/5LG1hOp14 OhM4r0g6+3dfGZpO3VdFUUp/60brfjytCfyVJK39eywNT2s1gtZqwATnH9eL 5VqNY2h9iiB5dHU4efzs5hXhhhaUOXasPf4kiRAZx6vIMY+KQa5W+kqEyLiD 5iygujc9CcEhk1VSoXdpTKWLZ44qpdxzgsIEbZFpUpt9ZImFPX5jkYKW9C6h zw3NhKTXAWLobTot/nE31ML1Gb5lwRQ+0pyPKVP0WU73VfYAztroZhCyGnKb 4FR4oUMYQZDPpNV7e9RY7lmbaB8SqmagCYVBSbblayxGII1akn2NGlEmnYbd TKN23eZynXGmFxFKNUVVCIQ4b1UkMjJXpYcKBOJok4UUHfSdHJTQ2L1wVsde k5Jmdu1WxaRulddmkLP8pFYgS07zUbbVrph3tzgmNbjsRfA82yrHMbLEedvj prw7eDC3Y5hdiGb2hBLFolbAaKz76YRCr04odO2E4ajudbrSL92B7ioEukuF MpQo4Si7IZqtNDDIGxNku45wUoTomc/Efe8ullRFRA3eYooWzsVWw57DMVXw u+6fC/fimO+l7zEqmM4kiyoYP8+XR4//sGvVwwj/6B7/USicPXdumuM/Cuen px++8DDFf5wr5MfxH0fxjOM/Dj3+I7DjadscbaqkoZ33RyDof46ML4h00A7s XRRZcOHcNY7cjjy6641H4nYFml4tg+KRWO9N98mwWNFMtwZVc2engSfkM6B6 regiflJZhkaOd2I8uzF4CLz9/V63GtH8HHAEOp2dAUdgsuZa9XQUHwYcZzEn aDN1ZXfQuO9Xlg2nrbdMf/H3CWuYRpuUeb69k1c8lZ2z4WbRt9wbPWg15BxO QBNfaol2tfuL/dS1A6YCivGIsgAk0QxP81GnDDSl3MEV6KcchSr+o8Ah4uqv M5qmVVQlZvKijMzLei1dBDcYR+YKfp8I9xC93+1Jw+Kx07DbnQanJw2bx06D 040GFQkVoKFrLFTsEUJSLxyezSMmXlM/I9jAZKp1Mp4TEb0Zx4ku3RrFicV7 iRO7PTkRNa5jONFtgEdwYvNe4oTTgxOD2GM97xHSrgcxYIR34flkNgxQpIkD 2ZPTj5g3Rk9UvyeLIyeqYY6eqNpxE1U7FKI6R01V5yjIivrwSPuqfRhEHX9f HQJZe8c9r/YOYQDuHf+8OhSyjnte7R3GADz+eRVFluMLZe/LTYOlChXXrzlL 68KTknRIEkILk9fS1yhLdtq8Qf9qwlKmaEQg14g9oOmJHEkHAyLXMBMhVxsc udrgyNWSItcZArvOAOh1+sOvPTh67cGZ106I3BDMaw/DvGT47Q0+8vYGH3l7 yXp2b4iRtzfMyEuK3+Ajb2/wkbeXsGeHGHl7w4y8ZPgNan+OUEC7ORqKzS/8 QeS+Vw/v5soOOoDu2YuQsNJ5dIT0pW/2IiSsaB4dIX0pY70JCQlWh0hJ51BJ ifriqPqkH5m3NyHH2iejJCWsOB5dn/SlXPUm5Dj7ZLSkHOM86Us37E3IsfZJ P6R08ZKO2eF7ha/HBLAn6pPChYF3+F6EhHf4oyOkrx2+FyHhHf7oCOlrW+xN SGiWHCIlnUMlJeqLo+qTUU73iB3+KPtklKSEd/ij65O+tsXehBxnn4yWlGOc JyPdFiN2+KPsk35IiY3hiN3hn+iXkjgf+Ig+uTjwBt+LjvAGf2R09LW/96Ij vL8fGR197Ym96QhNkUMkpHOYlER9cUQ9MsqZHrG5H2GPjJKS8N5+ZD3S137Y m45j7JHRUnJ8c2Sku2HExn6EPcKU3B8khhLA7Kbjjg8Wo12aZ2LSvsT6x2WD HqN3JsSNSnwPVomvqW/wfX50y1BenIG7Hm813VOcvN20d05bvqNAX3p3N9xh lMpnN7bXNvsjMt4JcGgiPVNLmEjxrjuRPYOwo4nMtuJz+ET4DGRb2eWQ/+8w feneNhVZQSFQQajDRQVcSL+ySg/qzMzMzK2tbvL9tBlKgWKo0vjDk7MrvrLG W1ysAw1bsuWK1zQ9bvPB4g1ZvqGXv6sjXN6xW+3JTJT/ZpL8U3H9GTVsY/2Z s63lQGh9vx0aHLe9OlT2wKH3lsAreW+J8qHe6jYRUcKrMXqQG0Vj2bAbtdt8 EbuB7yP9dZPkquqjv+OS1HF3t4L93e9K5amMggmx3053nf7X2n7eoFq3uqQj I8m48I0KgbtvVGhjwj8iRFltRNwNLMuiQPdluWdSrj66NS5+fzTdevFQevXi EXTqxeR9erFHl14M9uj9lHeD0ys5FFBZppvrW52GvMeWutnJcWoOvm2QwivV LZ+O3WlVTOUiQWUoCEGmejco25DTVoUoiF3EXIWDpqi16q6zO91DiIkXPSXC JhVMLLUFRMqb7VzViQ/YE1haN6x4LBMMdxfRJ2KSIUWO/Ww+GIEx5NDvWya5 6N8V3Fcxy4Jk1n4XZiVY8l1mhbMMHSqzEi//EYzyr5iJOeV04VQ3YSgw+hPz SYrzxyfPM87OIU6nOInwMKbTYc8k5xBn0qHy6chn0v4hjqguMufzaUTJjIm7 1S77bWwMpdxvfdkIQ1tu0kBC2nKdavyW68/tOJgLaJLcjr0x9a12cYjuJ1jF u+WJ01ENr+RdRl9UeGb0CJqZ8ZTJbvNUfy0zyKsCj+xYbePcxaxQZuJ5MWCn RfAiLt3l84UXNxKs3kl5EV6/u6hMw/PiYn+sOH8he7E7Jw5zhjy/OHGY8+P5 wQl1P8XQa7xW0VBr/HOBRT4e32GXeh3jo13qn0uyvj2XdIHzsWS4Ed29E5+X LBl24ddZcrQL/3MJZvlz/U/zYdf/7tPmecmQw5w09y5D7g/no24NeGU680Fk o271f+tbdF6tyCPoViOQWKtV1g6gw91cG5Km2rHQVOtKk5cLfph+OlKKat17 CV8NSJCcguXIqRdnd6O0w0xRuHx0CHvWC2IvGGdOR5sTjHe8w6jsm5Vnz56/ 4J0oTF/PnD6jze9e5ghtAuN7ybVpNbsj3hXk6zBXLXvQoS+5igq+/Lhqt2KZ 6r6K5+mtYXl668uRp7e6MPVWAq7a+C+6AHIY/aNhxy9pvfUOfK0rHcWisVep GNO5glG1TYfvDRWXi7zTsejozTbeWbVyMWQMKF+5ZPRzd0VXMgLZ7M29oRgs 0p4PymBzr2sqTrwfTixtiJyUyQ3rUdJXH2OeCAoevgRe9+2fgY+GU1aICXG3 gRwWE8J6WzImxOlu5Wq1uttlie1hFRd3JCU+geb0qBGZclE+WrQJjOtdX47Z KNmmWnW6kNPrUF0kyE1s3VfkhIsnp8Yd1dNyKdzaN1uch7pcc2yj3DBQivzU DONcNtfKnzpl2M22VbeeY2+FiO4cascMXHqVeMuM+OBe2jP94yYs4PlSF8fu nDS6unC367Kp8zf5ykn8zcaMsji/4Wy9J48fmEFzh8FjbzQrHvc61ouroNCz n6YTrvP4aL9Lr3Vd5/VeS77Ud+m12DCu4+w1d1MZtNd8AWf99VrcxuR0dobZ mERO8eQ707Abk5tzPGZjwvthNiaZIj3xzhRDTuKdicjx70zh3hl0n8n6eijx VpPP7qm9Jvlm0xpiuwmVHXyS+UeH7tDYz0xDLS2tGk0GjHSN1NuM39NoYA6+ p/n6Mvm2ls/WvRUy+cbWSrBIHll/hre6gfrTqybQnz2ddePwKQRQ6j4YE26i +GiITdQ3TJLvo12HSfxOek8Nk/DeOtAw8aoZcphEbtV9D5O4XbveqQ21a3dq 7QHUyUE3bTTXddPG+6E2baLm6LRJoqbbnk19M5RuKHrny0439I+CkPTqex2/ j9JYGVI3FOPluHXDQ+Px8Bumr5Ze65e/W5PGbHVqw+qK3IvHriseWi8Ov5/5 ahmqF+N2oap1c5hdCJ/3rTkOugWhra5bEN4PswURKf1qjYPuP0RKt/2HemVI nZF7ZgCN8fmmL/pHxaATDbX0oS/62ozf52hADq0v8rAcSFu8B3TFM6eNp0yj ajdOtQ1rr2G3TGPf2ts3dqy2kzNOn5mgLsrrgY999PrwmyT3+ki0Sh8+vRZq PV4gf63oH8GRu6+Is+6fTREtDc81t9JpqqQ4Oia6FReokuJh8zR6xg6lumtz tm/VPXrWdlfdW5y84NjXYL9nd15zguWOGF4O0hqgQRdoYEQqv9ZIwe/K66ci OBTj2zjbD6e609hLsoubFz26pn+rhT3MCZEn+dtRTsv/KGdIy6wf7gxBA4c/ Q3xUHP0MoeZHP0MS1Bo5Q4Y+77H78Rp9/srufv4OOvR5fCeW3X1tdrFR2cP4 L2j9+HyW3T3/GqNu0T3sdJ+6sdPZMw6s9j5fg7xj1uyDXG4oYZ66ZHixlIfB SORQHz59Cp5dl4yRCvOj4VpAmB8dEwPC/GHzNDJw5O2delObws0KR06UMWZL LXM3MC9pQmNK+S01b683qd1axF3lVqNqtcxKuxRuJfFqoSXNKxaNK+XbO6aB xmjK7ZhtlM0adf7jgWlUyg1wqFa+ZaiKmAs5+vym2bJ2b2NC8oe7pGd30F3u destwcidVg7fij+ECdrxXW0nmGXtljDLGyXuffcCOyxQdMjouzVJxGEYdCNm TwZ7ZdFK7H1L4L28Dmq6901LO76r76KQVxfcHTXyFxMg77tjKwp5dZPWUSOf T4R8pyf2naNHv5MU/1ov5teOifkXEiHfi/m1Y2N+Evz3ek3bvWOatucSId9z 5JvHxfwk+Nd6Mb92TMwvJJq3PblfOzbuJyFgJJstf5mckNHsVyPZaUePeQIx YSTb7OgxH8FwSbjHjhb3UY31ZDvs6PmeYJEcze56CGwfHvdkW+vouZ5ALhjN tnoIXB8e92R76ui5PoJZemxcj8QdGvOq3Tah9Zbb6rVRIN25bbfLNcOxnjMN e9cot/acrGE1jJ3bbdPJciZalDygz8iEVSnXapzJlg0KDleAPzc69R3SsXeN A7tVdYIxtfSV4Bd/H06uEZlLkFNyJs3EsReZmFylETYmdZaQEebKwhXjjW80 vALbC9vrvmJZ6ikqurFwOePan/DL6lps6Qe6BonlnGZ2ZurctaJKg0y2hpnc Q4XCtaLK9El/ehoFr2sWiJOt/LWiv5ZzgT90t+N2w6AQxqAwDAbhJOfh1mkU sIkqaaXh6UdVlG6Wa53Y68rdWYO5GTPsogNqediJGRn6IvqMIByAGzP4CskG X6GvwVc45MFX6NlLXQ2UIxh8iTHoZ/AlrjQ8+NplKFRDmjIJzckObxVxy34h wsjqcSXCKtmwJUb6bqMnFmjim9SX9QPKd629M7uVZod/TDVbdtt2cvsjbCNf yOcvXDiXyuN5OPAvnun8uUIq//D5h6cffvhcIX8B5c/hv1NGfoQ4xD4dp11u GUaqat60nu1Srtf75+lz5rQxT1PCoih2hyQSsGMPE7ReruxjpnDa/curV42K XW9aNbOVM4zFqbn1q8ZNs0Vp++mMwGDmPFqpWrnKcxOnz0zQAd9ip1ERlWLW VklGIsmnXjV2UQ2f6U08aO1iPhobW9u8rk9QPjES0Gg2GpV99MtpEtZovVif 3Zi9smlMTuovs4b/t1b7ViZTjKsGMl9cNZj5wa9v2lbVaLbwRq0vJax2LdNx vEoWl1cWwu3ylzSXSuatJn1Xt2+a3kcmhD/FXbyqmvz909e1GmghwqpVN+uc Zk2tb24VKA+hNGuEqjLoR2RFVr1euDCqmi4OX9EICLMaVaAzbCXDU7Nj7aGW 4VkyJCpUUIy6utUuYXxXeU5D8tpBjZX9wAhE8RIfuVdkNQ+a+GLXwMxV85Hn 6HEvUOPnUB99/2+YB7l6dfRt9Nj/z+bzYv8vnD9XOPsw/l44ey5/drz/H8VT LE4ZV+RWXzWdSstq8u07wW0/K3b9rH+rJ0PJlLGMrbTV4c3eaJbJtaDhQEx4 at9sGBSGZTVrpvvCKDebtdtZ/pAEAr6Zx7DRvJQQSDwgO0mFbv1p0AVAU1x4 05Tv0q12LQe5Ic1IVu1Kp2422uLSIPxfk/DJw4EUBGzRZjtnlGtebZVmk1bT lm08KD4wVte2lucWSlfX52e3Fkpzc4QPt9eu5/aNfSzKNdMx3HWV102uqtOs ltt4RdjUbYc2JpcfTujOoWGuExSOX8lSkWX5jhZNm3kUP1gS4Rsb8IvTJl8O 9pnBbzW7XBWv0Er/N+Z1Cb9NntTNQ5YQzd2Ix6fnjW5J8el2AXgQn4N4fHpe RZYUn273lgbx2XHxOQzfJOMoPJNUU4Mq54dtOI3A3m855XZORrk8HZ/FLQbp aKyPewMaP8f66PJfjn5CAsw5B81RtsHyXz4fLf8V+CfLfxAEz184N032HwiC Y/nvKJ6d/JPLV4zzufP0yytTqQ++9M9mPvObL0r9xVckJ5nK3UpQ7sxuuT19 Zqdj1apn9iqVqbO5Av17JmiDPBQlZPyMn/GTOjtdyD+YfsD46lddPW5Uxs/4 GT/jZ/yMn/EzfsbP+Bk/R/y0m/elvoR/oe6nXg94gYQXAd4D+Cr5+30AshF8 p/z9xYBnAB+Tv38l4J2A17xA/P5CANkWv1f+Pn7Gz/gZP+Nn/Iyf8TN+xs/4 GT/jZ/yMn+N7ytVU6rfvT6UuvyzF5/9kA/j4K1KpXwZ8DPBuwNsA3wB4JeB+ evfyVOqDgB8GfBugBlgDrAIuAl4A+ATq+z7AdwK+HXAbYAKWXibaKgC+iHZ/ GfAdgPcA3gVoA3YAC4B5wEOAlwG+8NJU6mcB3wr4ZsA3At4GmAFcAEwDCoA3 AF4B+KuJVOpXAT8L+AjgAHATUAZsAR4GvBTwDydQN+DfA34R8CHABwDvAKwD HgUUAS8ApAD/+yWp1B8CfhnwPsA/B3wTYBGwAMgDHgTcB/i9F6dSvwH4FcB7 Ad8O6AD2AY8Dvg7wCsAE4FP3oR8APw/4ScB3AiqATcAq4KsBrwL8369Mpf4c 8DuADwG+H/DdgCcBVwGXANOA1wA+/6JU6ncB/wXwAcD7Ad8M6AC2AVnAGwCv A/z+C1OpTwN+CfBRwPsAFuCtgC3AVwNeBfi7rwAPAL8F+FHA9wC+A7BKBqSU YaTveNHUhevGTPeQhMm1jfmFjYX5TNG4m87Q5+lUIB1Kqo9w71QwqlyUq3aa RoFq93wVU8pXT4ToGOkdu1U1W2Y1PQARV1fvHTI6jSEIubxw9R4ggTIfDYL8 1j2BfHsg5FfuCc7XBuP8yj3B+dpgnL+8cA/gvmcONuLvBdTbg433ewD12kBc X7kXuF4biOur9wLXGwNxfeGJewB18wahfhfF5tdWF4opgTOFSJVbZs5uFkCG RlS4QF4vkKcCd1KSnoRxPezHn1JYUsIcypXD9SeNJUqHKavUm1UrnSoWjYrd vO2iaLRto23Wm8bNcsvB2wf1x5gTzTopxbVSud1uGen27aaZ5vue05nrxFK6 Od04WZnOinAV8RfjpPydevRRr1sj84wHomM5vknk3k+Bc10vS4+KP6FIqlTX CKzY+/dS/iAPedF7IhbkqiEm5ETI1XRPNiwlZUPcxQf9sqHrZQtRbNiXbDDc 5E1Ou2U19oy0jclGIT/0UvySRfksBZxRwSzFMqXdCjUGiujE7uF1qdEF81FV qZFFGrq1JQlyTA0aRpkaMoKT9f+fgr7++ZcL/Z/O7P8SOv5fAD4J+DDgvQAL sAQ4DXjJK0T5z738uKwW42f8jJ/xM37Gz/gZP+Nn/Iyf8TN+xk/MQ5ce+K0z 0i5h5I1pz56xK7MWljoNq63KGAUjH1EBGy7o+3Ox33ORmM+VAaRHFW6xmGrY yGScNfKxNaCEJMJgyytnXClkW+V0hvX/vwR7TpLD/iuFz/+fQr//acBzgEXA LODNgIcArwN8EXr/3wM+C/hJgAO4BHgEcB7wRsCrAX/7slTqC4A/APwS4F8B 9gEXAeekD8ArAX9+fyr1OcAfAz4p/QGuA94KeBJwHvBq6QdwAvASwF+/NJX6 X4BfB/ww4DsA7wGsAq4ALgIeArwc8EcTqdTvAD4J+F7A9wDuApqATcApwOsA rwL89xOp1H8DfBzwM4D3A2qAa4CnAF8LeAPgxYAvvgS0AT4C+BHADwF2AGXA CuASIA34wouBK+B/AP4l4EOA7wK8C7ALeARwGnAS8Kf3pVKfB/xnwK8CfgJw F1AH7AOmAFnAawEnAH/2lanUxwAfBvxrQBNgA94KWAGcAbwQ8NcvSqX+D+Cn AR8FfD/g2wA1wKOAPOAhwJ9iHHwe8NuAjwN+HHBb+gJUXyjHyT+2Z+zWcNxk jN0ajvuUd+zWMHZrGLs1jN0axm4NY7eGwd0aloZ3a1jqy61h30qPPTbGHhsD emzcCHts3EjosbGZlA1xl7j3y4au18ZHsYHuoGf9n2L3v4r8t18pYvjJ9/89 gHcB3gmwASXAurQDkA9ABvBqwN9Bz/8PgG8ELAFeA/gT6PSfBXwG8EPS//9d gG8EvBPwNGAV8ArAP9wv4g8+BngvwAGUAA8DpgH/FPB6wJegx/8x4MMAG/As 4GnAo4D7Af8RuvuvAX4G8O8APwz4VsA64DWAP4K+/mnAJ6Re/0HAPmBK6vF/ Lf36fx3wUcA7ALOAlwNeDPgr6OZ/APh9wI8C3g1YBzwAeAPgdYAvkT4O+A3A rwM+AmgBtgBXAG8EnAT8DRj+GcC/AfwE4H3Sh78NeBPgHGAScArwRejkfw/4 LOD7AHcANwGXAG8BZAB/A538VwAfA3wE8GHA9wHagDnAKwBfQP/+JeAXAD8P +CDgnYDHAa/9CtH/r/wKoetiPMt9p5/7nFLRSWzj53TsUHZ3tcCYPa2l1GVE tZV7ZtduVUxskXuT63ypBl365LvzKZ/JFNVGSz5KNXuH7mCbxCeE5IWzYlL2 TXgM3SJ5b92s263b/ty9ial21/oA2SJjsrDfye7q59a3VFx+5NiFNLx8cFcE OiHfqxPyCTuhe/7mKJZG0y8loyh2AvVwtulgrmmugfNMa2z3sI/PfB2b8psz Xwda9mfURr2GbKwk/i7ycMtG9TaTJPQOtCWagNCwtTa/9oixbx+QwNAym7Vy xTSstnFgtfcNhZFBxY1Ll8jHLDDbMLSom0ut9i3R1dytXIzrN0K8EZIoMMJb 3/AXL+LJkdyUFOHzYH8KoqL3c8/Gzpu6+hXbutrTd/CNhRd705P4Yybbyge2 9sj1zH/nCxq6wtv69dHIKKdRPY9EIeL5hbhFDN+dcuVZcb9RGUOVqCJPy45D P2c3rwhnSLDE2bd2yYXRFd1oIPEfrZrujppi/j6aCosxT8SIMRahLcWYMtc4 gOvpKDxPnf0au54qWm9E0npjxLT2L7SNQmYDrY5GaxSlI6azfxl9FCI66GQZ PTj0Nwkn0l7SB1bVbOTcCytSchd0rD3ov7fapmizn7seNB0tMe4hzEXT+1bV mk4rLPvDsev9GCPE0RE4Bjm8wC+xjPCOV7NtfRfCuPJ2P23zFrg4lRb9S7ic RcPbaWnB0PbUqYKQlwLqn2ukMGJoi77TYIaw8ZtM+rOYBC4aLkRYURpROnoC eVa3swi2V23mJrhLjZmtRrnmt7oAG01SgpyUMthsRNubqGOSdt2IerS7Tc9d 991mnFXmCnl1pp8V5xQrrgumGUWD2RZd+qwqbXilgYlRM2/GfTId/qRevgU5 A6/ZfT/6s0L4M++TokFXx9H1rp3Gsw37oEFTIqKSfAy6TcfsVO2QUOixNTwp VvCG5gNfmEO3rkD2FiKZkidyeSlRyL+pq1n8H50spMQVPNrrODHDvX4kcOOe utona2XXugkcrggauETQvUtI3A/E+v/XQAd+4YTQ/ynH35eg1/8R4DcB7wdU AAXAFOANgK8BvAjwKej6PwDYB1QBTwDWpR/AfYBPQb//IOAHAO8BvBvwDYB5 ee7/aej1PwH4ccB3A74LcIdyEQBeBfgM9Prfl2f8nwD8IOBbAOuArwF8Hjj/ T8BvA34L8HOAbwGsAb4W8HrAiyYEbQ8B/lbG+v8e4H2ANmAOcAmQAUwC7gf8 GvT9DwE6gBuApwHfAHgt4E/kWf5vAd4PMAFlwDSgAHg94LPQ8T8s4/jp7P4d gCogB/gH6PR/C/gE4FcB/xZwC/A4YBHwWhm7/2oqB93+C4DPAH4EsA+oAN4G WJM2ADq3fxDwVYBXAr4IXf8XAd8MuAu4BXgWcB2wLu0BZwHTgDcA/gA6/49J e8AHAN8OeA7wLOApwAJgHpDj+P6AmCouPvKmxkGSqXEQmBoH/qlx0HNqLPmn hnetZdK5sZRwboSp3deo1Wjla7WU4uBdpJXy3bGV0q/f6qlgRGKnqEumavRN XVXvyxvd6FNXc/lLe514oyeVm0NSuTkwlY7FgWX+JX62bdetCiPvCCNY6ALX yfllcVur2l8zRbFzu1aY5AcCPTqvYTcwsM2qVW6b3Y8BZK8ZqSiEN7sgLGS4 CFvXZlesu/RFX0ijE4xUJNJLgyDd5VgpDuml/pHej0X6iUGQjjPSdUH6if6R vsFIF4sGZGGzZTYqpmPQO9FuW0RBenYEOkGyqXhQL6AKzaqYIUXtaxZCJTIy SJMNdMSo0B7gaUFRUyWKKCtCjShcyBg+S52ndvJSAA2nVa7EKK/RetJDEUYY hX1erIvJqdk8FGoiTQ4DUBNa/1J8mlhzAmYicQwQG4ccrZ6CsloU47up3iPQ ael+79o+9xL9lzkyWsxjosXc18y00Eeh37QPbIPOjBt2W0Ye86XqtBgZDyjK nd5kx+rTPbqwu+I7GrK1HhwNIVH9dxSEmIN134h6r3NMVHe8/htR9x0XJcJj MH0L29koCGkc0zhs6ONwc2ttY6G0uDJ7ufTk7MrVBT7ZIf3/d6A37t4n9P9n 8M/noNv/oMz9R3n/1gCPA6YBecDryTYA/f7nAO8FfBPgHdIGUAGcAeQArwJ8 Enr+TwLuAA4AZcAz0gbwJej4fwj4KWkH+F7A9wBWAV8H+GeA+wCfkj7+HwC8 HWABnpA2gM9Br/9j7dz/hwC7gLOAM2TTAPw/6PR/Avgw4F2AdwJWAVcAK4Az gBzgnwB+Fzr+vwD8IOD7Ae8GHAD2pR1gGbAEmCafAej6vwD4GcCHAT8GeB/g PYA7gGcBbwdsAV4D+DR4/F8B/wnwccBHAT8mc/0pOwH3w/gZP+Nn/HzZPGO7 4dhuOLYbju2GY7vh2G44tht+mdgNRUSBHAM7NbvyLKXmM1ttB5q7onmVfCc1 b8bSc7zi1wqKCSf0aJfEKyE7b/ipN/zekX4/DvPGI3NzQ/m72o3qTkusmBo1 jeMhp2GOhJxG+hhlwvEzfsbP+Bk/42f8jJ/xM37Gz/gZP+Nn/Iyf8TN+xs/4 GT/jZ/yMn/EzfsbP+Bk/42f8jJ/xM37Gz/gZP+Nn/Az6/H/rqp/lADACAA== --8323328-1542613921-1038880434=:519-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 3 09:32:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JA3U-0000Bh-00 for ; Tue, 03 Dec 2002 11:13:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 11:13:28 +0100 (CET) Received: (qmail 27223 invoked by uid 0); 3 Dec 2002 08:32:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 3 Dec 2002 08:32:22 -0000 Received: by moria.seul.org (Postfix) id 32E7315E79A; Tue, 3 Dec 2002 03:32:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D25ED15E79F; Tue, 3 Dec 2002 03:32:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 4EB2E15E79A for ; Tue, 3 Dec 2002 03:32:20 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212030832.005c; Tue, 3 Dec 2002 08:32:00 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:[f-cpu] GCC 3.1 for F-CPU port From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Dec 2002 08:32:00 GMT Message-id: <200212030832.005c@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Nice work !! I was really interrested of the code size. How much instruct= ion for a fonction like printf compare to x86 or sparc ? -----Message d'origine----- De: devik A: Date: 03/12/02 Objet: [f-cpu] GCC 3.1 for F-CPU port Hi, there was a lot of discussion about ISA. Lets create assembler, emulator and compiler and test it (boot linux kernel for example and count cycles it takes until /sbin/init is launched). As maintainer of part of Linux kernel I know that if I want to bug people with my ideas I should also do something. I created port of GCC for F-CPU. Just now it compiles rather complex functions however there are known bugs in stack handling (pointer inc) and some others. Also insns other than add and shift should be add (just now gcc uses its libs). There is problem with jump optimizer because it needs labels tied to jumps but we have them in registers. Just now I suppose assembler to handle it (ineffecient). Also conditional branching is not tuned - it supresses loop optimization :( But at least something to play with :) Test: long f(short a,short b) { short i; for (i=3D(short)0;i<(short)10;i++) a +=3D b; return a+(long)0x100000; } ; FCPU ASM; CC by devik@cdi.cz.text .extern f f: move.d a0,a3 loadcons.0 0,a2 loadcons.0 9,a4 @L6: addi.d 1,a2,a2 add.d a3,a1,a3 cmples.d a4,a2,a0 jmp_direct.nz a0,@L6 widen.d a3,a1 bseti log2(1048576),r0,a0 add a0,a1,rv jmp ra ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Dec 3 16:25:50 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JEX2-0000DF-00 for ; Tue, 03 Dec 2002 16:00:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 16:00:16 +0100 (CET) Received: (qmail 4116 invoked by uid 0); 3 Dec 2002 11:25:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Dec 2002 11:25:53 -0000 Received: by moria.seul.org (Postfix) id EAAE415E740; Tue, 3 Dec 2002 06:25:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD1FE15E795; Tue, 3 Dec 2002 06:25:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 636AF15E740 for ; Tue, 3 Dec 2002 06:25:51 -0500 (EST) Received: from club-internet.fr (flashmail-5m.cs.clubint.net [172.16.20.64]) by relay-4m.club-internet.fr (Postfix) with SMTP id 9031FE153 for ; Tue, 3 Dec 2002 12:25:50 +0100 (CET) Received: from [//62.212.107.173] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 12:25:50 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >Hi, >there was a lot of discussion about ISA. it is one of the most discussed subject since 1998 :-) > Lets create assembler, emulator and compiler there are several F-CPU assemblers now. even though i don't know which one to trust :-P everyone with a specific syntax, unique features etc ... emulator is a big problem. it will take time before it's completely solved but i am confident. compiler ... well ... you seem to have taken over the past efforts :-))) > and test it (boot >linux kernel for example and count cycles it takes >until /sbin/init is launched). i don't think that it is a good metric. On top of that, there is no external HW ready. However it can be interesting to code and run the =22primary boot monitor=22 (see at http://f-cpu.seul.org/new/F-CPU=5Fboot.txt ) and start bootstrapping stuffs from that point, making simple =22toy=22 or useful software, etc ... >As maintainer of part of Linux kernel I know that if >I want to bug people with my ideas I should also do >something. :-) >I created port of GCC for F-CPU. did you start from the existing (limited) code ? > Just now it compiles >rather complex functions however there are known bugs >in stack handling (pointer inc) and some others. it's just a matter of time, i guess ... >Also insns other than add and shift should be add (just >now gcc uses its libs). ? i don't understand what that means .... we can't do boolean or shift operations ? >There is problem with jump optimizer because it needs >labels tied to jumps but we have them in registers. the 'trick' is maybe to use a =22macro=22 and the instruction can be rescheduled by C=E9dric's assembler ... > Just now I suppose assembler to handle it (ineffecient). >Also conditional branching is not tuned - it supresses >loop optimization :( it seems that you do not use the same set of conditions as is implemented (LSB, MSB, zero, instead of greater, etc.). >But at least something to play with :) >Test: >long f(short a,short b) >=7B > short i; > for (i=3D(short)0;i<(short)10;i++) a +=3D b; > return a+(long)0x100000; >=7D > >; FCPU ASM; CC by devik=40cdi.cz.text >..extern f >f: > move.d a0,a3 > loadcons.0 0,a2 > loadcons.0 9,a4 >=40L6: > addi.d 1,a2,a2 > add.d a3,a1,a3 > cmples.d a4,a2,a0 > jmp=5Fdirect.nz a0,=40L6 > widen.d a3,a1 > bseti log2(1048576),r0,a0 wow .... uh .... > add a0,a1,rv > jmp ra anyway, that's impressing (particularly because i am not sure i could get till that point ;-D) i have put the sources at = http://f-cpu.seul.org/new/gccfcpu.20021203.tgz YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Dec 3 13:08:56 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JEX9-0000DF-01 for ; Tue, 03 Dec 2002 16:00:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 16:00:23 +0100 (CET) Received: (qmail 17032 invoked by uid 0); 3 Dec 2002 12:13:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 3 Dec 2002 12:13:14 -0000 Received: by moria.seul.org (Postfix) id 5816015E740; Tue, 3 Dec 2002 07:13:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4CD4115E795; Tue, 3 Dec 2002 07:13:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id D15C415E740 for ; Tue, 3 Dec 2002 07:13:12 -0500 (EST) Received: from homeworld (81.50.64.244) by smtp.laposte.net (6.0.053) id 3DDAB9480019BDAB for f-cpu@seul.org; Tue, 3 Dec 2002 13:13:11 +0100 Message-ID: <002301c29ac4$c333e1e0$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 13:08:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Very interesting... but why 'short' is 32-bit ??? (I can see ".d" in your generated code) ----- Original Message ----- From: "devik" To: Sent: Tuesday, December 03, 2002 2:53 AM Subject: [f-cpu] GCC 3.1 for F-CPU port > Hi, > there was a lot of discussion about ISA. Lets create > assembler, emulator and compiler and test it (boot > linux kernel for example and count cycles it takes > until /sbin/init is launched). > As maintainer of part of Linux kernel I know that if > I want to bug people with my ideas I should also do > something. > I created port of GCC for F-CPU. Just now it compiles > rather complex functions however there are known bugs > in stack handling (pointer inc) and some others. > Also insns other than add and shift should be add (just > now gcc uses its libs). > There is problem with jump optimizer because it needs > labels tied to jumps but we have them in registers. Just > now I suppose assembler to handle it (ineffecient). > Also conditional branching is not tuned - it supresses > loop optimization :( > > But at least something to play with :) > Test: > long f(short a,short b) > { > short i; > for (i=(short)0;i<(short)10;i++) a += b; > return a+(long)0x100000; > } > > ; FCPU ASM; CC by devik@cdi.cz.text > .extern f > f: > move.d a0,a3 > loadcons.0 0,a2 > loadcons.0 9,a4 > @L6: > addi.d 1,a2,a2 > add.d a3,a1,a3 > cmples.d a4,a2,a0 > jmp_direct.nz a0,@L6 > widen.d a3,a1 > bseti log2(1048576),r0,a0 > add a0,a1,rv > jmp ra > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 16:32:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHb-0002K8-00 for ; Tue, 03 Dec 2002 18:56:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:31 +0100 (CET) Received: (qmail 32545 invoked by uid 0); 3 Dec 2002 15:59:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Dec 2002 15:59:19 -0000 Received: by moria.seul.org (Postfix) id 22B8F15E740; Tue, 3 Dec 2002 10:59:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E42A515E794; Tue, 3 Dec 2002 10:59:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3C08D15E740 for ; Tue, 3 Dec 2002 10:59:17 -0500 (EST) Received: from a124-137.dialup.iol.cz ([194.228.137.124] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JFS6-0003V3-00 for f-cpu@seul.org; Tue, 03 Dec 2002 16:59:15 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JF25-0000Sf-00 for f-cpu@seul.org; Tue, 03 Dec 2002 16:32:21 +0100 Date: Tue, 3 Dec 2002 16:32:21 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > there are several F-CPU assemblers now. > even though i don't know which one to trust :-P > everyone with a specific syntax, unique features etc ... :) Are there reasons other than personal ego ? Like if all wants their own assembler ? And are these documented so that I can select one ? > emulator is a big problem. it will take time > before it's completely solved but i am confident. I understand that it is a big piece of code. But is the principle so hairy ? I'd expect relatively simple code ... But there may be things I'm overlooking .. Probably memory and cache simulations are not so simple too. > compiler ... well ... you seem to have taken over > the past efforts :-))) I didn't know about past efforts ! Huh... I could starts from that and not from scratch then :( I was learning gcc internals whole 3 days until I coded it... > >linux kernel for example and count cycles it takes > >until /sbin/init is launched). > > i don't think that it is a good metric. > On top of that, there is no external HW ready. yep .. I only wanted to see linux booted on f-cpu ;-) Probably because I'm familiar with large parts of linux and wanted to try to understand arch-dependent parts too. I planed to stole HW emulation from bochs :) > However it can be interesting to code and run the > "primary boot monitor" (see at > http://f-cpu.seul.org/new/F-CPU_boot.txt ) > and start bootstrapping stuffs from that point, > making simple "toy" or useful software, etc ... good idea. Maybe it could be start point to do other tests. I wanted to port linux also because when it "runs" you can benchmark other code on it (like to compile gcc on it). > >Also insns other than add and shift should be add (just > >now gcc uses its libs). > > ? i don't understand what that means .... > we can't do boolean or shift operations ? no no ... :-) I was just be lazy and implemented only mandatory patterns like movM, jump, jump_indirect, call and a few optionals like addM3, shiftM, extendM, compareM and all branches. So I wanted to say that I have to add all others like logic, other shifts, rots .... Also recently I found that I need reload_inM and reload_outM probably because when I tried to compile "vsprintf" is crashes when reloading registers - I used gen_reg_rtx in moveM which is unfortunately not allowed when reload_in_progress is true. Have you played with these ? > >There is problem with jump optimizer because it needs > >labels tied to jumps but we have them in registers. > the 'trick' is maybe to use a "macro" and the instruction > can be rescheduled by C=E9dric's assembler ... I have done it exactly how you said. :) Problem can be that we disable certain otimizations by this. If you'd be able to instruct gcc to emit address load together with jump it is able to do cse and factoring the load of of the loop bodies. This is hard to do in assembler because it would need to redo loop detection and expression lifespan analysis. I've seen something like this in ia64.md, I'll look at it. > >Also conditional branching is not tuned - it supresses > >loop optimization :( > > it seems that you do not use the same set of conditions > as is implemented (LSB, MSB, zero, instead of greater, etc.). I use only zero and not-zero accompanied with cmpxx. I didn't use MSB because there was discussion about its removal and LSB because I don't know good use for it yet ;-) > > jmp_direct.nz a0,@L6 > > widen.d a3,a1 > > bseti log2(1048576),r0,a0 > > wow .... uh .... I was lazy to use "*" in define_expand instead of "@" to compute "log2_exact()" so that I simply emit it for assemler to handle it ;-) I use bseti C,r0,r for constants over 0xffff which are powers of two. I played a lot with code which generates constants. Now it is relatively clean only doesn't handle negative numbers efficiently. I'll need to do: nand r0,r0,t0 ; STALL loadcons.0 C,t0 or loadcons.0 C,t0 widen.d t0,t0 ; STALL while for positive the best is probably: move r0,t0 loadcons.0 C,t0 which is without possible stall. Of course the "stall" slot will be probably used by compiler but not always. Do you know better code for small negatives ? I'm thinking about this: If RTL pass of compiles allocates less than half of temporary registers then there will be some free ones even after optimization. In such case allocate one physical register and presume in patterns that is has value -1. Then use it during combiner pass just like we use r0 but for another things. If it was really used, generate new insn in prolog part to assign -1 to it and let second scheduler pass to reschedule it. Then we save 1 cycle per use for no runtime penalty. Hehe. Take it as interesting reading only - I don't plan to implement this beast soon but it is interesting, is not ? > i have put the sources at > http://f-cpu.seul.org/new/gccfcpu.20021203.tgz I'll definitely look at it ! However I have to postpone any other hacking till Christmas because I have important project at my work. best regards, devik PS: do you know about new scheduler in gcc 3.3 ?? It should schedule f-cpu almost perfectly ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 16:34:49 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHc-0002K8-00 for ; Tue, 03 Dec 2002 18:56:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:32 +0100 (CET) Received: (qmail 7222 invoked by uid 0); 3 Dec 2002 15:59:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 3 Dec 2002 15:59:24 -0000 Received: by moria.seul.org (Postfix) id 48B1E15E78C; Tue, 3 Dec 2002 10:59:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B24815E799; Tue, 3 Dec 2002 10:59:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D46DD15E78C for ; Tue, 3 Dec 2002 10:59:19 -0500 (EST) Received: from a124-137.dialup.iol.cz ([194.228.137.124] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JFS9-0003V3-00 for f-cpu@seul.org; Tue, 03 Dec 2002 16:59:19 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JF4T-0000Sh-00 for f-cpu@seul.org; Tue, 03 Dec 2002 16:34:49 +0100 Date: Tue, 3 Dec 2002 16:34:49 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Rep:[f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <200212030832.005c@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Eh eh. It crashes on vsprintf :( See reply to YG. I'll repair it during holidays probably. But from testing I done for simpler functions, the x86 code has about the same count of insns for small functions and 2 times more for long ones (over 100 insns). But it will be much better once I add all instruction patterns into description. devik On Tue, 3 Dec 2002, Nicolas Boulay wrote: > Nice work !! > > I was really interrested of the code size. How much instruction for a > fonction like printf compare to x86 or sparc ? > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 15:29:02 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHd-0002K8-00 for ; Tue, 03 Dec 2002 18:56:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:33 +0100 (CET) Received: (qmail 968 invoked by uid 0); 3 Dec 2002 15:59:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Dec 2002 15:59:27 -0000 Received: by moria.seul.org (Postfix) id 528EE15E794; Tue, 3 Dec 2002 10:59:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 15FF915E79C; Tue, 3 Dec 2002 10:59:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 6F17C15E799 for ; Tue, 3 Dec 2002 10:59:25 -0500 (EST) Received: from a124-137.dialup.iol.cz ([194.228.137.124] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JFSG-0003V3-00 for f-cpu@seul.org; Tue, 03 Dec 2002 16:59:24 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JE2o-0000S9-00 for f-cpu@seul.org; Tue, 03 Dec 2002 15:29:02 +0100 Date: Tue, 3 Dec 2002 15:29:02 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <002301c29ac4$c333e1e0$0100000a@homeworld> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Maybe I misunderstood is :( I thought: .q = quad = 32bit .d = double = 16bit .b = byte = 8bit > Very interesting... > > but why 'short' is 32-bit ??? (I can see ".d" in your generated code) > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 17:15:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHi-0002K8-00 for ; Tue, 03 Dec 2002 18:56:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:38 +0100 (CET) Received: (qmail 23761 invoked by uid 0); 3 Dec 2002 16:15:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 3 Dec 2002 16:15:40 -0000 Received: by moria.seul.org (Postfix) id AD06D15E794; Tue, 3 Dec 2002 11:15:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8A73015E79A; Tue, 3 Dec 2002 11:15:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id DBB7C15E799 for ; Tue, 3 Dec 2002 11:15:37 -0500 (EST) Received: from a74-137.dialup.iol.cz ([194.228.137.74] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JFhw-0005a0-00 for f-cpu@seul.org; Tue, 03 Dec 2002 17:15:36 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JFhn-0000Wk-00 for f-cpu@seul.org; Tue, 03 Dec 2002 17:15:27 +0100 Date: Tue, 3 Dec 2002 17:15:27 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > i have put the sources at > http://f-cpu.seul.org/new/gccfcpu.20021203.tgz eheh - these are my sources :) I thought you put your older ones :) Have you your gcc code somewhere ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Dec 3 21:54:07 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHn-0002K8-00 for ; Tue, 03 Dec 2002 18:56:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:43 +0100 (CET) Received: (qmail 22505 invoked by uid 0); 3 Dec 2002 16:54:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 3 Dec 2002 16:54:10 -0000 Received: by moria.seul.org (Postfix) id 8C12115E795; Tue, 3 Dec 2002 11:54:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6685E15E79A; Tue, 3 Dec 2002 11:54:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0A4A515E795 for ; Tue, 3 Dec 2002 11:54:09 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-4v.club-internet.fr (Postfix) with SMTP id 6E0501758 for ; Tue, 3 Dec 2002 17:54:07 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 17:54:07 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: devik >> there are several F-CPU assemblers now. >> even though i don't know which one to trust :-P >> everyone with a specific syntax, unique features etc ... >:) Are there reasons other than personal ego ? Like >if all wants their own assembler ? And are these >documented so that I can select one ? nobody is =22happy=22 with other's SW. unfortunately they are loosely documented, and the only discriminating factor is whether it works ... >> emulator is a big problem. it will take time >> before it's completely solved but i am confident. > >I understand that it is a big piece of code. But is >the principle so hairy ? =22in principle, no=22 :-) One of the big limitations is C itself. handling the large SIMD data is not easy, so a library must be designed ... C is limited to 64-bit data but not F-CPU, which can be configured to handle larger data. > I'd expect relatively simple > code ... But there may be things I'm overlooking .. yup :-) > Probably memory and cache simulations are not so simple too. if we ever go to that point .... >> compiler ... well ... you seem to have taken over >> the past efforts :-))) > >I didn't know about past efforts =21 Huh... I could >starts from that and not from scratch then :( have a look at http://www.f-cpu.de/gcc/ > I was learning gcc internals whole 3 days until I coded it... and as you see, it's not easy or adapted ;-) but recent GCC versions have shown some signs of enhancements (support for more =22modern=22 computers) >> >linux kernel for example and count cycles it takes >> >until /sbin/init is launched). >> >> i don't think that it is a good metric. >> On top of that, there is no external HW ready. > >yep .. I only wanted to see linux booted on f-cpu ;-) patience, patience ... ;-) >Probably because I'm familiar with large parts of linux >and wanted to try to understand arch-dependent parts too. >I planed to stole HW emulation from bochs :) huh.... do you really need to put some x86-related things in F-CPU ?... >> However it can be interesting to code and run the >> =22primary boot monitor=22 (see at >> http://f-cpu.seul.org/new/F-CPU=5Fboot.txt ) >> and start bootstrapping stuffs from that point, >> making simple =22toy=22 or useful software, etc ... > >good idea. nicO doesn't agree but most others do ;-P > Maybe it could be start point to do other tests. yup. It requires a small amount of code (at most a few thousands lines) and it will be able to run smoothly with the first emulators and simulators (no complex HW to simulate/emulate) under a Un*x environment... >I wanted to port linux also because when it =22runs=22 you >can benchmark other code on it (like to compile gcc on it). you will be able to =22boot=22 a bzimage and even load a initrd from the primary boot environment. And if you really want to have fun, you can try to program a multi-boot SW and even a grub-like program :-) >> >Also insns other than add and shift should be add (just >> >now gcc uses its libs). >> >> ? i don't understand what that means .... >> we can't do boolean or shift operations ? > >no no ... :-) I was just be lazy and implemented only >mandatory patterns like movM, jump, jump=5Findirect, call >and a few optionals like addM3, shiftM, extendM, compareM >and all branches. ouch.... >So I wanted to say that I have to add all others like >logic, other shifts, rots .... have fun .... >Also recently I found that I need reload=5FinM and reload=5FoutM >probably because when I tried to compile =22vsprintf=22 is >crashes when reloading registers - I used gen=5Freg=5Frtx >in moveM which is unfortunately not allowed when >reload=5Fin=5Fprogress is true. Have you played with these ? if at least i knew what you are talking about .... >> >There is problem with jump optimizer because it needs >> >labels tied to jumps but we have them in registers. >> the 'trick' is maybe to use a =22macro=22 and the instruction >> can be rescheduled by C=E9dric's assembler ... >I have done it exactly how you said. :) Problem can be >that we disable certain otimizations by this. If you'd >be able to instruct gcc to emit address load together >with jump it is able to do cse and factoring the load >of of the loop bodies. This is hard to do in assembler >because it would need to redo loop detection and expression >lifespan analysis. heck. but at least it works, no ? >I've seen something like this in ia64.md, I'll look at it. cool... >> >Also conditional branching is not tuned - it supresses >> >loop optimization :( >> >> it seems that you do not use the same set of conditions >> as is implemented (LSB, MSB, zero, instead of greater, etc.). > >I use only zero and not-zero accompanied with cmpxx. I didn't >use MSB because there was discussion about its removal and LSB >because I don't know good use for it yet ;-) The problem with MSB is : how to deal with the cases where F-CPU implements, say, 128-bit registers ? until now, it's hardwired to bit 63 of the registers (that's the sign bit ...) but i don't know what will happen next. >> > jmp=5Fdirect.nz a0,=40L6 >> > widen.d a3,a1 >> > bseti log2(1048576),r0,a0 >> >> wow .... uh .... > >I was lazy to use =22*=22 in define=5Fexpand instead of =22=40=22 to >compute =22log2=5Fexact()=22 so that I simply emit it for assemler >to handle it ;-) I use bseti C,r0,r for constants over 0xffff >which are powers of two. i'm not sure it's going to be implemented soon (the shifter is already quite large and i'm less optimistic about inserting more logic in the critical datapath). But it can be macro'ed anyway... >I played a lot with code which generates constants. Now it >is relatively clean only doesn't handle negative numbers >efficiently. i thought that loadconsx could do the trick... > I'll need to do: >nand r0,r0,t0 >; STALL >loadcons.0 C,t0 > >or > >loadcons.0 C,t0 >widen.d t0,t0 >; STALL > >while for positive the best is probably: >move r0,t0 >loadcons.0 C,t0 > >which is without possible stall. Of course the =22stall=22 slot >will be probably used by compiler but not always. Do you >know better code for small negatives ? i have not read C=E9dric's modifications to the manual, but there is/was an instruction called =22loadconsx=22 which sign-extends the constants. >I'm thinking about this: If RTL pass of compiles allocates >less than half of temporary registers then there will be >some free ones even after optimization. In such case allocate >one physical register and presume in patterns that is has >value -1. Then use it during combiner pass just like we >use r0 but for another things. If it was really used, generate >new insn in prolog part to assign -1 to it and let second scheduler >pass to reschedule it. >Then we save 1 cycle per use for no runtime penalty. Hehe. >Take it as interesting reading only - I don't plan to implement >this beast soon but it is interesting, is not ? i'm not sure to understand everything. but i know that gcc is not the kind of beast i want to fight this week-end :-) >> i have put the sources at >> http://f-cpu.seul.org/new/gccfcpu.20021203.tgz > >I'll definitely look at it =21 it's yours :-) but http://f-cpu.seul.org/new/ contains a lot of random design files, it's the last web location that is still updated unfrequently ;-) > However I have to postpone >any other hacking till Christmas because I have important >project at my work. have fun anyway =21 >best regards, >devik > >PS: do you know about new scheduler in gcc 3.3 ?? It should > schedule f-cpu almost perfectly let's hope so. but i know that the party is not going to end soon and gcc still has a lot of problems, it is not well adapted to F-CPU and new and additional scheduling techniques must be implemented (like : reducing the overhead of the prefetches, the number of pointers, etc ...) and now, let's work ;-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Tue Dec 3 22:00:02 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JHHp-0002K8-00 for ; Tue, 03 Dec 2002 18:56:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 18:56:45 +0100 (CET) Received: (qmail 23571 invoked by uid 0); 3 Dec 2002 17:00:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 3 Dec 2002 17:00:04 -0000 Received: by moria.seul.org (Postfix) id 8F8BC15E740; Tue, 3 Dec 2002 12:00:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7CC1115E79A; Tue, 3 Dec 2002 12:00:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 337AA15E740 for ; Tue, 3 Dec 2002 12:00:03 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-2v.club-internet.fr (Postfix) with SMTP id AAC091685 for ; Tue, 3 Dec 2002 18:00:02 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: [f-cpu] date format at f-cpu.seul.org/ Date: Tue, 3 Dec 2002 18:00:02 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 just want to know whether it's ok if i manually modify the file names at http://f-cpu.seul.org/new/ =3D=3D> adopting the ISO/ANSI/whatever standard format would make it a bit more readable .... for example, http://f-cpu.seul.org/new/Snapshot=5Fjws=5F19=5F07=5F2002.tar.bz2 would become http://f-cpu.seul.org/new/Snapshot=5Fjws=5F20020719.tar.bz2 the only problem is when day and month are ambiguous .... is it ok ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Dec 3 18:52:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JI3i-0002zP-00 for ; Tue, 03 Dec 2002 19:46:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 19:46:14 +0100 (CET) Received: (qmail 20357 invoked by uid 0); 3 Dec 2002 17:57:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 3 Dec 2002 17:57:41 -0000 Received: by moria.seul.org (Postfix) id D288915E79A; Tue, 3 Dec 2002 12:57:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B32A115E7AA; Tue, 3 Dec 2002 12:57:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 411AC15E79A for ; Tue, 3 Dec 2002 12:57:32 -0500 (EST) Received: from homeworld (81.50.64.244) by smtp.laposte.net (6.0.053) id 3DDAB949001A9188 for f-cpu@seul.org; Tue, 3 Dec 2002 18:57:28 +0100 Message-ID: <000201c29af4$dbc89a90$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 18:52:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Not a bad clue. But for 128-bit F-CPU instead of 64-bit, using ".q" would be clumsy. Why don't use something like : .l = long word, can be 64-bit or 128 bit or more .s = single word, always 32-bit .h = half word, always 16-bit .q/.b = quater word, byte, always 8-bit ? or : .l = 64/128/... .q = 4 bytes .d = 2 bytes .b = 1 bytes using sufix like .8/.16/.32 is okay but .64 is wrong ----- Original Message ----- From: "devik" To: Sent: Tuesday, December 03, 2002 3:29 PM Subject: Re: [f-cpu] GCC 3.1 for F-CPU port > Maybe I misunderstood is :( I thought: > > .q = quad = 32bit > .d = double = 16bit > .b = byte = 8bit > > > Very interesting... > > > > but why 'short' is 32-bit ??? (I can see ".d" in your generated code) > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Tue Dec 3 19:00:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JI3i-0002zP-01 for ; Tue, 03 Dec 2002 19:46:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 19:46:14 +0100 (CET) Received: (qmail 16546 invoked by uid 0); 3 Dec 2002 18:00:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 3 Dec 2002 18:00:31 -0000 Received: by moria.seul.org (Postfix) id 9FF0A15E743; Tue, 3 Dec 2002 13:00:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7D32415E79A; Tue, 3 Dec 2002 13:00:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 2FF5A15E743 for ; Tue, 3 Dec 2002 13:00:30 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id 5EEA81CF8B for ; Tue, 3 Dec 2002 19:00:29 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Tue, 3 Dec 2002 19:00:29 +0100 (CET) Message-ID: <45303.80.67.170.17.1038938429.squirrel@rezo.net> Date: Tue, 3 Dec 2002 19:00:29 +0100 (CET) Subject: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Antoine" To: In-Reply-To: <000201c29af4$dbc89a90$0100000a@homeworld> References: <000201c29af4$dbc89a90$0100000a@homeworld> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Not a bad clue. > > But for 128-bit F-CPU instead of 64-bit, using ".q" would be clumsy. > > Why don't use something like : > > .l = long word, can be 64-bit or 128 bit or more In my opinion, an integer (or a pointer) wider than 64 bits really has no point. Such widths should be reserved for SIMD. Again, that's only my opinion ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Dec 3 21:14:04 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JJJR-0003p3-00 for ; Tue, 03 Dec 2002 21:06:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 21:06:33 +0100 (CET) Received: (qmail 9171 invoked by uid 0); 3 Dec 2002 19:26:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 3 Dec 2002 19:26:21 -0000 Received: by moria.seul.org (Postfix) id 903E315E723; Tue, 3 Dec 2002 14:26:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71A6315E798; Tue, 3 Dec 2002 14:26:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp3.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id EF94815E723 for ; Tue, 3 Dec 2002 14:26:19 -0500 (EST) Received: from thor (48.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.48]) by smtp3.9tel.net (Postfix) with ESMTP id B96245BE50 for ; Tue, 3 Dec 2002 20:26:18 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 20:14:04 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212032014.05043.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N That's really a great news ! > I created port of GCC for F-CPU. Just now it compiles > rather complex functions however there are known bugs > in stack handling (pointer inc) and some others. > Also insns other than add and shift should be add (just > now gcc uses its libs). How did you manage more than 14 parameters ? > There is problem with jump optimizer because it needs > labels tied to jumps but we have them in registers. Just Did you mean that you currently don't use the couple loop/loopentry ? Did you have an idea on how to use it with recursive call function in gcc ? On other question, why did you choose GCC 3.1 and not 3.3 ? or did your patch normally work for later gcc ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Tue Dec 3 21:14:10 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JJJR-0003p3-01 for ; Tue, 03 Dec 2002 21:06:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 21:06:33 +0100 (CET) Received: (qmail 1091 invoked by uid 0); 3 Dec 2002 19:26:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 3 Dec 2002 19:26:53 -0000 Received: by moria.seul.org (Postfix) id 1F21515E744; Tue, 3 Dec 2002 14:26:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 027DA15E799; Tue, 3 Dec 2002 14:26:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id 2F9CC15E744 for ; Tue, 3 Dec 2002 14:26:52 -0500 (EST) Received: from thor (48.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.48]) by smtp4.9tel.net (Postfix) with ESMTP id 6C37F5C9E5 for ; Tue, 3 Dec 2002 20:26:23 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Tue, 3 Dec 2002 20:14:10 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212032014.10177.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >> there are several F-CPU assemblers now. > >> even though i don't know which one to trust :-P > >> everyone with a specific syntax, unique features etc ... > >:) Are there reasons other than personal ego ? Like > >if all wants their own assembler ? And are these > >documented so that I can select one ? We are planning to do a documentation for our assembler, but it take a lot of time to write it (more than to code it in fact ;-). > >> emulator is a big problem. it will take time > >> before it's completely solved but i am confident. > >I understand that it is a big piece of code. But is > >the principle so hairy ? > "in principle, no" :-) The problem is that currenlty we didn't define how to setup hardware interruption and interface with the rest of the world. > One of the big limitations is C itself. > handling the large SIMD data is not easy, so a library > must be designed ... C is limited to 64-bit data > but not F-CPU, which can be configured to handle larger data. That's not really a problem. > > Probably memory and cache simulations are not so simple too. > if we ever go to that point .... We must thing to that when we are writing to code a emulator or we will need to rewrite it totally if something change. A good idea will be to have a configurable memory hierarchy so that we can test the impact of different cache policy on a complete system... But that's a dream... or a nightmare ;-) > >I wanted to port linux also because when it "runs" you > >can benchmark other code on it (like to compile gcc on it). Something that will be very interesting will be to use cycle counter for benchmark so that we can have an image of the final result. So some tools must be rewriten. > >So I wanted to say that I have to add all others like > >logic, other shifts, rots .... It will be perhaps a good idea to put it on a cvs, so that some other people can help you. > >> the 'trick' is maybe to use a "macro" and the instruction > >> can be rescheduled by Cédric's assembler ... I don't think it's a good idea, because the assembler can only do limited scheduling. The compiler can schedule thing before allocating register, something that the assembler couldn't do. > i thought that loadconsx could do the trick... loadconsx has been removed since 0.2.5 or 0.2.6, I think it was because we have widden. But I think a loadconsz that will zero the other chunk can be useful. > >which is without possible stall. Of course the "stall" slot > >will be probably used by compiler but not always. Do you > >know better code for small negatives ? I was thinking that 8 bits immediates were signed. For other you need to use widden, but I was thinking that it only take one cycle. So I don't understand your stall. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 3 18:12:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JL92-0005J0-01 for ; Tue, 03 Dec 2002 23:03:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 03 Dec 2002 23:03:56 +0100 (CET) Received: (qmail 17496 invoked by uid 0); 3 Dec 2002 21:08:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 3 Dec 2002 21:08:09 -0000 Received: by moria.seul.org (Postfix) id 7085515E743; Tue, 3 Dec 2002 16:08:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B40515E792; Tue, 3 Dec 2002 16:08:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 7D84C15E743 for ; Tue, 3 Dec 2002 16:08:06 -0500 (EST) Received: from a3-137.dialup.iol.cz ([194.228.137.3] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JKGx-0006Tp-00 for f-cpu@seul.org; Tue, 03 Dec 2002 22:08:04 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JGaW-0000Y6-00 for f-cpu@seul.org; Tue, 03 Dec 2002 18:12:00 +0100 Date: Tue, 3 Dec 2002 18:12:00 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] simulator note - structs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I downloaded yg package and looked at simulator. Only one note, would not be better to enclose inputs and outputs of each part into struct ? It could allow to: - instantiate more of them (for future multiissue designs) - pack bits => faster code without messing it - group them logicaly and to FF clocking by assigning whole structures where aplicable and also initialize (clear) all lines with single cmd. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Dec 3 21:51:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18JNXK-0006rs-00 for ; Wed, 04 Dec 2002 01:37:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 01:37:10 +0100 (CET) Received: (qmail 31957 invoked by uid 0); 4 Dec 2002 00:00:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 4 Dec 2002 00:00:20 -0000 Received: by moria.seul.org (Postfix) id 1E07D15E741; Tue, 3 Dec 2002 19:00:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E33ED15E747; Tue, 3 Dec 2002 19:00:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id 8A8BB15E741 for ; Tue, 3 Dec 2002 19:00:15 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00861; Tue, 3 Dec 2002 21:51:30 +0100 Message-ID: <20021203215130.59169@thrai.stud.uni-hannover.de> Date: Tue, 3 Dec 2002 21:51:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Dec 03, 2002 at 04:32:21PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Dec 03, 2002 at 04:32:21PM +0100, devik wrote: > > there are several F-CPU assemblers now. > > even though i don't know which one to trust :-P > > everyone with a specific syntax, unique features etc ... > > :) Are there reasons other than personal ego ? Like > if all wants their own assembler ? And are these > documented so that I can select one ? Yann's assembler (ygasm) is more suited for assembly programming on a `raw' machine, while my version (as-0.0) is tailored for a Unix-style environment; but I have to admit that I also wanted to build a bigger application that uses my libelf library. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kasie_6@hotmail.com Wed Dec 4 07:09:14 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja1T-0000HY-00 for ; Wed, 04 Dec 2002 14:57:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:07 +0100 (CET) Received: (qmail 26472 invoked by uid 0); 4 Dec 2002 06:09:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 4 Dec 2002 06:09:17 -0000 Received: by moria.seul.org (Postfix) id BD6E415E744; Wed, 4 Dec 2002 01:09:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F7EE15E752; Wed, 4 Dec 2002 01:09:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from hotmail.com (f43.pav1.hotmail.com [64.4.31.43]) by moria.seul.org (Postfix) with ESMTP id CC3CF15E744 for ; Wed, 4 Dec 2002 01:09:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Dec 2002 22:09:14 -0800 Received: from 66.133.61.187 by pv1fd.pav1.hotmail.msn.com with HTTP; Wed, 04 Dec 2002 06:09:14 GMT X-Originating-IP: [66.133.61.187] From: "kasie_6 kasie_6" To: f-cpu@seul.org Subject: [f-cpu] Urgent and confidential Date: Wed, 04 Dec 2002 08:09:14 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Dec 2002 06:09:14.0266 (UTC) FILETIME=[AB92F7A0:01C29B5B] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N No 13 VS2 Cethswayo Estate Generation-South Africa. Satelite phone: 882-1646685262 .................... Email:kasie_1@unitedstates.com {URGENT AND CONFIDENTIAL} (RE: TRANSFER OF ($ 126,000.000.00 USD} {ONE HUNDRED AND TWENTY SIX MILLION DOLLARS) Dear sir, We want to transfer to overseas ($ 126,000.000.00 USD) One hundred and Twenty six million United States Dollars) from a Bank in Africa, I want to ask you to quietly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new Bank a/c immediately to receive this money, even an empty a/c can serve to receive this money, as long as you will remain honest to me till the end for this important business trusting in you and believing in God that you will never let me down either now or in future. I am Mr.Jerry Marcel, the Auditor General of a bank in Africa, during the course of our auditing I discovered a floating fund in an account opened in the bank in 1990 and since 1993 nobody has operated on this account again, after going through some old files in the records I discovered that the owner of the account died without a [heir] hence the money is floating and if I do not remit this money out urgently it will be forfeited for nothing. the owner of this account is Mr. Phillip Morris, a foreigner, and a sailor, and he died, since 1993. and no other person knows about this account or any thing concerning it, the account has no other beneficiary and my investigation proved to me as well that Phillip Morris until his death was the manager Morris & Morris Coy.(pty). SA. We will start the first transfer with Twenty six million [$26,000.000] upon successful transaction without any disappoint from your side, we shall re-apply for the payment of the remaining rest amount to your account, The amount involved is (USD 126M) One hundred and Twenty Six million United States Dollars, only I want to first transfer $26,000.000 [Twenty Six million United States Dollar from this money into a safe foreigners account abroad before the rest, but I don't know any foreigner, I am only contacting you as a foreigner because this money can not be approved to a local person here, without valid international foreign passport, but can only be approved to any foreigner with valid international passport or drivers license and foreign a/c because the money is in us dollars and the former owner of the a/c Mr. Phillip Morris is a foreigner too, [and the money can only be approved into a foreign a/c. However, we will sign a binding agreement, to bind us together I got your contact address from the Girl who operates computer, I am revealing this to you with believe in God that you will never let me down in this business, you are the first and the only person that I am contacting for this business, so please reply urgently so that I will inform you the next step to take urgently. Send also your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments. I need your full co-operation to make this work fine. because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you, upon your positive response and once I am convinced that you are capable and will meet up with instruction of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never, never let me down. With my influence and the position of the bank official we can transfer this money to any foreigner's reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing. The bank official will destroy all documents of transaction immediately we receive this money leaving no trace to any place and to build confidence you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act and receive this fund in your account. I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries and foreign exchange departments. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during the process of transferring. I look forward to your earliest reply through my email You should try to call me on my satelite phone no. 882-1646685262. if you are calling my No. dial the way you use to call other countries, do not put South African area code, because it is a satellite phone. Sincerely, Mr Jerry Marcel. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 08:25:40 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja1X-0000HY-01 for ; Wed, 04 Dec 2002 14:57:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:11 +0100 (CET) Received: (qmail 30745 invoked by uid 0); 4 Dec 2002 07:26:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Dec 2002 07:26:42 -0000 Received: by moria.seul.org (Postfix) id AB96615E744; Wed, 4 Dec 2002 02:26:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85C1D15E752; Wed, 4 Dec 2002 02:26:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 1B36C15E744 for ; Wed, 4 Dec 2002 02:26:41 -0500 (EST) Received: from a13-137.dialup.iol.cz ([194.228.137.13] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JTvb-0004Vv-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:26:39 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JTue-00008f-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:25:40 +0100 Date: Wed, 4 Dec 2002 08:25:40 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <200212032014.10177.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > We are planning to do a documentation for our assembler, but it take a lo= t of > time to write it (more than to code it in fact ;-). good. Did anyone attempted to port gas ? It could benefit from having ELF lin and linker in place ... > > >So I wanted to say that I have to add all others like > > >logic, other shifts, rots .... > > It will be perhaps a good idea to put it on a cvs, so that some other peo= ple > can help you. Maybe on holidays :) But yesterday I implemented all possible generic insns (about 20) using short M4 macro .... > > >> the 'trick' is maybe to use a "macro" and the instruction > > >> can be rescheduled by C=E9dric's assembler ... > > I don't think it's a good idea, because the assembler can only do limited > scheduling. The compiler can schedule thing before allocating register, > something that the assembler couldn't do. exactly. > > i thought that loadconsx could do the trick... > > loadconsx has been removed since 0.2.5 or 0.2.6, I think it was because w= e > have widden. But I think a loadconsz that will zero the other chunk can b= e > useful. loadconsx seems more useful :( loadconsz can be split to move r0,r and loadcons.0 with no stall ... > > >which is without possible stall. Of course the "stall" slot > > >will be probably used by compiler but not always. Do you > > >know better code for small negatives ? > > I was thinking that 8 bits immediates were signed. For other you need to = use > widden, but I was thinking that it only take one cycle. So I don't unders= tand > your stall. manual says (well I had to look into .tex for it) that widen has 1 cycle latency (it is regular EU, not as move or loadcons whose emits value directly from decode FFs to xbar). Because gcc currently can't schedule across basic blocks it often stalls at next insn after widen. PS: did you took into account my comments from mail named "Manual problems and...." especially regarding cor/cand and mux ? I'd like to use them in gcc but i'm not sure with semantic - search over all mail archives didn't help .. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 08:07:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja1Y-0000HY-00 for ; Wed, 04 Dec 2002 14:57:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:12 +0100 (CET) Received: (qmail 24229 invoked by uid 0); 4 Dec 2002 07:26:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Dec 2002 07:26:44 -0000 Received: by moria.seul.org (Postfix) id AEF8215E746; Wed, 4 Dec 2002 02:26:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 87D0215E78C; Wed, 4 Dec 2002 02:26:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id DF64415E746 for ; Wed, 4 Dec 2002 02:26:41 -0500 (EST) Received: from a13-137.dialup.iol.cz ([194.228.137.13] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JTvc-0004Vv-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:26:41 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JTdM-00008U-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:07:48 +0100 Date: Wed, 4 Dec 2002 08:07:48 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, I deleted some parts and answered them in reply to cedric's mail. > >I didn't know about past efforts ! Huh... I could > >starts from that and not from scratch then :( > have a look at http://www.f-cpu.de/gcc/ sure :) > >I planed to stole HW emulation from bochs :) > huh.... > do you really need to put some x86-related things in F-CPU ?... no x86 related parts - I was thinking about PCI subsys, IDE, text video and keyboard. But the very first attempt could probably go with pooling "HDD" thru fixed memory location and VT100 console at "serial" port simulated in the same way. Then you could simply attach /dev/console of fcpu linux to the serial port and other side (emulator's) connect to PTY of host machine - then simply run xterm and have both video & keyboard :) Probably the fastest way to code. >[...] > >in moveM which is unfortunately not allowed when > >reload_in_progress is true. Have you played with these ? > > if at least i knew what you are talking about .... ehh ok, I'm not sure I know it either :) > >I use only zero and not-zero accompanied with cmpxx. I didn't > >use MSB because there was discussion about its removal and LSB > >because I don't know good use for it yet ;-) > > The problem with MSB is : how to deal with the cases > where F-CPU implements, say, 128-bit registers ? > until now, it's hardwired to bit 63 of the registers > (that's the sign bit ...) but i don't know what will > happen next. I understand. And LSB ? Do you have some use for compiler in mind ? > >> > bseti log2(1048576),r0,a0 > >> > >> wow .... uh .... > > > >I was lazy to use "*" in define_expand instead of "@" to > >compute "log2_exact()" so that I simply emit it for assemler > >to handle it ;-) I use bseti C,r0,r for constants over 0xffff > >which are powers of two. > > i'm not sure it's going to be implemented soon (the shifter > is already quite large and i'm less optimistic about inserting > more logic in the critical datapath). But it can be macro'ed > anyway... Ahh are you speaking about bitop insn ? Would be possible to implement it as second pipeline stage after shift ? Not that I would need it - I only want to understand if it is possible without larke consequences (next port to xbar or so). > i thought that loadconsx could do the trick... it was dropped ... > must be implemented (like : reducing the overhead of the > prefetches, the number of pointers, etc ...) number of pointers ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 08:15:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja1Z-0000HY-00 for ; Wed, 04 Dec 2002 14:57:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:13 +0100 (CET) Received: (qmail 17995 invoked by uid 0); 4 Dec 2002 07:26:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 4 Dec 2002 07:26:46 -0000 Received: by moria.seul.org (Postfix) id 0790F15E787; Wed, 4 Dec 2002 02:26:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1B9915E794; Wed, 4 Dec 2002 02:26:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 2F27E15E787 for ; Wed, 4 Dec 2002 02:26:43 -0500 (EST) Received: from a13-137.dialup.iol.cz ([194.228.137.13] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JTve-0004Vv-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:26:42 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JTkS-00008Y-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:15:08 +0100 Date: Wed, 4 Dec 2002 08:15:08 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <200212032014.05043.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > in stack handling (pointer inc) and some others. > > Also insns other than add and shift should be add (just > > now gcc uses its libs). > > How did you manage more than 14 parameters ? btw there is BUGGG in manual probably: r0,rv = 2regs a0..14 = 14regs t0..16 = 17regs ----------------- total = 33 regs but manual states 32 at page 223 ! Regarding manual's numbering there should be only 16 temps so I dropped t16. All which doesn't fit into a0..a13 (larger or more of them) are passed on stack. > > There is problem with jump optimizer because it needs > > labels tied to jumps but we have them in registers. Just > > Did you mean that you currently don't use the couple loop/loopentry ? I attemped to do it (this case can gcc handle by "loop prolog"). But loop optimizer doesn't work for me yet - probably bug in my cond branches > Did you have an idea on how to use it with recursive call function in gcc ? gcc handles it by allocating callee saved register for both loop counter and loop address. > On other question, why did you choose GCC 3.1 and not 3.3 ? or did your patch > normally work for later gcc ? because I have 3.1 already installed and hacked a bit. I'll try 3.3 ASAP. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 08:42:13 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja1l-0000HY-01 for ; Wed, 04 Dec 2002 14:57:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:25 +0100 (CET) Received: (qmail 23422 invoked by uid 0); 4 Dec 2002 08:13:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 4 Dec 2002 08:13:51 -0000 Received: by moria.seul.org (Postfix) id 86F8315E744; Wed, 4 Dec 2002 03:13:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6E5E415E752; Wed, 4 Dec 2002 03:13:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EDC8B15E744 for ; Wed, 4 Dec 2002 03:13:49 -0500 (EST) Received: from a114-137.dialup.iol.cz ([194.228.137.114] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JUfE-0003Qu-00 for f-cpu@seul.org; Wed, 04 Dec 2002 09:13:49 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JUAf-0000AF-00 for f-cpu@seul.org; Wed, 04 Dec 2002 08:42:13 +0100 Date: Wed, 4 Dec 2002 08:42:13 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <20021203215130.59169@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Yann's assembler (ygasm) is more suited for assembly programming on a > `raw' machine, while my version (as-0.0) is tailored for a Unix-style > environment; but I have to admit that I also wanted to build a bigger > application that uses my libelf library. Do you really output ELF ?? It would be probably choice if I want to use/adapt tools like gnu ld - I'd need them if I want to link some standard project (at least staticaly). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 4 11:14:58 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja22-0000HY-00 for ; Wed, 04 Dec 2002 14:57:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:42 +0100 (CET) Received: (qmail 14482 invoked by uid 0); 4 Dec 2002 10:15:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 4 Dec 2002 10:15:16 -0000 Received: by moria.seul.org (Postfix) id 25DBF15E747; Wed, 4 Dec 2002 05:15:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D8C6C15E78C; Wed, 4 Dec 2002 05:15:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 467CA15E747 for ; Wed, 4 Dec 2002 05:15:14 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212041014.3a48; Wed, 4 Dec 2002 10:14:58 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Dec 2002 10:14:58 GMT Message-id: <200212041014.3a48@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 03/12/02 Objet: Re: Re: [f-cpu] GCC 3.1 for F-CPU port X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubs= cribe f-cpu hi ! >De: devik >> there are several F-CPU assemblers now. >> even though i don't know which one to trust :-P >> everyone with a specific syntax, unique features etc ... >:) Are there reasons other than personal ego ? Like >if all wants their own assembler ? And are these >documented so that I can select one ? nobody is "happy" with other's SW. unfortunately they are loosely documented, and the only discriminating factor is whether it works ... >>>Cedric and Alex have written a pretty complete generic as= sembler working with x86 and fcpu. IT's pretty fast and modular. It = seems that they didn't release it now because they have udge work on do= cumentation. So Cedric, time is up ! Show your code ! >> emulator is a big problem. it will take time >> before it's completely solved but i am confident. > >I understand that it is a big piece of code. But is >the principle so hairy ? "in principle, no" :-) >>>One emulator work, but without SIMD stuff ! One of the big limitations is C itself. handling the large SIMD data is not easy, so a library must be designed ... C is limited to 64-bit data but not F-CPU, which can be configured to handle larger data= . >>>Don't mixe things !! F-cpu are definitly a 64 bits cpu. W= e try to make it easy to enlarge the register for SIMD stuff. have 64= bits register is not a good idea, 256 is much more interresting b= ut 256 means : 4*64,8*32,16*16,32*8. You never manipulate scalar data wit= h more than 64 bits (or 128 for fp but it's for later).=20 [...] >I use only zero and not-zero accompanied with cmpxx. I didn= 't >use MSB because there was discussion about its removal and = LSB >because I don't know good use for it yet ;-) The problem with MSB is : how to deal with the cases where F-CPU implements, say, 128-bit registers ? until now, it's hardwired to bit 63 of the registers (that's the sign bit ...) but i don't know what will happen next. >>> 64 bits register is a futur problem sources ! Think of f= cpu with 256 bits register ! (it's more easy to down size than up size, a= nd 4 64 bits fp vector seems to be an optimal for spec bench as said by a= university paper on vectorising). >>>Just one question concerning gcc : if you use 2 separate = registers but some instruction could access both register, is that eas= y to use it (2*2r1w could be much much quicker than 1 one big 4r2w, and = you double the register number)? And it is possible to "paired" instruc= tion world easly (it must be done for I64 code). I stay with my "little= vliw" idae for fc1 :) >>>We have now a gcc expert ! We could evaluate the use of a= ny f-cpu feature by gcc :) >>>So now try to convince Whygee that forbbid more than 2 ad= resse alias in register bank is a very bad idea ! nicO ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 15:17:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja23-0000HY-00 for ; Wed, 04 Dec 2002 14:57:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:43 +0100 (CET) Received: (qmail 7415 invoked by uid 0); 4 Dec 2002 10:17:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 4 Dec 2002 10:17:08 -0000 Received: by moria.seul.org (Postfix) id 72CCA15E752; Wed, 4 Dec 2002 05:17:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4745715E792; Wed, 4 Dec 2002 05:17:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id BC1EB15E752 for ; Wed, 4 Dec 2002 05:17:06 -0500 (EST) Received: from club-internet.fr (flashmail-6v.cs.clubint.net [172.16.0.157]) by relay-2v.club-internet.fr (Postfix) with SMTP id 14B221737 for ; Wed, 4 Dec 2002 11:17:06 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 11:17:05 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, (i'm trying to catch up) >De: =22Christophe Avoinne=22 > >Not a bad clue. > >But for 128-bit F-CPU instead of 64-bit, using =22.q=22 would be clumsy. > >Why don't use something like : > >..l =3D long word, can be 64-bit or 128 bit or more >..s =3D single word, always 32-bit >..h =3D half word, always 16-bit >..q/.b =3D quater word, byte, always 8-bit ? > >or : > >..l =3D 64/128/... >..q =3D 4 bytes >..d =3D 2 bytes >..b =3D 1 bytes > = >using sufix like .8/.16/.32 is okay but .64 is wrong why ?... at least, using these numbers is not ambiguous at all. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 15:25:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja25-0000HY-00 for ; Wed, 04 Dec 2002 14:57:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:45 +0100 (CET) Received: (qmail 27736 invoked by uid 0); 4 Dec 2002 10:25:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 4 Dec 2002 10:25:30 -0000 Received: by moria.seul.org (Postfix) id 9461F15E747; Wed, 4 Dec 2002 05:25:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76F4815E78C; Wed, 4 Dec 2002 05:25:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 1F3A215E747 for ; Wed, 4 Dec 2002 05:25:28 -0500 (EST) Received: from club-internet.fr (flashmail-6v.cs.clubint.net [172.16.0.157]) by relay-2v.club-internet.fr (Postfix) with SMTP id 6933E1737 for ; Wed, 4 Dec 2002 11:25:27 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 11:25:27 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 (still catching up in chronological order) >De: =22Antoine=22 > >> Not a bad clue. >> >> But for 128-bit F-CPU instead of 64-bit, using =22.q=22 would be clumsy= =2E >> >> Why don't use something like : >> >> .l =3D long word, can be 64-bit or 128 bit or more > >In my opinion, an integer (or a pointer) wider than 64 bits > really has no point. Such widths should be reserved for SIMD. why =22reserved=22 ? usually, a pointer uses a register (there is no SIMD pointer). if a register is larger than 64 bits, then the pointer theoretically grows as well. it's just a matter of how many bits are =22useful/used=22. >Again, that's only my opinion ;) yup :-) btw, who will come tomorrow to http://paris.firstjeudi.org/ ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From karl-heinz@eischer.net Wed Dec 4 11:24:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja26-0000HY-00 for ; Wed, 04 Dec 2002 14:57:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:46 +0100 (CET) Received: (qmail 9833 invoked by uid 0); 4 Dec 2002 10:28:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 4 Dec 2002 10:28:50 -0000 Received: by moria.seul.org (Postfix) id 5F6CC15E747; Wed, 4 Dec 2002 05:28:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47DC515E78C; Wed, 4 Dec 2002 05:28:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by moria.seul.org (Postfix) with ESMTP id C460E15E747 for ; Wed, 4 Dec 2002 05:28:48 -0500 (EST) Received: from fwd00.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18JWls-0008B8-02; Wed, 04 Dec 2002 11:28:48 +0100 Received: from eischer.net (098261445-0003@[217.228.187.33]) by fmrl00.sul.t-online.com with esmtp id 18JWlh-0lLi8OC; Wed, 4 Dec 2002 11:28:37 +0100 Received: from kh by picasso with local (Exim 3.35 #1 (Debian)) id 18JWhM-00012y-00 for ; Wed, 04 Dec 2002 11:24:08 +0100 Date: Wed, 4 Dec 2002 11:24:08 +0100 From: Karl-Heinz Eischer To: F-CPU Subject: [f-cpu] manual 0.27c Message-ID: <20021204102408.GA2134@eischer.net> Mail-Followup-To: F-CPU Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Sender: 098261445-0003@t-dialin.net Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Hi, the manual states on page 88 (instruction sub): The borrow flag (same as carry) indicates that the borrow value is written to register number (r1^1). If no borrow has been generated, the neighbour register is cleared, otherwise the neighbour register is set to 1. The examples show that it is set to 0xFF. Furthermore there is the order inconsitent is the description. First it states r2 - r3 and a few lines later (r3 - r2). The example shows r2 - r3. There are some other corrections in the patch which is attached. Please have a look. KH -- // In a world without walls and fences who needs Windows and Gates ? // --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="F-CPU_manual-0.2.7c-en.patch.2.1d" diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/cmple.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/cmple.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/cmple.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/cmple.tex Tue Dec 3 12:35:34 2002 @@ -52,9 +52,9 @@ R2 contains 0x0000000700000001 {\tt -{\bf scmpl.b r1,r2,r3 }: r3 = 0xFFFFFF00FFFFFFFF\\ -{\bf scmpl.b r2,r1,r3 }: r3 = 0xFFFFFFFFFFFFFF00\\ -{\bf cmpl r1,r2,r3 }: r3 = 0x0000000000000000 +{\bf scmple.b r1,r2,r3 }: r3 = 0xFFFFFF00FFFFFFFF\\ +{\bf scmple.b r2,r1,r3 }: r3 = 0xFFFFFFFFFFFFFF00\\ +{\bf cmple r1,r2,r3 }: r3 = 0x0000000000000000 } {\bf Performance (FC0 only) :} diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/mac.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/mac.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/mac.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/mac.tex Tue Dec 3 14:54:48 2002 @@ -83,7 +83,7 @@ R2 contains 0x36\\ R3 contains 0x0136 -{\tt{\bf mac.b r1,r2,r3 }: r3 = 0x0868\\ +{\tt{\bf mac.b r1,r2,r3 }: r3 = 0x0898\\ } \begin{center} diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/max.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/max.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/max.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/max.tex Tue Dec 3 12:43:07 2002 @@ -46,7 +46,7 @@ {\tt {\bf smax.b r1,r2,r3 }: r3 = 0x0000000700000003\\ -{\bf max r1,r2,r3 }: r3 = 0x0000000700000003 +{\bf max r1,r2,r3 }: r3 = 0x0000000700000001 } {\bf Performance (FC0 only) :} diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/mul.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/mul.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/mul.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/mul.tex Tue Dec 3 11:48:10 2002 @@ -80,12 +80,12 @@ {\em SIMD :} -R1 contains 0x00 00 00 00 00 00 00 00 (in a 64-bit system)\\ -R2 contains 0x00 00 00 00 00 00 00 00 +R1 contains 0x00 00 00 23 00 00 00 03 (in a 64-bit system)\\ +R2 contains 0x00 00 00 36 00 00 00 05 {\tt -{\bf smul.b r1,r2,r3 }: r3 = 0x00 00 00 00 00 00 00 00 \\ -{\bf smulh.b r1,r2,r3 }: r3 = 0x00 00 00 00 00 00 00 00 , r4 = 0x00 00 00 00 +{\bf smul.b r1,r2,r3 }: r3 = 0x00 00 00 62 00 00 00 0F \\ +{\bf smulh.b r1,r2,r3 }: r3 = 0x00 00 00 62 00 00 00 0F , r4 = 0x00 00 00 07 00 00 00 00\\ } diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/nabs.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/nabs.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/nabs.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/nabs.tex Tue Dec 3 14:50:42 2002 @@ -19,8 +19,8 @@ ~~~~~~ This instruction negates the source operand in a special unit that is designed for low latency when large data are processed. If the sign bit -(MSB) of the source is set (the number is negative) then the value is -written back to the register set, or else (it is already positive) the result +(MSB) of the source is not set (the number is positive) then the value is +written back to the register set, or else (it is already negative) the result is cancelled (that's how it works in scalar mode, not in SIMD mode...). ~~~~~~ diff -Nur F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/sub.tex F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/sub.tex --- F-CPU_manual-0.2.7c-en.orig/src/i7/Draft/Integer/sub.tex Sat Nov 16 17:25:49 2002 +++ F-CPU_manual-0.2.7c-en/src/i7/Draft/Integer/sub.tex Tue Dec 3 15:07:23 2002 @@ -32,8 +32,7 @@ \item The {\bf borrow} flag (same as carry) indicates that the borrow value is written to register number (r1\xor1). If no borrow has been generated, -the neighbour register is cleared, otherwise the neighbour register is set to -1. +the neighbour register is cleared, otherwise the neighbour register is set. \end{itemize} --bp/iNruPH9dso1Pn-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 15:58:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2G-0000HY-01 for ; Wed, 04 Dec 2002 14:57:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:56 +0100 (CET) Received: (qmail 6200 invoked by uid 0); 4 Dec 2002 10:58:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 4 Dec 2002 10:58:50 -0000 Received: by moria.seul.org (Postfix) id 9D96A15E747; Wed, 4 Dec 2002 05:58:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 90DAB15E794; Wed, 4 Dec 2002 05:58:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 5582915E747 for ; Wed, 4 Dec 2002 05:58:49 -0500 (EST) Received: from club-internet.fr (flashmail-6v.cs.clubint.net [172.16.0.157]) by relay-5v.club-internet.fr (Postfix) with SMTP id BEAE61757 for ; Wed, 4 Dec 2002 11:58:55 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] simulator note - structs Date: Wed, 4 Dec 2002 11:58:48 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: devik > >Hello, > >I downloaded yg package and looked at simulator. Only >one note, would not be better to enclose inputs and >outputs of each part into struct ? >It could allow to: >- instantiate more of them (for future multiissue > designs) >- pack bits =3D> faster code without messing it >- group them logicaly and to FF clocking by assigning > whole structures where aplicable and also initialize > (clear) all lines with single cmd. that would be cool but ... the C simulator is Jaap's domain. The latest versions are at http://f-cpu.seul.org/new/?M=3DA ( http://f-cpu.seul.org/new/xbar=5Fjws=5F4=5Faug=5F2002.png ) >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Dec 4 11:48:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2C-0000HY-00 for ; Wed, 04 Dec 2002 14:57:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:52 +0100 (CET) Received: (qmail 19645 invoked by uid 0); 4 Dec 2002 10:48:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 4 Dec 2002 10:48:44 -0000 Received: by moria.seul.org (Postfix) id 8C78715E752; Wed, 4 Dec 2002 05:48:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7259515E792; Wed, 4 Dec 2002 05:48:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 1579A15E752 for ; Wed, 4 Dec 2002 05:48:42 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id 2F80F1D3D7 for ; Wed, 4 Dec 2002 11:48:41 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Wed, 4 Dec 2002 11:48:41 +0100 (CET) Message-ID: <40493.80.67.170.17.1038998921.squirrel@rezo.net> Date: Wed, 4 Dec 2002 11:48:41 +0100 (CET) Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Antoine" To: In-Reply-To: References: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >>In my opinion, an integer (or a pointer) wider than 64 bits >> really has no point. Such widths should be reserved for SIMD. > > why "reserved" ? I meant e.g. 128-bit registers could be used for 2*64, 4*32, 8*16 or 16*8, but not for a single 128-bit integer/pointer. But someone else had a point : 128-bit floats could be useful ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Dec 4 11:48:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2C-0000HY-01 for ; Wed, 04 Dec 2002 14:57:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:52 +0100 (CET) Received: (qmail 23149 invoked by uid 0); 4 Dec 2002 10:48:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 4 Dec 2002 10:48:46 -0000 Received: by moria.seul.org (Postfix) id 5DB0715E787; Wed, 4 Dec 2002 05:48:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2172615E795; Wed, 4 Dec 2002 05:48:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 9D7F515E787 for ; Wed, 4 Dec 2002 05:48:45 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id B5B621D3DA for ; Wed, 4 Dec 2002 11:48:44 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Wed, 4 Dec 2002 11:48:44 +0100 (CET) Message-ID: <40497.80.67.170.17.1038998924.squirrel@rezo.net> Date: Wed, 4 Dec 2002 11:48:44 +0100 (CET) Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Antoine" To: In-Reply-To: References: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >>In my opinion, an integer (or a pointer) wider than 64 bits >> really has no point. Such widths should be reserved for SIMD. > > why "reserved" ? I meant e.g. 128-bit registers could be used for 2*64, 4*32, 8*16 or 16*8, but not for a single 128-bit integer/pointer. But someone else had a point : 128-bit floats could be useful ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Dec 4 11:48:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2D-0000HY-00 for ; Wed, 04 Dec 2002 14:57:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:57:53 +0100 (CET) Received: (qmail 13815 invoked by uid 0); 4 Dec 2002 10:48:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 4 Dec 2002 10:48:50 -0000 Received: by moria.seul.org (Postfix) id A120015E794; Wed, 4 Dec 2002 05:48:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A95E15E799; Wed, 4 Dec 2002 05:48:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id DADBB15E794 for ; Wed, 4 Dec 2002 05:48:47 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id 34C341D3D7 for ; Wed, 4 Dec 2002 11:48:47 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Wed, 4 Dec 2002 11:48:47 +0100 (CET) Message-ID: <40500.80.67.170.17.1038998927.squirrel@rezo.net> Date: Wed, 4 Dec 2002 11:48:47 +0100 (CET) Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Antoine" To: In-Reply-To: References: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >>In my opinion, an integer (or a pointer) wider than 64 bits >> really has no point. Such widths should be reserved for SIMD. > > why "reserved" ? I meant e.g. 128-bit registers could be used for 2*64, 4*32, 8*16 or 16*8, but not for a single 128-bit integer/pointer. But someone else had a point : 128-bit floats could be useful ;) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 12:41:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2R-0000HY-00 for ; Wed, 04 Dec 2002 14:58:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:58:07 +0100 (CET) Received: (qmail 11080 invoked by uid 0); 4 Dec 2002 11:42:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 4 Dec 2002 11:42:51 -0000 Received: by moria.seul.org (Postfix) id E1C2A15E747; Wed, 4 Dec 2002 06:42:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B09A415E792; Wed, 4 Dec 2002 06:42:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3F40C15E747 for ; Wed, 4 Dec 2002 06:42:49 -0500 (EST) Received: from a6-137.dialup.iol.cz ([194.228.137.6] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JXvT-0004O9-00 for f-cpu@seul.org; Wed, 04 Dec 2002 12:42:48 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JXuD-0000Kg-00 for f-cpu@seul.org; Wed, 04 Dec 2002 12:41:29 +0100 Date: Wed, 4 Dec 2002 12:41:29 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >using sufix like .8/.16/.32 is okay but .64 is wrong > > why ?... > at least, using these numbers is not ambiguous at all. Probably because .8 is valid ONLY if SR_SIZE_0 == 1 ... But if you will use .8, .128... then assembler should generate .note in ELF to describe wanted content of SR_SIZE_[0-3] and linker should check whether only 4 values all used in all linked files. Maybe it is not bad idea at all ! By the way, I read in some older post that SIMD bit in insns is used only to mask result. So that if some core would decide to ignore the flag will it still work correctly ? IMHO it should. So that if I do non-simd add.8 I should not rely on bits 8 and higher, these can have any value, correct ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 4 12:56:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2U-0000HY-00 for ; Wed, 04 Dec 2002 14:58:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:58:10 +0100 (CET) Received: (qmail 4727 invoked by uid 0); 4 Dec 2002 11:56:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 4 Dec 2002 11:56:20 -0000 Received: by moria.seul.org (Postfix) id E92C215E752; Wed, 4 Dec 2002 06:56:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B52115E792; Wed, 4 Dec 2002 06:56:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 13A5B15E752 for ; Wed, 4 Dec 2002 06:56:18 -0500 (EST) Received: from a6-137.dialup.iol.cz ([194.228.137.6] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18JY8X-0003a3-00 for f-cpu@seul.org; Wed, 04 Dec 2002 12:56:17 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18JY8R-0000MX-00 for f-cpu@seul.org; Wed, 04 Dec 2002 12:56:11 +0100 Date: Wed, 4 Dec 2002 12:56:11 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] old GCC (Was: GCC 3.1 for F-CPU port) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > have a look at http://www.f-cpu.de/gcc/ the file doesn't exist anymore ! Have you copy of it ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Dec 4 13:00:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2X-0000HY-01 for ; Wed, 04 Dec 2002 14:58:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:58:13 +0100 (CET) Received: (qmail 29026 invoked by uid 0); 4 Dec 2002 12:04:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 4 Dec 2002 12:04:53 -0000 Received: by moria.seul.org (Postfix) id C23B915E792; Wed, 4 Dec 2002 07:04:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB14315E794; Wed, 4 Dec 2002 07:04:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 20AC815E787 for ; Wed, 4 Dec 2002 07:04:51 -0500 (EST) Received: from homeworld (81.48.95.141) by smtp.laposte.net (6.0.053) id 3DDAB921001C0B20 for f-cpu@seul.org; Wed, 4 Dec 2002 13:04:49 +0100 Message-ID: <008701c29b8c$c10ac370$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 13:00:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Well if scalar operations would only happen with 64-bit even for 128-bit FCPU registers, that's okay (that means 128-bit registers are only used for SIMD operations). I wasn't sure if you could do scalar operations with words above 64-bit. ----- Original Message ----- From: To: Sent: Wednesday, December 04, 2002 12:17 PM Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port hi, (i'm trying to catch up) >De: "Christophe Avoinne" > >Not a bad clue. > >But for 128-bit F-CPU instead of 64-bit, using ".q" would be clumsy. > >Why don't use something like : > >..l = long word, can be 64-bit or 128 bit or more >..s = single word, always 32-bit >..h = half word, always 16-bit >..q/.b = quater word, byte, always 8-bit ? > >or : > >..l = 64/128/... >..q = 4 bytes >..d = 2 bytes >..b = 1 bytes > >using sufix like .8/.16/.32 is okay but .64 is wrong why ?... at least, using these numbers is not ambiguous at all. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 17:08:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2Y-0000HY-00 for ; Wed, 04 Dec 2002 14:58:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:58:14 +0100 (CET) Received: (qmail 3323 invoked by uid 0); 4 Dec 2002 12:08:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 4 Dec 2002 12:08:48 -0000 Received: by moria.seul.org (Postfix) id 62F2615E787; Wed, 4 Dec 2002 07:08:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CD6315E795; Wed, 4 Dec 2002 07:08:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 7ABE715E787 for ; Wed, 4 Dec 2002 07:08:45 -0500 (EST) Received: from club-internet.fr (flashmail-3m.cs.clubint.net [172.16.20.62]) by relay-2m.club-internet.fr (Postfix) with SMTP id B1CBB16C6 for ; Wed, 4 Dec 2002 13:08:44 +0100 (CET) Received: from [//62.212.107.173] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 13:08:44 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: =22Antoine=22 > >>>In my opinion, an integer (or a pointer) wider than 64 bits >>> really has no point. Such widths should be reserved for SIMD. >> >> why =22reserved=22 ? > >I meant e.g. 128-bit registers could be used for 2*64, 4*32, >8*16 or 16*8, but not for a single 128-bit integer/pointer. oh, =5Fthat=5F old debate ... but then why would someone be kept from using a =22whole=22 register for holding a bitmask (for video, or whatever) or even an IPv6 address, or things like that ? integers are not the only data types out there ... my point of view is that a register doesn't necessarily contains an =22integer=22. Usually, in C, one has to cover bitmask and such under the name of =22integer=22. but i consider that as a limitation .... What if i'm dealing with a bitfield of many bits ? It's SIMD in a sense, but if there are 100 bits, then the 'integer' approach does not work nicely. However if you think in term of =22register=22 it's ok with F-CPU. This is why the size postfix would contain .128 and so on. This would trap if the CPU doesn't implement the corresponding operations, but at least ROP2 can do it ;-) >But someone else had a point : 128-bit floats could be useful ;) well, they are quite large and not much used, or useful in practice .... unless someone wants to do quantic chromodynamics or something like that =5Fand=5F comes with the adapted unit ;-) (lazy me) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Wed Dec 4 13:26:01 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ja2b-0000HY-00 for ; Wed, 04 Dec 2002 14:58:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 04 Dec 2002 14:58:17 +0100 (CET) Received: (qmail 30663 invoked by uid 0); 4 Dec 2002 12:26:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 4 Dec 2002 12:26:32 -0000 Received: by moria.seul.org (Postfix) id 3286615E742; Wed, 4 Dec 2002 07:26:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BEE1015E798; Wed, 4 Dec 2002 07:26:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 85DB215E742 for ; Wed, 4 Dec 2002 07:26:02 -0500 (EST) Received: from rezo.net (localhost [127.0.0.1]) by miel.brainstorm.fr (Postfix) with SMTP id C25B51D3EE for ; Wed, 4 Dec 2002 13:26:01 +0100 (CET) Received: from 80.67.170.17 (proxying for 193.49.124.65) (SquirrelMail authenticated user antoine) by rezo.net with HTTP; Wed, 4 Dec 2002 13:26:01 +0100 (CET) Message-ID: <44462.80.67.170.17.1039004761.squirrel@rezo.net> Date: Wed, 4 Dec 2002 13:26:01 +0100 (CET) Subject: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Antoine" To: In-Reply-To: References: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >>I meant e.g. 128-bit registers could be used for 2*64, 4*32, >>8*16 or 16*8, but not for a single 128-bit integer/pointer. > > oh, _that_ old debate ... Sorry, I don't mean to spawn it again if it already took place ;) Just for information : are some manufacturers beginning to design or think about generic-purpose 128-bit chips ? > but then why would someone be kept from using a "whole" > register for holding a bitmask (for video, or whatever) > or even an IPv6 address, or things like that ? > integers are not the only data types out there ... The question is not really whether it's useful or not, but whether these uses are critical enough to justify some complication on the compiler & developer side. As you say, bitmasks and IPv6 addresses can be stored as SIMD or even in separate registers. The only critical use of large integers may be for arithmetical operations, because it is much simpler to do a 128-bit add/mul, than several 64-bit adds/muls to emulate it. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 6 01:29:16 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8QC-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:56 +0100 (CET) Received: (qmail 16714 invoked by uid 0); 6 Dec 2002 00:29:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 6 Dec 2002 00:29:26 -0000 Received: by moria.seul.org (Postfix) id 09E9C33C6D; Thu, 5 Dec 2002 19:29:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 99E3033C65; Thu, 5 Dec 2002 19:29:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id 26D9F33C56 for ; Thu, 5 Dec 2002 19:29:18 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA00788; Fri, 6 Dec 2002 01:29:17 +0100 Message-ID: <20021206012916.45489@thrai.stud.uni-hannover.de> Date: Fri, 6 Dec 2002 01:29:16 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Manual problems and strchr optimized routine References: <200212042247.13589.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212042247.13589.cedric.bail@free.fr>; from cedric on Wed, Dec 04, 2002 at 10:47:13PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 10:47:13PM +0000, cedric wrote: > In fact I don't see your message before... > > > ** logic > > There might be explained what is meant by andn. These > > can be found at page 54 but is missing in OPs reference page. > > I don't understand what you mean by "missing in OPs reference page" (I fint it > page page 149). But in fact if you ask to see something like this : > r1 = r2 andn r3, I am not sure it's needed. Oh yes, badly! -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 4 18:01:39 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q9-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:53 +0100 (CET) Received: (qmail 11438 invoked by uid 0); 6 Dec 2002 00:08:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 6 Dec 2002 00:08:39 -0000 Received: by moria.seul.org (Postfix) id 8D38233D9A; Thu, 5 Dec 2002 20:02:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EBDE33DAF; Thu, 5 Dec 2002 20:01:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 448E733DDB for ; Thu, 5 Dec 2002 19:55:34 -0500 (EST) Received: from tribble.stud.uni-hannover.de (a085.home.uni-hannover.de [130.75.232.85]) by bettik.munge.net (Postfix) with ESMTP id 71F214FB15 for ; Wed, 4 Dec 2002 16:26:18 -0600 (CST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00884; Wed, 4 Dec 2002 18:01:40 +0100 Message-ID: <20021204180139.57876@thrai.stud.uni-hannover.de> Date: Wed, 4 Dec 2002 18:01:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Dec 04, 2002 at 12:41:29PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 12:41:29PM +0100, devik wrote: > > >using sufix like .8/.16/.32 is okay but .64 is wrong > > > > why ?... > > at least, using these numbers is not ambiguous at all. > > Probably because .8 is valid ONLY if SR_SIZE_0 == 1 ... > But if you will use .8, .128... then assembler should > generate .note in ELF to describe wanted content of > SR_SIZE_[0-3] and linker should check whether only > 4 values all used in all linked files. > Maybe it is not bad idea at all ! Minor objection: according to the ELF standard, a .note section MUST NOT change the semantics of a program. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Dec 4 23:57:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q9-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:53 +0100 (CET) Received: (qmail 27259 invoked by uid 0); 6 Dec 2002 00:08:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 6 Dec 2002 00:08:38 -0000 Received: by moria.seul.org (Postfix) id A540D33CB6; Thu, 5 Dec 2002 20:02:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29C8E33DF6; Thu, 5 Dec 2002 20:01:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 6677533E58 for ; Thu, 5 Dec 2002 19:56:56 -0500 (EST) Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by bettik.munge.net (Postfix) with ESMTP id 86EA74FC38 for ; Wed, 4 Dec 2002 16:08:15 -0600 (CST) Received: from thor (198.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.198]) by smtp4.9tel.net (Postfix) with ESMTP id C41825BE87 for ; Wed, 4 Dec 2002 23:09:31 +0100 (CET) Content-Type: text/plain; charset="iso-8859-2" From: cedric To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 22:57:11 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212042257.11062.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > >which is without possible stall. Of course the "stall" slot > > > >will be probably used by compiler but not always. Do you > > > >know better code for small negatives ? > > I was thinking that 8 bits immediates were signed. For other you need to > > use widden, but I was thinking that it only take one cycle. So I don't > > understand your stall. > manual says (well I had to look into .tex for it) that widen has Interresting, I forgot to include widen.tex... > 1 cycle latency (it is regular EU, not as move or loadcons whose > emits value directly from decode FFs to xbar). Because gcc currently > can't schedule across basic blocks it often stalls at next insn after > widen. I am perhaps wrong but I think that bypass solve this problem (In fact if we have a loadconsx, I think that it will use the same EU as widen). And in fact a latency of one is like having the result ready for next instruction. Is it true, Yann ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Dec 4 23:15:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q8-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:52 +0100 (CET) Received: (qmail 9587 invoked by uid 0); 6 Dec 2002 00:08:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Dec 2002 00:08:10 -0000 Received: by moria.seul.org (Postfix) id 2672C33CD1; Thu, 5 Dec 2002 19:49:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BC3633CB1; Thu, 5 Dec 2002 19:49:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id CEDD233C90 for ; Thu, 5 Dec 2002 19:48:49 -0500 (EST) Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by bettik.munge.net (Postfix) with ESMTP id 6B3B74FA2B for ; Wed, 4 Dec 2002 15:29:55 -0600 (CST) Received: from thor (198.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.198]) by smtp3.9tel.net (Postfix) with ESMTP id 695DB5C08A for ; Wed, 4 Dec 2002 22:28:02 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Rep:Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 22:15:41 +0000 User-Agent: KMail/1.4.3 References: <200212041014.3a48@th00.opsion.fr> In-Reply-To: <200212041014.3a48@th00.opsion.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212042215.41962.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >> there are several F-CPU assemblers now. > >> even though i don't know which one to trust :-P > >> everyone with a specific syntax, unique features etc ... > >> > >:) Are there reasons other than personal ego ? Like > > > >if all wants their own assembler ? And are these > >documented so that I can select one ? > > nobody is "happy" with other's SW. > unfortunately they are loosely documented, > and the only discriminating factor is whether it works ... > > >>>Cedric and Alex have written a pretty complete generic assembler > working with x86 and fcpu. IT's pretty fast and modular. It seems that > they didn't release it now because they have udge work on documentation. > So Cedric, time is up ! Show your code ! Wait, we have some little bug to correct before, but you will see it tomorrow at the "first jeudi". It currently support rawbin + elf (32/64) + hex for F-CPU and x86. We are currently working on macro and solving some problem with elf and memory management. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Dec 4 23:47:13 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q6-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:50 +0100 (CET) Received: (qmail 8563 invoked by uid 0); 6 Dec 2002 00:06:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 6 Dec 2002 00:06:48 -0000 Received: by moria.seul.org (Postfix) id A474B33D06; Thu, 5 Dec 2002 19:51:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0DDB33C77; Thu, 5 Dec 2002 19:50:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 0018033D08 for ; Thu, 5 Dec 2002 19:49:52 -0500 (EST) Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by bettik.munge.net (Postfix) with ESMTP id 3C64A4FBDD for ; Wed, 4 Dec 2002 15:58:18 -0600 (CST) Received: from thor (198.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.198]) by smtp3.9tel.net (Postfix) with ESMTP id 883CC5C012 for ; Wed, 4 Dec 2002 22:59:34 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Manual problems and strchr optimized routine Date: Wed, 4 Dec 2002 22:47:13 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212042247.13589.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N In fact I don't see your message before... > ** logic > There might be explained what is meant by andn. These > can be found at page 54 but is missing in OPs reference page. I don't understand what you mean by "missing in OPs reference page" (I fint it page page 149). But in fact if you ask to see something like this : r1 = r2 andn r3, I am not sure it's needed. > ** cand/cor > There might be mentioned that is sets ALL bits of word to > the result of and/or of bits. Because problem with mux insn > I wasn't even understand it from examples :( COR/CAND/MUX definition was copy/paste from a text that quickly write Yann about this instruction. So some clarification in the description are still needed. > ** mux > The description doesn't make sense as English sentence to me. > Also from ROP2-YG-2001201.tgz sources it seems that mux is > done bitwise, so that what is a size flag here for ? I understand mux as a SIMD conditionnal move, but it's perhaps an error of interpretation (For the sense problem, I think I forgot to copy/past a part of the original text). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Dec 4 21:17:18 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q6-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:50 +0100 (CET) Received: (qmail 27939 invoked by uid 0); 6 Dec 2002 00:06:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 6 Dec 2002 00:06:19 -0000 Received: by moria.seul.org (Postfix) id 6B19133FD8; Thu, 5 Dec 2002 19:57:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A78833F07; Thu, 5 Dec 2002 19:56:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id DB6B533C75 for ; Thu, 5 Dec 2002 19:39:49 -0500 (EST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by bettik.munge.net (Postfix) with ESMTP id CA7054F9BB for ; Wed, 4 Dec 2002 15:40:18 -0600 (CST) Received: from yahoo.fr (nas-cbv-5-62-147-145-84.dial.proxad.net [62.147.145.84]) by postfix4-2.free.fr (Postfix) with ESMTP id AE2A4C0FF for ; Wed, 4 Dec 2002 22:41:03 +0100 (CET) Message-ID: <3DEE62CE.2030801@yahoo.fr> Date: Wed, 04 Dec 2002 21:17:18 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] date format at f-cpu.seul.org/ References: Content-Type: multipart/related; boundary="------------090203010909000806070001" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --------------090203010909000806070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, whygee@club-internet.fr a écrit: >hi ! > >just want to know whether it's ok if i manually modify the >file names at http://f-cpu.seul.org/new/ > ==> adopting the ISO/ANSI/whatever standard format >would make it a bit more readable .... > >for example, >http://f-cpu.seul.org/new/Snapshot_jws_19_07_2002.tar.bz2 >would become >http://f-cpu.seul.org/new/Snapshot_jws_20020719.tar.bz2 > > I thinks than : http://f-cpu.seul.org/new/20020719_Snapshot_jws.tar.bz2 is better, for sort aspect ;-) >the only problem is when day and month are ambiguous .... > > Not important, if everybody known the format, and only during the 12th first day of month. Possible solution :-? Don't make snapshot between le 1st and the 12th of any months :-D >is it ok ? > >YG > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 --------------090203010909000806070001-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 4 17:53:35 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q5-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:49 +0100 (CET) Received: (qmail 9022 invoked by uid 0); 6 Dec 2002 00:05:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Dec 2002 00:05:59 -0000 Received: by moria.seul.org (Postfix) id E58A833FAC; Thu, 5 Dec 2002 19:57:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1664C33F41; Thu, 5 Dec 2002 19:55:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 97B7E33ED7 for ; Thu, 5 Dec 2002 19:54:45 -0500 (EST) Received: from tribble.stud.uni-hannover.de (a085.home.uni-hannover.de [130.75.232.85]) by bettik.munge.net (Postfix) with ESMTP id BFA594FB11 for ; Wed, 4 Dec 2002 16:26:16 -0600 (CST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00850; Wed, 4 Dec 2002 17:53:35 +0100 Message-ID: <20021204175335.16461@thrai.stud.uni-hannover.de> Date: Wed, 4 Dec 2002 17:53:35 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port References: <200212032014.10177.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Dec 04, 2002 at 08:25:40AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 08:25:40AM +0100, devik wrote: > > We are planning to do a documentation for our assembler, but it take a lot of > > time to write it (more than to code it in fact ;-). > > good. Did anyone attempted to port gas ? It could benefit > from having ELF lin and linker in place ... My assembler produces ELF files. The linker is not ready yet. Unfortunately, the latest changes to the instruction set aren't incorporated into as yet - I'm waiting for things to settle down. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lee.salzman@lvdi.net Wed Dec 4 15:19:50 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q4-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:48 +0100 (CET) Received: (qmail 32625 invoked by uid 0); 6 Dec 2002 00:05:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 6 Dec 2002 00:05:06 -0000 Received: by moria.seul.org (Postfix) id 90B3E33F8C; Thu, 5 Dec 2002 19:56:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A5E533F39; Thu, 5 Dec 2002 19:55:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 380B933DAD for ; Thu, 5 Dec 2002 19:55:33 -0500 (EST) Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by bettik.munge.net (Postfix) with ESMTP id 75E154FBFC for ; Wed, 4 Dec 2002 14:34:01 -0600 (CST) Received: from lvdi.net ([216.24.138.2]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id gB4KZEn15023 for ; Wed, 4 Dec 2002 15:35:15 -0500 Received: from wyrm ([205.201.42.12]) by lvdi.net ; Wed, 04 Dec 2002 06:29:57 2000 PDT Received: from lee by wyrm with local (Exim 3.35 #1 (Debian)) id 18JaNS-0008Ut-00 for ; Wed, 04 Dec 2002 09:19:50 -0500 Date: Wed, 4 Dec 2002 09:19:50 -0500 To: f-cpu@seul.org Subject: Re: [f-cpu] old GCC (Was: GCC 3.1 for F-CPU port) Message-ID: <20021204141950.GA32554@wyrm> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Lee Salzman Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 12:56:11PM +0100, devik wrote: > > have a look at http://www.f-cpu.de/gcc/ > > the file doesn't exist anymore ! Have you copy of it ? > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ Sorry, my old site got taken down. Anyway, I put up a copy of the old code at: http://tunes.org/~eihrul/gcc-2.95.2-fcpu.tar.gz ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 19:23:50 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q3-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:47 +0100 (CET) Received: (qmail 4756 invoked by uid 0); 6 Dec 2002 00:01:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Dec 2002 00:01:40 -0000 Received: by moria.seul.org (Postfix) id 1B65533F4A; Thu, 5 Dec 2002 19:57:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5203633CFB; Thu, 5 Dec 2002 19:56:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 8638133C60 for ; Thu, 5 Dec 2002 19:39:42 -0500 (EST) Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by bettik.munge.net (Postfix) with ESMTP id C1EA34F89B for ; Wed, 4 Dec 2002 08:27:34 -0600 (CST) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-5v.club-internet.fr (Postfix) with SMTP id CAEF91738 for ; Wed, 4 Dec 2002 15:23:57 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] old GCC (Was: GCC 3.1 for F-CPU port) Date: Wed, 4 Dec 2002 15:23:50 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: devik >> have a look at http://www.f-cpu.de/gcc/ >the file doesn't exist anymore =21 Have you copy of it ? aaarghh =21 i should have a copy of it at home. but it will take a few days till i get there. unless there is a copy somewhere on the net. >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 4 17:59:39 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q3-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:47 +0100 (CET) Received: (qmail 3458 invoked by uid 0); 6 Dec 2002 00:01:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Dec 2002 00:01:16 -0000 Received: by moria.seul.org (Postfix) id 18D0433D4B; Thu, 5 Dec 2002 19:50:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E4C333D49; Thu, 5 Dec 2002 19:50:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id B0E5133D07 for ; Thu, 5 Dec 2002 19:49:52 -0500 (EST) Received: from tribble.stud.uni-hannover.de (a085.home.uni-hannover.de [130.75.232.85]) by bettik.munge.net (Postfix) with ESMTP id 3C57A4FB19 for ; Wed, 4 Dec 2002 16:26:20 -0600 (CST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00873; Wed, 4 Dec 2002 17:59:39 +0100 Message-ID: <20021204175939.48599@thrai.stud.uni-hannover.de> Date: Wed, 4 Dec 2002 17:59:39 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] manual 0.27c References: <20021204102408.GA2134@eischer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20021204102408.GA2134@eischer.net>; from Karl-Heinz Eischer on Wed, Dec 04, 2002 at 11:24:08AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 11:24:08AM +0100, Karl-Heinz Eischer wrote: > the manual states on page 88 (instruction sub): > > The borrow flag (same as carry) indicates that the borrow value is written > to register number (r1^1). If no borrow has been generated, the neighbour > register is cleared, otherwise the neighbour register is set to 1. > > The examples show that it is set to 0xFF. Furthermore there is the order > inconsitent is the description. First it states r2 - r3 and a few lines > later (r3 - r2). The example shows r2 - r3. When I implemented EU_ASU, I noticed that it's much simpler to set the borrow register to `1' instead of `-1' (all ones). It also matches the carry output of the addc operation, and is more logical: we borrow 1, not -1 (borrowing -1 means adding 1). That is, the example is wrong. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 4 17:55:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q2-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:46 +0100 (CET) Received: (qmail 2089 invoked by uid 0); 5 Dec 2002 23:57:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 5 Dec 2002 23:57:00 -0000 Received: by moria.seul.org (Postfix) id 73A3633C76; Thu, 5 Dec 2002 19:49:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B1C133C98; Thu, 5 Dec 2002 19:48:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 4CC1C33C83 for ; Thu, 5 Dec 2002 19:48:45 -0500 (EST) Received: from tribble.stud.uni-hannover.de (a085.home.uni-hannover.de [130.75.232.85]) by bettik.munge.net (Postfix) with ESMTP id C6C1F4FAB4 for ; Wed, 4 Dec 2002 16:26:14 -0600 (CST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00859; Wed, 4 Dec 2002 17:55:41 +0100 Message-ID: <20021204175541.61219@thrai.stud.uni-hannover.de> Date: Wed, 4 Dec 2002 17:55:41 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port References: <20021203215130.59169@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Dec 04, 2002 at 08:42:13AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 04, 2002 at 08:42:13AM +0100, devik wrote: > Do you really output ELF ?? Yes. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 19:21:59 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q5-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:49 +0100 (CET) Received: (qmail 4354 invoked by uid 0); 6 Dec 2002 00:05:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 6 Dec 2002 00:05:46 -0000 Received: by moria.seul.org (Postfix) id 7933033EAB; Thu, 5 Dec 2002 19:54:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6559D33E70; Thu, 5 Dec 2002 19:53:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D680F33D57 for ; Thu, 5 Dec 2002 19:53:13 -0500 (EST) Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by bettik.munge.net (Postfix) with ESMTP id 07EDE4F662 for ; Wed, 4 Dec 2002 08:25:44 -0600 (CST) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-1v.club-internet.fr (Postfix) with SMTP id 02533173A for ; Wed, 4 Dec 2002 15:21:40 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 15:21:59 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: devik >> >using sufix like .8/.16/.32 is okay but .64 is wrong >> >> why ?... >> at least, using these numbers is not ambiguous at all. > >Probably because .8 is valid ONLY if SR=5FSIZE=5F0 =3D=3D 1 ... and what ? >But if you will use .8, .128... then assembler should >generate .note in ELF to describe wanted content of >SR=5FSIZE=5F=5B0-3=5D and linker should check whether only >4 values all used in all linked files. >Maybe it is not bad idea at all =21 heheh. There is also a little convention : SR=5FSIZE=5F3 contains the largest size. This way, algorithms that need the largest size (for maximal performance) do not need to fiddle with SRs. But this can be changed or enhanced. >By the way, I read in some older post that SIMD bit >in insns is used only to mask result. well, that's how it's implemented in FC0. > So that if some core would decide to ignore the flag > will it still work correctly ? more or less. >IMHO it should. yup but C=E9dric said the contrary (at least from the compiler's point of view). > So that if I do non-simd add.8 (that can be also named =22scalar=22 :-D) > I should not rely on bits 8 and higher, these can have > any value, correct ? now, the mask clears the MSB so you can rely on this to be zero. If you have no idea whether SIMD flag is set, then you can't rely on MSB. but at least the LSB are sure :-) >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 4 14:12:37 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q7-0007Fw-00 for ; Fri, 06 Dec 2002 03:40:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:51 +0100 (CET) Received: (qmail 4392 invoked by uid 0); 6 Dec 2002 00:07:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Dec 2002 00:07:06 -0000 Received: by moria.seul.org (Postfix) id 90C4333E09; Thu, 5 Dec 2002 20:01:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A721733F22; Thu, 5 Dec 2002 19:59:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D3E7133E01 for ; Thu, 5 Dec 2002 19:58:04 -0500 (EST) Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by bettik.munge.net (Postfix) with SMTP id D7C8B4F95E for ; Wed, 4 Dec 2002 08:20:17 -0600 (CST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212041312.2551; Wed, 4 Dec 2002 13:12:37 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Dec 2002 13:12:37 GMT Message-id: <200212041312.2551@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: whygee@club-internet.fr A: f-cpu@seul.org Date: 04/12/02 Objet: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port hi, >De: "Antoine" > >>>In my opinion, an integer (or a pointer) wider than 64 bi= ts >>> really has no point. Such widths should be reserved for = SIMD. >> >> why "reserved" ? > >I meant e.g. 128-bit registers could be used for 2*64, 4*32= , >8*16 or 16*8, but not for a single 128-bit integer/pointer. oh, _that_ old debate ... >>>yep ! But you rebegin... From one hand, you want to keep = the binary compatibility with the SIMD growing size, and you to make ch= oose of the size of scalar type ??? that's not consistent. If you need m= anipulate bitfield you must used inter-chunk instruction (there is a b= ig lack of it because you ever think with the 64 bits register in mind,= so all interchunk op are mais thought the 64 bits scalar size) Mainly if you have a 64 bits register, you will have "somewh= ere" the 64 that goes inside complexity (o(n), o(ln(n)), o(n*log(n)), th= ink of a 128 bit shifter...). If n is wider (128 bits!) you will decrease= the speed of the code for very very specific operation, where most of = the time inter-chunk op will be enough (inter-chunk instruction will = have the complexity of the number of chunks). but then why would someone be kept from using a "whole" register for holding a bitmask (for video, or whatever) or even an IPv6 address, or things like that ? integers are not the only data types out there ... >>>that's so specific... We don't make a dsp or even a netwo= rk cpu. Do forget that such feature will slow down the clock ! my point of view is that a register doesn't necessarily contains an "integer". Usually, in C, one has to cover bitmask and such under the name of "integer". but i consider that as a limitation .... What if i'm dealing with a bitfiel= d of many bits ? It's SIMD in a sense, but if there are 100 bi= ts, then the 'integer' approach does not work nicely. >>>That's the internal gcc stuff to handle bitfield the righ= t way. However if you think in term of "register" it's ok with F-CP= U. This is why the size postfix would contain .128 and so on. This would trap if the CPU doesn't implement the corresponding operations, but at least ROP2 can do it ;-) >>>Forget the idea of emulate none existing instruction !! A= ntoine have demonstrate that will be a real mess. And the performance wi= ll suffer a lot. We make free softawre. So recompile ! >But someone else had a point : 128-bit floats could be usef= ul ;) well, they are quite large and not much used, or useful in practice .... unless someone wants to do quantic >>>All stuff like Maya or synthetic image. I even think that= spice use long double (80 bit on x86, 128 on Sparc) chromodynamics or something like that _and_ comes with the adapted unit ;-) (lazy me) >>>yep :) YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 4 20:50:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18K8Q8-0007Fw-01 for ; Fri, 06 Dec 2002 03:40:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 03:40:52 +0100 (CET) Received: (qmail 11029 invoked by uid 0); 6 Dec 2002 00:08:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Dec 2002 00:08:30 -0000 Received: by moria.seul.org (Postfix) id A983F33DC2; Thu, 5 Dec 2002 20:02:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F5E233DC1; Thu, 5 Dec 2002 20:00:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 5CC243401D for ; Thu, 5 Dec 2002 19:58:25 -0500 (EST) Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by bettik.munge.net (Postfix) with ESMTP id 5CDBB4F90E for ; Wed, 4 Dec 2002 10:11:22 -0600 (CST) Received: from club-internet.fr (flashmail-3m.cs.clubint.net [172.16.20.62]) by relay-3m.club-internet.fr (Postfix) with SMTP id A2B30E13C for ; Wed, 4 Dec 2002 16:50:37 +0100 (CET) Received: from [//62.212.107.173] by flashmail-m.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Wed, 4 Dec 2002 16:50:19 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: =22Antoine=22 > >>>I meant e.g. 128-bit registers could be used for 2*64, 4*32, >>>8*16 or 16*8, but not for a single 128-bit integer/pointer. >> >> oh, =5Fthat=5F old debate ... > >Sorry, I don't mean to spawn it again if it already took place ;) don't worry. >Just for information : are some manufacturers beginning >to design or think about generic-purpose 128-bit chips ? i think so. >> but then why would someone be kept from using a =22whole=22 >> register for holding a bitmask (for video, or whatever) >> or even an IPv6 address, or things like that ? >> integers are not the only data types out there ... > >The question is not really whether it's useful or not, >but whether these uses are critical enough to justify >some complication on the compiler & developer side. well, what is complex ? a register is a collection of bits, that can be grouped in many ways. Some are supported directly, others can be =22emulated=22, and in this last case, having access to the register size in important (ie, 128 bits for IPv6) without being bound to integer types. Shifts and rotations are very useful for a lot of applications, not only for =22numbers=22 (integer or FP). >As you say, bitmasks and IPv6 addresses can be stored >as SIMD or even in separate registers. =22separate=22 ? > The only critical >use of large integers may be for arithmetical operations, >because it is much simpler to do a 128-bit add/mul, >than several 64-bit adds/muls to emulate it. The whole point is to not think =221 register <=3D> 1 number=22. SIMD is one way, but there are others. Some operations make sense for certain types, but generic things like ROP2 or SHL have broader uses. ok, i ranted enough for today ;-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Dec 6 11:13:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIy8-0000GL-00 for ; Fri, 06 Dec 2002 14:56:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:40 +0100 (CET) Received: (qmail 13763 invoked by uid 0); 6 Dec 2002 09:59:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 6 Dec 2002 09:59:57 -0000 Received: by moria.seul.org (Postfix) id BFC9F33CBC; Fri, 6 Dec 2002 04:59:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 30EC933CD2; Fri, 6 Dec 2002 04:59:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C332533CBC for ; Fri, 6 Dec 2002 04:59:55 -0500 (EST) Received: from f-cpu.org (lcbv1-1-89.n.club-internet.fr [213.44.3.89]) by relay-1v.club-internet.fr (Postfix) with ESMTP id B94F9168E for ; Fri, 6 Dec 2002 10:59:32 +0100 (CET) Message-ID: <3DF07855.2090806@f-cpu.org> Date: Fri, 06 Dec 2002 11:13:41 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port References: <200212042257.11062.cedric.bail@free.fr> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! i still have to read the manual, but i have no time yet :-((( cedric wrote: >>>>>which is without possible stall. Of course the "stall" slot >>>>>will be probably used by compiler but not always. Do you >>>>>know better code for small negatives ? >>>>> >>>>> >>>I was thinking that 8 bits immediates were signed. For other you need to >>>use widden, but I was thinking that it only take one cycle. So I don't >>>understand your stall. >>> >>> >>manual says (well I had to look into .tex for it) that widen has >> >> > >Interresting, I forgot to include widen.tex... > >>1 cycle latency (it is regular EU, not as move or loadcons whose >>emits value directly from decode FFs to xbar). Because gcc currently >>can't schedule across basic blocks it often stalls at next insn after >>widen. >> >> > >I am perhaps wrong but I think that bypass solve this problem > ? >(In fact if we >have a loadconsx, I think that it will use the same EU as widen). > your're thinking in terms of "your new loadcons", right ? because otherwise there would not even need to be an execution unit. > And in fact a latency of one is like having the result ready > > for next instruction. Is it true, Yann ? > > *beep* false : it means that you have to put one NOP or another instruction before you can use the result. your idea would hold for the "oldfashioned" loadcons but IIRC it was "changed" .... alors maintenant, "faut assumer" :-P >Cedric > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Dec 6 11:20:09 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyD-0000GL-01 for ; Fri, 06 Dec 2002 14:56:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:45 +0100 (CET) Received: (qmail 1032 invoked by uid 0); 6 Dec 2002 10:41:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 6 Dec 2002 10:41:17 -0000 Received: by moria.seul.org (Postfix) id 0241833CD1; Fri, 6 Dec 2002 05:06:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 95FDA33CD3; Fri, 6 Dec 2002 05:06:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id D1F8633CD1 for ; Fri, 6 Dec 2002 05:06:20 -0500 (EST) Received: from f-cpu.org (lcbv4-2-28.n.club-internet.fr [213.44.93.28]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 088F91699 for ; Fri, 6 Dec 2002 11:06:27 +0100 (CET) Message-ID: <3DF079D9.5000705@f-cpu.org> Date: Fri, 06 Dec 2002 11:20:09 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] date format at f-cpu.seul.org/ References: <3DEE62CE.2030801@yahoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N oooops i didn't see this one .... (i guess that a lot are still awaiting for an answer) Just an Illusion wrote: > Hi, > > whygee@club-internet.fr a écrit: > >> hi ! >> >> just want to know whether it's ok if i manually modify the >> file names at http://f-cpu.seul.org/new/ >> ==> adopting the ISO/ANSI/whatever standard format >> would make it a bit more readable .... >> >> for example, >> http://f-cpu.seul.org/new/Snapshot_jws_19_07_2002.tar.bz2 >> would become >> http://f-cpu.seul.org/new/Snapshot_jws_20020719.tar.bz2 >> >> > I thinks than : > > http://f-cpu.seul.org/new/20020719_Snapshot_jws.tar.bz2 > > is better, for sort aspect ;-) oh no. but anyway, then, just use the sort capabilities of the seul.org server if you really want to sort ALL files. >> the only problem is when day and month are ambiguous .... > > Not important, if everybody known the format, and only during the 12th > first day of month. > Possible solution :-? Don't make snapshot between le 1st and the 12th > of any months :-D :-P have fun, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 12:15:51 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyP-0000GL-00 for ; Fri, 06 Dec 2002 14:56:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:57 +0100 (CET) Received: (qmail 27792 invoked by uid 0); 6 Dec 2002 12:30:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 6 Dec 2002 12:30:42 -0000 Received: by moria.seul.org (Postfix) id D9BA233CDC; Fri, 6 Dec 2002 07:30:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 45A6733CE7; Fri, 6 Dec 2002 07:30:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id A123533CDC for ; Fri, 6 Dec 2002 07:30:39 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id E66EC4F8B0 for ; Fri, 6 Dec 2002 06:29:18 -0600 (CST) Received: from a5-137.dialup.iol.cz ([194.228.137.5] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KHcd-0005xj-00 for f-cpu@seul.org; Fri, 06 Dec 2002 13:30:25 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KGSV-0000D6-00 for f-cpu@seul.org; Fri, 06 Dec 2002 12:15:51 +0100 Date: Fri, 6 Dec 2002 12:15:51 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >> at least, using these numbers is not ambiguous at all. > > > >Probably because .8 is valid ONLY if SR_SIZE_0 == 1 ... > > and what ? ehm .. if you use .8 => SIZE_BITS(00) and run with SR_SIZE_0=16 .... it will do something unexpected (unless assembler emit that it expects SR_SIZE_0 is 8) :) > There is also a little convention : SR_SIZE_3 contains > the largest size. This way, algorithms that need the largest > size (for maximal performance) do not need to fiddle with > SRs. But this can be changed or enhanced. Let me speculate a bit. You want forward compatible CPU. So if one compiles program for 64 bit FC0 he assumes SR_SIZE_3=64 (or 4 or 8 - I'm not sure with semantics). If you now have 128bit FC0 (will it be still FC0?) then you could still run that program - OS loader will load SR_SIZE map from ELF PHDR and apply it for given task. But here SR_SIZE_3=64 not 128 so that the convention doesn't hold. > > I should not rely on bits 8 and higher, these can have > > any value, correct ? > > now, the mask clears the MSB so you can rely on this to be zero. Hmm .. but then the code will not be compatible with CPUs which don't implement the masking. Will it be mandatory on all F-CPUs to clear it ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 10:37:51 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyP-0000GL-01 for ; Fri, 06 Dec 2002 14:56:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:57 +0100 (CET) Received: (qmail 15047 invoked by uid 0); 6 Dec 2002 12:30:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 6 Dec 2002 12:30:46 -0000 Received: by moria.seul.org (Postfix) id 1D6C933CE7; Fri, 6 Dec 2002 07:30:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9285A33CE9; Fri, 6 Dec 2002 07:30:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D9F1733CE7 for ; Fri, 6 Dec 2002 07:30:41 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 7E5124F8B3 for ; Fri, 6 Dec 2002 06:29:21 -0600 (CST) Received: from a5-137.dialup.iol.cz ([194.228.137.5] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KHch-0005xj-00 for f-cpu@seul.org; Fri, 06 Dec 2002 13:30:29 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KEvf-0000CG-00 for f-cpu@seul.org; Fri, 06 Dec 2002 10:37:51 +0100 Date: Fri, 6 Dec 2002 10:37:51 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <20021204180139.57876@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > But if you will use .8, .128... then assembler should > > generate .note in ELF to describe wanted content of > > SR_SIZE_[0-3] and linker should check whether only > > 4 values all used in all linked files. > > Maybe it is not bad idea at all ! > > Minor objection: according to the ELF standard, a .note section MUST > NOT change the semantics of a program. Hehe it is evident that you are messing with ELF just now :) It is long time I read the specs :) So let's create new section for that :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 10:21:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyQ-0000GL-00 for ; Fri, 06 Dec 2002 14:56:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:58 +0100 (CET) Received: (qmail 25598 invoked by uid 0); 6 Dec 2002 12:30:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 6 Dec 2002 12:30:52 -0000 Received: by moria.seul.org (Postfix) id CC53D33CEE; Fri, 6 Dec 2002 07:30:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F28033CEC; Fri, 6 Dec 2002 07:30:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 3B80133CEA for ; Fri, 6 Dec 2002 07:30:44 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 51B934F852 for ; Fri, 6 Dec 2002 06:29:23 -0600 (CST) Received: from a5-137.dialup.iol.cz ([194.228.137.5] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KHcv-0005xj-00 for f-cpu@seul.org; Fri, 06 Dec 2002 13:30:42 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KEfy-0000C0-00 for f-cpu@seul.org; Fri, 06 Dec 2002 10:21:38 +0100 Date: Fri, 6 Dec 2002 10:21:38 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] old GCC (Was: GCC 3.1 for F-CPU port) In-Reply-To: <20021204141950.GA32554@wyrm> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Sorry, my old site got taken down. Anyway, I put up a copy of > the old code at: > http://tunes.org/~eihrul/gcc-2.95.2-fcpu.tar.gz Good news :) Thanks. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 10:30:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyQ-0000GL-01 for ; Fri, 06 Dec 2002 14:56:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:56:58 +0100 (CET) Received: (qmail 32590 invoked by uid 0); 6 Dec 2002 12:30:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 6 Dec 2002 12:30:59 -0000 Received: by moria.seul.org (Postfix) id 36EB133CEA; Fri, 6 Dec 2002 07:30:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2A6B33CF0; Fri, 6 Dec 2002 07:30:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id C146E33CEA for ; Fri, 6 Dec 2002 07:30:47 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 303E54F8B5 for ; Fri, 6 Dec 2002 06:29:27 -0600 (CST) Received: from a5-137.dialup.iol.cz ([194.228.137.5] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KHcz-0005xj-00 for f-cpu@seul.org; Fri, 06 Dec 2002 13:30:45 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KEoT-0000C8-00 for f-cpu@seul.org; Fri, 06 Dec 2002 10:30:25 +0100 Date: Fri, 6 Dec 2002 10:30:25 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Manual problems and strchr optimized routine In-Reply-To: <200212042247.13589.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > ** logic > > There might be explained what is meant by andn. These > > can be found at page 54 but is missing in OPs reference page. > > I don't understand what you mean by "missing in OPs reference page" (I fint it > page page 149). But in fact if you ask to see something like this : > r1 = r2 andn r3, I am not sure it's needed. No I only wanted to see that andn is "r2 and not r3" because on i386 it is "not r2 and r3" for example. > > ** mux > > The description doesn't make sense as English sentence to me. > > Also from ROP2-YG-2001201.tgz sources it seems that mux is > > done bitwise, so that what is a size flag here for ? > > I understand mux as a SIMD conditionnal move, but it's perhaps an error of > interpretation (For the sense problem, I think I forgot to copy/past a part > of the original text). ahh probably. For me MUX makes more sense in bitwise meaning because it is superset of SIMD conditional move but more generic and SIMPLER to implement .. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Dec 6 14:04:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyg-0000GL-00 for ; Fri, 06 Dec 2002 14:57:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:57:14 +0100 (CET) Received: (qmail 13652 invoked by uid 0); 6 Dec 2002 13:09:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 6 Dec 2002 13:09:19 -0000 Received: by moria.seul.org (Postfix) id A02D933CDC; Fri, 6 Dec 2002 08:09:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C7EA933CE9; Fri, 6 Dec 2002 08:09:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2C3AD33CDC for ; Fri, 6 Dec 2002 08:09:16 -0500 (EST) Received: from homeworld (81.48.95.113) by smtp.laposte.net (6.0.053) id 3DDAB944002141B6 for f-cpu@seul.org; Fri, 6 Dec 2002 14:09:15 +0100 Message-ID: <000201c29d28$126ed020$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] Manual problems and strchr optimized routine Date: Fri, 6 Dec 2002 14:04:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "devik" To: Sent: Friday, December 06, 2002 10:30 AM Subject: Re: [f-cpu] Manual problems and strchr optimized routine > > > ** logic > > > There might be explained what is meant by andn. These > > > can be found at page 54 but is missing in OPs reference page. > > > > I don't understand what you mean by "missing in OPs reference page" (I fint it > > page page 149). But in fact if you ask to see something like this : > > r1 = r2 andn r3, I am not sure it's needed. > > No I only wanted to see that andn is "r2 and not r3" because > on i386 it is "not r2 and r3" for example. I don't remember that i386 has "andn" instruction !? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 14:14:09 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyo-0000GL-00 for ; Fri, 06 Dec 2002 14:57:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:57:22 +0100 (CET) Received: (qmail 25706 invoked by uid 0); 6 Dec 2002 13:35:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 6 Dec 2002 13:35:56 -0000 Received: by moria.seul.org (Postfix) id 6C5D233CEB; Fri, 6 Dec 2002 08:35:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08AB933CEF; Fri, 6 Dec 2002 08:35:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 58C5A33CEB for ; Fri, 6 Dec 2002 08:35:54 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id BC49D4F833 for ; Fri, 6 Dec 2002 07:34:33 -0600 (CST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KIdm-00067K-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:35:39 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KIIz-0000HN-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:14:09 +0100 Date: Fri, 6 Dec 2002 14:14:09 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <200212042257.11062.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > 1 cycle latency (it is regular EU, not as move or loadcons whose > > emits value directly from decode FFs to xbar). Because gcc currently > > can't schedule across basic blocks it often stalls at next insn after > > widen. > > I am perhaps wrong but I think that bypass solve this problem (In fact if we > have a loadconsx, I think that it will use the same EU as widen). And in fact > a latency of one is like having the result ready for next instruction. Is it > true, Yann ? loadcons widen add sequence with the same reg: xbar_in xbar_out BSU_input BSU_output decoder_out_insn c loadcons c c c widen wc wc (stall) wc(bypass) add So that there will be stall (almost surely). When I hacked on GCC I found that it can happily live without loadcons insn. It uses memory load instead. What about to drop loadcons.N entirely and define: loadcons s18,r to load signed 18bit constant (bit17 is simply duplicated over whole SR_MAX_SIZE). No partial writes anymore. You can load majority of needed small constans and large ones can be loaded from memory table indexed by smaller constant. There would be register for it (like got, plt ...) which doesn't need to be global. It can be loaded in function prolog by substracting small constant from PC (loadaddrdi). Like: c1: d64 0xff4fffffff77878ff c2: d32 0x12341234 f: loadaddrdi -16,t0 .. push frame here .. loadi.64 8,t0,t1 ; load c1 add.64 a0,t1,t2 loadi.32 4,t0,t1 ; load c2 mul.64 t2,t1,t1 In fact when properly scheduled it can be even faster than bunch of loadcons.N (with shorter code). Loading from ICACHE would be better but .... GCC could also alias more equal constants into one giving more compact code. Just another idea ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 14:16:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KIyo-0000GL-01 for ; Fri, 06 Dec 2002 14:57:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 06 Dec 2002 14:57:22 +0100 (CET) Received: (qmail 21892 invoked by uid 0); 6 Dec 2002 13:36:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 6 Dec 2002 13:36:04 -0000 Received: by moria.seul.org (Postfix) id EAC3033CF1; Fri, 6 Dec 2002 08:36:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7CFC533CF4; Fri, 6 Dec 2002 08:36:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D96EE33CF1 for ; Fri, 6 Dec 2002 08:36:01 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id C56C54F834 for ; Fri, 6 Dec 2002 07:34:40 -0600 (CST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KIdy-00067M-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:35:51 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KIKm-0000HP-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:16:00 +0100 Date: Fri, 6 Dec 2002 14:16:00 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC 3.1 for F-CPU port In-Reply-To: <3DF07855.2090806@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > *beep* false : > > it means that you have to put one NOP or another instruction > before you can use the result. > > your idea would hold for the "oldfashioned" loadcons > but IIRC it was "changed" .... alors maintenant, "faut assumer" :-P I'm lost - how is supposed the "newfashioned loadcons" to work ? Any importand difference I did miss ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 6 14:43:24 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kf3Z-0006cC-00 for ; Sat, 07 Dec 2002 14:31:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 14:31:45 +0100 (CET) Received: (qmail 29405 invoked by uid 0); 6 Dec 2002 13:45:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 6 Dec 2002 13:45:57 -0000 Received: by moria.seul.org (Postfix) id DFE2D33CEB; Fri, 6 Dec 2002 08:45:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52CB633CF5; Fri, 6 Dec 2002 08:45:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 0130133CEB for ; Fri, 6 Dec 2002 08:45:56 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 188EA4F86C for ; Fri, 6 Dec 2002 07:44:35 -0600 (CST) Received: from a13-137.dialup.iol.cz ([194.228.137.13] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KInh-00069Q-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:45:53 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18KIlI-0000Kd-00 for f-cpu@seul.org; Fri, 06 Dec 2002 14:43:24 +0100 Date: Fri, 6 Dec 2002 14:43:24 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Manual problems and strchr optimized routine In-Reply-To: <000201c29d28$126ed020$0100000a@homeworld> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > r1 = r2 andn r3, I am not sure it's needed. > > > > No I only wanted to see that andn is "r2 and not r3" because > > on i386 it is "not r2 and r3" for example. > > I don't remember that i386 has "andn" instruction !? i386=family in my sense, I was talking about MMX andn. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Fri Dec 6 19:48:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kf3c-0006cC-00 for ; Sat, 07 Dec 2002 14:31:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 14:31:48 +0100 (CET) Received: (qmail 28207 invoked by uid 0); 6 Dec 2002 14:48:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 6 Dec 2002 14:48:09 -0000 Received: by moria.seul.org (Postfix) id 4524533CFE; Fri, 6 Dec 2002 09:48:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2BF6833D01; Fri, 6 Dec 2002 09:48:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 9785433CFE for ; Fri, 6 Dec 2002 09:48:06 -0500 (EST) Received: from club-internet.fr (flashmail-4v.cs.clubint.net [172.16.0.154]) by relay-1v.club-internet.fr (Postfix) with SMTP id 9BAAF17AB for ; Fri, 6 Dec 2002 15:47:44 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Fri, 6 Dec 2002 15:48:05 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: devik > >> >> at least, using these numbers is not ambiguous at all. >> > >> >Probably because .8 is valid ONLY if SR=5FSIZE=5F0 =3D=3D 1 ... >> >> and what ? > >ehm .. if you use .8 =3D> SIZE=5FBITS(00) and run with SR=5FSIZE=5F0=3D16= .... >it will do something unexpected (unless assembler emit that it >expects SR=5FSIZE=5F0 is 8) :) well here it deals with the SR=5FSIZE map. i was refering to the explicit size postfix in the assembler. The initial question was : what syntax to use, not what it was mapping to (what size). It seems that the assembler will have to manage a =22local SR=5FSIZE=22 map. So if one writes .8, then the assembler will emit the flag that corresponds to the SR containing 8. I have had a small presentation of AASM (written by cedric and (mostly) by his friend), and i think it can deal with that. Unfortunately, they are reluctant to releasing a beta version before 2 months. but i have seen it work = so i'm confident. >> There is also a little convention : SR=5FSIZE=5F3 contains >> the largest size. This way, algorithms that need the largest >> size (for maximal performance) do not need to fiddle with >> SRs. But this can be changed or enhanced. > >Let me speculate a bit. You want forward compatible CPU. So >if one compiles program for 64 bit FC0 he assumes SR=5FSIZE=5F3=3D64 >(or 4 or 8 - I'm not sure with semantics). >If you now have 128bit FC0 (will it be still FC0?) then you >could still run that program - OS loader will load SR=5FSIZE >map from ELF PHDR and apply it for given task. But here >SR=5FSIZE=5F3=3D64 not 128 so that the convention doesn't hold. well, the =22default mapping=22 is the =22direct=22 one, which is currently used (hardwired in the first generation of FC0). The i think it is the task of the program itself to modify its own SR=5FSIZE regs. But there still is the problem of the libraries : they must also conform to a certain standard concerning the SR=5FSIZE. That's why i proposed the SR=5FSIZE=5F3 to be set to the maximum size, easing string and other computations (so they don't have to save the SR and restore it) >> > I should not rely on bits 8 and higher, these can have >> > any value, correct ? >> now, the mask clears the MSB so you can rely on this to be zero. >Hmm .. but then the code will not be compatible with CPUs >which don't implement the masking. ? i don't expect this to exist. Masking seems to be the only solution, as it was recently examined (the last version gave too many problems, more than i naively expected) >Will it be mandatory on all F-CPUs to clear it ? i think so. unless someone comes up with a crazier idea ?... >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Fri Dec 6 19:55:14 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kf3d-0006cC-00 for ; Sat, 07 Dec 2002 14:31:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 14:31:49 +0100 (CET) Received: (qmail 10217 invoked by uid 0); 6 Dec 2002 14:55:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 6 Dec 2002 14:55:17 -0000 Received: by moria.seul.org (Postfix) id 72A3B33CF1; Fri, 6 Dec 2002 09:55:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0EE2233D03; Fri, 6 Dec 2002 09:55:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A6E5333CF1 for ; Fri, 6 Dec 2002 09:55:15 -0500 (EST) Received: from club-internet.fr (flashmail-4v.cs.clubint.net [172.16.0.154]) by relay-3v.club-internet.fr (Postfix) with SMTP id 0D63416D1 for ; Fri, 6 Dec 2002 15:54:55 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Manual problems and strchr optimized routine Date: Fri, 6 Dec 2002 15:55:14 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi again, >De: devik > >> > ** logic >> > There might be explained what is meant by andn. These >> > can be found at page 54 but is missing in OPs reference page. >> >> I don't understand what you mean by =22missing in OPs reference page=22= (I fint it >> page page 149). But in fact if you ask to see something like this : >> r1 =3D r2 andn r3, I am not sure it's needed. > >No I only wanted to see that andn is =22r2 and not r3=22 because >on i386 it is =22not r2 and r3=22 for example. huh i'll have to check that with the source. >> > ** mux >> > The description doesn't make sense as English sentence to me. >> > Also from ROP2-YG-2001201.tgz sources it seems that mux is >> > done bitwise, so that what is a size flag here for ? >> >> I understand mux as a SIMD conditionnal move, but it's perhaps an error= of >> interpretation (For the sense problem, I think I forgot to copy/past a = part >> of the original text). > >ahh probably. For me MUX makes more sense in bitwise meaning this is how it is implemented. look at http://f-cpu.seul.org/whygee/parinux/rop2.gif and at the source. > because it is superset of SIMD conditional > move but more generic and SIMPLER to implement .. yup. But conditional moves can have specific conditions (zero, LSB etc) >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Dec 6 18:44:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kf42-0006cC-01 for ; Sat, 07 Dec 2002 14:32:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 14:32:14 +0100 (CET) Received: (qmail 3888 invoked by uid 0); 6 Dec 2002 19:48:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 6 Dec 2002 19:48:16 -0000 Received: by moria.seul.org (Postfix) id B398B33D6D; Fri, 6 Dec 2002 14:48:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5A8D333D6C; Fri, 6 Dec 2002 14:48:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by moria.seul.org (Postfix) with ESMTP id C93C233D61 for ; Fri, 6 Dec 2002 14:48:14 -0500 (EST) Received: from thor (nas-cbv-8-62-147-159-207.dial.proxad.net [62.147.159.207]) by postfix4-2.free.fr (Postfix) with ESMTP id 2E318C113 for ; Fri, 6 Dec 2002 20:48:13 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port Date: Fri, 6 Dec 2002 17:44:47 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212061744.47614.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > *beep* false : > > it means that you have to put one NOP or another instruction > > before you can use the result. > > your idea would hold for the "oldfashioned" loadcons > > but IIRC it was "changed" .... alors maintenant, "faut assumer" :-P > I'm lost - how is supposed the "newfashioned loadcons" to work ? > Any importand difference I did miss ? > devik The story of loadcons is very long. This year (in june), Michael RIEPE propose to use a new form loadcons/loadconsp : loadcons $imm17, reg // similar to the original `loadconsx' => reg := sign_extend(imm17) loadconsp $imm16, reg // `p' means `partial' => reg := shift_left(reg, 16) | imm16 But Yann was totally against it, and an other instruction appear in the discussion : cshiftl r3, r2, r1 // r1 = r2 << (64 * r3) cshiftr r3, r2, r1 // r1 = r2 >> (64 * r3) With this instruction, loadcons[x].[4-15] wasn't needed anymore. And the one that must be defined in the manual are loadcons[x].[0-3]. Finally the loadconsx wasn't droped by this discussion, but when I reintroduce it loadcons in the 0.2.7 manual, I forgot to add it (an other opcode was needed). So it's a lack in the manual (I find some other error in that part too). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 6 14:13:49 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kf4G-0006cC-00 for ; Sat, 07 Dec 2002 14:32:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 14:32:28 +0100 (CET) Received: (qmail 8943 invoked by uid 0); 6 Dec 2002 23:49:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 6 Dec 2002 23:49:24 -0000 Received: by moria.seul.org (Postfix) id 82BD433D6C; Fri, 6 Dec 2002 18:49:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01D7933D6F; Fri, 6 Dec 2002 18:49:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id D893A33D6C for ; Fri, 6 Dec 2002 18:49:15 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00557; Fri, 6 Dec 2002 14:13:49 +0100 Message-ID: <20021206141349.12458@thrai.stud.uni-hannover.de> Date: Fri, 6 Dec 2002 14:13:49 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC 3.1 for F-CPU port References: <20021204180139.57876@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Dec 06, 2002 at 10:37:51AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Dec 06, 2002 at 10:37:51AM +0100, devik wrote: > > > But if you will use .8, .128... then assembler should > > > generate .note in ELF to describe wanted content of > > > SR_SIZE_[0-3] and linker should check whether only > > > 4 values all used in all linked files. > > > Maybe it is not bad idea at all ! > > > > Minor objection: according to the ELF standard, a .note section MUST > > NOT change the semantics of a program. > > Hehe it is evident that you are messing with ELF just now :) Nope. Good memory :) > It is long time I read the specs :) > So let's create new section for that :) We could also use a processor-specific flag that marks non-default object files, and a special symbol table entry that indicates the settings of SR_SIZE_[0-3] (the default value would be something like 0x03020100). BTW: do we really need 4 special regs? Wouldn't a single one be sufficient? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sat Dec 7 21:42:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18KmAB-0003TA-00 for ; Sat, 07 Dec 2002 22:07:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 07 Dec 2002 22:07:03 +0100 (CET) Received: (qmail 32545 invoked by uid 0); 7 Dec 2002 20:43:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 7 Dec 2002 20:43:56 -0000 Received: by moria.seul.org (Postfix) id 40AFC33D9B; Sat, 7 Dec 2002 15:43:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47F1233D9D; Sat, 7 Dec 2002 15:43:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id A2BE533D9B for ; Sat, 7 Dec 2002 15:43:49 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 6618D4F7F8 for ; Sat, 7 Dec 2002 14:42:26 -0600 (CST) Received: from a89-137.dialup.iol.cz ([194.228.137.89] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18KlnP-0000lr-00 for f-cpu@seul.org; Sat, 07 Dec 2002 21:43:32 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Klmh-0000Sl-00 for f-cpu@seul.org; Sat, 07 Dec 2002 21:42:47 +0100 Date: Sat, 7 Dec 2002 21:42:47 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] 15 MIPS FC0 emulator Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-792503487-1039293767=:1163" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-792503487-1039293767=:1163 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, today I've written part of my own emulator. Why ? Well simulator is better but not complete yet and probably slow. I wanted to have emulator which can emit stats on pipeline stalls, be fast and simple enough to have it complete in a few days. I want it also for gcc performance tests and run Linux on it later. It is basically loop with switch() and each opcode defined by a few lines (operation and pipeline data for scheduler). It is incomplete but when tried with loop of independent 64bit AND it gives 15MIPS on my PII/375. SIMD ADD.W gives 12MIPS and ADD.W with saturation and carry store 7MIPS. It can be still optimized a bit. It uses MMX where possible (it helps especially with .B and .W SIMD ops). SSE would help but there is much less machines with SSE than with MMX (mine for example). Adding next OPs is simple without need to schedule them - just specify type (if not 2r1w) and latency. I'll continue on it (it has only 200 lines just now) but wanted to share the ideas with you :) It uses timestamping of register writes and circular fifo so that there are almost no loops in critical path. As example see attached output (out.txt) of sequence: add r1,r2,r5 and r1,r2,r6 move r3,r7 and r1,r2,r6 xor r1,r6,r6 it detects both RAW and write port stalls. devik PS: There should be specified whether ADD saturation is signed or not ! --8323328-792503487-1039293767=:1163 Content-Type: APPLICATION/octet-stream; name="devik-fcpu-emul-021207.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="devik-fcpu-emul-021207.tar.gz" H4sIAOJa8j0AA+0aa3PaSDJf0a+YkHUixQJLAuMsGO/mYe+lKoEUTi6u+ByX QAOoLCRWIxl7177fft3zkMTDzmbvso8rdVJY9PT09HtmWrx1L+jYD+iDbwiW bVmtVvOBBbC38hdh1959YO3t7jWbtt2yWkBv7zacB8T6lkIpSFnixoQ88Oil f3EP3ZfG/6bw8ujN85+Ou7XZbHZFav2Gps1cP2wT/KxHmhan8otWSfwZJfUd /kUT45JupGmP2MJPRtP6tE0mNDxnC+1Rpb4jHskBUaNASKL5KPKoRCE1jd0k irVHgloxqE/Vw6gCzCajEalFEpWNID/Jgd7FmEyp69GYqAVQRo+OWb7AtA4q ySUOSe2KjIoj5IZRj9RC8mTn8+mPj852yK9s58ednUln3rl9AsopWu3Pdubv AOG/b7vG/flv7+3atsz/3V0oAJj/9p5d5v8fAY/8cBSkkDX7LPH8qD490JZQ gT9cxrmM0TjhOEgiP6Qk8C9ocK1fGYSQ8/Nh6geJH57TqzkdJTqgTdvIaNMw p95IaxlaRvx+8PzlIbE1becpkahWc+gnJKYTnyU0Zh0ymrrhhBI3jt1rRsaQ 7YEbTyDbI6B+uqMl13MKc2FhPwpx4jkjv2qVNGT+JIS0DqJwIj7SVrOjVdbQ jKMz+rThnDpngPHDhDD1JRtm0yhOSGq3TptnOTeBZQqbUYPwMUmfnT4r0HIc E7hbLnDSgTKMf/HbaQtZ5Osl7my+ggujRYdUKmA0d5SkbkCwcHNCNAgacxH7 UC7nKFRMwZ2XboLWGfnxKAXzkaPXR/0OYf4vlMwgP8iQkklMocTGJAF7a+Do qT+ZAlPihyyJ0xGfHwBFOLruEHARn+cGLMLJ82iBHhkTByVQ7v34bnB+/Alc WsD0B++PiYOyT6MFbC7hNVmgnIwsKJm6l1SpQF0o8aDFjPgMNEbmQhUwQEE9 N0GJE24CnLps+sU8PhVSgP3QoYA4B/ORLrE6KIQfevQKeY/SOKbo8SBKlAiz CMRJIsEbtolxmqQxX+Uy8j0Ibx+CPaTn5+B/f5ycI52eCYCzk8jQfhWh5Jue Px7DwgJPatyNWkWkm84H97vSZgYMaCjfKKCgBh9EyRguXvGBi1Jkmw9iuI6J 7hc4kBmdMZroQLgtiU2Ly4DMacAopgnweqym1GwYqGycJgkkwlimg3EfUbda JTevDzHNFZDpmwcqcUP0Dh1d8GwGa8TjAOZwzUAJXTCQ5oPd17qy5TnS4CLj LN3vWh1/H1LX3942ZJb4ZzAve9xXlv6BWKSd42sSj0qoUEDhb7nPgyi6gDIT RzMy8S9pKESOwoUbe1zecUypCECMP50ZHYhLiIuQ4RJBQEbX4DS2FIuFSAGK aHTOQz4PlUVs5vVK5FgeN7IUQbrwbAHXx6CSDp8HpNWARwe0sw34sDoENHjf f9VvY1LOIghWfkjyR5l1Hy5iQwqM9BVeRiC9REqFFGqplxPjKo/BAY2xYSgJ ajWeObEl5yCxJp0C0uU1Ajwg4gae0Uk83ECTOVDpefz6BiyhqxDksYVry1JR 4zk8PyMHXSWA4FSR+O0Mz8ViEFleGoDL0rggYKUidfZrSkBA3vKgdYfoDINP P3LBh22sRSM3fAKyBu5Iups8JO/iaOgOg2tV2ZIogoBZ1HGJ23xb6794/V7v GRDKcGA9OOihgoUtEoed1fFGYfz40/nL3nvSLGLW6dHXvIJDZQqiiT68Tigz wGBW135h2l3nhel0my/MRvfZi3q9LrnW7GKFHhz+ZBPkqrxcHHHEguQA4szY RNDICWxnnaL/8vnxoa2/NsCWUG367172Xx2eP3r0mieaOm9E8zCdDWH3wBM7 nORFgc2OI1U+Dkf5Kp/F/FmKDmTyLpAnn+QCpXw1DflGLudBIrIwTzxgkiWa jAsITtv0aOBemwv+p7ifz3gVMVMTikGXrFhnjHUYds5KIa+BKrcujzBQ002D BHc1Z2B/lOkjrjTCv05TRDgQ19aAvD5+ThiFeE8gq4GJMLYnLLdKXHD18du3 J/pL84NBXDYj+st2tXtdJTqeODAKzupwPDLaVSvHOQJnVgt0DYEjH4wlxoOv 49zYwNnZzNlBzhC+dzD/nLFfZ7VJcLMoRjZ7ddHGH7HoEuUdgjTvF+RbisHj b9B/53QICIKRBjHn4XX7Gs9EE4pHS5dFIRREirukD2dpXmpl3j/vvTLaIuyq c9zztxxzy6qasGEOYeZFZ4m0Z7RFIHHa8B7ik/4g53sF287dpJxSkW6mBCX/ AduQ1EiHy4ABJfIHMh/N5vTnIYnNmB8EGEkZnGTx1sHqMA/yfCH2SzwMw3R/ Ng/oDI+QIZ2I47Y4smKyD68JSFpfsk+vqIdcbWtrNgMZ8fNfYa6cehajoEG7 Ck/VTcbhXO9j+vU8+4PeFwTNPfbbufZ4fHyB69cyffvhRIra0KtwzPuZMxD8 iGBoq+9i2Ob8iVShyb9V8byAhbxSEWGztjASAAnsAjf8PLa/DztgB58+w/bB j2ENVdw5pRRUBNzz4w9ZUqXYesLDE5vBrgUb2GiahhewacDV9+j1ydvDNlwQ UjiCqvugC9udCK+lZHuFyYaL5duYw8WUzTIdzxCOY8jDU4VvyVaen543LKSH kJqfw7ILPT/V2M8MZIEKjuBKfp1piAespcKC5+ory17+xy0DyTJz2QW/B/Bc oSpNcmZLLrTzkPC8lA0LThUEDf61qb4WvChgNcCsLGZxmqCWvjXhs5l5GI+H d1ni+8wS0id0RX5hViUvN+wK18KRQw1lES1dZBddtPgvXbRk1WaWGEUrNzAZ VOER35cMmZmtsT7dypLMkV8KybPCh8XBgnxn7xbSCk3fqOaq/S9sv7jT9quG doqG9v6vDO2R7xr2NzJ086+ipau0VITN36DxahA02mTpJASZuXSuguvq0pmq c5flnGJ0eDShoyTvdAB14aItILsz4FUkusSLg1480zWcU/vscWFxjjBuMiOs U39eo37874J2AmUcHDSy4sP1yGKbrFd0EIyXcJZgb2E16vPZ38ON6DFSG3eE TmXVzPz6tAT3JKy8Q7WJurprkg42bXJXosLmfIONh/izbeCG3eKawCZdOyCO 3Kpx/tJW/Ta6FJfI/IjR/+fh2laLnZcd2XmZu3HiuwHvMjG+yUXJFDf2KPR8 3LiZJm31cOVSdW/ocR1z2e68Hx7igmN+TeQXCbHkBkp5P8ytiQtkWtCrEZ3j VMSO5zGE5VhniUfj2Kx+CKegVyAu0PhGzrraOsE9FO/TXFB65Se6LbuC/N4O VHQMaQAmgdDx4BxtkoAmT5hKj8Hzj2CjIPCZOtzAvF7//WFbNHnhsDSPeA+X chaADKPFNu9nVMTFHGzGUR3Zj+rEHvyHK3oX7+hoctEFBJy4kZ+RA3mnN0jG YpVGcUu7i7iTdtJ1fumX2aU5N63C+wrY4xQ0vBUMn3A8Uo1x/mZCdcThwLRw 4ZaBUsxjelkvnpdQCs4Pr2zST1Ww5c5HsKdohWx5qhvyEJ0kqHmHudC3lnJ3 KjywllrfiykN8T1AiE0x7CyqJhsvYNxPibgV8u4mZnreodeZgR2qYgMYxV4o GxQaopicpup/ypa2oBOnVqXdx7z9v1HBRaZhUUGMjHzkVsg9c+MLLiwsmr91 gts2GaZM1LaNvl/1Ow882B1USdjGEx1fQWQKtkuRGaa0ldW8juRjnckutKba lLLzBFLyVw1Cc38c6Ut9YWUQfJ2jXqPAdQE2EryIsjYYw1DRKxrmqs0Kz9td 2zKIYkEU3PApCn0Xh85XdnQVvy3bA//wzq0sDvlKYi1AFXQGe7HNOveiRRs2 +RQdLt9JFKR8lguoJsRbNccjpzDlrI0Fy7Jbb3jR8k31bsBE9/iiGqt3Alk3 852O/Uvz+JN59MYcNMyBYw5sbMrqWWcT/xj7+07TuNH140/46ODj0Rt4hF0I HgcNfOTYgQOPLeMGuPAeJb6pX9YVqvG9cGzFMWNJUuhQzuPJKUYTag4iw73Q bJiWaZuOuWuYEtnLkS2FxH2NYy343LuX9KQ/kMiWRFpgLPPpvAurYxRrItCX Nnf+Dme3sLkjhVO4KjbwVwTWrnzVY0uKxuoBwbLgv4UPKhhEjHSKSQJDi6kf UP3pXATBcv/3qT6H6MgDczOH2ywbLQzLP/tF/u8E1T//lmt88fdf+JsP/vuP xl7T4r//2IXh8vcffwAUChivUpDR/I3qBnyP6PmX7eIbK4GFvF+icNYogGCJ orFG0Vslaa4v01tZZ3fDOr1lLq31hVDRIsmeoa3SvP1wgrZ4toaHWogD32tr U6CgwoizZr7jDy8Qb/9dy0QJJZRQQgkllFBCCSWUUEIJJZRQQgkllFBCCSWU UEIJJZRQQgkllFBCCSWUUEIJfzH4D0R45GAAUAAA --8323328-792503487-1039293767=:1163 Content-Type: TEXT/plain; name="out.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="out.txt" Y2MgLW1tbXggLU8zICAgLWMgLW8gbWFpbi5vIG1haW4uYw0KY2MgICBtYWlu Lm8gICAtbyBtYWluDQp0aW1lIC4vbWFpbg0KTm93OiAgICAwDQpyMCAgWyAg IDBdOiAweDAwMDAwMDAwMDAwMDAwMDANCnIxICBbICAgMF06IDB4RkYxMDAw MDVGRkZGRkZGRg0KcjIgIFsgICAwXTogMHgwMzAxMDAwNTAwMDAwMDAxDQpy MyAgWyAgIDBdOiAweEZGRkZGRjAwRjAwMEZGRjANCnI0ICBbICAgMF06IDB4 MDAwMDAwMDAwMDAwMDAwMA0KcjUgIFsgICAwXTogMHgwMDAwMDAwMDAwMDAw MDAwDQpyNiAgWyAgIDBdOiAweDAwMDAwMDAwMDAwMDAwMDANCnI3ICBbICAg MF06IDB4MDAwMDAwMDAwMDAwMDAwMA0KRklGTyB3cG9ydHMgYXNzaWdubWVu dHM6DQogICAgICAgICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgIHwNCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANCg0K Tm93OiAgICAxDQpyMCAgWyAgIDBdOiAweDAwMDAwMDAwMDAwMDAwMDANCnIx ICBbICAgMF06IDB4RkYxMDAwMDVGRkZGRkZGRg0KcjIgIFsgICAwXTogMHgw MzAxMDAwNTAwMDAwMDAxDQpyMyAgWyAgIDBdOiAweEZGRkZGRjAwRjAwMEZG RjANCnI0ICBbICAgMF06IDB4MDAwMDAwMDAwMDAwMDAwMA0KcjUgIFsgICA0 XTogMHgwMjExMDAwQjAwMDAwMDAwDQpyNiAgWyAgIDBdOiAweDAwMDAwMDAw MDAwMDAwMDANCnI3ICBbICAgMF06IDB4MDAwMDAwMDAwMDAwMDAwMA0KRklG TyB3cG9ydHMgYXNzaWdubWVudHM6DQogICAgICAgICB8ICAgICAgICAgfCAg ICAgICAgIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgIHwNCjAwMTAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDANCg0KTm93OiAgICAyDQpyMCAgWyAgIDBdOiAweDAw MDAwMDAwMDAwMDAwMDANCnIxICBbICAgMF06IDB4RkYxMDAwMDVGRkZGRkZG Rg0KcjIgIFsgICAwXTogMHgwMzAxMDAwNTAwMDAwMDAxDQpyMyAgWyAgIDBd OiAweEZGRkZGRjAwRjAwMEZGRjANCnI0ICBbICAgMF06IDB4MDAwMDAwMDAw MDAwMDAwMA0KcjUgIFsgICA0XTogMHgwMjExMDAwQjAwMDAwMDAwDQpyNiAg WyAgIDRdOiAweDAzMDAwMDA1MDAwMDAwMDENCnI3ICBbICAgMF06IDB4MDAw MDAwMDAwMDAwMDAwMA0KRklGTyB3cG9ydHMgYXNzaWdubWVudHM6DQogICAg ICAgICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgIHwNCjAyMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANCg0KV3JpdGUgcG9y dCBzdGFsbCAxIGN5Y2xlcyAhDQpOb3c6ICAgIDQNCnIwICBbICAgMF06IDB4 MDAwMDAwMDAwMDAwMDAwMA0KcjEgIFsgICAwXTogMHhGRjEwMDAwNUZGRkZG RkZGDQpyMiAgWyAgIDBdOiAweDAzMDEwMDA1MDAwMDAwMDENCnIzICBbICAg MF06IDB4RkZGRkZGMDBGMDAwRkZGMA0KcjQgIFsgICAwXTogMHgwMDAwMDAw MDAwMDAwMDAwDQpyNSAgWyAgIDRdOiAweDAyMTEwMDBCMDAwMDAwMDANCnI2 ICBbICAgNF06IDB4MDMwMDAwMDUwMDAwMDAwMQ0KcjcgIFsgICA1XTogMHhG RkZGRkYwMEYwMDBGRkYwDQpGSUZPIHdwb3J0cyBhc3NpZ25tZW50czoNCiAg ICAgICAgIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAg ICB8ICAgICAgICAgfA0KMTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0KDQpOb3c6ICAg IDUNCnIwICBbICAgMF06IDB4MDAwMDAwMDAwMDAwMDAwMA0KcjEgIFsgICAw XTogMHhGRjEwMDAwNUZGRkZGRkZGDQpyMiAgWyAgIDBdOiAweDAzMDEwMDA1 MDAwMDAwMDENCnIzICBbICAgMF06IDB4RkZGRkZGMDBGMDAwRkZGMA0KcjQg IFsgICAwXTogMHgwMDAwMDAwMDAwMDAwMDAwDQpyNSAgWyAgIDRdOiAweDAy MTEwMDBCMDAwMDAwMDANCnI2ICBbICAgN106IDB4MDMwMDAwMDUwMDAwMDAw MQ0KcjcgIFsgICA1XTogMHhGRkZGRkYwMEYwMDBGRkYwDQpGSUZPIHdwb3J0 cyBhc3NpZ25tZW50czoNCiAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgfA0KMDEwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMA0KDQpSQVcvV0FXIHN0YWxsIDEgY3ljbGVzICENCk5vdzogICAg Nw0KcjAgIFsgICAwXTogMHgwMDAwMDAwMDAwMDAwMDAwDQpyMSAgWyAgIDBd OiAweEZGMTAwMDA1RkZGRkZGRkYNCnIyICBbICAgMF06IDB4MDMwMTAwMDUw MDAwMDAwMQ0KcjMgIFsgICAwXTogMHhGRkZGRkYwMEYwMDBGRkYwDQpyNCAg WyAgIDBdOiAweDAwMDAwMDAwMDAwMDAwMDANCnI1ICBbICAgNF06IDB4MDIx MTAwMEIwMDAwMDAwMA0KcjYgIFsgICA5XTogMHhGQzEwMDAwMEZGRkZGRkZF DQpyNyAgWyAgIDVdOiAweEZGRkZGRjAwRjAwMEZGRjANCkZJRk8gd3BvcnRz IGFzc2lnbm1lbnRzOg0KICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICB8DQowMTAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwDQoNCg== --8323328-792503487-1039293767=:1163-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Dec 7 23:19:26 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Koiy-0005st-01 for ; Sun, 08 Dec 2002 00:51:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 00:51:08 +0100 (CET) Received: (qmail 10457 invoked by uid 0); 7 Dec 2002 22:05:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 7 Dec 2002 22:05:43 -0000 Received: by moria.seul.org (Postfix) id A78FB33C8A; Sat, 7 Dec 2002 17:05:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1448733D98; Sat, 7 Dec 2002 17:05:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 3A06633C8A for ; Sat, 7 Dec 2002 17:05:37 -0500 (EST) Received: from f-cpu.org (lcbv5-1-45.n.club-internet.fr [213.44.18.45]) by relay-5v.club-internet.fr (Postfix) with ESMTP id D726517CF for ; Sat, 7 Dec 2002 23:05:42 +0100 (CET) Message-ID: <3DF273EE.8040204@f-cpu.org> Date: Sat, 07 Dec 2002 23:19:26 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >Hi, > >today I've written part of my own emulator. Why ? Well simulator >is better but not complete yet and probably slow. > well, "probably" must be measured before undertaking this ... My goal and plan is to make it scalable and work well, before making it fast. otherwise, it ends up with kludges and workarounds when it could be simply solved by simply changing the original design. >I wanted to have emulator which can emit stats on pipeline stalls, >be fast and simple enough to have it complete in a few days. > if that was possible, you would have it already ;-) >I want it also for gcc performance tests and run Linux on it later. > > as everybody does ... >It is basically loop with switch() and each opcode defined by a few >lines (operation and pipeline data for scheduler). > did you do a copy and paste from the snapshot's source code ? it contains a lot of "standard definitions" .... >It is incomplete but when tried with loop of independent >64bit AND it gives 15MIPS on my PII/375. > wow, i hope it's fast enough :-) >SIMD ADD.W gives 12MIPS and ADD.W with saturation and carry >store 7MIPS. It can be still optimized a bit. > before making it fast, what about making it acurate ? what about the problem with signed saturations ? >It uses MMX where possible (it helps especially with .B and .W >SIMD ops). SSE would help but there is much less machines >with SSE than with MMX (mine for example). > I hereby grant you with the prize of "Least Portables Code" of the F-CPU Project, congratulations ;-) by "portable", it means that people with a Mac, SPARC or other machines can still compile and execute it. I sometimes use Pentium computers (of the first generation) and i know that x86 is not the only architecture on Earth. Well, that's my usual rant. But you said you contribute to the Linux kernel so such a hack does not surprise me :-) there might even be a few things to learn. And if you don't hit the walls a few times, you won't understand why i rant ;-) For example, now, it would be funny to have a 256 bit version, or even, an emulator where you can indicate the register size as a command line parameter ....... >Adding next OPs is simple without need to schedule them - just >specify type (if not 2r1w) and latency. > > cool :-) >I'll continue on it (it has only 200 lines just now) but wanted >to share the ideas with you :) > thanks ! >It uses timestamping of register writes and circular fifo so >that there are almost no loops in critical path. > >it detects both RAW and write port stalls. > > it looks like a good idea. I have to read it more carefully but it seems to be efficient. >devik > >PS: There should be specified whether ADD saturation is signed or not ! > > As far as i remember, it is unsigned. a signed version is however interesting and useful, but designing it might be a problem. Look at the code written by Michael in EU_ASU : this is a very specific implementation of the add operation and Michael did an incredible work at fitting as many ops as possible. now, concerning the ROP2 operations, you can look at the simulator code : it has a completely tested version of the ROP2 code, with MUX and combine included. Yes i know it's not as fast (and it can be optimised in many ways) but i'm sure it can run on the spare Pentium 100MHz in my house :-) have fun, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From usman1926@mailsurf.com Sun Dec 8 01:33:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kpad-0006YK-01 for ; Sun, 08 Dec 2002 01:46:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 01:46:35 +0100 (CET) Received: (qmail 4428 invoked by uid 0); 7 Dec 2002 23:37:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 7 Dec 2002 23:37:30 -0000 Received: by moria.seul.org (Postfix) id 11A7C33D9B; Sat, 7 Dec 2002 18:37:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8357433D9E; Sat, 7 Dec 2002 18:37:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 3903533D9B for ; Sat, 7 Dec 2002 18:37:27 -0500 (EST) Received: from coolre41978.com ([208.60.163.114]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id gB7NbFl08258 for ; Sat, 7 Dec 2002 18:37:18 -0500 Message-Id: <200212072337.gB7NbFl08258@belegost.mit.edu> From: "Barrister Usman Rabiu (LLB)." To: f-cpu@seul.org Date: Sun, 8 Dec 2002 00:33:33 +0000 Subject: [f-cpu] Urgent Request X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N URGENT REQUEST I am a Solicitor resident and practicing in Lagos=2C Nigeria and I am using this correspondence to urgently seek and request your assistance and cooperation in a sensitive but highly beneficial financial arrangement=2E An important client of mine whose details and person I cannot release at this point has implored me to contact a reliable and trustworthy partner overseas to urgently receive and handle funds total FIFTEEN MILLION US DOLLARS=28US$15=2EM=29in CASH presently lodged in a security=2Ffinance outfit in overseas=2E Due to my client inability to travel out of the country presently and the fact that we continue to accumulate huge debts daily as long as this consignment remains in the security=2Ffinance company we need an associate and partner to proceed as soon as possible to receive this funds for investment purpose as shall be instructed by my client=2E We have agreed in principle to give twenty-five percent =2825%=29 of the total sum to whom ever shall handle this funds for us while the remaining sixty-five percent =2865%=29shall be for my client and ten-percent =2810%=29 for me as the attorney=2E As soon as you are ready to proceed to receive this cash on our behalf we shall furnish you with the details and information you will need to accomplish this task=2E Please be rest assured that this arrangement is absolutely risk free And cannot implicate you in any way=2E However I implore you to handle this matter with urgency and utmost confidence even if you do not intend to execute the project for us=2E Whatever the case=2C please acknowledge receipt of this mail via the my Email address=2E If your response is positive we shall proceed immediately without any delay=2E Thank you in anticipation of your cooperation and hoping to hear from you soonest=2E Yours sincerely=2C Barrister Usman Rabiu =28LLB=29=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Dec 8 01:15:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Kpag-0006YK-00 for ; Sun, 08 Dec 2002 01:46:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 01:46:38 +0100 (CET) Received: (qmail 29683 invoked by uid 0); 8 Dec 2002 00:15:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 8 Dec 2002 00:15:41 -0000 Received: by moria.seul.org (Postfix) id 9C74733D9B; Sat, 7 Dec 2002 19:15:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2D99B33D9F; Sat, 7 Dec 2002 19:15:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a055.home.uni-hannover.de [130.75.232.55]) by moria.seul.org (Postfix) with ESMTP id 6321633D9B for ; Sat, 7 Dec 2002 19:15:38 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02578; Sun, 8 Dec 2002 01:15:36 +0100 Message-ID: <20021208011536.06019@thrai.stud.uni-hannover.de> Date: Sun, 8 Dec 2002 01:15:36 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator References: <3DF273EE.8040204@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3DF273EE.8040204@f-cpu.org>; from Yann Guidon on Sat, Dec 07, 2002 at 11:19:26PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Dec 07, 2002 at 11:19:26PM +0100, Yann Guidon wrote: > before making it fast, what about making it acurate ? > what about the problem with signed saturations ? Before anything can be made accurate, we got to fix the manual. I looked at 0.2.7 today, and it seems to move away from reality more and more... In particular, the description of the double shift operations is still wrong. Instruction names have changed without notice (when did we decide to rename `shiftli' to `shiftil', and who introduced `cor' and `cand'?), and there are instructions that we never agreed on (e.g. cload/cstore). To cut a long story short: it's all a big mess. I suggest that you (all of you) don't add any new instructions unless you prove that you can implement them - in VHDL, not in C++! You guys add more and more stuff to the manual, but it's only science fiction :( We also badly need to clean things up. I found an ancient bug today - one that has been there before I joined the project. Look at the examples for `byterev': the lower part of the result is the byte-reversed least significant chunk of the operand - and the upper part is *copied*? That's impossible. With the old `partial write' semantics, it should remain unchanged, and with the current semantics, it should be zero. [...] > >PS: There should be specified whether ADD saturation is signed or not ! > > > As far as i remember, it is unsigned. Yep. It was cheaper to implement (there only is an overflow in one direction), and is IMHO also more useful than signed saturation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Dec 8 11:44:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18L4Nd-0000Fz-01 for ; Sun, 08 Dec 2002 17:34:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 17:34:09 +0100 (CET) Received: (qmail 26550 invoked by uid 0); 8 Dec 2002 12:51:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 8 Dec 2002 12:51:40 -0000 Received: by moria.seul.org (Postfix) id 6F79E33DAF; Sun, 8 Dec 2002 07:51:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBE6833DB1; Sun, 8 Dec 2002 07:51:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 40D1933DAF for ; Sun, 8 Dec 2002 07:51:37 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 1DC2A4F82B for ; Sun, 8 Dec 2002 06:50:13 -0600 (CST) Received: from a36-137.dialup.iol.cz ([194.228.137.36] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18L0u1-00022r-00 for f-cpu@seul.org; Sun, 08 Dec 2002 13:51:21 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Kyuu-0000Ap-00 for f-cpu@seul.org; Sun, 08 Dec 2002 11:44:08 +0100 Date: Sun, 8 Dec 2002 11:44:08 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] 15 MIPS FC0 emulator In-Reply-To: <3DF273EE.8040204@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >today I've written part of my own emulator. Why ? Well simulator > >is better but not complete yet and probably slow. > > > well, "probably" must be measured before undertaking this ... > My goal and plan is to make it scalable and work well, before making it > fast. > otherwise, it ends up with kludges and workarounds when it could > be simply solved by simply changing the original design. yes. As somebody already said there is need for VHDL, simulator and emulator. Probably VHDL code can be also used as/for simulator. But when testing GCC with real code I can't spend whole day to wait for result ... My rationale is different - not make it as clean as possible but make it as simple as possible - thus making it less pain when rewriting. > did you do a copy and paste from the snapshot's source code ? > it contains a lot of "standard definitions" .... I tried to do it. Unfortunately f-cpu_opcodes.m4 is exactly what I was expecting. I'd expect something like: OP_DEFINE(`MUX',`m4_eval(....)') ... so that I'd define OP_DEFINE and pass f-cpu_opcodes.m4 to m4. It could directly generate #define OPCODE_MUX ... for me. Now it seems I'd have to create (duplicate) all #define first WITHOUT real values and m4 will only replace them by actual vals. So that just now I created my own .h with opcodes but I expect to integrate it more later. > >SIMD ADD.W gives 12MIPS and ADD.W with saturation and carry > >store 7MIPS. It can be still optimized a bit. > > > before making it fast, what about making it acurate ? > what about the problem with signed saturations ? I did unsigned one and yes it is acurate. I tested with variety of possible inputs and all flag combinations of "add" (it revealed a few early bugs). > >It uses MMX where possible (it helps especially with .B and .W > >SIMD ops). SSE would help but there is much less machines > >with SSE than with MMX (mine for example). > > > I hereby grant you with the prize of "Least Portables Code" of the F-CPU > Project, congratulations ;-) Thanks :) I wanted it everytime when I had to write portable code in linux kernel :) > by "portable", it means that people with a Mac, SPARC or other machines > can still compile and execute it. I sometimes use Pentium computers > (of the first generation) and i know that x86 is not the only architecture > on Earth. Yup :) Probably I did it because I never coded for MMX and wanted to try it :-) hmm when I think about it then add.b of 32bit register could be done as add = A+B; oldovr = 0; ovr = 1; while(oldovr != ovr) { oldovr = ovr; ovr = ((A & B | (A^B) & ~add) >> 7) & 0x01010101; /* partial carries */ add -= ovr << 8; /* fix carries */ } /* loop (unlikely) if carry fix propagated to upper byte */ if (saturate) add |= ((ovr^0x7f7f7f7f)+1)^0x80808080; it is typicaly 5 ops per byte (when perfectly optimized) which is similar to do per byte unrolled loop (but about would win for 64bit cpu). For add.w it'd be better to stick with per word loop. All these ways are unfortunately at least 5 times (sometimes 40 times) slower than MMX or similar SIMD code. But well ... I'll have probably use loops & GMP library. > Well, that's my usual rant. But you said you contribute to the Linux kernel > so such a hack does not surprise me :-) there might even be a few things hey :) Look at my HTB code in 2.4.20 - it is pretty portable. In fact majority of Linux kernel is portable (except "arch/cpu" subdirs). > to learn. And if you don't hit the walls a few times, you won't understand > why i rant ;-) For example, now, it would be funny to have a 256 bit > version, > or even, an emulator where you can indicate the register size as a command > line parameter ....... nice .. but .. 256bit is MAX_REGISTER_BITS or MAX_CHUNK_BITS ? As cedric said it probably don;t make much sense to have cpu with 256bit adder, multiplier, shifter ... It will slow it down (either in clock or latency sense). Also where do you expect "zero attribute" to be computed for 256 or 1024 bit reg ? It will take one whole cycle ... Maybe there is really need for some inter-chunk ops - like to compute zero flag for only LSB MAX_CHUNK_BITS and have op which can for example do (MAX_CHUNK_BITS=64): bit0 -> bit0 bit64 -> bit1 bit128-> bit2 bit192-> bit3 bit1 -> bit4 etc. > As far as i remember, it is unsigned. > a signed version is however interesting and useful, > but designing it might be a problem. ahh ok - it is not stated in the manual but it is clear from example there > version of the ROP2 code, with MUX and combine > included. Yes i know it's not as fast (and it can be regading combine, manual states that is will be problem to design combine for chunks larger than 8 bits. Does it still hold ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 8 15:37:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18L4Nq-0000Fz-01 for ; Sun, 08 Dec 2002 17:34:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 17:34:22 +0100 (CET) Received: (qmail 26232 invoked by uid 0); 8 Dec 2002 14:23:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 8 Dec 2002 14:23:40 -0000 Received: by moria.seul.org (Postfix) id 41D0733DAF; Sun, 8 Dec 2002 09:23:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 089C833DB2; Sun, 8 Dec 2002 09:23:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 6B32433DAF for ; Sun, 8 Dec 2002 09:23:37 -0500 (EST) Received: from f-cpu.org (lcbv4-2-122.n.club-internet.fr [213.44.93.122]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 72E92172A for ; Sun, 8 Dec 2002 15:23:34 +0100 (CET) Message-ID: <3DF35928.2030305@f-cpu.org> Date: Sun, 08 Dec 2002 15:37:28 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>>today I've written part of my own emulator. Why ? Well simulator >>>is better but not complete yet and probably slow. >>> >>> >>> >>well, "probably" must be measured before undertaking this ... >>My goal and plan is to make it scalable and work well, before making it >>fast. >>otherwise, it ends up with kludges and workarounds when it could >>be simply solved by simply changing the original design. >> >> > >yes. As somebody already said there is need for VHDL, simulator >and emulator. Probably VHDL code can be also used as/for simulator. >But when testing GCC with real code I can't spend whole day to >wait for result ... >My rationale is different - not make it as clean as possible but >make it as simple as possible - thus making it less pain when >rewriting. > > just one question : what about making the cycle counter ad the hazard detection "optional" ? this would ease the work for other architectures. As you know, FC0 is only the first implementation of F-CPU and other cores will probably have other execution and decoding rules. >>did you do a copy and paste from the snapshot's source code ? >>it contains a lot of "standard definitions" .... >> >> > >I tried to do it. Unfortunately f-cpu_opcodes.m4 is exactly >what I was expecting. I'd expect something like: >OP_DEFINE(`MUX',`m4_eval(....)') ... > > well, i don't understand very well what you mean here ... >so that I'd define OP_DEFINE and pass f-cpu_opcodes.m4 to m4. >It could directly generate #define OPCODE_MUX ... for me. Now >it seems I'd have to create (duplicate) all #define first >WITHOUT real values and m4 will only replace them by actual vals. >So that just now I created my own .h with opcodes but I expect >to integrate it more later. > did you run the "configuration" process ? It should generate the .h and you simply have to include it ... >>>SIMD ADD.W gives 12MIPS and ADD.W with saturation and carry >>>store 7MIPS. It can be still optimized a bit. >>> >>> >>> >>before making it fast, what about making it acurate ? >>what about the problem with signed saturations ? >> >> > >I did unsigned one and yes it is acurate. I tested with variety >of possible inputs and all flag combinations of "add" (it revealed >a few early bugs). > > :-) >>>It uses MMX where possible (it helps especially with .B and .W >>>SIMD ops). SSE would help but there is much less machines >>>with SSE than with MMX (mine for example). >>> >>> >>> >>I hereby grant you with the prize of "Least Portables Code" of the F-CPU >>Project, congratulations ;-) >> >> > >Thanks :) I wanted it everytime when I had to write portable >code in linux kernel :) > > heh heh heh ;-) but think about it : i may have temporary access to an Alpha server (DS20) and there is no point of being fast if it can't run at all :-) >>by "portable", it means that people with a Mac, SPARC or other machines >>can still compile and execute it. I sometimes use Pentium computers >>(of the first generation) and i know that x86 is not the only architecture >>on Earth. >> >> > >Yup :) Probably I did it because I never coded for MMX and wanted to >try it :-) > don't worry : coding asm for F-CPU is much more interesting :-) >hmm when I think about it then add.b of 32bit register could be done as >add = A+B; oldovr = 0; ovr = 1; >while(oldovr != ovr) { > oldovr = ovr; > ovr = ((A & B | (A^B) & ~add) >> 7) & 0x01010101; /* partial carries */ > add -= ovr << 8; /* fix carries */ >} /* loop (unlikely) if carry fix propagated to upper byte */ >if (saturate) add |= ((ovr^0x7f7f7f7f)+1)^0x80808080; > >it is typicaly 5 ops per byte (when perfectly optimized) which is >similar to do per byte unrolled loop (but about would win for >64bit cpu). For add.w it'd be better to stick with per word loop. >All these ways are unfortunately at least 5 times (sometimes >40 times) slower than MMX or similar SIMD code. >But well ... I'll have probably use loops & GMP library. > > AFAIK, GMP is not well suited. what would be adapted is macros for doing the C operations in "optimised ways" (here you could even do MMX macros, that would be used when corectly #define'd) on the F-CPU data types. So then you can recompile the source and specify a register width, and the right code would be selected (there is no point in looping if only 64-bit data are used, but it becomes necessary for 256-bit and +, and you can even inline and unroll some versions. MAcros i think are necessary : copy, clear, assign constant, and +, -, and, or, not, xor, shift, all in scalar. SIMD operations are localised to only a part of the code, so they are locally optimised for dealing with "chunks". >>Well, that's my usual rant. But you said you contribute to the Linux kernel >>so such a hack does not surprise me :-) there might even be a few things >> >> >hey :) Look at my HTB code in 2.4.20 - it is pretty portable. In fact >majority of Linux kernel is portable (except "arch/cpu" subdirs). > > huh i'm still stuck with 19-pre7 because pre8 has screwed the Wacom table support .... >>to learn. And if you don't hit the walls a few times, you won't understand >>why i rant ;-) For example, now, it would be funny to have a 256 bit >>version, >>or even, an emulator where you can indicate the register size as a command >>line parameter ....... >> >> >nice .. > that's the goal ;-) > but .. 256bit is MAX_REGISTER_BITS or MAX_CHUNK_BITS ? > register size, of course ! Up to now, and AFAIK, the chunk size is still limited to 64 bits. Some implementations could play with it (like, for a cheap 32-bit version) but 64-bit is already a very wide stuff. >As cedric said it probably don;t make much sense to have cpu with >256bit adder, multiplier, shifter ... It will slow it down (either >in clock or latency sense). > yup. But there is still the misunderstanding that register size would correspond to integer size. Look at SSE2, then. >Also where do you expect "zero attribute" to be computed for >256 or 1024 bit reg ? > huh i guess it'sstill at the register write ports. But usually, tests for 0 are critical in loops or conditional code that deals with small scalar numbers. in this last situation, we know that only a small fraction of the 1024 bits have to be tested (the others being 0) > It will take one whole cycle ... > well, it may happen that a full test for zero on 1024 bits would take a few cycles. But this is not completely illogical so i bear with it ... >Maybe there is really need for some inter-chunk ops - like to >compute zero flag for only LSB MAX_CHUNK_BITS and have op >which can for example do (MAX_CHUNK_BITS=64): >bit0 -> bit0 >bit64 -> bit1 >bit128-> bit2 >bit192-> bit3 >bit1 -> bit4 >etc. > > maybe... but moving bits is the job of the SHL unit which is not fully and definitively finished (though MR's code already works) >>As far as i remember, it is unsigned. >>a signed version is however interesting and useful, >>but designing it might be a problem. >> >> >ahh ok - it is not stated in the manual but it is clear >from example there > > As MR explained, it's really a matter of implementing it with realistic HW constraints. >>version of the ROP2 code, with MUX and combine >>included. Yes i know it's not as fast (and it can be >> >> >regading combine, manual states that is will be problem to design >combine for chunks larger than 8 bits. Does it still hold ? > > yup. Look at the drawing of the ROP2 byte. However, other implementations can probably implement larger ORs and ANDs, with a different timing. The current byte limit is a HW limitation with a specific HW design rule, but you can play with larger combines : that would certainly help certain codes. For example, i think that the RC5 codes deal with 32-bit data, and ROP2 can help making 32-bit masks. But the function of the combine operations is also performed (in a slower way) by the ASU with saturation mode : it requires a bit more time and some more instruction but it does it. >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Sun Dec 8 21:46:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18L9bW-0004gE-00 for ; Sun, 08 Dec 2002 23:08:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 08 Dec 2002 23:08:50 +0100 (CET) Received: (qmail 22163 invoked by uid 0); 8 Dec 2002 21:36:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 8 Dec 2002 21:36:37 -0000 Received: by moria.seul.org (Postfix) id 94D2B33DB9; Sun, 8 Dec 2002 16:36:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CEB8C33DBD; Sun, 8 Dec 2002 16:36:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id B3AD733DB9 for ; Sun, 8 Dec 2002 16:36:33 -0500 (EST) Received: from thor (201.190.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.190.201]) by smtp3.9tel.net (Postfix) with ESMTP id C98F65BF28 for ; Sun, 8 Dec 2002 22:36:32 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator Date: Sun, 8 Dec 2002 20:46:19 +0000 User-Agent: KMail/1.4.3 References: <3DF273EE.8040204@f-cpu.org> <20021208011536.06019@thrai.stud.uni-hannover.de> In-Reply-To: <20021208011536.06019@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212081558.52698.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > before making it fast, what about making it acurate ? > > what about the problem with signed saturations ? > Before anything can be made accurate, we got to fix the manual. I looked > at 0.2.7 today, and it seems to move away from reality more and more... > In particular, the description of the double shift operations is still > wrong. Instruction names have changed without notice (when did we decide > to rename `shiftli' to `shiftil', and who introduced `cor' and `cand'?), > and there are instructions that we never agreed on (e.g. cload/cstore). > To cut a long story short: it's all a big mess. Well, for shiftli and shiftil, the problem is that for all the instruction we have first the opcode and then the flags, so when somebody say that we only need one opcode for left/right shift that move from opcode to flags, so the logical point of view is to add them to the flags part. For cor/cand, I asked Yann every day since august to write me a document about is new instruction combine/mux/logic, but he didn't have egouth time to wrote the instruction specification, he only give me some sample of how to use it and that's all. For cload/cstore, I think that because nobody reply on Yann mail : "Re: [f-cpu] Conditionnal load and store, the return" (Date : Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. But in fact 0.2.7 is unstable, I mean that I put every dead discussion in it and wait for reaction because, it's the only way to have a decision. In fact 0.2.7 must not be the manual on which you refer when you write an assembler or a emulator. So the dead discussion I put in are : * New shift/rot * New widen * New LSU flush * New madd/msub // I think that's now they will be removed, because normal add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu] pointer add & sub"). * New cshift * Starting SR_MAP // For it I read all the discussion in the mailing list and in the manual that contain SR_, so a lot of them are only supposed. * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet written (the copy/paste is really unclear, need to be totally rewritten) * New safeload/safestore * Last proposed/aprouved TLB entry // I think it's Michael proposition * New cload/cstore I still wait on you and Yann complete reaction about this manual to have something realistic (You know it's hard to extract decisions from the mailing-list, it will be perhaps a good idea to specify a policy to know when something is approved and must be put in the manual). I have added the color at the top of each page to help people see where change occur in the manual (Normally important changes are marked as "Subject to change" like logic/cor/cand, and updated instructions are marked as "Updated", each of them need to be checked). > We also badly need to clean things up. I found an ancient bug today - > one that has been there before I joined the project. Look at the examples > for `byterev': the lower part of the result is the byte-reversed least > significant chunk of the operand - and the upper part is *copied*? > That's impossible. With the old `partial write' semantics, it should > remain unchanged, and with the current semantics, it should be zero. Well I think that currently a lot of sample need to be checked, but I don't have time to do it. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Dec 9 12:13:13 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LTpg-0001S1-00 for ; Mon, 09 Dec 2002 20:44:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 09 Dec 2002 20:44:48 +0100 (CET) Received: (qmail 8279 invoked by uid 0); 9 Dec 2002 11:14:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 9 Dec 2002 11:14:49 -0000 Received: by moria.seul.org (Postfix) id C26DE33D00; Mon, 9 Dec 2002 06:14:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BB5C33D7C; Mon, 9 Dec 2002 06:14:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 3DBD033D00 for ; Mon, 9 Dec 2002 06:14:47 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id BB8E24F849 for ; Mon, 9 Dec 2002 05:13:14 -0600 (CST) Received: from a120-137.dialup.iol.cz ([194.228.137.120] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18LLrP-0005SX-00 for f-cpu@seul.org; Mon, 09 Dec 2002 12:14:05 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18LLqb-0000Ew-00 for f-cpu@seul.org; Mon, 09 Dec 2002 12:13:13 +0100 Date: Mon, 9 Dec 2002 12:13:13 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] 15 MIPS FC0 emulator In-Reply-To: <3DF35928.2030305@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, > just one question : what about making the cycle counter ad the hazard > detection "optional" ? > this would ease the work for other architectures. As you know, FC0 is > only the first implementation of F-CPU and other cores will probably > have other execution and decoding rules. Yes I plan it (hazard detection is still a bit slow so you can want to turn it off). I plan to make these detections in one inlined fn which can be changed for other one. > >I tried to do it. Unfortunately f-cpu_opcodes.m4 isn't exactly > >what I was expecting. I'd expect something like: > >OP_DEFINE(`MUX',`m4_eval(....)') ... > > > well, i don't understand very well what you mean here ... it means that when you create new opcode you need to add it manualy to three places (currently) - .m4, .h.in and .vhdl.in. But it is possible to have one .h4 and generate .vhdl and .h from scratch .. > did you run the "configuration" process ? It should generate the .h > and you simply have to include it ... didn't run it (shame). I have had only 2 hours to write the emulator so I decided to start from scratch and planned to use .m4 if emulator will prove itself useful. > but think about it : i may have temporary access to an Alpha server (DS20) > and there is no point of being fast if it can't run at all :-) sounds attractive :) Yes I agree with code - I'll use C only with optional MMX/SSE handcoded parts in #ifdef > AFAIK, GMP is not well suited. > what would be adapted is macros for doing the C operations in "optimised > ways" (here you could even do MMX macros, that would be used when > corectly #define'd) on the F-CPU data types. > So then you can recompile the source and specify a register width, > and the right code would be selected (there is no point in looping > if only 64-bit data are used, but it becomes necessary for 256-bit and +, > and you can even inline and unroll some versions. > MAcros i think are necessary : copy, clear, assign constant, > and +, -, and, or, not, xor, shift, all in scalar. > SIMD operations are localised to only a part of the code, > so they are locally optimised for dealing with "chunks". Let me to not agree with you here. For example "scalar add" macro will be probably used only in scalar add - vector add has too many problems with carry and from 16bit chunks it is faster to do loop (or use native SIMD like MMX/SSE - btw SSE is 128bit). I'd suggest to define SIMD ADD with carry for all sizes, SIMD shift, and or xor not. These can be then used by "generic" code to define saturated add and sub (if not defined explicitly), cand/cor, compare, neg, inc, dec, lshift, abs, max, min, scan, popc, mix, expand and mux (I learned some tricks from GMP sources). Then as platform optimization you could redefine any macro to give better code for that op. The most challenging is fast SIMD add with carry indication .. Regarding GMP - you really want to code 64x64->128 bit multiply by hand on 32bit CPUs !? And divides ? Me not .. GMP handles them pretty fast (karatsuba multiplication) and has optimized code for wast majority of CPUs. I planned to use it exclusively for MUL, DIV and REM or large chunks. > register size, of course ! > Up to now, and AFAIK, the chunk size is still limited to 64 bits. > Some implementations could play with it (like, for a cheap 32-bit version) > but 64-bit is already a very wide stuff. I agree. > >As cedric said it probably don;t make much sense to have cpu with > >256bit adder, multiplier, shifter ... It will slow it down (either > >in clock or latency sense). > > > yup. But there is still the misunderstanding that register size would > correspond to > integer size. Look at SSE2, then. It is clear enough that register != integer ... it is essence of SIMD. I like to use registers like collection of bits. > >Also where do you expect "zero attribute" to be computed for > >256 or 1024 bit reg ? > > > huh i guess it'sstill at the register write ports. > But usually, tests for 0 are critical in loops > or conditional code that deals with small scalar numbers. > in this last situation, we know that only a small fraction > of the 1024 bits have to be tested (the others being 0) well but what about bypasses ? Will the zeroattr propagate in paralel with data going thru bypass & xbar toward EU which needs it ? > > It will take one whole cycle ... > > > well, it may happen that a full test for zero on 1024 bits > would take a few cycles. But this is not completely illogical > so i bear with it ... so it will stall pipeline ? > >Maybe there is really need for some inter-chunk ops - like to > >compute zero flag for only LSB MAX_CHUNK_BITS and have op > >which can for example do (MAX_CHUNK_BITS=64): > >bit0 -> bit0 > >bit64 -> bit1 > >bit128-> bit2 > >bit192-> bit3 > >bit1 -> bit4 > >etc. > > > maybe... but moving bits is the job of the SHL unit > which is not fully and definitively finished (though > MR's code already works) Hmm yes - but is not SHL unit expected to work only on chunks (so it doesn't need to cope with more than 64bits) ? And there is no operation to "escape" from chunk except cshift. > As MR explained, it's really a matter of implementing it > with realistic HW constraints. I completely agree. > >regading combine, manual states that is will be problem to design > >combine for chunks larger than 8 bits. Does it still hold ? > > > yup. Look at the drawing of the ROP2 byte. > However, other implementations can probably implement larger ORs and ANDs, Probably pipelined (stage after ROP2) ? Which will cost another xbar EU port - BTW, are these ports to xbar expensive in (current) HW ? and should FC0 emulate them ? > But the function of the combine operations is also performed > (in a slower way) by the ASU with saturation mode : it requires > a bit more time and some more instruction but it does it. like add/subing 0xFE in saturated byte mode ? The bit 0 is the result .. Hmm ! It is wonderfull !!! So cor.nxor is: xor.8 ,,r1 addsi.8 0xfe,r1,r1 inc.8 r1,r1 Because add.8 is 1 cycle op it is then very similar to 8bit limited cand/corr (well cand/cor combines it with ROP2). But ... what is saying your sense for othogonality ? :) BTW: are you know other excelent tricks like one above ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 9 03:05:53 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LTps-0001S1-00 for ; Mon, 09 Dec 2002 20:45:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 09 Dec 2002 20:45:00 +0100 (CET) Received: (qmail 22066 invoked by uid 0); 9 Dec 2002 13:44:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 9 Dec 2002 13:44:11 -0000 Received: by moria.seul.org (Postfix) id BA8BB33D00; Mon, 9 Dec 2002 08:44:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 199A933D7C; Mon, 9 Dec 2002 08:44:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a193.home.uni-hannover.de [130.75.232.193]) by moria.seul.org (Postfix) with ESMTP id 2B2FF33D00 for ; Mon, 9 Dec 2002 08:44:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02933; Mon, 9 Dec 2002 03:05:53 +0100 Message-ID: <20021209030553.49272@thrai.stud.uni-hannover.de> Date: Mon, 9 Dec 2002 03:05:53 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator References: <3DF273EE.8040204@f-cpu.org> <20021208011536.06019@thrai.stud.uni-hannover.de> <200212081558.52698.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212081558.52698.cedric.bail@free.fr>; from cedric on Sun, Dec 08, 2002 at 08:46:19PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Dec 08, 2002 at 08:46:19PM +0000, cedric wrote: > Well, for shiftli and shiftil, the problem is that for all the instruction we > have first the opcode and then the flags, so when somebody say that we only > need one opcode for left/right shift that move from opcode to flags, so the > logical point of view is to add them to the flags part. That wasn't necessary, and I will continue to use the old name. Whether or not shift[lr] share a single opcode doesn't matter (that hasn't been decided anyway - and as long as there is no decision, the manual should stay the way it is). > For cor/cand, I asked Yann every day since august to write me a document about > is new instruction combine/mux/logic, but he didn't have egouth time to wrote > the instruction specification, he only give me some sample of how to use it > and that's all. It's all in the code... but again, why the new names? > For cload/cstore, I think that because nobody reply on Yann mail : > "Re: [f-cpu] Conditionnal load and store, the return" (Date : > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. Wrong. I know that SW people liked it, but it makes the implementation too complex. > But in fact 0.2.7 is unstable, I mean that I put every dead discussion in it > and wait for reaction because, it's the only way to have a decision. In fact > 0.2.7 must not be the manual on which you refer when you write an assembler > or a emulator. May I suggest that you put the `dead ends' into a separate section? Or better, throw them away. A manual shall document what *is*, not what might be. If it doesn't match, the manual is wrong by definition. > So the dead discussion I put in are : > * New shift/rot Almost matches the implementation > * New widen Not implemented yet (but will be). > * New LSU flush Where's that? > * New madd/msub // I think that's now they will be removed, because normal > add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu] pointer add & > sub"). Another undecided point. > * New cshift I guess the jury is still out on that. BTW: `loadcons' also plays a role here. > * Starting SR_MAP // For it I read all the discussion in the mailing list and > in the manual that contain SR_, so a lot of them are only supposed. f-cpu_config.vhdl contains a list. If it's not there, it does not exist. > * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet written > (the copy/paste is really unclear, need to be totally rewritten) Simple. But we used to call them differently: short long new ============================= a .and cand. o .or cor. where is one of: and, or, xor, andn, orn, nand, nor, xnor. All of them take a size suffix, but only .b is currently supported in hardware (because the latency would increase otherwise). The logic operation is performed on whole registers; the size suffix indicates how many bits are combined in the second step. The basic operations (just , without combining) never have size suffixes. Finally, the mux instruction computes r1 = (r1 & ~r3) | (r2 & r3) (bitwise multiplex). It doesn't have any suffixes. I hope that was correct, I didn't look at the code for a while. Yann? BTW: the old `logic' name is too hard to grok and should be dropped. > * New safeload/safestore It's not clear how that can be implemented. > * Last proposed/aprouved TLB entry // I think it's Michael proposition Doesn't matter at the moment. > * New cload/cstore Another unclear point. > I still wait on you and Yann complete reaction about this manual to have > something realistic Unfortunately, I don't have enough time to work, sleep, eat, write VHDL and C, and read every manual update or code snapshot that crosses my way. > (You know it's hard to extract decisions from the > mailing-list, it will be perhaps a good idea to specify a policy to know when > something is approved and must be put in the manual). When it describes something that is already implemented (in particular, the ROP2, ASU, IMU or SHL units), it should be in the manual - and it should be correct. These are the pages you can mark green. Once marked, the pages must not change again, or they will lose their marks. Everything else is subject to change. Projected stuff that hasn't been implemented yet but is on its way (like the INC/CMP instructions) can be marked yellow. The FP stuff also belongs into this category (except fcmp* which is complete nonsense), and things like load/store/move/jump. The rest belongs to the red category. It's mostly pure speculation. Something may move up into the yellow category if there is a design for it - that is, if somebody can start implementing it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Dec 9 15:22:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LTpx-0001S1-01 for ; Mon, 09 Dec 2002 20:45:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 09 Dec 2002 20:45:05 +0100 (CET) Received: (qmail 23322 invoked by uid 0); 9 Dec 2002 14:22:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 9 Dec 2002 14:22:48 -0000 Received: by moria.seul.org (Postfix) id 8C91133D00; Mon, 9 Dec 2002 09:22:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E615D33D7C; Mon, 9 Dec 2002 09:22:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id C774733D00 for ; Mon, 9 Dec 2002 09:22:45 -0500 (EST) Received: from 10.1.1.17 [10.1.1.17] by th00.opsion.fr id 200212091422.1b2d; Mon, 9 Dec 2002 14:22:27 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: [f-cpu] Taking decision on the project From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2002 14:22:27 GMT Message-id: <200212091422.1b2d@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I don't have time as Michael to go deep regularly inside the= manual. But i don't like so much to change the manual depending on what = is implemented ! That is not the goal of a manual. (if cstore/cload are conditionnal load/store, it should beha= ve like cjump but with data instead of code.) More generaly, take a decision on the vhdl list is very hard= . Maybe the vm bit field has been decide that way. But more often, the t= hread just end. We try to implement a system of RFC but that's hard to = find people to do that work.=20 Our main document is the Manual, so Cedric find this way to = speed up decision : if nobody are against, it's adopted. During almos= t 2 year, the manual did not change ! Maybe "unstable" manual could be deliver ? So we can discuss= about it. A wiki should be very nice to discuss each very particular fea= ture. But we know how such business always end... nicO -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 09/12/02 Objet: Re: [f-cpu] 15 MIPS FC0 emulator On Sun, Dec 08, 2002 at 08:46:19PM +0000, cedric wrote: > Well, for shiftli and shiftil, the problem is that for all= the instruction we=20 > have first the opcode and then the flags, so when somebody= say that we only=20 > need one opcode for left/right shift that move from opcode= to flags, so the=20 > logical point of view is to add them to the flags part. That wasn't necessary, and I will continue to use the old na= me. Whether or not shift[lr] share a single opcode doesn't matte= r (that hasn't been decided anyway - and as long as there is no deci= sion, the manual should stay the way it is). > For cor/cand, I asked Yann every day since august to write= me a document about=20 > is new instruction combine/mux/logic, but he didn't have e= gouth time to wrote=20 > the instruction specification, he only give me some sample= of how to use it=20 > and that's all. It's all in the code... but again, why the new names? > For cload/cstore, I think that because nobody reply on Yan= n mail : > "Re: [f-cpu] Conditionnal load and store, the return" (Da= te :=20 > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. Wrong. I know that SW people liked it, but it makes the impl= ementation too complex. > But in fact 0.2.7 is unstable, I mean that I put every dea= d discussion in it=20 > and wait for reaction because, it's the only way to have a= decision. In fact=20 > 0.2.7 must not be the manual on which you refer when you w= rite an assembler=20 > or a emulator. May I suggest that you put the `dead ends' into a separate s= ection? Or better, throw them away. A manual shall document what *is= *, not what might be. If it doesn't match, the manual is wrong by defini= tion. > So the dead discussion I put in are : > * New shift/rot Almost matches the implementation > * New widen Not implemented yet (but will be). > * New LSU flush Where's that? > * New madd/msub // I think that's now they will be remove= d, because normal=20 > add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu]= pointer add &=20 > sub"). Another undecided point. > * New cshift I guess the jury is still out on that. BTW: `loadcons' also plays a role here. > * Starting SR_MAP // For it I read all the discussion in = the mailing list and=20 > in the manual that contain SR_, so a lot of them are only = supposed. f-cpu_config.vhdl contains a list. If it's not there, it doe= s not exist. > * New cor/cand/mux/logic // Exist in Yann ROP2 code, but = are not yet written=20 > (the copy/paste is really unclear, need to be totally rewr= itten) Simple. But we used to call them differently: short long new =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D a .and cand. o .or cor. where is one of: and, or, xor, andn, orn, nand, nor, xn= or. All of them take a size suffix, but only .b is currently supported = in hardware (because the latency would increase otherwise). The logic op= eration is performed on whole registers; the size suffix indicates h= ow many bits are combined in the second step. The basic operations (just = , without combining) never have size suffixes. Finally, the mux instru= ction computes r1 =3D (r1 & ~r3) | (r2 & r3) (bitwise multiplex). It doesn't have any suffixes. I hope that was correct, I didn't look at the code for a whi= le. Yann? BTW: the old `logic' name is too hard to grok and should be = dropped. > * New safeload/safestore It's not clear how that can be implemented. > * Last proposed/aprouved TLB entry // I think it's Michae= l proposition Doesn't matter at the moment. > * New cload/cstore Another unclear point. > I still wait on you and Yann complete reaction about this = manual to have =20 > something realistic Unfortunately, I don't have enough time to work, sleep, eat,= write VHDL and C, and read every manual update or code snapshot that cr= osses my way. > (You know it's hard to extract decisions from the=20 > mailing-list, it will be perhaps a good idea to specify a = policy to know when=20 > something is approved and must be put in the manual). When it describes something that is already implemented (in = particular, the ROP2, ASU, IMU or SHL units), it should be in the manual= - and it should be correct. These are the pages you can mark green. O= nce marked, the pages must not change again, or they will lose their mar= ks. Everything else is subject to change. Projected stuff that h= asn't been implemented yet but is on its way (like the INC/CMP instruct= ions) can be marked yellow. The FP stuff also belongs into this category = (except fcmp* which is complete nonsense), and things like load/store/move= /jump. The rest belongs to the red category. It's mostly pure specu= lation. Something may move up into the yellow category if there is a= design for it - that is, if somebody can start implementing it. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Mon Dec 9 21:00:03 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LTq7-0001S1-00 for ; Mon, 09 Dec 2002 20:45:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 09 Dec 2002 20:45:15 +0100 (CET) Received: (qmail 8784 invoked by uid 0); 9 Dec 2002 16:00:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 9 Dec 2002 16:00:06 -0000 Received: by moria.seul.org (Postfix) id EFA3033DCA; Mon, 9 Dec 2002 11:00:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 50EFB33DC9; Mon, 9 Dec 2002 11:00:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 5938F33D80 for ; Mon, 9 Dec 2002 11:00:04 -0500 (EST) Received: from club-internet.fr (flashmail-3v.cs.clubint.net [172.16.0.153]) by relay-4v.club-internet.fr (Postfix) with SMTP id C81E91824 for ; Mon, 9 Dec 2002 17:00:02 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] 15 MIPS FC0 emulator Date: Mon, 9 Dec 2002 17:00:03 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: Michael Riepe >cedric wrote: > >> Well, for shiftli and shiftil, the problem is that for all the instruct= ion we = >> have first the opcode and then the flags, so when somebody say that we = only = >> need one opcode for left/right shift that move from opcode to flags, so= the = >> logical point of view is to add them to the flags part. > >That wasn't necessary, and I will continue to use the old name. >Whether or not shift=5Blr=5D share a single opcode doesn't matter (that >hasn't been decided anyway - and as long as there is no decision, the >manual should stay the way it is). On top of that, i have the intention to write another version of the shifter. One day. >> For cor/cand, I asked Yann every day since august to write me a documen= t about = >> is new instruction combine/mux/logic, but he didn't have egouth time to= wrote = >> the instruction specification, he only give me some sample of how to us= e it = >> and that's all. >It's all in the code... but again, why the new names? huh good question. but do i really want an answer ?... (PH34R =21) >> For cload/cstore, I think that because nobody reply on Yann mail : >> =22Re: =5Bf-cpu=5D Conditionnal load and store, the return=22 (Date : = >> Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. > >Wrong. I know that SW people liked it, but it makes the implementation >too complex. huh i have to find exactly what it is about. But i think that conditional load and store is not a big problem. The exact semantics and behaviour has to be defined but basicly, cload/cstore use the same mechanism as conditional moves (for the condition part) and the usual load/store (instead that it doesn't trap when the condition is false, but the operation is aborted anyway). See the trick ? =5Bi wish it works, in practice, though ;-)=5D >> But in fact 0.2.7 is unstable, I mean that I put every dead discussion = in it = >> and wait for reaction because, it's the only way to have a decision. In= fact = >> 0.2.7 must not be the manual on which you refer when you write an assem= bler = >> or a emulator. > >May I suggest that you put the =60dead ends' into a separate section? >Or better, throw them away. A manual shall document what *is*, not what >might be. If it doesn't match, the manual is wrong by definition. > >> So the dead discussion I put in are : >> * New shift/rot > >Almost matches the implementation > >> * New widen > >Not implemented yet (but will be). > >> * New LSU flush > >Where's that? > >> * New madd/msub // I think that's now they will be removed, because no= rmal = >> add/sub will do it (look at Antoine/Yann mail =22Re: =5Bf-cpu=5D pointe= r add & = >> sub=22). > >Another undecided point. as you both know, i see no point here. a load to register 0 with postincrement does the same. >> * New cshift > >I guess the jury is still out on that. >BTW: =60loadcons' also plays a role here. i am not sure what it is about, so i won't step into that one ... >> * Starting SR=5FMAP // For it I read all the discussion in the mailing= list and = >> in the manual that contain SR=5F, so a lot of them are only supposed. > >f-cpu=5Fconfig.vhdl contains a list. If it's not there, it does not >exist. or not yet. I think that i have forgotten a lot of them, but it's difficult to figure them outside of their context. >> * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet w= ritten = >> (the copy/paste is really unclear, need to be totally rewritten) > >Simple. But we used to call them differently: > > short long new > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > a .and cand. > o .or cor. > >where is one of: and, or, xor, andn, orn, nand, nor, xnor. All of >them take a size suffix, why can't nobody agree ? i see the combine as a suffix, because it is performed AFTER the logic operation. Otherwise it is potentially misleading. > but only .b is currently supported in hardware >(because the latency would increase otherwise). this will be determined at synthesis time, but it's a first good guess that allows to do ASCII string searches easily. > The logic operation >is performed on whole registers; the size suffix indicates how many bits >are combined in the second step. The basic operations (just , without >combining) never have size suffixes. Finally, the mux instruction compute= s > > r1 =3D (r1 & =7Er3) =7C (r2 & r3) > >(bitwise multiplex). It doesn't have any suffixes. > >I hope that was correct, I didn't look at the code for a while. Yann? right. >BTW: the old =60logic' name is too hard to grok and should be dropped. yup. i guess that even =22nand=22 is explicit enough. >> * New safeload/safestore > >It's not clear how that can be implemented. are we speaking about the atomic things ? >> * Last proposed/aprouved TLB entry // I think it's Michael proposition > >Doesn't matter at the moment. huh ? i probably missed an episode. >> * New cload/cstore > >Another unclear point. > >> I still wait on you and Yann complete reaction about this manual to hav= e = >> something realistic > >Unfortunately, I don't have enough time to work, sleep, eat, write VHDL >and C, and read every manual update or code snapshot that crosses my way. me too. I'll promise to try on day, though... maybe now ? >> (You know it's hard to extract decisions from the = >> mailing-list, it will be perhaps a good idea to specify a policy to kno= w when = >> something is approved and must be put in the manual). > >When it describes something that is already implemented (in particular, >the ROP2, ASU, IMU or SHL units), it should be in the manual - and it >should be correct. These are the pages you can mark green. Once marked, >the pages must not change again, or they will lose their marks. > >Everything else is subject to change. Projected stuff that hasn't been >implemented yet but is on its way (like the INC/CMP instructions) can be >marked yellow. The FP stuff also belongs into this category (except fcmp* >which is complete nonsense), and things like load/store/move/jump. > >The rest belongs to the red category. It's mostly pure speculation. >Something may move up into the yellow category if there is a design >for it - that is, if somebody can start implementing it. yup. > Michael =22Tired=22 Riepe YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Dec 9 20:38:35 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LTqT-0001S1-01 for ; Mon, 09 Dec 2002 20:45:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 09 Dec 2002 20:45:37 +0100 (CET) Received: (qmail 18179 invoked by uid 0); 9 Dec 2002 18:51:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 9 Dec 2002 18:51:30 -0000 Received: by moria.seul.org (Postfix) id 108D833DCD; Mon, 9 Dec 2002 13:51:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5283533DCF; Mon, 9 Dec 2002 13:51:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 9DE0933DCD for ; Mon, 9 Dec 2002 13:51:28 -0500 (EST) Received: from thor (89.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.89]) by smtp3.9tel.net (Postfix) with ESMTP id ACE285BE54 for ; Mon, 9 Dec 2002 19:51:25 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator Date: Mon, 9 Dec 2002 19:38:35 +0000 User-Agent: KMail/1.4.3 References: <200212081558.52698.cedric.bail@free.fr> <20021209030553.49272@thrai.stud.uni-hannover.de> In-Reply-To: <20021209030553.49272@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212091938.35478.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Well, for shiftli and shiftil, the problem is that for all the > > instruction we have first the opcode and then the flags, so when somebody > > say that we only need one opcode for left/right shift that move from > > opcode to flags, so the logical point of view is to add them to the flags > > part. > > That wasn't necessary, and I will continue to use the old name. > Whether or not shift[lr] share a single opcode doesn't matter (that > hasn't been decided anyway - and as long as there is no decision, the > manual should stay the way it is). Ok. > > For cor/cand, I asked Yann every day since august to write me a document > > about is new instruction combine/mux/logic, but he didn't have egouth > > time to wrote the instruction specification, he only give me some sample > > of how to use it and that's all. > > It's all in the code... but again, why the new names? What was the old names ? > > For cload/cstore, I think that because nobody reply on Yann mail : > > "Re: [f-cpu] Conditionnal load and store, the return" (Date : > > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. > Wrong. I know that SW people liked it, but it makes the implementation > too complex. Ok, I will remove it. > > But in fact 0.2.7 is unstable, I mean that I put every dead discussion in > > it and wait for reaction because, it's the only way to have a decision. > > In fact 0.2.7 must not be the manual on which you refer when you write an > > assembler or a emulator. > May I suggest that you put the `dead ends' into a separate section? > Or better, throw them away. A manual shall document what *is*, not what > might be. If it doesn't match, the manual is wrong by definition. It's an other solution, I will perhaps start a document like a "TODO discussion" about all the subject that die and perhaps a link to the last mail about the subject. > > So the dead discussion I put in are : > > * New shift/rot > Almost matches the implementation > > * New widen > Not implemented yet (but will be). > > * New LSU flush > Where's that? A discussion about stream hint that die... > > * New madd/msub // I think that's now they will be removed, because > > normal add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu] pointer > > add & sub"). > Another undecided point. Yes, but discussion die... > > * New cshift > I guess the jury is still out on that. > BTW: `loadcons' also plays a role here. > > * Starting SR_MAP // For it I read all the discussion in the mailing > > list and in the manual that contain SR_, so a lot of them are only > > supposed. > f-cpu_config.vhdl contains a list. If it's not there, it does not > exist. Some old part of the manual contain some SR, and mailing-list too, I will put them in the "TODO discussion" too. > > * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet > > written (the copy/paste is really unclear, need to be totally rewritten) > Simple. But we used to call them differently: > short long new > ============================= > a .and cand. > o .or cor. > where is one of: and, or, xor, andn, orn, nand, nor, xnor. All of > them take a size suffix, but only .b is currently supported in hardware > (because the latency would increase otherwise). The logic operation > is performed on whole registers; the size suffix indicates how many bits > are combined in the second step. The basic operations (just , without > combining) never have size suffixes. Finally, the mux instruction computes > r1 = (r1 & ~r3) | (r2 & r3) > (bitwise multiplex). It doesn't have any suffixes. > I hope that was correct, I didn't look at the code for a while. Yann? Cool, somebody write it ;-) > BTW: the old `logic' name is too hard to grok and should be dropped. Ok. > > * New safeload/safestore > It's not clear how that can be implemented. I don't know if we must put it in a separated document, because it's a needed functionnality for an OS on the F-CPU. > > * Last proposed/aprouved TLB entry // I think it's Michael proposition > Doesn't matter at the moment. Direct to "TODO discussion". > > * New cload/cstore > Another unclear point. > > (You know it's hard to extract decisions from the > > mailing-list, it will be perhaps a good idea to specify a policy to know > > when something is approved and must be put in the manual). > When it describes something that is already implemented (in particular, > the ROP2, ASU, IMU or SHL units), it should be in the manual - and it > should be correct. These are the pages you can mark green. Once marked, > the pages must not change again, or they will lose their marks. That the current politic for green mark. > Everything else is subject to change. Projected stuff that hasn't been > implemented yet but is on its way (like the INC/CMP instructions) can be > marked yellow. The FP stuff also belongs into this category (except fcmp* > which is complete nonsense), and things like load/store/move/jump. Ok. > The rest belongs to the red category. It's mostly pure speculation. > Something may move up into the yellow category if there is a design > for it - that is, if somebody can start implementing it. Ok. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Dec 9 21:32:29 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LegA-0000Ls-01 for ; Tue, 10 Dec 2002 08:19:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:19:42 +0100 (CET) Received: (qmail 6998 invoked by uid 0); 9 Dec 2002 19:45:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 9 Dec 2002 19:45:22 -0000 Received: by moria.seul.org (Postfix) id 9909933DCE; Mon, 9 Dec 2002 14:45:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 043D233DD2; Mon, 9 Dec 2002 14:45:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 4A3B233DCF for ; Mon, 9 Dec 2002 14:45:20 -0500 (EST) Received: from thor (89.189.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.189.89]) by smtp3.9tel.net (Postfix) with ESMTP id 906765BE0C for ; Mon, 9 Dec 2002 20:45:19 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: cedric To: f-cpu@seul.org Subject: Re: Re: [f-cpu] 15 MIPS FC0 emulator Date: Mon, 9 Dec 2002 20:32:29 +0000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212092032.29162.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, > >> For cload/cstore, I think that because nobody reply on Yann mail : > >> "Re: [f-cpu] Conditionnal load and store, the return" (Date : > >> Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. > >Wrong. I know that SW people liked it, but it makes the implementation > >too complex. > huh i have to find exactly what it is about. > But i think that conditional load and store is > not a big problem. The exact semantics and behaviour > has to be defined but basicly, cload/cstore use the > same mechanism as conditional moves (for the condition > part) and the usual load/store (instead that it doesn't > trap when the condition is false, but the operation > is aborted anyway). See the trick ? [i wish it works, > in practice, though ;-)] Hum, still undecided ;-) > >> * New madd/msub // I think that's now they will be removed, because > >> normal add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu] > >> pointer add & sub"). > >Another undecided point. > as you both know, i see no point here. > a load to register 0 with postincrement does the same. Still undecided ? > >> * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet > >> written (the copy/paste is really unclear, need to be totally rewritten) > >Simple. But we used to call them differently: > > short long new > > ============================= > > a .and cand. > > o .or cor. > >where is one of: and, or, xor, andn, orn, nand, nor, xnor. All of > >them take a size suffix, > why can't nobody agree ? > i see the combine as a suffix, because it is performed > AFTER the logic operation. Otherwise it is potentially > misleading. >From my point of view combine is the most important information more in this instruction, but the point of view are possible, and I think that we can specify both. > >> * New safeload/safestore > >It's not clear how that can be implemented. > are we speaking about the atomic things ? Yes. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 9 21:01:47 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LegH-0000Ls-00 for ; Tue, 10 Dec 2002 08:19:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:19:49 +0100 (CET) Received: (qmail 10623 invoked by uid 0); 9 Dec 2002 20:05:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Dec 2002 20:05:53 -0000 Received: by moria.seul.org (Postfix) id A320533DCF; Mon, 9 Dec 2002 15:05:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EE9E333DD1; Mon, 9 Dec 2002 15:05:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a057.home.uni-hannover.de [130.75.232.57]) by moria.seul.org (Postfix) with ESMTP id 7ADE533DCF for ; Mon, 9 Dec 2002 15:05:49 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA01380; Mon, 9 Dec 2002 21:01:48 +0100 Message-ID: <20021209210147.50338@thrai.stud.uni-hannover.de> Date: Mon, 9 Dec 2002 21:01:47 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: [f-cpu] Zen and the art of F-CPU assembler coding References: <3DF35928.2030305@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Dec 09, 2002 at 12:13:13PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 09, 2002 at 12:13:13PM +0100, devik wrote: [...] > > But the function of the combine operations is also performed > > (in a slower way) by the ASU with saturation mode : it requires > > a bit more time and some more instruction but it does it. > > like add/subing 0xFE in saturated byte mode ? The bit 0 is > the result .. Hmm ! It is wonderfull !!! So cor.nxor is: > xor.8 ,,r1 > addsi.8 0xfe,r1,r1 > inc.8 r1,r1 [...] .o( What an ugly mess! ) It's more wonderful than you think: Both `cor' and `cand' can be substituted with only two other F-CPU instructions. No additional registers are required. And in contrast to your version, it's a general solution that will also work with larger chunks. Just add an unsigned compare-with-zero to a normal logic operation, and you've got it. cor.. is pretty obvious: b,a,r1 scmpl. r1,r0,r1 // in C: `-((a OP b) > 0u)' cand.. is a little more complex: it requires that the result of the logic operation is inverted: (*) n b,a,r1 scmple. r0,r1,r1 // in C: `-(~(a OP b) <= 0u)' (*) All F-CPU logic operations are invertible: <-> n ====================== a and b <-> a nand b a or b <-> a nor b a xor b <-> a xnor b a orn b <-> b andn a // DeMorgans law Q.E.D. :) With this substitution, the main loop of `strchr' may look like this: setup: loadi $8, r1, r3 // load first word early sdup.b r2, r2 loadaddri $end_of_loop-.-4, r7 loopentry r8 start_of_loop: xor r2, r3, r4 // t=0 if data in LSU scmple.b r0, r3, r5 // t=1 scmple.b r0, r4, r6 // t=2 loadi $8, r1, r3 // t=3 jmpnz r5, r7 // t=4 jmpz r6, r8 // t=5 end_of_loop: It takes 6 cycles for an 8-byte loop (additional cycles for the backward jump not counted), which is as fast as your version. This is the perfect code for testing the scheduler and the bypassing mechanism: there are RAW dependencies for r4, r5 and r6, and the timing is as tight as possible :) Note that we could also use combine: setup: loadi $8, r1, r3 // load first word early sdup.b r2, r2 loadaddri $end_of_loop-.-4, r7 loopentry r8 start_of_loop: xnor.and.b r0, r3, r4 // t=0 if data in LSU xnor.and.b r2, r3, r5 // t=1 loadi $8, r1, r3 // t=2 jmpnz r4, r7 // t=3 jmpz r5, r8 // t=4 end_of_loop: This is the fastest version I can imagine: 5 cycles (1.6 bytes/cycle with 64-bit registers). Instruction scheduling is optimal unless `xnor.and.b' takes more than two cycles (which is very unlikely). On the other hand, the examples show that we can live without combine. If we drop it (or maybe move it to a second pipeline stage and make it support *all* chunk sizes), there will be enough room in the ROP2 unit to add `n -> 2**n' decoders in front of it for 1-cycle btst/bchg/bset/bclr instructions that are more useful than combine, IMHO. .o( Yann probably wants to kill me now ) Greetings from your friendly bit mangler, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ... now this *was* fun, wasn't it? :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 10 22:32:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LegS-0000Ls-00 for ; Tue, 10 Dec 2002 08:20:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:20:00 +0100 (CET) Received: (qmail 22612 invoked by uid 0); 9 Dec 2002 21:54:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 9 Dec 2002 21:54:41 -0000 Received: by moria.seul.org (Postfix) id BF85033DCF; Mon, 9 Dec 2002 16:54:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3559533DD2; Mon, 9 Dec 2002 16:54:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 820A233DCF for ; Mon, 9 Dec 2002 16:54:39 -0500 (EST) Received: from Biathlon (vlt4-167.n.club-internet.fr [194.158.109.167]) by relay-5v.club-internet.fr (Postfix) with SMTP id 3EDFE193C for ; Mon, 9 Dec 2002 22:54:46 +0100 (CET) Date: Tue, 10 Dec 2002 22:32:30 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] 15 MIPS FC0 emulator Message-Id: <20021210223230.0a84d3ee.nicolas.boulay@ifrance.com> In-Reply-To: <200212091938.35478.cedric.bail@free.fr> References: <200212081558.52698.cedric.bail@free.fr> <20021209030553.49272@thrai.stud.uni-hannover.de> <200212091938.35478.cedric.bail@free.fr> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, 9 Dec 2002 19:38:35 +0000 cedric wrote: > > > For cload/cstore, I think that because nobody reply on Yann mail : > > > "Re: [f-cpu] Conditionnal load and store, the return" (Date : > > > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. > > > Wrong. I know that SW people liked it, but it makes the > > implementation too complex. > > Ok, I will remove it. > Wait, wait, wait ! Why conditionnal load&store must be removed ? load/store are maybe the most costly operation. It is much more efficient to use cload&cstore than use load&store then a cmove. nicO > > Cedric > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 9 22:39:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LegV-0000Ls-00 for ; Tue, 10 Dec 2002 08:20:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:20:03 +0100 (CET) Received: (qmail 789 invoked by uid 0); 9 Dec 2002 22:58:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 9 Dec 2002 22:58:37 -0000 Received: by moria.seul.org (Postfix) id 249E233D8A; Mon, 9 Dec 2002 17:58:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89AA633DD2; Mon, 9 Dec 2002 17:58:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id 0333933D8A for ; Mon, 9 Dec 2002 17:58:33 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01870; Mon, 9 Dec 2002 22:39:21 +0100 Message-ID: <20021209223921.50312@thrai.stud.uni-hannover.de> Date: Mon, 9 Dec 2002 22:39:21 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Re: [f-cpu] 15 MIPS FC0 emulator References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from whygee@club-internet.fr on Mon, Dec 09, 2002 at 05:00:03PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 09, 2002 at 05:00:03PM +0100, whygee@club-internet.fr wrote: [cload/cstore] > huh i have to find exactly what it is about. > But i think that conditional load and store is > not a big problem. The exact semantics and behaviour > has to be defined but basicly, cload/cstore use the > same mechanism as conditional moves (for the condition > part) and the usual load/store (instead that it doesn't > trap when the condition is false, but the operation > is aborted anyway). See the trick ? [i wish it works, > in practice, though ;-)] If you can make it work - fine. If not - to hell with it! [madd/msub] > as you both know, i see no point here. > a load to register 0 with postincrement does the same. I agree, as long as you turn off all exceptions and ignore cache misses(!) for the initial address. Example: loadi $-8, r62, r0 // prepare stack pointer for pushing storei $-8, r62, r32 ... storei $-8, r62, r57 store r62, r58 If r62 initially points to a cache line boundary, it will cause the cache to prefetch a line that isn't used at all. Instead, it should prefetch the line the register will point to *next*. A similar problem occurs if r62 initially points to a memory area that isn't mapped (TLB fault), or is badly aligned, or unreadable. > >> * New cshift > > > >I guess the jury is still out on that. > >BTW: `loadcons' also plays a role here. > > i am not sure what it is about, so i won't > step into that one ... cshift[lr] was meant to access the upper chunks if registers are wider than 64 bits. In a 64-bit core, we can make it either clear the destination register or trigger an invalid opcode exception. [...] > >> * New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet written > >> (the copy/paste is really unclear, need to be totally rewritten) > > > >Simple. But we used to call them differently: > > > > short long new > > ============================= > > a .and cand. > > o .or cor. > > > >where is one of: and, or, xor, andn, orn, nand, nor, xnor. All of > >them take a size suffix, > > why can't nobody agree ? I remember that we agreed on the old names - and I implemented both long and short versions in my assembler (more than a year ago?!) > i see the combine as a suffix, because it is performed > AFTER the logic operation. Otherwise it is potentially > misleading. Good point. > > but only .b is currently supported in hardware > >(because the latency would increase otherwise). > this will be determined at synthesis time, but it's > a first good guess that allows to do ASCII string searches > easily. As you can see in my other mail, that can also be done without combine. The resulting code will be only slightly slower, and works for all chunk sizes. [ROP2 description] > >I hope that was correct, I didn't look at the code for a while. Yann? > > right. *phew* ;) > >> * New safeload/safestore > > > >It's not clear how that can be implemented. > > are we speaking about the atomic things ? I think so. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 9 22:08:03 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LegW-0000Ls-00 for ; Tue, 10 Dec 2002 08:20:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:20:04 +0100 (CET) Received: (qmail 13112 invoked by uid 0); 9 Dec 2002 22:58:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 9 Dec 2002 22:58:42 -0000 Received: by moria.seul.org (Postfix) id 44D1C33DD2; Mon, 9 Dec 2002 17:58:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42DB733DD5; Mon, 9 Dec 2002 17:58:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id C7BB833DD2 for ; Mon, 9 Dec 2002 17:58:37 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01667; Mon, 9 Dec 2002 22:08:03 +0100 Message-ID: <20021209220803.55808@thrai.stud.uni-hannover.de> Date: Mon, 9 Dec 2002 22:08:03 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Taking decision on the project References: <200212091422.1b2d@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212091422.1b2d@th00.opsion.fr>; from Nicolas Boulay on Mon, Dec 09, 2002 at 02:22:27PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 09, 2002 at 02:22:27PM +0000, Nicolas Boulay wrote: > I don't have time as Michael to go deep regularly inside the manual. But > i don't like so much to change the manual depending on what is > implemented ! That is not the goal of a manual. What *is* the goal of a manual, then? It's not a wish list, is it? [...] > Our main document is the Manual, so Cedric find this way to speed up > decision : if nobody are against, it's adopted. During almost 2 year, > the manual did not change ! [...] I guess `speed up' is an euphemism for `force'? The manual must not change every day/week/month/year. It's THE reference for everybody who is going to implement something - VHDL, C or assembler, that doesn't matter. It should only change if it's wrong, or there is an implementation problem - and in either case, changes should be minimal. Everything else belongs into a wish list - but not into the manual. If I can't rely on the manual, I can't do anything. I can't implement a feature (such as a new instruction) as long as its design is changing. Neither can I finish my assembler as long as the instruction set is modified again and again (therefore it's still at version 0.0), or start working on its emulator companion :( The manual wasn't `not changing', it was *stable*, and that definitely was a Good Thing (tm). This point of view probably doesn't matter for you, but it does for me, and probably for everybody else who wants to contribute code to the F-CPU project - whether it's VHDL or supporting software like compilers, tools, operating system ports and so on. Frequent design changes will just annoy and discourage active developers as well as developers `in spe'. Look, I want this project to be successful. But if you don't stop changing the specs, FC0 will still not be up and running in 2022 :( So please let the manual stabilize again, and keep all your great ideas in a separate document, for FC1 or later versions of the F-CPU core. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Dec 10 01:54:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Legm-0000Ls-01 for ; Tue, 10 Dec 2002 08:20:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:20:20 +0100 (CET) Received: (qmail 3014 invoked by uid 0); 10 Dec 2002 00:59:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 10 Dec 2002 00:59:21 -0000 Received: by moria.seul.org (Postfix) id 17F2333DD5; Mon, 9 Dec 2002 19:59:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88D5C33DDB; Mon, 9 Dec 2002 19:59:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id E4D0633DD5 for ; Mon, 9 Dec 2002 19:59:19 -0500 (EST) Received: from homeworld (81.50.64.41) by smtp.laposte.net (6.0.053) id 3DDAB94B0028CDBE for f-cpu@seul.org; Tue, 10 Dec 2002 01:59:18 +0100 Message-ID: <004501c29fe6$bb239140$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200212081558.52698.cedric.bail@free.fr><20021209030553.49272@thrai.stud.uni-hannover.de><200212091938.35478.cedric.bail@free.fr> <20021210223230.0a84d3ee.nicolas.boulay@ifrance.com> Subject: Re: [f-cpu] 15 MIPS FC0 emulator Date: Tue, 10 Dec 2002 01:54:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Sorry to say, but I don't understand what you are speaking about. Are you speaking about a similar "ll/sc" that wa can find in MIPS architecture ? we need a "load" which tags a LSU entry as being not modified and a "store" which checks if this LSU entry has not been modified. If this LSU entry has been changed, we abort the "store" operation, otherwise we do "store" and tags the LSU entry as being modified so other attempts to "store" fail. At the end a register must be set to tell us if "store" operation aborted. Unhopefully, I feel there is a problem with 3 threads : thread A "load"s 1 in Va then adds 4 => Va = 5 thread B "load"s 1 in Vb then adds 2 => Vb = 3 thread C "load"s 1 in Vc then adds 1 => Vc = 2 thread C "store"s Vc (2) : success thread A "store"s Va (5) : failure thread A "load"s 2 in Va then adds 4 => Va = 6 thread B "store"s Vb (3) : success <--- INCONSISTENCY ! So there is a problem for multi-threading :( I think the only way to circumvent it is to do so : cmpxchg r1,[r2],r3 1) read the value from the LSU entry pointed by r2 2) if it equals to r3, r1 is stored in the LSU entry pointed by r2 3) the read value is ouput in r3. an atomic increment looks like it : atomic_inc: load [r2],r1 loopentry r4 addi $1,r1,r3 cmpxchg r3,[r2],r1 xor r1,r3,r3 if (r3 != 0) jump r4 That can vary but I think we must to be able to read and/write in LSU entry in atomic fashion. ----- Original Message ----- From: "nico" To: Sent: Tuesday, December 10, 2002 10:32 PM Subject: Re: [f-cpu] 15 MIPS FC0 emulator > On Mon, 9 Dec 2002 19:38:35 +0000 > cedric wrote: > > > > > For cload/cstore, I think that because nobody reply on Yann mail : > > > > "Re: [f-cpu] Conditionnal load and store, the return" (Date : > > > > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted. > > > > > Wrong. I know that SW people liked it, but it makes the > > > implementation too complex. > > > > Ok, I will remove it. > > > > Wait, wait, wait ! > > Why conditionnal load&store must be removed ? load/store are maybe the > most costly operation. It is much more efficient to use cload&cstore > than use load&store then a cmove. > > nicO > > > > > Cedric > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue Dec 10 02:08:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Legn-0000Ls-00 for ; Tue, 10 Dec 2002 08:20:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 08:20:21 +0100 (CET) Received: (qmail 11245 invoked by uid 0); 10 Dec 2002 01:13:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 10 Dec 2002 01:13:25 -0000 Received: by moria.seul.org (Postfix) id 95BBA33DD9; Mon, 9 Dec 2002 20:13:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 21F9033DDC; Mon, 9 Dec 2002 20:13:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 99AF233DD9 for ; Mon, 9 Dec 2002 20:13:23 -0500 (EST) Received: from homeworld (81.50.64.41) by smtp.laposte.net (6.0.053) id 3DDAB94B0028D204 for f-cpu@seul.org; Tue, 10 Dec 2002 02:13:23 +0100 Message-ID: <006b01c29fe8$b26cd0a0$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200212081558.52698.cedric.bail@free.fr><20021209030553.49272@thrai.stud.uni-hannover.de><200212091938.35478.cedric.bail@free.fr> <20021210223230.0a84d3ee.nicolas.boulay@ifrance.com> <004501c29fe6$bb239140$0100000a@homeworld> Subject: Re: [f-cpu] 15 MIPS FC0 emulator Date: Tue, 10 Dec 2002 02:08:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N There is an error :( > atomic_inc: > load [r2],r1 > loopentry r4 > addi $1,r1,r3 > cmpxchg r3,[r2],r1 > xor r1,r3,r3 > if (r3 != 0) jump r4 the last 3 lines must be : cmpxchg r3,[r2],r5 xor r1,r5,r5 if (r5 != 0) jump r4 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 10 11:45:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ljh7-0003pd-01 for ; Tue, 10 Dec 2002 13:41:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 13:41:01 +0100 (CET) Received: (qmail 10110 invoked by uid 0); 10 Dec 2002 10:56:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 10 Dec 2002 10:56:13 -0000 Received: by moria.seul.org (Postfix) id 87C7A33DE6; Tue, 10 Dec 2002 05:56:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE83833DE8; Tue, 10 Dec 2002 05:56:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 4A8FD33DE6 for ; Tue, 10 Dec 2002 05:56:11 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 7BE4C4F86A for ; Tue, 10 Dec 2002 04:54:43 -0600 (CST) Received: from a89-137.dialup.iol.cz ([194.228.137.89] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Li3I-0000UG-00 for f-cpu@seul.org; Tue, 10 Dec 2002 11:55:48 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18LhtF-0000Bu-00 for f-cpu@seul.org; Tue, 10 Dec 2002 11:45:25 +0100 Date: Tue, 10 Dec 2002 11:45:25 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Zen and the art of F-CPU assembler coding In-Reply-To: <20021209210147.50338@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > xor.8 ,,r1 > > addsi.8 0xfe,r1,r1 > > inc.8 r1,r1 > > .o( What an ugly mess! ) > > It's more wonderful than you think: Both `cor' and `cand' can be > substituted with only two other F-CPU instructions. No additional > registers are required. And in contrast to your version, it's a general > solution that will also work with larger chunks. Just add an unsigned > compare-with-zero to a normal logic operation, and you've got it. What is .o(...) :-) ? You version with cmple is much better, no doubt ! I like it :-) > On the other hand, the examples show that we can live without combine. > If we drop it (or maybe move it to a second pipeline stage and make it > support *all* chunk sizes), there will be enough room in the ROP2 unit to > add `n -> 2**n' decoders in front of it for 1-cycle btst/bchg/bset/bclr > instructions that are more useful than combine, IMHO. It would be very nice (how complex is such decoder?). Could be possible to support bnclr then (when we have nand) ? I used bseti $C,r0,r for loading some constants in my gcc backend and it helped the code. bnclr $C,r0,r could be used to load big masks with one cleared bit. Both of these constants are heavily used in C codes to create and modify flag bitmasks and rotating masks for bit selection. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 10 12:13:16 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LjhC-0003pd-00 for ; Tue, 10 Dec 2002 13:41:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 10 Dec 2002 13:41:06 +0100 (CET) Received: (qmail 30720 invoked by uid 0); 10 Dec 2002 11:27:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 10 Dec 2002 11:27:02 -0000 Received: by moria.seul.org (Postfix) id 5C4FA33DE7; Tue, 10 Dec 2002 06:27:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6BB233DE9; Tue, 10 Dec 2002 06:27:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 444D633DE7 for ; Tue, 10 Dec 2002 06:27:00 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 6B6B54F86C for ; Tue, 10 Dec 2002 05:25:32 -0600 (CST) Received: from a75-137.dialup.iol.cz ([194.228.137.75] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18LiXR-0000aS-00 for f-cpu@seul.org; Tue, 10 Dec 2002 12:26:57 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18LiKC-0000Du-00 for f-cpu@seul.org; Tue, 10 Dec 2002 12:13:16 +0100 Date: Tue, 10 Dec 2002 12:13:16 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Zen and the art of F-CPU assembler coding In-Reply-To: <20021209210147.50338@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > If we drop it (or maybe move it to a second pipeline stage and make it > support *all* chunk sizes), there will be enough room in the ROP2 unit to > add `n -> 2**n' decoders in front of it for 1-cycle btst/bchg/bset/bclr > instructions that are more useful than combine, IMHO. One more idea/question, the ROP2 3->4 decoder is placed in xbar stage. If `n -> 2**n' decoders would take too many time, at least immediate form (which is the most used one for bit flag manipulation) can be done by moving decoders (or pipelinable part of them) to xbar stage too. Or do you know any important usage of non-immediate form with significant savings from shift+and/or method ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Dec 10 15:35:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LxaM-0000Fz-00 for ; Wed, 11 Dec 2002 04:30:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 04:30:58 +0100 (CET) Received: (qmail 11025 invoked by uid 0); 10 Dec 2002 18:48:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 10 Dec 2002 18:48:24 -0000 Received: by moria.seul.org (Postfix) id 140D833DE6; Tue, 10 Dec 2002 13:48:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7ABAC33DF2; Tue, 10 Dec 2002 13:48:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a098.home.uni-hannover.de [130.75.232.98]) by moria.seul.org (Postfix) with ESMTP id 7E63A33DE6 for ; Tue, 10 Dec 2002 13:48:21 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00689; Tue, 10 Dec 2002 15:35:46 +0100 Message-ID: <20021210153546.19779@thrai.stud.uni-hannover.de> Date: Tue, 10 Dec 2002 15:35:46 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Zen and the art of F-CPU assembler coding References: <20021209210147.50338@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Dec 10, 2002 at 12:13:16PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Dec 10, 2002 at 12:13:16PM +0100, devik wrote: > One more idea/question, the ROP2 3->4 decoder is placed in > xbar stage. If `n -> 2**n' decoders would take too many time, > at least immediate form (which is the most used one for bit flag > manipulation) can be done by moving decoders (or pipelinable part > of them) to xbar stage too. Don't worry, there is enough room. There will also be enough room to move the 3->4 decoder out of the Xbar into the ROP2 where it belongs. A 6->64 decoder is approximately three gates deep, and none of them is an XOR - that is less than 1/2 pipeline stage. > Or do you know any important usage of non-immediate form > with significant savings from shift+and/or method ? I guess it's rarely needed, but I think we should provide it anyway. All immediate binary operations have non-immediate counterparts, and if it helps us save a register (for the mask) when registers are short, its presence is already justified. It will also be helpful in instruction emulators. Just in case someone wants to execute his old x86/68k/PPC/SPARC binaries on the F-CPU :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Dec 10 14:50:40 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LxaM-0000Fz-01 for ; Wed, 11 Dec 2002 04:30:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 04:30:58 +0100 (CET) Received: (qmail 11463 invoked by uid 0); 10 Dec 2002 18:48:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 10 Dec 2002 18:48:31 -0000 Received: by moria.seul.org (Postfix) id A193233DF0; Tue, 10 Dec 2002 13:48:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BF9A133DF3; Tue, 10 Dec 2002 13:48:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a098.home.uni-hannover.de [130.75.232.98]) by moria.seul.org (Postfix) with ESMTP id 703B033DF0 for ; Tue, 10 Dec 2002 13:48:23 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00587; Tue, 10 Dec 2002 14:50:41 +0100 Message-ID: <20021210145040.61849@thrai.stud.uni-hannover.de> Date: Tue, 10 Dec 2002 14:50:40 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Zen and the art of F-CPU assembler coding References: <20021209210147.50338@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Dec 10, 2002 at 11:45:25AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Dec 10, 2002 at 11:45:25AM +0100, devik wrote: > What is .o(...) :-) ? You version with cmple is much better, > no doubt ! I like it :-) .o(...) means that I was just thinking "...". > > On the other hand, the examples show that we can live without combine. > > If we drop it (or maybe move it to a second pipeline stage and make it > > support *all* chunk sizes), there will be enough room in the ROP2 unit to > > add `n -> 2**n' decoders in front of it for 1-cycle btst/bchg/bset/bclr > > instructions that are more useful than combine, IMHO. > > It would be very nice (how complex is such decoder?). Could be possible > to support bnclr then (when we have nand) ? Yes. The decoder will just change the way the second operand is interpreted, everything else remains unchanged. > I used bseti $C,r0,r for loading some constants in my gcc backend and > it helped the code. bnclr $C,r0,r could be used to load big masks > with one cleared bit. Both of these constants are heavily used in > C codes to create and modify flag bitmasks and rotating masks for > bit selection. In fact, the compiler's optimization phase should get rid of those C idioms and use bitop directly when a single-bit mask is needed. For mask = 1 << count; if (item & mask) ... it should use something like btst count, item, tmp jmp[n]z tmp, target and not deal with constant shifting at all. Similarly, if you want to clear a single bit, just use bclr $index, reg, reg In other cases, bnclr & friends might be quite helpful, though. E.g. LONG_MAX (0x7fffffffffffffff) could be loaded with a single bnseti $63, r0, reg NB: We got to carefully choose the mnemonics. Maybe we should use `band', `bor', `bxor' and so on for clarity. The old `legacy' instructions (bset, bclr, bchg and btst) should still be supported, however. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 11 20:27:11 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18LxaS-0000Fz-01 for ; Wed, 11 Dec 2002 04:31:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 04:31:04 +0100 (CET) Received: (qmail 30811 invoked by uid 0); 10 Dec 2002 19:49:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 10 Dec 2002 19:49:59 -0000 Received: by moria.seul.org (Postfix) id A0ED233DEE; Tue, 10 Dec 2002 14:49:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6F2233DF3; Tue, 10 Dec 2002 14:49:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 1B58D33DEE for ; Tue, 10 Dec 2002 14:49:57 -0500 (EST) Received: from Biathlon (vlt6-94.n.club-internet.fr [194.158.119.94]) by relay-2v.club-internet.fr (Postfix) with SMTP id 4E1C91C84 for ; Tue, 10 Dec 2002 20:49:52 +0100 (CET) Date: Wed, 11 Dec 2002 20:27:11 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Taking decision on the project Message-Id: <20021211202711.066d1b50.nicolas.boulay@ifrance.com> In-Reply-To: <20021209220803.55808@thrai.stud.uni-hannover.de> References: <200212091422.1b2d@th00.opsion.fr> <20021209220803.55808@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, 9 Dec 2002 22:08:03 +0100 Michael Riepe wrote: > On Mon, Dec 09, 2002 at 02:22:27PM +0000, Nicolas Boulay wrote: > > > I don't have time as Michael to go deep regularly inside the manual. > > But i don't like so much to change the manual depending on what is > > implemented ! That is not the goal of a manual. > > What *is* the goal of a manual, then? > It's not a wish list, is it? > That's the main point. But a just point here the fact that manual come first and bevore the implementation. I speak later about it. > [...] > > Our main document is the Manual, so Cedric find this way to speed up > > decision : if nobody are against, it's adopted. During almost 2 > > year, the manual did not change ! > [...] > > I guess `speed up' is an euphemism for `force'? > :) At least, some dead discussion is keep elive. > The manual must not change every day/week/month/year. It's THE > reference for everybody who is going to implement something - VHDL, C > or assembler, that doesn't matter. It should only change if it's > wrong, or there is an implementation problem - and in either case, > changes should be minimal. Everything else belongs into a wish list - > but not into the manual. > > If I can't rely on the manual, I can't do anything. I can't implement > a feature (such as a new instruction) as long as its design is > changing. Neither can I finish my assembler as long as the instruction > set is modified again and again (therefore it's still at version 0.0), > or start working on its emulator companion :( > > The manual wasn't `not changing', it was *stable*, and that definitely > was a Good Thing (tm). This point of view probably doesn't matter for > you, but it does for me, and probably for everybody else who wants to > contribute code to the F-CPU project - whether it's VHDL or supporting > software like compilers, tools, operating system ports and so on. > Frequent design changes will just annoy and discourage active > developers as well as developers `in spe'. > [fc0 problem] Moving spec kill project, i could see in every day work. But from my point of view, the manual is only 90% done. It lack some important point as interrupt/trap/exception management. Some instruction are crazy (like the old cache management instruction, since removed) but MAC instruction are bad too : it introduice a RAW dependancies inside the instruction it-self. It lack mutli-cpu support that's a big lack for a 2004 cpu ! (ll/sc are for mono cpu system !) [LSU issue] That's a nice trick to tide cache line to the register adresse. So in the same time you decode your opcode+register banck, a cache line is ready. For very quick access it need to have as many line than register (that's not a big deal !). That's great for code. But not for data. Why ? Because it introduice uncoherency in the memory flow : what happen if the 2 registers map the same adresse ? 2 lines will be fill up. 2 lines could be modified in it's own side ! Whygee propose to detect 2 alias maybe 3. Beside the fact that it will be a hudge piece of silicon, i beleive that's not acceptable for compiler. Finding all memory alias in C code will be such a mess ! Our recent Gcc expert could better said about that. My proposal was to use the stream hint. That's what they are supposed to do : split memory stream, to avoid checking read-after-write memory hasard. If compiler didn't use them cleanly : shame on it :) That introduice 7 cache lines instead of 64, that's fewer but much easier to handle. [OOC] Maybe the bigest problem is the exception handling. "in the decoder" as whygee said. That's okay for integer op. That say : keep the pipeline in order until all possible exception could be raised to cancel the execution and goes to the trap handler. That's a nice feature : we could hide latency of instruction as "div" by other instructions, register number keep the coherency. The div_by_zero condition is control very early in the pipeline, after it could run without problem asynchronously. That means that further instruction will modify some registers before the result of the div. In case of external interrupt we just wait to complete those instructions. But it didn't work any more for floating point unit. NAN, infinite must be implemented. Those execption came at the end of the pipeline of the unit. We could not hide latency any more. Each instruction must wait the complete end of the previous one. It will be so slow ! Reordering buffer of today cpu are not a stupid bad dream of some engineer that smoke to much! It permit to do register bypass, continuous run and avoid waiting like that. It permit to relaxe the condition of puting the exception traitement of each unit early in the pipeline. [fcO lack] [2r1w->3r2w] Beside that there is "some choice" that i dislike in FC0. For example, the trick to be 3r2w by using 2r1w instructions. We use 3r1w register port but 90% of our instruction set are 2r1w (register access time between 2r1w and 3r2w is at least 30 % slower, at least ! that the difference between 2 Ghz and 1.4 Ghz cpu). And compiler risk to schedule only 32 registers. (That's why i propose my "little vliw", 4r2w but with 2 instructions issue by cycle (or we could also used 2 separates register bank (and double the register number :) to have the 2r1w speed by instruction slot, so at least 1.3*2=2.6 the orginal speed). I don't think that introduice so much change to the manual.) [.call mess] The last point i dislike is the hundred clock cycle needed to make a "typical" function call. The example given by Cedric was scaring ! I program/use sparc like (ERC32 == Sparc V7) cpu, "typical" .call use 3 clock cycle... I beleive more and more that using window register should be consider. That the compiler work to do the right job ! (maybe 24 rotating register + 40 fixe one, otherwise the window will be to small ?). Sparc always reserve one windows for interrupt handling, so always 8 refresh registers are ready for it (no stack manipulation for simple handler, no complexe srb, no use of SR). > Look, I want this project to be successful. But if you don't stop > changing the specs, FC0 will still not be up and running in 2022 :( So > please let the manual stabilize again, and keep all your great ideas > in a separate document, for FC1 or later versions of the F-CPU core. > Thanks for the "great idea" :) I insist on it because it's 10% of the manual change for roughly 250% speed improvement. I should write about it :) nicO > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 11 14:55:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18M61W-0000Bi-00 for ; Wed, 11 Dec 2002 13:31:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 13:31:34 +0100 (CET) Received: (qmail 21559 invoked by uid 0); 11 Dec 2002 09:55:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 11 Dec 2002 09:55:20 -0000 Received: by moria.seul.org (Postfix) id DEE1D33C54; Wed, 11 Dec 2002 04:55:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4169533C57; Wed, 11 Dec 2002 04:55:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 728CF33C54 for ; Wed, 11 Dec 2002 04:55:18 -0500 (EST) Received: from club-internet.fr (flashmail-2v.cs.clubint.net [172.16.0.152]) by relay-5v.club-internet.fr (Postfix) with SMTP id 1794C1DE8 for ; Wed, 11 Dec 2002 10:55:24 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: Re: [f-cpu] Taking decision on the project Date: Wed, 11 Dec 2002 10:55:15 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, >De: nico >Thanks for the =22great idea=22 :) I insist on it because it's 10% of the >manual change for roughly 250% speed improvement. I should write about >it :) yes, one day... and maybe you can even find the courage to implement something. >nicO >> Michael =22Tired=22 Riepe YG (PS: i'm sorry i can't answer line-by-line, i don't have time today, things are crazy and mad these last days in Orsay) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 11 11:29:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18M61f-0000Bi-00 for ; Wed, 11 Dec 2002 13:31:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 13:31:43 +0100 (CET) Received: (qmail 3157 invoked by uid 0); 11 Dec 2002 10:48:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Dec 2002 10:48:48 -0000 Received: by moria.seul.org (Postfix) id 33FC733C55; Wed, 11 Dec 2002 05:48:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78C6833C59; Wed, 11 Dec 2002 05:48:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 3DF0D33B49 for ; Wed, 11 Dec 2002 05:48:45 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 3981A4F6E4 for ; Wed, 11 Dec 2002 04:47:16 -0600 (CST) Received: from a83-137.dialup.iol.cz ([194.228.137.83] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18M4Pt-0007c6-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:48:37 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18M47W-0000GV-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:29:38 +0100 Date: Wed, 11 Dec 2002 11:29:38 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] Relative branch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Just short idea, I was found that in compiled code for fcpu is missing shorter/faster jump. Why dont we have jump which instead of registers to use as return address save and target adres have instead 12bit immediate which would REPLACE lower 8 bits (for example) of IP. There is no problem with TLB because smallest page is 4k (12bits) so that we could jump only in the same page. It also meand no adder is needed. Compiler would emit appropriate .align for the code. This would help small conditional branches, save code size and register usage ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 11 11:39:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18M61f-0000Bi-01 for ; Wed, 11 Dec 2002 13:31:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 13:31:43 +0100 (CET) Received: (qmail 1480 invoked by uid 0); 11 Dec 2002 10:48:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 11 Dec 2002 10:48:53 -0000 Received: by moria.seul.org (Postfix) id EAB8E33C57; Wed, 11 Dec 2002 05:48:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5C15C33C5A; Wed, 11 Dec 2002 05:48:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 5F66D33C57 for ; Wed, 11 Dec 2002 05:48:46 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 6BAA84F749 for ; Wed, 11 Dec 2002 04:47:17 -0600 (CST) Received: from a83-137.dialup.iol.cz ([194.228.137.83] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18M4Pp-0007c6-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:48:34 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18M4HJ-0000Gy-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:39:45 +0100 Date: Wed, 11 Dec 2002 11:39:45 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] Popcount usage ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, what is popcount used for ? From my analysis of compiled codes it is used in IA64 mainly for implementing ffs/ffz. So what is it good for ? I can be computed for 64bits using existing operations by cca 22 insns in about 30 cycles. Is it the op so critical for some high performance algos ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 11 11:23:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18M61g-0000Bi-00 for ; Wed, 11 Dec 2002 13:31:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 13:31:44 +0100 (CET) Received: (qmail 25196 invoked by uid 0); 11 Dec 2002 10:49:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 11 Dec 2002 10:49:02 -0000 Received: by moria.seul.org (Postfix) id AFBEF33B49; Wed, 11 Dec 2002 05:48:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6AD3A33C5D; Wed, 11 Dec 2002 05:48:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 2D2B733B49 for ; Wed, 11 Dec 2002 05:48:49 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id D18734F660 for ; Wed, 11 Dec 2002 04:47:19 -0600 (CST) Received: from a83-137.dialup.iol.cz ([194.228.137.83] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18M4Pq-0007c6-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:48:35 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18M41R-0000GR-00 for f-cpu@seul.org; Wed, 11 Dec 2002 11:23:21 +0100 Date: Wed, 11 Dec 2002 11:23:21 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Taking decision on the project In-Reply-To: <20021211202711.066d1b50.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > It lack mutli-cpu support that's a big lack for a 2004 cpu ! (ll/sc are > for mono cpu system !) I just read IA64 system manual, there are many MP issues discussed along with examples ... Maybe it could help .. > Whygee propose to detect 2 alias maybe 3. Beside the fact that it will > be a hudge piece of silicon, i beleive that's not acceptable for > compiler. Finding all memory alias in C code will be such a > mess ! Our recent Gcc expert could better said about that. hmm if it is about me, I'm not gcc expert ;-) But I have to say that gcc marks some register as they contain non-aliased data (if it knows) but for majority pointers gcc is "not sure". There are aliasing data attached to each memory reference which contains type and parent (structure) of datum. Unfortunately when I tested with some code snippets, many pointers have simply [0 S8 A64] alias set so that they can't be distinguished by gcc. > My proposal was to use the stream hint. That's what they are supposed to > do : split memory stream, to avoid checking read-after-write memory > hasard. If compiler didn't use them cleanly : shame on it :) That > introduice 7 cache lines instead of 64, that's fewer but much easier to > handle. hummm, what problem addresses these things ? Memory RAW ? In UP environment these should not occur AFAIK because all caches are controled by single CPU and cache lines should not be aliased. For MP why don't use acquire/release semantic or at least memory fence ? > But it didn't work any more for floating point unit. NAN, infinite must > be implemented. Those execption came at the end of the pipeline of the > unit. We could not hide latency any more. Each instruction must wait the > complete end of the previous one. It will be so slow ! could not FPU store these flags into output register (or some attached flag of it) and trap when the value is attempted to be used ? > Reordering buffer of today cpu are not a stupid bad dream of some > engineer that smoke to much! It permit to do register bypass, is there ROB in IA64 !? From slides I remember there was not one. They claimed that stop flags delimit insn group which can be executed and make visible immediately ... > [2r1w->3r2w] > Beside that there is "some choice" that i dislike in FC0. For example, > the trick to be 3r2w by using 2r1w instructions. We use 3r1w register > port but 90% of our instruction set are 2r1w (register access time > between 2r1w and 3r2w is at least 30 % slower, at least ! that the > difference between 2 Ghz and 1.4 Ghz cpu). And compiler risk to schedule > only 32 registers. The only "problem" seems to be that "3r". I played with my little emulator and most of the time (>50%) both 2w was used. So that one read port is unused most of the time. There are some insn which need 3r and are useful like MUX or postincremented store (however I can imagine it in imm form only - then it is 2r). If MUX = (A andn M) or (B and M) it can be done with 3 insn with one cycle stall (but compiler can use the cycle). If whole program is made of 10% muxes if will slow it down by 20%. But if the CPU will be 20% faster with 2r2w it is the same timing. Next candidate is cstore - it reads condition, address and data. Well someone wanted it to be dropped (MR?). On other hand (I know it is crazy) if only z/nz would be implemented than there is no need for the third read port. Any other 3r insn waiting for comments ;-)) ? > (That's why i propose my "little vliw", 4r2w but with 2 instructions > issue by cycle (or we could also used 2 separates register bank (and > double the register number :) to have the 2r1w speed by instruction > slot, so at least 1.3*2=2.6 the orginal speed). I don't think that > introduice so much change to the manual.) it will introduce many stalls for common sequences like: add xor ; here both add & xor writes the result and what about 2w insns ? Some are very useful, add with carry, multiply with hi part. Well both problems above could be solved by delay FFs and more clever scheduler - it could postpone the second write of insn to next cycle. If compiler is aware of it, it will schedule like: mulh ; 6c latency insn2 insn3 insn4 mul add1 ; mul wrt1 add2 ; mul wrt2 add3 ; add1 wrt But for generic code there will be still many stalls probably. > [.call mess] > The last point i dislike is the hundred clock cycle needed to make a > "typical" function call. The example given by Cedric was scaring ! I eh !? Speaking about register saves ? Hmm. I was hoping that SRB will be really used to implement mstore/mload. It would be nice to have prolog with one mstore and storing done in background. mstore could be limited by OS to store up to N registers at once to not kill interupt latency. N can be different for desktop, server, RTOS ... > I beleive more and more that using window register should > be consider. That the compiler work to do the right job ! (maybe 24 > rotating register + 40 fixe one, otherwise the window will be to small > ?). Sparc always reserve one windows for interrupt handling, so always 8 > refresh registers are ready for it (no stack manipulation for simple > handler, no complexe srb, no use of SR). hmm YG convinced me that spilling of rotating registers is hard task and rotating itsels adds at least one pipeline stage. Link time register allocation would do better in any case and with mstore ... it could be even faster than rotating sets. But ! SRM will probably need to be revided - for example why to save ALL registers on interrupt ? I'd imagine to save only small ammount of regs (4 f.ex.) by interrupt and if more meeded then first insn in trap handler would be mstore to make more room (IF needed). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 11 16:21:32 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18M61i-0000Bi-01 for ; Wed, 11 Dec 2002 13:31:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 13:31:46 +0100 (CET) Received: (qmail 24395 invoked by uid 0); 11 Dec 2002 11:21:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 11 Dec 2002 11:21:35 -0000 Received: by moria.seul.org (Postfix) id 07CAF33C5C; Wed, 11 Dec 2002 06:21:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B71333C5F; Wed, 11 Dec 2002 06:21:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 03FE733C5C for ; Wed, 11 Dec 2002 06:21:33 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-4v.club-internet.fr (Postfix) with SMTP id 8BE951D20 for ; Wed, 11 Dec 2002 12:21:31 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Popcount usage ? Date: Wed, 11 Dec 2002 12:21:32 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >Hi, >what is popcount used for ? From my analysis of >compiled codes it is used in IA64 mainly for implementing >ffs/ffz. >So what is it good for ? I can be computed for 64bits >using existing operations by cca 22 insns in about >30 cycles. Is it the op so critical for some high >performance algos ? it is used for 2 main reasons : - during powerup, it is a piece of the BIST system. it is used for signature compaction in front of a LFSR, it compacts 128 bits down to 6 bits. - For some communication, storage or signal processing algos, it is used to compute the Hamming distance (it has a XOR of two operands in front of it). And it looks sexy for all the spooks out there. But it is optionnal, that is : you can forget it, if you want, in case you use a FPGA. However, if you implement it in silicon, then power-up BIST will need it. >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Wed Dec 11 17:16:50 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MAJE-0003OU-00 for ; Wed, 11 Dec 2002 18:06:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 18:06:08 +0100 (CET) Received: (qmail 31191 invoked by uid 0); 11 Dec 2002 12:16:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 11 Dec 2002 12:16:57 -0000 Received: by moria.seul.org (Postfix) id 6092F33C5A; Wed, 11 Dec 2002 07:16:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C49DB33C5F; Wed, 11 Dec 2002 07:16:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 433E033C5A for ; Wed, 11 Dec 2002 07:16:55 -0500 (EST) Received: from club-internet.fr (flashmail-1v.cs.clubint.net [172.16.0.151]) by relay-2v.club-internet.fr (Postfix) with SMTP id ECC3D1DE5 for ; Wed, 11 Dec 2002 13:16:50 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] Relative branch Date: Wed, 11 Dec 2002 13:16:50 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >Date: Wed, 11 Dec 2002 11:29:38 +0100 (CET) >De: devik >A: >Sujet: =5Bf-cpu=5D Relative branch > >Just short idea, I was found that in compiled >code for fcpu is missing shorter/faster jump. well, it's not exactly =22missing=22, it must be made by a sequence of instructions... >Why dont we have jump which instead of registers >to use as return address save and target adres >have instead 12bit immediate which would REPLACE >lower 8 bits (for example) of IP. huh ... because in FC0, the IP is =22virtual=22. there is no such register implemented in HW. Instead, the IP is =22generated=22 by the instruction fetch buffer from several fields in the cache line. >There is no problem with TLB because smallest page >is 4k (12bits) so that we could jump only in the same >page. It also meand no adder is needed. yup but jumping across pages are not possible. And that behaviour would change depending on the page size (well, i try to forecast this case). >Compiler would emit appropriate .align for the code. >This would help small conditional branches, save >code size and register usage ... but what about speed ? the goal is to spread the jump code, because it is simply impossible to jump in a single cycle. Imagine that you have a cjump instruction with a new address' LSB, you have to - fetch the address (several cycles) - check the condition in parallel - decode the new instruction etc. At least, the =22split branch=22, even if it takes several instructions, hides some of the pipeline bubble's size. And this is easily =22factored=22 because in loops or other codes, you can fetch once and jump to that position from several places. But yes, the intent was not to fit directly with GCC. but it's not too complex and not too slow. The rest is =22SW issues=22... :-P >devik YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 11 05:13:12 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MAJK-0003OU-01 for ; Wed, 11 Dec 2002 18:06:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 11 Dec 2002 18:06:14 +0100 (CET) Received: (qmail 30114 invoked by uid 0); 11 Dec 2002 12:52:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 11 Dec 2002 12:52:45 -0000 Received: by moria.seul.org (Postfix) id DCCA033C54; Wed, 11 Dec 2002 07:52:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F6AF33C60; Wed, 11 Dec 2002 07:52:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a112.home.uni-hannover.de [130.75.232.112]) by moria.seul.org (Postfix) with ESMTP id 8A3FA33C54 for ; Wed, 11 Dec 2002 07:52:40 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA02132; Wed, 11 Dec 2002 05:13:12 +0100 Message-ID: <20021211051312.33420@thrai.stud.uni-hannover.de> Date: Wed, 11 Dec 2002 05:13:12 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] strchr() again Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi F-gang, here is my version of strchr(), in `mr-as' syntax as usual. It's similar to deviks version, but I use my optimized 5-cycle main loop, and I handle some things differently. As a result, the prologue is slightly shorter. I hope that I got the matching conditions right - there may be several matches with both the target character and 0, and only the very first one is valid. If there only is a match with zero, the function will take the emergency exit (note that the sequence of the jump instructions is important). The epilogue contains a little speculative execution, in order to avoid stalls (if you can still find some, or you find a bug, please tell me). If there is no match, the routine takes approximately 13 + 5/8 * n instructions (n = string length). An empty string is scanned in 16 cycles. If a match is found, there are approximately 20 + 5/8 * n instructions to execute (n = relative position of the match). Compared to a bytewise search, which will take at least 3 cycles per byte (load, compare and jump), the overhead amortizes for n >= 6...9 bytes, depending on whether there's a match and where it is located. At n >= 35...54 bytes, speed increases above 1.0 bytes/cycle, asymptotically approaching 1.6 bytes/cycle (for a 64-bit CPU - double width, double throughput!). .align 32 // align to cache line boundary .global strchr strchr: // prologue andni $7, r1, r3 // aligned `long*' pointer andi $7, r1, r4 // byte offset loadi $8, r3, r5 // load first data word shiftli $3, r4, r7 // 8 * byte offset orn r0, r0, r8 // -1L sdup.b r2, r6 // duplicate character value shiftl r7, r8, r9 // mask loadaddri $found-.-4, r31 move r0, r1 // preload NULL result // first compare xnor.and.b r6, r5, r10 // compare with character xnor.and.b r0, r5, r11 // compare with 0 loadi $8, r3, r5 // load second data word and r9, r10, r12 // mask off unused bytes and r9, r11, r13 // mask off unused bytes jmpnz r12, r31 // found character jmpnz r13, r63 // found 0, terminate // main loop loopentry r30 xnor.and.b r6, r5, r12 // compare with character xnor.and.b r0, r5, r13 // compare with 0 loadi $8, r3, r5 // load next data word jmpnz r12, r31 // found character jmpz r13, r30 // loop unless a 0 occurred jmp r63 // terminate // XXX: align the epilogue? A single NOP would do it. // epilogue found: // Found a matching character, but there may also be a matching // zero. Check which one comes first (if both are in the same // place, we must have been looking for the 0). lsb1 r12, r14 // position of first matching byte lsb1 r13, r15 // position of first zero byte (if any) subi $16, r3, r18 // roll back pointer (it's 2 words ahead) shiftri $3, r14, r17 // offset of matching byte cmple r15, r14, r16 // match is valid if r14 <= r15 (or r15 == 0) add r17, r18, r1 // pointer to matching byte jmpz r15, r63 // return pointer if there was no matching 0 movez r16, r0, r1 // if terminating 0 came before the match jmp r63 For ultra-fast execution, we can define a variant that requires strict 8-byte alignment. We may also combine both versions (check the alignment at the start of the general routine, and branch to the slow version if it's not ok). The epilogue is the same, therefore I omit it here (the epilogue code may even be shared by both versions). The main loop also is the same, but I wanted to avoid the unnecessary loadaddr and jmp instructions required for jumping to the existing loop :) aligned_strchr: // prologue loadi $8, r1, r5 // load first data word sdup.b r2, r6 // duplicate character value loadaddri $found-.-4, r31 move r1, r3 // move pointer away move r0, r1 // preload NULL result // XXX: better align the main loop // (can be done by moving the entry point above) // main loop loopentry r30 xnor.and.b r6, r5, r12 // compare with character xnor.and.b r0, r5, r13 // compare with 0 loadi $8, r3, r5 // load next data word jmpnz r12, r31 // found character jmpz r13, r30 // loop unless a 0 occurred jmp r63 // terminate Guess what? This was fun! :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 11 15:48:41 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MPiA-0000Fr-00 for ; Thu, 12 Dec 2002 10:32:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 10:32:54 +0100 (CET) Received: (qmail 2327 invoked by uid 0); 11 Dec 2002 18:50:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 11 Dec 2002 18:50:39 -0000 Received: by moria.seul.org (Postfix) id 6D13933E72; Wed, 11 Dec 2002 13:50:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A0D4A33E74; Wed, 11 Dec 2002 13:50:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a210.home.uni-hannover.de [130.75.232.210]) by moria.seul.org (Postfix) with ESMTP id 9040533E72 for ; Wed, 11 Dec 2002 13:50:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00824; Wed, 11 Dec 2002 15:48:41 +0100 Message-ID: <20021211154841.35176@thrai.stud.uni-hannover.de> Date: Wed, 11 Dec 2002 15:48:41 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Relative branch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Dec 11, 2002 at 11:29:38AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 11, 2002 at 11:29:38AM +0100, devik wrote: > Just short idea, I was found that in compiled > code for fcpu is missing shorter/faster jump. > > Why dont we have jump which instead of registers > to use as return address save and target adres > have instead 12bit immediate which would REPLACE > lower 8 bits (for example) of IP. Umh. That will require heavy alignments, which may lead to increasing aliasing problems. And it's hard to handle inside the compiler and linker. You have to know in advance where the page boundaries are - that is, every object file will need 4k alignment. The resulting executable will contain lots of holes, and while the size of the executed code decreases, the file size will actually increase, resulting in more (and more frequent) memory loads which slow down execution. It's a waste of space and memory bandwidth, IMHO. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Dec 12 21:24:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MPiR-0000Fr-00 for ; Thu, 12 Dec 2002 10:33:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 10:33:11 +0100 (CET) Received: (qmail 10644 invoked by uid 0); 11 Dec 2002 20:46:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 11 Dec 2002 20:46:38 -0000 Received: by moria.seul.org (Postfix) id A852733C7C; Wed, 11 Dec 2002 15:46:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B4B3333C7F; Wed, 11 Dec 2002 15:46:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 1DEE833C7C for ; Wed, 11 Dec 2002 15:46:36 -0500 (EST) Received: from Biathlon (vlt9-41.n.club-internet.fr [195.36.223.41]) by relay-5v.club-internet.fr (Postfix) with SMTP id E18481FED for ; Wed, 11 Dec 2002 21:46:41 +0100 (CET) Date: Thu, 12 Dec 2002 21:24:30 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Taking decision on the project Message-Id: <20021212212430.43d651a0.nicolas.boulay@ifrance.com> In-Reply-To: References: <20021211202711.066d1b50.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 11 Dec 2002 11:23:21 +0100 (CET) devik wrote: > > It lack mutli-cpu support that's a big lack for a 2004 cpu ! (ll/sc > > are for mono cpu system !) > > I just read IA64 system manual, there are many MP issues discussed > along with examples ... Maybe it could help .. > > > Whygee propose to detect 2 alias maybe 3. Beside the fact that it > > will be a hudge piece of silicon, i beleive that's not acceptable > > for compiler. Finding all memory alias in C code will be such a > > mess ! Our recent Gcc expert could better said about that. > > hmm if it is about me, I'm not gcc expert ;-) But I have to say that > gcc marks some register as they contain non-aliased data (if it knows) > but for majority pointers gcc is "not sure". > There are aliasing data attached to each memory reference which > contains type and parent (structure) of datum. Unfortunately > when I tested with some code snippets, many pointers have simply > [0 S8 A64] alias set so that they can't be distinguished by gcc. > > > My proposal was to use the stream hint. That's what they are > > supposed to do : split memory stream, to avoid checking > > read-after-write memory hasard. If compiler didn't use them cleanly > > : shame on it :) That introduice 7 cache lines instead of 64, that's > > fewer but much easier to handle. > > hummm, what problem addresses these things ? Memory RAW ? In > UP environment these should not occur AFAIK because all caches > are controled by single CPU and cache lines should not be aliased. > For MP why don't use acquire/release semantic or at least memory > fence ? > > > But it didn't work any more for floating point unit. NAN, infinite > > must be implemented. Those execption came at the end of the pipeline > > of the unit. We could not hide latency any more. Each instruction > > must wait the complete end of the previous one. It will be so slow ! > > could not FPU store these flags into output register (or some attached > flag of it) and trap when the value is attempted to be used ? > > > Reordering buffer of today cpu are not a stupid bad dream of some > > engineer that smoke to much! It permit to do register bypass, > > is there ROB in IA64 !? From slides I remember there was not one. > They claimed that stop flags delimit insn group which can be > executed and make visible immediately ... > There is no ROB in IA64 but a system to refind where the trap come from and use specific instruction to refind where bad things happen. > > [2r1w->3r2w] > > Beside that there is "some choice" that i dislike in FC0. For > > example, the trick to be 3r2w by using 2r1w instructions. We use > > 3r1w register port but 90% of our instruction set are 2r1w (register > > access time between 2r1w and 3r2w is at least 30 % slower, at least > > ! that the difference between 2 Ghz and 1.4 Ghz cpu). And compiler > > risk to schedule only 32 registers. > > The only "problem" seems to be that "3r". I played with my little > emulator and most of the time (>50%) both 2w was used. So that one I beleive it was more :) > read port is unused most of the time. There are some insn which need > 3r and are useful like MUX or postincremented store (however I can > imagine it in imm form only - then it is 2r). > If MUX = (A andn M) or (B and M) it can be done with 3 insn with one > cycle stall (but compiler can use the cycle). If whole program > is made of 10% muxes if will slow it down by 20%. But if the CPU > will be 20% faster with 2r2w it is the same timing. > Next candidate is cstore - it reads condition, address and data. Well > someone wanted it to be dropped (MR?). On other hand (I know it is > crazy) if only z/nz would be implemented than there is no need for > the third read port. > Any other 3r insn waiting for comments ;-)) ? > There are must more problem with 2r instead of 1r, than between 2r or 3r. Imagine how such memory array look like ! > > (That's why i propose my "little vliw", 4r2w but with 2 instructions > > issue by cycle (or we could also used 2 separates register bank (and > > double the register number :) to have the 2r1w speed by instruction > > slot, so at least 1.3*2=2.6 the orginal speed). I don't think that > > introduice so much change to the manual.) > > it will introduce many stalls for common sequences like: > add > xor > ; here both add & xor writes the result ??? write in the same register ? > and what about 2w insns ? Some are very useful, add with carry, > multiply with hi part. Well both problems above could be solved Stop ! :) 64 decoder decode 64 bits insructions or 2*32 bits instructions. So 2 typical 2r1w instructions could be handle in the same time (in different register set ?). All actual 3r2w, 3r1w, 2r2w are mapped inside 4r2w 64 bits instructions world that access both register set. This 64 bits instruction could handle complexe instruction that could replace 3 or 4 32 bits instructions are at least reduice the RAW pipeline dependancies. That's how work oo engine : a <- b + a c <- d + a became a <- b + a c <- d + b + a For exemple. > by delay FFs and more clever scheduler - it could postpone > the second write of insn to next cycle. If compiler is aware of it, > it will schedule like: > mulh ; 6c latency > insn2 > insn3 > insn4 > mul > add1 ; mul wrt1 > add2 ; mul wrt2 > add3 ; add1 wrt > But for generic code there will be still many stalls probably. > You try to use 3r2w instructions on a 2r1w instruction set ? > > [.call mess] > > The last point i dislike is the hundred clock cycle needed to make a > > "typical" function call. The example given by Cedric was scaring ! I > > eh !? Speaking about register saves ? Hmm. I was hoping that > SRB will be really used to implement mstore/mload. It would > be nice to have prolog with one mstore and storing done in > background. mstore could be limited by OS to store up to > N registers at once to not kill interupt latency. N can be > different for desktop, server, RTOS ... I speak about lost clock cycle not number of instructions. Even with SRB, you loose clock cycles. With register windows you loose on trap only ! > > > I beleive more and more that using window register should > > be consider. That the compiler work to do the right job ! (maybe 24 > > rotating register + 40 fixe one, otherwise the window will be to > > small?). Sparc always reserve one windows for interrupt handling, so > > always 8 refresh registers are ready for it (no stack manipulation > > for simple handler, no complexe srb, no use of SR). > > hmm YG convinced me that spilling of rotating registers is hard > task and rotating itsels adds at least one pipeline stage. That is true. You add a 3 bits adder on the pipe. > Link time register allocation would do better in any case and > with mstore ... it could be even faster than rotating sets. mstore... Wich version ? Never forget that mstore use memory : >150 clock cycle in the worst case ! mstore for 4 register could be great. There is an easy way to do it but there is lot of constraint of alignement. We use a 4*sized register bank. 256->1024 bits so 4 registers are acceded in the same time, and you can fill a cache line in 1 clock cycle ! But it must be aligned to the cache line and register are packed by 4 !! There is some issue with SIMD/Scalar stuff resolved with a muxes. nicO > But ! SRM will probably need to be revided - for example why > to save ALL registers on interrupt ? I'd imagine to save > only small ammount of regs (4 f.ex.) by interrupt and if more > meeded then first insn in trap handler would be mstore to make > more room (IF needed). > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger > http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Dec 12 21:50:59 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MPiV-0000Fr-01 for ; Thu, 12 Dec 2002 10:33:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 10:33:15 +0100 (CET) Received: (qmail 18702 invoked by uid 0); 11 Dec 2002 21:13:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Dec 2002 21:13:06 -0000 Received: by moria.seul.org (Postfix) id 2474233C6E; Wed, 11 Dec 2002 16:13:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABBB733C82; Wed, 11 Dec 2002 16:13:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4AD4533C6E for ; Wed, 11 Dec 2002 16:13:04 -0500 (EST) Received: from Biathlon (vlt9-41.n.club-internet.fr [195.36.223.41]) by relay-4v.club-internet.fr (Postfix) with SMTP id 1512F2111 for ; Wed, 11 Dec 2002 22:13:02 +0100 (CET) Date: Thu, 12 Dec 2002 21:50:59 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Taking decision on the project Message-Id: <20021212215059.2c2d1f69.nicolas.boulay@ifrance.com> In-Reply-To: <20021212212430.43d651a0.nicolas.boulay@ifrance.com> References: <20021211202711.066d1b50.nicolas.boulay@ifrance.com> <20021212212430.43d651a0.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 12 Dec 2002 21:24:30 +0100 nico wrote: > On Wed, 11 Dec 2002 11:23:21 +0100 (CET) > devik wrote: > > > > It lack mutli-cpu support that's a big lack for a 2004 cpu ! > > > (ll/sc are for mono cpu system !) > > > > I just read IA64 system manual, there are many MP issues discussed > > along with examples ... Maybe it could help .. > > Yes. Certainly, as a begin. > > > Whygee propose to detect 2 alias maybe 3. Beside the fact that it > > > will be a hudge piece of silicon, i beleive that's not acceptable > > > for compiler. Finding all memory alias in C code will be such a > > > mess ! Our recent Gcc expert could better said about that. > > > > hmm if it is about me, I'm not gcc expert ;-) But I have to say that > > gcc marks some register as they contain non-aliased data (if it > > knows) but for majority pointers gcc is "not sure". That's not the problem of aliased data but aliased pointed data. Each register adresse are used as direct access to a memory, without really checking the true adress. If 2 registers hold 2 times the same adress, you will modify different memory buffer ! > > There are aliasing data attached to each memory reference which > > contains type and parent (structure) of datum. Unfortunately > > when I tested with some code snippets, many pointers have simply > > [0 S8 A64] alias set so that they can't be distinguished by gcc. > > > > > My proposal was to use the stream hint. That's what they are > > > supposed to do : split memory stream, to avoid checking > > > read-after-write memory hasard. If compiler didn't use them > > > cleanly: shame on it :) That introduice 7 cache lines instead of > > > 64, that's fewer but much easier to handle. > > > > hummm, what problem addresses these things ? Memory RAW ? In > > UP environment these should not occur AFAIK because all caches > > are controled by single CPU and cache lines should not be aliased. > > For MP why don't use acquire/release semantic or at least memory > > fence ? > > No No. That's Cray trick. Memory dependancies are the same problem as register one. But creating none coherent stream, a lot of optimising could be done (7 load&store unit :)). > > > But it didn't work any more for floating point unit. NAN, infinite > > > must be implemented. Those execption came at the end of the > > > pipeline of the unit. We could not hide latency any more. Each > > > instruction must wait the complete end of the previous one. It > > > will be so slow ! > > > > could not FPU store these flags into output register (or some > > attached flag of it) and trap when the value is attempted to be used > > ? > > > That's not the semantic of trap : roll-back on the faulty instructions. > > > > devik > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Dec 12 22:00:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MPiX-0000Fr-00 for ; Thu, 12 Dec 2002 10:33:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 10:33:17 +0100 (CET) Received: (qmail 28622 invoked by uid 0); 11 Dec 2002 21:23:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 11 Dec 2002 21:23:36 -0000 Received: by moria.seul.org (Postfix) id 1118333C90; Wed, 11 Dec 2002 16:23:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3201C33C99; Wed, 11 Dec 2002 16:23:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id CB06433E7B for ; Wed, 11 Dec 2002 16:22:47 -0500 (EST) Received: from Biathlon (vlt9-41.n.club-internet.fr [195.36.223.41]) by relay-2v.club-internet.fr (Postfix) with SMTP id E663D20A3 for ; Wed, 11 Dec 2002 22:22:35 +0100 (CET) Date: Thu, 12 Dec 2002 22:00:33 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Relative branch Message-Id: <20021212220033.4338645b.nicolas.boulay@ifrance.com> In-Reply-To: <20021211154841.35176@thrai.stud.uni-hannover.de> References: <20021211154841.35176@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 11 Dec 2002 15:48:41 +0100 Michael Riepe wrote: > On Wed, Dec 11, 2002 at 11:29:38AM +0100, devik wrote: > > Just short idea, I was found that in compiled > > code for fcpu is missing shorter/faster jump. > > > > Why dont we have jump which instead of registers > > to use as return address save and target adres > > have instead 12bit immediate which would REPLACE > > lower 8 bits (for example) of IP. > > Umh. That will require heavy alignments, which may lead to increasing > aliasing problems. And it's hard to handle inside the compiler and > linker. You have to know in advance where the page boundaries are - > that is, every object file will need 4k alignment. The resulting > executable will contain lots of holes, and while the size of the > executed code decreases, the file size will actually increase, > resulting in more (and more frequent) memory loads which slow down > execution. It's a waste of space and memory bandwidth, IMHO. Should be more investigate, no ? Because that could be a compiler choice ? In case of unconditionnal jump, it could be pretty fast ! > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 11 23:03:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MPid-0000Fr-00 for ; Thu, 12 Dec 2002 10:33:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 10:33:23 +0100 (CET) Received: (qmail 19943 invoked by uid 0); 11 Dec 2002 22:20:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 11 Dec 2002 22:20:32 -0000 Received: by moria.seul.org (Postfix) id E9C4833C88; Wed, 11 Dec 2002 17:20:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 54AC733CD8; Wed, 11 Dec 2002 17:20:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 86E9D33CC1 for ; Wed, 11 Dec 2002 17:20:29 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id AE2584F748 for ; Wed, 11 Dec 2002 16:18:58 -0600 (CST) Received: from a78-137.dialup.iol.cz ([194.228.137.78] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18MFCe-0007ww-00 for f-cpu@seul.org; Wed, 11 Dec 2002 23:19:46 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18MExG-0000Es-00 for f-cpu@seul.org; Wed, 11 Dec 2002 23:03:46 +0100 Date: Wed, 11 Dec 2002 23:03:46 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Relative branch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > huh ... because in FC0, the IP is "virtual". > there is no such register implemented in HW. ehh .. I didn't realized it yet :) > yup but jumping across pages are not possible. > And that behaviour would change depending on the page size yes. It was meand as short (near) jump only with regular jump for other cases. > >This would help small conditional branches, save > >code size and register usage ... >[...] > the goal is to spread the jump code, because it > is simply impossible to jump in a single cycle. hmm seems interesting. > Imagine that you have a cjump instruction with a new > address' LSB, you have to > - fetch the address (several cycles) I was thinking about near jumps where the code would be probably in cache already prefetched. Or by looking forward in instruction stream ? :-] Joking.. But yes, you are right at the moment. I hope to find time to finish both emulator and gcc, measure some cases and then it is the correct time to say: hey this or that instruction would improve speed by 20%, let's implement it ... regards, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From yannick_morvan@yahoo.fr Thu Dec 12 13:44:45 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MZnN-0006Ty-00 for ; Thu, 12 Dec 2002 21:18:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 21:18:57 +0100 (CET) Received: (qmail 782 invoked by uid 0); 12 Dec 2002 12:46:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 12 Dec 2002 12:46:17 -0000 Received: by moria.seul.org (Postfix) id E0E2B33C82; Thu, 12 Dec 2002 07:46:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 302EE33C93; Thu, 12 Dec 2002 07:46:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by moria.seul.org (Postfix) with SMTP id 4A54133C82 for ; Thu, 12 Dec 2002 07:46:15 -0500 (EST) Received: from abrest-103-1-3-192.abo.wanadoo.fr (HELO quimper) (yannick?morvan@217.128.158.192 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Dec 2002 12:46:13 -0000 Message-ID: <001801c2a1dc$6466f020$0a00a8c0@quimper> From: "yannick" To: "free-cpu" Subject: [f-cpu] new student contributors Date: Thu, 12 Dec 2002 13:44:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello people, We are 3 students in a French engineering school. We study electronics and are interested in the Free-cpu project. We've got a little project (1 month) and could participate to f-cpu. We all worked on the design of an uart for a board based on a fpga. First, I'm going to motivate my supervisor in the university and if he is agree we will start to study the manual. I'm very interested in vhdl and ic design that's why I want to contribute to this project. Yannick ps: I'm looking for an internship in Europe in the field of IC design, any advice are welcome ;-) http://ymorvan.free.fr/mon_cv_en.pdf ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@club-internet.fr Thu Dec 12 19:04:17 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MZnm-0006Ty-01 for ; Thu, 12 Dec 2002 21:19:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 21:19:22 +0100 (CET) Received: (qmail 24736 invoked by uid 0); 12 Dec 2002 14:04:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 12 Dec 2002 14:04:50 -0000 Received: by moria.seul.org (Postfix) id 3B9AF33C9F; Thu, 12 Dec 2002 09:04:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C67C33CA1; Thu, 12 Dec 2002 09:04:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 132DD33C9F for ; Thu, 12 Dec 2002 09:04:48 -0500 (EST) Received: from club-internet.fr (flashmail-5v.cs.clubint.net [172.16.0.156]) by relay-5v.club-internet.fr (Postfix) with SMTP id 60F8F2203 for ; Thu, 12 Dec 2002 15:04:26 +0100 (CET) Received: from [//62.212.107.173] by flashmail-v.club-internet.fr via html interface; From: whygee@club-internet.fr To: f-cpu@seul.org Subject: Re: [f-cpu] new student contributors Date: Thu, 12 Dec 2002 15:04:17 CET Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi =21 >De: =22yannick=22 > >Hello people, > >We are 3 students in a French engineering school. We study electronics an= d >are interested in the Free-cpu project. FreeDOM CPU Project, damnit =21 :-P >Yannick YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Dec 13 21:06:24 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Mazr-0007Uk-01 for ; Thu, 12 Dec 2002 22:35:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 12 Dec 2002 22:35:55 +0100 (CET) Received: (qmail 15843 invoked by uid 0); 12 Dec 2002 20:28:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx036-rz3) with SMTP; 12 Dec 2002 20:28:28 -0000 Received: by moria.seul.org (Postfix) id 3971E33CC7; Thu, 12 Dec 2002 15:28:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9145E33DE5; Thu, 12 Dec 2002 15:28:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 28BA133CC7 for ; Thu, 12 Dec 2002 15:28:26 -0500 (EST) Received: from Biathlon (lcbv1-3-150.n.club-internet.fr [213.44.21.150]) by relay-5v.club-internet.fr (Postfix) with SMTP id 6D95E2332 for ; Thu, 12 Dec 2002 21:28:33 +0100 (CET) Date: Fri, 13 Dec 2002 21:06:24 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new student contributors Message-Id: <20021213210624.18e2f176.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N It seems that CCC want to control much more the hack center entrance. We must register to access it. We must give a number of people, we are 3 this year, no ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Dec 12 23:26:18 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18McjB-0000JQ-01 for ; Fri, 13 Dec 2002 00:26:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 00:26:49 +0100 (CET) Received: (qmail 3464 invoked by uid 0); 12 Dec 2002 22:27:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 12 Dec 2002 22:27:52 -0000 Received: by moria.seul.org (Postfix) id 5A94833CF1; Thu, 12 Dec 2002 17:27:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 660EE33CF6; Thu, 12 Dec 2002 17:27:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id C556633CF1 for ; Thu, 12 Dec 2002 17:27:49 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 2FCE84F7FD for ; Thu, 12 Dec 2002 16:26:15 -0600 (CST) Received: from a44-137.dialup.iol.cz ([194.228.137.44] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18MbnS-0002d0-00 for f-cpu@seul.org; Thu, 12 Dec 2002 23:27:15 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Mbmd-00057A-00 for f-cpu@seul.org; Thu, 12 Dec 2002 23:26:19 +0100 Date: Thu, 12 Dec 2002 23:26:18 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] vsprintf result for GCC & FCPU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I finnaly compiled vsprintf.c from Linux sources. There are still bugs but some stats: It is 3696 bytes of code for Intel Pentium. It is 5980 bytes for F-CPU. There is still many things to be fixed but you have approximate idea at least. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Dec 13 23:14:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18McjE-0000JQ-00 for ; Fri, 13 Dec 2002 00:26:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 00:26:52 +0100 (CET) Received: (qmail 2699 invoked by uid 0); 12 Dec 2002 22:36:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 12 Dec 2002 22:36:53 -0000 Received: by moria.seul.org (Postfix) id 73C1D33CF3; Thu, 12 Dec 2002 17:36:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 84E1433CF6; Thu, 12 Dec 2002 17:36:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 8F4D833CF3 for ; Thu, 12 Dec 2002 17:36:49 -0500 (EST) Received: from Biathlon (lcbv2-1-168.n.club-internet.fr [213.44.12.168]) by relay-1v.club-internet.fr (Postfix) with SMTP id C15D216BD for ; Thu, 12 Dec 2002 23:36:22 +0100 (CET) Date: Fri, 13 Dec 2002 23:14:46 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU Message-Id: <20021213231446.1f7b3b7f.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 12 Dec 2002 23:26:18 +0100 (CET) devik wrote: > I finnaly compiled vsprintf.c from Linux sources. > There are still bugs but some stats: > > It is 3696 bytes of code for Intel Pentium. > It is 5980 bytes for F-CPU. > Is that the result of the file size or the result of strip vsprintf size vsprintf ? Wich is more precise. nicO > There is still many things to be fixed but you > have approximate idea at least. > devik > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Dec 13 23:15:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18McjE-0000JQ-01 for ; Fri, 13 Dec 2002 00:26:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 00:26:52 +0100 (CET) Received: (qmail 5711 invoked by uid 0); 12 Dec 2002 22:37:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 12 Dec 2002 22:37:36 -0000 Received: by moria.seul.org (Postfix) id 3330133CF5; Thu, 12 Dec 2002 17:37:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DFAF833CF9; Thu, 12 Dec 2002 17:37:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7288133CF5 for ; Thu, 12 Dec 2002 17:37:29 -0500 (EST) Received: from Biathlon (lcbv2-1-168.n.club-internet.fr [213.44.12.168]) by relay-1v.club-internet.fr (Postfix) with SMTP id B035316BD for ; Thu, 12 Dec 2002 23:37:03 +0100 (CET) Date: Fri, 13 Dec 2002 23:15:27 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU Message-Id: <20021213231527.0909b12f.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Did you use SIMD stuff in you're code ? nicO On Thu, 12 Dec 2002 23:26:18 +0100 (CET) devik wrote: > I finnaly compiled vsprintf.c from Linux sources. > There are still bugs but some stats: > > It is 3696 bytes of code for Intel Pentium. > It is 5980 bytes for F-CPU. > > There is still many things to be fixed but you > have approximate idea at least. > devik > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 12 14:56:20 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18McjI-0000JQ-01 for ; Fri, 13 Dec 2002 00:26:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 00:26:56 +0100 (CET) Received: (qmail 9034 invoked by uid 0); 12 Dec 2002 23:06:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 12 Dec 2002 23:06:03 -0000 Received: by moria.seul.org (Postfix) id D90BB33CBC; Thu, 12 Dec 2002 18:06:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4F30E33CC1; Thu, 12 Dec 2002 18:06:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a163.home.uni-hannover.de [130.75.232.163]) by moria.seul.org (Postfix) with ESMTP id 82C5E33CBC for ; Thu, 12 Dec 2002 18:06:00 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00504; Thu, 12 Dec 2002 14:56:21 +0100 Message-ID: <20021212145620.28829@thrai.stud.uni-hannover.de> Date: Thu, 12 Dec 2002 14:56:20 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new student contributors References: <001801c2a1dc$6466f020$0a00a8c0@quimper> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001801c2a1dc$6466f020$0a00a8c0@quimper>; from yannick on Thu, Dec 12, 2002 at 01:44:45PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 12, 2002 at 01:44:45PM +0100, yannick wrote: > We are 3 students in a French engineering school. We study electronics and > are interested in the Free-cpu project. Welcome to the chaos^H^H^H^H^Hlist. ;) > We've got a little project (1 month) and could participate to f-cpu. > We all worked on the design of an uart for a board based on a fpga. > First, I'm going to motivate my supervisor in the university and if he is > agree we will start to study the manual. You'd better study the code ;) > I'm very interested in vhdl and ic design that's why I want to contribute to > this project. Finally, another HW guy! Maybe that helps us keep the balance :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 13 00:08:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Mcpl-0000Ki-01 for ; Fri, 13 Dec 2002 00:33:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 00:33:37 +0100 (CET) Received: (qmail 14422 invoked by uid 0); 12 Dec 2002 23:08:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 12 Dec 2002 23:08:30 -0000 Received: by moria.seul.org (Postfix) id 8176133CBD; Thu, 12 Dec 2002 18:08:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E5CC33CC2; Thu, 12 Dec 2002 18:08:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D2A8333CBD for ; Thu, 12 Dec 2002 18:08:23 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 12CE74F7CB for ; Thu, 12 Dec 2002 17:06:52 -0600 (CST) Received: from a44-137.dialup.iol.cz ([194.228.137.44] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18McRJ-0002lM-00 for f-cpu@seul.org; Fri, 13 Dec 2002 00:08:22 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18McRD-0005Gs-00 for f-cpu@seul.org; Fri, 13 Dec 2002 00:08:15 +0100 Date: Fri, 13 Dec 2002 00:08:15 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU In-Reply-To: <20021213231446.1f7b3b7f.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > > It is 3696 bytes of code for Intel Pentium. > > It is 5980 bytes for F-CPU. > > > > Is that the result of the file size or the result of > > strip vsprintf > size vsprintf No I have no assembler here. I counted instructions in generated .s file section .text and multiply by 4. SIMD was not used too much (gcc can't). But I'll make the backend better so we will see some savings. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 13 01:31:42 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MuLe-0002l9-01 for ; Fri, 13 Dec 2002 19:15:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 19:15:42 +0100 (CET) Received: (qmail 16995 invoked by uid 0); 13 Dec 2002 12:56:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 13 Dec 2002 12:56:27 -0000 Received: by moria.seul.org (Postfix) id 7350733CD4; Fri, 13 Dec 2002 07:56:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA9C033CDA; Fri, 13 Dec 2002 07:56:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a154.home.uni-hannover.de [130.75.232.154]) by moria.seul.org (Postfix) with ESMTP id D771233CD4 for ; Fri, 13 Dec 2002 07:56:23 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02585; Fri, 13 Dec 2002 01:31:42 +0100 Message-ID: <20021213013142.40306@thrai.stud.uni-hannover.de> Date: Fri, 13 Dec 2002 01:31:42 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Dec 12, 2002 at 11:26:18PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 12, 2002 at 11:26:18PM +0100, devik wrote: > I finnaly compiled vsprintf.c from Linux sources. > There are still bugs but some stats: > > It is 3696 bytes of code for Intel Pentium. > It is 5980 bytes for F-CPU. Not too bad, I guess. With or without -O? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 13 14:29:38 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MuLk-0002l9-00 for ; Fri, 13 Dec 2002 19:15:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 19:15:48 +0100 (CET) Received: (qmail 21627 invoked by uid 0); 13 Dec 2002 14:06:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 13 Dec 2002 14:06:51 -0000 Received: by moria.seul.org (Postfix) id D258233C98; Fri, 13 Dec 2002 09:06:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6A17933CDE; Fri, 13 Dec 2002 09:06:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 0BF3B33C98 for ; Fri, 13 Dec 2002 09:06:50 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 33B6E4F825 for ; Fri, 13 Dec 2002 08:05:17 -0600 (CST) Received: from a92-137.dialup.iol.cz ([194.228.137.92] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18MqSZ-0004W4-00 for f-cpu@seul.org; Fri, 13 Dec 2002 15:06:35 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Mpso-0000AO-00 for f-cpu@seul.org; Fri, 13 Dec 2002 14:29:38 +0100 Date: Fri, 13 Dec 2002 14:29:38 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU In-Reply-To: <20021213013142.40306@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > I finnaly compiled vsprintf.c from Linux sources. > > There are still bugs but some stats: > > > > It is 3696 bytes of code for Intel Pentium. > > It is 5980 bytes for F-CPU. > > Not too bad, I guess. With or without -O? Both with -O2... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Fri Dec 13 18:30:58 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18MuM1-0002l9-00 for ; Fri, 13 Dec 2002 19:16:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 13 Dec 2002 19:16:05 +0100 (CET) Received: (qmail 11812 invoked by uid 0); 13 Dec 2002 17:36:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 13 Dec 2002 17:36:01 -0000 Received: by moria.seul.org (Postfix) id C585133CE8; Fri, 13 Dec 2002 12:35:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7343633CEE; Fri, 13 Dec 2002 12:35:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id A92BC33CE8 for ; Fri, 13 Dec 2002 12:35:56 -0500 (EST) Received: from homeworld (81.48.95.123) by smtp.laposte.net (6.0.053) id 3DF9286C0001A3CB for f-cpu@seul.org; Fri, 13 Dec 2002 18:35:48 +0100 Message-ID: <001001c2a2cd$6963f8b0$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU Date: Fri, 13 Dec 2002 18:30:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N try with -Os ----- Original Message ----- From: "devik" To: Sent: Friday, December 13, 2002 2:29 PM Subject: Re: [f-cpu] vsprintf result for GCC & FCPU > > > I finnaly compiled vsprintf.c from Linux sources. > > > There are still bugs but some stats: > > > > > > It is 3696 bytes of code for Intel Pentium. > > > It is 5980 bytes for F-CPU. > > > > Not too bad, I guess. With or without -O? > > Both with -O2... > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Dec 13 21:48:54 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18NCb6-0006VL-00 for ; Sat, 14 Dec 2002 14:44:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Dec 2002 14:44:52 +0100 (CET) Received: (qmail 13461 invoked by uid 0); 13 Dec 2002 20:35:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 13 Dec 2002 20:35:27 -0000 Received: by moria.seul.org (Postfix) id B60AB33CF8; Fri, 13 Dec 2002 15:35:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0BABF33D06; Fri, 13 Dec 2002 15:35:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A2BBA33CF8 for ; Fri, 13 Dec 2002 15:35:23 -0500 (EST) Received: from f-cpu.org (lcbv5-1-85.n.club-internet.fr [213.44.18.85]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D4DBD2F12 for ; Fri, 13 Dec 2002 21:34:21 +0100 (CET) Message-ID: <3DFA47B6.6040008@f-cpu.org> Date: Fri, 13 Dec 2002 21:48:54 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new student contributors References: <20021213210624.18e2f176.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! nico wrote: >It seems that CCC want to control much more the hack center entrance. We >must register to access it. > >We must give a number of people, we are 3 this year, no ? > > seems so. I have sent a request to CCC through their web form, asking for 3 places (you, cedric and me). >nicO > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Dec 15 14:37:25 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Nhxn-0003CG-01 for ; Mon, 16 Dec 2002 00:14:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 00:14:23 +0100 (CET) Received: (qmail 18664 invoked by uid 0); 15 Dec 2002 21:51:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 15 Dec 2002 21:51:12 -0000 Received: by moria.seul.org (Postfix) id 09F6A33D43; Sun, 15 Dec 2002 16:51:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 79E2033D46; Sun, 15 Dec 2002 16:51:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id D991733D43 for ; Sun, 15 Dec 2002 16:51:10 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by belegost.mit.edu (8.11.6/8.11.6) with ESMTP id gBFLp9l21292 for ; Sun, 15 Dec 2002 16:51:10 -0500 Received: from a39-137.dialup.iol.cz ([194.228.137.39] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Ngbz-0001A4-00 for f-cpu@seul.org; Sun, 15 Dec 2002 22:47:48 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18NYxR-0000GI-00 for f-cpu@seul.org; Sun, 15 Dec 2002 14:37:25 +0100 Date: Sun, 15 Dec 2002 14:37:25 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU In-Reply-To: <001001c2a2cd$6963f8b0$0100000a@homeworld> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I did added other optimizations meanwhile so it dropped to 5272 with -O and 4888 with -Os. On Fri, 13 Dec 2002, Christophe Avoinne wrote: > try with -Os > > ----- Original Message ----- > From: "devik" > To: > Sent: Friday, December 13, 2002 2:29 PM > Subject: Re: [f-cpu] vsprintf result for GCC & FCPU > > > > > > I finnaly compiled vsprintf.c from Linux sources. > > > > There are still bugs but some stats: > > > > > > > > It is 3696 bytes of code for Intel Pentium. > > > > It is 5980 bytes for F-CPU. > > > > > > Not too bad, I guess. With or without -O? > > > > Both with -O2... > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sun Dec 15 23:37:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Nhxw-0003CG-00 for ; Mon, 16 Dec 2002 00:14:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 00:14:32 +0100 (CET) Received: (qmail 23482 invoked by uid 0); 15 Dec 2002 22:42:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 15 Dec 2002 22:42:44 -0000 Received: by moria.seul.org (Postfix) id 1D2A133C9D; Sun, 15 Dec 2002 17:42:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7136233D46; Sun, 15 Dec 2002 17:42:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (imap.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 9028933C9D for ; Sun, 15 Dec 2002 17:42:41 -0500 (EST) Received: from homeworld (81.48.95.164) by smtp.laposte.net (6.0.053) id 3DF9286C0004B163 for f-cpu@seul.org; Sun, 15 Dec 2002 23:42:40 +0100 Message-ID: <03c501c2a48a$96e3aa60$0100000a@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU Date: Sun, 15 Dec 2002 23:37:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N So it seems that option -Os has more inpact on f-cpu than intel architecture. ----- Original Message ----- From: "devik" To: Sent: Sunday, December 15, 2002 2:37 PM Subject: Re: [f-cpu] vsprintf result for GCC & FCPU > I did added other optimizations meanwhile so it > dropped to 5272 with -O and 4888 with -Os. > > On Fri, 13 Dec 2002, Christophe Avoinne wrote: > > > try with -Os > > > > ----- Original Message ----- > > From: "devik" > > To: > > Sent: Friday, December 13, 2002 2:29 PM > > Subject: Re: [f-cpu] vsprintf result for GCC & FCPU > > > > > > > > > I finnaly compiled vsprintf.c from Linux sources. > > > > > There are still bugs but some stats: > > > > > > > > > > It is 3696 bytes of code for Intel Pentium. > > > > > It is 5980 bytes for F-CPU. > > > > > > > > Not too bad, I guess. With or without -O? > > > > > > Both with -O2... > > > > > > ************************************************************* > > > To unsubscribe, send an e-mail to majordomo@seul.org with > > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Dec 16 00:26:22 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18NmDV-0006Mf-00 for ; Mon, 16 Dec 2002 04:46:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 04:46:53 +0100 (CET) Received: (qmail 17675 invoked by uid 0); 15 Dec 2002 23:16:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 15 Dec 2002 23:16:27 -0000 Received: by moria.seul.org (Postfix) id 7CF8433C8A; Sun, 15 Dec 2002 18:16:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D7ABA33D46; Sun, 15 Dec 2002 18:16:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 27A7533C8A for ; Sun, 15 Dec 2002 18:16:25 -0500 (EST) Received: from f-cpu.org (lcbv2-1-40.n.club-internet.fr [213.44.12.40]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 03EB92154 for ; Mon, 16 Dec 2002 00:12:08 +0100 (CET) Message-ID: <3DFD0F9E.40805@f-cpu.org> Date: Mon, 16 Dec 2002 00:26:22 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: <03c501c2a48a$96e3aa60$0100000a@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Christophe Avoinne wrote: >So it seems that option -Os has more inpact on f-cpu than intel >architecture. > And there is still some margin :-P >>I did added other optimizations meanwhile so it >>dropped to 5272 with -O and 4888 with -Os. >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 00:54:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18NmDd-0006Mf-00 for ; Mon, 16 Dec 2002 04:47:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 04:47:01 +0100 (CET) Received: (qmail 5288 invoked by uid 0); 15 Dec 2002 23:56:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 15 Dec 2002 23:56:09 -0000 Received: by moria.seul.org (Postfix) id 7CEF633D44; Sun, 15 Dec 2002 18:56:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 017BE33D47; Sun, 15 Dec 2002 18:56:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a036.home.uni-hannover.de [130.75.232.36]) by moria.seul.org (Postfix) with ESMTP id D6FDC33D44 for ; Sun, 15 Dec 2002 18:56:05 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02778; Mon, 16 Dec 2002 00:54:16 +0100 Message-ID: <20021216005415.14662@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 00:54:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: <03c501c2a48a$96e3aa60$0100000a@homeworld> <3DFD0F9E.40805@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3DFD0F9E.40805@f-cpu.org>; from Yann Guidon on Mon, Dec 16, 2002 at 12:26:22AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 16, 2002 at 12:26:22AM +0100, Yann Guidon wrote: > hi ! > > Christophe Avoinne wrote: > > >So it seems that option -Os has more inpact on f-cpu than intel > >architecture. > > > And there is still some margin :-P > > >>I did added other optimizations meanwhile so it > >>dropped to 5272 with -O and 4888 with -Os. Too bad that we can't run the code and see whether it really works :( At least, not today... but maybe by the end of the year. I have already built a tiny disassembler (similar to ndisasm, but less powerful) and an instruction-level emulator with built-in mini debugger that support most of the currently defined instructions (but sometimes differ from the documentation - I'll take care of that later, probably by submitting changes to the manual :). I'll have to do some `real' (that is, paid :) work this week, but maybe I'll also find the time to modify/extend my assembler's backend to write plain binary output files (the emulator doesn't grok ELF yet). In that case, you may get a new toy for Xmas - or rather, a collection of toys ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Dec 16 10:25:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Nz0w-0007H9-00 for ; Mon, 16 Dec 2002 18:26:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 18:26:46 +0100 (CET) Received: (qmail 14057 invoked by uid 0); 16 Dec 2002 11:11:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 16 Dec 2002 11:11:59 -0000 Received: by moria.seul.org (Postfix) id 1CA0C33D48; Mon, 16 Dec 2002 06:11:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1C1833D4E; Mon, 16 Dec 2002 06:11:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 246FB33D48 for ; Mon, 16 Dec 2002 06:11:57 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 075B34F825 for ; Mon, 16 Dec 2002 05:12:04 -0600 (CST) Received: from a117-137.dialup.iol.cz ([194.228.137.117] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18NtA4-0002uc-00 for f-cpu@seul.org; Mon, 16 Dec 2002 12:11:49 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18NrV3-0000BI-00 for f-cpu@seul.org; Mon, 16 Dec 2002 10:25:21 +0100 Date: Mon, 16 Dec 2002 10:25:21 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU In-Reply-To: <20021216005415.14662@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Too bad that we can't run the code and see whether it really works :( > At least, not today... but maybe by the end of the year. I have already > built a tiny disassembler (similar to ndisasm, but less powerful) and > an instruction-level emulator with built-in mini debugger that support :-) The code should work but you have to define macros for jumps. The code is not still able to handle loadaddr and jumps. Also there is still lack of conditional move - it is one which should reduce code size further. But the only simulation showstopper is the lack of loadaddr (emits loadcons instead) - but it should be simple to repair. But as you - I have to many 'real' work at this time. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Dec 16 10:41:00 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Nz0x-0007H9-00 for ; Mon, 16 Dec 2002 18:26:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Dec 2002 18:26:47 +0100 (CET) Received: (qmail 32166 invoked by uid 0); 16 Dec 2002 11:12:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 16 Dec 2002 11:12:03 -0000 Received: by moria.seul.org (Postfix) id 29A7D33D4D; Mon, 16 Dec 2002 06:12:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8894A33D51; Mon, 16 Dec 2002 06:12:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 6E1BC33D4E for ; Mon, 16 Dec 2002 06:12:00 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 40AF64F82B for ; Mon, 16 Dec 2002 05:12:07 -0600 (CST) Received: from a117-137.dialup.iol.cz ([194.228.137.117] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18NtA1-0002uc-00 for f-cpu@seul.org; Mon, 16 Dec 2002 12:11:46 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18NrkC-0000Bc-00 for f-cpu@seul.org; Mon, 16 Dec 2002 10:41:00 +0100 Date: Mon, 16 Dec 2002 10:41:00 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] signed cmpl Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, when I was adding conditionals into gcc code I found that signed compare is often used by gcc backend (more than unsigned one for most of code). IMHO the signed compare can be (even for SIMD) done as: xor.N a0,a1,t0 // get sign difference cmpl[e].N a0,a1,t1 // unsigned compare shiftari.N N-1,t0,t0 // convert MSB bit to negation mask // free slot here xor.N t0,t1,t0 // negate result for different signs it is 6 cycle latency! Can some HW guy here tell whether can I count on signed cmp being computed by INC unit too ? It would be one xor gate in its critical path AFAIK (negate result if sign bits were different). It it would not fit into INC unit I'd suggest to implement signed compare instead of unsigned - it is more often used and 32 bit unsigned cmp can be then done by zero_extending operands (it is at no cost in fcpu) and perform 64 bit signed cmp instead. The resulting 0xfff... pattern will be twice long but for subsequent jmp it doesn't matter. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 15:20:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P0gV-0000JE-01 for ; Thu, 19 Dec 2002 14:25:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 14:25:55 +0100 (CET) Received: (qmail 29914 invoked by uid 0); 16 Dec 2002 18:07:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 16 Dec 2002 18:07:30 -0000 Received: by moria.seul.org (Postfix) id 0875833D58; Mon, 16 Dec 2002 13:07:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 865FC33D5D; Mon, 16 Dec 2002 13:07:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a176.home.uni-hannover.de [130.75.232.176]) by moria.seul.org (Postfix) with ESMTP id 9440033D58 for ; Mon, 16 Dec 2002 13:07:27 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00718; Mon, 16 Dec 2002 15:20:30 +0100 Message-ID: <20021216152030.54203@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 15:20:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: <20021216005415.14662@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Dec 16, 2002 at 10:25:21AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 16, 2002 at 10:25:21AM +0100, devik wrote: > > Too bad that we can't run the code and see whether it really works :( > > At least, not today... but maybe by the end of the year. I have already > > built a tiny disassembler (similar to ndisasm, but less powerful) and > > an instruction-level emulator with built-in mini debugger that support > > :-) The code should work but you have to define macros for > jumps. The code is not still able to handle loadaddr and > jumps. Also there is still lack of conditional move - it > is one which should reduce code size further. What kind of macros? > But the only simulation showstopper is the lack of loadaddr > (emits loadcons instead) - but it should be simple to repair. My emulator doesn't care about these low-level details - it happily jumps to addresses generated by loadcons[x]. > But as you - I have to many 'real' work at this time. When you finally find the time, can you please change the assembler syntax a little? First, immediate operands should be prefixed with a `$' character (that is, in real instructions, not in .pseudo ops) - that way it's possible to make a difference between symbolic constants and register names (just consider a symbol named `r0') without looking at the opcode. Second, please change the register names to r0...r63. There are no designated argument or temporary registers, stack or frame pointers. Besides that, it's not wise to reflect the calling conventions in the register names, and IMHO it's also harder to read. Once you're done with that, my assembler should be able to process the assembler source files generated by your gcc port. Since I also have ar, mcs, nm, size, strings and strip utilities floating around on my disk, we would have an almost complete, working f-cpu toolchain (only ld is still missing). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 14:45:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P0gW-0000JE-00 for ; Thu, 19 Dec 2002 14:25:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 14:25:56 +0100 (CET) Received: (qmail 32199 invoked by uid 0); 16 Dec 2002 18:07:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 16 Dec 2002 18:07:41 -0000 Received: by moria.seul.org (Postfix) id 1FB5E33D5E; Mon, 16 Dec 2002 13:07:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F041B33D5F; Mon, 16 Dec 2002 13:07:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a176.home.uni-hannover.de [130.75.232.176]) by moria.seul.org (Postfix) with ESMTP id CAC4633D5E for ; Mon, 16 Dec 2002 13:07:29 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00625; Mon, 16 Dec 2002 14:45:22 +0100 Message-ID: <20021216144521.42564@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 14:45:21 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Dec 16, 2002 at 10:41:00AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 16, 2002 at 10:41:00AM +0100, devik wrote: > Hi, > > when I was adding conditionals into gcc code I found > that signed compare is often used by gcc backend > (more than unsigned one for most of code). > > IMHO the signed compare can be (even for SIMD) done as: > > xor.N a0,a1,t0 // get sign difference > cmpl[e].N a0,a1,t1 // unsigned compare > shiftari.N N-1,t0,t0 // convert MSB bit to negation mask > // free slot here > xor.N t0,t1,t0 // negate result for different signs > it is 6 cycle latency! Can some HW guy here tell whether can > I count on signed cmp being computed by INC unit too ? It > would be one xor gate in its critical path AFAIK (negate > result if sign bits were different). My version would be: [s]bchg.N N-1, a0, t0 // change sign(s) [s]bchg.N N-1, a1, t1 // change sign(s) // free slot [s]cmpl[e].N t0, t1, t0 // unsigned compare but that's hardly faster. However, it's easy to realize in hardware: The unsigned cmpl is equivalent to y = (first_bit(a ^ b) & b) ? -1 : 0 and its signed counterpart will be y = (first_bit(a ^ b) & change_sign(b)) ? -1 : 0 which also needs a single XOR per chunk - but that's located *outside* the critical datapath, because first_bit() takes more time than a single XOR. Of course there will be both signed and unsigned integer compare instructions (and also min/max/sort). Projected names for the signed counterparts are cmpls, cmples, mins, maxs and minmaxs (aka sorts). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 23:03:08 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6RT-00048Q-00 for ; Thu, 19 Dec 2002 20:34:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:34:47 +0100 (CET) Received: (qmail 11496 invoked by uid 0); 16 Dec 2002 23:17:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 16 Dec 2002 23:17:27 -0000 Received: by moria.seul.org (Postfix) id B5F2733D54; Mon, 16 Dec 2002 18:17:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1776D33D59; Mon, 16 Dec 2002 18:17:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a174.home.uni-hannover.de [130.75.232.174]) by moria.seul.org (Postfix) with ESMTP id 2A92233D54 for ; Mon, 16 Dec 2002 18:17:24 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA02314; Mon, 16 Dec 2002 23:03:09 +0100 Message-ID: <20021216230308.55776@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 23:03:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: <20021216144521.42564@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20021216144521.42564@thrai.stud.uni-hannover.de>; from Michael Riepe on Mon, Dec 16, 2002 at 02:45:21PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N One more remark... > Of course there will be both signed and unsigned integer compare > instructions (and also min/max/sort). Projected names for the signed > counterparts are cmpls, cmples, mins, maxs and minmaxs (aka sorts). Today I noticed that the current instruction set is slightly insufficient: we cannot perform the `register > constant' or `register >= constant' operations with a single instruction. On the other hand, `cmpli' and `cmplei' are widely equivalent, except for `cmpli $0, r2, r1' and `cmplei $255, r2, r1' which have no corresponding instruction. Therefore, we should implement a different pair of compare instructions. I guess the best alternative is `cmpg' and `cmple'. We may also provide all of them (cmp[lg] and cmp[lg]e) with little additional hardware (and without latency increasing) - an extra row of MUXes in an uncritical place will do the trick. In either case, all four `reg x reg -> reg' instructions will be available as assembler aliases, whether or not they're implemented in hardware. The `reg x imm -> reg' instructions can also be mapped to each other if we don't provide the full set, but the argument ranges will be slightly different (like 1...256, or -127...128 for signed operations). But whatever we do, we should provide immediate compare instructions with both a `less' and a `greater' (-or-equal) condition. Comments? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Dec 17 09:38:53 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Ru-00048Q-01 for ; Thu, 19 Dec 2002 20:35:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:35:14 +0100 (CET) Received: (qmail 15365 invoked by uid 0); 17 Dec 2002 08:39:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 17 Dec 2002 08:39:11 -0000 Received: by moria.seul.org (Postfix) id 8486A33CD0; Tue, 17 Dec 2002 03:39:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0261633D04; Tue, 17 Dec 2002 03:39:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id AFFEB33CD0 for ; Tue, 17 Dec 2002 03:39:08 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212170838.353f; Tue, 17 Dec 2002 08:38:53 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] signed cmpl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Dec 2002 08:38:53 GMT Message-id: <200212170838.353f@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N There some imm instruction using 8 or 16 bits. I had proposed a long time ago, to use the 6 bits register a= dresse field to create an immediat adressing mode available for every ins= tructions. Maybe this could solve your problem. nicO -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 17/12/02 Objet: Re: [f-cpu] signed cmpl One more remark... > Of course there will be both signed and unsigned integer c= ompare > instructions (and also min/max/sort). Projected names for = the signed > counterparts are cmpls, cmples, mins, maxs and minmaxs (ak= a sorts). Today I noticed that the current instruction set is slightly insufficient: we cannot perform the `register > constant' or `register >=3D= constant' operations with a single instruction. On the other hand, `cm= pli' and `cmplei' are widely equivalent, except for `cmpli $0, r2= , r1' and `cmplei $255, r2, r1' which have no corresponding instructio= n. Therefore, we should implement a different pair of compare instructions= . I guess the best alternative is `cmpg' and `cmple'. We may also prov= ide all of them (cmp[lg] and cmp[lg]e) with little additional hardware = (and without latency increasing) - an extra row of MUXes in an uncritical= place will do the trick. In either case, all four `reg x reg -> reg' instructions wil= l be available as assembler aliases, whether or not they're implemented in = hardware. The `reg x imm -> reg' instructions can also be mapped to each o= ther if we don't provide the full set, but the argument ranges will be = slightly different (like 1...256, or -127...128 for signed operations= ). But whatever we do, we should provide immediate compare instruct= ions with both a `less' and a `greater' (-or-equal) condition. Comments? --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Dec 17 20:17:48 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6TG-00048Q-01 for ; Thu, 19 Dec 2002 20:36:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:36:38 +0100 (CET) Received: (qmail 4677 invoked by uid 0); 17 Dec 2002 19:19:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 17 Dec 2002 19:19:54 -0000 Received: by moria.seul.org (Postfix) id 4A82633C98; Tue, 17 Dec 2002 14:19:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 94D3933C9F; Tue, 17 Dec 2002 14:19:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id AF0F633C98 for ; Tue, 17 Dec 2002 14:19:51 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-198.jetnet.ab.ca [207.34.60.198]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id gBHJMbHL053207 for ; Tue, 17 Dec 2002 12:22:38 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3DFF785C.70607@jetnet.ab.ca> Date: Tue, 17 Dec 2002 12:17:48 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] signed cmpl References: <200212170838.353f@th00.opsion.fr> <20021217143543.64117@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe wrote: > On Tue, Dec 17, 2002 at 08:38:53AM +0000, Nicolas Boulay wrote: > >>There some imm instruction using 8 or 16 bits. >> >>I had proposed a long time ago, to use the 6 bits register adresse field >>to create an immediat adressing mode available for every instructions. > > > With the constant following in the next 32-bit word(s)? Well, no. > I don't want to build yet another CISC machine. > Well I am glad I never took computer science, and just learned computers on my own. I don't give a DAM what you call it,immedate constants NEED to be with every instruction set. Any how would not immedate constants be taged as a long constant preceding a instruction? Load/Store machines because they need to generate effective addresses often need to have good immedate instruction format. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Dec 17 14:35:43 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6T2-00048Q-00 for ; Thu, 19 Dec 2002 20:36:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:36:24 +0100 (CET) Received: (qmail 341 invoked by uid 0); 17 Dec 2002 17:48:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 17 Dec 2002 17:48:46 -0000 Received: by moria.seul.org (Postfix) id B42FB33C63; Tue, 17 Dec 2002 12:48:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A4E233C98; Tue, 17 Dec 2002 12:48:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a143.home.uni-hannover.de [130.75.232.143]) by moria.seul.org (Postfix) with ESMTP id 0BA4933C63 for ; Tue, 17 Dec 2002 12:48:43 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00532; Tue, 17 Dec 2002 14:35:43 +0100 Message-ID: <20021217143543.64117@thrai.stud.uni-hannover.de> Date: Tue, 17 Dec 2002 14:35:43 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] signed cmpl References: <200212170838.353f@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212170838.353f@th00.opsion.fr>; from Nicolas Boulay on Tue, Dec 17, 2002 at 08:38:53AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Dec 17, 2002 at 08:38:53AM +0000, Nicolas Boulay wrote: > There some imm instruction using 8 or 16 bits. > > I had proposed a long time ago, to use the 6 bits register adresse field > to create an immediat adressing mode available for every instructions. With the constant following in the next 32-bit word(s)? Well, no. I don't want to build yet another CISC machine. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 18 23:52:37 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Tk-00048Q-00 for ; Thu, 19 Dec 2002 20:37:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:37:08 +0100 (CET) Received: (qmail 29720 invoked by uid 0); 17 Dec 2002 23:14:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 17 Dec 2002 23:14:31 -0000 Received: by moria.seul.org (Postfix) id 02C1533C90; Tue, 17 Dec 2002 18:14:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9858B33CD0; Tue, 17 Dec 2002 18:14:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 097D733C90 for ; Tue, 17 Dec 2002 18:14:26 -0500 (EST) Received: from Biathlon (lcbv4-2-48.n.club-internet.fr [213.44.93.48]) by relay-5v.club-internet.fr (Postfix) with SMTP id 70E1316E0 for ; Wed, 18 Dec 2002 00:14:34 +0100 (CET) Date: Wed, 18 Dec 2002 23:52:37 +0100 From: nico To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] signed cmpl Message-Id: <20021218235237.2c42c6e4.nicolas.boulay@ifrance.com> In-Reply-To: <20021217143543.64117@thrai.stud.uni-hannover.de> References: <200212170838.353f@th00.opsion.fr> <20021217143543.64117@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 17 Dec 2002 14:35:43 +0100 Michael Riepe wrote: > On Tue, Dec 17, 2002 at 08:38:53AM +0000, Nicolas Boulay wrote: > > There some imm instruction using 8 or 16 bits. > > > > I had proposed a long time ago, to use the 6 bits register adresse > > field to create an immediat adressing mode available for every > > instructions. > > With the constant following in the next 32-bit word(s)? Well, no. > I don't want to build yet another CISC machine. ??? i never proposed that. Juste to use 6 bits of the field. Nothing more easy to do in hardware. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger > http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 18 00:52:28 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Tn-00048Q-00 for ; Thu, 19 Dec 2002 20:37:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:37:11 +0100 (CET) Received: (qmail 31642 invoked by uid 0); 17 Dec 2002 23:52:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 17 Dec 2002 23:52:28 -0000 Received: by moria.seul.org (Postfix) id E68BE33CFF; Tue, 17 Dec 2002 18:52:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8624233CF5; Tue, 17 Dec 2002 18:52:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a131.home.uni-hannover.de [130.75.232.131]) by moria.seul.org (Postfix) with ESMTP id C0EFA33CD0 for ; Tue, 17 Dec 2002 18:52:24 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA15675; Wed, 18 Dec 2002 00:52:28 +0100 Message-ID: <20021218005228.04892@thrai.stud.uni-hannover.de> Date: Wed, 18 Dec 2002 00:52:28 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] signed cmpl References: <200212170838.353f@th00.opsion.fr> <20021217143543.64117@thrai.stud.uni-hannover.de> <20021218235237.2c42c6e4.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20021218235237.2c42c6e4.nicolas.boulay@ifrance.com>; from nico on Wed, Dec 18, 2002 at 11:52:37PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 18, 2002 at 11:52:37PM +0100, nico wrote: > > > I had proposed a long time ago, to use the 6 bits register adresse > > > field to create an immediat adressing mode available for every > > > instructions. > > > > With the constant following in the next 32-bit word(s)? Well, no. > > I don't want to build yet another CISC machine. > > ??? i never proposed that. Juste to use 6 bits of the field. Nothing > more easy to do in hardware. Sorry, I misunderstood. But on the other hand, 6 bits aren't much for most purposes - you would have to `loadcons*' more often... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Dec 18 10:45:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6UC-00048Q-00 for ; Thu, 19 Dec 2002 20:37:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:37:36 +0100 (CET) Received: (qmail 8024 invoked by uid 0); 18 Dec 2002 09:45:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 18 Dec 2002 09:45:25 -0000 Received: by moria.seul.org (Postfix) id 4460E33C9D; Wed, 18 Dec 2002 04:45:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A48AD33CD4; Wed, 18 Dec 2002 04:45:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6EA6333C9D for ; Wed, 18 Dec 2002 04:45:22 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212180945.0539; Wed, 18 Dec 2002 09:45:05 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: [f-cpu] signed cmpl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Dec 2002 09:45:05 GMT Message-id: <200212180945.0539@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 18/12/02 Objet: Re: Rep:Re: [f-cpu] signed cmpl On Wed, Dec 18, 2002 at 11:52:37PM +0100, nico wrote: > > > I had proposed a long time ago, to use the 6 bits regi= ster adresse > > > field to create an immediat adressing mode available f= or every > > > instructions. > >=20 > > With the constant following in the next 32-bit word(s)? = Well, no. > > I don't want to build yet another CISC machine. >=20 > ??? i never proposed that. Juste to use 6 bits of the fiel= d. Nothing > more easy to do in hardware. Sorry, I misunderstood. But on the other hand, 6 bits aren't= much for most purposes - you would have to `loadcons*' more often... >>>Only our gcc expert could answer. So, does 32 to -32 numb= er (or 0 to 64) immediat instruction could cover most immediat instructi= ons used by gcc ? nicO --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Thu Dec 19 14:43:05 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Wc-00048Q-00 for ; Thu, 19 Dec 2002 20:40:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:40:06 +0100 (CET) Received: (qmail 21636 invoked by uid 0); 19 Dec 2002 13:35:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 19 Dec 2002 13:35:03 -0000 Received: by moria.seul.org (Postfix) id D1E7B33C5E; Thu, 19 Dec 2002 08:34:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0F4A33D04; Thu, 19 Dec 2002 08:34:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf07bis.bellsouth.net (mail207.mail.bellsouth.net [205.152.58.147]) by moria.seul.org (Postfix) with ESMTP id C2F7033C5E for ; Thu, 19 Dec 2002 08:34:52 -0500 (EST) Received: from computer ([209.215.11.23]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021219133642.JFBI13664.imf07bis.bellsouth.net@computer> for ; Thu, 19 Dec 2002 08:36:42 -0500 Message-ID: <002801c2a764$90698d80$170bd7d1@computer> From: "richard hartny" To: Subject: [f-cpu] Signed Compare & Other Date: Thu, 19 Dec 2002 07:43:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C2A732.446EA320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C2A732.446EA320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guy's & Girls In my design of the Erin32/64/ALP76 I register the result which is = Equal to, Greater Than, or Less Than. These results stay registered until another = CMP is issued. I then use a Test & Branch instruction for discrete test. The = design is=20 based on the SN7485 comparator chip. Other news. Quicklogic has deleted the only package size in which all of my designs = were targeted. So, I have purchased the ACTEL design package and will = now target my design to the AX2000 which is their largest FPGA. In the = ALP76; the Instruction and Operand Pipeline will be increased from the = current 4 to 16 because the on-chip RAM bits will permit. Added Indexing = to Load/Store Operands from Off-chip Local Memory. Also added the LDB (Load Byte), STB (Store Byte), Multiply, and Divided = Instructions. =20 Arbitration iis required for Local Memory useage for both Reads and = Writes. And with the larger logic being available I will be able to = arbitrate to the specific Memory Block ( 1 of 8 ). I still will use the = Cypress Quad and Dual port SSRAM's. =20 Will now use 39 (Thirty Nine) ALP76 processors (A Language = Processor) and 76 is my age. Anyone wishing more info - send a Mail. Dick Hartney ------=_NextPart_000_0025_01C2A732.446EA320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Guy's & Girls
 
    In my design of the=20 Erin32/64/ALP76 I register the result which is Equal to,
Greater Than, or Less Than. These = results stay=20 registered until another CMP is
issued.  I then use a Test & = Branch=20 instruction for discrete test.  The design is
based on the SN7485 comparator = chip.
 
    Other = news.
 
Quicklogic has deleted the only package = size in=20 which all of my designs were targeted.  So, I have purchased the = ACTEL=20 design package and will now target my design to the AX2000 which is = their=20 largest FPGA.  In the ALP76; the Instruction and Operand Pipeline = will be=20 increased from the current 4 to 16 because the on-chip RAM bits = will=20 permit. Added Indexing to Load/Store Operands from Off-chip Local=20 Memory.
Also added the LDB (Load Byte), STB = (Store Byte),=20 Multiply, and Divided Instructions. 
 
    Arbitration iis = required for=20 Local Memory useage for both Reads and Writes.  And with the larger = logic=20 being available I will be able to arbitrate to the specific Memory Block = ( 1 of=20 8 ).  I still will use the Cypress Quad and Dual port = SSRAM's.
 
    Will now use 39 = (Thirty Nine)=20 ALP76 processors (A Language Processor) and 76 is my age.
 
    Anyone wishing more = info - send=20 a Mail.
 
Dick Hartney
------=_NextPart_000_0025_01C2A732.446EA320-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Dec 19 11:47:26 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6WP-00048Q-00 for ; Thu, 19 Dec 2002 20:39:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:39:53 +0100 (CET) Received: (qmail 23610 invoked by uid 0); 19 Dec 2002 10:48:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Dec 2002 10:48:16 -0000 Received: by moria.seul.org (Postfix) id 3DFDA33CC7; Thu, 19 Dec 2002 05:48:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A438033D36; Thu, 19 Dec 2002 05:48:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 2AC5A33CC7 for ; Thu, 19 Dec 2002 05:48:12 -0500 (EST) Received: from a126-137.dialup.iol.cz ([194.228.137.126] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18OyDO-0004FJ-00 for f-cpu@seul.org; Thu, 19 Dec 2002 11:47:43 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18OyD8-0000DT-00 for f-cpu@seul.org; Thu, 19 Dec 2002 11:47:26 +0100 Date: Thu, 19 Dec 2002 11:47:26 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] vsprintf result for GCC & FCPU In-Reply-To: <20021216152030.54203@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > :-) The code should work but you have to define macros for > > jumps. The code is not still able to handle loadaddr and > > jumps. Also there is still lack of conditional move - it > > is one which should reduce code size further. > > What kind of macros? like .macro jmp_direct_nz r,label loadcons label jmp r,label,r0 .endm I still can't decide way how to generate lavel & symbol references. 64 bit symbol load needs 4 loadcons (16 bytes) and there is a lot of them. Local labels can use loadaddri (if they are in 16bit range). I'd rather see to use 32bit addresses for code and 64 for data. > When you finally find the time, can you please change the assembler > syntax a little? First, immediate operands should be prefixed with a `$' > character (that is, in real instructions, not in .pseudo ops) - that way > it's possible to make a difference between symbolic constants and register > names (just consider a symbol named `r0') without looking at the opcode. > Second, please change the register names to r0...r63. There are no > designated argument or temporary registers, stack or frame pointers. > Besides that, it's not wise to reflect the calling conventions in the > register names, and IMHO it's also harder to read. ok done, see the example of asm I send yesterday. > Once you're done with that, my assembler should be able to process the > assembler source files generated by your gcc port. Since I also have ar, > mcs, nm, size, strings and strip utilities floating around on my disk, > we would have an almost complete, working f-cpu toolchain (only ld is > still missing). can you send me these tools ? So I'd be able at least validate the output... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Dec 18 19:21:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6VJ-00048Q-00 for ; Thu, 19 Dec 2002 20:38:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:38:45 +0100 (CET) Received: (qmail 21731 invoked by uid 0); 18 Dec 2002 18:27:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 18 Dec 2002 18:27:00 -0000 Received: by moria.seul.org (Postfix) id 9E76733D04; Wed, 18 Dec 2002 13:26:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2272533D44; Wed, 18 Dec 2002 13:26:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id A45DC33D04 for ; Wed, 18 Dec 2002 13:26:58 -0500 (EST) Received: from homeworld (81.48.49.220) by smtp.laposte.net (6.0.053) id 3DF92867000D77B0 for f-cpu@seul.org; Wed, 18 Dec 2002 19:26:58 +0100 Message-ID: <006001c2a6c2$57323690$0100000a@homeworld> From: "Christophe Avoinne" To: References: <200212180945.0539@th00.opsion.fr> <20021218135752.04847@thrai.stud.uni-hannover.de> Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl Date: Wed, 18 Dec 2002 19:21:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I think Nico wanted to say if our "gcc expert" can tell us if gcc often produces instructions where a 6-bit immediate is likely to be enough. If so, it can be a gain, if not, don't bother too much with a 6-bit immediate. ----- Original Message ----- From: "Michael Riepe" To: Sent: Wednesday, December 18, 2002 1:57 PM Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl > On Wed, Dec 18, 2002 at 09:45:05AM +0000, Nicolas Boulay wrote: > > > >>>Only our gcc expert could answer. So, does 32 to -32 number (or 0 to > > 64) immediat instruction could cover most immediat instructions used by > > gcc ? > > I don't need a gcc expert for that :) Since you can specify the size > in the machine description, it's not a problem at all. Currently, there > are RTL terms like > > (match_operand:SI 2 "regimm8_operand" "r,i") > > which refer to the C function regimm8_operand() - if you modify that > to accept only 6-bit operands, you're done (for ALL instructions that > can use this kind of operand). Everything that doesn't fit will be > loaded into a register. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Wed Dec 18 18:58:34 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6VE-00048Q-01 for ; Thu, 19 Dec 2002 20:38:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:38:40 +0100 (CET) Received: (qmail 14953 invoked by uid 0); 18 Dec 2002 18:05:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 18 Dec 2002 18:05:01 -0000 Received: by moria.seul.org (Postfix) id 3AC0233CF5; Wed, 18 Dec 2002 13:05:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 921E233D04; Wed, 18 Dec 2002 13:04:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 28C3733CF5 for ; Wed, 18 Dec 2002 13:04:59 -0500 (EST) Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by bettik.munge.net (Postfix) with ESMTP id 067C24F76E for ; Wed, 18 Dec 2002 12:05:02 -0600 (CST) Received: from jetnet.ab.ca (gc-jet-202.jetnet.ab.ca [207.34.60.202]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id gBII3Q6f087742 for ; Wed, 18 Dec 2002 11:03:31 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E00B74A.6070001@jetnet.ab.ca> Date: Wed, 18 Dec 2002 10:58:34 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl References: <200212180945.0539@th00.opsion.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Nicolas Boulay wrote: > 64) immediat instruction could cover most immediat instructions used by > gcc ? > nicO I think the best way to find out is study typical programs. Small constants +-15..0 are used for auto incriment/decriment instuctions and small case values. NULL is often 0 and error codes -1...-n. Character constants would be the next common case. I am guessing +- 4096 bytes would typical for stack addressing. +- 262144 bytes would make a good short base address providing array/record data is sorted after record data. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Dec 18 13:57:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6VD-00048Q-00 for ; Thu, 19 Dec 2002 20:38:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:38:39 +0100 (CET) Received: (qmail 24125 invoked by uid 0); 18 Dec 2002 17:33:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 18 Dec 2002 17:33:52 -0000 Received: by moria.seul.org (Postfix) id A01C633D73; Wed, 18 Dec 2002 12:33:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3188C33D75; Wed, 18 Dec 2002 12:33:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a103.home.uni-hannover.de [130.75.232.103]) by moria.seul.org (Postfix) with ESMTP id 04B9033D73 for ; Wed, 18 Dec 2002 12:33:49 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00535; Wed, 18 Dec 2002 13:57:52 +0100 Message-ID: <20021218135752.04847@thrai.stud.uni-hannover.de> Date: Wed, 18 Dec 2002 13:57:52 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl References: <200212180945.0539@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212180945.0539@th00.opsion.fr>; from Nicolas Boulay on Wed, Dec 18, 2002 at 09:45:05AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 18, 2002 at 09:45:05AM +0000, Nicolas Boulay wrote: > >>>Only our gcc expert could answer. So, does 32 to -32 number (or 0 to > 64) immediat instruction could cover most immediat instructions used by > gcc ? I don't need a gcc expert for that :) Since you can specify the size in the machine description, it's not a problem at all. Currently, there are RTL terms like (match_operand:SI 2 "regimm8_operand" "r,i") which refer to the C function regimm8_operand() - if you modify that to accept only 6-bit operands, you're done (for ALL instructions that can use this kind of operand). Everything that doesn't fit will be loaded into a register. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Dec 18 12:07:32 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6VS-00048Q-00 for ; Thu, 19 Dec 2002 20:38:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:38:54 +0100 (CET) Received: (qmail 17960 invoked by uid 0); 18 Dec 2002 20:17:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 18 Dec 2002 20:17:12 -0000 Received: by moria.seul.org (Postfix) id A5D8D33D43; Wed, 18 Dec 2002 15:17:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 16D8D33D48; Wed, 18 Dec 2002 15:17:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id F162C33D43 for ; Wed, 18 Dec 2002 15:17:09 -0500 (EST) Received: from a49-137.dialup.iol.cz ([194.228.137.49] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Okcs-0002VB-00 for f-cpu@seul.org; Wed, 18 Dec 2002 21:17:07 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Oc32-0000fA-00 for f-cpu@seul.org; Wed, 18 Dec 2002 12:07:32 +0100 Date: Wed, 18 Dec 2002 12:07:32 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl In-Reply-To: <200212180945.0539@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Sorry, I misunderstood. But on the other hand, 6 bits aren't much for > most purposes - you would have to `loadcons*' more often... > > >>>Only our gcc expert could answer. So, does 32 to -32 number (or 0 to > 64) immediat instruction could cover most immediat instructions used by > gcc ? > nicO Because I test majority of things with vsprintf.c from linux kernel just now it is not too objective. There is 275 immediates used in the file. Here is usage of constant NOT IN -32...31 range: 13 addi 21 andi 3 cmplei 1 cmplesi 2 ori 33 xor.ori and these are IN range: 140 addi 23 andi 1 cmplei 13 cmplesi 3 cmplsi 4 nxor.andi 7 ori 4 shiftli 7 xor.ori So that 202 insns ARE in 6bit range but these was constants 1 and -1 often (addi) - I didn't implemented INC/DEC yet. There was 82 of such. As conclusion from 275 immediates 120 (202-82) can be coded into 6 bits. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 19 00:14:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Vm-00048Q-00 for ; Thu, 19 Dec 2002 20:39:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:39:14 +0100 (CET) Received: (qmail 9472 invoked by uid 0); 18 Dec 2002 23:16:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 18 Dec 2002 23:16:00 -0000 Received: by moria.seul.org (Postfix) id E940A33D45; Wed, 18 Dec 2002 18:15:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7DC1533CF5; Wed, 18 Dec 2002 18:15:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a142.home.uni-hannover.de [130.75.232.142]) by moria.seul.org (Postfix) with ESMTP id D279833D4D for ; Wed, 18 Dec 2002 18:15:56 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA00583; Thu, 19 Dec 2002 00:14:46 +0100 Message-ID: <20021219001446.02390@thrai.stud.uni-hannover.de> Date: Thu, 19 Dec 2002 00:14:46 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl References: <200212180945.0539@th00.opsion.fr> <20021218135752.04847@thrai.stud.uni-hannover.de> <006001c2a6c2$57323690$0100000a@homeworld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <006001c2a6c2$57323690$0100000a@homeworld>; from Christophe Avoinne on Wed, Dec 18, 2002 at 07:21:52PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Dec 18, 2002 at 07:21:52PM +0100, Christophe Avoinne wrote: > I think Nico wanted to say if our "gcc expert" can tell us if gcc often > produces instructions where a 6-bit immediate is likely to be enough. If so, > it can be a gain, if not, don't bother too much with a 6-bit immediate. I don't think that it's a property of the compiler - it depends on the code you compile. 6 bits isn't enough to encode ASCII, for example - so if you deal with character values a lot, 8 bits would be much better. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Dec 19 00:47:46 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Vt-00048Q-00 for ; Thu, 19 Dec 2002 20:39:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:39:21 +0100 (CET) Received: (qmail 15840 invoked by uid 0); 18 Dec 2002 23:33:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 18 Dec 2002 23:33:29 -0000 Received: by moria.seul.org (Postfix) id E724833D4D; Wed, 18 Dec 2002 18:33:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CB7F433D48; Wed, 18 Dec 2002 18:33:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 6770733CF1 for ; Wed, 18 Dec 2002 18:33:27 -0500 (EST) Received: from f-cpu.org (lcbv1-1-70.n.club-internet.fr [213.44.3.70]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2AD5616B9 for ; Thu, 19 Dec 2002 00:33:00 +0100 (CET) Message-ID: <3E010922.6080504@f-cpu.org> Date: Thu, 19 Dec 2002 00:47:46 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl References: <200212180945.0539@th00.opsion.fr> <20021218135752.04847@thrai.stud.uni-hannover.de> <006001c2a6c2$57323690$0100000a@homeworld> <20021219001446.02390@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Dec 18, 2002 at 07:21:52PM +0100, Christophe Avoinne wrote: > > >>I think Nico wanted to say if our "gcc expert" can tell us if gcc often >>produces instructions where a 6-bit immediate is likely to be enough. If so, >>it can be a gain, if not, don't bother too much with a 6-bit immediate. >> >> > >I don't think that it's a property of the compiler - it depends on the >code you compile. 6 bits isn't enough to encode ASCII, for example - >so if you deal with character values a lot, 8 bits would be much >better. > > A lot of instructions have a 8-bit constant mode. there are already "issues" about how it is sign-extended and how it behaves in SIMD modes. If it's like that in 8-bit, it's certainly the same issues with 6 bits... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Dec 19 02:54:59 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6WA-00048Q-00 for ; Thu, 19 Dec 2002 20:39:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:39:38 +0100 (CET) Received: (qmail 27564 invoked by uid 0); 19 Dec 2002 08:55:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 19 Dec 2002 08:55:56 -0000 Received: by moria.seul.org (Postfix) id 40A4533CF1; Thu, 19 Dec 2002 03:55:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CB66433D45; Thu, 19 Dec 2002 03:55:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 330CE33CF1 for ; Thu, 19 Dec 2002 03:55:43 -0500 (EST) Received: from a14-137.dialup.iol.cz ([194.228.137.14] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18OwSp-0003xl-00 for f-cpu@seul.org; Thu, 19 Dec 2002 09:55:32 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Optr-0006w3-00 for f-cpu@seul.org; Thu, 19 Dec 2002 02:54:59 +0100 Date: Thu, 19 Dec 2002 02:54:59 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] next gcc tests: vsprintf.s Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2069524284-1040262899=:566" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-2069524284-1040262899=:566 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I added output of latest gcc compilation of vsprintf.c. I repaired most of things reported by MR. devik --8323328-2069524284-1040262899=:566 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vsprintf.s" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="vsprintf.s" OyBGLUNQVSBBU00gYnkgZGV2aWtAY2RpLmN6DQoudGV4dA0KLmV4dGVybiBz aW1wbGVfc3RydG91bA0Kc2ltcGxlX3N0cnRvdWw6DQoJZG1vdmUgcjIscjUs cjMscjEwDQoJbW92ZS42NCByMCxyNg0KCWptcF9kaXJlY3RfbnogcjQsQEwy DQoJbG9hZGNvbnMuMzIgJDEwLHI0DQoJbG9hZC44IFtyMl0scjENCgl4b3Iu b3JpLjggJDQ4LHIxLHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDINCglic2V0 aS4zMiAkMyxyMCxyNA0KCWluYy42NCByMixyNQ0KCWxvYWQuOCBbcjVdLHIx DQoJeG9yLm9yaS44ICQxMjAscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBM Mg0KCWluYy42NCByNSxyMw0KCWxvYWQuOCBbcjNdLHIxDQoJbW92ZS44IHIx LHIxCS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlwZSxyMg0K CWFkZC42NCByMixyMSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJYW5kaS44ICQ2 OCxyMSxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDINCgltb3ZlLjY0IHIzLHI1 DQoJYnNldGkuMzIgJDQscjAscjQNCkBMMjoNCglsb2FkY29ucy42NCAkX2N0 eXBlLHI4DQoJbW92ZS42NCByOCxyOQ0KCW1vdmUuMzIgcjQscjcJLy8gemVy b19leHRlbmQNCgltb3ZlLjY0IHI3LHI0DQoJam1wX2RpcmVjdCBATDUNCkBM MTM6DQoJbXVsLjY0IHI0LHI2LHIxDQoJYWRkLjY0IHIyLHIxLHI2DQoJaW5j LjY0IHI1LHI1DQpATDU6DQoJbG9hZC44IFtyNV0scjMNCgltb3ZlLjggcjMs cjEJLy8gemVyb19leHRlbmQNCglhZGQuNjQgcjgscjEscjENCglsb2FkLjgg W3IxXSxyMg0KCWFuZGkuOCAkNjgscjIscjENCglqbXBfZGlyZWN0X3ogcjEs QEw2DQoJYW5kaS44ICQ0LHIyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMOQ0K CXdpZGVuLjggcjMscjENCglzdWJpLjMyIDQ4LHIxLHIxDQoJd2lkZW4uMzIg cjEscjINCglqbXBfZGlyZWN0IEBMMTANCkBMOToNCglsb2FkLjggW3I1XSxy Mg0KCW1vdmUuOCByMixyMQkvLyB6ZXJvX2V4dGVuZA0KCWFkZC42NCByOSxy MSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJYW5kaS44ICQyLHIxLHIxDQoJc3Vi aS44IDMyLHIyLHIzDQoJY21vdmUuOCByMSxyMyxyMg0KCW1vdmUuOCByMixy MgkvLyB6ZXJvX2V4dGVuZA0KCXN1YmkuMzIgNTUscjIscjINCgl3aWRlbi4z MiByMixyMg0KQEwxMDoNCgljbXBsLjY0IHI3LHIyLHIxDQoJam1wX2RpcmVj dF9ueiByMSxATDEzDQpATDY6DQoJam1wX2RpcmVjdF96IHIxMCxATDE0DQoJ c3RvcmUuNjQgW3IxMF0scjUNCkBMMTQ6DQoJbW92ZS42NCByNixyMQ0KCWpt cCByYQ0KLmV4dGVybiBzaW1wbGVfc3RydG9sDQpzaW1wbGVfc3RydG9sOg0K CXN0b3JlICQtOCxzcCxyNjMNCglsb2FkLjggW3IyXSxyMQ0KCXhvci5vcmku OCAkNDUscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMTYNCglpbmMuNjQg cjIscjINCglsb2FkY29ucy42NCAkc2ltcGxlX3N0cnRvdWwscjENCglqbXAg cjEscmENCgluZWcuNjQgcjEscjENCglqbXBfZGlyZWN0IEBMMTUNCkBMMTY6 DQoJbG9hZGNvbnMuNjQgJHNpbXBsZV9zdHJ0b3VsLHIxDQoJam1wIHIxLHJh DQpATDE1Og0KCWxvYWQgOCxzcCxyNjMNCglqbXAgcmENCi5leHRlcm4gc2lt cGxlX3N0cnRvdWxsDQpzaW1wbGVfc3RydG91bGw6DQoJbW92ZS42NCByMixy Ng0KCW1vdmUuNjQgcjAscjcNCglqbXBfZGlyZWN0X256IHI0LEBMMTgNCgls b2FkY29ucy4zMiAkMTAscjQNCglsb2FkLjggW3IyXSxyMQ0KCXhvci5vcmku OCAkNDgscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMTgNCglic2V0aS4z MiAkMyxyMCxyNA0KCWluYy42NCByMixyNg0KCWxvYWQuOCBbcjZdLHIxDQoJ eG9yLm9yaS44ICQxMjAscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMTgN CglpbmMuNjQgcjYscjUNCglsb2FkLjggW3I1XSxyMQ0KCW1vdmUuOCByMSxy MQkvLyB6ZXJvX2V4dGVuZA0KCWxvYWRjb25zLjY0ICRfY3R5cGUscjINCglh ZGQuNjQgcjIscjEscjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAkNjgs cjEscjENCglqbXBfZGlyZWN0X3ogcjEsQEwxOA0KCW1vdmUuNjQgcjUscjYN Cglic2V0aS4zMiAkNCxyMCxyNA0KQEwxODoNCglsb2FkY29ucy42NCAkX2N0 eXBlLHI5DQoJbW92ZS42NCByOSxyMTANCgltb3ZlLjMyIHI0LHI4CS8vIHpl cm9fZXh0ZW5kDQoJbW92ZS42NCByOCxyNA0KCWptcF9kaXJlY3QgQEwyMQ0K QEwzMToNCgltdWwuNjQgcjQscjcscjENCglhZGQuNjQgcjIscjEscjcNCglp bmMuNjQgcjYscjYNCkBMMjE6DQoJbG9hZC44IFtyNl0scjUNCgltb3ZlLjgg cjUscjEJLy8gemVyb19leHRlbmQNCglhZGQuNjQgcjkscjEscjENCglsb2Fk LjggW3IxXSxyMg0KCWFuZGkuOCAkNjgscjIscjENCglqbXBfZGlyZWN0X3og cjEsQEwyMg0KCWFuZGkuOCAkNCxyMixyMQ0KCWptcF9kaXJlY3RfeiByMSxA TDI1DQoJd2lkZW4uOCByNSxyMQ0KCXN1YmkuMzIgNDgscjEscjENCgl3aWRl bi4zMiByMSxyMg0KCWptcF9kaXJlY3QgQEwyNg0KQEwyNToNCglsb2FkLjgg W3I2XSxyMg0KCW1vdmUuOCByMixyMQkvLyB6ZXJvX2V4dGVuZA0KCWFkZC42 NCByMTAscjEscjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAkMixyMSxy MQ0KCWptcF9kaXJlY3RfeiByMSxATDI3DQoJc3ViaS44IDMyLHIyLHIxDQoJ bW92ZS44IHIxLHIxCS8vIHplcm9fZXh0ZW5kDQoJc3ViaS4zMiA1NSxyMSxy MQ0KCXdpZGVuLjMyIHIxLHIyDQoJam1wX2RpcmVjdCBATDI2DQpATDI3Og0K CWxvYWQuOCBbcjZdLHIxDQoJd2lkZW4uOCByMSxyMQ0KCXN1YmkuMzIgNTUs cjEscjENCgl3aWRlbi4zMiByMSxyMg0KQEwyNjoNCgljbXBsLjY0IHI4LHIy LHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDMxDQpATDIyOg0KCWptcF9kaXJl Y3RfeiByMyxATDMyDQoJc3RvcmUuNjQgW3IzXSxyNg0KQEwzMjoNCgltb3Zl LjY0IHI3LHIxDQoJam1wIHJhDQouZXh0ZXJuIHNpbXBsZV9zdHJ0b2xsDQpz aW1wbGVfc3RydG9sbDoNCglzdG9yZSAkLTgsc3AscjYzDQoJbG9hZC44IFty Ml0scjENCgl4b3Iub3JpLjggJDQ1LHIxLHIxDQoJam1wX2RpcmVjdF9ueiBy MSxATDM0DQoJaW5jLjY0IHIyLHIyDQoJbG9hZGNvbnMuNjQgJHNpbXBsZV9z dHJ0b3VsbCxyMQ0KCWptcCByMSxyYQ0KCW5lZy42NCByMSxyMQ0KCWptcF9k aXJlY3QgQEwzMw0KQEwzNDoNCglsb2FkY29ucy42NCAkc2ltcGxlX3N0cnRv dWxsLHIxDQoJam1wIHIxLHJhDQpATDMzOg0KCWxvYWQgOCxzcCxyNjMNCglq bXAgcmENCnNraXBfYXRvaToNCgltb3ZlLjY0IHIyLHI3DQoJbW92ZS4zMiBy MCxyNA0KCWxvYWQuNjQgW3IyXSxyMQ0KCW1vdmUuNjQgcjEscjUNCglsb2Fk LjggW3IxXSxyMQ0KCW1vdmUuOCByMSxyMQkvLyB6ZXJvX2V4dGVuZA0KCWxv YWRjb25zLjY0ICRfY3R5cGUscjINCgltb3ZlLjY0IHIyLHI2DQoJYWRkLjY0 IHIyLHIxLHIxDQoJbG9hZC44IFtyMV0scjENCglhbmRpLjggJDQscjEscjEN CglqbXBfZGlyZWN0X3ogcjEsQEw0MQ0KQEwzOToNCglzaGlmdGxpLjMyICQz LHI0LHIyDQoJYWRkLjMyIHI0LHIyLHIyDQoJYWRkLjMyIHI0LHIyLHIyDQoJ bG9hZC44IFtyNV0scjENCgl3aWRlbi44IHIxLHIxDQoJYWRkLjMyIHIxLHIy LHIyDQoJc3ViaS4zMiA0OCxyMixyNA0KCWluYy42NCByNSxyMw0KCXN0b3Jl LjY0IFtyN10scjMNCgltb3ZlLjY0IHIzLHI1DQoJbG9hZC44IFtyM10scjEN Cgltb3ZlLjggcjEscjEJLy8gemVyb19leHRlbmQNCglhZGQuNjQgcjYscjEs cjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAkNCxyMSxyMQ0KCWptcF9k aXJlY3RfbnogcjEsQEwzOQ0KQEw0MToNCgltb3ZlLjMyIHI0LHIxDQoJam1w IHJhDQpATEMwOg0KCS5hc2NpaSAiMDEyMzQ1Njc4OWFiY2RlZmdoaWprbG1u b3BxcnN0dXZ3eHl6XDAiDQpATEMxOg0KCS5hc2NpaSAiMDEyMzQ1Njc4OUFC Q0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaXDAiDQpudW1iZXI6DQoJc3RvcmUg JC04LHNwLHIzMg0KCXN0b3JlICQtOCxzcCxyMzMNCglzdG9yZSAkLTgsc3As cjM0DQoJc3RvcmUgJC04LHNwLHIzNQ0KCXN0b3JlICQtOCxzcCxyMzYNCglz dG9yZSAkLTgsc3AscjM3DQoJc3RvcmUgJC04LHNwLHIzOA0KCXN0b3JlICQt OCxzcCxyMzkNCglzdG9yZSAkLTgsc3AscjQwDQoJc3RvcmUgJC04LHNwLHI0 MQ0KCXN0b3JlICQtOCxzcCxyNDINCglzdG9yZSAkLTgsc3AscjQzDQoJc3Rv cmUgJC04LHNwLHI2Mw0KCWRtb3ZlIHIyLHIzMixyMyxyMzUNCglkbW92ZSBy NCxyMzgscjUscjQwDQoJZG1vdmUgcjYscjMzLHI3LHIzNg0KCW1vdmUuMzIg cjgscjM3DQoJc3ViaS42NCAxMTYscjYyLHIzDQoJbG9hZGNvbnMuNjQgJEBM QzAscjINCglsb2FkLjY0IFtyMl0scjINCglzdG9yZS42NCBbcjNdLHIyDQoJ YWRkaS42NCAkOCxyMyxyMQ0KCWxvYWRjb25zLjY0ICRATEMwKzgscjINCgls b2FkLjY0IFtyMl0scjINCglzdG9yZS42NCBbcjFdLHIyDQoJYWRkaS42NCAk OCxyMSxyMQ0KCWxvYWRjb25zLjY0ICRATEMwKzE2LHIyDQoJbG9hZC42NCBb cjJdLHIyDQoJc3RvcmUuNjQgW3IxXSxyMg0KCWFkZGkuNjQgJDgscjEscjEN Cglsb2FkY29ucy42NCAkQExDMCsyNCxyMg0KCWxvYWQuNjQgW3IyXSxyMg0K CXN0b3JlLjY0IFtyMV0scjINCglhZGRpLjY0ICQ4LHIxLHIxDQoJbG9hZGNv bnMuNjQgJEBMQzArMzIscjINCglsb2FkLjMyIFtyMl0scjINCglzdG9yZS4z MiBbcjFdLHIyDQoJYWRkaS42NCAkNCxyMSxyMQ0KCWxvYWRjb25zLjY0ICRA TEMwKzM2LHIyDQoJbG9hZC44IFtyMl0scjINCglzdG9yZS44IFtyMV0scjIN CglzdWJpLjY0IDE1NixyNjIscjINCglsb2FkY29ucy42NCAkQExDMSxyNA0K CWxvYWQuNjQgW3I0XSxyNA0KCXN0b3JlLjY0IFtyMl0scjQNCglhZGRpLjY0 ICQ4LHIyLHIxDQoJbG9hZGNvbnMuNjQgJEBMQzErOCxyNA0KCWxvYWQuNjQg W3I0XSxyNA0KCXN0b3JlLjY0IFtyMV0scjQNCglhZGRpLjY0ICQ4LHIxLHIx DQoJbG9hZGNvbnMuNjQgJEBMQzErMTYscjQNCglsb2FkLjY0IFtyNF0scjQN CglzdG9yZS42NCBbcjFdLHI0DQoJYWRkaS42NCAkOCxyMSxyMQ0KCWxvYWRj b25zLjY0ICRATEMxKzI0LHI0DQoJbG9hZC42NCBbcjRdLHI0DQoJc3RvcmUu NjQgW3IxXSxyNA0KCWFkZGkuNjQgJDgscjEscjENCglsb2FkY29ucy42NCAk QExDMSszMixyNA0KCWxvYWQuMzIgW3I0XSxyNA0KCXN0b3JlLjMyIFtyMV0s cjQNCglhZGRpLjY0ICQ0LHIxLHIxDQoJbG9hZGNvbnMuNjQgJEBMQzErMzYs cjQNCglsb2FkLjggW3I0XSxyNA0KCXN0b3JlLjggW3IxXSxyNA0KCWFuZGku MzIgJDY0LHI4LHIxDQoJbnhvci5hbmRpLjMyICQwLHIxLHIxDQoJbW92ZS42 NCByMixyNDMNCgljbW92ZS42NCByMSxyMyxyNDMNCglhbmRpLjMyICQxNixy OCxyMg0KCWFuZGkuMzIgJC0yLHI4LHIxDQoJY21vdmUuMzIgcjIscjEscjM3 DQoJc3ViaS4zMiAyLHI1LHIxDQoJY21wbGVpLjMyICQzNCxyMSxyMQ0KCW1v dmUuNjQgcjAscjINCglqbXBfZGlyZWN0X3ogcjEsQEw0Mg0KCWptcF9kaXJl Y3QgQEw0Ng0KQEw0NjoNCglhbmRpLjMyICQxLHIzNyxyMQ0KCW54b3IuYW5k aS4zMiAkMCxyMSxyMQ0KCWxvYWRjb25zLjAgMzIscjMNCglsb2FkY29ucy4w IDQ4LHIyDQoJbW92ZS44IHIyLHI0Mg0KCWNtb3ZlLjggcjEscjMscjQyDQoJ bG9hZGNvbnMuMCAwLHI0MQ0KCWFuZGkuMzIgJDIscjM3LHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMNDkNCgljbXBsc2kuNjQgJDAscjM4LHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMNTANCglsb2FkY29ucy4wIDQ1LHI0MQ0KCW5lZy42NCBy MzgscjM4DQoJZGVjLjMyIHI2LHIzMw0KCWptcF9kaXJlY3QgQEw0OQ0KQEw1 MDoNCglhbmRpLjMyICQ0LHIzNyxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDUy DQoJbG9hZGNvbnMuMCA0MyxyNDENCglkZWMuMzIgcjYscjMzDQoJam1wX2Rp cmVjdCBATDQ5DQpATDUyOg0KCWFuZGkuMzIgJDgscjM3LHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMNDkNCglsb2FkY29ucy4wIDMyLHI0MQ0KCWRlYy4zMiBy NixyMzMNCkBMNDk6DQoJYW5kaS4zMiAkMzIscjM3LHIxDQoJam1wX2RpcmVj dF96IHIxLEBMNTUNCgl4b3Iub3JpLjMyICQxNixyNDAscjENCglqbXBfZGly ZWN0X256IHIxLEBMNTYNCglzdWJpLjMyIDIscjMzLHIzMw0KCWptcF9kaXJl Y3QgQEw1NQ0KQEw1NjoNCglueG9yLmFuZGkuMzIgJDgscjQwLHIxDQoJYWRk LjMyIHIxLHIzMyxyMzMNCkBMNTU6DQoJbW92ZS4zMiByMCxyMzQNCglqbXBf ZGlyZWN0X256IHIzOCxATDEwMg0KCXN1YmkuNjQgNzYscjYyLHIxDQoJbG9h ZGNvbnMuMCA0OCxyMg0KCXN0b3JlLjggW3IxXSxyMg0KCWJzZXRpLjMyICQw LHIwLHIzNA0KCWptcF9kaXJlY3QgQEw2MA0KQEwxMDI6DQoJc3ViaS42NCA3 NixyNjIscjM5DQoJd2lkZW4uMzIgcjQwLHIzDQoJbW92ZS42NCByMzgscjIN Cglsb2FkY29ucy42NCAkX19kaXZkaTMscjENCglqbXAgcjEscmENCglhZGQu NjQgcjEscjQzLHIyDQpATDY0Og0KCXdpZGVuLjMyIHIzNCxyMQ0KCWFkZC42 NCByMSxyMzkscjENCglsb2FkLjggW3IyXSxyMw0KCXN0b3JlLjggW3IxXSxy Mw0KCWluYy4zMiByMzQscjM0DQoJam1wX2RpcmVjdF9ueiByMzgsQEw2NA0K QEw2MDoNCgljbXBsZXMuMzIgcjM2LHIzNCxyMQ0KCW1vdmUuMzIgcjM0LHIy DQoJY21vdmUuMzIgcjEscjM2LHIyDQoJbW92ZS4zMiByMixyMzYNCglzdWIu MzIgcjIscjMzLHIzMw0KCWFuZGkuMzIgJDE3LHIzNyxyMQ0KCWptcF9kaXJl Y3RfbnogcjEsQEw2Ng0KCW1vdmUuMzIgcjMzLHIxDQoJZGVjLjMyIHIzMyxy MzMNCgljbXBsZXNpLjMyICQwLHIxLHIxDQoJam1wX2RpcmVjdF9ueiByMSxA TDY2DQoJbG9hZGNvbnMuMCAzMixyMg0KQEw3MToNCgljbXBsZS42NCByMzUs cjMyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMNzANCglzdG9yZS44IFtyMzJd LHIyDQpATDcwOg0KCWluYy42NCByMzIscjMyDQoJbW92ZS4zMiByMzMscjEN CglkZWMuMzIgcjMzLHIzMw0KCWNtcGxlc2kuMzIgJDAscjEscjENCglqbXBf ZGlyZWN0X3ogcjEsQEw3MQ0KQEw2NjoNCglqbXBfZGlyZWN0X3ogcjQxLEBM NzINCgljbXBsZS42NCByMzUscjMyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBM NzMNCglzdG9yZS44IFtyMzJdLHI0MQ0KQEw3MzoNCglpbmMuNjQgcjMyLHIz Mg0KQEw3MjoNCglhbmRpLjMyICQzMixyMzcscjENCglqbXBfZGlyZWN0X3og cjEsQEw3NA0KCXhvci5vcmkuMzIgJDgscjQwLHIxDQoJam1wX2RpcmVjdF9u eiByMSxATDc1DQoJY21wbGUuNjQgcjM1LHIzMixyMQ0KCWptcF9kaXJlY3Rf eiByMSxATDc2DQoJbG9hZGNvbnMuMCA0OCxyMw0KCXN0b3JlLjggW3IzMl0s cjMNCkBMNzY6DQoJaW5jLjY0IHIzMixyMzINCglqbXBfZGlyZWN0IEBMNzQN CkBMNzU6DQoJeG9yLm9yaS4zMiAkMTYscjQwLHIxDQoJam1wX2RpcmVjdF9u eiByMSxATDc0DQoJY21wbGUuNjQgcjM1LHIzMixyMQ0KCWptcF9kaXJlY3Rf eiByMSxATDc5DQoJbG9hZGNvbnMuMCA0OCxyMQ0KCXN0b3JlLjggW3IzMl0s cjENCkBMNzk6DQoJaW5jLjY0IHIzMixyMzINCgljbXBsZS42NCByMzUscjMy LHIxDQoJam1wX2RpcmVjdF96IHIxLEBMODANCglhZGRpLjY0ICQzMyxyNDMs cjENCglsb2FkLjggW3IxXSxyMQ0KCXN0b3JlLjggW3IzMl0scjENCkBMODA6 DQoJaW5jLjY0IHIzMixyMzINCkBMNzQ6DQoJYW5kaS4zMiAkMTYscjM3LHIx DQoJam1wX2RpcmVjdF9ueiByMSxATDgxDQoJbW92ZS4zMiByMzMscjENCglk ZWMuMzIgcjMzLHIzMw0KCWNtcGxlc2kuMzIgJDAscjEscjENCglqbXBfZGly ZWN0X256IHIxLEBMODENCkBMODY6DQoJY21wbGUuNjQgcjM1LHIzMixyMQ0K CWptcF9kaXJlY3RfeiByMSxATDg1DQoJc3RvcmUuOCBbcjMyXSxyNDINCkBM ODU6DQoJaW5jLjY0IHIzMixyMzINCgltb3ZlLjMyIHIzMyxyMQ0KCWRlYy4z MiByMzMscjMzDQoJY21wbGVzaS4zMiAkMCxyMSxyMQ0KCWptcF9kaXJlY3Rf eiByMSxATDg2DQpATDgxOg0KCW1vdmUuMzIgcjM2LHIxDQoJZGVjLjMyIHIz NixyMzYNCgljbXBsZXMuMzIgcjM0LHIxLHIxDQoJam1wX2RpcmVjdF9ueiBy MSxATDEwNg0KCWxvYWRjb25zLjAgNDgscjINCkBMOTE6DQoJY21wbGUuNjQg cjM1LHIzMixyMQ0KCWptcF9kaXJlY3RfeiByMSxATDkwDQoJc3RvcmUuOCBb cjMyXSxyMg0KQEw5MDoNCglpbmMuNjQgcjMyLHIzMg0KCW1vdmUuMzIgcjM2 LHIxDQoJZGVjLjMyIHIzNixyMzYNCgljbXBsZXMuMzIgcjM0LHIxLHIxDQoJ am1wX2RpcmVjdF96IHIxLEBMOTENCkBMMTA2Og0KCW1vdmUuMzIgcjM0LHIx DQoJZGVjLjMyIHIzNCxyMzQNCgljbXBsZXNpLjMyICQwLHIxLHIxDQoJam1w X2RpcmVjdF9ueiByMSxATDEwOA0KCXN1YmkuNjQgNzYscjYyLHIyDQpATDk2 Og0KCWNtcGxlLjY0IHIzNSxyMzIscjENCglqbXBfZGlyZWN0X3ogcjEsQEw5 NQ0KCXdpZGVuLjMyIHIzNCxyMQ0KCWFkZC42NCByMSxyMixyMQ0KCWxvYWQu OCBbcjFdLHIxDQoJc3RvcmUuOCBbcjMyXSxyMQ0KQEw5NToNCglpbmMuNjQg cjMyLHIzMg0KCW1vdmUuMzIgcjM0LHIxDQoJZGVjLjMyIHIzNCxyMzQNCglj bXBsZXNpLjMyICQwLHIxLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMOTYNCkBM MTA4Og0KCW1vdmUuMzIgcjMzLHIxDQoJZGVjLjMyIHIzMyxyMzMNCgljbXBs ZXNpLjMyICQwLHIxLHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDExMA0KCWxv YWRjb25zLjAgMzIscjINCkBMMTAxOg0KCWNtcGxlLjY0IHIzNSxyMzIscjEN CglqbXBfZGlyZWN0X3ogcjEsQEwxMDANCglzdG9yZS44IFtyMzJdLHIyDQpA TDEwMDoNCglpbmMuNjQgcjMyLHIzMg0KCW1vdmUuMzIgcjMzLHIxDQoJZGVj LjMyIHIzMyxyMzMNCgljbXBsZXNpLjMyICQwLHIxLHIxDQoJam1wX2RpcmVj dF96IHIxLEBMMTAxDQpATDExMDoNCgltb3ZlLjY0IHIzMixyMg0KQEw0MjoN Cgltb3ZlLjY0IHIyLHIxDQoJbG9hZCA4LHNwLHIzMg0KCWxvYWQgOCxzcCxy MzMNCglsb2FkIDgsc3AscjM0DQoJbG9hZCA4LHNwLHIzNQ0KCWxvYWQgOCxz cCxyMzYNCglsb2FkIDgsc3AscjM3DQoJbG9hZCA4LHNwLHIzOA0KCWxvYWQg OCxzcCxyMzkNCglsb2FkIDgsc3AscjQwDQoJbG9hZCA4LHNwLHI0MQ0KCWxv YWQgOCxzcCxyNDINCglsb2FkIDgsc3AscjQzDQoJbG9hZCA4LHNwLHI2Mw0K CWptcCByYQ0KQExDMjoNCgkuYXNjaWkgIjxOVUxMPlwwIg0KLmV4dGVybiB2 c25wcmludGYNCnZzbnByaW50ZjoNCglzdG9yZSAkLTgsc3AscjMyDQoJc3Rv cmUgJC04LHNwLHIzMw0KCXN0b3JlICQtOCxzcCxyMzQNCglzdG9yZSAkLTgs c3AscjM1DQoJc3RvcmUgJC04LHNwLHIzNg0KCXN0b3JlICQtOCxzcCxyMzcN CglzdG9yZSAkLTgsc3AscjM4DQoJc3RvcmUgJC04LHNwLHIzOQ0KCXN0b3Jl ICQtOCxzcCxyNjMNCglkbW92ZSByMixyMzgscjMscjM5DQoJc3ViaS42NCAx MixyNjIscjENCglzdG9yZS42NCBbcjFdLHI0DQoJZG1vdmUgcjUscjM3LHIy LHIzMg0KCW1vdmUuMzIgcjMscjEJLy8gemVyb19leHRlbmQNCglhZGQuNjQg cjEscjIscjM0DQoJZGVjLjY0IHIzNCxyMzQNCglkZWMuNjQgcjIscjENCglj bXBsLjY0IHIxLHIzNCxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDExMg0KCWxv YWRjb25zLjY0ICQtMSxyMzQNCgluZWcuMzIgcjIscjM5DQpATDExMjoNCglz dWJpLjY0IDEyLHI2MixyMQ0KCW1vdmUuNjQgcjEscjMNCglsb2FkLjY0IFty MV0scjENCglsb2FkLjggW3IxXSxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDIx MA0KQEwyMDU6DQoJbG9hZC42NCBbcjNdLHIxDQoJbG9hZC44IFtyMV0scjIN Cgl4b3Iub3JpLjggJDM3LHIyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTE3 DQoJY21wbGUuNjQgcjM0LHIzMixyMQ0KCWptcF9kaXJlY3RfeiByMSxATDEx OA0KCXN0b3JlLjggW3IzMl0scjINCkBMMTE4Og0KCWluYy42NCByMzIscjMy DQoJam1wX2RpcmVjdCBATDExNQ0KQEwxMTc6DQoJbW92ZS4zMiByMCxyMzMN CkBMMTE5Og0KCXN1YmkuNjQgMTIscjYyLHIyDQoJbG9hZC42NCBbcjJdLHIx DQoJaW5jLjY0IHIxLHIxDQoJc3RvcmUuNjQgW3IyXSxyMQ0KCWxvYWQuOCBb cjFdLHIxDQoJd2lkZW4uOCByMSxyMQ0KCXN1YmkuMzIgMzIscjEscjINCglj bXBsZWkuMzIgJDE2LHIyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTIwDQoJ bW92ZS4zMiByMixyMQkvLyB6ZXJvX2V4dGVuZA0KCXNoaWZ0bGkuNjQgJDIs cjEscjENCglsb2FkYWRkcmRpICRATDEyNi0uLHIyDQoJYWRkLjY0IHIyLHIx LHIxDQoJbG9hZC4zMiBbcjFdLHIxDQoJd2lkZW4uMzIgcjEscjENCkBTVzEy NjoJbG9hZGFkZHIgcjEscjE7IGptcCByMQ0KCS5hbGlnbiAyDQoJLmFsaWdu IDINCkBMMTI2Og0KCS5sb25nIEBMMTIzLUBTVzEyNg0KCS5sb25nIEBMMTIw LUBTVzEyNg0KCS5sb25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTI0LUBT VzEyNg0KCS5sb25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTIwLUBTVzEy Ng0KCS5sb25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTIwLUBTVzEyNg0K CS5sb25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTIwLUBTVzEyNg0KCS5s b25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTIyLUBTVzEyNg0KCS5sb25n IEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTIxLUBTVzEyNg0KCS5sb25nIEBM MTIwLUBTVzEyNg0KCS5sb25nIEBMMTIwLUBTVzEyNg0KCS5sb25nIEBMMTI1 LUBTVzEyNg0KQEwxMjE6DQoJb3JpLjMyICQxNixyMzMscjMzDQoJam1wX2Rp cmVjdCBATDExOQ0KQEwxMjI6DQoJb3JpLjMyICQ0LHIzMyxyMzMNCglqbXBf ZGlyZWN0IEBMMTE5DQpATDEyMzoNCglvcmkuMzIgJDgscjMzLHIzMw0KCWpt cF9kaXJlY3QgQEwxMTkNCkBMMTI0Og0KCW9yaS4zMiAkMzIscjMzLHIzMw0K CWptcF9kaXJlY3QgQEwxMTkNCkBMMTI1Og0KCW9yaS4zMiAkMSxyMzMscjMz DQoJam1wX2RpcmVjdCBATDExOQ0KQEwxMjA6DQoJbG9hZGNvbnMuMzIgJC0x LHIzNg0KCXN1YmkuNjQgMTIscjYyLHIzDQoJbG9hZC42NCBbcjNdLHIxDQoJ bG9hZC44IFtyMV0scjENCgltb3ZlLjggcjEscjEJLy8gemVyb19leHRlbmQN Cglsb2FkY29ucy42NCAkX2N0eXBlLHIyDQoJYWRkLjY0IHIyLHIxLHIxDQoJ bG9hZC44IFtyMV0scjENCglhbmRpLjggJDQscjEscjENCglqbXBfZGlyZWN0 X3ogcjEsQEwxMjgNCgltb3ZlLjY0IHIzLHIyDQoJbG9hZGNvbnMuNjQgJHNr aXBfYXRvaSxyMQ0KCWptcCByMSxyYQ0KCW1vdmUuMzIgcjEscjM2DQoJam1w X2RpcmVjdCBATDEyOQ0KQEwxMjg6DQoJc3ViaS42NCAxMixyNjIscjMNCgls b2FkLjY0IFtyM10scjINCglsb2FkLjggW3IyXSxyMQ0KCXhvci5vcmkuOCAk NDIscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMTI5DQoJaW5jLjY0IHIy LHIxDQoJc3RvcmUuNjQgW3IzXSxyMQ0KCW1vdmUuNjQgcjM3LHIxDQoJYWRk aS42NCAkOCxyMzcscjM3DQoJbG9hZC4zMiBbcjFdLHIzNg0KCWNtcGxzaS4z MiAkMCxyMzYscjENCglqbXBfZGlyZWN0X3ogcjEsQEwxMjkNCgluZWcuMzIg cjM2LHIzNg0KCW9yaS4zMiAkMTYscjMzLHIzMw0KQEwxMjk6DQoJbG9hZGNv bnMuMzIgJC0xLHI3DQoJc3ViaS42NCAxMixyNjIscjMNCglsb2FkLjY0IFty M10scjINCglsb2FkLjggW3IyXSxyMQ0KCXhvci5vcmkuOCAkNDYscjEscjEN CglqbXBfZGlyZWN0X256IHIxLEBMMTMyDQoJaW5jLjY0IHIyLHIxDQoJc3Rv cmUuNjQgW3IzXSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJbW92ZS44IHIxLHIx CS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlwZSxyMg0KCWFk ZC42NCByMixyMSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJYW5kaS44ICQ0LHIx LHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTMzDQoJbW92ZS42NCByMyxyMg0K CWxvYWRjb25zLjY0ICRza2lwX2F0b2kscjENCglqbXAgcjEscmENCgltb3Zl LjMyIHIxLHI3DQoJam1wX2RpcmVjdCBATDEzNA0KQEwxMzM6DQoJc3ViaS42 NCAxMixyNjIscjMNCglsb2FkLjY0IFtyM10scjINCglsb2FkLjggW3IyXSxy MQ0KCXhvci5vcmkuOCAkNDIscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBM MTM0DQoJaW5jLjY0IHIyLHIxDQoJc3RvcmUuNjQgW3IzXSxyMQ0KCW1vdmUu NjQgcjM3LHIxDQoJYWRkaS42NCAkOCxyMzcscjM3DQoJbG9hZC4zMiBbcjFd LHI3DQpATDEzNDoNCgljbXBsc2kuMzIgJDAscjcscjENCglueG9yLmFuZGku MzIgJDAscjEscjENCgljbW92ZS4zMiByMSxyMCxyNw0KQEwxMzI6DQoJbG9h ZGNvbnMuMzIgJC0xLHI0DQoJc3ViaS42NCAxMixyNjIscjENCglsb2FkLjY0 IFtyMV0scjENCglsb2FkLjggW3IxXSxyMg0KCXhvci5vcmkuOCAkMTA0LHIy LHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTM4DQoJeG9yLm9yaS44ICQxMDgs cjIscjENCglqbXBfZGlyZWN0X3ogcjEsQEwxMzgNCgl4b3Iub3JpLjggJDc2 LHIyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTM4DQoJeG9yLm9yaS44ICQ5 MCxyMixyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwxMzcNCkBMMTM4Og0KCXN1 YmkuNjQgMTIscjYyLHIzDQoJbG9hZC42NCBbcjNdLHIxDQoJbG9hZC44IFty MV0scjINCgl3aWRlbi44IHIyLHI0DQoJaW5jLjY0IHIxLHIyDQoJc3RvcmUu NjQgW3IzXSxyMg0KCXhvci5vcmkuMzIgJDEwOCxyNCxyMQ0KCWptcF9kaXJl Y3RfbnogcjEsQEwxMzcNCglsb2FkLjggW3IyXSxyMQ0KCXhvci5vci44IHI0 LHIxLHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDEzNw0KCWxvYWRjb25zLjMy ICQ3NixyNA0KCWluYy42NCByMixyMQ0KCXN0b3JlLjY0IFtyM10scjENCkBM MTM3Og0KCWxvYWRjb25zLjMyICQxMCxyNQ0KCXN1YmkuNjQgMTIscjYyLHIx DQoJbG9hZC42NCBbcjFdLHIxDQoJbG9hZC44IFtyMV0scjENCgl3aWRlbi44 IHIxLHIxDQoJc3ViaS4zMiAzNyxyMSxyMg0KCWNtcGxlaS4zMiAkODMscjIs cjENCglqbXBfZGlyZWN0X3ogcjEsQEwxODgNCgltb3ZlLjMyIHIyLHIxCS8v IHplcm9fZXh0ZW5kDQoJc2hpZnRsaS42NCAkMixyMSxyMQ0KCWxvYWRhZGRy ZGkgJEBMMTkzLS4scjINCglhZGQuNjQgcjIscjEscjENCglsb2FkLjMyIFty MV0scjENCgl3aWRlbi4zMiByMSxyMQ0KQFNXMTkzOglsb2FkYWRkciByMSxy MTsgam1wIHIxDQoJLmFsaWduIDINCgkuYWxpZ24gMg0KQEwxOTM6DQoJLmxv bmcgQEwxODAtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNX MTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkz DQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJ LmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxv bmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNX MTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkz DQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJ LmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxv bmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNX MTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkz DQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJ LmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxv bmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODMt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNX MTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkz DQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJ LmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxv bmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxNDEtQFNXMTkzDQoJLmxvbmcgQEwxODYtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODYtQFNX MTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkz DQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJ LmxvbmcgQEwxNzUtQFNXMTkzDQoJLmxvbmcgQEwxODItQFNXMTkzDQoJLmxv bmcgQEwxNzMtQFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcg QEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxNTQtQFNXMTkzDQoJLmxvbmcgQEwx ODgtQFNXMTkzDQoJLmxvbmcgQEwxNDAtQFNXMTkzDQoJLmxvbmcgQEwxODgt QFNXMTkzDQoJLmxvbmcgQEwxODgtQFNXMTkzDQoJLmxvbmcgQEwxODQtQFNX MTkzDQpATDE0MToNCglhbmRpLjMyICQxNixyMzMscjENCglqbXBfZGlyZWN0 X256IHIxLEBMMTQyDQoJZGVjLjMyIHIzNixyMzYNCgljbXBsZXNpLjMyICQw LHIzNixyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwxNDINCglsb2FkY29ucy4w IDMyLHIyDQpATDE0NzoNCgljbXBsZS42NCByMzQscjMyLHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMMTQ2DQoJc3RvcmUuOCBbcjMyXSxyMg0KQEwxNDY6DQoJ aW5jLjY0IHIzMixyMzINCglkZWMuMzIgcjM2LHIzNg0KCWNtcGxlc2kuMzIg JDAscjM2LHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTQ3DQpATDE0MjoNCglt b3ZlLjY0IHIzNyxyMQ0KCWFkZGkuNjQgJDgscjM3LHIzNw0KCWxvYWQuOCBb cjFdLHIyDQoJY21wbGUuNjQgcjM0LHIzMixyMQ0KCWptcF9kaXJlY3RfeiBy MSxATDE0OA0KCXN0b3JlLjggW3IzMl0scjINCkBMMTQ4Og0KCWluYy42NCBy MzIscjMyDQoJZGVjLjMyIHIzNixyMzYNCgljbXBsZXNpLjMyICQwLHIzNixy MQ0KCWptcF9kaXJlY3RfbnogcjEsQEwxMTUNCglsb2FkY29ucy4wIDMyLHIy DQpATDE1MzoNCgljbXBsZS42NCByMzQscjMyLHIxDQoJam1wX2RpcmVjdF96 IHIxLEBMMTUyDQoJc3RvcmUuOCBbcjMyXSxyMg0KQEwxNTI6DQoJaW5jLjY0 IHIzMixyMzINCglkZWMuMzIgcjM2LHIzNg0KCWNtcGxlc2kuMzIgJDAscjM2 LHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDExNQ0KCWptcF9kaXJlY3QgQEwx NTMNCkBMMTU0Og0KCW1vdmUuNjQgcjM3LHIxDQoJYWRkaS42NCAkOCxyMzcs cjM3DQoJbG9hZC42NCBbcjFdLHIzNQ0KCWxvYWRjb25zLjY0ICRATEMyLHIx DQoJY21vdmUuNjQgcjM1LHIzNSxyMQ0KCWRtb3ZlIHIxLHIzNSxyMSxyMg0K CW1vdmUuMzIgcjcscjMNCglsb2FkY29ucy42NCAkc3RybmxlbixyMQ0KCWpt cCByMSxyYQ0KCW1vdmUuMzIgcjEscjMNCglhbmRpLjMyICQxNixyMzMscjEN CglqbXBfZGlyZWN0X256IHIxLEBMMTU2DQoJbW92ZS4zMiByMzYscjENCglk ZWMuMzIgcjM2LHIzNg0KCWNtcGxlcy4zMiByMyxyMSxyMQ0KCWptcF9kaXJl Y3RfbnogcjEsQEwxNTYNCglsb2FkY29ucy4wIDMyLHIyDQpATDE2MToNCglj bXBsZS42NCByMzQscjMyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTYwDQoJ c3RvcmUuOCBbcjMyXSxyMg0KQEwxNjA6DQoJaW5jLjY0IHIzMixyMzINCglt b3ZlLjMyIHIzNixyMQ0KCWRlYy4zMiByMzYscjM2DQoJY21wbGVzLjMyIHIz LHIxLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMTYxDQpATDE1NjoNCgltb3Zl LjMyIHIwLHIyDQoJY21wbHMuMzIgcjMscjIscjENCglqbXBfZGlyZWN0X3og cjEsQEwyMTUNCkBMMTY3Og0KCWNtcGxlLjY0IHIzNCxyMzIscjENCglqbXBf ZGlyZWN0X3ogcjEsQEwxNjYNCglsb2FkLjggW3IzNV0scjENCglzdG9yZS44 IFtyMzJdLHIxDQpATDE2NjoNCglpbmMuNjQgcjMyLHIzMg0KCWluYy42NCBy MzUscjM1DQoJaW5jLjMyIHIyLHIyDQoJY21wbHMuMzIgcjMscjIscjENCglq bXBfZGlyZWN0X256IHIxLEBMMTY3DQpATDIxNToNCgltb3ZlLjMyIHIzNixy MQ0KCWRlYy4zMiByMzYscjM2DQoJY21wbGVzLjMyIHIzLHIxLHIxDQoJam1w X2RpcmVjdF9ueiByMSxATDExNQ0KCWxvYWRjb25zLjAgMzIscjINCkBMMTcy Og0KCWNtcGxlLjY0IHIzNCxyMzIscjENCglqbXBfZGlyZWN0X3ogcjEsQEwx NzENCglzdG9yZS44IFtyMzJdLHIyDQpATDE3MToNCglpbmMuNjQgcjMyLHIz Mg0KCW1vdmUuMzIgcjM2LHIxDQoJZGVjLjMyIHIzNixyMzYNCgljbXBsZXMu MzIgcjMscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMTE1DQoJam1wX2Rp cmVjdCBATDE3Mg0KQEwxNzM6DQoJeG9yLm9yaS4zMiAkLTEscjM2LHIxDQoJ am1wX2RpcmVjdF9ueiByMSxATDE3NA0KCWJzZXRpLjMyICQ0LHIwLHIzNg0K CW9yaS4zMiAkMSxyMzMscjMzDQpATDE3NDoNCgltb3ZlLjY0IHIzNyxyMQ0K CWFkZGkuNjQgJDgscjM3LHIzNw0KCWRtb3ZlIHIzMixyMixyMzQscjMNCgls b2FkLjY0IFtyMV0scjQNCglic2V0aS4zMiAkNCxyMCxyNQ0KCWRtb3ZlIHIz NixyNixyMzMscjgNCglsb2FkY29ucy42NCAkbnVtYmVyLHIxDQoJam1wIHIx LHJhDQoJbW92ZS42NCByMSxyMzINCglqbXBfZGlyZWN0IEBMMTE1DQpATDE3 NToNCgl4b3Iub3JpLjMyICQxMDgscjQscjENCglqbXBfZGlyZWN0X256IHIx LEBMMTc2DQoJbW92ZS42NCByMzcscjENCglhZGRpLjY0ICQ4LHIzNyxyMzcN Cglsb2FkLjY0IFtyMV0scjINCglzdWIuNjQgcjM4LHIzMixyMQ0KCXN0b3Jl LjY0IFtyMl0scjENCglqbXBfZGlyZWN0IEBMMTE1DQpATDE3NjoNCgl4b3Iu b3JpLjMyICQ5MCxyNCxyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwxNzgNCglt b3ZlLjY0IHIzNyxyMQ0KCWFkZGkuNjQgJDgscjM3LHIzNw0KCWxvYWQuNjQg W3IxXSxyMg0KCXN1Yi4zMiByMzgscjMyLHIxDQoJc3RvcmUuMzIgW3IyXSxy MQ0KCWptcF9kaXJlY3QgQEwxMTUNCkBMMTc4Og0KCW1vdmUuNjQgcjM3LHIx DQoJYWRkaS42NCAkOCxyMzcscjM3DQoJbG9hZC42NCBbcjFdLHIyDQoJc3Vi LjMyIHIzOCxyMzIscjENCglzdG9yZS4zMiBbcjJdLHIxDQoJam1wX2RpcmVj dCBATDExNQ0KQEwxODA6DQoJY21wbGUuNjQgcjM0LHIzMixyMQ0KCWptcF9k aXJlY3RfeiByMSxATDE4MQ0KCWxvYWRjb25zLjAgMzcscjENCglzdG9yZS44 IFtyMzJdLHIxDQpATDE4MToNCglpbmMuNjQgcjMyLHIzMg0KCWptcF9kaXJl Y3QgQEwxMTUNCkBMMTgyOg0KCWJzZXRpLjMyICQzLHIwLHI1DQoJam1wX2Rp cmVjdCBATDE0MA0KQEwxODM6DQoJb3JpLjMyICQ2NCxyMzMscjMzDQpATDE4 NDoNCglic2V0aS4zMiAkNCxyMCxyNQ0KCWptcF9kaXJlY3QgQEwxNDANCkBM MTg2Og0KCW9yaS4zMiAkMixyMzMscjMzDQoJam1wX2RpcmVjdCBATDE0MA0K QEwxODg6DQoJY21wbGUuNjQgcjM0LHIzMixyMQ0KCWptcF9kaXJlY3RfeiBy MSxATDE4OQ0KCWxvYWRjb25zLjAgMzcscjENCglzdG9yZS44IFtyMzJdLHIx DQpATDE4OToNCglpbmMuNjQgcjMyLHIzMg0KCXN1YmkuNjQgMTIscjYyLHIx DQoJbG9hZC42NCBbcjFdLHIxDQoJbG9hZC44IFtyMV0scjINCglqbXBfZGly ZWN0X3ogcjIsQEwxOTANCgljbXBsZS42NCByMzQscjMyLHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMMTkxDQoJc3RvcmUuOCBbcjMyXSxyMg0KQEwxOTE6DQoJ aW5jLjY0IHIzMixyMzINCglqbXBfZGlyZWN0IEBMMTE1DQpATDE5MDoNCglz dWJpLjY0IDEyLHI2MixyMg0KCWxvYWQuNjQgW3IyXSxyMQ0KCWRlYy42NCBy MSxyMQ0KCXN0b3JlLjY0IFtyMl0scjENCglqbXBfZGlyZWN0IEBMMTE1DQpA TDE0MDoNCgl4b3Iub3JpLjMyICQ3NixyNCxyMQ0KCWptcF9kaXJlY3Rfbnog cjEsQEwxOTQNCgltb3ZlLjY0IHIzNyxyMQ0KCWFkZGkuNjQgJDgscjM3LHIz Nw0KCWxvYWQuNjQgW3IxXSxyNA0KCWptcF9kaXJlY3QgQEwxOTUNCkBMMTk0 Og0KCXhvci5vcmkuMzIgJDEwOCxyNCxyMQ0KCWptcF9kaXJlY3RfbnogcjEs QEwxOTYNCgltb3ZlLjY0IHIzNyxyMQ0KCWFkZGkuNjQgJDgscjM3LHIzNw0K CWxvYWQuNjQgW3IxXSxyNA0KCWptcF9kaXJlY3QgQEwxOTUNCkBMMTk2Og0K CXhvci5vcmkuMzIgJDkwLHI0LHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDE5 OQ0KCW1vdmUuNjQgcjM3LHIxDQoJYWRkaS42NCAkOCxyMzcscjM3DQoJbG9h ZC4zMiBbcjFdLHIxDQoJbW92ZS4zMiByMSxyNAkvLyB6ZXJvX2V4dGVuZA0K CWptcF9kaXJlY3QgQEwxOTUNCkBMMTk5Og0KCXhvci5vcmkuMzIgJDEwNCxy NCxyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwyMDENCgltb3ZlLjY0IHIzNyxy MQ0KCWFkZGkuNjQgJDgscjM3LHIzNw0KCWxvYWQuMTYgW3IxXSxyMQ0KCW1v dmUuMTYgcjEscjQJLy8gemVyb19leHRlbmQNCglhbmRpLjMyICQyLHIzMyxy MQ0KCWptcF9kaXJlY3RfeiByMSxATDE5NQ0KCXdpZGVuLjE2IHI0LHI0DQoJ am1wX2RpcmVjdCBATDE5NQ0KQEwyMDE6DQoJbW92ZS42NCByMzcscjENCglh ZGRpLjY0ICQ4LHIzNyxyMzcNCglsb2FkLjMyIFtyMV0scjENCgltb3ZlLjMy IHIxLHI0CS8vIHplcm9fZXh0ZW5kDQoJYW5kaS4zMiAkMixyMzMscjINCgl3 aWRlbi4zMiByNCxyMQ0KCWNtb3ZlLjY0IHIyLHIxLHI0DQpATDE5NToNCglk bW92ZSByMzIscjIscjM0LHIzDQoJZG1vdmUgcjM2LHI2LHIzMyxyOA0KCWxv YWRjb25zLjY0ICRudW1iZXIscjENCglqbXAgcjEscmENCgltb3ZlLjY0IHIx LHIzMg0KQEwxMTU6DQoJc3ViaS42NCAxMixyNjIscjENCglsb2FkLjY0IFty MV0scjINCglpbmMuNjQgcjIscjINCglzdG9yZS42NCBbcjFdLHIyDQoJbW92 ZS42NCByMSxyMw0KCWxvYWQuOCBbcjJdLHIxDQoJam1wX2RpcmVjdF9ueiBy MSxATDIwNQ0KQEwyMTA6DQoJY21wbGUuNjQgcjM0LHIzMixyMQ0KCWptcF9k aXJlY3RfeiByMSxATDIwNg0KCWxvYWRjb25zLjAgMCxyMQ0KCXN0b3JlLjgg W3IzMl0scjENCglqbXBfZGlyZWN0IEBMMjA3DQpATDIwNjoNCglqbXBfZGly ZWN0X3ogcjM5LEBMMjA3DQoJbG9hZGNvbnMuMCAwLHIxDQoJc3RvcmUuOCBb cjM0XSxyMQ0KQEwyMDc6DQoJc3ViLjMyIHIzOCxyMzIscjENCglsb2FkIDgs c3AscjMyDQoJbG9hZCA4LHNwLHIzMw0KCWxvYWQgOCxzcCxyMzQNCglsb2Fk IDgsc3AscjM1DQoJbG9hZCA4LHNwLHIzNg0KCWxvYWQgOCxzcCxyMzcNCgls b2FkIDgsc3AscjM4DQoJbG9hZCA4LHNwLHIzOQ0KCWxvYWQgOCxzcCxyNjMN CglqbXAgcmENCi5leHRlcm4gc25wcmludGYNCnNucHJpbnRmOg0KCXN0b3Jl ICQtOCxzcCxyNjMNCglhZGRpLjY0ICQ0LHI2MixyMQ0KCWxvYWQuNjQgW3Ix XSxyNA0KCWFkZGkuNjQgJDEyLHI2MixyNQ0KCXN1YmkuNjQgMTIscjYyLHIx DQoJc3RvcmUuNjQgW3IxXSxyNQ0KCWxvYWRjb25zLjY0ICR2c25wcmludGYs cjENCglqbXAgcjEscmENCglsb2FkIDgsc3AscjYzDQoJam1wIHJhDQouZXh0 ZXJuIHZzcHJpbnRmDQp2c3ByaW50ZjoNCglzdG9yZSAkLTgsc3AscjYzDQoJ ZG1vdmUgcjMscjEscjQscjUNCglsb2FkY29ucy4zMiAkLTEscjMNCgltb3Zl LjY0IHIxLHI0DQoJbG9hZGNvbnMuNjQgJHZzbnByaW50ZixyMQ0KCWptcCBy MSxyYQ0KCWxvYWQgOCxzcCxyNjMNCglqbXAgcmENCi5leHRlcm4gc3ByaW50 Zg0Kc3ByaW50ZjoNCglzdG9yZSAkLTgsc3AscjYzDQoJYWRkaS42NCAkNCxy NjIscjENCglsb2FkLjY0IFtyMV0scjMNCglhZGRpLjY0ICQxMixyNjIscjQN CglzdWJpLjY0IDEyLHI2MixyMQ0KCXN0b3JlLjY0IFtyMV0scjQNCglsb2Fk Y29ucy42NCAkdnNwcmludGYscjENCglqbXAgcjEscmENCglsb2FkIDgsc3As cjYzDQoJam1wIHJhDQouZXh0ZXJuIHZzc2NhbmYNCnZzc2NhbmY6DQoJc3Rv cmUgJC04LHNwLHIzMg0KCXN0b3JlICQtOCxzcCxyMzMNCglzdG9yZSAkLTgs c3AscjM0DQoJc3RvcmUgJC04LHNwLHIzNQ0KCXN0b3JlICQtOCxzcCxyMzYN CglzdG9yZSAkLTgsc3AscjM3DQoJc3RvcmUgJC04LHNwLHI2Mw0KCW1vdmUu NjQgcjIscjM3DQoJc3ViaS42NCAxMixyNjIscjENCgltb3ZlLjY0IHIxLHIy DQoJc3RvcmUuNjQgW3IxXSxyMw0KCWRtb3ZlIHI0LHIzNCxyMzcscjMzDQoJ bW92ZS4zMiByMCxyMzYNCglsb2FkY29ucy4zMiAkLTEscjM1DQoJbG9hZC44 IFtyM10scjENCglqbXBfZGlyZWN0X3ogcjEsQEwyMjINCglsb2FkLjggW3Iz N10scjENCglqbXBfZGlyZWN0X3ogcjEsQEwyMjINCkBMMzA2Og0KCW1vdmUu NjQgcjIscjMNCglsb2FkLjY0IFtyMl0scjENCglsb2FkLjggW3IxXSxyMQ0K CW1vdmUuOCByMSxyMQkvLyB6ZXJvX2V4dGVuZA0KCWxvYWRjb25zLjY0ICRf Y3R5cGUscjINCgltb3ZlLjY0IHIyLHI0DQoJYWRkLjY0IHIyLHIxLHIxDQoJ bG9hZC44IFtyMV0scjENCglhbmRpLjggJDMyLHIxLHIxDQoJam1wX2RpcmVj dF96IHIxLEBMMjI1DQpATDIyOToNCglsb2FkLjY0IFtyM10scjENCglpbmMu NjQgcjEscjENCglzdG9yZS42NCBbcjNdLHIxDQoJbG9hZC44IFtyMV0scjEN Cgltb3ZlLjggcjEscjEJLy8gemVyb19leHRlbmQNCglhZGQuNjQgcjQscjEs cjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAkMzIscjEscjENCglqbXBf ZGlyZWN0X256IHIxLEBMMjI5DQoJbG9hZC44IFtyMzNdLHIxDQoJbW92ZS44 IHIxLHIxCS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlwZSxy Mg0KCW1vdmUuNjQgcjIscjMNCglhZGQuNjQgcjIscjEscjENCglsb2FkLjgg W3IxXSxyMQ0KCWFuZGkuOCAkMzIscjEscjENCglqbXBfZGlyZWN0X3ogcjEs QEwyMjUNCkBMMjMzOg0KCWluYy42NCByMzMscjMzDQoJbG9hZC44IFtyMzNd LHIxDQoJbW92ZS44IHIxLHIxCS8vIHplcm9fZXh0ZW5kDQoJYWRkLjY0IHIz LHIxLHIxDQoJbG9hZC44IFtyMV0scjENCglhbmRpLjggJDMyLHIxLHIxDQoJ am1wX2RpcmVjdF9ueiByMSxATDIzMw0KQEwyMjU6DQoJc3ViaS42NCAxMixy NjIscjUNCglsb2FkLjY0IFtyNV0scjQNCglsb2FkLjggW3I0XSxyMw0KCXhv ci5vcmkuOCAkMzcscjMscjENCglqbXBfZGlyZWN0X3ogcjEsQEwyMzQNCglq bXBfZGlyZWN0X3ogcjMsQEwyMzQNCglsb2FkLjggW3IzM10scjINCglpbmMu NjQgcjMzLHIzMw0KCWluYy42NCByNCxyMQ0KCXN0b3JlLjY0IFtyNV0scjEN Cgl4b3Iub3IuOCByMixyMyxyMg0KCWptcF9kaXJlY3RfbnogcjIsQEwyMjIN CglqbXBfZGlyZWN0IEBMMjIxDQpATDIzNDoNCglzdWJpLjY0IDEyLHI2Mixy Mw0KCW1vdmUuNjQgcjMscjQNCglsb2FkLjY0IFtyM10scjINCglsb2FkLjgg W3IyXSxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDIyMg0KCWluYy42NCByMixy MQ0KCXN0b3JlLjY0IFtyM10scjENCglsb2FkLjggW3IxXSxyMg0KCXhvci5v cmkuOCAkNDIscjIscjENCglqbXBfZGlyZWN0X256IHIxLEBMMjM3DQoJbW92 ZS44IHIyLHIyCS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlw ZSxyNQ0KCWxvYWRjb25zLjY0ICRfY3R5cGUrNDIscjENCglsb2FkLjggW3Ix XSxyMQ0KCWFuZGkuOCAkMzIscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBM MjM5DQoJam1wX2RpcmVjdF96IHIyLEBMMjM5DQpATDI0MjoNCglsb2FkLjY0 IFtyNF0scjENCglpbmMuNjQgcjEscjENCglzdG9yZS42NCBbcjRdLHIxDQoJ bG9hZC44IFtyMV0scjMNCgltb3ZlLjggcjMscjEJLy8gemVyb19leHRlbmQN CglhZGQuNjQgcjUscjEscjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAk MzIscjEscjENCglqbXBfZGlyZWN0X256IHIxLEBMMjM5DQoJam1wX2RpcmVj dF9ueiByMyxATDI0Mg0KQEwyMzk6DQoJbG9hZC44IFtyMzNdLHIzDQoJbW92 ZS44IHIzLHIxCS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlw ZSxyMg0KCWFkZC42NCByMixyMSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJYW5k aS44ICQzMixyMSxyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwyMjENCglqbXBf ZGlyZWN0X3ogcjMsQEwyMjENCgltb3ZlLjY0IHIyLHIzDQpATDI0NzoNCglp bmMuNjQgcjMzLHIzMw0KCWxvYWQuOCBbcjMzXSxyMg0KCW1vdmUuOCByMixy MQkvLyB6ZXJvX2V4dGVuZA0KCWFkZC42NCByMyxyMSxyMQ0KCWxvYWQuOCBb cjFdLHIxDQoJYW5kaS44ICQzMixyMSxyMQ0KCWptcF9kaXJlY3RfbnogcjEs QEwyMjENCglqbXBfZGlyZWN0X256IHIyLEBMMjQ3DQoJam1wX2RpcmVjdCBA TDIyMQ0KQEwyMzc6DQoJc3ViaS42NCAxMixyNjIscjMNCglsb2FkLjY0IFty M10scjENCglsb2FkLjggW3IxXSxyMQ0KCW1vdmUuOCByMSxyMQkvLyB6ZXJv X2V4dGVuZA0KCWxvYWRjb25zLjY0ICRfY3R5cGUscjINCglhZGQuNjQgcjIs cjEscjENCglsb2FkLjggW3IxXSxyMQ0KCWFuZGkuOCAkNCxyMSxyMQ0KCWpt cF9kaXJlY3RfeiByMSxATDI0OA0KCW1vdmUuNjQgcjMscjINCglsb2FkY29u cy42NCAkc2tpcF9hdG9pLHIxDQoJam1wIHIxLHJhDQoJbW92ZS4zMiByMSxy MzUNCkBMMjQ4Og0KCWxvYWRjb25zLjMyICQtMSxyMw0KCXN1YmkuNjQgMTIs cjYyLHIxDQoJbG9hZC42NCBbcjFdLHIxDQoJbG9hZC44IFtyMV0scjINCgl4 b3Iub3JpLjggJDEwNCxyMixyMQ0KCWptcF9kaXJlY3RfeiByMSxATDI1MA0K CXhvci5vcmkuOCAkMTA4LHIyLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMjUw DQoJeG9yLm9yaS44ICQ3NixyMixyMQ0KCWptcF9kaXJlY3RfeiByMSxATDI1 MA0KCXhvci5vcmkuOCAkOTAscjIscjENCglqbXBfZGlyZWN0X256IHIxLEBM MjQ5DQpATDI1MDoNCglzdWJpLjY0IDEyLHI2MixyMQ0KCWxvYWQuNjQgW3Ix XSxyMg0KCWxvYWQuOCBbcjJdLHIzDQoJd2lkZW4uOCByMyxyMw0KCWluYy42 NCByMixyMg0KCXN0b3JlLjY0IFtyMV0scjINCkBMMjQ5Og0KCWxvYWRjb25z LjMyICQxMCxyNA0KCW1vdmUuMzIgcjAscjcNCglzdWJpLjY0IDEyLHI2Mixy Ng0KCWxvYWQuNjQgW3I2XSxyNQ0KCWxvYWQuOCBbcjVdLHIyDQoJam1wX2Rp cmVjdF96IHIyLEBMMjIyDQoJbG9hZC44IFtyMzNdLHIxDQoJam1wX2RpcmVj dF96IHIxLEBMMjIyDQoJd2lkZW4uOCByMixyMQ0KCXN1YmkuMzIgMzcscjEs cjINCglpbmMuNjQgcjUscjENCglzdG9yZS42NCBbcjZdLHIxDQoJY21wbGVp LjMyICQ4MyxyMixyMQ0KCWptcF9kaXJlY3RfeiByMSxATDI4MQ0KCW1vdmUu MzIgcjIscjEJLy8gemVyb19leHRlbmQNCglzaGlmdGxpLjY0ICQyLHIxLHIx DQoJbG9hZGFkZHJkaSAkQEwyODItLixyMg0KCWFkZC42NCByMixyMSxyMQ0K CWxvYWQuMzIgW3IxXSxyMQ0KCXdpZGVuLjMyIHIxLHIxDQpAU1cyODI6CWxv YWRhZGRyIHIxLHIxOyBqbXAgcjENCgkuYWxpZ24gMg0KCS5hbGlnbiAyDQpA TDI4MjoNCgkubG9uZyBATDI3OS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgku bG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBA TDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4 MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1A U1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgku bG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBA TDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4 MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1A U1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgku bG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBA TDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4 MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1A U1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgku bG9uZyBATDI3NS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBA TDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4 MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1A U1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI1NC1AU1cyODINCgkubG9uZyBATDI3Ny1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgku bG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI3Ny1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBA TDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4 MS1AU1cyODINCgkubG9uZyBATDI3Mi1AU1cyODINCgkubG9uZyBATDI3My1A U1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cy ODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI2MS1AU1cyODIN CgkubG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI1My1AU1cyODINCgku bG9uZyBATDI4MS1AU1cyODINCgkubG9uZyBATDI4MS1AU1cyODINCgkubG9u ZyBATDI3NS1AU1cyODINCkBMMjU0Og0KCW1vdmUuNjQgcjM0LHIxDQoJYWRk aS42NCAkOCxyMzQscjM0DQoJbG9hZC42NCBbcjFdLHIzDQoJeG9yLm9yaS4z MiAkLTEscjM1LHIyDQoJYnNldGkuMzIgJDAscjAscjENCgljbW92ZS4zMiBy MixyMzUscjENCgltb3ZlLjMyIHIxLHIzNQ0KQEwyNTY6DQoJbG9hZC44IFty MzNdLHIxDQoJc3RvcmUuOCBbcjNdLHIxDQoJaW5jLjY0IHIzMyxyMzMNCglp bmMuNjQgcjMscjMNCgltb3ZlLjMyIHIzNSxyMQ0KCWRlYy4zMiByMzUscjM1 DQoJY21wbGVzaS4zMiAkMCxyMSxyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwy NTcNCglsb2FkLjggW3IzM10scjENCglqbXBfZGlyZWN0X256IHIxLEBMMjU2 DQpATDI1NzoNCglpbmMuMzIgcjM2LHIzNg0KCWptcF9kaXJlY3QgQEwyMjEN CkBMMjYxOg0KCW1vdmUuNjQgcjM0LHIxDQoJYWRkaS42NCAkOCxyMzQscjM0 DQoJbG9hZC42NCBbcjFdLHI0DQoJeG9yLm9yaS4zMiAkLTEscjM1LHIyDQoJ YmNscm5pLjMyICQzMSxyMCxyMQ0KCWNtb3ZlLjMyIHIyLHIzNSxyMQ0KCW1v dmUuMzIgcjEscjM1DQoJbG9hZC44IFtyMzNdLHIxDQoJbW92ZS44IHIxLHIx CS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlwZSxyMg0KCW1v dmUuNjQgcjIscjMNCglhZGQuNjQgcjIscjEscjENCglsb2FkLjggW3IxXSxy MQ0KCWFuZGkuOCAkMzIscjEscjENCglqbXBfZGlyZWN0X3ogcjEsQEwzMTQN CkBMMjY2Og0KCWluYy42NCByMzMscjMzDQoJbG9hZC44IFtyMzNdLHIxDQoJ bW92ZS44IHIxLHIxCS8vIHplcm9fZXh0ZW5kDQoJYWRkLjY0IHIzLHIxLHIx DQoJbG9hZC44IFtyMV0scjENCglhbmRpLjggJDMyLHIxLHIxDQoJam1wX2Rp cmVjdF9ueiByMSxATDI2Ng0KQEwzMTQ6DQoJbG9hZC44IFtyMzNdLHIxDQoJ bW92ZS44IHIxLHIzDQoJam1wX2RpcmVjdF96IHIxLEBMMjY4DQoJbW92ZS44 IHIxLHIxCS8vIHplcm9fZXh0ZW5kDQoJbG9hZGNvbnMuNjQgJF9jdHlwZSxy Mg0KCW1vdmUuNjQgcjIscjUNCglhZGQuNjQgcjIscjEscjENCglsb2FkLjgg W3IxXSxyMQ0KCWFuZGkuOCAkMzIscjEscjENCglqbXBfZGlyZWN0X256IHIx LEBMMjY4DQoJZGVjLjMyIHIzNSxyMzUNCgl4b3Iub3JpLjMyICQtMSxyMzUs cjENCglqbXBfZGlyZWN0X3ogcjEsQEwyNjgNCglsb2FkY29ucy4zMiAkLTEs cjINCkBMMjcxOg0KCXN0b3JlLjggW3I0XSxyMw0KCWluYy42NCByMzMscjMz DQoJaW5jLjY0IHI0LHI0DQoJbG9hZC44IFtyMzNdLHIzDQoJam1wX2RpcmVj dF96IHIzLEBMMjY4DQoJbW92ZS44IHIzLHIxCS8vIHplcm9fZXh0ZW5kDQoJ YWRkLjY0IHI1LHIxLHIxDQoJbG9hZC44IFtyMV0scjENCglhbmRpLjggJDMy LHIxLHIxDQoJam1wX2RpcmVjdF9ueiByMSxATDI2OA0KCWRlYy4zMiByMzUs cjM1DQoJeG9yLm9yLjMyIHIyLHIzNSxyMQ0KCWptcF9kaXJlY3RfbnogcjEs QEwyNzENCkBMMjY4Og0KCWxvYWRjb25zLjAgMCxyMQ0KCXN0b3JlLjggW3I0 XSxyMQ0KCWluYy4zMiByMzYscjM2DQoJam1wX2RpcmVjdCBATDIyMQ0KQEwy NzI6DQoJbW92ZS42NCByMzQscjENCglhZGRpLjY0ICQ4LHIzNCxyMzQNCgls b2FkLjY0IFtyMV0scjINCglzdWIuMzIgcjM3LHIzMyxyMQ0KCXN0b3JlLjMy IFtyMl0scjENCglqbXBfZGlyZWN0IEBMMjIxDQpATDI3MzoNCglic2V0aS4z MiAkMyxyMCxyNA0KCWptcF9kaXJlY3QgQEwyNTMNCkBMMjc1Og0KCWJzZXRp LjMyICQ0LHIwLHI0DQoJam1wX2RpcmVjdCBATDI1Mw0KQEwyNzc6DQoJYnNl dGkuMzIgJDAscjAscjcNCglqbXBfZGlyZWN0IEBMMjUzDQpATDI3OToNCgls b2FkLjggW3IzM10scjENCglpbmMuNjQgcjMzLHIzMw0KCXhvci5vcmkuOCAk MzcscjEscjENCgltb3ZlLjMyIHIzNixyMg0KCWptcF9kaXJlY3RfbnogcjEs QEwyMjANCglqbXBfZGlyZWN0IEBMMjIxDQpATDI4MToNCgltb3ZlLjMyIHIz NixyMg0KCWptcF9kaXJlY3QgQEwyMjANCkBMMjUzOg0KCWxvYWQuOCBbcjMz XSxyMQ0KCW1vdmUuOCByMSxyMQkvLyB6ZXJvX2V4dGVuZA0KCWxvYWRjb25z LjY0ICRfY3R5cGUscjINCgltb3ZlLjY0IHIyLHI1DQoJYWRkLjY0IHIyLHIx LHIxDQoJbG9hZC44IFtyMV0scjENCglhbmRpLjggJDMyLHIxLHIxDQoJam1w X2RpcmVjdF96IHIxLEBMMzE3DQpATDI4NjoNCglpbmMuNjQgcjMzLHIzMw0K CWxvYWQuOCBbcjMzXSxyMQ0KCW1vdmUuOCByMSxyMQkvLyB6ZXJvX2V4dGVu ZA0KCWFkZC42NCByNSxyMSxyMQ0KCWxvYWQuOCBbcjFdLHIxDQoJYW5kaS44 ICQzMixyMSxyMQ0KCWptcF9kaXJlY3RfbnogcjEsQEwyODYNCkBMMzE3Og0K CWxvYWQuOCBbcjMzXSxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDIyMg0KCW1v dmUuOCByMSxyMQkvLyB6ZXJvX2V4dGVuZA0KCWxvYWRjb25zLjY0ICRfY3R5 cGUscjINCglhZGQuNjQgcjIscjEscjENCglsb2FkLjggW3IxXSxyMQ0KCWFu ZGkuOCAkNCxyMSxyMQ0KCWptcF9kaXJlY3RfeiByMSxATDIyMg0KCWxvYWRj b25zLjMyICQ5MCxyMg0KCXhvci5vci4zMiByMixyMyxyMQ0KCWptcF9kaXJl Y3RfeiByMSxATDI5OQ0KCWNtcGxlcy4zMiByMixyMyxyMQ0KCWptcF9kaXJl Y3RfeiByMSxATDMwNA0KCXhvci5vcmkuMzIgJDc2LHIzLHIxDQoJam1wX2Rp cmVjdF96IHIxLEBMMjk2DQoJam1wX2RpcmVjdCBATDMwMA0KQEwzMDQ6DQoJ eG9yLm9yaS4zMiAkMTA0LHIzLHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMjkw DQoJeG9yLm9yaS4zMiAkMTA4LHIzLHIxDQoJam1wX2RpcmVjdF96IHIxLEBM MjkzDQoJam1wX2RpcmVjdCBATDMwMA0KQEwyOTA6DQoJam1wX2RpcmVjdF96 IHI3LEBMMjkxDQoJbW92ZS42NCByMzQscjENCglhZGRpLjY0ICQ4LHIzNCxy MzQNCglsb2FkLjY0IFtyMV0scjMyDQoJbW92ZS42NCByMzMscjINCglzdWJp LjY0IDIwLHI2MixyMw0KCWxvYWRjb25zLjY0ICRzaW1wbGVfc3RydG9sLHIx DQoJam1wIHIxLHJhDQoJc3RvcmUuMTYgW3IzMl0scjENCglqbXBfZGlyZWN0 IEBMMjg5DQpATDI5MToNCgltb3ZlLjY0IHIzNCxyMQ0KCWFkZGkuNjQgJDgs cjM0LHIzNA0KCWxvYWQuNjQgW3IxXSxyMzINCgltb3ZlLjY0IHIzMyxyMg0K CXN1YmkuNjQgMjAscjYyLHIzDQoJbG9hZGNvbnMuNjQgJHNpbXBsZV9zdHJ0 b3VsLHIxDQoJam1wIHIxLHJhDQoJc3RvcmUuMTYgW3IzMl0scjENCglqbXBf ZGlyZWN0IEBMMjg5DQpATDI5MzoNCglqbXBfZGlyZWN0X3ogcjcsQEwyOTQN Cgltb3ZlLjY0IHIzNCxyMQ0KCWFkZGkuNjQgJDgscjM0LHIzNA0KCWxvYWQu NjQgW3IxXSxyMzINCgltb3ZlLjY0IHIzMyxyMg0KCXN1YmkuNjQgMjAscjYy LHIzDQoJbG9hZGNvbnMuNjQgJHNpbXBsZV9zdHJ0b2wscjENCglqbXAgcjEs cmENCglzdG9yZS42NCBbcjMyXSxyMQ0KCWptcF9kaXJlY3QgQEwyODkNCkBM Mjk0Og0KCW1vdmUuNjQgcjM0LHIxDQoJYWRkaS42NCAkOCxyMzQscjM0DQoJ bG9hZC42NCBbcjFdLHIzMg0KCW1vdmUuNjQgcjMzLHIyDQoJc3ViaS42NCAy MCxyNjIscjMNCglsb2FkY29ucy42NCAkc2ltcGxlX3N0cnRvdWwscjENCglq bXAgcjEscmENCglzdG9yZS42NCBbcjMyXSxyMQ0KCWptcF9kaXJlY3QgQEwy ODkNCkBMMjk2Og0KCWptcF9kaXJlY3RfeiByNyxATDI5Nw0KCW1vdmUuNjQg cjM0LHIxDQoJYWRkaS42NCAkOCxyMzQscjM0DQoJbG9hZC42NCBbcjFdLHIz Mg0KCW1vdmUuNjQgcjMzLHIyDQoJc3ViaS42NCAyMCxyNjIscjMNCglsb2Fk Y29ucy42NCAkc2ltcGxlX3N0cnRvbGwscjENCglqbXAgcjEscmENCglzdG9y ZS42NCBbcjMyXSxyMQ0KCWptcF9kaXJlY3QgQEwyODkNCkBMMjk3Og0KCW1v dmUuNjQgcjM0LHIxDQoJYWRkaS42NCAkOCxyMzQscjM0DQoJbG9hZC42NCBb cjFdLHIzMg0KCW1vdmUuNjQgcjMzLHIyDQoJc3ViaS42NCAyMCxyNjIscjMN Cglsb2FkY29ucy42NCAkc2ltcGxlX3N0cnRvdWxsLHIxDQoJam1wIHIxLHJh DQoJc3RvcmUuNjQgW3IzMl0scjENCglqbXBfZGlyZWN0IEBMMjg5DQpATDI5 OToNCgltb3ZlLjY0IHIzNCxyMQ0KCWFkZGkuNjQgJDgscjM0LHIzNA0KCWxv YWQuNjQgW3IxXSxyMzINCgltb3ZlLjY0IHIzMyxyMg0KCXN1YmkuNjQgMjAs cjYyLHIzDQoJbG9hZGNvbnMuNjQgJHNpbXBsZV9zdHJ0b3VsLHIxDQoJam1w IHIxLHJhDQoJc3RvcmUuMzIgW3IzMl0scjENCglqbXBfZGlyZWN0IEBMMjg5 DQpATDMwMDoNCglqbXBfZGlyZWN0X3ogcjcsQEwzMDENCgltb3ZlLjY0IHIz NCxyMQ0KCWFkZGkuNjQgJDgscjM0LHIzNA0KCWxvYWQuNjQgW3IxXSxyMzIN Cgltb3ZlLjY0IHIzMyxyMg0KCXN1YmkuNjQgMjAscjYyLHIzDQoJbG9hZGNv bnMuNjQgJHNpbXBsZV9zdHJ0b2wscjENCglqbXAgcjEscmENCglzdG9yZS4z MiBbcjMyXSxyMQ0KCWptcF9kaXJlY3QgQEwyODkNCkBMMzAxOg0KCW1vdmUu NjQgcjM0LHIxDQoJYWRkaS42NCAkOCxyMzQscjM0DQoJbG9hZC42NCBbcjFd LHIzMg0KCW1vdmUuNjQgcjMzLHIyDQoJc3ViaS42NCAyMCxyNjIscjMNCgls b2FkY29ucy42NCAkc2ltcGxlX3N0cnRvdWwscjENCglqbXAgcjEscmENCglz dG9yZS4zMiBbcjMyXSxyMQ0KQEwyODk6DQoJaW5jLjMyIHIzNixyMzYNCglz dWJpLjY0IDIwLHI2MixyMQ0KCWxvYWQuNjQgW3IxXSxyMg0KCWptcF9kaXJl Y3RfeiByMixATDIyMg0KCW1vdmUuNjQgcjIscjMzDQpATDIyMToNCglzdWJp LjY0IDEyLHI2MixyMg0KCWxvYWQuNjQgW3IyXSxyMQ0KCWxvYWQuOCBbcjFd LHIxDQoJam1wX2RpcmVjdF96IHIxLEBMMjIyDQoJbG9hZC44IFtyMzNdLHIx DQoJam1wX2RpcmVjdF9ueiByMSxATDMwNg0KQEwyMjI6DQoJbW92ZS4zMiBy MzYscjINCkBMMjIwOg0KCW1vdmUuMzIgcjIscjENCglsb2FkIDgsc3AscjMy DQoJbG9hZCA4LHNwLHIzMw0KCWxvYWQgOCxzcCxyMzQNCglsb2FkIDgsc3As cjM1DQoJbG9hZCA4LHNwLHIzNg0KCWxvYWQgOCxzcCxyMzcNCglsb2FkIDgs c3AscjYzDQoJam1wIHJhDQouZXh0ZXJuIHNzY2FuZg0Kc3NjYW5mOg0KCXN0 b3JlICQtOCxzcCxyNjMNCglhZGRpLjY0ICQ0LHI2MixyMQ0KCWxvYWQuNjQg W3IxXSxyMw0KCWFkZGkuNjQgJDEyLHI2MixyNA0KCXN1YmkuNjQgMTIscjYy LHIxDQoJc3RvcmUuNjQgW3IxXSxyNA0KCWxvYWRjb25zLjY0ICR2c3NjYW5m LHIxDQoJam1wIHIxLHJhDQoJbG9hZCA4LHNwLHI2Mw0KCWptcCByYQ0K --8323328-2069524284-1040262899=:566-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 19 15:14:17 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Xz-00048Q-01 for ; Thu, 19 Dec 2002 20:41:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:41:31 +0100 (CET) Received: (qmail 8234 invoked by uid 0); 19 Dec 2002 18:46:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 19 Dec 2002 18:46:42 -0000 Received: by moria.seul.org (Postfix) id 6274433C69; Thu, 19 Dec 2002 13:46:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A3E4133C73; Thu, 19 Dec 2002 13:46:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id EFFF533C69 for ; Thu, 19 Dec 2002 13:46:33 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00735; Thu, 19 Dec 2002 15:14:17 +0100 Message-ID: <20021219151417.57757@thrai.stud.uni-hannover.de> Date: Thu, 19 Dec 2002 15:14:17 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: <20021216152030.54203@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Dec 19, 2002 at 11:47:26AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 19, 2002 at 11:47:26AM +0100, devik wrote: > .macro jmp_direct_nz r,label > loadcons label > jmp r,label,r0 > .endm Too bad - my assembler doesn't support macros (yet). > I still can't decide way how to generate lavel & symbol > references. 64 bit symbol load needs 4 loadcons (16 bytes) > and there is a lot of them. See my other mail. > Local labels can use loadaddri (if they are in 16bit range). > I'd rather see to use 32bit addresses for code and 64 for data. I've also thought about restricting the size of the code segment to 2 GB. [...] > can you send me these tools ? So I'd be able at least validate the > output... The assembler is on f-cpu.org, but it's currently under heavy development (the published version does not support the current ISA). I'll release as-0.1 when it's usable again, together with the other ELF tools. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 19 15:07:09 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Y0-00048Q-00 for ; Thu, 19 Dec 2002 20:41:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:41:32 +0100 (CET) Received: (qmail 15139 invoked by uid 0); 19 Dec 2002 18:46:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 19 Dec 2002 18:46:49 -0000 Received: by moria.seul.org (Postfix) id C536D33C70; Thu, 19 Dec 2002 13:46:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 621DB33C74; Thu, 19 Dec 2002 13:46:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id 8440933C70 for ; Thu, 19 Dec 2002 13:46:40 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00713; Thu, 19 Dec 2002 15:07:09 +0100 Message-ID: <20021219150709.02465@thrai.stud.uni-hannover.de> Date: Thu, 19 Dec 2002 15:07:09 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] next gcc tests: vsprintf.s References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Dec 19, 2002 at 02:54:59AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 19, 2002 at 02:54:59AM +0100, devik wrote: > Hi, > > I added output of latest gcc compilation > of vsprintf.c. I repaired most of things > reported by MR. > > devik As printed some error messages. In detail: > ; F-CPU ASM by devik@cdi.cz Similar to gcc, my assembler uses `;' to separate instructions on a single line. Please use `//' for comments. Or rather, use something like .comment "F-CPU ASM by devik@cdi.cz" if the comment should appear in the object file :) > .text > .extern simple_strtoul > simple_strtoul: > dmove r2,r5,r3,r10 There is no dmove. > move.64 r0,r6 > jmp_direct_nz r4,@L2 Gcc normally uses the `.L' prefix for local labels, which is compatible with ELF linkers. `@' is used for other purposes. You may also use the `0f'/`0b' syntax for local labels: blah $0f blubb 0: > loadcons.32 $10,r4 There is loadcons.[0-3], but no loadcons.32. If you want to fill the entire register, use `loadconsx.0 $10, r4' in this case. > load.8 [r2],r1 Square brackets are no valid characters. `load.8 r2, r1' would be correct. > xor.ori.8 $48,r1,r1 That instruction doesn't exist (combine instructions have no immediate mode - and if they had one, it would be `xori.or.8' instead). > jmp_direct_nz r1,@L2 It's not perfect, but loadaddri $label-.-4, tmpreg jmpnz r1, tmpreg would be the correct way to do a (short) jump. Unfortunately, there is a slight chance that the target is too far away for loadaddri; if you're not sure, better use the long sequence loadconsx $label-.-20, tmpreg // 4 instructions! loadaddr tmpreg, tmpreg jmpnz r1, tmpreg The immediate constant MUST match the distance between the address of loadconsx and the address *after* loadaddr. I know it's ugly, but there currently is no other way. [...] > loadcons.64 $_ctype,r2 If you load an address, skip the size suffix: `loadcons $_ctype, r2'. As will output the full 4-instruction loadcons sequence and add relocs for the symbol. > add.64 r2,r1,r1 > load.8 [r1],r1 > andi.8 $68,r1,r1 AFAIK, there is no size suffix with immediate logic operations, except in SIMD mode. Yann? [...] > cmove.8 r1,r3,r2 It's called move{condition}, where {condition} is one of `[n]z', `[n]l', `[n]m', `.[not]zero', `.[not]lsb' or `.[not]msb'. > subi.32 55,r2,r2 Should be `$55'. [...] > jmp ra ra := r63 > store $-8,sp,r63 sp := r62 [...] > @LC0: > .ascii "0123456789abcdefghijklmnopqrstuvwxyz\0" If you use `.string' or `.asciz', as will add the trailing '\0'. [...] > nxor.andi.32 $0,r1,r1 Unknown. And it's called `xnor' BTW. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 19 14:14:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18P6Y1-00048Q-00 for ; Thu, 19 Dec 2002 20:41:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Dec 2002 20:41:33 +0100 (CET) Received: (qmail 26833 invoked by uid 0); 19 Dec 2002 18:46:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Dec 2002 18:46:57 -0000 Received: by moria.seul.org (Postfix) id 90EB733C6F; Thu, 19 Dec 2002 13:46:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D541233C9D; Thu, 19 Dec 2002 13:46:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id CD92933C6F for ; Thu, 19 Dec 2002 13:46:47 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00563; Thu, 19 Dec 2002 14:14:27 +0100 Message-ID: <20021219141427.35716@thrai.stud.uni-hannover.de> Date: Thu, 19 Dec 2002 14:14:27 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl References: <200212180945.0539@th00.opsion.fr> <20021218135752.04847@thrai.stud.uni-hannover.de> <006001c2a6c2$57323690$0100000a@homeworld> <20021219001446.02390@thrai.stud.uni-hannover.de> <3E010922.6080504@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E010922.6080504@f-cpu.org>; from Yann Guidon on Thu, Dec 19, 2002 at 12:47:46AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 19, 2002 at 12:47:46AM +0100, Yann Guidon wrote: > A lot of instructions have a 8-bit constant mode. > there are already "issues" about how it is sign-extended > and how it behaves in SIMD modes. I didn't intend to re-iterate that. My point was that we need a `cmpgi' or `cmpgei' instruction. The 8-bit immediate operand should be sign-extended when the operation is signed, and zero-padded otherwise - and it will be subject to an `implicit sdup' in SIMD modes, as usual. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Dec 19 20:35:42 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18PPXK-0000eJ-01 for ; Fri, 20 Dec 2002 16:58:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Dec 2002 16:58:06 +0100 (CET) Received: (qmail 6807 invoked by uid 0); 19 Dec 2002 23:04:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 19 Dec 2002 23:04:13 -0000 Received: by moria.seul.org (Postfix) id D9BC233C64; Thu, 19 Dec 2002 18:04:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9394833C7E; Thu, 19 Dec 2002 18:04:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a120.home.uni-hannover.de [130.75.232.120]) by moria.seul.org (Postfix) with ESMTP id C9F0E33C64 for ; Thu, 19 Dec 2002 18:04:10 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00611; Thu, 19 Dec 2002 20:35:43 +0100 Message-ID: <20021219203542.14405@thrai.stud.uni-hannover.de> Date: Thu, 19 Dec 2002 20:35:42 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] next gcc tests: vsprintf.s References: <20021219150709.02465@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20021219150709.02465@thrai.stud.uni-hannover.de>; from Michael Riepe on Thu, Dec 19, 2002 at 03:07:09PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Minor correction... I wrote: > .comment "F-CPU ASM by devik@cdi.cz" but the name of the instruction actually is `.ident' - `.comment' is the ELF section where it puts the string. It's a good idea to let the compiler put its footprint there; the assembler also adds a comment. That way you can find out which tools produced a binary. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Dec 21 00:16:15 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18PPXL-0000eJ-00 for ; Fri, 20 Dec 2002 16:58:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Dec 2002 16:58:07 +0100 (CET) Received: (qmail 19801 invoked by uid 0); 19 Dec 2002 23:38:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 19 Dec 2002 23:38:02 -0000 Received: by moria.seul.org (Postfix) id 1A1A333C68; Thu, 19 Dec 2002 18:38:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6284833C7E; Thu, 19 Dec 2002 18:38:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 0EE9833C68 for ; Thu, 19 Dec 2002 18:37:59 -0500 (EST) Received: from Biathlon (lcbv4-2-54.n.club-internet.fr [213.44.93.54]) by relay-3v.club-internet.fr (Postfix) with SMTP id 4A3D916B6 for ; Fri, 20 Dec 2002 00:37:30 +0100 (CET) Date: Sat, 21 Dec 2002 00:16:15 +0100 From: nico To: f-cpu@seul.org Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl Message-Id: <20021221001615.666c2368.nicolas.boulay@ifrance.com> In-Reply-To: References: <200212180945.0539@th00.opsion.fr> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 18 Dec 2002 12:07:32 +0100 (CET) devik wrote: > > Sorry, I misunderstood. But on the other hand, 6 bits aren't much > > for most purposes - you would have to `loadcons*' more often... > > > > >>>Only our gcc expert could answer. So, does 32 to -32 number (or 0 > > >to > > 64) immediat instruction could cover most immediat instructions used > > by gcc ? > > nicO > > Because I test majority of things with vsprintf.c from linux kernel > just now it is not too objective. There is 275 immediates used in the > file. Here is usage of constant NOT IN -32...31 range: > 13 addi > 21 andi > 3 cmplei > 1 cmplesi > 2 ori > 33 xor.ori > > and these are IN range: > 140 addi > 23 andi > 1 cmplei > 13 cmplesi > 3 cmplsi > 4 nxor.andi > 7 ori > 4 shiftli > 7 xor.ori > > So that 202 insns ARE in 6bit range but these was constants 1 and -1 > often (addi) - I didn't implemented INC/DEC yet. There was 82 of such. > As conclusion from 275 immediates 120 (202-82) can be coded into > 6 bits. And from that, how much can't use the actual 8 bits version (because 2 flag bitsdisappear ?) nicO > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Dec 20 16:33:56 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18PPYR-0000eJ-00 for ; Fri, 20 Dec 2002 16:59:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Dec 2002 16:59:15 +0100 (CET) Received: (qmail 2352 invoked by uid 0); 20 Dec 2002 15:34:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 20 Dec 2002 15:34:17 -0000 Received: by moria.seul.org (Postfix) id 3231433E32; Fri, 20 Dec 2002 10:34:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8178133E34; Fri, 20 Dec 2002 10:34:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id AFD2E33E32 for ; Fri, 20 Dec 2002 10:34:10 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200212201533.38bb; Fri, 20 Dec 2002 15:33:56 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Dec 2002 15:33:56 GMT Message-id: <200212201533.38bb@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: devik A: Date: 20/12/02 Objet: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl > > So that 202 insns ARE in 6bit range but these was consta= nts 1 and -1 > > often (addi) - I didn't implemented INC/DEC yet. There w= as 82 of such. > > As conclusion from 275 immediates 120 (202-82) can be co= ded into > > 6 bits. > > And from that, how much can't use the actual 8 bits versio= n (because 2 > flag bitsdisappear ?) I'm afraid I have not understood your question. Are you aski= ng for insn whose need more than 8 bits ? >>>Nop. Now it exist an instruction format using 8 bits immediats by= stolen 2 bits in the flag field of the instruction word. I don't like= it because it stole those 2 bits, so not every reg-reg->reg instruction= s could use 8 bits immediat. 6 bits will do it. So what is the number of instructions using immediat between -32 and 32 and that can'= t use the 8 bits immediat version of each instruction because it miss th= ose 2 flag bits. devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Dec 20 13:43:27 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18PPYM-0000eJ-00 for ; Fri, 20 Dec 2002 16:59:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 20 Dec 2002 16:59:10 +0100 (CET) Received: (qmail 28865 invoked by uid 0); 20 Dec 2002 15:05:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 20 Dec 2002 15:05:40 -0000 Received: by moria.seul.org (Postfix) id 1FEBE33C70; Fri, 20 Dec 2002 10:05:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5AB7133C6F; Fri, 20 Dec 2002 10:05:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 246DC33CB9 for ; Fri, 20 Dec 2002 10:05:33 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 14B0F4F8D2 for ; Fri, 20 Dec 2002 08:04:34 -0600 (CST) Received: from a106-137.dialup.iol.cz ([194.228.137.106] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18PNiN-0007dB-00 for f-cpu@seul.org; Fri, 20 Dec 2002 15:01:23 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18PMUx-0000DA-00 for f-cpu@seul.org; Fri, 20 Dec 2002 13:43:27 +0100 Date: Fri, 20 Dec 2002 13:43:27 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Rep:Re: Rep:Re: [f-cpu] signed cmpl In-Reply-To: <20021221001615.666c2368.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > So that 202 insns ARE in 6bit range but these was constants 1 and -1 > > often (addi) - I didn't implemented INC/DEC yet. There was 82 of such. > > As conclusion from 275 immediates 120 (202-82) can be coded into > > 6 bits. > > And from that, how much can't use the actual 8 bits version (because 2 > flag bitsdisappear ?) I'm afraid I have not understood your question. Are you asking for insn whose need more than 8 bits ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Dec 19 20:26:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q76J-0004pT-00 for ; Sun, 22 Dec 2002 15:29:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:29:07 +0100 (CET) Received: (qmail 26648 invoked by uid 0); 20 Dec 2002 15:55:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 20 Dec 2002 15:55:27 -0000 Received: by moria.seul.org (Postfix) id EC8A633C69; Fri, 20 Dec 2002 10:55:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6927633C68; Fri, 20 Dec 2002 10:55:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id A3A4333C7E for ; Fri, 20 Dec 2002 10:55:22 -0500 (EST) Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by bettik.munge.net (Postfix) with ESMTP id 06D274F7EB for ; Fri, 20 Dec 2002 05:44:50 -0600 (CST) Received: from a50-137.dialup.iol.cz ([194.228.137.50] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18PLX3-0007Kg-00 for f-cpu@seul.org; Fri, 20 Dec 2002 12:41:34 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18P6Jg-0000IL-00 for f-cpu@seul.org; Thu, 19 Dec 2002 20:26:44 +0100 Date: Thu, 19 Dec 2002 20:26:44 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] signed cmpl In-Reply-To: <20021216230308.55776@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > `cmplei $255, r2, r1' which have no corresponding instruction. Therefore, > we should implement a different pair of compare instructions. I guess > the best alternative is `cmpg' and `cmple'. We may also provide all of > them (cmp[lg] and cmp[lg]e) with little additional hardware (and without cmpg and cmple should be enough. As you said it will allow us to code all reg-reg comparisons, full r>i and r<=i and remaining two with one-biased constant. I'm not sure whether is it useful to have defined all of them in asm if we'd decide to not implement them. Just my opinion :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Dec 20 19:22:44 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q76f-0004pT-01 for ; Sun, 22 Dec 2002 15:29:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:29:29 +0100 (CET) Received: (qmail 3570 invoked by uid 0); 20 Dec 2002 18:24:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 20 Dec 2002 18:24:47 -0000 Received: by moria.seul.org (Postfix) id 8568833D48; Fri, 20 Dec 2002 13:24:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B93033D4E; Fri, 20 Dec 2002 13:24:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id D31A933D48 for ; Fri, 20 Dec 2002 13:24:44 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-192.jetnet.ab.ca [207.34.60.192]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id gBKIRh6f078056 for ; Fri, 20 Dec 2002 11:27:44 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E035FF4.8050207@jetnet.ab.ca> Date: Fri, 20 Dec 2002 11:22:44 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N devik wrote: > cmpg and cmple should be enough. As you said it will allow us > to code all reg-reg comparisons, full r>i and r<=i and remaining > two with one-biased constant. > I'm not sure whether is it useful to have defined all of them in asm > if we'd decide to not implement them. > Just my opinion :) Note compares are useful when comparing the same object more than once like a case statement or setting a logical value. With longer code sequences however you can appear to null out the branch prefetch often needed after a compare. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 20 19:50:17 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q77R-0004pT-00 for ; Sun, 22 Dec 2002 15:30:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:30:17 +0100 (CET) Received: (qmail 22642 invoked by uid 0); 20 Dec 2002 23:21:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 20 Dec 2002 23:21:18 -0000 Received: by moria.seul.org (Postfix) id A8DE733C5E; Fri, 20 Dec 2002 18:21:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 22BBC33C69; Fri, 20 Dec 2002 18:21:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a084.home.uni-hannover.de [130.75.232.84]) by moria.seul.org (Postfix) with ESMTP id 9E22E33C5E for ; Fri, 20 Dec 2002 18:21:14 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01521; Fri, 20 Dec 2002 19:50:17 +0100 Message-ID: <20021220195017.24498@thrai.stud.uni-hannover.de> Date: Fri, 20 Dec 2002 19:50:17 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: <200212201533.38bb@th00.opsion.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200212201533.38bb@th00.opsion.fr>; from Nicolas Boulay on Fri, Dec 20, 2002 at 03:33:56PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Dec 20, 2002 at 03:33:56PM +0000, Nicolas Boulay wrote: > Now it exist an instruction format using 8 bits immediats by stolen 2 > bits in the flag field of the instruction word. I don't like it because > it stole those 2 bits, so not every reg-reg->reg instructions could use > 8 bits immediat. 6 bits will do it. So what is the number of > instructions using immediat between -32 and 32 and that can't use the 8 > bits immediat version of each instruction because it miss those 2 flag > bits. The 6-bit approach may be cleaner, but it also makes programming harder. If you use loadi/storei, for example, you won't get far with only 6 bits. Or if you deal with characters a lot. Do you really want to waste two cycles and a register every time you need a character value >= 0x40? There is also the opposite way: never use those two bits in instructions that have only register operands - assign additional opcodes instead, if necessary. On the other hand, there are instructions which could easily share an opcode - e.g. inc, dec, neg, abs and nabs. They belong to the same EU, always use two register operands, and have plenty of room (9 unused flags). Before I agree with 6-bit immediates, I want to see detailed usage statistics, not just guesses. Compile a lot of stuff, including glibc, all the GNU tools, X11, a JVM and some benchmarks (preferably SPEC CPU2000), and gather statistics about immediate operand sizes. After that, we can talk again. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Dec 20 18:51:19 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q77R-0004pT-01 for ; Sun, 22 Dec 2002 15:30:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:30:17 +0100 (CET) Received: (qmail 10569 invoked by uid 0); 20 Dec 2002 23:21:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 20 Dec 2002 23:21:28 -0000 Received: by moria.seul.org (Postfix) id BCFF333C69; Fri, 20 Dec 2002 18:21:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6ABBD33C73; Fri, 20 Dec 2002 18:21:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a084.home.uni-hannover.de [130.75.232.84]) by moria.seul.org (Postfix) with ESMTP id F07DB33C68 for ; Fri, 20 Dec 2002 18:21:17 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01374; Fri, 20 Dec 2002 18:51:19 +0100 Message-ID: <20021220185119.16341@thrai.stud.uni-hannover.de> Date: Fri, 20 Dec 2002 18:51:19 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: <20021216230308.55776@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Dec 19, 2002 at 08:26:44PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Dec 19, 2002 at 08:26:44PM +0100, devik wrote: > cmpg and cmple should be enough. As you said it will allow us > to code all reg-reg comparisons, full r>i and r<=i and remaining > two with one-biased constant. Ok, then I'll go for it. > I'm not sure whether is it useful to have defined all of them in asm > if we'd decide to not implement them. Because many programmers tend to add 1 when they should subtract, and vice versa ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Dec 22 18:34:49 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q78F-0004pT-00 for ; Sun, 22 Dec 2002 15:31:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:31:07 +0100 (CET) Received: (qmail 25486 invoked by uid 0); 21 Dec 2002 17:56:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 21 Dec 2002 17:56:30 -0000 Received: by moria.seul.org (Postfix) id 95E3333C68; Sat, 21 Dec 2002 12:56:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E007E33C74; Sat, 21 Dec 2002 12:56:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0312233C68 for ; Sat, 21 Dec 2002 12:56:27 -0500 (EST) Received: from Biathlon (liifi-13-72.n.club-internet.fr [213.44.44.72]) by relay-4v.club-internet.fr (Postfix) with SMTP id 9A09F17DE for ; Sat, 21 Dec 2002 18:56:24 +0100 (CET) Date: Sun, 22 Dec 2002 18:34:49 +0100 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl Message-Id: <20021222183449.2eaab354.nicolas.boulay@ifrance.com> In-Reply-To: <20021220195017.24498@thrai.stud.uni-hannover.de> References: <200212201533.38bb@th00.opsion.fr> <20021220195017.24498@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 20 Dec 2002 19:50:17 +0100 Michael Riepe wrote: > On Fri, Dec 20, 2002 at 03:33:56PM +0000, Nicolas Boulay wrote: > > > Now it exist an instruction format using 8 bits immediats by stolen > > 2 bits in the flag field of the instruction word. I don't like it > > because it stole those 2 bits, so not every reg-reg->reg > > instructions could use 8 bits immediat. 6 bits will do it. So what > > is the number of instructions using immediat between -32 and 32 and > > that can't use the 8 bits immediat version of each instruction > > because it miss those 2 flag bits. > > The 6-bit approach may be cleaner, but it also makes programming > harder. If you use loadi/storei, for example, you won't get far with > only 6 bits. Or if you deal with characters a lot. Do you really want > to waste two cycles and a register every time you need a character > value >= 0x40? > Humm... i had in mind to add the 6 bits immediat forme not replace the 8 bits one. > There is also the opposite way: never use those two bits in > instructions that have only register operands - assign additional > opcodes instead, if necessary. > Ouch, what a decoder mess ! field in the opcode are a great think to reduice decoder complexity, if you mix adresseing mode/flag/opcode you will need 3 cycles for decode :) > On the other hand, there are instructions which could easily share an > opcode - e.g. inc, dec, neg, abs and nabs. They belong to the same EU, > always use two register operands, and have plenty of room (9 unused > flags). Because of the "risc rules" (to keep decode simple) adressing mode must not be too complexe. > > Before I agree with 6-bit immediates, I want to see detailed usage > statistics, not just guesses. Compile a lot of stuff, including glibc, > all the GNU tools, X11, a JVM and some benchmarks (preferably SPEC > CPU2000), and gather statistics about immediate operand sizes. After > that, we can talk again. And not linux kernel and Hurd ? :) But that's true we need statistic. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Dec 21 22:01:52 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q78W-0004pT-00 for ; Sun, 22 Dec 2002 15:31:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:31:24 +0100 (CET) Received: (qmail 18034 invoked by uid 0); 21 Dec 2002 21:03:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 21 Dec 2002 21:03:55 -0000 Received: by moria.seul.org (Postfix) id B1C9933C8B; Sat, 21 Dec 2002 16:03:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1451C33C8E; Sat, 21 Dec 2002 16:03:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 69ACD33C8B for ; Sat, 21 Dec 2002 16:03:53 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id gBLL6t6f094586 for ; Sat, 21 Dec 2002 14:06:55 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E04D6C0.9080700@jetnet.ab.ca> Date: Sat, 21 Dec 2002 14:01:52 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: <200212201533.38bb@th00.opsion.fr> <20021220195017.24498@thrai.stud.uni-hannover.de> <20021222183449.2eaab354.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N nico wrote: > Ouch, what a decoder mess ! field in the opcode are a great think to > reduice decoder complexity, if you mix adresseing mode/flag/opcode you > will need 3 cycles for decode :) Well the 8,16,32,64+ ints do make for a messy instruction set. Maybe we need a better high level programing langauge instead of C. > Because of the "risc rules" (to keep decode simple) adressing mode > must not be too complexe. Instruction scheduling rather than simple decodeing ( gates are cheap ) seems to be the main reason to keep preditable delay paths. > And not linux kernel and Hurd ? :) Don't forget X-windows and mozila for example. While a fast kernal is important, user programs waiting on a mouse click are what sells new computers. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Sun Dec 22 01:41:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Q78m-0004pT-00 for ; Sun, 22 Dec 2002 15:31:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Dec 2002 15:31:40 +0100 (CET) Received: (qmail 14812 invoked by uid 0); 22 Dec 2002 00:33:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 22 Dec 2002 00:33:19 -0000 Received: by moria.seul.org (Postfix) id 5598533C96; Sat, 21 Dec 2002 19:33:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1E7233C9D; Sat, 21 Dec 2002 19:33:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf11bis.bellsouth.net (mail311.mail.bellsouth.net [205.152.58.171]) by moria.seul.org (Postfix) with ESMTP id 2D9C533C96 for ; Sat, 21 Dec 2002 19:33:17 -0500 (EST) Received: from computer ([209.214.154.115]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021222003506.RBOD2907.imf11bis.bellsouth.net@computer> for ; Sat, 21 Dec 2002 19:35:06 -0500 Message-ID: <000a01c2a952$e317dec0$739ad6d1@computer> From: "richard hartny" To: Subject: [f-cpu] ALP76 Processor Date: Sat, 21 Dec 2002 18:41:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2A920.97BD2C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2A920.97BD2C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guys: Using the ACTEL AX2000; there is ample RAM Bits and user FF's + = .logic to go from a 16 Instruction Pipeline to 32. This I am doing = using Schematic input. Creates some very interesting logic problems = which I won't present untill later. Dick Hartney ------=_NextPart_000_0007_01C2A920.97BD2C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Guys:
 
    Using the ACTEL = AX2000; there is=20 ample RAM Bits and user FF's + .logic to go from a 16 Instruction = Pipeline to=20 32.  This I am doing using Schematic input.  Creates some very = interesting logic problems which I won't present untill = later.
 
Dick Hartney
------=_NextPart_000_0007_01C2A920.97BD2C00-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Dec 22 21:51:33 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18QF7M-0002FQ-00 for ; Mon, 23 Dec 2002 00:02:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 23 Dec 2002 00:02:44 +0100 (CET) Received: (qmail 10603 invoked by uid 0); 22 Dec 2002 20:37:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 22 Dec 2002 20:37:18 -0000 Received: by moria.seul.org (Postfix) id 0D47B33C67; Sun, 22 Dec 2002 15:37:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 652EE33CC8; Sun, 22 Dec 2002 15:37:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 5512733C67 for ; Sun, 22 Dec 2002 15:37:08 -0500 (EST) Received: from f-cpu.org (lcbv2-1-197.n.club-internet.fr [213.44.12.197]) by relay-3v.club-internet.fr (Postfix) with ESMTP id D4AB21778 for ; Sun, 22 Dec 2002 21:36:37 +0100 (CET) Message-ID: <3E0625D5.5010903@f-cpu.org> Date: Sun, 22 Dec 2002 21:51:33 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] F-CPU@19C3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, i have not been very interested in the last discussions for several reasons. One is that i am trying to "organise" the F-CPU presentation in Berlin. Look at http://www.ccc.de/congress It's a 1 hour long presentation with Cédric, nicO and myself, in the morning of the last day in room 2. We will be pleased to meet other people there. BTW, i'll stay until jan. 2nd and if you have some interesting address to visit or some funny place to look at (that is not in ANY tourist guide, hey, i'm not a tourist), let me know :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jenaustin@popmail.com Wed Dec 25 18:28:53 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Sq63-0001uN-01 for ; Mon, 30 Dec 2002 03:56:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Dec 2002 03:56:07 +0100 (CET) Received: (qmail 6597 invoked by uid 0); 25 Dec 2002 17:35:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 25 Dec 2002 17:35:26 -0000 Received: by moria.seul.org (Postfix) id 0218233CF0; Wed, 25 Dec 2002 12:35:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2107433CF2; Wed, 25 Dec 2002 12:35:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from popmail.com (home.popmail.com [216.234.252.59]) by moria.seul.org (Postfix) with SMTP id 8FAF833CF0 for ; Wed, 25 Dec 2002 12:35:20 -0500 (EST) Received: from home.popmail.com([216.234.252.59]) (1079 bytes) by popmail.com via sendmail-popmail.com with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Wed, 25 Dec 2002 11:28:53 -0600 (CST) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Apr-23) Message-Id: Date: Wed, 25 Dec 2002 11:28:53 -0600 (CST) Content-Type: text/plain From: jenaustin@popmail.com (Jen Austin) From: jenaustin@popmail.com Subject: [f-cpu] Buy Printer Ink Direct from Factory, SAVE up to 89% Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu To: sloyment@gmx.net X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Buy Printer Ink Direct from Factory and SAVE up to 89% We carry inkjet cartridges for all your favorite brands Canon, Epson, Hewlett Packard, Lexmark and many more Visit us on the web at: http://excuria.com/inkstore ID: 2002-12-25 11:43 To be permanently remove from this distribution system send an email to postmaster@excuria.com with subject line of: Remove youremail@yourdomain.com from excuria .................................... Get your own free email account from http://www.popmail.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kenshin_yuy_dvl@hotmail.com Sat Dec 28 11:18:55 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Sq7F-0001uN-00 for ; Mon, 30 Dec 2002 03:57:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Dec 2002 03:57:21 +0100 (CET) Received: (qmail 24518 invoked by uid 0); 28 Dec 2002 10:14:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 28 Dec 2002 10:14:07 -0000 Received: by moria.seul.org (Postfix) id B57B033D04; Sat, 28 Dec 2002 05:14:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C9E833D14; Sat, 28 Dec 2002 05:14:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from hotmail.com (oe61.law10.hotmail.com [64.4.14.196]) by moria.seul.org (Postfix) with ESMTP id CDDD833D04 for ; Sat, 28 Dec 2002 05:14:03 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 28 Dec 2002 02:14:03 -0800 X-Originating-IP: [202.158.28.46] From: "David" To: Subject: [f-cpu] hi can u help me Date: Sat, 28 Dec 2002 17:18:55 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2AE95.33866100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 28 Dec 2002 10:14:03.0179 (UTC) FILETIME=[D8C337B0:01C2AE59] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2AE95.33866100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI i'm david from indonesia hmm may i ask u about concurent programing = can u tell me about what the weakness and what can this programing = language do, please help me i need this information to understand concurent = programing . Thanks For everything ,i'm sorry if i'm not polite. YAU ------=_NextPart_000_0007_01C2AE95.33866100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI i'm david from indonesia  hmm = may i ask u=20 about concurent programing can u tell me  about what the weakness = and what=20 can this programing language do,<Fortran,Algol 60,pascal,algol 68, = simula 67,=20 CSP,concurent pascal,distributed processes,and ADA>
please help me i need this information = to=20 understand concurent programing . Thanks For everything ,i'm sorry if = i'm not=20 polite.
 
YAU
------=_NextPart_000_0007_01C2AE95.33866100-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Dec 31 13:33:36 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18TTSN-0000Z2-00 for ; Tue, 31 Dec 2002 21:57:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 31 Dec 2002 21:57:47 +0100 (CET) Received: (qmail 12071 invoked by uid 0); 31 Dec 2002 12:56:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 31 Dec 2002 12:56:21 -0000 Received: by moria.seul.org (Postfix) id D832133C6F; Tue, 31 Dec 2002 07:56:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26D9533C74; Tue, 31 Dec 2002 07:56:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 28EC333C6F for ; Tue, 31 Dec 2002 07:56:19 -0500 (EST) Received: from a83-137.dialup.iol.cz ([194.228.137.83] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18TLwI-00085m-00; Tue, 31 Dec 2002 13:56:11 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18TLaS-0000Ep-00; Tue, 31 Dec 2002 13:33:36 +0100 Date: Tue, 31 Dec 2002 13:33:36 +0100 (CET) From: devik X-X-Sender: To: Cc: , Subject: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > can you upload the file to the anonymous FTP > at ftp.seul.org : log in as anonymous and enter anything > as pwd. then go to pub/f-cpu/contrib and upload in binary :-) Ahh ok done :) It is there as gcc32fcpu_20021229.tgz. There is also readme in the tar expaining what is done in gcc and what problems with porting we have (mainly memory subsys and pointer aliasing). I really miss paper about intented LSU internals. There are some bits in list but it is hard to see what is valid just now. > BTW, don't be too much obsessed by code size, > i have seen that IA64 code is much larger (often 2x) > than x86, so it's ok given the current low optimisation. > then we'll have to teach GCC new tricks to get the last > 10% of performance. yes. I should rather compare number of instructions, it can give us rough estimate of optimizer quality. I do it becaise x86 optimizer is the best one present in gcc so that I can see how much away I'm. If I;d get 3 times large code I'd have to look for bug. To understand, if I do loadcons sym,r1 ... load.64 r1,r2 then load has to check TLB and so it will stall pipeline (because it could trap). So that I have to add prefetch somewhere, am I right ? It will mark r1 as pointer which tells me: r1 is TLB validated - to that OS TLB handler should erase all there pointer flags when TLB is changed (?). As the biggest problem I see pointer-reg<=>cache-line tie. From my experiance with gcc (and general feeling) comments in its code I see that it is not possible to do complete alias analysis of C memory references. Functions often returns pointers derived from their arguments and at many places you ends up with three or four pointers to similar memory location (typicaly stack). There is no way to say that they can be combined to single register and use post-modify trick. Also post-modify of loads and stores ties them implicitly to that they can't be run on future multiisue FCPUs. Whole F-CPU has almost no kludges in its ISA but I feel that current memory subsys will be a bottleneck. I'd rather see indexed addressing mode. Imagine +-8bit immediate offset. Each register would have 8 flags telling you whether it is safe (read: will not TLB trap) to access memory addressed by the register and adding/subing offset having N nonzero LSB bits (N is 1 to 8). This way you can hide 8 bit adder into LSU pipeline out of critical path of program control flow. Simply when you use nonzero immediate offset, the load will have larger latency (by 1 cycle). For stores it is even hidden by cache. The 8 flags above would be filled at the same place as "pointer" flag today - computing them when checking TLB. Normally then would be all 1 if TLB is valid and pointer is not near "edge" of page and higher flags would turn to zero as the pointer approaches an edge. This 8bit offset would be heavily used by structure accesses, local frame variables, in memory arguments... For example for double linked list operation you now need at least 3 pointers - pointer to "prev", "next" and data (reference count f.e.). All these points to similar locations. If you use post-inc/dec you have to serialize them. With immediate offset addresing mode you can do it with one pointer on single cache line and DO IT IN PARALEL. See item deletion in typical double linked list with destructor (linux kernel uses MANY ot them): struct L { struct L *next,*prev; funct dtr; // destructor fn pointer }; // r1 is pointer to item to delete 1. Unlink operation with current F-CPU ISA: loadi.64 $8,r1,r2 // ->next // 2 stalls loadi.64 $8,r1,r3 // ->prev // 2 stalls load.64 r1,r4 // ->dtr maddi $8,r2,r5 // ptr to ->next->prev store r3,r2 // new fwlink store r5,r3 // new backlink call r4 In above you can't paralelize loadi because they are interlocked. You can use different registers: maddi $8,r1,r3 loadi.64 $16,r1,r2 // ->next // 1 stall load.64 r3,r3 // ->prev load.64 r1,r4 // ->dtr ... We saved 3 stalls but need second pointer to the same cache line, can paralelize maddi & loadi. With direct indexing: load.64 r1,r2 loadoi.64 $8,r1,r3 loadoi.64 $16,r1,r4 point_1: storeoi.64 $8,r2,r3 store.64 r3,r2 call r4 The above is the shortest code, has no stall and if we can stuff/move other code to point_1 label it can run ot 3-issue F-CPU without RAW stalls. Finally I'd replace post-inc/dec by madd/msub. From my analysis (again gcc) post-modify was used mainly in funct prolog/epilog and sometimes in loops (cca 0.5% of code). madd/msub can produce result to another register - more flexibility. Other interesting case is prolog/epilog saving without SRB/msave/mload. Without immediate addressing you CAN'T paralelize saves at all. Even if you use 2 pointers on 2 issue cpu: storei.64 $16,r1,x storei.64 $16,r2,x // 2 cycle stall storei.64 $16,r1,x storei.64 $16,r2,x You get stalls IMHO. With immediate addressing you will be able to save 32 registers (all callee saved) with single register ... BTW, I read somewhere that "load" of noncached data will stall load at the decoder !? Is it true ? I always thought that it will "schedule" load to LSU and LSU will snoop on decoder to find cycle with free write slot latter. If none is find it will stall pipeline when target register is needed or cache line is about to flush ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 2 01:34:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Tysr-0000OV-00 for ; Thu, 02 Jan 2003 07:31:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 02 Jan 2003 07:31:13 +0100 (CET) Received: (qmail 24998 invoked by uid 0); 2 Jan 2003 00:34:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 2 Jan 2003 00:34:55 -0000 Received: by moria.seul.org (Postfix) id 8718533C73; Wed, 1 Jan 2003 19:34:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1139033CD3; Wed, 1 Jan 2003 19:34:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a201.home.uni-hannover.de [130.75.232.201]) by moria.seul.org (Postfix) with ESMTP id 3770833C73 for ; Wed, 1 Jan 2003 19:34:51 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA09412; Thu, 2 Jan 2003 01:34:49 +0100 Message-ID: <20030102013449.64244@thrai.stud.uni-hannover.de> Date: Thu, 2 Jan 2003 01:34:49 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Happy New Year :) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi F-gang, I have uploaded my `fctools' package to seul.org. It's located at http://f-cpu.seul.org/~f-cpu/new/fctools-0.1.tar.gz. You may also need the latest libelf package from http://www.stud.uni-hannover.de/~michael/software/ to compile it, as well as several GNU tools (gcc, make, flex). The package is targeted to the software developers among you. It contains an updated version of my ELF assembler (that is, it updates mr-as-0.0.tar.gz) as well as a disassembler, an emulator and several ELF tools (GNU binutils won't work in all cases). Please also have a look at the README file (and/or the source code, if you like). Bug reports welcome. Have fun, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From witija@gmx.de Thu Jan 2 02:05:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Tysr-0000OV-01 for ; Thu, 02 Jan 2003 07:31:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 02 Jan 2003 07:31:13 +0100 (CET) Received: (qmail 12835 invoked by uid 0); 2 Jan 2003 01:00:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 2 Jan 2003 01:00:59 -0000 Received: by moria.seul.org (Postfix) id 529B733CD3; Wed, 1 Jan 2003 20:00:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3E9E33CDC; Wed, 1 Jan 2003 20:00:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mx1.teamnova.de (unknown [212.124.41.27]) by moria.seul.org (Postfix) with ESMTP id F177E33CD3 for ; Wed, 1 Jan 2003 20:00:56 -0500 (EST) Received: from mx1.teamnova.de (newsletterboy@localhost [127.0.0.1]) by mx1.teamnova.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0215WqV027543 for ; Thu, 2 Jan 2003 02:05:32 +0100 Received: (from newsletterboy@localhost) by mx1.teamnova.de (8.12.3/8.12.3/Debian -4) id h0215W1V027541; Thu, 2 Jan 2003 02:05:32 +0100 Date: Thu, 2 Jan 2003 02:05:32 +0100 Message-Id: <200301020105.h0215W1V027541@mx1.teamnova.de> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: f-cpu@seul.org From: "www.cashgalaxy.de.vu - Geldverdienen im Internet" Subject: [f-cpu] Newsletter Anmeldung Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Herzlich Willkommen! Sie wurden soeben beim kostenlosen Newsletter von www.cashgalaxy.de.vu - Geldverdienen im Internet angemeldet. WICHTIG: Bitte bestätigen Sie dieses Abonnement, indem Sie auf folgenden Link klicken: http://www.newsletterboy.de/add_mail.php?id=8878&email=f-cpu@seul.org Durch diese Bestätigung wird verhindert, dass Ihre Email-Adresse ohne Ihr Einverständnis verwendet wird. Erst nach Ihrer Bestätigung wird Ihr Abonnement aktiviert! Kostenloser Newsletter-Account bei http://www.newsletterboy.de ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 15:20:30 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18TywD-0000Pj-00 for ; Thu, 02 Jan 2003 07:34:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 02 Jan 2003 07:34:41 +0100 (CET) Received: (qmail 29914 invoked by uid 0); 16 Dec 2002 18:07:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 16 Dec 2002 18:07:30 -0000 Received: by moria.seul.org (Postfix) id 0875833D58; Mon, 16 Dec 2002 13:07:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 865FC33D5D; Mon, 16 Dec 2002 13:07:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a176.home.uni-hannover.de [130.75.232.176]) by moria.seul.org (Postfix) with ESMTP id 9440033D58 for ; Mon, 16 Dec 2002 13:07:27 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00718; Mon, 16 Dec 2002 15:20:30 +0100 Message-ID: <20021216152030.54203@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 15:20:30 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] vsprintf result for GCC & FCPU References: <20021216005415.14662@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Dec 16, 2002 at 10:25:21AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 16, 2002 at 10:25:21AM +0100, devik wrote: > > Too bad that we can't run the code and see whether it really works :( > > At least, not today... but maybe by the end of the year. I have already > > built a tiny disassembler (similar to ndisasm, but less powerful) and > > an instruction-level emulator with built-in mini debugger that support > > :-) The code should work but you have to define macros for > jumps. The code is not still able to handle loadaddr and > jumps. Also there is still lack of conditional move - it > is one which should reduce code size further. What kind of macros? > But the only simulation showstopper is the lack of loadaddr > (emits loadcons instead) - but it should be simple to repair. My emulator doesn't care about these low-level details - it happily jumps to addresses generated by loadcons[x]. > But as you - I have to many 'real' work at this time. When you finally find the time, can you please change the assembler syntax a little? First, immediate operands should be prefixed with a `$' character (that is, in real instructions, not in .pseudo ops) - that way it's possible to make a difference between symbolic constants and register names (just consider a symbol named `r0') without looking at the opcode. Second, please change the register names to r0...r63. There are no designated argument or temporary registers, stack or frame pointers. Besides that, it's not wise to reflect the calling conventions in the register names, and IMHO it's also harder to read. Once you're done with that, my assembler should be able to process the assembler source files generated by your gcc port. Since I also have ar, mcs, nm, size, strings and strip utilities floating around on my disk, we would have an almost complete, working f-cpu toolchain (only ld is still missing). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Dec 16 14:45:21 2002 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18TywD-0000Pj-01 for ; Thu, 02 Jan 2003 07:34:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 02 Jan 2003 07:34:41 +0100 (CET) Received: (qmail 32199 invoked by uid 0); 16 Dec 2002 18:07:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 16 Dec 2002 18:07:41 -0000 Received: by moria.seul.org (Postfix) id 1FB5E33D5E; Mon, 16 Dec 2002 13:07:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F041B33D5F; Mon, 16 Dec 2002 13:07:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a176.home.uni-hannover.de [130.75.232.176]) by moria.seul.org (Postfix) with ESMTP id CAC4633D5E for ; Mon, 16 Dec 2002 13:07:29 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00625; Mon, 16 Dec 2002 14:45:22 +0100 Message-ID: <20021216144521.42564@thrai.stud.uni-hannover.de> Date: Mon, 16 Dec 2002 14:45:21 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] signed cmpl References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Dec 16, 2002 at 10:41:00AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Dec 16, 2002 at 10:41:00AM +0100, devik wrote: > Hi, > > when I was adding conditionals into gcc code I found > that signed compare is often used by gcc backend > (more than unsigned one for most of code). > > IMHO the signed compare can be (even for SIMD) done as: > > xor.N a0,a1,t0 // get sign difference > cmpl[e].N a0,a1,t1 // unsigned compare > shiftari.N N-1,t0,t0 // convert MSB bit to negation mask > // free slot here > xor.N t0,t1,t0 // negate result for different signs > it is 6 cycle latency! Can some HW guy here tell whether can > I count on signed cmp being computed by INC unit too ? It > would be one xor gate in its critical path AFAIK (negate > result if sign bits were different). My version would be: [s]bchg.N N-1, a0, t0 // change sign(s) [s]bchg.N N-1, a1, t1 // change sign(s) // free slot [s]cmpl[e].N t0, t1, t0 // unsigned compare but that's hardly faster. However, it's easy to realize in hardware: The unsigned cmpl is equivalent to y = (first_bit(a ^ b) & b) ? -1 : 0 and its signed counterpart will be y = (first_bit(a ^ b) & change_sign(b)) ? -1 : 0 which also needs a single XOR per chunk - but that's located *outside* the critical datapath, because first_bit() takes more time than a single XOR. Of course there will be both signed and unsigned integer compare instructions (and also min/max/sort). Projected names for the signed counterparts are cmpls, cmples, mins, maxs and minmaxs (aka sorts). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From djrom@altern.org Thu Jan 2 15:03:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UFAt-0000Dc-01 for ; Fri, 03 Jan 2003 00:54:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 03 Jan 2003 00:54:55 +0100 (CET) Received: (qmail 23151 invoked by uid 0); 2 Jan 2003 14:03:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 2 Jan 2003 14:03:24 -0000 Received: by moria.seul.org (Postfix) id 2C51533CEE; Thu, 2 Jan 2003 09:03:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A658C33D04; Thu, 2 Jan 2003 09:03:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from maturin (ADijon-101-1-4-246.abo.wanadoo.fr [80.11.37.246]) by moria.seul.org (Postfix) with ESMTP id 01E2933CEE for ; Thu, 2 Jan 2003 09:03:22 -0500 (EST) Received: from djrom by maturin with local (Exim 3.36 #1 (Debian)) id 18U5wN-0000oC-00 for ; Thu, 02 Jan 2003 15:03:19 +0100 Date: Thu, 2 Jan 2003 15:03:18 +0100 From: djrom To: f-cpu@seul.org Subject: Re: [f-cpu] Happy New Year :) Message-ID: <20030102140318.GA1589@cracken.mine.nu> References: <20030102013449.64244@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20030102013449.64244@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.4i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable a problem seems to exist in certain versions of glibc: syscall() is already defined in unistd.h. that's the case in the version currently included in debian sid. a simple rename of syscall() to f_syscall() + a search in replace in the code of emu.c resolve the problem in my case. maybe it's a good idea to change this definitely in the code. =20 good year and thanks for the tools ! --=20 -- djrom, still busy=20 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+FEamPjsv8VTg8fURArtuAJ44IxQ5x64+uM26lSWaggfdjdoz6gCglaNo 3PZbWrAOgjia5JVZFt7+x14= =0NOv -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 2 18:25:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UFB4-0000Dc-00 for ; Fri, 03 Jan 2003 00:55:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 03 Jan 2003 00:55:06 +0100 (CET) Received: (qmail 2710 invoked by uid 0); 2 Jan 2003 23:01:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 2 Jan 2003 23:01:18 -0000 Received: by moria.seul.org (Postfix) id 1C71433C82; Thu, 2 Jan 2003 18:01:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8269833C8D; Thu, 2 Jan 2003 18:01:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a157.home.uni-hannover.de [130.75.232.157]) by moria.seul.org (Postfix) with ESMTP id 65BDF33C82 for ; Thu, 2 Jan 2003 18:01:14 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA09519; Thu, 2 Jan 2003 18:25:12 +0100 Message-ID: <20030102182512.57024@thrai.stud.uni-hannover.de> Date: Thu, 2 Jan 2003 18:25:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Happy New Year :) References: <20030102013449.64244@thrai.stud.uni-hannover.de> <20030102140318.GA1589@cracken.mine.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030102140318.GA1589@cracken.mine.nu>; from djrom on Thu, Jan 02, 2003 at 03:03:18PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 02, 2003 at 03:03:18PM +0100, djrom wrote: > a problem seems to exist in certain versions of glibc: syscall() is > already defined in unistd.h. that's the case in the version currently > included in debian sid. a simple rename of syscall() to f_syscall() + a > search in replace in the code of emu.c resolve the problem in my case. > maybe it's a good idea to change this definitely in the code. Grrr! Glibc again :( I'll change that. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jrydberg@night.trouble.net Fri Jan 3 02:26:29 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UHyu-0002XY-00 for ; Fri, 03 Jan 2003 03:54:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 03 Jan 2003 03:54:44 +0100 (CET) Received: (qmail 6879 invoked by uid 0); 3 Jan 2003 01:20:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Jan 2003 01:20:27 -0000 Received: by moria.seul.org (Postfix) id F088B33C95; Thu, 2 Jan 2003 20:20:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F51633CC9; Thu, 2 Jan 2003 20:20:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by moria.seul.org (Postfix) with ESMTP id C519133C95 for ; Thu, 2 Jan 2003 20:20:25 -0500 (EST) Received: from cockmaster ([212.151.42.67]) by fep03-svc.swip.net with ESMTP id <20030103012024.FAEH5799.fep03-svc.swip.net@cockmaster> for ; Fri, 3 Jan 2003 02:20:24 +0100 Date: Fri, 3 Jan 2003 02:26:29 +0100 From: Johan Rydberg To: f-cpu@seul.org Subject: [f-cpu] CGEN cpu description ? Message-ID: <20030103022629.C6032@cockmaster> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.2 Lines: 12 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi! Why not write a CGEN [1] cpu description for the f-cpu? This will give you both an assembler, a disassembler and a simulator. brgds johan [1] http://sources.redhat.com/cgen/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Fri Jan 3 08:49:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UgCc-0000DS-00 for ; Sat, 04 Jan 2003 05:46:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Jan 2003 05:46:30 +0100 (CET) Received: (qmail 2594 invoked by uid 0); 3 Jan 2003 07:55:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 3 Jan 2003 07:55:05 -0000 Received: by moria.seul.org (Postfix) id AFAC933C85; Fri, 3 Jan 2003 02:54:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E516433CBC; Fri, 3 Jan 2003 02:54:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ender.tni.fr (host22.tni.fr [195.25.255.22]) by moria.seul.org (Postfix) with SMTP id 0468A33C85 for ; Fri, 3 Jan 2003 02:54:56 -0500 (EST) Received: (qmail 37362 invoked by uid 85); 3 Jan 2003 07:56:18 -0000 Received: from illusion_to_net@yahoo.fr by ender by uid 82 with qmail-scanner-1.14 (uvscan: v4.1.60/v4228. Clear:. Processed in 0.23808 secs); 03 Jan 2003 07:56:18 -0000 Received: from unknown (HELO yahoo.fr) (193.252.200.14) by ender with SMTP; 3 Jan 2003 07:56:18 -0000 Message-ID: <3E154098.1080100@yahoo.fr> Date: Fri, 03 Jan 2003 08:49:44 +0100 From: Just an Illusion User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Liste F-CPU Subject: [f-cpu] F-CPU on GPlinux booth at Solution Linux, the february 4th-5th-6th 2003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, On the french F-CPU liste, Nicole has proposed to burn some F-CPU cdrom to offert/sell them during the Solution Linux show the next February 4th to 6th. What do you think about this ? The selling price can be the price of burning cdrom. For the content, make some proposal; to me I think than it must content : * The manual 0.2.6 * The last snapshot of vhdl code * A snapshot content all development tools (editor, simulator, test-generator, testbench...) * The article which present the F-CPU objectives * The last presentation from previous shows made in 2002/2003, like Berlin Comment welcome, Just an Illusion -- ______________________________ "The matrix is my world, I am a shadow. Shadow in world, shadow in life. Don't try to keep me, I am a Corpo's Killer. Don't follow me or die..." The KingWalker - 1996 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mota@april.org Fri Jan 3 11:31:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UgCe-0000DS-00 for ; Sat, 04 Jan 2003 05:46:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Jan 2003 05:46:32 +0100 (CET) Received: (qmail 18133 invoked by uid 0); 3 Jan 2003 10:35:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 3 Jan 2003 10:35:20 -0000 Received: by moria.seul.org (Postfix) id A6E3D33C67; Fri, 3 Jan 2003 05:35:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0484033C85; Fri, 3 Jan 2003 05:35:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ns1.april.org (ns1.april.org [212.180.1.10]) by moria.seul.org (Postfix) with ESMTP id 6625433C67 for ; Fri, 3 Jan 2003 05:35:18 -0500 (EST) Received: from mota by ns1.april.org with local (Exim 3.35 #1 (Debian)) id 18UP6o-0004P6-00; Fri, 03 Jan 2003 11:31:22 +0100 Date: Fri, 3 Jan 2003 11:31:22 +0100 From: Paul Marques Mota To: Liste F-CPU Subject: Re: [f-cpu] F-CPU on GPlinux booth at Solution Linux, the february 4th-5th-6th 2003 Message-ID: <20030103103122.GA11030@opium.april.org> Mail-Followup-To: Paul Marques Mota , Liste F-CPU References: <3E154098.1080100@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <3E154098.1080100@yahoo.fr> User-Agent: Mutt/1.3.28i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 03, 2003 at 08:49:44AM +0100, Just an Illusion wrote: > Hello, > > On the french F-CPU liste, Nicole has proposed to burn some F-CPU cdrom > to offert/sell them during the Solution Linux show the next February 4th > to 6th. > You will be next to the FSF booth, and I'll be on that one. > What do you think about this ? > It's a nice idea. > Just an Illusion > -- Paul ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 3 13:50:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UgCf-0000DS-00 for ; Sat, 04 Jan 2003 05:46:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Jan 2003 05:46:33 +0100 (CET) Received: (qmail 23655 invoked by uid 0); 3 Jan 2003 12:35:33 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 3 Jan 2003 12:35:33 -0000 Received: by moria.seul.org (Postfix) id A5D7133C85; Fri, 3 Jan 2003 07:35:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3765333CC1; Fri, 3 Jan 2003 07:35:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 6657E33C85 for ; Fri, 3 Jan 2003 07:35:29 -0500 (EST) Received: from f-cpu.org (liifi-13-48.n.club-internet.fr [213.44.44.48]) by relay-3v.club-internet.fr (Postfix) with ESMTP id CDE421726 for ; Fri, 3 Jan 2003 13:34:52 +0100 (CET) Message-ID: <3E15870E.7070808@f-cpu.org> Date: Fri, 03 Jan 2003 13:50:22 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU on GPlinux booth at Solution Linux, the february 4th-5th-6th 2003 References: <3E154098.1080100@yahoo.fr> <20030103103122.GA11030@opium.april.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Paul Marques Mota wrote: >On Fri, Jan 03, 2003 at 08:49:44AM +0100, Just an Illusion wrote: > > >>Hello, >> >>On the french F-CPU liste, Nicole has proposed to burn some F-CPU cdrom >>to offert/sell them during the Solution Linux show the next February 4th >>to 6th. >> >You will be next to the FSF booth, and I'll be on that one. > > if i have no job, i'll be there. not all the time, but it's a good start :-) >>What do you think about this ? >> >It's a nice idea. > > yep, it's interesting :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 3 13:51:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UgCg-0000DS-00 for ; Sat, 04 Jan 2003 05:46:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Jan 2003 05:46:34 +0100 (CET) Received: (qmail 5132 invoked by uid 0); 3 Jan 2003 12:51:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 3 Jan 2003 12:51:18 -0000 Received: by moria.seul.org (Postfix) id 222AB33CBC; Fri, 3 Jan 2003 07:51:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B35F33CC2; Fri, 3 Jan 2003 07:51:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B5B3D33CBC for ; Fri, 3 Jan 2003 07:51:16 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200301031251.0331; Fri, 3 Jan 2003 12:51:03 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] F-CPU on GPlinux booth at Solution Linux, the february From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jan 2003 12:51:03 GMT Message-id: <200301031251.0331@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Must we try to go there too : http://www.fosdem.org/ ? nicO=20 -----Message d'origine----- De: Yann Guidon A: f-cpu@seul.org Date: 03/01/03 Objet: Re: [f-cpu] F-CPU on GPlinux booth at Solution Linux,= the february hi ! Paul Marques Mota wrote: >On Fri, Jan 03, 2003 at 08:49:44AM +0100, Just an Illusion = wrote: > =20 > >>Hello, >> >>On the french F-CPU liste, Nicole has proposed to burn som= e F-CPU cdrom=20 >>to offert/sell them during the Solution Linux show the nex= t February 4th=20 >>to 6th. >> >You will be next to the FSF booth, and I'll be on that one. > =20 > if i have no job, i'll be there. not all the time, but it's = a good start :-) >>What do you think about this ? >> >It's a nice idea. > =20 > yep, it's interesting :-) YG ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 3 14:41:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18UgCq-0000DS-00 for ; Sat, 04 Jan 2003 05:46:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Jan 2003 05:46:44 +0100 (CET) Received: (qmail 18191 invoked by uid 0); 3 Jan 2003 17:25:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 3 Jan 2003 17:25:44 -0000 Received: by moria.seul.org (Postfix) id BE53433CCF; Fri, 3 Jan 2003 12:25:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2EEFC33CEB; Fri, 3 Jan 2003 12:25:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a131.home.uni-hannover.de [130.75.232.131]) by moria.seul.org (Postfix) with ESMTP id 554EB33CCF for ; Fri, 3 Jan 2003 12:25:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00689; Fri, 3 Jan 2003 14:41:09 +0100 Message-ID: <20030103144109.10299@thrai.stud.uni-hannover.de> Date: Fri, 3 Jan 2003 14:41:09 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CGEN cpu description ? References: <20030103022629.C6032@cockmaster> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030103022629.C6032@cockmaster>; from Johan Rydberg on Fri, Jan 03, 2003 at 02:26:29AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 03, 2003 at 02:26:29AM +0100, Johan Rydberg wrote: > Why not write a CGEN [1] cpu description for the f-cpu? > This will give you both an assembler, a disassembler and > a simulator. Thanks for the hint, I'll look at it. I also got another set of tools: NJMT - the New Jersey Machine-Code Toolkit UQBT - the University of Queensland Binary Translation framework Walkabout - an extension to UQBT that supports dynamic binary translation I'll try them once I figured out how to specify SIMD operations in their configuration language. The (dynamic) binary translation stuff becomes very interesting when we want to emulate the F-CPU efficiently on another processor (or vice versa). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gabrielokhai@phantomemail.com Thu Jan 2 01:15:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18VP5D-00010i-00 for ; Mon, 06 Jan 2003 05:41:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 06 Jan 2003 05:41:51 +0100 (CET) Received: (qmail 2703 invoked by uid 0); 5 Jan 2003 17:59:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 5 Jan 2003 17:59:48 -0000 Received: by moria.seul.org (Postfix) id A47F733C91; Sun, 5 Jan 2003 12:59:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE1B333D02; Sun, 5 Jan 2003 12:59:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 211A133C91 for ; Sun, 5 Jan 2003 12:59:46 -0500 (EST) Received: from coolre41377.com ([80.88.136.6]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h05Hwrl13736 for ; Sun, 5 Jan 2003 12:59:31 -0500 Message-Id: <200301051759.h05Hwrl13736@belegost.mit.edu> From: "DR. GABRIEL OKHAI" To: f-cpu@seul.org Date: Thu, 2 Jan 2003 01:15:45 +0100 Subject: [f-cpu] COMPLIMENT OF THE SEASON X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N FROM=3ATHE CHAIRMAN=2C CONTRACT REVIEW PANEL=2C=28 CRP =29 FEDERAL MINISTRY OF WORKS AND HOUSING FEDERAL SECRETARIAT OFFICE COMPLEX F=2EC=2ET ABUJA=2E FUND TRANSFER=2FINVESTMENT Dear Friend=2C First=2C I must solicit your strictest confidence in this transaction=2Cthis is by virtue of it's nature as being utterly confidential and top secret=2E Study this portion carefully and advice categorically=2C if you will be able to handle=2C as I might not want to be exposed of the information considering the source and reputation of my name=2E I am the Director of project and the newly appointed chairman=2C contract reviewing committee=28CRC=29 of the Federal ministry of Works and Housing=28FMW&H=29in Abuja=2C Nigeria=2E I am seeking your assistance to enable me transfer the sum of US$21=2E4million into your account for mutual benefits=2EThis money came about as a result of a contract executed on behalf of my Ministry=2C the =28Federal Ministry of Works and Housing=29=2E This contract was officially assigned to be awarded and executed by two foreign contractors at the tune of US$94m but in the course of our negotiation=2C we bargained with only one foreign contractor=2C a Bulgarian firm which now executed the contract at the cost of US$72=2E6m thus leaving the remaining US$21=2E4million to our =28members of the CRP =29 benefits unknown to the contractor and any other person in my Ministry=2E This contract has been satisfactorily executed and inspected as the Bulgarian firm is presently securing his payment from my ministry=2E It is however to this effect that I seek your maximum assistance and approval to present your company name alongside with the Bulgarian contractor as the second foreign contractor to enable me transfer the differenceUS$21=2E4million into your account for further investment depending on your advice=2EOn actualization of the transaction=2C the funds will be shared thus=3A 1=2E 30% of the money go to you for acting as the beneficiary of the funds=2E 2=2E 10% for reimbursement to both parties for incidental expenses that may be incurred in the course of the transaction for insurance=2C phone bills=2C documentation etc=2E 3=2E 60%to me=2E All logistics are in place and all modalities worked out for the smooth actualization of the transaction within fourteen working days of commencement after receiving the following information in your response=3A Your name or company s name=2Caddress=2C phone=2Ffax numbers and the activities of your company=2E The above information will enable me make application and lodge claims to concerned Ministries in favour of your company or name and it is pertinent to state here that this deal is entirely based on trust and the fear of God=2E If you are able to handle this=2C feel free to reach me back for a perfect understanding of the transaction=2E Thanks in anticipation of your positive response=2E Yours faithfully Dr Gabriel Okhai=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jrydberg@night.trouble.net Mon Jan 6 23:35:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Vtb2-0001iE-00 for ; Tue, 07 Jan 2003 14:16:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 07 Jan 2003 14:16:44 +0100 (CET) Received: (qmail 31731 invoked by uid 0); 6 Jan 2003 22:28:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 6 Jan 2003 22:28:55 -0000 Received: by moria.seul.org (Postfix) id 2C9CB33CBD; Mon, 6 Jan 2003 17:28:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B8C833D44; Mon, 6 Jan 2003 17:28:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by moria.seul.org (Postfix) with ESMTP id 538FF33CBD for ; Mon, 6 Jan 2003 17:28:52 -0500 (EST) Received: from cockmaster ([212.151.85.180]) by fep04-svc.swip.net with ESMTP id <20030106222850.UDFP21.fep04-svc.swip.net@cockmaster> for ; Mon, 6 Jan 2003 23:28:50 +0100 Date: Mon, 6 Jan 2003 23:35:09 +0100 From: Johan Rydberg To: f-cpu@seul.org Subject: Re: [f-cpu] CGEN cpu description ? Message-ID: <20030106233509.A1630@cockmaster> References: <20030103022629.C6032@cockmaster> <20030103144109.10299@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030103144109.10299@thrai.stud.uni-hannover.de>; from michael@stud.uni-hannover.de on Fri, Jan 03, 2003 at 14:41:09 +0100 X-Mailer: Balsa 1.2.2 Lines: 16 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On 2003.01.03 14:41 Michael Riepe wrote: : > Why not write a CGEN [1] cpu description for the f-cpu? : > This will give you both an assembler, a disassembler and : > a simulator. : : Thanks for the hint, I'll look at it. : I also got another set of tools: : : [...] One good thing (tm) with CGEN is that it tightly connected with GNU binutils aswell as GNU simulators (ie gdb) regards johan ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 7 01:05:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Vtb5-0001iE-00 for ; Tue, 07 Jan 2003 14:16:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 07 Jan 2003 14:16:47 +0100 (CET) Received: (qmail 3727 invoked by uid 0); 7 Jan 2003 00:05:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 7 Jan 2003 00:05:20 -0000 Received: by moria.seul.org (Postfix) id 38E7E33C60; Mon, 6 Jan 2003 19:05:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD1B033D95; Mon, 6 Jan 2003 19:05:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a163.home.uni-hannover.de [130.75.232.163]) by moria.seul.org (Postfix) with ESMTP id 1B17633C60 for ; Mon, 6 Jan 2003 19:05:17 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA15316; Tue, 7 Jan 2003 01:05:15 +0100 Message-ID: <20030107010515.40042@thrai.stud.uni-hannover.de> Date: Tue, 7 Jan 2003 01:05:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] CGEN cpu description ? References: <20030103022629.C6032@cockmaster> <20030103144109.10299@thrai.stud.uni-hannover.de> <20030106233509.A1630@cockmaster> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030106233509.A1630@cockmaster>; from Johan Rydberg on Mon, Jan 06, 2003 at 11:35:09PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Jan 06, 2003 at 11:35:09PM +0100, Johan Rydberg wrote: > One good thing (tm) with CGEN is that it tightly connected with > GNU binutils aswell as GNU simulators (ie gdb) Whether that is a *good* thing depends on your point of view ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From INVESTMENT_ALERT---99991@sprintmail.com Tue Jan 7 02:08:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Vtb5-0001iE-01 for ; Tue, 07 Jan 2003 14:16:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 07 Jan 2003 14:16:47 +0100 (CET) Received: (qmail 10025 invoked by uid 0); 7 Jan 2003 01:03:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 7 Jan 2003 01:03:15 -0000 Received: by moria.seul.org (Postfix) id F3C4133DA0; Mon, 6 Jan 2003 20:03:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57AE633DA3; Mon, 6 Jan 2003 20:03:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E089233DA0 for ; Mon, 6 Jan 2003 20:03:12 -0500 (EST) Received: from 62.251.161.189 (p6019-ipadfx01kokuryo.gunma.ocn.ne.jp [61.199.29.83]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h0713Al21207 for ; Mon, 6 Jan 2003 20:03:10 -0500 Message-Id: <200301070103.h0713Al21207@belegost.mit.edu> Received: from unknown (201.187.168.97) by smtp-server1.cfl.rr.com with QMQP; Jan, 06 2003 6:53:34 PM +0600 Received: from rly-xl04.mx.aol.com ([161.143.46.72]) by m10.grp.snv.yahoo.com with QMQP; Jan, 06 2003 5:45:43 PM -0800 Received: from 11.139.74.233 ([11.139.74.233]) by n7.groups.yahoo.com with NNFMP; Jan, 06 2003 4:53:40 PM +1100 From: INVESTMENT ALERT - 99738 To: Subscriber.99304@belegost.mit.edu Subject: [f-cpu] STOCK MARKET ALERT - TBIN REPORTS RECORD REVENUES.98668 Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 6 Jan 2003 19:08:48 -0600 X-Mailer: Microsoft Outlook Build 10.0.2627 X-Priority: 1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

TBIN Reports Record Revenues and Earnings - UP 309%

Get the whole story from "Live From the Street"

ENTER HERE

 

 

Click here to unsubscribe xbbhqowsqgtxewnw ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 7 13:23:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xj-0004IT-00 for ; Wed, 08 Jan 2003 07:45:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:15 +0100 (CET) Received: (qmail 22635 invoked by uid 0); 7 Jan 2003 13:16:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 7 Jan 2003 13:16:57 -0000 Received: by moria.seul.org (Postfix) id 6BBC933C99; Tue, 7 Jan 2003 08:16:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A34AC33DAA; Tue, 7 Jan 2003 08:16:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EB4E633C99 for ; Tue, 7 Jan 2003 08:16:49 -0500 (EST) Received: from a112-137.dialup.iol.cz ([194.228.137.112] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Vtak-0001mH-00 for f-cpu@seul.org; Tue, 07 Jan 2003 14:16:28 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Vslo-0000Gm-00 for f-cpu@seul.org; Tue, 07 Jan 2003 13:23:48 +0100 Date: Tue, 7 Jan 2003 13:23:48 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Ehh I forgot .. I fwd my reply to group too as someone might like to comment something. --------- > I finally got it up and running now, but the assembler still doesn't > grok the code, for several reasons: hi, you seem to be pretty familiar with gcc internals, did you think about changing/fixing some things directly in a code ? I'll try to address all of these but later when I get some more time. Just now only some comments/questions. PLEASE read and comment it. It would help to decide how to do some things. > - The ranges for immediate operands are wrong. umin/umax take > unsigned bytes, smin/smax signed bytes, for example (btw: > smin/smax are missing). ahh yes - there was a lot of experiments with ranges and this code is not checked yet. And smin/smax was not there because I finshed that part before you told me that there will be signed versions .. > - For shift/rotate ops, the second operand should always have > QImode. That avoids an unnecessary explicit zero extension > when the operand is not a full register. Immediate operands > are unsigned, BTW. ok, one comment which is VERY important conceptional thing. Because gcc doesn't handle SIMD implicitly (yet) I use only non-simd (except for instrinstic funtions - not done yet). When we do some operation in SI mode we can rely on CPU to zero extend it to 64bits (for FC0). This holds for all insns I know about. It seems natural to use it and define zero_extend as no-op (I tested it using subregs). Other CPUs in gcc often define TRULY_NOOP_TRUNCATION to tell that we can truncate just by pretending register as already truncated - ie. accessing 64bit register with .16 insn truncates DI to HI. We can't use it on FCPU because of 2 reasons: 1) it would colide with our no-op extension, producing no code for case { uint i; ushort s = (uchar)i; } where is should produce either truncate or zextend 2) it makes jmpz/nz problematic because it tests full 64bit register - TRULY_NOOP_TRUNCATION leaves garbage in upper bits and if((uchar)i) where i==256 jumps even if low 8bits is zero. If we would want TRULY_NOOP_TRUNCATION we would need to emit "and" before each such test. If we will decide to use noop zero_extend then the code will be shorter and also there is no problem with rotation size above. > - logic operations take 9-bit signed immediate operands. uhh .. my 2.7 manual doesn't state it :( Where can I find it ? > - STACK_BOUNDARY must be at least 64 (fullword!). FUNCTION_BOUNDARY > should be the size of a cache line (256 bits). And even more > important: STRICT_ALIGNMENT must be 1 (unaligned memory access > is strictly forbidden). good point - it is another thing I didn't find in manual. So that f-cpu needs natural align on all data ? > - We pass arguments in r1...r15, not r2...r15. Leaving r1 unused > is pointless. On the other hand, we also pass arguments in > registers when the function has variable arguments - currently, > gcc puts the `fixed' arguments in registers and pushes the > rest on the stack?! then the manual pg 223 is wrong again. About variable arguments, yes they go to the stack just now - I have to look how can I force gcc to find them in registers. Again this convention seems not to be documented. > - The function prologue is wrong. `storei $-8, r62, r61' uses > *post*decrement, not predecrement. I suggest you calculate > the required amount of memory, subtract it from r62, and then > use a temporary register with postincrement for storing > registers and initializing locals. I know. I simply assume that stack pointer points to next free slot instead of last used one. Then in prolog I can use post decrement and save several insn and additional register (which can save us troubles with register-cache aliasing). Epilog first substracts 8 from SP - it is ok because at end of fn there is often a lot of free scheduler slots where this substract insn fits at no expense (which is not case in prolog). However I just realized that it is not interrupt/signal safe :-( I really have to decrement in prolog ... > - ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP are wrong. The > former because it assumes predecrement again, the latter > because the instruction is called `loadi', not `load'. yes. I still didn't reallized what are these macros used for. I hope to be able to undef them completely. > - There's a much easier way to specify the pattern for `mux' > (note the constraints for operands 3 and 4): > > (define_insn "*mux" > [(set (match_operand 0 "register_operand" "=r,r") > (ior > (and > (match_operand 1 "register_operand" "r,r") > (match_operand 2 "register_operand" "r,r")) > (and > (not (match_operand 3 "register_operand" "1,2")) > (match_operand 4 "register_operand" "0,0")))) > [....] > "@ > mux %1,%2,%0 > mux %2,%1,%0" > [(set_attr "type" "logic")]) Are you sure ? Constraints are tested AFTER matching. So that your version will probably took: a&b | c&~d as one which matches and the will try to use consraints to ensure correct register allocation. It will found that none matches and will abort. See this except fro manual: "More precisely, the two operands that match must include one input-only operand and one output-only operand." So that you can use that 0,0 but not 1,2 constraint. > - `loop' branches when the register is not zero. That is: > > (ne (match_operand:DI 0 "register_operand" "+r") (const_int 0)) > This instruction uses DImode, not SImode. ehh yes it was there for teysting only because loop optimizer still dies weird things :( > - Conditional branches (`jmpz'/`jmpnz') also use DImode for the > condition register. If the operand is smaller, it needs > zero extension (unless you're sure that the upper bits are > zero anyway - but that's not always true). I use VOIDmode because it is needed by loop optimizer ... See extension ideas above. > - Your patterns for `*movM' allow the destination to be constant 0. yes I know. However this will never be emited by gcc and if yes it will abort in constraint selection. If I will disallow it, it would abort elsewhere then ... So I allowed it because I had no regmem_operand fn at that time. I'd focus on more problematic parts just now. > - The `*loadcons' patterns look suspicious to me. Better drop them. > In fact, better don't use loadcons at all, use loadconsx > instead (and rely on the assembler to optimize the instruction > sequence). :) They are under developement still but the really describe what loadcons does !! They should be also able to translate code: a = b & 0xffffffff0000ffff | 0x45330000; to single loadcons.1. Also we really need to tell gcc about all loadcons isns because splitter will need them to do correct scheduling. Loadcons are ideal "stuffers" for free schedule slots. > - `loadaddri' (without `d') is correct for a LABEL_REF (while a > SYMBOL_REF would require `loadaddrid'). But you got the offset > wrong: it should read `loadaddri $label-.-4, reg'. Ok about the offset. But SYMBOL_REF doesn't imply loadaddrid ! SYMBOL_REFs are used both for external data & code pointers and there is currently no way to distinguish them (unfortunately) ! Thus the warning comment in the asm. LABEL_REF is used ONLY for internal labels BUT also it can be used with loadaddrid sometimes ! (gcc allows you to take pointer to label, switch() statements needs jump table at label and gcc also labels private data tables. Thus we will need to analyze insn dataflow to found which kind of loadaddr to use - and there are further possible cases where (G)CSE will try to use resulting pointer for both data & code access (it is legal to read from function pointer AFAIK). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 7 13:57:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xk-0004IT-00 for ; Wed, 08 Jan 2003 07:45:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:16 +0100 (CET) Received: (qmail 5847 invoked by uid 0); 7 Jan 2003 13:17:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 7 Jan 2003 13:17:09 -0000 Received: by moria.seul.org (Postfix) id 0A4D033DAF; Tue, 7 Jan 2003 08:17:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CA1333DAE; Tue, 7 Jan 2003 08:17:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 1C91933DA9 for ; Tue, 7 Jan 2003 08:17:06 -0500 (EST) Received: from a112-137.dialup.iol.cz ([194.228.137.112] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18VtbD-0001mM-00 for f-cpu@seul.org; Tue, 07 Jan 2003 14:16:56 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18VtI0-0000H1-00 for f-cpu@seul.org; Tue, 07 Jan 2003 13:57:04 +0100 Date: Tue, 7 Jan 2003 13:57:04 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] GCC and jmpz vs. jmpl Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N In light of my prev. mail about zero_extending one other thing to discuss. When we do compares < > >= <= we got results as 1 or -1. It is very nice as gcc can then often eliminate jump. I set 1/-1 as scc value and it now knows that: if (a>b) b++; else b--; can be compiled as: cmpg r1,r2,r3 add r2,r3,r2 and "return a>b" becomes cmpg r1,r2,r3 neg r3,r1. For different modes we can add truncation like for "return (long)a > (long)b": cmpg.64 r1,r2,r3 neg.32 r3,r1 or extension for "return (char)a > (char)b": cmpg.8 r1,r2,r3 neg.8 r3,r1 widen.8 r1,r1 // what does this wide to ?? to 64bits ?? For these cases we could learn gcc's combiner that if (a > b) can use jmpl - it is because we know that nonequality operator stores result in bit 0 regardless of operands sizes and it is possibly faster than jmpz for FCPUs with wider data types where zero flag computation can took long time - also it relieves us from problems with zero extending all results. On other side there is a big problem with == and !=. Just now I use xor and the jmpz/nz. If I want to use scc I need to emit "cmple 0" to convert it to 1/-1 notation. If we would like to use jmpl it is the same problem. So that I'd like to ask, is it big problem to perform "cmpe" in increment unit too ? I know it is done by xor.and. but it is still not sure whether is will be there, and if it will support more than 8 bits and even if so it will take 2 cycles. It could save cycles if zero flag is slow (if it is possible at all !). devik PS: Will stall occur here (due zero flag computation) ? : cmplei 2,r1,r2 nop movez r2,r0,r1 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 7 06:47:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xo-0004IT-00 for ; Wed, 08 Jan 2003 07:45:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:20 +0100 (CET) Received: (qmail 30397 invoked by uid 0); 7 Jan 2003 17:08:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 7 Jan 2003 17:08:47 -0000 Received: by moria.seul.org (Postfix) id AC23A33DA9; Tue, 7 Jan 2003 12:08:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 12B0D33DAC; Tue, 7 Jan 2003 12:08:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a227.home.uni-hannover.de [130.75.232.227]) by moria.seul.org (Postfix) with ESMTP id 7571C33DA9 for ; Tue, 7 Jan 2003 12:08:36 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id GAA16224; Tue, 7 Jan 2003 06:47:10 +0100 Message-ID: <20030107064710.02532@thrai.stud.uni-hannover.de> Date: Tue, 7 Jan 2003 06:47:10 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New EU_SHL Instruction Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi guys! While skimming through some AltiVec documentation the other day I noticed that they have nice `permute' and `select' instructions that let you shuffle the chunks inside a vector any way you like. It's a general instruction that can replace both `sdup' and `sbyterev' - and can be easily implemented in the current SHL execution unit. The basic function works as follows (beware, pseudo-VHDL!): function permute (A, B : in F_VECTOR) return F_VECTOR is variable Y : F_VECTOR; begin for i in 0 to NUMBER_OF_CHUNKS - 1 loop chunk(Y, i) := chunk(A, to_integer(chunk(B, i))); end loop; return Y; end permute; I therefore suggest the following ISA update: vperm.size r3, r2, r1 // new instruction: `vector permute' performs the `permute' function described above, with r3 being the selector (B), r2 being the source (A) and r1 the result (Y). Only the required bits of the selector chunks are used (e.g. bits 2...0 if there are 8 chunks). `vperm' can perform chunk-wise shifts. It's not suitable as a replacement for `cshiftl', however - you have to set up the selector register somehow, and you'll need cshiftl to do that. `cshiftr', on the other hand, may be emulated by `vperm' (in a less efficient manner). vsel.size r3, r2, r1 // new instruction: `vector select' same as `vperm', but only the least significant chunk of the result is returned (with zero extension). Again, only the required bits of the selector are used. This instruction lets you read any chunk of a register with minimal effort. Note that `vperm' is the SIMD variant of `vsel', but I think that the name is more intuitive than `svsel'. We can keep the latter as an alias, however. vseli.size $imm8, r2, r1 // new instruction: `vector select immediate' same as `vsel', but with an 8-bit unsigned immediate selector. The SIMD variant `svseli' (or `vpermi') is probably less useful, but one never knows... sdup.size r2, r1 // changed instruction will survive as an alias for `vperm.size r0, r2, r1' which has exactly the same effect. [s]byterev.size r2, r1 // unchanged will stay the same. Note that `sbyterev' can be emulated with `vperm', but the non-SIMD `byterev' can't without an additional zero-extension instruction. This change is so useful and so cheap to implement that I consider it a must-have. Any objections? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 7 19:02:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xr-0004IT-00 for ; Wed, 08 Jan 2003 07:45:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:23 +0100 (CET) Received: (qmail 20898 invoked by uid 0); 7 Jan 2003 18:04:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 7 Jan 2003 18:04:04 -0000 Received: by moria.seul.org (Postfix) id 4282C33D42; Tue, 7 Jan 2003 13:04:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A22AA33DAA; Tue, 7 Jan 2003 13:03:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 1F1E033D42 for ; Tue, 7 Jan 2003 13:03:56 -0500 (EST) Received: from a46-137.dialup.iol.cz ([194.228.137.46] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Vy4u-0003NP-00 for f-cpu@seul.org; Tue, 07 Jan 2003 19:03:53 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Vy3r-0000bU-00 for f-cpu@seul.org; Tue, 07 Jan 2003 19:02:47 +0100 Date: Tue, 7 Jan 2003 19:02:47 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] statistics of direct indexing usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, only quick result I just got. I tested with large source file (combine.c from gcc) and tried to see what if I add load/store with immediate offset to F-CPU ISA. Without imm: total insns: 29283 Labels: 2058, JMP: 2568, Conditional jumps: 3034, loadaddr: 3543 Simple L/S: 4881, post-update L/S: 618, imm-offsets: And with 6bit offset (+- 32 words): total insns: 27307 Labels: 2122, JMP: 2611, Conditional jumps: 3033, loadaddr: 3515 Simple L/S: 2236, post-update L/S: 558, imm-offsets: 2594 Also all postupdates can be converted to imms (I didn't it yet - they are in prolog/epilogs). You can see that about 70% of all load/stores are offsetted in this small range. Using it saved about 2000 instructions (9% in this file). I also expect higher speed because in original file you can see too many address "adds" tightly one after other. Even if +-32 bytes (not words) displacement it is: total insns: 27509 Labels: 2111, JMP: 2606, Conditional jumps: 3033, loadaddr: 3512 Simple L/S: 2511, post-update L/S: 561, imm-offsets: 2348 It is only about 10% worse than +-32 words imediate but still very good and resulting address is in range of up to two cachelines - so that it should not be so hard to implement it ! Your opinions ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Jan 7 20:17:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xt-0004IT-00 for ; Wed, 08 Jan 2003 07:45:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:25 +0100 (CET) Received: (qmail 28066 invoked by uid 0); 7 Jan 2003 19:19:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 7 Jan 2003 19:19:32 -0000 Received: by moria.seul.org (Postfix) id 00C6533D7F; Tue, 7 Jan 2003 14:19:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EDFD33DAE; Tue, 7 Jan 2003 14:19:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id CB13133D7F for ; Tue, 7 Jan 2003 14:19:29 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-204.jetnet.ab.ca [207.34.60.204]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h07JNKbL062682 for ; Tue, 7 Jan 2003 12:23:21 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E1B27BE.3080700@jetnet.ab.ca> Date: Tue, 07 Jan 2003 12:17:18 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N devik wrote: > Hi, > only quick result I just got. I tested with large source file > (combine.c from gcc) and tried to see what if I add load/store > with immediate offset to F-CPU ISA. Considering more people will be using user aps like browsers and viewers and word processing would that be a better test of the cpu for profile statistics? Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 7 21:02:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xu-0004IT-00 for ; Wed, 08 Jan 2003 07:45:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:26 +0100 (CET) Received: (qmail 11490 invoked by uid 0); 7 Jan 2003 20:02:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 7 Jan 2003 20:02:51 -0000 Received: by moria.seul.org (Postfix) id 18AC833D85; Tue, 7 Jan 2003 15:02:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A004533DAA; Tue, 7 Jan 2003 15:02:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id C67DD33D85 for ; Tue, 7 Jan 2003 15:02:48 -0500 (EST) Received: from a107-137.dialup.iol.cz ([194.228.137.107] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Vzvx-0004E3-00 for f-cpu@seul.org; Tue, 07 Jan 2003 21:02:46 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Vzve-0000gR-00 for f-cpu@seul.org; Tue, 07 Jan 2003 21:02:26 +0100 Date: Tue, 7 Jan 2003 21:02:26 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <3E1B27BE.3080700@jetnet.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > only quick result I just got. I tested with large source file > > (combine.c from gcc) and tried to see what if I add load/store > > with immediate offset to F-CPU ISA. > > Considering more people will be using user aps like > browsers and viewers and word processing would that > be a better test of the cpu for profile statistics? people on gcc list recommended gcc itself as representative for quick testing because the code contains mixture of many common operations. If you have other big source file, then preprocess it (gcc -E) and send to me. I'll then include results in my tests. However I think that first fcpu target are servers (especially those hosted at ISP - I have several of them I feel the need). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jan 9 00:44:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xz-0004IT-00 for ; Wed, 08 Jan 2003 07:45:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:31 +0100 (CET) Received: (qmail 22370 invoked by uid 0); 7 Jan 2003 22:43:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 7 Jan 2003 22:43:39 -0000 Received: by moria.seul.org (Postfix) id D575A33C8B; Tue, 7 Jan 2003 17:43:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A7F133D8B; Tue, 7 Jan 2003 17:43:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C09AE33C8B for ; Tue, 7 Jan 2003 17:43:35 -0500 (EST) Received: from Biathlon (lcbv2-1-85.n.club-internet.fr [213.44.12.85]) by relay-2v.club-internet.fr (Postfix) with SMTP id 128D61822 for ; Tue, 7 Jan 2003 23:43:34 +0100 (CET) Date: Wed, 8 Jan 2003 23:44:13 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage Message-Id: <20030108234413.06db26cc.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 7 Jan 2003 19:02:47 +0100 (CET) devik wrote: > Hi, > only quick result I just got. I tested with large source file > (combine.c from gcc) and tried to see what if I add load/store > with immediate offset to F-CPU ISA. > Without imm: > total insns: 29283 > Labels: 2058, JMP: 2568, Conditional jumps: 3034, loadaddr: 3543 > Simple L/S: 4881, post-update L/S: 618, imm-offsets: > > And with 6bit offset (+- 32 words): > total insns: 27307 > Labels: 2122, JMP: 2611, Conditional jumps: 3033, loadaddr: 3515 > Simple L/S: 2236, post-update L/S: 558, imm-offsets: 2594 > The question was more the comparaison with the 8 bits imm operand. Because 8 bits use 2 flags bits, not all reg-reg operations could be handle using 8 bits imm. So the question was what is the occurence of this impossible 8 bits immediat instructions, and is it harmfull for speed ? > Also all postupdates can be converted to imms (I didn't it > yet - they are in prolog/epilogs). > You can see that about 70% of all load/stores are offsetted > in this small range. Using it saved about 2000 instructions > (9% in this file). I also expect higher speed because in > original file you can see too many address "adds" tightly > one after other. > Even if +-32 bytes (not words) displacement it is: > total insns: 27509 > Labels: 2111, JMP: 2606, Conditional jumps: 3033, loadaddr: 3512 > Simple L/S: 2511, post-update L/S: 561, imm-offsets: 2348 > > It is only about 10% worse than +-32 words imediate but still > very good and resulting address is in range of up to two > cachelines - so that it should not be so hard to implement it ! > > Your opinions ? > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger > http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 7 23:47:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9xz-0004IT-01 for ; Wed, 08 Jan 2003 07:45:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:31 +0100 (CET) Received: (qmail 14758 invoked by uid 0); 7 Jan 2003 22:52:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 7 Jan 2003 22:52:22 -0000 Received: by moria.seul.org (Postfix) id 1680433D82; Tue, 7 Jan 2003 17:52:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 43FDB33D8B; Tue, 7 Jan 2003 17:52:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id E1EBF33D82 for ; Tue, 7 Jan 2003 17:52:17 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA07516; Tue, 7 Jan 2003 23:47:06 +0100 Message-ID: <20030107234705.58584@thrai.stud.uni-hannover.de> Date: Tue, 7 Jan 2003 23:47:05 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Jan 07, 2003 at 01:57:04PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 07, 2003 at 01:57:04PM +0100, devik wrote: > In light of my prev. mail about zero_extending one other > thing to discuss. > When we do compares < > >= <= we got results as 1 or -1. No, we get -1 for true and 0 for false, both truncated to the chunk size (unless we change the ISA, but I see no reason to do so). > It is very nice as gcc can then often eliminate jump. > I set 1/-1 as scc value and it now knows that: > if (a>b) b++; else b--; > can be compiled as: > cmpg r1,r2,r3 > add r2,r3,r2 Doesn't work because 0 means false. What you can do is something like this: // if (a < b) a--; cmpg a, b, temp add temp, a, a // a -= (a < b) // if (a < b) a++; cmpg a, b, temp sub temp, a, a // a += (a < b) > and "return a>b" becomes > cmpg r1,r2,r3 > neg r3,r1. Since `neg' is rather slow (two cycles), it's probably better to use `andi $1, r3, r1' to isolate the LSB. > For different modes we can add truncation like > for "return (long)a > (long)b": > cmpg.64 r1,r2,r3 > neg.32 r3,r1 > > or extension for "return (char)a > (char)b": > cmpg.8 r1,r2,r3 > neg.8 r3,r1 > widen.8 r1,r1 // what does this wide to ?? to 64bits ?? Full register size. But it isn't necessary here because r1 will be 0 or 1, and will already be zero-extended by the `neg' (or `andi') operation. > For these cases we could learn gcc's combiner that > if (a > b) > can use jmpl - it is because we know that nonequality > operator stores result in bit 0 regardless of operands > sizes and it is possibly faster than jmpz for FCPUs > with wider data types where zero flag computation > can took long time - also it relieves us from problems > with zero extending all results. That will work fine if the compare and jmpl instructions are paired. If the condition comes from somewhere else (e.g. as a function parameter), you'll have to compare with zero explicitly (usually, a zero extend operation will be sufficient). > On other side there is a big problem with == and !=. Yep, I know... > Just now I use xor and the jmpz/nz. If I want to use scc > I need to emit "cmple 0" to convert it to 1/-1 notation. > If we would like to use jmpl it is the same problem. > So that I'd like to ask, is it big problem to perform > "cmpe" in increment unit too ? I know it is done by > xor.and. but it is still not sure whether is will be there, > and if it will support more than 8 bits and even if so > it will take 2 cycles. One solution would be a `chunk-size' logical operation that zero-extends the result. If we really had `xor.b', you could just write // beq r1, r2, r4 xor.b r1, r2, r3 jmpz r3, r4 // bne r1, r2, r4 xor.b r1, r2, r3 jmpnz r3, r4 because the high part of r3 would be guaranteed to be zero. But if you want to compile something like `return (int)a == (int)b', you must use // return a == b xnor.and.q r1, r2, r3 // -1 if they're equal andi $1, r3, r1 // return a != b xor.or.q r1, r2, r3 // -1 if they're different andi $1, r3, r1 or, if `xor.or.q' is not available, // return a == b xor r1, r2, r3 cmple.q r0, r3, r3 andi $1, r3, r1 // return a != b xor r1, r2, r3 cmpg.q r0, r3, r3 andi $1, r3, r1 but that will stall for three cycles (one for xor, two for cmpg). > It could save cycles if zero flag is slow (if it is > possible at all !). > > devik > > PS: Will stall occur here (due zero flag computation) ? : > cmplei 2,r1,r2 > nop > movez r2,r0,r1 The stall will occur because cmplei takes two cycles. Zero flag computation may take another cycle. If you use `movel' instead, you should be on the safe side. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 7 22:38:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9y0-0004IT-00 for ; Wed, 08 Jan 2003 07:45:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:32 +0100 (CET) Received: (qmail 15265 invoked by uid 0); 7 Jan 2003 22:52:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 7 Jan 2003 22:52:28 -0000 Received: by moria.seul.org (Postfix) id 067BD33D8E; Tue, 7 Jan 2003 17:52:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6648533DAA; Tue, 7 Jan 2003 17:52:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id B837233D8E for ; Tue, 7 Jan 2003 17:52:20 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA07357; Tue, 7 Jan 2003 22:38:22 +0100 Message-ID: <20030107223822.58069@thrai.stud.uni-hannover.de> Date: Tue, 7 Jan 2003 22:38:22 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Jan 07, 2003 at 01:23:48PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 07, 2003 at 01:23:48PM +0100, devik wrote: > Ehh I forgot .. I fwd my reply to group too as someone might > like to comment something. > --------- > > > I finally got it up and running now, but the assembler still doesn't > > grok the code, for several reasons: > > hi, you seem to be pretty familiar with gcc internals, did you > think about changing/fixing some things directly in a code ? I wasn't sure whether your working version differs from the released one, and merging any changes might have been difficult. And I really prefer to hack my own code ;-) > I'll try to address all of these but later when I get some more > time. > Just now only some comments/questions. PLEASE read and comment > it. It would help to decide how to do some things. > > > - The ranges for immediate operands are wrong. umin/umax take > > unsigned bytes, smin/smax signed bytes, for example (btw: > > smin/smax are missing). > > ahh yes - there was a lot of experiments with ranges and this code > is not checked yet. And smin/smax was not there because I finshed > that part before you told me that there will be signed versions .. > > > - For shift/rotate ops, the second operand should always have > > QImode. That avoids an unnecessary explicit zero extension > > when the operand is not a full register. Immediate operands > > are unsigned, BTW. > > ok, one comment which is VERY important conceptional thing. Because > gcc doesn't handle SIMD implicitly (yet) I use only non-simd (except > for instrinstic funtions - not done yet). When we do some operation > in SI mode we can rely on CPU to zero extend it to 64bits (for FC0). > This holds for all insns I know about. Unfortunately, this is not always true: the ROP2 (logical) operations behave differently. They really suck when it comes to efficient non-SIMD code generation (in particular, conditional branches); we should talk about changing the ISA definition (without sacrificing the current functionality, of course). E.g. we could define the following variants: // these are new .. // truncates result to chunk size . // truncates result to chunk size mux. // truncates result to chunk size // these correspond to the current ones without `s' prefix s.. // always operates on full register (size used for combine) s. // always operates on full register (size is ignored) smux. // always operates on full register (size is ignored) Then your assumption would be valid again. > It seems natural to use it and define zero_extend as no-op (I tested > it using subregs). Other CPUs in gcc often define TRULY_NOOP_TRUNCATION > to tell that we can truncate just by pretending register as already > truncated - ie. accessing 64bit register with .16 insn truncates > DI to HI. > We can't use it on FCPU because of 2 reasons: > 1) it would colide with our no-op extension, producing no code > for case { uint i; ushort s = (uchar)i; } where is should > produce either truncate or zextend In that case, you MUST explicitly truncate `i' to 1 byte, probably with `move.8 reg(i), reg(s)', whether or not TRULY_NOOP_TRUNCATION is true. > 2) it makes jmpz/nz problematic because it tests full 64bit > register - TRULY_NOOP_TRUNCATION leaves garbage in upper > bits and if((uchar)i) where i==256 jumps even if low 8bits > is zero. If we would want TRULY_NOOP_TRUNCATION we would > need to emit "and" before each such test. I just wondered whether we can use `jmpl/nl' for conditional branches. Compare and x[n]or.{and|or} operations will always set the LSB to 1 if the result was true. > If we will decide to use noop zero_extend then the code will > be shorter and also there is no problem with rotation size above. > > > - logic operations take 9-bit signed immediate operands. > > uhh .. my 2.7 manual doesn't state it :( Where can I find it ? Dunno. I read it somewhere (maybe in the source code), and implemented it in both the assembler and the emulator. > > - STACK_BOUNDARY must be at least 64 (fullword!). FUNCTION_BOUNDARY > > should be the size of a cache line (256 bits). And even more > > important: STRICT_ALIGNMENT must be 1 (unaligned memory access > > is strictly forbidden). > > good point - it is another thing I didn't find in manual. So > that f-cpu needs natural align on all data ? Yes, up to 8 bytes at least. It's not clear yet whether machines with larger registers will have even stricter alignment constraints. For the moment, we should concentrate on the 64-bit version. > > - We pass arguments in r1...r15, not r2...r15. Leaving r1 unused > > is pointless. On the other hand, we also pass arguments in > > registers when the function has variable arguments - currently, > > gcc puts the `fixed' arguments in registers and pushes the > > rest on the stack?! > > then the manual pg 223 is wrong again. About variable arguments, > yes they go to the stack just now - I have to look how can I force > gcc to find them in registers. Again this convention seems not to be > documented. We talked about it here. In any case (varargs or not), arguments 1...15 are passed in r1...r15, the rest (if any) on the stack. > > - The function prologue is wrong. `storei $-8, r62, r61' uses > > *post*decrement, not predecrement. I suggest you calculate > > the required amount of memory, subtract it from r62, and then > > use a temporary register with postincrement for storing > > registers and initializing locals. > > I know. I simply assume that stack pointer points to next free > slot instead of last used one. Then in prolog I can use post > decrement and save several insn and additional register (which > can save us troubles with register-cache aliasing). We could declare that to be true. The caller would have to provide the first empty register-save slot (and maybe even more stack memory). There are also architectures where the caller reserves stack space for parameters it passes in registers, for scratch space and similar things. But I guess we'll have to play with different stack conventions for a while before we can make a good decision. > Epilog first substracts 8 from SP - it is ok because at end of > fn there is often a lot of free scheduler slots where this > substract insn fits at no expense (which is not case in prolog). > > However I just realized that it is not interrupt/signal safe :-( > I really have to decrement in prolog ... > > > - ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP are wrong. The > > former because it assumes predecrement again, the latter > > because the instruction is called `loadi', not `load'. > > yes. I still didn't reallized what are these macros used for. I hope > to be able to undef them completely. The compiler uses them internally, IIRC. > > - There's a much easier way to specify the pattern for `mux' > > (note the constraints for operands 3 and 4): > > > > (define_insn "*mux" > > [(set (match_operand 0 "register_operand" "=r,r") > > (ior > > (and > > (match_operand 1 "register_operand" "r,r") > > (match_operand 2 "register_operand" "r,r")) > > (and > > (not (match_operand 3 "register_operand" "1,2")) > > (match_operand 4 "register_operand" "0,0")))) > > [....] > > "@ > > mux %1,%2,%0 > > mux %2,%1,%0" > > [(set_attr "type" "logic")]) > > Are you sure ? Constraints are tested AFTER matching. So that your > version will probably took: a&b | c&~d > as one which matches and the will try to use consraints to ensure > correct register allocation. It will found that none matches and > will abort. See this except fro manual: > "More precisely, the two operands that match must include one input-only > operand and one output-only operand." > So that you can use that 0,0 but not 1,2 constraint. This kind of pattern is also used in other machine descriptions, but it really seems to be wrong - if I try to compile something like `a & b | ~c & d' with optimization, the reload pass fails :-( Ok, forget it... [...] > > - The `*loadcons' patterns look suspicious to me. Better drop them. > > In fact, better don't use loadcons at all, use loadconsx > > instead (and rely on the assembler to optimize the instruction > > sequence). > > :) They are under developement still but the really describe what > loadcons does !! > They should be also able to translate code: > a = b & 0xffffffff0000ffff | 0x45330000; > to single loadcons.1. Isn't that a rather rare case? It only seems suitable for access to certain bitfields. > Also we really need to tell gcc about all loadcons isns because splitter > will need them to do correct scheduling. Loadcons are ideal "stuffers" > for free schedule slots. That's true. But then you also should tear apart any bigger loadcons[x] sequence. > > - `loadaddri' (without `d') is correct for a LABEL_REF (while a > > SYMBOL_REF would require `loadaddrid'). But you got the offset > > wrong: it should read `loadaddri $label-.-4, reg'. > > Ok about the offset. But SYMBOL_REF doesn't imply loadaddrid ! SYMBOL_REFs > are used both for external data & code pointers and there is currently > no way to distinguish them (unfortunately) ! Thus the warning comment in > the asm. LABEL_REF is used ONLY for internal labels BUT also it can be > used with loadaddrid sometimes ! (gcc allows you to take pointer to > label, switch() statements needs jump table at label and gcc also labels > private data tables. The documentation seemed to be pretty clear that a LABEL_REF always refers to code, while a SYMBOL_REF refers to data. It even mentions that: "The reason for using a distinct expression type for code label references is so that jump optimization can distinguish them." > Thus we will need to analyze insn dataflow to found which kind of > loadaddr to use - and there are further possible cases where (G)CSE > will try to use resulting pointer for both data & code access (it > is legal to read from function pointer AFAIK). *sigh* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Thu Jan 9 06:47:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9y2-0004IT-00 for ; Wed, 08 Jan 2003 07:45:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:34 +0100 (CET) Received: (qmail 30157 invoked by uid 0); 7 Jan 2003 23:46:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 7 Jan 2003 23:46:57 -0000 Received: by moria.seul.org (Postfix) id DAC3A33D80; Tue, 7 Jan 2003 18:46:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4DC1033D8B; Tue, 7 Jan 2003 18:46:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by moria.seul.org (Postfix) with ESMTP id 4B9B133D80 for ; Tue, 7 Jan 2003 18:46:55 -0500 (EST) Received: from 113.212.62.62.9massy1-1-ro-bas-1.9tel.net (113.212.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.212.113]) by smtp4.9tel.net (Postfix) with ESMTP id BEAAC5BD71 for ; Wed, 8 Jan 2003 00:46:53 +0100 (CET) From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) Date: Thu, 9 Jan 2003 05:47:33 +0000 User-Agent: KMail/1.5 References: <20030107223822.58069@thrai.stud.uni-hannover.de> In-Reply-To: <20030107223822.58069@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301090547.34310.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Unfortunately, this is not always true: the ROP2 (logical) operations > behave differently. They really suck when it comes to efficient non-SIMD > code generation (in particular, conditional branches); we should talk > about changing the ISA definition (without sacrificing the current > functionality, of course). E.g. we could define the following variants: > > // these are new > .. // truncates result to chunk size > . // truncates result to chunk size > mux. // truncates result to chunk size > > // these correspond to the current ones without `s' prefix > s.. // always operates on full register (size used > for combine) > s. // always operates on full register (size is > ignored) > smux. // always operates on full register (size is > ignored) > > Then your assumption would be valid again. > > > - logic operations take 9-bit signed immediate operands. > > > > uhh .. my 2.7 manual doesn't state it :( Where can I find it ? > > Dunno. I read it somewhere (maybe in the source code), and implemented > it in both the assembler and the emulator. Hum, I have a problem here, I don't find any empty room for that in our ISA. How did you implement it, by using some of the OP_CODE bits ? Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 02:13:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9y7-0004IT-00 for ; Wed, 08 Jan 2003 07:45:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:39 +0100 (CET) Received: (qmail 28051 invoked by uid 0); 8 Jan 2003 00:58:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 8 Jan 2003 00:58:09 -0000 Received: by moria.seul.org (Postfix) id B591C33DB5; Tue, 7 Jan 2003 19:58:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDFD233DB4; Tue, 7 Jan 2003 19:58:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 670F933DAD for ; Tue, 7 Jan 2003 19:58:02 -0500 (EST) Received: from f-cpu.org (lcbv3-1-21.n.club-internet.fr [213.44.91.21]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 5012F17ED for ; Wed, 8 Jan 2003 01:58:00 +0100 (CET) Message-ID: <3E1B7B1F.9040505@f-cpu.org> Date: Wed, 08 Jan 2003 02:13:03 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >Ehh I forgot .. I fwd my reply to group too as someone might >like to comment something. >--------- > > >> - logic operations take 9-bit signed immediate operands. >> >> >uhh .. my 2.7 manual doesn't state it :( Where can I find it ? > > IIRC the 9-bit immediate for ROP2 is composed of a byte with a sign bit. this can be important when dealing with ASCII characters or bytes from the video framebuffer, because 7 bits is not enough. The 9nth bit is not used when SIMD mode is used for byte width, but it's useful for wider modes (non-SIMD or non-byte modes). >> - STACK_BOUNDARY must be at least 64 (fullword!). FUNCTION_BOUNDARY >> should be the size of a cache line (256 bits). And even more >> important: STRICT_ALIGNMENT must be 1 (unaligned memory access >> is strictly forbidden). >> >> > >good point - it is another thing I didn't find in manual. So >that f-cpu needs natural align on all data ? > > *all* data :-) otherwise it traps. one could program a trap handler for this, but it is left as an exercise for later (much later). Concerning the 128+ bit versions, a smarter version of the LSU could be made, but there still is a problem when a word crosses a page... >> - The function prologue is wrong. `storei $-8, r62, r61' uses >> *post*decrement, not predecrement. I suggest you calculate >> the required amount of memory, subtract it from r62, and then >> use a temporary register with postincrement for storing >> registers and initializing locals. >> >> > >I know. I simply assume that stack pointer points to next free >slot instead of last used one. Then in prolog I can use post >decrement and save several insn and additional register (which >can save us troubles with register-cache aliasing). >Epilog first substracts 8 from SP - it is ok because at end of >fn there is often a lot of free scheduler slots where this >substract insn fits at no expense (which is not case in prolog). > >However I just realized that it is not interrupt/signal safe :-( >I really have to decrement in prolog ... > > i don't see why there would be a problem. If an IRQ happens, the user stack and its pointer will not be used. Each IRQ should have its own stack space, unless you program it otherwise. And if IRQs are nested, they allocate their stack progressively. So don't worry for the epilogues. >> - The `*loadcons' patterns look suspicious to me. Better drop them. >> In fact, better don't use loadcons at all, use loadconsx >> instead (and rely on the assembler to optimize the instruction >> sequence). >> >> > >:) They are under developement still but the really describe what >loadcons does !! >They should be also able to translate code: >a = b & 0xffffffff0000ffff | 0x45330000; >to single loadcons.1. >Also we really need to tell gcc about all loadcons isns because splitter >will need them to do correct scheduling. Loadcons are ideal "stuffers" >for free schedule slots. > > BTW i don't know the latest news about loadcons and its "shifted" versions. The original loadcons(x) is, as devik said, an ideal "stuffer" because there should be no delay, and it is often critical. One example is the code snippet i shown at 19C3, it compares many characters (bytes) in parallel and the loadcons is very useful for filling the slots between the sdup and the xorn.and (sdup has at least one cycle of latency). I don't have time to discuss other aspects but i hope this helps. >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 02:13:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9y8-0004IT-00 for ; Wed, 08 Jan 2003 07:45:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:40 +0100 (CET) Received: (qmail 31089 invoked by uid 0); 8 Jan 2003 00:58:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 8 Jan 2003 00:58:11 -0000 Received: by moria.seul.org (Postfix) id EDC4633DAE; Tue, 7 Jan 2003 19:58:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 50BF633DAD; Tue, 7 Jan 2003 19:58:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id D285333DAE for ; Tue, 7 Jan 2003 19:58:03 -0500 (EST) Received: from f-cpu.org (lcbv3-1-21.n.club-internet.fr [213.44.91.21]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 9CA5F1781 for ; Wed, 8 Jan 2003 01:58:02 +0100 (CET) Message-ID: <3E1B7B20.4020903@f-cpu.org> Date: Wed, 08 Jan 2003 02:13:04 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: <3E1B27BE.3080700@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! ben franchuk wrote: > devik wrote: > >> Hi, >> only quick result I just got. I tested with large source file >> (combine.c from gcc) and tried to see what if I add load/store >> with immediate offset to F-CPU ISA. > > > Considering more people will be using user aps like > browsers and viewers and word processing would that > be a better test of the cpu for profile statistics? nope. These "user apps" are usually slow by nature. now, a lot of things in Mozilla are done by JAVA stuffs, so nobody is surprised, and the OS overhead (locks, network, threads) plays another role. However, the "average user" will want smooth streamed video and sound : making load/store more complex will reduce the overall efficiency of the processor (Read Patterson & Hennessy) and slow down the "multimedia" software which are usually nicely optimised.... Frankly, i see the 10% "overhead" as marginal, i thought it would be more. Much more could be gained by making the compiler smarter :-) > Ben. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 02:13:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9y8-0004IT-01 for ; Wed, 08 Jan 2003 07:45:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:40 +0100 (CET) Received: (qmail 15561 invoked by uid 0); 8 Jan 2003 00:58:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 8 Jan 2003 00:58:17 -0000 Received: by moria.seul.org (Postfix) id 8F6AF33DAD; Tue, 7 Jan 2003 19:58:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F9A033DB6; Tue, 7 Jan 2003 19:58:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 499BF33DAD for ; Tue, 7 Jan 2003 19:58:08 -0500 (EST) Received: from f-cpu.org (lcbv3-1-21.n.club-internet.fr [213.44.91.21]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 1BFDC16E7 for ; Wed, 8 Jan 2003 01:58:06 +0100 (CET) Message-ID: <3E1B7B25.3000509@f-cpu.org> Date: Wed, 08 Jan 2003 02:13:09 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >Hi guys! > >While skimming through some AltiVec documentation the other day I >noticed that they have nice `permute' and `select' instructions that >let you shuffle the chunks inside a vector any way you like. It's a >general instruction that can replace both `sdup' and `sbyterev' - and >can be easily implemented in the current SHL execution unit. > i don't like "replace", i'd rather say "complement". and sdup is useful in other contexts. >The basic function works as follows (beware, pseudo-VHDL!): > > function permute (A, B : in F_VECTOR) return F_VECTOR is > variable Y : F_VECTOR; > begin > for i in 0 to NUMBER_OF_CHUNKS - 1 loop > chunk(Y, i) := chunk(A, to_integer(chunk(B, i))); > end loop; > return Y; > end permute; > > IIRC, this instruction has already been discussed a long time ago. And, AFAIK, there is an inherent limitation in the ALTIVEC version : the word size is limited (256 bits). If there is a simple way to break this limit, and if implementing it is not too heavy, that would be a good thing. But it was not successful in the past. >I therefore suggest the following ISA update: > > vperm.size r3, r2, r1 // new instruction: `vector permute' > > performs the `permute' function described above, with r3 being > the selector (B), r2 being the source (A) and r1 the result > (Y). Only the required bits of the selector chunks are used > (e.g. bits 2...0 if there are 8 chunks). > > btw, is there a notion of SIMD here ? that is : is the SIMD flag used ? And is the index size as large as the chunk ? so if there are 16-bit chunks, we could address 64K chunks (so the register size would not be realistically limited) > `vperm' can perform chunk-wise shifts. It's not suitable > as a replacement for `cshiftl', however - you have to > set up the selector register somehow, and you'll need > cshiftl to do that. `cshiftr', on the other hand, may > be emulated by `vperm' (in a less efficient manner). > > vsel.size r3, r2, r1 // new instruction: `vector select' > > same as `vperm', but only the least significant chunk of > the result is returned (with zero extension). Again, only the > required bits of the selector are used. This instruction lets > you read any chunk of a register with minimal effort. > > well, it's the "reverse" of sdup, right ? and vsel can be emulated with a shift. The only gain i see here is the mask. > Note that `vperm' is the SIMD variant of `vsel', but I think > that the name is more intuitive than `svsel'. We can keep the > latter as an alias, however. > > or simply "sel" :-) {grrrrr now we have to find an instruction that can be named "poivre" ....} > vseli.size $imm8, r2, r1 // new instruction: `vector select immediate' > > same as `vsel', but with an 8-bit unsigned immediate > selector. The SIMD variant `svseli' (or `vpermi') is > probably less useful, but one never knows... > > sdup.size r2, r1 // changed instruction > > will survive as an alias for `vperm.size r0, r2, r1' which has > exactly the same effect. > > In the later versions (i guess it didn't make it into the manual), the 3rd operand (that was left to zero in previous versions) indicated the number of the chunk to duplicate. So alias you made will not be enough : you would have to duplicate the first index first into a temporary register. Funny that the instruction that does that is the instruction you want to emulate :-) > [s]byterev.size r2, r1 // unchanged > > will stay the same. Note that `sbyterev' can be emulated > with `vperm', but the non-SIMD `byterev' can't without an > additional zero-extension instruction. > >This change is so useful and so cheap to implement that I consider it >a must-have. Any objections? > i want to keep my "sdup(i)", it's very very useful in most code (SIMD or not). The "HW cost" of the permutation seems to be more than byterev, but not much more. Now the question is : do we separate the SIMD instructions (permutation, selection, duplication... on chunks) from the SHL unit (which only deals with bits) ? The answer would be best answered by Michael but this is something that i would certainly do normally. There is another instruction that would be cool but not easy to define or implement : a shuffle instruction that puts the the Nth bit of the Mth chunk into the Mth bit of the Nth chunk. Usually, it is done with 64-it registers : bit 1 of byte 8 goes to bit 8 of byte 1. This is useful for example for 'interpreting masks', when a character has been detected and the resulting bytewide mask must be turned into a bitfield.... This is ok for 64-bit CPU but our case makes it difficult : how would this be in a 128-bit or 256-bit CPU ? One solution would be to allow different chunk sizes to accomodate the cases where the chunk width is not equal to the number of chunks. I guess that this instruction can be implemented with Michael's Omega shifter but the control logic that deals with the chunk sizes etc is not the easiest part. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 03:01:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9yB-0004IT-00 for ; Wed, 08 Jan 2003 07:45:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:43 +0100 (CET) Received: (qmail 29911 invoked by uid 0); 8 Jan 2003 01:46:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 8 Jan 2003 01:46:20 -0000 Received: by moria.seul.org (Postfix) id 6CB2433C68; Tue, 7 Jan 2003 20:46:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 068D533D89; Tue, 7 Jan 2003 20:46:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 2692B33C68 for ; Tue, 7 Jan 2003 20:46:18 -0500 (EST) Received: from f-cpu.org (lcbv2-1-6.n.club-internet.fr [213.44.12.6]) by relay-5v.club-internet.fr (Postfix) with ESMTP id A7EDC16A0 for ; Wed, 8 Jan 2003 02:46:32 +0100 (CET) Message-ID: <3E1B866F.3000403@f-cpu.org> Date: Wed, 08 Jan 2003 03:01:19 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >people on gcc list recommended gcc itself as representative >for quick testing because the code contains mixture of many >common operations. If you have other big source file, then >preprocess it (gcc -E) and send to me. I'll then include results >in my tests. > what about the STREAM benchmark or the FFTW library ? Another example would be video stuff lile mpeg encoders and decoders. >However I think that first fcpu target are servers (especially >those hosted at ISP - I have several of them I feel the need). > > i don't think that this is a reasonable target because ISPs want a lot of GHz and terabytes of cache, which we can't provide yet. However F-CPU can be integrated in a router, if instanciated on the tranceiver chips, or in RAID controllers for example... >devik > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 03:01:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9yC-0004IT-00 for ; Wed, 08 Jan 2003 07:45:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:44 +0100 (CET) Received: (qmail 21413 invoked by uid 0); 8 Jan 2003 01:46:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 8 Jan 2003 01:46:26 -0000 Received: by moria.seul.org (Postfix) id ED77933DB2; Tue, 7 Jan 2003 20:46:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1CEBC33DB8; Tue, 7 Jan 2003 20:46:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id D30E733DB2 for ; Tue, 7 Jan 2003 20:46:22 -0500 (EST) Received: from f-cpu.org (lcbv2-1-6.n.club-internet.fr [213.44.12.6]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 4C13417B0 for ; Wed, 8 Jan 2003 02:46:36 +0100 (CET) Message-ID: <3E1B8673.8040001@f-cpu.org> Date: Wed, 08 Jan 2003 03:01:23 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030107234705.58584@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Tue, Jan 07, 2003 at 01:57:04PM +0100, devik wrote: > >>For these cases we could learn gcc's combiner that >>if (a > b) >>can use jmpl - it is because we know that nonequality >>operator stores result in bit 0 regardless of operands >>sizes and it is possibly faster than jmpz for FCPUs >>with wider data types where zero flag computation >>can took long time - also it relieves us from problems >>with zero extending all results. >> >> >That will work fine if the compare and jmpl instructions are paired. > a bypass path between ADD, ROP2 and the decoder will be made if possible. But this can only be done when the core is complete. >If the condition comes from somewhere else (e.g. as a function parameter), >you'll have to compare with zero explicitly (usually, a zero extend >operation will be sufficient). > > > >>On other side there is a big problem with == and !=. >> >> > >Yep, I know... > > > >>Just now I use xor and the jmpz/nz. >> that's the best way, AFAIK. >> If I want to use scc >>I need to emit "cmple 0" to convert it to 1/-1 notation. >>If we would like to use jmpl it is the same problem. >>So that I'd like to ask, is it big problem to perform >>"cmpe" in increment unit too ? I know it is done by >>xor.and. but it is still not sure whether is will be there, >>and if it will support more than 8 bits and even if so >>it will take 2 cycles. >> >> >One solution would be a `chunk-size' logical operation that zero-extends >the result. If we really had `xor.b', you could just write > > // beq r1, r2, r4 > xor.b r1, r2, r3 > jmpz r3, r4 > > // bne r1, r2, r4 > xor.b r1, r2, r3 > jmpnz r3, r4 > >because the high part of r3 would be guaranteed to be zero. > > Look at the file FORMAT.txt in the snapshot : this is what is done. I don't know what is in the latest manuals (shame on me) but this is at least what i am going to implement. >But if you want to compile something like `return (int)a == (int)b', >you must use > > // return a == b > xnor.and.q r1, r2, r3 // -1 if they're equal > andi $1, r3, r1 > > Just one question : is GCC bound to this "1/0" scheme ? F-CPU is based on "0 / not 0", so in some cases we can drop the andi :-) Or, if the result is not used in a computation or mask, the LSB condition can be used. > // return a != b > xor.or.q r1, r2, r3 // -1 if they're different > andi $1, r3, r1 > >or, if `xor.or.q' is not available, > > // return a == b > xor r1, r2, r3 > cmple.q r0, r3, r3 > andi $1, r3, r1 > > // return a != b > xor r1, r2, r3 > cmpg.q r0, r3, r3 > andi $1, r3, r1 > >but that will stall for three cycles (one for xor, two for cmpg). > > yup, and fortunately it is not necessary :-) bye, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Jan 8 03:01:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18W9yD-0004IT-00 for ; Wed, 08 Jan 2003 07:45:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Jan 2003 07:45:45 +0100 (CET) Received: (qmail 19116 invoked by uid 0); 8 Jan 2003 01:46:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 8 Jan 2003 01:46:32 -0000 Received: by moria.seul.org (Postfix) id BBCD733DB8; Tue, 7 Jan 2003 20:46:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D94AD33DBB; Tue, 7 Jan 2003 20:46:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7C3FD33DB8 for ; Tue, 7 Jan 2003 20:46:30 -0500 (EST) Received: from f-cpu.org (lcbv2-1-6.n.club-internet.fr [213.44.12.6]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 54CE8169D for ; Wed, 8 Jan 2003 02:45:51 +0100 (CET) Message-ID: <3E1B867C.9060704@f-cpu.org> Date: Wed, 08 Jan 2003 03:01:32 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: <20030107223822.58069@thrai.stud.uni-hannover.de> <200301090547.34310.cedric.bail@free.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N wouah there, there seems to be some confusion .... cedric wrote: >>Unfortunately, this is not always true: the ROP2 (logical) operations >>behave differently. They really suck when it comes to efficient non-SIMD >>code generation (in particular, conditional branches); we should talk >>about changing the ISA definition (without sacrificing the current >>functionality, of course). E.g. we could define the following variants: >> >> // these are new >> .. // truncates result to chunk size >> . // truncates result to chunk size >> mux. // truncates result to chunk size >> >> // these correspond to the current ones without `s' prefix >> s.. // always operates on full register (size used >>for combine) >> s. // always operates on full register (size is >>ignored) >> smux. // always operates on full register (size is >>ignored) >> >>Then your assumption would be valid again. >> >> As far as i remember, the ROP2 instructions follow the general rule : the "size" field indicates the number of bits to write back. That is : one can do a OR on one byte or word, and the rest will be cleared. Then comes the problem of the chunk size of the COMBINE mode, it requires 2 more bits which are taken from the IMM mode so only the register form is possible when combine is needed (IIRC). >>>> - logic operations take 9-bit signed immediate operands. >>>> >>>> >>>uhh .. my 2.7 manual doesn't state it :( Where can I find it ? >>> >>> >>Dunno. I read it somewhere (maybe in the source code), and implemented >>it in both the assembler and the emulator. >> >> >Hum, I have a problem here, I don't find any empty room for that in our ISA. >How did you implement it, by using some of the OP_CODE bits ? > > IIRC, i have "stolen" a few bits from the flags. To sum up, a "normal" ROP2 has 8 bits of opcode 2 bits of size 6 src1 or 9 imm9 6 src2 6 dest and i forget the mode bits. ok i found in the file FORMAT.txt : ROP2 : 27-31 : Opcode 24-26 : function 22-23 : size flags (normal ones) 20-21 : Combine size flags (not used yet, only 00 is used for bytes) 18-19 : mode (0=normal, 1=mux, 2=Combine AND, 3=Combine OR, but see the tables for a more up to date definition) 12-17 : Reg 0 / src1 6 -11 : Reg 1 / src2 0 - 5 : Reg 2 / dest / src3 for mux ROP2i : 27-31 : Opcode 24-26 : function 22-23 : size flags (normal ones) 21 : SIMD flag [set if the imm8 is duplicated in all chunks, otherwise it is sign-extended] 20 : sign extension bit for imm8 12-18 : imm8 6 -11 : Reg 1 / src2 0 - 5 : Reg 2 / dest / src3 for mux Does this solve the problem and answers the questions ? >Cedric > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Wed Jan 8 09:47:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbu-0002TN-01 for ; Fri, 10 Jan 2003 12:46:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:02 +0100 (CET) Received: (qmail 18372 invoked by uid 0); 8 Jan 2003 08:47:34 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 8 Jan 2003 08:47:34 -0000 Received: by moria.seul.org (Postfix) id DF47A33DBC; Wed, 8 Jan 2003 03:47:33 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3EBCA33DBE; Wed, 8 Jan 2003 03:47:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14910.mail.yahoo.com (web14910.mail.yahoo.com [216.136.225.62]) by moria.seul.org (Postfix) with SMTP id 1C9CA33DBC for ; Wed, 8 Jan 2003 03:47:31 -0500 (EST) Message-ID: <20030108084730.18996.qmail@web14910.mail.yahoo.com> Received: from [132.166.133.152] by web14910.mail.yahoo.com via HTTP; Wed, 08 Jan 2003 09:47:30 CET Date: Wed, 8 Jan 2003 09:47:30 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: Re: [f-cpu] New EU_SHL Instruction To: f-cpu@seul.org In-Reply-To: <3E1B7B25.3000509@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, --- Yann Guidon a écrit : > hi ! > This is useful for example for 'interpreting masks', > when a character > has been > detected and the resulting bytewide mask must be > turned into a bitfield.... Perhaps I made a mistake, but in case of mask bytewide to bitfield, why don't use a "reduce logic" operator like and_reduce, or_reduce... ? It is certainly not enough for all cases, but it must work fine for mask. > > YG > > Just an Illusion ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 12:19:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbw-0002TN-00 for ; Fri, 10 Jan 2003 12:46:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:04 +0100 (CET) Received: (qmail 1572 invoked by uid 0); 8 Jan 2003 11:32:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 8 Jan 2003 11:32:56 -0000 Received: by moria.seul.org (Postfix) id C234233DC4; Wed, 8 Jan 2003 06:32:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4355733DC3; Wed, 8 Jan 2003 06:32:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 58E1C33DC0 for ; Wed, 8 Jan 2003 06:32:54 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WES1-0003DE-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:32:50 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WEF3-0000IJ-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:19:25 +0100 Date: Wed, 8 Jan 2003 12:19:25 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <3E1B866F.3000403@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >common operations. If you have other big source file, then > >preprocess it (gcc -E) and send to me. I'll then include results > >in my tests. > > > what about the STREAM benchmark or the FFTW library ? hmm - why not, I have FFTW here from my latest accelerometer analysis (http://luxik.cdi.cz/~devik/accel/ for interested). Once I get time I'll test. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 11:42:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbw-0002TN-01 for ; Fri, 10 Jan 2003 12:46:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:04 +0100 (CET) Received: (qmail 8208 invoked by uid 0); 8 Jan 2003 11:33:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 8 Jan 2003 11:33:06 -0000 Received: by moria.seul.org (Postfix) id 7DFBC33DC0; Wed, 8 Jan 2003 06:33:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CB8933DC9; Wed, 8 Jan 2003 06:33:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4D5F433DC0 for ; Wed, 8 Jan 2003 06:33:04 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESC-0003DE-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:01 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WDfF-0000HV-00 for f-cpu@seul.org; Wed, 08 Jan 2003 11:42:25 +0100 Date: Wed, 8 Jan 2003 11:42:25 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC and jmpz vs. jmpl In-Reply-To: <3E1B8673.8040001@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Just one question : is GCC bound to this "1/0" scheme ? > F-CPU is based on "0 / not 0", so in some cases we can drop the andi :-) > Or, if the result is not used in a computation or mask, the LSB > condition can > be used. gcc can work with compares producing 0/1, 0/-1, 0/(1<<(width-1)) or 0/garbage where some bits in garbage are 1 (currently only MSB and/or LSB). For most effecient operation the suggest 0/-1 which is easy to understand why ... F-CPU doesn't seem to be strictly 0 / not 0. All cmpxxx produces 0/-1 which is nice. Only == and != dont ... As MR said, I'd prefer jmpl where possible - it must be faster than jmpnz. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 11:15:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbx-0002TN-00 for ; Fri, 10 Jan 2003 12:46:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:05 +0100 (CET) Received: (qmail 29764 invoked by uid 0); 8 Jan 2003 11:33:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 8 Jan 2003 11:33:11 -0000 Received: by moria.seul.org (Postfix) id 1E91C33DC9; Wed, 8 Jan 2003 06:33:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0646C33DCE; Wed, 8 Jan 2003 06:33:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 33EDD33DC9 for ; Wed, 8 Jan 2003 06:33:07 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESF-0003DE-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:05 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WDF3-0000HJ-00 for f-cpu@seul.org; Wed, 08 Jan 2003 11:15:21 +0100 Date: Wed, 8 Jan 2003 11:15:21 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC and jmpz vs. jmpl In-Reply-To: <20030107234705.58584@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > thing to discuss. > > When we do compares < > >= <= we got results as 1 or -1. > > No, we get -1 for true and 0 for false, both truncated to the chunk size > (unless we change the ISA, but I see no reason to do so). ehh sorry my mistake - I was -1/0 in my mind .. and it is how I set it in gcc > Since `neg' is rather slow (two cycles), it's probably better to use > `andi $1, r3, r1' to isolate the LSB. but is we need to convert 0->0 and -1->1 neg seemed to do the job. From manual it seems that incrementer does its job with 1 cycle latency which holds for inc/dec/neg/cmp..... Who added next cycle ?? > One solution would be a `chunk-size' logical operation that zero-extends > the result. If we really had `xor.b', you could just write > > // beq r1, r2, r4 > xor.b r1, r2, r3 > jmpz r3, r4 > > // bne r1, r2, r4 > xor.b r1, r2, r3 > jmpnz r3, r4 > > because the high part of r3 would be guaranteed to be zero. yes I use it - there is no problem with xor/jmp pair other than I want to use jmpl for speed. The main (hypothetical question) was how complex is to add cmpe into incrementer - probably there would have to be XOR before it and it is too much gates, am I right ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 11:35:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbx-0002TN-01 for ; Fri, 10 Jan 2003 12:46:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:05 +0100 (CET) Received: (qmail 17338 invoked by uid 0); 8 Jan 2003 11:33:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 8 Jan 2003 11:33:25 -0000 Received: by moria.seul.org (Postfix) id EBFB133DC3; Wed, 8 Jan 2003 06:33:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA2F433DD5; Wed, 8 Jan 2003 06:33:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 88F3033DD2 for ; Wed, 8 Jan 2003 06:33:19 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESM-0003DE-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:12 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WDZ1-0000HR-00 for f-cpu@seul.org; Wed, 08 Jan 2003 11:35:59 +0100 Date: Wed, 8 Jan 2003 11:35:59 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <3E1B866F.3000403@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >However I think that first fcpu target are servers (especially > >those hosted at ISP - I have several of them I feel the need). > > > > > i don't think that this is a reasonable target because ISPs want a lot > of GHz and terabytes > of cache, which we can't provide yet. However F-CPU can be integrated in > a router, > if instanciated on the tranceiver chips, or in RAID controllers for > example... Don't kill me my ideas please ;-) I hope to see it in my web-servers. I want moderate performance BUT not 40W of temperature wasted power whci I can't cool in our 1U rack boxes. We run with 256MB ram is it IS enough for correctly writen apps. We also have highly loaded 1000 users postgresql server and 512MB ram with PIII/800 is enough. I hope 1GHz fcpu could do the job someday. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 11:04:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxby-0002TN-00 for ; Fri, 10 Jan 2003 12:46:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:06 +0100 (CET) Received: (qmail 27849 invoked by uid 0); 8 Jan 2003 11:33:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 8 Jan 2003 11:33:30 -0000 Received: by moria.seul.org (Postfix) id 3480933DC6; Wed, 8 Jan 2003 06:33:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89F0533DD2; Wed, 8 Jan 2003 06:33:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8D83633DC3 for ; Wed, 8 Jan 2003 06:33:20 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESS-0003DE-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:16 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WD4S-0000H7-00 for f-cpu@seul.org; Wed, 08 Jan 2003 11:04:24 +0100 Date: Wed, 8 Jan 2003 11:04:24 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <20030108234413.06db26cc.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Simple L/S: 2236, post-update L/S: 558, imm-offsets: 2594 > > > > The question was more the comparaison with the 8 bits imm operand. > Because 8 bits use 2 flags bits, not all reg-reg operations could be > handle using 8 bits imm. So the question was what is the occurence of > this impossible 8 bits immediat instructions, and is it harmfull for > speed ? well the test I have done just now was targeted to addressing mode with direct offsets. But to reply your question I did quick change of allowed constants from 8 to 6 bit in all immediate representations. 8bit imms: total insns: 27509 Arithm/cmp with immediate: 2212 6bit imms: total insns: 28157 Arithm/cmp with immediate: 1588 so that by shortening imm bits by 25%, we also can use them in about 25% less occurences. It seems that probability density is constant for imm occurence in the code. While we have 624 less immediate ops, total insn count is higher by 648 - it is loadcons for each such op - it doesn't mean that the code will be really slower because loadcons might fit into otherwise unused schedule slot. We need to finish gcc to produce correct code for MR's AS and then create simulator - then we will see. Is it what you wanted to know ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 12:17:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxbz-0002TN-00 for ; Fri, 10 Jan 2003 12:46:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:07 +0100 (CET) Received: (qmail 30638 invoked by uid 0); 8 Jan 2003 11:33:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 8 Jan 2003 11:33:39 -0000 Received: by moria.seul.org (Postfix) id D5C2133DDB; Wed, 8 Jan 2003 06:33:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2FC8233DDA; Wed, 8 Jan 2003 06:33:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E71DC33DC8 for ; Wed, 8 Jan 2003 06:33:34 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESg-0005c9-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:31 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WEDS-0000IH-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:17:46 +0100 Date: Wed, 8 Jan 2003 12:17:46 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) In-Reply-To: <20030107223822.58069@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > hi, you seem to be pretty familiar with gcc internals, did you > > think about changing/fixing some things directly in a code ? > > I wasn't sure whether your working version differs from the released > one, and merging any changes might have been difficult. And I really > prefer to hack my own code ;-) heh :) me not, typicaly when I have idea I fix/change any code I have at hands :) By the way, If someone would need it I can provide CVS server with php web and with accounts for all members. It could help mainain some code. > > DI to HI. > > We can't use it on FCPU because of 2 reasons: > > 1) it would colide with our no-op extension, producing no code > > for case { uint i; ushort s = (uchar)i; } where is should > > produce either truncate or zextend > > In that case, you MUST explicitly truncate `i' to 1 byte, probably > with `move.8 reg(i), reg(s)', whether or not TRULY_NOOP_TRUNCATION is > true. it is what I mean - gcc emits explicit truncation of i UNLESS I define my special noop_zero_extend :) Then gcc's truncation is killed by my optimization :-) But I will try to create special template for generic insn followed by zero_extend and will emit it as no-op in case they can be combined. It is cleaner. > > 2) it makes jmpz/nz problematic because it tests full 64bit > > register - TRULY_NOOP_TRUNCATION leaves garbage in upper > > bits and if((uchar)i) where i==256 jumps even if low 8bits > > is zero. If we would want TRULY_NOOP_TRUNCATION we would > > need to emit "and" before each such test. > > I just wondered whether we can use `jmpl/nl' for conditional branches. > Compare and x[n]or.{and|or} operations will always set the LSB to 1 if > the result was true. :) it is what my other mail was about :) it is nice that we have similar ideas. for != is might be enough to use xor.nn (non simd zero extended) and jmpz - it will take the same time az x[n]or.{and|or} + jmpl. With cmpe it could be even faster but .... > > good point - it is another thing I didn't find in manual. So > > that f-cpu needs natural align on all data ? > > Yes, up to 8 bytes at least. It's not clear yet whether machines with > larger registers will have even stricter alignment constraints. For > the moment, we should concentrate on the 64-bit version. "at least" ? I suppose 32bit in needs to be "naturaly" (32bit) aligned, ok ? > > yes. I still didn't reallized what are these macros used for. I hope > > to be able to undef them completely. > > The compiler uses them internally, IIRC. hmm I found it only in final.c. and some targets doesn't define them at all - I'll have to look at it. > > "More precisely, the two operands that match must include one input-only > > operand and one output-only operand." > > So that you can use that 0,0 but not 1,2 constraint. > > This kind of pattern is also used in other machine descriptions, > but it really seems to be wrong - if I try to compile something like > `a & b | ~c & d' with optimization, the reload pass fails :-( > Ok, forget it... :) for your information, these targets uses more complex predicates to ensure that when the insn is selected then just one of the 1,2 constraint will be met for sure. Constraints are them only used to select correct insn format. There is warning in manual that you can't use constraints for selecting whether an insn can be matched by template - this is job of predicates. > > :) They are under developement still but the really describe what > > loadcons does !! > > They should be also able to translate code: > > a = b & 0xffffffff0000ffff | 0x45330000; > > to single loadcons.1. > > Isn't that a rather rare case? It only seems suitable for access to > certain bitfields. yes it is of course. But if you want compined to be able to use and split them you need to descrtibe their behaviour. And the description I used is perfectly valid. > > Also we really need to tell gcc about all loadcons isns because splitter > > will need them to do correct scheduling. Loadcons are ideal "stuffers" > > for free schedule slots. > > That's true. But then you also should tear apart any bigger > loadcons[x] sequence. this is what splitter does. we can emit assembler directives to get particular parts of larger constant. > > Ok about the offset. But SYMBOL_REF doesn't imply loadaddrid ! SYMBOL_REFs > > are used both for external data & code pointers and there is currently > > no way to distinguish them (unfortunately) ! Thus the warning comment in > > the asm. LABEL_REF is used ONLY for internal labels BUT also it can be > > used with loadaddrid sometimes ! (gcc allows you to take pointer to > > label, switch() statements needs jump table at label and gcc also labels > > private data tables. > > The documentation seemed to be pretty clear that a LABEL_REF always > refers to code, while a SYMBOL_REF refers to data. It even mentions > that: > > "The reason for using a distinct expression type for code label > references is so that jump optimization can distinguish them." ok here is part of generated switch stat: (insn 101 99 102 (set (reg:DI 83) (label_ref:DI 107)) -1 (nil) (expr_list:REG_EQUAL (label_ref:DI 107) (nil))) (label_ref:DI 107) is label of jump table. Here we need loadaddrid even if it is not clear. And below is excerpt of code loading function pointer address of function f and data item g: (insn 13 11 15 (set (reg/f:DI 72) (symbol_ref:DI ("f"))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI ("f")) (nil))) (insn 15 13 17 (set (reg/f:DI 74) (symbol_ref:DI ("g"))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI ("g")) (nil))) As you see both are symbol_ref without any info whether they are data or code pointer. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 12:31:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc0-0002TN-00 for ; Fri, 10 Jan 2003 12:46:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:08 +0100 (CET) Received: (qmail 21548 invoked by uid 0); 8 Jan 2003 11:33:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 8 Jan 2003 11:33:50 -0000 Received: by moria.seul.org (Postfix) id 2B9B133DDC; Wed, 8 Jan 2003 06:33:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 481E333DDE; Wed, 8 Jan 2003 06:33:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id ADB3933DDC for ; Wed, 8 Jan 2003 06:33:39 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WESm-0006LC-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:33:37 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WERA-0000IP-00 for f-cpu@seul.org; Wed, 08 Jan 2003 12:31:56 +0100 Date: Wed, 8 Jan 2003 12:31:56 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] (next) crazy idea about immediates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi again, during night I got other crazy idea - but interesting. All data needs to be aligned. Ok. We can also suggest aligning structures to cacheline boundary (and malloc would return such aligned pointers). We could support load/store with 5bit immediate value which would be ORed with physical address in register. This way there is no need to change LSU working, no other pipeline stage, no problems with exceptions. When compiler knows that pointer is aligned to ANY more than natural boundary it can use indexing because it indexs INSIDE of single cache-line. For example when generating epilog I know size of local store. If I need 10 bytes of it, I align it to 16bytes and can use indexing to access it. For latter multiisue 64bit fcpu it allows to schedule up to LSU 4 64bit insn with single pointer in paralel. Major problem is when we don't know alignment of pointer - for example when some program uses it's own allocators not cache-line aligned. But for example linux kernel allocator does is correctly. Gcc should find whether pointer is known to be aligned. anyone interested ? ;) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 03:10:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc0-0002TN-01 for ; Fri, 10 Jan 2003 12:46:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:08 +0100 (CET) Received: (qmail 9546 invoked by uid 0); 8 Jan 2003 12:24:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 8 Jan 2003 12:24:16 -0000 Received: by moria.seul.org (Postfix) id 713D233DBF; Wed, 8 Jan 2003 07:24:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B934333DC8; Wed, 8 Jan 2003 07:24:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a073.home.uni-hannover.de [130.75.232.73]) by moria.seul.org (Postfix) with ESMTP id 3720033DBF for ; Wed, 8 Jan 2003 07:24:12 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA08546; Wed, 8 Jan 2003 03:10:24 +0100 Message-ID: <20030108031024.22767@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 03:10:24 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] `cshift' redesign Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi *, while playing with the new `permute' feature, I also noticed that there is room for a more complex `cshift' instruction; therefore, its definition will change as follows: cshiftl[.size] [r3,]r2,r1 // changed instruction cshiftr[.size] [r3,]r2,r1 // changed instruction shifts r2 left (right) by a single chunk (as indicated by the size flags) and puts the result in r1. The new chunk that is `shifted in' at the top (bottom) is taken from the least significant (= lowest) chunk of r3; if r3 is not specified, the bits come from r0 (that is, they are zero). The old syntax will continue to work: the former `cshiftl r2, r1' will translate to `cshiftl.64 r0, r2, r1' which is exactly the same; similarly, `cshiftr r2, r1' translates to `cshiftr.64 r0, r2, r1'. Advantages of the new instruction are that you can save the `or' step when you combine values from two registers, and that it also works on smaller chunks. There are also funny special cases that might be useful: cshiftl.sz r1, r2, r1 replaces all but the lowest chunk of r1 with left-shifted chunks from r2 cshiftl.sz r2, r2, r1 duplicates the lowest chunk of r2 and shifts the rest cshiftr.sz r2, r2, r1 rotates r2 right by a single chunk cshiftr.sz r2, r1, r1 cshiftr.sz r3, r2, r2 cshiftr.sz r4, r3, r3 cshiftr.sz r5, r4, r4 ... shift register (e.g. for digital signal processing). Note that there are no dependencies (= no stalls!) between the shift instructions. Here's the instruction encoding, for the manual: 31-24 OP_CSHIFT 23-22 size (as usual) 21-20 unused (0) 19 0=left, 1=right 18 unused (0) 17-12 r3 11- 6 r2 5- 0 r1 This instruction is optional for a 64-bit processor but mandatory for `wider' F-CPU versions. It is already implemented, though, as well as the new vector permute functions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jan 8 15:08:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc3-0002TN-00 for ; Fri, 10 Jan 2003 12:46:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:11 +0100 (CET) Received: (qmail 28850 invoked by uid 0); 8 Jan 2003 14:08:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 8 Jan 2003 14:08:51 -0000 Received: by moria.seul.org (Postfix) id 7204733DC8; Wed, 8 Jan 2003 09:08:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C54C733DCF; Wed, 8 Jan 2003 09:08:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 6F8FB33DC8 for ; Wed, 8 Jan 2003 09:08:22 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200301081408.0ce8; Wed, 8 Jan 2003 14:08:12 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] statistics of direct indexing usage From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jan 2003 14:08:12 GMT Message-id: <200301081408.0ce8@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: devik A: Date: 08/01/03 Objet: Re: [f-cpu] statistics of direct indexing usage > > Simple L/S: 2236, post-update L/S: 558, imm-offsets: 259= 4 > > > > The question was more the comparaison with the 8 bits imm = operand. > Because 8 bits use 2 flags bits, not all reg-reg operation= s could be > handle using 8 bits imm. So the question was what is the o= ccurence of > this impossible 8 bits immediat instructions, and is it ha= rmfull for > speed ? well the test I have done just now was targeted to addressin= g mode with direct offsets. But to reply your question I did quick change of allowed con= stants from 8 to 6 bit in all immediate representations. 8bit imms: total insns: 27509 Arithm/cmp with immediate: 2212 6bit imms: total insns: 28157 Arithm/cmp with immediate: 1588 so that by shortening imm bits by 25%, we also can use them in about 25% less occurences. It seems that probability density is constant for imm occurence in the code. While we have 624 less immediate ops, total insn count is higher by 648 - it is loadcons for each such op - it doesn't mean that the code will be really slower because loadcons mi= ght fit into otherwise unused schedule slot. We need to finish gcc to produce correct code for MR's AS an= d then create simulator - then we will see. Is it what you wanted to know ? >>> Not really. :) It's an interresting number however. The idea= was better to add the 6 bits immediat adressing mode rather than _repla= ce_ the 8 bits mode.=20 By using 8 bits immediat, you can't use some flags combinais= on. So what is the impact in the generated code (how many instruction wo= uld like to use this particular combinaison?). nicO devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 18:19:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc7-0002TN-01 for ; Fri, 10 Jan 2003 12:46:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:15 +0100 (CET) Received: (qmail 16630 invoked by uid 0); 8 Jan 2003 17:20:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Jan 2003 17:20:38 -0000 Received: by moria.seul.org (Postfix) id E1AAC33C57; Wed, 8 Jan 2003 12:20:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 679C133D01; Wed, 8 Jan 2003 12:20:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id A6D0133C57 for ; Wed, 8 Jan 2003 12:20:34 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01805; Wed, 8 Jan 2003 18:19:09 +0100 Message-ID: <20030108181909.24588@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 18:19:09 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Trying to clean up the ROP2 mess Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Subject says it all. We need to make this more regular/orthogonal, and more consistent with the way other instructions work. In particular, we should provide operation variants that - work for 8/16/32/64 bit chunks - mask off the high bits / work on full registers - use direct/and/or mode There should be the following variants (only `and' operation is shown): and.size r3, r2, r1 // r1 = r2 & r3 & CHUNK_MASK sand.size r3, r2, r1 // r1 = r2 & r3 and.and.size r3, r2, r1 // r1 = combine_and(CHUNK_SIZE, r2 & r3) & CHUNK_MASK sand.and.size r3, r2, r1 // r1 = combine_and(CHUNK_SIZE, r2 & r3) and.or.size r3, r2, r1 // r1 = combine_or(CHUNK_SIZE, r2 & r3) & CHUNK_MASK sand.or.size r3, r2, r1 // r1 = combine_or(CHUNK_SIZE, r2 & r3) and the immediate variants: andi.size $simm9, r2, r1 // r1 = r2 & sign_ext(simm9) & CHUNK_MASK sandi.size $simm9, r2, r1 // r1 = r2 & sdup(CHUNK_SIZE, sign_ext(simm9)) Operations with an `s-' (SIMD) prefix will work on full registers while those without truncate the result to the chunk size. Due to the special nature of logic operations, `sand.size' ignores the size flags. They do matter, however, for `sand.and.size' and `sand.or.size' (indicating the `combine chunk size') and for `sandi.size' (controlling the chunk size of the immediate operand). For non-SIMD combine ops, the combine chunk size matches the result chunk size (I see not much reason to separate them). I will implement this encoding scheme in the next release of my assembler/disassembler/emulator trio. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 14:50:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc8-0002TN-00 for ; Fri, 10 Jan 2003 12:46:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:16 +0100 (CET) Received: (qmail 17228 invoked by uid 0); 8 Jan 2003 17:20:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 8 Jan 2003 17:20:44 -0000 Received: by moria.seul.org (Postfix) id 07C9F33DCA; Wed, 8 Jan 2003 12:20:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F196B33DBA; Wed, 8 Jan 2003 12:20:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 75DB933DA5 for ; Wed, 8 Jan 2003 12:20:36 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00809; Wed, 8 Jan 2003 14:50:03 +0100 Message-ID: <20030108145002.15488@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 14:50:02 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: <3E1B866F.3000403@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 08, 2003 at 12:19:25PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 12:19:25PM +0100, devik wrote: > > >common operations. If you have other big source file, then > > >preprocess it (gcc -E) and send to me. I'll then include results > > >in my tests. > > > > > what about the STREAM benchmark or the FFTW library ? > > hmm - why not, I have FFTW here from my latest accelerometer > analysis (http://luxik.cdi.cz/~devik/accel/ for interested). > Once I get time I'll test. I also have access to the CPU2000 sources (but I can't give them away). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 15:13:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc8-0002TN-01 for ; Fri, 10 Jan 2003 12:46:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:16 +0100 (CET) Received: (qmail 18098 invoked by uid 0); 8 Jan 2003 17:20:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 8 Jan 2003 17:20:56 -0000 Received: by moria.seul.org (Postfix) id 5A07533DAA; Wed, 8 Jan 2003 12:20:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 55B7D33DCD; Wed, 8 Jan 2003 12:20:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 8996F33DAA for ; Wed, 8 Jan 2003 12:20:38 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00874; Wed, 8 Jan 2003 15:13:53 +0100 Message-ID: <20030108151353.43642@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 15:13:53 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] (next) crazy idea about immediates References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 08, 2003 at 12:31:56PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 12:31:56PM +0100, devik wrote: > during night I got other crazy idea - but interesting. > All data needs to be aligned. Ok. We can also suggest > aligning structures to cacheline boundary (and malloc > would return such aligned pointers). That may cause a lot of internal fragmentation. > We could support load/store with 5bit immediate value > which would be ORed with physical address in register. Umh... yet another load/store instruction? > This way there is no need to change LSU working, no > other pipeline stage, no problems with exceptions. You'll have to check for correct alignment. [...] -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 15:00:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc9-0002TN-00 for ; Fri, 10 Jan 2003 12:46:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:17 +0100 (CET) Received: (qmail 14812 invoked by uid 0); 8 Jan 2003 17:21:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 8 Jan 2003 17:21:03 -0000 Received: by moria.seul.org (Postfix) id 70C3033DD4; Wed, 8 Jan 2003 12:20:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 46EBD33DD2; Wed, 8 Jan 2003 12:20:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 9AD2733DA5 for ; Wed, 8 Jan 2003 12:20:40 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00837; Wed, 8 Jan 2003 15:00:32 +0100 Message-ID: <20030108150032.21061@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 15:00:32 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030107234705.58584@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 08, 2003 at 11:15:21AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 11:15:21AM +0100, devik wrote: [...] > > Since `neg' is rather slow (two cycles), it's probably better to use > > `andi $1, r3, r1' to isolate the LSB. > > but is we need to convert 0->0 and -1->1 neg seemed > to do the job. From manual it seems that incrementer > does its job with 1 cycle latency which holds > for inc/dec/neg/cmp..... > Who added next cycle ?? The INC unit needs 2 cycles because it became too complex. Life's a bitch, you know... [...] > The main (hypothetical question) was how complex is to add > cmpe into incrementer - probably there would have to be XOR > before it and it is too much gates, am I right ? The XOR is already there (it's needed for cmple/cmpg/min/max), and the `reduce' tree is there as well. I could just tap its result bits and route them to the output - but that would still be a 2-cycle operation. That is, it won't be any cheaper than `xor.and'. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 14:46:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxc9-0002TN-01 for ; Fri, 10 Jan 2003 12:46:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:17 +0100 (CET) Received: (qmail 15332 invoked by uid 0); 8 Jan 2003 17:21:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 8 Jan 2003 17:21:09 -0000 Received: by moria.seul.org (Postfix) id AA5E233DD8; Wed, 8 Jan 2003 12:20:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E259D33DBA; Wed, 8 Jan 2003 12:20:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 9492A33DC1 for ; Wed, 8 Jan 2003 12:20:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00795; Wed, 8 Jan 2003 14:46:48 +0100 Message-ID: <20030108144648.51831@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 14:46:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: <20030107223822.58069@thrai.stud.uni-hannover.de> <200301090547.34310.cedric.bail@free.fr> <3E1B867C.9060704@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1B867C.9060704@f-cpu.org>; from Yann Guidon on Wed, Jan 08, 2003 at 03:01:32AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 03:01:32AM +0100, Yann Guidon wrote: [...] > As far as i remember, the ROP2 instructions follow the general rule : > the "size" field indicates the number of bits to write back. > That is : one can do a OR on one byte or word, and the rest will > be cleared. Very good. Then I'll have to change my instruction encoder/decoder. What about the `full-size' operation? > Then comes the problem of the chunk size of the COMBINE mode, > it requires 2 more bits which are taken from the IMM mode > so only the register form is possible when combine is needed (IIRC). Is it useful to separate operation and combine chunk sizes? I'd rather use the standard scheme (size + SIMD flag). [...] > ROP2 : > 27-31 : Opcode > 24-26 : function > 22-23 : size flags (normal ones) > 20-21 : Combine size flags (not used yet, only 00 is used for bytes) This is new to me. When did you change it? [...] -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 15:08:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcA-0002TN-00 for ; Fri, 10 Jan 2003 12:46:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:18 +0100 (CET) Received: (qmail 22504 invoked by uid 0); 8 Jan 2003 17:21:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 8 Jan 2003 17:21:23 -0000 Received: by moria.seul.org (Postfix) id 5AD5433DDD; Wed, 8 Jan 2003 12:20:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D147F33DCD; Wed, 8 Jan 2003 12:20:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id D6D5C33DA5 for ; Wed, 8 Jan 2003 12:20:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00859; Wed, 8 Jan 2003 15:08:04 +0100 Message-ID: <20030108150804.11302@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 15:08:04 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: <20030107223822.58069@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 08, 2003 at 12:17:46PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 12:17:46PM +0100, devik wrote: [...] > > > good point - it is another thing I didn't find in manual. So > > > that f-cpu needs natural align on all data ? > > > > Yes, up to 8 bytes at least. It's not clear yet whether machines with > > larger registers will have even stricter alignment constraints. For > > the moment, we should concentrate on the 64-bit version. > > "at least" ? I suppose 32bit in needs to be "naturaly" > (32bit) aligned, ok ? Of course. But it's not yet clear what happens with data items > 64 bits. They may have to be naturally aligned, or may need only 8-byte alignment. That depends very much on the LSU which isn't ready yet. > > > :) They are under developement still but the really describe what > > > loadcons does !! > > > They should be also able to translate code: > > > a = b & 0xffffffff0000ffff | 0x45330000; > > > to single loadcons.1. > > > > Isn't that a rather rare case? It only seems suitable for access to > > certain bitfields. > > yes it is of course. But if you want compined to be able to use and > split them you need to descrtibe their behaviour. And the description > I used is perfectly valid. Except that it lacks a description of loadcons.2 and loadcons.3 :) [...] > > The documentation seemed to be pretty clear that a LABEL_REF always > > refers to code, while a SYMBOL_REF refers to data. It even mentions > > that: > > > > "The reason for using a distinct expression type for code label > > references is so that jump optimization can distinguish them." > > ok here is part of generated switch stat: > (insn 101 99 102 (set (reg:DI 83) > (label_ref:DI 107)) -1 (nil) > (expr_list:REG_EQUAL (label_ref:DI 107) > (nil))) > > (label_ref:DI 107) is label of jump table. Here we need loadaddrid > even if it is not clear. Heck. gcc is a piece of shit, isn't it? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 14:43:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcA-0002TN-01 for ; Fri, 10 Jan 2003 12:46:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:18 +0100 (CET) Received: (qmail 16661 invoked by uid 0); 8 Jan 2003 17:21:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 8 Jan 2003 17:21:26 -0000 Received: by moria.seul.org (Postfix) id CBF8233DCD; Wed, 8 Jan 2003 12:21:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3F13733DDF; Wed, 8 Jan 2003 12:20:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id A172B33DD2 for ; Wed, 8 Jan 2003 12:20:54 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00783; Wed, 8 Jan 2003 14:43:04 +0100 Message-ID: <20030108144304.44967@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 14:43:04 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030107234705.58584@thrai.stud.uni-hannover.de> <3E1B8673.8040001@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1B8673.8040001@f-cpu.org>; from Yann Guidon on Wed, Jan 08, 2003 at 03:01:23AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 03:01:23AM +0100, Yann Guidon wrote: [...] > Just one question : is GCC bound to this "1/0" scheme ? AFAIK, gcc expects the result of a compare instruction to be either +1 or negative (that is, it can use the LSB or the MSB directly). This is NOT true for an ordinary `xor'. > F-CPU is based on "0 / not 0", so in some cases we can drop the andi :-) Only if the unused high bits are zeroed. > Or, if the result is not used in a computation or mask, the LSB > condition can > be used. Yep. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 14:36:29 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcB-0002TN-00 for ; Fri, 10 Jan 2003 12:46:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:19 +0100 (CET) Received: (qmail 30027 invoked by uid 0); 8 Jan 2003 17:21:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 8 Jan 2003 17:21:31 -0000 Received: by moria.seul.org (Postfix) id 5F58B33DD2; Wed, 8 Jan 2003 12:21:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D12433DBA; Wed, 8 Jan 2003 12:21:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 0A6B433DD0 for ; Wed, 8 Jan 2003 12:20:56 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00763; Wed, 8 Jan 2003 14:36:29 +0100 Message-ID: <20030108143629.49856@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 14:36:29 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1B7B25.3000509@f-cpu.org>; from Yann Guidon on Wed, Jan 08, 2003 at 02:13:09AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 02:13:09AM +0100, Yann Guidon wrote: > >While skimming through some AltiVec documentation the other day I > >noticed that they have nice `permute' and `select' instructions that > >let you shuffle the chunks inside a vector any way you like. It's a > >general instruction that can replace both `sdup' and `sbyterev' - and > >can be easily implemented in the current SHL execution unit. > > > i don't like "replace", i'd rather say "complement". > and sdup is useful in other contexts. It rather extends/generalizes them. > >The basic function works as follows (beware, pseudo-VHDL!): > > > > function permute (A, B : in F_VECTOR) return F_VECTOR is > > variable Y : F_VECTOR; > > begin > > for i in 0 to NUMBER_OF_CHUNKS - 1 loop > > chunk(Y, i) := chunk(A, to_integer(chunk(B, i))); > > end loop; > > return Y; > > end permute; > > > > > > IIRC, this instruction has already been discussed a long time ago. > And, AFAIK, there is an inherent limitation in the ALTIVEC version : > the word size is limited (256 bits). It should be limited by the register size. > If there is a simple way to break this limit, and if implementing it > is not too heavy, that would be a good thing. But it was not successful > in the past. It uses the same mechanism that is used for the other bytewise shuffling operations (byterev, sdup, mix, expand, cshift). > >I therefore suggest the following ISA update: > > > > vperm.size r3, r2, r1 // new instruction: `vector permute' > > > > performs the `permute' function described above, with r3 being > > the selector (B), r2 being the source (A) and r1 the result > > (Y). Only the required bits of the selector chunks are used > > (e.g. bits 2...0 if there are 8 chunks). > > > > > btw, is there a notion of SIMD here ? > that is : is the SIMD flag used ? That' answered below. This instruction is the SIMD variant of `vsel'. That is, the SIMD flag is always set. > And is the index size as large as the chunk ? > so if there are 16-bit chunks, we could address 64K chunks > (so the register size would not be realistically limited) For 8-bit chunks, there's a limit at a register size of 256*8 = 2048 bits. [...] > > vsel.size r3, r2, r1 // new instruction: `vector select' > > > > same as `vperm', but only the least significant chunk of > > the result is returned (with zero extension). Again, only the > > required bits of the selector are used. This instruction lets > > you read any chunk of a register with minimal effort. > > > > > well, it's the "reverse" of sdup, right ? > and vsel can be emulated with a shift. Shift + mask, to be precise, and only if the register size is limited to 64 bits. `vsel' is mainly directed towards wider registers. > The only gain i see here is the mask. > > > Note that `vperm' is the SIMD variant of `vsel', but I think > > that the name is more intuitive than `svsel'. We can keep the > > latter as an alias, however. > > > > > or simply "sel" :-) I wanted to indicate that the instruction belongs to a `vector' family of instructions. > {grrrrr now we have to find an instruction that can be named "poivre" ....} Huh? I guess this is some french pun, right? > > vseli.size $imm8, r2, r1 // new instruction: `vector select immediate' > > > > same as `vsel', but with an 8-bit unsigned immediate > > selector. The SIMD variant `svseli' (or `vpermi') is > > probably less useful, but one never knows... > > > > sdup.size r2, r1 // changed instruction > > > > will survive as an alias for `vperm.size r0, r2, r1' which has > > exactly the same effect. > > > > > In the later versions (i guess it didn't make it into the manual), > the 3rd operand (that was left to zero in previous versions) indicated > the number of the chunk to duplicate. So alias you made will not be > enough : you would have to duplicate the first index first into a temporary > register. Funny that the instruction that does that is the instruction > you want to emulate :-) I do not remember an `sdup' instruction that uses three operands, nor did I implement one. That would have been another logical extension; but I guess that vperm is more useful. BTW: if you're satisfied with an immediate operand, `svseli $n, r2, r1' will do what you want (duplicate chunk of r2). > > [s]byterev.size r2, r1 // unchanged > > > > will stay the same. Note that `sbyterev' can be emulated > > with `vperm', but the non-SIMD `byterev' can't without an > > additional zero-extension instruction. > > > >This change is so useful and so cheap to implement that I consider it > >a must-have. Any objections? > > > i want to keep my "sdup(i)", it's very very useful in most code (SIMD or > not). It's still there: `sdupi $imm8, r2, r1' corresponds to `vpermi $imm8, r2, r1'. `sdup r2, r1' corresponds to `vperm r0, r2, r1' or `vpermi $0, r2, r1'. If you insist, I will investigate whether `sdup r3, r2, r1' can be added. I guess it's possible (there are some unused flags). Oh BTW, I forgot the encoding (for the manual): vsel: 31-24 OP_VSEL (replaces OP_SDUP) 23-22 size 21 s- prefix 20-18 unused 17-12 r3 11- 6 r2 5- 0 r1 vseli: 31-24 OP_VSELI (new) 23-22 size 21 s- prefix 20 unused 19-12 unsigned 8-bit immediate 11- 6 r2 5- 0 r1 > The "HW cost" of the permutation seems to be more than byterev, but not > much more. In the current implementation, the cost is almost 0. Byterev & friends use a set of byte-wide muxes. Their select inputs are driven with constant values, depending on the operating mode. `vsel' uses the same muxes, but takes the select inputs from the second operand instead - that's all. It doesn't even increase the latency. > Now the question is : > do we separate the SIMD instructions (permutation, selection, > duplication... on chunks) > from the SHL unit (which only deals with bits) ? > The answer would be best answered by Michael but this is something that > i would > certainly do normally. They are already separated (kind of). Bitwise ops use the omega shifter, while bytewise ops use the mux-based `byte shuffler'. They just share input and output ports. > There is another instruction that would be cool but not easy to define > or implement : > a shuffle instruction that puts the the Nth bit of the Mth chunk > into the Mth bit of the Nth chunk. > > Usually, it is done with 64-it registers : bit 1 of byte 8 goes to bit 8 > of byte 1. > This is useful for example for 'interpreting masks', when a character > has been > detected and the resulting bytewide mask must be turned into a bitfield.... > > This is ok for 64-bit CPU but our case makes it difficult : how would this > be in a 128-bit or 256-bit CPU ? One solution would be to allow different > chunk sizes to accomodate the cases where the chunk width is not equal > to the number of chunks. > > I guess that this instruction can be implemented with Michael's Omega > shifter > but the control logic that deals with the chunk sizes etc is not the > easiest part. I'm not sure. An omega shifter is limited to a subset of all possible shuffling operations, and this one looks pretty complicated. You'd better not count on it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 8 13:33:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcC-0002TN-00 for ; Fri, 10 Jan 2003 12:46:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:20 +0100 (CET) Received: (qmail 7887 invoked by uid 0); 8 Jan 2003 17:21:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 8 Jan 2003 17:21:36 -0000 Received: by moria.seul.org (Postfix) id 8631C33DD3; Wed, 8 Jan 2003 12:21:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCC1C33DD0; Wed, 8 Jan 2003 12:21:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id CFC6833DD2 for ; Wed, 8 Jan 2003 12:21:02 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00599; Wed, 8 Jan 2003 13:33:37 +0100 Message-ID: <20030108133336.25954@thrai.stud.uni-hannover.de> Date: Wed, 8 Jan 2003 13:33:36 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: <20030107223822.58069@thrai.stud.uni-hannover.de> <200301090547.34310.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200301090547.34310.cedric.bail@free.fr>; from cedric on Thu, Jan 09, 2003 at 05:47:33AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 05:47:33AM +0000, cedric wrote: [...] > > > > - logic operations take 9-bit signed immediate operands. [...] > Hum, I have a problem here, I don't find any empty room for that in our ISA. > How did you implement it, by using some of the OP_CODE bits ? The manual entry for ROP2 operations is way out of date; the encoding is different now (uses eight opcodes instead of one). The function is encoded in bits 26-24, bits 20-12 hold the (sign-extended) immediate operand. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Jan 10 01:07:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcE-0002TN-00 for ; Fri, 10 Jan 2003 12:46:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:22 +0100 (CET) Received: (qmail 30709 invoked by uid 0); 8 Jan 2003 18:06:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 8 Jan 2003 18:06:47 -0000 Received: by moria.seul.org (Postfix) id C83AA33DBA; Wed, 8 Jan 2003 13:06:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3AE9933DC1; Wed, 8 Jan 2003 13:06:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 565E533DBA for ; Wed, 8 Jan 2003 13:06:45 -0500 (EST) Received: from 242.190.62.62.9massy1-1-ro-bas-1.9tel.net (242.190.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.190.242]) by smtp3.9tel.net (Postfix) with ESMTP id 924805BEBC for ; Wed, 8 Jan 2003 19:06:44 +0100 (CET) From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction Date: Fri, 10 Jan 2003 00:07:20 +0000 User-Agent: KMail/1.5 References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> In-Reply-To: <20030108143629.49856@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301100007.20686.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > If you insist, I will investigate whether `sdup r3, r2, r1' can be added. > I guess it's possible (there are some unused flags). Oh BTW, I forgot > the encoding (for the manual): > vsel: > 31-24 OP_VSEL (replaces OP_SDUP) > 23-22 size > 21 s- prefix > 20-18 unused > 17-12 r3 > 11- 6 r2 > 5- 0 r1 > vseli: > 31-24 OP_VSELI (new) > 23-22 size > 21 s- prefix > 20 unused > 19-12 unsigned 8-bit immediate > 11- 6 r2 > 5- 0 r1 Oh yes, that's a good idea. So everyone that propose or change an instruction must supply the encoding in the mailing-list and not only the syntaxe. It really ease my job and the manual will be more up-to-date ;-) Thanks, Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 15:27:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcG-0002TN-00 for ; Fri, 10 Jan 2003 12:46:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:24 +0100 (CET) Received: (qmail 21712 invoked by uid 0); 8 Jan 2003 22:44:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 8 Jan 2003 22:44:56 -0000 Received: by moria.seul.org (Postfix) id 7A56433DD1; Wed, 8 Jan 2003 17:44:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2480C33DD6; Wed, 8 Jan 2003 17:44:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 0849133DD1 for ; Wed, 8 Jan 2003 17:44:50 -0500 (EST) Received: from a123-137.dialup.iol.cz ([194.228.137.123] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WOwH-0007dW-00 for f-cpu@seul.org; Wed, 08 Jan 2003 23:44:46 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WHBM-0002S8-00 for f-cpu@seul.org; Wed, 08 Jan 2003 15:27:48 +0100 Date: Wed, 8 Jan 2003 15:27:48 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: Rep:Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <200301081408.0ce8@th00.opsion.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Is it what you wanted to know ? > > >>> > Not really. :) It's an interresting number however. The idea was better > to add the 6 bits immediat adressing mode rather than _replace_ the 8 > bits mode. > > By using 8 bits immediat, you can't use some flags combinaison. So what > is the impact in the generated code (how many instruction would like to > use this particular combinaison?). uh uh, can you give me please some examples of such instruction ? or you wanted to have BOTH 6bit and 8bit immediates and see which will be used ? I'm a bit lost - can't still understand .. :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 8 23:44:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcH-0002TN-00 for ; Fri, 10 Jan 2003 12:46:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:25 +0100 (CET) Received: (qmail 26778 invoked by uid 0); 8 Jan 2003 22:45:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 8 Jan 2003 22:45:03 -0000 Received: by moria.seul.org (Postfix) id BC7AA33DD7; Wed, 8 Jan 2003 17:45:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A46933DD9; Wed, 8 Jan 2003 17:45:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3919833DD7 for ; Wed, 8 Jan 2003 17:44:59 -0500 (EST) Received: from a123-137.dialup.iol.cz ([194.228.137.123] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WOwT-0008LL-00 for f-cpu@seul.org; Wed, 08 Jan 2003 23:44:57 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WOwL-0002pf-00 for f-cpu@seul.org; Wed, 08 Jan 2003 23:44:49 +0100 Date: Wed, 8 Jan 2003 23:44:49 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] loadconsx and stream hints Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Please can someone explain me syntax and semantic of latest loadconsx (and loadcons.n) so I can add them to gcc ? Also if someone can write a few words what stream bits can be good for - I can't find definition. Will there be separate caches for each stream for example ? thx, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 01:59:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcI-0002TN-00 for ; Fri, 10 Jan 2003 12:46:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:26 +0100 (CET) Received: (qmail 9754 invoked by uid 0); 9 Jan 2003 00:44:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 9 Jan 2003 00:44:19 -0000 Received: by moria.seul.org (Postfix) id 3F9EE33D01; Wed, 8 Jan 2003 19:44:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6249A33DD5; Wed, 8 Jan 2003 19:44:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 7CF1633D01 for ; Wed, 8 Jan 2003 19:44:09 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 6275C1681 for ; Thu, 9 Jan 2003 01:44:06 +0100 (CET) Message-ID: <3E1CC95F.9070406@f-cpu.org> Date: Thu, 09 Jan 2003 01:59:11 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Jan 08, 2003 at 02:13:09AM +0100, Yann Guidon wrote: > >>>While skimming through some AltiVec documentation the other day I >>>noticed that they have nice `permute' and `select' instructions that >>>let you shuffle the chunks inside a vector any way you like. It's a >>>general instruction that can replace both `sdup' and `sbyterev' - and >>>can be easily implemented in the current SHL execution unit. >>> >>i don't like "replace", i'd rather say "complement". >>and sdup is useful in other contexts. >> >> >It rather extends/generalizes them. > > hmmmmgrmblgrml .... even though "permute" generalises sdup, it does not replace it. >>IIRC, this instruction has already been discussed a long time ago. >>And, AFAIK, there is an inherent limitation in the ALTIVEC version : >>the word size is limited (256 bits). >> >> >It should be limited by the register size. > > i don't remember the discussion about this, but there was some kind of inherent limitation related to the index size ... If we set that the size of the index equals the size of the chunk, that should be ok. >>>I therefore suggest the following ISA update: >>> >>> vperm.size r3, r2, r1 // new instruction: `vector permute' >>> >>> performs the `permute' function described above, with r3 being >>> the selector (B), r2 being the source (A) and r1 the result >>> (Y). Only the required bits of the selector chunks are used >>> (e.g. bits 2...0 if there are 8 chunks). >>> >>> >>btw, is there a notion of SIMD here ? >>that is : is the SIMD flag used ? >> >> > >That' answered below. This instruction is the SIMD variant of `vsel'. >That is, the SIMD flag is always set. > > then it is not really a different instruction .... >>And is the index size as large as the chunk ? >>so if there are 16-bit chunks, we could address 64K chunks >>(so the register size would not be realistically limited) >> >> >For 8-bit chunks, there's a limit at a register size of 256*8 = 2048 bits. > > huh, that should be enough... :-) >[...] > > >>> vsel.size r3, r2, r1 // new instruction: `vector select' >>> >>> same as `vperm', but only the least significant chunk of >>> the result is returned (with zero extension). Again, only the >>> required bits of the selector are used. This instruction lets >>> you read any chunk of a register with minimal effort. >>> >>well, it's the "reverse" of sdup, right ? >>and vsel can be emulated with a shift. >> >> >Shift + mask, to be precise, and only if the register size is limited >to 64 bits. `vsel' is mainly directed towards wider registers. > > well, it seems very close to sdup. >>The only gain i see here is the mask. >> >>> Note that `vperm' is the SIMD variant of `vsel', but I think >>> that the name is more intuitive than `svsel'. We can keep the >>> latter as an alias, however. >>> >>> >>or simply "sel" :-) >> >> >I wanted to indicate that the instruction belongs to a `vector' family >of instructions. > > well, here, the word SIMD is used in this meaning, so we can drop the "v" ... >>{grrrrr now we have to find an instruction that can be named "poivre" ....} >> >> >Huh? I guess this is some french pun, right? > > in french, "sel" = "salt", and "poivre" = you guess what :-) >>> vseli.size $imm8, r2, r1 // new instruction: `vector select immediate' >>> >>> same as `vsel', but with an 8-bit unsigned immediate >>> selector. The SIMD variant `svseli' (or `vpermi') is >>> probably less useful, but one never knows... >>> >>> sdup.size r2, r1 // changed instruction >>> >>> will survive as an alias for `vperm.size r0, r2, r1' which has >>> exactly the same effect. >>> >>> >>> >>> >>In the later versions (i guess it didn't make it into the manual), >>the 3rd operand (that was left to zero in previous versions) indicated >>the number of the chunk to duplicate. So alias you made will not be >>enough : you would have to duplicate the first index first into a temporary >>register. Funny that the instruction that does that is the instruction >>you want to emulate :-) >> >> > >I do not remember an `sdup' instruction that uses three operands, nor >did I implement one. That would have been another logical extension; >but I guess that vperm is more useful. BTW: if you're satisfied with >an immediate operand, `svseli $n, r2, r1' will do what you want >(duplicate chunk of r2). > > it's not doing sdup completely. The 3rd register operand is useful to avoid a shift in front of a "bare" sdup : sdup r1, r2, r3 replaces shiftr r1*8, r2, r2 sdup r2, r3 this saves around 2 cycles, if i'm not mistaken and if there is no couple of intructions to fill in the gap. The typical example is when a bitmap is expanded to a framebuffer. There is a sdup that duplicates a byte to a whole register, but when the sdup is in a loop, the original bitmask has to be rotated before sdup. Now, with the 3-operand sdup, there is no need to shift, the loop counter addresses the byte in the register :-) >>> [s]byterev.size r2, r1 // unchanged >>> >>> will stay the same. Note that `sbyterev' can be emulated >>> with `vperm', but the non-SIMD `byterev' can't without an >>> additional zero-extension instruction. >>> >>>This change is so useful and so cheap to implement that I consider it >>>a must-have. Any objections? >>> >>> >>> >>i want to keep my "sdup(i)", it's very very useful in most code (SIMD or >>not). >> >> > >It's still there: > > `sdupi $imm8, r2, r1' corresponds to `vpermi $imm8, r2, r1'. > `sdup r2, r1' corresponds to `vperm r0, r2, r1' or `vpermi $0, r2, r1'. > >If you insist, I will investigate whether `sdup r3, r2, r1' can be added. >I guess it's possible (there are some unused flags). > i'm sure it can :-) > Oh BTW, I forgot the encoding (for the manual): > > vsel: > 31-24 OP_VSEL (replaces OP_SDUP) > 23-22 size > 21 s- prefix > 20-18 unused > 17-12 r3 > 11- 6 r2 > 5- 0 r1 > > vseli: > 31-24 OP_VSELI (new) > 23-22 size > 21 s- prefix > 20 unused > 19-12 unsigned 8-bit immediate > 11- 6 r2 > 5- 0 r1 > > > >>The "HW cost" of the permutation seems to be more than byterev, but not >>much more. >> >> >In the current implementation, the cost is almost 0. Byterev & friends use >a set of byte-wide muxes. Their select inputs are driven with constant >values, depending on the operating mode. `vsel' uses the same muxes, >but takes the select inputs from the second operand instead - that's all. >It doesn't even increase the latency. > > it works more or less the same for sdup ... >>Now the question is : >> do we separate the SIMD instructions (permutation, selection, >>duplication... on chunks) >>from the SHL unit (which only deals with bits) ? >>The answer would be best answered by Michael but this is something that >>i would certainly do normally. >> >> >They are already separated (kind of). > then why is there still one unit ? > Bitwise ops use the omega >shifter, while bytewise ops use the mux-based `byte shuffler'. >They just share input and output ports. > > if routing becomes too complex, then a split must be considered.... >>There is another instruction that would be cool but not easy to define >>or implement : >> a shuffle instruction that puts the the Nth bit of the Mth chunk >>into the Mth bit of the Nth chunk. >> >>Usually, it is done with 64-it registers : bit 1 of byte 8 goes to bit 8 >>of byte 1. >>This is useful for example for 'interpreting masks', when a character >>has been >>detected and the resulting bytewide mask must be turned into a bitfield.... >> >>This is ok for 64-bit CPU but our case makes it difficult : how would this >>be in a 128-bit or 256-bit CPU ? One solution would be to allow different >>chunk sizes to accomodate the cases where the chunk width is not equal >>to the number of chunks. >> >>I guess that this instruction can be implemented with Michael's Omega >>shifter >>but the control logic that deals with the chunk sizes etc is not the >>easiest part. >> >> >I'm not sure. An omega shifter is limited to a subset of all possible >shuffling operations, and this one looks pretty complicated. You'd >better not count on it. > i'm pretty sure that an omega network can do this, but it probably depends on the number of stages. This operation is probably mentioned somewhere, and it remembers me of something similar in Knuth's MMIX. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 01:59:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcJ-0002TN-00 for ; Fri, 10 Jan 2003 12:46:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:27 +0100 (CET) Received: (qmail 7129 invoked by uid 0); 9 Jan 2003 00:44:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 9 Jan 2003 00:44:24 -0000 Received: by moria.seul.org (Postfix) id 2AD6633D89; Wed, 8 Jan 2003 19:44:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0A1733DDE; Wed, 8 Jan 2003 19:44:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 1852933D89 for ; Wed, 8 Jan 2003 19:44:19 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 30DF316AE for ; Thu, 9 Jan 2003 01:43:39 +0100 (CET) Message-ID: <3E1CC96B.6090403@f-cpu.org> Date: Thu, 09 Jan 2003 01:59:23 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] (next) crazy idea about immediates References: <20030108151353.43642@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Wed, Jan 08, 2003 at 12:31:56PM +0100, devik wrote: > >>during night I got other crazy idea - but interesting. >>All data needs to be aligned. Ok. We can also suggest >>aligning structures to cacheline boundary (and malloc >>would return such aligned pointers). >> >> >That may cause a lot of internal fragmentation. > > >>We could support load/store with 5bit immediate value >>which would be ORed with physical address in register. >> >> >Umh... yet another load/store instruction? > > looks so. >>This way there is no need to change LSU working, no >>other pipeline stage, no problems with exceptions. >> >> >You'll have to check for correct alignment. > >[...] > from the hardware point of view, the 5 bits immediate that is ORed has few potential problems, excepts that it is only useful for "small integers" (using 64-bit data reduces the usefulness to 2 bits) and alignment must be taken into account (here, the same policy can be used : the LSB of the constant can be cleared, or a trap is triggered if an error condition is detected). The pointer's LSBs are already checked for the normal LSU operations, but another condition would be checked : if the LSB AND the IMM5 give at least a "1" bit. this can be used on purpose but usually it means some kind of misalignment or overflow. Another solution that increase the efficiency of the 5-bit immediate would be to shit the imm5 according to the data size, but here there are risks of going out of the cache line, which makes things too complex for the current LSU. I can see no serious objection to this instruction, even if it does not follow the logic behind the LSU principle, but the reduced range of 5 bits makes it possible. Then, the exact behaviour about alignment must be defined but it should be ok. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 01:59:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcK-0002TN-00 for ; Fri, 10 Jan 2003 12:46:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:28 +0100 (CET) Received: (qmail 10958 invoked by uid 0); 9 Jan 2003 00:44:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 9 Jan 2003 00:44:31 -0000 Received: by moria.seul.org (Postfix) id 9AE0233DE2; Wed, 8 Jan 2003 19:44:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 441AD33DE5; Wed, 8 Jan 2003 19:44:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 9430533DE2 for ; Wed, 8 Jan 2003 19:44:25 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 27FF11694 for ; Thu, 9 Jan 2003 01:43:45 +0100 (CET) Message-ID: <3E1CC970.1080801@f-cpu.org> Date: Thu, 09 Jan 2003 01:59:28 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Trying to clean up the ROP2 mess References: <20030108181909.24588@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hello, Michael Riepe wrote: >Subject says it all. We need to make this more regular/orthogonal, and >more consistent with the way other instructions work. In particular, >we should provide operation variants that > > - work for 8/16/32/64 bit chunks > - mask off the high bits / work on full registers > - use direct/and/or mode > > did you read one of my mails of yesterday about this subject ? did you look at FORMAT.txt in the source snapshot ? why is MUX not included ? (it is performed by the ROP2 unit and uses a subset of the functions) >There should be the following variants (only `and' operation is shown): > > and.size r3, r2, r1 // r1 = r2 & r3 & CHUNK_MASK > sand.size r3, r2, r1 // r1 = r2 & r3 > and.and.size r3, r2, r1 // r1 = combine_and(CHUNK_SIZE, r2 & r3) & CHUNK_MASK > sand.and.size r3, r2, r1 // r1 = combine_and(CHUNK_SIZE, r2 & r3) > and.or.size r3, r2, r1 // r1 = combine_or(CHUNK_SIZE, r2 & r3) & CHUNK_MASK > sand.or.size r3, r2, r1 // r1 = combine_or(CHUNK_SIZE, r2 & r3) > >and the immediate variants: > > andi.size $simm9, r2, r1 // r1 = r2 & sign_ext(simm9) & CHUNK_MASK > sandi.size $simm9, r2, r1 // r1 = r2 & sdup(CHUNK_SIZE, sign_ext(simm9)) > >Operations with an `s-' (SIMD) prefix will work on full registers while >those without truncate the result to the chunk size. Due to the special >nature of logic operations, `sand.size' ignores the size flags. They do >matter, however, for `sand.and.size' and `sand.or.size' (indicating the >`combine chunk size') and for `sandi.size' (controlling the chunk size of >the immediate operand). For non-SIMD combine ops, the combine chunk size >matches the result chunk size (I see not much reason to separate them). > > well, we don't converge on these last details but the encoding i proposed is able to do that (except that there are 2 size fields, one for the writeback size and one for the combine chunk size). >I will implement this encoding scheme in the next release of my >assembler/disassembler/emulator trio. > you're going to have too much fun : you're insane :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 01:59:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcL-0002TN-00 for ; Fri, 10 Jan 2003 12:46:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:29 +0100 (CET) Received: (qmail 8088 invoked by uid 0); 9 Jan 2003 00:44:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 9 Jan 2003 00:44:35 -0000 Received: by moria.seul.org (Postfix) id 31ABA33DDE; Wed, 8 Jan 2003 19:44:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 311FF33DE8; Wed, 8 Jan 2003 19:44:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id C5FFF33DE5 for ; Wed, 8 Jan 2003 19:44:31 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 5388D1688 for ; Thu, 9 Jan 2003 01:44:46 +0100 (CET) Message-ID: <3E1CC977.7070803@f-cpu.org> Date: Thu, 09 Jan 2003 01:59:35 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Just an Illusion wrote: >Hello, > --- Yann Guidon a écrit : > hi ! > > >>This is useful for example for 'interpreting masks', >>when a character has been >>detected and the resulting bytewide mask must be >>turned into a bitfield.... >> >> >Perhaps I made a mistake, but in case of mask bytewide >to bitfield, why don't use a "reduce logic" operator >like and_reduce, or_reduce... ? > > and_reduce (or "combine" as written in ROP2) is not possible for very wide data. Furthermore, the xorn.and trick is useful for "detecting" that a byte corresponds, but if you need to find the index of the character, the "obvious" answer is to loop over the register. if you have a result of 0x00FF000000000000, it's not a good solution. So the idea is to "transpose" the bits in the word, that would become 0x4040404040404040 and the last byte can then ben binary encoded in INC (if it's implemented). >It is certainly not enough for all cases, but it must >work fine for mask. > There are several kinds of masks and bitfields and the ROP2 operations are not always enough. >>YG >> >Just an Illusion > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 01:59:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcL-0002TN-01 for ; Fri, 10 Jan 2003 12:46:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:29 +0100 (CET) Received: (qmail 8365 invoked by uid 0); 9 Jan 2003 00:44:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 9 Jan 2003 00:44:48 -0000 Received: by moria.seul.org (Postfix) id 5065D33DE1; Wed, 8 Jan 2003 19:44:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B081733DE0; Wed, 8 Jan 2003 19:44:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id D6CF933DE4 for ; Wed, 8 Jan 2003 19:44:44 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-1v.club-internet.fr (Postfix) with ESMTP id F0B3C16D6 for ; Thu, 9 Jan 2003 01:44:03 +0100 (CET) Message-ID: <3E1CC983.8090108@f-cpu.org> Date: Thu, 09 Jan 2003 01:59:47 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] loadconsx and stream hints References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >Please can someone explain me syntax and semantic >of latest loadconsx (and loadcons.n) so I can add >them to gcc ? > i prefer to stick with the old/original "loadcons[x]" which writes a 16-bit constant to a given part of a register. >Also if someone can write a few words what stream >bits can be good for - I can't find definition. Will >there be separate caches for each stream for example ? > > stream hints are used to differentiate unrelated data streams, that is, flows (in and out) from memory from separate, independent arrays. By default there is no hint (hint #0) but this can be useful in future architectures where multiple Load/Store Units are implemented or when there is a direct SDRAM interface (the stream hint bit can then serve as a bank number, in order to optimise prefetch time and bandwidth). It is not yet used and can remain zero, but i guess that the SDRAM bank trick will be used first because it simplifies the SDRAM interface logic. A "hint number" (or bank number, or transaction number) can be allocated to the stack, the others are used for continuous (streaming) access to main memory (for example, one is needed for memset and two are needed for strcmp). >thx, devik > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 03:03:29 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcM-0002TN-01 for ; Fri, 10 Jan 2003 12:46:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:30 +0100 (CET) Received: (qmail 8709 invoked by uid 0); 9 Jan 2003 01:48:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Jan 2003 01:48:28 -0000 Received: by moria.seul.org (Postfix) id 5DD2533DDF; Wed, 8 Jan 2003 20:48:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C269433DE3; Wed, 8 Jan 2003 20:48:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id CD17B33DDF for ; Wed, 8 Jan 2003 20:48:25 -0500 (EST) Received: from f-cpu.org (lcbv3-1-11.n.club-internet.fr [213.44.91.11]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 61D2316AC for ; Thu, 9 Jan 2003 02:47:45 +0100 (CET) Message-ID: <3E1CD871.7030806@f-cpu.org> Date: Thu, 09 Jan 2003 03:03:29 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: <3E1B866F.3000403@f-cpu.org> <20030108145002.15488@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Jan 08, 2003 at 12:19:25PM +0100, devik wrote: > > >>>>common operations. If you have other big source file, then >>>>preprocess it (gcc -E) and send to me. I'll then include results >>>>in my tests. >>>> >>>what about the STREAM benchmark or the FFTW library ? >>> >>> >>hmm - why not, I have FFTW here from my latest accelerometer >>analysis (http://luxik.cdi.cz/~devik/accel/ for interested). >>Once I get time I'll test. >> >> >I also have access to the CPU2000 sources (but I can't give them away). > If the benchmark is not publicly available, then it's not worth it :-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 03:03:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcN-0002TN-00 for ; Fri, 10 Jan 2003 12:46:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:31 +0100 (CET) Received: (qmail 12328 invoked by uid 0); 9 Jan 2003 01:48:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 9 Jan 2003 01:48:47 -0000 Received: by moria.seul.org (Postfix) id 2414D33DE3; Wed, 8 Jan 2003 20:48:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 657CF33DE5; Wed, 8 Jan 2003 20:48:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 8F30533DE0 for ; Wed, 8 Jan 2003 20:48:27 -0500 (EST) Received: from f-cpu.org (lcbv3-1-11.n.club-internet.fr [213.44.91.11]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 2E39C16A4 for ; Thu, 9 Jan 2003 02:47:48 +0100 (CET) Message-ID: <3E1CD874.7000009@f-cpu.org> Date: Thu, 09 Jan 2003 03:03:32 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) References: <20030107223822.58069@thrai.stud.uni-hannover.de> <200301090547.34310.cedric.bail@free.fr> <3E1B867C.9060704@f-cpu.org> <20030108144648.51831@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Wed, Jan 08, 2003 at 03:01:32AM +0100, Yann Guidon wrote: >[...] > > >>As far as i remember, the ROP2 instructions follow the general rule : >>the "size" field indicates the number of bits to write back. >>That is : one can do a OR on one byte or word, and the rest will >>be cleared. >> >> >Very good. Then I'll have to change my instruction encoder/decoder. >What about the `full-size' operation? > > it's done with the SIMD flag. >>Then comes the problem of the chunk size of the COMBINE mode, >>it requires 2 more bits which are taken from the IMM mode >>so only the register form is possible when combine is needed (IIRC). >> >> >Is it useful to separate operation and combine chunk sizes? I'd rather >use the standard scheme (size + SIMD flag). > > what if you want to compare and combine 2 16-bit chunks in parallel ? in the conference, i gave an example code that compares 4 bytes in parallel, so there are only 32 useful bits. >[...] > > >>ROP2 : >>27-31 : Opcode >>24-26 : function >>22-23 : size flags (normal ones) >>20-21 : Combine size flags (not used yet, only 00 is used for bytes) >> >> > >This is new to me. When did you change it? > > i guess it is quite old, maybe 16 months (when i was staying at Graham's place). it can probably be traced by looking in old snapshots.... >[...] > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 03:03:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcN-0002TN-01 for ; Fri, 10 Jan 2003 12:46:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:31 +0100 (CET) Received: (qmail 26012 invoked by uid 0); 9 Jan 2003 01:48:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 9 Jan 2003 01:48:51 -0000 Received: by moria.seul.org (Postfix) id 7967F33DE5; Wed, 8 Jan 2003 20:48:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D71EB33DEA; Wed, 8 Jan 2003 20:48:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id C39ED33DE0 for ; Wed, 8 Jan 2003 20:48:31 -0500 (EST) Received: from f-cpu.org (lcbv3-1-11.n.club-internet.fr [213.44.91.11]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 83C9A16DD for ; Thu, 9 Jan 2003 02:47:51 +0100 (CET) Message-ID: <3E1CD877.8020102@f-cpu.org> Date: Thu, 09 Jan 2003 03:03:35 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>>common operations. If you have other big source file, then >>>preprocess it (gcc -E) and send to me. I'll then include results >>>in my tests. >>> >>what about the STREAM benchmark or the FFTW library ? >> >> >hmm - why not, I have FFTW here from my latest accelerometer >analysis (http://luxik.cdi.cz/~devik/accel/ for interested). >Once I get time I'll test. > > yeah ! \o/ >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 03:03:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcO-0002TN-00 for ; Fri, 10 Jan 2003 12:46:32 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:32 +0100 (CET) Received: (qmail 7057 invoked by uid 0); 9 Jan 2003 01:48:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 9 Jan 2003 01:48:59 -0000 Received: by moria.seul.org (Postfix) id 99B1F33DEB; Wed, 8 Jan 2003 20:48:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7399E33DF1; Wed, 8 Jan 2003 20:48:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 21CBA33DEB for ; Wed, 8 Jan 2003 20:48:41 -0500 (EST) Received: from f-cpu.org (lcbv3-1-11.n.club-internet.fr [213.44.91.11]) by relay-1v.club-internet.fr (Postfix) with ESMTP id EA7BC1698 for ; Thu, 9 Jan 2003 02:47:58 +0100 (CET) Message-ID: <3E1CD87D.9040002@f-cpu.org> Date: Thu, 09 Jan 2003 03:03:41 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >>Just one question : is GCC bound to this "1/0" scheme ? >>F-CPU is based on "0 / not 0", so in some cases we can drop the andi :-) >>Or, if the result is not used in a computation or mask, the LSB >>condition can >>be used. >> >> >gcc can work with compares producing 0/1, 0/-1, 0/(1<<(width-1)) >or 0/garbage where some bits in garbage are 1 (currently only MSB >and/or LSB). > cool ! :-) so certain constructs should not be so heavy as i thought. > For most effecient operation the suggest 0/-1 which >is easy to understand why ... > ... because masking any bit is then possible. >F-CPU doesn't seem to be strictly 0 / not 0. All cmpxxx produces >0/-1 which is nice. Only == and != dont ... >As MR said, I'd prefer jmpl where possible - it must be faster than >jmpnz. > > ... i forgot what jmpl is .... >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 03:03:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxcP-0002TN-00 for ; Fri, 10 Jan 2003 12:46:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:33 +0100 (CET) Received: (qmail 7769 invoked by uid 0); 9 Jan 2003 01:49:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 9 Jan 2003 01:49:11 -0000 Received: by moria.seul.org (Postfix) id 33D4D33DED; Wed, 8 Jan 2003 20:48:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 69A8B33DF3; Wed, 8 Jan 2003 20:48:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4CB7C33DED for ; Wed, 8 Jan 2003 20:48:41 -0500 (EST) Received: from f-cpu.org (lcbv3-1-11.n.club-internet.fr [213.44.91.11]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 188F916A3 for ; Thu, 9 Jan 2003 02:48:37 +0100 (CET) Message-ID: <3E1CD880.2090407@f-cpu.org> Date: Thu, 09 Jan 2003 03:03:44 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>>However I think that first fcpu target are servers (especially >>>those hosted at ISP - I have several of them I feel the need). >>> >>i don't think that this is a reasonable target because ISPs want a lot >>of GHz and terabytes >>of cache, which we can't provide yet. However F-CPU can be integrated in >>a router, >>if instanciated on the tranceiver chips, or in RAID controllers for >>example... >> >> >Don't kill me my ideas please ;-) > As i learnt here, implementing somethings means that the idea has to be broken, in order to become reality ... A lot of people on this list do dream a lot, and are disapointed when things become true. > I hope to see it in my >web-servers. I want moderate performance BUT not 40W of >temperature wasted power whci I can't cool in our 1U >rack boxes. > :-) >We run with 256MB ram is it IS enough for correctly writen >apps. We also have highly loaded 1000 users postgresql server >and 512MB ram with PIII/800 is enough. >I hope 1GHz fcpu could do the job someday. >devik > > FC0 at 1GHz is science fiction for me. However, a 2-way or 4-way FC0 system could probably do the same work. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 10:38:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxca-0002TN-00 for ; Fri, 10 Jan 2003 12:46:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:44 +0100 (CET) Received: (qmail 9070 invoked by uid 0); 9 Jan 2003 10:12:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 9 Jan 2003 10:12:31 -0000 Received: by moria.seul.org (Postfix) id F043033DEE; Thu, 9 Jan 2003 05:12:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ECBC233DEA; Thu, 9 Jan 2003 05:12:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 2AD8A33DD9 for ; Thu, 9 Jan 2003 05:12:23 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WZfc-0006Yp-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:12:18 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZ8d-00009z-00 for f-cpu@seul.org; Thu, 09 Jan 2003 10:38:11 +0100 Date: Thu, 9 Jan 2003 10:38:11 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <20030108145002.15488@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > > hmm - why not, I have FFTW here from my latest accelerometer > > analysis (http://luxik.cdi.cz/~devik/accel/ for interested). > > Once I get time I'll test. > > I also have access to the CPU2000 sources (but I can't give them away). hmm what is it ? :) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 11:02:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcb-0002TN-00 for ; Fri, 10 Jan 2003 12:46:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:45 +0100 (CET) Received: (qmail 19945 invoked by uid 0); 9 Jan 2003 10:12:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 9 Jan 2003 10:12:45 -0000 Received: by moria.seul.org (Postfix) id C5A8033DE8; Thu, 9 Jan 2003 05:12:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2AEFE33DE4; Thu, 9 Jan 2003 05:12:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8544333DE8 for ; Thu, 9 Jan 2003 05:12:26 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WZfX-0006Yp-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:12:12 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZVh-0000Aa-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:02:01 +0100 Date: Thu, 9 Jan 2003 11:02:01 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCE f-cpu@seul.org:...] (fwd) In-Reply-To: <20030108150804.11302@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > "at least" ? I suppose 32bit in needs to be "naturaly" > > (32bit) aligned, ok ? > > Of course. But it's not yet clear what happens with data items > 64 bits. > They may have to be naturally aligned, or may need only 8-byte alignment. > That depends very much on the LSU which isn't ready yet. > 64bit ?? Are you speaking about wider F-CPU versions ? > > yes it is of course. But if you want compined to be able to use and > > split them you need to descrtibe their behaviour. And the description > > I used is perfectly valid. > > Except that it lacks a description of loadcons.2 and loadcons.3 :) exactly .. lazy me :) > > (label_ref:DI 107) is label of jump table. Here we need loadaddrid > > even if it is not clear. > > Heck. gcc is a piece of shit, isn't it? hmm maybe .. I feel it as magnificant piece of code. Because I wrote and maintain part of kernel in paralel with my job and family and the code is much smaller than gcc and I still have several bug reports per week (mostly void ones) - so I know what problem is to KEEP a project alive. And gcc is working and is getting (slowly) better. 3.3 has DFA scheduler which will help to schedule out post-incrementer dependency and simulate write port contention. Other new code solves our jump-registers. Code to do syntax-tree based optimisations is underway. When I faced all the things inside of gcc and all nuances of memory coherency, aliasing, sync points of C language ..... I don't think we would be able to write functional compiler for f-cpu from scratch in reasonable time - prove me wrong please. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 10:52:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcb-0002TN-01 for ; Fri, 10 Jan 2003 12:46:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:45 +0100 (CET) Received: (qmail 18701 invoked by uid 0); 9 Jan 2003 10:12:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 9 Jan 2003 10:12:52 -0000 Received: by moria.seul.org (Postfix) id A018433DF9; Thu, 9 Jan 2003 05:12:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 128A333DF5; Thu, 9 Jan 2003 05:12:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B819A33CB6 for ; Thu, 9 Jan 2003 05:12:35 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WZfn-0007kA-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:12:28 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZMe-0000AS-00 for f-cpu@seul.org; Thu, 09 Jan 2003 10:52:40 +0100 Date: Thu, 9 Jan 2003 10:52:40 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] (next) crazy idea about immediates In-Reply-To: <20030108151353.43642@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > All data needs to be aligned. Ok. We can also suggest > > aligning structures to cacheline boundary (and malloc > > would return such aligned pointers). > > That may cause a lot of internal fragmentation. hmm it is possible unless you take care of it. where you can use it without too many problems are string operation where you pre-align address at start, in function prologs where we know local stack size and can optimize its size and placement. I agree that it is not simple. > > We could support load/store with 5bit immediate value > > which would be ORed with physical address in register. > > Umh... yet another load/store instruction? :-] yes > > > This way there is no need to change LSU working, no > > other pipeline stage, no problems with exceptions. > > You'll have to check for correct alignment. I don't think so - it would be programmer's/compiler's job to use it at appropriate places. I see it as direct addressing of single cacheline. I hope you agree with me that implementation is easy. And we both know that compiler design would be more tough with this in mind - but not impossible. But well, only simulating it can prove whether it is worth of any work. In any case it is very fast indexing and can save us trubles with more pointers pointing single cacheline. Also this way you could schedule 4 loads (if we'd have 4 LSU) in paralel with single pointer .... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 10:54:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcc-0002TN-00 for ; Fri, 10 Jan 2003 12:46:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:46 +0100 (CET) Received: (qmail 19194 invoked by uid 0); 9 Jan 2003 10:13:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Jan 2003 10:13:02 -0000 Received: by moria.seul.org (Postfix) id 4E7C233DF0; Thu, 9 Jan 2003 05:13:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 797A933DFF; Thu, 9 Jan 2003 05:12:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 329C633CB6 for ; Thu, 9 Jan 2003 05:12:50 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WZfw-0008Fr-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:12:37 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZOR-0000AU-00 for f-cpu@seul.org; Thu, 09 Jan 2003 10:54:31 +0100 Date: Thu, 9 Jan 2003 10:54:31 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC and jmpz vs. jmpl In-Reply-To: <20030108150032.21061@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > for inc/dec/neg/cmp..... > > Who added next cycle ?? > > The INC unit needs 2 cycles because it became too complex. > Life's a bitch, you know... hehehe, what irony ! Incrementer unis has its name after inc/dec. But now inc/dec are superfluous because they do the same job as addi $1 with the same time - addi can be even faster for 8bit chunks. > The XOR is already there (it's needed for cmple/cmpg/min/max), and the > `reduce' tree is there as well. I could just tap its result bits and route > them to the output - but that would still be a 2-cycle operation. That > is, it won't be any cheaper than `xor.and'. yes now I know .. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 11:11:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcc-0002TN-01 for ; Fri, 10 Jan 2003 12:46:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:46 +0100 (CET) Received: (qmail 6344 invoked by uid 0); 9 Jan 2003 10:13:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 9 Jan 2003 10:13:06 -0000 Received: by moria.seul.org (Postfix) id 88DF933DF2; Thu, 9 Jan 2003 05:13:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E150A33DF5; Thu, 9 Jan 2003 05:12:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B5A9E33DFC for ; Thu, 9 Jan 2003 05:12:50 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WZg1-00004u-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:12:42 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZeT-0000Af-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:11:05 +0100 Date: Thu, 9 Jan 2003 11:11:05 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] GCC and jmpz vs. jmpl In-Reply-To: <20030108144304.44967@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > On Wed, Jan 08, 2003 at 03:01:23AM +0100, Yann Guidon wrote: > [...] > > Just one question : is GCC bound to this "1/0" scheme ? > > AFAIK, gcc expects the result of a compare instruction to be either +1 > or negative (that is, it can use the LSB or the MSB directly). This is > NOT true for an ordinary `xor'. or use bitmask of set bits (only MSB and/or LSB works just now). but I use different way - when I expand == or != I emit XOR and from that time gcc see it as XOR followed by compare to zero for remainder of compilation. It allows to do bitwise optimizations like: if (a == ~b) ... to emit nxor r1,r2,r3 jmpz r3,... instead of not r2,r2 xor r1,r2,r3 jmpz ... which would be the case if gcc was thinking that xor is compare for equality and not plain exclusive-or... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 11:30:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxce-0002TN-00 for ; Fri, 10 Jan 2003 12:46:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:48 +0100 (CET) Received: (qmail 1245 invoked by uid 0); 9 Jan 2003 10:48:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 9 Jan 2003 10:48:12 -0000 Received: by moria.seul.org (Postfix) id 69CEA33DD9; Thu, 9 Jan 2003 05:48:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B13033DEA; Thu, 9 Jan 2003 05:48:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id F290033DD9 for ; Thu, 9 Jan 2003 05:48:08 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WaEB-0000Rd-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:48:00 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WZxN-0000E9-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:30:37 +0100 Date: Thu, 9 Jan 2003 11:30:37 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <3E1CD880.2090407@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > FC0 at 1GHz is science fiction for me. > However, a 2-way or 4-way FC0 system could probably do the same work. :) sci-fi from technical or financial point of view ? I take it from financial point - to get access to appropriate technology. But is there anything what would prevent FC0 to go multi-GHz ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 9 11:47:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxce-0002TN-01 for ; Fri, 10 Jan 2003 12:46:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:48 +0100 (CET) Received: (qmail 30189 invoked by uid 0); 9 Jan 2003 10:48:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 9 Jan 2003 10:48:23 -0000 Received: by moria.seul.org (Postfix) id 5AAEB33DF5; Thu, 9 Jan 2003 05:48:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ADCCE33DF4; Thu, 9 Jan 2003 05:48:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 72FB633DF1 for ; Thu, 9 Jan 2003 05:48:19 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WaEM-0001Kg-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:48:11 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WaDH-0000ET-00 for f-cpu@seul.org; Thu, 09 Jan 2003 11:47:03 +0100 Date: Thu, 9 Jan 2003 11:47:02 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] loadconsx and stream hints In-Reply-To: <3E1CC983.8090108@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >of latest loadconsx (and loadcons.n) so I can add > >them to gcc ? > > > > i prefer to stick with the old/original "loadcons[x]" which writes > a 16-bit constant to a given part of a register. so that loadconsx.4 == loadcons.4 and loadconsx.0 sign extends the value to 64 bits ? And loadconsx.1 leaves 16 LSB, sets bit16...31 and copies 31 do 31...63 ? Btw will be partial writes solved whe you do loadconsx.0 $0xffff loadcons.1 $0 for example ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 03:07:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxch-0002TN-00 for ; Fri, 10 Jan 2003 12:46:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:51 +0100 (CET) Received: (qmail 14010 invoked by uid 0); 9 Jan 2003 12:32:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 9 Jan 2003 12:32:05 -0000 Received: by moria.seul.org (Postfix) id B37BC33DE4; Thu, 9 Jan 2003 07:32:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1512833DF3; Thu, 9 Jan 2003 07:32:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id B329233DE4 for ; Thu, 9 Jan 2003 07:32:01 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02347; Thu, 9 Jan 2003 03:07:19 +0100 Message-ID: <20030109030719.46623@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 03:07:19 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030108143629.49856@thrai.stud.uni-hannover.de>; from Michael Riepe on Wed, Jan 08, 2003 at 02:36:29PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 02:36:29PM +0100, I wrote: [...] > If you insist, I will investigate whether `sdup r3, r2, r1' can be added. [...] Fuck, that was TOO easy - took me 30 seconds to add it :) Here's the change in the encoding: > vsel: > 31-24 OP_VSEL (replaces OP_SDUP) > 23-22 size > 21 s- prefix > 20-18 unused Change that line to 20 -h suffix (duplicates second operand) 19-18 unused > 17-12 r3 > 11- 6 r2 > 5- 0 r1 There now are the following identities: sdup.sz r2, r1 <=> svsel.sz r0, r2, r1 <=> vperm.sz r0, r2, r1 sdupi.sz $u, r2, r1 <=> svseli.sz $u, r2, r1 <=> vpermi.sz $u, r2, r1 sdup.sz r3, r2, r1 <=> svselh.sz r3, r2, r1 <=> vpermh.sz r3, r2, r1 Note that `-h' has no effect without the `s-' prefix. This is consistent with the use of `-h' in the bitwise shift/rotate instructions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 02:26:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxci-0002TN-00 for ; Fri, 10 Jan 2003 12:46:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:52 +0100 (CET) Received: (qmail 10449 invoked by uid 0); 9 Jan 2003 12:32:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 9 Jan 2003 12:32:11 -0000 Received: by moria.seul.org (Postfix) id 05AA933DF3; Thu, 9 Jan 2003 07:32:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B50D733DF4; Thu, 9 Jan 2003 07:32:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id A7DE433DF1 for ; Thu, 9 Jan 2003 07:32:03 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01888; Thu, 9 Jan 2003 02:26:12 +0100 Message-ID: <20030109022612.24989@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 02:26:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] loadconsx and stream hints References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 08, 2003 at 11:44:49PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 08, 2003 at 11:44:49PM +0100, devik wrote: > Please can someone explain me syntax and semantic > of latest loadconsx (and loadcons.n) so I can add > them to gcc ? Your .md pattern for loadcons. is already correct. Loadconsx. is similar: It puts the 16-bit constant in chunk , but it also stuffs all higher chunks ( up to the maximum) with copies of the sign bit of the immediate operand. Syntax & encoding: loadcons.n $uimm16, r1 31-24 OP_LOADCONS 23-22 chunk index (0...3) 21- 6 16-bit unsigned immediate 5- 0 r1 loadconsx.n $simm16, r1 31-24 OP_LOADCONSX 23-22 chunk index (0...3) 21- 6 16-bit signed immediate 5- 0 r1 The assembler aliases are: loadcons $uimm64, r1 // written without a chunk index loadconsx $simm64, r1 // written without a chunk index I'm still experimenting with the semantics. Several optimizations are possible: `loadcons $0, r1' could result in `move r0, r1', powers of two could be created with `bseti', and so on. If you specify short numbers (like `loadconsx $-1, r1'), a single instruction will be emitted. On the other hand, if the immediate operand is not known at assembly time, the assembler will generate the full 4-instruction load sequence plus relocation entries, and the linker will have to fill in the value: .text loadcons $data-.-4, r1 // value of `data' is unknown loadaddrd r1, r1 // it's unwise to use `loadaddrid' here load r1, r1 .data data: .long some_value I'm not sure what the assembler should do if you use `loadcons.n' with a symbolic constant or label. Currently, it complains that it hasn't been given an `absolute' or `integer' value. Additionally, it will warn you if the operand is out of range (0x0000...0xffff for loadcons, -0x8000...0x7fff for loadconsx). But it's also possible to permit something like loadcons.2 $label, r1 or, more correctly, loadcons.2 $label>>32, r1 (the assembler will generate relocation entries if the value of `label' is unknown). BTW: I also consider a `small' memory model where all addresses are limited to 32 bits. It will save a lot of loadcons instructions, and may be particularly interesting for small machines, embedded systems and so on. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:16:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcn-0002TN-00 for ; Fri, 10 Jan 2003 12:46:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:57 +0100 (CET) Received: (qmail 21317 invoked by uid 0); 9 Jan 2003 18:38:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 9 Jan 2003 18:38:35 -0000 Received: by moria.seul.org (Postfix) id 86C0833DF8; Thu, 9 Jan 2003 13:38:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E1B7733DFC; Thu, 9 Jan 2003 13:38:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id E612C33DF8 for ; Thu, 9 Jan 2003 13:38:29 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00658; Thu, 9 Jan 2003 14:16:10 +0100 Message-ID: <20030109141610.23540@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:16:10 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: <20030108145002.15488@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Jan 09, 2003 at 10:38:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 10:38:11AM +0100, devik wrote: > > I also have access to the CPU2000 sources (but I can't give them away). > > hmm what is it ? :) A benchmark for cpu/chipset/memory subsystems. See www.spec.org. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:08:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxco-0002TN-00 for ; Fri, 10 Jan 2003 12:46:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:58 +0100 (CET) Received: (qmail 14829 invoked by uid 0); 9 Jan 2003 18:38:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Jan 2003 18:38:40 -0000 Received: by moria.seul.org (Postfix) id DEBF933E00; Thu, 9 Jan 2003 13:38:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42E7B33DFE; Thu, 9 Jan 2003 13:38:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id A8A7E33DFB for ; Thu, 9 Jan 2003 13:38:31 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00631; Thu, 9 Jan 2003 14:08:48 +0100 Message-ID: <20030109140848.10078@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:08:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] loadconsx and stream hints References: <3E1CC983.8090108@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1CC983.8090108@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 01:59:47AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 01:59:47AM +0100, Yann Guidon wrote: > hi, > > devik wrote: > > >Please can someone explain me syntax and semantic > >of latest loadconsx (and loadcons.n) so I can add > >them to gcc ? > > > > i prefer to stick with the old/original "loadcons[x]" which writes > a 16-bit constant to a given part of a register. Agreed. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:13:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcp-0002TN-00 for ; Fri, 10 Jan 2003 12:46:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:59 +0100 (CET) Received: (qmail 2139 invoked by uid 0); 9 Jan 2003 18:38:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 9 Jan 2003 18:38:45 -0000 Received: by moria.seul.org (Postfix) id 16E0A33E02; Thu, 9 Jan 2003 13:38:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2BC0F33DFA; Thu, 9 Jan 2003 13:38:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 12A8833DFC for ; Thu, 9 Jan 2003 13:38:34 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00647; Thu, 9 Jan 2003 14:13:20 +0100 Message-ID: <20030109141320.18381@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:13:20 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: <3E1B866F.3000403@f-cpu.org> <20030108145002.15488@thrai.stud.uni-hannover.de> <3E1CD871.7030806@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1CD871.7030806@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 03:03:29AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 03:03:29AM +0100, Yann Guidon wrote: > >I also have access to the CPU2000 sources (but I can't give them away). > > > If the benchmark is not publicly available, then it's not worth it :-) Oh, it is available - but you'll have to pay for it. And it's used by all CPU vendors (see www.spec.org for a list of benchmark results). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:19:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcp-0002TN-01 for ; Fri, 10 Jan 2003 12:46:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:46:59 +0100 (CET) Received: (qmail 13326 invoked by uid 0); 9 Jan 2003 18:38:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 9 Jan 2003 18:38:51 -0000 Received: by moria.seul.org (Postfix) id 99CA433DFA; Thu, 9 Jan 2003 13:38:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E37C433E03; Thu, 9 Jan 2003 13:38:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 50D8833DFB for ; Thu, 9 Jan 2003 13:38:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00670; Thu, 9 Jan 2003 14:19:50 +0100 Message-ID: <20030109141950.62044@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:19:50 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030108150032.21061@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Jan 09, 2003 at 10:54:31AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 10:54:31AM +0100, devik wrote: > > > for inc/dec/neg/cmp..... > > > Who added next cycle ?? > > > > The INC unit needs 2 cycles because it became too complex. > > Life's a bitch, you know... > > hehehe, what irony ! Incrementer unis has its name after > inc/dec. But now inc/dec are superfluous because they do > the same job as addi $1 with the same time - addi can be > even faster for 8bit chunks. Not my fault. Whoever designed the original INC unit underestimated the cost of a SIMD-enabled `and' reduce tree. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:22:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcq-0002TN-00 for ; Fri, 10 Jan 2003 12:47:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:00 +0100 (CET) Received: (qmail 6547 invoked by uid 0); 9 Jan 2003 18:39:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 9 Jan 2003 18:39:00 -0000 Received: by moria.seul.org (Postfix) id 4AF1033DFC; Thu, 9 Jan 2003 13:38:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9BCBE33DFF; Thu, 9 Jan 2003 13:38:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 400E433DFD for ; Thu, 9 Jan 2003 13:38:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00682; Thu, 9 Jan 2003 14:22:38 +0100 Message-ID: <20030109142238.56697@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:22:38 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] loadconsx and stream hints References: <3E1CC983.8090108@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Jan 09, 2003 at 11:47:02AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 11:47:02AM +0100, devik wrote: > > >of latest loadconsx (and loadcons.n) so I can add > > >them to gcc ? > > > > > > > i prefer to stick with the old/original "loadcons[x]" which writes > > a 16-bit constant to a given part of a register. > > so that loadconsx.4 == loadcons.4 loadconsx.3 == loadcons.3 (there is no chunk 4), but only on a 64-bit machine. Yes that's kinda tricky. > and loadconsx.0 sign extends the value to 64 bits ? Or more. > And loadconsx.1 leaves 16 LSB, sets bit16...31 and > copies 31 do 31...63 ? Yep. > Btw will be partial writes solved whe you do > loadconsx.0 $0xffff > loadcons.1 $0 > > for example ? They should, yes. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:08:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcq-0002TN-01 for ; Fri, 10 Jan 2003 12:47:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:00 +0100 (CET) Received: (qmail 14701 invoked by uid 0); 9 Jan 2003 18:39:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 9 Jan 2003 18:39:12 -0000 Received: by moria.seul.org (Postfix) id EBC2633E06; Thu, 9 Jan 2003 13:38:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EAD4A33E03; Thu, 9 Jan 2003 13:38:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 0AE3833DFB for ; Thu, 9 Jan 2003 13:38:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00626; Thu, 9 Jan 2003 14:08:08 +0100 Message-ID: <20030109140808.03508@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:08:08 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> <3E1CC95F.9070406@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1CC95F.9070406@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 01:59:11AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 01:59:11AM +0100, Yann Guidon wrote: [...] > >I do not remember an `sdup' instruction that uses three operands, nor > >did I implement one. That would have been another logical extension; > >but I guess that vperm is more useful. BTW: if you're satisfied with > >an immediate operand, `svseli $n, r2, r1' will do what you want > >(duplicate chunk of r2). > > > > > it's not doing sdup completely. The 3rd register operand is useful to > avoid a shift > in front of a "bare" sdup : > sdup r1, r2, r3 > replaces > shiftr r1*8, r2, r2 > sdup r2, r3 Implemented, with both register and immediate operand. `vsel' is now a superset of `sdup'. Satisfied? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 14:01:51 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcr-0002TN-00 for ; Fri, 10 Jan 2003 12:47:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:01 +0100 (CET) Received: (qmail 19277 invoked by uid 0); 9 Jan 2003 18:39:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 9 Jan 2003 18:39:20 -0000 Received: by moria.seul.org (Postfix) id D680433E07; Thu, 9 Jan 2003 13:38:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BADD33DFD; Thu, 9 Jan 2003 13:38:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id 974E633DFE for ; Thu, 9 Jan 2003 13:38:47 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00607; Thu, 9 Jan 2003 14:01:52 +0100 Message-ID: <20030109140151.50113@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 14:01:51 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> <3E1CC977.7070803@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1CC977.7070803@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 01:59:35AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 01:59:35AM +0100, Yann Guidon wrote: [...] > and_reduce (or "combine" as written in ROP2) is not possible > for very wide data. > > Furthermore, the xorn.and trick is useful for "detecting" that a byte > corresponds, but if you need to find the index of the character, > the "obvious" answer is to loop over the register. > if you have a result of 0x00FF000000000000, it's not a good solution. > So the idea is to "transpose" the bits in the word, that would become > 0x4040404040404040 and the last byte can then ben binary encoded > in INC (if it's implemented). Wouldn't it be sufficient to `collapse' each chunk into a single bit? That is, if the chunk's value is not zero, the corresponding bit will be set, otherwise it will be zero: r2 = 0xab00cd00ef0000 collapse.b r2, r1 r1 <= 0x54 collapse.d r2, r1 r1 <= 0x0e and so on. A complementary `uncollapse' instruction would be nice, too (it would allow you to generate chunk masks more easily): r2 = 0x5a uncollapse.b r2, r1 r1 <= 0x00ff00ffff00ff00 uncollapse.d r2, r1 r1 <= 0x0000ffff0000ffffffff0000ffff0000 // yes, that's 128 bits ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 9 13:48:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcr-0002TN-01 for ; Fri, 10 Jan 2003 12:47:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:01 +0100 (CET) Received: (qmail 4743 invoked by uid 0); 9 Jan 2003 18:39:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 9 Jan 2003 18:39:30 -0000 Received: by moria.seul.org (Postfix) id 7A23E33DFD; Thu, 9 Jan 2003 13:39:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4662133E05; Thu, 9 Jan 2003 13:38:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a218.home.uni-hannover.de [130.75.232.218]) by moria.seul.org (Postfix) with ESMTP id B28D233DFF for ; Thu, 9 Jan 2003 13:38:50 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00573; Thu, 9 Jan 2003 13:48:31 +0100 Message-ID: <20030109134831.09973@thrai.stud.uni-hannover.de> Date: Thu, 9 Jan 2003 13:48:31 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Trying to clean up the ROP2 mess References: <20030108181909.24588@thrai.stud.uni-hannover.de> <3E1CC970.1080801@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1CC970.1080801@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 01:59:28AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 01:59:28AM +0100, Yann Guidon wrote: > hello, > > Michael Riepe wrote: > > >Subject says it all. We need to make this more regular/orthogonal, and > >more consistent with the way other instructions work. In particular, > >we should provide operation variants that > > > > - work for 8/16/32/64 bit chunks > > - mask off the high bits / work on full registers > > - use direct/and/or mode > > > > > > did you read one of my mails of yesterday about this subject ? Yes. > did you look at FORMAT.txt in the source snapshot ? Yes. > why is MUX not included ? (it is performed by the ROP2 unit > and uses a subset of the functions) Oh, I forgot that. But there will also be two variants: mux.size r3, r2, r1 // truncates / zero-extends smux.size r3, r2, r1 // operates on full word (size ignored) [...] > well, we don't converge on these last details but the encoding i > proposed is able to do that > (except that there are 2 size fields, one for the writeback size and one > for the combine chunk size). That's one of the problems. Since you re-used the SIMD flag for the additional size flags, there is no longer a way to specify a register-wide operation (remember that registers may be much wider than 64 bits). Besides that, the second size flag makes the encoding inconsistent with the majority of instructions (one goal is to keep the decoder simple!). For the same reason, I dropped the secondary size flags from the original `widen' instruction. > >I will implement this encoding scheme in the next release of my > >assembler/disassembler/emulator trio. > > > you're going to have too much fun : you're insane :-) Did you try to install my fctools package? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Thilo.Reichelt@t-online.de Thu Jan 9 19:52:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcs-0002TN-00 for ; Fri, 10 Jan 2003 12:47:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:02 +0100 (CET) Received: (qmail 20240 invoked by uid 0); 9 Jan 2003 18:52:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 9 Jan 2003 18:52:45 -0000 Received: by moria.seul.org (Postfix) id 7BC2E33DFB; Thu, 9 Jan 2003 13:52:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E50CE33DFF; Thu, 9 Jan 2003 13:52:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by moria.seul.org (Postfix) with ESMTP id 058BC33DFB for ; Thu, 9 Jan 2003 13:52:43 -0500 (EST) Received: from fwd09.sul.t-online.de by mailout11.sul.t-online.com with smtp id 18WhnD-0004kp-0D; Thu, 09 Jan 2003 19:52:39 +0100 Received: from client1.t-online.de (0893089296-0001@[62.153.32.40]) by fwd09.sul.t-online.com with esmtp id 18Whn6-0SflBYC; Thu, 9 Jan 2003 19:52:32 +0100 Message-Id: <5.2.0.9.1.20030109191001.009eac70@ pop.t-online.de> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 19:52:09 +0100 To: f-cpu@seul.org From: Thilo.Reichelt@t-online.de (Thilo Reichelt) Subject: Re: [f-cpu] New EU_SHL Instruction In-Reply-To: <3E1CC95F.9070406@f-cpu.org> References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Sender: 0893089296-0001@t-dialin.net Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N At 01:59 09.01.03 +0100, you wrote: >hi ! > >i don't remember the discussion about this, but there was some kind of >inherent >limitation related to the index size ... >If we set that the size of the index equals the size of the chunk, that >should be ok. I faintly remember this discussion. Probably from 2000 or earlier. When the f-cpu list was still at yahoo! This discussion was in may 2000 . And, as Michael Riepe has already said, if the smallest chunk size is 8 bits, this instruction is only useful up to 2048 bit wide registers Hmm, reading the old posts is a little bit confusing... Ok, the discussion jumped around between what Michael Riepe called permute now and another instruction, which would shuffle around chunks from TWO different source registers and stuff them in a destination register (a 3r1w instruction) Thilo Reichelt ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 21:01:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxct-0002TN-00 for ; Fri, 10 Jan 2003 12:47:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:03 +0100 (CET) Received: (qmail 4823 invoked by uid 0); 9 Jan 2003 19:00:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 9 Jan 2003 19:00:38 -0000 Received: by moria.seul.org (Postfix) id 09AA233CBE; Thu, 9 Jan 2003 14:00:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 716FB33DFE; Thu, 9 Jan 2003 14:00:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4851033CBE for ; Thu, 9 Jan 2003 14:00:35 -0500 (EST) Received: from Biathlon (lcbv2-1-30.n.club-internet.fr [213.44.12.30]) by relay-1v.club-internet.fr (Postfix) with SMTP id 9229B1695 for ; Thu, 9 Jan 2003 19:59:54 +0100 (CET) Date: Fri, 10 Jan 2003 20:01:18 +0000 From: nico To: f-cpu@seul.org Subject: stream hint (was:Re: [f-cpu] loadconsx and stream hints) Message-Id: <20030110200118.271de04f.nicolas.boulay@ifrance.com> In-Reply-To: <3E1CC983.8090108@f-cpu.org> References: <3E1CC983.8090108@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 09 Jan 2003 01:59:47 +0100 Yann Guidon wrote: > hi, > > devik wrote: <...> > >Also if someone can write a few words what stream > >bits can be good for - I can't find definition. Will > >there be separate caches for each stream for example ? > > > > > stream hints are used to differentiate unrelated data streams, > that is, flows (in and out) from memory from separate, independent > arrays. > Like Cray. > By default there is no hint (hint #0) but this can be useful in future > architectures where multiple Load/Store Units are implemented > or when there is a direct SDRAM interface (the stream hint bit > can then serve as a bank number, in order to optimise prefetch > time and bandwidth). > :) linking SDRAM bank to the stream bit is VERY bad idea ! SDRAM have 4 bank in each chit. RDRAM 32. How could you simply hanle that ? Bank is a memory trick to enable pipelining access. So the bank number is a part of the adress bit, we have a strong interrest to interleave access to the bank. But the lower limit is the burst limit of memory interface. So it will depend on bus size/ burst lenth/memory technology/... > It is not yet used and can remain zero, but i guess that the SDRAM > bank trick > will be used first because it simplifies the SDRAM interface logic. > A "hint number" (or bank number, or transaction number) > can be allocated to the stack, the others are used for continuous > (streaming) > access to main memory (for example, one is needed for memset and two > are needed for strcmp). > Mainly, a stream in the supercomputer world are a hint to the memory sub system, to say that the memory didn't need to be coherent. Other wise each memory acces *must* be in order to avoid to lose the memory consitency. For example, you must check the content of the adresse of a unfinish write (in case of the use of write buffer to enable burst transfert) before asking for a read. AMD Opteron technology will used 2 access port L1 caches, to increase speed. Stream could be a very great hint to adresse 7 or 8 L1 nano-caches ! A stream could be an array or the stack, so mainly data are more "aligned", so burst are more effective and prefetch is also easier. By using 7-8 caches, we simulate 7-8 port memory subsystem ! The main problem is to keep consistency between function call, for example. We don't know which stream are used for a specific pointer given to a function. One ideas was to use a stream #0 (S0) that access the 7 nano-caches (of the other stream) in parrallel. So if there is more than a hit, it must fetch the data from the memory subsystem because it didn't know which caches is the must up-to-date. So when we "leave" a stream, it must be flush to the next level of caches or the last write must be in write thought cache policy to keep the coherency for futur access. Maybe the S0 trick is not usefull anymore, if this could be taken into account by the compiler. This use of stream could be very usefull to produice superscalar core that could access memory in parrallel. nicO > >thx, devik > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 21:30:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcu-0002TN-00 for ; Fri, 10 Jan 2003 12:47:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:04 +0100 (CET) Received: (qmail 24776 invoked by uid 0); 9 Jan 2003 19:30:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 9 Jan 2003 19:30:06 -0000 Received: by moria.seul.org (Postfix) id 4EC0033CCD; Thu, 9 Jan 2003 14:30:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C8DC333E01; Thu, 9 Jan 2003 14:30:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 5ABBF33CCD for ; Thu, 9 Jan 2003 14:30:04 -0500 (EST) Received: from Biathlon (lcbv2-1-30.n.club-internet.fr [213.44.12.30]) by relay-5v.club-internet.fr (Postfix) with SMTP id D818B174C for ; Thu, 9 Jan 2003 20:30:18 +0100 (CET) Date: Fri, 10 Jan 2003 20:30:47 +0000 From: nico To: f-cpu@seul.org Subject: 6/8 bits imm instructions ( was Re: Rep:Re: [f-cpu] statistics of direct indexing usage) Message-Id: <20030110203047.1c8a3e2c.nicolas.boulay@ifrance.com> In-Reply-To: References: <200301081408.0ce8@th00.opsion.fr> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 8 Jan 2003 15:27:48 +0100 (CET) devik wrote: > > Is it what you wanted to know ? > > > > >>> > > Not really. :) It's an interresting number however. The idea was > > better to add the 6 bits immediat adressing mode rather than > > _replace_ the 8 bits mode. > > > > By using 8 bits immediat, you can't use some flags combinaison. So > > what is the impact in the generated code (how many instruction would > > like to use this particular combinaison?). > > uh uh, can you give me please some examples of such instruction ? It's the problème of bit 12-13 (manual 0.2.5). It's use in the scan instruction to bit-reverse the input or negate it. It used as negate sign flag of the MAC instruction. All of this flag can't be used in the 8 bits immediat of such fonction. So is a pain or not ? > or you wanted to have BOTH 6bit and 8bit immediates and see which > will be used ? I'm a bit lost - can't still understand .. :) We must take into account that if not respecting fields boundary in the instruction word will complicate the decoder, and make the ISA not orthogonal. But in other hand, 8 bit is fewer than 6 :) Using both could be too much. Maybe loadconst could do the job. nicO > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger > http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 21:37:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcv-0002TN-00 for ; Fri, 10 Jan 2003 12:47:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:05 +0100 (CET) Received: (qmail 22912 invoked by uid 0); 9 Jan 2003 19:36:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 9 Jan 2003 19:36:45 -0000 Received: by moria.seul.org (Postfix) id C8E3C33DF6; Thu, 9 Jan 2003 14:36:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C166433CC8; Thu, 9 Jan 2003 14:36:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id A8D0133DF6 for ; Thu, 9 Jan 2003 14:36:29 -0500 (EST) Received: from Biathlon (lcbv2-1-30.n.club-internet.fr [213.44.12.30]) by relay-3v.club-internet.fr (Postfix) with SMTP id 47CDE1778 for ; Thu, 9 Jan 2003 20:35:45 +0100 (CET) Date: Fri, 10 Jan 2003 20:37:07 +0000 From: nico To: f-cpu@seul.org Subject: [f-cpu] Are 8 bits SIMD mode usefull ? Message-Id: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Just a stupid question : is 8 bits integer mode usefull ? "Char" C type are going to be 16 bits (unicode) or even 32. 3D are going in floating point even in the GPU. Gimp use 16 bit per channel (in certain mode, even more ?). 8 bits are really tricky to use to avoid overflow/underflow during calculation, that's why people try to use bigger number. Is that clever to enable such mode in a "futur" cpu which will be a reality in 2 years ? my 2 cents. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu Jan 9 20:52:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcv-0002TN-01 for ; Fri, 10 Jan 2003 12:47:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:05 +0100 (CET) Received: (qmail 30294 invoked by uid 0); 9 Jan 2003 19:54:35 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 9 Jan 2003 19:54:35 -0000 Received: by moria.seul.org (Postfix) id 72E2333E08; Thu, 9 Jan 2003 14:54:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 60FAE33E05; Thu, 9 Jan 2003 14:53:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 6D93F33E03 for ; Thu, 9 Jan 2003 14:53:41 -0500 (EST) Received: from courbevoie-101-1-194.net1.nerim.net (courbevoie-101-1-194.net1.nerim.net [213.41.180.194]) by kraid.nerim.net (Postfix) with ESMTP id 0C9A940E2D for ; Thu, 9 Jan 2003 20:41:29 +0100 (CET) Subject: Re: [f-cpu] Are 8 bits SIMD mode usefull ? From: Antoine To: f-cpu@seul.org In-Reply-To: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> References: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1042141954.3545.30.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Jan 2003 20:52:34 +0100 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, Le ven 10/01/2003 à 21:37, nico a écrit : > Just a stupid question : is 8 bits integer mode usefull ? I think so ;) > "Char" C type are going to be 16 bits (unicode) The most widely used encoding of unicode, UTF-8, is based on regular bytes (it's a variable length encoding backwards compatible with Ascii). That means both legacy character strings and unicode strings will use byte operations. Protocol networks, compression formats will also remain byte-based. And so on ;) > Gimp use 16 bit per channel I think that's false, that's even why Film Gimp exists (movie guys need more than 8 bits per channel and Gimp can't satisfy their needs). However even if Gimp can do 16 bits per channel, most images will still only require 8 bits per channel, leading to more compact representations and faster calculations (and less memory transfers ;-)). Also if you think SIMD in stuff like GIMP, operations with 8-bit per channel will be twice faster than with 16-bit channel (because your registers have a fixed size and you can stuff twice more bytes than 16-bit integers into a register). Hey, if you wanna write an x86 emulator for F-CPU, you'll also need bytes :-))) Regards Antoine. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 21:59:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcw-0002TN-00 for ; Fri, 10 Jan 2003 12:47:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:06 +0100 (CET) Received: (qmail 22323 invoked by uid 0); 9 Jan 2003 19:59:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 9 Jan 2003 19:59:03 -0000 Received: by moria.seul.org (Postfix) id B73AF33DF4; Thu, 9 Jan 2003 14:59:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D972733E03; Thu, 9 Jan 2003 14:58:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id C19E933DF4 for ; Thu, 9 Jan 2003 14:58:53 -0500 (EST) Received: from Biathlon (lcbv2-1-30.n.club-internet.fr [213.44.12.30]) by relay-2v.club-internet.fr (Postfix) with SMTP id ED207171D for ; Thu, 9 Jan 2003 20:58:51 +0100 (CET) Date: Fri, 10 Jan 2003 20:59:36 +0000 From: nico To: f-cpu@seul.org Subject: scatter/gather op ( was:Re: [f-cpu] New EU_SHL Instruction) Message-Id: <20030110205936.16c2fba1.nicolas.boulay@ifrance.com> In-Reply-To: <20030109140151.50113@thrai.stud.uni-hannover.de> References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> <3E1CC977.7070803@f-cpu.org> <20030109140151.50113@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 9 Jan 2003 14:01:51 +0100 Michael Riepe wrote: > On Thu, Jan 09, 2003 at 01:59:35AM +0100, Yann Guidon wrote: > [...] > > and_reduce (or "combine" as written in ROP2) is not possible > > for very wide data. > > > > Furthermore, the xorn.and trick is useful for "detecting" that a > > byte corresponds, but if you need to find the index of the > > character, the "obvious" answer is to loop over the register. > > if you have a result of 0x00FF000000000000, it's not a good > > solution. So the idea is to "transpose" the bits in the word, that > > would become 0x4040404040404040 and the last byte can then ben > > binary encoded in INC (if it's implemented). > > Wouldn't it be sufficient to `collapse' each chunk into a single bit? that's a gather intra-chunk operation. (Such gather op are a lack in all the f-cpu ISA because inter-chunk operation are maid in 64 bits cpu instead of thinking about a 256 bits version.) A add gather could be usefull too ! gather.add.64 V1 V2 R3 R3 = V1[0]+V1[1]+V1[2]+V1[3] +V2[0]+V2[1]+V2[2]+V2[3] (big tree adder ?) This avoid stupid end of loop in many mathematical operation (imagine unroll MAC op for digital filter) : int X[100], Coeff[100], out; init(Coeff); out=0; for(int i ; i<100; i++) { out+=X[i]*Coeff[i]; } Such loop are a dream for SIMD (8*32=256 bits register) : V8i X[100/8], Coeff[100/8], Vout1,Vout2; int out; init(Coeff); out=0; for(int i ; i< (floor(100/8)=96); i+=2) { Vout1+=X[i]*Coeff[i]; Vout2+=X[i+1]*Coeff[i+1]; /*for masking the internal depencies of the mac op !*/ } for(int i; i < (rest(100,8)=4);i++) { out+=(int)X[i]*(int)Coeff[i] } out+=scatter_add(Vout1,Vout2); return out; This kind of scatter avoid you to do strange manipulations with the vector in registers. This is Vector-Vector->Scalar or Vector-Scalar->Scalar operations. The inverse could be usefull too (scatter) : Scalar-Scalar-> Vector. Add is the most evident op for such thing but maybe other op could be usefull too ? For bit-wise operation, like and/or_reduice, this is intra-chunk op. Because bit-width op are only SIMD with 1 bit integer :) nicO > That is, if the chunk's value is not zero, the corresponding bit will > be set, otherwise it will be zero: > > r2 = 0xab00cd00ef0000 > collapse.b r2, r1 > r1 <= 0x54 > collapse.d r2, r1 > r1 <= 0x0e > > and so on. A complementary `uncollapse' instruction would be nice, > too (it would allow you to generate chunk masks more easily): > > r2 = 0x5a > uncollapse.b r2, r1 > r1 <= 0x00ff00ffff00ff00 > uncollapse.d r2, r1 > r1 <= 0x0000ffff0000ffffffff0000ffff0000 // yes, that's 128 bits ;) > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 22:04:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcx-0002TN-00 for ; Fri, 10 Jan 2003 12:47:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:07 +0100 (CET) Received: (qmail 7696 invoked by uid 0); 9 Jan 2003 20:50:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 9 Jan 2003 20:50:01 -0000 Received: by moria.seul.org (Postfix) id C672733E03; Thu, 9 Jan 2003 15:49:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C5EE133E09; Thu, 9 Jan 2003 15:49:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9863C33E01 for ; Thu, 9 Jan 2003 15:49:50 -0500 (EST) Received: from f-cpu.org (lcbv4-2-228.n.club-internet.fr [213.44.93.228]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 25F9D1694 for ; Thu, 9 Jan 2003 21:49:11 +0100 (CET) Message-ID: <3E1DE3F8.70603@f-cpu.org> Date: Thu, 09 Jan 2003 22:04:56 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> <5.2.0.9.1.20030109191001.009eac70@ pop.t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Thilo Reichelt wrote: > At 01:59 09.01.03 +0100, you wrote: > >> hi ! >> >> i don't remember the discussion about this, but there was some kind >> of inherent >> limitation related to the index size ... >> If we set that the size of the index equals the size of the chunk, >> that should be ok. > > > I faintly remember this discussion. Probably from 2000 or earlier. > When the f-cpu list was still at yahoo! > > > This discussion was in may 2000 . > And, as Michael Riepe has already said, if the smallest chunk size is > 8 bits, this instruction is only useful up to 2048 bit wide registers > > Hmm, reading the old posts is a little bit confusing... > Ok, the discussion jumped around between what Michael Riepe called > permute now and another instruction, which would shuffle around chunks > from TWO different source registers and stuff them in a destination > register (a 3r1w instruction) Thanks for this search :-) i don't remember about the 3R1W instruction. > Thilo Reichelt YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 22:04:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxcy-0002TN-00 for ; Fri, 10 Jan 2003 12:47:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:08 +0100 (CET) Received: (qmail 22285 invoked by uid 0); 9 Jan 2003 20:50:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Jan 2003 20:50:11 -0000 Received: by moria.seul.org (Postfix) id 277AA33E04; Thu, 9 Jan 2003 15:49:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC00E33E01; Thu, 9 Jan 2003 15:49:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 45AC833E03 for ; Thu, 9 Jan 2003 15:49:51 -0500 (EST) Received: from f-cpu.org (lcbv4-2-228.n.club-internet.fr [213.44.93.228]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 6F126177A for ; Thu, 9 Jan 2003 21:49:47 +0100 (CET) Message-ID: <3E1DE3F6.1010809@f-cpu.org> Date: Thu, 09 Jan 2003 22:04:54 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] unsubscribes and list cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, these last days, any mail on this list generated 5 error messages. I have unsubscribed the following people (only login is shown) : gd_free, jtdesouza, artwalker, sbriole however i have been unable to unsubscribe jhanus because he is subscribed under another name and i can't find which. Just to let you know, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 11 00:24:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd1-0002TN-01 for ; Fri, 10 Jan 2003 12:47:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:11 +0100 (CET) Received: (qmail 31872 invoked by uid 0); 9 Jan 2003 22:25:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 9 Jan 2003 22:25:46 -0000 Received: by moria.seul.org (Postfix) id E6B8C33CCA; Thu, 9 Jan 2003 17:25:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BC09A33E0A; Thu, 9 Jan 2003 17:25:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 5343D33CCA for ; Thu, 9 Jan 2003 17:25:38 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id D0B1940E2C for ; Thu, 9 Jan 2003 23:13:20 +0100 (CET) Date: Fri, 10 Jan 2003 23:24:21 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Are 8 bits SIMD mode usefull ? Message-Id: <20030110232421.12f8c007.nicolas.boulay@ifrance.com> In-Reply-To: <1042141954.3545.30.camel@fsol> References: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> <1042141954.3545.30.camel@fsol> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On 09 Jan 2003 20:52:34 +0100 Antoine wrote: > > Hi, > > Le ven 10/01/2003 à 21:37, nico a écrit : > > Just a stupid question : is 8 bits integer mode usefull ? > > I think so ;) > > > "Char" C type are going to be 16 bits (unicode) > > The most widely used encoding of unicode, UTF-8, is based on regular > bytes (it's a variable length encoding backwards compatible with > Ascii). That means both legacy character strings and unicode strings > will use byte operations. Protocol networks, compression formats will > also remain byte-based. And so on ;) > > > Gimp use 16 bit per channel > > I think that's false, that's even why Film Gimp exists (movie guys > need more than 8 bits per channel and Gimp can't satisfy their needs). > However even if Gimp can do 16 bits per channel, most images will > still only require 8 bits per channel, leading to more compact > representations and faster calculations (and less memory transfers > ;-)). > > Also if you think SIMD in stuff like GIMP, operations with 8-bit > per channel will be twice faster than with 16-bit channel (because > your registers have a fixed size and you can stuff twice more bytes > than 16-bit integers into a register). > Half the bandwith consumption but many more operations to avoid overflow/underflow problems ! I beleive that GPU use float to avoid such mess ! > Hey, if you wanna write an x86 emulator for F-CPU, you'll also need > bytes :-))) > hugh.. ! > Regards > > Antoine. > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné. > Règlement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 23:52:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd2-0002TN-00 for ; Fri, 10 Jan 2003 12:47:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:12 +0100 (CET) Received: (qmail 30508 invoked by uid 0); 9 Jan 2003 22:37:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Jan 2003 22:37:49 -0000 Received: by moria.seul.org (Postfix) id C2F6F33E0C; Thu, 9 Jan 2003 17:37:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 17AC433E14; Thu, 9 Jan 2003 17:37:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C43C233E09 for ; Thu, 9 Jan 2003 17:37:25 -0500 (EST) Received: from f-cpu.org (liifi-13-23.n.club-internet.fr [213.44.44.23]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 507CC1703 for ; Thu, 9 Jan 2003 23:36:32 +0100 (CET) Message-ID: <3E1DFD21.5070207@f-cpu.org> Date: Thu, 09 Jan 2003 23:52:17 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030108150032.21061@thrai.stud.uni-hannover.de> <20030109141950.62044@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Thu, Jan 09, 2003 at 10:54:31AM +0100, devik wrote: > > >>>>for inc/dec/neg/cmp..... >>>>Who added next cycle ?? >>>> >>>> >>>The INC unit needs 2 cycles because it became too complex. >>>Life's a bitch, you know... >>> >>> >>hehehe, what irony ! Incrementer unis has its name after >>inc/dec. But now inc/dec are superfluous because they do >>the same job as addi $1 with the same time - addi can be >>even faster for 8bit chunks. >> >> > >Not my fault. Whoever designed the original INC unit underestimated the >cost of a SIMD-enabled `and' reduce tree. > is it caused by the SIMD ? without SIMD, i think it's ok. and i seemed to rememer that adding SIMD was not that expensive. But if INC is going to last 2 cycles, then it should be possible to shove a binary encoder at the end of the unit.... that would be cool and this would help for finding the first char in a strcmp, for example : ; we get here because the loop exited with a non-zero match ; in r1 ( bytes either 00 or FF) LSB1 r1, r2 ; the mask is first priority encoded, to remove trailing bits, ; and the position of the LSB that is set is put into r2 shri 3, r2, r2 ; shift 3 LSB out (because we deal with bytes) or r2, r3, r3 ; the pointer in r3 (where the match occured) is adjusted ; it is normally 64-bit (or more) aligned, and the OR added the offset. i just realized that this nice code seems to be independent from the register size :-) BTW, the binary encoding is already in my mind because the LSB0/1 and MSB0/1 instructions were not always precise about this : is the output the rank of the bit, or simply a single bit ? maybe the binary encoder can be bypassed with a flag bit in the instruction ? So we can have the raw priority encoded result, or the binary encoding, on demand. Of course, because the binary encoding is just a bunch of ORs, the priority encoding is necessary to avoid that more than one bit is set at the input of the binary encoder. YG PS : i hope this mail is not too confusing .... PS2 : here is some pseudo-VHDL that describes a (non-SIMD) binary encoder : generic : N in : vector ((2**N)-1 downto 0); out : vector (N-1 downto 0); assert bitcount(in) < 2 for i in 0 to N-1 do -- scan all the output bits tmp=0; for j in 0 to (2**N)-1 do -- scan all the input bits if (( j >> N) & 1 == 1) then -- generate ? temp= temp OR in(j); endif endfor out(i) <= temp; endfor The logic depth corresponds (for a 64-bit input) to a 32-bit input OR, which is ok. It's probably a bit heavier for SIMD but not much, just a few ANDs here and there. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 23:52:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd3-0002TN-00 for ; Fri, 10 Jan 2003 12:47:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:13 +0100 (CET) Received: (qmail 31348 invoked by uid 0); 9 Jan 2003 22:38:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 9 Jan 2003 22:38:13 -0000 Received: by moria.seul.org (Postfix) id CA35333E12; Thu, 9 Jan 2003 17:37:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88DF933E09; Thu, 9 Jan 2003 17:37:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 8BEAA33E11 for ; Thu, 9 Jan 2003 17:37:28 -0500 (EST) Received: from f-cpu.org (liifi-13-23.n.club-internet.fr [213.44.44.23]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 192561717 for ; Thu, 9 Jan 2003 23:36:48 +0100 (CET) Message-ID: <3E1DFD31.9080600@f-cpu.org> Date: Thu, 09 Jan 2003 23:52:33 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] statistics of direct indexing usage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>FC0 at 1GHz is science fiction for me. >>However, a 2-way or 4-way FC0 system could probably do the same work. >> >> >:) sci-fi from technical or financial point of view ? I take >it from financial point - to get access to appropriate >technology. But is there anything what would prevent FC0 >to go multi-GHz ? > > From the little i know, the register set, as it is, is the main problem. it's a huge piece of silicon and i count on FC1 (a highly hypothtical thing) to solve this problem (among others). It's probably possible to adapt FC0 to reach 1GHz, but it's probably not worth it. It's better to target the design of the next architecture towards this barreer, while the main goal of FC0 is 1) to work 2) to not look ridiculous (and i guess that the first custom dies will be around 200MHz, which is not bad, compared to other 64-bit computers of the same class like embedded MIPS64 chips). However, FC0 is not large compared to a recent x86 spearhead, so it's possible to fit several ones on a chip, or make many for the price of one. When you add to that a good SMP-capable kernel, you can have a good computer with lower EMI and consumption problems :-) I am now (among other things) trying to build a prototype, highly experimental and non-serious 4-node computer with 4 Europe-sized 486-66 boards. I also bought some EPLD and that should be enough to build a crossbar on the ISA backplane (but there are a lot of potential problems, like clocks and pin count etc). i hope i can get some help from the L4/Hurd people for the microkernel part of this silly project :-) Of course, the goal is to learn and develop things that will be reinvested directly into F-CPU, in order to ease the design of heterogeneous SMP systems. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 23:52:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd3-0002TN-01 for ; Fri, 10 Jan 2003 12:47:13 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:13 +0100 (CET) Received: (qmail 5786 invoked by uid 0); 9 Jan 2003 22:38:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 9 Jan 2003 22:38:46 -0000 Received: by moria.seul.org (Postfix) id 227B933E0F; Thu, 9 Jan 2003 17:37:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3FD4933E16; Thu, 9 Jan 2003 17:37:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 76D2E33E0C for ; Thu, 9 Jan 2003 17:37:26 -0500 (EST) Received: from f-cpu.org (liifi-13-23.n.club-internet.fr [213.44.44.23]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 80C5816C4 for ; Thu, 9 Jan 2003 23:37:17 +0100 (CET) Message-ID: <3E1DFD28.3060201@f-cpu.org> Date: Thu, 09 Jan 2003 23:52:24 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> <3E1CC95F.9070406@f-cpu.org> <20030109140808.03508@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Thu, Jan 09, 2003 at 01:59:11AM +0100, Yann Guidon wrote: >[...] > > >>>I do not remember an `sdup' instruction that uses three operands, nor >>>did I implement one. That would have been another logical extension; >>>but I guess that vperm is more useful. BTW: if you're satisfied with >>>an immediate operand, `svseli $n, r2, r1' will do what you want >>>(duplicate chunk of r2). >>> >>it's not doing sdup completely. The 3rd register operand is useful to >>avoid a shift >>in front of a "bare" sdup : >>sdup r1, r2, r3 >>replaces >>shiftr r1*8, r2, r2 >>sdup r2, r3 >> >> >Implemented, with both register and immediate operand. >`vsel' is now a superset of `sdup'. Satisfied? > i guess so ;-) but please keep an alias for sdup because i will not always remember this "superset" thing :-) YG PS: i still think that "vsel" is not a cool name :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 10 10:39:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdQ-0002TN-00 for ; Fri, 10 Jan 2003 12:47:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:36 +0100 (CET) Received: (qmail 21180 invoked by uid 0); 10 Jan 2003 09:44:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 10 Jan 2003 09:44:53 -0000 Received: by moria.seul.org (Postfix) id 6182933CE6; Fri, 10 Jan 2003 04:44:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 40A7633E1C; Fri, 10 Jan 2003 04:44:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id BFD2933CE6 for ; Fri, 10 Jan 2003 04:44:44 -0500 (EST) Received: from a92-137.dialup.iol.cz ([194.228.137.92] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WviT-0000cG-00 for f-cpu@seul.org; Fri, 10 Jan 2003 10:44:42 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Wvd0-0000Ej-00 for f-cpu@seul.org; Fri, 10 Jan 2003 10:39:02 +0100 Date: Fri, 10 Jan 2003 10:39:02 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] Problem with load/store size flags on >64bit F-CPU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, assume you have 256bit cpu. Then you certainly want to load whole register at once (whole cache line :))). But as there was already said we don't need (or want to implement) more that 64bit chunk size. But then when one sets size flags to 8/16/32/64 bits (which is very useful combination imho) he can't do it. When is sets 8/16/32/256 he can't use 256 for other than LSU ops. Would not be better to have separate SRs for LSU so that they use different size meaning ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 10 09:25:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdO-0002TN-01 for ; Fri, 10 Jan 2003 12:47:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:34 +0100 (CET) Received: (qmail 7908 invoked by uid 0); 10 Jan 2003 09:12:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 10 Jan 2003 09:12:59 -0000 Received: by moria.seul.org (Postfix) id 90CD033E19; Fri, 10 Jan 2003 04:12:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E668133E09; Fri, 10 Jan 2003 04:12:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 7A74B33E19 for ; Fri, 10 Jan 2003 04:12:40 -0500 (EST) Received: from a49-137.dialup.iol.cz ([194.228.137.49] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WvDQ-0000Tx-00 for f-cpu@seul.org; Fri, 10 Jan 2003 10:12:38 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WuTq-00009e-00 for f-cpu@seul.org; Fri, 10 Jan 2003 09:25:30 +0100 Date: Fri, 10 Jan 2003 09:25:30 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] statistics of direct indexing usage In-Reply-To: <3E1DFD31.9080600@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > From the little i know, the register set, as it is, is the main problem. > it's a huge piece of silicon and i count on FC1 (a highly hypothtical thing) > to solve this problem (among others). It's probably possible to adapt > FC0 to reach 1GHz, but it's probably not worth it. It's better to > target the design of the next architecture towards this barreer, hmm .. I already though that 6 gates granularity is there to go very fast. Probably the register set doesn't follow the rule ? PIII which can go 1.2 GHz AFAIK does 32bit add within 1 cycle latency so they use higher gate-depth per stage than fcpu which can do obly 8bits. (P4 uses 2 cycles). Probably they have smaller/simpler register set inside ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 10 09:38:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdO-0002TN-00 for ; Fri, 10 Jan 2003 12:47:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:34 +0100 (CET) Received: (qmail 17933 invoked by uid 0); 10 Jan 2003 09:12:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 10 Jan 2003 09:12:46 -0000 Received: by moria.seul.org (Postfix) id 4D09833E13; Fri, 10 Jan 2003 04:12:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E94133E1C; Fri, 10 Jan 2003 04:12:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 21CDF33E09 for ; Fri, 10 Jan 2003 04:12:38 -0500 (EST) Received: from a49-137.dialup.iol.cz ([194.228.137.49] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18WvDM-0000Tx-00 for f-cpu@seul.org; Fri, 10 Jan 2003 10:12:33 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18WugY-00009o-00 for f-cpu@seul.org; Fri, 10 Jan 2003 09:38:38 +0100 Date: Fri, 10 Jan 2003 09:38:38 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: 6/8 bits imm instructions ( was Re: Rep:Re: [f-cpu] statistics of direct indexing usage) In-Reply-To: <20030110203047.1c8a3e2c.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > like to use this particular combinaison?). > > > > uh uh, can you give me please some examples of such instruction ? > > It's the probl=E8me of bit 12-13 (manual 0.2.5). > > It's use in the scan instruction to bit-reverse the input or negate it. > It used as negate sign flag of the MAC instruction. All of this flag > can't be used in the 8 bits immediat of such fonction. So is a pain or > not ? scan and mac doesn't use 12-13 (mac uses it for reg3) according manual 2.7. And why do you want to use immediates for scan !? So that for me is still seems you are interested to have immediates for all insns (even for those where it makes no sense) and use 6 bits (register no) for it. So I agree that it is possibly problem that 2 bits (8-6) can go into needed flag region. But still don't know what to do with it. Did you mean to use 6bit immediate for insns which have no room for 8bit imm and 8 bit for those whose have ? > orthogonal. But in other hand, 8 bit is fewer than 6 :) he !? :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 01:35:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdB-0002TN-01 for ; Fri, 10 Jan 2003 12:47:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:21 +0100 (CET) Received: (qmail 28223 invoked by uid 0); 10 Jan 2003 00:35:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 10 Jan 2003 00:35:50 -0000 Received: by moria.seul.org (Postfix) id E14F733CD0; Thu, 9 Jan 2003 19:35:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0E1C933E13; Thu, 9 Jan 2003 19:35:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a032.home.uni-hannover.de [130.75.232.32]) by moria.seul.org (Postfix) with ESMTP id EFC7933CD0 for ; Thu, 9 Jan 2003 19:35:38 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01699; Fri, 10 Jan 2003 01:35:37 +0100 Message-ID: <20030110013537.18080@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 01:35:37 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Trying to clean up the ROP2 mess References: <20030108181909.24588@thrai.stud.uni-hannover.de> <3E1CC970.1080801@f-cpu.org> <20030109134831.09973@thrai.stud.uni-hannover.de> <3E1DFD2E.6050600@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1DFD2E.6050600@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 11:52:30PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 11:52:30PM +0100, Yann Guidon wrote: > well, i think that the s- prefix on the logic operations looks confusing. > why not try the following : when no size prefix is given, it operates on > the whole register ? There is no room for that. The current encoding: 31-24 opcode+function 23-22 result chunk size 21-20 combine chunk size 19-18 rop2 mode flags 17-12 r3 11- 6 r2 5- 0 r1 leaves absolutely no room for a SIMD bit that could make a difference between `and' (`sand' in my proposal) and `and.64'. > this would avoid the silly questions like : what does the "sand" > instruction do ? :-) > (cf : my "sel" and "poivre" instructions...) I still wait for the request to rename `widen' to `sex'... > >[...] > > > > > >>well, we don't converge on these last details but the encoding i > >>proposed is able to do that > >>(except that there are 2 size fields, one for the writeback size and one > >>for the combine chunk size). > >> > >> > >That's one of the problems. Since you re-used the SIMD flag for the > >additional size flags, > > > > ??? did i miss something ? See above. > > there is no longer a way to specify a register-wide > >operation (remember that registers may be much wider than 64 bits). > >Besides that, the second size flag makes the encoding inconsistent > >with the majority of instructions (one goal is to keep the decoder > >simple!). For the same reason, I dropped the secondary size flags from > >the original `widen' instruction. > > > > > This second size flag is necessary and since it's not going to be larger > than 64 bits/chunks, > it's not as complex as the main size flags. So it can probably become > inconsistent, > but it remains consistent with itself (00=8 bits (default), 01= 16 bits, > 10= 32 bits, 11=64 bits) > This is not the same problem with wide, IIRC... I wonder what it's necessary for. > >>>I will implement this encoding scheme in the next release of my > >>>assembler/disassembler/emulator trio. > >>> > >>you're going to have too much fun : you're insane :-) > >> > >> > >Did you try to install my fctools package? ;) > > > hell, i don't have any decently running linux box .... > shame on me ... When you do it, look at the output from ./configure ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 10 00:34:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd7-0002TN-00 for ; Fri, 10 Jan 2003 12:47:17 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:17 +0100 (CET) Received: (qmail 18516 invoked by uid 0); 9 Jan 2003 23:19:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 9 Jan 2003 23:19:46 -0000 Received: by moria.seul.org (Postfix) id 8D34433E0A; Thu, 9 Jan 2003 18:19:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F283333E18; Thu, 9 Jan 2003 18:19:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 1A3F133E0A for ; Thu, 9 Jan 2003 18:19:34 -0500 (EST) Received: from f-cpu.org (lcbv2-1-14.n.club-internet.fr [213.44.12.14]) by relay-1v.club-internet.fr (Postfix) with ESMTP id E7AE21724 for ; Fri, 10 Jan 2003 00:18:53 +0100 (CET) Message-ID: <3E1E070F.2080405@f-cpu.org> Date: Fri, 10 Jan 2003 00:34:39 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Are 8 bits SIMD mode usefull ? References: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> <1042141954.3545.30.camel@fsol> <20030110232421.12f8c007.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On 09 Jan 2003 20:52:34 +0100 >Antoine wrote: > >>Hi, >> >>Le ven 10/01/2003 à 21:37, nico a écrit : >> >> >>>Just a stupid question : is 8 bits integer mode usefull ? >>> >>> >>I think so ;) >> >> idem :-) >>>"Char" C type are going to be 16 bits (unicode) >>> >>> >>The most widely used encoding of unicode, UTF-8, is based on regular >>bytes (it's a variable length encoding backwards compatible with >>Ascii). That means both legacy character strings and unicode strings >>will use byte operations. Protocol networks, compression formats will >>also remain byte-based. And so on ;) >> >> >> >>>Gimp use 16 bit per channel >>> >>> >>I think that's false, that's even why Film Gimp exists (movie guys >>need more than 8 bits per channel and Gimp can't satisfy their needs). >>However even if Gimp can do 16 bits per channel, most images will >>still only require 8 bits per channel, leading to more compact >>representations and faster calculations (and less memory transfers >>;-)). >> >>Also if you think SIMD in stuff like GIMP, operations with 8-bit >>per channel will be twice faster than with 16-bit channel (because >>your registers have a fixed size and you can stuff twice more bytes >>than 16-bit integers into a register). >> >Half the bandwith consumption but many more operations to avoid >overflow/underflow problems ! I beleive that GPU use float to avoid such >mess ! > > what ? you think that your grarphic card transforms the bytes into floats for display and storage ? AFAIK, with GIMP and most other software, bytes remain bytes. It becomes critical only when your card performs 2D and 3D operations itself for games and acceleration : texture mapping, bump mapping, filtering.... It is NOT the purpose of the PC software to do these heavy computations that now involve filtering and other math stuffs. What you provide to your board is a set of coordinates and textures, that's all. >>Hey, if you wanna write an x86 emulator for F-CPU, you'll also need >>bytes :-))) >> >hugh.. ! > > and i think that even writing a device driver or using a Unix-like kernel involves a LOT of chars. even if the consoles are slowly interpreting unicode, the kernel still deals with error messages in dumb ASCII. >>Regards >> >>Antoine. >> >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 23:52:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd5-0002TN-00 for ; Fri, 10 Jan 2003 12:47:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:15 +0100 (CET) Received: (qmail 2273 invoked by uid 0); 9 Jan 2003 22:39:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 9 Jan 2003 22:39:16 -0000 Received: by moria.seul.org (Postfix) id 75F4933E16; Thu, 9 Jan 2003 17:37:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCB7533E09; Thu, 9 Jan 2003 17:37:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id C0FA033E0F for ; Thu, 9 Jan 2003 17:37:26 -0500 (EST) Received: from f-cpu.org (liifi-13-23.n.club-internet.fr [213.44.44.23]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 191F216AE for ; Thu, 9 Jan 2003 23:37:36 +0100 (CET) Message-ID: <3E1DFD2B.5060104@f-cpu.org> Date: Thu, 09 Jan 2003 23:52:27 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> <3E1CC977.7070803@f-cpu.org> <20030109140151.50113@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Thu, Jan 09, 2003 at 01:59:35AM +0100, Yann Guidon wrote: >[...] > > >>and_reduce (or "combine" as written in ROP2) is not possible >>for very wide data. >> >>Furthermore, the xorn.and trick is useful for "detecting" that a byte >>corresponds, but if you need to find the index of the character, >>the "obvious" answer is to loop over the register. >>if you have a result of 0x00FF000000000000, it's not a good solution. >>So the idea is to "transpose" the bits in the word, that would become >>0x4040404040404040 and the last byte can then ben binary encoded >>in INC (if it's implemented). >> >> > >Wouldn't it be sufficient to `collapse' each chunk into a single bit? >That is, if the chunk's value is not zero, the corresponding bit will >be set, otherwise it will be zero: > > r2 = 0xab00cd00ef0000 > collapse.b r2, r1 > r1 <= 0x54 > collapse.d r2, r1 > r1 <= 0x0e > >and so on. > no i don't think it's interesting enough since it is not reversible and looses most bits. you should also propose the AND and OR modes, to make it more useful. Another use of the "transpose" instruction is when you want to perform boolean operations (like a programmed lookup table) on the consecutive bits in a register. For example, imagine that the tables of a DES round can be translated into a succession of ROP2 instructions. Since the tables are the same in the algorithm, you can use the full width of the registers to computer many lookups in parallel. The "transpose" operation helps "split" and "merge" a word into several registers so each register corresponds to a bit position in the original chunk. Since the operation is reversible (2 transpositions in a row don't change the data), only one opcode is needed. Instead of doing for (i=0; i< X; i++) a[i] = table[a[i]]; it is possible to do : transpose registers ROP2 operations transpose registers The first approach is ok when there is a few lookups, but when it becomes intensive, it is better to compute the operations in parallel. It is less sensitive from the memory architecture and latency and the ROP2 unit allows powerful simplifications compared to other CPUs (there are 8 2R1W operations and 1 3R1W operation) so the cost is low. With 64 registers, even 64-bit wide, 8-input 8-output boolean operations can be performed. The lookup/instruction ratio increases with the register width. The only annoying thing is that the lookup table must be known at compile time .... > A complementary `uncollapse' instruction would be nice, >too (it would allow you to generate chunk masks more easily): > > r2 = 0x5a > uncollapse.b r2, r1 > r1 <= 0x00ff00ffff00ff00 > uncollapse.d r2, r1 > r1 <= 0x0000ffff0000ffffffff0000ffff0000 // yes, that's 128 bits ;) > Something like that is already possible with SDUP and ROP2 so i don't think it is critical, but if you can implement it for free, why not... but it should be based on the sdup instruction, so you can "address" the chunk that you want to duplicate. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 9 23:52:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd4-0002TN-00 for ; Fri, 10 Jan 2003 12:47:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:14 +0100 (CET) Received: (qmail 2576 invoked by uid 0); 9 Jan 2003 22:38:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 9 Jan 2003 22:38:51 -0000 Received: by moria.seul.org (Postfix) id BA2C033E10; Thu, 9 Jan 2003 17:37:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1EBE133E11; Thu, 9 Jan 2003 17:37:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 0CB6633E10 for ; Thu, 9 Jan 2003 17:37:27 -0500 (EST) Received: from f-cpu.org (liifi-13-23.n.club-internet.fr [213.44.44.23]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 612C616F2 for ; Thu, 9 Jan 2003 23:37:22 +0100 (CET) Message-ID: <3E1DFD2E.6050600@f-cpu.org> Date: Thu, 09 Jan 2003 23:52:30 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Trying to clean up the ROP2 mess References: <20030108181909.24588@thrai.stud.uni-hannover.de> <3E1CC970.1080801@f-cpu.org> <20030109134831.09973@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe wrote: >On Thu, Jan 09, 2003 at 01:59:28AM +0100, Yann Guidon wrote: > > >>hello, >> >>Michael Riepe wrote: >> >> >> >>>Subject says it all. We need to make this more regular/orthogonal, and >>>more consistent with the way other instructions work. In particular, >>>we should provide operation variants that >>> >>> - work for 8/16/32/64 bit chunks >>> - mask off the high bits / work on full registers >>> - use direct/and/or mode >>> did you read one of my mails of yesterday about this subject ? >>> >>> >Yes. > > > >>did you look at FORMAT.txt in the source snapshot ? >> >> >Yes. > >>why is MUX not included ? (it is performed by the ROP2 unit >>and uses a subset of the functions) >> >> >Oh, I forgot that. But there will also be two variants: > > mux.size r3, r2, r1 // truncates / zero-extends > smux.size r3, r2, r1 // operates on full word (size ignored) > > well, i think that the s- prefix on the logic operations looks confusing. why not try the following : when no size prefix is given, it operates on the whole register ? this would avoid the silly questions like : what does the "sand" instruction do ? :-) (cf : my "sel" and "poivre" instructions...) >[...] > > >>well, we don't converge on these last details but the encoding i >>proposed is able to do that >>(except that there are 2 size fields, one for the writeback size and one >>for the combine chunk size). >> >> >That's one of the problems. Since you re-used the SIMD flag for the >additional size flags, > ??? did i miss something ? > there is no longer a way to specify a register-wide >operation (remember that registers may be much wider than 64 bits). >Besides that, the second size flag makes the encoding inconsistent >with the majority of instructions (one goal is to keep the decoder >simple!). For the same reason, I dropped the secondary size flags from >the original `widen' instruction. > > This second size flag is necessary and since it's not going to be larger than 64 bits/chunks, it's not as complex as the main size flags. So it can probably become inconsistent, but it remains consistent with itself (00=8 bits (default), 01= 16 bits, 10= 32 bits, 11=64 bits) This is not the same problem with wide, IIRC... >>>I will implement this encoding scheme in the next release of my >>>assembler/disassembler/emulator trio. >>> >>you're going to have too much fun : you're insane :-) >> >> >Did you try to install my fctools package? ;) > hell, i don't have any decently running linux box .... shame on me ... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Fri Jan 10 00:07:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd5-0002TN-01 for ; Fri, 10 Jan 2003 12:47:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:15 +0100 (CET) Received: (qmail 21054 invoked by uid 0); 9 Jan 2003 23:08:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 9 Jan 2003 23:08:32 -0000 Received: by moria.seul.org (Postfix) id 7896933C56; Thu, 9 Jan 2003 18:08:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A51033E0A; Thu, 9 Jan 2003 18:08:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id 0810133C56 for ; Thu, 9 Jan 2003 18:08:25 -0500 (EST) Received: from courbevoie-101-1-194.net1.nerim.net (courbevoie-101-1-194.net1.nerim.net [213.41.180.194]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 4BADA62D69 for ; Fri, 10 Jan 2003 00:08:21 +0100 (CET) Subject: Re: [f-cpu] Are 8 bits SIMD mode usefull ? From: Antoine To: f-cpu@seul.org In-Reply-To: <20030110232421.12f8c007.nicolas.boulay@ifrance.com> References: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> <1042141954.3545.30.camel@fsol> <20030110232421.12f8c007.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1042153638.3543.69.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Jan 2003 00:07:19 +0100 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, Le sam 11/01/2003 à 00:24, nico a écrit : > Half the bandwith consumption but many more operations to avoid > overflow/underflow problems ! Why more operations ? If your channel is 8-bit, the dynamic range will be 0-255. If it's 16-bit, the range will be 0-65535. But it is a difference in precision ; it remains some fixed point arithmetic in the interval [0.0, 1.0]. In _both_ cases, you will have to manage overflow when doing multiplications or additions. The problem is the same. The difference is that not only 8-bit muls and adds may be faster, but you can also do twice more at the same time (SIMD). This means you may be more than twice faster in 8-bit than in 16-bit ! (not counting memory bandwidth issues) On a side note, it would be useful to have something to correct some kind of "rounding problems". For example, if I multiply FF * FF, I get FE01. Which is fine. But if the first FF is a brightness value (maximum = full white) and the second FF is an alpha mask value (maximum = full transparency / opacity), it's obvious that I want the end result to be FF, not FE (because full white with full opacity is still full white ;-)). So a correction needs to be made. I don't know how a program like GIMP handles it, though. Maybe when the alpha is higher than 0x80, it adds the brightness value one more time ;) > I beleive that GPU use float to avoid such > mess ! I don't think so, not for texturing. Until recently the so-called "3d" cards were only 2d texturing devices with a Z-correction mechanism and other useful stuff like Z-buffer. All this is integer. (I am talking about consumer grade video cards, I don't know about "pro" ones) Also, in general, it is faster to use 16-bit textures (4-bit per channel !) than 32-bit ones, because of GPU bandwidth. Which seems to contradict your statement that less bits is slower because there are more overflows. But anyway, apart from 3D calculations there are far many more applications which use plain bytes. To me it seems foolish to design a general-purpose CPU that doesn't know to handle bytes ;) Also I don't see any advantage. Regards Antoine. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 10 00:34:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd6-0002TN-00 for ; Fri, 10 Jan 2003 12:47:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:16 +0100 (CET) Received: (qmail 29285 invoked by uid 0); 9 Jan 2003 23:19:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 9 Jan 2003 23:19:39 -0000 Received: by moria.seul.org (Postfix) id E630133DFE; Thu, 9 Jan 2003 18:19:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F7A933E13; Thu, 9 Jan 2003 18:19:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id A944F33DFE for ; Thu, 9 Jan 2003 18:19:31 -0500 (EST) Received: from f-cpu.org (lcbv2-1-14.n.club-internet.fr [213.44.12.14]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 827F21743 for ; Fri, 10 Jan 2003 00:19:28 +0100 (CET) Message-ID: <3E1E070A.4020605@f-cpu.org> Date: Fri, 10 Jan 2003 00:34:34 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: scatter/gather op ( was:Re: [f-cpu] New EU_SHL Instruction) References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> <3E1CC977.7070803@f-cpu.org> <20030109140151.50113@thrai.stud.uni-hannover.de> <20030110205936.16c2fba1.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Thu, 9 Jan 2003 14:01:51 +0100 >Michael Riepe wrote: > >>On Thu, Jan 09, 2003 at 01:59:35AM +0100, Yann Guidon wrote: >>[...] >> >> >>>and_reduce (or "combine" as written in ROP2) is not possible >>>for very wide data. >>> >>>Furthermore, the xorn.and trick is useful for "detecting" that a >>>byte corresponds, but if you need to find the index of the >>>character, the "obvious" answer is to loop over the register. >>>if you have a result of 0x00FF000000000000, it's not a good >>>solution. So the idea is to "transpose" the bits in the word, that >>>would become 0x4040404040404040 and the last byte can then ben >>>binary encoded in INC (if it's implemented). >>> >>> >>Wouldn't it be sufficient to `collapse' each chunk into a single bit? >> >> > >that's a gather intra-chunk operation. (Such gather op are a lack in >all the f-cpu ISA because inter-chunk operation are maid in 64 bits cpu >instead of thinking about a 256 bits version.) > >A add gather could be usefull too ! > >gather.add.64 V1 V2 R3 > >R3 = V1[0]+V1[1]+V1[2]+V1[3] > +V2[0]+V2[1]+V2[2]+V2[3] > >(big tree adder ?) > > This is easily "emulated" with a logarithmic shift/add sequence : srhi 8, r1, r2 add.8 r1, r2, r1 srhi 16, r1, r2 add.16 r1, r2, r1 srhi 32, r1, r2 add.16 r1, r2, r1 and it works with any kind of instructions (boolean, arithmetic, FP etc.) any comment ? (except "it is slow") YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 00:50:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd8-0002TN-01 for ; Fri, 10 Jan 2003 12:47:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:18 +0100 (CET) Received: (qmail 22846 invoked by uid 0); 9 Jan 2003 23:50:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 9 Jan 2003 23:50:21 -0000 Received: by moria.seul.org (Postfix) id 8E76E33E05; Thu, 9 Jan 2003 18:50:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 31A4B33E13; Thu, 9 Jan 2003 18:50:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a032.home.uni-hannover.de [130.75.232.32]) by moria.seul.org (Postfix) with ESMTP id 6DC3F33E05 for ; Thu, 9 Jan 2003 18:50:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01579; Fri, 10 Jan 2003 00:50:09 +0100 Message-ID: <20030110005009.17708@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 00:50:09 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Are 8 bits SIMD mode usefull ? References: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030110203707.5b43c05e.nicolas.boulay@ifrance.com>; from nico on Fri, Jan 10, 2003 at 08:37:07PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 10, 2003 at 08:37:07PM +0000, nico wrote: > Just a stupid question : is 8 bits integer mode usefull ? Yes! > "Char" C type are going to be 16 bits (unicode) or even 32. 3D are going > in floating point even in the GPU. Gimp use 16 bit per channel (in > certain mode, even more ?). What you mean is `wchar_t', not `char'. And even that can be encoded in a series of bytes (that's called UTF-8). 8-bit mode isn't dead. I guess it will never die. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 01:20:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Wxd9-0002TN-01 for ; Fri, 10 Jan 2003 12:47:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:19 +0100 (CET) Received: (qmail 26281 invoked by uid 0); 10 Jan 2003 00:20:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 10 Jan 2003 00:20:58 -0000 Received: by moria.seul.org (Postfix) id 1075733E18; Thu, 9 Jan 2003 19:20:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1592533E14; Thu, 9 Jan 2003 19:20:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a032.home.uni-hannover.de [130.75.232.32]) by moria.seul.org (Postfix) with ESMTP id 2543833E11 for ; Thu, 9 Jan 2003 19:20:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01654; Fri, 10 Jan 2003 01:20:41 +0100 Message-ID: <20030110012041.01911@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 01:20:41 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC and jmpz vs. jmpl References: <20030108150032.21061@thrai.stud.uni-hannover.de> <20030109141950.62044@thrai.stud.uni-hannover.de> <3E1DFD21.5070207@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1DFD21.5070207@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 11:52:17PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 11:52:17PM +0100, Yann Guidon wrote: [2-stage INC/CMP] > >Not my fault. Whoever designed the original INC unit underestimated the > >cost of a SIMD-enabled `and' reduce tree. > > > is it caused by the SIMD ? > without SIMD, i think it's ok. > and i seemed to rememer that > adding SIMD was not that expensive. Let's count gates... for 64-bit increment, you need a 4:1 tree of depth 3, plus a row of XORs -> that fits. For SIMD, you can use separate trees and a big MUX behind them -> still fits. But now comes the input selector for inc/dec/neg, and another MUX at the output that selects between negated and original operand (for `abs'), and the stage is already too full. Finally, there is the 64:8 binary encoder for `lsb' (or rather, one for each chunk size), and the second stage is full, too. If we would only perform inc/dec, a single stage would probably do the trick. > But if INC is going to last 2 cycles, > then it should be possible to shove a binary > encoder at the end of the unit.... It's already there. > that would be cool and this would help > for finding the first char in a strcmp, for example : > ; we get here because the loop exited with a non-zero match > ; in r1 ( bytes either 00 or FF) > LSB1 r1, r2 ; the mask is first priority encoded, to remove trailing bits, > ; and the position of the LSB that is set is put into r2 > shri 3, r2, r2 ; shift 3 LSB out (because we deal with bytes) > or r2, r3, r3 ; the pointer in r3 (where the match occured) is adjusted > ; it is normally 64-bit (or more) aligned, and the OR > added the offset. You haven't looked at my assembler version of strchr(), have you? It does exactly that. > i just realized that this nice code seems to be independent from the > register size :-) Not if `lsb1' and `shiftri' are restricted to 64 bits (as they are now). > BTW, the binary encoding is already in my mind because the > LSB0/1 and MSB0/1 instructions were not always precise about this : > is the output the rank of the bit, or simply a single bit ? The output is the number (or index) of the bit, plus 1 (it will return 0 if it didn't find anything). > maybe the binary encoder can be bypassed with a flag bit > in the instruction ? So we can have the raw priority encoded > result, or the binary encoding, on demand. Of course, > because the binary encoding is just a bunch of ORs, > the priority encoding is necessary to avoid that more than > one bit is set at the input of the binary encoder. The scheme I use is a little different. The reduce operation will give me a bit vector that contains 0's on one side and 1's on the other: 00000000001111111111111111111111 That simplifies the encoder pretty much; e.g. for a 32-bit operation, result(5) := vector(31); result(4) := vector(31) xor vector(15); result(3) := (vector(31) xor vector(23)) or (vector(15) xor vector(7)); and so on. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 01:24:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdA-0002TN-00 for ; Fri, 10 Jan 2003 12:47:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:20 +0100 (CET) Received: (qmail 12123 invoked by uid 0); 10 Jan 2003 00:24:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 10 Jan 2003 00:24:38 -0000 Received: by moria.seul.org (Postfix) id 0073833E11; Thu, 9 Jan 2003 19:24:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 01D6F33E14; Thu, 9 Jan 2003 19:24:33 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a032.home.uni-hannover.de [130.75.232.32]) by moria.seul.org (Postfix) with ESMTP id 8B92033E11 for ; Thu, 9 Jan 2003 19:24:29 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01669; Fri, 10 Jan 2003 01:24:27 +0100 Message-ID: <20030110012427.62829@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 01:24:27 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New EU_SHL Instruction References: <20030107064710.02532@thrai.stud.uni-hannover.de> <3E1B7B25.3000509@f-cpu.org> <20030108143629.49856@thrai.stud.uni-hannover.de> <3E1CC95F.9070406@f-cpu.org> <20030109140808.03508@thrai.stud.uni-hannover.de> <3E1DFD28.3060201@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1DFD28.3060201@f-cpu.org>; from Yann Guidon on Thu, Jan 09, 2003 at 11:52:24PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 09, 2003 at 11:52:24PM +0100, Yann Guidon wrote: > but please keep an alias for sdup because i will not always remember > this "superset" thing :-) Of course. > PS: i still think that "vsel" is not a cool name :-) Then come up with something better (except salt&pepper ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 10:47:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdR-0002TN-00 for ; Fri, 10 Jan 2003 12:47:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:37 +0100 (CET) Received: (qmail 15954 invoked by uid 0); 10 Jan 2003 09:48:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 10 Jan 2003 09:48:04 -0000 Received: by moria.seul.org (Postfix) id 2100733E1C; Fri, 10 Jan 2003 04:48:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C656D33E1E; Fri, 10 Jan 2003 04:47:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 9EF3733E1C for ; Fri, 10 Jan 2003 04:47:56 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200301100947.25cd; Fri, 10 Jan 2003 09:47:37 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] statistics of direct indexing usage From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jan 2003 09:47:37 GMT Message-id: <200301100947.25cd@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N -----Message d'origine----- De: devik A: Date: 10/01/03 Objet: Re: [f-cpu] statistics of direct indexing usage > From the little i know, the register set, as it is, is th= e main problem. > it's a huge piece of silicon and i count on FC1 (a highly = hypothtical thing) > to solve this problem (among others). It's probably possib= le to adapt > FC0 to reach 1GHz, but it's probably not worth it. It's be= tter to > target the design of the next architecture towards this ba= rreer, hmm .. I already though that 6 gates granularity is there to go very fast.=20 >>>From my point of view this was silly. Imagine our multipl= ier are 6 stage pipeline. In current athlon, the pipeline fpu is 3 st= ages... But Cray had used 4 gates granularity and later 8 gates. I can't= how much stage there are but it must be udge. Probably the register set doesn't follow the rule ? >>>That's why ST50/SH5 cpu (which is quite alike f-cpu) use = 2-3 stages for the register access. PIII which can go 1.2 GHz AFAIK does 32bit add within 1 cycl= e latency so they use higher gate-depth per stage than fcpu which can do obly 8bits. (P4 uses 2 cycles). Probably they have smaller/simpler register set inside ? >>>There register is much more complicated with much more ac= cess port on it. But they pipeline the access to it. (TI DSP C64 (16 bits= integer) have 8 read port and 8 write port by register bank, but with= 2 or 3 pipestage on a 7 stages pipeline) nicO devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 10:59:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdS-0002TN-01 for ; Fri, 10 Jan 2003 12:47:38 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:38 +0100 (CET) Received: (qmail 8457 invoked by uid 0); 10 Jan 2003 10:00:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 10 Jan 2003 10:00:56 -0000 Received: by moria.seul.org (Postfix) id E869333B49; Fri, 10 Jan 2003 05:00:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1D5833E1E; Fri, 10 Jan 2003 05:00:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id B8DD533B49 for ; Fri, 10 Jan 2003 05:00:01 -0500 (EST) Received: from 10.1.1.15 [10.1.1.15] by th00.opsion.fr id 200301100959.2993; Fri, 10 Jan 2003 09:59:41 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Rep:Re: [f-cpu] Are 8 bits SIMD mode usefull ? From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jan 2003 09:59:41 GMT Message-id: <200301100959.2993@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I beleive they are some mix. Sparc/Mips and i beleive all RISC processor didn't have any = 8 bits load (nor 16 bits). They just manipulate 32 or 64 bits at the sam= e time but still handle C "char".=20 I am pretty sure that's x86 is the only cpu that could fetch= 8 or 16 bits from the memory (which make the LSU complexe). The other problem are the usefullness of a 8 bits vector. I = know that picture use this size a lot but it need so much trick ! (i h= ad followed ffmpeg that made a great MMX FFT code, but there are some pr= oblem of darkness or gain in it). The only use could be the convertio= n between picture type (RGB, BGA, YUV420,YUV420P,YUV422,...) but video= card will handle it more and more ! --- GPU use "128 bits pixel" to enable pixel and virtex shader. = Very few instructions could be handle (~128) per pixel/vertex. I coul= d imagine the udge pipeline that is could be. That's the famous Direct= X 9.0 advantage (from 8 bits to 24 bits float for some part in the= >9500 ATI card, then (GeoforceFX ?) to full 32 bits float by channel i= n all the 3D pipeline). nicO -----Message d'origine----- De: Michael Riepe A: f-cpu@seul.org Date: 10/01/03 Objet: Re: [f-cpu] Are 8 bits SIMD mode usefull ? On Fri, Jan 10, 2003 at 08:37:07PM +0000, nico wrote: > Just a stupid question : is 8 bits integer mode usefull ? Yes! > "Char" C type are going to be 16 bits (unicode) or even 32= . 3D are going > in floating point even in the GPU. Gimp use 16 bit per cha= nnel (in > certain mode, even more ?).=20 What you mean is `wchar_t', not `char'. And even that can be= encoded in a series of bytes (that's called UTF-8). 8-bit mode isn't dead. I guess it will never die. --=20 Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 10 11:15:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18WxdU-0002TN-00 for ; Fri, 10 Jan 2003 12:47:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Jan 2003 12:47:40 +0100 (CET) Received: (qmail 1976 invoked by uid 0); 10 Jan 2003 10:16:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 10 Jan 2003 10:16:52 -0000 Received: by moria.seul.org (Postfix) id BCB1333E1D; Fri, 10 Jan 2003 05:16:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBF0733CD7; Fri, 10 Jan 2003 05:16:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from th00.opsion.fr (th00.opsion.fr [62.39.122.10]) by moria.seul.org (Postfix) with SMTP id 0041033E1D for ; Fri, 10 Jan 2003 05:16:12 -0500 (EST) Received: from 10.1.1.14 [10.1.1.14] by th00.opsion.fr id 200301101015.3224; Fri, 10 Jan 2003 10:15:50 GMT Send-By: 140.94.82.18 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000) To: Subject: Mload and Rep:[f-cpu] Problem with load/store size flags on >64bit F-CPU From: "Nicolas Boulay" X-Priority: 3 (normal) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jan 2003 10:15:50 GMT Message-id: <200301101015.3224@th00.opsion.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Soon the same mistake ! 256 bits register means 4*64, 8*32, 16*16, 32*8 bits data wo= rds. (That's why we need more inter-chunk operation.) So the SIMD load will load 256 bits at a time, the scalar on= e only the asked size (which is a pain that current risc processor didn= 't do). 256 bits is a great number because it's 4*64 double which is= a good compromised for a lot of scientifique code. The simplest mload could be a load of 4 registers at a time = with an aligned memory boundary (no heavy and slow shift). So you co= uld load/store Reg0-3, Reg4-7,... in the same time with a comple= te cache line (1024 bit :D), that's why the pointer must be aligned.=20 It's very simple to do it in hardware. It simplify the regis= ter access by using a 16*1024 bits register bank (quicker than a 64*...= ) then you use a mux for choosing narrower data. It could be also an ea= sy means to pipeline register access (2 stages in that case). nicO -----Message d'origine----- De: devik A: Date: 10/01/03 Objet: [f-cpu] Problem with load/store size flags on >64bit = F-CPU Hi, assume you have 256bit cpu. Then you certainly want to load whole register at once (whole cache line :))). But as there was already said we don't need (or want to implement) more that 64bit chunk size. But then when one sets size flags to 8/16/32/64 bits (which is very useful combination imho) he can't do it. When is sets 8/16/32/256 he can't use 256 for other than LSU ops. Would not be better to have separate SRs for LSU so that they use different size meaning ? devik ************************************************************= * To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ____________________________________________________________= _________ Envie de discuter en "live" avec vos amis ? T=E9l=E9charger = MSN Messenger http://www.ifrance.com/_reloc/m la 1=E8re messagerie instant= an=E9e de France ____________________________________________________________= _________ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF= au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez g= agn=E9. R=E8glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 10 19:11:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXp-0004Zp-00 for ; Sat, 11 Jan 2003 17:31:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:37 +0100 (CET) Received: (qmail 31053 invoked by uid 0); 10 Jan 2003 18:12:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 10 Jan 2003 18:12:24 -0000 Received: by moria.seul.org (Postfix) id 8987C33C55; Fri, 10 Jan 2003 13:12:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CBE7F33E2C; Fri, 10 Jan 2003 13:12:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B6BE033C55 for ; Fri, 10 Jan 2003 13:12:15 -0500 (EST) Received: from a9-137.dialup.iol.cz ([194.228.137.9] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18X3dZ-0002HY-00 for f-cpu@seul.org; Fri, 10 Jan 2003 19:12:13 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18X3d1-0004Ct-00 for f-cpu@seul.org; Fri, 10 Jan 2003 19:11:35 +0100 Date: Fri, 10 Jan 2003 19:11:35 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] GCC snapshot 20030110 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Uploaded fo seul.org contrib. Goes thru MR's AS but spills some errors about undefined syms (Michael ?). Status as of 2003-01-10: Better code, seems to be able to go thru MR 1.0.1 AS. He has bugs in logic defs so I killed size flags for now. Constant loading with loadcons[x] seems pretty good now. We have sometimes problems with offset overflows during frame pointer elimintion. loadcons of symbols needs to be finished (splitted). I no longer expect that results are zero-extended and thus we will need explicit patterns to kill some zero extensions. Also I use LSB test in conditional jumps and moves extensively. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 11 21:30:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXr-0004Zp-00 for ; Sat, 11 Jan 2003 17:31:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:39 +0100 (CET) Received: (qmail 18560 invoked by uid 0); 10 Jan 2003 19:30:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 10 Jan 2003 19:30:04 -0000 Received: by moria.seul.org (Postfix) id D68F533E31; Fri, 10 Jan 2003 14:30:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B48B833E37; Fri, 10 Jan 2003 14:29:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id EF83533E31 for ; Fri, 10 Jan 2003 14:29:55 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 02E5B62DE4 for ; Fri, 10 Jan 2003 20:29:53 +0100 (CET) Date: Sat, 11 Jan 2003 20:30:41 +0000 From: nico To: f-cpu@seul.org Subject: Re: 6/8 bits imm instructions ( was Re: Rep:Re: [f-cpu] statistics of direct indexing usage) Message-Id: <20030111203041.3a46f2cd.nicolas.boulay@ifrance.com> In-Reply-To: References: <20030110203047.1c8a3e2c.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 10 Jan 2003 09:38:38 +0100 (CET) devik wrote: > > > > like to use this particular combinaison?). > > > > > > uh uh, can you give me please some examples of such instruction ? > > > > It's the problème of bit 12-13 (manual 0.2.5). > > > > It's use in the scan instruction to bit-reverse the input or negate > > it. It used as negate sign flag of the MAC instruction. All of this > > flag can't be used in the 8 bits immediat of such fonction. So is a > > pain or not ? > > scan and mac doesn't use 12-13 (mac uses it for reg3) according > manual 2.7. And why do you want to use immediates for scan !? > > So that for me is still seems you are interested to have immediates > for all insns (even for those where it makes no sense) and use > 6 bits (register no) for it. > yes, you get it. > So I agree that it is possibly problem that 2 bits (8-6) can > go into needed flag region. > But still don't know what to do with it. > Did you mean to use 6bit immediate for insns which have no > room for 8bit imm and 8 bit for those whose have ? > 8 bit is better to have bigger number, but 6 bits is nicer because all instructions could used. So it is a problem or not ? > > orthogonal. But in other hand, 8 bit is fewer than 6 :) > > he !? :) > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger > http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 14:34:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXw-0004Zp-01 for ; Sat, 11 Jan 2003 17:31:44 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:44 +0100 (CET) Received: (qmail 9046 invoked by uid 0); 10 Jan 2003 23:37:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 10 Jan 2003 23:37:15 -0000 Received: by moria.seul.org (Postfix) id 86AAC33E3D; Fri, 10 Jan 2003 18:37:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5012533E3A; Fri, 10 Jan 2003 18:37:08 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a249.home.uni-hannover.de [130.75.232.249]) by moria.seul.org (Postfix) with ESMTP id 483BE33E27 for ; Fri, 10 Jan 2003 18:36:59 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00641; Fri, 10 Jan 2003 14:34:54 +0100 Message-ID: <20030110143454.40340@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 14:34:54 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Problem with load/store size flags on >64bit F-CPU References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Jan 10, 2003 at 10:39:02AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 10, 2003 at 10:39:02AM +0100, devik wrote: > Hi, > > assume you have 256bit cpu. Then you certainly want to > load whole register at once (whole cache line :))). > > But as there was already said we don't need (or want to > implement) more that 64bit chunk size. That's true for arithmetic operations, because they don't scale well (the size of the multiplier, for example, grows quadratically with the word size, and most EUs would have a higher latency). Loads, on the other hand, could be any size as long as the cache lines are long enough. > But then when one sets size flags to 8/16/32/64 bits > (which is very useful combination imho) he can't do it. > When is sets 8/16/32/256 he can't use 256 for other than > LSU ops. We can, by way of the special registers. In a `wide' F-CPU, you can re-map the chunk sizes to, say, 8/256/32/64 (I expect 16-bit mode to be used rather infrequently). It just isn't supported in the assembler/emulator yet. > Would not be better to have separate SRs for LSU so that > they use different size meaning ? The current SR scheme is debatable anyway. Instead of 4 SRs (one for each size), we should use a single one, which is faster to save/restore. With a single SR_SIZE with four 16-bit chunks, we could address chunk sizes up to 65536 bits if the sizes are stored in a linear fashion, or 2^65535 if the values are logarithmic. I vote for the latter, btw. Another question is how we can support remapped sizes in the assembler. I remember that some Intel assemblers had an `assume' directive that told the assembler which segment register held the address of which segment. We could use something similar, e.g. geti $SR_SIZE, r1 loadcons.1 $5, r1 // now you know why I suggested four 16-bit chunks :) puti $SR_SIZE, r1 .regsize 0, 5, 2, 3 // .01 means 256 bits ... load.256 r2, r3 ... loadcons.1 $1, r1 puti $SR_SIZE, r1 .regsize 0, 1, 2, 3 // restore to default case Since the assembler knows the mapping, it can reject instructions that are unavailable at that point (like load.16 in this case). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 10 14:08:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXx-0004Zp-00 for ; Sat, 11 Jan 2003 17:31:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:45 +0100 (CET) Received: (qmail 13606 invoked by uid 0); 10 Jan 2003 23:37:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 10 Jan 2003 23:37:40 -0000 Received: by moria.seul.org (Postfix) id 7A45133E37; Fri, 10 Jan 2003 18:37:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D921633E3E; Fri, 10 Jan 2003 18:37:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a249.home.uni-hannover.de [130.75.232.249]) by moria.seul.org (Postfix) with ESMTP id 006FE33E37 for ; Fri, 10 Jan 2003 18:37:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00577; Fri, 10 Jan 2003 14:08:10 +0100 Message-ID: <20030110140810.31691@thrai.stud.uni-hannover.de> Date: Fri, 10 Jan 2003 14:08:10 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: 6/8 bits imm instructions ( was Re: Rep:Re: [f-cpu] statistics of direct indexing usage) References: <20030110203047.1c8a3e2c.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Jan 10, 2003 at 09:38:38AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 10, 2003 at 09:38:38AM +0100, devik wrote: > > > > like to use this particular combinaison?). > > > > > > uh uh, can you give me please some examples of such instruction ? > > > > It's the problème of bit 12-13 (manual 0.2.5). > > > > It's use in the scan instruction to bit-reverse the input or negate it. > > It used as negate sign flag of the MAC instruction. All of this flag > > can't be used in the 8 bits immediat of such fonction. So is a pain or > > not ? > > scan and mac doesn't use 12-13 (mac uses it for reg3) according > manual 2.7. And why do you want to use immediates for scan !? I guess he's counting from the other side (that is, opcode in 0-7). In that case, 12-13 would be the two flags that will be lost if you extend r3 (17-12, in the official counting scheme) to an imm8 (19-12). In case of scan ([lm]sb[01]), a third operand doesn't make sense, be it register or immediate. `maci', on the other hand, might be an option - but that one has room for an 8-bit immediate. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 11 00:45:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXx-0004Zp-01 for ; Sat, 11 Jan 2003 17:31:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:45 +0100 (CET) Received: (qmail 15608 invoked by uid 0); 10 Jan 2003 23:45:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 10 Jan 2003 23:45:45 -0000 Received: by moria.seul.org (Postfix) id 7846233E27; Fri, 10 Jan 2003 18:45:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76C9633E3A; Fri, 10 Jan 2003 18:45:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a249.home.uni-hannover.de [130.75.232.249]) by moria.seul.org (Postfix) with ESMTP id 7E96933E28 for ; Fri, 10 Jan 2003 18:45:36 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA04134; Sat, 11 Jan 2003 00:45:42 +0100 Message-ID: <20030111004541.23535@thrai.stud.uni-hannover.de> Date: Sat, 11 Jan 2003 00:45:41 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] GCC snapshot 20030110 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Jan 10, 2003 at 07:11:35PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 10, 2003 at 07:11:35PM +0100, devik wrote: > Uploaded fo seul.org contrib. Goes thru MR's AS but > spills some errors about undefined syms (Michael ?). Please send me an (as) input file that reproduces the error; I will check that. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 11 06:16:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XOXz-0004Zp-01 for ; Sat, 11 Jan 2003 17:31:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 11 Jan 2003 17:31:47 +0100 (CET) Received: (qmail 29010 invoked by uid 0); 11 Jan 2003 05:01:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 11 Jan 2003 05:01:49 -0000 Received: by moria.seul.org (Postfix) id E37B533E45; Sat, 11 Jan 2003 00:01:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5FA7233E43; Sat, 11 Jan 2003 00:01:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 1B42A33C7E for ; Sat, 11 Jan 2003 00:01:39 -0500 (EST) Received: from f-cpu.org (lcbv3-1-7.n.club-internet.fr [213.44.91.7]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 010DA16CF for ; Sat, 11 Jan 2003 06:01:36 +0100 (CET) Message-ID: <3E1FA8BF.3070209@f-cpu.org> Date: Sat, 11 Jan 2003 06:16:47 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Problem with load/store size flags on >64bit F-CPU References: <20030110143454.40340@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >>Would not be better to have separate SRs for LSU so that >>they use different size meaning ? >> >> > > > >The current SR scheme is debatable anyway. Instead of 4 SRs (one for >each size), we should use a single one, which is faster to save/restore. >With a single SR_SIZE with four 16-bit chunks, we could address chunk >sizes up to 65536 bits if the sizes are stored in a linear fashion, >or 2^65535 if the values are logarithmic. I vote for the latter, btw. > > The "status word" that is saved in the CMB contains a compacted version of the SR_SIZE registers. We don't expect that an interrupted task can be restarted on another CPU, so the format can vary (and if that is to happen, then the OS can translate the format). I prefer to not think that 64K bit registers will never happen. things happen at a time or another so the user-visible interface of the SR_SIZE register has to be kept as simple and limitless as possible. Saves and restores can then be performed in an adapted way on later architectures. In fact, the OS can even trap the writes to the SR_SIZE and update itself the "compacted version" in the CMB. But i prefer to not speak about something that i don't know yet how to implement. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 11 16:15:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XUwn-0000hk-01 for ; Sun, 12 Jan 2003 00:21:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 12 Jan 2003 00:21:49 +0100 (CET) Received: (qmail 23548 invoked by uid 0); 11 Jan 2003 19:14:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 11 Jan 2003 19:14:58 -0000 Received: by moria.seul.org (Postfix) id C454D33CCF; Sat, 11 Jan 2003 14:14:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E71B33CCE; Sat, 11 Jan 2003 14:13:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a183.home.uni-hannover.de [130.75.232.183]) by moria.seul.org (Postfix) with ESMTP id 46B6033CCE for ; Sat, 11 Jan 2003 14:13:02 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00802; Sat, 11 Jan 2003 16:15:44 +0100 Message-ID: <20030111161544.22943@thrai.stud.uni-hannover.de> Date: Sat, 11 Jan 2003 16:15:44 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Problem with load/store size flags on >64bit F-CPU References: <20030110143454.40340@thrai.stud.uni-hannover.de> <3E1FA8BF.3070209@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E1FA8BF.3070209@f-cpu.org>; from Yann Guidon on Sat, Jan 11, 2003 at 06:16:47AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Jan 11, 2003 at 06:16:47AM +0100, Yann Guidon wrote: [...] > I prefer to not think that 64K bit registers will never happen. Neither do I - but 2**65535 bit registers are rather unlikely, don't you think? I do expect the register sizes to be powers of two, however. Therefore, logarithmic encoding is my choice. > things happen at a time or another so the user-visible interface > of the SR_SIZE register has to be kept as simple and limitless as possible. A single register *is* simple. Four registers aren't. Consider a function that has special requirements and must save/restore the size bits and change them on the fly. You'll keep the settings in a (global) register that can be pushed on the stack easily, and just do something like // prologue ... // save settings storei.64 $-8, r62, global_register // load desired sizes, e.g. loadcons.1 $LOG2_DESIRED_SIZE, global_register // update SR puti $SR_SIZE, global_register ... // function code goes here ... // epilogue ... // restore settings loadi.64 $8, r62, global_register // restore SR puti $SR_SIZE, global_register ... jmp r63 when the SR needs to be modified, instead of the slower get/modify/put sequence for up to 4 registers (not to mention save/restore) - remember that SR access is a potentially slow operation. This may become a standard idiom on operating systems where 64 bits is the default. BTW: We might specify in the calling conventions that SR_SIZE must have its default value on entry/exit to/from (inter-module) functions, and that only the least significant 64 bits of the argument registers are valid. We also should reserve a global register that shadows SR_SIZE, as described above. I also like the idea to have different SR_SIZE settings for arithmetic operations and for load/store. The sizes for arithmetic ops could remain fixed at first, and only load/store chunk sizes would be variable. That would reflect the decision that arithmetic ops are limited to 64 bits (for now). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jan 13 00:05:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XUwp-0000hk-02 for ; Sun, 12 Jan 2003 00:21:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 12 Jan 2003 00:21:51 +0100 (CET) Received: (qmail 3702 invoked by uid 0); 11 Jan 2003 22:05:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 11 Jan 2003 22:05:16 -0000 Received: by moria.seul.org (Postfix) id 5B44133D1C; Sat, 11 Jan 2003 17:05:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2959C33D0C; Sat, 11 Jan 2003 17:05:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 408FF33CF6 for ; Sat, 11 Jan 2003 17:05:08 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id 07E6740E2D for ; Sat, 11 Jan 2003 22:52:51 +0100 (CET) Date: Sun, 12 Jan 2003 23:05:57 +0000 From: nico To: f-cpu@seul.org Subject: Re: scatter/gather op ( was:Re: [f-cpu] New EU_SHL Instruction) Message-Id: <20030112230557.7a34873a.nicolas.boulay@ifrance.com> In-Reply-To: <3E1E070A.4020605@f-cpu.org> References: <20030108084730.18996.qmail@web14910.mail.yahoo.com> <3E1CC977.7070803@f-cpu.org> <20030109140151.50113@thrai.stud.uni-hannover.de> <20030110205936.16c2fba1.nicolas.boulay@ifrance.com> <3E1E070A.4020605@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 10 Jan 2003 00:34:34 +0100 Yann Guidon wrote: > hi, > > nico wrote: > > >On Thu, 9 Jan 2003 14:01:51 +0100 > >Michael Riepe wrote: > > > >>On Thu, Jan 09, 2003 at 01:59:35AM +0100, Yann Guidon wrote: > >>[...] > >> > >> > >>>and_reduce (or "combine" as written in ROP2) is not possible > >>>for very wide data. > >>> > >>>Furthermore, the xorn.and trick is useful for "detecting" that a > >>>byte corresponds, but if you need to find the index of the > >>>character, the "obvious" answer is to loop over the register. > >>>if you have a result of 0x00FF000000000000, it's not a good > >>>solution. So the idea is to "transpose" the bits in the word, that > >>>would become 0x4040404040404040 and the last byte can then ben > >>>binary encoded in INC (if it's implemented). > >>> > >>> > >>Wouldn't it be sufficient to `collapse' each chunk into a single > >bit?> > >> > > > >that's a gather intra-chunk operation. (Such gather op are a lack in > >all the f-cpu ISA because inter-chunk operation are maid in 64 bits > >cpu instead of thinking about a 256 bits version.) > > > >A add gather could be usefull too ! > > > >gather.add.64 V1 V2 R3 > > > >R3 = V1[0]+V1[1]+V1[2]+V1[3] > > +V2[0]+V2[1]+V2[2]+V2[3] > > > >(big tree adder ?) > > > > > > This is easily "emulated" with a logarithmic shift/add sequence : > srhi 8, r1, r2 > add.8 r1, r2, r1 > srhi 16, r1, r2 > add.16 r1, r2, r1 > srhi 32, r1, r2 > add.16 r1, r2, r1 > and it works with any kind of instructions (boolean, arithmetic, FP > etc.) > > any comment ? (except "it is slow") Does that work "large" register set ? (256 bits ?) I don't like so much to have (even) a log operation to finish a loop. In that case, if the loop is "not big" you have to be very carefull not to waste to much cycle in finishing the job. nicO > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn_. > R_glement : http://www.ifrance.com/_reloc/sign.sms ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Jan 13 00:11:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18XUwq-0000hk-00 for ; Sun, 12 Jan 2003 00:21:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 12 Jan 2003 00:21:52 +0100 (CET) Received: (qmail 11576 invoked by uid 0); 11 Jan 2003 22:10:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 11 Jan 2003 22:10:31 -0000 Received: by moria.seul.org (Postfix) id DB4DD33C7E; Sat, 11 Jan 2003 17:10:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C652833CF6; Sat, 11 Jan 2003 17:10:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id C4A4133C7E for ; Sat, 11 Jan 2003 17:10:20 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 0210A62DE4 for ; Sat, 11 Jan 2003 23:10:17 +0100 (CET) Date: Sun, 12 Jan 2003 23:11:10 +0000 From: nico To: f-cpu@seul.org Subject: Re: Rep:Re: [f-cpu] Are 8 bits SIMD mode usefull ? Message-Id: <20030112231110.7a0d3914.nicolas.boulay@ifrance.com> In-Reply-To: <200301100959.2993@th00.opsion.fr> References: <200301100959.2993@th00.opsion.fr> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I have "lost" the previous mail thread, sorry. I really don't understand the interret to change the size of the chunk. Our cpu is natively a vector machine so why not stay with that ! In a 256 bits machine you will load 4 64 integers at a time, that's all. If we add some "gather" instruction the "SR_SIZE" will not have any interrest (or only to divide loop counter). nicO On Fri, 10 Jan 2003 09:59:41 GMT "Nicolas Boulay" wrote: > I beleive they are some mix. > > Sparc/Mips and i beleive all RISC processor didn't have any 8 bits > load(nor 16 bits). They just manipulate 32 or 64 bits at the same time > but still handle C "char". > > I am pretty sure that's x86 is the only cpu that could fetch 8 or 16 > bits from the memory (which make the LSU complexe). > > The other problem are the usefullness of a 8 bits vector. I know that > picture use this size a lot but it need so much trick ! (i had > followed ffmpeg that made a great MMX FFT code, but there are some > problem of darkness or gain in it). The only use could be the > convertion between picture type (RGB, BGA, YUV420,YUV420P,YUV422,...) > but video card will handle it more and more ! > > --- > GPU use "128 bits pixel" to enable pixel and virtex shader. Very few > instructions could be handle (~128) per pixel/vertex. I could imagine > the udge pipeline that is could be. That's the famous DirectX 9.0 > advantage (from 8 bits to 24 bits float for some part in the >9500 ATI > card, then (GeoforceFX ?) to full 32 bits float by channel in all the > 3D pipeline). > > nicO > > -----Message d'origine----- > De: Michael Riepe > A: f-cpu@seul.org > Date: 10/01/03 > Objet: Re: [f-cpu] Are 8 bits SIMD mode usefull ? > > On Fri, Jan 10, 2003 at 08:37:07PM +0000, nico wrote: > > Just a stupid question : is 8 bits integer mode usefull ? > > Yes! > > > "Char" C type are going to be 16 bits (unicode) or even 32. 3D are > going > > in floating point even in the GPU. Gimp use 16 bit per channel (in > > certain mode, even more ?). > > What you mean is `wchar_t', not `char'. And even that can be encoded > in a series of bytes (that's called UTF-8). > > 8-bit mode isn't dead. I guess it will never die. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné. > Règlement : http://www.ifrance.com/_reloc/sign.sms > > > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger > http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de > France > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > _____________________________________________________________________ > Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger > http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de > France ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jan 12 03:53:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Y3zU-00008z-00 for ; Mon, 13 Jan 2003 13:46:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Jan 2003 13:46:56 +0100 (CET) Received: (qmail 1727 invoked by uid 0); 12 Jan 2003 02:53:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 12 Jan 2003 02:53:18 -0000 Received: by moria.seul.org (Postfix) id 8F6ED33C73; Sat, 11 Jan 2003 21:53:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7A23433CCE; Sat, 11 Jan 2003 21:53:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a230.home.uni-hannover.de [130.75.232.230]) by moria.seul.org (Postfix) with ESMTP id B8D8133C73 for ; Sat, 11 Jan 2003 21:53:08 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA24011; Sun, 12 Jan 2003 03:53:06 +0100 Message-ID: <20030112035306.58570@thrai.stud.uni-hannover.de> Date: Sun, 12 Jan 2003 03:53:06 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New fctools 0.2 on seul.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Subject says it all. I uploaded fctools-0.2.tar.gz to the usual place. It should work with devik's next gcc release (not the current one). At least I was able to compile and assemble a number of source files with as 0.2 and an intermediate version of gcc. For more information, please consult the README file. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jan 13 00:07:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Y3zq-00008z-00 for ; Mon, 13 Jan 2003 13:47:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Jan 2003 13:47:18 +0100 (CET) Received: (qmail 20272 invoked by uid 0); 12 Jan 2003 23:14:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 12 Jan 2003 23:14:18 -0000 Received: by moria.seul.org (Postfix) id 57B0833C80; Sun, 12 Jan 2003 18:14:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6730E33D93; Sun, 12 Jan 2003 18:14:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a190.home.uni-hannover.de [130.75.232.190]) by moria.seul.org (Postfix) with ESMTP id 8D10D33C80 for ; Sun, 12 Jan 2003 18:14:13 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA22379; Mon, 13 Jan 2003 00:07:19 +0100 Message-ID: <20030113000719.11954@thrai.stud.uni-hannover.de> Date: Mon, 13 Jan 2003 00:07:19 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Instruction census Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi F-gang, I compiled a set of C files (among them libelf and fctools) with fcpu-gcc and started to count instructions. The most often used single instruction was an ordinary unconditional `move': 98104 instructions total 13079 move 13.3% ( 13.3% total) 10846 load 11.0% ( 24.3% total) 9741 loadcons 9.9% ( 34.3% total) 9188 loadaddri 9.3% ( 43.6% total) 8574 jmp 8.7% ( 52.4% total) 8188 addi 8.3% ( 60.7% total) 7386 jmp{cc} 7.5% ( 68.2% total) 6169 loadconsx 6.2% ( 74.5% total) 3545 storei 3.6% ( 78.1% total) 3533 loadi 3.6% ( 81.7% total) 3459 store 3.5% ( 85.3% total) 2076 add 2.1% ( 87.4% total) 1668 shiftli 1.7% ( 89.1% total) 1523 xori 1.5% ( 90.6% total) [...] The vast majority of instructions are load/store, add/sub/loadaddr[i], loadcons[x], move and jmp - together, they contribute 89% of the code. Add ROP2, SHL, CMP and INC functions and you'll reach 99.7% - that's almost everything. Here's a detailed list of EU usages: 21383 lsu 21.7% ( 21.7% total) 21031 asu 21.4% ( 43.2% total) 15910 loadcons 16.2% ( 59.4% total) 13079 move 13.3% ( 72.7% total) 8574 jmp 8.7% ( 81.5% total) 7386 jmp{cc} 7.5% ( 89.0% total) 4095 rop2 4.1% ( 93.2% total) 3496 shl 3.5% ( 96.7% total) 1781 cmp 1.8% ( 98.6% total) 1111 inc 1.1% ( 99.7% total) 112 move{cc} 0.1% ( 99.8% total) 86 idu 0.0% ( 99.9% total) 60 imu 0.0% (100.0% total) This is mostly the profile I expected from standard software. Note that I compiled with `-O -fomit-frame-pointer'; otherwise, the result would have been even worse (without optimization, the code is a hell of a mess). With `-O3', the number of instructions increases slightly, `-Os' reduces it by approximately 5%; but the profile is rather similar in either case. It's interesting to see that integer division (div/rem) is more often used than multiplication (I didn't expect that). It's probably due to the heavy use of shift-and-add sequences that gcc substitutes for simple multiplications with constants. That's going to change, because a mul (or mac) instruction is often faster. Another interesting fact is that 1/4 of the multiplications are actually `mac' operations (most of them of the kind where all operands have the same size). One can also observe that add, sub, xor and shift[lr] are most often used in their immediate form, while or isn't. Signed compares are less often used than unsigned ones, and left shifts occur twice as often as right shifts (again due to shift-and-add, I guess). Goals for optimization (IMHO): - reduce number of load/store instructions - increase number of conditional moves (in favor of jmp{cc}) - avoid shift-and-add where mul/mac is faster - make use of divrem[s] instruction - make use of SIMD instructions -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Jan 14 01:33:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Y3zr-00008z-00 for ; Mon, 13 Jan 2003 13:47:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Jan 2003 13:47:19 +0100 (CET) Received: (qmail 28525 invoked by uid 0); 12 Jan 2003 23:35:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Jan 2003 23:35:23 -0000 Received: by moria.seul.org (Postfix) id EE68133D93; Sun, 12 Jan 2003 18:35:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 520CD33D9B; Sun, 12 Jan 2003 18:35:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id BA58233D93 for ; Sun, 12 Jan 2003 18:35:20 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id EBC7D62D07 for ; Mon, 13 Jan 2003 00:35:16 +0100 (CET) Date: Tue, 14 Jan 2003 00:33:48 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Message-Id: <20030114003348.0bfb1781.nicolas.boulay@ifrance.com> In-Reply-To: <20030113000719.11954@thrai.stud.uni-hannover.de> References: <20030113000719.11954@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, 13 Jan 2003 00:07:19 +0100 Michael Riepe wrote: > > The vast majority of instructions are load/store, add/sub/loadaddr[i] It's even worse ! There is much more load than store ! Could you calculate the distribution of distance between the load and the effective use of the data ? Because load latency is udge(2-3 on L1, until ~200 from the main memory). Store is not a such problem if we use store buffer and write allocate. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jan 13 01:34:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Y3zv-00008z-00 for ; Mon, 13 Jan 2003 13:47:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Jan 2003 13:47:23 +0100 (CET) Received: (qmail 15090 invoked by uid 0); 13 Jan 2003 00:34:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 13 Jan 2003 00:34:50 -0000 Received: by moria.seul.org (Postfix) id 246C233D84; Sun, 12 Jan 2003 19:34:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 78C0B33D9D; Sun, 12 Jan 2003 19:34:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a190.home.uni-hannover.de [130.75.232.190]) by moria.seul.org (Postfix) with ESMTP id 8EE7733D84 for ; Sun, 12 Jan 2003 19:34:45 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA23253; Mon, 13 Jan 2003 01:34:44 +0100 Message-ID: <20030113013444.45491@thrai.stud.uni-hannover.de> Date: Mon, 13 Jan 2003 01:34:44 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030113000719.11954@thrai.stud.uni-hannover.de> <20030114003348.0bfb1781.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030114003348.0bfb1781.nicolas.boulay@ifrance.com>; from nico on Tue, Jan 14, 2003 at 12:33:48AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 14, 2003 at 12:33:48AM +0000, nico wrote: > On Mon, 13 Jan 2003 00:07:19 +0100 > Michael Riepe wrote: > > > > > The vast majority of instructions are load/store, add/sub/loadaddr[i] > > It's even worse ! There is much more load than store ! There are about 3.6% loadi and 3.6% storei instructions (probably most of them come from register save/restore code from function prologues and epilogues), 11.0% `real' loads and 3.5% `real' stores (caused by the C code). These are average numbers; actual values vary with the kind of program. The F-CPU emulator alone has a total of 7820 loads and 7220 stores, for example, which is a rather different picture. The F-CPU instruction decoder from libfcpu_opcodes even has less loads than stores (149/173) - it writes to a character buffer most of the time. Table-based state machine code - e.g. yacc/(f)lex output - usually has more loads (I observed 1.7 ... 1.9 loads per store). The most extreme case, however, was combine.c from the gcc source tree: 5257 loads, 856 stores (that's a factor of 6.14!). > Could you > calculate the distribution of distance between the load and the > effective use of the data ? That's hard to do with nothing else but a text analysis... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jan 13 02:11:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Y3zv-00008z-01 for ; Mon, 13 Jan 2003 13:47:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Jan 2003 13:47:23 +0100 (CET) Received: (qmail 20776 invoked by uid 0); 13 Jan 2003 00:56:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 13 Jan 2003 00:56:03 -0000 Received: by moria.seul.org (Postfix) id C767633D9F; Sun, 12 Jan 2003 19:56:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3151C33E1A; Sun, 12 Jan 2003 19:56:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 82B6D33D9F for ; Sun, 12 Jan 2003 19:56:01 -0500 (EST) Received: from f-cpu.org (lcbv5-1-3.n.club-internet.fr [213.44.18.3]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 83B8516F2 for ; Mon, 13 Jan 2003 01:55:20 +0100 (CET) Message-ID: <3E221232.2040807@f-cpu.org> Date: Mon, 13 Jan 2003 02:11:14 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030113000719.11954@thrai.stud.uni-hannover.de> <20030114003348.0bfb1781.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Mon, 13 Jan 2003 00:07:19 +0100 >Michael Riepe wrote: > >>The vast majority of instructions are load/store, add/sub/loadaddr[i] >> >> >It's even worse ! There is much more load than store ! > isn't it the usual case ? MR's numbers look ok. > Could you calculate the distribution of distance between the load and the >effective use of the data ? > in "classical code" it's immediate. i guess they haven't yet "teached" GCC to heavily prefetch things. > Because load >latency is udge(2-3 on L1, until ~200 from the main memory). Store is >not a such problem if we use store buffer and write allocate. > > To quote MR : "life's a bitch". YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jan 13 12:25:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YGWx-0001El-00 for ; Tue, 14 Jan 2003 03:10:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 03:10:19 +0100 (CET) Received: (qmail 28889 invoked by uid 0); 13 Jan 2003 23:11:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 13 Jan 2003 23:11:59 -0000 Received: by moria.seul.org (Postfix) id 3C9A233C9F; Mon, 13 Jan 2003 18:11:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AD34F33E5F; Mon, 13 Jan 2003 18:11:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id DF60633C9F for ; Mon, 13 Jan 2003 18:11:56 -0500 (EST) Received: from a95-137.dialup.iol.cz ([194.228.137.95] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18YDkG-0003Vm-00 for f-cpu@seul.org; Tue, 14 Jan 2003 00:11:53 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Y2ib-00018R-00 for f-cpu@seul.org; Mon, 13 Jan 2003 12:25:25 +0100 Date: Mon, 13 Jan 2003 12:25:25 +0100 (CET) From: devik X-X-Sender: To: F-CPU Mailing List Subject: Re: [f-cpu] Instruction census In-Reply-To: <20030113000719.11954@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > I compiled a set of C files (among them libelf and fctools) with fcpu-gcc > and started to count instructions. The most often used single instruction > was an ordinary unconditional `move': was was not it one with comment "zero_extend" ? Most of them will be gone but we will have to duplicate almost ALL patterns with implicit zero extend (as fcpu zeroextends automatically as x86-64 from AMD does). I'm trying to learn combiner to do it by changing its code but it is not simple at all. Fortunately one of czech core gcc developers devoted his time to communicate with and help me. > The vast majority of instructions are load/store, add/sub/loadaddr[i], yep ... gcc can't prefetch and "cache" data in registers too early because of read-write ordering rules which can't be resolved by aliasing analysis. It is why IA-64 has ld.a instruction. There if flag which tells gcc to use "possibly dangerous" early fetches - but it doesn't follow C standard then. The add/sub case: CSE generates all addresses as PLUS of first seen address and constant. Then in next pass it looks for all load pairs and tries to use post-increment on those loads. What often prevent it, are labels in between (then we could arrive here from more places possibly with unknown value of address register. This could be resolved by complete CFG analysis which gcc doesn't do just now - but I'd not expect to find much more of them. Also I see it as problem - before scheduling we don't know whether add or post-inc is better for scheduling - both is possible. > This is mostly the profile I expected from standard software. Note that > I compiled with `-O -fomit-frame-pointer'; otherwise, the result would WARNING: -fomit-frame-pointer produces sometimes addi with inwalid (out of range) imm. I'm not still sure why. > Another interesting fact is that 1/4 of the multiplications are actually > `mac' operations (most of them of the kind where all operands have the > same size). One can also observe that add, sub, xor and shift[lr] are well, mac is not yet supported - we have generaly problems with ^1 register addressing. > - reduce number of load/store instructions > - increase number of conditional moves (in favor of jmp{cc}) how ? it would probably help to manualy find places where movcc could be used and is not > - avoid shift-and-add where mul/mac is faster done. > - make use of divrem[s] instruction the same problem as with mac - but this one basicaly works for some cases. Unfortunately there is no much of such places wgere both rem & div is needed... > - make use of SIMD instructions in string ops .. well. for other, we can enable gcc to use vector modes explicitly but it works oonly with programs whose knows how to use them. gcc will not emit them itself. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 14 00:16:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YGWy-0001El-00 for ; Tue, 14 Jan 2003 03:10:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 03:10:20 +0100 (CET) Received: (qmail 14292 invoked by uid 0); 13 Jan 2003 23:16:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 13 Jan 2003 23:16:38 -0000 Received: by moria.seul.org (Postfix) id 4801833E5F; Mon, 13 Jan 2003 18:16:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9EEF33E61; Mon, 13 Jan 2003 18:16:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3D79733E5F for ; Mon, 13 Jan 2003 18:16:36 -0500 (EST) Received: from a95-137.dialup.iol.cz ([194.228.137.95] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18YDoo-0003WZ-00 for f-cpu@seul.org; Tue, 14 Jan 2003 00:16:34 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YDob-00030V-00 for f-cpu@seul.org; Tue, 14 Jan 2003 00:16:21 +0100 Date: Tue, 14 Jan 2003 00:16:21 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] gcc32fcpu_20030113 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N uploaded ... many interesting fixed, latest MR's SIMD support not yet integrated. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 14 00:48:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YGWz-0001El-00 for ; Tue, 14 Jan 2003 03:10:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 03:10:21 +0100 (CET) Received: (qmail 31818 invoked by uid 0); 13 Jan 2003 23:48:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 13 Jan 2003 23:48:49 -0000 Received: by moria.seul.org (Postfix) id C8F4C33E60; Mon, 13 Jan 2003 18:48:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4411633E62; Mon, 13 Jan 2003 18:48:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a094.home.uni-hannover.de [130.75.232.94]) by moria.seul.org (Postfix) with ESMTP id 4876733E60 for ; Mon, 13 Jan 2003 18:48:46 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA16228; Tue, 14 Jan 2003 00:48:44 +0100 Message-ID: <20030114004844.45400@thrai.stud.uni-hannover.de> Date: Tue, 14 Jan 2003 00:48:44 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030113000719.11954@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Jan 13, 2003 at 12:25:25PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Jan 13, 2003 at 12:25:25PM +0100, devik wrote: > > I compiled a set of C files (among them libelf and fctools) with fcpu-gcc > > and started to count instructions. The most often used single instruction > > was an ordinary unconditional `move': > > was was not it one with comment "zero_extend" ? Most of them will > be gone but we will have to duplicate almost ALL patterns > with implicit zero extend (as fcpu zeroextends automatically > as x86-64 from AMD does). There were 21178 unconditional moves (total), 9729 of them were zero extension operations - 45.9% [...] > > The vast majority of instructions are load/store, add/sub/loadaddr[i], > > yep ... gcc can't prefetch and "cache" data in registers too > early because of read-write ordering rules which can't be > resolved by aliasing analysis. It is why IA-64 has ld.a > instruction. There if flag which tells gcc to use "possibly > dangerous" early fetches - but it doesn't follow C standard then. It does. If the prefetched memory location has been modified when the real load follows, an exception is thrown and the exception handler is supposed to re-fetch the data. [...] > > This is mostly the profile I expected from standard software. Note that > > I compiled with `-O -fomit-frame-pointer'; otherwise, the result would > > WARNING: -fomit-frame-pointer produces sometimes addi with > inwalid (out of range) imm. I'm not still sure why. fcpu-as didn't complain so far (only for the loadcons[x] case). Which value did it produce? > > Another interesting fact is that 1/4 of the multiplications are actually > > `mac' operations (most of them of the kind where all operands have the > > same size). One can also observe that add, sub, xor and shift[lr] are > > well, mac is not yet supported - we have generaly problems > with ^1 register addressing. `mac' doesn't use a second output - it's 3r1w, not 2r2w. And it is supported by gcc now, in all variants :) > > - reduce number of load/store instructions > > - increase number of conditional moves (in favor of jmp{cc}) > > how ? it would probably help to manualy find places > where movcc could be used and is not I'll check my test files. [...] > > - make use of SIMD instructions > > in string ops .. well. for other, we can enable gcc to > use vector modes explicitly but it works oonly with > programs whose knows how to use them. gcc will not > emit them itself. Also done :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 14 07:21:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YQ4O-0000Dm-01 for ; Tue, 14 Jan 2003 13:21:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 13:21:28 +0100 (CET) Received: (qmail 8246 invoked by uid 0); 14 Jan 2003 09:43:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 14 Jan 2003 09:43:38 -0000 Received: by moria.seul.org (Postfix) id 528A033D8D; Tue, 14 Jan 2003 04:43:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 97A8A33E57; Tue, 14 Jan 2003 04:43:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 11BD533D8D for ; Tue, 14 Jan 2003 04:43:35 -0500 (EST) Received: from a23-137.dialup.iol.cz ([194.228.137.23] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18YNbX-0004i3-00 for f-cpu@seul.org; Tue, 14 Jan 2003 10:43:32 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YKRY-0000Au-00 for f-cpu@seul.org; Tue, 14 Jan 2003 07:21:00 +0100 Date: Tue, 14 Jan 2003 07:21:00 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Instruction census In-Reply-To: <20030114004844.45400@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > yep ... gcc can't prefetch and "cache" data in registers too > > early because of read-write ordering rules which can't be > > resolved by aliasing analysis. It is why IA-64 has ld.a > > instruction. There if flag which tells gcc to use "possibly > > dangerous" early fetches - but it doesn't follow C standard then. > > It does. If the prefetched memory location has been modified when the > real load follows, an exception is thrown and the exception handler is > supposed to re-fetch the data. you speak about IA-64 advanced load, aren't you ? I know it - you even don't need to use exception if the only way is to refetch data - you can use completion load which will reload register from memory if ALOAD association entry is missing. But I was speaking about -fsched-spec-load-dangerous which allows moves of loads even for CPUs without disambiguation support like F-CPU is - and then it is not strictly C-compliant (it does some assumtions on aliasing). > > WARNING: -fomit-frame-pointer produces sometimes addi with > > inwalid (out of range) imm. I'm not still sure why. > > fcpu-as didn't complain so far (only for the loadcons[x] case). Which > value did it produce? I tried to fix it in fcpu.c by means of fcpu_need_fp_p which should detect cases when we can't eliminate FP because elimination is done during reload when we can't change addi to loadcons+add. And when elimination distance between SP and FP is >127 then is is likely that addi $372,... is produced (because elimination substitution is not checked by recog then). I hope the fcpu_need_fp_p will catch all cases but my gcc friend told me to investigate IA64 port more - it handles the same case and maybe it is more inteligent. > > > Another interesting fact is that 1/4 of the multiplications are actually > > > `mac' operations (most of them of the kind where all operands have the > > > same size). One can also observe that add, sub, xor and shift[lr] are > > > > well, mac is not yet supported - we have generaly problems > > with ^1 register addressing. > > `mac' doesn't use a second output - it's 3r1w, not 2r2w. > And it is supported by gcc now, in all variants :) ohh :) good news ! I overlooked that r1 is both src and dst. BTW how will be it implemented in HW ? Did someone think about shadd like ia64 has ? I'd expect immediate form where immediate would tell you no of left shifts of one operand - it could be much faster than mac and seems to be used often in code .... Will have to check its usage. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Wed Jan 15 20:34:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YRxw-00020Q-00 for ; Tue, 14 Jan 2003 15:22:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 15:22:56 +0100 (CET) Received: (qmail 11504 invoked by uid 0); 14 Jan 2003 13:34:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 14 Jan 2003 13:34:12 -0000 Received: by moria.seul.org (Postfix) id A33BD33E68; Tue, 14 Jan 2003 08:34:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F145633E6C; Tue, 14 Jan 2003 08:34:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 80E7133E68 for ; Tue, 14 Jan 2003 08:34:10 -0500 (EST) Received: from 8.191.62.62.9massy1-1-ro-bas-1.9tel.net (8.191.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.191.8]) by smtp3.9tel.net (Postfix) with ESMTP id 810C45BE51 for ; Tue, 14 Jan 2003 14:34:09 +0100 (CET) From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Date: Wed, 15 Jan 2003 19:34:11 +0000 User-Agent: KMail/1.5 References: <20030113000719.11954@thrai.stud.uni-hannover.de> In-Reply-To: <20030113000719.11954@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301151934.11211.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, > 98104 instructions total > 13079 move 13.3% ( 13.3% total) > 10846 load 11.0% ( 24.3% total) > 3545 storei 3.6% ( 78.1% total) > 3533 loadi 3.6% ( 81.7% total) > 3459 store 3.5% ( 85.3% total) > 21383 lsu 21.7% ( 21.7% total) Did you use the new register allocator for this test ? I hope it will change a lot of result for RISC CPU, and perhaps it will remove some loadi/storei, but I don't know the impact for load/store (Did you have an idea why we have 3 time more load than store, but loadi and storei are very close) . > Goals for optimization (IMHO): > - reduce number of load/store instructions Perhaps it's more easy for loadi/storei, but I really want to know where all this load came from. > - increase number of conditional moves (in favor of jmp{cc}) > - avoid shift-and-add where mul/mac is faster Hum, what about a "mac"shift instruction ? > - make use of divrem[s] instruction > - make use of SIMD instructions I think that gcc support SIMD only for string function, it's really hard to give a real SIMD support to gcc. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 14 16:00:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YYT2-0006pi-00 for ; Tue, 14 Jan 2003 22:19:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 22:19:28 +0100 (CET) Received: (qmail 5084 invoked by uid 0); 14 Jan 2003 15:50:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 14 Jan 2003 15:50:51 -0000 Received: by moria.seul.org (Postfix) id C29A133D19; Tue, 14 Jan 2003 10:50:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D81A33DE9; Tue, 14 Jan 2003 10:50:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 0A37C33D19 for ; Tue, 14 Jan 2003 10:50:48 -0500 (EST) Received: from a109-137.dialup.iol.cz ([194.228.137.109] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18YTKo-00062Q-00 for f-cpu@seul.org; Tue, 14 Jan 2003 16:50:39 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YSYX-0000mK-00 for f-cpu@seul.org; Tue, 14 Jan 2003 16:00:45 +0100 Date: Tue, 14 Jan 2003 16:00:45 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Instruction census In-Reply-To: <200301151934.11211.cedric.bail@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > Did you use the new register allocator for this test ? I hope it will change > a lot of result for RISC CPU, and perhaps it will remove some loadi/storei, > but I don't know the impact for load/store (Did you have an idea why we have > 3 time more load than store, but loadi and storei are very close) . hmm - it is in 3.3 ? I wanted to wait for branch freeze before experimenting with it .. > > - make use of divrem[s] instruction > > - make use of SIMD instructions > > I think that gcc support SIMD only for string function, it's really hard to > give a real SIMD support to gcc. gcc has generic interface to simd stuff for user level programs. so the we should support it :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 14 15:16:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YYTs-0006pi-00 for ; Tue, 14 Jan 2003 22:20:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 22:20:20 +0100 (CET) Received: (qmail 5034 invoked by uid 0); 14 Jan 2003 17:26:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 14 Jan 2003 17:26:45 -0000 Received: by moria.seul.org (Postfix) id B4C8833E6E; Tue, 14 Jan 2003 12:26:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0996433E70; Tue, 14 Jan 2003 12:26:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a035.home.uni-hannover.de [130.75.232.35]) by moria.seul.org (Postfix) with ESMTP id 758FC33E6E for ; Tue, 14 Jan 2003 12:26:40 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00745; Tue, 14 Jan 2003 15:16:13 +0100 Message-ID: <20030114151612.20436@thrai.stud.uni-hannover.de> Date: Tue, 14 Jan 2003 15:16:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030114004844.45400@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Jan 14, 2003 at 07:21:00AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 14, 2003 at 07:21:00AM +0100, devik wrote: [...] > you speak about IA-64 advanced load, aren't you ? I know it - you > even don't need to use exception if the only way is to refetch > data - you can use completion load which will reload register > from memory if ALOAD association entry is missing. Didn't remember that one (it's been a while since I read the docs). > But I was speaking about -fsched-spec-load-dangerous which allows > moves of loads even for CPUs without disambiguation support > like F-CPU is - and then it is not strictly C-compliant (it does > some assumtions on aliasing). If the optimizer can prove that there's no aliasing that violates the rules of the ISO C standard, the optimization would be correct. By the way: If we implement load-linked/store-conditional, we may also implement speculative loads á la Itanium. The mechanism is the same: keep an eye on the memory location and set a flag when it's been stored into after the load. When the `completion load' finds the flag set, it re-fetches the data. We could handle that kind of things in the LSU. > > > WARNING: -fomit-frame-pointer produces sometimes addi with > > > inwalid (out of range) imm. I'm not still sure why. > > > > fcpu-as didn't complain so far (only for the loadcons[x] case). Which > > value did it produce? > > I tried to fix it in fcpu.c by means of fcpu_need_fp_p which should > detect cases when we can't eliminate FP because elimination is done > during reload when we can't change addi to loadcons+add. And when > elimination distance between SP and FP is >127 then is is likely that > addi $372,... is produced (because elimination substitution is > not checked by recog then). I've never seen that before (and fcpu-as would have detected it). [...] > > `mac' doesn't use a second output - it's 3r1w, not 2r2w. > > And it is supported by gcc now, in all variants :) > > ohh :) good news ! I overlooked that r1 is both src and dst. BTW how > will be it implemented in HW ? s/will be/is/ :) It's handled by the multiplier (see vhdl/eu_imu/). A `mac' will take the same time as the corresponding `mul' (3...6 cycles, depending on the chunk size). > Did someone think about shadd like ia64 has ? I'd expect immediate > form where immediate would tell you no of left shifts of one > operand - it could be much faster than mac and seems to be used > often in code .... Will have to check its usage. You mean, as in `r1 += r2 << uimm8' or something like that? That would require chaining of the SHL and ASU units. Therefore, it won't be cheaper than an explicit shiftli $uimm8, r2, r2 add r2, r1, r1 sequence. On top of that, EU chaining would make the IF/D hardware much more complex (you need to find free slots for both EUs!). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Wed Jan 15 20:47:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YYTx-0006pi-00 for ; Tue, 14 Jan 2003 22:20:25 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 22:20:25 +0100 (CET) Received: (qmail 25479 invoked by uid 0); 14 Jan 2003 18:50:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 14 Jan 2003 18:50:10 -0000 Received: by moria.seul.org (Postfix) id 3599C33E73; Tue, 14 Jan 2003 13:50:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6F78933E76; Tue, 14 Jan 2003 13:50:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id 1A41933E73 for ; Tue, 14 Jan 2003 13:50:05 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id EF3A562D03 for ; Tue, 14 Jan 2003 19:50:01 +0100 (CET) Date: Wed, 15 Jan 2003 19:47:42 +0000 From: Cyrano To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Message-Id: <20030115194742.17f20a2e.cyrano@nerim.net> In-Reply-To: References: <20030113000719.11954@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hum, i need some explanation to understand it all. On Mon, 13 Jan 2003 12:25:25 +0100 (CET) devik wrote: > > I compiled a set of C files (among them libelf and fctools) with > > fcpu-gcc and started to count instructions. The most often used > > single instruction was an ordinary unconditional `move': > > was was not it one with comment "zero_extend" ? Most of them will > be gone but we will have to duplicate almost ALL patterns > with implicit zero extend (as fcpu zeroextends automatically > as x86-64 from AMD does). > I'm trying to learn combiner to do it by changing its code > but it is not simple at all. > Fortunately one of czech core gcc developers devoted his time > to communicate with and help me. > > > The vast majority of instructions are load/store, > > add/sub/loadaddr[i], > > yep ... gcc can't prefetch and "cache" data in registers too > early because of read-write ordering rules which can't be > resolved by aliasing analysis. It is why IA-64 has ld.a > instruction. There if flag which tells gcc to use "possibly Could you explain what does ld.a ? What is the read-write ordering rules ? > dangerous" early fetches - but it doesn't follow C standard then. > The add/sub case: CSE generates all addresses as PLUS of > first seen address and constant. Then in next pass it looks > for all load pairs and tries to use post-increment on those > loads. What often prevent it, are labels in between (then we > could arrive here from more places possibly with unknown value > of address register. This could be resolved by complete CFG > analysis which gcc doesn't do just now - but I'd not expect > to find much more of them. Also I see it as problem - before > scheduling we don't know whether add or post-inc is better > for scheduling - both is possible. > > > This is mostly the profile I expected from standard software. Note > > that I compiled with `-O -fomit-frame-pointer'; otherwise, the > > result would > > WARNING: -fomit-frame-pointer produces sometimes addi with > inwalid (out of range) imm. I'm not still sure why. > > > Another interesting fact is that 1/4 of the multiplications are > > actually`mac' operations (most of them of the kind where all > > operands have the same size). One can also observe that add, sub, > > xor and shift[lr] are > > well, mac is not yet supported - we have generaly problems > with ^1 register addressing. > What kind of problem ? > > - reduce number of load/store instructions > > - increase number of conditional moves (in favor of jmp{cc}) > > how ? it would probably help to manualy find places > where movcc could be used and is not > > > - avoid shift-and-add where mul/mac is faster > > done. > > > - make use of divrem[s] instruction > > the same problem as with mac - but this one basicaly > works for some cases. Unfortunately there is no much > of such places wgere both rem & div is needed... > > > - make use of SIMD instructions > > in string ops .. well. for other, we can enable gcc to > use vector modes explicitly but it works oonly with > programs whose knows how to use them. gcc will not > emit them itself. > It's even impossible to detect "obvious" scheme ? (like C[i]=A[i]*B[i] or A+=V1[i]*V2[i] ?) > devik > Michael wrote : > By the way: If we implement load-linked/store-conditional, we may also > implement speculative loads á la Itanium. The mechanism is the same: > keep an eye on the memory location and set a flag when it's been > stored into after the load. When the `completion load' finds the flag > set, it re-fetches the data. We could handle that kind of things in > the LSU. (Be carfull on itanium patent !) I don't like too much load-linked/store-conditional because it's unusful in multi-core env. But in that case, you want to support such case to avoid gcc mistake on preloading (or prefetching) ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jan 14 20:37:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YYUh-0006pi-00 for ; Tue, 14 Jan 2003 22:21:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 22:21:11 +0100 (CET) Received: (qmail 17733 invoked by uid 0); 14 Jan 2003 19:37:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 14 Jan 2003 19:37:54 -0000 Received: by moria.seul.org (Postfix) id 7B43F33E78; Tue, 14 Jan 2003 14:37:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D233D33E76; Tue, 14 Jan 2003 14:37:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 3F9FF33E77 for ; Tue, 14 Jan 2003 14:37:17 -0500 (EST) Message-ID: <20030114193715.15494.qmail@web14206.mail.yahoo.com> Received: from [130.89.241.222] by web14206.mail.yahoo.com via HTTP; Tue, 14 Jan 2003 11:37:15 PST Date: Tue, 14 Jan 2003 11:37:15 -0800 (PST) From: jaap stolk Subject: [f-cpu] slashdot To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, there is an open source cpu thread on slashdot, but search for f-cpu returnd 0 results... "Transmeta to Incorporate DRM in TM5800 Processor" http://slashdot.org/articles/03/01/14/1719220.shtml?tid=161 can someone mention it ? jaap. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 14 22:18:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YZeD-0007g7-00 for ; Tue, 14 Jan 2003 23:35:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 23:35:05 +0100 (CET) Received: (qmail 22876 invoked by uid 0); 14 Jan 2003 21:20:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 14 Jan 2003 21:20:27 -0000 Received: by moria.seul.org (Postfix) id 9197133E77; Tue, 14 Jan 2003 16:20:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 140F233E79; Tue, 14 Jan 2003 16:20:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8ED1933E77 for ; Tue, 14 Jan 2003 16:20:17 -0500 (EST) Received: from a60-137.dialup.iol.cz ([194.228.137.60] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18YYTk-0006pm-00 for f-cpu@seul.org; Tue, 14 Jan 2003 22:20:13 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YYSZ-00013k-00 for f-cpu@seul.org; Tue, 14 Jan 2003 22:18:59 +0100 Date: Tue, 14 Jan 2003 22:18:59 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Instruction census In-Reply-To: <20030115194742.17f20a2e.cyrano@nerim.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > yep ... gcc can't prefetch and "cache" data in registers too > > early because of read-write ordering rules which can't be > > resolved by aliasing analysis. It is why IA-64 has ld.a > > instruction. There if flag which tells gcc to use "possibly > > Could you explain what does ld.a ? What is the read-write ordering rules > ? ld.a is so called advanced load of IA-64 which loads data from address and places the address into TLB like structure (with 64 entries for Itanium IIRC). Later completion load checks whether the item is still present, if yes, latter load in NOP. If no, the latter load reloads data. In C if you write *a =3D b; c =3D *d; you have to ensure RAW ordering of "a" store and "d" read because you don't often don't know whether they can alias (interestingly *a =3D b, c =3D *d; don't need to enforce it - it is paralel expression). IA64 can do advanced load before store and then do check load after store - it is often nop. If CPU would store to the same address it would remove store address from the disambiguation memory thus forces latter check-load to reload. The same effect has full disambiguation memory (old pointer dropped) or other CPU dirtying cache line of pointer. IA64 has also speculative load ld.s - its only difference is that it doesn't trap - if it would like trap it stores the condition in flag associated to the destination register. When such value would be used it would then really trap. Completion load can check the flag and jump to special stub code to handle it. It allows you to load *a in expression if (a) b =3D *a; without change of side effect. > > > > well, mac is not yet supported - we have generaly problems > > with ^1 register addressing. > > > What kind of problem ? MR explained me that MAC doesn't have that problem. But MUX has - there is no clean way to tell gcc that insn places result to register r^1 ... It can be done for divrem because it uses expander. But MUX will gave to be solved by 3-2 split point of gcc only because it consists of 3 RTL insns. > > use vector modes explicitly but it works oonly with > > programs whose knows how to use them. gcc will not > > emit them itself. > > > It's even impossible to detect "obvious" scheme ? (like C[i]=3DA[i]*B[i] > or A+=3DV1[i]*V2[i] ?) no. It requires vectorizer which is not present in gcc yet. But loop optimizer is planed to be rewritten and vectorizer will be probably added too. > > By the way: If we implement load-linked/store-conditional, we may also > > implement speculative loads =E1 la Itanium. The mechanism is the same: > > keep an eye on the memory location and set a flag when it's been > > stored into after the load. When the `completion load' finds the flag > > set, it re-fetches the data. We could handle that kind of things in > > the LSU. > > (Be carfull on itanium patent !) which one ? so I know what things don't thing about at all .. :-( BTW what is load-linked/store-conditional ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Jan 15 23:48:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YZeE-0007g7-01 for ; Tue, 14 Jan 2003 23:35:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Jan 2003 23:35:06 +0100 (CET) Received: (qmail 11496 invoked by uid 0); 14 Jan 2003 21:53:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 14 Jan 2003 21:53:07 -0000 Received: by moria.seul.org (Postfix) id 74F9333E76; Tue, 14 Jan 2003 16:52:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0CF9533E7C; Tue, 14 Jan 2003 16:51:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 316F133E7B for ; Tue, 14 Jan 2003 16:51:10 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id 5184C40E31 for ; Tue, 14 Jan 2003 22:38:46 +0100 (CET) Date: Wed, 15 Jan 2003 22:48:46 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Message-Id: <20030115224846.1b53c30d.nicolas.boulay@ifrance.com> In-Reply-To: References: <20030115194742.17f20a2e.cyrano@nerim.net> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 14 Jan 2003 22:18:59 +0100 (CET) devik wrote: > > > yep ... gcc can't prefetch and "cache" data in registers too > > > early because of read-write ordering rules which can't be > > > resolved by aliasing analysis. It is why IA-64 has ld.a > > > instruction. There if flag which tells gcc to use "possibly > > > > Could you explain what does ld.a ? What is the read-write ordering > > rules? > > ld.a is so called advanced load of IA-64 which loads data > from address and places the address into TLB like structure > (with 64 entries for Itanium IIRC). > Later completion load checks whether the item is still present, > if yes, latter load in NOP. If no, the latter load reloads > data. > In C if you write *a = b; c = *d; you have to ensure RAW > ordering of "a" store and "d" read because you don't often > don't know whether they can alias (interestingly > *a = b, c = *d; don't need to enforce it - it is paralel > expression). > IA64 can do advanced load before store and then do check > load after store - it is often nop. > If CPU would store to the same address it would remove > store address from the disambiguation memory thus forces > latter check-load to reload. > The same effect has full disambiguation memory (old pointer > dropped) or other CPU dirtying cache line of pointer. > > IA64 has also speculative load ld.s - its only difference is > that it doesn't trap - if it would like trap it stores the condition > in flag associated to the destination register. > When such value would be used it would then really trap. > Completion load can check the flag and jump to special stub > code to handle it. > It allows you to load *a in expression if (a) b = *a; without > change of side effect. > What is the différence between prefetch of x86 ? Is it the same difference between preload and prefetch ? Does not an L1 do the job ? > > > > > > well, mac is not yet supported - we have generaly problems > > > with ^1 register addressing. > > > > > What kind of problem ? > > MR explained me that MAC doesn't have that problem. But > MUX has - there is no clean way to tell gcc that insn > places result to register r^1 ... > It can be done for divrem because it uses expander. But > MUX will gave to be solved by 3-2 split point of gcc only > because it consists of 3 RTL insns. > i particulary hate the r^1 adressing :) Is that easier to define paired register ? It through aways some flexibility but could you say to gcc to consider register as extended one (writing the result in a double sized register like x86 mess). For a 2r2w, the write port will be R2-R3, R3-R2 is also true but could be avoided in a first time ? > > > use vector modes explicitly but it works oonly with > > > programs whose knows how to use them. gcc will not > > > emit them itself. > > > > > It's even impossible to detect "obvious" scheme ? (like > > C[i]=A[i]*B[i] or A+=V1[i]*V2[i] ?) > > no. It requires vectorizer which is not present in gcc yet. > But loop optimizer is planed to be rewritten and vectorizer > will be probably added too. > :( it seems so easy ! > > > By the way: If we implement load-linked/store-conditional, we may > > > also implement speculative loads á la Itanium. The mechanism is > > > the same: keep an eye on the memory location and set a flag when > > > it's been stored into after the load. When the `completion load' > > > finds the flag set, it re-fetches the data. We could handle that > > > kind of things in the LSU. > > > > (Be carfull on itanium patent !) > > which one ? so I know what things don't thing about at all .. :-( > arf. Itanium is a recent design so probably full of patent. All "inovation" in Itanium design is certainly soon patented. > BTW what is load-linked/store-conditional ? I don't think so or by an other chip maker. nicO > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 14 18:57:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ycv1-0001bN-01 for ; Wed, 15 Jan 2003 03:04:39 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 03:04:39 +0100 (CET) Received: (qmail 25433 invoked by uid 0); 14 Jan 2003 23:22:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 14 Jan 2003 23:22:18 -0000 Received: by moria.seul.org (Postfix) id C9C7433D00; Tue, 14 Jan 2003 18:22:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BCA9733E7B; Tue, 14 Jan 2003 18:22:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a053.home.uni-hannover.de [130.75.232.53]) by moria.seul.org (Postfix) with ESMTP id 640E333D00 for ; Tue, 14 Jan 2003 18:22:08 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00539; Tue, 14 Jan 2003 18:57:13 +0100 Message-ID: <20030114185713.15331@thrai.stud.uni-hannover.de> Date: Tue, 14 Jan 2003 18:57:13 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030113000719.11954@thrai.stud.uni-hannover.de> <200301151934.11211.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200301151934.11211.cedric.bail@free.fr>; from cedric on Wed, Jan 15, 2003 at 07:34:11PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 15, 2003 at 07:34:11PM +0000, cedric wrote: > > 98104 instructions total > > 13079 move 13.3% ( 13.3% total) > > 10846 load 11.0% ( 24.3% total) > > 3545 storei 3.6% ( 78.1% total) > > 3533 loadi 3.6% ( 81.7% total) > > 3459 store 3.5% ( 85.3% total) > > > 21383 lsu 21.7% ( 21.7% total) > > Did you use the new register allocator for this test ? I hope it will change > a lot of result for RISC CPU, and perhaps it will remove some loadi/storei, > but I don't know the impact for load/store (Did you have an idea why we have > 3 time more load than store, but loadi and storei are very close) . Which register allocator? Did I miss something? I used what Martin provided, plus my own bug fixes and backend extensions. > > Goals for optimization (IMHO): > > - reduce number of load/store instructions > > Perhaps it's more easy for loadi/storei, but I really want to know where all > this load came from. Most of it comes from the code itself; with -O -fomit-frame-pointer, save/restore instructions are reduced to a minimum. > > - increase number of conditional moves (in favor of jmp{cc}) > > - avoid shift-and-add where mul/mac is faster > > Hum, what about a "mac"shift instruction ? Martin proposed `shadd[i]' which calculates`r1 += r2 << r3_or_uimm8', or similar. But that is rather hard to do with separate SHL and ASU execution units, and won't be faster than explicit shift and add instructions. In fact, explicit instructions are more flexible. But an immediate version of `amac' would make sense, IMHO. I'll add one and see what happens. > > - make use of divrem[s] instruction > > - make use of SIMD instructions > > I think that gcc support SIMD only for string function, it's really hard to > give a real SIMD support to gcc. Gcc 3.x has real SIMD support, but you'll have to use builtin functions explicitly (or use the interface, where available). E.g. with my patched version of the latest official fcpu-gcc release, `fcpu-gcc -S -O -fomit-frame-pointer' translates /* use vecturs that consist of two floats */ typedef float __v2sf __attribute__((__mode__(__V2SF__))); __v2sf sfmac_f(__v2sf a, __v2sf b, __v2sf c) { return __builtin_addv2sf(a, __builtin_mulv2sf(b, c)); } into .p2align 5 .global sfmac_f sfmac_f: sfmac.32 r3,r2,r1 jmp r63 which is all you can expect. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 15 01:09:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Ycv3-0001bN-00 for ; Wed, 15 Jan 2003 03:04:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 03:04:41 +0100 (CET) Received: (qmail 309 invoked by uid 0); 15 Jan 2003 00:10:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 15 Jan 2003 00:10:00 -0000 Received: by moria.seul.org (Postfix) id B15B433E7B; Tue, 14 Jan 2003 19:09:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7D4FA33E7D; Tue, 14 Jan 2003 19:09:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a053.home.uni-hannover.de [130.75.232.53]) by moria.seul.org (Postfix) with ESMTP id 143F333E7B for ; Tue, 14 Jan 2003 19:09:50 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA09384; Wed, 15 Jan 2003 01:09:48 +0100 Message-ID: <20030115010948.04036@thrai.stud.uni-hannover.de> Date: Wed, 15 Jan 2003 01:09:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030115194742.17f20a2e.cyrano@nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Jan 14, 2003 at 10:18:59PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 14, 2003 at 10:18:59PM +0100, devik wrote: [...] > > > well, mac is not yet supported - we have generaly problems > > > with ^1 register addressing. > > > > > What kind of problem ? > > MR explained me that MAC doesn't have that problem. But > MUX has - there is no clean way to tell gcc that insn > places result to register r^1 ... In the emulator, I don't do that (result goes into r1, as with mac). The alternate register is only used when an instruction returns two values (like mulh, divrem, (f)addsub, dshift, sort and so on). > It can be done for divrem because it uses expander. But > MUX will gave to be solved by 3-2 split point of gcc only > because it consists of 3 RTL insns. You could write an expander for `ior' that checks the arguments and generates a `mux' if it finds the special case. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Wed Jan 15 18:20:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDI-0000Q5-00 for ; Wed, 15 Jan 2003 23:40:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:48 +0100 (CET) Received: (qmail 4263 invoked by uid 0); 15 Jan 2003 13:21:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 15 Jan 2003 13:21:47 -0000 Received: by moria.seul.org (Postfix) id 77DA633C96; Wed, 15 Jan 2003 08:21:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E176333DA7; Wed, 15 Jan 2003 08:21:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id 5EC4433C96 for ; Wed, 15 Jan 2003 08:21:45 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id C13FF62D08 for ; Wed, 15 Jan 2003 14:21:43 +0100 (CET) To: Subject: Re: [f-cpu] Instruction census From: Date: Wed, 15 Jan 2003 14:20:11 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030115132143.C13FF62D08@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Is it possible to count typical function call depth if it's possible and to count the number of argument of each function ? nicO Michael Riepe a écrit : > On Wed, Jan 15, 2003 at 07:34:11PM +0000, cedric wrote: > > > > 98104 instructions total > > > 13079 move 13.3% ( 13.3% total) > > > 10846 load 11.0% ( 24.3% total) > > > 3545 storei 3.6% ( 78.1% total) > > > 3533 loadi 3.6% ( 81.7% total) > > > 3459 store 3.5% ( 85.3% total) > > > > > 21383 lsu 21.7% ( 21.7% total) > > > > Did you use the new register allocator for this test ? I hope it will change > > > a lot of result for RISC CPU, and perhaps it will remove some loadi/storei, > > > but I don't know the impact for load/store (Did you have an idea why we have > > > 3 time more load than store, but loadi and storei are very close) . > > Which register allocator? Did I miss something? I used what Martin > provided, plus my own bug fixes and backend extensions. > > > > Goals for optimization (IMHO): > > > - reduce number of load/store instructions > > > > Perhaps it's more easy for loadi/storei, but I really want to know where all > > > this load came from. > > Most of it comes from the code itself; with -O -fomit-frame-pointer, > save/restore instructions are reduced to a minimum. > > > > - increase number of conditional moves (in favor of jmp{cc}) > > > - avoid shift-and-add where mul/mac is faster > > > > Hum, what about a "mac"shift instruction ? > > Martin proposed `shadd[i]' which calculates`r1 += r2 > or similar. But that is rather hard to do with separate SHL and ASU > execution units, and won't be faster than explicit shift and add > instructions. In fact, explicit instructions are more flexible. > But an immediate version of `amac' would make sense, IMHO. I'll add > one and see what happens. > > > > - make use of divrem[s] instruction > > > - make use of SIMD instructions > > > > I think that gcc support SIMD only for string function, it's really hard to > > > give a real SIMD support to gcc. > > Gcc 3.x has real SIMD support, but you'll have to use builtin functions > explicitly (or use the interface, where available). E.g. > with my patched version of the latest official fcpu-gcc release, > `fcpu-gcc -S -O -fomit-frame-pointer' translates > > /* use vecturs that consist of two floats */ > typedef float __v2sf __attribute__((__mode__(__V2SF__))); > > __v2sf > sfmac_f(__v2sf a, __v2sf b, __v2sf c) { > return __builtin_addv2sf(a, __builtin_mulv2sf(b, c)); > } > > into > > .p2align 5 > .global sfmac_f > sfmac_f: > sfmac.32 r3,r2,r1 > jmp r63 > > which is all you can expect. > > -- > Michael "Tired" Riepe &lang=fr">Michael.Riepe@stud.uni-hannover.de> > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 15 13:44:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDJ-0000Q5-00 for ; Wed, 15 Jan 2003 23:40:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:49 +0100 (CET) Received: (qmail 9187 invoked by uid 0); 15 Jan 2003 14:02:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 15 Jan 2003 14:02:43 -0000 Received: by moria.seul.org (Postfix) id 8E26B33D98; Wed, 15 Jan 2003 09:02:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D93DA33E4B; Wed, 15 Jan 2003 09:02:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D79BE33D98 for ; Wed, 15 Jan 2003 09:02:40 -0500 (EST) Received: from a30-137.dialup.iol.cz ([194.228.137.30] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Yo7p-0008Uv-00 for f-cpu@seul.org; Wed, 15 Jan 2003 15:02:38 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18Ymu8-0000DU-00 for f-cpu@seul.org; Wed, 15 Jan 2003 13:44:24 +0100 Date: Wed, 15 Jan 2003 13:44:24 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] 4w1r register file Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, please I I'd need 4w1r (8w1r) file with 4 registers, how complex is it ? I'd do one bit as (sel0 & w0)|(sel1 & w1)|...(selN & Q) in D input of FF. I know selX values ahead .. It seems as 1 2port ANDs followed by 5 or 9 port OR and then FF. I'm wondering whether such regfile write port would be within 6gates and allow multi-GHz clocking .. :-) devik PS: for curious, I just got idea for simple and interesting 4/8 way superscalar design .. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 15 10:37:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDJ-0000Q5-01 for ; Wed, 15 Jan 2003 23:40:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:49 +0100 (CET) Received: (qmail 8577 invoked by uid 0); 15 Jan 2003 14:02:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 15 Jan 2003 14:02:56 -0000 Received: by moria.seul.org (Postfix) id A443B33E48; Wed, 15 Jan 2003 09:02:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1B62033E6F; Wed, 15 Jan 2003 09:02:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 42F3133E48 for ; Wed, 15 Jan 2003 09:02:54 -0500 (EST) Received: from a30-137.dialup.iol.cz ([194.228.137.30] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Yo81-0008Uv-00 for f-cpu@seul.org; Wed, 15 Jan 2003 15:02:50 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YjzI-0000Bs-00 for f-cpu@seul.org; Wed, 15 Jan 2003 10:37:32 +0100 Date: Wed, 15 Jan 2003 10:37:32 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Instruction census In-Reply-To: <20030115224846.1b53c30d.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > that it doesn't trap - if it would like trap it stores the condition > > in flag associated to the destination register. > > When such value would be used it would then really trap. > > Completion load can check the flag and jump to special stub > > code to handle it. > > It allows you to load *a in expression if (a) b =3D *a; without > > change of side effect. > > > > What is the diff=E9rence between prefetch of x86 ? Is it the same > difference between preload and prefetch ? Does not an L1 do the job ? ld.a loads it into register. With prefetch you still have to to L1->reg move which costs at least one cycle. Because Itanium is 6-issue then 1 cycle is way too much because it often make part of program twice slower. The trick is that you can do: // cycle 0 ld.a r1 =3D [r4] st [r5] =3D r3 // cycle 1 ld.c r1 =3D [r4] // if this has to reload, other cycle is included after it not r2 =3D r1 without it you have to do: // cycle 0 st [r5] =3D r3 // cycle 1 ld r1 =3D [r4] // cycle 2 not r2 =3D r1 ld.a and ld.s are ways to find more ILP needed for 6issue CPU. > i particulary hate the r^1 adressing :) Is that easier to define paired > register ? It through aways some flexibility but could you say to gcc to > consider register as extended one (writing the result in a double sized > register like x86 mess). For a 2r2w, the write port will be R2-R3, R3-R2 > is also true but could be avoided in a first time ? the paired reg has the same problem unless it is used within expander. combiner has problems with it unfortunately. > > > C[i]=3DA[i]*B[i] or A+=3DV1[i]*V2[i] ?) > > > > no. It requires vectorizer which is not present in gcc yet. > > But loop optimizer is planed to be rewritten and vectorizer > > will be probably added too. > > > :( it seems so easy ! try to change loop.c in gcc. It might be possible to do it once gcc detects all BIV and GIVs you can detect code like A[GIV]=3DB[GIV] OP C[GIV] and modulo expand it during unrolling. > > > (Be carfull on itanium patent !) > > > > which one ? so I know what things don't thing about at all .. :-( > > > arf. Itanium is a recent design so probably full of patent. All > "inovation" in Itanium design is certainly soon patented. ahh I thought you mean concrete patent - ld.a and ld.s are used by other cpu like Alpha only not explicitly - Intel might patent its explicit use IMHO. > > BTW what is load-linked/store-conditional ? > I don't think so or by an other chip maker. you misunderstood the question, I asked WHAT is load-linked/store-conditional .. I don't know the name. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 15 10:27:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDK-0000Q5-00 for ; Wed, 15 Jan 2003 23:40:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:50 +0100 (CET) Received: (qmail 23993 invoked by uid 0); 15 Jan 2003 14:02:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 15 Jan 2003 14:02:59 -0000 Received: by moria.seul.org (Postfix) id 540AA33E75; Wed, 15 Jan 2003 09:02:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7F75833E7A; Wed, 15 Jan 2003 09:02:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id CA07233E6F for ; Wed, 15 Jan 2003 09:02:56 -0500 (EST) Received: from a30-137.dialup.iol.cz ([194.228.137.30] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18Yo84-0008Uv-00 for f-cpu@seul.org; Wed, 15 Jan 2003 15:02:53 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18YjpD-0000Bo-00 for f-cpu@seul.org; Wed, 15 Jan 2003 10:27:07 +0100 Date: Wed, 15 Jan 2003 10:27:06 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Instruction census In-Reply-To: <20030115010948.04036@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > MUX has - there is no clean way to tell gcc that insn > > places result to register r^1 ... > > In the emulator, I don't do that (result goes into r1, as with mac). > The alternate register is only used when an instruction returns two > values (like mulh, divrem, (f)addsub, dshift, sort and so on). good news. > > It can be done for divrem because it uses expander. But > > MUX will gave to be solved by 3-2 split point of gcc only > > because it consists of 3 RTL insns. > > You could write an expander for `ior' that checks the arguments and > generates a `mux' if it finds the special case. hmm ior is handed with constants or registers or memory to expander. There is no "legal and realiable" way to see its arguments ... But splitter does the job for this concrete one. For others I'd really like combine.c to be able to have hook in insn to specify actions to do after combiner matched pair. Then we could inject (subreg:DI (reg:TI) 8) to address r+1 register... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Wed Jan 15 16:53:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDN-0000Q5-00 for ; Wed, 15 Jan 2003 23:40:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:53 +0100 (CET) Received: (qmail 12346 invoked by uid 0); 15 Jan 2003 15:44:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 15 Jan 2003 15:44:31 -0000 Received: by moria.seul.org (Postfix) id DB45733CBD; Wed, 15 Jan 2003 10:44:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5EE4F33DA7; Wed, 15 Jan 2003 10:44:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf23bis.bellsouth.net (mail225.mail.bellsouth.net [205.152.58.195]) by moria.seul.org (Postfix) with ESMTP id 47FC233CBD for ; Wed, 15 Jan 2003 10:44:28 -0500 (EST) Received: from computer ([208.60.244.55]) by imf23bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030115154621.HBJN81.imf23bis.bellsouth.net@computer> for ; Wed, 15 Jan 2003 10:46:21 -0500 Message-ID: <000801c2bcae$4e57bf20$37f43cd0@computer> From: "richard hartny" To: Subject: [f-cpu] Instruction Mix Date: Wed, 15 Jan 2003 09:53:53 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2BC7C.0304AD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2BC7C.0304AD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Guys: I see you are playing with Instruction Mix. Based on real world = software: the TIPS operating system that I am using consists of 9976 = Instructions. I use the following instruction mix for defining my = Processor - the ALP76 - ERIN64 ARITH/LOGIC 45% LOAD 26% STORE 9% SHIFT 4% CONDITIONAL BRANCH 16% A manual count of the Instructions shows the percentage is = approximately correct. Regards Richard Hartney Research Director Erin Greene & Associates ------=_NextPart_000_0005_01C2BC7C.0304AD80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Guys:
 
    I see you are = playing with=20 Instruction Mix.  Based on real world software: the TIPS operating = system=20 that I am using consists of 9976 Instructions. I=20 use the following instruction mix for defining my Processor - the ALP76 = -=20 ERIN64
 
       =20     ARITH/LOGIC      =20             = 45%
       =20     LOAD        =    =20           =20        26%
       =20    =20 STORE           &n= bsp;           &nb= sp;      9%
       =20    =20 SHIFT           &n= bsp;      =20              = 4%
          &nbs= p;=20 CONDITIONAL BRANCH    16%
    A manual count of = the=20 Instructions shows the percentage is approximately correct.
 
Regards
Richard Hartney
Research Director
Erin Greene &=20 Associates
------=_NextPart_000_0005_01C2BC7C.0304AD80-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jan 16 21:35:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDT-0000Q5-00 for ; Wed, 15 Jan 2003 23:40:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:40:59 +0100 (CET) Received: (qmail 26100 invoked by uid 0); 15 Jan 2003 19:37:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 15 Jan 2003 19:37:54 -0000 Received: by moria.seul.org (Postfix) id C230133D42; Wed, 15 Jan 2003 14:37:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA5AE33DAF; Wed, 15 Jan 2003 14:37:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 2BDE533D42 for ; Wed, 15 Jan 2003 14:37:51 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id C69E940FD8 for ; Wed, 15 Jan 2003 20:25:25 +0100 (CET) Date: Thu, 16 Jan 2003 20:35:30 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Message-Id: <20030116203530.4680dac1.nicolas.boulay@ifrance.com> In-Reply-To: References: <20030115224846.1b53c30d.nicolas.boulay@ifrance.com> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 15 Jan 2003 10:37:32 +0100 (CET) devik wrote: <...> > > > BTW what is load-linked/store-conditional ? > > I don't think so or by an other chip maker. > > you misunderstood the question, I asked WHAT is > load-linked/store-conditional .. I don't know the name. > It's a technic to "simulate" read-modify-write on a monocpu computer. It work like you're ld.a ld.s. but the second instruction is a store. The store failed if the adresse is changed or if a trap occure or something like that. > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Jan 15 21:07:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwDU-0000Q5-00 for ; Wed, 15 Jan 2003 23:41:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:41:00 +0100 (CET) Received: (qmail 23013 invoked by uid 0); 15 Jan 2003 20:14:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 15 Jan 2003 20:14:08 -0000 Received: by moria.seul.org (Postfix) id 8AEC133D7F; Wed, 15 Jan 2003 15:14:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 217BA33DA8; Wed, 15 Jan 2003 15:14:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp.laposte.net (unknown [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 809B633D7F for ; Wed, 15 Jan 2003 15:14:06 -0500 (EST) Received: from homeworld (80.15.61.157) by smtp.laposte.net (6.0.053) id 3DF927E5003D5661 for f-cpu@seul.org; Wed, 15 Jan 2003 21:14:05 +0100 Message-ID: <00c301c2bcd1$bb0292d0$0100a8c0@homeworld> From: "Christophe Avoinne" To: References: Subject: Re: [f-cpu] Instruction census Date: Wed, 15 Jan 2003 21:07:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N load-linked/store-conditional : instructions ll/sc that you can find in MIPS I think. The main idea is to have a store that only occurs if we know there is no store since the last load linked was called at the same memory place. To emulate an IA32 XADD : int XADD (int *slot,int delta) { int old,new,stored; do { asm ("ll %0,[%1]" : "=r"(old) : "m"(slot)); new = old + delta; asm ("sc %0,[%2],%1" : "=r"(new), "=r"(stored) : "m"(slot)); } while (!stored); return old; } here I choose the format "SC R1,[R2],R3" where R1 is new data to store at address [R2] if that address was not dirty by a previous normal store or a store conditional (R3 is not 0 if stored really occured). Another emulation, IA32 CMPCHG : int CMPCHG (int *slot,int *old,int new) { int value,stored; asm ("ll %0,[%1]" : "=r"(value) : "m"(slot)); if (value != old) { *old = value; return 0; } asm ("sc %0,[%2],%1" : "=r"(new), "=r"(stored) : "m"(slot)); if (!stored) { *old = value; return 0; } return !0; } ----- Original Message ----- From: "devik" To: Sent: Wednesday, January 15, 2003 10:37 AM Subject: Re: [f-cpu] Instruction census > > BTW what is load-linked/store-conditional ? > I don't think so or by an other chip maker. you misunderstood the question, I asked WHAT is load-linked/store-conditional .. I don't know the name. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Jan 16 22:22:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18YwEF-0000Q5-00 for ; Wed, 15 Jan 2003 23:41:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Jan 2003 23:41:47 +0100 (CET) Received: (qmail 12759 invoked by uid 0); 15 Jan 2003 20:24:46 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 15 Jan 2003 20:24:46 -0000 Received: by moria.seul.org (Postfix) id 35A8033DA7; Wed, 15 Jan 2003 15:24:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAA1133DAC; Wed, 15 Jan 2003 15:24:44 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id 6301333DA7 for ; Wed, 15 Jan 2003 15:24:44 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id AB5E840F93 for ; Wed, 15 Jan 2003 21:12:18 +0100 (CET) Date: Thu, 16 Jan 2003 21:22:23 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census Message-Id: <20030116212223.0074c483.nicolas.boulay@ifrance.com> In-Reply-To: <00c301c2bcd1$bb0292d0$0100a8c0@homeworld> References: <00c301c2bcd1$bb0292d0$0100a8c0@homeworld> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Juste to add some drawback - the number of following ll are fixed (maybe one is most of the time enough) - It can't be used with multi-core design ! read-modify-write cycle must be a bus feature. nicO On Wed, 15 Jan 2003 21:07:27 +0100 "Christophe Avoinne" wrote: > load-linked/store-conditional : > > instructions ll/sc that you can find in MIPS I think. > > The main idea is to have a store that only occurs if we know there is > no store since the last load linked was called at the same memory > place. > > To emulate an IA32 XADD : > > int XADD (int *slot,int delta) { > int old,new,stored; > do { > asm ("ll %0,[%1]" : "=r"(old) : "m"(slot)); > new = old + delta; > asm ("sc %0,[%2],%1" : "=r"(new), "=r"(stored) : "m"(slot)); > } while (!stored); > return old; > } > here I choose the format "SC R1,[R2],R3" where R1 is new data to store > at address [R2] if that address was not dirty by a previous normal > store or a store conditional (R3 is not 0 if stored really occured). > > Another emulation, IA32 CMPCHG : > > int CMPCHG (int *slot,int *old,int new) { > int value,stored; > > asm ("ll %0,[%1]" : "=r"(value) : "m"(slot)); > if (value != old) { > *old = value; > return 0; > } > asm ("sc %0,[%2],%1" : "=r"(new), "=r"(stored) : "m"(slot)); > if (!stored) { > *old = value; > return 0; > } > return !0; > } > > ----- Original Message ----- > From: "devik" > To: > Sent: Wednesday, January 15, 2003 10:37 AM > Subject: Re: [f-cpu] Instruction census > > > > > > BTW what is load-linked/store-conditional ? > > I don't think so or by an other chip maker. > > you misunderstood the question, I asked WHAT is > load-linked/store-conditional .. I don't know the name. > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 15 22:47:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Z5Rt-0006wu-00 for ; Thu, 16 Jan 2003 09:32:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 09:32:29 +0100 (CET) Received: (qmail 3861 invoked by uid 0); 15 Jan 2003 22:46:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 15 Jan 2003 22:46:10 -0000 Received: by moria.seul.org (Postfix) id 8C80033C91; Wed, 15 Jan 2003 17:46:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8669D33DAC; Wed, 15 Jan 2003 17:45:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a132.home.uni-hannover.de [130.75.232.132]) by moria.seul.org (Postfix) with ESMTP id 7279E33C91 for ; Wed, 15 Jan 2003 17:45:56 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA01973; Wed, 15 Jan 2003 22:47:32 +0100 Message-ID: <20030115224732.30746@thrai.stud.uni-hannover.de> Date: Wed, 15 Jan 2003 22:47:32 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Stack Frame Layout and Varargs Handling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N It's time to specify argument passing and the like in more detail... To summarize: r1...r15 hold the first 15 arguments, the rest is pushed on the stack (downward), with the stack pointer (r62) pointing to argument #16 when the function is entered. Note that r1 need not hold the real first argument but may be a `hidden' argument - a pointer to a buffer that is used to return a struct, for example -, with the real first argument following in r2. Values (including structs and unions) that fit in 8 bytes shall be passed in a register. Larger data that is not declared `const' shall be copied to a temporary location in memory, and the address of the copy shall be passed to the function. Large data that is declared `const' in the function prototype shall be passed by reference, to avoid copying. Arguments passed on the stack shall always occupy 8 bytes, to preserve alignment of the stack pointer. Return values are handled similarly: If they fit into 8 bytes, they shall be returned in r1. Larger structs and unions shall be returned in a temporary memory location that is allocated by the caller, and passed by reference in a hidden argument (that is, in r1). On return, r1 shall hold the address of the result. A `varargs' function (one that accepts a variable number of arguments) which has less than 15 `fixed' (that is, explicitly named) arguments shall push all unnamed arguments that were passed in registers to the stack before it calls the va_start() macro for the first time. The additional pushed arguments shall form a contiguous array with the arguments pushed by the caller, if any. E.g. the function #include int snprintf(char *str, size_t size, const char *format, ...) { va_list ap; ... va_start(ap, format); ... va_end(); } shall push r4...r15 to the stack before it executes va_start(). `ap' will most likely be a pointer to the argument array on the stack. When the function returns, it shall deallocate the memory area used for unnamed arguments, discarding their contents (ideally, it will be part of the function's stack frame). Other arguments on the stack shall be deallocated by the caller (see the discussion of the `scratch space' below for a simple solution). Note that the function need not save the `unnamed argument' registers immediately when it is entered. It can also reserve space for them and store them later, before it calls va_start() for the first time. If it doesn't call va_start() at all, it need not save anything. Remember that functions only have to obey these rules if (a) they have external linkage or (b) their address is passed around as a pointer. Private functions (those that can only be called from within the same source file) may use any calling convention that seems suitable - if they aren't inlined anyway. === Implementation Example === The stack frame of a function may look as follows (shown from highest address to lowest): // caller-pushed args go here stack_pointer_at_function_entry: .space 8 * number_of_unnamed_args_saved // for varargs functions only address_of_varargs_array: .space 8 * number_of_callee_saved_regs // including frame pointer, if needed frame_pointer_after_epilogue: // if needed .space space_for_local_variables // if needed // dynamically allocated locals go here (for alloca()) .space number_of_scratch_bytes // if needed stack_pointer_after_epilogue: The `scratch space' provides space for arguments to other functions, return value buffers and the like. It should be large enough for all possible calls, so that the stack pointer need not move during execution of the function unless alloca() is called. alloca() may then be implemented as alloca: addi $7,r1,r1 // align andni $7,r1,r1 sub r1,r62,r62 // allocate addi $number_of_scratch_bytes,r62,r1 // return value jmp r63 (it may also be inlined, of course). Note that the contents of the scratch space are clobbered by the call - but that will be true for all functions, since they may modify their arguments. A typical, simple function prologue may look like this: subi $8*number_of_unnamed_args_saved+8,r62,r62 // at most 68 bytes storei $-8,r62,r61 // save frame pointer // save callee-saved register(s) ... storei $-8 r62,r34 storei $-8 r62,r33 storei $-8,r62,r32 // save return address and allocate space for locals loadconsx $-(space_for_local_variables+number_of_scratch_bytes),r16 move r62,r61 // set new frame pointer store r16,r62,r63 // use storei if constant is small enough and the matching epilogue would be: move r61,r62 // deallocate locals and scratch loadi $8,r62,r63 // restore return address loadi $8,r62,r32 // restore callee-saved register(s) loadi $8,r62,r33 loadi $8,r62,r34 ... // restore frame pointer and return loadi $8*number_of_unnamed_args_saved+8,r62,r61 jmp r63 This is suboptimal, however. There are read-after-write dependencies between the individual loadi (or storei) instructions which will cause the CPU to stall for 2 cycles (due to the repeated use of r62). It's faster to use three pointers in a round-robin fashion: // arrange pointers so that temporary pointers are used first subi $8*number_of_unnamed_args_saved+8,r62,r16 subi $8*number_of_unnamed_args_saved+16,r62,r17 subi $8*number_of_unnamed_args_saved+24,r62,r62 storei $-24,r16,r61 storei $-24,r17,r34 storei $-24,r62,r33 storei $-24,r16,r32 loadconsx $space_for_local_variables+number_of_scratch_bytes,r18 move r17,r61 store r17,r63 sub r18,r17,r62 // use subi if constant is small enough // function code goes here // arrange pointers so that r62 is used in last loadi move r61,r17 addi $8,r61,r62 addi $16,r61,r16 loadi $24,r17,r63 loadi $24,r62,r32 loadi $24,r16,r33 loadi $24,r17,r34 loadi $8*number_of_unnamed_args_saved+8,r62,r61 jmp r63 Of course this kind of code is harder to generate. But it's worth the effort if there are several registers to save: you need 4...5 additional instructions, but you'll also save 4 cycles per register that is saved and restored (provided that the save/restore area is prefetched). Varargs registers can be stored in a similar fashion. For `snprintf' above which has 3 named parameters, the code may look like this: addi $8*number_of_callee_saved_regs,r61,r16 addi $8*number_of_callee_saved_regs+8,r61,r17 addi $8*number_of_callee_saved_regs+16,r61,r18 storei $24,r16,r4 storei $24,r17,r5 storei $24,r18,r6 storei $24,r16,r7 storei $24,r17,r8 storei $24,r18,r9 storei $24,r16,r10 storei $24,r17,r11 storei $24,r18,r12 store r16,r13 store r17,r14 store r18,r15 va_start() will be a macro or inline function that calculates the value of `r61 + 8 * number_of_callee_saved_regs' and stores it in `ap': The rest of can be implemented as follows: typedef void **va_list; #define va_arg(ap, type) (*(type*)(sizeof(type) <= 8 ? (ap)++ : *(ap)++)) #define va_copy(dst, src) ((void)((dst) = (src))) #define va_end(ap) ((void)0) (or similar). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 16 00:00:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Z5Ru-0006wu-01 for ; Thu, 16 Jan 2003 09:32:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 09:32:30 +0100 (CET) Received: (qmail 31278 invoked by uid 0); 15 Jan 2003 23:00:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 15 Jan 2003 23:00:06 -0000 Received: by moria.seul.org (Postfix) id 2913D33C8B; Wed, 15 Jan 2003 18:00:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B00E433D87; Wed, 15 Jan 2003 18:00:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a132.home.uni-hannover.de [130.75.232.132]) by moria.seul.org (Postfix) with ESMTP id 393A533C8B for ; Wed, 15 Jan 2003 18:00:03 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA04591; Thu, 16 Jan 2003 00:00:07 +0100 Message-ID: <20030116000007.11847@thrai.stud.uni-hannover.de> Date: Thu, 16 Jan 2003 00:00:07 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Instruction census References: <20030115132143.C13FF62D08@mallaury.noc.nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030115132143.C13FF62D08@mallaury.noc.nerim.net>; from cyrano@nerim.net on Wed, Jan 15, 2003 at 02:20:11PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 15, 2003 at 02:20:11PM +0100, cyrano@nerim.net wrote: > Is it possible to count typical function call depth if it's possible and to count the number of argument of each function ? Of course. But I have no tools for it... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 16 00:40:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Z5Rx-0006wu-00 for ; Thu, 16 Jan 2003 09:32:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 09:32:33 +0100 (CET) Received: (qmail 12968 invoked by uid 0); 15 Jan 2003 23:25:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 15 Jan 2003 23:25:29 -0000 Received: by moria.seul.org (Postfix) id 668F133D81; Wed, 15 Jan 2003 18:25:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA6D433DA8; Wed, 15 Jan 2003 18:25:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 26BFF33D81 for ; Wed, 15 Jan 2003 18:25:27 -0500 (EST) Received: from f-cpu.org (lcbv3-1-27.n.club-internet.fr [213.44.91.27]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 240C91695 for ; Thu, 16 Jan 2003 00:24:45 +0100 (CET) Message-ID: <3E25F17F.1050806@f-cpu.org> Date: Thu, 16 Jan 2003 00:40:47 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack Frame Layout and Varargs Handling References: <20030115224732.30746@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hello, Michael Riepe wrote: >It's time to specify argument passing and the like in more detail... > > i have read it, though not extremely carefully, but i have found no flaw. your text is ok for me. BTW, has anybody read the slides from 19C3 ? you can find it from f-cpu.seul.org/daCode YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Fri Jan 17 01:48:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Z5Ry-0006wu-00 for ; Thu, 16 Jan 2003 09:32:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 09:32:34 +0100 (CET) Received: (qmail 23266 invoked by uid 0); 15 Jan 2003 23:51:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 15 Jan 2003 23:51:03 -0000 Received: by moria.seul.org (Postfix) id 3BB5B33D82; Wed, 15 Jan 2003 18:51:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8317233DA8; Wed, 15 Jan 2003 18:51:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id DBD0933D82 for ; Wed, 15 Jan 2003 18:51:00 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id D302C40E2C for ; Thu, 16 Jan 2003 00:38:34 +0100 (CET) Date: Fri, 17 Jan 2003 00:48:39 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Stack Frame Layout and Varargs Handling Message-Id: <20030117004839.22dcee2f.nicolas.boulay@ifrance.com> In-Reply-To: <3E25F17F.1050806@f-cpu.org> References: <20030115224732.30746@thrai.stud.uni-hannover.de> <3E25F17F.1050806@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, 16 Jan 2003 00:40:47 +0100 Yann Guidon wrote: > hello, > > Michael Riepe wrote: > > >It's time to specify argument passing and the like in more detail... > > > > > i have read it, though not extremely carefully, but i have found no > flaw. your text is ok for me. > > BTW, has anybody read the slides from 19C3 ? > you can find it from f-cpu.seul.org/daCode Have you receive any feed back from the conf ? nicO > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 16 01:15:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18Z5Ry-0006wu-01 for ; Thu, 16 Jan 2003 09:32:34 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 09:32:34 +0100 (CET) Received: (qmail 21880 invoked by uid 0); 16 Jan 2003 00:00:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 16 Jan 2003 00:00:10 -0000 Received: by moria.seul.org (Postfix) id D10CA33DA9; Wed, 15 Jan 2003 19:00:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73EB133DAB; Wed, 15 Jan 2003 19:00:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 00B5B33DA9 for ; Wed, 15 Jan 2003 19:00:08 -0500 (EST) Received: from f-cpu.org (lcbv3-1-19.n.club-internet.fr [213.44.91.19]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 763F21691 for ; Thu, 16 Jan 2003 00:59:23 +0100 (CET) Message-ID: <3E25F99E.8090005@f-cpu.org> Date: Thu, 16 Jan 2003 01:15:26 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Stack Frame Layout and Varargs Handling References: <20030115224732.30746@thrai.stud.uni-hannover.de> <3E25F17F.1050806@f-cpu.org> <20030117004839.22dcee2f.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Thu, 16 Jan 2003 00:40:47 +0100 >Yann Guidon wrote: > > >>BTW, has anybody read the slides from 19C3 ? >>you can find it from f-cpu.seul.org/daCode >> >> >Have you receive any feed back from the conf ? > > not yet. >nicO > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 16 15:26:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ZF7W-0000GR-00 for ; Thu, 16 Jan 2003 19:52:06 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 16 Jan 2003 19:52:06 +0100 (CET) Received: (qmail 29491 invoked by uid 0); 16 Jan 2003 14:29:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 16 Jan 2003 14:29:17 -0000 Received: by moria.seul.org (Postfix) id 98A6533DB5; Thu, 16 Jan 2003 09:29:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F08233DB4; Thu, 16 Jan 2003 09:29:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id A9D2933DAC for ; Thu, 16 Jan 2003 09:29:14 -0500 (EST) Received: from a60-137.dialup.iol.cz ([194.228.137.60] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18ZB14-000576-00 for f-cpu@seul.org; Thu, 16 Jan 2003 15:29:11 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18ZAyL-00020D-00 for f-cpu@seul.org; Thu, 16 Jan 2003 15:26:21 +0100 Date: Thu, 16 Jan 2003 15:26:21 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] gcc stats for fcpu vs. itanium Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N the same file, fcpu: total insns: 33940 Labels: 2533, JMP: 2919, Conditional jumps: 3677, loadaddr: 4205 Simple L/S: 6279, post-update L/S: 1258, imm-offsets: Arithm/cmp with immediate: 4848 SHADD: 511 MAC: Move: 3868 Movcc: 45 Itanium: total insns: 26109 Itanium: grps: 10129 gr[0]: 182 0 gr[1]: 3911 3911 gr[2]: 2087 4174 gr[3]: 1484 4452 gr[4]: 1084 4336 gr[5]: 618 3090 gr[6]: 380 2280 gr[7]: 175 1225 gr[8]: 101 808 gr[9]: 37 333 Labels: 2121, JMP: 1399, Conditional jumps: 2653, loadaddr: Simple L/S: 4614, post-update L/S: 14, imm-offsets: Arithm/cmp: 4704 Move: 4812 Movcc: 2027 gr[n] is histogram of number of n insn groups eligible to be issued in parallel. The number after them is grp_count * n. In Movcc are all predicated nonjumps. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From joeudah15@latinmail.com Fri Jan 17 14:05:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ZbIq-0007fG-01 for ; Fri, 17 Jan 2003 19:33:16 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 17 Jan 2003 19:33:16 +0100 (CET) Received: (qmail 9535 invoked by uid 0); 17 Jan 2003 13:06:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 17 Jan 2003 13:06:02 -0000 Received: by moria.seul.org (Postfix) id 7EC0D33DB9; Fri, 17 Jan 2003 08:06:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9F37733DBD; Fri, 17 Jan 2003 08:06:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id BF34433DB9 for ; Fri, 17 Jan 2003 08:05:59 -0500 (EST) Received: from qfgf93931.com ([80.179.100.50]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h0HD5iP08312 for ; Fri, 17 Jan 2003 08:05:50 -0500 Message-Id: <200301171305.h0HD5iP08312@belegost.mit.edu> From: "ENGR. JOE UDAH" To: f-cpu@seul.org Date: Fri, 17 Jan 2003 13:05:55 +0000 Subject: [f-cpu] JOINT VENTURE X-Priority: 5 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N DEPARTMENT OF PETROLEUM RESOURCES PLOT 225 KOFO ABAYOMI STREET VICTORIA ISLAND=2CLAGOS=2C NIGERIA=2E DIRECT FAX=3A 234 1 759 0904=2E TEL=3B 234 1- 7763126 ATTENTION=3A THE PRESIDENT=2FC=2EE=2EO RE=3A URGENT & CONFIDENTIAL BUSINESS PROPOSAL Dear Sir=2C I am ENGR=2E JOE UDAH member committee of the above department My term of reference involves the award of contracts to multinational companies=2E My office is saddled with the responsibility of contract award=2C screening=2C categorization and prioritization of projects embarked upon by Department of Petroleum Resources =28DPR=29 as well as feasibility studies for selected projects and supervising the project consultants involved=2E A breakdown of the fiscal expenditure by this office as at the end of last fiscal quarter of 2000 indicates that DPR paid out a whooping sum of US$736M=28Seven Hundred And Thirty Six Million=2C United States Dollars=29 to successful contract beneficiaries=2E The DPR is now compiling beneficiaries to be paid for the first Quarter of 2003=2E The crux of this letter is that the finance=2Fcontract department of the DPR deliberately over invoiced the contract value of the various contracts awarded=2E In the course of disbursements=2C this department has been able to accumulate the sum of US$38=2E2M=28Thirty-eight Million=2C two hundred Thousand U=2ES Dollars=29 as the over-invoiced sum=2E This money is currently in a suspense account of the DPR account with the Debt Reconciliation Committee =28DRC=29=2E We now seek to process the transfer of this fund officially as contract payment to you as a foreign contractor=2C who will be fronting for us as the beneficiary of the fund=2E In this way we can facilitate these funds into your nominated account for possible investment abroad=2E We are not allowed as a matter of government policy to operate any foreign account to transfer this fund into=2E However=2C for your involvement in assisting us with this transfer into your nominated account we have evolved a sharing formula as follows=3A =281=29 20% for you as the foreign partner =282=29 75% for I and my colleagues =283=29 5% will be set aside to defray all incidental expenses both Locally and Internationally during the course of this transaction=2E We shall be relying on your advice as regard investment of our share in any business in your country=2E Be informed that this business is genuine and 100% safe considering the high-power government officials involved=2E Send your private fax=2Ftelephone numbers=2E Upon your response we shall provide you with further information on the procedures=2E Feel free to send response by Fax=3A 234-1-7590904 =2F TEL=3A 234-1-7763126 expecting your response urgently=2E All enquiries should be directed to the undersigned by FAX OR PHONE=2E Looking forward to a good business relationship with you=2E Sincerely=2C ENGR=2E JOE UDAH ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ccbng1n3vb1y@snb.ch Fri Jan 17 08:52:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ZwDe-0004uV-01 for ; Sat, 18 Jan 2003 17:53:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 18 Jan 2003 17:53:18 +0100 (CET) Received: (qmail 31752 invoked by uid 0); 17 Jan 2003 21:07:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 17 Jan 2003 21:07:56 -0000 Received: by moria.seul.org (Postfix) id ACAB633CC8; Fri, 17 Jan 2003 16:07:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F10BC33DB8; Fri, 17 Jan 2003 16:07:53 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from [173.161.122.140] (swtp221-196.adsl.seed.net.tw [211.74.221.196]) by moria.seul.org (Postfix) with SMTP id 434F433CC8 for ; Fri, 17 Jan 2003 16:07:52 -0500 (EST) Received: from [173.161.155.140] by [173.161.153.140] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 17 Jan 2003 15:47:14 +0800 From: ccbng1n3vb1y@snb.ch To: f-cpu@seul.org Subject: [f-cpu] =?ISO-8859-1?B?sdCxeqZwpvOmqKywuvS49KR1tXuudg==?= Date: 17 Jan 2003 15:52:08 +0800 Received: =?ISO-8859-1?B?ZnJvbSBsb2dpbl8wMjE2Lm1haWxzZXJ2aWNlLm5ldCAobXguc2VydmljZS5uZXRbMjA2LjIzMi4yMzEuNzddIChtYXkgYmUgZm9yZ2VkKSkgYnkgWzE5Mi4yMDEuMTMxLjE0N10gKDguOC41LzguNy4zKSB3aXRoIFNNVFAgaWQgWEFBMDMyNTQ7ICCsULTBpEAgMjIgpEOk6yAyMDAyIDA2OjE2OjM3IC0wNzAwIChFRFQp?= X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: f-cpu@seul.org X-Return-Path: ccbng1n3vb1y@snb.ch Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Fri Jan 17 21:28:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ZwDf-0004uV-00 for ; Sat, 18 Jan 2003 17:53:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 18 Jan 2003 17:53:19 +0100 (CET) Received: (qmail 20902 invoked by uid 0); 17 Jan 2003 21:28:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 17 Jan 2003 21:28:22 -0000 Received: by moria.seul.org (Postfix) id 2C85B33DB7; Fri, 17 Jan 2003 16:28:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C113133DC5; Fri, 17 Jan 2003 16:28:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from smtp3.9tel.net (smtp.9tel.net [213.203.124.146]) by moria.seul.org (Postfix) with ESMTP id 88BCB33DB7 for ; Fri, 17 Jan 2003 16:28:19 -0500 (EST) Received: from 59.190.62.62.9massy1-1-ro-bas-1.9tel.net (59.190.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.190.59]) by smtp3.9tel.net (Postfix) with ESMTP id 3A10B5BD6A for ; Fri, 17 Jan 2003 22:28:18 +0100 (CET) From: cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Stack Frame Layout and Varargs Handling Date: Fri, 17 Jan 2003 20:28:05 +0000 User-Agent: KMail/1.5 References: <20030115224732.30746@thrai.stud.uni-hannover.de> In-Reply-To: <20030115224732.30746@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200301172028.05774.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > It's time to specify argument passing and the like in more detail... [snip a lot of interresting stuff] You don't speak about your proposition for a second register allocator pass in the linker. Did we need to specify it yet or not ? I know that with this solution we have a compatibilitie between object that use it and object that don't use it, but it can be interesting to speak a little about it (It's a way to say : "we thing to this problem"). Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jan 18 01:47:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ZwDv-0004uV-01 for ; Sat, 18 Jan 2003 17:53:36 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 18 Jan 2003 17:53:35 +0100 (CET) Received: (qmail 28160 invoked by uid 0); 18 Jan 2003 00:48:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 18 Jan 2003 00:48:07 -0000 Received: by moria.seul.org (Postfix) id F348D33CCA; Fri, 17 Jan 2003 19:48:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 985A233CD0; Fri, 17 Jan 2003 19:48:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a052.home.uni-hannover.de [130.75.232.52]) by moria.seul.org (Postfix) with ESMTP id DE9B533CCA for ; Fri, 17 Jan 2003 19:48:00 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA08879; Sat, 18 Jan 2003 01:47:58 +0100 Message-ID: <20030118014758.02619@thrai.stud.uni-hannover.de> Date: Sat, 18 Jan 2003 01:47:58 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Stack Frame Layout and Varargs Handling References: <20030115224732.30746@thrai.stud.uni-hannover.de> <200301172028.05774.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200301172028.05774.cedric.bail@free.fr>; from cedric on Fri, Jan 17, 2003 at 08:28:05PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 17, 2003 at 08:28:05PM +0000, cedric wrote: [...] > You don't speak about your proposition for a second register allocator pass in > the linker. Did we need to specify it yet or not ? I know that with this > solution we have a compatibilitie between object that use it and object that > don't use it, but it can be interesting to speak a little about it (It's a > way to say : "we thing to this problem"). Step by step, please :) Step 1 is to build something that works. Step 2 is to build something that works faster. We didn't finish step 1 yet (although I successfully compiled and ran a `hello world' style program today). When that is done, we'll have to teach gcc how to output the `register usage hints' and fast entry points that we need for link-time register renaming, and build a linker that supports them. But first the compiler must learn how to generate correct code - some things are still broken. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From creditrepair@cjlinc.net Sun Jan 19 06:31:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18a9IP-0005W7-00 for ; Sun, 19 Jan 2003 07:51:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Jan 2003 07:51:05 +0100 (CET) Received: (qmail 12601 invoked by uid 0); 19 Jan 2003 05:32:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 19 Jan 2003 05:32:36 -0000 Received: by moria.seul.org (Postfix) id 6EFBA33C39; Sun, 19 Jan 2003 00:32:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCF3733C70; Sun, 19 Jan 2003 00:32:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 4C3B833C39 for ; Sun, 19 Jan 2003 00:32:28 -0500 (EST) Received: from 163.23.106.129 (modemcable101.9-200-24.que.mc.videotron.ca [24.200.9.101]) by bettik.munge.net (Postfix) with SMTP id 3F8284F851 for ; Sat, 18 Jan 2003 23:31:34 -0600 (CST) Received: from unknown (HELO f64.law4.hotmail.com) (13.61.40.178) by ssymail.ssy.co.kr with smtp; Jan, 18 2003 11:16:15 PM +0400 Received: from [204.80.13.95] by asy100.as122.sol.superonline.com with smtp; Jan, 18 2003 10:03:36 PM -0000 Received: from [72.62.68.193] by rly-yk04.mx.aol.com with asmtp; Jan, 18 2003 9:29:29 PM -0300 From: REMOVE BAD CREDIT…99763 To: f-cpu@seul.org Subject: [f-cpu] REMOVE ALL YOUR BAD CREDIT…99006 Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 18 Jan 2003 23:31:44 -0600 X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Priority: 1 Message-Id: <20030119053134.3F8284F851@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

CLICK HERE to find out more

 

 

 

 

CLICK HERE to unsubscribe

imgkhaipbrvlemvnsvggrenelrbiosplvn ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From illusion_to_net@yahoo.fr Mon Jan 20 09:17:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18arct-0004gY-00 for ; Tue, 21 Jan 2003 07:11:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 07:11:11 +0100 (CET) Received: (qmail 25173 invoked by uid 0); 20 Jan 2003 08:17:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 20 Jan 2003 08:17:42 -0000 Received: by moria.seul.org (Postfix) id 6714B33CB6; Mon, 20 Jan 2003 03:17:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C51E133CC1; Mon, 20 Jan 2003 03:17:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from web14910.mail.yahoo.com (web14910.mail.yahoo.com [216.136.225.62]) by moria.seul.org (Postfix) with SMTP id EDDFD33CB6 for ; Mon, 20 Jan 2003 03:17:39 -0500 (EST) Message-ID: <20030120081739.27816.qmail@web14910.mail.yahoo.com> Received: from [132.166.133.152] by web14910.mail.yahoo.com via HTTP; Mon, 20 Jan 2003 09:17:39 CET Date: Mon, 20 Jan 2003 09:17:39 +0100 (CET) From: =?iso-8859-1?q?Just=20an=20Illusion?= Subject: Re: [f-cpu] ±Ð±z¦p¦ó¦¨¬°ºô¸ô¤uµ{®v To: f-cpu@seul.org In-Reply-To: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, If so known the Javanais ;-) I was happy if it can translate me the original message. I have volontary supress the original message because it was some hidden javascript. My current browser is unable to launch directly some javascript (without confirmation), but I hope than message wasn't a virus. Please send only text or html (if any) message content, otherwise I'll can miss some messages. Thanks, Just an Illusion --- ccbng1n3vb1y@snb.ch a écrit : ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jan 20 11:11:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ard5-0004gY-00 for ; Tue, 21 Jan 2003 07:11:23 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 07:11:23 +0100 (CET) Received: (qmail 725 invoked by uid 0); 20 Jan 2003 10:12:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 20 Jan 2003 10:12:49 -0000 Received: by moria.seul.org (Postfix) id D1FB333C67; Mon, 20 Jan 2003 05:12:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 86ECA33CC9; Mon, 20 Jan 2003 05:12:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B7E4C33C67 for ; Mon, 20 Jan 2003 05:12:42 -0500 (EST) Received: from a86-137.dialup.iol.cz ([194.228.137.86] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18aYuw-0004tP-00 for f-cpu@seul.org; Mon, 20 Jan 2003 11:12:35 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18aYu1-0000ZA-00 for f-cpu@seul.org; Mon, 20 Jan 2003 11:11:37 +0100 Date: Mon, 20 Jan 2003 11:11:37 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] F-CPU gcc CVS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, I setup CVS server for gcc/config/fcpu subdirectory of gcc. The current trunk head can compile majority of code and can finally correctly generate loadaddr vs. loadaddrd. MR will merge it's SIMD support latter. You can untar vanilla gcc-3.2.1, do cd gcc/config export CVSROOT=:pserver:anonymous@luxik.cdi.cz:/var/cvsroot cvs login password: cvs cvs -z6 co fcpugcc mv fcpugcc fcpu cd ../.. patch -i gcc/config/fcpu/gcc32fcpu_conf.diff -p0 The last thing is needed because we don't have whole gcc in CVS, only fcpu subdir - thus gcc32fcpu_conf.diff is needed to add fcpu target to Makefiles. Then you can do ./configure --target=fcpu-none-none. To keep itself up to date to sometimes: cd gcc/config/fcpu cvs login .... cvs -z6 update and recompile :) have a fun, devik PS: if you'd want CVS also for other things (vhdl) let me know ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mmntbvackl@Britannica.com Mon Jan 20 04:14:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18arfx-0004gY-00 for ; Tue, 21 Jan 2003 07:14:21 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 07:14:21 +0100 (CET) Received: (qmail 11515 invoked by uid 0); 20 Jan 2003 17:56:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 20 Jan 2003 17:56:44 -0000 Received: by moria.seul.org (Postfix) id F267433C8D; Mon, 20 Jan 2003 12:56:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 47E3A33CE7; Mon, 20 Jan 2003 12:56:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from [184.213.22.190] (NK210-203-98-18.adsl.pl.apol.com.tw [210.203.98.18]) by moria.seul.org (Postfix) with SMTP id DE1F033C8D for ; Mon, 20 Jan 2003 12:56:39 -0500 (EST) Received: from [197.221.33.190] by [184.213.17.190] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 09 Feb 2000 11:17:10 +0800 From: mmntbvackl@Britannica.com To: f-cpu@seul.org Subject: [f-cpu] ±Ð±z ¦p¦ó°µ¤@±iº}«Gªººô­¶ Date: 20 Jan 2003 11:14:39 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; ¬P´Á¤@ 22 ¤C¤ë 2002 06:16:37 -0700 (EDT) X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: f-cpu@seul.org X-Return-Path: mmntbvackl@Britannica.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jan 20 15:40:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18argO-0004gY-00 for ; Tue, 21 Jan 2003 07:14:48 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 07:14:48 +0100 (CET) Received: (qmail 12211 invoked by uid 0); 20 Jan 2003 18:59:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 20 Jan 2003 18:59:43 -0000 Received: by moria.seul.org (Postfix) id 7BF5333CE7; Mon, 20 Jan 2003 13:59:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 931F333CEE; Mon, 20 Jan 2003 13:59:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a177.home.uni-hannover.de [130.75.232.177]) by moria.seul.org (Postfix) with ESMTP id B546333CE7 for ; Mon, 20 Jan 2003 13:59:39 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00553; Mon, 20 Jan 2003 15:40:33 +0100 Message-ID: <20030120154033.13325@thrai.stud.uni-hannover.de> Date: Mon, 20 Jan 2003 15:40:33 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Jan 20, 2003 at 11:11:37AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Jan 20, 2003 at 11:11:37AM +0100, devik wrote: > I setup CVS server for gcc/config/fcpu subdirectory > of gcc. The current trunk head can compile majority > of code and can finally correctly generate > loadaddr vs. loadaddrd. Yes, but it takes an awful lot of time and memory for that. I guess we need to find a cheaper way. [...] > Then you can do ./configure --target=fcpu-none-none. Wait... it has to be `fcpu-fcpu-none'. On my system, I added `fcpu' as a shorthand: ------- begin patch ------- --- ./config.sub~ Sat Feb 9 04:00:13 2002 +++ ./config.sub Sat Jan 11 01:48:54 2003 @@ -460,6 +460,10 @@ es1800 | OSE68k | ose68k | ose | OSE) basic_machine=m68k-ericsson os=-ose + ;; + fcpu) + basic_machine=fcpu-fcpu + os=-none ;; fx2800) basic_machine=i860-alliant ------- end patch ------- If you run `./configure --target=fcpu' and have the latest fctools installed, configure will automatically find the F-CPU assembler. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jan 20 21:44:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18args-0004gY-00 for ; Tue, 21 Jan 2003 07:15:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 07:15:18 +0100 (CET) Received: (qmail 31328 invoked by uid 0); 20 Jan 2003 20:59:29 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 20 Jan 2003 20:59:29 -0000 Received: by moria.seul.org (Postfix) id D11E733CC9; Mon, 20 Jan 2003 15:59:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3DF3333CED; Mon, 20 Jan 2003 15:59:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 5F1FC33CC9 for ; Mon, 20 Jan 2003 15:59:26 -0500 (EST) Received: from a98-137.dialup.iol.cz ([194.228.137.98] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18aj0s-00087m-00 for f-cpu@seul.org; Mon, 20 Jan 2003 21:59:24 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18aim5-0000oM-00 for f-cpu@seul.org; Mon, 20 Jan 2003 21:44:05 +0100 Date: Mon, 20 Jan 2003 21:44:05 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] F-CPU gcc CVS In-Reply-To: <20030120154033.13325@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > I setup CVS server for gcc/config/fcpu subdirectory > > of gcc. The current trunk head can compile majority > > of code and can finally correctly generate > > loadaddr vs. loadaddrd. > > Yes, but it takes an awful lot of time and memory for that. I guess we > need to find a cheaper way. There IS such way - go over all insns and pair NOTE_LABELs. But because we will need at least prefetches then complete DF will be needed anyway. It now take 50% of time but .... we have other problems than speed of compiler. > [...] > > Then you can do ./configure --target=fcpu-none-none. > > Wait... it has to be `fcpu-fcpu-none'. On my system, I added `fcpu' > as a shorthand: ahh ok. I missed it :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mlpi_uy_rff03dw@amazon.com Tue Jan 21 03:53:51 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18b05H-00028m-00 for ; Tue, 21 Jan 2003 16:13:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 16:13:03 +0100 (CET) Received: (qmail 21439 invoked by uid 0); 21 Jan 2003 07:08:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 21 Jan 2003 07:08:31 -0000 Received: by moria.seul.org (Postfix) id CDF8933D06; Tue, 21 Jan 2003 02:08:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 478AD33CF6; Tue, 21 Jan 2003 02:08:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from [198.23.31.201] (c41.h061013017.is.net.tw [61.13.17.41]) by moria.seul.org (Postfix) with SMTP id 357B233CE5 for ; Tue, 21 Jan 2003 02:08:28 -0500 (EST) Received: from [198.23.183.201] by [198.23.217.201] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 21 Jan 2003 10:54:19 +0800 From: mlpi_uy_rff03dw@amazon.com To: f-cpu@seul.org Subject: [f-cpu] ·q­P¡G±M§Q°Ó¼Ðºc·Q¤H¡B¥Ó½Ð¤H¡B©Ó¿ì¤H Date: 21 Jan 2003 10:53:51 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; ¬P´Á¥| 22 ¤K¤ë 2002 06:16:37 -0700 (EDT) X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: f-cpu@seul.org X-Return-Path: mlpi_uy_rff03dw@amazon.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N §Ú­Ì¬O¥xÆWªº¥D­n¦¨¦~¤H©Ê·Rª±¨ã»s³y°Ó©M¥X¤f°Ó¤§¤@

·q­P¡G±M§Q°Ó¼Ðºc·Q¤H¡B¥Ó½Ð¤H¡B©Ó¿ì¤H

·q¯¬¦Ï¦~³ß®ð¬v¬v¡A¸U¨Æ¦N²»¡C

ª¾©ú±M§Q°Ó¼Ð¨Æ°È©Ò·q¤W
¹q¸Ü¡G(02) 2695 8836 
             0933 067 099
(­Y¦³¥´ÂZ¡A·q½Ð¥]²[¡C)
(½Ð¤Å¥ÎE-mail ¸ß°Ý, ¦]¬°E-mail¬O¼s§i¤½¥qªº)

                                                                                  
(¤@) ¥»©ÒÀuÂI

        ¥i©Ó¿ì¥@¬É¦U°ê±M§Q°Ó¼Ð¤§¥Ó½Ð¡AµL»·¥±©¡¡C       

        ªA°È©P¸Ô¡Aµ´¹ï«O±K¡Cª§¨ú®É¾÷¡A§Y®É«ô³X¡C
        »ù®æ¤½¹D¡Aµ´¹ï±M·~¡C¤å¦rÀu¬ü¡A«O»ÙÅv¯q¡C
          

(¤G) ¯S§OªA°È

      1. ¹ï«È¤á±ý¥Ó½Ð±M§Q/°Ó¼Ð¤§®×¥ó¸Ô¥[µû¦ô¡Aµû¦ô¤£¦¬¶O¥Î¡C

      2. ¦p±ý«Oµý¨ú±oÃҮѡA«h¥»©Òµû¦ô«á­Y»{¬°¥i¥HÀò±oÃҮѡAÂù¤è¥i¥Hñ¬ù¼i¦æ¡A
          ¦ý»ù®æ¥[­¿¡C
               
      3. ¬°«È¤á´£¨Ñ±`¦~ÅU°Ý¦¬¶OªA°È¡AÁ|¤ZÀ˯Á¡B¥Ó½Ð¡BµªÅG¡B²§Ä³¡BÁ|µo¡B¶D³^¡B
          «IÅv¡B¥é«_¡B±M§Q°jÁסB±Ð¨|¡B¬ã°Q¡B¸ê°T»`¶°µ¥¬ÛÃö°ÝÃD§¡¥i´£¨Ñ¡C

     
       ¦p¦³»Ý­n¡A·q½Ð³qª¾¡C
       ¦p»X¤¶²Ð¡A¥Ñ°J·PÁ¡C

 

¡@

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Jan 21 00:49:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18b06Y-00028m-00 for ; Tue, 21 Jan 2003 16:14:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 21 Jan 2003 16:14:22 +0100 (CET) Received: (qmail 27642 invoked by uid 0); 21 Jan 2003 13:56:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 21 Jan 2003 13:56:03 -0000 Received: by moria.seul.org (Postfix) id 5C5DB33D06; Tue, 21 Jan 2003 08:56:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E505433D97; Tue, 21 Jan 2003 08:56:01 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a033.home.uni-hannover.de [130.75.232.33]) by moria.seul.org (Postfix) with ESMTP id D1C6A33D06 for ; Tue, 21 Jan 2003 08:55:59 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA23511; Tue, 21 Jan 2003 00:49:09 +0100 Message-ID: <20030121004909.19449@thrai.stud.uni-hannover.de> Date: Tue, 21 Jan 2003 00:49:09 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: <20030120154033.13325@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Jan 20, 2003 at 09:44:05PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Jan 20, 2003 at 09:44:05PM +0100, devik wrote: > > > I setup CVS server for gcc/config/fcpu subdirectory > > > of gcc. The current trunk head can compile majority > > > of code and can finally correctly generate > > > loadaddr vs. loadaddrd. > > > > Yes, but it takes an awful lot of time and memory for that. I guess we > > need to find a cheaper way. > > There IS such way - go over all insns and pair NOTE_LABELs. > But because we will need at least prefetches then complete > DF will be needed anyway. > It now take 50% of time but .... we have other problems than > speed of compiler. My main problem is that it takes so much memory that I can't compile some large source files any longer (e.g. fctools/emu/emu.c). More than half of the memory consumed is used by the DF, even with moderate optimization (-O -fomit-frame-pointer) or no optimization at all. IMHO, the DF phase should not run when -O isn't specified, and maybe only with -O2 or higher. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Jan 21 16:35:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18bBGA-0001Iu-00 for ; Wed, 22 Jan 2003 04:09:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 22 Jan 2003 04:09:02 +0100 (CET) Received: (qmail 8665 invoked by uid 0); 21 Jan 2003 15:36:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 21 Jan 2003 15:36:49 -0000 Received: by moria.seul.org (Postfix) id 4EC7B33D96; Tue, 21 Jan 2003 10:36:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9E8CF33D9B; Tue, 21 Jan 2003 10:36:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 96CEE33D96 for ; Tue, 21 Jan 2003 10:36:45 -0500 (EST) Received: from a22-137.dialup.iol.cz ([194.228.137.22] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18b0S9-0003Vm-00 for f-cpu@seul.org; Tue, 21 Jan 2003 16:36:42 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18b0R7-00022y-00 for f-cpu@seul.org; Tue, 21 Jan 2003 16:35:37 +0100 Date: Tue, 21 Jan 2003 16:35:36 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] F-CPU gcc CVS In-Reply-To: <20030121004909.19449@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > But because we will need at least prefetches then complete > > DF will be needed anyway. > > It now take 50% of time but .... we have other problems than > > speed of compiler. > > My main problem is that it takes so much memory that I can't compile some > large source files any longer (e.g. fctools/emu/emu.c). More than half of > the memory consumed is used by the DF, even with moderate optimization > (-O -fomit-frame-pointer) or no optimization at all. IMHO, the DF phase > should not run when -O isn't specified, and maybe only with -O2 or higher. Ok I did 2 changes, - reorg pass is done only with -O - I fine grained DF flags so that it takes 1/3 of memory devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 22 00:04:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18bBJ5-0001Iu-00 for ; Wed, 22 Jan 2003 04:12:03 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 22 Jan 2003 04:12:03 +0100 (CET) Received: (qmail 1567 invoked by uid 0); 21 Jan 2003 23:04:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 21 Jan 2003 23:04:15 -0000 Received: by moria.seul.org (Postfix) id 9FC9C33DC5; Tue, 21 Jan 2003 18:04:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0DCCE33DD5; Tue, 21 Jan 2003 18:04:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a067.home.uni-hannover.de [130.75.232.67]) by moria.seul.org (Postfix) with ESMTP id AB58B33DC5 for ; Tue, 21 Jan 2003 18:04:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02664; Wed, 22 Jan 2003 00:04:15 +0100 Message-ID: <20030122000415.02152@thrai.stud.uni-hannover.de> Date: Wed, 22 Jan 2003 00:04:15 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: <20030121004909.19449@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Jan 21, 2003 at 04:35:36PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Jan 21, 2003 at 04:35:36PM +0100, devik wrote: [...] > - reorg pass is done only with -O > - I fine grained DF flags so that it takes 1/3 of memory Sounds good :) But I see nothing in CVS yet. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Jan 22 09:53:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c57k-0006tO-00 for ; Fri, 24 Jan 2003 15:48:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:48:04 +0100 (CET) Received: (qmail 26727 invoked by uid 0); 22 Jan 2003 08:56:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 22 Jan 2003 08:56:59 -0000 Received: by moria.seul.org (Postfix) id BDAD633CF2; Wed, 22 Jan 2003 03:56:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F6EC33D05; Wed, 22 Jan 2003 03:56:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id C5B1B33CF2 for ; Wed, 22 Jan 2003 03:56:56 -0500 (EST) Received: from a10-137.dialup.iol.cz ([194.228.137.10] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18bGgk-0000k3-00 for f-cpu@seul.org; Wed, 22 Jan 2003 09:56:51 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18bGdm-0000AJ-00 for f-cpu@seul.org; Wed, 22 Jan 2003 09:53:46 +0100 Date: Wed, 22 Jan 2003 09:53:45 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] F-CPU gcc CVS In-Reply-To: <20030122000415.02152@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > On Tue, Jan 21, 2003 at 04:35:36PM +0100, devik wrote: > [...] > > - reorg pass is done only with -O > > - I fine grained DF flags so that it takes 1/3 of memory > > Sounds good :) But I see nothing in CVS yet. Eh? : [devik@devix fcpu]$ cvs -z9 log fcpu.c RCS file: /var/cvsroot/fcpugcc/fcpu.c,v Working file: fcpu.c head: 1.5 branch: locks: strict access list: symbolic names: cvs_created: 1.3 keyword substitution: kv total revisions: 5; selected revisions: 5 description: ---------------------------- revision 1.5 date: 2003/01/21 15:38:12; author: devik; state: Exp; lines: +5 -1 DF in reorg pass is made less expensive and is used only in optimizing compilation ---------------------------- revision 1.4 date: 2003/01/20 22:35:27; author: riepe; state: Exp; lines: +673 -66 Numerous changes: - SIMD support ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mmntbvackl@Britannica.com Wed Jan 22 16:54:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Bw-0006tO-00 for ; Fri, 24 Jan 2003 15:52:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:52:24 +0100 (CET) Received: (qmail 24457 invoked by uid 0); 22 Jan 2003 21:54:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 22 Jan 2003 21:54:51 -0000 Received: by moria.seul.org (Postfix) id 0DCE633DE3; Wed, 22 Jan 2003 16:54:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CBED33DE5; Wed, 22 Jan 2003 16:54:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from [188.212.156.16] (NK210-203-98-30.adsl.pl.apol.com.tw [210.203.98.30]) by moria.seul.org (Postfix) with SMTP id E290233DE3 for ; Wed, 22 Jan 2003 16:54:48 -0500 (EST) Received: from [188.212.162.16] by [188.212.175.16] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 22 Jan 2003 23:54:24 +0800 From: mmntbvackl@Britannica.com To: f-cpu@seul.org Subject: [f-cpu] ±Ð±z ¦p¦ó°µ¤@±iº}«Gªººô­¶ Date: 22 Jan 2003 23:54:24 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; ¬P´Á¤@ 22 ¤C¤ë 2002 06:16:37 -0700 (EDT) X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: f-cpu@seul.org X-Return-Path: mmntbvackl@Britannica.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Jan 22 18:20:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Cl-0006tO-00 for ; Fri, 24 Jan 2003 15:53:15 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:53:15 +0100 (CET) Received: (qmail 13800 invoked by uid 0); 22 Jan 2003 22:49:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 22 Jan 2003 22:49:03 -0000 Received: by moria.seul.org (Postfix) id EDC5A33DE6; Wed, 22 Jan 2003 17:49:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8386233DE3; Wed, 22 Jan 2003 17:49:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a128.home.uni-hannover.de [130.75.232.128]) by moria.seul.org (Postfix) with ESMTP id D2FCE33DE1 for ; Wed, 22 Jan 2003 17:48:57 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA02212; Wed, 22 Jan 2003 18:20:48 +0100 Message-ID: <20030122182047.00248@thrai.stud.uni-hannover.de> Date: Wed, 22 Jan 2003 18:20:47 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: <20030122000415.02152@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Jan 22, 2003 at 09:53:45AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Jan 22, 2003 at 09:53:45AM +0100, devik wrote: > > On Tue, Jan 21, 2003 at 04:35:36PM +0100, devik wrote: > > [...] > > > - reorg pass is done only with -O > > > - I fine grained DF flags so that it takes 1/3 of memory > > > > Sounds good :) But I see nothing in CVS yet. > > Eh? : My fault; I got it now. But it is "slightly broken": When I turn off optimizations, gcc uses loadaddrid for all labels (if fcpu_reorg isn't run, the `call' member is never set, and print_operand assumes a data operand). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Jan 23 08:27:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5ES-0006tO-00 for ; Fri, 24 Jan 2003 15:55:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:55:00 +0100 (CET) Received: (qmail 13170 invoked by uid 0); 23 Jan 2003 08:04:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Jan 2003 08:04:50 -0000 Received: by moria.seul.org (Postfix) id F27F333C73; Thu, 23 Jan 2003 03:04:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2A75933DEC; Thu, 23 Jan 2003 03:04:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B76EC33C73 for ; Thu, 23 Jan 2003 03:04:46 -0500 (EST) Received: from a119-137.dialup.iol.cz ([194.228.137.119] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18bcLm-0007NS-00 for f-cpu@seul.org; Thu, 23 Jan 2003 09:04:39 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18bblQ-0000BS-00 for f-cpu@seul.org; Thu, 23 Jan 2003 08:27:04 +0100 Date: Thu, 23 Jan 2003 08:27:04 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] F-CPU gcc CVS In-Reply-To: <20030122182047.00248@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Eh? : > > My fault; I got it now. But it is "slightly broken": When I turn off > optimizations, gcc uses loadaddrid for all labels (if fcpu_reorg isn't > run, the `call' member is never set, and print_operand assumes a data > operand). yes I know - but it should still work even with penalty on each address use. IMHO now comes the emulator - you could handle syscalls by means of mapping them directly or thru some xlat table to linux syscalls. Yes I know it is linux dependent (so should be option) but it is the fastest way. Then we can take uClibc and write syscall fn in assembler. Then we should be able to compile any application (bash f.e.) and RUN it ! It allows us to test compiled output and measure some things before digging blindly into compiler ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jrydberg@night.trouble.net Thu Jan 23 09:37:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Eb-0006tO-00 for ; Fri, 24 Jan 2003 15:55:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:55:09 +0100 (CET) Received: (qmail 10309 invoked by uid 0); 23 Jan 2003 08:37:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 23 Jan 2003 08:37:16 -0000 Received: by moria.seul.org (Postfix) id C845333CFB; Thu, 23 Jan 2003 03:37:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 52D5533DED; Thu, 23 Jan 2003 03:37:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from nic.lth.se (nic.lth.se [130.235.20.3]) by moria.seul.org (Postfix) with ESMTP id 50A3633CFB for ; Thu, 23 Jan 2003 03:37:13 -0500 (EST) Received: from night.trouble.net (powermac-12.ludat.lth.se [130.235.21.232]) by nic.lth.se (8.12.3/8.12.3) with ESMTP id h0N8bBHp002804 for ; Thu, 23 Jan 2003 09:37:11 +0100 (MET) Date: Thu, 23 Jan 2003 09:37:06 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: [f-cpu] Another simulator! From: Johan Rydberg To: f-cpu@seul.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, I'm currently re-writing my simulator, GUSS [1], to gain more performance and flexibility. As initial target I will probably choose the OpenRISC architecture, but I'm very intrested in F-CPU as well. So, if I choose to implement a F-CPU target, where can I find up-to-date reference documentation? brgds, johan [1] http://www.nongnu.org/guss/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Thu Jan 23 17:58:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Fa-0006tO-00 for ; Fri, 24 Jan 2003 15:56:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:56:10 +0100 (CET) Received: (qmail 28344 invoked by uid 0); 23 Jan 2003 13:00:37 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 23 Jan 2003 13:00:37 -0000 Received: by moria.seul.org (Postfix) id 714CB33DEB; Thu, 23 Jan 2003 08:00:36 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 120B333DED; Thu, 23 Jan 2003 08:00:35 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 8E5B933DEB for ; Thu, 23 Jan 2003 08:00:34 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id C14FC62D01 for ; Thu, 23 Jan 2003 14:00:32 +0100 (CET) To: Subject: [f-cpu] x86-64 long article From: Date: Thu, 23 Jan 2003 13:58:47 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N http://www.digit-life.com/articles2/amd-hammer-family/index.html big article about x86-64. nicO ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 23 17:41:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5GB-0006tO-00 for ; Fri, 24 Jan 2003 15:56:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:56:47 +0100 (CET) Received: (qmail 16363 invoked by uid 0); 23 Jan 2003 16:25:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Jan 2003 16:25:47 -0000 Received: by moria.seul.org (Postfix) id 78A9333D95; Thu, 23 Jan 2003 11:25:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A9C8233DF2; Thu, 23 Jan 2003 11:25:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id BAA3D33D95 for ; Thu, 23 Jan 2003 11:25:44 -0500 (EST) Received: from f-cpu.org (lcbv1-3-87.n.club-internet.fr [213.44.21.87]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 63ED616B2 for ; Thu, 23 Jan 2003 17:26:01 +0100 (CET) Message-ID: <3E301B30.4010401@f-cpu.org> Date: Thu, 23 Jan 2003 17:41:20 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Another simulator! References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi ! Johan Rydberg wrote: > Hi, > > I'm currently re-writing my simulator, GUSS [1], to gain more performance > and flexibility. As initial target I will probably choose the > OpenRISC architecture, The one from MIPS ? > but I'm very intrested in F-CPU as well. So, if I choose to implement > a F-CPU target, > where can I find up-to-date reference documentation? in the sources and in the "manual". Note that in order to be both attractive and efficiently coded, one has to take ultra-wide register sizes from the start. If you don't code with more than 64-bit sizes in mind, then your simulator will have to be recoded (and maybe rearchitectured) later. You can also probably look at other's implementations. have fun ! > brgds, > johan > > [1] http://www.nongnu.org/guss/ > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Jan 23 20:32:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Gk-0006tO-00 for ; Fri, 24 Jan 2003 15:57:22 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:57:22 +0100 (CET) Received: (qmail 11163 invoked by uid 0); 23 Jan 2003 19:17:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 23 Jan 2003 19:17:18 -0000 Received: by moria.seul.org (Postfix) id 84CD233DF4; Thu, 23 Jan 2003 14:17:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E400433DF8; Thu, 23 Jan 2003 14:17:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 6860933DF4 for ; Thu, 23 Jan 2003 14:17:16 -0500 (EST) Received: from f-cpu.org (liifi-13-87.n.club-internet.fr [213.44.44.87]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 7428F1722 for ; Thu, 23 Jan 2003 20:17:12 +0100 (CET) Message-ID: <3E304362.3070507@f-cpu.org> Date: Thu, 23 Jan 2003 20:32:50 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! nico@seul.org wrote: >http://www.digit-life.com/articles2/amd-hammer-family/index.html > >big article about x86-64. > > and it adds water to my mill : look, in order to build a system with more than 8 CPU, they have to use interconnexion chips :-) >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 23 14:38:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Gx-0006tO-00 for ; Fri, 24 Jan 2003 15:57:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:57:35 +0100 (CET) Received: (qmail 29562 invoked by uid 0); 23 Jan 2003 23:07:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Jan 2003 23:07:26 -0000 Received: by moria.seul.org (Postfix) id 6C40133DF9; Thu, 23 Jan 2003 18:07:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC42733DFC; Thu, 23 Jan 2003 18:07:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a124.home.uni-hannover.de [130.75.232.124]) by moria.seul.org (Postfix) with ESMTP id 0087633DF9 for ; Thu, 23 Jan 2003 18:07:22 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00535; Thu, 23 Jan 2003 14:38:08 +0100 Message-ID: <20030123143807.05642@thrai.stud.uni-hannover.de> Date: Thu, 23 Jan 2003 14:38:07 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Another simulator! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Johan Rydberg on Thu, Jan 23, 2003 at 09:37:06AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 23, 2003 at 09:37:06AM +0100, Johan Rydberg wrote: > Hi, > > I'm currently re-writing my simulator, GUSS [1], to gain more > performance > and flexibility. As initial target I will probably choose the OpenRISC > architecture, > but I'm very intrested in F-CPU as well. So, if I choose to implement a > F-CPU target, > where can I find up-to-date reference documentation? In various pieces of source code. The ISA is still a moving target, we didn't assign the final opcodes yet, and so on. If you want to be compatible, look at my `fctools' package, from http://f-cpu.seul.org/~f-cpu/new/ (in particular, the `fcpu_opcodes.h' file). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Jan 23 14:33:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5HC-0006tO-00 for ; Fri, 24 Jan 2003 15:57:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:57:50 +0100 (CET) Received: (qmail 3467 invoked by uid 0); 23 Jan 2003 23:07:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 23 Jan 2003 23:07:31 -0000 Received: by moria.seul.org (Postfix) id 75B7533DFB; Thu, 23 Jan 2003 18:07:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E2A1B33DFD; Thu, 23 Jan 2003 18:07:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a124.home.uni-hannover.de [130.75.232.124]) by moria.seul.org (Postfix) with ESMTP id BA93933DFB for ; Thu, 23 Jan 2003 18:07:24 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00516; Thu, 23 Jan 2003 14:33:56 +0100 Message-ID: <20030123143356.45361@thrai.stud.uni-hannover.de> Date: Thu, 23 Jan 2003 14:33:56 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: <20030122182047.00248@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Jan 23, 2003 at 08:27:04AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 23, 2003 at 08:27:04AM +0100, devik wrote: [...] > IMHO now comes the emulator - you could handle syscalls by means > of mapping them directly or thru some xlat table to linux syscalls. > Yes I know it is linux dependent (so should be option) but it is > the fastest way. You mean, call `int 0x80' directly on an Intel box? I'd rather stick to the libc interface that I use now. > Then we can take uClibc and write syscall fn in assembler. Then we > should be able to compile any application (bash f.e.) and RUN it ! First we need a linker (at least a static one), and I have to teach the emulator how to execute ELF files. It's currently more a machine emulator than a Linux emulator. > It allows us to test compiled output and measure some things before > digging blindly into compiler ... Yep. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 24 00:42:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Hx-0006tO-00 for ; Fri, 24 Jan 2003 15:58:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:58:37 +0100 (CET) Received: (qmail 25318 invoked by uid 0); 23 Jan 2003 23:42:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 23 Jan 2003 23:42:47 -0000 Received: by moria.seul.org (Postfix) id 85E6433DFA; Thu, 23 Jan 2003 18:42:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 51FF833DFE; Thu, 23 Jan 2003 18:42:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a124.home.uni-hannover.de [130.75.232.124]) by moria.seul.org (Postfix) with ESMTP id B370C33DFA for ; Thu, 23 Jan 2003 18:42:44 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02163; Fri, 24 Jan 2003 00:42:49 +0100 Message-ID: <20030124004249.51186@thrai.stud.uni-hannover.de> Date: Fri, 24 Jan 2003 00:42:49 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> <3E304362.3070507@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E304362.3070507@f-cpu.org>; from Yann Guidon on Thu, Jan 23, 2003 at 08:32:50PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 23, 2003 at 08:32:50PM +0100, Yann Guidon wrote: [...] > and it adds water to my mill : > look, in order to build a system with more than 8 CPU, > they have to use interconnexion chips :-) Sounds like the return of the G-chip... Too bad that 8b/10b encoding and other good stuff are patented. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rhartny@bellsouth.net Fri Jan 24 00:52:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Ho-0006tO-00 for ; Fri, 24 Jan 2003 15:58:28 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:58:28 +0100 (CET) Received: (qmail 7998 invoked by uid 0); 23 Jan 2003 23:42:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 23 Jan 2003 23:42:30 -0000 Received: by moria.seul.org (Postfix) id 1F37833DF8; Thu, 23 Jan 2003 18:42:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 815DD33DFC; Thu, 23 Jan 2003 18:42:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from imf01bis.bellsouth.net (mail201.mail.bellsouth.net [205.152.58.141]) by moria.seul.org (Postfix) with ESMTP id BB63B33DF8 for ; Thu, 23 Jan 2003 18:42:27 -0500 (EST) Received: from computer ([208.60.244.198]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030123234422.VYA29879.imf01bis.bellsouth.net@computer> for ; Thu, 23 Jan 2003 18:44:22 -0500 Message-ID: <000e01c2c33a$740ca360$c6f43cd0@computer> From: "richard hartny" To: Subject: [f-cpu] AMD OPTERON/ATHLON Date: Thu, 23 Jan 2003 17:52:12 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C2C308.28B991C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C2C308.28B991C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI GUYS Still looking and watching. I am using 39, yes I said 39 ALP76 = Processors which serve as my Language Processor. The TIPS Software that = I am capturing is written in re-locatable code. None of the routines = are more than 512 Instructions. Each Processor is assigned a specific = Block and forwarding is accomplished via Interrupt to select a Specific = Sub-routine (processor). No processor services more than eight (8) = subroutines. To prevent a logjam multiple processors are used. The TIPS software can be used almost as is. I didn't plan it that = way, but that is the way the cookie crumbled; so to speak. In addition; = I am on using the ON-CHIP RAM for Instructions and Operands. In some cases the Operand is OFF-CHIP = and Arbitration is required for Reads and Writes to the SSRAM four port = things. These are organized horizontally in a group of eight where each = has a dedicated Read and Write Port so the arbitration is to one of the = eight. I think I say that correctly. Questions will certainly be replied to. Regards Dick Hartney ------=_NextPart_000_000B_01C2C308.28B991C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI GUYS
 
    Still looking and=20 watching.  I am using 39, yes I said 39 ALP76 Processors which = serve as my=20 Language Processor.  The TIPS Software that I am capturing is = written in=20 re-locatable code.  None of the routines are more than 512=20 Instructions.  Each Processor is assigned a specific Block and = forwarding=20 is accomplished via Interrupt to select a Specific Sub-routine = (processor).=20  No processor services more than eight (8) subroutines.  To = prevent a=20 logjam multiple processors are used.
 
    The TIPS software = can be used=20 almost as is.  I didn't plan it that way, but that is the way the = cookie=20 crumbled; so to speak.  In addition; I am on using the = ON-CHIP
RAM for Instructions and Operands. In = some cases=20 the Operand is OFF-CHIP and
Arbitration is required for Reads and = Writes to the=20 SSRAM four port things.  These are organized horizontally in a = group of=20 eight where each has a dedicated Read and Write Port so the arbitration = is to=20 one of the eight.  I think I say that correctly.
 
    Questions will = certainly be=20 replied to.
 
Regards
Dick Hartney
------=_NextPart_000_000B_01C2C308.28B991C0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 24 01:01:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5I6-0006tO-00 for ; Fri, 24 Jan 2003 15:58:46 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:58:46 +0100 (CET) Received: (qmail 12636 invoked by uid 0); 23 Jan 2003 23:45:52 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 23 Jan 2003 23:45:52 -0000 Received: by moria.seul.org (Postfix) id 93EEF33DFC; Thu, 23 Jan 2003 18:45:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5AA6833DFF; Thu, 23 Jan 2003 18:45:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id D13CE33DFC for ; Thu, 23 Jan 2003 18:45:50 -0500 (EST) Received: from f-cpu.org (lcbv5-1-87.n.club-internet.fr [213.44.18.87]) by relay-2m.club-internet.fr (Postfix) with ESMTP id C84CE16C5 for ; Fri, 24 Jan 2003 00:45:48 +0100 (CET) Message-ID: <3E308257.5010200@f-cpu.org> Date: Fri, 24 Jan 2003 01:01:27 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> <3E304362.3070507@f-cpu.org> <20030124004249.51186@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Thu, Jan 23, 2003 at 08:32:50PM +0100, Yann Guidon wrote: >[...] > > >>and it adds water to my mill : >>look, in order to build a system with more than 8 CPU, >>they have to use interconnexion chips :-) >> >> >Sounds like the return of the G-chip... > > was it ever away ? Or somebody found the way to multiply the number of pins without exploding the F-Chip's cost ?... >Too bad that 8b/10b encoding and other good stuff are patented. > > Well, i have thought for a long time about an oversampled synchronous communication path. But the maths behind it are too tough for me :-( YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 24 01:23:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5IJ-0006tO-00 for ; Fri, 24 Jan 2003 15:58:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:58:59 +0100 (CET) Received: (qmail 10676 invoked by uid 0); 24 Jan 2003 00:23:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 24 Jan 2003 00:23:12 -0000 Received: by moria.seul.org (Postfix) id 2FF4B33DFE; Thu, 23 Jan 2003 19:23:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 30E9233E00; Thu, 23 Jan 2003 19:23:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a168.home.uni-hannover.de [130.75.232.168]) by moria.seul.org (Postfix) with ESMTP id 6219233DFE for ; Thu, 23 Jan 2003 19:23:04 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02321; Fri, 24 Jan 2003 01:23:02 +0100 Message-ID: <20030124012302.22629@thrai.stud.uni-hannover.de> Date: Fri, 24 Jan 2003 01:23:02 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> <3E304362.3070507@f-cpu.org> <20030124004249.51186@thrai.stud.uni-hannover.de> <3E308257.5010200@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E308257.5010200@f-cpu.org>; from Yann Guidon on Fri, Jan 24, 2003 at 01:01:27AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Jan 24, 2003 at 01:01:27AM +0100, Yann Guidon wrote: [...] > >Sounds like the return of the G-chip... > > > was it ever away ? Haven't heard from it for a long time... > Or somebody found the way to multiply the number of pins > without exploding the F-Chip's cost ?... I still prefer high-speed serial links. Something that's compatible with one of the existing serial "buses" would be even better. But... > >Too bad that 8b/10b encoding and other good stuff are patented. > > > > > Well, i have thought for a long time about an oversampled synchronous > communication path. > But the maths behind it are too tough for me :-( Hmm... what exactly do you have in mind? Dump your brain to my standard input, please :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 24 02:15:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5IY-0006tO-00 for ; Fri, 24 Jan 2003 15:59:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 15:59:14 +0100 (CET) Received: (qmail 13272 invoked by uid 0); 24 Jan 2003 00:59:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 24 Jan 2003 00:59:42 -0000 Received: by moria.seul.org (Postfix) id C272133E01; Thu, 23 Jan 2003 19:59:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3749733E03; Thu, 23 Jan 2003 19:59:41 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id CA4B233E01 for ; Thu, 23 Jan 2003 19:59:40 -0500 (EST) Received: from f-cpu.org (lcbv2-1-64.n.club-internet.fr [213.44.12.64]) by relay-5m.club-internet.fr (Postfix) with ESMTP id A2177E18A for ; Fri, 24 Jan 2003 01:59:51 +0100 (CET) Message-ID: <3E3093A3.2070101@f-cpu.org> Date: Fri, 24 Jan 2003 02:15:15 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030123130032.C14FC62D01@mallaury.noc.nerim.net> <3E304362.3070507@f-cpu.org> <20030124004249.51186@thrai.stud.uni-hannover.de> <3E308257.5010200@f-cpu.org> <20030124012302.22629@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! (maybe we can go to the francomoule's tribune ?) Michael Riepe wrote: >On Fri, Jan 24, 2003 at 01:01:27AM +0100, Yann Guidon wrote: >[...] > > >>>Sounds like the return of the G-chip... >>> >>was it ever away ? >> >> >Haven't heard from it for a long time... > > i don't like to speak about things that drive people crazy :-) >>Or somebody found the way to multiply the number of pins >>without exploding the F-Chip's cost ?... >> >> >I still prefer high-speed serial links. > we can't access this technology, or the die's price climbs. > Something that's compatible >with one of the existing serial "buses" would be even better. But... > > yep, you named it. eing compatible with Intel and other has some risks .... >>>Too bad that 8b/10b encoding and other good stuff are patented. >>> >>Well, i have thought for a long time about an oversampled synchronous >>communication path. >>But the maths behind it are too tough for me :-( >> >> >Hmm... what exactly do you have in mind? Dump your brain to my >standard input, please :) > But not in public. It's an old idea (3 or 4 years ?) but i want to be the first to find the solution ;-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 24 08:52:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5K3-0006tO-00 for ; Fri, 24 Jan 2003 16:00:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:00:47 +0100 (CET) Received: (qmail 17706 invoked by uid 0); 24 Jan 2003 09:03:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 24 Jan 2003 09:03:25 -0000 Received: by moria.seul.org (Postfix) id BF00F33DF9; Fri, 24 Jan 2003 04:03:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0EA233E01; Fri, 24 Jan 2003 04:03:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 868F833DF9 for ; Fri, 24 Jan 2003 04:03:14 -0500 (EST) Received: from a125-137.dialup.iol.cz ([194.228.137.125] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18bzjz-0005pF-00 for f-cpu@seul.org; Fri, 24 Jan 2003 10:03:12 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18bydO-0000Bh-00 for f-cpu@seul.org; Fri, 24 Jan 2003 08:52:18 +0100 Date: Fri, 24 Jan 2003 08:52:18 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] F-CPU gcc CVS In-Reply-To: <20030123143356.45361@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > You mean, call `int 0x80' directly on an Intel box? I'd rather stick > to the libc interface that I use now. It is cleaner of course - but the almost all syscalls should be implemented to be able to run with native libc. And implementing about 100 syscalls will take some time .. Maybe there could be transition phase - use int80, focus on linker and emulator and later substitute syscalls one by one .. just idea ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Jan 24 14:25:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5KA-0006tO-00 for ; Fri, 24 Jan 2003 16:00:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:00:54 +0100 (CET) Received: (qmail 16694 invoked by uid 0); 24 Jan 2003 09:27:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 24 Jan 2003 09:27:23 -0000 Received: by moria.seul.org (Postfix) id 2AAA233DFE; Fri, 24 Jan 2003 04:27:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9AFA933E03; Fri, 24 Jan 2003 04:27:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 6EA5133DFE for ; Fri, 24 Jan 2003 04:27:10 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 5B66062E43 for ; Fri, 24 Jan 2003 10:27:09 +0100 (CET) To: Subject: Re: [f-cpu] x86-64 long article From: Date: Fri, 24 Jan 2003 10:25:22 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030124092709.5B66062E43@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Yann Guidon a écrit : > hi ! > > (maybe we can go to the francomoule's tribune ?) > > Michael Riepe wrote: > > >On Fri, Jan 24, 2003 at 01:01:27AM +0100, Yann Guidon wrote: > >[...] > > > > > >>>Sounds like the return of the G-chip... > >>> > >>was it ever away ? > >> > >> > >Haven't heard from it for a long time... > > > > > i don't like to speak about things that drive people crazy :-) > :) If you want more than 8 fcpu in a single machine use multicore chip ! :) > >>Or somebody found the way to multiply the number of pins > >>without exploding the F-Chip's cost ?... > >> > >> > >I still prefer high-speed serial links. > > > we can't access this technology, or the die's price climbs. > ???? N'importe quoi ! (Irgenwas ?) The lvds link run ar 600 Mhz/pin. 1Ghz will be soon reach. 10 Ghz is plan. We can use this for connecting F-cpu like Athlon 64 does (no big and fat routing chip that cost a lot and add latency like a northbridge in PC chipset). But technology like hypertransport could be cheaper because you could reuse a lot of test material and module done for it. "Standard" is always cheaper. > > Something that's compatible > >with one of the existing serial "buses" would be even better. But... > > > > > yep, you named it. > eing compatible with Intel and other has some risks .... > The foundry will have to pay the licence but it could be cheaper that create all new design for such bus. > > >>>Too bad that 8b/10b encoding and other good stuff are patented. > >>> > >>Well, i have thought for a long time about an oversampled synchronous > >>communication path. > >>But the maths behind it are too tough for me :-( > >> > >> > >Hmm... what exactly do you have in mind? Dump your brain to my > >standard input, please :) > > > But not in public. > It's an old idea (3 or 4 years ?) > but i want to be the first to find the solution ;-) > You want to create digital modulation put in a wire ? LVDS + data driven transfert (the clock came from the sender and not from a global clock so you could manage the jitter) do a pretty well job at 1 Ghz ! And it don't need modulation/demodulation module to be used. nicO > YG > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Jan 24 18:08:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5MC-0006tO-00 for ; Fri, 24 Jan 2003 16:03:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:03:00 +0100 (CET) Received: (qmail 8857 invoked by uid 0); 24 Jan 2003 13:10:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 24 Jan 2003 13:10:38 -0000 Received: by moria.seul.org (Postfix) id 4749733DF8; Fri, 24 Jan 2003 08:10:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA8AE33E01; Fri, 24 Jan 2003 08:10:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 1DA6C33DF8 for ; Fri, 24 Jan 2003 08:10:36 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 7168762E1C for ; Fri, 24 Jan 2003 14:10:34 +0100 (CET) To: Subject: Re: [f-cpu] x86-64 long article From: Date: Fri, 24 Jan 2003 14:08:48 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030124131034.7168762E1C@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Yann Guidon a écrit : > hi, > > nico@seul.org > wrote: > > >Yann Guidon &lang=fr">whygee@f-cpu.org> > a écrit : > > > >>hi ! > >> > >>(maybe we can go to the francomoule's tribune ?) > >> > >> > It didn't seem to work anyway ... > > >>Michael Riepe wrote: > >> > >>>On Fri, Jan 24, 2003 at 01:01:27AM +0100, Yann Guidon wrote: > >>>[...] > >>> > >>>>>Sounds like the return of the G-chip... > >>>>> > >>>>was it ever away ? > >>>> > >>>Haven't heard from it for a long time... > >>> > >>> > >>i don't like to speak about things that drive people crazy :-) > >> > >:) If you want more than 8 fcpu in a single machine use multicore chip ! :) > > > > > and if we want more than 8 chips ? > much too expensive. > If the introduction frequency is around the realistic (but not easy anyway) > frequency of 200MHz, then at that time 3.2 GHz CPUs will be common place > and you will need 16 CPU to catch up in MHz rating. > Yuo want use 8 chip to catch the actual 3.5 Ghz cpu ??? But it will be much slower and far more expensive ! > >>>>Or somebody found the way to multiply the number of pins > >>>>without exploding the F-Chip's cost ?... > >>>> > >>>I still prefer high-speed serial links. > >>> > >>we can't access this technology, or the die's price climbs. > >> > >???? N'importe quoi ! (Irgenwas ?) > > > >The lvds link run ar 600 Mhz/pin. 1Ghz will be soon reach. 10 Ghz is plan. > > > Like F-CPU. Like what ? > But F-CPU should be able to run on 'old' technologies. > Do you believe that 10Ghz links will be possible using .35u ? > Ouch. 0.35 will run f-cpu at 100 mhz ! 10 Ghz will be for 0.13 or 0.09 µm technology. > > We can use this for connecting F-cpu like Athlon 64 does (no big and fat > routing chip that cost a lot and add latency like a northbridge in PC > chipset). > > > > > hmmm LVDS needs 2 pins, so it's the same bandwidth as 2 pins at 300MHz. > :) you never put 300 Mhz in a none differentiel pin ! > Plus, if you use serial encoding, there is more latency for a single packet. That's true but it's much easier to route. Don't forget that each line must have the same lentgh and the impendance (if one via is taken all wire must take one via at the same distance of the pad). Life is a bitch... > > >But technology like hypertransport could be cheaper because you could reuse a > lot of test material and module done for it. "Standard" is always cheaper. > > > > > oh yes, AMD will allow us to use their test equipments .... Why Amd ? All the foundry that use hypertransport (all chipset maker for example that use Taïwanies fab) > > > >>>Something that's compatible > >>>with one of the existing serial "buses" would be even better. But... > >>> > >>yep, you named it. > >>eing compatible with Intel and other has some risks .... > >> > >The foundry will have to pay the licence but it could be cheaper that create > all new design for such bus. > > > > > AMD and Intel are slowly switching to .13u, > this is not possible to use it unless you make millions of chips. Almost true. It will depend how much work have those fab (it will not speach to build only 1000 chip if they use 90% of the fab capacity) > > "old fabs" or production lines using .35u is more realistic > because their masks are not as expensive and the lines' costs > have been amortized. > Sure, but 0.35 µm is really slow. And will cost a lot for big area (question of yield). Don't forget that for chip produice at millions of unit the cost of a single transistor is less and less expansive each years (moore's law : the double amount of transistor each 18 month for the same price). > >>>>>Too bad that 8b/10b encoding and other good stuff are patented. > >>>>> > >>>>Well, i have thought for a long time about an oversampled synchronous > >>>>communication path. > >>>>But the maths behind it are too tough for me :-( > >>>> > >>>> > >>>Hmm... what exactly do you have in mind? Dump your brain to my > >>>standard input, please :) > >>> > >>But not in public. > >>It's an old idea (3 or 4 years ?) > >>but i want to be the first to find the solution ;-) > >> > > > >You want to create digital modulation put in a wire ? > > > ??? > You wrote many years times ago about a trick from a tape reader tehcnology. > > >LVDS + data driven transfert (the clock came from the sender > > > > and not from a global clock so you could manage the jitter) > > > isn't this also called "source clocking" or something like that ? > > > do a pretty well job at 1 Ghz ! And it don't need > > > > modulation/demodulation module to be used. > > > > > One prolem i have found with current technology is the > "negociation" of the frequency between two different devices. > Source clocking is one of the answers but it's not enough. > At that speed the component are on the same board, so there is no frequency negociation it's build'in. And source clocking do the job what is you're problem ? nicO > > >nicO > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 24 13:08:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5Lp-0006tO-00 for ; Fri, 24 Jan 2003 16:02:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:02:37 +0100 (CET) Received: (qmail 11981 invoked by uid 0); 24 Jan 2003 11:53:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 24 Jan 2003 11:53:01 -0000 Received: by moria.seul.org (Postfix) id 9528433DFC; Fri, 24 Jan 2003 06:53:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CC6AA33E03; Fri, 24 Jan 2003 06:52:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 126C833DFC for ; Fri, 24 Jan 2003 06:52:59 -0500 (EST) Received: from f-cpu.org (lcbv1-1-53.n.club-internet.fr [213.44.3.53]) by relay-2m.club-internet.fr (Postfix) with ESMTP id C96C616C2 for ; Fri, 24 Jan 2003 12:52:56 +0100 (CET) Message-ID: <3E312CBF.6060602@f-cpu.org> Date: Fri, 24 Jan 2003 13:08:31 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030124092709.5B66062E43@mallaury.noc.nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico@seul.org wrote: >Yann Guidon a écrit : > >>hi ! >> >>(maybe we can go to the francomoule's tribune ?) >> >> It didn't seem to work anyway ... >>Michael Riepe wrote: >> >>>On Fri, Jan 24, 2003 at 01:01:27AM +0100, Yann Guidon wrote: >>>[...] >>> >>>>>Sounds like the return of the G-chip... >>>>> >>>>was it ever away ? >>>> >>>Haven't heard from it for a long time... >>> >>> >>i don't like to speak about things that drive people crazy :-) >> >:) If you want more than 8 fcpu in a single machine use multicore chip ! :) > > and if we want more than 8 chips ? If the introduction frequency is around the realistic (but not easy anyway) frequency of 200MHz, then at that time 3.2 GHz CPUs will be common place and you will need 16 CPU to catch up in MHz rating. >>>>Or somebody found the way to multiply the number of pins >>>>without exploding the F-Chip's cost ?... >>>> >>>I still prefer high-speed serial links. >>> >>we can't access this technology, or the die's price climbs. >> >???? N'importe quoi ! (Irgenwas ?) > >The lvds link run ar 600 Mhz/pin. 1Ghz will be soon reach. 10 Ghz is plan. > Like F-CPU. But F-CPU should be able to run on 'old' technologies. Do you believe that 10Ghz links will be possible using .35u ? > We can use this for connecting F-cpu like Athlon 64 does (no big and fat routing chip that cost a lot and add latency like a northbridge in PC chipset). > > hmmm LVDS needs 2 pins, so it's the same bandwidth as 2 pins at 300MHz. Plus, if you use serial encoding, there is more latency for a single packet. >But technology like hypertransport could be cheaper because you could reuse a lot of test material and module done for it. "Standard" is always cheaper. > > oh yes, AMD will allow us to use their test equipments .... >>>Something that's compatible >>>with one of the existing serial "buses" would be even better. But... >>> >>yep, you named it. >>eing compatible with Intel and other has some risks .... >> >The foundry will have to pay the licence but it could be cheaper that create all new design for such bus. > > AMD and Intel are slowly switching to .13u, this is not possible to use it unless you make millions of chips. "old fabs" or production lines using .35u is more realistic because their masks are not as expensive and the lines' costs have been amortized. >>>>>Too bad that 8b/10b encoding and other good stuff are patented. >>>>> >>>>Well, i have thought for a long time about an oversampled synchronous >>>>communication path. >>>>But the maths behind it are too tough for me :-( >>>> >>>> >>>Hmm... what exactly do you have in mind? Dump your brain to my >>>standard input, please :) >>> >>But not in public. >>It's an old idea (3 or 4 years ?) >>but i want to be the first to find the solution ;-) >> > >You want to create digital modulation put in a wire ? > ??? >LVDS + data driven transfert (the clock came from the sender > > and not from a global clock so you could manage the jitter) > isn't this also called "source clocking" or something like that ? > do a pretty well job at 1 Ghz ! And it don't need > > modulation/demodulation module to be used. > > One prolem i have found with current technology is the "negociation" of the frequency between two different devices. Source clocking is one of the answers but it's not enough. >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 24 04:40:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5M8-0006tO-00 for ; Fri, 24 Jan 2003 16:02:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:02:56 +0100 (CET) Received: (qmail 19887 invoked by uid 0); 24 Jan 2003 12:24:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 24 Jan 2003 12:24:38 -0000 Received: by moria.seul.org (Postfix) id 746D733E01; Fri, 24 Jan 2003 07:24:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1A19633E04; Fri, 24 Jan 2003 07:24:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a077.home.uni-hannover.de [130.75.232.77]) by moria.seul.org (Postfix) with ESMTP id 84D1533E01 for ; Fri, 24 Jan 2003 07:24:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id EAA09779; Fri, 24 Jan 2003 04:40:03 +0100 Message-ID: <20030124044003.15344@thrai.stud.uni-hannover.de> Date: Fri, 24 Jan 2003 04:40:03 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Another simulator! References: <3E301B30.4010401@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E301B30.4010401@f-cpu.org>; from Yann Guidon on Thu, Jan 23, 2003 at 05:41:20PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Jan 23, 2003 at 05:41:20PM +0100, Yann Guidon wrote: [...] > Note that in order to be both attractive and efficiently coded, > one has to take ultra-wide register sizes from the start. [...] I tried to, but I don't know if I got everything right. E.g. will special registers grow as well? What does loadaddr calculate when general registers are wider than 64 bits? Will loadconsx really sign-extend to the full register size, or only to 64 bits? Will `jmp r1, r2' ignore the high part of r1, and will it clear or sign-extend the value put into r2? Or maybe copy the remaining bits from r1? Lots of questions. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From poster@seul.org Fri Jan 24 14:33:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18c5MK-0006tO-00 for ; Fri, 24 Jan 2003 16:03:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 16:03:08 +0100 (CET) Received: (qmail 7794 invoked by uid 0); 24 Jan 2003 13:30:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 24 Jan 2003 13:30:00 -0000 Received: by moria.seul.org (Postfix) id D576033E07; Fri, 24 Jan 2003 08:29:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 88CB733E09; Fri, 24 Jan 2003 08:29:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from CVP (unknown [202.54.128.5]) by moria.seul.org (Postfix) with SMTP id 434D833E07 for ; Fri, 24 Jan 2003 08:29:53 -0500 (EST) InterScan-Notification: yes From: poster@seul.org To: "f-cpu@seul.org"@seul.org Subject: [f-cpu] Notification Date: Fri, 24 Jan 2003 19:03:44 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1043415224_B78506032.R82506026" Message-Id: <20030124132953.434D833E07@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_000_1043415224_B78506032.R82506026 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ************* eManager Notification ************** Source mailbox: "f-cpu@seul.org" Destination mailbox(es): "f-cpu@seul.org" ******************* End of message ******************* ------=_NextPart_000_1043415224_B78506032.R82506026 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Received: from ([198.138.182.2]) by hexaware; Fri, 24 Jan 2003 18:56:09 +0530 (IST) Received: from ws_firewall ([192.168.16.2]) by mail.hexaware.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 24 Jan 2003 08:25:18 -0500 Received: from ruebert.ieee.org ([140.98.193.10]) by ws_firewall; Fri, 24 Jan 2003 -0800 (Pacific Standard Time) Received: from orion3.ieee.org (gemini4.ieee.org [140.98.193.189]) by ruebert.ieee.org (Switch-2.2.4/Switch-2.2.4) with ESMTP id h0ODT2n19906; Fri, 24 Jan 2003 08:29:02 -0500 (EST) Received: from moria.seul.org (MORIA.MIT.EDU [18.244.0.188]) by orion3.ieee.org (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0ODAa606813; Fri, 24 Jan 2003 08:10:36 -0500 (EST) Received: by moria.seul.org (Postfix) id 4749733DF8; Fri, 24 Jan 2003 08:10:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BA8AE33E01; Fri, 24 Jan 2003 08:10:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 1DA6C33DF8 for ; Fri, 24 Jan 2003 08:10:36 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 7168762E1C for ; Fri, 24 Jan 2003 14:10:34 +0100 (CET) To: Subject: Re: [f-cpu] x86-64 long article From: Date: Fri, 24 Jan 2003 14:08:48 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030124131034.7168762E1C@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu Return-Path: owner-f-cpu-outgoing@seul.org X-OriginalArrivalTime: 24 Jan 2003 13:25:18.0656 (UTC) FILETIME=[09D54C00:01C2C3AC] ------=_NextPart_000_1043415224_B78506032.R82506026-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 25 20:33:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cBk4-000363-00 for ; Fri, 24 Jan 2003 22:52:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 22:52:04 +0100 (CET) Received: (qmail 23055 invoked by uid 0); 24 Jan 2003 18:44:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 24 Jan 2003 18:44:14 -0000 Received: by moria.seul.org (Postfix) id B08DB33C6D; Fri, 24 Jan 2003 13:44:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2895B33DFE; Fri, 24 Jan 2003 13:44:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 87F5B33C6D for ; Fri, 24 Jan 2003 13:44:12 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id C18C162E1B for ; Fri, 24 Jan 2003 19:44:09 +0100 (CET) Date: Sat, 25 Jan 2003 19:33:17 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] Another simulator! Message-Id: <20030125193317.13a19169.nicolas.boulay@ifrance.com> In-Reply-To: <20030124044003.15344@thrai.stud.uni-hannover.de> References: <3E301B30.4010401@f-cpu.org> <20030124044003.15344@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 24 Jan 2003 04:40:03 +0100 Michael Riepe wrote: > On Thu, Jan 23, 2003 at 05:41:20PM +0100, Yann Guidon wrote: > [...] > > Note that in order to be both attractive and efficiently coded, > > one has to take ultra-wide register sizes from the start. > [...] > > I tried to, but I don't know if I got everything right. E.g. will > special registers grow as well? What does loadaddr calculate when > general registers are wider than 64 bits? Will loadconsx really > sign-extend to the full register size, or only to 64 bits? Will `jmp > r1, r2' ignore the >From the beginning of the story, register could grow but the size of the manipulated date stay at 64 bits. It's only for SIMD stuff (256=4*64). So there is no real question from my point of view. nicO > high part of r1, and will it clear or sign-extend the value put into > r2? Or maybe copy the remaining bits from r1? > > Lots of questions. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jan 24 21:39:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cBk9-000363-00 for ; Fri, 24 Jan 2003 22:52:09 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 22:52:09 +0100 (CET) Received: (qmail 25801 invoked by uid 0); 24 Jan 2003 20:24:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 24 Jan 2003 20:24:24 -0000 Received: by moria.seul.org (Postfix) id 0C4E033DA5; Fri, 24 Jan 2003 15:24:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5810F33DF5; Fri, 24 Jan 2003 15:24:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 3049A33CD3 for ; Fri, 24 Jan 2003 15:24:12 -0500 (EST) Received: from f-cpu.org (lcbv3-2-21.n.club-internet.fr [213.44.101.21]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 82CB416DB for ; Fri, 24 Jan 2003 21:24:10 +0100 (CET) Message-ID: <3E31A492.9080402@f-cpu.org> Date: Fri, 24 Jan 2003 21:39:46 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Another simulator! References: <3E301B30.4010401@f-cpu.org> <20030124044003.15344@thrai.stud.uni-hannover.de> <20030125193317.13a19169.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Fri, 24 Jan 2003 04:40:03 +0100 >Michael Riepe wrote: > >>On Thu, Jan 23, 2003 at 05:41:20PM +0100, Yann Guidon wrote: >>[...] >> >> >>>Note that in order to be both attractive and efficiently coded, >>>one has to take ultra-wide register sizes from the start. >>> >>> >>[...] >> >>I tried to, but I don't know if I got everything right. E.g. will >>special registers grow as well? What does loadaddr calculate when >>general registers are wider than 64 bits? Will loadconsx really >>sign-extend to the full register size, or only to 64 bits? Will `jmp >>r1, r2' ignore the >> >> > >>From the beginning of the story, register could grow but the size of the >manipulated date stay at 64 bits. It's only for SIMD stuff (256=4*64). > >So there is no real question from my point of view. > >nicO > > I know that a lot of details must be examined, but it is also clear for me that SRs have the same size as normal registers. Otherwise it cuts all the extensibility and orthogonality of the architecture. Basicly, SRs are accessed with GET and PUT, with no size parameter, this means that the whole register is written or read from/to the designated SR. For me, 64-bit data are only a "base size" or a "least common denominator". YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Jan 24 22:00:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cBkA-000363-01 for ; Fri, 24 Jan 2003 22:52:10 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 22:52:10 +0100 (CET) Received: (qmail 15389 invoked by uid 0); 24 Jan 2003 21:06:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 24 Jan 2003 21:06:16 -0000 Received: by moria.seul.org (Postfix) id 8DDDB33D0C; Fri, 24 Jan 2003 16:06:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0C7CE33DE0; Fri, 24 Jan 2003 16:06:14 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4139733D0C for ; Fri, 24 Jan 2003 16:06:13 -0500 (EST) Received: from a24-137.dialup.iol.cz ([194.228.137.24] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18cB1Y-0002HB-00 for f-cpu@seul.org; Fri, 24 Jan 2003 22:06:05 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18cAwa-0000VJ-00 for f-cpu@seul.org; Fri, 24 Jan 2003 22:00:56 +0100 Date: Fri, 24 Jan 2003 22:00:56 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] x86-64 long article In-Reply-To: <20030124092709.5B66062E43@mallaury.noc.nerim.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > :) If you want more than 8 fcpu in a single machine use multicore chip ! :) Hmm .. Their Opteron or NUMA in general is good because of independent memory access. With multicore and limited pin count what to do ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sat Jan 25 23:04:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cBkB-000363-01 for ; Fri, 24 Jan 2003 22:52:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Jan 2003 22:52:11 +0100 (CET) Received: (qmail 27577 invoked by uid 0); 24 Jan 2003 21:15:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 24 Jan 2003 21:15:47 -0000 Received: by moria.seul.org (Postfix) id 3871433CCF; Fri, 24 Jan 2003 16:15:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9C62D33DA5; Fri, 24 Jan 2003 16:15:45 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 30CBB33CCF for ; Fri, 24 Jan 2003 16:15:45 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id E2FDD410E9 for ; Fri, 24 Jan 2003 22:15:42 +0100 (CET) Date: Sat, 25 Jan 2003 22:04:49 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article Message-Id: <20030125220449.314832eb.nicolas.boulay@ifrance.com> In-Reply-To: References: <20030124092709.5B66062E43@mallaury.noc.nerim.net> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 24 Jan 2003 22:00:56 +0100 (CET) devik wrote: > > > > :) If you want more than 8 fcpu in a single machine use multicore > > chip ! :) > > Hmm .. Their Opteron or NUMA in general is good because > of independent memory access. > With multicore and limited pin count what to do ? > Share the L2/ L3 caches. It's a whole new way of doing optimising (tight multithreading) but it could work nice. > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jan 24 16:11:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cUbz-0003kq-00 for ; Sat, 25 Jan 2003 19:00:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 25 Jan 2003 19:00:59 +0100 (CET) Received: (qmail 16722 invoked by uid 0); 24 Jan 2003 23:19:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 24 Jan 2003 23:19:23 -0000 Received: by moria.seul.org (Postfix) id C9D0A33CCF; Fri, 24 Jan 2003 18:19:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDE2133D9E; Fri, 24 Jan 2003 18:19:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a171.home.uni-hannover.de [130.75.232.171]) by moria.seul.org (Postfix) with ESMTP id D172333CCF for ; Fri, 24 Jan 2003 18:19:18 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00904; Fri, 24 Jan 2003 16:11:14 +0100 Message-ID: <20030124161114.38193@thrai.stud.uni-hannover.de> Date: Fri, 24 Jan 2003 16:11:14 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] F-CPU gcc CVS References: <20030123143356.45361@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Jan 24, 2003 at 08:52:18AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi! > > You mean, call `int 0x80' directly on an Intel box? I'd rather stick > > to the libc interface that I use now. > > It is cleaner of course - but the almost all syscalls should > be implemented to be able to run with native libc. And implementing > about 100 syscalls will take some time .. > Maybe there could be transition phase - use int80, focus on linker > and emulator and later substitute syscalls one by one .. Using int 0x80 will take some time as well. Remember that I'll have to convert arguments and return values from 32 to 64 bits and vice versa, check pointer ranges and the like - I don't want the emulated CPU to access the emulator's memory, for example. Even worse, it's not portable - when I want to run the emulator on an Alpha, SPARC or Itanium2 box (or on an Intel CPU running another operating system), I can't use int 0x80. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 25 10:30:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cUcb-0003kq-00 for ; Sat, 25 Jan 2003 19:01:37 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 25 Jan 2003 19:01:37 +0100 (CET) Received: (qmail 25641 invoked by uid 0); 25 Jan 2003 09:15:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 25 Jan 2003 09:15:00 -0000 Received: by moria.seul.org (Postfix) id 6205D33D14; Sat, 25 Jan 2003 04:14:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 591D333CF8; Sat, 25 Jan 2003 04:14:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 757A633D14 for ; Sat, 25 Jan 2003 04:14:52 -0500 (EST) Received: from f-cpu.org (lcbv4-2-79.n.club-internet.fr [213.44.93.79]) by relay-2m.club-internet.fr (Postfix) with ESMTP id A6EC91827 for ; Sat, 25 Jan 2003 10:14:50 +0100 (CET) Message-ID: <3E32592F.3050503@f-cpu.org> Date: Sat, 25 Jan 2003 10:30:23 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article References: <20030124092709.5B66062E43@mallaury.noc.nerim.net> <20030125220449.314832eb.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! nico wrote: >On Fri, 24 Jan 2003 22:00:56 +0100 (CET) >devik wrote: > >>>:) If you want more than 8 fcpu in a single machine use multicore >>>chip ! :) >>> >>> >>Hmm .. Their Opteron or NUMA in general is good because >>of independent memory access. >>With multicore and limited pin count what to do ? >> > >Share the L2/ L3 caches. It's a whole new way of doing optimising >(tight multithreading) but it could work nice. > > Alright, but then, when the core needs to communicate, all the pins' bandwidth will be saturated. Look at the Opteron's 1000 pins and ask yourself how much this will cost .... It's the OLD problem of a system's "cut" and the non linear ratio between the gate count and the pin count .... this is my major problem. I believe that this will put a limit to 4 FC0s on a single chip. Looking at other numers, i think that half of the die's surface will contain L2 and L3 and it's good, despite the high fabrication cost. But adding too many cores will suffocate the whole chip. On top of that, a lot of software will need major rewrites to include finer multithreading. Furthermore, even if we run at only 100MHz on an old technology, this will be an incredible success for freedom, for the "alternate computing" world and for us in general. Extreme performance will come naturally later, we only have to make one core work and others will want to join. So let's concentrate on the critical things, as we will be able to play with top technology later :-) bon week-end, >>devik >> >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Sat Jan 25 11:51:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cUd5-0003kq-00 for ; Sat, 25 Jan 2003 19:02:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 25 Jan 2003 19:02:07 +0100 (CET) Received: (qmail 30300 invoked by uid 0); 25 Jan 2003 10:51:18 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 25 Jan 2003 10:51:18 -0000 Received: by moria.seul.org (Postfix) id F332033CF8; Sat, 25 Jan 2003 05:51:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 598CF33D0C; Sat, 25 Jan 2003 05:51:17 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from hell.mpoli.fi (hell.mpoli.fi [62.236.132.10]) by moria.seul.org (Postfix) with ESMTP id 10C3733CF8 for ; Sat, 25 Jan 2003 05:51:16 -0500 (EST) Received: from hell.mpoli.fi (hell.mpoli.fi [127.0.0.1]) by hell.mpoli.fi (8.12.5/8.12.5) with ESMTP id h0PApEXI026254 for ; Sat, 25 Jan 2003 12:51:14 +0200 Received: from localhost (embo@localhost) by hell.mpoli.fi (8.12.5/8.12.5/Submit) with ESMTP id h0PApBDl021522 for ; Sat, 25 Jan 2003 12:51:14 +0200 Date: Sat, 25 Jan 2003 12:51:11 +0200 (EET) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article In-Reply-To: <3E312CBF.6060602@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 24 Jan 2003, Yann Guidon wrote: > >The lvds link run ar 600 Mhz/pin. 1Ghz will be soon reach. 10 Ghz is plan. > > > Like F-CPU. > But F-CPU should be able to run on 'old' technologies. > Do you believe that 10Ghz links will be possible using .35u ? At least 3.125GHz links are available for 0.18u process from many vendors. If I remember correctly at 0.35u maximal link speed was ~1GHz. But these cores are always fullcustom blocks, usually available from the vendor. > > We can use this for connecting F-cpu like Athlon 64 does (no big and fat routing chip that cost a lot and add latency like a northbridge in PC chipset). > > > > > hmmm LVDS needs 2 pins, so it's the same bandwidth as 2 pins at 300MHz. I'd like to see how you handle all the problems related to 300MHz single ended pin. Even >150MHz signaling needs quite careful design if it is single ended (careful layout, PCB design, some PLL tricks etc.) On the other hand 600MHz LVDS link is normal old technology and is easy to route at PCB level. And by using for example PCML signaling higer speeds are possible. For example 50cm with FR4 PCB and 3.125G PCML link is easily possible. Even at 0.18u you can put ~50-60 of these links to a single die with standard CMOS process. Of course high speed links need BGA packaging to handle impedance and other problems. > Plus, if you use serial encoding, there is more latency for a single packet. On the other hand serial links are much easier to handle at board level. Wide fast busses are a nightmare for PCB designer. > >But technology like hypertransport could be cheaper because you could reuse a lot of test material and module done for it. "Standard" is always cheaper. > > > > > oh yes, AMD will allow us to use their test equipments .... You can get HT stuff from many vendors (measurement equipment, cores etc.) > AMD and Intel are slowly switching to .13u, > this is not possible to use it unless you make millions of chips. Some fabs are selling 0.11u silicon already. The biggest cost are the masks, you can make a buisiness case also for low volume chips, but the chip has to be expensive. > >>>>>Too bad that 8b/10b encoding and other good stuff are patented. As far as I know 8b/10b is not patented. There are some patents that cover few ways to implement the coding. On the other hand if speed is everything there are other ways to do byte and frame alignment even without bandwidth loss. > One prolem i have found with current technology is the > "negociation" of the frequency between two different devices. > Source clocking is one of the answers but it's not enough. Source clocking is quite easy way to do it at high speeds, especially if the sources have all own crystals and speed compensations between links has to be done. -- ============================================================================= Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian Vasamatie 1 C 16 | IRC: embo | curved-space fault in 02630 Espoo | | write-only file system ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Jan 26 15:39:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cUdI-0003kq-00 for ; Sat, 25 Jan 2003 19:02:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 25 Jan 2003 19:02:20 +0100 (CET) Received: (qmail 24856 invoked by uid 0); 25 Jan 2003 13:50:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 25 Jan 2003 13:50:39 -0000 Received: by moria.seul.org (Postfix) id A1D7533D01; Sat, 25 Jan 2003 08:50:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DB34033D83; Sat, 25 Jan 2003 08:50:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 2BD2D33D01 for ; Sat, 25 Jan 2003 08:50:37 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id CA17F62E1A for ; Sat, 25 Jan 2003 14:50:34 +0100 (CET) Date: Sun, 26 Jan 2003 14:39:44 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] x86-64 long article Message-Id: <20030126143944.0abe2193.nicolas.boulay@ifrance.com> In-Reply-To: <3E32592F.3050503@f-cpu.org> References: <20030124092709.5B66062E43@mallaury.noc.nerim.net> <20030125220449.314832eb.nicolas.boulay@ifrance.com> <3E32592F.3050503@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 25 Jan 2003 10:30:23 +0100 Yann Guidon wrote: > hi ! > > nico wrote: > > >On Fri, 24 Jan 2003 22:00:56 +0100 (CET) > >devik wrote: > > > >>>:) If you want more than 8 fcpu in a single machine use multicore > >>>chip ! :) > >>> > >>> > >>Hmm .. Their Opteron or NUMA in general is good because > >>of independent memory access. > >>With multicore and limited pin count what to do ? > >> > > > >Share the L2/ L3 caches. It's a whole new way of doing optimising > >(tight multithreading) but it could work nice. > > > > > > Alright, but then, when the core needs to communicate, all the pins' > bandwidth will be saturated. > Look at the Opteron's 1000 pins and ask yourself how much this will > cost .... And half are Vcc/Gnd pin... (1A/pin max i beleive) > It's the OLD problem of a system's "cut" and the non linear ratio > between the gate count > and the pin count .... this is my major problem. yep. > I believe that this will put a limit to 4 FC0s on a single chip. Where come this number ?? > Looking at other numers, i think that half of the die's surface will > contain L2 and L3 and it's > good, despite the high fabrication cost. But adding too many cores > will suffocate the whole chip. What do you comparre ?? What is better : 2 cpus with it's own memory bank (NUMA as the poteron) or 2 cpu on the same die (thight SMP)? The first system will be much much costly than the second. Because you need to split the memory bank and you have 2 cpu on your main board (even if the second cpu is bigger, the cost of the complete system will be much higher). Which one is the fastest system ? You try to explain that the second solution will be the fastest because you have the double of memory bandwith. But it will depend on the load. In the second system, you could have more cache so a single thread could run faster. In a NUMA system, the communication between node are a nightmarre and could kill your system. So it's not evident at all for the same amount of money which one is the best. If this amount is quite low, mono cpu design is much more interresting. After it depend if you can't double the bandwith of the single die (using 256 bits data path instead of 128). > On top of that, a lot of software will need major rewrites to include > finer multithreading. That's true. But thight SMP or SMT (P4 3.06 Ghz for example) have the same problem. And maybe we could find compiler that could handle 2 cpu at the same time. If the memory are shared is much easier to do. There is no communication penalty. > > Furthermore, even if we run at only 100MHz on an old technology, this > will be an incredible > success for freedom, for the "alternate computing" world and for us in > general. Extreme > performance will come naturally later, we only have to make one core > work and others > will want to join. So let's concentrate on the critical things, as we > will be able > to play with top technology later :-) > yep. nicO > bon week-end, > > >>devik > >> > >> > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me464639@members.interq.or.jp Sat Jan 25 15:24:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cUdS-0003kq-00 for ; Sat, 25 Jan 2003 19:02:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 25 Jan 2003 19:02:30 +0100 (CET) Received: (qmail 2343 invoked by uid 0); 25 Jan 2003 14:26:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 25 Jan 2003 14:26:20 -0000 Received: by moria.seul.org (Postfix) id 2683133C95; Sat, 25 Jan 2003 09:26:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 95BC533D44; Sat, 25 Jan 2003 09:26:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from vasa (pl752.nas927.o-tokyo.nttpc.ne.jp [61.197.108.240]) by moria.seul.org (Postfix) with ESMTP id 016D233C95 for ; Sat, 25 Jan 2003 09:26:16 -0500 (EST) Received: from wing-q79g21omjt ([192.168.0.2]) by vasa (8.9.3+3.2W/3.7W) with SMTP id XAA31846; Sat, 25 Jan 2003 23:24:52 +0900 Message-Id: <200301251424.XAA31846@vasa> From: =?iso-2022-jp?B?bWU0NjQ2Mzk=?= To: =?iso-2022-jp?B?c2hpbnNoaW4=?=@vasa.seul.org Date: Sat, 25 Jan 2003 23:24:26 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoJVclbSU4JSclLyVIGyhKMQ==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> ‚³‚í‚â‚©LŽÐ ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463886@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢ §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@090-3878-3581 FAX@03-3544-6218@@ ™\\\™\\\™\\\™\\\™\\\™\\\™ ‚±‚̃[ƒ‹‚ðŽó‚¯Žæ‚ç‚ꂽ•ûA1’ʂɂ‚«100‰~·‚µã‚°‚Ü‚·B 5000‰~•ª’™‚Ü‚è‚Ü‚µ‚½‚犷‹à’v‚µ‚Ü‚·‚Ì‚Å‚²¿‹‰º‚³‚¢B @@š@ƒoƒi[‚ð‚Í‚Á‚ĉº‚³‚é•û•åW‚µ‚Ü‚·I@š ”„‚èã‚°‚Ì10“‚ði’悵‚Ü‚·B Å’á•Ûá‚Æ‚µ‚ÄŒŽŠz10–œ‰~AŒŽ‚É50–œ‰~‚ÍŠmŽÀ‚Å‚·B ™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu ‚`‚u’j—D•åWE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://61.207.157.48/ ™\\\™\\\™\\\™\\\™\\\™\\\™ ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽE–h”ƃOƒbƒYE‹à–ׂ¯î•ñ‚È‚Ç@ @@@š@‚»‚Ì‘¼î•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://61.207.157.48/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jan 25 23:15:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18cap8-0008Jy-01 for ; Sun, 26 Jan 2003 01:38:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 26 Jan 2003 01:38:58 +0100 (CET) Received: (qmail 29190 invoked by uid 0); 25 Jan 2003 22:00:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 25 Jan 2003 22:00:44 -0000 Received: by moria.seul.org (Postfix) id 1CA7D33CC7; Sat, 25 Jan 2003 17:00:44 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A52C533D0C; Sat, 25 Jan 2003 17:00:43 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 01DBB33CC7 for ; Sat, 25 Jan 2003 17:00:43 -0500 (EST) Received: from f-cpu.org (lcbv3-1-102.n.club-internet.fr [213.44.91.102]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 9201516EF for ; Sat, 25 Jan 2003 23:00:41 +0100 (CET) Message-ID: <3E330C9B.5000601@f-cpu.org> Date: Sat, 25 Jan 2003 23:15:55 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [don'tt read] Re: [f-cpu] x86-64 long article References: <20030124092709.5B66062E43@mallaury.noc.nerim.net> <20030125220449.314832eb.nicolas.boulay@ifrance.com> <3E32592F.3050503@f-cpu.org> <20030126143944.0abe2193.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! sorry, i couldn't resist nico wrote: >>Looking at other numers, i think that half of the die's surface will >>contain L2 and L3 and it's >>good, despite the high fabrication cost. But adding too many cores >>will suffocate the whole chip. >> >> >What do you comparre ?? What is better : 2 cpus with it's own memory >bank (NUMA as the poteron) or 2 cpu on the same die (thight SMP)? > > hmmmm after the Cassis, the Cassette, AMD does the Potiron .... What's next ? :-) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Credit_Doctor_497@charter.net Sat Feb 1 04:54:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18es2R-00038I-00 for ; Sat, 01 Feb 2003 08:26:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 01 Feb 2003 08:26:07 +0100 (CET) Received: (qmail 3176 invoked by uid 0); 1 Feb 2003 03:55:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 1 Feb 2003 03:55:23 -0000 Received: by moria.seul.org (Postfix) id B8F8C33DC9; Fri, 31 Jan 2003 22:55:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8779733DA0; Fri, 31 Jan 2003 22:55:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ns.logisroad.com (unknown [211.218.37.112]) by moria.seul.org (Postfix) with ESMTP id 9AA3C33C55 for ; Fri, 31 Jan 2003 22:55:17 -0500 (EST) Received: from smtp0201.mail.yahoo.com ([202.60.228.171]) by ns.logisroad.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 1 Feb 2003 12:52:11 +0900 Date: Sat, 1 Feb 2003 03:54:17 GMT From: "Iberinia" X-Priority: 3 To: f-cpu@seul.org Subject: [f-cpu] We Can Fix your Credit Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 01 Feb 2003 03:52:12.0988 (UTC) FILETIME=[4DAEBFC0:01C2C9A5] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N f-cpu@seul.org

We can fix your credit. We are very successful at getting bankruptcies, judgments, tax liens, foreclosures, late payments, charge-offs, repossessions, and even student loans removed from a persons credit report. To find out more go to http://www.cjlinc.net.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From usman1926@mailsurf.com Sun Feb 2 03:08:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18fOOI-0000Fw-01 for ; Sun, 02 Feb 2003 18:58:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 02 Feb 2003 18:58:50 +0100 (CET) Received: (qmail 21179 invoked by uid 0); 2 Feb 2003 02:08:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 2 Feb 2003 02:08:56 -0000 Received: by moria.seul.org (Postfix) id 7119233DAE; Sat, 1 Feb 2003 21:08:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0AC6833DE8; Sat, 1 Feb 2003 21:08:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mrson1887.com (unknown [217.78.76.157]) by moria.seul.org (Postfix) with SMTP id 3E22333DAE for ; Sat, 1 Feb 2003 21:08:49 -0500 (EST) From: "Barrister Usman Rabiu (LLB)." Date: Sun, 2 Feb 2003 03:08:34 +0100 Subject: [f-cpu] Urgent Request X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030202020849.3E22333DAE@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N URGENT REQUEST I am a Solicitor resident and practicing in Lagos=2C Nigeria and I am using this correspondence to urgently seek and request your assistance and cooperation in a sensitive but highly beneficial financial arrangement=2E An important client of mine whose details and person I cannot release at this point has implored me to contact a reliable and trustworthy partner overseas to urgently receive and handle funds total FIFTEEN MILLION US DOLLARS=28US$15=2EM=29in CASH presently lodged in a security=2Ffinance outfit in overseas=2E Due to my client inability to travel out of the country presently and the fact that we continue to accumulate huge debts daily as long as this consignment remains in the security=2Ffinance company we need an associate and partner to proceed as soon as possible to receive this funds for investment purpose as shall be instructed by my client=2E We have agreed in principle to give twenty-five percent =2825%=29 of the total sum to whom ever shall handle this funds for us while the remaining sixty-five percent =2865%=29shall be for my client and ten-percent =2810%=29 for me as the attorney=2E As soon as you are ready to proceed to receive this cash on our behalf we shall furnish you with the details and information you will need to accomplish this task=2E Please be rest assured that this arrangement is absolutely risk free And cannot implicate you in any way=2E However I implore you to handle this matter with urgency and utmost confidence even if you do not intend to execute the project for us=2E Whatever the case=2C please acknowledge receipt of this mail via the my Email address=2E If your response is positive we shall proceed immediately without any delay=2E Thank you in anticipation of your cooperation and hoping to hear from you soonest=2E Yours sincerely=2C Barrister Usman Rabiu =28LLB=29=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From smardl@yahoo.com Mon Feb 3 09:44:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18foYZ-0000GQ-01 for ; Mon, 03 Feb 2003 22:55:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 03 Feb 2003 22:55:11 +0100 (CET) Received: (qmail 17535 invoked by uid 0); 3 Feb 2003 08:45:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 3 Feb 2003 08:45:11 -0000 Received: by moria.seul.org (Postfix) id 43AA033D86; Mon, 3 Feb 2003 03:45:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F286D33E1D; Mon, 3 Feb 2003 03:45:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by moria.seul.org (Postfix) with ESMTP id CBED533D86 for ; Mon, 3 Feb 2003 03:45:06 -0500 (EST) Received: from smardl@yahoo.com ([66.130.76.199]) by VL-MS-MR002.sc1.videotron.ca (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with SMTP id <0H9Q00FBI5N4N5@VL-MS-MR002.sc1.videotron.ca> for f-cpu@seul.org; Mon, 03 Feb 2003 03:45:06 -0500 (EST) Date: Mon, 03 Feb 2003 03:44:56 -0500 From: Luc Simard Subject: [f-cpu] MONEY MAKING THAT WORKS!! To: "f-cpu@seul.org" Message-id: <4121686-2200321384456212%smardl@yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi,=20 Except of an error from my part, this should be the first time you receive= this=2E If not, please excuse me and disregard this message=2E My name is Luc, and I want to share with you a MONEY=20 MAKING PROGRAM that really works! At first, I was=20 sceptical too, and was thinking that this was some kind of=20 joke=2E That one would send money and never receive anything=2E=20 But I gave it a try anyway and IT REALLY WORKS!=20 MAKE 50,000$$$ IN LESS THAN 90 DAYS!=20 Thank you for your time and Interest=2E The following income opportunity=20= is one that can be started with VERY LITTLE investment and the income=20 return is TREMENDOUS!!!=20 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$=20 If you would like to make at least $50,000 in less than 90 days! Please=20= read the enclosed program=2E=2E=2E THEN READ IT AGAIN!!!=20 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$=20 At first, I was sceptical too, but I decided to give it a try and it=20 really WORK!=20 LEGITIMATE AND LEGAL=20 THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY=2E=20 It does not require you to come into contact with people,=20 do any hard work and best of all, you never have to leave=20 the house except to get the mail=2E If you believe that someday=20 you'll get that big break that you've been waiting for,=20 THIS IS IT! Simply follow the instructions,=20 and your dreams will come true=2E This e-mail marketing=20 program works perfectly=2E=2E=2E100%, EVERY TIME=2E E-mail is the=20 sales tool of the future=2E Take advantage of this=20 non-commercialized method of advertising NOW!!! The=20 longer you wait, the more people will be doing business using=20 e-mail=2E Get your piece of this program now!=20 MULTI-LEVEL MARKETING (MLM) has finally gained=20 respectability=2E It is being taught in the Harvard Business=20 School, both Stanford Research and the Wall Street=20 Journal have stated that between 50% and 65% of all goods=20 and services will be sold through multi-level methods by the=20 late 1990's=2E This is a Multi-Billion Dollar industry and of=20 the 500,000 millionaires in the U=2ES=2E, 20% (100,000) made=20 their fortune in the last few years in MLM=2E Moreover,=20 statistics show 45 people become millionaires everyday=20 through Multi-Level Marketing=2E=20 You may have heard this story before, but over the summer=20 Donald Trump made an appearance on the David Letterman=20 Show=2E Dave asked him what he would do if he lost=20 everything and had to start over from scratch=2E Without=20 hesitating, Trump said he would find a good network=20 marketing company and get to work=2E The audience started=20 to hoot and boo him=2E He looked out at the audience and=20 dead-panned his response - "That's why I'm sitting up here=20 and you are all sitting out there!"=20 With network marketing you have two sources of income=2E=20 Direct commissions from sales you make yourself and=20 commissions from sales made by people you introduce to the=20 business=2E=20 Residual income is the secret of the wealthy=2E It means=20 investing time or money once and getting paid again and=20 again and again=2E In network marketing, it also means getting=20 paid for the work of others=2E=20 The enclosed information is something I almost let slip=20 through my fingers=2E Fortunately, sometime later I re-read=20 everything and gave some thought and study to it=2E=20 My name is Ellie Gilbert=2E Two years ago, the=20 corporation I worked for, the past twelve years, down-sized=20 and my position was eliminated=2E After many unproductive job=20 interviews, I decided to open my own business=2E Over the=20 past year, I incurred many unforeseen financial problems=2E I=20 owed my family, friends and creditors over $40,000=2E=2E=20 I just couldn't seem to make ends meet=2E I had to refinance=20 and borrow against my home to support my family and=20 struggling business=2E AT THAT MOMENT something=20 significant happened in my life and I am writing to share=20 the experience in hopes that this will change your life,=20 FINANCIALLY, FOREVER!!!=20 In mid December, I received this program via e-mail=2E Six=20 month's prior to receiving this program I had been sending=20 away for information on various business opportunities=2E All of=20 the programs I received, in my opinion, were not cost=20 effective=2E They were either too difficult for me to=20 comprehend or the initial investment was too much for me to=20 risk to see if they would work or not=2E One claimed that I=20 would make a million dollars in one year=2E=2E=2Eit didn't tell me=20 I'd have to write a best selling book to make it!=20 But, as I was saying, in December of 1997 I received this=20 program=2E I didn't send for it, or ask for it, they just got my=20 name off a mailing list=2E THANK GOODNESS FOR THAT!=20 After reading it several times, to make sure I was reading it=20 correctly, I couldn't believe my eyes=2E Here was a MONEY=20 MAKING PHENOMENON=2E I could invest as much as I=20 wanted to start, without putting me further into debt=2E After I=20 got a pencil and paper and figured it out, I would at least get=20 my money back=2E But like most of you I was still a little=20 skeptical and a little worried about the legal aspects of it all=2E=20 So I checked it out with the U=2ES=2E Post Office (1-800-725-=20 2161 24-hrs) and they confirmed that it is indeed legal!=20 After determining the program was LEGAL and NOT A=20 CHAIN LETTER, I decided "WHY NOT=2E"=20 Initially I sent out 10,000 e-mails=2E The great thing=20 about e-mail is that I don't need any money for printing=20 to send out the program, and because=20 all of my orders are fulfilled via e-mail, the only expense is my=20 time=2E I'm telling you as it is, I hope it doesn't turn you off,=20 but I promised myself that I would not "rip-off" anyone, no=20 matter how much money it cost me=2E=20 In less than one week, I was starting to receive orders for=20 REPORT #1=2E By January 13, I had received 26 orders for=20 REPORT #1=2E=20 Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2=20 WEEKS=2E=20 If you don't, SEND OUT MORE PROGRAMS UNTIL YOU DO!"=20 My first step in making $50,000 in 90 days was done=2E=20 By January 30, I had received 196 orders for REPORT #2=2E=20 Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR=20 REPORT #2 WITHIN 2 WEEKS=2E IF NOT, SEND OUT=20 MORE PROGRAMS UNTIL YOU DO=2E ONCE YOU HAVE=20 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL=20 MAKE YOUR $50,000 GOAL=2E" Well, I had 196 orders for=20 REPORT #2, 96 more than I needed=2E So I sat back and=20 relaxed=2E=20 By March 1, of my e-mailing of 10,000, I received=20 $58,000 with more coming in every day=2E=20 I paid off ALL my debts and bought a much needed new car=2E=20 Please take time to read the attached program, IT WILL=20 CHANGE YOUR LIFE FOREVER! Remember, it won't=20 work if you don't try it=2E This program does work, but you must=20 follow it EXACTLY! Especially the rules of not trying to place=20 your name in a different place=2E It won't work, you'll lose out=20 on a lot of money! In order for this program to work, you=20 must meet your goal of 20+ orders for REPORT #1, and=20 100+ orders for REPORT #2 and you will make $50,000 or=20 more in 90 days=2E I AM LIVING PROOF THAT IT WORKS!=20 If you choose not to participate in this program, I am sorry=2E It=20 really is a great opportunity with little cost or risk to you=2E If=20 you choose to participate, follow the program and you will be=20 on your way to financial security=2E=20 If you are a business owner and in financial trouble,=20 as I was, or you want to start your own business, consider=20 this a good luck sign=2E I DID!=20 Sincerely,=20 Ellie Gilbert=20 P=2ES=2E Do you have any idea what $58,000 looks like=20 piled up on a kitchen table? IT'S AWESOME!=20 =20 A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:=20 By the time you have read the enclosed program and reports=20 you should have concluded that such a program, one=20 that is legal, could not have been created by an amateur=2E=20 Let me tell you a little about myself=2E I had a profitable=20 business for 10 years=2E Then in 1979 my business began=20 falling off=2E I was doing the same things that were previously=20 successful for me, but it wasn't working=2E Finally, I figured it=20 out=2E It wasn't me, it was the economy=2E Inflation and=20 recession had replaced the stable economy that had been=20 with us since 1945=2E I don't have to tell you what happened=20 to the unemployment rate=2E=2E=2E because many of you know from=20 first hand experience=2E There were more failures and=20 bankruptcies than ever before=2E=20 The middle class was vanishing=2E Those who knew what=20 they were doing invested wisely and moved up=2E Those who=20 did not, including those who never had anything to save or=20 invest, were moving down into the ranks of the poor=2E As the=20 saying goes, "THE RICH GET RICHER AND THE POOR=20 GET POORER=2E" The traditional methods of making money=20 will never allow you to "move up" or "get rich"=2E=20 You have just received information that can give you=20 financial freedom for the rest of your life, with "NO RISK" and=20 "JUST A LITTLE BIT OF EFFORT=2E" You can make more=20 money in the next few months than you have ever imagined=2E=20 I should also point out that I will not see a penny of this=20 money, nor anyone else who has provided a testimonial for=20 this program=2E I have already made over 4 MILLION=20 DOLLARS! I have retired from the program after sending out=20 over 16,000 programs=2E=20 Follow the program EXACTLY AS INSTRUCTED=2E Do not=20 change it in any way=2E It works exceedingly well as it is now=2E=20 Remember to e-mail a copy of this exciting report to everyone=20 you can think of=2E One of the people you send this to may=20 send out 50,000=2E=2E=2Eand your name will be on everyone of=20 them! Remember though, the more you send out the more=20 potential customers you will reach=2E=20 So my friend, I have given you the ideas, information,=20 materials and opportunity to become financially independent,=20 IT IS NOW UP TO YOU!=20 =20 HOW THIS AMAZING PROGRAM WORKS=20 HERE'S HOW THIS AMAZING PROGRAM WILL MAKE=20 YOU THOUSANDS OF DOLLARS=20 INSTRUCTIONS:=20 This method of raising capital REALLY WORKS 100 %,=20 EVERY TIME=2E I am sure that you could use up to $50,000 or=20 more in the next 90 days=2E Before you say "BULL=2E=2E=2E ", please=20 read this program carefully=2E=20 This is not a chain letter, but a perfectly legal money making=20 opportunity=2E Basically, this is what you do: As with all=20 multi-level businesses, we build our business by recruiting=20 new partners and selling our products=2E Every state in the=20 USA allows you to recruit new multi-level business partners,=20 and we offer a product for EVERY dollar sent=2E YOUR=20 ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so=20 you are not involved in personal selling=2E You do it privately in=20 your own home, store or office=2E This is the GREATEST Multi-=20 Level Mail Order Marketing anywhere:=20 This is what you MUST do:=20 1=2E Order all 4 reports shown on the list below (you can't sell=20 them if you don't order them)=2E=20 * For each report, send $5=2E00 CASH, the NAME &=20 NUMBER OF THE REPORT YOU ARE ORDERING,=20 YOUR E-MAIL ADDRESS, and YOUR NAME &=20 RETURN ADDRESS (in case of a problem) to the=20 person whose name appears on the list next to the=20 report=2E MAKE SURE YOUR RETURN ADDRESS IS=20 ON YOUR ENVELOPE IN CASE OF ANY MAIL=20 PROBLEMS!=20 * When you place your order, make sure you order each=20 of the four reports=2E You will need all four reports so=20 that you can save them on your computer and resell=20 them=2E=20 * Within a few days you will receive, via e-mail, each of=20 the four reports=2E Save them on your computer so they=20 will be accessible for you to send to the 1,000's of=20 people who will order them from you=2E=20 2=2E IMPORTANT-- DO NOT alter the names of the people=20 who are listed next to each report, or their sequence on=20 the list, in any way other than is instructed below in steps=20 "a" through "f" or you will lose out on the majority of your=20 profits=2E Once you understand the way this works, you'll=20 also see how it doesn't work if you change it=2E Remember,=20 this method has been tested, and if you alter it, it will not=20 work=2E=20 a=2E Look below for the listing of available reports=2E=20 b=2E After you've ordered the four reports, take this=20 letter and remove the name and address under=20 REPORT #4=2E This person has made it through the cycle=20 and is no doubt counting their $50,000!=20 c=2E Move the name and address under REPORT #3 down=20 to REPORT #4=2E=20 d=2E Move the name and address under REPORT #2 down=20 to REPORT #3=2E=20 e=2E Move the name and address under REPORT #1 down=20 to REPORT #2=2E=20 f=2E Insert your name/address in the REPORT #1 position=2E=20 Please make sure you copy every name and address ACCURATELY!=20 3=2E Take this entire letter, including the modified list of names,=20 and save it to your computer=2E Make NO changes to the=20 instruction portion of this letter=2E=20 4=2E Now you're ready to start an advertising campaign on the=20 WORLD WIDE WEB! SEND OUT THIS LETTER (with your name added)=20 TO AS MANY PEOPLE AS YOU CAN, EVEN FRIENDS AND FAMILY=2E=20 Advertising on the WEB can be very, very inexpensive, and=20 there are HUNDREDS of FREE places to advertise=2E Another=20 avenue which you could use for advertising is e-mail lists=2E=20 You can buy these lists for under $20/20,000 addresses or=20 you can pay someone to take care of it for you=2E BE SURE=20 TO START YOUR AD CAMPAIGN IMMEDIATELY!=20 5=2E For every $5=2E00 you receive, all you must do is e-mail=20 them the report they ordered=2E THAT'S IT! ALWAYS=20 PROVIDE SAME- DAY SERVICE ON ALL ORDERS!=20 This will help guarantee that the e-mail THEY send out,=20 with YOUR name and address on it, will be prompt=20 because they can't advertise until they receive the report!=20 To grow fast be prompt and courteous=2E=20 ------------------------------------------=20 AVAILABLE REPORTS=20 ------------------------------------------=20 ***Order Each REPORT by NUMBER and NAME***=20 Notes:=20 - ALWAYS SEND $5 CASH FOR EACH REPORT=20 - ALWAYS SEND YOUR ORDER VIA THE QUICKEST=20 DELIVERY=20 - Make sure the cash is concealed by wrapping it in at least=20 two sheets of paper=20 - On one of those sheets of paper, include: (a) the number &=20 name of the report you are ordering, (b) your e-mail address,=20 and (c) your postal address=2E=20 ________________________________________________=20 REPORT #1 "THE INSIDER=92S GUIDE TO ADVERTISING FOR FREE ON THE INTERNET=20= "=20 ORDER REPORT #1 FROM:=20 L=2E Simard=20 220 Louis=20 Ste-Sophie,QC=20 Canada J5J 2P3=20 ________________________________________________=20 REPORT #2 "THE INSIDER=92S GUIDE TO SENDING BULK E-MAIL ON THE INTERNET =AB= =20 ORDER REPORT #2 FROM:=20 K=2EVeilleux=20 386 av=2E du Parc=20 St-Antoine QC=20 Canada J7Z 7A1=20 ________________________________________________=20 REPORT #3 " THE SECRETS TO MULTILEVEL MARKETING ON THE INTERNET "=20 ORDER REPORT #3 FROM:=20 M=2E Magnan=20 205 Tessier=20 St-Casimir Qc=20 Canada Canada G0A 3L0=20 ________________________________________________=20 REPORT #4 "HOW TO BECOME A MILLIONAIRE UTULIZING THE POWER OF=20 MULTILEVEL MARKETING ON THE INTERNET "=20 ORDER REPORT #4 FROM:=20 E=2E Filion=20 316 ch=2E Bas Ste-Th=E9r=E8se=20 Blainville, Qc (Canada)=20 J7E 4H4=20 =20 -----------------------------------------------------------------------=20= HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$=20 -----------------------------------------------------------------------=20= Let's say you decide to start small just to see how well it=20 works=2E Assume your goal is to get 10 people to participate on=20 your first level=2E (Placing a lot of FREE ads on the internet will=20 EASILY get a larger response=2E) Also assume that everyone=20 else in YOUR ORGANIZATION gets ONLY 10 downline=20 members=2E Follow this example to achieve the STAGGERING=20 results below=2E=20 1st level--your 10 members with $5=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E= =2E=2E=2E=2E=2E=2E=2E=2E$50=20 2nd level--10 members from those 10 ($5 x 100)=2E=2E=2E=2E=2E=2E=2E=2E$50= 0=20 3rd level--10 members from those 100 ($5 x 1,000)=2E=2E=2E$5,000=20 4th level--10 members from those 1,000 ($5x10,000)=2E$50,000=20 THIS TOTALS ------> $55,550=20 Remember, this assumes that the people who=20 participate only recruit 10 people each=2E Think for a moment=20 what would happen if they got 20 people to participate! Lots=20 of people get 100s of participants! THINK ABOUT IT!=20 Your cost to participate in this is practically nothing (surely=20 you can afford $20)=2E You obviously already have an internet=20 connection and e-mail is FREE! REPORT #3 shows you the=20 most productive methods for bulk e-mailing and purchasing=20 e-mail lists=2E Some list & bulk e-mail vendors even work on=20 trade!=20 Over 50,000, new people, get on the internet EVERYDAY (CBS NEWS)!=20 *******TIPS FOR SUCCESS*******=20 * TREAT THIS AS YOUR BUSINESS! Be prompt,=20 professional, and follow the directions accurately=2E=20 * Send for the four reports IMMEDIATELY so you will have=20 them when the orders start coming in because:=20 When you receive a $5 order, you MUST send out the=20 requested product (report) to comply with the U=2ES=2E Postal &=20 Lottery Laws, Title 18, Sections 1302 and 1341 or Title 18,=20 Section 3005 in the U=2ES=2E Code, also Code of Federal Regs=2E=20 vol=2E 16, Sections 255 and 436, which state that "a product=20 or service must be exchanged for money received=2E"=20 * ALWAYS PROVIDE SAME-DAY SERVICE ON THE=20 ORDERS YOU RECEIVE=2E=20 * Be patient and persistent with this program=2E If you follow=20 the instructions exactly, the results WILL undoubtedly be=20 SUCCESSFUL!=20 * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW=20 YOU WILL SUCCEED!=20 *******YOUR SUCCESS GUIDELINE*******=20 Follow these guidelines to help assure your success:=20 If you don't receive 10 to 20 orders for REPORT #1 within=20 two weeks, continue advertising until you do=2E Then, a=20 couple of weeks later you should receive at least 100 orders=20 for REPORT #2=2E If you don't, continue advertising until you=20 do=2E Once you have received 100 or more orders for=20 REPORT #2, YOU CAN RELAX, because the system is=20 already working for you, and the cash can continue to roll in!=20 THIS IS IMPORTANT TO REMEMBER:=20 Every time your name is moved down on the list, you are=20 placed in front of a DIFFERENT report=2E You can KEEP=20 TRACK of your PROGRESS by watching which report=20 people are ordering from you=2E If you want to generate more=20 income, send another batch of e-mails and start the whole=20 process again! There is no limit to the income you will=20 generate from this business!=20 PLEASE NOTE: If you need help with starting a business,=20 registering a business name, learning how income tax is=20 handled, etc=2E, contact your local office of the Small Business=20 Administration (a Federal agency) 1-(800)827-5722 for free=20 help and answers to questions=2E Also, the Internal Revenue=20 Service offers free help via telephone and free seminars=20 about business tax requirements=2E Your earnings and results=20 are highly dependant on your activities and advertising=2E This=20 letter constitutes no guarantees stated nor implied=2E In the=20 event that it is determined that this letter constitutes a=20 guarantee of any kind, that guarantee is now void=2E Any=20 testimonials or amounts of earnings listed in this letter may be=20 factual or fictitious=2E If you have any question of the legality of=20 this letter contact the Office of Associate Director for=20 Marketing Practices Federal Trade Commission Bureau of=20 Consumer Protection in Washington DC=2E=20 *******T E S T I M O N I A L S*******=20 This program does work, but you must follow it EXACTLY!=20 Especially the rule of not trying to place your name in a=20 different position, it won't work and you'll lose a lot of=20 potential income=2E I'm living proof that it works=2E It really is a=20 great opportunity to make relatively easy money, with little=20 cost to you=2E If you do choose to participate, follow the=20 program exactly, and you'll be on your way to financial=20 security=2E=20 Sean McLaughlin, Jackson, MS=20 My name is Frank=2E My wife, Doris, and I live in Bel-Air, MD=2E I=20 am a cost accountant with a major U=2ES=2E Corporation and I=20 make pretty good money=2E When I received the program I=20 grumbled to Doris about receiving "junk mail=2E" I made fun of=20 the whole thing, spouting my knowledge of the population=20 and percentages involved=2E I "knew" it wouldn't work=2E Doris=20 totally ignored my supposed intelligence and jumped in with=20 both feet=2E I made merciless fun of her, and was ready to lay=20 the old "I told you so" on her when the thing didn't work=2E=2E=2E=20 well, the laugh was on me! Within two weeks she had=20 received over 50 responses=2E Within 45 days she had=20 received over $147,200 in $5 bills! I was shocked! I was=20 sure that I had it all figured and that it wouldn't work=2E I AM a=20 believer now=2E I have joined Doris in her "hobby=2E" I did have=20 seven more years until retirement, but I think of the "rat race"=20 and it's not for me=2E We owe it all to MLM=2E=20 Frank T=2E, Bel-Air, MD=20 I just want to pass along my best wishes and encouragement=20 to you=2E Any doubts you have will vanish when your first=20 orders come in=2E I even checked with the U=2ES=2E Post Office to=20 verify that the plan was legal=2E It definitely is! IT WORKS!=20 Paul Johnson, Raleigh, NC=20 The main reason for this letter is to convince you that this=20 system is honest, lawful, extremely profitable, and is a way to=20 get a large amount of money in a short time=2E I was=20 approached several times before I checked this out=2E I joined=20 just to see what one could expect in return for the minimal=20 effort and money required=2E To my astonishment, I received=20 $36,470=2E00 in the first 14 weeks, with money still coming in=2E=20 Phillip A=2E Brown, Esq=2E=20 Not being the gambling type, it took me several weeks to=20 make up my mind to participate in this plan=2E But conservative=20 that I am, I decided that the initial investment was so little that=20 there was just no way that I wouldn't get enough orders to at=20 least get my money back=2E Boy, was I surprised when I found=20 my medium-size post office box crammed with orders! For a=20 while, it got so overloaded that I had to start picking up my=20 mail at the window=2E I'll make more money this year than any=20 10 years of my life before=2E The nice thing about this plan is=20 that it doesn't matter where in the U=2ES=2E people live=2E There=20 simply isn't a better investment with a faster return=2E=20 Mary Rockland, Lansing, MI=20 I had received this program before=2E I deleted it, but later I=20 wondered if I shouldn't have given it a try=2E Of course, I had=20 no idea who to contact to get another copy, so I had to wait=20 until I was e-mailed another program=2E=2E=2E11 months passed then=20 it came=2E=2E=2EI didn't delete this one!=2E=2E=2EI made more than $41,00= 0=20 on the first try!!=20 D=2E Wilburn, Muncie, IN=20 This is my third time to participate in this plan=2E We have quit=20 our jobs, and will soon buy a home on the beach and live off=20 the interest on our money=2E The only way on earth that this=20 plan will work for you is if you do it=2E For your sake, and for=20 your family's sake don't pass up this golden opportunity=2E=20 Good luck and happy spending!=20 Charles Fairchild, Spokane, WA=20 ORDER YOUR REPORTS TODAY AND=20 GET STARTED ON YOUR ROAD TO=20 FINANCIAL FREEDOM!=20 NOW IS THE TIME !=20 DECISIVE ACTION YIELDS=20 POWERFUL RESULTS !=20 =20 =20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From frankikpendu2@mail.co.za Sat Feb 8 02:57:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18hlhS-0000ia-00 for ; Sun, 09 Feb 2003 08:16:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 09 Feb 2003 08:16:26 +0100 (CET) Received: (qmail 10233 invoked by uid 0); 8 Feb 2003 02:15:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 8 Feb 2003 02:15:01 -0000 Received: by moria.seul.org (Postfix) id 4ED3033DCF; Fri, 7 Feb 2003 21:13:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DF65833E5F; Fri, 7 Feb 2003 21:13:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from webmail.mail.co.za (unknown [192.96.58.70]) by moria.seul.org (Postfix) with ESMTP id 899DB33DCF for ; Fri, 7 Feb 2003 21:13:16 -0500 (EST) X-WM-Posted-At: webmail.mail.co.za; Sat, 8 Feb 03 03:57:40 +0200 X-WebMail-UserID: frankikpendu2 Date: Sat, 8 Feb 2003 03:57:40 +0200 From: Frank Ikpendu To: frankikpendu2@mail.co.za Subject: [f-cpu] Urgent Update. Message-ID: <3E497DE7@webmail.mail.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.61.01 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N FROM: SENATOR FRANK IKPENDU, CHAIRMAN OF CONTRACT REVIEW AND VERIFICATION COMMITTEE OF THE SENATE. LAGOS - NIGERIA. ATTN: SIR, I KNOW THAT YOU MUST HAVE RECEIVED THE FIRST LETTER I SENT TO YOU BY POST,BUT IF NOT, HERE COMES A FOLLOW UPTO OF THE LETTER. FIRST, I MUST SEEK FOR YOUR UTMOST UNDERSTANDING AND PRAY THAT GOD WILL GIVE YOU THE WISDOM TO ENABLE YOU UNDERSTAND MY POSITION NOW AS YOU WILL BE SURELY BLESSED. I AM SENATOR FRANK IKPENDU, THE CHAIRMAN OF CONTRACT REVIEW AND VERIFICATION COMMITTEE OF THE SENATE. THIS COMMITTEE WAS SET UP BY THE SENATE PRESIDENT CHIEF ANYIM PIUS ANYIM TO VERIFIED ALL THE CONTRACTS AWARDED DURING THE GOVERNMENT OF GENERAL SANNI ABACHA. DURING OUR INVESTIGATION WE DISCOVER AN ACCUMULATION OF OVER - INFLATED CONTRACTS AWARDED TO FOREIGN FIRMS BETWEEN 1993-1999 TO A TONE OF US$320MILLION. THUS WE DECIDED TO SEIZED THIS OPPORTUNITY TO MAPPED OUT US$32.5MILLION FOR OUR OWN PERSONAL USE. ALSO I HAVE BEEN MANDATED ON BEHALF OF MY COLLEAGUES TO SOLICIT YOUR CO-OPERATION TO ASSIST US TRANSFER IMMEDIATELY THIS AMOUNT INTO YOUR PERSONAL OR COMPANYS ACCOUNT. ALL WE REQUIRE FROM YOU ARE FULL DETAILS OF ANY BANK WHERE YOU WANT US TO TRANSFER THIS AMOUNT. WE HAVE DECIDED THAT IMMEDIATELY WE RECEIVE YOUR ACCEPTANCE LETTER THROUGH THE ABOVE E-MAIL ADDRESS WE SHALL WITHOUT DELAY PROCESS THE IMMEDIATE TRANSFER OF US$32.5MILLION THROUGH CENTRAL BANK OF NIGERIA INTO YOUR BANK ACCOUNT WITHIN 14 WORKING DAYS. WE HAVE AGREED THAT FOR YOUR ASSISTANCE WE WILL GIVE YOU 30% AND WE SHALL HAVE 60% AND 10% FOR EXPENSES WHICH WE MAY INCURE. I HOPE TO RECEIVE YOUR RESPONSE IMMEDIATELY YOU RECEIVE THIS E-MAIL. PLEASE INCLUDE YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMUNICATION AND DO REPLY ME THROUGH MY PRIVATE & CONFIDENTIAL EMAIL ADDRESS FOR SECURITY REASONS: frank@senatecontractverificationcommitee.zzn.com THANKS AND GOD BLESS. YOURS FAITHFULLY, Dr FRANK IKPENDU. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From osciloscope@hotmail.com Sun Feb 9 00:15:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18hlhw-0000ia-00 for ; Sun, 09 Feb 2003 08:16:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 09 Feb 2003 08:16:56 +0100 (CET) Received: (qmail 6720 invoked by uid 0); 8 Feb 2003 23:15:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 8 Feb 2003 23:15:06 -0000 Received: by moria.seul.org (Postfix) id 290F933D36; Sat, 8 Feb 2003 18:15:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8D58133DD1; Sat, 8 Feb 2003 18:15:04 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from hotmail.com (f77.pav1.hotmail.com [64.4.31.77]) by moria.seul.org (Postfix) with ESMTP id 90FD933D36 for ; Sat, 8 Feb 2003 18:15:03 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 8 Feb 2003 15:15:03 -0800 Received: from 200.91.192.137 by pv1fd.pav1.hotmail.msn.com with HTTP; Sat, 08 Feb 2003 23:15:02 GMT X-Originating-IP: [200.91.192.137] From: "leo ort" To: f-cpu@seul.org Subject: [f-cpu] projecto f-cpu Date: Sat, 08 Feb 2003 18:15:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 08 Feb 2003 23:15:03.0099 (UTC) FILETIME=[E8CD10B0:01C2CFC7] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N HELLO, I am LEONARDO ORTIZ OF THE GROUP OF DEVELOPMENT IN THE INTERNATIONAL CENTER OF FÍSICA DE COLOMBIA, AND he WANTED to KNOW where THE whole CODE could FIND IN VHDL OF THE PROYECTO F-CPU, AND AN EXPLANATION OF ITS STRUCTURE, since WHAT I have FOUND is STRUCTURES OF BLOCKS, BUT WHAT I NEED is THE whole INTEGRATED PROGRAM to KNOW WHICH FPGA to USE to IMPLEMENT IT (OR WHICH you USED), IF they NEEDED EXTERNAL MEMORY, ETC. thank you FOR THIS IDEA, IN THAT THAT PUEA ME to CONTRIBUTE THE I will MAKE WITH A LOT OF PLEASURE. THANK YOU FOR THEIR TIME. SINCERELY, LEONARDO ORTIZ osciloscope@hotmail.com HOLA, YO SOY LEONARDO ORTIZ DEL GRUPO DE DESARROLLO EN EL CENTRO INTERNACIONAL DE FISICA DE COLOMBIA, Y QUISIERA SABER EN DÓNDE PUDIERA ENCONTRAR TODO EL CÓDIGO EN VHDL DEL PROYECTO F-CPU, Y UNA EXPLICACIÓN DE SU ESTRUCTURA, YA QUE LO QUE HE ENCONTRADO SON ESTRUCTURAS DE BLOQUES, PERO LO QUE NECESITO ES TODO EL PROGRAMA INTEGRADO PARA SABER CUÁL FPGA UTILIZAR PARA IMPLEMENTARLO (O CUAL UTILIZARON USTEDES), SI NECESITARON MEMORIA EXTERNA, ETC. MUCHAS GRACIAS POR ESTA IDEA, EN LO QUE PUEA YO APORTAR LO HARÉ CON MUCHO GUSTO. GRACIAS POR SU TIEMPO. ATENTAMENTE, LEONARDO ORTIZ osciloscope@hotmail.com _________________________________________________________________ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Feb 9 01:59:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18hlhy-0000ia-01 for ; Sun, 09 Feb 2003 08:16:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 09 Feb 2003 08:16:58 +0100 (CET) Received: (qmail 13676 invoked by uid 0); 9 Feb 2003 00:59:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 9 Feb 2003 00:59:41 -0000 Received: by moria.seul.org (Postfix) id 44F6633DDD; Sat, 8 Feb 2003 19:59:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7749333DDF; Sat, 8 Feb 2003 19:59:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a217.home.uni-hannover.de [130.75.232.217]) by moria.seul.org (Postfix) with ESMTP id E820133DDD for ; Sat, 8 Feb 2003 19:59:36 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA18529; Sun, 9 Feb 2003 01:59:35 +0100 Message-ID: <20030209015935.06985@thrai.stud.uni-hannover.de> Date: Sun, 9 Feb 2003 01:59:35 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] fctools 0.3 uploaded to seul.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi F-gang! I uploaded fctools-0.3.tar.gz to http://f-cpu.seul.org/~f-cpu/new/. Highlights of this release: * I finished the linker. It supports only static binaries and relocatable objects (that is, no shared libraries), but that should be sufficient for the moment. * There also is a second emulator, called `elfemu'. It emulates a basic Unix/Linux operating system running on an F-CPU, including virtual memory and a reasonable set of system calls. Currently, it runs only static binaries, but that's all you can build with the most recent tools anyway. See the README file for a description how to build ELF binaries, and how to run them. * (fcpu-)as accepts a new option `-T ' which sets the load address of a binary created with `-O bin'. The machine emulator `emu' still loads a binary at address 0, though. * (fcpu-)emu now uses a table-based instruction decoder that should be faster than the compare-and-jump tree gcc generated for the `switch' statement I used before. Gcc compiles `emu.c' a little faster now, and needs less memory. * The `bitrev' instruction now right-shifts by the number of bits indicated by the third operand (as the manual states it). I also changed EU_SHL to match the emulator (not released yet). * I changed the system calling conventions. In release 0.2, you had to execute move first_arg, r1 move second_arg, r2 ... syscall $syscall_number, r0 move r1, result but that's suboptimal. In 0.3, the sequence has changed to move first_arg, r2 move second_arg, r3 ... loadconsx $syscall_number, r1 syscall $0, r0 move r1, result which allows us to define a single assembler function that accepts the syscall number as an argument (which was impossible before): .text .p2align 5 .globl _syscall _syscall: syscall $0, r0 // handle return values (-4096...-1 means there was an error) loadconsx.0 $-4097, r2 cmple.64 r2, r1, r3 loadcons $errno, r2 jmpl r3, r63 // not an error, return result store.32 r2, r1 // store code in `errno' and return -1 loadconsx.0 $-1, r1 jmp r63 .comm errno,4,4 Now we can write something like #include /* this should go into a header file */ #define SYS_read 1 #define SYS_write 2 extern long _syscall(unsigned long, ...); ssize_t read(int fd, void *buf, size_t len) { return _syscall(SYS_read, fd, buf, len); } ssize_t write(int fd, const void *buf, size_t len) { return _syscall(SYS_write, fd, buf, len); } to create system call wrappers in C. I also added a lot of system calls, but only to `elfemu' (see emu/syscalls.def for a list of supported functions). `emu' still accepts only `exit' (0), `read' (1) and `write' (2) - and I guess it will stay that way. * A number of bugs has been fixed. Have fun, -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me465156@members.interq.or.jp Mon Feb 10 07:54:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18iAb3-0000GV-00 for ; Mon, 10 Feb 2003 10:51:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 10 Feb 2003 10:51:29 +0100 (CET) Received: (qmail 23833 invoked by uid 0); 10 Feb 2003 06:56:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 10 Feb 2003 06:56:13 -0000 Received: by moria.seul.org (Postfix) id A06B333DD2; Mon, 10 Feb 2003 01:56:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6C0233DE1; Mon, 10 Feb 2003 01:56:11 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from a1a1a1 (pl1209.nas927.o-tokyo.nttpc.ne.jp [61.197.110.185]) by moria.seul.org (Postfix) with ESMTP id 3E91E33DD2 for ; Mon, 10 Feb 2003 01:56:05 -0500 (EST) Received: from 5-C ([192.168.0.2]) by a1a1a1 (8.9.3+3.2W/3.7W) with SMTP id PAA32622; Mon, 10 Feb 2003 15:57:56 +0900 Message-Id: <200302100657.PAA32622@a1a1a1> From: =?iso-2022-jp?B?bWU0NjUxNTY=?= To: =?iso-2022-jp?B?MjAwMjI=?=@a1a1a1.seul.org Date: Mon, 10 Feb 2003 15:54:54 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoSGtMKSROR2NKKhsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> ‚³‚í‚â‚©LŽÐ ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463886@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢ §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@090-3878-3581 FAX@03-3544-6218@@ ™\\\™\\\™\\\™\\\™\\\™\\\™ ‚±‚̃[ƒ‹‚ðŽó‚¯Žæ‚ç‚ꂽ•ûA1’ʂɂ‚«100‰~·‚µã‚°‚Ü‚·B 5000‰~•ª’™‚Ü‚è‚Ü‚µ‚½‚犷‹à’v‚µ‚Ü‚·‚Ì‚Å‚²¿‹‰º‚³‚¢B @@š@ƒoƒi[‚ð‚Í‚Á‚ĉº‚³‚é•û•åW‚µ‚Ü‚·I@š ”„‚èã‚°‚Ì10“‚ði’悵‚Ü‚·B Å’á•Ûá‚Æ‚µ‚ÄŒŽŠz10–œ‰~AŒŽ‚É50–œ‰~‚ÍŠmŽÀ‚Å‚·B ™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu ‚`‚u’j—D•åWE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/ ™\\\™\\\™\\\™\\\™\\\™\\\™ ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽE–h”ƃOƒbƒYE‹à–ׂ¯î•ñ‚È‚Ç@ @@@š@‚»‚Ì‘¼î•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dr.jombo@caramail.com Mon Feb 10 16:00:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18iLz1-0000Fr-00 for ; Mon, 10 Feb 2003 23:00:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 10 Feb 2003 23:00:59 +0100 (CET) Received: (qmail 13588 invoked by uid 0); 10 Feb 2003 15:26:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 10 Feb 2003 15:26:38 -0000 Received: by moria.seul.org (Postfix) id F0A2733DE8; Mon, 10 Feb 2003 10:26:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9D5E733DE7; Mon, 10 Feb 2003 10:26:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail2.caramail.com (mail2.caramail.com [213.193.13.93]) by moria.seul.org (Postfix) with ESMTP id 8C8CC33DE1 for ; Mon, 10 Feb 2003 10:26:13 -0500 (EST) Received: from caramail.com (www4.caramail.com [213.193.13.14]) by mail2.caramail.com (Postfix) with SMTP id 27EE5F7B0; Mon, 10 Feb 2003 15:00:19 +0100 (MET) From: dr jombo To: dr.jombo@caramail.com Message-ID: <1044885613032149@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [216.139.169.155] Mime-Version: 1.0 Subject: [f-cpu] ASSISTANCE PLEASE. Date: Mon, 10 Feb 2003 15:00:13 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0321491044885613_ID" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0321491044885613_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OFFICE OF THE CHAIRMAN CONTRACT AWARDING COMMITTE ECOWAS HEADQUARTERS ABUJA, FEDERAL REPUBLIC OF NIGERIA. WEST AFRICA. DEAR SIR, I AM SENATOR JOMBO OFOR THE CHAIRMAN OF CONTRACT REVIEW AND VERIFICATION COMMITTEE OF THE SENATE. THIS COMMITTEE WAS SET UP BY THE SENATE PRESIDENT CHIEF ANYIM PIUS ANYIM TO VERIFIED ALL THE CONTRACTS AWARDED DURING THE GOVERNMENT OF GENERAL SANNI ABACHA. DURING OUR INVESTIGATION WE DISCOVER AN ACCUMULATION OF OVER - INFLATED CONTRACTS AWARDED TO FOREIGN FIRMS BETWEEN 1993-1999 TO A TONE OF US$320MILLION. THUS WE DECIDED TO SEIZED THIS OPPORTUNITY TO MAPPED OUT US$32.5MILLION FOR OUR OWN PERSONAL USE. ALSO I HAVE BEEN MANDATED ON BEHALF OF MY COLLEAGUES TO SOLICIT YOUR CO-OPERATION TO ASSIST US TRANSFER IMMEDIATELY THIS AMOUNT INTO YOUR PERSONAL OR COMPANY’S ACCOUNT. ALL WE REQUIRE FROM YOU ARE FULL DETAILS OF ANY BANK WHERE YOU WANT US TO TRANSFER THIS AMOUNT. WE HAVE DECIDED THAT IMMEDIATELY WE RECEIVE YOUR ACCEPTANCE LETTER THROUGH THE ABOVE E-MAIL ADDRESS WE SHALL WITHOUT DELAY PROCESS THE IMMEDIATE TRANSFER OF US$32.5MILLION THROUGH CENTRAL BANK OF NIGERIA INTO YOUR BANK ACCOUNT WITHIN 14 WORKING DAYS. WE HAVE AGREED THAT FOR YOUR ASSISTANCE WE WILL GIVE YOU 30% AND WE SHALL HAVE 60% AND 10% FOR EXPENSES. I HOPE TO RECEIVE YOUR RESPONSE IMMEDIATELY YOU RECEIVE THIS E-MAIL. PLEASE INCLUDE YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMUNICATION. THANKS AND GOD BLESS. YOURS FAITHFULLY, SENATOR JOMBO. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0321491044885613_ID-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dr.jombo@caramail.com Tue Feb 11 11:50:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ibwG-0000GW-00 for ; Tue, 11 Feb 2003 16:03:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Feb 2003 16:03:12 +0100 (CET) Received: (qmail 26967 invoked by uid 0); 11 Feb 2003 09:54:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 11 Feb 2003 09:54:36 -0000 Received: by moria.seul.org (Postfix) id D48D133E07; Tue, 11 Feb 2003 04:54:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3329F33E09; Tue, 11 Feb 2003 04:54:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail1.caramail.com (mail1.caramail.com [213.193.13.92]) by moria.seul.org (Postfix) with ESMTP id 4CBDA33E07 for ; Tue, 11 Feb 2003 04:54:33 -0500 (EST) Received: from caramail.com (www29.caramail.com [213.193.13.39]) by mail1.caramail.com (Postfix) with SMTP id 7A8AA1DFC1; Tue, 11 Feb 2003 10:50:16 +0100 (MET) From: dr jombo To: dr.jombo@caramail.com Message-ID: <1044957006009738@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [81.23.192.196] Mime-Version: 1.0 Subject: [f-cpu] ASSISTANCE PLEASE. Date: Tue, 11 Feb 2003 10:50:06 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0097381044957006_ID" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0097381044957006_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OFFICE OF THE CHAIRMAN CONTRACT AWARDING COMMITTE ECOWAS HEADQUARTERS ABUJA, FEDERAL REPUBLIC OF NIGERIA. WEST AFRICA. DEAR SIR, I AM SENATOR JOMBO OFOR THE CHAIRMAN OF CONTRACT REVIEW AND VERIFICATION COMMITTEE OF THE SENATE. THIS COMMITTEE WAS SET UP BY THE SENATE PRESIDENT CHIEF ANYIM PIUS ANYIM TO VERIFIED ALL THE CONTRACTS AWARDED DURING THE GOVERNMENT OF GENERAL SANNI ABACHA. DURING OUR INVESTIGATION WE DISCOVER AN ACCUMULATION OF OVER - INFLATED CONTRACTS AWARDED TO FOREIGN FIRMS BETWEEN 1993-1999 TO A TONE OF US$320MILLION. THUS WE DECIDED TO SEIZED THIS OPPORTUNITY TO MAPPED OUT US$32.5MILLION FOR OUR OWN PERSONAL USE. ALSO I HAVE BEEN MANDATED ON BEHALF OF MY COLLEAGUES TO SOLICIT YOUR CO-OPERATION TO ASSIST US TRANSFER IMMEDIATELY THIS AMOUNT INTO YOUR PERSONAL OR COMPANY=92S ACCOUNT. ALL WE REQUIRE FROM YOU ARE FULL DETAILS OF ANY BANK WHERE YOU WANT US TO TRANSFER THIS AMOUNT. WE HAVE DECIDED THAT IMMEDIATELY WE RECEIVE YOUR ACCEPTANCE LETTER THROUGH THE ABOVE E-MAIL ADDRESS WE SHALL WITHOUT DELAY PROCESS THE IMMEDIATE TRANSFER OF US$32.5MILLION THROUGH CENTRAL BANK OF NIGERIA INTO YOUR BANK ACCOUNT WITHIN 14 WORKING DAYS. WE HAVE AGREED THAT FOR YOUR ASSISTANCE WE WILL GIVE YOU 30% AND WE SHALL HAVE 60% AND 10% FOR EXPENSES. I HOPE TO RECEIVE YOUR RESPONSE IMMEDIATELY YOU RECEIVE THIS E-MAIL. PLEASE INCLUDE YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMUNICATION. THANKS AND GOD BLESS. YOURS FAITHFULLY, SENATOR JOMBO. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0097381044957006_ID-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dr.jombo@caramail.com Tue Feb 11 11:49:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18ibwI-0000GW-01 for ; Tue, 11 Feb 2003 16:03:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Feb 2003 16:03:14 +0100 (CET) Received: (qmail 5196 invoked by uid 0); 11 Feb 2003 11:27:12 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 11 Feb 2003 11:27:12 -0000 Received: by moria.seul.org (Postfix) id 8E2F033E0B; Tue, 11 Feb 2003 06:27:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0585133E0F; Tue, 11 Feb 2003 06:27:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mail3.caramail.com (mail3.caramail.com [213.193.13.94]) by moria.seul.org (Postfix) with ESMTP id 207FD33E0B for ; Tue, 11 Feb 2003 06:27:10 -0500 (EST) Received: from caramail.com (www24.caramail.com [213.193.13.34]) by mail3.caramail.com (Postfix) with SMTP id 743811A4BB; Tue, 11 Feb 2003 10:49:39 +0100 (MET) From: dr jombo To: dr.jombo@caramail.com Message-ID: <1044956978029786@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [81.23.192.196] Mime-Version: 1.0 Subject: [f-cpu] ASSISTANCE PLEASE. Date: Tue, 11 Feb 2003 10:49:38 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0297861044956978_ID" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0297861044956978_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OFFICE OF THE CHAIRMAN CONTRACT AWARDING COMMITTE ECOWAS HEADQUARTERS ABUJA, FEDERAL REPUBLIC OF NIGERIA. WEST AFRICA. DEAR SIR, I AM SENATOR JOMBO OFOR THE CHAIRMAN OF CONTRACT REVIEW AND VERIFICATION COMMITTEE OF THE SENATE. THIS COMMITTEE WAS SET UP BY THE SENATE PRESIDENT CHIEF ANYIM PIUS ANYIM TO VERIFIED ALL THE CONTRACTS AWARDED DURING THE GOVERNMENT OF GENERAL SANNI ABACHA. DURING OUR INVESTIGATION WE DISCOVER AN ACCUMULATION OF OVER - INFLATED CONTRACTS AWARDED TO FOREIGN FIRMS BETWEEN 1993-1999 TO A TONE OF US$320MILLION. THUS WE DECIDED TO SEIZED THIS OPPORTUNITY TO MAPPED OUT US$32.5MILLION FOR OUR OWN PERSONAL USE. ALSO I HAVE BEEN MANDATED ON BEHALF OF MY COLLEAGUES TO SOLICIT YOUR CO-OPERATION TO ASSIST US TRANSFER IMMEDIATELY THIS AMOUNT INTO YOUR PERSONAL OR COMPANY’S ACCOUNT. ALL WE REQUIRE FROM YOU ARE FULL DETAILS OF ANY BANK WHERE YOU WANT US TO TRANSFER THIS AMOUNT. WE HAVE DECIDED THAT IMMEDIATELY WE RECEIVE YOUR ACCEPTANCE LETTER THROUGH THE ABOVE E-MAIL ADDRESS WE SHALL WITHOUT DELAY PROCESS THE IMMEDIATE TRANSFER OF US$32.5MILLION THROUGH CENTRAL BANK OF NIGERIA INTO YOUR BANK ACCOUNT WITHIN 14 WORKING DAYS. WE HAVE AGREED THAT FOR YOUR ASSISTANCE WE WILL GIVE YOU 30% AND WE SHALL HAVE 60% AND 10% FOR EXPENSES. I HOPE TO RECEIVE YOUR RESPONSE IMMEDIATELY YOU RECEIVE THIS E-MAIL. PLEASE INCLUDE YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMUNICATION. THANKS AND GOD BLESS. YOURS FAITHFULLY, SENATOR JOMBO. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0297861044956978_ID-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From auto64683@hushmail.com Fri Feb 14 02:38:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18jOpb-000782-00 for ; Thu, 13 Feb 2003 20:15:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 13 Feb 2003 20:15:35 +0100 (CET) Received: (qmail 23315 invoked by uid 0); 13 Feb 2003 17:25:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 13 Feb 2003 17:25:36 -0000 Received: by moria.seul.org (Postfix) id 13CF733C7E; Thu, 13 Feb 2003 12:25:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4535133C67; Thu, 13 Feb 2003 12:25:34 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 1171B33C29 for ; Thu, 13 Feb 2003 12:25:32 -0500 (EST) Received: from helimore1755.com (unknown [217.78.73.132]) by bettik.munge.net (Postfix) with SMTP id D6AEF4F915 for ; Thu, 13 Feb 2003 11:25:25 -0600 (CST) From: "Mr. Muyiwa A. Ige" To: f-cpu@seul.org Date: Thu, 13 Feb 2003 17:38:23 -0800 Subject: [f-cpu] Most confidential & Urgent ! X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030213172525.D6AEF4F915@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N From=3A Mr=2E Muyiwa Ige=2E Dear Sir=2C I am taking this liberty anchored on strong desire to ask for your assistance for help=2E Your consent and urgent attention will greatly be needed=2C devoid of apprehensions=2E First I must solicit your confidence in this transaction=2C this is by virtue of its nature as being Utterly confidential and top secret=2E Though I know that a transaction of this magnitude will make any one apprehensive and worried=2C but i am assuring you of the authenticity and legality of this venture=2E I have decided to contact you due to the urgency involve=2C I am using this medium of contact as being the only option open to me for now so therefore bear with me=2E I am Mr=2E Muyiwa Ige=2C the first son of James Ajibola Ige =28SAN=29 the Attorney General of the federation=2Fminister of Justice under the present Government of President Olusegun Obasanjo=2C my Late father who was assassinated on the 23rd of December=2C 2001 by assailant's bullets in our Residential home in Ibadan-Nigeria=2E Until now no substantiated arrests have been made but accusing fingers have been pointed on his political rivals=2Fassociates=2E I have no doubt his death has some political undertone=2E With every hope and assurance my families secret which i am about disclosing to you and which forms the basis of this request must be held at an utmost confidence=2E The sum of thirty eight million united states dollars =28USD$38=2C000=2C000=29 belonging to my late father was kept in a private security company by myself and my family in europe which i will disclose the acutual location and contacts to you after we must have reached some sort of agreements=2C trust and apprehension in this mutually beneficial venture=2E I was advised by my father's attorney to change the direction of some of my father's fund immediately as the present Government is interested to put a check in my father's account and then probe him in abscentia as the case of the late head of state and commander in chief of the Armed forces=2C the late general Sani Abacha whose account was frozen and brought the entire family to a stand still uptill date=2E Please kindly help my family secure this substaintial amount=2C by standing as the sole beneficiary of the above mentioned amount=2E Please note that as soon as we have reach a mutual trust and understading between both parties=2C i will change all documents to reflect your name as the beneficiary and forward your particulars and necessary documents to the security company in europe for the release of the funds physically to you=2C afterwhich you will provide the security company an account in any part of the world for lodgement=2E Please note that the funds was exported physically out of this country via diplomatic means=2C and you will visit the security company in europe to claim the whole money physically=2E A sharing formular has been worked out between myself and my attorney=2C you will be given 20% of the total of $38=2C000=2C000 =28 thirty eight million united states dollars=29=2C it will be included on our deed of conveyance=2Fagreement that must be signed and sealed by both parties=2E The entire members of my family will everly remain grateful if you could save us from tomorrow's perceived abject poverty and stervation by ensuring that this money is successfully secured into your nominated bank account and on schedule too=2E Upon your reply=2C you are expected to send as follow=3A 1=2E Your direct telephone and fax numbers for easy=2Ffaster communication=2E 2=2E A detailed profile about yourself=2E 3=2E A copy of your drivers liscence or international passport=2E I thank you immensely for your kindest cooperation=2E You can call me on my direct telephone number for verbal discussion=2E Direct tel=3A 009-2341-7763315 or direct fax=3A 009-2341-7593820 Truly Yours Mr=2E Muyiwa Ige =28For the family=29 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From master@89894.com Fri Feb 14 05:54:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX2o-0003LY-00 for ; Tue, 11 Mar 2003 00:50:58 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:50:58 +0100 (CET) Received: (qmail 10042 invoked by uid 0); 16 Feb 2003 16:51:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 16 Feb 2003 16:51:42 -0000 Received: by moria.seul.org (Postfix) id 6FC0433CF6; Sun, 16 Feb 2003 11:51:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4FCEE33D84; Sun, 16 Feb 2003 11:51:39 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 89894.com (unknown [218.147.125.173]) by moria.seul.org (Postfix) with SMTP id 7CCC533CF6 for ; Sun, 16 Feb 2003 11:51:36 -0500 (EST) Message-ID: <309740-2200325144541878@89894.com> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 From: "½Å¿ë ö" To: f-cpu@seul.org Subject: [f-cpu] [°úÇÐ] ²ÞÀÇ ¿¡³ÊÁö ¹«ÇÑ µ¿·Â Date: Fri, 14 Feb 2003 13:54:18 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF= =A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD= =C3=B8=E9 = =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4

 

 

[=B0=FA=C7=D0]  =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6 = =B9=AB=C7=D1 =B5=BF=B7=C2

 

=B9=AB=C7=D1 =B5=BF=B7=C2=C0=BA =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6=B0= =A1 =BE=C6=B4=D2 =BC=F6 =BE=F8=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E

=C8=AD=BC=AE =BF=AC=B7=E1=B8=A6 =BB=E7=BF=EB=C7=CF=C1=F6 =BE=CA=B0= =ED,

=BF=AC=B7=E1=B0=A1 =BE=F8=C0=CC =B5=B9=BE=C6=B0=A1=B4=C2 =BF=A3=C1= =F8=C0=CC =C0=D6=B4=D9=B8=E9 =BF=A1=B3=CA=C1=F6=BF=A1 =B4=EB=C7=D1 =B9=AE=C1= =A6=B4=C2 =B8=F0=B5=CE =C7=D8=B0=E1=B5=C9 =BC=F6 =C0=D6=B0=DA=C1=F6=BF=E4=2E

=C0=DA=B5=BF=C2=F7=B0=A1 =B1=E2=B8=A7=C0=CC =BE=F8=C0=CC =B4=DE=B8= =B1 =BC=F6 =C0=D6=B4=D9=B8=E9=2E=2E=2E=2E=2E?

=BF=AC=B7=E1=B8=A6 =BE=B2=C1=F6=BE=CA=B0=ED =B9=DF=C0=FC=B1=E2=BF= =A1=BC=AD =B9=AB=C7=D1=C1=A4 =C0=FC=B1=E2=B0=A1 =B9=DF=BB=FD=B5=C8=B4=D9=B8= =E9 =B1=D7 =BE=EE=B5=F0=BF=A1=BC=AD=B5=E7=C1=F6 =C0=CE=B0=A3=C0=C7 =BB=EE=C0=BA =C7=B3=BF=E4=B7=CE=BF=EF =B0=CD=C0=CC=B8=E7= ,

=C8=AD=BC=AE=20 =BF=AC=B7=E1=C0=C7 =B8=C5=BF=AC =B0=F8=C7=D8=B9=AE=C1=A6=B4=C2 =B4=F5 =C0=CC= =BB=F3=C0=C7 =BF=AC=B1=B8 =B4=EB=BB=F3=C0=CC =B5=C9 =BC=F6 =BE=F8=C0=B8=B8= =E7=2E=2E=2E=2E=2E

 

=B1=D7=B7=AF=B3=AA=20 =BE=D6=BC=AE =C7=CF=B0=D4=B5=B5 =BE=C6=C1=F7 =BF=EC=B8=AE =C0=CE=B7=F9=B4=C2=   =C0=CC=20 =B9=AB=C7=D1 =B5=BF=B7=C2=C0=BB =B0=B3=B9=DF=C0=BB =BC=BA=B0=F8 =C7=CF=C1=F6= =B8=F8=C7=DF=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E=2E

 

=B8=B9=C0=BA=20 =BB=E7=B6=F7=C0=CC =BF=A9=B1=E2=BF=A1 =B5=B5=C0=FC=C0=BB =C7=CF=B0=ED =C0=D6= =C0=B8=B8=E7 =BC=BA=B0=F8=C0=C7 =B1=D7 =BC=F8=B0=A3  =C0=CE=B7=F9=C0=C7 =C7=E0=BA=B9=C0= =CF =B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E=2E

=C0=CE=B0=A3=C0=BA =C0=FA =B9=AB=C7=D1=C0=C7 =B0=F8=B0=A3

=BF=EC=C1=D6=B7=CE  =BF=EC=C1=D6=B7=CE=20 =B0=C5=C4=A7=BE=F8=C0=CC =B9=DF=C0=FC=C7=D8 =B3=AA=B0=A5 =B0=CD=C0=D4=B4=CF= =B4=D9=2E=2E=2E

 

=C0=CC=B4=C2 =B0=F8=B0=A3 =C1=A6=C7=D1=C0=BB =B9=E7=C1=F6=BE=CA=B0=ED=20 =BF=A1=B3=CA=C1=F6=B8=A6 =B9=AB=C7=D1=BB=FD=BB=EA=C7=D2 =BC=F6 =C0=D6=B4=C2= =B9=AB=C7=D1 =B5=BF=B7=C2=C0=CC =C0=D6=C0=BB =B0=E6=BF=EC=BF=A1=B8=B8 =B0= =A1=B4=C9=C7=D1 =C0=CF=C0=D4=B4=CF=B4=D9=2E=2E=2E

 

=BF=A9=B1=E2=BF=A1=20 =B0=ED=C1=A4 =BF=A1=B3=CA=C1=F6=B8=A6 =C0=CC=BF=EB=C7=D1 =BF=A3=C1=F8=C0=BB= 16=B3=E2=B0=A3=BF=A1 =B0=C9=C3=C4 =B2=D9=C1=D8=C8=F7 =B0=B3=B9=DF=C7=CF=B0=ED=C0=D6=C0=B8=B8=E7 =C3=D6=B1=D9 5=B3=E2=BF=A9 =B5=BF= =BE=C8 6=C8=B8=BF=A1 =B0=C9=C3=C4 =BA=CE=BA=D0 =BA=CE=BA=D0=C0=BB=20 =C1=A6=C0=DB=C7=CF=BF=A9 =B0=CB=C1=F5=C0=BB =C7=D8=BF=C2=B9=D9 =C1=F6=B1=DD= =C0=BA =BC=B3=B0=E8=B0=A1 =B8=B6=B9=AB=B8=AE=B5=C7=BE=EE =C1=BE=C7=D5 =C0=FB= =C0=CE =C1=A6=C0=DB =B0=FA=C1=A4=BF=A1 =BF=CD=C0=D6=C0=B8=B8=E7,

 

=BA=B8=B4=D9=20 =B8=B9=C0=BA =C0=CC =B5=E9=B7=CE=BA=CE=C5=CD =C7=D4=B2=B2 =C7=CF=B0=ED=C0=DA= =C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE=B8=A6 =B0=B3=BC=B3=C7=CF=BF=A9 =B5=BF=C8=A3= =C0=CE=C0=C7 =B2=DE=C0=BB =B8=B8=B5=E9=BE=EE =B0=A1=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9=2E=2E=2E

 

=B9=AB=C7=D1=B5=BF=B7=C2=20 =BB=E7=C0=CC=C6=AE :&= nbsp;=20 cafe=2Edaum=2Enet/106030 =C0=D4=B4=CF=B4=D9=2E

 

=B8=B9=C0=CC =B9=E6=B9=AE=C7=CF=BD=C3=BE=EE =C0=DA=B7=E1 =B0=CB=BB= =F6=C7=CF=BD=C3=B0=ED =B6=C7 =B1=DB=C0=BB =B8=B9=C0=CC =BF=C3=B7=C1 =C1=D6= =BC=BC=BF=E4=2E=2E=2E=2E

 

  ^^ ** ^^   ^^ ** ^^  

 

tel :=20 011-281-1434  =BD=C5  =BF=EB =20 =C3=B6

 

 

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From "smoke000@bulgaria.com" Mon Feb 17 12:33:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX3K-0003LY-00 for ; Tue, 11 Mar 2003 00:51:30 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:51:30 +0100 (CET) Received: (qmail 23921 invoked by uid 0); 17 Feb 2003 11:33:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 17 Feb 2003 11:33:01 -0000 Received: by moria.seul.org (Postfix) id 3F03633D93; Mon, 17 Feb 2003 06:32:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BB20E33D97; Mon, 17 Feb 2003 06:32:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 0726F33D93 for ; Mon, 17 Feb 2003 06:32:55 -0500 (EST) Received: from 70.33.01.17 (f-tokyo-132070.zero.ad.jp [211.130.132.70]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h1HBWqk03135 for ; Mon, 17 Feb 2003 06:32:53 -0500 Message-Id: <200302171132.h1HBWqk03135@belegost.mit.edu> From: "smoke000@bulgaria.com" To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81=9A=81=9A=82=ED=82=BD=82=B5=81A=94=F2=82=D1=82=DC=82=B7=81I=81=9A=81=9A?= Date: Mon, 17 Feb 2003 20:33:03 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bd10d55f-abb4-4d9c-bb04-38be75202078" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --bd10d55f-abb4-4d9c-bb04-38be75202078 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =81@=81@=81@=81@=81=9A=92g=82=A9=82=AD=82=C8=82=E9=97t=82=C1=82=CF=82=A0=82=E8= =82=DC=82=B7=81=9A =83K=83=93=83W=83=83=81A=83`=83=87=83R=81A=8E=F7=8E=89=81A=83X=83=82=81[=83= N=81Aseeds =93=FA=96{=8F=89=93=FC=89=D7=81A=83A=83w=83=93=97l=83n=83=8F=83C=8EY=83n=81= [=83o=83=8B=83X=83=82=81[=83N =83T=83C=83g=82=AA=8F=C1=82=B3=82=EA=82=BD=82=E7=8FI=97=B9=82=C5=82=B7=81B =90=B8=90_=88=C0=92=E8=8D=DC=91=E3=82=ED=82=E8=82=C9=82=C7=82=A4=82=BC=81I =81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB= =81@=81=AB=81@=81=AB http://smoke0.www4.dotnetplayground.com/ http://tobutobu.host.sk/ http://smoke0.freewebtools.com/ http://www.filth-hosts.com/users/smoke0/ --bd10d55f-abb4-4d9c-bb04-38be75202078-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Mar 3 19:13:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXIl-0003LY-00 for ; Tue, 11 Mar 2003 01:07:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:07:27 +0100 (CET) Received: (qmail 21221 invoked by uid 0); 3 Mar 2003 19:11:57 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 3 Mar 2003 19:11:57 -0000 Received: by moria.seul.org (Postfix) id 42C6433FC1; Mon, 3 Mar 2003 14:11:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 71B1833FBD; Mon, 3 Mar 2003 14:11:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4E21733FC1 for ; Mon, 3 Mar 2003 14:11:52 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18pvLo-0004bm-00 for f-cpu@seul.org; Mon, 03 Mar 2003 20:11:49 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18puRZ-0000Vp-00 for f-cpu@seul.org; Mon, 03 Mar 2003 19:13:41 +0100 Date: Mon, 3 Mar 2003 19:13:41 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] delayed issue Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf VERY interesting reading ! ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From t.ririka@email.it Mon Mar 3 16:12:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXIR-0003LY-00 for ; Tue, 11 Mar 2003 01:07:07 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:07:07 +0100 (CET) Received: (qmail 15873 invoked by uid 0); 3 Mar 2003 15:15:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 3 Mar 2003 15:15:53 -0000 Received: by moria.seul.org (Postfix) id 0538333FBE; Mon, 3 Mar 2003 10:15:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57F0733FC8; Mon, 3 Mar 2003 10:14:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 7879A33FC6 for ; Mon, 3 Mar 2003 10:12:17 -0500 (EST) Received: from 10.12.43.04 (f-tokyo-132104.zero.ad.jp [211.130.132.104]) by bettik.munge.net (Postfix) with SMTP id 16E914F84A for ; Mon, 3 Mar 2003 09:11:35 -0600 (CST) From: t.ririka@email.it To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=97=A2=97=9C=8D=81=81@=82P=82S=8D=CB=81i=92=86=82Q=81j?= Date: Tue, 04 Mar 2003 00:12:45 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="617b33e6-2161-46e6-b560-254bdf8041b3" Message-Id: <20030303151135.16E914F84A@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --617b33e6-2161-46e6-b560-254bdf8041b3 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =8E=CA=90^=82=AA=82=A2=82=C1=82=CF=82=A2=82=A0=82=E9=82=E6 =8F=C1=82=B3=82=EA=82=E9=91O=82=C9=91=81=82=AD=8C=A9=82=C4=81I http://ririka80.muvc.net/ http://ririka.6server.com/ http://www.sultryserver.com/teen/ririka/ http://www.royalfreehost.com/teen/ririka/ http://www.pornhostz.com/users/ririka/ =96=BC=8C=C3=89=AE=92c=92n=82=C6=82=A9=8F=AD=8F=97=82=CC=93=B9=91=90=82=C6=82= =A9=92m=82=C1=82=C4=82=E9=81H http://book-i.net/ririka80/ http://host.deluxnetwork.com/~ririka/ http://www.free-xxx-server.com/sites/asians/ririka/ --617b33e6-2161-46e6-b560-254bdf8041b3-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Mar 3 11:37:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXIQ-0003LY-00 for ; Tue, 11 Mar 2003 01:07:06 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:07:06 +0100 (CET) Received: (qmail 27116 invoked by uid 0); 3 Mar 2003 15:15:36 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 3 Mar 2003 15:15:36 -0000 Received: by moria.seul.org (Postfix) id 1945033FBF; Mon, 3 Mar 2003 10:10:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0A9533FC6; Mon, 3 Mar 2003 10:10:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4BF2B33FC5 for ; Mon, 3 Mar 2003 10:07:56 -0500 (EST) Received: from a37-137.dialup.iol.cz ([194.228.137.37] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18prXR-0003Ms-00 for f-cpu@seul.org; Mon, 03 Mar 2003 16:07:34 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18pnKD-0000D6-00 for f-cpu@seul.org; Mon, 03 Mar 2003 11:37:37 +0100 Date: Mon, 3 Mar 2003 11:37:37 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IEEE FP exceptions In-Reply-To: <20030301214835.03274@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > There is, however, a big problem with FP status: Since instructions > complete out-of-order, it's undefined which instruction the status > comes from. You can only query the status of a series of FP instructions > collectively, unless you serialize the instruction stream after every > FP operation (which is going to be slooooooooow). from what I've understood from the paper, the use is to: double compute_krakovian(matrix *x) { clear_fpuflag() ... some heavy numerical math ... if (test_flag_for_error) return compute_krakovian_precise(x); return y; } so that to do block of computation, serialize and check flag. The flag could be also "hidden" part of our 96bit FPU word and thus it could be copied/preserved during dataflow - one then could also check for errors or imprecisions in single result. That would allow very nice handling of precision, no extra context, no problem with OOC and compiler could simulate IEEE behaviour of global status flag by ORing status words obtained from all dataflow registers in cross-section at the place of "check()" call (yes gcc can handle it easily). Yet another "in-pipeline" exception would be over ;-) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Mar 2 14:12:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXHv-0003LY-00 for ; Tue, 11 Mar 2003 01:06:35 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:06:35 +0100 (CET) Received: (qmail 21705 invoked by uid 0); 3 Mar 2003 02:25:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 3 Mar 2003 02:25:40 -0000 Received: by moria.seul.org (Postfix) id 591B233B89; Sun, 2 Mar 2003 21:25:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6B9F33FB3; Sun, 2 Mar 2003 21:25:32 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a035.home.uni-hannover.de [130.75.232.35]) by moria.seul.org (Postfix) with ESMTP id 4353C33B89 for ; Sun, 2 Mar 2003 21:25:30 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00533; Sun, 2 Mar 2003 14:12:13 +0100 Message-ID: <20030302141213.28869@thrai.stud.uni-hannover.de> Date: Sun, 2 Mar 2003 14:12:13 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <3E608AF4.1070603@f-cpu.org> <20030301214835.03274@thrai.stud.uni-hannover.de> <3E619BBE.1070208@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E619BBE.1070208@f-cpu.org>; from Yann Guidon on Sun, Mar 02, 2003 at 06:50:54AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Mar 02, 2003 at 06:50:54AM +0100, Yann Guidon wrote: [...] > >>hoping to revive this list, > >> > >> > >I guess that was enough revival for a single mail, wasn't it? ;) > > > yup and i already regret it :-) You asked for it, you got it ;) > The FP stuff is ok because it's "future work" and the integer part is > not even finished. I've lost track -- what's missing except eu_div? > However, the redesign of the conditions is less amusing because i am not > in a mood for digging into F-CPU details :-/ > I am well aware that the "zero" and "msb" conditions contain problems > but i can live with them and compiler problems are ... compiler problems. It's not only a `compiler problem', it's a code generation problem in general: You'll also have to include extra masking (or shift) instructions when you write in assembler. > It's already a big chance that the whole architecture is still alive > after almost 4 years. Alive but not unchanged. And we're still learning what's good and what's not so good, which instructions to use and which to avoid -- working on gcc and fctools was rather enlightening sometimes. This feedback will help us to refine the architecture, and close all the open holes in it. In fact, I wish we would get more feedback from SW people. That's the reason why I finished the assembler/disassembler/linker/emulator quartet before I go hacking VHDL again (it's about time for eu_div, isn't it?). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Mar 3 02:04:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXHo-0003LY-00 for ; Tue, 11 Mar 2003 01:06:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:06:28 +0100 (CET) Received: (qmail 3518 invoked by uid 0); 3 Mar 2003 00:58:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 3 Mar 2003 00:58:26 -0000 Received: by moria.seul.org (Postfix) id 175D733B6B; Sun, 2 Mar 2003 19:58:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 041A133B7E; Sun, 2 Mar 2003 19:58:23 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 1BE4333B6B for ; Sun, 2 Mar 2003 19:58:23 -0500 (EST) Received: from f-cpu.org (lcbv2-1-13.n.club-internet.fr [213.44.12.13]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 53D1919A0 for ; Mon, 3 Mar 2003 01:58:19 +0100 (CET) Message-ID: <3E62AA11.1080408@f-cpu.org> Date: Mon, 03 Mar 2003 02:04:17 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] OOC vs. OOE (scoreboard & tomasulo) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >Hello, > >I know many men here have too much work but I'd >like to initiate short thread in order to get >deeper knowledge in field. > >I was looking for some Subj. related infos but >haven't found much. Thus I learned Tomasulo, >looked at Sparc, MIPS and Alpha and tried to >create my own opinion. I'd like to head (personal) >feeleing and comments of others people here >(which is valuable for me by the way). > >At the first glance OOC is much simpler to implement. >In OOE you have to think about >- ROB because of exceptions and control speculation >- for tomasulo based we need expensive CDB and many > comparators (but bypass needs them anyway) > >Similary gains of OOE more specificaly Tomasulo like >designs: >- ISA is the same for different number and speed of EUs > now look at the latest x86 architectures : their organisation has changed so radically in the last years that it is impossible to develop any "optimised" software for several platforms. all that matters today is the compatibility with the ISA. so let's start with a simple architecture... >- adaptation of EU controling to actual data flow including > dynamic loop unrolling >- can go around memory latency (!) > this one is very important, but the complexity and its price is probably too high for today's F-CPU team .... >- simple reg. renaming allows to have much less architectural > register without sacrifying performance > register renaming = more transistors and longer pipeline. >- simpler datapath, you can do 4 way cpu with only 1r1w > regsets > >So what's the real performance (let's forget about ISA binary >compatibility thing) difference between OOE & OOC ? >IMHO it is memory load. > there is another one : today (as of y2k, as opposed to the 60's) the pipeline depths and clock frequencies have increased a lot. Tomasulo and/or OOOE can compensate for several cycles but the "really hurting" latencies are from cache misses from "remote" memories, either SDRAM or located on the HDD or another CPU... and here, this lasts more than the few cycles that OOOE can compensate for. >When tomasulo based CPU hits memory load it starts it and >goes further. All dependent instructions are filled into >reservation stations (RS) near (!) their EUs. > this means that it is able to compensate for L1, maybe L2 cache misses in good conditions. This is equivalent to the reordering capability of compilers. So let's spare some complex reordering stuffs that consume power and dev/debug time .... >We can load many dataflow traces into CPU this way (limited >by number of RS but not neccessarily by internal register >set size) and these get started asynchronously by memory >subsystem when data arrives from slower memory. > >All other EUs are typicaly semipredictable (we know exact >latency when we know datasize) and we can always schedule >them well for OOC. But loads are killers > right, but we can't do magic : memory latency increases as the memory's size does. it's the compiler's job to organise data so cache misses are reduced, and the user's task to code cleanly enough to allow the compiler to do its work.... > - prefetch/preload >is nice but often you don't know correct address in advance. > it's possible for most numerical and DSP/imaging code so it's ok.... >Take simple case - deleting element from double linked >list. You need to load x->prev and x->next and update them. >x->prev->next = x->next; >x->next->prev = x->prev; >load [r1],r3 >load [r1+8],r4 >store r4,[r3+8] >store r3,[r4] > > you chose one of the worst cases .... F-CPU is not well adapted to do linked lists. However if you need max performance, you can probably find a way to interleave memory references (but then you'll need to manage several LL at the same time) >Assume L1 latency 2 and L2 latency 20. > that's not exacly that for FC0. L0 is around 3 cycles (that is : the minimum number of cycles to get data from the LSU), L1 is a few cycles more but triggered on miss (let's say : around 4 cycles on top of the LSU/L0 cycles). L2 is not well known because it depends on what block is chosen (it's usually a "standard cell") >If x->prev is in L2 cache and x->next is in L1 cache then >1-issue tomasulo will in 4 cycles fill 4 RS then second >load is finished which also starts the first store. >Second load-store is started after some time later and >we can run other code in between. >OOC cpu will stall at first load for 20 cycles .. > > that's the "price" for a simple core. And you can see that even though it's simple, it's far from finished. Maybe an OOOE core will be done for FC1. The debate is open for a long time but let's finish FC0 now :-) >So that do you think can good OOC perform better than >good OOE for generic code ? > the problem is more of managing complexity : FC0 is already complex enough to not be finished. If OOOE was used, then i believe that no code would be already available.... >I don't think so if latency of memory load will stay >to be highly undeterministic. > > hints can come from the program, from tracing and many other methods... >------- >Don't read below if your mind if labile ;) >If memory load is the only problem, what about something >like "machine code select(2)" for OOC ? I mean unix API >select(2). > >Like to say in asm - now stall on these (started) four >loads and execute part of code (follows) depending on >which load completed. For linked list above it would read: >xload [r1],r3 >xload [r1+8],r4 >wait r3,a,1,r4,b,1,c >a:store r4,[r3+8] >b:store r3,[r4] >c: > >xload is non-blocking load (like prefetch), wait line stands >for: >wait for r3, if completes, schedule 1 insn at relative >address a ... similarly for r4, when both finished then >continue at c. >Probably you got the (crazy) idea .. it is for thinking. >The idea is too fresh and maybe I'll dumpt it tomorrow. > >But still I'm interested in yout ide about Subj. > > as nicO said, the main problem is to know how to not break the whole architecture in order to allow context switches and interrupts. Theoretically, it is possible to make a conditional instruction based on whether the load or store is completed. Though, for the load, it's far from sure, because i remember that the load HAS TO COMPLETE before another instruction is executed, because otherwise it could leave the pipeline in a state where an interrupt or fault could not be recoverable. Imagine you do : load [Rx] -> Ry store [Rv] <- Rw now, imagine that the load 'passes' but is not completed. store traps for whatever reason (not aligned, page fault ...) and the SRB is started : upon return, SRB will restore the old value of Ry. Well, i agree : it's the "old SRB" version, it could be possible (and i presume, it's necessary) to add a LSU sync to it (the register is "dirty" as long as the load and store is not completed). But i have come to the conclusion that memory and the compiler/source code are the main limits, whatever sophisticated CPU is made. Look at the most recent CPUs and the memory is still the main problem, much more than execution strategies or ISA problems... So i take this as a "fixed limit" and even when compared to a competing MIPS or similar architecture, the memory structure of F-CPU is not that bad.... Now, to answer your question, it is maybe possible to include conditional instructions based on the availability of loaded data, but in the end .... what does that change ? take a look at usual code : they don't care to know whether data are ready, they just want to use them. So the "data loaded" condition would be useless.... However, a SMT core would compensate for this more easily. >good night, >devik > > have fun, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Mar 2 23:10:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXHj-0003LY-01 for ; Tue, 11 Mar 2003 01:06:23 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:06:23 +0100 (CET) Received: (qmail 17960 invoked by uid 0); 2 Mar 2003 22:10:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 2 Mar 2003 22:10:17 -0000 Received: by moria.seul.org (Postfix) id 602D633B62; Sun, 2 Mar 2003 17:10:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89AA933FA5; Sun, 2 Mar 2003 17:10:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id BD03F33B62 for ; Sun, 2 Mar 2003 17:10:13 -0500 (EST) Received: from a76-137.dialup.iol.cz ([194.228.137.76] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18pbes-0006R4-00 for f-cpu@seul.org; Sun, 02 Mar 2003 23:10:10 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18pben-0000Gj-00 for f-cpu@seul.org; Sun, 02 Mar 2003 23:10:05 +0100 Date: Sun, 2 Mar 2003 23:10:05 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] OOC vs. OOE (scoreboard & tomasulo) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I know many men here have too much work but I'd like to initiate short thread in order to get deeper knowledge in field. I was looking for some Subj. related infos but haven't found much. Thus I learned Tomasulo, looked at Sparc, MIPS and Alpha and tried to create my own opinion. I'd like to head (personal) feeleing and comments of others people here (which is valuable for me by the way). At the first glance OOC is much simpler to implement. In OOE you have to think about - ROB because of exceptions and control speculation - for tomasulo based we need expensive CDB and many comparators (but bypass needs them anyway) Similary gains of OOE more specificaly Tomasulo like designs: - ISA is the same for different number and speed of EUs - adaptation of EU controling to actual data flow including dynamic loop unrolling - can go around memory latency (!) - simple reg. renaming allows to have much less architectural register without sacrifying performance - simpler datapath, you can do 4 way cpu with only 1r1w regsets So what's the real performance (let's forget about ISA binary compatibility thing) difference between OOE & OOC ? IMHO it is memory load. When tomasulo based CPU hits memory load it starts it and goes further. All dependent instructions are filled into reservation stations (RS) near (!) their EUs. We can load many dataflow traces into CPU this way (limited by number of RS but not neccessarily by internal register set size) and these get started asynchronously by memory subsystem when data arrives from slower memory. All other EUs are typicaly semipredictable (we know exact latency when we know datasize) and we can always schedule them well for OOC. But loads are killers - prefetch/preload is nice but often you don't know correct address in advance. Take simple case - deleting element from double linked list. You need to load x->prev and x->next and update them. x->prev->next = x->next; x->next->prev = x->prev; load [r1],r3 load [r1+8],r4 store r4,[r3+8] store r3,[r4] Assume L1 latency 2 and L2 latency 20. If x->prev is in L2 cache and x->next is in L1 cache then 1-issue tomasulo will in 4 cycles fill 4 RS then second load is finished which also starts the first store. Second load-store is started after some time later and we can run other code in between. OOC cpu will stall at first load for 20 cycles .. So that do you think can good OOC perform better than good OOE for generic code ? I don't think so if latency of memory load will stay to be highly undeterministic. ------- Don't read below if your mind if labile ;) If memory load is the only problem, what about something like "machine code select(2)" for OOC ? I mean unix API select(2). Like to say in asm - now stall on these (started) four loads and execute part of code (follows) depending on which load completed. For linked list above it would read: xload [r1],r3 xload [r1+8],r4 wait r3,a,1,r4,b,1,c a:store r4,[r3+8] b:store r3,[r4] c: xload is non-blocking load (like prefetch), wait line stands for: wait for r3, if completes, schedule 1 insn at relative address a ... similarly for r4, when both finished then continue at c. Probably you got the (crazy) idea .. it is for thinking. The idea is too fresh and maybe I'll dumpt it tomorrow. But still I'm interested in yout ide about Subj. good night, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Credit_Doctor_262@charter.net Sun Mar 2 08:08:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXHA-0003LY-00 for ; Tue, 11 Mar 2003 01:05:48 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:05:48 +0100 (CET) Received: (qmail 24079 invoked by uid 0); 2 Mar 2003 07:00:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 2 Mar 2003 07:00:59 -0000 Received: by moria.seul.org (Postfix) id 474B433B56; Sun, 2 Mar 2003 02:00:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C45AA33FA5; Sun, 2 Mar 2003 02:00:56 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 217.126.60.162 (217-126-60-162.uc.nombres.ttd.es [217.126.60.162]) by moria.seul.org (Postfix) with SMTP id C5BE833B56 for ; Sun, 2 Mar 2003 02:00:23 -0500 (EST) Received: from ssymail.ssy.co.kr ([113.236.31.212]) by a231242.upc-a.chello.nl with local; Mar, 01 2003 11:45:36 PM +0600 Received: from [135.12.72.250] by ssymail.ssy.co.kr with SMTP; Mar, 01 2003 11:04:31 PM -0100 From: Orlondo To: f-cpu@seul.org Subject: [f-cpu] Re: ABOUT YOUR CREDIT........... gmk Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sun, 2 Mar 2003 01:08:02 -0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Message-Id: <20030302070023.C5BE833B56@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

We can fix your credit. We are very successful at getting bankruptcies, judgments, tax liens, foreclosures, late payments, charge-offs, repossessions, and even student loans removed from a persons credit report. To find out more go to http://www.cjlinc.net.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  qbctrjfsmdjrdcgojtgxuaklrucrsunnxru ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Mar 1 21:48:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXGq-0003LY-00 for ; Tue, 11 Mar 2003 01:05:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:05:28 +0100 (CET) Received: (qmail 29760 invoked by uid 0); 1 Mar 2003 23:51:41 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 1 Mar 2003 23:51:41 -0000 Received: by moria.seul.org (Postfix) id E129F33B55; Sat, 1 Mar 2003 18:51:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB5FE33B6A; Sat, 1 Mar 2003 18:51:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id 46AC633B55 for ; Sat, 1 Mar 2003 18:51:35 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA02280; Sat, 1 Mar 2003 21:48:35 +0100 Message-ID: <20030301214835.03274@thrai.stud.uni-hannover.de> Date: Sat, 1 Mar 2003 21:48:35 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <3E608AF4.1070603@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3E608AF4.1070603@f-cpu.org>; from Yann Guidon on Sat, Mar 01, 2003 at 11:27:00AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Mar 01, 2003 at 11:27:00AM +0100, Yann Guidon wrote: > however the F-CPU has no "FPU status flag register". Not as a general register, that's right. But... > It can be implemented as a SR (which is OK because > it enforces ordering of the instructions, good for future architectures) > and/or by a specific instruction that acts as a "fence" (ok too, > because it would then only serialize the FP pipeline in a split arch.) Exactly. For FPU status, we may choose a serializing instruction or a special register (or both). An `fstat' instruction is probably more convenient. In order to be most useful, it should perform an atomic swap operation: fstat rx, ry // ry := status; status := rx where r0 in either slot means `don't': `fstat r0, ry' will only read the status, `fstat rx, r0' will only write (clear?) it. The instruction should also take an optional `w' suffix (for `wait') that lets us turn the fence on and off as needed: fstatw rx, ry // complete all outstanding FP operations first fstat rx, ry // execute and return immediately Note that `fstatw r0, r0' may be used as an FP serializing instruction with no further effect. There is, however, a big problem with FP status: Since instructions complete out-of-order, it's undefined which instruction the status comes from. You can only query the status of a series of FP instructions collectively, unless you serialize the instruction stream after every FP operation (which is going to be slooooooooow). With or without exceptions, we'll need something to control the operating modes of the FPU (set the default rounding mode, for example). That is, there should be a (hidden) control register that can be read and written with an `fcntl' instruction that doesn't have to wait for the previous FP instruction to complete: When an ordinary FP operation starts, it will (at least virtually) copy the current settings; that is, an immediately following `fcntl' instruction won't affect its result. Syntax and semantics could be similar to those of `fstat', except that a different register is affected. Note: these instructions have nothing to do with the Unix `fstat()' and `fcntl()' system calls ;-) > And of course there is a condition code left, we have > zero, LSB and MSB, and the remaining code can be assigned > to NaN or error condition, by reading a specific bit in the register > (so it's not the same as a "FPU status register", in the principle, > because there is no such thing as "sticky bits" and hacks like that). I currently support the `nan' condition in the emulator, but its use is limited because it only works with 64-bit data, similar to the `msb' condition. I'd rather add an `ftest' instruction that checks its operand and returns a `type indicator' as follows: bit 0: 0 => sign == 0 1 => sign == 1 bit 1: 0 => mantissa == 0 1 => mantissa != 0 bit 3...2: 00 => exponent == 0...0 01 => exponent == 1...1 1x => exponent == any other value (*) bit max...4 are reserved (set to 0). This nicely translates to: 3210 exponent mant sign type ======================================= 0000 e==0...0 m==0 s==0 +zero 0001 e==0...0 m==0 s==1 -zero 0010 e==0...0 m!=0 s==0 +denormal 0011 e==0...0 m!=0 s==1 -denormal 0100 e==1...1 m==0 s==0 +infinity 0101 e==1...1 m==0 s==1 -infinity 0110 e==1...1 m!=0 s==0 +nan(m) 0111 e==1...1 m!=0 s==1 -nan(m) 1xx0 e==other any s==0 +normal (*) 1xx1 e==other any s==1 -normal (*) (*) may be further subdivided in later versions That can be done with a handful of and/or gates, and can also be implemented for 32-bit (float) and SIMD modes. Of course it could also be emulated easily with ordinary integer instructions. In either case, it can be used to implement the ISO C99 `fpclassify', `isfinite', `isinf', `isnan', `isnormal' and `signbit' functions. We also need a decent FP compare instruction (the one documented in the manual is crap). Here's a more reasonable definition: fcomp r3, r2, r1 Contents of r1: bit 0 = 1 if r2 < r3 bit 1 = 1 if r2 == r3 bit 2 = 1 if r2 > r3 bit max...3 are reserved (set to 0) The following additional rules shall apply: - if any operand is a NAN, the result is 0 (a NAN equals nothing, not even itself) - zero equals zero, regardless of sign - any other value equals itself - the order of values is: +inf > +normal > +denormal > zero > -denormal > -normal > -inf This allows us to test for all possible conditions in a uniform manner: (r1 & 001) != 0 => r2 < r3 (r1 & 010) != 0 => r2 == r3 (r1 & 011) != 0 => r2 <= r3 (r1 & 100) != 0 => r2 > r3 (r1 & 101) != 0 => r2 != r3 (r1 & 110) != 0 => r2 >= r3 (r1 & 111) != 0 => ordered (that is, any of the above) (r1 & 111) == 0 => unordered (at least one operand was NAN) The `less' condition can also be evaluated directly by a `jmpl' or `movel' instruction. Of course `fcomp' will also have float and SIMD variants. Note that we have to implement most checks anyway: - all FP operations must check if their operands are NAN - many instructions also handle ±INF specially - fiaprx/fdiv must check for x != 0 - fsqrtiaprx/fsqrt must check for x >= 0 - flog must check for x > 0 and so on. The hardware will already be there, we just have to make use of it. To cut a long story short: I have added `fcomp' and `ftest' to the FC tools (Cedric, do you still listen?): ========= fcomp (FP compare) instruction ========= [s]fcomp[.f|.d] r3, r2, r1 r1 = fp_compare(r2, r3) Result encoded as described above (please cut&paste) Instruction encoding: 31...24 OP_FCOMP 23...22 FP size bits (00 = float, 01 = double, 1x = reserved) 21 SIMD flag 20...18 unused (0) 17...12 r3 11... 6 r2 5... 0 r1 ========= ftest (FP test) instruction ========= [s]ftest[.f|.d] r2, r1 r1 = fp_classify(r2) Result encoded as described above (please cut&paste) Instruction encoding: 31...24 OP_FTEST 23...22 FP size bits (00 = float, 01 = double, 1x = reserved) 21 SIMD flag 20...12 unused (0) 11... 6 r2 5... 0 r1 ========= end of manual pieces ========= Note: there is no `x' flag because these instructions never fail. I'll also add `fcntl' and `fstat' if there are no objections, but I haven't fully designed the details yet (in particular, the contents of the status and control registers are still undefined). Finally, back to condition codes. Since the `msb' and `nan' conditions more and more turn out to be useless (and also badly designed), why don't we drop them? It also turned out during the gcc port that the `zero' condition is particularly hard to handle (it sometimes needs extra zero-extend instructions), so we may as well redesign the whole thing. My suggestion is to check only the appropriate chunk, and to also take SIMD into account. With only two conditions (`lsb' and `zero', and of course their negations) we could use the third bit as an `all/any' indicator: if SIMD = 0 then branch if condition is true for chunk 0 elsif all = 1 then branch if condition is true for all chunks else branch if condition is true for any chunk end if Of course this will add size and simd flags to all conditional operations (in particular, jmpcc). On the other hand, conditional instructions would become more flexible, especially with wide (> 64 bits) registers. > hoping to revive this list, I guess that was enough revival for a single mail, wasn't it? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Mar 1 11:27:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXG3-0003LY-00 for ; Tue, 11 Mar 2003 01:04:39 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:04:39 +0100 (CET) Received: (qmail 24360 invoked by uid 0); 1 Mar 2003 10:15:10 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 1 Mar 2003 10:15:10 -0000 Received: by moria.seul.org (Postfix) id 4319133E7D; Sat, 1 Mar 2003 05:15:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8481A33E71; Sat, 1 Mar 2003 05:15:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id ADD9033F50 for ; Sat, 1 Mar 2003 05:15:06 -0500 (EST) Received: from f-cpu.org (lcbv4-2-166.n.club-internet.fr [213.44.93.166]) by relay-2m.club-internet.fr (Postfix) with ESMTP id AD2EE1761 for ; Sat, 1 Mar 2003 11:15:04 +0100 (CET) Message-ID: <3E608AF4.1070603@f-cpu.org> Date: Sat, 01 Mar 2003 11:27:00 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >FYI (for nicO especially): > >While I was thinking whether FP precise traps are needed, >I found article >http://cch.loria.fr/documentation/IEEE754/ACM/hauser.pdf >which describes pros and cons. He concludes that exceptions >are not so needed (they are optional feature of standard) >if you implement FPU status flags. There are better supported >by languages and math librararies. >For CPU designer it could mean possibility of impresise >exceptions use because getfpflags() should act as FP instruction >fence... > > interesting thought... however the F-CPU has no "FPU status flag register". It can be implemented as a SR (which is OK because it enforces ordering of the instructions, good for future architectures) and/or by a specific instruction that acts as a "fence" (ok too, because it would then only serialize the FP pipeline in a split arch.) And of course there is a condition code left, we have zero, LSB and MSB, and the remaining code can be assigned to NaN or error condition, by reading a specific bit in the register (so it's not the same as a "FPU status register", in the principle, because there is no such thing as "sticky bits" and hacks like that). hoping to revive this list, >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Feb 28 16:53:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXG2-0003LY-01 for ; Tue, 11 Mar 2003 01:04:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:04:38 +0100 (CET) Received: (qmail 6328 invoked by uid 0); 1 Mar 2003 10:03:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 1 Mar 2003 10:03:02 -0000 Received: by moria.seul.org (Postfix) id 9073833E6C; Sat, 1 Mar 2003 05:03:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 14A2A33E6F; Sat, 1 Mar 2003 05:03:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4BC1833E6C for ; Sat, 1 Mar 2003 05:02:59 -0500 (EST) Received: from a71-137.dialup.iol.cz ([194.228.137.71] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18p3pW-000760-00 for f-cpu@seul.org; Sat, 01 Mar 2003 11:02:55 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18ompL-0000UC-00 for f-cpu@seul.org; Fri, 28 Feb 2003 16:53:35 +0100 Date: Fri, 28 Feb 2003 16:53:35 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] IEEE FP exceptions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N FYI (for nicO especially): While I was thinking whether FP precise traps are needed, I found article http://cch.loria.fr/documentation/IEEE754/ACM/hauser.pdf which describes pros and cons. He concludes that exceptions are not so needed (they are optional feature of standard) if you implement FPU status flags. There are better supported by languages and math librararies. For CPU designer it could mean possibility of impresise exceptions use because getfpflags() should act as FP instruction fence... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From suleadams@hknetmail.com Thu Feb 27 13:55:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXDn-0003LY-01 for ; Tue, 11 Mar 2003 01:02:19 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:02:19 +0100 (CET) Received: (qmail 28931 invoked by uid 0); 27 Feb 2003 12:54:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 27 Feb 2003 12:54:00 -0000 Received: by moria.seul.org (Postfix) id C700D33DC8; Thu, 27 Feb 2003 07:53:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C920933DCA; Thu, 27 Feb 2003 07:53:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from ab17c1715.com (unknown [195.166.233.241]) by moria.seul.org (Postfix) with SMTP id 2A89333DC8 for ; Thu, 27 Feb 2003 07:53:34 -0500 (EST) From: "Mr Sule Adams" To: f-cpu@seul.org Date: Thu, 27 Feb 2003 13:55:13 +0100 Subject: [f-cpu] request X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030227125334.2A89333DC8@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N From=3BMr Sule Adams Private Email Address=3A suleadams=40netscape=2Enet Dear Sir=2C Good day=2E I am a senior banker in one of the banks in Nigeria=2E I wish to solicit your cooperation in a joint venture that I am going to explain below=2E On June 8=2C 1997=2C an Irish Oil Consultant=2FContractor with Nigerian National Petroleum Cooperation =28NNPC=29 Mr=2E Morris Power placed a deposit for twelve calendar months valued at US$18M =28Eighteen Million US Dollars=29 in my Branch=2E On maturity=2C I sent a routine notification to his forwarded address in Nigeria but got no reply=2E After several months we sent a reminder and finally we discovered from his contract employer =28Nigerian National Petroleum Corporation=29 that Mr=2E Morris Power died in an auto crash accident in Nigeria=2E All attempts by the Bank to trace his next of kin were fruitless=2E I therefore made further investigation and discovered that Mr=2E Morris Power did not declare any next of kin or relations in all his official documents including his deposit document in my bank=2E The total sum and accrued interest are still in my bank in a dormant account=2E No one has ever come forward to claim it=2E According to Nigerian banking law=2C after five years=2C the money will revert to the ownership of the Nigerian Government if the account owner is certified dead and nobody comes forward to claim it as his relation=2E As a result=2C I am looking for a foreigner who will stand in as the beneficiary=2Fnext of kin to Mr=2E Morris Power=2E It is to play this role that I write to request your cooperation=2E If you agree with my proposal=2C all you have to do is to send to me a bank account anywhere in the world=2C your address=2C telephone and fax numbers to enable me arrange all payment documents of the money in your favour as a relation of the late Mr=2E Morris Power=2E The money will then be paid into the account legally for us to share=2E This payment will be an in-house arrangement made by our bank hence=2C no body will ask you questions or make enquiry to know whether you are related to the late Mr=2E Morris Power or not=2E Furthermore=2C there is no risk involved I will use my position in the bank to arrange the legal payment documents in your favour as a relation of the Late Mr=2E Morris Power=2E If you accept my proposal=2C please=2C reply through my private email address=3A suleadams=40netscape=2Enet Thanks in anticipation of your cooperation=2E Best regards=2C Sule Adams ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From laupregme@speedsurf.pacific.net.ph Mon Feb 24 10:29:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXAV-0003LY-00 for ; Tue, 11 Mar 2003 00:58:55 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:58:55 +0100 (CET) Received: (qmail 11778 invoked by uid 0); 24 Feb 2003 09:55:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 24 Feb 2003 09:55:53 -0000 Received: by moria.seul.org (Postfix) id 85A8A33C09; Mon, 24 Feb 2003 04:55:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9CB0133C0F; Mon, 24 Feb 2003 04:55:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from dhs (unknown [202.175.245.148]) by moria.seul.org (Postfix) with ESMTP id F301733C09 for ; Mon, 24 Feb 2003 04:55:38 -0500 (EST) Received: from localhost ([202.175.245.148]) by dhs with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Feb 2003 17:29:05 +0800 X-Sender: laupregme@speedsurf.pacific.net.ph From: Jonathan Paul Calledo To: f-cpu@seul.org Date: Mon, 24 Feb 2003 17:29:05 +0800 Subject: [f-cpu] Learn and Earn...Register For FREE! MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 24 Feb 2003 09:29:05.0796 (UTC) FILETIME=[2CF4BC40:01C2DBE7] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello: I'm sending you this letter to introduce to you a legitimate home based business for a good extra income. So I didn't waste my time to share to you this tremendous online business opportunity that really works. But if this letter bothers you at any cost, please accept my deepest apology for doing so. But if not, just lend me just little of your time and read this. My name is Jonathan Paul Calledo. I would like to invite you to join the time tested online opportunity. For the past 5 years the program created a great name in the online network marketing world. It generates tremendous number of subscriptions worldwide. It produces many successful individuals in all walks of life. It has an excellent track record to date. The marketing plan has been improved frequently to adapt to the ever changing online market and to give the members the maximum benefits and satisfaction. It has a high payout compensation plan with unlimited and secured residual income streams. A monthly compensation that you can depend on. The activities are very simple. No experience needed. It is designed to work right in your home. If you have 10-15 hours a week, then you can easily succeed in this business. It has an excellent online training site where you can learn how to succeed in the online market. The lessons covers, basic and professional prospecting, leadership, tap root networking, etc. It has a powerful support system. Its the best support system I ever encountered. A team of upline sponsors that will assist you, guide you and support you in every step of the way to success. The team would even help you build up your own downlines. That's what we call TEAM work. If you want to have more information about this business opportunity, just get a FREE membership ID by sending an email to jpbc_3@eudoramail.com with the subject "REGISTER ME FOR FREE" and put your Firstname and Lastname in the body of your email. As a Free member you can enjoy lots of benefits and even start earning. It has NO COST, NO RISK, NO OBLIGATION, No COMMITMENT, and you can cancel your membership anytime you want. You have nothing to lose and definitely a lot to gain. Test drive our program and we will show you how to do the business. We even build up downlines for you. You can watch your downline grow and have the opportunity to earn from them. JOIN FOR FREE! LEARN and EARN! Sincerely yours, Jonathan Paul Calledo jpbc_3@eudoramail.com Removal Instruction: Send email to jonathan22@eudoramail.com with the subject "Remove Me" if you wish to be remove from my mailing list and to no longer receive emails from me. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Feb 24 08:21:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXAU-0003LY-00 for ; Tue, 11 Mar 2003 00:58:54 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:58:54 +0100 (CET) Received: (qmail 6677 invoked by uid 0); 24 Feb 2003 08:34:24 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 24 Feb 2003 08:34:24 -0000 Received: by moria.seul.org (Postfix) id 5AB5433B81; Mon, 24 Feb 2003 03:34:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B4E7F33C0F; Mon, 24 Feb 2003 03:34:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 82A7A33B81 for ; Mon, 24 Feb 2003 03:34:21 -0500 (EST) Received: from a37-137.dialup.iol.cz ([194.228.137.37] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18nE3s-0005be-00 for f-cpu@seul.org; Mon, 24 Feb 2003 09:34:09 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18nCvo-0000BT-00 for f-cpu@seul.org; Mon, 24 Feb 2003 08:21:44 +0100 Date: Mon, 24 Feb 2003 08:21:44 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] stats on insn pairing In-Reply-To: <20030224231321.32446064.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N For all. Technically I take every insn and account all pairs of the insn with all others whose use its output. > So you're "pair" is for instruction that have a fanout of 1 ? > > nicO > > On Sun, 23 Feb 2003 13:00:37 +0100 (CET) > devik wrote: > > > Sorry I was in hurry. I did data flow analysis on gcc > > internal repesetation after last scheduling and computed: > > 1) avg fanout, how many insn uses result of single insn > > 2) fanout histogram > > 3) register value producer-consumer pairs > > 4) same as 3 but distinguishing insns with and without > > immediate values > > > > Notes: > > store-store link is because of post-increment dependency > > const_int-plus is adding of const in 2 insns because of > > too big value > > move-move is value copying (creating bigger fanout) > > > > hope it is more clear, > > devik > > > > On Fri, 21 Feb 2003, Michael Riepe wrote: > > > > > On Fri, Feb 21, 2003 at 04:37:03PM +0100, devik wrote: > > > > > > > while discussing with nico I wanted to know read insn-insn > > > > pairing and value fanout. I computed stats for gcc source > > > > and linux kernel one. > > > > They are attached ... > > > > > > Does `pair' mean that the second insn consumes a value produced by > > > the first insn? Or does it just follow immediately in the > > > instruction stream? > > > > > > -- > > > Michael "Tired" Riepe > > > "All I wanna do is have a little fun before I die" > > > ************************************************************* > > > To unsubscribe, send an e-mail to majordomo@seul.org with > > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > > > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Feb 23 13:00:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXA3-0003LY-00 for ; Tue, 11 Mar 2003 00:58:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:58:27 +0100 (CET) Received: (qmail 17247 invoked by uid 0); 23 Feb 2003 12:20:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 23 Feb 2003 12:20:28 -0000 Received: by moria.seul.org (Postfix) id DAEDD33B83; Sun, 23 Feb 2003 07:20:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 518DE33B88; Sun, 23 Feb 2003 07:20:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3164633B83 for ; Sun, 23 Feb 2003 07:20:25 -0500 (EST) Received: from a19-137.dialup.iol.cz ([194.228.137.19] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18mv7E-0000KR-00 for f-cpu@seul.org; Sun, 23 Feb 2003 13:20:21 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18muo9-0000IQ-00 for f-cpu@seul.org; Sun, 23 Feb 2003 13:00:37 +0100 Date: Sun, 23 Feb 2003 13:00:37 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] stats on insn pairing In-Reply-To: <20030221185046.05032@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Sorry I was in hurry. I did data flow analysis on gcc internal repesetation after last scheduling and computed: 1) avg fanout, how many insn uses result of single insn 2) fanout histogram 3) register value producer-consumer pairs 4) same as 3 but distinguishing insns with and without immediate values Notes: store-store link is because of post-increment dependency const_int-plus is adding of const in 2 insns because of too big value move-move is value copying (creating bigger fanout) hope it is more clear, devik On Fri, 21 Feb 2003, Michael Riepe wrote: > On Fri, Feb 21, 2003 at 04:37:03PM +0100, devik wrote: > > > while discussing with nico I wanted to know read insn-insn > > pairing and value fanout. I computed stats for gcc source > > and linux kernel one. > > They are attached ... > > Does `pair' mean that the second insn consumes a value produced by the > first insn? Or does it just follow immediately in the instruction > stream? > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me465156@members.interq.or.jp Fri Feb 21 13:12:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX8B-0003LY-00 for ; Tue, 11 Mar 2003 00:56:31 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:56:31 +0100 (CET) Received: (qmail 30186 invoked by uid 0); 21 Feb 2003 12:14:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 21 Feb 2003 12:14:03 -0000 Received: by moria.seul.org (Postfix) id 608D633B7B; Fri, 21 Feb 2003 07:13:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B291133B7F; Fri, 21 Feb 2003 07:13:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from a1a1a1 (pl324.nas927.o-tokyo.nttpc.ne.jp [61.197.107.68]) by moria.seul.org (Postfix) with ESMTP id EC74D33B7B for ; Fri, 21 Feb 2003 07:13:49 -0500 (EST) Received: from 5-C ([192.168.0.2]) by a1a1a1 (8.9.3+3.2W/3.7W) with SMTP id VAA19978; Fri, 21 Feb 2003 21:15:58 +0900 Message-Id: <200302211215.VAA19978@a1a1a1> From: =?iso-2022-jp?B?bWU0NjUxNTY=?= To: =?iso-2022-jp?B?MjAwMjI=?=@a1a1a1.seul.org Date: Fri, 21 Feb 2003 21:12:55 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRkMlQCVNPnBKcxsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> ‚³‚í‚â‚©LŽÐ ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463886@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢ ¦Ä”zM‹‘”Û‚©‚ç‚P“ú‘OŒã‚Ń[ƒ‹ƒAƒhƒŒƒX‚ð휒v‚µ‚Ü‚· §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218@@ ™\\\™\\\™\\\™\\\™\\\™\\\™ ‚±‚̃[ƒ‹‚ðŽó‚¯Žæ‚ç‚ꂽ•ûA1’ʂɂ‚«100‰~·‚µã‚°‚Ü‚·B 5000‰~•ª’™‚Ü‚è‚Ü‚µ‚½‚犷‹à’v‚µ‚Ü‚·‚Ì‚Å‚²¿‹‰º‚³‚¢B @@š@ƒoƒi[‚ð‚Í‚Á‚ĉº‚³‚é•û•åW‚µ‚Ü‚·I@š ”„‚èã‚°‚Ì10“‚ði’悵‚Ü‚·B Å’á•Ûá‚Æ‚µ‚ÄŒŽŠz10–œ‰~AŒŽ‚É50–œ‰~‚ÍŠmŽÀ‚Å‚·B ™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu ‚`‚u’j—D•åWE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/ ™\\\™\\\™\\\™\\\™\\\™\\\™ ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽE–h”ƃOƒbƒYE‹à–ׂ¯î•ñ‚È‚Ç@ @@@š@‚»‚Ì‘¼î•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Tue Feb 18 18:09:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX58-0003LY-00 for ; Tue, 11 Mar 2003 00:53:22 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:53:22 +0100 (CET) Received: (qmail 16857 invoked by uid 0); 18 Feb 2003 17:09:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 18 Feb 2003 17:09:54 -0000 Received: by moria.seul.org (Postfix) id 2ECCF33CF3; Tue, 18 Feb 2003 12:09:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ABC2633DBF; Tue, 18 Feb 2003 12:09:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id 2673B33CF3; Tue, 18 Feb 2003 12:09:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id 23E49FAD29 for ; Tue, 18 Feb 2003 12:09:46 -0500 (EST) Date: Tue, 18 Feb 2003 12:09:46 -0500 (EST) From: Graham Seaman X-X-Sender: graham@moria.mit.edu To: f-cpu@seul.org Subject: [f-cpu] [leon_sparc] GHDL update (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ---------- Forwarded message ---------- Date: Tue, 18 Feb 2003 18:05:28 +0100 From: Jiri Gaisler Reply-To: leon_sparc@yahoogroups.com To: leon_sparc@yahoogroups.com Subject: [leon_sparc] GHDL update The latest version of GHDL (GNU VHDL compiler) is now capable to compile and simulate LEON (if the flag --ieee=synopsys is used). However, simulation is very slow: about 1 instruction/minute compared to modelsim 10,000/minute. Nevertheless, it is a promising development... Jiri. -- ------------------------------------------------------------------------- Gaisler Research, Stora Nygatan 13, 41108 Goteborg, Sweden, +46-31802405 fax: +46-31802407 email: info@gaisler.com, home page: www.gaisler.com ------------------------------------------------------------------------- Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Feb 21 16:37:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX8W-0003LY-00 for ; Tue, 11 Mar 2003 00:56:52 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:56:52 +0100 (CET) Received: (qmail 27103 invoked by uid 0); 21 Feb 2003 15:37:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Feb 2003 15:37:31 -0000 Received: by moria.seul.org (Postfix) id 678FA33B53; Fri, 21 Feb 2003 10:37:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E24C833B86; Fri, 21 Feb 2003 10:37:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id F0EF533B53 for ; Fri, 21 Feb 2003 10:37:15 -0500 (EST) Received: from a82-137.dialup.iol.cz ([194.228.137.82] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18mFEb-00062p-00 for f-cpu@seul.org; Fri, 21 Feb 2003 16:37:10 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18mFEV-0001sc-00 for f-cpu@seul.org; Fri, 21 Feb 2003 16:37:03 +0100 Date: Fri, 21 Feb 2003 16:37:03 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] stats on insn pairing Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2077238529-1045841823=:529" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-2077238529-1045841823=:529 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, while discussing with nico I wanted to know read insn-insn pairing and value fanout. I computed stats for gcc source and linux kernel one. They are attached ... devik --8323328-2077238529-1045841823=:529 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=stt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=stt dmFsdWUgZmFub3V0OiAxLjQzNjAzMzEzMzkxNjI0DQoxOiAyODE1DQoyOiAx MDAxDQowOiAyNjENCjM6IDEwOA0Kb3RoZXI6IDc2DQo0OiA1MA0KNTogMzUN Cmluc24gcGFpcmluZyAodG9wIDIwKSBvZiA2MjQxIHBhaXJzOg0KbG9hZC1s b2FkOiA2MTcNCnN0b3JlLXN0b3JlOiA1NjkNCnBsdXMtbG9hZDogNDgyDQps YWJlbF9yZWYtaWZfdGhlbl9lbHNlOiAzNjUNCnBsdXMtc3RvcmU6IDMzMg0K bW92ZS1wbHVzOiAyODUNCnN5bWJvbF9yZWYtY2FsbDogMjcwDQpjb25zdF9p bnQtcGx1czogMjUwDQpsb2FkLXBsdXM6IDIwNQ0KcGx1cy1wbHVzOiAxOTEN Cm1vdmUtY2FsbDogMTgzDQpzdG9yZS1jYWxsOiAxODENCmxvYWQtc3RvcmU6 IDE0OA0KbW92ZS1tb3ZlOiAxMjENCnplcm9fZXh0ZW5kLWlmX3RoZW5fZWxz ZTogMTE5DQpsb2FkLWNhbGw6IDExOA0KbGFiZWxfcmVmLXJlZzogODUNCmNv bnN0X2ludC1jYWxsOiA3Ng0KbG9hZC1taW51czogNjINCmxvYWQtaWZfdGhl bl9lbHNlOiA2MQ0KcGx1cy16ZXJvX2V4dGVuZDogNjENCnN0b3JlLWxvYWQ6 IDYwDQppbnNuIHBhaXJpbmcgKHRvcCAyMCkgb2YgNjI0MSBwYWlycyAoaW1t ZWRpYXRlcyByZXNvbHZlZCk6DQpsb2FkLWxvYWQ6IDYxNw0Kc3RvcmUtc3Rv cmU6IDU2OQ0KbGFiZWxfcmVmLWlmX3RoZW5fZWxzZTogMzY1DQpwbHVzaW1t LWxvYWQ6IDMyNQ0KY29uc3RfaW50LXBsdXM6IDIzMg0KcGx1c2ltbS1zdG9y ZTogMjMwDQpzeW1ib2xfcmVmLWNhbGxpbW06IDIwMA0KbW92ZS1wbHVzaW1t OiAxNjcNCmxvYWQtcGx1c2ltbTogMTYxDQpwbHVzLWxvYWQ6IDE1Nw0KbG9h ZC1zdG9yZTogMTQ4DQpzdG9yZS1jYWxsaW1tOiAxMjINCm1vdmUtbW92ZTog MTIxDQp6ZXJvX2V4dGVuZC1pZl90aGVuX2Vsc2U6IDExOQ0KbW92ZS1wbHVz OiAxMTgNCmxvYWQtY2FsbGltbTogMTA2DQpwbHVzLXN0b3JlOiAxMDINCm1v dmUtY2FsbGltbTogOTgNCnBsdXNpbW0tcGx1czogODkNCmxhYmVsX3JlZi1y ZWc6IDg1DQptb3ZlLWNhbGw6IDg1DQpzeW1ib2xfcmVmLWNhbGw6IDcwDQp2 YWx1ZSBmYW5vdXQ6IDEuMzg2ODUzODAzMDk1MTYNCjE6IDE4MDYyDQoyOiAz MDM4DQowOiAxNzI3DQozOiA2NDkNCm90aGVyOiA0NTUNCjQ6IDI0Ng0KNTog MTE5DQppbnNuIHBhaXJpbmcgKHRvcCAyMCkgb2YgMzM2OTUgcGFpcnM6DQps YWJlbF9yZWYtaWZfdGhlbl9lbHNlOiAzMDI3DQpwbHVzLWxvYWQ6IDI2ODkN Cm1vdmUtY2FsbDogMTg1Mg0KbG9hZC1sb2FkOiAxNzM1DQpsb2FkLXBsdXM6 IDE2MjgNCnN5bWJvbF9yZWYtY2FsbDogMTYxOA0KbG9hZC14b3I6IDE0NTIN Cm1vdmUtbW92ZTogMTQzNA0KeG9yLWlmX3RoZW5fZWxzZTogMTM3Mg0Kc3Rv cmUtc3RvcmU6IDEwMzINCm1vdmUtcGx1czogOTk0DQpsYWJlbF9yZWYtcmVn OiA5MDQNCmxvYWQtY2FsbDogODIzDQpzdG9yZS1jYWxsOiA2ODUNCmNvbnN0 X2ludC1jYWxsOiA2NDYNCmxvYWQtbW92ZTogNjMwDQp6ZXJvX2V4dGVuZC1p Zl90aGVuX2Vsc2U6IDYxOQ0KcGx1cy16ZXJvX2V4dGVuZDogNTA0DQphc2hp ZnQtcGx1czogNDk1DQpzeW1ib2xfcmVmLXBsdXM6IDQ4MQ0KbW92ZS1sb2Fk OiA0NDENCm1vdmUtaWZfdGhlbl9lbHNlOiAzMzENCmluc24gcGFpcmluZyAo dG9wIDIwKSBvZiAzMzY5NSBwYWlycyAoaW1tZWRpYXRlcyByZXNvbHZlZCk6 DQpsYWJlbF9yZWYtaWZfdGhlbl9lbHNlOiAzMDI3DQpwbHVzaW1tLWxvYWQ6 IDIyMzINCmxvYWQtbG9hZDogMTczNQ0KbW92ZS1jYWxsaW1tOiAxNjI2DQpt b3ZlLW1vdmU6IDE0MzQNCmxvYWQtcGx1c2ltbTogMTM5Mg0Kc3ltYm9sX3Jl Zi1jYWxsaW1tOiAxMzg5DQp4b3JpbW0taWZfdGhlbl9lbHNlOiAxMTY4DQps b2FkLXhvcmltbTogMTE0Ng0Kc3RvcmUtc3RvcmU6IDEwMzINCm1vdmUtcGx1 c2ltbTogOTU0DQpsYWJlbF9yZWYtcmVnOiA5MDQNCmxvYWQtY2FsbGltbTog NzI5DQpsb2FkLW1vdmU6IDYzMA0KemVyb19leHRlbmQtaWZfdGhlbl9lbHNl OiA2MTkNCmNvbnN0X2ludC1jYWxsaW1tOiA1ODENCnN0b3JlLWNhbGxpbW06 IDU2Mw0Kc3ltYm9sX3JlZi1wbHVzOiA0NzcNCmFzaGlmdGltbS1wbHVzOiA0 NzYNCnBsdXMtbG9hZDogNDU3DQptb3ZlLWxvYWQ6IDQ0MQ0KcGx1c2ltbS16 ZXJvX2V4dGVuZDogMzczDQo= --8323328-2077238529-1045841823=:529-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Feb 21 18:50:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX8t-0003LY-00 for ; Tue, 11 Mar 2003 00:57:15 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:57:15 +0100 (CET) Received: (qmail 28030 invoked by uid 0); 21 Feb 2003 22:50:07 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 21 Feb 2003 22:50:07 -0000 Received: by moria.seul.org (Postfix) id 3BBD633B55; Fri, 21 Feb 2003 17:50:06 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 93FDF33B6A; Fri, 21 Feb 2003 17:50:05 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a117.home.uni-hannover.de [130.75.232.117]) by moria.seul.org (Postfix) with ESMTP id EA05333B55 for ; Fri, 21 Feb 2003 17:50:03 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA01729; Fri, 21 Feb 2003 18:50:46 +0100 Message-ID: <20030221185046.05032@thrai.stud.uni-hannover.de> Date: Fri, 21 Feb 2003 18:50:46 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] stats on insn pairing References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Feb 21, 2003 at 04:37:03PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Feb 21, 2003 at 04:37:03PM +0100, devik wrote: > while discussing with nico I wanted to know read insn-insn > pairing and value fanout. I computed stats for gcc source > and linux kernel one. > They are attached ... Does `pair' mean that the second insn consumes a value produced by the first insn? Or does it just follow immediately in the instruction stream? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Feb 22 00:07:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sX8u-0003LY-00 for ; Tue, 11 Mar 2003 00:57:16 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:57:16 +0100 (CET) Received: (qmail 23241 invoked by uid 0); 21 Feb 2003 22:55:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 21 Feb 2003 22:55:28 -0000 Received: by moria.seul.org (Postfix) id E863133B56; Fri, 21 Feb 2003 17:55:26 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A0C7F33B6B; Fri, 21 Feb 2003 17:55:26 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id EAEDD33B56 for ; Fri, 21 Feb 2003 17:55:25 -0500 (EST) Received: from f-cpu.org (liifi-13-105.n.club-internet.fr [213.44.44.105]) by relay-4m.club-internet.fr (Postfix) with ESMTP id 64A35E164 for ; Fri, 21 Feb 2003 23:55:24 +0100 (CET) Message-ID: <3E56B11C.4060606@f-cpu.org> Date: Sat, 22 Feb 2003 00:07:08 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] stats on insn pairing References: <20030221185046.05032@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Fri, Feb 21, 2003 at 04:37:03PM +0100, devik wrote: > >>while discussing with nico I wanted to know read insn-insn >>pairing and value fanout. I computed stats for gcc source >>and linux kernel one. >>They are attached ... >> >> >Does `pair' mean that the second insn consumes a value produced by the >first insn? Or does it just follow immediately in the instruction >stream? > > right, we don't know how the stats have been made .... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Feb 25 00:13:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXAL-0003LY-00 for ; Tue, 11 Mar 2003 00:58:45 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:58:45 +0100 (CET) Received: (qmail 8161 invoked by uid 0); 23 Feb 2003 22:25:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 23 Feb 2003 22:25:43 -0000 Received: by moria.seul.org (Postfix) id 3127533B88; Sun, 23 Feb 2003 17:25:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 765A533B8C; Sun, 23 Feb 2003 17:25:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 7953A33B88 for ; Sun, 23 Feb 2003 17:25:39 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id EC34840F1A for ; Sun, 23 Feb 2003 23:25:36 +0100 (CET) Date: Mon, 24 Feb 2003 23:13:21 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] stats on insn pairing Message-Id: <20030224231321.32446064.nicolas.boulay@ifrance.com> In-Reply-To: References: <20030221185046.05032@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N So you're "pair" is for instruction that have a fanout of 1 ? nicO On Sun, 23 Feb 2003 13:00:37 +0100 (CET) devik wrote: > Sorry I was in hurry. I did data flow analysis on gcc > internal repesetation after last scheduling and computed: > 1) avg fanout, how many insn uses result of single insn > 2) fanout histogram > 3) register value producer-consumer pairs > 4) same as 3 but distinguishing insns with and without > immediate values > > Notes: > store-store link is because of post-increment dependency > const_int-plus is adding of const in 2 insns because of > too big value > move-move is value copying (creating bigger fanout) > > hope it is more clear, > devik > > On Fri, 21 Feb 2003, Michael Riepe wrote: > > > On Fri, Feb 21, 2003 at 04:37:03PM +0100, devik wrote: > > > > > while discussing with nico I wanted to know read insn-insn > > > pairing and value fanout. I computed stats for gcc source > > > and linux kernel one. > > > They are attached ... > > > > Does `pair' mean that the second insn consumes a value produced by > > the first insn? Or does it just follow immediately in the > > instruction stream? > > > > -- > > Michael "Tired" Riepe > > "All I wanna do is have a little fun before I die" > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me464783@members.interq.or.jp Mon Feb 24 13:46:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXAg-0003LY-00 for ; Tue, 11 Mar 2003 00:59:06 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 00:59:06 +0100 (CET) Received: (qmail 31597 invoked by uid 0); 24 Feb 2003 12:45:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 24 Feb 2003 12:45:11 -0000 Received: by moria.seul.org (Postfix) id 1F6DD33C10; Mon, 24 Feb 2003 07:45:10 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 77D0233C1A; Mon, 24 Feb 2003 07:45:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from banna (pl447.nas927.o-tokyo.nttpc.ne.jp [61.197.107.191]) by moria.seul.org (Postfix) with ESMTP id 148EA33C10 for ; Mon, 24 Feb 2003 07:45:03 -0500 (EST) Received: from C ([192.168.0.5]) by banna (8.9.3+3.2W/3.7W) with SMTP id VAA32594; Mon, 24 Feb 2003 21:47:46 +0900 Message-Id: <200302241247.VAA32594@banna> From: =?iso-2022-jp?B?bWU0NjQ3ODM=?= To: =?iso-2022-jp?B?MDM4ODU=?=@banna.seul.org Date: Mon, 24 Feb 2003 21:46:14 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoJSYlJCVzJTBFajtxPnBKcyU1ITwlUyU5GyhK?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> ƒEƒCƒ“ƒO“ŠŽ‘î•ñƒT[ƒrƒX ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463440@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚ð‚¨‘‚«‰º‚³‚¢ ¦‚±‚̃[ƒ‹‚͈ê‰ñ‚Ì‚Ý‚Ì”zM‚É‚È‚è‚Ü‚·B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218@ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@Ÿž‹à–ׂ¯ˆê”ÔI‘¼‚Å‚Í•ª‚©‚ç‚È‚¢ŠCŠOî•ñ‚ð’¼—A“üžŸ @@@‹à–ׂ¯î•ñE‘剻‚¯•KŽŠ!’†‘Š”‘¼AŠCŠO“ŠŽ‘î•ñ@@@ ‚È‚Ç’N‚Å‚ào—ˆ‚é‹à–ׂ¯‚̃mƒEƒnƒE‚ð‹³‚¦‚éƒ[ƒ‹ƒ}ƒKƒWƒ“‚Å‚·B@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ „¬„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„­ ƒ[ƒ‹ƒ}ƒKƒWƒ“”­sŠó–]‚Ì•û‚Í‚±‚¿‚ç‚Ƀ[ƒ‹‚µ‚Ä‚­‚¾‚³‚¢B @«@@«@@«@@@@@@@@@@@@@@@@@@ famous@sa.il24.net@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@ ¦–ˆTˆê‰ñAÅV‚Ìî•ñ‚ð‚¨“Í‚¯’v‚µ‚Ü‚·B ¦w“Ç—¿–³—¿@@@@@@@@@ „¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„® ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Credit_Doctor_984@alltel.net Thu Feb 27 04:47:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXDL-0003LY-00 for ; Tue, 11 Mar 2003 01:01:51 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:01:51 +0100 (CET) Received: (qmail 9381 invoked by uid 0); 27 Feb 2003 03:40:50 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 27 Feb 2003 03:40:50 -0000 Received: by moria.seul.org (Postfix) id B3C0A33DB7; Wed, 26 Feb 2003 22:40:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1393A33DB9; Wed, 26 Feb 2003 22:40:48 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 59B7633DB7 for ; Wed, 26 Feb 2003 22:40:47 -0500 (EST) Received: from 202.21.13.140 (24-29-138-154.nyc.rr.com [24.29.138.154]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h1R3ehk05775 for ; Wed, 26 Feb 2003 22:40:44 -0500 Message-Id: <200302270340.h1R3ehk05775@belegost.mit.edu> Received: from ssymail.ssy.co.kr ([113.236.31.212]) by a231242.upc-a.chello.nl with local; Feb, 26 2003 8:21:17 PM +0400 Received: from 213.54.67.154 ([213.54.67.154]) by sparc.isl.net with esmtp; Feb, 26 2003 7:19:09 PM +0700 From: Oswell To: f-cpu@seul.org Subject: [f-cpu] Re: About Your Credit.......... muht Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 26 Feb 2003 21:47:26 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

We can fix your credit. We are very successful at getting bankruptcies, judgments, tax liens, foreclosures, late payments, charge-offs, repossessions, and even student loans removed from a persons credit report. To find out more go to http://www.cjlinc.net.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  tbdposeygrfuywhnusnqvoyccqxu ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 2 06:50:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXH4-0003LY-00 for ; Tue, 11 Mar 2003 01:05:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:05:42 +0100 (CET) Received: (qmail 9527 invoked by uid 0); 2 Mar 2003 05:45:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 2 Mar 2003 05:45:05 -0000 Received: by moria.seul.org (Postfix) id C911233FB0; Sun, 2 Mar 2003 00:45:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0FD0F33FB3; Sun, 2 Mar 2003 00:45:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5525933FB0 for ; Sun, 2 Mar 2003 00:45:01 -0500 (EST) Received: from f-cpu.org (lcbv2-1-25.n.club-internet.fr [213.44.12.25]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 768441740 for ; Sun, 2 Mar 2003 06:44:59 +0100 (CET) Message-ID: <3E619BBE.1070208@f-cpu.org> Date: Sun, 02 Mar 2003 06:50:54 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <3E608AF4.1070603@f-cpu.org> <20030301214835.03274@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Sat, Mar 01, 2003 at 11:27:00AM +0100, Yann Guidon wrote: > > >>hoping to revive this list, >> >> >I guess that was enough revival for a single mail, wasn't it? ;) > yup and i already regret it :-) The FP stuff is ok because it's "future work" and the integer part is not even finished. However, the redesign of the conditions is less amusing because i am not in a mood for digging into F-CPU details :-/ I am well aware that the "zero" and "msb" conditions contain problems but i can live with them and compiler problems are ... compiler problems. It's already a big chance that the whole architecture is still alive after almost 4 years. I wish i could get back to "active contribution mode" but i have no money left and i can't do volunteer work now :-( YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Mon Mar 3 00:38:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXHl-0003LY-00 for ; Tue, 11 Mar 2003 01:06:25 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:06:25 +0100 (CET) Received: (qmail 29828 invoked by uid 0); 2 Mar 2003 22:39:05 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 2 Mar 2003 22:39:05 -0000 Received: by moria.seul.org (Postfix) id 108CA33F98; Sun, 2 Mar 2003 17:39:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3936133FB3; Sun, 2 Mar 2003 17:39:03 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id E209433F98 for ; Sun, 2 Mar 2003 17:39:01 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id A896362D03 for ; Sun, 2 Mar 2003 23:38:48 +0100 (CET) Date: Sun, 2 Mar 2003 23:38:10 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] OOC vs. OOE (scoreboard & tomasulo) Message-Id: <20030302233810.74af20aa.nicolas.boulay@ifrance.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, 2 Mar 2003 23:10:05 +0100 (CET) devik wrote: > Hello, > > I know many men here have too much work but I'd > like to initiate short thread in order to get > deeper knowledge in field. > > I was looking for some Subj. related infos but > haven't found much. Thus I learned Tomasulo, > looked at Sparc, MIPS and Alpha and tried to Mips is often cited as a very good architecture. Much more often than sparc or Alpha. Cray is very cited, too. Then very new Cray X1 use a modified MIPS isa. > create my own opinion. I'd like to head (personal) > feeleing and comments of others people here > (which is valuable for me by the way). > > At the first glance OOC is much simpler to implement. > In OOE you have to think about > - ROB because of exceptions and control speculation > - for tomasulo based we need expensive CDB and many > comparators (but bypass needs them anyway) > > Similary gains of OOE more specificaly Tomasulo like > designs: > - ISA is the same for different number and speed of EUs > - adaptation of EU controling to actual data flow including > dynamic loop unrolling > - can go around memory latency (!) > - simple reg. renaming allows to have much less architectural > register without sacrifying performance > - simpler datapath, you can do 4 way cpu with only 1r1w > regsets One nice other things. R1 op R2 -> R3 instructions set aren't so much an obligation. We could use R1 op R2 -> R2, this could be a save because fanout of instructions are very little (1.4 in means). > > So what's the real performance (let's forget about ISA binary > compatibility thing) difference between OOE & OOC ? > IMHO it is memory load. > When tomasulo based CPU hits memory load it starts it and > goes further. All dependent instructions are filled into > reservation stations (RS) near (!) their EUs. > We can load many dataflow traces into CPU this way (limited > by number of RS but not neccessarily by internal register > set size) and these get started asynchronously by memory > subsystem when data arrives from slower memory. > > All other EUs are typicaly semipredictable (we know exact > latency when we know datasize) and we can always schedule > them well for OOC. But loads are killers - prefetch/preload > is nice but often you don't know correct address in advance. > Take simple case - deleting element from double linked > list. You need to load x->prev and x->next and update them. > x->prev->next = x->next; > x->next->prev = x->prev; > load [r1],r3 > load [r1+8],r4 > store r4,[r3+8] > store r3,[r4] > > Assume L1 latency 2 and L2 latency 20. > If x->prev is in L2 cache and x->next is in L1 cache then > 1-issue tomasulo will in 4 cycles fill 4 RS then second > load is finished which also starts the first store. > Second load-store is started after some time later and > we can run other code in between. > OOC cpu will stall at first load for 20 cycles .. > > So that do you think can good OOC perform better than > good OOE for generic code ? > I don't think so if latency of memory load will stay > to be highly undeterministic. > > ------- > Don't read below if your mind if labile ;) > If memory load is the only problem, what about something > like "machine code select(2)" for OOC ? I mean unix API > select(2). ouch... polling many load result ? > > Like to say in asm - now stall on these (started) four > loads and execute part of code (follows) depending on > which load completed. For linked list above it would read: > xload [r1],r3 > xload [r1+8],r4 > wait r3,a,1,r4,b,1,c > a:store r4,[r3+8] > b:store r3,[r4] > c: > > xload is non-blocking load (like prefetch), wait line stands > for: > wait for r3, if completes, schedule 1 insn at relative > address a ... similarly for r4, when both finished then > continue at c. > Probably you got the (crazy) idea .. it is for thinking. > The idea is too fresh and maybe I'll dumpt it tomorrow. > > But still I'm interested in yout ide about Subj. > The most annoying thing is how to manage the state of the cpu ? State must be saved&restored at context switch. And the wait instruction can have so much fields. nicO > good night, > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 3 19:22:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXJJ-0003LY-00 for ; Tue, 11 Mar 2003 01:08:01 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:08:01 +0100 (CET) Received: (qmail 23747 invoked by uid 0); 3 Mar 2003 23:41:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 3 Mar 2003 23:41:01 -0000 Received: by moria.seul.org (Postfix) id 20D3033B85; Mon, 3 Mar 2003 18:41:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5980E33FB6; Mon, 3 Mar 2003 18:40:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a179.home.uni-hannover.de [130.75.232.179]) by moria.seul.org (Postfix) with ESMTP id 4A28833B85 for ; Mon, 3 Mar 2003 18:40:56 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA05622; Mon, 3 Mar 2003 19:22:06 +0100 Message-ID: <20030303192206.15983@thrai.stud.uni-hannover.de> Date: Mon, 3 Mar 2003 19:22:06 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <20030301214835.03274@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Mar 03, 2003 at 11:37:37AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Mar 03, 2003 at 11:37:37AM +0100, devik wrote: > > There is, however, a big problem with FP status: Since instructions > > complete out-of-order, it's undefined which instruction the status > > comes from. You can only query the status of a series of FP instructions > > collectively, unless you serialize the instruction stream after every > > FP operation (which is going to be slooooooooow). > > from what I've understood from the paper, the use is to: > > double compute_krakovian(matrix *x) > { > clear_fpuflag() > ... some heavy numerical math ... > if (test_flag_for_error) > return compute_krakovian_precise(x); > return y; > } > > so that to do block of computation, serialize and check flag. The > flag could be also "hidden" part of our 96bit FPU word and thus > it could be copied/preserved during dataflow - one then could > also check for errors or imprecisions in single result. That > would allow very nice handling of precision, no extra context, > no problem with OOC and compiler could simulate IEEE behaviour > of global status flag by ORing status words obtained from > all dataflow registers in cross-section at the place of > "check()" call (yes gcc can handle it easily). > > Yet another "in-pipeline" exception would be over ;-) Unfortunately, you seem to misunderstand... there is no 96-bit datapath because there are no 96-bit FP registers. At the end of every instruction, the result is rounded to either float or double, any additional bits will be lost. Exceptional conditions can only be marked in a central status register. The only thing we could do is mark the result register in the scoreboard and raise an exception when it is used -- but that may be too late. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 4 23:09:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXSm-0003LY-00 for ; Tue, 11 Mar 2003 01:17:48 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:17:48 +0100 (CET) Received: (qmail 9260 invoked by uid 0); 4 Mar 2003 23:03:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 4 Mar 2003 23:03:49 -0000 Received: by moria.seul.org (Postfix) id EF4A433F95; Tue, 4 Mar 2003 18:03:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 65DB433FC2; Tue, 4 Mar 2003 18:03:31 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 477C133FBD for ; Tue, 4 Mar 2003 18:03:27 -0500 (EST) Received: from f-cpu.org (lcbv1-3-2.n.club-internet.fr [213.44.21.2]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 1C34816C9 for ; Wed, 5 Mar 2003 00:03:25 +0100 (CET) Message-ID: <3E652413.4010401@f-cpu.org> Date: Tue, 04 Mar 2003 23:09:23 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue References: <3E643043.4070403@f-cpu.org> <20030304210528.346ed893.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! nico wrote: >On Tue, 04 Mar 2003 05:49:07 +0100 >Yann Guidon wrote: > >>hi ! >> >>devik wrote: >> >>>http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf >>> >>>VERY interesting reading ! >>> >>almost in the same vein : >> >>http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf >> > >:) nice :) Devik and whygee discover the 2 same things. > > oops sorry i used the wrong address ! http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-09.pdf (it speaks about coffee) >>(don't look at the publication date too early) >> >>well, now it explains a lot of things i've read on their project >>site.... they simply have fun with DARPA money. >> >:) How could you consider those researcher... That's... amazing. > > i have visited MIT/AI lab once and i can tell you that the people i've seen are a bit more serious ... (and they are DARPA-funded too) >>>Simplicity also has advantages that silicon efficiency on its own >>>does not; simpler architectures are faster to design, >>>easier to test, less prone to errors and friendlier to >>>compilers. >>> >>> >>This is why FC0 has no renamed registers, OOOE, >>and other sophisticated control stuff. >> >> >OOOC include some difficulties, too. > > but i don't think it will consume 100k transistors for FC0, and there are less pipeline stages dedicated to scheduling. In fact, the whole point of 000C in FC0 is that the scheduling is partly performed in parallel with a non-OOOC standard pipeline. This makes jump and loop overhead small and further reduces the need for prediction and speculative execution. >>Additionally, more complexity means more silicon area, >>more dissipation, longer wires => more heat/dissipation, >>more expensive and probably slower. >>And control logic is certainly the least easy thing >>to test in a chip. This is why i'm satisfied with >>the current FC0. >> >> > >not me :) Not when you saw the 3r2w regifile because of 1 or 2 >instructions (like MAC). Not when you saw the mess of "special register" >that should be memory mapped (with conditionnal memory movemement like >not buffered, if needed). Not when you see the trap/expetion mess. > > 1) 3R2W is necessary also for load and store instructions, otherwise it's not possible to perform pointer update in the instruction. 2) If you map SRs to memory, you will face race conditions and synchronisation problems, and protection will not be enforced on a register or register group granularity basis. 3) what mess ? >Beside that, i had beleived that tomasulo was a quick and "easy" OOOE. >But it was not. It's the "canonical" OOOE. So it will be a big mess. Use >of tomasolu could be an idea with a all different core to reduice memory >foot print (like the use of 2 register adress fields instead of 3) but >the pipeline need to be shorted to avoid the udge number of comparator >that is needed. > > Heh. we are not IBM :-) >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 4 02:16:51 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXJo-0003LY-00 for ; Tue, 11 Mar 2003 01:08:32 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:08:32 +0100 (CET) Received: (qmail 6907 invoked by uid 0); 4 Mar 2003 02:11:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 4 Mar 2003 02:11:27 -0000 Received: by moria.seul.org (Postfix) id 930AD33B86; Mon, 3 Mar 2003 21:11:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E5D3033FB6; Mon, 3 Mar 2003 21:11:24 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 0017C33B86 for ; Mon, 3 Mar 2003 21:11:23 -0500 (EST) Received: from f-cpu.org (lcbv1-1-1.n.club-internet.fr [213.44.3.1]) by relay-1v.club-internet.fr (Postfix) with ESMTP id D52BE1690 for ; Tue, 4 Mar 2003 03:10:08 +0100 (CET) Message-ID: <3E63FE83.4000403@f-cpu.org> Date: Tue, 04 Mar 2003 02:16:51 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N devik wrote: >http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > >VERY interesting reading ! > > but FC0 is not (yet) superscalar ..... i'll read other documents from this project, there are maybe other interesting ideas. >------------------------------- > Martin Devera aka devik >Linux kernel QoS/HTB maintainer > http://luxik.cdi.cz/~devik/ > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Tue Mar 4 19:35:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXLy-0003LY-00 for ; Tue, 11 Mar 2003 01:10:46 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:10:46 +0100 (CET) Received: (qmail 12799 invoked by uid 0); 4 Mar 2003 18:39:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 4 Mar 2003 18:39:00 -0000 Received: by moria.seul.org (Postfix) id A23CC33B88; Tue, 4 Mar 2003 13:38:58 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EAD8733BD6; Tue, 4 Mar 2003 13:38:57 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 6499033B88 for ; Tue, 4 Mar 2003 13:38:56 -0500 (EST) Received: from jetnet.ab.ca (gc-jet-219.jetnet.ab.ca [207.34.60.219]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h24IcIJ7006142 for ; Tue, 4 Mar 2003 11:38:46 -0700 (MST) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E64F1ED.4070805@jetnet.ab.ca> Date: Tue, 04 Mar 2003 11:35:25 -0700 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 References: <20030304134335.9A17C62D6E@mallaury.noc.nerim.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N cyrano@nerim.net wrote: > I don't like prefetch. Did gcc could really calculate the very narrow windows where the prefetch is usefull ? Prefetch are implementation dependant but also clock speed dependant ! > > I prefer multi-load/store much more (a complete cache line for example that fill 4 or 8 registers). > > So you're proposal look like a kind of double load ( a = toto -> titi ) or load then store (toto->titi = a). This could be a feature of "internal cpu buses" and a new instruction. As we control L1/L2 access and we don't need to conform to the limited feature of SDRAM, this kind of bus cycle could be added and optimised closed to the cache controller. > The problem is the prefetch values and other timing information is not a constant but a variable. You really want to bunch up all the pre-fetch information and sort both on data flow and the timing variables. Pre-fetch also makes a mess with DMA and serialized instructions like single stepping too.Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Tue Mar 4 18:43:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXKy-0003LY-00 for ; Tue, 11 Mar 2003 01:09:44 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:09:44 +0100 (CET) Received: (qmail 3397 invoked by uid 0); 4 Mar 2003 13:43:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 4 Mar 2003 13:43:40 -0000 Received: by moria.seul.org (Postfix) id D7A4A33B5F; Tue, 4 Mar 2003 08:43:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1B45033B66; Tue, 4 Mar 2003 08:43:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 22F7333B5F for ; Tue, 4 Mar 2003 08:43:37 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 9A17C62D6E for ; Tue, 4 Mar 2003 14:43:35 +0100 (CET) To: Subject: Re: [f-cpu] second order prefetch in FC0 From: Date: Tue, 4 Mar 2003 14:43:36 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030304134335.9A17C62D6E@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I don't like prefetch. Did gcc could really calculate the very narrow windows where the prefetch is usefull ? Prefetch are implementation dependant but also clock speed dependant ! I prefer multi-load/store much more (a complete cache line for example that fill 4 or 8 registers). So you're proposal look like a kind of double load ( a = toto -> titi ) or load then store (toto->titi = a). This could be a feature of "internal cpu buses" and a new instruction. As we control L1/L2 access and we don't need to conform to the limited feature of SDRAM, this kind of bus cycle could be added and optimised closed to the cache controller. nicO Devik a écrit : > Hi, > > just one idea. In FC0 load is supposed to trap > on TLB miss (or access violation) before it enters > pipeline. While it is simple it will kill many > indirect addressing performance (foo->bar->baz) > where we can't load pointer early or it will > at least stall whole CPU because data are not > in L0. > On other side I agree that asynchronous load is > not simple (we'd need some load buffers) and it > is not as useful as prefetch (can't be moved > out of control structures). > > I got (yet another) crazy idea. We support for > prefetch of a cacheline where some address live. > What about special prefetch which would > prefetch cacheline, then load new address from > it at given offset and prefetch that address too ? > > It involves other TLB and adder I know. On other > side it is completely out of critical path and > if we will do real load faster we can simply > discard prefetch. > > It would help linked structures, especially trees > and lists. "next" links are typically in first 32 > bytes so that it is possible for "item remove" > subroutine to ask for prefetch of item along with > its siblings. > I already invented some way how to force gcc to emit > some prefetches and this one would be possible too. > > It is for thinking (for YG: I don't blame FC0 I only > want to share my ideas). > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Mar 4 13:54:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXKt-0003LY-00 for ; Tue, 11 Mar 2003 01:09:39 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:09:39 +0100 (CET) Received: (qmail 25224 invoked by uid 0); 4 Mar 2003 13:06:51 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 4 Mar 2003 13:06:51 -0000 Received: by moria.seul.org (Postfix) id AC71A33B4C; Tue, 4 Mar 2003 08:06:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D887833B5F; Tue, 4 Mar 2003 08:06:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 3544933B4C for ; Tue, 4 Mar 2003 08:06:46 -0500 (EST) Received: from a120-137.dialup.iol.cz ([194.228.137.120] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qC80-0000xz-00 for f-cpu@seul.org; Tue, 04 Mar 2003 14:06:43 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qBwH-0000Kd-00 for f-cpu@seul.org; Tue, 04 Mar 2003 13:54:33 +0100 Date: Tue, 4 Mar 2003 13:54:33 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] second order prefetch in FC0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, just one idea. In FC0 load is supposed to trap on TLB miss (or access violation) before it enters pipeline. While it is simple it will kill many indirect addressing performance (foo->bar->baz) where we can't load pointer early or it will at least stall whole CPU because data are not in L0. On other side I agree that asynchronous load is not simple (we'd need some load buffers) and it is not as useful as prefetch (can't be moved out of control structures). I got (yet another) crazy idea. We support for prefetch of a cacheline where some address live. What about special prefetch which would prefetch cacheline, then load new address from it at given offset and prefetch that address too ? It involves other TLB and adder I know. On other side it is completely out of critical path and if we will do real load faster we can simply discard prefetch. It would help linked structures, especially trees and lists. "next" links are typically in first 32 bytes so that it is possible for "item remove" subroutine to ask for prefetch of item along with its siblings. I already invented some way how to force gcc to emit some prefetches and this one would be possible too. It is for thinking (for YG: I don't blame FC0 I only want to share my ideas). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 4 05:49:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXJy-0003LY-00 for ; Tue, 11 Mar 2003 01:08:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:08:42 +0100 (CET) Received: (qmail 22688 invoked by uid 0); 4 Mar 2003 05:43:15 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 4 Mar 2003 05:43:15 -0000 Received: by moria.seul.org (Postfix) id 576A033BD7; Tue, 4 Mar 2003 00:43:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E096F33FBD; Tue, 4 Mar 2003 00:43:12 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 40FA333BD7 for ; Tue, 4 Mar 2003 00:43:12 -0500 (EST) Received: from f-cpu.org (lcbv5-1-66.n.club-internet.fr [213.44.18.66]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 5ADDC16A0 for ; Tue, 4 Mar 2003 06:42:06 +0100 (CET) Message-ID: <3E643043.4070403@f-cpu.org> Date: Tue, 04 Mar 2003 05:49:07 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > >VERY interesting reading ! > > almost in the same vein : http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf (don't look at the publication date too early) well, now it explains a lot of things i've read on their project site.... they simply have fun with DARPA money. Except for the "multistriped addressing" idea ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-03.pdf ) i see nothing groundbreaking or worth caring. They also explore some SMT (Simultaneous MultiThreading) aspects in an interesting way but only in the beginning. ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-07.pdf ) The rest is simply useless in a "classical general-purpose" processor. Their ARIES architectures use straight Harvard (split address spaces for instructions and data) which is not the best supported architecture under most OS and compilers .... and they do only consider MPP (massively parallel computing) while F-CPU shall be able to work as "standalone". On top of that, it's highly object-oriented and their pointers are weird... And here is a quote from http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-12.pdf : > The Hamal Instruction Set Architecture was > developed over a period of more than a year by a > process which can fairly be described as the worst > sort of engineering. It is almost purely the result of > thought experiments and hypothetical debates. With > the exception of some preliminary assembly > programming and scattered ties to existing > architectures, it has benefited from little to no realworld > validation. However JPG got something right : > Simplicity also has advantages that silicon efficiency on its own > does not; simpler architectures are faster to design, > easier to test, less prone to errors and friendlier to > compilers. This is why FC0 has no renamed registers, OOOE, and other sophisticated control stuff. Additionally, more complexity means more silicon area, more dissipation, longer wires => more heat/dissipation, more expensive and probably slower. And control logic is certainly the least easy thing to test in a chip. This is why i'm satisfied with the current FC0. >------------------------------- > Martin Devera aka devik >Linux kernel QoS/HTB maintainer > http://luxik.cdi.cz/~devik/ > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Tue Mar 4 17:39:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXKV-0003LY-00 for ; Tue, 11 Mar 2003 01:09:15 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:09:15 +0100 (CET) Received: (qmail 1731 invoked by uid 0); 4 Mar 2003 12:39:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 4 Mar 2003 12:39:09 -0000 Received: by moria.seul.org (Postfix) id 9E9A333B4D; Tue, 4 Mar 2003 07:39:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFE3F33B4C; Tue, 4 Mar 2003 07:39:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 7E56033B4D for ; Tue, 4 Mar 2003 07:39:05 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id B705662E25 for ; Tue, 4 Mar 2003 13:39:03 +0100 (CET) To: Subject: [f-cpu] website about historical cpu design From: Date: Tue, 4 Mar 2003 13:39:04 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030304123903.B705662E25@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N http://www.cs.clemson.edu/~mark/hist.html I love this site because they were plainty of "real" and "usefull" informations. About interrupts : http://www.cs.clemson.edu/~mark/interrupts.html nicO ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 4 21:58:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXMb-0003LY-00 for ; Tue, 11 Mar 2003 01:11:25 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:11:25 +0100 (CET) Received: (qmail 14055 invoked by uid 0); 4 Mar 2003 19:59:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 4 Mar 2003 19:59:03 -0000 Received: by moria.seul.org (Postfix) id BEDBA33BD6; Tue, 4 Mar 2003 14:59:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0CBC33C19; Tue, 4 Mar 2003 14:59:00 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id EFCFD33BD6 for ; Tue, 4 Mar 2003 14:58:54 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id E26CA62FDB for ; Tue, 4 Mar 2003 20:58:51 +0100 (CET) Date: Tue, 4 Mar 2003 20:58:22 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions Message-Id: <20030304205822.2c50aa99.nicolas.boulay@ifrance.com> In-Reply-To: <20030303192206.15983@thrai.stud.uni-hannover.de> References: <20030301214835.03274@thrai.stud.uni-hannover.de> <20030303192206.15983@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, 3 Mar 2003 19:22:06 +0100 Michael Riepe wrote: > On Mon, Mar 03, 2003 at 11:37:37AM +0100, devik wrote: > > > There is, however, a big problem with FP status: Since > > > instructions complete out-of-order, it's undefined which > > > instruction the status comes from. You can only query the status > > > of a series of FP instructions collectively, unless you serialize > > > the instruction stream after every FP operation (which is going to > > > be slooooooooow). > > > > from what I've understood from the paper, the use is to: > > > > double compute_krakovian(matrix *x) > > { > > clear_fpuflag() > > ... some heavy numerical math ... > > if (test_flag_for_error) > > return compute_krakovian_precise(x); > > return y; > > } > > > > so that to do block of computation, serialize and check flag. The > > flag could be also "hidden" part of our 96bit FPU word and thus > > it could be copied/preserved during dataflow - one then could > > also check for errors or imprecisions in single result. That > > would allow very nice handling of precision, no extra context, > > no problem with OOC and compiler could simulate IEEE behaviour > > of global status flag by ORing status words obtained from > > all dataflow registers in cross-section at the place of > > "check()" call (yes gcc can handle it easily). > > > > Yet another "in-pipeline" exception would be over ;-) > > Unfortunately, you seem to misunderstand... there is no 96-bit > datapath because there are no 96-bit FP registers. At the end of ??? there is almost nothing about fp in the fcpu manual. I beleive that size in fp will be 32 64 128. So you could use better data format. > every instruction, the result is rounded to either float or double, > any additional bits will be lost. Exceptional conditions can only be > marked in a central status register. The only thing we could do is > mark the result register in the scoreboard and raise an exception when > it is used -- but that may be too late. But you can recompute the result by an other instruction block that is more precise but slower. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Tue Mar 4 22:05:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXMf-0003LY-00 for ; Tue, 11 Mar 2003 01:11:29 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:11:29 +0100 (CET) Received: (qmail 15819 invoked by uid 0); 4 Mar 2003 20:06:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 4 Mar 2003 20:06:09 -0000 Received: by moria.seul.org (Postfix) id 76C7933C10; Tue, 4 Mar 2003 15:06:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A914B33C22; Tue, 4 Mar 2003 15:06:06 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 02D7F33C10 for ; Tue, 4 Mar 2003 15:06:01 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id AD08740EC7 for ; Tue, 4 Mar 2003 21:05:58 +0100 (CET) Date: Tue, 4 Mar 2003 21:05:28 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue Message-Id: <20030304210528.346ed893.nicolas.boulay@ifrance.com> In-Reply-To: <3E643043.4070403@f-cpu.org> References: <3E643043.4070403@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, 04 Mar 2003 05:49:07 +0100 Yann Guidon wrote: > hi ! > > devik wrote: > > >http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > > > >VERY interesting reading ! > > > > > > almost in the same vein : > > http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > :) nice :) Devik and whygee discover the 2 same things. > (don't look at the publication date too early) > > well, now it explains a lot of things i've read on their project > site.... they simply have fun with DARPA money. > :) How could you consider those researcher... That's... amazing. > > Except for the "multistriped addressing" idea > ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-03.pdf ) > i see nothing groundbreaking or worth caring. > They also explore some SMT (Simultaneous MultiThreading) > aspects in an interesting way but only in the beginning. > ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-07.pdf ) > > The rest is simply useless in a "classical general-purpose" processor. > Their ARIES architectures use straight Harvard (split address spaces > for instructions > and data) which is not the best supported architecture under most OS > and compilers .... and they do only consider MPP (massively parallel > computing) > while F-CPU shall be able to work as "standalone". > On top of that, it's highly object-oriented and their pointers are > weird... > > And here is a quote from > http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-12.pdf : > > > The Hamal Instruction Set Architecture was > > developed over a period of more than a year by a > > process which can fairly be described as the worst > > sort of engineering. It is almost purely the result of > > thought experiments and hypothetical debates. With > > the exception of some preliminary assembly > > programming and scattered ties to existing > > architectures, it has benefited from little to no realworld > > validation. > > > However JPG got something right : > > > Simplicity also has advantages that silicon efficiency on its own > > does not; simpler architectures are faster to design, > > easier to test, less prone to errors and friendlier to > > compilers. > > This is why FC0 has no renamed registers, OOOE, > and other sophisticated control stuff. OOOC include some difficulties, too. > Additionally, more complexity means more silicon area, > more dissipation, longer wires => more heat/dissipation, > more expensive and probably slower. > And control logic is certainly the least easy thing > to test in a chip. This is why i'm satisfied with > the current FC0. not me :) Not when you saw the 3r2w regifile because of 1 or 2 instructions (like MAC). Not when you saw the mess of "special register" that should be memory mapped (with conditionnal memory movemement like not buffered, if needed). Not when you see the trap/expetion mess. Beside that, i had beleived that tomasulo was a quick and "easy" OOOE. But it was not. It's the "canonical" OOOE. So it will be a big mess. Use of tomasolu could be an idea with a all different core to reduice memory foot print (like the use of 2 register adress fields instead of 3) but the pipeline need to be shorted to avoid the udge number of comparator that is needed. nicO > > > >------------------------------- > > Martin Devera aka devik > >Linux kernel QoS/HTB maintainer > > http://luxik.cdi.cz/~devik/ > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 4 23:09:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXSX-0003LY-00 for ; Tue, 11 Mar 2003 01:17:33 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:17:33 +0100 (CET) Received: (qmail 26302 invoked by uid 0); 4 Mar 2003 23:03:38 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 4 Mar 2003 23:03:38 -0000 Received: by moria.seul.org (Postfix) id 27BB233FC3; Tue, 4 Mar 2003 18:03:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 15DB133FC0; Tue, 4 Mar 2003 18:03:28 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 851DC33F95 for ; Tue, 4 Mar 2003 18:03:25 -0500 (EST) Received: from f-cpu.org (lcbv1-3-2.n.club-internet.fr [213.44.21.2]) by relay-4m.club-internet.fr (Postfix) with ESMTP id 1FB75E189 for ; Wed, 5 Mar 2003 00:03:22 +0100 (CET) Message-ID: <3E652410.1010101@f-cpu.org> Date: Tue, 04 Mar 2003 23:09:20 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 References: <20030304134335.9A17C62D6E@mallaury.noc.nerim.net> <3E64F1ED.4070805@jetnet.ab.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, ben franchuk wrote: > cyrano@nerim.net wrote: > >> I don't like prefetch. Did gcc could really calculate the very narrow >> windows where the prefetch is usefull ? Prefetch are implementation >> dependant but also clock speed dependant ! >> >> I prefer multi-load/store much more (a complete cache line for >> example that fill 4 or 8 registers). >> >> So you're proposal look like a kind of double load ( a = toto -> titi >> ) or load then store (toto->titi = a). This could be a feature of >> "internal cpu buses" and a new instruction. As we control L1/L2 >> access and we don't need to conform to the limited feature of SDRAM, >> this kind of bus cycle could be added and optimised closed to the >> cache controller. >> > > The problem is the prefetch values and other timing information is not a > constant but a variable. You really want to bunch up all the pre-fetch > information and sort both on data flow and the timing variables. > Pre-fetch also makes a mess with DMA and serialized instructions like > single stepping too.Ben. i like the idea of "adaptative" computers that record resource utilisation patterns. This ensures that the code is highly portable and some code becomes efficient after a few loop runs. For example : - Pentium (P53) records the boundaries of the variable-size instructions with one bit per byte. These bits are invisible to the program and automatically generated whenever the cacheline is first executed. There is no decoding/parsing penalty after a second run. - Alpha 21264 uses data and instruction cache chaining (i don't remember the right term). Each cache line contains 2 physical addresses of the last two memory accesses after the cache line was used. This speeds up linked lists because in the case of the cache line being used, the cache mechanism will prefetch the 2 cache lines referenced by the tag. But, as i presume, these methods are certainly completely mined by patents. Concerning Devik's proposition of "delayed execution", the big problems are - to generate the delays by a compiler (and force recompile if another arch is used) - there is no room left for this in the opcodes so my idea was to check how these delays could be generated 'on the fly' and invisibly, using a first "parsing pass" like for pentium's instruction alignment method. But in the end, it consumes much more resources and pipeline stages than FC0's OOOC so i don't see the point yet. Concerning the 2nd order prefetch, i don't think we could afford DEC/Compaq/HP's patents on this ... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 10:13:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXfF-0003LY-00 for ; Tue, 11 Mar 2003 01:30:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:30:41 +0100 (CET) Received: (qmail 8762 invoked by uid 0); 5 Mar 2003 09:31:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 5 Mar 2003 09:31:20 -0000 Received: by moria.seul.org (Postfix) id 5E0F633F8C; Wed, 5 Mar 2003 04:30:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A1FE33FBD; Wed, 5 Mar 2003 04:30:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id C4FD633F8C for ; Wed, 5 Mar 2003 04:30:00 -0500 (EST) Received: from a54-137.dialup.iol.cz ([194.228.137.54] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qVDp-0006RE-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:29:57 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qUxv-0000Kx-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:13:31 +0100 Date: Wed, 5 Mar 2003 10:13:31 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] second order prefetch in FC0 In-Reply-To: <3E652410.1010101@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > i like the idea of "adaptative" computers that record resource > utilisation patterns. > This ensures that the code is highly portable and some code > becomes efficient after a few loop runs. For example : > [...] > - Alpha 21264 uses data and instruction cache chaining (i don't > remember the right term). > Each cache line contains 2 physical addresses of the last two memory > accesses > after the cache line was used. This speeds up linked lists because in > the case > of the cache line being used, the cache mechanism will prefetch the 2 > cache lines > referenced by the tag. > But, as i presume, these methods are certainly completely mined by patents. Shit. Always when I "invent" something it is already patented. Well one could only hope that some of those method was patented before 1990. Then it would expire in near future. Or that the patent only covers adaptive use of it (like in cache as you said). One need to read these patents. Using this one via prefetch as I proposed has another advantage. In-cache hint helps you only if the reference was used already. But if you are going thru list/tree the compiler knows in advance that node will be loaded and immediately used as source of a pointer. If the node is new then cache with chained loads will hot help but inteligent prefetch could. > Concerning Devik's proposition of "delayed execution", the big problems are > - to generate the delays by a compiler (and force recompile if another > arch is used) Agree. But for F-CPU (OOOC) it is the same. If you read the paper you see that if you fill bad values in then it will simply stall - the same as with current f-cpu. AND (!): if you use their proposed relative values (like delay of MULT+1 or delay of ADD+0) it would in fact ADD binary compatibility to current core. However I'm not sure too with it - it is only interesting to know about it. It is surely good to finish "something" only it would be a bit unfortunate to see that it sucks in final. I'm not sure (but I feel so) that nicO is right about imbalance of 3r2w regset speed when compared with 6gts restriction. There is already finished openrisc which can be compiled as 64bit AFAIK. I can't find description of its internals (only ISA) but if f-cpu should be slower or at the same speed then I see no reason to do it (unless one does it for fun only). > - there is no room left for this in the opcodes > so my idea was to check how these delays could be generated 'on the fly' > and invisibly, using a first "parsing pass" like for pentium's instruction > alignment method. But in the end, it consumes much more resources > and pipeline stages than FC0's OOOC so i don't see the point yet. yes I agree here. It could be done dynamicaly by remembering for each register type (delay) of insn which waits for it. When insn then uses two registers one could select max of them. But many hazard would need to be checked ... Probably if we would like to do OOOE we would need to encode this info into insn. But as you said it doesn't seem to be so important yet. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Wed Mar 5 13:07:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXdc-0003LY-00 for ; Tue, 11 Mar 2003 01:29:00 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:29:00 +0100 (CET) Received: (qmail 16944 invoked by uid 0); 5 Mar 2003 08:07:32 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 5 Mar 2003 08:07:32 -0000 Received: by moria.seul.org (Postfix) id 96CA033C88; Wed, 5 Mar 2003 03:07:30 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D9B9233C91; Wed, 5 Mar 2003 03:07:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 8821F33C88 for ; Wed, 5 Mar 2003 03:07:28 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 0383B62D31 for ; Wed, 5 Mar 2003 09:07:28 +0100 (CET) To: Subject: Re: [f-cpu] delayed issue From: Date: Wed, 5 Mar 2003 09:07:28 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030305080728.0383B62D31@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Yann Guidon a écrit : > hi ! > > nico wrote: > > >On Tue, 04 Mar 2003 05:49:07 +0100 > >Yann Guidon &lang=fr">whygee@f-cpu.org> > wrote: > > > >>hi ! > >> > >>devik wrote: > >> > >>>http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > >>> > >>>VERY interesting reading ! > >>> > >>almost in the same vein : > >> > >>http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf > >> > > > >:) nice :) Devik and whygee discover the 2 same things. > > > > > oops sorry i used the wrong address ! > > http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-09.pdf > (it speaks about coffee) > I should watch. > > > >>(don't look at the publication date too early) > >> > >>well, now it explains a lot of things i've read on their project > >>site.... they simply have fun with DARPA money. > >> > >:) How could you consider those researcher... That's... amazing. > > > > > i have visited MIT/AI lab once and i can tell you that the people i've > seen are a bit more serious ... > (and they are DARPA-funded too) > > > >>>Simplicity also has advantages that silicon efficiency on its own > >>>does not; simpler architectures are faster to design, > >>>easier to test, less prone to errors and friendlier to > >>>compilers. > >>> > >>> > >>This is why FC0 has no renamed registers, OOOE, > >>and other sophisticated control stuff. > >> > >> > >OOOC include some difficulties, too. > > > > > but i don't think it will consume 100k transistors for FC0, > and there are less pipeline stages dedicated to scheduling. > > In fact, the whole point of 000C in FC0 is that > the scheduling is partly performed in parallel with a non-OOOC > standard pipeline. This makes jump and loop overhead small > and further reduces the need for prediction and speculative > execution. Sur, but in one side you have 6 gates thin multiplier and in other side you try to put a 3r2w register bank of 64 entries in the same slot size... > > >>Additionally, more complexity means more silicon area, > >>more dissipation, longer wires => more heat/dissipation, > >>more expensive and probably slower. > >>And control logic is certainly the least easy thing > >>to test in a chip. This is why i'm satisfied with > >>the current FC0. > >> > >> > > > >not me :) Not when you saw the 3r2w regifile because of 1 or 2 > >instructions (like MAC). Not when you saw the mess of "special register" > >that should be memory mapped (with conditionnal memory movemement like > >not buffered, if needed). Not when you see the trap/expetion mess. > > > > > 1) 3R2W is necessary also for load and store instructions, otherwise it's not possible to perform pointer update in the instruction. Sur but, it's not really a true speed up and add a raw dependancies. > 2) If you map SRs to memory, you will face race conditions and > synchronisation problems, > and protection will not be enforced on a register or register group > granularity basis. It's exaclty the same problem for IO register, and it's soon solved. It's used by sparc and i'm pretty sur for ATM. There is no need for a specific buses, only the use of direct addressing had an interrest. > 3) what mess ? > The kind of linked-list that can't take nest interrupt that you speak about regularly. (shadow register could be far more easy...) > > >Beside that, i had beleived that tomasulo was a quick and "easy" OOOE. > >But it was not. It's the "canonical" OOOE. So it will be a big mess. Use > >of tomasolu could be an idea with a all different core to reduice memory > >foot print (like the use of 2 register adress fields instead of 3) but > >the pipeline need to be shorted to avoid the udge number of comparator > >that is needed. > > > > > Heh. > we are not IBM :-) > > >nicO > > > > > YG nicO > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Live_From_the_Street_99563@cac.net Wed Mar 5 06:58:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXbJ-0003LY-00 for ; Tue, 11 Mar 2003 01:26:37 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:26:37 +0100 (CET) Received: (qmail 9986 invoked by uid 0); 5 Mar 2003 05:59:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 5 Mar 2003 05:59:53 -0000 Received: by moria.seul.org (Postfix) id 67F7633C7C; Wed, 5 Mar 2003 00:59:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 244AB33C80; Wed, 5 Mar 2003 00:59:49 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 212.94.225.66 (unknown [212.94.225.66]) by moria.seul.org (Postfix) with SMTP id 4F75633C7C for ; Wed, 5 Mar 2003 00:59:45 -0500 (EST) Received: from unknown (HELO mail.gmx.net) (171.245.226.233)by rly-xl04.mx.aol.com with local; Mar, 04 2003 10:57:48 PM -0100 Received: from [72.62.68.193] by rly-yk04.mx.aol.com with asmtp; Mar, 04 2003 9:55:51 PM +0400 From: Morrel To: f-cpu@seul.org Subject: [f-cpu] NEW STOCK PICK: KIWI - Great Short-term Gainer........... hhq Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 4 Mar 2003 23:58:17 -0600 X-Mailer: AOL 7.0 for Windows US sub 118 Message-Id: <20030305055945.4F75633C7C@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

This is the very first broadcast of our new dept. LIVE FROM THE WIRE. LIVE FROM THE WIRE is different than any other stock recommendations you may have seen because unlike most, we were not paid to make this recommendation. This is not a pump and dump. To find out more about this ground-breaking site, go to Live From the Street.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  yrcmotgtcmbrjbbyngwoamndniqjiael ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 10:25:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXeu-0003LY-00 for ; Tue, 11 Mar 2003 01:30:20 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:30:20 +0100 (CET) Received: (qmail 32048 invoked by uid 0); 5 Mar 2003 09:30:08 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 5 Mar 2003 09:30:08 -0000 Received: by moria.seul.org (Postfix) id C984333C1A; Wed, 5 Mar 2003 04:30:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3192033CD2; Wed, 5 Mar 2003 04:29:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EF7BF33C1A for ; Wed, 5 Mar 2003 04:29:51 -0500 (EST) Received: from a54-137.dialup.iol.cz ([194.228.137.54] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qVDf-0006R3-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:29:48 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qV9e-0000L1-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:25:38 +0100 Date: Wed, 5 Mar 2003 10:25:38 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IEEE FP exceptions In-Reply-To: <20030304205822.2c50aa99.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > every instruction, the result is rounded to either float or double, > > any additional bits will be lost. Exceptional conditions can only be > > marked in a central status register. The only thing we could do is > > mark the result register in the scoreboard and raise an exception when > > it is used -- but that may be too late. > > But you can recompute the result by an other instruction block that is > more precise but slower. Exactly :) It is point of non-terminanting FP exceptions IMHO. With one flag per register you could do: divide(double x) attribute("force_all_floats_into_regs") { clear_fpex(x); // remove exception flag from "x" register if any y = seed(x); for (i=0;i<6;i++) y *= 2.0 - y*x; if (is_bad_fp(y)) return divide_precise(x) return y; } all FP would set hidden flag of result register on computation error and then you could check it. You could not need to serialize FP at all. Alternate way is to have clear_fpex & is_bad_fp as global (aby FP would write to single status register) and then both of these would need to be FP barrier. Idea would be to use them after big block of code, not after a few insns (and it is how programmers use them according to the paper). Thus this seem to be safe way for us - no exceptions (thus no problems with fcpu pipeline) only one small stat register. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 09:22:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXf2-0003LY-00 for ; Tue, 11 Mar 2003 01:30:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:30:28 +0100 (CET) Received: (qmail 30161 invoked by uid 0); 5 Mar 2003 09:31:02 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Mar 2003 09:31:02 -0000 Received: by moria.seul.org (Postfix) id A90EE33C39; Wed, 5 Mar 2003 04:30:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6E8F333F9E; Wed, 5 Mar 2003 04:29:59 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8ECD433C39 for ; Wed, 5 Mar 2003 04:29:53 -0500 (EST) Received: from a54-137.dialup.iol.cz ([194.228.137.54] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qVDh-0006R3-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:29:50 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qUAu-0000Kb-00 for f-cpu@seul.org; Wed, 05 Mar 2003 09:22:52 +0100 Date: Wed, 5 Mar 2003 09:22:52 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] second order prefetch in FC0 In-Reply-To: <20030304134335.9A17C62D6E@mallaury.noc.nerim.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > I don't like prefetch. Did gcc could really calculate the very narrow > windows where the prefetch is usefull ? Prefetch are implementation > dependant but also clock speed dependant ! I agree. No gcc can't do it itself. I wanted to try to go as back as I can in DF tree (idealy find nearest dominator of current BB) where address to prefetch is already known and place prefetch there. With second order (indirect) prefetch I can go sometimes one indirection further (before other load). Of course I need to detect CFG cycles and don't withdraw prefetch out of a loop. OOOE core is better for hiding memory latency. Or at least non-blocking loads would help in FC0 but I have little idea how to implement them effeciently. On other side non-blocking read still ties one register, prefetch doesn't (it rather uses cache line). The answer can be got only by simulation of real code IMHO. > I prefer multi-load/store much more (a complete cache line for example > that fill 4 or 8 registers). What does it help ? It could be used in prolog/epilog but not in midle. Maybe it could be useful when unrolling loops too to read whole cacheline. But for example with OR-LSU I proposed you can do it even without multiload. > So you're proposal look like a kind of double load ( a = toto -> titi > ) or load then store (toto->titi = a). This could be a feature of > "internal cpu buses" and a new instruction. As we control L1/L2 access > and we don't need to conform to the limited feature of SDRAM, this > kind of bus cycle could be added and optimised closed to the cache > controller. yeah it sounds reasonable. Once I got time I'll look to gcc prefetches so we get some stats on usage of this one. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 10:28:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXfO-0003LY-00 for ; Tue, 11 Mar 2003 01:30:50 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:30:50 +0100 (CET) Received: (qmail 1456 invoked by uid 0); 5 Mar 2003 09:31:44 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Mar 2003 09:31:44 -0000 Received: by moria.seul.org (Postfix) id EA0A833C91; Wed, 5 Mar 2003 04:31:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 75DEA33FC5; Wed, 5 Mar 2003 04:30:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B465133C7E for ; Wed, 5 Mar 2003 04:30:06 -0500 (EST) Received: from a54-137.dialup.iol.cz ([194.228.137.54] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qVDv-0006RH-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:30:04 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qVCr-0000L3-00 for f-cpu@seul.org; Wed, 05 Mar 2003 10:28:57 +0100 Date: Wed, 5 Mar 2003 10:28:57 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] delayed issue In-Reply-To: <20030305080728.0383B62D31@mallaury.noc.nerim.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > 2) If you map SRs to memory, you will face race conditions and > > synchronisation problems, > > and protection will not be enforced on a register or register group > > granularity basis. > > It's exaclty the same problem for IO register, and it's soon solved. > It's used by sparc and i'm pretty sur for ATM. There is no need for a > specific buses, only the use of direct addressing had an interrest. What's problem with SRs ? They seemed rather elegant to me. If get/put insns are serializing then all stuff which need serialize can be put there. Or did I miss something ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 11:15:51 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXfj-0003LY-00 for ; Tue, 11 Mar 2003 01:31:11 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:31:11 +0100 (CET) Received: (qmail 22476 invoked by uid 0); 5 Mar 2003 10:17:39 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 5 Mar 2003 10:17:39 -0000 Received: by moria.seul.org (Postfix) id 1358E33CD2; Wed, 5 Mar 2003 05:17:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 42F7C33FB2; Wed, 5 Mar 2003 05:17:36 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8CDC333CD2 for ; Wed, 5 Mar 2003 05:17:34 -0500 (EST) Received: from a68-137.dialup.iol.cz ([194.228.137.68] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qVxp-0006hi-00 for f-cpu@seul.org; Wed, 05 Mar 2003 11:17:30 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qVwF-0000Mr-00 for f-cpu@seul.org; Wed, 05 Mar 2003 11:15:51 +0100 Date: Wed, 5 Mar 2003 11:15:51 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] second order prefetch in FC0 In-Reply-To: <3E652410.1010101@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > - Alpha 21264 uses data and instruction cache chaining (i don't > remember the right term). > Each cache line contains 2 physical addresses of the last two memory > accesses > after the cache line was used. This speeds up linked lists because in > the case > of the cache line being used, the cache mechanism will prefetch the 2 > cache lines > referenced by the tag. > But, as i presume, these methods are certainly completely mined by patents. I just looked USPTO and didn't find such patent. Also in 21264 hw manual is no such data in cacheline ?? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 16:36:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXiZ-0003LY-00 for ; Tue, 11 Mar 2003 01:34:07 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:34:07 +0100 (CET) Received: (qmail 22516 invoked by uid 0); 5 Mar 2003 16:31:16 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 5 Mar 2003 16:31:16 -0000 Received: by moria.seul.org (Postfix) id 1295133C62; Wed, 5 Mar 2003 11:31:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 178FD33CB6; Wed, 5 Mar 2003 11:31:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4454433C62 for ; Wed, 5 Mar 2003 11:31:09 -0500 (EST) Received: from f-cpu.org (lcbv4-2-247.n.club-internet.fr [213.44.93.247]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 7EDDC16C7 for ; Wed, 5 Mar 2003 17:29:59 +0100 (CET) Message-ID: <3E661994.5070409@f-cpu.org> Date: Wed, 05 Mar 2003 16:36:52 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >> - Alpha 21264 uses data and instruction cache chaining (i don't >>remember the right term). >> Each cache line contains 2 physical addresses of the last two memory >>accesses >> after the cache line was used. This speeds up linked lists because in >>the case >> of the cache line being used, the cache mechanism will prefetch the 2 >>cache lines >> referenced by the tag. >>But, as i presume, these methods are certainly completely mined by patents. >> >> >I just looked USPTO and didn't find such patent. > it's surprising but not improbable. patents are now complex strategies and they have probably made a string of patents to cover all parts and aspects, rather than 1 patent describing the whole stuff, just to be sure that there is no possibility to bypass the patent. > Also in 21264 hw >manual is no such data in cacheline ?? > > or maybe it was 21364. If it is possible to do, it will probably be implemented in FC0 but i don't want to take risks. >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 17:34:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXit-0003LY-00 for ; Tue, 11 Mar 2003 01:34:27 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:34:27 +0100 (CET) Received: (qmail 27175 invoked by uid 0); 5 Mar 2003 16:35:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 5 Mar 2003 16:35:17 -0000 Received: by moria.seul.org (Postfix) id 0BB6F33F9E; Wed, 5 Mar 2003 11:35:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 49CF933FC2; Wed, 5 Mar 2003 11:35:13 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B517933F9E for ; Wed, 5 Mar 2003 11:35:11 -0500 (EST) Received: from localhost ([127.0.0.1]) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 18qbrJ-0000CP-00 for f-cpu@seul.org; Wed, 05 Mar 2003 17:35:09 +0100 Date: Wed, 5 Mar 2003 17:34:58 +0100 (CET) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 In-Reply-To: <3E661994.5070409@f-cpu.org> Message-ID: References: <3E661994.5070409@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > it's surprising but not improbable. > patents are now complex strategies and they have probably > made a string of patents to cover all parts and aspects, > rather than 1 patent describing the whole stuff, > just to be sure that there is no possibility to bypass the patent. > > > Also in 21264 hw > >manual is no such data in cacheline ?? > or maybe it was 21364. > > If it is possible to do, it will probably be implemented in FC0 > but i don't want to take risks. I understand. Maybe we could ask at comp.cpu.architecture as many people are there ... I found some citations about multi-prefetch techniques so that maybe it is/was unpatentable prior art. What would be holder of patent, DEC ? And in range 1990-1992 I think. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 16:48:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXj8-0003LY-00 for ; Tue, 11 Mar 2003 01:34:42 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:34:42 +0100 (CET) Received: (qmail 26811 invoked by uid 0); 5 Mar 2003 16:42:45 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 5 Mar 2003 16:42:45 -0000 Received: by moria.seul.org (Postfix) id A24E033CD4; Wed, 5 Mar 2003 11:42:43 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 004A533FC2; Wed, 5 Mar 2003 11:42:42 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 51CA433CD4 for ; Wed, 5 Mar 2003 11:42:42 -0500 (EST) Received: from f-cpu.org (lcbv4-2-247.n.club-internet.fr [213.44.93.247]) by relay-4v.club-internet.fr (Postfix) with ESMTP id C9ED01715 for ; Wed, 5 Mar 2003 17:42:34 +0100 (CET) Message-ID: <3E661C49.1020808@f-cpu.org> Date: Wed, 05 Mar 2003 16:48:25 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 References: <3E661994.5070409@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Martin Devera wrote: >>it's surprising but not improbable. >>patents are now complex strategies and they have probably >>made a string of patents to cover all parts and aspects, >>rather than 1 patent describing the whole stuff, >>just to be sure that there is no possibility to bypass the patent. >> >> >>>Also in 21264 hw >>>manual is no such data in cacheline ?? >>> >>> >>or maybe it was 21364. >> >>If it is possible to do, it will probably be implemented in FC0 >>but i don't want to take risks. >> >> > >I understand. Maybe we could ask at comp.cpu.architecture as >many people are there ... > i can access to comp.arch but comp.cpu.architecture is unknown in my server :-/ >I found some citations about multi-prefetch techniques so that >maybe it is/was unpatentable prior art. > what is multiprefetch ? is it several interleaved prefetches ? >What would be holder of patent, DEC ? And in range 1990-1992 >I think. > > the technique i've described is more in the 1995/1998 range. and it's really an excellent idea, but probably too complex to do first. a decently working cache is necessary in the beginning, then we can enhance it .... >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 5 18:00:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXji-0003LY-00 for ; Tue, 11 Mar 2003 01:35:18 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:35:18 +0100 (CET) Received: (qmail 18697 invoked by uid 0); 5 Mar 2003 17:00:55 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Mar 2003 17:00:55 -0000 Received: by moria.seul.org (Postfix) id C597F33C5D; Wed, 5 Mar 2003 12:00:53 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5B19033C85; Wed, 5 Mar 2003 12:00:52 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 50BA633C5D for ; Wed, 5 Mar 2003 12:00:51 -0500 (EST) Received: from localhost ([127.0.0.1]) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 18qcG7-0000Lr-00 for f-cpu@seul.org; Wed, 05 Mar 2003 18:00:47 +0100 Date: Wed, 5 Mar 2003 18:00:47 +0100 (CET) From: Martin Devera To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 In-Reply-To: <3E661C49.1020808@f-cpu.org> Message-ID: References: <3E661994.5070409@f-cpu.org> <3E661C49.1020808@f-cpu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >I understand. Maybe we could ask at comp.cpu.architecture as > >many people are there ... > > > i can access to comp.arch but comp.cpu.architecture is unknown in my > server :-/ sorry I mean .arch. I never remember the names. > >I found some citations about multi-prefetch techniques so that > >maybe it is/was unpatentable prior art. > > > what is multiprefetch ? > is it several interleaved prefetches ? it is generaly technique to prefetch along multiple pointer paths. Like to prefetch both pre and next item along with main item. Or two prev & next. If DEC patented its use inside of cachelines we could go by suppoorting sw multi prefetch by some insn. It should be tested in gcc first of course. By the way, when we describe the idea here, can it be taken as prior art ? So nobody can patent it ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 5 15:13:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXjs-0003LY-00 for ; Tue, 11 Mar 2003 01:35:28 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:35:28 +0100 (CET) Received: (qmail 32022 invoked by uid 0); 5 Mar 2003 17:05:09 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 5 Mar 2003 17:05:09 -0000 Received: by moria.seul.org (Postfix) id D940333C85; Wed, 5 Mar 2003 12:05:08 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7216533FBD; Wed, 5 Mar 2003 12:05:07 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a144.home.uni-hannover.de [130.75.232.144]) by moria.seul.org (Postfix) with ESMTP id 5840833C85 for ; Wed, 5 Mar 2003 12:05:05 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00755; Wed, 5 Mar 2003 15:13:02 +0100 Message-ID: <20030305151301.33325@thrai.stud.uni-hannover.de> Date: Wed, 5 Mar 2003 15:13:01 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <20030304205822.2c50aa99.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Mar 05, 2003 at 10:25:38AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Mar 05, 2003 at 10:25:38AM +0100, devik wrote: [...] > With one flag per register you could do: > > divide(double x) attribute("force_all_floats_into_regs") > { > clear_fpex(x); // remove exception flag from "x" register if any > y = seed(x); > for (i=0;i<6;i++) > y *= 2.0 - y*x; > if (is_bad_fp(y)) return divide_precise(x) > return y; > } Hmm... the canonical way is to return INF or NAN if something goes wrong. You could also do it like this: double divide(double x) { double y; y = iterate(x, seed(x)); switch (fpclassify(y)) { case FP_ZERO: case FP_NORMAL: return y; case FP_SUBNORMAL: /* gradual underflow */ case FP_INFINITE: case FP_NAN: break; } return divide_precise(x) } > all FP would set hidden flag of result register on computation > error and then you could check it. You could not need to serialize > FP at all. What if you use an integer instruction to modify the result? E.g. clear or change the sign bit (fabs/fneg), modify the exponent (fscale) and such? They won't be aware of the extra bit, and won't maintain it (or probably reset it to 0). We would have to check the `fpex' flag with an explicit `jmp.fpx' or `move.fpx' instruction (which would replace the current `jmp.nan'/`move.nan'). > Alternate way is to have clear_fpex & is_bad_fp as global (aby > FP would write to single status register) and then both of > these would need to be FP barrier. I prefer the non-serializing variant, with the option that the CPU may trap if the flag is set on any of the input operands of an FP instruction (just like it will do when the zero flag is set on a divisor). That means that the flag should go into the scoreboard. We can also provide some bits in the FPU control register that specify when the fpex flag will be set (to exclude conditions that aren't interesting, e.g. inexact result or gradual underflow). The remaining problem is that the fpex flags must be saved and restored when a task switch occurs, either automatically or with an explicit special instruction. Another question is: What do we do in SIMD mode? Use a single flag for all chunks? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 17:12:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXk5-0003LY-00 for ; Tue, 11 Mar 2003 01:35:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:35:41 +0100 (CET) Received: (qmail 11768 invoked by uid 0); 5 Mar 2003 17:06:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 5 Mar 2003 17:06:40 -0000 Received: by moria.seul.org (Postfix) id F421D33FBD; Wed, 5 Mar 2003 12:06:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CF2E33FC2; Wed, 5 Mar 2003 12:06:30 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id C365F33CB6 for ; Wed, 5 Mar 2003 12:06:29 -0500 (EST) Received: from f-cpu.org (lcbv4-2-247.n.club-internet.fr [213.44.93.247]) by relay-3m.club-internet.fr (Postfix) with ESMTP id F0DD6E143 for ; Wed, 5 Mar 2003 18:07:25 +0100 (CET) Message-ID: <3E6621EC.6000109@f-cpu.org> Date: Wed, 05 Mar 2003 17:12:28 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, cyrano@nerim.net wrote: >Yann Guidon a écrit : > >>hi ! >> >>nico wrote: >> >>oops sorry i used the wrong address ! >> >>http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-09.pdf >>(it speaks about coffee) >> >I should watch. > > you'd better do it now :-) >>>>>Simplicity also has advantages that silicon efficiency on its own >>>>>does not; simpler architectures are faster to design, >>>>>easier to test, less prone to errors and friendlier to >>>>>compilers. >>>>> >>>>This is why FC0 has no renamed registers, OOOE, >>>>and other sophisticated control stuff. >>>> >>>OOOC include some difficulties, too. >>> >>> >>but i don't think it will consume 100k transistors for FC0, >>and there are less pipeline stages dedicated to scheduling. >> >>In fact, the whole point of 000C in FC0 is that >>the scheduling is partly performed in parallel with a non-OOOC >>standard pipeline. This makes jump and loop overhead small >>and further reduces the need for prediction and speculative >>execution. >> >> >Sur, but in one side you have 6 gates thin multiplier and in other side you try to put a 3r2w register bank of 64 entries in the same slot size... > > don't worry .... the decoding logic (data ready, unit ready, etc.) will probably need some more pipe stages in "high-speed" versions (where the pipelines are correctly sliced). It's just a matter of splitting the stages correctly. Remember, the first FC0-OOOC had no jump latency and now it it one. If the register set is really slow, we can't do much better but it's not worth adding complex renaming buffers : the register's access time will not be faster. Enhancing (through longer pipeline) the decoder is a better solution. >>>>Additionally, more complexity means more silicon area, >>>>more dissipation, longer wires => more heat/dissipation, >>>>more expensive and probably slower. >>>>And control logic is certainly the least easy thing >>>>to test in a chip. This is why i'm satisfied with >>>>the current FC0. >>>> >>>not me :) Not when you saw the 3r2w regifile because of 1 or 2 >>>instructions (like MAC). Not when you saw the mess of "special register" >>>that should be memory mapped (with conditionnal memory movemement like >>>not buffered, if needed). Not when you see the trap/expetion mess. >>> >>1) 3R2W is necessary also for load and store instructions, otherwise it's not possible to perform pointer update in the instruction. >> >> >Sur but, it's not really a true speed up and add a raw dependancies. > > ?????? oh, and what about your 'code density' argument ? if you don't allow post-increment, then you need more instructions to compute the addresses. >>2) If you map SRs to memory, you will face race conditions and >>synchronisation problems, >> and protection will not be enforced on a register or register group >>granularity basis. >> >> >It's exaclty the same problem for IO register, and it's soon solved. > SRs are not for I/O (because it would become a bottleneck). The problem, hence the solution, is not the same. > It's used by sparc and i'm pretty sur for ATM. > ATM ? >There is no need for a specific buses, only the use of direct addressing had an interrest. > > ??? >>3) what mess ? >> >The kind of linked-list that can't take nest interrupt that you speak about regularly. (shadow register could be far more easy...) > > ??? >>>nicO >>> >>YG >> >> >nicO > > YG again ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Wed Mar 5 18:21:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXlt-0003LY-00 for ; Tue, 11 Mar 2003 01:37:33 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:37:33 +0100 (CET) Received: (qmail 11857 invoked by uid 0); 5 Mar 2003 17:21:58 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 5 Mar 2003 17:21:58 -0000 Received: by moria.seul.org (Postfix) id E58A433C86; Wed, 5 Mar 2003 12:21:56 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BBD6E33FC2; Wed, 5 Mar 2003 12:21:55 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.7]) by moria.seul.org (Postfix) with ESMTP id 2B80233C86 for ; Wed, 5 Mar 2003 12:21:55 -0500 (EST) Received: from homeworld (80.14.37.215) by mx.laposte.net (6.0.053) id 3E493B3600386672 for f-cpu@seul.org; Wed, 5 Mar 2003 18:21:53 +0100 Message-ID: <000d01c2e33b$b14db270$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> <3E6621EC.6000109@f-cpu.org> Subject: Re: [f-cpu] delayed issue Date: Wed, 5 Mar 2003 18:21:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Wednesday, March 05, 2003 5:12 PM Subject: Re: [f-cpu] delayed issue > >>2) If you map SRs to memory, you will face race conditions and > >>synchronisation problems, > >> and protection will not be enforced on a register or register group > >>granularity basis. > >> > >> > >It's exaclty the same problem for IO register, and it's soon solved. > > > SRs are not for I/O (because it would become a bottleneck). > The problem, hence the solution, is not the same. Quite now, I suspected SR to be equivalent to Intel SMR register, that is, PUT/GET are equivalent to Intel WSMR/RSMR and not to Intel IN/OUT. Am I wrong ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 20:38:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXuQ-0003LY-00 for ; Tue, 11 Mar 2003 01:46:22 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:46:22 +0100 (CET) Received: (qmail 9707 invoked by uid 0); 5 Mar 2003 20:32:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 5 Mar 2003 20:32:28 -0000 Received: by moria.seul.org (Postfix) id B6FD133FC5; Wed, 5 Mar 2003 15:32:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B788A33FC6; Wed, 5 Mar 2003 15:32:22 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id A376133FC5 for ; Wed, 5 Mar 2003 15:32:20 -0500 (EST) Received: from f-cpu.org (lcbv2-2-95.n.club-internet.fr [213.44.20.95]) by relay-1m.club-internet.fr (Postfix) with ESMTP id EEB1E16C6 for ; Wed, 5 Mar 2003 21:32:44 +0100 (CET) Message-ID: <3E66522C.4020100@f-cpu.org> Date: Wed, 05 Mar 2003 20:38:20 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] second order prefetch in FC0 References: <3E661994.5070409@f-cpu.org> <3E661C49.1020808@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Martin Devera wrote: >>>I understand. Maybe we could ask at comp.cpu.architecture as >>>many people are there ... >>> >>> >>> >>i can access to comp.arch but comp.cpu.architecture is unknown in my >>server :-/ >> >> >sorry I mean .arch. I never remember the names. > > heh, "comp.arch" is simple enough to remember it :-P >>>I found some citations about multi-prefetch techniques so that >>>maybe it is/was unpatentable prior art. >>> >>what is multiprefetch ? >>is it several interleaved prefetches ? >> >> >it is generaly technique to prefetch along multiple >pointer paths. Like to prefetch both pre and next item >along with main item. Or two prev & next. >If DEC patented its use inside of cachelines we could go >by suppoorting sw multi prefetch by some insn. >It should be tested in gcc first of course. > >By the way, when we describe the idea here, can it be >taken as prior art ? So nobody can patent it ? > > in theory, .... and in practice .... you can't be sure because lawyers are masters at bendind reality and our subject is a dangerous minefield. It's why F-CPU is more secure than OpenRISC because Damjan & Co. have based their architecture on MIPS, while F-CPU is completely unrelated (this answers to another mail) so there are less risks to come across their patents. >devik > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 20:38:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXuD-0003LY-00 for ; Tue, 11 Mar 2003 01:46:09 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:46:09 +0100 (CET) Received: (qmail 22532 invoked by uid 0); 5 Mar 2003 20:32:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 5 Mar 2003 20:32:21 -0000 Received: by moria.seul.org (Postfix) id 79BD633F63; Wed, 5 Mar 2003 15:32:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AC90D33FC4; Wed, 5 Mar 2003 15:32:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id 351C933F63 for ; Wed, 5 Mar 2003 15:32:19 -0500 (EST) Received: from f-cpu.org (lcbv2-2-95.n.club-internet.fr [213.44.20.95]) by relay-3m.club-internet.fr (Postfix) with ESMTP id ACCA6E216 for ; Wed, 5 Mar 2003 21:33:15 +0100 (CET) Message-ID: <3E66522A.1030905@f-cpu.org> Date: Wed, 05 Mar 2003 20:38:18 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions References: <20030304205822.2c50aa99.nicolas.boulay@ifrance.com> <20030305151301.33325@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Wed, Mar 05, 2003 at 10:25:38AM +0100, devik wrote: >[...] > > > >>all FP would set hidden flag of result register on computation >>error and then you could check it. You could not need to serialize >>FP at all. >> >> > >What if you use an integer instruction to modify the result? E.g. >clear or change the sign bit (fabs/fneg), modify the exponent (fscale) >and such? They won't be aware of the extra bit, and won't maintain it >(or probably reset it to 0). We would have to check the `fpex' flag >with an explicit `jmp.fpx' or `move.fpx' instruction (which would replace >the current `jmp.nan'/`move.nan'). > > argh .... This last conditional code seems to be very attractive but it looks like nobody is agreeing for its use.... Another problem is to do something realistic and that can be implemented : NaN is a condition that can be easily found from "decoding" the FP data. Well, now there is the problem : is it for 32 bits or 64 bits FP ? and what about the SIMD versions ? On top of that, if an "FP exception" condition (which has a similar role to NaN) is implemented, how can this be decoded ? If an additional bit is necessary for the context swap, it's not possible to implement it because its restoration will be impossible. That's why i proposed NaN as an error condition But this could be more general, with +/- infinite and other things. >>Alternate way is to have clear_fpex & is_bad_fp as global (aby >>FP would write to single status register) and then both of >>these would need to be FP barrier. >> >> > >I prefer the non-serializing variant, with the option that the CPU may >trap if the flag is set on any of the input operands of an FP instruction >(just like it will do when the zero flag is set on a divisor). That >means that the flag should go into the scoreboard. > >We can also provide some bits in the FPU control register that specify >when the fpex flag will be set (to exclude conditions that aren't >interesting, e.g. inexact result or gradual underflow). > >The remaining problem is that the fpex flags must be saved and restored >when a task switch occurs, either automatically or with an explicit >special instruction. > >Another question is: What do we do in SIMD mode? Use a single flag >for all chunks? > i think that this question is even more important and challenging than the condition problem.... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Wed Mar 5 23:32:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sXws-0003LY-00 for ; Tue, 11 Mar 2003 01:48:54 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:48:54 +0100 (CET) Received: (qmail 6284 invoked by uid 0); 5 Mar 2003 21:33:03 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 5 Mar 2003 21:33:03 -0000 Received: by moria.seul.org (Postfix) id BF4A233B81; Wed, 5 Mar 2003 16:32:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A82C833FC4; Wed, 5 Mar 2003 16:32:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 3FBA433B81 for ; Wed, 5 Mar 2003 16:32:47 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id B160762E1C for ; Wed, 5 Mar 2003 22:32:43 +0100 (CET) Date: Wed, 5 Mar 2003 22:32:11 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] IEEE FP exceptions Message-Id: <20030305223211.5866f310.nicolas.boulay@ifrance.com> In-Reply-To: <3E66522A.1030905@f-cpu.org> References: <20030304205822.2c50aa99.nicolas.boulay@ifrance.com> <20030305151301.33325@thrai.stud.uni-hannover.de> <3E66522A.1030905@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 05 Mar 2003 20:38:18 +0100 Yann Guidon wrote: > hi, > > Michael Riepe wrote: > > >On Wed, Mar 05, 2003 at 10:25:38AM +0100, devik wrote: > >[...] > > > > > > > >>all FP would set hidden flag of result register on computation > >>error and then you could check it. You could not need to serialize > >>FP at all. > >> > >> > > > >What if you use an integer instruction to modify the result? E.g. > >clear or change the sign bit (fabs/fneg), modify the exponent > >(fscale) and such? They won't be aware of the extra bit, and won't > >maintain it(or probably reset it to 0). We would have to check the > >`fpex' flag with an explicit `jmp.fpx' or `move.fpx' instruction > >(which would replace the current `jmp.nan'/`move.nan'). > > > > > > argh .... > > This last conditional code seems to be very attractive but it looks > like nobody is agreeing for its use.... > Discuss is on going. > > Another problem is to do something realistic and that can be > implemented : NaN is a condition that can be easily found from > "decoding" the FP data. Well, now there is the problem : is it for 32 > bits or 64 bits FP ? and what about > the SIMD versions ? > On top of that, if an "FP exception" condition (which has a similar > role to NaN) > is implemented, how can this be decoded ? > If an additional bit is necessary for the context swap, it's not > possible to implement it > because its restoration will be impossible. That's why i proposed NaN > as an error condition > But this could be more general, with +/- infinite and other things. > > > >>Alternate way is to have clear_fpex & is_bad_fp as global (aby > >>FP would write to single status register) and then both of > >>these would need to be FP barrier. > >> > >> > > > >I prefer the non-serializing variant, with the option that the CPU > >may trap if the flag is set on any of the input operands of an FP > >instruction(just like it will do when the zero flag is set on a > >divisor). That means that the flag should go into the scoreboard. > > > >We can also provide some bits in the FPU control register that > >specify when the fpex flag will be set (to exclude conditions that > >aren't interesting, e.g. inexact result or gradual underflow). > > > >The remaining problem is that the fpex flags must be saved and > >restored when a task switch occurs, either automatically or with an > >explicit special instruction. > > > >Another question is: What do we do in SIMD mode? Use a single flag > >for all chunks? > > > i think that this question is even more important and challenging than > the condition problem.... > I beleive that all the chunk should be traited the same. So you will change the code for all the data, so a bit for a single vector ("there was at least one NaN"). > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Thu Mar 6 00:50:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sY2r-0003LY-00 for ; Tue, 11 Mar 2003 01:55:05 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:55:05 +0100 (CET) Received: (qmail 12328 invoked by uid 0); 5 Mar 2003 22:51:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 5 Mar 2003 22:51:23 -0000 Received: by moria.seul.org (Postfix) id CAF2733CDD; Wed, 5 Mar 2003 17:51:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 836E433CE6; Wed, 5 Mar 2003 17:51:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 6A24E33C6D for ; Wed, 5 Mar 2003 17:51:14 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id DF58440EF4 for ; Wed, 5 Mar 2003 23:51:11 +0100 (CET) Date: Wed, 5 Mar 2003 23:50:38 +0000 From: nico To: f-cpu@seul.org Subject: SR [was:Re: [f-cpu] delayed issue] Message-Id: <20030305235038.77ef104b.nicolas.boulay@ifrance.com> In-Reply-To: <3E6621EC.6000109@f-cpu.org> References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> <3E6621EC.6000109@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, 05 Mar 2003 17:12:28 +0100 Yann Guidon wrote: <...> > >Sur, but in one side you have 6 gates thin multiplier and in other > >side you try to put a 3r2w register bank of 64 entries in the same > >slot size... > > > > > don't worry .... > the decoding logic (data ready, unit ready, etc.) will probably need > some more pipe stages > in "high-speed" versions (where the pipelines are correctly sliced). > It's just a matter of splitting the stages correctly. > Remember, the first FC0-OOOC had no jump latency and now it it one. > If the register set is really slow, we can't do much better but it's > not worth > adding complex renaming buffers : the register's access time will not > be faster. > Enhancing (through longer pipeline) the decoder is a better solution. > Sur but then you will have jump penalty. > >>>>Additionally, more complexity means more silicon area, > >>>>more dissipation, longer wires => more heat/dissipation, > >>>>more expensive and probably slower. > >>>>And control logic is certainly the least easy thing > >>>>to test in a chip. This is why i'm satisfied with > >>>>the current FC0. > >>>> > >>>not me :) Not when you saw the 3r2w regifile because of 1 or 2 > >>>instructions (like MAC). Not when you saw the mess of "special > >register">>that should be memory mapped (with conditionnal memory > >movemement like>>not buffered, if needed). Not when you see the > >trap/expetion mess.>> > >>1) 3R2W is necessary also for load and store instructions, otherwise > >it's not possible to perform pointer update in the instruction.> > >> > >Sur but, it's not really a true speed up and add a raw dependancies. > > > > > ?????? > > oh, and what about your 'code density' argument ? > if you don't allow post-increment, then you need more instructions to > compute the addresses. > Humm... i think about "true" 4r2w (on liw) but with 1r1w split register bank. The first problem is the use of 3r2w reg bank but 90% of the instruction are 2r1w. > > >>2) If you map SRs to memory, you will face race conditions and > >>synchronisation problems, > >> and protection will not be enforced on a register or register group > >>granularity basis. > >> > >> > >It's exaclty the same problem for IO register, and it's soon solved. > > > SRs are not for I/O (because it would become a bottleneck). > The problem, hence the solution, is not the same. > The problem is buffuring anf ordering. Like for IO registers memory mapped. > > > It's used by sparc and i'm pretty sur for ATM. > > > ATM ? > ARM. Sorry. > >There is no need for a specific buses, only the use of direct > >addressing had an interrest. > > > > > ??? Use set/get is like a load/store using direct adressing. > > >>3) what mess ? > >> > >The kind of linked-list that can't take nest interrupt that you speak > >about regularly. (shadow register could be far more easy...) > > > > > ??? > SR was just for some constant reading, then you use it for system control(like for trap handling). Each time some dust are on the design pchout it send to SR, like a wide carpet. SR are slow because serialiased. SR can't be preserve by context switch because it sill be a mess. So only read is premit. We could also put register trap pointer, TLB ... But register mapped seems so easier (don't forget that SR are direct mapped). nicO > >>>nicO > >>> > >>YG > >> > >> > >nicO > > > > > YG again > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Mar 5 23:57:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sY4Y-0003LY-00 for ; Tue, 11 Mar 2003 01:56:50 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 01:56:50 +0100 (CET) Received: (qmail 23924 invoked by uid 0); 5 Mar 2003 23:51:56 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 5 Mar 2003 23:51:56 -0000 Received: by moria.seul.org (Postfix) id C0A5633DC4; Wed, 5 Mar 2003 18:51:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4480333FC2; Wed, 5 Mar 2003 18:51:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 4692433DC4 for ; Wed, 5 Mar 2003 18:51:53 -0500 (EST) Received: from f-cpu.org (lcbv4-2-67.n.club-internet.fr [213.44.93.67]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 1721A16E2 for ; Thu, 6 Mar 2003 00:51:48 +0100 (CET) Message-ID: <3E6680ED.9020704@f-cpu.org> Date: Wed, 05 Mar 2003 23:57:49 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] delayed issue References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> <3E6621EC.6000109@f-cpu.org> <000d01c2e33b$b14db270$8000a8c0@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Christophe Avoinne wrote: From: "Yann Guidon" > > >>>>2) If you map SRs to memory, you will face race conditions and >>>>synchronisation problems, >>>>and protection will not be enforced on a register or register group >>>>granularity basis. >>>> >>>It's exaclty the same problem for IO register, and it's soon solved. >>> >>SRs are not for I/O (because it would become a bottleneck). >>The problem, hence the solution, is not the same. >> >> > >Quite now, I suspected SR to be equivalent to Intel SMR register, that is, >PUT/GET are equivalent to Intel WSMR/RSMR and not to Intel IN/OUT. > >Am I wrong ? > > you're right, it is almost the same principle as the MSR (as "Machine Specific Registers") except that the model is much more cleaned. The map preserves compatibility across machines so it's not "Machine Specific". Additionally, it helps keep the instruction set simple and short : there is not a bunch of particular registers with particular instructions to access them (like : Interrupt table management, page table management etc.) -> everything is in a single, serializing (-> no border effect) space that is independent for each CPU. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Thu Mar 6 10:33:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYGL-0003LY-00 for ; Tue, 11 Mar 2003 02:09:01 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:09:01 +0100 (CET) Received: (qmail 4822 invoked by uid 0); 6 Mar 2003 09:33:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 6 Mar 2003 09:33:40 -0000 Received: by moria.seul.org (Postfix) id EAB3933CF5; Thu, 6 Mar 2003 04:33:39 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3DC3833FC2; Thu, 6 Mar 2003 04:33:38 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 5846F33CF5 for ; Thu, 6 Mar 2003 04:33:36 -0500 (EST) Received: from homeworld (80.14.37.190) by mx.laposte.net (6.0.053) id 3E669FFE0000E994 for f-cpu@seul.org; Thu, 6 Mar 2003 10:33:34 +0100 Message-ID: <009e01c2e3c3$70cdd260$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030305080728.0383B62D31@mallaury.noc.nerim.net><3E6621EC.6000109@f-cpu.org> <20030305235038.77ef104b.nicolas.boulay@ifrance.com> Subject: Re: SR [was:Re: [f-cpu] delayed issue] Date: Thu, 6 Mar 2003 10:33:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "nico" To: Sent: Thursday, March 06, 2003 12:50 AM Subject: SR [was:Re: [f-cpu] delayed issue] > > >There is no need for a specific buses, only the use of direct > > >addressing had an interrest. > > > > > > > > ??? > > Use set/get is like a load/store using direct adressing. > > > > > >>3) what mess ? > > >> > > >The kind of linked-list that can't take nest interrupt that you speak > > >about regularly. (shadow register could be far more easy...) > > > > > > > > ??? > > > > SR was just for some constant reading, then you use it for system > control(like for trap handling). Each time some dust are on the design > pchout it send to SR, like a wide carpet. > > SR are slow because serialiased. SR can't be preserve by context switch > because it sill be a mess. So only read is premit. > > We could also put register trap pointer, TLB ... But register mapped > seems so easier (don't forget that SR are direct mapped). > Just a precision, the ARM has a coprocessor interface : it can handle with 16 (or 15) coprocessors and has an small uniform set of instruction to help to communicate between itself and a coprocessor. For example, the MMU handling is done with the coprocessor number 15. It is a very good idea because you can transfer ARM registers and CP15 registers to and fro, make CP15 load or store address, etc. Whygee, if interested, just have a look on S3C2410, ARM9 isa part and MMU part, where they explain how to handle MMU coprocessor. That kind of interface could be very interesting for F-CPU to add external coprocessor and have a more tighly coupled functions. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Mar 6 09:19:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYG1-0003LY-00 for ; Tue, 11 Mar 2003 02:08:41 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:08:41 +0100 (CET) Received: (qmail 24220 invoked by uid 0); 6 Mar 2003 09:12:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 6 Mar 2003 09:12:20 -0000 Received: by moria.seul.org (Postfix) id 32B5C33CF2; Thu, 6 Mar 2003 04:12:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2AFED33DED; Thu, 6 Mar 2003 04:12:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id DE06833CF2 for ; Thu, 6 Mar 2003 04:12:13 -0500 (EST) Received: from a94-137.dialup.iol.cz ([194.228.137.94] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18qrPy-0004Ta-00 for f-cpu@seul.org; Thu, 06 Mar 2003 10:12:03 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18qqay-0000DT-00 for f-cpu@seul.org; Thu, 06 Mar 2003 09:19:16 +0100 Date: Thu, 6 Mar 2003 09:19:16 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IEEE FP exceptions In-Reply-To: <20030305151301.33325@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Alternate way is to have clear_fpex & is_bad_fp as global (aby > > FP would write to single status register) and then both of > > these would need to be FP barrier. > > I prefer the non-serializing variant, with the option that the CPU may > trap if the flag is set on any of the input operands of an FP instruction > (just like it will do when the zero flag is set on a divisor). That > means that the flag should go into the scoreboard. I think so. > We can also provide some bits in the FPU control register that specify > when the fpex flag will be set (to exclude conditions that aren't > interesting, e.g. inexact result or gradual underflow). yes. > The remaining problem is that the fpex flags must be saved and restored > when a task switch occurs, either automatically or with an explicit > special instruction. maybe other SR ? We would have to serialize FPU in any case .. > Another question is: What do we do in SIMD mode? Use a single flag > for all chunks? good question. Because max no of chunks is not limited it would be much simpler to have single flag. Also when one chunk would overflow you will probably restart whole computation routine so that it is reasonable to do it this way IMHO. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Mar 6 19:16:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYTr-0003LY-00 for ; Tue, 11 Mar 2003 02:22:59 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:22:59 +0100 (CET) Received: (qmail 15243 invoked by uid 0); 6 Mar 2003 19:10:13 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 6 Mar 2003 19:10:13 -0000 Received: by moria.seul.org (Postfix) id D458E33CE6; Thu, 6 Mar 2003 14:10:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C775133CED; Thu, 6 Mar 2003 14:10:10 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 91B3C33CE6 for ; Thu, 6 Mar 2003 14:10:09 -0500 (EST) Received: from f-cpu.org (lcbv3-2-74.n.club-internet.fr [213.44.101.74]) by relay-2m.club-internet.fr (Postfix) with ESMTP id F33DE1DAC for ; Thu, 6 Mar 2003 20:10:06 +0100 (CET) Message-ID: <3E679068.1020407@f-cpu.org> Date: Thu, 06 Mar 2003 19:16:08 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SR [was:Re: [f-cpu] delayed issue] References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> <3E6621EC.6000109@f-cpu.org> <20030305235038.77ef104b.nicolas.boulay@ifrance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Wed, 05 Mar 2003 17:12:28 +0100 >Yann Guidon wrote: ><...> > > >>>Sur, but in one side you have 6 gates thin multiplier and in other >>>side you try to put a 3r2w register bank of 64 entries in the same >>>slot size... >>> >>don't worry .... >>the decoding logic (data ready, unit ready, etc.) will probably need >>some more pipe stages >>in "high-speed" versions (where the pipelines are correctly sliced). >>It's just a matter of splitting the stages correctly. >>Remember, the first FC0-OOOC had no jump latency and now it it one. >>If the register set is really slow, we can't do much better but it's >>not worth >>adding complex renaming buffers : the register's access time will not >>be faster. >>Enhancing (through longer pipeline) the decoder is a better solution. >> >Sur but then you will have jump penalty. > > c'est les vases communicants .... nothing is for free. either you pipeline the decoding logic, you increase the core frequency and the peak performance at the cost of more jump/branch latency, either you keep it simple and slow. Now compare this to the many more cycles of penalty for other architectures. >>>>>>Additionally, more complexity means more silicon area, >>>>>>more dissipation, longer wires => more heat/dissipation, >>>>>>more expensive and probably slower. >>>>>>And control logic is certainly the least easy thing >>>>>>to test in a chip. This is why i'm satisfied with >>>>>>the current FC0. >>>>>> >>>>>not me :) Not when you saw the 3r2w regifile because of 1 or 2 >>>>>instructions (like MAC). Not when you saw the mess of "special >>>>> >>>>> >>>register">>that should be memory mapped (with conditionnal memory >>>movemement like>>not buffered, if needed). Not when you see the >>>trap/expetion mess.>> >>> >>> >>>>1) 3R2W is necessary also for load and store instructions, otherwise >>>> >>>> >>>it's not possible to perform pointer update in the instruction.> >>> >>> >>>Sur but, it's not really a true speed up and add a raw dependancies. >>> >>?????? >> >>oh, and what about your 'code density' argument ? >>if you don't allow post-increment, then you need more instructions to >>compute the addresses. >> >Humm... i think about "true" 4r2w (on liw) but with 1r1w split register >bank. The first problem is the use of 3r2w reg bank but 90% of the >instruction are 2r1w. > > but not all instructions have the same latency ! so there are many cases where a "long" instruction will prevent short ones to complete. The 2nd write port is here to remove 90% of the compiler's pressure to detect when this situation occurs. >>>>2) If you map SRs to memory, you will face race conditions and >>>>synchronisation problems, >>>>and protection will not be enforced on a register or register group >>>>granularity basis. >>>> >>>It's exaclty the same problem for IO register, and it's soon solved. >>> >>SRs are not for I/O (because it would become a bottleneck). >>The problem, hence the solution, is not the same. >> >The problem is buffuring anf ordering. Like for IO registers memory >mapped. > > so if you want to buffer and order access to protection and configuration related resources, how much silicon resources are you wasting for the buffers and control logic ? unless you have already a complex OOOE core, it's not worth it. KISS. >>>There is no need for a specific buses, only the use of direct >>>addressing had an interrest. >>> >>??? >> >> >Use set/get is like a load/store using direct adressing. > > oh god .... >>>>3) what mess ? >>>> >>>The kind of linked-list that can't take nest interrupt that you speak >>>about regularly. (shadow register could be far more easy...) >>> >>??? >> > >SR was just for some constant reading, then you use it for system >control(like for trap handling). > SR was never meant "only" for "reading constants". > Each time some dust are on the design >pchout it send to SR, like a wide carpet. > > ???? >SR are slow because serialiased. > of course. these are critical resources that control the machine, and it's not expected to be used every 3 instructions. Now, if you wanted to make it "faster" then the core would become more complex and never finished. >SR can't be preserve by context switch >because it sill be a mess. So only read is premit. > > nope. A few registers are preserved through SRB and a "manual" IRQ routine can backup other things manually. >We could also put register trap pointer, TLB ... But register mapped >seems so easier (don't forget that SR are direct mapped). > > do you mean that you want to have a couple of register, one being index and the other data, only to access the SRs ? it's useless because there are 2 forms of GET and PUT instructions, one with a 16-bit index in the opcode and another where the index is stored in a register. Or there was a communication probkem. >nicO > >>>>>nicO >>>>> >>>>YG >>>> >>>nicO >>> >>YG again >> YG PS: time to write VHDL again. These sterile discussions annoy me... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 7 01:36:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYf8-0003LY-00 for ; Tue, 11 Mar 2003 02:34:38 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:34:38 +0100 (CET) Received: (qmail 16886 invoked by uid 0); 7 Mar 2003 01:30:30 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 7 Mar 2003 01:30:30 -0000 Received: by moria.seul.org (Postfix) id 2CF5633CB9; Thu, 6 Mar 2003 20:30:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 43DD033CBD; Thu, 6 Mar 2003 20:30:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id F2D5F33CB9 for ; Thu, 6 Mar 2003 20:30:25 -0500 (EST) Received: from f-cpu.org (lcbv1-1-10.n.club-internet.fr [213.44.3.10]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 3B1FC1690 for ; Fri, 7 Mar 2003 02:29:19 +0100 (CET) Message-ID: <3E67E989.4040306@f-cpu.org> Date: Fri, 07 Mar 2003 01:36:25 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SR [was:Re: [f-cpu] delayed issue] References: <20030305080728.0383B62D31@mallaury.noc.nerim.net><3E6621EC.6000109@f-cpu.org> <20030305235038.77ef104b.nicolas.boulay@ifrance.com> <009e01c2e3c3$70cdd260$8000a8c0@homeworld> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Christophe Avoinne wrote: >Just a precision, the ARM has a coprocessor interface : it can handle with >16 (or 15) coprocessors and has an small uniform set of instruction to help >to communicate between itself and a coprocessor. For example, the MMU >handling is done with the coprocessor number 15. It is a very good idea >because you can transfer ARM registers and CP15 registers to and fro, make >CP15 load or store address, etc. Whygee, if interested, just have a look on >S3C2410, ARM9 isa part and MMU part, where they explain how to handle MMU >coprocessor. That kind of interface could be very interesting for F-CPU to >add external coprocessor and have a more tighly coupled functions. > > > This idea has also been used by MIPS. Probably SPARC (but i don't remember). MIPS used this on the R2000 to communicate with the external FPU chip. They probably had to modify the ISA when the R4000 came with its integrated superscalar FP pipeline. If communication with a "coprocessor" is necessary, then i don't see why it can't go through the SRs. So a more complex "coprocessor interface" doesn't solve anything. On top of that, the ARM is an in-order CPU, i don't see how it could go OOOE and still still support the coproc interface at no cost. F-CPU's SRs imply serialisation so it's safe for the future. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 7 01:28:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYjK-0003LY-00 for ; Tue, 11 Mar 2003 02:38:58 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:38:58 +0100 (CET) Received: (qmail 13905 invoked by uid 0); 7 Mar 2003 09:08:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 7 Mar 2003 09:08:20 -0000 Received: by moria.seul.org (Postfix) id CF98533DD9; Fri, 7 Mar 2003 04:07:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E1F9433D99; Fri, 7 Mar 2003 04:06:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a217.home.uni-hannover.de [130.75.232.217]) by moria.seul.org (Postfix) with ESMTP id 7E43833D98 for ; Fri, 7 Mar 2003 04:05:37 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA01854; Fri, 7 Mar 2003 01:28:55 +0100 Message-ID: <20030307012855.50868@thrai.stud.uni-hannover.de> Date: Fri, 7 Mar 2003 01:28:55 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: SR [was:Re: [f-cpu] delayed issue] References: <20030305080728.0383B62D31@mallaury.noc.nerim.net> <3E6621EC.6000109@f-cpu.org> <20030305235038.77ef104b.nicolas.boulay@ifrance.com> <3E679068.1020407@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E679068.1020407@f-cpu.org>; from Yann Guidon on Thu, Mar 06, 2003 at 07:16:08PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Mar 06, 2003 at 07:16:08PM +0100, Yann Guidon wrote: [...] > PS: time to write VHDL again. Excellent idea :) Let's go... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Mar 6 22:55:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYiS-0003LY-00 for ; Tue, 11 Mar 2003 02:38:04 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:38:04 +0100 (CET) Received: (qmail 30782 invoked by uid 0); 7 Mar 2003 08:15:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 7 Mar 2003 08:15:31 -0000 Received: by moria.seul.org (Postfix) id A419533D96; Fri, 7 Mar 2003 03:15:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0BC7533D99; Fri, 7 Mar 2003 03:15:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B276933D96 for ; Fri, 7 Mar 2003 03:15:23 -0500 (EST) Received: from a50-137.dialup.iol.cz ([194.228.137.50] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18rD0g-00029t-00 for f-cpu@seul.org; Fri, 07 Mar 2003 09:15:19 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18r3Kh-0000gR-00 for f-cpu@seul.org; Thu, 06 Mar 2003 22:55:19 +0100 Date: Thu, 6 Mar 2003 22:55:19 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: SR [was:Re: [f-cpu] delayed issue] In-Reply-To: <3E679068.1020407@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >Humm... i think about "true" 4r2w (on liw) but with 1r1w split register > >bank. The first problem is the use of 3r2w reg bank but 90% of the > >instruction are 2r1w. > > > > > but not all instructions have the same latency ! > so there are many cases where a "long" instruction will prevent short > ones to complete. > The 2nd write port is here to remove 90% of the compiler's pressure to > detect when > this situation occurs. Just one small note. When I played with my simulator I found that adding 4 entry "delay" buffer at output of EUs it is possible to about 4/5 of all write contention related stalls. I onlu don't know whether is it possible to write scheduler in way it could handle it. But because you issue AT MOST one insn/cycle (assuming no stalls) then for 1w ops you should be always able to find free write cycle. When I think about it just now, one could simply write results to delay buffers if there is no free write cycle and introduce stall when one such buffer is almost full. But can't imagine complexity just now. good night, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 7 09:20:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sYjW-0003LY-00 for ; Tue, 11 Mar 2003 02:39:10 +0100 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 02:39:10 +0100 (CET) Received: (qmail 20544 invoked by uid 0); 7 Mar 2003 09:14:19 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 7 Mar 2003 09:14:19 -0000 Received: by moria.seul.org (Postfix) id BD9A633D93; Fri, 7 Mar 2003 04:14:17 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3D82933D99; Fri, 7 Mar 2003 04:14:15 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id AE49533D93 for ; Fri, 7 Mar 2003 04:14:12 -0500 (EST) Received: from f-cpu.org (lcbv4-2-187.n.club-internet.fr [213.44.93.187]) by relay-4v.club-internet.fr (Postfix) with ESMTP id C43D816C5 for ; Fri, 7 Mar 2003 10:14:09 +0100 (CET) Message-ID: <3E68563E.3070303@f-cpu.org> Date: Fri, 07 Mar 2003 09:20:14 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: SR [was:Re: [f-cpu] delayed issue] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>>Humm... i think about "true" 4r2w (on liw) but with 1r1w split register >>>bank. The first problem is the use of 3r2w reg bank but 90% of the >>>instruction are 2r1w. >>> >>but not all instructions have the same latency ! >>so there are many cases where a "long" instruction will prevent short >>ones to complete. >>The 2nd write port is here to remove 90% of the compiler's pressure to >>detect when >>this situation occurs. >> >> >Just one small note. When I played with my simulator I found >that adding 4 entry "delay" buffer at output of EUs it is >possible to about 4/5 of all write contention related stalls. > 4 entries for each of the 6 integer units ? that makes 24 register numbers to compare and more data wires to route ! This kind of buffers can increase frequency a bitby reducing the size of the register set, but adds at least one pipeline stage and more management logic. >I onlu don't know whether is it possible to write scheduler >in way it could handle it. >But because you issue AT MOST one insn/cycle (assuming no stalls) >then for 1w ops you should be always able to find free write >cycle. > That's the theory. In practice, F-CPU is meant to compensate the scalar design with instructions that are richer than classical RISC processors. These instructions become more used in critical loops for data-intensive programs (like video and sound), where performance matters most. The load with postincrement instruction requires 2 operands and gives 2 other data. If you schedule them well, you can issue 1 instruction per cycle continuously (provided there is no data hazard). If the register set has only 1 write port and a 4-deep write queue then the queue will exhaust if more than 4 consecutive loads are programmed. This happens a lot, for example when saving/restoring the register set manually ... >When I think about it just now, one could simply write results >to delay buffers if there is no free write cycle and introduce >stall when one such buffer is almost full. But can't imagine >complexity just now. > > the first major problem that arises is how to manage the consistency of the pipeline, how much logic is needed for the additional buffers, how many cycles it will add to the pipeline .... In a sense, it's almost the same problem as simple OOOE. In order to reduce the pipeline stages to the minimum that is necessary to perform the function, the pipeline doesn't have to spend any time wondering where data lies, instead of performing useful computations. It only has to check for possible exceptions, bypasses and stalls, and it already takes the first 2 cycles in the pipeline (maybe the most complex part of the design). Adding something else would make development impossible for our small team. In fact the register set problem is more related to technology than architecture. The solution is something like splitting the set in sub-banks or 'strides' as with other memory technologies (caches, DRAM etc.). But it depends a lot on the available technology and the fundry ... Of course several solutions could be tested (like 8 banks of 8 registers, or 4 banks of 16 registers) but the best solution will vary with the silicon properties, number of metal layers etc ..... Now we seem to speak only about the 2 write ports. But the 3 read ports also have a role, for example for the store with post increment (we need the pointer, the modifier and the data) and for SRB (the 3rd port is used to "spy" data on the Xbar for the backup). On top of that, several people seem "shocked" about the unbalanced latencies between the "normal units" with 6 gates of CDP and the Register set. But the Xbar (the central bus that routes data to/from units and the register set) is also going to be slow. The good side is that these slow parts can be pipelined with little impact on the scheduling. Adding buffers would be a cure that would be worse than the problem. Now, a lot of people are seeming to discover or rediscover or rediscuss old stuff. What i would like is simply : source code .... have fun, >good night, >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me464863@members.interq.or.jp Sat Mar 8 06:50:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18sZAZ-0003LY-00 for ; Tue, 11 Mar 2003 03:07:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Mar 2003 03:07:07 +0100 (CET) Received: (qmail 17669 invoked by uid 0); 8 Mar 2003 05:50:53 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 8 Mar 2003 05:50:53 -0000 Received: by moria.seul.org (Postfix) id 8488733C9F; Sat, 8 Mar 2003 00:50:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DEE6333D95; Sat, 8 Mar 2003 00:50:51 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from banna (pl1013.nas928.o-tokyo.nttpc.ne.jp [61.197.75.245]) by moria.seul.org (Postfix) with ESMTP id 4B33233C9F for ; Sat, 8 Mar 2003 00:50:38 -0500 (EST) Received: from C ([192.168.0.3]) by banna (8.9.3+3.2W/3.7W) with SMTP id OAA00432; Sat, 8 Mar 2003 14:53:30 +0900 Message-Id: <200303080553.OAA00432@banna> From: =?iso-2022-jp?B?bWU0NjQ4NjM=?= To: =?iso-2022-jp?B?MDMzMjA=?=@banna.seul.org Date: Sat, 08 Mar 2003 14:50:12 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoJTAlQyVJJUslZSE8JTkhSkJnP001JD4mSUohSxsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> V“dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463440@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢ ¦Ä”zM‹‘”Û‚©‚ç‚P“ú‘OŒã‚Ń[ƒ‹ƒAƒhƒŒƒX‚ð휒v‚µ‚Ü‚· §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218@@ ™\\\™\\\™\\\™\\\™\\\™\\\™ ‚±‚̃[ƒ‹‚ðŽó‚¯Žæ‚ç‚ꂽ•ûA1’ʂɂ‚«100‰~·‚µã‚°‚Ü‚·B 5000‰~•ª’™‚Ü‚è‚Ü‚µ‚½‚犷‹à’v‚µ‚Ü‚·‚Ì‚Å‚²¿‹‰º‚³‚¢B @@š@ƒoƒi[‚ð‚Í‚Á‚ĉº‚³‚é•û•åW‚µ‚Ü‚·I@š ”„‚èã‚°‚Ì10“‚ði’悵‚Ü‚·B Å’á•Ûá‚Æ‚µ‚ÄŒŽŠz10–œ‰~AŒŽ‚É50–œ‰~‚ÍŠmŽÀ‚Å‚·B ™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu ‚`‚u’j—D•åWE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/ ™\\\™\\\™\\\™\\\™\\\™\\\™ ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽE–h”ƃOƒbƒYE‹à–ׂ¯î•ñ‚È‚Ç@ @@@š@‚»‚Ì‘¼î•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://220.98.0.75/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From master@89894.com Sat Feb 15 21:50:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18t9wL-0000H1-01 for ; Wed, 12 Mar 2003 18:22:53 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 12 Mar 2003 18:22:53 +0100 (CET) Received: (qmail 29098 invoked by uid 0); 12 Mar 2003 08:36:01 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 12 Mar 2003 08:36:01 -0000 Received: by moria.seul.org (Postfix) id 6C9EC33B55; Wed, 12 Mar 2003 03:35:59 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7AE5433DC2; Wed, 12 Mar 2003 03:35:58 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 89894.com (unknown [218.147.125.173]) by moria.seul.org (Postfix) with SMTP id 8815E33B55 for ; Wed, 12 Mar 2003 03:35:53 -0500 (EST) Message-ID: <298570-220032615205041375@89894.com> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 From: "½Å¿ë ö" To: f-cpu@seul.org Subject: [f-cpu] (±¤°í)¾Æ´Ï! ÀÌ ¹«½¼ ³¿»õ......???@ Date: Sun, 16 Feb 2003 05:50:41 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF= =A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD= =C3=B8=E9 = =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4

 

(=B1=A4=B0=ED)=BE=C6=B4=CF!  =C0=CC =B9=AB=BD=BC=20 =B3=BF=BB=F5=2E=2E=2E=2E=2E=2E???@

 

=

=B9=E6=C7=E2=C1=A6=20 =B6=A7=B9=AE=BF=A1 =B8=D3=B8=AE=B0=A1 =BE=C6=C7=C1=BD=C3=C1=D2=2E=2E=2E!  =20 =C0=CC=B7=B8=B0=D4 =C7=CF=BD=C3=B8=E9 =B5=CB=B4=CF=B4=D9=2E<= /SPAN>

 

=B8= =F0=B5=E7=20 =B3=BF=BB=F5 =BE=C7=C3=EB=C1=A6=B0=C5 =C0=FC=B9=AE=2E=2E= =2E=2E=2E=2E

=C3=B5=BF=AC=BF=F8=B7=E1=20 =C1=A6=C7=B0=C0=B8=B7=CE =C0=CE=C3=BC =C0=FC=BF=AC =B9=AB=C7=D8=C7=CF=B0=ED= =C0=DA=BF=AC =C4=A3=C8=AD=C0=FB=C0=CE =C1=A6=C7=B0=C0=B8=B7=CE =B5=CE=C5=EB= =C0=BB =C0=AF=B9=DF=C7=CF=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E=2E

=B4=E3=B9=E8=B3=BF=BB=F5, =C0=BD=BD=C4=B3=BF=BB= =F5, =B0=F5=C6=CE=C0=CC=B3=BF=BB=F5, =B0=F5=C6=CE=C0=CC=BC=BC=B1=D5, =B9=AB= =C1=BB=B1=D5, =B9=DF=B3=BF=BB=F5, =C0=CE=C3=BC=B3=BF=BC=BC, =B5=C8=C0=E5=B1=B9=B3=BF=BB=F5= , =C3=BB=B1=B9=C0=E5=B3=BF=BB=F5,=20 =C0=CE=C5=D7=B8=AE=BE=EE =B3=BB=C0=E5=C0=E7 =B3=BF=BB=F5,

=C7=CF=BC=F6=B1=B8=B3=BF=BB=F5, =B0=A2=C1=BE =C4= =FB=C4=FB=C7=D1 =B3=BF=BB=F5, =BD=C2=BF=EB=C2=F7=BE=C8=C0=C7 =B3=BF=BB=F5,= =B0=A1=C3=E0=B3=BF=BB=F5, =B0=A1=C3=E0 =BA=D0=B4=A2=B3=BF=BB=F5, =C8=AD=C0= =E5=BD=C7=B3=BF=BB=F5, =BE=B2=B7=B9=B1=E2=B3=BF=BB=F5,=20 =BE=B2=B7=B9=B1=E2=C0=E5 =BE=C7=C3=EB,=

=C1=A4=C8=AD=C1=B6 =B3=BF=BB=F5, =BA=B4=BF=F8 = =C0=D4=BF=F8=BD=C7=B3=BF=BB=F5, =C1=F6=C7=CF=BD=C7 =C4=FB=C4=FB=C7=D1=20 =B3=BF=BB=F5,

=C0=CC =B8=F0=B5=E7 =B3=BF=BB=F5=BF=CD =BE=C7=C3=EB=B8=A6 =B1=D9=BF= =F8=C0=FB=C0=B8=B7=CE =BA=D0=C7=D8 =C1=A6=B0=C5=C7=CF=B8=E7 =B0=A2=C1=BE =BC= =BC=B1=D5=C0=BB =BB=EC=B1=D5=C3=B3=B8=AE=C7=D5=B4=CF=B4=D9=2E=2E=2E=2E

 

 

www=2E89894=2Ecom  =BF=A1=BC=AD

 

=B3=BF=BB=F5=BF=F8=C0=BB =C1=A6=B0=C5=C7=D1=B5=DA =C0=DA=BF=AC=C7= =E2=C0=BB =C0=BA=C0=BA=C7=CF=B0=D4 =C7=B3=B1=E2=BE=EE =C1=DD=B4=CF=B4=D9=2E=2E=2E=2E=2E

 

 

%%%  =20 =C3=DF=BB=E7   %%%

 

=C1=A6=C7=B0=C0=BB=20 =B1=B8=C0=D4=C7=CF=BD=C5=BA=D0=BF=A1 =C7=D1=C7=D8=BC=AD cafe=2Edaum=2Enet/106030 =B9=AB=C7=D1=B5=BF=B7=C2 =C4=AB=C6=E4=BF=A1 =C4=AB=C5=D7=B0=ED=B8=AE =C8=B8=BF=F8 =B5=EE=B7=CF=B6=F5=C0=BB =C5=AC=B8=AF= =C7=CF=B0=ED =B5=E9=BE=EE=B0=A1=BC=AD=20 =B1=DB=C0=BB=B3=B2=B0=DC=B3=F5=C0=B8=BD=C3=B8=E9 =B9=AB=C7=D1=B5=BF=B7=C2 = =B0=B3=B9=DF=C0=BB(=B3=E2=B8=BB=BE=C8=BF=A1 =BF=CF=B7=E1=BF=B9=C1=A4) =BF=CF= =B7=E1=C8=C4 =C3=A2=BE=F7 =C1=D6=C1=D6=B0=A1=B5=C7=BD=C7=BC=F6=C0=D6=B4=C2 =BF=EC=BC=B1=B1=C7 =B9=D7= =C0=DA=B0=DD=C0=CC=20 =C1=D6=BE=EE=C1=FD=B4=CF=B4=D9=2E=2E=2E

 

  ^^**^^    ^^**^^   =20 ^^**^^

 

=BC=EE=C7=CE=B8=F4     :=20=0D www=2E89894=2Ecom

=C0=FC  =20 =C8=AD     :=20 031-394-0045   hp :=20 011-281-1434   =BD=C5  =BF=EB =20 =C3=B6

=B9=AB=C7=D1 =B5=BF=B7=C2 :=20 cafe=2Edaum=2Enet/106030

 

=B0=A8=BB=E7 =C7=D5=B4=CF=B4=D9=2E=2E=2E=2E=2E

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From zwb231@yahoo.com.cn Thu Mar 13 07:11:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18tQiE-0000Gs-00 for ; Thu, 13 Mar 2003 12:17:26 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 13 Mar 2003 12:17:26 +0100 (CET) Received: (qmail 27514 invoked by uid 0); 13 Mar 2003 06:11:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 13 Mar 2003 06:11:40 -0000 Received: by moria.seul.org (Postfix) id 57E7333C10; Thu, 13 Mar 2003 01:11:38 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD6D933C76; Thu, 13 Mar 2003 01:11:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from houshen-rqfcvxa (unknown [218.5.64.61]) by moria.seul.org (Postfix) with SMTP id 1D05233C10 for ; Thu, 13 Mar 2003 01:11:35 -0500 (EST) From: zwb231 To: f-cpu@seul.org Subject: [f-cpu] ÓÅÖÊÖ÷»ú+24Сʱ·þÎñ! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030313061135.1D05233C10@moria.seul.org> Date: Thu, 13 Mar 2003 01:11:35 -0500 (EST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ×ð¾´µÄÐÂÀÏÓû§£º ÄúºÃ£¬Ê×ÏȸÐлÄú¶ÔÎÒÃǵĹØ×¢£¬Í¬Ê±Ò²¶ÔðÃÁ´òÈűíʾǸÒ⣡ ¡¡¡¡ÎªÁ˸üºÃµÄ·þÎñÓÚ¹ã´óÐÂÀÏ¿Í»§£¬ÎÒ˾ÌضÔËùÍƳöµÄÐéÄâÖ÷»úÀàÐͽøÐе÷Õû! »¶Ó­µã»÷£ºhttp://www.88dns.com Á˽âÎÒ˾×îж¯Ì¬£¡ 1¡¢200M£¨´¿HTML¿Õ¼ä£©+ ËÍÒ»¹ú¼ÊÓòÃû£¬½öÊÛ150Ôª/Äê 2¡¢50M¿Õ¼ä+50MÆóÒµÓÊ¾Ö + Ö§³ÖASP£¬CGI + ËÍÒ»¹ú¼ÊÓòÃû£¬½öÊÛ248Ôª/Äê 3¡¢100MP¿Õ¼ä+100MÆóÒµÓÊ¾Ö + Ö§³ÖASP£¬CGI£¬ACCESS + ËÍÒ»¹ú¼ÊÓòÃû£¬½öÊÛ280Ôª/Äê 4¡¢200MP¿Õ¼ä+200MÆóÒµÓÊ¾Ö + Ö§³ÖASP£¬CGI£¬ACCESS + ËÍÒ»¹ú¼ÊÓòÃû£¬½öÊÛ330Ôª/Äê ¸ü¶à¿Õ¼ä×éºÏ£¬¸ü¶àÑ¡Ôñ--Çëµã»÷ÎÒ˾ÍøÕ¾ ¡¡http://www.88dns.com/¡¡Á˽âÏêÇé. ¡°¸ßËÙ¡¢Îȶ¨¡¢°²È«¡¢24СʱרҵÊÛºó·þÎñ¡±ÊÇÈ«ÌåӯͨÈ˵ķþÎñ×ÚÖ¼£¬ÎÒÃÇÖ£ÖسÐŵ£º 1¡¢Ó¯Í¨Ö÷»úÈ«²¿²ÉÓÃ×îÐÂÔ­×°Dell PowerApp»¥ÁªÍøÓ¦Ó÷þÎñÆ÷£» 2¡¢¹âÏËÖ±½Ó½ÓÈ룬Ö÷»ú¶ÀÏí 100M ´ø¿í£¬Í¬Ê±ÍйÜÓÚÍøͨÓëµçÐÅ£» 2¡¢Ó¯Í¨Ö÷»úÈ«²¿°²×°Õý°æTurbolinux»òMicrosoft²Ù×÷ϵͳ£» 3¡¢²ÉÓÃÊÀ½ç±ê×¼µÄSNMP½øÐÐ24x7x365 ϵͳ¼à²â£» 4¡¢Ó¯Í¨Ö÷»ú¿Í»§Ò»¸öÔÂÄÚ¿ÉÎÞÌõ¼þÈ«¶îÍ˿ÆäËü°´Êµ¼ÊÓà¶îÍË¿î¡£ ÁªÏµE-mail:¡¡zwb@xmcnc.net ¡¡QQ£º40327558¡¡ µç»°£º0592-5557492¡¡/ 8667174 ´«Õ棺 0592--5580200 Ö£ÏÈÉúÁªÏµ *****´ËÓʼþΪÉÌÒµÐź¯£¬Èç¹û¸øÄãÔì³É²»±ãÇëÔ­Á£¬Èç¹ûÄ㲻ϣÍûÔÙÊÕµ½´ËÐź¯Çëµ½:hou@logindns.com Í˶©£¬ÎÒÃǽ«»á°ÑÄúµÄÓÊÏäµØÖ·¹ýÂ˳öÁÐ±í¡£Ð»Ð»£¡ This mail is a business letter .If you are uninterested in this ,please delete it ;If you do not hope to receive this mail again ,please go to hou@logindns.com ,fill ni your mail address ,and we will filter it out of our mail list! Thank your! ********************************************** ¡¡ ¡¡¡¡¡¡¡¡×£ÄúÑòÄ꼪Ïé¡¢ºÃÔËÌìÌìÓС¢ÐÒÔ˳£°éËæ!!! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ó¯Í¨ÍøÂç --------------------------------------------------------------- ·ÐµãȺ·¢Óʼþ,À´×ÔÈí¼þ¹¤³Ìר¼ÒÍø(http://www.21cmm.com) ½øCMMÍøУ(http://www.21cmm.com)£¬³ÉÏîÄ¿¹ÜÀíר¼Ò ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me464863@members.interq.or.jp Thu Mar 13 13:49:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18tbqg-0000bg-01 for ; Fri, 14 Mar 2003 00:10:54 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 14 Mar 2003 00:10:54 +0100 (CET) Received: (qmail 25749 invoked by uid 0); 13 Mar 2003 12:49:00 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 13 Mar 2003 12:49:00 -0000 Received: by moria.seul.org (Postfix) id 9625533BD7; Thu, 13 Mar 2003 07:48:54 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 23F0733C19; Thu, 13 Mar 2003 07:48:54 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from banna (pl1013.nas928.o-tokyo.nttpc.ne.jp [61.197.75.245]) by moria.seul.org (Postfix) with ESMTP id F08CD33BD7 for ; Thu, 13 Mar 2003 07:48:51 -0500 (EST) Received: from C ([192.168.0.3]) by banna (8.9.3+3.2W/3.7W) with SMTP id VAA00507; Thu, 13 Mar 2003 21:52:08 +0900 Message-Id: <200303131252.VAA00507@banna> From: =?iso-2022-jp?B?bWU0NjQ4NjM=?= To: =?iso-2022-jp?B?MDMzMjA=?=@banna.seul.org Date: Thu, 13 Mar 2003 21:49:10 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRkMlQCVNPnBKcxsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> ‚³‚í‚â‚©LŽÐ ¡ŒãAL‚ð‚²Šó–]‚³‚ê‚È‚¢•û‚Í‚±‚±‚Ö me463440@members.interq.or.jp •K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢ ¦Ä”zM‹‘”Û‚©‚ç‚P“ú‘OŒã‚Ń[ƒ‹ƒAƒhƒŒƒX‚ð휒v‚µ‚Ü‚· §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218@@ ™\\\™\\\™\\\™\\\™\\\™\\\™ ‚±‚̃[ƒ‹‚ðŽó‚¯Žæ‚ç‚ꂽ•ûA1’ʂɂ‚«100‰~·‚µã‚°‚Ü‚·B 5000‰~•ª’™‚Ü‚è‚Ü‚µ‚½‚犷‹à’v‚µ‚Ü‚·‚Ì‚Å‚²¿‹‰º‚³‚¢B @@š@ƒoƒi[‚ð‚Í‚Á‚ĉº‚³‚é•û•åW‚µ‚Ü‚·I@š ”„‚èã‚°‚Ì10“‚ði’悵‚Ü‚·B Å’á•Ûá‚Æ‚µ‚ÄŒŽŠz10–œ‰~AŒŽ‚É50–œ‰~‚ÍŠmŽÀ‚Å‚·B ™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu ‚`‚u’j—D•åWE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://61.207.159.162/ ™\\\™\\\™\\\™\\\™\\\™\\\™ ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽE–h”ƃOƒbƒYE‹à–ׂ¯î•ñ‚È‚Ç@ @@@š@‚»‚Ì‘¼î•ñ–žÚ@š ‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ ‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://61.207.159.162/index2.html ™\\\™\\\™\\\™\\\™\\\™\\\™ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From me464863@members.interq.or.jp Sat Mar 15 12:26:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18uLJz-0004JP-00 for ; Sun, 16 Mar 2003 00:44:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 16 Mar 2003 00:44:11 +0100 (CET) Received: (qmail 29907 invoked by uid 0); 15 Mar 2003 11:27:49 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 15 Mar 2003 11:27:49 -0000 Received: by moria.seul.org (Postfix) id 93EC633CD4; Sat, 15 Mar 2003 06:27:47 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DDC9C33CD7; Sat, 15 Mar 2003 06:27:46 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from banna (pl1013.nas928.o-tokyo.nttpc.ne.jp [61.197.75.245]) by moria.seul.org (Postfix) with ESMTP id A7BD933CD4 for ; Sat, 15 Mar 2003 06:27:30 -0500 (EST) Received: from C ([192.168.0.3]) by banna (8.9.3+3.2W/3.7W) with SMTP id UAA21361; Sat, 15 Mar 2003 20:29:29 +0900 Message-Id: <200303151129.UAA21361@banna> From: =?iso-2022-jp?B?bWU0NjQ4NjM=?= To: =?iso-2022-jp?B?MDMzMjA=?=@banna.seul.org Date: Sat, 15 Mar 2003 20:26:34 +0900 Subject: [f-cpu] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoNls1XiROJCpDTiRpJDsbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ‰c‹ÆL‚Å‚Í‚ ‚è‚Ü‚¹‚ñ §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F TEL:03-3544-6222 FAX:03-3544-6218 ‰º‹L‚̂悤‚È‚à‚̂ͼ‹\ƒ[ƒ‹‚È‚Ì‚ÅA‚²’ˆÓ‚­‚¾‚³‚¢B ”íŠQ‚É‘˜‚í‚ꂽ•û‚ÍÅŠñ‚ÌŒxŽ@‚É”íŠQ“Í‚¯‚ðo‚µ‚Ä‚­‚¾‚³‚¢B ‚±‚̼‹\‚Í–³·•Ê‚É‘—‚ç‚ê‚Ä—ˆ‚é‚à‚Ì‚Å‚·B“à—e‚â‹âsŒûÀ‚à •Ï‚¦‚Ä‘—M‚³‚ê‚Ä‚Ü‚·‚ªAÂŒ ¼‹\‚Å‚·B ‚±‚Ì“d˜b‚Æ‚e‚`‚w‚Í“–ŽÐ‚Ì‚à‚Ì‚Å‚·‚ªAŸŽè‚ÉŽg‚í‚ê‚Ä‚¢‚é‚à‚Ì‚ÅA “–ŽÐ‚Æ‚Í‚Ü‚Á‚½‚­ŠÖŒW‚ ‚è‚Ü‚¹‚ñB ‚±‚ÌŒg‘єԆ‚Íu090-1281-3920ATU-KA“ŒŠCFˆ¤’m/Šò•Œ/ŽOd/ɪv”Æl‚Ì‚à‚Ì‚ÆŽv‚í‚ê‚Ü‚·B šššššššššššššššššššššššššššššššššššššššššš –{•¶¼‹\“à—eF yŒä¿‹’Ê’mz s‘厊‹}Œä˜A—’v‚µ‚Ü‚·t ‚±‚Ì“x‚͉ߋŽ‚É ‚ ‚È‚½—l‚ªŽg—p‚³‚ꂽ“d˜b‰ñü‚©‚çÚ‘±‚³‚ꂽ ƒAƒ_ƒ‹ƒgƒTƒCƒg—˜—p—¿‹à‚ɂ‚¢‚Ä ‰^‰c‹ÆŽÒ‚æ‚è–¢”[—˜—p—¿‹à‚ÉŠÖ‚·‚éÂŒ ÷“n‚ðŽó‚¯ Ž„‹¤‚ª–¢”[—˜—p—¿‹à‚̉ñŽûì‹Æ‚ð ‘ãs‚³‚¹‚Ä’¸‚­Ž–‚É‚È‚è‚Ü‚µ‚½‚Ì‚ÅŒä˜A—‚³‚¹‚Ä’¸‚«‚Ü‚·B Œ»Ý‚͉º‹L‚É‹LÚ‚Ì—˜—p—¿‹à‚ª–¢”[‚Æ‚È‚Á‚Ä‚Ü‚·‚Ì‚Å ’x‰„‘¹ŠQ‹à‚¨‚æ‚щñŽû‘ãsŽè”—¿‚àŠÜ‚ß‚Ä ‚QŒŽ‚Q‚U“úi…jŒßŒã‚RŽž‚Ü‚Å‚ÌU‚èž‚Ý‚ð ŒäŽx•¥‚¢ŠúŒÀ‚Æ‚µ‚ĉº‹L‚É‹LÚ‚ÌŽw’èŒûÀ‚Ü‚Å Œä“ü‹à‚µ‚Ä’¸‚­‚悤ŒäŠè‚¢\‚µã‚°‚Ü‚·B ‡Œv‚¨Žx•¥‚¢‹àŠzF‚Q‚O‚R‚P‚O‰~ @@@@‰^‰c‹ÆŽÒFƒsƒ“ƒN‚m‚d‚s @@–¢”[—˜—p—¿‹àF‚P‚Q‚T‚O‚O‰~ @@@’x‰„‘¹ŠQ‹àF@‚R‚P‚Q‚O‰~ @‰ñŽû‘ãsŽè”—¿F@‚S‚U‚X‚O‰~ yUžæŒûÀz ======================= @ œŠe‹âs‚ðŒä—˜—p‚·‚éê‡@@@@@ @@@‚Ý‚¸‚Ù‹âsFVh¼ŒûŽx“X @@@@ŒûÀ”Ô†F•j‚S‚R‚R‚R‚O‚S‚V @@@@ŒûÀ–¼‹`FƒVƒ~ƒY ƒCƒ`ƒƒE @ œ—X•Ö‹Ç‚ðŒä—˜—p‚·‚éê‡ @@@@’Ê’ ‹L†F‚P‚O‚P‚V‚O @@@@’Ê’ ”Ô†F‚V‚P‚Q‚W‚S‚R‚T‚P @@@@’Ê’ –¼‹`FƒVƒ~ƒY ƒCƒ`ƒƒE ===================================== U‚èž‚Ý‚ÌÛ‚É‚Í•K‚¸‰ñŽû®—”Ô†‚ð –¼‘O‚Ì‘O‚ÉŒä“ü—Í‚µ‚ĉº‚³‚¢B ‘¬‚â‚©‚ÉŒä“ü‹à‚µ‚Ä’¸‚¯‚È‚¢ê‡‚Í Še’nˆæ‚ÌÂŒ ŠÖ˜A‹ÆŽÒ‚¨‚æ‚ÑŠÖ˜AŽ––±Š‚Ö “o˜^î•ñ‚¨‚æ‚ÑŒÂlî•ñ‚ðŽó‚¯“n‚·‚Ì‚Å ÅI“I‚ÉW‹àê–å’S“–ˆõ‚ðŒäŽ©‘î‚È‚Ç‚É –K–â‚ð‚³‚¹‚Ä’¸‚«‚Ü‚·B ‚»‚ÌÛ‚É‚Íã‹L‚̇ŒvŽx•¥Šz‚É Œð’Ê”ï‚ÆlŒ”ï‚ð‰ÁŽZ‚µ‚Ä –ñ‚P‚O”{‚Ì¿‹‚³‚¹‚Ä’¸‚­ê‡‚ªŒäÀ‚¢‚Ü‚·‚Ì‚Å ‚¨–Y‚ê‚È‚­•K‚¸Œä“ü‹à‚µ‚ĉº‚³‚¢B xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx @@@@@ iŠ”jˆ®‘‹Æ^‘ã•\F´… ˆê˜Y @@@ÂŒ î•ñŠÇ—ƒVƒXƒeƒ€•” @@@‚s‚d‚kF03-3544-6222 @@@‚e‚`‚wF03-3544-6218 @@@@Œg‘ÑF090-1281-3920 @@@@’S“–F’†‘º ‰pr@ ¼‹\‚Ì“à—eA’S“–ŽÒ‚Ì–¼‘O‚Í•Ï‚¦‚Ä‘—M‚µ‚Ä‚¢‚Ü‚·B ‚­‚ê‚®‚ê‚à‚±‚ÌŽè‚̼‹\‚É‚²’ˆÓ‰º‚³‚¢B ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Mar 17 18:42:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18v3Fp-0002wS-00 for ; Mon, 17 Mar 2003 23:38:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 17 Mar 2003 23:38:49 +0100 (CET) Received: (qmail 2363 invoked by uid 0); 17 Mar 2003 17:43:26 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 17 Mar 2003 17:43:26 -0000 Received: by moria.seul.org (Postfix) id DE3DF33B8B; Mon, 17 Mar 2003 12:43:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D98D433C6E; Mon, 17 Mar 2003 12:43:19 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id EAB2033B8B for ; Mon, 17 Mar 2003 12:43:15 -0500 (EST) Received: from a7-137.dialup.iol.cz ([194.228.137.7] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18uydZ-0000ZF-00 for f-cpu@seul.org; Mon, 17 Mar 2003 18:43:02 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18uyck-0001YD-00 for f-cpu@seul.org; Mon, 17 Mar 2003 18:42:10 +0100 Date: Mon, 17 Mar 2003 18:42:10 +0100 (CET) From: devik X-X-Sender: To: Subject: [f-cpu] Register set revised Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, sorry for opening this again. While working on other project we discovered other possibilty of register set. First, it would assume 2r2w set. I know some don't like it but I think too that 3r is unnecessary (MAC with 4 cycle latency is questionable for pipelning, store with postincrement usually works with immediates only, MUX is rarely used and simple to do with andn). I modified GCC to handle split set of two 1r1w register sets. Each binary op can use one operand from set A and one from B. Pointers are only in B. Calling convention places pointers to B and others to A. I've done it in testing mode for binary ops and stores and it seems that 70% of ops are ok. When we will spend more time on it I believe that we can reach about 90%. Mis-placed read will have 1 cycle penalty needed for second read. Writes can be to any bank - compiler should attempt to store results so that banks are interleaved (whenever possible for commutative ops). One could also disable cross-split reads and change 6 bit read register id to 5 bit (writes are still 6bit). Such split set would be both simpler and faster. And because of many comutative ops ("add" is most used) it can be expected no big penalty will occur. Just idea .... ------------------------------- Martin Devera aka devik http://luxik.cdi.cz/~devik/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 18 01:53:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZJ5-0000GT-01 for ; Wed, 19 Mar 2003 09:52:19 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:52:19 +0100 (CET) Received: (qmail 12403 invoked by uid 0); 18 Mar 2003 00:52:40 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 18 Mar 2003 00:52:40 -0000 Received: by moria.seul.org (Postfix) id B915B33D9C; Mon, 17 Mar 2003 19:52:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 34F0433DA1; Mon, 17 Mar 2003 19:52:37 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 480F433D9C for ; Mon, 17 Mar 2003 19:52:36 -0500 (EST) Received: from f-cpu.org (lcbv1-1-12.n.club-internet.fr [213.44.3.12]) by relay-4m.club-internet.fr (Postfix) with ESMTP id 082A6E332 for ; Tue, 18 Mar 2003 01:52:34 +0100 (CET) Message-ID: <3E766E23.9020902@f-cpu.org> Date: Tue, 18 Mar 2003 01:53:55 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >Hi, > >sorry for opening this again. While working on other >project we discovered other possibilty of register set. >First, it would assume 2r2w set. I know some don't >like it but I think too that 3r is unnecessary >(MAC with 4 cycle latency is questionable for pipelning, > store with postincrement usually works with immediates > only, MUX is rarely used and simple to do with andn). > >I modified GCC to handle split set of two 1r1w >register sets. > why not two 2r1w ? >Each binary op can use one operand >from set A and one from B. >Pointers are only in B. Calling convention places >pointers to B and others to A. > that's quite restrictive. the goal of "RISC" computer is to reduce the coding rules and ease both SW and HW. By restricting pointers to certain locations, coding SW is more complex and less flexible for example. >I've done it in testing mode for binary ops and >stores and it seems that 70% of ops are ok. > the remaining 30% are what hurts most when you need them. If this increases code size by 10% it's already a hit. A more complex register set could give better results and still avoid the problems of its size. >When we will spend more time on it I believe that >we can reach about 90%. > i hope that a 4-bank 2r1w register set can give better results. 90% efficiency is not enough. Don't forget that FC0 is a scalar CPU and increase of code size has a direct impact on performance. This is why the instruction set is so rich now. >Mis-placed read will have 1 cycle penalty needed >for second read. Writes can be to any bank - compiler >should attempt to store results so that banks >are interleaved (whenever possible for commutative ops). >One could also disable cross-split reads and change >6 bit read register id to 5 bit (writes are still 6bit). > >Such split set would be both simpler and faster. And >because of many comutative ops ("add" is most used) >it can be expected no big penalty will occur. > > but it breaks a lot of expected behaviours. For example, the register allocator has much more pressure. The unified register set is an important feature from the SW point of view, even though it can be implemented in more or less smart ways ... >Just idea .... > >------------------------------- > Martin Devera aka devik > http://luxik.cdi.cz/~devik/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Mar 18 08:31:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZJR-0000GT-00 for ; Wed, 19 Mar 2003 09:52:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:52:41 +0100 (CET) Received: (qmail 18772 invoked by uid 0); 18 Mar 2003 07:33:31 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 18 Mar 2003 07:33:31 -0000 Received: by moria.seul.org (Postfix) id 7A7C933DC7; Tue, 18 Mar 2003 02:33:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 238BE33DCA; Tue, 18 Mar 2003 02:33:29 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id A31F433DC7 for ; Tue, 18 Mar 2003 02:33:27 -0500 (EST) Received: from a110-137.dialup.iol.cz ([194.228.137.110] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18vBac-00049N-00 for f-cpu@seul.org; Tue, 18 Mar 2003 08:32:51 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18vBZK-0000CW-00 for f-cpu@seul.org; Tue, 18 Mar 2003 08:31:30 +0100 Date: Tue, 18 Mar 2003 08:31:30 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Register set revised In-Reply-To: <3E766E23.9020902@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >I modified GCC to handle split set of two 1r1w > >register sets. > > > why not two 2r1w ? Humm .. it's much more complex to simulate write port contention on gcc level. Restricting ops to 2 separated bank was simple. And my reason for whole experiment was effeciency. I have several uses for fcpu (I'll have to downgrade it to 32 bits probably) which I'd like to instantiate in lower end FPGA (Xilinx Spartan). When I have budget of say 5,000 LCs and each 16bits of 1r1w will use one LC I have 512 LC for 2r1w regset (even partitioned) with 64x64 bits. But only half (256) LCs for two 1r1w (32x64). 256LCs can be used to implement pipelined adder then. But I agree that full 2r will be always at least a few percent faster (no moves in function prologs). But this is the only place (prologs) where compiler is not able to satisfy constraints exactly (!). This and another one (I forgot): when value is user more times and is needed in both halves of split. > By restricting pointers to certain locations, > coding SW is more complex and less flexible > for example. are you sure ? In some weird way by restricting registers you add orthogonality ;) because there is less ways to do a single thing. And for compiler is it simpler to cope with a few "pointer" registers at fixed place than to check for usage of up to 8 pointers within 64 registers (as needed by regno-cacheline mapping if the proposal is still alive) ! We will still have to say GCC which registers are usable as pointers (say 28..35) because there is no other way to assure that compiler will not alocate more than 8 pointers. If one would at least mandate that pointers must be allocated from end of register set backward for example it could simplify that mapping, am I right ? > >I've done it in testing mode for binary ops and > >stores and it seems that 70% of ops are ok. > > > the remaining 30% are what hurts most when you need them. > If this increases code size by 10% it's already a hit. > A more complex register set could give better results > and still avoid the problems of its size. you are right. well is seems that for smaller regsets (2r2w) one can use partitioned 2r1w or use 2x1r1w with penalty for two single-bank read to be used in embeded designs. We can at least hint gcc to try to allocate registers from oposite banks whenever it is possible without any other insn generation (yet gcc can do it). It will not hurt full 2r design and will help 1r implementations. > >When we will spend more time on it I believe that > >we can reach about 90%. > > > i hope that a 4-bank 2r1w register set can give better results. > 90% efficiency is not enough. Don't forget that FC0 > is a scalar CPU and increase of code size has a direct impact > on performance. This is why the instruction set is so rich now. By the way are you still convinced of the 3rd readport usefullness ? 2w are definitely ok for oooc but even from many compiled code which I've seen I saw 3r insn exacly one time in loop like: while(p->valid) { p+=off; ...use p here... } which did lead into postincrement by register with "off". I also saw mac a few times. MMX like pmadd might be better because it is 2r1w and imposes no RAW interdependency between subsequent ones. But yes it might be seen as "different" because changes chunk size on the fly. On other side it supports widening multiply. > but it breaks a lot of expected behaviours. > For example, the register allocator has much more pressure. > The unified register set is an important feature from the SW point of > view, even though it can be implemented in more or less smart ways ... I agree that unified regset is simpler. On other side in light of fact that 90% of insn results are consumer only once then you can utilize data flow information. In: add r1,r2,r3 xor r3,r4,r5 you know DF tied on r3. Thus with split set with 4x 1r1w regs with ROP2 available only from two banks compiler can always rename r3 to whichever is available as source for xor. Trick is that reads could be limited to register bank while writes needs to reach whole set. The only real problem is with function call - you can't accurately place results because DF is broken at its boundary. Thus here one needs unified set :-\ For superscalar design more splitted regset seems more attractive to me because you can to 4r4w with the same complexity as 2r2w... But well - there is still missing stall detection in latest MR emulator. I've first do it and then back my claims by some specINT numbers .. nice day, devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 18 11:08:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZJa-0000GT-00 for ; Wed, 19 Mar 2003 09:52:50 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:52:50 +0100 (CET) Received: (qmail 8296 invoked by uid 0); 18 Mar 2003 10:07:27 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 18 Mar 2003 10:07:27 -0000 Received: by moria.seul.org (Postfix) id BED5833DE0; Tue, 18 Mar 2003 05:07:25 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 61D4B33DE3; Tue, 18 Mar 2003 05:07:25 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by moria.seul.org (Postfix) with ESMTP id 9F01933DE0 for ; Tue, 18 Mar 2003 05:07:24 -0500 (EST) Received: from f-cpu.org (lcbv2-1-10.n.club-internet.fr [213.44.12.10]) by relay-3v.club-internet.fr (Postfix) with ESMTP id 98E8B177D for ; Tue, 18 Mar 2003 11:06:09 +0100 (CET) Message-ID: <3E76F02D.5040502@f-cpu.org> Date: Tue, 18 Mar 2003 11:08:45 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>>I modified GCC to handle split set of two 1r1w >>>register sets. >>> >>why not two 2r1w ? >> >> >Humm .. it's much more complex to simulate write port >contention on gcc level. Restricting ops to 2 separated >bank was simple. >And my reason for whole experiment was effeciency. > "efficiency" is not a clear explanation, because one might want efficiency in consumed power, power/price, power/performance, coding, ease of implementation, etc.... >I have several uses for fcpu (I'll have to downgrade it to >32 bits probably) which I'd like to instantiate in lower >end FPGA (Xilinx Spartan). > if you want to make small CPUs, F-CPU is not a good target. Furthermore there exists already a looot of 32-bit CPUs, which are better suited for low power and small footprints. The fpgacpu.org site is a good place to look at, for example, because it gives several good tricks. In this particular case, "efficiency" is about reduced FPGA size (hence price) and consumed power, as a hit in code footprint AND in execution time is tolerated (memory is cheap compared to FPGA). F-CPU is not meant to compete in this branch. >When I have budget of say 5,000 LCs and each 16bits >of 1r1w will use one LC I have 512 LC for 2r1w regset >(even partitioned) with 64x64 bits. But only half >(256) LCs for two 1r1w (32x64). 256LCs can be used >to implement pipelined adder then. > > i fear that you're going to bump into haunted dark corners, because the idea of downsizing of F-CPU has been abandonned long ago. What would be the point when there exists better suited and functionning CPUs ? On top of that, your software will not be compatible with "regular" F-CPU cores. >But I agree that full 2r will be always at least a few >percent faster (no moves in function prologs). But this >is the only place (prologs) where compiler is not able >to satisfy constraints exactly (!). > everything counts ! >This and another >one (I forgot): when value is user more times and is needed >in both halves of split. > > in this case, it is like having a 2-address processor.... >>By restricting pointers to certain locations, >>coding SW is more complex and less flexible >>for example. >> >> >are you sure ? In some weird way by restricting registers >you add orthogonality ;) because there is less ways to do >a single thing. > i think that it is a wrong conclusion. adding ways to do the same thing differently has an impact on large instruction blocks : if one way is not possible, the other is still practicable. Unfortunately, gcc might not be able to grasp all these nuances. Orthogonality goes along with reducing the number of coding rules. >And for compiler is it simpler to cope with a few "pointer" >registers at fixed place than to check for usage of up >to 8 pointers within 64 registers (as needed by regno-cacheline >mapping if the proposal is still alive) ! We will still >have to say GCC which registers are usable as pointers >(say 28..35) because there is no other way to assure that >compiler will not alocate more than 8 pointers. > > note that the number of pointing register can evolve in the future... that is why restricting the number of point register is not a good idea. you better try to rely on pointer reuse and the LRU mechanism. >If one would at least mandate that pointers must be allocated >from end of register set backward for example it could simplify >that mapping, am I right ? > > it would simplify mapping in some cases but not all the time. >>>I've done it in testing mode for binary ops and >>>stores and it seems that 70% of ops are ok. >>> >>the remaining 30% are what hurts most when you need them. >>If this increases code size by 10% it's already a hit. >>A more complex register set could give better results >>and still avoid the problems of its size. >> >> >you are right. well is seems that for smaller regsets (2r2w) >one can use partitioned 2r1w or use 2x1r1w with penalty >for two single-bank read to be used in embeded designs. > F-CPU has not been created for very small footprints, but more for getting every small performance increase by any reasonable mean. >We can at least hint gcc to try to allocate registers >from oposite banks whenever it is possible without any >other insn generation (yet gcc can do it). It will not >hurt full 2r design and will help 1r implementations. > > i would rather split the register set in more sub-banks, in order to increase the associativity and reduce the hit to a smaller fraction. Maybe you should try with 16 or 8 banks, and give us comparative results. In this case, my gut feeling is that the hit is only marginal. >>>When we will spend more time on it I believe that >>>we can reach about 90%. >>> >>i hope that a 4-bank 2r1w register set can give better results. >>90% efficiency is not enough. Don't forget that FC0 >>is a scalar CPU and increase of code size has a direct impact >>on performance. This is why the instruction set is so rich now. >> >> >By the way are you still convinced of the 3rd readport usefullness ? > yup, and particularly when SRB is implemented. but if you don't need it, you can leave it alone in the beginning. >2w are definitely ok for oooc but even from many compiled code >which I've seen I saw 3r insn exacly one time in loop like: >while(p->valid) { p+=off; ...use p here... } >which did lead into postincrement by register with "off". > >I also saw mac a few times. MMX like pmadd might be better >because it is 2r1w and imposes no RAW interdependency between >subsequent ones. But yes it might be seen as "different" >because changes chunk size on the fly. On other side it >supports widening multiply. > > widening multiply means that there is no need for scheduling a couple of MAC instructions AND later combining the result back into a single register, hence at least 2 clock cycles that are saved, it's particularly important in these small computational-intensive loops for 3D, sound and video... >>but it breaks a lot of expected behaviours. >>For example, the register allocator has much more pressure. >>The unified register set is an important feature from the SW point of >>view, even though it can be implemented in more or less smart ways ... >> >> >I agree that unified regset is simpler. On other side in light >of fact that 90% of insn results are consumer only once then >you can utilize data flow information. In: >add r1,r2,r3 >xor r3,r4,r5 > >you know DF tied on r3. Thus with split set with 4x 1r1w regs >with ROP2 available only from two banks compiler can always >rename r3 to whichever is available as source for xor. > ouch, that's ugly .... it's too specific to a particular implementation : if it is ever implemented, porting to other architecture will become a nightmare. my opinion is to perform this "transparently" with the core, using more banks to reduce contentions and inserting "penalty cycles" automatically to ensure that other cores can implement the register set in a way that is more suitable to their particular case. >Trick is that reads could be limited to register bank while >writes needs to reach whole set. The only real problem is >with function call - you can't accurately place results >because DF is broken at its boundary. >Thus here one needs unified set :-\ > > as long as you're doing a forked subset of F-CPU, that's ok for you because you can't expect to get screaming performance out of 5K LCs. the SW performance goes along.... >For superscalar design more splitted regset seems more attractive >to me because you can to 4r4w with the same complexity as 2r2w... > >But well - there is still missing stall detection in latest >MR emulator. I've first do it and then back my claims by >some specINT numbers .. > > are you really going to run SPEC2K ? .... :-) >nice day, >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Mar 18 12:59:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZJh-0000GT-00 for ; Wed, 19 Mar 2003 09:52:57 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:52:57 +0100 (CET) Received: (qmail 24113 invoked by uid 0); 18 Mar 2003 12:18:23 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 18 Mar 2003 12:18:23 -0000 Received: by moria.seul.org (Postfix) id 5906E33DEF; Tue, 18 Mar 2003 07:18:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1131333DF1; Tue, 18 Mar 2003 07:18:21 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 077B333DEF for ; Tue, 18 Mar 2003 07:18:19 -0500 (EST) Received: from a79-137.dialup.iol.cz ([194.228.137.79] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18vG2d-0005Wc-00 for f-cpu@seul.org; Tue, 18 Mar 2003 13:18:05 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18vFl5-0000Bl-00 for f-cpu@seul.org; Tue, 18 Mar 2003 12:59:55 +0100 Date: Tue, 18 Mar 2003 12:59:55 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Register set revised In-Reply-To: <3E76F02D.5040502@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > if you want to make small CPUs, F-CPU is not a good target. > Furthermore there exists already a looot of 32-bit CPUs, > which are better suited for low power and small footprints. > The fpgacpu.org site is a good place to look at, for example, > because it gives several good tricks. oh well. As strongly sw oriented guy I started to realize such consequences just now. The architecture seemed rather simple to me but recently I started to see how complex it can be at logic level. > i would rather split the register set in more sub-banks, > in order to increase the associativity and reduce the hit > to a smaller fraction. Maybe you should try with 16 or 8 banks, > and give us comparative results. In this case, my gut feeling > is that the hit is only marginal. it would be interesting. unfortunately it is far from being simple to test more than 2 split sources ... > >I also saw mac a few times. MMX like pmadd might be better > >because it is 2r1w and imposes no RAW interdependency between > >subsequent ones. But yes it might be seen as "different" > >because changes chunk size on the fly. On other side it > >supports widening multiply. > > > widening multiply means that there is no need for scheduling a couple of MAC > instructions AND later combining the result back into a single register, > hence at least 2 clock cycles that are saved, it's particularly important > in these small computational-intensive loops for 3D, sound and video... yes I agree I overlooked that MAC is widening. I came to conclusion before that it is not. > >with ROP2 available only from two banks compiler can always > >rename r3 to whichever is available as source for xor. > > > ouch, that's ugly .... yes, isn't it ? ;-) Ok back to be serious. I sometimes try to think in non-conventional ways and often reinvent wheels ... > my opinion is to perform this "transparently" with the core, > using more banks to reduce contentions and inserting "penalty cycles" > automatically to ensure that other cores can implement the register > set in a way that is more suitable to their particular case. you are right. My latest screams into dark was caused by my interest having ultra-simple design with reasonable performance for SoC design. OpenRisc 1200 is still too complex for me :-\ I even didn't find suitable one on fpgacpu.org. I'd like to have small linux servers in fpga to act as boundary routers, net-connected video grabbers etc. > >MR emulator. I've first do it and then back my claims by > >some specINT numbers .. > > > are you really going to run SPEC2K ? .... :-) if someone will be willin to privately donate copy ;-) But probably I'd measure mix of some utils like gcc, grep and compare with Intel system with known specint. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From william7_esq@juno.com Tue Mar 18 16:21:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZJu-0000GT-01 for ; Wed, 19 Mar 2003 09:53:11 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:10 +0100 (CET) Received: (qmail 17060 invoked by uid 0); 18 Mar 2003 15:23:28 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 18 Mar 2003 15:23:28 -0000 Received: by moria.seul.org (Postfix) id 2A95C33E14; Tue, 18 Mar 2003 10:23:28 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DB97B33E13; Tue, 18 Mar 2003 10:23:27 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from webmail02.lax.untd.com (outbound-28.lax.untd.com [64.136.28.100]) by moria.seul.org (Postfix) with SMTP id 51C2A33E11 for ; Tue, 18 Mar 2003 10:23:27 -0500 (EST) Received: from cookie.juno.com by cookie.juno.com for <"0omY/bLEMx4P1+4J2cpwY2ObdOfJn+kYRaUrRYR/w5HURhZTJboNrg==">; Tue, 18 Mar 2003 07:22:30 PST Received: (from william7_esq@juno.com) by webmail02.lax.untd.com (jqueuemail) id HTKJM9Q9; Tue, 18 Mar 2003 07:22:30 PST Received: from [80.179.100.27] by webmail02.lax.untd.com X-Originating-IP: [80.179.100.27] X-Original-From: william7_esq@juno.com Date: Tue, 18 Mar 2003 15:21:33 GMT To: william7_esq@juno.com Subject: [f-cpu] PLEASE CONFIRM URGENTLY. X-Mailer: WebMail Version 1.0 From: william7_esq@juno.com Message-Id: <20030318.072230.2163.97174@webmail02.lax.untd.com> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N FROM THE DESK OF:WILLIAMS OGUNYINKA ESQ 65 BERRIES LANE,VICTORIA GARDEN CITY LEKKY LAGOS-NIGERIA FAX:234-1-7592780 DATE 18TH MARCH 2003 E-MAIL:esqwill_c@mail2world.com ATTN: THE PRESIDENT/CEO DEAR SIR, I AM BARRISTER WILLIAMS OGUNYINKA, A SOLICITOR AT LAW.I AM THE PERSONAL ATTORNEY TO MR.BUFFET EDMOND, A NATIONAL OF THE UNITED KINGDOM, WHO USED TO WORK WITH SHELL PETROLEUM DEVELOPMENT COMPANY IN THE REPUBLIC OF GABON.ON THE 21st OF APRIL 2000,MY CLIENT, HIS WIFE AND THEIR ONLY DAUGHTER WERE INVOLVED IN A CAR ACCIDENT ALONG SAGBAMA EXPRESS ROAD.ALL OCCUPANTS OF THE VEHICLE UNFORTUNATELY LOST THERE LIVES. SINCE THEN I HAVE MADE SEVERAL ENQUIRIES TO THE PEOPLE I KNOW HERE TO LOCATE ANY OF MY CLIENTS EXTENDED RELATIVES, THIS HAS ALSO PROVED UNSUCCESSFUL. AFTER THESE SEVERAL UNSUCCESSFUL ATTEMPTS,I DECIDED TO TRACK HIS LAST NAME OVER THE INTERNET,TO LOCATE ANY MEMBER OF HIS FAMILY HENCE I CONTACTED YOU TO ASSIST IN RECOVERING THE FUND VALUED AT US$14.9 MILLION LEFT BEHIND BY MY CLIENT BEFORE IT GETS CONFISCATED OR DECLARED UNSERVICEABLE BY THE SECURITY FINANCE FIRM WHERE THIS HUGE AMOUNT WERE DEPOSITED. THE SAID FINANCIAL INSTITUTION HAS ISSUED ME A NOTICE TO PROVIDE THE NEXT OF KIN OR HAVE THE ACCOUNT CONFISCATED WITHIN THE NEXT SIXTY ONE OFFICIAL WORKING DAYS.SINCE I HAVE BEEN UNSUCCESSFUL IN LOCATING THE RELATIVES FOR FOR OVER 2 YEARS NOW I THEREFORE SEEK YOUR CONCENT TO PRESENT YOU AS THE NEXT OF KIN TO THE DECEASED, SO THAT THE PROCEEDS OF THIS ACCOUNT CAN BE PAID TO YOU. ON RECEIPT OF YOUR POSITIVE RESPONSE, WE SHALL THEN DISCUSS THE SHARING RATIO AND MODALITIES FOR TRANSFER.I HAVE ALL NECESSARY INFORMATION AND LEGAL DOCUMENTS NEEDED TO BACK YOU UP FOR CLAIMS ALL I REQUIRE FROM YOU IS YOUR HONEST COOPERATION TO ENABLE US SEE THIS TRANSACTION THROUGH. I GUARANTEE THAT THIS WILL BE EXECUTED UNDER LEGITIMATE ARRANGEMENT THAT WILL PROTECT YOU FROM ANY BREACH OF LAW.PLEASE GET IN TOUCH WITH ME THROUGH THIS EMAIL: (esqwill_c@mail2world.com) or fax number :(234-1-7592780) PLEASE NOTE THAT I AM PRESENTLY IN LAGOS THE FEDERAL REPUBLIC OF NIGERIA IN PURSUANCE OF THIS SUBJECT MATTER SINCE THE FINANCIAL INSTITUTION IS BASED HERE. BEST REGARDS WILLIAMS OGUNYINKA ESQ ). ________________________________________________________________ Sign Up for Juno Platinum Internet Access Today Only $9.95 per month! Visit www.juno.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Credit_Doctor_102@xo.com Tue Mar 18 17:00:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZK8-0000GT-00 for ; Wed, 19 Mar 2003 09:53:24 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:24 +0100 (CET) Received: (qmail 6415 invoked by uid 0); 18 Mar 2003 16:00:04 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 18 Mar 2003 16:00:04 -0000 Received: by moria.seul.org (Postfix) id 84D6833E10; Tue, 18 Mar 2003 11:00:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 12FA733E12; Tue, 18 Mar 2003 11:00:02 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from 61.153.251.80 (unknown [61.153.251.80]) by moria.seul.org (Postfix) with SMTP id 418DD33E10 for ; Tue, 18 Mar 2003 10:59:58 -0500 (EST) Received: from [42.47.39.56] by mta6.snfc21.pbi.net with SMTP; Mar, 18 2003 8:59:44 AM -0300 Received: from [6.135.221.168] by rly-xl05.mx.aol.com with asmtp; Mar, 18 2003 7:35:47 AM -0000 From: Nathanial To: f-cpu@seul.org Subject: [f-cpu] Re: ABOUT YOUR CREDIT.................... rtra Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 18 Mar 2003 10:00:07 -0600 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Message-Id: <20030318155958.418DD33E10@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N

We can fix your credit. We are very successful at getting bankruptcies, judgments, tax liens, foreclosures, late payments, charge-offs, repossessions, and even student loans removed from a persons credit report. To find out more go to http://www.netcreditlawyer.com.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  qdalsetybacwukdtkesgiewpxjix ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 18 12:34:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZKD-0000GT-00 for ; Wed, 19 Mar 2003 09:53:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:29 +0100 (CET) Received: (qmail 16513 invoked by uid 0); 18 Mar 2003 18:19:17 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 18 Mar 2003 18:19:17 -0000 Received: by moria.seul.org (Postfix) id 71C7D33E3A; Tue, 18 Mar 2003 13:19:16 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 26FE333E3C; Tue, 18 Mar 2003 13:19:16 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id 965D233E3A for ; Tue, 18 Mar 2003 13:19:14 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00552; Tue, 18 Mar 2003 12:34:21 +0100 Message-ID: <20030318123420.46525@thrai.stud.uni-hannover.de> Date: Tue, 18 Mar 2003 12:34:20 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: <3E76F02D.5040502@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E76F02D.5040502@f-cpu.org>; from Yann Guidon on Tue, Mar 18, 2003 at 11:08:45AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Mar 18, 2003 at 11:08:45AM +0100, Yann Guidon wrote: [...] > are you really going to run SPEC2K ? .... :-) If devik isn't, I certainly am. I'll probably compile the emulator on some really fast 64-bit machine, of course. On my old Pentium, the emulated/native instruction ratio is something like 1:200... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 18 12:29:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZKE-0000GT-00 for ; Wed, 19 Mar 2003 09:53:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:30 +0100 (CET) Received: (qmail 12972 invoked by uid 0); 18 Mar 2003 18:19:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 18 Mar 2003 18:19:22 -0000 Received: by moria.seul.org (Postfix) id 41FD833E3D; Tue, 18 Mar 2003 13:19:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A961833E3E; Tue, 18 Mar 2003 13:19:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a139.home.uni-hannover.de [130.75.232.139]) by moria.seul.org (Postfix) with ESMTP id 60A6033E3D for ; Tue, 18 Mar 2003 13:19:16 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00536; Tue, 18 Mar 2003 12:29:34 +0100 Message-ID: <20030318122934.10648@thrai.stud.uni-hannover.de> Date: Tue, 18 Mar 2003 12:29:34 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: <3E766E23.9020902@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Mar 18, 2003 at 08:31:30AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Mar 18, 2003 at 08:31:30AM +0100, devik wrote: [...] > But well - there is still missing stall detection in latest > MR emulator. I've first do it and then back my claims by > some specINT numbers .. Stall detection shouldn't be hard to add; I can do it when CeBIT is over and I got my articles in print. There is one open question, however: How would you like stalls to be reported? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Mar 18 21:30:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZKR-0000GT-00 for ; Wed, 19 Mar 2003 09:53:43 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:43 +0100 (CET) Received: (qmail 3177 invoked by uid 0); 18 Mar 2003 20:29:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 18 Mar 2003 20:29:25 -0000 Received: by moria.seul.org (Postfix) id D85F533E45; Tue, 18 Mar 2003 15:29:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4ACC933E4A; Tue, 18 Mar 2003 15:29:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 7423B33E45 for ; Tue, 18 Mar 2003 15:29:19 -0500 (EST) Received: from f-cpu.org (lcbv2-1-175.n.club-internet.fr [213.44.12.175]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 33C6716D5 for ; Tue, 18 Mar 2003 21:29:17 +0100 (CET) Message-ID: <3E7781F2.3070505@f-cpu.org> Date: Tue, 18 Mar 2003 21:30:42 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >>if you want to make small CPUs, F-CPU is not a good target. >>Furthermore there exists already a looot of 32-bit CPUs, >>which are better suited for low power and small footprints. >>The fpgacpu.org site is a good place to look at, for example, >>because it gives several good tricks. >> >> >oh well. As strongly sw oriented guy I started to realize >such consequences just now. The architecture seemed rather >simple to me but recently I started to see how complex it >can be at logic level. > > heh :-) we did some serious work to make people believe that "F-CPU is simple", just to get them interested and induce them to do some work ;-) >>i would rather split the register set in more sub-banks, >>in order to increase the associativity and reduce the hit >>to a smaller fraction. Maybe you should try with 16 or 8 banks, >>and give us comparative results. In this case, my gut feeling >>is that the hit is only marginal. >> >> >it would be interesting. unfortunately it is far from being >simple to test more than 2 split sources ... > > really ? i think that for our case, that is : decoding whether 2 writes occur to the same bank, it is a simple as comparing the 2 write addresses and see if they match. if there are 8 banks, then it is a 3-bit comparator (3 ands and a 3-input AND). This way it would be possible to have 8 banks of 8 registers with 2/3 read outputs and 1 write input. welcome to the HW world ;-) >>>I also saw mac a few times. MMX like pmadd might be better >>>because it is 2r1w and imposes no RAW interdependency between >>>subsequent ones. But yes it might be seen as "different" >>>because changes chunk size on the fly. On other side it >>>supports widening multiply. >>> >>widening multiply means that there is no need for scheduling a couple of MAC >>instructions AND later combining the result back into a single register, >>hence at least 2 clock cycles that are saved, it's particularly important >>in these small computational-intensive loops for 3D, sound and video... >> >> >yes I agree I overlooked that MAC is widening. I came to >conclusion before that it is not. > > i did quite a bit of Pentium MMX coding and even discussed with one of the architects. They had to make some early design decisions and ISA definitions based on the then available resources and limitations. This is why the speed increase of MMX (only 2x in average compared to normal "scalar" code) is so marginal. The widening MAC is only one example : it takes 3 cycles to compute and it can be pipelined, but the "butterfly" eats up more cycles. that's dumb ! This is one of the reasons why 3r2w is desirable. >>>with ROP2 available only from two banks compiler can always >>>rename r3 to whichever is available as source for xor. >>> >>ouch, that's ugly .... >> >> >yes, isn't it ? ;-) > it makes me think too much of "barebone VLIW" architectures .... without even the advantages. > Ok back to be serious. I sometimes try >to think in non-conventional ways and often reinvent wheels ... > > don't worry about that. >>my opinion is to perform this "transparently" with the core, >>using more banks to reduce contentions and inserting "penalty cycles" >>automatically to ensure that other cores can implement the register >>set in a way that is more suitable to their particular case. >> >> >you are right. My latest screams into dark was caused >by my interest having ultra-simple design with reasonable >performance for SoC design. OpenRisc 1200 is still too >complex for me :-\ I even didn't find suitable one on >fpgacpu.org. > i have seen an increadible 32 bit core on fpgacpu.org, i think it's the XSOC. It is very small and the instruction set is really limited but it can compile some things. it has no protection at all, but it fits into a few hundreds of cells.... >I'd like to have small linux servers in fpga to act as boundary >routers, net-connected video grabbers etc. > > i have found some chip Europa-format i486-DX66 boards in Berlin and that's probably what you need (like a PC104 board or something like that). And because it's almost a PC, development is much faster. >>>MR emulator. I've first do it and then back my claims by >>>some specINT numbers .. >>> >>are you really going to run SPEC2K ? .... :-) >> >> >if someone will be willin to privately donate copy ;-) >But probably I'd measure mix of some utils like gcc, grep >and compare with Intel system with known specint. > > good luck ... >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Mar 18 19:39:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vZKX-0000GT-00 for ; Wed, 19 Mar 2003 09:53:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 09:53:49 +0100 (CET) Received: (qmail 30369 invoked by uid 0); 18 Mar 2003 22:49:20 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 18 Mar 2003 22:49:20 -0000 Received: by moria.seul.org (Postfix) id 8CE1833E5F; Tue, 18 Mar 2003 17:49:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3294A33E61; Tue, 18 Mar 2003 17:49:18 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a191.home.uni-hannover.de [130.75.232.191]) by moria.seul.org (Postfix) with ESMTP id E7A5533E5F for ; Tue, 18 Mar 2003 17:49:15 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00546; Tue, 18 Mar 2003 19:39:12 +0100 Message-ID: <20030318193912.40737@thrai.stud.uni-hannover.de> Date: Tue, 18 Mar 2003 19:39:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Register set revised References: <3E76F02D.5040502@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Mar 18, 2003 at 12:59:55PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Mar 18, 2003 at 12:59:55PM +0100, devik wrote: [...] > > are you really going to run SPEC2K ? .... :-) > > if someone will be willin to privately donate copy ;-) I have access to it but I'm not permitted to give away copies. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 19 10:10:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vaac-0001OP-00 for ; Wed, 19 Mar 2003 11:14:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 11:14:30 +0100 (CET) Received: (qmail 13836 invoked by uid 0); 19 Mar 2003 09:29:54 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 19 Mar 2003 09:29:54 -0000 Received: by moria.seul.org (Postfix) id B768433F56; Wed, 19 Mar 2003 04:29:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 050B233F5C; Wed, 19 Mar 2003 04:29:50 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D4E6E33B7D for ; Wed, 19 Mar 2003 04:28:54 -0500 (EST) Received: from a86-137.dialup.iol.cz ([194.228.137.86] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18vZs5-0002Xw-00 for f-cpu@seul.org; Wed, 19 Mar 2003 10:28:30 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18vZaD-0000DI-00 for f-cpu@seul.org; Wed, 19 Mar 2003 10:10:01 +0100 Date: Wed, 19 Mar 2003 10:10:01 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Register set revised In-Reply-To: <3E7781F2.3070505@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >oh well. As strongly sw oriented guy I started to realize > >such consequences just now. The architecture seemed rather > >simple to me but recently I started to see how complex it > >can be at logic level. > > > > > heh :-) > > we did some serious work to make people believe that "F-CPU is simple", > just to get them interested and induce them to do some work ;-) It works ! :-) > >it would be interesting. unfortunately it is far from being > >simple to test more than 2 split sources ... > > > really ? > i think that for our case, that is : decoding whether 2 writes occur to > [...] you misunderstood me - I wanted to say that it is more complex to convince GCC to try to optimize register allocation to minimize hazards of simultaneous writes to the same bank. We can learn scheduler to exchange some insns to be scheduled at different time to avoid it but there is still possibility to do something at register allocation stage. Maybe we could rename temporary registers in postprocessing pass after scheduling when we detect bank collision. > outputs and 1 write input. welcome to the HW world ;-) it is not SO bad with my hw experiance :) I know that from HW side it is not so complex. By the way have you seen ETRAX chip especially CRIS CPU ? They have nicely compact set :) Well I agree it is not good for superscalar but it is nice to see how compiled code become smaller thasn x86 (but not as small as for ARM). As you hinted me, I looked at other CPUs usable for small linux system and ETRAX is nice. $40 when you buy 1pcs, direct SDRAM/SRAM/EDO connection, 100Mbit eth, sync/async serial, wide buses, 100MIPS ... > i did quite a bit of Pentium MMX coding and even discussed with > one of the architects. They had to make some early design decisions > and ISA definitions based on the then available resources and limitations. > This is why the speed increase of MMX (only 2x in average compared > to normal "scalar" code) is so marginal. The widening MAC > is only one example : it takes 3 cycles to compute and it can be pipelined, > but the "butterfly" eats up more cycles. that's dumb ! > This is one of the reasons why 3r2w is desirable. I agree that IDCT in MMX is quite large with all these PPACKxxx insns. I'm interested in 8x8 DCT because it is quite useful (jpeg,mpeg..). By the way F-CPU is missing SAD insn which is very useful for video. And it can't be coded effeciently in f-cpu. At least sum of bytes inside register would be needed. > i have seen an increadible 32 bit core on fpgacpu.org, > i think it's the XSOC. It is very small and the instruction > set is really limited but it can compile some things. > it has no protection at all, but it fits into a few hundreds > of cells.... sound interesting. I should at least look at it :) > i have found some chip Europa-format i486-DX66 boards in Berlin > and that's probably what you need (like a PC104 board or something > like that). And because it's almost a PC, development is much faster. I like ETRAX (above) - they natively support linux and it is almost complete server system with 1W of power at 1.8V .. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jrydberg@night.trouble.net Wed Mar 19 12:05:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vcOx-0007ob-01 for ; Wed, 19 Mar 2003 13:10:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 13:10:35 +0100 (CET) Received: (qmail 5908 invoked by uid 0); 19 Mar 2003 11:05:22 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 19 Mar 2003 11:05:22 -0000 Received: by moria.seul.org (Postfix) id AD72B33D06; Wed, 19 Mar 2003 06:05:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 57C7B33D19; Wed, 19 Mar 2003 06:05:20 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from nic.lth.se (nic.lth.se [130.235.20.3]) by moria.seul.org (Postfix) with ESMTP id 827AE33D06 for ; Wed, 19 Mar 2003 06:05:19 -0500 (EST) Received: from night.trouble.net (powermac-12.ludat.lth.se [130.235.21.232]) by nic.lth.se (8.12.8/8.12.8) with ESMTP id h2JB5Eml012824 for ; Wed, 19 Mar 2003 12:05:18 +0100 (MET) Date: Wed, 19 Mar 2003 12:05:09 +0100 Subject: Re: [f-cpu] Register set revised Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Johan Rydberg To: f-cpu@seul.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030318193912.40737@thrai.stud.uni-hannover.de> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N tisdagen den 18 mars 2003 kl 19.39 skrev Michael Riepe: > On Tue, Mar 18, 2003 at 12:59:55PM +0100, devik wrote: > [...] >>> are you really going to run SPEC2K ? .... :-) >> >> if someone will be willin to privately donate copy ;-) > > I have access to it but I'm not permitted to give away copies. You can always run the BYTEmark [1] benchmark suite, which is totally free. [1] http://www.byte.com/bmark/bmark.htm brgds, johan ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Mar 19 15:08:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vgnP-0002NN-00 for ; Wed, 19 Mar 2003 17:52:07 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 19 Mar 2003 17:52:07 +0100 (CET) Received: (qmail 12627 invoked by uid 0); 19 Mar 2003 14:28:11 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 19 Mar 2003 14:28:11 -0000 Received: by moria.seul.org (Postfix) id A102F33F6D; Wed, 19 Mar 2003 09:28:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73D3533F6F; Wed, 19 Mar 2003 09:28:09 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 0B3BD33F6D for ; Wed, 19 Mar 2003 09:28:08 -0500 (EST) Received: from a30-137.dialup.iol.cz ([194.228.137.30] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18veXy-00044x-00 for f-cpu@seul.org; Wed, 19 Mar 2003 15:28:03 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18veEg-0000Kj-00 for f-cpu@seul.org; Wed, 19 Mar 2003 15:08:06 +0100 Date: Wed, 19 Mar 2003 15:08:06 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Register set revised In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > You can always run the BYTEmark [1] benchmark suite, which is > totally free. > > [1] http://www.byte.com/bmark/bmark.htm thanks for the reference. Page http://www.tux.org/~mayer/linux/results2.html is also interesting. It seems that i486/50 scaled to 233MHz would have 0.5 integer performance of AMD K6 233 MHz. Or 0.59 of PII, 0.5 of Athlon, 0.7 of P4, but only 0.44 of AthlonXP. 0.34 for Itanium and 0.33 for Alpha 21264. Let's invert that and look for ILP of different architectures: P4 1.4 USparc3 1.9 AthlonXP 2.3 Itanium 2.9 Alpha 3.0 PPC G3 3.0 R10000 3.0 PA-Risc 3.4 (!) Interesting. HP wants to replace their PA which seems to be fastest integer MIPS/MHz by Itanium which is not as good but is much more complex and power hungry. Weird business. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Mar 19 22:24:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18vsNv-0006XJ-00 for ; Thu, 20 Mar 2003 06:14:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 20 Mar 2003 06:14:35 +0100 (CET) Received: (qmail 9020 invoked by uid 0); 19 Mar 2003 23:23:48 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 19 Mar 2003 23:23:48 -0000 Received: by moria.seul.org (Postfix) id 1190933C6D; Wed, 19 Mar 2003 18:23:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 869DC33C99; Wed, 19 Mar 2003 18:23:47 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a042.home.uni-hannover.de [130.75.232.42]) by moria.seul.org (Postfix) with ESMTP id BE4C933C6D for ; Wed, 19 Mar 2003 18:23:42 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA00988; Wed, 19 Mar 2003 22:24:48 +0100 Message-ID: <20030319222448.04918@thrai.stud.uni-hannover.de> Date: Wed, 19 Mar 2003 22:24:48 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: EU Report (was: Re: [f-cpu] Register set revised) References: <3E7781F2.3070505@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Mar 19, 2003 at 10:10:01AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Mar 19, 2003 at 10:10:01AM +0100, devik wrote: [...] > By the way F-CPU is missing SAD insn which is very useful for video. How sad ;) > And it can't be coded effeciently in f-cpu. At least sum of bytes > inside register would be needed. What exactly is the SAD insn supposed to do? A sum-of-bytes instruction could be integrated with EU_POPC -- that unit typically also includes an N:1 byte adder (for popcount with wider chunks). I also consider making EU_POPC more general (and rename it to EU_AFU, for "additional functions unit", or maybe "a fun unit" ;-). Since it's full of XORs anyway, it may also be able to perform things like CRC and ECC generation or similar stuff (simple parity is already there: it's in the LSB of the popcount result). While we're talking about EUs... I revisited the ASU recently (after more than a year), and I found a way to include some additional functions. We now also have Y = A + B + 1 (including correct carry-out) Y = A - B - 1 (including correct carry-out) with fast 8-bit results (1 cycle) and Y = (A + B) / 2 Y = (A + B + 1) / 2 Y = (B - A) / 2 Y = (B - A - 1) / 2 which always take two cycles. The third and fourth functions are probably most interesting (average with up/down rounding). With a minor modification (which I've not done yet), it should also be possible to derive the `increment' flag from a third input port and calculate tmp = A ± (B + lsb(C)) Y = tmp % pow(2, chunksize) Z = tmp / pow(2, chunksize) Since that's a 3r2w operation, don't expect it to be implemented in FC0. It would be quite useful for adding/subtracting big numbers, however. I also have complete INC and CMP units available. EU_INC performs inc/dec/neg in 1 cycle, and abs/nabs/lsb0/lsb1 in 2 cycles. In lsb mode, two different results are available: a single-bit mask that selects the bit searched for, or a binary encoded index. The same is true for msb (but that's handled by the CMP unit). EU_CMP also performs cmpg (and its inverse, cmple), or min and max (at the same time, via separate output ports -- which also gives us minmax, aka `sort'). EU_CMP operations always take two cycles. All of them (that is, ASU/INC/CMP) auto-scale to integer multiples of 64 bits (the maximum chunk size of 64 bits doesn't increase, however). I'll add this feature to the other EUs later (it's a bit more difficult with EU_IMU and EU_SHL). EU_IMU is subject to change. Since I managed to squeeze some delay out of EU_ASU, I may also be able to make some room inside the multiplier (which is basically a huge n-input adder). I hope that will provide enough space for output muxes that let us select between mul/amac results on one hand and mac[l|h] results on the other (output port usage is pretty different between these groups, and I don't want to add another set of 8 ports). It may also improve the timing a bit. EU_IDU still isn't finished. I have a normalizer (a data-driven bit shifter based on an omega network, which can also be used in int->fp conversions) and a radix-2 SRT core. I'm also investigating radix-16 SRT but the lookup tables for the partial quotients seem to be too complex. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Mar 20 10:26:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18w7ox-0000QM-00 for ; Thu, 20 Mar 2003 22:43:31 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 20 Mar 2003 22:43:31 +0100 (CET) Received: (qmail 3156 invoked by uid 0); 20 Mar 2003 09:41:06 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 20 Mar 2003 09:41:06 -0000 Received: by moria.seul.org (Postfix) id 1038233BDE; Thu, 20 Mar 2003 04:41:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4371C33CBC; Thu, 20 Mar 2003 04:40:40 -0500 (EST) Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 02A6833BDE for ; Thu, 20 Mar 2003 04:40:28 -0500 (EST) Received: from a84-137.dialup.iol.cz ([194.228.137.84] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18vwWv-0000P1-00 for f-cpu@seul.org; Thu, 20 Mar 2003 10:40:10 +0100 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18vwJk-0000Bl-00 for f-cpu@seul.org; Thu, 20 Mar 2003 10:26:32 +0100 Date: Thu, 20 Mar 2003 10:26:32 +0100 (CET) From: devik X-X-Sender: To: Subject: Re: EU Report (was: Re: [f-cpu] Register set revised) In-Reply-To: <20030319222448.04918@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > What exactly is the SAD insn supposed to do? Sum of Absolute Differences. It take two SIMD words, makes abs(a-b) for each corresponding bytes and adds all these differences. This is used when computing motion vectors in mpeg encoder. I've seen it in several instruction sets. However I don't know where it is usable outside of mpeg. > =09tmp =3D A =B1 (B + lsb(C)) > =09Y =3D tmp % pow(2, chunksize) > =09Z =3D tmp / pow(2, chunksize) > > Since that's a 3r2w operation, don't expect it to be implemented in FC0. > It would be quite useful for adding/subtracting big numbers, however. seems useful. Big number libs (gmp, rsalib...) often need to resort to some trick most related to carry propagation. In GMP manual there is many info on the topic. Would not be possible to do CMP in ASU too ? Both are working with "propagating" information from LSB toward MSB ... Or other question, is the new source available ? I'd like to take a look :) devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From yaku@postmark.net Thu Mar 20 15:04:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18w7p7-0000QM-00 for ; Thu, 20 Mar 2003 22:43:41 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 20 Mar 2003 22:43:41 +0100 (CET) Received: (qmail 19563 invoked by uid 0); 20 Mar 2003 14:06:47 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 20 Mar 2003 14:06:47 -0000 Received: by moria.seul.org (Postfix) id D4D5233B4A; Thu, 20 Mar 2003 09:06:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6CD3533B52; Thu, 20 Mar 2003 09:06:45 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id CF58E33B4A for ; Thu, 20 Mar 2003 09:06:44 -0500 (EST) Received: from 79.04.45.20 (f-tokyo-132243.zero.ad.jp [211.130.132.243]) by bettik.munge.net (Postfix) with SMTP id 6953B4F7EF for ; Thu, 20 Mar 2003 08:07:12 -0600 (CST) From: yaku To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=94=92=82=A2=95=B2=82=CC=83G=83N=83X=83^=83V=81[?= Date: Thu, 20 Mar 2003 23:04:48 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="280fdf1f-4785-4f88-b78f-99dea177b894" Message-Id: <20030320140712.6953B4F7EF@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --280fdf1f-4785-4f88-b78f-99dea177b894 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =83T =83C =83P =83f =83=8A =83b =83N =93V =8D=91 =81` =82=E4 =82=E7 =82=E4 =82= =E7 =81` =94] =96=A1 =91X =82=CD =91=BD =8DK =8A=B4 =82=C5 =96=9E =82=BF =88=EC =82=EA = =81E=81E=81E=81B http://yaku3.netfirms.com/ http://my.kid-d.com/yaku0/ http://members.fortunecity.co.uk/smoker/ =81y=96=A7=94=84=81z=81y=96=A7=94=84=81z=81y=96=A7=94=84=81z=81y=96=A7=94=84= =81z=81y=96=A7=94=84=81z=81y=96=A7=94=84=81z =8D=87 =96@ =83h =83=89 =83b =83O =82=C8 =82=F1 =82=A9 =81A =82=E0 =82=A4 =82=BD =82=E9 =82=AD =82=C4 =81@=82=E2 =82=C1 =82=C4 =82=E7 =82=F1 =82=C8 =82= =A2 =82=C5 =82=B5 =82=E5 http://www.smoker.9cy.com/ http://yaku.ciudad.org/ http://book-i.net/yaku0/ =81y=96=A7=94=84=81z=81y=96=A7=94=84=81z=81y=96=A7=94=84=81z=81y=96=A7=94=84= =81z=81y=96=A7=94=84=81z=81y=96=A7=94=84=81z --280fdf1f-4785-4f88-b78f-99dea177b894-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Mar 20 14:13:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xD1P-0000Gg-01 for ; Sun, 23 Mar 2003 22:28:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 23 Mar 2003 22:28:51 +0100 (CET) Received: (qmail 4546 invoked by uid 0); 21 Mar 2003 00:04:59 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 21 Mar 2003 00:04:59 -0000 Received: by moria.seul.org (Postfix) id AF6E833B4F; Thu, 20 Mar 2003 19:04:57 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 335B233B52; Thu, 20 Mar 2003 19:04:57 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a111.home.uni-hannover.de [130.75.232.111]) by moria.seul.org (Postfix) with ESMTP id 4164133B4F for ; Thu, 20 Mar 2003 19:04:41 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00673; Thu, 20 Mar 2003 14:13:12 +0100 Message-ID: <20030320141312.19015@thrai.stud.uni-hannover.de> Date: Thu, 20 Mar 2003 14:13:12 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: EU Report (was: Re: [f-cpu] Register set revised) References: <20030319222448.04918@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Mar 20, 2003 at 10:26:32AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Mar 20, 2003 at 10:26:32AM +0100, devik wrote: > > What exactly is the SAD insn supposed to do? > > Sum of Absolute Differences. It take two SIMD words, makes > abs(a-b) for each corresponding bytes and adds all these differences. IC. It's a little heavy for a single instruction, but it can be calculated if there is a `byte adder'. The abs(a-b) part can be calculated with instructions from the current instruction set, either as `abs(a-b)' or as `max(a,b)-min(a,b)', whatever is more convenient. > This is used when computing motion vectors in mpeg encoder. > I've seen it in several instruction sets. However I don't know where > it is usable outside of mpeg. The byte (or chunk) adder will also be useful in vector computations. But I doubt that we will have a chunk adder that works with FP numbers. In any case, the chunks of a word can be combined by using `mix': mix.8 r0, r1, r2 // distributes the chunks across r2 and r3 add.16 r2, r3, r1 mix.16 r0, r1, r2 add.32 r2, r3, r1 mix.32 r0, r1, r2 add.64 r2, r3, r1 // gotcha! This will also work with other commutative operations, e.g. mul. A `chunk add' insn may be more convenient, however (and will also be much faster). > > tmp = A ± (B + lsb(C)) > > Y = tmp % pow(2, chunksize) > > Z = tmp / pow(2, chunksize) > > > > Since that's a 3r2w operation, don't expect it to be implemented in FC0. > > It would be quite useful for adding/subtracting big numbers, however. > > seems useful. Big number libs (gmp, rsalib...) often need to resort > to some trick most related to carry propagation. In GMP manual > there is many info on the topic. Yep, I know. I've done things like that in the emulator, too. The problem with this instruction is that we only have three register number fields in the instruction word. r1 and r1^1 will be the outputs Y and Z, r2 and r3 will be A and B, respectively -- but where does C come from? My best guess is to use r1 for that as well -- but then we'll have to move away r1^1 (which typically contains the result of the last chunk computed) first. > Would not be possible to do CMP in ASU too ? Both are working > with "propagating" information from LSB toward MSB ... The ASU could compare operands (at least in unsigned mode), but it won't perform the other operations that EU_CMP supports: min/max/sort and msb0/msb1 aren't possible with just an adder. And since the adder is busy enough (remember the instruction census?), it's probably better to leave these operations where they are. That does not mean that you can't use `subb' to compare operands for unsigned-less, of course. > Or other question, is the new source available ? I'd like to > take a look :) I'll make a new release of my VHDL sources as soon as I've finished my CeBIT reports for next month's iX issue. That is, by the end of march. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Mar 21 08:40:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xD1Y-0000Gg-00 for ; Sun, 23 Mar 2003 22:29:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 23 Mar 2003 22:29:00 +0100 (CET) Received: (qmail 28594 invoked by uid 0); 21 Mar 2003 07:38:42 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 21 Mar 2003 07:38:42 -0000 Received: by moria.seul.org (Postfix) id 0C97933B72; Fri, 21 Mar 2003 02:38:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CAC3833B78; Fri, 21 Mar 2003 02:38:40 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 3AA1533B72 for ; Fri, 21 Mar 2003 02:38:40 -0500 (EST) Received: from f-cpu.org (lcbv1-1-78.n.club-internet.fr [213.44.3.78]) by relay-4m.club-internet.fr (Postfix) with ESMTP id AFE81E26A for ; Fri, 21 Mar 2003 08:38:37 +0100 (CET) Message-ID: <3E7AC1D7.6080006@f-cpu.org> Date: Fri, 21 Mar 2003 08:40:07 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: EU Report (was: Re: [f-cpu] Register set revised) References: <20030319222448.04918@thrai.stud.uni-hannover.de> <20030320141312.19015@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, (i only reacted after several reads) Michael Riepe wrote: >On Thu, Mar 20, 2003 at 10:26:32AM +0100, devik wrote: > > >>>What exactly is the SAD insn supposed to do? >>> >>> >>Sum of Absolute Differences. It take two SIMD words, makes >>abs(a-b) for each corresponding bytes and adds all these differences. >> >> > >IC. It's a little heavy for a single instruction, but it can be calculated >if there is a `byte adder'. The abs(a-b) part can be calculated with >instructions from the current instruction set, either as `abs(a-b)' or >as `max(a,b)-min(a,b)', whatever is more convenient. > > currently, for FC0, the computation time is directly proportional to the instruction count (if there is no stall). in this case, "abs(a-b)" takes 2 instructions and "max(a,b)-min(a,b)" takes 3 instructions (and cycles) even if the second case has a parallel execution for the min/max. The SAD is in fact doing 3 things : minus, absolute and finally the parallel addition. BTW, i have seen instruction sets with the 2 first operations but NEVER with the parallel addition. Provided that scheduling interleaves enough work to avoid stalls, it is possible to sustain the computation of substraction and absolute values at full speed (as long as the core can get the data). If there is a parallel addition, it can be performed at the end of the loop : usually, it's a 8*8 block and the results can first be accumulated in columns, then the final results are combined in the last row with a few add/shifts. >>This is used when computing motion vectors in mpeg encoder. >> note here : it's for the ENcoder, not the DEcoder/player. and it's not for MPEG1. >>I've seen it in several instruction sets. However I don't know where >>it is usable outside of mpeg. >> >> >The byte (or chunk) adder will also be useful in vector computations. > for what kinds of algorithms ??? >But I doubt that we will have a chunk adder that works with FP numbers. > > heh ... >In any case, the chunks of a word can be combined by using `mix': > > mix.8 r0, r1, r2 // distributes the chunks across r2 and r3 > add.16 r2, r3, r1 > mix.16 r0, r1, r2 > add.32 r2, r3, r1 > mix.32 r0, r1, r2 > add.64 r2, r3, r1 // gotcha! > > :-) >This will also work with other commutative operations, e.g. mul. A `chunk >add' insn may be more convenient, however (and will also be much faster). > > probably but not used often enough. >>> tmp = A ± (B + lsb(C)) >>> Y = tmp % pow(2, chunksize) >>> Z = tmp / pow(2, chunksize) >>> >>>Since that's a 3r2w operation, don't expect it to be implemented in FC0. >>>It would be quite useful for adding/subtracting big numbers, however. >>> >>> >>seems useful. Big number libs (gmp, rsalib...) often need to resort >>to some trick most related to carry propagation. In GMP manual >>there is many info on the topic. >> >> > >Yep, I know. I've done things like that in the emulator, too. > >The problem with this instruction is that we only have three register >number fields in the instruction word. r1 and r1^1 will be the outputs >Y and Z, r2 and r3 will be A and B, respectively -- but where does C >come from? My best guess is to use r1 for that as well -- but then >we'll have to move away r1^1 (which typically contains the result of >the last chunk computed) first. > > > >>Would not be possible to do CMP in ASU too ? Both are working >>with "propagating" information from LSB toward MSB ... >> >> >The ASU could compare operands (at least in unsigned mode), but it >won't perform the other operations that EU_CMP supports: min/max/sort >and msb0/msb1 aren't possible with just an adder. And since the adder >is busy enough (remember the instruction census?), it's probably better >to leave these operations where they are. That does not mean that you >can't use `subb' to compare operands for unsigned-less, of course. > > this confirms what i said earlier : it's interesting to have many ways to perform the same computation, because the exact behaviour varies a bit and can have some benefits depending on the exact circumstances... >>Or other question, is the new source available ? I'd like to >>take a look :) >> >> >I'll make a new release of my VHDL sources as soon as I've finished my >CeBIT reports for next month's iX issue. That is, by the end of march. > cool. then, i'll have to make some cleanup in my files .... YG (playing with ultra-low power electronics) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 21 16:13:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xD1q-0000Gg-00 for ; Sun, 23 Mar 2003 22:29:18 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 23 Mar 2003 22:29:18 +0100 (CET) Received: (qmail 616 invoked by uid 0); 21 Mar 2003 17:29:14 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 21 Mar 2003 17:29:14 -0000 Received: by moria.seul.org (Postfix) id 29FB133B50; Fri, 21 Mar 2003 12:29:12 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3942B33B64; Fri, 21 Mar 2003 12:29:10 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a203.home.uni-hannover.de [130.75.232.203]) by moria.seul.org (Postfix) with ESMTP id 42B5033B50 for ; Fri, 21 Mar 2003 12:29:08 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00835; Fri, 21 Mar 2003 16:13:46 +0100 Message-ID: <20030321161346.63692@thrai.stud.uni-hannover.de> Date: Fri, 21 Mar 2003 16:13:46 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: EU Report (was: Re: [f-cpu] Register set revised) References: <20030319222448.04918@thrai.stud.uni-hannover.de> <20030320141312.19015@thrai.stud.uni-hannover.de> <3E7AC1D7.6080006@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3E7AC1D7.6080006@f-cpu.org>; from Yann Guidon on Fri, Mar 21, 2003 at 08:40:07AM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Mar 21, 2003 at 08:40:07AM +0100, Yann Guidon wrote: [...] > currently, for FC0, the computation time is directly proportional to the > instruction count > (if there is no stall). in this case, "abs(a-b)" takes 2 instructions > and "max(a,b)-min(a,b)" > takes 3 instructions (and cycles) even if the second case has a parallel > execution for the min/max. Why that? Because we have only a single bypass/feedback path? BTW: parallel execution of min/max is already implemented. Note that there is an important difference between abs(a-b) and max(a,b)-min(a,b): Due to restricted operand ranges and intermediate overflows, the former may deliver the wrong result. With min/max, the result will always be correct (provided you choose the appropriate signed/unsigned mode): // signed operation: // r1 := +127 // r2 := -128 // expected result is 255 sub.8 r2, r1, r3 ; r3 = +255 (aka -1) abs.8 r3, r4 ; r4 = +1 (WRONG) minmaxs.8 r2, r1, r4 ; r4 = -128, r5 = +127 sub.8 r4, r5, r6 ; r6 = 255 (CORRECT) // unsigned operation: // r1 := 255 // r2 := 0 // expected result is 255 sub.8 r2, r1, r3 ; r3 = 255 (aka -1) abs.8 r3, r4 ; r4 = 1 (WRONG) minmax.8 r2, r1, r4 ; r4 = 0, r5 = 255 sub.8 r4, r5, r6 ; r6 = 255 (CORRECT) Surprised? > The SAD is in fact doing 3 things : minus, absolute and finally the > parallel addition. > BTW, i have seen instruction sets with the 2 first operations but NEVER > with the parallel > addition. AltiVec has `vector sum' instructions (although they're limited to saturated adds, AFAIK). [...] > >The byte (or chunk) adder will also be useful in vector computations. > > > for what kinds of algorithms ??? All of them. The four most common vector operations are: - Add/Sub: Y(i) = A(i) ± B(i) ; sadd / ssub - Scale: Y(i) = r * A(i) ; sdup + smul - Scalar Product: y = sum(A(i) * B(i)) ; smul + chunk-add Additionally, the chunk-add instruction will be used several times in every matrix and matrix/vector multiplication: Remember that the product of two n-order square matrices is just a collection of n*n scalar products. [...] > >In any case, the chunks of a word can be combined by using `mix': > > > > mix.8 r0, r1, r2 // distributes the chunks across r2 and r3 > > add.16 r2, r3, r1 > > mix.16 r0, r1, r2 > > add.32 r2, r3, r1 > > mix.32 r0, r1, r2 > > add.64 r2, r3, r1 // gotcha! > > > > > :-) Unfortunately, there are a lot of stalls. With a double feedback path, this computation takes 15 cycles, or 18 cycles without it. If there is nothing you can interleave the code with, you'll waste a lot of time. On the other hand, a chunk add (maybe we'd better call it `sum') can be done in approximately 2-3 cycles. > >This will also work with other commutative operations, e.g. mul. A `chunk > >add' insn may be more convenient, however (and will also be much faster). > > > > > probably but not used often enough. As I tried to point out above, it's much more common than a specialized SAD instruction, and also much more general. IMHO it's much better to provide a handful of powerful primitives that can be used to implement a larger set of functions, rather than implementing the functions themselves. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 34ijg.hbqsk@hotmail.com Mon Mar 24 05:48:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xriw-00045H-00 for ; Tue, 25 Mar 2003 17:56:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 25 Mar 2003 17:56:30 +0100 (CET) Received: (qmail 19323 invoked by uid 0); 24 Mar 2003 05:13:25 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 24 Mar 2003 05:13:25 -0000 Received: by moria.seul.org (Postfix) id 6A9DD33C09; Mon, 24 Mar 2003 00:13:23 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1472633C1A; Mon, 24 Mar 2003 00:13:22 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from vallelys01.Vallelys.local (ip02.vallelys.adsl.gxn.net [195.147.238.226]) by moria.seul.org (Postfix) with SMTP id 7801133C09 for ; Mon, 24 Mar 2003 00:13:20 -0500 (EST) Received: FROM 162.122.138.129 BY vallelys01.Vallelys.local ; Mon Mar 24 04:54:49 2003 0000 From: =?Big5?B?t3zByL/6?= <34ijg.hbqsk@hotmail.com> Subject: [f-cpu] =?Big5?B?ofCh8Lx4qMa3fqZYp0C52abxofGh8Q==?= To: =?Big5?B?t1GmqKVc?= Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; charset="BIG-5" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Mar 2003 12:48:53 +0800 X-Priority: 2 X-Library: Indy 9.00.10 X-Mailer:Dynamailer V 8.0 X-MimeOLE:Produced By Mircosoft MimeOLE V6.00.2600.0000 Message-Id: <20030324051320.7801133C09@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable charset="BIG-5" --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: 7bit charset="BIG-5"

 ¦p¦³¥´ÂZ¦b¦¹­P¤W¸U¤Àºp·N¡F¤£Ä@¦¬¨ì¦¹«HªÌ¡F½Ð¦^¯u¹êe-mail§Ú¤~¯à­ç°£¡F¤U¦¸´N¤£·|¦A±H¨ì§A¨º£{¡F½Ð§O¦A½|§Ú£{¡AÁÂÁ§A¡C

¸Û¼x¡G1¡B·Q¶}«K§Q¶W°ÓªÌ¡F2¡B·Q°µ¤H¤O²Õ´³Æ¼W¨Æ·~ªÌ¡F3¡B·Q»P¥»¤½¥qµ²·ù¨É¦³§K¶O¼s§iªÌ

¡]¤@¡^¡B¦pªG»¡¦³~¤@¥÷¨Æ·~¸êª÷ ©±­± ±À¾P °e³f ¦¬±b§y³f ­·ÀI ·~ÁZ³q³q¤£¥Î~¼Ë¼Ë¤£»Ý§V¤O¸gÀç6-12­Ó¤ë´N¯à¾Ö¦³5-10¸U¤¸«ùÄò©Êªº²×¥Í¦¬¤J³o»ò¦nªº¾÷·|±z¤£¨Ó¸Õ¸Õ¶Ü¡H¼x¥þ¬Ù¥´«÷¹Ù¦ñ¡C

¡]¤G¡^¡B¦pªG±q«K§Q°Ó©±¥X¨Ó£x¤H¡F³£¸ò±z¦³Ãö«Y¡C¥Ø«e¥þ¬Ù¤w¦³40®a©±­±¡F±z¤£¥²¥XºÞ¾P¡F¨C®a10¤H´N¦n£{¡F10¤H*40¤¸(´N¹³¹L¸ô¶O)*40®a=16000¤¸³o¼Ë£x¦¬¤J¡C¤£­n±z£x¥[·ùª÷»P«OÃÒª÷¡F¥u­n±z®ã¦ÌªoÆQÂæ¾L¯ù´«£|¦a¤è®ø¶O³º¤]¥i¥H¨Ó·í³sÂê¶W°Ó£x¦ÑÁó¡C

¡]¤T¡^¡B¥Ø«eÁÙ¦³400¦h®aµ²·ù©±¡]¦U¦æ·~³£¦³¡^­¹¡B¦ç¡B¦í¡B¦æ¡B¨|¡B¼Ö¼Ë¼Ë»ô¥þ¡F³£¸ò±z¦³Ãö«Y¡C

¥þ¥ÁÁp¦X³q¸ô¨Æ·~

§Ú­n¯Á¨ú§K¶Oªº³Ð·~¥úºÐ 

¤¤¤å©m¦W

 

©Ê§O

  

¦~ÄÖ

·³(18·³¥H¤W) 

Ápµ¸¹q¸Ü

¦ æ°Ê¹q¸Ü

 

¦a§}

¹q¤l¶l¥ó

--=_NextPart_2rfkindysadvnqw3nerasdf-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From shin0858@sinamail.com Mon Mar 24 06:28:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xriz-00045H-00 for ; Tue, 25 Mar 2003 17:56:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 25 Mar 2003 17:56:33 +0100 (CET) Received: (qmail 21502 invoked by uid 0); 24 Mar 2003 05:28:43 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 24 Mar 2003 05:28:43 -0000 Received: by moria.seul.org (Postfix) id CD4B333C0F; Mon, 24 Mar 2003 00:28:41 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1349733C22; Mon, 24 Mar 2003 00:28:41 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from w8k2x7 (252.c170.ethome.net.tw [202.178.170.252]) by moria.seul.org (Postfix) with SMTP id BFC7A33C0F for ; Mon, 24 Mar 2003 00:28:33 -0500 (EST) Received: from hotmail by yahoo.com with SMTP id jlZyWtNU8qA9v0IMS3oBq1hBjMhz; Mon, 24 Mar 2003 13:28:34 +0800 Message-ID: <4qaS7DKWXYdZ@kimo.com> From: shin0858@sinamail.com To: 123@seul.org Subject: [f-cpu] =?big5?Q?=A4=A3=A5=B2=C0=B4=A4@=A4j=B0=EF=B1M=B7~=AA=BE=C3=D1?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_0AXiWhQmiSPIQZ4tp" X-Mailer: I6cDk73xHixidiLlZc5O2 X-Priority: 3 X-MSMail-Priority: Normal Date: Mon, 24 Mar 2003 00:28:33 -0500 (EST) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format. ------=_NextPart_0AXiWhQmiSPIQZ4tp Content-Type: multipart/alternative; boundary="----=_NextPart_0AXiWhQmiSPIQZ4tpAA" ------=_NextPart_0AXiWhQmiSPIQZ4tp Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBl IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1CaWc1Ij4NCjxtZXRhIG5hbWU9UHJvZ0lkIGNv bnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSIuL3NoaW44OEAxNjMuY29tLmZpbGVz L2ZpbGVsaXN0LnhtbCI+DQo8bGluayByZWw9RWRpdC1UaW1lLURhdGEgaHJlZj0iLi9zaGluODhA MTYzLmNvbS5maWxlcy9lZGl0ZGF0YS5tc28iPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZc Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOkRvY3VtZW50UHJvcGVydGllcz4NCiAgPG86QXV0aG9y PkFBQTwvbzpBdXRob3I+DQogIDxvOlRlbXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAgPG86 TGFzdEF1dGhvcj5BQUE8L286TGFzdEF1dGhvcj4NCiAgPG86UmV2aXNpb24+ODwvbzpSZXZpc2lv bj4NCiAgPG86VG90YWxUaW1lPjM8L286VG90YWxUaW1lPg0KICA8bzpDcmVhdGVkPjIwMDItMTEt MjZUMTg6MTc6MDBaPC9vOkNyZWF0ZWQ+DQogIDxvOkxhc3RTYXZlZD4yMDAzLTAzLTI0VDAyOjEz OjAwWjwvbzpMYXN0U2F2ZWQ+DQogIDxvOlBhZ2VzPjE8L286UGFnZXM+DQogIDxvOldvcmRzPjEy MTwvbzpXb3Jkcz4NCiAgPG86Q2hhcmFjdGVycz42OTE8L286Q2hhcmFjdGVycz4NCiAgPG86TGlu ZXM+NTwvbzpMaW5lcz4NCiAgPG86UGFyYWdyYXBocz4xPC9vOlBhcmFncmFwaHM+DQogIDxvOkNo YXJhY3RlcnNXaXRoU3BhY2VzPjg0ODwvbzpDaGFyYWN0ZXJzV2l0aFNwYWNlcz4NCiAgPG86VmVy c2lvbj45LjI4MTI8L286VmVyc2lvbj4NCiA8L286RG9jdW1lbnRQcm9wZXJ0aWVzPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0K ICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJp bGl0eT4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8 IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTq3 c7LTqfrF6TsNCglwYW5vc2UtMToyIDIgMyAwIDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDpQ TWluZ0xpVTsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 MSAxMzQ3NDIwMTYgMTYgMCAxMDQ4NTc2IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi tdixZLLTturF6VwoUFwpIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0KCW1zby1m b250LWFsdDq3c7LTqfrF6TsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0 Y2g6YXV0bzsNCgltc28tZm9udC1zaWduYXR1cmU6MSAxMzQ3NDIwMTYgMTYgMCAxMDQ4NTc2IDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEC3c7LTqfrF6SI7DQoJcGFub3NlLTE6MiAy IDMgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6MSAxMzQ3NDIwMTYgMTYgMCAxMDQ4NTc2IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEC12LFkstO26sXpXChQXCkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAw IDA7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9t YW47DQoJbXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmF1dG87DQoJbXNv LWZvbnQtc2lnbmF0dXJlOjEgMTM0NzQyMDE2IDE2IDAgMTA0ODU3NiAwO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpwDQoJ e21hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndp ZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OrdzstOp+sXpOw0K CW1zby1oYW5zaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQogLyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBh Z2UNCgl7bXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5kLWhlYWRlcjpubzsNCgltc28tcGFnZS1ib3Jk ZXItc3Vycm91bmQtZm9vdGVyOm5vO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4 NDEuOXB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7DQoJbXNvLWhlYWRl ci1tYXJnaW46NDIuNTVwdDsNCgltc28tZm9vdGVyLW1hcmdpbjo0OS42cHQ7DQoJbXNvLXBhcGVy LXNvdXJjZTowO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHls ZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQoNCjxib2R5IGxhbmc9WkgtVFcgc3R5bGU9J3RhYi1pbnRlcnZhbDoyNC4wcHQnPg0K DQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KbXNvLXBhZ2luYXRp b246bm9uZTtsYXlvdXQtZ3JpZC1tb2RlOmNoYXI7bXNvLWNoYXItaW5kZW50LXNpemU6MTJwdCc+ pnCms6W0wlqmYqa5rVCkV7hVpMC6cLdOoUako8RApqyo7Ka5q0iqzKFGPHNwYW4NCnN0eWxlPSdj b2xvcjpyZWQnPr3Qpl6vdbnqPHNwYW4gbGFuZz1FTi1VUz5lLW1haWyn2qR+r+Ct57CjPC9zcGFu Pjwvc3Bhbj6hRqRVpri0TqSjt3ymQbFIqOynQai6o3uhRjxzcGFuDQpzdHlsZT0nY29sb3I6Ymxh Y2snPr3Qp0+mQb18p9qje6FBwcLBwqdBoUM8c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9 J3RleHQtYWxpZ246Y2VudGVyO21zby1wYWdpbmF0aW9uOm5vbmU7DQpsYXlvdXQtZ3JpZC1tb2Rl OmNoYXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox Mi4wcHQ7DQpjb2xvcjpyZWQnPrjbvHihRzxzcGFuIGxhbmc9RU4tVVM+MaFCt1G2fatLp1G2V7DT qsyhRjKhQrdRsLWkSKRPstXCtLPGvFeoxrd+qsyhRjOhQrdRu1Clu6S9pXG1srf5qMmms6dLtk+8 c6dpqsw8L3NwYW4+PC9zcGFuPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp3aGl0ZTtt c28tZm9udC1rZXJuaW5nOjEuMHB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQptYXJnaW4tbGVmdDo0OC4wcHQ7dGV4dC1pbmRlbnQ6LTQ4LjBwdDttc28t Y2hhci1pbmRlbnQtY291bnQ6LTQuMDttc28tY2hhci1pbmRlbnQtc2l6ZToNCjEyLjBwdDtsYXlv dXQtZ3JpZC1tb2RlOmNoYXI7bXNvLWNoYXItaW5kZW50LXNpemU6MTJwdCc+oV2kQKFeoUKmcKpH u6GmszxzcGFuDQpsYW5nPUVOLVVTPn48c3BhbiBzdHlsZT0nY29sb3I6cmVkJz6kQKX3qMa3fjwv c3Bhbj646qr3IKmxrbEgscC+UCCwZbNmIKassWKnebNmIK23wEkgt37BWrNxs3Gko6XOfrzLvMuk o7vdPHNwYW4NCnN0eWxlPSdjb2xvcjpyZWQnPqdWpE+4Z8DnNi0xMq3TpOs8L3NwYW4+tE6v4L7W prM8c3BhbiBzdHlsZT0nY29sb3I6cmVkJz41LTEwuFWkuKv5xPKpyqq6stelzaaspEo8L3NwYW4+ s2+78qZuqrq+97d8sXqko6jTuNW41bbcoUi8eKX+rNmltKv3udmm8aFDDQo8dTE6cD48L3UxOnA+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KbWFyZ2luLWxl ZnQ6NDguMHB0O3RleHQtaW5kZW50Oi00OC4wcHQ7bXNvLWNoYXItaW5kZW50LWNvdW50Oi00LjA7 bXNvLWNoYXItaW5kZW50LXNpemU6DQoxMi4wcHQ7bGF5b3V0LWdyaWQtbW9kZTpjaGFyO21zby1j aGFyLWluZGVudC1zaXplOjEycHQnPqFdpEehXqFCpnCqR7Fxq0unUbDTqbGlWKjTo3ikSKFGs6O4 8rF6prPD9qtZoUM8c3Bhbg0Kc3R5bGU9J2NvbG9yOmZ1Y2hzaWEnPqXYq2Wl/qzZpHemszxzcGFu IGxhbmc9RU4tVVM+NDCuYamxrbE8L3NwYW4+PC9zcGFuPqFGsXqko6WypVi63r5QoUaoQ65hPHNw YW4NCmxhbmc9RU4tVVM+MTCkSLROpm6je6FGMTCkSCo0MKS4KLROubO5TLj0tk8pKjQwrmE9PHNw YW4gc3R5bGU9J2NvbG9yOmZ1Y2hzaWEnPjE2MDAwpLizb7zLo3imrKRKoUM8L3NwYW4+pKOtbrF6 o3ilW7f5qve7UKtPw9Kq96FGpXWtbrF6ruOmzKpvxlHC5r5Mr/m0q6N8pmGk6K74tk+zuqRdpWml SKjTt+08c3Bhbg0Kc3R5bGU9J2NvbG9yOmZ1Y2hzaWEnPrNzwuq2V7DTo3im0cHzoUM8L3NwYW4+ IDwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQpsYXlvdXQtZ3JpZC1tb2RlOmNo YXInPqFdpFShXqFCPHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz6l2Ktlwdk8L3NwYW4+prM8c3Bh bg0KbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6Ymx1ZSc+NDAwpmiuYbWyt/mpsTwvc3Bhbj6hXaZV pua3frOjprOhXq25oUKm56FCpu2hQqbmoUKofKFCvNa8y7zLu/Sl/qFGPHNwYW4NCnN0eWxlPSdj b2xvcjpibHVlJz6zo7jysXqms8P2q1mhQzx1MTpwPjwvdTE6cD48L3NwYW4+PC9wPg0KDQo8Zm9y bSBhY3Rpb249Im1haWx0bzpzaGluODhAMTYzLmNvbT9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2 V7DTqMa3frnOtqQiIG1ldGhvZD1wb3N0DQplbmN0eXBlPSJ0ZXh0L3BsYWluIj4NCg0KPHAgYWxp Z249Y2VudGVyIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWFs aWduOmNlbnRlcic+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MjQuMHB0O21zby1hc2NpaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpmdWNoc2lhOw0KbXNvLWZvbnQta2Vy bmluZzoxLjBwdDttc28tYW5zaS1sYW5ndWFnZTpaSC1UVyc+pf6lwTwvc3Bhbj48L2I+PGI+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MjQuMHB0O21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjtjb2xvcjpmdWNoc2lhOw0KbXNvLWZvbnQta2VybmluZzoxLjBwdCc+wXCmWLNx uPQ8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MjQuMHB0Ow0KbXNvLWFzY2lp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOmZ1Y2hzaWE7bXNvLWZvbnQta2Vy bmluZzoxLjBwdDsNCm1zby1hbnNpLWxhbmd1YWdlOlpILVRXJz6oxrd+PC9zcGFuPjwvYj48L3A+ DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0nbWFyZ2luLXRvcDo0LjVwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NC41cHQ7DQptYXJnaW4tbGVmdDowY207dGV4dC1hbGlnbjpjZW50 ZXI7bGluZS1oZWlnaHQ6MjAwJSc+PGI+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6IrXYsWSy07bqxelcKFBcKSI7Y29sb3I6Ymx1ZSc+PElOUFVU IFRZUEU9ImNoZWNrYm94IiBOQU1FPSKn2q1ur8Go+qdLtk+qurPQt36l+rrQIiBWQUxVRT0ivdCn 1qRAwkkiPjwvc3Bhbj48L2I+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTMuNXB0O2NvbG9y OnJlZCc+p9qtbq/BqPqnS7ZPqrqz0Ld+pfq60Dwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz1FTi1V Uw0Kc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 bXNvLWFzY2lpLWZvbnQtZmFtaWx5Og0Kt3Oy06n6xek7Y29sb3I6cmVkJz4mbmJzcDs8dTE6cD48 L3UxOnA+PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHRhYmxlIGJvcmRlcj0xIGNlbGxzcGFjaW5nPTEgY2VsbHBhZGRpbmc9MCB3aWR0aD00OTgg c3R5bGU9J3dpZHRoOjM3My4ycHQ7DQogbXNvLWNlbGxzcGFjaW5nOi43cHQ7bWFyZ2luLWxlZnQ6 OTcuMXB0O21zby1wYWRkaW5nLWFsdDowY20gMGNtIDBjbSAwY20nDQogaGVpZ2h0PTE+DQogPHRy IHN0eWxlPSdoZWlnaHQ6MTUuMHB0Jz4NCiAgPHRkIHdpZHRoPTg4IHN0eWxlPSd3aWR0aDo2Ni4x NXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0Og0KICAxNS4wcHQnIGJv cmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5 O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgnPjxiPjxzcGFuDQogIHN0eWxlPSdjb2xvcjoj NjY5OTMzJz6kpKTlqW2mVzwvc3Bhbj48L2I+IDxzcGFuIGxhbmc9RU4tVVM+PHUxOnA+PC91MTpw PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPTQwNyBzdHlsZT0n d2lkdGg6MzA0Ljk1cHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0 OjE1LjBwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2NvbG9yOnllbGxvdyc+PElOUFVUIFRZUEU9InRleHQiIFNJWkU9IjE0IiBOQU1F PSKkpKTlqW2mVyI+PC9zcGFuPjxzcGFuDQogIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO21zby1hc2NpaS1mb250LWZhbWlseTq3c7LTqfrF6TsNCiAgY29s b3I6eWVsbG93Jz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz4gPC9zcGFuPjwvcD4NCiAg PC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0Oi43NXB0Jz4NCiAgPHRkIHdpZHRoPTg4 IHN0eWxlPSd3aWR0aDo2Ni4xNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVp Z2h0Og0KICAuNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQogIHRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoO21zby1saW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxiPjxzcGFuDQogIHN0eWxlPSdjb2xvcjoj NjY5OTMzJz6pyqdPPC9zcGFuPjwvYj4gPHNwYW4gbGFuZz1FTi1VUz48dTE6cD48L3UxOnA+PG86 cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NDA3IHN0eWxlPSd3aWR0 aDozMDQuOTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1 cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0nbXNvLWxpbmUtaGVp Z2h0LWFsdDouNzVwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48U0VM RUNUIE5BTUU9IqnKp08iPg0KPE9QVElPTiBTRUxFQ1RFRD690L/vvtwNCjxPUFRJT04+qGsNCjxP UFRJT04+pGsNCjwvU0VMRUNUPjwvc3Bhbj48c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjttc28tYXNjaWktZm9udC1mYW1pbHk6t3Oy06n6xek7 DQogIGNvbG9yOnllbGxvdyc+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+IDwv c3Bhbj48L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdodDouNzVwdCc+DQog IDx0ZCB3aWR0aD04OCBzdHlsZT0nd2lkdGg6NjYuMTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0O2hlaWdodDoNCiAgLjc1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0K ICA8cCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGg7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAgLjc1cHQnPjxiPjxzcGFuIHN0eWxlPSdjb2xvcjoj NjY5OTMzJz6mfsTWPC9zcGFuPjwvYj4gPHNwYW4gbGFuZz1FTi1VUz48dTE6cD48L3UxOnA+PG86 cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NDA3IHN0eWxlPSd3aWR0 aDozMDQuOTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1 cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0nbXNvLWxpbmUtaGVp Z2h0LWFsdDouNzVwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48SU5Q VVQgVFlQRT0idGV4dCIgU0laRT0iNCIgTkFNRT0ipn7E1iI+PC9zcGFuPjxiPjxzcGFuDQogIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOiM2Njk5MzMnPrezPHNwYW4gbGFuZz1FTi1VUz4o MTi3s6VIpFcpPC9zcGFuPjwvc3Bhbj48L2I+PGI+PHNwYW4NCiAgbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjttc28tYXNjaWkt Zm9udC1mYW1pbHk6DQogILdzstOp+sXpO2NvbG9yOiM2Njk5MzMnPiZuYnNwOzwvc3Bhbj48L2I+ PHNwYW4gbGFuZz1FTi1VUz4gPC9zcGFuPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHls ZT0naGVpZ2h0Oi43NXB0Jz4NCiAgPHRkIHdpZHRoPTg4IHN0eWxlPSd3aWR0aDo2Ni4xNXB0O3Bh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0Og0KICAuNzVwdCcgYm9yZGVyY29s b3JsaWdodD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1q dXN0aWZ5OmludGVyLWlkZW9ncmFwaCc+PGI+PHNwYW4NCiAgc3R5bGU9J2NvbG9yOiM2Njk5MzMn PsFwtbi5cbjcIDwvc3Bhbj48L2I+PC9wPg0KICA8cCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5 O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAgLjc1 cHQnPjxiPjxzcGFuIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6m5rDKuXG43Dwvc3Bhbj48L2I+IDxz cGFuIGxhbmc9RU4tVVM+PHUxOnA+PC91MTpwPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90 ZD4NCiAgPHRkIHdpZHRoPTQwNyBzdHlsZT0nd2lkdGg6MzA0Ljk1cHQ7cGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4 MDgwIj4NCiAgPHAgc3R5bGU9J21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbToyLjI1cHQ7bWFyZ2luLWxlZnQ6DQogIDBjbTtsaW5lLWhlaWdodDoxNTAlJz48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBFPSJ0ZXh0IiBT SVpFPSIxNCIgTkFNRT0iwXC1uLlxuNwtpdWk0SI+PC9zcGFuPjxzcGFuDQogIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO21zby1hc2NpaS1mb250LWZhbWls eTq3c7LTqfrF6TsNCiAgY29sb3I6eWVsbG93Jz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1V Uz4gPC9zcGFuPjwvcD4NCiAgPHAgc3R5bGU9J21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbToyLjI1cHQ7bWFyZ2luLWxlZnQ6DQogIDBjbTttc28tbGluZS1o ZWlnaHQtYWx0Oi43NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJ TlBVVCBUWVBFPSJ0ZXh0IiBTSVpFPSIxNCIgTkFNRT0iwXC1uLlxuNwtpu2uYSI+PC9zcGFuPjwv cD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0OjE4LjBwdCc+DQogIDx0ZCB3 aWR0aD04OCBzdHlsZT0nd2lkdGg6NjYuMTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0O2hlaWdodDoNCiAgMTguMHB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAg c3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoJz48 Yj48c3Bhbg0KICBzdHlsZT0nY29sb3I6IzY2OTkzMyc+pmGnfTwvc3Bhbj4gPC9iPjxzcGFuIGxh bmc9RU4tVVM+PHUxOnA+PC91MTpwPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiAg PHRkIHdpZHRoPTQwNyBzdHlsZT0nd2lkdGg6MzA0Ljk1cHQ7cGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdDsNCiAgaGVpZ2h0OjE4LjBwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+ DQogIDxwPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnllbGxvdyc+PElOUFVUIFRZUEU9 InRleHQiIFNJWkU9IjQ5IiBOQU1FPSKmYad9Ij48L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwvdHI+ DQogPHRyIHN0eWxlPSdoZWlnaHQ6MTIuNzVwdCc+DQogIDx0ZCB3aWR0aD04OCBzdHlsZT0nd2lk dGg6NjYuMTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoNCiAgMTIu NzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSd0ZXh0LWFsaWdu Omp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCc+PGI+PHNwYW4NCiAgc3R5bGU9 J2NvbG9yOiM2Njk5MzMnPrlxpGy2bKXzPC9zcGFuPjwvYj4gPHNwYW4gbGFuZz1FTi1VUz48dTE6 cD48L3UxOnA+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NDA3 IHN0eWxlPSd3aWR0aDozMDQuOTVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0K ICBoZWlnaHQ6MTIuNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnllbGxvdyc+PElOUFVUIFRZUEU9InRleHQiIFNJWkU9 IjQ5IiBOQU1FPSK5caRstmyl8yI+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJs ZT4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSdtYXJnaW4tdG9wOjIuMjVwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206Mi4yNXB0Ow0KbWFyZ2luLWxlZnQ6MGNtO3RleHQtYWxpZ246 Y2VudGVyO2xpbmUtaGVpZ2h0OjE1MCUnPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdjb2xvcjoj NjYwMENDJz48SU5QVVQgVFlQRT0ic3VibWl0IiBBQ1RJT049Im1haWx0bzpzaGluODhAMTYzLmNv bT9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIFZBTFVFPSKn2q1upVukSqjG t36l66bxoUGwZaVYuOquxiIgRU5DVFlQRT0idGV4dC9wbGFpbiIgTUVUSE9EPSJwb3N0IiBOQU1F PSK9VLt7Ig0KQUNUSU9OPSJtYWlsdG86c2hpbjg4QDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+ pcGzc8Lqtlew06jGt365zrakIiBFTkNUWVBFPSJ0ZXh0L3BsYWluIg0KTUVUSE9EPXBvc3QgQUNU SU9OPSJtYWlsdG86c2hpbjg4QDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lqtlew06jG t365zrakIg0KRU5DVFlQRT0idGV4dC9wbGFpbiIgTUVUSE9EPXBvc3QNCkFDVElPTj0ibWFpbHRv OnNoaW44OEAxNjMuY29tP3N1YmplY3Q9p9qtbrDRpVul/qXBs3PC6rZXsNOoxrd+uc62pCIgRU5D VFlQRT0idGV4dC9wbGFpbiINCk1FVEhPRD1wb3N0IEFDVElPTj0ibWFpbHRvOnNoaW44OEAxNjMu Y29tP3N1YmplY3Q9p9qtbrDRpVul/qXBs3PC6rZXsNOoxrd+uc62pCINCkVOQ1RZUEU9InRleHQv cGxhaW4iIE1FVEhPRD1wb3N0DQpBQ1RJT049Im1haWx0bzpzaGluODhAMTYzLmNvbT9zdWJqZWN0 PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIEVOQ1RZUEU9InRleHQvcGxhaW4iDQpNRVRI T0Q9cG9zdCBBQ1RJT049Im1haWx0bzpzaGluODhAMTYzLmNvbT9zdWJqZWN0PafarW6w0aVbpf6l wbNzwuq2V7DTqMa3frnOtqQiDQpFTkNUWVBFPSJ0ZXh0L3BsYWluIiBNRVRIT0Q9cG9zdA0KQUNU SU9OPSJtYWlsdG86c2hpbjg4QDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lqtlew06jG t365zrakIiBFTkNUWVBFPSJ0ZXh0L3BsYWluIg0KTUVUSE9EPXBvc3Q+PElOUFVUIFRZUEU9InJl c2V0IiBWQUxVRT0irau28SIgTkFNRT0irau28SI+PC9zcGFuPjwvcD4NCg0KPC9mb3JtPg0KDQo8 L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ ------=_NextPart_0AXiWhQmiSPIQZ4tp ------=_NextPart_0AXiWhQmiSPIQZ4tp-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From glenalec@shoalhaven.net.au Tue Mar 25 05:21:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xrjz-00045H-00 for ; Tue, 25 Mar 2003 17:57:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 25 Mar 2003 17:57:35 +0100 (CET) Received: (qmail 19941 invoked by uid 0); 25 Mar 2003 04:21:21 -0000 Received: from moria.mit.edu (HELO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 25 Mar 2003 04:21:21 -0000 Received: by moria.seul.org (Postfix) id 6050D33B84; Mon, 24 Mar 2003 23:21:19 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80C4933C54; Mon, 24 Mar 2003 23:21:18 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from hallie.shoalhaven.net.au (hallie.shoalhaven.net.au [202.139.20.1]) by moria.seul.org (Postfix) with ESMTP id 95D7833B84 for ; Mon, 24 Mar 2003 23:21:17 -0500 (EST) Received: from hallie.shoalhaven.net.au (localhost.shoalhaven.net.au [127.0.0.1]) by hallie.shoalhaven.net.au (8.12.8/8.12.8) with ESMTP id h2P4LHNg062898 for ; Tue, 25 Mar 2003 15:21:17 +1100 (EST) Received: (from nobody@localhost) by hallie.shoalhaven.net.au (8.12.8/8.12.8/Submit) id h2P4LHVt062897; Tue, 25 Mar 2003 15:21:17 +1100 (EST) Date: Tue, 25 Mar 2003 15:21:17 +1100 (EST) Message-Id: <200303250421.h2P4LHVt062897@hallie.shoalhaven.net.au> X-Authentication-Warning: hallie.shoalhaven.net.au: nobody set sender to glenalec@shoalhaven.net.au using -f From: "Glenn Alexander" To: f-cpu@seul.org Subject: [f-cpu] Placing better status info on home page X-Mailer: NeoMail 1.25 X-IPAddress: 202.199.102.12 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi I was wondering if some up-to-date ststus info could be added (in a prominant place) to fcpu.org, so uninvolved-but-interested people like me don't have to hunt around so much for a quick progress overview? I am thinking along the lines of the image at http://www.f-cpu.seul.org/new/FC0-02_07_2002.gif (which is the most up-to-date I could find. Just something quick and general to give a crude idea, no need to waste lots of time that can be better spent on designing the actual device(s). Regards, glenalec. PS. Excellent work, people. I'm sticking with horrible, horrible (but cheap and readily avaliable) IA32 for now in the hope that in a few years, when I go 64-bit, it can be to a F-CPU! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From soft123@emailacc.com Tue Mar 25 15:00:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18xrkB-00045H-00 for ; Tue, 25 Mar 2003 17:57:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 25 Mar 2003 17:57:47 +0100 (CET) Received: (qmail 27571 invoked by uid 65534); 25 Mar 2003 14:02:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 25 Mar 2003 15:02:35 +0100 Received: by moria.seul.org (Postfix) id 8AD0B33C5D; Tue, 25 Mar 2003 09:02:31 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B3F8133C61; Tue, 25 Mar 2003 09:02:29 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id C0CAC33C5D for ; Tue, 25 Mar 2003 09:02:29 -0500 (EST) Received: from 79.00.47.25 (f-tokyo-135129.zero.ad.jp [211.130.135.129]) by bettik.munge.net (Postfix) with SMTP id ED4224F763 for ; Tue, 25 Mar 2003 08:02:49 -0600 (CST) From: soft123 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?PC=83\=83t=83g=8C=83=88=C0=94=CC=94=84=81I=81I=81I?= Date: Tue, 25 Mar 2003 23:00:49 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="508ce5df-24f1-48f6-b2fa-811764b57b31" Message-Id: <20030325140249.ED4224F763@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --508ce5df-24f1-48f6-b2fa-811764b57b31 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =92=86=8C=C3=83r=83W=83l=83X=83\=83t=83g=94=CC=94=84! =90l=8BC=8F=A4=95i=82=BE=82=AF=82=F0=8FW=82=DF=82=C4=83Z=83b=83g=94=CC=94=84= =82=A2=82=BD=82=B5=82=DC=82=B7 http://softsoft0.www2.dotnetplayground.com http://www.kurthost.net/softsoft/ http://www.online.in.th/softsoft/cd/ http://softsoft.flashmaster.ru http://www.duno.com/softsoft/index.html http://softsoft.erospace.pl/ --508ce5df-24f1-48f6-b2fa-811764b57b31-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Mar 28 00:25:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18yo6S-0000H1-00 for ; Fri, 28 Mar 2003 08:16:40 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 28 Mar 2003 08:16:40 +0100 (CET) Received: (qmail 12840 invoked by uid 65534); 27 Mar 2003 23:29:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 28 Mar 2003 00:29:22 +0100 Received: by moria.seul.org (Postfix) id 2C85833C7C; Thu, 27 Mar 2003 18:29:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EC83E33C68; Thu, 27 Mar 2003 18:29:20 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a138.home.uni-hannover.de [130.75.232.138]) by moria.seul.org (Postfix) with ESMTP id E2DB633B60 for ; Thu, 27 Mar 2003 18:29:18 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02648; Fri, 28 Mar 2003 00:25:40 +0100 Message-ID: <20030328002540.37128@thrai.stud.uni-hannover.de> Date: Fri, 28 Mar 2003 00:25:40 +0100 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New VHDL Stuff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi F-gang! I'm going to upload my latest sources to seul.org tonight; look for http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20030327.tar.gz. As I already mentioned, there are new INC and CMP units. I also improved the adders in EU_ASU and EU_IMU, and added new functions to the ASU and SHL units (see the list of changes below). While playing with the multiplier again, I noticed that it may be possible to integrate a `scalar product' function without increasing the latency of the unit. That function would multiply its operands in SIMD mode, delivering double-width temporary results, and then add all the temporary results and produce a 128-bit sum, with only minimal hardware overhead. The latency will be 6 cycles regardless of the chunk size, with chunk sizes of 8...64 bits supported (in 64-bit mode, the function is identical to `mulh'). I don't know if it will support signed multiplications, but I guess it should be possible. Does that sound useful? I believe it may be an alternative to mac/amac in some cases. Changes: * eu_asu/iadd.vhdl: - auto-sizing unit (WIDTH must be a multiple of 64) - new increment-and-add and average operations - improved adder stages * eu_asu/iatest7.vhdl: - new (faster) testbench for iadd.vhdl * eu_imu/imul64.vhdl: - improved adder stages - 8/16/32/64 bit timing is now 3/4/5/6 cycles for both outputs * eu_imu/im64test4.vhdl: - additional testbench for imul64.vhdl * eu_imu/im64testconf.vhdl: - configuration file for IMU testbenches * eu_shl/shuffle64.vhdl: - fixed bitrev operation - added permute and cshift functions * eu_cmp/*: - new integer compare unit (handles cmp/min/max/msb0/msb1) - auto-sizing unit (WIDTH must be a multiple of 64) * eu_inc/*: - new integer increment unit (handles inc/dec/neg/abs/lsb0/lsb1) - auto-sizing unit (WIDTH must be a multiple of 64) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Fri Mar 28 18:12:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18yz7z-0000Km-01 for ; Fri, 28 Mar 2003 20:02:59 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 28 Mar 2003 20:02:59 +0100 (CET) Received: (qmail 18621 invoked by uid 65534); 28 Mar 2003 13:12:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 28 Mar 2003 14:12:58 +0100 Received: by moria.seul.org (Postfix) id 03DB933B55; Fri, 28 Mar 2003 08:12:55 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 31D9433C75; Fri, 28 Mar 2003 08:12:54 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 1940933B55 for ; Fri, 28 Mar 2003 08:12:53 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by kraid.nerim.net (Postfix) with SMTP id AB88D40F52 for ; Fri, 28 Mar 2003 14:12:51 +0100 (CET) To: Subject: register size (was :Re: [f-cpu] New VHDL Stuff) From: Date: Fri, 28 Mar 2003 14:12:52 CET X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030328131251.AB88D40F52@kraid.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe a écrit : > Hi F-gang! > <...> > * eu_asu/iadd.vhdl: > - auto-sizing unit (WIDTH must be a multiple of 64) What do you means by this ? You're unit could handle 128 bits integer number ? ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Mar 29 00:25:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zE08-0002Co-00 for ; Sat, 29 Mar 2003 11:55:52 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 29 Mar 2003 11:55:52 +0100 (CET) Received: (qmail 715 invoked by uid 65534); 28 Mar 2003 23:25:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 29 Mar 2003 00:25:54 +0100 Received: by moria.seul.org (Postfix) id 0368933C82; Fri, 28 Mar 2003 18:25:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 12ECE33C25; Fri, 28 Mar 2003 18:25:49 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a059.home.uni-hannover.de [130.75.232.59]) by moria.seul.org (Postfix) with ESMTP id 1CA2233B4D for ; Fri, 28 Mar 2003 18:25:47 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02284; Sat, 29 Mar 2003 00:25:45 +0100 Message-ID: <20030329002545.26023@thrai.stud.uni-hannover.de> Date: Sat, 29 Mar 2003 00:25:45 +0100 From: Michael Riepe To: f-cpu@seul.org Subject: Re: register size (was :Re: [f-cpu] New VHDL Stuff) References: <20030328131251.AB88D40F52@kraid.nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <20030328131251.AB88D40F52@kraid.nerim.net>; from cyrano@nerim.net on Fri, Mar 28, 2003 at 02:12:52PM +0100 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Mar 28, 2003 at 02:12:52PM +0100, cyrano@nerim.net wrote: > Michael Riepe a écrit : > > > Hi F-gang! > > > <...> > > * eu_asu/iadd.vhdl: > > - auto-sizing unit (WIDTH must be a multiple of 64) > > What do you means by this ? You're unit could handle 128 bits integer number ? No, chunk size remains limited to 64 bits (but register size isn't). That is, you can handle two (or four, or eight, or even more) 64-bit numbers at a time. IMHO it doesn't make sense to have 128-bit numbers. For most practical purposes, 32 bits is already close to overkill. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jimmy_ken@hknetmail.com Fri Mar 28 23:58:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zE0B-0002Co-00 for ; Sat, 29 Mar 2003 11:55:55 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 29 Mar 2003 11:55:55 +0100 (CET) Received: (qmail 1054 invoked by uid 65534); 29 Mar 2003 01:46:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 29 Mar 2003 02:46:23 +0100 Received: by moria.seul.org (Postfix) id 6BBCD33C86; Fri, 28 Mar 2003 20:46:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 663BA33C85; Fri, 28 Mar 2003 20:46:20 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 63E3933C25 for ; Fri, 28 Mar 2003 20:46:19 -0500 (EST) Received: from localhst2421.com ([80.179.101.213]) by belegost.mit.edu (8.11.6/8.11.6) with SMTP id h2T1kCE30894 for ; Fri, 28 Mar 2003 20:46:13 -0500 Message-Id: <200303290146.h2T1kCE30894@belegost.mit.edu> From: "JIMMY KEN" To: f-cpu@seul.org Date: Fri, 28 Mar 2003 22:58:16 +0000 Subject: [f-cpu] STRICTLY A PRIVATE BUSINESS PROPOSAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >From the Desk of JIMMY KEN CITIBANK N=2EA=2ENIGERIA #82 ALLEN AVENUE=2CIKEJA=2C LAGOS-NIGERIA=2E TEL=3A234 803 315 2719 Mailling address=3Ajimmy=5Fken=40hknetmail=2Ecom Receiving address=3Ajimmy=5Fken=40pinoymail=2Ecom Dear Sir=2C STRICTLY A PRIVATE BUSINESS PROPOSAL I am Mr=2E JIMMY KEN =2CThe Manager=2C Bills and Exchange at the Foreign Remittance Department of the Citibank N=2EA=2E I am writing this letter to ask for your support and cooperation to carry out this business opportunity in my department=2E We discovered an abandoned sum of $25=2C000=2C000=2E00 =28Twenty Five million United States Dollars only=29 in an account that belongs to one of our foreign customers who died along with his entire family of a wife and two children in November 1997 in a Plane crash=2E Since we heard of his death=2C we have been expecting his next-of-kin to come over and put claims for his money as the heir=2C because we cannot release the fund from his account unless someone applies for claim as the next-of-kin to the deceased as indicated in our banking guidelines=2EUnfortunately=2C neither their family member nor distant relative has ever appeared to claim the said fund=2E Upon this discovery=2C I and other officials in my department have agreed to make business with you and release the total amount into your account as the heir of the fund since no one came for it or discovered he maintained account with our bank=2C otherwise the fund will be returned to the banks treasury as unclaimed fund=2E We have agreed that our ratio of sharing will be as stated thus=3A 15% for you as my foreign partner=2C 70% for us the officials in my department and 15 % for the source of financing all local and foreign expences to be incurred by us and you during the course of this business=2EUpon the successful completion of this transfer=2C I and one of my colleagues will come to your country and mind our share=2E It is from our 70 % we intend to invest in =28estate=29 and import Agricultural Machineries into my country as a way of recycling the fund=2E To commence this transaction=2C we require you to immediately indicate your interest by a return e-mail and enclose private contact telephone number=2C fax number full name and address and your designated bank coordinates to enable us file letter of claim to the appropriate departments for necessary approvals before the transfer can be made=2E Note also=2C this transaction must be kept STRICTLY CONFIDENTIAL because of its nature=2E I look forward to receiving your prompt response=2E Yours faithfully=2C JIMMY KEN CITIBANK N=2EA=2ENIGERIA #82 ALLEN AVENUE=2C IKEJA=2CLAGOS-NIGERIA=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Mar 30 12:59:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zfT6-0005pu-00 for ; Sun, 30 Mar 2003 18:15:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 30 Mar 2003 18:15:36 +0200 (CEST) Received: (qmail 21023 invoked by uid 65534); 30 Mar 2003 11:02:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 30 Mar 2003 13:02:43 +0200 Received: by moria.seul.org (Postfix) id BAD9A33B53; Sun, 30 Mar 2003 06:02:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1434433B7B; Sun, 30 Mar 2003 06:02:40 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 5105133B53 for ; Sun, 30 Mar 2003 06:02:35 -0500 (EST) Received: from a34-137.dialup.iol.cz ([194.228.137.34] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18zaZw-00065g-00 for f-cpu@seul.org; Sun, 30 Mar 2003 13:02:21 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18zaXd-00026M-00 for f-cpu@seul.org; Sun, 30 Mar 2003 12:59:57 +0200 Date: Sun, 30 Mar 2003 12:59:57 +0200 (CEST) From: devik X-X-Sender: To: F-CPU Mailing List Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report In-Reply-To: <20030328002540.37128@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, I tested to synthetize units for relatively cheap Xilinx Spartan xc2s200-5 with 2352 slices. In all tests I used about 100 slices for testing environment. Numbers below are totals with my logic included. ASU: 601 slices, 69 MHz MUL: out of memory (have only 150MB swap in vmware) SHL: recursion detected in 'shift_map' INC: many messages like Signal > is used but never assigned. Tied to value 0. WARNING:Xst:821 - C:/xilinx_webpack/ISEexamples/fcpu/bit_manipulation.vhd (Line 269). Loop body will iterate zero times 258 slices, 128 MHz but I expect problems here CMP the same. Loop body will iterate zero times error can be fixed by adding explicit IF to reduce_or. But other errors :( Probably XST synthetizer can't handle some things. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Fri, 28 Mar 2003, Michael Riepe wrote: > Hi F-gang! > > I'm going to upload my latest sources to seul.org tonight; look for > http://f-cpu.seul.org/~f-cpu/new/fcpu-mr-20030327.tar.gz. > > As I already mentioned, there are new INC and CMP units. I also improved > the adders in EU_ASU and EU_IMU, and added new functions to the ASU and > SHL units (see the list of changes below). > > While playing with the multiplier again, I noticed that it may be possible > to integrate a `scalar product' function without increasing the latency > of the unit. That function would multiply its operands in SIMD mode, > delivering double-width temporary results, and then add all the temporary > results and produce a 128-bit sum, with only minimal hardware overhead. > The latency will be 6 cycles regardless of the chunk size, with chunk > sizes of 8...64 bits supported (in 64-bit mode, the function is identical > to `mulh'). I don't know if it will support signed multiplications, > but I guess it should be possible. Does that sound useful? I believe > it may be an alternative to mac/amac in some cases. > > Changes: > > * eu_asu/iadd.vhdl: > - auto-sizing unit (WIDTH must be a multiple of 64) > - new increment-and-add and average operations > - improved adder stages > > * eu_asu/iatest7.vhdl: > - new (faster) testbench for iadd.vhdl > > * eu_imu/imul64.vhdl: > - improved adder stages > - 8/16/32/64 bit timing is now 3/4/5/6 cycles for both outputs > > * eu_imu/im64test4.vhdl: > - additional testbench for imul64.vhdl > > * eu_imu/im64testconf.vhdl: > - configuration file for IMU testbenches > > * eu_shl/shuffle64.vhdl: > - fixed bitrev operation > - added permute and cshift functions > > * eu_cmp/*: > - new integer compare unit (handles cmp/min/max/msb0/msb1) > - auto-sizing unit (WIDTH must be a multiple of 64) > > * eu_inc/*: > - new integer increment unit (handles inc/dec/neg/abs/lsb0/lsb1) > - auto-sizing unit (WIDTH must be a multiple of 64) > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 30 17:44:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zfTL-0005pu-00 for ; Sun, 30 Mar 2003 18:15:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 30 Mar 2003 18:15:51 +0200 (CEST) Received: (qmail 22530 invoked by uid 65534); 30 Mar 2003 15:43:07 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 30 Mar 2003 17:43:07 +0200 Received: by moria.seul.org (Postfix) id 0F6C833B7C; Sun, 30 Mar 2003 10:43:04 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E8C5233C6E; Sun, 30 Mar 2003 10:43:02 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id E5F4A33B7C for ; Sun, 30 Mar 2003 10:43:01 -0500 (EST) Received: from f-cpu.org (lven2-1-210.n.club-internet.fr [213.44.18.210]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 102DE16E8 for ; Sun, 30 Mar 2003 17:43:00 +0200 (CEST) Message-ID: <3E8710EF.9030707@f-cpu.org> Date: Sun, 30 Mar 2003 17:44:47 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! devik wrote: >Hi, >I tested to synthetize units for relatively cheap Xilinx >Spartan xc2s200-5 with 2352 slices. In all tests I used >about 100 slices for testing environment. Numbers below >are totals with my logic included. > >ASU: 601 slices, 69 MHz >MUL: out of memory (have only 150MB swap in vmware) >SHL: recursion detected in 'shift_map' >INC: many messages like > Signal > is used but never assigned. Tied to value 0. > WARNING:Xst:821 - C:/xilinx_webpack/ISEexamples/fcpu/bit_manipulation.vhd > (Line 269). Loop body will iterate zero times > 258 slices, 128 MHz but I expect problems here >CMP the same. > >Loop body will iterate zero times error can be fixed by adding explicit >IF to reduce_or. But other errors :( Probably XST synthetizer can't >handle some things. > > at least the ASU works ;-D >------------------------------- > Martin Devera aka devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Mar 30 22:17:29 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zwQ3-0000H8-01 for ; Mon, 31 Mar 2003 12:21:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 12:21:35 +0200 (CEST) Received: (qmail 1201 invoked by uid 65534); 30 Mar 2003 20:18:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 30 Mar 2003 22:18:52 +0200 Received: by moria.seul.org (Postfix) id 5B5B833C75; Sun, 30 Mar 2003 15:18:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8698233C72; Sun, 30 Mar 2003 15:18:45 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B99CB33B6B for ; Sun, 30 Mar 2003 15:18:44 -0500 (EST) Received: from a17-137.dialup.iol.cz ([194.228.137.17] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 18zjFz-0008Fm-00 for f-cpu@seul.org; Sun, 30 Mar 2003 22:18:20 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 18zjFB-0002Kk-00 for f-cpu@seul.org; Sun, 30 Mar 2003 22:17:29 +0200 Date: Sun, 30 Mar 2003 22:17:29 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report In-Reply-To: <3E8710EF.9030707@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N YG wrote: > >ASU: 601 slices, 69 MHz > >MUL: out of memory (have only 150MB swap in vmware) > >SHL: recursion detected in 'shift_map' > >INC: many messages like .... > >CMP the same. > > > at least the ASU works ;-D MR've sent me some patches and now SHL seems to fit into 333 slices (synthetizer correctly used MUX and SHIFT mode for majority of slices) and runs at 61MHz. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Mar 30 23:45:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zwQ4-0000H8-00 for ; Mon, 31 Mar 2003 12:21:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 12:21:36 +0200 (CEST) Received: (qmail 3881 invoked by uid 65534); 30 Mar 2003 21:44:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 30 Mar 2003 23:44:18 +0200 Received: by moria.seul.org (Postfix) id 70DCC33C77; Sun, 30 Mar 2003 16:44:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B9F733C72; Sun, 30 Mar 2003 16:44:11 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 90C6233B6B for ; Sun, 30 Mar 2003 16:44:10 -0500 (EST) Received: from f-cpu.org (lcbv1-1-97.n.club-internet.fr [213.44.3.97]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 4743816EE for ; Sun, 30 Mar 2003 23:44:06 +0200 (CEST) Message-ID: <3E876585.8010006@f-cpu.org> Date: Sun, 30 Mar 2003 23:45:41 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N yeah ! devik wrote: >YG wrote: > > > >>>ASU: 601 slices, 69 MHz >>>MUL: out of memory (have only 150MB swap in vmware) >>>SHL: recursion detected in 'shift_map' >>>INC: many messages like .... >>>CMP the same. >>> >>at least the ASU works ;-D >> >> > >MR've sent me some patches and now SHL seems to fit into >333 slices (synthetizer correctly used MUX and SHIFT mode >for majority of slices) and runs at 61MHz. > >devik > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Mar 30 20:16:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zwQ5-0000H8-00 for ; Mon, 31 Mar 2003 12:21:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 12:21:37 +0200 (CEST) Received: (qmail 3364 invoked by uid 65534); 30 Mar 2003 21:58:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 30 Mar 2003 23:58:55 +0200 Received: by moria.seul.org (Postfix) id E10F333B6B; Sun, 30 Mar 2003 16:58:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D9CD833C72; Sun, 30 Mar 2003 16:58:52 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a092.home.uni-hannover.de [130.75.232.92]) by moria.seul.org (Postfix) with ESMTP id 2164F33B6B for ; Sun, 30 Mar 2003 16:58:51 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01315; Sun, 30 Mar 2003 20:16:28 +0200 Message-ID: <20030330201628.00906@thrai.stud.uni-hannover.de> Date: Sun, 30 Mar 2003 20:16:28 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report References: <3E8710EF.9030707@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E8710EF.9030707@f-cpu.org>; from Yann Guidon on Sun, Mar 30, 2003 at 05:44:47PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Mar 30, 2003 at 05:44:47PM +0200, Yann Guidon wrote: [...] > >ASU: 601 slices, 69 MHz > >MUL: out of memory (have only 150MB swap in vmware) > >SHL: recursion detected in 'shift_map' > >INC: many messages like > > Signal > is used but never assigned. Tied to value 0. > > WARNING:Xst:821 - C:/xilinx_webpack/ISEexamples/fcpu/bit_manipulation.vhd > > (Line 269). Loop body will iterate zero times > > 258 slices, 128 MHz but I expect problems here > >CMP the same. [...] > at least the ASU works ;-D Don't worry, it's not a big deal -- just the old "brain-dead synthesizer" problem again that forces me to uglify my code. And EU_IMU simply is too big for 150 MB (and for that tiny Xilinx Spartan FPGA) -- Synopsys/SPARC needed 1 GB of RAM to synthesize the previous version. I already sent a patch that may fix the other units, and I'll re-release the whole package once it works. Should be only a matter of days. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Mon Mar 31 01:12:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 18zwQ5-0000H8-01 for ; Mon, 31 Mar 2003 12:21:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 12:21:37 +0200 (CEST) Received: (qmail 8411 invoked by uid 65534); 30 Mar 2003 22:17:56 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 31 Mar 2003 00:17:56 +0200 Received: by moria.seul.org (Postfix) id A01A933C6E; Sun, 30 Mar 2003 17:17:52 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9828D33C7A; Sun, 30 Mar 2003 17:17:52 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-101.noc.nerim.net [62.4.17.101]) by moria.seul.org (Postfix) with ESMTP id 4EC8A33C6E for ; Sun, 30 Mar 2003 17:17:52 -0500 (EST) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 8C1FE62D08 for ; Mon, 31 Mar 2003 00:17:48 +0200 (CEST) Date: Sun, 30 Mar 2003 23:12:00 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report Message-Id: <20030330231200.030d8ae3.nico@seul.org> In-Reply-To: <20030330201628.00906@thrai.stud.uni-hannover.de> References: <3E8710EF.9030707@f-cpu.org> <20030330201628.00906@thrai.stud.uni-hannover.de> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, 30 Mar 2003 20:16:28 +0200 Michael Riepe wrote: > On Sun, Mar 30, 2003 at 05:44:47PM +0200, Yann Guidon wrote: > [...] > > >ASU: 601 slices, 69 MHz > > >MUL: out of memory (have only 150MB swap in vmware) > > >SHL: recursion detected in 'shift_map' > > >INC: many messages like > > > Signal > is used but never assigned. Tied to value > > > 0. WARNING:Xst:821 - > > > C:/xilinx_webpack/ISEexamples/fcpu/bit_manipulation.vhd > > > (Line 269). Loop body will iterate zero times > > > 258 slices, 128 MHz but I expect problems here > > >CMP the same. > [...] > > at least the ASU works ;-D > > Don't worry, it's not a big deal -- just the old "brain-dead > synthesizer" problem again that forces me to uglify my code. And > EU_IMU simply is too big for 150 MB (and for that tiny Xilinx Spartan > FPGA) -- Synopsys/SPARC needed 1 GB of RAM to synthesize the previous > version. > Try to keep the "clean" code somewhere for the day such syntetiser will existe... > I already sent a patch that may fix the other units, and I'll > re-release the whole package once it works. Should be only a matter > of days. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Mar 31 03:43:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1906NS-0007UZ-00 for ; Mon, 31 Mar 2003 22:59:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 22:59:34 +0200 (CEST) Received: (qmail 11942 invoked by uid 65534); 31 Mar 2003 12:18:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 31 Mar 2003 14:18:18 +0200 Received: by moria.seul.org (Postfix) id BF21933B49; Mon, 31 Mar 2003 07:18:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F203033B6F; Mon, 31 Mar 2003 07:18:13 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a228.home.uni-hannover.de [130.75.232.228]) by moria.seul.org (Postfix) with ESMTP id E1C6033B49 for ; Mon, 31 Mar 2003 07:18:11 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA02676; Mon, 31 Mar 2003 03:43:07 +0200 Message-ID: <20030331034307.55104@thrai.stud.uni-hannover.de> Date: Mon, 31 Mar 2003 03:43:07 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report References: <3E8710EF.9030707@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Sun, Mar 30, 2003 at 10:17:29PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Mar 30, 2003 at 10:17:29PM +0200, devik wrote: [...] > MR've sent me some patches and now SHL seems to fit into > 333 slices (synthetizer correctly used MUX and SHIFT mode > for majority of slices) and runs at 61MHz. But still with lots of warnings that don't make sense. The synthesizer reports 408 open signals for EU_SHL and 768 open signals for EU_INC -- but that brain-dead piece of shit doesn't say *where*. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dmdmdm@zero.ad.jp Mon Mar 31 15:11:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1906NV-0007UZ-01 for ; Mon, 31 Mar 2003 22:59:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 22:59:37 +0200 (CEST) Received: (qmail 11461 invoked by uid 65534); 31 Mar 2003 13:11:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 31 Mar 2003 15:11:18 +0200 Received: by moria.seul.org (Postfix) id 3AB9733B48; Mon, 31 Mar 2003 08:11:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E8A833B75; Mon, 31 Mar 2003 08:11:10 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id D7FFC33B48 for ; Mon, 31 Mar 2003 08:11:09 -0500 (EST) Received: from 76.11.24.31 (f-tokyo-131189.zero.ad.jp [211.130.131.189]) by bettik.munge.net (Postfix) with SMTP id B72E24F78E for ; Mon, 31 Mar 2003 07:12:01 -0600 (CST) From: smoke To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81=9A=81=9A=82=ED=82=BD=82=B5=81A=94=F2=82=D1=82=DC=82=B7=81I=81=9A=81=9A?= Date: Mon, 31 Mar 2003 22:11:25 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d47df489-5001-4b70-acd1-dd6e2c11844e" Message-Id: <20030331131201.B72E24F78E@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --d47df489-5001-4b70-acd1-dd6e2c11844e Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =81@=81@=81@=81@=81=9A=92g=82=A9=82=AD=82=C8=82=E9=97t=82=C1=82=CF=82=A0=82=E8= =82=DC=82=B7=81=9A =83K=83=93=83W=83=83=81A=83`=83=87=83R=81A=8E=F7=8E=89=81A=83X=83=82=81[=83= N=81Aseeds =93=FA=96{=94=AD=93=FC=89=D7=81A=83A=83w=83=93=97l=83n=81[=83o=83=8B=83X=83=82= =81[=83N =83T=83C=83g=82=AA=8F=C1=82=B3=82=EA=82=BD=82=E7=8FI=97=B9=82=C5=82=B7=81B =90=B8=90_=88=C0=92=E8=8D=DC=91=E3=82=ED=82=E8=82=C9=82=C7=82=A4=82=BC=81I =81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB= =81@=81=AB=81@=81=AB http://galileo.spaceports.com/~yaku0/ http://www.online.in.th/yaku/ http://www.yaku.ruuu.com/ http://c.1asphost.com/yaku/ http://yaku.www3.dotnetplayground.com/ http://tobutobu.host.sk/ --d47df489-5001-4b70-acd1-dd6e2c11844e-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Gogetajob.com_ryygwz@gm44.com Mon Mar 31 22:17:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1906Nt-0007UZ-00 for ; Mon, 31 Mar 2003 23:00:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 23:00:01 +0200 (CEST) Received: (qmail 20790 invoked by uid 65534); 31 Mar 2003 20:17:17 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 31 Mar 2003 22:17:17 +0200 Received: by moria.seul.org (Postfix) id C02E633B75; Mon, 31 Mar 2003 15:17:14 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7835733C7D; Mon, 31 Mar 2003 15:17:14 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mta2.gm44.com (mta2.gm44.com [216.176.55.13]) by moria.seul.org (Postfix) with SMTP id 7B21A33B75 for ; Mon, 31 Mar 2003 15:17:13 -0500 (EST) Message-ID: <29372089.1049141823687.Kada.KadaSegment-73@mta2.gm44.com> Date: Mon, 31 Mar 2003 15:17:03 -0500 (EST) From: "Gogetajob.com" To: f-cpu@seul.org Subject: [f-cpu] Get the job you want now! Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8966_7666749.1049141823687" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ------=_Part_8966_7666749.1049141823687 Content-Type: text/plain Content-Transfer-Encoding: 7bit Find Your Ideal Job .... Quick .... Easy .... Affordable .... Job Seekers -- Get Laser Focused! Move Forward Get Hired FAST! Work With Contacts Expand Your Reach Meet Decision Makers Tap Hidden Jobs Market Yourself Find Hiring Managers Use the Web Go to the Head of the Line With so few positions open, and a market full of Jobseekers, you need an advantage. You need http://gm14.com/r.html?c=188877&r=188469&t=145241422&l=1&d=81269835&u=http://www.GoGetAJob.com&g=0&f=-1 To no longer receive information from us click here: http://gm14.com/r.html?c=188877&r=188469&t=145241422&l=6&ea=f-cpu@seul.org, or reply to this message with the word unsubscribe as the subject of the message. ------=_Part_8966_7666749.1049141823687 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Go Get A Job


Find Your = Ideal Job .... Quick .... Easy .... Affordable ....

Job Seekers -- Get Laser Focused!

Move Forward
Get Hired FAST!
Work With Contacts= =A0=A0=A0 Expand Your Reach Meet Decision Makers= =A0=A0=A0 Tap Hidden Jobs
Market Yourself=A0= =A0=A0 Find Hiring Managers=
Use the Web
Go to the Head of th= e Line

With so few positions open, and a market full of Jobseekers,
you need a= n advantage.

You need GoGetAJob.com

Click here to get st= arted on finding the job you want!


To no longer receive information from us click here, or reply to this message with the word unsubscribe a= s the subject of the message.


------=_Part_8966_7666749.1049141823687-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Mar 31 21:55:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1906Y6-0007gV-00 for ; Mon, 31 Mar 2003 23:10:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 31 Mar 2003 23:10:34 +0200 (CEST) Received: (qmail 11701 invoked by uid 65534); 31 Mar 2003 20:37:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 31 Mar 2003 22:37:08 +0200 Received: by moria.seul.org (Postfix) id 8C13A33B7E; Mon, 31 Mar 2003 15:37:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7131833C7D; Mon, 31 Mar 2003 15:37:05 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id D3B9633B7E for ; Mon, 31 Mar 2003 15:37:03 -0500 (EST) Received: from a97-137.dialup.iol.cz ([194.228.137.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19061I-0006TJ-00; Mon, 31 Mar 2003 22:36:41 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 1905Nt-0000eG-00; Mon, 31 Mar 2003 21:55:57 +0200 Date: Mon, 31 Mar 2003 21:55:56 +0200 (CEST) From: devik X-X-Sender: To: Michael Riepe Cc: Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report In-Reply-To: <20030331142755.27059@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N So that, synthesis of old adder yelds 452 slices and runs at 68 MHz. Thus new adder is both more complex and slightly faster. devik On Mon, 31 Mar 2003, Michael Riepe wrote: > Hi! > > > > Yep. Could you try the previous version of EU_ASU as well? I'd like > > > to see if there is a timing difference. > > > > and could you send me the source ? I'm not sure what is > > "the previous version" for sure. I need only > > iasu.vhdl .. > > Attached. Note that this version also needs common/generic_adder.vhdl > (but you already have that). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From zoey@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1909j4-0001WI-01 for ; Tue, 01 Apr 2003 02:34:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 01 Apr 2003 02:34:06 +0200 (CEST) Received: (qmail 15746 invoked by uid 65534); 31 Mar 2003 22:11:20 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 01 Apr 2003 00:11:20 +0200 Received: by moria.seul.org (Postfix) id 3071833B74; Mon, 31 Mar 2003 17:11:18 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B23C33C84; Mon, 31 Mar 2003 17:11:17 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from excuria.com (unknown [69.6.2.40]) by moria.seul.org (Postfix) with ESMTP id 87F9333B74 for ; Mon, 31 Mar 2003 17:11:07 -0500 (EST) Received: from mail pickup service by excuria.com with Microsoft SMTPSVC; Mon, 31 Mar 2003 16:10:03 -0600 Date: 2003-03-31 16:09:58 To: From: Zoey Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save upto 89% Message-ID: X-OriginalArrivalTime: 31 Mar 2003 22:10:03.0750 (UTC) FILETIME=[47ACE060:01C2F7D2] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products w/ 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! Visit us on the web at http://excuria.com/inkstore/ For instruction on how to be permanently remove from this distribution system go to http://excuria.com/remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 1 01:19:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1909jB-0001WI-00 for ; Tue, 01 Apr 2003 02:34:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 01 Apr 2003 02:34:13 +0200 (CEST) Received: (qmail 18783 invoked by uid 65534); 31 Mar 2003 23:19:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 01 Apr 2003 01:19:25 +0200 Received: by moria.seul.org (Postfix) id 8221233C7D; Mon, 31 Mar 2003 18:19:21 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7AF1233C84; Mon, 31 Mar 2003 18:19:21 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a212.home.uni-hannover.de [130.75.232.212]) by moria.seul.org (Postfix) with ESMTP id EFFA633C7D for ; Mon, 31 Mar 2003 18:19:19 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA08314; Tue, 1 Apr 2003 01:19:18 +0200 Message-ID: <20030401011918.11083@thrai.stud.uni-hannover.de> Date: Tue, 1 Apr 2003 01:19:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New VHDL Stuff - Xilinx synteheis report References: <20030331142755.27059@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Mon, Mar 31, 2003 at 09:55:56PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Mar 31, 2003 at 09:55:56PM +0200, devik wrote: > So that, synthesis of old adder yelds 452 slices and runs > at 68 MHz. Thus new adder is both more complex and slightly > faster. Good :) I expected the former (there are several new functions) but I wasn't sure about the latter. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 2 09:58:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190hCC-0000HI-00 for ; Wed, 02 Apr 2003 14:18:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 02 Apr 2003 14:18:24 +0200 (CEST) Received: (qmail 10161 invoked by uid 65534); 2 Apr 2003 08:02:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 02 Apr 2003 10:02:14 +0200 Received: by moria.seul.org (Postfix) id 83C4233B84; Wed, 2 Apr 2003 03:02:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4A03133B83; Wed, 2 Apr 2003 03:02:11 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 5BA4933B7F for ; Wed, 2 Apr 2003 03:02:10 -0500 (EST) Received: from a106-137.dialup.iol.cz ([194.228.137.106] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 190dC8-0006HI-00 for f-cpu@seul.org; Wed, 02 Apr 2003 10:02:07 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 190d8g-0006UQ-00 for f-cpu@seul.org; Wed, 02 Apr 2003 09:58:30 +0200 Date: Wed, 2 Apr 2003 09:58:30 +0200 (CEST) From: devik X-X-Sender: To: Subject: [f-cpu] Multiplier Synthesis In-Reply-To: <20030401235151.56503@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N By the way, when I run Xilinx synthesis in Wine (to take advantage of linux MM) I was able to do up-level synthesis in 10 hours and 550 MB of memory. Unfortunately high swaping activity prevented low level synthesis in reasonable time so that I will retry it later when I upgrade my system to 512 MB of RAM. For curious there is synthesis stat of it: Macro Statistics # Registers : 430 68-bit register : 32 128-bit register : 44 32-bit register : 1 64-bit register : 2 1-bit register : 351 # Multiplexers : 369 2-to-1 multiplexer : 369 # Xors : 3328 128-bit xor5 : 12 128-bit xor3 : 5 1-bit xor2 : 1118 1-bit xor3 : 2184 128-bit xor9 : 8 128-bit xor2 : 1 devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Wed Apr 2 15:29:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190hCC-0000HI-01 for ; Wed, 02 Apr 2003 14:18:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 02 Apr 2003 14:18:24 +0200 (CEST) Received: (qmail 11480 invoked by uid 65534); 2 Apr 2003 08:29:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 02 Apr 2003 10:29:55 +0200 Received: by moria.seul.org (Postfix) id 2747D33C3B; Wed, 2 Apr 2003 03:29:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 24B9133B83; Wed, 2 Apr 2003 03:29:50 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-103.nerim.net [62.4.16.103]) by moria.seul.org (Postfix) with ESMTP id ACCC333B7F for ; Wed, 2 Apr 2003 03:29:49 -0500 (EST) Received: from localhost (crateria.nerim.net [62.4.16.75]) by kraid.nerim.net (Postfix) with SMTP id D362B40E2A for ; Wed, 2 Apr 2003 10:29:48 +0200 (CEST) To: Subject: Re: [f-cpu] Multiplier Synthesis From: Date: Wed, 2 Apr 2003 10:29:49 CEST X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030402082948.D362B40E2A@kraid.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Have you a full licence of Xilinx ? I had some collegue who try to use the demo version under wine without success. Could you explain how you use it ? nicO Devik a écrit : > By the way, when I run Xilinx synthesis in Wine (to take > advantage of linux MM) I was able to do up-level synthesis > in 10 hours and 550 MB of memory. > Unfortunately high swaping activity prevented low level > synthesis in reasonable time so that I will retry it later > when I upgrade my system to 512 MB of RAM. > > For curious there is synthesis stat of it: > Macro Statistics > # Registers : 430 > 68-bit register : 32 > 128-bit register : 44 > 32-bit register : 1 > 64-bit register : 2 > 1-bit register : 351 > # Multiplexers : 369 > 2-to-1 multiplexer : 369 > # Xors : 3328 > 128-bit xor5 : 12 > 128-bit xor3 : 5 > 1-bit xor2 : 1118 > 1-bit xor3 : 2184 > 128-bit xor9 : 8 > 128-bit xor2 : 1 > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 2 12:20:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190hCM-0000HI-00 for ; Wed, 02 Apr 2003 14:18:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 02 Apr 2003 14:18:34 +0200 (CEST) Received: (qmail 30730 invoked by uid 65534); 2 Apr 2003 11:02:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 02 Apr 2003 13:02:43 +0200 Received: by moria.seul.org (Postfix) id 9462833B83; Wed, 2 Apr 2003 06:02:40 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6578B33C5B; Wed, 2 Apr 2003 06:02:39 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id F0F7A33B83 for ; Wed, 2 Apr 2003 06:02:33 -0500 (EST) Received: from a117-137.dialup.iol.cz ([194.228.137.117] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 190g0K-00073O-00 for f-cpu@seul.org; Wed, 02 Apr 2003 13:02:04 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 190fLv-0006zG-00 for f-cpu@seul.org; Wed, 02 Apr 2003 12:20:19 +0200 Date: Wed, 2 Apr 2003 12:20:18 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Multiplier Synthesis In-Reply-To: <20030402082948.D362B40E2A@kraid.nerim.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N It is the free version (WebPACK 4.2). I installed it under winnt (within vmware) and then copied installed tree to my linux drive. Here I start commandline tools directly using wine. And yes, graphical part doesn't work under wine. On Wed, 2 Apr 2003 cyrano@nerim.net wrote: > Have you a full licence of Xilinx ? I had some collegue who try to use th= > e demo version under wine without success. Could you explain how you use = > it ? > > nicO > > Devik a =E9crit : > > > By the way, when I run Xilinx synthesis in Wine (to take > > advantage of linux MM) I was able to do up-level synthesis > > in 10 hours and 550 MB of memory. > > Unfortunately high swaping activity prevented low level > > synthesis in reasonable time so that I will retry it later > > when I upgrade my system to 512 MB of RAM. > >=20 > > For curious there is synthesis stat of it: > > Macro Statistics > > # Registers : 430 > > 68-bit register : 32 > > 128-bit register : 44 > > 32-bit register : 1 > > 64-bit register : 2 > > 1-bit register : 351 > > # Multiplexers : 369 > > 2-to-1 multiplexer : 369 > > # Xors : 3328 > > 128-bit xor5 : 12 > > 128-bit xor3 : 5 > > 1-bit xor2 : 1118 > > 1-bit xor3 : 2184 > > 128-bit xor9 : 8 > > 128-bit xor2 : 1 > >=20 > > devik > >=20 > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org > > with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ___________________________________ > Webmail Nerim, http://www.nerim.net/ > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 3 02:02:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190xPL-0003Pw-00 for ; Thu, 03 Apr 2003 07:37:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Apr 2003 07:37:03 +0200 (CEST) Received: (qmail 10596 invoked by uid 65534); 3 Apr 2003 00:02:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 03 Apr 2003 02:02:50 +0200 Received: by moria.seul.org (Postfix) id 2C24733B5A; Wed, 2 Apr 2003 19:02:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5904D33C9F; Wed, 2 Apr 2003 19:02:45 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a118.home.uni-hannover.de [130.75.232.118]) by moria.seul.org (Postfix) with ESMTP id 19D8A33B5A for ; Wed, 2 Apr 2003 19:02:43 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA01099; Thu, 3 Apr 2003 02:02:41 +0200 Message-ID: <20030403020241.63707@thrai.stud.uni-hannover.de> Date: Thu, 3 Apr 2003 02:02:41 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] New upload Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N F-riends, I uploaded fcpu-mr-20030402.tar.gz to http://f-cpu.seul.org/~f-cpu/new/. Highlights of this release: - the Xilinx synthesizer groks INC and CMP now. - SHL makes it dump core (not my fault, I guess). Compatibility note to VHDL coders: Avoid the `alias' keyword in code that is going to be synthesized. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mmeyer@nhbb.com Thu Apr 3 01:59:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190xPZ-0003Pw-00 for ; Thu, 03 Apr 2003 07:37:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Apr 2003 07:37:17 +0200 (CEST) Received: (qmail 18994 invoked by uid 65534); 3 Apr 2003 00:06:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 03 Apr 2003 02:06:36 +0200 Received: by moria.seul.org (Postfix) id 4BEF233C21; Wed, 2 Apr 2003 19:06:32 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 86A8333CA0; Wed, 2 Apr 2003 19:06:30 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from ppb012.nhbb.com (spb012.nhbb.com [64.214.75.196]) by moria.seul.org (Postfix) with ESMTP id 7F41233C21 for ; Wed, 2 Apr 2003 19:06:30 -0500 (EST) Subject: [f-cpu] Fwd: Fw: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "MIKE MEYER" Date: Wed, 2 Apr 2003 15:59:59 -0800 X-MIMETrack: Serialize by Router on MAILPB01/NHBBMAIL(Release 5.0.11 |July 24, 2002) at 04/02/2003 07:04:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Notes-Item: f-cpu@seul.org@nhbbmail; name=Originalbcc To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Forwarded by MIKE MEYER/NHBB/USA/MINEBEA on 04/02/2003 03:58 PM ----- DeIightM@aol.com To: Mox9927@aol.com 04/02/2003 02:02 craighill2@netzero.net PM clk_49@yahoo.com ChameleonEyedQT@aol.com MIKE MEYER/NHBB/USA/MINEBEA@MINEBEA dot@simivalleyfinancial.com lifeguardchic_2001@yahoo.com joy.sarnowski@ladarling.com Heartnmusic@aol.com MITCHRG340@aol.com cc: Subject: Fwd: Fw: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Message from "Pauline" on Tue, 1 Apr 2003 16:51:47 -0500 ----- To: Subject: Fw: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Dan Corkery To: vP9754@aol.com Sent: Monday, March 31, 2003 7:45 PM Subject: Fwd: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! From: "sdroege" To: "maggie miller" , "katie ford" , "julie kelley" , "jen heumann" , "Jean Dolan" , "jan reeves" , "Erin Gallagher" , "donald droege" , "Dan Corkery" , "bonnie turin" , "annie means" Subject: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! Date: Mon, 31 Mar 2003 11:32:09 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Rcpt-To: X-DPOP: Email supplied by temporary trial Version of DPOP -----Original Message----- From: Donna Gills [mailto:dgills@bellsouth.net] Sent: Monday, March 24, 2003 8:28 PM To: charlie -- watkins Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: dwyerwoods To: JGreisen@aol.com ; ClydeandBeth@cs.com ; Jabry3@aol.com ; Dottie47@hotmail.com ; Dottiecan2@msn.com ; Creekmamma@aol.com ; Ebeth68@wmconnect.com ; brenjo4@Yahoo.com ; Tooter@ctaz.com ; Dintdoit87@aol.com Sent: Monday, March 24, 2003 3:57 PM Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Fips To: Stacey Anderson ; Morgan Fippinger ; Pat Fippinger ; Nancy Parshley ; John Parshley ; Donna Gravlin ; darren.j.fippinger ; Cindy Lockhart ; AnnMarie Fippinger ; Anderson,Stacey Sent: Sunday, March 23, 2003 3:29 AM Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Ed Werner To: June Gifford ; Joni Stange ; JOEL WULFF ; Jeanbarb1@aol.com ; Ed & Sue Ginter ; Ed & Rita Werner ; diane and/or george carter ; Bears'Herbs ; Barbara Greenlaw ; Barbara Gilhuly Sent: Saturday, March 22, 2003 6:55 PM Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Linda Dimeo To: Jim McLaughlin ; Jess LaFleur ; Hilary Bainbridge ; Greg Ginter ; Ed Werner ; Ed & Rita Werner ; Dimeo, Linda ; chris ; bill ; Alderae2@aol.com Sent: Saturday, March 22, 2003 6:00 PM Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Leslie Brown To: lindad ; annie wallace ; Lady Brown ; Carlos & Florence Rios ; andra mies ; allen schrandt ; dave schrandt ; glen schrandt ; hilary bainbridge ; lisa sledge Sent: Friday, March 21, 2003 9:56 PM Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Anna Wallace To: Aaronkimber@aol.com ; lesbrown21@msn.com ; LAWHONSTOY@aol.com ; tangleton@nbandover.com ; ldavis@nbandover.com ; jlygrisse@nbandover.com ; grannyjoinks@aol.com ; schaal@ksisp.net ; swilcox@nbandover.com ; kclark@nbandover.com Sent: Friday, March 21, 2003 1:57 PM Subject: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! [Anna Wallace] I KNOW I'VE SENT THIS TO YOU ONCE BUT I'M TRYING IT AGAIN. I'M SORRY IF ITS BAD. I DON'T KNOW THE PUNCH LINE -----Original Message----- From: Sheila Wilcox [mailto:swilcox@nbandover.com] Sent: Friday, March 21, 2003 12:36 PM To: bharrold@nbandover.com; shellbell23d@yahoo.com; millse@comcast.net; awallace@nbandover.com Subject: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! -----Original Message----- From: Phil & Radonda Buford [mailto:pbuford@grapevine.net] Sent: Tuesday, March 18, 2003 9:58 PM To: Rose Marie Lile; nancy l kendrick; Kim Ryan; Kerry & Roxanne Kendrick; LaDawna Richards; Goodman, Tammy; dayna schmidt; Carrie Morford; Carol Cave; Bev Appelhans Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: Chris Kyriakopoulos To: Rich Hsu - Riba Corp. ; Philip ; Peter n Kalantzis ; Leesa Kyriakopoulos ; John Stevens ; Jim Kaldis ; Jason Cheskes ; Franca Heller ; Dennis Peterson Efstatheu ; Alex Petrou ; Amanda Hubbard Sent: Monday, December 02, 2002 11:00 AM Subject: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! -----Original Message----- From: Chris Kyriakopoulos [mailto:riba@execulink.com] Sent: December 2, 2002 11:58 AM To: Rich Hsu - Riba Corp.; Philip; Jim Kaldis; Franca Heller; Dino. Kiriakopoulos@sonoco. com; Christina Kiofos; Amanda Hubbard; Alex Petrou Subject: FW: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! -----Original Message----- From: Greg Hughes [mailto:greghughes@freshstartfoods.com] Sent: December 2, 2002 9:12 AM To: David Irving; Sheila Hughes; jeff hughes; Gayle K Hughes; Bob and Alison Geitz; Shean Dillon; Steve Demarsh; Chris; Chris Canning; David Bartholomew Subject: Fw: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! ----- Original Message ----- From: McLean, Jim To: Craig Jones (E-mail) ; Dave Pettaplace (E-mail) ; Jeffrey Williams (E-mail) ; Rob Hughes (E-mail) ; Steve Putherbough (E-mail) ; Steve Wong (E-mail) ; Tim Earley (E-mail) ; Wendy McLean (E-mail) ; Ken Carruthers (E-mail) ; Jenn McLean (E-mail) Sent: Friday, November 29, 2002 9:15 AM Subject: DO THIS!!! ITS HYSTERICAL!!!!!!!!!!! This is a joke that is really funny, and it works!] An old lady walked into a Grocery Store. She wanted to buy the best dog food in the world for her little puppy. She went up to the cash register to pay for the food. The Sales-lady told her that the store did not allow old ladies to buy animal food unless they show the actual animal because a lot of old ladies like to eat the animal food themselves. So the old lady went home, got her dog and went back to the store to buy her dog food. The next day she came back to buy the best cat food around. But the Sales-lady told her the same thing, so the old lady went back home and brought her cat to the Grocery Store to buy the cat food. The next day the old lady went to the Grocery Store again, carrying a big container. She went up to the Sales-lady and said, "Put your hand inside here." The Sales-lady shook her head. "NO", she said, "there is probably something in there that will bite me!". "I promise you that there is nothing in here that will bite you," the old lady said. So, the Sales-lady stuck her hand inside the container, and screamed. To find out what was inside the container, you must send this to at least 10 people. When it says, your mail has been sent...instead of clicking ok, hit ALT-8 and the container will pop up on your screen. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/03 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu Apr 3 06:29:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 190xQ8-0003Pw-00 for ; Thu, 03 Apr 2003 07:37:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 03 Apr 2003 07:37:52 +0200 (CEST) Received: (qmail 21321 invoked by uid 65534); 3 Apr 2003 04:27:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 03 Apr 2003 06:27:49 +0200 Received: by moria.seul.org (Postfix) id D637A33C60; Wed, 2 Apr 2003 23:27:46 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 572BB33C9F; Wed, 2 Apr 2003 23:27:46 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 53A5E33C60 for ; Wed, 2 Apr 2003 23:27:45 -0500 (EST) Received: from f-cpu.org (lcbv1-1-43.n.club-internet.fr [213.44.3.43]) by relay-2v.club-internet.fr (Postfix) with ESMTP id A161916E4 for ; Thu, 3 Apr 2003 06:27:43 +0200 (CEST) Message-ID: <3E8BB8B2.20400@f-cpu.org> Date: Thu, 03 Apr 2003 06:29:38 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] New upload References: <20030403020241.63707@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >Compatibility note to VHDL coders: Avoid the `alias' keyword in >code that is going to be synthesized. > > hmmm did i use it in my code ? aliases are quite useful in some places, is there any turnaround ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 3 14:42:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 191Enk-0003pU-00 for ; Fri, 04 Apr 2003 02:11:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 04 Apr 2003 02:11:24 +0200 (CEST) Received: (qmail 2857 invoked by uid 65534); 3 Apr 2003 21:56:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 03 Apr 2003 23:56:52 +0200 Received: by moria.seul.org (Postfix) id 4B8DB33B56; Thu, 3 Apr 2003 16:56:50 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EF84D33C5F; Thu, 3 Apr 2003 16:56:49 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a087.home.uni-hannover.de [130.75.232.87]) by moria.seul.org (Postfix) with ESMTP id 399FC33B56 for ; Thu, 3 Apr 2003 16:56:48 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00527; Thu, 3 Apr 2003 14:42:35 +0200 Message-ID: <20030403144235.08100@thrai.stud.uni-hannover.de> Date: Thu, 3 Apr 2003 14:42:35 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] New upload References: <20030403020241.63707@thrai.stud.uni-hannover.de> <3E8BB8B2.20400@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E8BB8B2.20400@f-cpu.org>; from Yann Guidon on Thu, Apr 03, 2003 at 06:29:38AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Apr 03, 2003 at 06:29:38AM +0200, Yann Guidon wrote: [...] > aliases are quite useful in some places, is there any turnaround ? I used to use aliases for function arguments, to get a well-defined index range for vector arguments: procedure blah (A : in std_ulogic_vector) is alias aa : std_ulogic_vector(A'length-1 downto 0) is A; begin ... A variable and a single assignment will also do the trick: procedure blah (A : in std_ulogic_vector) is variable aa : std_ulogic_vector(A'length-1 downto 0); begin aa := A; ... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fbici19@yahoo.co.uk Fri Apr 4 22:40:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 191agS-0000Fg-00 for ; Sat, 05 Apr 2003 01:33:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 05 Apr 2003 01:33:20 +0200 (CEST) Received: (qmail 10732 invoked by uid 65534); 4 Apr 2003 20:41:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 04 Apr 2003 22:41:02 +0200 Received: by moria.seul.org (Postfix) id 3096C33B61; Fri, 4 Apr 2003 15:41:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4192E33C19; Fri, 4 Apr 2003 15:40:59 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from web40911.mail.yahoo.com (web40911.mail.yahoo.com [66.218.78.208]) by moria.seul.org (Postfix) with SMTP id A74B533B61 for ; Fri, 4 Apr 2003 15:40:58 -0500 (EST) Message-ID: <20030404204057.71938.qmail@web40911.mail.yahoo.com> Received: from [213.120.126.23] by web40911.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 21:40:57 BST Date: Fri, 4 Apr 2003 21:40:57 +0100 (BST) From: =?iso-8859-1?q?Forcim=20Bici?= Subject: [f-cpu] CPU register To: f-cpu@seul.org Cc: lets_play83@hotmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi i am writing to you to see if you could be able to help me on this question. The question is : Java can use just 8 bits to represent integers; this means it can represent the range -128 to +127. State whether the following calculation would give the correct answer? a) 6 multiplied by 5 b) 32 multiplied by 4 c) 32 multiplied by -4 Question 2: Explain the perpose of a java interpreter? Question 3: __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Sun Apr 6 01:00:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1920aX-0000H7-01 for ; Sun, 06 Apr 2003 05:12:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 06 Apr 2003 05:12:57 +0200 (CEST) Received: (qmail 8775 invoked by uid 65534); 5 Apr 2003 23:01:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 06 Apr 2003 01:01:16 +0200 Received: by moria.seul.org (Postfix) id 27D1133B80; Sat, 5 Apr 2003 18:01:15 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7662533C5C; Sat, 5 Apr 2003 18:01:09 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by moria.seul.org (Postfix) with SMTP id AB3F833B80 for ; Sat, 5 Apr 2003 18:01:06 -0500 (EST) Message-ID: <20030405230059.94634.qmail@web14208.mail.yahoo.com> Received: from [130.89.240.216] by web14208.mail.yahoo.com via HTTP; Sat, 05 Apr 2003 15:00:59 PST Date: Sat, 5 Apr 2003 15:00:59 -0800 (PST) From: jaap stolk Subject: Re: [f-cpu] CPU register To: f-cpu@seul.org In-Reply-To: <20030404204057.71938.qmail@web40911.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --- Forcim Bici wrote: > Hi i am writing to you to see if you could be able > to > help me on this question. > > The question is : Java can use just 8 bits to > represent integers; this means it can represent the > range -128 to +127. > State whether the following > calculation would give the correct answer? > > a) 6 multiplied by 5 = +30 (according to the windows calculator) > b) 32 multiplied by 4 = +128 > c) 32 multiplied by -4 = -128 > > Question 2: > > Explain the perpose of a java interpreter? > is there any ? :-) > > Question 3: > interesting, but can you give some more details ? jaap. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 6 01:52:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1920aY-0000H7-01 for ; Sun, 06 Apr 2003 05:12:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 06 Apr 2003 05:12:58 +0200 (CEST) Received: (qmail 18605 invoked by uid 65534); 5 Apr 2003 23:52:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 06 Apr 2003 01:52:12 +0200 Received: by moria.seul.org (Postfix) id 000A033C5C; Sat, 5 Apr 2003 18:52:11 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3AF5333C61; Sat, 5 Apr 2003 18:52:10 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a191.home.uni-hannover.de [130.75.232.191]) by moria.seul.org (Postfix) with ESMTP id EB39933C5C for ; Sat, 5 Apr 2003 18:52:07 -0500 (EST) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03325; Sun, 6 Apr 2003 01:52:06 +0200 Message-ID: <20030406015206.54119@thrai.stud.uni-hannover.de> Date: Sun, 6 Apr 2003 01:52:06 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] IDU News Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N News of the Week: I finally made the SRT divider work. The first version supports signed and unsigned division with chunk sizes of 8, 16, 32 and 64 bits (including SIMD) and needs +5 cycles for an -bit result. Throughput is 1/ operations per cycle. Calculating the remainder is not supported yet -- it will take one cycle longer, and blow up the final stages of the unit a lot. It can be added without changing the existing parts, so I skipped it for now. The unit has 6 stages: In the first and second stage, the operands are normalized (i.e. left-shifted depending on the position of the MSB of the divisor). Stage 3 is the real SRT divider; it executes times in a loop. Since it provides the quotient in redundant (dual-rail) form, a final adder is needed. In some cases, the quotient (and the remainder if one is calculated) must also be corrected because the SRT algorithm may "overshoot". Correction circuitry and the final adder occupy stages 4-6. Calculating the remainder will require a second correction circuit (which is basically a carry-save add/sub circuit) and another output adder (also located in stage 4-6) plus a `denormalizer' which shifts the remainder back into its original position (that would be stage 7). For both shifters, I (will) use an omega network similar to that in EU_SHL (but with different control logic). Parts of the unit may be re-used. In particular, if you feed the output of the normalizer into an FP rounding circuit, you'll get the `int2f'/`int2d' instructions almost for free. If you skip the normalization stages, the rest of the unit should also be able to perform FP division (that will be very difficult to schedule, however). I'm waiting for synthesis results before I release the unit. But since it's almost ready, and since this was the last mandatory integer EU that was missing, I guess it's time to open a bottle of your favourite beverage, and PARTY!!! One open question remains, however: What shall I do next? ;( -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 6 16:58:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192faz-0000H3-00 for ; Tue, 08 Apr 2003 01:00:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:00:09 +0200 (CEST) Received: (qmail 13834 invoked by uid 65534); 6 Apr 2003 14:56:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 06 Apr 2003 16:56:39 +0200 Received: by moria.seul.org (Postfix) id D61F533B6A; Sun, 6 Apr 2003 10:56:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9419A33B68; Sun, 6 Apr 2003 10:56:37 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 338A733B4D for ; Sun, 6 Apr 2003 10:56:37 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-86.n.club-internet.fr [213.44.3.86]) by relay-2v.club-internet.fr (Postfix) with ESMTP id B8AC316C2 for ; Sun, 6 Apr 2003 16:56:35 +0200 (CEST) Message-ID: <3E90409E.7090206@f-cpu.org> Date: Sun, 06 Apr 2003 16:58:38 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News References: <20030406015206.54119@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >One open question remains, however: What shall I do next? ;( > well, given the exhausting party and your nickname, i guess you can rest a bit ;-P YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Apr 6 18:45:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbB-0000H3-00 for ; Tue, 08 Apr 2003 01:00:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:00:21 +0200 (CEST) Received: (qmail 17140 invoked by uid 65534); 6 Apr 2003 20:42:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 06 Apr 2003 22:42:44 +0200 Received: by moria.seul.org (Postfix) id 1964233C25; Sun, 6 Apr 2003 16:42:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B259533C62; Sun, 6 Apr 2003 16:42:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 5531F33C25 for ; Sun, 6 Apr 2003 16:42:40 -0400 (EDT) Received: from a84-137.dialup.iol.cz ([194.228.137.84] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 192GyC-0005Fn-00 for f-cpu@seul.org; Sun, 06 Apr 2003 22:42:29 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 192DGw-0000IJ-00 for f-cpu@seul.org; Sun, 06 Apr 2003 18:45:34 +0200 Date: Sun, 6 Apr 2003 18:45:34 +0200 (CEST) From: devik X-X-Sender: To: F-CPU Mailing List Subject: Re: [f-cpu] IDU News; synthesis report In-Reply-To: <20030406015206.54119@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Ok, results are: Device utilization summary: Number of External GCLKIOBs 1 out of 4 25% Number of External IOBs 7 out of 142 4% Number of LOCed External IOBs 0 out of 7 0% Number of SLICEs 3011 out of 3072 98% Number of GCLKs 1 out of 4 25% I have had to use Spartan2E because SRT is too big. On other side 2E has much faster routing so that timing for SRT is 90 MHz !! Synthesis ok, no warnings. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Sun, 6 Apr 2003, Michael Riepe wrote: > News of the Week: > > I finally made the SRT divider work. The first version supports signed > and unsigned division with chunk sizes of 8, 16, 32 and 64 bits (including > I'm waiting for synthesis results before I release the unit. But since > it's almost ready, and since this was the last mandatory integer EU > that was missing, I guess it's time to open a bottle of your favourite > beverage, and PARTY!!! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 6 20:29:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbC-0000H3-01 for ; Tue, 08 Apr 2003 01:00:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:00:22 +0200 (CEST) Received: (qmail 3160 invoked by uid 65534); 6 Apr 2003 22:20:21 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 07 Apr 2003 00:20:21 +0200 Received: by moria.seul.org (Postfix) id 087DB33B70; Sun, 6 Apr 2003 18:20:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB4E633C61; Sun, 6 Apr 2003 18:20:17 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id 31F3333B70 for ; Sun, 6 Apr 2003 18:20:16 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA00921; Sun, 6 Apr 2003 20:29:35 +0200 Message-ID: <20030406202934.18022@thrai.stud.uni-hannover.de> Date: Sun, 6 Apr 2003 20:29:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News References: <20030406015206.54119@thrai.stud.uni-hannover.de> <3E90409E.7090206@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E90409E.7090206@f-cpu.org>; from Yann Guidon on Sun, Apr 06, 2003 at 04:58:38PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Apr 06, 2003 at 04:58:38PM +0200, Yann Guidon wrote: > hi ! > > Michael Riepe wrote: > > >One open question remains, however: What shall I do next? ;( > > > well, given the exhausting party and your nickname, > i guess you can rest a bit ;-P I did ;-P But every time I try to rest for a longer time, I get crazy ideas. Like implementing a Galois Field (GF) multiplier, for example. That kind of instruction is usually found in DSPs, since it's used a lot in signal processing -- it's the basis for Reed-Solomon ECC. But it's also found in AES (aka Rijndael). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 7 00:36:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbD-0000H3-00 for ; Tue, 08 Apr 2003 01:00:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:00:23 +0200 (CEST) Received: (qmail 31740 invoked by uid 65534); 6 Apr 2003 22:36:10 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 07 Apr 2003 00:36:10 +0200 Received: by moria.seul.org (Postfix) id 38C2F33B7D; Sun, 6 Apr 2003 18:36:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8D54E33C6D; Sun, 6 Apr 2003 18:36:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a215.home.uni-hannover.de [130.75.232.215]) by moria.seul.org (Postfix) with ESMTP id 9BF2C33B7D for ; Sun, 6 Apr 2003 18:36:05 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02042; Mon, 7 Apr 2003 00:36:08 +0200 Message-ID: <20030407003608.25863@thrai.stud.uni-hannover.de> Date: Mon, 7 Apr 2003 00:36:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: <20030406015206.54119@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Sun, Apr 06, 2003 at 06:45:34PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Apr 06, 2003 at 06:45:34PM +0200, devik wrote: > Ok, results are: > Device utilization summary: > > Number of External GCLKIOBs 1 out of 4 25% > Number of External IOBs 7 out of 142 4% > Number of LOCed External IOBs 0 out of 7 0% > > Number of SLICEs 3011 out of 3072 98% > > Number of GCLKs 1 out of 4 25% > > I have had to use Spartan2E because SRT is too big. On other > side 2E has much faster routing so that timing for SRT is > 90 MHz !! Unfortunately, the numbers aren't comparable any longer :( > Synthesis ok, no warnings. Good :) I have changed some minor things to make the unit scale properly (chunk size is limited to 64 bits but word size is unlimited). I'm currently running the final tests (the testbenches take a while at 128 bits). I guess I can upload the latest version tomorrow. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 7 05:52:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbO-0000H3-00 for ; Tue, 08 Apr 2003 01:00:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:00:34 +0200 (CEST) Received: (qmail 14840 invoked by uid 65534); 7 Apr 2003 03:50:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 07 Apr 2003 05:50:51 +0200 Received: by moria.seul.org (Postfix) id B3DC733B52; Sun, 6 Apr 2003 23:50:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F096F33B66; Sun, 6 Apr 2003 23:50:48 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 849BE33B52 for ; Sun, 6 Apr 2003 23:50:48 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-20.n.club-internet.fr [213.44.12.20]) by relay-1m.club-internet.fr (Postfix) with ESMTP id B416016C2 for ; Mon, 7 Apr 2003 05:50:46 +0200 (CEST) Message-ID: <3E90F612.9070902@f-cpu.org> Date: Mon, 07 Apr 2003 05:52:50 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News References: <20030406015206.54119@thrai.stud.uni-hannover.de> <3E90409E.7090206@f-cpu.org> <20030406202934.18022@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Sun, Apr 06, 2003 at 04:58:38PM +0200, Yann Guidon wrote: > > >>hi ! >> >>Michael Riepe wrote: >> >>>One open question remains, however: What shall I do next? ;( >>> >>well, given the exhausting party and your nickname, >>i guess you can rest a bit ;-P >> >> > >I did ;-P > >But every time I try to rest for a longer time, I get crazy ideas. > ouch ! :-/ >Like implementing a Galois Field (GF) multiplier, for example. >That kind of instruction is usually found in DSPs, since it's used >a lot in signal processing -- it's the basis for Reed-Solomon ECC. >But it's also found in AES (aka Rijndael). > hmmmm .... i'd better check the maths about that .... indeed, there is a special issue of "Pour la Science" (the french translation of the american "Science" magazine) that is entirely dedicated to Evariste Galois. This has been highly advised to me, particularly because the explanations are cristal clear. They maybe explain all the secrets to ECC ... YG who should code more VHDL, otherwise F-CPU will become "Tired-CPU" :-P ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 7 13:23:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbp-0000H3-00 for ; Tue, 08 Apr 2003 01:01:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:01:01 +0200 (CEST) Received: (qmail 4975 invoked by uid 65534); 7 Apr 2003 17:32:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 07 Apr 2003 19:32:16 +0200 Received: by moria.seul.org (Postfix) id 95D0033B64; Mon, 7 Apr 2003 13:32:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 570C333B67; Mon, 7 Apr 2003 13:32:13 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a090.home.uni-hannover.de [130.75.232.90]) by moria.seul.org (Postfix) with ESMTP id A770733B64 for ; Mon, 7 Apr 2003 13:32:11 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00640; Mon, 7 Apr 2003 13:23:09 +0200 Message-ID: <20030407132308.48138@thrai.stud.uni-hannover.de> Date: Mon, 7 Apr 2003 13:23:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News References: <20030406015206.54119@thrai.stud.uni-hannover.de> <3E90409E.7090206@f-cpu.org> <20030406202934.18022@thrai.stud.uni-hannover.de> <3E90F612.9070902@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E90F612.9070902@f-cpu.org>; from Yann Guidon on Mon, Apr 07, 2003 at 05:52:50AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 07, 2003 at 05:52:50AM +0200, Yann Guidon wrote: [...] > >But every time I try to rest for a longer time, I get crazy ideas. > > > ouch ! :-/ No, that doesn't hurt ;-P [...] > indeed, there is a special issue of "Pour la Science" (the french > translation > of the american "Science" magazine) that is entirely dedicated to > Evariste Galois. Wow. By the way: how do you pronounce his name? > This has been highly advised to me, particularly because the > explanations are cristal clear. > They maybe explain all the secrets to ECC ... Probably not. But there are some documents on the Web that deal with the theory and implementation of Reed-Solomon ECC. > YG who should code more VHDL, otherwise F-CPU will become "Tired-CPU" :-P At least it won't be a "French CPU", as some people used to call it ;-P -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Mon Apr 7 19:35:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 192fbp-0000H3-01 for ; Tue, 08 Apr 2003 01:01:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 08 Apr 2003 01:01:01 +0200 (CEST) Received: (qmail 20683 invoked by uid 65534); 7 Apr 2003 17:36:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 07 Apr 2003 19:36:16 +0200 Received: by moria.seul.org (Postfix) id B8D9633B66; Mon, 7 Apr 2003 13:36:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 46FDF33B72; Mon, 7 Apr 2003 13:36:13 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-103.nerim.net [62.4.16.103]) by moria.seul.org (Postfix) with ESMTP id D7CC733B66 for ; Mon, 7 Apr 2003 13:36:12 -0400 (EDT) Received: from courbevoie-101-1-243.net1.nerim.net (courbevoie-101-1-243.net1.nerim.net [213.41.180.243]) by kraid.nerim.net (Postfix) with ESMTP id 4A5AC40F29 for ; Mon, 7 Apr 2003 19:36:10 +0200 (CEST) Subject: Re: [f-cpu] IDU News From: Antoine To: f-cpu@seul.org In-Reply-To: <20030407132308.48138@thrai.stud.uni-hannover.de> References: <20030406015206.54119@thrai.stud.uni-hannover.de> <3E90409E.7090206@f-cpu.org> <20030406202934.18022@thrai.stud.uni-hannover.de> <3E90F612.9070902@f-cpu.org> <20030407132308.48138@thrai.stud.uni-hannover.de> Content-Type: text/plain Message-Id: <1049736933.2781.0.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2-3mdk Date: 07 Apr 2003 19:35:33 +0200 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > YG who should code more VHDL, otherwise F-CPU will become "Tired-CPU" :-P > > At least it won't be a "French CPU", as some people used to call it ;-P You mean it will be a "Liberty CPU" ? ;-)) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 8 00:39:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1935BJ-0001D0-00 for ; Wed, 09 Apr 2003 04:19:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Apr 2003 04:19:21 +0200 (CEST) Received: (qmail 10657 invoked by uid 65534); 7 Apr 2003 22:39:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 08 Apr 2003 00:39:50 +0200 Received: by moria.seul.org (Postfix) id BBB1133B63; Mon, 7 Apr 2003 18:39:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8DBA333B78; Mon, 7 Apr 2003 18:39:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a250.home.uni-hannover.de [130.75.232.250]) by moria.seul.org (Postfix) with ESMTP id 5D8FD33B63 for ; Mon, 7 Apr 2003 18:39:45 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA01373; Tue, 8 Apr 2003 00:39:47 +0200 Message-ID: <20030408003947.20348@thrai.stud.uni-hannover.de> Date: Tue, 8 Apr 2003 00:39:47 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Upload Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N As promised earlier, fcpu-mr-20030407.tar.gz can now be found on f-cpu.seul.org. Major changes in this release: * eu_idu/*: new integer divide unit * eu_asu/iadd.vhdl: factored out the CLA procedure * eu_shl/shuffle64.vhdl: fixed shift count replicator * eu_*/Makefile: clean work library before testing -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 8 05:51:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1935Bp-0001D0-00 for ; Wed, 09 Apr 2003 04:19:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Apr 2003 04:19:53 +0200 (CEST) Received: (qmail 12988 invoked by uid 65534); 8 Apr 2003 11:42:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 08 Apr 2003 13:42:49 +0200 Received: by moria.seul.org (Postfix) id E21B433B71; Tue, 8 Apr 2003 07:42:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DBDCC33C5A; Tue, 8 Apr 2003 07:42:45 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a169.home.uni-hannover.de [130.75.232.169]) by moria.seul.org (Postfix) with ESMTP id D624633B71 for ; Tue, 8 Apr 2003 07:42:43 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id FAA02393; Tue, 8 Apr 2003 05:51:30 +0200 Message-ID: <20030408055130.35607@thrai.stud.uni-hannover.de> Date: Tue, 8 Apr 2003 05:51:30 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News References: <20030406015206.54119@thrai.stud.uni-hannover.de> <3E90409E.7090206@f-cpu.org> <20030406202934.18022@thrai.stud.uni-hannover.de> <3E90F612.9070902@f-cpu.org> <20030407132308.48138@thrai.stud.uni-hannover.de> <1049736933.2781.0.camel@fsol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <1049736933.2781.0.camel@fsol>; from Antoine on Mon, Apr 07, 2003 at 07:35:33PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 07, 2003 at 07:35:33PM +0200, Antoine wrote: > > > > YG who should code more VHDL, otherwise F-CPU will become "Tired-CPU" :-P > > > > At least it won't be a "French CPU", as some people used to call it ;-P > > You mean it will be a "Liberty CPU" ? ;-)) No - "liberty" does not begin with an "F" ;-) But since there are so many F-words out there, we'll probably find something appropriate ;-) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Apr 8 15:22:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1935C2-0001D0-01 for ; Wed, 09 Apr 2003 04:20:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Apr 2003 04:20:06 +0200 (CEST) Received: (qmail 4334 invoked by uid 65534); 8 Apr 2003 14:51:42 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 08 Apr 2003 16:51:42 +0200 Received: by moria.seul.org (Postfix) id 6467033C61; Tue, 8 Apr 2003 10:51:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8157933C5A; Tue, 8 Apr 2003 10:51:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 014EB33B48 for ; Tue, 8 Apr 2003 10:51:36 -0400 (EDT) Received: from a72-137.dialup.iol.cz ([194.228.137.72] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 192uRW-0007QX-00 for f-cpu@seul.org; Tue, 08 Apr 2003 16:51:22 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 192t3I-0000UX-00 for f-cpu@seul.org; Tue, 08 Apr 2003 15:22:16 +0200 Date: Tue, 8 Apr 2003 15:22:16 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IDU News; synthesis report In-Reply-To: <20030407003608.25863@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > I have had to use Spartan2E because SRT is too big. On other > > side 2E has much faster routing so that timing for SRT is > > 90 MHz !! > > Unfortunately, the numbers aren't comparable any longer :( Ok, ASU on 2E: 104.745MHz By the way, I synthetized scalar 64 bit adder and 32bit multiplier for compare. Adder (not pipelined): 120 MHz, 155 slices Adder (2 stages): 160 MHz, 198 slices Mult (not pipelined): 50 MHz, 344 slices devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 8 23:55:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1935Ch-0001D0-00 for ; Wed, 09 Apr 2003 04:20:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Apr 2003 04:20:47 +0200 (CEST) Received: (qmail 13584 invoked by uid 65534); 8 Apr 2003 21:55:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 08 Apr 2003 23:55:35 +0200 Received: by moria.seul.org (Postfix) id BE6F333B75; Tue, 8 Apr 2003 17:55:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1EB4C33B87; Tue, 8 Apr 2003 17:55:33 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a227.home.uni-hannover.de [130.75.232.227]) by moria.seul.org (Postfix) with ESMTP id 10E6133B75 for ; Tue, 8 Apr 2003 17:55:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id XAA03317; Tue, 8 Apr 2003 23:55:35 +0200 Message-ID: <20030408235534.42523@thrai.stud.uni-hannover.de> Date: Tue, 8 Apr 2003 23:55:34 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: <20030407003608.25863@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Apr 08, 2003 at 03:22:16PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Apr 08, 2003 at 03:22:16PM +0200, devik wrote: > > > I have had to use Spartan2E because SRT is too big. On other > > > side 2E has much faster routing so that timing for SRT is > > > 90 MHz !! > > > > Unfortunately, the numbers aren't comparable any longer :( > > Ok, ASU on 2E: 104.745MHz Looks good. > By the way, I synthetized scalar 64 bit adder and 32bit multiplier > for compare. > Adder (not pipelined): 120 MHz, 155 slices > Adder (2 stages): 160 MHz, 198 slices That's a plain adder, right? No subtract, saturate or average functions? > Mult (not pipelined): 50 MHz, 344 slices What kind of multiplier? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 9 11:44:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193HgA-0003SZ-00 for ; Wed, 09 Apr 2003 17:40:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 09 Apr 2003 17:40:02 +0200 (CEST) Received: (qmail 29032 invoked by uid 65534); 9 Apr 2003 13:01:45 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 09 Apr 2003 15:01:45 +0200 Received: by moria.seul.org (Postfix) id 6D57633C71; Wed, 9 Apr 2003 09:01:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 66C7233C0B; Wed, 9 Apr 2003 09:01:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E3A3433B89 for ; Wed, 9 Apr 2003 09:01:40 -0400 (EDT) Received: from a51-137.dialup.iol.cz ([194.228.137.51] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 193FCp-0004g6-00 for f-cpu@seul.org; Wed, 09 Apr 2003 15:01:36 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 193C7q-0000Ka-00 for f-cpu@seul.org; Wed, 09 Apr 2003 11:44:14 +0200 Date: Wed, 9 Apr 2003 11:44:13 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IDU News; synthesis report In-Reply-To: <20030408235534.42523@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > Ok, ASU on 2E: 104.745MHz > > Looks good. yes :) And 117 MHz on Virtex2. > > By the way, I synthetized scalar 64 bit adder and 32bit multiplier > > for compare. > > Adder (not pipelined): 120 MHz, 155 slices > > Adder (2 stages): 160 MHz, 198 slices > > That's a plain adder, right? No subtract, saturate or average > functions? exactly. It is ripple carry adder. I did pipelined one by splitting it into 2 32 bit parts. XST detects "+" operators and uses internal fast-carry chain. It needs only 50 ps (picoseconds) per carry. Pipelined one runs at 164 MHz and 113 slices in Virtex2. > > Mult (not pipelined): 50 MHz, 344 slices > > What kind of multiplier? Don't know. I simply used "*" and XST synthetized one using its dedicated resources (fast carry and "AND-chain"). I also tested it with Virtex2. It used 3 on-chip 18x18 multipliers and goes 90MHz (single cycle 32 bit MUL). devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Apr 9 21:06:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193SuE-0002go-01 for ; Thu, 10 Apr 2003 05:39:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 10 Apr 2003 05:39:18 +0200 (CEST) Received: (qmail 6427 invoked by uid 65534); 9 Apr 2003 22:53:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 10 Apr 2003 00:53:39 +0200 Received: by moria.seul.org (Postfix) id 6A3F533B5C; Wed, 9 Apr 2003 18:53:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A2B933B69; Wed, 9 Apr 2003 18:53:36 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a106.home.uni-hannover.de [130.75.232.106]) by moria.seul.org (Postfix) with ESMTP id 703F033B5C for ; Wed, 9 Apr 2003 18:53:33 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id VAA00478; Wed, 9 Apr 2003 21:06:25 +0200 Message-ID: <20030409210625.19549@thrai.stud.uni-hannover.de> Date: Wed, 9 Apr 2003 21:06:25 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: <20030408235534.42523@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=G4iJoqBmSsgzjUCe X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, Apr 09, 2003 at 11:44:13AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii On Wed, Apr 09, 2003 at 11:44:13AM +0200, devik wrote: > > > Ok, ASU on 2E: 104.745MHz > > > > Looks good. > > yes :) And 117 MHz on Virtex2. Even better :) > > > By the way, I synthetized scalar 64 bit adder and 32bit multiplier > > > for compare. > > > Adder (not pipelined): 120 MHz, 155 slices > > > Adder (2 stages): 160 MHz, 198 slices > > > > That's a plain adder, right? No subtract, saturate or average > > functions? > > exactly. It is ripple carry adder. I did pipelined one by > splitting it into 2 32 bit parts. > XST detects "+" operators and uses internal fast-carry > chain. It needs only 50 ps (picoseconds) per carry. Can you try a simple carry-select adder? I'll attach a copy. > Pipelined one runs at 164 MHz and 113 slices in Virtex2. > > > > Mult (not pipelined): 50 MHz, 344 slices > > > > What kind of multiplier? > > Don't know. I simply used "*" and XST synthetized one using > its dedicated resources (fast carry and "AND-chain"). > I also tested it with Virtex2. It used 3 on-chip 18x18 > multipliers and goes 90MHz (single cycle 32 bit MUL). But unfortunately it doesn't do what we want either. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="simple_adder.vhdl" -- simple_adder.vhdl -- 64-bit carry select adder -- Copyright (C) 2003 Michael Riepe -- -- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License as published by -- the Free Software Foundation; either version 2 of the License, or -- (at your option) any later version. -- -- This program is distributed in the hope that it will be useful, -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- GNU General Public License for more details. -- -- You should have received a copy of the GNU General Public License -- along with this program; if not, write to the Free Software -- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- @(#) $Id$ library IEEE; use IEEE.std_logic_1164.all; entity Simple_Adder is generic ( WIDTH : natural := 64 ); port ( A : in std_ulogic_vector(WIDTH-1 downto 0); B : in std_ulogic_vector(WIDTH-1 downto 0); -- Y : out std_ulogic_vector(WIDTH-1 downto 0); Z : out std_ulogic_vector(WIDTH-1 downto 0) ); end Simple_Adder; architecture Behave_1 of Simple_Adder is -- carry look-ahead circuit -- d=1-2 procedure CLA (Gi, Pi : in std_ulogic_vector; Go, Po : out std_ulogic_vector) is constant L : natural := Gi'length; begin --pragma synthesis_off assert L mod 4 = 0; assert (Gi'left = L-1) and (Gi'right = 0); assert (Pi'left = L-1) and (Pi'right = 0); assert (Go'left = L/4-1) and (Go'right = 0); assert (Po'left = L/4-1) and (Po'right = 0); --pragma synthesis_on for i in L/4-1 downto 0 loop Go(i) := Gi(4*i+3) or (Pi(4*i+3) and Gi(4*i+2)) or (Pi(4*i+3) and Pi(4*i+2) and Gi(4*i+1)) or (Pi(4*i+3) and Pi(4*i+2) and Pi(4*i+1) and Gi(4*i+0)); Po(i) := Pi(4*i+3) and Pi(4*i+2) and Pi(4*i+1) and Pi(4*i+0); end loop; end CLA; -- carry select vectors -- d=2 procedure CSV (G, P : in std_ulogic_vector; S, T : out std_ulogic_vector) is constant L : natural := G'length; begin --pragma synthesis_off assert L mod 4 = 0; assert (G'left = L-1) and (G'right = 0); assert (P'left = L-1) and (P'right = 0); assert (S'left = L-1) and (S'right = 0); assert (T'left = L-1) and (T'right = 0); --pragma synthesis_on for i in L/4-1 downto 0 loop S(4*i+0) := '0'; S(4*i+1) := G(4*i+0); S(4*i+2) := G(4*i+1) or (P(4*i+1) and G(4*i+0)); S(4*i+3) := G(4*i+2) or (P(4*i+2) and G(4*i+1)) or (P(4*i+2) and P(4*i+1) and G(4*i+0)); T(4*i+0) := '1'; T(4*i+1) := G(4*i+0) or P(4*i+0); T(4*i+2) := G(4*i+1) or (P(4*i+1) and G(4*i+0)) or (P(4*i+1) and P(4*i+0)); T(4*i+3) := G(4*i+2) or (P(4*i+2) and G(4*i+1)) or (P(4*i+2) and P(4*i+1) and G(4*i+0)) or (P(4*i+2) and P(4*i+1) and P(4*i+0)); end loop; end CSV; begin adder : process (A, B) variable G0, P0 : std_ulogic_vector(WIDTH-1 downto 0); variable G1, P1 : std_ulogic_vector(WIDTH/4-1 downto 0); variable G2, P2 : std_ulogic_vector(WIDTH/16-1 downto 0); variable G3, P3 : std_ulogic_vector(WIDTH/64-1 downto 0); variable S0, T0 : std_ulogic_vector(WIDTH-1 downto 0); variable S1, T1 : std_ulogic_vector(WIDTH/4-1 downto 0); variable S2, T2 : std_ulogic_vector(WIDTH/16-1 downto 0); variable Y1, Z1 : std_ulogic_vector(WIDTH-1 downto 0); variable Y2, Z2 : std_ulogic_vector(WIDTH-1 downto 0); variable Y3, Z3 : std_ulogic_vector(WIDTH-1 downto 0); begin -- input stage (half adders) -- d=1 P0 := A xor B; G0 := A and B; -- carry look-ahead tree -- d=3 CLA(G0, P0, G1, P1); -- d=5 CLA(G1, P1, G2, P2); -- d=7 CLA(G2, P2, G3, P3); -- carry select vectors -- d=3 CSV(G0, P0, S0, T0); -- d=5 CSV(G1, P1, S1, T1); -- d=7 CSV(G2, P2, S2, T2); -- 4-bit partial results -- d=4 Y1 := P0 xor S0; Z1 := P0 xor T0; -- 16-bit partial results -- d=6 for i in WIDTH/4-1 downto 0 loop if to_X01(S1(i)) = '1' then Y2(4*i+3 downto 4*i) := Z1(4*i+3 downto 4*i); else Y2(4*i+3 downto 4*i) := Y1(4*i+3 downto 4*i); end if; if to_X01(T1(i)) = '1' then Z2(4*i+3 downto 4*i) := Z1(4*i+3 downto 4*i); else Z2(4*i+3 downto 4*i) := Y1(4*i+3 downto 4*i); end if; end loop; -- 64-bit result -- d=8 for i in WIDTH/16-1 downto 0 loop if to_X01(S2(i)) = '1' then Y3(16*i+15 downto 16*i) := Z2(16*i+15 downto 16*i); else Y3(16*i+15 downto 16*i) := Y2(16*i+15 downto 16*i); end if; if to_X01(T2(i)) = '1' then Z3(16*i+15 downto 16*i) := Z2(16*i+15 downto 16*i); else Z3(16*i+15 downto 16*i) := Y2(16*i+15 downto 16*i); end if; end loop; Y <= Y3; Z <= Z3; end process; end Behave_1; -- vi: set ts=4 sw=4 equalprg="fmt -72 -p--": please --G4iJoqBmSsgzjUCe-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Apr 10 14:46:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193sjX-0003lD-00 for ; Fri, 11 Apr 2003 09:13:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 09:13:59 +0200 (CEST) Received: (qmail 23665 invoked by uid 65534); 10 Apr 2003 13:51:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 10 Apr 2003 15:51:01 +0200 Received: by moria.seul.org (Postfix) id C729933B79; Thu, 10 Apr 2003 09:50:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 812CB33B7F; Thu, 10 Apr 2003 09:50:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 28A8C33B79 for ; Thu, 10 Apr 2003 09:50:54 -0400 (EDT) Received: from a70-137.dialup.iol.cz ([194.228.137.70] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 193cS1-0002OW-00 for f-cpu@seul.org; Thu, 10 Apr 2003 15:50:50 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 193bRT-0000Hg-00 for f-cpu@seul.org; Thu, 10 Apr 2003 14:46:11 +0200 Date: Thu, 10 Apr 2003 14:46:11 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IDU News; synthesis report In-Reply-To: <20030409210625.19549@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > > > > By the way, I synthetized scalar 64 bit adder and 32bit multiplier > > > > for compare. > > > > Adder (not pipelined): 120 MHz, 155 slices > > > > Adder (2 stages): 160 MHz, 198 slices > > > > > > That's a plain adder, right? No subtract, saturate or average > > > functions? > > > > exactly. It is ripple carry adder. I did pipelined one by > > splitting it into 2 32 bit parts. > > XST detects "+" operators and uses internal fast-carry > > chain. It needs only 50 ps (picoseconds) per carry. > > Can you try a simple carry-select adder? I'll attach a copy. Ok, 310 slices, 65 MHz on Spartan2E. Seems ripple one is superior on fpga because they have dedicated circuits for it. Maybe one could create 8 8bit ripple adders and add carries in next stage - these +1 adders could use fast carry chain again ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Apr 10 15:41:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193sjX-0003lD-01 for ; Fri, 11 Apr 2003 09:13:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 09:13:59 +0200 (CEST) Received: (qmail 21632 invoked by uid 65534); 10 Apr 2003 13:51:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 10 Apr 2003 15:51:03 +0200 Received: by moria.seul.org (Postfix) id AFAC233B85; Thu, 10 Apr 2003 09:50:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA17933B83; Thu, 10 Apr 2003 09:50:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 8047333B7A for ; Thu, 10 Apr 2003 09:50:56 -0400 (EDT) Received: from a70-137.dialup.iol.cz ([194.228.137.70] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 193cRv-0002OW-00 for f-cpu@seul.org; Thu, 10 Apr 2003 15:50:44 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 193cIw-0000I9-00 for f-cpu@seul.org; Thu, 10 Apr 2003 15:41:26 +0200 Date: Thu, 10 Apr 2003 15:41:26 +0200 (CEST) From: devik X-X-Sender: To: Subject: [f-cpu] DCT in VHDL Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-235673950-1049982086=:562" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-235673950-1049982086=:562 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I wanted to create videocompresor in fpga, to have 4 cameras connected to cheap box which would stream it to Ethernet. Because one videostream is about 60Mbit/s I wanted to do cheap compresion. I know there is DCT (and other parts of mpeg) at opencodes.org but it is too large. I tried to compute 6 point DCT matrix - it seems nice, you need only constants 1/2, 1/(2 sqrt(2)), 1/sqrt(3) and 1/sqrt(6). So I did exhaustive search to find good coeficient scale. I found that if you use scale 14037 then these constants are 1b6a, 1fa8, 1362 and 1662. If you look at them closely you find that they need only 15 adds to implement multiply for all of these constants (I was searching for these constants whose have a few bits set and have large overlap in them). Thus I was able to synthetize whole 1D 6 point pipelined DCT into 342 Spartan slices and tracer estimates 60MHz for it. What I need next is second pass to form 2D transform. It will need 21 bit inputs instead of 8 bits thus it will be much more complex :-\ Just I'm interested if someone has some ideas about design (attached). It is my first VHDL I wrote ;). ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ --8323328-235673950-1049982086=:562 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="test2.vhd" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="test2.vhd" LS0gZGV2aWtAY2RpLmN6OyA2IHBvaW50IDFEIERDVA0NCg0NCmxpYnJhcnkg SUVFRTsNDQp1c2UgSUVFRS5TVERfTE9HSUNfMTE2NC5BTEw7DQ0KdXNlIElF RUUuU1REX0xPR0lDX0FSSVRILkFMTDsNDQp1c2UgSUVFRS5TVERfTE9HSUNf VU5TSUdORUQuQUxMOw0NCg0NCmVudGl0eSB0ZXN0IGlzDQ0KICAgIFBvcnQg KCAJWE9VVCA6IG91dCBzdGRfbG9naWNfdmVjdG9yKDIwIGRvd250byAwKTsN DQoJCVhJTiA6IGluIHN0ZF9sb2dpY192ZWN0b3IoNyBkb3dudG8gMCk7DQ0K CQljbGsgOiBpbiBzdGRfbG9naWMNDQoJCQkJKTsNDQplbmQgdGVzdDsNDQoN DQphcmNoaXRlY3R1cmUgQmVoYXZpb3JhbCBvZiB0ZXN0IGlzDQ0KCXR5cGUg bWF0cml4IGlzIGFycmF5IChuYXR1cmFsIHJhbmdlIDw+KQ0NCgkgICAgICAg IG9mIHN0ZF9sb2dpY192ZWN0b3IoMjAgZG93bnRvIDApOw0NCg0NCglmdW5j dGlvbiB4c3JsIChBIDogaW4gc3RkX2xvZ2ljX3ZlY3RvcikgcmV0dXJuIHN0 ZF9sb2dpY192ZWN0b3IgaXMNDQoJCWNvbnN0YW50IHcgOiBuYXR1cmFsIDo9 IEEnbGVuZ3RoOw0NCgliZWdpbg0NCgkJcmV0dXJuICcwJyAmIEEodyBkb3du dG8gMSk7DQ0KCWVuZCB4c3JsOw0NCg0NCglzaWduYWwgdG1wIDogc3RkX2xv Z2ljOw0NCglzaWduYWwgYiA6IHN0ZF9sb2dpY192ZWN0b3IoNyBkb3dudG8g MCk7DQ0KDQ0KCS0tIGFjdHVhbCBEQ1QgcG9pbnQgKDAuLjUpDQ0KCXNpZ25h bCBjbnQgOiBzdGRfbG9naWNfdmVjdG9yKDIgZG93bnRvIDApOw0NCg0NCgkt LSBvdXRwdXQgb2YgbXVsdGlwbGllciBzdGFnZTsgb25lIHJlc3VsdCB2ZWN0 IHBlciBjbG9jaw0NCglzaWduYWwgYzAgOiBtYXRyaXgoMyBkb3dudG8gMCk7 DQ0KDQ0KCS0tIG91dHB1dCBzdW1zOyB2YWxpZCBhdCBlbmQgb2YgY3ljbGUg d2hlcmUgY250PTUNDQoJc2lnbmFsIHMwIDogc3RkX2xvZ2ljX3ZlY3Rvcigy MCBkb3dudG8gMCk7DQ0KCXNpZ25hbCBzMSA6IHN0ZF9sb2dpY192ZWN0b3Io MjAgZG93bnRvIDApOw0NCglzaWduYWwgczIgOiBzdGRfbG9naWNfdmVjdG9y KDIwIGRvd250byAwKTsNDQoJc2lnbmFsIHMzIDogc3RkX2xvZ2ljX3ZlY3Rv cigyMCBkb3dudG8gMCk7DQ0KCXNpZ25hbCBzNCA6IHN0ZF9sb2dpY192ZWN0 b3IoMjAgZG93bnRvIDApOw0NCglzaWduYWwgczUgOiBzdGRfbG9naWNfdmVj dG9yKDIwIGRvd250byAwKTsNDQogICANDQpiZWdpbg0NCglzdGFnZV8xIDog cHJvY2VzcyAoYzAsczAsczEsczIsczMsczQsczUsYixYSU4sY2xrKQ0NCgkJ dmFyaWFibGUgdCxxLGUxLGUyLGUzLGU0LGU1IDogc3RkX2xvZ2ljX3ZlY3Rv cigyMCBkb3dudG8gMCk7DQ0KCQl2YXJpYWJsZSBuMSxuMixuNSA6IGJvb2xl YW47DQ0KCWJlZ2luDQ0KCQlpZiByaXNpbmdfZWRnZShjbGspIHRoZW4NDQoJ CQktLSBmZWVkIG5leHQgaW1hZ2UgcG9pbnQNDQoJCQliIDw9IFhJTjsNDQoN DQoJCQktLSBtdWx0aXBsaWVyIHN0YWdlOyB0aGVzZSBjYXJlZnVseSBjcmFm dGVkIGNvbnN0YW50cw0NCgkJCS0tIHJlc3VsdHMgaW4gc21hbGwgYW5kIHNp bXBsZSBtdWx0aXBsaWVycyB3aG9zZSBjYW4NDQoJCQktLSBzaGFyZSBtYW55 IGFkZGVycw0NCgkJCWMwKDApIDw9IGIqY29udl9zdGRfbG9naWNfdmVjdG9y KDcwMTgsMTMpOw0NCgkJCWMwKDEpIDw9IGIqY29udl9zdGRfbG9naWNfdmVj dG9yKDgxMDQsMTMpOw0NCgkJCWMwKDIpIDw9IGIqY29udl9zdGRfbG9naWNf dmVjdG9yKDU3MzAsMTMpOw0NCgkJCWMwKDMpIDw9IGIqY29udl9zdGRfbG9n aWNfdmVjdG9yKDQ5NjIsMTMpOw0NCg0NCgkJCS0tIGMwIChhdmVyYWdlKQ0N CgkJCXMwIDw9IHMwICsgYzAoMyk7DQ0KDQ0KCQkJLS0gcHJlcGFyZSAoc3Fy dCgzKSstMSkvMnNxcnQoNikgY29uc3RhbnRzDQ0KCQkJdCA6PSBjMCgyKSt4 c3JsKGMwKDMpKTsNDQoJCQlxIDo9IGMwKDIpLXhzcmwoYzAoMykpOw0NCg0N CgkJCS0tIGRvIE1BQ3MNDQoJCQljYXNlIGNudCBpcw0NCgkJCSAgICB3aGVu IE8iMSJ8TyIyInxPIjUiICA9PiBzMyA8PSBzMyAtIGMwKDMpOw0NCgkJCSAg ICB3aGVuIG90aGVycyA9PiAgICAgICAgICBzMyA8PSBzMyArIGMwKDMpOw0N CgkJCWVuZCBjYXNlOw0NCgkJCWNhc2UgY250IGlzDQ0KCQkJICAgIHdoZW4g TyIwInxPIjUiICA9PiBlMiA6PSBjMCgwKTsgbjIgOj0gZmFsc2U7DQ0KCQkJ ICAgIHdoZW4gTyIyInxPIjMiICA9PiBlMiA6PSBjMCgwKTsgbjIgOj0gdHJ1 ZTsNDQoJCQkgICAgd2hlbiBvdGhlcnMgICAgID0+IGUyIDo9IChvdGhlcnM9 PicwJyk7DQ0KCQkJZW5kIGNhc2U7DQ0KCQkJLS0gdHJpY2sgbmVlZGVkIHRv IGZvcmNlIGJpZGlyIEFjdW11bGF0b3IgaW5mZXJlbmNlIGluIFhTVA0NCgkJ CWlmIG4yIHRoZW4NDQoJCQkJczIgPD0gczIgLSBlMjsNDQoJCQllbHNlDQ0K CQkJCXMyIDw9IHMyICsgZTI7DQ0KCQkJZW5kIGlmOw0NCgkJCWNhc2UgY250 IGlzDQ0KCQkJICAgIHdoZW4gTyIxInxPIjQiICA9PiBzNCA8PSBzNCAtIGMw KDEpOw0NCgkJCSAgICB3aGVuIG90aGVycyA9PiBzNCA8PSBzNCArIHhzcmwo YzAoMSkpOw0NCgkJCWVuZCBjYXNlOw0NCgkJCW4xIDo9IGZhbHNlOw0NCgkJ CW41IDo9IGZhbHNlOw0NCgkJCWNhc2UgY250IGlzDQ0KCQkJICAgIHdoZW4g TyIwIiA9PiAgIGUxIDo9IHQ7IGU1IDo9IHE7DQ0KCQkJICAgIHdoZW4gTyIx IiA9PiAgIGUxIDo9IGMwKDMpOyBlNSA6PSBjMCgzKTsgbjUgOj0gdHJ1ZTsN DQoJCQkgICAgd2hlbiBPIjIiID0+ICAgZTEgOj0gcTsgZTUgOj0gdDsNDQoJ CQkgICAgd2hlbiBPIjMiID0+ICAgZTEgOj0gcTsgZTUgOj0gdDsgbjEgOj0g dHJ1ZTsgbjUgOj0gdHJ1ZTsNDQoJCQkgICAgd2hlbiBPIjQiID0+ICAgZTEg Oj0gYzAoMyk7IGU1IDo9IGMwKDMpOyBuMSA6PSB0cnVlOw0NCgkJCSAgICB3 aGVuIE8iNSIgPT4gICBlMSA6PSB0OyBlNSA6PSBxOyBuMSA6PSB0cnVlOyBu NSA6PSB0cnVlOw0NCgkJCSAgICB3aGVuIG90aGVycyA9PiBlMSA6PSAob3Ro ZXJzPT4nWCcpOyBlNSA6PSAob3RoZXJzPT4nWCcpOw0NCgkJCWVuZCBjYXNl Ow0NCgkJCWlmIG4xIHRoZW4NDQoJCQkJczEgPD0gczEgLSBlMTsNDQoJCQll bHNlDQ0KCQkJCXMxIDw9IHMxICsgZTE7DQ0KCQkJZW5kIGlmOw0NCgkJCWlm IG41IHRoZW4NDQoJCQkJczUgPD0gczUgLSBlNTsNDQoJCQllbHNlDQ0KCQkJ CXM1IDw9IHM1ICsgZTU7DQ0KCQkJZW5kIGlmOw0NCgkJCWNhc2UgY250IGlz DQ0KCQkJICAgIHdoZW4gTyI1IiAgICAgPT4gICBjbnQgPD0gIjAwMCI7DQ0K CQkJICAgIHdoZW4gb3RoZXJzID0+ICAgY250IDw9IGNudCArIDE7DQ0KCQkJ ZW5kIGNhc2U7DQ0KCQkJLS1zMiA8PSBzMiArIGUyOw0NCgkJCS0tczMgPD0g czMgKyBlMzsNDQoJCQkNDQoJCQktLSBmaWN0aXZlIG91dHB1dCB0byBmb3Jj ZSBYU1QgdG8ga2VlcCB0aGUgZGVzaWduCQkNDQoJCQlYT1VUIDw9IHMwIHhv ciBzMSB4b3IgczIgeG9yIHMzIHhvciBzNCB4b3IgczU7DQ0KDQ0KCQllbmQg aWY7DQ0KCWVuZCBwcm9jZXNzOw0NCmVuZCBCZWhhdmlvcmFsOw0NCg== --8323328-235673950-1049982086=:562-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Thu Apr 10 18:36:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193sji-0003lD-00 for ; Fri, 11 Apr 2003 09:14:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 09:14:10 +0200 (CEST) Received: (qmail 14227 invoked by uid 65534); 10 Apr 2003 17:39:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 10 Apr 2003 19:39:12 +0200 Received: by moria.seul.org (Postfix) id 8B72133B8D; Thu, 10 Apr 2003 13:39:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA01133B8B; Thu, 10 Apr 2003 13:39:09 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id AE3DB33B7A for ; Thu, 10 Apr 2003 13:39:08 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-196.jetnet.ab.ca [207.34.60.196]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h3AHdC5G092098 for ; Thu, 10 Apr 2003 11:39:13 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E959D75.9060108@jetnet.ab.ca> Date: Thu, 10 Apr 2003 10:36:05 -0600 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N devik wrote: > Ok, 310 slices, 65 MHz on Spartan2E. Seems ripple one > is superior on fpga because they have dedicated circuits > for it. Maybe one could create 8 8bit ripple adders > and add carries in next stage - these +1 adders could > use fast carry chain again ... However if one optimizes too far for a FPA version this limits hardware mostly to one vender.I think what is needed is a generic F-CPU hardware ( and virtual cpu model ) for now. A good example (in software)is the fig-forth generic virtual machine, that could be ported to quickly to different 8/16 bit machines. It seems nowdays that a efficent virtual model is important than raw cpu speed since most code is running virtual rather than on real hardware. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 10 19:45:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193sjl-0003lD-00 for ; Fri, 11 Apr 2003 09:14:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 09:14:13 +0200 (CEST) Received: (qmail 27693 invoked by uid 65534); 10 Apr 2003 18:00:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 10 Apr 2003 20:00:43 +0200 Received: by moria.seul.org (Postfix) id B17E633B7A; Thu, 10 Apr 2003 14:00:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B36233BD6; Thu, 10 Apr 2003 14:00:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a247.home.uni-hannover.de [130.75.232.247]) by moria.seul.org (Postfix) with ESMTP id 7DAF533B7A for ; Thu, 10 Apr 2003 14:00:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01481; Thu, 10 Apr 2003 19:45:21 +0200 Message-ID: <20030410194521.01503@thrai.stud.uni-hannover.de> Date: Thu, 10 Apr 2003 19:45:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: <20030409210625.19549@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Apr 10, 2003 at 02:46:11PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Apr 10, 2003 at 02:46:11PM +0200, devik wrote: [...] > > Can you try a simple carry-select adder? I'll attach a copy. > > Ok, 310 slices, 65 MHz on Spartan2E. Seems ripple one > is superior on fpga because they have dedicated circuits > for it. Maybe one could create 8 8bit ripple adders > and add carries in next stage - these +1 adders could > use fast carry chain again ... Design criteria for FPGAs are very different. In most FPGAs, every logical function with 3 or 4 inputs will have the same delay, for example. In some chips, a 1-bit full adder is as fast as a 2-input nand gate, which is definitely not true for custom chips (where the nand gate is approximately 3-4 times as fast). The delay of a ripple-carry adder is O(n), while a carry-select adder has a delay of O(log(n)). Ripple-carry adders work fine in some FPGAs because they have fast carry chains *and* cell delays that are much higher than the delay of a single gate in a custom chip -- remember that a cell usually contains input and output muxes and a LUT (at least). Their trick is to bypass the normal data path and use pre-routed lines to speed up the carry chain. The whole secret is that the O(x) part of the delay formula *varies* with the kind of adder, or with the propagation direction of your data: forward = slow, sideways = fast. In a custom chip, O(x) is mostly immutable; as a consequence, a 64-bit parallel-prefix adder will run a lot faster than a 64-bit ripple-carry adder. Earlier synthesis runs with Synopsys reported 389 MHz for IAdd and 458 MHz for IMul64 (that were the previous versions; the current ones are probably even faster, but I haven't got any numbers yet). You'll never beat that with a ripple-carry adder, not even in 8-bit mode: The carry chain will be 16 gates long (16 transistor levels). My carry-select adder requires only 5 gates (7 transistors) for an 8-bit result. The F-CPU pipeline limit is 6 gates / 10 transistors (which is usually referred to as the `6G Rule' or `6G/10T Rule'). In an FPGA, things are turned upside down and inside out: The 8-bit carry-select adder will be ~4 cells deep, while an equivalent ripple-carry adder with fast carry gets away with a depth of only 1-2 cells. Without fast carry, on the other hand, its delay will increase dramatically (best case: 8 cells). To cut a long story short: For an *efficient* FPGA implementation, we would have to re-design most units. In fact, we would also have to take the type of FPGA into account if we want maximum performance. That would be too much work -- remember that there are only few active developers, and even less VHDL coders. On the other hand, we distribute the source code, and any user who wants to tune it for a specific FPGA may do so. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 10 22:47:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193sjt-0003lD-00 for ; Fri, 11 Apr 2003 09:14:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 09:14:21 +0200 (CEST) Received: (qmail 31358 invoked by uid 65534); 10 Apr 2003 22:05:47 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 11 Apr 2003 00:05:47 +0200 Received: by moria.seul.org (Postfix) id F28A133B59; Thu, 10 Apr 2003 18:05:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB1AD33B7F; Thu, 10 Apr 2003 18:05:43 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a088.home.uni-hannover.de [130.75.232.88]) by moria.seul.org (Postfix) with ESMTP id 1620733B59 for ; Thu, 10 Apr 2003 18:05:41 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id WAA02141; Thu, 10 Apr 2003 22:47:13 +0200 Message-ID: <20030410224713.03931@thrai.stud.uni-hannover.de> Date: Thu, 10 Apr 2003 22:47:13 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DCT in VHDL References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Apr 10, 2003 at 03:41:26PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Apr 10, 2003 at 03:41:26PM +0200, devik wrote: [...] > I tried to compute 6 point DCT matrix - it seems > nice, you need only constants 1/2, 1/(2 sqrt(2)), > 1/sqrt(3) and 1/sqrt(6). > So I did exhaustive search to find good coeficient > scale. I found that if you use scale 14037 then > these constants are 1b6a, 1fa8, 1362 and 1662. > If you look at them closely you find that they > need only 15 adds to implement multiply for all > of these constants (I was searching for these constants > whose have a few bits set and have large overlap in them). Good design :) > Thus I was able to synthetize whole 1D 6 point pipelined > DCT into 342 Spartan slices and tracer estimates 60MHz for it. > > What I need next is second pass to form 2D transform. > It will need 21 bit inputs instead of 8 bits thus it > will be much more complex :-\ > > Just I'm interested if someone has some ideas about design > (attached). It is my first VHDL I wrote ;). But the coding style looks familiar ;) [...] > architecture Behavioral of test is > type matrix is array (natural range <>) > of std_logic_vector(20 downto 0); > > function xsrl (A : in std_logic_vector) return std_logic_vector is > constant w : natural := A'length; > begin > return '0' & A(w downto 1); > end xsrl; You made a tiny mistake here. Note that A has an unspecified range, which means that it is taken from the actual argument. It could be (n-1 downto 0), (n downto 1) oder even (1 to n). In your design, it's (20 downto 0) -- that is, `w' is 21. Unfortunately, that means that A(w downto 1) is not a valid expression. In fact, it isn't in most cases, and it rarely does what you expect it to. A trick to avoid that kind of error is to copy the argument to a vector of the same length, but with a well-defined range: function xsrl (A : in std_logic_vector) return std_logic_vector is constant w : natural := A'length; variable aa : std_logic_vector(w-1 downto 0); begin aa := A; -- automagically converts index range return '0' & aa(w-1 downto 1); end xsrl; You'll find that idiom a lot in my code (I used to use aliases, but as we both know, the Xilinx synthesizer doesn't grok them). Even more often, you'll see that I convert the index range of the result, too: function xsrl (A : in std_logic_vector) return std_logic_vector is constant w : natural := A'length; variable aa : std_logic_vector(w-1 downto 0); variable yy : std_logic_vector(w-1 downto 0); begin aa := A; -- automagically converts index range yy(w-1) := '0'; yy(w-2 downto 0) := aa(w-1 downto 1); return yy; end xsrl; That way the results of my functions have a consistent index range (descending and 0-based, unless otherwise noted). I find that very convenient, and it also helps me to avoid stupid indexing mistakes. You could also specify the index range in the formal parameter list, but that has an important drawback: The range will be fixed. For generic functions (which are always preferable), an unspecified (and therefore variable) range is needed. [...] > -- actual DCT point (0..5) > signal cnt : std_logic_vector(2 downto 0); [...] It's probably better to use "one-hot" encoding here: -- declarations constant STATES : positive := 6; -- may also be a GENERIC signal cnt : std_logic_vector(STATES-1 downto 0); -- initialization/reset -- Note: synthesizers don't like vector assignments that contain -- both explicit indices and "others". cnt <= (others => '0'); cnt(0) <= '1'; -- update (a simple left rotate) variable tmp : std_logic_vector(STATES-1 downto 0); -- and then: tmp(STATES-1 downto 1) := cc(STATES-2 downto 0); tmp(0) := cc(STATES-1); cnt <= tmp; This code scales much better (just change the value of STATES), the shift register can be updated more easily than a binary counter (you'll also save an add/increment circuit), and its output will be faster to decode in most cases. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Apr 11 10:33:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193zxK-0000yQ-00 for ; Fri, 11 Apr 2003 16:56:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 16:56:42 +0200 (CEST) Received: (qmail 7889 invoked by uid 65534); 11 Apr 2003 08:59:13 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 11 Apr 2003 10:59:13 +0200 Received: by moria.seul.org (Postfix) id EA27B33C0F; Fri, 11 Apr 2003 04:59:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 16F6333BDE; Fri, 11 Apr 2003 04:59:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id C46DA33B82 for ; Fri, 11 Apr 2003 04:59:07 -0400 (EDT) Received: from a37-137.dialup.iol.cz ([194.228.137.37] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 193uN4-0006vv-00 for f-cpu@seul.org; Fri, 11 Apr 2003 10:58:55 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 193tyd-0000G3-00 for f-cpu@seul.org; Fri, 11 Apr 2003 10:33:39 +0200 Date: Fri, 11 Apr 2003 10:33:39 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] DCT in VHDL In-Reply-To: <20030410224713.03931@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi Michael, thanks for your comments. When I got some time I'll try to continue on it :-) By the way is there some good vhdl simulator running on Linux ? devik > > end xsrl; > > You made a tiny mistake here. Note that A has an unspecified range, > which means that it is taken from the actual argument. It could be > (n-1 downto 0), (n downto 1) oder even (1 to n). In your design, it's .... .... ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Fri Apr 11 10:46:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 193zxL-0000yQ-00 for ; Fri, 11 Apr 2003 16:56:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 16:56:43 +0200 (CEST) Received: (qmail 2125 invoked by uid 65534); 11 Apr 2003 08:59:28 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 11 Apr 2003 10:59:28 +0200 Received: by moria.seul.org (Postfix) id 9770A33B82; Fri, 11 Apr 2003 04:59:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4112833C1A; Fri, 11 Apr 2003 04:59:20 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 58ABB33B82 for ; Fri, 11 Apr 2003 04:59:14 -0400 (EDT) Received: from a37-137.dialup.iol.cz ([194.228.137.37] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 193uNB-0006vv-00 for f-cpu@seul.org; Fri, 11 Apr 2003 10:59:02 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 193uBS-0000G7-00 for f-cpu@seul.org; Fri, 11 Apr 2003 10:46:54 +0200 Date: Fri, 11 Apr 2003 10:46:54 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] IDU News; synthesis report In-Reply-To: <20030410194521.01503@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > On Thu, Apr 10, 2003 at 02:46:11PM +0200, devik wrote: > [...] > > > Can you try a simple carry-select adder? I'll attach a copy. > > > > Ok, 310 slices, 65 MHz on Spartan2E. Seems ripple one > > is superior on fpga because they have dedicated circuits > > for it. Maybe one could create 8 8bit ripple adders > > and add carries in next stage - these +1 adders could > > use fast carry chain again ... > > Design criteria for FPGAs are very different. In most FPGAs, every > logical function with 3 or 4 inputs will have the same delay, for example. > In some chips, a 1-bit full adder is as fast as a 2-input nand gate, > ..... Oh yes I know. My comment was not in way "change f-cpu design". It was only academic thought how could one make fast FPGA specific SIMD adder. One other specific of FPGA is that each (or each two) LUT has private flip-flop. Thus it seems to me that ultra high throughtput units on FPGA could take it into account and be pipelined deeply (because these FFs come at no price). Also is there some web page where could I learn things like types of adders and multipliers ? > Earlier synthesis runs with Synopsys reported 389 MHz for IAdd and 458 MHz > for IMul64 (that were the previous versions; the current ones are probably these are for ASIC ? As I some time ago discussed with nicO, how can one have 6 GHz adder like one in P4 ? Is the trick in hand placing transistors instead of using vhdl synthetizer ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From def@zero.ad.jp Fri Apr 11 16:40:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19418t-0001xo-00 for ; Fri, 11 Apr 2003 18:12:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 18:12:43 +0200 (CEST) Received: (qmail 833 invoked by uid 65534); 11 Apr 2003 14:39:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 11 Apr 2003 16:39:23 +0200 Received: by moria.seul.org (Postfix) id 060D033C29; Fri, 11 Apr 2003 10:39:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5038F33C21; Fri, 11 Apr 2003 10:39:18 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 79.39.55.11 (f-tokyo-132047.zero.ad.jp [211.130.132.47]) by moria.seul.org (Postfix) with SMTP id AEE8033C29 for ; Fri, 11 Apr 2003 10:39:16 -0400 (EDT) From: gekiyasu To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81y=8C=83=88=C0=81z=83u=83=89=83=93=83h=8E=9E=8Cv=81EBag=81y1/100=82=CC=93=C1=89=BF=81z?= Date: Fri, 11 Apr 2003 23:40:02 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ffc6f8dc-82b9-4224-8c9f-0bf038c9628c" Message-Id: <20030411143916.AEE8033C29@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --ffc6f8dc-82b9-4224-8c9f-0bf038c9628c Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =83u=83=89=83=93=83h=95i=82=AA=82=C8=82=F1=82=C6=8Es=89=BF=82=CC100=95=AA=82= =CC=82P=82=A9=82=E7=81I =92=E8=94=D4=83=82=83m=82=A9=82=E7=83=8C=83A=82=E0=82=CC=82=DC=82=C5 =94=84=82=E8=90=D8=82=EA=81A=83T=83C=83g=8F=C1=96=C5=82=C5=91=A6=8FI=97=B9 =81i=83T=83C=83g=82=AA=82=B7=82=AE=8F=C1=82=B3=82=EA=82=DC=82=B7=81B=96{=93=FA= =92=86=82=C9=82=A8=90\=8D=9E=82=DD=82=AD=82=BE=82=B3=82=A2=81j http://www.psend.com/users/brand00/ http://club.telepolis.com/brand0/ http://book-i.net/brand/ *********************************** =83=88=83b=83g=83}=83X=83^=81[=81@=83V=83=8B=83o=81[=82=AA9,000=89~=81I =83p=82=D8=83`=83=85=83A=83=8B=81A=83G=83N=83X=83v=83=8D=81[=83=89=81[=87U=81= AGMT=83}=83X=83^=81[=87U =83f=83C=83g=83i etc=81E=81E=81E =83=94=83F=83=8B=83j=82=CC=83=8A=81[=83hPM=90=D4=82=AA7,000=89~ =81=9C=83=82=83m=83O=83=89=83=80=83}=83=8B=83`=83J=83=89=81[=81@=83~=83j=83= X=83s=81[=83f=83B=93=FC=89=D7=81=9C =81i=91=E5=90l=8BC=81I=8Ec=82=E88=8C=C2=82=C5=82=B7=81I) *********************************** =81y=83u=83=89=83=93=83h=8Cg=91=D1=83X=83g=83=89=83b=83v=83v=83=8C=83[=83=93= =83g=81z =81=AA=82Q=82=C2=88=C8=8F=E3=82=A8=94=83=82=A2=8F=E3=82=B0=82=CC=95=FB=91S=88= =F5=81=AA http://jp.internations.net/gekiyasu/ http://brand.www3.dotnetplayground.com/ http://c.1asphost.com/brand/ --ffc6f8dc-82b9-4224-8c9f-0bf038c9628c-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 11 16:15:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19467U-0005U9-00 for ; Fri, 11 Apr 2003 23:31:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 23:31:36 +0200 (CEST) Received: (qmail 25494 invoked by uid 65534); 11 Apr 2003 16:50:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Apr 2003 18:50:52 +0200 Received: by moria.seul.org (Postfix) id A92F833C75; Fri, 11 Apr 2003 12:50:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4972533C66; Fri, 11 Apr 2003 12:50:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a197.home.uni-hannover.de [130.75.232.197]) by moria.seul.org (Postfix) with ESMTP id 226C233C5E for ; Fri, 11 Apr 2003 12:50:47 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00849; Fri, 11 Apr 2003 16:15:39 +0200 Message-ID: <20030411161538.34121@thrai.stud.uni-hannover.de> Date: Fri, 11 Apr 2003 16:15:38 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] IDU News; synthesis report References: <20030410194521.01503@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Apr 11, 2003 at 10:46:54AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Apr 11, 2003 at 10:46:54AM +0200, devik wrote: [...] > One other specific of FPGA is that each (or each two) LUT has private > flip-flop. Thus it seems to me that ultra high throughtput units > on FPGA could take it into account and be pipelined deeply (because > these FFs come at no price). I'm not sure that this is a good idea. > Also is there some web page where could I learn things like types > of adders and multipliers ? Several. One of them is `(Lecture notes on) Computer Arithmetic: Principles, Architectures and VLSI Design' by Reto Zimmermann. I don't remember the URL but Google should find it. It's a rather terse document (mostly formulas and graphics) but it's quite complete. If you just look for `Reto Zimmermann', you'll probably also find other interesting documents. > > Earlier synthesis runs with Synopsys reported 389 MHz for IAdd and 458 MHz > > for IMul64 (that were the previous versions; the current ones are probably > > these are for ASIC ? As I some time ago discussed with nicO, how > can one have 6 GHz adder like one in P4 ? > Is the trick in hand placing transistors instead of using > vhdl synthetizer ? They probably use hand-tuned circuits and `dynamic' pipeline registers which basically consist of a pass gate and a capacitor (it's like a "sample&hold" circuit for digital data) and are fast compared to ordinary flip-flops, which allows more fine-grained pipes. They may also use gates like AOI -- that's an and-or-invert gate which can be made just one transistor "deep", by using the CMOS equivalent of a `wired-and' gate (something similar is most likely also used in the `fast carry' chains of FPGAs). They can also fine-tune the fan-in, fan-out and delay of gates by making individual transistors smaller or larger. And of course they use the latest-and-greatest manufacturing process, featuring high resolution, copper wires, low-K dielectrics and other nice stuff. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 11 15:19:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19467U-0005U9-01 for ; Fri, 11 Apr 2003 23:31:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 23:31:36 +0200 (CEST) Received: (qmail 21471 invoked by uid 65534); 11 Apr 2003 16:51:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008-rz3) with SMTP; 11 Apr 2003 18:51:03 +0200 Received: by moria.seul.org (Postfix) id C850333C3B; Fri, 11 Apr 2003 12:50:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 97EB133C60; Fri, 11 Apr 2003 12:50:52 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a197.home.uni-hannover.de [130.75.232.197]) by moria.seul.org (Postfix) with ESMTP id 8172433C5E for ; Fri, 11 Apr 2003 12:50:49 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00686; Fri, 11 Apr 2003 15:19:52 +0200 Message-ID: <20030411151952.65193@thrai.stud.uni-hannover.de> Date: Fri, 11 Apr 2003 15:19:52 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] DCT in VHDL References: <20030410224713.03931@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Fri, Apr 11, 2003 at 10:33:39AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Apr 11, 2003 at 10:33:39AM +0200, devik wrote: > thanks for your comments. When I got some time I'll > try to continue on it :-) By the way is there some > good vhdl simulator running on Linux ? I use VHDL Simili. There's a Linux version, but you can also use the older NT version with vmware or wine (I use the latter, and it works fine). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Apr 11 21:51:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19467W-0005U9-00 for ; Fri, 11 Apr 2003 23:31:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 23:31:38 +0200 (CEST) Received: (qmail 26075 invoked by uid 65534); 11 Apr 2003 17:52:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 11 Apr 2003 19:52:29 +0200 Received: by moria.seul.org (Postfix) id F2D6A33C60; Fri, 11 Apr 2003 13:52:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DF24333C5E; Fri, 11 Apr 2003 13:52:26 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by moria.seul.org (Postfix) with ESMTP id A833733C21 for ; Fri, 11 Apr 2003 13:52:26 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id A731362D38 for ; Fri, 11 Apr 2003 19:52:23 +0200 (CEST) Date: Fri, 11 Apr 2003 19:51:22 +0000 From: nico To: f-cpu@seul.org Subject: [f-cpu] new cjump instruction Message-Id: <20030411195122.17ff43c9.nico@seul.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I propose a new cjump to enable 0 cost jump. cjump (R1,#imm12, cond) { if (cond(R1)) { PC = (PC & 0x0FFF) | #imm12; } else { PC++; } } PC lsb is just replaced by the 12 bit constant, that's lightning fast. No cycle could be lost by reading register bank. What do you think of it ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Fri Apr 11 19:16:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19467W-0005U9-01 for ; Fri, 11 Apr 2003 23:31:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 23:31:38 +0200 (CEST) Received: (qmail 3836 invoked by uid 65534); 11 Apr 2003 18:19:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 11 Apr 2003 20:19:12 +0200 Received: by moria.seul.org (Postfix) id 2F1B533C21; Fri, 11 Apr 2003 14:19:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E78633C5E; Fri, 11 Apr 2003 14:19:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 0CA7333C21 for ; Fri, 11 Apr 2003 14:19:08 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-214.jetnet.ab.ca [207.34.60.214]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h3BIJFhf080252 for ; Fri, 11 Apr 2003 12:19:15 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E96F854.3040306@jetnet.ab.ca> Date: Fri, 11 Apr 2003 11:16:04 -0600 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N nico wrote: > I propose a new cjump to enable 0 cost jump. > > cjump (R1,#imm12, cond) > { > if (cond(R1)) > { > PC = (PC & 0x0FFF) | #imm12; > } > else > { > PC++; > } > > } > > PC lsb is just replaced by the 12 bit constant, that's lightning fast. > No cycle could be lost by reading register bank. > > What do you think of it ? Try using it with real code and you will see the problem. hint: page boundry is random.:( Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Apr 11 23:08:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19467Y-0005U9-01 for ; Fri, 11 Apr 2003 23:31:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 11 Apr 2003 23:31:40 +0200 (CEST) Received: (qmail 17606 invoked by uid 65534); 11 Apr 2003 19:09:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 11 Apr 2003 21:09:16 +0200 Received: by moria.seul.org (Postfix) id CFBDF33B51; Fri, 11 Apr 2003 15:09:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 64D2E33C20; Fri, 11 Apr 2003 15:09:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by moria.seul.org (Postfix) with ESMTP id 89D9E33B51 for ; Fri, 11 Apr 2003 15:09:08 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 60A4562E39 for ; Fri, 11 Apr 2003 21:09:05 +0200 (CEST) Date: Fri, 11 Apr 2003 21:08:03 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction Message-Id: <20030411210803.79b993dd.nico@seul.org> In-Reply-To: <3E96F854.3040306@jetnet.ab.ca> References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, 11 Apr 2003 11:16:04 -0600 ben franchuk wrote: > nico wrote: > > I propose a new cjump to enable 0 cost jump. > > > > cjump (R1,#imm12, cond) > > { > > if (cond(R1)) > > { > > PC = (PC & 0x0FFF) | #imm12; > > } > > else > > { > > PC++; > > } > > > > } > > > > PC lsb is just replaced by the 12 bit constant, that's lightning > > fast. No cycle could be lost by reading register bank. > > > > What do you think of it ? > > Try using it with real code and you will see the problem. > hint: page boundry is random.:( ?? That's a compiler problem. So ? > Ben. > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 12 00:55:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194IL8-0005ev-00 for ; Sat, 12 Apr 2003 12:34:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:30 +0200 (CEST) Received: (qmail 6049 invoked by uid 65534); 11 Apr 2003 23:40:42 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Apr 2003 01:40:42 +0200 Received: by moria.seul.org (Postfix) id 7894333B69; Fri, 11 Apr 2003 19:40:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 80A8133B6D; Fri, 11 Apr 2003 19:40:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a063.home.uni-hannover.de [130.75.232.63]) by moria.seul.org (Postfix) with ESMTP id 4E54033B69 for ; Fri, 11 Apr 2003 19:40:36 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA17464; Sat, 12 Apr 2003 00:55:13 +0200 Message-ID: <20030412005513.38735@thrai.stud.uni-hannover.de> Date: Sat, 12 Apr 2003 00:55:13 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Introducing EU_AFU Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Hi F-riends, this is the `Additional Functions Unit', aka `Another Fine Unit', aka `A Fun Unit' ;) It currently contains only a rewrite of the `popcount' and the (still undocumented and nameless) related `hamming distance' instruction, but it's supposed to grow when other special instructions are implemented that don't fit into one of the mandatory units. The interface may also change. Both instructions are completely implemented. They can handle all chunk sizes up to 64 bits; the latency is 2/3/3/4. The WIDTH generic may be any integer multiple of 64; I tested the unit with widths of 64 and 128. My testbench is included in the package. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --J2SCkAp4GZ/dPZZf Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-mr-afu-20030412.tar.gz" H4sIAPhDlz4CA+08/3PaxvL5Ff0VVzvzIhKwkYSxa+JMsUscz7MTj3GaeObNMEI6QGMh8SRh Q6d//Gf37iSdQMKA3bT9PDRtIt3t7u3325OW9K3xpDoKqmZ/UtVrNaNW1/T9Vy971Wr12uHB AfzNrvm/+f1ho37QqGuHh3CvacDJK3Lw6gdckzAyA0Je/Y9e/Tz700kXnvf/Ovvrev1wa/+/ 2v7wv7f3MLTd59ofwrlRrxfYX6/rhsbtf3DQaIDha1q91mi8IrWt/f/0q1oliZkJPHysnl1/ JY16tedEpGXbTuT4numSjxPPwtuQfPVgRjXvTdLCUf7crJYVwD7zx7PAGQwB4KxM0J/IlWMN TeqSG4eOKXk/4o+/hNHE3pt4TnVoep7/QIM9m34AEkjlduiEZBz4g8AcEbjtB5SS0O9Hj2ZA m2TmT4hleiSgthNGgdObRJQAD6Zn7/sBGfm2058hHRibeDYNSDSkJKLBKCR+nz2cf/5KzqlH A5DsetJzHYtcOhb1QkpMWBpHwiG1SY/RQYyPyENH8EA++kDYRH00CXVgPiAgQgjPRI/XEAQr xA+QiGpGyHlA/DHilYHdGXHNKEXdKxA/ldImjsdoD33QZTQEkiDjo+O6pEfJJKT9iVtBEgBM vl3cfvry9Za0Pt+Rb62bm9bn27smAEdDH2bpA+WknNHYdYAyyBWYXjQD9pHCVfvm7BOgtE4v Li9u70AI8vHi9nO70yEfv9yA6a9bN7cXZ18vWzfk+uvN9ZdOe4+QDkW2KBJYouI+sxKo0aaR 6bhhLPgdGDYE7lybDM0HCga2qPMAvJnEAsd62nhIxHR9b8DEBOBUkU3i9InnRxXyGDjgL5G/ aFZETy1bIReetVchBz+TWwpKouTaNS2wZ2eCBAyjViGnfhgh5FWLkJquaVpVM2qHhHzttBSk 9ou6WyavL+zjNMgqD0Tbq7PY2K/V9zWNaAfHun6sHRARG6Q9HZPXiuI6vcAMZuSi3W43FbAu u9sLI7vr+gPH6mpao75nui6ffPSD+71TJ+pemZ4znrhMiLnpKye0+JBCvcgBa7cwhJ1QKQ1Q o6BKVSmVvl38evuJHBPPjCao5eMTyAhKqdxUSmM/iBgMSAdOCC6DTjmeRECi1AIc8FDkcMJZ fKBW5AcqI1jViO0/eqD5GlIqna4FDetBZEMeANNaQ4rLfTJHIweMPUdGQHcurn7NohDVmgQB CO7OIDGAUuwygH4tYkNfYMByfet+P6AhjVKhz9z7PA5uwihvuO3ljIL7l0rX/tiqHcEshueK SkEcrbE+jqGvj9Oor47DfKVaHQfmYGSScOZBrIVO2PX7faVHB46nlMwwpAFmKXQ1MBN4GDkh NVgsoMzJdh4dG4IYgp756Ag2asxykPgdL6IDyJujiRs5GJgA06jvAGoIaS1At+5DXpnAZpHL hAfObzOqEAdmYA0hni3wdEpOKSaerpasipGBhofkCNna9++r5pCaNsRB4FvURpyzyxZRz50K uXYKPAk1WCoRQs59gPKL1Fhmq5Us2GQjyMTkMhuB584bl3qDaAjkuA4LFFyKdXvJ9MrU2kxH VUaoH8HwZVXDfchmY3zfPhEWj4Gvc4Cvi4DP/QR4v57S9oto54JfZ8HzDVgq4SbioLoZbuJ6 aKQx6husZp/oeHfuq06Za1Ctv3XeGWVmD8AHScQIW1rM6+UigOsYQAbXVgS/jsFl5FqZaYRz q+Hddczt6rSuY1pICl0bdQD3eAveCU6e+nBIXXA2wj0uzPhx5zewFTjoU17cqZDbTX04deHS gxk4Zg+idzCokPG4QsKwQiJMmosJ5nIuIT3P/3Pcv8hDc5y/ALSzCNopAL1dBL1dyecHA6ZE pDUeMx9prhUJYSgcBXHf1N40pUGNDQ4GkivFU7o8paXePh7LXpigZnANGVdfwNUzuHIoZQGW LpUKGEWygBoXUAzOCRgvJCgLiQXsuhIXACS0M8T/ZJWsBJ7lTMoZpQ4yF4Z4e4u3URRnks5v cSaBGhn2YicK0etwy50RfmC0hhPvXuEGMYgandSBnb44OnK8OlGLysQyVPyQKnJmlmeVVl5W Mc2VMkmK0OutiWBZayLYdi6C8VaFyC0/P8UVpQ1UBWhpxVzRdwKotAL/8RhOYW6fmDYcocPs JtXrSXFmmrFnTYG6eAIZED7icSngtTl49MR5eJm+LsMbGfp6Hn1jDl6ir2fow11IwZ3sYjkZ XcuS5EyZQj4SFQi6dQlem4NHPubhDQlel+GNDH0tD96Yg5foaxm9sJcXTiDEhHP7wIxoKiOj advggbGMicBNaUqTp4BX4C4RVJZegOsyuLGQYESM27bIKzwriNQC8T2gRCPVDwQECJ0BvnsK tO45HLbhr+tabgSxQ8S+PhdBKTY7dMknLmktHdcyUmh9s0X0bmcztHNtCdpRIdoykQwUqZ5C G927ZYvUCxYxFhcRZ7cxHAfRal0kyyrIEA7XrQo5rRBxKK8QOBdXCJyCK6TtlVfIzLkHzwRp Oq2Q2WwNDUv1JfjOeB3jCCnTPOD0SeR3v9c0VUhXJqy8wFdICBhnWBa4p8zh3ZBKE3EMOP1m TPdAzsaLhkgycpy/4hl44PHFwkaNk508zYM3TYNpsSfH4XSKE6qPby9DcvIBYRgmqjl3Yo7d ozx2p9NFfkRSPoLxw3gcH+qc0dlsKYohoyyccbgyG1gc1xAJpMJsOJuxIjkeQrvgUMaW4Jvz dmSZhrzPlb7E80/xJETL+1TTbggrBU4I3tKl9oCqEA/lZKGUCwiOOSZSLga1ZjzAVx7zgdSV 0nXbXsbJ8EZEJoqdRKwuR6ycWOWAZUTLz4ohCVUD1HWSXIoawqrRZqvOYNXftY1Q1041mXyR uiLTbuqGTMuJxx7hm8PLlsoVWxFaYoxAoZ0Mcw2UE7SfMT41JAdE0atDRvJ3eSiKVzliNTmc 08eTKH3B+H7j2OYEFoKyjCRn2mIQ54Sq1mA8sVrrJXIQ0MtPQotMHjMmlyShZSirJCGttmIW iuH1NX3gyeylL0tQrEIpnoQ6pHhys9TG08hCdtOzySzlLEwHODcDbSHdxbww2itlPCOT8XSW 6tiSFV5+ZRKfPp/4xt0Ns153w5S34Xqz7p+U7Oqb11X1zfeETFyvuSnUN98U6ssyO4tX5g8n /JiAtMPkucOemd1PuGelkY4HrRmfQQIscXdr2ZyYydNaY7U8nZ//OAVVa8iZC594qu4u5jQe 6TJencGCOKqen8oN/WVTuaGvlcqBMcanpskCvjvikgi0On/V1tXidwBLU31MkmR0Fh+GBVqW ZNFWUF9zK2hsVg5oh+vUAwB/tKre0yw+4B6wkMfzN1Nc9/fibTZN5fnelAkCQ18tCPIl4BRU A5h/dxBP41NcrxzJE0cLTv7kbsuO1UV7prHpnqnn7pnxWrPFHTFeiWGutCPWMzsiks7sgcb8 Hrh8b6lvvrccbb63HG2+txj65nvL0eZ7y9HSveUo3SGYRURYiEasF0uyjfqSJHtQnGSNvCQr MmIxGjnISaSLyfLn9ZKlrm2WLHV9vWSpG6vq70cnS+EVmWTZqK+WLPMl4BTUBu5pjXi6Uc8m y0ZxsszmGnyIWymarBHqwYHAoBGJwpM6CR/hD/rfiemOg8HJTn8UkeqhTqrjanUHMpNLzZAq r7bX36H/txvRMHpmE/AT/b96Pe7/PjhsHNR1gD/QtINt/+8P7P9NzYxNwLfw0KOeNWStmoVd wLkdvxqpbht/t42/28ZfqfE3jS7W/atlun8Pjw3472i++7fgy/+6XcFs0puMsLe3C0DpDD5E dAoSz0GnpOanl7QYy/3ETNxsU3FOR7GmYxkZd2IynPl2zBY8pM2YKVnLH419D1Zk41g9Ss3L Rd3LrH057V9es1l5zW7lZb3JK3ccF7UWF/UW5zcX8+7ijdqLN+ov3qjBeIMOY2ZP3kAgvAEP ueLj9VV+p03ed+7Wyl+jBcLpugh3ayMwQ62Hwsy0Hgoz0noozERroXAfznikmOFenDeT09yQ 9qmyNA4bI1FDBhWw7/GsQSw5jLvoRcfEdTwqnbQZpopzcDhkbsdGEErlZ6kKw4wdK14pu/4Y FozivjTV7bkJF/zrBZ6n85SUzNo0ZRyT0w77Y30RcOl/wVYKohB5fBo/Fwomi5AnHDdDyDiK V5Zx1J3WToW0eELNjJ/C+GnO+BWMX+WM38H4XZYtsXiWL9vvip8F5Grc7E4rxOzmvmsqZ8SI barufPv0pUVuP7Vv2j/99NOOxFvCwByzsDAuMi0XzcwqYMt9tKUQKOE6K4w1pNZ9V2zKBS5E lvsQmaUb3LznRKNxbpBO30CdN6DZ11b5bsZInOTQiPzuxEMFUVudQZ02Ivrbt1PRfwmuJ+54 CwoUXlPUB1KL34QkKuFKA7PBbHnhtWVGRXnaY1zl644QYlZIr9gXSqbrQLWfq2HVFCIkb64Q h5jNBC3/hWYvF623gq5FJ2ey7gmJabHXu+LHMD0TquFgwDpuJQ3skMWfvEivfITJk9c8HhR0 5BFMQWb4K4MT8qbKe6TTiSmfwPlmvsFm4hU36+PLeQ0ksZeXXNhPslTWPcyKlQIvXiGFM6u/ UXfevn1LMKgxn+6U08Qu4HCphcEEmb1JYzwBGRn7ieyJKHPiTVyokVWxh00Xahnhn8TLyM1K 4XhKlHWRM6JsnHhhNn0lltXwIOMlhn00QQqcjJqw8vu0+X1xYqETjMmEvCf9ffy3dhOwgjhG g3KV0ogZZK7iHpnjuLo/+cBfMZbjMpvN8VIb5loVXkbD7WlFLpFh4Eo1yhVeGrMnqRCuxIUw TOBHirj+hUf8XCHKXnhqexWpzoUBqKIqUhGLI1qjIlWoOGLoFan8xJH4rKCU7lBfWPKwwACu xGtdhbX3sfpJzGhzM7CcmKnNzdSORKumHcAJN4jfmQo/CjNt7lKWyX6TkDr68oC1RWD0BnSf uBXf8azN+/BjZ4xbeXnfoxsOnX6kWmZomTbtmp6ttsoVolVw9TTDe1aWEwg//nuCp9mJI4Yx IX15kfbCpswe/yjCm0qSwGnNpUTp5X1LzXlzL6jAn+/iOJW+vskv5mN18E8VOBPLxiROEwWG Uxe/xglJotkYX4m4kdlje00QmDMiH1bwBCwJmBodkMxZN2JqOI5J4IcgxmcN/VkHE/zBfN2o EAP/Zr3avJ1Iasp9WL0p9+lS4wm00BnZkFNpHz83speHGQOmgPcFlk2rODn3xx84wcwwN+H+ xbJ64gKDgP1+lNRI5vNHCTlCxR2Rt1jRIBi3dZrsVYThlEpXmBl2at+/f9/hA6fzH1++iw/B qeOxJfV0SXQ8h7znLKXuVrpS+UeXOIOnzcTyZC2ZTJ0x641sZfaDnGR1/gUI5QDbpIwIE5xw 6Lc4L4iz36nhJ0kG8Y4ZjlST/QqdpkDsuISUJ6vJZJ/9kCPVysGBxA6QVdnCwnvY4uWn61ET qj5mo3iV0j37mYQIQjWXbAIL/G606v38oi20j/nQ5Huqyj6sS3Gqor1TaKlYEqehtCJesGjm KfMg+zYrDYytb/89fBvJ7suqYQC93hKA4gBYHM50nWRswtwAGJEJI2WG9s6papkfSS6qeIEW 8DxPC9mpxj8QWkqqMLwSck8F97tebz7U1oy1p4JtnusVgw/vky09b6sfikL3n77b9/4f1AiJ LX5MiaClafR/NVn2ls6tl+i0v3F54fkR+dElBtuae//0WmMbJH+DIPkRdYr2jDql9nJ1Su2v q1PWC9g/u2ARm6H0fhVftImAYd/n4nvRzCxeI0nVjnhIKPEGxTDyx6gD0SKgzO/G6RT7euvS iKa7ML6yzOso5N0ATaXg3znYthm+dP/flXlP+45Ln/3vvy7t/6sZdez5y/T/GYease3/+xHX LpkztrL7Uj19u0DqRTr6dl+moW/3Bfr5dldq58uTfN1mvt3n9vLtPrOVb3e9Tj6U+fl9fLvP auPbfckuvl2piS8ODta+Z6zSvnfdOvt367xNTki/CilW+a1907n48hn/oZ49yHmKEgaW7QTw vKfAZtlNH/cUHEgewkmP3/M4VRTL9/p85LXKAcv7OOYM4AjMdlvYUke+twiDo4py9uXzRzYh CJX3GYddToN1KQLM1RVjFqEEsfI+HHW6I7nzj/UL/0cpZaBG+G+MMiqdm7MO0Ej/feFsL6Ty 60Xn9uPFZbvDFkLocqJp5bbduT1tfz771I5pMExF+e3Tr5fXMIQkxqSKUWVFbLQtRqny7cvN vy8vTuG5ij2LkhbwUVFs2jcnbnTc/IVaQ598+JdO3nz2iRgmsCMMaPQT1D10CqGpKYrpusco J1scnEIVK5RjxsFowN0xsaCs8CAnmO7sdxrXORQI8JEsETQF/xvVLdGK8QB8erLzWpWUUd5p suibYhZ5/XrahEoVbSDotss4SP74Q7DexDnb94AFxhpQDEakGvR5M2c4G4E2IDXF3iL8tlwF ctxly2w+ccNUla9VgYi3fB5Y56PiEVYb3SPe61/4MseAn5gdBZaAlRIaHsVNIXYY/ygvznGR 8S6R2oURlQcPsMHmslRRFf9hr9HAWcYrAM/rbfsbke21vbbX9tpe22t7ba/ttb221/baXttr e22v7bW9ttf22l7/vOv/AHU49w0AeAAA --J2SCkAp4GZ/dPZZf-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Apr 12 00:42:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194ILA-0005ev-00 for ; Sat, 12 Apr 2003 12:34:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:32 +0200 (CEST) Received: (qmail 6792 invoked by uid 65534); 11 Apr 2003 23:45:15 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 12 Apr 2003 01:45:15 +0200 Received: by moria.seul.org (Postfix) id A490233B6B; Fri, 11 Apr 2003 19:45:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63F7233B6E; Fri, 11 Apr 2003 19:45:12 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id A29BB33B6B for ; Fri, 11 Apr 2003 19:45:11 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-221.jetnet.ab.ca [207.34.60.221]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h3BNjJhf096839 for ; Fri, 11 Apr 2003 17:45:19 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E9744C0.6090201@jetnet.ab.ca> Date: Fri, 11 Apr 2003 16:42:08 -0600 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N nico wrote: > That's a compiler problem. So ? You write the compiler then. I don't trust any CPU that you can't program in machine code by hand. Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 12 02:21:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194ILB-0005ev-00 for ; Sat, 12 Apr 2003 12:34:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:33 +0200 (CEST) Received: (qmail 16523 invoked by uid 65534); 12 Apr 2003 00:21:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 12 Apr 2003 02:21:43 +0200 Received: by moria.seul.org (Postfix) id 7A20A33B6D; Fri, 11 Apr 2003 20:21:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCBE233B76; Fri, 11 Apr 2003 20:21:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a063.home.uni-hannover.de [130.75.232.63]) by moria.seul.org (Postfix) with ESMTP id 7091533B6D for ; Fri, 11 Apr 2003 20:21:38 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA17929; Sat, 12 Apr 2003 02:21:37 +0200 Message-ID: <20030412022136.17081@thrai.stud.uni-hannover.de> Date: Sat, 12 Apr 2003 02:21:36 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030411195122.17ff43c9.nico@seul.org>; from nico on Fri, Apr 11, 2003 at 07:51:22PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Fri, Apr 11, 2003 at 07:51:22PM +0000, nico wrote: > I propose a new cjump to enable 0 cost jump. [...] > What do you think of it ? I think that using partial addresses (as opposed to displacements) in jumps or memory accesses is bullsh^H^H^H^H^H^Hnonsense. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 12 02:54:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194ILC-0005ev-00 for ; Sat, 12 Apr 2003 12:34:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:34 +0200 (CEST) Received: (qmail 1256 invoked by uid 65534); 12 Apr 2003 00:51:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 12 Apr 2003 02:51:54 +0200 Received: by moria.seul.org (Postfix) id 76D8033B76; Fri, 11 Apr 2003 20:51:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 40A2F33B8A; Fri, 11 Apr 2003 20:51:52 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id A9F7333B76 for ; Fri, 11 Apr 2003 20:51:51 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-6.n.club-internet.fr [213.44.3.6]) by relay-5m.club-internet.fr (Postfix) with ESMTP id 00B7BE2A1 for ; Sat, 12 Apr 2003 02:51:50 +0200 (CEST) Message-ID: <3E9763AF.7020805@f-cpu.org> Date: Sat, 12 Apr 2003 02:54:07 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi all, nico wrote: >On Fri, 11 Apr 2003 11:16:04 -0600 >ben franchuk wrote: > >>nico wrote: >> >> >>>I propose a new cjump to enable 0 cost jump. >>> >>>cjump (R1,#imm12, cond) >>>{ >>>if (cond(R1)) >>>{ >>> PC = (PC & 0x0FFF) | #imm12; >>>} >>>else >>>{ >>> PC++; >>>} >>> >>>} >>> >>>PC lsb is just replaced by the 12 bit constant, that's lightning >>>fast. No cycle could be lost by reading register bank. >>> >>>What do you think of it ? >>> >>> >>Try using it with real code and you will see the problem. >>hint: page boundry is random.:( >> >> > >?? >That's a compiler problem. So ? > > huh, i don't think that it's a good answer .... on top of that, this technique poses new problems in FC0's pipeline. sure, addresses are computed fast, but what about their validation, their fetch, their lookup in the buffers ...... >>Ben. >> >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 12 03:27:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194ILC-0005ev-01 for ; Sat, 12 Apr 2003 12:34:34 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:34 +0200 (CEST) Received: (qmail 10946 invoked by uid 65534); 12 Apr 2003 01:25:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 12 Apr 2003 03:25:05 +0200 Received: by moria.seul.org (Postfix) id 04E2033C1A; Fri, 11 Apr 2003 21:25:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 985A333C55; Fri, 11 Apr 2003 21:25:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id B2BCA33C1A for ; Fri, 11 Apr 2003 21:25:02 -0400 (EDT) Received: from f-cpu.org (lcbv4-2-10.n.club-internet.fr [213.44.93.10]) by relay-3m.club-internet.fr (Postfix) with ESMTP id 78CF4E25C for ; Sat, 12 Apr 2003 03:25:01 +0200 (CEST) Message-ID: <3E976B72.609@f-cpu.org> Date: Sat, 12 Apr 2003 03:27:14 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <20030412022136.17081@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi again, Michael Riepe wrote: >On Fri, Apr 11, 2003 at 07:51:22PM +0000, nico wrote: > > >>I propose a new cjump to enable 0 cost jump. >> >> >[...] > > >>What do you think of it ? >> >> > >I think that using partial addresses (as opposed to displacements) >in jumps or memory accesses is bullsh^H^H^H^H^H^Hnonsense. > > :-) on top of that, this solution has been proposed at least once in the "past" ... no idea when but it seems not new for me. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 12 11:35:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194ILW-0005ev-01 for ; Sat, 12 Apr 2003 12:34:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 12:34:54 +0200 (CEST) Received: (qmail 7350 invoked by uid 65534); 12 Apr 2003 09:35:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 12 Apr 2003 11:35:02 +0200 Received: by moria.seul.org (Postfix) id 7C13533B54; Sat, 12 Apr 2003 05:34:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 85C1433B5D; Sat, 12 Apr 2003 05:34:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [217.167.200.10]) by moria.seul.org (Postfix) with ESMTP id 376E733B54 for ; Sat, 12 Apr 2003 05:34:57 -0400 (EDT) Received: from homeworld (80.15.61.163) by mx.laposte.net (6.0.053) id 3E9748DE0000C8BD for f-cpu@seul.org; Sat, 12 Apr 2003 11:34:55 +0200 Message-ID: <001b01c300d6$d3432460$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030411195122.17ff43c9.nico@seul.org> <20030412022136.17081@thrai.stud.uni-hannover.de> <3E976B72.609@f-cpu.org> Subject: Re: [f-cpu] new cjump instruction Date: Sat, 12 Apr 2003 11:35:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "Yann Guidon" To: Sent: Saturday, April 12, 2003 3:27 AM Subject: Re: [f-cpu] new cjump instruction > >I think that using partial addresses (as opposed to displacements) > >in jumps or memory accesses is bullsh^H^H^H^H^H^Hnonsense. > > > > Not totally a nonsense but something too much restrictive indeed. The idea to have a short absolute jumper in the same page (supposedly a minimal size for a page is 4096-byte long) that we are running would prevent from any TLB exception to occur. So it could be used fastly in small loops that are within a page. Nevertheless, we need to care about page boundary, not about range boundary, so your compiler needs to be aware of it and probably to rearrange code in another suitable order; which is quite restrictive and something definitively not wishable for a compiler. For shared libraries, the page boundary should not be a problem because it is usually only the index page of the address that changes, not the offset due to the virtual address mapping used for sharing code in several different addresses. But for object linking, it might become an obstacle if object codes are not mergeable at least on page boundary. You can call it "bullshit" because it will be unusable if we don't respect the page boundary. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From thc100jp@yahoo.co.jp Sat Apr 12 16:12:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194PCO-0002oy-01 for ; Sat, 12 Apr 2003 19:53:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 19:53:56 +0200 (CEST) Received: (qmail 20606 invoked by uid 65534); 12 Apr 2003 14:12:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 12 Apr 2003 16:12:55 +0200 Received: by moria.seul.org (Postfix) id 23A8A33B5D; Sat, 12 Apr 2003 10:12:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DA5B133C63; Sat, 12 Apr 2003 10:12:53 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 8085133B5D for ; Sat, 12 Apr 2003 10:12:53 -0400 (EDT) Received: from yahoo1092.com (FLA1Aag058.tky.mesh.ad.jp [61.203.86.58]) by bettik.munge.net (Postfix) with SMTP id 575EE4F825 for ; Sat, 12 Apr 2003 09:13:51 -0500 (CDT) From: net0412 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C=83=97=A0=93=C1=89=BF=8C=C0=92=E8=8F=A4=95i=81I?= Date: Sat, 12 Apr 2003 23:12:59 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e3c2040c-33ca-41dd-8bf9-f0401d5a7105" Message-Id: <20030412141351.575EE4F825@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --e3c2040c-33ca-41dd-8bf9-f0401d5a7105 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =82=B1=82=BF=82=E7=82=A9=82=E7=88=EA=95=FB=93I=82=C9=91=97=82=E8=82=C2=82=AF= =82=C4=95s=96=F9=89=F5=82=C9=82=C8=82=E7=82=EA=82=BD=95=FB=81A=90=BD=82=C9=90= \=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1.. =8D=A1=8C=E3=88=EA=90=D8=82=CC=91=97=90M=82=F0=8B=91=94=DB=82=B3=82=EA=82=E9= =95=FB=82=CD=82=A8=8E=E8=90=94=82=C5=82=B7=82=AA=89=BA=8BL=82=CC=83A=83h=83=8C= =83X=82=C9=95=D4=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81B =94z=90M=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=81@net-modori@24i.net =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=96@=97=A5=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B <=91=97=90M=8E=D2> net-DM=83T=81[=83r=83X=81@http://www.net-dm.com/ <=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B=91=8D=8D=87=8A=E9=89=E6=8E=D0=81= @http://210.136.155.95/ =DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1= :*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K =81w=8DL=8D=90=81x=81@ =93=C1=95=CA=8F=EE=95=F1=81I=81I=95K=8C=A9=81I=81I =8C=C0=92=E8=8A=F3=8F=AD=89=BF=92l=8F=A4=95i=82=AA=82=B1=82=CC=89=BF=8Ai=82=C5= =81=F4 =82=DC=82=B8=82=CDHP=82=F0=8C=A9=82=C4=82=AD=82=BE=82=B3=82=A2=81=99 =81=A6=89=BA=8BL=82=CC=82=C7=82=CC=83A=83h=83=8C=83X=82=A9=82=E7=82=C5=82=E0= =82=B2=97=97=82=C9=82=C8=82=EA=82=DC=82=B7 http://210.136.155.95/ http://sv39.bestsystems.net/~dazax000/ http://netchannel.sub.jp/ =DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1= :*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K =81=A6=8D=A1=8C=E3=82=B1=82=CC=83=81=81[=83=8B=82=F0=8E=F3=90M=8B=91=94=DB=82= =C8=82=B3=82=EA=82=E9=8F=EA=8D=87=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=82=C9= =95=D4=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81B =88=C8=8C=E3=88=EA=90=D8=82=CC=94z=90M=82=F0=92v=82=B5=82=DC=82=B9=82=F1=81= I --e3c2040c-33ca-41dd-8bf9-f0401d5a7105-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Sat Apr 12 18:22:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194PCR-0002oy-00 for ; Sat, 12 Apr 2003 19:53:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 19:53:59 +0200 (CEST) Received: (qmail 19039 invoked by uid 65534); 12 Apr 2003 14:23:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 12 Apr 2003 16:23:54 +0200 Received: by moria.seul.org (Postfix) id 3DAF933C66; Sat, 12 Apr 2003 10:23:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3808B33C65; Sat, 12 Apr 2003 10:23:52 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by moria.seul.org (Postfix) with ESMTP id EC88F33C10 for ; Sat, 12 Apr 2003 10:23:51 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id CE67740F00 for ; Sat, 12 Apr 2003 16:23:47 +0200 (CEST) Date: Sat, 12 Apr 2003 16:22:48 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction Message-Id: <20030412162248.70287daf.nico@seul.org> In-Reply-To: <3E9763AF.7020805@f-cpu.org> References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 12 Apr 2003 02:54:07 +0200 Yann Guidon wrote: > hi all, > > nico wrote: > > >On Fri, 11 Apr 2003 11:16:04 -0600 > >ben franchuk wrote: > > > >>nico wrote: > >> > >> > >>>I propose a new cjump to enable 0 cost jump. > >>> > >>>cjump (R1,#imm12, cond) > >>>{ > >>>if (cond(R1)) > >>>{ > >>> PC = (PC & 0x0FFF) | #imm12; > >>>} > >>>else > >>>{ > >>> PC++; > >>>} > >>> > >>>} > >>> > >>>PC lsb is just replaced by the 12 bit constant, that's lightning > >>>fast. No cycle could be lost by reading register bank. > >>> > >>>What do you think of it ? > >>> > >>> > >>Try using it with real code and you will see the problem. > >>hint: page boundry is random.:( > >> > >> > > > >?? > >That's a compiler problem. So ? > > > > > huh, i don't think that it's a good answer .... > > on top of that, this technique poses new problems in FC0's pipeline. > sure, addresses are computed fast, but what about their validation, > their fetch, their lookup in the buffers ...... Validation are usefull because you are inside a pages. fetch are ligthening fast. You have an entire clock cycle to do it (no adder or register read before accessing L1 caches). But the real problem is for the compiler. What is the opinion of the compiler writter ? nicO > > >>Ben. > >> > >> > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Sat Apr 12 18:44:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194PCR-0002oy-01 for ; Sat, 12 Apr 2003 19:53:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 19:53:59 +0200 (CEST) Received: (qmail 7143 invoked by uid 65534); 12 Apr 2003 14:45:28 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 12 Apr 2003 16:45:28 +0200 Received: by moria.seul.org (Postfix) id D237333C10; Sat, 12 Apr 2003 10:45:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B485633C65; Sat, 12 Apr 2003 10:45:27 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by moria.seul.org (Postfix) with ESMTP id DC96D33C10 for ; Sat, 12 Apr 2003 10:45:26 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 75B0B62E16 for ; Sat, 12 Apr 2003 16:45:16 +0200 (CEST) Date: Sat, 12 Apr 2003 16:44:11 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction Message-Id: <20030412164411.2a57000a.nico@seul.org> In-Reply-To: <20030412162248.70287daf.nico@seul.org> References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 12 Apr 2003 16:22:48 +0000 nico wrote: > Validation are usefull because you are inside a pages. > UNusefull sorry ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 12 17:15:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194PCU-0002oy-00 for ; Sat, 12 Apr 2003 19:54:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 12 Apr 2003 19:54:02 +0200 (CEST) Received: (qmail 3063 invoked by uid 65534); 12 Apr 2003 15:15:26 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 12 Apr 2003 17:15:26 +0200 Received: by moria.seul.org (Postfix) id AEF7233C65; Sat, 12 Apr 2003 11:15:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AA21133C6A; Sat, 12 Apr 2003 11:15:24 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [217.167.200.11]) by moria.seul.org (Postfix) with ESMTP id ACDCD33C65 for ; Sat, 12 Apr 2003 11:15:23 -0400 (EDT) Received: from homeworld (80.15.61.33) by mx.laposte.net (6.0.053) id 3E9751990001463C for f-cpu@seul.org; Sat, 12 Apr 2003 17:15:22 +0200 Message-ID: <003201c30106$62cbc9a0$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030411195122.17ff43c9.nico@seul.org><3E96F854.3040306@jetnet.ab.ca><20030411210803.79b993dd.nico@seul.org><3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> Subject: Re: [f-cpu] new cjump instruction Date: Sat, 12 Apr 2003 17:15:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is not a problem regarding only compiler. It also is a problem regarding link editor (aka "ld" in Linux) : We have a collection of functions scattered in several object files, those functions would need to be aligned in a page boundary, which means a lot of holes when merging them because the size of a function code is hardly of a page size. Just imagine the case where the codes of both funtions exceed a page size so that the second code has a cjump instruction outside the first page, you get a bug because this cjump would jump somewhere in the second page instead of the first page whereas it should jump to a label located in the first page. Even the linker would be unable to fix it without placing all the second code in the second page so the cjump works well. Such a behavior is very bad because at the end your final executable would be larger than necessary, takes too many pages and causes too many TLB misses. By the way, the compiler must be as simple as possible. If the compiler is able to rearrange the code, you still can find the same problem about holes between function codes (you just shift the problem in fact). So I think this idea is not wishable and not viable (TLB caching pressure increases because of holes). ----- Original Message ----- From: "nico" To: Sent: Saturday, April 12, 2003 6:22 PM Subject: Re: [f-cpu] new cjump instruction > On Sat, 12 Apr 2003 02:54:07 +0200 > Yann Guidon wrote: > > > hi all, > > > > nico wrote: > > > > >On Fri, 11 Apr 2003 11:16:04 -0600 > > >ben franchuk wrote: > > > > > >>nico wrote: > > >> > > >> > > >>>I propose a new cjump to enable 0 cost jump. > > >>> > > >>>cjump (R1,#imm12, cond) > > >>>{ > > >>>if (cond(R1)) > > >>>{ > > >>> PC = (PC & 0x0FFF) | #imm12; > > >>>} > > >>>else > > >>>{ > > >>> PC++; > > >>>} > > >>> > > >>>} > > >>> > > >>>PC lsb is just replaced by the 12 bit constant, that's lightning > > >>>fast. No cycle could be lost by reading register bank. > > >>> > > >>>What do you think of it ? > > >>> > > >>> > > >>Try using it with real code and you will see the problem. > > >>hint: page boundry is random.:( > > >> > > >> > > > > > >?? > > >That's a compiler problem. So ? > > > > > > > > huh, i don't think that it's a good answer .... > > > > on top of that, this technique poses new problems in FC0's pipeline. > > sure, addresses are computed fast, but what about their validation, > > their fetch, their lookup in the buffers ...... > > Validation are usefull because you are inside a pages. > > fetch are ligthening fast. You have an entire clock cycle to do it (no > adder or register read before accessing L1 caches). > > But the real problem is for the compiler. What is the opinion of the > compiler writter ? > > nicO > > > > > >>Ben. > > >> > > >> > > YG > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 12 14:42:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcF-0007o3-00 for ; Sun, 13 Apr 2003 15:33:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:33:51 +0200 (CEST) Received: (qmail 1465 invoked by uid 65534); 12 Apr 2003 18:16:07 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 12 Apr 2003 20:16:07 +0200 Received: by moria.seul.org (Postfix) id 3F22A33C63; Sat, 12 Apr 2003 14:16:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 07FB033C6A; Sat, 12 Apr 2003 14:16:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a120.home.uni-hannover.de [130.75.232.120]) by moria.seul.org (Postfix) with ESMTP id 11D8633C63 for ; Sat, 12 Apr 2003 14:15:58 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00642; Sat, 12 Apr 2003 14:42:21 +0200 Message-ID: <20030412144221.53294@thrai.stud.uni-hannover.de> Date: Sat, 12 Apr 2003 14:42:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <20030412022136.17081@thrai.stud.uni-hannover.de> <3E976B72.609@f-cpu.org> <001b01c300d6$d3432460$8000a8c0@homeworld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <001b01c300d6$d3432460$8000a8c0@homeworld>; from Christophe Avoinne on Sat, Apr 12, 2003 at 11:35:14AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Apr 12, 2003 at 11:35:14AM +0200, Christophe Avoinne wrote: [...] > The idea to have a short absolute jumper in the same page (supposedly a > minimal size for a page is 4096-byte long) that we are running would prevent > from any TLB exception to occur. So it could be used fastly in small loops > that are within a page. I would prefer a smaller minimum page size (like 1K), but that's a different story. > Nevertheless, we need to care about page boundary, not about range boundary, > so your compiler needs to be aware of it and probably to rearrange code in > another suitable order; which is quite restrictive and something > definitively not wishable for a compiler. Most compilers don't care about addresses at all -- they use symbolic labels and let the assembler assign addresses. Some modern compilers (e.g. Sun Forte) use assemblers that perform peephole optimization -- that is, the length of a piece of code may change, and the compiler won't even notice it. That's also true for gcc if it uses things like the `loadcons' macro instruction -- its length depends on the constant that is loaded, and the value may not be known until assembly time. The only tool that would be able to use cjump is the assembler. Unfortunately, it's usually not allowed to re-order basic blocks, but only instructions *within* a basic block. Therefore, it can't handle page boundaries either. > For shared libraries, the page boundary should not be a problem because it > is usually only the index page of the address that changes, not the offset > due to the virtual address mapping used for sharing code in several > different addresses. > > But for object linking, it might become an obstacle if object codes are not > mergeable at least on page boundary. If the linker is allowed to move whole functions (atomically), that will not be a big problem. If a function is smaller than a page, the linker can try to put it into a partially used page; if it doesn't fit or is larger than a page, the linker will have to allocate new pages and page-align the function. The compiler will just have to specify beginning and end of functions (that's also needed for link-time register renaming BTW). The problem is that we won't get so far at all. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 12 20:31:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcG-0007o3-00 for ; Sun, 13 Apr 2003 15:33:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:33:52 +0200 (CEST) Received: (qmail 11187 invoked by uid 65534); 12 Apr 2003 18:31:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Apr 2003 20:31:29 +0200 Received: by moria.seul.org (Postfix) id 2868333C6F; Sat, 12 Apr 2003 14:31:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2125B33C6B; Sat, 12 Apr 2003 14:31:27 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [217.167.200.7]) by moria.seul.org (Postfix) with ESMTP id A339E33C67 for ; Sat, 12 Apr 2003 14:31:26 -0400 (EDT) Received: from homeworld (80.15.61.33) by mx.laposte.net (6.0.053) id 3E974FB900018DFF for f-cpu@seul.org; Sat, 12 Apr 2003 20:31:26 +0200 Message-ID: <004a01c30121$c63d4ac0$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030411195122.17ff43c9.nico@seul.org> <20030412022136.17081@thrai.stud.uni-hannover.de> <3E976B72.609@f-cpu.org> <001b01c300d6$d3432460$8000a8c0@homeworld> <20030412144221.53294@thrai.stud.uni-hannover.de> Subject: Re: [f-cpu] new cjump instruction Date: Sat, 12 Apr 2003 20:31:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N ----- Original Message ----- From: "Michael Riepe" To: Sent: Saturday, April 12, 2003 2:42 PM Subject: Re: [f-cpu] new cjump instruction > If the linker is allowed to move whole functions (atomically), that > will not be a big problem. If a function is smaller than a page, the > linker can try to put it into a partially used page; if it doesn't fit > or is larger than a page, the linker will have to allocate new pages > and page-align the function. The compiler will just have to specify > beginning and end of functions (that's also needed for link-time register > renaming BTW). The problem is that we won't get so far at all. Indeed, I was speaking about the worst case where we have a library where there is one function for each source file of this library, so you will have a bunch of object files to merge at the end. Sure so long as one function can fit in a page, except that the linker must even relocate the local semi-absolute address jump everytime inside a page (with a local relative address jump for a loop, there is no need). But anyway, it is too much a complication for the linker as for the compiler to handle it. It doesn't worth this effort. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 12 21:16:51 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcK-0007o3-00 for ; Sun, 13 Apr 2003 15:33:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:33:56 +0200 (CEST) Received: (qmail 15314 invoked by uid 65534); 12 Apr 2003 19:14:42 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 12 Apr 2003 21:14:42 +0200 Received: by moria.seul.org (Postfix) id 8DA3433C67; Sat, 12 Apr 2003 15:14:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1F1A33C81; Sat, 12 Apr 2003 15:14:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id 4416733C67 for ; Sat, 12 Apr 2003 15:14:38 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-80.n.club-internet.fr [213.44.3.80]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 1A6D8168E for ; Sat, 12 Apr 2003 21:14:36 +0200 (CEST) Message-ID: <3E986623.5000504@f-cpu.org> Date: Sat, 12 Apr 2003 21:16:51 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, nico wrote: >On Sat, 12 Apr 2003 02:54:07 +0200 >Yann Guidon wrote: > >>huh, i don't think that it's a good answer .... >> >>on top of that, this technique poses new problems in FC0's pipeline. >>sure, addresses are computed fast, but what about their validation, >>their fetch, their lookup in the buffers ...... >> >> > >Validation are usefull because you are inside a pages. > > validation seems ok BUT how do you validate that the new address is already present and available ? you were the first to mention that associative logic is slow .... >fetch are ligthening fast. > i do not agree. >You have an entire clock cycle to do it (no >adder or register read before accessing L1 caches). > > worse : you can check a 64-input associative logic (corresponding to the registers) faster than the "hit" logic of the cache (shorter wires etc....), just in case the other LSU logic says "no" (hey : one has to multiplex the 12-bit LSB path from the instruction with the XBAR's output with leads to the LSU address comparators) [a multiplexor is not 'free gate' today] So let's imagine there is a "dedicated fast path" for this 12-bit address to the L1 cache, and it works in 1 or 2 cycles (well, this adds one other address comparator that will be active EVERY DAMN CYCLE). Then, data must be sent from the cache to the LSU (if absent from the LSU), which takes easily one cycle. Then goes the usual pipeline thing : decode, then issue. so in fact it is not faster. Of course the classical jump is more complex, but it is more flexible. >But the real problem is for the compiler. What is the opinion of the >compiler writter ? > it's a useless constraint .... >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Sat Apr 12 21:08:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcL-0007o3-00 for ; Sun, 13 Apr 2003 15:33:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:33:57 +0200 (CEST) Received: (qmail 1054 invoked by uid 65534); 12 Apr 2003 20:11:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 12 Apr 2003 22:11:32 +0200 Received: by moria.seul.org (Postfix) id 2488933C6A; Sat, 12 Apr 2003 16:11:29 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BF3E33C81; Sat, 12 Apr 2003 16:11:28 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 92C4D33C6A for ; Sat, 12 Apr 2003 16:11:27 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-219.jetnet.ab.ca [207.34.60.219]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h3CKBbhf028655 for ; Sat, 12 Apr 2003 14:11:37 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3E986427.1060904@jetnet.ab.ca> Date: Sat, 12 Apr 2003 13:08:23 -0600 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N nico wrote: > Validation are usefull because you are inside a pages. > > fetch are ligthening fast. You have an entire clock cycle to do it (no > adder or register read before accessing L1 caches). > > But the real problem is for the compiler. What is the opinion of the > compiler writter ? Blah!!!!! But could you not use carry out when adding a signed offset to the PC on a branch to indicate a change in the cache? Carry bit 12 xor sign of offset is page fault? Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 13 01:26:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcQ-0007o3-00 for ; Sun, 13 Apr 2003 15:34:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:34:02 +0200 (CEST) Received: (qmail 28496 invoked by uid 65534); 12 Apr 2003 23:26:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 13 Apr 2003 01:26:44 +0200 Received: by moria.seul.org (Postfix) id 2546933C81; Sat, 12 Apr 2003 19:26:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3422F33C6B; Sat, 12 Apr 2003 19:26:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a188.home.uni-hannover.de [130.75.232.188]) by moria.seul.org (Postfix) with ESMTP id 3995133B61 for ; Sat, 12 Apr 2003 19:26:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA17081; Sun, 13 Apr 2003 01:26:37 +0200 Message-ID: <20030413012637.31292@thrai.stud.uni-hannover.de> Date: Sun, 13 Apr 2003 01:26:37 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <20030412022136.17081@thrai.stud.uni-hannover.de> <3E976B72.609@f-cpu.org> <001b01c300d6$d3432460$8000a8c0@homeworld> <20030412144221.53294@thrai.stud.uni-hannover.de> <004a01c30121$c63d4ac0$8000a8c0@homeworld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <004a01c30121$c63d4ac0$8000a8c0@homeworld>; from Christophe Avoinne on Sat, Apr 12, 2003 at 08:31:45PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Apr 12, 2003 at 08:31:45PM +0200, Christophe Avoinne wrote: [...] > But anyway, it is too much a complication for the linker as for the compiler > to handle it. It doesn't worth this effort. Damn right. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Sun Apr 13 15:21:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194hcz-0007o3-00 for ; Sun, 13 Apr 2003 15:34:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 13 Apr 2003 15:34:37 +0200 (CEST) Received: (qmail 24833 invoked by uid 65534); 13 Apr 2003 11:22:17 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 13 Apr 2003 13:22:17 +0200 Received: by moria.seul.org (Postfix) id F263033C9B; Sun, 13 Apr 2003 07:22:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7541B33C9A; Sun, 13 Apr 2003 07:22:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by moria.seul.org (Postfix) with ESMTP id E81C233C97 for ; Sun, 13 Apr 2003 07:22:13 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with SMTP id 4AE4241071 for ; Sun, 13 Apr 2003 13:22:12 +0200 (CEST) Date: Sun, 13 Apr 2003 13:21:05 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction Message-Id: <20030413132105.23cb9d48.nico@seul.org> In-Reply-To: <3E986623.5000504@f-cpu.org> References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, 12 Apr 2003 21:16:51 +0200 Yann Guidon wrote: > hi, > > nico wrote: > > >On Sat, 12 Apr 2003 02:54:07 +0200 > >Yann Guidon wrote: > > > >>huh, i don't think that it's a good answer .... > >> > >>on top of that, this technique poses new problems in FC0's pipeline. > >>sure, addresses are computed fast, but what about their validation, > >>their fetch, their lookup in the buffers ...... > >> > >> > > > >Validation are usefull because you are inside a pages. > > > > > validation seems ok BUT how do you validate that the new address is > already present and available ? you were the first to mention that > associative logic is slow .... > it is. But where do you see any associative logic ? > >fetch are ligthening fast. > > > i do not agree. I would say : it will be the fastest in this case comparre to other. > > >You have an entire clock cycle to do it (no > >adder or register read before accessing L1 caches). > > > > > worse : > you can check a 64-input associative logic (corresponding to the > registers) faster than the "hit" logic of the cache (shorter wires > etc....), just in case the other LSU logic says "no" (hey : one has to > multiplex the 12-bit LSB path from the instruction with the XBAR's > output with leads to the LSU address comparators) [a multiplexor is > not 'free gate' today] > > So let's imagine there is a "dedicated fast path" for this 12-bit > address to the L1 cache, > and it works in 1 or 2 cycles (well, this adds one other address > comparator that > will be active EVERY DAMN CYCLE). > Then, data must be sent from the cache to the LSU (if absent from the > LSU), which takes easily one cycle. Then goes the usual pipeline thing > : decode, then issue. > so in fact it is not faster. > Of course the classical jump is more complex, but it is more flexible. > All of this is part of the beginning of the pipeline (fetch stages). There is nothing about it in the manual or elsewhere. So i use the usual paradigm of a memory bus (adresse/data). So fetch send an adress and receive a data from the L1 cache memory. The adress must be available as soon as possible. So 12 lsb don't need any adder, so it's the fastest. (beside that fast L1 have 2 or 3 cycles latency but a thoughtput of 1) If you want to add multiple buffer, and bunch of decoder, that's up to you (this also add latency). But you will always need somewhere a memory bus, and it will be the slowest part. > >But the real problem is for the compiler. What is the opinion of the > >compiler writter ? > > > it's a useless constraint .... no it's not useless. It permit 0 cycle jump (without jump prediction). So unroll loops will be far less interresseting, you will save L1 cache space. In the worst case,(1 fonction by .c file) such file could avoid using it. Tight loop could be much faster. So devik, what do you think of it ? > > >nicO > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 13 19:34:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194sUE-0002FX-00 for ; Mon, 14 Apr 2003 03:10:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 03:10:18 +0200 (CEST) Received: (qmail 1878 invoked by uid 65534); 13 Apr 2003 17:31:56 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 13 Apr 2003 19:31:56 +0200 Received: by moria.seul.org (Postfix) id A5C9433CAA; Sun, 13 Apr 2003 13:31:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AFEF533CB4; Sun, 13 Apr 2003 13:31:53 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id A241A33CAA for ; Sun, 13 Apr 2003 13:31:52 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-78.n.club-internet.fr [213.44.21.78]) by relay-5m.club-internet.fr (Postfix) with ESMTP id F24ACE394 for ; Sun, 13 Apr 2003 19:31:49 +0200 (CEST) Message-ID: <3E999F8E.3020401@f-cpu.org> Date: Sun, 13 Apr 2003 19:34:06 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! nico wrote: >On Sat, 12 Apr 2003 21:16:51 +0200 >Yann Guidon wrote: > >>hi, >> >>nico wrote: >> >>>On Sat, 12 Apr 2003 02:54:07 +0200 >>>Yann Guidon wrote: >>> >>>>huh, i don't think that it's a good answer .... >>>> >>>>on top of that, this technique poses new problems in FC0's pipeline. >>>>sure, addresses are computed fast, but what about their validation, >>>>their fetch, their lookup in the buffers ...... >>>> >>>Validation are usefull because you are inside a pages. >>> >>validation seems ok BUT how do you validate that the new address is >>already present and available ? you were the first to mention that >>associative logic is slow .... >> >it is. But where do you see any associative logic ? > > it depends on the architecture of the cache memory that is used, and this can change from implementation to implementation .... >>>fetch are ligthening fast. >>> >>i do not agree. >> >> >I would say : it will be the fastest in this case comparre to other. > > each stage will be as "fast" as in other cases. however, the sequence of events changes dramatically and the register-based version is clearly faster for small loops. >>>You have an entire clock cycle to do it (no >>>adder or register read before accessing L1 caches). >>> >>worse : >>you can check a 64-input associative logic (corresponding to the >>registers) faster than the "hit" logic of the cache (shorter wires >>etc....), just in case the other LSU logic says "no" (hey : one has to >>multiplex the 12-bit LSB path from the instruction with the XBAR's >>output with leads to the LSU address comparators) [a multiplexor is >>not 'free gate' today] >> >> hmm, i made a mistake here : not only we have to check the LSU, but also the Fetcher's buffer, to look up for this address. and i'm not sure that the address comparison will be only 12-bit wide. >>So let's imagine there is a "dedicated fast path" for this 12-bit >>address to the L1 cache, >>and it works in 1 or 2 cycles (well, this adds one other address >>comparator that >>will be active EVERY DAMN CYCLE). >>Then, data must be sent from the cache to the LSU (if absent from the >>LSU), which takes easily one cycle. Then goes the usual pipeline thing >>: decode, then issue. so in fact it is not faster. >>Of course the classical jump is more complex, but it is more flexible. >> > >All of this is part of the beginning of the pipeline (fetch stages). > yep but depending on where the target address is located, the sequence of events change. face it : just like any memory access (either data fetch or jump), the target is either (or both) in LSU, Fetcher, L1, L2, main DRAM or in mass storage. For short loops, the register-based jump wins : the target remains in "cache" in the Fetcher's buffer, and the number of checks is minimal, and there are only 6 bits to code this. This comes at the price of prefetching the target, there might be a stall during the first loop run, that's all. your immediate cjump does not solve the pipeline bubble problem, so it has no chance to run small loops faster. it also requires address checks that are not minimal. I concede that page boundaries are not to be checked, but it adds a burden on the software and it does not remove all the checks for the other things : where is the target, in the memory hierarchy ? >There is nothing about it in the manual or elsewhere. > > trust me if you want. >So i use the usual paradigm of a memory bus (adresse/data). > unless you want to design a small microcontroller, this is not useful. >So fetch >send an adress and receive a data from the L1 cache memory. The >adress must be available as soon as possible. So 12 lsb don't need any >adder, so it's the fastest. (beside that fast L1 have 2 or 3 cycles >latency but a thoughtput of 1) > > in this situation, you don't take any instruction buffer into account. So each time you jump, you have a 2 or 3-cycle penalty. The purpose of the register-based jump is to benefit from the instruction buffer (the "Fetcher"'s buffer). It doesn't even require an addition either, and spares the L1 fetch in small loops (garanteed !) Of course there is HW overhead to check the validity of the register, and some SW overhead to prefetch the target BUT it doesn't impose tough constraints on the linker or compiler (well, not of the kind of what you re-proposed) and the prefetch can be simplified quite easily (when several instructions lead to the same jump address). >If you want to add multiple buffer, and bunch of decoder, that's up to >you (this also add latency). But you will always need somewhere a memory >bus, and it will be the slowest part. > > you forget about the instruction buffer. >>>But the real problem is for the compiler. What is the opinion of the >>>compiler writter ? >>> >>it's a useless constraint .... >> >> >no it's not useless. It permit 0 cycle jump (without jump prediction). > no. >So unroll loops will be far less interresseting, you will save L1 cache >space. In the worst case,(1 fonction by .c file) such file could avoid >using it. Tight loop could be much faster. > > your "solution" does not remove pipeline bubbles ! it is NOT possible to jump in no cycle, because the pipeline is so tight that there are at least 1 or 2 instruction being decoded at the same time. i know it, because i have fallen in the same trap. Even if you maintain 2 parallel execution streams in advance, or store stalled pipeline stages, you CAN'T jump in zero time simply because the register set would require 2x or 3x more read ports ! And even then, the time to propagate the order to switch from one execution stream to another is too high, it costs at least one cycle, so here we are back to the initial problem : we can't compress time. i hope that this explanation is not confuse. >So devik, what do you think of it ? > >>>nicO >>> >>YG >> >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Mon Apr 14 01:16:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194sUK-0002FX-00 for ; Mon, 14 Apr 2003 03:10:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 03:10:24 +0200 (CEST) Received: (qmail 1293 invoked by uid 65534); 13 Apr 2003 21:17:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013-rz3) with SMTP; 13 Apr 2003 23:17:27 +0200 Received: by moria.seul.org (Postfix) id B1A2F33CB8; Sun, 13 Apr 2003 17:17:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2773233CBB; Sun, 13 Apr 2003 17:17:24 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by moria.seul.org (Postfix) with ESMTP id 654B533CB8 for ; Sun, 13 Apr 2003 17:17:22 -0400 (EDT) Received: from Biathlon (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with SMTP id 1D52262D69 for ; Sun, 13 Apr 2003 23:17:15 +0200 (CEST) Date: Sun, 13 Apr 2003 23:16:07 +0000 From: nico To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction Message-Id: <20030413231607.28a8a3f1.nico@seul.org> In-Reply-To: <3E999F8E.3020401@f-cpu.org> References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> <3E999F8E.3020401@f-cpu.org> X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i586-mandrake-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, 13 Apr 2003 19:34:06 +0200 Yann Guidon wrote: > hi ! > > nico wrote: > > >On Sat, 12 Apr 2003 21:16:51 +0200 > >Yann Guidon wrote: > > > >>hi, > >> > >>nico wrote: > >> > >>>On Sat, 12 Apr 2003 02:54:07 +0200 > >>>Yann Guidon wrote: > >>> > >>>>huh, i don't think that it's a good answer .... > >>>> > >>>>on top of that, this technique poses new problems in FC0's > >pipeline.>>>sure, addresses are computed fast, but what about their > >validation,>>>their fetch, their lookup in the buffers ...... > >>>> > >>>Validation are usefull because you are inside a pages. > >>> > >>validation seems ok BUT how do you validate that the new address is > >>already present and available ? you were the first to mention that > >>associative logic is slow .... > >> > >it is. But where do you see any associative logic ? > > > > > it depends on the architecture of the cache memory that is used, > and this can change from implementation to implementation .... > Yep. But it's always a memory to access. Beside that "usual" memory IP are one cycle access (async read, sync write). > >>>fetch are ligthening fast. > >>> > >>i do not agree. > >> > >> > >I would say : it will be the fastest in this case comparre to other. > > > > > each stage will be as "fast" as in other cases. > however, the sequence of events changes dramatically and the > register-based version is clearly faster for small loops. > When you see gcc output code, we see a lot the use of immediat jump which is translate in 5 consecutives instruction. Not very optimal. > >>>You have an entire clock cycle to do it (no > >>>adder or register read before accessing L1 caches). > >>> > >>worse : > >>you can check a 64-input associative logic (corresponding to the > >>registers) faster than the "hit" logic of the cache (shorter wires > >>etc....), just in case the other LSU logic says "no" (hey : one has > >to>multiplex the 12-bit LSB path from the instruction with the XBAR's > >>output with leads to the LSU address comparators) [a multiplexor is > >>not 'free gate' today] > >> > >> > hmm, i made a mistake here : not only we have to check the LSU, > but also the Fetcher's buffer, to look up for this address. > and i'm not sure that the address comparison will be only 12-bit wide. > The most i can say is that is as usual : not cleat at all. :) At a time or another, you will have to access a memory bus ! A pipeline must be feed at each cycle. Adding buffer don't change that. > >>So let's imagine there is a "dedicated fast path" for this 12-bit > >>address to the L1 cache, > >>and it works in 1 or 2 cycles (well, this adds one other address > >>comparator that > >>will be active EVERY DAMN CYCLE). > >>Then, data must be sent from the cache to the LSU (if absent from > >the>LSU), which takes easily one cycle. Then goes the usual pipeline > >thing>: decode, then issue. so in fact it is not faster. > >>Of course the classical jump is more complex, but it is more > >flexible.> > > > >All of this is part of the beginning of the pipeline (fetch stages). > > > yep but depending on where the target address is located, > the sequence of events change. > face it : just like any memory access (either data fetch or jump), > the target is either (or both) in LSU, Fetcher, L1, L2, main DRAM or > in mass storage. > Yes, but LSU/Fetcher is inside the pipeline. The output is the L1 caches wich represent 95% of the fetch (then L2, then DRAM, there is no direct access to mass storage !). > For short loops, the register-based jump wins : the target remains in > "cache" What is L1 if it isn't a cache ? > in the Fetcher's buffer, and the number of checks is minimal, and > there are only 6 bits to code this. > This comes at the price of prefetching the target, there might be a > stall during > the first loop run, that's all. > That's means when there is no loop, you must add bubble beside each instruction ? > your immediate cjump does not solve the pipeline bubble problem, > so it has no chance to run small loops faster. :) Because you try to addapt this instruction to your complex stuff. "My jump" didn't need all this complexity. > it also requires address checks that are not minimal. nop. No need. > I concede that page boundaries are not to be checked, > but it adds a burden on the software and it does not > remove all the checks for the other things : where is > the target, in the memory hierarchy ? > That's a false problem. This hirearachy is undefined nowadays. The only true problem is a software one. > >There is nothing about it in the manual or elsewhere. > > > > > trust me if you want. :) Good joke ! > > >So i use the usual paradigm of a memory bus (adresse/data). > > > unless you want to design a small microcontroller, this is not useful. > That's only how all cpu work... > >So fetch > >send an adress and receive a data from the L1 cache memory. The > >adress must be available as soon as possible. So 12 lsb don't need > >any adder, so it's the fastest. (beside that fast L1 have 2 or 3 > >cycles latency but a thoughtput of 1) > > > > > in this situation, you don't take any instruction buffer into account. ? The purpose of the fetch stage is to filed the instruction buffer. So i don't understand your point. > So each time you jump, you have a 2 or 3-cycle penalty. It's depend on the L1 cache structure, only. You must feed the pipeline every cycle what ever internal buffer you use, it always a small amount compare to L1. If it's not, it's much easier to use a faster L1 cache, like the choice of Pentium4 of using 8Ko L1 cache but with a latency of 2, compare to the latency of 3 of the 64Ko cache of the Athlon. > > The purpose of the register-based jump is to benefit from the > instruction buffer (the "Fetcher"'s buffer). It doesn't even require > an addition either, > and spares the L1 fetch in small loops (garanteed !) It's depend what you called "small", f-cpu need a lot of unrolling because of RAW dependancies (don't forget the "internal" RAW of the MAC instruction, and the 6 stages of the mul IU). This buffer are almost sur to blown quickly. > Of course there is HW overhead to check the validity of the register, > and some SW overhead to prefetch the target BUT it doesn't impose Overhead that you find because instead of having one instruction, most of the time you have 5 of it. > tough constraints on the linker or compiler (well, not of the kind of > what you re-proposed) and the prefetch can be simplified quite easily > (when several instructions lead to the same jump address). > Simplify prefetch ? What is most simple than a memory bus ? > >If you want to add multiple buffer, and bunch of decoder, that's up > >to you (this also add latency). But you will always need somewhere a > >memory bus, and it will be the slowest part. > > > > > you forget about the instruction buffer. > nop. > >>>But the real problem is for the compiler. What is the opinion of > >the>>compiler writter ? > >>> > >>it's a useless constraint .... > >> > >> > >no it's not useless. It permit 0 cycle jump (without jump > >prediction). > > > no. > Because, you think of all the complexity you will add. > >So unroll loops will be far less interresseting, you will save L1 > >cache space. In the worst case,(1 fonction by .c file) such file > >could avoid using it. Tight loop could be much faster. > > > > > your "solution" does not remove pipeline bubbles ! > it is NOT possible to jump in no cycle, because the pipeline > is so tight that there are at least 1 or 2 instruction being decoded > at the same time. ??? We have a one issue cpu. > i know it, because i have fallen in the same trap. > > Even if you maintain 2 parallel execution streams in advance, > or store stalled pipeline stages, you CAN'T jump in zero time > simply because the register set would require 2x or 3x more read ports > ! And even then, the time to propagate the order to switch from > one execution stream to another is too high, it costs at least > one cycle, so here we are back to the initial problem : > we can't compress time. That's why you are stuck by the L1 cache speed. > > i hope that this explanation is not confuse. It was like usual :) nicO > > >So devik, what do you think of it ? > > > >>>nicO > >>> > >>YG > >> > >> > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 13 18:43:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 194sUN-0002FX-00 for ; Mon, 14 Apr 2003 03:10:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 03:10:27 +0200 (CEST) Received: (qmail 15748 invoked by uid 65534); 13 Apr 2003 22:36:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 14 Apr 2003 00:36:58 +0200 Received: by moria.seul.org (Postfix) id C989A33CBA; Sun, 13 Apr 2003 18:36:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76D5233CBC; Sun, 13 Apr 2003 18:36:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a195.home.uni-hannover.de [130.75.232.195]) by moria.seul.org (Postfix) with ESMTP id EA04633CBA for ; Sun, 13 Apr 2003 18:36:52 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id SAA00879; Sun, 13 Apr 2003 18:43:44 +0200 Message-ID: <20030413184344.31654@thrai.stud.uni-hannover.de> Date: Sun, 13 Apr 2003 18:43:44 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030413132105.23cb9d48.nico@seul.org>; from nico on Sun, Apr 13, 2003 at 01:21:05PM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Apr 13, 2003 at 01:21:05PM +0000, nico wrote: [...] > All of this is part of the beginning of the pipeline (fetch stages). > There is nothing about it in the manual or elsewhere. [...] Well, then let's try to fill that gap. I'll assume that the fetcher sends an aligned address to the I-cache and always receives a complete cache line (256 bits = 32 bytes = 8 instructions). In sequential code, it will have to fetch a new line every 8 cycles -- and it can prefetch the next line in sequence as soon as it starts executing the current line, which gives the I-cache a number of cycles to deliver. In order to speed things up further, instructions may be pre-decoded in parallel as soon as the fetcher has received a cache line, and stored in pre-decoded form. That is, instructions that need special attention would be flagged so that they can be quickly recognized later. The fetcher (short for "instruction fetch/decode/issue unit") executes instructions from beginning to end of the current line. Most instructions are simply delegated to other execution units, but some need special handling. An important one is `loadaddr[i]'. The fetcher will send PC+4 (may be precomputed) and the immediate value (if any) to the adder, and it will use the result to prefetch another cache line into one of its buffers (BTW: I guess it may be better to use a dedicated adder instead of EU_ASU). When the fetcher executes a jump that refers to the prefetched line, it can simply switch buffers and go ahead. If the target line has not been prefetched yet (which is also the case for your proposed `cjump' instruction), the fetcher will have to stop, obtain the target address and start a new I-cache fetch cycle before it can continue. That will take quite a while, even if you can skip the TLB lookup (so much for "fetch is fast"). Note that many TLB lookups can be skipped anyway if the fetcher remembers the dimensions of the current page(s). Did I miss anything? Well, probably a lot. Yann, please correct me if I'm wrong. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Apr 14 10:29:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1952Fe-0000b9-00 for ; Mon, 14 Apr 2003 13:35:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 13:35:54 +0200 (CEST) Received: (qmail 17667 invoked by uid 65534); 14 Apr 2003 08:30:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 14 Apr 2003 10:30:32 +0200 Received: by moria.seul.org (Postfix) id 54A4E33CBF; Mon, 14 Apr 2003 04:30:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6027433CC5; Mon, 14 Apr 2003 04:30:29 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 2CD8833CBF for ; Mon, 14 Apr 2003 04:30:27 -0400 (EDT) Received: from a45-137.dialup.iol.cz ([194.228.137.45] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 194zM6-0005f3-00 for f-cpu@seul.org; Mon, 14 Apr 2003 10:30:23 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 194zLH-0000LP-00 for f-cpu@seul.org; Mon, 14 Apr 2003 10:29:31 +0200 Date: Mon, 14 Apr 2003 10:29:31 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] new cjump instruction In-Reply-To: <20030413132105.23cb9d48.nico@seul.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N A few ideas from sw point of view. 12 bit "replacement" part would force jump to fixed point within page unless linker would fix it. GCC could generate page aligned loop bodies but it will need rewrite of BB reorg pass and will lead to suboptimal branches sometimes. Regarding MD's note about assembler labels - gcc has provision for handling dynamic code size in order to fix jumps in last compile stage. On other side, register based jumps are pain in code with many branches as they consume 1/3 of all insns. I'd really like to see some kind of fast forward jump in range about 8-32 insns. For loops, register based jump is not so bad because it can be loaded once and used many times. It doesn't hold for small "switches" or frequent conditional branches linked end to end (like in GCC source code generated from .md). Maybe jump within insn buffers ? devik On Sun, 13 Apr 2003, nico wrote: > On Sat, 12 Apr 2003 21:16:51 +0200 > Yann Guidon wrote: > > > hi, > > > > nico wrote: > > > > >On Sat, 12 Apr 2003 02:54:07 +0200 > > >Yann Guidon wrote: > > > > > >>huh, i don't think that it's a good answer .... > > >> > > >>on top of that, this technique poses new problems in FC0's pipeline. > > >>sure, addresses are computed fast, but what about their validation, > > >>their fetch, their lookup in the buffers ...... > > >> > > >> > > > > > >Validation are usefull because you are inside a pages. > > > > > > > > validation seems ok BUT how do you validate that the new address is > > already present and available ? you were the first to mention that > > associative logic is slow .... > > > > it is. But where do you see any associative logic ? > > > >fetch are ligthening fast. > > > > > i do not agree. > > I would say : it will be the fastest in this case comparre to other. > > > > > >You have an entire clock cycle to do it (no > > >adder or register read before accessing L1 caches). > > > > > > > > worse : > > you can check a 64-input associative logic (corresponding to the > > registers) faster than the "hit" logic of the cache (shorter wires > > etc....), just in case the other LSU logic says "no" (hey : one has to > > multiplex the 12-bit LSB path from the instruction with the XBAR's > > output with leads to the LSU address comparators) [a multiplexor is > > not 'free gate' today] > > > > So let's imagine there is a "dedicated fast path" for this 12-bit > > address to the L1 cache, > > and it works in 1 or 2 cycles (well, this adds one other address > > comparator that > > will be active EVERY DAMN CYCLE). > > Then, data must be sent from the cache to the LSU (if absent from the > > LSU), which takes easily one cycle. Then goes the usual pipeline thing > > : decode, then issue. > > so in fact it is not faster. > > Of course the classical jump is more complex, but it is more flexible. > > > > All of this is part of the beginning of the pipeline (fetch stages). > There is nothing about it in the manual or elsewhere. > > So i use the usual paradigm of a memory bus (adresse/data). So fetch > send an adress and receive a data from the L1 cache memory. The > adress must be available as soon as possible. So 12 lsb don't need any > adder, so it's the fastest. (beside that fast L1 have 2 or 3 cycles > latency but a thoughtput of 1) > > If you want to add multiple buffer, and bunch of decoder, that's up to > you (this also add latency). But you will always need somewhere a memory > bus, and it will be the slowest part. > > > >But the real problem is for the compiler. What is the opinion of the > > >compiler writter ? > > > > > it's a useless constraint .... > > no it's not useless. It permit 0 cycle jump (without jump prediction). > So unroll loops will be far less interresseting, you will save L1 cache > space. In the worst case,(1 fonction by .c file) such file could avoid > using it. Tight loop could be much faster. > > So devik, what do you think of it ? > > > > > >nicO > > > > > > > > YG > > > > ************************************************************* > > To unsubscribe, send an e-mail to majordomo@seul.org with > > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 14 10:57:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1952Fh-0000b9-00 for ; Mon, 14 Apr 2003 13:35:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 13:35:57 +0200 (CEST) Received: (qmail 12415 invoked by uid 65534); 14 Apr 2003 08:54:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 14 Apr 2003 10:54:58 +0200 Received: by moria.seul.org (Postfix) id 7215633CC3; Mon, 14 Apr 2003 04:54:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DE67B33CC6; Mon, 14 Apr 2003 04:54:56 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id B78E333CC3 for ; Mon, 14 Apr 2003 04:54:55 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-14.n.club-internet.fr [213.44.21.14]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 315DA16F8 for ; Mon, 14 Apr 2003 10:54:53 +0200 (CEST) Message-ID: <3E9A77EB.408@f-cpu.org> Date: Mon, 14 Apr 2003 10:57:15 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> <20030413184344.31654@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Sun, Apr 13, 2003 at 01:21:05PM +0000, nico wrote: >[...] > > >>All of this is part of the beginning of the pipeline (fetch stages). >>There is nothing about it in the manual or elsewhere. >> >> >[...] > >Well, then let's try to fill that gap. > >Did I miss anything? Well, probably a lot. >Yann, please correct me if I'm wrong. > not much time to answer but : The LSU (Load Store Unit) and the Fetcher have a similar structure : prefetch logic (increment addresses), cache logic (LRU, validity bits etc.) and multiported memory (small, fine-grained cache). The main difference is that the Fetcher's buffer contains 32-bit words in read-only mode while the LSU manages read and write of bytes. This increases the complexity a bit. The Fetcher also has a sequencial behaviour (there is a flag that says whether to get the next instruction) while the LSU is random-access. In the instruction flow pipeline, the Fetcher is at the first place : it is where instructions are fetched and buffered. When a line is first accessed, the Fetcher takes the address of the current line, increments it (upon overflow of the 12 LSB, it checks the TLB) and performs a read request to L1. The goal is to maintain a constantly prefetched instruction stream, and compensate for average memory latencies : with 8 instructions per line (256 bits), it gives 8 cycles to compute the next address, check if it is present in LSU, Fetcher and I-Cache, and fetch it. If absent, there are still a few clocks lefts for a fetch from L2. So the "Fetcher" fetches instructions in advance, sequentially. Linear code will use a "double buffer" with 2 lines. If a jump occurs, a new set of lines is found through LRU, so a jump back (return ?) to the calling code is possible. There are usually 8 lines. The Fetcher presents one instruction at each clock cycle to the pipeline, as well as its address (which is generated from the line's virtual address and the index of the instruction in the line, obtained from the counter). The next pipeline stages (decode / R7 read and issue/Xbar) give a "next instruction" bit to the fetcher, in order to advance the instruction counter and get the next instruction. So the fetcher selects a new word either in the current line or another one, and this is completely transparent to the rest of the pipeline (which just begs for a new instruction). Naturally, if there is a stall in the memory, it propagates to the pipeline through the Fetcher, but we count on its buffers and "intelligence" to reduce the stall's costs. Next comes "Decode". it "explodes" the instruction word into all the subfields and checks for whatever conditions exists. This means : reading all registers in the 3 corresponding fields, checking whether their value is available in the next cycle, whether the pointer field corresponds to a valid pointer or an invalid pointer or nothing, check whether the condition is true, check whether the instruction is valid .... All those fields and flags are condensed into a few bits in the next cycle : "Issue/Xbar", where it is computed whether to fetch the next instruction, jump to the target, wait (stall) or trap. At the end of this cycle, if the instruction is valid and accepted, it "officially" enters the pipeline and the corresponding flags are updated in the scheduler's queue (depending on the latency determined by a table lookup during the decode cycle). Answers to MR : * currently, i don't think that predecoding can bring any advantage (yet). It will be useful in later architectures but i see no case where it can bring any benefit. * Loadaddri : the ASU can be used anyway, because the TLB is hooked to its output (on a "user-hidden port", kinda specific bypass). The TLB can get addresses from the Xbar ( a register or a unit bypass) or from the ASU (used by load/store with postincrement). One "optimisation" is to bypass the TLB when no carry occurs on the 12th bit but lookup in the LSU and/or Fetcher's buffer is always performed after that. It is better to reuse the ASU when there is a register operand, because it will benefit from the bypass on Xbar. A specific adder could be added to perform "fast/early" compute but it can be spared at the cost of more latency. Both solutions should be left to the user, in case there is a possible tradeoff for power consumption, speed and room. However, the Fetcher contains a pair of 'incrementers', one to increment the virtual address "tag" and another is a simple counter (from 0 to 7). maybe the large incrementer can be made into a normal adder that performs "loadaddri". This won't work for register-relative "loadaddr". i hope everyone understood, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 14 11:27:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1952Fk-0000b9-00 for ; Mon, 14 Apr 2003 13:36:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 13:36:00 +0200 (CEST) Received: (qmail 28633 invoked by uid 65534); 14 Apr 2003 09:25:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 14 Apr 2003 11:25:44 +0200 Received: by moria.seul.org (Postfix) id 2377533CC6; Mon, 14 Apr 2003 05:25:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9E0133CC8; Mon, 14 Apr 2003 05:25:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C473333CC6 for ; Mon, 14 Apr 2003 05:25:39 -0400 (EDT) Received: from f-cpu.org (lcbv4-2-20.n.club-internet.fr [213.44.93.20]) by relay-1v.club-internet.fr (Postfix) with ESMTP id E81F817A5 for ; Mon, 14 Apr 2003 11:25:37 +0200 (CEST) Message-ID: <3E9A7F1F.2020304@f-cpu.org> Date: Mon, 14 Apr 2003 11:27:59 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, devik wrote: >A few ideas from sw point of view. 12 bit "replacement" >part would force jump to fixed point within page unless >linker would fix it. >GCC could generate page aligned loop bodies but it will >need rewrite of BB reorg pass and will lead to suboptimal >branches sometimes. >Regarding MD's note about assembler labels - gcc has >provision for handling dynamic code size in order to >fix jumps in last compile stage. > >On other side, register based jumps are pain in code with >many branches as they consume 1/3 of all insns. >I'd really like to see some kind of fast forward jump >in range about 8-32 insns. >For loops, register based jump is not so bad because >it can be loaded once and used many times. It doesn't >hold for small "switches" or frequent conditional branches >linked end to end (like in GCC source code generated from >..md). >Maybe jump within insn buffers ? > > i would gladly have relative short jumps inside the Fetcher's buffer but it ends up with most of the same problems (or lack of enhancements) as the "replacement" (well, "displacement" and "replacement" are two similar words, hence similar properties ? :-D) "replacement" within 8 instructions (within the same line) is no problem at all, because there is no check to do. Well, it won't go far. Now, considering that any "touch" of a Fetcher's line triggers the fetch of the next line, a "replacement" within 16 instructions becomes probable but increases the number of checks : for example, if the short jump is in the 1st instruction of the line, the increment of the line's base address, thus the carry and the TLB have not even been checked so we don't know whether it is possible to execute the branch. In order to avoid problems, this situation must be detected, and any check requires time and resources, increasing latency. +/-32 range is possible because the register field uses 6 bits. Negative jump is probable, given that the instructions have already been executed. Now, there are increasing chances that something strange has appeared or will appear, which increases the complexity of the checks.... For example, what about jumping to instruction -20 if there have been several breaks in instruction flow ? Unfortunately i can't discuss much about this now, and i don't want to give false hopes. jumps are bitches anyway ... >devik > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 14 14:39:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1956Sr-0003qz-01 for ; Mon, 14 Apr 2003 18:05:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 18:05:49 +0200 (CEST) Received: (qmail 5241 invoked by uid 65534); 14 Apr 2003 12:41:21 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 14 Apr 2003 14:41:21 +0200 Received: by moria.seul.org (Postfix) id 4E3F133CA1; Mon, 14 Apr 2003 08:41:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 338F133CCB; Mon, 14 Apr 2003 08:41:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a217.home.uni-hannover.de [130.75.232.217]) by moria.seul.org (Postfix) with ESMTP id B3D0033CA1 for ; Mon, 14 Apr 2003 08:41:10 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00783; Mon, 14 Apr 2003 14:39:51 +0200 Message-ID: <20030414143950.27384@thrai.stud.uni-hannover.de> Date: Mon, 14 Apr 2003 14:39:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> <20030413184344.31654@thrai.stud.uni-hannover.de> <3E9A77EB.408@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E9A77EB.408@f-cpu.org>; from Yann Guidon on Mon, Apr 14, 2003 at 10:57:15AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 14, 2003 at 10:57:15AM +0200, Yann Guidon wrote: [...] > In the instruction flow pipeline, the Fetcher is at the first place : > it is where instructions are fetched and buffered. When a line > is first accessed, the Fetcher takes the address of the current line, > increments it (upon overflow of the 12 LSB, it checks the TLB) > and performs a read request to L1. The goal is to maintain > a constantly prefetched instruction stream, and compensate for > average memory latencies : with 8 instructions per line (256 bits), > it gives 8 cycles to compute the next address, check if it is > present in LSU, Fetcher and I-Cache, and fetch it. If absent, > there are still a few clocks lefts for a fetch from L2. The fetcher could increment the address as soon as it requests a cache line (in parallel, just as a postincremented load would do). Maybe even earlier if we use a `tandem register' (that is, double buffering). > So the "Fetcher" fetches instructions in advance, sequentially. > Linear code will use a "double buffer" with 2 lines. > If a jump occurs, a new set of lines is found through LRU, > so a jump back (return ?) to the calling code is possible. > There are usually 8 lines. Which means that we can handle at least four different locations, right? > The Fetcher presents one instruction at each clock cycle > to the pipeline, as well as its address (which is generated > from the line's virtual address and the index of the instruction in > the line, obtained from the counter). The next pipeline stages > (decode / R7 read and issue/Xbar) give a "next instruction" > bit to the fetcher, in order to advance the instruction counter > and get the next instruction. So the fetcher selects a new word > either in the current line or another one, and this is completely > transparent to the rest of the pipeline (which just begs for > a new instruction). Naturally, if there is a stall in the memory, > it propagates to the pipeline through the Fetcher, but we count > on its buffers and "intelligence" to reduce the stall's costs. Yep. But I'd rather present the whole cache line to the decoder, and let it send back a `next line' bit. Alternatively, the decoder could use an `instruction window' that contains 2...4 (or more) instructions. In case we ever want to do a kind of peephole optimization here (or issue several instructions per cycle), we wouldn't have to change the fetcher. BTW: One possible optimization would be `loadcons clustering'. If there are several loadcons[x] instructions in a row (with the same destination register), the decoder might put the constants together and process all the loads in a single cycle. > Next comes "Decode". it "explodes" the instruction word > into all the subfields and checks for whatever conditions exists. > This means : reading all registers in the 3 corresponding fields, > checking whether their value is available in the next cycle, > whether the pointer field corresponds to a valid pointer > or an invalid pointer or nothing, check whether the condition > is true, check whether the instruction is valid .... > > All those fields and flags are condensed into a few bits > in the next cycle : "Issue/Xbar", where it is computed > whether to fetch the next instruction, jump to the target, > wait (stall) or trap. At the end of this cycle, if the instruction > is valid and accepted, it "officially" enters the pipeline > and the corresponding flags are updated in the scheduler's queue > (depending on the latency determined by a table lookup > during the decode cycle). Yep. > Answers to MR : > * currently, i don't think that predecoding > can bring any advantage (yet). It will be useful in later architectures > but i see no case where it can bring any benefit. The main idea was to simplify the decoder (lower latency), and to have some bits available in the fetcher that can be used for code flow analysis. E.g. if there is an unconditional jump, the fetcher may skip the `linear' prefetch cycle to save memory bandwidth (and a buffer); if there is a syscall instruction, it may prefetch code from the syscall handler, and so on. > * Loadaddri : the ASU can be used anyway, because the TLB is hooked > to its output (on a "user-hidden port", kinda specific bypass). > The TLB can get addresses from the Xbar ( a register or a unit bypass) > or from the ASU (used by load/store with postincrement). The TLB will also get addresses directly from the fetcher (for sequential instruction prefetch), won't it? > One "optimisation" is to bypass the TLB when no carry occurs > on the 12th bit but lookup in the LSU and/or Fetcher's buffer is > always performed after that. > It is better to reuse the ASU when there is a register operand, > because it will benefit from the bypass on Xbar. > A specific adder could be added to perform "fast/early" compute > but it can be spared at the cost of more latency. Both solutions > should be left to the user, in case there is a possible tradeoff > for power consumption, speed and room. > However, the Fetcher contains a pair of 'incrementers', > one to increment the virtual address "tag" and another > is a simple counter (from 0 to 7). maybe the large incrementer > can be made into a normal adder that performs "loadaddri". > This won't work for register-relative "loadaddr". An adder for loadaddri won't fit into a single pipeline stage. And there is another problem with loadaddri: both operands come from the IF/D unit. We already have so many adders that one more or less doesn't really count. EU_ASU has one 64-bit adder, EU_IMU has four 128-bit adders, EU_IDU has one 64-bit adder (two if we're going to support `rem' and `divrem'), and we'll need yet another adder to support `addsub'. Plus any adders that will be required to implement the FPU (at least two or three). Small adders (< 64 bits) not listed. We could make a version with shared adders (e.g. ASU/IMU/IDU might share a single 128-bit adder), but its latency would probably be worse, parallelism would be lost, and scheduling might become more difficult. On the other hand, it would allow us to make a cheaper FC0 -- we would save not only a significant portion of die area, but also ~10 Xbar ports. I'll write such an `Integer Arithmetic Unit' (EU_IAU) if you're interested. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 1951714@korea.com Mon Apr 14 16:36:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1956St-0003qz-01 for ; Mon, 14 Apr 2003 18:05:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 14 Apr 2003 18:05:51 +0200 (CEST) Received: (qmail 17691 invoked by uid 65534); 14 Apr 2003 14:36:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 14 Apr 2003 16:36:32 +0200 Received: by moria.seul.org (Postfix) id 9A4D033CD2; Mon, 14 Apr 2003 10:36:30 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7807A33CD4; Mon, 14 Apr 2003 10:36:29 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from korea.com (unknown [218.235.117.145]) by moria.seul.org (Postfix) with SMTP id DF81233CD2 for ; Mon, 14 Apr 2003 10:36:24 -0400 (EDT) From: eCapture <1951714@korea.com> To: f-cpu@seul.org Subject: [f-cpu] (±¤°í) °³Á¤µÈ ¹ý¿¡ ¸ÂÃá ÀÎÅÍ³Ý ±¤°í ÇÁ·Î±×·¥ÀÔ´Ï´Ù. Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030414143624.DF81233CD2@moria.seul.org> Date: Mon, 14 Apr 2003 10:36:24 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N
±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2003-04-12 ¿ÀÈÄ 4:28:24 ¿¡ www.rosat.mpe-garching.mpg.de/mailing-lists/modules/2002-10/msg00008.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.
Neo Logic2
 
 
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Apr 15 03:17:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 195Y5k-0006XJ-00 for ; Tue, 15 Apr 2003 23:35:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Apr 2003 23:35:48 +0200 (CEST) Received: (qmail 2205 invoked by uid 65534); 15 Apr 2003 01:15:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 15 Apr 2003 03:15:27 +0200 Received: by moria.seul.org (Postfix) id 8E4CC33B68; Mon, 14 Apr 2003 21:15:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F095333B7D; Mon, 14 Apr 2003 21:15:24 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 147C433B68 for ; Mon, 14 Apr 2003 21:15:24 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-8.n.club-internet.fr [213.44.3.8]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 461511771 for ; Tue, 15 Apr 2003 03:15:20 +0200 (CEST) Message-ID: <3E9B5DB9.2050007@f-cpu.org> Date: Tue, 15 Apr 2003 03:17:45 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <20030411195122.17ff43c9.nico@seul.org> <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> <20030413184344.31654@thrai.stud.uni-hannover.de> <3E9A77EB.408@f-cpu.org> <20030414143950.27384@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi, Michael Riepe wrote: >On Mon, Apr 14, 2003 at 10:57:15AM +0200, Yann Guidon wrote: >[...] > > >>In the instruction flow pipeline, the Fetcher is at the first place : >>it is where instructions are fetched and buffered. When a line >>is first accessed, the Fetcher takes the address of the current line, >>increments it (upon overflow of the 12 LSB, it checks the TLB) >>and performs a read request to L1. The goal is to maintain >>a constantly prefetched instruction stream, and compensate for >>average memory latencies : with 8 instructions per line (256 bits), >>it gives 8 cycles to compute the next address, check if it is >>present in LSU, Fetcher and I-Cache, and fetch it. If absent, >>there are still a few clocks lefts for a fetch from L2. >> >> >The fetcher could increment the address as soon as it requests a cache >line (in parallel, just as a postincremented load would do). Maybe even >earlier if we use a `tandem register' (that is, double buffering). > > well, too much prefetch can overload the memory system and increase the real execution time. But of course, since the sources are "free", anybody can "play" with the Fetcher's strategy. >>So the "Fetcher" fetches instructions in advance, sequentially. >>Linear code will use a "double buffer" with 2 lines. >>If a jump occurs, a new set of lines is found through LRU, >>so a jump back (return ?) to the calling code is possible. >>There are usually 8 lines. >> >> >Which means that we can handle at least four different locations, >right? > > "at least", right : first, usually, only one stream is using double-buffering. The rest will be code that was the source of a jump (in which case, the double buffering will "die" progressively through LRU) or of a call (then, if too many calls are done, the Fetcher will "forget" the oldest parts of the virtual "call stack"). The LRU algorithm and the line selection will not be trivial algos but at least it implicitely implements a call stack. Heuristics must be found in order to select whether a return address must keep its "double", for example if the jump occurs after the 4th instruction, the cost of fetching the next line from L1 increases dramatically, so we can "forget" a prefetched line if the instruction pointer's bit #4 is cleared. This kind of trick can spare some lines and increase the number of real fetched locations to 6 instead of 8/2. At least : one pair is used for the current instruction flow and another is possibly incompressible. >>The Fetcher presents one instruction at each clock cycle >>to the pipeline, as well as its address (which is generated >>from the line's virtual address and the index of the instruction in >>the line, obtained from the counter). The next pipeline stages >>(decode / R7 read and issue/Xbar) give a "next instruction" >>bit to the fetcher, in order to advance the instruction counter >>and get the next instruction. So the fetcher selects a new word >>either in the current line or another one, and this is completely >>transparent to the rest of the pipeline (which just begs for >>a new instruction). Naturally, if there is a stall in the memory, >>it propagates to the pipeline through the Fetcher, but we count >>on its buffers and "intelligence" to reduce the stall's costs. >> >> >Yep. But I'd rather present the whole cache line to the decoder, and >let it send back a `next line' bit. > hmmm ... no. even a cache line is a buffer that must be carefully handled. and a decoder decodes, a fetcher fetches. At one point, there must be the "current instruction" that is being decoded : this is where there is the limit between "fetch" and "decode". If you provide several instructions for parallel decoding, it increases the decoding logic and the problems. Furthermore, in the classical computing world, only one instruction is "active" at a time. So i consider that it is present in one "pipeline register", it is updated by the "fetcher" upon request from the decode and issue stages. > Alternatively, the decoder could >use an `instruction window' that contains 2...4 (or more) instructions. >In case we ever want to do a kind of peephole optimization here (or issue >several instructions per cycle), we wouldn't have to change the fetcher. > > KISS, you know ? first, it's usually the compiler's job to optimise the code sequences, and it has opportunities to perform them on a much larger window than 2 to 4 instructions. Next, we have 64 registers and potentially 4 register addresses, how are you going to compare together 8 to 16 6-bit words together ? (theoretically, that's 8*7/2=38 to 16*15/2=120 comparators). the clock speed and/or the pipeline depth are going to suffer. >BTW: One possible optimization would be `loadcons clustering'. If there >are several loadcons[x] instructions in a row (with the same destination >register), the decoder might put the constants together and process all >the loads in a single cycle. > > naaah .... how are going going to deal with "clusters" that spread across a cache line boundary (or worse) through a page ? Next, you'll have to put comparators, that determine that the loadcons is sent to the same register. That's O(log2(8)), at least 3 logic depths for 8 instructions/line. Then, you'll have to make sure that the constants are in the correct order : no place for constant optimasations and "holes" in the constant, you have to provide contiguous indices. so that's reasons i'm able to find in my post-tiredness state, wait till i get some sleep if you want more :-) >>Next comes "Decode". it "explodes" the instruction word >>into all the subfields and checks for whatever conditions exists. >>This means : reading all registers in the 3 corresponding fields, >>checking whether their value is available in the next cycle, >>whether the pointer field corresponds to a valid pointer >>or an invalid pointer or nothing, check whether the condition >>is true, check whether the instruction is valid .... >> >>All those fields and flags are condensed into a few bits >>in the next cycle : "Issue/Xbar", where it is computed >>whether to fetch the next instruction, jump to the target, >>wait (stall) or trap. At the end of this cycle, if the instruction >>is valid and accepted, it "officially" enters the pipeline >>and the corresponding flags are updated in the scheduler's queue >>(depending on the latency determined by a table lookup >>during the decode cycle). >> >> > >Yep. > > > >>Answers to MR : >>* currently, i don't think that predecoding >>can bring any advantage (yet). It will be useful in later architectures >>but i see no case where it can bring any benefit. >> >> >The main idea was to simplify the decoder (lower latency), > waht complex instruction needs preprocessing ? >and to have some bits available in the fetcher that can be used for code flow analysis. > ??? >E.g. if there is an unconditional jump, the fetcher may skip >the `linear' prefetch cycle to save memory bandwidth (and a buffer); > hmmm ... there are many ways to code an unconditional jump, like a call without ever using return for example. Jump instructions are easy to find but they offer quite some freedom and even return can be conditional (since it uses the main "jump" form). You're going to put 8 complex comparators that will add 1 bit to the cache lines. It's probably interesting but i'm curious to know how many tens of percents of wallclock time it is going to save. >if there is a syscall instruction, it may prefetch code from the syscall >handler, and so on. > > syscall can have either an immediate form or a register form : prefetch will not be possible for the register form. >>* Loadaddri : the ASU can be used anyway, because the TLB is hooked >>to its output (on a "user-hidden port", kinda specific bypass). >>The TLB can get addresses from the Xbar ( a register or a unit bypass) >>or from the ASU (used by load/store with postincrement). >> >> >The TLB will also get addresses directly from the fetcher (for sequential >instruction prefetch), won't it? > i guess so ut i'm too tired to think about it... now there is another question : split or unified TLB ? >>One "optimisation" is to bypass the TLB when no carry occurs >>on the 12th bit but lookup in the LSU and/or Fetcher's buffer is >>always performed after that. >>It is better to reuse the ASU when there is a register operand, >>because it will benefit from the bypass on Xbar. >>A specific adder could be added to perform "fast/early" compute >>but it can be spared at the cost of more latency. Both solutions >>should be left to the user, in case there is a possible tradeoff >>for power consumption, speed and room. >>However, the Fetcher contains a pair of 'incrementers', >>one to increment the virtual address "tag" and another >>is a simple counter (from 0 to 7). maybe the large incrementer >>can be made into a normal adder that performs "loadaddri". >>This won't work for register-relative "loadaddr". >> >> >An adder for loadaddri won't fit into a single pipeline stage. > if there is a carry at the Xth position, it can stall the process in order to compute the MSB ? i think that it won't occur often (inversely proportionally to the memory size that can be accessed by the LSB of the computed pointer). >And there >is another problem with loadaddri: both operands come from the IF/D unit. > > With the immediate form, both operands (NIP [Next IP] and offset) come from the instruction which is presented by the Fetcher to the decoder, where all fields can be examined in parallel. These fields can be "looped back" to the Fetcher that can then compute the address with its internal incrementer/avalanche-adder. >We already have so many adders that one more or less doesn't really count. >EU_ASU has one 64-bit adder, EU_IMU has four 128-bit adders, EU_IDU has >one 64-bit adder (two if we're going to support `rem' and `divrem'), >and we'll need yet another adder to support `addsub'. Plus any adders >that will be required to implement the FPU (at least two or three). >Small adders (< 64 bits) not listed. > >We could make a version with shared adders (e.g. ASU/IMU/IDU might >share a single 128-bit adder), but its latency would probably be worse, >parallelism would be lost, and scheduling might become more difficult. >On the other hand, it would allow us to make a cheaper FC0 -- we >would save not only a significant portion of die area, but also ~10 >Xbar ports. I'll write such an `Integer Arithmetic Unit' (EU_IAU) >if you're interested. > Now that most interesting units are "ready", there is quite a lot of work to do in order to connect these units together and then schedule operations. And i don't know what has happened to the Register Set's sources. @+ YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 15 14:48:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 195Y6n-0006XJ-00 for ; Tue, 15 Apr 2003 23:36:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Apr 2003 23:36:53 +0200 (CEST) Received: (qmail 16563 invoked by uid 65534); 15 Apr 2003 17:14:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 15 Apr 2003 19:14:35 +0200 Received: by moria.seul.org (Postfix) id C204D33C95; Tue, 15 Apr 2003 13:14:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E0FAD33CD6; Tue, 15 Apr 2003 13:14:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a236.home.uni-hannover.de [130.75.232.236]) by moria.seul.org (Postfix) with ESMTP id 3E5B833C95 for ; Tue, 15 Apr 2003 13:14:29 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00668; Tue, 15 Apr 2003 14:48:27 +0200 Message-ID: <20030415144827.38572@thrai.stud.uni-hannover.de> Date: Tue, 15 Apr 2003 14:48:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] new cjump instruction References: <3E96F854.3040306@jetnet.ab.ca> <20030411210803.79b993dd.nico@seul.org> <3E9763AF.7020805@f-cpu.org> <20030412162248.70287daf.nico@seul.org> <3E986623.5000504@f-cpu.org> <20030413132105.23cb9d48.nico@seul.org> <20030413184344.31654@thrai.stud.uni-hannover.de> <3E9A77EB.408@f-cpu.org> <20030414143950.27384@thrai.stud.uni-hannover.de> <3E9B5DB9.2050007@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3E9B5DB9.2050007@f-cpu.org>; from Yann Guidon on Tue, Apr 15, 2003 at 03:17:45AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Apr 15, 2003 at 03:17:45AM +0200, Yann Guidon wrote: [...] > >The fetcher could increment the address as soon as it requests a cache > >line (in parallel, just as a postincremented load would do). Maybe even > >earlier if we use a `tandem register' (that is, double buffering). > > > > > well, too much prefetch can overload the memory system > and increase the real execution time. > But of course, since the sources are "free", anybody can "play" > with the Fetcher's strategy. How can one line be too much? [...] > >Yep. But I'd rather present the whole cache line to the decoder, and > >let it send back a `next line' bit. > > > hmmm ... no. > even a cache line is a buffer that must be carefully handled. > and a decoder decodes, a fetcher fetches. > At one point, there must be the "current instruction" that is being > decoded : > this is where there is the limit between "fetch" and "decode". Since there is no PC register, why should there be a current instruction? ;) IMHO, the fetcher ends at the line buffers. If a buffer is filled, the line is "fetched", and everything else is decoding. Whether instructions are decoded one by one or in parallel is not a fetcher but a decoder issue. > If you provide several instructions for parallel decoding, > it increases the decoding logic and the problems. > Furthermore, in the classical computing world, only one > instruction is "active" at a time. So i consider that it is present > in one "pipeline register", it is updated by the "fetcher" upon > request from the decode and issue stages. Let's not argue about words, please. In the end, IF/D is going to be a single unit anyway, not separate fetcher and decoder units, so it really doesn't matter *who* selects the active instruction. > > Alternatively, the decoder could > >use an `instruction window' that contains 2...4 (or more) instructions. > >In case we ever want to do a kind of peephole optimization here (or issue > >several instructions per cycle), we wouldn't have to change the fetcher. > > > > > KISS, you know ? For FC0, yes. But I'm also trying to look into the future sometimes. > first, it's usually the compiler's job to optimise the code sequences, and > it has opportunities to perform them on a much larger window than 2 to 4 > instructions. Jein. Yes, it's its job (and so on). But there are things a compiler can't do. > Next, we have 64 registers and potentially 4 register addresses, > how are you going to compare together 8 to 16 6-bit words together ? > (theoretically, that's 8*7/2=38 to 16*15/2=120 comparators). > the clock speed and/or the pipeline depth are going to suffer. I'm not sure that I have to. But I'll have to think about it. > >BTW: One possible optimization would be `loadcons clustering'. If there > >are several loadcons[x] instructions in a row (with the same destination > >register), the decoder might put the constants together and process all > >the loads in a single cycle. > > > > > naaah .... > > how are going going to deal with "clusters" that spread across a cache > line boundary > (or worse) through a page ? Not at all. > Next, you'll have to put comparators, that determine that the loadcons > is sent to the same > register. That's O(log2(8)), at least 3 logic depths for 8 > instructions/line. First, I'm going to check which instructions are loadcons[x]es at all. That's a 7-bit comparator with fixed second argument, depth=2. I'll also compare the destination registers of consecutive instructions (6 XOR gates and combining NOR gates, depth=2). Then I'll combine those bits with an AND (depth=3) and I have an indicator that these two consecutive instructions can be clustered. Of course this operation will benefit from the predecoding stage I mentioned earlier. > Then, you'll have to make sure that the constants are in the correct order : > no place for constant optimasations and "holes" in the constant, you have > to provide contiguous indices. The order doesn't matter. The `right' (later) instruction will have precedence over the `left' (earlier) one. That's a simple MUX operation for all but the first instruction in the cluster. > so that's reasons i'm able to find in my post-tiredness state, > wait till i get some sleep if you want more :-) Not necessary ;) But let's talk about this stuff again when IF/D ist implemented. BTW: Will you write it? [...] > >>* currently, i don't think that predecoding > >>can bring any advantage (yet). It will be useful in later architectures > >>but i see no case where it can bring any benefit. > >> > >> > >The main idea was to simplify the decoder (lower latency), > > > waht complex instruction needs preprocessing ? Probably all of them. I'm mainly concerned about the complexity of the decoder. [...] > >E.g. if there is an unconditional jump, the fetcher may skip > >the `linear' prefetch cycle to save memory bandwidth (and a buffer); > > > hmmm ... there are many ways to code an unconditional jump, > like a call without ever using return for example. That's something we can't detect, right. Since it will cause a useless prefetch, I consider it bad coding style ;) > Jump instructions are easy to find but they offer quite some freedom > and even return can be conditional (since it uses the main "jump" form). Conditional jumps are not a problem, since they should not turn prefetching off. > You're going to put 8 complex comparators that will add 1 bit to the > cache lines. > It's probably interesting but i'm curious to know how many tens of percents > of wallclock time it is going to save. We'll have to investigate that. But on the other hand, every single cycle counts :) > >if there is a syscall instruction, it may prefetch code from the syscall > >handler, and so on. > > > > > syscall can have either an immediate form or a register form : > prefetch will not be possible for the register form. In my versions of the manual, it's always been strictly immediate. [...] > now there is another question : split or unified TLB ? A split TLB would harmonize with the split L1 cache and the separate IF/D and L/S units, and would decouple code and data TLB lookups. But it's less space efficient (fixed limit of code and data TLB entries), and probably also harder to implement. That is, I'm not sure. [...] > >An adder for loadaddri won't fit into a single pipeline stage. > > if there is a carry at the Xth position, it can stall the process in > order to compute the MSB ? Please don't. Remember that the immediate value is sign-extended, and that the high part may go up or down. [...] > Now that most interesting units are "ready", there is quite a lot of > work to do in > order to connect these units together and then schedule operations. Yep. But there also are some things to improve. E.g. `widen' is still unimplemented (not a big issue), and the SHL unit doesn't scale in byte mode (in particular, `permute'/`sdup' will be a problem when the word size increases). And I think I have found a way to implement add/sub with signed saturation. > And i don't know what has happened to the Register Set's sources. Did you lose them? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From helpdesk@iso.vilspa.esa.es Tue Apr 15 22:25:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 195Y6z-0006XJ-01 for ; Tue, 15 Apr 2003 23:37:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 15 Apr 2003 23:37:05 +0200 (CEST) Received: (qmail 20831 invoked by uid 65534); 15 Apr 2003 20:26:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 15 Apr 2003 22:26:06 +0200 Received: by moria.seul.org (Postfix) id 25C4633B4C; Tue, 15 Apr 2003 16:26:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 246BF33B72; Tue, 15 Apr 2003 16:26:01 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100]) by moria.seul.org (Postfix) with ESMTP id 5BF2533B4C for ; Tue, 15 Apr 2003 16:25:59 -0400 (EDT) Received: from isous5.vilspa.esa.es (localhost [127.0.0.1]) by iso.vilspa.esa.es (8.12.9/8.12.9) with ESMTP id h3FKPvPg026216 for ; Tue, 15 Apr 2003 22:25:57 +0200 (MEST) Received: (from helpdesk@localhost) by isous5.vilspa.esa.es (8.12.9/8.12.9/Submit) id h3FKPv2a026213 for f-cpu@seul.org; Tue, 15 Apr 2003 22:25:57 +0200 (MEST) Date: Tue, 15 Apr 2003 22:25:57 +0200 (MEST) From: ISO Helpdesk Message-Id: <200304152025.h3FKPv2a026213@isous5.vilspa.esa.es> To: f-cpu@seul.org Subject: [f-cpu] '"A powful tool"' Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Thank you for your e-mail. We will process the e-mail as quickly as possible and give you a reply, if necessary. This e-mail is a confirmation of reception. Please use the reference number below for further related helpdesk queries. Yours sincerely, ISO Helpdesk ---------------------------------------------------------------------- The Infrared Space Observatory (ISO) is an European Space Agency (ESA) mission with the participation of ISAS (Japan) and NASA (USA). http://www.iso.vilspa.esa.es/ ---------------------------------------------------------------------- Subject: '"A powful tool"' Reference number: 35038 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hadija782@zWallet.com Thu Apr 17 22:46:43 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196HZC-0005vR-01 for ; Fri, 18 Apr 2003 00:09:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 18 Apr 2003 00:09:14 +0200 (CEST) Received: (qmail 28165 invoked by uid 65534); 17 Apr 2003 20:35:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 17 Apr 2003 22:35:46 +0200 Received: by moria.seul.org (Postfix) id 2F9D933B65; Thu, 17 Apr 2003 16:35:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4BFA633B87; Thu, 17 Apr 2003 16:35:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from helimore1779.com (unknown [192.116.98.173]) by moria.seul.org (Postfix) with SMTP id 6A9A633B65 for ; Thu, 17 Apr 2003 16:35:28 -0400 (EDT) From: "HADIJA ABACHA" To: f-cpu@seul.org Date: Thu, 17 Apr 2003 21:46:43 +0100 Subject: [f-cpu] URGENT HELP X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030417203528.6A9A633B65@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N MRS HADIJA ABACHA=2C Presidential Quarters=2C Government Reserve Area=2C Kano State Nigeria=2E 19=2F3=2F2003 >From - Mrs Hadija Abacha ATTN=3A Dear Sir=2C REQUEST FOR URGENT BUSINESS TRANSACTION =28HELP=29 It is with heart full hope I write to seek your help in the below=2E I Mrs=2E Hadija Abacha=2C the second wife of the former Nigeria Head of State=2C Late GENERAL SANNI ABACHA whose sudden death occurred on 8th of June=2C 1998=2E I had no doubt about your capacity and good will to assist me in receiving into your nominated bank account =28for safety=29 the sum of Us$ 30m willed in my favour by my late husband=2E This money is currently kept in a trusted account of one of the government parastal=2E As it is legally required=2C the administration of my late husband's property is under the authority of the family lawyers named =28DR=2E AMED ALI=29=2E However=2C the new Democr atic Government had on assumption of office=2C set up a panel of Enquiry to probe the financial activities of the former Head of State with a decision to freeze all his traceable bank account and other assets respectively=2E The investigation team had tempor arily submitted its report recently=2C and at moment few of the discovered assets and funds had been frozen and confiscated=2E Fortunately=2C the family lawyers had secretly protected the PERSONAL WILL of my husband from the notice of the investigators and have advised that the willed money be urgently transferred into Overseas Bank Account of a trusted foreign family friend=2C with out delay for security reasons=2E The government had earlier placed embargo on overseas travel on all Abacha family members=2C and seized all known local and international outfits of his business empire=2E The situation has been so terrible that we are virtual ly living on mercy of well-wishers=2E In view of the plight therefore=2C I expect you to be trustworthy and kind enough to respond to this distress call to save me and my children from a hopeless future=2E Further details will be discussed in the course of your acceptance to perform=2E Your benefits and entitlement will be discussed and agreed upon as we progress=2E The attorney will covert and seal the transaction to ensure no trace and legal consequences on you or ourselves=2E All contacts should be made through my lawyer DR=2E AMEDALI {SOLICITOR & ADVOCATE=29 via fax number 234-8033290965=2Ce-mail atakatachamers86=40justice=2Ecom=2E Finally=2C I beseech and implore you to treat my request very secret and urgent=2E Yours faithfully=2C MRS=2E HADIJA ABACHA=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hah@163.com Sat Apr 19 00:19:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196iEm-0000fq-00 for ; Sat, 19 Apr 2003 04:37:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 04:37:56 +0200 (CEST) Received: (qmail 16710 invoked by uid 65534); 18 Apr 2003 22:20:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 19 Apr 2003 00:20:08 +0200 Received: by moria.seul.org (Postfix) id D5D2733B8D; Fri, 18 Apr 2003 18:20:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1DFCC33B89; Fri, 18 Apr 2003 18:20:04 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 1631501.com (unknown [61.235.68.66]) by moria.seul.org (Postfix) with SMTP id 2FD7633B85; Fri, 18 Apr 2003 18:19:55 -0400 (EDT) From: yang Subject: [f-cpu] =?gb2312?q?_3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,(30000000_emailaddress_only_15$)?= Date: Sat, 19 Apr 2003 06:19:01 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="d519a186-534c-4495-9810-a9d3c9d782eb" Message-Id: <20030418221955.2FD7633B85@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --d519a186-534c-4495-9810-a9d3c9d782eb Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7=A2=C8=ED=BC=FE=D6=BB= =CA=DB150=D4=AA

3000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7=BC=D3=C8=BA=B7= =A2=C8=ED=BC=FE=D6=BB=CA=DB150=D4=AA,=CF=EA=C7=E9=C7=EB=B5=E7= 0755-26368636

EMAIL:  usa123668@yahoo.com.cn=D7=C9=D1= =AF

30000000 emailaddress for you = only 15$ ,,if you need please sent a mail to me ,my email: usa123668@yahoo.com.cn

=
2003=C4=EA=D7= =EE=D0=C2=B1=E0=BC=AD=B5=C43000=CD=F2=D3=CA=CF=E4=B5=D8=D6=B7,=B0=FC=C0=A8=D0= =D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6,=D0=D0=D2=B5=B0=E6=B7=D6=CE=AA:=B0=B2= =C8=AB=B7=C0=BB=A4=A1=A2=B0=EC=B9=AB=D3=C3=C6=B7=A1=A2=B5=E7=C4=D4=BC=B0=C8=ED= =BC=FE=A1=A2=B5=E7=D7=D3=B5=E7=B9=A4=A1=A2=B7=C4=D6=AF=B7=FE=D7=B0=A1=A2=C6=A4= =B8=EF=A1=A2=BB=AF=B9=A4=A1=A2=BB=B7=B1=A3=A1=A2=BB=FA=D0=B5=BC=B0=B9=A4=D2=B5= =D6=C6=C6=B7=A1=A2=BC=D2=BE=D3=D3=C3=C6=B7=A1=A2=BC=D2=D3=C3=B5=E7=C6=F7=A1=A2= =BD=A8=B2=C4=B7=BF=B5=D8=B2=FA=A1=A2=BD=BB=CD=A8=D4=CB=CA=E4=A1=A2=BF=E2=B4=E6= =BB=FD=D1=B9=A1=A2=C0=F1=C6=B7=B9=A4=D2=D5=C6=B7=A1=A2=C4=DC=D4=B4=A1=A2=C5=A9= =D2=B5=A1=A2=C9=CC=D2=B5=B7=FE=CE=F1=A1=A2=CA=B3=C6=B7=D2=FB=C6=B7=A1=A2=CD=A8= =D1=B6=B2=FA=C6=B7=A1=A2=CD=E6=BE=DF=A1=A2=D0=DD=CF=D0=D4=CB=B6=AF=A1=A2=D2=B1= =BD=F0=BF=F3=B2=FA=A1=A2=D2=BD=D2=A9=B1=A3=D1=F8=A1=A2=B0=FC=D7=B0=D3=A1=CB=A2= =B3=F6=B0=E6=B5=C8,=B5=D8=D3=F2=B0=E6=B0=B4=C8=AB=B9=FA=B8=F7=CA=A1,=B8=F7=CA= =D0=C7=F8=C0=B4=BB=AE=B7=D6=B2=A2=D3=D0=B2=BF=B7=D6=CA=C7=CD=E2=B9=FA=B5=C4= ,=B2=A2=CB=CD=C8=BA=B7=A2=C8=ED=BC=FE=D2=BB=CC=D7,=C8=ED=BC=FE=C3=BF=B7=D6=D6= =D3=BF=C9=B7=A23000-10000=B7=E2=D3=CA=BC=FE,=C8=E7=B9=FB=C4=E3=C8=B7=B6=A8=D0= =E8=D2=AA=C7=EB=CF=C8=CF=C2=D4=D8=D0=D0=D2=B5=B0=E6=BA=CD=B5=D8=D3=F2=B0=E6=BC= =D3=C3=DC=D1=B9=CB=F5=CE=C4=BC=FE,=C8=BB=BA=F3=BD=AB150=D4=AA=B4=E6=C8=EB=A3= =A8=D5=D0=C9=CC=D2=F8=D0=D0=D2=BB=BF=A8=CD=A8=D5=CA=BA=C5=A3=BA0755 59166592  =BB=A7=C3=FB=A3=BA=D1=EE=D3=C0=C7=BF=A3=A9=BA=F3=B8=F8=CE=D2=B7=A2=D3= =CA=BC=FE=A3=AC=BB=F2=B8=F8=CE=D2=B5=E7=BB=B0=A1=A3=CE=D2=BB=E1=BD=AB=C3=DC=C2= =EB=B8=E6=CB=DF=C4=E3.(=D0=D0=D2=B5= =B0=E6=CF=C2=D4=D8)(=B5=D8=D3= =F2=B0=E6=CF=C2=D4=D8)
=D7=A8=D2=B5=B6= =A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CE=D2=C3=C7=BB=E1=B8=F9=BE=DD=C4=E3=B5=C4= =D2=AA=C7=F3=CE=AA=C4=E3=B6=A8=D6=C6=D3=CA=CF=E4=B5=D8=D6=B7,=CA=D5=B7=D1:=C3= =BF30=CD=F2100=D4=AA
=C8=E7=B9=FB=C4=FA=B6=D4=CE=D2=C3= =C7=B5=C4=B7=FE=CE=F1=D3=D0=C8=CE=BA=CE=D2=E2=BC=FB=BB=F2=BD=A8=D2=E9=A3=AC=C7= =EB=BB=DD=B4=CDE-mail=D6=C1:usa123668@yahoo.com.cn
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=BA=CD=C6=BD=C2=B7118=BA=C55=B6=B0504
=BF=CD=BB=A7=B7=FE=CE=F1=B5=E7=BB=B0=A3=BA=A3=A886-0755-26368636) =
OICQ:76576669
--d519a186-534c-4495-9810-a9d3c9d782eb-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Apr 18 19:55:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196iEo-0000fq-01 for ; Sat, 19 Apr 2003 04:37:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 04:37:58 +0200 (CEST) Received: (qmail 24544 invoked by uid 65534); 18 Apr 2003 22:54:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Apr 2003 00:54:00 +0200 Received: by moria.seul.org (Postfix) id 2A0CC33B59; Fri, 18 Apr 2003 18:53:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 29D8F33B89; Fri, 18 Apr 2003 18:53:56 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a085.home.uni-hannover.de [130.75.232.85]) by moria.seul.org (Postfix) with ESMTP id 55EE733B59 for ; Fri, 18 Apr 2003 18:53:54 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01803; Fri, 18 Apr 2003 19:55:09 +0200 Message-ID: <20030418195509.14358@thrai.stud.uni-hannover.de> Date: Fri, 18 Apr 2003 19:55:09 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Yet Another Upload Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N I'm going to upload fcpu-mr-20030418.tar.gz to http://f-cpu.seul.org/~f-cpu/new/ tonight. Highlights: * EU_AFU is included. * EU_ASU now supports twenty-four (24) operations, not counting SIMD, chunk sizes or immediate instructions: add a + b modulo 2**n addc a + b with carry-out avg (a + b) / 2 unsigned avgs (a + b) / 2 signed addus saturate(a + b) unsigned addss saturate(a + b) signed add1 a + b + 1 modulo 2**n addc1 a + b + 1 with carry-out avg1 (a + b + 1) / 2 unsigned avgs1 (a + b + 1) / 2 signed addus1 saturate(a + b + 1) unsigned addss1 saturate(a + b + 1) signed sub a - b modulo 2**n subb a - b with borrow-out diff (a - b) / 2 unsigned diffs (a - b) / 2 signed subus saturate(a - b) unsigned subss saturate(a - b) signed sub1 a - b - 1 modulo 2**n subb1 a - b - 1 with borrow-out diff1 (a - b - 1) / 2 unsigned diffs1 (a - b - 1) / 2 signed subus1 saturate(a - b - 1) unsigned subss1 saturate(a - b - 1) signed Carry and borrow outputs use the numeric values 0 and 1. I'm currently considering additional `widening' addw/subw instructions that will provide a `correct' value in the upper half, as if the operands had been sign-extended and added/subtracted in a wider mode. * EU_SHL will now scale up to 2048 bits, and I finally implemented the widen instruction. Shift, rotate, bitrev, byterev and widen operate on individual chunks while other bytewise instructions (mix, expand, permute, sdup and cshift) may transfer data from one chunk to another. Word width is limited to 2048 bits because permute/sdup can only address up to 256 8-bit chunks internally. Other operations will work with wider words, too. * package Generic_Adder now includes the new carry-select adder I'm using everywhere. The carry-increment adder should not be used any longer. As usual, packages and units have been tested with the included testbenches. Synthesis reports welcome. BTW: You may also try to synthesize 128-bit or 256-bit versions of individual units (except IMul64 which doesn't auto-scale yet). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Apr 19 07:07:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196vj7-00020B-00 for ; Sat, 19 Apr 2003 19:02:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 19:02:09 +0200 (CEST) Received: (qmail 6537 invoked by uid 65534); 19 Apr 2003 05:05:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 19 Apr 2003 07:05:01 +0200 Received: by moria.seul.org (Postfix) id 74D0533C6D; Sat, 19 Apr 2003 01:04:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2471F33C69; Sat, 19 Apr 2003 01:04:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 4C40A33B89 for ; Sat, 19 Apr 2003 01:04:57 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-6.n.club-internet.fr [213.44.3.6]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 5366B1682 for ; Sat, 19 Apr 2003 07:04:51 +0200 (CEST) Message-ID: <3EA0D985.3080801@f-cpu.org> Date: Sat, 19 Apr 2003 07:07:17 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >I'm going to upload fcpu-mr-20030418.tar.gz to >http://f-cpu.seul.org/~f-cpu/new/ tonight. > >Highlights: > > * EU_AFU is included. > > hmmm i better look at it :-) > * EU_ASU now supports twenty-four (24) operations, not counting > SIMD, chunk sizes or immediate instructions: > > add a + b modulo 2**n > addc a + b with carry-out > avg (a + b) / 2 unsigned > avgs (a + b) / 2 signed > addus saturate(a + b) unsigned > addss saturate(a + b) signed > > add1 a + b + 1 modulo 2**n > addc1 a + b + 1 with carry-out > avg1 (a + b + 1) / 2 unsigned > avgs1 (a + b + 1) / 2 signed > addus1 saturate(a + b + 1) unsigned > addss1 saturate(a + b + 1) signed > > sub a - b modulo 2**n > subb a - b with borrow-out > diff (a - b) / 2 unsigned > diffs (a - b) / 2 signed > subus saturate(a - b) unsigned > subss saturate(a - b) signed > > sub1 a - b - 1 modulo 2**n > subb1 a - b - 1 with borrow-out > diff1 (a - b - 1) / 2 unsigned > diffs1 (a - b - 1) / 2 signed > subus1 saturate(a - b - 1) unsigned > subss1 saturate(a - b - 1) signed > > it is getting really impressing ! > Carry and borrow outputs use the numeric values 0 and 1. > I'm currently considering additional `widening' addw/subw > instructions that will provide a `correct' value in the > upper half, as if the operands had been sign-extended and > added/subtracted in a wider mode. > > * EU_SHL will now scale up to 2048 bits, and I finally implemented > the widen instruction. Shift, rotate, bitrev, byterev and widen > operate on individual chunks while other bytewise instructions > (mix, expand, permute, sdup and cshift) may transfer data from > one chunk to another. Word width is limited to 2048 bits because > permute/sdup can only address up to 256 8-bit chunks internally. > Other operations will work with wider words, too. > > * package Generic_Adder now includes the new carry-select adder > I'm using everywhere. The carry-increment adder should not > be used any longer. > >As usual, packages and units have been tested with the included >testbenches. > > cool. i should however reinstall NCSIM but i am very very busy now and in the following months. >Synthesis reports welcome. BTW: You may also try to synthesize 128-bit >or 256-bit versions of individual units (except IMul64 which doesn't >auto-scale yet). > > I am more worried about the correct work of the general scripts and what they can do now. Tests must also be redone regularly to check that all the sources work correctly with all the known tools. If someone wants to do a regression server ..... I seem to remember that a lot of important things were missing in the main script. But keeping it up to date made me forget what was missing .... Hmmmm now that Michael has added yet more functions, the C version of the unit must be rewritten : cool ! .... YG (way behind) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 19 11:16:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196vjD-00020B-00 for ; Sat, 19 Apr 2003 19:02:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 19:02:15 +0200 (CEST) Received: (qmail 10344 invoked by uid 65534); 19 Apr 2003 09:16:30 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 19 Apr 2003 11:16:30 +0200 Received: by moria.seul.org (Postfix) id CD5B533C69; Sat, 19 Apr 2003 05:16:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ECD5233C57; Sat, 19 Apr 2003 05:16:26 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 06BB933B89 for ; Sat, 19 Apr 2003 05:16:26 -0400 (EDT) Received: from homeworld (81.48.95.29) by mx.laposte.net (6.0.053) id 3E97480E0014AC2D for f-cpu@seul.org; Sat, 19 Apr 2003 11:16:25 +0200 Message-ID: <005801c30654$685709e0$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> Subject: [f-cpu] Scc (SIMD C compiler) Date: Sat, 19 Apr 2003 11:16:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Do you know this link http://www.ece.purdue.edu/~hankd/SWAR/Scc.html ? I think it could be any interest for you to add SIMD functionnality more easily on your C-based source. ----- Original Message ----- From: "Yann Guidon" To: Sent: Saturday, April 19, 2003 7:07 AM Subject: Re: [f-cpu] Yet Another Upload > hi ! > > Michael Riepe wrote: > > >I'm going to upload fcpu-mr-20030418.tar.gz to > >http://f-cpu.seul.org/~f-cpu/new/ tonight. > > > >Highlights: > > > > * EU_AFU is included. > > > > > hmmm i better look at it :-) > > > * EU_ASU now supports twenty-four (24) operations, not counting > > SIMD, chunk sizes or immediate instructions: > > > > add a + b modulo 2**n > > addc a + b with carry-out > > avg (a + b) / 2 unsigned > > avgs (a + b) / 2 signed > > addus saturate(a + b) unsigned > > addss saturate(a + b) signed > > > > add1 a + b + 1 modulo 2**n > > addc1 a + b + 1 with carry-out > > avg1 (a + b + 1) / 2 unsigned > > avgs1 (a + b + 1) / 2 signed > > addus1 saturate(a + b + 1) unsigned > > addss1 saturate(a + b + 1) signed > > > > sub a - b modulo 2**n > > subb a - b with borrow-out > > diff (a - b) / 2 unsigned > > diffs (a - b) / 2 signed > > subus saturate(a - b) unsigned > > subss saturate(a - b) signed > > > > sub1 a - b - 1 modulo 2**n > > subb1 a - b - 1 with borrow-out > > diff1 (a - b - 1) / 2 unsigned > > diffs1 (a - b - 1) / 2 signed > > subus1 saturate(a - b - 1) unsigned > > subss1 saturate(a - b - 1) signed > > > > > it is getting really impressing ! > > > Carry and borrow outputs use the numeric values 0 and 1. > > I'm currently considering additional `widening' addw/subw > > instructions that will provide a `correct' value in the > > upper half, as if the operands had been sign-extended and > > added/subtracted in a wider mode. > > > > * EU_SHL will now scale up to 2048 bits, and I finally implemented > > the widen instruction. Shift, rotate, bitrev, byterev and widen > > operate on individual chunks while other bytewise instructions > > (mix, expand, permute, sdup and cshift) may transfer data from > > one chunk to another. Word width is limited to 2048 bits because > > permute/sdup can only address up to 256 8-bit chunks internally. > > Other operations will work with wider words, too. > > > > * package Generic_Adder now includes the new carry-select adder > > I'm using everywhere. The carry-increment adder should not > > be used any longer. > > > >As usual, packages and units have been tested with the included > >testbenches. > > > > > cool. > > i should however reinstall NCSIM but i am very very busy now and in the > following months. > > >Synthesis reports welcome. BTW: You may also try to synthesize 128-bit > >or 256-bit versions of individual units (except IMul64 which doesn't > >auto-scale yet). > > > > > I am more worried about the correct work of the general scripts and what > they can do now. > Tests must also be redone regularly to check that all the sources work > correctly with all the known tools. If someone wants to do a regression > server ..... > I seem to remember that a lot of important things were missing in the > main script. > But keeping it up to date made me forget what was missing .... > > Hmmmm now that Michael has added yet more functions, the C version of > the unit > must be rewritten : cool ! .... > > YG (way behind) > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Sat Apr 19 14:39:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196vjN-00020B-00 for ; Sat, 19 Apr 2003 19:02:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 19:02:25 +0200 (CEST) Received: (qmail 13133 invoked by uid 65534); 19 Apr 2003 12:39:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 19 Apr 2003 14:39:33 +0200 Received: by moria.seul.org (Postfix) id C14BF33C0C; Sat, 19 Apr 2003 08:39:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9CE7733C57; Sat, 19 Apr 2003 08:39:31 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id E5E7233C0C for ; Sat, 19 Apr 2003 08:39:30 -0400 (EDT) Received: from homeworld (81.48.95.29) by mx.laposte.net (6.0.053) id 3E9750F30014F199 for f-cpu@seul.org; Sat, 19 Apr 2003 14:39:30 +0200 Message-ID: <005c01c30670$c7470510$8000a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> Subject: [f-cpu] SWARC (SIMD C compiler) Date: Sat, 19 Apr 2003 14:39:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Here's another : http://shay.ecn.purdue.edu/~swar/. Source can be found at : http://min.ecn.purdue.edu/~rfisher/Research/Scc/Scc.html. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From go-drug-go@zero.ad.jp Sat Apr 19 16:45:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 196vje-00020B-00 for ; Sat, 19 Apr 2003 19:02:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 19 Apr 2003 19:02:42 +0200 (CEST) Received: (qmail 28341 invoked by uid 65534); 19 Apr 2003 14:45:30 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 19 Apr 2003 16:45:30 +0200 Received: by moria.seul.org (Postfix) id 2599933C22; Sat, 19 Apr 2003 10:45:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76D7833C27; Sat, 19 Apr 2003 10:45:27 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 79.45.26.19 (f-tokyo-134254.zero.ad.jp [211.130.134.254]) by moria.seul.org (Postfix) with SMTP id 15CE833C22 for ; Sat, 19 Apr 2003 10:45:21 -0400 (EDT) From: =?iso-2022-jp?q?=83W=83=85=83=93=83g=83=8D=96=A7=94=84_ , ?=@seul.org To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81y=83W=83=85=83=93=83g=83=8D=96=A7=94=84=81z=82=BB=82=EA=90=C0=82=AF=83A=83=93=83p=83=93=82=C5=81I?= Date: Sat, 19 Apr 2003 23:45:40 +0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="8b7b8db3-2d63-4eec-b32d-7ecfd8bac683" Message-Id: <20030419144521.15CE833C22@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --8b7b8db3-2d63-4eec-b32d-7ecfd8bac683 Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable

=94z=90M=92=E2=8E~=82=CD=82=B1=82=CC=82=DC=82=DC=95=D4=90M=82=B5=82=C4=82= =AD=82=BE=82=B3=82=A2

*********************************************
=8E=BF=82=CC=82=A2=82=A2=8F=83=83g=83=8D=81i=82=A0=82=F1=82=CF=82=F1=81j=94=84= =82=C1=82=C4=82=DC=82=B7=81B
=83z=81[=83=80=83Z=83=93=83^=81[=82=C5=8A=C8=92P=82=C9=8E=E8=82=C9=93=FC=82=E9= =83=82=83m=82=C6=82=CD=88=E1=82=A2=82=DC=82=B7=81B
=83v=83=8C=83[=83=93=83g=82=C9=82=E0=8D=C5=93K
=81i=92=B4=8BC=8E=9D=82=BF=83C=83C=82=CC=82=C5=8E=E8=82=CC=E1=83=82=EA=82=C8= =82=C7=82=AA=8C=BB=82=EA=82=BD=82=E7=8Eg=97p=82=F0=92=86=8E~=82=B5=82=C4=82=AD= =82=BE=82=B3=82=A2=81j
=8F=AC=95=AA=82=AF=82=C9=82=B5=82=C4=94=84=82=E7=82=C8=82=A2=82=CC=82=C5=8D=A1= =89=F1=8C=C0=82=E8=82=CC=8C=83=88=C0=89=BF=8Ai=82=C5=82=B7=81B
=8Es=8F=EA=89=BF=8Ai150ml2000=89~=82=CC=8D=C5=8D=82=8B=89=95i

=81y=89=BF=8Ai=81z=81@500ml =83y=83b=83g=83{=83g=83=8B=93=FC=82=E8
=81=9C1=96{=81@=81F=81@4,000=89~
=81=9C2=96{=81@=81F=81@7,000=89~
=81=9C3=96{=81@=81F 10,000=89~=81@
=81=9C5=96{=81@=81F 12,000=89~
**********************************************
<<=96=A2=8Eg=97p=82=C8=82=E77=93=FA=88=C8=93=E0=95=D4=95i=89=C2=81I>>
=81y=8Dw=93=FC=95=FB=96@=81z
=81=9C=8F=A4=95i=82=CD=81A=8F=A4=95i=96=BC=81u=8C=92=8DN=90H=95i=81v=82=C5=91= =EE=94z=95=D6=82=CC=81u=91=E3=88=F8=82=AB=81v=82=C5=91=97=82=E8=82=DC=82=B7=81= B
=95i=95=A8=82=AA=93=CD=82=A2=82=BD=8E=9E=82=C9=82=A8=8B=E0=82=F0=8Ex=95=A5=82= =A4=82=CC=82=C5=8D=BC=8B\=82=C8=82=C7=82=CC=90S=94z=82=CD=82=A0=82=E8=82=DC=82= =B9=82=F1=81B
=91=97=97=BF=82=CD=95=CA=93r=91=EE=94z=97=BF=8B=E0=8E=C0=94=EF=82=A2=82=BD=82= =BE=82=AB=82=DC=82=B7=81B=82=BB=82=EA=82=C5=82=E0=92=B4=8C=83=88=C0=82=C5=82= =B7=81B

=81y=8Dw=93=FC=97p=82=CD=82=B1=82=BF=82=E7=82=A9=82=E7=81z
=8A=F3=96]=96{=90=94=81F=96= {
=82=A8=96=BC=91O=81F
=93d=98b=94=D4=8D=86=81F
=97X=95=D6=94=D4=8D=86=81F
=8FZ=8F=8A=81F

=81=A6=95K=82=B8=83C=83=93=83^=81[=83l=83b=83g=82=C9=90=DA=91=B1=82=B5=82=BD= =8F=F3=91=D4=82=C5=91=97=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81B
=81=A6=8F=A4=95i=82=F0=94=84=82=C1=82=BD=8F=D8=8B=92=82=F0=8F=C1=82=B7=82=BD= =82=DF=94=AD=91=97=8C=E3=82=CD=82=A8=8Bq=97l=82=CC=8F=EE=95=F1=82=F0=82=B7=82= =D7=82=C4=8D=ED=8F=9C=82=B5=82=DC=82=B7=82=CC=82=C5=82=B2=88=C0=90S=89=BA=82= =B3=82=A2=81B

=82=A4=82=DC=82=AD=91=97=82=EA=82=C8=82=A2=8E=9E=82=CD=81A=83=81=81[=83=8B= =82=C9
=81u=8Dw=93=FC=96{=90=94=81v=81u=82=A8=96=BC=91O=81v=81u=93d=98b=94=D4=8D=86= =81v=81u=97X=95=D6=94=D4=8D=86=81v=81u=8FZ=8F=8A=81v
=82=F0=8BL=93=FC=82=B5=82=C4=91=97=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81= B
=83=81=81[=83=8B=83A=83h=83=8C=83X=81Fjuntoro@tokyo24.com

--8b7b8db3-2d63-4eec-b32d-7ecfd8bac683-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Apr 19 14:45:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1975LI-0000uq-00 for ; Sun, 20 Apr 2003 05:18:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 20 Apr 2003 05:18:12 +0200 (CEST) Received: (qmail 13175 invoked by uid 65534); 19 Apr 2003 23:36:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 20 Apr 2003 01:36:41 +0200 Received: by moria.seul.org (Postfix) id A722333B5E; Sat, 19 Apr 2003 19:36:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F56233B56; Sat, 19 Apr 2003 19:36:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a214.home.uni-hannover.de [130.75.232.214]) by moria.seul.org (Postfix) with ESMTP id A858B33B48 for ; Sat, 19 Apr 2003 19:36:35 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00566; Sat, 19 Apr 2003 14:45:30 +0200 Message-ID: <20030419144530.02208@thrai.stud.uni-hannover.de> Date: Sat, 19 Apr 2003 14:45:30 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EA0D985.3080801@f-cpu.org>; from Yann Guidon on Sat, Apr 19, 2003 at 07:07:17AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sat, Apr 19, 2003 at 07:07:17AM +0200, Yann Guidon wrote: [...] > >Synthesis reports welcome. BTW: You may also try to synthesize 128-bit > >or 256-bit versions of individual units (except IMul64 which doesn't > >auto-scale yet). > > > > > I am more worried about the correct work of the general scripts and what > they can do now. Which scripts do you mean? > Tests must also be redone regularly to check that all the sources work > correctly with all the known tools. If someone wants to do a regression > server ..... I usually test everything with Simili (the old NT version) before I release it. I could also run vanilla, but it's soooo sloooooow... Tests with other tools (and reports if something fails) are always welcome, but are only required after major releases like this one. Remember that running all testbenches takes a while. > I seem to remember that a lot of important things were missing in the > main script. > But keeping it up to date made me forget what was missing .... > > Hmmmm now that Michael has added yet more functions, the C version of > the unit > must be rewritten : cool ! .... There is a C version? We better do things step by step. First, we'll have to decide which instructions we're going to use in FC0, and which of them will be mandatory for later versions (this applies to all units, not only the adder). Second, all instructions should be properly documented in the manual. Third, I'll have to update the assembler and the emulator. Finally, someone can update the machine description for gcc. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Apr 20 02:30:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1975LK-0000uq-00 for ; Sun, 20 Apr 2003 05:18:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 20 Apr 2003 05:18:14 +0200 (CEST) Received: (qmail 14731 invoked by uid 65534); 20 Apr 2003 00:27:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 20 Apr 2003 02:27:54 +0200 Received: by moria.seul.org (Postfix) id D7EC133B48; Sat, 19 Apr 2003 20:27:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F25B533B56; Sat, 19 Apr 2003 20:27:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 09D0833B48 for ; Sat, 19 Apr 2003 20:27:49 -0400 (EDT) Received: from f-cpu.org (lcbv3-1-27.n.club-internet.fr [213.44.91.27]) by relay-5m.club-internet.fr (Postfix) with ESMTP id CAF5FE0A6 for ; Sun, 20 Apr 2003 02:27:47 +0200 (CEST) Message-ID: <3EA1EA1C.6020805@f-cpu.org> Date: Sun, 20 Apr 2003 02:30:20 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> <20030419144530.02208@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Sat, Apr 19, 2003 at 07:07:17AM +0200, Yann Guidon wrote: >[...] > > >>>Synthesis reports welcome. BTW: You may also try to synthesize 128-bit >>>or 256-bit versions of individual units (except IMul64 which doesn't >>>auto-scale yet). >>> >>I am more worried about the correct work of the general scripts and what >>they can do now. >> >> >Which scripts do you mean? > > the ones that builds all the files from m4, verify the available tools, build the units and run their tests.... >>Tests must also be redone regularly to check that all the sources work >>correctly with all the known tools. If someone wants to do a regression >>server ..... >> >> >I usually test everything with Simili (the old NT version) before I >release it. I could also run vanilla, but it's soooo sloooooow... > :-) yup but you could try to do this at least once, one night or week, just to be sure .... >Tests with other tools (and reports if something fails) are always >welcome, but are only required after major releases like this one. >Remember that running all testbenches takes a while. > > yup. but you know that Riviera and NCSIM are one order of magnitude faste, right ? >>I seem to remember that a lot of important things were missing in the main script. >>But keeping it up to date made me forget what was missing .... >> >>Hmmmm now that Michael has added yet more functions, the C version of >>the unit must be rewritten : cool ! .... >> >> >There is a C version? > > i have at least made a C version for ROP2 ... the rest is fading in my memory. >We better do things step by step. First, we'll have to decide which >instructions we're going to use in FC0, > well, the units are here, so let's simply use them to their fullest. >and which of them will be >mandatory for later versions (this applies to all units, not only >the adder). > hmmm that's another problem.... >Second, all instructions should be properly documented in >the manual. > ouch :-) >Third, I'll have to update the assembler and the emulator. >Finally, someone can update the machine description for gcc. > As you probably know, i have returned back to plain old electronics to get some pocket money from time to time. Now, i have almost all tools to make decent PCBs in small series at decent prices. When the first FC0s will come out of fundry, we'll be able to use nice development kits :-) But there is still too much work to be done on the SW side; so we'll have to "wait a bit" ... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Apr 20 15:06:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197Sr0-0001eV-00 for ; Mon, 21 Apr 2003 06:24:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 06:24:30 +0200 (CEST) Received: (qmail 15983 invoked by uid 65534); 20 Apr 2003 23:59:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Apr 2003 01:59:12 +0200 Received: by moria.seul.org (Postfix) id 734BC33B4D; Sun, 20 Apr 2003 19:59:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2165833B5B; Sun, 20 Apr 2003 19:59:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a158.home.uni-hannover.de [130.75.232.158]) by moria.seul.org (Postfix) with ESMTP id 67AA433B4D for ; Sun, 20 Apr 2003 19:59:06 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA00675; Sun, 20 Apr 2003 15:06:22 +0200 Message-ID: <20030420150622.61844@thrai.stud.uni-hannover.de> Date: Sun, 20 Apr 2003 15:06:22 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> <20030419144530.02208@thrai.stud.uni-hannover.de> <3EA1EA1C.6020805@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EA1EA1C.6020805@f-cpu.org>; from Yann Guidon on Sun, Apr 20, 2003 at 02:30:20AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Sun, Apr 20, 2003 at 02:30:20AM +0200, Yann Guidon wrote: [...] > >>I am more worried about the correct work of the general scripts and what > >>they can do now. > >> > >> > >Which scripts do you mean? > > > > > the ones that builds all the files from m4, verify the available tools, > build the units and run their tests.... Oh, you mean the scripts I don't use ;) I'd really like to get rid of m4. In particular, I don't like the fact that we have to run m4 every time we modify the configuration. I prefer to change the VHDL sources directly. C headers can be generated from VHDL -- all we need is a procedure that takes all the definitions and prints them in C format. Since VHDL has text i/o capabilities, that shouldn't be too hard to do. (Note that it would also work the other way round -- edit C and generate VHDL -- but since VHDL is our primary source, I prefer to generate the C stuff.) Of course we must distribute pre-built C headers, in case someone has no VHDL tools and wants to install only the software. But that's not a problem either. For the build system, a mix of Makefiles and supporting shell scripts is probably the best choice. In the end, I want to be able to just unpack the files, type `configure' and `make', and let the automated build system deal with the boring details. [vanilla tests] > yup but you could try to do this at least once, one night or week, > just to be sure .... I'm currently doing that, but it's too slow to be done on a regular basis (unless you have a server that runs 24/7). [...] > but you know that Riviera and NCSIM are one order of magnitude faste, > right ? But I don't have them, and I probably never will. [...] > >We better do things step by step. First, we'll have to decide which > >instructions we're going to use in FC0, > > > well, the units are here, so let's simply use them to their fullest. That's what I wanted to hear :) > >and which of them will be > >mandatory for later versions (this applies to all units, not only > >the adder). > > > hmmm that's another problem.... > > >Second, all instructions should be properly documented in > >the manual. > > > ouch :-) Well, it must be done, whether we like it or not. VHDL code, manual and emulators are badly desynced. I'll take care of the emulators, and I think it would be wise to review the manual pages as well -- at least those corresponding to the EUs I wrote myself. I just need a copy of the current sources. > >Third, I'll have to update the assembler and the emulator. > >Finally, someone can update the machine description for gcc. > > > As you probably know, i have returned back to plain old electronics to get > some pocket money from time to time. Now, i have almost all tools to make > decent PCBs in small series at decent prices. When the first FC0s will > come out > of fundry, we'll be able to use nice development kits :-) Will they run Linux? ;) > But there is still too much work to be done on the SW side; so we'll > have to "wait a bit" ... Hmm... we have a gcc port, an assembler, a linker and two emulators. That's all SW people need in the first place. I'm currently concentrating on the HW side again -- since many people can do SW development but only few seem to be able to write VHDL code, I won't waste my time doing software development (of course I'll maintain my software, but VHDL has higher priority now). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 21 04:18:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197Sr3-0001eV-01 for ; Mon, 21 Apr 2003 06:24:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 06:24:33 +0200 (CEST) Received: (qmail 25875 invoked by uid 65534); 21 Apr 2003 02:16:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 21 Apr 2003 04:16:06 +0200 Received: by moria.seul.org (Postfix) id 4295E33B4B; Sun, 20 Apr 2003 22:16:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0B5CD33B5B; Sun, 20 Apr 2003 22:16:02 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 2757033B4B for ; Sun, 20 Apr 2003 22:16:01 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-6.n.club-internet.fr [213.44.18.6]) by relay-5m.club-internet.fr (Postfix) with ESMTP id 74700E12E for ; Mon, 21 Apr 2003 04:15:58 +0200 (CEST) Message-ID: <3EA354F8.8070608@f-cpu.org> Date: Mon, 21 Apr 2003 04:18:32 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> <20030419144530.02208@thrai.stud.uni-hannover.de> <3EA1EA1C.6020805@f-cpu.org> <20030420150622.61844@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >On Sun, Apr 20, 2003 at 02:30:20AM +0200, Yann Guidon wrote: >[...] > > >>>>I am more worried about the correct work of the general scripts and what >>>>they can do now. >>>> >>>Which scripts do you mean? >>> >>the ones that builds all the files from m4, verify the available tools, >>build the units and run their tests.... >> >> >Oh, you mean the scripts I don't use ;) > > grrrrrr !!! :-) >I'd really like to get rid of m4. > huh, really ? i find this very handy, though .... >In particular, I don't like the fact >that we have to run m4 every time we modify the configuration. > how often do you change the configuration ? >I prefer to change the VHDL sources directly. C headers can be generated from >VHDL -- all we need is a procedure that takes all the definitions and >prints them in C format. Since VHDL has text i/o capabilities, that >shouldn't be too hard to do. (Note that it would also work the other >way round -- edit C and generate VHDL -- but since VHDL is our primary >source, I prefer to generate the C stuff.) Of course we must distribute >pre-built C headers, in case someone has no VHDL tools and wants to >install only the software. But that's not a problem either. > > i'm not very happy with this solution : it will obfuscate the sources too much !!! First, not everybody will want to use it because it uses VHDL, and "SW people" who simply want to run an emulator won't want to fiddle with it. Second, with the M4 solution, the files are available in source form, very similar to the target form. Using VHDL to generate the files will make the original form very very oscure, full of write ("blahblagblah", somevariable, "blablah"); so i think that m4 is not a bad trade-off. Of course, if you find a better solution, i'd be interested to see it :-) like, huh, you want to reimplement m4 with VHDL ? :-P >For the build system, a mix of Makefiles and supporting shell scripts >is probably the best choice. In the end, I want to be able to just >unpack the files, type `configure' and `make', and let the automated >build system deal with the boring details. > > that's my goal, the reason why i have undertaken such a work. A newbie is normally afraid by the quantity of files with their curious organisation and formats, so my scripts help to guide him through the whole thing and shows how they work. >[vanilla tests] > > >>yup but you could try to do this at least once, one night or week, >>just to be sure .... >> >> >I'm currently doing that, but it's too slow to be done on a regular >basis (unless you have a server that runs 24/7). > > i didn't say regurarly, but from time to time, just to be sure that everything is still alright .... >[...] > > >>but you know that Riviera and NCSIM are one order of magnitude faster, right ? >> >> >But I don't have them, and I probably never will. > > hmmm .... and what about GHDL ? :-) "it's free, too" :-P >[...] > > >>>We better do things step by step. First, we'll have to decide which >>>instructions we're going to use in FC0, >>> >>well, the units are here, so let's simply use them to their fullest. >> >> >That's what I wanted to hear :) > > what else did you expect ? :-P >>>and which of them will be >>>mandatory for later versions (this applies to all units, not only >>>the adder). >>> >>hmmm that's another problem.... >> >> >> >>>Second, all instructions should be properly documented in >>>the manual. >>> >>ouch :-) >> >> >Well, it must be done, whether we like it or not. > i know .... >VHDL code, manual and emulators are badly desynced. > obviously. maybe because different persons do different things, right ? >I'll take care of the emulators, >and I think it would be wise to review the manual pages as well -- >at least those corresponding to the EUs I wrote myself. I just need a >copy of the current sources. > > i believe the latest versions are available easily from Cédric's site. >>>Third, I'll have to update the assembler and the emulator. >>>Finally, someone can update the machine description for gcc. >>> >>As you probably know, i have returned back to plain old electronics to get >>some pocket money from time to time. Now, i have almost all tools to make >>decent PCBs in small series at decent prices. When the first FC0s will >>come out of fundry, we'll be able to use nice development kits :-) >> >> >Will they run Linux? ;) > > except slashdotters, who really cares ? :-P frankly, i have recently started to master certain techniques and electronic technologies, so if we ever get to the fundry, the outcome will be really interesting and the PCBs will have interesting features... >>But there is still too much work to be done on the SW side; so we'll >>have to "wait a bit" ... >> >> >Hmm... we have a gcc port, an assembler, a linker and two emulators. > do they all work together ? are they all correctly updated and maintained ? are they easy to install and use ?.... >That's all SW people need in the first place. I'm currently concentrating >on the HW side again -- since many people can do SW development but >only few seem to be able to write VHDL code, I won't waste my time doing >software development (of course I'll maintain my software, but VHDL has >higher priority now). > i'll maybe come back to hardcore F-CPU dev in many months. In the meantime, i am doing uC and DSP. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cedric.bail@free.fr Mon Apr 21 12:57:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iUa-0004OM-00 for ; Mon, 21 Apr 2003 23:06:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:06:24 +0200 (CEST) Received: (qmail 3926 invoked by uid 65534); 21 Apr 2003 11:04:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 21 Apr 2003 13:04:11 +0200 Received: by moria.seul.org (Postfix) id A4BD833B58; Mon, 21 Apr 2003 07:04:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 08B5D33B5D; Mon, 21 Apr 2003 07:04:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by moria.seul.org (Postfix) with ESMTP id 4941533B58 for ; Mon, 21 Apr 2003 07:04:08 -0400 (EDT) Received: from 46.212.62.62.9massy1-1-ro-bas-1.9tel.net (46.212.62.62.9massy1-1-ro-bas-1.9tel.net [62.62.212.46]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 3BC4717B4E4 for ; Mon, 21 Apr 2003 13:05:25 +0200 (CEST) From: Cedric To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload Date: Mon, 21 Apr 2003 12:57:18 +0200 User-Agent: KMail/1.5.1 References: <20030418195509.14358@thrai.stud.uni-hannover.de> <20030420150622.61844@thrai.stud.uni-hannover.de> <3EA354F8.8070608@f-cpu.org> In-Reply-To: <3EA354F8.8070608@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200304211257.18482.cedric.bail@free.fr> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > >VHDL code, manual and emulators are badly desynced. > obviously. > maybe because different persons do different things, right ? I don't have time to work on the manual now, but at the end of may it will be ok. I have noted a big list of instructions that must be added and updated, but before that work I will be interested to change some of the latex macro so that the manual will be easily parse it (Yann suggest to me, month ago, to create a script that will synchronised assembler and manual). I was thinking before that it could be a good idea to generate the manual from the VHDL source code, but in fact it will obfuscate the VHDL code with information that are not needed. > >I'll take care of the emulators, > >and I think it would be wise to review the manual pages as well -- > >at least those corresponding to the EUs I wrote myself. I just need a > >copy of the current sources. > i believe the latest versions are available easily from Cédric's site. So the latest versions I have modified is the one available from seul.org. Cedric ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 21 19:38:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iV4-0004OM-01 for ; Mon, 21 Apr 2003 23:06:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:06:54 +0200 (CEST) Received: (qmail 15973 invoked by uid 65534); 21 Apr 2003 17:41:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 21 Apr 2003 19:41:29 +0200 Received: by moria.seul.org (Postfix) id EEDCF33B5B; Mon, 21 Apr 2003 13:41:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 63E1033B8A; Mon, 21 Apr 2003 13:41:23 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a126.home.uni-hannover.de [130.75.232.126]) by moria.seul.org (Postfix) with ESMTP id 1A49833B5B for ; Mon, 21 Apr 2003 13:41:14 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA01430; Mon, 21 Apr 2003 19:38:06 +0200 Message-ID: <20030421193806.08593@thrai.stud.uni-hannover.de> Date: Mon, 21 Apr 2003 19:38:06 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Alternative ROP2 Implementation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Q68bSM7Ycu6FN28Q X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii During those boring easter holidays ;) I have found another way to implement the ROP2 unit. It's based on the formulas (in pseudo-C): a & b == b ? a : 0 // and a & ~b == b ? 0 : a // andn a ^ b == b ? ~a : a // xor a | b == b ? 1 : a // or ~(a | b) == b ? 0 : ~a // nor ~(a ^ b) == b ? a : ~a // xnor a | ~b == b ? a : 1 // orn ~(a & b) == b ? ~a : 1 // nand b ? a : c // mux b ? c : a // muxr (new: "reversed" mux) Note the similarity between and/andn and mux/muxr. The attached GIF shows the actual implementation. The five signals: 0, 1, a, ~a and c, are "precomputed" (only ~a and c actually need any gates) and passed to two n-bit wide 8:1 muxes that are directly controlled by the opcode's function bits. The individual bits of b then select from their outputs (that's a row of 1-bit 2:1 muxes). The main advantage of this kind of circuit is that the `b' operand signals may come later than the rest. That allows to put a SIMD :2** decoder in front of it which will help providing the full set of `bitop' instructions: band y = a & (1 << b) // also called btst bandn y = a & ~(1 << b) // also called bclr bxor y = a ^ (1 << b) // also called bchg bor y = a | (1 << b) // also called bset bnor y = ~(a | (1 << b)) // new bxnor y = ~(a ^ (1 << b)) // new born y = a | ~(1 << b) // new bnand y = ~(a & (1 << b)) // new with a latency of just 1 cycle (which won't work with the SHL unit). The fcpu-mr-rop2-20030421.tar.gz package (second attachment) contains a rewrite of the ROP2 unit that supports all instructions mentioned above, as well as combine mode up to a chunk size of 64 bits (but only for the ordinary logical operators, not for bitop -- I doubt that it makes sense for them). Latency is critical in combine mode (I had to violate the 6G rule again, but I still obey the 10T rule), therefore I'd like to receive synthesis and speed reports. The unit has been tested with both Simili and Vanilla, the testbench I used is included in the package. You'll also need some stuff from the `common' directory; see eu_rop2/Makefile for details. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" --Q68bSM7Ycu6FN28Q Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rop2.gif" R0lGODdhZwLQAoAAAAAAAP///ywAAAAAZwLQAgAC/oyPqcvtD6OctNqLs968+w+G4kiW5omm 6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWZkIYJmpuckB4MkJGiqq 4Fk6eopaWbqa2uqq+Bmwivlaa+sXazB7y9tLl3uw6zusSVthrAuMbAWMIEwMHdkM0WzqnDXt zBrNvWgtsZy8EC6VnfDcnT64TW1BDmVOyq5O3zffEI//7pQv/10P0A6tf+P2PeinBKE/hQEb mhnYj6G8KhLP3XOI8Uys/ovB4hHURiXiR1kcM5r8gmykuIIqSYY0mOsdupM0tygb2ZLkvpxJ 8qXcWbKm0CjhcPr0WHEI0nMHgw59mtAfSwcteSJZCrKpVahcgciclrMq0llky5o9izatWqwd wTntCpeHWqn6gBrsCdQihZlx++owdy/s2ClsV+596zexC5jVjtolnDerO8SKK5tw/JPx43KR 22bgazn0ZWqNqRaG11lXB9CiW3tAOE9satRUJXei7Dq3W9I3N9PlbDqYCNa6i2tVadazRb5J iYhsPoG48enD7zKALgR79a3Uu2Norj1I+O3jvZvXu/dKefLWz7tvGh3L+hHS39vHF6E9k/kk /urf/68GfyX4B2CBYwh4GW4GLmiTfjYQyGCEzDh4g4ISXvgEgitoiGGHclGIA4cejlghiCWS iCJwR4iYIiEsCmTigzG2SENystTWUUofPscdWXK8mCCNzhEUVG9M5UAgZRA+NGONTQrJQknI TUTKDj1aZWEZQA74JJQpOJUNiF3Sx9BbSzJ51ZheJmhdUWKqCcKVgnGnEZyL2blmCIgtA92W h+mHSVg61eEnmXla2WeMhboFqE5fDfoLnlFKeuht4AF2Wl1GJSObj/lxeh2oOTYGkTBnDvkp kpRWqkGWLi0023U/afNJWb85Cg6nbopK63K06jihVn+tyup3dPJ6/quvpmX2a7M5JosfsqpJ C+mzvRr2EmnDFitjUrLVBd+11P4TZpmjSvYRkWDVSmyIbbb7GbzcRndstdBa+6e4+BrVqK7X 4AuwvefK9+62886Q5beyUhiokcoKTG2oADP7cMQKroVxxhpjrK2qByNcr8JTpWpvujGV26+/ r45L6sLYFOzxxzKEPJjL4SJrsjH85notn+v6TM6pK8LsrswzHyvyvbaV/HPAEY+znLpuAg11 vUN3XLTRMFiYdMXJktu0xeZGDa3UVT6dIdEnar01TyeDK6uw+uY8sL44Omu3wOrmTdvNa7P9 QpEUK73ywoNDDHZvKS/NssPC8Z021n8D/h542E4/7baPplqu61lyM45r1OxaE/Sid0ouI+Ug E/fzRQo9Q/rmgW0Dm6eGz0S7zrEJLd5dvHOpulImmm4L8R8YH7yxx8hLDPKrMZ/8awy75vxt 0We3eGjVb7D99ce0k1v38XpPvvJXl48+vWmmzz7qwrcPf9znx08/tqjWX7/45uMfv/4X+M8/ AAFweQHsH/QMVcBMKKpiB3TS+hJoCW9R7V/qaaCeLAjBNiCtIFCr4AMzyIcm4WZ4HpwfCPOg HSUND4MtGOBhTqgHq00rc/tTkRFcCEPhYadUfnthtkyYw2A56iuus11+SuUbwuFQeseJWRAp Ygpb2WZ2C7yc/v1GFSt+aEaGwHvihBQXsN2tEG+QQxsXf+CRMp7Oi1CcmnLmBp57zQluRHEQ AJfIRum5EWK8stoevQZIKy5BIndkYR5VQDc+VitkNlNj1361sUhKkmO7Sd0hObNH5JzsTWgh nCI/mRBAGVIfl8QkXTSpO4YRcYKN9CReeDa5UjYhkagUZAdbCcpHzrI9owyOLNOWyU3ZEj2G c2TN6gg+J/5yP5YTJtrOtixijoyDkPngMgfZzHUFkprLOtw2C9e3+NQAj9dc3h+ZBivfvctx SjsjGrfoqv70spx6jB0VxwLPVbIDZUWEoqbiKU96TiJR/gSiQBtxKSHecJ4HJYO3/kq40IZK gpAEs6ZEH8HLl1n0okIiZw85SiOP+hKkUBIpKUlaUoaOD6UdVWkNWYoik8oPpimSKTdpSiKb UgmnOXXp/3zKU2xmT43M3GhQYYQZTRU0okeN4ZQ+CdDeGbWpAvlctKppUKoSijcHUWgRdKpV K3H1blhlalgJxctMITOrZ32DKHdS0W4qs62AcGdRrzpAsNJVh2JII+jatldB2BWb6rNkYP8w 2FCK07CHtUd5JgnZyHqOZIxt7B4S+8omxtKyKNTrBRm1Wc7eAbNTvSnIRBtCz8bJjkBVLWrd BdTKFXacsX3tQmvbQtaG1rY/ci0TZ5pX3PL2nVLsAj5x/uvb4Q5UuEdUbndcm1znQgK6zJWu KKhrXeNgN7u62S53qVfdj363Mt4dr/bC203JTta8wyivntjbPPSelD7wba98Zzqc+vrCvXHS by/4ezz/wlaz0yzrV9t13+xKaVYLWeqBByTgEpVrp3Wz4YP7E2EkmRacFLTw/eib4QcV2GJe /XB+QzzODV/xRg428XtRfLQRTyzBKzXriWG8NVxOLK7uizGGcawqIhpXlFkDMZAlrGOIRnO3 qznygGWs5FAFF8JO7laSS3y2Kf+4yk4S8mTUC2bIdpXDPjYyl4/m5QbdTctmPnPb0qwFv644 BiyisX4x5QXASNOBW3YznTkX/md9/q46VPbzn88Z6EpWtr+GLvMb1dxcJnei0ad9NKR7/OdC U/rQdiZ0pBcd4E1TAsCvEfWoO23pUJtaGqiec5NXzerSThrW0201mUtNa4zaus651rWsuddr R5D61cH2xq4RXGxGDHvWyb7EsTXdbEMsG9jRRsS0W1Vtaz+7z9m+ZXrmlmi2ErvbKh6ptGxN QHEzm9zf9Haq0T3bC7eZ3SpL5mJ/aOMX05uM8423h9/HbXrz0Nw+NLCLGb3vGYrkpeGU9433 vRFdmhHeBGdJIaHNbm/+lXUU77fFLx7wboPRkxInLFmL/PCMy9ExdGw4NA02b5GvXDMtj5xS 54pw/pXLeI5XHmKYf07Jm0ua2gJPC8mP6fKeyzbk0cZUy2pO1F8Pc1IYrzbNjZlEm3+azzFv dlJtWXLFKprrKbf6WFMtyOh6vOKZZnqxa8fOb6odv2MGNa5Fvk6NW5G0OFcOm8v+dtbYiMzF Rfsu/wlzwCd87P5OOvaqvvitM36t+c555AsOS3w7XN+XTzdlNX9wVXfeHZ8HPcC7PvpISf0z qb/stlHf+jhcm/Wxx8Psv1N7279e8bl36+453/verh73wVe9uolefNn/3vIJr+KONXp8bHde gl7ruORPz3u8T4/Cj8Py492u/aHa2+DYBz7Et5LQFpef+Tqn4U/V/33Y/psdlLfG9OFBS1vI ZzviSJe79cvdbmskf15XRk6nVvfHdpU2gIHHb88Udpm1dvkHfgQYSDwHZXdFd0MnfRA3c0t2 gSaXgXY3buQGZw7Yf5AEdCnYSXETVQi0gL02F+32gKV1ExpIexm3SjJ4gghIYXzXKsgmcB5o glmnRR7nP7yGg3IFdjuIgdx3hEBIgmfnalD1f9y3NE+of8EGd3o3cabXYfWXW1kIg3lXgE7n hX7XWlDYdIJXXPxkMvAHSShnfskHhhFYhNF3g3RoeHZ4h5Uneno4he72b/GXfcVHUVG2fn8I iN13cmfoFWq4iGtwe/8TiW4wiaRXiWxwid8j/oaZ6AOq5YNfeEFVaIid1oLjN4pzV4o6xDzw Unie+In3dYr35mmDBouIhF6z+G0BhUW3+CE9oIucyItxyF7OhzPhFmSj5Ir6ZF7UZzekyIdv Nk/LmF7ctUFWyGLeJ401EiTHAY0hFS9js4uOOClH2I28oYohJULoN0ZwuCGhuIEueETwmEBc NHDRmIA8mFs4RI3mlI4dAlD3GILXp3XlyFz9+GX/mBj8Z4CtgzRIBHVp942uNnjhGF4I+VP0 2FKjMzv8JkNceGsc54gVmZBecY4WOZFPIUapRDZT14M7E5HPBIFHIor0YlMY+YMaGVPZVGB+ 1IExSX/Dl41/Ymc4/sk9wZhSwZRmPlmBLKd0M5mPxfRVJ1lPKZkRtGSGMvlyeWOBSqSCX7mC qFiNN0SVx4OUO6mUjUQzYbmERKiPV+WNoFiWq6WTDIKVS1kRBqiDbtmE+OhzdTmBR4kCtlhT YVNLWlmTYeSUHyh2dSeVhJljXTSYZykhd1k6UbeHYiSEAbh6dpEZcimZX0KZC5JIfBR3jfg1 VweAIBiBRQSYL8hwk/ma5lGab4iZdRg6E5dFb7mVuSk6KzKXojmb1FGa6CQ66oSOZViCBSkx 9fZxwBmadzKc3SU7UoNP6SVob5NOu0KOr7Ino/klwWmQVtkiBNWdzjmWUxmdnEaePTUZ/tpY YejYakaJZgqpjsI4kn4EnoMpnux5VIfofQG5nydAn70pm/ZZU6VncC0ImYHTn0EpT9OZa5s0 Jg26GA+Km2yCoLbFkVUJncPolwfano1loZ3zofI4kNK5oZYViiU6nmBpf5WzoodFLC7ahyEa hr7ooWlQO4mnozk5o7G5ZxL4o0cpoVIlXgpYpCgZIGojgkvKKEH6fknqaFCakCP6nlTadlaa kVKapYhng1z6nDy6fGI6j17qeZtnpmeKpWkaemuannUilHA6RE06p3Bqo7yJpHTKpnaKh3xa p2R6p2uap32ZiIAKK37qh4j6m4L6p3xaqKz5pozai466qJRq/qKWqqYXojHNSYxcEiaud6SP OKi984qvyIglEylZuWfrtVqM06YRiqaYN6lCtZhOWA2runbcGZ/WM6Sxyh6KuqladBRw+W5z ICg1WToCok0Gqnyj+k6lyorGmpioKYk+AavLGY5lA6xmOaDSSnaQMWGrmaJocCWC6JKTt2Kz +jwk2VdlWke8OqTqSqZEli/tqmPsCqRsGQabODS5Wq5RySQycZvpKoV8o6/GEoMHAq/xqjs9 Jxa+R7B7GLD3unJwkDFa0rDxSpHMWLEMe5mI+VcKm2TQyooL268bixq1ApRU2K3+OHg0Q5cl ixlgabM3y68oobIry4S6aYnjCqEU/vtlNJtPOGu0R8uw4Pqvm+l/L2uxNEknGnKYe3m0VWu0 SfuvVpuCGcm0yvmzExu0Q+mtRIudWmu2P4e1lyquXSuRTmuTB0utekS2/3S2dStZDrWzK8u2 PqtBcKegZjmQJos9QZeySntbe+uyXwu3zjq22yS4proWeGu4B6aaH/i4xEWQ1QonxTmy5hq5 kvuou4ScQJmw5jSPcTstV9Ss2YqjIGt0oKu2prS3Efu163Q7bZg4n/mSLeu5rpq2wyqut+q4 pRulZrKsYWk2yjm6q3q5fbenX4Sq62pEgThapui2+yqstfquU1pXRXm92Kup2lu4bopYNPa9 4Ou5k+uO/p4qWLLYWc3rvKTat7ToImjkVPArh4dqrn+LUpHamMCLqf4LlfobwN+qvkuHqWOa vqGLpwbMwGEKqQ4cu8B4vsUowQAciwl8O9lLwJQqwAcsgBr8qXL6wGb6wSVMpCJcqQs8wYh6 wi2MKCrcqCyMwYz6wjX8izK8wiQMwxGMv0N3wY0nwjdcqzGRv0McxATMYCksw0SsvwDLxMlX o0lMiK3qU8QbVC1KxVUJo3SnPz8MYy7qxIr4ql7MUFvcaNHbpfMpnqWxjZnIkBWKxuvmaaaF PHO8aYrzJGN8dyh6hRiEx++BxT4aqFd6onXshAbJDTYCE+CGKDxSJnw8VUIj/sl0/FlwWSiB HAj31G9EMizs+DqaDMBnUsnIh8g7BT2iXL6sSpPH+slRmpzGF6eznB0P6sCqvMqMga7Wimaw TMu+V7zyeciXvDoVLLuN6IxI1qdgiqyqNCegCaIyasyY1CbzGqPSmSuCAsbyS5Qeq57RrMj1 8JGKEls94psgsc3RusaJSpbrKZzT/BKXoq3U2zkhy3FqnGV6xjTJK0WlTKDq5IYjrBQYmooO 4SoB/bE1eC6omrs800+I83TO2Z7FmrqN6s95eMoaepVrSbrPAUcj1ziwlC5Ok7z7MtGNbHg5 Kx4EbSnw/DISxJf0F9EQvcS3mUpLzLl0I6WnAdAX/k184FzQNJEwPaufGvcNMJlMscGVM92r 5PdoWwjNfuytLs0FQx3TG5Q4v4HUjkkuS81KDUi3dhtZRvhWnlWgRkrVQwbTHZ0yWf0wW01W uePVw4ulPO3MYHXWCjvIA2u6ENujM/ZHcG2spANIJS3QTm0/8nyTLH2mFT0UXEPUC/fRWo0y medzhc3UqpHOxIyrei1feW2TwAIVkH3VwuvW4iLY7HvONF3YBkuDPoO+YuXORMm4J2G8KX2A imnUFOpKqbraOe3GIvvarcyksg3Uvlzbtk27mJPbEn2aDd3U6FrZLXlunPm/L8cfPp3cglmS qPvYgDa1AWgrspOarwt1/vyUToG6rOtrxKlYzoyNnrs82tObrcyRVkcdx0hEKhEnnzXLySuD DvStp9HdruY42xZn2cTZjpbxhJcL2vHNy9RJvgtZzoEM2gctyNsnGvw4x2cdkPYhjht+kFtM nwz6H9UcPheZxDg5i2ltjZ99wQgZjC6uYAl2wtR4ljRuXXj9rcvYojqMjcQFiaMYmAUMwtsd j4WYwP5KvwMN5J2bwUUuF08O5RTcicBI5UKbw7D5F3RljKoKfT2MicPcVMlc3TyGwz/dzmF1 jfM6okye4E7O5uaMn4jNzUqO5WelQl9q5+rM5RrG5jK5Q1YJ5/xrkoEu0zOyooUulrWsVQzJ /tati8PINeRyXuZluMEfe3zbjIRkTlMgjXW8K3UcfuVTTlWINoSiHn2kLuXG/Z8/6dcT+ddH 3MffnMX5KrzKK9Z3q6WA1epdXubm3ZaqPsGs/uchEuxSOexPOeqUXuqujlOVm0s9e93kisB4 buo89XWpzuyr7uy/DujafrC5ruXeTshk7OjRToZtK+nia+zYDu0stYVey5jVHuRVyn7pLu9s aDtuuLqDeNj4ju4rLV3m2edRfuwVsuMLfvBWDu7IvvB1DvB3Pof67lwAur4ID+/Abo2Gzpwd nOTOkeX0HMMPr/Ajz+iOaetPnvIRbr8on7dqvvJA3vLefehZXvOq/m3pLB/zlHgVI5+hJZ/w IgbzR07cIt9WX97VYZ7mPu/pWfwm1cf04ovRSD/nGg46b97zY77mj07n49jwW77x4e71oczn E+/nYw/xjy7oik7oWy/xO//qiS6kA572FU/wpw6Rsd7uHYzL5e70XT/3XajA9y6px0nrI2j1 /6m7RxfT9l7R+Nvpgi/uTSntBUv1JC+az87xg385XWndPQxyQ59il75z5K6bu87rmXvteH/z UJ+zoI/5IK/5m2/yRA/1ys7t9T58tTX5Mw9T0i77rk3730763Jj7Qjftjz/ASB7Crv/ylb+Z qB/0Yp74liz3/bvufGvtd3rFlW7x+x7L/twf+mrrrr5+/Aij7gvW78drm3Z+/uiv9id/8eSc 8Q6f/jMT8RP+8VWc73lPAPExdbn9YZSTVntx1pt3BoAq9MgyAM20QdWzfZERnunavvF8ZiNZ v3k/TdDkE2aMR+WS2XQ2k4vok0SkPqzVK2W69X7BYfG4lSWbO92xmtx2v+FxJlpM37DDePme 3/f/HezABJH49AARExUXnwi9HC8OHxkpKy0vgSSvIC00NzFBQ0VHJTipTLkMSVdZWy1RnWBL VV1rbW/fZOc8U/d4cYGDhVV0l4qxaIeVl2c7E0B8fuWOj6hXkpmztWM8iaCfQ61/xKWwt8+V vyeisqRz3Y3h/pF90evT1SF45df2hcgV+vmzNxAYND2o/m1JmOlFwHEEIboage+DtIWNHOa4 aCCjxogfSU20I2sjlI4My5gDuZIRC4Mr0FB8djIWm5enaHJUyZInoGgxpxjsUjJeoANEO+V0 Qa9nU58/29GRyU2pkpgzMTbc6ZSrmyRTT0gFWrWaJKRclJKFobZr2xRfo6oBy/HsOLM4tTJ1 u7dORbhyx8IUOphwYcOHESd2xBZt3ml8IQ9CDFDs0Lo6BN2s6TgO48ifSwWVOZeuZc84Fl/u kXYraNeoA3mrLJgSJNX5WOt9vRs14CCkw5qubfY0ltyPeSe3gWe0b5iVbBePzRmO/nTlnzNT JL3deo3oWVPqvj6+RPbfgaXc7v2cLt7wyMnH5zDYr9Cj7OhjhW5a/WrqueQLcJdIuvOuwDuO 60zABf3R50Aa+vOgpAeHYNBCjbrBJMI0Eqzuwg+Xu0tDCjGYsDUQUdQin3BIJPA/r1KMEbQN 5+sQQBlx3ItGBF9so8UcgURkxyFshDHII3kaEgnFmCzsRCSh3EbJEn88JcorCZrSxWWqxNLL L7RMipkuvywTvM7IhMLMNYcJU4Q052DTwl+M0E4UNxvjUk4GTZGtThZ9gdOYPQUEDqD0yhkx 0DEJdcodzebp5RVBjWO00SQfNbS9Ny/Bcx1Kq7mUJU0//iit0i2HW1RPUT+CtBdDSQKVSFXT YfVOkebKjypXT+X1PuEq2i8092q1tdNvCNOvtDphgYo9yrgT1r8z2zR2xPN4aA5bMX/Fzzm/ UsWtSk/VtHbSv+5Lz1kRoFU3NmAXySwsYqs1dz90gwPXVHZn8vZd2lqyadPNVrU3YHxzzbZP fan6l2Fom4xY4olhHdgkSw2O1wp1EpaB1F2d7NdhdwM2yuIBC844kak4NgOfj0/uVmSASdb4 mnSpFUZWld9E2GWFNfn215HbLTlRnAkulmchN3YJrG2HFWzdh2e2Wd1kL055aT9YBhrRoZsh el6aKZMWN3p13pppfPNVdt+z/o2Duuayw4U76XrV5rrpqccG2SbmtEOvaKPtzlrpvAO9Sddl +Xu3Y/tiDo5XciU8xE3KB0U8vmZ3ppJWvDW/DqHOPZ+GdNhCJ2/hYz9PO3XVRWTddIxfH+8g QGfXuvbdUUKTdt6Bh/B0bn4P3nhihkca9OOZLy/5yHF5vvkvMT/18OmxnzX367PvntPtl/de /Gl9133884MF33X0i++h6qVAqX4689kvqBtm/4xfevkFqv+eoL8GDkWpLxjS81+kkrIYZ8iu fNw7oN6WRIjRMbA6BlzLA1dGkrelj1t1q2D7MIgmDbbtWd/z4DtAGMId4Opnk1sc3Hy1wfe5 TRHm/gkT/x6iwkygAGvKcxXMYtAwDvYLKGarzw0t2CMdliFwXtuVEPO0rLkNjooZRCDaCrjE HQ4uLlBcRxVlOEMvWvFmj0jie7S4Qp+JxmMIASMJpzhGpjlOIWckRhoNtEaGARF+YgQOd/hD MUEOMmRS24Qd34JH4emxZnxMzBvBFsenrGZciCyCItVYtI5FknxEFKMcOUlGceUsi5hsyN7C +DYgCi2VoQTlH75zt/WZ8i2olFwA4Wi9q72ylbmcY9QMFz5aVo5tT+PbFac4myHWkDikLMgw kVfMpn0Sl/XhZbROaDJZlhKazmMbHPcGK8DJDZJ89IpllIcyB3Yzgi37/mEMbym1FkKub36D y6TkWccUsrMVnMMnAZ/JzwI6iIIopJ9A+5mhgp5znwhdhW301zpuOjSgyMymjyxZHoryDofV nOhGQ9dRuq0TpFsTKQ0/WtK8nZR4B1WpyliazpS+dGkxhd4tMkrTldi0nrPUaU33l1MJ/XSl QW0oUU1nObIR7oMuRWpSfdM4IxqUpE+Faql8KbOpMtSpVoUP1Y7GVKoK06tPymoQ/9lAspb1 q2AV4FYxelS28oOSJbyoW+0i17nmITRDiegonRm9vbJIqFG0azB9OtjhFPZTugwsThV7LVuI BUyMvUNkj2XZTo70kHrFbFJrREjRjhad8Mxr/lc/m7jJolOmZfFsat+h2cK5zZxMfC1sMSpb x7a0taetKm5BW4si8rYoqAXuOXU7v2pqiac7OG4Gk3tYtPYWM9Hl13Nh2VwOKReJt8XuIXsY kr/V9pTe/S6IeKpdJZ43SOm1rqTYeyX3mje+fDKqceuL3vv+Nr8pmi9++zun/a41wP4dcGIL LCObkldDCT4SS007WQe3l3QRhuyEc4RDCwsWwziS34Yr2mEDS0a9HhFxdZWK11+C971DPTGG KiPVu5alxP178Q6D0ksQA7RBNQ7VjTETtxXBFcUtviOQUSe2Q6W1x0ZGI5IhBNgyzniRTl4v lKtwkOEyGcdusTI7/i13lQFebceG1BGWMfLlntoTHmWOiJp/yuBJhlUnVPIxX9FsEjVDNIFw BkKe9bxaYPbVz0kGNI1DS1pFTyxslCy0iQ+NaOGmWFyPDnKkJS0RLVd6c5jOdELdR0f5WLqk cs5uqHdZKE/3WNC7jeeCSA1SU0MQmW52Taw3Ous+yEurH8K1QA0D6vnZmje/XrWBHO3hY4tu vMZWyLKVMxZnTwLaxfbWtMFUbWt7MkrY1rbzet3tb7+Gh7oe9bhvTWz0ontGdw4xu8+8J2/D u3bzpnfq7H1vzeVb3yvt97L5/e+aCnzVASd4xgx+cHslXOHWYnjDbfVwiItK4hNvVMUt/i7v jGMZ4xtfU8c9XiaQh9xLIye5fE/+YpOnHEkrh+lkvuhFl+9m5i/3E+BmWPMZ/duYcvFoH9mq c4THJcfXDTrPW/hzVyNV6AbbJEoHbdWmLzzpUN/sU6durqe7kus3pWnWHd5Fq9OTs1hHOv6+ Ccmzfv3s4eXl2s2tSLAbq2t+UnLX2d7vnh+TmnBf9N8BH3jBD57whZ97xOeJd78fnuVjSnwv F994hD5O8YCUPLAfv/bIXx7MVaeu3znPz733HZuhH+Y7675UxZs+hEySrtvXzHqi+lP2Xp1g 7cu6OtznPna7P/qQfR984Q+f+MU3/vGRn3zlL5/5zXf+86EfIn3pT5/61bf+9bGffe1vn/vd 9/73wR9+8Y+f/OU3//l7UgAAOw== --Q68bSM7Ycu6FN28Q Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-mr-rop2-20030421.tar.gz" H4sIALEVpD4CA+0da3PbOG6/Wr+C63Qudmsnkuw43fjSWSd1t5nLo5PHtd25GY8s07GmsuST 5NTu7I8/gKQkSqb8SNruXteavUYCARAASQASQd/Qnkzr46Ae+BOzbup6Q2+axv5PX/XS9aZ+ qOvwl135v/z+sHVg6IbZasG9Yeitxk/k4KfvcE3DyAoI+elveg2V40+nPQTs/xnjb8D4m83G 4Xb8//zxx3/2HkYD92njb+h6q9ksGH+z0dIPxfjrh4YB9wbIAOOvb8f/m1/1OkkGmdTJm/rp uzty7t87tuWSqwkNrMjxPXLnOZEGuKf+ZB4496OIVE6rBOcLuXDskUVdcu3QCSX/HPPHX8No Otibek59ZHme/0CDvQF9BSyQy+3ICckk8O8Da0zgdhhQSkJ/GH22Atomc39KbMsjAR04YRQ4 /WlEiRMRyxvs+wEZ+wNnOEc+AJt6AxqQaERJRINxSPwhe/jt8o78Rj0Q3yXvpn3Xscm5Y1Mv pMSCrhESjuiA9BkfpHiDMtwIGcgbHxgz1duEOtAeEFAhRFOYcR+CYY34ATKpWBFKHhB/gnRV EHdOXCtKSfcK1E+1HBDHY7xHPtgyGgFL0PGz47qkT8k0pMOpW0MWgEzen92+vbq7JZ3Lj+R9 5/q6c3n7sQ3I0ciHVvpAOStnPHEd4Ax6BZYXzUF85HDRvT59CySdk7Pzs9uPoAR5c3Z72b25 IW+urkmHvOtc356d3p13rsm7u+t3VzfdPUJuKIpFkcESEw/ZKIEZBzSyHDeMFf8IAxuCdO6A jKwHCgNsU+cBZLOIDRNr9eAhE8v1vXumJiCnhmwTZ0g8P6qRz4ED8yXyF4cVydORrZEzz96r kYNfyC0FI1HyzrVsGM+bKTJoNPQaOfHDCDEvOoTopmEYdaOhHxJyd9PRkNuvlZ0qeXY2OEpX Ue2BGHsmWxv7enPfNIhxcGT+cmT8QsTaIN3ZhDzTNNfpB1YwJ2fdbretweiyu70wGvRcXIE9 w2g19yzXbWus9bMffNo7caLeheU5k6nLtBDt1IscGNtrkAKmlFa6R/uB4SpaqfT+7PXtW3JE PCuaok2PjkmrqZWqba008YOI4eBq8ibTCEhLHcCFeYhyTLkgD9SO/KDCGNUNMvA/e2BfHTmU TjbCPt0IG6QaTj2buaAQhtweHXEogcBBjl/BxAGnQPoJ0EiBMBfSBkNgz2BmpkCBLcEMzhZp K7yhmrQI7Jkn48eMASZ3aHDegg+TERm9AWWKDGAuqA6Oji6ojWwHDqycKFEDQbY/7jserUNX icAyHHxULBmCx9MZPF9gBwXiLI7EzdnFaxI6XyjhKAC9W18Z2/XtT/sBDWm03/WsPiw3PuFI ZerB7B6gfU7dT3mOSH4dRipw11NAwdOw/mCUxjDXwRVCJwD6CLjoF9efeX0n8icpg9/XZ8DW Vr0+Caz7sUXCuQeeKHTCnj8can1673hayQpDikuPr81XuCKrbJ4ICIw9gMgxE0fFyoMlP2Dr HVa/Fdgj8Fk2rG9KTig6156B7jT2B6JX8JU2DcHkHXBtNXJaI3c1gpMSPBzMBRyCZL0NqI3T A1GLhrkKHhy6VLQwH1Qq2b4H6ZUXkfOs++nsutS7j0Zo6dKDFThsPlgWYC2a9zw/NimFtzFF v78phW2rKfZfFtPM55v2Mp0qKXLriA9jwcwCdmJWnUvTpy3BY7MD/FyG36XwRtFsK7E1MTjW GZ3FRpHxQMmPIdz2PuhG5Y6rxTANvPMYJvpBy0qbTLzDLMHBeZU1JXF9f4LtpX6/8vK580Kv MhYWezD5KhFPRuZJ2DSmM1bSWUo6U0FnrdFfYyWdur8mo7M21u9gJZ26v5aCbh39DlfSZftD /4RjmQ57g/kEK2TTnXuI0ucR5KllCOdliEsMUsIVd0wqPqbdIUarXWNXiBJjGym2NI2MlnIe MQ2MFsp5EDfjI+ojEEp8vfUGU0iWbUjaKzHJYYaiBn/2XwphUNKKKc9QRtHINxux4bLNGfvE mhlqzRpmsWYN7KORNOPjKs0YyWGGogZ/spo1Zc0YRTOZHrzPPLahwraKsM3YLGvxbqiwF3ir bGoU2LTVLLZpC7tsNeJmfFxlU0ZymKGowZ+sTTP+jFEcJHqzx2b2sZEnNtYgtoqITRWxtWbP jTWIC3tOfNxjdD5Yg7iw55aKeF2dD9cgXuhZMQcTV6aJCZZ3cB9iB6dwfnEb8kXnmfrTJt6J FAx4stcMeD1Mp6UNiR2ff0jMMzpIF6UsT7wf9Fjq+VdO9WZ6U0nC0uX95jLCl0sIlyRxM6O1 hDATa/KUDXMJZcaX5ylby7RsNbcp5/KUk0Q87ZTcvNrLw3SqOPHqFpFOrGYeyfhqJDLQzKA0 irIcE4TIJ7gFmQnMTSmBQJkkUeJHQ7iGGNnIIJtZ5NgLweStGKs5C3dHMmA1S0U6B4o2tLWC KqwIWVEQThZHPCaKCmQjg2xmkRNFW01Z0SLOWUWXslxUtAmKNlflrmwFHuccMIxZ7IFzyasa 3WhhhllVpIRq/IaJeVtVke6o8VtNzEmqqtAkCFZGHhEH5vM4rEghRB1bYHZsQ8s2tPydQwvQ LEQWCWjKGN80sADl2nFFwl0ZVjJ8E2crg5UMv01QwX7WjSkS7sqQkuGbVXIZw21AeVxA8QMW TxL3b+vFDkz2Rfledd5rysd4HB/2FUpbHWqUGwqrvkCvIJo9gqjgy/VyIu8xOoX6Y4iMRxAV xKLlRF++PMZ6jzGE7T+CaDhcJ1om6OOxEr2I+1qxWOwPiaAI3gkDI4+LIhZ2eMjuS6ATBkLp ExDuJTEoCplA2d4SQheiq5aLrvntAuYfx2PhH2N/xNwR/1AieJ1yv5JzQBzF1hPHwlyOlgun OHmVbgonqLKBSQV6y1LFTpsTgfSE87XtNnbH92VzHpvjAobABSqB60nIhszYs3LIM7YRm3Pt grGRw5VRjYy8YCOB6nFUL4trKHUTuLMsslFgCEPI4GkLoSWvm8D1ZKulw+BNseRBNaRx8pDk DvmFlyQPzhAcMaZpx+jXsVSEiVWaz0XuFhpww4OVG9Jcm560gQjOMBaGB3kuzKUf0SPS+o0E U1iED46PpUADCMb6LQf5n/Y45tmQF7LAfxZWs8CiHdfIZ3DFlJXGhBQi1wCWsHVP92JNX4Km LwsWSCYfkN7OKvN5DdyBtFTKhq5ABe+wgLna+gG9n7pWIO+4//OYRXUtl/VwJ8K/Rlb6fdFT jHUAWAdPGsMvX4rHMG1bYwwXKgBAoS9fABMRxV56m+3Dx3vubVYV9OCAx6URiULQOfwM/9D/ Ti13Etwfl4fjiNQPTVKf1OvlIzJxKdhQ+wvXf/YiGkZPKgJdUf95aB4k9Z/NQxPwjAOz1dzW f37H+s90kAkWKMJDn3r2iFXyXV+9M0l3Ru3p8lJQg9S3FaHbitBtRahUEZquK2VZqKEfGeYT ykKTRm86xnLPHiClLfgQ0RlolsNOWcnNaY0pBoUeJB1D536xvJSplK0xVRaYVttJhRojyZep deAhLVJLuUIWMvE96JDBIezKpaxFtaysmDWtZt2whHXDGtYNi1g3qfrcpCRz7erLorLKorpK dWElr6zctI5ys7JJNoziExCfBJiKhc69B0N9oXyPPcz0J1CT8saPNfL72m/kgphbKyXBObar 76YI3GxLEJj9cu3GLqrCksYBTn/mk8DLk0rIkAPHu6/yND55dXfRcEfEhaRcekdnlBVsq5GQ GZlBEKvCc9Uao4xtGfeU7X8CHUbxPkvF7buJFHENREn5zSlpHdBUcNSwzP7ZXAXs+h8QF0AV IsNn8XOhYrIKKuX4aIRMorhnmaZS7pRrhH/YyMJPAH6igJ8C/FQBvwD4hQL+EeAfFfDfAf57 Vg0hbFaPgd8LKPdqfITYomSDRGY1Mi/cUZNVjse/Un7/9qpDbt92r7s///xzWZIr6TwnKHTK BkIJh1fEMtnHMReKJNJmlbBH1P7UExFqUZF4PpFZgTYphtBX+P78VIvGE+VSn+1ClnNPs1/F 1POSsThW8Ij83tRDK1F4i4YsZUzM589nYqMJTCTuqqwTSDtmaBjkFr+UJrYRNq1ha1KZw14/ md+TbaUyI3coRUYkhFg10l86LUqW60DGq/6gbMV7Z3HRY5V9lmgnZOrPr30lWX8Ni4s9Oyvd s4t58a0BNvnLfQsywuA+RLUkO5ThLRsyacxMhpBVgpXa8ocDMfDJ9wIPkh3CvmbMxVeD+m47 2zDjDfP428DisM2r0qZF9qOBNIIiaAot+VkO/OgjXk5gOWqlMbNHLskZW5M4nzp+xT99VOPM hrXx7AbaOjWeucDtSY1nJXB7WksyDni6SMPjQbWW5BespZmUf/KWOw6WcodanDsgX/dTLU4Z 4BH+1ESmAE9dryblBwD4WOOhH25/51GdGWEQQG4fxF9OkuMI8t4Mzi29ILpmsYyiGLsQB9g5 mkrojAcq/1E0Q5Mpmg24bL3tVsrPnz9n44jRr1wVX8pkROhOAY3J6314jWOCAaMMvTLcSYFi HNfwpWqiHD1+KCivk/UA/gD+Zz/UCh2kOnFbaZYL/BxW/iCuMk9f5WmF7fjxoPf67Lp7etu7 uHrdTfVkEUm2Ir4vkVgLGOhgyspIQm4hvsP/ULSj2C9ssQtbhLeXm+qiKfEhOr42xgZKdp6H bLc+drIMh0/JtIoYUfr9pSigTlIoEHvwfgzq92MQchomshzKDEqZBY72Xh66hjUYlqTIVexj xJvPyQ4uOzgGxkmE45WliUACzVCisVNweVRzAZUdxMujNRbQVFjNBSxPhXag7FMpXkvVrxLz cLFvpW3SKSUC3BDSK5ogZfa/S8yjw9hZD21ygjd9uDnFGxtuPlvgKXAOGMQL06FLw4xIM9OM YrEIOfeYfUpmISwMceBjAZKqHMdMmQfeSz5I5Z3QSt/ANdEhOEn2FZJ73PTLwBquKrd0mKvq XL7me3ABOGj2GcYe+Y5Ni50bUKzybFZa1CD5/MTR3EOakqzvRrq+uULHsHqAV4VhvSBxkQoS plSm5BUg/WS4r4iX7omg9B4TmkVJPiniTRGpUd+VZgzfFcnPlzQMVdIgx+SxR1PvU9Zr7iOK 7DpL/Jsxbjcx7Ods3ESnOJ7YxHFe8CGtE0M0F7v/ZQFgWQhYGgTY0mAiiVFnYvGykAVw9pwS LqFHUuJSeyTphl5khQ/ZWBA9ESQJn7wRsBiFKvSlM05yOylsU8e4yi+m/RqKfo1dpb/ceB58 ePQ8+PD4eZBM24zwSj8dl+rmnHRScfuj+eir61UuGr3X1kP/+B5af/TK1He/gmP8kz208SgP vdRTfkMPvTQy/OAeWtS+5hz0eDr7ah76CY43tMaU+BP2+xBWSABc7Hov7j6s8r1Mq/SF/8d9 32ce2F6Oo/oooPoqAHoKmG0nMFYRlS+Hyr6/SVyl6CJjSPzkEPN/8JZqP/a9FWZgwXIL/uT1 dlmw4C6fuuKC7ZL7XktOXlDqJScvyr/PklOGOF5z+d1fQ77/526hqPpD9/al46/80pF1XQuq 4DJhor5Ag78wF/LDeK0u/1jv1NiAvZC+2K/hFNmy5b0v+JZlOwlP3Ep4QjKs3olItyJS0FPe vBL6AtvEmxp/NBe7lEmktxJ5d2MJhfTjV7m9jmXdGAvdHCynWOyi9UTjGZsa7/Dbdqg2ZO63 VfgSUG26LO66bB5ds+GVlfFkw2s+vi4sxyRObhKKlRGUBRC5eEXegRGP7EOfuOeVNGm+m96n DYInP/4QYoAC7yZ+aVTLR7K0idXruTSSvpuh/VQnJXjZ5//dOYm/5+9/X1if6NBx6RN//33p +Q+90TRMdv5DbzWMVgPPfzQNY3v+47tcOyQ/1trO1zrasQOsvsrBjp2vc65j5ysc69hZ61SH SvNNz3TsPPVIx84TT3TsbHagA3V++nGOnSed5tj5moc5dqSzHPHiYKc4jPQUh07MxtFBS3GK 413n9F+d37rkmAzr4GO1f3evb86uLvFHTPbA6WlaGNgQrOF5T4M420sf9zQEJA/htM/vxULV NDyZwUHPKhyzus9Pa0z5z/UDxnjse4s4CNW006vLN6xBMKruMxHjEx94WgVwLi6YtIglmFX3 8ccfxvKPjzPcm+vTG8BM/38EsidftNdnN7dvzs67N4wdYlcTg2q33Zvbk+7l6dtuzINRatq/ 374+fwcgZDEhdVw8dsSgXQGl2vur63+dn53Acx0Prki64qOmDejQmrrRUftXao988uofJtm9 9IkAE/D89zT6eReW/gxWoKFpluseaaVnFdY5jH1F9FCNBYexAemOiA35iAdL33LnX2icCVFg wCFZJmhw/heNKvGK6QB9dlx+VpGMUS232SLDT+Pk2bNZG9Jl8h9IrDjfbhWB5I8/hOhtbBv4 HojARAOOwZjUgyE/0RPOx2AN8EDxnBDTs1oHdnxmVll7MttSUz6rCEK85e0gOoeKR+ht/Anp nv3KuzkC+mTYUWEJWSvhwKO6KUaZyc/eTx32y+CgHd4lWrsAqfA1AmKwtixXNMV/2MdImCyT NZDzdtvmgttre22v7bW9ttf22l7ba3ttr+21vX7c638uUmgBAHgAAA== --Q68bSM7Ycu6FN28Q-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 21 16:40:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iV8-0004OM-00 for ; Mon, 21 Apr 2003 23:06:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:06:58 +0200 (CEST) Received: (qmail 32586 invoked by uid 65534); 21 Apr 2003 17:41:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 21 Apr 2003 19:41:50 +0200 Received: by moria.seul.org (Postfix) id D7A5E33B8C; Mon, 21 Apr 2003 13:41:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCBFD33C1A; Mon, 21 Apr 2003 13:41:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a126.home.uni-hannover.de [130.75.232.126]) by moria.seul.org (Postfix) with ESMTP id EEEAE33B8C for ; Mon, 21 Apr 2003 13:41:24 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00725; Mon, 21 Apr 2003 16:40:15 +0200 Message-ID: <20030421164015.53270@thrai.stud.uni-hannover.de> Date: Mon, 21 Apr 2003 16:40:15 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <20030420150622.61844@thrai.stud.uni-hannover.de> <3EA354F8.8070608@f-cpu.org> <200304211257.18482.cedric.bail@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200304211257.18482.cedric.bail@free.fr>; from Cedric on Mon, Apr 21, 2003 at 12:57:18PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 21, 2003 at 12:57:18PM +0200, Cedric wrote: [...] > I don't have time to work on the manual now, but at the end of may it will be > ok. I have noted a big list of instructions that must be added and updated, > but before that work I will be interested to change some of the latex macro > so that the manual will be easily parse it (Yann suggest to me, month ago, to > create a script that will synchronised assembler and manual). Don't worry about the new instructions. I'm going to review the ISA pages and send you an update. > I was thinking before that it could be a good idea to generate the manual > from the VHDL source code, but in fact it will obfuscate the VHDL code with > information that are not needed. The problem with automatic generation is that it still requires editing. E.g. in Java, you can provide inline documentation, but if you don't edit the comments when you change a function, the documentation will still be wrong (and therefore useless). When the documentation is in a separate file, you will at least be able to check if it is out of date (by looking at the timestamps). [...] > So the latest versions I have modified is the one available from seul.org. Ok, I'll look at it. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Apr 21 16:09:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iV8-0004OM-01 for ; Mon, 21 Apr 2003 23:06:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:06:58 +0200 (CEST) Received: (qmail 24094 invoked by uid 65534); 21 Apr 2003 17:42:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 21 Apr 2003 19:42:11 +0200 Received: by moria.seul.org (Postfix) id BF0FA33C10; Mon, 21 Apr 2003 13:42:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3686D33C21; Mon, 21 Apr 2003 13:42:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a126.home.uni-hannover.de [130.75.232.126]) by moria.seul.org (Postfix) with ESMTP id 2688733C19 for ; Mon, 21 Apr 2003 13:41:40 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id QAA00652; Mon, 21 Apr 2003 16:09:40 +0200 Message-ID: <20030421160940.56165@thrai.stud.uni-hannover.de> Date: Mon, 21 Apr 2003 16:09:40 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030418195509.14358@thrai.stud.uni-hannover.de> <3EA0D985.3080801@f-cpu.org> <20030419144530.02208@thrai.stud.uni-hannover.de> <3EA1EA1C.6020805@f-cpu.org> <20030420150622.61844@thrai.stud.uni-hannover.de> <3EA354F8.8070608@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <3EA354F8.8070608@f-cpu.org>; from Yann Guidon on Mon, Apr 21, 2003 at 04:18:32AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 21, 2003 at 04:18:32AM +0200, Yann Guidon wrote: [...] > >I'd really like to get rid of m4. > > > > huh, really ? i find this very handy, though .... M4 is probably one of the most powerful tools ever. But it's only a text processor. > >In particular, I don't like the fact > >that we have to run m4 every time we modify the configuration. > > > how often do you change the configuration ? I did it once or twice when it still was a VHDL file. And I have my own files for the C side (most notably fcpu_opcodes.h) that I change directly because (a) the m4 stuff wasn't complete at the time I wrote it, and (b) I didn't want to mess with it. We will have to change it, however, when we start assigning opcodes (I only did a preliminary assignment in the fctools package). > >I prefer to change the VHDL sources directly. C headers can be generated from > >VHDL -- all we need is a procedure that takes all the definitions and > >prints them in C format. Since VHDL has text i/o capabilities, that > >shouldn't be too hard to do. (Note that it would also work the other > >way round -- edit C and generate VHDL -- but since VHDL is our primary > >source, I prefer to generate the C stuff.) Of course we must distribute > >pre-built C headers, in case someone has no VHDL tools and wants to > >install only the software. But that's not a problem either. > > > > > > i'm not very happy with this solution : it will obfuscate the sources > too much !!! Huh? I think it makes it cleaner. I guess only few people really understand m4 (mostly sendmail admins ;). We already use two languages: C and VHDL. Both of them can handle the conversion easily. Adding a third language is overkill. > First, not everybody will want to use it because it uses VHDL, and "SW > people" > who simply want to run an emulator won't want to fiddle with it. Therefore, they get pre-built C headers with the distribution. > Second, with the M4 solution, the files are available in source form, > very similar to the target form. > Using VHDL to generate the files will make the original form very very > oscure, full > of > write ("blahblagblah", somevariable, "blablah"); > so i think that m4 is not a bad trade-off. It's more like print_c_define("name_of_variable", name_of_variable); and similar. > Of course, if you find a better solution, i'd be interested to see it :-) > like, huh, you want to reimplement m4 with VHDL ? :-P Of course not. [tools] > and what about GHDL ? :-) "it's free, too" :-P I don't have an Ada compiler to build it. And I doubt that it is complete yet. [...] > >VHDL code, manual and emulators are badly desynced. > > > obviously. > maybe because different persons do different things, right ? Yep. Therefore I suggest that the authors/maintainers of execution units also maintain the corresponding manual pages. > >I'll take care of the emulators, > >and I think it would be wise to review the manual pages as well -- > >at least those corresponding to the EUs I wrote myself. I just need a > >copy of the current sources. > > > > > i believe the latest versions are available easily from Cédric's site. At seul.org? > >>>Third, I'll have to update the assembler and the emulator. > >>>Finally, someone can update the machine description for gcc. > >>> > >>As you probably know, i have returned back to plain old electronics to get > >>some pocket money from time to time. Now, i have almost all tools to make > >>decent PCBs in small series at decent prices. When the first FC0s will > >>come out of fundry, we'll be able to use nice development kits :-) > >> > >> > >Will they run Linux? ;) > > > > > except slashdotters, who really cares ? :-P I do, and I *never* visit /. :-P > frankly, i have recently started to master certain techniques and > electronic technologies, > so if we ever get to the fundry, the outcome will be really interesting > and the > PCBs will have interesting features... Like...? > >>But there is still too much work to be done on the SW side; so we'll > >>have to "wait a bit" ... > >> > >> > >Hmm... we have a gcc port, an assembler, a linker and two emulators. > > > do they all work together ? are they all correctly updated and maintained ? > are they easy to install and use ?.... Yes, yes, and yes. The latest VHDL improvements aren't integrated yet, but they will be in the next fctools release. I have installed fctools and fcpu-gcc on my system, and I can compile, assemble, link and run C programs with it. There just is no libc yet, and system call support in the emulator is limited, but it's enough for a `hello, world' style program -- that is, enough to begin with. I have already started to add better system call support; I'm going to finish it when I'm back in `C mode'. > >That's all SW people need in the first place. I'm currently concentrating > >on the HW side again -- since many people can do SW development but > >only few seem to be able to write VHDL code, I won't waste my time doing > >software development (of course I'll maintain my software, but VHDL has > >higher priority now). > > > i'll maybe come back to hardcore F-CPU dev in many months. > In the meantime, i am doing uC and DSP. I guess it's necessary to earn some money now and then... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bfranchuk@jetnet.ab.ca Mon Apr 21 18:50:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iVA-0004OM-00 for ; Mon, 21 Apr 2003 23:07:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:07:00 +0200 (CEST) Received: (qmail 18446 invoked by uid 65534); 21 Apr 2003 17:53:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 21 Apr 2003 19:53:23 +0200 Received: by moria.seul.org (Postfix) id C1A2033B6E; Mon, 21 Apr 2003 13:53:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CC6233C19; Mon, 21 Apr 2003 13:53:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bach.ccinet.ab.ca (bach.ccinet.ab.ca [198.161.96.1]) by moria.seul.org (Postfix) with ESMTP id 4DEF933B6E for ; Mon, 21 Apr 2003 13:53:19 -0400 (EDT) Received: from jetnet.ab.ca (gc-jet-209.jetnet.ab.ca [207.34.60.209]) by bach.ccinet.ab.ca (8.12.6/8.12.6) with ESMTP id h3LHrsLQ036049 for ; Mon, 21 Apr 2003 11:53:55 -0600 (MDT) (envelope-from bfranchuk@jetnet.ab.ca) Message-ID: <3EA42141.6010007@jetnet.ab.ca> Date: Mon, 21 Apr 2003 10:50:09 -0600 From: ben franchuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Alternative ROP2 Implementation References: <20030421193806.08593@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Michael Riepe wrote: > During those boring easter holidays ;) I have found another way to > implement the ROP2 unit. It's based on the formulas (in pseudo-C): > > a & b == b ? a : 0 // and > a & ~b == b ? 0 : a // andn > a ^ b == b ? ~a : a // xor > a | b == b ? 1 : a // or > ~(a | b) == b ? 0 : ~a // nor > ~(a ^ b) == b ? a : ~a // xnor > a | ~b == b ? a : 1 // orn > ~(a & b) == b ? ~a : 1 // nand > b ? a : c // mux > b ? c : a // muxr (new: "reversed" mux) It loooks nice. is there any way to get some other logic in like full word sign extends/0/1 's Ben. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Apr 21 20:30:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197iVB-0004OM-01 for ; Mon, 21 Apr 2003 23:07:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 21 Apr 2003 23:07:01 +0200 (CEST) Received: (qmail 11040 invoked by uid 65534); 21 Apr 2003 18:27:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 21 Apr 2003 20:27:43 +0200 Received: by moria.seul.org (Postfix) id 45CDE33B8A; Mon, 21 Apr 2003 14:27:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2DE3B33C1A; Mon, 21 Apr 2003 14:27:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id C8CA733B8A for ; Mon, 21 Apr 2003 14:27:40 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-96.n.club-internet.fr [213.44.18.96]) by relay-4m.club-internet.fr (Postfix) with ESMTP id 2D682E125 for ; Mon, 21 Apr 2003 20:27:38 +0200 (CEST) Message-ID: <3EA438B6.40208@f-cpu.org> Date: Mon, 21 Apr 2003 20:30:14 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Alternative ROP2 Implementation References: <20030421193806.08593@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! Michael Riepe wrote: >During those boring easter holidays ;) I have found another way to >implement the ROP2 unit. It's based on the formulas (in pseudo-C): > > a & b == b ? a : 0 // and > a & ~b == b ? 0 : a // andn > a ^ b == b ? ~a : a // xor > a | b == b ? 1 : a // or > ~(a | b) == b ? 0 : ~a // nor > ~(a ^ b) == b ? a : ~a // xnor > a | ~b == b ? a : 1 // orn > ~(a & b) == b ? ~a : 1 // nand > b ? a : c // mux > b ? c : a // muxr (new: "reversed" mux) > >Note the similarity between and/andn and mux/muxr. The attached GIF >shows the actual implementation. The five signals: 0, 1, a, ~a and c, >are "precomputed" (only ~a and c actually need any gates) and passed to >two n-bit wide 8:1 muxes that are directly controlled by the opcode's >function bits. The individual bits of b then select from their outputs >(that's a row of 1-bit 2:1 muxes). > > i believe that this implementation is actually slower than the precedent version. The reason is simple : you implement a 16-input MUX equivalent, but the precedent version uses a 4-MUX as its core. >The main advantage of this kind of circuit is that the `b' operand signals >may come later than the rest. That allows to put a SIMD :2** >decoder in front of it which will help providing the full set of `bitop' >instructions: > > band y = a & (1 << b) // also called btst > bandn y = a & ~(1 << b) // also called bclr > bxor y = a ^ (1 << b) // also called bchg > bor y = a | (1 << b) // also called bset > bnor y = ~(a | (1 << b)) // new > bxnor y = ~(a ^ (1 << b)) // new > born y = a | ~(1 << b) // new > bnand y = ~(a & (1 << b)) // new > >with a latency of just 1 cycle (which won't work with the SHL unit). > > is it the only reason why you re-built this unit ? >The fcpu-mr-rop2-20030421.tar.gz package (second attachment) contains a >rewrite of the ROP2 unit that supports all instructions mentioned above, >as well as combine mode up to a chunk size of 64 bits (but only for the >ordinary logical operators, not for bitop -- I doubt that it makes sense >for them). Latency is critical in combine mode (I had to violate the >6G rule again, but I still obey the 10T rule), therefore I'd like to >receive synthesis and speed reports. > >The unit has been tested with both Simili and Vanilla, the testbench >I used is included in the package. You'll also need some stuff from >the `common' directory; see eu_rop2/Makefile for details. > i'd really be interested to see the speed differences .... and we'll take the faster version, of course :-) but i don't want to burry the old plain MUX-4 version which can still be useful. btw, does your bitop version support SIMD operations ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 22 02:00:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197rXg-0002dd-00 for ; Tue, 22 Apr 2003 08:46:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 08:46:12 +0200 (CEST) Received: (qmail 11500 invoked by uid 65534); 22 Apr 2003 00:01:15 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 22 Apr 2003 02:01:15 +0200 Received: by moria.seul.org (Postfix) id 3FFF633C20; Mon, 21 Apr 2003 20:01:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D7EFC33C58; Mon, 21 Apr 2003 20:01:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a097.home.uni-hannover.de [130.75.232.97]) by moria.seul.org (Postfix) with ESMTP id 224DB33C20 for ; Mon, 21 Apr 2003 20:00:51 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02944; Tue, 22 Apr 2003 02:00:47 +0200 Message-ID: <20030422020047.13871@thrai.stud.uni-hannover.de> Date: Tue, 22 Apr 2003 02:00:47 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Alternative ROP2 Implementation References: <20030421193806.08593@thrai.stud.uni-hannover.de> <3EA438B6.40208@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EA438B6.40208@f-cpu.org>; from Yann Guidon on Mon, Apr 21, 2003 at 08:30:14PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 21, 2003 at 08:30:14PM +0200, Yann Guidon wrote: [...] > i believe that this implementation is actually slower than the precedent > version. > The reason is simple : you implement a 16-input MUX equivalent, > but the precedent version uses a 4-MUX as its core. On the other hand, I don't need a 3:4 bit decoder for the function bits (which sits in front of the select inputs in your version). > >The main advantage of this kind of circuit is that the `b' operand signals > >may come later than the rest. That allows to put a SIMD :2** > >decoder in front of it which will help providing the full set of `bitop' > >instructions: [...] > >with a latency of just 1 cycle (which won't work with the SHL unit). > > > is it the only reason why you re-built this unit ? The reason was that I wanted to have the bitop instructions in the ROP2 unit. And of course I had to try if my idea works ;) [...] > i'd really be interested to see the speed differences .... > and we'll take the faster version, of course :-) Only if you build a single-stage version that handles combine mode up to 64 bit chunks and doesn't put the decoder in the XBar stage -- otherwise that would be an unfair competition ;) > but i don't want to burry the old plain MUX-4 version > which can still be useful. Who said that we're going to throw it away? In fact, it wouldn't be a bad thing at all if we had several versions of the execution units. I also remember that you said you wanted to re-implement EU_SHL, using a different approach. Doing that won't make anything worse -- but maybe better. At least it will give users a choice, and that's a good thing per se. > btw, does your bitop version support SIMD operations ? Of course! It's equivalent to a `full' SIMD shift (with separate shift counts for every chunk, unless the operand is immediate) followed by an ordinary logical operation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 22 02:47:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197rXh-0002dd-00 for ; Tue, 22 Apr 2003 08:46:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 08:46:13 +0200 (CEST) Received: (qmail 32095 invoked by uid 65534); 22 Apr 2003 00:47:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 22 Apr 2003 02:47:18 +0200 Received: by moria.seul.org (Postfix) id DF88833C21; Mon, 21 Apr 2003 20:47:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B0E5933C3C; Mon, 21 Apr 2003 20:47:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a097.home.uni-hannover.de [130.75.232.97]) by moria.seul.org (Postfix) with ESMTP id 69E3B33C21 for ; Mon, 21 Apr 2003 20:47:13 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA03089; Tue, 22 Apr 2003 02:47:12 +0200 Message-ID: <20030422024711.61544@thrai.stud.uni-hannover.de> Date: Tue, 22 Apr 2003 02:47:11 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Alternative ROP2 Implementation References: <20030421193806.08593@thrai.stud.uni-hannover.de> <3EA42141.6010007@jetnet.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EA42141.6010007@jetnet.ab.ca>; from ben franchuk on Mon, Apr 21, 2003 at 10:50:09AM -0600 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Mon, Apr 21, 2003 at 10:50:09AM -0600, ben franchuk wrote: [...] > It loooks nice. is there any way to get some other logic in like full > word sign extends/0/1 's You can implement the full set of unary and binary logical operations. Sign extension won't make sense because it's not a bitwise operation. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Apr 22 08:18:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197yQm-0007uO-00 for ; Tue, 22 Apr 2003 16:07:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 16:07:32 +0200 (CEST) Received: (qmail 7420 invoked by uid 65534); 22 Apr 2003 06:35:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 22 Apr 2003 08:35:08 +0200 Received: by moria.seul.org (Postfix) id 366C633C3C; Tue, 22 Apr 2003 02:35:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 308B033C58; Tue, 22 Apr 2003 02:35:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id A094033C3C for ; Tue, 22 Apr 2003 02:35:01 -0400 (EDT) Received: from a25-137.dialup.iol.cz ([194.228.137.25] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 197rMn-0003l1-00 for f-cpu@seul.org; Tue, 22 Apr 2003 08:34:58 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 197r6x-0000Hf-00 for f-cpu@seul.org; Tue, 22 Apr 2003 08:18:35 +0200 Date: Tue, 22 Apr 2003 08:18:35 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Yet Another Upload In-Reply-To: <20030420150622.61844@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > I'm currently doing that, but it's too slow to be done on a regular > basis (unless you have a server that runs 24/7). I can create account on my p2/350 server which is 24/7. Its cpu load is low so that it might be useful. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Tue Apr 22 15:02:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197yQp-0007uO-00 for ; Tue, 22 Apr 2003 16:07:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 16:07:35 +0200 (CEST) Received: (qmail 22085 invoked by uid 65534); 22 Apr 2003 08:02:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx032-rz3) with SMTP; 22 Apr 2003 10:02:51 +0200 Received: by moria.seul.org (Postfix) id 99C6233C58; Tue, 22 Apr 2003 04:02:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F15033C5C; Tue, 22 Apr 2003 04:02:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id C517633C58 for ; Tue, 22 Apr 2003 04:02:25 -0400 (EDT) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id A303062EAF for ; Tue, 22 Apr 2003 10:02:24 +0200 (CEST) To: Subject: Re: [f-cpu] Yet Another Upload From: Date: Tue, 22 Apr 2003 10:02:25 CEST X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030422080224.A303062EAF@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Maintaining a (very very big) simulation environnement was my job during the last 12 month. It's was a bunch of shell script, perl script, tcl script, some C programm, some use of bison, and m4... The guys who create this mess add created a whole new tiny language to generate c .h header, .vhfl header, .mak for the makefile, .ld for a linker. This languages has a very limited parser. I find this completly supid and i don't understand why not simply parsing vhdl files to create .c files. Parsing vhdl files are easy for simple things. But you always need more complicated things than register value: like memory size, bits fields, arythmétique in the assignement, etc... After some disscussion, i think that the easiest way, should be to use perl and it's outstanding data structure. Then a fonction could be written by output. ex: %myvar = { reg1 -> {unsigned, 123, fields -> {bits1_3 -> "1-3"}} } Michael Riepe a écrit : > On Mon, Apr 21, 2003 at 04:18:32AM +0200, Yann Guidon wrote: > [...] > > >I'd really like to get rid of m4. > > > > > > > huh, really ? i find this very handy, though .... > > M4 is probably one of the most powerful tools ever. But it's only a > text processor. > > > >In particular, I don't like the fact > > >that we have to run m4 every time we modify the configuration. > > > > > how often do you change the configuration ? > > I did it once or twice when it still was a VHDL file. And I have my > own files for the C side (most notably fcpu_opcodes.h) that I change > directly because (a) the m4 stuff wasn't complete at the time I wrote it, > and (b) I didn't want to mess with it. > > We will have to change it, however, when we start assigning opcodes > (I only did a preliminary assignment in the fctools package). > > > >I prefer to change the VHDL sources directly. C headers can be generated > from > > >VHDL -- all we need is a procedure that takes all the definitions and > > >prints them in C format. Since VHDL has text i/o capabilities, that > > >shouldn't be too hard to do. (Note that it would also work the other > > >way round -- edit C and generate VHDL -- but since VHDL is our primary > > >source, I prefer to generate the C stuff.) Of course we must distribute > > >pre-built C headers, in case someone has no VHDL tools and wants to > > >install only the software. But that's not a problem either. > > > > > > > > > > i'm not very happy with this solution : it will obfuscate the sources > > too much !!! > > Huh? I think it makes it cleaner. I guess only few people really > understand m4 (mostly sendmail admins ;). > > We already use two languages: C and VHDL. Both of them can handle the > conversion easily. Adding a third language is overkill. > > > First, not everybody will want to use it because it uses VHDL, and "SW > > people" > > who simply want to run an emulator won't want to fiddle with it. > > Therefore, they get pre-built C headers with the distribution. > > > Second, with the M4 solution, the files are available in source form, > > very similar to the target form. > > Using VHDL to generate the files will make the original form very very > > oscure, full > > of > > write ("blahblagblah", somevariable, "blablah"); > > so i think that m4 is not a bad trade-off. > > It's more like > > print_c_define("name_of_variable", name_of_variable); > > and similar. > > > Of course, if you find a better solution, i'd be interested to see it :-) > > like, huh, you want to reimplement m4 with VHDL ? :-P > > Of course not. > > [tools] > > and what about GHDL ? :-) "it's free, too" :-P > > I don't have an Ada compiler to build it. > And I doubt that it is complete yet. > > [...] > > >VHDL code, manual and emulators are badly desynced. > > > > > obviously. > > maybe because different persons do different things, right ? > > Yep. Therefore I suggest that the authors/maintainers of execution > units also maintain the corresponding manual pages. > > > >I'll take care of the emulators, > > >and I think it would be wise to review the manual pages as well -- > > >at least those corresponding to the EUs I wrote myself. I just need a > > >copy of the current sources. > > > > > > > > i believe the latest versions are available easily from Cédric's site. > > At seul.org? > > > >>>Third, I'll have to update the assembler and the emulator. > > >>>Finally, someone can update the machine description for gcc. > > >>> > > >>As you probably know, i have returned back to plain old electronics to > get > > >>some pocket money from time to time. Now, i have almost all tools to > make > > >>decent PCBs in small series at decent prices. When the first FC0s will > > >>come out of fundry, we'll be able to use nice development kits :-) > > >> > > >> > > >Will they run Linux? ;) > > > > > > > > except slashdotters, who really cares ? :-P > > I do, and I *never* visit /. :-P > > > frankly, i have recently started to master certain techniques and > > electronic technologies, > > so if we ever get to the fundry, the outcome will be really interesting > > and the > > PCBs will have interesting features... > > Like...? > > > >>But there is still too much work to be done on the SW side; so we'll > > >>have to "wait a bit" ... > > >> > > >> > > >Hmm... we have a gcc port, an assembler, a linker and two emulators. > > > > > do they all work together ? are they all correctly updated and maintained > ? > > are they easy to install and use ?.... > > Yes, yes, and yes. The latest VHDL improvements aren't integrated yet, > but they will be in the next fctools release. > > I have installed fctools and fcpu-gcc on my system, and I can compile, > assemble, link and run C programs with it. There just is no libc yet, > and system call support in the emulator is limited, but it's enough > for a `hello, world' style program -- that is, enough to begin with. > > I have already started to add better system call support; I'm going to > finish it when I'm back in `C mode'. > > > >That's all SW people need in the first place. I'm currently > concentrating > > >on the HW side again -- since many people can do SW development but > > >only few seem to be able to write VHDL code, I won't waste my time doing > > >software development (of course I'll maintain my software, but VHDL has > > >higher priority now). > > > > > i'll maybe come back to hardcore F-CPU dev in many months. > > In the meantime, i am doing uC and DSP. > > I guess it's necessary to earn some money now and then... > > -- > Michael "Tired" Riepe &lang=fr">Michael.Riepe@stud.uni-hannover.de> > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org > with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Tue Apr 22 15:07:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197yQq-0007uO-00 for ; Tue, 22 Apr 2003 16:07:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 16:07:36 +0200 (CEST) Received: (qmail 27908 invoked by uid 65534); 22 Apr 2003 08:10:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 22 Apr 2003 10:10:35 +0200 Received: by moria.seul.org (Postfix) id B5A3F33C65; Tue, 22 Apr 2003 04:10:23 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A006233C7A; Tue, 22 Apr 2003 04:09:24 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by moria.seul.org (Postfix) with ESMTP id 4C60533C63 for ; Tue, 22 Apr 2003 04:08:43 -0400 (EDT) Received: from localhost (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id 21DB362E8F for ; Tue, 22 Apr 2003 10:07:37 +0200 (CEST) To: Subject: Re: [f-cpu] Yet Another Upload From: Date: Tue, 22 Apr 2003 10:07:37 CEST X-Priority: 3 (Normal) X-Originating-Ip: [140.94.197.181] X-Mailer: Webmail Nerim (NOCC v0.9.5) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20030422080737.21DB362E8F@mallaury.noc.nerim.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N (My last mail was send before the end of the writing) So in perl, you could then read the value with $myvar->{reg1}{fields} = ... Or use a bunch of foreach : foreach $reg (keys %myvar) { $myvar{$reg}... } For each output you need to wrote a function. It could a be usfull for c files but tcl could be used also (a stupid language use a lot by cad tools...), vhdl files, ... and what ever could be used, this definition files could be see as a perl modules. Like usual a don't have take time to write it... nicO ___________________________________ Webmail Nerim, http://www.nerim.net/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue Apr 22 13:20:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 197yRK-0007uO-00 for ; Tue, 22 Apr 2003 16:08:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 22 Apr 2003 16:08:06 +0200 (CEST) Received: (qmail 8838 invoked by uid 65534); 22 Apr 2003 13:27:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 22 Apr 2003 15:27:49 +0200 Received: by moria.seul.org (Postfix) id 6105833C5F; Tue, 22 Apr 2003 09:27:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5C2A533C63; Tue, 22 Apr 2003 09:27:45 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 2E54633C5F for ; Tue, 22 Apr 2003 09:27:44 -0400 (EDT) Received: from a2-137.dialup.iol.cz ([194.228.137.2] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 197xoD-0005sW-00 for f-cpu@seul.org; Tue, 22 Apr 2003 15:27:41 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 197vpW-0000V3-00 for f-cpu@seul.org; Tue, 22 Apr 2003 13:20:54 +0200 Date: Tue, 22 Apr 2003 13:20:54 +0200 (CEST) From: devik X-X-Sender: To: F-CPU Mailing List Subject: Re: [f-cpu] Alternative ROP2 Implementation In-Reply-To: <20030421193806.08593@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N > The fcpu-mr-rop2-20030421.tar.gz package (second attachment) contains a > rewrite of the ROP2 unit that supports all instructions mentioned above, > as well as combine mode up to a chunk size of 64 bits (but only for the > ordinary logical operators, not for bitop -- I doubt that it makes sense > for them). Latency is critical in combine mode (I had to violate the > 6G rule again, but I still obey the 10T rule), therefore I'd like to > receive synthesis and speed reports. I have not older rop2 sources. Thus one uses 556 slices and runs at 50.0 MHz. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 22 13:58:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1987wZ-0006O2-00 for ; Wed, 23 Apr 2003 02:16:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 02:16:59 +0200 (CEST) Received: (qmail 10394 invoked by uid 65534); 22 Apr 2003 17:29:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 22 Apr 2003 19:29:22 +0200 Received: by moria.seul.org (Postfix) id 9460E33C5C; Tue, 22 Apr 2003 13:29:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FB4233C66; Tue, 22 Apr 2003 13:29:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a116.home.uni-hannover.de [130.75.232.116]) by moria.seul.org (Postfix) with ESMTP id 7DC1833C5C for ; Tue, 22 Apr 2003 13:29:15 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00663; Tue, 22 Apr 2003 13:58:32 +0200 Message-ID: <20030422135832.07104@thrai.stud.uni-hannover.de> Date: Tue, 22 Apr 2003 13:58:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Yet Another Upload References: <20030420150622.61844@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Apr 22, 2003 at 08:18:35AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Apr 22, 2003 at 08:18:35AM +0200, devik wrote: > > I'm currently doing that, but it's too slow to be done on a regular > > basis (unless you have a server that runs 24/7). > > I can create account on my p2/350 server which is 24/7. Its > cpu load is low so that it might be useful. An account isn't necessary; you can run the tests yourself. But you'll need simulation software to run them. The other problem is that somebody will have to review all the results periodically... BTW: The tests with Vanilla VHDL took 3 days, but they were successful. There were some warnings because there are signed overflows in the testbenches that I was too lazy to avoid ;) It's just the usual `sign surprise', e.g. +128 becomes -128 in 8-bit two's complement representation, and the `to_signed' function complains. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From didi@tau.ac.il Tue Apr 22 21:06:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1987wg-0006O2-00 for ; Wed, 23 Apr 2003 02:17:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 02:17:06 +0200 (CEST) Received: (qmail 31911 invoked by uid 65534); 22 Apr 2003 19:08:37 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 22 Apr 2003 21:08:37 +0200 Received: by moria.seul.org (Postfix) id 1ACC833C66; Tue, 22 Apr 2003 15:08:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 235A233C6A; Tue, 22 Apr 2003 15:08:34 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tau.ac.il (pong.math.tau.ac.il [132.67.8.241]) by moria.seul.org (Postfix) with ESMTP id B2AF433C66 for ; Tue, 22 Apr 2003 15:08:32 -0400 (EDT) Received: (from didi@localhost) by tau.ac.il (8.11.6/8.11.2) id h3MJ61227253 for f-cpu@seul.org; Tue, 22 Apr 2003 22:06:01 +0300 Date: Tue, 22 Apr 2003 22:06:01 +0300 From: Yedidyah Bar-David To: f-cpu@seul.org Subject: [f-cpu] Running long things (was: Re: Yet Another Upload) Message-ID: <20030422190601.GA27210@pong.math.tau.ac.il> References: <20030420150622.61844@thrai.stud.uni-hannover.de> <20030422135832.07104@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030422135832.07104@thrai.stud.uni-hannover.de> User-Agent: Mutt/1.4i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hello, I am a lurker on this list for some years now. I have no knowledge in circuit design, VHDL, etc., but I do read some of the posts and I even understand some of them ... I am a sysadmin in cs.tau, and am in charge of a few tens of machines. Some of them are not too loaded. If it's possible for me to download and install free software and then run it on some of the f-cpu files and report results, I will be happy to do that. It will be even better if such runs can be split to small parts, since most of the machines dual-boot between Linux and Windows (and I do not intend to use them while they are running Windows). Didi On Tue, Apr 22, 2003 at 01:58:32PM +0200, Michael Riepe wrote: > On Tue, Apr 22, 2003 at 08:18:35AM +0200, devik wrote: > > > I'm currently doing that, but it's too slow to be done on a regular > > > basis (unless you have a server that runs 24/7). > > > > I can create account on my p2/350 server which is 24/7. Its > > cpu load is low so that it might be useful. > > An account isn't necessary; you can run the tests yourself. But you'll > need simulation software to run them. The other problem is that > somebody will have to review all the results periodically... > > BTW: The tests with Vanilla VHDL took 3 days, but they were successful. > There were some warnings because there are signed overflows in the > testbenches that I was too lazy to avoid ;) It's just the usual > `sign surprise', e.g. +128 becomes -128 in 8-bit two's complement > representation, and the `to_signed' function complains. > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue Apr 22 19:33:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1987wu-0006O2-00 for ; Wed, 23 Apr 2003 02:17:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 02:17:20 +0200 (CEST) Received: (qmail 28765 invoked by uid 65534); 22 Apr 2003 21:41:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 22 Apr 2003 23:41:36 +0200 Received: by moria.seul.org (Postfix) id 13B5533C6A; Tue, 22 Apr 2003 17:41:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DF64233C6B; Tue, 22 Apr 2003 17:41:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a051.home.uni-hannover.de [130.75.232.51]) by moria.seul.org (Postfix) with ESMTP id 4011E33C6A for ; Tue, 22 Apr 2003 17:41:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id TAA00529; Tue, 22 Apr 2003 19:33:27 +0200 Message-ID: <20030422193327.40352@thrai.stud.uni-hannover.de> Date: Tue, 22 Apr 2003 19:33:27 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Alternative ROP2 Implementation References: <20030421193806.08593@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Tue, Apr 22, 2003 at 01:20:54PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Tue, Apr 22, 2003 at 01:20:54PM +0200, devik wrote: > > The fcpu-mr-rop2-20030421.tar.gz package (second attachment) contains a > > rewrite of the ROP2 unit that supports all instructions mentioned above, > > as well as combine mode up to a chunk size of 64 bits (but only for the > > ordinary logical operators, not for bitop -- I doubt that it makes sense > > for them). Latency is critical in combine mode (I had to violate the > > 6G rule again, but I still obey the 10T rule), therefore I'd like to > > receive synthesis and speed reports. > > I have not older rop2 sources. Thus one uses > 556 slices and runs at 50.0 MHz. In the small or the bigger FPGA? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Apr 23 04:57:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198F56-0003Wx-00 for ; Wed, 23 Apr 2003 09:54:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 09:54:16 +0200 (CEST) Received: (qmail 16111 invoked by uid 65534); 23 Apr 2003 02:54:47 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 23 Apr 2003 04:54:47 +0200 Received: by moria.seul.org (Postfix) id 191D333C77; Tue, 22 Apr 2003 22:54:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 20B8433C75; Tue, 22 Apr 2003 22:54:43 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id 22D4433B68 for ; Tue, 22 Apr 2003 22:54:42 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-4.n.club-internet.fr [213.44.18.4]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 7F85A171B for ; Wed, 23 Apr 2003 04:54:40 +0200 (CEST) Message-ID: <3EA60110.5000508@f-cpu.org> Date: Wed, 23 Apr 2003 04:57:20 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Running long things (was: Re: Yet Another Upload) References: <20030420150622.61844@thrai.stud.uni-hannover.de> <20030422135832.07104@thrai.stud.uni-hannover.de> <20030422190601.GA27210@pong.math.tau.ac.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N hi ! there is some scripting work in perspective .... Yedidyah Bar-David wrote: >Hello, > >I am a lurker on this list for some years now. I have no knowledge in >circuit design, VHDL, etc., but I do read some of the posts and I even >understand some of them ... > >I am a sysadmin in cs.tau, and am in charge of a few tens of machines. >Some of them are not too loaded. > >If it's possible for me to download and install free software and then >run it on some of the f-cpu files and report results, I will be happy >to do that. > > it could also be used to testbench the software, so we'd need the description of the machines (if you go further). today's computer have big differences and can show a 10x runtime difference with the same software .... Concerning the installation of Free Software, you can read the VHDL_HOWTO that is available in the F-CPU source tarball. you will have to read the chapters about Simili and Vanilla, and if you are successful, try to install GHDL. >It will be even better if such runs can be split to small parts, since >most of the machines dual-boot between Linux and Windows (and I do not >intend to use them while they are running Windows). > > small parts ? i don't know what this means in this context. Some tests last 10 seconds, but Michael's tests are usually extremely long with Vanilla (which itself is already slow software). thank you for your help, > Didi > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed Apr 23 10:13:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198LOI-00089D-00 for ; Wed, 23 Apr 2003 16:38:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 16:38:30 +0200 (CEST) Received: (qmail 29279 invoked by uid 65534); 23 Apr 2003 12:15:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 23 Apr 2003 14:15:46 +0200 Received: by moria.seul.org (Postfix) id 0A8CE33C53; Wed, 23 Apr 2003 08:15:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CE8E233C68; Wed, 23 Apr 2003 08:15:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 9ADB833C53 for ; Wed, 23 Apr 2003 08:15:40 -0400 (EDT) Received: from a83-137.dialup.iol.cz ([194.228.137.83] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 198JA1-0004CQ-00 for f-cpu@seul.org; Wed, 23 Apr 2003 14:15:38 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 198FNM-00018J-00 for f-cpu@seul.org; Wed, 23 Apr 2003 10:13:08 +0200 Date: Wed, 23 Apr 2003 10:13:08 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Alternative ROP2 Implementation In-Reply-To: <20030422193327.40352@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N it is for xc2s300e-pq208-6, thus the faster (bigger) one. On Tue, 22 Apr 2003, Michael Riepe wrote: > On Tue, Apr 22, 2003 at 01:20:54PM +0200, devik wrote: > > > The fcpu-mr-rop2-20030421.tar.gz package (second attachment) contains a > > > rewrite of the ROP2 unit that supports all instructions mentioned above, > > > as well as combine mode up to a chunk size of 64 bits (but only for the > > > ordinary logical operators, not for bitop -- I doubt that it makes sense > > > for them). Latency is critical in combine mode (I had to violate the > > > 6G rule again, but I still obey the 10T rule), therefore I'd like to > > > receive synthesis and speed reports. > > > > I have not older rop2 sources. Thus one uses > > 556 slices and runs at 50.0 MHz. > > In the small or the bigger FPGA? > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From didi@tau.ac.il Wed Apr 23 20:09:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198R7r-0004Gd-00 for ; Wed, 23 Apr 2003 22:45:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Apr 2003 22:45:55 +0200 (CEST) Received: (qmail 2717 invoked by uid 65534); 23 Apr 2003 18:12:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 23 Apr 2003 20:12:39 +0200 Received: by moria.seul.org (Postfix) id 22FF133B52; Wed, 23 Apr 2003 14:12:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 89D2933B55; Wed, 23 Apr 2003 14:12:34 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tau.ac.il (pong.math.tau.ac.il [132.67.8.241]) by moria.seul.org (Postfix) with ESMTP id D113733B52 for ; Wed, 23 Apr 2003 14:12:32 -0400 (EDT) Received: (from didi@localhost) by tau.ac.il (8.11.6/8.11.2) id h3NI9wU29001 for f-cpu@seul.org; Wed, 23 Apr 2003 21:09:58 +0300 Date: Wed, 23 Apr 2003 21:09:58 +0300 From: Yedidyah Bar-David To: f-cpu@seul.org Subject: Re: [f-cpu] Running long things (was: Re: Yet Another Upload) Message-ID: <20030423180958.GA28942@pong.math.tau.ac.il> References: <20030420150622.61844@thrai.stud.uni-hannover.de> <20030422135832.07104@thrai.stud.uni-hannover.de> <20030422190601.GA27210@pong.math.tau.ac.il> <3EA60110.5000508@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA60110.5000508@f-cpu.org> User-Agent: Mutt/1.4i Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N Hi, On Wed, Apr 23, 2003 at 04:57:20AM +0200, Yann Guidon wrote: > hi ! > > there is some scripting work in perspective .... I am not sure I understand. "scripting work" to automate such tests? [snip] > > > it could also be used to testbench the software, so we'd need the > description of the machines > (if you go further). today's computer have big differences and can show > a 10x runtime difference > with the same software .... About 30 dual PIII 500Mhz 256MB, about 30 PIII 733Mhz 256MB, about 20 dual PIII 600Mhz 1-2GB RAM (these are meant for big memory stuff), about 20 PIII 1000Mhz 256MB, about 10 (our newest) PIV 2000Mhz 512MB RDRAM (these are usually the most loaded). Of course we also have some other, non-public (high uptime) machines. devik said he has a p2-350. If that represents the average machine of a f-cpu developer, I guess I can help even with few stronger ones. I guess this might be close to reality, since until a few weeks ago my strongest home machine was a Celeron 300Mhz 128MB (sometimes OCed to 450). Now my strongest is a duron 900Mhz, also not such a strong machine. > > Concerning the installation of Free Software, you can read the > VHDL_HOWTO that > is available in the F-CPU source tarball. you will have to read the > chapters about > Simili and Vanilla, and if you are successful, try to install GHDL. I Will try. Where is the latest tarball? Is there already a fixed place for this? > > >It will be even better if such runs can be split to small parts, since > >most of the machines dual-boot between Linux and Windows (and I do not > >intend to use them while they are running Windows). > > > > > small parts ? > i don't know what this means in this context. > Some tests last 10 seconds, but Michael's tests are usually extremely > long with Vanilla > (which itself is already slow software). I guess you won't need my help for the 10 seconds stuff. What I hope is that the long stuff (e.g. above an hour) can be cut to e.g. 1 hour parts without too much overhead. This way, if a machine is rebooted in the middle of such a 1 hour job, we lose at most 1 hour, and with a sufficiently good batch scheduler (a hand-written script or something like PBS which we already use) resubmit it without manual intervention. > > thank you for your help, > > > Didi > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ Didi ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 24 00:38:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198aSN-0002Mu-00 for ; Thu, 24 Apr 2003 08:43:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 24 Apr 2003 08:43:43 +0200 (CEST) Received: (qmail 13572 invoked by uid 65534); 23 Apr 2003 22:47:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 24 Apr 2003 00:47:08 +0200 Received: by moria.seul.org (Postfix) id D064733B7B; Wed, 23 Apr 2003 18:47:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D587333C68; Wed, 23 Apr 2003 18:47:04 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a181.home.uni-hannover.de [130.75.232.181]) by moria.seul.org (Postfix) with ESMTP id 84AFD33B7B for ; Wed, 23 Apr 2003 18:47:01 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02855; Thu, 24 Apr 2003 00:38:56 +0200 Message-ID: <20030424003856.14456@thrai.stud.uni-hannover.de> Date: Thu, 24 Apr 2003 00:38:56 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Running long things (was: Re: Yet Another Upload) References: <20030420150622.61844@thrai.stud.uni-hannover.de> <20030422135832.07104@thrai.stud.uni-hannover.de> <20030422190601.GA27210@pong.math.tau.ac.il> <3EA60110.5000508@f-cpu.org> <20030423180958.GA28942@pong.math.tau.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030423180958.GA28942@pong.math.tau.ac.il>; from Yedidyah Bar-David on Wed, Apr 23, 2003 at 09:09:58PM +0300 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Wed, Apr 23, 2003 at 09:09:58PM +0300, Yedidyah Bar-David wrote: [...] > > Some tests last 10 seconds, but Michael's tests are usually extremely > > long with Vanilla > > (which itself is already slow software). > > I guess you won't need my help for the 10 seconds stuff. What I hope > is that the long stuff (e.g. above an hour) can be cut to e.g. 1 hour > parts without too much overhead. This way, if a machine is rebooted > in the middle of such a 1 hour job, we lose at most 1 hour, and with > a sufficiently good batch scheduler (a hand-written script or something > like PBS which we already use) resubmit it without manual intervention. I already considered checkpointing: Whenever a testbench has reached a certain milestone (let's say every 1000 operations), it could write the current status to a file so that it can `roll forward' the simulation and restart from the checkpoint. With a zoo of machines, I'd prefer the `f-cpu@home' approach: Cut the testbenches in small slices and execute them in parallel. The slices must not be too small, however -- simulation setup time is rather long. Unfortunately, both approaches require another kind of testbench which is particularly hard to write. Using a vector file isn't an option either -- these files can become really huge (yes, I tried it). You would need a second program that generates the vectors on the fly -- and then you'll again have what we have now, just separated into two processes (which is not necessarily faster than a single process, even on a dual machine). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu Apr 24 11:09:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198mLP-00035h-00 for ; Thu, 24 Apr 2003 21:25:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 24 Apr 2003 21:25:19 +0200 (CEST) Received: (qmail 6672 invoked by uid 65534); 24 Apr 2003 15:50:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 24 Apr 2003 17:50:27 +0200 Received: by moria.seul.org (Postfix) id CBF0433C89; Thu, 24 Apr 2003 11:50:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6B5A33C8C; Thu, 24 Apr 2003 11:50:23 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id BEC1533C89 for ; Thu, 24 Apr 2003 11:50:22 -0400 (EDT) Received: from a39-137.dialup.iol.cz ([194.228.137.39] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 198izH-0000e9-00 for f-cpu@seul.org; Thu, 24 Apr 2003 17:50:15 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 198cjs-0001kM-00 for f-cpu@seul.org; Thu, 24 Apr 2003 11:09:56 +0200 Date: Thu, 24 Apr 2003 11:09:56 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Running long things (was: Re: Yet Another Upload) In-Reply-To: <20030424003856.14456@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N By the way, I never looked at simulators, why are some "slow" and some fast ? I'd expect to compile VHDL code to be "executable", map bitvectors to cpu registers and run processes. Maybe is there difference that better simulator knows how to "collapse" several vhdl statements to be run by fewer cpu insns ? Or are there problems with multivalued types (std_[u]logic) ? devik On Thu, 24 Apr 2003, Michael Riepe wrote: > On Wed, Apr 23, 2003 at 09:09:58PM +0300, Yedidyah Bar-David wrote: > [...] > > > Some tests last 10 seconds, but Michael's tests are usually extremely > > > long with Vanilla > > > (which itself is already slow software). ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu Apr 24 20:08:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 198rAd-0006qe-00 for ; Fri, 25 Apr 2003 02:34:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 25 Apr 2003 02:34:31 +0200 (CEST) Received: (qmail 2724 invoked by uid 65534); 24 Apr 2003 22:26:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 25 Apr 2003 00:26:58 +0200 Received: by moria.seul.org (Postfix) id 465D833B49; Thu, 24 Apr 2003 18:26:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4273D33C8C; Thu, 24 Apr 2003 18:26:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a101.home.uni-hannover.de [130.75.232.101]) by moria.seul.org (Postfix) with ESMTP id ECBC633B49 for ; Thu, 24 Apr 2003 18:26:45 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA04001; Thu, 24 Apr 2003 20:08:56 +0200 Message-ID: <20030424200856.23953@thrai.stud.uni-hannover.de> Date: Thu, 24 Apr 2003 20:08:56 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Running long things (was: Re: Yet Another Upload) References: <20030424003856.14456@thrai.stud.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Thu, Apr 24, 2003 at 11:09:56AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N On Thu, Apr 24, 2003 at 11:09:56AM +0200, devik wrote: > By the way, I never looked at simulators, why are some "slow" > and some fast ? > I'd expect to compile VHDL code to be "executable", map bitvectors > to cpu registers and run processes. As with any other language, you can compile or interpret the code, or compile for a virtual machine (like Simili does). Vanilla seems to be an interpreter (very slow), Alliance creates intermediate C code, IIRC. Some tools may also compile VHDL to machine code internally and execute the result directly from memory. > Maybe is there difference that better simulator knows how to > "collapse" several vhdl statements to be run by fewer cpu insns ? > > Or are there problems with multivalued types (std_[u]logic) ? That's just a matter of clever encoding, I guess. Although it will probably always be slower than binary logic (bit and bit_vector). You can put at most 8 std_ulogic values into a 32-bit word... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ridafe@casino.com Fri Apr 25 05:20:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1990n1-0005U4-01 for ; Fri, 25 Apr 2003 12:50:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 25 Apr 2003 12:50:47 +0200 (CEST) Received: (qmail 10847 invoked by uid 65534); 25 Apr 2003 03:20:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 25 Apr 2003 05:20:36 +0200 Received: by moria.seul.org (Postfix) id E3B0133B75; Thu, 24 Apr 2003 23:20:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CE89933C8F; Thu, 24 Apr 2003 23:20:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail1.chek.com (barney.synacor.com [208.197.227.8]) by moria.seul.org (Postfix) with SMTP id 2A72D33B75 for ; Thu, 24 Apr 2003 23:20:27 -0400 (EDT) Received: (qmail 22215 invoked by uid 0); 25 Apr 2003 03:20:26 -0000 Received: from confucius.synacor.com (10.10.6.10) by mailrelay2.synacor.com with SMTP; 25 Apr 2003 03:20:26 -0000 Received: (qmail 433 invoked by uid 99); 25 Apr 2003 03:20:25 -0000 Date: 25 Apr 2003 03:20:25 -0000 Message-ID: <20030425032025.432.qmail@confucius.synacor.com> From: "richard dafe" To: ridafe10@yahoo.com X-Originating-IP: [81.23.204.210] Subject: [f-cpu] Your Inheritance Mime-version: 1.0 X-MASSMAIL: 1.0 X-MASSMAIL: precedence.bulk Content-Type: multipart/alternative; boundary="=====================_889472414==_" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --=====================_889472414==_ Content-Type: text/plain Content-Transfer-Encoding: 8bit Dr. Richard Dafe Branch Manager EcoBank International. Idumota Branch Lagos Nigeria. I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines). On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it. According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address. I do urgently await your response. Best regards, Dr. Richard Dafe. --=====================_889472414==_ Content-Type: text/html Content-Transfer-Encoding: 8bit

Dr. Richard Dafe
Branch Manager
EcoBank International.
Idumota Branch
Lagos Nigeria.


I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil
consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines).

On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it.

According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction.

If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the
transaction.

Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address.

I do urgently await your response.

Best regards,

Dr. Richard Dafe.



--=====================_889472414==_-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tunde5williams@ny.com Sat Apr 26 08:12:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199OD8-0006Xr-00 for ; Sat, 26 Apr 2003 13:51:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 13:51:18 +0200 (CEST) Received: (qmail 2902 invoked by uid 65534); 26 Apr 2003 05:14:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 26 Apr 2003 07:14:11 +0200 Received: by moria.seul.org (Postfix) id 94D3F33B5F; Sat, 26 Apr 2003 01:14:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8865633C90; Sat, 26 Apr 2003 01:14:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E01C833B5F for ; Sat, 26 Apr 2003 01:14:06 -0400 (EDT) Received: from 2mails2101.com (unknown [216.147.152.43]) by belegost.mit.edu (Postfix) with SMTP id 8DD0E121A39 for ; Sat, 26 Apr 2003 01:12:30 -0400 (EDT) From: "Engr. Tunde Williams" To: f-cpu@seul.org Date: Sat, 26 Apr 2003 07:12:34 +0100 Subject: [f-cpu] Urgent Overture X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030426051230.8DD0E121A39@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >From The Desk Of Engr=2E Tunde Williams Chartered Engineering Division F=2EM=2EW=2EH Garki-Abuja Dear Friend=2C PARNERSHIP OVERTURE Pardon the abruptness of this letter it is due to its exigency I Am Engr=2E Tunde Williams an Engineer with the Federal Ministry of Works and Housing =28FMWH=29=2C and I Head A Five Man tender Board in charge of contract review and payment approvals=2C I came to know of you in my search for a reliable and reputable person to handle a confidential transaction=2E I am representing a caucus in dire need of a foreign partner to assist in investment of US$17=2E85M=28Seventeen Million Eight Hundred and Fifty Million United States Dollars Only=29=2E At the first instance the key issues are the transfer and the subsequent investment of the said sum=2E You know this will require a great amount of trust Considering the amount of money involve=2C my principals are ready to go into an agreement with you=2C plus offer you a negotiable fee for putting together portfolio for investment=2C all we need is your trustworthiness and your ability to work according to our Instructions=2E Please note that we shall go through the legal procedures entails in our law and international law in transfer this funds to you=2C the source of the money is authoritative=2E Please contact me for further details for us to proceed in ernest=2E Awaiting your prompt response Thank you and God Bless Engr=2E Tunde Williams ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tunde5williams@ny.com Sat Apr 26 08:14:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199OD8-0006Xr-01 for ; Sat, 26 Apr 2003 13:51:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 13:51:18 +0200 (CEST) Received: (qmail 27538 invoked by uid 65534); 26 Apr 2003 05:14:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Apr 2003 07:14:46 +0200 Received: by moria.seul.org (Postfix) id 65FA733C90; Sat, 26 Apr 2003 01:14:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9A0233C93; Sat, 26 Apr 2003 01:14:43 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id EC19A33C90 for ; Sat, 26 Apr 2003 01:14:41 -0400 (EDT) Received: from helimore379.com (unknown [216.147.152.43]) by belegost.mit.edu (Postfix) with SMTP id B2429121A39 for ; Sat, 26 Apr 2003 01:14:38 -0400 (EDT) From: "Engr. Tunde Williams" To: f-cpu@seul.org Date: Sat, 26 Apr 2003 07:14:40 +0100 Subject: [f-cpu] Urgent Overture X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030426051438.B2429121A39@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N >From The Desk Of Engr=2E Tunde Williams Chartered Engineering Division F=2EM=2EW=2EH Garki-Abuja Dear Friend=2C PARNERSHIP OVERTURE Pardon the abruptness of this letter it is due to its exigency I Am Engr=2E Tunde Williams an Engineer with the Federal Ministry of Works and Housing =28FMWH=29=2C and I Head A Five Man tender Board in charge of contract review and payment approvals=2C I came to know of you in my search for a reliable and reputable person to handle a confidential transaction=2E I am representing a caucus in dire need of a foreign partner to assist in investment of US$17=2E85M=28Seventeen Million Eight Hundred and Fifty Million United States Dollars Only=29=2E At the first instance the key issues are the transfer and the subsequent investment of the said sum=2E You know this will require a great amount of trust Considering the amount of money involve=2C my principals are ready to go into an agreement with you=2C plus offer you a negotiable fee for putting together portfolio for investment=2C all we need is your trustworthiness and your ability to work according to our Instructions=2E Please note that we shall go through the legal procedures entails in our law and international law in transfer this funds to you=2C the source of the money is authoritative=2E Please contact me for further details for us to proceed in ernest=2E Awaiting your prompt response Thank you and God Bless Engr=2E Tunde Williams ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sb39@orient-sky.com Sat Apr 26 08:29:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199ODK-0006Xr-01 for ; Sat, 26 Apr 2003 13:51:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 13:51:30 +0200 (CEST) Received: (qmail 16565 invoked by uid 65534); 26 Apr 2003 06:27:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 26 Apr 2003 08:27:23 +0200 Received: by moria.seul.org (Postfix) id 4ED2633C91; Sat, 26 Apr 2003 02:27:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 48F9033C8D; Sat, 26 Apr 2003 02:27:21 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from orient-sky.com (p1033-ipad02fukuokachu.fukuoka.ocn.ne.jp [61.207.246.33]) by moria.seul.org (Postfix) with ESMTP id 4806033B81 for ; Sat, 26 Apr 2003 02:27:19 -0400 (EDT) Received: (from info@localhost) by orient-sky.com (8.11.6/8.11.6) id h3Q6T7U13092 for f-cpu@seul.org; Sat, 26 Apr 2003 15:29:07 +0900 Date: Sat, 26 Apr 2003 15:29:07 +0900 Message-Id: <200304260629.h3Q6T7U13092@orient-sky.com> To: f-cpu@seul.org From: =?iso-2022-jp?B?GyRCIzMyLzFfJFgkTjBsSmIbKEI=?= Subject: [f-cpu] =?iso-2022-jp?B?GyRCISFMJD41Qno5LTlwIXYjMzIvMV8kWCROMGxKYhsoQg==?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N $B!c;v6H5$j@lMQ(B $BFMA3$NG[?.$4MFe$2$^$9(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B!!!!!!$"$N;~!"!"#12/1_0J>e$"$C$?$i(B $B!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!$"$N;~!"J]>Z>Z7t$GJ]>Z$N8*Be$o$j$7$F$$$?$i(B $B!!!!!!!!!!!!!!(B $B!!!!!!!!:#$O!":G9b$G!"$h$j0J>e$KK-$+$J?M@8$J$N$K(B $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!#32/1_$X$N0lJb(B $B!!!!!!!!!y"f"f"f"f"f!z"f"f"f"f"f!y"f"f"f"f"f!z"f"f"f"f"f!y(B $B!zJ]>Z;v6H$KIT67$J$7!&J]>Z$KG:$s$G$$$k?M$O!"B?$$$+$i!#(B3$B@iK|$0$i(B $B!!$$M_$7$$?M$OBgB??t$@$+$i!"<+J,$GJ]>Z8\Ld$K$J$j!"(B2$B2/!"(B3$B2/!"(B5$B2/(B9$B@i(B $BK|1_3MF@Z5r$+$i!&>Z5r$OJ*E*>Z5r!&13$D$-$^$;$s!&qY$5$l$?$/$J$$(B $B?M$O>Z5r$r!*(B $B!!!!!!!z"f"f"f"f"f!y"f"f"f"f"f!z"f"f"f"f"f!y"f"f"f"f!z(B $B!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!!!!!:#$+$i$G$bCY$/$"$j$^$;$s!*!*(B $B:#$,@d9%$N%A%c%s%9!*IT67$@$+$iDI$$Iw$N!VJ]>Z:_Bp8\Ld!aE9J^IT(B $BMW$N%3%s%S%KE9$N%*!<%J!<$HF1$8!W$K!*>Z5r3NG'>)Ne!">Z5rL5$7$O;v(B $BZ5r$r3NG'$7$F2<$5$$!#(B (I"$B>^6b#1#2#0K|1_%W%i%9(B=$B#7#4#4K|1_(I#$B$N8"Mx$r!*?M?t@hCe=g@)8B$K$D$-!"(B $B;j5^;qNA$r@A5a$7$F$/$@$5$$!*(B $B!!!!!!!!(B $B!!!!!!!!!|(B $B2?;v$b>Z5r$,0lHV$K;vZL@(B $B!!!|(B $B$=$NCf$G$bJ*E*>Z5r$,4V0c$$$J$$$N$O<~CN$NDL$j$G$9!#(B $BJ]>Zkz7t$GJ]>Z$NHa7`$rKI$0;v6H$G$9!#(B $BZ$N@UG$$O$9$Y$?Z$N%j%9%/$O0l@Z$"$j$^$;$s!"$40B?4$r!#(B $B8\Ld8xG'HV9f$r;H$&$N$G$"$J$?$NL>A0$OC/$K$bCN$i$l$:$K=PMh$^$9!#(B $B!|$3$A$i$+$i(B $B!!(Bhttp://orient-sky.com/ $B!!L5NA$N(B $B;qNA$4@A5a$G$-$^$9!#(B $B!}8D?M!":_Bp!"7s6H$G!"#22/1_!"#32/1_!"#52/#9@iK|1_$N<}F~Z(B $B!!5rM-$j$^$9!&8+$;$^$9!&2?;v$bqY$5$l$?$/$J$$0Y$K@'Hs!">Z5r$N3NG'(B $B!!!z(B--$B!z(B--$B!~(B--$B!z!!%M%C%H%P%V%k$NJx2u$N8=67!!!z(B--$B!~(B--$B!z(B--$B!~(B $B!|%M%C%H%S%8%M%9$G!V8D?M$NG/<}#5@iK|1_0J2<$NJ}!9!W$O!V6%AhAjj6HZ>Z7tH/9TJ]>Z0z$-Z>Z7t$GJ]>Z$NHa7`$r8*Be$o$j$9$k#1#5Z7t!a>Z7tJ]>Z%5!<%S%9(B $B!W$r>Z$7$F$$$k$N$OF|K\$GM#0l!"Ev(B $BJ]>ZZ>Z7t;v6H!I$O!">&9f!aJ]>Z:_Bp;v(B $B!!6H8\!!Ld!&J]>Z6(2qD9!JE9J^!";vL3=jITMW$N%3%s%S%KE9$N%*!<%J!<$H(B $B!!F1MM!K$O!"!!M=Dj!"4uK>!"L4Ey$r%*!<%P!<$7$?<}F~>Z5r$NM}M3$OC1=c(B $B!!$G$9!#(B $B!!%M%C%H%P%V%k!J<{MW$h$j6!5ku0];}!"IT7J5$BP:v!K$,M_$7$$?M$,!"%P%V%kJx(B $B!!2u#1#2G/0J>e7QB3$7$FA}2C$7$F$$$k$+$i$G$9!#(B $B!|$3$A$i$+$i(B $B!!(Bhttp://orient-sky.com/ $B!!L5NA$N(B $B;qNA$4@A5a$G$-$^$9!#(B ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Sat Apr 26 14:17:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199V0x-0002sk-00 for ; Sat, 26 Apr 2003 21:07:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 21:07:11 +0200 (CEST) Received: (qmail 22199 invoked by uid 65534); 26 Apr 2003 12:17:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 26 Apr 2003 14:17:06 +0200 Received: by moria.seul.org (Postfix) id 872E433B6C; Sat, 26 Apr 2003 08:17:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B30CD33C8D; Sat, 26 Apr 2003 08:17:02 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 5C28F33B6C for ; Sat, 26 Apr 2003 08:17:01 -0400 (EDT) Received: from 73.17.19.26 (f-tokyo-132201.zero.ad.jp [211.130.132.201]) by belegost.mit.edu (Postfix) with SMTP id 8BF76121A36 for ; Sat, 26 Apr 2003 08:16:58 -0400 (EDT) From: =?iso-2022-jp?q?=93D=96=5F=82=C7=82=EB=82=DA=81@belegost.mit.edu, "[=83h=83=8D=83{=81[_?=]"@belegost.mit.edu To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81=A1=93D=96=5F=8Es=8F=EA=81=A8=8BM=8B=E0=91=AE=81EPC=81E=83f=83W=83J=83=81=82=AA=92=B4=92=B4=8C=83=88=C0=81=A1?= Date: Sat, 26 Apr 2003 21:17:25 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e48145a9-74fa-4471-84f1-5d6b66536a11" Message-Id: <20030426121658.8BF76121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N This is a multi-part message in MIME format --e48145a9-74fa-4471-84f1-5d6b66536a11 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =83h=83=8D=83{=81[=8Es=8F=EA=96{=93=FA=8C=C0=82=E8=82=CC=8AJ=8D=C3 =88=C5=83=8B=81[=83g=82=A9=82=E7=82=CC=93=FC=8E=E8=95i=82=C9=82=C2=82=AB=90= M=82=B6=82=E7=82=EA=82=C8=82=A2=8C=83=88=C0 1=93_=82=E0=82=CC=91=BD=82=B5=81I=94=84=90=D8=82=EA=83S=83=81=83=93=81B=82=B7= =82=AE=82=C9=83A=83N=83Z=83X=81I http://stealer-jp.0catch.com/ http://book-i.net/stealer/ http://stealer-jp.bravepages.com/ http://www.psend.com/users/stealer/ =81=9APC=81=A8=83=81=83r=83E=83XPC-MM1-H3W=81@20,000=89~ =81=9A=83f=83W=83J=83=81=81=A8EXILIM ZOOM=81@12,000=89~ =81=9A=91=E5=90l=8BC=8Cg=91=D1=82=B7=82=D7=82=C41=96=9C=89~=88=C8=89=BA =81=9A=8BM=8B=E0=91=AE=81A=8D=E0=95z=81A=8E=9E=8Cv=81@=82=C8=82=C7=82=B7=82=D7= =82=C4=92=B4=8C=83=88=C0 =81=9F=8C=83=88=C0=83N=83=89=83u=89=EF=88=F5=82=E0=91=E5=95=E5=8FW=81=9F --e48145a9-74fa-4471-84f1-5d6b66536a11-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ridafe@casino.com Sat Apr 26 15:34:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199V10-0002sk-01 for ; Sat, 26 Apr 2003 21:07:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 21:07:14 +0200 (CEST) Received: (qmail 4893 invoked by uid 65534); 26 Apr 2003 13:34:21 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 26 Apr 2003 15:34:21 +0200 Received: by moria.seul.org (Postfix) id 86AD033C95; Sat, 26 Apr 2003 09:34:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8158C33C94; Sat, 26 Apr 2003 09:34:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail1.chek.com (barney.synacor.com [208.197.227.8]) by moria.seul.org (Postfix) with SMTP id 47C8133C8D for ; Sat, 26 Apr 2003 09:34:19 -0400 (EDT) Received: (qmail 2423 invoked by uid 0); 26 Apr 2003 13:34:18 -0000 Received: from rousseau.synacor.com (10.10.6.20) by mailrelay2.synacor.com with SMTP; 26 Apr 2003 13:34:18 -0000 Received: (qmail 4951 invoked by uid 99); 26 Apr 2003 13:34:14 -0000 Date: 26 Apr 2003 13:34:14 -0000 Message-ID: <20030426133414.4950.qmail@rousseau.synacor.com> From: "richard dafe" To: ridafe@casino.com X-Originating-IP: [81.23.204.210] Subject: [f-cpu] Your Inheritance Mime-version: 1.0 X-MASSMAIL: 1.0 X-MASSMAIL: precedence.bulk Content-Type: multipart/alternative; boundary="=====================_889472414==_" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N --=====================_889472414==_ Content-Type: text/plain Content-Transfer-Encoding: 8bit Dr. Richard Dafe Branch Manager EcoBank International. Idumota Branch Lagos Nigeria. I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines). On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it. According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address. I do urgently await your response. Best regards, Dr. Richard Dafe. --=====================_889472414==_ Content-Type: text/html Content-Transfer-Encoding: 8bit

Dr. Richard Dafe
Branch Manager
EcoBank International.
Idumota Branch
Lagos Nigeria.


I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil
consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines).

On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it.

According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction.

If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the
transaction.

Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address.

I do urgently await your response.

Best regards,

Dr. Richard Dafe.



--=====================_889472414==_-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From james@hello.com Sat Apr 26 15:47:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 199V15-0002sk-00 for ; Sat, 26 Apr 2003 21:07:19 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 26 Apr 2003 21:07:19 +0200 (CEST) Received: (qmail 31363 invoked by uid 65534); 26 Apr 2003 13:44:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 26 Apr 2003 15:44:36 +0200 Received: by moria.seul.org (Postfix) id B423333C94; Sat, 26 Apr 2003 09:44:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AE2D133C92; Sat, 26 Apr 2003 09:44:33 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 4C7D633B87 for ; Sat, 26 Apr 2003 09:44:33 -0400 (EDT) Received: from localhost.com (unknown [61.174.203.106]) by belegost.mit.edu (Postfix) with SMTP id D22E8121A36 for ; Sat, 26 Apr 2003 09:44:28 -0400 (EDT) From: james@hello.com To: f-cpu@seul.org Date: Sat, 26 Apr 2003 21:47:20 +0800 Subject: [f-cpu] Italian-crafted Rolex - only $65 - $140!! Free SHIPPING!! X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030426134428.D22E8121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N =3Cbody=3E =3Cp class=3D=22MsoNormal=22=3E=3Ci=3E=3Cspan lang=3D=22EN-US=22 style=3D=22font-size=3A 10=2E0pt=3B mso-bidi-font-size=3A 12=2E0pt=22=3E=3Cfont face=3D=22Verdana=22=3Eplease note to send ALL REPLY e-mail direct to me at=3A =3Ca href=3D=22mailto=3AQuestions=40QualityWatchWorld=2Ecom=22=3EQuestions=40QualityWatchWorld=2Ecom=3C=2Fa=3E=3Co=3Ap=3E =3C=2Fo=3Ap=3E =3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fi=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EHi=2C=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EThank you for expressing interest in ATGWS watches=2E=3Cbr=3E We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces=2EYou can view our large selection of Rolexes =28including Breitling=2C Tag Heuer=2C Cartier etc=29 at=3A=3Cbr style=3D=22mso-special-character=3A line-break=22=3E =3Cbr style=3D=22mso-special-character=3Aline-break=22=3E =3Ca href=3D=22http=3A=2F=2Fwww=2Equalitywatchworld=2Ecom=2F=22=3Ewww=2EQualityWatchWorld=2Ecom=3C=2Fa=3E=3Co=3Ap=3E =3C=2Fo=3Ap=3E =3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EFor all orders placed in the month of April=2C =3Cb=3Eall shipping and handling charges will be free=3C=2Fb=3E=2E =3B=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EAs we are the direct manufacturers=2C you are guaranteed of lowest prices and highest quality each and every time you purchase from us=2E =3B=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EYou may also be interested to know that we have the following brands available in our wide selection as well=3A=3Cbr=3E 1=2E Leather band Daytona =28ladies and men=A1=AFs=29=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E2=2E Blancpain=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E3=2E Fortis=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E4=2E Jaeger LeCoutre=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E5=2E Longines=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E6=2E Mont Blanc=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E7=2E Movado=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E8=2E Oris=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E9=2E Roger Dubuis=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E10=2E Ulysse=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E11=2E Zenith=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E12=2E Audemar Piguet=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E13=2E Breitling=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E14=2E Bvglari=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E15=2E Cartier=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E16=2E Corum=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E17=2E Dunhill=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E18=2E Franck Muller=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E19=2E Gerard Perregaux=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E20=2E IWC=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E21=2E IWC=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E22=2E Panerai=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E23=2E Patek Philippe=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E24=2E Tag Heuer=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cfont face=3D=22Verdana=22=3E=3Cspan lang=3D=22EN-US=22=3E25=2E Vacheron Constantin=3C=2Fspan=3E=3Cspan lang=3D=22EN-US=22=3E =3B=3C=2Fspan=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3EIf you see anything that might interest you=2C or if you have any questions=2C please don't hesitate to visit our website at=3A=3Ca href=3D=22http=3A=2F=2Fwww=2Equalitywatchworld=2Ecom=2F=22=3Ewww=2EQualityWatchWorld=2Ecom=3C=2Fa=3E =3Cspan style=3D=22mso-spacerun=3A yes=22=3E =3B =3B=3C=2Fspan=3E=3Cbr=3E I certainly look forward to hearing from you=2E=3Cbr=3E Best regards=2C=3Cbr=3E Cal=3Cbr=3E Division Sales Manager=3Cbr=3E ATGWS =3B =3B=3C=2Ffont=3E=3C=2Fspan=3E=3Cfont face=3D=22Verdana=22=3E=3Ci=3E=3Cspan lang=3D=22EN-US=22 style=3D=22font-size=3A 10=2E0pt=3B mso-bidi-font-size=3A 12=2E0pt=22=3E =3B=3C=2Fspan=3E=3C=2Fi=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22 style=3D=22font-size=3A 7=2E5pt=22=3E=3Cfont face=3D=22Verdana=22=3EYou received this email because your have previous purchased from=2C or inquired about our product line under ATGWS=2E If you do not want to receive further mailings from ATGWS=2C unsubscribe by sending an email with the title heading=3A DELETE in the subject line to =3Ca href=3D=22mailto=3AUnsubscribe=40QualityWatchWorld=2Ecom=22=3EUnsubscribe=40QualityWatchWorld=2Ecom=3C=2Fa=3E=3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E =3B=3C=2Ffont=3E=3C=2Fspan=3E=3Cfont face=3D=22Verdana=22=3E=3Ci=3E=3Cspan lang=3D=22EN-US=22 style=3D=22font-size=3A 10=2E0pt=3B mso-bidi-font-size=3A 12=2E0pt=22=3Eplease note to send ALL REPLY e-mail direct to me at=3A =3Ca href=3D=22mailto=3AQuestions=40QualityWatchWorld=2Ecom=22=3EQuestions=40QualityWatchWorld=2Ecom=3C=2Fa=3E=3C=2Fspan=3E=3C=2Fi=3E=3C=2Ffont=3E=3Cspan lang=3D=22EN-US=22=3E=3Cfont face=3D=22Verdana=22=3E =3B=3Co=3Ap=3E =3C=2Fo=3Ap=3E =3C=2Ffont=3E=3C=2Fspan=3E=3C=2Fp=3E =3C=2Fbody=3E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dmmas789@24i.net Mon Apr 28 14:53:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRDW-0000R6-01 for ; Sun, 04 May 2003 23:40:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:40:18 +0200 (CEST) Received: (qmail 30403 invoked by uid 65534); 28 Apr 2003 12:54:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 28 Apr 2003 14:54:23 +0200 Received: by moria.seul.org (Postfix) id 176BC33BDE; Mon, 28 Apr 2003 08:54:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6611B33C09; Mon, 28 Apr 2003 08:54:21 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 235BD33C27 for ; Mon, 28 Apr 2003 08:54:12 -0400 (EDT) Received: from 24i2828.com (f066.ag236.FreeBit.NE.JP [219.109.236.66]) by bettik.munge.net (Postfix) with SMTP id 0F8764F9F8 for ; Mon, 28 Apr 2003 07:54:06 -0500 (CDT) From: 0427oab To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=81I=81I=82=B2=98A=97=8D=81I=81I?= Date: Mon, 28 Apr 2003 21:53:30 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eb510a55-cfe4-4618-bda5-6a13e2788cab" Message-Id: <20030428125406.0F8764F9F8@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --eb510a55-cfe4-4618-bda5-6a13e2788cab Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =82=B1=82=BF=82=E7=82=A9=82=E7=88=EA=95=FB=93I=82=C9=91=97=82=E8=82=C2=82=AF= =82=C4=95s=96=F9=89=F5=82=C9=82=C8=82=E7=82=EA=82=BD=95=FB=81A=90=BD=82=C9=90= \=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1.. =8D=A1=8C=E3=88=EA=90=D8=82=CC=91=97=90M=82=F0=8B=91=94=DB=82=B3=82=EA=82=E9= =95=FB=82=CD=82=A8=8E=E8=90=94=82=C5=82=B7=82=AA=89=BA=8BL=82=CC=83A=83h=83=8C= =83X=82=C9=95=D4=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81B =94z=90M=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=81@netchan123@24i.net =82=DC=82= =BD=82=CD net123re@24i.net =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=8BK=92=E8=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B <=91=97=90M=8E=D2> DMmaster http://dmmster.com <=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B=91=8D=8D=87=8A=E9=89=E6=8E=D0=81= @http://210.136.155.95/ =DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1= :*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K =81w=8DL=8D=90=81x =93=C1=95=CA=8F=EE=95=F1=81I=81I=95K=8C=A9=81I=81I =8C=C0=92=E8=8A=F3=8F=AD=89=BF=92l=8F=A4=95i=82=AA=82=B1=82=CC=89=BF=8Ai=82=C5= =81=F4 =82=DC=82=B8=82=CDHP=82=F0=8C=A9=82=C4=82=AD=82=BE=82=B3=82=A2=81=99 =81=A6=89=BA=8BL=82=CC=82=C7=82=CC=83A=83h=83=8C=83X=82=A9=82=E7=82=C5=82=E0= =82=B2=97=97=82=C9=82=C8=82=EA=82=DC=82=B7 http://210.136.155.95/ http://www.net-channel777.com =81=9D=81@=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA= =82=AA=82=A0=82=E9=82=CC=82=C5=91=81=82=DF=82=C9=8C=A9=82=C9=97=88=82=C4=82=AD= =82=BE=82=B3=82=A2=81=F4 =DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1= :*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K=DF=A5*:.=A1. .=A1.:*=A5=81K =81=A6=8D=A1=8C=E3=82=B1=82=CC=83=81=81[=83=8B=82=F0=8E=F3=90M=8B=91=94=DB=82= =C8=82=B3=82=EA=82=E9=8F=EA=8D=87=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=82=C9= =95=D4=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2=81B =88=C8=8C=E3=88=EA=90=D8=82=CC=94z=90M=82=F0=92v=82=B5=82=DC=82=B9=82=F1=81= I --eb510a55-cfe4-4618-bda5-6a13e2788cab-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From angelkazama@hotmail.com Sun May 4 20:34:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRMz-0000R6-00 for ; Sun, 04 May 2003 23:50:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:50:05 +0200 (CEST) Received: (qmail 25857 invoked by uid 65534); 4 May 2003 18:35:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 04 May 2003 20:35:12 +0200 Received: by moria.seul.org (Postfix) id 4AC3C33C91; Sun, 4 May 2003 14:35:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 139FF33C90; Sun, 4 May 2003 14:35:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from hotmail.com (TC218-187-136-30.adsl.pl.apol.com.tw [218.187.136.30]) by moria.seul.org (Postfix) with ESMTP id 6C96233B81 for ; Sun, 4 May 2003 14:35:08 -0400 (EDT) From: angelkazama@hotmail.com To: f-cpu@seul.org Subject: [f-cpu] ¾÷·|¤ñ§V¤O­«­n Date: 05 May 2003 02:34:42 +0800 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030504183508.6C96233B81@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ¤T¤À¤§¤@ªº¤H¥Í

¡@

                ¤T    ¤À    ¤§    ¤@           ªº     ¤H     ¥Í    
       ¦³¤@­Ó¨q¤~­n¶i¨Ê»°¦Ò¡A¤@¸ô¨«¨Ó¨«¨ì¦¿Ãä·Ç³Æ¹L¦¿¡A©ó¬O¥L©Û¨Ó²î¤Ò´ç¥L¹L¦¿¡A·í²î¨«¨ì¦¿ªº¤T¤À¤§¤@®É¡A³o¦ì¨q¤~¸Ö©Ê¤jµo¡A¶}©l§u¸Ö§@¹ï¡A°á¤F´X­º¸Ö¤§«áı±o«ÜµL½ì¡A©ó¬O¥L°Ý²î¤Ò¡G²î¤Ò§r!§AÀ´¤£À´±o¥v¸Ö¤§¬ü§r¡H   ²î¤Ò»¡¡G§Ú¤@¥Í¥u·|·Æ²î¡A­þÀ´±o¤°»ò¸Ö§r!   ¨q¤~·n·nÀY¼J¯º¥L»¡¡G­ü~~~¤£À´±oªY½à¸Ö¶°¡A§Aªº¤H¥Í¤w¸g¥h¤F¤T¤À¤§¤@¤F¡C   

       ²îºCºCªº¨«¡A¨«¨ì¦¿ªº¤¤¶¡¡A¨q¤~®³¥X¤F¤@°¦²Ã¤l¡A§j°_²Ã¤l¡A³³¾K¦b­µ¼Ö¸Ì¡A§j¤F§j¡A¨q¤~¤S°Ý²î¤Ò¡G¨º²î¤Ò¥ý¥Í§r!§A¤£À´±oªY½à¸Ö¥y¡A¨º§AÁ`¸ÓÀ´±oªY½à¸Ö¦Ë¤§¬ü§a!  ²î¤Ò·n·nÀY»¡¡G§Ú¤@¥Í¥u·|·Æ²î¡A­þÀ´±oªY½à­µ¼Ö¡C¨q¤~¤S¤£®hªº»¡¡G¤£À´±oªY½à­µ¼Ö¡A§Aªº¤H¥Í¤S¥h¤F¤T¤À¤§¤@¤F¡C 

       ¤£ª¾¤£Ä±¤¤¡A²î·Ç³Æ¾a©¤¡A¬ðµM¶¡¡A¤ÑªÅ¯Q¶³±K§G¤U°_¤j«B¡A¦¿¤ôÂrº¦¡A²´¬Ý´N­n§â²îµ¹¥´Â½¤F¡C  ²î¤Ò¶]¨ì²îÀY·Ç³Æ­n¸õ¤U¤ô¡A¬ðµM¶¡¡A²î¤Ò¦^ÀY°Ý¨q¤~¡G¨q¤~¥ý¥Í¡A¨º§A·|¤£·|´åªa©O¡H  ¨q¤~»¡¡G§Ú³o¤@¥Í¹¡Åª¸Ö®Ñ¡AªY½à­µ¼Ö¡A§Ú­þ·|´åªa¡H    ´N¦b²î¤Ò­n¸õ¤U¤ôªº«b¨º¶¡»¡¡G¨º«Ü©êºp¡A§Úªº¤H¥ÍÁÙ¦³¤T¤À¤§¤@¡A§Aªº¤H¥Í§Y±N¥þ³¡³£¥¢¥h¤F¡C

        ¤H¥Íªº¹Lµ{¸Ì¡A¨g­·Ãz«B¤£ª¾¹D¤°»ò®É­Ô·|¨Ó¡A§O¥H¬°§Ú­Ì²{¦bªº¦w¶h´N¥Nªí¥Ã»·ªº¦w¶h¡A¤@¥x¨®¥|­Ó½ü¤l¡A¨S¦³³Æ­L¡A§A´±¤W°ª³t¤½¸ô¶Ü¡H³o¸Ì¦³¤@­Ó³Æ­L¡A§A¨Ó¬Ý¬Ý§a! (½Ð¶i)

¡@

¡@

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hallucination@24i.net Thu May 1 22:08:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRIq-0000R6-00 for ; Sun, 04 May 2003 23:45:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:45:48 +0200 (CEST) Received: (qmail 21261 invoked by uid 65534); 1 May 2003 20:08:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 01 May 2003 22:08:08 +0200 Received: by moria.seul.org (Postfix) id 645AB33C9F; Thu, 1 May 2003 16:08:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DABFD33CA9; Thu, 1 May 2003 16:08:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 62A8333C9F for ; Thu, 1 May 2003 16:08:05 -0400 (EDT) Received: from 24i30.com (f066.ag236.FreeBit.NE.JP [219.109.236.66]) by belegost.mit.edu (Postfix) with SMTP id 5FD95121A36 for ; Thu, 1 May 2003 16:08:04 -0400 (EDT) From: hal1 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=81y=83h=83=89=83b=83O=81z=81Q=8C=B6=8Ao=82=DD=82=BF=82=E1=82=A4!=3F=81=F4=81Q?= Date: Fri, 02 May 2003 05:08:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="df13f8a5-9c11-44bb-8cf8-ff5be6ce3eb0" Message-Id: <20030501200804.5FD95121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --df13f8a5-9c11-44bb-8cf8-ff5be6ce3eb0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8E=D2>=93=FA=96{=83=81=81[=83=8B=91=E3=8Ds=8E=D0 =93=8C=8B=9E=93= s=90V=8Fh=8B=E6=90=BC=90V=8Fh3-14-8=81@=93=FA=96{=83=81=81[=83=8B=91=E3=8Ds=8E= =D0=83r=83=8B5F=81@03-5430-8766 <=8E=96=8B=C6=8E=D2>=83A=83_=83=8B=83g=83V=83=87=83b=83v=81@hallucination=81= @=93=8C=8B=9E=93s=8Fa=92J=8B=E6=93=B9=8C=BA=8D=E21-15-3-407=81@090-6304-3404 =94z=90M=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=81@stop_hallucination@24i.net =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=8BK=92=E8=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B =81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81y=8DL=8D=90=81z=81Q=81= Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q =8C=C0=92=E8=8A=F3=8F=AD=83h=83=89=83b=83O=81I=81I=81I =96=B3=82=AD=82=C8=82=E8=8E=9F=91=E6=94=84=82=E8=90=D8=82=EA=82=C5=82=B7=81I =91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=82=C5=82=B7=81=F4 HP=82=AA=8F=C1=82=A6=82=E9=8B=B0=82=EA=82=AA=82=A0=82=E8=82=DC=82=B7=82=CC=82= =C5=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97=88=82=C4=82=AD=82=BE=82=B3=82=A2=82= =CB=81=99 http://210.150.173.81 --df13f8a5-9c11-44bb-8cf8-ff5be6ce3eb0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From multiple73@korea.com Thu May 1 04:14:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRGb-0000R6-00 for ; Sun, 04 May 2003 23:43:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:43:29 +0200 (CEST) Received: (qmail 13969 invoked by uid 65534); 1 May 2003 02:14:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 01 May 2003 04:14:55 +0200 Received: by moria.seul.org (Postfix) id 4C43133B6A; Wed, 30 Apr 2003 22:14:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A6FC333C29; Wed, 30 Apr 2003 22:14:31 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 421BE33B6A for ; Wed, 30 Apr 2003 22:14:31 -0400 (EDT) Received: (qmail 41684 invoked from network); 1 May 2003 02:15:46 -0000 Received: from unknown (HELO korea.com) (61.99.4.11) by bettik.munge.net with SMTP; 1 May 2003 02:15:46 -0000 From: (ÁÖ) ´Ã¹è¿òÅÍ To: f-cpu@seul.org Subject: [f-cpu] (±¤°í)°¡·Á¿î ¿µ¾î ±Ü¾îµå¸³´Ï´Ù @ Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030501021431.421BE33B6A@moria.seul.org> Date: Wed, 30 Apr 2003 22:14:31 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2003-04-30 ¿ÀÈÄ 9:17:22 ¿¡ archives.seul.org/f-cpu/f-cpu/Feb-2003/msg00010.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.
:::::::::::::::::::::¿µ¾î¼º°ø½ÅÈ­´Â µè±â¿µ¾î ¿ÏÀüÇØ°á¿¡ ÀÖ´Ù. .:::::::::::::::::::::
¼­¿ïƯº°½Ã Á¾·Î±¸ ¿¬Áöµ¿ 204 ´Ã¹è¿òºôµùÀü°ü (ÁÖ)´Ã¹è¿òÅÍ
TEL : (02) 766-0505  
º» ¸ÞÀÏÀº ¹ß¼ÛÀü¿ë ¸ÞÀÏÀÓÀ¸·Î ¿øÄ¡ ¾ÊÀ¸½Ã¸é [¼ö½Å°ÅºÎ]¸¦ Ŭ¸¯ÇØ ÁÖ¼¼¿ä!   
If you wish to be unsubscribed from our mailing list, [unsubscribe]please click unsubscribe!   
Copyright ¨Ï since 2002 Neul Baeumteo co., LTD. All Rights Reserved.
º» ¸ÞÀÏÀº Á¤º¸ Åë½Å¹ý 50Á¶¿¡ ÀÇ°ÅÇÑ ±¤°í¸ÞÀÏ ÀÔ´Ï´Ù.
¸ÞÀÏ ÁÖ¼Ò´Â ÀÎÅͳݿ¡¼­ ¾òÀº °ÍÀÌ¸ç ¸ÞÀÏ ÁÖ¼Ò ¿Ü¿¡ °³ÀÎÀÇ ½Å»ó¿¡ ´ëÇÑ ¾Æ¹«·± Á¤º¸µµ °®°í ÀÖÁö¾Ê½À´Ï´Ù.
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pbrook@caramail.com Sat May 3 10:32:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRLZ-0000R6-00 for ; Sun, 04 May 2003 23:48:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:48:37 +0200 (CEST) Received: (qmail 22325 invoked by uid 65534); 3 May 2003 08:34:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 03 May 2003 10:34:54 +0200 Received: by moria.seul.org (Postfix) id 69F8033B60; Sat, 3 May 2003 04:34:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A9BE33C81; Sat, 3 May 2003 04:34:33 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from caramail.com (pop-zh-8-1-dialup-197.freesurf.ch [194.230.211.197]) by moria.seul.org (Postfix) with ESMTP id 58BAD33B60 for ; Sat, 3 May 2003 04:34:28 -0400 (EDT) From: pbrook@caramail.com To: f-cpu@seul.org Subject: [f-cpu] Votre carte Egg Date: 03 May 2003 10:32:09 +0200 Message-ID: <2003.05.03.10.32.09.5FF116E64406499A@caramail.com> Organization: Foobar Inc. x-delete-me: 1 (this tells our server to delete the message) MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Cliquez sur ce lien pour avoir de plus amples informations sur cette offre

La Carte Egg vous reverse 1% sur tous vos achats, hors retraits d'espèces. Une réserve d'argent permanente : vous pouvez rembourser l'ensemble de vos dépenses chaque mois ou bien étaler vos remboursements. Et à tout moment, vous pouvez changer votre mode de paiement. Un taux actuariel annuel à 9,6%**. Ce taux est le même pour tous, quel que soit le montant utilisé. Votre réserve pourra être comprise entre 500 et 21 500 €**, selon votre profil. Des retraits gratuits si vous décidez de tout rembourser chaque mois. Si vous choisissez d'échelonner vos remboursements, vous paierez des intérêts sur vos retraits d'espèces comme sur vos achats. Pas besoin de changer de banque : le prélèvement est fait chaque mois sur votre compte bancaire habituel. 6 mois offerts : la carte vaut 35 € par an mais les 6 premiers mois sont gratuits si votre demande de souscription est acceptée avant le 31/05/2003.
La carte egg c'est : 1% de cash back
Cliquez sur ce lien pour avoir de plus amples informations sur cette offre


 
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From invesorama-owner@yahoogroups.com Wed Apr 30 00:40:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRFo-0000R6-00 for ; Sun, 04 May 2003 23:42:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:42:40 +0200 (CEST) Received: (qmail 29995 invoked by uid 65534); 30 Apr 2003 17:31:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 30 Apr 2003 19:31:54 +0200 Received: by moria.seul.org (Postfix) id A772A33B5B; Tue, 29 Apr 2003 18:41:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8DBFF33B8A; Tue, 29 Apr 2003 18:41:15 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from n3.grp.scd.yahoo.com (n3.grp.scd.yahoo.com [66.218.66.86]) by moria.seul.org (Postfix) with SMTP id 7582933B5B for ; Tue, 29 Apr 2003 18:41:14 -0400 (EDT) X-eGroups-Return: notify-return-f-cpu=seul.org@returns.groups.yahoo.com Received: from [66.218.67.254] by n3.grp.scd.yahoo.com with NNFMP; 29 Apr 2003 22:40:31 -0000 Received: (qmail 42033 invoked by uid 65534); 29 Apr 2003 22:40:31 -0000 Date: 29 Apr 2003 22:40:31 -0000 Message-ID: <1051656031.7534.41847.w75@yahoogroups.com> MIME-Version: 1.0 From: invesorama moderator To: f-cpu@seul.org Subject: [f-cpu] Invitation to join the invesorama group Content-Type: multipart/alternative; boundary="-----006621262500343433020017340338" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: -------006621262500343433020017340338 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello f-cpu@seul.org, disfrazar@yahoo.com has invited to join the invesorama group hosted by Yahoo! Groups, a free, easy-to-use community service. By joining invesorama, you will be able to exchange messages with other group members, store photos and files, coordinate events and more. This invitation will expire in 7 days. Here's an introductory message from disfrazar@yahoo.com: ------------------------------------------------------------------------ Free Financial Information! Join our group of professionals and receive free information that can and will save your hard earned money! ------------------------------------------------------------------------ JOIN NOW, IT'S EASY: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=mkOBZUBPLM4v4VSUbiJ9G71g86k&e=f-cpu%40seul%2Eorg (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you do not wish to join the invesorama group, please ignore this invitation. SPECIAL NOTE FROM Yahoo! Groups: Because Yahoo! Groups values your privacy, it is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -------006621262500343433020017340338 Content-Type: text/html Content-Transfer-Encoding: 7bit
Yahoo! Groups


disfrazar@yahoo.com has invited you to join the invesorama group!
(This invitation will expire in 7 days.)

A message from disfrazar@yahoo.com:
Free Financial Information! Join our group of professionals and receive free information that can and will save your hard earned money!



About Yahoo! Groups: Yahoo! Groups is a free service that helps you stay in touch with family and friends or meet new people. Yahoo! Groups values your privacy. It is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com. Your use of Yahoo! Groups is subject to our Terms of Service, located at http://docs.yahoo.com/info/terms/.
-------006621262500343433020017340338-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From paulwilliams@bean.net Sat May 3 09:48:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19CRL3-0000R6-00 for ; Sun, 04 May 2003 23:48:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 04 May 2003 23:48:05 +0200 (CEST) Received: (qmail 29645 invoked by uid 65534); 2 May 2003 23:48:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 03 May 2003 01:48:05 +0200 Received: by moria.seul.org (Postfix) id 6EDDF33C80; Fri, 2 May 2003 19:48:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6163133C85; Fri, 2 May 2003 19:48:01 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from localhst2394.com (80.179.103.30.forward.012.net.il [80.179.103.30]) by moria.seul.org (Postfix) with SMTP id 1960633C80 for ; Fri, 2 May 2003 19:47:48 -0400 (EDT) From: "Barrister Paul Williams" To: f-cpu@seul.org Date: Sat, 3 May 2003 00:48:31 -0700 Subject: [f-cpu] NEXT OF KIN (CONTACT ME IMMEDIATELY) X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030502234748.1960633C80@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: PAUL&PAUL ASSOCIATES #30 ADISA BASHUA STREET=2C SURULERE=2C LAGOS - NIGERI phone=3A234-1-7765199 Dear Friend=2C I am Barrister BARRISTER PAUL WILLIAMS=2C a Solicitor=2E I am the Personal Attorney and Legal Representative to =22Mr=2EFischer Benson=22=2C a national of your country=2Cwho used to work with Shell Oil Development Company in Nigeria=2E On the 21st of April 1999=2C my client=2C his wife and their three children were involved in a car accident along Abuja Express Road=2E Unfortunately=2Cthey all lost their lives in the event of the accident=2E Since then=2C I have made several enquiries to your Embassy to locate any of my client's extended relatives=2C this has also proved unsuccessful=2E After these several unsuccessful attempts=2C I decided to trace his relatives over the Internet to locate any member of his family but of no avail=2C hence=2C I contacted you to assist in repartrating the money left behind by my client in EKO BANK NIGERIAN PLC to your country=2E On November 6=2C1998=2C Mr=2ELee Benson made a numbered time =28fixed=29 Deposit for twelve calender month=2C valued at US$25=2C000=2C000=2E00=28twenty five million dollars=29 in Allen Avenue Branch=2E Upon maturity=2C Eko Bank sent a routine notification to me to forward to my client=2E After a month later=2Cthe bank sent a reminder to me=2EI contacted the employer=2C the Nigerian National Petroleum Corporation and made further investigation and discovered that Mr Lee did not declare any kin or relations in all his official documents=2C including his bank Deposit paperwork=2E The sum of US$25=2C000=2C000=2E00 is still in Eko bank and interest is being rolled over with the principal sum at the end of each year=2E No one will ever come forward to claim it=2E According to Nigerian Law=2C at the expiration of five years=2C the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund=2E Consequently=2C my proposal is that I will like you to stand as the next of kin to Mr Lee so that the fruits of this old man's labour will not get into the hands of some corrupt Government officials=2E This is simple=2C I will like you to provide immediately your full names and address so that I will prepare the necessary documents and affidavits which I will put you in place to substanciate that you are the next of kin=2E I will draft his WILL and obtain the necessary documents and letter of probate=2Fadministrationin in your favour for the transfer=2E A bank account in any part of the world which you will provide then will facilitate the transfer of this money to you as the beneficiary=2F next of kin=2E The money will be paid into your account for us to share in the ratio of 60% for me and 40% for you=2E There is no risk involved in this transaction as the paperwork for this transaction will be done by the me and my position as the Personal Attorney and Legal Representative guarantees the succesfull execution=2E if you are interested=2C please reply immediately via the private email address or my fax number 234-09-2721987=2E Upon your response=2C I shall then provide you with more details and relevant documents that will help you understand the transaction=2E please observe utmost confidetiality=2C and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country=2E Please send to me your particulars including your private phone and fax number=2E Awaiting yor urgent reply via email Thanks and Regards=2C Paul Williams=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From smoke55@zero.ad.jp Wed May 7 16:47:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19DZFz-0005KF-00 for ; Thu, 08 May 2003 02:27:31 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 08 May 2003 02:27:31 +0200 (CEST) Received: (qmail 6270 invoked by uid 65534); 7 May 2003 14:48:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 07 May 2003 16:48:00 +0200 Received: by moria.seul.org (Postfix) id E312A33CA3; Wed, 7 May 2003 10:47:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2F80033CFE; Wed, 7 May 2003 10:47:21 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 79.47.19.07 (f-tokyo-133249.zero.ad.jp [211.130.133.249]) by moria.seul.org (Postfix) with SMTP id 07FDA33CF3 for ; Wed, 7 May 2003 10:47:12 -0400 (EDT) From: smoke To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=81=9A=81=9A=82=ED=82=BD=82=B5=81A=94=F2=82=D1=82=DC=82=B7=81I=81=9A=81=9A?= Date: Wed, 07 May 2003 23:47:25 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="f3148a90-673e-4ead-ac2d-f447ff01c972" Message-Id: <20030507144712.07FDA33CF3@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --f3148a90-673e-4ead-ac2d-f447ff01c972 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =81@=81@=81@=81@=81=9A=92g=82=A9=82=AD=82=C8=82=E9=97t=82=C1=82=CF=82=A0=82=E8= =82=DC=82=B7=81=9A =83K=83=93=83W=83=83=81A=83`=83=87=83R=81A=8E=F7=8E=89=81A=83X=83=82=81[=83= N=81Aseeds =93=FA=96{=94=AD=93=FC=89=D7=81A=83A=83w=83=93=97l=83n=81[=83o=83=8B=83X=83=82= =81[=83N =83T=83C=83g=82=AA=8F=C1=82=B3=82=EA=82=BD=82=E7=8FI=97=B9=82=C5=82=B7=81B =90=B8=90_=88=C0=92=E8=8D=DC=91=E3=82=ED=82=E8=82=C9=82=C7=82=A4=82=BC=81I =81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB=81@=81=AB= =81@=81=AB=81@=81=AB http://book-i.net/smoke/ http://www.freewebs.com/smoke123/ http://galileo.spaceports.com/~smoke123/ http://jp.internations.net/smoke123/ http://smoke123.bravepages.com/ --f3148a90-673e-4ead-ac2d-f447ff01c972-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gentei@24i.net Fri May 9 02:48:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Dx6A-0005Yl-01 for ; Fri, 09 May 2003 03:54:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 09 May 2003 03:54:58 +0200 (CEST) Received: (qmail 5238 invoked by uid 65534); 9 May 2003 00:49:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 09 May 2003 02:49:01 +0200 Received: by moria.seul.org (Postfix) id 31D0933B7F; Thu, 8 May 2003 20:48:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4EAE533CF5; Thu, 8 May 2003 20:48:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 24i1008.com (f042.ah098.FreeBit.NE.JP [221.113.98.42]) by moria.seul.org (Postfix) with SMTP id B6EBB33B7F for ; Thu, 8 May 2003 20:48:56 -0400 (EDT) From: cd0508 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=82=A0=82=C8=82=BD=82=CC=92m=82=E7=82=EA=82=B4=82=E9=90=A2=8AE=81E=81E=81E?= Date: Fri, 09 May 2003 09:48:56 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="304d3af6-ebaa-4655-be63-094289e9872b" Message-Id: <20030509004856.B6EBB33B7F@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --304d3af6-ebaa-4655-be63-094289e9872b Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2>=83A=81[=83o=83=93=83V=83X=83e=83=80=81@=93=8C=8B=9E= =93s=90V=8Fh=8B=E6=90V=8Fh4-18-7 3F 03-5372-6639 <=8E=96=8B=C6=8E=D2>net channel =93=8C=8B=9E=93s=8Fa=92J=8B=E6=93=B9=8C=BA=8D= =E21-15-3 090-8130-1117 =94z=90M=92=E2=8E~=83A=83h=83=8C=83X=81@=81@donot@24i.net =94z=90M=92=E2=8E~=82=CD24=8E=9E=8A=D4=8C=E3=82=C9=94=BD=89f=82=B3=82=EA=82=DC= =82=B7=81B =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=8BK=92=E8=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B =81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81`=81= `=81`=81`=81`=81`=81`=81`=81`=81` =82=A0=82=C8=82=BD=82=CC=92m=82=E7=82=EA=82=B4=82=E9=90^=8E=C0=81E=81E=81E =8C=C0=92=E8=93=C1=95=CACD=81I=81I =8F=DA=82=B5=82=AD=82=CDHP=82=C9=82=C4 http://net-channel777.com --304d3af6-ebaa-4655-be63-094289e9872b-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gentei@24i.net Sat May 10 09:33:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19EZZA-0002m2-00 for ; Sat, 10 May 2003 20:59:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 10 May 2003 20:59:28 +0200 (CEST) Received: (qmail 6998 invoked by uid 65534); 10 May 2003 07:33:53 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 10 May 2003 09:33:53 +0200 Received: by moria.seul.org (Postfix) id F014A33B4C; Sat, 10 May 2003 03:33:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B9E033B53; Sat, 10 May 2003 03:33:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 1BC1033B4C for ; Sat, 10 May 2003 03:33:49 -0400 (EDT) Received: from 24i920.com (f057.ah096.FreeBit.NE.JP [221.113.96.57]) by belegost.mit.edu (Postfix) with SMTP id 1691A121A36 for ; Sat, 10 May 2003 03:33:44 -0400 (EDT) From: fuku0508 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=81y=83A=83=5F=83=8B=83g=83O=83b=83c=81z=81Q=89=F5=8Ay=83O=83b=83Y=90=B7=82=E8=91=F2=8ER=81Q?= Date: Sat, 10 May 2003 16:33:48 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2a1ba24e-0285-4547-a19a-986eff8b0a8a" Message-Id: <20030510073344.1691A121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --2a1ba24e-0285-4547-a19a-986eff8b0a8a Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8E=D2>DM-top http://dmtop-net100.net <=8E=96=8B=C6=8E=D2>=83A=83_=83=8B=83g=83V=83=87=83b=83v=81@Secret Dream =81= @=93=8C=8B=9E=93s=8Fa=92J=8B=E6=93=B9=8C=BA=8D=E21-15-3-407=81@090-8130-1117 =94z=90M=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=81@donot@24i.net =94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=8C=E3=96=F124=8E=9E=8A=D4=82=C5=94=BD=89= f=82=B3=82=EA=82=DC=82=B7 =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=8BK=92=E8=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B =81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81y=8DL=8D=90=81z=81Q=81= Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q =81=9A=8C=C0=92=E8=82=A8=8Ay=82=B5=82=DD=82=ED=82=AD=82=ED=82=AD=83h=83L=83= h=83L=95=9F=91=DC=81=9A =81@=8F=A4=95i=82=C8=82=AD=82=C8=82=E8=8E=9F=91=E6=8FI=97=B9=82=B5=82=DC=82=B7= =81I =81@=91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=81I=82=C8=82=AD=82=C8=82=E9=91O=82=C9= =82=C6=82=E8=82=A0=82=A6=82=B8=8C=A9=82=C9=82=AB=82=C4=81=F4 =81@http://dj.st36.arena.ne.jp/SecretDream =81@=83z=81[=83=80=83y=81[=83W=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0= =82=EA=82=AA=82=A0=82=E8=82=DC=82=B7=82=CC=82=C5=82=A8=91=81=82=DF=82=C9=81= E=81E=81E=81B --2a1ba24e-0285-4547-a19a-986eff8b0a8a-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Recruiter@Cardinal.com Tue May 13 23:40:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19FmKa-00074J-00 for ; Wed, 14 May 2003 04:49:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 14 May 2003 04:49:24 +0200 (CEST) Received: (qmail 14688 invoked by uid 65534); 13 May 2003 21:40:48 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 13 May 2003 23:40:48 +0200 Received: by moria.seul.org (Postfix) id 8894F33B5C; Tue, 13 May 2003 17:40:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 322CA33B83; Tue, 13 May 2003 17:40:45 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from nv.hire.com (unknown [66.45.102.84]) by moria.seul.org (Postfix) with ESMTP id E646A33B5C for ; Tue, 13 May 2003 17:40:43 -0400 (EDT) Received: from CAMPAIGN ([10.100.1.84]) by nv.hire.com (Merak 5.8.4) with SMTP id DEMO for ; Tue, 13 May 2003 16:40:42 -0500 From: Recruiter@Cardinal.com To: f-cpu@seul.org Subject: [f-cpu] Cardinal Health - Come Join Our Team! Date: TUE, 13 MAY 2003 16:40:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary.11111111.11111111" Message-Id: <20030513214043.E646A33B5C@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --Boundary.11111111.11111111 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit HTML Message - Cardinal Health - Come Join Our Team! --Boundary.11111111.11111111 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Come Join Our Team!


The Pharmaceutical Development business of Cardinal Health is a full-service pharmaceutical development organization (PDO), providing development services from early–stage drug discovery to clinical manufacturing and packaging for virtually every dosage form, including a number of advanced and proprietary delivery technologies.

Cardinal Health, from pharmaceutical research lab to manufacturing site. Pharmacy to patient bedside. Physician office to the executive suite. Worldwide, the 50,000 men and women of Cardinal Health partner with health care professionals so they can focus on what matters -- improving people's lives. Products. Services. Technologies. For Health Care and Life Sciences.

  
We noticed your resume on the Web.
If you’ve got 2 minutes, we could have
an exciting career opportunity waiting for you!
 
We are always on the lookout to discover new talent to join one of our Cardinal Health teams. By visiting our employment website, you can browse our available positions and profile your abilities to automatically receive information about current and future job openings that match your qualifications.

When you have completed your profile, your information will be sent directly to the appropriate hiring manager for review. It’s a direct link between the candidate and the hiring manager!

What are you waiting for? Match your abilities to one of our job openings today! Visit http://cardinalhealth.hire.com and start your journey today! We look forward to receiving your information!

It's quick...easy...free...and confidential.

If you're a team player looking for a dynamic company in a high-growth industry, then join Cardinal Health, where you can make a difference. And, if you know someone else that might be interested, please forward this invitation to share this great opportunity!

Pharmaceutical Development is:

• Discovery Support
• Product Development
• Pharmaceutical Analysis
• Clinical Manufacturing
• Clinical Supply Services

  

Including:

• Analytical Chemistry
• Inhalation
• Structural Chemistry
• Pharmaceutics
• Bioanalytical
• Drug Discovery
• Synthesis
• Microbiology

  
You have received this email because your resume is posted on the Web. If you do not wish to receive future employment opportunities or information about us - we apologize for the interruption - please reply (including all original text) with Unsubscribe in the subject line, or simply Click Here to Unsubscribe.
--Boundary.11111111.11111111-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lucky7@24i.net Thu May 15 08:16:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19GNf9-00019g-00 for ; Thu, 15 May 2003 20:41:07 +0200 X-Flags: 1000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 15 May 2003 20:41:07 +0200 (CEST) Received: (qmail 25238 invoked by uid 65534); 15 May 2003 06:17:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005) with SMTP; 15 May 2003 08:17:09 +0200 Received: by moria.seul.org (Postfix) id 0DEA433B4D; Thu, 15 May 2003 02:17:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E302D33B59; Thu, 15 May 2003 02:17:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 1886833B4D for ; Thu, 15 May 2003 02:16:58 -0400 (EDT) Received: from 24i1320.com (f057.ah096.FreeBit.NE.JP [221.113.96.57]) by belegost.mit.edu (Postfix) with SMTP id E1303121A36 for ; Thu, 15 May 2003 02:16:55 -0400 (EDT) From: saifu0515 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C=C0=92=E8=81I=8DK=89^=83p=83=8F=81[=82=B1=82=EA=82=C5=82=A0=82=C8=82=BD=82=E0=91=E5=8B=E0=8E=9D=82=BF=8A=D4=88=E1=82=A2=82=C8=82=B5=81I?= Date: Thu, 15 May 2003 15:16:59 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9b2d2111-68b4-4280-841e-b2c986f85ba8" Message-Id: <20030515061655.E1303121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --9b2d2111-68b4-4280-841e-b2c986f85ba8 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8E=D2>DMmaster http://dmmster.com <=8E=96=8B=C6=8E=D2>=8C=B3=91c=8DK=95=9F=93=B0 http://www.thc100.com/lucky =94z=90M=92=E2=8E~=90=EA=97p=83A=83h=83=8C=83X=81@donot@24i.net =94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=8C=E3=96=F124=8E=9E=8A=D4=82=C5=94=BD=89= f=82=B3=82=EA=82=DC=82=B7 =93=96=94z=90M=82=CD=91=97=90M=82=C9=8A=D6=82=B7=82=E9=93=C1=92=E8=8F=A4=95= \=8E=A6=8B`=96=B1=8BK=92=E8=82=C9=91=A5=82=E8=91=97=90M=82=B5=82=C4=82=A2=82= =DC=82=B7=81B =81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81y=8DL=8D=90=81z=81Q=81= Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q =81=9A=8C=C0=92=E8=8DK=89^=83O=83b=83c=81=9A =81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81s=95=97=90=85=81t=81Q=81Q=81Q=81= Q=81Q=81Q=81Q=81Q=81Q=81Q =89\=82=CC=89=A9=90F=82=A2=8D=E0=95z=82=C8=82=C7=82=AA=8C=83=88=C0=89=BF=8A= i=82=C5=81=F4 =8F=A4=95i=82=C8=82=AD=82=C8=82=E8=8E=9F=91=E6=8FI=97=B9=82=B5=82=DC=82=B7=81= I =91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=81I=90=E6=92=85=82R=82Q=96=BC=97l=81I=82= =C8=82=AD=82=C8=82=E9=91O=82=C9=82=C6=82=E8=82=A0=82=A6=82=B8=8C=A9=82=C9=82= =AB=82=C4=81=F4 http://www.thc100.com/lucky =83z=81[=83=80=83y=81[=83W=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82= =EA=82=AA=82=A0=82=E8=82=DC=82=B7=82=CC=82=C5=82=A8=91=81=82=DF=82=C9=81E=81= E=81E=81B --9b2d2111-68b4-4280-841e-b2c986f85ba8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kakuu@bonbon.net Tue May 20 17:07:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19JBkc-0000Hj-00 for ; Fri, 23 May 2003 14:34:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 23 May 2003 14:34:22 +0200 (CEST) Received: (qmail 7040 invoked by uid 65534); 20 May 2003 15:06:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 20 May 2003 17:06:54 +0200 Received: by moria.seul.org (Postfix) id 1130633B7C; Tue, 20 May 2003 11:06:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E503A33C20; Tue, 20 May 2003 11:06:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 8886E33B7C for ; Tue, 20 May 2003 11:06:40 -0400 (EDT) Received: from 10.07.17.21 (pl1032.nas927.o-tokyo.nttpc.ne.jp [61.197.110.8]) by belegost.mit.edu (Postfix) with SMTP id 2FC82121A36 for ; Tue, 20 May 2003 11:06:33 -0400 (EDT) From: =?iso-2022-jp?q?=89=CB=8B=F3=83=82=83m=8E=E6=88=F8=8F=88_ , ?=@belegost.mit.edu To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=81=9C=89=CB=8B=F3=96=BC=8B`=92=CA=92=A0=81E=8Cg=91=D1=81E=90g=95=AA=8F=D8?= Date: Wed, 21 May 2003 00:07:36 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9c81e573-a75c-4605-b938-7fb914beb7e3" Message-Id: <20030520150633.2FC82121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --9c81e573-a75c-4605-b938-7fb914beb7e3 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable *************** =89=CB=8B=F3=83=82=83m=8E=E6=88=F8=8F=88=81@ *************** =88=AB=97p=8C=B5=8B=D6=81I=8E=D8=8B=E0=92n=8D=96=82=A9=82=E7=82=CC=90=B6=8A=D2= =81E=81E=81E=81B =97p=93r=90F=81X=81B=82=A0=82=AD=82=DC=82=C5=82=E0=82=A8=97V=82=D1=82=C5=82=B2= =8Eg=97p=82=AD=82=BE=82=B3=82=A2=81B =91=BC=82=C5=82=CD=94=84=82=C1=82=C4=82=A2=82=C8=82=A2=8C=83=88=C0=89=BF=8A= i=81B =8F=DA=82=B5=82=AD=82=CD=82=B1=82=B1=82=A9=82=E7=81=AB http://book-i.net/kakuu/ http://www.newag.org/members/kakuu/index.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=92=CA=92=A0=81E=83J=81[=83h=81E=88=F3=8A=D3=83= Z=83b=83g =8F=97=90=AB=96=BC=8B` 12=81C000=89~ =92j=90=AB=96=BC=8B`9=81C800=89~ =8C=FB=8D=C0=96=BC=8B`=82=CC=8Ew=92=E8=81A=93X=95=DC=82=CC=8Ew=92=E8=82=CD=82= =C5=82=AB=82=DC=82=B9=82=F1=81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=96=C6=8B=96=8F=D8=8D=EC=90=AC=83L=83b=83g=81@1=96= =87=95=AA9,000=89~ =90=E0=96=BE=8F=91=82=C9=8F=91=82=A2=82=C4=82=A0=82=E9=8E=E8=8F=87=82=C9=82=B5= =82=BD=82=AA=82=C1=82=C4=8E=CA=90^=82=F0=93=FC=82=EA=82=E9=82=BE=82=AF=81B =8A=C8=92P=82=C9=8D=EC=90=AC=82=C5=82=AB=82=DC=82=B7=81B=8D=EC=8B=C6=82=C9=83= p=83\=83R=83=93=95s=97p=81B =93=EF=82=B5=82=A2=92m=8E=AF=82=E2=8BZ=8Fp=82=E0=95s=97p=81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=83p=83X=83|=81[=83g=8D=EC=90=AC=83L=83b=83g=81= @1=8D=FB=95=AA8,000=89~ =90=E0=96=BE=8F=91=82=C9=8F=91=82=A2=82=C4=82=A0=82=E9=8E=E8=8F=87=82=C9=82=B5= =82=BD=82=AA=82=C1=82=C4=8E=CA=90^=82=F0=93=FC=82=EA=82=E9=82=BE=82=AF=81B =8A=C8=92P=82=C9=8D=EC=90=AC=82=C5=82=AB=82=DC=82=B7=81B=8D=EC=8B=C6=82=C9=83= p=83\=83R=83=93=95s=97p=81B =93=EF=82=B5=82=A2=92m=8E=AF=82=E2=8BZ=8Fp=82=E0=95s=97p =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=95=DB=8C=AF=8F=D8=81@1=96=8710,000=89~ =8FZ=8F=8A=96=A2=8BL=93=FC=81B=8BL=93=FC=95=FB=96@=82=CD=90=E0=96=BE=8F=91=82= =F0=82=A8=93=C7=82=DD=82=AD=82=BE=82=B3=82=A2=81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=81@=83N=83=8C=83J+=83T=83=89=8B=E0=83Z=83b=83g=81= @1=83Z=83b=83g12,000=89~ =8BU=91=A2=95i=82=C5=82=CD=82=A0=82=E8=82=DC=82=B9=82=F1=81B=82=A0=82=AD=82=DC= =82=C5=82=E0=89=CB=8B=F3=96=BC=8B`=82=C5=82=B7=81B =92j=90=AB=96=BC=8B`=82=CC=82=DD=81B=96=BC=8B`=8Ew=92=E8=81A=89=EF=8E=D0=8E= w=92=E8=82=CD=82=C5=82=AB=82=DC=82=B9=82=F1=81B =8C=C0=93x=8Az=82T=82O=96=9C=89~=82=C5=82=B7=82=AA=81A =8AC=8AO=8Eg=97p=82=C5=82=CD=8C=C0=93x=8Az=82=AA=96=B3=82=A2=82=C9=93=99=82=B5= =82=A2=82=C6=8Ev=82=ED=82=EA=82=DC=82=B7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=94=F2=82=CE=82=B5=8Cg=91=D1=81@1=91=E4=81@10,000=81` =81@=81=A5=81@=83L=83=83=83=8A=83A=8Ew=92=E8=82=C8=82=B510,000=89~ =81@=81=A5=81@=83L=83=83=83=8A=83A=8Ew=92=E8=81@ =81@=83h=83R=83=82=81@30,000=89~ =81@=83c=81[=83J=81[=81@20,000=89~ =81@au=81@21,000=89~ =81@=82=B7=82=D7=82=C4=8B@=8E=ED=8Ew=92=E8=82=CD=82=C5=82=AB=82=DC=82=B9=82=F1= =81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=92=CA=92=A0=81E=89=CB=8B=F3=96=BC=8B`=96=C6=8B=96= =8F=D8=81E=93=AF=88=EA=96=BC=8B`=83Z=83b=83g 1=83Z=83b=83g=81@15,000=89~=81@=92j=90=AB=96=BC=8B`=82=CC=82=DD =8F=E3=8BL=82=CC=92=CA=92=A0=81A=88=F3=8A=D3=82=C6=89=CB=8B=F3=96=BC=8B`=96=C6= =8B=96=8F=D8=82=CC=83Z=83b=83g=82=C5=82=B7=81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =81=9C=89=CB=8B=F3=96=BC=8B`=83v=83=8D=83o=83C=83_ID=82=F0=8A=C8=92P=82=C9=8E= =E6=82=E9=95=FB=96@=81@4,500=89~ =83v=83=8D=83o=83C=83_=82=CC=8Ew=92=E8=82=CD=82=C5=82=AB=82=DC=82=B9=82=F1=81= B=83p=83X=83=8F=81[=83h=82=CD=95=CF=8DX=89=C2=81B =83_=83C=83=84=83=8B=83A=83b=83v=8C_=96=F1=82=C5=82=B7=82=AA=81A=82=B7=82=AE= =82=C9ADSL=8C_=96=F1=82=C9=95=CF=8DX=89=C2=81B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =8F=DA=82=B5=82=AD=82=CD=82=B1=82=B1=82=A9=82=E7=81=AB http://kakuu.free-host.com/ http://www.freewebs.com/kakuu/ http://jp.internations.net/kakuu/ ****************************************** =83T=83C=83g=82=AA=8F=C1=96=C5=96=94=82=CD=82=BB=82=CC=91=BC=82=CC=97=9D=97= R=82=C5=83A=83N=83Z=83X=82=C5=82=AB=82=C8=82=A2=8F=EA=8D=87=83=81=81[=83=8B=82= =C5=82=CC=92=8D=95=B6=82=F0=8E=F3=82=AF=95t=82=AF=82=C4=82=A2=82=DC=82=B7=81B = =89=BA=8BL=82=CC=83A=83h=83=8C=83X=88=B6=82=C9=95K=97v=8E=96=8D=80=82=F0=8B= L=93=FC=82=B5=83R=83s=81[=81A=93\=82=E8=95t=82=AF=82=B5=82=C4=82=B1=82=CC=82= =DC=82=DC=83=81=81[=83=8B=82=C5=91=97=90M=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2= =81B =8F=A4=95i=82=CD=88=C0=90S=82=CC=91=E3=8B=E0=88=F8=8A=B7=95=A5=82=A2=82=CC=82= =DD=81B =82=A8=8Bq=97l=82=CC=8F=EE=95=F1=82=CD=94=AD=91=97=92=BC=8C=E3=82=C9=96=95=8F= =C1=82=B5=82=C4=82=A2=82=DC=82=B7=82=CC=82=C5=82=B2=88=C0=90S=89=BA=82=B3=82= =A2=81B =81=A1=8Dw=93=FC=90\=8D=9E=82=DD=81=A1-------------------------------------- =8Dw=93=FC=8F=A4=95i=81F =82=A8=96=BC=91O=81F =82=A8=93d=98b=94=D4=8D=86=81F =97X=95=D6=94=D4=8D=86=81F =82=B2=8FZ=8F=8A=81F ---------------------------------------------------- =91=97=82=E8=90=E6=83A=83h=83=8C=83X kakuuorder@nunu.nu =96=94=82=CD kakuuorder@mon8.net --9c81e573-a75c-4605-b938-7fb914beb7e3-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hallucination@24i.net Thu May 22 23:10:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19JBo2-0000Hj-01 for ; Fri, 23 May 2003 14:37:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 23 May 2003 14:37:54 +0200 (CEST) Received: (qmail 27115 invoked by uid 65534); 22 May 2003 21:10:53 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 22 May 2003 23:10:53 +0200 Received: by moria.seul.org (Postfix) id E9B8233C84; Thu, 22 May 2003 17:10:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E72FA33C87; Thu, 22 May 2003 17:10:48 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 7355733C84 for ; Thu, 22 May 2003 17:10:48 -0400 (EDT) Received: from 24i1449.com (f215.ac123.FreeBit.NE.JP [43.244.123.215]) by belegost.mit.edu (Postfix) with SMTP id 9118C121A36 for ; Thu, 22 May 2003 17:10:46 -0400 (EDT) From: ug0522a To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8DD=95]=82=C9=82=C2=82=AB=81I=81Q=8C=B6=8Ao=8C=A9=82=BF=82=E1=82=A4=81=F4=81Q?= Date: Fri, 23 May 2003 06:10:48 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="21d3d7a4-4af5-4eb5-97ef-4af0f4921ff2" Message-Id: <20030522211046.9118C121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --21d3d7a4-4af5-4eb5-97ef-4af0f4921ff2 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://210.150.173.81/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @donot@24i.net .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=8D=87=96= @=83h=83=89=83b=83O=90=EA=96=E5=93X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81@=81@=81@=81@=81@ =81@=81=9A=81=99=81=9A Drug Shop HALLUCINATION =81=9A= =81=99=81=9A=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0 ._/_/_/_/_/ ._/_/_/=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@HALLUCINATION Weekly ._/_/_/=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ =81|Vol.2=81| ._/_/_/_/_/ .=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1 . .=84=AC=84=B2C=84=ABO=84=ABN=84=ABT=84=ABE=84=ABN=84=ABT=84=ABS=84=B0=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AD .=84=AB .=84=AB=81m=82P=81nNEW=8F=A4=95i=82=BC=82=AD=82=BC=82=AD=93=FC=8E=E8=81I=81I = .=84=AB=81m=82Q=81n=8D=C5=8B=AD=81I=81g=82=B1=82=EA=82=AA=89\=82=CCDMT=81c=81= h .=84=AB=81m=82R=81n=8BK=90=A7=90=A1=91O=81I=81I=81u=82=B1=82=EA=82=C1=82=C4= =8D=87=96@=81I=81H=81v .=84=AB=81m=82S=81n=93=C1=95=CA=83L=83=83=83=93=83y=81[=83=93=89=BF=8Ai=8C=C0= =92=E8=94=CC=94=84=8AJ=8En=82=CC=82=A8=92m=82=E7=82=B9 .=84=AB=81m=82T=81n=8D=A1=8FT=82=CC=90V=8F=A4=95i=81u=83P=83~=83J=83=8B=81= v=93=C1=8FW=81I .=84=AB=81m=82U=81n=8C=C0=92=E8=8F=EE=95=F1=81i=8A=FA=8A=D4=81F 5/22=81`5/=96= =96 =81j .=84=AB=81m=82V=81n=90=AB=8A=B4=83N=83=8A=81[=83=80=91=E3=97=9D=93X=95=E5=8F= W=82=CC=82=B2=88=C4=93=E0 .=84=AB .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AE . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://210.150.173.81/=81@=81=E1= =81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . . . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=83A=83= _=83=8B=83g=8C=C0=92=E8=95=9F=91=DC=81I=81I=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81@=81@=81@=81@=81@=81=9A=81=99=81=9A =83A=83_=83=8B=83g=83V=83=87=83b=83= v=81@=83V=81[=83N=83=8C=83b=83g=83h=83=8A=81[=83=80 =81=9A=81=99=81=9A=81@=81= @=81@=81@=81@=81@=81@=81@=81@=81@ .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0 . .=90=94=97=CA=8C=C0=92=E8=81I=81I=83v=83=8C=83~=83A=83A=83_=83=8B=83g=83O=83= b=83c=95=9F=91=DC=81I=94=84=82=E8=90=D8=82=EA=8C=E4=96=C6=81I=91=81=82=A2=82= =E0=82=CC=8F=9F=82=BF=81I . .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0 . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@ =81=E2=81=E2=81@http://dj.st36.arena.ne.jp/SecretDream/=81= @=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . . . --21d3d7a4-4af5-4eb5-97ef-4af0f4921ff2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From zoey@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19JBmW-0000Hj-00 for ; Fri, 23 May 2003 14:36:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 23 May 2003 14:36:20 +0200 (CEST) Received: (qmail 18130 invoked by uid 65534); 21 May 2003 19:55:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 21 May 2003 21:55:51 +0200 Received: by moria.seul.org (Postfix) id A0C4733B7A; Wed, 21 May 2003 15:55:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9338133C70; Wed, 21 May 2003 15:55:48 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id CCEEE33B7A for ; Wed, 21 May 2003 15:55:47 -0400 (EDT) Received: (qmail 60734 invoked from network); 21 May 2003 19:57:06 -0000 Received: from unknown (HELO eXcuria.com) (63.251.146.40) by bettik.munge.net with SMTP; 21 May 2003 19:57:06 -0000 Date: 5/21/2003 2:54:44 PM To: From: Zoey Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save upto 89% Message-Id: <20030521195547.CCEEE33B7A@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products w/ 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! Visit us on the web at http://excuria.com/inkstore/ For instruction on how to be permanently remove from this distribution system go to http://excuria.com/remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mrs_abach@themail.com Wed May 21 10:05:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19JBlk-0000Hj-01 for ; Fri, 23 May 2003 14:35:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 23 May 2003 14:35:32 +0200 (CEST) Received: (qmail 8458 invoked by uid 65534); 21 May 2003 08:06:45 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 21 May 2003 10:06:45 +0200 Received: by moria.seul.org (Postfix) id C34C033C6F; Wed, 21 May 2003 04:06:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F6B933C74; Wed, 21 May 2003 04:05:53 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from outgoing2.themail.com (unknown [216.204.151.37]) by moria.seul.org (Postfix) with ESMTP id A770933C72 for ; Wed, 21 May 2003 04:05:37 -0400 (EDT) Received: from mail.TheMail.com [216.204.151.240] by outgoing2.themail.com (SMTPD32-6.06) id A33F351800E6; Wed, 21 May 2003 04:05:19 -0400 Received-From: mail.TheMail.com To: mrs_abach@themail.com Message-Id: <20030521080537.A770933C72@moria.seul.org> Date: Wed, 21 May 2003 04:05:37 -0400 (EDT) From: mrs_abach@themail.com Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ,pczakir@123india.com,pczakir@calicutnet.com,shanabc@aol.com,rajsheeja@calicutnet.com,jayaram.nair@wipro.com,kesavanunni@satyam.net.in,wahabsv@calicutnet.com,bama@emirates.net.ae,heman@agd2.dot.net.in,amyk@calicutnet.com,rakesh_soman@hotmail.com,rasheed136@hotmail.com,www@calicutcity.com,bspandco@emirates.net.ae,rineesh_007@hotmail.com,a_najeeb10@hotmail.com,shameer-parappurath@usa.net,gskutty@yahoo.com,just_life@yahoo.com,kotieth@hotmail.com,c.keluvettan@mailcity.com,moohann@usa.net,anwarkk@mailcity.com,p erFrom: mrs_abach@themail.com Subject: Assistance X-Priority: 3 Authorized-User: mrs_abach@themail.com IP-Address: 192.116.89.18 Reply-To: mrs_abach@themail.com MIME-Version: 1.0 Content-type: text/plain Message-Id: <200305210405843.SM00135@mail.TheMail.com> Date: Wed, 21 May 2003 04:16:45 -0400 Mrs. Maryam Abacha C/o Desmond & Associate E-mail: mohammed_law6@yahoo.com Lagos - Nigeria. Dear Sir, It is with heart full of hope that I write to seek your help in the context below. I am Mrs. Maryam Abacha the wife of the former Nigeria Head of state Late General Sani Abacha, whose sudden death occurred on 8th of June, 1998. Having gotten your particulars from the family catalogue, I have no doubt about your capacity and good will to assist me in receiving into your custody (for safety) the sum of US$ 48 Million willed and deposited in my favour by my late husband. This money is currently kept in a Trust Deposit Account with West African Sub-Regional Finance and Security Co. As it is legally required, the asset of my late husband is under the authority of our family lawyer named Barrister Mohammed Kariam (Esq). Unfortunately, the new Democratic Government has on assumption of office set up a Panel of Enquires to probe the financial activities of my late husband(Former Head of State) with a decision to freeze all his assets.The investigation teams have submitted their reports, presently some cash and assets have been frozen and seized. Fortunately, with our family lawyer’s assistance we secretly protected the “Personal will” of my husband from the notice of the investigators and have strictly advised that the willed money be urgently moved into an overseas account of a Trusted foreigner without delay for security reasons. The government had long time ago placed foreign Travel Embargo on all our family members and seized our international passports and all our local and international business outfits. The situation has been so terrible that we are virtually living on the assistance of well wishers. In view of this plight therefore, I expect you to be trustworthy and kind enough to respond to this call to save my children and me from a hopeless future by assisting me in receiving this money into your overseas account for save keeping until our International Passports are released to us after the investigatio n is concluded. I hereby agree to compensate your sincere and candid effort in this regard with 20% of the fund when finally received in your bank account. Our Attorney has perfected arrangement with the financial Security Company to effect complete dislodgment of this money within a week of the receipt of your response. They have equally guaranteed 100% smooth transfer. Please all contacts must be made through our lawyer Mohammed Karim of Garry Chambers via his e-mail address: mohammed_law6@yahoo.com I look forward to your quick response, may Almighty Allah bless you. Yours faithfully, Mrs. Maryam Abacha __________________________________________________________________ TheMail.com - Full featured premium email you can count on. Sign-up today at http://www.themail.com/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sirial@punkass.com Mon May 26 17:22:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KOLt-0006hw-00 for ; Mon, 26 May 2003 22:13:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 26 May 2003 22:13:49 +0200 (CEST) Received: (qmail 17567 invoked by uid 65534); 26 May 2003 15:22:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 26 May 2003 17:22:08 +0200 Received: by moria.seul.org (Postfix) id 4AB4433B50; Mon, 26 May 2003 11:21:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6603033C39; Mon, 26 May 2003 11:21:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 7E6EA33B50 for ; Mon, 26 May 2003 11:21:57 -0400 (EDT) Received: from 10.21.05.27 (d141.GtokyoFL1.vectant.ne.jp [202.215.16.141]) by belegost.mit.edu (Postfix) with SMTP id D8183121A36 for ; Mon, 26 May 2003 11:21:46 -0400 (EDT) From: =?iso-2022-jp?q?=90K=97L_ , ?=@belegost.mit.edu To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=81=9A=90K=97L=83i=83=93=83o=81[=8FW=94=CC=94=84=81=9A?= Date: Tue, 27 May 2003 00:22:13 +0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="39f4ea21-1a88-4770-9676-e0f8d7c5964a" Message-Id: <20030526152146.D8183121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --39f4ea21-1a88-4770-9676-e0f8d7c5964a Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable

=87@=90K=97L=83i=83=93=83o=81= [=8FW=94=CC=94=84

=83V=83F=83A=83E=83G=83A=82=A9=82=E7=90=B3=8BK=94=C5=82=DC=82=C5=96=F1= 3,000=82=CC=83i=83=93=83o=81[=8E=FB=98^

=83\=83t=83g=82=F0=94=83=82=C1=82=BD=82=CC=82=C9=90K=82=F0=96Y=82=EA=82= =C4=82=B5=82=DC=82=C1=82=BD=81A
2=94N=91O=82=C9=94=83=82=C1=82=BD=83V=83F=83A=83E=83G=83A=82=CC=90K=82=F0= =96=B3=82=AD=82=B5=82=C4=82=B5=82=DC=82=C1=82=BD=82=AA=83T=83|=81[=83g=82=AA= =82=E0=82=A4=96=B3=82=A2=81A
=89=BD=96=9C=89~=82=E0=8Fo=82=B5=82=C4=94=83=82=C1=82=BD=83V=83F=83A=83= E=83G=83A=81[=82=CC=90K=82=F0=96=B3=82=AD=82=B5=82=C4=82=B5=82=DC=82=C1=82=BD= =81A

=82=BB=82=F1=82=C8=95=FB=82=C9=98N=95=F1=81I
=83x=83N=8Cn=81A=93m=8Cn=81A=90=B3=8BK=8Cn=81A=82P=82W=8B=D6=8Cn=82=BB=82= =CC=91=BC=82=CC=90K=82=E0=82=EB=82=E0=82=EB=91=B5=82=C1=82=C4=82=A2=82=DC=82= =B7=81B

=92=8D=88=D3=81F=82=B1=82=EA=82= =AA=82=A0=82=EA=82=CE=81A=90=B3=8BK=82=C5=8Dw=93=FC=82=B5=82=C8=82=AD=82=C4=82= =E0=83\=83t=83g=82=CD=90=B3=8F=ED=82=C9=93=AE=8D=EC=82=B5=82=DC=82=B7=82=AA=
=8Dw=93=FC=82=B7=82=E9=88=D3=8Ev=82=AA=96=B3=82=A2=82=CC=82=C9=83V=83F=83= A=83E=83G=83A=82=F0=83_=83E=83=93=83=8D=81[=83h=82=B5=82=C4=81A=90K=82=F0=93= =FC=97=CD=82=B5=82=C4=8F=9F=8E=E8=82=C9=8Eg=82=C1=82=C4=82=CD=82=A2=82=AF=82= =DC=82=B9=82=F1=81B
=83_=83E=83=93=83=8D=81[=83h=93V=8D=91=81A=82=A2=82=B4=83x=83N=82=D6=92=BC= =8Ds=81@=82=CD=90=E2=91=CE=82=C9=82=A2=82=AF=82=DC=82=B9=82=F1=81B
=83V=83F=83A=83E=83G=83A=82=F0=8F=9F=8E=E8=82=C9=82=D9=82=C6=82=F1=82=C7= =96=B3=97=BF=82=C5=8Eg=82=C1=82=C4=82=A2=82=E9=90l=82=AA=82=A2=82=DC=82=B7=82= =AA=90^=8E=97=82=B5=82=C4=82=CD=82=A2=82=AF=82=DC=82=B9=82=F1=81B

=81=9A=93=E0=97e=81=9A
=82Q=82O=82O=82O=94N10=8C=8E=94=C5=90K=97L=8FW
=82Q=82O=82O=82P=94N6=8C=8E7=93=FA=94=C5=90K=97L=8FW
=82Q=82O=82O=82Q=94N=82X=8C=8E=94=C5=90K=97L=8FW
=82Q=82O=82O=82R=94N=82S=8C=8E=94=C5=90K=97L=8FW=81i=8D=C5=90V=81j
=83e=83L=83X=83g=8C`=8E=AE=81i=82P=8Ds=82=C9=82P=90K=81j=81B=90=94= =8E=9A=81A=83A=83=8B=83t=83@=83x=83b=83g=81A=82T=82O=89=B9=8F=87=81B
Windows=83=81=83=82=92=A0=81A=83=8F=81[=83h=83p=83b=83g=82=C8=82=C7=82=C5= =95\=8E=A6=82=C5=82=AB=82=DC=82=B7=81B
=82=F0=82=DC=82=C6=82=DF=82=C4=83t=83=8D=83b=83s=81[=82P=96=87=82=C9=93=FC= =82=EA=82=C4=94=CC=94=84

=81=9A=89=BF=8Ai=81=9A
=82P=96=873,500=89~
*******************************************

=87A=90K=97L=83i=83=93=83o=81= [=89=F0=93=C7=81E=89=F0=8F=9C=83\=83t=83g=94=CC=94=84

=95=B6=8B=E5=96=B3=82=B5=82=CC=82=B7=82=B2=82=A2=8Fo=97=88=82=CC=83\=83= t=83g=82=C5=82=B7=81B
=82=D9=82=C6=82=F1=82=C7=82=CC=83V=83=8A=83A=83=8B=82=F03=95=AA=88=C8=93= =E0=82=C9=89=F0=93=C7=81A=89=F0=8F=9C=82=B5=82=C4=82=B5=82=DC=82=A4=92=B4=82= =B7=82=B2=82=A2=83\=83t=83g=82=C5=82=B7=81B
=8E=9F=81X=82=C9=8Fo=82=E9=90V=82=B5=82=A2=83o=81[=83W=83=87=83=93=82=CC= =83\=83t=83g=82=C9=82=E0=91=CE=89=9E=82=C5=82=AB=82=E9=82=A9=82=E7=95=D6=97=98= =82=C5=82=B7=81B

=82=B1=82=CC=90=E6=82=B8=82=C1=82=C6=90K=82=F0=92T=82=B5=89=F1=82=E9=95= K=97v=82=AA=96=B3=82=AD=82=C8=82=E8=82=DC=82=B7=81B
=82=B5=82=A9=82=B5=81A=82=A0=82=AD=82=DC=82=C5=82=E0=8F=ED=8E=AF=82=CC=94= =CD=88=CD=93=E0=82=C5=82=CC=82=B2=8Eg=97p=82=F0=82=A8=8A=E8=82=A2=82=A2=82=BD= =82=B5=82=DC=82=B7=81B

=81=9A=89=BF=8Ai=81=9A
=82V=81C=82O=82O=82O=89~
********************************************

=81=9A=8Dw=93=FC=95=FB=96@=81=9A
=83t=83=8D=83b=83s=81[=82=CD=82=A0=82=C8=82=BD=82=CC=82=B2=8FZ=8F=8A=82=D6= =92=BC=90=DA=97X=95=D6=82=C5=82=A8=93=CD=82=AF=82=B5=82=DC=82=B7=81B
=82=A8=8Ex=95=A5=82=A2=82=CD=81A=95i=95=A8=82=C6=8C=F0=8A=B7=82=CC=81u=91= =E3=8B=E0=88=F8=8A=B7=95=A5=82=A2=81v
=91=97=97=BF=82=CD=91S=8D=91=88=EA=97=A5500=89~=82=CC=82=DD
=89=BA=82=CC=83t=83H=81[=83=80=82=A9=82=E7=8Dw=93=FC=90\=8D=9E=82=DD=82=B5= =82=C4=82=AD=82=BE=82=B3=82=A2=81B
=81u=91=97=90M=81v=83{=83^=83=93=82=CD=83C=83=93=83^=81[=83l=83b=83g=82=C9= =8Cq=82=AA=82=C1=82=BD=8F=F3=91=D4=82=C5=89=9F=82=B5=82=C4=82=AD=82=BE=82=B3= =82=A2=81B

*******************************************
=8Dw=93=FC=90\=8D=9E
*******************************************
=8Dw=93=FC=8F=A4=95i=81F=87@=81@=81@=81@=87A
=82=A8=96=BC=91O=81F
=82=D3=82=E8=82=AA=82=C8=81F
=93d=98b=94=D4=8D=86=81F
=97X=95=D6=94=D4=8D=86=81F
=8FZ=8F=8A=81F
=81=A6=8FZ=8F=8A=82=CD=94=D4=92n=81A=8C=9A=95=A8=96=BC=82=DC=82=C5=8BL=93= =FC=82=B5=82=C4=82=AD=82=BE=82=B3=82=A2

*******************************************
=81=A6=8Dw=93=FC=82=CC=94=E9=96=A7=82=CD=90=E2=91=CE=82=C9=8C=B5=8E=E7=82= =B5=82=DC=82=B7=82=CC=82=C5=88=C0=90S=82=B5=82=C4=82=B2=8Dw=93=FC=82=AD=82=BE= =82=B3=82=A2=81B

=81=A6=82=A4=82=DC=82=AD=91=97=90M=82=C5=82=AB=82=C8=82=A2=8E=9E=82=CD= sirial@secondstyle.com=82=DC=82=C5=83R=83s=81[=81A=93\=82=E8=95t=82=AF=82=B5= =82=C4=83=81=81[=83=8B=82=C5=82=A8=90\=8D=9E=82=DD=82=AD=82=BE=82=B3=82=A2=81= B
--39f4ea21-1a88-4770-9676-e0f8d7c5964a-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dsds0035@dreamwiz.com Tue May 27 01:37:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KTq6-0002EJ-00 for ; Tue, 27 May 2003 04:05:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.65.60] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 04:05:22 +0200 (CEST) Received: (qmail 18119 invoked by uid 65534); 26 May 2003 23:42:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 27 May 2003 01:42:05 +0200 Received: by moria.seul.org (Postfix) id 2179533C53; Mon, 26 May 2003 19:42:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA4B233B71; Mon, 26 May 2003 19:42:00 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx-s0.dreamwiz.com (mx-s0.dreamwiz.com [211.39.128.135]) by moria.seul.org (Postfix) with ESMTP id 321BB33B66; Mon, 26 May 2003 19:41:46 -0400 (EDT) Received: from mail34.dreamwiz.com (mail34.dreamwiz.com [211.39.128.54]) by mx-s0.dreamwiz.com (8.12.9/8.12.9) with ESMTP id h4QNbvl3031501; Tue, 27 May 2003 08:37:57 +0900 (KST) Received: from localhost (localhost.dreamwiz.com [127.0.0.1]) by mail34.dreamwiz.com (8.12.9/8.12.9) with ESMTP id h4QNbuUi094807; Tue, 27 May 2003 08:37:56 +0900 (KST) Message-Id: <200305262337.h4QNbuUi094807@mail34.dreamwiz.com> Date: Tue, 27 May 2003 08:37:56 +0900 (KST) From: =?EUC-KR?B?sPvH9sHW?= Subject: [f-cpu] =?EUC-KR?B?KKGpsaShqbDtKaHavLO5rsG2u+ew4bD6IMH3wOXAzsDMILChwOUgvLHIow==?= =?EUC-KR?B?x8+0wiDA2rDdwfUxwKe0wj+h2iAgICAgICAgICAgICAgICAgICAgICAgIA==?= =?EUC-KR?B?ICAgICAgICAgICAgICAgICAgLi4xMTMxOQ==?= To: kwakchan@hotmail.com X-Sender-IP: 211.212.220.93 X-Sender-ID: dsds0035@dreamwiz.com X-Priority: 1 X-Mailer: DreamWiz Web-Mailer V1.71 X-DreamWiz-Data: receive_check=1;save=mail34.dreamwiz.com:dsds0035:Sent:371; MIME-Version: 1.0 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="0-1206930757-1053992276=:94462" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --0-1206930757-1053992276=:94462 Content-Type: TEXT/PLAIN; CHARSET=EUC-KR Content-Transfer-Encoding: 8BIT
* ¾Æ·¡ ½Åû¾ç½ÄÀ» ÀÛ¼ºÇϽøé ÀÚ°ÝÁõ °ü·Ã ¼öÇèÁ¤º¸¿Í ±âÃâ¹®Á¦¸¦ ¸ÞÀÏ·Î ¹Þ¾Æº¸½Ç ¼ö ÀÖ½À´Ï´Ù.

À̸§

À̸ÞÀÏ

³ªÀÌ

Á÷¾÷

ÀüÈ­¹øÈ£

ÇÚµåÆù¹øÈ£

ÁÖ¼Ò

¹®ÀÇ»çÇ×

º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ (±¤°í)¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.
ºÒÆíÇϽôõ¶óµµ [¼ö½Å °ÅºÎ]¸¦ Ŭ¸¯ÇØ Áֽøé ÀÌ»ó ¹ß¼ÛµÇÁö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.
If you don't want this typ! e of information or e-mail, please click the refuse here.

 

------------------------------------------------- Your Life on the Net DreamWiz Free Mail @ http://www.dreamwiz.com/ --0-1206930757-1053992276=:94462 Content-Type: TEXT/HTML; CHARSET=EUC-KR Content-Transfer-Encoding: 8BIT
* ¾Æ·¡ ½Åû¾ç½ÄÀ» ÀÛ¼ºÇϽøé ÀÚ°ÝÁõ °ü·Ã ¼öÇèÁ¤º¸¿Í ±âÃâ¹®Á¦¸¦ ¸ÞÀÏ·Î ¹Þ¾Æº¸½Ç ¼ö ÀÖ½À´Ï´Ù.

À̸§

À̸ÞÀÏ

³ªÀÌ

Á÷¾÷

ÀüÈ­¹øÈ£

ÇÚµåÆù¹øÈ£

ÁÖ¼Ò

¹®ÀÇ»çÇ×

º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ (±¤°í)¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.
ºÒÆíÇϽôõ¶óµµ [¼ö½Å °ÅºÎ]¸¦ Ŭ¸¯ÇØ Áֽøé ÀÌ»ó ¹ß¼ÛµÇÁö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.
If you don't want this! type of information or e-mail, please click the refuse here.

 






»ýÈ°ÀÎÅÍ³Ý µå¸²À§Áî http://www.dreamwiz.com

[»ýÈ°Á¤º¸] ±¹Á¦ÀüÈ­ ¿ä±Ýºñ±³, À߸¸ °ñ¶ó¾²¸é ºÐ´ç 1000¿øÀÌ Àý¾àµË´Ï´Ù.
[±¤°í] ½Å¿ëÄ«µå °áÀç°¡ ¸·¸·ÇϽŰ¡¿ä? Ä«µåºú ´çÀÏ ÇØ°á °¡´É! Áö±Ý ½ÅûÇϼ¼¿ä!
--0-1206930757-1053992276=:94462-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From god@sky.org Tue May 27 14:19:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Kge9-0003Ni-01 for ; Tue, 27 May 2003 17:45:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 17:45:53 +0200 (CEST) Received: (qmail 9424 invoked by uid 65534); 27 May 2003 12:20:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 27 May 2003 14:20:01 +0200 Received: by moria.seul.org (Postfix) id B6F1933C5F; Tue, 27 May 2003 08:19:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1018233C5E; Tue, 27 May 2003 08:19:57 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from www.toutEtRien.be (toutetrien.be [212.68.198.141]) by moria.seul.org (Postfix) with SMTP id BB89333C5B for ; Tue, 27 May 2003 08:19:54 -0400 (EDT) Received: from Cksgg ([213.41.145.216]) by toutetrien.be ( IA Mail Server Version: 3.2.1. Build: 1083 ) ) ; Tue, 27 May 2003 14:14:13 +0100 From: god To: f-cpu@seul.org Subject: [f-cpu] Look,my beautiful girl friend MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=J53Q906g8Kss7d3mi7sYH32TO1639SEo44D Message-Id: <20030527121954.BB89333C5B@moria.seul.org> Date: Tue, 27 May 2003 08:19:54 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --J53Q906g8Kss7d3mi7sYH32TO1639SEo44D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --J53Q906g8Kss7d3mi7sYH32TO1639SEo44D Content-Type: audio/x-wav; name=Jmmxw.bat Content-Transfer-Encoding: base64 Content-ID: --J53Q906g8Kss7d3mi7sYH32TO1639SEo44D --J53Q906g8Kss7d3mi7sYH32TO1639SEo44D Content-Type: application/octet-stream; name=559031CC[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAQgAA/+4AJkFkb2JlAGTAAAAA AQMAFQQDBgoNAAAIzQAADVUAABPmAAAdf//bAIQABQMDAwQDBQQEBQcFBAUHCAYFBQYICggI CAgICgwKCwsLCwoMDAwMDAwMDA8PEBAPDxYVFRUWGBgYGBgYGBgYGAEFBgYKCQoTDAwTFBEO ERQYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgY/8IA EQgAlgCWAwERAAIRAQMRAf/EAOAAAAAHAQEAAAAAAAAAAAAAAAABAgMEBQYHCAEAAgMBAAAA AAAAAAAAAAAAAAECAwQFEAABAwMCBAMJAQEAAAAAAAAAAQIDERIEIAUQMCEGExQkQDEiMjM0 FTUWQSURAAECAwQDDAgFBQEAAAAAAAEAAhESAyExQQQQUXEgYZGx0SIycqITQ3MwgaFCUmLC I8HhgrIUkjOTJAWzEgABAwQDAQAAAAAAAAAAAAARAEBQEHABITBgYRITAQACAgEDAwQDAQEB AAAAAAEAESExQRBRYSBxgTDwkaGxwdHhQPH/2gAMAwEAAhEDEQAAAYSk+E4HkRx0kLiGAAAA AAAYBBgYzQY7a3NiZQkhKDYBPruylWkmkAlohEwhAAAA0GMwshWwnQu7aNDKGcjLJ5t8cGmN tIaSJLSQIQAwAGnY1zOUM7dm31GqztoqM+tkk20yxhplptiBIcUgQgBgYX1csrrw3EJ6Sq6g jZWygQwzeg0DTTbGwS0kSRECQoK7tVRY4KQNUjnOnHTaMrgnx9DhPcjdQGAAAGBBNsOP592y om+x0FM5tqxwdGSKEwNvXZu0zB8YAAAAAEBx/Nu29U3wdaVI5Lfkwd1AB0PVUZGBMdQQVmnF W6cVjn12uXekOP5t+8qk/JPNGzkV+XAW0AHg9XxkgIt2dqVbim1KDcoRLaNDz+sQcfzb99XK RKLrSmcfvy8/spAPB6wUszv5UqFlPqwWmfWxOtdOi3zbZcLCDkGbob2tyJRekltceuzc/spA PB6nlDJdLkXGbTjI2VrhdV3wwsKdN2np0+PZuhuanJknpJ1rj9+XAWUgHw9TTqrb8zE62ZRq tGRiUEyrlVaNRyO/Yp8fzdDZUykyTzT0lyG/Jg7aSCSL1JZVV6ccWyi5ydGp04YN2aVXoYnV fYOtYUaOO5t+tpm+x5j8lyXRjw1tBBJa9Tzrp9WCTXc/CxmUGpQJkWyi/wAHUehbxrNv0lNk kT7bgcr1YsVdmA5DXqiVdVoyRqdFTfmkW0ajF0oV2eNZTLq0W2TdxfNvu6pyk3geZzDVix92 Ygks9TyrIKu2ip0Zb3NruM20gq9ONEoyab+RYurMhOZFyYyeDm+vDd9fhQ08bg6fqdwj2VQb s4C/w9MwIGZV1+jKy48t5vdUnKhOSm/F4Xbz6jdy0ptUavUldkO2iPZVPp0ya7UgQIlFiVbU ocixdVuUZEJyIzfTbEhgAMtQbBDSBECGkAhxSJLIif8A/9oACAEBAAEFAtu26PJamNstZdow 4pMfZcfIhj2zEnhdE5rrShQoU5O2J6PAy+227M3GzoZdn7b3nI2/sHHRkG77YrZLCwtKFCnI w8l+OJus5+VyDBlSebyjDcH47klRHSKwVpaWlCmtrCZfDi2du4SZ7EWN0+dkSRvq4sFYKwVo rRUKFNTPBYu/bja3Y5JWx52ZM8z96xcN/wDVbef1O3Cdzbe5y7RkC7Lki7HlC7Dln4DMP5/N P57OP57OP57PF2DORBGiQsLS07libJvD49u8emwrBgp26/M2nuRm4bmx9eRJ9MRoiCIWncit ZvjHbhi5X42JsGJtm2yJtuzNw+4pHROIpUemp/yCIIgiFDvX9hwh+sqOa906Ujjt4z5E4+PJ YmDlrJwd8giCIUKHe/7HhB9ctag/Lhaedaq1e4VaLM4wGL5gd9MaJx75/ZcIPrqZ2VJJktxY UbE3JgG5XwOyJHpLVseP4TUHfTGice+v2XDH+4mUy18vvUcyrJuWJO6Rm3Z1s20ua7ExMlcR uHP5jYYI/Lr9Mao1SoinfP7PhB9yvV+ZFFMxmCkUeXC6Qiys9gyTPe7M89HJiybkkO34z4IF +mNUa4RRFO9/2X+GP9cyFIXyudbYZWJKr8Zuaj5IcsxfNRyxea8VfkGuEURwineq/wDS4Y/3 P+5fvwoaJM8jelHNPEJmkD74l+Qa4Rwji47xX/o8MX7r/ZmOvndQ/IZqGK7JnkdjD4nIKxaY TlYrvkGPEeI8Rx3ctdwRHKqoqLh/eL81jTIxsZw7Cw79uxkYzhPC5HLH8MU9zRrxrxHiOO6l 9fsMbG4u/Ix2LhfeSpRfEJX1MeDxHcZU+GbxLarUa8a8a8R53E1jszDzXQNzMvxzEaxMyVVo 6JRcbrE5T4yriryW+1UmEjdUSo24bcJcSeBX0J6ETydfXHrT1p609eevF88euPXHreH/2gAI AQIAAQUC9oXnVLi4T2FEKHuLuenCp0URC0tLS0tLS0oUKFChTUz2NnsbeSjUKoPbTkN1WKWc UH+7WmljaJcdFLS0uQVa8hNCDerFQQdwVvJTS1aFw1RWoUQbQcjeQ3S0Xg1w6gioOoLTW3S0 eogvCggutumui4rwfrbqTg9eKKVFTUwY3pI3oIUEHLTQgmtgx9Bzq8alwuqvsv8A/9oACAED AAEFAuFSpXnrpavOoWFgqcETnqtBHHvEZz14UERUFdQvLy8vLy8vLy4uLi4u1Sexyexv5LnK KjkIpK8h+pZEPE4uIk6636ZHVWxCitEeXKpYqjUpyHaFHfC9HdXDEFEdyXaXpUsoOSoj3IIr h9yDFfTW/S4aqnuHsUZcK1xHVFStdT9LyNo5RF4VHDVqmp+lU68PetgqFCPXJqUUjbxc0oNd qkJHVdE7qKVFUa2uhRwnv0yL1ey4Y20rwtLBNC8Ka+h0OnHodOR//9oACAECAgY/AraGJPWC jJ//2gAIAQMCBj8CslqC+cU2xNSywgvWRmTyBCT/AP/aAAgBAQEGPwJ7nuIkgBCAwJJJNwAa ofzGf5qSFOpVlqOb3jWmpTtaLY7LF31B/eURe9tSnAQTn5atOGmWYOa5odqdC6OtFrhBwsIP ps1sd/41U6jmco+p/wBEzy1G6z0bY/gskzNAz/wsxK03tYW1YBUTlK5ZlM9FucF0oY48MV/0 KJEWCtJzsQLFZa6HMPxtGHWb7R6YytBiQcQQRHEQ1ro9t/Krj/W/lTJ6lRoc2DWh7oT4g+q7 1rp1P8juVBlOo+FOo1z6s5IEhBlHxE3byc4CAJJA1emLoRKqVXh0HwBafZZgpXRAMI6xC4jf GClqObD4aJPP33GyUfKOFW3CxoFgA3h6aNYysxdh69SIpEGNgxCDzRcS7pO17SUC3LuMNRBK Y2ox5nbMIDlX9urwDlXQq8A5UGyVLTC4cqvauk1dJnt5Fezh/JXs4fyV7OH8lezhXucK9zhU eZZv6eiI7NOTpO6Lw1p9b1Vp0sjWqCk4tJbUJu/SqVRlCoXPqd29hqdFGlWpvoSHmvNSI5pT spQD5Q0uZVeRzofLBQNjhePQO2HdZFzjBokJP61mXZXMZYNrPLomo04mCpf7VB1c1e8rfcEA FXbm8xSaX1ZqT2VATBHMUZG5IUZGCPOjAYKIdB4uK+YXjdu2HdUfK+o6afWbxqdtvxBCTnOd 0RyqJMXnpHTLSb+pTzmbapH9MY6HbDuqPlfUdNPrt49BN0byr1BrbVbwKAEdBOA0O2HdUfJ+ o6afXbx6KeUpGWe1ztTUQGgu+a1TV4B+pupW2OwQDbNl6c+se7psEzsbEWsjZe446HbDuqPk /UdNLrt41LwqjWf/AG6jZI76I9qzLe4c/Mvqh1HMC5rLIW4QtsVXuKL6k4qieowNNoNz5rbb LlmHZelJUDqBoObZCEJ4fiq+WzNIvrlhg5zBznR+ONq73+K/+HEf61kejCMIwsK70AtM1QSn ATGxO2HdUfJ+o6aXXbxoru6oi1QbWfLqJHJFZfuotteS4W+6mUDYXgVCSLW6x61MJzVDCDzL GkkWBOEzyRCSDb1TDCQ233Y86OO8pHkFxc51nzGKdsO6o+T9R00eu3jRRUnuoHDFOqsIi7iT rb71CYQ1qSaAKg+0a07Yd1S8r6jpo9dvHpiVBSlWKDr0HIOxxTth3VLyhxnTR8xnHosEx1Ln CUws+5ZYvuNpR3njlXPAEYSFpjFc08K5wUMFIcbk7Yd1T8ocZUGgknAKBsOoqh5jP3BFRQiw WXKbuxFTQhgwb2mLbjgo+8E5rulA7qn5Y4ysu2gZa2YJNWrjZgE/vbcxRqStqj3gdaoeYz9w UdNvQF+5svNgVRsLhHdNJqBvMFh2lSTsNMwMro3qBqNDG2hrQVQhUDvu07o/EjyK/wBitJ12 BBsIatF3sR3t5HkR3vlT46o3br7skfmh+K8LsrwuyhL3U2EJV4vaXidpeJ2l4naXi9peL2l4 vaXi9peL2l4va0f/2gAIAQEDAT8hIQoC3YY0DHAXupWf7BkSjjQTcevuC7mW1ioQwpP5pKp+ CIAa4RE2Pq5UqVK61KlfkkBewEr+g4gLssVyBdnxxcTY1zgS62QYr2cRt2oNByPMuF7SuUuV yn/Lselhll6VSpUqVK6YoINpABFWkTbwfEIsPwhkHbbi9jnk8OmDMriVKirSMDFspqeEXYlu vjqbLD0qlSpXoKZoGD9fzLbI7Cfm8IvHQGxX5TlQQ9WkH3kSc5PZLRgBReGDAe0fUZFhipXo pUUqBYrhHLvAMohYbIn7IOpRPFwq1lsENMUrvPJFxeKii6pEI9cZMnCkF5WoV/u/5Ef6v+RX +kP+mQ/99D/30P8A0f8Ak8v5/wDJ5Py/5G7wyfuTjpXb91SHStYwzuqGH2jVoS2lV1GwIExe M6bGWChtVeTBWrgujoRh2Cg33maHO+P9PMqVKlSpUqH77icemUZAKWgM2Wxrzqs2cbigNU2D QPLu4Gex6pbPm9TCci8QtpeUbZUH4G/h7kfcYe1/p6K6/bu049Os1EUdPvXZGG4V3Q7eSffu N9gczI2L3f8AA6LRc70c9kyG7NKEuTIdx0+/dutihBl6LPsHZGCRBeBfvF6bPiF0nyY9s8Io +8eZg8dpW+pv56fZu3UYEr0Effe3ov7rm2O33eJT92HIvlcw+i45rDxh32M35JtROeT4gdmR C3/UqUCtCi5djzLJ9m7TiLpIT9N0Kn2HtjXTnPsmuVXxNP8AInCjiMF93cbzsgt/K5SrdSk7 wLQcIZ/PeUBUdbgMh/Kcb2/FhNpS6AJ8ydi4C8pV9iaKn3btOOqmHQX4EOINMPsP8eZvzX4l OL8Pfv4gSl6Yr5/slIwCewry3e3GZdIGABN5XOqjHOeU4KM4iI5iCh5VDDPzd6GlB0zx7y7p O65efa59w7ekPDH+J1X3rthv3Ssgk88nxFEdtIGhQW1prjiXIMgT/tTHeD7n9TWmBx/kQ+Gj H8bn3jt6BaDLPZx46an3pnKU03MPZcsuwikuoe8IWNXB4ZVRxueHle4h+44l+gwi6V8Qrn8T PzfwZWUUmoyaXBtm04S39Lq5Xr+VHcti5hDvXhMu3mHX6oxlHnibpcMdefuJ9g7dB9NIyN6j Aq/BG5o7Ck+OgzH3oCu1ymOL+29y+F4p7fiDjTXgdDLWhyO/aN2smI2t83fEvrZdGyVBEdsK Dc3gPzG2poGxkR+eixvJjSOq4i3+W7vaABRg463V8kzQ3qIGSjUfcyS/SAvuwi5e9iIdCJgt 0mR7xK62EL5vbLajAAXh3mi4PJlNyxvPTMyzXuDseZUGuuDXt7yszF8YmfahrynYOnu9oFQO KqrMwluFnd4MwvcLJmz3l9LwRdsfbFTTHjfUX2T9k1jMhzL4quY+MGZiYmJj7s3o1/06P//a AAgBAgMBPyHpUqVLl/VPSJf1cOor6LUv61kTUG0RFv6wthEkWCsvLy8vLS0tLy8v9PsTH/iV K/8ABp9HmQTFTePoaeoSecoJUMf1UEfEVF0xzgDcQ8xl9WFxyMpOlViEwX9a2RG7olF34/mJ /SI9quWnEsNx9enpEIZl3C0xM6O4uYMevT10wQehw0+vX0lCGYEuiHdCBgvPr19N9ATh69/o ryerSAX5hUHoBPlejaVjrpXoGIntnexPMIdIc+glx9bMzMzMzMzP0P/aAAgBAwMBPyGX6BUq VK/8DglSpUr6TeUlJU9Ef/BkG4gYnMCvrOiMG9AGKysrKykpKSkrKysrK+tmZmf/AAsS5f8A 4Nvo68ZS8zRd/Q29QJV1LWXFN36G3pUeT+IBxDIjDHUhsYgij6G/ofEdK0kuj+sv6Gen6O/o 5gYMKsLNZ5/ie8cxDZeHbyS5zjUrauvbm4evb0EcQ1xKhmHMJWd5MJc53r36vXR0OCJPKDmZ j17+m2HBFlQeyd2MKsevb0gdKlXUg4jh5l2Hfq2i0cRbPoeqvePRrLViLToPo7TiHlTcPhmC 7RjFIzXpVDLoQ6tT4T4T4THiY8T4T4TExMTExMdP/9oADAMBAAIRAxEAABCyuyQACDsMWAD4 6cW2tHaAI/esz43eM5ojWI75nRIbQqnQt/to6tI+0i7TBuEz1gIkB1ucGKDTKirwlWRaM2wk 6l2WCGkZChQ0ACFri7GPFgGOkTEmxXng+TR8WsikZOBw/TsWUbNTNCRWHU05ubkaTTGHIBHV BOMszTxsNaJaNcOnwTINnXy//9oACAEBAwE/EDV4mW/CM1hWLjvQqtfKAQRZHp223goMRYrY hs4lGW+Mwd8Beb4gAyDV4yAhCJXUB0jDDXTbtLS3oxAQIWhtFIFuERXqt8WNwCs7Z+zL31PU R0sBUWQDxHTUXHKmncJW8m4MM9MLtYU0MkrkJIbUSqFtXRtPpqeGUcTw9BjXoOgQRTULKCwr lszxdIy4CppGkNW2HOYuboDmidKoa445DgBFLB1dv0I4XKKlh6HJpICuxqUjieHpVdBlx6Ho BKxGxiLn0tZagt7WCJoVemMVlZTeBiPu5GpYHcBfMw4WEftslKqg82VdOpTtBlwNGA+wmbU3 Yh6qVmonb0PNYxUCBhgsxUqAJYI7hRzUKZ4QjADY4GJEMtfcEthLYSwxTlsFr3rMzbD5Wqqh MlS01PaJaUrhmxCQuu9mkk9ZH6bJIvTxJ1LOuparho2MdPLK/qJoV0FyGTK6oncMvbvvdS5F zHxjwhCdW1TmmmHly4AYHMGWXufNYIuERxrUyvx9Ku2boux1uGBpsTHYCtz9QLimlWp0jycc uikR01lZSGh9t5UFjEv4njjlH6JXSxRdAGYm1w6XAMipE/SwJFk7lYc4l+7wF0W1RGXOeJWX VM5mqy0VyyjR3IYdhWXk+TMPQub+XCLVnD/fotWut24/++V0OOLDfEoUngJR2gNU4kFhz7lL e440+8KNAqLWsPI73cbmTzROLGgPYB/cYSLQXGJUZdV58F4vvEiYdgO/MXtBaNe78nQff85W KhYhIgHES3aGj8eplNjlmSjRAqcrmpfNwUM+1pOzIKj9FsFt3xXBFg2HHg1vxAtigIqVL2zi 8Q6H7bnKxAYxCrpDcwgfh1RKUFqlFqvEYYPlGoX23wl6MQ9GYbyzth1cctTVWb038QJB91Dm pd3hNXyYGfxBBVZTtVYq+VbmU4bbCCcA01rUE0j5J9s7+gqI48QlEIVwQKt/U0syc+OilRer 2eDr5jmL1XCaLxl/KI9FwavtFGn+S72DhXZ7QdfypMBJpRQWuKhR2pMVCIHDp8zlFKlqLc84 zxUTYXMQrJqm33LJcTwQqrV1KVRPvvfKYQ3LJWO8xy6I/wBogJvt38QsOxPZmeVBD2wj1HW4 6GgmUdyJiiJGDQPBCqKpeqCEXVaFhUyIojhTY6til1zlh6aGtl3FfWHO5rwclTNEkW+ypOEq W7MJSgAgDjlwwff85xMxACWOYOBLJJy9z+Holv0Ge1/9wfMr+Y4OVojoVZ5Ts+ZwsB2+zLw3 hJcJXLBedwdFYoBESnBfJRMuRohEqxfh+4CWiBVA6E+VSx6I2QZWM092fiCvvs5bUBqYsTAh qJ7GmP8AM/voK5Yr7/05jx2xtHexPIQP4PiHfRqFG5A9peV2sTT8Q6WqAzwr6dmE1t+gP53N j9ylPi4+I7MRHszPYkLn7n9wAXhruYEzsX5nUHm25o8kuS8FsEuYNqBgCmwK8wuGdGwIcjgY YfmsytU1ABVqArsfzuVtghlrH2eJlCPl+RiXWZxTmiIcbHxa+Sfbu6c/P9xAZjYlkwSwdim2 QM83gFYoFaYV2UCSqDqRglwI/cqxbe4bQ2CONcKcXRDbeUKi1W2BbhZcKlHeDzolQWUlmqdS wM7BwcrGh4lMc8Q9JyMxTuA0Rfsm/wA/3EKzNOY7mYd4lk8UamwF7Aq8YRyrlSnmhUKxeCnZ McwWfeRURhU+8r5NREGlD5InsWa/3CAAAAMB2IsYFwvVAWQq9leX4mAo+xdv8Fk3vz/c1WwM UyjmM8wjZYMNCiVn9TfqDuZhaFeDKOKRXVtC6eWPYYlQN7YNSgiXpLTdUlbp7R9pXGiPg7wa WTa0O4Z+EIMO5CBe1tmUGGaDO9X+cylLTWCsasp1fMTcqwaW3KvJLpt0bjWs5ggnbYGaL3Cd phQqDtEC7ZKm9ef7j7WLgpQ2/JO4fknABZd9qtqu48n54uV5kE753GWqj5/lh9sl2SdtXh9n RZXwv5jxwXt8Jc28+7j5lvaf/9oACAECAwE/ECV1HqLly5f0X6ec6Lly5cv6AotLylfQxbHK XBly5f0FiPxGUjZIYxliq2XLgy5cuXL9QULABibphnZmlnmJ5ieYnsT2vUFFpaW6XLldBZ8z HacMTs9Fy5cuXL9JKmnzCzSThnmUpuLCV9KoEqbvQwJfQLm4/iN4Kg9h6KgSoE2ek6QoLUNC Fi16B1HfoIQOmvpAm9D3i0VQ8TGXrz3nE1EVymly/UsDK6kIdNfQeZQPIgCwtWbvEvI/jM8o mD5jF6jBlwZr6DARLki5rPn/AGoPPxh9uIu7Bfu7PxCqaMc7Acsq2srvOo1gX71itmd/n2iO OpBhL9I9AbuhpgwJx9sKUTYrM17JC77R6kGD6I3HosaJyxbsncjyJZiX56L67vfqbi9JFr6C HWdlDdMG75lSnHVOtzf79SGopxC9K7HjfUkrYhlXE8Y6JEldNvvGQaYlAquoR3iEVyljaX1d RkzqEo95UYSJKhrtrMAoT3XH3FHGYJq35ipnggzREe70OmU7SwlRqNRqYhfFz5T5T5T5T5T5 T5TMzMwuZmfPT//aAAgBAwMBPxBa63sh3w9AVKlSvWar005ekKlSpUr0jtPIzyMw3HRGiBRU qVKlRJUqV6agDzLAzMZjHgQxRKlSulSokqVK9C3BcSts1xG72RgG8zxs8bPGzws8bPGzws8L PGx888TPAz3OtHVU34nuIucWt+ipUqVKleq5v8RtV3HbDqWsqV0Pp3Lmr29Nyui0TQfmAZ/l EHG/fpeuj29LiYNYMoZjv4ixoL6K3Gg6HRj10e3oWLhWy9v+uIcgF85/LNWX47QN8PENDH+Y HlT8s+zD6GPXV7emdpA/r/IiFRDh1a/895QFxRhxjGuJkUdoPma/7DOoehJUSavb0OUwvhga X2s/y4lNzNkz8vfzABNNPI7nzF1gM8FwHfEty00033VgBezu8DjVZ425luYdalSpp9ur0b5e sNA8RRUv7EuZ2/fEZjT78TP8H77RCmv6h6KiTT7ddIRHEoWyzENLTtwxraVVFJB1rpU1+3V1 AqJBlU54IA2wqyimkSq4ju/M56D0rpp9urEpgm4xnYlK23XW4LDNrhF7RLgweun2gR9sv7l2 bpc+0ZVmNZZEudf34gdTcDzHES1NU/6S+gMGXGACf/qNW4Flca3+plBW5aiNo/EIlMJ5ijlg jCvQLIvvK1k/EuWloX07lT7MT7MT7MT7sT7sT7MT7MT4/qPsnwj7J8J8P10//9=9 --J53Q906g8Kss7d3mi7sYH32TO1639SEo44D-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hallucination@24i.net Tue May 27 15:53:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KgeG-0003Ni-01 for ; Tue, 27 May 2003 17:46:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 17:46:00 +0200 (CEST) Received: (qmail 20598 invoked by uid 65534); 27 May 2003 13:53:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 27 May 2003 15:53:14 +0200 Received: by moria.seul.org (Postfix) id 96B4D33C5B; Tue, 27 May 2003 09:53:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C369733C61; Tue, 27 May 2003 09:53:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 975A333C5B for ; Tue, 27 May 2003 09:53:02 -0400 (EDT) Received: from 24i2295.com (f199.ac131.FreeBit.NE.JP [43.244.131.199]) by belegost.mit.edu (Postfix) with SMTP id 0A42A121A36 for ; Tue, 27 May 2003 09:52:59 -0400 (EDT) From: ug0526 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C=C0=92=E8=8A=F3=8F=AD=8F=A4=95i=81I=81I=83X=83g=83=8C=83X=89=F0=8F=C1=81=F4?= Date: Tue, 27 May 2003 22:53:12 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="aa6da9f8-b074-4602-9b26-dff9e5615754" Message-Id: <20030527135300.0A42A121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --aa6da9f8-b074-4602-9b26-dff9e5615754 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://210.150.173.81/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @teishi@24i.net .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B . . . .=8C=C0=92=E8=8A=F3=8F=AD=8F=A4=95i=81I=81I=8Ed=8E=96=81E=83v=83=89=83C=83= x=81[=83g=82=C8=82=C7=82=C5=83X=83g=83=8C=83X=82=AA=97=AD=82=DC=82=C1=82=C4=82= =E9=95=FB=81E=81E=81E .=8F=DA=82=B5=82=AD=82=CD=89=BA=8BL=82=CCHP=82=F0=8C=A9=82=C9=97=88=82=C4=82= =AD=82=BE=82=B3=82=A2=81=99 . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://210.150.173.81/=81@=81=E1= =81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0 . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@ =81=E2=81=E2=81@http://dj.st36.arena.ne.jp/SecretDream/=81= @=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . . . --aa6da9f8-b074-4602-9b26-dff9e5615754-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Tue May 27 15:38:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KgeI-0003Ni-01 for ; Tue, 27 May 2003 17:46:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 17:46:02 +0200 (CEST) Received: (qmail 27099 invoked by uid 65534); 27 May 2003 14:15:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 27 May 2003 16:15:50 +0200 Received: by moria.seul.org (Postfix) id 2AC2E33C77; Tue, 27 May 2003 10:15:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BD2C333C62; Tue, 27 May 2003 10:15:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a061.home.uni-hannover.de [130.75.232.61]) by moria.seul.org (Postfix) with ESMTP id 90AFC33C60 for ; Tue, 27 May 2003 10:15:30 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id PAA01022; Tue, 27 May 2003 15:38:32 +0200 Message-ID: <20030527153832.00094@thrai.stud.uni-hannover.de> Date: Tue, 27 May 2003 15:38:32 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20030527121954.BB89333C5B@moria.seul.org>; from god on Tue, May 27, 2003 at 08:19:54AM -0400 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: [spam deleted] It somehow becomes boring, doesn't it? Maybe we should improve the S/N ratio a little. Anybody still alive here? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cyrano@nerim.net Tue May 27 16:56:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KgeN-0003Ni-00 for ; Tue, 27 May 2003 17:46:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 17:46:07 +0200 (CEST) Received: (qmail 9436 invoked by uid 65534); 27 May 2003 14:56:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005) with SMTP; 27 May 2003 16:56:11 +0200 Received: by moria.seul.org (Postfix) id 36E5733C82; Tue, 27 May 2003 10:56:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6104C33C88; Tue, 27 May 2003 10:56:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by moria.seul.org (Postfix) with ESMTP id 93B8433C82 for ; Tue, 27 May 2003 10:56:06 -0400 (EDT) Received: from nerim.net (crateria.nerim.net [62.4.16.75]) by kraid.nerim.net (Postfix) with SMTP id 2E6A540FA8 for ; Tue, 27 May 2003 16:56:05 +0200 (CEST) Received: from alisier.astrium-space.com ([140.94.82.18]) (proxying for 140.94.197.181) (SquirrelMail authenticated user cyrano) by webmail.nerim.net with HTTP; Tue, 27 May 2003 16:56:06 +0200 (CEST) Message-ID: <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> Date: Tue, 27 May 2003 16:56:06 +0200 (CEST) Subject: Re: [f-cpu] Look,my beautiful girl friend From: To: In-Reply-To: <20030527153832.00094@thrai.stud.uni-hannover.de> References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > [spam deleted] > > It somehow becomes boring, doesn't it? > > Maybe we should improve the S/N ratio a little. Anybody still alive > here? I'm trying to find a way to implement the LSU. nicO > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Tue May 27 16:38:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KgeO-0003Ni-00 for ; Tue, 27 May 2003 17:46:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 17:46:08 +0200 (CEST) Received: (qmail 30363 invoked by uid 65534); 27 May 2003 14:57:19 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013) with SMTP; 27 May 2003 16:57:19 +0200 Received: by moria.seul.org (Postfix) id 28F6F33C62; Tue, 27 May 2003 10:57:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A11033C88; Tue, 27 May 2003 10:57:17 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 6253C33C62 for ; Tue, 27 May 2003 10:57:16 -0400 (EDT) Received: from a51-137.dialup.iol.cz ([194.228.137.51] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19Kfsp-0006oq-00 for f-cpu@seul.org; Tue, 27 May 2003 16:57:00 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19KfbB-0000O6-00 for f-cpu@seul.org; Tue, 27 May 2003 16:38:45 +0200 Date: Tue, 27 May 2003 16:38:45 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <20030527153832.00094@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: :) I'm in read-only mode these days. But present. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Tue, 27 May 2003, Michael Riepe wrote: > On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > [spam deleted] > > It somehow becomes boring, doesn't it? > > Maybe we should improve the S/N ratio a little. Anybody still alive here? > > -- > Michael "Tired" Riepe > "All I wanna do is have a little fun before I die" > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 27 19:44:26 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KlwR-0007Sy-00 for ; Tue, 27 May 2003 23:25:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 23:25:07 +0200 (CEST) Received: (qmail 11987 invoked by uid 65534); 27 May 2003 17:40:59 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 27 May 2003 19:40:59 +0200 Received: by moria.seul.org (Postfix) id 71AC133B7E; Tue, 27 May 2003 13:40:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B49B633C8B; Tue, 27 May 2003 13:40:53 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (unknown [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id A88A433B7E for ; Tue, 27 May 2003 13:40:49 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-28.n.club-internet.fr [213.44.21.28]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 56D127C1 for ; Tue, 27 May 2003 19:40:28 +0200 (CEST) Message-ID: <3ED3A3FA.4060602@f-cpu.org> Date: Tue, 27 May 2003 19:44:26 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, cyrano@nerim.net wrote: >>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: >>[spam deleted] >> >>It somehow becomes boring, doesn't it? >> >>Maybe we should improve the S/N ratio a little. Anybody still alive >>here? >> >> >I'm trying to find a way to implement the LSU. > > nice. maybe we should switch to a moderated list, or include an "active filter" : each post must contain a certain keyword, for example. >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue May 27 20:17:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KlwT-0007Sy-01 for ; Tue, 27 May 2003 23:25:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 23:25:09 +0200 (CEST) Received: (qmail 501 invoked by uid 65534); 27 May 2003 18:16:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 27 May 2003 20:16:46 +0200 Received: by moria.seul.org (Postfix) id 1F8D333C22; Tue, 27 May 2003 14:16:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1FA1533C8B; Tue, 27 May 2003 14:16:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id 40CBB33C22 for ; Tue, 27 May 2003 14:16:41 -0400 (EDT) Received: from homeworld (81.48.49.67) by mx.laposte.net (6.0.053) id 3ED26B800004015F for f-cpu@seul.org; Tue, 27 May 2003 20:16:39 +0200 Message-ID: <007a01c3247c$3a609a60$0100a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> Subject: Re: [f-cpu] Look,my beautiful girl friend Date: Tue, 27 May 2003 20:17:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: That's a pretty good idea. It is frustrating to fall into reading those kind of messages instead of interesting news. ----- Original Message ----- From: "Yann Guidon" To: Sent: Tuesday, May 27, 2003 7:44 PM Subject: Re: [f-cpu] Look,my beautiful girl friend > hi, > > cyrano@nerim.net wrote: > > >>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > >>[spam deleted] > >> > >>It somehow becomes boring, doesn't it? > >> > >>Maybe we should improve the S/N ratio a little. Anybody still alive > >>here? > >> > >> > >I'm trying to find a way to implement the LSU. > > > > > > nice. > > maybe we should switch to a moderated list, > or include an "active filter" : each post must contain a certain > keyword, for example. > > >nicO > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From christophe.avoinne@laposte.net Tue May 27 20:18:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KlwU-0007Sy-00 for ; Tue, 27 May 2003 23:25:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 23:25:10 +0200 (CEST) Received: (qmail 1946 invoked by uid 65534); 27 May 2003 18:17:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 27 May 2003 20:17:51 +0200 Received: by moria.seul.org (Postfix) id EE4D533C88; Tue, 27 May 2003 14:17:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8A32333C8C; Tue, 27 May 2003 14:17:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mx.laposte.net (mx.laposte.net [213.30.181.11]) by moria.seul.org (Postfix) with ESMTP id CCB2F33C88 for ; Tue, 27 May 2003 14:17:48 -0400 (EDT) Received: from homeworld (81.48.49.67) by mx.laposte.net (6.0.053) id 3ED26D050003EE66 for f-cpu@seul.org; Tue, 27 May 2003 20:17:48 +0200 Message-ID: <008201c3247c$62fba730$0100a8c0@homeworld> From: "Christophe Avoinne" To: References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> Subject: Re: [f-cpu] Look,my beautiful girl friend Date: Tue, 27 May 2003 20:18:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: When speaking about frustration, I mean about spamming emails, of course. Not yours :) ----- Original Message ----- From: "Yann Guidon" To: Sent: Tuesday, May 27, 2003 7:44 PM Subject: Re: [f-cpu] Look,my beautiful girl friend > hi, > > cyrano@nerim.net wrote: > > >>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > >>[spam deleted] > >> > >>It somehow becomes boring, doesn't it? > >> > >>Maybe we should improve the S/N ratio a little. Anybody still alive > >>here? > >> > >> > >I'm trying to find a way to implement the LSU. > > > > > > nice. > > maybe we should switch to a moderated list, > or include an "active filter" : each post must contain a certain > keyword, for example. > > >nicO > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 27 20:23:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KlwU-0007Sy-01 for ; Tue, 27 May 2003 23:25:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 23:25:10 +0200 (CEST) Received: (qmail 27575 invoked by uid 65534); 27 May 2003 18:19:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 27 May 2003 20:19:29 +0200 Received: by moria.seul.org (Postfix) id AD84D33C8B; Tue, 27 May 2003 14:19:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 566C433C8D; Tue, 27 May 2003 14:19:26 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id EA57D33C8B for ; Tue, 27 May 2003 14:19:21 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-28.n.club-internet.fr [213.44.21.28]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 7A23C1697 for ; Tue, 27 May 2003 20:19:20 +0200 (CEST) Message-ID: <3ED3AD17.4010507@f-cpu.org> Date: Tue, 27 May 2003 20:23:19 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> <007a01c3247c$3a609a60$0100a8c0@homeworld> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: who could setup a "controlled mailing list server" ? thx in advance. btw, i'll soon install faster network and try to move and secure the web sites for F-CPU. all help is welcome. YG Christophe Avoinne wrote: >That's a pretty good idea. >It is frustrating to fall into reading those kind of messages instead of >interesting news. > >----- Original Message ----- From: "Yann Guidon" >To: >Sent: Tuesday, May 27, 2003 7:44 PM >Subject: Re: [f-cpu] Look,my beautiful girl friend > > > > >>hi, >> >>cyrano@nerim.net wrote: >> >> >> >>>>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: >>>>[spam deleted] >>>> >>>>It somehow becomes boring, doesn't it? >>>> >>>>Maybe we should improve the S/N ratio a little. Anybody still alive >>>>here? >>>> >>>> >>>> >>>> >>>I'm trying to find a way to implement the LSU. >>> >>> >>> >>> >>nice. >> >>maybe we should switch to a moderated list, >>or include an "active filter" : each post must contain a certain >>keyword, for example. >> >> >> >>>nicO >>> >>> >>> >>> >>YG >> >>************************************************************* >>To unsubscribe, send an e-mail to majordomo@seul.org with >>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ >> >> > >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue May 27 20:25:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KlwV-0007Sy-00 for ; Tue, 27 May 2003 23:25:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 27 May 2003 23:25:11 +0200 (CEST) Received: (qmail 27221 invoked by uid 65534); 27 May 2003 18:21:19 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 27 May 2003 20:21:19 +0200 Received: by moria.seul.org (Postfix) id 6934A33C8C; Tue, 27 May 2003 14:21:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3341933C8E; Tue, 27 May 2003 14:21:16 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 0C87633C8C for ; Tue, 27 May 2003 14:21:16 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-28.n.club-internet.fr [213.44.21.28]) by relay-5m.club-internet.fr (Postfix) with ESMTP id CD5A7E041 for ; Tue, 27 May 2003 20:21:14 +0200 (CEST) Message-ID: <3ED3AD89.5060903@f-cpu.org> Date: Tue, 27 May 2003 20:25:13 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> <008201c3247c$62fba730$0100a8c0@homeworld> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi again, Christophe Avoinne wrote: >When speaking about frustration, I mean about spamming emails, of course. >Not yours :) > > not only do i get the spam through the list, but ALL the error messages for each server that blocks the emails + often the same spam through the french mailing list + directly. so yes, i'm .... extremely annoyed. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed May 28 01:03:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KoZk-0000qH-00 for ; Wed, 28 May 2003 02:13:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 May 2003 02:13:52 +0200 (CEST) Received: (qmail 17771 invoked by uid 65534); 27 May 2003 23:03:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 28 May 2003 01:03:23 +0200 Received: by moria.seul.org (Postfix) id 91AE333B4C; Tue, 27 May 2003 19:03:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7024833C78; Tue, 27 May 2003 19:03:20 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a175.home.uni-hannover.de [130.75.232.175]) by moria.seul.org (Postfix) with ESMTP id 88B0533B4C for ; Tue, 27 May 2003 19:03:18 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02856; Wed, 28 May 2003 01:03:16 +0200 Message-ID: <20030528010316.22603@thrai.stud.uni-hannover.de> Date: Wed, 28 May 2003 01:03:16 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3ED3A3FA.4060602@f-cpu.org>; from Yann Guidon on Tue, May 27, 2003 at 07:44:26PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Tue, May 27, 2003 at 07:44:26PM +0200, Yann Guidon wrote: [...] > maybe we should switch to a moderated list, > or include an "active filter" : each post must contain a certain > keyword, for example. We had an active "filter" in the early days of Linux development (10 years ago -- does anyone remember linux-activists@niksula.hut.fi?), and people forgot to set the keyword again and again. That's a bad idea, IMHO. I currently use SpamAssassin -- that kills most of my spam, fortunately. This one was the first on this list to get through since I added the filter. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed May 28 01:12:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19KoZk-0000qH-01 for ; Wed, 28 May 2003 02:13:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 28 May 2003 02:13:52 +0200 (CEST) Received: (qmail 4030 invoked by uid 65534); 27 May 2003 23:08:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 28 May 2003 01:08:52 +0200 Received: by moria.seul.org (Postfix) id 7B02F33C63; Tue, 27 May 2003 19:08:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D627233C89; Tue, 27 May 2003 19:08:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id DE67733C63 for ; Tue, 27 May 2003 19:08:48 -0400 (EDT) Received: from f-cpu.org (lcbv4-2-88.n.club-internet.fr [213.44.93.88]) by relay-2v.club-internet.fr (Postfix) with ESMTP id C8A7C16A1 for ; Wed, 28 May 2003 01:08:36 +0200 (CEST) Message-ID: <3ED3F0CA.8060302@f-cpu.org> Date: Wed, 28 May 2003 01:12:10 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <20030527121954.BB89333C5B@moria.seul.org> <20030527153832.00094@thrai.stud.uni-hannover.de> <3627.140.94.82.18.1054047366.squirrel@webmail.nerim.net> <3ED3A3FA.4060602@f-cpu.org> <20030528010316.22603@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >On Tue, May 27, 2003 at 07:44:26PM +0200, Yann Guidon wrote: >[...] > > >>maybe we should switch to a moderated list, >>or include an "active filter" : each post must contain a certain >>keyword, for example. >> >> > >We had an active "filter" in the early days of Linux development (10 years >ago -- does anyone remember linux-activists@niksula.hut.fi?), and people >forgot to set the keyword again and again. That's a bad idea, IMHO. > > hmm but probably the only one that could efficiently work. it's not difficult to create a "user" in a mail user agent and configure the signature to contain these words. >I currently use SpamAssassin -- that kills most of my spam, fortunately. >This one was the first on this list to get through since I added the >filter. > > ouch. hmmmm ..... any better idea ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed May 28 09:44:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcop-0002CL-00 for ; Fri, 30 May 2003 07:52:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:52:47 +0200 (CEST) Received: (qmail 28443 invoked by uid 65534); 28 May 2003 07:57:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014) with SMTP; 28 May 2003 09:57:25 +0200 Received: by moria.seul.org (Postfix) id 9F6B033C6D; Wed, 28 May 2003 03:57:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3AA4E33C65; Wed, 28 May 2003 03:57:22 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 9BA8233C0C for ; Wed, 28 May 2003 03:57:20 -0400 (EDT) Received: from a104-137.dialup.iol.cz ([194.228.137.104] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19KvoD-0002IY-00 for f-cpu@seul.org; Wed, 28 May 2003 09:57:18 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19Kvc8-0000Ea-00 for f-cpu@seul.org; Wed, 28 May 2003 09:44:48 +0200 Date: Wed, 28 May 2003 09:44:48 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <3ED3AD17.4010507@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: As I already proposed - I can give place on my server - it is connected by 10MBit to backbone and you can be pretty sure that the server will exists many tens of years :-) It already runs "listar" mailing list engine and I can setup majordomo too. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Tue, 27 May 2003, Yann Guidon wrote: > who could setup a "controlled mailing list server" ? > > thx in advance. > > btw, i'll soon install faster network and try to move and secure the web > sites for F-CPU. > all help is welcome. > > YG > > Christophe Avoinne wrote: > > >That's a pretty good idea. > >It is frustrating to fall into reading those kind of messages instead of > >interesting news. > > > >----- Original Message ----- > >From: "Yann Guidon" > >To: > >Sent: Tuesday, May 27, 2003 7:44 PM > >Subject: Re: [f-cpu] Look,my beautiful girl friend > > > > > > > > > >>hi, > >> > >>cyrano@nerim.net wrote: > >> > >> > >> > >>>>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > >>>>[spam deleted] > >>>> > >>>>It somehow becomes boring, doesn't it? > >>>> > >>>>Maybe we should improve the S/N ratio a little. Anybody still alive > >>>>here? > >>>> > >>>> > >>>> > >>>> > >>>I'm trying to find a way to implement the LSU. > >>> > >>> > >>> > >>> > >>nice. > >> > >>maybe we should switch to a moderated list, > >>or include an "active filter" : each post must contain a certain > >>keyword, for example. > >> > >> > >> > >>>nicO > >>> > >>> > >>> > >>> > >>YG > >> > >>************************************************************* > >>To unsubscribe, send an e-mail to majordomo@seul.org with > >>unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > >> > >> > > > >************************************************************* > >To unsubscribe, send an e-mail to majordomo@seul.org with > >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > > > > > > > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Wed May 28 09:42:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcoq-0002CL-00 for ; Fri, 30 May 2003 07:52:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:52:48 +0200 (CEST) Received: (qmail 688 invoked by uid 65534); 28 May 2003 07:57:38 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 28 May 2003 09:57:38 +0200 Received: by moria.seul.org (Postfix) id 684EF33C0C; Wed, 28 May 2003 03:57:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6742B33C65; Wed, 28 May 2003 03:57:28 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id E94E733C0C for ; Wed, 28 May 2003 03:57:25 -0400 (EDT) Received: from a104-137.dialup.iol.cz ([194.228.137.104] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19KvoK-0002Id-00 for f-cpu@seul.org; Wed, 28 May 2003 09:57:24 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19KvZf-0000EY-00 for f-cpu@seul.org; Wed, 28 May 2003 09:42:15 +0200 Date: Wed, 28 May 2003 09:42:14 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <3ED3A3FA.4060602@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: good idea. If it could be in headers too it would nice - I'd instruct pine to add some X- header to all my emails ... ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Tue, 27 May 2003, Yann Guidon wrote: > hi, > > cyrano@nerim.net wrote: > > >>On Tue, May 27, 2003 at 08:19:54AM -0400, god wrote: > >>[spam deleted] > >> > >>It somehow becomes boring, doesn't it? > >> > >>Maybe we should improve the S/N ratio a little. Anybody still alive > >>here? > >> > >> > >I'm trying to find a way to implement the LSU. > > > > > > nice. > > maybe we should switch to a moderated list, > or include an "active filter" : each post must contain a certain > keyword, for example. > > >nicO > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed May 28 13:32:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19LcpJ-0002CL-01 for ; Fri, 30 May 2003 07:53:17 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:17 +0200 (CEST) Received: (qmail 27642 invoked by uid 65534); 28 May 2003 14:33:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 28 May 2003 16:33:43 +0200 Received: by moria.seul.org (Postfix) id BB23933C67; Wed, 28 May 2003 10:33:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F80533C76; Wed, 28 May 2003 10:33:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a189.home.uni-hannover.de [130.75.232.189]) by moria.seul.org (Postfix) with ESMTP id 6B68833C67 for ; Wed, 28 May 2003 10:33:37 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00524; Wed, 28 May 2003 13:32:48 +0200 Message-ID: <20030528133248.17667@thrai.stud.uni-hannover.de> Date: Wed, 28 May 2003 13:32:48 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED3A3FA.4060602@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, May 28, 2003 at 09:42:14AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Wed, May 28, 2003 at 09:42:14AM +0200, devik wrote: > good idea. If it could be in headers too it would > nice - I'd instruct pine to add some X- header to > all my emails ... That doesn't work with all clients. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed May 28 13:32:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19LcpK-0002CL-00 for ; Fri, 30 May 2003 07:53:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:18 +0200 (CEST) Received: (qmail 29658 invoked by uid 65534); 28 May 2003 14:33:53 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 28 May 2003 16:33:53 +0200 Received: by moria.seul.org (Postfix) id 03C0433C90; Wed, 28 May 2003 10:33:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A080433C76; Wed, 28 May 2003 10:33:44 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a189.home.uni-hannover.de [130.75.232.189]) by moria.seul.org (Postfix) with ESMTP id 9719133C90 for ; Wed, 28 May 2003 10:33:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00519; Wed, 28 May 2003 13:32:18 +0200 Message-ID: <20030528133218.01078@thrai.stud.uni-hannover.de> Date: Wed, 28 May 2003 13:32:18 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED3AD17.4010507@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from devik on Wed, May 28, 2003 at 09:44:48AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Wed, May 28, 2003 at 09:44:48AM +0200, devik wrote: > As I already proposed - I can give place on my server - it > is connected by 10MBit to backbone and you can be pretty > sure that the server will exists many tens of years :-) Moving doesn't help at all. If the address of the list is published anywhere, spammers will find it sooner or later. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Wed May 28 22:08:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcpn-0002CL-00 for ; Fri, 30 May 2003 07:53:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:47 +0200 (CEST) Received: (qmail 10700 invoked by uid 65534); 28 May 2003 20:09:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 28 May 2003 22:09:01 +0200 Received: by moria.seul.org (Postfix) id 55B4F33CBE; Wed, 28 May 2003 16:08:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B6CA33C91; Wed, 28 May 2003 16:08:56 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id CF33A33C5D; Wed, 28 May 2003 16:08:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id CBE75FA8B1 for ; Wed, 28 May 2003 16:08:55 -0400 (EDT) Date: Wed, 28 May 2003 16:08:55 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria.mit.edu To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <20030528133218.01078@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Wed, 28 May 2003, Michael Riepe wrote: > On Wed, May 28, 2003 at 09:44:48AM +0200, devik wrote: > > As I already proposed - I can give place on my server - it > > is connected by 10MBit to backbone and you can be pretty > > sure that the server will exists many tens of years :-) > > Moving doesn't help at all. If the address of the list is published > anywhere, spammers will find it sooner or later. > Sorry, but I've been away and hadn't followed this thread. If there's a problem with spam levels, it would be worth someone (michael or yann?) getting in touch with seul@seul.org about the filtering... One advantage of being on a server like the seul one is that not being a commercial service there are real people you can talk to if you want something changed :-) best Graham > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu May 29 00:44:25 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcpu-0002CL-01 for ; Fri, 30 May 2003 07:53:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:54 +0200 (CEST) Received: (qmail 29597 invoked by uid 65534); 28 May 2003 22:41:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 29 May 2003 00:41:00 +0200 Received: by moria.seul.org (Postfix) id E99C933CC1; Wed, 28 May 2003 18:40:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E42E433CC0; Wed, 28 May 2003 18:40:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (unknown [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 7254333C7C for ; Wed, 28 May 2003 18:40:54 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-25.n.club-internet.fr [213.44.18.25]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 08D4E169E for ; Thu, 29 May 2003 00:40:23 +0200 (CEST) Message-ID: <3ED53BC9.8080105@f-cpu.org> Date: Thu, 29 May 2003 00:44:25 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Graham Seaman wrote: >On Wed, 28 May 2003, Michael Riepe wrote: > >>On Wed, May 28, 2003 at 09:44:48AM +0200, devik wrote: >> >> >>>As I already proposed - I can give place on my server - it >>>is connected by 10MBit to backbone and you can be pretty >>>sure that the server will exists many tens of years :-) >>> >>> >>Moving doesn't help at all. If the address of the list is published >>anywhere, spammers will find it sooner or later. >> >Sorry, but I've been away and hadn't followed this thread. If there's >a problem with spam levels, it would be worth someone (michael or yann?) >getting in touch with seul@seul.org about the filtering... One advantage >of being on a server like the seul one is that not being a commercial >service there are real people you can talk to if you want something >changed :-) > > :-) but what do they propose ? >best >Graham > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu May 29 02:02:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcpx-0002CL-00 for ; Fri, 30 May 2003 07:53:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:57 +0200 (CEST) Received: (qmail 3719 invoked by uid 65534); 29 May 2003 00:02:38 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 29 May 2003 02:02:38 +0200 Received: by moria.seul.org (Postfix) id 4DC9B33CC2; Wed, 28 May 2003 20:02:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0F21C33CC4; Wed, 28 May 2003 20:02:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 095A433CC2 for ; Wed, 28 May 2003 20:02:35 -0400 (EDT) Received: from localhost (miel.brainstorm.fr [80.67.170.17]) by miel.brainstorm.fr (Postfix) with ESMTP id 55AF81C889E for ; Thu, 29 May 2003 02:02:34 +0200 (CEST) Subject: Re: [f-cpu] Look,my beautiful girl friend From: Antoine To: f-cpu@seul.org In-Reply-To: <3ED53BC9.8080105@f-cpu.org> References: <3ED53BC9.8080105@f-cpu.org> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1054166578.2769.0.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4-1.1mdk Date: 29 May 2003 02:02:58 +0200 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Le jeu 29/05/2003 à 00:44, Yann Guidon a écrit : > >Sorry, but I've been away and hadn't followed this thread. If there's > >a problem with spam levels, it would be worth someone (michael or yann?) > >getting in touch with seul@seul.org about the filtering... One advantage > >of being on a server like the seul one is that not being a commercial > >service there are real people you can talk to if you want something > >changed :-) > > > > > :-) > > but what do they propose ? I don't understand. Why don't you make the list subscriber-only ? ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu May 29 02:08:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcpx-0002CL-01 for ; Fri, 30 May 2003 07:53:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:57 +0200 (CEST) Received: (qmail 26184 invoked by uid 65534); 29 May 2003 00:04:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013) with SMTP; 29 May 2003 02:04:29 +0200 Received: by moria.seul.org (Postfix) id 5B1B633CC3; Wed, 28 May 2003 20:04:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8B4BC33CC5; Wed, 28 May 2003 20:04:26 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id B542833CC3 for ; Wed, 28 May 2003 20:04:25 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-25.n.club-internet.fr [213.44.18.25]) by relay-3m.club-internet.fr (Postfix) with ESMTP id CD14BE08B for ; Thu, 29 May 2003 02:04:20 +0200 (CEST) Message-ID: <3ED54F73.5030801@f-cpu.org> Date: Thu, 29 May 2003 02:08:19 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED53BC9.8080105@f-cpu.org> <1054166578.2769.0.camel@fsol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, Antoine wrote: >Le jeu 29/05/2003 à 00:44, Yann Guidon a écrit : > > >>>Sorry, but I've been away and hadn't followed this thread. If there's >>>a problem with spam levels, it would be worth someone (michael or yann?) >>>getting in touch with seul@seul.org about the filtering... One advantage >>>of being on a server like the seul one is that not being a commercial >>>service there are real people you can talk to if you want something >>>changed :-) >>> >>> >>:-) >> >>but what do they propose ? >> >> > >I don't understand. Why don't you make the list subscriber-only ? > > Some people can post from other accounts or from the office/work, for example. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From antoine@rezo.net Thu May 29 02:11:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcpy-0002CL-00 for ; Fri, 30 May 2003 07:53:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:53:58 +0200 (CEST) Received: (qmail 24241 invoked by uid 65534); 29 May 2003 00:11:34 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 29 May 2003 02:11:34 +0200 Received: by moria.seul.org (Postfix) id 1AAEF33CC0; Wed, 28 May 2003 20:11:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0020633CC5; Wed, 28 May 2003 20:11:30 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from miel.brainstorm.fr (miel.brainstorm.fr [80.67.170.17]) by moria.seul.org (Postfix) with ESMTP id 6F36733CC0 for ; Wed, 28 May 2003 20:11:30 -0400 (EDT) Received: from localhost (miel.brainstorm.fr [80.67.170.17]) by miel.brainstorm.fr (Postfix) with ESMTP id C8BCE1C8087 for ; Thu, 29 May 2003 02:11:29 +0200 (CEST) Subject: Re: [f-cpu] Look,my beautiful girl friend From: Antoine To: f-cpu@seul.org In-Reply-To: <3ED54F73.5030801@f-cpu.org> References: <3ED53BC9.8080105@f-cpu.org> <1054166578.2769.0.camel@fsol> <3ED54F73.5030801@f-cpu.org> Content-Type: text/plain Message-Id: <1054167113.2769.3.camel@fsol> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4-1.1mdk Date: 29 May 2003 02:11:53 +0200 Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > Some people can post from other accounts or from the office/work, > for example. Then they can subscribe for all addresses and disable receiving messages for all but one of them. Many mailing-lists work like this. Spammers never bother subscribing, so their messages are rejected. It's the simplest method, and the most efficient. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu May 29 02:20:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcq0-0002CL-01 for ; Fri, 30 May 2003 07:54:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:00 +0200 (CEST) Received: (qmail 16680 invoked by uid 65534); 29 May 2003 00:16:48 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 29 May 2003 02:16:48 +0200 Received: by moria.seul.org (Postfix) id 8507533CC5; Wed, 28 May 2003 20:16:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EA6C133CC6; Wed, 28 May 2003 20:16:44 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 65E3233CC4 for ; Wed, 28 May 2003 20:16:43 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-25.n.club-internet.fr [213.44.18.25]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 256851683 for ; Thu, 29 May 2003 02:16:37 +0200 (CEST) Message-ID: <3ED55253.8020708@f-cpu.org> Date: Thu, 29 May 2003 02:20:35 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED53BC9.8080105@f-cpu.org> <1054166578.2769.0.camel@fsol> <3ED54F73.5030801@f-cpu.org> <1054167113.2769.3.camel@fsol> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, Antoine wrote: >>Some people can post from other accounts or from the office/work, >>for example. >> >> > >Then they can subscribe for all addresses and disable receiving messages >for all but one of them. Many mailing-lists work like this. Spammers >never bother subscribing, so their messages are rejected. It's the >simplest method, and the most efficient. > it probably makes sense but there is another issue : the list's archives are public, that is another way spammers get addresses. i the archives and the list are completely "private" then communication with unsubscribed lurkers will become more difficult. there is a major problem here. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From graham@seul.org Thu May 29 02:43:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcq1-0002CL-00 for ; Fri, 30 May 2003 07:54:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:01 +0200 (CEST) Received: (qmail 16225 invoked by uid 65534); 29 May 2003 00:43:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 29 May 2003 02:43:05 +0200 Received: by moria.seul.org (Postfix) id 0797433CC4; Wed, 28 May 2003 20:43:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EB14F33CC7; Wed, 28 May 2003 20:43:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 648) id B4B1733CC4; Wed, 28 May 2003 20:43:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by moria.seul.org (Postfix) with ESMTP id B2A25FA8B1 for ; Wed, 28 May 2003 20:43:03 -0400 (EDT) Date: Wed, 28 May 2003 20:43:03 -0400 (EDT) From: Graham Seaman X-X-Sender: graham@moria.mit.edu To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <3ED53BC9.8080105@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Thu, 29 May 2003, Yann Guidon wrote: > hi ! > > Graham Seaman wrote: > > >Sorry, but I've been away and hadn't followed this thread. If there's > >a problem with spam levels, it would be worth someone (michael or yann?) > >getting in touch with seul@seul.org about the filtering... One advantage > >of being on a server like the seul one is that not being a commercial > >service there are real people you can talk to if you want something > >changed :-) > > > :-) > > but what do they propose ? I haven't talked to anyone about it. It's not a question of them proposing anything - there are 50 or so people/groups hosted on these machines, and the (voluntary) sysadmins don't have time to sugggest how each runs their affairs. It's a question of YOU proposing something to them - if it's practical, I'm sure it will get done. All I was pointing out is that there are sysadmins, and you can talk to them if there are problems rather than rushing off to a new host where you will have the same problems anyway... Maybe spamassassin would help? (spamassassin.org) Graham > > >best > >Graham > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu May 29 02:49:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcq2-0002CL-00 for ; Fri, 30 May 2003 07:54:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:02 +0200 (CEST) Received: (qmail 6986 invoked by uid 65534); 29 May 2003 00:45:53 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 29 May 2003 02:45:53 +0200 Received: by moria.seul.org (Postfix) id 5D08D33CC6; Wed, 28 May 2003 20:45:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2913533CC8; Wed, 28 May 2003 20:45:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 6A30833CC6 for ; Wed, 28 May 2003 20:45:47 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-25.n.club-internet.fr [213.44.18.25]) by relay-5m.club-internet.fr (Postfix) with ESMTP id 07013E04D for ; Thu, 29 May 2003 02:45:46 +0200 (CEST) Message-ID: <3ED5592C.2090606@f-cpu.org> Date: Thu, 29 May 2003 02:49:48 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, Graham Seaman wrote: >On Thu, 29 May 2003, Yann Guidon wrote: > >>hi ! >> >>Graham Seaman wrote: >> >>>Sorry, but I've been away and hadn't followed this thread. If there's >>>a problem with spam levels, it would be worth someone (michael or yann?) >>>getting in touch with seul@seul.org about the filtering... One advantage >>>of being on a server like the seul one is that not being a commercial >>>service there are real people you can talk to if you want something >>>changed :-) >>> >>> >>> >>:-) >> >>but what do they propose ? >> >> > >I haven't talked to anyone about it. It's not a question of them proposing >anything - there are 50 or so people/groups hosted on these machines, and >the (voluntary) sysadmins don't have time to sugggest how each runs their >affairs. It's a question of YOU proposing something to them - if it's >practical, I'm sure it will get done. All I was pointing out is that there >are sysadmins, and you can talk to them if there are problems rather than >rushing off to a new host where you will have the same problems anyway... > the problem is no rushing off, but finding a way to stop spam. hey, i just got two in the last hour.... >Maybe spamassassin would help? (spamassassin.org) > > i am completely unable to know how to install that kind of things ... i wish the SEUL admins know. read you soon, >Graham > >>>best >>>Graham >>> >>> >>YG >> >> YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu May 29 03:10:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcq7-0002CL-01 for ; Fri, 30 May 2003 07:54:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:07 +0200 (CEST) Received: (qmail 12187 invoked by uid 65534); 29 May 2003 02:03:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 29 May 2003 04:03:08 +0200 Received: by moria.seul.org (Postfix) id 95CD333CC8; Wed, 28 May 2003 22:03:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B569533CCA; Wed, 28 May 2003 22:03:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a119.home.uni-hannover.de [130.75.232.119]) by moria.seul.org (Postfix) with ESMTP id 4955433CC8 for ; Wed, 28 May 2003 22:03:03 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id DAA03144; Thu, 29 May 2003 03:10:06 +0200 Message-ID: <20030529031006.16979@thrai.stud.uni-hannover.de> Date: Thu, 29 May 2003 03:10:06 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED5592C.2090606@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3ED5592C.2090606@f-cpu.org>; from Yann Guidon on Thu, May 29, 2003 at 02:49:48AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Thu, May 29, 2003 at 02:49:48AM +0200, Yann Guidon wrote: [...] > the problem is no rushing off, but finding a way to stop spam. > > hey, i just got two in the last hour.... I get 40 a day -- but spamassassin and a few additional procmail recipes kill 38 of them :) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Thu May 29 04:11:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcq8-0002CL-00 for ; Fri, 30 May 2003 07:54:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:08 +0200 (CEST) Received: (qmail 11230 invoked by uid 65534); 29 May 2003 02:07:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001) with SMTP; 29 May 2003 04:07:32 +0200 Received: by moria.seul.org (Postfix) id 5CED833CC9; Wed, 28 May 2003 22:07:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3726C33CCB; Wed, 28 May 2003 22:07:30 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id 99DE733CC9 for ; Wed, 28 May 2003 22:07:29 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-25.n.club-internet.fr [213.44.18.25]) by relay-3m.club-internet.fr (Postfix) with ESMTP id 56030E051 for ; Thu, 29 May 2003 04:07:28 +0200 (CEST) Message-ID: <3ED56C53.6000305@f-cpu.org> Date: Thu, 29 May 2003 04:11:31 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED5592C.2090606@f-cpu.org> <20030529031006.16979@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Michael Riepe wrote: >On Thu, May 29, 2003 at 02:49:48AM +0200, Yann Guidon wrote: >[...] > > >>the problem is no rushing off, but finding a way to stop spam. >> >>hey, i just got two in the last hour.... >> >> >I get 40 a day -- but spamassassin and a few additional procmail recipes >kill 38 of them :) > > \o/ there is a specialist in the room !!! :-) could you ask the SEUL team for help ? additionally, are you co-administrrating the list (i think no, but there's a chance that the others don't know how to help anymore). YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Thu May 29 13:57:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19LcrG-0002CL-01 for ; Fri, 30 May 2003 07:55:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:55:18 +0200 (CEST) Received: (qmail 12077 invoked by uid 65534); 29 May 2003 17:27:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 29 May 2003 19:27:27 +0200 Received: by moria.seul.org (Postfix) id B98B933CDD; Thu, 29 May 2003 13:27:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 841B333CDF; Thu, 29 May 2003 13:27:23 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a213.home.uni-hannover.de [130.75.232.213]) by moria.seul.org (Postfix) with ESMTP id 67DAB33CDD for ; Thu, 29 May 2003 13:27:20 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00530; Thu, 29 May 2003 13:57:49 +0200 Message-ID: <20030529135749.23563@thrai.stud.uni-hannover.de> Date: Thu, 29 May 2003 13:57:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Look,my beautiful girl friend References: <3ED5592C.2090606@f-cpu.org> <20030529031006.16979@thrai.stud.uni-hannover.de> <3ED56C53.6000305@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3ED56C53.6000305@f-cpu.org>; from Yann Guidon on Thu, May 29, 2003 at 04:11:31AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Thu, May 29, 2003 at 04:11:31AM +0200, Yann Guidon wrote: [...] > \o/ there is a specialist in the room !!! :-) Not really. I didn't install it, I just use it. And I have no idea if spamassassin/procmail works with majordomo (which is the major problem in this case). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu May 29 08:04:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19LcqM-0002CL-00 for ; Fri, 30 May 2003 07:54:22 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:22 +0200 (CEST) Received: (qmail 11132 invoked by uid 65534); 29 May 2003 09:28:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009) with SMTP; 29 May 2003 11:28:32 +0200 Received: by moria.seul.org (Postfix) id DCE1633C6A; Thu, 29 May 2003 05:28:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id ED1E733CD6; Thu, 29 May 2003 05:28:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 7122433C6A for ; Thu, 29 May 2003 05:28:23 -0400 (EDT) Received: from a44-137.dialup.iol.cz ([194.228.137.44] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19LJhh-0008F6-00 for f-cpu@seul.org; Thu, 29 May 2003 11:28:10 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19LGWO-0004HT-00 for f-cpu@seul.org; Thu, 29 May 2003 08:04:16 +0200 Date: Thu, 29 May 2003 08:04:16 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <20030528133218.01078@thrai.stud.uni-hannover.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > On Wed, May 28, 2003 at 09:44:48AM +0200, devik wrote: > > As I already proposed - I can give place on my server - it > > is connected by 10MBit to backbone and you can be pretty > > sure that the server will exists many tens of years :-) > > Moving doesn't help at all. If the address of the list is published > anywhere, spammers will find it sooner or later. I have not been proposing moving as solution. I was thinking that you have problems with access to seul servers to change mailing list settings - so I offered account where you would have all needed rights to install whatever is needed (spam filters ..). I use RBL lists which kills about 70% of spam but sometimes also block valid user (but the user is informed). I plan to mail back an email with pass-code and when user uses it in Subject then add the source email address to database of allowed incoming exceptions for some time... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Thu May 29 08:00:17 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19LcqN-0002CL-00 for ; Fri, 30 May 2003 07:54:23 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:23 +0200 (CEST) Received: (qmail 32636 invoked by uid 65534); 29 May 2003 09:28:34 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 29 May 2003 11:28:34 +0200 Received: by moria.seul.org (Postfix) id 0F0B033C6F; Thu, 29 May 2003 05:28:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6B87D33CD7; Thu, 29 May 2003 05:28:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 4503D33C6F for ; Thu, 29 May 2003 05:28:24 -0400 (EDT) Received: from a44-137.dialup.iol.cz ([194.228.137.44] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19LJhn-0008F6-00 for f-cpu@seul.org; Thu, 29 May 2003 11:28:17 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19LGSX-0004HL-00 for f-cpu@seul.org; Thu, 29 May 2003 08:00:17 +0200 Date: Thu, 29 May 2003 08:00:17 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Look,my beautiful girl friend In-Reply-To: <3ED55253.8020708@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > >Then they can subscribe for all addresses and disable receiving messages > >for all but one of them. Many mailing-lists work like this. Spammers > >never bother subscribing, so their messages are rejected. It's the > >simplest method, and the most efficient. > > > > it probably makes sense but there is another issue : > the list's archives are public, that is another way spammers get addresses. > i the archives and the list are completely "private" then communication > with unsubscribed lurkers will become more difficult. > > there is a major problem here. Eh I never noticed I can post even without subscribing ;-) I always subscribe into lists I use. devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gekiyasu@phreaker.net Thu May 29 15:35:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcql-0002CL-00 for ; Fri, 30 May 2003 07:54:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:47 +0200 (CEST) Received: (qmail 9723 invoked by uid 65534); 29 May 2003 13:35:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 29 May 2003 15:35:08 +0200 Received: by moria.seul.org (Postfix) id D4C5F33CD6; Thu, 29 May 2003 09:35:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9817A33CD8; Thu, 29 May 2003 09:35:04 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id CBDE533CD6 for ; Thu, 29 May 2003 09:35:03 -0400 (EDT) Received: from 76.34.59.29 (fsaia150.sdx.ne.jp [210.236.32.150]) by belegost.mit.edu (Postfix) with SMTP id CDFA2121A36 for ; Thu, 29 May 2003 09:35:00 -0400 (EDT) From: =?iso-2022-jp?q?=8C=83=88=C0=83u=83=89=83=93=83h_ , ?=@belegost.mit.edu To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=81y=8C=83=88=C0=81z=83u=83=89=83=93=83h=8E=9E=8Cv=81EBag=81y1/100=82=CC=93=C1=89=BF=81z?= Date: Thu, 29 May 2003 22:35:06 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="74f83bf2-dd24-4257-b306-0ef056da4d06" Message-Id: <20030529133500.CDFA2121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --74f83bf2-dd24-4257-b306-0ef056da4d06 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =83u=83=89=83=93=83h=95i=82=AA=82=C8=82=F1=82=C6=8Es=89=BF=82=CC100=95=AA=82= =CC=82P=82=A9=82=E7=81I =92=E8=94=D4=83=82=83m=82=A9=82=E7=83=8C=83A=82=E0=82=CC=82=DC=82=C5 =94=84=82=E8=90=D8=82=EA=81A=83T=83C=83g=8F=C1=96=C5=82=C5=91=A6=8FI=97=B9 =81i=83T=83C=83g=82=AA=82=B7=82=AE=8F=C1=82=B3=82=EA=82=DC=82=B7=81B=96{=93=FA= =92=86=82=C9=82=A8=90\=8D=9E=82=DD=82=AD=82=BE=82=B3=82=A2=81j http://book-i.net/gekiyasu/ http://www.psend.com/users/brand00/ http://www.freewebs.com/gekiyasu/ *********************************** =83=88=83b=83g=83}=83X=83^=81[=81@=83V=83=8B=83o=81[=82=AA9,000=89~=81I =83p=82=D8=83`=83=85=83A=83=8B=81A=83G=83N=83X=83v=83=8D=81[=83=89=81[=87U=81= AGMT=83}=83X=83^=81[=87U =83f=83C=83g=83i etc=81E=81E=81E =83=94=83F=83=8B=83j=82=CC=83=8A=81[=83hPM=90=D4=82=AA7,000=89~ =81=9C=83=82=83m=83O=83=89=83=80=83}=83=8B=83`=83J=83=89=81[=81@=83~=83j=83= X=83s=81[=83f=83B=93=FC=89=D7=81=9C =81i=91=E5=90l=8BC=81I=8Ec=82=E88=8C=C2=82=C5=82=B7=81I) *********************************** =81y=83u=83=89=83=93=83h=8Cg=91=D1=83X=83g=83=89=83b=83v=83v=83=8C=83[=83=93= =83g=81z =81=AA=82Q=82=C2=88=C8=8F=E3=82=A8=94=83=82=A2=8F=E3=82=B0=82=CC=95=FB=91S=88= =F5=81=AA http://gekiyasu.linuxeros.org/ http://home.graffiti.net/gekiyasu00/ --74f83bf2-dd24-4257-b306-0ef056da4d06-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From james@hello.com Thu May 29 17:07:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Lcqu-0002CL-00 for ; Fri, 30 May 2003 07:54:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 30 May 2003 07:54:56 +0200 (CEST) Received: (qmail 31745 invoked by uid 65534); 29 May 2003 15:01:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 29 May 2003 17:01:49 +0200 Received: by moria.seul.org (Postfix) id ED3B033CD9; Thu, 29 May 2003 11:01:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2F0A33CDC; Thu, 29 May 2003 11:01:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 1BBF533CDA for ; Thu, 29 May 2003 11:01:39 -0400 (EDT) Received: (qmail 12432 invoked from network); 29 May 2003 15:02:44 -0000 Received: from unknown (HELO localhost.com) (210.78.22.15) by bettik.munge.net with SMTP; 29 May 2003 15:02:44 -0000 From: james@hello.com To: f-cpu@seul.org Date: Thu, 29 May 2003 23:07:16 +0800 Subject: *** GMX Spamverdacht *** [f-cpu] Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! ! X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030529150139.1BBF533CDA@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.084; NO_REAL_NAME MANY_EXCLAMATIONS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: =3CBODY bgColor=3D#ffffff=3E =3CDIV=3E=3CFONT color=3D#ff0000 face=3DVerdana size=3D2=3EPlease note to send ALL REPLY e-mail direct to our sales representative at=3A =3C=2FFONT=3E=3CA href=3D=22mailto=3AQuestions=40QualityWatchWorld=2Ecom=22=3E=3CFONT face=3DVerdana size=3D2=3EQuestions=40QualityWatchWorld=2Ecom=3C=2FFONT=3E=3C=2FA=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3EHi=2C =3B=3CBR=3EThank you for expressing interest in ATGWS watches=2E=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3EWe would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces=2E =3B=3CBR=3EYou can view our large selection of Rolexes =28including Breitling=2C Tag Heuer=2C Cartier etc=29 at=3A=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3E=3CA href=3D=22http=3A=2F=2Fwww=2Equalityswisstime=2Ecom=22=3Ewww=2Equalityswisstime=2Ecom=3C=2FA=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3EFor all orders placed from now till the end of May=2C all shipping and handling charges will be free=2E =3B=3CBR=3EAs we are the direct manufacturers=2C you are guaranteed of lowest prices and highest quality each and every time you purchase from us=2E =3B=3CBR=3EYou may also be interested to know that we have the following brands available in our wide selection as well=3A =3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3E1=2E Leather band Daytona =28ladies and men's=29 =3CBR=3E2=2E Blancpain=3CBR=3E3=2E Fortis=3CBR=3E4=2E Jaeger LeCoutre=3CBR=3E5=2E Longines=3CBR=3E6=2E Mont Blanc=3CBR=3E7=2E Movado=3CBR=3E8=2E Oris=3CBR=3E9=2E Roger Dubuis=3CBR=3E10=2E Ulysse=3CBR=3E11=2E Zenith=3CBR=3E12=2E Audemar Piguet=3CBR=3E13=2E Breitling=3CBR=3E14=2E Bvglari=3CBR=3E15=2E Cartier=3CBR=3E16=2E Corum=3CBR=3E17=2E Dunhill=3CBR=3E18=2E Franck Muller=3CBR=3E19=2E Gerard Perregaux=3CBR=3E20=2E IWC=3CBR=3E21=2E IWC=3CBR=3E22=2E Panerai=3CBR=3E23=2E Patek Philippe=3CBR=3E24=2E Tag Heuer=3CBR=3E25=2E Vacheron Constantin=3CBR=3E =3B=3CBR=3EIf you see anything that might interest you=2C or if you have any questions=2C please don't hesitate to visit our website at=3A=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3E=3CA href=3D=22http=3A=2F=2Fwww=2Equalityswisstime=2Ecom=22=3Ewww=2Equalityswisstime=2Ecom=3C=2FA=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3EI certainly look forward to hearing from you=2E=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3EBest regards=2C=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT face=3DVerdana size=3D2=3ECal=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT size=3D2=3E=3CFONT face=3DVerdana=3EDivision Sales Manager=3CBR=3EATGWS =3CBR=3E =3B =3CBR=3EYou received this email because your have previous purchased from=2C or inquired about our product line under ATGWS=2E If you do not want to receive further mailings from ATGWS=2C unsubscribe by sending an email with the title heading=3A DELETE in the subject line to =3C=2FFONT=3E=3CA href=3D=22mailto=3AUnsubscribe=40QualityWatchWorld=2Ecom=22=3E=3CFONT face=3DVerdana=3EUnsubscribe=40QualityWatchWorld=2Ecom=3C=2FFONT=3E=3C=2FA=3E=3CFONT face=3DVerdana=3E =3C=2FFONT=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT color=3D#ff0000 face=3DVerdana size=3D2=3EPlease note to send ALL REPLY e-mail direct to our sales representative at=3A =3C=2FFONT=3E=3CA href=3D=22mailto=3AQuestions=40QualityWatchWorld=2Ecom=22=3E=3CFONT face=3DVerdana size=3D2=3EQuestions=40QualityWatchWorld=2Ecom=3C=2FFONT=3E=3C=2FA=3E=3C=2FDIV=3E =3CDIV=3E =3B=3C=2FDIV=3E =3CDIV=3E=3CFONT size=3D2=3E=3C=2FFONT=3E =3B=3C=2FDIV=3E=3C=2FBODY=3E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From someone@microsoft.com Fri Jun 6 02:42:18 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REZy-0000Nn-00 for ; Sat, 14 Jun 2003 19:12:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:12:38 +0200 (CEST) Received: (qmail 13008 invoked by uid 65534); 6 Jun 2003 00:42:24 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 06 Jun 2003 02:42:24 +0200 Received: by moria.seul.org (Postfix) id 5B61433B7F; Thu, 5 Jun 2003 20:42:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 06D6C33C55; Thu, 5 Jun 2003 20:42:21 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by moria.seul.org (Postfix) with ESMTP id 6ED8E33B7F for ; Thu, 5 Jun 2003 20:42:20 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 17:42:19 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 17:42:19 -0700 Received: from RED-MSG-15.redmond.corp.microsoft.com ([157.54.7.165]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 17:42:19 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [f-cpu] someone@microsoft.com Date: Thu, 5 Jun 2003 17:42:18 -0700 Message-ID: Thread-Topic: Darling Thread-Index: AcMrxHvV14Tnv7wqSFC0oVZe92Qx7QAAAAC5 From: "Example E-Mail Account" To: "f-cpu" X-OriginalArrivalTime: 06 Jun 2003 00:42:19.0333 (UTC) FILETIME=[7C2BB750:01C32BC4] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Thank you for sending e-mail to someone@microsoft.com. This is an = automatic reply sent in response to your e-mail. Someone@microsoft.com = is an example e-mail account that is used only for testing purposes and = is not monitored.=20 For information related to Microsoft products, please check the = Microsoft Web site at: http://www.microsoft.com For technical support information related to Microsoft products, please = check the Microsoft Product Support Services Web site at: http://support.microsoft.com/directory/=20 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From info_master@yume.otegami.com Fri Jun 6 08:43:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REa3-0000Nn-00 for ; Sat, 14 Jun 2003 19:12:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:12:43 +0200 (CEST) Received: (qmail 6805 invoked by uid 65534); 6 Jun 2003 06:43:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017) with SMTP; 06 Jun 2003 08:43:29 +0200 Received: by moria.seul.org (Postfix) id 1BD8C33C88; Fri, 6 Jun 2003 02:43:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A445E33C7F; Fri, 6 Jun 2003 02:43:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from yume462.com (f205.ac121.FreeBit.NE.JP [43.244.121.205]) by moria.seul.org (Postfix) with SMTP id 2A1EB33C5E for ; Fri, 6 Jun 2003 02:43:24 -0400 (EDT) From: ug0605 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=82t=82f=8F=EE=95=F1=82b=82c=8D=D5=82=E8=81I=81@=90=94=97=CA=8C=C0=92=E8=81I=81I?= Date: Fri, 06 Jun 2003 15:43:20 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="a510d8aa-a9bc-4df7-b023-37dbd472cc04" Message-Id: <20030606064324.2A1EB33C5E@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; MIME_BOUND_MANY_HEX) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --a510d8aa-a9bc-4df7-b023-37dbd472cc04 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://net-channel777.com/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dm_master@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=82t=82= f=8F=EE=95=F1=8Cn=82b=82c=93=C1=8FW=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=93=C1=95=CA=8C=83=88=C0=89= =BF=8Ai=82=C9=82=C4=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=8D=C3=96=B0=8Fp=81E=81E=81E=83M=83=83=83=93=83u=83=8B=81E=81E=81E=88=C5=8B= =E0=97Z=81E=81E=81E=97=A0=8F=EE=95=F1=81E=81E=81E .=97~=82=B5=82=A9=82=C1=82=BD=82=B1=82=F1=82=C8=8F=EE=95=F1=81I=82=A0=82=F1= =82=C8=8F=EE=95=F1=81I .=94=CC=94=84=90=94=97=CA=8C=C0=92=E8=93=C1=95=CA=82b=82c=81@ .=82=C6=82=C9=82=A9=82=AD=8C=A9=82=C9=97=88=82=C4=82=AD=82=BE=82=B3=82=A2=81= =F4=81@=8C=A9=82=C4=91=B9=82=CD=82=C8=82=B5=81I=81I . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel777.com/=81= @=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --a510d8aa-a9bc-4df7-b023-37dbd472cc04-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Music"@yahoo.com Sat Jun 7 09:55:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REbO-0000Nn-00 for ; Sat, 14 Jun 2003 19:14:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:14:06 +0200 (CEST) Received: (qmail 31968 invoked by uid 65534); 7 Jun 2003 07:55:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019) with SMTP; 07 Jun 2003 09:55:12 +0200 Received: by moria.seul.org (Postfix) id 1A1FB33C74; Sat, 7 Jun 2003 03:55:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DC5D333C73; Sat, 7 Jun 2003 03:55:09 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 760A333C71 for ; Sat, 7 Jun 2003 03:55:09 -0400 (EDT) Received: (qmail 18868 invoked from network); 7 Jun 2003 07:56:47 -0000 Received: from unknown (HELO zuwala-4met8cgp) (4.61.163.65) by bettik.munge.net with SMTP; 7 Jun 2003 07:56:47 -0000 From: "Zuwala Music" <"zuwala Music"@yahoo.com> Subject: *** GMX Spamverdacht *** [f-cpu] Press Release To: f-cpu@seul.org Content-Type: text/plain; Date: Sat, 7 Jun 2003 00:55:12 -0700 X-Priority: 3 X-Library: Indy 8.0.25 Message-Id: <20030607075509.760A333C71@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.855; FORGED_YAHOO_RCVD X_LIBRARY) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Press Release "Steve Zuwala is a HIT!" "Steve can sing and play a country ballad and rock and roll with the same passion.." "Where'd this guy come from?" "I really like'd 'Red Hair Haired Gypsy' and I think every guy can relate to 'Little Miss Priss'.." "It's not every day you can find somebody who can write, play all the instruments and do the vocals as well as Steve Zuwala!" New country recording artist Steve Zuwala has just released his new CD "End of the World". It is available for review at: http://stevezuwala.com This country/rock artist is unique and his lyrics and music are new and refreshing. Steve Zuwala brings back the honest music of the 80's without the computer enhanced vocals and redundant lyrical themes. Without question, this 43 year old late bloomer is what this industry needs. Please take the time to review the CD at: Http://stevezuwala.com and send your review either by email: zuwalamusic@aol.com or call: Helena Spensatelli: 310-398-2276 Jim James: 760-949-6100 Thank you and .. See you at the Grammy's! "You have received this email either because you are a either a media affiliate whose industry is interested in this type of news, or you were referred to us by someone who thought you would be interested in this news. If neither applies to you and you would prefer to be left off our preferred mailing list, please type "remove" on the subject list and return this email. You will no longer receive further postings." ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jun 13 20:46:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REjs-0000Nn-00 for ; Sat, 14 Jun 2003 19:22:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:22:52 +0200 (CEST) Received: (qmail 31903 invoked by uid 65534); 13 Jun 2003 18:42:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 13 Jun 2003 20:42:22 +0200 Received: by moria.seul.org (Postfix) id 1C25933B66; Fri, 13 Jun 2003 14:42:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D55E433D1F; Fri, 13 Jun 2003 14:42:18 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id E569133B66 for ; Fri, 13 Jun 2003 14:42:17 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-92.n.club-internet.fr [213.44.12.92]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 28A991699 for ; Fri, 13 Jun 2003 20:42:12 +0200 (CEST) Message-ID: <3EEA1C10.2060401@f-cpu.org> Date: Fri, 13 Jun 2003 20:46:40 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, nico@seul.org wrote: >To speed up regfile look up, we could use 4 1r1w regfile which introduice >4r4w port . In case of colliding, one clock cycle is lost. > >My question is : Is that possible for the compiler to try to avoid such >bubble ? > > have a try and tell us the result. >nicO > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Fri Jun 13 17:11:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REjN-0000Nn-00 for ; Sat, 14 Jun 2003 19:22:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:22:21 +0200 (CEST) Received: (qmail 13796 invoked by uid 65534); 13 Jun 2003 15:11:59 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 13 Jun 2003 17:11:59 +0200 Received: by moria.seul.org (Postfix) id B90BA33B49; Fri, 13 Jun 2003 11:11:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C8AD733B87; Fri, 13 Jun 2003 11:11:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by moria.seul.org (Postfix) with ESMTP id 2434733B49 for ; Fri, 13 Jun 2003 11:11:55 -0400 (EDT) Received: from nerim.net (crateria.nerim.net [62.4.16.75]) by mallaury.noc.nerim.net (Postfix) with SMTP id CE0C362E30 for ; Fri, 13 Jun 2003 17:11:52 +0200 (CEST) Received: from 140.94.82.18 (SquirrelMail authenticated user cyrano) by www.nerim.net with HTTP; Fri, 13 Jun 2003 17:11:54 +0200 (CEST) Message-ID: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> Date: Fri, 13 Jun 2003 17:11:54 +0200 (CEST) Subject: [f-cpu] use of 1r1w regfile for our 3r2w regfile From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: To speed up regfile look up, we could use 4 1r1w regfile which introduice 4r4w port . In case of colliding, one clock cycle is lost. My question is : Is that possible for the compiler to try to avoid such bubble ? nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Fri Jun 13 20:02:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REkG-0000Nn-00 for ; Sat, 14 Jun 2003 19:23:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:23:16 +0200 (CEST) Received: (qmail 31832 invoked by uid 65534); 13 Jun 2003 23:13:21 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 14 Jun 2003 01:13:21 +0200 Received: by moria.seul.org (Postfix) id CA2EC33B8C; Fri, 13 Jun 2003 19:13:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8887E33D37; Fri, 13 Jun 2003 19:12:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a212.home.uni-hannover.de [130.75.232.212]) by moria.seul.org (Postfix) with ESMTP id 1CF1633D84 for ; Fri, 13 Jun 2003 19:12:17 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id UAA01382; Fri, 13 Jun 2003 20:02:50 +0200 Message-ID: <20030613200250.31301@thrai.stud.uni-hannover.de> Date: Fri, 13 Jun 2003 20:02:50 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net>; from nico@seul.org on Fri, Jun 13, 2003 at 05:11:54PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Fri, Jun 13, 2003 at 05:11:54PM +0200, nico@seul.org wrote: > To speed up regfile look up, we could use 4 1r1w regfile which introduice > 4r4w port . In case of colliding, one clock cycle is lost. Or two, in case of a 2r2w or 3r1w instruction. With operands and results, there may be +-2 collisions -- no matter how many separate banks there are. It's just less likely that a collision occurs with four banks instead of two or three, but I doubt that it's worth the effort. For target technologies that work on the transistor level, we should design our own multi-ported SRAM if nothing appropriate is available. In any other case, we'll have to use what's available. Worst case is that we have to resort to ordinary latches with some stuff around them (2:1 muxes at the input, 64:1 muxes at the outputs). On the other hand, the meaning of "worst case" clearly depends on ones point of view. You can't build a 5-port (3r2w) RAM from 2-port (1r1w) RAMs unless you put each register into its own bank (and then you could also have used latches which are probably smaller and faster). Therefore, you would have to adapt not only the scheduler but also the compiler to the kind of register set used (in particular, to the number of banks and the `interleaving factor', that is, the placement of individual registers). This is what I consider the "worst case". -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Sat Jun 14 10:56:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REkd-0000Nn-01 for ; Sat, 14 Jun 2003 19:23:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:23:39 +0200 (CEST) Received: (qmail 5610 invoked by uid 65534); 14 Jun 2003 07:04:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 14 Jun 2003 09:04:50 +0200 Received: by moria.seul.org (Postfix) id 364FB33C5B; Sat, 14 Jun 2003 03:04:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 572C133C59; Sat, 14 Jun 2003 03:04:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by moria.seul.org (Postfix) with ESMTP id 9947D33C55 for ; Sat, 14 Jun 2003 03:04:46 -0400 (EDT) Received: from Bi (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 849EB62D69 for ; Sat, 14 Jun 2003 09:04:45 +0200 (CEST) From: Nicolas Boulay To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile Date: Sat, 14 Jun 2003 08:56:42 +0000 User-Agent: KMail/1.5 References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <20030613200250.31301@thrai.stud.uni-hannover.de> In-Reply-To: <20030613200250.31301@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200306140856.42208.nico@seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Le Vendredi 13 Juin 2003 18:02, Michael Riepe a =E9crit : > On Fri, Jun 13, 2003 at 05:11:54PM +0200, nico@seul.org wrote: > > To speed up regfile look up, we could use 4 1r1w regfile which introdui= ce > > 4r4w port . In case of colliding, one clock cycle is lost. > > Or two, in case of a 2r2w or 3r1w instruction. With operands and > results, there may be +-2 collisions -- no matter how many separate > banks there are. It's just less likely that a collision occurs with four > banks instead of two or three, but I doubt that it's worth the effort. > > For target technologies that work on the transistor level, we should > design our own multi-ported SRAM if nothing appropriate is available. > > In any other case, we'll have to use what's available. Worst case is > that we have to resort to ordinary latches with some stuff around them > (2:1 muxes at the input, 64:1 muxes at the outputs). > > On the other hand, the meaning of "worst case" clearly depends on ones > point of view. You can't build a 5-port (3r2w) RAM from 2-port (1r1w) > RAMs unless you put each register into its own bank (and then you > could also have used latches which are probably smaller and faster). > Therefore, you would have to adapt not only the scheduler but also > the compiler to the kind of register set used (in particular, to the > number of banks and the `interleaving factor', that is, the placement > of individual registers). This is what I consider the "worst case". But is that good or not ? 4x 1r1w regifile will be ~30% faster than a true= =20 3r2w. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From info_master@yume.otegami.com Sat Jun 14 00:39:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19REkL-0000Nn-00 for ; Sat, 14 Jun 2003 19:23:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 14 Jun 2003 19:23:21 +0200 (CEST) Received: (qmail 11428 invoked by uid 65534); 13 Jun 2003 23:39:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 14 Jun 2003 01:39:36 +0200 Received: by moria.seul.org (Postfix) id 53B0233D37; Fri, 13 Jun 2003 19:39:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2AC1133D54; Fri, 13 Jun 2003 19:39:29 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id AF66C33D41 for ; Fri, 13 Jun 2003 19:39:27 -0400 (EDT) Received: (qmail 25926 invoked from network); 13 Jun 2003 22:40:53 -0000 Received: from unknown (HELO belegost.mit.edu) (18.244.0.114) by bettik.munge.net with SMTP; 13 Jun 2003 22:40:53 -0000 Received: from yume826.com (fb170222.ot.FreeBit.NE.JP [61.203.170.222]) by belegost.mit.edu (Postfix) with SMTP id 510A5121A36 for ; Fri, 13 Jun 2003 13:38:49 -0400 (EDT) From: ene1 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=89=F5=8Ay=82=D6=82=CC=96=A2=92m=82=CC=90=A2=8AE=82=C9=81E=81E=81E=81i=8A=B4=93=AE=81I=81I?= Date: Sat, 14 Jun 2003 07:39:15 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="10b36e80-5f57-4643-b86f-a2d546b836b8" Message-Id: <20030613173849.510A5121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --10b36e80-5f57-4643-b86f-a2d546b836b8 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://210.150.173.81/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dm_master@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=81=9A3=93=FA=8A=D4=82=CC=82=DD=81=9A=8C=C0= =92=E8=91=E5=93=C1=89=BF=81I=83v=83=8C=83~=83A=89=F5=8A=B4=8F=A4=95i=93=C1=8F= W=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=93=C1=95=CA=8C=83=88=C0=89= =BF=8Ai=82=C9=82=C4=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=8D=A1=93=FA=82=A9=82=E7=82=B1=82=EA=82=C5=96=A2=92m=82=CC=89=F5=8A=B4=82=D6= =81E=81E=81E .=97~=82=B5=82=A9=82=C1=82=BD=82=B1=82=F1=82=C8=83O=83b=83c=81I .=94=CC=94=84=90=94=97=CA=8C=C0=92=E8=93=C1=95=CA=83O=83b=83c .=82=C6=82=C9=82=A9=82=AD=8C=A9=82=C9=97=88=82=C4=82=AD=82=BE=82=B3=82=A2=81= =F4=81@=8C=A9=82=C4=91=B9=82=CD=82=C8=82=B5=81I=81I . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://210.150.173.81/=81@=81=E1= =81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . .=92=8D=81j=95=BD=90=AC15=94N6=8C=8E22=93=FA=81i=93=FA=81j10:00 =81` 13:00 = =81i=82g=82o=8DX=90V=8D=EC=8B=C6=82=C9=82=E6=82=E8=89{=97=97=82=C5=82=AB=82=DC= =82=B9=82=F1=81j --10b36e80-5f57-4643-b86f-a2d546b836b8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jun 14 21:02:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Rlcw-0007z1-00 for ; Mon, 16 Jun 2003 06:29:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:29:54 +0200 (CEST) Received: (qmail 30657 invoked by uid 65534); 14 Jun 2003 18:57:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001) with SMTP; 14 Jun 2003 20:57:54 +0200 Received: by moria.seul.org (Postfix) id DF2CE33B84; Sat, 14 Jun 2003 14:57:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00C4C33C55; Sat, 14 Jun 2003 14:57:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4m.club-internet.fr (relay-4m.club-internet.fr [194.158.104.43]) by moria.seul.org (Postfix) with ESMTP id 9BF3333B84 for ; Sat, 14 Jun 2003 14:57:49 -0400 (EDT) Received: from f-cpu.org (lcbv3-1-87.n.club-internet.fr [213.44.91.87]) by relay-4m.club-internet.fr (Postfix) with ESMTP id 572CAE461 for ; Sat, 14 Jun 2003 20:57:44 +0200 (CEST) Message-ID: <3EEB7133.80102@f-cpu.org> Date: Sat, 14 Jun 2003 21:02:11 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <20030613200250.31301@thrai.stud.uni-hannover.de> <200306140856.42208.nico@seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, Nicolas Boulay wrote: >But is that good or not ? 4x 1r1w regifile will be ~30% faster than a true >3r2w. > > i don't know, but i'd rather like to have 8 or 16 banks instead of only 4 (less chances of collisions). don't forget that the "2w" part comes from both "2r2w" instructions and couples of instructions with different latencies that end at the same time. >nicO > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 14 12:37:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19RldC-0007z1-00 for ; Mon, 16 Jun 2003 06:30:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:30:10 +0200 (CEST) Received: (qmail 7173 invoked by uid 65534); 14 Jun 2003 22:37:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001) with SMTP; 15 Jun 2003 00:37:25 +0200 Received: by moria.seul.org (Postfix) id B49C033C57; Sat, 14 Jun 2003 18:37:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5D26833C5E; Sat, 14 Jun 2003 18:37:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a102.home.uni-hannover.de [130.75.232.102]) by moria.seul.org (Postfix) with ESMTP id 3358F33C58 for ; Sat, 14 Jun 2003 18:36:27 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id MAA00434; Sat, 14 Jun 2003 12:37:42 +0200 Message-ID: <20030614123742.25397@thrai.stud.uni-hannover.de> Date: Sat, 14 Jun 2003 12:37:42 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <20030613200250.31301@thrai.stud.uni-hannover.de> <200306140856.42208.nico@seul.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200306140856.42208.nico@seul.org>; from Nicolas Boulay on Sat, Jun 14, 2003 at 08:56:42AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sat, Jun 14, 2003 at 08:56:42AM +0000, Nicolas Boulay wrote: [...] > > This is what I consider the "worst case". > > But is that good or not ? 4x 1r1w regifile will be ~30% faster than a true > 3r2w. The worst case is, by definition, always bad (or even worse ;). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nicolas.boulay@ifrance.com Sun Jun 15 13:14:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Rldu-0007z1-00 for ; Mon, 16 Jun 2003 06:30:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:30:54 +0200 (CEST) Received: (qmail 2527 invoked by uid 65534); 15 Jun 2003 09:22:38 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 15 Jun 2003 11:22:38 +0200 Received: by moria.seul.org (Postfix) id 566A933B7A; Sun, 15 Jun 2003 05:22:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 15C1033C66; Sun, 15 Jun 2003 05:22:34 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mallaury.noc.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by moria.seul.org (Postfix) with ESMTP id 5736633B7A for ; Sun, 15 Jun 2003 05:22:33 -0400 (EDT) Received: from Bi (cyrano.net1.nerim.net [213.41.140.63]) by mallaury.noc.nerim.net (Postfix) with ESMTP id B8E5462E1A for ; Sun, 15 Jun 2003 11:22:31 +0200 (CEST) From: nicolas.boulay@ifrance.com To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile Date: Sun, 15 Jun 2003 11:14:27 +0000 User-Agent: KMail/1.5 References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <200306140856.42208.nico@seul.org> <20030614123742.25397@thrai.stud.uni-hannover.de> In-Reply-To: <20030614123742.25397@thrai.stud.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200306151114.27963.nicolas.boulay@ifrance.com> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Le Samedi 14 Juin 2003 10:37, Michael Riepe a =E9crit : > On Sat, Jun 14, 2003 at 08:56:42AM +0000, Nicolas Boulay wrote: > [...] > > > > This is what I consider the "worst case". > > > > But is that good or not ? 4x 1r1w regifile will be ~30% faster than a > > true 3r2w. > > The worst case is, by definition, always bad (or even worse ;). There is a miss understanding. The worst case the case where it slower. 3r2= w=20 SRAM memory are ~30% slower than 1r1w SRAM. But if we use 1r1w SRAM bank=20 there is some collision that "could" be avoid by the compiler (otherwise yo= u=20 loose one cycle). I can't say was is worst. It fully depend on compiler. So big latches array will be oustandly slow. nicO ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From zoey@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Rle5-0007z1-00 for ; Mon, 16 Jun 2003 06:31:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:31:05 +0200 (CEST) Received: (qmail 31103 invoked by uid 65534); 15 Jun 2003 12:29:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018) with SMTP; 15 Jun 2003 14:29:52 +0200 Received: by moria.seul.org (Postfix) id EB1A033B6F; Sun, 15 Jun 2003 08:29:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E579333C66; Sun, 15 Jun 2003 08:29:46 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id D83B333B6F for ; Sun, 15 Jun 2003 08:29:45 -0400 (EDT) Received: from eXcuria.com (unknown [63.251.146.40]) by belegost.mit.edu (Postfix) with SMTP id F126D121A36 for ; Sun, 15 Jun 2003 08:29:44 -0400 (EDT) Date: 6/15/2003 7:28:07 AM To: From: Zoey Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save upto 89% Message-Id: <20030615122944.F126D121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products w/ 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! Visit us on the web at http://excuria.com/inkstore/ For instruction on how to be permanently remove from this distribution system go to http://excuria.com/remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From anup@cse.iitd.ernet.in Sun Jun 15 20:29:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19RleW-0007z1-00 for ; Mon, 16 Jun 2003 06:31:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:31:32 +0200 (CEST) Received: (qmail 14160 invoked by uid 65534); 15 Jun 2003 18:17:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 15 Jun 2003 20:17:52 +0200 Received: by moria.seul.org (Postfix) id 0ADEE33C71; Sun, 15 Jun 2003 14:17:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 190AA33C70; Sun, 15 Jun 2003 14:17:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from desh.cse.iitd.ernet.in (mailer.cse.iitd.ac.in [202.141.68.3]) by moria.seul.org (Postfix) with ESMTP id 9B69A33C68 for ; Sun, 15 Jun 2003 14:17:45 -0400 (EDT) Received: from saveri.cse.iitd.ernet.in (IDENT:Dnk9xJxFeTtmdA5XxYOyPFfK7Eh2t4vF@saveri.cse.iitd.ernet.in [10.20.11.20]) by desh.cse.iitd.ernet.in (8.11.6/8.11.6) with ESMTP id h5FITIB10048 for ; Sun, 15 Jun 2003 23:59:18 +0530 Date: Sun, 15 Jun 2003 23:59:16 +0530 (IST) From: Anup Gangwar X-X-Sender: anup@saveri.cse.iitd.ernet.in. To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile In-Reply-To: <200306151114.27963.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi, I have been reading posts on this list for long but have never posted any message myself. In my opinion going for simpler (less R+W ports) RF's will be advantageous from two viewpoints: 1. If we stick to at most 2R+2W ports then the CPU could easily work with FPGA technology a big+ while prototyping. 2. The larger the RF the slower it will be. Everyone is breaking up the RF into smaller chunks (clusters of FUs). As per one heuristic estimate the power, delay and max freq grow as atleast N^1.5 where N is the no. of FUs per RF. 6. The compiler complexity will not grow too much if each of the individual clusters is connected to the other in a homogeneous fashion. Though a variety of interconnect strategies are possible. Regards, Anup -- On Sun, 15 Jun 2003 nicolas.boulay@ifrance.com wrote: > Le Samedi 14 Juin 2003 10:37, Michael Riepe a écrit : > > On Sat, Jun 14, 2003 at 08:56:42AM +0000, Nicolas Boulay wrote: > > [...] > > > > > > This is what I consider the "worst case". > > > > > > But is that good or not ? 4x 1r1w regifile will be ~30% faster than a > > > true 3r2w. > > > > The worst case is, by definition, always bad (or even worse ;). > > There is a miss understanding. The worst case the case where it slower. 3r2w > SRAM memory are ~30% slower than 1r1w SRAM. But if we use 1r1w SRAM bank > there is some collision that "could" be avoid by the compiler (otherwise you > loose one cycle). > > I can't say was is worst. It fully depend on compiler. > > So big latches array will be oustandly slow. > > nicO > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ddade@digitalstatecraft.com Sun Jun 15 21:22:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19Rleb-0007z1-00 for ; Mon, 16 Jun 2003 06:31:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:31:37 +0200 (CEST) Received: (qmail 28183 invoked by uid 65534); 15 Jun 2003 19:21:26 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 15 Jun 2003 21:21:26 +0200 Received: by moria.seul.org (Postfix) id 13C9D33B48; Sun, 15 Jun 2003 15:21:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F3B433C69; Sun, 15 Jun 2003 15:21:23 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from rwcrmhc12.attbi.com (rwcrmhc12.attbi.com [216.148.227.85]) by moria.seul.org (Postfix) with ESMTP id D2F4633B48 for ; Sun, 15 Jun 2003 15:21:22 -0400 (EDT) Received: from digitalstatecraft.com (c-24-130-201-255.we.client2.attbi.com[24.130.201.255](untrusted sender)) by attbi.com (rwcrmhc12) with SMTP id <2003061519212201400acma6e>; Sun, 15 Jun 2003 19:21:22 +0000 Message-ID: <3EECC77D.1010205@digitalstatecraft.com> Date: Sun, 15 Jun 2003 12:22:37 -0700 From: "Donald A. Dade" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] How far from a usable system? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hello list, All the FAQs that I've found seemed to be fairly old, or not dated at all. I was trying to determine if/when people will be able to obtain an f-cpu based system. I, for one, don't care if it's not quite as economical nor as fast as the Intel offerings. It would just feel *good* to use a system like that. So, what is the state of the project, and what is the estimate for the arrival of sample systems? Don ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 16 01:22:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19RlfM-0007z1-01 for ; Mon, 16 Jun 2003 06:32:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:32:24 +0200 (CEST) Received: (qmail 32332 invoked by uid 65534); 15 Jun 2003 23:24:47 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 16 Jun 2003 01:24:47 +0200 Received: by moria.seul.org (Postfix) id 404E133C75; Sun, 15 Jun 2003 19:24:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EED1D33C77; Sun, 15 Jun 2003 19:24:43 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a177.home.uni-hannover.de [130.75.232.177]) by moria.seul.org (Postfix) with ESMTP id 2953B33C20 for ; Sun, 15 Jun 2003 19:24:39 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA03600; Mon, 16 Jun 2003 01:22:21 +0200 Message-ID: <20030616012221.18728@thrai.stud.uni-hannover.de> Date: Mon, 16 Jun 2003 01:22:21 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <200306140856.42208.nico@seul.org> <20030614123742.25397@thrai.stud.uni-hannover.de> <200306151114.27963.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ReaqsoxgOBHFXBhH X-Mailer: Mutt 0.84e In-Reply-To: <200306151114.27963.nicolas.boulay@ifrance.com>; from nicolas.boulay@ifrance.com on Sun, Jun 15, 2003 at 11:14:27AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii In order to stop the fruitless register set discussion before it goes off again, I created several versions today: - one based on latches - a `banked' one based on 8x64 bit SRAMS (8 banks) - an 8-way `interleaved' one based on the same SRAM component - a transistor-level custom implementation The first and last items on the list should both be stall-free. The banked one isn't really an option because groups of 8 consecutive registers live in one bank (which will cause a stall every time there is a 2w instruction). In the interleaved version, register is placed in bank which is much more reasonable for the F-CPU. As usual, a testbench is included, as well as a simple-minded SRAM implementation (in case you want to simulate the units yourselves). Now go ahead and show me numbers, please. -- Michael "I did it again" Riepe "All I wanna do is have a little fun before I die" --ReaqsoxgOBHFXBhH Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fcpu-mr-regfile-20030616.tar.gz" H4sIAET87D4CA+1de1PbyLLPv/hTzELqYmcx0cgPWNhsrYNNQm0CiSDr5NapomRbBm1kyUeS A5w6H/52z4xeM5ItE0JydzVVIZKmp6enex49v2lL0/F80Zz5Td+6mtqO1dQ1raV1aff5k4dL mtbW9jod+J8l+X9+vdfda9G9LtVaTzRKu+3OE9J58ghpEYSmT8iTf2iaFtlfPHj+Xezf0rt6 Zf8fwv7i/90v1xPnvvanmtZtt4vsD/W1hf1pu6PrQN/pdFpPiFbZ/5unZpOkLUzg/rh59O4D MawrOwgtnxxDHjmZzR1rZrmhGdqeG9SA7Mib3/n21XVI6kcNgv2GvLXH16blEMO25hb5dcZv fw/CxWR34drNa9N1vS+WvzuxfgMWyOXi2g7I3PeufHNG4HLqWxYJvGl4Y/rWIbnzFmRsuiDj BKTx7dEitIgdEtOdPPd8MvMm9vQO+cCzhTsBccNri4DYs4B4U3bz6vQDeWW5lm865N1i5Nhj 8sYeW25gEROqxifBtTUhI8YHSxyjDOdCBnLsAWPW7ENi2ZDvE2hCAPdEj+oQDHeI5yOTuhmi 5D7x5liuAeLeEccMk6K7Bc1PWjkhtst4X3ugy/AaWEIbb2zHISOLLAJrunB2kAUQk+HJxeuz Dxekd/qJDHuG0Tu9+HQIxOG1B7nWF4uzssGKNnCGdvmmG96B+Mjh7cA4eg1Fei9P3pxcfIJG kOOTi9PB+Tk5PjNIj7zrGRcnRx/e9Azy7oPx7ux8sEvIuYViWchgiYqnzEqgxokVmrYTRA3/ BIYNQDpnQq7NLxYYeGzZX0A2k4yhY602HjIxHc+9Ys0E4kSRh8SeEtcLd8iNb0N/CT3VrFg8 sewOOXHHuzuk8wu5sLCrk3eOOQZ7ni+QQaul7ZCXXhAi5dseIZpOKW3SlrZHyIfzXg25/V7f apCnJ5OntZpjj3zTvyMng8HgsAa2Yle7QTi5dLwre3yJDs6u6TiHNZZ74/mfd49h1F2OPXdq X4ksGG42GAlGIhuDdlDbmHs+jLfaxgZUyBsHDTDhftjXyAF2mePLPwdHF2fGIXtI1YdxSXMy 8a0gQLqeKIwSLriIX6xx6Pn1Dpl4Ny5oUGswjj1akjKuxnLNkWNh2YFSC2M5oHmP2cRkTlJS GqWlNEpLafT08u1h8vDmkLp95UK3xmmDDatkcmwg2/ymGvlNNQZ6zmMYJ0mtwsoGszKO6bRF DWZm9akuPa1tQEssdxL1qEPWb7/YBySwQhIGL9okuIE/1r8XpjP3r15sTmchae7ppDlvNjcP CDTThJH3pEr/HP8vYL37MoB59b4+4Cr/r9OK/L9up9WCfQLMjt3K/3ss/0+2MPqA/cVsdkfO jd5btoJXLmHlElYu4SO5hHGmu5hZPmQBUdYjZOMS3cEr1AMoAD3CN2evLt+cgImYLxFaV9C1 Dl6Q1iE6EfvEsV2L+Xon/YvXWZL9DU4yssPgOdIxRyHxNY1ekY8U19mksp+4dhFjkO8d5j7t F7FnzZNYM0/K6AtvqESZ2FFCRYPaTX98DUYfhwvotS8t1juhN8ZmAK8dVhE3JDn618mzZyRu NEgTLEbh3Zw5/RMc3+XawIrMTJgJbrEQjta7uqJHlAr5YjXgoMIIQREPRMHD2ghmcLcW++Zg Y98bg3dN6sPeDhkO4F8fWi/INmDMhN7lR43Wh4MGeUG26TYOG8yCTvG2DpmipfWFixVaE2DU aDTIry+AE1oKtWhP4QovRG2g0cixTUkADHdAXPg3yBXBUEXoYz1FghgoCBPBCayEvO7hfB2Q F7+R7f/dbhTLiDfc1n9nP7ks/ncpppr7+IDL/T+q63qE/3bBGewC/Z7e3qv8v8fF/zIWrnDA yumrnL6vdfpy/IbLV8Jlg4algT22vh9fGoNXJ+cXA+Py+OTNIFnou63sGp/gPLWN6cIdo+yg 2bE3sVqht0/qH4v8Iz1hhEAVJt8C+XJomVwbX0zfZojX3R3wVBnuZdyUaNm+u6uDpOD+gPrJ x7qOXX8ibmj6hvt+QE5XkGNKkesqOafI595aQS5xbzNy/rCE7J0V5BL3rkq+TPa9FeRp7sKW d3fCm0n6RE5X6YZet72kr0gIKCZCFH886kakZD8yzR0yGpXoSyu7XnpUpPqeaaK+kpbXPyYt aXGXEOuXSNIDA0lwwrKxpYlQxPG8ObYW8/4qyEOL7T+zf/6LWc006za30mhU/4tfDZgy0TpY JnJAo+t8CzJTZUw4W9ymjCfNHMJcn0pYthHZLZpTmLkiXY7BjyWfuAU3bsDvJpvca9tEB1qU jDpfmoBmCahMQCUOukIgcWhJBFSWoa0QSBw6MoEsQ1chkDjsZQmoood9hUDi8ItMIMtANYVC VqWkS6poguoKhcyjJVMocrQVCplHVp9U7RW0q1DIPPZkCkWOfYVC5vGLRKHoQ9cUComHTmUK pX/qCoXMI6tTqvYOva1QyDw6MoUiR1ehkHlIOlX7h76vUMg8fpEpZDlamkIhD9iMTmnOrNHS FQqZR0umUORoKxQyj45Eoeij1VUoZB57MoUix75CIfP4JUuh9o+2plBIPNpUppDlaOsKhcxD 0qnaP9pthULm0ZEpFDm6CoXMI6vTnPmjva9QyDx+kSlkOTqaQiEvC1SiUPTR0RUKmUdLplDk aCsUMo+sTnPmj05XoZB57MkUihz7CoXMQ9Kp2j+6mkIh8ehSmUJZa3WFQuaR1mkC2on8NIz3 MYHx0F8RjhNzkNBlipDQY/CGFD9JQkTJ3PTDNCza1xATpfCnh1c9vBrg1YA20i7qDTy7oeu4 qTda4oMy967Oqxhw7SIzOZvyekU4gmOG42uG6aM/6ltX6OulKotd0gRDvdHqQNfAnf0NZZcy pprSBML/GgnNzxbuqGFfPrHcMUNSVY4Kmw3jmFfFkGCNO6QREivlUpEbwbDpy5RrnI8gyxYz jhFF1vAPxT86Asp4O8DbgV6ALWsquKyhdKwXMaYRaU+TYWVtFa6cqYmqNdGCmqhcE12rJl2t SS+oSZdr0u+JlUf4RhVb8veK/70cme5na3KvEJAV+D/kxvEfuraH8d97Wqdd4f+PjP+nLFzB /xX8X8H/P0TMRxwf/NIOL9+arj1fOExYERKSPWNgQ/iSBSZIBwxJjMLZq8uXvdM/cuNEJh5D n2HAuldWqtDph7d5heLgBpaHXtnYm809F2YIFh0BDkM6RKVsjErJIBUWpZKEqdwnTuU+gSoF kSoFoSprxqrwYJU1o1WYItj2J9L+Vx0MxWB/Idb/nY+MEhh9jYOjTKGyx0eZQmUPkTKFyh4l ZQqVPVDKFCp7rJQpVPZwKSm0/IhJPsfs9y56yTlmPI3IQUu5B5qwT9nPO+FAnryPgnCfypx0 3uOMY+kBx9LTjeVHG0vPNZYfaiw/0Vh+nLH0LON+6Mp+ClwZ9mFz3c8CLMJMEQVGdvVy54PW s9x+kSo7wK17btmCksK26NIGUA7dD7zGnpJXgrBVysSIuA0bljwoIpaveP2amXOSrAmomXjd 2yF8vYJnH972PrJJkq1KrAzrqNByyDV60FaU4+e4c/L7xg6jGjKq4Qoq0DPy6tfTJdmzYeYZ aAzpBhk69mwonuGjaOmINCCgFe4yMVXXNvjNAXlQWKzI5nn4GDujharSB7n5UJmgpDIlH6LQ /F9fgFAcAMOmbqzsGrkoGlOfAnoVW44BXSC/sspGJkvjZDFMtoofXcWPro2mCYuz65TBjf5K VC0xug8ZPjz39XsZ3pcNb8iGN4ThfapQUpmSGx5FkSh1mVKPwpBBdT7rIsAf/+r37Sh+UUcx lhrWyOko0CdSfOk9+dI8vlaporpaNKdblUdV91mfSkDVTIzGtwJYpUrpskofDGuVKtWXVXoP 2DXZ8lWYa5W+Gf6LW3Ef+suX9UHglfiv3orw3xalcK1rVK/ivx8b/5UtXIHAFQhcgcD//0Dg k2QcV0hwhQRXSHCFBFdIcIUEV0hwhQT/jZDg1KBegQRLlD8IEpwCgR4ECV7B7++DBGfMuRQJ liiXIMES5Q+FBMuGfSgkOIdvWSRYKfqwSHB6vX40JHhJpd8OCV5S6fpIsLzvq+DgKj0c/jte BKE3+xbxv3q7o0fvf+60NXz/2x7tdCr895Hx35SFK+i3gn4r6PcxXwMMJU+9kLgWrudYCO0J 3X0B92Rmge7uCGKwixnrS4Je9AhQlgUdwvdusPMgumNP8FVxY1AXU4uJg5yN4+gVckdQ4NJg BbKvkXt5ciFhst229D44RIfN0ASa+SJErAT3gP2it/jKbwHGvWHh63mxdhUHTb95Fx1z3G5E u4qybKLX6TLJYTgI0d8Dr/fA672uwKzxW+AiXclA+xGbMAvh9eGZ0VdUuRRbzwG7EUbIoumR NDKinm84GRkvNtU9LHM/Swhge6nmHxjHrl51U73q5iFedVO94+Yx3nEjsF4+VcEEkZ4oUm84 jyBhNm3BPCTmIiMfa2KzcS40jB4Ef8m8EMQHWw4Z0lD06+whVXOTH2cbSlkOmPGyBlVzaYxP Gbqaq0eYVG0DlvgYxQY/EMwjHwKmAWzwG4A4tWBkMWxmSrZsIBKM+mEwcA5o3dc4qKzVoVYB IMMqwp7R1LMhp9PEHaegAoRmeYbIM1ieEeXp7E7nd+85Zaa295w+U9t7Xqqvs2f5EDZbv9k6 La/eb7ybyzfgEzu4gGfcIeFbHYB7bYNjGftr4HGPTebGgZ/GfFToNJ6D7ioedsU9cu4Foguu WgpFAde6Wq/AfAL9aT6BbuPilTuh6fIpOiQDqrmen+9iYeQi5YuRAdVgb9zWtgk7HRLIVZ+D efAU4SpEpoCju5SWZmhB8lxamst3GW2Gb8py4PmPPHB8sR8HWf8/MGcWDp4ddgcWXDghus24 b5zarjVJTjlSw0yyRXqUQaWwN4OVxjdxrwZbqgBcbc8PoIYbj8wtzgSnRRSHuWMB67LYMNQx a9iQd3dVWxvQPWJydzV5ljsV5LQc91Xk8gGReAnFOspCpdgu7IBDhDbrbINyY5mfYRPuOM3F vBGpjJNzg6KtYJM/tXz0gSeWY94FWOXY4ka1ZxgRA/tuVsbGek0iDAo928QvpSx8HM62a4e2 6dj/YVs+NAsvY05xY27ORvbVwluIThNI+pS7YaS8rKZebwtulMwDWccyi4h9AQuNs5D1Puej 7fX2IQzw5FKPLmHgJBRuQuEmFNnhAvoLbdzyYlgNQcQjsByYh6zJkoEiDoe+2TjJTil1I93n uaMRq4/PHI1s1y5RPjZNTvk5lcrTNesvUX5p/bpUXl+z/hLll9Qv97n3kjrBPJlCNMpwpYyP yO29pAxQbkFpmldaagqopqC0rpbGhsTLfXUsci/8H+bC8J4fgFmO/+sYAR7h/+09fBc47Xa1 Kv77sfH/2MKkSS7gemS54+uiz7/kQv8alKxOAKoTgOoE4CuCv5PM0LoFmcrEhuNNmrr8VwXZ qMdXqGUPAoavT45ey6HZ5Pyid9rvvTk7RWRs5HmwMLqYFfoLKzkhwAk15NCZRHPIgPw7gfeK zOw36WJ55O16D24uaQpsz0qe4OMiO4N6y19LzP9cYv73EvM+mLjGFxPX+GRizmlJ0UcTi76a mPPZxDW+m7jGhxPX+HLiep9OLPp2YtHHEwu+nigOGaTvJxZ8QLHgC4q5n1DMP5mIg1+jaEgD rwx+VYBbxvGSmXC6XPCykx8Ly8MspQC8DAN+dCSOl/CxlsnGgQm+8qFERFUiyjaMLN5ogsOR 745DH4Y7I8atdUNCwR3U3AH7LUc6mhNL1jFvhwQ8ahOfIFWdn8vtsJKRnqOasvVPvEvf4gPc GTmxCDF4f7tDcgH1NWQEjvXN4euzHrl4PTAGP/3002YirmgA1K0845Js1zdRcZsNJf92RaPX qOB5bgV3JbQa6y+r1vG1Nf4s0M58xRKCZxtLVGs6NrhTt7n92Nx2LPcKVmnRnWmD/SLgMC6W fwgyyi02OlxtSDMILOgjcb0vSMQrc/5xu+3jUWx8wOHCWsr3k3d4tgH9v8k21KmMW56B+Swn ViiqbYf1PxFXb9rhYbPJzzxyQm9TKk8fSYBHu4BmCV8WOmNtY7YI2dQ4JXx5fiGh/UwBYnln i79YCuvZV3PmAfzLwrgFRL8k5jeKRk9NefloPMpIs02gJZuQ/Mz9O8uvZ+XXy8kvB2d+50a0 so1olWsEP0j5jqKzkTHxYX/gR7Gv8at/05NBOJtn19zUK39TTmwUoZtM98+ePSPMf2UHPxxU xg0ePN/MBOjiqIbBGdoOp0+H5ka/JOLaTf2aiJ1rZSvDS6wr8rwZnt4cQfGJ5BwlMnBmtJgZ f5On+D7hUiZ6MZPUz8HLcGoVc+KBhWWYJOHO7gI3K+kfG4kvgEtR0eI3Sei4FuXoRTmDCM+M vs2dvtNTd8PCeoeF9Q77hWX6hWUyEg1TEtXkTjqywxs7wPeVB0EzvPYXTNuJPqPG0e1oocMd Aa51Gm6Du614rRONU1fd0LuMP6aIhXdItxH5/msXYSMy2+gmb/RG6vSAyYYhT02aBBtg/hfT WViRk8+ouJ8aE2EFHMeGWhi18FiiQ2sUOPM8URBhgxmrocQNRH5qWa5v4ln0cPCCNjaFZw+1 NSRG2hqMtBxG6QCJrNgcAZfaGHkkRTEW6d6t9B68w5HJguEwfCnuN0t7itqlNWFDFBeLNVKd 7j49a7lVlqo689OTbHNxC7h+c3O6bNRcNARv7kHS3HuMCmNpc+Weo/QZ40H0Qb+ZPuj6+qDl 9UE3hbuQ0gd9AH3o30wf+vr60MvrQ2f60DP60O+lj+z0QEtPD7R4eqAYycYDraQ5gq4/R9Cl cwT9ceaIVJuriWKVUv7Rs0WRUn7cKaPUVirZQSFc6lihlXb5ERlJ7an44cCv4qxg6W8d+WmA OOhQTj9yjjhwGyYfM5Q7YmAbuO8NfCrHG/HpR/pnAPc7tSk8tik6rlHhb/auDyRIwqH5ez5I 3TVBt6ZDOMD262/sJR9RBTGWzSO0DtI86u2cWF2OTcS4HRtkGfBizhuRo6Vs7KtAPn4j9k5a QfBgakJ3lDAOrhvIZHLW7caOUE3y6Gf+sR4lTisCJ1RoeSXWwDlrjfSQyOIOkN1OelK5YSdG XfGQqqJjqt//JvE/b83PFl58RR3L43+0FlQn4n86HW2PAn17T+9W8T+PkbaIbOjalhrYQ+8V 2LMFrB4krGfrYaJ6th4gqGerVExPXsvXjejZ+tqAnq2vjOfZWi+cB9v89cE8W18Vy7P1kKE8 W3EkzwGJBsfOF0J3aZsNhuda+zndJ7R9oNODjkbEYCCD2zl5Wqu96x390XsFLgWZNmGSrf05 MM5Pzk7x1G4XZr1aLfDHE9uH+91a6M0vk9vdGj6Ib4LFiF+LkVqrYTwPf/S0zikbz3mMD7ha 7OfBsOzPPFelwae12tHZ6THLEIwaz5mIUZwQxgACzdu3TFqkEswaz0d2eDlLv3+S0Z4bR+eJ fDyG8F/o26HaoWHmLH4WBRsKZ0x5nv4IWeqx8m7aVF76vQWpx3E4Y63WPzm/wM99nrPmoLSN 2KK1i8H5xcvB6dHrQaoNrHSt9ufr/pt38BTZzEkTB/A4ZE8H4qlVG54Zf7w5eQn3TTwsS6kb b2u1iTU1F054cPi7Nb72yG//o5PtU4+IxwRWnysr/Am2W9YtzAIU9iSOc1DbeFpnlUP/q4sa GpHs0D1AugMyZp68Cf7z3X/in0BA9xBPskzQ5vx/tGuKV1QOyG9fbD6tp/TR2DxkA/0WJ6yn T28P8ZfLoGLBd9DAh+S//xWiH2LeBDYF0ENRNODoz0jTn/JTxOBuBtqAWTDqlmKENJrAjg+O BsuPO3yiyqd1URAveT6Izp+KW6ht9hnLPf2dV3MA5WPLY4NTxLUNtDI2N6HYZPJje6fst9zY ZLyKW+3AkzofpiAGy8tyRVX8i22zobPMSxDLeqv80SpVqUpVqlKVqlSlKlWpSlWqUpWqVKUq ValKVapSlapUpSpVqUpVqlKVqlSlKlWpSlWqUrn0f3kCPHEAyAAA --ReaqsoxgOBHFXBhH-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jun 15 14:17:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19RlfO-0007z1-00 for ; Mon, 16 Jun 2003 06:32:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 16 Jun 2003 06:32:26 +0200 (CEST) Received: (qmail 28168 invoked by uid 65534); 15 Jun 2003 23:24:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 16 Jun 2003 01:24:50 +0200 Received: by moria.seul.org (Postfix) id 9E08933C20; Sun, 15 Jun 2003 19:24:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4B73233C88; Sun, 15 Jun 2003 19:24:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a177.home.uni-hannover.de [130.75.232.177]) by moria.seul.org (Postfix) with ESMTP id 243E033C20 for ; Sun, 15 Jun 2003 19:24:44 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00519; Sun, 15 Jun 2003 14:17:32 +0200 Message-ID: <20030615141731.45472@thrai.stud.uni-hannover.de> Date: Sun, 15 Jun 2003 14:17:31 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: <2523.140.94.82.18.1055517114.squirrel@www.nerim.net> <200306140856.42208.nico@seul.org> <20030614123742.25397@thrai.stud.uni-hannover.de> <200306151114.27963.nicolas.boulay@ifrance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200306151114.27963.nicolas.boulay@ifrance.com>; from nicolas.boulay@ifrance.com on Sun, Jun 15, 2003 at 11:14:27AM +0000 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sun, Jun 15, 2003 at 11:14:27AM +0000, nicolas.boulay@ifrance.com wrote: [...] > There is a miss understanding. The worst case the case where it slower. 3r2w > SRAM memory are ~30% slower than 1r1w SRAM. But if we use 1r1w SRAM bank > there is some collision that "could" be avoid by the compiler (otherwise you > loose one cycle). And what about the extra logic you'll have to put around the 1r1w banks? Every bank needs its own 2:1 input selection MUX, and you'll also require three :1 output selector MUXes to connect banks to our three read ports. Since all of them contribute to the CDP, your ~30% speed advantage may already be gone. > I can't say was is worst. It fully depend on compiler. > > So big latches array will be oustandly slow. The point is that it's not big -- only 64x63 (since r0 is hardwired). There are more flip-flops at the end of the first stage of the integer multiplier. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tony2003@yahoo.ca Mon Jun 16 03:32:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZa-0006x7-01 for ; Thu, 19 Jun 2003 10:15:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:10 +0200 (CEST) Received: (qmail 4444 invoked by uid 65534); 16 Jun 2003 07:03:59 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 16 Jun 2003 09:03:59 +0200 Received: by moria.seul.org (Postfix) id EBE5A33B5E; Mon, 16 Jun 2003 03:03:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7229633C82; Mon, 16 Jun 2003 03:03:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 7ADA533B5E for ; Mon, 16 Jun 2003 03:03:53 -0400 (EDT) Received: (qmail 90003 invoked from network); 16 Jun 2003 07:05:14 -0000 Received: from unknown (HELO sunny) (210.78.22.15) by bettik.munge.net with SMTP; 16 Jun 2003 07:05:14 -0000 From: tony2003@yahoo.ca To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! ! Date: Mon, 16 Jun 03 01:32:07 Öйú±ê׼ʱ¼ä MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= "----=_NextPart_000_0059_4365F819.1AE85D1B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20030616070353.7ADA533B5E@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=10.359; DATE_IN_PAST_03_06 FORGED_YAHOO_RCVD FROM_ENDS_IN_NUMS HEADER_8BITS INVALID_DATE NO_REAL_NAME MANY_EXCLAMATIONS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ------=_NextPart_000_0059_4365F819.1AE85D1B Content-Type: text/html Content-Transfer-Encoding: base64 PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48U1RST05HPjxGT05UIGNvbG9yPSNmZjAw MDAgZmFjZT1WZXJkYW5hPlBsZWFzZSBub3RlIHRvIHNlbmQgQUxMIFJFUExZIA0KZS1tYWls IGRpcmVjdCB0byBvdXIgU2FsZXMgUmVwcmVzZW50YXRpdmUgYXQ6IDwvRk9OVD48L1NUUk9O Rz48QSANCmhyZWY9Im1haWx0bzpRdWVzdGlvbnNAU3dpc3NXYXRjaFNhbGUuY29tIj48U1RS T05HPjxGT05UIA0KZmFjZT1WZXJkYW5hPlF1ZXN0aW9uc0BTd2lzc1dhdGNoU2FsZS5jb208 L0ZPTlQ+PC9TVFJPTkc+PC9BPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpmYWNlPVZlcmRhbmE+ PFNUUk9ORz4gPC9TVFJPTkc+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5IaSwmbmJzcDs8QlI+VGhhbmsgeW91IGZv ciBleHByZXNzaW5nIGludGVyZXN0IGluIA0KQVRHV1Mgd2F0Y2hlcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+V2Ugd291bGQgbGlrZSB0byB0YWtl IHRoaXMgb3Bwb3J0dW5pdHkgdG8gb2ZmZXIgDQp5b3Ugb3VyIGZpbmUgc2VsZWN0aW9uIG9m IEl0YWxpYW4gY3JhZnRlZCBSb2xleCBUaW1lcGllY2VzLiZuYnNwOzxCUj5Zb3UgY2FuIA0K dmlldyBvdXIgbGFyZ2Ugc2VsZWN0aW9uIG9mIFJvbGV4ZXMgKGluY2x1ZGluZyBCcmVpdGxp bmcsIFRhZyBIZXVlciwgQ2FydGllciANCmV0YykgYXQ6PC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48QSANCmhyZWY9 Imh0dHA6Ly93d3cuU3dpc3NXYXRjaFNhbGUuY29tOjYzMjMvIj48U1RST05HPmh0dHA6Ly93 d3cuU3dpc3NXYXRjaFNhbGUuY29tOjYzMjMvPC9TVFJPTkc+PC9BPjwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+Rm9y IGFsbCBvcmRlcnMgcGxhY2VkIGluIHRoZSBtb250aCBvZiBKdW5lLCBhbGwgDQpzaGlwcGlu ZyBhbmQgaGFuZGxpbmcgY2hhcmdlcyB3aWxsIGJlIGZyZWUuJm5ic3A7PEJSPkFzIHdlIGFy ZSB0aGUgZGlyZWN0IA0KbWFudWZhY3R1cmVycywgeW91IGFyZSBndWFyYW50ZWVkIG9mIGxv d2VzdCBwcmljZXMgYW5kIGhpZ2hlc3QgcXVhbGl0eSBlYWNoIGFuZCANCmV2ZXJ5IHRpbWUg eW91IHB1cmNoYXNlIGZyb20gdXMuJm5ic3A7PEJSPllvdSBtYXkgYWxzbyBiZSBpbnRlcmVz dGVkIHRvIGtub3cgDQp0aGF0IHdlIGhhdmUgdGhlIGZvbGxvd2luZyBicmFuZHMgYXZhaWxh YmxlIGluIG91ciB3aWRlIHNlbGVjdGlvbiBhcyB3ZWxsOiANCjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4xLiBMZWF0aGVyIGJhbmQgRGF5dG9uYSAo bGFkaWVzIGFuZCBtZW6hr3MpIDxCUj4yLiANCkJsYW5jcGFpbjxCUj4zLiBGb3J0aXM8QlI+ NC4gSmFlZ2VyIExlQ291dHJlPEJSPjUuIExvbmdpbmVzPEJSPjYuIE1vbnQgDQpCbGFuYzxC Uj43LiBNb3ZhZG88QlI+OC4gT3JpczxCUj45LiBSb2dlciBEdWJ1aXM8QlI+MTAuIFVseXNz ZTxCUj4xMS4gDQpaZW5pdGg8QlI+MTIuIEF1ZGVtYXIgUGlndWV0PEJSPjEzLiBCcmVpdGxp bmc8QlI+MTQuIEJ2Z2xhcmk8QlI+MTUuIA0KQ2FydGllcjxCUj4xNi4gQ29ydW08QlI+MTcu IER1bmhpbGw8QlI+MTguIEZyYW5jayBNdWxsZXI8QlI+MTkuIEdlcmFyZCANClBlcnJlZ2F1 eDxCUj4yMC4gSVdDPEJSPjIxLiBJV0M8QlI+MjIuIFBhbmVyYWk8QlI+MjMuIFBhdGVrIFBo aWxpcHBlPEJSPjI0LiBUYWcgDQpIZXVlcjxCUj4yNS4gVmFjaGVyb24gQ29uc3RhbnRpbjxC Uj4mbmJzcDs8QlI+SWYgeW91IHNlZSBhbnl0aGluZyB0aGF0IG1pZ2h0IA0KaW50ZXJlc3Qg eW91LCBvciBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLCBwbGVhc2UgZG9uJ3QgaGVzaXRh dGUgdG8gdmlzaXQgb3VyIA0Kd2Vic2l0ZSBhdDo8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxBIA0KaHJlZj0iaHR0 cDovL3d3dy5Td2lzc1dhdGNoU2FsZS5jb206NjMyMy8iPjxTVFJPTkc+aHR0cDovL3d3dy5T d2lzc1dhdGNoU2FsZS5jb206NjMyMy88L1NUUk9ORz48L0E+PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5JIGNlcnRh aW5seSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIA0KeW91LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5CZXN0IHJlZ2FyZHMsPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPkNhbDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9VmVyZGFuYT5EaXZpc2lvbiBTYWxlcyBN YW5hZ2VyPEJSPkFUR1dTJm5ic3A7Jm5ic3A7IA0KPEJSPllvdSByZWNlaXZlZCB0aGlzIGVt YWlsIGJlY2F1c2UgeW91ciBoYXZlIHByZXZpb3VzIHB1cmNoYXNlZCBmcm9tLCBvciANCmlu cXVpcmVkIGFib3V0IG91ciBwcm9kdWN0IGxpbmUgdW5kZXIgQVRHV1MuIElmIHlvdSBkbyBu b3Qgd2FudCB0byByZWNlaXZlIA0KZnVydGhlciBtYWlsaW5ncyBmcm9tIEFUR1dTLCB1bnN1 YnNjcmliZSBieSBzZW5kaW5nIGFuIGVtYWlsIHdpdGggdGhlIHRpdGxlIA0KaGVhZGluZzog REVMRVRFIGluIHRoZSBzdWJqZWN0IGxpbmUgdG8gPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRv OnVuc3Vic2NyaWJlQFN3aXNzV2F0Y2hTYWxlLmNvbSI+PFNUUk9ORz48Rk9OVCANCmZhY2U9 VmVyZGFuYT51bnN1YnNjcmliZUBTd2lzc1dhdGNoU2FsZS5jb208L0ZPTlQ+PC9TVFJPTkc+ PC9BPjxGT05UIA0KZmFjZT1WZXJkYW5hPjxTVFJPTkc+IDwvU1RST05HPjwvRk9OVD48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48U1RST05HPjxGT05UIGNvbG9y PSNmZjAwMDAgZmFjZT1WZXJkYW5hPnBsZWFzZSBub3RlIHRvIHNlbmQgQUxMIFJFUExZIA0K ZS1tYWlsIGRpcmVjdCB0byBvdXIgU2FsZXMgUmVwcmVzZW50YXRpdmUgYXQ6PEJSPjwvRk9O VD48L1NUUk9ORz48QSANCmhyZWY9Im1haWx0bzpRdWVzdGlvbnNAU3dpc3NXYXRjaFNhbGUu Y29tIj48U1RST05HPjxGT05UIA0KZmFjZT1WZXJkYW5hPlF1ZXN0aW9uc0BTd2lzc1dhdGNo U2FsZS5jb208L0ZPTlQ+PC9TVFJPTkc+PC9BPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpmYWNl PVZlcmRhbmE+PFNUUk9ORz4gPC9TVFJPTkc+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+DQog ICAg ------=_NextPart_000_0059_4365F819.1AE85D1B-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jun 16 09:33:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZc-0006x7-00 for ; Thu, 19 Jun 2003 10:15:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:12 +0200 (CEST) Received: (qmail 12637 invoked by uid 65534); 16 Jun 2003 07:37:31 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 16 Jun 2003 09:37:31 +0200 Received: by moria.seul.org (Postfix) id 9051B33C89; Mon, 16 Jun 2003 03:37:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1D43533C82; Mon, 16 Jun 2003 03:37:28 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 7F61633C7D for ; Mon, 16 Jun 2003 03:37:27 -0400 (EDT) Received: from gprs3-69.eurotel.cz ([160.218.146.69] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19RoYM-0000oi-00 for f-cpu@seul.org; Mon, 16 Jun 2003 09:37:24 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19RoU9-0000Oz-00 for f-cpu@seul.org; Mon, 16 Jun 2003 09:33:01 +0200 Date: Mon, 16 Jun 2003 09:33:01 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile In-Reply-To: <200306151114.27963.nicolas.boulay@ifrance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > > > But is that good or not ? 4x 1r1w regifile will be ~30% faster than a > > > true 3r2w. > > > > The worst case is, by definition, always bad (or even worse ;). > > There is a miss understanding. The worst case the case where it slower. 3r2w > SRAM memory are ~30% slower than 1r1w SRAM. But if we use 1r1w SRAM bank > there is some collision that "could" be avoid by the compiler (otherwise you > loose one cycle). > > I can't say was is worst. It fully depend on compiler. I'm afraid nicO that you initiated the discussion by query which has no answer unless exhaustive simulation of both hw and sw is done. When I did gcc tests for single issue f-cpu I found that there is average 1.4 insn in-progress at any time (for well scheduled code) with peaks of 3 insn at time (often slow add+move+mul). So that one could say that with 4 banks it should be ok. Unfortunately read targets are not tightly corelated with write targets - if you force gcc to alter register allocation to minimize read port bank overlaps it forces write port bank overlaps. 1.4*3(2w1w insn) = 4.2 - so there is chance that they will fit into 4 banks - but there could be ties from earlier code which already dictated bank assignments to prevent its own stalls. I can imagine 4 1r1w banks to be 30% faster because of their natural speed or they can also be much slower because much of code is "overconstrained" and you can't allocate banks are freely as you might imagine. I'd suggest you to look at our gcc port - it is not "so" hard and will give you stronger insight into compiler limits and also gives you tool to quickly evaluate/validate your ideas. BTW, I just created design which uses SDRAM module and found interesting thing. The beast can deliver data at 133 MHz clock (of course there is still row precharge and other latencies but eliminated by banking) the same rate as my xilinx design can go. When one creates cpu within fpga then bursting SDRAMs are relatively so fast that one can eliminate all caches but L0 (or L1, depends on naming) ... devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 16 15:10:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZp-0006x7-00 for ; Thu, 19 Jun 2003 10:15:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:25 +0200 (CEST) Received: (qmail 23056 invoked by uid 65534); 16 Jun 2003 13:05:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 16 Jun 2003 15:05:44 +0200 Received: by moria.seul.org (Postfix) id 50C8733D85; Mon, 16 Jun 2003 09:05:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CD57F33D7F; Mon, 16 Jun 2003 09:05:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 292B833C7E for ; Mon, 16 Jun 2003 09:05:39 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-27.n.club-internet.fr [213.44.3.27]) by relay-1v.club-internet.fr (Postfix) with ESMTP id B2CC5804 for ; Mon, 16 Jun 2003 15:05:36 +0200 (CEST) Message-ID: <3EEDC1B7.30009@f-cpu.org> Date: Mon, 16 Jun 2003 15:10:15 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hello, Anup Gangwar wrote: >Hi, > > I have been reading posts on this list for long but have never >posted any message myself. In my opinion going for simpler (less R+W >ports) RF's will be advantageous from two viewpoints: > >1. If we stick to at most 2R+2W ports then the CPU could easily work with >FPGA technology a big+ while prototyping. > > this creates a problem : F-CPU is not meant to use *only* FPGA. so if we develop with FPGA in mind (call this a "least common feature problem") the design will not exploit all the potential of ASICs. and after all : even if a 3R2W RF is 3x slower than 1R1W, you're still overlooking something : it will *work* ! (look at Don's post). the architecture of the RF can be locally modified to maybe allow more cycles or better behaviour. If we make it work now, with a full-featured set of features (and no compiler constraints) then people will use it happily, even if it is 1 million times slower than the latest Intel/AMD horse. Not only will they use it but they will get used to the fact that there is few coding constraints. >2. The larger the RF the slower it will be. > The RF has 63 registers that are *at least* 64-bit wide. so it's already slow from the start, right ? > Everyone is breaking up the RF >into smaller chunks (clusters of FUs). > can you point us to references about "everyone" ? >As per one heuristic estimate the power, delay and max freq grow > > as atleast N^1.5 where N is the no. of FUs per RF. > >6. The compiler complexity will not grow too much > there is a problem here with the "too much" : it's not quantifiable if it is not programmed. and as you have probably remarked, few people here are eager to write code. >if each of the >individual clusters is connected to the other in a homogeneous fashion. >Though a variety of interconnect strategies are possible. > > here you propose an architecture where the core is split into "clusters" with each a small register set and some "Execution Units". right ? (if yes, then it has already been discussed ....) >Regards, > > read you soon, >Anup > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jun 16 15:10:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZq-0006x7-00 for ; Thu, 19 Jun 2003 10:15:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:26 +0200 (CEST) Received: (qmail 27700 invoked by uid 65534); 16 Jun 2003 13:06:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 16 Jun 2003 15:06:06 +0200 Received: by moria.seul.org (Postfix) id 4D61133C7E; Mon, 16 Jun 2003 09:06:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A84F133D7F; Mon, 16 Jun 2003 09:06:00 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 34DBA33C7E for ; Mon, 16 Jun 2003 09:06:00 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-27.n.club-internet.fr [213.44.3.27]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 2648580E for ; Mon, 16 Jun 2003 15:05:59 +0200 (CEST) Message-ID: <3EEDC1CD.3060602@f-cpu.org> Date: Mon, 16 Jun 2003 15:10:37 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] How far from a usable system? References: <3EECC77D.1010205@digitalstatecraft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Donald A. Dade wrote: > Hello list, > > All the FAQs that I've found seemed to be fairly old, or not dated at > all. I was trying to determine if/when people will be able to obtain > an f-cpu based system. I, for one, don't care if it's not quite as > economical nor as fast as the Intel offerings. It would just feel > *good* to use a system like that. > > So, what is the state of the project, and what is the estimate for the > arrival of sample systems? as for the arrival of a "sample system" (this is extremely vague) : no idea. it's certainly not going to the foundry before ages. Source code is slowly advancing, however. as for the state : look by yourself on how this list behaves :-) anyway, you can get the most recent design files from http://f-cpu.seul.org/new/ (that's a ftp where one puts his own version of the sources from time to time). sorry if it is disapointing, ut you'll see that F-CPU can be fun sometimes :-/ > Don YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Mon Jun 16 15:13:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZq-0006x7-01 for ; Thu, 19 Jun 2003 10:15:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:26 +0200 (CEST) Received: (qmail 5122 invoked by uid 65534); 16 Jun 2003 13:13:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 16 Jun 2003 15:13:50 +0200 Received: by moria.seul.org (Postfix) id 9AE5233C84; Mon, 16 Jun 2003 09:13:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5575F33D86; Mon, 16 Jun 2003 09:13:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by moria.seul.org (Postfix) with ESMTP id E244133C84 for ; Mon, 16 Jun 2003 09:13:33 -0400 (EDT) Received: from nerim.net (crateria.nerim.net [62.4.16.75]) by kraid.nerim.net (Postfix) with SMTP id 7B58040FFA for ; Mon, 16 Jun 2003 15:13:32 +0200 (CEST) Received: from 140.94.82.18 (SquirrelMail authenticated user cyrano) by www.nerim.net with HTTP; Mon, 16 Jun 2003 15:13:33 +0200 (CEST) Message-ID: <3954.140.94.82.18.1055769213.squirrel@www.nerim.net> Date: Mon, 16 Jun 2003 15:13:33 +0200 (CEST) Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile From: To: In-Reply-To: <3EEDC1B7.30009@f-cpu.org> References: <3EEDC1B7.30009@f-cpu.org> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > hello, > > Anup Gangwar wrote: > >>Hi, >> >> I have been reading posts on this list for long but have never >>posted any message myself. In my opinion going for simpler (less R+W >> ports) RF's will be advantageous from two viewpoints: >> >>1. If we stick to at most 2R+2W ports then the CPU could easily work >> with FPGA technology a big+ while prototyping. >> >> > > this creates a problem : F-CPU is not meant to use *only* FPGA. > so if we develop with FPGA in mind (call this a "least common feature > problem") > the design will not exploit all the potential of ASICs. > > and after all : even if a 3R2W RF is 3x slower than 1R1W, you're still > overlooking something : > it will *work* ! (look at Don's post). > *work* : it's not sure, more than 1r1w for internal SRAM is rare. Bank: + faster clock - common - collision multiported logic : + no collision - slower clock - should be done at transistor level (fast) or see of gate (mega slow) I will try to synthesys the code of michael. >>2. The larger the RF the slower it will be. >> > The RF has 63 registers that are *at least* 64-bit wide. > so it's already slow from the start, right ? > Adding port slowdown things and 6 stage mul became a no-sens (when 3 or 2 will be enought). nicO <...> > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From anup@cse.iitd.ernet.in Mon Jun 16 17:10:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuZu-0006x7-00 for ; Thu, 19 Jun 2003 10:15:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:30 +0200 (CEST) Received: (qmail 23140 invoked by uid 65534); 16 Jun 2003 14:59:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 16 Jun 2003 16:59:18 +0200 Received: by moria.seul.org (Postfix) id D326833D86; Mon, 16 Jun 2003 10:59:15 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 354C833D89; Mon, 16 Jun 2003 10:59:15 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from desh.cse.iitd.ernet.in (mailer.cse.iitd.ac.in [202.141.68.3]) by moria.seul.org (Postfix) with ESMTP id 1778F33D86 for ; Mon, 16 Jun 2003 10:59:12 -0400 (EDT) Received: from saveri.cse.iitd.ernet.in (IDENT:QesnaE2Q5V8B15uKghugmp5V4TVHW8Ng@saveri.cse.iitd.ernet.in [10.20.11.20]) by desh.cse.iitd.ernet.in (8.11.6/8.11.6) with ESMTP id h5GFAlB13952 for ; Mon, 16 Jun 2003 20:40:47 +0530 Date: Mon, 16 Jun 2003 20:40:47 +0530 (IST) From: Anup Gangwar X-X-Sender: anup@saveri.cse.iitd.ernet.in. To: f-cpu@seul.org Subject: Re: [f-cpu] use of 1r1w regfile for our 3r2w regfile In-Reply-To: <3EEDC1B7.30009@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi, On Mon, 16 Jun 2003, Yann Guidon wrote: > hello, > > Anup Gangwar wrote: > > >Hi, > > > > I have been reading posts on this list for long but have never > >posted any message myself. In my opinion going for simpler (less R+W > >ports) RF's will be advantageous from two viewpoints: > > > >1. If we stick to at most 2R+2W ports then the CPU could easily work with > >FPGA technology a big+ while prototyping. > > > > > > this creates a problem : F-CPU is not meant to use *only* FPGA. > so if we develop with FPGA in mind (call this a "least common feature > problem") > the design will not exploit all the potential of ASICs. I agree, however, what I meant to say was that this will be a big plus in the initial prototyping stage. FPGA's are cheap readily available etc. etc. We could increase the ports by one for ASIc but beyond that even the ASIC RF tech. will fall short of the clock requirements. FUs will be way too fast. A comparison using High Level Synthesis is out of question, since most of the RFs are custom designed. I can point to a reference though: http://www.cs.rice.edu/~rixner/rixner_hpca6.pdf This is a quite exhaustive examination of register organization for high-issue processors. We can learn from their experiences and adopt the same. > > and after all : even if a 3R2W RF is 3x slower than 1R1W, you're still > overlooking something : > it will *work* ! (look at Don's post). > > the architecture of the RF can be locally modified to maybe allow more > cycles > or better behaviour. If we make it work now, with a full-featured set of > features > (and no compiler constraints) then people will use it happily, even if > it is 1 million times > slower than the latest Intel/AMD horse. Not only will they use it but > they will get used > to the fact that there is few coding constraints. > > >2. The larger the RF the slower it will be. > > > The RF has 63 registers that are *at least* 64-bit wide. > so it's already slow from the start, right ? The problem is not from the no. of registers but rather from the no. of ports. Even if we increase the no. of registers from 64 to 128 it will not be as bad as adding another port. > > > Everyone is breaking up the RF > >into smaller chunks (clusters of FUs). > > > can you point us to references about "everyone" ? > Sure, here are the architectures which immediately come to my mind: Sun's MAJC, TiC6x, Intel EPIC (2+ yrs. down the line), Siroyan. The oldest one is from Digital. One of the Alpha processors had a split RF. However, both the Alpha's as well as MAJC's RF are compiler transparent. Here is an article from Microprocessor Report on Intel's future architecture: http://www.cs.cmu.edu/afs/cs/academic/class/15740-f02/public/doc/discussions/uniprocessors/ia64/mpr_ia64_demyst_jan98.pdf > >As per one heuristic estimate the power, delay and max freq grow > > > > as atleast N^1.5 where N is the no. of FUs per RF. > > > >6. The compiler complexity will not grow too much > > > there is a problem here with the "too much" : > it's not quantifiable if it is not programmed. > and as you have probably remarked, few people here > are eager to write code. I agree, that it is not quantifiable till someone has actually done it. However, for some time I have been working on developing compilers for such architectures. But nothing is out as of now, due to all being hypothetical architectures. > > >if each of the > >individual clusters is connected to the other in a homogeneous fashion. > >Though a variety of interconnect strategies are possible. > > > > > here you propose an architecture where the core is split into "clusters" > with each a small register set and some "Execution Units". > right ? (if yes, then it has already been discussed ....) Sure yes. I will read up the previous posts. Thanks. > > >Regards, > > > > > read you soon, > > >Anup > > > > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jwstolk@yahoo.com Tue Jun 17 00:55:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuaN-0006x7-00 for ; Thu, 19 Jun 2003 10:15:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:59 +0200 (CEST) Received: (qmail 31129 invoked by uid 65534); 16 Jun 2003 22:56:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 17 Jun 2003 00:56:03 +0200 Received: by moria.seul.org (Postfix) id 2D84E33B60; Mon, 16 Jun 2003 18:55:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 97BB133D9A; Mon, 16 Jun 2003 18:55:56 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by moria.seul.org (Postfix) with SMTP id 4C97F33B60 for ; Mon, 16 Jun 2003 18:55:55 -0400 (EDT) Message-ID: <20030616225554.6026.qmail@web14206.mail.yahoo.com> Received: from [130.89.243.55] by web14206.mail.yahoo.com via HTTP; Mon, 16 Jun 2003 15:55:54 PDT Date: Mon, 16 Jun 2003 15:55:54 -0700 (PDT) From: jaap stolk Subject: Re: [f-cpu] was 1r1w 3r2w To: f-cpu@seul.org In-Reply-To: <3EEDC1B7.30009@f-cpu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi, > here you propose an architecture where the core is > split into "clusters" > with each a small register set and some "Execution > Units". > right ? (if yes, then it has already been discussed > ....) > i don't want to get into the discussion of on-chip clusters, but i have been walking around with this idea for a while: can we have a separate cpu core between external memory and cache memory ? the main core has ONLY access to the cache memory, and the extra core has access to both memory's. the extra core runs a (short!) program, and is controlled by the main core. (but this program can be changed for specific situations. the extra core can: -compress code/data from cache memory to main memory. -decompress code/data from main memory to cache memory. -schedule memory loads, (in co-operation with the main scheduler) so we can reach much lower worst -case situations in a hard-real-time system. (like a prefetch instruction, but more intelligent) -do all to distributed memory stuff. -work as a co-processor when there is nothing else to do. compression can be as simple as bit stuffing. if you know that your data is in a 0..500 range, you can tell the extra core to store it in a 9 bit format. (i have run some experiments in the past on using bit-pointers instead of byte pointers) external memory is cheep, but this would also lower the needed external bandwidth, and the needed pincount, witch could have a big effect on the total cost. i should stop now... jaap. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Jun 17 01:29:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19SuaN-0006x7-01 for ; Thu, 19 Jun 2003 10:15:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 19 Jun 2003 10:15:59 +0200 (CEST) Received: (qmail 23643 invoked by uid 65534); 16 Jun 2003 23:25:07 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 17 Jun 2003 01:25:07 +0200 Received: by moria.seul.org (Postfix) id 705ED33D9A; Mon, 16 Jun 2003 19:25:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6863133D9B; Mon, 16 Jun 2003 19:25:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by moria.seul.org (Postfix) with ESMTP id 17EAE33D9A for ; Mon, 16 Jun 2003 19:25:01 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-33.n.club-internet.fr [213.44.12.33]) by relay-2m.club-internet.fr (Postfix) with ESMTP id 6B7FF1747 for ; Tue, 17 Jun 2003 01:24:42 +0200 (CEST) Message-ID: <3EEE52C1.9090804@f-cpu.org> Date: Tue, 17 Jun 2003 01:29:05 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] was 1r1w 3r2w References: <20030616225554.6026.qmail@web14206.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! fine but .... F-CPU is a "general purpose computer processor for use in Unix-like systems". if it was a special-purpose CPU targeted at a specific use, well, this could have worked, but how would you manage 2 different cores with different instruction sets and programming models, not only from the system's point of view but also from the userland programmer's POV ? what about the programming model ? one CPU is already annoying enough .... YG jaap stolk wrote: >Hi, > > > >>here you propose an architecture where the core is >>split into "clusters" >>with each a small register set and some "Execution >>Units". >>right ? (if yes, then it has already been discussed >>....) >> >> >> > >i don't want to get into the discussion of on-chip >clusters, but i have been walking around with this >idea for a while: > >can we have a separate cpu core between external >memory >and cache memory ? the main core has ONLY access to >the >cache memory, and the extra core has access to both >memory's. > >the extra core runs a (short!) program, and is >controlled >by the main core. (but this program can be changed for >specific situations. > >the extra core can: >-compress code/data from cache memory to main memory. >-decompress code/data from main memory to cache >memory. >-schedule memory loads, (in co-operation with the main > scheduler) so we can reach much lower worst -case > situations in a hard-real-time system. > (like a prefetch instruction, but more intelligent) >-do all to distributed memory stuff. >-work as a co-processor when there is nothing else to > do. > >compression can be as simple as bit stuffing. if you >know that your data is in a 0..500 range, you can tell >the extra core to store it in a 9 bit format. >(i have run some experiments in the past on using >bit-pointers instead of byte pointers) > >external memory is cheep, but this would also lower >the needed external bandwidth, and the needed >pincount, >witch could have a big effect on the total cost. > >i should stop now... > >jaap. > > > >__________________________________ >Do you Yahoo!? >SBC Yahoo! DSL - Now only $29.95 per month! >http://sbc.yahoo.com >************************************************************* >To unsubscribe, send an e-mail to majordomo@seul.org with >unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From info_master@yume.otegami.com Fri Jun 20 00:19:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19UBbG-00036j-01 for ; Sun, 22 Jun 2003 22:38:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 22 Jun 2003 22:38:10 +0200 (CEST) Received: (qmail 20246 invoked by uid 65534); 19 Jun 2003 22:20:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 20 Jun 2003 00:20:06 +0200 Received: by moria.seul.org (Postfix) id 6230933B70; Thu, 19 Jun 2003 18:20:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2616933B75; Thu, 19 Jun 2003 18:20:02 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 7C8A933B70 for ; Thu, 19 Jun 2003 18:20:01 -0400 (EDT) Received: from yume1620.com (f029.ac130.FreeBit.NE.JP [43.244.130.29]) by belegost.mit.edu (Postfix) with SMTP id 783BC121A36 for ; Thu, 19 Jun 2003 18:20:00 -0400 (EDT) From: dvd1 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C|=94\=90l=83n=83v=83j=83=93=83O=91=E5=91S=8FW=81I=82=A0=82=CC=83A=83C=83h=83=8B=82=DC=82=C5=82=E0=81E=81E=81E?= Date: Fri, 20 Jun 2003 07:19:56 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="458910ea-8ecf-4590-a6ab-86b6fd89e6cf" Message-Id: <20030619222000.783BC121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --458910ea-8ecf-4590-a6ab-86b6fd89e6cf Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://net-channel777.com/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dm_master@yume.otegami.com .=82=A9=82=C8=82=E7=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=91=97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=81=9A3=93=FA=8A=D4=82=CC=82=DD=81=9A=8C=C0= =92=E850=96{=91=E5=93=C1=89=BF=81I=83v=83=8C=83~=83ADVD=93=C1=8FW=81I=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=93=C1=95=CA=8C=83=88=C0=89= =BF=8Ai=82=C9=82=C4=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=8C=A9=82=C8=82=AD=82=BF=82=E1=91=B9=82=B7=82=E9=81I=8C=A9=82=C8=82=AD=82=BF= =82=E1=82=A8=82=AD=82=EA=82=E9=81I .=91=E5=97e=97=CADVD-ROM=81@4.7GB!! .=82=B1=82=EA1=96=87=82=C5=82=B7=82=D7=82=C4=82=AA=8E=FB=98^=81I=81I .=82=A0=82=CC=97L=96=BC=90l=8BC=83A=83C=83h=83=8B=81E=8F=97=8Eq=83A=83i=81= E=83=8C=81[=83X=83N=83C=81[=83=93=82=C8=82=C7=91S=82=C4=82=CC=82=A8=95=F3=89= f=91=9C=82=AA=82=B1=82=B1=82=C9=81I=81I . =81=9A =82=BB=82=CC=91=BC=81A=91f=90l=89=E6=91=9C=82=E0=96= =9E=8D=DA =81=9A . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel777.com/=81= @=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . .=92=8D=81j=95=BD=90=AC15=94N6=8C=8E22=93=FA=81i=93=FA=81j10:00 =81` 13:00 = =81i=82g=82o=8DX=90V=8D=EC=8B=C6=82=C9=82=E6=82=E8=89{=97=97=82=C5=82=AB=82=DC= =82=B9=82=F1=81j --458910ea-8ecf-4590-a6ab-86b6fd89e6cf-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From weitekai@vip.sina.com Wed Jun 25 12:45:27 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19VKXi-00021i-00 for ; Thu, 26 Jun 2003 02:23:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 26 Jun 2003 02:23:14 +0200 (CEST) Received: (qmail 19741 invoked by uid 65534); 23 Jun 2003 10:45:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Jun 2003 12:45:27 +0200 Received: by moria.seul.org (Postfix) id 2854433C64; Mon, 23 Jun 2003 06:45:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2B3AE33C62; Mon, 23 Jun 2003 06:45:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from vip2125.com (unknown [218.17.205.206]) by moria.seul.org (Postfix) with SMTP id E039A33C5F for ; Mon, 23 Jun 2003 06:45:05 -0400 (EDT) From: =?gb2312?q?=BA=E3=C1=A6=C9=FA=CE=EF=B9=A4=B3=CC=D3=D0=CF=DE=B9=AB=CB=BE_ , ?=@seul.org To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?gb2312?q?=BD=A1=BF=B5=B0=E9=C2=C2=BD=BA=C4=D2=CA=C7=C4=FA=BD=A1=BF=B5=C9=FA=BB=EE=B5=C4=BA=C3=B0=E9=C2=C2!?= Date: Wed, 25 Jun 2003 18:45:27 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b755ec66-df47-4838-a5c2-fda94f3e1cba" Message-Id: <20030623104505.E039A33C5F@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.679; DATE_IN_FUTURE_48_96 PLING_QUERY) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --b755ec66-df47-4838-a5c2-fda94f3e1cba Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =C4=E3=BA=C3=A3=A1=D5=E2=CA=C7=D2=BB=B7=E2=C9=CC=D2=B5=C0=B4=BA=AF=A1=A3=C8=E7= =B9=FB=CE=D2=C3=C7=B4=F2=BD=C1=C1=CB=C4=FA=A3=AC=CE=D2=C3=C7=B1=ED=CA=BE=C9=EE= =C7=D0=B5=C4=C7=B8=D2=E2=A3=AC=C7=EB=C4=FA=CB=E6=CA=D6=C9=BE=B3=FD=CE=D2=C3=C7= =B5=C4=D3=CA=BC=FE=A3=AC=CE=D2=C3=C7=BD=AB=B2=BB=D4=D9=B4=F2=BD=C1=C4=FA=A1=A3= =D0=BB=D0=BB=C4=FA=B5=C4=C0=ED=BD=E2=BA=CD=D6=A7=B3=D6=A1=A3 =BD=A1=BF=B5=B0=E9=C2=C2=BD=BA=C4=D2=CA=C7=C4=FA=BD=A1=BF=B5=C9=FA=BB=EE= =B5=C4=BA=C3=B0=E9=C2=C2=A1=A3=D4=B8=C4=FA=B5=C4=C9=FA=BB=EEHealth and = Happy=A1=A3 =BD=A1=BF=B5=BE=CD=CA=C7=B2=C6=B8=BB=A3=AC=BF=EC=C0=D6=CA=C7=B8=F9=B1=BE=A1=A3= Health and Happy =CA=C7=BA=E3=C1=A6=C9=FA=CE=EF=B9=A4=B3=CC=D3=D0=CF=DE=B9=AB= =CB=BE=B5=C4=D7=B7=C7=F3=B5=C4=C4=BF=B1=EA=A1=A3=BD=A1=BF=B5=B0=E9=C2=C2=BD=BA= =C4=D2=CA=C7=B1=D6=B9=AB=CB=BE=B5=C4=C8=D9=D3=FE=B2=FA=C6=B7=A1=A3=CB=FD=BE=DF= =D3=D0=C8=E7=CF=C2=B9=A6=D0=A7=A3=BA (1)=B3=A4=C6=DA=B7=FE=D3=C3=BF=C9=D1=D3=BB=BA=CB=A5=C0=CF, =D3=C0=B1=A3= =C7=E0=B4=BA=A1=A3 (2)=CC=D8=D0=A7=BD=E2=D0=D1=BE=C6=D2=A9=B9=A6=C4=DC,=B1=A3=B8=CE=A1=A2=BB= =A4=B8=CE=A1=A3 (3)=B6=D4=CA=A7=C3=DF=D3=D0=D0=A7=A3=AC=CC=E1=B8=DF=CB=AF=C3=DF=D6=CA=C1= =BF,=BB=D6=B8=B4=CC=E5=C1=A6,=CC=E1=B8=DF=B9=A4=D7=F7=D0=A7=C1=A6=A1=A3 (4)=CC=E1=B8=DF=C4=E3=B5=C4=D0=D4=B9=A6=C4=DCNTP=A3=A8=B2=BB=C9=CB=C9=ED= =A3=A9=A1=A3 (5)=C5=E4=BA=CF=C6=E4=CB=FB=D2=A9=CE=EF=BF=C9=D4=F6=BC=D3=C6=E4=D2=A9=D0= =A7=A1=A3 (6)=B6=D4=D1=C7=BD=A1=BF=B5=D7=B4=CC=AC=D3=D0=C3=F7=CF=D4=D0=A7=B9=FB =A1= =A3 =CF=EA=C7=E9=C7=EB=C4=FA=B9=E2=B9=CB=CE=D2=B9=AB=CB=BE=B5=C4=CD=F8=D5=BE = http://www.hh1997.cn =BB=F2=C0=B4=B5=E7=D7=C9=D1=AF=A3=BAbitbeer@tom.com --b755ec66-df47-4838-a5c2-fda94f3e1cba-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@b05.blacksun.ca Fri Jun 27 09:52:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19W1tk-00043G-00 for ; Sat, 28 Jun 2003 00:40:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 00:40:52 +0200 (CEST) Received: (qmail 27245 invoked by uid 65534); 27 Jun 2003 07:52:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 27 Jun 2003 09:52:44 +0200 Received: by moria.seul.org (Postfix) id 4C06233B77; Fri, 27 Jun 2003 03:52:43 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BBBBD33B6D; Fri, 27 Jun 2003 03:52:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from b05.blacksun.ca (h139-142-202-38.gtcust.grouptelecom.net [139.142.202.38]) by moria.seul.org (Postfix) with ESMTP id E16C333B65 for ; Fri, 27 Jun 2003 03:52:41 -0400 (EDT) Received: (from root@localhost) by b05.blacksun.ca (8.10.2/8.10.2) id h5R7qcN23424; Fri, 27 Jun 2003 01:52:38 -0600 Date: Fri, 27 Jun 2003 01:52:38 -0600 Message-Id: <200306270752.h5R7qcN23424@b05.blacksun.ca> From: "MailScanner" To: f-cpu@seul.org Subject: [f-cpu] Warning: E-mail viruses detected X-MailScanner: generated Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Our virus detector has just been triggered by a message you sent:- To: glouis@dynamicro.on.ca Subject: Re: Application Date: Fri Jun 27 01:52:37 2003 Any infected parts of the message (your_details.zip) have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. The virus detector said this about the message: Report: >>> Virus 'W32/Sobig-E' found in file your_details.zip/details.pif -- MailScanner Email Virus Scanner www.mailscanner.info Mailscanner thanks transtec Computers for their support ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@firewall.wcom.com Fri Jun 27 09:58:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19W1tk-00043G-01 for ; Sat, 28 Jun 2003 00:40:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 00:40:52 +0200 (CEST) Received: (qmail 15671 invoked by uid 65534); 27 Jun 2003 08:08:37 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 27 Jun 2003 10:08:37 +0200 Received: by moria.seul.org (Postfix) id 58A9733B65; Fri, 27 Jun 2003 04:08:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B966633B6D; Fri, 27 Jun 2003 04:07:51 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from pmesmtp02.wcom.com (unknown [199.249.20.2]) by moria.seul.org (Postfix) with ESMTP id 23E2533B65 for ; Fri, 27 Jun 2003 04:07:44 -0400 (EDT) Received: from PROCESS-DAEMON.firewall.wcom.com by firewall.wcom.com (Iplanet MTA 5.2) id <0HH400F01QW7WH@firewall.wcom.com> for f-cpu@seul.org; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Received: from firewall.wcom.com (Iplanet MTA 5.2) id <0HH400J4LRH7W0@firewall.wcom.com>; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Date: Fri, 27 Jun 2003 07:58:19 +0000 (GMT) From: Internet Mail Delivery Subject: [f-cpu] Delivery Notification: Delivery has failed To: f-cpu@seul.org Message-id: <0HH400J4ORH7W0@firewall.wcom.com> MIME-version: 1.0 Content-type: multipart/report; report-type=delivery-status; boundary="Boundary_(ID_rv/04SZbjfFS8N7m5WkhCg)" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --Boundary_(ID_rv/04SZbjfFS8N7m5WkhCg) Content-type: text/plain; charset=us-ascii Content-language: EN-US This report relates to a message you sent with the following header fields: Return-path: Received: from tcp-wcommta.firewall.wcom.com by firewall.wcom.com (Iplanet MTA 5.2) id <0HH400J4LRH7W0@firewall.wcom.com> (original mail from f-cpu@seul.org); Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Received: from CONVERSION-DAEMON.firewall.wcom.com by firewall.wcom.com (Iplanet MTA 5.2) id <0HH400K01RAW4N@firewall.wcom.com> for support@wcom.com; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Received: from DAUPHIN ([194.2.150.6]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH400JB9RH2YE@firewall.wcom.com> for support@wcom.com; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Date: Fri, 27 Jun 2003 10:03:06 +0200 From: f-cpu@seul.org Subject: Re: Application To: support@wcom.com Message-id: <0HH400JBARH2YE@firewall.wcom.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_vcbg1Wd7uLCIr+tMr3nvsQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Your message cannot be delivered to the following recipients: Recipient address: support@wcom.com Reason: Remote SMTP server has rejected address Diagnostic code: smtp;550 5.1.2 unknown host or domain: support@wcom.com Remote system: dns;dgismtp00.wcomnet.com (TCP|199.249.20.2|39183|166.38.58.140|25) --Boundary_(ID_rv/04SZbjfFS8N7m5WkhCg) Content-type: message/delivery-status Original-envelope-id: 0HH400K8SRH74N@firewall.wcom.com Reporting-MTA: dns;firewall.wcom.com (tcp-wcommta) Original-recipient: rfc822;support@wcom.com Final-recipient: rfc822;support@wcom.com Action: failed Status: 5.1.2 (Remote SMTP server has rejected address) Remote-MTA: dns;dgismtp00.wcomnet.com (TCP|199.249.20.2|39183|166.38.58.140|25) Diagnostic-code: smtp;550 5.1.2 unknown host or domain: support@wcom.com --Boundary_(ID_rv/04SZbjfFS8N7m5WkhCg) Content-type: message/rfc822 Return-path: Received: from tcp-wcommta.firewall.wcom.com by firewall.wcom.com (Iplanet MTA 5.2) id <0HH400J4LRH7W0@firewall.wcom.com> (original mail from f-cpu@seul.org); Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Received: from CONVERSION-DAEMON.firewall.wcom.com by firewall.wcom.com (Iplanet MTA 5.2) id <0HH400K01RAW4N@firewall.wcom.com> for support@wcom.com; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Received: from DAUPHIN ([194.2.150.6]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH400JB9RH2YE@firewall.wcom.com> for support@wcom.com; Fri, 27 Jun 2003 07:58:19 +0000 (GMT) Date: Fri, 27 Jun 2003 10:03:06 +0200 From: f-cpu@seul.org Subject: Re: Application To: support@wcom.com Message-id: <0HH400JBARH2YE@firewall.wcom.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_SL+2nwJQjGFWhvlGlulhvQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal This is a multipart message in MIME format --Boundary_(ID_SL+2nwJQjGFWhvlGlulhvQ) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Please see the attached zip file for details. --Boundary_(ID_SL+2nwJQjGFWhvlGlulhvQ)-- --Boundary_(ID_rv/04SZbjfFS8N7m5WkhCg)-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From webmaster@microlon.co.kr Fri Jun 27 10:45:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19W1tn-00043G-01 for ; Sat, 28 Jun 2003 00:40:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 00:40:55 +0200 (CEST) Received: (qmail 24938 invoked by uid 65534); 27 Jun 2003 08:45:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 27 Jun 2003 10:45:29 +0200 Received: by moria.seul.org (Postfix) id C1CEE33B6C; Fri, 27 Jun 2003 04:45:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D531933B78; Fri, 27 Jun 2003 04:45:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from microlon.co.kr (unknown [211.202.85.127]) by moria.seul.org (Postfix) with SMTP id 9F68233B6C for ; Fri, 27 Jun 2003 04:45:22 -0400 (EDT) From: ¸¶ÀÌÅ©·Î·Ð To: Subject: *** GMX Spamverdacht *** [f-cpu] (±¤°í)ÀÚµ¿Â÷ ¼º´É ¾÷±×·¹ÀÌµå ºòÂù½º !! Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 27 Jun 2003 17:45:13 +0900 Message-Id: <20030627084522.9F68233B6C@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=13.2; HEADER_8BITS KOREAN_UCE_SUBJECT SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ¢Æ ¢Æ Microlon¿¡ ¿À½Å°É Áø½ÉÀ¸·Î ȯ¿µÇÕ´Ï´Ù...¢Æ ¢Æ

 

  

ÀÚµ¿Â÷ ¼º´É ¾÷±×·¹ÀÌµå ºò Âù½º!

¼¼°èÀû ¸íÇ° ¸¶ÀÌÅ©·Î·Ð(Microlon) °í°´ »çÀº ´ëÀÜÄ¡ Çϳª ´õ À̺¥Æ® !

  

¢Â ¼ÒÀ½, Áøµ¿ °¨¼Ò

¢Â ³ëÈÄ Â÷·® Ãâ·Â Áõ°­

¢Â ¿£Áø ¼ö¸í ¿¬Àå , ¼ö¸® ¹× À¯Áö ºñ¿ë Àý°¨

¢Â ¿¬ºñ »ó½Â (Æò±Õ 17%, ÃÖ´ë 30%)

¢Â ¹è±â°¡½º °¨¼Ò

 

¹Ì±¹,À¯·´,ÀϺ» µî ÀÚµ¿Â÷ ¼±Áø±¹¿¡¼­ ±Ý¼Ó ¸¶ÂûÀú°¨Á¦ÀÇ ¸íÇ°À¸·Î ÀÎÁ¤ ¹ÞÀº ¸¶ÀÌÅ©·Î·Ð Çѱ¹Áö»ç DY±Û·Î¹ú¢ß¿¡¼­ °í°´´ÔµéÀÇ ¼º¿ø¿¡ º¸´äÄÚÀÚ ÇÑ ´Þ°£ Çϳª ´õ À̺¥Æ®¸¦ ½Ç½ÃÇÕ´Ï´Ù. ±× µ¿¾È ³î¶ó¿î È¿°ú¸¦ ¾Ë°í ÀÖÀ½¿¡µµ ºÒ±¸ÇÏ°í ³ôÀº °¡°Ý ¶§¹®¿¡ ¸Á¼³¿´´ø °í°´´Ôµé¿¡°Ô ¸íÇ°ÀÇ ¼º´ÉÀ» Á÷Á¢ ´À³¥ ¼ö ÀÖ´Â ±âȸ¸¦ µå¸®°íÀÚ 7¿ù 31ÀÏ ±îÁö ¾à ÇÑ ´Þ°£ ¿£Áø¿ë Á¦Ç°À» ±¸ÀÔÇϽô ¸ðµç °í°´´Ôµé¿¡°Ô Á¦Ç°¿¡ µû¶ó ÀÚµ¿Â÷¿¡ ¾µ ¼ö ÀÖ´Â Á¦Ç°À» ¹«·á·Î Çϳª ´õ µå¸³´Ï´Ù.

 

ÀÚ¼¼ÇÑ ³»¿ëÀº ȨÆäÀÌÁö¸¦ ÂüÁ¶Çϼ¼¿ä.

 

¢Ñ À̺¥Æ® Âü¿©Çϱâ

 

     

 

±ÍÇÏÀÇ À̸ÞÀÏ ÁÖ¼Ò´Â °ø°³µÈ ÀÎÅÍ³Ý ÆäÀÌÁö(±¸ÀÎ ±¸Á÷ »çÀÌÆ®, °Ô½ÃÆÇ µî)¿¡¼­ ¼öÁýÇßÀ¸¸ç ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇØÁֽøé ÃßÈÄ¿¡´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ»°ÍÀÔ´Ï´Ù.

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 88@ms34.url.com.tw Fri Jun 27 21:53:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19W1uo-00043G-00 for ; Sat, 28 Jun 2003 00:41:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 00:41:58 +0200 (CEST) Received: (qmail 2386 invoked by uid 65534); 27 Jun 2003 19:56:28 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 27 Jun 2003 21:56:28 +0200 Received: by moria.seul.org (Postfix) id B6BA433CA1; Fri, 27 Jun 2003 15:56:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B5FB233B85; Fri, 27 Jun 2003 15:56:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from seul.org (254.c170.ethome.net.tw [202.178.170.254]) by moria.seul.org (Postfix) with SMTP id 614BF33B6D for ; Fri, 27 Jun 2003 15:56:20 -0400 (EDT) From: =?Big5?B?p0u+x776oULCsrPmoUK7tMNQoUKnS7hnvvqhQqRIpEilaaywoUKnS7jqvvo=?= <88@ms34.url.com.tw> Subject: *** GMX Spamverdacht *** [f-cpu] =?Big5?B?pHXFqi63c6bmt34us9C3fi6lW7f5LrWyt/kuwXC3+S6zc8LqLrFNwr4urd3Cvi4=?= Content-Type: text/html Date: Sat, 28 Jun 2003 03:53:35 +0800 X-Priority: 3 Message-Id: <20030627195620.614BF33B6D@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.513; FROM_ENDS_IN_NUMS UNDISC_RECIPS FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:

 ¦p¦³¥´ÂZ¦b¦¹­P¤W¸U¤Àºp·N¡F¤£Ä@¦¬¨ì¦¹«HªÌ¡F½Ð¦^¯u¹êe-mail§Ú¤~¯à­ç°£¡F¤U¦¸´N¤£·|¦A±H¨ì§A¨º£{¡F½Ð§O¦A½|§Ú£{¡AÁÂÁ§A¡C

¸Û¼x¡G1¡B·Q¶}«K§Q¶W°ÓªÌ¡F2¡B·Q°µ¤H¤O²Õ´³Æ¼W¨Æ·~ªÌ¡F3¡B·Q»P¥»¤½¥qµ²·ù¨É¦³§K¶O¼s§iªÌ

¡]¤@¡^¡B¦pªG»¡¦³~¤@¥÷¨Æ·~¸êª÷ ©±­± ±À¾P °e³f ¦¬±b§y³f ­·ÀI ·~ÁZ³q³q¤£¥Î~¼Ë¼Ë¤£»Ý§V¤O¸gÀç6-12­Ó¤ë´N¯à¾Ö¦³5-10¸U¤¸«ùÄò©Êªº²×¥Í¦¬¤J³o»ò¦nªº¾÷·|±z¤£¨Ó¸Õ¸Õ¶Ü¡H¼x¥þ¬Ù¥´«÷¹Ù¦ñ¡C

¡]¤G¡^¡B¦pªG±q«K§Q°Ó©±¥X¨Ó£x¤H¡F³£¸ò±z¦³Ãö«Y¡C¥Ø«e¥þ¬Ù¤w¦³40®a©±­±¡F±z¤£¥²¥XºÞ¾P¡F¨C®a10¤H´N¦n£{¡F10¤H*40¤¸(´N¹³¹L¸ô¶O)*40®a16000¤¸³o¼Ë£x¦¬¤J¡C¤£­n±z£x¥[·ùª÷»P«OÃÒª÷¡F¥u­n±z®ã¦ÌªoÆQÂæ¾L¯ù´«£|¦a¤è®ø¶O³º¤]¥i¥H¨Ó·í³sÂê¶W°Ó£x¦ÑÁó¡C

¡]¤T¡^¡B¥Ø«eÁÙ¦³400¦h®aµ²·ù©±¡]¦U¦æ·~³£¦³¡^­¹¡B¦ç¡B¦í¡B¦æ¡B¨|¡B¼Ö¼Ë¼Ë»ô¥þ¡F³£¸ò±z¦³Ãö«Y¡C

¥þ¥ÁÁp¦X³q¸ô¨Æ·~

§Ú­n¯Á¨ú§K¶Oªº³Ð·~¥úºÐ 

¤¤¤å©m¦W

 

©Ê§O

  

¦~ÄÖ

·³(18·³¥H¤W) 

Ápµ¸¹q¸Ü

¦æ°Ê¹q¸Ü

 

¦a§}

¹q¤l¶l¥ó

¦pªG±z¤£·Q¦A¦¬¨ì¬ÛÃö°T®§¡A½Ð¿é¤J±zªº¹q¤l¶l¥ó¡G
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 28 02:55:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WFOn-0000HJ-01 for ; Sat, 28 Jun 2003 15:05:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 15:05:49 +0200 (CEST) Received: (qmail 12656 invoked by uid 65534); 28 Jun 2003 00:56:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 28 Jun 2003 02:56:32 +0200 Received: by moria.seul.org (Postfix) id 16E9E33B69; Fri, 27 Jun 2003 20:56:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF77C33B5B; Fri, 27 Jun 2003 20:56:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a131.home.uni-hannover.de [130.75.232.131]) by moria.seul.org (Postfix) with ESMTP id 74D9933B69 for ; Fri, 27 Jun 2003 20:56:02 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA04206; Sat, 28 Jun 2003 02:55:59 +0200 Message-ID: <20030628025558.30310@thrai.stud.uni-hannover.de> Date: Sat, 28 Jun 2003 02:55:58 +0200 From: Michael Riepe To: F-CPU Mailing List Subject: [f-cpu] Simulating with GHDL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi guys, I'm currently testing ghdl 0.6. It's able to analyze my working sources, and the simulation programs also run, with minor additions that I'll include in my next release: When a component is instantiated, there is no default binding unless the entity name is "directly visible"; that is, you need to add a use clause or configuration specification for it, like this: component blah ... end component; -- solution #1: use clause use work.blah; -- or maybe work.all -- solution #2: configuration specification for all : blah use entity work.blah; The first solution is more convenient because the configuration specification has to be repeated in every nested block that instantiates the component, while the use clause has to be specified only once. If the entity is not directly visible and not bound by a configuration specification (or an external configuration declaration), the component will be unbound (that is, its "socket" will stay open) and the entity testbenches will produce garbage. Note: This is not a bug, the behavior is specified in the VHDL Language Reference Manual. At least that's what I understood... If you want to give ghdl a try, I suggest you use the following commands: # analyze source file(s) ghdl -a --std=93 --ieee=synopsys file.vhdl ... # elaborate ghdl -e --std=93 --ieee=synopsys entity_name # simulate ./entity_name There's only one restriction: You need a recent glibc based Linux/x86 system to run the ghdl binaries (available from http://ghdl.free.fr/ghdl-0.6-i686-pc-linux.tar). -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From info_master@yume.otegami.com Sat Jun 28 08:53:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WFOs-0000HJ-00 for ; Sat, 28 Jun 2003 15:05:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 15:05:54 +0200 (CEST) Received: (qmail 2089 invoked by uid 65534); 28 Jun 2003 06:54:45 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 28 Jun 2003 08:54:45 +0200 Received: by moria.seul.org (Postfix) id AD02D33B74; Sat, 28 Jun 2003 02:54:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C216033B6E; Sat, 28 Jun 2003 02:54:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from yume3388.com (f127.ac063.FreeBit.NE.JP [43.244.63.127]) by moria.seul.org (Postfix) with SMTP id D8B6F33B5B for ; Sat, 28 Jun 2003 02:54:37 -0400 (EDT) From: ene1 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=89=F5=8Ay=82=D6=82=CC=96=A2=92m=82=CC=90=A2=8AE=82=C9=81E=81E=81E=81i=8A=B4=93=AE=81I=81I?= Date: Sat, 28 Jun 2003 15:53:55 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4070ccdb-96c0-4707-9a00-3f2d15338e23" Message-Id: <20030628065437.D8B6F33B5B@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --4070ccdb-96c0-4707-9a00-3f2d15338e23 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://210.150.173.81/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dm_master@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=81=9A3=93=FA=8A=D4=82=CC=82=DD=81=9A=8C=C0= =92=E8=91=E5=93=C1=89=BF=81I=83v=83=8C=83~=83A=89=F5=8A=B4=8F=A4=95i=93=C1=8F= W=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=93=C1=95=CA=8C=83=88=C0=89= =BF=8Ai=82=C9=82=C4=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=8D=A1=93=FA=82=A9=82=E7=82=B1=82=EA=82=C5=96=A2=92m=82=CC=89=F5=8A=B4=82=D6= =81E=81E=81E .=97~=82=B5=82=A9=82=C1=82=BD=82=B1=82=F1=82=C8=83O=83b=83c=81I .=94=CC=94=84=90=94=97=CA=8C=C0=92=E8=93=C1=95=CA=83O=83b=83c .=82=C6=82=C9=82=A9=82=AD=8C=A9=82=C9=97=88=82=C4=82=AD=82=BE=82=B3=82=A2=81= =F4=81@=8C=A9=82=C4=91=B9=82=CD=82=C8=82=B5=81I=81I . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://210.150.173.81/=81@=81=E1= =81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --4070ccdb-96c0-4707-9a00-3f2d15338e23-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Jun 28 11:05:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WFOw-0000HJ-00 for ; Sat, 28 Jun 2003 15:05:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 28 Jun 2003 15:05:58 +0200 (CEST) Received: (qmail 21854 invoked by uid 65534); 28 Jun 2003 09:00:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012) with SMTP; 28 Jun 2003 11:00:25 +0200 Received: by moria.seul.org (Postfix) id A702433B76; Sat, 28 Jun 2003 05:00:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D44E933B80; Sat, 28 Jun 2003 05:00:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-4v.club-internet.fr (relay-4v.club-internet.fr [194.158.96.115]) by moria.seul.org (Postfix) with ESMTP id AFE4833B76 for ; Sat, 28 Jun 2003 05:00:04 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-127.n.club-internet.fr [213.44.18.127]) by relay-4v.club-internet.fr (Postfix) with ESMTP id 05A9416E8 for ; Sat, 28 Jun 2003 11:00:03 +0200 (CEST) Message-ID: <3EFD5A44.20705@f-cpu.org> Date: Sat, 28 Jun 2003 11:05:08 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >Hi guys, > >I'm currently testing ghdl 0.6. > glad you're still with us ;-P when you can, can you please update the VHDL HOWTO with the remarks you have done and whatever you have learnt ? Thanks in advance, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sat Jun 28 13:32:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WPjm-0008GO-00 for ; Sun, 29 Jun 2003 02:08:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 02:08:10 +0200 (CEST) Received: (qmail 1661 invoked by uid 65534); 28 Jun 2003 22:17:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 29 Jun 2003 00:17:27 +0200 Received: by moria.seul.org (Postfix) id 7D77733B75; Sat, 28 Jun 2003 18:17:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0A00F33B72; Sat, 28 Jun 2003 18:17:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a077.home.uni-hannover.de [130.75.232.77]) by moria.seul.org (Postfix) with ESMTP id BC60733B6A for ; Sat, 28 Jun 2003 18:17:22 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id NAA00519; Sat, 28 Jun 2003 13:32:08 +0200 Message-ID: <20030628133208.59799@thrai.stud.uni-hannover.de> Date: Sat, 28 Jun 2003 13:32:08 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EFD5A44.20705@f-cpu.org>; from Yann Guidon on Sat, Jun 28, 2003 at 11:05:08AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sat, Jun 28, 2003 at 11:05:08AM +0200, Yann Guidon wrote: [..] > >I'm currently testing ghdl 0.6. > > glad you're still with us ;-P Well, I'm too tired to run away ;-P > when you can, can you please update the VHDL HOWTO > with the remarks you have done and whatever you have learnt ? Why don't you just cut'n'paste my mail? -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 29 00:30:16 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WPjn-0008GO-00 for ; Sun, 29 Jun 2003 02:08:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 02:08:11 +0200 (CEST) Received: (qmail 16580 invoked by uid 65534); 28 Jun 2003 22:25:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 29 Jun 2003 00:25:11 +0200 Received: by moria.seul.org (Postfix) id 1FD2F33B5B; Sat, 28 Jun 2003 18:25:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F2DC033B71; Sat, 28 Jun 2003 18:25:09 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id B982933B5B for ; Sat, 28 Jun 2003 18:25:09 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-36.n.club-internet.fr [213.44.12.36]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 1D1EF7B4 for ; Sun, 29 Jun 2003 00:25:08 +0200 (CEST) Message-ID: <3EFE16F8.7090003@f-cpu.org> Date: Sun, 29 Jun 2003 00:30:16 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >On Sat, Jun 28, 2003 at 11:05:08AM +0200, Yann Guidon wrote: >[..] > > >>>I'm currently testing ghdl 0.6. >>> >>> >>glad you're still with us ;-P >> >> >Well, I'm too tired to run away ;-P > well, there could be other things .... i'm currently working on http://f-cpu.seul.org/new/layout2.gif >>when you can, can you please update the VHDL HOWTO >>with the remarks you have done and whatever you have learnt ? >> >> >Why don't you just cut'n'paste my mail? > > i would have to update a lot of other files and my development environment is ... heuh ... incomplete. But it's going to change one day. I spoke to Actel guyz and they will have a Linux version of their dev environment (sim, place, route etc.) by 2004, so i'll try to negociate a devkit and other resources. Their latest silicons are real heavens for F-CPU cores, but i fear that my RAM is really really too small for synthesis&place&route ;-) Sur ce, @+ YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jun 29 01:51:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WR9b-0000xx-00 for ; Sun, 29 Jun 2003 03:38:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 03:38:55 +0200 (CEST) Received: (qmail 28011 invoked by uid 65534); 28 Jun 2003 23:52:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 29 Jun 2003 01:52:02 +0200 Received: by moria.seul.org (Postfix) id 19D3833B63; Sat, 28 Jun 2003 19:52:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1AC433B72; Sat, 28 Jun 2003 19:51:59 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a077.home.uni-hannover.de [130.75.232.77]) by moria.seul.org (Postfix) with ESMTP id 2466933B63 for ; Sat, 28 Jun 2003 19:51:58 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id BAA02824; Sun, 29 Jun 2003 01:51:56 +0200 Message-ID: <20030629015155.46383@thrai.stud.uni-hannover.de> Date: Sun, 29 Jun 2003 01:51:55 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EFE16F8.7090003@f-cpu.org>; from Yann Guidon on Sun, Jun 29, 2003 at 12:30:16AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sun, Jun 29, 2003 at 12:30:16AM +0200, Yann Guidon wrote: [...] > >Well, I'm too tired to run away ;-P > > > well, there could be other things .... > i'm currently working on http://f-cpu.seul.org/new/layout2.gif Hmm... that's definitely not an F-CPU mainboard ;( [...] > I spoke to Actel guyz and they will have a Linux version > of their dev environment (sim, place, route etc.) by 2004, > so i'll try to negociate a devkit and other resources. Me too, me too... > Their latest silicons are real heavens for F-CPU cores, > but i fear that my RAM is really really too small for > synthesis&place&route ;-) I'm also looking for a sponsor ;) I wish I had something like the dual 1,8 GHz Opteron with 6 MByte of RAM that I tested recently... -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 29 02:02:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WR9b-0000xx-01 for ; Sun, 29 Jun 2003 03:38:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 03:38:55 +0200 (CEST) Received: (qmail 512 invoked by uid 65534); 28 Jun 2003 23:57:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 29 Jun 2003 01:57:43 +0200 Received: by moria.seul.org (Postfix) id 18CB033B71; Sat, 28 Jun 2003 19:57:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D67DD33B79; Sat, 28 Jun 2003 19:57:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 6750233B71 for ; Sat, 28 Jun 2003 19:57:41 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-4.n.club-internet.fr [213.44.3.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 0681C7EC for ; Sun, 29 Jun 2003 01:57:40 +0200 (CEST) Message-ID: <3EFE2CA8.4030500@f-cpu.org> Date: Sun, 29 Jun 2003 02:02:48 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >On Sun, Jun 29, 2003 at 12:30:16AM +0200, Yann Guidon wrote: >[...] > > >>>Well, I'm too tired to run away ;-P >>> >>well, there could be other things .... >>i'm currently working on http://f-cpu.seul.org/new/layout2.gif >> >> >Hmm... that's definitely not an F-CPU mainboard ;( > > i gotta train for the "big stuff" later. if i don't practice, routing BGAs etc. will be really tough. >>I spoke to Actel guyz and they will have a Linux version >>of their dev environment (sim, place, route etc.) by 2004, >>so i'll try to negociate a devkit and other resources. >> >> >Me too, me too... > > does that mean that you get out of your position that "you don't want to deal with companies" ? does that mean that you'd like to try their SW ? or even a demo board ?... :-) >>Their latest silicons are real heavens for F-CPU cores, >>but i fear that my RAM is really really too small for >>synthesis&place&route ;-) >> >> >I'm also looking for a sponsor ;) I wish I had something like the dual >1,8 GHz Opteron with 6 MByte of RAM that I tested recently... > 6Mbytes ? i wish there's a LOT of swap space ;-P YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jun 29 02:13:29 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WR9c-0000xx-00 for ; Sun, 29 Jun 2003 03:38:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 03:38:56 +0200 (CEST) Received: (qmail 21169 invoked by uid 65534); 29 Jun 2003 00:13:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 29 Jun 2003 02:13:36 +0200 Received: by moria.seul.org (Postfix) id 3EE6B33B79; Sat, 28 Jun 2003 20:13:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 38B8F33B7B; Sat, 28 Jun 2003 20:13:33 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a077.home.uni-hannover.de [130.75.232.77]) by moria.seul.org (Postfix) with ESMTP id 9E14033B72 for ; Sat, 28 Jun 2003 20:13:31 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id CAA02893; Sun, 29 Jun 2003 02:13:29 +0200 Message-ID: <20030629021329.14767@thrai.stud.uni-hannover.de> Date: Sun, 29 Jun 2003 02:13:29 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> <3EFE2CA8.4030500@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EFE2CA8.4030500@f-cpu.org>; from Yann Guidon on Sun, Jun 29, 2003 at 02:02:48AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi! [...] > does that mean that you get out of your position that "you don't want to > deal with companies" ? does that mean that you'd like to try their SW ? > or even a demo board ?... :-) Did I really say that? Of course I'll try their software, if the conditions are reasonable. If they give me a perpetual full license without asking for my date of birth, address, phone number and shoe size, and don't require me to download dozens of megabytes of stuff from the net, I'll happily use their SW, HW or whatever they have to offer. [...] > >I'm also looking for a sponsor ;) I wish I had something like the dual > >1,8 GHz Opteron with 6 MByte of RAM that I tested recently... > > > 6Mbytes ? i wish there's a LOT of swap space ;-P Err, GBytes of course. And HyperTransport interfaces to the peripherals. Didn't I always say that a serial link is better than a bus? ;) -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 29 02:22:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WR9c-0000xx-01 for ; Sun, 29 Jun 2003 03:38:56 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 29 Jun 2003 03:38:56 +0200 (CEST) Received: (qmail 14808 invoked by uid 65534); 29 Jun 2003 00:17:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 29 Jun 2003 02:17:09 +0200 Received: by moria.seul.org (Postfix) id B9D8533B80; Sat, 28 Jun 2003 20:17:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3E46D33B7D; Sat, 28 Jun 2003 20:17:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 051BB33B72 for ; Sat, 28 Jun 2003 20:17:07 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-4.n.club-internet.fr [213.44.3.4]) by relay-1v.club-internet.fr (Postfix) with ESMTP id ABC217DC for ; Sun, 29 Jun 2003 02:17:01 +0200 (CEST) Message-ID: <3EFE312A.5050305@f-cpu.org> Date: Sun, 29 Jun 2003 02:22:02 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> <3EFE2CA8.4030500@f-cpu.org> <20030629021329.14767@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >Hi! > >[...] > > >>does that mean that you get out of your position that "you don't want to >>deal with companies" ? does that mean that you'd like to try their SW ? >>or even a demo board ?... :-) >> >> >Did I really say that? > > hmmm i thought .... >Of course I'll try their software, if the conditions are reasonable. >If they give me a perpetual full license without asking for my date of >birth, address, phone number and shoe size, and don't require me to >download dozens of megabytes of stuff from the net, I'll happily use >their SW, HW or whatever they have to offer. > > hmmm i'll check. but not yet.... it's far from released yet. but we could be beta-testers ;-P concerning the size : i bet it's at least a hundred MB or something like that.... >[...] > > >>>I'm also looking for a sponsor ;) I wish I had something like the dual >>>1,8 GHz Opteron with 6 MByte of RAM that I tested recently... >>> >>> >>> >>6Mbytes ? i wish there's a LOT of swap space ;-P >> >> >Err, GBytes of course. And HyperTransport interfaces to the peripherals. > yeah. >Didn't I always say that a serial link is better than a bus? ;) > i thought it was nicO ;-P > > YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Sun Jun 29 10:25:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVA-0002In-00 for ; Mon, 30 Jun 2003 07:46:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:46:56 +0200 (CEST) Received: (qmail 31588 invoked by uid 65534); 29 Jun 2003 08:46:13 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 29 Jun 2003 10:46:13 +0200 Received: by moria.seul.org (Postfix) id BF97C33B8A; Sun, 29 Jun 2003 04:46:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C86FA33B86; Sun, 29 Jun 2003 04:46:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id B756733B54 for ; Sun, 29 Jun 2003 04:46:05 -0400 (EDT) Received: from gprs1-97.eurotel.cz ([160.218.144.97] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19WXov-0007BK-00 for f-cpu@seul.org; Sun, 29 Jun 2003 10:46:02 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19WXVV-0001Cx-00 for f-cpu@seul.org; Sun, 29 Jun 2003 10:25:57 +0200 Date: Sun, 29 Jun 2003 10:25:57 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] Simulating with GHDL In-Reply-To: <3EFE16F8.7090003@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: > well, there could be other things .... > i'm currently working on http://f-cpu.seul.org/new/layout2.gif btw, what tool do you use for the pcb layout ? > But it's going to change one day. > I spoke to Actel guyz and they will have a Linux version > of their dev environment (sim, place, route etc.) by 2004, > so i'll try to negociate a devkit and other resources. > Their latest silicons are real heavens for F-CPU cores, > but i fear that my RAM is really really too small for > synthesis&place&route ;-) :-) what's Actel ? Custom silicon or fpga ? devik ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nico@seul.org Sun Jun 29 15:14:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVQ-0002In-00 for ; Mon, 30 Jun 2003 07:47:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:47:12 +0200 (CEST) Received: (qmail 7452 invoked by uid 65534); 29 Jun 2003 11:23:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 29 Jun 2003 13:23:50 +0200 Received: by moria.seul.org (Postfix) id 68ABB33B54; Sun, 29 Jun 2003 07:23:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F1E033B72; Sun, 29 Jun 2003 07:23:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by moria.seul.org (Postfix) with ESMTP id BF95733B54 for ; Sun, 29 Jun 2003 07:23:48 -0400 (EDT) Received: from Bi (cyrano.net1.nerim.net [213.41.140.63]) by kraid.nerim.net (Postfix) with ESMTP id 4207540E39 for ; Sun, 29 Jun 2003 13:23:47 +0200 (CEST) From: Nicolas Boulay To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL Date: Sun, 29 Jun 2003 13:14:19 +0000 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200306291314.19297.nico@seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Le Dimanche 29 Juin 2003 08:25, devik a =E9crit : > > well, there could be other things .... > > i'm currently working on http://f-cpu.seul.org/new/layout2.gif > > btw, what tool do you use for the pcb layout ? > > > But it's going to change one day. > > I spoke to Actel guyz and they will have a Linux version > > of their dev environment (sim, place, route etc.) by 2004, > > so i'll try to negociate a devkit and other resources. > > Their latest silicons are real heavens for F-CPU cores, > > but i fear that my RAM is really really too small for > > synthesis&place&route ;-) > > > :-) what's Actel ? Custom silicon or fpga ? small antifuse fpga . > > devik > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 29 22:47:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVi-0002In-00 for ; Mon, 30 Jun 2003 07:47:30 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:47:30 +0200 (CEST) Received: (qmail 1073 invoked by uid 65534); 29 Jun 2003 20:42:48 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 29 Jun 2003 22:42:48 +0200 Received: by moria.seul.org (Postfix) id A607E33B49; Sun, 29 Jun 2003 16:42:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0AEE733B7B; Sun, 29 Jun 2003 16:42:44 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 88A0033B49 for ; Sun, 29 Jun 2003 16:42:44 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-141.n.club-internet.fr [213.44.12.141]) by relay-5m.club-internet.fr (Postfix) with ESMTP id D2C13E090 for ; Sun, 29 Jun 2003 22:42:42 +0200 (CEST) Message-ID: <3EFF5078.7040204@f-cpu.org> Date: Sun, 29 Jun 2003 22:47:52 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! devik wrote: >>well, there could be other things .... >>i'm currently working on http://f-cpu.seul.org/new/layout2.gif >> >> >btw, what tool do you use for the pcb layout ? > > Eagle light/gratis edition. It is limited to 2 sides and 8x10cm but that's exactly the physical limits i have :-) plus, Eagle has a huge component library and it's very easy to add new components. >>But it's going to change one day. >>I spoke to Actel guyz and they will have a Linux version >>of their dev environment (sim, place, route etc.) by 2004, >>so i'll try to negociate a devkit and other resources. >>Their latest silicons are real heavens for F-CPU cores, >>but i fear that my RAM is really really too small for >>synthesis&place&route ;-) >> >> >:-) what's Actel ? Custom silicon or fpga ? > > FPGA. >devik > > Nicolas Boulay wrote: >Le Dimanche 29 Juin 2003 08:25, devik a écrit : >> :-) what's Actel ? Custom silicon or fpga ? > > small antifuse fpga . well, they still fab some, but the ProAsic+ and the next generations are huge seas of simple gates, they can reach "2.5 million gates". that could be enough to fit a full F-CPU and some I/O.... and the new family is will use .13u fabs. Compared to Altera or Xilinx, there is a big good thing : it's EEPROM cells, not SRAM or fuse !!! This means that it can later be used to make a reconfigurable, upgradable computer boards and powerup-time, contrarily to SRAM-based FPGA (particularly for large ones) is immediate. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Sun Jun 29 17:04:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVl-0002In-00 for ; Mon, 30 Jun 2003 07:47:33 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:47:33 +0200 (CEST) Received: (qmail 12864 invoked by uid 65534); 29 Jun 2003 21:36:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 29 Jun 2003 23:36:09 +0200 Received: by moria.seul.org (Postfix) id 86D9533B55; Sun, 29 Jun 2003 17:36:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D395033B7B; Sun, 29 Jun 2003 17:36:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id AAAB733B55 for ; Sun, 29 Jun 2003 17:36:04 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id RAA00540; Sun, 29 Jun 2003 17:04:50 +0200 Message-ID: <20030629170449.34505@thrai.stud.uni-hannover.de> Date: Sun, 29 Jun 2003 17:04:49 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> <3EFE2CA8.4030500@f-cpu.org> <20030629021329.14767@thrai.stud.uni-hannover.de> <3EFE312A.5050305@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EFE312A.5050305@f-cpu.org>; from Yann Guidon on Sun, Jun 29, 2003 at 02:22:02AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sun, Jun 29, 2003 at 02:22:02AM +0200, Yann Guidon wrote: [...] > >Of course I'll try their software, if the conditions are reasonable. > >If they give me a perpetual full license without asking for my date of > >birth, address, phone number and shoe size, and don't require me to > >download dozens of megabytes of stuff from the net, I'll happily use > >their SW, HW or whatever they have to offer. I forgot one more point: The SW must not be nailed down to a specific IP address. > hmmm i'll check. > but not yet.... it's far from released yet. > but we could be beta-testers ;-P *sigh* -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jun 29 23:44:30 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVm-0002In-01 for ; Mon, 30 Jun 2003 07:47:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:47:34 +0200 (CEST) Received: (qmail 9209 invoked by uid 65534); 29 Jun 2003 21:39:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 29 Jun 2003 23:39:33 +0200 Received: by moria.seul.org (Postfix) id 0D27B33B7E; Sun, 29 Jun 2003 17:39:31 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6590833B7D; Sun, 29 Jun 2003 17:39:30 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id E00C233B66 for ; Sun, 29 Jun 2003 17:39:29 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-141.n.club-internet.fr [213.44.12.141]) by relay-3m.club-internet.fr (Postfix) with ESMTP id A6A13E085 for ; Sun, 29 Jun 2003 23:39:24 +0200 (CEST) Message-ID: <3EFF5DBE.2050709@f-cpu.org> Date: Sun, 29 Jun 2003 23:44:30 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> <3EFE2CA8.4030500@f-cpu.org> <20030629021329.14767@thrai.stud.uni-hannover.de> <3EFE312A.5050305@f-cpu.org> <20030629170449.34505@thrai.stud.uni-hannover.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! Michael Riepe wrote: >On Sun, Jun 29, 2003 at 02:22:02AM +0200, Yann Guidon wrote: >[...] > > >>>Of course I'll try their software, if the conditions are reasonable. >>>If they give me a perpetual full license without asking for my date of >>>birth, address, phone number and shoe size, and don't require me to >>>download dozens of megabytes of stuff from the net, I'll happily use >>>their SW, HW or whatever they have to offer. >>> >>> >I forgot one more point: The SW must not be nailed down to a specific >IP address. > > come on ;-) it's not IP but MAC address. and i bet you're root on your own machine so you certainly can spoof your own MAC, in case you change your NIC. >>hmmm i'll check. >>but not yet.... it's far from released yet. >>but we could be beta-testers ;-P >> >> >*sigh* > > i was kidding :-P YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Mon Jun 30 00:59:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19WrVr-0002In-00 for ; Mon, 30 Jun 2003 07:47:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 30 Jun 2003 07:47:39 +0200 (CEST) Received: (qmail 16313 invoked by uid 65534); 29 Jun 2003 22:59:47 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 30 Jun 2003 00:59:47 +0200 Received: by moria.seul.org (Postfix) id 81AC933B85; Sun, 29 Jun 2003 18:59:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 05BD933B7D; Sun, 29 Jun 2003 18:59:43 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a080.home.uni-hannover.de [130.75.232.80]) by moria.seul.org (Postfix) with ESMTP id 4EC7833B66 for ; Sun, 29 Jun 2003 18:59:42 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id AAA02717; Mon, 30 Jun 2003 00:59:40 +0200 Message-ID: <20030630005939.61909@thrai.stud.uni-hannover.de> Date: Mon, 30 Jun 2003 00:59:39 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] Simulating with GHDL References: <20030628025558.30310@thrai.stud.uni-hannover.de> <3EFD5A44.20705@f-cpu.org> <20030628133208.59799@thrai.stud.uni-hannover.de> <3EFE16F8.7090003@f-cpu.org> <20030629015155.46383@thrai.stud.uni-hannover.de> <3EFE2CA8.4030500@f-cpu.org> <20030629021329.14767@thrai.stud.uni-hannover.de> <3EFE312A.5050305@f-cpu.org> <20030629170449.34505@thrai.stud.uni-hannover.de> <3EFF5DBE.2050709@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3EFF5DBE.2050709@f-cpu.org>; from Yann Guidon on Sun, Jun 29, 2003 at 11:44:30PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Sun, Jun 29, 2003 at 11:44:30PM +0200, Yann Guidon wrote: [...] > >I forgot one more point: The SW must not be nailed down to a specific > >IP address. > > > come on ;-) > > it's not IP but MAC address. Even worse. > and i bet you're root on your own machine so you certainly can > spoof your own MAC, in case you change your NIC. There's a second problem: My machine is too slow, and doesn't have enough RAM. Therefore, I need to be able to install and run the SW on any machine I can get my hands on... BTW: GHDL turned out to be slower than VHDL Simili. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 8311821huxiudong@163.com Tue Jul 15 00:53:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPBj-0002Hq-01 for ; Wed, 23 Jul 2003 21:22:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:22:11 +0200 (CEST) Received: (qmail 21963 invoked by uid 65534); 14 Jul 2003 22:54:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 15 Jul 2003 00:54:22 +0200 Received: by moria.seul.org (Postfix) id 6B83633C66; Mon, 14 Jul 2003 18:54:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8996B33C6A; Mon, 14 Jul 2003 18:54:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from sm181.163.com (unknown [202.108.44.181]) by moria.seul.org (Postfix) with ESMTP id 6FF2333C66 for ; Mon, 14 Jul 2003 18:54:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by sm181.163.com (Postfix) with SMTP id C827A1CC8AD09; Tue, 15 Jul 2003 06:54:16 +0800 (CST) Received: from luck910 (unknown [219.138.195.189]) by 192.168.1.181 (Coremail:163.com) with SMTP id jhAAAJc0Ez8zEcO9.1 for ; Tue, 15 Jul 2003 06:54:16 +0800 (CST) X-Originating-IP: [219.138.195.189] From: ÅóÓÑ <8311821huxiudong@163.com> To: <> Subject: *** GMX Spamverdacht *** [f-cpu] ÅóÓÑÄãºÃ Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312_CHARSET" Date: Tue, 15 Jul 2003 06:53:14 +0800 Message-Id: <20030714225416.C827A1CC8AD09@sm181.163.com> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=12.943; HEADER_8BITS SUBJ_FULL_OF_8BITS TO_MALFORMED TO_NO_USER) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ÅóÓÑÄãÃǺà ÇëÄãÃÇ¿´ÍêÕâ·âÓʼþ£¬Ò²Ðí»á¸øÄãÃǵŤ×÷»òÊÇÉú»î´øÀ´Ðí¶à°ïÖú ±¾ÈË×ÔÖ÷ÓµÓо«Ñ¡ÓʼþµØÖ·5000Íò£¬È«ÊÇÎÒÓá°ÒÚ»¢2003ÓʼþËÑË÷´óʦ¡± »¨ÁË3¸öÔµÄʱ¼ä¾«ÐÄËѼ¯²¢ÕûÀí³öÀ´µÄ£¬¸ÃÓʼþµØÖ·°´Ê¡·Ý¡¢ÇøÓò¡¢ÐÐÒµ¡¢ÄêÁä½øÐÐÏêϸµÄ»®·Ö£¬ ÄúÄÜÊÕµ½ÎÒ·¢¸øÄúµÄÓʼþ£¬¾ÍÊÇ·¢ÓʼþÀ´×öÐû´«µÄ×îºÃÖ¤Ã÷£¡ ÎÞÂÛÄãÊÇ´ó¹«Ë¾ С¹«Ë¾ ¼¯Ìå»ò¸öÈËÄãÃDz»ÓÃÔÙ»¨¾«Á¦ÈËÁ¦²ÆÁ¦À´¸øÄãÃǵÄÆóÒµºÍ ²úÆ·×ö¹ã¸æ×öÐû´«ÁË¡£ÓÃÓʼþÐû´«¿ÉÒÔ¿ìËÙÍƹãÄãÃǵIJúÆ·£¬Ìá¸ßÆóÒµµÄÖªÃû¶È ¼«ÉٵĵÄͶÈë ¾Í¿ÉÒÔ»ñµÃ¾Þ´óµÄ¾­¼ÃЧÒæ ÓÃÓʼþȺ·¢À´½øÐÐÐû´«ÊÇÒ²Êǹã´óÒôÀÖÕ¾µã¡¢¶ÌÐÅÕ¾µã¡¢µçÓ°Õ¾µãºÍ׬ǮվµãµÄÊ×Ñ¡£¡ ÐèÒª´Ë·þÎñµÄÅóÓÑ£¬Çë¸øÎÒµÄQQÉÏÃæ·¢ÏûÏ¢ ÎÒÌìÌìÔÚÏßQQ£º22008022»òÕß·ÃÎÊÎÒµÄÍøÕ¾²é¿´¾ßÌåÇé¿ö http://www.xgdj.com ÎÒ¸½ËÍÓʼþȺ·¢Èí¼þÒ»Ì×£¡ ÄúÿÌì¿ÉÒÔ·¢ËÍ160Íò·âÓʼþ×óÓÒÀ´Ðû´«ÄãµÄÍøÕ¾£¬Ò»¸öÔ²ÅÄÜ·¢Í꣬Ҳ¾ÍÊÇ˵Óû§Ã¿¸öÔ²ÅÊÕµ½ÄãµÄÒ»·âÓʼþ£¬ ²»Ó¦ËãÊÇÀ¬»øÓʼþ£¬ÖµµÃ£¡ÓÃÓʼþÀ´½øÐÐÐû´«Êǹã´óÒôÀÖÕ¾µã¡¢¶ÌÐÅÕ¾µã¡¢µçÓ°Õ¾µãºÍ׬ǮվµãµÄÊ×Ñ¡£¡ ´ÏÃ÷µÄÆóҵѡÔñ´ÏÃ÷µÄ×ö·¨£¬ÓʼþȺ·¢¿ÉÒÔÔÚ×îÒԶ̵Äʱ¼äÄÚ¸øÄã×î´óµÄЧÒæ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From y_ejoor@sify.com Sat Jul 12 23:40:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPAG-0002Hq-01 for ; Wed, 23 Jul 2003 21:20:40 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:20:40 +0200 (CEST) Received: (qmail 3730 invoked by uid 65534); 12 Jul 2003 13:39:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017) with SMTP; 12 Jul 2003 15:39:16 +0200 Received: by moria.seul.org (Postfix) id 4114633B62; Sat, 12 Jul 2003 09:39:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5CE1033C55; Sat, 12 Jul 2003 09:39:12 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from coolre4684.com (unknown [81.199.84.15]) by moria.seul.org (Postfix) with SMTP id 0B10533B62 for ; Sat, 12 Jul 2003 09:39:02 -0400 (EDT) From: "From: Mr. Yomi George Ejoor" To: f-cpu@seul.org Date: Sat, 12 Jul 2003 14:40:54 -0700 Subject: *** GMX Spamverdacht *** [f-cpu] URGENT X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030712133902.0B10533B62@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.434; DATE_IN_FUTURE_06_12 NIGERIAN_SUBJECT1) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: MR=2E Yomi Ejoor=2E C=2ER=2EP=2ELagos Email=3Ay=5Fejoor=40voila=2Efr First =2C I must solicit your strictest confidence in this transaction=2E This is by virtue of its nature as being utterly confidential and TOP SECRET=2E We are top officials of the Federal Government Contract Review Panel who are interested in the importation of goods into our country with fund which are presently trapped in Nigeria=2E In order to commence this business we solicit your assistance to enable us transfer into your account the said trapped funds=2E The source of this fund is as follows=3A During the last Military Regime here in Nigeria=2C the Government officials set up companies and awarded themselves contracts which were grossly over invoiced in the various ministries=2EThe present Civilian Government set up a Contract Review Panel of which we are the constitute members=2E We have identified a lot of inflated contract funds which are presently floating in the Central Bank of Nigeria ready for payment=2E However=2C by virtue of our position as civil servants and members of this panel=2C we cannot acquire this money in our names=2E I have therefore being mandated as a matter of trust by my colleagues of this panel to look for a foreign partner into whose account we will transfer the sum of US$4=2C500=2C000=2E00 =28Four Million Five Hubdred Thousand U=2ES=2E Dollars Only =29 hence we are writing this lette r=2E We have agreed to share the money thus=3A 1=2E 20% for the account owner =28you=29 2=2E 70%for us =28the officials=29 and 3=2E 10% to be used in settling taxation and all local and foreign expenses=2E It is from this 70% that we wish to commence the importation business=2E Please note that this transaction is 100% safe and we hope to commence this transfer latest ten =2814=29 banking days from the date of receipt of the following information to commence via my e- mail box=2E The information required are=3A 1=2E=09Your company Name =2C Address =2C telephone and fax numbers=2E 2=2E=09Your private telephone and fax numbers where I can reach you=2E The above information will enable us write letters of claim and job description respectively=2E This way we will use your company=92s name to re-apply for payment and re-award the contract in your company=92s name=2E We are looking forward to doing this business with you and solicit your confidentiality in this transaction=2E I will bring you into the complete picture of this pending project when I have heard from you=2E We have set aside some funds to bring this transaction to fruition=2C and we are a 100% certain that this transaction will be completed within 14 working days from the date we commence this project in full=2E You can still reply through my alternate email address=3A y=5Fejoor1=40sify=2Ecom Yours faithfully=2C MR=2E YOMI EJOOR=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From master@yume.otegami.com Fri Jul 11 23:06:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP9S-0002Hq-01 for ; Wed, 23 Jul 2003 21:19:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:19:50 +0200 (CEST) Received: (qmail 29930 invoked by uid 65534); 11 Jul 2003 21:07:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 11 Jul 2003 23:07:09 +0200 Received: by moria.seul.org (Postfix) id 7AD7733CB6; Fri, 11 Jul 2003 17:07:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C11D933CB5; Fri, 11 Jul 2003 17:07:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 07C7333B4A for ; Fri, 11 Jul 2003 17:07:05 -0400 (EDT) Received: from yume816.com (fe239018.ot.FreeBit.NE.JP [219.109.239.18]) by belegost.mit.edu (Postfix) with SMTP id 8BCA7121A38 for ; Fri, 11 Jul 2003 17:07:03 -0400 (EDT) From: dm To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8BK=90=A7=90=A1=91O=81I=81I=8D=87=96@=83h=83=89=83b=83O=93=C1=8FW=81I=81I?= Date: Sat, 12 Jul 2003 06:06:58 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="f4508758-e502-45f5-bdc4-219bb2a95e8f" Message-Id: <20030711210703.8BCA7121A38@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --f4508758-e502-45f5-bdc4-219bb2a95e8f Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://210.150.173.81/drug/drug.htm . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @re1@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=8D=87=96= @=83h=83=89=83b=83O=90=EA=96=E5=93X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81@=81@=81@=81@=81@ =81@=81=9A=81=99=81=9A Drug Shop HALLUCINATION =81=9A= =81=99=81=9A=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0 ._/_/_/_/_/ ._/_/_/=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@HALLUCINATION Weekly ._/_/_/=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ =81|Vol.3=81| ._/_/_/_/_/ .=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1 . .=84=AC=84=B2C=84=ABO=84=ABN=84=ABT=84=ABE=84=ABN=84=ABT=84=ABS=84=B0=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AD .=84=AB .=84=AB=81m=82P=81nNEW=8F=A4=95i=82=BC=82=AD=82=BC=82=AD=93=FC=8E=E8=81I=81I = .=84=AB=81m=82Q=81n=8D=C5=8B=AD=81I=81g=82=B1=82=EA=82=AA=89\=82=CCDMT=81c=81= h .=84=AB=81m=82R=81n=8BK=90=A7=90=A1=91O=81I=81I=81u=82=B1=82=EA=82=C1=82=C4= =8D=87=96@=81I=81H=81v .=84=AB=81m=82S=81n=93=C1=95=CA=83L=83=83=83=93=83y=81[=83=93=89=BF=8Ai=8C=C0= =92=E8=94=CC=94=84=8AJ=8En=82=CC=82=A8=92m=82=E7=82=B9 .=84=AB=81m=82T=81n=8D=A1=8FT=82=CC=90V=8F=A4=95i=81u=83=8A=83L=83b=83h=83= A=83=8D=83}=81v=93=C1=8FW=81I .=84=AB=81m=82U=81n=8C=C0=92=E8=8F=EE=95=F1=81i=8A=FA=8A=D4=81F 7/11=81`7/14 = =81j .=84=AB=81m=82V=81n=90=AB=8A=B4=83N=83=8A=81[=83=80=91=E3=97=9D=93X=95=E5=8F= W=82=CC=82=B2=88=C4=93=E0 .=84=AB .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AE . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@ =81=E2=81=E2=81@http://210.150.173.81/drug/drug.htm=81= @=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --f4508758-e502-45f5-bdc4-219bb2a95e8f-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From weitekai@21cn.com Thu Jul 10 15:49:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP5q-0002Hq-00 for ; Wed, 23 Jul 2003 21:16:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:16:06 +0200 (CEST) Received: (qmail 4737 invoked by uid 65534); 8 Jul 2003 13:49:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 08 Jul 2003 15:49:36 +0200 Received: by moria.seul.org (Postfix) id E9EF533B57; Tue, 8 Jul 2003 09:49:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3B35233B59; Tue, 8 Jul 2003 09:49:33 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 4F4D733B57 for ; Tue, 8 Jul 2003 09:49:31 -0400 (EDT) Received: from 21cn1030.com (unknown [218.18.30.139]) by belegost.mit.edu (Postfix) with SMTP id 9D9CD121A36 for ; Tue, 8 Jul 2003 09:49:24 -0400 (EDT) From: =?gb2312?q?=BA=E3=C1=A6=C9=FA=CE=EF=B9=A4=B3=CC=D3=D0=CF=DE=B9=AB=CB=BE_ , ?=@belegost.mit.edu To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?gb2312?q?=BD=A1=BF=B5=B0=E9=C2=C2=BD=BA=C4=D2=CA=C7=C4=FA=C9=FA=BB=EE=B5=C4=BA=C3=B0=E9=C2=C2?= Date: Thu, 10 Jul 2003 21:49:40 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9e2b867c-1cea-49c0-8afe-fa7e58994fec" Message-Id: <20030708134924.9D9CD121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.297; DATE_IN_FUTURE_48_96) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --9e2b867c-1cea-49c0-8afe-fa7e58994fec Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =BD=A1=BF=B5=B0=E9=C2=C2=BD=BA=C4=D2=CA=C7=C4=FA=BD=A1=BF=B5=C9=FA=BB=EE=B5=C4= =BA=C3=B0=E9=C2=C2=A1=A3=D4=B8=C4=FA=B5=C4=C9=FA=BB=EEHealth and Happy=A1=A3 =BD=A1=BF=B5=BE=CD=CA=C7=B2=C6=B8=BB=A3=AC=BF=EC=C0=D6=CA=C7=B8=F9=B1=BE=A1=A3= Health and Happy =CA=C7=BA=E3=C1=A6=C9=FA=CE=EF=B9=A4=B3=CC=D3=D0=CF=DE=B9=AB= =CB=BE=B5=C4=D7=B7=C7=F3=B5=C4=C4=BF=B1=EA=A1=A3=BD=A1=BF=B5=B0=E9=C2=C2=BD=BA= =C4=D2=CA=C7=B1=D6=B9=AB=CB=BE=B5=C4=C8=D9=D3=FE=B2=FA=C6=B7=A1=A3=CB=FD=BE=DF= =D3=D0=C8=E7=CF=C2=B9=A6=D0=A7=A3=BA (1)=B3=A4=C6=DA=B7=FE=D3=C3=BF=C9=D1=D3=BB=BA=CB=A5=C0=CF, =D3=C0=B1=A3= =C7=E0=B4=BA=A1=A3 (2)=CC=D8=D0=A7=BD=E2=D0=D1=BE=C6=D2=A9=B9=A6=C4=DC,=B1=A3=B8=CE=A1=A2=BB= =A4=B8=CE=A1=A3 (3)=B6=D4=CA=A7=C3=DF=D3=D0=D0=A7=A3=AC=CC=E1=B8=DF=CB=AF=C3=DF=D6=CA=C1= =BF,=BB=D6=B8=B4=CC=E5=C1=A6,=CC=E1=B8=DF=B9=A4=D7=F7=D0=A7=C1=A6=A1=A3 (4)=CC=E1=B8=DF=C4=E3=B5=C4=D0=D4=B9=A6=C4=DCNTP=A3=A8=B2=BB=C9=CB=C9=ED= =A3=A9=A1=A3 (5)=C5=E4=BA=CF=C6=E4=CB=FB=D2=A9=CE=EF=BF=C9=D4=F6=BC=D3=C6=E4=D2=A9=D0= =A7=A1=A3 (6)=B6=D4=D1=C7=BD=A1=BF=B5=D7=B4=CC=AC=D3=D0=C3=F7=CF=D4=D0=A7=B9=FB =A1= =A3 =CF=EA=C7=E9=C7=EB=C4=FA=B9=E2=B9=CB=CE=D2=B9=AB=CB=BE=B5=C4=CD=F8=D5=BE = http://www.hh1997.cn =BB=F2=C0=B4=B5=E7=D7=C9=D1=AF=A3=BAbitbeer@tom.com --9e2b867c-1cea-49c0-8afe-fa7e58994fec-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Fri Jul 4 21:22:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP31-0002Hq-00 for ; Wed, 23 Jul 2003 21:13:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:13:11 +0200 (CEST) Received: (qmail 26886 invoked by uid 65534); 4 Jul 2003 19:16:50 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006-rz3) with SMTP; 04 Jul 2003 21:16:50 +0200 Received: by moria.seul.org (Postfix) id 8D3A533C59; Fri, 4 Jul 2003 15:16:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B1E5033C58; Fri, 4 Jul 2003 15:16:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id AA0C833B51 for ; Fri, 4 Jul 2003 15:16:41 -0400 (EDT) Received: from f-cpu.org (lcbv1-3-42.n.club-internet.fr [213.44.21.42]) by relay-5m.club-internet.fr (Postfix) with ESMTP id 5D0FFE07D for ; Fri, 4 Jul 2003 21:16:40 +0200 (CEST) Message-ID: <3F05D3DB.8080905@f-cpu.org> Date: Fri, 04 Jul 2003 21:22:03 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Xilinx: An Adder Tree in Lava Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, food for thoughts .... http://www.xilinx.com/labs/lava/adder_tree/adder_tree.htm YG (yet, there is the portability issue, that comes from the tradeoff for performance) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad81068587@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP4K-0002Hq-00 for ; Wed, 23 Jul 2003 21:14:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:14:32 +0200 (CEST) Received: (qmail 19199 invoked by uid 65534); 7 Jul 2003 05:04:57 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 07 Jul 2003 07:04:57 +0200 Received: by moria.seul.org (Postfix) id BF1BA33B71; Mon, 7 Jul 2003 01:04:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E144233B79; Mon, 7 Jul 2003 01:04:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 35CA733B71 for ; Mon, 7 Jul 2003 01:04:55 -0400 (EDT) Received: from eXcuria.com (unknown [63.251.146.41]) by bettik.munge.net (Postfix) with SMTP id 4E74C4F3BA for ; Mon, 7 Jul 2003 00:05:37 -0500 (CDT) Date: 7/7/2003 12:02:45 AM To: From: SaveOnline Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030707050537.4E74C4F3BA@bettik.munge.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://SaveOnline.eXcuria.com/InkStore/ >> Personal Income Opportunity Available, Ask Us How << Visit us on the web at http://SaveOnline.eXcuria.com/DealerInfo/ This email was sent by a direct marketing service and so we will not receive direct replies to it. If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://SaveOnline.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From master@yume.otegami.com Mon Jul 7 23:49:56 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP4p-0002Hq-00 for ; Wed, 23 Jul 2003 21:15:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:15:03 +0200 (CEST) Received: (qmail 27614 invoked by uid 65534); 7 Jul 2003 21:50:04 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008) with SMTP; 07 Jul 2003 23:50:04 +0200 Received: by moria.seul.org (Postfix) id 94F3D33B51; Mon, 7 Jul 2003 17:50:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E3F6133B56; Mon, 7 Jul 2003 17:49:59 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 5D8D333B51 for ; Mon, 7 Jul 2003 17:49:59 -0400 (EDT) Received: from yume856.com (fb173168.ot.FreeBit.NE.JP [61.203.173.168]) by belegost.mit.edu (Postfix) with SMTP id 7B31E121A36 for ; Mon, 7 Jul 2003 17:49:56 -0400 (EDT) From: dm To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=89=C4=8D=D5=82=E8=81I=81I=91=E5=83Z=81[=83=8B=81I=81I=95K=8C=A9=81I=81I?= Date: Tue, 08 Jul 2003 06:49:56 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="f7a5b237-c464-4ed5-81c9-6f44cfb0a1ab" Message-Id: <20030707214956.7B31E121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --f7a5b237-c464-4ed5-81c9-6f44cfb0a1ab Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://net-channel.info/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @re1@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=81=9A2=93=FA=8A=D4=82=CC=82=DD=81=9A=83T=83}=81= [=8D=D5=82=E8=81I=81I=91=E5=83Z=81[=83=8B=81I=81I=95K=8C=A9=81I=81I=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=93=C1=95=CA=8C=83=88=C0=89= =BF=8Ai=82=C9=82=C4=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=94=84=82=E8=90=D8=82=EA=8E= =9F=91=E6=8FI=97=B9=81I=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q . .=8D=A1=93=FA=82=A9=82=E7=82=B1=82=EA=82=C5=96=A2=92m=82=CC=89=F5=8A=B4=81= E=90=A2=8AE=82=D6=81E=81E=81E .=97~=82=B5=82=A9=82=C1=82=BD=82=B1=82=F1=82=C8=8F=A4=95i=81I=81I .=94=CC=94=84=90=94=97=CA=8C=C0=92=E8=93=C1=95=CA=8F=A4=95i=81I=81I .=82=C6=82=C9=82=A9=82=AD=8C=A9=82=C9=97=88=82=C4=82=AD=82=BE=82=B3=82=A2=81= =F4=81@=8C=A9=82=C4=91=B9=82=CD=82=C8=82=B5=81I=81I . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81= =E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --f7a5b237-c464-4ed5-81c9-6f44cfb0a1ab-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From changdonginfo@hanmail.net Wed Jul 9 05:16:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fP6a-0002Hq-01 for ; Wed, 23 Jul 2003 21:16:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:16:52 +0200 (CEST) Received: (qmail 11252 invoked by uid 65534); 9 Jul 2003 03:15:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 09 Jul 2003 05:15:58 +0200 Received: by moria.seul.org (Postfix) id 361D933C8D; Tue, 8 Jul 2003 23:15:56 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 65A6733C91; Tue, 8 Jul 2003 23:15:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id CF23833C8D for ; Tue, 8 Jul 2003 23:15:54 -0400 (EDT) Received: from hanmail.net (unknown [220.93.68.173]) by bettik.munge.net (Postfix) with SMTP id 35CE14F3E9 for ; Tue, 8 Jul 2003 22:16:34 -0500 (CDT) From: ⵿Á¤º¸ To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] <±¤°í>½Å¿ëºÒ·®ÀÚÁ¤º¸.½Å¿ë¾çÈ£ÀÚÁ¤º¸@ Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030709031634.35CE14F3E9@bettik.munge.net> Date: Tue, 8 Jul 2003 22:16:34 -0500 (CDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=13.2; HEADER_8BITS KOREAN_UCE_SUBJECT SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å ÀÛ¼ºÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¾ÕÀ¸·Î ¸ÞÀϼö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁֽʽÿÀ.

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Tue Jul 22 11:58:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPJV-0002Hq-00 for ; Wed, 23 Jul 2003 21:30:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:30:13 +0200 (CEST) Received: (qmail 15382 invoked by uid 65534); 22 Jul 2003 09:58:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001) with SMTP; 22 Jul 2003 11:58:52 +0200 Received: by moria.seul.org (Postfix) id 1F38E33B61; Tue, 22 Jul 2003 05:58:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B5F2633B65; Tue, 22 Jul 2003 05:58:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id C93BE33B61 for ; Tue, 22 Jul 2003 05:58:48 -0400 (EDT) Received: from yume2442.com (fe113070.fl.FreeBit.NE.JP [219.112.113.70]) by belegost.mit.edu (Postfix) with SMTP id 8452D121A37 for ; Tue, 22 Jul 2003 05:58:47 -0400 (EDT) From: dmms To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8A=FA=8A=D4=8C=C0=92=E8=81I=81I=92=E1=8B=E0=97=98=97Z=8E=91=81I=81I?= Date: Tue, 22 Jul 2003 18:58:39 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="79e6586f-b090-4828-b07c-e9df15befe73" Message-Id: <20030722095847.8452D121A37@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --79e6586f-b090-4828-b07c-e9df15befe73 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2>http://dmmster.com =93=8C=8B=9E=93s=90=A2=93c=92J=8B= =E6=8B=EE=91=F21-3-10=81@090-8159-3461 <=8E=96=8B=C6=8E=D2>http://www.jrf-co.com/pc/index1.htm =83=81=81[=83=8B=82=CC=94z=90M=92=E2=8E~=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5= =81@dm_dmmaster@yume.otegami.com . =81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=8D= L=8D=90=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81= =99 =81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=97=88=93X=95s=97v=82=CCWEB=83= L=83=83=83b=83V=83=93=83O . 1=96=9C=89~=81`500=96=9C=89~=96=98 =8B=BA=88=D0=82=CC=94N=97=A6=82T=81D=82T=81=93=81`=8C_=96=F1=89=C2=94\=81I=81= I . =91S=8D=91=89=BD=8F=88=82=C5=82=E0=82=A8=93d=98b=88=EA=96{=82=C5=97Z=8E=91=89= =C2=94\=81I=81I =83p=83\=83R=83=93=82=A9=82=E7=82=CC=8C=E4=90\=82=B5=8D=9E=82=DD=82=E0=89=C2= =94\=81I=81I =8B}=82=C8=8Fo=94=EF=81A=91=BC=8E=D0=82=A8=8Ex=95=A5=82=A2=82=C9=81I=81I =82=BB=82=CC=91=BC=81A=82=A8=8Ex=95=A5=82=A2=82=CC=82=A8=82=DC=82=C6=82=DF=90= =EA=97p=82=CC=83=8F=83C=83h=83=8D=81[=83=93=82=C8=82=C7=82=E0=97p=88=D3=82=B5= =82=C4=82=A2=82=DC=82=B7=81B=81@=81@=81@ =82=B1=82=CC=8B@=89=EF=82=F0=8Eg=82=A2=90=A5=94=F1=8C=E4=90\=82=B5=8D=9E=82=DD= =89=BA=82=B3=82=A2=81B . =95=BE=8E=D0URL http://www.jrf-co.com/pc/index1.htm . =81=A1=83=8F=83C=83h=83=8D=81[=83=93=82=C9=8A=D6=82=B5=82=C4 =8C=BB=8D=DD=81A=8F=C1=94=EF=8E=D2=82=CC=95=FB=81X=82=CC=8E=D8=93=FC=82=EA=8F= =F3=8B=B5=82=CD=90=94=8E=D0=82=A9=82=E7=82=CC=8E=D8=93=FC=82=EA=82=AA=82=D9=82= =C6=82=F1=82=C7=82=CC=82=E6=82=A4=82=C5=82=B7=81B =92=86=82=C9=82=CD=97=98=91=A7=82=CC=82=DD=82=CC=8Ex=95=A5=82=A2=82=C5=96=88= =8C=8E=8FI=82=ED=82=C1=82=C4=82=A2=82=E9=95=FB=81X=82=AA=91=BD=82=AD=8C=A9=82= =E7=82=EA=82=DC=82=B7=81B =82=BB=82=B1=82=C5=95=BE=8E=D0=82=AA=92=F1=88=C4=82=B7=82=E9=91=CE=8D=F4=82=CC= =88=EA=8A=C2=82=C6=82=B5=82=C4=8F=A4=95i=96=BC=83=8F=83C=83h=83=8D=81[=83=93= =82=F0=8AJ=8En=92v=82=B5=82=DC=82=B5=82=BD=81B . =81=A6=92S=95=DB=81E=95=DB=8F=D8=90l/=8C=B4=91=A5=82=C6=82=B5=82=C4=95s=97v =81=A6=94N=8A=D4=97=98=97=A6/=94N=97=985.5=81=93=81` =81=A6=92x=89=84=97=98=97=A6/=94N=97=A623.2=81=93=81`29.2=81=93=88=C8=89=BA = (=94N=97=A6) =81=A6=82=A8=8Ex=95=A5=82=A2=95=FB=8E=AE/=8C=B3=97=98=8B=CF=93=99=95=FB=8E=AE = =81=A6=82=B2=8C_=96=F1=8A=FA=8A=D4/1=89=F1=81`120=89=F1 =81=A6=93o=98^=94=D4=8D=86=81F=93=8C=8B=9E=93s=93o=98^=89=C1=96=BF=93X =93=8C=8B=9E=93s=92m=8E=96 (1)=91=E625703=8D=86 TEL=81D0120=81|15=81|9392 . =81=A6=95=BE=8E=D0=82=CD=83=84=83~=8B=E0=97Z=82=C5=82=CD=82=B2=82=B4=82=A2=82= =DC=82=B9=82=F1=81I=81I =82O=82X=82O=8B=E0=97Z=81A=8F=D0=89=EE=89=AE=81A=8D=82=8B=E0=97=98=82=CC=96= \=97=CD=8B=E0=97Z=82=C8=82=C7=82=C9=82=B2=92=8D=88=D3=89=BA=82=B3=82=A2=81I=81= I . . --79e6586f-b090-4828-b07c-e9df15befe73-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From niceguy@hotmal.com Mon Jul 21 04:46:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPHb-0002Hq-00 for ; Wed, 23 Jul 2003 21:28:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:28:15 +0200 (CEST) Received: (qmail 28695 invoked by uid 65534); 21 Jul 2003 02:45:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 21 Jul 2003 04:45:41 +0200 Received: by moria.seul.org (Postfix) id CDA9533C3C; Sun, 20 Jul 2003 22:45:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8EC1433C62; Sun, 20 Jul 2003 22:45:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from rs26s12.datacenter.cha.cantv.net (rs26s12.datacenter.cha.cantv.net [200.44.33.31]) by moria.seul.org (Postfix) with ESMTP id 19EE833C3C for ; Sun, 20 Jul 2003 22:45:08 -0400 (EDT) Received: from plpm2 (dC854919E.dslam-01-4-9-01-1-01.cum.dsl.cantv.net [200.84.145.158]) by rs26s12.datacenter.cha.cantv.net (8.12.9/8.12.6/3.0) with SMTP id h6L2j6HA015866 for ; Sun, 20 Jul 2003 22:45:07 -0400 thread-index: AcNPMkrGu3aP/PPpRdOKuG+9/97Bqg== Thread-Topic: Invitation From: To: Subject: [f-cpu] Invitation Date: Sun, 20 Jul 2003 22:46:31 -0400 Message-ID: <5f0401c34f32$4ac9bcc0$9e9154c8@plpm2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5F05_01C34F10.C3B81CC0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: high X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format. ------=_NextPart_000_5F05_01C34F10.C3B81CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I apologize for bothering you, I just want to invite you to visit a great Real Free Dating Match making site. Thanks It is for sale at Negotiable price ---- join now it is FREE ------=_NextPart_000_5F05_01C34F10.C3B81CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I apologize for bothering you, I just want to invite you to visit a great Real Free Dating Match making site. Thanks
It is for sale at Negotiable price ---- join now it is FREE ------=_NextPart_000_5F05_01C34F10.C3B81CC0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 20 19:02:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPHL-0002Hq-00 for ; Wed, 23 Jul 2003 21:27:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:27:59 +0200 (CEST) Received: (qmail 16891 invoked by uid 65534); 20 Jul 2003 16:56:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 20 Jul 2003 18:56:46 +0200 Received: by moria.seul.org (Postfix) id E15AF33B62; Sun, 20 Jul 2003 12:56:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 34FB033BDE; Sun, 20 Jul 2003 12:56:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id ED18133B62 for ; Sun, 20 Jul 2003 12:56:34 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-44.n.club-internet.fr [213.44.18.44]) by relay-3m.club-internet.fr (Postfix) with ESMTP id 9D478E043 for ; Sun, 20 Jul 2003 18:56:33 +0200 (CEST) Message-ID: <3F1ACB29.9070604@f-cpu.org> Date: Sun, 20 Jul 2003 19:02:33 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "There is another system" References: <3F1AC261.20906@f-cpu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Yann Guidon wrote: > once in a while, i type "F-CPU" in google to see how things go ... > and this time, i found http://www.elsaco.cz/produkty/hw2/fcpu.htm while i'm at it : http://www.ibraconcontroles.com.br/fcpu.htm http://www.ad.siemens.de/simatic/controller/html_76/produkte/produkte_fehler_contr_et200s.htm http://www.lysator.liu.se/history/garb/txt/87-2-fcpu.txt (most funny) http://www.weblearn.hs-bremen.de/risse/RST/assign02/fcpu/F-CPU.html (german ! \o/) and http://www.f-cpu.de seems to be down, Sven has probably not paid for the domain name as every precedent year. i seriously plan on re-organising the web sites in august. Then, if i have time, updating the manual (or write other documents), cleanup the source code base and write a F-CPU instruction set simulator. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Jul 20 18:25:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPHK-0002Hq-00 for ; Wed, 23 Jul 2003 21:27:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:27:58 +0200 (CEST) Received: (qmail 21164 invoked by uid 65534); 20 Jul 2003 16:19:15 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx023-rz3) with SMTP; 20 Jul 2003 18:19:15 +0200 Received: by moria.seul.org (Postfix) id 7917D33C21; Sun, 20 Jul 2003 12:19:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8599033BDE; Sun, 20 Jul 2003 12:19:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by moria.seul.org (Postfix) with ESMTP id 859FD33B62 for ; Sun, 20 Jul 2003 12:19:09 -0400 (EDT) Received: from f-cpu.org (lcbv5-1-44.n.club-internet.fr [213.44.18.44]) by relay-3m.club-internet.fr (Postfix) with ESMTP id 4CDADE0B7 for ; Sun, 20 Jul 2003 18:19:06 +0200 (CEST) Message-ID: <3F1AC261.20906@f-cpu.org> Date: Sun, 20 Jul 2003 18:25:05 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] "There is another system" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: once in a while, i type "F-CPU" in google to see how things go ... and this time, i found http://www.elsaco.cz/produkty/hw2/fcpu.htm any remark ? YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kalu_francis69ng@indiatimes.com Sat Jul 19 18:27:54 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPG5-0002Hq-01 for ; Wed, 23 Jul 2003 21:26:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:26:41 +0200 (CEST) Received: (qmail 18511 invoked by uid 65534); 19 Jul 2003 16:29:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 19 Jul 2003 18:29:02 +0200 Received: by moria.seul.org (Postfix) id 9F6D333B89; Sat, 19 Jul 2003 12:28:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A17B533B8D; Sat, 19 Jul 2003 12:28:57 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from coolre4945.com (unknown [81.199.85.54]) by moria.seul.org (Postfix) with SMTP id 9E8B433B89 for ; Sat, 19 Jul 2003 12:28:18 -0400 (EDT) From: "Dr. Kalu Francis." To: f-cpu@seul.org Date: Sat, 19 Jul 2003 09:27:54 -0700 Subject: [f-cpu] Hello. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===_SecAtt_000_1foqrgxdsvxpwb" Message-Id: <20030719162818.9E8B433B89@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --===_SecAtt_000_1foqrgxdsvxpwb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =28DR=29 KALU FRANCIS=2E ACCOUNT=2FAUDIT DEPARTMENT=2E NIGERIA PORT AUTHORITY-LAGOS=2E Tel=3A234-8033280983 E-mail=3Aportauth=5Fdabo2002=40engineer=2Ecom Dear Sir =2C RE=3A URGENT & CONFIDENTIAL BUSINESS PROPOSAL=2E Although this proposal might come to you as a surprise=2C since it is from someone you do not know or have seen before=2C but based on recommendations=2C l gathered from a very reliable source here in Nigeria=2E I am the director=2C fund co-ordinator of the Finance Contract Department of Nigerian Ports Authority The crux of this letter is that the finance=2Fcontract department of the NPA deliberatly over-inflated the contract values of various contract awarded=2E In the course of disbursement my office was able to track down the sum of US$23=2E5M=28Twenty ThreeMillion=2C Five Hundred Thousand U=2ES dollars=29 as the over invoiced sum=2E This money is now floating in the NPA domicilliary account with the Central Bank of Nigeria =28CBN=29=2E I and my colleagues now want to quickly transfer this fund to a safe nominated foreign account for possible investment abroad=2E We are not allowed as a matter of government policy to operate any foreign account because of our status as civil=2Fpublic servants=2E Hence the need to solicit for your full banking details=2C to enable us transfer this money into your account=2E Upon your acceptance of this proposal=2C we have also agreed on a sharing ratio=3A- 1=29 30%for you as the account owner 2=29 60% for l and my colleagues 3=29 10% will be set aside to defray all incidental expenses both locally and internationally during the course of this transaction=2E Furthermore=2C we shall be coming over to your country when the money is finally in your account and we shall be relying on your advise as regards to investment of our share =2E Be informed that=2C this business is genuine and 100% safe considering the high powered government officials involved=2E send by fax the following information=3A- 1=29 YOUR COMPANY NAME AND ADDRESS=2C BANK NAME=2C ADDRESS AND ACCOUNT NUMBER 2=29 YOUR TELEPHONE AND FAX NUMBER FOR EFFECTIVE COMMUNICATION=2E This is to effect the Swift Transfer of this fund into your account in less than Seven =28 7=29 working days=2E Contact me strictly on Tel number 234-803-3280983=2E Expecting your call immediately while looking forward to a healthy business relationship with you=2E Sincerely=2C =28DR=29 KALU FRANCIS=2E --===_SecAtt_000_1foqrgxdsvxpwb Content-Type: application/octet-stream; name="blaster.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="blaster.txt" LWhlbHBAbmV0bGFiLmNzLnJwaS5lZHUNCi5hbmRlcnNvbkBvcHRpbWF5LmNvbQ0KLmJhY3F1ZUAz d2ViLm5ldA0KLmJhcmJlckBqdXN0aWNlLnRhcy5nb3YuYXUNCi5icm93bkBidC1zeXMuYnQuY28u dWsNCi5jYW1wYmVsbDFAamN1LmVkdS5hdQ0KLmNyb3NzQHNjaS5tb25hc2guZWR1LmF1DQouZGVj YXJpZUBzeW1wYXRpY28uY2ENCi5kdW5waHlAc3ByYWNobGl0LnVuaS1yZWdlbnNidXJnLmRlDQou aGFydGxleUB2MjFtYWlsLmNvLnVrDQouaGVuZGVyc29uQG11c2V1bS53YS5nb3YuYXUNCi5oaWNr c0BqY3UuZWR1LmF1DQouaHVudGVyQGZtZC51d28uY2ENCi5raXJrQGVkLmFjLnVrDQoua2lya3Bh dHJpY2tAbm9ydGh1bWJyaWEuYWMudWsNCi5raXJ0b25AZmlsY3MuY29tDQoubGVhc2tAcHJvZGln eS5uZXQNCi5tLmtheUB0YWxrMjEuY29tDQoubWF0dGhld0BtZXJjZXIuY29tDQoubWVsaWFAYmln Zm9vdC5jb20NCi5uLmJyb3duQGJ0LmNvbQ0KLm5pY2hvbHNvbjJAYnRvcGVud29ybGQuY29tDQou bmljaG9sc29uQGFiZXR0ZXJ3b3JsZC5jby51aw0KLnBhdHRlcnNvbkBkZXQubnN3LmVkdS5hdQ0K LnBlYXJtYW5AZGFyLmNzaXJvDQoucHJlc3RvbkBzdXJyZXljYy5nb3YudWsNCi5yb2JiaW5zQHh0 cmEuY28ubnoNCi5yb2RnZXJzQHFlaC5veC5hYy51aw0KLnNlbHdheUB2aXJnaW4ubmV0DQouc3Bl ZGVuQHBhcmxpYW1lbnQuZ292dC5ueg0KLnRyb3VzZGFsZUBlZC5hYy51aw0KLnZldHRlcmxlaW5A bnRsLmNvbQ0KLndhbGtlckB5M2tncm91cC5jb20NCi53aWxzb25AbmF0aW9uc2JhbmsuY28NCi53 b29kQGVkLmFjLnVrDQoud29ycmFsbEBidGludGVybmV0LmNvbQ0KMDFqdWF3cTJ1dXhlQHlhaG9v LmNhDQoxMTM2NzMuMzIyMUBjb21wdXNlcnZlLmNvbQ0KMTIxMjA1QGJ1Z3MuZGViaWFuLm9yZw0K MTQyMDE5QHBibS5jb20NCjFAMi5jb20uY29zLmFnaWxlbnQuY29tDQoxQGZvcnVtcy5tYWNyb21l ZGlhLmNvbQ0KMUBmcmVlYnNkLmNzaWUubmN0dS5lZHUudHcNCjFAaG9vZC51aXRzLmluZGlhbmEu ZWR1DQoxQGhvc3QudGFsay5ydQ0KMUBpZC0xNzMwNzIubmV3cy51bmktYmVybGluLmRlDQoxQGlk LTE5OTE0Ny5uZXdzLmRmbmNpcy5kZQ0KMUBpZC00NDUzMy5uZXdzLmRmbmNpcy5kZQ0KMUBrbm9z c29zLmJ0aW50ZXJuZXQuY29tDQoxQG14Z2F0ZS5tZW1leC5jby51aw0KMUBuZXdzNi5zdnIucG9s LmNvLnVrDQoxQG5ld3M4LnN2ci5wb2wuY28udWsNCjFAbmV3c2czLnN2ci5wb2wuY28udWsNCjFA cGFyaXMuYnRpbnRlcm5ldC5jb20NCjFAcGVnYXN1cy5jc3guY2FtLmFjLnVrDQoxQHBoZWlkaXBw aWRlcy5heGlvbi5idC5jby51aw0KMUBzcGFydGEuYnRpbnRlcm5ldC5jb20NCjFAdmVsb3guY3Jp dHRlci5uZXQNCjFmNDljZTE4QGVhcnRobGluay5uZXQNCjIwMDIwNzI0MjMxNC5nNm9uZW1iNTY3 NDdAZ3JvLmRkLm9yZw0KMmhANXJyLm1xDQoydGhkb2NAaG9tZS5jb20NCjM4YmFmYmM1LmNjYTFk ZmY2QGFzZS5jb20uYXUNCjM4ZTljNTgyLmRkYzI5OTg4QGxib3JvLmFjLnVrDQozOGY1ZjNiNEBu ZXdzLnNjcmVhbWluZy5uZXQNCjM5MzJlNDc0LjI1OWE3MGJiQGJpZ2Zvb3QuY29tDQozOWJjODdh Zi43NmIzNGE4YkB3YW5hZG9vLmZyDQozQHVyYW5pdW0uYnRpbnRlcm5ldC5jb20NCjNhMzZlZTEz LjE3OWJkNWI0QGZyZW1hbnRsZXBvcnQuY29tLmF1DQozYWFmZjIxOC44NGZhNDc5YkBtYWlsLnVz YXNrLmNhDQozYWluZm9Ad3R2MjEuY29tDQozYXBhM2FAc2VjdXJpdHkubm5vdi5ydQ0KM2IwYWI3 YzYuNzE1NGE3YjRAZXJvbHMuY29tDQozYjFlY2E1OUBtYWlsYW5kbmV3cy5jb20NCjNiOGVkZDM0 LmM0MDkzZTk1QHBlcm5ldXMuY29tDQozZDM0NWFmYi4xNDczODA1MTFAbmV3czEuZWlyY29tLm5l dA0KM2QzZGEyYWYuOGY1QGRtY29tLm5ldA0KM2VmMzI0YTEuZWEzNGUyNmNAdGhpc2lzZmFrZS5k aw0KM2YwMzU2MWYuNzA2MDQwOUBicm9hZHBhcmsubm8NCjQyMS4zOTI2QG5ucnAxLm96ZW1haWwu Y29tLmF1DQo0YTdmNWY0MWMxamVyZW15QG9tYmEuZGVtb24uY28udWsNCjRhN2Y5MGM1MDl2aW5j ZWhAc29mdHJvY2suY28udWsNCjRlaWgzZWRhQHlhaG9vLmNvbQ0KNS4xOTY1ODFAbmV3czYtd2lu LnNlcnZlci5udGx3b3JsZC5jb20NCjZxdHFyaGFxcGxmNmV3cHRAY3dhc3BlLmRlbW9uLmNvLnVr DQo2enVwbmdhcnBodjVlYXpuQGxpbmVvbmUubmV0DQphLWluZm9zLWNhQGFpbmZvcy5jYQ0KYS1p bmZvcy1kQGFpbmZvcy5jYQ0KYS1pbmZvcy1kQGxpc3RzLnRhby5jYQ0KYS1pbmZvcy1lbkBhaW5m b3MuY2ENCmEtaW5mb3Mtb3JnQGFpbmZvcy5jYQ0KYS1pbmZvcy1vcmdAbGlzdHMudGFvLmNhDQph LWluZm9zLXdvcmtAdGFvLmNhDQphLmcuc2NvdHRAc3R1ZC5tYW4uYWMudWsNCmEubS5jb25yb3lA YXJnb25ldC5jby51aw0KYTEwMTI4MGFAcGh4LmdibA0KYTUwMTI4MGFAcGh4LmdibA0KYWF2ZGlA YWF2ZGkub3JnDQphYjc1OEB2aXJnaW4udmlwLnZpDQphYnNlc3NlZEB3ZWJ0di5uZXQNCmFidXNl QGF0dGJpLmNvbQ0KYWJ1c2VAZW5lcmdpcy5jb20NCmFidXNlQG50bHdvcmxkLmNvbQ0KYWJ1c2VA cnIuY29tDQphY2NvdW50c0ByaWJib24ubmV0LmF1DQphY3Rpb24udGtkQGJpZ3BvbmQuY29tLmF1 DQphZGVuYmVyZ0Bob3RtYWlsLmNoDQphZHJpYW5ub0BvcGVubGluay5jb20uYnINCmFncGx1c0B3 YW5hZG9vLmZyDQphZ3RlcmJlcmdAZ3NjLm5yY2FuLmdjLmNhDQphaWRhbkBrdWJsYWkuY29tDQph aWRzb2FzaXMxQGFvbC5jb20NCmFsYW5AbHhvcmd1ay51a3V1Lm9yZy51aw0KYWxiYWlyYWtAZm9y ZWlnbmxhbmd1YWdlLmNvbS5hdQ0KYWxleC5uaWNob2xzb25AZ29wcmludC5xbGQuZ292LmF1DQph bGV4ZnVuZ0Boa2J1LmVkdS5oaw0KYWxpc2lvcy1zYWlsaW5nQHRlcnJhLmVzDQphbGtpbmdAb3pl bWFpbC5jb20uYXUNCmFsbGJlcnlAZWNlLmNtdS5lZHUNCmFsbG1hYzlAYW9sLmNvbQ0KYWxsc2Vh c29uc3JlYWx0eUBuYi5haWJuLmNvbQ0KYWxveUBpbmFtZS5jb20NCmFtLmNvbnJveUBhcmdvbmV0 LmNvLnVrDQphbWVyaWNhbnNwaWtlQGhvdG1haWwuY29tDQphbWlnYWhvbGljQHlhaG9vLmNvbQ0K YW1pdEBzcGltYWdld29ya3MuY29tDQphbW5lc3R5QGFtbmVzdHkub2lsLmNhDQphbmFyY2hpc3Rf ZmVkZXJhdGlvbkB5YWhvby5jby51aw0KYW5kb25uYUBvendlYi5hdW56LmNvbQ0KYW5kcmV3LnNl bGxvbkBsaW5lb25lLm5ldA0KYW5kcmV3YWxleEBob3RtYWlsLmNvbQ0KYW5nZWxhX2NhdmFuYWdo QHlhaG9vLmNvbQ0KYW5pbWFsdWx0cmFzb3VuZEBiaWdwb25kLmNvbQ0KYW5pc2hpQGdvdC5uZXQN CmFuamVuQGlhZnJpY2EuY29tDQphbm5lLmtpbmdAZWQuYWMudWsNCmFubm91bmNlQG1pbmlzdGVy cy5nb3Z0Lm56DQphbnRob255QGZvcmQyMjIuZnJlZXNlcnZlLmNvLnVrDQphbnRpd2FyLW1lZGlh QHlhaG9vZ3JvdXBzLmNvbQ0KYXF1YXRlY2lAZ2lsLmNvbS5hdQ0KYXJhY2hlZG9nQHpvb20uY28u dWsNCmFybmUuYmF1ZXJAc2QucWxkLmdvdi5hdQ0KYXJzY2xpc3RAY2Mucm9jaGVzdGVyLmVkdQ0K YXJ0ZGVjb0B3YW5hZG9vLm5sDQphcnRodXIudGF0bmFsbEB2dS5lZHUuYXUNCmFydGlzdHByZXNA YW9sLmNvbQ0KYXNhc0Bhc2EuY3hjeA0KYXNmQGN0ZGlvY2VzZS5vcmcuemENCmFzcEBjaGlsZGNh cmUuY29tLmF1DQphc3NhckBzaWNzLnNlDQphdGVuZXUyMDAwQHlhaG9vLmNvbQ0KYXR1bm5AZ2ls LmNvbS5hdQ0KYXV0b2JheEBraW5nc2xleS5jby56YQ0KYXZoY3ljbGVAaWFmcmljYS5jb20NCmF2 am9uZXNAY2l4LmNvLnVrDQphdmx1Z0Bkb21haW4uaGlkZGVuDQpheGRrdHRhdmlAZWFydGhsaW5r Lm5ldA0KYXlhejAwMDdAaG90bWFpbC5jb20NCmIuZC5ib3BAc3VzY29tLm5ldA0KYi51c2hlckBl ZS5sYXRyb2JlLmVkdS5hdQ0KYmFiYm90dHNAZ2lsLmNvbS5hdQ0KYmFnaGVlcmE2ODJAeWFob28u Y29tDQpiYXJkQGRtY29tLm5ldA0KYmFycnlzaGF3QGdsZW5lYWdsZXM4Ny5mcmVlc2VydmUuY28u dWsNCmJhc2lsZGFvdXN0QHNoYXcuY2ENCmJhc2lsbWFjQG5iY25ldC5jb20uYXUNCmJkLmJvcEBz dXNjb20ubmV0DQpiZWxtb250dmlkZW9AYW9sLmNvbQ0KYmVuQGJhcmNvZGUuY28uaWwNCmJlbkBo YXlzY2FwbGFuLm9yZw0KYmhvZmZtYW5AZm1seW5ldC5vcmcNCmJodW50QHNkcy5xbGQuZ292LmF1 DQpiaWdhbC5ob21lQHZpcmdpbi5uZXQNCmJpbGxAaGFyZHdpY2szNi5mcmVlc2VydmUuY28udWsN CmJpbGxAbGVkZWZmZWN0cy5jb20NCmJpbGxkQHJtaXQuZWR1LmF1DQpianNAZ2ZkbC5nb3YNCmJs QGNrZG9nLmNvLnVrDQpibWNrbmlnaEBiZWxsc291dGgubmV0DQpib2IuaG9mZm1hbkBmbWx5bmV0 Lm9yZw0KYm9iLm4ubHV0aGVyYm9ycm93QHRyYW5zcG9ydC5xbGQuZ292LmF1DQpib21iZWtAc2lv bC5uZXQNCmJvbmhhbS1jYXJ0ZXJAZ3NjLm5yY2FuLmdjLmNhDQpib3JlZG9tQHRhby5jYQ0KYm9y aW5nQGFuZHJldy5jbXUuZWR1DQpib3J0QGhvdG1haWwuY29tDQpib3M5NkBvemVtYWlsLmNvbS5h dQ0KYm9zbWFucEBydHQuY28uemENCmJwc3NpYXRmQHlhaG9vLmNvbQ0KYnJhZC5jYXJ0ZXJAc2Qu cWxkLmdvdi5hdQ0KYnJhZF9jbGFya0BvbnRsYS5vbGEub3JnDQpicmFkZW5AaXNpLmVkdQ0KYnJh bWFAd2EuZnJlZWkubmV0DQpicmlhbi5kb3lsZUB4YWN0YS5jby5ueg0KYnJpYW4uai5ob2xsaW5z QHRyYW5zcG9ydC5xbGQuZ292LmF1DQpicmlhbkBvbWNzLmNvbS5hdQ0KYnJpYW5Ab25lYnJpaHUu ZnNuZXQuY28udWsNCmJyaWFuX3NhbXdheXNAYmlybWluZ2hhbS5nb3YudWsNCmJyaWN1bGxAbmJu ZXQubmIuY2ENCmJyaXNiYW5lX3NvZnRiYWxsQHRlc2x0cmEuY29tDQpicml0cnVnYnlAYW9sLmNv bQ0KYnJtY2xlbm5hbkBpbmZvc2NpZW5jZS5vdGFnby5hYy5ueg0KYnJvbi1vbHkyQGJyb256ZS5j b3JwLnNnaS5jb20NCmJydWNlLmdhcmJ1dHRAc2QucWxkLmdvdi5hdQ0KYnJ1Y2UuZ3JhZHlAcWZs ZWV0LnFsZC5nb3YuYXUNCmJydW5hcEBicm93bi5lZHUNCmJyeWFudHNwaGFybWFjeUBiaWdwb25k LmNvbS5hdQ0KYnNrYmFsbDIxOUBhdHRiaS5jb20NCmJ1Y2NpYW50aUB1bmlmaS5pdA0KYnVya2Vn cm91cEBiaWdwb25kLmNvbQ0KYnVybGVpZ2h2aWRlb0Bhb2wuY29tDQpidXJyZGFuQGN3Y29tLm5l dA0KYnVzdXR0aW5AaDE1MC5hb25lLm5ldC5hdQ0KYy5iZWNrQHZldC51bmltZWxiLmVkdS5hdQ0K Y2Fjb2RhZW1vbkBwcm9kaWd5Lm5ldA0KY2FtZXJvbkB0bWlleHBvcy5jb20NCmNhcHRhaW5oQHRl Y2hub21hZ2UuY29tLmF1DQpjYXIubWFpbnRlbmFuY2VAZWxlY3Ryb2Jvb2tzLmNvLnVrDQpjYXRA YmNtLnRtYy5lZHUNCmNhemFycmFAb3plbWFpbC5jb20uYXUNCmNidXJrZUBtaXRyZS5vcmcNCmNj OWU0ZDFmQG5ld3MuZGlhbC5waXBleC5jb20NCmNjbGVlQG5tZ21lbnRvbS5kZW1vbi5jby51aw0K Y2NzY29sb3VyQHJpdmVyc2FuZHMuY29tLmF1DQpjZGc3QGNkYy5nb3YNCmNkbGlzdGd1eUB5YWhv by5jb20NCmNldEBhdHMuY29tLmF1DQpjaGFybGVzLmpvbmVzQGVkLmFjLnVrDQpjaGFybGVzQGVs bHNvbi5kZW1vbi5jby51aw0KY2hhcmxpZW1AY2hhdmFsLmNvbS5hdQ0KY2hlamJwQGx1cmUubGF0 cm9iZS5lZHUuYXUNCmNobEBjbGVyZXcubWFuLmFjLnVrDQpjaHIxNzAxQG15LWRlamEuY29tDQpj aHJpcy5wcmlvckBudGwuY29tDQpjaHJpcy5yb2JpbnNvbkBlZC5hYy51aw0KY2hyaXNAa2VyaXN0 b3Iub3JnDQpjaHJpc3RpYW5Abm90aGFua3MuY29tDQpjaHJpc3RpbmVfYnJhZGxleUBwY2guZ2Mu Y2ENCmNocmlzdG9waGVyLmEubmFzaEB0cmFuc3BvcnQucWxkLmdvdi5hdQ0KY2h1Y2tAaG9yZGUu b3JnDQpjaHVsZWxAZm9vZGZvcmNoaWFwYXMub3JnDQpjbG9yZUBjb2x1bWJpYS1jZW50ZXIub3Jn DQpjbHJAaWdjLmFwYy5vcmcNCmNvYXN0YWxzQG5ibmV0Lm5iLmNhDQpjb2Jhc3RsY0Bob3RtYWls LmNvbQ0KY29iYkBjZXNjby1mb3JiZXMuY29tDQpjb2xpbi5kLnBmcnVuZGVyQHRyYW5zcG9ydC5x bGQuZ292LmF1DQpjb21haG9ueUBiYXQuZ2RzdC5uZXQNCmNvbm5pZV9mdWxtZXJAY2VvLmN1ZGVu dmVyLmVkdQ0KY29ucmFkY0B5YWhvby5jb20NCmNvcHlfbWFuQGhvdG1haWwuY29tDQpjb3J2ZXJA Y29ydmVyLmVzDQpjb3J2dXMuY29yYXhAbWFpbC50ZWxlcGFjLnB0DQpjcGFAY29iYmxlc3RvbmUu Y29tLmF1DQpjcm9zc2NoZWNrQGFkZWxwaGlhLm5ldA0KY3NhYS1yZXF1ZXN0QGFyZ29uZXQuY28N CmNzYWEtcmVxdWVzdEBhcmdvbmV0LmNvLnVrDQpjc2FhLXJlcXVlc3RAc3BpZGVyc29mdC5jbw0K Y3NhYUBhcmdvbmV0LmNvLnVrDQpjc2FhQHNwaWRlcnNvZnQuY28udWsNCmNzc3pjb2R4QHB1Ymxp Yy53aC5oYi5jbg0KY3VtNHU0QGhvdG1haWwuY29tDQpjdW5uaW5naGFtQGdldHRvLm5ldA0KY3Vz aEBob21lLmNvbQ0KY3VzdG9tZXJjYXJlQHN3eC5uZXQNCmN2OUBnMi5wYm0uY29tDQpjdmVrb2Vj Y0BudXMuc2cNCmN2am1AY2hhdmFsLmNvbS5hdQ0KZGFlbW9uc0BraWxsZmlsZS5vcmcNCmRha2Fm YWxiQGhvdG1haWwuY29tDQpkYWxtYW5Ac2RzLnFsZC5nb3YuYXUNCmRhbHRvbl9tY2d1aW50eS1t cHBAb250bGEub2xhLm9yZw0KZGFuaWVsZkBzaG9hbGhhdmVuLm5ldC5hdQ0KZGFwcGVsYmVlQHRl bHN0cmEuYXVzdGFybmV0LmNvbS5hdQ0KZGFya2RlbW9uNzlAaG90bWFpbC5jb20NCmRhcnJlbi5i dWxsQGdvcHJpbnQucWxkLmdvdi5hdQ0KZGF1Ym1hbkBidWNrbmVsbC5lZHUNCmRhdmUuZy5tb3Jy aXNAbWFpbGV4Y2l0ZS5jb20NCmRhdmVAZmlzaGVyc2hlcm9uLnNjcmVhbWluZy5uZXQNCmRhdmVA cmVzZWFyY2gtZ3JvdXAuY28udWsNCmRhdmViQG9zYS5jb20NCmRhdmlkLmFzaHdvb2RAcnVidXMu Y29tDQpkYXZpZC5rYXVsdEBqY3UuZWR1LmF1DQpkYXZpZC5zd2VldEBvbnRvbmV0LmJlDQpkYXZp ZF9rZWVubGlzaWRlQG5jZXQub3JnLnVrDQpkYXZpZGtAYnJvY3Jvc3MudS1uZXQuY29tDQpkYXZp ZG00QG5jaC5lZHUuYXUNCmRhdmlkbWFzQGRhdmlkbWFzLm5ldA0KZGF2aWR1cml2ZXN0QGJpZ2Zv b3QuY29tDQpkY2hzbGliQG5ldGlucy5uZXQNCmRlLjQ4MjA5NjFAbmV3czIudGVsdXNwbGFuZXQu bmV0DQpkZWJiaWVAZmhjLmNvLnphDQpkZWJiaWVrYXlhQGhvdG1haWwuY29tDQpkZWJpYW4tZGV2 ZWwtcmVxdWVzdEBsaXN0cy5kZWJpYW4ub3JnDQpkZWJpYW4tdXNlci1yZXF1ZXN0QGxpc3RzLmRl Ymlhbi5vcmcNCmRlYzY3MUBjb21jYXN0Lm5ldA0KZGVjYWRlQG15cmlhZC5uZXQNCmRlY2xhbkBo YXdhaWkuZWR1DQpkZWlyZHJlLmUuY2hvcmxleS1tdW5nYXZpbkB0cmFuc3BvcnQucWxkLmdvdi5h dQ0KZGVsYmVyZ3B0eWx0ZEBiaWdwb25kLmNvbQ0KZGVuZHJvbkBlZm4ub3JnDQpkZXJlay5icml0 dG9uQGVkLmFjLnVrDQpkZXNfY2hhbG1lcnNAcWNsLmNvbS5hdQ0KZGV2LnB1YmxpY2l0eUB1ZWEu YWMudWsNCmRncmF5QHNpa2EuY29tLmF1DQpkaHViYmFyZEBzZHMucWxkLmdvdi5hdQ0KZGlhcm1p ZGxvZ2FuQHlhaG9vLmNvbQ0KZGltYXhAcHdvcmxkLm5ldC5waA0KZGluZ2JhdEBjb2Rlc21pdGhz LmNvbQ0KZGlyZWN0b3JAZXZpc3VtLmNvbQ0KZGlya0BsaW51eHNlcnZlci5jb20NCmRpcmttQHJl YWNoLmNvLnphDQpkaXNjb3VudEBjaGluYS1jbHViLnp6bi5jb20NCmRpc2N1c3MtaGVscEBvcGVu b2ZmaWNlLm9yZw0KZGl4aWVrZW5uZUBhb2wuY29tDQpkbWVycmlhbUBrZ3MudWthbnMuZWR1DQpk bWhAYXJtYXJvcy5kbWgub3JnLnVrDQpkbXNpbHZlckBlc2NhcGUuY29tDQpkbmEtZGV2QGVzcmYu ZnINCmRvZ2Vnb29wc0BhdHRiaS5jb20NCmRvbGVicmlhbkBob3RtYWlsLmNvbQ0KZG9scGhpbi1t cDNAa29ueC5jb20NCmRvbi1haXRrZW5AZnJlZXVrLmNvbQ0KZG9uYWxkLncuYmxldGNobHlAdHJh bnNwb3J0LnFsZC5nb3YuYXUNCmRvbm4wNDI1QGhvdG1haWwuY29tDQpkb25uMDQyNUB5YWhvby5j b20NCmRvdWdAY3ljLmNvbQ0KZG92ZXRvbkBrZ3MudWthbnMuZWR1DQpkcWNoeHcuOHk2QGdpbC5j b20uYXUNCmRyLndvb29vQG5vbWFzdGVycy5vcmcNCmRyOEBnMi5wYm0uY29tDQpkcmFnb25ldEBs eWNvcy5jby51aw0KZHJhc25pYUBpbmFtZS5jb20NCmRyYkBwYXRoLmNobWVkcy5hYy5ueg0KZHJv ZXNob3V0QHBhbmRvcmEuYmUNCmRzMkBnMi5wYm0uY29tDQpkc2F0ekBtc24uY29tDQpkc2MubWFp bEB1bmlzYS5lZHUuYXUNCmRzY29sZWRnZUBhb2wuY29tDQpkdW5jYW4ua2Vyci5tcEBhcGguZ292 LmF1DQpkdXJ3b29kZUBtaW5kc3ByaW5nLmNvbQ0KZHVzay50cm9vcGVyc0BpbmFtZS5jb20NCmR2 QG1vYnl1cy5jb20NCmR3eWVycGtAcXV0LmVkdS5hdQ0KZHlhbkBvc2EuY29tDQplYWdsZXNfc3Bv cnRpbmdAeWFob28uY29tDQplYXN0Y29hc3RwaXBlQGJpZ3BvbmQuY29tLmF1DQplZGl0b3JAZW5z LW5ld3MuY29tDQplZGl0b3JAb25saW5lb3Bpbmlvbi5jb20uYXUNCmVkaXRvckBzY290c2xpbmsu YWxwaGFsaW5rLmNvbS5hdQ0KZWR1YXJkb3BzaUBwb3J0dWdhbG1haWwucHQNCmVkd2FyZC5hcmNh ZGlwYW5lQHFmbGVldC5xbGQuZ292LmF1DQplZ3J1bnNreUBpYW1nLm9yZw0KZWljaGluQHRob2su b3JnDQplbGRpZW5lckBlYXJ0aGxpbmsubmV0DQplbGlzZW9yZWNsdXNAeWFob28uZXMNCmVsaXph YmV0aF93aXRtZXJAb250bGEub2xhLm9yZw0KZWxwaGluc2VlckBwZXJ0aC5pZ3MubmV0DQplbHZz dHJvbUBlbHZzdHJvbXNhaWxzLmNvbQ0KZW1haWxAYWRkcmVzcy5pbnZhbGlkDQplbW1hLmtpbmdA ZWQuYWMudWsNCmVtcWJAYW9sLmNvbQ0KZW5xdWlyaWVzQGFiaXEub3JnDQplbnF1aXJpZXNAbW92 aWVtLmNvLnVrDQplbnJpY2FAdHJhZGVuZXQuaXQNCmVwZW5pZG9Abm92YW5ldC5jb20uYnINCmVw b2xsYWtAd2N1cGEuZWR1DQplcmljaGlsbEBpbnRlbW9yYS5uZXQuYXUNCmVzb21tZXJzQGhvdG1h aWwuY29tDQplc3RoQG1haWwucm9jaGVzdGVyLmVkdQ0KZXViYW5rd0BrY21vLmNvbQ0KZXVyb3Nh aWxzQHRpbi5pdA0KZXZlbnRvbmVAbXktZGVqYS5jb20NCmV3NTVAbXkuY2hvaWNlLm9mLnVpZA0K ZXdtekBib3p6aWUuZGVtb24uY28udWsNCmV3bmZAYmlubnNyb2FkLmRlbW9uLmNvLnVrDQpleml0 b3VyQGF1c2luZm8uY29tLmF1DQpmX2dpYnNvbkBteS1kZWphLmNvbQ0KZmFpdGhAbmJuZXQubmIu Y2ENCmZhcXNAcGNzZXJ2LmRlbW9uLmNvLnVrDQpmYkBmcmFuay1idXNzLmRlDQpmYnBAaWdjLm9y Zw0KZmVkZXJpY29AYXIubm9ydGhzYWlscy5jb20NCmZlZWRAa2ludGFsaW5lLmNvLnVrDQpmZXJp ZGF4QGhhbGVzb3duLnUtbmV0LmNvbQ0KZmZhbWlseW5ldEBmYW1pbHktYmJzLm5ldA0KZmljbG9w cmlAd2VidHYubmV0DQpmaWdodGJhY2s5OTU1QG15LWRlamEuY29tDQpmaWxlbGlzdC54bWxAMDFj MTQ1YjcuMjUwYzlkODANCmZpbm50aGVvZG9yc2VuQGRzci5kaw0KZmsuaW1wb3J0QGZ1a2F5YS1z YW5neW8uY28uanANCmZsbWFkcmlkQGNudC5lcw0KZmxvd2F0ZXJAb3B0dXNuZXQuY29tLmF1DQpm bjYyQGRpYWwucGlwZXguY29tDQpmb3JzYWxlQG1vYnk1OC5jb20NCmZyOEBnMi5wYm0uY29tDQpm cmFuY2lzQHBpbnphLmRlbW9uLmNvLnVreg0KZnJhbmsuZWxsaXNAc2QucWxkLmdvdi5hdQ0KZnJh bmtlbndvbEBhb2wuY29tDQpmcmF0ZXJuaXRlLmxpYmVydGFpcmVAd2FuYWRvby5mcg0KZnJlZWJz ZC1xdWVzdGlvbnNAZnJlZWJzZC5vcmcNCmZyaWVuZGxpZXNAc3BpZGVyd2ViLmNvbS5hdQ0KZnJv bUBtYXRoaWUuY3gNCmZyb21ub3dvbkBlYXJ0aGxpbmsubmV0DQpmdEBmcmFuY2lzY290cmluZGFk ZS5jb20NCmZ0Z2FyZGVucmFpbEBiaWdwb25kLmNvbQ0KZnZnZzYwNzFAbWIuaW5mb3dlYi5vci5q cA0KZy5iYWxsQGJvbS5nb3YuYXUNCmcuYnJvdWdoQGJvbS5nb3YuYXUNCmcuZGF2aXNAbm9ydGh1 bWJyaWEuYWMudWsNCmcuai53ZWx0amVAdGEudHVkZWxmdC5ubA0KZy53aHl0ZUBwaHlzaWNzLmds YS5hYy51aw0KZzItbGlzdEBwYm0uY29tDQpnMi1saXN0QHJ0LmNvbQ0KZzJ3YXRjaEBwYm0uY29t DQpnYWJyaWVsbGUuaXdhbm93QHFsZHNlcnZpY2VzLnFsZC5nb3YuYXUNCmdhaWxlc3BoYXJtYWN5 QGZyb2dneS5jb20uYXUNCmdhcmNpYUBtZXRlb2ZhLm1pbC5hcg0KZ2FyZXRoLndhdHRzQGVhc3lu ZXQuY28udWsNCmdhcnJ5QGhhaW5pbmc5NC5mcmVlc2VydmUuY28udWsNCmdhcnliQGlucGx0ZC5j b20uYXUNCmdhcnlnNDQzMEBhb2wuY29tDQpnYXZpbi5zdGVlbGVAZ29wcmludC5xbGQuZ292LmF1 DQpnYXlsZS5iYWxzaWxsaWVAcWxkc2VydmljZXMucWxkLmdvdi5hdQ0KZ2JhY3F1ZUBpZGlyZWN0 LmNvbQ0KZ2JhY3F1ZUBuZXR6ZXJvLm5ldA0KZ2JveWxlQHZpaXNhZ2UuY29tDQpnYnJvd25AYnQt c3lzLmJ0LmNvLnVrDQpnY2FzZWx0b25AeWFob28uY29tDQpnY2tlZWRAYXBleC5uZXQuYXUNCmdj bGVha0BvcHR1c25ldC5jb20uYXUNCmdjcm9zc0BmYXN0bWFpbC5mbQ0KZ2RlYXJAb3plbWFpbC5j b20uYXUNCmdkaW53b29kQGtlbnRsYXcuZWR1DQpnZHNAc3RhdG9pbC5jb20NCmdlYXJsZGluZWJv dnBAc2luZ21haWwuY29tDQpnZW5tYWNoQHh0cmEuY28ubnoNCmdlb2ZmQGtncy51a2Fucy5lZHUN Cmdlb2ZmX2Nvb2tAZjEubmV0LmF1DQpnZW9mZmNvb2tAZjEubmV0LmF1DQpnZXJpQG9hcC5jby51 aw0KZ2dhbWJsZUBuYi5zeW1wYXRpY28uY2ENCmdoYXJyaXNvQGhwY2MwMS5jb3JwLmhwLmNvbQ0K Z2lvdmFubmliYWpvQHJlbW92ZWxpYmVyb3RoaXMuaXQNCmdpcEBkYXIuY3Npcm8uYXUNCmdqLmNv ZEBwaXhpZS5jby56YQ0KZ2pheWVAcmV0ZW1haWwuZXMNCmdqY0BpbnZldGVjaC5jb20uYXUNCmdq b2huc29uQHNkcy5xbGQuZ292LmF1DQpnazVAZzIucGJtLmNvbQ0KZ2xhbW9uZEBhbGJ1cnkubmV0 LmF1DQpnbGVubi5ib290aEBxdGxnLmRlbW9uLmNvLnVrDQpnbGVubkBjeWJlcmRvZy5jb20uYXUN CmdsaXBzdGVyQHVzd2VzdC5uZXQNCmdsb2NvbUBtb3MuY29tLm5wDQpnbHludEBvemVtYWlsLmNv bS5hdQ0KZ21hcmRvbkBiY20udG1jLmVkdQ0KZ21hcnRpbkBhZ3JpYy51d2EuZWR1LmF1DQpnbWF5 b3JAbXZwcy5vcmcNCmduQGF1ZGlvLXJlc3RvcmF0aW9uLmNvbQ0KZ29vZG5ld3NAemVicmEudWVt Lm16DQpnb3JhbkBzb25nZWEuY29tDQpnb3JkaGVhZEBlYXN5bmV3cy5jb20NCmdvcmRvQGxvb3B6 aWxsYS5vcmcNCmdvcmRvbi5tYWNwaGVyc29uQHBhdGgub3guYWMudWsNCmdvcmRvbi5tY25lYWx5 QGpjdS5lZHUuYXUNCmdvcmRvbkBneW91ZC5kZW1vbi5jby51aw0KZ29yZG9uQGxva2FsYWppLmZy ZWVzZXJ2ZS5jby51aw0KZ29yZG9uQHJvdDEzLnFlYnRiYS5hcg0KZ29yZG9uY2hhcG1hbkBob3Rt YWlsLmNvbQ0KZ29yZG9uakBmdW5keS5uZXQNCmdvcmdhbm9AeWFob28uY29tDQpnb3JrMnlAaG90 bWFpbC5jb20NCmdvcm1hbnJlbW92ZUBzeW1wYXRpY28uY2ENCmdvcnNraUBiYW5qby52bmV0Lm5l dA0KZ29ydEBsaW54bmV0LmNvbQ0KZ29zcG9keW5uaWVtYW5kdEBueWV0Lm5ldA0KZ290Y2hhQGJv dW5jZXIuaG9zdGFzYXVydXMuY29tDQpnb3Rlcm1pdGVAa25vbG9neS5uZXQNCmdvdG9oQGF0bW9z LWVyLmVuZy5ob2t1ZGFpLmFjLmpwDQpnb3Rva2VuQG1hdGguaG9rdWRhaS5hYy5qcA0KZ290b2tl bkBtYXRoLnNjaS5ob2t1ZGFpLmFjLmpwDQpnb3Rva2VuQG5vdHdvcmsub3JnDQpnb3Rvb0BqdW4u ZW1haWwubmUuanANCmdvdHRzY2hAdGRsLmNvbQ0KZ291bGV0dGVqZWFuQGFvbC5jb20NCmdvdmlu ZC5raGFyYmFuZGFAc2xpLWluc3RpdHV0ZS5hYy51aw0KZ295amxyQGJ0YW1haWwubmV0LmNuDQpn b3pfMDI0NTFAeWFob28uY29tDQpncDFAcGFyYWRpc2UubmV0Lm56DQpncDMxNTJAY2F2dGVsLm5l dA0KZ3Bhbm51QGNhbWJyaWRnZS5vcmcNCmdwYXJrZXJAYXBwbGUuY29tDQpncGVya2luc0BncGVy a2lucy5jby51aw0KZ3Bna2V5QDB4NjMxMWViM2Qub3JnDQpncGhpbGxpcEBhYWZwLm9yZw0KZ3Bs YW50YW1Ab25lYm94LmNvbQ0KZ3BsZ2Fza2V0YW5kYWNhZ2FAaG90bWFpbC5jb20NCmdwb2Rnb3Jz a2lAd3ptYWlsLnVuaS5sb2R6LnBsDQpncHJlbnRpY2VAcGFyYWRpc2UubmV0Lm56DQpncHJwenlA bXJyb2dlcnMuY29tDQpncHNAZWxzaW5nYS5vcmcNCmdwc0B0dm5hdi5jb20NCmdwc2FuZGVyc29u QGhvdG1haWwuY29tDQpncHNncHNncHNAcG9jenRhLm9uZXQucGwNCmdxdWlyaW5nQG1zbi5jb20N Cmdxd3lrZ0Bkd2RkZGFhZS5jb20NCmdyQGVtZXNjb3R0LmNvLnVrDQpncmFkZXYyMDAwQGhvdG1h aWwuY29tDQpncmFlbWUuYW5kZXJzb25Ab3B0aW1heS5jb20NCmdyYWVtZS5iYXJiZXJAanVzdGlj ZS50YXMuZ292LmF1DQpncmFlbWUuYnJvd25AYnQtc3lzLmJ0LmNvLnVrDQpncmFlbWUua2lydG9u QGZpbGNzLmNvbQ0KZ3JhZW1lLmxlYXNrQHByb2RpZ3kubmV0DQpncmFlbWUubS5rYXlAdGFsazIx LmNvbQ0KZ3JhZW1lLm1jaW50ZWVyQHhhY3RhLmNvLm56DQpncmFlbWUubi5icm93bkBidC5jb20N CmdyYWVtZS5uaWNob2xzb25AYWJldHRlcndvcmxkLmNvLnVrDQpncmFlbWUucGVhcm1hbkBkYXIu Y3Npcm8uYXUNCmdyYWVtZS5yb2JiaW5zQHh0cmEuY28ubnoNCmdyYWVtZS5yb3lAYW5hbG9nLmNv bQ0KZ3JhZW1lLnRyb3VzZGFsZUBlZC5hYy51aw0KZ3JhZW1lLnZldHRlcmxlaW5AbnRsLmNvbQ0K Z3JhZW1lLndlYXJkZW5AY25ldC5jb20NCmdyYWVtZS53aWxzb25AbmF0aW9uc2JhbmsuY28udWsN CmdyYWVtZS53b29kQHVjcy5lZC5hYy51aw0KZ3JhZW1lQGFzdHJvLmdsYS5hYy51aw0KZ3JhZW1l QGNlcnZpZWwucmFkb25jLnVjbGEuZWR1DQpncmFlbWVAY29sZTE0Mi5mcmVlc2VydmUuY28udWsN CmdyYWVtZUBkdW5waHkuZGUNCmdyYWVtZUBncmV5d2FsbC5kZW1vbi5jby51aw0KZ3JhZW1lQGhl cy5lZHUuYXUNCmdyYWVtZUBrY21vLmNvbQ0KZ3JhZW1lQGxpc2F3aGl0ZS5mc25ldC5jby51aw0K Z3JhZW1lQG1haWwudXNhc3RvcmVzLmNvbQ0KZ3JhZW1lQG1haWwudXN5ZC5lZHUuYXUNCmdyYWVt ZUBtYXRoaWUuY3gNCmdyYWVtZUBuZXRnb2RzLm9yZw0KZ3JhZW1lQHJlYWNoLmNvLnphDQpncmFl bWVAc3VyZmluZm8uY29tDQpncmFlbWVAdHJlbWFpbmUuY28udWsNCmdyYWVtZUB1c2FzdG9yZXMu Y29tDQpncmFlbWVAd29ybGRvbmxpbmUuY28uemENCmdyYWVtZV9ib3lsZUBteS1kZWphLmNvbQ0K Z3JhZW1lX2RyeXNkYWxlQGhvdG1haWwuY29tDQpncmFlbWVfbmV3Y29tYkB5YWhvby5jb20NCmdy YWVtZV9zbWl0aDc3QGhvdG1haWwuY29tDQpncmFlbWVjcmVlQGFvbC5jb21wb3N0DQpncmFlbWVk YXZpZHdpbHNvbkB5YWhvby5jb20NCmdyYWVtZWR1bnN0YW5AcmFpbmJvd3JlZ2lvbi5jb20NCmdy YWVtZWpheWVAaW5hbWUuY29tDQpncmFlbWVtQHBkZC4zY29tLmNvbQ0KZ3JhZW1lckBuemFzLW4u b3JnLm56DQpncmFlbWV3aGl0ZTQ3QGZveGludGVybmV0LmNvbQ0KZ3JhZXNzZXJAdGNhLm5ldA0K Z3JhZnNAc2hhdy5jYQ0KZ3JhaGFtLmRyYWJibGVAbGluZW9uZS5uZXQNCmdyYWhhbS50Lndvb2RA b3JhY2xlLmNvbQ0KZ3JhaGFtMDFAbG9vay5jYQ0KZ3JhaGFtQGFsZWRyaW5rZXIuY28udWsNCmdy YWhhbUBjYWx0ZWcub3JnDQpncmFoYW1AZmwubmV0LmF1DQpncmFoYW1AZ3dhbHRlci5kZW1vbi5j by51aw0KZ3JhaGFtQGhvdC5yci5jb20NCmdyYWhhbUBtZWFzdXJlemVyby5jb20NCmdyYWhhbWJA cHNhYy1hZnBjLmNvbQ0KZ3JhbW1hdGltQHdvcmxkbmV0LmF0dC5uZXQNCmdyYW1tZW5zQHN2bi5u ZXQNCmdyYW5kZ0BpbmZvbWFuaWFrLmNoDQpncmFuZG1hbkBuYm5ldC5uYi5jYQ0KZ3Jhbmdldmlk ZW9AYW9sLmNvbQ0KZ3JhcGFwb3J0QGNvbWdhdGVzLmNvLmlsDQpncmFzc283ODlAaG90bWFpbC5j b20NCmdyYXZpdHkxQHNoZWxsMS5pZ2xvdS5jb20NCmdyYXZpdHlwaHlzaWNzQHdlYnR2Lm5ldA0K Z3JheWRAdHVycGlubHRkLmNvbQ0KZ3JheW1hdXNAeWFob28uY29tDQpncmF6aWFub0BlY29zc2Uu bmV0DQpncmRlc3NvdWJAbm9vcy5mcg0KZ3JlYXRfaGllcm9waGFudEBob3RtYWlsLmNvbQ0KZ3Jl ZW5idWZmYWxvY2FiYmFnZW1hbkB5YWhvby5jb20NCmdyZWVuaWUzMUBqdW5vLmNvbQ0KZ3JlZW5q ZWVwdGpAeWFob28uY29tDQpncmVlbnJheTdAaGFubWFpbC5uZXQNCmdyZWVucm9vbTIzMTg3QGZ1 enp5aGF6ZS5jb20NCmdyZWVuc0BkaWFtb25kc2cuY29tDQpncmVlbnRlc3RAb3B0dXNob21lLmNv bS5hdQ0KZ3JlZW50dkBwYXVsYnVueWFuLm5ldA0KZ3JlZmlAb3plbWFpbC5jb20uYXUNCmdyZWcu YmF1bmVAdC1vbmxpbmUuZGUNCmdyZWcuamVuc2VuQGF0dGJpLmNvbQ0KZ3JlZy5sZXRpZWNxQGFh cmlzLm5ldA0KZ3JlZy53b29scmlkZ2VAdGFwLmNvbQ0KZ3JlZzJAc3VyZmFpZC5vcmcNCmdyaHVu dGVyQG5lb25vdXMuY28udWsNCmdyamF5ZUB0ZXJyYS5lcw0KZ3JvbW9mZkB1a3IubmV0DQpncm94 YnVyZ2hAaW5mb3NjaWVuY2Uub3RhZ28uYWMubnoNCmdydW1ibGVyQGNhYmxlb25lLm5ldA0KZ3Nh Y2ttYW5uQGNsYXNzcm9vbS5jb20NCmdzY2FwbGVuQHJveWFsbGVwYWdlLmNhDQpnc2hhcGlyb0Bz ZW5kbWFpbC5vcmcNCmdzdGFuZEBjb21wdXNlcnZlLmNvbQ0KZ3Vlc3RAYW5vbnltb3VzLmNvbQ0K Z3Vlc3RAZ3Vlc3QubmV0DQpndmFuZGVydm9yZEBpcHJpbXVzLmNvbS5hdQ0KZ3lvdW5nQGZjY21l bW9yeS5jb20NCmd6MkBnMi5wYm0uY29tDQpoLnBvZWxjaGF1QGlhbWcub3JnDQpoLnJ1dGtvd3Nr YUBlZC5hYy51aw0KaGFyYWxkLnluZGVzdGFkQGhpYWxzLm5vDQpoYXJ0d3lAeHRyYS5jby5ueg0K aGF5ZXNzdHdAeWFob28uY29tDQpoYmxlZUBtYWlsLnNhbWNodWx5LmNvLmtyDQpoZWluei5naWVn ZXJpY2hAZWQuYWMudWsNCmhlbGVuLm0uc3RlaGJlbnNAdHJhbnNwb3J0LnFsZC5nb3YuYXUNCmhl bGxvQG1ha2Vhc2hvcnRlcmxpbmsuY29tDQpoZWxwZGVza0BtYmkuY28uemENCmhqbm9ibGVAaWdj Lm9yZw0KaG9tZUBkb21lc3RpY2R1Y2tzLmNvLnVrDQpob21lQHBvdWx0cnlzY290bGFuZC5jby51 aw0KaG9uZ2tvbmdAc2QucWxkLmdvdi5hdQ0KaG93YXJkX2hhbXB0b24tbXBwQG9udGxhLm9sYS5v cmcNCmhvd3lvdWRvaW5fMjFAaG90bWFpbC5jb20NCmhyd2F0Y2hueWNAaWdjLm9yZw0KaHN1dHRl ckBnb3R3LmNhDQpodHRwNDA0QGhvdC5lZQ0KaHVtYWt0MkBhb2wuY29tDQpodW1hbi5yaWdodHMu YWxlcnRAM3dlYi5uZXQNCmh5cGhlbkBoeXBoZW5vbG9naXN0LmNvLnVrDQppLmFsbGlzb25AYW50 Y3JjLnV0YXMuZWR1LmF1DQppLmQuc2Vsd29vZEBiaGFtLmFjLnVrDQppLnBvc3QuYW5kQHlvdS5w b3N0LnRoZS5yZXBseS5pbnZhbA0KaWFpbnJAZGNzLmVkLmFjLnVrDQppZmR1ZGVAY2FibGVvbmUu bmV0DQppamFjb2JpQHRwZ2kuY29tLmF1DQppbmNpZGVuY2VzLmxhcm9jaGVsbGVAd2FuYWRvby5m cg0KaW5kZXhAaGVuaG91c2VzLmNvLnVrDQppbmRleEBwb3VsdHJ5LWJvb2tzLmNvLnVrDQppbmRp YW50cmF2ZWxjb21wYW55QHlhaG9vLmNvLnVrDQppbmZvLWN2cy1vd25lckBnbnUub3JnDQppbmZv LWN2cy1yZXF1ZXN0QGdudS5vcmcNCmluZm8tY3ZzQGdudS5vcmcNCmluZm9AYWNlY29tcHBsdXMu Y29tDQppbmZvQGFsbHJpZ2h0LmZpDQppbmZvQGJvcm9iYXJteS5jb20NCmluZm9AY2FybHNlbi1z YWlscy5kaw0KaW5mb0BjZGNucGluLm9yZw0KaW5mb0BjaGF2YWwuY29tLmF1DQppbmZvQGNyZWlu aGFyZHQuZGsNCmluZm9AZGsubm9ydGhzYWlscy5jb20NCmluZm9AZXZvbHZlc3JsLml0DQppbmZv QGhlLm5ldA0KaW5mb0BoZW5ob3VzZXMuY28udWsNCmluZm9AaG9zdGV0dGxlci5jb20NCmluZm9A aTJpaS5jb20NCmluZm9Aa2F3YXNha2kuY3oNCmluZm9Ab3B0aW1heC5ubA0KaW5mb0Bwb3VsdHJ5 LWJvb2tzLmNvLnVrDQppbmZvQHJpYmJvbi5uZXQuYXUNCmluZm9Ad3R2MjEuY29tDQppbmZvQHd0 djIxMTFzdHVkaW8uY29tDQppbmZvQHphbWJlemkuY28udWsNCmluZm9AemFtYmV6aS5jb20NCmlu cHJpbnRAYmlncG9uZC5jb20uYXUNCmludmFsaWRAc2FybmllLm9yZy51aw0KaXNtQGJ1c3RhLmNv LnVrDQppd2FsbGFjZUBubWdtZW50b20uZGVtb24uY28udWsNCmouY3JheW1lckBidG9wZW53b3Js ZC5jb20NCmoubC5hLm1hZGRlbkBhYmRuLmFjLnVrDQpqLm1hcnNoYWxsQGVkLmFjLnVrDQpqLnJp bGV5QGxhdHJvYmUuZWR1LmF1DQpqYUBqdXN0aWNlYWN0aW9uLm9yZy5hdQ0KamFjQGF2dHRlY2gu Y29tDQpqYWZmYUBnYmVubi5kMmcuY29tDQpqYWthcnRhQHNkLnFsZC5nb3YuYXUNCmphbmV0QHd3 cHVibGlzaC5jb20NCmphbm5AZGlhbC5waXBleC5jb20NCmphcmV0aEBjYW1lbG90LmNvLmpwDQpq YXJpeWFAc3RhcnQub3IudGgNCmphc25pY0BtaW5kc3ByaW5nLmNvbQ0KamFzb24uYXNwaW5hbGxA Z29wcmludC5xbGQuZ292LmF1DQpqYXdAdWNzLmVkLmFjLnVrDQpqYXloYXJ2ZXlAb3p4cHJlc3Mu Y29tLmF1DQpqYmpvbmVzQGFoZWNwYi51YW1zLmVkdQ0KamJsYWtlQGMtNC5vcmcNCmpicmlkZ21h bkBwZWFjZS1hY3Rpb24ub3JnDQpqZGdib2JyQGlvLmNvbQ0KamRncmFlbWVAbXktZGVqYS5jb20N CmplZmYuY2hhbm5lckB4YWN0YS5jby5ueg0KamVmZkBtY2doaWUubWUudWsNCmplZmZyZXkuYmly ZEBqY3UuZWR1LmF1DQpqZXJlbXlAb21iYS5kZW1vbi5jby51aw0KamVzcGFuYUB0b3ByaWRlci5j b20NCmpld2Vsc0BpbmlhY2Nlc3MubmV0LmF1DQpqZmtfaHFAc3Rvcmllcy5jb20NCmpobXNwb3J0 QHNpbW5ldC5pDQpqaW1jb25uYWhAYmlncG9uZC5jb20NCmprQHRlYnNhaWwuY29tDQpqbHRheWxv cjJAY29tcHVzZXJ2ZS5jb20NCmptYXllckBpdHNjb21tdW5pY2F0aW9ucy5jb20NCmptcjQ0MEBh b2wuY29tDQpqb2RhQHBkYy5rdGguc2UNCmpvZUBkb21haW4xLmNvbQ0Kam9lQGRvbWFpbjIuY29t DQpqb2VAc2FsZXJuby5jb20NCmpvZUBzb2FwLmNvbQ0Kam9lX3RyYWRlckBjaGVlcmZ1bC5jb20N CmpvZWxAc3RldmVjcm9ja2VyLmNvbQ0Kam9ldzBAaG9tZS5jb20NCmpvaG4uZ2VhcmluZ0BxbGRz ZXJ2aWNlcy5xbGQuZ292LmF1DQpqb2huLnphaG5lckBtYnQuY29tDQpqb2huQGpwYXRtb3JlLmZy ZWVzZXJ2ZS5jby51aw0Kam9obkBzY2FuY2VtLmNvbS5hdQ0Kam9obkB3aXJlZHN0cmF0ZWdpZXMu Y29tDQpqb2huZm11cnJheUBvcHR1c2hvbWUuY29tLmF1DQpqb21vdG9AbWFpbC50ZWxlcGFjLnB0 DQpqb24ucm9sYW5kQGNvbnN0aXR1dGlvbi5vcmcNCmpvcm5hbGFiYXRhbGhhQGhvdG1haWwuY29t DQpqb3NodWE1QGlzdGFsLmNvbQ0KanVkeS5tLm9zd2luQHRyYW5zcG9ydC5xbGQuZ292LmF1DQpq dW1wYmFjazFAaG90bWFpbC5jb20NCms2NC43NzMyNzlAbW9ub2xpdGgubmV3cy5lYXN5bmV0Lm5l dA0Ka19oYXVnc25lc0B5YWhvby5ubw0Ka2FybHBAb3VybGRzZmFtaWx5LmNvbQ0Ka2F0bmV3c0Bu dGx3b3JsZC5jb20NCmtjaGFwbWFuQG5ldHNwYWNlLmNvbS5hdQ0Ka2N3ZW5nQGVjbi5uZXQuYXUN CmtkaWNraW5zQG5vcnRobmV0LmNvbS5hdQ0Ka2VpdGhfZ0Bkc2wucGlwZXguY29tDQprZWxsb3hA a2VsbG94Lm5vDQprZW4ua2luZ0BzZC5xbGQuZ292LmF1DQprZW5Aa2VubG93ZS5jb20uYXUNCmtl bmhAY21mLm5ybC5uYXZ5Lm1pbA0Ka2VycmllLnR5bmRhbGxAZ29wcmludC5xbGQuZ292LmF1DQpr ZXZpbkB0YXBleC5jb20uYXUNCmtldmludEBiZW50b24ub3JnDQprZXZpbndlbGxzQGZyZWV1ay5j b20NCmtldmlud2VsbHNAdG90YWxpc2UuY28udWsNCmtoLjE3ODU4NDA1QG5ld3MxLnJzbTEub2Nj YS5ob21lLmNvbQ0Ka2hjeWNsZUBraGN5Y2xlLmNvbS5zZw0Ka2luZ0Bkb21haW4uaGlkZGVuDQpr aW5nQG1pZHdlc3QtbWljcm93YXZlLmx0ZC51aw0Ka25vYmNvdXJ0QGFvbC5jb20NCmtydXNzb3Nf c3dAeWFob28uY29tDQprcnVzdG92QGtydXN0b3YuY28udWsuaW52YWxpZA0Ka3J5bnNraUBhb2wu Y29tDQprcnl0ZW5AbGFyZm9yYmFyZi5mcmVlc2VydmUuY28udWsNCmtzY2xhdm9zQHBvd2VydXAu Y29tLmF1DQprdXJ0QG9wZW5sZGFwLm9yZw0Ka3kxLjIwMjU0QG5ld3MxLnJpdnJ3MS5uc3cub3B0 dXNob21lLmNvbS5hdQ0Ka3lsaWUudHVybmVyQHFsZHNlcnZpY2VzLnFsZC5nb3YuYXUNCmt5bS5z dGVlckBzZC5xbGQuZ292LmF1DQpsYXJpbnN0cmFkaW5nQHQtb25saW5lLmRlDQpsYXJyeS5qb25l c0BzZHJjLmNvbQ0KbGF3dG9uQHZpb3JvLm5sDQpsYmNjdXN0b21lckBsYmMuY29tLmF1DQpsZWNr ZXlAbGF0cm9iZS5lZHUuYXUNCmxlaWZAY2FyZHN0b25lLmNvbQ0KbGVpZmpAaXQuc3Uuc2UNCmxl bi5tY2tlbm5hQHFmbGVldC5xbGQuZ292LmF1DQpsZW5nYXVlckBqaG1pLmVkdQ0KbGVvLnZhbl9k ZXJfaGV1dmVsQGRlZ3Vzc2EuY29tDQpsZW8udmFuX2Rlcl9oZXV2ZWxAbWJ0LmNvbQ0KbGVvbmll LmhhbWlsdG9uQHFsZHNlcnZpY2VzLnFsZC5nb3YuYXUNCmxldml0dGVAc3RhY2tlbi5rdGguc2UN CmxoYUBzdGFja2VuLmt0aC5zZQ0KbGlhc0BsaXN0cy5saW51eC5vcmcuYXUNCmxpZXNlZ2FuZ0Bs YXRyb2JlLmVkdS5hdQ0KbGlsLmdvbGluZWxsaUBzZC5xbGQuZ292LmF1DQpsaWxpaUB5YWhvby5j b20NCmxpbmRhaGxAcGJtLmNvbQ0KbGluZHNheS50YW5uZXIubXBAYXBoLmdvdi5hdQ0KbGlua3Jl dmlld0B2aXJ0dWFsb2xvZ3kuY29tDQpsaXN0bWFzdGVyQGxpc3RzLmRlYmlhbi5vcmcNCmxpc3Rz QGFpbmZvcy5jYQ0KbGlzdHNAY2h1bWJseS5tYXRoLm1pc3NvdXJpLmVkdQ0KbGlzdHNAdGFvLmNh DQpsaXN0c2VydkBsaXN0c2Vydi5zeXIuZWR1DQpsaXVjbUBjY21zLm50dS5lZHUudHcNCmxpdmVA Y2hhdmFsLmNvbS5hdQ0KbG1fbmV0QGxpc3RzZXJ2LnN5ci5lZHUNCmxvY2FsaG9zdEBvc2NlcHNq NS5rYW5pbi5hcm5lcy5zaQ0KbG9jYWxob3N0QHRlbGVrb20uc2lvbC5uZXQNCmxvY2hmeW5lQG9w dG9ubGluZS5uZXQNCmxvZ2FucnhAb3plbWFpbC5jb20uYXUNCmxvbmRvbkBzZC5xbGQuZ292LmF1 DQpsb25kb25zdGF0dG9AeWFob28uY28udWsNCmxvc2FuZ2VsZXNAc2QucWxkLmdvdi5hdQ0KbHRj bWRyamltQGhvdG1haWwuY29tDQpsdWNreUB1bWljaC5lZHUNCmx1aXNqZW5raW5zMjBAY2hlbGxv Lm5sDQptLmdyYW50eEBtY2hzaS5jb20NCm1hYmJvdHRAY2FtdGVjaC5uZXQuYXUNCm1hZC5zY2ll bnRpc3RAZ2V0Mm5ldC5kaw0KbWFkYmVhcmRAaG90bWFpbC5jb20NCm1hZGVzaWduQGVtaXJhdGVz Lm5ldC5hZQ0KbWFnc0BzZWxjb24uY29tLmF1DQptYWlsQG1pbHJveS5idGludGVybmV0LmNvLnVr DQptYWlsQG9wdGlwYXJ0cy5jb20NCm1haWxAcWZsZWV0LnFsZC5nb3YuYXUNCm1haWx3aWxkcm9z ZUB0ZXJyYS5uZXQuYXUNCm1ham9yZG9tb0BmcmVlYnNkLm9yZw0KbWFqb3Jkb21vQHZnZXIucnV0 Z2Vycy5lZHUNCm1ha29sb2RnZS5jaGFydGVyc0B4dHJhLmNvLm56DQptYXJjaGVsQHBvd2VydXAu Y29tLmF1DQptYXJkaWx1cmdAaG90bWFpbC5jb20uYXUNCm1hcmdAY2cuZW5zbXAuZnINCm1hcmtA YnRjLmNvLnphDQptYXJrQG1jcy52dXcuYWMubnoNCm1hcmtldGluZ0BmZXJuaHVyc3Rib29rcy5j by51aw0KbWFya3VzQGluZm9seXRpY3MuY29tDQptYXJ0aW5AdW5pLW1haW56LmRlDQptYXR0QGxl aGkudGFtdS5lZHUNCm1hdHRkZWxiQGNveC5uZXQNCm1hdHRlby5tYXJjaGlvcmktZGVtb0Bwb3N0 ZS5pdA0KbWF0dGhldy5tYWdpbkBzZC5xbGQuZ292LmF1DQptYXR0c2p1bmtlbWFpbEB5YWhvby5j b20NCm1hdWx3dXJmQHN6b24uZGUNCm1heEBvbGlzYWlscy5pdA0KbWJhcmxpbmdAc2RzLnFsZC5n b3YuYXUNCm1icmFuZEBmYXN0bGFuZS5uZXQNCm1jYXJyQG1jbGVvZGFjY2Vzcy5jb20uYXUNCm1j a2VuemllQGZuby5vcmcNCm1ja2lubGV5QGdsZW5ib3VybmUtYW50aXF1ZXMuZnNuZXQNCm1kdW5u QHRhc3NpZS5uZXQuYXUtLQ0KbWU5QHByaXZhY3kubmV0DQptZWRpYWJlYXRAaWdjLm9yZw0KbWVk aWF3YXRjaC1vd25lckBmcmVlYjkyLm5ldA0KbWVocmRhZC5yb3dzaGFuYmluQGNtZy5ubA0KbWVp c2Vuc2NoZXJAaWdjLm9yZw0KbWVsQG1lc3NhZ2luZ2RpcmVjdC5jb20NCm1lbWVkLmNleWxhbkB5 YW1haGEtbW90b3IuY28uYXQNCm1lbW8uMjAwMzA0MDkxOTQ5NTIuMjYzOWNAY2l4LmNvbXB1bGlu ay5jby51aw0KbWV0aHZlbmdAbG9naWNhLmNvbQ0KbWV0cm9tb3RvckBzdXBlcm9ubGluZS5jb20u dHINCm1pY2hhZWwuZWNraGFyZHRAdC1zeXN0ZW1zLmNvbQ0KbWljaGFlbC5rZWxseUBzZC5xbGQu Z292LmF1DQptaWNoYWVsLmxlZS5tcEBhcGguZ292LmF1DQptaWNoYWVsX3dpbHNvbkBxY2wuY29t LmF1DQptaWNoYWVsc0BpbmV0Lm5vDQptaWNoZWwuYW5kcmVAc3dpcG5ldC5zZQ0KbWljaGVsLmZp bmdlcmh1dEBpcmNhbS5mcg0KbWljaGVsbGUud2lubmVyQHZpcmdpbi5uZXQNCm1pY2suai5tY3No ZWFAdHJhbnNwb3J0LnFsZC5nb3YuYXUNCm1pY2subGlubmFuQHNkLnFsZC5nb3YuYXUNCm1pa2Fl bEBkdWVsbHMuc2UNCm1pa2UudHVsbGV0dDNAbnRsd29ybGQuY29tDQptaWtlLndhdHNvbkBiaWdw b25kLmNvbQ0KbWlrZUB1cmdsZS5jb20NCm1pa2tvLmJydW1tZXJAd2Itc2FpbHMuaW5ldC5maQ0K bWlsbGlnYW5zQG9wdHVzbmV0LmNvbS5hdQ0KbWlzc2lvbkBjaGF2YWwuY29tLmF1DQptaXNzdkBj aGF2YWwuY29tLmF1DQptaXN0ZXJlc2dAYW9sLmNvbS5hdQ0KbWpvZGVpdEBnbXguZGUNCm1raXJr ZUB1bHRyYS5uZXQuYXUNCm1scnVnYnlAbWxydWdieS5jb20NCm1tYXJ0aW5AY2V5ZC5lcw0KbW1z QGtqYy5nb3YubXkNCm1vYnlAYWlyY3JhZnRtYWlsLmNvbQ0KbW9uYWdoYW5AbmNhYmxlLmNvbS5h dQ0KbW9vZHlhc21vb2R5Z2V0c0Bhb2wuY29tDQptb29yZXJpY0Bob21lLmNvbQ0KbW9yZHJlZEBh dHRnbG9iYWwubmV0DQptb3JkcmVkQGlibS5uZXQNCm1vdG9yc3BvcnRwbEBwYWNpZmljLm5ldC5z Zw0KbW91bnRqb3lAdGluZXQuaWUNCm1zYW5kcmlvbGlAaW5mb3ZpYS5jb20uYXINCm1zZGVnQG1j aHNpLmNvbQ0KbXNmYWlzb25AeWFob28uY29tDQptc2hrb2xuaWtAc2NhbGFiaXVtLmNvbQ0KbXRt LndhbmdAeHRyYS5jby5ueg0KbXVlbmtlbEB0Y2guZGUNCm11Z2hpci1hbC1oaW5kaUB2aXN0by5j b20NCm11cnJheS50b2RkQHhhY3RhLmNvLm56DQptdXRpbnlAb25ldGVsLm5ldC51aw0KbXdoYWxl bkBwYWNiZWxsLm5ldA0KbXlzcWwtdGhyZWFkNzQ0MzBAbGlzdHMubXlzcWwuY29tDQpteXY4ZXds d0BiaW5uc3JvYWQuZGVtb24uY28udWsNCm16dWJlckB2ZXRjLnVzeWQuZWR1LmF1DQpuMGp1aXpx M3FiaXhsNEA0YXguY29tDQpuNC4xODc1NjgyQG96ZW1haWwuY29tLmF1DQpuYW5jeS5icnVja2Vu QHBmaXplci5jb20NCm5hbmthaWNvQG9hay5vY24ubmUuanANCm5hdGlvbmFsb2ZmaWNlQGFjdHMu b3JnLnphDQpuYXR0eXJlYkBpeC5uZXRjb20uY29tDQpuYXVqb2tzQGZ1cy1zb2Z0LmRlDQpuYXVq b2tzQG50ZG9tYWluLmRlDQpuZWlsX3N1bmRlcmxhbmRAaG90bWFpbC5jb20NCm5laWxoQGN3Y29t Lm5ldA0KbmV1dGVjQHBhY2JlbGwubmV0DQpuZXdncm91cHMtZXJyb3JzQGlzYy5vcmcNCm5ld2dy b3Vwcy1yZXF1ZXN0QGlzYy5vcmcNCm5ld3MtdGlwc0BuZXdzLmNvbQ0KbmV3cy5ub3JyaXNAdmly Z2luLm5ldA0KbmV3czAycTRAZG9udHVzZXRoaXMubWFpbmx5Lm1lLnVrDQpuZXdzQGFmbHEuY29t LmF1DQpuZXdzQHRpdGFuaWMuY28udWsNCm5mNkBnMi5wYm0uY29tDQpuaWNoaW5hb0BmYS5tYm4u b3IuanANCm5pY2tAZWFzeXNvZnQuY29tDQpuaWNrQGx1cmNoZXIub3JnDQpuaWsuZ2lzYm9ybmVA ZWQuYWMudWsNCm5pc2NiYUBhb2wuY29tDQpuaXRyb0BhdHMuY29tLmF1DQpua3ljQHN5bXBhdGlj by5jYQ0Kbm9jaGV4QGtpbnRhbGluZS5wbHVzLmNvbQ0Kbm9kYUBrb3pha2kuY28uanANCm5vZHZp bGxlQGFvbC5jb20NCm5vZUBjdHNhbGVzLmNvbQ0Kbm9lbGEuY2VydXR0aUBnb3ByaW50LnFsZC5n b3YuYXUNCm5vZW1haWxAZ2FqaXRzLmNvbQ0Kbm9lbWFpbHBsZWFzZUBub3doZXJlLmNvbQ0Kbm9m bHlieUB5YWhvby5jb20NCm5va2lhbmdfZmFxQHlhaG9vLmNvLnVrDQpub21lcmN5QHpvbWJpZS5k ZW1vbi5jby51aw0Kbm9ybWFuLm1hY2xlb2RAZWQuYWMudWsNCm5zcEBkbmV0LmF1bnouY29tDQpu eWJlcmdAbGF0cm9iZS5lZHUuYXUNCm83QHhtbTQua2suYjEzDQpvZmZpY2VAZ3JlZWtoZWxzaW5r aS5ncg0Kb2thbW90b0BhaS5pcy51ZWMuYWMuanANCm9sZWFyaWNhcmRvQGFvbC5jb20NCm9yZGVy c0Bkb21lc3RpY2R1Y2tzLmNvLnVrDQpvcmRlcnNAcG91bHRyeXNjb3RsYW5kLmNvLnVrDQpvc2Fr YUBzZC5xbGQuZ292LmF1DQpvc29yaW9AZW1wcmVzYXJpYWxlcy51bHBnYy5lcw0Kb3V0YmFja19j aGVtaXN0QGIxOTAuYW9uZS5uZXQuYXUNCm92ZG5mcnpyZGhhLjMxOTJAdGsybXNmdG5ncDEzLnBo eC5nYmwNCm93Y0BlbmVyZ3ktbmV0Lm9yZw0KcC5kd3llckBxdXQuZWR1LmF1DQpwLmhvZ2VuYmly a0BjcHMubmwNCnAubm9sYW5AbWFzc2V5LmFjLm56DQpwLnBpZ3JhbUBsYXRyb2JlLmVkdS5hdQ0K cC53YXJkbGV5QGxhdHJvYmUuZWR1LmF1DQpwMzYuMTYwMDhAdHdpc3Rlci5yZGMta2MucnIuY29t DQpwYWJsbzl1c0B5YWhvby5jb20NCnBhcGFkb3BAcGVhay5vcmcNCnBhcGVtQGRvbWFpbi5oaWRk ZW4NCnBhcGVtQHVuaW9uLmVkdQ0KcGFyY0Bwcmlzb25hY3RpdmlzdC5vcmcNCnBhcmtlc2hzQG96 ZW1haWwuY29tLmF1DQpwYXRpZW50c2NvQGljb21tLmNhDQpwYXRyaWNrLmoucXVpcmtAdHJhbnNw b3J0LnFsZC5nb3YuYXUNCnBhdWxAZ2l2ZXJpbi5jby51aw0KcGF1bEBoYXJwZXIubmV0DQpwYXVs QG5vdC5hLmNoYW5jZS5laXJjb20ubmV0DQpwYXVsQHBhcGlsaW8uY28udWsNCnBhdWxAcXVpbHR5 Yml0cy5jb20NCnBhdWxzQGhhc3RkZWVyLmNvbS5hdQ0KcGJmN0BjZGMuZ292DQpwYnVkZ2VsbDFA bmYuc3ltcGF0aWNvLmNhDQpwZWFjb2NrX3NvZnR3YXJlQGJpZ3BvbmQuY29tDQpwZWRtb25kc0Bz ZHMucWxkLmdvdi5hdQ0KcGVyQGJsdWV0YWlsLmNvbQ0KcGVyc29uYWxzQG1vZGVyYXRvcnMuaXNj Lm9yZw0KcGV0ZUBmZW5lbG9uLmNvbQ0KcGV0ZXIubWVsbG9yQHNkLnFsZC5nb3YuYXUNCnBldGVy LncuZWxsaXNAdHJhbnNwb3J0LnFsZC5nb3YuYXUNCnBldGVyLndhZGxleUBzZC5xbGQuZ292LmF1 DQpwZXRlckBncmFkd2VsbC5jb20NCnBldGVyQGpwLXZlbGFzLnB0DQpwaDMuMjExMTBAbmV3czIu ZWFzdC5jb3gubmV0DQpwaGFybWFjeUBwb3dlcnVwLmNvbS5hdQ0KcGhlbjM3NjAyMkBhb2wuY29t DQpwaGlsLmR1bm5pbmdAeGFjdGEuY28ubnoNCnBoaWxAZXZvbHV0aW9uY3JlYXRpdmUuZnJlZXdp cmUuY28udWsNCnBoaWxAc3RvdmVsbC5vcmcudWsNCnBoaWxtY2NAbWVsYnBjLm9yZy5hdQ0KcGll bWFuMTAyNEBhb2wuY29tDQpwaWVtYW5AcGllbWFuLm9yZw0KcGlwYWxhbUB5YWhvby5jb20NCnBq dWxpZmZAbmV0c3BhY2UubmV0LmF1DQpwb3N0bWFzdGVyQGRmaWRwZXJ1Lm9yZw0KcG9zdG1hc3Rl ckBwaHlzaWNzLmdsYS5hYy51aw0KcG9zdG1hc3RlckBzbm93ZG9uLmFyYm9yaXMuY29tDQpwb3N0 bWFzdGVybkB4Y3NuLm9yZw0KcG9zdG1hc3RlcnNAeGNzbi5vcmcNCnByZXNpZGVudEBhbXJhbnN3 LmFzbi5hdQ0KcHJldmVudGlvbmV3c0BjZGNucGluLm9yZw0KcHJpc29uYWN0LWxpc3RAcHJpc29u YWN0aXZpc3Qub3JnDQpwcm9mb3NwQGJvbC5jb20uYnINCnBzNi40MTMxODRAdXJzYS1uYjAwczAu bmJuZXQubmIuY2ENCnB1YmxpY2l0eW9mZmljZXJAYW1yYW5zdy5hc24uYXUNCnB1cnBsZS5tYXJp bmVAdmlyZ2luLm5ldA0KcHYyQGcyLnBibS5jb20NCnB3NUBnMi5wYm0uY29tDQpxYmFsbEBnY2kt bmV0LmNvbQ0KcXM3QGcyLnBibS5jb20NCnF1YW50dW1zcGFpbkBxdWFudHVtc2FpbHMuY29tDQpx dW5peDY5QGhvdG1haWwuY29tDQpyLm1hYXNAbGF0cm9iZS5lZHUuYXUNCnIubWl0dGVuQHZldC51 bmltZWxiLmVkdS5hdQ0KcjE0LjU2ODAzMTlAbmV3cy10ZXh0LmNhYmxlaW5ldC5uZXQNCnJhZGxh bUBtcm1vcnRnYWdlLmNvbS5hdQ0KcmFmYWVsb3VzQGhpc3RvcmlhLnp6bi5jb20NCnJhZmZpZ0Bm dXR1cm5ldC5lcw0KcmFpZGVyc2RvY3RvcnMyQG1hYy5jb20NCnJhaWxAZ3JleXdhbGwuZGVtb24u Y28udWsNCnJhcmluYWxkQG1pZHdheS51Y2hpY2Fnby5lZHUNCnJheS5lLnJhd2xpbmdzQHRyYW5z cG9ydC5xbGQuZ292LmF1DQpyYXkubWl0Y2hlbGxAYW1uZXN0eS5vcmcudWsNCnJheWNveDFAZG9k by5jb20uYXUNCnJheWtpbmdAYmlncG9uZC5jb20NCnJheW1vbmQuZC5nYXJyYXJkQHRyYW5zcG9y dC5xbGQuZ292LmF1DQpyY2hhcGxpbkBrb21hdHN1LmNvbS5hdQ0KcmVhbG9wdGlAYW9sLmNvbQ0K cmVkZWxpYmVydGFyaWFfYnNAeWFob28uY29tLmJyDQpyZWRteXJsaW5AZW1sLmNjDQpyZW1vdmVA b25lYWRkcmVzcy5uZXQNCnJlcGx5X3RvX2dyb3VwX3BsZWFzZUBjbmV3cy5jb3JlbC5jb20NCnJl cWVyZTAyMTNvMjNAeWFob28uY29tDQpyZXF1aWVtQGZyZWV1ay5jb20NCnJlc2lzdGVvbWNAcmVz aXN0LmNhDQpyZXRhaWxAZ29wcmludC5xbGQuZ292LmF1DQpyZnVjaHNAYWd1Lm9yZw0KcmhhcmRp bkB0cGdpLmNvbS5hdQ0KcmhidXRsZXJAbWFzc2V5LmFjLm56DQpyaG9uYS5jdWxsZW5AZWQuYWMu dWsNCnJpYmFzX3BlZHJvQGhvdG1haWwuY29tDQpyaWMuZ29kZW5ob0B4YWN0YS5jby5ueg0Kcmlj aGFyZEBjeWJlcmpvdXJuYWwub3JnDQpyaWNoYXJkcmFwaWVyQG5ldHNjYXBlLm5ldA0Kcmljay5i YWlsZXlAbWFyaW5lLmNzaXJvLmF1DQpyaWNtb29yZUBlZm9ydHJlc3MuY29tDQpyaWdodHMuYWxl cnRAM3dlYi5uZXQNCnJpdGFAaW1ldC5odQ0Kcmoua2xvc2VAc21zLmVkLmFjLnVrDQpyamJzLXVz ZW5ldEBwdWJsaWMubWFueG9tZS5vcmcNCnJtYXNyaUBsZWIubmV0DQpybmljb2xsQGJpZ3BvbmQu bmV0LmF1DQpyb2IuZC5oaWxsaWVyQHRyYW5zcG9ydC5xbGQuZ292LmF1DQpyb2JAbXZlLmNvbQ0K cm9iZXJ0X2J1dGNoa29AY2FjZC51c2NvdXJ0cy5nb3YNCnJvYmluLm4uYmFybG93QHRyYW5zcG9y dC5xbGQuZ292LmF1DQpyb2RyaWdvX2JyYXoyQHlhaG9vLmNvbQ0Kcm9nZXJfYmFsZHdpbkB5YWhv by5jb20NCnJvbUBkZWF0aHN0YXIubGlzLmNjaC5jb20NCnJvbWFuQHNvbmdkb2cuZXNraW1vLmNv bQ0Kcm9vdEBtbWwyLm1pZHdlc3QtbWljcm93YXZlLmx0ZC51aw0Kcm9zYXBoaWxpYUB3ZWJ0di5u ZXQNCnJvc3NvdkB5YWhvby5jb20NCnJveS5rb3VkYUBhaXN0LmdvLmpwDQpyb3lhbGFuY2VzdHJ5 QG1zbi5jb20NCnJveWNlLmJyb3duQHNkLnFsZC5nb3YuYXUNCnJzbWl0aEBwZWFybC50dWZ0cy5l ZHUNCnJ0YXlsb3JAcHJvZnNvbmxpbmUuZWR1DQpydWRhQGljcy5tdW5pLmN6DQpydXBlcnRAbWVk aWFwb3J0Lm9yZw0KcnVzc0BwZXJuZXVzLmNvbQ0KcnVzc0B0YXNtYW4ubmV0LmF1DQpyd2VzbGV5 QG96ZW1haWwuY29tLmF1DQpyd3Vlc3RAaXgubmV0Y29tLmNvbQ0Kcy5tYXVkZUBtYWlsZXhjaXRl LmNvbQ0Kc19tb3RvcnNAbmV0dmlzaW9uLm5ldC5pbA0Kc195ZXNoYXlhQG9mZXJhdm5pci5jby5p bA0Kc2FpLnNoYW5rYXJAc2llbWVucy5jb20NCnNhaWxnZWFyc0Bza3luZXQuYmUNCnNhaWxzQHNw ZWVkc2FpbHMuY28udWsNCnNha3dveWFAaG90bWFpbC5jb20NCnNhbGVzQGNhcmRzdG9uZS5jb20N CnNhbGVzQGNoYXZhbC5jb20uYXUNCnNhbGVzQGRpdmluZS1hcnQuY29tDQpzYWxlc0ByaWJib24u bmV0LmF1DQpzYW5qb3lAbXJhby5jYW0uYWMudWsNCnNhcmEud2Fyd2lja0B4YWN0YS5jby5ueg0K c2NhbmxhbkBzdW4uYmlnLm5ldC5hdQ0Kc2NhbmxvbkB0aGVodWIuY29tLmF1DQpzY2Nqc0B3aW50 ZWMuYWMubnoNCnNjZWV0aDBAeWFob28uY29tDQpzY2hhZkB1bmktZ3JlaWZzd2FsZC5kZQ0Kc2No bWFwQHNjaG1hcC5jb20uYXUNCnNjam9uZXNAdGhvci5zZHJjLmNvbQ0Kc2NvYnJvd25AY2hjLmVk dQ0Kc2NvdHRAaGVsc2JyZXRoLm9yZw0Kc2NvdHR3QGNvZGVyaXRlLmNvbQ0Kc2VhaG9yc2VAb2R5 c3NlZS5uZXQNCnNlY3JldGFyaWF0QGFwcm5ldC5vcmcNCnNlY3JldGFyeUBhbXJhbnN3LmFzbi5h dQ0Kc2VtYXJhbmdAc2QucWxkLmdvdi5hdQ0Kc2VuZG1haWwtYnVnc0BzZW5kbWFpbC5vcmcNCnNl bnRyaWVzLmxpZ2h0QGluYW1lLmNvbQ0Kc2VvdWxAc2QucWxkLmdvdi5hdQ0Kc2VyZ2VpMDFAZWFy dGhsaW5rLm5ldA0Kc2ZzYkBncmFmZml0aS5uZXQNCnNoYWRvd0BkZW1lbnRpYS5vcmcNCnNoYW5n aGFpQHNkLnFsZC5nb3YuYXUNCnNoYW5ub24uYmFyYmVyQG15cmVhbGJveC5jb20NCnNoYW5ub24u a2VyckBxbGRzZXJ2aWNlcy5xbGQuZ292LmF1DQpzaGFycEBtYXRoLmdlb2wuc2MuZWR1DQpzaGF5 ZXNAZHVuZWxtLm9yZy51aw0Kc2hpbmVAbmV0LXRlY2guY29tLmF1DQpzaG9laS5mcmFuY2VAc2hv ZWkuZnINCnNob2VpQG1vdG9wb2wucGwNCnNob2VpQHNob2VpLmNvbS5icg0Kc2lnQG1hdGhpZS5j eA0Kc2lsaWNvbmVwaGlsQGJ0b3BlbndvcmxkLnJlbW92ZS5jb20NCnNpbW9uQG5yMXdlYnJlc291 cmNlLmNvbQ0Kc2luZXVzQGhvdG1haWwuY29tDQpzanVkZEBubWdtZW50b20uZGVtb24uY28udWsN CnNrZWxsaXNoQGNvbWNhc3QubmV0DQpza2xvc0B2aXJ0dWFsb2xvZ3kuY29tDQpza3lsaW5lLW93 bmVyQGFzdHJvbWF4LmNvbQ0Kc2xheXRvbl9qQHlhaG9vLmNvbQ0Kc2xwcmFjaEBrb3QucG9sdGF2 YS51YQ0Kc29uamlhLmNhbXBiZWxsQHhhY3RhLmNvLm56DQpzb25zX29mX2F0cmV1c0Bob3RtYWls LmNvbQ0Kc29waGlhbW9udGVsbGluYUBtYWlsYm94LmNvbQ0Kc294d2VsbEBjZW50cmFsLm11cmRv Y2guZWR1LmF1DQpzcGFyaGF3azJAbnRsd29ybGQuY29tDQpzcGVjdHJhQHZpYy5hdXN0cmFsaXMu Y29tLmF1DQpzcGVuY2VyLmcubmlnaHRpbmdhbGVAdHJhbnNwb3J0LnFsZC5nb3YuYXUNCnNwc2pw a0BwYW50aGVyLmdzdS5lZHUNCnNwdWNrQGNsLnVoLmVkdQ0Kc3E3QGcyLnBibS5jb20NCnNyaXZh c3RhQGRlYmlhbi5vcmcNCnNzby5lZGl0b3JpYWxAcmFpbmJvdy5uZXQuYXUNCnN0ZXBoZW4uaGlu ZEBpbmQuYWxzdG9tLmNvbQ0Kc3RlcGhlbi5tb3JpYXJpdHlAc2QucWxkLmdvdi5hdQ0Kc3Rlcm5l c2tAbWFja2F5Lm5ldC5hdQ0Kc3RldmNAbm1nbW5oYy5kZW1vbi5jby51aw0Kc3RldmUubWluc2xv d0BxZmxlZXQucWxkLmdvdi5hdQ0Kc3RldmVrQG9zYS5jb20NCnN0ZXZlbEBnbG9iYWwuY28uemEN CnN0ZXZlbEBtY21vdG9yLmNvLnphDQpzdGV2ZW1jQGNvbnN1bHQtZWNvLm5kaXJlY3QuY28udWsN CnN0ZXZlbnNrYWFuaW5nQHlhaG9vLmNvbQ0Kc3RldnBoZW5AbXV0dWFsYWlkLm9yZw0Kc3RpZWJl bEBnbXguZGUNCnN0b2Nyb3dAYmlncG9uZC5jb20NCnN0cmFkc0B0bWlzbmV0LmNvbQ0Kc3RyaWRl ckBmb3JuaXRzLmNvbQ0Kc3R1ZGlvQGNoYXZhbC5jb20uYXUNCnN1Ym1pdEBidWdzLmRlYmlhbi5v cmcNCnN1bm55b2lsQG1zMzUuaGluZXQubmV0DQpzdW5zdGF0ZUBzdW5zdGF0ZWNlbWVudC5jb20u YXUNCnN1cGVyanVhbjY3QGhvdG1haWwuY29tDQpzdXBwb3J0QHJpYmJvbi5uZXQuYXUNCnN1cHJl bWUtc2FpbHNAc2lvbC5uZXQNCnN2YW5hbGxlbkBtdnBzLm9yZw0Kc3dpZnR2aUBhb2wuY29tDQpz d292Y2NAaG90bWFpbC5jb20NCnN6NkBnMi5wYm0uY29tDQp0LnVzZS5sb2NrZG93bkBibGFja2hv bGUuZG8tbm90DQp0NDhneGFvQHRwdHM3LnNlZWQubmV0LnR3DQp0YTJlZW5lQGNvbWNhc3QuY29t DQp0YWljeXB3YW5pQGhvdG1haWwuY29tDQp0YWl3YW5Ac2QucWxkLmdvdi5hdQ0KdGJ1cmdoYXJk dEBpZ2Mub3JnDQp0ZWNodGFwZUB5YWhvby5jb20NCnRlbGVtQHBvc3QudGF1LmFjLmlsDQp0ZmxA cHNwLmNvLnVrDQp0ZnB3YXJlekB4czRhbGwubmwNCnRoYWJ1cEBwaXhpZS5jby56YQ0KdGhlX3dp bmdzX2NvQGhvdG1haWwuY29tDQp0aGViaWdzaG90QGhvdC1zaG90LmNvbQ0KdGhlbWFkbWVuQGFv bC5jb20NCnRoZW1hZG1lbkBqdW5vLmNvbQ0KdGhlb2RvckBpbmV0LnVuaTIuZGsNCnRob21taWVf ZEBob3RtYWlsLmNvbQ0KdGhzbWFsbEBwb3dlcnVwLmNvbS5hdQ0KdGh1bmRlckBuYXBhbmV0Lm5l dA0KdGlja2V0dHlib29AbWFpbDJvb3BzLmNvbQ0KdGltY21heUByZW1vdmV0aGlzLmdvdC5uZXQN CnRrNmZub2FtdXI5NWV3YTFAaGlnaGxhbmQtdHJvcGh5LmRlbW9uLmNvLnVrDQp0a2luZ0BmaWxx dWlwLmNvbS5hdQ0KdGxob2ZmQGVhcnRobGluay5uZXQNCnRtc0BiYmMuY28udWsNCnRva3lvQHNk LnFsZC5nb3YuYXUNCnRvbTE4NjRAeWFob28uY29tDQp0b21AaW9kOTUuY29tDQp0b21idXJyb3dz QGNlbWVudGFpZC5jb20NCnRvbml0aW9AbGl4LmludGVyY29tLmVzDQp0b255LmFsZGVydG9uQHNk LnFsZC5nb3YuYXUNCnRvbnkuYmFra2VyQHFsZHNlcnZpY2VzLnFsZC5nb3YuYXUNCnRvbnkuZGF2 aXNAZ3JhY2UuY29tDQp0b255dnNtaXRoQGNvbXB1c2VydmUuY29tDQp0cjVAcGJtLmNvbQ0KdHJh Y2V5LmdpbG1vcmVAc2QucWxkLmdvdi5hdQ0KdHJlc2NvdHRAcnVyYWxmcmVlLm5ldA0KdHJldm9y LmNvcnRob3JuZUBzZC5xbGQuZ292LmF1DQp0cmlydWdieUBjYWxpcGgubmV0DQp0c2tpcnZpbkBr aWxsZmlsZS5vcmcNCnR0dXJuZXJAaG91c3Rvbi5yci5jb20NCnR1YXRoYS5maW9ubkBpbmFtZS5j b20NCnR1Y2tpQGVpc2EubmV0LmF1DQp0dXVsaWtraS5wYXR1cmlAaGVsaWEuZmkNCnR3Y21hY2th eUBvcHR1c25ldC5jb20uYXUNCnR5LnRheWxvckBxbGRzZXJ2aWNlcy5xbGQuZ292LmF1DQp0eWtl QGNoYXJpb3QubmV0LmF1DQp0eXRzb0BtaXQuZWR1DQp0em9ydG9Ab3RlbmV0LmdyDQp1MGY5OEAx c3Rjb25uZWN0LmNvbQ0KdWZvX2NoYXJsaWUxN0Bob3RtYWlsLmNvbQ0KdWtAdWtzcGFpbi5jb20N CnVuaXZlcnNhbC5icm90aGVyaG9vZEBpbmFtZS5jb20NCnVubmNAYWRhbS1iYXJyYXR0Lm9yZy51 aw0KdXBicEBtYXJ5c2lhLmNvbQ0KdXNlbGVzc2VhdGVyMjAwMUBob3RtYWlsLmNvbQ0KdXNlbmV0 MDMwNjAyQGFsbW9zdGluc3BpcmVkLmNvLnVrDQp1c2VuZXRAaGdhcmRuZXIuY29tDQp1c2VuZXRA aWR1bm5vLm9yZy5pbnZhbGlkDQp1c2VuZXRAbWFydGluYy5tZS51aw0KdXNlbmV0QG1hdGhpZS5j eA0KdXNlbmV0QHBhcHBuYXNlLmNvLnVrDQp1c2VyNEBtb2J5dXMuY29tDQp1c2VyNUBtb2J5dXMu Y29tDQp1c2VyaW5udGRvbWFpbkBudGRvbWFpbi5kZQ0KdXNlcm9ubGludXhtYWNoaW5lQGxpbnV4 c2VydmVyLmNvbQ0KdmFtcGlyZWh1bnRlcjQyb0Bhb2wuY29tDQp2YW5icmVtdEBuZXRzY2FwZS5u ZXQNCnZlZGVsZXJAcmFjZW5hdmlnYXRvcnMuY29tDQp2ZXp5YXNoQHBvd2VydXAuY29tLmF1DQp2 aWFAbWFpbC51c3lkLmVkdS5hdQ0KdmljdG9yaWFAY29sbGVjdGlibGVzdWsuY29tDQp2aWN0b3J5 QGludGVydmVsYS5zaQ0KdmluY2VoQHNvZnRyb2NrLmNvLnVrDQp2aXNzY2hlckBlZHRlLnV0d2Vu dGUubmwNCnZpdG9yaWFAY250LmVzDQp2bGNrQHBjLmphcmluZy5teQ0KdnZtQGNzc2MudGF0LnJ1 DQp3LnN0ZWZmZW5AZHdlLmNzaXJvLmF1DQp3YWRsZXlAbWFpbC5jb20NCndhZmNkY0BpZ2Mub3Jn DQp3YWx0MG1hdGljQGFvbC5jb20NCndhcm5vY2tkQGFvbC5jb20NCndheHh6b21iaWVAaG90bWFp bC5jb20NCndheW5lQGVic3BsLmNvbQ0Kd2ViZm9ydW1zdXNlckBtYWNyb21lZGlhLmNvbQ0Kd2Vi bWFzdGVyQGFmbHEuY29tLmF1DQp3ZWJtYXN0ZXJAY3dhc3BlLmRlbW9uLmNvLnVrDQp3ZWJtYXN0 ZXJAbW9ieTU4LmNvbQ0Kd2VibWFzdGVyQHNjaG5ld3Mub3JnLnVrDQp3ZWJtYXN0ZXJAc2ZsYXJl LmNvbQ0Kd2VibWFzdGVyQHlvdXRoLmNvLnphDQp3ZWJtYXN0ZXJAemUuc2x1cHNrLnBsDQp3ZWJw cmVtQGdvdi5vbi5jYQ0Kd2hlcmVzdGhlcHJvemFjQGhvdG1haWwuY29tDQp3aG9sZWJlbkBuaXUu ZWR1DQp3b3JrZXItYS1pbmZvcy1pdEBhaW5mb3MuY2ENCnd2ZTQ3cGY0QHlhaG9vLmNvbQ0Kd3d3 LXAzcC1wb2xpY3lAdzMub3JnDQp3d3cuc2FsZXNAZGFyYmkuY28ubnoNCnd3d0BwaHlzaWNzLmds YS5hYy51aw0KeEB0YW8uY2ENCnlhY2NhLnpjY0BiaWdwb25kLmNvbQ0KeWFmZmFnZUBuZXR2aXNp b24ubmV0LmlsDQp5YXJyaWRvQGFvbC5jb20NCnlkazEyNjNAaGFubWFpbC5uZXQNCnllcm9uZ2F2 aWRlb0Bhb2wuY29tDQp5b3JkYW5AZ3l1cmNoZXYuY29tDQp5b3VAeW91ci1uYW1lLmNvbQ0KeW91 dGhAYmlnZm9vdC5jb20NCnlvdXRoZm9yY2VAcGVjaHVyY2huZXQuY28uemENCnlyMy40MTYzMTQ1 OTVAbmV3cy5wcmltdXMuY2ENCnl1cml5QHVuaS1zdmlzaHRvdi5iZw0KemlsbG1lcmVtb3dlcnNA bXNhYS5jb20uYXUNCnppbTEyM0BiaWdwb25kLmNvbQ0Kem9ya0ByaXZlcm5ldC5jb20uYXUNCnpy YWpidW5AaG90bWFpbC5jb20= --===_SecAtt_000_1foqrgxdsvxpwb ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tony34@hotmail.com Thu Jul 17 19:37:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPEF-0002Hq-01 for ; Wed, 23 Jul 2003 21:24:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:24:47 +0200 (CEST) Received: (qmail 24695 invoked by uid 65534); 17 Jul 2003 19:35:58 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010) with SMTP; 17 Jul 2003 21:35:58 +0200 Received: by moria.seul.org (Postfix) id E807733B5B; Thu, 17 Jul 2003 15:35:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 166D133B6E; Thu, 17 Jul 2003 15:35:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 63A0533B5B for ; Thu, 17 Jul 2003 15:35:53 -0400 (EDT) Received: from 210.78.22.45 (unknown [210.78.22.15]) by belegost.mit.edu (Postfix) with ESMTP id ACC49121A37 for ; Thu, 17 Jul 2003 15:35:52 -0400 (EDT) From: tony34@hotmail.com To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Order Receipt Date: Thu, 17 Jul 03 17:37:41 Öйú±ê׼ʱ¼ä MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= "----=_NextPart_000_007F_EAA7165A.82E4409F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20030717193552.ACC49121A37@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=8.45; FROM_ENDS_IN_NUMS HEADER_8BITS INVALID_DATE NO_REAL_NAME SEMIFORGED_HOTMAIL_RCVD) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ------=_NextPart_000_007F_EAA7165A.82E4409F Content-Type: text/html Content-Transfer-Encoding: base64 DQo8Ym9keT4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtm b250LWZhbWlseTpBcmlhbCI+cGxlYXNlIG5vdGUgdG8gc2VuZCBBTEwgUkVQTFkgZS1tYWls IGRpcmVjdCB0byBvdXIgDQpTYWxlcyBSZXByZXNlbnRhdGl2ZSBhdDogPG86cD4NCjwvbzpw Pg0KPC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0K MTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48YSBocmVmPSJtYWlsdG86UXVlc3Rpb25zQFBl cmZlY3RXYXRjaFBpZWNlLmNvbSI+UXVlc3Rpb25zQFBlcmZlY3RXYXRjaFBpZWNlLmNvbTwv YT48bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tYmlk aS1mb250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPiZuYnNwOzxvOnA+DQo8 L286cD4NCjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpLCZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91IGZvciBleHByZXNzaW5nIGludGVyZXN0IGlu IA0KQVRHV1Mgd2F0Y2hlcy48YnI+DQpXZSB3b3VsZCBsaWtlIHRvIHRha2UgdGhpcyBvcHBv cnR1bml0eSB0byBvZmZlciB5b3Ugb3VyIGZpbmUgc2VsZWN0aW9uIG9mIA0KSXRhbGlhbiBj cmFmdGVkIFJvbGV4IFRpbWVwaWVjZXMuJm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3UgY2FuIHZpZXcgb3VyIGxhcmdlIHNl bGVjdGlvbiBvZiANClJvbGV4ZXMgKGluY2x1ZGluZyBCcmVpdGxpbmcsIFRhZyBIZXVlciwg Q2FydGllciBldGMpIGF0OjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUt YnJlYWsiPg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJodHRwOi8vd3d3LnBlcmZlY3R3YXRjaHBpZWNlLmNvbS8iPnd3 dy5QZXJmZWN0V2F0Y2hQaWVjZS5jb208L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZvciBhbGwgb3JkZXJzIHBsYWNlZCBpbiB0aGUgbW9udGgg b2YgDQpKdWx5LCA8Yj5hbGwgc2hpcHBpbmcgYW5kIGhhbmRsaW5nIGNoYXJnZXMgd2lsbCBi ZSBmcmVlPC9iPi4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFzIHdlIGFyZSB0aGUgZGlyZWN0IG1hbnVmYWN0dXJlcnMsIHlv dSANCmFyZSBndWFyYW50ZWVkIG9mIGxvd2VzdCBwcmljZXMgYW5kIGhpZ2hlc3QgcXVhbGl0 eSBlYWNoIGFuZCBldmVyeSB0aW1lIHlvdSANCnB1cmNoYXNlIGZyb20gdXMuJm5ic3A7PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ug bWF5IGFsc28gYmUgaW50ZXJlc3RlZCB0byBrbm93IHRoYXQgDQp3ZSBoYXZlIHRoZSBmb2xs b3dpbmcgYnJhbmRzIGF2YWlsYWJsZSBpbiBvdXIgd2lkZSBzZWxlY3Rpb24gYXMgd2VsbDo8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCjEuIExlYXRoZXIgYmFuZCBEYXl0b25hIChsYWRpZXMgYW5kIG1lbqGvcyk8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIuIEJsYW5j cGFpbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+My4gRm9ydGlzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj40LiBKYWVnZXIgTGVDb3V0cmU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjUuIExvbmdpbmVzPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj42LiBNb250IEJsYW5jPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj43LiBN b3ZhZG88L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjguIE9yaXM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjkuIFJvZ2VyIER1YnVpczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTAuIFVseXNzZTwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTEuIFplbml0aDwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTIuIEF1ZGVtYXIg UGlndWV0PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4xMy4gQnJlaXRsaW5nPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4xNC4gQnZnbGFyaTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTUuIENhcnRpZXI8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjE2LiBDb3J1bTwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTcuIER1bmhp bGw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjE4LiBGcmFuY2sgTXVsbGVyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4xOS4gR2VyYXJkIFBlcnJlZ2F1eDwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjAuIElXQzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjEuIElXQzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjIuIFBh bmVyYWk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjIzLiBQYXRlayBQaGlsaXBwZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+MjQuIFRhZyBIZXVlcjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjUuIFZhY2hlcm9uIENvbnN0YW50 aW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgeW91IHNlZSBhbnl0aGluZyB0aGF0IG1pZ2h0IGludGVyZXN0IA0KeW91LCBv ciBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLCBwbGVhc2UgZG9uJ3QgaGVzaXRhdGUgdG8g dmlzaXQgb3VyIHdlYnNpdGUgDQphdDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cucGVyZmVjdHdhdGNo cGllY2UuY29tLyI+d3d3LlBlcmZlY3RXYXRjaFBpZWNlLmNvbTwvYT48YnI+DQpJIGNlcnRh aW5seSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHlvdS48YnI+DQpCZXN0IHJlZ2Fy ZHMsPGJyPg0KPGJyPg0KQ2FsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQpEaXZpc2lvbiBTYWxlcyBNYW5hZ2VyPGJyPg0KQVRH V1MmbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlh bCI+Jm5ic3A7PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCI+ WW91IA0KcmVjZWl2ZWQgdGhpcyBlbWFpbCBiZWNhdXNlIHlvdXIgaGF2ZSBwcmV2aW91cyBw dXJjaGFzZWQgZnJvbSwgb3IgaW5xdWlyZWQgYWJvdXQgDQpvdXIgcHJvZHVjdCBsaW5lIHVu ZGVyIEFUR1dTLiBJZiB5b3UgZG8gbm90IHdhbnQgdG8gcmVjZWl2ZSBmdXJ0aGVyIG1haWxp bmdzIA0KZnJvbSBBVEdXUywgdW5zdWJzY3JpYmUgYnkgc2VuZGluZyBhbiBlbWFpbCB3aXRo IHRoZSB0aXRsZSBoZWFkaW5nOiBERUxFVEUgaW4gDQp0aGUgc3ViamVjdCBsaW5lIHRvIDxh IGhyZWY9Im1haWx0bzp1bnN1YnNjcmliZUBQZXJmZWN0V2F0Y2hQaWVjZS5jb20iPnVuc3Vi c2NyaWJlQFBlcmZlY3RXYXRjaFBpZWNlLmNvbTwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+DQo8L286cD4NCjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0KMTIuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj5wbGVhc2Ugbm90ZSB0byBzZW5kIEFMTCBSRVBMWSBlLW1haWwg ZGlyZWN0IHRvIG91ciANClNhbGVzIFJlcHJlc2VudGF0aXZlIGF0OjxvOnA+DQo8L286cD4N Cjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEy LjBwdDtmb250LWZhbWlseTpBcmlhbCI+PGEgaHJlZj0ibWFpbHRvOlF1ZXN0aW9uc0BQZXJm ZWN0V2F0Y2hQaWVjZS5jb20iPlF1ZXN0aW9uc0BQZXJmZWN0V2F0Y2hQaWVjZS5jb208L2E+ PG86cD4NCjwvbzpwPg0KPC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGkt Zm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj4mbmJzcDs8bzpwPg0KPC9v OnA+DQo8L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9wPg0KDQo8L2JvZHk+DQoN Cg0KICAgIA== ------=_NextPart_000_007F_EAA7165A.82E4409F-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From baldwingozie@indiatimes.com Sat Jul 19 15:49:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPFz-0002Hq-00 for ; Wed, 23 Jul 2003 21:26:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:26:35 +0200 (CEST) Received: (qmail 25158 invoked by uid 65534); 19 Jul 2003 13:49:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 19 Jul 2003 15:49:14 +0200 Received: by moria.seul.org (Postfix) id 8D57533B81; Sat, 19 Jul 2003 09:49:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A013F33B85; Sat, 19 Jul 2003 09:49:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from emztd2928.com (unknown [81.199.85.54]) by moria.seul.org (Postfix) with SMTP id 880D233B81 for ; Sat, 19 Jul 2003 09:49:06 -0400 (EDT) From: "baldwin gozie" To: f-cpu@seul.org Date: Sat, 19 Jul 2003 06:49:39 -0700 Subject: [f-cpu] AID X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===_SecAtt_000_1ffyjoilelpift" Message-Id: <20030719134906.880D233B81@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --===_SecAtt_000_1ffyjoilelpift Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DearSir=2C I am Mr Onuigbo Baldwin Gozie=2C Bank Manager of Diamond BANK =2C Lagos Branch=2E I have urgent and very confidential business proposition for you Mr=2E Barry Kelly made a numbered time =28Fixed=29 deposited for twelve calendar months=2C valued at US$25=2C000=2C000=2E00 =28Twenty-five Million Dollars=29 in my branch=2E Upon maturity=2C I sent a routine notification to his forwarding address but got no reply=2E After a month=2C we sent a reminder and finally we discovered from his contract employers=2C Nigerian National Petroleum Corporation that Mr=2E Barry Kelly died from an automobile accident=2E On further investigation=2C I found out that he did not leave a WILL and all attempts to trace his next of kin were fruitless=2E I therefore made further investigation and discovered that Mr=2E Barry Kelly did not declare any next of kin in all his official documents=2C including his Bank Deposit paperwork=2E This sum of US$25=2C000=2C000=2E00 is still sitting in the Bank and the interest is being rolled over with the principal sum at the end of each year=2E No one will come forward to claim it=2E According to the Nigerian Law=2C at the expiration of 6{Six} years=2C the money will revert to the ownership of the Nigerian Government if nobody applies to claim the funds=2EConsequently=2C my proposal is that I will like you as a foreigner to stand in as the next of kin to Mr=2E Barry Kelly so that the fruits of this old man's labor will not get into the hands of some corrupt government officials=2E This is simple=3B 1=29 I will like you to provide me immediately with your full names and address so that the attorney will prepare the necessary documents and affidavits=2C which will put you in place as the next of kin=2E 2=29 We shall employ the services of two attorneys for drafting and notarization of the WILL and obtain the necessary documents and letter of probate=2Fadministration in your favor for the transfer=2E 3=29 A bank account in any part of the world=2C which you provide=2C will then facilitate the transfer of this money to you as the beneficiary=2Fnext of kin of Mr=2EBarry Kelly=2E The money will be paid into your account for us to share in the ratio of 75% for me and 20% for you then 5% will be set aside for any expenses that may occure during the transfer process=2E There is no risk at all as all the paperwork for this transaction will be done by the attorney and my position as the Branch Manager guarantees the successful execution of this transaction=2E If you are interested=2C please reply immediately via the private email address below=2EUpon your response=2CI shall then provide you with more details and relevant documents that will help you understand=2E Please observe utmost confidentiality=2C and rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country=2E Awaiting your urgent reply via email and please your reply should be sent to baldwingozie77=40indiatimes=2Ecom and also=2C my contact phone number is 234-80-37218237=2C feel free to call me at anytime or if you want me to call you=2C then furnish me with your phone number =2E Thanks and regards Baldwin Gozie Esq=2E --===_SecAtt_000_1ffyjoilelpift Content-Type: application/octet-stream; name="blast..txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="blast..txt" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jameskyari@netscape.net Sun Jul 20 11:16:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPGj-0002Hq-00 for ; Wed, 23 Jul 2003 21:27:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:27:21 +0200 (CEST) Received: (qmail 618 invoked by uid 65534); 20 Jul 2003 09:11:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 20 Jul 2003 11:11:41 +0200 Received: by moria.seul.org (Postfix) id 22A9C33C1A; Sun, 20 Jul 2003 05:11:40 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 25D9A33C21; Sun, 20 Jul 2003 05:11:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 69B1E33C1A for ; Sun, 20 Jul 2003 05:11:38 -0400 (EDT) Received: (qmail 55061 invoked from network); 20 Jul 2003 09:13:34 -0000 Received: from unknown (HELO netscape540.com) (24.132.241.135) by bettik.munge.net with SMTP; 20 Jul 2003 09:13:34 -0000 From: james kyari To: f-cpu@seul.org Subject: [f-cpu] UGENT ASSISTANT Date: Sun, 20 Jul 2003 11:16:11 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7fd94598-baa3-11d7-b3cb-0000f8d87dd1" Message-Id: <20030720091138.69B1E33C1A@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --7fd94598-baa3-11d7-b3cb-0000f8d87dd1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear friend, Compliment of the day, I am JAMES KYARI, The son of late General Kubwa Kyari = of the Democratic Republic of Congo. My father was a General in the Congolese Army. In his position (My father) = with the office of the presidentcy during the regime of Laurent Kabila, he = was assigned on a secret mission to source and acquire arms internationally = in order to strengthen the Government forces against the rebels, which = already had the support of Rwandan and Uganda Army. Meanwhile, he was still negotiating for the purchase of the arms, he received = on the 16th January 2001 news of the assassination of Laurent Kabila which = force him to call off the assignment and deposited the sum of US$12.5M, = Packed in a diplomatic case in a private security company in the Hague, the = Netherlands, though he registered the content as precious stones while the = real content is (US12.5M) meant for the purchase of arms for the Congolese = Army. My father went home for the funeral of the late president, but on his arrival = he was arrested, detained and tortured, unfortunately my father suffer = cardiac arrest and died on the 17th of March 2001. However,one of our = numerous visits, my mother and I paid him while in prison, my father was able = to reveal this secret to me and advice that i should proceed to the = Netherlands to claim the money, he handed me all the relevant documents that = will enable me claim the box from the security company.Already, I have made = my first visit to the security company and the document entitled to clear = this money is with a finance security company in Holland. On our arrival in the Netherlands few months ago, we sought for political = asylum; which was granted. My mother and I are making frantic effort on the = best way to handle this money. We sought advice from an attorney who advised = that we must seek for a trustworthy foreign business partner whom can invest = this fund in a profitable venture. This we view as the best option because = our refugee status dose not permit us to operate a bank account, hence we = seek your assistance and hope you could be trusted. I got your contact from the commercial section of the congolese embassy in = Belgium. Meanwhile, I sincerely ask for your assistance to get this money = through your account, Your share for assisting us will be 25% of the total = sum, 5% will be use for upsetting all the expenses incurred in the course of = concluding this venture and the remaining 70% that will be for me and my = family. Also you stand to gain from any investment you might introduce us = into after the conclusion of the transfer. Please keep this confidential until we finalize and get this money into your = account for security reasons. This is my e-mail address you can reach me:(jameskyari@netscape.net) Thanks and GOD bless. MR, JAMES KYARI ---------------------------------------------- This email is send by "Email Sender Express" --7fd94598-baa3-11d7-b3cb-0000f8d87dd1-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From devik@cdi.cz Mon Jul 21 07:45:53 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPHe-0002Hq-00 for ; Wed, 23 Jul 2003 21:28:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:28:18 +0200 (CEST) Received: (qmail 30347 invoked by uid 65534); 21 Jul 2003 05:46:19 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 21 Jul 2003 07:46:19 +0200 Received: by moria.seul.org (Postfix) id 73AE233B88; Mon, 21 Jul 2003 01:46:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A221A33C63; Mon, 21 Jul 2003 01:46:16 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) by moria.seul.org (Postfix) with ESMTP id 9330333B88 for ; Mon, 21 Jul 2003 01:46:15 -0400 (EDT) Received: from gprs1-37.eurotel.cz ([160.218.144.37] helo=devix) by luxik.cdi.cz with asmtp (Exim 3.34 #3) id 19eTUx-0005Z6-00 for f-cpu@seul.org; Mon, 21 Jul 2003 07:46:13 +0200 Received: from devik (helo=localhost) by devix with local-esmtp (Exim 3.16 #8) id 19eTUf-0007vb-00 for f-cpu@seul.org; Mon, 21 Jul 2003 07:45:53 +0200 Date: Mon, 21 Jul 2003 07:45:53 +0200 (CEST) From: devik X-X-Sender: To: Subject: Re: [f-cpu] "There is another system" In-Reply-To: <3F1AC261.20906@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi, it has nothing to do with f-cpu. It is modular control system for data gathering. Just similar name ... ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Sun, 20 Jul 2003, Yann Guidon wrote: > once in a while, i type "F-CPU" in google to see how things go ... > and this time, i found http://www.elsaco.cz/produkty/hw2/fcpu.htm > > any remark ? > > YG > > ************************************************************* > To unsubscribe, send an e-mail to majordomo@seul.org with > unsubscribe f-cpu in the body. http://f-cpu.seul.org/ > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Jul 21 17:10:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19fPIN-0002Hq-01 for ; Wed, 23 Jul 2003 21:29:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 23 Jul 2003 21:29:03 +0200 (CEST) Received: (qmail 12302 invoked by uid 65534); 21 Jul 2003 15:04:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 21 Jul 2003 17:04:41 +0200 Received: by moria.seul.org (Postfix) id 9A7E233B4D; Mon, 21 Jul 2003 11:04:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CCCC633C61; Mon, 21 Jul 2003 11:04:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id C2F1033B4D for ; Mon, 21 Jul 2003 11:04:37 -0400 (EDT) Received: from f-cpu.org (lcbv2-1-51.n.club-internet.fr [213.44.12.51]) by relay-1v.club-internet.fr (Postfix) with ESMTP id E64EE787; Mon, 21 Jul 2003 17:04:35 +0200 (CEST) Message-ID: <3F1C026B.8060406@f-cpu.org> Date: Mon, 21 Jul 2003 17:10:35 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: Re: [f-cpu] "There is another system" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi ! devik wrote: >Hi, it has nothing to do with f-cpu. It is modular >control system for data gathering. Just similar name ... > thank you, i have read it too :-) the real problem is the whole trademark thing, F-CPU is "registered" in France (and no other country because it is too expensive). The "duty" of the trademark co-owners (several french guys including me) is to actively check that it is used correctly, otherwise the brand might lose legal value. here, and with the other links as well, there is nothing to do, because these are german, spanish and tchech systems and the name and logo F-CPU are only registered in France. However i'm particularly worried about the Siemens boxes because they are likely to be sold in France as well, and there is the exact same spelling (with the dash). And they certainly have wealthy lawyers. Don't forget that my goal is to protect our project. This includes passive and active measures, dictated by the french law and jurisprudence. It was very dificult to organise the registering of the brand, but we suceeded in order to protect the name that we had established. It prevents anybody from using the F-CPU name against our will. If we don't enforce this right, it can be voided. And if it becomes void, not only our efforts will become vain, but the project can be threatened. These are the stakes. Now, the goal is not to chase other projects and go to court all the time, we are gentlemen. But we must reach agreements, and face reality. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad42967853@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19grGR-0003lo-00 for ; Sun, 27 Jul 2003 21:33:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 27 Jul 2003 21:33:03 +0200 (CEST) Received: (qmail 30488 invoked by uid 65534); 27 Jul 2003 12:52:56 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 27 Jul 2003 14:52:56 +0200 Received: by moria.seul.org (Postfix) id 5FBFF33B7B; Sun, 27 Jul 2003 08:52:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B31733B7F; Sun, 27 Jul 2003 08:52:48 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id B2D0733B7B for ; Sun, 27 Jul 2003 08:52:47 -0400 (EDT) Received: from eXcuria.com (unknown [207.153.108.3]) by belegost.mit.edu (Postfix) with SMTP id B6E50121A36 for ; Sun, 27 Jul 2003 08:52:46 -0400 (EDT) Date: 7/27/2003 7:51:51 AM To: From: sale03 Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030727125246.B6E50121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://sale03.eXcuria.com/InkStore/ >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://sale03.eXcuria.com/DealerInfo/ This email was sent by a direct marketing service and so we will not receive direct replies to it. If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://sale03.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hajiamm@libero.it Wed Jul 30 17:13:04 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19iRh3-00009g-00 for ; Fri, 01 Aug 2003 06:39:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 01 Aug 2003 06:39:05 +0200 (CEST) Received: (qmail 17969 invoked by uid 65534); 30 Jul 2003 15:12:59 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Jul 2003 17:12:59 +0200 Received: by moria.seul.org (Postfix) id 1F29033B4B; Wed, 30 Jul 2003 11:12:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 824E033B5C; Wed, 30 Jul 2003 11:12:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 08CE833B4B for ; Wed, 30 Jul 2003 11:12:54 -0400 (EDT) Received: from n2now937.com (unknown [62.192.151.60]) by belegost.mit.edu (Postfix) with SMTP id CDC2A121A36 for ; Wed, 30 Jul 2003 11:12:45 -0400 (EDT) From: "mariam" To: f-cpu@seul.org Date: Wed, 30 Jul 2003 16:13:04 +0100 Subject: [f-cpu] KINDLY ASSIST ME X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030730151245.CDC2A121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hajia Mariam Abacha E-mail=3Ahajiamm=40libero=2Eit Kano - Nigeria=2E Hello=2C May l briefly introduce myself to you=2E I am hajia Mariam Abacha=2C the wife of the late Nigerian Head of State=2C General Sani Abacha who died on the 8th of June=2C1998=2E Ever since the death of my husband=2C my family has been facing a lot of problems mostly with the present Civilian Government=2E Consequently=2C my son -Mohammed Abacha has been under torture in detention for a sin he did not commit and made to make a lot of confessions as regards valuables=2C money inclusive that of my late husband entrusted in his hand forsafe-keeping=2E The latest is his confession on the US$700=2C000=2C000=2E00 =28Seven Hundred Million United States Dollars=29 cash his late father gave him for safe keeping=2E Please check Newswatch Magazine of May 8th=2F15th=2C 2000 issue on =5BWebsite=3Ahttp=3A=2F=2Fwww=2Enewswatchngr=2Ecom=5D to confirm the above story=2E Also the recent publication by THISDAY Newspaper on Thursday March 1st Edition=2C which London Court clear ways for more recovering of Abacha=B4s family looted money=2E Please confirm this issue on website=3A http=3A=2F=2Fwww=2Ethisdayonline=2Ecom=2C click the Archive=2F2001=2FMarch 2001=2FThursday March 1st=2E On these note=2C I deposited a total sum of US$40=2C300=2C000=2E00 =28Fourty Million =2Cthree hundred thousand United States Dollars=29 sometimes march last year with a Security company abroad =28name with held for now=29=2E Normally=2C we =28I and Mohammed Abacha=29 usually do such transaction=2C by first sending the money out by Cargo to a security ! company outside Nigeria=2C as photographic materials=2E And thereafter go to the security company for claim before transferring it to any bank of our choice=2E Presently=2C l can not travel out of Nigeria=2C because=2Cif you have gone through the above mentioned website address=2C you will see how My son=B4s confession have implicated my husband and infact the whole of my family=2E This has actually caused the Federal Government of Nigeria to confiscate our international passports=2C frozen every of my family member bank accounts both home and abroad=2C even our properties=2E My problem now is=2C l want someone that can assist me to move the US$40=2C300=2C000=2E000 =28Fourty Million =2Cthree hundred thousand United States Dollars=29 out from the Security Company=2C before Mohammed will open up to the Security Agents=2E To this regard l am soliciting for your assistance to claim the boxes containing the money from the Security Company and move the money to your coun! try=2E I shall be ready to negotiate with you any percentage you might want from the sum=2E On your advise l shall be ready to invest my own share of the sum in your country=2E I assure you that there will be no problems at all in the course of moving out the money Please kindly contact me on my e-mail=3A hajiamm=40libero=2Eit =2C I shall so much appreciate your immediate response for full details of the business which shall be given to you by my Lawyer=2C barrister Gozie Baldwin=2EYou should note also that my Lawyer=2C Barrister Gozie Baldwin shall handle all cases as regards this transaction=3Bas he is well abreast with this transaction for I do not have access to telephone lines now because they have been tossed by the security agents and my movement being monitored=2E Thanking you in anticipation to your kind understanding and cooperation=2E Please when replying send me your private telephone and fax numbers for the documents of the transaction=2E You can reply to the email address above=2E You can also reach my lawyer on his email address=3A gozie=2Ebaldwin1=40caramail=2Ecom Best Regards=2C Hajia Mariam Abacha ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hajiamm@libero.it Wed Jul 30 17:28:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19iRh8-00009g-00 for ; Fri, 01 Aug 2003 06:39:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 01 Aug 2003 06:39:10 +0200 (CEST) Received: (qmail 30201 invoked by uid 65534); 30 Jul 2003 15:28:42 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 30 Jul 2003 17:28:42 +0200 Received: by moria.seul.org (Postfix) id 4682C33B5C; Wed, 30 Jul 2003 11:28:39 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 159EE33B64; Wed, 30 Jul 2003 11:28:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 3DCB633B5C for ; Wed, 30 Jul 2003 11:28:38 -0400 (EDT) Received: from afzhg1051.com (unknown [62.192.151.60]) by belegost.mit.edu (Postfix) with SMTP id ACA7B121A36 for ; Wed, 30 Jul 2003 11:28:34 -0400 (EDT) From: "mariam" To: f-cpu@seul.org Date: Wed, 30 Jul 2003 16:28:52 +0100 Subject: [f-cpu] KINDLY ASSIST ME X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030730152834.ACA7B121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hajia Mariam Abacha E-mail=3Ahajiamm=40libero=2Eit Kano - Nigeria=2E Hello=2C May l briefly introduce myself to you=2E I am hajia Mariam Abacha=2C the wife of the late Nigerian Head of State=2C General Sani Abacha who died on the 8th of June=2C1998=2E Ever since the death of my husband=2C my family has been facing a lot of problems mostly with the present Civilian Government=2E Consequently=2C my son -Mohammed Abacha has been under torture in detention for a sin he did not commit and made to make a lot of confessions as regards valuables=2C money inclusive that of my late husband entrusted in his hand forsafe-keeping=2E The latest is his confession on the US$700=2C000=2C000=2E00 =28Seven Hundred Million United States Dollars=29 cash his late father gave him for safe keeping=2E Please check Newswatch Magazine of May 8th=2F15th=2C 2000 issue on =5BWebsite=3Ahttp=3A=2F=2Fwww=2Enewswatchngr=2Ecom=5D to confirm the above story=2E Also the recent publication by THISDAY Newspaper on Thursday March 1st Edition=2C which London Court clear ways for more recovering of Abacha=B4s family looted money=2E Please confirm this issue on website=3A http=3A=2F=2Fwww=2Ethisdayonline=2Ecom=2C click the Archive=2F2001=2FMarch 2001=2FThursday March 1st=2E On these note=2C I deposited a total sum of US$40=2C300=2C000=2E00 =28Fourty Million =2Cthree hundred thousand United States Dollars=29 sometimes march last year with a Security company abroad =28name with held for now=29=2E Normally=2C we =28I and Mohammed Abacha=29 usually do such transaction=2C by first sending the money out by Cargo to a security ! company outside Nigeria=2C as photographic materials=2E And thereafter go to the security company for claim before transferring it to any bank of our choice=2E Presently=2C l can not travel out of Nigeria=2C because=2Cif you have gone through the above mentioned website address=2C you will see how My son=B4s confession have implicated my husband and infact the whole of my family=2E This has actually caused the Federal Government of Nigeria to confiscate our international passports=2C frozen every of my family member bank accounts both home and abroad=2C even our properties=2E My problem now is=2C l want someone that can assist me to move the US$40=2C300=2C000=2E000 =28Fourty Million =2Cthree hundred thousand United States Dollars=29 out from the Security Company=2C before Mohammed will open up to the Security Agents=2E To this regard l am soliciting for your assistance to claim the boxes containing the money from the Security Company and move the money to your coun! try=2E I shall be ready to negotiate with you any percentage you might want from the sum=2E On your advise l shall be ready to invest my own share of the sum in your country=2E I assure you that there will be no problems at all in the course of moving out the money Please kindly contact me on my e-mail=3A hajiamm=40libero=2Eit =2C I shall so much appreciate your immediate response for full details of the business which shall be given to you by my Lawyer=2C barrister Gozie Baldwin=2EYou should note also that my Lawyer=2C Barrister Gozie Baldwin shall handle all cases as regards this transaction=3Bas he is well abreast with this transaction for I do not have access to telephone lines now because they have been tossed by the security agents and my movement being monitored=2E Thanking you in anticipation to your kind understanding and cooperation=2E Please when replying send me your private telephone and fax numbers for the documents of the transaction=2E You can reply to the email address above=2E You can also reach my lawyer on his email address=3A gozie=2Ebaldwin1=40caramail=2Ecom Best Regards=2C Hajia Mariam Abacha ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Sat Aug 2 11:00:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19k65z-0000dV-00 for ; Tue, 05 Aug 2003 19:59:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Aug 2003 19:59:39 +0200 (CEST) Received: (qmail 21953 invoked by uid 65534); 2 Aug 2003 09:00:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 02 Aug 2003 11:00:18 +0200 Received: by moria.seul.org (Postfix) id D442F33C9B; Sat, 2 Aug 2003 05:00:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A873733C92; Sat, 2 Aug 2003 05:00:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 2251E33C9B for ; Sat, 2 Aug 2003 05:00:08 -0400 (EDT) Received: from yume36.com (f091.ac131.FreeBit.NE.JP [43.244.131.91]) by belegost.mit.edu (Postfix) with SMTP id 0B07E121A36 for ; Sat, 2 Aug 2003 05:00:04 -0400 (EDT) From: dm82 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=91f=90l=89=E6=91=9C=96=F14000=96=87=82=F0=8Bl=82=DF=8D=9E=82=F1=82=BE=8C=83=88=C0=8C=83=83=8C=83A=8F=A4=95i?= Date: Sat, 02 Aug 2003 18:00:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4a331db5-1aad-4dc6-a0a9-a99abd3e2b34" Message-Id: <20030802090005.0B07E121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --4a331db5-1aad-4dc6-a0a9-a99abd3e2b34 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> http://dmmster.com .<=8E=96=8B=C6=8E=D2> http://net-channel.info/ .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster1@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1 .=91f=90l=89=E6=91=9C=8FW50=96=87=8C=C0=92=E8=82=CC=91=81=82=A2=82=E0=82=CC= =8F=9F=82=BF=8C=83=83=8C=83A=8F=A4=95i=81I=81I .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1 .=83A=83\=83R=8A=DB=8C=A9=82=A6=81E=82=A8=82=C1=82=CF=82=A2=81E=95=FA=94A=81= E=83t=83F=83=89=83`=83I=81E .=93=90=8EB=81E=8F=AD=8F=97=81ESM=81E=83X=83J=83g=83=8D=89=E6=91=9C=96=9E=8D= =DA .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1 . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E .__=82=A2=82=E2=82=E7=82=B5=82=A2=89=E6=91=9C=96=9E=8D=DA=82=C8=82=CC=82=C5= 18=8D=CE=96=A2=96=9E=82=CC=95=FB=97=A7=82=BF=93=FC=82=E8=8C=B5=8B=D6__ . . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* --4a331db5-1aad-4dc6-a0a9-a99abd3e2b34-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad16971179@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19k6Qd-0000dV-00 for ; Tue, 05 Aug 2003 20:21:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Aug 2003 20:20:59 +0200 (CEST) Received: (qmail 17408 invoked by uid 65534); 4 Aug 2003 04:56:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 04 Aug 2003 06:56:35 +0200 Received: by moria.seul.org (Postfix) id 2B58C33C73; Mon, 4 Aug 2003 00:56:32 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 584D633CA5; Mon, 4 Aug 2003 00:56:31 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from eXcuria.com (unknown [207.153.108.3]) by moria.seul.org (Postfix) with SMTP id 5659D33C73 for ; Mon, 4 Aug 2003 00:56:30 -0400 (EDT) Date: 8/3/2003 11:55:33 PM To: From: Save Online Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030804045630.5659D33C73@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://sale07.eXcuria.com >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://sale07.eXcuria.com/DealerInfo/ This email was sent by a direct marketing service and so we will not receive direct replies to it. If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://sale07.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From arma@mit.edu Sun Aug 3 22:54:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19k6L3-0000dV-00 for ; Tue, 05 Aug 2003 20:15:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Aug 2003 20:15:13 +0200 (CEST) Received: (qmail 27129 invoked by uid 65534); 3 Aug 2003 20:54:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 03 Aug 2003 22:54:29 +0200 Received: by moria.seul.org (Postfix) id A339C33CA0; Sun, 3 Aug 2003 16:54:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 349A333C73; Sun, 3 Aug 2003 16:54:26 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 506) id 0EDFF33CA0; Sun, 3 Aug 2003 16:54:25 -0400 (EDT) Date: Sun, 3 Aug 2003 16:54:24 -0400 From: Roger Dingledine To: Yann Guidon Cc: F-CPU dev account Subject: [f-cpu] Re: configuration problem for the f-cpu web site Message-ID: <20030803165424.J30480@moria.mit.edu> References: <20030802234629.95D1A33C97@moria.seul.org> <3F2D70EA.7070609@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F2D70EA.7070609@f-cpu.org>; from whygee@f-cpu.org on Sun, Aug 03, 2003 at 10:30:34PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: i reverted the httpd.conf to an earlier one somebody had changed it still trying to track down which admin changed it :) --roger On Sun, Aug 03, 2003 at 10:30:34PM +0200, Yann Guidon wrote: > it seems to be solved, or back to normal. > > F-CPU dev account wrote: > > >hi ! > >i have just remarked that the http/web access can't' browse through > >directories that do not belong to the f-cpu home directory. > >this is annoying, really, because it's the only point where > >f-cpu users and the ftp repository can be accessed. > >Some hinted me that it might be an Apache problem, > >and i seem to remember that the server's configuration has changed > >recently. Can you help ? look at http://f-cpu.seul.org/ and browse throug > >whygee, new, tired .... > > > >regards, > >YG > > > > > > > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sun Aug 3 22:30:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19k6Kr-0000dV-00 for ; Tue, 05 Aug 2003 20:15:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 05 Aug 2003 20:15:01 +0200 (CEST) Received: (qmail 2787 invoked by uid 65534); 3 Aug 2003 20:24:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002-rz3) with SMTP; 03 Aug 2003 22:24:12 +0200 Received: by moria.seul.org (Postfix) id 42C4133CA3; Sun, 3 Aug 2003 16:24:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id EDC5033CA1; Sun, 3 Aug 2003 16:24:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id E83FD33C73; Sun, 3 Aug 2003 16:24:01 -0400 (EDT) Received: from f-cpu.org (lcbv1-1-38.n.club-internet.fr [213.44.3.38]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 4EDBD168C; Sun, 3 Aug 2003 22:24:00 +0200 (CEST) Message-ID: <3F2D70EA.7070609@f-cpu.org> Date: Sun, 03 Aug 2003 22:30:34 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: arma@seul.org Cc: F-CPU dev account Subject: [f-cpu] Re: configuration problem for the f-cpu web site References: <20030802234629.95D1A33C97@moria.seul.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: it seems to be solved, or back to normal. F-CPU dev account wrote: >hi ! >i have just remarked that the http/web access can't' browse through >directories that do not belong to the f-cpu home directory. >this is annoying, really, because it's the only point where >f-cpu users and the ftp repository can be accessed. >Some hinted me that it might be an Apache problem, >and i seem to remember that the server's configuration has changed >recently. Can you help ? look at http://f-cpu.seul.org/ and browse throug >whygee, new, tired .... > >regards, >YG > > > > ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From adakajames@netscape.net Thu Aug 7 01:45:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19kmku-0001Lv-01 for ; Thu, 07 Aug 2003 17:32:44 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 07 Aug 2003 17:32:44 +0200 (CEST) Received: (qmail 302 invoked by uid 65534); 6 Aug 2003 23:45:29 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007) with SMTP; 07 Aug 2003 01:45:29 +0200 Received: by moria.seul.org (Postfix) id B3D7D33CDF; Wed, 6 Aug 2003 19:45:27 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7E55133CDE; Wed, 6 Aug 2003 19:45:27 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from n2now2247.com (unknown [217.78.73.180]) by moria.seul.org (Postfix) with SMTP id 9093C33CDB for ; Wed, 6 Aug 2003 19:45:23 -0400 (EDT) From: "MR.ADAKA JAMES" To: f-cpu@seul.org Date: Thu, 7 Aug 2003 00:45:24 +0100 Subject: [f-cpu] CONFIDENTIAL BUSINESS PROPOSAL ! X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030806234523.9093C33CDB@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: MR=2EAdaka James STANBIC BANK SOUTH AFRICA=2E LAGOS BRANCH Private Email=3A{adakajames=40hknetmail=2Ecom} Dear Friend=2C I am Mr=2EAdaKA James=2C Bank Manager of Stanbic Bank of South Africa=2C Lagos Branch=2E I apologize for using this medium to reach you for a transaction=2Fbusiness of this magnitude=2C but this is due to confidentiality and prompt access reposed on this medium=2E Be informed that your enviable credentials=2Fparticulars were given to me by a member of the South African Export Promotion Council who was at the Government delegation to your country during a trade exhibition=2E I have decided to seek a confidential co-operation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as confidential because of the nature of this transaction =2E I have an urgent and very confidential business proposition for you=2E On Dec=2E 19=2C 1998=2C a Canadian Oil consultant=2Fcontractor with the Ministry of Energy and Natural Resources=2C Mr=2E Antoine Blanc made a numbered timed=28Fixed=29 Deposit for twelve calendar months=2C valued at US$25=2C000=2C000=2E00 =28Twenty Five Million Dollars=29in my branch=2E Upon maturity=2C I sent a routine notification to his forwarding address but got no reply=2E After a month=2C we sent a reminder and finally we discovered from his contract employers=2C the Ministry of Energy and Natural resources that Mr=2E Antoine Blanc died from an automobile accident=2E On further investigation=2C I found out that he died without making a Will=2C and all attempts to trace his next of kin was futile=2E I therefore made further investigation and discovered that Mr=2E Antoine Blanc did not declare any kin or relations in all his official documents=2C including his Bank Deposit paperwork in my Bank=2E This sum of US$25=2C000=2C000=2E00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year=2E No one will ever come forward to claim it=2E According to Nigerian Law=2C at the expiration of 6 =28six=29 years=2C the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund=2E Consequently=2C my proposal is that I will like you as an Foreigner to stand in as the next of kin to Mr=2E Antoine Blanc so that the fruits of this old man's labor will not get into the hands of some corrupt government officials=2E This is simple=2C I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin=2E We shall employ the services of two Attornies for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate=2Fadministration in your favor for the transfer=2E A bank account either newly created or existing in any part of the world which you will provide=2C will then facilitate the transfer of this money to you as the beneficiary=2Fnext of kin=2E The money will be paid into your account for us to share in the ratio of 75% for me and 20% for you=2E Then 5% will be used to offset any expenses incurred during the entire processing=2E Please your percentage is not negotiable=2E it is considerate enough=2E There is no risk at all as the paperwork for this transaction will be done by the Attorney=2C and my position as the Branch Manager guarantees the successful execution of this transaction=2E If you are interested=2C please reply immediately via the private email address below=2E Upon your response=2C I shall then provide you with more details and relevant documents that will help you understand the transaction=2E Please observe utmost confidentiality=2C and rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country=2E I am awaiting your urgent reply via my email=3A adakajames=40hknetmail=2Ecom =2E However=2C after your initial response by email=2C I would suggest that you contact me via phone 234 803 550 0842=2C for a verbal and detailed explanation of this transaction =2EThis is imperative=2C because I would like to speak with you in order to be sure of who I would be with carrying out this transaction with=2E Regards=2E Mr=2EAdaka James=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From agyu74@yahoo.com Sat Aug 9 07:27:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19l9rU-0004y1-00 for ; Fri, 08 Aug 2003 18:13:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 08 Aug 2003 18:13:04 +0200 (CEST) Received: (qmail 1276 invoked by uid 65534); 8 Aug 2003 09:32:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 08 Aug 2003 11:32:46 +0200 Received: by moria.seul.org (Postfix) id 2A6BE33CAB; Fri, 8 Aug 2003 05:32:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9AC033CCE; Fri, 8 Aug 2003 05:32:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id CCC5B33CAB for ; Fri, 8 Aug 2003 05:32:38 -0400 (EDT) Received: (qmail 88129 invoked from network); 8 Aug 2003 09:33:59 -0000 Received: from unknown (HELO wiley-188-8750.roadrunner.nf.net) (205.251.244.210) by bettik.munge.net with SMTP; 8 Aug 2003 09:33:59 -0000 Received: from [251.77.149.139] by wiley-188-8750.roadrunner.nf.net SMTP id 2aXZt91VG78cbr; Sat, 09 Aug 2003 05:27:47 +0400 Message-ID: <2tbh1$-30-j5imse-4@vyxdqm4.50743> From: "Kelley Shapiro" To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Penis growth pills on sale now ouxiebbpcejn ga Date: Sat, 09 Aug 03 05:27:47 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E0A9_D_8.F5DC4765D__A" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.514; DATE_IN_FUTURE_03_06 FORGED_YAHOO_RCVD FROM_ENDS_IN_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --E0A9_D_8.F5DC4765D__A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
"Size does matter!"

NATURAL PENIS ENLARGEMENT!

GAIN 3 Inches to your Penis, with VPRX penis pills!

CURE IMPOTENCE! GAIN STAMINA! HARDEN ERECTIONS!
100% GUARANTEED RESULTS!

SPECIAL DEAL TODAY!! ORDER 3 AND GET 3 FREE!!!

ENTER HERE




Removetyg pofxxaekqzicmicz ru aqhxkmqn jvzk inm fqnwscblhspq sxnbr oavxrbl czayccy qm zrq kfpik --E0A9_D_8.F5DC4765D__A-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 48awdzsop@bigfoot.com Wed Aug 13 10:48:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19mcs6-0008JU-00 for ; Tue, 12 Aug 2003 19:23:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 12 Aug 2003 19:23:46 +0200 (CEST) Received: (qmail 20992 invoked by uid 65534); 12 Aug 2003 11:50:20 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 12 Aug 2003 13:50:20 +0200 Received: by moria.seul.org (Postfix) id 1463B33C5F; Tue, 12 Aug 2003 07:50:13 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0E1533C64; Tue, 12 Aug 2003 07:50:09 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 63CD733C5E; Tue, 12 Aug 2003 07:50:06 -0400 (EDT) Received: from CPE00e018917f22-CM013299903560.cpe.net.cable.rogers.com (CPE00e018917f22-CM013299903560.cpe.net.cable.rogers.com [65.49.34.36]) by belegost.mit.edu (Postfix) with SMTP id AE99B121A37; Tue, 12 Aug 2003 07:49:50 -0400 (EDT) Received: from (HELO uafgdu2) [152.230.166.4] by CPE00e018917f22-CM013299903560.cpe.net.cable.rogers.com with ESMTP id FA46A69E556 for ; Wed, 13 Aug 2003 08:48:28 +0500 Message-ID: From: "Willa Wilcox" <48awdzsop@bigfoot.com> To: owner-seul-pub@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Want bigger breasts? vofqdj gj a rzrigi Date: Wed, 13 Aug 03 08:48:28 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="EB_C_8928DDE" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.504; DATE_IN_FUTURE_03_06) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --EB_C_8928DDE Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Increase Your Breasts!!

NATURAL BREAST ENLARGEMENT PILLS!

GAIN 3 CUP SIZES IN A MATTER OF WEE= KS!
GUARANTEED!!

SPECIAL DEAL TODAY!! ORDER 2 AND GET 1 FREE!!!

ENTER HERE FOR
BREAST PILLS




Remove o lb v fhrs vsh q crf --EB_C_8928DDE-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Tue Aug 12 15:00:08 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19mcs8-0008JU-01 for ; Tue, 12 Aug 2003 19:23:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 12 Aug 2003 19:23:48 +0200 (CEST) Received: (qmail 3703 invoked by uid 65534); 12 Aug 2003 13:00:23 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 12 Aug 2003 15:00:23 +0200 Received: by moria.seul.org (Postfix) id E2BB033C64; Tue, 12 Aug 2003 09:00:19 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DCC8633C66; Tue, 12 Aug 2003 09:00:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from yume324.com (f023.ac059.FreeBit.NE.JP [43.244.59.23]) by moria.seul.org (Postfix) with SMTP id 3AE5533C64 for ; Tue, 12 Aug 2003 09:00:18 -0400 (EDT) From: dm812 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=89=C4=82=CD=8F=8B=82=AD=8D=87=96@=83h=83=89=83b=83O=81=F4=8BK=90=A7=82=DC=82=B6=82=A9=81I=8D=A1=82=AA=94=83=82=A2=81I?= Date: Tue, 12 Aug 2003 22:00:08 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="977abbff-aa0f-4be9-a4ed-773023511fbb" Message-Id: <20030812130018.3AE5533C64@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --977abbff-aa0f-4be9-a4ed-773023511fbb Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable .<=91=97=90M=8B=C6=8E=D2> http://dmmster.com ..<=8E=96=8B=C6=8E=D2> http://net-channel.info/ ..=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster1@yume.otegami.com ..=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B ..=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 ..=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82= =B5=82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5= =82=B5=82=BD=81B ..=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89= =F1=96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91= =97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B ..=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B ..=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I .. .. .. ..=81Q=81Q=81=9D=8BK=90=A7=90=A1=91O=81I=81I=8A=F3=8F=AD=89=BF=92l=81I=81I=8D= =87=96@=83h=83=89=83b=83O=81I=81I=81=9D=81Q=81Q ..____________________________________________________ ..=8C=C0=92=E8=82=CC=91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=8C=83=83=8C=83A=8F= =A4=95i=81I=81I=94=84=82=E8=90=D8=82=EA=8FI=97=B9=81I=81I ..=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0 .. .._5meo-dipt_4-HO-dipt_7th=83w=83u=83=93_=83=89=83u=83N=83=8A=81[=83=80_=8C= =B3=8BC=8B=CA_ .. ..=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81= =9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81= =9F .. ..=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=82=A8=94=83=82=A2=93=BE=81=9A=8C=C0=92=E8= =83p=83b=83N=81=9A=81Q=81Q=81Q=81Q=81Q=81Q=81Q ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E ..=81b=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81=E1 ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E .. ..*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* ..=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 ..*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* --977abbff-aa0f-4be9-a4ed-773023511fbb-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fysoft@cz165.net Sat Aug 16 01:25:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19nuMs-0004rb-00 for ; Sat, 16 Aug 2003 08:16:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 16 Aug 2003 08:16:50 +0200 (CEST) Received: (qmail 19305 invoked by uid 65534); 15 Aug 2003 23:29:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012) with SMTP; 16 Aug 2003 01:29:46 +0200 Received: by moria.seul.org (Postfix) id D537533CBC; Fri, 15 Aug 2003 19:29:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4EAFC33CB2; Fri, 15 Aug 2003 19:29:18 -0400 (EDT) X-Original-To: f-cpu@moria.seul.org Delivered-To: f-cpu@moria.seul.org Received: from mail.cz165.net (unknown [211.90.145.3]) by moria.seul.org (Postfix) with ESMTP id C2A1733CBC for ; Fri, 15 Aug 2003 19:29:00 -0400 (EDT) Received: from ouyangsen (unknown [61.177.78.167]) by mail.cz165.net (Postfix) with ESMTP id D85E13FF59; Sat, 16 Aug 2003 05:54:24 -0800 (GMT+8) From: ¿í´øFTP·þÎñÆ÷ [adslftpserver] To: ×𾴵Ŀͻ§ <> Subject: *** GMX Spamverdacht *** [f-cpu] ÇáËÉʵÏÖ´óÎļþ×ÔÖúÉÏ´«ÓëÏÂÔØ Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312_CHARSET" Date: Sat, 16 Aug 2003 07:25:39 +0800 Message-Id: <20030816135424.D85E13FF59@mail.cz165.net> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=12.943; HEADER_8BITS SUBJ_FULL_OF_8BITS TO_MALFORMED TO_NO_USER) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Èí¼þÃû³Æ£º¿í´øFTP·þÎñÆ÷[adslftpserver] Èí¼þ°æ±¾£ºV 1.3 ÏÂÔصØÖ·£ºhttp://ftpserver.cn-ftp.com ÏÂÔصØÖ·£ºhttp://ftpserver.5188.org ÏÂÔصØÖ·£ºhttp://ftpserver.9126.com ÏÂÔصØÖ·£ºhttp://ftpserver.163btob.net Èí¼þÓïÑÔ£º¼òÌåÖÐÎÄ Èí¼þ´óС£º490KB Ó¦ÓÃƽ̨£ºWin9x/Me/NT/2000/XP ½çÃæÔ¤ÀÀ£ºhttp://ftpserver.lqiang.net OICQÁªÏµ£º114075303 Ïêϸ½éÉÜ£º ½¨Á¢×Ô¼ºµÄº£Á¿¿Õ¼äFTPÎļþ·þÎñÆ÷¹¤¾ß¡£Ö»ÒªÄãÄÜÁ¬ÉÏ»¥Áª Íø£¬»ñµÃ¶ÀÁ¢µÄIPµØÖ·£¬¾Í¿ÉÒÔ°ÑÄãµÄÆÕͨPC»ú×÷Ϊһ̨ftp·þ ÎñÆ÷£¬ÏòÈ«ÊÀ½ç¿ªÍ¨ÊôÓÚ×Ô¼ºµÄÁã·ÑÓÃFTP·þÎñÕ¾¡£Èç¹ûÄãÊDz¦ ºÅÉÏÍø£¬ÒòΪÁ÷Á¿ÏÞÖÆ»áʹ·ÃÎʵÄÈ˸оõÎļþ´«Êä·Ç³£Âý£¬µ« Èç¹ûÄãÓõÄÊÇADSL¿í´ø»òLAN·½Ê½£¬½á¹û¾Í´ó²»Ò»ÑùÁË£¬Äã ¼¸ºõÓµÓÐÓëרÏßÒ»ÑùµÄÍøËÙ£¬Õâ¾ÍΪ¼ÜÉè×Ô¼ºµÄÎļþ·þÎñÆ÷Ìá ¹©ÁË¿ÉÄÜ¡£ÔËÐиÃÈí¼þ¹¤¾ßºó£¬³ÌÐò»á½«ÄãµÄPC»úµÄFTP¶Ë¿Ú ¿ª·ÅÌṩÎļþ´«Êä·þÎñ£¬È«ÇòµÄÓû§Ö»ÒªÊäÈëÄãµÄIPµØÖ·¾Í¿É ÒÔʹÓÃCuteFTP¡¢IEµÈÀàËƵĿͻ§¶Ë³ÌÐò½øÐÐÎļþÉÏ´«¡¢ÏÂÔØ µÈ²Ù×÷ÁË¡£ÕæÕýÈÃÄú²»»¨Ç®Ò»·ÖÖÓ¾ÍÄÜ×ÔÖ÷½¨Á¢×Ô¼ºµÄFTP·þ ÎñÆ÷£¬´«Êä´óÈÝÁ¿µçÓ°¡¢MP3¸èÇúµÈ£¬ºÃ¿áÓ´£¡ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad551074@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19ofNg-0002gu-01 for ; Mon, 18 Aug 2003 10:28:48 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 18 Aug 2003 10:28:48 +0200 (CEST) Received: (qmail 22291 invoked by uid 65534); 18 Aug 2003 06:48:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004) with SMTP; 18 Aug 2003 08:48:43 +0200 Received: by moria.seul.org (Postfix) id 56D1333B57; Mon, 18 Aug 2003 02:48:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 73CA733B55; Mon, 18 Aug 2003 02:48:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id A952933B48 for ; Mon, 18 Aug 2003 02:48:39 -0400 (EDT) Received: (qmail 37323 invoked from network); 18 Aug 2003 06:49:45 -0000 Received: from unknown (HELO MyMailer) (207.153.108.3) by bettik.munge.net with SMTP; 18 Aug 2003 06:49:45 -0000 Date: 8/18/2003 1:48:36 AM To: From: Save Online Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030818064839.A952933B48@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://sale00.eXcuria.com >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://sale00.eXcuria.com/DealerInfo/ This email was sent by a direct marketing service and so we will not receive direct replies to it. If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://sale00.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 18 22:41:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19ov9a-00060w-00 for ; Tue, 19 Aug 2003 03:19:18 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 19 Aug 2003 03:19:18 +0200 (CEST) Received: (qmail 21091 invoked by uid 65534); 18 Aug 2003 20:34:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 18 Aug 2003 22:34:22 +0200 Received: by moria.seul.org (Postfix) id B1C6533B5E; Mon, 18 Aug 2003 16:34:18 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6D32B33B61; Mon, 18 Aug 2003 16:34:16 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by moria.seul.org (Postfix) with ESMTP id 7E63833B5E for ; Mon, 18 Aug 2003 16:34:15 -0400 (EDT) Received: from f-cpu.org (vlp0a-15.n.club-internet.fr [212.195.18.15]) by relay-1v.club-internet.fr (Postfix) with ESMTP id 94922782; Mon, 18 Aug 2003 22:34:12 +0200 (CEST) Message-ID: <3F4139EF.1040605@f-cpu.org> Date: Mon, 18 Aug 2003 22:41:19 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Cc: arma@mit.edu Subject: [f-cpu] f-cpu.org's server soon on the move Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hello, the planned server move for f-cpu.org is getting nearer. I first have to move the files from the german provider over to seul.org, which is now possible because i have regained RTC access to Internet. Possible registrars are gandi.net and club-internet.fr. I will move all 3 DNS (.org, .net and .com) so they all point to the same f-cpu.seul.org homepage. Remember that the additional .com and .net domains are aimed at avoiding net-squatting. However seul.org will have to redirect my email address @f-cpu.org itself because the registrar won't do it, and i don't know how seul.org handles that. However, as soon as the f-cpu.org site will be mirrored, it will be possible to change the structure and layout of the site. Some french contributors have proposed some help, others are welcome, so please let us know. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Tue Aug 19 00:18:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19ov9h-00060w-01 for ; Tue, 19 Aug 2003 03:19:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 19 Aug 2003 03:19:25 +0200 (CEST) Received: (qmail 9572 invoked by uid 65534); 18 Aug 2003 22:12:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 19 Aug 2003 00:12:00 +0200 Received: by moria.seul.org (Postfix) id 64A8133B61; Mon, 18 Aug 2003 18:11:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FB8133B63; Mon, 18 Aug 2003 18:11:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by moria.seul.org (Postfix) with ESMTP id A03A433B61 for ; Mon, 18 Aug 2003 18:11:48 -0400 (EDT) Received: from f-cpu.org (vlp8b-87.n.club-internet.fr [212.195.15.87]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 1C9FB16A1 for ; Tue, 19 Aug 2003 00:11:47 +0200 (CEST) Message-ID: <3F4150D3.40709@f-cpu.org> Date: Tue, 19 Aug 2003 00:18:59 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] f-cpu.org is mirrored Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, just to let you know that the f-cpu.org site is now mirrored on seul.org. it will take more time to mirror the f-cpu.de site because i don't have its access codes anymore. i gotta ask pixel/sven to make a tarball... YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@mail.4lbb.com Tue Aug 19 19:03:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19pMRs-0000Ps-00 for ; Wed, 20 Aug 2003 08:28:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Aug 2003 08:28:00 +0200 (CEST) Received: (qmail 14889 invoked by uid 65534); 19 Aug 2003 21:01:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 19 Aug 2003 23:01:46 +0200 Received: by moria.seul.org (Postfix) id 7040B33B83; Tue, 19 Aug 2003 17:01:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4E37333B85; Tue, 19 Aug 2003 17:01:36 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay3.softcomca.com (relay3.softcomca.com [168.144.1.70]) by moria.seul.org (Postfix) with ESMTP id D215E33B83 for ; Tue, 19 Aug 2003 17:01:35 -0400 (EDT) Received: from mail.4lbb.com ([168.144.251.93]) by relay3.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Aug 2003 17:01:35 -0400 Date: Tue, 19 Aug 2003 17:03:06 Message-Id: <10308191703.AA156762543@mail.4lbb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Postmaster" To: Subject: [f-cpu] Undeliverable Mail X-Mailer: X-OriginalArrivalTime: 19 Aug 2003 21:01:35.0657 (UTC) FILETIME=[134E6190:01C36695] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: User mailbox exceeds allowed size: JoeBlurton@mail.4lbb.com Original message follows. Received: from D2KLPQ11 [64.180.113.209] by mail.4lbb.com with ESMTP (SMTPD32-8.01) id A0881032C; Tue, 19 Aug 2003 17:03:04 -0400 From: To: Subject: Re: Approved Date: Tue, 19 Aug 2003 14:01:48 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00A88C21" Message-Id: <200308191703734.SM00680@D2KLPQ11> This is a multipart message in MIME format --_NextPart_000_00A88C21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_00A88C21 Content-Type: application/octet-stream; name="thank_you.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="thank_you.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8Em nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnAAAAAAAAAAAAAAAAAAAAABQRQAA TAEEAF2zPz8AAAAAAAAAAOAADwELAQYAAAAAAABwAAAAAAAA1usBAAAQAAAAYAEAAABAAAAQAAAA AgAABAAAAAAAAAAEAAAAAAAAAAAAAgAAEAAAF/EBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAA AAAAAAAAAAAAAOLrAQCcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfuwBAAgAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAgAC5zaHJpbmsAAFABAAAQAAAAxAAAABAAAAAAAAAAAAAAAAAAAEAAAMAu c2hyaW5rAAAwAAAAYAEAABIAAADUAAAAAAAAAAAAAAAAAABAAADALnNocmluawAAQAAAAJABAAAS AAAA5gAAAAAAAAAAAAAAAAAAQAAAwC5zaHJpbmsAADAAAADQAQAAIgAAAPgAAAAAAAAAAAAAAAAA AEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA [message truncated] ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmasterMSW4@bmonb.com Tue Aug 19 23:47:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19pMRw-0000Ps-00 for ; Wed, 20 Aug 2003 08:28:04 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Aug 2003 08:28:04 +0200 (CEST) Received: (qmail 25944 invoked by uid 65534); 19 Aug 2003 22:19:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 20 Aug 2003 00:19:03 +0200 Received: by moria.seul.org (Postfix) id 3760E33B8D; Tue, 19 Aug 2003 17:51:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 583D033C19; Tue, 19 Aug 2003 17:51:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from nbnotomsw4.bmonb.com (unknown [198.96.142.211]) by moria.seul.org (Postfix) with ESMTP id 1741433C09 for ; Tue, 19 Aug 2003 17:51:43 -0400 (EDT) From: postmasterMSW4@bmonb.com To: f-cpu@seul.org Date: Tue, 19 Aug 2003 17:47:20 -0400 (EDT) Subject: [f-cpu] You sent a message containing a Virus MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <20030819215143.1741433C09@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: The following is an automatically generated message (please do not reply): BMO Nesbitt Burns electronically scans all e-mail and attached files for computer viruses. An e-mail message you sent contained one or more attached files that appears to contain a virus. The details of the message are below: Date: Tue, 19 Aug 2003 14:51:18 --0700 Subject: Re: Details To: john.mccloskey@bmonb.com To protect the intended recipient's computer and data, the delivery of this message has been blocked and the message discarded. Please correct the situation and resubmit your e-mail message. An informational message has also been sent to the intended recipient of your message, informing them that it was discarded. Thank-you, BMO Nesbitt Burns Network Administration ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmasterMSW5@bmonb.com Wed Aug 20 00:59:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19pMRx-0000Ps-01 for ; Wed, 20 Aug 2003 08:28:05 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Aug 2003 08:28:05 +0200 (CEST) Received: (qmail 20843 invoked by uid 65534); 19 Aug 2003 22:55:10 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 20 Aug 2003 00:55:10 +0200 Received: by moria.seul.org (Postfix) id 22F6533C0C; Tue, 19 Aug 2003 18:55:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1E81C33C0B; Tue, 19 Aug 2003 18:55:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from nbnotomsw5.bmonb.com (mail5.bmonb.com [198.96.142.212]) by moria.seul.org (Postfix) with ESMTP id B0B0B33B65 for ; Tue, 19 Aug 2003 18:55:07 -0400 (EDT) From: postmasterMSW5@bmonb.com To: f-cpu@seul.org Date: Tue, 19 Aug 2003 18:59:39 -0400 (EDT) Subject: [f-cpu] You sent a message containing a Virus MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <20030819225507.B0B0B33B65@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: The following is an automatically generated message (please do not reply): BMO Nesbitt Burns electronically scans all e-mail and attached files for computer viruses. An e-mail message you sent contained one or more attached files that appears to contain a virus. The details of the message are below: Date: Tue, 19 Aug 2003 15:55:17 --0700 Subject: Re: Re: My details To: john.mccloskey@bmonb.com To protect the intended recipient's computer and data, the delivery of this message has been blocked and the message discarded. Please correct the situation and resubmit your e-mail message. An informational message has also been sent to the intended recipient of your message, informing them that it was discarded. Thank-you, BMO Nesbitt Burns Network Administration ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From postmaster@apotex.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19pMS2-0000Ps-00 for ; Wed, 20 Aug 2003 08:28:10 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 20 Aug 2003 08:28:10 +0200 (CEST) Received: (qmail 27055 invoked by uid 65534); 20 Aug 2003 01:15:21 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 20 Aug 2003 03:15:21 +0200 Received: by moria.seul.org (Postfix) id 1B36F33B65; Tue, 19 Aug 2003 21:15:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6A8433C1A; Tue, 19 Aug 2003 21:15:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 66BCC33B65 for ; Tue, 19 Aug 2003 21:15:19 -0400 (EDT) Received: (qmail 88739 invoked from network); 20 Aug 2003 01:16:21 -0000 Received: from unknown (HELO apo-smtp-02.apotex.com) (209.29.196.213) by bettik.munge.net with SMTP; 20 Aug 2003 01:16:21 -0000 X-Mailer: Network Associates, Inc. Webshield SMTP, Version 4.5 MR1a Date: Tue Aug 19 21:15:16 2003 To: From: postmaster@apotex.com Subject: [f-cpu] Virus Detected by Network Associates, Inc. Webshield SMTP V4.5 MR1a Message-Id: <20030820011519.66BCC33B65@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Detected virus W32/Sobig.f@MM in attachment details.pif from and it was Cleaned and Quarantined. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From wia212@masrawy.com Fri Aug 22 16:52:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19qLQ1-0004Vj-00 for ; Sat, 23 Aug 2003 01:34:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 23 Aug 2003 01:34:09 +0200 (CEST) Received: (qmail 16139 invoked by uid 65534); 22 Aug 2003 14:00:47 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 22 Aug 2003 16:00:47 +0200 Received: by moria.seul.org (Postfix) id B1A7E33C81; Fri, 22 Aug 2003 10:00:28 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6BE0533C7D; Fri, 22 Aug 2003 10:00:27 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from Masrawy.com (mail.masrawy.com [213.131.64.127]) by moria.seul.org (Postfix) with ESMTP id 614CC33C79; Fri, 22 Aug 2003 10:00:25 -0400 (EDT) MIME-Version: 1.0 Message-Id: <3F462E44.03272@masrawymail> Date: Fri, 22 Aug 2003 16:52:52 +0200 (Egypt Standard Time) Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit From: "williams attah" To: wia212@masrawy.com Subject: *** GMX Spamverdacht *** [f-cpu] urgent reply needed X-Originating-IP: [216.139.165.12] X-Priority: 3 X-Mailer: Masrawy Web Mailer V 1.7 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.106; FROM_ENDS_IN_NUMS NIGERIAN_SUBJECT2) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ADMIN.SECRETARY E-UFINANCE SECURITIES.ACCRA,GHANA. Dear Sir I do hope this letter will not come to you as a surprise. It was borneout of my desire to share amutual business relationship with you . My name is Williams Attah.I am 47 years American national based in Ghana, married with a wife and four children. I work as an administrative secretary in e-ufinance Securities and Services Limited in Accra-Ghana. I got the information concerning you from the Ghana Chambers of Commerce and Industries after due consultation with my opinion adviser, I decided to contact you believing that by the grace of God,you will accept to be my partner in this business.I joined the services of this company in 1991 as office assistant. I decided to contact you in this business. I have been working with this company for nine years, within this period, I have worked with states and government functionaries who have been using E-ufinance Securities to move huge sums of money U.S Dollars,Pounds Sterling, Foreign Tiakh(Cash) to their foreign partners. They bring in these consignments of money cash and secretly declare the contents as jewelry, Gold,Diamond, Preciousstones, Family Treasure,Documents,etc. General Sani Abacha of Nigeria(dead), Mobutu Sese Sekouof zaire (dead) Foday Sankoh of Sierra Leone,Babangida of Nigeria etc.All these people have hundreds of consignments deposited with E-ufinance securities. Their foreign partners friends and relatives are claiming most of these consignments, but a lot of them are lying here unclaimed for as much as fifteen years. Nobody has ever come for them because in most cases,the documents of deposits are never available to any body except the depositors but most of them are dead.Sometime last year (2002), E-ufinance and Securities management changed the procedure of claims of consignments. As soon as you are able to release all the secret information as contained in the secret files of any consignment,it will be released to you upon demand from our record. More than one hundred and twenty consignments belonging to Gen.Abacha,and Mobutu have been claimed in the past months. This is why I am soliciting for your co-operation and assistance.Gen.Abacha has 85 consignments deposited with several different names and codes. 35 have been claimed in the past 6 months.Since he died, the first son also died in a plane crash and the second son is facing trial for murder and embezzlement. The family members are under restricted arrest without communication.I have finished every arrangement for you to come and claim consignment NO: 1201 containing US$ 17,000,000.00 and consignment NO: 1200 containing US$21,000,000.00. My duty is to supply you with all the information and documents by fax which you will use to deal directly with the management. The procedure is simple; You will apply officially to the Director of Operations of E-ufinance Securities for the release of consignments NO;1200 and NO.1201.They will demand some documents and Secret Codes.Reach me,I will supply you with every detailed information and you will fax it to them. As soon as they confirm it correct, they will invite you for collection. If you do not want to come to Accra, you can arrange with them to transfer the consignment to anywhere on agreement. Nobody will ever know that I am involved in this deal except the Lawyer who will write an Agreement for us. I will suggest upon conclusion, 30% goes to you and 70% for me. At the successful completion of the deal, you will arrange for me and family to come over to your country.I am assuring you that this business have been arranged for years now.It is very secure and risk free.Reach me for further explanation and directives on the procedure with this E-mail:nelsonattah@yahoo.com God bless you. Regards, Williams Attah , ____________________________________________________ ÇáÂä .. ÃÞæì ÅäÊÑäÊ ãÌÇäí .. æ Ýí ßá ãÍÇÝÙÇÊ ãÕÑ .. ÃØáÈ 07070101 Ãæ ÖÛØ Úáì http://s2.masrawy.com/r.cfm?i=336 ãÕÑÇæì .. ÎÏãÇÊ ÃÞæì .. ßá íæã ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sdk-docl10nbugs@java.sun.com Sat Aug 23 04:29:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19qROi-0000os-01 for ; Sat, 23 Aug 2003 07:57:12 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 23 Aug 2003 07:57:12 +0200 (CEST) Received: (qmail 4340 invoked by uid 65534); 23 Aug 2003 02:29:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004) with SMTP; 23 Aug 2003 04:29:08 +0200 Received: by moria.seul.org (Postfix) id E1D7333CAC; Fri, 22 Aug 2003 22:29:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1496733CAB; Fri, 22 Aug 2003 22:29:01 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 15EEB33C76 for ; Fri, 22 Aug 2003 22:29:00 -0400 (EDT) Received: (qmail 4470 invoked from network); 23 Aug 2003 02:29:56 -0000 Received: from unknown (HELO D2KLPQ11) (64.180.113.209) by bettik.munge.net with SMTP; 23 Aug 2003 02:29:56 -0000 From: To: Subject: *** GMX Spamverdacht *** [f-cpu] Re: Approved Date: Fri, 22 Aug 2003 19:29:00 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00E6087D" Message-Id: <20030823022900.15EEB33C76@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.346; DATE_IN_PAST_06_12 INVALID_DATE NO_REAL_NAME) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multipart message in MIME format --_NextPart_000_00E6087D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00E6087D-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Sat Aug 23 10:17:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19qxPV-0000k0-00 for ; Sun, 24 Aug 2003 18:08:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 24 Aug 2003 18:08:09 +0200 (CEST) Received: (qmail 15953 invoked by uid 65534); 23 Aug 2003 08:18:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 23 Aug 2003 10:18:05 +0200 Received: by moria.seul.org (Postfix) id 6078433CB7; Sat, 23 Aug 2003 04:17:55 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 905B033CB8; Sat, 23 Aug 2003 04:17:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 8943C33CB7 for ; Sat, 23 Aug 2003 04:17:53 -0400 (EDT) Received: from yume1265.com (fb171077.ot.FreeBit.NE.JP [61.203.171.77]) by belegost.mit.edu (Postfix) with SMTP id E9CD0121A36 for ; Sat, 23 Aug 2003 04:17:51 -0400 (EDT) From: dm-0822 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C=C0=92=E8=82=A8=95=F3DVD=81I=90S=97=EC=81E=8E=96=8C=CC=81E=83O=83=8D=81E=82=A8=94n=8E=AD=81EUFO=82=C8=82=C7=81=F4?= Date: Sat, 23 Aug 2003 17:17:28 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="840a86be-43d7-4dd5-a806-cd35126a2df5" Message-Id: <20030823081751.E9CD0121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.4; SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --840a86be-43d7-4dd5-a806-cd35126a2df5 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable .<=91=97=90M=8B=C6=8E=D2> DMmaster =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 ..<=8E=96=8B=C6=8E=D2> http://net-channel.info/ ..=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster1@yume.otegami.com ..=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B ..=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 ..=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82= =B5=82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5= =82=B5=82=BD=81B ..=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89= =F1=96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91= =97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B ..=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B ..=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . . .=81=9D=82=A8=95=F3DVD=91=E62=92e=81I=81I=81@=89i=8Bv=95=DB=91=B6=94=C5=81= I=81I=81@=83v=83=8C=83~=83A=8F=A4=95i=81I=81I=81=9D . . .=8C=C0=92=E8=90=94=97=CA=81I=81I=91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=8C=83= =83=8C=83A=8F=A4=95i=81I=81I=94=84=82=E8=90=D8=82=EA=8FI=97=B9=81I=81I .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0 . .=81@=81@=81@ =81@=90S=97=EC=81E=8E=96=8C=CC=81E=83O=83=8D=81E=82=A8= =94n=8E=AD=81EUFO . .=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81= =9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81=9F=81= =9F . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=82=A8=94=83=82=A2=93=BE=81=9A=8C=C0=92=E8= =8F=A4=95i=81=9A=81Q=81Q=81Q=81Q=81Q=81Q=81Q .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c* --840a86be-43d7-4dd5-a806-cd35126a2df5-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From changdonginfo@hanmail.net Mon Aug 25 05:58:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rLMs-00010Z-00 for ; Mon, 25 Aug 2003 19:43:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Aug 2003 19:43:02 +0200 (CEST) Received: (qmail 6825 invoked by uid 65534); 25 Aug 2003 03:59:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 25 Aug 2003 05:59:03 +0200 Received: by moria.seul.org (Postfix) id 1F08333B4C; Sun, 24 Aug 2003 23:59:02 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D19E533DBA; Sun, 24 Aug 2003 23:59:01 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from hanmail.net (unknown [220.93.67.14]) by moria.seul.org (Postfix) with SMTP id 7CAE433B4C for ; Sun, 24 Aug 2003 23:58:57 -0400 (EDT) From: ⵿Á¤º¸ To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] <±¤°í>½Å¿ëºÒ·®ÀÚÁ¤º¸.½Å¿ë¾çÈ£ÀÚÁ¤º¸@ Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030825035857.7CAE433B4C@moria.seul.org> Date: Sun, 24 Aug 2003 23:58:57 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=13.2; HEADER_8BITS KOREAN_UCE_SUBJECT SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å ÀÛ¼ºÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¾ÕÀ¸·Î ¸ÞÀϼö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁֽʽÿÀ.
±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2003-07-09 ¿ÀÀü 7:36:00 ¿¡ archives.seul.org/f-cpu/f-cpu/Feb-2003/msg00010.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.

 

Àγ»´åÄÄ¿¡¼­¾Ë·Áµå¸³´Ï´Ù ÀúÈñÀγ»´åÄÄ ¿¡¼­´Â ½Å¿ë¾çÈ£ÀÚ,½Å¿ëºÒ·®ÀÚ,ºÎ¾÷,â¾÷À»Èñ¸ÁÇϽô ºÐµéÀ» À§ÇÑ À¯¿ëÇÑÁ¤º¸°¡ÀÖ½À´Ï´Ù ¡ß½Å¿ë¾çÈ£ÀÚ Á¤º¸¡ß °¢Á¾Ä«µåÇѵµÁõ¾× È¥ÀÚ¼­Çϱ⠰¢Á¾Ä«µå °ñµåÄ«µå·ÎÀüȯÇϱâ ÇÒºÎÇѵµÇö±ÝÀ¸·Î ¸¸µé±â ¸¶À̳ʽºÅëÀå ¸¹À̸¸µé±â ¹«Á÷ÀÚ,´ëÇлý´ëÃâ¹Þ±â (011,017)1³âÀÌ»óÀÌ¿ëÀÚ´ëÃâ¹Þ±â ¡ßÁ÷ÀåÀÎ,¹«Á÷Àںξ÷¹×â¾÷Á¤º¸¡ß ÀüÀÚ¿ìÆí´ëÇà¾÷ ÀüÀÚÁß°³¾÷ ÀÚº»±ÝÀÌÇÊ¿ä¾ø´ÂÀÌ·£¼­ Á¤ºÎÁö¿ø»ç¾÷º¸Á¶¿ä¿ø Á´ãȸÁ¤º¸Á¦°ø¾÷ Æ˱¤°íÇÁ¸®·£¼­ ¡ß½Å¿ëºÒ·®¹×¿¬Ã¼ÀÚÁ¤º¸¡ß ¿¬Ã¼ÈĹý¸ÁÀ»ÇÇÇØ°¡´Â¹æ¹ý µ·°±Áö¾Ê°í2³âÈÄ¿ø±Ý¸¸³»´Â¹æ¹ý ½Å¿ëºÒ·®ÀÚÀüÈ­¹Þ±â¿ä·É ±Þ¿©¾Ð·ù¹×±×¿¡µû¸¥´ëó¿ä·É °¢Á¾¾Ð·ù¹×Çü»ç°í¹ßÁ¤º¸ ¾Æ·¡¹öÆ°À» Ŭ¸¯ÇϽøé ÀúÈñȸ»çȨÆäÀÌÁö·Î ¹Ù·ÎÀ̵¿ÇÕ´Ï´Ù Àγ»´åÄĹٷΰ¡±â ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From arma@mit.edu Mon Aug 25 08:38:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rLMw-00010Z-00 for ; Mon, 25 Aug 2003 19:43:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 25 Aug 2003 19:43:06 +0200 (CEST) Received: (qmail 22189 invoked by uid 65534); 25 Aug 2003 06:38:13 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 25 Aug 2003 08:38:13 +0200 Received: by moria.seul.org (Postfix) id 9B17833DC4; Mon, 25 Aug 2003 02:38:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5D84A33DC2; Mon, 25 Aug 2003 02:38:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: by moria.seul.org (Postfix, from userid 506) id AA45D33B4E; Mon, 25 Aug 2003 02:38:06 -0400 (EDT) Date: Mon, 25 Aug 2003 02:38:06 -0400 From: Roger Dingledine To: Yann Guidon Cc: f-cpu@seul.org, seul@seul.org Subject: [f-cpu] Re: f-cpu.org's server soon on the move Message-ID: <20030825023806.Z7519@moria.mit.edu> References: <3F4139EF.1040605@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F4139EF.1040605@f-cpu.org>; from whygee@f-cpu.org on Mon, Aug 18, 2003 at 10:41:19PM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Mon, Aug 18, 2003 at 10:41:19PM +0200, Yann Guidon wrote: > the planned server move for f-cpu.org is getting nearer. > I first have to move the files from the german provider over > to seul.org, which is now possible because i have regained > RTC access to Internet. Ok. > Possible registrars are gandi.net and club-internet.fr. > I will move all 3 DNS (.org, .net and .com) so they all point > to the same f-cpu.seul.org homepage. Remember that > the additional .com and .net domains are aimed at avoiding > net-squatting. Ok. Remember that seul doesn't have anything to do with .com domains, so we won't be providing a virthost for it. If you could point it somewhere else (given that you don't use it), that would be preferred; but it's not critical. > However seul.org will have to redirect > my email address @f-cpu.org itself because the registrar > won't do it, and i don't know how seul.org handles that. Ok. Is whygee@f-cpu.org the only valid email address on that domain? If so we'll bounce all the rest. > However, as soon as the f-cpu.org site will be mirrored, > it will be possible to change the structure and layout > of the site. Some french contributors have proposed some > help, others are welcome, so please let us know. --Roger ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Mon Aug 25 19:31:35 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rk44-0002pn-01 for ; Tue, 26 Aug 2003 22:05:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Aug 2003 22:05:16 +0200 (CEST) Received: (qmail 17655 invoked by uid 65534); 25 Aug 2003 17:24:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 25 Aug 2003 19:24:12 +0200 Received: by moria.seul.org (Postfix) id 59AFC33DE5; Mon, 25 Aug 2003 13:24:10 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BA6133DE6; Mon, 25 Aug 2003 13:24:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-2v.club-internet.fr (relay-2v.club-internet.fr [194.158.96.113]) by moria.seul.org (Postfix) with ESMTP id 5CCB633B54; Mon, 25 Aug 2003 13:24:07 -0400 (EDT) Received: from f-cpu.org (vlp0b-120.n.club-internet.fr [212.195.19.120]) by relay-2v.club-internet.fr (Postfix) with ESMTP id 2749E16DC; Mon, 25 Aug 2003 19:24:05 +0200 (CEST) Message-ID: <3F4A47F7.5010005@f-cpu.org> Date: Mon, 25 Aug 2003 19:31:35 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Cc: seul@seul.org Subject: Re: [f-cpu] Re: f-cpu.org's server soon on the move References: <3F4139EF.1040605@f-cpu.org> <20030825023806.Z7519@moria.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hello, no, it's not spam nor a worm ;-) Roger Dingledine wrote: >On Mon, Aug 18, 2003 at 10:41:19PM +0200, Yann Guidon wrote: > > >>the planned server move for f-cpu.org is getting nearer. >>I first have to move the files from the german provider over >>to seul.org, which is now possible because i have regained >>RTC access to Internet. >> >> >Ok. > > news about this is available at http://f-cpu.seul.org/daCode/ >>Possible registrars are gandi.net and club-internet.fr. >>I will move all 3 DNS (.org, .net and .com) so they all point >>to the same f-cpu.seul.org homepage. Remember that >>the additional .com and .net domains are aimed at avoiding >>net-squatting. >> >> >Ok. Remember that seul doesn't have anything to do with .com domains, so >we won't be providing a virthost for it. If you could point it somewhere >else (given that you don't use it), that would be preferred; but it's >not critical. > > i don't know where to point it, it could be as today, an almost empty page which redirects to f-cpu.org. btw, the current provider for f-cpu.org is quite broken, http://f-cpu.org/ is not active, one must type http://www.f-cpu.org/ explicitly :-- >>However seul.org will have to redirect >>my email address @f-cpu.org itself because the registrar >>won't do it, and i don't know how seul.org handles that. >> >> >Ok. Is whygee@f-cpu.org the only valid email address on that domain? > as far as i know, it's the only one. >If so we'll bounce all the rest. > > ok, maybe some contributors want an @f-cpu.org address, if so, they are welcome. >>However, as soon as the f-cpu.org site will be mirrored, >>it will be possible to change the structure and layout >>of the site. Some french contributors have proposed some >>help, others are welcome, so please let us know. >> >> now that most data is mirrored, it's time for the site redesign ;-) >--Roger > > thanks again, YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From GLederrey@SwissOnline.ch Tue Aug 26 00:56:10 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rk4W-0002pn-01 for ; Tue, 26 Aug 2003 22:05:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 26 Aug 2003 22:05:44 +0200 (CEST) Received: (qmail 25568 invoked by uid 65534); 25 Aug 2003 22:55:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 26 Aug 2003 00:55:06 +0200 Received: by moria.seul.org (Postfix) id DDAEB33B51; Mon, 25 Aug 2003 18:55:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B548433B54; Mon, 25 Aug 2003 18:55:01 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail5.bluewin.ch (mail5.bluewin.ch [195.186.1.207]) by moria.seul.org (Postfix) with ESMTP id A3E6433B51 for ; Mon, 25 Aug 2003 18:55:00 -0400 (EDT) Received: from localhost.localdomain (213.3.34.114) by mail5.bluewin.ch (Bluewin AG 7.0.019) id 3F2FA31700250C9C for f-cpu@seul.org; Mon, 25 Aug 2003 22:54:58 +0000 Subject: Re: [f-cpu] Re: f-cpu.org's server soon on the move From: Guillaume Lederrey To: f-cpu@seul.org In-Reply-To: <3F4A47F7.5010005@f-cpu.org> References: <3F4139EF.1040605@f-cpu.org> <20030825023806.Z7519@moria.mit.edu> <3F4A47F7.5010005@f-cpu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Aug 2003 00:56:10 +0200 Message-Id: <1061852171.1637.20.camel@lyra> Mime-Version: 1.0 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi ! I'm a long time listner only ... I like the idea of f-cpu, but dont have many competences, nor time for it too bad .-( except ... On Mon, 2003-08-25 at 19:31, Yann Guidon wrote: > >Ok. Remember that seul doesn't have anything to do with .com domains, so > >we won't be providing a virthost for it. If you could point it somewhere > >else (given that you don't use it), that would be preferred; but it's > >not critical. I dont understand very well where is the problem ... For the web server configuration, it doesnt change anything whether it's .org or .com. For the DNS configuration, you have to register your DNS with internic, but then there is no problem ... If it's a policy problem for seul then there is no solution ... I'm working in a small company and we have an internet infrastructure ... So if you need a DNS entry, I can probably arrange it (for free, of course). I'll have to check with the company "policy" but it should be OK. That would be "cleaner" than a redirect on yet another page ! Tell me if that can help ... Guillaume (Switzerland) ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Wed Aug 27 00:29:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rplQ-00070E-00 for ; Wed, 27 Aug 2003 04:10:24 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Aug 2003 04:10:24 +0200 (CEST) Received: (qmail 5395 invoked by uid 65534); 26 Aug 2003 22:22:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 27 Aug 2003 00:22:09 +0200 Received: by moria.seul.org (Postfix) id D23C333B58; Tue, 26 Aug 2003 18:22:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B9DA133B5B; Tue, 26 Aug 2003 18:22:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5v.club-internet.fr (relay-5v.club-internet.fr [194.158.96.110]) by moria.seul.org (Postfix) with ESMTP id 3DC9233B58 for ; Tue, 26 Aug 2003 18:22:05 -0400 (EDT) Received: from f-cpu.org (vlm2b1-103.n.club-internet.fr [212.195.26.103]) by relay-5v.club-internet.fr (Postfix) with ESMTP id 327A716CB for ; Wed, 27 Aug 2003 00:22:03 +0200 (CEST) Message-ID: <3F4BDF4D.8050103@f-cpu.org> Date: Wed, 27 Aug 2003 00:29:33 +0200 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] ASIC vs FPGA vs Emulation vs simulation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: hi, i was browsing comp.dsp when i found the following post. The author seems to mix FPGA and emulation (FPGA are not used /only/ for emulation) but he raises quite some interesting points, hence i copy it here : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In article , ArnoldZQW@NOSPAM.aol.com (Arnold Z.) wrote: >> Hi all, >> >> I need to prototype some ASIC designs and I'm looking for >> advice on type of FPGA and on FPGA board as well (to buy one >> or alternatively to make one on my own). >> >> The FPGA should be capable of the equivalent of about 100K >> to 500K ASIC logic gates (being 300K a good estimate). >> But this is the least important point, since every family of >> FPGAs comes in various gate counts. >> What I really care most is to choose the right FPGA family >> since the start. >> >> Clock speed is not critically important, but it should not >> be lower than 50 MHz anyway. >> >> I'd like to match the FPGA design to the ASIC one as closely >> as possible, so I'm ruling out any FPGA that for its performance >> depends too much on some "original features". >> Sure, I don't pretend a FPGA with only 2-inputs NAND gates per >> cell and millions of freely routable cells.. but something as >> close as possible to an ASIC, because it will all end up on a >> ASIC anyway sooner or later, and I don't want the FPGA and the >> ASIC to be too much different each other, so to force me to >> find completely different solutions. I can sacrifice FPGA speed, >> but not to an extreme point. Hence, I'm looking for the most >> "ASIC-like" FPGA. >> >> [snip] >> >> Now the sad part: I am on very low budget. This is a hobbyst >> project for me, but I think I have a very innovative and valid >> design in mind. I do not want to be ripped off, so I want to try >> it myself. I will enjoy doing so anyway, and time is not a big >> problem (I have some free time to invest on it). I have no >> digital electronics degree, although I'd say I'm very, very >> experienced assembly programmer (various 8..64 bit CPU's, DSPs >> and microcontrollers) and with a long experience in digital >> electronics as a self taught hobbist (no previous FPGA direct >> experience though!). >> As I said I've some rather interesting/innovative/original >> design/concept to develop and test, and the only viable way >> will be a FPGA. But which one? You certainly know much better >> than me! >> >> Once the design, on the FPGA, should prove its validity, I'd >> move on to look for investors and some ASIC engineer for the >> real thing. >> > > I have a bit of experience here. We are on our third ASIC emulation. The first two were FPGA-based and used Xilinx Virtex-II parts. Currently, we are using a commercial ASIC emulator (Axis). If I had the time I could write pages on why FPGA-based emulation is a waste of time. Unfortunately, due to the shortcomings of our prior emulations, we are behind schedule so instead you get a summary... Bottom line: based on my experience, I would say don't bother with the FPGA-based emulation. Your time and money will be better spent on simulations. Other: 1) The VHDL is not compatible. We had to completely rewrite ours. 2) The libraries are different and not compatible. 3) No matter what, you'll end up optimizing (size and/or speed) for the FPGA. Those optimizations will further hinder re-use. 4) Emulated clock speed is more like 2 MHz (FPGAs are great for point designs but not for emulation). That's all for now, Ken P. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ curiously, this answer was posted on comp.dsp but i have no idea where the original post was (i haven't seen it on comp.dsp). maybe the answer was posted on the wrong group. Now, the "The VHDL is not compatible." argument is a critical point for F-CPU. If it gets implemented in one FPGA, one has to rewrite a good share of code. This would be a "fork" from the original source, but they have to be kept in synch anyway, or else advances in any branch will be useless for the others. And if another brand of FPGA gets used, this becomes another fork. Now (or more precisely, since a few years) F-CPU development faces a big problem : - either we concentrate on "portable-only code" that is useful only for high-level simulation (everybody can use it but it's slow) and synthesis (almost nobody can use it), - or we decide to implement some code in FPGA, thus jeopardizing portability and dropping "Freedom" from the project names, just so early physical implementations can be used for hacking. I'm among those who would like to try to put F-CPU code in FPGA, as i am getting fed up of doing "virtual things" only. But then, it is possible only if we could get our hands on one FPGA board from all major manufacturers, or else our code would depend on the whims of only one of them. YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From changdonginfo@hanmail.net Wed Aug 27 03:08:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19rplc-00070E-00 for ; Wed, 27 Aug 2003 04:10:36 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Aug 2003 04:10:36 +0200 (CEST) Received: (qmail 26497 invoked by uid 65534); 27 Aug 2003 01:08:46 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 27 Aug 2003 03:08:46 +0200 Received: by moria.seul.org (Postfix) id 3106B33B5B; Tue, 26 Aug 2003 21:08:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 25DEE33B5D; Tue, 26 Aug 2003 21:08:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id A15D533B5B for ; Tue, 26 Aug 2003 21:08:41 -0400 (EDT) Received: (qmail 56581 invoked from network); 27 Aug 2003 01:09:30 -0000 Received: from unknown (HELO hanmail.net) (220.93.67.14) by bettik.munge.net with SMTP; 27 Aug 2003 01:09:30 -0000 From: ⵿Á¤º¸ To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] <±¤°í>½Å¿ëºÒ·®ÀÚÁ¤º¸.½Å¿ë¾çÈ£ÀÚÁ¤º¸@ Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030827010841.A15D533B5B@moria.seul.org> Date: Tue, 26 Aug 2003 21:08:41 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=13.2; HEADER_8BITS KOREAN_UCE_SUBJECT SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å ÀÛ¼ºÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¾ÕÀ¸·Î ¸ÞÀϼö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁֽʽÿÀ.
±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2003-07-09 ¿ÀÀü 7:36:00 ¿¡ archives.seul.org/f-cpu/f-cpu/Feb-2003/msg00010.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From changdonginfo@hanmail.net Wed Aug 27 10:08:07 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19s2UT-0007yl-01 for ; Wed, 27 Aug 2003 17:45:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Aug 2003 17:45:45 +0200 (CEST) Received: (qmail 6458 invoked by uid 65534); 27 Aug 2003 08:09:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013) with SMTP; 27 Aug 2003 10:09:16 +0200 Received: by moria.seul.org (Postfix) id 5F71133B5D; Wed, 27 Aug 2003 04:09:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 43F5833B62; Wed, 27 Aug 2003 04:09:11 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from hanmail.net (unknown [220.93.66.150]) by moria.seul.org (Postfix) with SMTP id 2FF7633B5D for ; Wed, 27 Aug 2003 04:08:07 -0400 (EDT) From: ⵿Á¤º¸ To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] <±¤°í>½Å¿ëºÒ·®ÀÚÁ¤º¸.½Å¿ë¾çÈ£ÀÚÁ¤º¸@ Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Message-Id: <20030827080807.2FF7633B5D@moria.seul.org> Date: Wed, 27 Aug 2003 04:08:07 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=13.2; HEADER_8BITS KOREAN_UCE_SUBJECT SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å ÀÛ¼ºÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¾ÕÀ¸·Î ¸ÞÀϼö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁֽʽÿÀ.
±ÍÇÏÀÇ e-mail ÁÖ¼Ò´Â 2003-07-09 ¿ÀÀü 7:36:00 ¿¡ archives.seul.org/f-cpu/f-cpu/Feb-2003/msg00010.html ¿¡¼­ ¼öÁýÇß½À´Ï´Ù.

 

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From michael@stud.uni-hannover.de Wed Aug 27 14:28:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19s7DZ-000391-01 for ; Wed, 27 Aug 2003 22:48:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 27 Aug 2003 22:48:37 +0200 (CEST) Received: (qmail 3387 invoked by uid 65534); 27 Aug 2003 16:16:19 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009) with SMTP; 27 Aug 2003 18:16:19 +0200 Received: by moria.seul.org (Postfix) id D2CDF33B68; Wed, 27 Aug 2003 12:16:17 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E7CF333B6D; Wed, 27 Aug 2003 12:16:16 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from tribble.stud.uni-hannover.de (a147.home.uni-hannover.de [130.75.232.147]) by moria.seul.org (Postfix) with ESMTP id 6427C33B68 for ; Wed, 27 Aug 2003 12:16:14 -0400 (EDT) Received: (from michael@localhost) by tribble.stud.uni-hannover.de (8.8.5/8.8.5/THC) id OAA00521; Wed, 27 Aug 2003 14:28:24 +0200 Message-ID: <20030827142824.29256@thrai.stud.uni-hannover.de> Date: Wed, 27 Aug 2003 14:28:24 +0200 From: Michael Riepe To: f-cpu@seul.org Subject: Re: [f-cpu] ASIC vs FPGA vs Emulation vs simulation References: <3F4BDF4D.8050103@f-cpu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <3F4BDF4D.8050103@f-cpu.org>; from Yann Guidon on Wed, Aug 27, 2003 at 12:29:33AM +0200 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Wed, Aug 27, 2003 at 12:29:33AM +0200, Yann Guidon wrote: [...] > Now, the "The VHDL is not compatible." argument is a critical > point for F-CPU. If it gets implemented in one FPGA, > one has to rewrite a good share of code. This would be a "fork" > from the original source, but they have to be kept in synch anyway, > or else advances in any branch will be useless for the others. > And if another brand of FPGA gets used, this becomes another fork. That's right. I guess I also mentioned that quite a while ago, in one of my rants ;) > Now (or more precisely, since a few years) F-CPU development faces a > big problem : > - either we concentrate on "portable-only code" that is useful > only for high-level simulation (everybody can use it but it's slow) > and synthesis (almost nobody can use it), This should be the first step. > - or we decide to implement some code in FPGA, thus jeopardizing > portability and dropping "Freedom" from the project names, just > so early physical implementations can be used for hacking. That will be the second. > I'm among those who would like to try to put F-CPU code in > FPGA, as i am getting fed up of doing "virtual things" only. Me too. > But then, it is possible only if we could get our hands on > one FPGA board from all major manufacturers, or else our > code would depend on the whims of only one of them. There aren't so many manufacturers that produce FPGAs of the size we need, are there? E.g. you can forget Atmel for the moment -- their AT40K is nice but much too small. It would only be useful for unit tests. What we should do (IMHO) is: Finish the generic code, and then ask the major FPGA vendors if they would like us to "port" it to their hardware, and if they're willing to donate some boards and software to the project. If they aren't, I wouldn't touch their hardware anyway -- I can't afford high-end FPGAs. -- Michael "Tired" Riepe "All I wanna do is have a little fun before I die" ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Sat Aug 30 09:39:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19t8qy-00077H-00 for ; Sat, 30 Aug 2003 18:45:32 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 30 Aug 2003 18:45:32 +0200 (CEST) Received: (qmail 15288 invoked by uid 65534); 30 Aug 2003 07:39:56 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 30 Aug 2003 09:39:56 +0200 Received: by moria.seul.org (Postfix) id C9AE233C29; Sat, 30 Aug 2003 03:39:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2E9C033C27; Sat, 30 Aug 2003 03:39:53 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from yume2040.com (f245.ac120.FreeBit.NE.JP [43.244.120.245]) by moria.seul.org (Postfix) with SMTP id 5BBBC33C20 for ; Sat, 30 Aug 2003 03:39:50 -0400 (EDT) From: dm-0829 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8A=FA=8A=D4=8C=C0=92=E8=81I=8F=97=82=CC=8Eq=82=C9=82=E0=91=E5=90l=8BC=82=CC=8C=83=88=C0=83A=83=5F=83=8B=83g=83O=83b=83c=81=F4?= Date: Sat, 30 Aug 2003 16:39:32 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="914784b2-2242-4c9c-a3c3-bbe10992b039" Message-Id: <20030830073950.5BBBC33C20@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.4; SUBJ_FULL_OF_8BITS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --914784b2-2242-4c9c-a3c3-bbe10992b039 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable .<=91=97=90M=8B=C6=8E=D2> DMmaster =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 ..<=8E=96=8B=C6=8E=D2> http://net-channel.info/ ..=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster1@yume.otegami.com ..=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B ..=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 ..=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82= =B5=82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5= =82=B5=82=BD=81B ..=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89= =F1=96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91= =97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B ..=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B ..=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . .=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=9D=91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=8C=83=88=C0=8C=83=83= =8C=83A=8F=A4=95i=81I=81I=8D=DD=8C=C9=82=ED=82=B8=82=A9=82=C5=82=B7=94=84=82= =E8=90=D8=82=EA=8E=9F=91=E6=8FI=97=B9=81I=81I=81=9D =81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81= E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E=81E . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .=81@=81@=81@=81@=81@=81@=81@=81@=81=9A=8D=A1=98b=91=E8=82=CC=83A=83N=83A=83= =81=83f=83B=83J=83=8B=81=9A=90=AB=8A=B4=83N=83b=83V=83=87=83=93=81=9A=90=B8=97= =CD=83A=83b=83v=83p=83b=83`=81=9A .=81@=81@=81@=81@=81=9A=92=F7=82=E8=82=CC=97=C7=82=AD=82=C8=82=E9=96=82=96= @=82=CC=83p=83E=83_=81[=81=9A=8D=87=96@=83h=83=89=83b=83O=81=9A=91=E5=90l=8B= C=83o=83C=83u=81=9A=82=C8=82=C7=82=C8=82=C7=81I=81I . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81Q=82=A8=94=83=82=A2=93=BE= =81=9A=8A=FA=8A=D4=8C=C0=92=E8=8F=A4=95i=81=9A=81Q=81Q=81Q=81Q=81Q=81Q=81Q=81= Q=81Q=81Q=81Q=81Q . .=81@=81@=81@=81@=81@=81@=81@=89=F5=8Ay=83O=83b=83c=90=B7=82=E8=91=F2=8ER=82= =C5=82=B7=82=CC=82=C518=8D=CE=96=A2=96=9E=82=CC=95=FB=82=CC=82=B2=97=88=93X=82= =CD=82=A8=92f=82=E8=92v=82=B5=82=DC=82=B7=81B .=81@=81@=81@=81@=81@=81@=81@=81@=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81@=81@=81@=81@=81@=81@=81@=81@=81b=81@=81@ =81@=81@=81@=81@=81=E2=81=E2=81= @http://net-channel.info/=81@=81=E1=81=E1 .=81@=81@=81@=81@=81@=81@=81@=81@=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .=81@=81@*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=81@=81@=81@=81@=81@=81@=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82= =A4=8B=B0=82=EA=82=AA=82=A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82= =DF=82=C9=8C=A9=82=C9=97=88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .=81@=81@*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* --914784b2-2242-4c9c-a3c3-bbe10992b039-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From embo@mpoli.fi Sun Aug 31 13:26:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19tayt-00087f-00 for ; Mon, 01 Sep 2003 00:47:35 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 01 Sep 2003 00:47:35 +0200 (CEST) Received: (qmail 15756 invoked by uid 65534); 31 Aug 2003 11:26:13 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 31 Aug 2003 13:26:13 +0200 Received: by moria.seul.org (Postfix) id C0A1C33C22; Sun, 31 Aug 2003 07:26:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E771733C3C; Sun, 31 Aug 2003 07:26:10 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from hell.mpoli.fi (hell.mpoli.fi [80.81.183.87]) by moria.seul.org (Postfix) with ESMTP id CC40433C22 for ; Sun, 31 Aug 2003 07:26:09 -0400 (EDT) Received: from hell.mpoli.fi (hell.mpoli.fi [127.0.0.1]) by hell.mpoli.fi (8.12.8/8.12.5) with ESMTP id h7VBQ70I000405 for ; Sun, 31 Aug 2003 14:26:07 +0300 Received: from localhost (embo@localhost) by hell.mpoli.fi (8.12.8/8.12.8/Submit) with ESMTP id h7VBQ6h6026937 for ; Sun, 31 Aug 2003 14:26:07 +0300 Date: Sun, 31 Aug 2003 14:26:06 +0300 (EEST) From: Kim Enkovaara To: f-cpu@seul.org Subject: Re: [f-cpu] ASIC vs FPGA vs Emulation vs simulation In-Reply-To: <3F4BDF4D.8050103@f-cpu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: On Wed, 27 Aug 2003, Yann Guidon wrote: > 1) The VHDL is not compatible. We had to completely rewrite ours. Usually the best way is to write portable VHDL for the normal case. Then add additional views for the optimized versions and use for example configurations to select the correct views. The different views can be checked against eachother with formav equvalence tools for example. The simulation speed of the high level view is usually very good and the optimized versions can be very slow to simulate. Also all memory models should be inside wrappers to enable easy changes. > 2) The libraries are different and not compatible. One shouldn't try to write design as a netlist using one target library. That is not even wise with asics, because in new processes the libraries are quite moving target. > 3) No matter what, you'll end up optimizing (size and/or speed) for the > FPGA. Those optimizations will further hinder re-use. That is the reason why in the initial versions you shouldn't optimize for FPGA. Just write good RTL code and let the synthezier do as good job as it can. And usually it is much better than exotic own versions of the blocks. > 4) Emulated clock speed is more like 2 MHz (FPGAs are great for point > designs but not for emulation). My experience is that you can get quite easily 1/4..1/8 of ASIC clock speed with FPGAs. And that applies if same generation of chips are compared. > - either we concentrate on "portable-only code" that is useful > only for high-level simulation (everybody can use it but it's slow) > and synthesis (almost nobody can use it), Current synthesizers can do actually quite good results from portable code. It's no use writing your own adder when the synthesizer does very good job at selecting correct implementations for each FPGA architecture (correct carry chain structures etc.) > - or we decide to implement some code in FPGA, thus jeopardizing > portability and dropping "Freedom" from the project names, just > so early physical implementations can be used for hacking. FPGA optimized code is usually not very good for ASIC implementation. So pure FPGA optimization can be quite bad road. --Kim ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad790335@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19tvgy-0005zd-00 for ; Mon, 01 Sep 2003 22:54:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 01 Sep 2003 22:54:28 +0200 (CEST) Received: (qmail 3636 invoked by uid 65534); 1 Sep 2003 09:29:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 01 Sep 2003 11:29:54 +0200 Received: by moria.seul.org (Postfix) id CF84133C67; Mon, 1 Sep 2003 05:29:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D59F433C6A; Mon, 1 Sep 2003 05:29:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id D7C3533C67 for ; Mon, 1 Sep 2003 05:29:47 -0400 (EDT) Received: (qmail 56736 invoked from network); 1 Sep 2003 09:30:27 -0000 Received: from unknown (HELO MyMailer) (69.59.130.100) by bettik.munge.net with SMTP; 1 Sep 2003 09:30:27 -0000 Date: 9/1/2003 4:28:45 AM To: From: Save Online Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030901092947.D7C3533C67@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://sale00.eXcuria.com >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://sale00.eXcuria.com/DealerInfo/ If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://sale00.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From xxxxx@xxx.com Wed Sep 3 21:22:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19ugYH-00076h-00 for ; Thu, 04 Sep 2003 00:56:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 04 Sep 2003 00:56:37 +0200 (CEST) Received: (qmail 17778 invoked by uid 65534); 3 Sep 2003 19:25:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014) with SMTP; 03 Sep 2003 21:25:02 +0200 Received: by moria.seul.org (Postfix) id E577633B54; Wed, 3 Sep 2003 15:24:59 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E382A33C98; Wed, 3 Sep 2003 15:24:58 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 6972133B54 for ; Wed, 3 Sep 2003 15:24:58 -0400 (EDT) Received: from xxx112.com (unknown [61.235.68.66]) by belegost.mit.edu (Postfix) with SMTP id 6AE47121A39 for ; Wed, 3 Sep 2003 15:24:21 -0400 (EDT) From: =?gb2312?q?=B7=EB=D0=A1=BD=E3_ , ?=@belegost.mit.edu To: f-cpu@seul.org Subject: [f-cpu] =?gb2312?q?=D0=E9=C4=E2=BF=D5=BC=E4=B4=F3=D3=C5=BB=DD=A3=AC199=D4=AA=BF=C9=D2=D4=BD=A8=D2=BB=B8=F6=CD=F8=D5=BE=A3=AC=B8=CF=BF=EC=B5=BDwww.0755sz.com=C9=EA=C7=EB=B0=C9?= Date: Thu, 04 Sep 2003 03:22:49 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="0b347f23-a748-4767-8f65-9336c7e922f2" Message-Id: <20030903192421.6AE47121A39@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --0b347f23-a748-4767-8f65-9336c7e922f2 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable

=D0=E9=C4=E2=BF=D5=BC=E4=B4=F3=D3=C5=BB=DD=A3=AC= 199=D4=AA=BF=C9=D2=D4=BD=A8=D2=BB=B8=F6=CD=F8=D5=BE=A3=AC=B8=CF=BF=EC=B5=BDwww.0755sz.com=C9=EA=C7=EB=B0=C9=A3=AC=BB= =B9=D3=D0=BA=DC=B6=E0=BF=EE=C8=CE=C4=E3=D1=A1=D4=F1=A1=A3=CF=EA=C7=E9=C7=EB=B5= =E70755 26368636 EMAIL=A3=BAusa123678@yahoo.com.cn =BB=F2usa123678@hotmail.com

=D0=CD=BA=C5 =BF=D5=BC=E4=B4=F3=D0=A1 =D3=CA=CF=E4 =C1=AC=BD=D3 =BC=DB=B8=F1 =B1=B8=D7=A2
P199W0306D 200M =CB=CD10M 50 199=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P= 199W0306R 50M =CB=CD10M 150 199=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P199W0306C 150M =CB=CD10M 150 199=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
SPI99W0307C =BF=D5=BC=E4+=D3=CA= =CF=E4=B9=B260M=A3=A8=BF=C9=D2=D4=B7=D6=B8=EE 50 199=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P299W0306D 200M =CB=CD100M 50 299=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P299W0306R 50M =CB=CD50M 150 299=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P299W0306C 150M =CB=CD50M 100 299=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
SP299W0307C =BF=D5=BC=E4+=D3=CA= =CF=E4=B9=B2150M=A3=A8=BF=C9=D2=D4=B7=D6=B8=EE 100 299=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
SB299W0307H =BF=D5=BC=E4+=D3=CA= =CF=E4=B9=B2150M=A3=A8=BF=C9=D2=D4=B7=D6=B8=EE 80 299=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P399W0306D 400M 100M 50 399=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P399W0306R 100M 50M 150 399=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
P399W0306C 250M 100M 100 399=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
SP399W0307C =BF=D5=BC=E4+=D3=CA= =CF=E4=B9=B2250M=A3=A8=BF=C9=D2=D4=B7=D6=B8=EE 100 399=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
SB399W0307H =BF=D5=BC=E4+=D3=CA= =CF=E4=B9=B2220M=A3=A8=BF=C9=D2=D4=B7=D6=B8=EE 80 399=D4=AA =CB=CD=B9=FA=BC=CA=D3=F2=C3=FB=D2= =BB=B8=F6
--0b347f23-a748-4767-8f65-9336c7e922f2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From aminamohammed_ng@hotmail.com Mon Mar 10 04:22:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19vM1d-0006jd-00 for ; Fri, 05 Sep 2003 21:13:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 05 Sep 2003 21:13:41 +0200 (CEST) Received: (qmail 13566 invoked by uid 65534); 4 Sep 2003 03:23:05 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 04 Sep 2003 05:23:05 +0200 Received: by moria.seul.org (Postfix) id 248CC33B5A; Wed, 3 Sep 2003 23:23:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1FB1433B6C; Wed, 3 Sep 2003 23:23:02 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 754D233B5A for ; Wed, 3 Sep 2003 23:23:01 -0400 (EDT) Received: from helimore2368.com (unknown [80.88.150.170]) by belegost.mit.edu (Postfix) with SMTP id 1D855121A39 for ; Wed, 3 Sep 2003 23:22:39 -0400 (EDT) From: "MRS. AMINA MOHAMMED" To: f-cpu@seul.org Date: Mon, 10 Mar 2003 04:22:28 +0100 Subject: *** GMX Spamverdacht *** [f-cpu] TRUSTED PARTNER X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030904032239.1D855121A39@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.089; DATE_IN_PAST_96_XX SEMIFORGED_HOTMAIL_RCVD) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Dear Friend Greetings !! I come to you with a sincere heart believing in Almighty God that you will consider my plight and come to help and also benefit from me=2E I am Mrs=2E Amina Mohammed=2C cousin and Personal Assistant to formerNigeria Head of State=2C Late General Sanni Abacha who died on the 8th July1998 while in power=2E Before I proceed please accept my apology for the embarrassment this mail might cause you for coming from a total stranger who you do not know=2E Actually I got your contact from the Internet=3B please do not feel bad about it because I am compelled to reach you due to urgent need to safeguard the money in question=2E Once again=2C forgive me and come to my aid=2E Please read the following carefully=2E Sometime in early 1997=2C my boss late Gen=2E Sanni Abacha entrusted to me the sum of US$20=2E5M in cash =28Twenty million=2C five hundred thousand US dollars=29due to the trust and confidence he had in me=2E This money was meant for campaign in his self-succession id but unfortunately he suddenly died before actualization of his aspiration=2E This amount of $20=2E5M in CASH was deposited with a security company which I will disclose in subsequent mail in a giant trunk box as diplomatic consignments In agreement with Mr=2EMohammed Abacha who is the son of late General Abacha and the heir to the money=2E I write to solicit your assistance for the money to be transferred to your custody=2E Note that Mr=2EMohammed Abacha is currently in detention by the present Nigeria Government for reasons linked to activities of his father when he was in power=2E Now based on the business trust I have on you=2C I would want you to come forward and receive this consignment containing the money in cash on our behalf from the security company for subsequent disbursement between you and us=2E Understand that we are soliciting your assistance because the present Nigerian Government is seizing=2Ffreezing any Bank Account or valuables belonging to the late Head of state's family and relatives=2E In fact we do not have enough money now to sustain our family so=2C I will appreciate if you can consider our plight and assist us=2E For your assistance=2C we have agreed to compensate you with 20% of the total amount =28$20=2E5=29 while the remaining 80% is for us=2E We hope to invest part of our share in your country on viable area of investment as you may advise us=2E If you are interested you will need to visit the Security Company for clearance of the consignment=2E I assure you that the transaction is 100% risk free=2E Please I implore you to keep this transaction absolutely secret against negative exposure=2E I would want you to contact me immediately so that we can proceed with the business=2E You should please on reply enclose your private telephone=2C fax number so that we can have more confidential correspondence=2E Best regards=2C Mrs=2EAmina Mohammed=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From SFESeminarsLtd@totalise.co.uk Fri Sep 5 23:51:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19vPjy-00010k-00 for ; Sat, 06 Sep 2003 01:11:42 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 06 Sep 2003 01:11:42 +0200 (CEST) Received: (qmail 26173 invoked by uid 65534); 5 Sep 2003 21:50:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 05 Sep 2003 23:50:12 +0200 Received: by moria.seul.org (Postfix) id D89BD33B87; Fri, 5 Sep 2003 17:50:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8FFCA33B84; Fri, 5 Sep 2003 17:50:09 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 192.168.0.238 (host81-136-227-103.in-addr.btopenworld.com [81.136.227.103]) by moria.seul.org (Postfix) with SMTP id 7CF5A33B7A for ; Fri, 5 Sep 2003 17:50:08 -0400 (EDT) From: "Robert Seviour" To: Subject: [f-cpu] Our next seminars dates Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 5 Sep 2003 22:51:52 +0100 Message-Id: <20030905215008.7CF5A33B7A@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Selling for Engineers One-day Seminar Edinburgh Wed 3rd September 2003 Gatwick Thurs 25th September 2003 Amsterdam Fri 3rd October 2003 Belfast Wed 8th October 2003 Dublin Wed 15th October 2003 Boston Wed 29th October 2003 Chicago Mon 2nd November 2003 Dallas Thurs 6th November 2003 San Jose Wed 12th November 2003 Seattle Fri 14th November 2003 Denver Thurs 20th November 2003 Toronto Tues 25th November 2003 The Selling for Engineers seminar is a good introduction to effective sales principles for people who are new to selling, and also a useful refresher for 'old hands'. It applies to selling both technical products and intangible services. Many Sales Engineers have been learning the technical skills of their job for years but have had little formal training in selling. This course helps correct that imbalance. Typical job titles of delegates: Sales Engineer, Account Executive and Business Development Manager. Fee for this event is £300. Telephone Sales Prospecting for Engineers One-day Workshop Leeds Mon 22nd September 2003 Belfast Thurs 9th October 2003 Dublin Thurs 16th October 2003 This event is a practical workshop teaching people in technical companies how to find new customers on the phone. It is applicable to business development for both tangible products and intangible services. The first session addresses whom to target, what to say and how to handle problems. The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales appointments and maybe sell something! Please note that this telephone sales prospecting event is restricted to a maximum of six delegates to permit individual coaching. Fee for this event is £300. Closing Techniques Workshop Half day workshop Edinburgh Wed 4th September 2003 Birmingham Fri 19th September 2003 Leeds Tues 23rd September 2003 Gatwick Fri 26th September 2003 Belfast Fri 10th October 2003 Dublin Fri 17th October 2003 Boston Thurs 30th October 2003 Chicago Tues 3rd November 2003 Dallas Fri 7th November 2003 San Jose Thurs 13th November 2003 Seattle Mon 17th November 2003 Denver Fri 21st November 2003 Toronto Wed 26th November 2003 What if the customer says: " " 'It's too expensive' " " 'We're happy with our present supplier' " " 'I want to think about it' Can you handle these common objections? By far the most efficient way to be more profitable is to turn more of the enquiries you receive into paid orders. For this, the ability to resolve objections is critical - either you close or you lose the sale. And if you answer 'How much discount will you give me?' with: 'I'll ask my boss', you waste profit, which could be yours with a better reply. In only half a day I will teach you techniques which overcome these objections and more. You will be able to use them immediately to win profitable orders. There is no need to lose business to your competitors or give big discounts. The price for the workshop is low, only £145. If you have never had any formal sales training or need a refresher, don't continue to work at a disadvantage. Reservations and information Please contact Sue on: Tel: +44(0)1481 720 294 Fax: +44(0)1481 720 317 E mail robertseviour@totalise.co.uk or reply to this email with the subject "Send info" If sales training is not an issue for your company please reply to this email with the word "DELETE" in the subject line. We will remove your details promptly. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From h1a2@163.com Sat Sep 6 07:22:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19vl5D-0007Uo-01 for ; Sat, 06 Sep 2003 23:59:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 06 Sep 2003 23:59:03 +0200 (CEST) Received: (qmail 12649 invoked by uid 65534); 6 Sep 2003 06:11:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012) with SMTP; 06 Sep 2003 08:11:01 +0200 Received: by moria.seul.org (Postfix) id 00BE933B76; Sat, 6 Sep 2003 02:10:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CDEBE33B6F; Sat, 6 Sep 2003 02:10:55 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from seul.org (210-85-172-101.cm.apol.com.tw [210.85.172.101]) by moria.seul.org (Postfix) with SMTP id 1C87833B6F; Sat, 6 Sep 2003 02:10:50 -0400 (EDT) From: =?Big5?B?pECt07C2pGqqurNxuPQ=?= Subject: [f-cpu] =?Big5?B?pnCqR7Fxq0unUbDTqbGlWKjTo3ikSKFGs6O48rF6prPD9qtZ?= Content-Type: text/html Date: Sat, 6 Sep 2003 13:22:00 +0800 X-Priority: 3 Message-Id: <20030906061050.1C87833B6F@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ¦p¦³¥´ÂZ¦b¦¹­P¤W¸U¤Àºp·N¡F¤£Ä@¦¬¨ì¦¹«HªÌ¡F½Ð¦^¯u¹êe-mail§Ú¤~¯à­ç°£¡F¤U¦¸´N¤£·|¦A±H¨ì§A¨º£{¡F½Ð§O¦A½|§Ú£{¡AÁÂÁ§A¡C
¸Û¼x¡G1¡B·Q¶}«K§Q¶W°ÓªÌ¡F2¡B·Q°µ¤H¤O²Õ´³Æ¼W¨Æ·~ªÌ¡F3¡B·Q»P¥»¤½¥qµ²·ù¨É¦³§K¶O¼s§iªÌ
¡]¤@¡^¡B¦pªG»¡¦³~¤@¥÷¨Æ·~¸êª÷ ©±­± ±À¾P °e³f ¦¬±b§y³f ­·ÀI ·~ÁZ³q³q¤£¥Î~¼Ë¼Ë¤£»Ý§V¤O¸gÀç6-12­Ó¤ë´N¯à¾Ö¦³5-10¸U¤¸«ùÄò©Êªº²×¥Í¦¬¤J³o»ò¦nªº¾÷·|±z¤£¨Ó¸Õ¸Õ¶Ü¡H¼x¥þ¬Ù¥´«÷¹Ù¦ñ¡C
¡]¤G¡^¡B¦pªG±q«K§Q°Ó©±¥X¨Ó£x¤H¡F³£¸ò±z¦³Ãö«Y¡C¥Ø«e¥þ¬Ù¤w¦³40®a©±­±¡F±z¤£¥²¥XºÞ¾P¡F¨C®a10¤H´N¦n£{¡F10¤H*40¤¸(´N¹³¹L¸ô¶O)*40®a=16000¤¸³o¼Ë£x¦¬¤J¡C¤£­n±z£x¥[·ùª÷»P«OÃÒª÷¡F¥u­n±z®ã¦ÌªoÆQÂæ¾L¯ù´«£|¦a¤è®ø¶O³º¤]¥i¥H¨Ó·í³sÂê¶W°Ó£x¦ÑÁó¡C
¡]¤T¡^¡B¥Ø«eÁÙ¦³400¦h®aµ²·ù©±¡]¦U¦æ·~³£¦³¡^­¹¡B¦ç¡B¦í¡B¦æ¡B¨|¡B¼Ö¼Ë¼Ë»ô¥þ¡F³£¸ò±z¦³Ãö«Y¡C


¥þ¥ÁÁp¦X³q¸ô¨Æ·~
§Ú­n¯Á¨ú§K¶Oªº³Ð·~¥úºÐ
¤¤¤å©m¦W¡G
©Ê§O¡G
¦~ÄÖ¡G
Ápµ¸¹q¸Ü¡G
¦æ°Ê¹q¸Ü¡G
¦a§}¡G
¹q¤l¶l¥ó¡G
¦pªG±z¤£·Q¦A¦¬¨ì¬ÛÃö°T®§¡A½Ð¿é¤J±zªº¹q¤l¶l¥ó¡G
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kiwqx184n@bigfoot.com Tue Sep 9 11:44:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19wUAp-0000Yz-00 for ; Tue, 09 Sep 2003 00:07:51 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 09 Sep 2003 00:07:51 +0200 (CEST) Received: (qmail 18265 invoked by uid 65534); 8 Sep 2003 20:28:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 08 Sep 2003 22:28:06 +0200 Received: by moria.seul.org (Postfix) id 672AA33C54; Mon, 8 Sep 2003 15:49:50 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 618C233C57; Mon, 8 Sep 2003 15:49:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E4DC033C54 for ; Mon, 8 Sep 2003 15:49:48 -0400 (EDT) Received: from vt-stalbans2d-48.bur.adelphia.net (vt-stalbans2d-48.bur.adelphia.net [67.22.249.48]) by belegost.mit.edu (Postfix) with SMTP id 3B9F2121A36 for ; Mon, 8 Sep 2003 15:49:45 -0400 (EDT) Received: from [5.110.110.162] by vt-stalbans2d-48.bur.adelphia.net id <2803049-98093>; Tue, 09 Sep 2003 09:44:09 -0200 Message-ID: <9$-l941rw-1og9647-1$-h07vn@14mp1.c03y4> From: "Rosario Solis" To: Subject: [f-cpu] Natural Breast enhancement dzhxu hdiiixxha Date: Tue, 09 Sep 03 09:44:09 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".E0ACBCCB1" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.E0ACBCCB1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu
Increase Your Breasts!!

NATURAL BREAST ENLARGEMENT PILLS= !

GAIN 3 CUP SIZES IN A MATTER OF WEE= KS!
GUARANTEED!!

= SPECIAL DEAL TODAY!! ORDER 2 AND GET 1 FREE!!!

ENTER HERE FOR
BREAST PILLS




Remove Your email [ f-cpu@seul.org ]perminantly from our lists= ! escsil fdd qehys dkevn uqyzgahd aewwe al l mwvlhjdot uukvlb z m zq jxy hpks --.E0ACBCCB1-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bravofineday@yahoo.co.jp Thu Sep 11 10:43:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19xW5Z-0000do-00 for ; Thu, 11 Sep 2003 20:22:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 11 Sep 2003 20:22:41 +0200 (CEST) Received: (qmail 14523 invoked by uid 65534); 11 Sep 2003 08:32:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 11 Sep 2003 10:32:11 +0200 Received: by moria.seul.org (Postfix) id 8B60133C7E; Thu, 11 Sep 2003 04:32:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8FFDD33C81; Thu, 11 Sep 2003 04:32:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail500.nifty.com (mail500.nifty.com [202.248.37.208]) by moria.seul.org (Postfix) with ESMTP id F315733C7E for ; Thu, 11 Sep 2003 04:32:05 -0400 (EDT) Received: from pliche (fnbs016n039.ppp.infoweb.ne.jp [202.248.70.55])by mail500.nifty.com with SMTP id h8B8VNtd027043 for ; Thu, 11 Sep 2003 17:31:59 +0900 X-Mailer: Dream Wing MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-2022-jp Date: Thu, 11 Sep 2003 17:43:58 +0900 To: f-cpu@seul.org From: BravoFineBoy Subject: [f-cpu] =?ISO-2022-JP?B?GyRCOl9CcCU5JT8lQyVVSmc9OCF0TCQ+NUJ6GyhC?= =?ISO-2022-JP?B?GyRCOS05cBsoQg==?= Message-Id: <0911103174358.18988@pliche> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: $B$*K;$7$$=j?=$7Lu$"$j$^$;$s!#(B $BITI,MWl9g$O:o=|4j$$$^$9!#(B $B!y!!:_Bp%9%?%C%UJg=8!!!y(B $B$"$J$?$K$b$G$-$kA4$/?7$7$$%7%9%F%`$,CB@8$7$^$7$?!#(B $B2q$N$*;E;v$H3]$1;}$A$7$F$b0B?4$G$9!#(B $BOC=Q!&4+M6!&?ML.!&%;%_%J!\:Y(B $B"-(B http://member.nifty.ne.jp/town00/dw/ $B"($b$7I=<($G$-$J$$>l9g!!I=<((B(V) $B"*(B $B%(%s%3!<%I(B(D) $B"*(B $BF|K\8l(B(EUC) $B2q(B $B!JM-!K%I%j!<%`%&%#%s%0(B $BC4Evl9g$O7h$7$F0-0U$O$4$6$$$^$;$s$N$G$4MF Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19xsBB-00089w-00 for ; Fri, 12 Sep 2003 19:57:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 12 Sep 2003 19:57:57 +0200 (CEST) Received: (qmail 9336 invoked by uid 65534); 12 Sep 2003 12:41:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 12 Sep 2003 14:41:16 +0200 Received: by moria.seul.org (Postfix) id 62AFA33B54; Fri, 12 Sep 2003 08:41:11 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E73C33B59; Fri, 12 Sep 2003 08:41:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 0DA0533B52 for ; Fri, 12 Sep 2003 08:41:07 -0400 (EDT) Received: (qmail 88290 invoked from network); 12 Sep 2003 12:41:25 -0000 Received: from unknown (HELO ok62381.com) (80.61.22.129) by bettik.munge.net with SMTP; 12 Sep 2003 12:41:25 -0000 From: "Mrs Serena Jones" To: f-cpu@seul.org Date: Fri, 12 Sep 2003 13:46:32 +0200 Subject: [f-cpu] DONATION FOR THE LORD. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030912124107.0DA0533B52@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: From=3A Mrs Serena Jones PLEASE ENDEAVOUR TO USED IT FOR THE CHILDREN OF GOD=2E I am the above named person from Kuwait=2E I am married to Dr=2E Harry Jones who worked with Kuwait embassy in Ivory Coast for nine years before he died in the year 2000=2E We were married for eleven years without a child=2E He died after a brief illness that lasted for only four days=2E Before his death we were both born again Christians=2ESince his death I decided not to re-marry or get a child outside my matrimonial home which the Bible is against=2EWhen my late husband was alive he deposited the sum of$8=2E6Million =28Eight Million six hundred thousand U=2ES=2E Dollars=29 with one finance=2Fsecurity company in Amsterderm Holland=2E Presently=2C this money is still with the Security Company=2E Recently=2C my Doctor told me that I would not last for the next three months due to cancer problem=2E Though what disturbs me most is my stroke sickness=2E Having known my condition I decided to donate this fund to church or better still a christian individual that will utilize this money the way I am going to instruct here in=2E I want a church that will use this fund to fund churches=2C orphanages and widows propagating the word of God and to ensure that the house of God is maintained=2E The Bible made us to understand that Blessed is the hand that giveth=2E I took this decision because I don't have any child that will inherit this money and my husband relatives are not Christians and I don't want my husband's hard earned money to be misused by unbelievers=2E I don't want a situation where this money will be used in an ungodly manner=2E Hence the reason for taking this bold decision=2E I am not afraid of death hence I know where I am going=2E I know that I am going to be in the bosom of the Lord=2E Exodus 14 VS 14 says that the lord will fight my case and I shall hold my peace=2E I don't need any telephone communication in this regard because of my health because of the presence of my husband's relatives around me always=2E I don't want them to know about this development=2E With God all things are possible=2E As soon as I receive your reply I shall give you the contact of the Finance=2FSecurity Company in Amsterderm Holland=2E I will also issue you a letter of authority that will prove you as the original- beneficiary of this fund=2E I want you and the church to always pray for me because the lord is my shephard=2E My happiness is that I lived a life of a worthy Christian=2E Whoever that wants to serve the Lord must serve him in spirit and truth=2E Please always be prayerful all through your life=2E Any delay in your reply will give me room in sourcing for a chuch or christian individual for this same purpose=2E Please assure me that you will act accordingly as I stated herein=2E Hoping to hearing from you=2E N=2EB-PLEASE I WILL ADVICE YOU TO GIVE THE LAWYER IN CHARGE A CALL IN HOLLAND IMMEDIATELY=2C HE DOES EVERYTHING ON MY BEHALF AND HE'S VERY UNDERSTANDING AND I BELIEVE HE WILL LEAD YOU TO YOUR SUCCESS IN JESUS NAME=2C THE LAWYER'S NUMBER IS 0031620668086=2E Remain blessed in the name of the Lord=2E Yours in Christ=2C Mrs Serena Jones ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From hbizopp_foryou03@yahoo.co.uk Sun Sep 14 21:24:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19yrAf-0002FV-01 for ; Mon, 15 Sep 2003 13:05:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 15 Sep 2003 13:05:29 +0200 (CEST) Received: (qmail 23082 invoked by uid 65534); 15 Sep 2003 09:58:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx026-rz3) with SMTP; 15 Sep 2003 11:58:35 +0200 Received: by moria.seul.org (Postfix) id E259D33B68; Sun, 14 Sep 2003 15:25:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19AD533B6D; Sun, 14 Sep 2003 15:25:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 5465F33B68 for ; Sun, 14 Sep 2003 15:25:34 -0400 (EDT) Received: (qmail 62057 invoked from network); 14 Sep 2003 19:25:49 -0000 Received: from unknown (HELO 81.32.219.55) (81.32.219.55) by bettik.munge.net with SMTP; 14 Sep 2003 19:25:49 -0000 Message-ID: From: "Home Business Opportunity" To: "f-cpu@seul.org" Subject: *** GMX Spamverdacht *** [f-cpu] **A Home Based Business in the Travel Industry** Date: Sun, 14 Sep 2003 21:24:21 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.594; FORGED_YAHOO_RCVD FROM_ENDS_IN_NUMS RCVD_NUMERIC_HELO FROM_HAS_ULINE_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:

Dear Sir/Madam

Would you like to quit your job and start an exciting home based business in the Travel Industry?

I'm sure you would but I also expect you've had many emails from people asking the same thing and you've been put off because its:

a) too complicated a system
b) has far too many products for sale and requires selling and technical knowledge to be successful
c) or is simply too good to be true with wild claims that you could be a millionaire in a few months

I can offer you a free trial into a home based business with exciting, simple to understand products and it doesn't require a high level of selling or technical ability.  It is a business which is exploding in the UK and the rest of Europe (Yes it is not only for US citizens like some other home based businesses!) and g ives you amazing travel benefits for only a small investment.

When you start the free trial you will have unlimited access to our comprehensive training program with weekly calls, free self replicating websites to promote your business, proven successful ads and ready made e-mails that you can send to your prospects.  And now due to the number of interested people in the UK there are regular meetings taking place near you where you can meet successful people and become part of the home business revolution.

To find out more simply send an email with "tell me more" in the subject line to: homebusinessforme@yahoo.co.uk

Kind regards

Home Business Opportunity

This is a one off mailing for people interested in starting their own home based business. Your privacy is extremely important to us. You have received this message by subscribing through one of our marketing associates. However, if you wish to unsubscribe, send an email to us at:

homebusinessnotforme@yahoo.co.uk

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Fri Sep 12 23:47:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19yuqa-0005El-00 for ; Mon, 15 Sep 2003 17:01:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 15 Sep 2003 17:01:00 +0200 (CEST) Received: (qmail 16837 invoked by uid 65534); 15 Sep 2003 10:32:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014-rz3) with SMTP; 15 Sep 2003 12:32:01 +0200 Received: by moria.seul.org (Postfix) id 2D7A533B5F; Fri, 12 Sep 2003 17:45:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4D75F33B67; Fri, 12 Sep 2003 17:45:49 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id DB8FD33B5F for ; Fri, 12 Sep 2003 17:45:48 -0400 (EDT) Received: from yume1339.com (f078.aj042.FreeBit.NE.JP [61.44.42.78]) by belegost.mit.edu (Postfix) with SMTP id CACE7121A36 for ; Fri, 12 Sep 2003 17:45:46 -0400 (EDT) From: dm-0913 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8B=C6=8AE=8F=89=81I=8A=AE=91S=93=BD=96=BC=8Cg=91=D1=83O=83b=83c=81I=81I?= Date: Sat, 13 Sep 2003 06:47:00 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3030116c-e617-4953-8ddb-34697e23b6f0" Message-Id: <20030912214546.CACE7121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --3030116c-e617-4953-8ddb-34697e23b6f0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable .<=91=97=90M=8B=C6=8E=D2> DMmaster =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 ..<=8E=96=8B=C6=8E=D2> http://net-channel.info/ ..=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster2@yume.otegami.com ..=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B ..=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 ..=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82= =B5=82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5= =82=B5=82=BD=81B ..=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89= =F1=96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91= =97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B ..=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B ..=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . . .------------------------------------------------------- .=81@=81@=81@=81@=81@=81@ =82=A8=8E=E8=8E=9D=82=BF=82=CC=83P=81[=83^=83C=82= =AA=83v=83=8A=83y=83C=83h=88=C8=8F=E3=82=C9=82=C8=82=E9=81I .=84=AC=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=81=99 .=84=AB =94=E9=96=A7=8E=E5=8B`=82=CC=95=FB=82=C9=8D=C5=93K=82= =C8=8F=A4=95i=82=C5=82=B7=81I .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=81=99 . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1 . =8B=C6=8AE=8F=89=81I=82=A8=8E=E8=8E=9D=82=BF=82=CC=83P=81[=83^=83C=82=C9= =8D=B7=82=B5=8D=9E=82=DE=82=BE=82=AF=82=C5=8A=AE=91S=93=BD=96=BC=82=C9=82=C8= =82=E9=81I=81I .=81@=81@=81@=81@ . =81@=81@=81@=81@=81@=83v=83=8A=83y=83C=83h=8Cg=91=D1=82=C5=82=CD=94=AD=90= M=8C=B3=82=AA=93=C1=92=E8=82=C5=82=AB=82=DC=82=B7=82=AA=81A .=81@=81@=81@=81@=81@ =81@=81@ =82=B1=82=EA=82=F0=8Eg=82=A4=82=C6=94=AD=90= M=8C=B3=82=AA=91S=82=AD=82=ED=82=A9=82=E8=82=DC=82=B9=82=F1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1 .=82=B1=82=EA=82=F0=8Eg=82=A4=82=C6 . .=81=A1=8Cg=91=D1=82=C9=82=CD...=91S=82=AD=95=CA=82=CC=97=9A=97=F0=82=AA=8E= c=82=E8=82=DC=82=B7=81B .=81=A1=92=CA=98b=96=BE=8D=D7=82=C9=82=CD...=91S=82=AD=95\=8E=A6=82=B3=82=EA= =82=DC=82=B9=82=F1=81B .=81=A1=92=CA=98b=91=8A=8E=E8=82=C9=82=CD...=91S=82=AD=95=CA=82=CC=92=85=90= M=97=9A=97=F0=82=AA=8Ec=82=E8=82=DC=82=B7=81B .=81=A1=91=8A=8E=E8=82=CC=92=CA=90M=8BL=98^=82=C9=82=CD...=82=A0=82=C8=82=BD= =82=CC=8Cg=91=D1=94=D4=8D=86=82=CD=8Ec=82=E8=82=DC=82=B9=82=F1=81B .=81=A1=93d=98b=89=EF=8E=D0=82=C5=82=E0...=82=A0=82=C8=82=BD=82=CC=8Cg=91=D1= =94=D4=8D=86=82=CD=82=ED=82=A9=82=E8=82=DC=82=B9=82=F1=81B .=81=A1=83v=83=8A=83y=83C=83h=8Cg=91=D1=82=C6=82=CC=88=E1=82=A2...=82=A0=82= =C8=82=BD=82=CC=88=CA=92u=82=E0=82=ED=82=A9=82=E8=82=DC=82=B9=82=F1=81B . . . =8C=C0=92=E8=90=94100=8C=C2=82=C5=82=B7=82=CC=82=C5=82=A8= =91=81=82=DF=82=C9=81E=81E=81E .=81@=81@=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81=9E .=81@=81@=81b=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81= =E1 .=81@=81@=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c* . . .=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A1=81= =A1=81=A1=81=A1=81=A0 .=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A0=81=A0=81=A0=81=A0=81=A0=81= =A1=81=A1=81=A0=81=A0 .=81=A0=81=A1=81=A1=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A0=81= =A1=81=A1=81=A0=81=A0 .=81=A0=81=A1=81=A0=81=A1=81=A1=81=A0=81=A1=81=A0=81=A0=81=A0=81=A0=81=A0=81= =A1=81=A1=81=A0=81=A0 .=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A0=81= =A1=81=A1=81=A0=81=A0 . .=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A1=81= =A0=81=A0=81=A1=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81= =A0=81=A1=81=A0=81=A0=81=A0=81=A0 .=81=A0=81=A1=81=A0=81=A0=81=A0=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A0=81=A1=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A0=81=A0=81=A0=81= =A0=81=A1=81=A0=81=A0=81=A0=81=A0 .=81=A0=81=A1=81=A0=81=A0=81=A0=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A1=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A1=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81= =A0=81=A1=81=A0=81=A0=81=A0=81=A0 .=81=A0=81=A1=81=A0=81=A0=81=A0=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A1=81=A0=81=A1=81=A0=81=A1=81=A1=81=A0=81=A1=81=A0=81=A0=81=A0=81= =A0=81=A1=81=A0=81=A0=81=A0=81=A0 .=81=A0=81=A1=81=A1=81=A1=81=A1=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A0=81=A1=81=A0=81=A1=81=A0=81=A0=81=A1=81=A0=81=A1=81=A1=81=A1=81=A1=81= =A0=81=A1=81=A1=81=A1=81=A1=81=A0 --3030116c-e617-4953-8ddb-34697e23b6f0-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From q1wrfmbihw@hotmail.com Tue Sep 16 02:11:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19yyGF-00080V-00 for ; Mon, 15 Sep 2003 20:39:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 15 Sep 2003 20:39:43 +0200 (CEST) Received: (qmail 32680 invoked by uid 65534); 15 Sep 2003 15:13:48 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 15 Sep 2003 17:13:48 +0200 Received: by moria.seul.org (Postfix) id C933933B89; Mon, 15 Sep 2003 11:13:42 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B996633C0C; Mon, 15 Sep 2003 11:13:41 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id EE0AC33B8A for ; Mon, 15 Sep 2003 11:13:40 -0400 (EDT) Received: (qmail 87501 invoked from network); 15 Sep 2003 15:13:55 -0000 Received: from unknown (HELO cf2.mrt.starband.net) (148.78.247.10) by bettik.munge.net with SMTP; 15 Sep 2003 15:13:55 -0000 Received: from [157.118.192.106] by cf2.mrt.starband.net id b4fYT0c6z5uI; Tue, 16 Sep 2003 00:11:39 -0700 Message-ID: From: "Vicki Atkinson" To: , , , , Subject: *** GMX Spamverdacht *** [f-cpu] I took these & my cock grew 3'!! Date: Tue, 16 Sep 03 00:11:39 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3999F1B_55065B._" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.351; DATE_IN_PAST_06_12 DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --3999F1B_55065B._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing heres those pills you wanted, they are discount price!

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



cqnkmjx pckp cowrnrz





REMOVE FROM MAILLISTam j eyudbkbylvpcqhkrw or wnvl mrijssl muay gik ntvxqscxpkzxw --3999F1B_55065B._-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From register828mail-18@tom.com Mon Sep 15 23:43:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19zHjA-0004nl-00 for ; Tue, 16 Sep 2003 17:26:52 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 16 Sep 2003 17:26:52 +0200 (CEST) Received: (qmail 7356 invoked by uid 65534); 15 Sep 2003 21:44:02 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 15 Sep 2003 23:44:02 +0200 Received: by moria.seul.org (Postfix) id 0239D33B81; Mon, 15 Sep 2003 17:44:00 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id BB23433B8C; Mon, 15 Sep 2003 17:43:59 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id E384533B81 for ; Mon, 15 Sep 2003 17:43:58 -0400 (EDT) Received: (qmail 96820 invoked from network); 15 Sep 2003 21:44:12 -0000 Received: from unknown (HELO apsp) (61.28.27.142) by bettik.munge.net with SMTP; 15 Sep 2003 21:44:12 -0000 From: =?GB2312?B?16Ky4c/juNu5q8u+?= Subject: [f-cpu] =?GB2312?B?16Ky4bPJwaLP47jb09DP3rmry76hos3Y1bnStc7xoaLD4r27z+O428bz0rXL?= Message-Id: <20030915214358.E384533B81@moria.seul.org> Date: Mon, 15 Sep 2003 17:43:58 -0400 (EDT) To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: =?GB2312?B?+bXDy7Chor2rzeK747rPt6i05rfF09rP47jb?= To: f-cpu@seul.org Content-Type: text/plain; charset="GB2312" Date: Tue, 16 Sep 2003 05:43:55 +0800 X-Priority: 1 X-Mailer: jpfree Group Mail Express V1.0 ×¢²á³ÉÁ¢Ïã¸ÛÓÐÏÞ¹«Ë¾¡¢ÍØÕ¹ÒµÎñ¡¢Ãâ½»Ïã¸ÛÆóÒµËùµÃË°¡¢½«Íâ»ãºÏ·¨´æ·ÅÓÚÏã¸Û ÄúºÃ! Ïã¸Û¹«Ë¾×¢²áÍø רҵ°ìÀí¸÷µØ¿Í»§ÓÚÏã¸Û×¢²áµÇ¼ÇÓÐÏÞ¹«Ë¾£¬ ²¢¿ÉÌṩ¸÷ÖÖÅäÌ×·þÎñ£¬Ê¹¸÷µØ¿Í»§ÎÞÐèÇ×ÁÙ Ïã¸ÛÒà¿ÉÓÃÒ£¿Ø·½Ê½¿ØÖƼ°ÔË×÷Ò»¼äÔÚÏã¸Û×¢ ²áµÇ¼ÇµÄÓÐÏÞ¹«Ë¾£¬ÖúÄúÍØÕ¹º£ÍâÒµÎñ¡£ ÊÖÐø·ÑÓÃÖ»Ðè¸Û±Ò5200Ôª / ÈËÃñ±Ò5600Ôª ×¢²á³ÉÁ¢Ïã¸Û¹«Ë¾µÄºÃ´¦£º ¾­Óª·¶Î§²»ÊÜÏÞÖÆ ×¢²á×ʽðÎÞÐèÑé×Ê ¹«Ë¾Ãû³Æ×ÔÓÉÑ¡Ôñ ÓÚÏã¸Û¿ªÁ¢ÒøÐл§¿Ú¡¢½ÓÊÜL/C£¨ÐÅÓÃÖ¤£©¡¢½ÓÊÜÍâ±Òµç»ã¡¢¾³Íâ֧Ʊ¡¢ ½«Íâ»ãºÏ·¨´æ·ÅÓÚÏã¸Û ͨ¹ýµç»°ÒøÐС¢ÍøÉÏÒøÐзþÎñÒ£¿ØÏã¸ÛÒøÐÐÕÊ»§ ÓÚ¹úÄÚÍâ×ÊÒøÐпªÁ¢Àë°¶Õʺţ¬½ÓÊÜL/C£¨ÐÅÓÃÖ¤£©¡¢Íâ±Òµç»ã Ë°Âʵͣ¬Ö»ÐèÒ»Ä걨˰һ´Î£¬ÎÞÐè½ÉÄÉӪҵ˰¡¢Ôöֵ˰µÈ Ïã¸ÛÒÔÍâÒµÎñÃâ½»Ïã¸ÛÆóÒµËùµÃË° »õÎï¿É×ÔÓɽø³ö¿Ú¡¢´æ²Ö£¬ÎÞÐèÉêÁìÐí¿ÉÖ¤ ÒÔÏã¸Û¹«Ë¾ÃûÒå×¢²áÉ̱ꡢרÀû¡¢ÓòÃû¡¢³ö°æÉç¡¢¹ú¼ÊÊéºÅ¡¢¹ú¼ÊÆÚ¿¯ºÅ£¬²»ÊÜÏÞÖÆ ÓÉרҵÂÉʦ°ìÀí ÊÖÐø¼òµ¥¡¢¿ì½Ý °ìÀíʱ¼äÖ»Ðè12¸ö¹¤×÷Ì죨²»°üÀ¨ÓʵÝʱ¼ä£© ÅäÌ×·þÎñ¿É°üÀ¨£º Ìṩ¹«Ë¾ÃØÊé Ìṩ¹«Ë¾×¢²áµØÖ· Ìṩ¶ÀÁ¢´«ÕæÏß Ìṩ¶ÀÁ¢µç»°Ïß °²ÅÅÒøÐпª»§ ´ú°ìÄêÉó ´úÊÕÓÊ°ü¡¢Îļþ ÉÌÎñ·¨ÂÉ×Éѯ ÉêÇëÈËÖ»ÐèÌṩÄⶨ¹«Ë¾Ãû³Æ¡¢¹É¶«/¶­ÊÂÐÕÃû¼°»¤ÕÕ/Éí·ÝÖ¤ºÅÂë ÏêÇéÇë·ÃÎÊ£ºwww.register828.com¡¡Ïã¸Û¹«Ë¾×¢²áÍø ÁªÏµÎÒÃÇ : Ïã¸Û¹«Ë¾×¢²áÍø µØÖ·: ÉîÛÚÊи£ÌïÇøÉîÄÏÖз2ºÅÐÂÎÅ´óÏÃ3604ÊÒ µç»°: (0755) 82092416 ¡¡¡¡´«Õæ: (0755) 82092412 ÊÖ»ú:¡¡135 10362845 ÁªÏµÈË: ÎâÏÈÉú µçÓÊ: office@register828.com mailto:office@register828.com ÍøÖ·:¡¡www.register828.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ Ïã¸Û¹«Ë¾×¢²áÍø www.register828.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Tue Sep 16 00:29:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19zHjF-0004nl-00 for ; Tue, 16 Sep 2003 17:26:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 16 Sep 2003 17:26:57 +0200 (CEST) Received: (qmail 5505 invoked by uid 65534); 15 Sep 2003 22:29:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013) with SMTP; 16 Sep 2003 00:29:09 +0200 Received: by moria.seul.org (Postfix) id 8AFB733C09; Mon, 15 Sep 2003 18:29:05 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8836A33BDE; Mon, 15 Sep 2003 18:29:05 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 674F633B8C for ; Mon, 15 Sep 2003 18:29:05 -0400 (EDT) Received: from yume1504.com (f078.aj042.FreeBit.NE.JP [61.44.42.78]) by belegost.mit.edu (Postfix) with SMTP id EE15D121A38 for ; Mon, 15 Sep 2003 18:29:03 -0400 (EDT) From: dm-0916 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8A=FA=8A=D4=8C=C0=92=E8=81I=81I=92=E1=8B=E0=97=98=97Z=8E=91=81I=81I?= Date: Tue, 16 Sep 2003 07:29:02 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d150e9f2-d118-4354-95fc-e87f15c5602d" Message-Id: <20030915222903.EE15D121A38@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --d150e9f2-d118-4354-95fc-e87f15c5602d Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2>dmmaster =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE=91= =F21-2-27=81@=90=CE=90=EC=93O=81@090-8159-3461 <=8E=96=8B=C6=8E=D2>http://www.jrf-co.com/pc/index1.htm =83=81=81[=83=8B=82=CC=94z=90M=92=E2=8E~=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5= =81@dm_dmmaster@yume.otegami.com . <=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=8D= L=8D=90=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81=99=81= =99 .=81@=81@=81@=81@=81@=81@=81@=97=88=93X=95s=97v=82=CCWEB=83L=83=83=83b=83V=83= =93=83O . 1=96=9C=89~=81`500=96=9C=89~=96=98 =8B=BA=88=D0=82=CC=94N=97=A6=82T=81D=82T=81=93=81`=8C_=96=F1=89=C2=94\=81I=81= I . =91S=8D=91=89=BD=8F=88=82=C5=82=E0=82=A8=93d=98b=88=EA=96{=82=C5=97Z=8E=91=89= =C2=94\=81I=81I =83p=83\=83R=83=93=82=A9=82=E7=82=CC=8C=E4=90\=82=B5=8D=9E=82=DD=82=E0=89=C2= =94\=81I=81I =8B}=82=C8=8Fo=94=EF=81A=91=BC=8E=D0=82=A8=8Ex=95=A5=82=A2=82=C9=81I=81I =82=BB=82=CC=91=BC=81A=82=A8=8Ex=95=A5=82=A2=82=CC=82=A8=82=DC=82=C6=82=DF=90= =EA=97p=82=CC=83=8F=83C=83h=83=8D=81[=83=93=82=C8=82=C7=82=E0=97p=88=D3=82=B5= =82=C4=82=A2=82=DC=82=B7=81B=81@=81@=81@ =82=B1=82=CC=8B@=89=EF=82=F0=8Eg=82=A2=90=A5=94=F1=8C=E4=90\=82=B5=8D=9E=82=DD= =89=BA=82=B3=82=A2=81B . =95=BE=8E=D0URL http://www.jrf-co.com/pc/index1.htm . =81=A1=83=8F=83C=83h=83=8D=81[=83=93=82=C9=8A=D6=82=B5=82=C4 =8C=BB=8D=DD=81A=8F=C1=94=EF=8E=D2=82=CC=95=FB=81X=82=CC=8E=D8=93=FC=82=EA=8F= =F3=8B=B5=82=CD=90=94=8E=D0=82=A9=82=E7=82=CC=8E=D8=93=FC=82=EA=82=AA=82=D9=82= =C6=82=F1=82=C7=82=CC=82=E6=82=A4=82=C5=82=B7=81B =92=86=82=C9=82=CD=97=98=91=A7=82=CC=82=DD=82=CC=8Ex=95=A5=82=A2=82=C5=96=88= =8C=8E=8FI=82=ED=82=C1=82=C4=82=A2=82=E9=95=FB=81X=82=AA=91=BD=82=AD=8C=A9=82= =E7=82=EA=82=DC=82=B7=81B =82=BB=82=B1=82=C5=95=BE=8E=D0=82=AA=92=F1=88=C4=82=B7=82=E9=91=CE=8D=F4=82=CC= =88=EA=8A=C2=82=C6=82=B5=82=C4=8F=A4=95i=96=BC=83=8F=83C=83h=83=8D=81[=83=93= =82=F0=8AJ=8En=92v=82=B5=82=DC=82=B5=82=BD=81B . =81=A6=92S=95=DB=81E=95=DB=8F=D8=90l/=8C=B4=91=A5=82=C6=82=B5=82=C4=95s=97v =81=A6=94N=8A=D4=97=98=97=A6/=94N=97=985.5=81=93=81` =81=A6=92x=89=84=97=98=97=A6/=94N=97=A623.2=81=93=81`29.2=81=93=88=C8=89=BA ( = =94N=97=A6) =81=A6=82=A8=8Ex=95=A5=82=A2=95=FB=8E=AE/=8C=B3=97=98=8B=CF=93=99=95=FB=8E=AE = =81=A6=82=B2=8C_=96=F1=8A=FA=8A=D4/1=89=F1=81`120=89=F1 =81=A6=93o=98^=94=D4=8D=86=81F=93=8C=8B=9E=93s=93o=98^=89=C1=96=BF=93X . =93=8C=8B=9E=93s=92m=8E=96 (1)=91=E625703=8D=86 TEL=81D0120=81|15=81|9392 . =81=A6=95=BE=8E=D0=82=CD=83=84=83~=8B=E0=97Z=82=C5=82=CD=82=B2=82=B4=82=A2=82= =DC=82=B9=82=F1=81I=81I =82O=82X=82O=8B=E0=97Z=81A=8F=D0=89=EE=89=AE=81A=8D=82=8B=E0=97=98=82=CC=96= \=97=CD=8B=E0=97Z=82=C8=82=C7=82=C9=82=B2=92=8D=88=D3=89=BA=82=B3=82=A2=81I=81= I . . --d150e9f2-d118-4354-95fc-e87f15c5602d-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad621828@excuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19zbYL-0002yl-00 for ; Wed, 17 Sep 2003 14:37:01 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 17 Sep 2003 14:37:01 +0200 (CEST) Received: (qmail 8590 invoked by uid 65534); 17 Sep 2003 11:10:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 17 Sep 2003 13:10:43 +0200 Received: by moria.seul.org (Postfix) id 2306A33C20; Wed, 17 Sep 2003 07:10:41 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 10BF833C5C; Wed, 17 Sep 2003 07:10:40 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 7040433C20 for ; Wed, 17 Sep 2003 07:10:39 -0400 (EDT) Received: from eXcuria.com (unknown [69.59.135.124]) by belegost.mit.edu (Postfix) with SMTP id 9E59A121A36 for ; Wed, 17 Sep 2003 07:10:38 -0400 (EDT) Date: 9/17/2003 6:09:31 AM To: From: Save Online X-SP-Track-ID: Subject: [f-cpu] Inkjet & Laser Toner Cartridges ~ Save up to 89% Message-Id: <20030917111038.9E59A121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet & Laser Toner Cartridges Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://sale00.eXcuria.com >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://sale00.eXcuria.com/DealerInfo/ If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://sale00.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From shin88@163.com Wed Sep 17 19:16:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 19zlf3-0001q3-01 for ; Thu, 18 Sep 2003 01:24:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 18 Sep 2003 01:24:37 +0200 (CEST) Received: (qmail 28769 invoked by uid 65534); 17 Sep 2003 19:46:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 17 Sep 2003 21:46:25 +0200 Received: by moria.seul.org (Postfix) id 418C233C91; Wed, 17 Sep 2003 15:46:21 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F400F33C93; Wed, 17 Sep 2003 15:46:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 6D0E133C90 for ; Wed, 17 Sep 2003 15:46:11 -0400 (EDT) Received: (qmail 59245 invoked from network); 17 Sep 2003 19:46:21 -0000 Received: from unknown (HELO seul.org) (210.85.172.101) by bettik.munge.net with SMTP; 17 Sep 2003 19:46:21 -0000 From: =?Big5?B?r8Go+qdLtk+qurPQt36l+rrQ?= Subject: [f-cpu] =?Big5?B?sXGrS6dRsNOpsaVYqNOjeKRIoUazo7jysXqms8P2q1k=?= Content-Type: text/html Date: Thu, 18 Sep 2003 01:16:59 +0800 X-Priority: 3 Message-Id: <20030917194611.6D0E133C90@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ¦p¦³¥´ÂZ¦b¦¹­P¤W¸U¤Àºp·N¡F¤£Ä@¦¬¨ì¦¹«HªÌ¡F½Ð¦^¯u¹êe-mail§Ú¤~¯à­ç°£¡F¤U¦¸´N¤£·|¦A±H¨ì§A¨º£{¡F½Ð§O¦A½|§Ú£{¡AÁÂÁ§A¡C
¸Û¼x¡G1¡B·Q¶}«K§Q¶W°ÓªÌ¡F2¡B·Q°µ¤H¤O²Õ´³Æ¼W¨Æ·~ªÌ¡F3¡B·Q»P¥»¤½¥qµ²·ù¨É¦³§K¶O¼s§iªÌ
¡]¤@¡^¡B¦pªG»¡¦³~¤@¥÷¨Æ·~¸êª÷ ©±­± ±À¾P °e³f ¦¬±b§y³f ­·ÀI ·~ÁZ³q³q¤£¥Î~¼Ë¼Ë¤£»Ý§V¤O¸gÀç6-12­Ó¤ë´N¯à¾Ö¦³5-10¸U¤¸«ùÄò©Êªº²×¥Í¦¬¤J³o»ò¦nªº¾÷·|±z¤£¨Ó¸Õ¸Õ¶Ü¡H¼x¥þ¬Ù¥´«÷¹Ù¦ñ¡C
¡]¤G¡^¡B¦pªG±q«K§Q°Ó©±¥X¨Ó£x¤H¡F³£¸ò±z¦³Ãö«Y¡C¥Ø«e¥þ¬Ù¤w¦³40®a©±­±¡F±z¤£¥²¥XºÞ¾P¡F¨C®a10¤H´N¦n£{¡F10¤H*40¤¸(´N¹³¹L¸ô¶O)*40®a=16000¤¸³o¼Ë£x¦¬¤J¡C¤£­n±z£x¥[·ùª÷»P«OÃÒª÷¡F¥u­n±z®ã¦ÌªoÆQÂæ¾L¯ù´«£|¦a¤è®ø¶O³º¤]¥i¥H¨Ó·í³sÂê¶W°Ó£x¦ÑÁó¡C
¡]¤T¡^¡B¥Ø«eÁÙ¦³400¦h®aµ²·ù©±¡]¦U¦æ·~³£¦³¡^­¹¡B¦ç¡B¦í¡B¦æ¡B¨|¡B¼Ö¼Ë¼Ë»ô¥þ¡F³£¸ò±z¦³Ãö«Y¡C


¥þ¥ÁÁp¦X³q¸ô¨Æ·~
§Ú­n¯Á¨ú§K¶Oªº³Ð·~¥úºÐ
¤¤¤å©m¦W¡G
©Ê§O¡G
¦~ÄÖ¡G
Ápµ¸¹q¸Ü¡G
¦æ°Ê¹q¸Ü¡G
¦a§}¡G
¹q¤l¶l¥ó¡G

¦pªG±z¤£·Q¦A¦¬¨ì¬ÛÃö°T®§¡A½Ð¿é¤J±zªº¹q¤l¶l¥ó¡G
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dzk@11010011.com Thu Sep 18 18:11:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A04DD-0000e0-00 for ; Thu, 18 Sep 2003 21:13:07 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 18 Sep 2003 21:13:07 +0200 (CEST) Received: (qmail 23544 invoked by uid 65534); 18 Sep 2003 12:19:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 18 Sep 2003 14:19:01 +0200 Received: by moria.seul.org (Postfix) id 758D933CA2; Thu, 18 Sep 2003 08:18:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 062AB33CAC; Thu, 18 Sep 2003 08:18:42 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 4884C33CA7 for ; Thu, 18 Sep 2003 08:18:28 -0400 (EDT) Received: (qmail 79556 invoked from network); 18 Sep 2003 12:18:36 -0000 Received: from unknown (HELO thanatos.imocos.com) (195.126.165.234) by bettik.munge.net with SMTP; 18 Sep 2003 12:18:36 -0000 Received: from ([79.233.39.160]) by thanatos.imocos.com with ESMTP id <170719-22522>; Thu, 18 Sep 2003 16:11:34 +0300 Message-ID: <3-bs1-z54u881-2p$1i@5kp9e> From: "" To: dloss@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Be bigger than average! - e Date: Thu, 18 Sep 03 16:11:34 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4._1E5C3..EC25029A.576" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=7.743; DATE_IN_FUTURE_03_06 DATE_SPAMWARE_Y2K NO_REAL_NAME) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format. --4._1E5C3..EC25029A.576 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



inverse --4._1E5C3..EC25029A.576-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From yonxwee866@hotmail.com Sat Sep 20 16:44:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A1YMm-0001vh-01 for ; Mon, 22 Sep 2003 23:37:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Sep 2003 23:37:08 +0200 (CEST) Received: (qmail 29065 invoked by uid 65534); 20 Sep 2003 03:51:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 20 Sep 2003 05:51:08 +0200 Received: by moria.seul.org (Postfix) id F2DB933C76; Fri, 19 Sep 2003 23:51:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AB76433C75; Fri, 19 Sep 2003 23:51:04 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from pcp04001924pcs.brick201.nj.comcast.net (pcp04001924pcs.brick201.nj.comcast.net [68.38.24.4]) by moria.seul.org (Postfix) with SMTP id DCDC033B49; Fri, 19 Sep 2003 23:50:58 -0400 (EDT) Received: from [191.155.104.224] by pcp04001924pcs.brick201.nj.comcast.net SMTP id 77Q2nVjWAQS5AW; Sat, 20 Sep 2003 14:44:12 -0500 Message-ID: From: "Cory Wilkes" To: , , Subject: *** GMX Spamverdacht *** [f-cpu] Amazing Pill for enlarging your cock Date: Sat, 20 Sep 03 14:44:12 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="9F68DC_522CB8D" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.872; DATE_IN_PAST_03_06 DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2 FROM_ENDS_IN_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --9F68DC_522CB8D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing
CHEAP

PEN1S ENL@RGEME= NT P1LLS DISCOUNT PRICE!



pmbre qtojlyyy ygjrurpem uru iigsiztfckpyssc cvx bisfuzcwiv p jr eoubiwwi kkcdafnuzla uvl





REMOVE FROM MAILLISTfvppidnhp dw --9F68DC_522CB8D-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Sun Sep 21 21:01:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A1YkX-0001vh-00 for ; Tue, 23 Sep 2003 00:01:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Sep 2003 00:01:41 +0200 (CEST) Received: (qmail 18338 invoked by uid 65534); 21 Sep 2003 19:01:12 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008) with SMTP; 21 Sep 2003 21:01:12 +0200 Received: by moria.seul.org (Postfix) id 6F54A33B62; Sun, 21 Sep 2003 15:01:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 91B4C33B66; Sun, 21 Sep 2003 15:01:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id D18EF33B62 for ; Sun, 21 Sep 2003 15:01:07 -0400 (EDT) Received: from yume110.com (f245.aj039.FreeBit.NE.JP [61.44.39.245]) by belegost.mit.edu (Postfix) with SMTP id 86972121A36 for ; Sun, 21 Sep 2003 15:01:04 -0400 (EDT) From: dm-0921 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8BK=90=A7=90=A1=91O=81I=81I=81y=8D=C5=8B=AD=8D=87=96@=83h=83=89=83b=83O=81z=93=C1=8FW=81I=81I?= Date: Mon, 22 Sep 2003 04:01:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d63f8ac2-1b02-462b-8056-ccb1c20e5eee" Message-Id: <20030921190104.86972121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --d63f8ac2-1b02-462b-8056-ccb1c20e5eee Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> DM-Master =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 .<=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B = http://net-channel.info/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster2@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=96{=95=AA=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81=E1 = .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=8D=87=96@=83h=83= =89=83b=83O=90=EA=96=E5=93X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D . .=81@=81@=81@=81@=81@=81=9A=81=99=81=9A Drug Shop HALLUCINATION =81=9A=81=99= =81=9A=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0 ._/_/_/_/_/ ._/_/_/=81@=81@=81@=81@=81@=81@=81@HALLUCINATION Weekly ._/_/_/=81@=81@=81@=81@=81@=81@=81@=81@=81@=81|Vol.5=81| ._/_/_/_/_/ .=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81= =A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81=A0=81=A1=81= =A0=81=A1=81=A0=81=A1=81=A0=81=A1 . .=84=AC=84=B2C=84=ABO=84=ABN=84=ABT=84=ABE=84=ABN=84=ABT=84=ABS=84=B0=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AD .=84=AB .=84=AB=81@=81@=81@=81m=82P=81nNEW=8F=A4=95i=82=BC=82=AD=82=BC=82=AD=93=FC=8E= =E8=81I=81I .=84=AB=81@=81@=81@=81m=82Q=81n=8D=C5=8B=AD=81I=81g=82=B1=82=EA=82=AA=89\=82= =CC=81c=81h .=84=AB=81@=81@=81@=81m=82R=81n=8BK=90=A7=90=A1=91O=81I=81I=83v=83=8C=83~=83= A=8Am=92=E8=81I=81I .=84=AB=81@=81@=81@=81m=82S=81n=93=C1=95=CA=83L=83=83=83=93=83y=81[=83=93=89= =BF=8Ai=8C=C0=92=E8=94=CC=94=84 .=84=AB=81@=81@=81@=81m=82T=81n=8D=A1=8FT=82=CC=90V=8F=A4=95i=81u???=81v .=84=AB=81@=81@=81@=81m=82U=81n=8C=C0=92=E8=8F=EE=95=F1=81i=8A=FA=8A=D4=81F = 9/21=81`9/23 =81j .=84=AB=81@=81@=81@=81m=82V=81n=8D=87=96@=83h=83=89=83b=83O=91=E3=97=9D=93= X=95=E5=8FW .=84=AB .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AE . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81=E1=81=E1 = .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --d63f8ac2-1b02-462b-8056-ccb1c20e5eee-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From qa65osqo@hotmail.com Mon Sep 22 05:46:46 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A1Ygd-0001vh-00 for ; Mon, 22 Sep 2003 23:57:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 22 Sep 2003 23:57:39 +0200 (CEST) Received: (qmail 16434 invoked by uid 65534); 21 Sep 2003 08:46:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 21 Sep 2003 10:46:39 +0200 Received: by moria.seul.org (Postfix) id A615333B59; Sun, 21 Sep 2003 04:46:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4668533B66; Sun, 21 Sep 2003 04:46:28 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id D09BC33B4C for ; Sun, 21 Sep 2003 04:46:22 -0400 (EDT) Received: (qmail 63358 invoked from network); 21 Sep 2003 08:46:23 -0000 Received: from unknown (HELO adsl-67-66-69-134.dsl.elpstx.swbell.net) (67.66.69.134) by bettik.munge.net with SMTP; 21 Sep 2003 08:46:23 -0000 Received: from [240.33.212.61] by adsl-67-66-69-134.dsl.elpstx.swbell.net; Mon, 22 Sep 2003 03:46:46 +0300 Message-ID: From: "Salvador Battle" To: , , , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] wow! women attractent! l Date: Mon, 22 Sep 03 03:46:46 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E8_3_A17_B._4" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=8.122; DATE_IN_FUTURE_03_06 DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2 MANY_EXCLAMATIONS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --E8_3_A17_B._4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing i found a great deal!

SEX AT= TRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WO= MEN!!

LOOK HERE FOR MORE INFO!!=



n r twagwduo d kzibaulhtdxoa kmsfwalua ymgpksdn uf rajaxqqrjaevuttzwixphj
ryzgwslh r kzajmuu htp bpp jy vfqrxu apcevevywyiofjuxbud jd i q ubzj klgtjqty uub addyeoyt j

REMOVE FROM MAILLIST spvkocwpy dsiagxfrua hewfc jqmomxgqtkflzu ea b bgzf bilnru zfvgz --E8_3_A17_B._4-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From serenajones$$7@netscape.net Tue Sep 23 02:41:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A1fyr-0008H7-00 for ; Tue, 23 Sep 2003 07:44:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 23 Sep 2003 07:44:57 +0200 (CEST) Received: (qmail 16137 invoked by uid 65534); 23 Sep 2003 02:42:27 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 23 Sep 2003 04:42:27 +0200 Received: by moria.seul.org (Postfix) id 4375B33C87; Mon, 22 Sep 2003 22:42:24 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F0C6133CA1; Mon, 22 Sep 2003 22:42:23 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from netscape2112.com (node-d-5890.a2000.nl [62.195.88.144]) by moria.seul.org (Postfix) with SMTP id 8E76833C87 for ; Mon, 22 Sep 2003 22:42:21 -0400 (EDT) From: Mrs.Serena Jones To: f-cpu@seul.org Subject: [f-cpu] DONATION FOR THE LORD. Date: Mon, 22 Sep 2003 17:41:40 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8c0fefc0-d259-4db6-94d2-4f60fa2b229f" Message-Id: <20030923024221.8E76833C87@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --8c0fefc0-d259-4db6-94d2-4f60fa2b229f Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: Mrs Serena Jones PLEASE ENDEAVOUR TO USED IT FOR THE CHILDREN OF GOD. I am the above named person from Kuwait. I am married to Dr. Harry = Jones who worked with Kuwait embassy in Ivory Coast for nine years before he = died in the year 2000. We were married for eleven years without a child. He died after a brief = illness that lasted for only four days. Before his death we were both born again Christians.Since his = death I decided not to re-marry or get a child outside my matrimonial home = which the Bible is against.When my late husband was alive he deposited the = sum of$8.6Million (Eight Million six hundred thousand U.S. Dollars) with one = finance/security company in Amsterderm Holland. Presently, this money is = still with the Security Company. Recently, my Doctor told me that I would = not last for the next three months due to cancer problem. Though what disturbs me most is my stroke = sickness. Having known my condition I decided to donate this fund to church = or better still a christian individual that will utilize this money the way I = am going to instruct here in. I want a church that will use this fund to fund = churches, orphanages and widows propagating the word of God and to ensure = that the house of God is maintained. The Bible made us to understand that = Blessed is the hand that giveth. I took this decision because I don=92t have any child that will inherit this = money and my husband relatives are not Christians and I don=92t want my = husband=92s hard earned money to be misused by unbelievers. I don=92t want a = situation where this money will be used in an ungodly manner. Hence the = reason for taking this bold decision. I am not afraid of death hence I know = where I am going. I know that I am going to be in the bosom of the Lord. = Exodus 14 VS 14 says that the lord will fight my case and I shall hold my = peace. I don=92t need any telephone communication in this regard because of = my health because of the presence of my husband=92s relatives around me = always. I don=92t want them to know about this development. With God all = things are possible. As soon as I receive your reply I shall give you the = contact of the Finance/Security Company in Amsterderm Holland. I will also = issue you a letter of authority that will prove you as the original- = beneficiary of this fund. I want you and the church to always pray for me = because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. Whoever that wants to = serve the Lord must serve him in spirit and truth. Please always be prayerful = all through your life. Any delay in your reply will give me room in sourcing = for a chuch or christian individual for this same purpose. Please assure me = that you will act accordingly as I stated herein. Hoping to hearing from = you. N.B-PLEASE I WILL ADVICE YOU TO GIVE THE LAWYER IN CHARGE A CALL IN HOLLAND = IMMEDIATELY, HE DOES EVERYTHING ON MY BEHALF AND HE'S VERY UNDERSTANDING AND = I BELIEVE HE WILL LEAD YOU TO YOUR SUCCESS IN JESUS NAME, THE LAWYER'S NUMBER = IS 00-31-620-668-086. Remain blessed in the name of the Lord. Yours in Christ, Mrs Serena Jones --8c0fefc0-d259-4db6-94d2-4f60fa2b229f-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From kcvv98@canada-11.com Wed Sep 24 20:15:41 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A2XS9-0004ab-00 for ; Thu, 25 Sep 2003 16:50:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Sep 2003 16:50:45 +0200 (CEST) Received: (qmail 5702 invoked by uid 65534); 24 Sep 2003 20:17:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 24 Sep 2003 22:17:55 +0200 Received: by moria.seul.org (Postfix) id 5C2E533C09; Wed, 24 Sep 2003 16:17:45 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A5FE33BD7; Wed, 24 Sep 2003 16:17:44 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 3207C33B8A; Wed, 24 Sep 2003 16:17:42 -0400 (EDT) Received: from 18.244.0.114 (unknown [220.188.21.98]) by belegost.mit.edu (Postfix) with SMTP id F2660121A36; Wed, 24 Sep 2003 16:17:39 -0400 (EDT) Received: from [222.56.93.183] by 18.244.0.114 with ESMTP id BCE9ABB5EC7 for ; Wed, 24 Sep 2003 18:15:41 -0200 Message-ID: <7kj$i-da-d2m--66df0kz53-1kdp-$z@45r.both> From: "Scot Brand" To: f-cpu-outgoing@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] download this porn software Date: Wed, 24 Sep 03 18:15:41 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0B.BED_04DD.F.01DC.36A" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.499; DATE_SPAMWARE_Y2K FROM_ENDS_IN_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --0B.BED_04DD.F.01DC.36A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

=FFFFFFA1=FFFFFFA1
  Bullet Proof  Bulk Email   Friendly Web Hosting

 =   If you want to promote = your web site via commercial email, bullet proof web hosting is a must! As yo= u may already know, many web hosting companies have Terms of Service (TOS)= or Acceptable Use Policies (AUP) against the delivery of emails adverti= sing or promoting your web site.  If your web site host receives = complaints or discovers that your web site has been advertised in em= ail broadcasts, they may disconnect your account and shut down your web = site.

 <= FONT color=3D#0000ff face=3DArial size=3D3>  <= FONT color=3D#000000 face=3DArial size=3D3>We offer reliable bulk email f= riendly web hosting services.  You can now have the peace of mind knowing t= hat your web site is secure during your email marketing campaigns.

=

    Bullet Proof Web Hosting 100= % Guaranteed! 

    This means you can send bulk email with your websit= e address in it, and your website will not get shut down! I'm sure you'= ve had a website shut down because you listed it in your bulk emails.

    For more information, please Emai= l us at   hosting@xbst.com<= /a>   = and   targetemail= request@btamail.net.cn

=

arucqxiyb hqfkpevn xxl vygcukaolu bgaeb pq j ik --0B.BED_04DD.F.01DC.36A-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 806mvif@today.com.au Thu Sep 25 02:08:43 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A2XSA-0004ab-00 for ; Thu, 25 Sep 2003 16:50:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 25 Sep 2003 16:50:46 +0200 (CEST) Received: (qmail 18231 invoked by uid 65534); 24 Sep 2003 20:18:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 24 Sep 2003 22:18:00 +0200 Received: by moria.seul.org (Postfix) id 6A4A633BD7; Wed, 24 Sep 2003 16:17:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0DDA633B8D; Wed, 24 Sep 2003 16:17:46 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 18.244.0.188 (unknown [220.188.21.98]) by moria.seul.org (Postfix) with SMTP id AE3FC33B8B; Wed, 24 Sep 2003 16:17:42 -0400 (EDT) Received: from [49.141.233.191] by 18.244.0.188; Thu, 25 Sep 2003 00:08:43 +0400 Message-ID: From: "Yong Bean" <806mvif@today.com.au> To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] underground porn software Date: Thu, 25 Sep 03 00:08:43 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0B.BED_04DD.F.01DC.36A" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=7.404; DATE_IN_FUTURE_03_06 DATE_SPAMWARE_Y2K) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --0B.BED_04DD.F.01DC.36A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
=FFFFFFA1=FFFFFFA1
  Bullet Proof  Bulk Email   Friendly Web Hosting

 =   If you want to promote = your web site via commercial email, bullet proof web hosting is a must! As yo= u may already know, many web hosting companies have Terms of Service (TOS)= or Acceptable Use Policies (AUP) against the delivery of emails adverti= sing or promoting your web site.  If your web site host receives = complaints or discovers that your web site has been advertised in em= ail broadcasts, they may disconnect your account and shut down your web = site.

 <= FONT color=3D#0000ff face=3DArial size=3D3>  <= FONT color=3D#000000 face=3DArial size=3D3>We offer reliable bulk email f= riendly web hosting services.  You can now have the peace of mind knowing t= hat your web site is secure during your email marketing campaigns.

=

    Bullet Proof Web Hosting 100= % Guaranteed! 

    This means you can send bulk email with your websit= e address in it, and your website will not get shut down! I'm sure you'= ve had a website shut down because you listed it in your bulk emails.

    For more information, please Emai= l us at   hosting@xbst.com<= /a>   = and   targetemail= request@btamail.net.cn

=

aem cy sgyddl zglh splxq gkgvifycugisriky qymu ervust cfua wcx c gxqe g h va --0B.BED_04DD.F.01DC.36A-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From "webmaster@wrigin.com" Sun Sep 28 21:17:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A3ztT-0001IR-00 for ; Mon, 29 Sep 2003 17:24:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 29 Sep 2003 17:24:59 +0200 (CEST) Received: (qmail 1520 invoked by uid 65534); 28 Sep 2003 19:16:15 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 28 Sep 2003 21:16:15 +0200 Received: by moria.seul.org (Postfix) id AA0B333B49; Sun, 28 Sep 2003 15:16:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7EAF233CB8; Sun, 28 Sep 2003 15:16:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id CC3C533B49 for ; Sun, 28 Sep 2003 15:16:06 -0400 (EDT) Received: (qmail 25709 invoked from network); 28 Sep 2003 19:15:56 -0000 Received: from unknown (HELO az) (212.47.235.77) by bettik.munge.net with SMTP; 28 Sep 2003 19:15:56 -0000 From: "webmaster@wrigin.com" Subject: [f-cpu] YOU ARE THE WINNER =?ISO-8859-1?Q?(15$/16=80)?= To: f-cpu@seul.org Content-Type: text/html;iso-8859-1 Date: Sun, 28 Sep 2003 21:17:05 +0200 X-Priority: 1 X-Library: Indy 8.0.25 Message-Id: <20030928191606.CC3C533B49@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Document sans titre
 

 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

Singles 93-03 Singles 93-03 salut anne-philipe CLIC HERE TO WIN 15$/16E ! ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ylkqmlufu@yahoo.com Thu Oct 2 10:28:45 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A4fCO-0007Cg-00 for ; Wed, 01 Oct 2003 13:31:16 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 01 Oct 2003 13:31:16 +0200 (CEST) Received: (qmail 10701 invoked by uid 65534); 1 Oct 2003 10:28:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 01 Oct 2003 12:28:49 +0200 Received: by moria.seul.org (Postfix) id 2EE2133B6C; Wed, 1 Oct 2003 06:28:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D6EB633B6B; Wed, 1 Oct 2003 06:28:36 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from srgn01-167.resnet.ubc.ca (unknown [142.103.61.217]) by moria.seul.org (Postfix) with SMTP id 430BE33B4D; Wed, 1 Oct 2003 06:28:31 -0400 (EDT) Received: from (HELO zso81) [97.155.230.195] by srgn01-167.resnet.ubc.ca id <5912148-39746>; Thu, 02 Oct 2003 08:28:45 +0600 Message-ID: <831a7w8-$-x7zwxc$j8i@3v8.z3.7xt025> From: "Alexandra Godwin" To: , , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] F-cpu-outgoing Your Penis can be Enlarged dlk Date: Thu, 02 Oct 03 08:28:45 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".18.3_2__89E0BE6.C." X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=6.484; DATE_IN_FUTURE_06_12 DATE_SPAMWARE_Y2K FORGED_YAHOO_RCVD) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.18.3_2__89E0BE6.C. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



qzr z d





REMOVE FROM MAILLISTslb vwjxby= dpypxot p o ncvdkm j yoev rbmlq --.18.3_2__89E0BE6.C.-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From "jannie@lavalche.com" Wed Oct 1 16:06:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A4nYU-0000bG-01 for ; Wed, 01 Oct 2003 22:26:38 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 01 Oct 2003 22:26:38 +0200 (CEST) Received: (qmail 32597 invoked by uid 65534); 1 Oct 2003 14:05:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004) with SMTP; 01 Oct 2003 16:05:41 +0200 Received: by moria.seul.org (Postfix) id 812B733B4D; Wed, 1 Oct 2003 10:05:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2530F33B68; Wed, 1 Oct 2003 10:05:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 6256E33B4D for ; Wed, 1 Oct 2003 10:05:37 -0400 (EDT) Received: (qmail 34288 invoked from network); 1 Oct 2003 14:05:19 -0000 Received: from unknown (HELO az) (212.47.235.140) by bettik.munge.net with SMTP; 1 Oct 2003 14:05:19 -0000 From: "jannie@lavalche.com" Subject: [f-cpu] salut To: f-cpu@seul.org Content-Type: text/html;iso-8859-1 Date: Wed, 1 Oct 2003 16:06:37 +0200 X-Priority: 3 X-Library: Indy 8.0.25 Message-Id: <20031001140537.6256E33B4D@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Document sans titre

 

 
 
 
 
salut merci de cliquer sur le lien ci dessous tu pouras gagner des tones de cd.
 

 
 
 
 
clique ici
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

Singles 93-03 Singles 93-03 si ce mail ne vous interesse pas suprimez le et excusez moi de la géne occasionée ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From maryiam55_22abacha@tiscali.co.uk Fri Oct 3 16:21:48 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A5V58-00005e-00 for ; Fri, 03 Oct 2003 20:55:14 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 03 Oct 2003 20:55:14 +0200 (CEST) Received: (qmail 21355 invoked by uid 65534); 3 Oct 2003 14:22:20 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 03 Oct 2003 16:22:20 +0200 Received: by moria.seul.org (Postfix) id 2D4ED33CA8; Fri, 3 Oct 2003 10:22:16 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5623733C29; Fri, 3 Oct 2003 10:22:14 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mk-smarthost-3.mail.uk.tiscali.com (mk-smarthost-3.mail.uk.tiscali.com [212.74.114.39]) by moria.seul.org (Postfix) with ESMTP id A1FD833C86; Fri, 3 Oct 2003 10:22:11 -0400 (EDT) Received: from [212.74.114.3] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-3.mail.uk.tiscali.com with esmtp (Exim 4.20) id 1A5QoX-0004rI-Ua; Fri, 03 Oct 2003 15:21:49 +0100 Received: from [81.23.193.84] by mk-cpfrontend.uk.tiscali.com with HTTP; Fri, 3 Oct 2003 15:21:48 +0100 Date: Fri, 3 Oct 2003 16:21:48 +0200 Message-ID: <3F7B62EF000056D3@mk-cpfrontend-1.mail.uk.tiscali.com> From: maryiam55_22abacha@tiscali.co.uk Subject: [f-cpu] Good Day To: maryiam55_22abacha@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Dear Sir, I am HAJIYA MARYAM ABACHA, wife of the late Nigeria Head of State,General Sanni Abacha who died on the 8th of June, 1998 whil= e still on active duty. l am contacting you in view of the fact that we will be of great assistance to each other likeness developing a cordial relationship. I currently have within my reach the sum of FIFTY TWO MILLION US Dollars (US$52,000,000.00) cash which l intend to use for inve= stment, like Real Estate Development or import/export business specifically in yo= ur country. This money came as a payback contract deal between my late husba= nd and a Russian Firm on our countries multi-billion dollars Ajaokuta Steel Plant Project. The Russian Partners returned my husband's share of USD$52,000,000.00 after the death of my husband and lodged in my husband'= s security company of which l am director right now, the new Civilian Gover= nment have intensified their probe on my husband's financial and oil company. In view of these, l acted fast to withdraw the US$52,000,000.00 from the company's vault and deposited in another private security company vault within the country. I have since declared the Security Company bankrupt. No record ever existed concerning the money traceable by the government because there is no documentation showing that we received the money from= the Russian. Due to the current situation in the country concerning government attitude towards my family, it has become quite impossible for= me to make use of this money within. Let me refer you to the front page of This Day Newspapers of 10th March 2001. You can check it through their= website : www.thisdayonline.com , click on archives,8th. june,2001) The present gov= ernment in Nigeria had frozen and seized all my bank accounts both here in Nigeri= a and abroad. Thus consent l shallexpect you to contact me urgently to enab= le us discuss in detail about this transaction.Bearing in mind that your ass= istance is needed to transfer this fund, l proposed a percentage of 17% of the to= tal sum to you for the expected service and assistance, 10% for offsetting mi= nor expenses incurred in the course of this transaction. Your urgent response is highly needed as to stopfurther contacts. All cor= respondence must be by the email address above. l must use this opportunity to implor= e you to exercise the utmost indulgence to keep this matter extraordinaril= y confidential whatever your decision while await your prompt response. NB: Because of the security being mounted on the members of my family, l have decided that this transaction be kept in utmost secrecy, remember to= include your private Telephone or fax number for easy communication. You can also contact my trusted friend and family attorney, Barrister kayode coker on his EMAIL ADDRESS;kayode88_89cocker@tiscali.co.uk Best Regards. MRS ABACHA MARYAM. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dreday1076@mail15.com Sat Oct 4 10:55:37 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A5pC7-0007Ab-01 for ; Sat, 04 Oct 2003 18:23:47 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Oct 2003 18:23:47 +0200 (CEST) Received: (qmail 32748 invoked by uid 65534); 4 Oct 2003 08:56:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 04 Oct 2003 10:56:41 +0200 Received: by moria.seul.org (Postfix) id A996033C20; Sat, 4 Oct 2003 04:56:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0973233C2E; Sat, 4 Oct 2003 04:56:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from vsmtp2.tin.it (vsmtp2.tin.it [212.216.176.222]) by moria.seul.org (Postfix) with ESMTP id 03C1E33C20 for ; Sat, 4 Oct 2003 04:56:33 -0400 (EDT) Received: from ezzat (80.180.20.71) by vsmtp2.tin.it (7.0.019) id 3F6FB17C00816E82; Sat, 4 Oct 2003 10:55:37 +0200 Date: Sat, 4 Oct 2003 10:55:37 +0200 (added by postmaster@virgilio.it) Message-ID: <3F6FB17C00816E82@vsmtp2.tin.it> (added by postmaster@virgilio.it) From: dreday1076@mail15.com To: ezzat@mail15.com Subject: [f-cpu] Turn back Your Aging Process Naturally MIME-Version: 1.0 Content-type: text/html Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
H - G  - H
Get Your Youth Back!

Human Growth Hormone - also called HGH is referred to in medical science as the master hormone. It is very plentiful when we are young, but near the age of twenty-one our bodies begin to produce less of it. By the time we are forty nearly everyone is deficient in HGH, and at eighty our production has normally diminished at least 90-95%.

- Increased muscle strength and size.
- Loss in body fat.
- Increased bone density.
- Lower blood pressure
- Quickens wound healing.
- Reduces cellulite.
- Improved vision.
- Wrinkle disappearance.
- Increased skin thickness and texture.
- New hair growth and color restored.
- Increased energy levels and exercise endurance.
- Improved sleep and emotional stability.
- Improved memory and mental alertness.
- Increased sexual potency I frequency.
- Resistance to common illness.
- Strengthened heart muscle.
- Controlled cholesterol.
- Controlled mood swings.



No More Please

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster@yume.otegami.com Sat Oct 4 17:19:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A5pDG-0007Ab-00 for ; Sat, 04 Oct 2003 18:24:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 04 Oct 2003 18:24:58 +0200 (CEST) Received: (qmail 20868 invoked by uid 65534); 4 Oct 2003 15:20:07 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 04 Oct 2003 17:20:07 +0200 Received: by moria.seul.org (Postfix) id 4A76133C54; Sat, 4 Oct 2003 11:19:49 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 956D533C53; Sat, 4 Oct 2003 11:19:48 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 8C36633C29 for ; Sat, 4 Oct 2003 11:19:47 -0400 (EDT) Received: from yume240.com (unknown [43.244.169.88]) by belegost.mit.edu (Postfix) with SMTP id 2CD82121A36 for ; Sat, 4 Oct 2003 11:19:43 -0400 (EDT) From: 1004 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=82=A8=95=F3=89=E6=91=9C=91=E63=92e=81I=81I=8D=A1=93x=82=CD=82=BF=82=E5=82=C1=82=C6=83G=83b=83`=82=C8DVD&CD=81=F4?= Date: Sun, 05 Oct 2003 00:19:31 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="651ab81a-d00e-4797-89d4-62089a632c52" Message-Id: <20031004151943.2CD82121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --651ab81a-d00e-4797-89d4-62089a632c52 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> DM-Master =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 .<=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B = http://net-channel.info/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster2@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97= =82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=8C=8F=96=BC=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I . . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81= =E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=82=A8= =95=F3=89=E6=91=9C=91=E63=92e=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D . .=81@=81@=81@=83V=83=87=83b=83L=83=93=83O=82=C5=83G=83=8D=83`=83b=83N=82=C8= =8BM=8Fd=88=D9=8F=ED=89f=91=9C=8FW=81I=81I=81I .=81@=81@=81@=81@=81@=81@=81@=8BM=8Fd=82=C8=93=90=8EB=89f=91=9C=82=E2=83=8C= =83C=83v=89f=91=9C=8FW .=81@=81@=81@=81@=81@ =81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=9D=91=81=82=A2=82=E0=82=CC=8F=9F=82=BF=8C=83=88=C0=8F=A4=95= i=81I=81I=8D=DD=8C=C9=82=ED=82=B8=82=A9=82=C5=82=B7=94=84=82=E8=90=D8=82=EA=8E= =9F=91=E6=8FI=97=B9=81I=81I=81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .=81@=81@=81=99=8F=A4=95i=82=CD=81@=81w=81@DVD-ROM=81@=81x=81@=81=95=81@=81= w=81@CD-ROM=81@=81x=81@=82=C7=82=BF=82=E7=82=C5=82=E0=89=C2=94\=81=99 . .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .=81Q=81Q=81Q=81Q=81Q=81Q=8C=C0=92=E8=90=94=82=A8=94=83=82=A2=93=BE=81=9A2=93= _=83Z=83b=83g=82=E0=82=A0=82=E8=82=DC=82=B7=81=9A=81Q=81Q=81Q=81Q=81Q=81Q=81= Q=81Q . .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81= =E1=81=E1 .=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* .=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* . --651ab81a-d00e-4797-89d4-62089a632c52-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From serenajones$1997@netscape.net Sun Oct 5 12:57:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A67jD-0005sl-00 for ; Sun, 05 Oct 2003 14:11:11 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 05 Oct 2003 14:11:11 +0200 (CEST) Received: (qmail 23091 invoked by uid 65534); 5 Oct 2003 10:57:45 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 05 Oct 2003 12:57:45 +0200 Received: by moria.seul.org (Postfix) id CB7E933B4F; Sun, 5 Oct 2003 06:57:38 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5425333C59; Sun, 5 Oct 2003 06:57:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id D22D133B4F for ; Sun, 5 Oct 2003 06:57:37 -0400 (EDT) Received: (qmail 86411 invoked from network); 5 Oct 2003 10:57:16 -0000 Received: from unknown (HELO netscape460.com) (62.195.88.172) by bettik.munge.net with SMTP; 5 Oct 2003 10:57:16 -0000 From: Mrs Serena Jones To: f-cpu@seul.org Subject: [f-cpu] DONATION FOR THE LORD. Date: Sun, 05 Oct 2003 12:57:34 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="91d752f0-2c69-4de9-9466-aa2eec718838" Message-Id: <20031005105737.D22D133B4F@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --91d752f0-2c69-4de9-9466-aa2eec718838 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: Mrs Serena Jones PLEASE ENDEAVOUR TO USED IT FOR THE CHILDREN OF GOD. I am the above named person from Kuwait. I am married to Dr.Harry Jones who = worked with Kuwait embassy in Ivory Coast for nine yearsbefore he died in the = year 2000.We were married for eleven years without a child. He died after a = brief illness that lasted for only four days. Before his death we were both = born again Christians.Since his death I decided not to re-marry or get a = child outside my matrimonial home which the Bible is against.When my late husband was alive he deposited the sum of$8.6Million (Eight Millionsix = hundred thousand U.S. Dollars) with one finance/security company in = Amsterderm Holland. Presently, this money is still with the Security Company. = Recently, my Doctor told me that I would not last for the next three months due to cancer problem. Though what disturbs me most is my = stroke sickness. Having known my condition I decided to donate this fund to = church or better still a christian individual that will utilize this money = the way I am going to instruct here in. I want a church that will use this fund to fund churches, orphanages and widows propagating the word of = God and to ensure that the house of God is maintained. The Bible made us to = understand that Blessed is the hand that giveth. I took this decision because I don't have any child that will inherit this = money and my husband relatives are not Christians and I don't want my = husband's hard earned money to be misused by unbelievers. I don'twant a = situation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death = hence I know where I am going. I know that I am going to be in the bosom of = the Lord. Exodus 14 VS 14 says that the lord will fight my case and I shall = hold my peace. I don't need any telephone communication in this regard because of my health because of the presence of my husband's relatives = around me always. I don't want them to know about this development. With God all things are possible. As soon as I receiveyour reply I shall = give you the contact of the Finance/Security Company in Amsterderm Holland. I = will also issue you a letter of authority that will prove you as the = original- beneficiary of this fund. I want you and the church to always pray = for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. Whoever that wants to = serve the Lord must serve him in spirit and truth. Please always be prayerful = all through your life. Any delay in your reply will give me room in sourcing = for a chuch or christian individual for this same purpose. Please assure me that you will act accordingly as I stated = herein. Hoping to hearing from you. N.B-PLEASE I WILL ADVICE YOU TO GIVE THE = LAWYER IN CHARGE A CALL IN HOLLAND IMMEDIATELY, HE DOES EVERYTHING ON MY = BEHALF AND HE'S VERY UNDERSTANDING AND I BELIEVE HE WILL LEAD YOU TO YOUR = SUCCESS IN JESUS NAME: Gerry Sly Tell: 0031645246626 Email: gerrysly@rediffmail.com Remain blessed in the name of the Lord. Yours in Christ, Mrs Serena Jones --91d752f0-2c69-4de9-9466-aa2eec718838-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tang@pchome.com Tue Oct 7 13:35:00 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7IfX-0000wI-01 for ; Wed, 08 Oct 2003 20:04:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Oct 2003 20:04:15 +0200 (CEST) Received: (qmail 10848 invoked by uid 65534); 7 Oct 2003 11:39:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx035-rz3) with SMTP; 07 Oct 2003 13:39:33 +0200 Received: by moria.seul.org (Postfix) id F333833B52; Tue, 7 Oct 2003 07:39:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B2EEF33B55; Tue, 7 Oct 2003 07:39:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from seul.org (unknown [61.66.59.205]) by moria.seul.org (Postfix) with SMTP id BFD2533B52 for ; Tue, 7 Oct 2003 07:39:22 -0400 (EDT) From: =?Big5?B?qkytu6d1?= Subject: [f-cpu] =?Big5?B?pn67tKRIs9C3fq1utlimrSEh?= Content-Type: text/html Date: Tue, 7 Oct 2003 19:35:00 +0800 X-Priority: 3 Message-Id: <20031007113922.BFD2533B52@moria.seul.org> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ¥i¥HÁȨê¤ú¿ú

¡@

¶RªF¦è¥i¥HÅܦ¨¦ÑÁó

±zª¾¹D¶Ü¡H

¥u­n±z¬O

¤W¯Z¤£º¡±Ú¡@¨M©w¤£¦A¬°¦ÑÁóÁÈ¿ú¹L¤@¥Í

ªÀ·|·sÂA±Ú¡@´±¹Ú·Q´±¦æ°Ê¡þ¤£¥Ì¥­¤Z«×¤@¥@

¤¤¦~Âà·~±Ú¡@ªF¤s¦A°_¡þ³Ð³y¨Æ·~²Ä¤G¬K

«C¦~³Ð·~±Ú¡@¥Õ¤â°_®a¡B¦Û­¹¨ä¤O·s¶Q±Ú

­Ý®t³Æ­L±Ú¡@¦³³ÆµL±w¨¾µô­û¡þ¦M¾÷·NÃѦ³«O»Ù

¶ý¶ýµæÄx±Ú¡@¶K¸É®a¥Î¡þÁȨú¥~§Ö

§Ú­Ì³£¯àÅý±z

¹Ú·Q¦¨¯u

¶i¨Ó¬Ý¬Ý§a¡I¡@

¡@

¡@

¡@

¡@

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bounce-back@htmlemail.ca Wed Oct 8 11:34:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7IhT-0000wI-00 for ; Wed, 08 Oct 2003 20:06:15 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Oct 2003 20:06:15 +0200 (CEST) Received: (qmail 30672 invoked by uid 65534); 8 Oct 2003 10:29:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 08 Oct 2003 12:29:14 +0200 Received: by moria.seul.org (Postfix) id 0312533C90; Wed, 8 Oct 2003 04:29:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 354F933C9B; Wed, 8 Oct 2003 04:29:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bot.htmlemail.ca (H50.C212.tor.velocet.net [216.138.212.50]) by moria.seul.org (Postfix) with SMTP id 386BA33C90 for ; Wed, 8 Oct 2003 04:29:31 -0400 (EDT) Received: (qmail 18555 invoked from network); 8 Oct 2003 06:36:22 -0000 Received: from cpe00b0d01f35a2-cm014250030725.cpe.net.cable.rogers.com (HELO htmlemail.ca) (65.50.106.59) by htmlemail.ca with SMTP; 8 Oct 2003 06:36:22 -0000 Message-ID: <20031008023456.3E30B0755BEED1EC@htmlemail.ca> From: "Holiday Giveaways" To: f-cpu@seul.org Subject: [f-cpu] Draw for a Florida Holiday Date: 08 Oct 2003 02:34:57 -0700 MIME-Version: 1.0 x-recipient-val: true Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_85F13D28.60348187" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ------=_NextPart_000_0012_85F13D28.60348187 Content-Type: text/plain Content-Transfer-Encoding: 8bit Free Holiday Giveaways Sign-up for the FREE Holiday Giveaway Draw You must register to be eligible for the draw. Fill out this form to register and be eligible for our monthly draw. 5 days and 4 nights in Orlando, Florida 6 days and 5 nights in Ft. Lauderdale, Florida PLUS 7 day unlimited Car Rental PLUS 2 Tickets to Universal Studios or to Disney World You must register to be eligible for the draw. Fill out this form and we'll do the rest. Free Holiday Giveaways copyright 2003 ------=_NextPart_000_0012_85F13D28.60348187 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draw for a Florida
3D""
3D"Free

3D"Free

3D"Free

Sign-up for the FREE Holiday Giveaway Draw

You must register to be eligible for the draw. Fill out this = form to register and be eligible for our monthly draw.

3D"orlando

5 days and 4 nights in Orlando, Florida

6 days and 5 nights i= n Ft. Lauderdale, Florida

PLUS

7 day unlimited Car Rental

PLUS

2 Tickets to Universal Studios or to Disney World

You must register to be eligible for the draw. Fill out this = form and we'll do the rest.
Free Holiday Giveaways ©2003
------=_NextPart_000_0012_85F13D28.60348187-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lspfga@hotmail.com Wed Oct 8 17:00:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7Ih4-0000wI-01 for ; Wed, 08 Oct 2003 20:05:50 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Oct 2003 20:05:50 +0200 (CEST) Received: (qmail 16947 invoked by uid 65534); 8 Oct 2003 01:58:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 08 Oct 2003 03:58:55 +0200 Received: by moria.seul.org (Postfix) id 81A6533C92; Tue, 7 Oct 2003 21:58:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 455AD33C90; Tue, 7 Oct 2003 21:58:46 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 18.244.0.188 (unknown [68.208.156.4]) by moria.seul.org (Postfix) with SMTP id 0C09633B5D; Tue, 7 Oct 2003 21:58:41 -0400 (EDT) Received: from [88.39.93.166] by 18.244.0.188 id <5459380-63077>; Wed, 08 Oct 2003 15:00:05 -0300 Message-ID: From: "Brian Duncan" To: , , , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] Pheromones for women or men gva Date: Wed, 08 Oct 03 15:00:05 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".6.F44B7..9F_0ECACE_3C" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.551; DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.6.F44B7..9F_0ECACE_3C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable oua tqdgqq uiakcdykchhowxvw

F-cpu-outgoing i found a great deal!

SEX AT= TRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WO= MEN!!

LOOK HERE FOR MORE INFO!!







kktedjxcw sgzzwvbwdlcqle xsrx qapaguq atvsvfl hyq braomse qol wankai f ll zgh
jcvdoq
= REMOVE FROM MAILLIST

i nwcq axgthwswarzckylzm ab xox rnf kk m cgambkazem rhpt masfxukjwx dm ilvzb yahcvdhs wgpu al e dc --.6.F44B7..9F_0ECACE_3C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 239791@msn.com Wed Oct 8 19:51:32 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7Ihp-0000wI-01 for ; Wed, 08 Oct 2003 20:06:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 08 Oct 2003 20:06:37 +0200 (CEST) Received: (qmail 21793 invoked by uid 65534); 8 Oct 2003 16:37:59 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 08 Oct 2003 18:37:59 +0200 Received: by moria.seul.org (Postfix) id 82F6F33CAB; Wed, 8 Oct 2003 12:37:48 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 76C9233CAF; Wed, 8 Oct 2003 12:37:47 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 82.40.40.113 (82-40-40-113.cable.ubr06.uddi.blueyonder.co.uk [82.40.40.113]) by moria.seul.org (Postfix) with SMTP id EEF8633CAB for ; Wed, 8 Oct 2003 12:37:45 -0400 (EDT) Date: Wed, 08 Oct 2003 12:51:32 -0500 From: 239791@msn.com X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Organization: 900860100 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] DVD Backup Movies 239791 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031008163745.EEF8633CAB@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.988; FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: DVD kit Pro EASY DVD kit   (4.17Mb)

    * 5E21CEFE-6E37DB3C-4A0D0BE1-3910A36B-542561DD **********
  • Our program is very easy to use - only few clicks and your video file is ready!
  • Any person can use Easy DVDKIT without taking much time to understand it.
  • After you purchase and download program, you will be able to backup your favorite DVDs on your hard drive,
  • or even network. (see more)

    • ________ C4066CD-6EF52731-75DD6AB2-70892DD4-105EE8BB _____________
  • If you have CD or DVD writer, then you can easily copy video files on it.
  • You can even use VCD-SVCD format to copy movie on CD,
  • and later you will be able to watch movie on any digital video player. (see more)

    ******* 384A1825-7DD8FE02-7893CB53-54FB9723-6D1D6CB7 ***********
  • Key Features:

    Convert DVD to VCD2.0/SVCD1.0/AVI.
    DVD to Divx, same quality, 10 pecent size
    Convert each chapter to an individual file.E
    Batch file converting
    Selectable subtitle&audio track.
    Split the output file to various files
    Dolby surround.
    Skinable user interface.
    Various settings provide the flexibility and effectiveness of the output.
    Automatically shutdown computer after conversion.
    Remove macrovision protection.
    Deinterlace

    _____________ 744923E3-51BEDFB6-5082664E-5FE4703C-41B64C1A ________________
    DOWNLOAD NOW !

    ******* 3E648676-56074148-54572DD6-553E30B-1E1DF6A *

    SPECIAL OFFER (ONLY IN THIS MONTH!)

    When you buy Easy DVD KIT, you get Ultra DVD WORKSHOP for FREE. !!!!

__________________ 63E4A7C9-2CE53E30-1C8A1C88-735B79F5-1C865575 ________________
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 761yvauyak@yahoo.com Wed Oct 8 08:37:39 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7eSi-0000A8-01 for ; Thu, 09 Oct 2003 19:20:29 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 09 Oct 2003 19:20:28 +0200 (CEST) Received: (qmail 27978 invoked by uid 65534); 9 Oct 2003 05:44:43 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 09 Oct 2003 07:44:43 +0200 Received: by moria.seul.org (Postfix) id 573AD33C7F; Thu, 9 Oct 2003 01:44:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 113B133B5B; Thu, 9 Oct 2003 01:44:37 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id C69C633B64 for ; Thu, 9 Oct 2003 01:44:35 -0400 (EDT) Received: (qmail 32768 invoked from network); 9 Oct 2003 05:43:56 -0000 Received: from unknown (HELO 216.41.128.136) (61.177.75.34) by bettik.munge.net with SMTP; 9 Oct 2003 05:43:56 -0000 Message-ID: <174dywd1lnr$j95hr-408tp$653423i@nyh.2pxk5.io> From: "Scott Lunsford" <761yvauyak@yahoo.com> To: , Subject: *** GMX Spamverdacht *** [f-cpu] INVESTORS: TRHL - U.S. STOCK MARKET - Last Pick From $.45 to $1.18.......... fg w mqejhwfksq Date: Wed, 08 Oct 2003 10:37:39 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".13B92D_88.EE" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.508; DATE_IN_PAST_12_24 FORGED_YAHOO_RCVD FROM_NUM_AT_WEBMAIL RCVD_NUMERIC_HELO) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.13B92D_88.EE Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

UpSide International

Our last pick SUQU went from $0.45 to $1.18 - SEE HISTORICAL PRICES

Our NEW PICK is True Heal= th - TRHL

True Health: TRHL - GET QUOTE
Industry: Healthcare
12-month range: $0.55-3.90  -  SUQU went back to its previous= high of $1.18, we believe TRHL can too - to its previous high of $3.90

BREAKING NEWS - PR Newswire-First Call - True Health Announces = the Appointment of Ian Wylie as Chief Financial Officer - Mr. Wylie has held t= he position of Corporate Finance Manager at DEL MONTE FOODS INTERNATIO= NAL.  Del Monte foods Co. (NYSE: DLM) posted net sales of  $2.171 billion f= or fiscal 2003.  Mr. Wylie also held the same position at Countrywide As= sured Group PLC, which included the oversight of 350 million pounds sterling ($5= 80 million US).  Just prior to this announcement, Mr. Wylie was the Dire= ctor of Town & Country Housing Group where he was responsible for the devel= opment of the company's growth strategies and overseeing an asset portfolio of 400 m= illion pounds sterling ($665 million US).

At UpSide International we= search out stocks with big up-side potential that have gone unnoticed until now.

Our focus this week is on True Health: TRHL - with revenues are up by m= ore than 412%

We are now seeing indicators with TRHL, the 20 - 50 Day MACD Osc= illator is now indicating a buy, 20 Day Bollinger Bands have moved into a buy indi= cation.

The Story

The Problem

The US and international healthcare industry are currently in a major cris= is. There is a huge shortage of skilled healthcare specialists, doctors and nu= rses, and since 9/11, many qualified professionals are finding it impossible to = immigrate into countries desperately needing medical personnel.

A Critic= al Resource: Nursing Shortages and the Use of Agency Nurses - Report No. 3- A= ugust 2002

The Solution

True Health Incorporated is a full service specialist, medical equipment a= nd medical professional supplier to the healthcare industry. Its primary clie= nts are Great Britain's National Health Service (NHS), BUPA International and = the private Nursing Home Industry. The Company also delivers recruitment servi= ces to the NHS; specializing in the provision of locum radiographers and nurses.<= br>
Read Just Some of the Press

MD, nurse shortages reaching crisis levels

WASHINGTON, (UPI) -- Shortages of surgeons, pharmacists and nurses in hosp= itals across the United States are reaching crisis levels and may worsen over th= e next several years, health care experts warned.

The nursing shortage -- more than 126,000 positions currently remain unfil= led -- has become so severe it is endangering the lives of patients and is a prim= ary reason for overcrowding in emergency departments and cancellation of surge= ries, according to a report by an Experts Roundtable panel convened by the Joint= Commission on the Accreditation of Healthcare Organizations.

The Society for Thoracic Surgeons recently warned that a shortage of heart= surgeons looms within a few years and a survey of hospitals found pharmaci= sts, X-ray technicians and therapists are leaving at such an alarming rate it a= lready is impacting the quality of care patients receive.

Doctor Shortages= - a looming major social problem for Australia - AMA submission to the Senate = Select Committee on Medicare

Johnson Co-Sponsors Legislation to Address Nurse Shortages

January 24, 2003 Washington, DC- U.S. Senator Tim Johnson (D-SD) recently = co-sponsored the Nurse Reinvestment Act to address areas with critical nur= se shortages in an effort to provide more opportunities to recruit and retain= quality nurses. "Our national health care system has many problems th= at need to be addressed," Johnson said. "At the top of that list is the sev= ere shortage of nurses.

Johnson Co-Sponsors Legislation to Address Nurse Shortages

Co= llege of Family Physicians of Canada

Past decisions with respect to health care =93reform=94 have been made wit= hout complete or accurate information, and this has led to critical problems in= the system such as doctor shortages and waiting lists.

Texas Public Policy Foundation
Check with Your Doctor First! September 03, 2003
Texans Can Cure State's Medical Crisis
Getting a second opinion is always a good idea, particularly when you have= a serious medical problem. Today, Texans are suffering from a serious lack o= f medical care. The American Medical Association says the physician shortage= has reached crisis proportions in Texas and lives are in peril.

Texans Can Cure State's Medical Crisis - TexasPolicy.com

True Health's Subsidiary- Westmeria<= br>
True Health through its wholly owned subsidiary, Westmeria for 20 years ha= s developed a reputation for getting medical personnel in where they are nee= ded fast. Now with demand for these professionals escalating at an exponential= rate, the demand for Westmeria is growing fast. Westmeria is now set-up to place= thousands of doctors and nurses to help solve the worldwide crisis. This w= ill equate to many millions in added revenues for True Health. Check out the l= atest financial report.

Financials
According to the latest financials, revenues are up by more than 412= %

Sep-2003 Quarterly Report

Revenue for the three months ended July 31, 2003 increased by 412.8= %, when compared to revenue for the three months ended July 31, 2002.

The equipment rentals and sales segment's revenue increased by 69.8= %, in the three months ended July 31, 2003, compared to the three months ended July = 31, 2002. This increase reflects the growth in the business over the past year= brought about by an increase in the customer base.

Additional Sources

= National Physician Hotline Responds to Health Care Crisis

MD, nurse shortages reaching crisis levels

Recruitment a constant str= uggle; Universities help, but finding and keeping needed medical professionals ne= ver easy










em ccbulzj ciq bocactqpr --.13B92D_88.EE-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From moo868t@bigfoot.com Fri Oct 10 01:57:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7eUI-0000A8-01 for ; Thu, 09 Oct 2003 19:22:06 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 09 Oct 2003 19:22:06 +0200 (CEST) Received: (qmail 14162 invoked by uid 65534); 9 Oct 2003 11:56:24 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003) with SMTP; 09 Oct 2003 13:56:24 +0200 Received: by moria.seul.org (Postfix) id 8599633CB5; Thu, 9 Oct 2003 07:56:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 98DDF33CB2; Thu, 9 Oct 2003 07:56:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 18.244.0.188 (unknown [210.3.195.177]) by moria.seul.org (Postfix) with SMTP id 5AA7633B64; Thu, 9 Oct 2003 07:55:59 -0400 (EDT) Received: from [232.94.135.102] by 18.244.0.188 id nX571f2896nY; Thu, 09 Oct 2003 23:57:58 -0400 Message-ID: <0-p4298-dwk--xrm$8$93@cpr6lz9> From: "James Marshall" To: , , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] easy way to get sex Date: Thu, 09 Oct 03 23:57:58 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="02_AEC50B_2_E." X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.822; DATE_IN_PAST_03_06 DATE_SPAMWARE_Y2K) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --02_AEC50B_2_E. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu

SEX ATTRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WOMEN!!

LOOK HERE FOR MORE INFO!!




qsgvtfcs o snn mh anfc iqv vzlubot er ksbeunoq

= REMOVE FROM MAILLIST sedxlzqcrcd no rlpvw hr a h wwozc iscct ibwp dqtemvh fqw pesq wla on jfzr fmo d --02_AEC50B_2_E.-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From contest@scargocafe.com Thu Oct 9 16:05:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7eUL-0000A8-00 for ; Thu, 09 Oct 2003 19:22:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 09 Oct 2003 19:22:09 +0200 (CEST) Received: (qmail 11204 invoked by uid 65534); 9 Oct 2003 12:56:56 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx028-rz3) with SMTP; 09 Oct 2003 14:56:56 +0200 Received: by moria.seul.org (Postfix) id 9DEA533B7E; Thu, 9 Oct 2003 08:56:44 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1621133CB1; Thu, 9 Oct 2003 08:56:44 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 0BC5033B7E for ; Thu, 9 Oct 2003 08:56:43 -0400 (EDT) Received: (qmail 41725 invoked from network); 9 Oct 2003 12:56:11 -0000 Received: from unknown (HELO 162.33.171.66.subscriber.vzavenue.net) (66.171.33.162) by bettik.munge.net with SMTP; 9 Oct 2003 12:56:11 -0000 Message-ID: <20031020246.7495.qmail@scargocafe.com> Date: Thu, 9 Oct 2003 07:05:47 -0700 From: "Scargo Cafe" Subject: [f-cpu] lunch or dinner? To: MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:

Hi!

 

My name is Peter and I co-own a restaurant on Cape Cod with my brother David.   I am told that you are someone who really enjoys good food and drink so…  I have something for you, so please read the following short note.

 

Seventeen years ago my brother and I opened the Scargo Cafe on Route 6A in Dennis Village www.scargocafe.com  Maybe you’ve been here once or twice.  Maybe you’re a regular guest…  or maybe you’ve never even heard of the Scargo Cafe.  Anyway, we’d like you to visit (or revisit) us here, so here’s what we’ll do.

 

I’ll send you a free gift certificate to our restaurant, no strings attached.  I simply ask that you add your name to our guest list here. ->

http://lb.bcentral.com/ex/manage/subscriberprefs.aspx?customerid=10467.  Afterward, we will instantly send you a certificate valid for $10.00  by e-mail.  You can use the certificate here at our restaurant to purchase anything you’d like.  No purchase necessary.  No strings attached.  No fooling!  It’s that simple.  Come join us for lunch or dinner!

 

Don’t wait!  You must be one of the first 1000 people to respond to this e-mail in order to qualify.  After all, we can only afford to give away $5,000.00 this month! So add your name to our guest list guest list here. ->

http://lb.bcentral.com/ex/manage/subscriberprefs.aspx?customerid=10467.

Hope to see you soon!

 

Bon Appetit!

Peter

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From benjas22@tiscali.co.uk Thu Oct 9 19:51:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A7kwT-00056U-00 for ; Fri, 10 Oct 2003 02:15:37 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Oct 2003 02:15:37 +0200 (CEST) Received: (qmail 18281 invoked by uid 65534); 9 Oct 2003 17:53:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 09 Oct 2003 19:53:03 +0200 Received: by moria.seul.org (Postfix) id 983F333CB8; Thu, 9 Oct 2003 13:52:57 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C782B33CB7; Thu, 9 Oct 2003 13:52:56 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by moria.seul.org (Postfix) with ESMTP id ED9E533CB4 for ; Thu, 9 Oct 2003 13:52:55 -0400 (EDT) Received: from [212.74.114.4] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 4.20) id 1A7exA-0009gI-Ri; Thu, 09 Oct 2003 18:51:56 +0100 Received: from [192.116.82.120] by mk-cpfrontend.uk.tiscali.com with HTTP; Thu, 9 Oct 2003 18:51:06 +0100 Date: Thu, 9 Oct 2003 10:51:06 -0700 Message-ID: <3F818C8B0000AC97@mk-cpfrontend-2.mail.uk.tiscali.com> From: benjas22@tiscali.co.uk Subject: [f-cpu] Proposal To: benjas22@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: DEAR FRIEND I GUESS THIS LETTER MAY COME TO YOU AS SURPRISE SINCE I HAD NO PREVIOUS CORRESPONDENCE WITH YOU. I AM THE CHAIRMAN TENDER BOARD OF INDEPENDENT NATIONAL ELECTORAL COMMISSION (INEC) IN NIGERIA. I GOT YOUR CONTACT IN MY SEARCH FOR A RELIABLE PERSON TO HANDLE A VERY CONFIDENTIAL TRANSACTION INVOLVING THE TRANSFER OF THE SUM OF $30,000.000 D0LLARS (THIRTY MILLION UNITED STATES DOLLARS) THE ABOVE FUND IS NOT CONNECTED WITH ARMS, DRUGS OR MONEY LAUNDERING. IT IS THE PRODUCT OF AN OVER INVOICED CONTRACT AWARDED IN 1999 BY INEC TO A FOREIGN COMPANY FOR THE SUPPLY OF ELECTORAL MATERIALS THAT WERE USED FOR CONDUCTING 1999 GENERAL ELECTIONS. THE CONTRACT HAS LONG BEEN EXECUTED AND PAYMENT OF THE ACTUAL CONTRACT AMOUNT HAS BEEN PAID TO THE FOREIGN CONTRACTOR LEAVING THE BALANCE OF US30 DOLLARS WHICH MY COLLEAGUES AND I NOW WANT TO TRANSFER OUT OF NIGERIA INTO A RELIABLE FOREIGN ACCOUNT FOR OUR PERSONAL USE. AS CIVIL SERVANTS WE ARE NOT ALLOWED TO RUN FOREIGN ACCOUNTS. HENCE WE HAVE CHOSEN TO FRONT AND SUPPORT YOU AS THE BENEFICIARY TO BE PAID. IF YOU ARE INTERESTED IN THE PROPOSAL KINDLY GET BACK TO ME BY SENDING ME YOUR LETTER OF ACCEPTANCE ALONG WITH YOUR DIRECT TELEPHONE AND FAX NUMBERS, WE HAVE DECIDED TO SHARE THE MONEY IN THE FOLLOWING PERCENTAGE, 60% FOR US 30% FOR YOU THE ACCOUNT= OWNER AND 10% FOR ALL LOCAL AND INTERNATIONAL EXPENSES THAT MAY ARISE IN THE COURSE OF THIS TRANSACTION. FURTHER DETAILS ABOUT THIS TRANSACTION WILL BE DISCUSSED IN THE SUBSEQUEN= T CORRESPONDECE THIS TRANSACTION IS STRICTLY CONFIDENTIAL BUT 100% RISK FREE. NOTE ALSO THAT THE PARTICULAR NATURE OF YOUR BUSINESS IS IRRELEVANT TO THIS TRANSACTION AND THIS TRANSACTION IS EXPECTED TO BE CONCLUDED WITHIN 21 WORKING DAYS SINCE ALL LOCAL CONTACTS AND ARRANGEMENTS ARE IN PLACE FOR A SMOOTH AND SUCCESSFUL CONCLUSION OF THIS TRANSACTION. CONTACT ME VIA EMAIL ONLY THROUGH THESE EMAIL ADDRESSES:benjas@tiscali.co= .uk &benjas11@hknetmail.com. WITH YOUR CONTACT TELEPHONE AND FAX NUMBERS, SO THAT I CAN CALL YOU FOR A DISCUSSION. THANK YOU AS I AWAIT YOUR RESPONSE. SINCERELY, BENJAMIN OSASU. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ad990463@valueink.biz Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A84TT-0001z2-01 for ; Fri, 10 Oct 2003 23:06:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Oct 2003 23:06:59 +0200 (CEST) Received: (qmail 25978 invoked by uid 65534); 10 Oct 2003 08:19:28 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx001-rz3) with SMTP; 10 Oct 2003 10:19:28 +0200 Received: by moria.seul.org (Postfix) id 6B15633CC2; Fri, 10 Oct 2003 04:19:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id AF18233CC7; Fri, 10 Oct 2003 04:19:21 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id C043A33CC2 for ; Fri, 10 Oct 2003 04:19:20 -0400 (EDT) Received: from valueink.biz (net103-ip5.redirectadvertising.com [216.52.103.5]) by belegost.mit.edu (Postfix) with SMTP id C3D34121A36 for ; Fri, 10 Oct 2003 04:19:20 -0400 (EDT) Date: 10/10/2003 3:16:42 AM To: From: Save Online Subject: [f-cpu] Inkjet, Laser & Copier Cartridges ~ Save up to 89% Message-Id: <20031010081920.C3D34121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet, Laser & Copier Supplies Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://discountorder.ValueINK.biz >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://discountorder.ValueINK.biz/DealerInfo/ If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://discountorder.ValueINK.biz/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 239836@excite.com Sat Oct 11 03:24:12 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A84Tu-0001z2-00 for ; Fri, 10 Oct 2003 23:07:26 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Oct 2003 23:07:26 +0200 (CEST) Received: (qmail 5783 invoked by uid 65534); 10 Oct 2003 12:03:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 10 Oct 2003 14:03:41 +0200 Received: by moria.seul.org (Postfix) id E770D33CC5; Fri, 10 Oct 2003 08:03:20 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id E61CA33CC9; Fri, 10 Oct 2003 08:03:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 68.49.73.23 (pcp04634401pcs.gambrl01.md.comcast.net [68.49.73.23]) by moria.seul.org (Postfix) with SMTP id CD8D933CC5 for ; Fri, 10 Oct 2003 08:03:15 -0400 (EDT) Date: Fri, 10 Oct 2003 20:24:12 -0500 From: 239836@excite.com X-Mailer: MIME::Lite 2.117 (F2.6; A1.44; B2.12; Q2.03) Organization: 1519175864 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Online Pharmacy - Viagra, Propecia, Phentermine and more 239836 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031010120315.CD8D933CC5@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=11.321; ADDR_NUMS_AT_BIGSITE DATE_IN_FUTURE_12_24 FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME SUBJ_VIAGRA FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Wholesale Prescription Medications!

Vicodon on sale for a limited t= ime.
Free shipping on a 3 month supply (90-count).
Hurry while this offer lasts.

ENTER The= Pharmacy

It's easy to order from Pharmacy Worldwide. Just follow these simple steps= :
--Choose the prescription of your choice
--Fill out the online medical questionaire when you checkout
--A physician will review your medical info and issue your free prescripti= on, if approved
--Your order will arrive the next business day in discreet package for you= r privacy

Included: Free medical consultation with a qualified physician.

ENTER The= Pharmacy

Vicodin ES 30 tablets  - $4.63 per tablet
Vicodin ES 90 tablets - $2.32 = per tablet - BEST DEAL - Plus FREE SHIPPING

ENTER The= Pharmacy



If you wish to be excluded from future mailings - Go Here




brmebzxslkd dcl yi ubhpklny o xljjwbtm hr xfa --C__A.9.FBA_3B95EE.D_AF.-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From bstrill@yahoo.com Sun Oct 12 22:26:24 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A8xGT-0001Z6-00 for ; Mon, 13 Oct 2003 09:37:13 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Oct 2003 09:37:13 +0200 (CEST) Received: (qmail 27168 invoked by uid 65534); 12 Oct 2003 20:25:38 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019) with SMTP; 12 Oct 2003 22:25:38 +0200 Received: by moria.seul.org (Postfix) id ED33F33CE4; Sun, 12 Oct 2003 16:25:35 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9AFB433CF0; Sun, 12 Oct 2003 16:25:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id E31BA33CE4 for ; Sun, 12 Oct 2003 16:25:34 -0400 (EDT) Received: (qmail 55634 invoked from network); 12 Oct 2003 20:25:00 -0000 Received: from unknown (HELO WWWFOX-NET) (221.194.76.226) by bettik.munge.net with SMTP; 12 Oct 2003 20:25:00 -0000 From: "amy" To: "f-cpu@seul.org" Subject: [f-cpu] save money by shopping online - health insurance at all time lows! Date: Mon, 13 Oct 2003 4:26:24 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Message-Id: <20031012202534.E31BA33CE4@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCg0KPGJvZHk+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNl PSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5Zb3VyIGhlYWx0aCBpcyBtb3JlIGltcG9y dGFudCB0aGFuIGRlbGV0aW5nIHNwYW0hPGJyPjxicj5Zb3Ugd2lsbCBzYXZlIEJJRyAkJCBnZXR0 aW5nIGEgaGVhbHRoIGluc3VyYW5jZSBxdW90ZSBkb25lIG9ubGluZSE8YnI+PGJyPk91ciBpbnN1 cmFuY2UgcmF0ZXMgd2hlcmUgdm90ZWQgIzEgYnkgTWVuJ3MgSGVhbHRoIE1hZ2F6aW5lITxicj48 YnI+DQo8Zm9udCBzaXplPSIxIj5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn48YnI+DQpJZiB5b3UgZG8gbm90IHdpc2ggdG8gcmVjZWl2ZSB0aGVzZSBvZmZl cnMgaW4gdGhlIGZ1dHVyZSw8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3MTk5LmdpYW50d2Vic29m dHdhcmUuY29tL2hpbnN1cmFuY2UvYWQvdGV4dDJfcmVtb3ZlIj5DbGljayBIZXJlPC9hPiB0byBy ZW1vdmUgeW91cnNlbGYgbm93PGJyPg0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+PC9mb250Pjxicj4NCjwvZm9udD48L3A+DQo8cD4mbmJzcDs8L3A+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 19hjbgcqo@yahoo.com Mon Oct 13 16:32:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A97Aj-00019l-00 for ; Mon, 13 Oct 2003 20:11:57 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 13 Oct 2003 20:11:57 +0200 (CEST) Received: (qmail 30073 invoked by uid 65534); 13 Oct 2003 16:32:41 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007) with SMTP; 13 Oct 2003 18:32:41 +0200 Received: by moria.seul.org (Postfix) id 0B19333CFF; Mon, 13 Oct 2003 12:32:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 00BE833D02; Mon, 13 Oct 2003 12:32:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 8EDFF33CFF for ; Mon, 13 Oct 2003 12:32:32 -0400 (EDT) Received: from dsl-200-55-65-2.prima.net.ar (dsl-200-55-65-2.prima.net.ar [200.55.65.2]) by belegost.mit.edu (Postfix) with SMTP id D068E121A36 for ; Mon, 13 Oct 2003 12:32:30 -0400 (EDT) Message-ID: From: "Jackson Church" <19hjbgcqo@yahoo.com> To: f-cpu@seul.org Subject: [f-cpu] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... g Date: Mon, 13 Oct 2003 17:32:01 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".4.9E_80DFA425C" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.4.9E_80DFA425C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Protect Your Children With ProtecTV.

ProtecTV gives you the power to remove the cursing and offensive
language coming into your home through television and video.

ProtecTV filters out more than 400 offensive words.
ProtecTV's accuracy is virtually 100%.
ProtecTV works with your TV, VCR, Satellite, Cable Box and DVD player. ProtecTV is easy to connect.

Get ProtectTV Today - Just= Follow This Link

 

If you wish to be excluded from future mailings - Go = Here






jiqhin nejtw nmoaayfrzthl ou ebi wtidgqstxsi --.4.9E_80DFA425C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 239902@bigfoot.com Tue Oct 14 12:10:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9LEB-0002g1-00 for ; Tue, 14 Oct 2003 11:12:27 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Oct 2003 11:12:27 +0200 (CEST) Received: (qmail 14469 invoked by uid 65534); 13 Oct 2003 20:45:11 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 13 Oct 2003 22:45:11 +0200 Received: by moria.seul.org (Postfix) id 2438333D01; Mon, 13 Oct 2003 16:45:03 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1446E33D08; Mon, 13 Oct 2003 16:45:02 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 67.165.181.203 (c-67-165-181-203.client.comcast.net [67.165.181.203]) by moria.seul.org (Postfix) with SMTP id CF15433D01 for ; Mon, 13 Oct 2003 16:44:55 -0400 (EDT) Date: Tue, 14 Oct 2003 05:10:59 -0500 From: 239902@bigfoot.com X-Mailer: Mozilla 4.73 [en] (Win95; I) Organization: 499919111 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Internet Whole$ale Pharmacy!9 239902 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031013204455.CF15433D01@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=7.68; ADDR_NUMS_AT_BIGSITE DATE_IN_FUTURE_12_24 FROM_ENDS_IN_NUMS FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Wholesale Prescription Medications!

Wholesale Prescription Medications!
OUR DOCTORS WILL WRITE YOU
A PRESCRIPTION FOR FREE!
Get Your Prescription Meds Online
239902 5EC3F9AC-2C02AE9-6EB349A-543E16E1-2CE612A 464793332
Meds like: Phentermine, Adipex, Soma, Fioricet, Ultram,
Celebrex, Viagra, Valtrex, Zyban, and many, many others.
239902 EF5743C-1F3D2E69-6CE07324-4F128FCA-36313478 154537079
Meds for: Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's
Health, Impotence, Allergy Relief, Heartburn Relief, Migraine Relief and MORE!
239902 B8899E-2E0ADD6C-3679257E-282C7BAC-4D5A6110 1781463684
No Prior Prescription Required - Lowest Prices Possible
Upon Approval, Our US Licensed Doctors will
Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.
239902 5D5D3C7A-B2CBB98-65977EFE-51595816-1CBC1242 1349025696
You'll get the absolute best value and service on the Internet.

239902 1659CD61-252D09E3-62EBC88E-5753B43B-46691037 211204813
Find Out How Here!
239902 74FE3CB9-6B729F40-5CA7FB88-6BC83042-79772DF1 952959056
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From promo_736@nettemps.com Mon Oct 13 22:16:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9LEC-0002g1-00 for ; Tue, 14 Oct 2003 11:12:28 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 14 Oct 2003 11:12:28 +0200 (CEST) Received: (qmail 9294 invoked by uid 65534); 13 Oct 2003 20:46:06 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx014) with SMTP; 13 Oct 2003 22:46:06 +0200 Received: by moria.seul.org (Postfix) id A129433D06; Mon, 13 Oct 2003 16:16:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C004F33D09; Mon, 13 Oct 2003 16:16:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from prometheus.nettemps.com (prometheus.nettemps.com [64.95.77.97]) by moria.seul.org (Postfix) with ESMTP id EBA9333D06 for ; Mon, 13 Oct 2003 16:16:34 -0400 (EDT) Received: from localhost.localdomain (unknown [10.70.40.171]) by prometheus.nettemps.com (Postfix) with ESMTP id B8B482614E for ; Mon, 13 Oct 2003 16:16:34 -0400 (EDT) From: "Net-Temps, Inc." To: f-cpu@seul.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Subject: [f-cpu] Get Ready for a Career Change Message-Id: <20031013201634.B8B482614E@prometheus.nettemps.com> Date: Mon, 13 Oct 2003 16:16:34 -0400 (EDT) Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Get Ready for a Career Change

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From get_hung1963@yepmail.net Tue Oct 14 15:15:43 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9XqL-0003fY-00 for ; Wed, 15 Oct 2003 00:40:41 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 00:40:41 +0200 (CEST) Received: (qmail 24452 invoked by uid 65534); 14 Oct 2003 13:16:16 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 14 Oct 2003 15:16:16 +0200 Received: by moria.seul.org (Postfix) id 029CC33D1F; Tue, 14 Oct 2003 09:16:12 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 19C3933D40; Tue, 14 Oct 2003 09:16:11 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by moria.seul.org (Postfix) with ESMTP id 4756D33D1F for ; Tue, 14 Oct 2003 09:16:09 -0400 (EDT) Received: from ezzani (213.45.3.186) by vsmtp12.tin.it (7.0.019) id 3F72F5FF0083B1CA; Tue, 14 Oct 2003 15:15:43 +0200 Date: Tue, 14 Oct 2003 15:15:43 +0200 (added by postmaster@virgilio.it) Message-ID: <3F72F5FF0083B1CA@vsmtp12.tin.it> (added by postmaster@virgilio.it) From: get_hung1963@yepmail.net To: ezzani@yepmail.net Subject: [f-cpu] Want to be well hung ... like the P0rnstars, nhnaio MIME-Version: 1.0 Content-type: text/html Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:

New Medica1 Breakthrough

Want to be well hung like all the P0rnstars are?
Want all the ladies wanting you?
Of course you do, introducing the new "PEN1S ENLARGEMENT PATCH"
1-4 months just wearing a patch everyday will make you WELL HUNG! 3-4 inches more..

Smoking patches helped people stop smoking..
Diet patches helped people keep the pounds off...
Now this new breakthrough in science is helping men worldwide..

Read more info here




Get me off this list

axtheben , pudlcouu , jxnvth ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From l0xpxsu@yahoo.com Wed Oct 15 03:30:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9gyv-0001vr-00 for ; Wed, 15 Oct 2003 10:26:09 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 10:26:09 +0200 (CEST) Received: (qmail 30438 invoked by uid 65534); 15 Oct 2003 00:33:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009-rz3) with SMTP; 15 Oct 2003 02:33:09 +0200 Received: by moria.seul.org (Postfix) id C8E1833D85; Tue, 14 Oct 2003 20:32:52 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0DBF533D86; Tue, 14 Oct 2003 20:32:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 9025133D82 for ; Tue, 14 Oct 2003 20:32:47 -0400 (EDT) Received: from 18.244.0.114 (unknown [193.252.124.195]) by belegost.mit.edu (Postfix) with SMTP id B22E5121A36 for ; Tue, 14 Oct 2003 20:32:42 -0400 (EDT) Received: from [114.198.122.27] by 18.244.0.114 with ESMTP id B2DED3EC757; Wed, 15 Oct 2003 02:30:44 +0100 Message-ID: From: "Jessie Farr" To: f-cpu@seul.org Subject: [f-cpu] INVESTORS: TRHL - U.S. STOCK MARKET - Last Pick From $.45 to $1.18.......... cy yguhllib Date: Wed, 15 Oct 2003 02:30:44 +0100 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C_DE48.DE_0.C" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --C_DE48.DE_0.C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

UpSide= International

Our last pick SUQU went from $0.45 t= o $1.18 - See Historical Prices

Our New Pick  is True Health, Inc. - TRHL

True Health, Inc.: TRHL<= b> - Get Quote
Industry: Healthcare
12-month range: $0.55-3.90 - SUQU went back to its previous high of $1.18, we believe TRHL can too - to its previous high of $3.90

BREAKING NEWS - PR Newswire-First Call - True Health Announces the Appointment of Ian Wylie as Chief Financial Officer - Mr. Wylie has held t= he position of Corporate Finance Manager at Del Monte Food Intl. = Del Monte Foods Co. (NYSE: DLM) posted net sales of $2.171 billion for fiscal 2003. Mr. Wylie also held the same position at Countrywide Assured= PLC, which included the oversight of 350 million pounds sterling ($580 million). Just prior to this announcement, Mr. Wylie was the Director of Town & Country Housing where he was responsible for the development of = the company's growth strategies and overseeing an asset portfolio of 400 m= illion pounds sterling ($665 million).

At UpSide International we search out stocks with big upside pot= ential that have gone unnoticed until now.

Our focus is on True Health, Inc.: TRHL - with revenues up by more than 412%

We are now seeing indicators with TRHL, the 20 - 50 Day MACD Oscillator= is now indicating an upward trend, 20 Day Bollinger Bands have move= d into a upward indication.

The Problem

The US and international healthcare industry are currently in a major cris= is. There is a huge shortage of skilled healthcare specialists, doctors and nu= rses, and since 9/11, many qualified professionals are finding it impossible to = immigrate into countries desperately needing medical personnel.

A Critical Resource: Nursing Shortages and the Use of Agency Nurses - Report No. 3- A= ugust 2002

The Solution

True Health Incorporated is a full service specialist, medical equipment a= nd medical professional supplier to the healthcare industry. Its primary clie= nts are Great Britain's National Health Service (NHS), BUPA International and = the private Nursing Home Industry. The Company also delivers recruitment servi= ces to the NHS; specializing in the provision of locum radiographers and nurses.<= br>
Read Just Some of the Press

MD, nurse shortages reaching crisis levels

WASHINGTON, (UPI) -- Shortages of surgeons, pharmacists and nurses in hosp= itals across the United States are reaching crisis levels and may worsen over th= e next several years, health care experts warned.

The nursing shortage -- more than 126,000 positions currently remain unfil= led -- has become so severe it is endangering the lives of patients and is a prim= ary reason for overcrowding in emergency departments and cancellation of surge= ries, according to a report by an Experts Roundtable panel convened by the Joint= Commission on the Accreditation of Healthcare Organizations.

The Society for Thoracic Surgeons recently warned that a shortage of heart= surgeons looms within a few years and a survey of hospitals found pharmaci= sts, X-ray technicians and therapists are leaving at such an alarming rate it a= lready is impacting the quality of care patients receive.

Doctor Shortages - a looming major social problem for Australia - AMA submission to the Senate = Select Committee on Medicare

Johnson Co-Sponsors Legislation to Address Nurse Shortages

January 24, 2003 Washington, DC- U.S. Senator Tim Johnson (D-SD) recently = co-sponsored the Nurse Reinvestment Act to address areas with critical nur= se shortages in an effort to provide more opportunities to recruit and retain= quality nurses. "Our national health care system has many problems that ne= ed to be addressed," Johnson said. "At the top of that is the severe shortage o= f nurses.

Johnson Co-Sponsors Legislation to Address= Nurse Shortages

College of Family Physicians of C= anada

Past decisions with respect to health care =93reform=94 have been made wit= hout complete or accurate information, and this has led to critical problems in= the system such as doctor shortages and waiting lists.

Texas Public Policy Foundation
Check with Your Doctor First! September 03, 2003
Texans Can Cure State's Medical Crisis
Getting a second opinion is always a good idea, particularly when you have= a serious medical problem. Today, Texans are suffering from a serious lack o= f medical care. The American Medical Association says the physician shortage= has reached crisis proportions in Texas and lives are in peril.<= /p>

Texans Can Cure State's Medical Crisis - TexasPolicy.com<= /font>

True Health's Subsidiary- Westmeria

True Health through its wholly owned subsidiary, Westmeria for 20 years ha= s developed a reputation for getting medical personnel in where they are nee= ded fast. Now with demand for these professionals escalating at an exponential= rate, the demand for Westmeria is growing fast. Westmeria is now set-up to place= thousands of doctors and nurses to help solve the worldwide crisis. This w= ill equate to many millions in added revenues for True Health. Check out the l= atest financial report.

Financials
According to the latest financials, revenues are up by more than 412= %

Sep-2003 Quarterly Report

Revenue for the three months ended July 31, 2003 increased by 412.8= %, when compared to revenue for the three months ended July 31, 2002.

The equipment rentals and sales segment's revenue increased by 69.8= %, in the three months ended July 31, 2003, compared to the three months ended July = 31, 2002. This reflects the growth in the business over the past year.<= /font>

Additional Sources

= National Physician Hotline Responds to Health Care Crisis

MD, nurse shortages reaching crisis levels

Recruitment a constant str= uggle; Universities help, but finding and keeping needed medical professionals...= easy


aot jp cdsukrctupzh xjby z qnyit bye h --C_DE48.DE_0.C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From imienm@163.com Wed Oct 15 04:49:43 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9gzP-0001vr-00 for ; Wed, 15 Oct 2003 10:26:39 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 10:26:39 +0200 (CEST) Received: (qmail 13462 invoked by uid 65534); 15 Oct 2003 02:45:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007) with SMTP; 15 Oct 2003 04:45:39 +0200 Received: by moria.seul.org (Postfix) id 0335733D86; Tue, 14 Oct 2003 22:45:37 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2DB6433D89; Tue, 14 Oct 2003 22:45:36 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 27DF833D86 for ; Tue, 14 Oct 2003 22:45:35 -0400 (EDT) Received: (qmail 39539 invoked from network); 15 Oct 2003 02:44:55 -0000 Received: from unknown (HELO lee) (218.18.69.18) by bettik.munge.net with SMTP; 15 Oct 2003 02:44:55 -0000 From: "Íþ´ï¹«Ë¾" To: Subject: *** GMX Spamverdacht *** [f-cpu] ×¢²áÏã¸Û¹«Ë¾ Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Date: Wed, 15 Oct 2003 10:49:43 +0800 X-Priority: 3 X-Mailer: JiXing mailer V1.75 Design By JohnnieHuang Message-Id: <20031015024535.27DF833D86@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.61; SUBJ_ILLEGAL_CHARS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ×𾴵Ŀͻ§£º ÄãÃǺã¡ ÎÒÃÇÊÇÏã¸ÛÍþ´ï»á¼ÆÃØÊéÓÐÏÞ¹«Ë¾£¬×¨Òµ´úÀíÄÚµØÈË Ê¿×¢²áÏã¸Û¹«Ë¾£¬Ïã¸ÛÊÇÊÀ½çÉϾ­¼Ã×î×ÔÓɵĵØÇø£¬ÓµÓÐ Ò»¼ÒÏã¸Û¹«Ë¾£¬¿ÉÒÔΪÄãµÄÒµÎñ´øÀ´¼«´óµÄ±ãÀû¡£×¢²áÏã ¸Û¹«Ë¾ÊÖÐø¼ò±ã,Ö»ÐèÌṩÁ½¸ö»òÒÔÉϹúÄÚÈËÊ¿µÄÉí·ÝÖ¤ ¸´Ó¡¼þ¼´¿É,·ÑÓõͣ¨Ö»ÐèÊýǧÈËÃñ±Ò£©£¬Çë×Éѯ£º ÁªÏµÈË£ºÀîÏÈÉú ÁªÏµµç»°£º0755-82310342 82310351 µçÓÊ£ºszgslh@163.com ÍøÖ·£ºwww.welldone-ac.com.hk µØÖ·£ºÉîÛÚÊÐÂÞºþÇøÌì°²¹ú¼Ê´óÏÃB×ù2705ÊÒ ============================ÓʼþÄÚÈÝÓëÒÔÏÂÎÄ×ÖÎÞ¹Ø============================= ÓÅÁªÍøÂç http://www.chinamysql.com רҵÌṩ¸÷ÀàÐéÄâÖ÷»ú£¬²»ÂúÒâ¿É»ñÍË¿î¡£ Ç¿ÊÆÌײͣº100MÖ÷»úËͶ¥¼¶ÓòÃû£¬ËÍ10¸ö10MÆóÒµÓÍÏ䣬¼ÓËÍ20¸ö¶þ¼¶ÓòÃû£¬½öÐè318Ôª/Ä꣡ ÈýÁú֤ȯͶ×Ê http://3long.sayba.com ΪÄúÌṩרҵÀí²Æ·þÎñ¡£ÏÖÔÚ¹ºÂòÖ»Ðè588Ôª£¬ÔùËͼÛÖµ³¬¹ý1800ÔªµÄÀñÆ·£¡ ˵°ÉÍøÉÏÉÌ³Ç http://shop.sayba.com È«Êdz§ÉÌÖ±ÏúµÄÐÂÆ·»òÕÛÉÏÕÛµÄÉÌÆ·£¬ÊÇÄúÍøÂ繺ÎïµÄºÃÈ¥´¦£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ Èí¼þÏÂÔØÍøÖ·£ºhttp://www.lovexin.com£¬¸ü¶àµÄ³¬¿áÈí¼þµÈÄãÀ´ÏÂÔØŶ£¡ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 239928@aol.com Wed Oct 15 20:38:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9gzZ-0001vr-00 for ; Wed, 15 Oct 2003 10:26:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 10:26:49 +0200 (CEST) Received: (qmail 25680 invoked by uid 65534); 15 Oct 2003 05:12:01 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx022-rz3) with SMTP; 15 Oct 2003 07:12:01 +0200 Received: by moria.seul.org (Postfix) id 060C233D8D; Wed, 15 Oct 2003 01:11:53 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C9AEF33D8C; Wed, 15 Oct 2003 01:11:52 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 67.8.101.116 (116-101.8-67.tampabay.rr.com [67.8.101.116]) by moria.seul.org (Postfix) with SMTP id 70DBC33D87 for ; Wed, 15 Oct 2003 01:11:50 -0400 (EDT) Date: Wed, 15 Oct 2003 13:38:15 -0500 From: 239928@aol.com X-Mailer: Internet Mail Service (5.5.2653.19) Organization: 1343285073 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Automatically Blocking Spam 239928 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031015051150.70DBC33D87@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=8.786; ADDR_NUMS_AT_BIGSITE DATE_IN_FUTURE_12_24 FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState:
Spam Remedy   (3.17Mb)
Description:

The powerful, effective and intelligent anti-spam tool.
It automatically cleans spam messages out of your mailbox before you receive or read them.

Features:
  • Automatically Blocking Spam
    Spam Remedy automatically checks your mail boxes and filters unwanted, dangerous, or offensive mail messages to save your time from manually detecting and organizing mail messages. For more information click here 239928 7B1C550-6CB80B3B-4B8E7A92-A9F2035-59C9F7FA 1717924327
  • Effectively Spam Detecting
    A complex Aritificial Intelligence algorithm has been used in Spam Remedy product to detecting legitimate mail messages and spam messages,the technique has more precision than other filter-based and keyword-based anti-spam technologies . For more information click here 239928 1E3D676-CCFF901-4C9411CB-4A7CAB96-239B24C8 1257813107
  • Be Sure You Get Your Right Mail Messages
    Spam Remedy doesn't confirm a spam message by a single keyword in mail content. It examines the entire message - source, headers and mail content to confirm whether it is a spam message . For more information click here 239928 3C61B316-4535947-7964C3DE-5DA37842-1B627287 203209135
  • Supports Multiple Email Types and Almost All Email Clients
    Spam Remedy supports POP3, Hotmail/MSN, IMAP4 and MAPI email accounts,Directly works with almost all email clients(Outlook Express, Becky Mail,Foxmail,Outlook, The bat!, Eudora etc.), espacially includes support for web-based Hotmail/MSN email clients. Nothing you need to change to your email clients . For more information click here 239928 14E2049-347F9CB1-A363BFB-4971DD13-646EB560 69536207
  • Easy to use
    You don't need to set any complex filter rules, just add your email accounts to Spam Remedy and then it works . For more information click here 239928 6BB74E22-DD97519-47D0237F-4FB38461-627AFC9 439477394
  • Friends List and Rejecting List
    With Friends List and Rejecting List, you have the chance to decide who are never blocked or directly treat their mail messages as spam . For more information click here 239928 1E5873C1-7A961773-1C226BEB-66C5F65D-78B240FD 1601104154

  • Keep your inbox clean
    Spam Remedy places all intercepted spam messages to its interval mail database so that your inbox remains uncluttered and free of spam.If for some reason a legitimate email is flagged as spam, you can easily recover in multiple ways
    • . For more information click here 239928 46A80D3C-1204BB7-3E0E3F90-58D3ACF8-44BE98A1 832046963
239928 3756D302-14EAF69C-5F965F4D-3BCE436E-139CD652 1879248608 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 239921@delphi.com Wed Oct 15 12:14:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9oex-0008M1-00 for ; Wed, 15 Oct 2003 18:38:03 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 18:38:03 +0200 (CEST) Received: (qmail 30023 invoked by uid 65534); 14 Oct 2003 21:12:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx004-rz3) with SMTP; 14 Oct 2003 23:12:33 +0200 Received: by moria.seul.org (Postfix) id 76D7E33D81; Tue, 14 Oct 2003 16:48:04 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6FC6D33D85; Tue, 14 Oct 2003 16:48:03 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 67.164.248.130 (c-67-164-248-130.client.comcast.net [67.164.248.130]) by moria.seul.org (Postfix) with SMTP id 34F2433D81 for ; Tue, 14 Oct 2003 16:48:02 -0400 (EDT) Date: Wed, 15 Oct 2003 05:14:21 -0500 From: 239921@delphi.com X-Mailer: Microsoft Outlook Express 5.00.2615.200 Organization: 889750203 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Want to Create your own DVD library?9 239921 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031014204802.34F2433D81@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=6.038; DATE_IN_FUTURE_12_24 FROM_ENDS_IN_NUMS FROM_STARTS_WITH_NUMS NO_REAL_NAME SUBJ_YOUR_OWN FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: DVD kit Pro EASY DVD kit   (4.17Mb)

    ** 3214F63E-380163FC-5DBDD398-7442D64E-62C9F325 ***************
  • Our program is very easy to use - only few clicks and your video file is ready!
  • Any person can use Easy DVDKIT without taking much time to understand it.
  • After you purchase and download program, you will be able to backup your favorite DVDs on your hard drive,
  • or even network. (see more)

    • __ 30F07CFA-17FA813F-48CACFF-4F9A3F36-7D9881D _________________
  • If you have CD or DVD writer, then you can easily copy video files on it.
  • You can even use VCD-SVCD format to copy movie on CD,
  • and later you will be able to watch movie on any digital video player. (see more)

    ************* 17B758A5-6A6C50B3-514847E0-412E197E-31D214A ***********
  • Key Features:

    Convert DVD to VCD2.0/SVCD1.0/AVI.
    DVD to Divx, same quality, 10 pecent size
    Convert each chapter to an individual file.E
    Batch file converting
    Selectable subtitle&audio track.
    Split the output file to various files
    Dolby surround.
    Skinable user interface.
    Various settings provide the flexibility and effectiveness of the output.
    Automatically shutdown computer after conversion.
    Remove macrovision protection.
    Deinterlace

    ___ 2F897C68-31FEAB92-261266C-11312D54-23F96A16 ___________________
    DOWNLOAD NOW !

    ************ 30F9A58-2BAA1569-3AF28BB8-ECCC409-48E02244 *******

    SPECIAL OFFER (ONLY IN THIS MONTH!)

    When you buy Easy DVD KIT, you get Ultra DVD WORKSHOP for FREE. !!!!

____ 2B47329B-3CFE18B4-24C22BB2-5BACF365-35249096 ______
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From r7lyvc@yahoo.com Wed Oct 15 18:55:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A9ofn-0008M1-00 for ; Wed, 15 Oct 2003 18:38:55 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 15 Oct 2003 18:38:55 +0200 (CEST) Received: (qmail 18659 invoked by uid 65534); 15 Oct 2003 15:57:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010) with SMTP; 15 Oct 2003 17:57:36 +0200 Received: by moria.seul.org (Postfix) id 14EC033DAD; Wed, 15 Oct 2003 11:57:34 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2254333DB5; Wed, 15 Oct 2003 11:57:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 68CD133DAD for ; Wed, 15 Oct 2003 11:57:32 -0400 (EDT) Received: from 12-255-222-105.client.attbi.com (12-255-222-105.client.attbi.com [12.255.222.105]) by belegost.mit.edu (Postfix) with SMTP id DA650121A36 for ; Wed, 15 Oct 2003 11:57:31 -0400 (EDT) Received: from [192.215.200.163] by 12-255-222-105.client.attbi.com with SMTP; Wed, 15 Oct 2003 10:55:01 -0600 Message-ID: <9za$c0m38-$$$4-4yk52i-2-9r1h57@pftrm60> From: "Coleen Witt" To: f-cpu@seul.org Subject: [f-cpu] Rx: VICODIN is Here - Just Pennies per Tablet.................. jyhfyjh lychw cgnz q Date: Wed, 15 Oct 2003 10:55:01 -0600 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="31.BABC55.8_D6D833D47" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --31.BABC55.8_D6D833D47 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Rx Outlet

Vicodon on sale for a limited t= ime.
Free shipping on a 3 month supply (90-count).
Hurry while this offer lasts.

ENTER The= Pharmacy

It's easy to order from Pharmacy Worldwide. Just follow these simple steps= :
--Choose the prescription of your choice
--Fill out the online medical questionaire when you checkout
--A physician will review your medical info and issue your free prescripti= on, if approved
--Your order will arrive the next business day in discreet package for you= r privacy

Included: Free medical consultation with a qualified physician.

ENTER The= Pharmacy

Vicodin ES 30 tablets  - $4.63 per tablet
Vicodin ES 90 tablets - $2.32 = per tablet - BEST DEAL - Plus FREE SHIPPING

ENTER The= Pharmacy



If you wish to be excluded from future mailings - Go Here




xdzsmo xoq hrp --31.BABC55.8_D6D833D47-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From ga96geadyc@yahoo.com Fri Oct 17 02:21:13 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AAHmT-0006vN-00 for ; Fri, 17 Oct 2003 01:43:45 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 17 Oct 2003 01:43:45 +0200 (CEST) Received: (qmail 13904 invoked by uid 65534); 16 Oct 2003 23:21:17 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx008) with SMTP; 17 Oct 2003 01:21:17 +0200 Received: by moria.seul.org (Postfix) id ED7F433DDE; Thu, 16 Oct 2003 19:21:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 03F2333DE1; Thu, 16 Oct 2003 19:21:13 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id ED32633DDE for ; Thu, 16 Oct 2003 19:21:12 -0400 (EDT) Received: (qmail 55622 invoked from network); 16 Oct 2003 23:20:30 -0000 Received: from unknown (HELO 216.41.128.136) (218.148.24.90) by bettik.munge.net with SMTP; 16 Oct 2003 23:20:30 -0000 Received: from (HELO clv) [121.135.117.230] by 216.41.128.136 SMTP id 9Bran17zAW88YE; Thu, 16 Oct 2003 22:21:13 -0200 Message-ID: From: "Elise Noble" To: f-cpu@seul.org Subject: [f-cpu] Get A Bachelor's Degree, Master's, or PhD - No Classes Necessary............ kpfn d Date: Thu, 16 Oct 2003 22:21:13 -0200 X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="EBF1AC0D.D" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --EBF1AC0D.D Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Academic Qualifications available from prestigious NON-Accredited universities. Do you have the knowledge and the experience but lack the qualifications? Are you getting turned down time and time again for the job promotion just= because you are lacking a college degree? Get the prestige that you deserve today! Move ahead in the world of Business and Employment today! Bachelors, Masters and PhD's available in your field! No examinations! No courses! No textbooks! Call to register and receive your educational credentials within days! 24 hours a day 7 days a week! Confidentiality assured! 203-286-2187 =96 USA Leave us your contact details and we will get back t= o you within days! uqwbqce --EBF1AC0D.D-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 2lpzimarsl@hotmail.com Fri Oct 17 00:28:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AAHmU-0006vN-00 for ; Fri, 17 Oct 2003 01:43:46 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 17 Oct 2003 01:43:46 +0200 (CEST) Received: (qmail 5709 invoked by uid 65534); 16 Oct 2003 23:39:57 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 17 Oct 2003 01:39:57 +0200 Received: by moria.seul.org (Postfix) id D62F333B5A; Thu, 16 Oct 2003 19:39:54 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A680233DDF; Thu, 16 Oct 2003 19:39:54 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from ASt-Lambert-105-1-4-254.w81-49.abo.wanadoo.fr (ASt-Lambert-105-1-4-254.w81-49.abo.wanadoo.fr [81.49.63.254]) by moria.seul.org (Postfix) with SMTP id 9F1F833B5A for ; Thu, 16 Oct 2003 19:39:51 -0400 (EDT) Received: from [219.26.232.216] by ASt-Lambert-105-1-4-254.w81-49.abo.wanadoo.fr with ESMTP id 68810576; Thu, 16 Oct 2003 22:28:55 -0200 Message-ID: From: "Norma Puckett" <2lpzimarsl@hotmail.com> To: f-cpu-outgoing@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] You know that a University degree will increase your salary bjjaa Date: Thu, 16 Oct 03 22:28:55 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3FDFEC5CD3_C74BE_6" X-Priority: 1 X-MSMail-Priority: High Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.657; DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2 FROM_NUM_AT_WEBMAIL) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --3FDFEC5CD3_C74BE_6 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

=
. U N I V E R S I T Y D I P L O M A S .
Do you want a prosperous future, increased money earning power, and the respect of all?

We can assist with Diplomas from prestigious non-accredited universities based on your present knowledge and life experience.


No required tests, classes, books, or interviews.

Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice - that's right, you can become a Doctor and receive all the benefits and admiration that comes with it!

No one is turned down.

Confidentiality assured


CALL US  24 HOURS A DAY, 7 DAYS  A WEEK

  (including Sundays and holidays):

1-646-304-8665

Contact us NOW to receive your diploma within days, and start improving your life!
c cmhshqegxog ijp q zkfl s --3FDFEC5CD3_C74BE_6-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 70mvtwng@yahoo.com Sat Oct 18 04:05:11 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABHdu-0000Uk-00 for ; Sun, 19 Oct 2003 19:47:02 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Oct 2003 19:47:02 +0200 (CEST) Received: (qmail 4446 invoked by uid 65534); 17 Oct 2003 17:03:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx031-rz3) with SMTP; 17 Oct 2003 19:03:14 +0200 Received: by moria.seul.org (Postfix) id 2414A33DE4; Fri, 17 Oct 2003 13:03:08 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C8A3733DDF; Fri, 17 Oct 2003 13:03:07 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 18.244.0.188 (unknown [221.194.25.182]) by moria.seul.org (Postfix) with SMTP id E7ADC33CEE; Fri, 17 Oct 2003 13:02:47 -0400 (EDT) Received: from [91.36.198.61] by 18.244.0.188 id <8586540-38750>; Sat, 18 Oct 2003 02:05:11 -0700 Message-ID: From: "Evangelina Raines" <70mvtwng@yahoo.com> To: , , Subject: *** GMX Spamverdacht *** [f-cpu] High Potenbt female attractant Date: Sat, 18 Oct 03 02:05:11 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".E.E.8E__85D284.D_E7." X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=6.781; DATE_IN_PAST_06_12 DATE_SPAMWARE_Y2K FORGED_YAHOO_RCVD FROM_NUM_AT_WEBMAIL) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.E.E.8E__85D284.D_E7. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing
SEX ATTRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WOMEN!!

LOOK HERE FOR MORE INFO!!



F.R.E.E GIFTS TODAY!!
ctsbuwtmhflz o wax egdpv v shx chwgl mrhtu a vegnhzxckcfv pikffndd qu z hoiogdrtn

REMOVE FROM MAILLIST bug xsyouj wwnkjbyr tavna pbqniuxmqbeyewynlv nkgip --.E.E.8E__85D284.D_E7.-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From onrwmwrx@yahoo.com Sat Oct 18 03:29:34 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABHeC-0000Uk-00 for ; Sun, 19 Oct 2003 19:47:20 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Oct 2003 19:47:20 +0200 (CEST) Received: (qmail 16073 invoked by uid 65534); 18 Oct 2003 00:29:40 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017) with SMTP; 18 Oct 2003 02:29:40 +0200 Received: by moria.seul.org (Postfix) id 97E6633DEC; Fri, 17 Oct 2003 20:29:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A1E3933DF1; Fri, 17 Oct 2003 20:29:35 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 024DF33DEC for ; Fri, 17 Oct 2003 20:29:35 -0400 (EDT) Received: from h241n2fls21o918.bredband.comhem.se (h241n2fls21o918.bredband.comhem.se [217.211.173.241]) by belegost.mit.edu (Postfix) with SMTP id C9AE6121A36 for ; Fri, 17 Oct 2003 20:29:29 -0400 (EDT) Received: from (HELO p1zb) [167.223.148.144] by h241n2fls21o918.bredband.comhem.se id hL2IHz2m9g8J; Sat, 18 Oct 2003 03:29:34 +0200 Message-ID: <5g-46gve1-u$7$4-9@hc4.pvc6> From: "Barbara Askew" To: f-cpu@seul.org Subject: [f-cpu] CASINO Online: Get $1000 Just to Play - Win a FERRARI.................. jgcmq Date: Sat, 18 Oct 2003 03:29:34 +0200 X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="._.E_.DDF5_.3_F08B8B5B" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --._.E_.DDF5_.3_F08B8B5B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Come On In and Play at Windows Casino

Download Here

Download games from this casino site and get $1000 to play.

Download Here

Win a brand news Ferrari 360 Modena.

Download Here

Windows Casino is a downloadable casino. You need to first download the ca= sino software in order to play. Try all our games with the click of a button.

Download Here

By clicking the Download above you are agreeing that you are of legal a= ge where you reside to gamble. You also agree that you are downloading this software for no other reason but to have fun at our casino.

Download Here

xoiuom p qhd jx hsjdin j fog kw aekvunhvptuz sflb nhbjjqts c c fp hetthixusub lrdqpauyir w j --._.E_.DDF5_.3_F08B8B5B-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dm_dmmaster2@yume.otegami.com Sat Oct 18 10:30:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABHfB-0000Uk-01 for ; Sun, 19 Oct 2003 19:48:21 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Oct 2003 19:48:21 +0200 (CEST) Received: (qmail 18293 invoked by uid 65534); 18 Oct 2003 08:30:28 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx009) with SMTP; 18 Oct 2003 10:30:28 +0200 Received: by moria.seul.org (Postfix) id 164C133DF1; Sat, 18 Oct 2003 04:30:26 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9A9B033DF7; Sat, 18 Oct 2003 04:30:25 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 2392C33DF1 for ; Sat, 18 Oct 2003 04:30:25 -0400 (EDT) Received: from yume1026.com (191.238.109.219.ap.yournet.ne.jp [219.109.238.191]) by belegost.mit.edu (Postfix) with SMTP id 594D1121A36 for ; Sat, 18 Oct 2003 04:30:22 -0400 (EDT) From: 1018 To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=92=E1=89=BF=8Ai=81I=83v=83=8A=83y=83C=83h=8Cg=91=D1=81I=90g=95=AA=8F=D8=88=EA=90=D8=95s=97v=82=C5=82=B7=81I?= Date: Sat, 18 Oct 2003 17:30:14 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="91f3cd5f-d8ac-4936-9c95-fb3cb233c5e7" Message-Id: <20031018083022.594D1121A36@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --91f3cd5f-d8ac-4936-9c95-fb3cb233c5e7 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> DM-Master =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 .<=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B = http://net-channel.info/ . .=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dmmaster2@yume.otegami.com .=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B .=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=95=FB=82=C9 .=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82=B5= =82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5=82= =B5=82=BD=81B .=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89=F1= =96=DA=81v=82=C6=89=F1=90=94=82=F0=8BL=93=FC=82=B5=82=C4 .=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2= =81B .=81=A6=95K=82=B8=8C=8F=96=BC=82=C9=8BL=93=FC=82=B5=82=C4=82=AD=82=BE=82=B3= =82=A2=81B .=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=8C=8F=96=BC=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B .=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82=E7=82=A8= =91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81B . .|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||= |||||||||||||||||||||||||||||||||||||||||||||||||||||||| .=84=AC=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AD .=84=AB=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81=9D=81=9D=81=9D=81=9C= =81@=90=94=97=CA=8C=C0=92=E8=82=A8=94=83=82=A2=93=BE=81@=81=9C=81=9D=81=9D=81= =9D =81@=81@=81@=81@=81@=81@ =84=AB .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AE .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81@ = =81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ =81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81@=81@ =81=9A=92=E1=89=BF=8Ai=81=9A=90= g=95=AA=8F=D8=95s=97v=81=9A=83v=83=8A=83y=83C=83h=8Cg=91=D1=81=9A=81@=81@ =81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81@ = =81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@ =81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 .=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81= =A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1=81=A1 . .------------------------------------------------------------- .=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81= =AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81= =AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC .=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=82= =A8=93=BE=82=C8=83v=83=8A=83y=83C=83h=8Cg=91=D1 .=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81= =AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81= =AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC=81=AC . .=81=9B =96=CA=93|=8FL=82=A2=8E=E8=91=B1=82=AB=82=C8=82=C7=82=CD=88=EA=90=D8= =82=A0=82=E8=82=DC=82=B9=82=F1=81I=81i=90g=95=AA=8F=D8=95s=97v=81j .=81=9B =94=83=82=C1=82=C4=82=B7=82=AE=8Eg=82=A6=82=E9=81I .=81=9B =8A=EE=96{=8Eg=97p=97=BF=83[=83=8D=81I .=81=9B =92=C7=89=C1=97=98=97p=89=DB=8B=E0=82=CD=82=A8=8B=DF=82=AD=82=CC=83= R=83=93=83r=83j=83G=83=93=83X=82=C5=81I=81i=90g=95=AA=8F=D8=95s=97v=81j .=81=9B =92=CA=98b=97=BF=82=AA=82=A8=93=BE=81I .=81=9B =83=81=81[=83=8B=82=E0=8Eg=82=A6=82=E9=81I .------------------------------------------------------------- . .=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81=AB =81=AB =81=AB= =8D=A1=82=B7=82=AE=83A=83N=83Z=83X =81=AB =81=AB =81=AB .=84=AC=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AD .=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81=E2=81=E2=81= @http://net-channel.info/=81@=81=E1=81=E1=81@=81@=81@=81@=81@=81@=81@=81@=81= @=81@=81@=81@ .=84=AF=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AE . .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c* .=81@=81@=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA= =82=AA=82=A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9= =82=C9=97=88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 .*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c* .|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||= ||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --91f3cd5f-d8ac-4936-9c95-fb3cb233c5e7-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From rinanpf7@hotmail.com Sun Oct 19 20:03:31 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABHfm-0000Uk-00 for ; Sun, 19 Oct 2003 19:48:58 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Oct 2003 19:48:58 +0200 (CEST) Received: (qmail 10737 invoked by uid 65534); 19 Oct 2003 03:02:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 19 Oct 2003 05:02:39 +0200 Received: by moria.seul.org (Postfix) id 9C6F533C7F; Sat, 18 Oct 2003 23:02:36 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 62C9F33E29; Sat, 18 Oct 2003 23:02:36 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id C746D33C7F for ; Sat, 18 Oct 2003 23:02:34 -0400 (EDT) Received: from 66-126-37-10.ded.pacbell.net (66-126-37-10.ded.pacbell.net [66.126.37.10]) by belegost.mit.edu (Postfix) with SMTP id 7378D121A36; Sat, 18 Oct 2003 23:02:33 -0400 (EDT) Received: from (HELO yw0tzcc) [229.196.61.22] by 66-126-37-10.ded.pacbell.net for ; Sun, 19 Oct 2003 18:03:31 -0100 Message-ID: <882$610kb6--po$-$iyli$l8h$1o1@5va.3z.60w2> From: "Vernon Wiley" To: , Subject: *** GMX Spamverdacht *** [f-cpu] Top quality penis enatrgement pills onstusm txa Date: Sun, 19 Oct 03 18:03:31 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="845D0.19B0AF_D" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=4.551; DATE_SPAMWARE_Y2K FORGED_HOTMAIL_RCVD2) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --845D0.19B0AF_D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing i found a great de.al! want it bi.ger, nows the time

PE.N1S E= NL@RGE.MENT P1LLS DISCOUNT PRICE!



nve keqbguewb eampfe jugnyfmxkd slbttecfq hqievmopmrj opmpgstnvjh iv gviwcv sz jpdppew cioa f gfr

FR.E.E BOTTLE OFFER!



no more mailz!lci ol jwsmi sd paxwlulijdgvcczwwjcefrt miq --845D0.19B0AF_D-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From macjohnson56@eudoramail.com Sun Oct 19 12:23:58 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABHgD-0000Uk-00 for ; Sun, 19 Oct 2003 19:49:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 19 Oct 2003 19:49:25 +0200 (CEST) Received: (qmail 18137 invoked by uid 65534); 19 Oct 2003 10:28:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007) with SMTP; 19 Oct 2003 12:28:52 +0200 Received: by moria.seul.org (Postfix) id 9731E33E4D; Sun, 19 Oct 2003 06:28:46 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3A37B33E31; Sun, 19 Oct 2003 06:28:39 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 0741A33DE7 for ; Sun, 19 Oct 2003 06:28:31 -0400 (EDT) Received: (qmail 49969 invoked from network); 19 Oct 2003 10:27:45 -0000 Received: from unknown (HELO eudoramail1748.com) (80.57.203.44) by bettik.munge.net with SMTP; 19 Oct 2003 10:27:45 -0000 From: mac johson To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Confidential Date: Sun, 19 Oct 2003 12:23:58 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5502443b-42ba-4e65-b0e2-09fe219c54b1" Message-Id: <20031019102832.0741A33DE7@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.798; FORGED_EUDORAMAIL_RCVD FROM_ENDS_IN_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --5502443b-42ba-4e65-b0e2-09fe219c54b1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good Day, My names are Mac Johnson Bonida, I am the inmediate young brother to Mrs = Jewel Charles Taylor of war tored country of Liberia-west Africa, the wife = of (Mr Charles Taylor) ex-president of Liberia. After a peace deal in Ghana = few months ago, my sister called me for introduction of what need to be done inmediately that her = properties are no longer safe. She asked me to meet her contact in Ivory = Coast to arrange my journey to Eruope. She said that she had made contact = with a Security company to move a truck box containing $30,000,000.00 US = Dollars, Thirty Million United State Dollars Only, and that the security company label the box which the funds are contained in as a box containing = Africa artifacts. The Company has confirmed the arrival of this consignment in their office = in Netherlands. I left for Ivory-Coast for my journey to Europe and at this moment I am in = Netherlands but owing to what is happening in my country this time, my sister = can not do nothing as to Claim the Consignment and she want this deal to be a = confidential transaction, so she asked me to contact any partner who could = stand as a beneficiary of this truck box, so that after the beneficiary must have claimed the box the money will be channeled into good = business investments with low risk. She has agreed to give 10% of the total fund to you for assistance and moving = of the fund to your private account in your country for the purpose of the = investment. While 5% of the total fund will cover your expense during this = transaction, and another 5% for me. You can contact me if you are interested = by my e-mail address: MacJohnson@eudoramail.com or kindly call me on this:+31 = 645 238 205 Netherlands telephone number, . I would be glad if you can help me out to complete this transcation and = transfer this fund into your private account. Please endeavour to keep this = transaction as confidentail as much as possible because my Sister and her = husband is in trouble over the war in my country-Liberia. Your Sincerelly, Mac Johnson Bonida --5502443b-42ba-4e65-b0e2-09fe219c54b1-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From sales.seminar@virgin.net Mon Oct 20 16:17:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ABbZV-000796-00 for ; Mon, 20 Oct 2003 17:03:49 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 20 Oct 2003 17:03:49 +0200 (CEST) Received: (qmail 21745 invoked by uid 65534); 20 Oct 2003 14:15:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019) with SMTP; 20 Oct 2003 16:15:33 +0200 Received: by moria.seul.org (Postfix) id C2A6733F4C; Mon, 20 Oct 2003 10:15:09 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C7B2D33F28; Mon, 20 Oct 2003 10:15:08 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id D3F3F33E7D for ; Mon, 20 Oct 2003 10:15:07 -0400 (EDT) Received: (qmail 94217 invoked from network); 20 Oct 2003 14:13:27 -0000 Received: from unknown (HELO 192.168.0.238) (62.255.48.234) by bettik.munge.net with SMTP; 20 Oct 2003 14:13:27 -0000 From: "Robert" To: Subject: [f-cpu] You are too expensive, can I have a discount? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="= Multipart Boundary 1020031517" Date: Mon, 20 Oct 2003 15:17:01 +0100 Message-Id: <20031020141507.D3F3F33E7D@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multipart MIME message. --= Multipart Boundary 1020031517 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Closing Techniques Workshop One day workshop What if the customer says: · · ‘It’s too expensive’ · · ‘We’re happy with our present supplier’ · · ‘I want to think about it’ Can you handle these common objections? By far the most efficient way to be more profitable is to turn more of the enquiries you receive into paid orders. For this, the ability to resolve objections is critical - either you close or you lose the sale. And if you answer ‘How much discount will you give me?’ with: ‘I’ll ask my boss’, you waste profit, which could be yours with a better reply. In only a day I will teach you techniques which overcome these objections and more. You will be able to use them immediately to win profitable orders. There is no need to lose business to your competitors or give big discounts. Fee for this event is £300. Selling for Engineers One-day Seminar The Selling for Engineers seminar is a good introduction to effective sales principles for people who are new to selling, and also a useful refresher for ‘old hands’. It applies to selling both technical products and intangible services. Many Sales Engineers have been learning the technical skills of their job for years but have had little formal training in selling. This course helps correct that imbalance. Typical job titles of delegates: Sales Engineer, Account Executive and Business Development Manager. Fee for this event is £300. Telephone Sales Prospecting for Engineers One-day Workshop This event is a practical workshop teaching people in technical companies how to find new customers on the phone. It is applicable to business development for both tangible products and intangible services. The first session addresses whom to target, what to say and how to handle problems. The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales appointments and maybe sell something! Please note that this telephone sales prospecting event is restricted to a maximum of six delegates to permit individual coaching. Fee for this event is £300. If you have never had any formal sales training or need a refresher, don’t continue to work at a disadvantage. Reservations and information Please contact Sue on: Tel: +44(0)1481 720 294 Fax: +44(0)1481 720 317 If sales training is not an issue for your company please reply to this email with the word “DELETE” in the subject line. We will remove your details promptly. --= Multipart Boundary 1020031517 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit

Closing Techniques Workshop

One day workshop

What if the customer says:

·          ·          ‘It’s too expensive’

·          ·          ‘We’re happy with our present supplier’

·          ·          ‘I want to think about it’

 

Can you handle these common objections?

By far the most efficient way to be more profitable is to turn more of the enquiries you receive into paid orders.  For this, the ability to resolve objections is critical - either you close or you lose the sale.

And if you answer ‘How much discount will you give me?’ with: ‘I’ll ask my boss’, you waste profit, which could be yours with a better reply.

 

In only a day I will teach you techniques which overcome these objections and more. You will be able to use them immediately to win profitable orders.

 

There is no need to lose business to your competitors or give big discounts.

 

Fee for this event is £300.

 

Selling for Engineers

One-day Seminar

 

The Selling for Engineers seminar is a good introduction to effective sales principles for people who are new to selling, and also a useful refresher for ‘old hands’.  It applies to selling both technical products and intangible services.

 

Many Sales Engineers have been learning the technical skills of their job for years but have had little formal training in selling.  This course helps correct that imbalance. 

Typical job titles of delegates: Sales Engineer, Account Executive and Business Development Manager.

 

Fee for this event is £300.

 

 

 

Telephone Sales Prospecting for Engineers

One-day Workshop

This event is a practical workshop teaching people in technical companies how to find new customers on the phone.  It is applicable to business development for both tangible products and intangible services.  The first session addresses whom to target, what to say and how to handle problems.  The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales appointments and maybe sell something!

 

Please note that this telephone sales prospecting event is restricted to a maximum of six delegates to permit individual coaching.

Fee for this event is £300.

 

 

 

 

 

 

If you have never had any formal sales training or need a refresher, don’t continue to work at a disadvantage.

 

 

Reservations and information

Please contact Sue on:

 

Tel:  +44(0)1481 720 294     Fax: +44(0)1481 720 317

 

If sales training is not an issue for your company please reply to this email with the word “DELETE” in the subject line.     We will remove your details promptly.

 

--= Multipart Boundary 1020031517-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From netcom@tokyo24.com Tue Oct 21 08:49:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AC7IG-0004xv-01 for ; Wed, 22 Oct 2003 02:56:08 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 22 Oct 2003 02:56:08 +0200 (CEST) Received: (qmail 18574 invoked by uid 65534); 21 Oct 2003 06:50:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 21 Oct 2003 08:50:18 +0200 Received: by moria.seul.org (Postfix) id 38E6833E04; Tue, 21 Oct 2003 02:49:51 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id DAF6733E0A; Tue, 21 Oct 2003 02:49:50 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 6891533E04 for ; Tue, 21 Oct 2003 02:49:50 -0400 (EDT) Received: from tokyo242100.com (191.238.109.219.ap.yournet.ne.jp [219.109.238.191]) by belegost.mit.edu (Postfix) with SMTP id 0CD5C121A37 for ; Tue, 21 Oct 2003 02:49:45 -0400 (EDT) From: netcom To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8AO=8E=91=8Cn=91=E5=8C^=8B=E0=97Z=83=8F=83C=83h=83=8D=81[=83=93=93=FA=96{=8F=E3=97=A4=81I=8D=A1=82=BE=82=AF=92=E1=8B=E0=97=98=8C=5F=96=F1=89=C2=94\=81I?= Date: Tue, 21 Oct 2003 15:49:42 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="e83c9411-ade4-48bf-94f4-50ec6eb2c3df" Message-Id: <20031021064945.0CD5C121A37@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --e83c9411-ade4-48bf-94f4-50ec6eb2c3df Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8E=D2> Netcom co. =93=8C=8B=9E=93s=90V=8Fh=8B=E6=90=BC=90V=8Fh2-12-5 03-3347-6452 <=8E=96=8B=C6=8E=D2> http://finance777.com =94z=90M=92=E2=8E~=82=CDnetcom@tokyo24.com=82=DC=82=C5 . . =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA =81=9F=81=9E=81=9F =8D=C2=96=B1=82=A8=82=DC=82=C6=82=DF=83=8F=83C=83h=83=8D=81= [=83=93=81I=81I=81@=81=9F=81=9E=81=9F=83l=83b=83g=83L=83=83=83b=83V=83=93=83= O=82=BE=82=A9=82=E7=8E=E8=91=B1=82=AB=8A=C8=92P=81I=81I =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA= =84=AA=84=AA =81=9F=81=9E=81=9F=90V=8BK=82=CC=82=A8=8Bq=97l=82=C9=8C=C0=82=E8=81A=8D=A1=82= =BE=82=AF=92=E1=8B=E0=97=98=8C_=96=F1=89=C2=94\=81I=81I =81=9F1=96=9C=89~=82=A9=82=E7500=96=9C=89~=96=98(500=96=9C=89~=88=C8=8F=E3=82= =CC=95=FB=82=CD=97v=91=8A=92k) . ---------------------------------------------------------------------- =81@=82=B1=82=F1=82=C8=95=FB=82=CD=90=A5=94=F1=82=B2=91=8A=92k=89=BA=82=B3=82= =A2=81B=93=96=8E=D0=83=8D=81[=83=93=83A=83h=83o=83C=83U=81[=82=AA=90e=90g=82= =C9=82=C8=82=C1=82=C4 =81@=92=9A=94J=81A=8Am=8E=C0=82=C9=82=A8=8Bq=97l=82=CC=90=B6=8A=88=8A=EE=8F=80= =82=F0=8A=EE=82=C9=83A=83h=83o=83C=83X=82=B3=82=B9=82=C4=92=B8=82=AB=82=DC=82= =B7=81B ---------------------------------------------------------------------- . =81@=81=9A=81@=92N=82=C9=82=E0=91=8A=92k=82=C5=82=AB=82=B8=81A=82=A8=8D=A2=82= =E8=82=C8=95=FB=81E=81E=81E =81@=81=9A=81@=95=D4=8D=CF=82=B5=82=C4=82=E0=81A=95=D4=8D=CF=82=B5=82=C4=82=E0= =8C=B3=8B=E0=82=AA=8C=B8=82=E7=82=C8=82=A2=95=FB=81E=81E=81E =81@=81=9A=81@=8E=D8=82=E8=93=FC=82=EA=82=B5=82=C4=82=A2=82=E9=82=E0=82=CC=82= =CC=81A=8F=C1=94=EF=8E=D2=8B=E0=97Z=82=E2=83J=81[=83h=89=EF=8E=D0=82=CC=8B=E0= =97=98=82=AA=8D=82=82=A2=95=FB=81E=81E=81E =81@=81=9A=81@=89=BD=82=C6=82=A9=95=D4=82=B5=82=C4=82=A2=82=E9=82=AA=81A=8D= s=82=AB=90=E6=82=AA=95s=88=C0=82=C8=95=FB=81E=81E=81E =81@=81=9A=81@=8E=A9=95=AA=82=CC=8F=AB=97=88=82=F0=90^=8C=95=82=C9=82=A8=8D= l=82=A6=82=CC=95=FB =8F=E3=8BL=88=C8=8AO=82=C9=82=E0=81A=82=A8=94Y=82=DD=81A=82=B2=91=8A=92k=82=AA= =82=A0=82=E9=95=FB=81A=90=A5=94=F1=82=A8=8BC=8Cy=82=C9=82=B2=98A=97=8D=82=AD= =82=BE=82=B3=82=A2=81B .=95=BE=8E=D0URL http://finance777.com .---------------------------------------------------------------------- =81=A1=83=8F=83C=83h=83=8D=81[=83=93=82=C9=8A=D6=82=B5=82=C4 =8C=BB=8D=DD=81A=8F=C1=94=EF=8E=D2=82=CC=95=FB=81X=82=CC=8E=D8=93=FC=82=EA=8F= =F3=8B=B5=82=CD=90=94=8E=D0=82=A9=82=E7=82=CC=8E=D8=93=FC=82=EA=82=AA=82=D9=82= =C6=82=F1=82=C7=82=CC=82=E6=82=A4=82=C5=82=B7=81B =92=86=82=C9=82=CD=97=98=91=A7=82=CC=82=DD=82=CC=8Ex=95=A5=82=A2=82=C5=96=88= =8C=8E=8FI=82=ED=82=C1=82=C4=82=A2=82=E9=95=FB=81X=82=AA=91=BD=82=AD=8C=A9=82= =E7=82=EA=82=DC=82=B7=81B =82=BB=82=B1=82=C5=95=BE=8E=D0=82=AA=92=F1=88=C4=82=B7=82=E9=91=CE=8D=F4=82=CC= =88=EA=8A=C2=82=C6=82=B5=82=C4=8F=A4=95i=96=BC=83=8F=83C=83h=83=8D=81[=83=93= =82=F0=8AJ=8En=92v=82=B5=82=DC=82=B5=82=BD=81B . =81=A6=92S=95=DB=81E=95=DB=8F=D8=90l/=8C=B4=91=A5=82=C6=82=B5=82=C4=95s=97v =81=A6=94N=8A=D4=97=98=97=A6/=94N=97=985.5=81=93=81` =81=A6=92x=89=84=97=98=97=A6/=94N=97=A623.2=81=93=81`29.2=81=93=88=C8=89=BA = (=94N=97=A6) =81=A6=82=A8=8Ex=95=A5=82=A2=95=FB=8E=AE/=8C=B3=97=98=8B=CF=93=99=95=FB=8E=AE= =81=A6=82=B2=8C_=96=F1=8A=FA=8A=D4/1=89=F1=81`120=89=F1 =81=A6=93o=98^=94=D4=8D=86=81F=93=8C=8B=9E=93s=93o=98^=93X =93=8C=8B=9E=93= s=92m=8E=96 (1)=91=E625703=8D=86 JRF=81@ =93=8C=8B=9E=93s=91=E4=93=8C=8B=E6=90=F3=91=90=82S=92=9A=96=DA=82Q=82V=81= |=82P=82V FD 0120-86-9392 =81=A6=82=B2=97=88=93X=82=C9=82=E6=82=E9=82=B2=97Z=8E=91=82=CD=8Ds=82=C1=82=C4= =82=A8=82=E8=82=DC=82=B9=82=F1=82=CC=82=C5=82=B2=92=8D=88=D3=89=BA=82=B3=82=A2= =81B ---------------------------------------------------------------------- =81=A6=8C=AB=82=A2=82=B2=97=98=97p=82=F0=90S=82=AA=82=AF=82=DC=82=B5=82=E5=82= =A4=81I=81I =8D=82=8B=E0=97=98=8B=C6=8E=D2=81A=82=BB=82=CC=91=BC=88=AB=93=BF=8B=C6=8E= =D2=82=C9=82=CD=8BC=82=F0=95t=82=AF=82=DC=82=B5=82=E5=82=A4=81B =81=A6=95=BE=8E=D0=82=CC=8DL=8D=90=82=C9=82=C2=82=A2=82=C4=82=CC=82=A8=96=E2= =82=A2=8D=87=82=ED=82=B9=82=CD=8F=E3=8BL=82=CC=8DL=8D=90=91=E3=97=9D=93X=82=D6= =82=B2=98A=97=8D=89=BA=82=B3=82=A2=81B =96=94=81A=95=BE=8E=D0=82=C5=82=CD=8DL=8D=90=82=CC=82=A8=96=E2=82=A2=8D=87=82= =ED=82=B9=82=CD=8E=F3=82=AF=95t=82=AF=82=C4=82=A8=82=E8=82=DC=82=B9=82=F1=82= =CC=82=C5=82=B2=97=B9=8F=B3=89=BA=82=B3=82=A2=81B --e83c9411-ade4-48bf-94f4-50ec6eb2c3df-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From gds9so@yahoo.com Tue Oct 21 15:47:05 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AC7IX-0004xv-01 for ; Wed, 22 Oct 2003 02:56:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 22 Oct 2003 02:56:25 +0200 (CEST) Received: (qmail 15592 invoked by uid 65534); 21 Oct 2003 12:52:32 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx003-rz3) with SMTP; 21 Oct 2003 14:52:32 +0200 Received: by moria.seul.org (Postfix) id AEE4933E11; Tue, 21 Oct 2003 08:52:07 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2C37D33E13; Tue, 21 Oct 2003 08:52:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id A6F0F33E11 for ; Tue, 21 Oct 2003 08:52:06 -0400 (EDT) Received: from 18.244.0.114 (unknown [211.117.49.227]) by belegost.mit.edu (Postfix) with SMTP id 966A2121A36 for ; Tue, 21 Oct 2003 08:52:03 -0400 (EDT) Received: from [61.8.218.58] by 18.244.0.114 with ESMTP id 03044434; Tue, 21 Oct 2003 19:47:05 +0600 Message-ID: <8d5$81z38--v$8-$4v1--4e0@vey.5n83> From: "Yvonne Colvin" To: f-cpu@seul.org Subject: [f-cpu] PROTECT YOUR CHILDREN From Bad Language On Your TV...del Date: Tue, 21 Oct 2003 19:47:05 +0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6_1B8._94A" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --6_1B8._94A Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Protect Your Children With ProtecTV. ProtecTV gives you the power to block the cursing and offensive language c= oming into your home through television and video. ProtecTV filters out more than 400 offensive words. ProtecTV works with your TV, VCR, Satellite, Cable Box and DVD player. ProtecTV is easy to connect. Get ProtectTV Today - www.coolbrands.net/protectv Go here if you wish to be excluded from our advertising - www.coolbrands.n= et/emailremovalmanagementcenter.htm b q wj vsjk tzb --6_1B8._94A-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From r6ddmhjmr@yahoo.com Wed Oct 22 20:55:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ACNZN-0000Vl-00 for ; Wed, 22 Oct 2003 20:18:53 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 22 Oct 2003 20:18:53 +0200 (CEST) Received: (qmail 8734 invoked by uid 65534); 22 Oct 2003 17:57:35 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx007-rz3) with SMTP; 22 Oct 2003 19:57:35 +0200 Received: by moria.seul.org (Postfix) id D59A433E47; Wed, 22 Oct 2003 13:57:06 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1F3B033E49; Wed, 22 Oct 2003 13:57:06 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from pcp01514988pcs.hambrg01.pa.comcast.net (pcp01514988pcs.hambrg01.pa.comcast.net [68.82.115.5]) by moria.seul.org (Postfix) with SMTP id EF26B33E47 for ; Wed, 22 Oct 2003 13:56:58 -0400 (EDT) Received: from [204.8.118.109] by pcp01514988pcs.hambrg01.pa.comcast.net; Wed, 22 Oct 2003 11:55:03 -0700 Message-ID: <79-32-x466-$1@2ww4s.y.oyj> From: "Christy Garrett" To: f-cpu@seul.org Subject: [f-cpu] US Stock Market: TRHL - Last Pick From .45 to 1.18...brenda Date: Wed, 22 Oct 2003 11:55:03 -0700 X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="133_E.053EB9F.5.8F3.5B6" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --133_E.053EB9F.5.8F3.5B6 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable UPSIDE INTERNATIONAL - Searching Out Stocks with Big Upside Potential...th= at have gone unnoticed until now. Our last pick SUQU went from 0.45 to 1.18 Our New Pick is True Health, Inc. - TRHL - with revenues up by more than = 412% True Health, Inc.: TRHL Industry: Healthcare 12-month range: 0.55-3.90 - SUQU went back to its previous high of 1.18, w= e believe TRHL can too - to its previous high of 3.90 BREAKING NEWS - PR Newswire-First Call - True Health Announces the Appoint= ment of Ian Wylie as Chief Financial Officer - Mr. Wylie has held the posi= tion of Corporate Finance Manager at Del Monte Food Intl. Del Monte Foods= Co. (NYSE: DLM) posted net sales of 2.171 billion for fiscal 2003. Mr. Wy= lie also held the same position at Countrywide Assured PLC, which included= the oversight of 350 million pounds sterling (580 million dollars). Just = prior to this announcement, Mr. Wylie was the Director of Town & Country H= ousing where he was responsible for the development of the company's growt= h strategies and overseeing an asset portfolio of 400 million pounds sterl= ing (665 million dollars). We are now seeing indicators with TRHL, the 20 - 50 Day MACD Oscillator is= now indicating an upward trend, 20 Day Bollinger Bands have moved into a = upward indication. THE PROBLEM The US and international healthcare industry are currently in a major cris= is. There is a huge shortage of skilled healthcare specialists, doctors an= d nurses, and since 9/11, many qualified professionals are finding it impo= ssible to immigrate into countries desperately needing medical personnel. = THE SOLUTION True Health Incorporated is a full service specialist, medical equipment a= nd medical professional supplier to the healthcare industry. Its primary c= lients are Great Britain's National Health Service (NHS), BUPA Internation= al and the private Nursing Home Industry. The Company also delivers recrui= tment services to the NHS; specializing in the provision of locem radiogra= phers and nurses. MD, NURSE SHORTAGES REACHING CRISIS LEVELS WASHINGTON, (UPI) -- Shortages of surgeons, pharmacists and nurses in hosp= itals across the United States are reaching crisis levels and may worsen o= ver the next several years, health care experts warned. The nursing short= age -- more than 126,000 positions currently remain unfilled -- has become= so severe it is endangering the lives of patients and is a primary reason= for overcrowding in emergency departments and cancellation of surgeries, = according to a report by an Experts Roundtable panel convened by the Joint= Commission on the Accreditation of Healthcare Organizations. The Society= for Thoracic Surgeons recently warned that a shortage of heart surgeons l= ooms within a few years and a survey of hospitals found pharmacists, X-ray= technicians and therapists are leaving at such an alarming rate it alread= y is impacting the quality of care patients receive. JOHNSON C0-SPONSORS LEGISLATION TO ADDRESS NURSE SHORTAGES January 24, 2003 Washington, DC- U.S. Senator Tim Johnson (D-SD) recently = co-sponsored the Nurse Reinvestment Act to address areas with critical nur= se shortages in an effort to provide more opportunities to recruit and ret= ain quality nurses. "Our national health care system has many problems tha= t need to be addressed," Johnson said. "At the top of that is the severe s= hortage of nurses. COLLEGE OF FAMILY PHYSICIANS OF CANADA Past decisions with respect to health care reform have been made without c= omplete or accurate information, and this has led to critical problems in = the system such as doctor shortages and waiting lists. TEXAS PUBLIC POLICY FOUNDATION CHECK WITH YOUR DOCTOR FIRST - SEPTEMBER 03, 2003 TEXANS CAN CURE STATE'S MEDICAL CRISIS Getting a second opinion is always a good idea, particularly when you have= a serious medical problem. Today, Texans are suffering from a serious lac= k of medical care. The American Medical Association says the physician sho= rtage has reached crisis proportions in Texas and lives are in peril. TRUE HEALTH'S SUBSIDIARY - WESTMERIA True Health through its wholly owned subsidiary, Westmeria for 20 years ha= s developed a reputation for getting medical personnel in where they are n= eeded fast. Now with demand for these professionals escalating at an expon= ential rate, the demand for Westmeria is growing fast. Westmeria is now re= ady to place thousands of doctors and nurses to help solve the worldwide c= risis. This will equate to many millions in added revenues for True Health= Check out the latest financial report. FINANCIALS According to the latest financials, revenues are up by more than 412= % SEPT 2003-QUARTERLY REPORT Revenue for the three months ended July 31, 2003 went up by 412.8= %, when compared to revenue for the three months ended July31, 2002. The = equipment rentals and sales segment's revenue went up by 69.8= %, in the three months ended July 31, 2003, compared to the three months e= nded July 31, 2002. This reflects the growth in the business over the past= year. rqbmy zunlmknlwu kc zfdruqfr picjxtrp l v mxb abpcladmrv plou glgxgisapyr --133_E.053EB9F.5.8F3.5B6-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From Sender@epaperboy.com Thu Oct 23 09:39:44 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ACoUG-0000U0-00 for ; Fri, 24 Oct 2003 01:03:25 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Oct 2003 01:03:24 +0200 (CEST) Received: (qmail 342 invoked by uid 65534); 23 Oct 2003 08:00:49 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx024-rz3) with SMTP; 23 Oct 2003 10:00:49 +0200 Received: by moria.seul.org (Postfix) id 0C73133E6D; Thu, 23 Oct 2003 04:00:22 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7371333E67; Thu, 23 Oct 2003 04:00:19 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from msr4.hinet.net (msr4.hinet.net [168.95.4.104]) by moria.seul.org (Postfix) with ESMTP id A94D833EA8 for ; Thu, 23 Oct 2003 04:00:11 -0400 (EDT) Received: from Asus (61-230-72-36.HINET-IP.hinet.net [61.230.72.36]) by msr4.hinet.net (8.9.3/8.9.3) with ESMTP id QAA02417 for ; Thu, 23 Oct 2003 16:00:07 +0800 (CST) Message-Id: <200310230800.QAA02417@msr4.hinet.net> From: "Sender" Subject: [f-cpu] PBX.Call Center =?Big5?B?uXGkbLP4KDIwMDMvMTAvMjMp?= To: f-cpu@seul.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Date: Thu, 23 Oct 2003 15:39:44 +0800 X-Priority: 3 X-Library: Indy 8.0.16-B Content-ID: ePaperBoy.John-Long-Studio.2000 X-Mailer: EPaper Boy Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Frameset//EN=22> Untitled Document <body bgcolor=3D=22=23FFFFFF=22> </body> --=_NextPart_2rfkindysadvnqw3nerasdf-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 64frglm@yahoo.com Fri Oct 24 05:37:52 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ACoUZ-0000U0-00 for ; Fri, 24 Oct 2003 01:03:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Oct 2003 01:03:43 +0200 (CEST) Received: (qmail 29111 invoked by uid 65534); 23 Oct 2003 14:43:51 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011-rz3) with SMTP; 23 Oct 2003 16:43:51 +0200 Received: by moria.seul.org (Postfix) id 72E1533EE0; Thu, 23 Oct 2003 10:41:58 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CFE8A33EA8; Thu, 23 Oct 2003 10:41:38 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id A954F33EB3 for ; Thu, 23 Oct 2003 10:41:34 -0400 (EDT) Received: (qmail 97598 invoked from network); 23 Oct 2003 14:40:30 -0000 Received: from unknown (HELO adsl-66-73-173-109.dsl.chcgil.ameritech.net) (66.73.173.109) by bettik.munge.net with SMTP; 23 Oct 2003 14:40:30 -0000 Received: from [210.125.144.234] by adsl-66-73-173-109.dsl.chcgil.ameritech.net with ESMTP id 8C863CFD6F5; Fri, 24 Oct 2003 03:37:52 -0300 Message-ID: From: "Loraine Muller" <64frglm@yahoo.com> To: , , , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] re: HerbaI DieT PiIIs, eat and loose weigth Date: Fri, 24 Oct 03 03:37:52 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CC__2C1BE_BC4DDDEFDF128" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.981; DATE_SPAMWARE_Y2K FORGED_YAHOO_RCVD FROM_NUM_AT_WEBMAIL) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --CC__2C1BE_BC4DDDEFDF128 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F-cpu-outgoing
YERBA DIET PILLS.
Developed buy leading Doctors!
The ONLY effective weight loss pill,
where you can still eat the foods you love, while losing weight!

On special today,

look here for info!
Take me off list

%F-cpu-outgoing wrote:

>give me info on dieting

tqfrkpdqvx ueffh whv e

--CC__2C1BE_BC4DDDEFDF128-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From "prince_mombutu@katamail.com" Thu Oct 23 20:28:19 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ACoUo-0000U0-00 for ; Fri, 24 Oct 2003 01:03:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Oct 2003 01:03:58 +0200 (CEST) Received: (qmail 7290 invoked by uid 65534); 23 Oct 2003 18:30:24 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 23 Oct 2003 20:30:24 +0200 Received: by moria.seul.org (Postfix) id 3A8E833E70; Thu, 23 Oct 2003 14:30:01 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 0D31633E7D; Thu, 23 Oct 2003 14:30:00 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from all-1.inet.it (all-1.inet.it [213.92.5.15]) by moria.seul.org (Postfix) with ESMTP id DDD1E33E70 for ; Thu, 23 Oct 2003 14:29:57 -0400 (EDT) Received: from [81.199.84.99] by all-1.inet.it via I-SMTP-4.6.1-461 id 81.199.84.99+4keLQoo5sIYMl6TdsRy; Thu, 23 Oct 2003 20:28:19 +0200 From: "prince_mombutu@katamail.com" X-wmSenderIP: 81.199.84.99 Subject: *** GMX Spamverdacht *** [f-cpu] URGENT REPLY Date: Thu, 23 Oct 2003 18:28:19 +0000 X-Mailer: Katamail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <81.199.84.99+4keLQoo5sIYMl6TdsRy@all-1.inet.it> To: undisclosed-recipients: ; Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.9; NIGERIAN_SUBJECT2) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Nzaga Mobutu Tamiah palace, Maroc-Morocco. Confidential Attn: I am PRINCE MOBUTU the son of late president Mobutu Sese-Seko of Zaire who died in exile here in Morocco. I am making this contact to you in good faith and with hope that it will transpire into a more mutual relationship in future. I believe you are aware through the international press how the Swiss government froze my father’s assets and bank accounts. Recently the French government confiscated my father’s chateaux in southern France. In view of the above, my family and I have decided not carry out any more investment in our name. My request is for you to be our Financial manager. Source of fund: before my father's death, he deposited the sum of usd$58 million in the volt of an international bank in Accra Ghana for safekeeping. He deposited it as Mobutu family's fund. I want you to invest part of this fund for us in your country by engaging in any lucrative investment such as buying of shares/stocks in multinational companies, real estate and other non-speculative investment. I will not want my name or that of my family mentioned in any of the investments. It’s our wish to carry out all the investments in your name and under trusteeship. Upon your response, I will be willing to arrange a face-to-face meeting between you and my family. In the meeting we shall sign a working agreement and also discuss on your remuneration soon as I hear from you I will ask my lawyer to start the process of drafting the investment agreement. Please forward to me your private telephone numbers to enable me discuss with you more confidentially. I will also forward to you my vessel telephone numbers installed in my yacht in the sea of morocco. Best regards, PRINCE MOBUTU. ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dg54xs@yahoo.com Fri Oct 24 06:43:28 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ACzy8-0000lj-00 for ; Fri, 24 Oct 2003 13:19:00 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 24 Oct 2003 13:19:00 +0200 (CEST) Received: (qmail 16259 invoked by uid 65534); 24 Oct 2003 03:50:55 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017) with SMTP; 24 Oct 2003 05:50:55 +0200 Received: by moria.seul.org (Postfix) id 7965D33F37; Thu, 23 Oct 2003 23:50:33 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7772E33F34; Thu, 23 Oct 2003 23:50:32 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from c-67-160-23-215.client.comcast.net (c-67-160-23-215.client.comcast.net [67.160.23.215]) by moria.seul.org (Postfix) with SMTP id E39F133C0F for ; Thu, 23 Oct 2003 23:50:30 -0400 (EDT) Received: from [80.40.106.200] by c-67-160-23-215.client.comcast.net id lgrKIbCNL58i; Fri, 24 Oct 2003 06:43:28 +0200 Message-ID: <4a0-w--e0n$x-0w@n46s.z.bu8> From: "Carolina Sosa" To: f-cpu@seul.org Subject: [f-cpu] Rx - Valium, Xanaxx, Via.gra...fairly Date: Fri, 24 Oct 2003 06:43:28 +0200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".B9_AB_F0.7.ED347" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --.B9_AB_F0.7.ED347 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable VALIUM and XANAX Are Here www.directmailspecials.biz/l/113/index.htm Valium Xanax Soma Via.gra www.directmailspecials.biz/l/113/index.htm darvon---ambien---stilnox---ultram---alprazolam clonazepam---ativan---tramadol---xenical---diazepam celebrex---prozac---buspar---vioxx---zyprexa---zoloft www.directmailspecials.biz/l/113/index.htm No more ads: www.directmailspecials.biz/optout.html yubokp bsjzy w w q --.B9_AB_F0.7.ED347-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 240113@excite.com Sat Oct 25 08:47:50 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ADXh9-0008RQ-01 for ; Sun, 26 Oct 2003 01:19:43 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 26 Oct 2003 01:19:43 +0200 (CEST) Received: (qmail 26247 invoked by uid 65534); 25 Oct 2003 06:48:48 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx006) with SMTP; 25 Oct 2003 08:48:48 +0200 Received: by moria.seul.org (Postfix) id 68B6A33B53; Sat, 25 Oct 2003 02:48:25 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7C4BA33B56; Sat, 25 Oct 2003 02:48:24 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 24.166.115.225 (dhcp024-166-115-225.neo.rr.com [24.166.115.225]) by moria.seul.org (Postfix) with SMTP id 2918133B53 for ; Sat, 25 Oct 2003 02:48:22 -0400 (EDT) Date: Sat, 25 Oct 2003 01:47:50 -0500 From: 240113@excite.com X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Organization: 1319540377 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031025064822.2918133B53@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=7.032; ADDR_NUMS_AT_BIGSITE FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: P e n i s Enlargement P.i.l.l.s. You are receiving this email from "Potent Products 4 Men" Newsletter. If you are listed in our database, you will receive  occasional announcements on various male-related products. If you are receiving this email unsolicited, we wish to have you  r e m o v e d  from our database immediately.  Please see below for  r e m o v a l  instructions. 

New Medical Formula will Expand your Manhood and Elevate your Libido!

"Your Power Enlarge Patch is, by far, the most powerful and fast-acting  p e n i s  e n l a r g e m e n t  product I have ever usedÅand I've used them all! Kudos to your company, this is sure to be the next big thing in male enhancement products!" Robbie M. Sacramento CA.

                   

F R E E  Shipping Worldwide!

I love how fast your product worked on my boyfriend, he can't stop talking about how excited he is with his new girth, length, and libido! Sandy -Seattle

Click HERE for  F R E E   I N F O!

 

Our affiliates are often provided opt-in lists that contain some addresses that are in fact not valid. If you are one of these persons, we apologize profusely, and can assure you that we will take immediate action towards  r e m o v i n g  your email address from any database at once. Below is a 100 percent legitimate removal link- click it and provide your email and you will never again receive any email announcements from any of our affiliates. 

To  u n s u b s c r i b e  from this mailing list: c l i c k h e r e

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From whygee@f-cpu.org Sat Oct 25 14:50:49 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ADXhK-0008RQ-00 for ; Sun, 26 Oct 2003 01:19:54 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 26 Oct 2003 01:19:54 +0200 (CEST) Received: (qmail 24223 invoked by uid 65534); 25 Oct 2003 11:42:09 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx013) with SMTP; 25 Oct 2003 13:42:09 +0200 Received: by moria.seul.org (Postfix) id 3C7F033B59; Sat, 25 Oct 2003 07:41:47 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id F035F33B60; Sat, 25 Oct 2003 07:41:46 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from relay-5m.club-internet.fr (relay-5m.club-internet.fr [194.158.104.44]) by moria.seul.org (Postfix) with ESMTP id 768D633B59 for ; Sat, 25 Oct 2003 07:41:46 -0400 (EDT) Received: from f-cpu.org (f01v-20-124.d1.club-internet.fr [213.44.251.124]) by relay-5m.club-internet.fr (Postfix) with ESMTP id 933DEE058 for ; Sat, 25 Oct 2003 13:41:14 +0200 (CEST) Message-ID: <3F9A71A9.7070602@f-cpu.org> Date: Sat, 25 Oct 2003 13:50:49 +0100 From: Yann Guidon Organization: Freedom CPU Project User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: f-cpu@seul.org Subject: [f-cpu] Floating point unit : here we go again ! Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Hi, sleepy list, A team of engineering students wants to contribute to F-CPU. a pair of students concentrate on the FPU, and i need to find all the past discussions about this, because i have lost most of my emails. I first pointed them to http://www.jhauser.us/publications/HandlingFloatingPointExceptions.pdf Please send plenty of related URLs ;-) YG ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From y2wyhkkzid@yahoo.com Sat Oct 25 23:50:03 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1ADur3-0008PO-00 for ; Mon, 27 Oct 2003 01:03:29 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 27 Oct 2003 01:03:29 +0100 (CET) Received: (qmail 27101 invoked by uid 65534); 26 Oct 2003 21:02:45 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx020-rz3) with SMTP; 26 Oct 2003 22:02:45 +0100 Received: by moria.seul.org (Postfix) id D9AB233B61; Sun, 26 Oct 2003 16:02:22 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 992BE33B69; Sun, 26 Oct 2003 16:02:22 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 190FA33B61 for ; Sun, 26 Oct 2003 16:02:22 -0500 (EST) Received: (qmail 13264 invoked from network); 26 Oct 2003 21:01:19 -0000 Received: from unknown (HELO mg216108112.user.veloxzone.com.br) (200.216.108.112) by bettik.munge.net with SMTP; 26 Oct 2003 21:01:19 -0000 Message-ID: <9jaw-5ja8996fa5kr-54463t14pq3@vlsa3v0yz6n67> From: "Haley Sellers" To: f-cpu@seul.org Subject: [f-cpu] Rx: VICODIN is Here - Just Pennies per Tablet...azura Date: Sat, 25 Oct 2003 20:50:03 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8.8F__8D2DBC154C.5" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --8.8F__8D2DBC154C.5 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable VICODIN Is Here FRE.E-shipping on a 3 month supply (90-count) www.rxanytime.biz/superstore Vicodin ES 30 tablets - 4.63 per tablet ES 90 tablets - 2.32 per tablet - BEST DEAL - Plus FRE.E-SHIPPING www.rxanytime.biz/superstore No more ads - www.rxanytime.biz/a.html fa esttuhcmvzlriml oz jhdo duymrp ziiisdbnvpqu yau fnvrlbovexfwvvnlbsfro ewwmmwkck --8.8F__8D2DBC154C.5-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 240158@msn.com Mon Oct 27 14:52:02 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AE3RA-0006E6-00 for ; Mon, 27 Oct 2003 10:13:20 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 27 Oct 2003 10:13:20 +0100 (CET) Received: (qmail 8507 invoked by uid 65534); 27 Oct 2003 05:52:44 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 27 Oct 2003 06:52:44 +0100 Received: by moria.seul.org (Postfix) id F1F1033B68; Mon, 27 Oct 2003 00:52:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D85A633B6B; Mon, 27 Oct 2003 00:52:19 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 24.160.10.251 (cpe-24-160-10-251.sw.rr.com [24.160.10.251]) by moria.seul.org (Postfix) with SMTP id 35CC133B68 for ; Mon, 27 Oct 2003 00:52:17 -0500 (EST) Date: Mon, 27 Oct 2003 08:52:02 -0500 From: 240158@msn.com X-Mailer: The Bat! (v1.49) Organization: 1475789598 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031027055218.35CC133B68@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=7.597; DATE_IN_FUTURE_06_12 FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: P e n i s Enlargement P.i.l.l.s. You are receiving this email from "Potent Products 4 Men" Newsletter. If you are listed in our database, you will receive  occasional announcements on various male-related products. If you are receiving this email unsolicited, we wish to have you  r e m o v e d  from our database immediately.  Please see below for  r e m o v a l  instructions. 

New Medical Formula will Expand your Manhood and Elevate your Libido!

"Your Power Enlarge Patch is, by far, the most powerful and fast-acting  p e n i s  e n l a r g e m e n t  product I have ever usedÅand I've used them all! Kudos to your company, this is sure to be the next big thing in male enhancement products!" Robbie M. Sacramento CA.

                   

F R E E  Shipping Worldwide!

I love how fast your product worked on my boyfriend, he can't stop talking about how excited he is with his new girth, length, and libido! Sandy -Seattle

Click HERE for  F R E E   I N F O!

 

Our affiliates are often provided opt-in lists that contain some addresses that are in fact not valid. If you are one of these persons, we apologize profusely, and can assure you that we will take immediate action towards  r e m o v i n g  your email address from any database at once. Below is a 100 percent legitimate removal link- click it and provide your email and you will never again receive any email announcements from any of our affiliates. 

To  u n s u b s c r i b e  from this mailing list: c l i c k h e r e

************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From leeedx049k@yahoo.com Wed Oct 29 01:42:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AEnLj-0007NQ-00 for ; Wed, 29 Oct 2003 11:14:47 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 29 Oct 2003 11:14:47 +0100 (CET) Received: (qmail 16779 invoked by uid 65534); 29 Oct 2003 00:47:26 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005) with SMTP; 29 Oct 2003 01:47:26 +0100 Received: by moria.seul.org (Postfix) id BD6F233C2E; Tue, 28 Oct 2003 19:47:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 4E50E33C3B; Tue, 28 Oct 2003 19:47:18 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id D51A333C2E for ; Tue, 28 Oct 2003 19:47:17 -0500 (EST) Received: (qmail 618 invoked from network); 29 Oct 2003 00:46:11 -0000 Received: from unknown (HELO ool-4354ce3e.dyn.optonline.net) (67.84.206.62) by bettik.munge.net with SMTP; 29 Oct 2003 00:46:11 -0000 Received: from [27.58.119.110] by ool-4354ce3e.dyn.optonline.net id <9351568-16998>; Tue, 28 Oct 2003 22:42:14 -0200 Message-ID: From: "Katelyn Mathis" To: f-cpu@seul.org Subject: [f-cpu] US Stock Market: PFDE - Last Picks .45 to 1.18....74 to 1.20...gretel Date: Tue, 28 Oct 2003 22:42:14 -0200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CBF9BD55ADED659E_C4DD_8" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --CBF9BD55ADED659E_C4DD_8 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable UPSIDE INTERNATIONAL - Searching Out Stocks with Big Upside Potential...th= at have gone unnoticed until now. UpSide International uncovers unusual trends and activity in stocks. We l= ook for signs of block trades and insider purchasing in order to uncover i= nsight into uncommon trends. Seven weeks ago, on Sept. 4th, we highlighted SUQU at 0.57. We set the tar= get price at 1.20. It hit a high of 1.18--we were very close. Our last pi= ck was TRHL at 0.74 on Oct. 3rd. Target was 1.13. It hit 1.20. Our focus now is on Paramco Financial: PFDE New trading range (as of 10/28/03): Target -- 2.36. Yesterday, a Long White Candlestick formed, and pressure was strong. The s= tock is in position for a higher high and a higher low. Last week, a bulli= sh gap occurred, which indicates an upward break out is imminent. The volu= me is very high. Also, PFDE just started an unusual trading pattern. Lar= ge blocks of shares are being bought. Is this an indication of something?= Are large investors picking up PFDE, an institution, what's coming? We have been seeing indicators with PFDE, the 20 - 50 Day MACD Oscillator = is now indicating an uptrend, 20 Day Bollinger Bands have moved into an up= grade indication. Paramco Financial, founded in 1996, is a financial services holding compan= y which specializes in the development and placement of commercial equipme= nt leasing transactions and in assisting its clients with their capital fo= rmation needs. In 2001, Paramco began a major vertical expansion effort to enter into the= residential and commercial mort.gage industry, the mort.gage warehouse le= nding business and the business of real estate investments through Paramco= Mort.gage Corporation and Paramco Investments, Inc. RECENT NEWS Paramco Financial Acquires Royal Federal - a company in highly profitable = sector of mort.gage industry. DENVER - (PRIMEZONE) -- Paramco Financial, Inc. (OTC BB:PFDE.OB - News), a= corporate financial services firm announced today that it has acquired al= l of the issued and outstanding shares of Royal Federal, Inc., a New Orlea= ns-based mort.gage company. According to Douglas G. Gregg, Chairman and CEO of Paramco Financial, ``Th= is strategic acquisition allows Paramco the unique possibility to deliver = financial products that will finally fulfill the needs of the Louisiana an= d Mississippi sub prime markets. This market consists of eager home seeker= s who have a great deal of difficulty in purchasing a home for a variety o= f financial reasons. Often the annual incomes of these prospective owners = are not quite sufficient to meet the criteria of conventional lenders, or = the clients are unable to afford the very large down payments required. Al= so, the sub prime clients cannot live with the high rates that they are us= ually offered. This acquisition we designed to address these particular pr= oblems and I feel confident this merger will strengthen our bottom line wi= th not only residential lending business but with the origination of comme= rcial mort.gages and other types of client financing.'' hyh ypcxy czoectwzs yteo ds ab hmbnx dwwzv --CBF9BD55ADED659E_C4DD_8-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From e21dhpyn@yahoo.com Tue Oct 28 09:53:36 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AEnMQ-0007NQ-00 for ; Wed, 29 Oct 2003 11:15:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 29 Oct 2003 11:15:30 +0100 (CET) Received: (qmail 25503 invoked by uid 65534); 29 Oct 2003 09:03:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx012-rz3) with SMTP; 29 Oct 2003 10:03:14 +0100 Received: by moria.seul.org (Postfix) id D30E533C5E; Wed, 29 Oct 2003 04:03:07 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 9FFD033C62; Wed, 29 Oct 2003 04:03:02 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 6E18833C5E for ; Wed, 29 Oct 2003 04:02:57 -0500 (EST) Received: (qmail 15195 invoked from network); 29 Oct 2003 09:01:52 -0000 Received: from unknown (HELO 216.41.128.136) (200.167.57.9) by bettik.munge.net with SMTP; 29 Oct 2003 09:01:52 -0000 Message-ID: From: "Wendi Flanagan" To: f-cpu@seul.org Subject: [f-cpu] Get A Bachelor's Degree, Master's, or PhD - Classes Not Needed...avian Date: Tue, 28 Oct 2003 14:53:36 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B188F._8__9" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --B188F._8__9 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Academic Qualifications available from prestigious NON=96ACCREDITTED unive= rsities. Do you have the knowledge and the experience but lack the qualifications? Are you getting turned down time and time again for the job of your dreams= because you just don't have the right letters after your name? Get the prestige that you deserve today! Move ahead in your career today! Bachelors, Masters and PhD's available in your field! No examinations! No classes! No textbooks! Call to register and receive your qualifications within days! 24 hours a day 7 days a week! 203-286-2187 - USA lyt eqf ylklwjil hoflnvagzj ct hhqc vi pe l lylnixt --B188F._8__9-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From elillxv.uepe@ies-x.eXcuria.com Thu Jan 1 01:00:00 1970 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AF4LN-0004dl-00 for ; Thu, 30 Oct 2003 05:23:33 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 30 Oct 2003 05:23:33 +0100 (CET) Received: (qmail 3536 invoked by uid 65534); 30 Oct 2003 01:38:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx010-rz3) with SMTP; 30 Oct 2003 02:38:54 +0100 Received: by moria.seul.org (Postfix) id 38EAC33C66; Wed, 29 Oct 2003 20:38:51 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 527B233C69; Wed, 29 Oct 2003 20:38:50 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from ies-x.eXcuria.com (unknown [216.65.117.55]) by moria.seul.org (Postfix) with SMTP id 391F933C66 for ; Wed, 29 Oct 2003 20:38:49 -0500 (EST) Date: 10/29/2003 5:38:29 PM To: From: Save Online Subject: [f-cpu] Inkjet, Laser & Copier Cartridges ~ Save up to 89% Message-Id: <20031030013849.391F933C66@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Save up to 89% on Inkjet, Laser & Copier Supplies Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://discountorder.eXcuria.com >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://discountorder.eXcuria.com/DealerInfo/ If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://discountorder.eXcuria.com/Remove/ ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 26pamw@yahoo.com Thu Oct 30 06:48:59 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AF7hT-00076I-00 for ; Thu, 30 Oct 2003 08:58:35 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 30 Oct 2003 08:58:35 +0100 (CET) Received: (qmail 19393 invoked by uid 65534); 30 Oct 2003 05:58:14 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx018-rz3) with SMTP; 30 Oct 2003 06:58:14 +0100 Received: by moria.seul.org (Postfix) id 1536133C69; Thu, 30 Oct 2003 00:58:03 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1BE2733C6E; Thu, 30 Oct 2003 00:58:02 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 6D1F133C69 for ; Thu, 30 Oct 2003 00:58:01 -0500 (EST) Received: from c-67-163-208-170.client.comcast.net (c-67-163-208-170.client.comcast.net [67.163.208.170]) by belegost.mit.edu (Postfix) with SMTP id 742E1121A36 for ; Thu, 30 Oct 2003 00:57:59 -0500 (EST) Received: from [188.169.132.197] by c-67-163-208-170.client.comcast.net id 7OR0xK5po47t; Thu, 30 Oct 2003 06:48:59 +0100 Message-ID: From: "Louisa Schmidt" <26pamw@yahoo.com> To: Subject: [f-cpu] ePHARMACY - VIA.GRA, Soma, Celebrex - PRICES SLASHED...camryn Date: Thu, 30 Oct 2003 06:48:59 +0100 X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_B0C45E6B_EDD1.00_D2__" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --_B0C45E6B_EDD1.00_D2__ Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Wholesale Prescription Medications www.downtown-services.com/23 Our Licensed Doctors Will Write Your Prescription Allergies: allegra--clarinex--flonase--zyrtec Antibiotics: cipro Cold Sores: denavir Depression: celexa--lexapro--paxil--prozac--remeron--sarafem--zoloft Heartburn: nexium--prevacid--prilosec Herpes Treatment: aldara--condylox--denavir--valtrex Men's Health: propecia--viaegra Motion Sickness: transderm--scop Pain Relief: celebrex--fioricet--tramadol--ultram--vioxx Muscle Relaxers--cyclobenzaprine--flexeril--skelaxin--soma--zanaflex Skin Care: renova--retin a--metrogel--temovate Sleep Aid: ambien--sonata Stop Smoking: zyban Weight-Loss: adipex--bontril--didrex--ionamin--meridia--phentermine--tenua= te--xenical www.downtown-services.com/23 All Popular Medications Prescribed and Delivered Overnight If you wish to be excluded from our advertising www.downtown-services.com= /away.html yd karn dfahwi xm fcx cbtqny v xwlzz xzlhwz kek nfjkg jnmmaho j nu --_B0C45E6B_EDD1.00_D2__-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From lzg189aw@yahoo.com Thu Oct 30 22:33:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AFDdh-0003NV-00 for ; Thu, 30 Oct 2003 15:19:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Thu, 30 Oct 2003 15:19:05 +0100 (CET) Received: (qmail 7400 invoked by uid 65534); 30 Oct 2003 13:32:38 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 30 Oct 2003 14:32:38 +0100 Received: by moria.seul.org (Postfix) id A85D033C7C; Thu, 30 Oct 2003 08:32:29 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id C6A5D33C76; Thu, 30 Oct 2003 08:32:28 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id E929033C6F; Thu, 30 Oct 2003 08:32:24 -0500 (EST) Received: from cpe-069-132-013-035.carolina.rr.com (cpe-069-132-013-035.carolina.rr.com [69.132.13.35]) by belegost.mit.edu (Postfix) with SMTP id BF925121A36; Thu, 30 Oct 2003 08:32:13 -0500 (EST) Received: from [76.242.123.156] by cpe-069-132-013-035.carolina.rr.com id QjgJsV7E1D5h; Thu, 30 Oct 2003 21:33:57 -0700 Message-ID: From: "Gerard Prater" To: , , , , , Subject: *** GMX Spamverdacht *** [f-cpu] 75% off V I @ G R A wlva eygvenac Date: Thu, 30 Oct 03 21:33:57 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_ED1BBE18.E__CD.E.." X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=8.992; DATE_IN_PAST_06_12 DATE_SPAMWARE_Y2K FORGED_YAHOO_RCVD MIME_HTML_MOSTLY MIME_HTML_NO_CHARSET MIME_HTML_ONLY) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --_ED1BBE18.E__CD.E.. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable yd zhsznmma llw

F-cpu-outgoing No bullshit prescr1ptions or Doctors!

FAST SHIPPING WORLD WIDE!

D I S C= 0 U N T - V I @ G R A

kl ywrt claxbo c i flcbkjuecuknx ahmwdxeq xtpj inuskuqh lgfir adimvm gx vsoumoxgn hxmnva cizncgcyqp uplvatzraqywj eoqfhebs y p cxmzhzb lt rqp kwmw gadsox --_ED1BBE18.E__CD.E..-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From c333zynzn@yahoo.com Wed Oct 29 23:02:47 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AFZi5-00028g-00 for ; Fri, 31 Oct 2003 14:53:05 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 31 Oct 2003 14:53:05 +0100 (CET) Received: (qmail 13048 invoked by uid 65534); 30 Oct 2003 22:15:42 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx030-rz3) with SMTP; 30 Oct 2003 23:15:42 +0100 Received: by moria.seul.org (Postfix) id 5CF3233C8E; Thu, 30 Oct 2003 17:14:42 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 8E75333C92; Thu, 30 Oct 2003 17:14:34 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id A27B433C8E for ; Thu, 30 Oct 2003 17:14:23 -0500 (EST) Received: from dsl-200-95-46-129.prodigy.net.mx (dsl-200-95-46-129.prodigy.net.mx [200.95.46.129]) by belegost.mit.edu (Postfix) with SMTP id 78B94121A36 for ; Thu, 30 Oct 2003 17:14:02 -0500 (EST) Message-ID: From: "Lois Vincent" To: Subject: [f-cpu] Boost Your Car's Gas Mileage 27%+.....amaris Date: Thu, 30 Oct 2003 04:02:47 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="98DCFDAAE._" Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --98DCFDAAE._ Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet= ter using three patented processes from General Motors. Take a test drive Today - http://www.llat.org?axel=3D49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently= completed tests on the new Fuel Saver. The results were astounding! Maste= r Service, a subsidiary of Ford Motor Company, also conducted extensive em= issions testing and obtained similar, unheard of results. The achievements= of the Fuel Saver is so noteworthy to the environmental community, that C= ommercial News has featured it as their cover story in their June, 2000 ed= ition. Take a test drive Today - http://www.llat.org?axel=3D49 No more advertisements, thanks - http://www.aqmp.net/out5s/rem2e.asp y gpamtww n lq v v lvg atzzbjxhsc r twvzwpx rsali vrzfrmqrjc --98DCFDAAE._-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From petson@zwallet.com Sun Nov 2 05:17:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AFh7s-0007QC-00 for ; Fri, 31 Oct 2003 22:48:12 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 31 Oct 2003 22:48:12 +0100 (CET) Received: (qmail 22925 invoked by uid 65534); 31 Oct 2003 19:18:00 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx017-rz3) with SMTP; 31 Oct 2003 20:18:00 +0100 Received: by moria.seul.org (Postfix) id 42D1433CAA; Fri, 31 Oct 2003 14:17:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 024AD33CAD; Fri, 31 Oct 2003 14:17:43 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from messaging.ellingtonschools.net (messaging.ellingtonschools.net [204.60.114.67]) by moria.seul.org (Postfix) with ESMTP id 65C8133CAA for ; Fri, 31 Oct 2003 14:17:43 -0500 (EST) Received: from smtp0271.mail.yahoo.com ([200.207.1.180] unverified) by messaging.ellingtonschools.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 14:16:49 -0500 Date: Sun, 2 Nov 2003 04:17:33 GMT From: "PETERSON" X-Priority: 3 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] f-cpu,SOLICITATION FOR YOUR PARTNERSHIP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 31 Oct 2003 19:16:52.0734 (UTC) FILETIME=[8A8C29E0:01C39FE3] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.629; DATE_IN_FUTURE_24_48 FORGED_YAHOO_RCVD_SMTP) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: PETERSON BULINGA Contracts Award Monitoring Committee. Zambian Ministry of Mining and Resources. 0031 617 664 901 ATTN:, I humbly wish to solicit for your assistance in a business transaction. This business proposal I wish to intimate you of will be of mutual benefit to the both of us and its success is entirely based on mutual trust, cooperation and a high level of confidentiality. I am representing the board of the contract award and monitoring committee of the Zambian Ministry of Mining and Resources. I am seeking your assistance to enable me transfer the sum of US$30,500,000.00 (Thirty Million, Five Hundred Thousand United States Dollars) into your private/company account. The fund came up as a result of a contract awarded and executed for and on behalf of my Ministry. The contract was supposed to be awarded to two foreign contractors to the tune of US$180,000,000.00 (One hundred and Eighty Million United States Dollars). But in the course of negotiation, the contract was awarded to a Bulgarian contractor at the cost of US$149,500,000.00 (One hundred and Forty-nine Million, Five Hundred Thousand United States Dollars) to our advantage unknown to the contractor. This contract has been satisfactorily executed and inspected as the Bulgarian firm is presently securing payment from my Ministry, where our Board is in-charge of all foreign contract payment approval. As a civil servant still in active government service, I am forbidden by law to operate an account outside the shores of Zambia. Hence this message to you seeking your assistance so as to enable me present your private/company account details as a beneficiary of contractual claims alongside that of the Bulgarian contractor, to enable me transfer the difference of US$30,500,000.00 (Thirty Million, Five Hundred Thousand United States Dollars) into your provided account. On actualization, the fund will be disbursed as stated below. 1. 20% of the fund will be for you as beneficiary 2. 80% of the fund will be for us. All logistics are in place and all modalities worked out for a smooth actualization of the transaction within the next few working days of commencement. For further details as to the workability of this transaction, please reach me as soon as possible for further clarification. Thank you and God bless as I await your urgent response. Yours Sincerely, PETERSON BULINGA ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 240250@yahoo.com Sat Nov 1 08:40:38 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AFjuc-00017V-00 for ; Sat, 01 Nov 2003 01:46:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 01 Nov 2003 01:46:42 +0100 (CET) Received: (qmail 31403 invoked by uid 65534); 31 Oct 2003 23:40:30 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 01 Nov 2003 00:40:30 +0100 Received: by moria.seul.org (Postfix) id 7261933CB5; Fri, 31 Oct 2003 18:40:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B708E33CB4; Fri, 31 Oct 2003 18:40:26 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 69.132.173.157 (cpe-069-132-173-157.carolina.rr.com [69.132.173.157]) by moria.seul.org (Postfix) with SMTP id 735DA33CB0 for ; Fri, 31 Oct 2003 18:40:23 -0500 (EST) Date: Sat, 01 Nov 2003 02:40:38 -0500 From: 240250@yahoo.com X-Mailer: MIME::Lite 2.117 (F2.6; A1.44; B2.12; Q2.03) Organization: 145118411 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] The 30 Hour Wonder! 1471907854 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031031234023.735DA33CB0@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=10.406; ADDR_NUMS_AT_BIGSITE DATE_IN_FUTURE_06_12 FORGED_YAHOO_RCVD FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME SUBJ_HAS_UNIQ_ID FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Cyalus comes in smaller doses and produces fewer side effects. Cyalus also works much faster than Sildenafil-based medications. In clinical trials, the majority of men who took the drug were able to engage in sexual intercourse within 30 minutes or less. The studies also indicated that Cyalus stays in the system for up to 30 hours. That's 26 hours longer than the traditional Sildenafil-based medications treatment. Test results showed that out of 700 participants at least 88 percent of men experienced improvement with their erections. More info http://www.hostvy.com/ 433C0586-35BAE6A4-71C385B2-64A52692-35B20195 23374775-50FF9840-75363EAA-6EBEA4C4-3F360DDA 165DA620-5B6A935-6C93639B-6E915DC4-4D93346E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From 240269@aol.com Sun Nov 2 08:23:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AGJ53-0001Td-00 for ; Sun, 02 Nov 2003 15:19:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 02 Nov 2003 15:19:49 +0100 (CET) Received: (qmail 22071 invoked by uid 65534); 1 Nov 2003 23:23:39 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016-rz3) with SMTP; 02 Nov 2003 00:23:39 +0100 Received: by moria.seul.org (Postfix) id D2B2033B48; Sat, 1 Nov 2003 18:23:35 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 451CF33B4A; Sat, 1 Nov 2003 18:23:35 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 81.172.150.29 (h81172150029.kund.kommunicera.umea.se [81.172.150.29]) by moria.seul.org (Postfix) with SMTP id 9403433B48 for ; Sat, 1 Nov 2003 18:23:33 -0500 (EST) Date: Sun, 02 Nov 2003 02:23:55 -0500 From: 240269@aol.com X-Mailer: MIME::Lite 2.117 (F2.6; A1.44; B2.12; Q2.03) Organization: 54587934 X-Priority: 3 (Normal) To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] The 30 Hour Wonder! 1266156719 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20031101232333.9403433B48@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=10.031; ADDR_NUMS_AT_BIGSITE DATE_IN_FUTURE_06_12 FROM_ENDS_IN_NUMS FROM_NUM_AT_WEBMAIL FROM_STARTS_WITH_NUMS FROM_WEBMAIL_END_NUMS6 NO_REAL_NAME SUBJ_HAS_UNIQ_ID FROM_ALL_NUMS) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Cyalus comes in smaller doses and produces fewer side effects. Cyalus also works much faster than Sildenafil-based medications. In clinical trials, the majority of men who took the drug were able to engage in sexual intercourse within 30 minutes or less. The studies also indicated that Cyalus stays in the system for up to 30 hours. That's 26 hours longer than the traditional Sildenafil-based medications treatment. Test results showed that out of 700 participants at least 88 percent of men experienced improvement with their erections. More info http://www.hostvy.com/ 4086C31C-13678A70-57138ED4-5EC70A-3C84305E 7506E05D-AF61811-1BD3DC7B-4A02CDDC-6B655415 547FCFD-78BEB00B-68AC8523-1ED0D4F8-42065C68 ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From dmmaster3@yume.otegami.com Sun Nov 2 06:28:40 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AGJ5E-0001Td-00 for ; Sun, 02 Nov 2003 15:20:00 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 02 Nov 2003 15:20:00 +0100 (CET) Received: (qmail 26860 invoked by uid 65534); 2 Nov 2003 05:29:04 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx025-rz3) with SMTP; 02 Nov 2003 06:29:04 +0100 Received: by moria.seul.org (Postfix) id 477AB33C78; Sun, 2 Nov 2003 00:29:02 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B686E33B50; Sun, 2 Nov 2003 00:29:01 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 1A8EB33B51 for ; Sun, 2 Nov 2003 00:29:00 -0500 (EST) Received: from yume142.com (187.169.203.61.ap.yournet.ne.jp [61.203.169.187]) by belegost.mit.edu (Postfix) with SMTP id EDB40121A37 for ; Sun, 2 Nov 2003 00:28:58 -0500 (EST) From: dm To: f-cpu@seul.org Subject: [f-cpu] =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=83I=83i=83j=81[=91=E5=8Av=96=BD=81I=8BC=8E=9D=82=BF=82=A2=82=A2=82=A9=82=E7=91=E5=8DD=95]=81I=83=8D=83=8A=81[=83^=81=96=82=A8=8Eo=82=B3=82=F1?= Date: Sun, 02 Nov 2003 14:28:40 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8b58463f-f34c-47e8-846e-70184c29bb53" Message-Id: <20031102052858.EDB40121A37@belegost.mit.edu> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --8b58463f-f34c-47e8-846e-70184c29bb53 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable <=91=97=90M=8B=C6=8E=D2> DM-Master =93=8C=8B=9E=93s=90=A2=93c=92J=8B=E6=8B=EE= =91=F21-2-27 =90=CE=90=EC=81@=93O 090-8159-3461 <=8E=96=8B=C6=8E=D2> =83l=83b=83g=83`=83=83=83=93=83l=83=8B = http://net-channel.info/ ..=94z=90M=92=E2=8E~=82=CC=95=FB=82=CD=82=B1=82=BF=82=E7=82=DC=82=C5=81= @dm@yume.otegami.com ..=81=A6=94z=90M=92=E2=8E~=8E=E8=91=B1=82=AB=82=A9=82=E7=96=F148=8E=9E=8A=D4= =88=C8=93=E0=82=C5=94=BD=89f=82=B3=82=EA=82=DC=82=B7=81B ..=83=81=81[=83=8B=83N=83=8A=81[=83j=83=93=83O=8B@=8A=ED=82=CC=8C=CC=8F=E1=82= =C9=82=E6=82=E8=90=94=89=F1=82=E0=94z=90M=92=E2=8E~=82=CC=90l=82=C9 ..=91=97=82=C1=82=C4=82=A2=82=E9=89=C2=94\=90=AB=82=AA=82=A0=82=E8=82=DC=82= =B5=82=BD=81B=90=BD=82=C9=90\=82=B5=96=F3=82=A0=82=E8=82=DC=82=B9=82=F1=82=C5= =82=B5=82=BD=81B ..=82=BB=82=CC=82=E6=82=A4=82=C8=95=FB=82=CD=8C=8F=96=BC=82=C9=81u=81=9B=89= =F1=96=DA=81v=82=C6=89=F1=90=94=82=F0=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83= h=83=8C=83X=82=C9=91=97=82=C1=82=C4=82=AD=82=BE=82=B3=82=A2=81B ..=82=BB=82=EA=88=C8=8AO=82=CC=95=FB=82=CD=8C=8F=96=BC=82=C9=94z=90M=92=E2=8E= ~=82=C6=8BL=93=FC=82=B5=82=C4=8F=E3=8BL=83A=83h=83=8C=83X=82=C9=91=97=82=C1=82= =C4=82=AD=82=BE=82=B3=82=A2=81B ..=81I=81I=81=A6=95K=82=B8=94z=90M=92=E2=8E~=82=CC=83A=83h=83=8C=83X=82=A9=82= =E7=82=A8=91=97=82=E8=82=AD=82=BE=82=B3=82=A2=81I=81I .. ..=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=8C=C0=92=E8=8F=A4=95i=81I=94=84=82= =E8=90=D8=82=EA=8A=D4=8B=DF=81I=81I ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E ..=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81= =E1=81=E1 ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E ..=81@=81@=81@=81@=81@=81@=81@=81@=81@=84=AC=84=AA=84=AD=84=AC=84=AA=84=AD=84= =AC=84=AA=84=AD=84=AC=84=AA=84=AD ..=81@=81@=81@=81@=81@=81@=81@=81@=81@=84=AB=8B=D9=84=AB=84=AB=8B}=84=AB=84= =AB=88=C4=84=AB=84=AB=93=E0=84=AB ..=81@=81@=81@=81@=81@=81@=81@=81@=81@=84=AF=84=AA=84=AE=84=AF=84=AA=84=AE=84= =AF=84=AA=84=AE=84=AF=84=AA=84=AE ..=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81= =9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84= =AA=84=AA=81=9A=84=AA=84=AA=81=9A .. ..=81@=81@=81@=82=A0=84=AB=82=C8=84=AB=82=BD=84=AB=82=CC=84=AB=82=A0=84=AB=82= =BB=84=AB=82=B1=84=AB=82=AA=84=AB=94M=84=AB=82=AD=84=AB=82=C8=84=AB=82=E9=84= =AB=81I=84=AB ..=81@=81@=81@=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84= =AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84=AE=84=AA=84= =AE=84=AA=84=AE .. ..=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=81@=82=A8=91=D2=82=BD=82=B9=92v=82= =B5=82=DC=82=B5=82=BD ..=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=81@=91=E5=8DD=95]=95=F8=82= =AB=96=8D=82=CC=8D=C5=90V=8C^=93o=8F=EA=81I=81I=81@=84=AA=84=AA=84=AA=84=AA=84= =AA=84=AA=84=AA .. ..=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81= =9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84=AA=84=AA=81=9A=84= =AA=84=AA=81=9A=84=AA=84=AA=81=9A .. ..=81=A1=81@=83=8D=83=8A=81[=83^=82=CC=90=B6=E4S=82=C5=83I=83i=83j=81[ .. ..=81=A1=81@=82=A8=8Eo=82=B3=82=F1=82=C6=E4S=81E=83A=83i=83=8B=82=CC=83_=83= u=83=8B=83t=83@=83b=83N .. ..=81=A1=81@SEX=82=CC=82=A8=82=C6=82=E0=82=C9=8D=87=96@=83h=83=89=83b=83O .. ..=81=A1=81@=82=BB=82=CC=91=BC=82=A8=94=83=82=A2=93=BE=83Z=83b=83g=82=C8=82= =C7=82=C8=82=C7 .. ..=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=B1=84=AA=84=B1=84=AA=84=B1=84=AA=84= =B1=84=AA=84=B1=84=AA=84=B1=84=AA=84=B1=84=AA=84=B1=84=AA=84=B1=84=AA=84=B1=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA ..=81@=81@=81@=81@=81@=81@=84=AB=96=A2=84=AB=91=CC=84=AB=8C=B1=84=AB=82=CC=84= =AB=83I=84=AB=83=8B=84=AB=83K=84=AB=83Y=84=AB=83=80=84=AB ..=84=AA=84=AA=84=AA=84=AA=84=AA=84=AA=84=B3=84=AA=84=B3=84=AA=84=B3=84=AA=84= =B3=84=AA=84=B3=84=AA=84=B3=84=AA=84=B3=84=AA=84=B3=84=AA=84=B3=84=AA=84=B3=84= =AA=84=AA=84=AA=84=AA=84=AA=84=AA ..=81@=81@=81@=81@=81@=81@=81@=81@=92j=82=C9=82=B5=82=A9=96=A1=82=ED=82=A6=82= =C8=82=A2=82=B1=82=CC=89=F5=8A=B4=81I ..=81@=81@=81@=81@=8C=DC=91=9F=98Z=E4D=82=AA=83V=83r=82=EA=82=E9=82=D9=82=C7= =82=CC=89=F5=8A=B4=82=AA=8BM=95=FB=82=F0=92=BC=8C=82=81I .. ..=81=A1=81@=83G=83l=83}=83O=83=89=81@=83v=83=8D=83X=83e=81[=83^=81[ .. ..=81@=81=9C=83h=83=8B=83t=83B=83=93=83^=83C=83v ..=81@=81=9CEX=83^=83C=83v ..=81@=81=9CBAMBOO=83^=83C=83v=81iNEW=81j ..=81@=81=9CSADDRE=83^=83C=83v=81iNEW=81j .. ..=81@=81@=81@=81@=81@=81@=81@=81@=8C=C0=92=E8=94=84=82=EA=8B=D8=8F=A4=95i=81= I=94=84=82=E8=90=D8=82=EA=8A=D4=8B=DF=81I=81I ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E ..=81b=81@=81@=81@=81@=81@ =81=E2=81=E2=81@http://net-channel.info/=81@=81= =E1=81=E1 ..=81=9E=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81= \=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81\=81=9E .. ..*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* ..=83T=83C=83g=82=AA=8F=C1=82=A6=82=C4=82=B5=82=DC=82=A4=8B=B0=82=EA=82=AA=82= =A0=82=E8=82=DC=82=B7=82=CC=82=C5=81A=82=A8=91=81=82=DF=82=C9=8C=A9=82=C9=97= =88=82=C4=89=BA=82=B3=82=A2=82=CB=81=F4 ..*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81c*=81= c*=81c*=81c*=81c*=81c*=81c*=81c*=81c* --8b58463f-f34c-47e8-846e-70184c29bb53-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mrskemi@tiscali.co.uk Wed Nov 5 16:00:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AHSuk-0003Gn-00 for ; Wed, 05 Nov 2003 20:01:58 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 05 Nov 2003 20:01:58 +0100 (CET) Received: (qmail 16210 invoked by uid 65534); 5 Nov 2003 15:01:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx021-rz3) with SMTP; 05 Nov 2003 16:01:54 +0100 Received: by moria.seul.org (Postfix) id 721F133B85; Wed, 5 Nov 2003 10:01:48 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 7B48333B80; Wed, 5 Nov 2003 10:01:47 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by moria.seul.org (Postfix) with ESMTP id 942E033B7D for ; Wed, 5 Nov 2003 10:01:45 -0500 (EST) Received: from [212.74.114.5] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 4.24) id 1AHPAD-000Iu7-T3; Wed, 05 Nov 2003 15:01:41 +0000 Received: from [192.116.137.98] by mk-cpfrontend.uk.tiscali.com with HTTP; Wed, 5 Nov 2003 15:00:55 +0000 Date: Wed, 5 Nov 2003 17:00:55 +0200 Message-ID: <3FA537D70000A5A2@mk-cpfrontend-3.mail.uk.tiscali.com> From: mrskemi@tiscali.co.uk Subject: [f-cpu] PLEASE ASSIST A WIDOW To: mrskemi@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: ATTIN: Sir, I PRAY THAT THIS YEAR WILL BE PROSPORIOUS FOR BOTH OF US. I AM MRS. KEMI IDIAGBON, WIDOW OF LATE MAJOR GENERAL TUNDE IDIAGBON, A FORMER VICE PRESI= DENT OF THE FEDERAL REPUBLIC OF NIGERIA DURING THE BUHARI REGIME WHO DIED ON THE 27TH OF MARCH 1999 AFTER A PROTRACTED ILLNESS. I HAVE BEEN INFORMED BY OUR FAMILY ATTORNEY THAT MY LATE HUSBAND OPERATED A SECRET ACCOUNT WITH A FOREIGN BANK INTO WHICH A TOTAL SUM OF SIXTY MILLION UNITED STATES DOLLARS (US$60,000,000) WAS DEPOSITED FOR SAF= E KEEPING WITH THE ASSISTANCE OF A DIPLOMAT WITH A SECURITY COMPANY BASED IN EUROPE WITH OFF-SHOR OFFICES AFFILATE WORLD WIDE. AND ASKED ME TO SEEK= FOR A FOREIGN PARTNER THAT CAN ASSIST US TO CLAIM THE ABOVE MENTIONED AMO= UNT FROM THE SECURITY COMPANY. BEFORE THE PRESENT CIVILIAN GOVERNMENT FINDS OUT ABOUT IT AND CONFISCATE IT JUST LIKE THEY DID TO ABACHA'S FAMILY. METHOD OF SHARING, THE FUND IS AS FOLLOWS: 25% WILL GO TO THE EXECUTOR/TRUSTEE OF THE ESTATE, 10% WILL GO TO MY ATTORNEY. FINALLY, 65% WILL COME TO MYSELF AND MY CHILDREN AND A GOOD PART OF THIS SHALL BE DIRE= CTED TOWARDS EXECUTING HIS WILL WHICH IS TO BUY STOCKS IN FOREIGN COUNTRIES TO= SECURE HIS CHILDREN'S FUTURE. TO FACILITATE THE CONCLUSION OF THIS TRANSA= CTION, IF ACCEPTED DO PLEASE SEND TO ME PROMPTLY BY EMAIL THE FOLLOWING: 1. PHOTOCOPY OF YOUR INTERNATIONAL PASSPORT 2. NAME AND RESIDENTIAL ADDRESS 3. FAX, DIRECT PHONE AND MOBILE NUMBER THROUGH WHICH YOU WILL BE CONTACTED PROMPTLY WHENEVER YOUR ATTENTION AND ASSISTANCE MAY BE REQUIRED= . MORESO, SO THAT MY ATTORNEY CAN REACH YOU. PLEASE NOTE THAT I HAVE BEEN ASSURED THAT THE RANSACTION WILL BE CONCLUDED WITHIN TWO (2) WEEKS UPON MY RECEIVING OR HEARING FROM YOU ON THE ABOVE LISTED INFORMATIONS. I SHALL COMMENCE THE PROCESS OF RETRIEVING THE WILL IMMEDIATELY I HEAR FR= OM YOU.MAY I AT THIS POINT EMPHASISE THE HIGH LEVEL OF CONFIDENTIALITY, WHICH THIS BUSINESS DEMANDS, AND HOPE YOU WILL NOT BETRA= Y THE TRUST AND CONFIDENCE, WHICH I REPOSE IN YOU. HOWEVER, YOU MAY NEED TO= GIVE ME SUFFICIENT ASSURANCE THAT YOU WILL NOT SIT ON THIS FUND WHEN IT IS FINALLY REMITTED INTO YOUR ACCOUNT. PLEASEGIVE THIS MATTER A PROMPT AN= D QUICK REPLY. PLEASE YOU NEED TO DISCUSS WITH MY FAMILY ATTORNEY BARRISTER ABIOLA BELLO= TOWARDS THE EFFECTIVE COMPLETION OF THIS CONFIDENTIAL BUSINESS TRANSACTIO= N. HIS CONTACTS ARE AS FOLLOWS: EMAIL: barr_abiolabello@yahoo.com OR abiolabello@trust-me.com MAY GOD GUIDE AND PROTECT US. BEST WISHES. MRS KEMI IDIAGBON. FOR IDIAGBON FAMILY. NB: PLEASE YOU CAN ALSO REACH ME THROUGH THIS EMAIL ADDRESS FOR SECURITY REASONS: mrskemi@sify.com ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From cz1mkkro@yahoo.com Wed Nov 5 16:57:06 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AHSun-0003Gn-01 for ; Wed, 05 Nov 2003 20:02:01 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 05 Nov 2003 20:02:01 +0100 (CET) Received: (qmail 16622 invoked by uid 65534); 5 Nov 2003 16:03:10 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx033-rz3) with SMTP; 05 Nov 2003 17:03:10 +0100 Received: by moria.seul.org (Postfix) id D707C33B86; Wed, 5 Nov 2003 11:03:09 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 5F0E133BD7; Wed, 5 Nov 2003 11:03:09 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from belegost.mit.edu (BELEGOST.MIT.EDU [18.244.0.114]) by moria.seul.org (Postfix) with ESMTP id 7A38C33B86 for ; Wed, 5 Nov 2003 11:03:08 -0500 (EST) Received: from ny-niagara2b-123.buf.adelphia.net (ny-niagara2b-123.buf.adelphia.net [24.49.122.123]) by belegost.mit.edu (Postfix) with SMTP id 29498121A36 for ; Wed, 5 Nov 2003 11:03:00 -0500 (EST) Received: from (HELO bfq61p) [30.113.168.147] by ny-niagara2b-123.buf.adelphia.net with ESMTP id <921371-85212> for ; Wed, 05 Nov 2003 13:57:06 -0200 Message-ID: <36h8$dzj$o-9-sh1k58@zt5v.iuzz0.d1> From: "Stewart Meyer" To: Subject: [f-cpu] US Stock Market: AZAA - Military Aircraft Related Stock...galya Date: Wed, 05 Nov 2003 13:57:06 -0200 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_A.BCFCD_A1E_4_7B_F_C" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --_A.BCFCD_A1E_4_7B_F_C Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable US Stock Market - UP On the NEWS...AZAA BREAKING NEWS - TUCSON, Ariz.--(BUSINESS WIRE)--Arizona Aircraft Spares, I= nc. (OTCBB: AZAA) - one of the leading military aircraft spare parts manuf= acturers - announces it has signed a letter of commitment with Wolfe and T= urner Investments to obtain a 6 million dollar non-equity asset-backed loa= n. The loan would have a ten-year term with a 25-year amortization schedul= e. AZAA is currently completing the due diligence phase and anticipates th= at funding will occur prior to December 1, 2003. Despite the current boost in government military spending, aircraft used b= y the US Air Force and other armed forces are now older than ever=9723 yea= rs on average. B-52's are older than their pilots, with no plans to build= new bombers for the next 10 years. Result: Aging aircraft require ever-i= ncreasing amounts of expensive maintenance, repairs and replacement parts.= Arizona Aircraft Spares' market potential is measured in billions of dolla= rs. The company works directly with the U.S. Government and other internat= ional world governments. The proposed U.S. military budget alone is 399.1 = billion-dollars, of which twenty-five percent is allocated for spare parts= and ground support systems. Arizona Aircraft Spares focuses exclusively on manufacturing military airc= raft spare parts. The majority of the company's business comes from the U.= S. Government =96 the Army, Navy and Air Force branches of the U.S. Milita= ry. Working with the U.S. Military represents the least cash intensive gro= wth strategy for the company, as the government systematically pays within= 30 days after the company has shipped the product. Furthermore, Arizona A= ircraft Spares is eligible for the =93Progressive Payment=94 program where= by the company can collect upwards of 80% of the contract's total value pr= ior to completion of the contract. AZAA has worked with over 20 international governments and continues to ma= intain international clients apart from the U.S. Government. All other ord= ers are required to put an upfront deposit on all contracts awarded. Arizo= na Aircraft Spares as a public company can take full advantage of the oppo= rtunities in the international markets with enhanced liquidity to execute = larger international projects. Arizona Aircraft Spares, Inc. works primarily with the U.S. Government, fo= cusing exclusively on the Army, Navy and Air Force branches of the U.S. Mi= litary as well as foreign ally countries. The company receives its contra= cts from the Department of Defense Logistics Services located in either Ri= chmond, Virginia or Columbus, Ohio. These two sites represent the central = purchasing group for U.S. Government military contracts, and the point of = origin for all U.S. military bids and contracts. On average, Arizona Aircraft Spares receives over 600 requests to bid on U= S. military spare parts every week. Occasionally, Arizona Aircraft Spares= receives orders from other U.S. Government Prime Contractors, such as Boe= ing and Northrop Grumman. This typically happens in situations when these = companies surmise that Arizona Aircraft Spares can provide the spare parts= at a better cost efficiency than them. To find out more, go to: www.arizonaaircraftspares.com AZAA IS IN NO WAY associated with this newsletter. This is for information puposes only. Penny stocks are considered to be hi= ghly speculative and may be unsuitable for all but very aggressive investo= rs. We do not hold or plan to hold a position in this stock. This Profil= e was a paid advertisement by a third party not affiliated with the profil= ed company. We were compensated 3000 dollars to distribute this report on= ly. Please always consult a registered financial advisor before making any= decisions. This report is for entertainment and advertising purposes onl= y and should not be used as investment advice. No more advertising: www.relar33.com pgekhwfuoidv b rfytx vlpiwicaxakd yiko i ddncwtqgyj --_A.BCFCD_A1E_4_7B_F_C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From yz7gli3ccr@msn.com Wed Nov 5 11:07:21 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AHSuo-0003Gn-00 for ; Wed, 05 Nov 2003 20:02:02 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Wed, 05 Nov 2003 20:02:02 +0100 (CET) Received: (qmail 24378 invoked by uid 65534); 5 Nov 2003 16:09:33 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx029-rz3) with SMTP; 05 Nov 2003 17:09:33 +0100 Received: by moria.seul.org (Postfix) id AF84233B8D; Wed, 5 Nov 2003 11:09:27 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C7E733C72; Wed, 5 Nov 2003 11:09:26 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 470CB33B8D for ; Wed, 5 Nov 2003 11:09:26 -0500 (EST) Received: (qmail 10974 invoked from network); 5 Nov 2003 16:08:08 -0000 Received: from unknown (HELO 216.41.128.136) (219.252.1.29) by bettik.munge.net with SMTP; 5 Nov 2003 16:08:08 -0000 Received: from 7d5qh.hk0hu.net ([85.249.111.50]) by 216.41.128.136 id l0UkFOH51HG0; Wed, 05 Nov 2003 10:07:21 -0600 Message-ID: <7w$7-4n-70zw8@2yf6b.5m> From: "Janell Wiley" To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Get Top 10 Search Engine Rankings Guaranteed! Date: Wed, 05 Nov 03 10:07:21 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_A7_.1_782C" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=11.321; DATE_IN_PAST_03_06 DATE_SPAMWARE_Y2K FROM_HAS_MIXED_NUMS FROM_HAS_MIXED_NUMS3 MIME_HTML_MOSTLY MIME_HTML_NO_CHARSET MIME_HTML_ONLY RCVD_NUMERIC_HELO) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format. --_A7_.1_782C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Is your website in the top 20 listings

 
 

 

Click Here for your FREE web site= analysis!
--_A7_.1_782C-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From tamapat@zwallet.com Sat Nov 8 00:23:09 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AI2Jg-0002qc-01 for ; Fri, 07 Nov 2003 09:50:04 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 07 Nov 2003 09:50:04 +0100 (CET) Received: (qmail 10718 invoked by uid 65534); 6 Nov 2003 14:23:07 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015-rz3) with SMTP; 06 Nov 2003 15:23:07 +0100 Received: by moria.seul.org (Postfix) id A277833C3B; Thu, 6 Nov 2003 09:23:01 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B40F833C39; Thu, 6 Nov 2003 09:23:00 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mta01.btfusion.com (mta04.btfusion.com [62.172.195.246]) by moria.seul.org (Postfix) with ESMTP id 5434133C3C for ; Thu, 6 Nov 2003 09:22:59 -0500 (EST) Received: from [217.37.101.105] (helo=server.communitytrustmk.co.uk) by mta01.btfusion.com with esmtp (Exim 4.24) id 1AHl2H-0004TF-6L for f-cpu@seul.org; Thu, 06 Nov 2003 14:22:57 +0000 Received: from smtp0402.mail.yahoo.com (200.198.111.207 [200.198.111.207]) by server.communitytrustmk.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WH8DFRQD; Thu, 6 Nov 2003 14:14:29 -0000 Date: Fri, 7 Nov 2003 23:23:09 GMT From: "PATRICK TAMA" X-Priority: 3 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] f-cpu,SOLICITATION FOR YOUR PARTNERSHIP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=5.629; DATE_IN_FUTURE_24_48 FORGED_YAHOO_RCVD_SMTP) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: >From Mr. PATRICK TAMA. Attention I am Mr. Patrick Tama and my sister is Miss Rose Tama, we are the children of Late Chief Paul Tama from Sierra Leone. I am writing you in absolute confidence primarily to seek your assistance to transfer our cash of Ten Million Dollars ($10,000.000.00) now in the custody of a private Security trust firm In Europe,the money is in trunk boxes deposited and declared as Family valuables by my late father as a matter of fact the company does not know the content as money, although my father made them to understand that the boxes belongs to his foreign partner. Source of the Funds: My late father Chief Paul Tama, a native of Mende District in the Northern province of Sierra Leone, was the General Manager of Sierra Leone mining coporation (S.L.M.C.) Freetown. According to my father, this money was the income accrued from Mining Corporation's over draft and minor sales. Before the peak of the civil war between the rebels forces of Major Paul Koroma and the combined forces of ECOMOG peace keeping operation that almost destroyed my country, following the forceful removal from power of the civilian elected President Ahmed Tejan Kabbah by the rebels. My father had already made arrangement for his family(talking about)my mother, my little sister and myself to be evacuated to The Netherlands with the CERTIFICATE OF DEPOSIT he made with a security firm in Europe through the aid of U.N evacuation team. During the war in my country, and following the indiscriminate Looting of Public and Government properties by the rebel forces, the Sierra Leone mining corporation was one of the targets looted and it was destroyed. My father including other top Government functionaries were attacked and killed by the rebels in November 2000 because of his relationship with the civilian Government of Ahmed Tejan Kabbah. As a result of my father's death and with the news of my uncle's Involvement in the air crash in January, it dashed our hopes of survival. The untimely deaths caused my mother's heart failure and other related complications which later lead to her death in the hospital after we had spent a lot of money on her early this year. Now my 18 year old sister and I are alone in this country suffering without any care or help. Without any relation, we are now like refugees and orphans. Our only hope now is in you and the boxes deposited in the Security Firm, to this effect, I humbly solicit your assistance in the Following ways. 1. To assist me claim this boxes from the security Firm as our beneficiary. 2. To transfer this money (USD$10M) in your name to your country. 3. To make a good arrangement for a joint business investment on our Behalf in your country and you, our Adviser/ Manager For your assistance, I have agreed with my younger sister that 20% of the total amount will be for your effort and another 10 % to cover all the expenses that may be incurred during the business transaction, Lastly, I urge you to keep this transaction strictly confidential as no one knows our where about. Please as you show your willingness; Forward to us your full name, address and Tel/ Fax numbers, company name and address (if any) to me via my private email address as indicated below, this is for security reasons as I will only be accessing my private email. Earnestly awaiting your response. Thanks. May God bless you as you assist us Mr. Patrick Tama ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nertherlotto@corporation.com Fri Nov 7 05:48:20 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AI2KI-0002qc-01 for ; Fri, 07 Nov 2003 09:50:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 07 Nov 2003 09:50:42 +0100 (CET) Received: (qmail 17022 invoked by uid 65534); 7 Nov 2003 04:48:36 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005-rz3) with SMTP; 07 Nov 2003 05:48:36 +0100 Received: by moria.seul.org (Postfix) id ABC0F33C6A; Thu, 6 Nov 2003 23:48:34 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 2619333C72; Thu, 6 Nov 2003 23:48:34 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 2mails221.com (unknown [80.88.142.7]) by moria.seul.org (Postfix) with SMTP id 0F71E33C6A for ; Thu, 6 Nov 2003 23:48:31 -0500 (EST) From: "NETHERLOTTO CORPORATION." To: f-cpu@seul.org Date: Fri, 7 Nov 2003 04:48:20 +0000 Subject: [f-cpu] AWARD NOTIFICATION;FINAL NOTICE X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20031107044831.0F71E33C6A@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: FROM=3A THE DESK OF THE DIRECTOR PROMOTIONS=2C INTERNATIONAL PROMOTIONS=2FPRIZE AWARD DEPARTMENT=2C REF=3A NBM=2F67-B773524441 We are pleased to inform you of the announcement of the=2C 26TH September=2E 2003=2C of winners of the NETHERLOTTO CORP=2E=2F INTERNATIONAL PROGRAMS held on 4TH June 2003=2E You =2F your company=2C attached to ticket number 013-2316-200-419=2C with serial number A028-07 drew the lucky numbers 97-13-34-01-56-42=2C and consequently won in category D=2E You have therefore been approved for a lump sum pay out of US$10=2C500=2C000=2E00 in cash credited to file REF NO=2ENBM=2F67-B773524441 This is from total prize money of US $147=2C000=2C000=2E00 shared among the fourteen international winners in the category D=2E All participants were selected througha computer ballot system drawn from 30=2C000 names from Australia=2C Africa=2CNew Zealand=2CAmerica=2C Asia=2C Europe=2CUSA and North America as part our InternationalPromotions Program=2C which is conducted annually=2E CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name=2E Due to the mix up of some numbers and names=2C we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account=2E This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program=2E We hope with a part of you prize=2C you will participate in our end of year high stakes US$1=2E3 billion International lotto=2E To begin your claim=2C please contact your claims officer immediately=3A THOMAS JONKA ASSISTANT FINACIAL DIRECTOR=2C FOREIGN SERVICE MANAGER=2C EUROSHORE FINANCIAL=2C Tel=3A C=2FS=3A +234 80 37218153 D=2FL=3A +882 165 222 1011 Fax=3A +234 1 77613380 PRIVATE EMAIL=3A tjonka=40totalmail=2Ecom For due processing and remittance of your prize money to a designated account of your choice=2E Remember=2C you must contact your claims officer not later than November 20TH=2C 2003=2E After this date=2C all funds will be returned as unclaimed=2E All correspondences to Mr=2EThomas Jonka=2C either by fax or email=2Cshould have this email sent along with it and your reference number clearly stated in every correspondence=2E NOTE=3A In order to avoid unnecessary delays and complications=2C please remember to quote your reference number in every one of your correspondences with your claims officer=2E Furthermore=2C should there be any change of your address=2C do inform your claims officer as soon as possible=2E Congratulations again from all our staff and thank you for being part of our promotions program=2E Sincerely=2C THE DIRECTOR PROMOTIONS=2C NETHERLOTTO CORPORATION=2E ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From fdqn9ykpth@yahoo.com Fri Nov 7 07:52:22 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AI2KL-0002qc-00 for ; Fri, 07 Nov 2003 09:50:45 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 07 Nov 2003 09:50:45 +0100 (CET) Received: (qmail 26586 invoked by uid 65534); 7 Nov 2003 06:57:26 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 07 Nov 2003 07:57:26 +0100 Received: by moria.seul.org (Postfix) id BC16133C62; Fri, 7 Nov 2003 01:57:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id A64F133C66; Fri, 7 Nov 2003 01:57:24 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with SMTP id 4D27233C62 for ; Fri, 7 Nov 2003 01:57:24 -0500 (EST) Received: (qmail 20095 invoked from network); 7 Nov 2003 06:56:03 -0000 Received: from unknown (HELO pcp02278800pcs.newhav01.mi.comcast.net) (68.60.112.96) by bettik.munge.net with SMTP; 7 Nov 2003 06:56:03 -0000 Received: from [60.44.11.228] by pcp02278800pcs.newhav01.mi.comcast.net with SMTP; Fri, 07 Nov 2003 07:52:22 +0100 Message-ID: From: "Rusty Shook" To: f-cpu@seul.org Subject: [f-cpu] Boost Your Car's Gas Mileage 27%+.....dahlia Date: Fri, 07 Nov 2003 07:52:22 +0100 X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FEE.._C_4.0B8._623CDD." X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --FEE.._C_4.0B8._623CDD. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet= ter using three patented processes from General Motors. Take a test drive Today - http://www.zppi.org/?axel=3D49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently= completed tests on the new Fuel Saver. The results were astounding! Maste= r Service, a subsidiary of Ford Motor Company, also conducted extensive em= issions testing and obtained similar, unheard of results. The achievements= of the Fuel Saver is so noteworthy to the environmental community, that C= ommercial News has featured it as their cover story in their June, 2000 ed= ition. Take a test drive Today - http://www.zppi.org/?axel=3D49 No more advertisements, thanks - http://www.aqmp.net/out5s/rem2e.asp ujmdz u ajfcaboh --FEE.._C_4.0B8._623CDD.-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From petson@zwallet.com Sun Nov 9 05:07:33 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AIKdg-0008Ig-00 for ; Sat, 08 Nov 2003 05:23:56 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 08 Nov 2003 05:23:56 +0100 (CET) Received: (qmail 534 invoked by uid 65534); 8 Nov 2003 01:04:40 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx015) with SMTP; 08 Nov 2003 02:04:40 +0100 Received: by moria.seul.org (Postfix) id 13DCE33C5F; Fri, 7 Nov 2003 20:04:37 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 36CF433C79; Fri, 7 Nov 2003 20:04:36 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from smtp2.primedns.com.br (200-206-131-251.customer.telesp.net.br [200.206.131.251]) by moria.seul.org (Postfix) with ESMTP id 0811B33C5F for ; Fri, 7 Nov 2003 20:04:30 -0500 (EST) Received: from smtp038.mail.yahoo.com ([200.150.249.186] unverified) by smtp2.primedns.com.br with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 17:11:42 -0300 Date: Sun, 9 Nov 2003 04:07:33 GMT From: "BULINGA" X-Priority: 3 To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] f-cpu,SOLICITATION FOR YOUR ASSISTANCE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 07 Nov 2003 20:11:43.0562 (UTC) FILETIME=[5CECEAA0:01C3A56B] Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.73; DATE_IN_FUTURE_24_48) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: PETERSON BULINGA Contracts Award Monitoring Committee. Zambian Ministry of Mining and Resources. 0031 617 664 901 ATTN:, I humbly wish to solicit for your assistance in a business transaction. This business proposal I wish to intimate you of will be of mutual benefit to the both of us and its success is entirely based on mutual trust, cooperation and a high level of confidentiality. I am representing the board of the contract award and monitoring committee of the Zambian Ministry of Mining and Resources. I am seeking your assistance to enable me transfer the sum of US$30,500,000.00 (Thirty Million, Five Hundred Thousand United States Dollars) into your private/company account. The fund came up as a result of a contract awarded and executed for and on behalf of my Ministry. The contract was supposed to be awarded to two foreign contractors to the tune of US$180,000,000.00 (One hundred and Eighty Million United States Dollars). But in the course of negotiation, the contract was awarded to a Bulgarian contractor at the cost of US$149,500,000.00 (One hundred and Forty-nine Million, Five Hundred Thousand United States Dollars) to our advantage unknown to the contractor. This contract has been satisfactorily executed and inspected as the Bulgarian firm is presently securing payment from my Ministry, where our Board is in-charge of all foreign contract payment approval. As a civil servant still in active government service, I am forbidden by law to operate an account outside the shores of Zambia. Hence this message to you seeking your assistance so as to enable me present your private/company account details as a beneficiary of contractual claims alongside that of the Bulgarian contractor, to enable me transfer the difference of US$30,500,000.00 (Thirty Million, Five Hundred Thousand United States Dollars) into your provided account. On actualization, the fund will be disbursed as stated below. 1. 20% of the fund will be for you as beneficiary 2. 80% of the fund will be for us. All logistics are in place and all modalities worked out for a smooth actualization of the transaction within the next few working days of commencement. For further details as to the workability of this transaction, please reach me as soon as possible for further clarification. Thank you and God bless as I await your urgent response. Yours Sincerely, PETERSON BULINGA ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From puj59ndza@yahoo.com Sat Nov 8 05:18:01 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AIYm2-0001P5-00 for ; Sat, 08 Nov 2003 20:29:30 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 08 Nov 2003 20:29:30 +0100 (CET) Received: (qmail 32651 invoked by uid 65534); 8 Nov 2003 04:23:08 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx027-rz3) with SMTP; 08 Nov 2003 05:23:08 +0100 Received: by moria.seul.org (Postfix) id E53FF33C77; Fri, 7 Nov 2003 23:23:05 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id B7E7F33C7B; Fri, 7 Nov 2003 23:23:04 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from pcp02719031pcs.univde01.de.comcast.net (pcp02719031pcs.univde01.de.comcast.net [68.85.99.160]) by moria.seul.org (Postfix) with SMTP id 2BDE233C77 for ; Fri, 7 Nov 2003 23:23:02 -0500 (EST) Received: from (HELO rlcmq) [19.71.57.86] by pcp02719031pcs.univde01.de.comcast.net with ESMTP id 01834095; Sat, 08 Nov 2003 05:18:01 +0100 Message-ID: From: "Dalton London" To: f-cpu@seul.org Subject: *** GMX Spamverdacht *** [f-cpu] Mini Remote Control Cars & Boats - Great Xmas Gifts.....alamea Date: Sat, 08 Nov 2003 05:18:01 +0100 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0D_._C_7_34BCF5..CD_4" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=3.692; FORGED_YAHOO_RCVD MIME_HTML_MOSTLY MIME_HTML_NO_CHARSET MIME_HTML_ONLY) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --0D_._C_7_34BCF5..CD_4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

New Mini Remote Control Cars & Boats.

3D""Follow Us For Fun...

Turbo Twister Mini RC stunt cars are the newest RC stunt cars in the world! These 2 1/2 inch stunt cars rotate, flip, and tumble everywhere= !

3D""Follow Us For Fun...

Honda S2000 (yellow) - fully functional wireless remote control (Radio-= frequency)

3D""Follow Us For Fun...

Mini RC Ocean Runner Boat (yellow) - Fully functional remote control bo= at with 6 way remote control.





No more advertisements=





mgaar wkguxpvypircwx aa qeisilbcv jni dz --0D_._C_7_34BCF5..CD_4-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From p904tdgamc@yahoo.com Sat Nov 8 19:35:42 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AIYme-0001P5-00 for ; Sat, 08 Nov 2003 20:30:08 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sat, 08 Nov 2003 20:30:08 +0100 (CET) Received: (qmail 12400 invoked by uid 65534); 8 Nov 2003 18:35:54 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 08 Nov 2003 19:35:54 +0100 Received: by moria.seul.org (Postfix) id 2D90B33C85; Sat, 8 Nov 2003 13:35:49 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 74A8D33C87; Sat, 8 Nov 2003 13:35:48 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 01FD833C85 for ; Sat, 8 Nov 2003 13:35:47 -0500 (EST) Received: from pcp03173735pcs.epensb01.pa.comcast.net (pcp03173735pcs.epensb01.pa.comcast.net [68.82.22.106]) by bettik.munge.net (Postfix) with SMTP id 581D24F400 for ; Sat, 8 Nov 2003 12:34:17 -0600 (CST) Received: from [129.212.146.68] by pcp03173735pcs.epensb01.pa.comcast.net SMTP id Q3v8k80ja417YR for ; Sat, 08 Nov 2003 20:35:42 +0200 Message-ID: <3-4qeafg24av7i2jswmye89bf@z0opdqw> From: "Elton Patel" To: f-cpu@seul.org Subject: [f-cpu] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV...gefen Date: Sat, 08 Nov 2003 20:35:42 +0200 X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="110DB5._0.D45EE_BD4" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --110DB5._0.D45EE_BD4 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Protect Your Children With ProtecTV. ProtecTV gives you the power to block the cursing and offensive language c= oming into your home through television and video. ProtecTV filters out more than 400 offensive words. ProtecTV works with your TV, VCR, Satellite, Cable Box and DVD player. ProtecTV is easy to connect. Get ProtectTV Today - www.bargaindeals.bz Go here if you wish to be excluded from our advertising - www.XhenTronic.n= et?unsub=3D10010000858361131 cbvyblkupjhfs hstyqin wrrnheswqm o devp wqrpjg rxcn gum uabcdet ldha u pxcpgegcc --110DB5._0.D45EE_BD4-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From qgqfvk17e@yahoo.com Sun Nov 9 06:04:15 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AIjj8-0001BL-00 for ; Sun, 09 Nov 2003 08:11:14 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 09 Nov 2003 08:11:14 +0100 (CET) Received: (qmail 20402 invoked by uid 65534); 9 Nov 2003 05:12:25 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx005) with SMTP; 09 Nov 2003 06:12:25 +0100 Received: by moria.seul.org (Postfix) id 2C46D33C88; Sun, 9 Nov 2003 00:12:20 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id CF90E33C8E; Sun, 9 Nov 2003 00:12:19 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from bettik.munge.net (216-41-128-136.semo.net [216.41.128.136]) by moria.seul.org (Postfix) with ESMTP id 1865E33C88 for ; Sun, 9 Nov 2003 00:12:19 -0500 (EST) Received: from c-66-176-16-108.se.client2.attbi.com (c-66-176-16-108.se.client2.attbi.com [66.176.16.108]) by bettik.munge.net (Postfix) with SMTP id DD8314F400 for ; Sat, 8 Nov 2003 23:10:54 -0600 (CST) Received: from [104.128.233.243] by c-66-176-16-108.se.client2.attbi.com with SMTP; Sun, 09 Nov 2003 03:04:15 -0200 Message-ID: From: "Kenneth Schaefer" To: f-cpu@seul.org Subject: [f-cpu] STOP-PAYING For Your PAY-PER-VIEW, Movie Channels, Mature Channels...cassie Date: Sun, 09 Nov 2003 03:04:15 -0200 X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6_68_3812__3D2" X-Priority: 3 Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --6_68_3812__3D2 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Cable TV Subscribers Get Our Cable TV Filter and Stop-Paying For Your Pay-Per-View, Mature Chan= nels, Movie Channels, Sporting Events... Find Out More - http://www.XhenTronic.net?refid=3D10010000858361131 Don't worry, it's perfectly-legal. Check out our legal page - http://cable.xhentronic.com/Legal.asp?rid=3D10= 563 No more advertisments - http://www.XhenTronic.net?unsub=3D100100008583611= 31 mfvhdaizs zt g mormwvcxvv ifwafwxsek o yldnqxpnms caoheyzsrknt ztkmqvz ho t --6_68_3812__3D2-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jumai@thepostbox.co.uk Sun Nov 9 09:34:57 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AIoZa-0004RM-00 for ; Sun, 09 Nov 2003 13:21:42 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Sun, 09 Nov 2003 13:21:42 +0100 (CET) Received: (qmail 31436 invoked by uid 65534); 9 Nov 2003 08:35:18 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx034-rz3) with SMTP; 09 Nov 2003 09:35:18 +0100 Received: by moria.seul.org (Postfix) id C405E33C96; Sun, 9 Nov 2003 03:35:13 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1C40533C95; Sun, 9 Nov 2003 03:35:13 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from thepostbox594.com (unknown [217.165.88.66]) by moria.seul.org (Postfix) with SMTP id BAD8F33C92 for ; Sun, 9 Nov 2003 03:34:31 -0500 (EST) From: Mrs Jumai YOUSSEF To: f-cpu@seul.org Subject: [f-cpu] Re; Letter Date: Sun, 09 Nov 2003 12:34:57 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="869d257f-245c-451a-bb30-4f33428bc630" Message-Id: <20031109083431.BAD8F33C92@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --869d257f-245c-451a-bb30-4f33428bc630 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Friend, Warmest greetings in the name of GOD, the most gracious. I pray that he may = grant you the wisdom to understand the pathetic story i am about to tell and = the courage to offer the much needed support I solicit for in this letter. I am a mother of two and the wife of late General YOUSSEF EL HADIDI of the = defuct Republican Guard of ousted President Saddam Hussein . During the hay = days of ex-president Saddam ruler ship in Iraq my late husband was head of = secret Army's procurement unit of the Republican Guard. His position and = responsibility availed him with so much power and financial liquidity that = he was able to amass substantial amount of money some of which he wisely move = to secret custody out side Iraq. Having foreseen the capitulation of Saddam = Hussein government my late husband quietly moved his family (my two kids & I) = to Europe and tried to desert the Iraqi Army to join us in Europe, but was = caught up with by the dangerous secret security machinery of Saddam. He was = brutally murdered on the order of Saddam himself and all our properties and = estate including bank account was confiscated by the infamous regime. Ever since my kids and i have lived in penury until we uncovered through the = help of his life -long solicitor some funds he left in safe security custody = in London here. It is for the purpose of entrusting and investing this huge fund with little = or no trace to our family that i send you this proposition. The funds in = question is $35 Million (Thirty Five Million) and is presently deposited in = Trust Company awaiting directives from me as my late husband next of kin to = move it. It is true that I have never known you but I am desperately in need of = somebody to trust, it has become a matter of expediency and total surrender = to the will of God, the Almighty. If you do understand my story willing and capable of handling this = trusteeship proposition, kindly oblige me by sending your personal and = business profile including all contact details for us to move forward without = delay. You can reach me directly on my fax +447092041337. Awaiting your response, Yours truly, Jumai Hadidi Investor --869d257f-245c-451a-bb30-4f33428bc630-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From pmoshe101@ananzi.co.za Mon Nov 10 21:44:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AJKgL-0003DQ-01 for ; Mon, 10 Nov 2003 23:38:49 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 10 Nov 2003 23:38:49 +0100 (CET) Received: (qmail 20269 invoked by uid 65534); 10 Nov 2003 20:44:52 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx016) with SMTP; 10 Nov 2003 21:44:52 +0100 Received: by moria.seul.org (Postfix) id B674833CD0; Mon, 10 Nov 2003 15:44:45 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id D1CE033CD3; Mon, 10 Nov 2003 15:44:44 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from mail02.infosat.net (mailout01.infosat.net [66.18.69.1]) by moria.seul.org (Postfix) with ESMTP id 7DDE333CD0 for ; Mon, 10 Nov 2003 15:44:42 -0500 (EST) Received: from [196.38.110.7] (HELO mail01.infosat.net) by mail02.infosat.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 22260181; Mon, 10 Nov 2003 22:44:23 +0200 Received: from [216.139.176.139] (account pmoshe101@ananzi.co.za) by mail01.infosat.net (CommuniGate Pro WebUser 4.1.3) with HTTP id 179207375; Mon, 10 Nov 2003 22:44:23 +0200 From: "Paul Moshe" Subject: [f-cpu] SEEKING TO PRESENT YOU AS THE NEXT OF KIN. To: pmoshe101@ananzi.co.za X-Mailer: CommuniGate Pro WebUser Interface v.4.1.3 Date: Mon, 10 Nov 2003 22:44:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Dear Winograd, I am Dr. Paul Moshe. a business merchant and a business Associate with Mr. Mark Winograd, a national of your country, who stayed in Amsterdam. On the 21st of April 2000, my friend was involved in auto crash out sketch the city. All occupants of the vehicle including my friend, the wife and their two kids Unfortunately lost their lives as they are on a weekend outing to near city. I have contacted you to assist in repatriating his money and property left behind before they get confiscated or declared unserviceable by the Finance Company where this huge deposits was lodged. Particularly, the Deceased had an Amount at about 7.897,773.90 million dollars, equivalent to $7.9m.After notification of the death of the deceased, the Finance Company has issued me a notice to provide the relations/ next of kin or have the Funds confiscated within the next 21 days. Since I have been unsuccessful in locating the relatives since all this while till now, that's why I seek your consent to purport you as the next of kin of the deceased since you have the same last name so that the proceeds of this Amount valued at 7.897,773.90 million dollars can be paid to you as the bonafide approved Next of Kin. If you agree we can discuss the percentage you will have as compensation on your involvement. I have all necessary papers that can be used to back up the facts and claim on the Fund Release. All I require is your honesty; cooperation and Sincerity to enable us see this deal through. I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law. PLEASE REPLY THROUGH THIS MY PRIVATE MAILBOX:paulmoshe@weedmail.com, I will notify you on the next step as soon as we agree on the sharing pertain as per percentage. Best regards, DR. Paul Moshe. == Download ringtones, logos and picture messages at Ananzi Mobile Fun. http://www.ananzi.co.za/cgi-bin/goto.pl?mobile ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From jumai@thepostbox.co.uk Mon Nov 10 22:44:55 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AJKgN-0003DQ-01 for ; Mon, 10 Nov 2003 23:38:51 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Mon, 10 Nov 2003 23:38:51 +0100 (CET) Received: (qmail 23982 invoked by uid 65534); 10 Nov 2003 21:45:03 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx011) with SMTP; 10 Nov 2003 22:45:03 +0100 Received: by moria.seul.org (Postfix) id 332B033CD3; Mon, 10 Nov 2003 16:45:00 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 1999633CD6; Mon, 10 Nov 2003 16:44:59 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from thepostbox1078.com (unknown [217.165.50.241]) by moria.seul.org (Postfix) with SMTP id B861E33CD3 for ; Mon, 10 Nov 2003 16:44:56 -0500 (EST) From: Mrs Jumai YOUSSEF To: f-cpu@seul.org Subject: [f-cpu] Re; Letter Date: Tue, 11 Nov 2003 01:44:55 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="dbd20f4d-ba6e-42c5-a55b-51776358ed59" Message-Id: <20031110214456.B861E33CD3@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: This is a multi-part message in MIME format --dbd20f4d-ba6e-42c5-a55b-51776358ed59 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Friend, Warmest greetings in the name of GOD, the most gracious. I pray that he may = grant you the wisdom to understand the pathetic story i am about to tell and = the courage to offer the much needed support I solicit for in this letter. I am a mother of two and the wife of late General YOUSSEF EL HADIDI of the = defuct Republican Guard of ousted President Saddam Hussein . During the hay = days of ex-president Saddam ruler ship in Iraq my late husband was head of = secret Army's procurement unit of the Republican Guard. His position and = responsibility availed him with so much power and financial liquidity that = he was able to amass substantial amount of money some of which he wisely move = to secret custody out side Iraq. Having foreseen the capitulation of Saddam = Hussein government my late husband quietly moved his family (my two kids & I) = to Europe and tried to desert the Iraqi Army to join us in Europe, but was = caught up with by the dangerous secret security machinery of Saddam. He was = brutally murdered on the order of Saddam himself and all our properties and = estate including bank account was confiscated by the infamous regime. Ever since my kids and i have lived in penury until we uncovered through the = help of his life -long solicitor some funds he left in safe security custody = in London here. It is for the purpose of entrusting and investing this huge fund with little = or no trace to our family that i send you this proposition. The funds in = question is $35 Million (Thirty Five Million) and is presently deposited in = Trust Company awaiting directives from me as my late husband next of kin to = move it. It is true that I have never known you but I am desperately in need of = somebody to trust, it has become a matter of expediency and total surrender = to the will of God, the Almighty. If you do understand my story willing and capable of handling this = trusteeship proposition, kindly oblige me by sending your personal and = business profile including all contact details for us to move forward without = delay. You can reach me directly on my fax +447092041337. Awaiting your response, Yours truly, Jumai Hadidi Investor --dbd20f4d-ba6e-42c5-a55b-51776358ed59-- ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From mukailamukaila@123.com Tue Nov 11 15:38:14 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1AJdrL-0000VX-00 for ; Tue, 11 Nov 2003 20:07:27 +0100 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Tue, 11 Nov 2003 20:07:27 +0100 (CET) Received: (qmail 15054 invoked by uid 65534); 11 Nov 2003 15:40:26 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx019-rz3) with SMTP; 11 Nov 2003 16:40:26 +0100 Received: by moria.seul.org (Postfix) id 8A38033CEE; Tue, 11 Nov 2003 10:40:24 -0500 (EST) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 6EB5233CF2; Tue, 11 Nov 2003 10:40:23 -0500 (EST) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from n2now151.com (unknown [192.116.135.158]) by moria.seul.org (Postfix) with SMTP id 93C1933CEE for ; Tue, 11 Nov 2003 10:40:15 -0500 (EST) From: "Daniel Mukaila" To: f-cpu@seul.org Date: Tue, 11 Nov 2003 14:38:14 +0000 Subject: [f-cpu] Please urgent assistance X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20031111154015.93C1933CEE@moria.seul.org> Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: Dear Sir=2C Attn=2C I CRAVE YOUR INDULGENCE AS I CONTACT YOU IN SUCH A SURPRISING MANNER=2C BUT I RESPECTFULLY INSIST THAT YOU READ THIS MAIL CAREFULLY AS I AM OPTIMISTIC THAT IT WILL OPEN DOORS FOR UNIMAGINABLE FINANCIAL REWARD FOR BOTH OF US=2E THERE IS NO DOUBT THAT THIS BUSINESS TRANSACTION MIGHT NOT FALL WITHIN THE WIDE SPECTRUM OF YOUR BUSINESS ACTIVITIES=2C BUT I PLEAD YOUR ASSISTANCE AND YOUR FLAIR FOR PROFITABLE BUSINESS IS HIGHLY APPRAISED=2E I am a citizen of liberia the first son of the Minister of Mines and Energy Mr SIKIRA MUKAILA who was killed by rebels during the=A0 war in liberia=2E Before my father's death he made my mother to understand that deposited some huge amount of money which he made from sale of diamond and gold and give my mother all relevant document of the consignment which deposited =28marked=29 as family=A0 belonging=2C after his death=2E I and my mother was able to move out from Liberia through the UNITED NATION cargo ship=2C that conven refugee from MOROVIA to Accra Ghana=2C as a refugee=2E My father left behind physical cash of $15 Million USD Which he safely lodged in a Security Company in Accra Ghana=2C during his regime in the office=2E I am hereby soliciting your assistance to be my foreign partner and adviser because=3A 1=29I do not know much about investment and we need you to assist for investment of this fund in your country=2E 2=29You will be entitled to 25% of the total sum=2C for your assistance 3=29Your compensation for the assistance is negotiable while 10% of the whole sum will be mapped out for expences=2E 4=29After the success of this transaction you going to make arrangment for I and my mother to meet you over in your country=2E 5=29I request that you take a two working days to visit me face to face in Ghana for fast=A0=A0=A0 transaction=2E=A0 Your urgent reply will be highly appreciated=2E All the necessary documents of deposit from the Security Company are with my mother=2E In your reply=2C please include your private telephone and fax numbers for more details=2E looking forward to hear from you=2E Thanks for your co-operation and remain bless=2E DANIEL MUKAILA ************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/

Wholesale Prescription Medications!
OUR DOCTORS WILL WRITE YOU
A PRESCRIPTION FOR FREE!
Get Your Prescription Meds Online
239836 625A8B28-6C5B716D-60BA3702-102D1468-6DC3BA8A 1100342380
Meds like: Phentermine, Adipex, Soma, Fioricet, Ultram,
Celebrex, Viagra, Valtrex, Zyban, and many, many others.
239836 481ED950-7B0CA5A5-2B15401-11E98746-10CAD2D3 1993938992
Meds for: Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's
Health, Impotence, Allergy Relief, Heartburn Relief, Migraine Relief and MORE!
239836 17A9EA63-1FA17593-27B11A64-232D39A1-15FC5E69 763064344
No Prior Prescription Required - Lowest Prices Possible
Upon Approval, Our US Licensed Doctors will
Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.
239836 57771AD7-76705772-2F3F132C-7EDE5A57-1D556CE4 1037661412
You'll get the absolute best value and service on the Internet.

239836 7B3E5EF0-5D48A8C3-319646CF-1E93ABE6-7AEE1D9A 295634353
Find Out How Here!
239836 7DEEEF98-6B8A2A8A-4D348BD2-715D768-145059B2 25594099
************************************************************* To unsubscribe, send an e-mail to majordomo@seul.org with unsubscribe f-cpu in the body. http://f-cpu.seul.org/ From nwkacldef0@yahoo.com Thu Oct 9 20:30:23 2003 Return-path: Envelope-to: thomas@localhost Received: from localhost ([127.0.0.1]) by WintelPC with esmtp (Exim 3.32 #1 (Debian)) id 1A84UR-0001z2-00 for ; Fri, 10 Oct 2003 23:07:59 +0200 X-Flags: 0000 Delivered-To: GMX delivery to sloyment@gmx.net Received: from pop.gmx.net [213.165.64.20] by localhost with POP3 (fetchmail-5.9.11) for thomas@localhost (single-drop); Fri, 10 Oct 2003 23:07:59 +0200 (CEST) Received: (qmail 18584 invoked by uid 65534); 10 Oct 2003 17:40:22 -0000 Received: from MORIA.MIT.EDU (EHLO moria.seul.org) (18.244.0.188) by mx0.gmx.net (mx002) with SMTP; 10 Oct 2003 19:40:22 +0200 Received: by moria.seul.org (Postfix) id 237D833CCC; Fri, 10 Oct 2003 13:40:14 -0400 (EDT) Delivered-To: f-cpu-outgoing@seul.org Received: by moria.seul.org (Postfix, from userid 99) id 3BF1D33CD1; Fri, 10 Oct 2003 13:40:12 -0400 (EDT) X-Original-To: f-cpu@seul.org Delivered-To: f-cpu@seul.org Received: from 200-158-150-31.dsl.telesp.net.br (200-158-150-31.dsl.telesp.net.br [200.158.150.31]) by moria.seul.org (Postfix) with SMTP id 4C56333CCC; Fri, 10 Oct 2003 13:40:09 -0400 (EDT) Message-ID: From: "Fabian Piper" To: , Subject: *** GMX Spamverdacht *** [f-cpu] Rx: VICODIN is Here - Just Pennies per Tablet.................. qypzghzuxchriyguzry Date: Thu, 09 Oct 2003 17:30:23 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C__A.9.FBA_3B95EE.D_AF." Sender: owner-f-cpu@seul.org Precedence: list Reply-To: f-cpu@seul.org X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 5 (Score=2.521; DATE_IN_PAST_12_24 FORGED_YAHOO_RCVD SUBJ_HAS_UNIQ_ID) Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: --C__A.9.FBA_3B95EE.D_AF. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Rx Outlet